From 0030bbb734a2caf21613c01d18a34c788acdcc00 Mon Sep 17 00:00:00 2001 From: Nick Charlton Date: Mon, 23 Dec 2024 21:20:03 +0000 Subject: [PATCH] Add recent podcast episodes We fetch the most recent episodes from both the Giant Robots and Bike Shed feeds, then list them in the README. The two feeds are combined in order, so it appears like there's one list even though it comes from different sources. --- bin/update_readme | 7 + lib/combined_rss_feed.rb | 23 + lib/github_readme.rb | 3 + lib/rss_feed.rb | 2 + profile/README.md | 19 + spec/combined_rss_feed_spec.rb | 49 + spec/fixtures/bike_shed_feed.xml | 114837 ++++++++++++++++++++++ spec/fixtures/giant_robots_feed.xml | 128515 +++++++++++++++++++++++++ spec/spec_helper.rb | 6 + 9 files changed, 243461 insertions(+) create mode 100644 lib/combined_rss_feed.rb create mode 100644 spec/combined_rss_feed_spec.rb create mode 100644 spec/fixtures/bike_shed_feed.xml create mode 100644 spec/fixtures/giant_robots_feed.xml diff --git a/bin/update_readme b/bin/update_readme index bfeff84..9249f32 100755 --- a/bin/update_readme +++ b/bin/update_readme @@ -10,5 +10,12 @@ require "github_readme" readme = Readme.new("profile/README.md") blog = RssFeed.new(url: "https://feeds.feedburner.com/GiantRobotsSmashingIntoOtherGiantRobots") +podcasts = CombinedRssFeed.new( + feed_urls: [ + "https://podcast.thoughtbot.com/rss", + "https://bikeshed.thoughtbot.com/rss" + ] +) readme.update(section: "blog", items: blog.take(5)) +readme.update(section: "podcasts", items: podcasts.take(5)) diff --git a/lib/combined_rss_feed.rb b/lib/combined_rss_feed.rb new file mode 100644 index 0000000..cbe25b2 --- /dev/null +++ b/lib/combined_rss_feed.rb @@ -0,0 +1,23 @@ +require "rss_feed" + +class CombinedRssFeed + include Enumerable + + def initialize(feed_urls:) + @rss_feeds = feed_urls.map { |url| RssFeed.new(url: url) } + end + + def each + rss_feeds + .map(&:entries) + .flatten + .compact + .sort_by(&:created_at) + .reverse! + .each { |entry| yield entry } + end + + private + + attr_reader :rss_feeds +end diff --git a/lib/github_readme.rb b/lib/github_readme.rb index b3e2e49..c17aad5 100644 --- a/lib/github_readme.rb +++ b/lib/github_readme.rb @@ -2,4 +2,7 @@ require "feed_item" require "rss_feed" +require "combined_rss_feed" require "readme" + +Excon.defaults[:middlewares].push(Excon::Middleware::RedirectFollower) diff --git a/lib/rss_feed.rb b/lib/rss_feed.rb index 4afe61f..73e71c3 100644 --- a/lib/rss_feed.rb +++ b/lib/rss_feed.rb @@ -2,6 +2,8 @@ require "excon" require "feedjira" +require "feed_item" + class RssFeed include Enumerable diff --git a/profile/README.md b/profile/README.md index 8433394..4050da7 100644 --- a/profile/README.md +++ b/profile/README.md @@ -12,6 +12,24 @@ for your business each step of the way. Since 2003, we have worked to produce higher-quality products while improving team processes and have done so successfully for over [1,000 clients.][case studies] +
+ +### Podcasts + + +[554: Founding a Life Saving Business from your dorm room with Luká Yancopoulos](https://podcast.thoughtbot.com/554) + +[451: Making Time for and Managing Focus](https://bikeshed.thoughtbot.com/451) + +[450: Javascript-Driven Development?](https://bikeshed.thoughtbot.com/450) + +[553: The One with Sami and Chad](https://podcast.thoughtbot.com/553) + +[449: Evergreen skills for new-ish developers](https://bikeshed.thoughtbot.com/449) + + + + ### Writing @@ -26,6 +44,7 @@ successfully for over [1,000 clients.][case studies] [Testing SQL queries in a Ruby service](https://thoughtbot.com/blog/testing-sql-queries-in-a-ruby-service) +
[thoughtbot]: https://thoughtbot.com [design]: https://thoughtbot.com/services/product-design diff --git a/spec/combined_rss_feed_spec.rb b/spec/combined_rss_feed_spec.rb new file mode 100644 index 0000000..20fa38b --- /dev/null +++ b/spec/combined_rss_feed_spec.rb @@ -0,0 +1,49 @@ +require "spec_helper" +require "combined_rss_feed" + +RSpec.describe CombinedRssFeed do + it "combines a given set of feeds into an ordered list by most recent" do + Excon.stub( + {host: "podcast.thoughtbot.com"}, + {status: 200, body: giant_robots_feed} + ) + Excon.stub( + {host: "bikeshed.thoughtbot.com"}, + {status: 200, body: bike_shed_feed} + ) + + combined_items = described_class.new( + feed_urls: [ + "https://podcast.thoughtbot.com/rss", + "https://bikeshed.thoughtbot.com/rss" + ] + ) + recent = combined_items.take(3) + + expect(recent).to include( + have_attributes( + title: "451: Making Time for and Managing Focus", + url: "https://bikeshed.thoughtbot.com/451", + created_at: match_date(Date.new(2024, 12, 17)) + ), + have_attributes( + title: "450: Javascript-Driven Development?", + url: "https://bikeshed.thoughtbot.com/450", + created_at: match_date(Date.new(2024, 12, 10)) + ), + have_attributes( + title: "553: The One with Sami and Chad", + url: "https://podcast.thoughtbot.com/553", + created_at: match_date(Date.new(2024, 12, 5)) + ) + ) + end + + def giant_robots_feed + File.read("spec/fixtures/giant_robots_feed.xml") + end + + def bike_shed_feed + File.read("spec/fixtures/bike_shed_feed.xml") + end +end diff --git a/spec/fixtures/bike_shed_feed.xml b/spec/fixtures/bike_shed_feed.xml new file mode 100644 index 0000000..3a61ba6 --- /dev/null +++ b/spec/fixtures/bike_shed_feed.xml @@ -0,0 +1,114837 @@ + + + + feed01.fireside.fm + Tue, 17 Dec 2024 02:46:14 -0600 + Fireside (https://fireside.fm) + The Bike Shed + https://bikeshed.thoughtbot.com + Tue, 17 Dec 2024 08:45:04 -0000 + On The Bike Shed, hosts Joël Quenneville and Stephanie Minn discuss development experiences and challenges at thoughtbot with Ruby, Rails, JavaScript, and whatever else is drawing their attention, admiration, or ire this week. + + en + © 2024 The Bike Shed + episodic + + thoughtbot + On The Bike Shed, hosts Joël Quenneville and Stephanie Minn discuss development experiences and challenges at thoughtbot with Ruby, Rails, JavaScript, and whatever else is drawing their attention, admiration, or ire this week. + + + no + web development,ruby,javascript,rails,back-end,front-end,app development,graphql,developer + + thoughtbot + hosts@bikeshed.fm + + yes + Support the show! + + + + + + 451: Making Time for and Managing Focus + https://bikeshed.thoughtbot.com/451 + 606e8698-3e7f-41d2-b31c-3513b68736e6 + Tue, 17 Dec 2024 03:00:00 -0500 + thoughtbot + + full + thoughtbot + It’s officially the holidays at the Bike Shed! Defrag your hard drives and take a break with Joël and Stephanie as they breakdown different ways to manage your focus during the day. + 29:25 + no + + It’s officially the holidays at the Bike Shed! Defrag your hard drives and take a break with Joël and Stephanie as they breakdown different ways to manage your focus during the day. +The pair discuss separating coding time from thinking time when working, the pros and cons of blocking out time for different tasks and clever ways to move seamlessly from one project to the next without losing momentum. +Joël has some more timezone facts to share, while Stephanie reveals her worst enemy when it comes to productivity. +— +Try out the Pomodoro system (https://en.wikipedia.org/wiki/Pomodoro_Technique) in your workflow and let us know if it works for you! +Your hosts for this episode have been thoughtbot’s own Stephanie Minn and Joël Quenneville (https://www.linkedin.com/in/joel-quenneville-96b18b58/). +If you would like to support the show, head over to our GitHub page (https://github.com/sponsors/thoughtbot), or check out our website (https://bikeshed.thoughtbot.com). +Got a question or comment about the show? Why not write to our hosts: hosts@bikeshed.fm +This has been a thoughtbot (https://thoughtbot.com/) podcast. +Stay up to date by following us on social media - LinkedIn (https://www.linkedin.com/company/150727/) - Mastodon (https://thoughtbot.social/@thoughtbot) - Instagram (https://www.instagram.com/thoughtbot/) +© 2024 thoughtbot, inc. + + focus, tasks, concentration + + It’s officially the holidays at the Bike Shed! Defrag your hard drives and take a break with Joël and Stephanie as they breakdown different ways to manage your focus during the day.

+ +

The pair discuss separating coding time from thinking time when working, the pros and cons of blocking out time for different tasks and clever ways to move seamlessly from one project to the next without losing momentum.

+ +

Joël has some more timezone facts to share, while Stephanie reveals her worst enemy when it comes to productivity.

+ +

—

+ +

Try out the Pomodoro system in your workflow and let us know if it works for you!

+ +

Your hosts for this episode have been thoughtbot’s own Stephanie Minn and Joël Quenneville.

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@bikeshed.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support The Bike Shed

]]> + + + It’s officially the holidays at the Bike Shed! Defrag your hard drives and take a break with Joël and Stephanie as they breakdown different ways to manage your focus during the day.

+ +

The pair discuss separating coding time from thinking time when working, the pros and cons of blocking out time for different tasks and clever ways to move seamlessly from one project to the next without losing momentum.

+ +

Joël has some more timezone facts to share, while Stephanie reveals her worst enemy when it comes to productivity.

+ +

—

+ +

Try out the Pomodoro system in your workflow and let us know if it works for you!

+ +

Your hosts for this episode have been thoughtbot’s own Stephanie Minn and Joël Quenneville.

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@bikeshed.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+P-SgXhXz + + ]]> + + Joël Quenneville + Stephanie Minn + + + 450: Javascript-Driven Development? + https://bikeshed.thoughtbot.com/450 + 43739264-f48a-4440-b30a-12e41dbbcd17 + Tue, 10 Dec 2024 03:00:00 -0500 + thoughtbot + + full + thoughtbot + Joël and Stephanie go back to fundamentals as they pick apart some recent conversations they’ve been having around the office. + 39:57 + no + + Joël and Stephanie go back to fundamentals as they pick apart some recent conversations they’ve been having around the office. +Together they discuss the advantages of GraphQL over a REST API, how they utilise JSONB over a regular column or table, and the use-cases for and against a frontend framework like React. +But what’s the theme that ties all these conversations together? +— +The article mentioned in this episode was Why I’m over GraphQL (https://bessey.dev/blog/2024/05/24/why-im-over-graphql/) +Your hosts for this episode have been thoughtbot’s own Stephanie Minn and Joël Quenneville (https://www.linkedin.com/in/joel-quenneville-96b18b58/). +If you would like to support the show, head over to our GitHub page (https://github.com/sponsors/thoughtbot), or check out our website (https://bikeshed.thoughtbot.com). +Got a question or comment about the show? Why not write to our hosts: hosts@bikeshed.fm +This has been a thoughtbot (https://thoughtbot.com/) podcast. +Stay up to date by following us on social media - LinkedIn (https://www.linkedin.com/company/150727/) - Mastodon (https://thoughtbot.social/@thoughtbot) - Instagram (https://www.instagram.com/thoughtbot/) +© 2024 thoughtbot, inc. + + javascript, GraphQL, framework, coding + + Joël and Stephanie go back to fundamentals as they pick apart some recent conversations they’ve been having around the office.

+ +

Together they discuss the advantages of GraphQL over a REST API, how they utilise JSONB over a regular column or table, and the use-cases for and against a frontend framework like React.

+ +

But what’s the theme that ties all these conversations together?

+ +

—
+The article mentioned in this episode was Why I’m over GraphQL

+ +

Your hosts for this episode have been thoughtbot’s own Stephanie Minn and Joël Quenneville.

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@bikeshed.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support The Bike Shed

]]> + + + Joël and Stephanie go back to fundamentals as they pick apart some recent conversations they’ve been having around the office.

+ +

Together they discuss the advantages of GraphQL over a REST API, how they utilise JSONB over a regular column or table, and the use-cases for and against a frontend framework like React.

+ +

But what’s the theme that ties all these conversations together?

+ +

—
+The article mentioned in this episode was Why I’m over GraphQL

+ +

Your hosts for this episode have been thoughtbot’s own Stephanie Minn and Joël Quenneville.

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@bikeshed.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+bz6RE4nv + + ]]> + + Joël Quenneville + Stephanie Minn + + + 449: Evergreen skills for new-ish developers + https://bikeshed.thoughtbot.com/449 + 79547e26-5c2f-4656-8b0d-b5d2cbbf681d + Tue, 03 Dec 2024 03:00:00 -0500 + thoughtbot + + full + thoughtbot + + 37:41 + no + + One of the most challenging things about starting out as a developer is how much you need to master all at once. And with so much to learn, it can be difficult for experts to guide fresh developers and advise them on where to focus first. Luckily, some skills will always be useful, no matter what language you’re coding in. In today’s episode, Stephanie and Joël tackle this topic by unpacking several key evergreen skills that will always be valuable, from reading error messages to deciphering a stack trace. They break down how new-ish developers can start acquiring these skills, key obstacles they’re likely to encounter, and how to ask for help when you hit a block. Their conversation covers the ins and outs of debugging, how to feel comfortable in your editor as a new developer, the art of asking for help, and much more. They also share plenty of valuable tips to help you on your journey – including one that will help you commit more frequently. Tune in now to hear it all! +Key Points From This Episode: +Stephanie’s time at the Ruby Conference in Chicago. +The challenges of advising new-ish developers as an expert. +Broad evergreen skills that are always valuable to learn. +Tips on mastering debugging as a core skill. +How to improve your ability to read error messages. +Our approach to resolving errors and isolating what is wrong. +Advice for learning to read a stack trace (even though it’s intimidating). +Strategies for fixing different types of bugs. +The value of editor mastery and version history. +Tips on how to commit more frequently as a new developer. +Learning to ask for help when you hit a block. +The art of structuring your questions when asking for help. +Breaking down large tasks into smaller sections. +Learning to find focus as a new developer. +Links Mentioned in Today’s Episode: +What technologies should I learn? (https://thoughtbot.com/blog/what-technologies-should-i-learn) +Debugging blog post series (https://thoughtbot.com/blog/tags/debugging-series-2021) +Asking about solutions rather than problems (https://xyproblem.info/) +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) +Mailtrap (https://l.rw.rw/the_bike_shed) +WorkOS (workos.com/) + + + One of the most challenging things about starting out as a developer is how much you need to master all at once. And with so much to learn, it can be difficult for experts to guide fresh developers and advise them on where to focus first. Luckily, some skills will always be useful, no matter what language you’re coding in. In today’s episode, Stephanie and Joël tackle this topic by unpacking several key evergreen skills that will always be valuable, from reading error messages to deciphering a stack trace. They break down how new-ish developers can start acquiring these skills, key obstacles they’re likely to encounter, and how to ask for help when you hit a block. Their conversation covers the ins and outs of debugging, how to feel comfortable in your editor as a new developer, the art of asking for help, and much more. They also share plenty of valuable tips to help you on your journey – including one that will help you commit more frequently. Tune in now to hear it all!

+ +

Key Points From This Episode:

+ +

Stephanie’s time at the Ruby Conference in Chicago.
+The challenges of advising new-ish developers as an expert.
+Broad evergreen skills that are always valuable to learn.
+Tips on mastering debugging as a core skill.
+How to improve your ability to read error messages.
+Our approach to resolving errors and isolating what is wrong.
+Advice for learning to read a stack trace (even though it’s intimidating).
+Strategies for fixing different types of bugs.
+The value of editor mastery and version history.
+Tips on how to commit more frequently as a new developer.
+Learning to ask for help when you hit a block.
+The art of structuring your questions when asking for help.
+Breaking down large tasks into smaller sections.
+Learning to find focus as a new developer.

+ +

Links Mentioned in Today’s Episode:

+ +

What technologies should I learn?
+Debugging blog post series
+Asking about solutions rather than problems
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed
+Mailtrap
+[WorkOS](workos.com/)

Support The Bike Shed

]]> + + + One of the most challenging things about starting out as a developer is how much you need to master all at once. And with so much to learn, it can be difficult for experts to guide fresh developers and advise them on where to focus first. Luckily, some skills will always be useful, no matter what language you’re coding in. In today’s episode, Stephanie and Joël tackle this topic by unpacking several key evergreen skills that will always be valuable, from reading error messages to deciphering a stack trace. They break down how new-ish developers can start acquiring these skills, key obstacles they’re likely to encounter, and how to ask for help when you hit a block. Their conversation covers the ins and outs of debugging, how to feel comfortable in your editor as a new developer, the art of asking for help, and much more. They also share plenty of valuable tips to help you on your journey – including one that will help you commit more frequently. Tune in now to hear it all!

+ +

Key Points From This Episode:

+ +

Stephanie’s time at the Ruby Conference in Chicago.
+The challenges of advising new-ish developers as an expert.
+Broad evergreen skills that are always valuable to learn.
+Tips on mastering debugging as a core skill.
+How to improve your ability to read error messages.
+Our approach to resolving errors and isolating what is wrong.
+Advice for learning to read a stack trace (even though it’s intimidating).
+Strategies for fixing different types of bugs.
+The value of editor mastery and version history.
+Tips on how to commit more frequently as a new developer.
+Learning to ask for help when you hit a block.
+The art of structuring your questions when asking for help.
+Breaking down large tasks into smaller sections.
+Learning to find focus as a new developer.

+ +

Links Mentioned in Today’s Episode:

+ +

What technologies should I learn?
+Debugging blog post series
+Asking about solutions rather than problems
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed
+Mailtrap
+[WorkOS](workos.com/)

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+pJcn9XbD + + ]]> + + Joël Quenneville + Stephanie Minn + + + 448: Other Uses for Tests + https://bikeshed.thoughtbot.com/448 + dffb29be-31bd-453d-a7a0-f580ba0e4620 + Tue, 26 Nov 2024 03:00:00 -0500 + thoughtbot + + full + thoughtbot + + 33:42 + no + + How can tests serve beyond just catching bugs in code? In this episode, Stephanie and Joël dive into the various roles that tests can play in a developer's toolkit. Covering all the fundamentals, from aiding knowledge transfer and documentation to ensuring accountability in code reviews, they explore the unexpected ways that tests support developer workflows. They also explain the balance between writing detailed tests for documentation and managing complex code, and how effective testing practices can help developers become more confident and informed in their work. Gain insights about the impact of test suites on team collaboration, code readability, and project handoffs, and discover how tests can provide a “living specification” that evolves with your application. Join us to learn how to make the most of your tests and unlock new ways to elevate your development process. Tune in now! +How test suites can act as living documentation that changes with the codebase. +Using tests to document complex code before handing off a project. +How backfilling tests can reveal critical edge cases in legacy code. +The benefits of tests for developers working with complex code areas. +Why a balance between comprehensive coverage and “good enough” testing is essential. +Challenges associated with reading tests as documentation in certain codebases. +Techniques for improving the readability of test suites for documentation. +Advantages of using tests as a tool for accountability in code reviews. +The concept of test-first code reviews to improve understanding of pull requests. +Links Mentioned in Today’s Episode: +Mailtrap (https://l.rw.rw/the_bike_shed) +'Unlock the value of tests in understanding your codebase' (https://thoughtbot.com/blog/unlock-the-value-of-tests-in-understanding-your-codebase) +Good Enough Testing (https://goodenoughtesting.com/) +'RailsConf 2024: So writing tests feels painful. What now? by Stephanie Minn' (https://youtu.be/t5MnS20adG4) +'Algorithms we develop software by' (https://grantslatton.com/software-pathfinding#algorithms-we-develop-software-by) +Exercism (exercism.io) +WorkOS (https://workos.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) + + + How can tests serve beyond just catching bugs in code? In this episode, Stephanie and Joël dive into the various roles that tests can play in a developer's toolkit. Covering all the fundamentals, from aiding knowledge transfer and documentation to ensuring accountability in code reviews, they explore the unexpected ways that tests support developer workflows. They also explain the balance between writing detailed tests for documentation and managing complex code, and how effective testing practices can help developers become more confident and informed in their work. Gain insights about the impact of test suites on team collaboration, code readability, and project handoffs, and discover how tests can provide a “living specification” that evolves with your application. Join us to learn how to make the most of your tests and unlock new ways to elevate your development process. Tune in now!

+ +

How test suites can act as living documentation that changes with the codebase.
+Using tests to document complex code before handing off a project.
+How backfilling tests can reveal critical edge cases in legacy code.
+The benefits of tests for developers working with complex code areas.
+Why a balance between comprehensive coverage and “good enough” testing is essential.
+Challenges associated with reading tests as documentation in certain codebases.
+Techniques for improving the readability of test suites for documentation.
+Advantages of using tests as a tool for accountability in code reviews.
+The concept of test-first code reviews to improve understanding of pull requests.

+ +

Links Mentioned in Today’s Episode:
+Mailtrap
+'Unlock the value of tests in understanding your codebase'
+Good Enough Testing
+'RailsConf 2024: So writing tests feels painful. What now? by Stephanie Minn'
+'Algorithms we develop software by'
+[Exercism](exercism.io)
+WorkOS
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + + How can tests serve beyond just catching bugs in code? In this episode, Stephanie and Joël dive into the various roles that tests can play in a developer's toolkit. Covering all the fundamentals, from aiding knowledge transfer and documentation to ensuring accountability in code reviews, they explore the unexpected ways that tests support developer workflows. They also explain the balance between writing detailed tests for documentation and managing complex code, and how effective testing practices can help developers become more confident and informed in their work. Gain insights about the impact of test suites on team collaboration, code readability, and project handoffs, and discover how tests can provide a “living specification” that evolves with your application. Join us to learn how to make the most of your tests and unlock new ways to elevate your development process. Tune in now!

+ +

How test suites can act as living documentation that changes with the codebase.
+Using tests to document complex code before handing off a project.
+How backfilling tests can reveal critical edge cases in legacy code.
+The benefits of tests for developers working with complex code areas.
+Why a balance between comprehensive coverage and “good enough” testing is essential.
+Challenges associated with reading tests as documentation in certain codebases.
+Techniques for improving the readability of test suites for documentation.
+Advantages of using tests as a tool for accountability in code reviews.
+The concept of test-first code reviews to improve understanding of pull requests.

+ +

Links Mentioned in Today’s Episode:
+Mailtrap
+'Unlock the value of tests in understanding your codebase'
+Good Enough Testing
+'RailsConf 2024: So writing tests feels painful. What now? by Stephanie Minn'
+'Algorithms we develop software by'
+[Exercism](exercism.io)
+WorkOS
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+UgU4Rucf + + ]]> + + Joël Quenneville + Stephanie Minn + + + 447: How to (not) implement impersonation + https://bikeshed.thoughtbot.com/447 + 53fbffbd-6827-45b2-9bc1-4fa02fb08d9b + Tue, 19 Nov 2024 03:00:00 -0500 + thoughtbot + + full + thoughtbot + + 37:39 + no + + 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/) + + + 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
+Notion Calendar
+'Implementing Impersonation'
+Sustainable Web Development with Ruby on Rails
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed
+WorkOS

Support 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
+Notion Calendar
+'Implementing Impersonation'
+Sustainable Web Development with Ruby on Rails
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed
+WorkOS

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GY-PGAY_ + + ]]> + + Joël Quenneville + Stephanie Minn + + + 446: All about rewrites + https://bikeshed.thoughtbot.com/446 + 90ae4176-2206-470a-892e-c0c88946acc3 + Tue, 12 Nov 2024 03:00:00 -0500 + thoughtbot + + full + thoughtbot + + 35:31 + no + + 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) + + + 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
+WorkOS
+Matt Brictson: ‘Simplify your Capybara selectors’
+React Testing Library Guidelines
+Capybara Accessibility Selectors
+Good Enough Testing
+‘RailsConf 2023: The Math Every Programmer Needs by Joël Quenneville’
+‘Testing Your Edge Cases’
+'Working Iteratively'
+'Technical Considerations to Help Scale Your Product'
+Dan McKinley: ‘Choose Boring Technology'
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + + 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
+WorkOS
+Matt Brictson: ‘Simplify your Capybara selectors’
+React Testing Library Guidelines
+Capybara Accessibility Selectors
+Good Enough Testing
+‘RailsConf 2023: The Math Every Programmer Needs by Joël Quenneville’
+‘Testing Your Edge Cases’
+'Working Iteratively'
+'Technical Considerations to Help Scale Your Product'
+Dan McKinley: ‘Choose Boring Technology'
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+D39ibilB + + ]]> + + Joël Quenneville + Stephanie Minn + + + 445: Working Iteratively + https://bikeshed.thoughtbot.com/445 + b6ec1c16-c92b-4e5e-8967-35f0f86d513a + Tue, 29 Oct 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 40:06 + no + + 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) + + + 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
+Working Incrementally
+Working Iteratively
+Elephant Carpaccio Exercise
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + + 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
+Working Incrementally
+Working Iteratively
+Elephant Carpaccio Exercise
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+hQLcar7p + + ]]> + + Joël Quenneville + Stephanie Minn + + + 444: From Solutions To Patterns + https://bikeshed.thoughtbot.com/444 + d3ac6150-2e74-4967-ae79-2af328eceab0 + Tue, 15 Oct 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 34:58 + no + + 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) + + + 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
+RubyConf 2021 - The Intro to Abstraction I Wish I'd Received
+'Ruby Science'
+Refactoring.Guru
+Thoughtbot code review guide
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + + 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
+RubyConf 2021 - The Intro to Abstraction I Wish I'd Received
+'Ruby Science'
+Refactoring.Guru
+Thoughtbot code review guide
+The Bike Shed
+Joël Quenneville on LinkedIn
+Joël Quenneville on X
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-q63OuRu + + ]]> + + Joël Quenneville + Stephanie Minn + + + 443: Rails World and Open Source with Stefanni Brasil + https://bikeshed.thoughtbot.com/443 + fc9c5697-5b07-46af-ba28-6bc7a3a3b1e4 + Tue, 08 Oct 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 32:23 + no + + 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/) + + + 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
+Stefanni Brasil on X
+Thoughtbot Open Summit
+Open Source Issues doc
+Open Source at Thoughtbot
+Polished Ruby Programming
+Faker Gem
+Rails World

+The Bike Shed
+Joël Quenneville on LinkedIn

Support The Bike Shed

]]> + + + 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
+Stefanni Brasil on X
+Thoughtbot Open Summit
+Open Source Issues doc
+Open Source at Thoughtbot
+Polished Ruby Programming
+Faker Gem
+Rails World

+The Bike Shed
+Joël Quenneville on LinkedIn

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+lQInlTqA + + ]]> + + Joël Quenneville + Stephanie Minn + + + 442: Paradigms - What is a Program? + https://bikeshed.thoughtbot.com/442 + 904d9472-bf80-4350-90ef-3f427b812e11 + Tue, 01 Oct 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 42:22 + no + + 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) + + + 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
+Church-Turing Thesis
+Dynamic type systems are not inherently more open
+What is Functional Programming?
+Blocks as an abstraction vs for loops
+Functional core imperative shell
+Testing objects with a functional mindset

+The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + + 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
+Church-Turing Thesis
+Dynamic type systems are not inherently more open
+What is Functional Programming?
+Blocks as an abstraction vs for loops
+Functional core imperative shell
+Testing objects with a functional mindset

+The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MObK5uvq + + ]]> + + Joël Quenneville + Stephanie Minn + + + 441: The Pickaxe Book with Noel Rappin + https://bikeshed.thoughtbot.com/441 + 10740248-7665-4be7-b0eb-77260e081107 + Tue, 24 Sep 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 39:44 + no + + 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) + + + 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
+Noel Rappin on X
+Programming Ruby

+How Not to Use Static Typing in Ruby

+David Copeland Talk

+Better Know a Ruby Thing

+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
+Standardrb
+Rails Test Prescriptions
+Programming Ruby: A Pragmatic Programmer’s Guide

+The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + + 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
+Noel Rappin on X
+Programming Ruby

+How Not to Use Static Typing in Ruby

+David Copeland Talk

+Better Know a Ruby Thing

+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
+Standardrb
+Rails Test Prescriptions
+Programming Ruby: A Pragmatic Programmer’s Guide

+The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ZzUXwC6j + + ]]> + + Joël Quenneville + Stephanie Minn + + + 440: When we stray from Rails defaults + https://bikeshed.thoughtbot.com/440 + 6e0b68fd-4f16-4abc-b75b-a0e7bf4fc1bf + Tue, 17 Sep 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 42:56 + no + + 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) + + + 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'
+Connascence of Name (CoN)
+ActiveModel docs
+GitHub | activemodel
+'Vanilla Rails is plenty'
+GitHub | minitest
+GitHub | test-unit
+Episode 435: Cohesive Code with Jared Norman
+Ruby on Rails
The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + + 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'
+Connascence of Name (CoN)
+ActiveModel docs
+GitHub | activemodel
+'Vanilla Rails is plenty'
+GitHub | minitest
+GitHub | test-unit
+Episode 435: Cohesive Code with Jared Norman
+Ruby on Rails
The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ucTK9V9j + + ]]> + + Joël Quenneville + Stephanie Minn + + + 439: Async Ruby & Rails with Trevor Turk + https://bikeshed.thoughtbot.com/439 + 93fc8aa0-4449-44bd-b17b-bf7e14954932 + Tue, 10 Sep 2024 15:00:00 -0400 + thoughtbot + + full + thoughtbot + + 34:11 + no + + 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) + + + 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
+Trevor Turk on X
+Trevor Turk on Threads
+Hello Weather
+Weather Machine
+GitHub | async gem
+GitHub | falcon gem
+'Async Ruby on Rails'
+load_async
+Episode 437: Contributing to Open Source in the Midst of Daily Work with Steve Polito
+GitHub | Action Cable server adapter
+ActiveRecord connection checkout caching
+Ruby on Rails
The Bike Shed
+The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + + 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
+Trevor Turk on X
+Trevor Turk on Threads
+Hello Weather
+Weather Machine
+GitHub | async gem
+GitHub | falcon gem
+'Async Ruby on Rails'
+load_async
+Episode 437: Contributing to Open Source in the Midst of Daily Work with Steve Polito
+GitHub | Action Cable server adapter
+ActiveRecord connection checkout caching
+Ruby on Rails
The Bike Shed
+The Bike Shed
+Joël Quenneville on LinkedIn
+Support The Bike Shed

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+XhvjL9xz + + ]]> + + Joël Quenneville + Stephanie Minn + + + 438: Writing abstractions in tests + https://bikeshed.thoughtbot.com/438 + 1ea2ba87-5f98-4689-a07f-6ab3b8bf9ed9 + Tue, 03 Sep 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 49:08 + no + + 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/) + + + 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:

+ +

Support The Bike Shed

]]> + + + 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:

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ZDe1bmju + + ]]> + + Joël Quenneville + Stephanie Minn + + + 437: Contributing to Open Source in the Midst of Daily Work with Steve Polito + https://bikeshed.thoughtbot.com/437 + a370aaa7-9f44-4a25-88d3-8c9467a620e8 + Tue, 27 Aug 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 35:28 + no + + 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/) + + + 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:

+ +

Support The Bike Shed

]]> + + + 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:

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+YznL-Gq2 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 436: Creating Conditions For Your Best Work with Steph Viccari + https://bikeshed.thoughtbot.com/436 + 69ffc4d2-44a0-4155-8736-30507cede73d + Tue, 13 Aug 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 43:09 + no + + 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 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:

+ +

Support The Bike Shed

]]> + + + 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:

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+xaoMcIxl + + ]]> + + Joël Quenneville + Stephanie Minn + + + 435: Cohesive Code with Jared Norman + https://bikeshed.thoughtbot.com/435 + 1fd3caa8-e30c-4bf9-9789-bd731f580459 + Tue, 30 Jul 2024 15:00:00 -0400 + thoughtbot + + full + thoughtbot + + 28:45 + no + + 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/) + + + 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:

+ +

Support The Bike Shed

]]> + + + 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:

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+RlGs0Ch2 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 434: Git and GitHub Workflows + https://bikeshed.thoughtbot.com/434 + a47e508d-5f80-4cc8-8552-4d5b3aaebd90 + Tue, 23 Jul 2024 15:00:00 -0400 + thoughtbot + + full + thoughtbot + + 47:42 + no + + 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 + + + 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

Support The Bike Shed

]]> + + + 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

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Rwj3Jw-H + + ]]> + + Joël Quenneville + Stephanie Minn + + + 433: Riffing with Kasper Timm Hansen + https://bikeshed.thoughtbot.com/433 + 80f4222b-deb4-401f-86cd-9f52319ab75b + Tue, 16 Jul 2024 03:00:00 -0400 + thoughtbot + + full + thoughtbot + + 37:20 + no + + 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) + + + 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:

+ + + +

Some of Kasper's open source work:

+ +

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:

+ + + +

Some of Kasper's open source work:

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ryfRrtnV + + ]]> + + Joël Quenneville + Stephanie Minn + + + 432: The Semantics and Meaning of Nil + https://bikeshed.thoughtbot.com/432 + e718f2fb-19a3-493b-986a-2df01bcab768 + Tue, 09 Jul 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + 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. + 38:13 + no + + 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/) + + + 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

+ +

Support The Bike Shed

]]> + + + 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

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+zDT5_xJr + + ]]> + + Joël Quenneville + Stephanie Minn + + + 431: Developers Are Professional Question Askers + https://bikeshed.thoughtbot.com/431 + d03b4bc7-3644-4852-af59-d77c079e6df1 + Tue, 02 Jul 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + 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. + 38:54 + no + + + 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, like, I do be asking questions [laughs] when I join a project on a client team. And I was trying to separate, like, what kinds of questions I ask. And I kind of came away with a few different categories depending on, like, the stage of the engagement I'm in. +But, you know, when I first join a team and when I'm first starting out consulting for a team, I feel like I just ask a lot of basic questions. Like, "Where's the Jira board [laughs]?" Like, "How do you do deployments here?" Like, "What kind of Git process do you use?" So, I don't know if those are necessarily the interesting ones. But I think one thing that has been nice is being a consultant has kind of stripped the fear of asking those questions because, I don't know, these are just things I need to know to do my work. And, like, I'm not as worried about, like, looking dumb or anything like that [laughs]. +JOËL: Yeah. I think there's often a fear that asking questions might make you look incompetent or maybe will sort of undermine your appearance of knowing what you're talking about, and I think I've found that to be sort of the opposite. Asking a lot of questions can build more trust, both because it forces people to think about things that maybe they didn't think about, bring to light sort of implicit assumptions that everyone has, and also because it helps you to ramp up much more quickly and to be productive in a way that people really appreciate. +STEPHANIE: Yeah. And I also think that putting those things in, like, a public and, like, documented space helps people in the future too, right? At least I am a power Slack searcher [laughs]. And whenever I am onboarding somewhere, one of the first places I go is just to search in Slack and see if someone has asked this question before. +I think the next kind of category of question that I discerned was just, like, questions to understand how the team understands things. So, it's purely just to, like, absorb kind of like perspective or, like, a worldview this team has about their codebase, or their work, or whatever. So, I think those questions manifest as just like, "Oh, like, you know, I am curious, like, what do you think about how healthy your codebase is? Or what kinds of bugs is your team, like, dealing with?" +Just trying to get a better understanding of like, what are the challenges that this team is facing in their own words, especially before I even start to form my own opinions. Well, okay, to be honest, I probably am forming my own opinions, like, on the side [laughs], but I really try hard to not let that be the driver of how I'm showing up and especially in the first month I'm starting on a new team. +JOËL: Would you say these sorts of questions are more around sort of social organization or, like, how a team approaches work, that sort of thing? Or do you classify more technical questions in this category? So, like, "Hey, tell me a little bit about your philosophy around testing." Or we talked in a recent episode "What value do you feel you get out of testing?" as a question to ask before even, like, digging into the implementation. +STEPHANIE: Yeah, I think these questions, for me, sit at, like, the intersection of both social organization and technical questions because, you know, asking something like, "What's the value of testing for your team?" That will probably give me information about how their test suite is like, right? Like, what kinds of tests they are writing and kind of the quality of them maybe. And it also tells me about, yeah, like, maybe the reasons why, like, they only have just unit tests or maybe, like, just [inaudible 12:31] test, or whatever. And I think all of that is helpful information. +And then, that's actually a really...I like the distinction you made because I feel like then the last category of questions that I'll mention, for now, feels like more geared towards technical, especially the questions I ask to debunk assumptions that might be held by the team. And I feel like that's like kind of the last...the evolution of my question-asking. Because I have, hopefully, like, really absorbed, like, why, you know, people think the way they do about some of these, you know, about their code and start to poke a little bit on being like, "Why do you think, you know, like, this problem space has to be modeled this way?" +And that has served me well as a consultant because, you know, once you've been at an organization for a while, like, you start to take a lot of things for granted about just having to always be this way, you know, it's like, things just are the way they are. And part of the power of, you know, being this kind of, like, external observer is starting to kind of just like, yeah, be able to question that. And, you know, at the end of day, like, we choose not to change something, but I think it's very powerful to be able to at least, like, open up that conversation. +JOËL: Right. And sometimes you open up that conversation, and what you get is a link to a big PR discussion or a Wiki or something where that discussion has already been had. And then, that's good for you and probably good for anybody else who has that question as well. +STEPHANIE: I'm curious, for you, though, like, this thesis statement, atomic note, did you have notes around it, or was it just, like, you dropped it in there [laughs]? +JOËL: So, I have a few things, one is that when you come in as a consultant, and, you know, we're talking here about consultants because that's what we do. I think this is probably true for most people onboarding, especially for non-junior roles where you're coming in, and there's an assumption of expertise, but you need to onboard onto a project. This is just particularly relevant for us as consultants because we do this every six months instead of, you know, a senior developer who's doing this maybe every two to three years. +So, the note that I have here is that when you're brought on, clients they expect expertise in a technology, something like Ruby on Rails or, you know, just the web environment in general. They don't expect you as a consultant to be an expert in their domain or their practices. And so, when you really engage with this sort of areas that are new by asking a lot of questions, that's the thing that's really valuable, especially if those questions are coming from a place of experience in other similar things. So, maybe asking some questions around testing strategies because you've seen three or four other ways that work or don't work or that have different trade-offs. +Even asking about, "Hey, I see we went down a particular path, technically. Can you walk me through what were the trade-offs that we evaluated and why we decided this was the path that was valuable for us?" That's something that people really appreciate from outside experts. Because it shows that you've got experience in those trade-offs, that you've thought the deeper thoughts beyond just shipping the next ticket. And sometimes they've made the decisions without actually thinking through the trade-offs. And so, that can be an opening for a conversation of like, "Hey, well, we just went down this path because we saw a blog article that recommended this, or we just did this because it felt right. Talk us through the trade-offs." +And now maybe you have a conversation on, "Hey, here are the trade-offs that you're doing. Let me know if this sounds right for your organization. If not, maybe you want to consider changing some things or tweaking your approach." And I think that is valuable sort of at the big level where you're thinking about how the team is structured, how different parts of work is done, the technical architecture, but it also is valuable at the small level as well. +STEPHANIE: Yeah, 100%. There is a blog post I really like by Hazel Weakly, and it's called "The Power of Being New: A Proven Recipe for High Impact." And one thing that she says at the beginning that I really enjoy is that even though, like, whenever you start on a new team there's always that little bit of pressure of starting to deliver immediate value, right? But there's something really special about that period where no one expects you to do anything, like, super useful immediately [laughs]. And I feel like it is both a fleeting time and, you know, I'm excited to continue this conversation of, like, how to keep integrating that even after you're no longer new. +But I like to use that time to just identify, while I have nothing really on my plate, like, things that might have just been overlooked or just people have gotten used to that sometimes is, honestly, like, can be a quick fix, right? Like, just, I don't know, deleting a piece of dead code that you're seeing is no longer used but just gets fallen off other people's plates. I really enjoy those first few weeks, and people are almost, like, always so appreciative, right? They're like, "Oh my gosh, I have been meaning to do that." Or like, "Great find." And these are things that, like I said, just get overlooked when you are, yeah, kind of busy with other things that now are your responsibility. +JOËL: You're talking about, like, that feeling of can you add value in the, like, initial time that you join. And I think that sometimes it can be easy to think that, oh, the only value you can add is by, like, shipping code. I think that being sort of noisy and asking a lot of questions in Slack is often a great way to add value, especially at first. +STEPHANIE: Yeah, agreed. +JOËL: Ideally, I think you come in, and you don't sort of slide in under the radar as, like, a new person on the team. Like, you come in, and everybody knows you're there because you are, like, spamming the channel with questions on all sorts of things and getting people to either link you to resources they have or explaining different topics, especially anything domain-related. You know, you're coming in with an outside expertise in a technology. You are a complete new person at the business and the problem domain. And so, that's an area where you need to ask a lot of questions and ramp up quickly. +STEPHANIE: Yes. I have a kind of side topic. I guess it's not a side topic. It's about asking questions, so it's relevant [laughs]. But one thing that I'm curious about is how do you approach kind of doing this in a place where question asking is not normalized and maybe other people are less comfortable with kind of people asking questions openly and in public? Like, how do you set yourself up to be able to ask questions in a way that doesn't lead to just, like, some just, like, suspicion or discomfort about, like, why you're asking those questions? +JOËL: I think that's the beauty of the consultant title. When an organization brings in outside experts, they kind of expect you to ask questions. Or maybe it's not an explicit expectation, but when they see you asking a lot of questions, it sort of, I think, validates a lot of things that they expect about what an outside expert should be. So, asking a lot of questions of trying to understand your business, asking a lot of questions to try to understand the technical architecture, asking questions around, like, some subtle edge cases or trade-offs that were made in the technical architecture. +These are all things that help clients feel like they're getting value for the money from an outside expert because that's what you want an outside expert to do is to help you question some of your assumptions, to be able to leverage their, like, general expertise in a technology by applying it to your specific situation. +I've had situations where I'll ask, like, a very nuanced, deep technical question about, like, "Hey, so there's, like, this one weird edge case that I think could potentially happen. How do we, like, think through about this?" And one of the, like, more senior people on the team who built the initial codebase responded, like, almost, like, proud that I've discovered this, like, weird edge case, and being like, "Oh yeah, that was a thing that we did think about, and here's why. And it's really cool that, like, day one you're, like, just while reading through the code and were like, 'Oh, this thing,' because it took us, like, a month of thinking about it before we stumbled across that." +So, it was a weird kind of fun interaction where as a new person rolling on, one of the more experienced devs in the codebase almost felt, like, proud of me for having found that. +STEPHANIE: I like that, yeah. I feel like a lot of the time...it's like, it's so easy to ask questions to help people feel seen, to be like, "Oh yeah, like, I noticed this." And, you know, if you withhold any kind of, like, judgment about it when you ask the question, people are so willing to be like, yeah, like you said, like, "Oh, I'm glad you saw that." Or like, "Isn't that weird? Like, I was feeling, you know, I saw that, too." Or, like, it opens it up, I think, for building trust, which, again, like, I don't even think this is something that you necessarily need to be new to even do. But if at any point you feel like, you know, maybe your working relationship with someone could be better, right? To the point where you feel like you're, like, really on the same page, yeah, ask questions [laughs]. It can be that easy. +JOËL: And I think what can be really nice is, in an environment where question asking is not normalized, coming in and doing that can help sort of provide a little bit of cover to other people who are feeling less comfortable or less safe doing that. So, maybe there's a lot of junior members on the team who are feeling not super confident in themselves and are afraid that asking questions might undermine their position in the company. But me coming in as a sort of senior consultant and asking a lot of those questions can then help normalize that as a thing because then they can look and say, "Oh, well he's asking all these questions. Maybe I can ask my question, and it'll be okay." +STEPHANIE: I also wanted to talk about setting yourself up and asking questions to get a good answer, asking good questions to get useful answers. One thing that has worked really well for me in the past few months has been sharing why I'm asking the question. And I think this goes back to a little bit of what I was hinting at earlier. If the culture is not really used to people asking questions and that just being a thing that is normal, sharing a bit of intention can help, like, ease maybe some nervousness that people might feel. Especially as consultants, we also are in a bit of a, I don't know, like, there is some power dynamics occasionally where it's like, oh, like, the consultants are here. Like, what are they going to come in and change or, like, start, you know, doing to, quote, unquote, "improve", whatever, I don't know [laughs]. +JOËL: Right, right. +STEPHANIE: Yeah, that's the consultant archetype, I think. Anyway. +JOËL: Just coming in and being like, "Oh, this is bad, and this is bad, and you're doing it wrong." +STEPHANIE: [laughs] +JOËL: Ooh, I would be ashamed if I was the author of this code. +STEPHANIE: Yeah, my hot take is that that is a bad consultant [laughs]. But maybe I'll say, like, "I am looking for some examples of this pattern. Where can I find them [laughs]?" Or "I've noticed that the team is struggling with, like, this particular part of the codebase, and I am thinking about improving it. What are some of your biggest challenges, like, working with this, like, model?" something like that. +And I think this also goes back to, like, proving value, right? Even if it's like, sometimes I know kind of what I want to do, and I'll try to be explicit about that. But even before I have, like, a clear action item, I might just say like, "I'm thinking about this," you know, to convey that, you know, I'm still in that information gathering stage, but the result of that will be useful to help me with whatever kind of comes out of it. +JOËL: A lot of it is about, like, genuine curiosity and an amount of empathetic listening. Existing team knows a lot about both the code and the business. And as a consultant coming on or maybe even a more senior person onboarding onto a team, the existing team has so much that they can give you to help you be better at your job. +STEPHANIE: I was also revisiting a really great blog post from Julia Evans about "How to Ask Good Questions." And this one is more geared towards asking technical questions that have, like, kind of a maybe more straightforward answer. But she included a few other strategies that I liked a lot. And, frankly, I feel like I want to be even better at finding the right time to ask questions [laughs] and finding the right person to ask those questions to. +I definitely get in the habit of just kind of like, I don't know, I'll just put it out there and [laughs], hopefully, get some answers. But there are definitely ways, I think, that you can be more strategic, right? About identifying who might be the best person to provide the answers you're looking for. And I think another thing that I often have to balance in the consulting position is when to know when to, like, stop kind of asking the really big questions because we just don't have time [laughs]. +JOËL: Right. You don't want to be asking questions in a way that's sort of undermining the product, or the decisions that are being made, or the work that has to get done. Ideally, the questions that you're asking are helping move the project forward in a positive way. Nobody likes the, you know, just asking kind of person. That person's annoying. +STEPHANIE: Do you have an approach or any thoughts about like, once you get an answer, like, what do you do with that? Yeah, what happens then for you? +JOËL: I guess there's a lot of different ways it can go. A potential way if it's just, like, an answer explained in Slack, is maybe saying, "We should document this." Or maybe even like, "Is this documented anywhere? If not, can I add that documentation somewhere?" And maybe that's, you know, a code comment that we want to add. Maybe that's an entry to the Wiki. Maybe that's updating the README. Maybe that's adding a test case. But converting that into something actionable can often be a really good follow-up. +STEPHANIE: Yeah, I think that mitigates the just asking [laughs] thing that you were saying earlier, where it's like, you know, the goal isn't to ask questions to then make more work for other people, right? It's to ask questions so, hopefully, you're able to take that information and do something valuable with it. +JOËL: Right. Sometimes it can be a sort of setup for follow-up questions. You get some information and you're like, okay, so, it looks like we do have a pattern for interacting with third-party APIs, but we're not using it consistently. Tell me a little bit about why that is. Is that a new pattern that we've introduced and we're trying to, like, get more buy-in from the team? Is this a pattern that we used to have, and we found out we didn't like it? So, we stopped using it, but we haven't found a replacement pattern that we like. And so, now we're just kind of...it's a free-for-all, and we're trying to figure it out. +Maybe there's two competing patterns, and there is this, like, weird politics within the tech team where they're sort of using one or the other, and that's something I'm going to have to be careful to navigate. So, asking some of those follow-up questions and once you have a technical answer can yield a lot of really interesting information and then help you think about how you can be impactful on the organization. +STEPHANIE: And that sounds like advice that's just true, you know, regardless of your role or how long you've been in it, don't you think? +JOËL: I would say yes. If you've been in the role a long time, though, you're the person who has that sort of institutional history in your mind. You know that in 2022, we switched over from one framework to another. You know that we used to have this, like, very opinionated architect who mandated a particular pattern, and then we moved away from it. You know that we were all in on this big feature last summer that we released and then nobody used it, and then the business pivoted, but there's still aspects of it that are left around. Those are things that someone knew onboarding doesn't know and that, hopefully, they're asking questions that you can then answer. +STEPHANIE: Have you been in the position where you have all that, like, institutional knowledge? And then, like, how do you maintain that sense of curiosity or just that sense of kind of, like, what you're talking about, that superpower that you get when you're new of being able to just, you know, kind of question why things are the way they are? +JOËL: It's hard, right? We're talking about how do you keep that sort of almost like a beginner's mindset, in this case, maybe less of a, like, new coder mindset and more of a new hire mindset. It's something that I think is much more front of mind for me because I rotate onto new clients every, like, 6 to 12 months. And so, I don't have very long to get comfortable before I'm immediately thrown into, like, a new situation. +But something that I like to do is to never sort of solely be in one role or the other, a sort of, like, experienced person helping others or the new person asking for help. Likely, you are not going to be the newest person on the team for long. Maybe you came on as a cohort and you've got a group of new people, all of whom are asking different questions. And maybe somebody is asking a question that you've asked before, that you've asked in a different channel or on a call with someone. Or maybe someone joins two weeks after you; you don't have deep institutional knowledge. +But if you've been asking a lot of questions, you've been building a lot of that for yourself, and you have a little bit that you can share to the next person who knows even less than you do. And that's an approach that I took even as an apprentice developer. When I was, like, brand new to Rails and I was doing an internship, and another intern joined me a couple of weeks after, and I was like, "You know what? I barely know anything. But I know what an instance variable is. And I can help you write a controller action. Let's pair on that. We'll figure it out. And, you know, ask me another question next week. I might have more answers for you." So, I guess a little bit of paying it forward. +STEPHANIE: Yeah, I really like that advice, though, of, like, switching up the role or, like, kind of what you're working on, just finding opportunities to practice that, you know, even if you have been somewhere for a long time. I think that is really interesting advice. And it's hard, too, right? Because that requires, like, doing something new, and doing something new can be hard [laughs]. But if you're, you know, aren't in a consultant role, where you're not rotating onto new projects every 6 to 12 months, that, I feel like, would be a good strategy to grow in that particular way. +JOËL: And even if you're not switching companies or in a consulting situation, it's not uncommon to have people switch from one team to another within an organization. And new team might mean new dynamics. That team might be doing a slightly different approach to project management. Their part of the code might be structured slightly differently. They might be dealing with a part of the business domain that you're less familiar with. While that might not be entirely new to you because, you know, you know a little bit of the organization's DNA and you understand the organization's mission and their core product, there are definitely a lot of things that will be new to you, and asking those questions becomes important. +STEPHANIE: I also have another kind of, I don't know, it's not even a strategy. It's just a funny thing that I do where, like, my memory is so poor that, like, even code I wrote, you know, a month ago, I'm like, oh, what was past Stephanie thinking here [laughs]? You know, questioning myself a little bit, right? And being willing to do that and recognizing that, like, I have information now that I didn't have in the past. And, like, can that be useful somehow? +You know, it's like, the code I wrote a month ago is not set in stone. And I think that's one way I almost, like, practice that skill with myself [laughs]. And yeah, it has helped me combat that, like, things are the way they are mentality, which, generally, I think is a very big blocker [laughs] when it comes to software development, but that's a topic for another day [laughs]. +JOËL: I like the idea of questioning yourself, and I think that's something that is a really valuable skill for all developers. I think it can come up in things like documentation. Let's say you're leaving a comment on a method, especially one that's a bit weird, being able to answer that "Why was this weird technical decision made?" Or maybe you do this in your PR description, or your commit message, or in any of the other places where you do this, not just sort of shipping the code as is, but trying to look at it from an outsider's eyes. +And being like, what are the areas where they're going to, like, get a quizzical look and be like, "Why is this happening? Why did you make this choice?" Bonus points if you talked a little bit about the trade-offs that were decided on to say, "Hey, there were two different implementations available for this. I chose to take implementation A because I like this set of trade-offs better." That's gold. And, I guess, as a reviewer, if I'm seeing that in a PR, that's going to make my job a lot easier. +STEPHANIE: Yes. Yeah, I never thought about it that way, but yeah, I guess I do kind of apply, you know, the things that I would kind of ask to other team members to myself sometimes. And that is...it's cool to hear that you really appreciate that because I always kind of just did it for myself [laughs], but yeah, I'm sure that it, like, is helpful for other people as well. +JOËL: I guess you were asking what are ways that you can ask questions even when you are more established. And talking about these sorts of self-reflective questions in the context of review got me thinking that PRs are a great place to ask questions. They're great when you're a newcomer. One of the things I like to do when I'm new on a project is do a lot of PR reviews so I can just see the weird things that people are working on and ask a lot of questions about the patterns. +STEPHANIE: Yep. Same here. +JOËL: Do a lot of code reading. But that's a thing that you can keep doing and asking a lot of questions on PRs and not in a, like, trying to undermine what the person is doing, but, like, genuine questions, I think, is a great way to maintain that mindset. +STEPHANIE: Yeah, yeah, agreed. And I think when I've seen it done well, it's like, you get to be engaged and involved with the rest of your team, right? And you kind of have a bit of an idea about what people are working on. But you're also kind of entrusting them with ownership of that work. Like, you don't need to be totally in the weeds and know exactly how every method works. But, you know, you can be curious about like, "Oh, like, what were you thinking about this?" Or like, "What about this pattern appeals to you?" And all of that information, I think, helps you become a better, like, especially a senior developer, but also just, like, a leader on the team, I think. +JOËL: Yeah, especially the questions around like, "Oh, walk me through some of the trade-offs that you chose for this method." And, you know, for maybe a person who's more senior, that's great. They have an opportunity to, like, talk about the decisions they made and why. That's really useful information. For a more junior person, maybe they've never thought about it. They're like, "Oh, wait, there are trade-offs here?" and now that's a great learning opportunity for them. +And you don't want to come at it from a place of judgment of like, oh, well, clearly, you know, you're a terrible developer because you didn't think about the performance implications of this method. But if you come at it from a place of, like, genuine curiosity and sort of assuming the best of people on the team and being willing to work alongside them, help them discover some new concepts...maybe they've never, like, interacted so much with performance trade-offs, and now you get to have a conversation. And they've learned a thing, and everybody wins. +STEPHANIE: Yeah. And also, I think seeing people ask questions that way helps more junior folks also learn when to ask those kinds of questions, even if they don't know the answer, right? But maybe they start kind of pattern matching. Like, oh, like, there might be some other trade-offs to consider with this kind of code, but I don't know what they are yet. But now I know to at least start asking and find someone who can help me determine that. And when I've seen that, that has been always, like, just so cool because it's upskilling happening [laughs] in practice. +JOËL: Exactly. I love that phrase that you said: "Asking questions where you don't know the answers," which I think is the opposite of what lawyers are taught to do. I think lawyers the mantra they have is you never ask a witness a question that you don't know the answer to. But I like to flip that for developers. Ask a lot of questions on PRs where you don't know the answer, and you'll grow, and the author will grow. And this is true across experience levels. +STEPHANIE: That's one of my favorite parts about being a developer, and maybe that's why I will never be a lawyer [laughter]. +JOËL: On that note, I have a question maybe I do know the answer to. Shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + software development, AI in software, naming conventions, Classnames resource, AI-generated names, D&D character names, Roman history, state vs non-state peoples, asking questions as consultants, onboarding experience, building trust, questioning assumptions, PR reviews, junior developers, collaborative environment, continuous improvement, effective decision-making + + 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.

+ + + +

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, like, I do be asking questions [laughs] when I join a project on a client team. And I was trying to separate, like, what kinds of questions I ask. And I kind of came away with a few different categories depending on, like, the stage of the engagement I'm in.

+ +

But, you know, when I first join a team and when I'm first starting out consulting for a team, I feel like I just ask a lot of basic questions. Like, "Where's the Jira board [laughs]?" Like, "How do you do deployments here?" Like, "What kind of Git process do you use?" So, I don't know if those are necessarily the interesting ones. But I think one thing that has been nice is being a consultant has kind of stripped the fear of asking those questions because, I don't know, these are just things I need to know to do my work. And, like, I'm not as worried about, like, looking dumb or anything like that [laughs].

+ +

JOËL: Yeah. I think there's often a fear that asking questions might make you look incompetent or maybe will sort of undermine your appearance of knowing what you're talking about, and I think I've found that to be sort of the opposite. Asking a lot of questions can build more trust, both because it forces people to think about things that maybe they didn't think about, bring to light sort of implicit assumptions that everyone has, and also because it helps you to ramp up much more quickly and to be productive in a way that people really appreciate.

+ +

STEPHANIE: Yeah. And I also think that putting those things in, like, a public and, like, documented space helps people in the future too, right? At least I am a power Slack searcher [laughs]. And whenever I am onboarding somewhere, one of the first places I go is just to search in Slack and see if someone has asked this question before.

+ +

I think the next kind of category of question that I discerned was just, like, questions to understand how the team understands things. So, it's purely just to, like, absorb kind of like perspective or, like, a worldview this team has about their codebase, or their work, or whatever. So, I think those questions manifest as just like, "Oh, like, you know, I am curious, like, what do you think about how healthy your codebase is? Or what kinds of bugs is your team, like, dealing with?"

+ +

Just trying to get a better understanding of like, what are the challenges that this team is facing in their own words, especially before I even start to form my own opinions. Well, okay, to be honest, I probably am forming my own opinions, like, on the side [laughs], but I really try hard to not let that be the driver of how I'm showing up and especially in the first month I'm starting on a new team.

+ +

JOËL: Would you say these sorts of questions are more around sort of social organization or, like, how a team approaches work, that sort of thing? Or do you classify more technical questions in this category? So, like, "Hey, tell me a little bit about your philosophy around testing." Or we talked in a recent episode "What value do you feel you get out of testing?" as a question to ask before even, like, digging into the implementation.

+ +

STEPHANIE: Yeah, I think these questions, for me, sit at, like, the intersection of both social organization and technical questions because, you know, asking something like, "What's the value of testing for your team?" That will probably give me information about how their test suite is like, right? Like, what kinds of tests they are writing and kind of the quality of them maybe. And it also tells me about, yeah, like, maybe the reasons why, like, they only have just unit tests or maybe, like, just [inaudible 12:31] test, or whatever. And I think all of that is helpful information.

+ +

And then, that's actually a really...I like the distinction you made because I feel like then the last category of questions that I'll mention, for now, feels like more geared towards technical, especially the questions I ask to debunk assumptions that might be held by the team. And I feel like that's like kind of the last...the evolution of my question-asking. Because I have, hopefully, like, really absorbed, like, why, you know, people think the way they do about some of these, you know, about their code and start to poke a little bit on being like, "Why do you think, you know, like, this problem space has to be modeled this way?"

+ +

And that has served me well as a consultant because, you know, once you've been at an organization for a while, like, you start to take a lot of things for granted about just having to always be this way, you know, it's like, things just are the way they are. And part of the power of, you know, being this kind of, like, external observer is starting to kind of just like, yeah, be able to question that. And, you know, at the end of day, like, we choose not to change something, but I think it's very powerful to be able to at least, like, open up that conversation.

+ +

JOËL: Right. And sometimes you open up that conversation, and what you get is a link to a big PR discussion or a Wiki or something where that discussion has already been had. And then, that's good for you and probably good for anybody else who has that question as well.

+ +

STEPHANIE: I'm curious, for you, though, like, this thesis statement, atomic note, did you have notes around it, or was it just, like, you dropped it in there [laughs]?

+ +

JOËL: So, I have a few things, one is that when you come in as a consultant, and, you know, we're talking here about consultants because that's what we do. I think this is probably true for most people onboarding, especially for non-junior roles where you're coming in, and there's an assumption of expertise, but you need to onboard onto a project. This is just particularly relevant for us as consultants because we do this every six months instead of, you know, a senior developer who's doing this maybe every two to three years.

+ +

So, the note that I have here is that when you're brought on, clients they expect expertise in a technology, something like Ruby on Rails or, you know, just the web environment in general. They don't expect you as a consultant to be an expert in their domain or their practices. And so, when you really engage with this sort of areas that are new by asking a lot of questions, that's the thing that's really valuable, especially if those questions are coming from a place of experience in other similar things. So, maybe asking some questions around testing strategies because you've seen three or four other ways that work or don't work or that have different trade-offs.

+ +

Even asking about, "Hey, I see we went down a particular path, technically. Can you walk me through what were the trade-offs that we evaluated and why we decided this was the path that was valuable for us?" That's something that people really appreciate from outside experts. Because it shows that you've got experience in those trade-offs, that you've thought the deeper thoughts beyond just shipping the next ticket. And sometimes they've made the decisions without actually thinking through the trade-offs. And so, that can be an opening for a conversation of like, "Hey, well, we just went down this path because we saw a blog article that recommended this, or we just did this because it felt right. Talk us through the trade-offs."

+ +

And now maybe you have a conversation on, "Hey, here are the trade-offs that you're doing. Let me know if this sounds right for your organization. If not, maybe you want to consider changing some things or tweaking your approach." And I think that is valuable sort of at the big level where you're thinking about how the team is structured, how different parts of work is done, the technical architecture, but it also is valuable at the small level as well.

+ +

STEPHANIE: Yeah, 100%. There is a blog post I really like by Hazel Weakly, and it's called "The Power of Being New: A Proven Recipe for High Impact." And one thing that she says at the beginning that I really enjoy is that even though, like, whenever you start on a new team there's always that little bit of pressure of starting to deliver immediate value, right? But there's something really special about that period where no one expects you to do anything, like, super useful immediately [laughs]. And I feel like it is both a fleeting time and, you know, I'm excited to continue this conversation of, like, how to keep integrating that even after you're no longer new.

+ +

But I like to use that time to just identify, while I have nothing really on my plate, like, things that might have just been overlooked or just people have gotten used to that sometimes is, honestly, like, can be a quick fix, right? Like, just, I don't know, deleting a piece of dead code that you're seeing is no longer used but just gets fallen off other people's plates. I really enjoy those first few weeks, and people are almost, like, always so appreciative, right? They're like, "Oh my gosh, I have been meaning to do that." Or like, "Great find." And these are things that, like I said, just get overlooked when you are, yeah, kind of busy with other things that now are your responsibility.

+ +

JOËL: You're talking about, like, that feeling of can you add value in the, like, initial time that you join. And I think that sometimes it can be easy to think that, oh, the only value you can add is by, like, shipping code. I think that being sort of noisy and asking a lot of questions in Slack is often a great way to add value, especially at first.

+ +

STEPHANIE: Yeah, agreed.

+ +

JOËL: Ideally, I think you come in, and you don't sort of slide in under the radar as, like, a new person on the team. Like, you come in, and everybody knows you're there because you are, like, spamming the channel with questions on all sorts of things and getting people to either link you to resources they have or explaining different topics, especially anything domain-related. You know, you're coming in with an outside expertise in a technology. You are a complete new person at the business and the problem domain. And so, that's an area where you need to ask a lot of questions and ramp up quickly.

+ +

STEPHANIE: Yes. I have a kind of side topic. I guess it's not a side topic. It's about asking questions, so it's relevant [laughs]. But one thing that I'm curious about is how do you approach kind of doing this in a place where question asking is not normalized and maybe other people are less comfortable with kind of people asking questions openly and in public? Like, how do you set yourself up to be able to ask questions in a way that doesn't lead to just, like, some just, like, suspicion or discomfort about, like, why you're asking those questions?

+ +

JOËL: I think that's the beauty of the consultant title. When an organization brings in outside experts, they kind of expect you to ask questions. Or maybe it's not an explicit expectation, but when they see you asking a lot of questions, it sort of, I think, validates a lot of things that they expect about what an outside expert should be. So, asking a lot of questions of trying to understand your business, asking a lot of questions to try to understand the technical architecture, asking questions around, like, some subtle edge cases or trade-offs that were made in the technical architecture.

+ +

These are all things that help clients feel like they're getting value for the money from an outside expert because that's what you want an outside expert to do is to help you question some of your assumptions, to be able to leverage their, like, general expertise in a technology by applying it to your specific situation.

+ +

I've had situations where I'll ask, like, a very nuanced, deep technical question about, like, "Hey, so there's, like, this one weird edge case that I think could potentially happen. How do we, like, think through about this?" And one of the, like, more senior people on the team who built the initial codebase responded, like, almost, like, proud that I've discovered this, like, weird edge case, and being like, "Oh yeah, that was a thing that we did think about, and here's why. And it's really cool that, like, day one you're, like, just while reading through the code and were like, 'Oh, this thing,' because it took us, like, a month of thinking about it before we stumbled across that."

+ +

So, it was a weird kind of fun interaction where as a new person rolling on, one of the more experienced devs in the codebase almost felt, like, proud of me for having found that.

+ +

STEPHANIE: I like that, yeah. I feel like a lot of the time...it's like, it's so easy to ask questions to help people feel seen, to be like, "Oh yeah, like, I noticed this." And, you know, if you withhold any kind of, like, judgment about it when you ask the question, people are so willing to be like, yeah, like you said, like, "Oh, I'm glad you saw that." Or like, "Isn't that weird? Like, I was feeling, you know, I saw that, too." Or, like, it opens it up, I think, for building trust, which, again, like, I don't even think this is something that you necessarily need to be new to even do. But if at any point you feel like, you know, maybe your working relationship with someone could be better, right? To the point where you feel like you're, like, really on the same page, yeah, ask questions [laughs]. It can be that easy.

+ +

JOËL: And I think what can be really nice is, in an environment where question asking is not normalized, coming in and doing that can help sort of provide a little bit of cover to other people who are feeling less comfortable or less safe doing that. So, maybe there's a lot of junior members on the team who are feeling not super confident in themselves and are afraid that asking questions might undermine their position in the company. But me coming in as a sort of senior consultant and asking a lot of those questions can then help normalize that as a thing because then they can look and say, "Oh, well he's asking all these questions. Maybe I can ask my question, and it'll be okay."

+ +

STEPHANIE: I also wanted to talk about setting yourself up and asking questions to get a good answer, asking good questions to get useful answers. One thing that has worked really well for me in the past few months has been sharing why I'm asking the question. And I think this goes back to a little bit of what I was hinting at earlier. If the culture is not really used to people asking questions and that just being a thing that is normal, sharing a bit of intention can help, like, ease maybe some nervousness that people might feel. Especially as consultants, we also are in a bit of a, I don't know, like, there is some power dynamics occasionally where it's like, oh, like, the consultants are here. Like, what are they going to come in and change or, like, start, you know, doing to, quote, unquote, "improve", whatever, I don't know [laughs].

+ +

JOËL: Right, right.

+ +

STEPHANIE: Yeah, that's the consultant archetype, I think. Anyway.

+ +

JOËL: Just coming in and being like, "Oh, this is bad, and this is bad, and you're doing it wrong."

+ +

STEPHANIE: [laughs]

+ +

JOËL: Ooh, I would be ashamed if I was the author of this code.

+ +

STEPHANIE: Yeah, my hot take is that that is a bad consultant [laughs]. But maybe I'll say, like, "I am looking for some examples of this pattern. Where can I find them [laughs]?" Or "I've noticed that the team is struggling with, like, this particular part of the codebase, and I am thinking about improving it. What are some of your biggest challenges, like, working with this, like, model?" something like that.

+ +

And I think this also goes back to, like, proving value, right? Even if it's like, sometimes I know kind of what I want to do, and I'll try to be explicit about that. But even before I have, like, a clear action item, I might just say like, "I'm thinking about this," you know, to convey that, you know, I'm still in that information gathering stage, but the result of that will be useful to help me with whatever kind of comes out of it.

+ +

JOËL: A lot of it is about, like, genuine curiosity and an amount of empathetic listening. Existing team knows a lot about both the code and the business. And as a consultant coming on or maybe even a more senior person onboarding onto a team, the existing team has so much that they can give you to help you be better at your job.

+ +

STEPHANIE: I was also revisiting a really great blog post from Julia Evans about "How to Ask Good Questions." And this one is more geared towards asking technical questions that have, like, kind of a maybe more straightforward answer. But she included a few other strategies that I liked a lot. And, frankly, I feel like I want to be even better at finding the right time to ask questions [laughs] and finding the right person to ask those questions to.

+ +

I definitely get in the habit of just kind of like, I don't know, I'll just put it out there and [laughs], hopefully, get some answers. But there are definitely ways, I think, that you can be more strategic, right? About identifying who might be the best person to provide the answers you're looking for. And I think another thing that I often have to balance in the consulting position is when to know when to, like, stop kind of asking the really big questions because we just don't have time [laughs].

+ +

JOËL: Right. You don't want to be asking questions in a way that's sort of undermining the product, or the decisions that are being made, or the work that has to get done. Ideally, the questions that you're asking are helping move the project forward in a positive way. Nobody likes the, you know, just asking kind of person. That person's annoying.

+ +

STEPHANIE: Do you have an approach or any thoughts about like, once you get an answer, like, what do you do with that? Yeah, what happens then for you?

+ +

JOËL: I guess there's a lot of different ways it can go. A potential way if it's just, like, an answer explained in Slack, is maybe saying, "We should document this." Or maybe even like, "Is this documented anywhere? If not, can I add that documentation somewhere?" And maybe that's, you know, a code comment that we want to add. Maybe that's an entry to the Wiki. Maybe that's updating the README. Maybe that's adding a test case. But converting that into something actionable can often be a really good follow-up.

+ +

STEPHANIE: Yeah, I think that mitigates the just asking [laughs] thing that you were saying earlier, where it's like, you know, the goal isn't to ask questions to then make more work for other people, right? It's to ask questions so, hopefully, you're able to take that information and do something valuable with it.

+ +

JOËL: Right. Sometimes it can be a sort of setup for follow-up questions. You get some information and you're like, okay, so, it looks like we do have a pattern for interacting with third-party APIs, but we're not using it consistently. Tell me a little bit about why that is. Is that a new pattern that we've introduced and we're trying to, like, get more buy-in from the team? Is this a pattern that we used to have, and we found out we didn't like it? So, we stopped using it, but we haven't found a replacement pattern that we like. And so, now we're just kind of...it's a free-for-all, and we're trying to figure it out.

+ +

Maybe there's two competing patterns, and there is this, like, weird politics within the tech team where they're sort of using one or the other, and that's something I'm going to have to be careful to navigate. So, asking some of those follow-up questions and once you have a technical answer can yield a lot of really interesting information and then help you think about how you can be impactful on the organization.

+ +

STEPHANIE: And that sounds like advice that's just true, you know, regardless of your role or how long you've been in it, don't you think?

+ +

JOËL: I would say yes. If you've been in the role a long time, though, you're the person who has that sort of institutional history in your mind. You know that in 2022, we switched over from one framework to another. You know that we used to have this, like, very opinionated architect who mandated a particular pattern, and then we moved away from it. You know that we were all in on this big feature last summer that we released and then nobody used it, and then the business pivoted, but there's still aspects of it that are left around. Those are things that someone knew onboarding doesn't know and that, hopefully, they're asking questions that you can then answer.

+ +

STEPHANIE: Have you been in the position where you have all that, like, institutional knowledge? And then, like, how do you maintain that sense of curiosity or just that sense of kind of, like, what you're talking about, that superpower that you get when you're new of being able to just, you know, kind of question why things are the way they are?

+ +

JOËL: It's hard, right? We're talking about how do you keep that sort of almost like a beginner's mindset, in this case, maybe less of a, like, new coder mindset and more of a new hire mindset. It's something that I think is much more front of mind for me because I rotate onto new clients every, like, 6 to 12 months. And so, I don't have very long to get comfortable before I'm immediately thrown into, like, a new situation.

+ +

But something that I like to do is to never sort of solely be in one role or the other, a sort of, like, experienced person helping others or the new person asking for help. Likely, you are not going to be the newest person on the team for long. Maybe you came on as a cohort and you've got a group of new people, all of whom are asking different questions. And maybe somebody is asking a question that you've asked before, that you've asked in a different channel or on a call with someone. Or maybe someone joins two weeks after you; you don't have deep institutional knowledge.

+ +

But if you've been asking a lot of questions, you've been building a lot of that for yourself, and you have a little bit that you can share to the next person who knows even less than you do. And that's an approach that I took even as an apprentice developer. When I was, like, brand new to Rails and I was doing an internship, and another intern joined me a couple of weeks after, and I was like, "You know what? I barely know anything. But I know what an instance variable is. And I can help you write a controller action. Let's pair on that. We'll figure it out. And, you know, ask me another question next week. I might have more answers for you." So, I guess a little bit of paying it forward.

+ +

STEPHANIE: Yeah, I really like that advice, though, of, like, switching up the role or, like, kind of what you're working on, just finding opportunities to practice that, you know, even if you have been somewhere for a long time. I think that is really interesting advice. And it's hard, too, right? Because that requires, like, doing something new, and doing something new can be hard [laughs]. But if you're, you know, aren't in a consultant role, where you're not rotating onto new projects every 6 to 12 months, that, I feel like, would be a good strategy to grow in that particular way.

+ +

JOËL: And even if you're not switching companies or in a consulting situation, it's not uncommon to have people switch from one team to another within an organization. And new team might mean new dynamics. That team might be doing a slightly different approach to project management. Their part of the code might be structured slightly differently. They might be dealing with a part of the business domain that you're less familiar with. While that might not be entirely new to you because, you know, you know a little bit of the organization's DNA and you understand the organization's mission and their core product, there are definitely a lot of things that will be new to you, and asking those questions becomes important.

+ +

STEPHANIE: I also have another kind of, I don't know, it's not even a strategy. It's just a funny thing that I do where, like, my memory is so poor that, like, even code I wrote, you know, a month ago, I'm like, oh, what was past Stephanie thinking here [laughs]? You know, questioning myself a little bit, right? And being willing to do that and recognizing that, like, I have information now that I didn't have in the past. And, like, can that be useful somehow?

+ +

You know, it's like, the code I wrote a month ago is not set in stone. And I think that's one way I almost, like, practice that skill with myself [laughs]. And yeah, it has helped me combat that, like, things are the way they are mentality, which, generally, I think is a very big blocker [laughs] when it comes to software development, but that's a topic for another day [laughs].

+ +

JOËL: I like the idea of questioning yourself, and I think that's something that is a really valuable skill for all developers. I think it can come up in things like documentation. Let's say you're leaving a comment on a method, especially one that's a bit weird, being able to answer that "Why was this weird technical decision made?" Or maybe you do this in your PR description, or your commit message, or in any of the other places where you do this, not just sort of shipping the code as is, but trying to look at it from an outsider's eyes.

+ +

And being like, what are the areas where they're going to, like, get a quizzical look and be like, "Why is this happening? Why did you make this choice?" Bonus points if you talked a little bit about the trade-offs that were decided on to say, "Hey, there were two different implementations available for this. I chose to take implementation A because I like this set of trade-offs better." That's gold. And, I guess, as a reviewer, if I'm seeing that in a PR, that's going to make my job a lot easier.

+ +

STEPHANIE: Yes. Yeah, I never thought about it that way, but yeah, I guess I do kind of apply, you know, the things that I would kind of ask to other team members to myself sometimes. And that is...it's cool to hear that you really appreciate that because I always kind of just did it for myself [laughs], but yeah, I'm sure that it, like, is helpful for other people as well.

+ +

JOËL: I guess you were asking what are ways that you can ask questions even when you are more established. And talking about these sorts of self-reflective questions in the context of review got me thinking that PRs are a great place to ask questions. They're great when you're a newcomer. One of the things I like to do when I'm new on a project is do a lot of PR reviews so I can just see the weird things that people are working on and ask a lot of questions about the patterns.

+ +

STEPHANIE: Yep. Same here.

+ +

JOËL: Do a lot of code reading. But that's a thing that you can keep doing and asking a lot of questions on PRs and not in a, like, trying to undermine what the person is doing, but, like, genuine questions, I think, is a great way to maintain that mindset.

+ +

STEPHANIE: Yeah, yeah, agreed. And I think when I've seen it done well, it's like, you get to be engaged and involved with the rest of your team, right? And you kind of have a bit of an idea about what people are working on. But you're also kind of entrusting them with ownership of that work. Like, you don't need to be totally in the weeds and know exactly how every method works. But, you know, you can be curious about like, "Oh, like, what were you thinking about this?" Or like, "What about this pattern appeals to you?" And all of that information, I think, helps you become a better, like, especially a senior developer, but also just, like, a leader on the team, I think.

+ +

JOËL: Yeah, especially the questions around like, "Oh, walk me through some of the trade-offs that you chose for this method." And, you know, for maybe a person who's more senior, that's great. They have an opportunity to, like, talk about the decisions they made and why. That's really useful information. For a more junior person, maybe they've never thought about it. They're like, "Oh, wait, there are trade-offs here?" and now that's a great learning opportunity for them.

+ +

And you don't want to come at it from a place of judgment of like, oh, well, clearly, you know, you're a terrible developer because you didn't think about the performance implications of this method. But if you come at it from a place of, like, genuine curiosity and sort of assuming the best of people on the team and being willing to work alongside them, help them discover some new concepts...maybe they've never, like, interacted so much with performance trade-offs, and now you get to have a conversation. And they've learned a thing, and everybody wins.

+ +

STEPHANIE: Yeah. And also, I think seeing people ask questions that way helps more junior folks also learn when to ask those kinds of questions, even if they don't know the answer, right? But maybe they start kind of pattern matching. Like, oh, like, there might be some other trade-offs to consider with this kind of code, but I don't know what they are yet. But now I know to at least start asking and find someone who can help me determine that. And when I've seen that, that has been always, like, just so cool because it's upskilling happening [laughs] in practice.

+ +

JOËL: Exactly. I love that phrase that you said: "Asking questions where you don't know the answers," which I think is the opposite of what lawyers are taught to do. I think lawyers the mantra they have is you never ask a witness a question that you don't know the answer to. But I like to flip that for developers. Ask a lot of questions on PRs where you don't know the answer, and you'll grow, and the author will grow. And this is true across experience levels.

+ +

STEPHANIE: That's one of my favorite parts about being a developer, and maybe that's why I will never be a lawyer [laughter].

+ +

JOËL: On that note, I have a question maybe I do know the answer to. Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + 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.

+ + + +

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, like, I do be asking questions [laughs] when I join a project on a client team. And I was trying to separate, like, what kinds of questions I ask. And I kind of came away with a few different categories depending on, like, the stage of the engagement I'm in.

+ +

But, you know, when I first join a team and when I'm first starting out consulting for a team, I feel like I just ask a lot of basic questions. Like, "Where's the Jira board [laughs]?" Like, "How do you do deployments here?" Like, "What kind of Git process do you use?" So, I don't know if those are necessarily the interesting ones. But I think one thing that has been nice is being a consultant has kind of stripped the fear of asking those questions because, I don't know, these are just things I need to know to do my work. And, like, I'm not as worried about, like, looking dumb or anything like that [laughs].

+ +

JOËL: Yeah. I think there's often a fear that asking questions might make you look incompetent or maybe will sort of undermine your appearance of knowing what you're talking about, and I think I've found that to be sort of the opposite. Asking a lot of questions can build more trust, both because it forces people to think about things that maybe they didn't think about, bring to light sort of implicit assumptions that everyone has, and also because it helps you to ramp up much more quickly and to be productive in a way that people really appreciate.

+ +

STEPHANIE: Yeah. And I also think that putting those things in, like, a public and, like, documented space helps people in the future too, right? At least I am a power Slack searcher [laughs]. And whenever I am onboarding somewhere, one of the first places I go is just to search in Slack and see if someone has asked this question before.

+ +

I think the next kind of category of question that I discerned was just, like, questions to understand how the team understands things. So, it's purely just to, like, absorb kind of like perspective or, like, a worldview this team has about their codebase, or their work, or whatever. So, I think those questions manifest as just like, "Oh, like, you know, I am curious, like, what do you think about how healthy your codebase is? Or what kinds of bugs is your team, like, dealing with?"

+ +

Just trying to get a better understanding of like, what are the challenges that this team is facing in their own words, especially before I even start to form my own opinions. Well, okay, to be honest, I probably am forming my own opinions, like, on the side [laughs], but I really try hard to not let that be the driver of how I'm showing up and especially in the first month I'm starting on a new team.

+ +

JOËL: Would you say these sorts of questions are more around sort of social organization or, like, how a team approaches work, that sort of thing? Or do you classify more technical questions in this category? So, like, "Hey, tell me a little bit about your philosophy around testing." Or we talked in a recent episode "What value do you feel you get out of testing?" as a question to ask before even, like, digging into the implementation.

+ +

STEPHANIE: Yeah, I think these questions, for me, sit at, like, the intersection of both social organization and technical questions because, you know, asking something like, "What's the value of testing for your team?" That will probably give me information about how their test suite is like, right? Like, what kinds of tests they are writing and kind of the quality of them maybe. And it also tells me about, yeah, like, maybe the reasons why, like, they only have just unit tests or maybe, like, just [inaudible 12:31] test, or whatever. And I think all of that is helpful information.

+ +

And then, that's actually a really...I like the distinction you made because I feel like then the last category of questions that I'll mention, for now, feels like more geared towards technical, especially the questions I ask to debunk assumptions that might be held by the team. And I feel like that's like kind of the last...the evolution of my question-asking. Because I have, hopefully, like, really absorbed, like, why, you know, people think the way they do about some of these, you know, about their code and start to poke a little bit on being like, "Why do you think, you know, like, this problem space has to be modeled this way?"

+ +

And that has served me well as a consultant because, you know, once you've been at an organization for a while, like, you start to take a lot of things for granted about just having to always be this way, you know, it's like, things just are the way they are. And part of the power of, you know, being this kind of, like, external observer is starting to kind of just like, yeah, be able to question that. And, you know, at the end of day, like, we choose not to change something, but I think it's very powerful to be able to at least, like, open up that conversation.

+ +

JOËL: Right. And sometimes you open up that conversation, and what you get is a link to a big PR discussion or a Wiki or something where that discussion has already been had. And then, that's good for you and probably good for anybody else who has that question as well.

+ +

STEPHANIE: I'm curious, for you, though, like, this thesis statement, atomic note, did you have notes around it, or was it just, like, you dropped it in there [laughs]?

+ +

JOËL: So, I have a few things, one is that when you come in as a consultant, and, you know, we're talking here about consultants because that's what we do. I think this is probably true for most people onboarding, especially for non-junior roles where you're coming in, and there's an assumption of expertise, but you need to onboard onto a project. This is just particularly relevant for us as consultants because we do this every six months instead of, you know, a senior developer who's doing this maybe every two to three years.

+ +

So, the note that I have here is that when you're brought on, clients they expect expertise in a technology, something like Ruby on Rails or, you know, just the web environment in general. They don't expect you as a consultant to be an expert in their domain or their practices. And so, when you really engage with this sort of areas that are new by asking a lot of questions, that's the thing that's really valuable, especially if those questions are coming from a place of experience in other similar things. So, maybe asking some questions around testing strategies because you've seen three or four other ways that work or don't work or that have different trade-offs.

+ +

Even asking about, "Hey, I see we went down a particular path, technically. Can you walk me through what were the trade-offs that we evaluated and why we decided this was the path that was valuable for us?" That's something that people really appreciate from outside experts. Because it shows that you've got experience in those trade-offs, that you've thought the deeper thoughts beyond just shipping the next ticket. And sometimes they've made the decisions without actually thinking through the trade-offs. And so, that can be an opening for a conversation of like, "Hey, well, we just went down this path because we saw a blog article that recommended this, or we just did this because it felt right. Talk us through the trade-offs."

+ +

And now maybe you have a conversation on, "Hey, here are the trade-offs that you're doing. Let me know if this sounds right for your organization. If not, maybe you want to consider changing some things or tweaking your approach." And I think that is valuable sort of at the big level where you're thinking about how the team is structured, how different parts of work is done, the technical architecture, but it also is valuable at the small level as well.

+ +

STEPHANIE: Yeah, 100%. There is a blog post I really like by Hazel Weakly, and it's called "The Power of Being New: A Proven Recipe for High Impact." And one thing that she says at the beginning that I really enjoy is that even though, like, whenever you start on a new team there's always that little bit of pressure of starting to deliver immediate value, right? But there's something really special about that period where no one expects you to do anything, like, super useful immediately [laughs]. And I feel like it is both a fleeting time and, you know, I'm excited to continue this conversation of, like, how to keep integrating that even after you're no longer new.

+ +

But I like to use that time to just identify, while I have nothing really on my plate, like, things that might have just been overlooked or just people have gotten used to that sometimes is, honestly, like, can be a quick fix, right? Like, just, I don't know, deleting a piece of dead code that you're seeing is no longer used but just gets fallen off other people's plates. I really enjoy those first few weeks, and people are almost, like, always so appreciative, right? They're like, "Oh my gosh, I have been meaning to do that." Or like, "Great find." And these are things that, like I said, just get overlooked when you are, yeah, kind of busy with other things that now are your responsibility.

+ +

JOËL: You're talking about, like, that feeling of can you add value in the, like, initial time that you join. And I think that sometimes it can be easy to think that, oh, the only value you can add is by, like, shipping code. I think that being sort of noisy and asking a lot of questions in Slack is often a great way to add value, especially at first.

+ +

STEPHANIE: Yeah, agreed.

+ +

JOËL: Ideally, I think you come in, and you don't sort of slide in under the radar as, like, a new person on the team. Like, you come in, and everybody knows you're there because you are, like, spamming the channel with questions on all sorts of things and getting people to either link you to resources they have or explaining different topics, especially anything domain-related. You know, you're coming in with an outside expertise in a technology. You are a complete new person at the business and the problem domain. And so, that's an area where you need to ask a lot of questions and ramp up quickly.

+ +

STEPHANIE: Yes. I have a kind of side topic. I guess it's not a side topic. It's about asking questions, so it's relevant [laughs]. But one thing that I'm curious about is how do you approach kind of doing this in a place where question asking is not normalized and maybe other people are less comfortable with kind of people asking questions openly and in public? Like, how do you set yourself up to be able to ask questions in a way that doesn't lead to just, like, some just, like, suspicion or discomfort about, like, why you're asking those questions?

+ +

JOËL: I think that's the beauty of the consultant title. When an organization brings in outside experts, they kind of expect you to ask questions. Or maybe it's not an explicit expectation, but when they see you asking a lot of questions, it sort of, I think, validates a lot of things that they expect about what an outside expert should be. So, asking a lot of questions of trying to understand your business, asking a lot of questions to try to understand the technical architecture, asking questions around, like, some subtle edge cases or trade-offs that were made in the technical architecture.

+ +

These are all things that help clients feel like they're getting value for the money from an outside expert because that's what you want an outside expert to do is to help you question some of your assumptions, to be able to leverage their, like, general expertise in a technology by applying it to your specific situation.

+ +

I've had situations where I'll ask, like, a very nuanced, deep technical question about, like, "Hey, so there's, like, this one weird edge case that I think could potentially happen. How do we, like, think through about this?" And one of the, like, more senior people on the team who built the initial codebase responded, like, almost, like, proud that I've discovered this, like, weird edge case, and being like, "Oh yeah, that was a thing that we did think about, and here's why. And it's really cool that, like, day one you're, like, just while reading through the code and were like, 'Oh, this thing,' because it took us, like, a month of thinking about it before we stumbled across that."

+ +

So, it was a weird kind of fun interaction where as a new person rolling on, one of the more experienced devs in the codebase almost felt, like, proud of me for having found that.

+ +

STEPHANIE: I like that, yeah. I feel like a lot of the time...it's like, it's so easy to ask questions to help people feel seen, to be like, "Oh yeah, like, I noticed this." And, you know, if you withhold any kind of, like, judgment about it when you ask the question, people are so willing to be like, yeah, like you said, like, "Oh, I'm glad you saw that." Or like, "Isn't that weird? Like, I was feeling, you know, I saw that, too." Or, like, it opens it up, I think, for building trust, which, again, like, I don't even think this is something that you necessarily need to be new to even do. But if at any point you feel like, you know, maybe your working relationship with someone could be better, right? To the point where you feel like you're, like, really on the same page, yeah, ask questions [laughs]. It can be that easy.

+ +

JOËL: And I think what can be really nice is, in an environment where question asking is not normalized, coming in and doing that can help sort of provide a little bit of cover to other people who are feeling less comfortable or less safe doing that. So, maybe there's a lot of junior members on the team who are feeling not super confident in themselves and are afraid that asking questions might undermine their position in the company. But me coming in as a sort of senior consultant and asking a lot of those questions can then help normalize that as a thing because then they can look and say, "Oh, well he's asking all these questions. Maybe I can ask my question, and it'll be okay."

+ +

STEPHANIE: I also wanted to talk about setting yourself up and asking questions to get a good answer, asking good questions to get useful answers. One thing that has worked really well for me in the past few months has been sharing why I'm asking the question. And I think this goes back to a little bit of what I was hinting at earlier. If the culture is not really used to people asking questions and that just being a thing that is normal, sharing a bit of intention can help, like, ease maybe some nervousness that people might feel. Especially as consultants, we also are in a bit of a, I don't know, like, there is some power dynamics occasionally where it's like, oh, like, the consultants are here. Like, what are they going to come in and change or, like, start, you know, doing to, quote, unquote, "improve", whatever, I don't know [laughs].

+ +

JOËL: Right, right.

+ +

STEPHANIE: Yeah, that's the consultant archetype, I think. Anyway.

+ +

JOËL: Just coming in and being like, "Oh, this is bad, and this is bad, and you're doing it wrong."

+ +

STEPHANIE: [laughs]

+ +

JOËL: Ooh, I would be ashamed if I was the author of this code.

+ +

STEPHANIE: Yeah, my hot take is that that is a bad consultant [laughs]. But maybe I'll say, like, "I am looking for some examples of this pattern. Where can I find them [laughs]?" Or "I've noticed that the team is struggling with, like, this particular part of the codebase, and I am thinking about improving it. What are some of your biggest challenges, like, working with this, like, model?" something like that.

+ +

And I think this also goes back to, like, proving value, right? Even if it's like, sometimes I know kind of what I want to do, and I'll try to be explicit about that. But even before I have, like, a clear action item, I might just say like, "I'm thinking about this," you know, to convey that, you know, I'm still in that information gathering stage, but the result of that will be useful to help me with whatever kind of comes out of it.

+ +

JOËL: A lot of it is about, like, genuine curiosity and an amount of empathetic listening. Existing team knows a lot about both the code and the business. And as a consultant coming on or maybe even a more senior person onboarding onto a team, the existing team has so much that they can give you to help you be better at your job.

+ +

STEPHANIE: I was also revisiting a really great blog post from Julia Evans about "How to Ask Good Questions." And this one is more geared towards asking technical questions that have, like, kind of a maybe more straightforward answer. But she included a few other strategies that I liked a lot. And, frankly, I feel like I want to be even better at finding the right time to ask questions [laughs] and finding the right person to ask those questions to.

+ +

I definitely get in the habit of just kind of like, I don't know, I'll just put it out there and [laughs], hopefully, get some answers. But there are definitely ways, I think, that you can be more strategic, right? About identifying who might be the best person to provide the answers you're looking for. And I think another thing that I often have to balance in the consulting position is when to know when to, like, stop kind of asking the really big questions because we just don't have time [laughs].

+ +

JOËL: Right. You don't want to be asking questions in a way that's sort of undermining the product, or the decisions that are being made, or the work that has to get done. Ideally, the questions that you're asking are helping move the project forward in a positive way. Nobody likes the, you know, just asking kind of person. That person's annoying.

+ +

STEPHANIE: Do you have an approach or any thoughts about like, once you get an answer, like, what do you do with that? Yeah, what happens then for you?

+ +

JOËL: I guess there's a lot of different ways it can go. A potential way if it's just, like, an answer explained in Slack, is maybe saying, "We should document this." Or maybe even like, "Is this documented anywhere? If not, can I add that documentation somewhere?" And maybe that's, you know, a code comment that we want to add. Maybe that's an entry to the Wiki. Maybe that's updating the README. Maybe that's adding a test case. But converting that into something actionable can often be a really good follow-up.

+ +

STEPHANIE: Yeah, I think that mitigates the just asking [laughs] thing that you were saying earlier, where it's like, you know, the goal isn't to ask questions to then make more work for other people, right? It's to ask questions so, hopefully, you're able to take that information and do something valuable with it.

+ +

JOËL: Right. Sometimes it can be a sort of setup for follow-up questions. You get some information and you're like, okay, so, it looks like we do have a pattern for interacting with third-party APIs, but we're not using it consistently. Tell me a little bit about why that is. Is that a new pattern that we've introduced and we're trying to, like, get more buy-in from the team? Is this a pattern that we used to have, and we found out we didn't like it? So, we stopped using it, but we haven't found a replacement pattern that we like. And so, now we're just kind of...it's a free-for-all, and we're trying to figure it out.

+ +

Maybe there's two competing patterns, and there is this, like, weird politics within the tech team where they're sort of using one or the other, and that's something I'm going to have to be careful to navigate. So, asking some of those follow-up questions and once you have a technical answer can yield a lot of really interesting information and then help you think about how you can be impactful on the organization.

+ +

STEPHANIE: And that sounds like advice that's just true, you know, regardless of your role or how long you've been in it, don't you think?

+ +

JOËL: I would say yes. If you've been in the role a long time, though, you're the person who has that sort of institutional history in your mind. You know that in 2022, we switched over from one framework to another. You know that we used to have this, like, very opinionated architect who mandated a particular pattern, and then we moved away from it. You know that we were all in on this big feature last summer that we released and then nobody used it, and then the business pivoted, but there's still aspects of it that are left around. Those are things that someone knew onboarding doesn't know and that, hopefully, they're asking questions that you can then answer.

+ +

STEPHANIE: Have you been in the position where you have all that, like, institutional knowledge? And then, like, how do you maintain that sense of curiosity or just that sense of kind of, like, what you're talking about, that superpower that you get when you're new of being able to just, you know, kind of question why things are the way they are?

+ +

JOËL: It's hard, right? We're talking about how do you keep that sort of almost like a beginner's mindset, in this case, maybe less of a, like, new coder mindset and more of a new hire mindset. It's something that I think is much more front of mind for me because I rotate onto new clients every, like, 6 to 12 months. And so, I don't have very long to get comfortable before I'm immediately thrown into, like, a new situation.

+ +

But something that I like to do is to never sort of solely be in one role or the other, a sort of, like, experienced person helping others or the new person asking for help. Likely, you are not going to be the newest person on the team for long. Maybe you came on as a cohort and you've got a group of new people, all of whom are asking different questions. And maybe somebody is asking a question that you've asked before, that you've asked in a different channel or on a call with someone. Or maybe someone joins two weeks after you; you don't have deep institutional knowledge.

+ +

But if you've been asking a lot of questions, you've been building a lot of that for yourself, and you have a little bit that you can share to the next person who knows even less than you do. And that's an approach that I took even as an apprentice developer. When I was, like, brand new to Rails and I was doing an internship, and another intern joined me a couple of weeks after, and I was like, "You know what? I barely know anything. But I know what an instance variable is. And I can help you write a controller action. Let's pair on that. We'll figure it out. And, you know, ask me another question next week. I might have more answers for you." So, I guess a little bit of paying it forward.

+ +

STEPHANIE: Yeah, I really like that advice, though, of, like, switching up the role or, like, kind of what you're working on, just finding opportunities to practice that, you know, even if you have been somewhere for a long time. I think that is really interesting advice. And it's hard, too, right? Because that requires, like, doing something new, and doing something new can be hard [laughs]. But if you're, you know, aren't in a consultant role, where you're not rotating onto new projects every 6 to 12 months, that, I feel like, would be a good strategy to grow in that particular way.

+ +

JOËL: And even if you're not switching companies or in a consulting situation, it's not uncommon to have people switch from one team to another within an organization. And new team might mean new dynamics. That team might be doing a slightly different approach to project management. Their part of the code might be structured slightly differently. They might be dealing with a part of the business domain that you're less familiar with. While that might not be entirely new to you because, you know, you know a little bit of the organization's DNA and you understand the organization's mission and their core product, there are definitely a lot of things that will be new to you, and asking those questions becomes important.

+ +

STEPHANIE: I also have another kind of, I don't know, it's not even a strategy. It's just a funny thing that I do where, like, my memory is so poor that, like, even code I wrote, you know, a month ago, I'm like, oh, what was past Stephanie thinking here [laughs]? You know, questioning myself a little bit, right? And being willing to do that and recognizing that, like, I have information now that I didn't have in the past. And, like, can that be useful somehow?

+ +

You know, it's like, the code I wrote a month ago is not set in stone. And I think that's one way I almost, like, practice that skill with myself [laughs]. And yeah, it has helped me combat that, like, things are the way they are mentality, which, generally, I think is a very big blocker [laughs] when it comes to software development, but that's a topic for another day [laughs].

+ +

JOËL: I like the idea of questioning yourself, and I think that's something that is a really valuable skill for all developers. I think it can come up in things like documentation. Let's say you're leaving a comment on a method, especially one that's a bit weird, being able to answer that "Why was this weird technical decision made?" Or maybe you do this in your PR description, or your commit message, or in any of the other places where you do this, not just sort of shipping the code as is, but trying to look at it from an outsider's eyes.

+ +

And being like, what are the areas where they're going to, like, get a quizzical look and be like, "Why is this happening? Why did you make this choice?" Bonus points if you talked a little bit about the trade-offs that were decided on to say, "Hey, there were two different implementations available for this. I chose to take implementation A because I like this set of trade-offs better." That's gold. And, I guess, as a reviewer, if I'm seeing that in a PR, that's going to make my job a lot easier.

+ +

STEPHANIE: Yes. Yeah, I never thought about it that way, but yeah, I guess I do kind of apply, you know, the things that I would kind of ask to other team members to myself sometimes. And that is...it's cool to hear that you really appreciate that because I always kind of just did it for myself [laughs], but yeah, I'm sure that it, like, is helpful for other people as well.

+ +

JOËL: I guess you were asking what are ways that you can ask questions even when you are more established. And talking about these sorts of self-reflective questions in the context of review got me thinking that PRs are a great place to ask questions. They're great when you're a newcomer. One of the things I like to do when I'm new on a project is do a lot of PR reviews so I can just see the weird things that people are working on and ask a lot of questions about the patterns.

+ +

STEPHANIE: Yep. Same here.

+ +

JOËL: Do a lot of code reading. But that's a thing that you can keep doing and asking a lot of questions on PRs and not in a, like, trying to undermine what the person is doing, but, like, genuine questions, I think, is a great way to maintain that mindset.

+ +

STEPHANIE: Yeah, yeah, agreed. And I think when I've seen it done well, it's like, you get to be engaged and involved with the rest of your team, right? And you kind of have a bit of an idea about what people are working on. But you're also kind of entrusting them with ownership of that work. Like, you don't need to be totally in the weeds and know exactly how every method works. But, you know, you can be curious about like, "Oh, like, what were you thinking about this?" Or like, "What about this pattern appeals to you?" And all of that information, I think, helps you become a better, like, especially a senior developer, but also just, like, a leader on the team, I think.

+ +

JOËL: Yeah, especially the questions around like, "Oh, walk me through some of the trade-offs that you chose for this method." And, you know, for maybe a person who's more senior, that's great. They have an opportunity to, like, talk about the decisions they made and why. That's really useful information. For a more junior person, maybe they've never thought about it. They're like, "Oh, wait, there are trade-offs here?" and now that's a great learning opportunity for them.

+ +

And you don't want to come at it from a place of judgment of like, oh, well, clearly, you know, you're a terrible developer because you didn't think about the performance implications of this method. But if you come at it from a place of, like, genuine curiosity and sort of assuming the best of people on the team and being willing to work alongside them, help them discover some new concepts...maybe they've never, like, interacted so much with performance trade-offs, and now you get to have a conversation. And they've learned a thing, and everybody wins.

+ +

STEPHANIE: Yeah. And also, I think seeing people ask questions that way helps more junior folks also learn when to ask those kinds of questions, even if they don't know the answer, right? But maybe they start kind of pattern matching. Like, oh, like, there might be some other trade-offs to consider with this kind of code, but I don't know what they are yet. But now I know to at least start asking and find someone who can help me determine that. And when I've seen that, that has been always, like, just so cool because it's upskilling happening [laughs] in practice.

+ +

JOËL: Exactly. I love that phrase that you said: "Asking questions where you don't know the answers," which I think is the opposite of what lawyers are taught to do. I think lawyers the mantra they have is you never ask a witness a question that you don't know the answer to. But I like to flip that for developers. Ask a lot of questions on PRs where you don't know the answer, and you'll grow, and the author will grow. And this is true across experience levels.

+ +

STEPHANIE: That's one of my favorite parts about being a developer, and maybe that's why I will never be a lawyer [laughter].

+ +

JOËL: On that note, I have a question maybe I do know the answer to. Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+YzU0NzCu + + ]]> + + Joël Quenneville + Stephanie Minn + + + 430: Test Suite Pain & Anti-Patterns + https://bikeshed.thoughtbot.com/430 + e0ab6318-d9f2-49da-9e2d-5bfb26bf0656 + Tue, 25 Jun 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + 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. + 40:57 + no + + + 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 to clean up this area of the codebase, but you kind of caught on to that bit of, you know, it can go so many different ways. And, like, how do you balance your grand visions [laughs] of things with, I guess, a little bit of pragmatism? So, it was very much like, here's all these bugs that are causing our customers problems that are kind of, like, hard for the devs to troubleshoot. You know, that kind of prompts the question, like, why? +And so, if there can be, you know, the fixing of the bugs, and then the learning of, like, how that part of the system works, and then, hopefully, some improvements along the way, yeah, that just felt like a dream [laughs] for me. And two weeks felt about the right amount of time. I don't know if anyone kind of hears that and feels like it's too long or too little. I would be really curious. But I feel like it is complex enough that, like, context switching would, I think, make this work harder, and you kind of do have to just sit with it for a little bit to get your bearings. +JOËL: A scenario that we encounter on a pretty regular basis is a customer coming to us and telling us that they're feeling a lot of test pain and asking what are the ways that we can help them to make things better and that test pain can come under a lot of forms. +It might be a test suite that's really slow and that's hurting the team in terms of their velocity. It might be a test suite that is really flaky. It might be one that is really difficult to add to, or maybe one that has very low coverage, or one that is just really brittle. Anytime you try to make a change to it, a bunch of things break, and it takes forever to ship anything. So, there's a lot of different aspects of challenging test suites that clients come to us with. +I'm curious, Stephanie, what are some of the ones that you've encountered most frequently? +STEPHANIE: I definitely think that a slow test suite and a flaky test suite end up going hand in hand a lot, or just a brittle one, right? That is slowing down development and, like you said, causing a lot of pain. I think even if that's not something that a client is coming to us directly about, it maybe gets, like, surfaced a little bit, you know, sometime into the engagement as something that I like to keep an eye on as a consultant. And I actually think, yeah, that's one of kind of the coolest things, I think, about our consulting work is just getting to see so many different test suites [laughs]. I don't know. I'm a testing nerd, so I love that kind of stuff. +And then, I think you were also kind of touching on this idea of, like, maintaining a test suite and, yeah, making testing just a better experience. I have a theory [laughs], and I'd be curious to get your thoughts on it. But one thing that I really struggle with in the industry is when people talk about writing tests as if it's, like, the morally superior thing to do. And I struggle with this because I don't think that it is a very good strategy for helping people feel better or more confident and, like, upskill at writing tests. +I think it kind of shames people a little bit who maybe either just haven't gotten that experience or, you know, just like, yeah, like, for whatever reason, are still learning how to do this thing. And then, I think that mindset leads to bad tests [laughs] or tests that aren't really serving the purpose that you hope they would because people are doing it more out of obligation rather than because they truly, like, feel like it adds something to their work. Okay, I kind of just dropped that on you [laughs]. Do you have any reactions? +JOËL: Yeah, I guess the idea that you're just checking a box with your test rather than writing code that adds value to the codebase. They're two very different perspectives that, in the end, will generate more lines of code if you're just doing a checkbox but may or may not add a whole lot of value. So, maybe before even looking at actual, like, test practices, it's worth stepping back and asking more of a mindset question: Why does your team test? What is the value that your team feels they get out of testing? +STEPHANIE: Yeah. Yeah. I like that because I was about to say they go hand in hand. But I do think that maybe there is some, you know, question asking [laughs] to be done because I do think people like to kind of talk about the testing practices before they've really considered that. And I am, like, pretty certain from just kind of, at least what I've seen, and what I've heard, and what I've experienced on embedding into client teams, that if your team can't answer that question of, like, "What value does testing bring?" then they probably aren't following good testing practices [laughs]. Because I do think you kind of need to approach it from a perspective of like, okay, like, I want to do this because it helps me, and it helps my team, rather than, like you said, getting the check mark. +JOËL: So, once we've sort of established maybe a bit of a mindset or we've had a conversation with the team around what value they think they're getting out of tests, or maybe even you might need to sell the team a little bit on like, "Hey, here's, like, all these different ways that testing can bring value into your life, make your life as developers easier," but once you've done that sort of pre-work and you can start looking at what's actually the problem with a test suite, a common complaint from developers is that the test suite is too slow. How do you like to approach a slow test suite? +STEPHANIE: That's a good question. I actually...I think there's a lot of ways to answer that. But to kind of stay on the theme of stepping back a little bit, I wonder if assessing how well your test suite aligns with the testing pyramid would be a good place to start; at least, that could be where I start if I'm coming into a client team for the first time, right, and being asked to start assessing or just poking around. Because I think the slowness a lot of the time comes from a lot of quote, unquote, "integration tests" or, like, unit tests masquerading as integration tests, where you end up having, like, a lot of duplication of things that are being tested in ways that are integrating with some slow parts of the system like the database. +And yeah, I think even before getting into some of the more discreet reasons why you might be writing slow tests, just looking at the structure of your test suite and what kinds of things you're testing, and, again, even going back to your team and asking, like, "What kinds of things do you test?" Or like, "Do you try to test or wish to be testing more of, less of?" Like looking at the structure, I have found to be a good place to start. +JOËL: And for those who are not familiar, you used the term testing pyramid. This is a concept which says that you probably want to have a lot of small, fast unit tests, a medium amount of integration tests that test a few different components together, and then a few end-to-end tests. Because as you go up that pyramid, tests become more expensive. They take a lot longer to run, whereas the little unit tests are super cheap. You can create thousands of them, and they will barely impact your run time. Adding a dozen end-to-end tests is going to be noticeable. So, you want to balance sort of the coverage that you get from end to end with the sort of cheapness and ubiquity of the little unit tests, and then split the difference for tests that are in between. +STEPHANIE: And I think that is challenging, even, you know, you're talking about how you want the peak of your pyramid to be end-to-end tests. So, you don't want a lot of them, but you do want some of them to really ensure that things are totally plumbed and working correctly. But that does require, I think, really looking at your application and kind of identifying what features are the most critical to it. And I think that doesn't get paid enough attention, at least from a lot of my client experiences. Like, sometimes teams just end up with a lot of feature bloat and can't say like, you know, they say, "Everything's important [chuckles]," but everything can't be equally important, you know? +JOËL: Right. I often like to develop using a sort of outside-in approach, where you start by writing an end-to-end test that describes the behavior that your new feature ticket is asking for and use that to drive the work that I'm doing. And that might lead to some lower-level unit tests as I'm building out different components, but the sort of high-level behavior that we're adding is driven by adding an end-to-end spec. +Do you feel that having one new end-to-end spec for every new feature ticket that you work on is a reasonable thing to do, or do you kind of pick and choose? Do you write some, but maybe start, like, coalescing or culling them, or something like that? How do you manage that idea that maybe you would or would not want one end-to-end spec for each feature ticket? +STEPHANIE: Yeah, it's a good question. Actually, as you were saying that, I was about to ask you, do you delete some afterwards [laughs]? Because I think that might be what I do sometimes, especially if I'm testing, you know, edge cases or writing, like, the end-to-end test for error states. Sometimes, not all of them make it into my, like, final, you know, commit. But they, you know, had their value, right? And at least it prompted me to make sure I thought about them and make sure that they were good error states, right? Like things that had visible UI to the user about what was going on in case of an error. So, I would say I will go back and kind of coalesce some of them, but they at least give me a place to start. Does that match your experience? +JOËL: Yeah, I tend to mostly write end-to-end tests for happy paths and then write kind of mid-level things to cover some of my edge cases, maybe a couple of end-to-end tests for particularly critical paths. But, at some point, there's just too many paths through the app that you can't have end-to-end coverage for every single branch on every single path that can happen. +STEPHANIE: Yeah, I like that because if you find yourself having a lot of different conditions that you need to test in an end-to-end situation, maybe there's room for that to, like, be better encapsulated in that, like, more, like, middle layer or, I don't know, even starting to ask questions about, like, does this make sense with the product? Like, having all of these different things going on, does that line up with kind of the vision of what this feature is trying to be or should be? Because I do think the complexity can start at that high of a level. +JOËL: How do you feel about the idea that adding more end-to-end tests, at some point, has diminishing returns? +STEPHANIE: I'm not quite sure I'm following [laughs]. +JOËL: So, let's say you have an end-to-end test for the happy path for every core feature of the app. And you decide, you know what, I want to add maybe some, like, side features in, or maybe I want to have more error states. And you start, like, filling in more end-to-end tests for those. Is it fair to say that adding some of those is a bit of a diminishing return? Like, you're not getting as much value as you would from the original specs. And maybe as you keep finding more and more rare edge cases, you get less and less value for your test. +STEPHANIE: Oh, yeah, I see. And there's more of a cost, too, right? The cost of the time to run, maintain, whatever. +JOËL: Right. Let's say they're roughly all equally expensive in terms of cost to run. But as you stray further and further off of that happy path, you're getting less and less value from that integration test or that end-to-end test. +STEPHANIE: I'm actually a little conflicted about this because that sounds right in theory, but then in practice, I feel like I've seen error states not get enough love [laughs] that it's...I don't even want to say, like, you make any kind of claim [laughs] about it. But, you know, if you're going to start somewhere, if you have, like, a limited amount of time and you're like, okay, I'm only going to write a handful of end-to-end tests, yeah, like, write tests for your happy paths [laughs]. +JOËL: I guess it's probably fair to say that error states just don't get as much love as they should throughout the entire testing stack: at the unit level, at the integration level, all the way up to end to end. +STEPHANIE: I'm curious if you were trying to get at some kind of conclusion, though, with the idea of diminishing returns. +JOËL: I guess I'm wondering if, from there, we can talk about maybe a breakdown of a particular testing pyramid for a particular test suite is being top heavy, and whether there's value in maybe pushing some of these tests, some of these edge cases, some of these maybe less important features down from that, like, top end-to-end layer into maybe more of an integration layer. So, in a Rails context, that might be moving system specs down to something like a request spec. +STEPHANIE: Yeah, I think that is what I tend to do. I'm trying to think of how I get there, and I'm not quite sure that I can explain it quite yet. Yeah, I don't know. Do you think you can help me out here? Like, how do you know it's time to start writing more tests for your unhappy paths lower on the pyramid? +JOËL: Ideally, I think a lot of your code should be unit-tested. And when you are unit testing it, those pieces all need coverage of the happy and unhappy paths. I think the way it may often happen naturally is if you're pushing logic out of your controllers because it's a little bit challenging sometimes to test Rails controllers. +And so, if you're moving things into domain objects, even service objects, depending on how you implement them, just doing that and then making sure you unit test them can give you a lot more coverage of all the different edge cases that can happen. Where things sometimes fall apart is getting out of that business layer into the web layer and saying, "Hey, if something raises an error or if the save fails or something like that, does the user get a good experience, or do we just crash and give them a 500 page?" +STEPHANIE: Yeah, that matches with a lot of what I've seen, where if you then spend too much time in that business layer and only handling errors there, you don't really think too much about how it bubbles up. And, you know, then you are digging through, like, your error monitoring [laughs] service, trying to find out what happened so that you can tell, you know, your customer support team [laughs] to help them resolve, like, a bug report they got. +But I actually think...and you were talking about outside in, but, in some ways, in my experience, I also get feedback from the bottom up sometimes that then ends up helping me adjust some of those integration or end-to-end tests about kind of what errors are possible, like, down in the depths of the code [laughs], and then finding ways to, you know, abstract that or, like, kind of be like, "Oh, like, here are all these possible, like, exceptions that might be raised." Like, what HTTP status code do I want to be returned to capture all of these things? And what do I want to say to the user? So, yeah, I'm [laughs] kind of a little lost myself, but this idea that going both, you know, outside in and then maybe even going back up a little bit has served me well before. +JOËL: I think there can be a lot of value in sort of dropping down a level in the pyramid, and maybe instead of doing sort of end-to-end tests where you, like, trigger a scenario where something fails, you can just write a request back against the controller and say, "Hey, if I go to this controller and something raises an error, expect that you get redirected to this other location." And that's really cheap to run compared to an end-to-end test. And so, I think that, for me, is often the right compromise is handling error states at sort of the next lowest level and also in slightly more atomic pieces. So, more like, if you hit this endpoint and things go wrong, here's how things happen. +And I use endpoint not so much in an API sense, although it could be, but just your, you know, maybe you've got a flow that's multiple steps where, you know, you can do a bunch of things. But I might have a test just for one controller action to say, "Hey, if things go wrong, it redirects you here, or it shows you this error page." Whereas the end-to-end test might say, "Oh, you're going to go through the entire flow that hits multiple different controllers, and the happy path is this nice chain." But each of the exit points off at where things fail would be covered by a more scoped request spec on that controller. +STEPHANIE: Yeah. Yeah. That makes sense. I like that. +JOËL: So, that's kind of how I've attempted to balance my pyramid in a way that balances complexity and time with coverage. You mentioned that another area that test suites get slow is making too many requests to the database. There's a lot of ways that that happens. Oftentimes, I think a classic is using a factory where you really don't need to, persisting data to the database when all you needed was some object in memory. So, there are different strategies for avoiding that. +It's also easy to be creating too much data. So, maybe you do need to persist some things in the database, but you're persisting a hundred objects into memory or into the database when you really meant to persist two, so that's an easy accident. A couple of years ago, I gave a talk at RailsConf titled "Your Test Suite is Making Too Many Database Requests" that went over a bunch of different ways that you can be doing a lot of expensive database requests you didn't plan on making and how that slows down your test suite. So, that is also another hot spot that I like to look at when dealing with a slow test suite. +STEPHANIE: Yeah, I mentioned earlier the idea of unit tests really masquerading as integration tests [laughs]. And I think that happens especially if you're starting with a class that may already be a little bit too big than it should be or have more responsibilities than it should be. And then, you are, like, either just, like, starting with using the create build, like, strategy with factories, or you find yourself, like, not being able to fully run the code path you're trying to test without having stuff persisted. +Those are all, I think, like, test smells that, you know, are signaling a little bit of a testing anti-pattern that, yeah, like, is there a way to write, like, true unit tests for this stuff where you are only using objects in memory? And does that require breaking out some responsibilities? That is a lot of what I am kind of going through right now, actually, with my little refractoring project [laughs] is backfilling some tests, finding that I have to create a lot of records. +And you know what? Like, the first step will probably be to write those tests and commit them, and just have them live there for a little while while I figure out, you know, the right places to start breaking things up, and that's okay. But yeah, I did want to, like, just mention that if you are having to create a lot of records and then also noticing, like, your test is running kind of slow [laughs], that could be a good indicator to just give a good, hard look at what kind of style of test you think you're writing [laughs]. +JOËL: Yeah, your tests speak to you, and when you're feeling pain, oftentimes, it can be a sign that you should consider refactoring your implementation. And I think that's doubly true if you're writing tests after the fact rather than test driving. Because sometimes you sort of...you came up with an implementation that you thought would be good, and then you're writing tests for it, and it's really painful. And that might be telling you something about the underlying implementation that you have that maybe it's...you thought it's well scoped, but maybe it actually has more responsibilities than you initially realized, or maybe it's just really tightly coupled in a way that you didn't realize. And so, learning to listen to your tests and not just sort of accepting the world for being the way it is, but being like, "No, I can make it better." +STEPHANIE: Yeah, I've been really curious why people have a hard time, like, recognizing that pain sometimes, or maybe believing that this is the way it is and that there's not a whole lot that you can do about it. But it's not true, like, testing really does not have to be painful. And I feel like, again, this is one of those things that's like, it's hard to believe until you really experience it, at least, that was the case for me. +But if you're having a hard time with tests, it's not because you're not smart enough. Like, that, I think, is a thing that I really want to debunk right now [laughs] for anyone who has ever had that thought cross their mind. Yeah, things are just complicated and complex somehow, or software entropy happens. That's, like, not how it should be, and we don't have to accept that [laughs]. So, I really like what you said about, oh, you can change it. And, you know, that is a bit of a callback to the whole mindset of testing that we mentioned earlier at the beginning. +JOËL: Speaking of test suites, we have not covered yet is paralyzing it. That could probably be its own Bike Shed episode on its own entirely on paralyzing a test suite. We've done entire engagements where our job was to come in and help paralyze a test suite, make it faster. And there's a lot of, like, pros and cons. So, I think maybe we can save that for a different episode. And, instead, I'd like to quickly jump in a little bit to some other common pain points of test suites, and I would say probably top of that list is test flakiness. How do you tend to approach flakiness in a client project? +STEPHANIE: I am, like, laughing to myself a little bit because I know that I was dealing with test flakiness on my last client engagement, and that was, like, such a huge part of my day-to-day is, like, hitting that retry button. And now that I am on a project with, like, relatively low flakiness, I just haven't thought about it at all [laughs], which is such a privilege, I think [laughs]. +But one of the first things to do is just start, like, capturing metrics around it. If you, you know, are hearing about flakiness or seeing that, like, start to plague your test suite or just, you know, cropping up in different ways, I have found it really useful to start, like, I don't know, just, like, maybe putting some of that information in a dashboard and seeing how, just to, like, even make sure that you are making improvements, that things are changing, and seeing if there's any, like, patterns around what's causing the flakiness because there are so many different causes of it. +And I think it is pretty important to figure out, like, what kind of code you're writing or just trying to wrangle. That's, you know, maybe more likely to crop up as flakiness for your particular domain or application. Yeah, I'm going to stop there and see, like, because I know you have a lot of thoughts about flakiness [laughs]. +JOËL: I mean, you mentioned that there's a lot of different causes for flakiness. And I think, in my experience, they often sort of group into, let's say, like, three different buckets. Anytime you're testing code that's doing things that are non-deterministic, that's easy for tests to be flaky. And so, you might think, oh, well, you know, you have something that makes a call to random, and then you're going to assert on a particular outcome of that. Well, clearly, that's going to not be the same every time, and that might be flaky. +But there are, like, more subtle versions of that, so maybe you're relying on the system clock in some way. And, you know, depending on the time you run that test, it might give you a different value than you expect, and that might cause it to fail. And it doesn't have to be you're asserting on, like, oh, specifically a given millisecond. You might be doing math around, like, number of days, and when you get near to, let's say, the daylight savings boundary, all of a sudden, no, you're off by an hour, and your number of days...calculation breaks because relying on the clock is something that is inherently non-deterministic. Non-determinism is a bucket. +Leaky tests is another bucket of failures that I see, things where one test might impact another that gets run after the fact, oftentimes by mutating some sort of global state. So, maybe you're both relying on some sort of, like, external file that you're both writing to or maybe a cache that one is writing to that the other one is reading from, something like that. It could even just be writing records into the database in a way that's not wrapped in a transaction, such that there's more data in the database when the next test runs than it expects. +And then, finally, if you are doing any form of parallelization, that can improve your test suite speed, but it also potentially leads to race conditions, where if your resources aren't entirely isolated between parallel test runners, maybe you're sharing a database, maybe you're sharing Redis instance or whatever, then you can run into situations where you're both kind of fighting over the same resources or overriding each other's data, or things like that, in a way that can cause tests to fail intermittently. And I think having a framework like that of categorization can then help you think about potential solutions because debugging approaches and then solutions tend to be a little bit different for each of these buckets. +STEPHANIE: Yeah, the buckets of different causes of flaky tests you were talking about, I think, also reminded me that, you know, some flakiness is caused by, like, your testing environment and your infrastructure. And other kinds of flakiness are maybe caused more from just the way that you've decided how your code should work, especially that, like, non-deterministic bucket. So, yeah, I don't know, that was just, like, something that I noticed as you were going through the different categories. And yeah, like, certainly, the solutions for approaching each kind are very different. +JOËL: I would like to pitch a talk from RubyConf last year called "The Secret Ingredient: How To Resolve And Understand Just About Any Flaky Test" by Alan Ridlehoover. Just really excellent walkthrough of these different buckets and common debugging and solving approaches to each of them. And I think having that framework in mind is just a great way to approach different types of flaky tests. +STEPHANIE: Yes, I'll plus one that talk, lots of great pictures of delicious croissants as well. +JOËL: Very flaky pastry. +STEPHANIE: [laughs] Joël, do you have any last testing anti-pattern guidances for our audience who might be feeling some test pain out there? +JOËL: A quick list, I'm going to say tight coupling that has then led to having a lot of stubbing in your tests often leads to tests that are very brittle, so tests that maybe don't fail when they should when you've actually broken things, or maybe, alternatively, tests that are constantly failing for the wrong reasons. And so, that is a thing that you can fix by making your code less coupled. +Tests that also require stubbing a lot of things because you do a lot of side effects. If you are making a lot of HTTP calls or things like that, that can both make a test more complex because it has to be aware of that. But also, it can make it more non-deterministic, more flaky, and it can just make it harder to change. And so, I have found that separating side effects from sort of business logic is often a great way to make your test suite much easier to work with. +I have a blog post on that that I'll link in the show notes. And I think this maybe also approaches the idea of a functional core and an imperative shell, which I believe was an idea pitched by Gary Bernhardt, like, over ten years ago. There's a famous video on that that we'll also link in the show notes. But that architecture for building an app can lead to a much nicer test to write. I guess the general idea being that testing code that does side effects is complicated and painful. Testing code that is more functional tends to be much more pleasant. And so, by not intermingling the two, you tend to get nicer tests that are easier to maintain. +STEPHANIE: That's really interesting. I've not heard that guidance before, but now I am intrigued. That reminded me of another thing that I had a conversation with someone about. Because after the RailsConf talk I gave, which was about testing pain, there was some stubbing involved in the examples that I was showing because I just see a lot of that stuff. And, you know, this audience member kind of had that question of, like, "How do you know that things are working correctly if you have to stub all this stuff out?" +And, you know, sometimes you just have to for the time being [chuckles]. And I wanted to just kind of call back to that idea of having those end-to-end tests testing your critical paths to at least make sure that those things work together in the happy way. Because I have seen, especially with apps that have a lot of service objects, for some reason, those being kind of the highest-level test sometimes. But oftentimes, they end up not being composed well, being quite coupled with other service objects. So, you end up with a lot of stubbing of those in your test for them. And I think that's kind of where you can see things start to break down. +JOËL: Yep. And when the RailsConf videos come out, I recommend seeing Stephanie's talk, some great gems in there for building a more maintainable test suite. Stephanie and I and, you know, most of us here at thoughtbot, we're testing nerds. We think about this a lot. We've also written a lot about this. There are a lot of resources in the show notes for this episode. Check them out. Also, just generally, check out the testing tag on the thoughtbot blog. There is a ton of content there that is worth looking into if you want to dig further into this topic. +STEPHANIE: Yeah, and if you are wanting some, like, dedicated, customized testing training, thoughtbot offers an RSpec workshop that's tailored to your team. And if you kind of are interested in the things we're sharing, we can definitely bring that to your company as well. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + RubyConf, thoughtbot, software development, refactoring code, test suite challenges, RubyCentral, proposal submissions, local conference, end-to-end tests, integration tests, unit tests, testing pyramid, error handling, code stability, database requests, programming conference, Ruby programming, RSpec workshop, community engagement, podcast episode, software testing strategies + + 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.

+ + + +

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 to clean up this area of the codebase, but you kind of caught on to that bit of, you know, it can go so many different ways. And, like, how do you balance your grand visions [laughs] of things with, I guess, a little bit of pragmatism? So, it was very much like, here's all these bugs that are causing our customers problems that are kind of, like, hard for the devs to troubleshoot. You know, that kind of prompts the question, like, why?

+ +

And so, if there can be, you know, the fixing of the bugs, and then the learning of, like, how that part of the system works, and then, hopefully, some improvements along the way, yeah, that just felt like a dream [laughs] for me. And two weeks felt about the right amount of time. I don't know if anyone kind of hears that and feels like it's too long or too little. I would be really curious. But I feel like it is complex enough that, like, context switching would, I think, make this work harder, and you kind of do have to just sit with it for a little bit to get your bearings.

+ +

JOËL: A scenario that we encounter on a pretty regular basis is a customer coming to us and telling us that they're feeling a lot of test pain and asking what are the ways that we can help them to make things better and that test pain can come under a lot of forms.

+ +

It might be a test suite that's really slow and that's hurting the team in terms of their velocity. It might be a test suite that is really flaky. It might be one that is really difficult to add to, or maybe one that has very low coverage, or one that is just really brittle. Anytime you try to make a change to it, a bunch of things break, and it takes forever to ship anything. So, there's a lot of different aspects of challenging test suites that clients come to us with.

+ +

I'm curious, Stephanie, what are some of the ones that you've encountered most frequently?

+ +

STEPHANIE: I definitely think that a slow test suite and a flaky test suite end up going hand in hand a lot, or just a brittle one, right? That is slowing down development and, like you said, causing a lot of pain. I think even if that's not something that a client is coming to us directly about, it maybe gets, like, surfaced a little bit, you know, sometime into the engagement as something that I like to keep an eye on as a consultant. And I actually think, yeah, that's one of kind of the coolest things, I think, about our consulting work is just getting to see so many different test suites [laughs]. I don't know. I'm a testing nerd, so I love that kind of stuff.

+ +

And then, I think you were also kind of touching on this idea of, like, maintaining a test suite and, yeah, making testing just a better experience. I have a theory [laughs], and I'd be curious to get your thoughts on it. But one thing that I really struggle with in the industry is when people talk about writing tests as if it's, like, the morally superior thing to do. And I struggle with this because I don't think that it is a very good strategy for helping people feel better or more confident and, like, upskill at writing tests.

+ +

I think it kind of shames people a little bit who maybe either just haven't gotten that experience or, you know, just like, yeah, like, for whatever reason, are still learning how to do this thing. And then, I think that mindset leads to bad tests [laughs] or tests that aren't really serving the purpose that you hope they would because people are doing it more out of obligation rather than because they truly, like, feel like it adds something to their work. Okay, I kind of just dropped that on you [laughs]. Do you have any reactions?

+ +

JOËL: Yeah, I guess the idea that you're just checking a box with your test rather than writing code that adds value to the codebase. They're two very different perspectives that, in the end, will generate more lines of code if you're just doing a checkbox but may or may not add a whole lot of value. So, maybe before even looking at actual, like, test practices, it's worth stepping back and asking more of a mindset question: Why does your team test? What is the value that your team feels they get out of testing?

+ +

STEPHANIE: Yeah. Yeah. I like that because I was about to say they go hand in hand. But I do think that maybe there is some, you know, question asking [laughs] to be done because I do think people like to kind of talk about the testing practices before they've really considered that. And I am, like, pretty certain from just kind of, at least what I've seen, and what I've heard, and what I've experienced on embedding into client teams, that if your team can't answer that question of, like, "What value does testing bring?" then they probably aren't following good testing practices [laughs]. Because I do think you kind of need to approach it from a perspective of like, okay, like, I want to do this because it helps me, and it helps my team, rather than, like you said, getting the check mark.

+ +

JOËL: So, once we've sort of established maybe a bit of a mindset or we've had a conversation with the team around what value they think they're getting out of tests, or maybe even you might need to sell the team a little bit on like, "Hey, here's, like, all these different ways that testing can bring value into your life, make your life as developers easier," but once you've done that sort of pre-work and you can start looking at what's actually the problem with a test suite, a common complaint from developers is that the test suite is too slow. How do you like to approach a slow test suite?

+ +

STEPHANIE: That's a good question. I actually...I think there's a lot of ways to answer that. But to kind of stay on the theme of stepping back a little bit, I wonder if assessing how well your test suite aligns with the testing pyramid would be a good place to start; at least, that could be where I start if I'm coming into a client team for the first time, right, and being asked to start assessing or just poking around. Because I think the slowness a lot of the time comes from a lot of quote, unquote, "integration tests" or, like, unit tests masquerading as integration tests, where you end up having, like, a lot of duplication of things that are being tested in ways that are integrating with some slow parts of the system like the database.

+ +

And yeah, I think even before getting into some of the more discreet reasons why you might be writing slow tests, just looking at the structure of your test suite and what kinds of things you're testing, and, again, even going back to your team and asking, like, "What kinds of things do you test?" Or like, "Do you try to test or wish to be testing more of, less of?" Like looking at the structure, I have found to be a good place to start.

+ +

JOËL: And for those who are not familiar, you used the term testing pyramid. This is a concept which says that you probably want to have a lot of small, fast unit tests, a medium amount of integration tests that test a few different components together, and then a few end-to-end tests. Because as you go up that pyramid, tests become more expensive. They take a lot longer to run, whereas the little unit tests are super cheap. You can create thousands of them, and they will barely impact your run time. Adding a dozen end-to-end tests is going to be noticeable. So, you want to balance sort of the coverage that you get from end to end with the sort of cheapness and ubiquity of the little unit tests, and then split the difference for tests that are in between.

+ +

STEPHANIE: And I think that is challenging, even, you know, you're talking about how you want the peak of your pyramid to be end-to-end tests. So, you don't want a lot of them, but you do want some of them to really ensure that things are totally plumbed and working correctly. But that does require, I think, really looking at your application and kind of identifying what features are the most critical to it. And I think that doesn't get paid enough attention, at least from a lot of my client experiences. Like, sometimes teams just end up with a lot of feature bloat and can't say like, you know, they say, "Everything's important [chuckles]," but everything can't be equally important, you know?

+ +

JOËL: Right. I often like to develop using a sort of outside-in approach, where you start by writing an end-to-end test that describes the behavior that your new feature ticket is asking for and use that to drive the work that I'm doing. And that might lead to some lower-level unit tests as I'm building out different components, but the sort of high-level behavior that we're adding is driven by adding an end-to-end spec.

+ +

Do you feel that having one new end-to-end spec for every new feature ticket that you work on is a reasonable thing to do, or do you kind of pick and choose? Do you write some, but maybe start, like, coalescing or culling them, or something like that? How do you manage that idea that maybe you would or would not want one end-to-end spec for each feature ticket?

+ +

STEPHANIE: Yeah, it's a good question. Actually, as you were saying that, I was about to ask you, do you delete some afterwards [laughs]? Because I think that might be what I do sometimes, especially if I'm testing, you know, edge cases or writing, like, the end-to-end test for error states. Sometimes, not all of them make it into my, like, final, you know, commit. But they, you know, had their value, right? And at least it prompted me to make sure I thought about them and make sure that they were good error states, right? Like things that had visible UI to the user about what was going on in case of an error. So, I would say I will go back and kind of coalesce some of them, but they at least give me a place to start. Does that match your experience?

+ +

JOËL: Yeah, I tend to mostly write end-to-end tests for happy paths and then write kind of mid-level things to cover some of my edge cases, maybe a couple of end-to-end tests for particularly critical paths. But, at some point, there's just too many paths through the app that you can't have end-to-end coverage for every single branch on every single path that can happen.

+ +

STEPHANIE: Yeah, I like that because if you find yourself having a lot of different conditions that you need to test in an end-to-end situation, maybe there's room for that to, like, be better encapsulated in that, like, more, like, middle layer or, I don't know, even starting to ask questions about, like, does this make sense with the product? Like, having all of these different things going on, does that line up with kind of the vision of what this feature is trying to be or should be? Because I do think the complexity can start at that high of a level.

+ +

JOËL: How do you feel about the idea that adding more end-to-end tests, at some point, has diminishing returns?

+ +

STEPHANIE: I'm not quite sure I'm following [laughs].

+ +

JOËL: So, let's say you have an end-to-end test for the happy path for every core feature of the app. And you decide, you know what, I want to add maybe some, like, side features in, or maybe I want to have more error states. And you start, like, filling in more end-to-end tests for those. Is it fair to say that adding some of those is a bit of a diminishing return? Like, you're not getting as much value as you would from the original specs. And maybe as you keep finding more and more rare edge cases, you get less and less value for your test.

+ +

STEPHANIE: Oh, yeah, I see. And there's more of a cost, too, right? The cost of the time to run, maintain, whatever.

+ +

JOËL: Right. Let's say they're roughly all equally expensive in terms of cost to run. But as you stray further and further off of that happy path, you're getting less and less value from that integration test or that end-to-end test.

+ +

STEPHANIE: I'm actually a little conflicted about this because that sounds right in theory, but then in practice, I feel like I've seen error states not get enough love [laughs] that it's...I don't even want to say, like, you make any kind of claim [laughs] about it. But, you know, if you're going to start somewhere, if you have, like, a limited amount of time and you're like, okay, I'm only going to write a handful of end-to-end tests, yeah, like, write tests for your happy paths [laughs].

+ +

JOËL: I guess it's probably fair to say that error states just don't get as much love as they should throughout the entire testing stack: at the unit level, at the integration level, all the way up to end to end.

+ +

STEPHANIE: I'm curious if you were trying to get at some kind of conclusion, though, with the idea of diminishing returns.

+ +

JOËL: I guess I'm wondering if, from there, we can talk about maybe a breakdown of a particular testing pyramid for a particular test suite is being top heavy, and whether there's value in maybe pushing some of these tests, some of these edge cases, some of these maybe less important features down from that, like, top end-to-end layer into maybe more of an integration layer. So, in a Rails context, that might be moving system specs down to something like a request spec.

+ +

STEPHANIE: Yeah, I think that is what I tend to do. I'm trying to think of how I get there, and I'm not quite sure that I can explain it quite yet. Yeah, I don't know. Do you think you can help me out here? Like, how do you know it's time to start writing more tests for your unhappy paths lower on the pyramid?

+ +

JOËL: Ideally, I think a lot of your code should be unit-tested. And when you are unit testing it, those pieces all need coverage of the happy and unhappy paths. I think the way it may often happen naturally is if you're pushing logic out of your controllers because it's a little bit challenging sometimes to test Rails controllers.

+ +

And so, if you're moving things into domain objects, even service objects, depending on how you implement them, just doing that and then making sure you unit test them can give you a lot more coverage of all the different edge cases that can happen. Where things sometimes fall apart is getting out of that business layer into the web layer and saying, "Hey, if something raises an error or if the save fails or something like that, does the user get a good experience, or do we just crash and give them a 500 page?"

+ +

STEPHANIE: Yeah, that matches with a lot of what I've seen, where if you then spend too much time in that business layer and only handling errors there, you don't really think too much about how it bubbles up. And, you know, then you are digging through, like, your error monitoring [laughs] service, trying to find out what happened so that you can tell, you know, your customer support team [laughs] to help them resolve, like, a bug report they got.

+ +

But I actually think...and you were talking about outside in, but, in some ways, in my experience, I also get feedback from the bottom up sometimes that then ends up helping me adjust some of those integration or end-to-end tests about kind of what errors are possible, like, down in the depths of the code [laughs], and then finding ways to, you know, abstract that or, like, kind of be like, "Oh, like, here are all these possible, like, exceptions that might be raised." Like, what HTTP status code do I want to be returned to capture all of these things? And what do I want to say to the user? So, yeah, I'm [laughs] kind of a little lost myself, but this idea that going both, you know, outside in and then maybe even going back up a little bit has served me well before.

+ +

JOËL: I think there can be a lot of value in sort of dropping down a level in the pyramid, and maybe instead of doing sort of end-to-end tests where you, like, trigger a scenario where something fails, you can just write a request back against the controller and say, "Hey, if I go to this controller and something raises an error, expect that you get redirected to this other location." And that's really cheap to run compared to an end-to-end test. And so, I think that, for me, is often the right compromise is handling error states at sort of the next lowest level and also in slightly more atomic pieces. So, more like, if you hit this endpoint and things go wrong, here's how things happen.

+ +

And I use endpoint not so much in an API sense, although it could be, but just your, you know, maybe you've got a flow that's multiple steps where, you know, you can do a bunch of things. But I might have a test just for one controller action to say, "Hey, if things go wrong, it redirects you here, or it shows you this error page." Whereas the end-to-end test might say, "Oh, you're going to go through the entire flow that hits multiple different controllers, and the happy path is this nice chain." But each of the exit points off at where things fail would be covered by a more scoped request spec on that controller.

+ +

STEPHANIE: Yeah. Yeah. That makes sense. I like that.

+ +

JOËL: So, that's kind of how I've attempted to balance my pyramid in a way that balances complexity and time with coverage. You mentioned that another area that test suites get slow is making too many requests to the database. There's a lot of ways that that happens. Oftentimes, I think a classic is using a factory where you really don't need to, persisting data to the database when all you needed was some object in memory. So, there are different strategies for avoiding that.

+ +

It's also easy to be creating too much data. So, maybe you do need to persist some things in the database, but you're persisting a hundred objects into memory or into the database when you really meant to persist two, so that's an easy accident. A couple of years ago, I gave a talk at RailsConf titled "Your Test Suite is Making Too Many Database Requests" that went over a bunch of different ways that you can be doing a lot of expensive database requests you didn't plan on making and how that slows down your test suite. So, that is also another hot spot that I like to look at when dealing with a slow test suite.

+ +

STEPHANIE: Yeah, I mentioned earlier the idea of unit tests really masquerading as integration tests [laughs]. And I think that happens especially if you're starting with a class that may already be a little bit too big than it should be or have more responsibilities than it should be. And then, you are, like, either just, like, starting with using the create build, like, strategy with factories, or you find yourself, like, not being able to fully run the code path you're trying to test without having stuff persisted.

+ +

Those are all, I think, like, test smells that, you know, are signaling a little bit of a testing anti-pattern that, yeah, like, is there a way to write, like, true unit tests for this stuff where you are only using objects in memory? And does that require breaking out some responsibilities? That is a lot of what I am kind of going through right now, actually, with my little refractoring project [laughs] is backfilling some tests, finding that I have to create a lot of records.

+ +

And you know what? Like, the first step will probably be to write those tests and commit them, and just have them live there for a little while while I figure out, you know, the right places to start breaking things up, and that's okay. But yeah, I did want to, like, just mention that if you are having to create a lot of records and then also noticing, like, your test is running kind of slow [laughs], that could be a good indicator to just give a good, hard look at what kind of style of test you think you're writing [laughs].

+ +

JOËL: Yeah, your tests speak to you, and when you're feeling pain, oftentimes, it can be a sign that you should consider refactoring your implementation. And I think that's doubly true if you're writing tests after the fact rather than test driving. Because sometimes you sort of...you came up with an implementation that you thought would be good, and then you're writing tests for it, and it's really painful. And that might be telling you something about the underlying implementation that you have that maybe it's...you thought it's well scoped, but maybe it actually has more responsibilities than you initially realized, or maybe it's just really tightly coupled in a way that you didn't realize. And so, learning to listen to your tests and not just sort of accepting the world for being the way it is, but being like, "No, I can make it better."

+ +

STEPHANIE: Yeah, I've been really curious why people have a hard time, like, recognizing that pain sometimes, or maybe believing that this is the way it is and that there's not a whole lot that you can do about it. But it's not true, like, testing really does not have to be painful. And I feel like, again, this is one of those things that's like, it's hard to believe until you really experience it, at least, that was the case for me.

+ +

But if you're having a hard time with tests, it's not because you're not smart enough. Like, that, I think, is a thing that I really want to debunk right now [laughs] for anyone who has ever had that thought cross their mind. Yeah, things are just complicated and complex somehow, or software entropy happens. That's, like, not how it should be, and we don't have to accept that [laughs]. So, I really like what you said about, oh, you can change it. And, you know, that is a bit of a callback to the whole mindset of testing that we mentioned earlier at the beginning.

+ +

JOËL: Speaking of test suites, we have not covered yet is paralyzing it. That could probably be its own Bike Shed episode on its own entirely on paralyzing a test suite. We've done entire engagements where our job was to come in and help paralyze a test suite, make it faster. And there's a lot of, like, pros and cons. So, I think maybe we can save that for a different episode. And, instead, I'd like to quickly jump in a little bit to some other common pain points of test suites, and I would say probably top of that list is test flakiness. How do you tend to approach flakiness in a client project?

+ +

STEPHANIE: I am, like, laughing to myself a little bit because I know that I was dealing with test flakiness on my last client engagement, and that was, like, such a huge part of my day-to-day is, like, hitting that retry button. And now that I am on a project with, like, relatively low flakiness, I just haven't thought about it at all [laughs], which is such a privilege, I think [laughs].

+ +

But one of the first things to do is just start, like, capturing metrics around it. If you, you know, are hearing about flakiness or seeing that, like, start to plague your test suite or just, you know, cropping up in different ways, I have found it really useful to start, like, I don't know, just, like, maybe putting some of that information in a dashboard and seeing how, just to, like, even make sure that you are making improvements, that things are changing, and seeing if there's any, like, patterns around what's causing the flakiness because there are so many different causes of it.

+ +

And I think it is pretty important to figure out, like, what kind of code you're writing or just trying to wrangle. That's, you know, maybe more likely to crop up as flakiness for your particular domain or application. Yeah, I'm going to stop there and see, like, because I know you have a lot of thoughts about flakiness [laughs].

+ +

JOËL: I mean, you mentioned that there's a lot of different causes for flakiness. And I think, in my experience, they often sort of group into, let's say, like, three different buckets. Anytime you're testing code that's doing things that are non-deterministic, that's easy for tests to be flaky. And so, you might think, oh, well, you know, you have something that makes a call to random, and then you're going to assert on a particular outcome of that. Well, clearly, that's going to not be the same every time, and that might be flaky.

+ +

But there are, like, more subtle versions of that, so maybe you're relying on the system clock in some way. And, you know, depending on the time you run that test, it might give you a different value than you expect, and that might cause it to fail. And it doesn't have to be you're asserting on, like, oh, specifically a given millisecond. You might be doing math around, like, number of days, and when you get near to, let's say, the daylight savings boundary, all of a sudden, no, you're off by an hour, and your number of days...calculation breaks because relying on the clock is something that is inherently non-deterministic. Non-determinism is a bucket.

+ +

Leaky tests is another bucket of failures that I see, things where one test might impact another that gets run after the fact, oftentimes by mutating some sort of global state. So, maybe you're both relying on some sort of, like, external file that you're both writing to or maybe a cache that one is writing to that the other one is reading from, something like that. It could even just be writing records into the database in a way that's not wrapped in a transaction, such that there's more data in the database when the next test runs than it expects.

+ +

And then, finally, if you are doing any form of parallelization, that can improve your test suite speed, but it also potentially leads to race conditions, where if your resources aren't entirely isolated between parallel test runners, maybe you're sharing a database, maybe you're sharing Redis instance or whatever, then you can run into situations where you're both kind of fighting over the same resources or overriding each other's data, or things like that, in a way that can cause tests to fail intermittently. And I think having a framework like that of categorization can then help you think about potential solutions because debugging approaches and then solutions tend to be a little bit different for each of these buckets.

+ +

STEPHANIE: Yeah, the buckets of different causes of flaky tests you were talking about, I think, also reminded me that, you know, some flakiness is caused by, like, your testing environment and your infrastructure. And other kinds of flakiness are maybe caused more from just the way that you've decided how your code should work, especially that, like, non-deterministic bucket. So, yeah, I don't know, that was just, like, something that I noticed as you were going through the different categories. And yeah, like, certainly, the solutions for approaching each kind are very different.

+ +

JOËL: I would like to pitch a talk from RubyConf last year called "The Secret Ingredient: How To Resolve And Understand Just About Any Flaky Test" by Alan Ridlehoover. Just really excellent walkthrough of these different buckets and common debugging and solving approaches to each of them. And I think having that framework in mind is just a great way to approach different types of flaky tests.

+ +

STEPHANIE: Yes, I'll plus one that talk, lots of great pictures of delicious croissants as well.

+ +

JOËL: Very flaky pastry.

+ +

STEPHANIE: [laughs] Joël, do you have any last testing anti-pattern guidances for our audience who might be feeling some test pain out there?

+ +

JOËL: A quick list, I'm going to say tight coupling that has then led to having a lot of stubbing in your tests often leads to tests that are very brittle, so tests that maybe don't fail when they should when you've actually broken things, or maybe, alternatively, tests that are constantly failing for the wrong reasons. And so, that is a thing that you can fix by making your code less coupled.

+ +

Tests that also require stubbing a lot of things because you do a lot of side effects. If you are making a lot of HTTP calls or things like that, that can both make a test more complex because it has to be aware of that. But also, it can make it more non-deterministic, more flaky, and it can just make it harder to change. And so, I have found that separating side effects from sort of business logic is often a great way to make your test suite much easier to work with.

+ +

I have a blog post on that that I'll link in the show notes. And I think this maybe also approaches the idea of a functional core and an imperative shell, which I believe was an idea pitched by Gary Bernhardt, like, over ten years ago. There's a famous video on that that we'll also link in the show notes. But that architecture for building an app can lead to a much nicer test to write. I guess the general idea being that testing code that does side effects is complicated and painful. Testing code that is more functional tends to be much more pleasant. And so, by not intermingling the two, you tend to get nicer tests that are easier to maintain.

+ +

STEPHANIE: That's really interesting. I've not heard that guidance before, but now I am intrigued. That reminded me of another thing that I had a conversation with someone about. Because after the RailsConf talk I gave, which was about testing pain, there was some stubbing involved in the examples that I was showing because I just see a lot of that stuff. And, you know, this audience member kind of had that question of, like, "How do you know that things are working correctly if you have to stub all this stuff out?"

+ +

And, you know, sometimes you just have to for the time being [chuckles]. And I wanted to just kind of call back to that idea of having those end-to-end tests testing your critical paths to at least make sure that those things work together in the happy way. Because I have seen, especially with apps that have a lot of service objects, for some reason, those being kind of the highest-level test sometimes. But oftentimes, they end up not being composed well, being quite coupled with other service objects. So, you end up with a lot of stubbing of those in your test for them. And I think that's kind of where you can see things start to break down.

+ +

JOËL: Yep. And when the RailsConf videos come out, I recommend seeing Stephanie's talk, some great gems in there for building a more maintainable test suite. Stephanie and I and, you know, most of us here at thoughtbot, we're testing nerds. We think about this a lot. We've also written a lot about this. There are a lot of resources in the show notes for this episode. Check them out. Also, just generally, check out the testing tag on the thoughtbot blog. There is a ton of content there that is worth looking into if you want to dig further into this topic.

+ +

STEPHANIE: Yeah, and if you are wanting some, like, dedicated, customized testing training, thoughtbot offers an RSpec workshop that's tailored to your team. And if you kind of are interested in the things we're sharing, we can definitely bring that to your company as well.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + 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.

+ + + +

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 to clean up this area of the codebase, but you kind of caught on to that bit of, you know, it can go so many different ways. And, like, how do you balance your grand visions [laughs] of things with, I guess, a little bit of pragmatism? So, it was very much like, here's all these bugs that are causing our customers problems that are kind of, like, hard for the devs to troubleshoot. You know, that kind of prompts the question, like, why?

+ +

And so, if there can be, you know, the fixing of the bugs, and then the learning of, like, how that part of the system works, and then, hopefully, some improvements along the way, yeah, that just felt like a dream [laughs] for me. And two weeks felt about the right amount of time. I don't know if anyone kind of hears that and feels like it's too long or too little. I would be really curious. But I feel like it is complex enough that, like, context switching would, I think, make this work harder, and you kind of do have to just sit with it for a little bit to get your bearings.

+ +

JOËL: A scenario that we encounter on a pretty regular basis is a customer coming to us and telling us that they're feeling a lot of test pain and asking what are the ways that we can help them to make things better and that test pain can come under a lot of forms.

+ +

It might be a test suite that's really slow and that's hurting the team in terms of their velocity. It might be a test suite that is really flaky. It might be one that is really difficult to add to, or maybe one that has very low coverage, or one that is just really brittle. Anytime you try to make a change to it, a bunch of things break, and it takes forever to ship anything. So, there's a lot of different aspects of challenging test suites that clients come to us with.

+ +

I'm curious, Stephanie, what are some of the ones that you've encountered most frequently?

+ +

STEPHANIE: I definitely think that a slow test suite and a flaky test suite end up going hand in hand a lot, or just a brittle one, right? That is slowing down development and, like you said, causing a lot of pain. I think even if that's not something that a client is coming to us directly about, it maybe gets, like, surfaced a little bit, you know, sometime into the engagement as something that I like to keep an eye on as a consultant. And I actually think, yeah, that's one of kind of the coolest things, I think, about our consulting work is just getting to see so many different test suites [laughs]. I don't know. I'm a testing nerd, so I love that kind of stuff.

+ +

And then, I think you were also kind of touching on this idea of, like, maintaining a test suite and, yeah, making testing just a better experience. I have a theory [laughs], and I'd be curious to get your thoughts on it. But one thing that I really struggle with in the industry is when people talk about writing tests as if it's, like, the morally superior thing to do. And I struggle with this because I don't think that it is a very good strategy for helping people feel better or more confident and, like, upskill at writing tests.

+ +

I think it kind of shames people a little bit who maybe either just haven't gotten that experience or, you know, just like, yeah, like, for whatever reason, are still learning how to do this thing. And then, I think that mindset leads to bad tests [laughs] or tests that aren't really serving the purpose that you hope they would because people are doing it more out of obligation rather than because they truly, like, feel like it adds something to their work. Okay, I kind of just dropped that on you [laughs]. Do you have any reactions?

+ +

JOËL: Yeah, I guess the idea that you're just checking a box with your test rather than writing code that adds value to the codebase. They're two very different perspectives that, in the end, will generate more lines of code if you're just doing a checkbox but may or may not add a whole lot of value. So, maybe before even looking at actual, like, test practices, it's worth stepping back and asking more of a mindset question: Why does your team test? What is the value that your team feels they get out of testing?

+ +

STEPHANIE: Yeah. Yeah. I like that because I was about to say they go hand in hand. But I do think that maybe there is some, you know, question asking [laughs] to be done because I do think people like to kind of talk about the testing practices before they've really considered that. And I am, like, pretty certain from just kind of, at least what I've seen, and what I've heard, and what I've experienced on embedding into client teams, that if your team can't answer that question of, like, "What value does testing bring?" then they probably aren't following good testing practices [laughs]. Because I do think you kind of need to approach it from a perspective of like, okay, like, I want to do this because it helps me, and it helps my team, rather than, like you said, getting the check mark.

+ +

JOËL: So, once we've sort of established maybe a bit of a mindset or we've had a conversation with the team around what value they think they're getting out of tests, or maybe even you might need to sell the team a little bit on like, "Hey, here's, like, all these different ways that testing can bring value into your life, make your life as developers easier," but once you've done that sort of pre-work and you can start looking at what's actually the problem with a test suite, a common complaint from developers is that the test suite is too slow. How do you like to approach a slow test suite?

+ +

STEPHANIE: That's a good question. I actually...I think there's a lot of ways to answer that. But to kind of stay on the theme of stepping back a little bit, I wonder if assessing how well your test suite aligns with the testing pyramid would be a good place to start; at least, that could be where I start if I'm coming into a client team for the first time, right, and being asked to start assessing or just poking around. Because I think the slowness a lot of the time comes from a lot of quote, unquote, "integration tests" or, like, unit tests masquerading as integration tests, where you end up having, like, a lot of duplication of things that are being tested in ways that are integrating with some slow parts of the system like the database.

+ +

And yeah, I think even before getting into some of the more discreet reasons why you might be writing slow tests, just looking at the structure of your test suite and what kinds of things you're testing, and, again, even going back to your team and asking, like, "What kinds of things do you test?" Or like, "Do you try to test or wish to be testing more of, less of?" Like looking at the structure, I have found to be a good place to start.

+ +

JOËL: And for those who are not familiar, you used the term testing pyramid. This is a concept which says that you probably want to have a lot of small, fast unit tests, a medium amount of integration tests that test a few different components together, and then a few end-to-end tests. Because as you go up that pyramid, tests become more expensive. They take a lot longer to run, whereas the little unit tests are super cheap. You can create thousands of them, and they will barely impact your run time. Adding a dozen end-to-end tests is going to be noticeable. So, you want to balance sort of the coverage that you get from end to end with the sort of cheapness and ubiquity of the little unit tests, and then split the difference for tests that are in between.

+ +

STEPHANIE: And I think that is challenging, even, you know, you're talking about how you want the peak of your pyramid to be end-to-end tests. So, you don't want a lot of them, but you do want some of them to really ensure that things are totally plumbed and working correctly. But that does require, I think, really looking at your application and kind of identifying what features are the most critical to it. And I think that doesn't get paid enough attention, at least from a lot of my client experiences. Like, sometimes teams just end up with a lot of feature bloat and can't say like, you know, they say, "Everything's important [chuckles]," but everything can't be equally important, you know?

+ +

JOËL: Right. I often like to develop using a sort of outside-in approach, where you start by writing an end-to-end test that describes the behavior that your new feature ticket is asking for and use that to drive the work that I'm doing. And that might lead to some lower-level unit tests as I'm building out different components, but the sort of high-level behavior that we're adding is driven by adding an end-to-end spec.

+ +

Do you feel that having one new end-to-end spec for every new feature ticket that you work on is a reasonable thing to do, or do you kind of pick and choose? Do you write some, but maybe start, like, coalescing or culling them, or something like that? How do you manage that idea that maybe you would or would not want one end-to-end spec for each feature ticket?

+ +

STEPHANIE: Yeah, it's a good question. Actually, as you were saying that, I was about to ask you, do you delete some afterwards [laughs]? Because I think that might be what I do sometimes, especially if I'm testing, you know, edge cases or writing, like, the end-to-end test for error states. Sometimes, not all of them make it into my, like, final, you know, commit. But they, you know, had their value, right? And at least it prompted me to make sure I thought about them and make sure that they were good error states, right? Like things that had visible UI to the user about what was going on in case of an error. So, I would say I will go back and kind of coalesce some of them, but they at least give me a place to start. Does that match your experience?

+ +

JOËL: Yeah, I tend to mostly write end-to-end tests for happy paths and then write kind of mid-level things to cover some of my edge cases, maybe a couple of end-to-end tests for particularly critical paths. But, at some point, there's just too many paths through the app that you can't have end-to-end coverage for every single branch on every single path that can happen.

+ +

STEPHANIE: Yeah, I like that because if you find yourself having a lot of different conditions that you need to test in an end-to-end situation, maybe there's room for that to, like, be better encapsulated in that, like, more, like, middle layer or, I don't know, even starting to ask questions about, like, does this make sense with the product? Like, having all of these different things going on, does that line up with kind of the vision of what this feature is trying to be or should be? Because I do think the complexity can start at that high of a level.

+ +

JOËL: How do you feel about the idea that adding more end-to-end tests, at some point, has diminishing returns?

+ +

STEPHANIE: I'm not quite sure I'm following [laughs].

+ +

JOËL: So, let's say you have an end-to-end test for the happy path for every core feature of the app. And you decide, you know what, I want to add maybe some, like, side features in, or maybe I want to have more error states. And you start, like, filling in more end-to-end tests for those. Is it fair to say that adding some of those is a bit of a diminishing return? Like, you're not getting as much value as you would from the original specs. And maybe as you keep finding more and more rare edge cases, you get less and less value for your test.

+ +

STEPHANIE: Oh, yeah, I see. And there's more of a cost, too, right? The cost of the time to run, maintain, whatever.

+ +

JOËL: Right. Let's say they're roughly all equally expensive in terms of cost to run. But as you stray further and further off of that happy path, you're getting less and less value from that integration test or that end-to-end test.

+ +

STEPHANIE: I'm actually a little conflicted about this because that sounds right in theory, but then in practice, I feel like I've seen error states not get enough love [laughs] that it's...I don't even want to say, like, you make any kind of claim [laughs] about it. But, you know, if you're going to start somewhere, if you have, like, a limited amount of time and you're like, okay, I'm only going to write a handful of end-to-end tests, yeah, like, write tests for your happy paths [laughs].

+ +

JOËL: I guess it's probably fair to say that error states just don't get as much love as they should throughout the entire testing stack: at the unit level, at the integration level, all the way up to end to end.

+ +

STEPHANIE: I'm curious if you were trying to get at some kind of conclusion, though, with the idea of diminishing returns.

+ +

JOËL: I guess I'm wondering if, from there, we can talk about maybe a breakdown of a particular testing pyramid for a particular test suite is being top heavy, and whether there's value in maybe pushing some of these tests, some of these edge cases, some of these maybe less important features down from that, like, top end-to-end layer into maybe more of an integration layer. So, in a Rails context, that might be moving system specs down to something like a request spec.

+ +

STEPHANIE: Yeah, I think that is what I tend to do. I'm trying to think of how I get there, and I'm not quite sure that I can explain it quite yet. Yeah, I don't know. Do you think you can help me out here? Like, how do you know it's time to start writing more tests for your unhappy paths lower on the pyramid?

+ +

JOËL: Ideally, I think a lot of your code should be unit-tested. And when you are unit testing it, those pieces all need coverage of the happy and unhappy paths. I think the way it may often happen naturally is if you're pushing logic out of your controllers because it's a little bit challenging sometimes to test Rails controllers.

+ +

And so, if you're moving things into domain objects, even service objects, depending on how you implement them, just doing that and then making sure you unit test them can give you a lot more coverage of all the different edge cases that can happen. Where things sometimes fall apart is getting out of that business layer into the web layer and saying, "Hey, if something raises an error or if the save fails or something like that, does the user get a good experience, or do we just crash and give them a 500 page?"

+ +

STEPHANIE: Yeah, that matches with a lot of what I've seen, where if you then spend too much time in that business layer and only handling errors there, you don't really think too much about how it bubbles up. And, you know, then you are digging through, like, your error monitoring [laughs] service, trying to find out what happened so that you can tell, you know, your customer support team [laughs] to help them resolve, like, a bug report they got.

+ +

But I actually think...and you were talking about outside in, but, in some ways, in my experience, I also get feedback from the bottom up sometimes that then ends up helping me adjust some of those integration or end-to-end tests about kind of what errors are possible, like, down in the depths of the code [laughs], and then finding ways to, you know, abstract that or, like, kind of be like, "Oh, like, here are all these possible, like, exceptions that might be raised." Like, what HTTP status code do I want to be returned to capture all of these things? And what do I want to say to the user? So, yeah, I'm [laughs] kind of a little lost myself, but this idea that going both, you know, outside in and then maybe even going back up a little bit has served me well before.

+ +

JOËL: I think there can be a lot of value in sort of dropping down a level in the pyramid, and maybe instead of doing sort of end-to-end tests where you, like, trigger a scenario where something fails, you can just write a request back against the controller and say, "Hey, if I go to this controller and something raises an error, expect that you get redirected to this other location." And that's really cheap to run compared to an end-to-end test. And so, I think that, for me, is often the right compromise is handling error states at sort of the next lowest level and also in slightly more atomic pieces. So, more like, if you hit this endpoint and things go wrong, here's how things happen.

+ +

And I use endpoint not so much in an API sense, although it could be, but just your, you know, maybe you've got a flow that's multiple steps where, you know, you can do a bunch of things. But I might have a test just for one controller action to say, "Hey, if things go wrong, it redirects you here, or it shows you this error page." Whereas the end-to-end test might say, "Oh, you're going to go through the entire flow that hits multiple different controllers, and the happy path is this nice chain." But each of the exit points off at where things fail would be covered by a more scoped request spec on that controller.

+ +

STEPHANIE: Yeah. Yeah. That makes sense. I like that.

+ +

JOËL: So, that's kind of how I've attempted to balance my pyramid in a way that balances complexity and time with coverage. You mentioned that another area that test suites get slow is making too many requests to the database. There's a lot of ways that that happens. Oftentimes, I think a classic is using a factory where you really don't need to, persisting data to the database when all you needed was some object in memory. So, there are different strategies for avoiding that.

+ +

It's also easy to be creating too much data. So, maybe you do need to persist some things in the database, but you're persisting a hundred objects into memory or into the database when you really meant to persist two, so that's an easy accident. A couple of years ago, I gave a talk at RailsConf titled "Your Test Suite is Making Too Many Database Requests" that went over a bunch of different ways that you can be doing a lot of expensive database requests you didn't plan on making and how that slows down your test suite. So, that is also another hot spot that I like to look at when dealing with a slow test suite.

+ +

STEPHANIE: Yeah, I mentioned earlier the idea of unit tests really masquerading as integration tests [laughs]. And I think that happens especially if you're starting with a class that may already be a little bit too big than it should be or have more responsibilities than it should be. And then, you are, like, either just, like, starting with using the create build, like, strategy with factories, or you find yourself, like, not being able to fully run the code path you're trying to test without having stuff persisted.

+ +

Those are all, I think, like, test smells that, you know, are signaling a little bit of a testing anti-pattern that, yeah, like, is there a way to write, like, true unit tests for this stuff where you are only using objects in memory? And does that require breaking out some responsibilities? That is a lot of what I am kind of going through right now, actually, with my little refractoring project [laughs] is backfilling some tests, finding that I have to create a lot of records.

+ +

And you know what? Like, the first step will probably be to write those tests and commit them, and just have them live there for a little while while I figure out, you know, the right places to start breaking things up, and that's okay. But yeah, I did want to, like, just mention that if you are having to create a lot of records and then also noticing, like, your test is running kind of slow [laughs], that could be a good indicator to just give a good, hard look at what kind of style of test you think you're writing [laughs].

+ +

JOËL: Yeah, your tests speak to you, and when you're feeling pain, oftentimes, it can be a sign that you should consider refactoring your implementation. And I think that's doubly true if you're writing tests after the fact rather than test driving. Because sometimes you sort of...you came up with an implementation that you thought would be good, and then you're writing tests for it, and it's really painful. And that might be telling you something about the underlying implementation that you have that maybe it's...you thought it's well scoped, but maybe it actually has more responsibilities than you initially realized, or maybe it's just really tightly coupled in a way that you didn't realize. And so, learning to listen to your tests and not just sort of accepting the world for being the way it is, but being like, "No, I can make it better."

+ +

STEPHANIE: Yeah, I've been really curious why people have a hard time, like, recognizing that pain sometimes, or maybe believing that this is the way it is and that there's not a whole lot that you can do about it. But it's not true, like, testing really does not have to be painful. And I feel like, again, this is one of those things that's like, it's hard to believe until you really experience it, at least, that was the case for me.

+ +

But if you're having a hard time with tests, it's not because you're not smart enough. Like, that, I think, is a thing that I really want to debunk right now [laughs] for anyone who has ever had that thought cross their mind. Yeah, things are just complicated and complex somehow, or software entropy happens. That's, like, not how it should be, and we don't have to accept that [laughs]. So, I really like what you said about, oh, you can change it. And, you know, that is a bit of a callback to the whole mindset of testing that we mentioned earlier at the beginning.

+ +

JOËL: Speaking of test suites, we have not covered yet is paralyzing it. That could probably be its own Bike Shed episode on its own entirely on paralyzing a test suite. We've done entire engagements where our job was to come in and help paralyze a test suite, make it faster. And there's a lot of, like, pros and cons. So, I think maybe we can save that for a different episode. And, instead, I'd like to quickly jump in a little bit to some other common pain points of test suites, and I would say probably top of that list is test flakiness. How do you tend to approach flakiness in a client project?

+ +

STEPHANIE: I am, like, laughing to myself a little bit because I know that I was dealing with test flakiness on my last client engagement, and that was, like, such a huge part of my day-to-day is, like, hitting that retry button. And now that I am on a project with, like, relatively low flakiness, I just haven't thought about it at all [laughs], which is such a privilege, I think [laughs].

+ +

But one of the first things to do is just start, like, capturing metrics around it. If you, you know, are hearing about flakiness or seeing that, like, start to plague your test suite or just, you know, cropping up in different ways, I have found it really useful to start, like, I don't know, just, like, maybe putting some of that information in a dashboard and seeing how, just to, like, even make sure that you are making improvements, that things are changing, and seeing if there's any, like, patterns around what's causing the flakiness because there are so many different causes of it.

+ +

And I think it is pretty important to figure out, like, what kind of code you're writing or just trying to wrangle. That's, you know, maybe more likely to crop up as flakiness for your particular domain or application. Yeah, I'm going to stop there and see, like, because I know you have a lot of thoughts about flakiness [laughs].

+ +

JOËL: I mean, you mentioned that there's a lot of different causes for flakiness. And I think, in my experience, they often sort of group into, let's say, like, three different buckets. Anytime you're testing code that's doing things that are non-deterministic, that's easy for tests to be flaky. And so, you might think, oh, well, you know, you have something that makes a call to random, and then you're going to assert on a particular outcome of that. Well, clearly, that's going to not be the same every time, and that might be flaky.

+ +

But there are, like, more subtle versions of that, so maybe you're relying on the system clock in some way. And, you know, depending on the time you run that test, it might give you a different value than you expect, and that might cause it to fail. And it doesn't have to be you're asserting on, like, oh, specifically a given millisecond. You might be doing math around, like, number of days, and when you get near to, let's say, the daylight savings boundary, all of a sudden, no, you're off by an hour, and your number of days...calculation breaks because relying on the clock is something that is inherently non-deterministic. Non-determinism is a bucket.

+ +

Leaky tests is another bucket of failures that I see, things where one test might impact another that gets run after the fact, oftentimes by mutating some sort of global state. So, maybe you're both relying on some sort of, like, external file that you're both writing to or maybe a cache that one is writing to that the other one is reading from, something like that. It could even just be writing records into the database in a way that's not wrapped in a transaction, such that there's more data in the database when the next test runs than it expects.

+ +

And then, finally, if you are doing any form of parallelization, that can improve your test suite speed, but it also potentially leads to race conditions, where if your resources aren't entirely isolated between parallel test runners, maybe you're sharing a database, maybe you're sharing Redis instance or whatever, then you can run into situations where you're both kind of fighting over the same resources or overriding each other's data, or things like that, in a way that can cause tests to fail intermittently. And I think having a framework like that of categorization can then help you think about potential solutions because debugging approaches and then solutions tend to be a little bit different for each of these buckets.

+ +

STEPHANIE: Yeah, the buckets of different causes of flaky tests you were talking about, I think, also reminded me that, you know, some flakiness is caused by, like, your testing environment and your infrastructure. And other kinds of flakiness are maybe caused more from just the way that you've decided how your code should work, especially that, like, non-deterministic bucket. So, yeah, I don't know, that was just, like, something that I noticed as you were going through the different categories. And yeah, like, certainly, the solutions for approaching each kind are very different.

+ +

JOËL: I would like to pitch a talk from RubyConf last year called "The Secret Ingredient: How To Resolve And Understand Just About Any Flaky Test" by Alan Ridlehoover. Just really excellent walkthrough of these different buckets and common debugging and solving approaches to each of them. And I think having that framework in mind is just a great way to approach different types of flaky tests.

+ +

STEPHANIE: Yes, I'll plus one that talk, lots of great pictures of delicious croissants as well.

+ +

JOËL: Very flaky pastry.

+ +

STEPHANIE: [laughs] Joël, do you have any last testing anti-pattern guidances for our audience who might be feeling some test pain out there?

+ +

JOËL: A quick list, I'm going to say tight coupling that has then led to having a lot of stubbing in your tests often leads to tests that are very brittle, so tests that maybe don't fail when they should when you've actually broken things, or maybe, alternatively, tests that are constantly failing for the wrong reasons. And so, that is a thing that you can fix by making your code less coupled.

+ +

Tests that also require stubbing a lot of things because you do a lot of side effects. If you are making a lot of HTTP calls or things like that, that can both make a test more complex because it has to be aware of that. But also, it can make it more non-deterministic, more flaky, and it can just make it harder to change. And so, I have found that separating side effects from sort of business logic is often a great way to make your test suite much easier to work with.

+ +

I have a blog post on that that I'll link in the show notes. And I think this maybe also approaches the idea of a functional core and an imperative shell, which I believe was an idea pitched by Gary Bernhardt, like, over ten years ago. There's a famous video on that that we'll also link in the show notes. But that architecture for building an app can lead to a much nicer test to write. I guess the general idea being that testing code that does side effects is complicated and painful. Testing code that is more functional tends to be much more pleasant. And so, by not intermingling the two, you tend to get nicer tests that are easier to maintain.

+ +

STEPHANIE: That's really interesting. I've not heard that guidance before, but now I am intrigued. That reminded me of another thing that I had a conversation with someone about. Because after the RailsConf talk I gave, which was about testing pain, there was some stubbing involved in the examples that I was showing because I just see a lot of that stuff. And, you know, this audience member kind of had that question of, like, "How do you know that things are working correctly if you have to stub all this stuff out?"

+ +

And, you know, sometimes you just have to for the time being [chuckles]. And I wanted to just kind of call back to that idea of having those end-to-end tests testing your critical paths to at least make sure that those things work together in the happy way. Because I have seen, especially with apps that have a lot of service objects, for some reason, those being kind of the highest-level test sometimes. But oftentimes, they end up not being composed well, being quite coupled with other service objects. So, you end up with a lot of stubbing of those in your test for them. And I think that's kind of where you can see things start to break down.

+ +

JOËL: Yep. And when the RailsConf videos come out, I recommend seeing Stephanie's talk, some great gems in there for building a more maintainable test suite. Stephanie and I and, you know, most of us here at thoughtbot, we're testing nerds. We think about this a lot. We've also written a lot about this. There are a lot of resources in the show notes for this episode. Check them out. Also, just generally, check out the testing tag on the thoughtbot blog. There is a ton of content there that is worth looking into if you want to dig further into this topic.

+ +

STEPHANIE: Yeah, and if you are wanting some, like, dedicated, customized testing training, thoughtbot offers an RSpec workshop that's tailored to your team. And if you kind of are interested in the things we're sharing, we can definitely bring that to your company as well.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+q1miYwYm + + ]]> + + Joël Quenneville + Stephanie Minn + + + 429: Transforming Experience Into Growth + https://bikeshed.thoughtbot.com/429 + e1643f75-19b4-4cab-8161-fc2fba176cbc + Tue, 18 Jun 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + 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. + 43:38 + no + + + 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've created, being something really helpful. That being said, I've never DM'd myself, so I have no idea what it actually is like to be on the other side of that screen. +STEPHANIE: Cool. I mean, if you ever do try that or have a DM experience and you're like, hmm, I wonder kind of how I might be able to help me here, I bet that would be a very cool experience to share on the show. +JOËL: I definitely have to report back here. +Something that I've been thinking about a lot recently is the difference between sort of professional growth and experience, so the time that you put into doing work. Particularly maybe because, you know, we spend part of our week doing client work, and then we have part of the week that's dedicated to maybe more directly professional growth: our investment day. How do we grow from that, like, four days a week where we're doing client work? Because not all experience is created equal. +Just because I put in the hours doesn't mean that I'm going to grow. And maybe I'm going to feel like I'm in a rut. So, how do I take those four days a week that I'm doing code and transform that into some sort of growth or expansion of my knowledge as a developer? Do you have any sort of tactics that you like to use or ways you try to be a little bit more mindful of that? +STEPHANIE: Yeah, this is a fun question for me, and kind of reminds me of something we've talked a little bit about before. I can't remember if it was, like, on air or just separately, but, you know, we talk a lot about, like, different learning strategies on the show, I think, because that's just something you and I are very into. And we often, like, lean on, you know, our investment day, so our Fridays that we get to not do client work and kind of dedicate to professional development. +But you and I also try to remember that, like, most people don't have that. And most people kind of are needing to maybe find ways to just grow from the day-to-day work that they do, and that is totally possible, I think. And some of the strategies that I have are, I guess, like, it is really...it can be really challenging to, like, you know, be like, okay, I spent 40 hours doing this, and like, what did I learn [chuckles]? Feeling like you have to have something to show for it or something to point to. +And one thing that I've been really liking is these automated check-ins we have at the end of the week. And, you know, I suspect that this is not that uncommon for just, like, a workplace to be like, "Hey, like, how did your week go? Like, what are some ways that it was successful? Like, what are your challenges? Like, where do you need support or help?" And I think I've now started using that as both, like, space for giving an update on just, like, business-y things. Like, "Here's the status of this project," or, like, "Here's, you know, a roadblock that we faced that took some extra time," or whatever. +Then also being like, oh, this is a great time to make this space for myself, especially because...I don't know about you, but whenever I have, like, performance review time and I have to write, like, a self-review, I'm just like, did I do anything in the last six months [laughs], or how have I grown in the last six months? It feels like such a big question, kind of like you were talking about that blank page syndrome a little bit. +But if I have kind of just put in the 10 minutes during my Friday to be like, is there something that was kind of just for me that I can say in my check-in? I can go back and, yeah, just kind of start to see just, like, you know, pick out or just pay attention to how, like, my 40 hours is kind of serving me in growing in the ways that I want to and not just to deliver code [laughs]. +JOËL: What you're describing there, that sort of weekly check-in and taking notes, reminds me of the practice of journaling. Is that something that you've ever tried to do in your, like, regular life? +STEPHANIE: Oh yeah, very much so. But I'm not nearly as, like, routine about it in my personal life. But I suspect that the routine is helpful in more of a, like, workplace setting, at least for me, because I do have, like, more clear pathways of growth that I'm interested in or just, like, something that, I don't know, not that it's, like, expected of everyone, but if that is part of your goals or, like, part of your company's culture, I feel like I benefit from that structure. And yeah, I mean, I guess maybe that's kind of my way of integrating something that I already do in my personal life to an environment where, like I said, maybe there is, like, that is just part of the work and part of your career progression. +JOËL: I'm curious about the frequency. You mentioned that you sort of do this once a week, sort of a check-in at the end of the week. Do you find that once a week is about the right frequency versus maybe something like daily? I know a lot of these sort of more modern note-taking systems, Roam Research, or Obsidian, or whatever, have this concept of, like, a daily note that's supposed to encourage something that's kind of like journaling. Have you ever tried something more on a daily basis, or do you feel like a week is about...or once a week is about the right cadence for you? +STEPHANIE: Listen, I have, like, complicated feelings about this because I think the daily note is so aspirational for me [laughs] and just not how I work. And I have finally begrudgingly come to accept this no matter how much, like, I don't know, like, bullet journal inspirational content I consume on the internet [laughs]. I have tried and failed many a time to have more frequency in that way. But, I don't know, I think it almost just, like, sets me up for failure [laughs] because I have these expectations. +And that's, like, the other thing. It's like, you can't force learning necessarily. I don't know if this is, like, a strategy, but I think there is some amount of, like, making sure that I'm in the right headspace for it and, you know, like, my environment, too, kind of is conducive to it. Like, I have, like, the time, right? If I'm trying to squeeze in, I don't know, maybe, like, in between meetings, 20 minutes to be like, what did I learn from this experience? Nothing's coming out [laughs]. +That was another thing that I was kind of mulling over when he had this topic proposed is this idea of, like, mindset and environment being really important because you know when you are saying, like, not all time is created equal, and I suspect that if, you know, either you or, like, the people around you and the environment you're in is not also facilitating growth, and, like, how much can you really expect for it to be happening? +JOËL: I mean, that's really interesting, right? The impact of sort of a broader company culture. And I think that definitely can act as a catalyst for growth, either to kind of propel you forward or to pull you back. +I want to dig into a little bit something you were saying about being in the right headspace to capture ideas. And I think that there's sort of almost, like, two distinct phases. There's the, like, capturing data, and information, and experiences, and then, there's synthesizing it, turning information into learning. +STEPHANIE: Yes. +JOËL: And it sounds like you're making a distinction between those two things, specifically that synthesis step is something that has to happen separately. +STEPHANIE: Ooh, I don't even...I don't know if I would necessarily say that I'm only talking about synthesis, but I do like that you kind of separated those categories because I do think that they are really important. And they kind of remind me a lot about the scientific method a little bit where, you know, you have the gathering data and, like, observations, and you have, you know, maybe some...whatever is precipitating learning that you're doing maybe differently or new. +And that also takes time, I think, or intention at least, to be like, oh, do I have what I need to, like, get information about how this is going? And then, yeah, that synthesis step that I think I was talking about a little bit more. But I don't think either is just automatic. There is, I think, quite a bit of intention involved. +JOËL: I think maybe the way I think about this is colored by reading some material on the Zettelkasten method of note-taking, which splits up the idea of fleeting notes and literature notes, which are sort of just, like, jotting down ideas, or things you've seen, things that you've learned, maybe a thought you had when you read a particular paragraph in a blog post, something like that. +And then, the permanent notes, which are more, like, fully formed thoughts that arise out of the more fleeting ones. And so, the idea is that the fleeting ones maybe you're taking those in a notebook if you're doing it pen and paper. You could be doing it in some sort of, like, daily note, or something like that. And then, those are temporary. They were there to just capture information. Later on, you process that, and then you can throw them out if you need to. +STEPHANIE: Yeah, that makes a lot of sense. This has actually been a shift for me, where I used to rely a lot more on memory and perhaps, like, didn't have a great system for taking things like fleeting notes and, like, documenting kind of [inaudible 18:28] what I was saying earlier about how do I make sure that the information is recorded, you know, for me to synthesize later? And I have found a lot more success lately in that fleeting note style of operating. And thanks to Obsidian honestly, now it's so easy to be like, oh, I'm just going to open a quick new file. And I need as little friction as possible to, like, put stuff somewhere [laughs]. +And, actually, I'm excited to talk a little bit more about this with you because I think you're a little bit different where you somehow find the time [laughs] and care to create your diagrams. I'm like, if I can, for some reason, even get an Obsidian file open, I'll tab to Slack. And I send myself a lot of notes in my just own personal DM space. In fact, it's actually kind of embarrassing because I use the Command+K shortcut to navigate to my own personal DMs, which you can get to by typing me, like, M-E. +And sometimes I've accidentally just entered that into a channel chat [laughs], and then I have to delete it really quick later when I realize what I've done. So, yeah, like, I meant to navigate to my personal notes, and I just put in our team chat, "Me [laughs]." And, I don't know, I have no idea how that comes up [laughs], what people think is going on. But if anyone's listening to this podcast from thoughtbot and has seen that of me, that's what happened. +JOËL: You may not be the only one who's done that. +STEPHANIE: Thank you. Yeah [laughs], that's good to know. +JOËL: I want to step back a little bit because we've been talking about, like, introspection, and synthesis, and finding moments to capture information. And I think we've sort of...there's an unspoken assumption here that a way to kind of turbocharge learning from day-to-day experience is some form of synthesis or self-reflection. Would you agree with that statement? +STEPHANIE: Okay. This is another thing that I am perhaps, like, still trying to figure out, and we can figure it out together, which is separating, like, self-driven learning and, like, circumstance-driven learning. Because it's so much easier to want to reflect on something and find time to be, like, oh, like, how does this kind of help my goals or, like, what I want to be doing with my work? Versus when you are just asked to do something, and it could still be learning, right? It could still be new, and you need to go do some research or, you know, play around with a new tool. But there's less of that internal motivation or, like, kind of drive to integrate it. Like, do you have this distinction? +JOËL: I've definitely noticed that when there is motivation, I get more out of every hour of work that I put in in terms of learning new things. The more interest, the more motivation, the more value I get per unit of effort I put in. +STEPHANIE: Yeah. I think, for me, the other difference is, like, generative learning versus just kind of absorbing information that's already out there that someone else's...that is kind of, yeah, just absorbing rather than, like, creating something new from, like, those connections. +JOËL: Ooh. +STEPHANIE: Does that [chuckles] spark something for you? +JOËL: The gears are turning in my head because I'm almost hearing that as, like, a passive versus active learning thing. But just sort of like, I'm going to let things happen to me, and I will come out of that with some experience, and something is going to happen. Versus an active, I am going to, like, try to move in a direction and learn from that and things like that. +And I think this maybe connects back to the original question. Maybe this sort of, like, checking in at the end of the week, taking notes is a way to convert something that's a bit more of a passive experience, spending four days a week doing a project for a client, into something that's a little bit of a more active learning, where you say, "Okay, I did four weeks of this particular type of Rails work. What do I get out of it? What have I learned? What is something new that I've seen? What are some opinions I have formed, patterns I like or dislike?" +STEPHANIE: Yeah, I like that distinction because, you know, a few weeks ago, we were at RailsConf. We had kind of recapped it in a previous episode. And I think we had talked about like, oh, do we, like, to sit in talks or participate in workshops? And I think that's also another example of, like, passive versus active, right? Because I 100%, like, don't have the same type of learning by just, you know, listening to a talk that I do with maybe then going to look up, like, other things this person has put out in the world, finding them to talk to them about it, like, doing something with the content, right? Otherwise, it's just like, oh yeah, I heard this talk. Maybe one day I'll remember it when the need arises [laughs]. I, like, have a pointer to it in my brain. But until then, it probably just kind of, like, sits there, and nothing's really happened with it. +JOËL: I think maybe another thing that's interesting in that passive versus active distinction is that synthesis is inherently an act of creation. You are now creating new ideas of your own rather than just capturing information that is being thrown at you, either by sitting in a talk or by shipping tickets. The act of synthesizing and particularly, I think, making connections between ideas, either because something that, let's say you're in a talk, a speaker said that sparks an idea for yourself, or because you can connect something that speaker said with another idea that you already have or an idea that you've seen elsewhere. +So, you're like, oh, the thing this person is saying connects to this thing I read in a book or something another speaker said in an earlier session, or something like that. All of a sudden, now you're creating these new bits of knowledge, new perspectives, maybe even new mental models. We talked about mental models last week. And so, knowledge is not just the facts that you absorb or memorize. A lot of it is building the connections between those facts. And those are things that are not always given to you. You have to create them yourself. +STEPHANIE: Yeah, I am nodding my head a lot because that's resonating with, like, an experience that I'm having kind of coaching and mentoring a client developer on my team who is earlier in her career. And one thing that I've been really, like, working on with her is asking like, "Oh, like, what do you think of this?" Or like, "Have you seen this before? What are your reactions to this code, or, like this comment?" or whatever. +And I get the sense that, like, not a lot of people have prompted her to, like, come up with answers for those kinds of questions. And I'm really, really hopeful that, like, that kind of will help her achieve some of the goals that she's, like, hoping for in terms of her technical growth, especially where she's felt like she's stagnated a little bit. +And I think that calls back really well to what you said at the beginning of, like, you can spend years, right? Just kind of plugging away. But that's not the same as that really active growth. And, again, like, that's fine if that's where you're at or want to be at for a little while. But I suspect if anyone is kind of, like, wondering, like, where did that time go [laughs]...even for me, too, like, once someone started asking me those questions, I was like, oh, there's still so much to figure out or explore. +And I think you're actually really good at doing that, asking questions of yourself. And then, another thing that I've picked up from you is you ask questions about, like, what are questions other people would have? And that's a skill that I feel like I still have yet to figure out. I'm [chuckles] curious what you think about that. +JOËL: That's interesting because that kind of goes to another level. I often think of the questions other people would have from a more, like, pedagogical sense. So, I write a lot of blog posts. I write a lot of talks that I give. So, oftentimes when I'm creating that kind of material, there's a bit of an inner critic who's trying to, you know, sitting in the audience listening to myself speak, and who's going to maybe roll their eyes at certain points, or just get lost, or maybe raise their hand with a question. And that's who I try to address those things so that then when I go through it the next time, that inner critic is actually feeling engaged and paying attention. +STEPHANIE: Do you find that you're able to do that because you've seen that happen enough times where you're like, oh, I can kind of predict maybe what someone might feel confused about? I'm curious, like, how you got from being, like, well, I know what I would be confused about to what would someone else be unsure or, like, want more information about. +JOËL: Part of the answer there is that I'm a very harsh critic myself. +STEPHANIE: [laughs] Yes. +JOËL: So, I'm sitting in somebody else's talk, and there are probably parts where I'm rolling my eyes or being like, wait a minute, how did you get from this idea to this other thing? That doesn't follow. And so, I try to turn that back towards myself and use that as fuel to make my own work better. +STEPHANIE: Yeah, that's cool. I like that. Even if it's just framed as, like, a missed opportunity for people to have better or more comprehensive understanding. I know that's something that you're, like, very motivated to help kind of spread more of [laughs]. Understanding and learning is just important to you and to me. So, I think that's really cool that you're able to find ways to do that. +JOËL: Well, you definitely want to, I think, to keep a sort of beginner's mindset for a lot of these things, and one of the best ways to do that is to work with beginners. So, I spent a lot of time, back in the day, for example, in the Elm language chat room, just helping people answer basic questions, looking up documentation, explaining sort of basic concepts. +And that, I think, helped me get a sense of like, where were newcomers to the language getting stuck? And what were the explanations of those concepts that really connected? Which I could then translate into my work. And I think that that made me a better developer and helped me build this, like, really deep understanding of the underlying concepts in a way that I wouldn't have had just writing code on my own. +STEPHANIE: Wow, forum question answering hero. I have never thought to do that or felt compelled to do that. But I remember my friend was telling me, she was like, "Yeah, sometimes I just want to feel good about myself. And I remember that I know things that other people, like, are wanting to find out," and she just will answer some easy questions on Stack Overflow, you know, about, like, basic Rails stuff or something. And she is like, "Yeah, and that's doing my good deed [laughs]." And yeah, I think that it also, you know, has the same benefits that you were just saying earlier about...because you want to be helpful, you figure out how to actually be helpful, right? +JOËL: There's maybe a sense as well that helping others, once more, forces you into more of an active mindset for growth in the same way that interrogating yourself does, except now it's a beginner who's interrogating you. And so, it forces you to think a little bit more about those whys or those places where people get stuck. And you've just sort of assumed it's a certain way, but now you have to, like, explain it and really get into some of the concepts. +STEPHANIE: So, on the show, we've talked a lot about the fun things you share in the dev channel in our Slack workspace. But I recently discovered that someone (Was it you?) created an Obsidian MD channel for our favorite note-taking software. And in it, you shared a really cool tool that is available in Obsidian called mind maps. +JOËL: Yeah, so mind maps are a type of diagram. They're effectively a tree structure, but they don't really look like that when you draw them out. You start with a sort of topic in the center, and then you just keep drawing branches off of that, going every direction. And then, maybe branches off branches and keep going as you add more content. Turns out that Mermaid.js supports mind maps as a graph type, and Obsidian embeds Mermaid diagrams. So, you can use Mermaid's little language to express a mind map. And now, all of a sudden, you have mind mapping as a tool available for you within Obsidian. +STEPHANIE: And how have you been using that to kind of process and experience or maybe, like, end up with some artifacts from, like, something that you're just doing in regular day-to-day work? +JOËL: So, kind of like you, I think I have the aspiration of doing some kind of, like, daily note journaling thing and turning that into bigger ideas. In practice, I do not do that. Maybe that's the thing that I will eventually incorporate into my practice, but that's not something that I'm currently doing. Instead, a thing that I've done is a little bit more like you, but it's a little bit more thematically chunked. So, for example, recently, I did several weeks of work that involved doing a lot of documentation for module-level documentation. +You know, I'd invested a lot of time learning about YARD, which is Ruby's documentation system, and trying to figure out, like, what exactly are docs that are going to be helpful for people? And I wanted that to not just be a thing I did once and then I kind of, like, move on and forget it. I wanted to figure out how can I sort of grow from that experience maximally? And so, the approach I took is to say, let's take some time after I've completed that experience and actually sort of almost interrogate it, ask myself a bunch of questions about that experience, which will then turn into more broad ideas. +And so, what I ended up doing is taking a mind-mapping approach. So, I start that center circle is just a circle that says, "My experience writing docs," and then I kind of ring it with a series of questions. So, what are questions that might be interesting to ask someone who just recently had experience writing documentation? And so, I come up with 4,5,6 questions that could be interesting to ask of someone who had experience. And here I'm trying to step away from myself a little bit. +And then, maybe I can start answering those questions, or maybe there are sub-questions that branch off of that. And maybe there are answers, or maybe there are answers that are interesting but that then trigger follow-up questions. And so I'm almost having a conversation with myself and using the mind map as a tool to facilitate that. But the first step is putting that experience in the center and then ringing it with questions, and then kind of seeing where those lead. +STEPHANIE: Cool. Yeah, I am, like, surprised that you're still following that thread because the module docs experience was quite a little bit a while ago now. We even, you know, had an episode on it that I'll link in the show notes. +How do you manage, like, learning new things all the time and knowing what to, like, invest energy and attention into and what to kind of maybe, like, consider just like, oh, like, I don't know, that was just an experience that I had, and I might not get around to doing anything with it? +JOËL: I don't know that I have a great system. I think sometimes when I do, especially a more prolonged chunk of time doing a thing, I find it really worthwhile to say, hey, I don't want that to sort of just be a thing that was in my memory, and then it moves out. I'd like to pull out some more maybe practical or long-term ideas from it. Part of that is capture, but some of that is also synthesis. +I just spent two weeks or I just spent a month using a particular technology or doing a new kind of task. What do I have to show for it? Are there any, like, bigger ideas that I have here? Does this connect with any other technologies I've done or any other ideas or theories? Did I come up with any opinions? Did I like this technology? Did I not? Are there elements that were inspirational? +And then capturing some of that eventually with the idea of...so I do a sort of Zettelkasten-style permanent note collection, the idea to create at least a few of those based off of the experience that I can then connect to other things. And maybe it eventually turns into other content. Maybe it's something I hold onto for a while. In the case of the module docs, it turned into a Bike Shed episode. It also turned into a blog post that was published this past week. And so, it does have a way of coming back. +STEPHANIE: Yeah. Yeah. One thing that sparked for me was that, you know, you and I spend a lot of time thinking about, like, the practice of writing software, you know, in the work we do as consultants, too. But I find that, like, you can also apply this to the actual just your work that you are getting paid for [laughs]. This was, I think, a nascent thought in the talk that I had given. But there's something to the idea of, like, you know, if you are working in some code, especially legacy code, for a long time, and you learn so much about it, and then what do you have to show for it [chuckles], you know? +I have really struggled with feeling like all of that work and learning was useful if it just, like, remains in my memory and not necessarily shared with the team or, I don't know, just, like, knowing that if I leave, especially since I am a contractor, like, just recognizing that there's value in being like, oh, I spent an hour or, like, half a day sifting through this complex legacy code just to make, like, a small change. But that small change is not the full value of all of the work that I did. And I suspect that, like, just the mind mapping stuff would be really interesting to apply to more. It's not, like, just practical work, but, like, more mundane, I don't know, like, labor [laughs], if you will. +JOËL: I can think of, like, sort of two types of knowledge that you can take out of something like that. Some of it is just understanding how this legacy system works, saying, oh, well, they have this user model that's connected to this old persona table, which is kind of unused, but we sometimes rely for in this legacy case. And you've got to have this permission flag turned on and, like, all those things that you had to just discover by reading the code and exploring. And that's going to be useful to you as long as you work in that legacy codebase, as long as you work through that path. But when you move on to another project, that knowledge probably doesn't serve you a whole lot. +There are things that you did throughout that journey, though, that you can probably pull out that are going to be useful to you on other projects. And that might be maybe you came up with a new way of navigating the code or a new way of, like, finding how different pieces were connected. Maybe it was a diagramming tool; maybe it was some sort of gem. Maybe it was just a, oh, a heuristic, like, when I see a model, I like to follow the associations first. And I always go for the hasmanys over the belongstos because those generally lead me in the right direction. Like, that's really interesting insight, and that's something that might serve you on a following project. +You can also pull out bigger things like, are there refactoring techniques that you experimented with or that you learned on this project that you would use again elsewhere? Are there ways of maybe quarantining scary code on a legacy project that are a thing that you would want to make more consistent part of your practice? Those are all great things to pull out of, just a like, oh yeah, I did some work on a, like, old legacy part of an app. And what do I have to show for it? I think you can actually have a lot to show for it. +STEPHANIE: Yeah, that's really cool. That sounds like a sure way of multiplying the learning. And I think I didn't really consider that when I was first talking about it, too. But yeah, there are, like, both of those things kind of available to you to, like, learn from. Yeah, it's like, that time is never just kind of, like, purely wasted. Oh, I don't know, sometimes it really feels like that [laughs] when you are debugging something really silly. +But yeah, like, I would be interested in kind of thinking about it from both of those lenses because I think there's value in what you learn about that particular system in that moment of time, even if it might not translate to just future works or future projects. And, like, that's something that I think we would do better at kind of capturing, and also, there's so much stuff, too, kind of to that higher level growth that you were speaking to. +JOËL: I think some of the distinctions we're talking about here is something that was explored in an older episode on note-taking with Amanda Beiner, where we sort of explored the difference between exploratory notes, debugging notes, idea notes, and how note-taking is not a single thing. It can serve many purposes, and they can have different lifespans. And those are all just ways to aid your thinking. But being maybe aware of the kind of thinking that you're trying to do, the kind of notes you're trying to take can help you make better use of that time. +STEPHANIE: I have one last question for you before we wrap up, which is, do you find, like, the stuff we're talking about to be particularly true about software development, or it just happens to be the thing that you and I both do, and we also love to learn, and so, therefore, we are able to talk about this for, like, 50 minutes [laughs]? Are you able to make any kind of distinction there, or is it just kind of part of pedagogy in general? +JOËL: I would say that that sort of active versus passive thing is a thing that's probably true, just about anything that you do. For example, I do a lot of bouldering. Just going spending a lot of time on the wall, climbing a lot; that's going to help me get better. But a classic way that people try to improve is filming themselves or having a friend film themselves, and then you can look at it, and then you evaluate, oh, that's what I did. This is where I was struggling to get the next hold. What if I try to do something different? +So, building in an amount of, like, self-reflection into the loop all of a sudden catalyzes that learning and helps you grow at a rate that's much more than if you're just kind of mindlessly putting time into it. So, I would go so far as to say that self-reflection, synthesis—those are all things that are probably going to catalyze growth in most areas of your life if you're being a little bit more self-aware. But I've found that it's been particularly useful for me when it comes to trying to get better at the job that I do every week. +STEPHANIE: Yeah, I think, for me, it's like, yeah, getting better at being a developer rather than being, you know, a software developer at X company. Like, not necessarily just getting better at working at that company but getting better at the skill itself. +JOËL: And those two things have a way of sort of, like, folding back into themselves, right? If you're a better software developer in general, you will probably be a better developer at that company. Yes, you want domain knowledge and, like, a deep understanding of how the system works is going to make you a better developer at that company. But also, if you're able to find more generic approaches to onboard onto new things, or to debug more effectively, or to better read or understand unknown code of high complexity, those are all going to make you much better at being a developer at that company as well. And they're transferable skills, so they're all really good things to have. +STEPHANIE: On that note. Shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + The Bike Shed, podcast, software development, urban foraging, serviceberries, Chicago, Dungeons & Dragons, AI, artificial intelligence, character creation, professional growth, note-taking, Obsidian, mind maps, self-reflection, learning strategies, professional development, coding, YARD documentation, Elm language, bouldering, active learning, passive learning, creative process, ChatGPT, thoughtbot, RailsConf, client work, synthesis, legacy code, coding practices + + 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.

+ + + +

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've created, being something really helpful. That being said, I've never DM'd myself, so I have no idea what it actually is like to be on the other side of that screen.

+ +

STEPHANIE: Cool. I mean, if you ever do try that or have a DM experience and you're like, hmm, I wonder kind of how I might be able to help me here, I bet that would be a very cool experience to share on the show.

+ +

JOËL: I definitely have to report back here.

+ +

Something that I've been thinking about a lot recently is the difference between sort of professional growth and experience, so the time that you put into doing work. Particularly maybe because, you know, we spend part of our week doing client work, and then we have part of the week that's dedicated to maybe more directly professional growth: our investment day. How do we grow from that, like, four days a week where we're doing client work? Because not all experience is created equal.

+ +

Just because I put in the hours doesn't mean that I'm going to grow. And maybe I'm going to feel like I'm in a rut. So, how do I take those four days a week that I'm doing code and transform that into some sort of growth or expansion of my knowledge as a developer? Do you have any sort of tactics that you like to use or ways you try to be a little bit more mindful of that?

+ +

STEPHANIE: Yeah, this is a fun question for me, and kind of reminds me of something we've talked a little bit about before. I can't remember if it was, like, on air or just separately, but, you know, we talk a lot about, like, different learning strategies on the show, I think, because that's just something you and I are very into. And we often, like, lean on, you know, our investment day, so our Fridays that we get to not do client work and kind of dedicate to professional development.

+ +

But you and I also try to remember that, like, most people don't have that. And most people kind of are needing to maybe find ways to just grow from the day-to-day work that they do, and that is totally possible, I think. And some of the strategies that I have are, I guess, like, it is really...it can be really challenging to, like, you know, be like, okay, I spent 40 hours doing this, and like, what did I learn [chuckles]? Feeling like you have to have something to show for it or something to point to.

+ +

And one thing that I've been really liking is these automated check-ins we have at the end of the week. And, you know, I suspect that this is not that uncommon for just, like, a workplace to be like, "Hey, like, how did your week go? Like, what are some ways that it was successful? Like, what are your challenges? Like, where do you need support or help?" And I think I've now started using that as both, like, space for giving an update on just, like, business-y things. Like, "Here's the status of this project," or, like, "Here's, you know, a roadblock that we faced that took some extra time," or whatever.

+ +

Then also being like, oh, this is a great time to make this space for myself, especially because...I don't know about you, but whenever I have, like, performance review time and I have to write, like, a self-review, I'm just like, did I do anything in the last six months [laughs], or how have I grown in the last six months? It feels like such a big question, kind of like you were talking about that blank page syndrome a little bit.

+ +

But if I have kind of just put in the 10 minutes during my Friday to be like, is there something that was kind of just for me that I can say in my check-in? I can go back and, yeah, just kind of start to see just, like, you know, pick out or just pay attention to how, like, my 40 hours is kind of serving me in growing in the ways that I want to and not just to deliver code [laughs].

+ +

JOËL: What you're describing there, that sort of weekly check-in and taking notes, reminds me of the practice of journaling. Is that something that you've ever tried to do in your, like, regular life?

+ +

STEPHANIE: Oh yeah, very much so. But I'm not nearly as, like, routine about it in my personal life. But I suspect that the routine is helpful in more of a, like, workplace setting, at least for me, because I do have, like, more clear pathways of growth that I'm interested in or just, like, something that, I don't know, not that it's, like, expected of everyone, but if that is part of your goals or, like, part of your company's culture, I feel like I benefit from that structure. And yeah, I mean, I guess maybe that's kind of my way of integrating something that I already do in my personal life to an environment where, like I said, maybe there is, like, that is just part of the work and part of your career progression.

+ +

JOËL: I'm curious about the frequency. You mentioned that you sort of do this once a week, sort of a check-in at the end of the week. Do you find that once a week is about the right frequency versus maybe something like daily? I know a lot of these sort of more modern note-taking systems, Roam Research, or Obsidian, or whatever, have this concept of, like, a daily note that's supposed to encourage something that's kind of like journaling. Have you ever tried something more on a daily basis, or do you feel like a week is about...or once a week is about the right cadence for you?

+ +

STEPHANIE: Listen, I have, like, complicated feelings about this because I think the daily note is so aspirational for me [laughs] and just not how I work. And I have finally begrudgingly come to accept this no matter how much, like, I don't know, like, bullet journal inspirational content I consume on the internet [laughs]. I have tried and failed many a time to have more frequency in that way. But, I don't know, I think it almost just, like, sets me up for failure [laughs] because I have these expectations.

+ +

And that's, like, the other thing. It's like, you can't force learning necessarily. I don't know if this is, like, a strategy, but I think there is some amount of, like, making sure that I'm in the right headspace for it and, you know, like, my environment, too, kind of is conducive to it. Like, I have, like, the time, right? If I'm trying to squeeze in, I don't know, maybe, like, in between meetings, 20 minutes to be like, what did I learn from this experience? Nothing's coming out [laughs].

+ +

That was another thing that I was kind of mulling over when he had this topic proposed is this idea of, like, mindset and environment being really important because you know when you are saying, like, not all time is created equal, and I suspect that if, you know, either you or, like, the people around you and the environment you're in is not also facilitating growth, and, like, how much can you really expect for it to be happening?

+ +

JOËL: I mean, that's really interesting, right? The impact of sort of a broader company culture. And I think that definitely can act as a catalyst for growth, either to kind of propel you forward or to pull you back.

+ +

I want to dig into a little bit something you were saying about being in the right headspace to capture ideas. And I think that there's sort of almost, like, two distinct phases. There's the, like, capturing data, and information, and experiences, and then, there's synthesizing it, turning information into learning.

+ +

STEPHANIE: Yes.

+ +

JOËL: And it sounds like you're making a distinction between those two things, specifically that synthesis step is something that has to happen separately.

+ +

STEPHANIE: Ooh, I don't even...I don't know if I would necessarily say that I'm only talking about synthesis, but I do like that you kind of separated those categories because I do think that they are really important. And they kind of remind me a lot about the scientific method a little bit where, you know, you have the gathering data and, like, observations, and you have, you know, maybe some...whatever is precipitating learning that you're doing maybe differently or new.

+ +

And that also takes time, I think, or intention at least, to be like, oh, do I have what I need to, like, get information about how this is going? And then, yeah, that synthesis step that I think I was talking about a little bit more. But I don't think either is just automatic. There is, I think, quite a bit of intention involved.

+ +

JOËL: I think maybe the way I think about this is colored by reading some material on the Zettelkasten method of note-taking, which splits up the idea of fleeting notes and literature notes, which are sort of just, like, jotting down ideas, or things you've seen, things that you've learned, maybe a thought you had when you read a particular paragraph in a blog post, something like that.

+ +

And then, the permanent notes, which are more, like, fully formed thoughts that arise out of the more fleeting ones. And so, the idea is that the fleeting ones maybe you're taking those in a notebook if you're doing it pen and paper. You could be doing it in some sort of, like, daily note, or something like that. And then, those are temporary. They were there to just capture information. Later on, you process that, and then you can throw them out if you need to.

+ +

STEPHANIE: Yeah, that makes a lot of sense. This has actually been a shift for me, where I used to rely a lot more on memory and perhaps, like, didn't have a great system for taking things like fleeting notes and, like, documenting kind of [inaudible 18:28] what I was saying earlier about how do I make sure that the information is recorded, you know, for me to synthesize later? And I have found a lot more success lately in that fleeting note style of operating. And thanks to Obsidian honestly, now it's so easy to be like, oh, I'm just going to open a quick new file. And I need as little friction as possible to, like, put stuff somewhere [laughs].

+ +

And, actually, I'm excited to talk a little bit more about this with you because I think you're a little bit different where you somehow find the time [laughs] and care to create your diagrams. I'm like, if I can, for some reason, even get an Obsidian file open, I'll tab to Slack. And I send myself a lot of notes in my just own personal DM space. In fact, it's actually kind of embarrassing because I use the Command+K shortcut to navigate to my own personal DMs, which you can get to by typing me, like, M-E.

+ +

And sometimes I've accidentally just entered that into a channel chat [laughs], and then I have to delete it really quick later when I realize what I've done. So, yeah, like, I meant to navigate to my personal notes, and I just put in our team chat, "Me [laughs]." And, I don't know, I have no idea how that comes up [laughs], what people think is going on. But if anyone's listening to this podcast from thoughtbot and has seen that of me, that's what happened.

+ +

JOËL: You may not be the only one who's done that.

+ +

STEPHANIE: Thank you. Yeah [laughs], that's good to know.

+ +

JOËL: I want to step back a little bit because we've been talking about, like, introspection, and synthesis, and finding moments to capture information. And I think we've sort of...there's an unspoken assumption here that a way to kind of turbocharge learning from day-to-day experience is some form of synthesis or self-reflection. Would you agree with that statement?

+ +

STEPHANIE: Okay. This is another thing that I am perhaps, like, still trying to figure out, and we can figure it out together, which is separating, like, self-driven learning and, like, circumstance-driven learning. Because it's so much easier to want to reflect on something and find time to be, like, oh, like, how does this kind of help my goals or, like, what I want to be doing with my work? Versus when you are just asked to do something, and it could still be learning, right? It could still be new, and you need to go do some research or, you know, play around with a new tool. But there's less of that internal motivation or, like, kind of drive to integrate it. Like, do you have this distinction?

+ +

JOËL: I've definitely noticed that when there is motivation, I get more out of every hour of work that I put in in terms of learning new things. The more interest, the more motivation, the more value I get per unit of effort I put in.

+ +

STEPHANIE: Yeah. I think, for me, the other difference is, like, generative learning versus just kind of absorbing information that's already out there that someone else's...that is kind of, yeah, just absorbing rather than, like, creating something new from, like, those connections.

+ +

JOËL: Ooh.

+ +

STEPHANIE: Does that [chuckles] spark something for you?

+ +

JOËL: The gears are turning in my head because I'm almost hearing that as, like, a passive versus active learning thing. But just sort of like, I'm going to let things happen to me, and I will come out of that with some experience, and something is going to happen. Versus an active, I am going to, like, try to move in a direction and learn from that and things like that.

+ +

And I think this maybe connects back to the original question. Maybe this sort of, like, checking in at the end of the week, taking notes is a way to convert something that's a bit more of a passive experience, spending four days a week doing a project for a client, into something that's a little bit of a more active learning, where you say, "Okay, I did four weeks of this particular type of Rails work. What do I get out of it? What have I learned? What is something new that I've seen? What are some opinions I have formed, patterns I like or dislike?"

+ +

STEPHANIE: Yeah, I like that distinction because, you know, a few weeks ago, we were at RailsConf. We had kind of recapped it in a previous episode. And I think we had talked about like, oh, do we, like, to sit in talks or participate in workshops? And I think that's also another example of, like, passive versus active, right? Because I 100%, like, don't have the same type of learning by just, you know, listening to a talk that I do with maybe then going to look up, like, other things this person has put out in the world, finding them to talk to them about it, like, doing something with the content, right? Otherwise, it's just like, oh yeah, I heard this talk. Maybe one day I'll remember it when the need arises [laughs]. I, like, have a pointer to it in my brain. But until then, it probably just kind of, like, sits there, and nothing's really happened with it.

+ +

JOËL: I think maybe another thing that's interesting in that passive versus active distinction is that synthesis is inherently an act of creation. You are now creating new ideas of your own rather than just capturing information that is being thrown at you, either by sitting in a talk or by shipping tickets. The act of synthesizing and particularly, I think, making connections between ideas, either because something that, let's say you're in a talk, a speaker said that sparks an idea for yourself, or because you can connect something that speaker said with another idea that you already have or an idea that you've seen elsewhere.

+ +

So, you're like, oh, the thing this person is saying connects to this thing I read in a book or something another speaker said in an earlier session, or something like that. All of a sudden, now you're creating these new bits of knowledge, new perspectives, maybe even new mental models. We talked about mental models last week. And so, knowledge is not just the facts that you absorb or memorize. A lot of it is building the connections between those facts. And those are things that are not always given to you. You have to create them yourself.

+ +

STEPHANIE: Yeah, I am nodding my head a lot because that's resonating with, like, an experience that I'm having kind of coaching and mentoring a client developer on my team who is earlier in her career. And one thing that I've been really, like, working on with her is asking like, "Oh, like, what do you think of this?" Or like, "Have you seen this before? What are your reactions to this code, or, like this comment?" or whatever.

+ +

And I get the sense that, like, not a lot of people have prompted her to, like, come up with answers for those kinds of questions. And I'm really, really hopeful that, like, that kind of will help her achieve some of the goals that she's, like, hoping for in terms of her technical growth, especially where she's felt like she's stagnated a little bit.

+ +

And I think that calls back really well to what you said at the beginning of, like, you can spend years, right? Just kind of plugging away. But that's not the same as that really active growth. And, again, like, that's fine if that's where you're at or want to be at for a little while. But I suspect if anyone is kind of, like, wondering, like, where did that time go [laughs]...even for me, too, like, once someone started asking me those questions, I was like, oh, there's still so much to figure out or explore.

+ +

And I think you're actually really good at doing that, asking questions of yourself. And then, another thing that I've picked up from you is you ask questions about, like, what are questions other people would have? And that's a skill that I feel like I still have yet to figure out. I'm [chuckles] curious what you think about that.

+ +

JOËL: That's interesting because that kind of goes to another level. I often think of the questions other people would have from a more, like, pedagogical sense. So, I write a lot of blog posts. I write a lot of talks that I give. So, oftentimes when I'm creating that kind of material, there's a bit of an inner critic who's trying to, you know, sitting in the audience listening to myself speak, and who's going to maybe roll their eyes at certain points, or just get lost, or maybe raise their hand with a question. And that's who I try to address those things so that then when I go through it the next time, that inner critic is actually feeling engaged and paying attention.

+ +

STEPHANIE: Do you find that you're able to do that because you've seen that happen enough times where you're like, oh, I can kind of predict maybe what someone might feel confused about? I'm curious, like, how you got from being, like, well, I know what I would be confused about to what would someone else be unsure or, like, want more information about.

+ +

JOËL: Part of the answer there is that I'm a very harsh critic myself.

+ +

STEPHANIE: [laughs] Yes.

+ +

JOËL: So, I'm sitting in somebody else's talk, and there are probably parts where I'm rolling my eyes or being like, wait a minute, how did you get from this idea to this other thing? That doesn't follow. And so, I try to turn that back towards myself and use that as fuel to make my own work better.

+ +

STEPHANIE: Yeah, that's cool. I like that. Even if it's just framed as, like, a missed opportunity for people to have better or more comprehensive understanding. I know that's something that you're, like, very motivated to help kind of spread more of [laughs]. Understanding and learning is just important to you and to me. So, I think that's really cool that you're able to find ways to do that.

+ +

JOËL: Well, you definitely want to, I think, to keep a sort of beginner's mindset for a lot of these things, and one of the best ways to do that is to work with beginners. So, I spent a lot of time, back in the day, for example, in the Elm language chat room, just helping people answer basic questions, looking up documentation, explaining sort of basic concepts.

+ +

And that, I think, helped me get a sense of like, where were newcomers to the language getting stuck? And what were the explanations of those concepts that really connected? Which I could then translate into my work. And I think that that made me a better developer and helped me build this, like, really deep understanding of the underlying concepts in a way that I wouldn't have had just writing code on my own.

+ +

STEPHANIE: Wow, forum question answering hero. I have never thought to do that or felt compelled to do that. But I remember my friend was telling me, she was like, "Yeah, sometimes I just want to feel good about myself. And I remember that I know things that other people, like, are wanting to find out," and she just will answer some easy questions on Stack Overflow, you know, about, like, basic Rails stuff or something. And she is like, "Yeah, and that's doing my good deed [laughs]." And yeah, I think that it also, you know, has the same benefits that you were just saying earlier about...because you want to be helpful, you figure out how to actually be helpful, right?

+ +

JOËL: There's maybe a sense as well that helping others, once more, forces you into more of an active mindset for growth in the same way that interrogating yourself does, except now it's a beginner who's interrogating you. And so, it forces you to think a little bit more about those whys or those places where people get stuck. And you've just sort of assumed it's a certain way, but now you have to, like, explain it and really get into some of the concepts.

+ +

STEPHANIE: So, on the show, we've talked a lot about the fun things you share in the dev channel in our Slack workspace. But I recently discovered that someone (Was it you?) created an Obsidian MD channel for our favorite note-taking software. And in it, you shared a really cool tool that is available in Obsidian called mind maps.

+ +

JOËL: Yeah, so mind maps are a type of diagram. They're effectively a tree structure, but they don't really look like that when you draw them out. You start with a sort of topic in the center, and then you just keep drawing branches off of that, going every direction. And then, maybe branches off branches and keep going as you add more content. Turns out that Mermaid.js supports mind maps as a graph type, and Obsidian embeds Mermaid diagrams. So, you can use Mermaid's little language to express a mind map. And now, all of a sudden, you have mind mapping as a tool available for you within Obsidian.

+ +

STEPHANIE: And how have you been using that to kind of process and experience or maybe, like, end up with some artifacts from, like, something that you're just doing in regular day-to-day work?

+ +

JOËL: So, kind of like you, I think I have the aspiration of doing some kind of, like, daily note journaling thing and turning that into bigger ideas. In practice, I do not do that. Maybe that's the thing that I will eventually incorporate into my practice, but that's not something that I'm currently doing. Instead, a thing that I've done is a little bit more like you, but it's a little bit more thematically chunked. So, for example, recently, I did several weeks of work that involved doing a lot of documentation for module-level documentation.

+ +

You know, I'd invested a lot of time learning about YARD, which is Ruby's documentation system, and trying to figure out, like, what exactly are docs that are going to be helpful for people? And I wanted that to not just be a thing I did once and then I kind of, like, move on and forget it. I wanted to figure out how can I sort of grow from that experience maximally? And so, the approach I took is to say, let's take some time after I've completed that experience and actually sort of almost interrogate it, ask myself a bunch of questions about that experience, which will then turn into more broad ideas.

+ +

And so, what I ended up doing is taking a mind-mapping approach. So, I start that center circle is just a circle that says, "My experience writing docs," and then I kind of ring it with a series of questions. So, what are questions that might be interesting to ask someone who just recently had experience writing documentation? And so, I come up with 4,5,6 questions that could be interesting to ask of someone who had experience. And here I'm trying to step away from myself a little bit.

+ +

And then, maybe I can start answering those questions, or maybe there are sub-questions that branch off of that. And maybe there are answers, or maybe there are answers that are interesting but that then trigger follow-up questions. And so I'm almost having a conversation with myself and using the mind map as a tool to facilitate that. But the first step is putting that experience in the center and then ringing it with questions, and then kind of seeing where those lead.

+ +

STEPHANIE: Cool. Yeah, I am, like, surprised that you're still following that thread because the module docs experience was quite a little bit a while ago now. We even, you know, had an episode on it that I'll link in the show notes.

+ +

How do you manage, like, learning new things all the time and knowing what to, like, invest energy and attention into and what to kind of maybe, like, consider just like, oh, like, I don't know, that was just an experience that I had, and I might not get around to doing anything with it?

+ +

JOËL: I don't know that I have a great system. I think sometimes when I do, especially a more prolonged chunk of time doing a thing, I find it really worthwhile to say, hey, I don't want that to sort of just be a thing that was in my memory, and then it moves out. I'd like to pull out some more maybe practical or long-term ideas from it. Part of that is capture, but some of that is also synthesis.

+ +

I just spent two weeks or I just spent a month using a particular technology or doing a new kind of task. What do I have to show for it? Are there any, like, bigger ideas that I have here? Does this connect with any other technologies I've done or any other ideas or theories? Did I come up with any opinions? Did I like this technology? Did I not? Are there elements that were inspirational?

+ +

And then capturing some of that eventually with the idea of...so I do a sort of Zettelkasten-style permanent note collection, the idea to create at least a few of those based off of the experience that I can then connect to other things. And maybe it eventually turns into other content. Maybe it's something I hold onto for a while. In the case of the module docs, it turned into a Bike Shed episode. It also turned into a blog post that was published this past week. And so, it does have a way of coming back.

+ +

STEPHANIE: Yeah. Yeah. One thing that sparked for me was that, you know, you and I spend a lot of time thinking about, like, the practice of writing software, you know, in the work we do as consultants, too. But I find that, like, you can also apply this to the actual just your work that you are getting paid for [laughs]. This was, I think, a nascent thought in the talk that I had given. But there's something to the idea of, like, you know, if you are working in some code, especially legacy code, for a long time, and you learn so much about it, and then what do you have to show for it [chuckles], you know?

+ +

I have really struggled with feeling like all of that work and learning was useful if it just, like, remains in my memory and not necessarily shared with the team or, I don't know, just, like, knowing that if I leave, especially since I am a contractor, like, just recognizing that there's value in being like, oh, I spent an hour or, like, half a day sifting through this complex legacy code just to make, like, a small change. But that small change is not the full value of all of the work that I did. And I suspect that, like, just the mind mapping stuff would be really interesting to apply to more. It's not, like, just practical work, but, like, more mundane, I don't know, like, labor [laughs], if you will.

+ +

JOËL: I can think of, like, sort of two types of knowledge that you can take out of something like that. Some of it is just understanding how this legacy system works, saying, oh, well, they have this user model that's connected to this old persona table, which is kind of unused, but we sometimes rely for in this legacy case. And you've got to have this permission flag turned on and, like, all those things that you had to just discover by reading the code and exploring. And that's going to be useful to you as long as you work in that legacy codebase, as long as you work through that path. But when you move on to another project, that knowledge probably doesn't serve you a whole lot.

+ +

There are things that you did throughout that journey, though, that you can probably pull out that are going to be useful to you on other projects. And that might be maybe you came up with a new way of navigating the code or a new way of, like, finding how different pieces were connected. Maybe it was a diagramming tool; maybe it was some sort of gem. Maybe it was just a, oh, a heuristic, like, when I see a model, I like to follow the associations first. And I always go for the has_manys over the belongs_tos because those generally lead me in the right direction. Like, that's really interesting insight, and that's something that might serve you on a following project.

+ +

You can also pull out bigger things like, are there refactoring techniques that you experimented with or that you learned on this project that you would use again elsewhere? Are there ways of maybe quarantining scary code on a legacy project that are a thing that you would want to make more consistent part of your practice? Those are all great things to pull out of, just a like, oh yeah, I did some work on a, like, old legacy part of an app. And what do I have to show for it? I think you can actually have a lot to show for it.

+ +

STEPHANIE: Yeah, that's really cool. That sounds like a sure way of multiplying the learning. And I think I didn't really consider that when I was first talking about it, too. But yeah, there are, like, both of those things kind of available to you to, like, learn from. Yeah, it's like, that time is never just kind of, like, purely wasted. Oh, I don't know, sometimes it really feels like that [laughs] when you are debugging something really silly.

+ +

But yeah, like, I would be interested in kind of thinking about it from both of those lenses because I think there's value in what you learn about that particular system in that moment of time, even if it might not translate to just future works or future projects. And, like, that's something that I think we would do better at kind of capturing, and also, there's so much stuff, too, kind of to that higher level growth that you were speaking to.

+ +

JOËL: I think some of the distinctions we're talking about here is something that was explored in an older episode on note-taking with Amanda Beiner, where we sort of explored the difference between exploratory notes, debugging notes, idea notes, and how note-taking is not a single thing. It can serve many purposes, and they can have different lifespans. And those are all just ways to aid your thinking. But being maybe aware of the kind of thinking that you're trying to do, the kind of notes you're trying to take can help you make better use of that time.

+ +

STEPHANIE: I have one last question for you before we wrap up, which is, do you find, like, the stuff we're talking about to be particularly true about software development, or it just happens to be the thing that you and I both do, and we also love to learn, and so, therefore, we are able to talk about this for, like, 50 minutes [laughs]? Are you able to make any kind of distinction there, or is it just kind of part of pedagogy in general?

+ +

JOËL: I would say that that sort of active versus passive thing is a thing that's probably true, just about anything that you do. For example, I do a lot of bouldering. Just going spending a lot of time on the wall, climbing a lot; that's going to help me get better. But a classic way that people try to improve is filming themselves or having a friend film themselves, and then you can look at it, and then you evaluate, oh, that's what I did. This is where I was struggling to get the next hold. What if I try to do something different?

+ +

So, building in an amount of, like, self-reflection into the loop all of a sudden catalyzes that learning and helps you grow at a rate that's much more than if you're just kind of mindlessly putting time into it. So, I would go so far as to say that self-reflection, synthesis—those are all things that are probably going to catalyze growth in most areas of your life if you're being a little bit more self-aware. But I've found that it's been particularly useful for me when it comes to trying to get better at the job that I do every week.

+ +

STEPHANIE: Yeah, I think, for me, it's like, yeah, getting better at being a developer rather than being, you know, a software developer at X company. Like, not necessarily just getting better at working at that company but getting better at the skill itself.

+ +

JOËL: And those two things have a way of sort of, like, folding back into themselves, right? If you're a better software developer in general, you will probably be a better developer at that company. Yes, you want domain knowledge and, like, a deep understanding of how the system works is going to make you a better developer at that company. But also, if you're able to find more generic approaches to onboard onto new things, or to debug more effectively, or to better read or understand unknown code of high complexity, those are all going to make you much better at being a developer at that company as well. And they're transferable skills, so they're all really good things to have.

+ +

STEPHANIE: On that note. Shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + 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.

+ + + +

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've created, being something really helpful. That being said, I've never DM'd myself, so I have no idea what it actually is like to be on the other side of that screen.

+ +

STEPHANIE: Cool. I mean, if you ever do try that or have a DM experience and you're like, hmm, I wonder kind of how I might be able to help me here, I bet that would be a very cool experience to share on the show.

+ +

JOËL: I definitely have to report back here.

+ +

Something that I've been thinking about a lot recently is the difference between sort of professional growth and experience, so the time that you put into doing work. Particularly maybe because, you know, we spend part of our week doing client work, and then we have part of the week that's dedicated to maybe more directly professional growth: our investment day. How do we grow from that, like, four days a week where we're doing client work? Because not all experience is created equal.

+ +

Just because I put in the hours doesn't mean that I'm going to grow. And maybe I'm going to feel like I'm in a rut. So, how do I take those four days a week that I'm doing code and transform that into some sort of growth or expansion of my knowledge as a developer? Do you have any sort of tactics that you like to use or ways you try to be a little bit more mindful of that?

+ +

STEPHANIE: Yeah, this is a fun question for me, and kind of reminds me of something we've talked a little bit about before. I can't remember if it was, like, on air or just separately, but, you know, we talk a lot about, like, different learning strategies on the show, I think, because that's just something you and I are very into. And we often, like, lean on, you know, our investment day, so our Fridays that we get to not do client work and kind of dedicate to professional development.

+ +

But you and I also try to remember that, like, most people don't have that. And most people kind of are needing to maybe find ways to just grow from the day-to-day work that they do, and that is totally possible, I think. And some of the strategies that I have are, I guess, like, it is really...it can be really challenging to, like, you know, be like, okay, I spent 40 hours doing this, and like, what did I learn [chuckles]? Feeling like you have to have something to show for it or something to point to.

+ +

And one thing that I've been really liking is these automated check-ins we have at the end of the week. And, you know, I suspect that this is not that uncommon for just, like, a workplace to be like, "Hey, like, how did your week go? Like, what are some ways that it was successful? Like, what are your challenges? Like, where do you need support or help?" And I think I've now started using that as both, like, space for giving an update on just, like, business-y things. Like, "Here's the status of this project," or, like, "Here's, you know, a roadblock that we faced that took some extra time," or whatever.

+ +

Then also being like, oh, this is a great time to make this space for myself, especially because...I don't know about you, but whenever I have, like, performance review time and I have to write, like, a self-review, I'm just like, did I do anything in the last six months [laughs], or how have I grown in the last six months? It feels like such a big question, kind of like you were talking about that blank page syndrome a little bit.

+ +

But if I have kind of just put in the 10 minutes during my Friday to be like, is there something that was kind of just for me that I can say in my check-in? I can go back and, yeah, just kind of start to see just, like, you know, pick out or just pay attention to how, like, my 40 hours is kind of serving me in growing in the ways that I want to and not just to deliver code [laughs].

+ +

JOËL: What you're describing there, that sort of weekly check-in and taking notes, reminds me of the practice of journaling. Is that something that you've ever tried to do in your, like, regular life?

+ +

STEPHANIE: Oh yeah, very much so. But I'm not nearly as, like, routine about it in my personal life. But I suspect that the routine is helpful in more of a, like, workplace setting, at least for me, because I do have, like, more clear pathways of growth that I'm interested in or just, like, something that, I don't know, not that it's, like, expected of everyone, but if that is part of your goals or, like, part of your company's culture, I feel like I benefit from that structure. And yeah, I mean, I guess maybe that's kind of my way of integrating something that I already do in my personal life to an environment where, like I said, maybe there is, like, that is just part of the work and part of your career progression.

+ +

JOËL: I'm curious about the frequency. You mentioned that you sort of do this once a week, sort of a check-in at the end of the week. Do you find that once a week is about the right frequency versus maybe something like daily? I know a lot of these sort of more modern note-taking systems, Roam Research, or Obsidian, or whatever, have this concept of, like, a daily note that's supposed to encourage something that's kind of like journaling. Have you ever tried something more on a daily basis, or do you feel like a week is about...or once a week is about the right cadence for you?

+ +

STEPHANIE: Listen, I have, like, complicated feelings about this because I think the daily note is so aspirational for me [laughs] and just not how I work. And I have finally begrudgingly come to accept this no matter how much, like, I don't know, like, bullet journal inspirational content I consume on the internet [laughs]. I have tried and failed many a time to have more frequency in that way. But, I don't know, I think it almost just, like, sets me up for failure [laughs] because I have these expectations.

+ +

And that's, like, the other thing. It's like, you can't force learning necessarily. I don't know if this is, like, a strategy, but I think there is some amount of, like, making sure that I'm in the right headspace for it and, you know, like, my environment, too, kind of is conducive to it. Like, I have, like, the time, right? If I'm trying to squeeze in, I don't know, maybe, like, in between meetings, 20 minutes to be like, what did I learn from this experience? Nothing's coming out [laughs].

+ +

That was another thing that I was kind of mulling over when he had this topic proposed is this idea of, like, mindset and environment being really important because you know when you are saying, like, not all time is created equal, and I suspect that if, you know, either you or, like, the people around you and the environment you're in is not also facilitating growth, and, like, how much can you really expect for it to be happening?

+ +

JOËL: I mean, that's really interesting, right? The impact of sort of a broader company culture. And I think that definitely can act as a catalyst for growth, either to kind of propel you forward or to pull you back.

+ +

I want to dig into a little bit something you were saying about being in the right headspace to capture ideas. And I think that there's sort of almost, like, two distinct phases. There's the, like, capturing data, and information, and experiences, and then, there's synthesizing it, turning information into learning.

+ +

STEPHANIE: Yes.

+ +

JOËL: And it sounds like you're making a distinction between those two things, specifically that synthesis step is something that has to happen separately.

+ +

STEPHANIE: Ooh, I don't even...I don't know if I would necessarily say that I'm only talking about synthesis, but I do like that you kind of separated those categories because I do think that they are really important. And they kind of remind me a lot about the scientific method a little bit where, you know, you have the gathering data and, like, observations, and you have, you know, maybe some...whatever is precipitating learning that you're doing maybe differently or new.

+ +

And that also takes time, I think, or intention at least, to be like, oh, do I have what I need to, like, get information about how this is going? And then, yeah, that synthesis step that I think I was talking about a little bit more. But I don't think either is just automatic. There is, I think, quite a bit of intention involved.

+ +

JOËL: I think maybe the way I think about this is colored by reading some material on the Zettelkasten method of note-taking, which splits up the idea of fleeting notes and literature notes, which are sort of just, like, jotting down ideas, or things you've seen, things that you've learned, maybe a thought you had when you read a particular paragraph in a blog post, something like that.

+ +

And then, the permanent notes, which are more, like, fully formed thoughts that arise out of the more fleeting ones. And so, the idea is that the fleeting ones maybe you're taking those in a notebook if you're doing it pen and paper. You could be doing it in some sort of, like, daily note, or something like that. And then, those are temporary. They were there to just capture information. Later on, you process that, and then you can throw them out if you need to.

+ +

STEPHANIE: Yeah, that makes a lot of sense. This has actually been a shift for me, where I used to rely a lot more on memory and perhaps, like, didn't have a great system for taking things like fleeting notes and, like, documenting kind of [inaudible 18:28] what I was saying earlier about how do I make sure that the information is recorded, you know, for me to synthesize later? And I have found a lot more success lately in that fleeting note style of operating. And thanks to Obsidian honestly, now it's so easy to be like, oh, I'm just going to open a quick new file. And I need as little friction as possible to, like, put stuff somewhere [laughs].

+ +

And, actually, I'm excited to talk a little bit more about this with you because I think you're a little bit different where you somehow find the time [laughs] and care to create your diagrams. I'm like, if I can, for some reason, even get an Obsidian file open, I'll tab to Slack. And I send myself a lot of notes in my just own personal DM space. In fact, it's actually kind of embarrassing because I use the Command+K shortcut to navigate to my own personal DMs, which you can get to by typing me, like, M-E.

+ +

And sometimes I've accidentally just entered that into a channel chat [laughs], and then I have to delete it really quick later when I realize what I've done. So, yeah, like, I meant to navigate to my personal notes, and I just put in our team chat, "Me [laughs]." And, I don't know, I have no idea how that comes up [laughs], what people think is going on. But if anyone's listening to this podcast from thoughtbot and has seen that of me, that's what happened.

+ +

JOËL: You may not be the only one who's done that.

+ +

STEPHANIE: Thank you. Yeah [laughs], that's good to know.

+ +

JOËL: I want to step back a little bit because we've been talking about, like, introspection, and synthesis, and finding moments to capture information. And I think we've sort of...there's an unspoken assumption here that a way to kind of turbocharge learning from day-to-day experience is some form of synthesis or self-reflection. Would you agree with that statement?

+ +

STEPHANIE: Okay. This is another thing that I am perhaps, like, still trying to figure out, and we can figure it out together, which is separating, like, self-driven learning and, like, circumstance-driven learning. Because it's so much easier to want to reflect on something and find time to be, like, oh, like, how does this kind of help my goals or, like, what I want to be doing with my work? Versus when you are just asked to do something, and it could still be learning, right? It could still be new, and you need to go do some research or, you know, play around with a new tool. But there's less of that internal motivation or, like, kind of drive to integrate it. Like, do you have this distinction?

+ +

JOËL: I've definitely noticed that when there is motivation, I get more out of every hour of work that I put in in terms of learning new things. The more interest, the more motivation, the more value I get per unit of effort I put in.

+ +

STEPHANIE: Yeah. I think, for me, the other difference is, like, generative learning versus just kind of absorbing information that's already out there that someone else's...that is kind of, yeah, just absorbing rather than, like, creating something new from, like, those connections.

+ +

JOËL: Ooh.

+ +

STEPHANIE: Does that [chuckles] spark something for you?

+ +

JOËL: The gears are turning in my head because I'm almost hearing that as, like, a passive versus active learning thing. But just sort of like, I'm going to let things happen to me, and I will come out of that with some experience, and something is going to happen. Versus an active, I am going to, like, try to move in a direction and learn from that and things like that.

+ +

And I think this maybe connects back to the original question. Maybe this sort of, like, checking in at the end of the week, taking notes is a way to convert something that's a bit more of a passive experience, spending four days a week doing a project for a client, into something that's a little bit of a more active learning, where you say, "Okay, I did four weeks of this particular type of Rails work. What do I get out of it? What have I learned? What is something new that I've seen? What are some opinions I have formed, patterns I like or dislike?"

+ +

STEPHANIE: Yeah, I like that distinction because, you know, a few weeks ago, we were at RailsConf. We had kind of recapped it in a previous episode. And I think we had talked about like, oh, do we, like, to sit in talks or participate in workshops? And I think that's also another example of, like, passive versus active, right? Because I 100%, like, don't have the same type of learning by just, you know, listening to a talk that I do with maybe then going to look up, like, other things this person has put out in the world, finding them to talk to them about it, like, doing something with the content, right? Otherwise, it's just like, oh yeah, I heard this talk. Maybe one day I'll remember it when the need arises [laughs]. I, like, have a pointer to it in my brain. But until then, it probably just kind of, like, sits there, and nothing's really happened with it.

+ +

JOËL: I think maybe another thing that's interesting in that passive versus active distinction is that synthesis is inherently an act of creation. You are now creating new ideas of your own rather than just capturing information that is being thrown at you, either by sitting in a talk or by shipping tickets. The act of synthesizing and particularly, I think, making connections between ideas, either because something that, let's say you're in a talk, a speaker said that sparks an idea for yourself, or because you can connect something that speaker said with another idea that you already have or an idea that you've seen elsewhere.

+ +

So, you're like, oh, the thing this person is saying connects to this thing I read in a book or something another speaker said in an earlier session, or something like that. All of a sudden, now you're creating these new bits of knowledge, new perspectives, maybe even new mental models. We talked about mental models last week. And so, knowledge is not just the facts that you absorb or memorize. A lot of it is building the connections between those facts. And those are things that are not always given to you. You have to create them yourself.

+ +

STEPHANIE: Yeah, I am nodding my head a lot because that's resonating with, like, an experience that I'm having kind of coaching and mentoring a client developer on my team who is earlier in her career. And one thing that I've been really, like, working on with her is asking like, "Oh, like, what do you think of this?" Or like, "Have you seen this before? What are your reactions to this code, or, like this comment?" or whatever.

+ +

And I get the sense that, like, not a lot of people have prompted her to, like, come up with answers for those kinds of questions. And I'm really, really hopeful that, like, that kind of will help her achieve some of the goals that she's, like, hoping for in terms of her technical growth, especially where she's felt like she's stagnated a little bit.

+ +

And I think that calls back really well to what you said at the beginning of, like, you can spend years, right? Just kind of plugging away. But that's not the same as that really active growth. And, again, like, that's fine if that's where you're at or want to be at for a little while. But I suspect if anyone is kind of, like, wondering, like, where did that time go [laughs]...even for me, too, like, once someone started asking me those questions, I was like, oh, there's still so much to figure out or explore.

+ +

And I think you're actually really good at doing that, asking questions of yourself. And then, another thing that I've picked up from you is you ask questions about, like, what are questions other people would have? And that's a skill that I feel like I still have yet to figure out. I'm [chuckles] curious what you think about that.

+ +

JOËL: That's interesting because that kind of goes to another level. I often think of the questions other people would have from a more, like, pedagogical sense. So, I write a lot of blog posts. I write a lot of talks that I give. So, oftentimes when I'm creating that kind of material, there's a bit of an inner critic who's trying to, you know, sitting in the audience listening to myself speak, and who's going to maybe roll their eyes at certain points, or just get lost, or maybe raise their hand with a question. And that's who I try to address those things so that then when I go through it the next time, that inner critic is actually feeling engaged and paying attention.

+ +

STEPHANIE: Do you find that you're able to do that because you've seen that happen enough times where you're like, oh, I can kind of predict maybe what someone might feel confused about? I'm curious, like, how you got from being, like, well, I know what I would be confused about to what would someone else be unsure or, like, want more information about.

+ +

JOËL: Part of the answer there is that I'm a very harsh critic myself.

+ +

STEPHANIE: [laughs] Yes.

+ +

JOËL: So, I'm sitting in somebody else's talk, and there are probably parts where I'm rolling my eyes or being like, wait a minute, how did you get from this idea to this other thing? That doesn't follow. And so, I try to turn that back towards myself and use that as fuel to make my own work better.

+ +

STEPHANIE: Yeah, that's cool. I like that. Even if it's just framed as, like, a missed opportunity for people to have better or more comprehensive understanding. I know that's something that you're, like, very motivated to help kind of spread more of [laughs]. Understanding and learning is just important to you and to me. So, I think that's really cool that you're able to find ways to do that.

+ +

JOËL: Well, you definitely want to, I think, to keep a sort of beginner's mindset for a lot of these things, and one of the best ways to do that is to work with beginners. So, I spent a lot of time, back in the day, for example, in the Elm language chat room, just helping people answer basic questions, looking up documentation, explaining sort of basic concepts.

+ +

And that, I think, helped me get a sense of like, where were newcomers to the language getting stuck? And what were the explanations of those concepts that really connected? Which I could then translate into my work. And I think that that made me a better developer and helped me build this, like, really deep understanding of the underlying concepts in a way that I wouldn't have had just writing code on my own.

+ +

STEPHANIE: Wow, forum question answering hero. I have never thought to do that or felt compelled to do that. But I remember my friend was telling me, she was like, "Yeah, sometimes I just want to feel good about myself. And I remember that I know things that other people, like, are wanting to find out," and she just will answer some easy questions on Stack Overflow, you know, about, like, basic Rails stuff or something. And she is like, "Yeah, and that's doing my good deed [laughs]." And yeah, I think that it also, you know, has the same benefits that you were just saying earlier about...because you want to be helpful, you figure out how to actually be helpful, right?

+ +

JOËL: There's maybe a sense as well that helping others, once more, forces you into more of an active mindset for growth in the same way that interrogating yourself does, except now it's a beginner who's interrogating you. And so, it forces you to think a little bit more about those whys or those places where people get stuck. And you've just sort of assumed it's a certain way, but now you have to, like, explain it and really get into some of the concepts.

+ +

STEPHANIE: So, on the show, we've talked a lot about the fun things you share in the dev channel in our Slack workspace. But I recently discovered that someone (Was it you?) created an Obsidian MD channel for our favorite note-taking software. And in it, you shared a really cool tool that is available in Obsidian called mind maps.

+ +

JOËL: Yeah, so mind maps are a type of diagram. They're effectively a tree structure, but they don't really look like that when you draw them out. You start with a sort of topic in the center, and then you just keep drawing branches off of that, going every direction. And then, maybe branches off branches and keep going as you add more content. Turns out that Mermaid.js supports mind maps as a graph type, and Obsidian embeds Mermaid diagrams. So, you can use Mermaid's little language to express a mind map. And now, all of a sudden, you have mind mapping as a tool available for you within Obsidian.

+ +

STEPHANIE: And how have you been using that to kind of process and experience or maybe, like, end up with some artifacts from, like, something that you're just doing in regular day-to-day work?

+ +

JOËL: So, kind of like you, I think I have the aspiration of doing some kind of, like, daily note journaling thing and turning that into bigger ideas. In practice, I do not do that. Maybe that's the thing that I will eventually incorporate into my practice, but that's not something that I'm currently doing. Instead, a thing that I've done is a little bit more like you, but it's a little bit more thematically chunked. So, for example, recently, I did several weeks of work that involved doing a lot of documentation for module-level documentation.

+ +

You know, I'd invested a lot of time learning about YARD, which is Ruby's documentation system, and trying to figure out, like, what exactly are docs that are going to be helpful for people? And I wanted that to not just be a thing I did once and then I kind of, like, move on and forget it. I wanted to figure out how can I sort of grow from that experience maximally? And so, the approach I took is to say, let's take some time after I've completed that experience and actually sort of almost interrogate it, ask myself a bunch of questions about that experience, which will then turn into more broad ideas.

+ +

And so, what I ended up doing is taking a mind-mapping approach. So, I start that center circle is just a circle that says, "My experience writing docs," and then I kind of ring it with a series of questions. So, what are questions that might be interesting to ask someone who just recently had experience writing documentation? And so, I come up with 4,5,6 questions that could be interesting to ask of someone who had experience. And here I'm trying to step away from myself a little bit.

+ +

And then, maybe I can start answering those questions, or maybe there are sub-questions that branch off of that. And maybe there are answers, or maybe there are answers that are interesting but that then trigger follow-up questions. And so I'm almost having a conversation with myself and using the mind map as a tool to facilitate that. But the first step is putting that experience in the center and then ringing it with questions, and then kind of seeing where those lead.

+ +

STEPHANIE: Cool. Yeah, I am, like, surprised that you're still following that thread because the module docs experience was quite a little bit a while ago now. We even, you know, had an episode on it that I'll link in the show notes.

+ +

How do you manage, like, learning new things all the time and knowing what to, like, invest energy and attention into and what to kind of maybe, like, consider just like, oh, like, I don't know, that was just an experience that I had, and I might not get around to doing anything with it?

+ +

JOËL: I don't know that I have a great system. I think sometimes when I do, especially a more prolonged chunk of time doing a thing, I find it really worthwhile to say, hey, I don't want that to sort of just be a thing that was in my memory, and then it moves out. I'd like to pull out some more maybe practical or long-term ideas from it. Part of that is capture, but some of that is also synthesis.

+ +

I just spent two weeks or I just spent a month using a particular technology or doing a new kind of task. What do I have to show for it? Are there any, like, bigger ideas that I have here? Does this connect with any other technologies I've done or any other ideas or theories? Did I come up with any opinions? Did I like this technology? Did I not? Are there elements that were inspirational?

+ +

And then capturing some of that eventually with the idea of...so I do a sort of Zettelkasten-style permanent note collection, the idea to create at least a few of those based off of the experience that I can then connect to other things. And maybe it eventually turns into other content. Maybe it's something I hold onto for a while. In the case of the module docs, it turned into a Bike Shed episode. It also turned into a blog post that was published this past week. And so, it does have a way of coming back.

+ +

STEPHANIE: Yeah. Yeah. One thing that sparked for me was that, you know, you and I spend a lot of time thinking about, like, the practice of writing software, you know, in the work we do as consultants, too. But I find that, like, you can also apply this to the actual just your work that you are getting paid for [laughs]. This was, I think, a nascent thought in the talk that I had given. But there's something to the idea of, like, you know, if you are working in some code, especially legacy code, for a long time, and you learn so much about it, and then what do you have to show for it [chuckles], you know?

+ +

I have really struggled with feeling like all of that work and learning was useful if it just, like, remains in my memory and not necessarily shared with the team or, I don't know, just, like, knowing that if I leave, especially since I am a contractor, like, just recognizing that there's value in being like, oh, I spent an hour or, like, half a day sifting through this complex legacy code just to make, like, a small change. But that small change is not the full value of all of the work that I did. And I suspect that, like, just the mind mapping stuff would be really interesting to apply to more. It's not, like, just practical work, but, like, more mundane, I don't know, like, labor [laughs], if you will.

+ +

JOËL: I can think of, like, sort of two types of knowledge that you can take out of something like that. Some of it is just understanding how this legacy system works, saying, oh, well, they have this user model that's connected to this old persona table, which is kind of unused, but we sometimes rely for in this legacy case. And you've got to have this permission flag turned on and, like, all those things that you had to just discover by reading the code and exploring. And that's going to be useful to you as long as you work in that legacy codebase, as long as you work through that path. But when you move on to another project, that knowledge probably doesn't serve you a whole lot.

+ +

There are things that you did throughout that journey, though, that you can probably pull out that are going to be useful to you on other projects. And that might be maybe you came up with a new way of navigating the code or a new way of, like, finding how different pieces were connected. Maybe it was a diagramming tool; maybe it was some sort of gem. Maybe it was just a, oh, a heuristic, like, when I see a model, I like to follow the associations first. And I always go for the has_manys over the belongs_tos because those generally lead me in the right direction. Like, that's really interesting insight, and that's something that might serve you on a following project.

+ +

You can also pull out bigger things like, are there refactoring techniques that you experimented with or that you learned on this project that you would use again elsewhere? Are there ways of maybe quarantining scary code on a legacy project that are a thing that you would want to make more consistent part of your practice? Those are all great things to pull out of, just a like, oh yeah, I did some work on a, like, old legacy part of an app. And what do I have to show for it? I think you can actually have a lot to show for it.

+ +

STEPHANIE: Yeah, that's really cool. That sounds like a sure way of multiplying the learning. And I think I didn't really consider that when I was first talking about it, too. But yeah, there are, like, both of those things kind of available to you to, like, learn from. Yeah, it's like, that time is never just kind of, like, purely wasted. Oh, I don't know, sometimes it really feels like that [laughs] when you are debugging something really silly.

+ +

But yeah, like, I would be interested in kind of thinking about it from both of those lenses because I think there's value in what you learn about that particular system in that moment of time, even if it might not translate to just future works or future projects. And, like, that's something that I think we would do better at kind of capturing, and also, there's so much stuff, too, kind of to that higher level growth that you were speaking to.

+ +

JOËL: I think some of the distinctions we're talking about here is something that was explored in an older episode on note-taking with Amanda Beiner, where we sort of explored the difference between exploratory notes, debugging notes, idea notes, and how note-taking is not a single thing. It can serve many purposes, and they can have different lifespans. And those are all just ways to aid your thinking. But being maybe aware of the kind of thinking that you're trying to do, the kind of notes you're trying to take can help you make better use of that time.

+ +

STEPHANIE: I have one last question for you before we wrap up, which is, do you find, like, the stuff we're talking about to be particularly true about software development, or it just happens to be the thing that you and I both do, and we also love to learn, and so, therefore, we are able to talk about this for, like, 50 minutes [laughs]? Are you able to make any kind of distinction there, or is it just kind of part of pedagogy in general?

+ +

JOËL: I would say that that sort of active versus passive thing is a thing that's probably true, just about anything that you do. For example, I do a lot of bouldering. Just going spending a lot of time on the wall, climbing a lot; that's going to help me get better. But a classic way that people try to improve is filming themselves or having a friend film themselves, and then you can look at it, and then you evaluate, oh, that's what I did. This is where I was struggling to get the next hold. What if I try to do something different?

+ +

So, building in an amount of, like, self-reflection into the loop all of a sudden catalyzes that learning and helps you grow at a rate that's much more than if you're just kind of mindlessly putting time into it. So, I would go so far as to say that self-reflection, synthesis—those are all things that are probably going to catalyze growth in most areas of your life if you're being a little bit more self-aware. But I've found that it's been particularly useful for me when it comes to trying to get better at the job that I do every week.

+ +

STEPHANIE: Yeah, I think, for me, it's like, yeah, getting better at being a developer rather than being, you know, a software developer at X company. Like, not necessarily just getting better at working at that company but getting better at the skill itself.

+ +

JOËL: And those two things have a way of sort of, like, folding back into themselves, right? If you're a better software developer in general, you will probably be a better developer at that company. Yes, you want domain knowledge and, like, a deep understanding of how the system works is going to make you a better developer at that company. But also, if you're able to find more generic approaches to onboard onto new things, or to debug more effectively, or to better read or understand unknown code of high complexity, those are all going to make you much better at being a developer at that company as well. And they're transferable skills, so they're all really good things to have.

+ +

STEPHANIE: On that note. Shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Zown5kAr + + ]]> + + Joël Quenneville + Stephanie Minn + + + 428: Ruminating on Ruby Enumerators + https://bikeshed.thoughtbot.com/428 + dbd66723-6b99-4645-85cf-c2da2d0ae2f3 + Tue, 11 Jun 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + 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. + 35:44 + no + + + 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 discovering a few things, too, about, like, what this feature is or could be. And I think those are the things that, you know, need to be brought into a conversation with a broader group and think about, like, is this the direction we want to go? So, that's kind of how I'm bucketing that feedback right now. +JOËL: How do you feel about receiving direct feedback versus having something filtered through something like a product team? +STEPHANIE: Ooh, that's an interesting question. Because right now we're doing, I think, a mix of both that I'm not sure that I really like. On one hand, when it's filtered, it's hard to get to the root of what someone is asking for. And oftentimes, like, it may not even include enough information after the fact to be able to come at it from a dev perspective. But then direct feedback, I think, is just a little bit overwhelming sometimes. And it can be hard to figure out what to pay attention to if you don't have that, like, input from a product team about, like, what the roadmap is looking like or where, you know, strategically their heads are at. +So, one thing that kind of has emerged from this is like, oh, I was getting, you know, notifications for the feedback coming in. And what we did was set up a meeting [laughs] so that we can...maybe all of us can, like, scan it together ahead of time and then come at it with a little bit of context about what's come in but then maybe coalesce around the things that we feel are important. +JOËL: Well, you'll have to keep us updated on how that plays out, and we can kind of hear what is the balance that ends up working well for you. +STEPHANIE: Yeah, I hope so. I think this is actually maybe something that's a bit underexplored from the dev perspective, you know, that in-between stage of you're not totally done because it's not shipped to the world yet, but, you know, you're starting to get a little bit of that input. And what you do with that? Because I think there is some value in being engaged in that process. +JOËL: So, we were talking earlier about this note-taking system that I use and sort of a renewed excitement that I have about it. And one thing that I did when I was going through and finding clusters of things that hadn't been written about was I found that I had a cluster of notes on different mental models that I had for understanding Ruby enumerators, not the enumerable module, but the enumerator object. And I decided, you know what? This would probably make for a good blog post. So, I drafted a blog post, and I've been thinking about this a little bit more recently. So, I've been really hyped about digging into enumerators because of that experience. +STEPHANIE: Yeah, that's very cool. I have to say that I feel like I did not know a lot about enumerators and the API for them kind of before you brought this topic up, and I did a bit of a deep dive in preparation for us to discuss it. I feel like most devs, you know, work with enumerators via methods on enumerable without totally knowing that they are. So, I think that this would be a really interesting episode for people to be like, oh, like, I've been using this stuff, you know, the whole time, and now I can have a different perspective or just more insight on what they can do. +JOËL: Before we dig into individual mental models, though, I want to think a little bit about the concept of mental models as a whole. Years ago, someone gave me advice to sort of pay attention to mental models, ways I think about the world or different code structures, different code approaches, and that really stuck with me. So, I've since been, like, kind of, like, collecting mental models. +And, in a way, they're like a, for me, a bit more of a concrete way to look at a particular topic. So, I can say I'm looking at this particular topic through the lens of a particular mental model that helps me build more clarity around it. And if I have three or four, then I can kind of look at it from three or four different perspectives. And now, all of a sudden, I feel like I'm seeing in three dimensions. +STEPHANIE: Whoa, the Matrix even [laughs]. That's cool. Yeah, I really like that advice. I think I'm going to steal it and start kind of suggesting it to other people because I think, in a way, on this show, that has come through a lot. And talking about things on the podcast has helped me develop a lot of my mental models. And I think we've done a few, like, episodes in the past about various ones we have for just our work because it's like, that's infinite [laughs]. But what I really have been appreciating is that mental models just need to work for you. As long as you're able to understand something, then it's valuable. +And that has really helped me also, like, just get on the same understanding with others because the goal is not necessarily to, like, explain it the way that I would think of it, but figure out what would help them kind of develop their own mental model for understanding something, and, you know, kind of as long as we both feel like we have that shared understanding, no matter what lens it's through. And, you know, sometimes it's even more effective when we are able to share it. But I feel like, you know, you can still find ways to collaborate on something with a diversity of mental models. +JOËL: Yeah, they're a great way to build self-understanding. They're a great way to sort of build understanding between two people. So, I'm a huge fan of the concept. And part of what I've been doing with my note-taking system is trying to capture those as much as possible. If I'm ever, like, trying to understand a complex topic and I'm like, oh, I think I've got a breakthrough here; I understand it; it's kind of like this, or you can imagine it in this perspective, it's like, write that down. That's gold. +STEPHANIE: Very cool. So, Joël, would you be able to share some of your mental models for enumerator? +JOËL: So, one way that I look at it is the idea that an enumerator is effectively a cursor over a collection. So, you have an array and a regular array; you're either in the middle of iterating through it using something like each, or you're not. You just have a collection of items. Enumerator introduces the idea that you're actually sort of at a position in the array. So, you're sort of focused on, let's say, the third item or the fourth item. You have a cursor there, and you can move that cursor forward as you sort of step through. +But the really cool thing is you can also kind of pause and just pass that cursor on to someone else, and someone else can move the cursor a few steps further down the collection, pause, pass it on to someone else. And it's totally fine. Nobody has to, like, go through an entire, like, each iteration. +STEPHANIE: Yeah. So, when you were talking about cursors, that got me thinking a little bit because I actually have struggled with that concept, especially when it comes to, you know, things code-related. Like, when I've had to work with database things and stuff, like, the idea of a cursor was a little, like, difficult for me to wrap my head around. And I was looking at the methods on enumerator, like the instance methods on enumerator. And one of them actually is what helped me develop this mental model. And I'm excited to see what you think. +But there is a rewind method that basically rewinds the sequence back to its beginning, right? And what that triggered for me was a VHS tape [laughs] and just those, like, car-shaped rewinders for tapes back in the '90s. I don't know if you ever had one in your house, but I did. And I just thought that was such a cool method name because it was very, I don't know, it was just like a word that we use in the English language, right? +So, the idea of, like, tapes, you know, like, cassette tapes or VHS tape kind of also it sounds like it matches well with what you were sharing, too, where it's like, I could pass, I don't know, maybe I, like, listen to a few songs on my cassette tape, and then I give it to someone else, and they can pick up where I left off. And yeah, that was really helpful in understanding, like, a marker of a position a little more than cursor was able to for me. +JOËL: That's really interesting because now I wonder, like, how far we could push that metaphor. So, musical data is encoded on magnetic tape. Cassette tapes typically there are sort of two spools. You start off with all of the tape wound up around one spool, and then as it sort of moves across the read head, it gets wound up on sort of the, I don't know, destination spool. I guess you can call them origin and destination. And because of that, you can sort of be in a, like, partly read state where, you know, half the tape is on the destination spool, half of it is on the origin spool, and you have that read head that's in the middle, and you're just kind of paused there. And you can kind of jump forward in that. +So, I imagine something like that in your metaphor is like an enumerator. Contrast that to imagine just a single spool, which is just we have musical data encoded on magnetic tape, and we wrapped it up on a spool. I feel like that's almost more like a regular array because you don't have that concept of, like, position, or being able to read parts of it or anything like that. It's just, here's some data. +STEPHANIE: Yeah. While you were talking about the two spools, I was thinking about, like, part of what is nice about enumerator is that you can go forward or backwards, right? And that feels a little more possible with that two-spool metaphor [laughs], rather than just unraveling something, where you are kind of discarding what has already been read. +JOËL: The one caveat there is that enumerators can move forward one item at a time. They can only move backwards by jumping back to the beginning. So, you can't step forward or step back. +STEPHANIE: Yeah, that's fair. +JOËL: You step forward, or you, like, rewind to the beginning. I think, in my mind, I was thinking a little bit more about this metaphor. And I think it's also just a metaphor for what's called the External Iterator Pattern. It's one of the classic Gang of Four Patterns, which is what enumerator, the object in Ruby, is an implementation of. I feel like I always see that in the documentation, like, oh, enumerator is an implementation of the External Iterator Pattern. And I just kind of go, what? +STEPHANIE: [laughs] +JOËL: Or maybe I kind of understand the idea of, like, okay, it's a way to, like, be able to step through a collection. But thinking in terms of a cursor or even your model as a cassette tape, I think that gives me a model, not just for enumerators, but then for better understanding that external iterator pattern. Like, I'm now not going to think of if I'm ever reading through the Gang Of Four book, or some other languages say we're an doing External Iterator Pattern, and I'll immediately be like, oh, that's a cursor, or that's a cassette tape. +STEPHANIE: Yeah, very cool. I like it. +JOËL: Another mental model that I have is thinking of enumerator in terms of a lazy collection. This is something that you tend to see more in functional programming languages, so the idea that you have a collection of potentially infinite length, or it could even be unknown length. But each element only sort of comes into being as you attempt to read it. So, it's kind of, like, a potentially infinite chain of Schrodinger's boxes. And you've got to open each of them to find out what's inside. +STEPHANIE: Do you know what this reminded me of? Like elementary school math questions that were like, "What comes next in this pattern?" And it has, like, you know, the first, like, four or five values in a sequence or something. And then, you have to figure out, like, what the next value is. But then, in some ways, you know, I think it can depend on whether your enumerator is using the previous value to determine the next one. But yeah, it's like, you can't just jump ahead to figure out what the 10th, you know, value in this pattern is without kind of knowing what's come before it. +JOËL: And sort of that needing to step through the entire collection, sort of one element at a time. +STEPHANIE: Yeah, exactly. +JOËL: I think a way that that concept is interesting, to me, is situations where a collection might be expensive, and you don't necessarily need all of it. So, you might have a bunch of calculations, but you can stop when you've hit the first one that succeeds or that matches a certain criteria. And so, it's not worth it to calculate the entire array of calculations if you're going to stop at the third one. And you could do that with some sort of, like, loop or something like that. But having it as a collection means you get to just treat it like an array, and you can call detect on it and do all the nice things that you're used to. It just happens to be a little bit more efficient in terms of not creating more data than you need to. +STEPHANIE: Yeah. And I think there's some really cool stuff you can do when you start chaining enumerators with this concept of it being lazy evaluated. So, one of the things I learned in my deep dive is that when you are using the lazy method, you're able to chain enumerators. And they work a bit differently, where the default functionality is, like, everything in the collection gets evaluated through the first method, and then it gets iterated over in the second method. Whereas if you use lazy, I believe how it works is that, like, the first value gets kind of processed by all of the methods. And then, you get, you know, the output before moving on to the second, like, the next value. Does that sound right? +JOËL: Yes. And I think that's where there's often a lot of confusion because there's sort of plain enumerator, and then there's a lazy enumerator that Ruby provides. A plain enumerator is a lazy list in the sense that items don't get evaluated unless you try to reach for them. So, if you have an enumerator and you say, "Just give me the first five items," it will do that. And even if the collection was 200 items long, the next 195 don't get evaluated. So, that's very efficient there. +Where you would get into trouble is that plain enumerators are not lazy when it comes to traversals. So, any method that would traverse the entire collection, so something like a map or a select, is not going to be lazy because it's going to traverse the entire collection, therefore forcing us to evaluate each of the items in there. Whereas something like enumerable lazy will not actually traverse the collection when you do your map or you're selecting. It will wait for you to say, "Give me the first item," or "Give me the first ten items," or something like that. But you don't always need lazy. You really only need lazy when you're doing a traversal method. +STEPHANIE: Okay. Cool, cool, cool. That makes a lot of sense. +JOËL: I think a sort of spinoff metaphor that I have there is this idea of a lazy list. Another concept that, in my mind, is very adjacent to lazy lists is the concept of streams. And streams I typically think of them in terms of, like, files or networking, things like that. But a thing that you can do let's say you're working on data that's in a very large file, so big that you can't fit it into memory, a common solution there is streaming it. So, you don't load the entire file into memory and then operate on it. Instead, little chunks of it are loaded into memory. You operate on them, and then you release that memory and load the next chunk. So, you sort of work through that file in chunks, but you'd only have, you know, 1 line or ten lines or however big your chunk is in memory at a time. +An enumerator allows you to do that with things that are not files. So, this could be a situation where, let's say, you're reading a lot of data from the database. You just have too many rows. You can't load them all into memory at once. But you do want to traverse through them. You could chunk that using enumerator so that every, you know, it loads 100 rows at a time or 1,000 rows at a time, or something like that. And your enumerator allows you to treat that as though it's a single array, even though, in the background, it's being chunked into pieces so that you never have more than a thousand rows at a time in memory. So, it allows you to do some, like, really nice sort of memory performance things. +STEPHANIE: When would you want to use this over kind of something like batching queries? +JOËL: So, I think ActiveRecord findinbatches does something like this under the hood. +STEPHANIE: Oh, cool. +JOËL: I don't know if they use Ruby's enumerator or if they sort of build their own custom extension to it, but it's built on this idea. +STEPHANIE: Okay, that's really neat. I have another mental model that I wanted to get your thoughts on. +JOËL: Yeah! +STEPHANIE: One of the ways that I looked up that you can construct an enumerator, an infinite enumerator like we were talking about a little bit earlier, was with the produce class method. And that actually got me thinking about a production line and this idea that, you know, you have this mechanism for, you know, producing some kind of material or, like, good or something like that. And it's just there and waiting and ready [laughs] for you to, like, kind of ask for it, like, what it needs to do. And you can do that, like, sometimes in batches, right? If you are asking for like, "Okay, I want a thousand units," and then the production line goes to work [laughs]. But yeah, that was another one of those things where I'm like, wow, they really, I think, came up with a cool method name that evoked, like, an image in my head. +JOËL: That's the power of naming, right? And I think it's interesting you've mentioned twice how going through the method names on enumerator and finding different method names all of a sudden, like, turned on a light bulb in your mind. So, if you're naming things well, it can be incredibly useful for users of your library to pick up on what you're trying to do. +So, I want to circle back to something that you mentioned earlier, the idea of elementary school quizzes where you have to, like, figure out the next item in the sequence. Because that, for me, is very similar to my mental model: the idea that an enumerator is a sequence generator. So, instead of thinking of it as, oh, it's like an array or it's some kind of collection, instead, think of it as a robot that I can just ask it, hey, give me a value, and it will give me a value. And then, it will, like, keep doing that as long as I keep asking it for it. And those values, you know, they could be totally random. You can build one of those. +But you can also have it so that the values sort of come from a sequence. It's not like an array where you're like, oh, I'm going to, like, predefine an array of, I don't know, the Fibonacci sequence, and when someone asks me for the third value, I'll just go and read that third value from the array. Instead, it knows the algorithm, and it just says, "Oh, you want the next value in the Fibonacci sequence? Let me calculate it. Here it is. Oh, you want the next value? Here it is." And so, thinking from that perspective helped me really come to terms with the concept that values really do get calculated just in time. It's not really a collection. It's an object that can give you new values if you ask it. +STEPHANIE: Yeah, okay. That is making a lot more sense kind of in conjunction with the lazy list model that you shared earlier, and even a little bit with the production line that I was kind of sharing where it's like, you know, in this case, kind of, it's, like, the potential for a value, right? +JOËL: Right, exactly. And, you know, these are all mental models that converge on the same ideas because they're all just slightly different perspectives on what the same object does. And so, there is going to be some overlap, some converging between all of them. I have another fun one. Can I throw it at you? +STEPHANIE: Please. +JOËL: This one's a little bit different, and it's the idea that enumerators are a tool to bring your own iteration to a collection. So, imagine a situation where you're building your own, let's say, binary tree implementation. And there are multiple ways to traverse through a binary tree. In particular, let's say you're doing depth-first search. There are sort of three classic ways to traverse that are called pre-order, post-order, and in-order traversals. And it really is just sort of what order do you visit all the children in your tree? +Now, the point of a collection, oftentimes, is you need a way to iterate through it. And a classic solution would be to include enumerable, the module. In order to do that, you have to define a way to iterate through your collection. You call that each. And then, enumerable just gives you all the other nice things for free. The question is, though, for something like a tree where there are multiple valid ways to traverse, which one do you pick to make it the each that gets sort of all the enumerable goodies, and then the others are just, like, random methods you've defined? +Because if you define, let's say, pre-order traversal as each, now your detect and select and all those are going to work in pre-order, but the others are not going to get that. So, if you map over a tree, you're forced to map over in pre-order because that's what the library author chose. But what if you want to map over a tree in post-order or in-order? +STEPHANIE: Yeah, well, I'm guessing that here's where enumerator comes in handy [laughs]. +JOËL: Yes. The approach here is instead of designating sort of one of those traversals as the sort of blessed traversal that gets to have enumerable; you build three of these, one for each of these traversals. And then, what's really nice is that because enumerators are themselves enumerable, they have map and select and all of these things built in. +Now you can do something like mytree dot preorder dot map or mytree dot postorder dot map. And you get all the goodies for free, but the users of your library get to basically choose which traversal they want to have. As a library author, you're not forced to pick ahead of time and sort of choose; this is the one I'm going to have. You sort of bring your own traversal by providing an enumerator, and then everything else just kind of falls into place. +STEPHANIE: Bring Your Own Traversal (BYOT) [laughter]. I like it. Yeah, that's cool. I can see how that would be really handy. I have not yet encountered a situation where I needed to get that deep into how my iteration is traversed, but that's really interesting. And, I mean, I can start even imagining, like, having an each method defined in these different ways, and then all of that being able to be composed with some of the other...just other methods. And now you have, like, so many different ways to perhaps, like, help, you know, different performance use cases. +JOËL: Yeah, it can be performance. I often tend to think of enumerator as a performance thing because of its sort of lazy properties because; it allows you to sort of stream or chunk data that you're working with. But in the case of this mental model of the Bring Your Own Traversal, it actually is more about flexibility and having sort of the beauty of Ruby without having to compromise on, oh, I have to pick a single way to traverse a collection. +STEPHANIE: But I really appreciate kind of this discussion about enumerator because this was previously, like, I don't think I have really ever used the class itself to solve a problem, but now I feel a lot more equipped to do so with a couple of the different kind of perspectives. And I think what they helped me do is just prime myself. If I see a problem that might benefit from something being iterated in a lazy way, like, being like, oh, I remember this thing, this mental model. Now I can go kind of look at the documentation for how to use it. And yeah, like, I don't know how I would have stumbled across, like, reaching for it otherwise. +JOËL: That's a really interesting thing to notice because we've been talking a lot about how mental models can be a tool for understanding. But once you build an understanding, even though it's somewhat fuzzy, they're also a great tool for sort of recall. So, not only are you thinking, okay, well, this mental model says enumerators are kind of like this, or they function in this way. +On the flip side of it, you can say, "Well, lazy evaluation problems are often enumerator problems. Like, streaming or chunked data problems are often enumerator problems. Multiple traversals are enumerator problems." So, now, even though you don't, like, fully understand it in your mind, you've got that recall where you can enter it, where you can come across that problem, and immediately you're like, oh, I'm dealing with multiple traversals here. I don't remember exactly how, but somehow, in my mind, I've got a connection that says, "Enumerators are a solution for this. Let me dig into that." +STEPHANIE: Yeah, especially as an alternative to where I would normally reach for something...a more kind of common enumerable method. Because I definitely know that feeling of like, oh, like, I wish it could just, like, do this a little bit differently, you know. And it turns out that, you know, something like that probably exists already. I just needed to know what it was [laughs]. +JOËL: On that theme of I wish that I could have something that behaved just a little bit more...like, I'm doing something slightly weird, and I wish they would behave more, like, just plain Ruby does normally with my, like, collections I'm familiar with. +I'm going to pitch a talk that I gave at RubyConf Mini called "Teaching Ruby to Count." Some of these mental models actually showed up there. But the whole idea is like, oh, if you're bringing in sort of more custom objects and all of that, how can you just tweak them a little bit so that they're just as joyful to use and interact with as arrays, and numbers, and ranges? And they just sort of fit into that beauty of Ruby that we get out of the box. +STEPHANIE: Awesome. On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + note-taking system, software development, Obsidian, mental models, Ruby enumerators, software beliefs, RailsConf, programming confidence, lazy evaluation, sequence generator, custom objects, performance optimization, traversal methods, thoughtbot, The Bike Shed podcast, Stephanie Minn, Joël Quenneville, public works, interconnected notes, conference talks, blog posts, RubyConf Mini + + 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.

+ + + +

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 discovering a few things, too, about, like, what this feature is or could be. And I think those are the things that, you know, need to be brought into a conversation with a broader group and think about, like, is this the direction we want to go? So, that's kind of how I'm bucketing that feedback right now.

+ +

JOËL: How do you feel about receiving direct feedback versus having something filtered through something like a product team?

+ +

STEPHANIE: Ooh, that's an interesting question. Because right now we're doing, I think, a mix of both that I'm not sure that I really like. On one hand, when it's filtered, it's hard to get to the root of what someone is asking for. And oftentimes, like, it may not even include enough information after the fact to be able to come at it from a dev perspective. But then direct feedback, I think, is just a little bit overwhelming sometimes. And it can be hard to figure out what to pay attention to if you don't have that, like, input from a product team about, like, what the roadmap is looking like or where, you know, strategically their heads are at.

+ +

So, one thing that kind of has emerged from this is like, oh, I was getting, you know, notifications for the feedback coming in. And what we did was set up a meeting [laughs] so that we can...maybe all of us can, like, scan it together ahead of time and then come at it with a little bit of context about what's come in but then maybe coalesce around the things that we feel are important.

+ +

JOËL: Well, you'll have to keep us updated on how that plays out, and we can kind of hear what is the balance that ends up working well for you.

+ +

STEPHANIE: Yeah, I hope so. I think this is actually maybe something that's a bit underexplored from the dev perspective, you know, that in-between stage of you're not totally done because it's not shipped to the world yet, but, you know, you're starting to get a little bit of that input. And what you do with that? Because I think there is some value in being engaged in that process.

+ +

JOËL: So, we were talking earlier about this note-taking system that I use and sort of a renewed excitement that I have about it. And one thing that I did when I was going through and finding clusters of things that hadn't been written about was I found that I had a cluster of notes on different mental models that I had for understanding Ruby enumerators, not the enumerable module, but the enumerator object. And I decided, you know what? This would probably make for a good blog post. So, I drafted a blog post, and I've been thinking about this a little bit more recently. So, I've been really hyped about digging into enumerators because of that experience.

+ +

STEPHANIE: Yeah, that's very cool. I have to say that I feel like I did not know a lot about enumerators and the API for them kind of before you brought this topic up, and I did a bit of a deep dive in preparation for us to discuss it. I feel like most devs, you know, work with enumerators via methods on enumerable without totally knowing that they are. So, I think that this would be a really interesting episode for people to be like, oh, like, I've been using this stuff, you know, the whole time, and now I can have a different perspective or just more insight on what they can do.

+ +

JOËL: Before we dig into individual mental models, though, I want to think a little bit about the concept of mental models as a whole. Years ago, someone gave me advice to sort of pay attention to mental models, ways I think about the world or different code structures, different code approaches, and that really stuck with me. So, I've since been, like, kind of, like, collecting mental models.

+ +

And, in a way, they're like a, for me, a bit more of a concrete way to look at a particular topic. So, I can say I'm looking at this particular topic through the lens of a particular mental model that helps me build more clarity around it. And if I have three or four, then I can kind of look at it from three or four different perspectives. And now, all of a sudden, I feel like I'm seeing in three dimensions.

+ +

STEPHANIE: Whoa, the Matrix even [laughs]. That's cool. Yeah, I really like that advice. I think I'm going to steal it and start kind of suggesting it to other people because I think, in a way, on this show, that has come through a lot. And talking about things on the podcast has helped me develop a lot of my mental models. And I think we've done a few, like, episodes in the past about various ones we have for just our work because it's like, that's infinite [laughs]. But what I really have been appreciating is that mental models just need to work for you. As long as you're able to understand something, then it's valuable.

+ +

And that has really helped me also, like, just get on the same understanding with others because the goal is not necessarily to, like, explain it the way that I would think of it, but figure out what would help them kind of develop their own mental model for understanding something, and, you know, kind of as long as we both feel like we have that shared understanding, no matter what lens it's through. And, you know, sometimes it's even more effective when we are able to share it. But I feel like, you know, you can still find ways to collaborate on something with a diversity of mental models.

+ +

JOËL: Yeah, they're a great way to build self-understanding. They're a great way to sort of build understanding between two people. So, I'm a huge fan of the concept. And part of what I've been doing with my note-taking system is trying to capture those as much as possible. If I'm ever, like, trying to understand a complex topic and I'm like, oh, I think I've got a breakthrough here; I understand it; it's kind of like this, or you can imagine it in this perspective, it's like, write that down. That's gold.

+ +

STEPHANIE: Very cool. So, Joël, would you be able to share some of your mental models for enumerator?

+ +

JOËL: So, one way that I look at it is the idea that an enumerator is effectively a cursor over a collection. So, you have an array and a regular array; you're either in the middle of iterating through it using something like each, or you're not. You just have a collection of items. Enumerator introduces the idea that you're actually sort of at a position in the array. So, you're sort of focused on, let's say, the third item or the fourth item. You have a cursor there, and you can move that cursor forward as you sort of step through.

+ +

But the really cool thing is you can also kind of pause and just pass that cursor on to someone else, and someone else can move the cursor a few steps further down the collection, pause, pass it on to someone else. And it's totally fine. Nobody has to, like, go through an entire, like, each iteration.

+ +

STEPHANIE: Yeah. So, when you were talking about cursors, that got me thinking a little bit because I actually have struggled with that concept, especially when it comes to, you know, things code-related. Like, when I've had to work with database things and stuff, like, the idea of a cursor was a little, like, difficult for me to wrap my head around. And I was looking at the methods on enumerator, like the instance methods on enumerator. And one of them actually is what helped me develop this mental model. And I'm excited to see what you think.

+ +

But there is a rewind method that basically rewinds the sequence back to its beginning, right? And what that triggered for me was a VHS tape [laughs] and just those, like, car-shaped rewinders for tapes back in the '90s. I don't know if you ever had one in your house, but I did. And I just thought that was such a cool method name because it was very, I don't know, it was just like a word that we use in the English language, right?

+ +

So, the idea of, like, tapes, you know, like, cassette tapes or VHS tape kind of also it sounds like it matches well with what you were sharing, too, where it's like, I could pass, I don't know, maybe I, like, listen to a few songs on my cassette tape, and then I give it to someone else, and they can pick up where I left off. And yeah, that was really helpful in understanding, like, a marker of a position a little more than cursor was able to for me.

+ +

JOËL: That's really interesting because now I wonder, like, how far we could push that metaphor. So, musical data is encoded on magnetic tape. Cassette tapes typically there are sort of two spools. You start off with all of the tape wound up around one spool, and then as it sort of moves across the read head, it gets wound up on sort of the, I don't know, destination spool. I guess you can call them origin and destination. And because of that, you can sort of be in a, like, partly read state where, you know, half the tape is on the destination spool, half of it is on the origin spool, and you have that read head that's in the middle, and you're just kind of paused there. And you can kind of jump forward in that.

+ +

So, I imagine something like that in your metaphor is like an enumerator. Contrast that to imagine just a single spool, which is just we have musical data encoded on magnetic tape, and we wrapped it up on a spool. I feel like that's almost more like a regular array because you don't have that concept of, like, position, or being able to read parts of it or anything like that. It's just, here's some data.

+ +

STEPHANIE: Yeah. While you were talking about the two spools, I was thinking about, like, part of what is nice about enumerator is that you can go forward or backwards, right? And that feels a little more possible with that two-spool metaphor [laughs], rather than just unraveling something, where you are kind of discarding what has already been read.

+ +

JOËL: The one caveat there is that enumerators can move forward one item at a time. They can only move backwards by jumping back to the beginning. So, you can't step forward or step back.

+ +

STEPHANIE: Yeah, that's fair.

+ +

JOËL: You step forward, or you, like, rewind to the beginning. I think, in my mind, I was thinking a little bit more about this metaphor. And I think it's also just a metaphor for what's called the External Iterator Pattern. It's one of the classic Gang of Four Patterns, which is what enumerator, the object in Ruby, is an implementation of. I feel like I always see that in the documentation, like, oh, enumerator is an implementation of the External Iterator Pattern. And I just kind of go, what?

+ +

STEPHANIE: [laughs]

+ +

JOËL: Or maybe I kind of understand the idea of, like, okay, it's a way to, like, be able to step through a collection. But thinking in terms of a cursor or even your model as a cassette tape, I think that gives me a model, not just for enumerators, but then for better understanding that external iterator pattern. Like, I'm now not going to think of if I'm ever reading through the Gang Of Four book, or some other languages say we're an doing External Iterator Pattern, and I'll immediately be like, oh, that's a cursor, or that's a cassette tape.

+ +

STEPHANIE: Yeah, very cool. I like it.

+ +

JOËL: Another mental model that I have is thinking of enumerator in terms of a lazy collection. This is something that you tend to see more in functional programming languages, so the idea that you have a collection of potentially infinite length, or it could even be unknown length. But each element only sort of comes into being as you attempt to read it. So, it's kind of, like, a potentially infinite chain of Schrodinger's boxes. And you've got to open each of them to find out what's inside.

+ +

STEPHANIE: Do you know what this reminded me of? Like elementary school math questions that were like, "What comes next in this pattern?" And it has, like, you know, the first, like, four or five values in a sequence or something. And then, you have to figure out, like, what the next value is. But then, in some ways, you know, I think it can depend on whether your enumerator is using the previous value to determine the next one. But yeah, it's like, you can't just jump ahead to figure out what the 10th, you know, value in this pattern is without kind of knowing what's come before it.

+ +

JOËL: And sort of that needing to step through the entire collection, sort of one element at a time.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I think a way that that concept is interesting, to me, is situations where a collection might be expensive, and you don't necessarily need all of it. So, you might have a bunch of calculations, but you can stop when you've hit the first one that succeeds or that matches a certain criteria. And so, it's not worth it to calculate the entire array of calculations if you're going to stop at the third one. And you could do that with some sort of, like, loop or something like that. But having it as a collection means you get to just treat it like an array, and you can call detect on it and do all the nice things that you're used to. It just happens to be a little bit more efficient in terms of not creating more data than you need to.

+ +

STEPHANIE: Yeah. And I think there's some really cool stuff you can do when you start chaining enumerators with this concept of it being lazy evaluated. So, one of the things I learned in my deep dive is that when you are using the lazy method, you're able to chain enumerators. And they work a bit differently, where the default functionality is, like, everything in the collection gets evaluated through the first method, and then it gets iterated over in the second method. Whereas if you use lazy, I believe how it works is that, like, the first value gets kind of processed by all of the methods. And then, you get, you know, the output before moving on to the second, like, the next value. Does that sound right?

+ +

JOËL: Yes. And I think that's where there's often a lot of confusion because there's sort of plain enumerator, and then there's a lazy enumerator that Ruby provides. A plain enumerator is a lazy list in the sense that items don't get evaluated unless you try to reach for them. So, if you have an enumerator and you say, "Just give me the first five items," it will do that. And even if the collection was 200 items long, the next 195 don't get evaluated. So, that's very efficient there.

+ +

Where you would get into trouble is that plain enumerators are not lazy when it comes to traversals. So, any method that would traverse the entire collection, so something like a map or a select, is not going to be lazy because it's going to traverse the entire collection, therefore forcing us to evaluate each of the items in there. Whereas something like enumerable lazy will not actually traverse the collection when you do your map or you're selecting. It will wait for you to say, "Give me the first item," or "Give me the first ten items," or something like that. But you don't always need lazy. You really only need lazy when you're doing a traversal method.

+ +

STEPHANIE: Okay. Cool, cool, cool. That makes a lot of sense.

+ +

JOËL: I think a sort of spinoff metaphor that I have there is this idea of a lazy list. Another concept that, in my mind, is very adjacent to lazy lists is the concept of streams. And streams I typically think of them in terms of, like, files or networking, things like that. But a thing that you can do let's say you're working on data that's in a very large file, so big that you can't fit it into memory, a common solution there is streaming it. So, you don't load the entire file into memory and then operate on it. Instead, little chunks of it are loaded into memory. You operate on them, and then you release that memory and load the next chunk. So, you sort of work through that file in chunks, but you'd only have, you know, 1 line or ten lines or however big your chunk is in memory at a time.

+ +

An enumerator allows you to do that with things that are not files. So, this could be a situation where, let's say, you're reading a lot of data from the database. You just have too many rows. You can't load them all into memory at once. But you do want to traverse through them. You could chunk that using enumerator so that every, you know, it loads 100 rows at a time or 1,000 rows at a time, or something like that. And your enumerator allows you to treat that as though it's a single array, even though, in the background, it's being chunked into pieces so that you never have more than a thousand rows at a time in memory. So, it allows you to do some, like, really nice sort of memory performance things.

+ +

STEPHANIE: When would you want to use this over kind of something like batching queries?

+ +

JOËL: So, I think ActiveRecord find_in_batches does something like this under the hood.

+ +

STEPHANIE: Oh, cool.

+ +

JOËL: I don't know if they use Ruby's enumerator or if they sort of build their own custom extension to it, but it's built on this idea.

+ +

STEPHANIE: Okay, that's really neat. I have another mental model that I wanted to get your thoughts on.

+ +

JOËL: Yeah!

+ +

STEPHANIE: One of the ways that I looked up that you can construct an enumerator, an infinite enumerator like we were talking about a little bit earlier, was with the produce class method. And that actually got me thinking about a production line and this idea that, you know, you have this mechanism for, you know, producing some kind of material or, like, good or something like that. And it's just there and waiting and ready [laughs] for you to, like, kind of ask for it, like, what it needs to do. And you can do that, like, sometimes in batches, right? If you are asking for like, "Okay, I want a thousand units," and then the production line goes to work [laughs]. But yeah, that was another one of those things where I'm like, wow, they really, I think, came up with a cool method name that evoked, like, an image in my head.

+ +

JOËL: That's the power of naming, right? And I think it's interesting you've mentioned twice how going through the method names on enumerator and finding different method names all of a sudden, like, turned on a light bulb in your mind. So, if you're naming things well, it can be incredibly useful for users of your library to pick up on what you're trying to do.

+ +

So, I want to circle back to something that you mentioned earlier, the idea of elementary school quizzes where you have to, like, figure out the next item in the sequence. Because that, for me, is very similar to my mental model: the idea that an enumerator is a sequence generator. So, instead of thinking of it as, oh, it's like an array or it's some kind of collection, instead, think of it as a robot that I can just ask it, hey, give me a value, and it will give me a value. And then, it will, like, keep doing that as long as I keep asking it for it. And those values, you know, they could be totally random. You can build one of those.

+ +

But you can also have it so that the values sort of come from a sequence. It's not like an array where you're like, oh, I'm going to, like, predefine an array of, I don't know, the Fibonacci sequence, and when someone asks me for the third value, I'll just go and read that third value from the array. Instead, it knows the algorithm, and it just says, "Oh, you want the next value in the Fibonacci sequence? Let me calculate it. Here it is. Oh, you want the next value? Here it is." And so, thinking from that perspective helped me really come to terms with the concept that values really do get calculated just in time. It's not really a collection. It's an object that can give you new values if you ask it.

+ +

STEPHANIE: Yeah, okay. That is making a lot more sense kind of in conjunction with the lazy list model that you shared earlier, and even a little bit with the production line that I was kind of sharing where it's like, you know, in this case, kind of, it's, like, the potential for a value, right?

+ +

JOËL: Right, exactly. And, you know, these are all mental models that converge on the same ideas because they're all just slightly different perspectives on what the same object does. And so, there is going to be some overlap, some converging between all of them. I have another fun one. Can I throw it at you?

+ +

STEPHANIE: Please.

+ +

JOËL: This one's a little bit different, and it's the idea that enumerators are a tool to bring your own iteration to a collection. So, imagine a situation where you're building your own, let's say, binary tree implementation. And there are multiple ways to traverse through a binary tree. In particular, let's say you're doing depth-first search. There are sort of three classic ways to traverse that are called pre-order, post-order, and in-order traversals. And it really is just sort of what order do you visit all the children in your tree?

+ +

Now, the point of a collection, oftentimes, is you need a way to iterate through it. And a classic solution would be to include enumerable, the module. In order to do that, you have to define a way to iterate through your collection. You call that each. And then, enumerable just gives you all the other nice things for free. The question is, though, for something like a tree where there are multiple valid ways to traverse, which one do you pick to make it the each that gets sort of all the enumerable goodies, and then the others are just, like, random methods you've defined?

+ +

Because if you define, let's say, pre-order traversal as each, now your detect and select and all those are going to work in pre-order, but the others are not going to get that. So, if you map over a tree, you're forced to map over in pre-order because that's what the library author chose. But what if you want to map over a tree in post-order or in-order?

+ +

STEPHANIE: Yeah, well, I'm guessing that here's where enumerator comes in handy [laughs].

+ +

JOËL: Yes. The approach here is instead of designating sort of one of those traversals as the sort of blessed traversal that gets to have enumerable; you build three of these, one for each of these traversals. And then, what's really nice is that because enumerators are themselves enumerable, they have map and select and all of these things built in.

+ +

Now you can do something like mytree dot preorder dot map or mytree dot postorder dot map. And you get all the goodies for free, but the users of your library get to basically choose which traversal they want to have. As a library author, you're not forced to pick ahead of time and sort of choose; this is the one I'm going to have. You sort of bring your own traversal by providing an enumerator, and then everything else just kind of falls into place.

+ +

STEPHANIE: Bring Your Own Traversal (BYOT) [laughter]. I like it. Yeah, that's cool. I can see how that would be really handy. I have not yet encountered a situation where I needed to get that deep into how my iteration is traversed, but that's really interesting. And, I mean, I can start even imagining, like, having an each method defined in these different ways, and then all of that being able to be composed with some of the other...just other methods. And now you have, like, so many different ways to perhaps, like, help, you know, different performance use cases.

+ +

JOËL: Yeah, it can be performance. I often tend to think of enumerator as a performance thing because of its sort of lazy properties because; it allows you to sort of stream or chunk data that you're working with. But in the case of this mental model of the Bring Your Own Traversal, it actually is more about flexibility and having sort of the beauty of Ruby without having to compromise on, oh, I have to pick a single way to traverse a collection.

+ +

STEPHANIE: But I really appreciate kind of this discussion about enumerator because this was previously, like, I don't think I have really ever used the class itself to solve a problem, but now I feel a lot more equipped to do so with a couple of the different kind of perspectives. And I think what they helped me do is just prime myself. If I see a problem that might benefit from something being iterated in a lazy way, like, being like, oh, I remember this thing, this mental model. Now I can go kind of look at the documentation for how to use it. And yeah, like, I don't know how I would have stumbled across, like, reaching for it otherwise.

+ +

JOËL: That's a really interesting thing to notice because we've been talking a lot about how mental models can be a tool for understanding. But once you build an understanding, even though it's somewhat fuzzy, they're also a great tool for sort of recall. So, not only are you thinking, okay, well, this mental model says enumerators are kind of like this, or they function in this way.

+ +

On the flip side of it, you can say, "Well, lazy evaluation problems are often enumerator problems. Like, streaming or chunked data problems are often enumerator problems. Multiple traversals are enumerator problems." So, now, even though you don't, like, fully understand it in your mind, you've got that recall where you can enter it, where you can come across that problem, and immediately you're like, oh, I'm dealing with multiple traversals here. I don't remember exactly how, but somehow, in my mind, I've got a connection that says, "Enumerators are a solution for this. Let me dig into that."

+ +

STEPHANIE: Yeah, especially as an alternative to where I would normally reach for something...a more kind of common enumerable method. Because I definitely know that feeling of like, oh, like, I wish it could just, like, do this a little bit differently, you know. And it turns out that, you know, something like that probably exists already. I just needed to know what it was [laughs].

+ +

JOËL: On that theme of I wish that I could have something that behaved just a little bit more...like, I'm doing something slightly weird, and I wish they would behave more, like, just plain Ruby does normally with my, like, collections I'm familiar with.

+ +

I'm going to pitch a talk that I gave at RubyConf Mini called "Teaching Ruby to Count." Some of these mental models actually showed up there. But the whole idea is like, oh, if you're bringing in sort of more custom objects and all of that, how can you just tweak them a little bit so that they're just as joyful to use and interact with as arrays, and numbers, and ranges? And they just sort of fit into that beauty of Ruby that we get out of the box.

+ +

STEPHANIE: Awesome. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + 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.

+ + + +

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 discovering a few things, too, about, like, what this feature is or could be. And I think those are the things that, you know, need to be brought into a conversation with a broader group and think about, like, is this the direction we want to go? So, that's kind of how I'm bucketing that feedback right now.

+ +

JOËL: How do you feel about receiving direct feedback versus having something filtered through something like a product team?

+ +

STEPHANIE: Ooh, that's an interesting question. Because right now we're doing, I think, a mix of both that I'm not sure that I really like. On one hand, when it's filtered, it's hard to get to the root of what someone is asking for. And oftentimes, like, it may not even include enough information after the fact to be able to come at it from a dev perspective. But then direct feedback, I think, is just a little bit overwhelming sometimes. And it can be hard to figure out what to pay attention to if you don't have that, like, input from a product team about, like, what the roadmap is looking like or where, you know, strategically their heads are at.

+ +

So, one thing that kind of has emerged from this is like, oh, I was getting, you know, notifications for the feedback coming in. And what we did was set up a meeting [laughs] so that we can...maybe all of us can, like, scan it together ahead of time and then come at it with a little bit of context about what's come in but then maybe coalesce around the things that we feel are important.

+ +

JOËL: Well, you'll have to keep us updated on how that plays out, and we can kind of hear what is the balance that ends up working well for you.

+ +

STEPHANIE: Yeah, I hope so. I think this is actually maybe something that's a bit underexplored from the dev perspective, you know, that in-between stage of you're not totally done because it's not shipped to the world yet, but, you know, you're starting to get a little bit of that input. And what you do with that? Because I think there is some value in being engaged in that process.

+ +

JOËL: So, we were talking earlier about this note-taking system that I use and sort of a renewed excitement that I have about it. And one thing that I did when I was going through and finding clusters of things that hadn't been written about was I found that I had a cluster of notes on different mental models that I had for understanding Ruby enumerators, not the enumerable module, but the enumerator object. And I decided, you know what? This would probably make for a good blog post. So, I drafted a blog post, and I've been thinking about this a little bit more recently. So, I've been really hyped about digging into enumerators because of that experience.

+ +

STEPHANIE: Yeah, that's very cool. I have to say that I feel like I did not know a lot about enumerators and the API for them kind of before you brought this topic up, and I did a bit of a deep dive in preparation for us to discuss it. I feel like most devs, you know, work with enumerators via methods on enumerable without totally knowing that they are. So, I think that this would be a really interesting episode for people to be like, oh, like, I've been using this stuff, you know, the whole time, and now I can have a different perspective or just more insight on what they can do.

+ +

JOËL: Before we dig into individual mental models, though, I want to think a little bit about the concept of mental models as a whole. Years ago, someone gave me advice to sort of pay attention to mental models, ways I think about the world or different code structures, different code approaches, and that really stuck with me. So, I've since been, like, kind of, like, collecting mental models.

+ +

And, in a way, they're like a, for me, a bit more of a concrete way to look at a particular topic. So, I can say I'm looking at this particular topic through the lens of a particular mental model that helps me build more clarity around it. And if I have three or four, then I can kind of look at it from three or four different perspectives. And now, all of a sudden, I feel like I'm seeing in three dimensions.

+ +

STEPHANIE: Whoa, the Matrix even [laughs]. That's cool. Yeah, I really like that advice. I think I'm going to steal it and start kind of suggesting it to other people because I think, in a way, on this show, that has come through a lot. And talking about things on the podcast has helped me develop a lot of my mental models. And I think we've done a few, like, episodes in the past about various ones we have for just our work because it's like, that's infinite [laughs]. But what I really have been appreciating is that mental models just need to work for you. As long as you're able to understand something, then it's valuable.

+ +

And that has really helped me also, like, just get on the same understanding with others because the goal is not necessarily to, like, explain it the way that I would think of it, but figure out what would help them kind of develop their own mental model for understanding something, and, you know, kind of as long as we both feel like we have that shared understanding, no matter what lens it's through. And, you know, sometimes it's even more effective when we are able to share it. But I feel like, you know, you can still find ways to collaborate on something with a diversity of mental models.

+ +

JOËL: Yeah, they're a great way to build self-understanding. They're a great way to sort of build understanding between two people. So, I'm a huge fan of the concept. And part of what I've been doing with my note-taking system is trying to capture those as much as possible. If I'm ever, like, trying to understand a complex topic and I'm like, oh, I think I've got a breakthrough here; I understand it; it's kind of like this, or you can imagine it in this perspective, it's like, write that down. That's gold.

+ +

STEPHANIE: Very cool. So, Joël, would you be able to share some of your mental models for enumerator?

+ +

JOËL: So, one way that I look at it is the idea that an enumerator is effectively a cursor over a collection. So, you have an array and a regular array; you're either in the middle of iterating through it using something like each, or you're not. You just have a collection of items. Enumerator introduces the idea that you're actually sort of at a position in the array. So, you're sort of focused on, let's say, the third item or the fourth item. You have a cursor there, and you can move that cursor forward as you sort of step through.

+ +

But the really cool thing is you can also kind of pause and just pass that cursor on to someone else, and someone else can move the cursor a few steps further down the collection, pause, pass it on to someone else. And it's totally fine. Nobody has to, like, go through an entire, like, each iteration.

+ +

STEPHANIE: Yeah. So, when you were talking about cursors, that got me thinking a little bit because I actually have struggled with that concept, especially when it comes to, you know, things code-related. Like, when I've had to work with database things and stuff, like, the idea of a cursor was a little, like, difficult for me to wrap my head around. And I was looking at the methods on enumerator, like the instance methods on enumerator. And one of them actually is what helped me develop this mental model. And I'm excited to see what you think.

+ +

But there is a rewind method that basically rewinds the sequence back to its beginning, right? And what that triggered for me was a VHS tape [laughs] and just those, like, car-shaped rewinders for tapes back in the '90s. I don't know if you ever had one in your house, but I did. And I just thought that was such a cool method name because it was very, I don't know, it was just like a word that we use in the English language, right?

+ +

So, the idea of, like, tapes, you know, like, cassette tapes or VHS tape kind of also it sounds like it matches well with what you were sharing, too, where it's like, I could pass, I don't know, maybe I, like, listen to a few songs on my cassette tape, and then I give it to someone else, and they can pick up where I left off. And yeah, that was really helpful in understanding, like, a marker of a position a little more than cursor was able to for me.

+ +

JOËL: That's really interesting because now I wonder, like, how far we could push that metaphor. So, musical data is encoded on magnetic tape. Cassette tapes typically there are sort of two spools. You start off with all of the tape wound up around one spool, and then as it sort of moves across the read head, it gets wound up on sort of the, I don't know, destination spool. I guess you can call them origin and destination. And because of that, you can sort of be in a, like, partly read state where, you know, half the tape is on the destination spool, half of it is on the origin spool, and you have that read head that's in the middle, and you're just kind of paused there. And you can kind of jump forward in that.

+ +

So, I imagine something like that in your metaphor is like an enumerator. Contrast that to imagine just a single spool, which is just we have musical data encoded on magnetic tape, and we wrapped it up on a spool. I feel like that's almost more like a regular array because you don't have that concept of, like, position, or being able to read parts of it or anything like that. It's just, here's some data.

+ +

STEPHANIE: Yeah. While you were talking about the two spools, I was thinking about, like, part of what is nice about enumerator is that you can go forward or backwards, right? And that feels a little more possible with that two-spool metaphor [laughs], rather than just unraveling something, where you are kind of discarding what has already been read.

+ +

JOËL: The one caveat there is that enumerators can move forward one item at a time. They can only move backwards by jumping back to the beginning. So, you can't step forward or step back.

+ +

STEPHANIE: Yeah, that's fair.

+ +

JOËL: You step forward, or you, like, rewind to the beginning. I think, in my mind, I was thinking a little bit more about this metaphor. And I think it's also just a metaphor for what's called the External Iterator Pattern. It's one of the classic Gang of Four Patterns, which is what enumerator, the object in Ruby, is an implementation of. I feel like I always see that in the documentation, like, oh, enumerator is an implementation of the External Iterator Pattern. And I just kind of go, what?

+ +

STEPHANIE: [laughs]

+ +

JOËL: Or maybe I kind of understand the idea of, like, okay, it's a way to, like, be able to step through a collection. But thinking in terms of a cursor or even your model as a cassette tape, I think that gives me a model, not just for enumerators, but then for better understanding that external iterator pattern. Like, I'm now not going to think of if I'm ever reading through the Gang Of Four book, or some other languages say we're an doing External Iterator Pattern, and I'll immediately be like, oh, that's a cursor, or that's a cassette tape.

+ +

STEPHANIE: Yeah, very cool. I like it.

+ +

JOËL: Another mental model that I have is thinking of enumerator in terms of a lazy collection. This is something that you tend to see more in functional programming languages, so the idea that you have a collection of potentially infinite length, or it could even be unknown length. But each element only sort of comes into being as you attempt to read it. So, it's kind of, like, a potentially infinite chain of Schrodinger's boxes. And you've got to open each of them to find out what's inside.

+ +

STEPHANIE: Do you know what this reminded me of? Like elementary school math questions that were like, "What comes next in this pattern?" And it has, like, you know, the first, like, four or five values in a sequence or something. And then, you have to figure out, like, what the next value is. But then, in some ways, you know, I think it can depend on whether your enumerator is using the previous value to determine the next one. But yeah, it's like, you can't just jump ahead to figure out what the 10th, you know, value in this pattern is without kind of knowing what's come before it.

+ +

JOËL: And sort of that needing to step through the entire collection, sort of one element at a time.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I think a way that that concept is interesting, to me, is situations where a collection might be expensive, and you don't necessarily need all of it. So, you might have a bunch of calculations, but you can stop when you've hit the first one that succeeds or that matches a certain criteria. And so, it's not worth it to calculate the entire array of calculations if you're going to stop at the third one. And you could do that with some sort of, like, loop or something like that. But having it as a collection means you get to just treat it like an array, and you can call detect on it and do all the nice things that you're used to. It just happens to be a little bit more efficient in terms of not creating more data than you need to.

+ +

STEPHANIE: Yeah. And I think there's some really cool stuff you can do when you start chaining enumerators with this concept of it being lazy evaluated. So, one of the things I learned in my deep dive is that when you are using the lazy method, you're able to chain enumerators. And they work a bit differently, where the default functionality is, like, everything in the collection gets evaluated through the first method, and then it gets iterated over in the second method. Whereas if you use lazy, I believe how it works is that, like, the first value gets kind of processed by all of the methods. And then, you get, you know, the output before moving on to the second, like, the next value. Does that sound right?

+ +

JOËL: Yes. And I think that's where there's often a lot of confusion because there's sort of plain enumerator, and then there's a lazy enumerator that Ruby provides. A plain enumerator is a lazy list in the sense that items don't get evaluated unless you try to reach for them. So, if you have an enumerator and you say, "Just give me the first five items," it will do that. And even if the collection was 200 items long, the next 195 don't get evaluated. So, that's very efficient there.

+ +

Where you would get into trouble is that plain enumerators are not lazy when it comes to traversals. So, any method that would traverse the entire collection, so something like a map or a select, is not going to be lazy because it's going to traverse the entire collection, therefore forcing us to evaluate each of the items in there. Whereas something like enumerable lazy will not actually traverse the collection when you do your map or you're selecting. It will wait for you to say, "Give me the first item," or "Give me the first ten items," or something like that. But you don't always need lazy. You really only need lazy when you're doing a traversal method.

+ +

STEPHANIE: Okay. Cool, cool, cool. That makes a lot of sense.

+ +

JOËL: I think a sort of spinoff metaphor that I have there is this idea of a lazy list. Another concept that, in my mind, is very adjacent to lazy lists is the concept of streams. And streams I typically think of them in terms of, like, files or networking, things like that. But a thing that you can do let's say you're working on data that's in a very large file, so big that you can't fit it into memory, a common solution there is streaming it. So, you don't load the entire file into memory and then operate on it. Instead, little chunks of it are loaded into memory. You operate on them, and then you release that memory and load the next chunk. So, you sort of work through that file in chunks, but you'd only have, you know, 1 line or ten lines or however big your chunk is in memory at a time.

+ +

An enumerator allows you to do that with things that are not files. So, this could be a situation where, let's say, you're reading a lot of data from the database. You just have too many rows. You can't load them all into memory at once. But you do want to traverse through them. You could chunk that using enumerator so that every, you know, it loads 100 rows at a time or 1,000 rows at a time, or something like that. And your enumerator allows you to treat that as though it's a single array, even though, in the background, it's being chunked into pieces so that you never have more than a thousand rows at a time in memory. So, it allows you to do some, like, really nice sort of memory performance things.

+ +

STEPHANIE: When would you want to use this over kind of something like batching queries?

+ +

JOËL: So, I think ActiveRecord find_in_batches does something like this under the hood.

+ +

STEPHANIE: Oh, cool.

+ +

JOËL: I don't know if they use Ruby's enumerator or if they sort of build their own custom extension to it, but it's built on this idea.

+ +

STEPHANIE: Okay, that's really neat. I have another mental model that I wanted to get your thoughts on.

+ +

JOËL: Yeah!

+ +

STEPHANIE: One of the ways that I looked up that you can construct an enumerator, an infinite enumerator like we were talking about a little bit earlier, was with the produce class method. And that actually got me thinking about a production line and this idea that, you know, you have this mechanism for, you know, producing some kind of material or, like, good or something like that. And it's just there and waiting and ready [laughs] for you to, like, kind of ask for it, like, what it needs to do. And you can do that, like, sometimes in batches, right? If you are asking for like, "Okay, I want a thousand units," and then the production line goes to work [laughs]. But yeah, that was another one of those things where I'm like, wow, they really, I think, came up with a cool method name that evoked, like, an image in my head.

+ +

JOËL: That's the power of naming, right? And I think it's interesting you've mentioned twice how going through the method names on enumerator and finding different method names all of a sudden, like, turned on a light bulb in your mind. So, if you're naming things well, it can be incredibly useful for users of your library to pick up on what you're trying to do.

+ +

So, I want to circle back to something that you mentioned earlier, the idea of elementary school quizzes where you have to, like, figure out the next item in the sequence. Because that, for me, is very similar to my mental model: the idea that an enumerator is a sequence generator. So, instead of thinking of it as, oh, it's like an array or it's some kind of collection, instead, think of it as a robot that I can just ask it, hey, give me a value, and it will give me a value. And then, it will, like, keep doing that as long as I keep asking it for it. And those values, you know, they could be totally random. You can build one of those.

+ +

But you can also have it so that the values sort of come from a sequence. It's not like an array where you're like, oh, I'm going to, like, predefine an array of, I don't know, the Fibonacci sequence, and when someone asks me for the third value, I'll just go and read that third value from the array. Instead, it knows the algorithm, and it just says, "Oh, you want the next value in the Fibonacci sequence? Let me calculate it. Here it is. Oh, you want the next value? Here it is." And so, thinking from that perspective helped me really come to terms with the concept that values really do get calculated just in time. It's not really a collection. It's an object that can give you new values if you ask it.

+ +

STEPHANIE: Yeah, okay. That is making a lot more sense kind of in conjunction with the lazy list model that you shared earlier, and even a little bit with the production line that I was kind of sharing where it's like, you know, in this case, kind of, it's, like, the potential for a value, right?

+ +

JOËL: Right, exactly. And, you know, these are all mental models that converge on the same ideas because they're all just slightly different perspectives on what the same object does. And so, there is going to be some overlap, some converging between all of them. I have another fun one. Can I throw it at you?

+ +

STEPHANIE: Please.

+ +

JOËL: This one's a little bit different, and it's the idea that enumerators are a tool to bring your own iteration to a collection. So, imagine a situation where you're building your own, let's say, binary tree implementation. And there are multiple ways to traverse through a binary tree. In particular, let's say you're doing depth-first search. There are sort of three classic ways to traverse that are called pre-order, post-order, and in-order traversals. And it really is just sort of what order do you visit all the children in your tree?

+ +

Now, the point of a collection, oftentimes, is you need a way to iterate through it. And a classic solution would be to include enumerable, the module. In order to do that, you have to define a way to iterate through your collection. You call that each. And then, enumerable just gives you all the other nice things for free. The question is, though, for something like a tree where there are multiple valid ways to traverse, which one do you pick to make it the each that gets sort of all the enumerable goodies, and then the others are just, like, random methods you've defined?

+ +

Because if you define, let's say, pre-order traversal as each, now your detect and select and all those are going to work in pre-order, but the others are not going to get that. So, if you map over a tree, you're forced to map over in pre-order because that's what the library author chose. But what if you want to map over a tree in post-order or in-order?

+ +

STEPHANIE: Yeah, well, I'm guessing that here's where enumerator comes in handy [laughs].

+ +

JOËL: Yes. The approach here is instead of designating sort of one of those traversals as the sort of blessed traversal that gets to have enumerable; you build three of these, one for each of these traversals. And then, what's really nice is that because enumerators are themselves enumerable, they have map and select and all of these things built in.

+ +

Now you can do something like mytree dot preorder dot map or mytree dot postorder dot map. And you get all the goodies for free, but the users of your library get to basically choose which traversal they want to have. As a library author, you're not forced to pick ahead of time and sort of choose; this is the one I'm going to have. You sort of bring your own traversal by providing an enumerator, and then everything else just kind of falls into place.

+ +

STEPHANIE: Bring Your Own Traversal (BYOT) [laughter]. I like it. Yeah, that's cool. I can see how that would be really handy. I have not yet encountered a situation where I needed to get that deep into how my iteration is traversed, but that's really interesting. And, I mean, I can start even imagining, like, having an each method defined in these different ways, and then all of that being able to be composed with some of the other...just other methods. And now you have, like, so many different ways to perhaps, like, help, you know, different performance use cases.

+ +

JOËL: Yeah, it can be performance. I often tend to think of enumerator as a performance thing because of its sort of lazy properties because; it allows you to sort of stream or chunk data that you're working with. But in the case of this mental model of the Bring Your Own Traversal, it actually is more about flexibility and having sort of the beauty of Ruby without having to compromise on, oh, I have to pick a single way to traverse a collection.

+ +

STEPHANIE: But I really appreciate kind of this discussion about enumerator because this was previously, like, I don't think I have really ever used the class itself to solve a problem, but now I feel a lot more equipped to do so with a couple of the different kind of perspectives. And I think what they helped me do is just prime myself. If I see a problem that might benefit from something being iterated in a lazy way, like, being like, oh, I remember this thing, this mental model. Now I can go kind of look at the documentation for how to use it. And yeah, like, I don't know how I would have stumbled across, like, reaching for it otherwise.

+ +

JOËL: That's a really interesting thing to notice because we've been talking a lot about how mental models can be a tool for understanding. But once you build an understanding, even though it's somewhat fuzzy, they're also a great tool for sort of recall. So, not only are you thinking, okay, well, this mental model says enumerators are kind of like this, or they function in this way.

+ +

On the flip side of it, you can say, "Well, lazy evaluation problems are often enumerator problems. Like, streaming or chunked data problems are often enumerator problems. Multiple traversals are enumerator problems." So, now, even though you don't, like, fully understand it in your mind, you've got that recall where you can enter it, where you can come across that problem, and immediately you're like, oh, I'm dealing with multiple traversals here. I don't remember exactly how, but somehow, in my mind, I've got a connection that says, "Enumerators are a solution for this. Let me dig into that."

+ +

STEPHANIE: Yeah, especially as an alternative to where I would normally reach for something...a more kind of common enumerable method. Because I definitely know that feeling of like, oh, like, I wish it could just, like, do this a little bit differently, you know. And it turns out that, you know, something like that probably exists already. I just needed to know what it was [laughs].

+ +

JOËL: On that theme of I wish that I could have something that behaved just a little bit more...like, I'm doing something slightly weird, and I wish they would behave more, like, just plain Ruby does normally with my, like, collections I'm familiar with.

+ +

I'm going to pitch a talk that I gave at RubyConf Mini called "Teaching Ruby to Count." Some of these mental models actually showed up there. But the whole idea is like, oh, if you're bringing in sort of more custom objects and all of that, how can you just tweak them a little bit so that they're just as joyful to use and interact with as arrays, and numbers, and ranges? And they just sort of fit into that beauty of Ruby that we get out of the box.

+ +

STEPHANIE: Awesome. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+eACTFMVU + + ]]> + + Joël Quenneville + Stephanie Minn + + + 427: RailsConf Recap and Conversing About Coupling + https://bikeshed.thoughtbot.com/427 + 70624f7b-b256-4405-a066-800448cd754f + Tue, 28 May 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël and Stephanie discuss RailsConf! Joël introduced Turbo features using a "Dungeons & Dragons & Rails" theme, performing as a D&D character to make his talk interactive. Stephanie addressed test pain by connecting it to code coupling. They emphasize continuous improvement as speakers and developers and encourage trying new approaches in talks and code design. + 37:03 + no + + + Joël and Stephanie talk RailsConf! (https://railsconf.org/). Joël shares how he performed as a D&D character, Glittersense the gnome, to make his Turbo features talk entertaining and interactive. Stephanie's talk focused on addressing test pain by connecting it to code coupling, offering practical insights and solutions. +They agree on the importance of continuous improvement as speakers and developers and trying new approaches in talks and code design, and recommend Jared Norman's RailsConf talk on design patterns, too! +That One Thing: Reduce Coupling for More Scalable and Sustainable Software (https://www.informit.com/articles/article.aspx?p=2222816) +Connascence.io (https://connascence.io/) +[Connascence as a vocabulary to discuss coupling](https://thoughtbot.com/blog/connascence-as-a-vocabulary-to-discuss-coupling](https://thoughtbot.com/blog/connascence-as-a-vocabulary-to-discuss-coupling) +The value of specialized vocabulary (https://bikeshed.thoughtbot.com/356?t=0) +Transcript: +We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. +Join for all seven of the weekly sessions or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.  +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, I think I can speak for both of us and say what's new in our world is that you and I just came back from RailsConf in Detroit. +JOËL: Yeah, we were there for, I guess, it's a three-day conference. Both of us were giving talks. +STEPHANIE: Yeah. I don't think we've both spoken at a conference for at least a little over a year, so that was really fun kind of to catch up in person. And there was a whole crew of thoughtboters who were there. Yeah, I feel like we were hanging out, like, a lot [chuckles] all of last week, just seeing each other, talking about, you know, rehearsing our talks and spending time together on...there was, like, a hack day, and we were sitting at the table together. So, I feel like I'm totally caught up on everything that's new in your world, and that's it. That's the end of the show [laughs]. +JOËL: On that note, shall we wrap up? +STEPHANIE: [laughs] That would not be very fair to our listeners. +[laughter] +JOËL: Yeah. So, how was the conference speaking experience for you? +STEPHANIE: Ooh, it was really great this year. I have not spoken at a RailsConf before, so this was actually, I think, a bigger stage than I had experienced before, and I had a great time. I met Ruby friends, new and old, and, yeah, I left feeling very gooeyed, and very energized, and just so grateful for the Rails community [laughs]. Yeah, I had a very lovely time, kind of being a little bit outside my normal life for a few days. And I think my favorite part about these things is just like, anywhere you go, you can kind of just have a shared interest with someone, and you can start a conversation with them. +JOËL: That's really interesting. Do you find yourself just reaching out to strangers at conferences like this? Or do you tend to just hang out with the people that you know? +STEPHANIE: Oh, I think a little bit of both. I like to get meals with people I know. But if I'm just hanging out in, like, the lobby or if I happen to get a seat for a talk and I'm sitting next to someone that I don't know, I find it quite easy to just be like, "Hi, like, I'm Stephanie. Are you excited for this talk?" Or, like, "What good talks have you seen recently?" There's an aspect of, like, the social butterfly that comes out of me when I'm at these things. Because I just don't get to have, like, easy access to, I don't know, people with, like, that shared interest or people who are willing to just have a conversation with you normally, I think. +JOËL: Yeah, would you describe yourself more as an introvert or an extrovert? +STEPHANIE: I am an extroverted introvert [laughter]. I feel like maybe that might be interpreted as a non-answer, but I think I lean more on the introvert side. But you know when you're with a group of people, and there's not, like, a very clear extrovert in that conversation, and then you're like, oh, I have to do the heavy [chuckles] lifting of the social lubrication [laughs] in this conversation, I can step into that role, reluctantly [laughs]. +JOËL: Okay. I like the label that you used, the extrovert introvert, in that I enjoy social situations. I do well in social situations. But they also consume a lot of energy for me. I don't necessarily get sort of recharged by doing social events. So, people will be surprised when they find out that I tend to talk about myself as an introvert because, like, "Oh, but you're, like, you know, you're not awkward. You engage very well in different group situations." +STEPHANIE: You have a podcast [laughs]. +JOËL: And the truth is I enjoy those things, right? I really like social interaction, but it does, after a while, wear me out. +STEPHANIE: Yeah, that makes sense. I did want to spend a little bit of time talking about the talk you gave at RailsConf this year: "Dungeons & Dragons & Rails." +JOËL: I got to have a lot of fun with the theme. The actual content was introducing people to Turbo by building an interactive Dungeons & Dragons character sheet using vanilla Rails and a little bit of Turbo. So, we're not even writing any JavaScript. We're just using the Turbo helpers, a little bit of Action Cable to mimic something a little bit like...people who are in the know might be familiar with the site D&D Beyond, which is kind of the official D&D online character sheet website. Of course, it wasn't anywhere near as fancy because it's a 30-minute talk and showcasing different features, but that's what we were aiming for. +STEPHANIE: Yeah, you know, you've talked a bit about giving talks on the show before, but I wanted to get into what made this one different because I think it could be fun for our listeners. +[laughter] +JOËL: The way I structured this talk so it has a theme. It's about Dungeons & Dragons, and we're building a character sheet. The way I wrote the talk was it's broken up into chapters. Each chapter is teaching a new feature in Turbo that I want to show off. In order to motivate learning each of these features...because I don't like to just say, "Oh, here's a thing that technology can do. Oh, here's a thing that technology can do." That's boring. You need a reason to learn that. So, I needed a reason to say, +"We need to add this to a character sheet." +So, every sort of chapter of the talk opens up with a little narrative portion. We're following this character, Glittersense, the gnome, and he's on adventures. And at different points in the adventures, he's going to do different types of roles or need different stats and things. And so, when we reach the point in the adventure where we need that, we sort of freeze frame and then say, "Okay, let's add that as a feature to the character sheet." +And then, oh no, it turns out that this feature is a little bit more complicated. We're going to have to learn a new Turbo feature to do that. Who would have guessed? And then, we learn a new Turbo feature together. And then, we go back to the narrative portion. The adventures of Glittersense continue. And then, oh no, we're going to need to add another feature to the character sheet. And that's sort of how the talk is structured. +STEPHANIE: Yeah. And you did a really cool thing with the narrative portions, which was you basically performed as Glittersense, the gnome, voice and posture, and a lot of really great acting from you [laughs], in my opinion. +JOËL: That is something that came out pretty late in the talk preparation. So, I knew I wanted this kind of alternating story and code structure. Then, like, the weekend before RailsConf, I'm running through my slide deck, and I realized, you know what? What if instead of narrating Glittersense's adventures, what if I went first person for those sections? Glittersense tells his own story. +And then, from there, it wasn't a big jump to say, you know what? This is D&D. If I'm going first person and narrating, I really should do a voice. And this is a conversation I had with a couple of people at the speaker dinner. And, of course, everyone's like, "You should 100% do the voice." And I was really not feeling confident in my ability to pull it off. So, for the next two nights, because I was speaking on the third day, the next two nights at the conference, in the evenings, I'm in the hotel room in front of the mirror just practicing my gnome voice to try to get something that got the persona of Glitterense, the gnome, across to the audience. +STEPHANIE: How would you describe the persona? +JOËL: Very extra. +STEPHANIE: [laughs] +JOËL: Very high energy. +STEPHANIE: Yes. The name Glittersense is very extra, after all. +JOËL: [laughs]. I punctuated a lot of the things that he says with just high-pitched laughter. He's also...so, the framing device for all of this is that you're in a tavern listening to him tell his adventures. I wanted a little bit of the sense that Glittersense is maybe embellishing a little bit. I think it may be too much to say he's full of himself, but he's definitely making himself to be the hero of the story, and maybe making himself to be slightly cooler than he really was. +STEPHANIE: Yeah. I definitely got, like, a little bit of eccentricity, too, from the persona. And you know when you just, I don't know, meet an older person who has, like, a lot of life experience, and they want to tell you about it [laughter], but you do kind of maybe have a little bit of suspicion around how much they're exaggerating [laughs]. +But it was really fun. Everyone I talked to afterwards, like, loved it. And I got to share the little nugget that, like, oh yeah, and Joël only, like, started doing the voice, like, decided that he was going to do it two days ago. And they were just all really, like, blown away because it seemed so well practiced, and it was really fun. +JOËL: I got to do something really fun, also, with physical space because Glittersense narrates his portion, sort of the story portions, but then the code portions where we're talking about Turbo, I'm talking in my own voice. And so, when I'm talking about Turbo, I'm standing at the lectern. And when I'm Glittersense, I'm kind of off to the side on the stage and doing the voice. +And so, there's this almost, like, two worlds that are inhabited: one by Joël, the speaker, and one by Glittersense, the gnome. And it got to the point where I don't say or do anything. I only move from the lectern to the, like, portion of the stage where Glittersense lives. And the audience starts chuckling and, like, nothing has happened yet, like, no jokes have been told. No voice has happened. No slides have changed. But the anticipation, people know what's coming. +STEPHANIE: Yeah. And I think the best part, what I really found just really fun and, I don't know, every time it happened, I just really enjoyed it, when you transitioned out of Glittersense, the gnome, and back to Joël because you were so nonchalant about it. You kind of, like, straighten up rather than having your little kind of crouchy gnome posture, and then just walk across back to the podium. And then, in your normal voice, go back to just, you know, sharing very...not necessarily dry, but just, like, straight to the point. "And this is, like, how you, you know, create a frame in [laughs] Turbo," as if nothing happened [laughs] when even just, like, you know, 20 seconds ago, you were just enthusing about, like, slaying the bandit, chieftain [laughter] known as Glittersense. +JOËL: Uh-huh. I think, especially when I open, so I get introduced. I'm off stage. I walk onto the stage, and I'm immediately Glittersense. And I'm telling a story, and the intro goes on for, like, quite a while. It's a big story chunk. And then, at some point, I just walk over to the lectern, drop the voice, hit next slide, and it's my title slide. I'm just like, "Okay, now welcome to Dungeons & Dragons on Rails. We're going to build a character sheet together." +STEPHANIE: Yeah, that's exactly the moment I'm thinking of. +JOËL: The walking in as Glittersense and just immediately going to the voice caught everyone by surprise. And then, the, like, oh, he keeps going for this. Is the whole talk going to be like this? And then, the, like, just when you think, oh, he's really going for it, the, like, dropping it and going to the podium and title slide. It wasn't intended to be a funny moment, but I think the contrast and the fact that I just switched over was one of the biggest laughs I got. +STEPHANIE: Yeah, I mean, I think that attests to how good the delivery of it was because that contrast was very felt. So, props to you. +JOËL: I love the idea of, you know, the thought that you put into building a talk and, like, the narrative structure and the pedagogy of the stuff. And, I think, in this particular case, this is almost like a narrative approach called in media res, where you start kind of in the middle. You open your book, or your movie, or whatever in the middle of the story. And then, you kind of come back to the beginning at some point later. So, it starts with some kind of action scene that grabs your attention. So, in this case, my title slide is 10, 15 slides into the talk. +We get immediately started with Glittersense and his adventures. And then, once we're sort of all bought into this world, then we move to the title slide and talk about, okay, we're here to build a character sheet and all that stuff. And I think that it wouldn't have had the same impact if I'd, like, opened with that and then gone into Glittersense's adventures. And that's something that was not the case at the beginning. I really reworked the talk to make it in that order. And I think that the talk had a lot more impact for doing that. +STEPHANIE: Yeah, definitely. I guess I also just wanted to point out that this is very different from all your other talks. And I think it's really cool that, you know, you are a veteran speaker, but you still find ways to do something new and try something that you've never done before, and yeah, find ways, new ways to, like, speak and engage people and teach. I don't know, do you have just any thoughts about why or how you got into a position to be like, "Oh, you know, I'm going to do something super different this time around" [laughs]? +JOËL: So, every talk I give, I try to do something new, something different, to push myself as a speaker to get better. That might be in the writing of the talk; that might be in the delivery. More recently, I've been trying to do more with dynamic presence on stage. So, when I spoke at RubyConf San Diego, I was trying to not just stand at the lectern but to learn to be able to give my talk while also, you know, walking around the stage, looking at the audience, making pauses where it's necessary, not to just be so into the delivery of the talk by just standing at the podium and, like, going through my deck, which is a small thing but I think is an area I wanted to improve in. +This time, I was playing around with some more narrative framing and ended up, yeah, like, pushing it to an extreme. And it works with the theme because inhabiting a character and role-playing is the core part of D&D. Not everybody plays a D&D character by doing a voice. You are a little bit extra if you do that. But it's not uncommon for people to do a voice. And so, it kind of fit perfectly with my theme. I just needed to get the self-confidence to do it. So, thank you to everyone at the speaker dinner that was like, "No, you totally got this. You should do this," because I was feeling very unsure. +STEPHANIE: It really paid off, so... +JOËL: I'd like to circle back to your talk, though. So, you gave, basically, the first talk of the conference. You were the first session after the keynote. A theme that came up multiple times in your talk was this idea of coupling and how it affects different parts of our code and, particularly the way that we structure tests or the way that we feel test pain. How did you, when you were prepping this talk, discover that theme and decide to lift it up? Was that something that you knew ahead of time you wanted to talk about, or did it just sort of emerge as part of the talk preparation process? +STEPHANIE: That's a really great question, and I'm glad you picked up on that. So, my talk was called: "So, Writing Tests Feels Painful. What Now?" Originally, when I came up with this idea, it actually started with coupling. I realized that I wanted to give a talk about coupling because it's just something that I was struggling with or, like, had seen other people struggle with and really wanting kind of a discrete resource, wanting to provide that. +But as I was just thinking about it, I was like, oh, like, there are so many different ways that this could go. On one hand, it was a very like important topic to me, but also maybe too big of a topic. And so, I actually, like, kind of put that on the back burner. And it wasn't until later when I connected it to another...it wasn't necessarily different at all, but just, like, an extension of this idea is, oh, like, people are struggling with coupling in tests or, like, it manifests in tests. And so, I thought maybe that could be the angle that I took on this topic that kind of gave me a little bit more focus. +And I didn't even end up saying like, "Yeah, this talk was, like, born out of just, you know, wrestling with coupling or anything like that." So, it's cool, to me, that you picked up on it as a theme because it was...I had, you know, ended up not being super explicit about it, but it was certainly, like, a thing that was driving the content from my perspective. +JOËL: Interesting. So, it started as a coupling talk and then got sort of focused through the lens of testing. +STEPHANIE: Yeah. And I think there was a part of me that was like, you know, I don't know if I could just teach the concept of coupling, like, by itself without the framing of testing for people who this is, like, a new concept for them. I realized that maybe it would be more effective to be like, "Hey, like, have you experienced test pain? You know, have you had to mock out a billion objects or changed, you know, made one change and then had to fix, like, a million tests subsequently? Then this talk is for you." And then weave in the idea of coupling in it to kind of start to help people feel familiar with it or just, like, identify it without as much, like, jargon as kind of I've seen when I've tried to figure out, like, how to manage it. +JOËL: It's interesting because I think it gives you a, like, concrete, valuable thing to optimize for as opposed to, like, hey, let's lower coupling because then you're writing, you know, quote, unquote, "better code." And you get to feel better about yourself as a programmer because you're doing things the, quote, unquote, "right way." That's very kind of hand-wavy, and I think sometimes leads people down a bad path where they're optimizing things that they shouldn't be. +But the tests give you this very concrete way to say, "Hey, we're not just trying to reach the, like, low score record for the app in terms of coupling. We're trying to reduce test pain. Tests are painful. And that pain is telling us something. It's telling us that we've crossed some sort of threshold for coupling. Let's find ways to reduce it, not so that we can feel good about ourselves, but so that our tests are actually manageable." +STEPHANIE: Yeah, I am really glad you picked up on that, too, because I feel the exact same way when someone just tells me to decouple something or, like, makes a note that, like, oh, this feels really coupled. I don't know what that means necessarily. And it's not very convincing to just be like, "Oh, you should write loosely coupled code [laughs]," at least for me. What you said just now, it's like, it's not to feel good about ourselves, you know, to write code that way, but, actually, to just feel good about our code, period [laughs]. And, yeah, finding that validation through just, like, actually working with code that is easier to change that is the goal, not necessarily to, yeah, kind of pursue some totally subjective, like, metric. +JOËL: So, one of the kinds of coupling that you called out, I think, was where you hardcode a class name of some other class in your object. And that feels, like, really sort of innocuous. Like, of course, my objects can talk to other objects. And maybe I want to, like, refer to a class somewhere. Why is that such a like tricky piece of coupling to work with? +STEPHANIE: It's not necessarily intentional sometimes. Like, you just do it because you're like, well, I need access to this class somewhere, and I happen to already be in this file. So, why not just hard-code it here? I do think it's a little tricky because the file that you're writing might be, like, very far down in, like, your code flow or, like, your code path, like, very far from, like, a controller or any kind of entry point into your system, at least based on what I've seen in a lot of modern Rails apps. And so, I think that coupling gets really, really obscured. +I have found that, like, if I have to kind of write a more, like, a higher level test, like, maybe a request spec or something, there are times when I'm, like, having to deal with a lot of classes just to set stuff up in a test like that that I didn't think I would have to [chuckles] when I first went about trying to just be like, oh, like, let's just figure out how to get a 200 response [laughs] from this request. So, you're really burying perhaps the things that are needed to set up, like, that full path of execution. And sometimes, it only comes out when you're writing a test for it. +JOËL: And you mentioned briefly, in passing, the idea that oftentimes this sort of coupling manifests as a lot of extra test setup because your object that you're trying to test now also needs all these other things that are related in order to be tested. But sometimes even when you hard code a class, though, you can't even just say, "Oh, I want this particular user or something returned." So, you have to then do something like allow this class to receive class method and return, and now you're stubbing. +And I don't know how you feel about stubs in RSpec. I always treat them a little bit like a code smell in the like classic sense of it's not necessarily bad, but maybe pause, take a look, and ask yourself, "Why is that there, and should I do things differently?" +STEPHANIE: Yeah. I ended up having, like, a lot of examples of stubbing in my example because the code had just been set up where that was the only way that you could access those collaborators, essentially, to, like, make an assertion on them, or have them do something different because you actually needed to go into a different path, right? And I was like, yeah, this should feel weird. You should feel a little bad [laughs] or at least, you know, kind of just pay attention to that feeling, even if you can't really do anything about it in that particular instance. +But on the flip side, you know, it's like, yes, it feels a bit strange, you know, but it's not all bad, right? Like, you're kind of learning like, oh, hey, like, I am coupled to this hard-coded class because I am needing to stub, like, a class method that returns it, or that constructs it. And at least you've exposed that, you know, for yourself. +One thing that I was running into a lot in my example, too, was that those things, like, weren't obvious when you were just reading maybe, like, the public methods and trying to figure out what was happening in them because they were wrapped in private methods. I was a little bit conflicted about this because there were times when it was already just a single method call, but then it was just kind of wrapped in a private method that actually hid [laughs] the things, like all the dependencies that were passed as arguments. +And I found that to be, sure, it looks kind of cleaner. But then all you need to do is scroll down [laughs], and then you're like, oh, actually, there's all these other things involved, but it was kind of hidden away for me. And I found that, actually, like, at least when I actually needed to change things, less helpful than I imagine what the, you know, code author intended. Do you have any thoughts about hiding details like that? +JOËL: I'm kind of a big fan. +STEPHANIE: Hmmm. +JOËL: The general idea, I think, is called the single level of abstraction principle. Whatever sort of public method that you're calling is often implemented in terms of...let's say it does a few different things. It's implemented in terms of, like, these sort of high-level concepts. So, whoever is reading the public method doesn't need to like care about the details of how each step is implemented. +So, maybe you're fetching something from an API, and then you're making a database call, and then you're doing some transformation and creating some new objects from it. Having all of the, like, HTTP calls and the ActiveRecord stuff and the, like, transformation all in the public method, yes, there's a lot of complexity happening there, and it makes that obvious. But it also makes it really hard to get a sense of what is happening. +So, I like to say, "Hey, there are four steps. Let's wrap them all each in a private method then you can call all of those in the public method." The public method now sort of reads like a very simple sort of script. First, fetch data from the HTTP API, then fetch some data from the database, then apply this transformation, then create this object. And if I'm mostly caring about what this object does and not the how let's say I'm building some other objects that interact with this, that is the information I want to know. Where I care about the actual implementation of, oh, well, exactly how is the ActiveRecord stuff done when I'm doing internal changes to the object, that's when I care about those private methods. +I think where it gets tricky, and I think that's the point that you were bringing up, is that if you write code in that way, it has to change the heuristics of how you read code to detect complexity. Because, oftentimes, I think a very classic heuristic for code complexity is just line length. If you have a 50-line method, probably there's a lot of complexity there. Maybe there's a lot of coupling. If it's a four-line method that is written at a high level of abstraction that just calls out to private methods, you scan over. You're like, oh, nice and clean. Nothing to see here. Move on. And so, that heuristic doesn't really hold up in a codebase where you're applying this single level of abstraction. Do you think that lines up with your experience? +STEPHANIE: Hmm. As I was listening to you, I was like, yeah, like, that makes total sense to me. But then I also clearly disagreed a little bit [laughs] in my initial...kind of what I was saying initially. And I think it's because that single layer of abstraction was not very well defined. +JOËL: Hmm. That's fair. +STEPHANIE: Yeah. Where, in fact, it was actually misleading. Like, it wanted to be at that level of abstraction, but it really wasn't. Like, it was operating on things at, like, a lower level and wasn't designed with that kind of readability in mind. So, it was more, like, it was just hiding stuff a little bit, at least for me. +And, I think, it certainly would have taken, like, more work to figure out what that code, like, really was meant to convey. It might have taken some refactoring to coalesce at that single level. And that was essentially kind of what I was showing in my talk as, like, how to get to saying, like, "Hey, we actually are operating in the lower level, but I don't think we need to." +There was some amount of, like, looking at all of the how to figure out, like, oh, maybe these things we don't even need to expose in this class. And we kind of got to a place where those details weren't, like, needed in that class at all. So, it's one of those things where it's harder than it sounds [laughs]. +JOËL: It's definitely an art. +STEPHANIE: Yeah. +JOËL: And I think what you're saying about some of the coupling being, like, scattered throughout the class, it's something that I see a lot with situations where you're coupled, not so much to, like, a single class, but to something side effectful. So, you're building some kind of integration with a third-party API, and you're going to have to make a lot of HTTP calls. And each of those might be individually simple, and they're all sort of maybe in different private methods or whatever, or they're interspersed among a larger chunk of logic. And that makes your tests really complicated. But there's no, like, one place you can point at and be like, ooh, that's the one place where there's a lot of complexity. +What's happening here, though, is that your business object that's doing stuff is coupled to the network, and that coupling is going to force you to do some stubbing. It's going to force you to deal with a bunch of side effects that are non-deterministic in your code. And you used the word coalesce earlier that I really liked because I think that's often a situation where you do have to stand back and say, "Look, there's a lot of HTTP going on here. What if I coalesced it all into an object? Now I have two objects: one that's responsible for business logic, and one that's responsible for just the HTTP calls." +And, all of a sudden, the tests just totally simplify. And we've removed some coupling, but that's not something that you would have seen just from reading the code. Because, as you were saying, it's sort of scattered in little bits and pieces throughout your file that don't necessarily catch your eye. +STEPHANIE: Yeah. Which brings me to a blog post that I had found a lot of inspiration from in the talk that I'll link. It's called "That One Thing: Reduce Coupling for More Scalable and Sustainable Software." But it's actually about tests [laughs], even though it doesn't make an appearance in the title of the blog post at all. But this is where I kind of got the idea of necessary versus unnecessary coupling in test. Because I had never thought about how, yeah, like, when you write a test, you are very correctly coupling yourself to at least the method and class under test [laughs], if not also the arguments, right? Or anything else needed to construct what you're testing. +And literally having that listed out for me in this blog post I think it's a...they use some examples in Java. And so, there's, like, a little bit more [laughs] setup involved. But I think they're like, yeah, these are six things that, like, it's mostly fine if you're coupled to these because that's kind of what needs to happen in a test. But, like, even having something to compare a test I wrote to just, like, okay, these are the things I know I need. And then, you can start to see when you've diverged from that list, when you are finding yourself coupled to some internals of your class. +I really...that was actually, like, really helpful for me because, as we talked about earlier, like, it can be kind of communicated so abstractly. But here is, like, a very clear heuristic for when you should at least, like, start to pay attention or be like, oh, this is something that was needed to get the test to run but is now starting to feel a little unnecessary because it's not on this list. +JOËL: That list reminds me, or the idea of a list of things to check out for when thinking about coupling, reminds me of the concept of connascence, which is a fancy word for almost a, like, categorization of different types of coupling because coupling comes in different flavors, some of which are tighter forms of coupling than others. And so, having that vocabulary has been really helpful for me when I'm looking at PRs and code review, or even when I'm refactoring my own code. Kind of like that list that you mentioned that you have, now I have some heuristics to look at that and say, "Oh, can I go from a connascence of position to a connascence of naming, and does that help me?" +STEPHANIE: Yeah, I like that you mentioned the positional connascence because I also came across a really great metaphor for kind of things that need to change together, like, when that makes sense. And it was basically the idea of a dishwasher and a laundry machine [laughs]. I wish I could recall, like, what book this was from. +But it was basically like, oh yeah, like, in theory, you're washing two things. So, maybe they are similar, but then you're like, no, actually, you want these to be a little bit separate because, you know, you don't want to wash your dishes and your clothes in the same machine. I don't know, maybe that exists [laughs], but I don't think it would do a very good job for either goal. +And I think that was really helpful, for me, in imagining, like, the difference between kind of coupling and cohesion, like things that...even just imagining, like, kind of where I'm doing those things in the house, right? It's like, okay, that lives in a separate room. And, like, the kitchen is for the dishes, and that could be like, you know, a module if you will. And, like, laundry happens in the laundry room, and how to kind of just separate those things, even though they also do share some qualities, too. Like, they're both appliances, right? And so, that's the way that they are similar, but they're not the same. +JOËL: You just mentioned the sort of keyword cohesion. And for our listeners who are not familiar with that term, it refers to an object sort of having one thing that it does well. Like, everything in that class sort of works towards the same goal, kind of similar to the idea of the single responsibility principle. +So, in my earlier example, where we're sort of interspersing some business logic, a lot of HTTP requests, and pulling out an object that's focused on HTTP, like everything is based around that, now that object has higher cohesion because it's all doing one thing. So, if you read classic object-oriented literature, the recommendations that you'll typically see are that objects should have high cohesion and low coupling. +STEPHANIE: Yeah. Think of a dishwasher and a washing machine next time [laughs] you come across something like that. Because I feel like those are really great, like, real-life examples of that separation. +JOËL: Did you go to Jared Norman's talk on the third day: "Undervalued: The Most Useful Design Pattern"? +STEPHANIE: No, I didn't. Can you tell me about it? +JOËL: It felt like he was addressing a lot of the same themes as you were but from more of a code perspective than a test perspective. Talking a lot about, again, forms of coupling, dependencies, and then, specifically, one of the tools that he focused on to reduce the coupling that we see is value objects and factory methods to construct those. +So, for any of our listeners who, when the talks come out, watch Stephanie's talk and are like, "Wow, I would love to learn more about this," a great follow-up, Jared Norman's talk: "Undervalued: The Most Useful Design Pattern." +STEPHANIE: Yeah, that's neat because I can see that being a solution to the hard code did class names that we were talking about earlier. And I like how that is kind of, like, a progressive lesson in coupling a little bit. I'm really glad you shared that talk with me because now I'm excited to watch it when it comes out. And in general, I just love learning new vocabulary or finding new ways to speak about this topic with clarity. So, if any of our listeners have just additional mental models for coupling [laughs] different metaphors, different household appliances [laughs], or something like that, I would love to know. +JOËL: You would like that, given that our first episode together was about "The Value Of Specialized Vocabulary." +STEPHANIE: Yeah, it's clearly undervalued. +JOËL: Haha, I see what you did there. +STEPHANIE: Thank you. Thank you very much [laughs]. +JOËL: On that terrible/wonderful pun, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + + Joël and Stephanie talk RailsConf!. Joël shares how he performed as a D&D character, Glittersense the gnome, to make his Turbo features talk entertaining and interactive. Stephanie's talk focused on addressing test pain by connecting it to code coupling, offering practical insights and solutions.

+ +

They agree on the importance of continuous improvement as speakers and developers and trying new approaches in talks and code design, and recommend Jared Norman's RailsConf talk on design patterns, too!

+ + + +

Transcript:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. 

+ +

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, I think I can speak for both of us and say what's new in our world is that you and I just came back from RailsConf in Detroit.

+ +

JOËL: Yeah, we were there for, I guess, it's a three-day conference. Both of us were giving talks.

+ +

STEPHANIE: Yeah. I don't think we've both spoken at a conference for at least a little over a year, so that was really fun kind of to catch up in person. And there was a whole crew of thoughtboters who were there. Yeah, I feel like we were hanging out, like, a lot [chuckles] all of last week, just seeing each other, talking about, you know, rehearsing our talks and spending time together on...there was, like, a hack day, and we were sitting at the table together. So, I feel like I'm totally caught up on everything that's new in your world, and that's it. That's the end of the show [laughs].

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: [laughs] That would not be very fair to our listeners.

+ +

[laughter]

+ +

JOËL: Yeah. So, how was the conference speaking experience for you?

+ +

STEPHANIE: Ooh, it was really great this year. I have not spoken at a RailsConf before, so this was actually, I think, a bigger stage than I had experienced before, and I had a great time. I met Ruby friends, new and old, and, yeah, I left feeling very gooeyed, and very energized, and just so grateful for the Rails community [laughs]. Yeah, I had a very lovely time, kind of being a little bit outside my normal life for a few days. And I think my favorite part about these things is just like, anywhere you go, you can kind of just have a shared interest with someone, and you can start a conversation with them.

+ +

JOËL: That's really interesting. Do you find yourself just reaching out to strangers at conferences like this? Or do you tend to just hang out with the people that you know?

+ +

STEPHANIE: Oh, I think a little bit of both. I like to get meals with people I know. But if I'm just hanging out in, like, the lobby or if I happen to get a seat for a talk and I'm sitting next to someone that I don't know, I find it quite easy to just be like, "Hi, like, I'm Stephanie. Are you excited for this talk?" Or, like, "What good talks have you seen recently?" There's an aspect of, like, the social butterfly that comes out of me when I'm at these things. Because I just don't get to have, like, easy access to, I don't know, people with, like, that shared interest or people who are willing to just have a conversation with you normally, I think.

+ +

JOËL: Yeah, would you describe yourself more as an introvert or an extrovert?

+ +

STEPHANIE: I am an extroverted introvert [laughter]. I feel like maybe that might be interpreted as a non-answer, but I think I lean more on the introvert side. But you know when you're with a group of people, and there's not, like, a very clear extrovert in that conversation, and then you're like, oh, I have to do the heavy [chuckles] lifting of the social lubrication [laughs] in this conversation, I can step into that role, reluctantly [laughs].

+ +

JOËL: Okay. I like the label that you used, the extrovert introvert, in that I enjoy social situations. I do well in social situations. But they also consume a lot of energy for me. I don't necessarily get sort of recharged by doing social events. So, people will be surprised when they find out that I tend to talk about myself as an introvert because, like, "Oh, but you're, like, you know, you're not awkward. You engage very well in different group situations."

+ +

STEPHANIE: You have a podcast [laughs].

+ +

JOËL: And the truth is I enjoy those things, right? I really like social interaction, but it does, after a while, wear me out.

+ +

STEPHANIE: Yeah, that makes sense. I did want to spend a little bit of time talking about the talk you gave at RailsConf this year: "Dungeons & Dragons & Rails."

+ +

JOËL: I got to have a lot of fun with the theme. The actual content was introducing people to Turbo by building an interactive Dungeons & Dragons character sheet using vanilla Rails and a little bit of Turbo. So, we're not even writing any JavaScript. We're just using the Turbo helpers, a little bit of Action Cable to mimic something a little bit like...people who are in the know might be familiar with the site D&D Beyond, which is kind of the official D&D online character sheet website. Of course, it wasn't anywhere near as fancy because it's a 30-minute talk and showcasing different features, but that's what we were aiming for.

+ +

STEPHANIE: Yeah, you know, you've talked a bit about giving talks on the show before, but I wanted to get into what made this one different because I think it could be fun for our listeners.

+ +

[laughter]

+ +

JOËL: The way I structured this talk so it has a theme. It's about Dungeons & Dragons, and we're building a character sheet. The way I wrote the talk was it's broken up into chapters. Each chapter is teaching a new feature in Turbo that I want to show off. In order to motivate learning each of these features...because I don't like to just say, "Oh, here's a thing that technology can do. Oh, here's a thing that technology can do." That's boring. You need a reason to learn that. So, I needed a reason to say,
+"We need to add this to a character sheet."

+ +

So, every sort of chapter of the talk opens up with a little narrative portion. We're following this character, Glittersense, the gnome, and he's on adventures. And at different points in the adventures, he's going to do different types of roles or need different stats and things. And so, when we reach the point in the adventure where we need that, we sort of freeze frame and then say, "Okay, let's add that as a feature to the character sheet."

+ +

And then, oh no, it turns out that this feature is a little bit more complicated. We're going to have to learn a new Turbo feature to do that. Who would have guessed? And then, we learn a new Turbo feature together. And then, we go back to the narrative portion. The adventures of Glittersense continue. And then, oh no, we're going to need to add another feature to the character sheet. And that's sort of how the talk is structured.

+ +

STEPHANIE: Yeah. And you did a really cool thing with the narrative portions, which was you basically performed as Glittersense, the gnome, voice and posture, and a lot of really great acting from you [laughs], in my opinion.

+ +

JOËL: That is something that came out pretty late in the talk preparation. So, I knew I wanted this kind of alternating story and code structure. Then, like, the weekend before RailsConf, I'm running through my slide deck, and I realized, you know what? What if instead of narrating Glittersense's adventures, what if I went first person for those sections? Glittersense tells his own story.

+ +

And then, from there, it wasn't a big jump to say, you know what? This is D&D. If I'm going first person and narrating, I really should do a voice. And this is a conversation I had with a couple of people at the speaker dinner. And, of course, everyone's like, "You should 100% do the voice." And I was really not feeling confident in my ability to pull it off. So, for the next two nights, because I was speaking on the third day, the next two nights at the conference, in the evenings, I'm in the hotel room in front of the mirror just practicing my gnome voice to try to get something that got the persona of Glitterense, the gnome, across to the audience.

+ +

STEPHANIE: How would you describe the persona?

+ +

JOËL: Very extra.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Very high energy.

+ +

STEPHANIE: Yes. The name Glittersense is very extra, after all.

+ +

JOËL: [laughs]. I punctuated a lot of the things that he says with just high-pitched laughter. He's also...so, the framing device for all of this is that you're in a tavern listening to him tell his adventures. I wanted a little bit of the sense that Glittersense is maybe embellishing a little bit. I think it may be too much to say he's full of himself, but he's definitely making himself to be the hero of the story, and maybe making himself to be slightly cooler than he really was.

+ +

STEPHANIE: Yeah. I definitely got, like, a little bit of eccentricity, too, from the persona. And you know when you just, I don't know, meet an older person who has, like, a lot of life experience, and they want to tell you about it [laughter], but you do kind of maybe have a little bit of suspicion around how much they're exaggerating [laughs].

+ +

But it was really fun. Everyone I talked to afterwards, like, loved it. And I got to share the little nugget that, like, oh yeah, and Joël only, like, started doing the voice, like, decided that he was going to do it two days ago. And they were just all really, like, blown away because it seemed so well practiced, and it was really fun.

+ +

JOËL: I got to do something really fun, also, with physical space because Glittersense narrates his portion, sort of the story portions, but then the code portions where we're talking about Turbo, I'm talking in my own voice. And so, when I'm talking about Turbo, I'm standing at the lectern. And when I'm Glittersense, I'm kind of off to the side on the stage and doing the voice.

+ +

And so, there's this almost, like, two worlds that are inhabited: one by Joël, the speaker, and one by Glittersense, the gnome. And it got to the point where I don't say or do anything. I only move from the lectern to the, like, portion of the stage where Glittersense lives. And the audience starts chuckling and, like, nothing has happened yet, like, no jokes have been told. No voice has happened. No slides have changed. But the anticipation, people know what's coming.

+ +

STEPHANIE: Yeah. And I think the best part, what I really found just really fun and, I don't know, every time it happened, I just really enjoyed it, when you transitioned out of Glittersense, the gnome, and back to Joël because you were so nonchalant about it. You kind of, like, straighten up rather than having your little kind of crouchy gnome posture, and then just walk across back to the podium. And then, in your normal voice, go back to just, you know, sharing very...not necessarily dry, but just, like, straight to the point. "And this is, like, how you, you know, create a frame in [laughs] Turbo," as if nothing happened [laughs] when even just, like, you know, 20 seconds ago, you were just enthusing about, like, slaying the bandit, chieftain [laughter] known as Glittersense.

+ +

JOËL: Uh-huh. I think, especially when I open, so I get introduced. I'm off stage. I walk onto the stage, and I'm immediately Glittersense. And I'm telling a story, and the intro goes on for, like, quite a while. It's a big story chunk. And then, at some point, I just walk over to the lectern, drop the voice, hit next slide, and it's my title slide. I'm just like, "Okay, now welcome to Dungeons & Dragons on Rails. We're going to build a character sheet together."

+ +

STEPHANIE: Yeah, that's exactly the moment I'm thinking of.

+ +

JOËL: The walking in as Glittersense and just immediately going to the voice caught everyone by surprise. And then, the, like, oh, he keeps going for this. Is the whole talk going to be like this? And then, the, like, just when you think, oh, he's really going for it, the, like, dropping it and going to the podium and title slide. It wasn't intended to be a funny moment, but I think the contrast and the fact that I just switched over was one of the biggest laughs I got.

+ +

STEPHANIE: Yeah, I mean, I think that attests to how good the delivery of it was because that contrast was very felt. So, props to you.

+ +

JOËL: I love the idea of, you know, the thought that you put into building a talk and, like, the narrative structure and the pedagogy of the stuff. And, I think, in this particular case, this is almost like a narrative approach called in media res, where you start kind of in the middle. You open your book, or your movie, or whatever in the middle of the story. And then, you kind of come back to the beginning at some point later. So, it starts with some kind of action scene that grabs your attention. So, in this case, my title slide is 10, 15 slides into the talk.

+ +

We get immediately started with Glittersense and his adventures. And then, once we're sort of all bought into this world, then we move to the title slide and talk about, okay, we're here to build a character sheet and all that stuff. And I think that it wouldn't have had the same impact if I'd, like, opened with that and then gone into Glittersense's adventures. And that's something that was not the case at the beginning. I really reworked the talk to make it in that order. And I think that the talk had a lot more impact for doing that.

+ +

STEPHANIE: Yeah, definitely. I guess I also just wanted to point out that this is very different from all your other talks. And I think it's really cool that, you know, you are a veteran speaker, but you still find ways to do something new and try something that you've never done before, and yeah, find ways, new ways to, like, speak and engage people and teach. I don't know, do you have just any thoughts about why or how you got into a position to be like, "Oh, you know, I'm going to do something super different this time around" [laughs]?

+ +

JOËL: So, every talk I give, I try to do something new, something different, to push myself as a speaker to get better. That might be in the writing of the talk; that might be in the delivery. More recently, I've been trying to do more with dynamic presence on stage. So, when I spoke at RubyConf San Diego, I was trying to not just stand at the lectern but to learn to be able to give my talk while also, you know, walking around the stage, looking at the audience, making pauses where it's necessary, not to just be so into the delivery of the talk by just standing at the podium and, like, going through my deck, which is a small thing but I think is an area I wanted to improve in.

+ +

This time, I was playing around with some more narrative framing and ended up, yeah, like, pushing it to an extreme. And it works with the theme because inhabiting a character and role-playing is the core part of D&D. Not everybody plays a D&D character by doing a voice. You are a little bit extra if you do that. But it's not uncommon for people to do a voice. And so, it kind of fit perfectly with my theme. I just needed to get the self-confidence to do it. So, thank you to everyone at the speaker dinner that was like, "No, you totally got this. You should do this," because I was feeling very unsure.

+ +

STEPHANIE: It really paid off, so...

+ +

JOËL: I'd like to circle back to your talk, though. So, you gave, basically, the first talk of the conference. You were the first session after the keynote. A theme that came up multiple times in your talk was this idea of coupling and how it affects different parts of our code and, particularly the way that we structure tests or the way that we feel test pain. How did you, when you were prepping this talk, discover that theme and decide to lift it up? Was that something that you knew ahead of time you wanted to talk about, or did it just sort of emerge as part of the talk preparation process?

+ +

STEPHANIE: That's a really great question, and I'm glad you picked up on that. So, my talk was called: "So, Writing Tests Feels Painful. What Now?" Originally, when I came up with this idea, it actually started with coupling. I realized that I wanted to give a talk about coupling because it's just something that I was struggling with or, like, had seen other people struggle with and really wanting kind of a discrete resource, wanting to provide that.

+ +

But as I was just thinking about it, I was like, oh, like, there are so many different ways that this could go. On one hand, it was a very like important topic to me, but also maybe too big of a topic. And so, I actually, like, kind of put that on the back burner. And it wasn't until later when I connected it to another...it wasn't necessarily different at all, but just, like, an extension of this idea is, oh, like, people are struggling with coupling in tests or, like, it manifests in tests. And so, I thought maybe that could be the angle that I took on this topic that kind of gave me a little bit more focus.

+ +

And I didn't even end up saying like, "Yeah, this talk was, like, born out of just, you know, wrestling with coupling or anything like that." So, it's cool, to me, that you picked up on it as a theme because it was...I had, you know, ended up not being super explicit about it, but it was certainly, like, a thing that was driving the content from my perspective.

+ +

JOËL: Interesting. So, it started as a coupling talk and then got sort of focused through the lens of testing.

+ +

STEPHANIE: Yeah. And I think there was a part of me that was like, you know, I don't know if I could just teach the concept of coupling, like, by itself without the framing of testing for people who this is, like, a new concept for them. I realized that maybe it would be more effective to be like, "Hey, like, have you experienced test pain? You know, have you had to mock out a billion objects or changed, you know, made one change and then had to fix, like, a million tests subsequently? Then this talk is for you." And then weave in the idea of coupling in it to kind of start to help people feel familiar with it or just, like, identify it without as much, like, jargon as kind of I've seen when I've tried to figure out, like, how to manage it.

+ +

JOËL: It's interesting because I think it gives you a, like, concrete, valuable thing to optimize for as opposed to, like, hey, let's lower coupling because then you're writing, you know, quote, unquote, "better code." And you get to feel better about yourself as a programmer because you're doing things the, quote, unquote, "right way." That's very kind of hand-wavy, and I think sometimes leads people down a bad path where they're optimizing things that they shouldn't be.

+ +

But the tests give you this very concrete way to say, "Hey, we're not just trying to reach the, like, low score record for the app in terms of coupling. We're trying to reduce test pain. Tests are painful. And that pain is telling us something. It's telling us that we've crossed some sort of threshold for coupling. Let's find ways to reduce it, not so that we can feel good about ourselves, but so that our tests are actually manageable."

+ +

STEPHANIE: Yeah, I am really glad you picked up on that, too, because I feel the exact same way when someone just tells me to decouple something or, like, makes a note that, like, oh, this feels really coupled. I don't know what that means necessarily. And it's not very convincing to just be like, "Oh, you should write loosely coupled code [laughs]," at least for me. What you said just now, it's like, it's not to feel good about ourselves, you know, to write code that way, but, actually, to just feel good about our code, period [laughs]. And, yeah, finding that validation through just, like, actually working with code that is easier to change that is the goal, not necessarily to, yeah, kind of pursue some totally subjective, like, metric.

+ +

JOËL: So, one of the kinds of coupling that you called out, I think, was where you hardcode a class name of some other class in your object. And that feels, like, really sort of innocuous. Like, of course, my objects can talk to other objects. And maybe I want to, like, refer to a class somewhere. Why is that such a like tricky piece of coupling to work with?

+ +

STEPHANIE: It's not necessarily intentional sometimes. Like, you just do it because you're like, well, I need access to this class somewhere, and I happen to already be in this file. So, why not just hard-code it here? I do think it's a little tricky because the file that you're writing might be, like, very far down in, like, your code flow or, like, your code path, like, very far from, like, a controller or any kind of entry point into your system, at least based on what I've seen in a lot of modern Rails apps. And so, I think that coupling gets really, really obscured.

+ +

I have found that, like, if I have to kind of write a more, like, a higher level test, like, maybe a request spec or something, there are times when I'm, like, having to deal with a lot of classes just to set stuff up in a test like that that I didn't think I would have to [chuckles] when I first went about trying to just be like, oh, like, let's just figure out how to get a 200 response [laughs] from this request. So, you're really burying perhaps the things that are needed to set up, like, that full path of execution. And sometimes, it only comes out when you're writing a test for it.

+ +

JOËL: And you mentioned briefly, in passing, the idea that oftentimes this sort of coupling manifests as a lot of extra test setup because your object that you're trying to test now also needs all these other things that are related in order to be tested. But sometimes even when you hard code a class, though, you can't even just say, "Oh, I want this particular user or something returned." So, you have to then do something like allow this class to receive class method and return, and now you're stubbing.

+ +

And I don't know how you feel about stubs in RSpec. I always treat them a little bit like a code smell in the like classic sense of it's not necessarily bad, but maybe pause, take a look, and ask yourself, "Why is that there, and should I do things differently?"

+ +

STEPHANIE: Yeah. I ended up having, like, a lot of examples of stubbing in my example because the code had just been set up where that was the only way that you could access those collaborators, essentially, to, like, make an assertion on them, or have them do something different because you actually needed to go into a different path, right? And I was like, yeah, this should feel weird. You should feel a little bad [laughs] or at least, you know, kind of just pay attention to that feeling, even if you can't really do anything about it in that particular instance.

+ +

But on the flip side, you know, it's like, yes, it feels a bit strange, you know, but it's not all bad, right? Like, you're kind of learning like, oh, hey, like, I am coupled to this hard-coded class because I am needing to stub, like, a class method that returns it, or that constructs it. And at least you've exposed that, you know, for yourself.

+ +

One thing that I was running into a lot in my example, too, was that those things, like, weren't obvious when you were just reading maybe, like, the public methods and trying to figure out what was happening in them because they were wrapped in private methods. I was a little bit conflicted about this because there were times when it was already just a single method call, but then it was just kind of wrapped in a private method that actually hid [laughs] the things, like all the dependencies that were passed as arguments.

+ +

And I found that to be, sure, it looks kind of cleaner. But then all you need to do is scroll down [laughs], and then you're like, oh, actually, there's all these other things involved, but it was kind of hidden away for me. And I found that, actually, like, at least when I actually needed to change things, less helpful than I imagine what the, you know, code author intended. Do you have any thoughts about hiding details like that?

+ +

JOËL: I'm kind of a big fan.

+ +

STEPHANIE: Hmmm.

+ +

JOËL: The general idea, I think, is called the single level of abstraction principle. Whatever sort of public method that you're calling is often implemented in terms of...let's say it does a few different things. It's implemented in terms of, like, these sort of high-level concepts. So, whoever is reading the public method doesn't need to like care about the details of how each step is implemented.

+ +

So, maybe you're fetching something from an API, and then you're making a database call, and then you're doing some transformation and creating some new objects from it. Having all of the, like, HTTP calls and the ActiveRecord stuff and the, like, transformation all in the public method, yes, there's a lot of complexity happening there, and it makes that obvious. But it also makes it really hard to get a sense of what is happening.

+ +

So, I like to say, "Hey, there are four steps. Let's wrap them all each in a private method then you can call all of those in the public method." The public method now sort of reads like a very simple sort of script. First, fetch data from the HTTP API, then fetch some data from the database, then apply this transformation, then create this object. And if I'm mostly caring about what this object does and not the how let's say I'm building some other objects that interact with this, that is the information I want to know. Where I care about the actual implementation of, oh, well, exactly how is the ActiveRecord stuff done when I'm doing internal changes to the object, that's when I care about those private methods.

+ +

I think where it gets tricky, and I think that's the point that you were bringing up, is that if you write code in that way, it has to change the heuristics of how you read code to detect complexity. Because, oftentimes, I think a very classic heuristic for code complexity is just line length. If you have a 50-line method, probably there's a lot of complexity there. Maybe there's a lot of coupling. If it's a four-line method that is written at a high level of abstraction that just calls out to private methods, you scan over. You're like, oh, nice and clean. Nothing to see here. Move on. And so, that heuristic doesn't really hold up in a codebase where you're applying this single level of abstraction. Do you think that lines up with your experience?

+ +

STEPHANIE: Hmm. As I was listening to you, I was like, yeah, like, that makes total sense to me. But then I also clearly disagreed a little bit [laughs] in my initial...kind of what I was saying initially. And I think it's because that single layer of abstraction was not very well defined.

+ +

JOËL: Hmm. That's fair.

+ +

STEPHANIE: Yeah. Where, in fact, it was actually misleading. Like, it wanted to be at that level of abstraction, but it really wasn't. Like, it was operating on things at, like, a lower level and wasn't designed with that kind of readability in mind. So, it was more, like, it was just hiding stuff a little bit, at least for me.

+ +

And, I think, it certainly would have taken, like, more work to figure out what that code, like, really was meant to convey. It might have taken some refactoring to coalesce at that single level. And that was essentially kind of what I was showing in my talk as, like, how to get to saying, like, "Hey, we actually are operating in the lower level, but I don't think we need to."

+ +

There was some amount of, like, looking at all of the how to figure out, like, oh, maybe these things we don't even need to expose in this class. And we kind of got to a place where those details weren't, like, needed in that class at all. So, it's one of those things where it's harder than it sounds [laughs].

+ +

JOËL: It's definitely an art.

+ +

STEPHANIE: Yeah.

+ +

JOËL: And I think what you're saying about some of the coupling being, like, scattered throughout the class, it's something that I see a lot with situations where you're coupled, not so much to, like, a single class, but to something side effectful. So, you're building some kind of integration with a third-party API, and you're going to have to make a lot of HTTP calls. And each of those might be individually simple, and they're all sort of maybe in different private methods or whatever, or they're interspersed among a larger chunk of logic. And that makes your tests really complicated. But there's no, like, one place you can point at and be like, ooh, that's the one place where there's a lot of complexity.

+ +

What's happening here, though, is that your business object that's doing stuff is coupled to the network, and that coupling is going to force you to do some stubbing. It's going to force you to deal with a bunch of side effects that are non-deterministic in your code. And you used the word coalesce earlier that I really liked because I think that's often a situation where you do have to stand back and say, "Look, there's a lot of HTTP going on here. What if I coalesced it all into an object? Now I have two objects: one that's responsible for business logic, and one that's responsible for just the HTTP calls."

+ +

And, all of a sudden, the tests just totally simplify. And we've removed some coupling, but that's not something that you would have seen just from reading the code. Because, as you were saying, it's sort of scattered in little bits and pieces throughout your file that don't necessarily catch your eye.

+ +

STEPHANIE: Yeah. Which brings me to a blog post that I had found a lot of inspiration from in the talk that I'll link. It's called "That One Thing: Reduce Coupling for More Scalable and Sustainable Software." But it's actually about tests [laughs], even though it doesn't make an appearance in the title of the blog post at all. But this is where I kind of got the idea of necessary versus unnecessary coupling in test. Because I had never thought about how, yeah, like, when you write a test, you are very correctly coupling yourself to at least the method and class under test [laughs], if not also the arguments, right? Or anything else needed to construct what you're testing.

+ +

And literally having that listed out for me in this blog post I think it's a...they use some examples in Java. And so, there's, like, a little bit more [laughs] setup involved. But I think they're like, yeah, these are six things that, like, it's mostly fine if you're coupled to these because that's kind of what needs to happen in a test. But, like, even having something to compare a test I wrote to just, like, okay, these are the things I know I need. And then, you can start to see when you've diverged from that list, when you are finding yourself coupled to some internals of your class.

+ +

I really...that was actually, like, really helpful for me because, as we talked about earlier, like, it can be kind of communicated so abstractly. But here is, like, a very clear heuristic for when you should at least, like, start to pay attention or be like, oh, this is something that was needed to get the test to run but is now starting to feel a little unnecessary because it's not on this list.

+ +

JOËL: That list reminds me, or the idea of a list of things to check out for when thinking about coupling, reminds me of the concept of connascence, which is a fancy word for almost a, like, categorization of different types of coupling because coupling comes in different flavors, some of which are tighter forms of coupling than others. And so, having that vocabulary has been really helpful for me when I'm looking at PRs and code review, or even when I'm refactoring my own code. Kind of like that list that you mentioned that you have, now I have some heuristics to look at that and say, "Oh, can I go from a connascence of position to a connascence of naming, and does that help me?"

+ +

STEPHANIE: Yeah, I like that you mentioned the positional connascence because I also came across a really great metaphor for kind of things that need to change together, like, when that makes sense. And it was basically the idea of a dishwasher and a laundry machine [laughs]. I wish I could recall, like, what book this was from.

+ +

But it was basically like, oh yeah, like, in theory, you're washing two things. So, maybe they are similar, but then you're like, no, actually, you want these to be a little bit separate because, you know, you don't want to wash your dishes and your clothes in the same machine. I don't know, maybe that exists [laughs], but I don't think it would do a very good job for either goal.

+ +

And I think that was really helpful, for me, in imagining, like, the difference between kind of coupling and cohesion, like things that...even just imagining, like, kind of where I'm doing those things in the house, right? It's like, okay, that lives in a separate room. And, like, the kitchen is for the dishes, and that could be like, you know, a module if you will. And, like, laundry happens in the laundry room, and how to kind of just separate those things, even though they also do share some qualities, too. Like, they're both appliances, right? And so, that's the way that they are similar, but they're not the same.

+ +

JOËL: You just mentioned the sort of keyword cohesion. And for our listeners who are not familiar with that term, it refers to an object sort of having one thing that it does well. Like, everything in that class sort of works towards the same goal, kind of similar to the idea of the single responsibility principle.

+ +

So, in my earlier example, where we're sort of interspersing some business logic, a lot of HTTP requests, and pulling out an object that's focused on HTTP, like everything is based around that, now that object has higher cohesion because it's all doing one thing. So, if you read classic object-oriented literature, the recommendations that you'll typically see are that objects should have high cohesion and low coupling.

+ +

STEPHANIE: Yeah. Think of a dishwasher and a washing machine next time [laughs] you come across something like that. Because I feel like those are really great, like, real-life examples of that separation.

+ +

JOËL: Did you go to Jared Norman's talk on the third day: "Undervalued: The Most Useful Design Pattern"?

+ +

STEPHANIE: No, I didn't. Can you tell me about it?

+ +

JOËL: It felt like he was addressing a lot of the same themes as you were but from more of a code perspective than a test perspective. Talking a lot about, again, forms of coupling, dependencies, and then, specifically, one of the tools that he focused on to reduce the coupling that we see is value objects and factory methods to construct those.

+ +

So, for any of our listeners who, when the talks come out, watch Stephanie's talk and are like, "Wow, I would love to learn more about this," a great follow-up, Jared Norman's talk: "Undervalued: The Most Useful Design Pattern."

+ +

STEPHANIE: Yeah, that's neat because I can see that being a solution to the hard code did class names that we were talking about earlier. And I like how that is kind of, like, a progressive lesson in coupling a little bit. I'm really glad you shared that talk with me because now I'm excited to watch it when it comes out. And in general, I just love learning new vocabulary or finding new ways to speak about this topic with clarity. So, if any of our listeners have just additional mental models for coupling [laughs] different metaphors, different household appliances [laughs], or something like that, I would love to know.

+ +

JOËL: You would like that, given that our first episode together was about "The Value Of Specialized Vocabulary."

+ +

STEPHANIE: Yeah, it's clearly undervalued.

+ +

JOËL: Haha, I see what you did there.

+ +

STEPHANIE: Thank you. Thank you very much [laughs].

+ +

JOËL: On that terrible/wonderful pun, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël and Stephanie talk RailsConf!. Joël shares how he performed as a D&D character, Glittersense the gnome, to make his Turbo features talk entertaining and interactive. Stephanie's talk focused on addressing test pain by connecting it to code coupling, offering practical insights and solutions.

+ +

They agree on the importance of continuous improvement as speakers and developers and trying new approaches in talks and code design, and recommend Jared Norman's RailsConf talk on design patterns, too!

+ + + +

Transcript:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. 

+ +

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, I think I can speak for both of us and say what's new in our world is that you and I just came back from RailsConf in Detroit.

+ +

JOËL: Yeah, we were there for, I guess, it's a three-day conference. Both of us were giving talks.

+ +

STEPHANIE: Yeah. I don't think we've both spoken at a conference for at least a little over a year, so that was really fun kind of to catch up in person. And there was a whole crew of thoughtboters who were there. Yeah, I feel like we were hanging out, like, a lot [chuckles] all of last week, just seeing each other, talking about, you know, rehearsing our talks and spending time together on...there was, like, a hack day, and we were sitting at the table together. So, I feel like I'm totally caught up on everything that's new in your world, and that's it. That's the end of the show [laughs].

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: [laughs] That would not be very fair to our listeners.

+ +

[laughter]

+ +

JOËL: Yeah. So, how was the conference speaking experience for you?

+ +

STEPHANIE: Ooh, it was really great this year. I have not spoken at a RailsConf before, so this was actually, I think, a bigger stage than I had experienced before, and I had a great time. I met Ruby friends, new and old, and, yeah, I left feeling very gooeyed, and very energized, and just so grateful for the Rails community [laughs]. Yeah, I had a very lovely time, kind of being a little bit outside my normal life for a few days. And I think my favorite part about these things is just like, anywhere you go, you can kind of just have a shared interest with someone, and you can start a conversation with them.

+ +

JOËL: That's really interesting. Do you find yourself just reaching out to strangers at conferences like this? Or do you tend to just hang out with the people that you know?

+ +

STEPHANIE: Oh, I think a little bit of both. I like to get meals with people I know. But if I'm just hanging out in, like, the lobby or if I happen to get a seat for a talk and I'm sitting next to someone that I don't know, I find it quite easy to just be like, "Hi, like, I'm Stephanie. Are you excited for this talk?" Or, like, "What good talks have you seen recently?" There's an aspect of, like, the social butterfly that comes out of me when I'm at these things. Because I just don't get to have, like, easy access to, I don't know, people with, like, that shared interest or people who are willing to just have a conversation with you normally, I think.

+ +

JOËL: Yeah, would you describe yourself more as an introvert or an extrovert?

+ +

STEPHANIE: I am an extroverted introvert [laughter]. I feel like maybe that might be interpreted as a non-answer, but I think I lean more on the introvert side. But you know when you're with a group of people, and there's not, like, a very clear extrovert in that conversation, and then you're like, oh, I have to do the heavy [chuckles] lifting of the social lubrication [laughs] in this conversation, I can step into that role, reluctantly [laughs].

+ +

JOËL: Okay. I like the label that you used, the extrovert introvert, in that I enjoy social situations. I do well in social situations. But they also consume a lot of energy for me. I don't necessarily get sort of recharged by doing social events. So, people will be surprised when they find out that I tend to talk about myself as an introvert because, like, "Oh, but you're, like, you know, you're not awkward. You engage very well in different group situations."

+ +

STEPHANIE: You have a podcast [laughs].

+ +

JOËL: And the truth is I enjoy those things, right? I really like social interaction, but it does, after a while, wear me out.

+ +

STEPHANIE: Yeah, that makes sense. I did want to spend a little bit of time talking about the talk you gave at RailsConf this year: "Dungeons & Dragons & Rails."

+ +

JOËL: I got to have a lot of fun with the theme. The actual content was introducing people to Turbo by building an interactive Dungeons & Dragons character sheet using vanilla Rails and a little bit of Turbo. So, we're not even writing any JavaScript. We're just using the Turbo helpers, a little bit of Action Cable to mimic something a little bit like...people who are in the know might be familiar with the site D&D Beyond, which is kind of the official D&D online character sheet website. Of course, it wasn't anywhere near as fancy because it's a 30-minute talk and showcasing different features, but that's what we were aiming for.

+ +

STEPHANIE: Yeah, you know, you've talked a bit about giving talks on the show before, but I wanted to get into what made this one different because I think it could be fun for our listeners.

+ +

[laughter]

+ +

JOËL: The way I structured this talk so it has a theme. It's about Dungeons & Dragons, and we're building a character sheet. The way I wrote the talk was it's broken up into chapters. Each chapter is teaching a new feature in Turbo that I want to show off. In order to motivate learning each of these features...because I don't like to just say, "Oh, here's a thing that technology can do. Oh, here's a thing that technology can do." That's boring. You need a reason to learn that. So, I needed a reason to say,
+"We need to add this to a character sheet."

+ +

So, every sort of chapter of the talk opens up with a little narrative portion. We're following this character, Glittersense, the gnome, and he's on adventures. And at different points in the adventures, he's going to do different types of roles or need different stats and things. And so, when we reach the point in the adventure where we need that, we sort of freeze frame and then say, "Okay, let's add that as a feature to the character sheet."

+ +

And then, oh no, it turns out that this feature is a little bit more complicated. We're going to have to learn a new Turbo feature to do that. Who would have guessed? And then, we learn a new Turbo feature together. And then, we go back to the narrative portion. The adventures of Glittersense continue. And then, oh no, we're going to need to add another feature to the character sheet. And that's sort of how the talk is structured.

+ +

STEPHANIE: Yeah. And you did a really cool thing with the narrative portions, which was you basically performed as Glittersense, the gnome, voice and posture, and a lot of really great acting from you [laughs], in my opinion.

+ +

JOËL: That is something that came out pretty late in the talk preparation. So, I knew I wanted this kind of alternating story and code structure. Then, like, the weekend before RailsConf, I'm running through my slide deck, and I realized, you know what? What if instead of narrating Glittersense's adventures, what if I went first person for those sections? Glittersense tells his own story.

+ +

And then, from there, it wasn't a big jump to say, you know what? This is D&D. If I'm going first person and narrating, I really should do a voice. And this is a conversation I had with a couple of people at the speaker dinner. And, of course, everyone's like, "You should 100% do the voice." And I was really not feeling confident in my ability to pull it off. So, for the next two nights, because I was speaking on the third day, the next two nights at the conference, in the evenings, I'm in the hotel room in front of the mirror just practicing my gnome voice to try to get something that got the persona of Glitterense, the gnome, across to the audience.

+ +

STEPHANIE: How would you describe the persona?

+ +

JOËL: Very extra.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Very high energy.

+ +

STEPHANIE: Yes. The name Glittersense is very extra, after all.

+ +

JOËL: [laughs]. I punctuated a lot of the things that he says with just high-pitched laughter. He's also...so, the framing device for all of this is that you're in a tavern listening to him tell his adventures. I wanted a little bit of the sense that Glittersense is maybe embellishing a little bit. I think it may be too much to say he's full of himself, but he's definitely making himself to be the hero of the story, and maybe making himself to be slightly cooler than he really was.

+ +

STEPHANIE: Yeah. I definitely got, like, a little bit of eccentricity, too, from the persona. And you know when you just, I don't know, meet an older person who has, like, a lot of life experience, and they want to tell you about it [laughter], but you do kind of maybe have a little bit of suspicion around how much they're exaggerating [laughs].

+ +

But it was really fun. Everyone I talked to afterwards, like, loved it. And I got to share the little nugget that, like, oh yeah, and Joël only, like, started doing the voice, like, decided that he was going to do it two days ago. And they were just all really, like, blown away because it seemed so well practiced, and it was really fun.

+ +

JOËL: I got to do something really fun, also, with physical space because Glittersense narrates his portion, sort of the story portions, but then the code portions where we're talking about Turbo, I'm talking in my own voice. And so, when I'm talking about Turbo, I'm standing at the lectern. And when I'm Glittersense, I'm kind of off to the side on the stage and doing the voice.

+ +

And so, there's this almost, like, two worlds that are inhabited: one by Joël, the speaker, and one by Glittersense, the gnome. And it got to the point where I don't say or do anything. I only move from the lectern to the, like, portion of the stage where Glittersense lives. And the audience starts chuckling and, like, nothing has happened yet, like, no jokes have been told. No voice has happened. No slides have changed. But the anticipation, people know what's coming.

+ +

STEPHANIE: Yeah. And I think the best part, what I really found just really fun and, I don't know, every time it happened, I just really enjoyed it, when you transitioned out of Glittersense, the gnome, and back to Joël because you were so nonchalant about it. You kind of, like, straighten up rather than having your little kind of crouchy gnome posture, and then just walk across back to the podium. And then, in your normal voice, go back to just, you know, sharing very...not necessarily dry, but just, like, straight to the point. "And this is, like, how you, you know, create a frame in [laughs] Turbo," as if nothing happened [laughs] when even just, like, you know, 20 seconds ago, you were just enthusing about, like, slaying the bandit, chieftain [laughter] known as Glittersense.

+ +

JOËL: Uh-huh. I think, especially when I open, so I get introduced. I'm off stage. I walk onto the stage, and I'm immediately Glittersense. And I'm telling a story, and the intro goes on for, like, quite a while. It's a big story chunk. And then, at some point, I just walk over to the lectern, drop the voice, hit next slide, and it's my title slide. I'm just like, "Okay, now welcome to Dungeons & Dragons on Rails. We're going to build a character sheet together."

+ +

STEPHANIE: Yeah, that's exactly the moment I'm thinking of.

+ +

JOËL: The walking in as Glittersense and just immediately going to the voice caught everyone by surprise. And then, the, like, oh, he keeps going for this. Is the whole talk going to be like this? And then, the, like, just when you think, oh, he's really going for it, the, like, dropping it and going to the podium and title slide. It wasn't intended to be a funny moment, but I think the contrast and the fact that I just switched over was one of the biggest laughs I got.

+ +

STEPHANIE: Yeah, I mean, I think that attests to how good the delivery of it was because that contrast was very felt. So, props to you.

+ +

JOËL: I love the idea of, you know, the thought that you put into building a talk and, like, the narrative structure and the pedagogy of the stuff. And, I think, in this particular case, this is almost like a narrative approach called in media res, where you start kind of in the middle. You open your book, or your movie, or whatever in the middle of the story. And then, you kind of come back to the beginning at some point later. So, it starts with some kind of action scene that grabs your attention. So, in this case, my title slide is 10, 15 slides into the talk.

+ +

We get immediately started with Glittersense and his adventures. And then, once we're sort of all bought into this world, then we move to the title slide and talk about, okay, we're here to build a character sheet and all that stuff. And I think that it wouldn't have had the same impact if I'd, like, opened with that and then gone into Glittersense's adventures. And that's something that was not the case at the beginning. I really reworked the talk to make it in that order. And I think that the talk had a lot more impact for doing that.

+ +

STEPHANIE: Yeah, definitely. I guess I also just wanted to point out that this is very different from all your other talks. And I think it's really cool that, you know, you are a veteran speaker, but you still find ways to do something new and try something that you've never done before, and yeah, find ways, new ways to, like, speak and engage people and teach. I don't know, do you have just any thoughts about why or how you got into a position to be like, "Oh, you know, I'm going to do something super different this time around" [laughs]?

+ +

JOËL: So, every talk I give, I try to do something new, something different, to push myself as a speaker to get better. That might be in the writing of the talk; that might be in the delivery. More recently, I've been trying to do more with dynamic presence on stage. So, when I spoke at RubyConf San Diego, I was trying to not just stand at the lectern but to learn to be able to give my talk while also, you know, walking around the stage, looking at the audience, making pauses where it's necessary, not to just be so into the delivery of the talk by just standing at the podium and, like, going through my deck, which is a small thing but I think is an area I wanted to improve in.

+ +

This time, I was playing around with some more narrative framing and ended up, yeah, like, pushing it to an extreme. And it works with the theme because inhabiting a character and role-playing is the core part of D&D. Not everybody plays a D&D character by doing a voice. You are a little bit extra if you do that. But it's not uncommon for people to do a voice. And so, it kind of fit perfectly with my theme. I just needed to get the self-confidence to do it. So, thank you to everyone at the speaker dinner that was like, "No, you totally got this. You should do this," because I was feeling very unsure.

+ +

STEPHANIE: It really paid off, so...

+ +

JOËL: I'd like to circle back to your talk, though. So, you gave, basically, the first talk of the conference. You were the first session after the keynote. A theme that came up multiple times in your talk was this idea of coupling and how it affects different parts of our code and, particularly the way that we structure tests or the way that we feel test pain. How did you, when you were prepping this talk, discover that theme and decide to lift it up? Was that something that you knew ahead of time you wanted to talk about, or did it just sort of emerge as part of the talk preparation process?

+ +

STEPHANIE: That's a really great question, and I'm glad you picked up on that. So, my talk was called: "So, Writing Tests Feels Painful. What Now?" Originally, when I came up with this idea, it actually started with coupling. I realized that I wanted to give a talk about coupling because it's just something that I was struggling with or, like, had seen other people struggle with and really wanting kind of a discrete resource, wanting to provide that.

+ +

But as I was just thinking about it, I was like, oh, like, there are so many different ways that this could go. On one hand, it was a very like important topic to me, but also maybe too big of a topic. And so, I actually, like, kind of put that on the back burner. And it wasn't until later when I connected it to another...it wasn't necessarily different at all, but just, like, an extension of this idea is, oh, like, people are struggling with coupling in tests or, like, it manifests in tests. And so, I thought maybe that could be the angle that I took on this topic that kind of gave me a little bit more focus.

+ +

And I didn't even end up saying like, "Yeah, this talk was, like, born out of just, you know, wrestling with coupling or anything like that." So, it's cool, to me, that you picked up on it as a theme because it was...I had, you know, ended up not being super explicit about it, but it was certainly, like, a thing that was driving the content from my perspective.

+ +

JOËL: Interesting. So, it started as a coupling talk and then got sort of focused through the lens of testing.

+ +

STEPHANIE: Yeah. And I think there was a part of me that was like, you know, I don't know if I could just teach the concept of coupling, like, by itself without the framing of testing for people who this is, like, a new concept for them. I realized that maybe it would be more effective to be like, "Hey, like, have you experienced test pain? You know, have you had to mock out a billion objects or changed, you know, made one change and then had to fix, like, a million tests subsequently? Then this talk is for you." And then weave in the idea of coupling in it to kind of start to help people feel familiar with it or just, like, identify it without as much, like, jargon as kind of I've seen when I've tried to figure out, like, how to manage it.

+ +

JOËL: It's interesting because I think it gives you a, like, concrete, valuable thing to optimize for as opposed to, like, hey, let's lower coupling because then you're writing, you know, quote, unquote, "better code." And you get to feel better about yourself as a programmer because you're doing things the, quote, unquote, "right way." That's very kind of hand-wavy, and I think sometimes leads people down a bad path where they're optimizing things that they shouldn't be.

+ +

But the tests give you this very concrete way to say, "Hey, we're not just trying to reach the, like, low score record for the app in terms of coupling. We're trying to reduce test pain. Tests are painful. And that pain is telling us something. It's telling us that we've crossed some sort of threshold for coupling. Let's find ways to reduce it, not so that we can feel good about ourselves, but so that our tests are actually manageable."

+ +

STEPHANIE: Yeah, I am really glad you picked up on that, too, because I feel the exact same way when someone just tells me to decouple something or, like, makes a note that, like, oh, this feels really coupled. I don't know what that means necessarily. And it's not very convincing to just be like, "Oh, you should write loosely coupled code [laughs]," at least for me. What you said just now, it's like, it's not to feel good about ourselves, you know, to write code that way, but, actually, to just feel good about our code, period [laughs]. And, yeah, finding that validation through just, like, actually working with code that is easier to change that is the goal, not necessarily to, yeah, kind of pursue some totally subjective, like, metric.

+ +

JOËL: So, one of the kinds of coupling that you called out, I think, was where you hardcode a class name of some other class in your object. And that feels, like, really sort of innocuous. Like, of course, my objects can talk to other objects. And maybe I want to, like, refer to a class somewhere. Why is that such a like tricky piece of coupling to work with?

+ +

STEPHANIE: It's not necessarily intentional sometimes. Like, you just do it because you're like, well, I need access to this class somewhere, and I happen to already be in this file. So, why not just hard-code it here? I do think it's a little tricky because the file that you're writing might be, like, very far down in, like, your code flow or, like, your code path, like, very far from, like, a controller or any kind of entry point into your system, at least based on what I've seen in a lot of modern Rails apps. And so, I think that coupling gets really, really obscured.

+ +

I have found that, like, if I have to kind of write a more, like, a higher level test, like, maybe a request spec or something, there are times when I'm, like, having to deal with a lot of classes just to set stuff up in a test like that that I didn't think I would have to [chuckles] when I first went about trying to just be like, oh, like, let's just figure out how to get a 200 response [laughs] from this request. So, you're really burying perhaps the things that are needed to set up, like, that full path of execution. And sometimes, it only comes out when you're writing a test for it.

+ +

JOËL: And you mentioned briefly, in passing, the idea that oftentimes this sort of coupling manifests as a lot of extra test setup because your object that you're trying to test now also needs all these other things that are related in order to be tested. But sometimes even when you hard code a class, though, you can't even just say, "Oh, I want this particular user or something returned." So, you have to then do something like allow this class to receive class method and return, and now you're stubbing.

+ +

And I don't know how you feel about stubs in RSpec. I always treat them a little bit like a code smell in the like classic sense of it's not necessarily bad, but maybe pause, take a look, and ask yourself, "Why is that there, and should I do things differently?"

+ +

STEPHANIE: Yeah. I ended up having, like, a lot of examples of stubbing in my example because the code had just been set up where that was the only way that you could access those collaborators, essentially, to, like, make an assertion on them, or have them do something different because you actually needed to go into a different path, right? And I was like, yeah, this should feel weird. You should feel a little bad [laughs] or at least, you know, kind of just pay attention to that feeling, even if you can't really do anything about it in that particular instance.

+ +

But on the flip side, you know, it's like, yes, it feels a bit strange, you know, but it's not all bad, right? Like, you're kind of learning like, oh, hey, like, I am coupled to this hard-coded class because I am needing to stub, like, a class method that returns it, or that constructs it. And at least you've exposed that, you know, for yourself.

+ +

One thing that I was running into a lot in my example, too, was that those things, like, weren't obvious when you were just reading maybe, like, the public methods and trying to figure out what was happening in them because they were wrapped in private methods. I was a little bit conflicted about this because there were times when it was already just a single method call, but then it was just kind of wrapped in a private method that actually hid [laughs] the things, like all the dependencies that were passed as arguments.

+ +

And I found that to be, sure, it looks kind of cleaner. But then all you need to do is scroll down [laughs], and then you're like, oh, actually, there's all these other things involved, but it was kind of hidden away for me. And I found that, actually, like, at least when I actually needed to change things, less helpful than I imagine what the, you know, code author intended. Do you have any thoughts about hiding details like that?

+ +

JOËL: I'm kind of a big fan.

+ +

STEPHANIE: Hmmm.

+ +

JOËL: The general idea, I think, is called the single level of abstraction principle. Whatever sort of public method that you're calling is often implemented in terms of...let's say it does a few different things. It's implemented in terms of, like, these sort of high-level concepts. So, whoever is reading the public method doesn't need to like care about the details of how each step is implemented.

+ +

So, maybe you're fetching something from an API, and then you're making a database call, and then you're doing some transformation and creating some new objects from it. Having all of the, like, HTTP calls and the ActiveRecord stuff and the, like, transformation all in the public method, yes, there's a lot of complexity happening there, and it makes that obvious. But it also makes it really hard to get a sense of what is happening.

+ +

So, I like to say, "Hey, there are four steps. Let's wrap them all each in a private method then you can call all of those in the public method." The public method now sort of reads like a very simple sort of script. First, fetch data from the HTTP API, then fetch some data from the database, then apply this transformation, then create this object. And if I'm mostly caring about what this object does and not the how let's say I'm building some other objects that interact with this, that is the information I want to know. Where I care about the actual implementation of, oh, well, exactly how is the ActiveRecord stuff done when I'm doing internal changes to the object, that's when I care about those private methods.

+ +

I think where it gets tricky, and I think that's the point that you were bringing up, is that if you write code in that way, it has to change the heuristics of how you read code to detect complexity. Because, oftentimes, I think a very classic heuristic for code complexity is just line length. If you have a 50-line method, probably there's a lot of complexity there. Maybe there's a lot of coupling. If it's a four-line method that is written at a high level of abstraction that just calls out to private methods, you scan over. You're like, oh, nice and clean. Nothing to see here. Move on. And so, that heuristic doesn't really hold up in a codebase where you're applying this single level of abstraction. Do you think that lines up with your experience?

+ +

STEPHANIE: Hmm. As I was listening to you, I was like, yeah, like, that makes total sense to me. But then I also clearly disagreed a little bit [laughs] in my initial...kind of what I was saying initially. And I think it's because that single layer of abstraction was not very well defined.

+ +

JOËL: Hmm. That's fair.

+ +

STEPHANIE: Yeah. Where, in fact, it was actually misleading. Like, it wanted to be at that level of abstraction, but it really wasn't. Like, it was operating on things at, like, a lower level and wasn't designed with that kind of readability in mind. So, it was more, like, it was just hiding stuff a little bit, at least for me.

+ +

And, I think, it certainly would have taken, like, more work to figure out what that code, like, really was meant to convey. It might have taken some refactoring to coalesce at that single level. And that was essentially kind of what I was showing in my talk as, like, how to get to saying, like, "Hey, we actually are operating in the lower level, but I don't think we need to."

+ +

There was some amount of, like, looking at all of the how to figure out, like, oh, maybe these things we don't even need to expose in this class. And we kind of got to a place where those details weren't, like, needed in that class at all. So, it's one of those things where it's harder than it sounds [laughs].

+ +

JOËL: It's definitely an art.

+ +

STEPHANIE: Yeah.

+ +

JOËL: And I think what you're saying about some of the coupling being, like, scattered throughout the class, it's something that I see a lot with situations where you're coupled, not so much to, like, a single class, but to something side effectful. So, you're building some kind of integration with a third-party API, and you're going to have to make a lot of HTTP calls. And each of those might be individually simple, and they're all sort of maybe in different private methods or whatever, or they're interspersed among a larger chunk of logic. And that makes your tests really complicated. But there's no, like, one place you can point at and be like, ooh, that's the one place where there's a lot of complexity.

+ +

What's happening here, though, is that your business object that's doing stuff is coupled to the network, and that coupling is going to force you to do some stubbing. It's going to force you to deal with a bunch of side effects that are non-deterministic in your code. And you used the word coalesce earlier that I really liked because I think that's often a situation where you do have to stand back and say, "Look, there's a lot of HTTP going on here. What if I coalesced it all into an object? Now I have two objects: one that's responsible for business logic, and one that's responsible for just the HTTP calls."

+ +

And, all of a sudden, the tests just totally simplify. And we've removed some coupling, but that's not something that you would have seen just from reading the code. Because, as you were saying, it's sort of scattered in little bits and pieces throughout your file that don't necessarily catch your eye.

+ +

STEPHANIE: Yeah. Which brings me to a blog post that I had found a lot of inspiration from in the talk that I'll link. It's called "That One Thing: Reduce Coupling for More Scalable and Sustainable Software." But it's actually about tests [laughs], even though it doesn't make an appearance in the title of the blog post at all. But this is where I kind of got the idea of necessary versus unnecessary coupling in test. Because I had never thought about how, yeah, like, when you write a test, you are very correctly coupling yourself to at least the method and class under test [laughs], if not also the arguments, right? Or anything else needed to construct what you're testing.

+ +

And literally having that listed out for me in this blog post I think it's a...they use some examples in Java. And so, there's, like, a little bit more [laughs] setup involved. But I think they're like, yeah, these are six things that, like, it's mostly fine if you're coupled to these because that's kind of what needs to happen in a test. But, like, even having something to compare a test I wrote to just, like, okay, these are the things I know I need. And then, you can start to see when you've diverged from that list, when you are finding yourself coupled to some internals of your class.

+ +

I really...that was actually, like, really helpful for me because, as we talked about earlier, like, it can be kind of communicated so abstractly. But here is, like, a very clear heuristic for when you should at least, like, start to pay attention or be like, oh, this is something that was needed to get the test to run but is now starting to feel a little unnecessary because it's not on this list.

+ +

JOËL: That list reminds me, or the idea of a list of things to check out for when thinking about coupling, reminds me of the concept of connascence, which is a fancy word for almost a, like, categorization of different types of coupling because coupling comes in different flavors, some of which are tighter forms of coupling than others. And so, having that vocabulary has been really helpful for me when I'm looking at PRs and code review, or even when I'm refactoring my own code. Kind of like that list that you mentioned that you have, now I have some heuristics to look at that and say, "Oh, can I go from a connascence of position to a connascence of naming, and does that help me?"

+ +

STEPHANIE: Yeah, I like that you mentioned the positional connascence because I also came across a really great metaphor for kind of things that need to change together, like, when that makes sense. And it was basically the idea of a dishwasher and a laundry machine [laughs]. I wish I could recall, like, what book this was from.

+ +

But it was basically like, oh yeah, like, in theory, you're washing two things. So, maybe they are similar, but then you're like, no, actually, you want these to be a little bit separate because, you know, you don't want to wash your dishes and your clothes in the same machine. I don't know, maybe that exists [laughs], but I don't think it would do a very good job for either goal.

+ +

And I think that was really helpful, for me, in imagining, like, the difference between kind of coupling and cohesion, like things that...even just imagining, like, kind of where I'm doing those things in the house, right? It's like, okay, that lives in a separate room. And, like, the kitchen is for the dishes, and that could be like, you know, a module if you will. And, like, laundry happens in the laundry room, and how to kind of just separate those things, even though they also do share some qualities, too. Like, they're both appliances, right? And so, that's the way that they are similar, but they're not the same.

+ +

JOËL: You just mentioned the sort of keyword cohesion. And for our listeners who are not familiar with that term, it refers to an object sort of having one thing that it does well. Like, everything in that class sort of works towards the same goal, kind of similar to the idea of the single responsibility principle.

+ +

So, in my earlier example, where we're sort of interspersing some business logic, a lot of HTTP requests, and pulling out an object that's focused on HTTP, like everything is based around that, now that object has higher cohesion because it's all doing one thing. So, if you read classic object-oriented literature, the recommendations that you'll typically see are that objects should have high cohesion and low coupling.

+ +

STEPHANIE: Yeah. Think of a dishwasher and a washing machine next time [laughs] you come across something like that. Because I feel like those are really great, like, real-life examples of that separation.

+ +

JOËL: Did you go to Jared Norman's talk on the third day: "Undervalued: The Most Useful Design Pattern"?

+ +

STEPHANIE: No, I didn't. Can you tell me about it?

+ +

JOËL: It felt like he was addressing a lot of the same themes as you were but from more of a code perspective than a test perspective. Talking a lot about, again, forms of coupling, dependencies, and then, specifically, one of the tools that he focused on to reduce the coupling that we see is value objects and factory methods to construct those.

+ +

So, for any of our listeners who, when the talks come out, watch Stephanie's talk and are like, "Wow, I would love to learn more about this," a great follow-up, Jared Norman's talk: "Undervalued: The Most Useful Design Pattern."

+ +

STEPHANIE: Yeah, that's neat because I can see that being a solution to the hard code did class names that we were talking about earlier. And I like how that is kind of, like, a progressive lesson in coupling a little bit. I'm really glad you shared that talk with me because now I'm excited to watch it when it comes out. And in general, I just love learning new vocabulary or finding new ways to speak about this topic with clarity. So, if any of our listeners have just additional mental models for coupling [laughs] different metaphors, different household appliances [laughs], or something like that, I would love to know.

+ +

JOËL: You would like that, given that our first episode together was about "The Value Of Specialized Vocabulary."

+ +

STEPHANIE: Yeah, it's clearly undervalued.

+ +

JOËL: Haha, I see what you did there.

+ +

STEPHANIE: Thank you. Thank you very much [laughs].

+ +

JOËL: On that terrible/wonderful pun, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3gb7hiaN + + ]]> + + Joël Quenneville + Stephanie Minn + + + 426: Bringing "Our Selves" to Work + https://bikeshed.thoughtbot.com/426 + b775ef67-48ff-4734-a827-2120f71e712f + Tue, 14 May 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël shares his preparations for his RailsConf talk, which is D&D-themed and centered around a gnome character named Glittersense. Stephanie expresses her delight in creating pod-related puns within thoughtbot's internal team structure, like "cross-podination" for inter-pod meetings and the adorable observation that her pod resembles "three peas in a pod" when using the git co-authored-by feature. + +Together, Stephanie and Joël discuss bringing one's authentic self to work, balancing personal disclosure with professional boundaries, and fostering psychological safety. They highlight the value of shared interests and personal anecdotes in enhancing team cohesion, especially remotely, and stress the importance of an inclusive culture that respects individual preferences and boundaries. + 33:04 + no + + + Joël shares his preparations for his RailsConf talk, which is D&D-themed and centered around a gnome character named Glittersense. Stephanie expresses her delight in creating pod-related puns within thoughtbot's internal team structure, like "cross-podination" for inter-pod meetings and the adorable observation that her pod resembles "three peas in a pod" when using the git co-authored-by feature. +Together, Stephanie and Joël discuss bringing one's authentic self to work, balancing personal disclosure with professional boundaries, and fostering psychological safety. They highlight the value of shared interests and personal anecdotes in enhancing team cohesion, especially remotely, and stress the importance of an inclusive culture that respects individual preferences and boundaries. +Transcript: +We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. +Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. +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, at the time of this recording, we're recording this the week before RailsConf. I've been working on some of the visuals for my RailsConf talk and leaning on AI to generate some of these. So, my talk is D&D-themed, and it's very narrative-based. We follow the adventures of this gnome named Glittersense throughout the talk as we learn about how to use Turbo to build a D&D character sheet. And so, I wanted the AI to generate images for me. +And the problem I've had with a lot of AI-generated images is that you're like, okay, I need a gnome, you know, in a fight doing this, doing that. But then, like, every time, you get, like, totally different images. You're like, "Oh, I need an image where it's this," but then, like, the character is different in all the scenes, and there's no consistency. So, I've been leaning a little bit more into the memory aspect of ChatGPT, where you can sort of tell it, "Look, these are the things. Now, whenever I refer to Glittersense, whenever you draw an image, do it with these characteristics that we've established what the character looks like." +Sometimes I'll have, like, a text conversation kind of, like, setting up the physical characteristics. And then, it's like, okay, now every time you draw him, draw him like this, or now every time you draw him, draw him with this particular piece of equipment that we've created. And so, leaning into that memory has allowed me to create a series of images that feel a little bit more consistent in a way that's been really interesting. +STEPHANIE: Cool. Yeah, that makes sense because you are telling a story, right? And you need it to have a through line and the imagery be matching as you progress in your presentation. I actually don't know a lot about how that memory works. Does it persist across sessions? Do you have to do it all in one [laughs] go, or how does that work? +JOËL: So, there's, like, a persistent chat. So, you can start sort of multiple conversations, but each conversation is its own thread with its own memory. And it will sort of keep track of certain things. And sometimes I'll even say, "Hey..." instead of, like, prompting it for something to get a response, you could prompt it to add things to its memory. So say like, "From now on, when I ask you these types of questions, I want you to respond in this way," or, "From now on, when I ask you to generate an image, I want it done in this format." So, for example, RailsConf requires all of their slides to be 16 by 9. If I want, like, a kind of cover image or, like, something full-screen, I need an image that is 16 by 9. So, one of the things I prompt the AI with is just, "From now on, whenever you generate an image, give me an image in 16:9 aspect ratio." +STEPHANIE: Cool. I also was intrigued by your gnome's name, Glittersense. And I was wondering what the story behind that character is. +JOËL: The story behind the name is that I was playing D&D with a friend who was this very kind of eclectic Dragonborn character. And I did some sort of valiant deed and got the name Glittersense bestowed upon me by this Dragonborn for having helped him out in some, like, cool way. So, that's a fun name. And so, when I was searching for a name for my character in this talk, I was like, you know what? Let's bring back Glittersense. I like that. I think it captures a little bit of, like, the wonder and the whimsy of a gnome. +STEPHANIE: That's really cute. I like that a lot. +JOËL: So, Stephanie, what's been new in your world? +STEPHANIE: So, lately, I've been having a lot of fun with coming up with names of things. You know the saying how naming is one of the hardest things in software? Well, okay, I'm not actually going to talk about anything that I named very particularly well in my code, but I've been just coming up with a lot of puns. It's just, I don't know, my brain is kind of in that space. And one thing that...I can't recall if I have talked about this on the show before, but our team at thoughtbot is experimenting with kind of smaller sub-teams within it called pods. We have now kind of been split into pods with other people who are working on maybe similar client projects. I have been having some really good naming ideas around [laughs] pod-related puns. +So, one thing that we did as part of this experiment was setting up meetings for pods to meet each other, and spend time together, and kind of share what each other was up to. And I was the first to coin the term cross-podination, kind of like cross-pollination. And I think I just, like, said it offhand one day, and then it caught on. And I was very pleasantly surprised to see that people just leaned into it and started naming those meetings cross-podination meetings. +And then, another one that came about recently was my pod there's three of us in it, and we were pairing, or I guess it's not really called a pairing if there's three. We were mobbing or ensembling, whatever you want to call it. And sometimes we like to use the git co-authored-by feature where you can attribute, you know, commits to people that you worked on them with. And in GitHub when you, you know, add people's emails to the commit, you know, you see your little GitHub profile picture in a little circle. And when you have multiple people shared on a commit, it is just, like, squished together. And since we're a trio, I was like, "Oh, it's like we're, like, three peas in a pod." +JOËL: [chuckles] +STEPHANIE: And I realized that it was an excellent missed opportunity for our pod name. We're something else. But I am hereby reserving that name for the next pod that I am in. You heard it here first [laughs]. It looked exactly like just three snug little peas. And I, yeah, it was very cute. I was very delighted. And yeah, that's what's new for me. +JOËL: I'll also point out the fact that you are currently talking on a podcast. +STEPHANIE: Whoa, whoa. So, you and I are a pod [laughter]. We're a podcasting pod [laughs]. Wow, I didn't even think about that. My world is just pods right now [laughs], folks. +JOËL: How do you feel about puns as an art form? +STEPHANIE: [laughs] Wow, art form is a strong phrase to use. I don't hate them. I think it depends. Sometimes I will cringe, and other times I'm like, that's great. That's excellent. Yeah, I think it depends. But I guess, clearly, I'm in my pun era, so I've just accepted it. +JOËL: Are you the kind of person who is, like, ashamed but secretly proud when you make a really good pun? +STEPHANIE: Yeah, that's a very good way to describe it. I'm sure there are other people out there [laughs]. +JOËL: What's interesting with puns, right? Like, some people love them, some people hate them. Some people really lean into them, like, that becomes almost, like, part of their personality. We had a former teammate who his...we made a custom Slack emoji with his face, and it was the pun emoji because he always had a good pun ready for any situation. And so, that's sort of a way that I feel like sometimes you get to bring an aspect of your personality or at least a persona to work. What parts of yourself do you like to bring to work? What parts do you like to maybe leave out? +STEPHANIE: Yeah, I am really excited about this topic because I feel like it's a little bit evergreen, maybe was kind of a trendy thing to talk about in terms of team culture in the past couple of years, but this idea of bringing an authentic or whole self to work as, like, an ideal. And I don't know that I totally agree with that [laughs] because, like you said, sometimes you have a different kind of persona, or you have a kind of way that you want to present yourself at work. And that doesn't necessarily mean it's a bad thing. I personally like some kind of separation in terms of my work self and my rest of life self [laughs]. Yeah, I just think that should be fine. +JOËL: So, you might secretly be the pun master, but you don't want your colleagues to know. +STEPHANIE: [laughs] That's true. Or I save my puns only for work [laughter]. If I ever have, like, a shower thought where I think of a really good pun, I will, like, send a Slack message to myself to find [laughs] the perfect opportunity to use this pun in a meeting [laughs]. I don't actually do that, but that would be very funny. +JOËL: I feel like there's probably a sense in which nobody is a hundred percent their authentic self or their full self in a work situation, you know, it varies by person. But I'm sure everybody, to a certain extent, has a professional persona that they inhabit during work hours. +STEPHANIE: Yeah, and I like that the way we're talking about it, too, is a professional persona doesn't necessarily mean that you're just a little...matching kind of a business speak bot [laughs], where it's kind of devoid of personality, but just using all the right language in their emails [laughs] and the correct business jargon or whatever. To me, what is important is that people are able to choose how they show up or present themselves at work. That's, like, an active choice that they're making, not out of obligation or fear of consequences. You know, like, it's fine to be a little more private at work if that's just how you want to operate. And it's also fine to be more open about sharing things going on in your personal life. +Because I've seen ways in which both have been more enforced or, like, there's pressure to perform one way or another. And that could mean, like, when people kind of encourage others to try to be more of themselves or, like, share more things about personal life. That's not always necessarily a good thing if it's not something that people are comfortable with. And I suspect that we have kind of pulled back a little bit from that, but there was certainly a time when that was a bit of an expectation. And I'm not sure that that was quite [chuckles] what we wanted to aim for in terms of just the modern workplace. +JOËL: It is interesting because I think there can be some advantages to maybe building connection with people by sharing a little bit more about your life. But, again, if there's pressure to do it, that becomes really unwholesome. +STEPHANIE: Yeah. Unwholesome is a good word to use. Like, I want that wholesome content [laughs] at work. And I actually have a couple of thoughts about how I prefer to share, like, just personal things with my team members. And I'm curious kind of where you fall on this as well. But a couple of things that our team does that I really like is we have a quarterly newsletter that one of our team leads puts together. She has an open call for submissions, and people just share any, like travel plans, any professional wins, any kind of personal life things that they want to share. +People love talking about their home improvement adventures [laughs] on our team, which is really fun. And yeah, like, just share photos and a little blurb about what they've been up to. And this happens every quarter. And it's always such a delight to remember a little bit like, oh yeah, my co-workers have lives outside of work. But I really like that it's opt-in and also not that frequent, you know? It's kind of like, this is the time to share any like, special things that have happened in the past three months. And yeah, I think every time a new dispatch of it comes out, everyone kind of gets the warm and fuzzy feelings of appreciating their co-workers and what they've been up to. +JOËL: Do you think that that kind of sharing sort of maybe helps personalize a little bit of our colleagues, especially because we're all remote and we're interacting with each other through a screen? +STEPHANIE: Yes. Yeah. That's another good distinction. I think it is, like, a little more important that there are touch points like these when we are working remote because, yeah, the water cooler conversation just doesn't really happen nearly as much as it does when you're in an office. And I feel like that's the kind of thing that I would talk about at the water cooler [laughs]. It's like, "Oh yeah, I went to Disney World, or traveled for this conference, or I built new garden beds for my yard," just stuff like that. I don't know, I don't find that...like, when you're just communicating over Slack and email, there's not a good place for that kind of stuff. And that's why I really like the newsletter. +JOËL: One thing that's interesting about the difference between in-person and remote is that, in person, a way that you can express personality in the office is you can do some things with your workspace. You might have some items on your desk that are of personal interest. And, you know, you might still do that when you're working remote, but those don't get captured by your webcam unless it's in your background. +Your background you can get real creative with. But you can also, like, really curate that to, like, show practically nothing. Whereas if you were putting things on your desk in the office, there's kind of no way for your colleagues not to see that. So, you had to be...like, it had to be things that you were willing for everyone to see. But at the same time, sometimes it's nice to be able to say, hey, I'm going to put a touch of, like, things that are meaningful to me in my work life. +STEPHANIE: Yeah, I really like that. I mean, Joël, your background is always these framed maps on the wall, hanging on the wall, and that is very you, I think. Did you kind of think about how they'll just be your background whenever you're in a meeting, or they just happened to be there? +JOËL: So, these I had set up pre-pandemic. I like the décor. And then, when I started working from home in 2020, I was trying to figure out, like, where do I want to be to take meetings? And I was like, you know what? The math wall is pretty cool. I think that's going to be my background. I guess now it's almost become, like, a bit of a trademark. +STEPHANIE: Yeah, I feel that. My trademark...I have a few because I like to move around when I take meetings. So, when I'm at my desk, it's the plants in my office. When I'm in my kitchen, it's either my jars [laughs]. So, I have, like, open shelving and just all of these jars of, you know, some of it is ingredients like nuts, and grains, and stuff like that, and some of it is just empty jars that I use for drinking water. So, I have my jar collection. And then, occasionally, if I'm sitting on the other side of the table [chuckles], all of my pots and pans are hanging in the background from above my stove. So, yeah, I'm the jars, pots, and plants person [laughs] at the company. +JOËL: You know, we were talking earlier about the idea that it's harder to see your sort of workspace in a remote world. And I just remembered that we do a semi-regular...there's, like, a thread at thoughtbot where people just share pictures of their workspace, and it's opt-in. You don't have to put anything in there. But you get a little bit of, like, oh, the other side of the camera. That's pretty cool. +STEPHANIE: Yeah, I love seeing those threads. And I think a lot of people in our industry are also gear nerds, so [laughter] they love to see people's, like, fancy monitor and keyboard setups, maybe some cool lighting, oh, like, wire organization [laughs]. +JOËL: Cable management. +STEPHANIE: Yep. Yep. Those are fun. And I actually think another one that we've lost since going remote is laptop stickers because that was such a great way for people to show some personality and things that they love, like programming stuff, maybe, like, you know, language stickers or organizations like thoughtbot stickers, too, and also, more personal stuff if they want. At a previous company, we were also remote, and someone came up with a really fun game where people anonymously submitted pictures of their laptop stickers. And we got together and tried to guess whose laptop belonged to who just based on the stickers. +JOËL: Oh, that's fun. +STEPHANIE: Yeah, that was really fun. I keep forgetting that I wanted to organize something like that for thoughtbot. But now I'm just thinking about it, and I feel the need to decorate my laptop with some stickers after this [laughs]. +JOËL: One thing I do want to highlight, though, is the fact that several years back, when people were talking a lot about the importance of bringing your sort of authentic or whole self to work, one of the really valuable parts of that conversation was giving people the ability to do that, not forcing people to sort of hide parts of themselves, especially if they don't fit into a dominant culture or demographic, in order to be able to even function at work, right? That's a sort of key aspect of, I guess, basic inclusivity. And so, I think that's still a hundred percent true today. We want to build cultures that are inclusive, both in our in-person professional situations and for remote teams. +STEPHANIE: Yeah, 100%. I think, for me, what I think is a good measure of that is, you know, how comfortable are people disagreeing at the company kind of in public or sharing an alternative perspective? Like, that should be okay and celebrated, even, and considered, you know, with equal weight as kind of what you're saying, the dominant identity or even just opinion. Like, especially in tech, I think people have very strongly held opinions, and when they're disagreed with...I've become a little skeptical of the idea of, like, this is how we do things here or, like, we don't do that. +And I think that rather than sticking to a, like, stance like that, there's always room to incorporate, like, new approaches, new perspectives, new ways of thinking to a given problem. And that can only happen when people are comfortable with going there, you know, and kind of saying, like, "This is important to me," or, like, "This is how I feel about it." And that, in and of itself, is just equally valid [laughs] as whatever is taking the airtime currently. +JOËL: That's really interesting because I feel like now you've leaned into almost the idea of psychological safety for a team. And if you're having to sort of repress or hide elements of the way you think, or maybe even sort of core elements of your identity to fit in with a team, that's not psychologically safe, and you can't have those deeper conversations. +STEPHANIE: Yeah, 100%. I think it's two sides of the same coin, you know, it's like two ways of saying the same thing, that people should be able to conduct themselves in the way they choose to [laughs]. And I can't imagine anyone really disagreeing with a statement like that. +JOËL: So, I know you choose to not always share everything about your life or sort of...I don't want to say bring your authentic self but, like, bring everything about yourself to the workplace. Do you have a sort of a heuristic for what you decide to share or not share? +STEPHANIE: Yeah. I don't know if it's necessarily a heuristic so much as it's just what I do [laughs]. But I tend to do better with, like, smaller groups, and, actually, that's why I think pods has been working really well for me personally because I can share personal information just in a more intimate setting, which is helpful for me. And yeah, I tend to, like, find once, like, either Slack channels or Spaces, meetings are starting to get into the, like, 10, 11, 12 people territory is when I hold it back a little bit more, not because of any sort of, like, reason that I don't want to share. It's just, like, that's just not the venue for me. +But I do love when other people are, like, open, even in, like, larger spaces like that. I appreciate when other people do it just to, you know, signal that it's okay [laughs]. And I enjoy throwing a reaction or responding in a thread about, you know, something that someone shared in a bigger channel. And I think that diversity is actually really helpful because it conveys that, like, there's different ways of existing online in your work environment and that they're all acceptable. What about you? How do you kind of choose where to share things about your personal life? +JOËL: I think, kind of like you, I don't really have a heuristic. I just sort of go with gut feeling. I think I, sort of by nature, have always been maybe a little bit of having, like, separate professional and personal lives and keeping those a little bit more distinct. And, you know, there's some things that kind of cross over, like, oh, you know, I tried out this fun, new restaurant, or I did a cool activity over the weekend, or something like that. +I think I've come to see that there can be a lot of value in sharing parts of yourself with other colleagues. And so, from time to time, I'll, like, maybe bring in something a little bit deeper. And, like you said, sometimes that's more easily done in a smaller context. And then yeah, for some things, it's like, okay, I'm going to share photos from a vacation in that, you know, quarterly newsletter. That's kind of fun. But also knowing that there's no pressure that's nice. +STEPHANIE: Yeah. I think you're really good about finding the right avenues for that. I like, love when you show photos in the travel channel, even though I have that channel muted [laughs]. You'll, like, send me the link to the post in that channel. And yeah, I love that because it's a way for you to kind of, like, find the right place for it, and then also share it with any particular people if you choose to. +JOËL: I think, also, personal connections can be a way to build deeper relationships, especially in smaller groups. And you can form deeper connections with colleagues over a particular project, or a particular technology, or a tech topic, or, you know, just a passion about mechanical keyboards, or something like that. But if you're people who chat kind of more on the regular for different things, maybe separate from a client project you're on or something like that, and you do find yourself exchanging a little bit more about, oh, you know, what you're doing in your life, or what are the things that are going on for you, that often does tend to build, I think, a deeper connection between colleagues, which can be really nice. +STEPHANIE: Yeah. And I like that those relationships can also change. Like, there's different seasons in which you're more connected to some people and then less connected. Sometimes a colleague that you have shared interests with becomes someone that you kind of are in touch with more regularly, and then maybe you switch projects, and you aren't so much kind of as up to date. But, I don't know, I always think that there's, like, the right time for that kind of stuff, and it emerges. +JOËL: I'm going to throw a bit of a buzzword at you, and I'd love to get your reaction. The idea of belonging, the feeling of belonging on a team, is that a good thing, something that we should seek out? And if so, how much of that is responsibility of, like, management or, like, a property of the team or the group to make you sort of feel that belonging? And how much of that is on you having to maybe disclose things about yourself or share a little bit of your personal life to, like, create that sense of belonging? +STEPHANIE: Whoa. Yeah, that is a good way to frame it. I think there's a balance. There've been some, like, periods of my work life where I'm like, oh, I need more of a detachment from work and other times where I'm like, oh, I feel really disconnected, like, I want to feel like more of a part of this team. But I do think it's a management responsibility. And one thing that I know people to be cautious of is, you know, becoming too close at work. I don't know if your work being treated like a family, like, that kind of language can be a little bit borderline. +JOËL: Almost manipulative. +STEPHANIE: Right. Yeah, exactly. I do think there's something to be said about community at work and feeling like that kind of belonging, right? But also, that you can choose how much, like, you want to engage with that community and that being okay. I don't think it necessarily needs to be only through what you share about yourself. Like, you can have that sense of connection just by being a good colleague [chuckles], right? Like, even if the things you talk about are just within the realm of the project you're working on, like, there's still a sense of commitment and, yeah, in that relationship. And I think that is what matters when it comes to belonging. +In the past, ways that I've seen that work well in regards to kind of how you share information is just, like, I don't know, share how you're doing. Like, you don't have to provide too many details. But it could be like, "Oh, I'm kind of distracted in my personal life right now, and that's why I wasn't able to get this done." People should be understanding of that, even if you don't kind of let them in on the more personal aspects of it. +JOËL: Right. And you don't have to give any details, right? +STEPHANIE: Yeah. +JOËL: You should be in a place where people are comfortable with not knowing and not be like, "Ooh, what's going on with Stephanie's life? " +STEPHANIE: [laughs] Yeah. But I do also think, like, the knowing that, like, something is going on is, like, also important context, right? Because you don't necessarily want that to impact the commitments you do have at work. +JOËL: Right. And people tend to be a little bit more understanding if you're having to maybe shift some meetings around, or if you're struggling to focus on a particular day, or something like that. +STEPHANIE: Yeah. 100%. +JOËL: Yeah, we should normalize it of just like, "Hey, I'm having a hard day. I don't want to give details, but you know." +STEPHANIE: Yeah. Yeah. I think a way that that is always kind of weird is how people communicate they're taking a sick day [laughs]. I actually had someone tell me that they really appreciated a time when I just said, "You know, I need to take care of myself today," and didn't really say anything else [laughs] about why. Because they're like, "Oh, like, that helped normalize this idea that, like, that is fine just kind of as is." There's no need to, you know, supply any additional reasoning. +JOËL: Sometimes I feel like people almost feel the need to like, justify taking sick time. So, you've got to, like, say just how bad things are that now I'm actually taking sick time. +STEPHANIE: Yeah, which is...that's not the point, right? You know, we have it because we need it [laughs]. So, yeah, I'm glad you mentioned that because I think that's actually a really good example of the ways that people, like, approach kind of bringing themselves to work like that. +JOËL: Yeah, sometimes it's setting a boundary. An aspect I'm curious to look at is you, and I do a little bit of this with this podcast, right? Every week, we share a little bit of what's new in our world, and it goes out into the public internet. How do you tend to pick those topics and, like, how personal are you willing to get? +STEPHANIE: Yeah. Oh, that's so hard. It's always hard [laughs], I think. I generally am pretty open. You know, I have talked about plans that I have for moving. I don't know, things about my gardening. I think I've also been a little vulnerable on the show before when I've, like, had a challenge, like, at work. But yeah, it's important, to me, I think, to be, like, true. Like, I think part of what our listeners like about this show is that we show up every week, and it's just a chat between two friends [laughs]. +JOËL: Uh-huh. +STEPHANIE: It also is kind of weird to know that it's just, like, out there, right? And I don't really know who's listening on the other side. I do know that, like, a lot of my friends listen. And, in some ways, I like to think that I'm talking to them, right? But yeah, sometimes I think about just, like, in a decade [laughs], it will still be out there. And on one hand, I think maybe it's kind of cool because I can listen back and be like, oh, like, that's what was going on for me in 2024. +And other times I'm like, oh my God, what if I'm one day just, like, deeply embarrassed by things I've talked about on this show [laughs]? But that's a risk, I guess, I'm willing to take because I do think that the sense of connection that we foster with our audience is really meaningful. And it gives me a lot of joy whenever I meet a listener who's like, "Oh, you, you know, talked about this one thing, and I really related to it." And yeah, I guess that's what I do this for. What about you? +JOËL: Yeah, I think kind of similar to you; tend to talk about things at work, interesting technical challenges, interesting sort of work, or even sometimes client-related challenges. Of course, you know, never calling out any clients by name, you know, talk about some hobbies and things like that. I think where I tend to draw the line a little bit is things that are a little bit more people-oriented in my personal life. So, I tend to not talk about family, and friends, and relationships, and things like that. And, you know, there are some times where there's like, those things intermix a little bit, where I'll, like, have shared, like, "This is what's new in my world." And then, like, off air, I'll follow up with you and say, "So, I didn't tell the whole story on air. +STEPHANIE: [laughs] Yeah. +JOËL: Here's what actually happened." Or, you know, "Here's this extra anecdote that I wanted you to know, but I didn't want everyone in the audience to hear." +STEPHANIE: Yeah. I think the weirdest part for me, too, is I certainly have my, like, parasocial relationships with people that I follow on the internet [laughs], like, people on YouTube, or other podcasts, and stuff like that. But I haven't thought a whole lot about just, like, what that looks like for me as a host of a podcast. I think, kind of the size of the show now it feels right for me, where it's like I run into people who listen at conferences and stuff like that, but it is kind of contained to a work-related thing. So, that feels good because it, I think, for me, helps just give the work stuff a little bit of a deeper meaning, but otherwise isn't spilling over to my regular life. +JOËL: And it's always fun when, you know, we get a listener email connecting to, you know, one of the random hobbies or something we've talked about and sharing a little bit of their experiences. I think last spring, I talked about getting a pair of bike shorts and, like, trying it out and seeing how that worked. And a listener called in and shared their experience with bike shorts, and, like, that's a lot of fun. It kind of creates that connection. So, I do enjoy that aspect. +STEPHANIE: Yeah. And just to plug, you can write in to us at hosts@bikeshed.fm, and if you have anything you want to share that was inspired by what you heard us talk about on the show. +JOËL: We'd love to have you. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + AI-generated images, D&D-themed talk, RailsConf preparation, thoughtbot, podcast production, Glittersense character, team culture, pod puns, cross-podination, psychological safety, authentic self at work, remote work dynamics, personal disclosure at work, team cohesion, inclusive work environment. + + Joël shares his preparations for his RailsConf talk, which is D&D-themed and centered around a gnome character named Glittersense. Stephanie expresses her delight in creating pod-related puns within thoughtbot's internal team structure, like "cross-podination" for inter-pod meetings and the adorable observation that her pod resembles "three peas in a pod" when using the git co-authored-by feature.

+ +

Together, Stephanie and Joël discuss bringing one's authentic self to work, balancing personal disclosure with professional boundaries, and fostering psychological safety. They highlight the value of shared interests and personal anecdotes in enhancing team cohesion, especially remotely, and stress the importance of an inclusive culture that respects individual preferences and boundaries.

+ +

Transcript:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

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, at the time of this recording, we're recording this the week before RailsConf. I've been working on some of the visuals for my RailsConf talk and leaning on AI to generate some of these. So, my talk is D&D-themed, and it's very narrative-based. We follow the adventures of this gnome named Glittersense throughout the talk as we learn about how to use Turbo to build a D&D character sheet. And so, I wanted the AI to generate images for me.

+ +

And the problem I've had with a lot of AI-generated images is that you're like, okay, I need a gnome, you know, in a fight doing this, doing that. But then, like, every time, you get, like, totally different images. You're like, "Oh, I need an image where it's this," but then, like, the character is different in all the scenes, and there's no consistency. So, I've been leaning a little bit more into the memory aspect of ChatGPT, where you can sort of tell it, "Look, these are the things. Now, whenever I refer to Glittersense, whenever you draw an image, do it with these characteristics that we've established what the character looks like."

+ +

Sometimes I'll have, like, a text conversation kind of, like, setting up the physical characteristics. And then, it's like, okay, now every time you draw him, draw him like this, or now every time you draw him, draw him with this particular piece of equipment that we've created. And so, leaning into that memory has allowed me to create a series of images that feel a little bit more consistent in a way that's been really interesting.

+ +

STEPHANIE: Cool. Yeah, that makes sense because you are telling a story, right? And you need it to have a through line and the imagery be matching as you progress in your presentation. I actually don't know a lot about how that memory works. Does it persist across sessions? Do you have to do it all in one [laughs] go, or how does that work?

+ +

JOËL: So, there's, like, a persistent chat. So, you can start sort of multiple conversations, but each conversation is its own thread with its own memory. And it will sort of keep track of certain things. And sometimes I'll even say, "Hey..." instead of, like, prompting it for something to get a response, you could prompt it to add things to its memory. So say like, "From now on, when I ask you these types of questions, I want you to respond in this way," or, "From now on, when I ask you to generate an image, I want it done in this format." So, for example, RailsConf requires all of their slides to be 16 by 9. If I want, like, a kind of cover image or, like, something full-screen, I need an image that is 16 by 9. So, one of the things I prompt the AI with is just, "From now on, whenever you generate an image, give me an image in 16:9 aspect ratio."

+ +

STEPHANIE: Cool. I also was intrigued by your gnome's name, Glittersense. And I was wondering what the story behind that character is.

+ +

JOËL: The story behind the name is that I was playing D&D with a friend who was this very kind of eclectic Dragonborn character. And I did some sort of valiant deed and got the name Glittersense bestowed upon me by this Dragonborn for having helped him out in some, like, cool way. So, that's a fun name. And so, when I was searching for a name for my character in this talk, I was like, you know what? Let's bring back Glittersense. I like that. I think it captures a little bit of, like, the wonder and the whimsy of a gnome.

+ +

STEPHANIE: That's really cute. I like that a lot.

+ +

JOËL: So, Stephanie, what's been new in your world?

+ +

STEPHANIE: So, lately, I've been having a lot of fun with coming up with names of things. You know the saying how naming is one of the hardest things in software? Well, okay, I'm not actually going to talk about anything that I named very particularly well in my code, but I've been just coming up with a lot of puns. It's just, I don't know, my brain is kind of in that space. And one thing that...I can't recall if I have talked about this on the show before, but our team at thoughtbot is experimenting with kind of smaller sub-teams within it called pods. We have now kind of been split into pods with other people who are working on maybe similar client projects. I have been having some really good naming ideas around [laughs] pod-related puns.

+ +

So, one thing that we did as part of this experiment was setting up meetings for pods to meet each other, and spend time together, and kind of share what each other was up to. And I was the first to coin the term cross-podination, kind of like cross-pollination. And I think I just, like, said it offhand one day, and then it caught on. And I was very pleasantly surprised to see that people just leaned into it and started naming those meetings cross-podination meetings.

+ +

And then, another one that came about recently was my pod there's three of us in it, and we were pairing, or I guess it's not really called a pairing if there's three. We were mobbing or ensembling, whatever you want to call it. And sometimes we like to use the git co-authored-by feature where you can attribute, you know, commits to people that you worked on them with. And in GitHub when you, you know, add people's emails to the commit, you know, you see your little GitHub profile picture in a little circle. And when you have multiple people shared on a commit, it is just, like, squished together. And since we're a trio, I was like, "Oh, it's like we're, like, three peas in a pod."

+ +

JOËL: [chuckles]

+ +

STEPHANIE: And I realized that it was an excellent missed opportunity for our pod name. We're something else. But I am hereby reserving that name for the next pod that I am in. You heard it here first [laughs]. It looked exactly like just three snug little peas. And I, yeah, it was very cute. I was very delighted. And yeah, that's what's new for me.

+ +

JOËL: I'll also point out the fact that you are currently talking on a podcast.

+ +

STEPHANIE: Whoa, whoa. So, you and I are a pod [laughter]. We're a podcasting pod [laughs]. Wow, I didn't even think about that. My world is just pods right now [laughs], folks.

+ +

JOËL: How do you feel about puns as an art form?

+ +

STEPHANIE: [laughs] Wow, art form is a strong phrase to use. I don't hate them. I think it depends. Sometimes I will cringe, and other times I'm like, that's great. That's excellent. Yeah, I think it depends. But I guess, clearly, I'm in my pun era, so I've just accepted it.

+ +

JOËL: Are you the kind of person who is, like, ashamed but secretly proud when you make a really good pun?

+ +

STEPHANIE: Yeah, that's a very good way to describe it. I'm sure there are other people out there [laughs].

+ +

JOËL: What's interesting with puns, right? Like, some people love them, some people hate them. Some people really lean into them, like, that becomes almost, like, part of their personality. We had a former teammate who his...we made a custom Slack emoji with his face, and it was the pun emoji because he always had a good pun ready for any situation. And so, that's sort of a way that I feel like sometimes you get to bring an aspect of your personality or at least a persona to work. What parts of yourself do you like to bring to work? What parts do you like to maybe leave out?

+ +

STEPHANIE: Yeah, I am really excited about this topic because I feel like it's a little bit evergreen, maybe was kind of a trendy thing to talk about in terms of team culture in the past couple of years, but this idea of bringing an authentic or whole self to work as, like, an ideal. And I don't know that I totally agree with that [laughs] because, like you said, sometimes you have a different kind of persona, or you have a kind of way that you want to present yourself at work. And that doesn't necessarily mean it's a bad thing. I personally like some kind of separation in terms of my work self and my rest of life self [laughs]. Yeah, I just think that should be fine.

+ +

JOËL: So, you might secretly be the pun master, but you don't want your colleagues to know.

+ +

STEPHANIE: [laughs] That's true. Or I save my puns only for work [laughter]. If I ever have, like, a shower thought where I think of a really good pun, I will, like, send a Slack message to myself to find [laughs] the perfect opportunity to use this pun in a meeting [laughs]. I don't actually do that, but that would be very funny.

+ +

JOËL: I feel like there's probably a sense in which nobody is a hundred percent their authentic self or their full self in a work situation, you know, it varies by person. But I'm sure everybody, to a certain extent, has a professional persona that they inhabit during work hours.

+ +

STEPHANIE: Yeah, and I like that the way we're talking about it, too, is a professional persona doesn't necessarily mean that you're just a little...matching kind of a business speak bot [laughs], where it's kind of devoid of personality, but just using all the right language in their emails [laughs] and the correct business jargon or whatever. To me, what is important is that people are able to choose how they show up or present themselves at work. That's, like, an active choice that they're making, not out of obligation or fear of consequences. You know, like, it's fine to be a little more private at work if that's just how you want to operate. And it's also fine to be more open about sharing things going on in your personal life.

+ +

Because I've seen ways in which both have been more enforced or, like, there's pressure to perform one way or another. And that could mean, like, when people kind of encourage others to try to be more of themselves or, like, share more things about personal life. That's not always necessarily a good thing if it's not something that people are comfortable with. And I suspect that we have kind of pulled back a little bit from that, but there was certainly a time when that was a bit of an expectation. And I'm not sure that that was quite [chuckles] what we wanted to aim for in terms of just the modern workplace.

+ +

JOËL: It is interesting because I think there can be some advantages to maybe building connection with people by sharing a little bit more about your life. But, again, if there's pressure to do it, that becomes really unwholesome.

+ +

STEPHANIE: Yeah. Unwholesome is a good word to use. Like, I want that wholesome content [laughs] at work. And I actually have a couple of thoughts about how I prefer to share, like, just personal things with my team members. And I'm curious kind of where you fall on this as well. But a couple of things that our team does that I really like is we have a quarterly newsletter that one of our team leads puts together. She has an open call for submissions, and people just share any, like travel plans, any professional wins, any kind of personal life things that they want to share.

+ +

People love talking about their home improvement adventures [laughs] on our team, which is really fun. And yeah, like, just share photos and a little blurb about what they've been up to. And this happens every quarter. And it's always such a delight to remember a little bit like, oh yeah, my co-workers have lives outside of work. But I really like that it's opt-in and also not that frequent, you know? It's kind of like, this is the time to share any like, special things that have happened in the past three months. And yeah, I think every time a new dispatch of it comes out, everyone kind of gets the warm and fuzzy feelings of appreciating their co-workers and what they've been up to.

+ +

JOËL: Do you think that that kind of sharing sort of maybe helps personalize a little bit of our colleagues, especially because we're all remote and we're interacting with each other through a screen?

+ +

STEPHANIE: Yes. Yeah. That's another good distinction. I think it is, like, a little more important that there are touch points like these when we are working remote because, yeah, the water cooler conversation just doesn't really happen nearly as much as it does when you're in an office. And I feel like that's the kind of thing that I would talk about at the water cooler [laughs]. It's like, "Oh yeah, I went to Disney World, or traveled for this conference, or I built new garden beds for my yard," just stuff like that. I don't know, I don't find that...like, when you're just communicating over Slack and email, there's not a good place for that kind of stuff. And that's why I really like the newsletter.

+ +

JOËL: One thing that's interesting about the difference between in-person and remote is that, in person, a way that you can express personality in the office is you can do some things with your workspace. You might have some items on your desk that are of personal interest. And, you know, you might still do that when you're working remote, but those don't get captured by your webcam unless it's in your background.

+ +

Your background you can get real creative with. But you can also, like, really curate that to, like, show practically nothing. Whereas if you were putting things on your desk in the office, there's kind of no way for your colleagues not to see that. So, you had to be...like, it had to be things that you were willing for everyone to see. But at the same time, sometimes it's nice to be able to say, hey, I'm going to put a touch of, like, things that are meaningful to me in my work life.

+ +

STEPHANIE: Yeah, I really like that. I mean, Joël, your background is always these framed maps on the wall, hanging on the wall, and that is very you, I think. Did you kind of think about how they'll just be your background whenever you're in a meeting, or they just happened to be there?

+ +

JOËL: So, these I had set up pre-pandemic. I like the décor. And then, when I started working from home in 2020, I was trying to figure out, like, where do I want to be to take meetings? And I was like, you know what? The math wall is pretty cool. I think that's going to be my background. I guess now it's almost become, like, a bit of a trademark.

+ +

STEPHANIE: Yeah, I feel that. My trademark...I have a few because I like to move around when I take meetings. So, when I'm at my desk, it's the plants in my office. When I'm in my kitchen, it's either my jars [laughs]. So, I have, like, open shelving and just all of these jars of, you know, some of it is ingredients like nuts, and grains, and stuff like that, and some of it is just empty jars that I use for drinking water. So, I have my jar collection. And then, occasionally, if I'm sitting on the other side of the table [chuckles], all of my pots and pans are hanging in the background from above my stove. So, yeah, I'm the jars, pots, and plants person [laughs] at the company.

+ +

JOËL: You know, we were talking earlier about the idea that it's harder to see your sort of workspace in a remote world. And I just remembered that we do a semi-regular...there's, like, a thread at thoughtbot where people just share pictures of their workspace, and it's opt-in. You don't have to put anything in there. But you get a little bit of, like, oh, the other side of the camera. That's pretty cool.

+ +

STEPHANIE: Yeah, I love seeing those threads. And I think a lot of people in our industry are also gear nerds, so [laughter] they love to see people's, like, fancy monitor and keyboard setups, maybe some cool lighting, oh, like, wire organization [laughs].

+ +

JOËL: Cable management.

+ +

STEPHANIE: Yep. Yep. Those are fun. And I actually think another one that we've lost since going remote is laptop stickers because that was such a great way for people to show some personality and things that they love, like programming stuff, maybe, like, you know, language stickers or organizations like thoughtbot stickers, too, and also, more personal stuff if they want. At a previous company, we were also remote, and someone came up with a really fun game where people anonymously submitted pictures of their laptop stickers. And we got together and tried to guess whose laptop belonged to who just based on the stickers.

+ +

JOËL: Oh, that's fun.

+ +

STEPHANIE: Yeah, that was really fun. I keep forgetting that I wanted to organize something like that for thoughtbot. But now I'm just thinking about it, and I feel the need to decorate my laptop with some stickers after this [laughs].

+ +

JOËL: One thing I do want to highlight, though, is the fact that several years back, when people were talking a lot about the importance of bringing your sort of authentic or whole self to work, one of the really valuable parts of that conversation was giving people the ability to do that, not forcing people to sort of hide parts of themselves, especially if they don't fit into a dominant culture or demographic, in order to be able to even function at work, right? That's a sort of key aspect of, I guess, basic inclusivity. And so, I think that's still a hundred percent true today. We want to build cultures that are inclusive, both in our in-person professional situations and for remote teams.

+ +

STEPHANIE: Yeah, 100%. I think, for me, what I think is a good measure of that is, you know, how comfortable are people disagreeing at the company kind of in public or sharing an alternative perspective? Like, that should be okay and celebrated, even, and considered, you know, with equal weight as kind of what you're saying, the dominant identity or even just opinion. Like, especially in tech, I think people have very strongly held opinions, and when they're disagreed with...I've become a little skeptical of the idea of, like, this is how we do things here or, like, we don't do that.

+ +

And I think that rather than sticking to a, like, stance like that, there's always room to incorporate, like, new approaches, new perspectives, new ways of thinking to a given problem. And that can only happen when people are comfortable with going there, you know, and kind of saying, like, "This is important to me," or, like, "This is how I feel about it." And that, in and of itself, is just equally valid [laughs] as whatever is taking the airtime currently.

+ +

JOËL: That's really interesting because I feel like now you've leaned into almost the idea of psychological safety for a team. And if you're having to sort of repress or hide elements of the way you think, or maybe even sort of core elements of your identity to fit in with a team, that's not psychologically safe, and you can't have those deeper conversations.

+ +

STEPHANIE: Yeah, 100%. I think it's two sides of the same coin, you know, it's like two ways of saying the same thing, that people should be able to conduct themselves in the way they choose to [laughs]. And I can't imagine anyone really disagreeing with a statement like that.

+ +

JOËL: So, I know you choose to not always share everything about your life or sort of...I don't want to say bring your authentic self but, like, bring everything about yourself to the workplace. Do you have a sort of a heuristic for what you decide to share or not share?

+ +

STEPHANIE: Yeah. I don't know if it's necessarily a heuristic so much as it's just what I do [laughs]. But I tend to do better with, like, smaller groups, and, actually, that's why I think pods has been working really well for me personally because I can share personal information just in a more intimate setting, which is helpful for me. And yeah, I tend to, like, find once, like, either Slack channels or Spaces, meetings are starting to get into the, like, 10, 11, 12 people territory is when I hold it back a little bit more, not because of any sort of, like, reason that I don't want to share. It's just, like, that's just not the venue for me.

+ +

But I do love when other people are, like, open, even in, like, larger spaces like that. I appreciate when other people do it just to, you know, signal that it's okay [laughs]. And I enjoy throwing a reaction or responding in a thread about, you know, something that someone shared in a bigger channel. And I think that diversity is actually really helpful because it conveys that, like, there's different ways of existing online in your work environment and that they're all acceptable. What about you? How do you kind of choose where to share things about your personal life?

+ +

JOËL: I think, kind of like you, I don't really have a heuristic. I just sort of go with gut feeling. I think I, sort of by nature, have always been maybe a little bit of having, like, separate professional and personal lives and keeping those a little bit more distinct. And, you know, there's some things that kind of cross over, like, oh, you know, I tried out this fun, new restaurant, or I did a cool activity over the weekend, or something like that.

+ +

I think I've come to see that there can be a lot of value in sharing parts of yourself with other colleagues. And so, from time to time, I'll, like, maybe bring in something a little bit deeper. And, like you said, sometimes that's more easily done in a smaller context. And then yeah, for some things, it's like, okay, I'm going to share photos from a vacation in that, you know, quarterly newsletter. That's kind of fun. But also knowing that there's no pressure that's nice.

+ +

STEPHANIE: Yeah. I think you're really good about finding the right avenues for that. I like, love when you show photos in the travel channel, even though I have that channel muted [laughs]. You'll, like, send me the link to the post in that channel. And yeah, I love that because it's a way for you to kind of, like, find the right place for it, and then also share it with any particular people if you choose to.

+ +

JOËL: I think, also, personal connections can be a way to build deeper relationships, especially in smaller groups. And you can form deeper connections with colleagues over a particular project, or a particular technology, or a tech topic, or, you know, just a passion about mechanical keyboards, or something like that. But if you're people who chat kind of more on the regular for different things, maybe separate from a client project you're on or something like that, and you do find yourself exchanging a little bit more about, oh, you know, what you're doing in your life, or what are the things that are going on for you, that often does tend to build, I think, a deeper connection between colleagues, which can be really nice.

+ +

STEPHANIE: Yeah. And I like that those relationships can also change. Like, there's different seasons in which you're more connected to some people and then less connected. Sometimes a colleague that you have shared interests with becomes someone that you kind of are in touch with more regularly, and then maybe you switch projects, and you aren't so much kind of as up to date. But, I don't know, I always think that there's, like, the right time for that kind of stuff, and it emerges.

+ +

JOËL: I'm going to throw a bit of a buzzword at you, and I'd love to get your reaction. The idea of belonging, the feeling of belonging on a team, is that a good thing, something that we should seek out? And if so, how much of that is responsibility of, like, management or, like, a property of the team or the group to make you sort of feel that belonging? And how much of that is on you having to maybe disclose things about yourself or share a little bit of your personal life to, like, create that sense of belonging?

+ +

STEPHANIE: Whoa. Yeah, that is a good way to frame it. I think there's a balance. There've been some, like, periods of my work life where I'm like, oh, I need more of a detachment from work and other times where I'm like, oh, I feel really disconnected, like, I want to feel like more of a part of this team. But I do think it's a management responsibility. And one thing that I know people to be cautious of is, you know, becoming too close at work. I don't know if your work being treated like a family, like, that kind of language can be a little bit borderline.

+ +

JOËL: Almost manipulative.

+ +

STEPHANIE: Right. Yeah, exactly. I do think there's something to be said about community at work and feeling like that kind of belonging, right? But also, that you can choose how much, like, you want to engage with that community and that being okay. I don't think it necessarily needs to be only through what you share about yourself. Like, you can have that sense of connection just by being a good colleague [chuckles], right? Like, even if the things you talk about are just within the realm of the project you're working on, like, there's still a sense of commitment and, yeah, in that relationship. And I think that is what matters when it comes to belonging.

+ +

In the past, ways that I've seen that work well in regards to kind of how you share information is just, like, I don't know, share how you're doing. Like, you don't have to provide too many details. But it could be like, "Oh, I'm kind of distracted in my personal life right now, and that's why I wasn't able to get this done." People should be understanding of that, even if you don't kind of let them in on the more personal aspects of it.

+ +

JOËL: Right. And you don't have to give any details, right?

+ +

STEPHANIE: Yeah.

+ +

JOËL: You should be in a place where people are comfortable with not knowing and not be like, "Ooh, what's going on with Stephanie's life? "

+ +

STEPHANIE: [laughs] Yeah. But I do also think, like, the knowing that, like, something is going on is, like, also important context, right? Because you don't necessarily want that to impact the commitments you do have at work.

+ +

JOËL: Right. And people tend to be a little bit more understanding if you're having to maybe shift some meetings around, or if you're struggling to focus on a particular day, or something like that.

+ +

STEPHANIE: Yeah. 100%.

+ +

JOËL: Yeah, we should normalize it of just like, "Hey, I'm having a hard day. I don't want to give details, but you know."

+ +

STEPHANIE: Yeah. Yeah. I think a way that that is always kind of weird is how people communicate they're taking a sick day [laughs]. I actually had someone tell me that they really appreciated a time when I just said, "You know, I need to take care of myself today," and didn't really say anything else [laughs] about why. Because they're like, "Oh, like, that helped normalize this idea that, like, that is fine just kind of as is." There's no need to, you know, supply any additional reasoning.

+ +

JOËL: Sometimes I feel like people almost feel the need to like, justify taking sick time. So, you've got to, like, say just how bad things are that now I'm actually taking sick time.

+ +

STEPHANIE: Yeah, which is...that's not the point, right? You know, we have it because we need it [laughs]. So, yeah, I'm glad you mentioned that because I think that's actually a really good example of the ways that people, like, approach kind of bringing themselves to work like that.

+ +

JOËL: Yeah, sometimes it's setting a boundary. An aspect I'm curious to look at is you, and I do a little bit of this with this podcast, right? Every week, we share a little bit of what's new in our world, and it goes out into the public internet. How do you tend to pick those topics and, like, how personal are you willing to get?

+ +

STEPHANIE: Yeah. Oh, that's so hard. It's always hard [laughs], I think. I generally am pretty open. You know, I have talked about plans that I have for moving. I don't know, things about my gardening. I think I've also been a little vulnerable on the show before when I've, like, had a challenge, like, at work. But yeah, it's important, to me, I think, to be, like, true. Like, I think part of what our listeners like about this show is that we show up every week, and it's just a chat between two friends [laughs].

+ +

JOËL: Uh-huh.

+ +

STEPHANIE: It also is kind of weird to know that it's just, like, out there, right? And I don't really know who's listening on the other side. I do know that, like, a lot of my friends listen. And, in some ways, I like to think that I'm talking to them, right? But yeah, sometimes I think about just, like, in a decade [laughs], it will still be out there. And on one hand, I think maybe it's kind of cool because I can listen back and be like, oh, like, that's what was going on for me in 2024.

+ +

And other times I'm like, oh my God, what if I'm one day just, like, deeply embarrassed by things I've talked about on this show [laughs]? But that's a risk, I guess, I'm willing to take because I do think that the sense of connection that we foster with our audience is really meaningful. And it gives me a lot of joy whenever I meet a listener who's like, "Oh, you, you know, talked about this one thing, and I really related to it." And yeah, I guess that's what I do this for. What about you?

+ +

JOËL: Yeah, I think kind of similar to you; tend to talk about things at work, interesting technical challenges, interesting sort of work, or even sometimes client-related challenges. Of course, you know, never calling out any clients by name, you know, talk about some hobbies and things like that. I think where I tend to draw the line a little bit is things that are a little bit more people-oriented in my personal life. So, I tend to not talk about family, and friends, and relationships, and things like that. And, you know, there are some times where there's like, those things intermix a little bit, where I'll, like, have shared, like, "This is what's new in my world." And then, like, off air, I'll follow up with you and say, "So, I didn't tell the whole story on air.

+ +

STEPHANIE: [laughs] Yeah.

+ +

JOËL: Here's what actually happened." Or, you know, "Here's this extra anecdote that I wanted you to know, but I didn't want everyone in the audience to hear."

+ +

STEPHANIE: Yeah. I think the weirdest part for me, too, is I certainly have my, like, parasocial relationships with people that I follow on the internet [laughs], like, people on YouTube, or other podcasts, and stuff like that. But I haven't thought a whole lot about just, like, what that looks like for me as a host of a podcast. I think, kind of the size of the show now it feels right for me, where it's like I run into people who listen at conferences and stuff like that, but it is kind of contained to a work-related thing. So, that feels good because it, I think, for me, helps just give the work stuff a little bit of a deeper meaning, but otherwise isn't spilling over to my regular life.

+ +

JOËL: And it's always fun when, you know, we get a listener email connecting to, you know, one of the random hobbies or something we've talked about and sharing a little bit of their experiences. I think last spring, I talked about getting a pair of bike shorts and, like, trying it out and seeing how that worked. And a listener called in and shared their experience with bike shorts, and, like, that's a lot of fun. It kind of creates that connection. So, I do enjoy that aspect.

+ +

STEPHANIE: Yeah. And just to plug, you can write in to us at hosts@bikeshed.fm, and if you have anything you want to share that was inspired by what you heard us talk about on the show.

+ +

JOËL: We'd love to have you.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël shares his preparations for his RailsConf talk, which is D&D-themed and centered around a gnome character named Glittersense. Stephanie expresses her delight in creating pod-related puns within thoughtbot's internal team structure, like "cross-podination" for inter-pod meetings and the adorable observation that her pod resembles "three peas in a pod" when using the git co-authored-by feature.

+ +

Together, Stephanie and Joël discuss bringing one's authentic self to work, balancing personal disclosure with professional boundaries, and fostering psychological safety. They highlight the value of shared interests and personal anecdotes in enhancing team cohesion, especially remotely, and stress the importance of an inclusive culture that respects individual preferences and boundaries.

+ +

Transcript:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

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, at the time of this recording, we're recording this the week before RailsConf. I've been working on some of the visuals for my RailsConf talk and leaning on AI to generate some of these. So, my talk is D&D-themed, and it's very narrative-based. We follow the adventures of this gnome named Glittersense throughout the talk as we learn about how to use Turbo to build a D&D character sheet. And so, I wanted the AI to generate images for me.

+ +

And the problem I've had with a lot of AI-generated images is that you're like, okay, I need a gnome, you know, in a fight doing this, doing that. But then, like, every time, you get, like, totally different images. You're like, "Oh, I need an image where it's this," but then, like, the character is different in all the scenes, and there's no consistency. So, I've been leaning a little bit more into the memory aspect of ChatGPT, where you can sort of tell it, "Look, these are the things. Now, whenever I refer to Glittersense, whenever you draw an image, do it with these characteristics that we've established what the character looks like."

+ +

Sometimes I'll have, like, a text conversation kind of, like, setting up the physical characteristics. And then, it's like, okay, now every time you draw him, draw him like this, or now every time you draw him, draw him with this particular piece of equipment that we've created. And so, leaning into that memory has allowed me to create a series of images that feel a little bit more consistent in a way that's been really interesting.

+ +

STEPHANIE: Cool. Yeah, that makes sense because you are telling a story, right? And you need it to have a through line and the imagery be matching as you progress in your presentation. I actually don't know a lot about how that memory works. Does it persist across sessions? Do you have to do it all in one [laughs] go, or how does that work?

+ +

JOËL: So, there's, like, a persistent chat. So, you can start sort of multiple conversations, but each conversation is its own thread with its own memory. And it will sort of keep track of certain things. And sometimes I'll even say, "Hey..." instead of, like, prompting it for something to get a response, you could prompt it to add things to its memory. So say like, "From now on, when I ask you these types of questions, I want you to respond in this way," or, "From now on, when I ask you to generate an image, I want it done in this format." So, for example, RailsConf requires all of their slides to be 16 by 9. If I want, like, a kind of cover image or, like, something full-screen, I need an image that is 16 by 9. So, one of the things I prompt the AI with is just, "From now on, whenever you generate an image, give me an image in 16:9 aspect ratio."

+ +

STEPHANIE: Cool. I also was intrigued by your gnome's name, Glittersense. And I was wondering what the story behind that character is.

+ +

JOËL: The story behind the name is that I was playing D&D with a friend who was this very kind of eclectic Dragonborn character. And I did some sort of valiant deed and got the name Glittersense bestowed upon me by this Dragonborn for having helped him out in some, like, cool way. So, that's a fun name. And so, when I was searching for a name for my character in this talk, I was like, you know what? Let's bring back Glittersense. I like that. I think it captures a little bit of, like, the wonder and the whimsy of a gnome.

+ +

STEPHANIE: That's really cute. I like that a lot.

+ +

JOËL: So, Stephanie, what's been new in your world?

+ +

STEPHANIE: So, lately, I've been having a lot of fun with coming up with names of things. You know the saying how naming is one of the hardest things in software? Well, okay, I'm not actually going to talk about anything that I named very particularly well in my code, but I've been just coming up with a lot of puns. It's just, I don't know, my brain is kind of in that space. And one thing that...I can't recall if I have talked about this on the show before, but our team at thoughtbot is experimenting with kind of smaller sub-teams within it called pods. We have now kind of been split into pods with other people who are working on maybe similar client projects. I have been having some really good naming ideas around [laughs] pod-related puns.

+ +

So, one thing that we did as part of this experiment was setting up meetings for pods to meet each other, and spend time together, and kind of share what each other was up to. And I was the first to coin the term cross-podination, kind of like cross-pollination. And I think I just, like, said it offhand one day, and then it caught on. And I was very pleasantly surprised to see that people just leaned into it and started naming those meetings cross-podination meetings.

+ +

And then, another one that came about recently was my pod there's three of us in it, and we were pairing, or I guess it's not really called a pairing if there's three. We were mobbing or ensembling, whatever you want to call it. And sometimes we like to use the git co-authored-by feature where you can attribute, you know, commits to people that you worked on them with. And in GitHub when you, you know, add people's emails to the commit, you know, you see your little GitHub profile picture in a little circle. And when you have multiple people shared on a commit, it is just, like, squished together. And since we're a trio, I was like, "Oh, it's like we're, like, three peas in a pod."

+ +

JOËL: [chuckles]

+ +

STEPHANIE: And I realized that it was an excellent missed opportunity for our pod name. We're something else. But I am hereby reserving that name for the next pod that I am in. You heard it here first [laughs]. It looked exactly like just three snug little peas. And I, yeah, it was very cute. I was very delighted. And yeah, that's what's new for me.

+ +

JOËL: I'll also point out the fact that you are currently talking on a podcast.

+ +

STEPHANIE: Whoa, whoa. So, you and I are a pod [laughter]. We're a podcasting pod [laughs]. Wow, I didn't even think about that. My world is just pods right now [laughs], folks.

+ +

JOËL: How do you feel about puns as an art form?

+ +

STEPHANIE: [laughs] Wow, art form is a strong phrase to use. I don't hate them. I think it depends. Sometimes I will cringe, and other times I'm like, that's great. That's excellent. Yeah, I think it depends. But I guess, clearly, I'm in my pun era, so I've just accepted it.

+ +

JOËL: Are you the kind of person who is, like, ashamed but secretly proud when you make a really good pun?

+ +

STEPHANIE: Yeah, that's a very good way to describe it. I'm sure there are other people out there [laughs].

+ +

JOËL: What's interesting with puns, right? Like, some people love them, some people hate them. Some people really lean into them, like, that becomes almost, like, part of their personality. We had a former teammate who his...we made a custom Slack emoji with his face, and it was the pun emoji because he always had a good pun ready for any situation. And so, that's sort of a way that I feel like sometimes you get to bring an aspect of your personality or at least a persona to work. What parts of yourself do you like to bring to work? What parts do you like to maybe leave out?

+ +

STEPHANIE: Yeah, I am really excited about this topic because I feel like it's a little bit evergreen, maybe was kind of a trendy thing to talk about in terms of team culture in the past couple of years, but this idea of bringing an authentic or whole self to work as, like, an ideal. And I don't know that I totally agree with that [laughs] because, like you said, sometimes you have a different kind of persona, or you have a kind of way that you want to present yourself at work. And that doesn't necessarily mean it's a bad thing. I personally like some kind of separation in terms of my work self and my rest of life self [laughs]. Yeah, I just think that should be fine.

+ +

JOËL: So, you might secretly be the pun master, but you don't want your colleagues to know.

+ +

STEPHANIE: [laughs] That's true. Or I save my puns only for work [laughter]. If I ever have, like, a shower thought where I think of a really good pun, I will, like, send a Slack message to myself to find [laughs] the perfect opportunity to use this pun in a meeting [laughs]. I don't actually do that, but that would be very funny.

+ +

JOËL: I feel like there's probably a sense in which nobody is a hundred percent their authentic self or their full self in a work situation, you know, it varies by person. But I'm sure everybody, to a certain extent, has a professional persona that they inhabit during work hours.

+ +

STEPHANIE: Yeah, and I like that the way we're talking about it, too, is a professional persona doesn't necessarily mean that you're just a little...matching kind of a business speak bot [laughs], where it's kind of devoid of personality, but just using all the right language in their emails [laughs] and the correct business jargon or whatever. To me, what is important is that people are able to choose how they show up or present themselves at work. That's, like, an active choice that they're making, not out of obligation or fear of consequences. You know, like, it's fine to be a little more private at work if that's just how you want to operate. And it's also fine to be more open about sharing things going on in your personal life.

+ +

Because I've seen ways in which both have been more enforced or, like, there's pressure to perform one way or another. And that could mean, like, when people kind of encourage others to try to be more of themselves or, like, share more things about personal life. That's not always necessarily a good thing if it's not something that people are comfortable with. And I suspect that we have kind of pulled back a little bit from that, but there was certainly a time when that was a bit of an expectation. And I'm not sure that that was quite [chuckles] what we wanted to aim for in terms of just the modern workplace.

+ +

JOËL: It is interesting because I think there can be some advantages to maybe building connection with people by sharing a little bit more about your life. But, again, if there's pressure to do it, that becomes really unwholesome.

+ +

STEPHANIE: Yeah. Unwholesome is a good word to use. Like, I want that wholesome content [laughs] at work. And I actually have a couple of thoughts about how I prefer to share, like, just personal things with my team members. And I'm curious kind of where you fall on this as well. But a couple of things that our team does that I really like is we have a quarterly newsletter that one of our team leads puts together. She has an open call for submissions, and people just share any, like travel plans, any professional wins, any kind of personal life things that they want to share.

+ +

People love talking about their home improvement adventures [laughs] on our team, which is really fun. And yeah, like, just share photos and a little blurb about what they've been up to. And this happens every quarter. And it's always such a delight to remember a little bit like, oh yeah, my co-workers have lives outside of work. But I really like that it's opt-in and also not that frequent, you know? It's kind of like, this is the time to share any like, special things that have happened in the past three months. And yeah, I think every time a new dispatch of it comes out, everyone kind of gets the warm and fuzzy feelings of appreciating their co-workers and what they've been up to.

+ +

JOËL: Do you think that that kind of sharing sort of maybe helps personalize a little bit of our colleagues, especially because we're all remote and we're interacting with each other through a screen?

+ +

STEPHANIE: Yes. Yeah. That's another good distinction. I think it is, like, a little more important that there are touch points like these when we are working remote because, yeah, the water cooler conversation just doesn't really happen nearly as much as it does when you're in an office. And I feel like that's the kind of thing that I would talk about at the water cooler [laughs]. It's like, "Oh yeah, I went to Disney World, or traveled for this conference, or I built new garden beds for my yard," just stuff like that. I don't know, I don't find that...like, when you're just communicating over Slack and email, there's not a good place for that kind of stuff. And that's why I really like the newsletter.

+ +

JOËL: One thing that's interesting about the difference between in-person and remote is that, in person, a way that you can express personality in the office is you can do some things with your workspace. You might have some items on your desk that are of personal interest. And, you know, you might still do that when you're working remote, but those don't get captured by your webcam unless it's in your background.

+ +

Your background you can get real creative with. But you can also, like, really curate that to, like, show practically nothing. Whereas if you were putting things on your desk in the office, there's kind of no way for your colleagues not to see that. So, you had to be...like, it had to be things that you were willing for everyone to see. But at the same time, sometimes it's nice to be able to say, hey, I'm going to put a touch of, like, things that are meaningful to me in my work life.

+ +

STEPHANIE: Yeah, I really like that. I mean, Joël, your background is always these framed maps on the wall, hanging on the wall, and that is very you, I think. Did you kind of think about how they'll just be your background whenever you're in a meeting, or they just happened to be there?

+ +

JOËL: So, these I had set up pre-pandemic. I like the décor. And then, when I started working from home in 2020, I was trying to figure out, like, where do I want to be to take meetings? And I was like, you know what? The math wall is pretty cool. I think that's going to be my background. I guess now it's almost become, like, a bit of a trademark.

+ +

STEPHANIE: Yeah, I feel that. My trademark...I have a few because I like to move around when I take meetings. So, when I'm at my desk, it's the plants in my office. When I'm in my kitchen, it's either my jars [laughs]. So, I have, like, open shelving and just all of these jars of, you know, some of it is ingredients like nuts, and grains, and stuff like that, and some of it is just empty jars that I use for drinking water. So, I have my jar collection. And then, occasionally, if I'm sitting on the other side of the table [chuckles], all of my pots and pans are hanging in the background from above my stove. So, yeah, I'm the jars, pots, and plants person [laughs] at the company.

+ +

JOËL: You know, we were talking earlier about the idea that it's harder to see your sort of workspace in a remote world. And I just remembered that we do a semi-regular...there's, like, a thread at thoughtbot where people just share pictures of their workspace, and it's opt-in. You don't have to put anything in there. But you get a little bit of, like, oh, the other side of the camera. That's pretty cool.

+ +

STEPHANIE: Yeah, I love seeing those threads. And I think a lot of people in our industry are also gear nerds, so [laughter] they love to see people's, like, fancy monitor and keyboard setups, maybe some cool lighting, oh, like, wire organization [laughs].

+ +

JOËL: Cable management.

+ +

STEPHANIE: Yep. Yep. Those are fun. And I actually think another one that we've lost since going remote is laptop stickers because that was such a great way for people to show some personality and things that they love, like programming stuff, maybe, like, you know, language stickers or organizations like thoughtbot stickers, too, and also, more personal stuff if they want. At a previous company, we were also remote, and someone came up with a really fun game where people anonymously submitted pictures of their laptop stickers. And we got together and tried to guess whose laptop belonged to who just based on the stickers.

+ +

JOËL: Oh, that's fun.

+ +

STEPHANIE: Yeah, that was really fun. I keep forgetting that I wanted to organize something like that for thoughtbot. But now I'm just thinking about it, and I feel the need to decorate my laptop with some stickers after this [laughs].

+ +

JOËL: One thing I do want to highlight, though, is the fact that several years back, when people were talking a lot about the importance of bringing your sort of authentic or whole self to work, one of the really valuable parts of that conversation was giving people the ability to do that, not forcing people to sort of hide parts of themselves, especially if they don't fit into a dominant culture or demographic, in order to be able to even function at work, right? That's a sort of key aspect of, I guess, basic inclusivity. And so, I think that's still a hundred percent true today. We want to build cultures that are inclusive, both in our in-person professional situations and for remote teams.

+ +

STEPHANIE: Yeah, 100%. I think, for me, what I think is a good measure of that is, you know, how comfortable are people disagreeing at the company kind of in public or sharing an alternative perspective? Like, that should be okay and celebrated, even, and considered, you know, with equal weight as kind of what you're saying, the dominant identity or even just opinion. Like, especially in tech, I think people have very strongly held opinions, and when they're disagreed with...I've become a little skeptical of the idea of, like, this is how we do things here or, like, we don't do that.

+ +

And I think that rather than sticking to a, like, stance like that, there's always room to incorporate, like, new approaches, new perspectives, new ways of thinking to a given problem. And that can only happen when people are comfortable with going there, you know, and kind of saying, like, "This is important to me," or, like, "This is how I feel about it." And that, in and of itself, is just equally valid [laughs] as whatever is taking the airtime currently.

+ +

JOËL: That's really interesting because I feel like now you've leaned into almost the idea of psychological safety for a team. And if you're having to sort of repress or hide elements of the way you think, or maybe even sort of core elements of your identity to fit in with a team, that's not psychologically safe, and you can't have those deeper conversations.

+ +

STEPHANIE: Yeah, 100%. I think it's two sides of the same coin, you know, it's like two ways of saying the same thing, that people should be able to conduct themselves in the way they choose to [laughs]. And I can't imagine anyone really disagreeing with a statement like that.

+ +

JOËL: So, I know you choose to not always share everything about your life or sort of...I don't want to say bring your authentic self but, like, bring everything about yourself to the workplace. Do you have a sort of a heuristic for what you decide to share or not share?

+ +

STEPHANIE: Yeah. I don't know if it's necessarily a heuristic so much as it's just what I do [laughs]. But I tend to do better with, like, smaller groups, and, actually, that's why I think pods has been working really well for me personally because I can share personal information just in a more intimate setting, which is helpful for me. And yeah, I tend to, like, find once, like, either Slack channels or Spaces, meetings are starting to get into the, like, 10, 11, 12 people territory is when I hold it back a little bit more, not because of any sort of, like, reason that I don't want to share. It's just, like, that's just not the venue for me.

+ +

But I do love when other people are, like, open, even in, like, larger spaces like that. I appreciate when other people do it just to, you know, signal that it's okay [laughs]. And I enjoy throwing a reaction or responding in a thread about, you know, something that someone shared in a bigger channel. And I think that diversity is actually really helpful because it conveys that, like, there's different ways of existing online in your work environment and that they're all acceptable. What about you? How do you kind of choose where to share things about your personal life?

+ +

JOËL: I think, kind of like you, I don't really have a heuristic. I just sort of go with gut feeling. I think I, sort of by nature, have always been maybe a little bit of having, like, separate professional and personal lives and keeping those a little bit more distinct. And, you know, there's some things that kind of cross over, like, oh, you know, I tried out this fun, new restaurant, or I did a cool activity over the weekend, or something like that.

+ +

I think I've come to see that there can be a lot of value in sharing parts of yourself with other colleagues. And so, from time to time, I'll, like, maybe bring in something a little bit deeper. And, like you said, sometimes that's more easily done in a smaller context. And then yeah, for some things, it's like, okay, I'm going to share photos from a vacation in that, you know, quarterly newsletter. That's kind of fun. But also knowing that there's no pressure that's nice.

+ +

STEPHANIE: Yeah. I think you're really good about finding the right avenues for that. I like, love when you show photos in the travel channel, even though I have that channel muted [laughs]. You'll, like, send me the link to the post in that channel. And yeah, I love that because it's a way for you to kind of, like, find the right place for it, and then also share it with any particular people if you choose to.

+ +

JOËL: I think, also, personal connections can be a way to build deeper relationships, especially in smaller groups. And you can form deeper connections with colleagues over a particular project, or a particular technology, or a tech topic, or, you know, just a passion about mechanical keyboards, or something like that. But if you're people who chat kind of more on the regular for different things, maybe separate from a client project you're on or something like that, and you do find yourself exchanging a little bit more about, oh, you know, what you're doing in your life, or what are the things that are going on for you, that often does tend to build, I think, a deeper connection between colleagues, which can be really nice.

+ +

STEPHANIE: Yeah. And I like that those relationships can also change. Like, there's different seasons in which you're more connected to some people and then less connected. Sometimes a colleague that you have shared interests with becomes someone that you kind of are in touch with more regularly, and then maybe you switch projects, and you aren't so much kind of as up to date. But, I don't know, I always think that there's, like, the right time for that kind of stuff, and it emerges.

+ +

JOËL: I'm going to throw a bit of a buzzword at you, and I'd love to get your reaction. The idea of belonging, the feeling of belonging on a team, is that a good thing, something that we should seek out? And if so, how much of that is responsibility of, like, management or, like, a property of the team or the group to make you sort of feel that belonging? And how much of that is on you having to maybe disclose things about yourself or share a little bit of your personal life to, like, create that sense of belonging?

+ +

STEPHANIE: Whoa. Yeah, that is a good way to frame it. I think there's a balance. There've been some, like, periods of my work life where I'm like, oh, I need more of a detachment from work and other times where I'm like, oh, I feel really disconnected, like, I want to feel like more of a part of this team. But I do think it's a management responsibility. And one thing that I know people to be cautious of is, you know, becoming too close at work. I don't know if your work being treated like a family, like, that kind of language can be a little bit borderline.

+ +

JOËL: Almost manipulative.

+ +

STEPHANIE: Right. Yeah, exactly. I do think there's something to be said about community at work and feeling like that kind of belonging, right? But also, that you can choose how much, like, you want to engage with that community and that being okay. I don't think it necessarily needs to be only through what you share about yourself. Like, you can have that sense of connection just by being a good colleague [chuckles], right? Like, even if the things you talk about are just within the realm of the project you're working on, like, there's still a sense of commitment and, yeah, in that relationship. And I think that is what matters when it comes to belonging.

+ +

In the past, ways that I've seen that work well in regards to kind of how you share information is just, like, I don't know, share how you're doing. Like, you don't have to provide too many details. But it could be like, "Oh, I'm kind of distracted in my personal life right now, and that's why I wasn't able to get this done." People should be understanding of that, even if you don't kind of let them in on the more personal aspects of it.

+ +

JOËL: Right. And you don't have to give any details, right?

+ +

STEPHANIE: Yeah.

+ +

JOËL: You should be in a place where people are comfortable with not knowing and not be like, "Ooh, what's going on with Stephanie's life? "

+ +

STEPHANIE: [laughs] Yeah. But I do also think, like, the knowing that, like, something is going on is, like, also important context, right? Because you don't necessarily want that to impact the commitments you do have at work.

+ +

JOËL: Right. And people tend to be a little bit more understanding if you're having to maybe shift some meetings around, or if you're struggling to focus on a particular day, or something like that.

+ +

STEPHANIE: Yeah. 100%.

+ +

JOËL: Yeah, we should normalize it of just like, "Hey, I'm having a hard day. I don't want to give details, but you know."

+ +

STEPHANIE: Yeah. Yeah. I think a way that that is always kind of weird is how people communicate they're taking a sick day [laughs]. I actually had someone tell me that they really appreciated a time when I just said, "You know, I need to take care of myself today," and didn't really say anything else [laughs] about why. Because they're like, "Oh, like, that helped normalize this idea that, like, that is fine just kind of as is." There's no need to, you know, supply any additional reasoning.

+ +

JOËL: Sometimes I feel like people almost feel the need to like, justify taking sick time. So, you've got to, like, say just how bad things are that now I'm actually taking sick time.

+ +

STEPHANIE: Yeah, which is...that's not the point, right? You know, we have it because we need it [laughs]. So, yeah, I'm glad you mentioned that because I think that's actually a really good example of the ways that people, like, approach kind of bringing themselves to work like that.

+ +

JOËL: Yeah, sometimes it's setting a boundary. An aspect I'm curious to look at is you, and I do a little bit of this with this podcast, right? Every week, we share a little bit of what's new in our world, and it goes out into the public internet. How do you tend to pick those topics and, like, how personal are you willing to get?

+ +

STEPHANIE: Yeah. Oh, that's so hard. It's always hard [laughs], I think. I generally am pretty open. You know, I have talked about plans that I have for moving. I don't know, things about my gardening. I think I've also been a little vulnerable on the show before when I've, like, had a challenge, like, at work. But yeah, it's important, to me, I think, to be, like, true. Like, I think part of what our listeners like about this show is that we show up every week, and it's just a chat between two friends [laughs].

+ +

JOËL: Uh-huh.

+ +

STEPHANIE: It also is kind of weird to know that it's just, like, out there, right? And I don't really know who's listening on the other side. I do know that, like, a lot of my friends listen. And, in some ways, I like to think that I'm talking to them, right? But yeah, sometimes I think about just, like, in a decade [laughs], it will still be out there. And on one hand, I think maybe it's kind of cool because I can listen back and be like, oh, like, that's what was going on for me in 2024.

+ +

And other times I'm like, oh my God, what if I'm one day just, like, deeply embarrassed by things I've talked about on this show [laughs]? But that's a risk, I guess, I'm willing to take because I do think that the sense of connection that we foster with our audience is really meaningful. And it gives me a lot of joy whenever I meet a listener who's like, "Oh, you, you know, talked about this one thing, and I really related to it." And yeah, I guess that's what I do this for. What about you?

+ +

JOËL: Yeah, I think kind of similar to you; tend to talk about things at work, interesting technical challenges, interesting sort of work, or even sometimes client-related challenges. Of course, you know, never calling out any clients by name, you know, talk about some hobbies and things like that. I think where I tend to draw the line a little bit is things that are a little bit more people-oriented in my personal life. So, I tend to not talk about family, and friends, and relationships, and things like that. And, you know, there are some times where there's like, those things intermix a little bit, where I'll, like, have shared, like, "This is what's new in my world." And then, like, off air, I'll follow up with you and say, "So, I didn't tell the whole story on air.

+ +

STEPHANIE: [laughs] Yeah.

+ +

JOËL: Here's what actually happened." Or, you know, "Here's this extra anecdote that I wanted you to know, but I didn't want everyone in the audience to hear."

+ +

STEPHANIE: Yeah. I think the weirdest part for me, too, is I certainly have my, like, parasocial relationships with people that I follow on the internet [laughs], like, people on YouTube, or other podcasts, and stuff like that. But I haven't thought a whole lot about just, like, what that looks like for me as a host of a podcast. I think, kind of the size of the show now it feels right for me, where it's like I run into people who listen at conferences and stuff like that, but it is kind of contained to a work-related thing. So, that feels good because it, I think, for me, helps just give the work stuff a little bit of a deeper meaning, but otherwise isn't spilling over to my regular life.

+ +

JOËL: And it's always fun when, you know, we get a listener email connecting to, you know, one of the random hobbies or something we've talked about and sharing a little bit of their experiences. I think last spring, I talked about getting a pair of bike shorts and, like, trying it out and seeing how that worked. And a listener called in and shared their experience with bike shorts, and, like, that's a lot of fun. It kind of creates that connection. So, I do enjoy that aspect.

+ +

STEPHANIE: Yeah. And just to plug, you can write in to us at hosts@bikeshed.fm, and if you have anything you want to share that was inspired by what you heard us talk about on the show.

+ +

JOËL: We'd love to have you.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+8z-RM4LB + + ]]> + + Joël Quenneville + Stephanie Minn + + + 425: Modeling Associations in Rails + https://bikeshed.thoughtbot.com/425 + 9815eedb-e4cb-4764-8608-8eea7f8b1b0b + Tue, 07 May 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie shares an intriguing discovery about the origins of design patterns in software, tracing them back to architect Christopher Alexander's ideas in architecture. Joël is an official member of the Boston bike share system, and he loves it. He even got a notification on the app this week: "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." #AchievementUnlocked, Joël! + +Joël and Stephanie transition into a broader discussion on data modeling within software systems, particularly how entities like companies, employees, and devices interconnect within a database. They debate the semantics of database relationships and the practical implications of various database design decisions, providing insights into the complexities of backend development. + 29:39 + no + + + Stephanie shares an intriguing discovery about the origins of design patterns in software, tracing them back to architect Christopher Alexander's ideas in architecture. Joël is an official member of the Boston bike share system, and he loves it. He even got a notification on the app this week: "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." #AchievementUnlocked, Joël! +Joël and Stephanie transition into a broader discussion on data modeling within software systems, particularly how entities like companies, employees, and devices interconnect within a database. They debate the semantics of database relationships and the practical implications of various database design decisions, providing insights into the complexities of backend development. +Christopher Alexander and Design Patterns (https://www.designsystems.com/christopher-alexander-the-father-of-pattern-language/) +Rails guide to choosing between belongsto and hasone (https://edgeguides.rubyonrails.org/association_basics.html#choosing-between-belongs-to-and-has-one) +Making impossible states impossible (https://www.youtube.com/watch?v=IcgmSRJHu_8) +Transcript: +We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. +Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. +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, I learned a very interesting tidbit. I don't know if it's historical; I don't know if I would label it that. But, I recently learned about where the idea of design patterns in software came from. Are you familiar with that at all? +JOËL: I read an article about that a while back, and I forget exactly, but there is, like, a design patterns movement, I think, that predates the software world. +STEPHANIE: Yeah, exactly. So, as far as I understand it, there is an architect named Christopher Alexander, and he's kind of the one who proposed this idea of a pattern language. And he developed these ideas from the lens of architecture and building spaces. And he wrote a book called A Pattern Language that compiles, like, all these time-tested solutions to how to create spaces that meet people's needs, essentially. And I just thought that was really neat that software design adopted that philosophy, kind of taking a lot of these interdisciplinary ideas and bringing them into something technical. +But also, what I was really compelled by was that the point of these patterns is to make these spaces comfortable and enjoyable for humans. And I have that same feeling evoked when I'm in a codebase that's really well designed, and I am just, like, totally comfortable in it, and I can kind of understand what's going on and know how to navigate it. That's a very visceral feeling, I think. +JOËL: I love the kind of human-centric approach that you're using and the language that you're using, right? A place that is comfortable for humans. We want that for our homes. It's kind of nice in our codebases, too. +STEPHANIE: Yeah. I have really enjoyed this framing because instead of just saying like, "Oh, it's quote, unquote, "best practice" to follow these design patterns," it kind of gives me more of a reason. It's more of a compelling reason to me to say like, "Following these design patterns makes the codebase, like, easier to navigate, or easier to change, or easier to work with." And that I can get kind of on board with rather than just saying, "This way is, like, the better way, or the superior way, or the way to do things." +JOËL: At the end of the day, design patterns are a means to an end. They're not an end in of itself. And I think that's where it's very easy to get into trouble is where you're just sort of, I don't know, trying to rack up engineering points, I guess, for using a lot of design patterns, and they're not necessarily in service to some broader goal. +STEPHANIE: Yeah, yeah, exactly. I like the way you put that. When you said that, for some reason, I was thinking about catching Pokémon or something like filling your Pokédex [laughs] with all the different design patterns. And it's not just, you know, like you said, to check off those boxes, but for something that is maybe a little more meaningful than that. +JOËL: You're just trying to, like, hit the completionist achievement on the design patterns. +STEPHANIE: Yeah, if someone ever reaches that, you know, gets that achievement trophy, let me know [laughs]. +JOËL: Can I get a badge on GitHub for having PRs that use every single Gang of Four pattern? +STEPHANIE: Anyway, Joël, what's new in your world? +JOËL: So, on the topic of completing things and getting badges for them, I am a part of the Boston bike share...project makes it sound like it's a, I don't know, an exclusive club. It's Boston's bike share system. I have a subscription with them, and I love it. It's so practical. You can go everywhere. You don't have to worry about, like, a bike getting stolen or something because, like, you drop it off at a docking station, and then it's not your responsibility anymore. Yeah, it's very convenient. I love it. +I got a notification on the app this week that said, "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." +STEPHANIE: Whoa, that's actually a pretty cool accomplishment. +JOËL: I didn't even know they tracked that, and it's kind of cool. And the achievement shows me, like, here are all the different stations you've visited. +STEPHANIE: You know what I think would be really fun? Is kind of the equivalent of a Spotify Wrapped, but for your biking in a year kind of around the city. +JOËL: [laughs] +STEPHANIE: That would be really neat, I think, just to be like, oh yeah, like, I took this bike trip here. Like, I docked at this station to go meet up with a friend in this neighborhood. Yeah, I think that would be really fun [laughs]. +JOËL: You definitely see some patterns come up, right? You're like, oh yeah, well, you know, this is my commute into work every day. Or this is that one friend where, you know, every Tuesday night, we go and do this thing. +STEPHANIE: Yeah, it's almost like a travelogue by bike. +JOËL: Yeah. I'll bet there's a lot of really interesting information that could surface from that. It might be a little bit disturbing to find out that a company has that data on you because you can, like, pick up so much. +STEPHANIE: That's -- +JOËL: But it's also kind of fun to look at it. And you mentioned Spotify Wrapped, right? +STEPHANIE: Right. +JOËL: I love Spotify Wrapped. I have so much fun looking at it every year. +STEPHANIE: Yeah. It's always kind of funny, you know, when products kind of track that kind of stuff because it's like, oh, like, it feels like you're really seen [laughs] in terms of what insights it's able to come up with. But yeah, I do think it's cool that you have this little badge. I would be curious to know if there's anyone who's, you know, managed to hit a hundred percent of all the docking stations. They must be a Boston bike messenger or something [laughs]. +JOËL: Now that I know that they track it, maybe I should go for completion. +STEPHANIE: That would be a very cool flex, in my opinion. +JOËL: [laughs] And, you know, of course, they're always expanding the network, which is a good thing. I'll bet it's the kind of thing where you get, like, 99%, and then it's just really hard to, like, keep up. +STEPHANIE: Yeah, nice. +JOËL: But I guess it's very appropriate, right? For a podcast titled The Bike Shed to be enthusiastic about a bike share program. +STEPHANIE: That's true. +So, for today's topic, I wanted to pick your brain a little bit on a data modeling question that I posed to some other developers at thoughtbot, specifically when it comes to associations and associations through other associations [laughs]. So, I'm just going to kind of try to share in words what this data model looks like and kind of see what you think about it. +So, if you had a company that has many employees and then the employee can also have many devices and you wanted to be able to associate that device with the company, so some kind of method like device dot company, how do you think you would go about making that association happen so that convenience method is available to you in the code? +JOËL: As a convenience for not doing device dot employee dot company. +STEPHANIE: Yeah, exactly. +JOËL: I think a classic is, at least the other way, is that it has many through. I forget if you can do a belongs to through or not. You could also write, effectively, a delegation method on the device to effectively do dot employee dot company. +STEPHANIE: Yeah. So, I had that same inkling as you as well, where at first I tried to do a belongs to through, but it turns out that belongs to does not support the through option. And then, I kind of went down the next path of thinking about if I could do a has one, a device has one company through employee, right? But the more I thought about it, the kind of stranger it felt to me in terms of the semantics of saying that a device has a company as opposed to a company having a device. It made more sense in plain English to think about it in terms of a device belonging to a company. +JOËL: That's interesting, right? Because those are ways of describing relationships in sort of ActiveRecord's language. And in sort of a richer situation, you might have all sorts of different adjectives to describe relationships. Instead of just belongs to has many, you have things like an employee owns a device, an employee works for a company, you know because an employee doesn't literally belong to a company in the literal sense. That's kind of messed up. So, I think what ActiveRecord's language is trying to use is less trying to, like, hit maybe, like, the English domain language of how these things relate to, and it's more about where the foreign keys are in the database. +STEPHANIE: Yeah. I like that point where even though, you know, these are the things that are available to us, that doesn't actually necessarily, you know, capture what we want it to mean. And I had gone to see what Rails' recommendation was, not necessarily for the situation I shared. But they have a section for choosing between which model should have the belongs to, as opposed to, like, it has one association on it. And it says, like you mentioned, you know, the distinction is where you place the foreign key, but you should kind of think about the actual meaning of the data. And, you know, we've talked a lot about, I think, domain modeling [chuckles] on the show. +But their kind of documentation says that...the has something relationship says that one of something is yours, that it can, like, point back to you. And in the example I shared, it still felt to me like, you know, really, the device wanted to point to the company that it is owned by. And if we think about it in real-world terms, too, if that device, like, is company property, for example, then that's a way that that does make sense. +But the couple of paths forward that I saw in front of me were to rework that association, maybe add a new column onto the device, and go down that path of codifying it at the database level. Or kind of maybe something as, like, an in-between step is delegating the method to the employee. And that's what I ended up doing because I wasn't quite ready to do that data migration. +JOËL: Adding more columns is interesting because then you can run into sort of data consistency issues. Let's say on the device you have a company ID to see who the device belongs to. Now, there are sort of two different independent paths. You can ask, "Which company does this device belong to?" You can either check the company ID and then look it up in the company table. Or you can join on the employee and join the employee back under company. And those might give you different answers and that can be a problem with data consistency if those two need to stay in sync. +STEPHANIE: Yeah, that is a good point. +JOËL: There could be scenarios where those two are allowed to diverge, right? You can imagine a scenario where maybe a company owns the device, but an employee of a potentially different company is using the device. And so, now it's okay to have sort of two different chains because the path through the employee is about what company is using our devices versus which company actually owns them. And those are, like, two different kinds of relationships. But if you're trying to get the same thing through two different paths of joining, then that can set you up for some data inconsistency issues. +STEPHANIE: Wow. I really liked what you said there because I don't think enough thought goes into the emergent relationships between models after they've been introduced to a codebase. At least in my experience, I've seen a lot of thought go up front into how we might want to model an ActiveRecord, but then less thought into seeing what patterns kind of show up over time as we introduce more functionality to these models, and kind of understand how they should exist in our codebase. Is that something that you find yourself kind of noticing? Like, how do you kind of pick up on the cue that maybe there's some more thought that needs to happen when it comes to existing database tables? +JOËL: I think it's something that definitely is a bit of a red flag, for me, is when there are multiple paths to connect to sort of establish a relationship. So, if I were to draw out some sort of, like, diagram of the models, boxes, and arrows or something like that, and then I could sort of overlay different paths through that diagram to connect two models and realize that those things need to be in sync, I think that's when I started thinking, ooh, that's a potential danger. +STEPHANIE: Yeah, that's a really great point because, you know, the example I shared was actually a kind of contrived one based on what I was seeing in a client codebase, not, you know, I'm not actually working with devices, companies, and employees [laughs]. But it was encoded as, essentially, a device having one company. And I ended up drawing it out because I just couldn't wrap my head around that idea. +And I had, essentially, an arrow from device pointing to company when I could also see that you could go take the path of going through employee [laughs]. And I was just curious if that was intentional or was it just kind of a convenient way to have that direct method available? I don't currently have enough context to determine but would be something I want to pay attention to. Like you said, it does feel like, if not a red flag, at least an orange one. +JOËL: And there's a whole kind of science to some of this called database normalization, where they're sort of, like, they all have rather arcane names. They're the first normal form, the second normal form, the third normal form, you know, it goes on. If you look at the definition, they're all also a little bit arcane, like every element in a relation must depend solely upon the primary key. And you're just like, well, what does that mean? And how do I know if my table is compliant with that? So, I think it's worth, if you're Googling for some of these, find an article that sort of explains these a little bit more in layman's terms, if you will. +But the general idea is that there are sort of stricter and stricter levels of the amount of sort of duplicate sources of truth you can have. In a sense, it's almost like DRY but for databases, and for your database schema in particular. Because when you have multiple sources of truth, like who does this device belong to, and now you get two different answers, or three different answers, now you've got a data corruption issue. Unlike bugs in code where it's, you know, it can be a problem because the site is down, or users have incorrect behavior, but then you can fix it later, and then go to production, and disruption to your clients is the worst that happened, this sort of problem in data is sometimes unrecoverable. Like, it's just, hey, -- +STEPHANIE: Whoa, that sounds scary. +JOËL: Yeah, no, data problems scare me in a way that code problems don't. +STEPHANIE: Whoa. Could you...I think I interrupted you. But where were you going to go about once you have corrupted data? Like, it's unrecoverable. What happens then? +JOËL: Because, like, if I look at the database, do I know who the real owner of this...if I want to fix it, let's say I fix my schema, but now I've got all this data where I've got devices that have two different owners, and I don't know which one is the real one. And maybe the answer is, I just sort of pick one and say, "Oh, the one that was through this association is sort of the canonical one, and we can just sort of ignore the other one." Do I have confidence in that decision? Well, maybe depending on some of the other context maybe, I'm lucky that I can have that. +The doomsday scenario is that it's a little bit of one, a little bit of the other because there were different code paths that would write to one way or another. And there's no real way of knowing. If there's not too many devices, maybe I do an audit. Maybe I have to, like, follow up with all of my customers and say, "Hey, can you tell me which ones are really your devices?" That's not going to scale. Like, real worst case scenario, you almost have to do, like, a bit of a bankruptcy, where you say, "Hey, all the data prior to this date there's a bit of a question mark on it. We're not a hundred percent sure about it." And that does not feel great. So, now you're talking about mitigation strategies. +STEPHANIE: Oof. Wow. Yeah, you did make it sound [laughs] very scary. I think I've kind of been on the periphery of a situation like this before, where it's not just that we couldn't trust the code. It's that we couldn't trust the data in the database either to tell us how things work, you know, for our users and should work from a product perspective. And I was on a previous client project where they had to, yeah, like, hire a bunch of people to go through that data and kind of make those determinations, like you said, to kind of figure out it out for, you know, all of these customers to determine the source of truth there. And it did not sound like an easy feat at all, right? That's so much time and investment that you have to put into that once you get to that point. +JOËL: And there's a little bit of, like, different problems at different layers. You know, at the database layer, generally, you want all of that data to be really in a sort of single source of truth. Sometimes that makes it annoying to query because you've got to do all these joins. And so, there are various denormalization strategies that you can use to make that. Or sometimes it's a risk you're going to take. You're going to say, "Look, this table is not going to be totally normalized. There's going to be some amount of duplication, and we're comfortable with the risk if that comes up." +Sometimes you also build layers of abstractions on top, so you might have your data sort of at rest in database tables fully normalized and separated out, but it's really clunky to query. So, you build out a database view on top of that that returns data in sort of denormalized fashion. But that's okay because you can always get your correct answer by querying the underlying tables. +STEPHANIE: Wow. Okay. I have a lot of thoughts about this because I feel like database normalization, and I guess denormalization now, are skills that I am certainly not an expert at. And so, when it comes to, like, your average developer, how much do you think that people need to be thinking about this? Or what strategies do you have for, you know, a typical Rails dev in terms of how deep they should go [laughs]? +JOËL: So, the classic advice is you probably want to go to, like, third to fourth normal form, usually three. There's also like 3.5 for some reason. That's also, I think, sometimes called BNF. Anyway, sort of levels of how much you normalize. Some of these things are, like, really, really basic things that Rails just builds into its defaults with that convention over configuration, so things like every table should have a primary key. And that primary key should be something that's fixed and unique. +So, don't use something like combination of first name, last name as your primary key because there could be multiple people with the same name. Also, people change their names, and that's not great. But it's great that people can change their names. It's not great to rely on that as a primary key. +There are things like look for repeating columns. If you've got columns in your schema with a number prefix at the end, that's probably a sign that you want to extract a table. So, I don't know, you have a movie, and you want to list the actors for a movie. If your movie table has actor 1, actor 2, actor 3, actor 4, actor 5, you know, like, all the way up to actor 20, and you're just like, "Yeah, no, we fill, like, actor 1 through N, and if there's any space left over, we just put nulls in those columns," that's a pretty big sign that, hey, why don't you instead have a, like, actor's table, and then make a, like, has many association? +So, a lot of the, like, really basic normalization things, I think, are either built into Rails or built into sort of best practices around Rails. I think something that's really useful for developers to get as a sense beyond learning the actual different normal forms is think about it like DRY for your schema. Be wary of sort of multiple sources of truth for your data, and that will get you most of the way there. +When you're designing sort of models and tables, oftentimes, we think of DRY more in terms of code. Do you ever think about that a little bit in terms of your tables as well? +STEPHANIE: Yeah, I would say so. I think a lot of the time rather than references to another table just starting to grow on a certain model, I would usually lean towards introducing a join table there, both because it kind of encapsulates this idea that there is a connection, and it makes the space for that idea to grow if it needs to in the future. +I don't know if I have really been disciplined in thinking about like, oh, you know, there should really...every time I kind of am designing my database tables, thinking about, like, there should only be one source of truth. But I think that's a really good rule of thumb to follow. And in fact, I can actually think of an example right now where we are a little bit tempted to break that rule. And you're making me reconsider [laughter] if there's another way of doing so. +One thing that I have been kind of appreciative of lately is on my current client project; there's just, like, a lot of data. It's a very data-intensive and sensitive application. And so, when we introduce migrations, those PRs get tagged for review by someone over from the DevOps side, just to kind of provide some guidance around, you know, making sure that we're setting up our models to scale well. One of the things that he's been asking me on my couple of code changes I introduced was, like, when I introduced an index, like, it happened to be, like, a composite index with a couple of different columns, and the particular order of those columns mattered. +And he kind of prompted me to, like, share what my use cases for this index were, just to make sure that, like, some thought went into it, right? Like, it's not so much that the way that I had done it was wrong, but just that I had, like, thought about it. And I like that as a way of kind of thinking about things at the abstraction that I need to to do my dev work day to day and then kind of mapping that to, like you were saying, those best practices around keeping things kind of performant at the database level. +JOËL: I think there's a bit of a parallel world that people could really benefit from dipping a toe in, and that's sort of the typed programming world, this idea of making impossible states impossible or making illegal states unrepresentable. That in the sort of now it's not schemas of database tables or schemas of types that you're creating but trying to prevent data coming into a state where someone could plausibly construct an instance of your object or your type that would be nonsensical in the context of your app, kind of trying to lock that down. +And I think a lot of the ways that people in those communities think about...in a sense, it's kind of like database normalization for developers. So, if you're not wanting to, like, dip your toe in more of the sort of database-centric world and, like, read an article from a DBA, it might be worthwhile to look at some of those worlds as well. And I think a great starting point for that is a talk by Richard Feldman called Making Impossible States Impossible. It's for the Elm language. And there are equivalents, I think, in many others as well. +STEPHANIE: That's really cool that you are making that connection. I know we've kind of briefly talked about workshops in the past on the show. But if there were a workshop for, you know, that kind of database normalization for developers, I would be the first to sign up [laughs]. +JOËL: Hint, hint, RailsConf idea. There's something from your original question that I think is interesting to circle back to, and that's the fact that it was awkward to work through in Ruby to do the work that you wanted to do because the tables were laid out in a certain way. And sometimes, there's certain ways that you need the tables to be in order to be sort of safe to represent data, but they're not the optimal way that we would like to interact with them at the Ruby level. +And I think it's okay for not everything in Ruby to be 100% reflective of the structure of the tables underneath. ActiveRecord gives us a great pattern, but everything is kind of one-to-one. And it's okay to layer on some things on top, add some extra methods to build some, like, connections in Ruby that rely on this normalized data underneath but that make life easier for you, or they better just represent or describe the relationships that you have. +STEPHANIE: 100%. I was really compelled by your idea of introducing helpers that use more descriptive adjectives for what that relationship is like. We've talked about how Rails abstracted things from the database level, you know, for our convenience, but that should not stop us from, like, leaning on that further, right? And kind of introducing our own abstractions for those connections that we see in our domain. So, I feel really inspired. I might even kind of reconsider the way I handled the original example and see what I can make of it. +JOËL: And I think your original solution of doing the delegation is a great example of this as well. You want the idea that a device belongs to a company or has an association called company, and you just don't want to go through that long chain, or at least you don't want that to be visible as an implementation detail. So, in this case, you delegate it through a chain of methods in Ruby. +It could also be that you have a much longer chain of tables, and maybe they don't all have associations in Rails and all that. And I think it would be totally fine as well to define a method on an object where, I don't know, a device, I don't know, has many...let's call it technicians, which is everybody who's ever touched this device or, you know, is on a log somewhere for having done maintenance. And maybe that list of technicians is not a thing you can just get through regular Rails associations. Maybe there's a whole, like, custom query underlying that, and that's okay. +STEPHANIE: Yeah, as you were saying that, I was thinking about that's actually kind of, like, active models are the great spot to put those methods and that logic. And I think you've made a really good case for that. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + "software design patterns, Christopher Alexander, architecture influence, human-centric coding, codebase navigation, design pattern application, MVP development, startup workshop series, thoughtbot, Boston bike share system, data modeling, database relationships, process orchestration, AI in software development, coding best practices, software development podcast, The Bike Shed, Joël Quenneville, Stephanie Minn" + + Stephanie shares an intriguing discovery about the origins of design patterns in software, tracing them back to architect Christopher Alexander's ideas in architecture. Joël is an official member of the Boston bike share system, and he loves it. He even got a notification on the app this week: "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." #AchievementUnlocked, Joël!

+ +

Joël and Stephanie transition into a broader discussion on data modeling within software systems, particularly how entities like companies, employees, and devices interconnect within a database. They debate the semantics of database relationships and the practical implications of various database design decisions, providing insights into the complexities of backend development.

+ + + +

Transcript:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

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, I learned a very interesting tidbit. I don't know if it's historical; I don't know if I would label it that. But, I recently learned about where the idea of design patterns in software came from. Are you familiar with that at all?

+ +

JOËL: I read an article about that a while back, and I forget exactly, but there is, like, a design patterns movement, I think, that predates the software world.

+ +

STEPHANIE: Yeah, exactly. So, as far as I understand it, there is an architect named Christopher Alexander, and he's kind of the one who proposed this idea of a pattern language. And he developed these ideas from the lens of architecture and building spaces. And he wrote a book called A Pattern Language that compiles, like, all these time-tested solutions to how to create spaces that meet people's needs, essentially. And I just thought that was really neat that software design adopted that philosophy, kind of taking a lot of these interdisciplinary ideas and bringing them into something technical.

+ +

But also, what I was really compelled by was that the point of these patterns is to make these spaces comfortable and enjoyable for humans. And I have that same feeling evoked when I'm in a codebase that's really well designed, and I am just, like, totally comfortable in it, and I can kind of understand what's going on and know how to navigate it. That's a very visceral feeling, I think.

+ +

JOËL: I love the kind of human-centric approach that you're using and the language that you're using, right? A place that is comfortable for humans. We want that for our homes. It's kind of nice in our codebases, too.

+ +

STEPHANIE: Yeah. I have really enjoyed this framing because instead of just saying like, "Oh, it's quote, unquote, "best practice" to follow these design patterns," it kind of gives me more of a reason. It's more of a compelling reason to me to say like, "Following these design patterns makes the codebase, like, easier to navigate, or easier to change, or easier to work with." And that I can get kind of on board with rather than just saying, "This way is, like, the better way, or the superior way, or the way to do things."

+ +

JOËL: At the end of the day, design patterns are a means to an end. They're not an end in of itself. And I think that's where it's very easy to get into trouble is where you're just sort of, I don't know, trying to rack up engineering points, I guess, for using a lot of design patterns, and they're not necessarily in service to some broader goal.

+ +

STEPHANIE: Yeah, yeah, exactly. I like the way you put that. When you said that, for some reason, I was thinking about catching Pokémon or something like filling your Pokédex [laughs] with all the different design patterns. And it's not just, you know, like you said, to check off those boxes, but for something that is maybe a little more meaningful than that.

+ +

JOËL: You're just trying to, like, hit the completionist achievement on the design patterns.

+ +

STEPHANIE: Yeah, if someone ever reaches that, you know, gets that achievement trophy, let me know [laughs].

+ +

JOËL: Can I get a badge on GitHub for having PRs that use every single Gang of Four pattern?

+ +

STEPHANIE: Anyway, Joël, what's new in your world?

+ +

JOËL: So, on the topic of completing things and getting badges for them, I am a part of the Boston bike share...project makes it sound like it's a, I don't know, an exclusive club. It's Boston's bike share system. I have a subscription with them, and I love it. It's so practical. You can go everywhere. You don't have to worry about, like, a bike getting stolen or something because, like, you drop it off at a docking station, and then it's not your responsibility anymore. Yeah, it's very convenient. I love it.

+ +

I got a notification on the app this week that said, "Congratulations. You have now visited 10% of all docking stations in the Boston metro area."

+ +

STEPHANIE: Whoa, that's actually a pretty cool accomplishment.

+ +

JOËL: I didn't even know they tracked that, and it's kind of cool. And the achievement shows me, like, here are all the different stations you've visited.

+ +

STEPHANIE: You know what I think would be really fun? Is kind of the equivalent of a Spotify Wrapped, but for your biking in a year kind of around the city.

+ +

JOËL: [laughs]

+ +

STEPHANIE: That would be really neat, I think, just to be like, oh yeah, like, I took this bike trip here. Like, I docked at this station to go meet up with a friend in this neighborhood. Yeah, I think that would be really fun [laughs].

+ +

JOËL: You definitely see some patterns come up, right? You're like, oh yeah, well, you know, this is my commute into work every day. Or this is that one friend where, you know, every Tuesday night, we go and do this thing.

+ +

STEPHANIE: Yeah, it's almost like a travelogue by bike.

+ +

JOËL: Yeah. I'll bet there's a lot of really interesting information that could surface from that. It might be a little bit disturbing to find out that a company has that data on you because you can, like, pick up so much.

+ +

STEPHANIE: That's --

+ +

JOËL: But it's also kind of fun to look at it. And you mentioned Spotify Wrapped, right?

+ +

STEPHANIE: Right.

+ +

JOËL: I love Spotify Wrapped. I have so much fun looking at it every year.

+ +

STEPHANIE: Yeah. It's always kind of funny, you know, when products kind of track that kind of stuff because it's like, oh, like, it feels like you're really seen [laughs] in terms of what insights it's able to come up with. But yeah, I do think it's cool that you have this little badge. I would be curious to know if there's anyone who's, you know, managed to hit a hundred percent of all the docking stations. They must be a Boston bike messenger or something [laughs].

+ +

JOËL: Now that I know that they track it, maybe I should go for completion.

+ +

STEPHANIE: That would be a very cool flex, in my opinion.

+ +

JOËL: [laughs] And, you know, of course, they're always expanding the network, which is a good thing. I'll bet it's the kind of thing where you get, like, 99%, and then it's just really hard to, like, keep up.

+ +

STEPHANIE: Yeah, nice.

+ +

JOËL: But I guess it's very appropriate, right? For a podcast titled The Bike Shed to be enthusiastic about a bike share program.

+ +

STEPHANIE: That's true.

+ +

So, for today's topic, I wanted to pick your brain a little bit on a data modeling question that I posed to some other developers at thoughtbot, specifically when it comes to associations and associations through other associations [laughs]. So, I'm just going to kind of try to share in words what this data model looks like and kind of see what you think about it.

+ +

So, if you had a company that has many employees and then the employee can also have many devices and you wanted to be able to associate that device with the company, so some kind of method like device dot company, how do you think you would go about making that association happen so that convenience method is available to you in the code?

+ +

JOËL: As a convenience for not doing device dot employee dot company.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I think a classic is, at least the other way, is that it has many through. I forget if you can do a belongs to through or not. You could also write, effectively, a delegation method on the device to effectively do dot employee dot company.

+ +

STEPHANIE: Yeah. So, I had that same inkling as you as well, where at first I tried to do a belongs to through, but it turns out that belongs to does not support the through option. And then, I kind of went down the next path of thinking about if I could do a has one, a device has one company through employee, right? But the more I thought about it, the kind of stranger it felt to me in terms of the semantics of saying that a device has a company as opposed to a company having a device. It made more sense in plain English to think about it in terms of a device belonging to a company.

+ +

JOËL: That's interesting, right? Because those are ways of describing relationships in sort of ActiveRecord's language. And in sort of a richer situation, you might have all sorts of different adjectives to describe relationships. Instead of just belongs to has many, you have things like an employee owns a device, an employee works for a company, you know because an employee doesn't literally belong to a company in the literal sense. That's kind of messed up. So, I think what ActiveRecord's language is trying to use is less trying to, like, hit maybe, like, the English domain language of how these things relate to, and it's more about where the foreign keys are in the database.

+ +

STEPHANIE: Yeah. I like that point where even though, you know, these are the things that are available to us, that doesn't actually necessarily, you know, capture what we want it to mean. And I had gone to see what Rails' recommendation was, not necessarily for the situation I shared. But they have a section for choosing between which model should have the belongs to, as opposed to, like, it has one association on it. And it says, like you mentioned, you know, the distinction is where you place the foreign key, but you should kind of think about the actual meaning of the data. And, you know, we've talked a lot about, I think, domain modeling [chuckles] on the show.

+ +

But their kind of documentation says that...the has something relationship says that one of something is yours, that it can, like, point back to you. And in the example I shared, it still felt to me like, you know, really, the device wanted to point to the company that it is owned by. And if we think about it in real-world terms, too, if that device, like, is company property, for example, then that's a way that that does make sense.

+ +

But the couple of paths forward that I saw in front of me were to rework that association, maybe add a new column onto the device, and go down that path of codifying it at the database level. Or kind of maybe something as, like, an in-between step is delegating the method to the employee. And that's what I ended up doing because I wasn't quite ready to do that data migration.

+ +

JOËL: Adding more columns is interesting because then you can run into sort of data consistency issues. Let's say on the device you have a company ID to see who the device belongs to. Now, there are sort of two different independent paths. You can ask, "Which company does this device belong to?" You can either check the company ID and then look it up in the company table. Or you can join on the employee and join the employee back under company. And those might give you different answers and that can be a problem with data consistency if those two need to stay in sync.

+ +

STEPHANIE: Yeah, that is a good point.

+ +

JOËL: There could be scenarios where those two are allowed to diverge, right? You can imagine a scenario where maybe a company owns the device, but an employee of a potentially different company is using the device. And so, now it's okay to have sort of two different chains because the path through the employee is about what company is using our devices versus which company actually owns them. And those are, like, two different kinds of relationships. But if you're trying to get the same thing through two different paths of joining, then that can set you up for some data inconsistency issues.

+ +

STEPHANIE: Wow. I really liked what you said there because I don't think enough thought goes into the emergent relationships between models after they've been introduced to a codebase. At least in my experience, I've seen a lot of thought go up front into how we might want to model an ActiveRecord, but then less thought into seeing what patterns kind of show up over time as we introduce more functionality to these models, and kind of understand how they should exist in our codebase. Is that something that you find yourself kind of noticing? Like, how do you kind of pick up on the cue that maybe there's some more thought that needs to happen when it comes to existing database tables?

+ +

JOËL: I think it's something that definitely is a bit of a red flag, for me, is when there are multiple paths to connect to sort of establish a relationship. So, if I were to draw out some sort of, like, diagram of the models, boxes, and arrows or something like that, and then I could sort of overlay different paths through that diagram to connect two models and realize that those things need to be in sync, I think that's when I started thinking, ooh, that's a potential danger.

+ +

STEPHANIE: Yeah, that's a really great point because, you know, the example I shared was actually a kind of contrived one based on what I was seeing in a client codebase, not, you know, I'm not actually working with devices, companies, and employees [laughs]. But it was encoded as, essentially, a device having one company. And I ended up drawing it out because I just couldn't wrap my head around that idea.

+ +

And I had, essentially, an arrow from device pointing to company when I could also see that you could go take the path of going through employee [laughs]. And I was just curious if that was intentional or was it just kind of a convenient way to have that direct method available? I don't currently have enough context to determine but would be something I want to pay attention to. Like you said, it does feel like, if not a red flag, at least an orange one.

+ +

JOËL: And there's a whole kind of science to some of this called database normalization, where they're sort of, like, they all have rather arcane names. They're the first normal form, the second normal form, the third normal form, you know, it goes on. If you look at the definition, they're all also a little bit arcane, like every element in a relation must depend solely upon the primary key. And you're just like, well, what does that mean? And how do I know if my table is compliant with that? So, I think it's worth, if you're Googling for some of these, find an article that sort of explains these a little bit more in layman's terms, if you will.

+ +

But the general idea is that there are sort of stricter and stricter levels of the amount of sort of duplicate sources of truth you can have. In a sense, it's almost like DRY but for databases, and for your database schema in particular. Because when you have multiple sources of truth, like who does this device belong to, and now you get two different answers, or three different answers, now you've got a data corruption issue. Unlike bugs in code where it's, you know, it can be a problem because the site is down, or users have incorrect behavior, but then you can fix it later, and then go to production, and disruption to your clients is the worst that happened, this sort of problem in data is sometimes unrecoverable. Like, it's just, hey, --

+ +

STEPHANIE: Whoa, that sounds scary.

+ +

JOËL: Yeah, no, data problems scare me in a way that code problems don't.

+ +

STEPHANIE: Whoa. Could you...I think I interrupted you. But where were you going to go about once you have corrupted data? Like, it's unrecoverable. What happens then?

+ +

JOËL: Because, like, if I look at the database, do I know who the real owner of this...if I want to fix it, let's say I fix my schema, but now I've got all this data where I've got devices that have two different owners, and I don't know which one is the real one. And maybe the answer is, I just sort of pick one and say, "Oh, the one that was through this association is sort of the canonical one, and we can just sort of ignore the other one." Do I have confidence in that decision? Well, maybe depending on some of the other context maybe, I'm lucky that I can have that.

+ +

The doomsday scenario is that it's a little bit of one, a little bit of the other because there were different code paths that would write to one way or another. And there's no real way of knowing. If there's not too many devices, maybe I do an audit. Maybe I have to, like, follow up with all of my customers and say, "Hey, can you tell me which ones are really your devices?" That's not going to scale. Like, real worst case scenario, you almost have to do, like, a bit of a bankruptcy, where you say, "Hey, all the data prior to this date there's a bit of a question mark on it. We're not a hundred percent sure about it." And that does not feel great. So, now you're talking about mitigation strategies.

+ +

STEPHANIE: Oof. Wow. Yeah, you did make it sound [laughs] very scary. I think I've kind of been on the periphery of a situation like this before, where it's not just that we couldn't trust the code. It's that we couldn't trust the data in the database either to tell us how things work, you know, for our users and should work from a product perspective. And I was on a previous client project where they had to, yeah, like, hire a bunch of people to go through that data and kind of make those determinations, like you said, to kind of figure out it out for, you know, all of these customers to determine the source of truth there. And it did not sound like an easy feat at all, right? That's so much time and investment that you have to put into that once you get to that point.

+ +

JOËL: And there's a little bit of, like, different problems at different layers. You know, at the database layer, generally, you want all of that data to be really in a sort of single source of truth. Sometimes that makes it annoying to query because you've got to do all these joins. And so, there are various denormalization strategies that you can use to make that. Or sometimes it's a risk you're going to take. You're going to say, "Look, this table is not going to be totally normalized. There's going to be some amount of duplication, and we're comfortable with the risk if that comes up."

+ +

Sometimes you also build layers of abstractions on top, so you might have your data sort of at rest in database tables fully normalized and separated out, but it's really clunky to query. So, you build out a database view on top of that that returns data in sort of denormalized fashion. But that's okay because you can always get your correct answer by querying the underlying tables.

+ +

STEPHANIE: Wow. Okay. I have a lot of thoughts about this because I feel like database normalization, and I guess denormalization now, are skills that I am certainly not an expert at. And so, when it comes to, like, your average developer, how much do you think that people need to be thinking about this? Or what strategies do you have for, you know, a typical Rails dev in terms of how deep they should go [laughs]?

+ +

JOËL: So, the classic advice is you probably want to go to, like, third to fourth normal form, usually three. There's also like 3.5 for some reason. That's also, I think, sometimes called BNF. Anyway, sort of levels of how much you normalize. Some of these things are, like, really, really basic things that Rails just builds into its defaults with that convention over configuration, so things like every table should have a primary key. And that primary key should be something that's fixed and unique.

+ +

So, don't use something like combination of first name, last name as your primary key because there could be multiple people with the same name. Also, people change their names, and that's not great. But it's great that people can change their names. It's not great to rely on that as a primary key.

+ +

There are things like look for repeating columns. If you've got columns in your schema with a number prefix at the end, that's probably a sign that you want to extract a table. So, I don't know, you have a movie, and you want to list the actors for a movie. If your movie table has actor 1, actor 2, actor 3, actor 4, actor 5, you know, like, all the way up to actor 20, and you're just like, "Yeah, no, we fill, like, actor 1 through N, and if there's any space left over, we just put nulls in those columns," that's a pretty big sign that, hey, why don't you instead have a, like, actor's table, and then make a, like, has many association?

+ +

So, a lot of the, like, really basic normalization things, I think, are either built into Rails or built into sort of best practices around Rails. I think something that's really useful for developers to get as a sense beyond learning the actual different normal forms is think about it like DRY for your schema. Be wary of sort of multiple sources of truth for your data, and that will get you most of the way there.

+ +

When you're designing sort of models and tables, oftentimes, we think of DRY more in terms of code. Do you ever think about that a little bit in terms of your tables as well?

+ +

STEPHANIE: Yeah, I would say so. I think a lot of the time rather than references to another table just starting to grow on a certain model, I would usually lean towards introducing a join table there, both because it kind of encapsulates this idea that there is a connection, and it makes the space for that idea to grow if it needs to in the future.

+ +

I don't know if I have really been disciplined in thinking about like, oh, you know, there should really...every time I kind of am designing my database tables, thinking about, like, there should only be one source of truth. But I think that's a really good rule of thumb to follow. And in fact, I can actually think of an example right now where we are a little bit tempted to break that rule. And you're making me reconsider [laughter] if there's another way of doing so.

+ +

One thing that I have been kind of appreciative of lately is on my current client project; there's just, like, a lot of data. It's a very data-intensive and sensitive application. And so, when we introduce migrations, those PRs get tagged for review by someone over from the DevOps side, just to kind of provide some guidance around, you know, making sure that we're setting up our models to scale well. One of the things that he's been asking me on my couple of code changes I introduced was, like, when I introduced an index, like, it happened to be, like, a composite index with a couple of different columns, and the particular order of those columns mattered.

+ +

And he kind of prompted me to, like, share what my use cases for this index were, just to make sure that, like, some thought went into it, right? Like, it's not so much that the way that I had done it was wrong, but just that I had, like, thought about it. And I like that as a way of kind of thinking about things at the abstraction that I need to to do my dev work day to day and then kind of mapping that to, like you were saying, those best practices around keeping things kind of performant at the database level.

+ +

JOËL: I think there's a bit of a parallel world that people could really benefit from dipping a toe in, and that's sort of the typed programming world, this idea of making impossible states impossible or making illegal states unrepresentable. That in the sort of now it's not schemas of database tables or schemas of types that you're creating but trying to prevent data coming into a state where someone could plausibly construct an instance of your object or your type that would be nonsensical in the context of your app, kind of trying to lock that down.

+ +

And I think a lot of the ways that people in those communities think about...in a sense, it's kind of like database normalization for developers. So, if you're not wanting to, like, dip your toe in more of the sort of database-centric world and, like, read an article from a DBA, it might be worthwhile to look at some of those worlds as well. And I think a great starting point for that is a talk by Richard Feldman called Making Impossible States Impossible. It's for the Elm language. And there are equivalents, I think, in many others as well.

+ +

STEPHANIE: That's really cool that you are making that connection. I know we've kind of briefly talked about workshops in the past on the show. But if there were a workshop for, you know, that kind of database normalization for developers, I would be the first to sign up [laughs].

+ +

JOËL: Hint, hint, RailsConf idea. There's something from your original question that I think is interesting to circle back to, and that's the fact that it was awkward to work through in Ruby to do the work that you wanted to do because the tables were laid out in a certain way. And sometimes, there's certain ways that you need the tables to be in order to be sort of safe to represent data, but they're not the optimal way that we would like to interact with them at the Ruby level.

+ +

And I think it's okay for not everything in Ruby to be 100% reflective of the structure of the tables underneath. ActiveRecord gives us a great pattern, but everything is kind of one-to-one. And it's okay to layer on some things on top, add some extra methods to build some, like, connections in Ruby that rely on this normalized data underneath but that make life easier for you, or they better just represent or describe the relationships that you have.

+ +

STEPHANIE: 100%. I was really compelled by your idea of introducing helpers that use more descriptive adjectives for what that relationship is like. We've talked about how Rails abstracted things from the database level, you know, for our convenience, but that should not stop us from, like, leaning on that further, right? And kind of introducing our own abstractions for those connections that we see in our domain. So, I feel really inspired. I might even kind of reconsider the way I handled the original example and see what I can make of it.

+ +

JOËL: And I think your original solution of doing the delegation is a great example of this as well. You want the idea that a device belongs to a company or has an association called company, and you just don't want to go through that long chain, or at least you don't want that to be visible as an implementation detail. So, in this case, you delegate it through a chain of methods in Ruby.

+ +

It could also be that you have a much longer chain of tables, and maybe they don't all have associations in Rails and all that. And I think it would be totally fine as well to define a method on an object where, I don't know, a device, I don't know, has many...let's call it technicians, which is everybody who's ever touched this device or, you know, is on a log somewhere for having done maintenance. And maybe that list of technicians is not a thing you can just get through regular Rails associations. Maybe there's a whole, like, custom query underlying that, and that's okay.

+ +

STEPHANIE: Yeah, as you were saying that, I was thinking about that's actually kind of, like, active models are the great spot to put those methods and that logic. And I think you've made a really good case for that.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie shares an intriguing discovery about the origins of design patterns in software, tracing them back to architect Christopher Alexander's ideas in architecture. Joël is an official member of the Boston bike share system, and he loves it. He even got a notification on the app this week: "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." #AchievementUnlocked, Joël!

+ +

Joël and Stephanie transition into a broader discussion on data modeling within software systems, particularly how entities like companies, employees, and devices interconnect within a database. They debate the semantics of database relationships and the practical implications of various database design decisions, providing insights into the complexities of backend development.

+ + + +

Transcript:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

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, I learned a very interesting tidbit. I don't know if it's historical; I don't know if I would label it that. But, I recently learned about where the idea of design patterns in software came from. Are you familiar with that at all?

+ +

JOËL: I read an article about that a while back, and I forget exactly, but there is, like, a design patterns movement, I think, that predates the software world.

+ +

STEPHANIE: Yeah, exactly. So, as far as I understand it, there is an architect named Christopher Alexander, and he's kind of the one who proposed this idea of a pattern language. And he developed these ideas from the lens of architecture and building spaces. And he wrote a book called A Pattern Language that compiles, like, all these time-tested solutions to how to create spaces that meet people's needs, essentially. And I just thought that was really neat that software design adopted that philosophy, kind of taking a lot of these interdisciplinary ideas and bringing them into something technical.

+ +

But also, what I was really compelled by was that the point of these patterns is to make these spaces comfortable and enjoyable for humans. And I have that same feeling evoked when I'm in a codebase that's really well designed, and I am just, like, totally comfortable in it, and I can kind of understand what's going on and know how to navigate it. That's a very visceral feeling, I think.

+ +

JOËL: I love the kind of human-centric approach that you're using and the language that you're using, right? A place that is comfortable for humans. We want that for our homes. It's kind of nice in our codebases, too.

+ +

STEPHANIE: Yeah. I have really enjoyed this framing because instead of just saying like, "Oh, it's quote, unquote, "best practice" to follow these design patterns," it kind of gives me more of a reason. It's more of a compelling reason to me to say like, "Following these design patterns makes the codebase, like, easier to navigate, or easier to change, or easier to work with." And that I can get kind of on board with rather than just saying, "This way is, like, the better way, or the superior way, or the way to do things."

+ +

JOËL: At the end of the day, design patterns are a means to an end. They're not an end in of itself. And I think that's where it's very easy to get into trouble is where you're just sort of, I don't know, trying to rack up engineering points, I guess, for using a lot of design patterns, and they're not necessarily in service to some broader goal.

+ +

STEPHANIE: Yeah, yeah, exactly. I like the way you put that. When you said that, for some reason, I was thinking about catching Pokémon or something like filling your Pokédex [laughs] with all the different design patterns. And it's not just, you know, like you said, to check off those boxes, but for something that is maybe a little more meaningful than that.

+ +

JOËL: You're just trying to, like, hit the completionist achievement on the design patterns.

+ +

STEPHANIE: Yeah, if someone ever reaches that, you know, gets that achievement trophy, let me know [laughs].

+ +

JOËL: Can I get a badge on GitHub for having PRs that use every single Gang of Four pattern?

+ +

STEPHANIE: Anyway, Joël, what's new in your world?

+ +

JOËL: So, on the topic of completing things and getting badges for them, I am a part of the Boston bike share...project makes it sound like it's a, I don't know, an exclusive club. It's Boston's bike share system. I have a subscription with them, and I love it. It's so practical. You can go everywhere. You don't have to worry about, like, a bike getting stolen or something because, like, you drop it off at a docking station, and then it's not your responsibility anymore. Yeah, it's very convenient. I love it.

+ +

I got a notification on the app this week that said, "Congratulations. You have now visited 10% of all docking stations in the Boston metro area."

+ +

STEPHANIE: Whoa, that's actually a pretty cool accomplishment.

+ +

JOËL: I didn't even know they tracked that, and it's kind of cool. And the achievement shows me, like, here are all the different stations you've visited.

+ +

STEPHANIE: You know what I think would be really fun? Is kind of the equivalent of a Spotify Wrapped, but for your biking in a year kind of around the city.

+ +

JOËL: [laughs]

+ +

STEPHANIE: That would be really neat, I think, just to be like, oh yeah, like, I took this bike trip here. Like, I docked at this station to go meet up with a friend in this neighborhood. Yeah, I think that would be really fun [laughs].

+ +

JOËL: You definitely see some patterns come up, right? You're like, oh yeah, well, you know, this is my commute into work every day. Or this is that one friend where, you know, every Tuesday night, we go and do this thing.

+ +

STEPHANIE: Yeah, it's almost like a travelogue by bike.

+ +

JOËL: Yeah. I'll bet there's a lot of really interesting information that could surface from that. It might be a little bit disturbing to find out that a company has that data on you because you can, like, pick up so much.

+ +

STEPHANIE: That's --

+ +

JOËL: But it's also kind of fun to look at it. And you mentioned Spotify Wrapped, right?

+ +

STEPHANIE: Right.

+ +

JOËL: I love Spotify Wrapped. I have so much fun looking at it every year.

+ +

STEPHANIE: Yeah. It's always kind of funny, you know, when products kind of track that kind of stuff because it's like, oh, like, it feels like you're really seen [laughs] in terms of what insights it's able to come up with. But yeah, I do think it's cool that you have this little badge. I would be curious to know if there's anyone who's, you know, managed to hit a hundred percent of all the docking stations. They must be a Boston bike messenger or something [laughs].

+ +

JOËL: Now that I know that they track it, maybe I should go for completion.

+ +

STEPHANIE: That would be a very cool flex, in my opinion.

+ +

JOËL: [laughs] And, you know, of course, they're always expanding the network, which is a good thing. I'll bet it's the kind of thing where you get, like, 99%, and then it's just really hard to, like, keep up.

+ +

STEPHANIE: Yeah, nice.

+ +

JOËL: But I guess it's very appropriate, right? For a podcast titled The Bike Shed to be enthusiastic about a bike share program.

+ +

STEPHANIE: That's true.

+ +

So, for today's topic, I wanted to pick your brain a little bit on a data modeling question that I posed to some other developers at thoughtbot, specifically when it comes to associations and associations through other associations [laughs]. So, I'm just going to kind of try to share in words what this data model looks like and kind of see what you think about it.

+ +

So, if you had a company that has many employees and then the employee can also have many devices and you wanted to be able to associate that device with the company, so some kind of method like device dot company, how do you think you would go about making that association happen so that convenience method is available to you in the code?

+ +

JOËL: As a convenience for not doing device dot employee dot company.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I think a classic is, at least the other way, is that it has many through. I forget if you can do a belongs to through or not. You could also write, effectively, a delegation method on the device to effectively do dot employee dot company.

+ +

STEPHANIE: Yeah. So, I had that same inkling as you as well, where at first I tried to do a belongs to through, but it turns out that belongs to does not support the through option. And then, I kind of went down the next path of thinking about if I could do a has one, a device has one company through employee, right? But the more I thought about it, the kind of stranger it felt to me in terms of the semantics of saying that a device has a company as opposed to a company having a device. It made more sense in plain English to think about it in terms of a device belonging to a company.

+ +

JOËL: That's interesting, right? Because those are ways of describing relationships in sort of ActiveRecord's language. And in sort of a richer situation, you might have all sorts of different adjectives to describe relationships. Instead of just belongs to has many, you have things like an employee owns a device, an employee works for a company, you know because an employee doesn't literally belong to a company in the literal sense. That's kind of messed up. So, I think what ActiveRecord's language is trying to use is less trying to, like, hit maybe, like, the English domain language of how these things relate to, and it's more about where the foreign keys are in the database.

+ +

STEPHANIE: Yeah. I like that point where even though, you know, these are the things that are available to us, that doesn't actually necessarily, you know, capture what we want it to mean. And I had gone to see what Rails' recommendation was, not necessarily for the situation I shared. But they have a section for choosing between which model should have the belongs to, as opposed to, like, it has one association on it. And it says, like you mentioned, you know, the distinction is where you place the foreign key, but you should kind of think about the actual meaning of the data. And, you know, we've talked a lot about, I think, domain modeling [chuckles] on the show.

+ +

But their kind of documentation says that...the has something relationship says that one of something is yours, that it can, like, point back to you. And in the example I shared, it still felt to me like, you know, really, the device wanted to point to the company that it is owned by. And if we think about it in real-world terms, too, if that device, like, is company property, for example, then that's a way that that does make sense.

+ +

But the couple of paths forward that I saw in front of me were to rework that association, maybe add a new column onto the device, and go down that path of codifying it at the database level. Or kind of maybe something as, like, an in-between step is delegating the method to the employee. And that's what I ended up doing because I wasn't quite ready to do that data migration.

+ +

JOËL: Adding more columns is interesting because then you can run into sort of data consistency issues. Let's say on the device you have a company ID to see who the device belongs to. Now, there are sort of two different independent paths. You can ask, "Which company does this device belong to?" You can either check the company ID and then look it up in the company table. Or you can join on the employee and join the employee back under company. And those might give you different answers and that can be a problem with data consistency if those two need to stay in sync.

+ +

STEPHANIE: Yeah, that is a good point.

+ +

JOËL: There could be scenarios where those two are allowed to diverge, right? You can imagine a scenario where maybe a company owns the device, but an employee of a potentially different company is using the device. And so, now it's okay to have sort of two different chains because the path through the employee is about what company is using our devices versus which company actually owns them. And those are, like, two different kinds of relationships. But if you're trying to get the same thing through two different paths of joining, then that can set you up for some data inconsistency issues.

+ +

STEPHANIE: Wow. I really liked what you said there because I don't think enough thought goes into the emergent relationships between models after they've been introduced to a codebase. At least in my experience, I've seen a lot of thought go up front into how we might want to model an ActiveRecord, but then less thought into seeing what patterns kind of show up over time as we introduce more functionality to these models, and kind of understand how they should exist in our codebase. Is that something that you find yourself kind of noticing? Like, how do you kind of pick up on the cue that maybe there's some more thought that needs to happen when it comes to existing database tables?

+ +

JOËL: I think it's something that definitely is a bit of a red flag, for me, is when there are multiple paths to connect to sort of establish a relationship. So, if I were to draw out some sort of, like, diagram of the models, boxes, and arrows or something like that, and then I could sort of overlay different paths through that diagram to connect two models and realize that those things need to be in sync, I think that's when I started thinking, ooh, that's a potential danger.

+ +

STEPHANIE: Yeah, that's a really great point because, you know, the example I shared was actually a kind of contrived one based on what I was seeing in a client codebase, not, you know, I'm not actually working with devices, companies, and employees [laughs]. But it was encoded as, essentially, a device having one company. And I ended up drawing it out because I just couldn't wrap my head around that idea.

+ +

And I had, essentially, an arrow from device pointing to company when I could also see that you could go take the path of going through employee [laughs]. And I was just curious if that was intentional or was it just kind of a convenient way to have that direct method available? I don't currently have enough context to determine but would be something I want to pay attention to. Like you said, it does feel like, if not a red flag, at least an orange one.

+ +

JOËL: And there's a whole kind of science to some of this called database normalization, where they're sort of, like, they all have rather arcane names. They're the first normal form, the second normal form, the third normal form, you know, it goes on. If you look at the definition, they're all also a little bit arcane, like every element in a relation must depend solely upon the primary key. And you're just like, well, what does that mean? And how do I know if my table is compliant with that? So, I think it's worth, if you're Googling for some of these, find an article that sort of explains these a little bit more in layman's terms, if you will.

+ +

But the general idea is that there are sort of stricter and stricter levels of the amount of sort of duplicate sources of truth you can have. In a sense, it's almost like DRY but for databases, and for your database schema in particular. Because when you have multiple sources of truth, like who does this device belong to, and now you get two different answers, or three different answers, now you've got a data corruption issue. Unlike bugs in code where it's, you know, it can be a problem because the site is down, or users have incorrect behavior, but then you can fix it later, and then go to production, and disruption to your clients is the worst that happened, this sort of problem in data is sometimes unrecoverable. Like, it's just, hey, --

+ +

STEPHANIE: Whoa, that sounds scary.

+ +

JOËL: Yeah, no, data problems scare me in a way that code problems don't.

+ +

STEPHANIE: Whoa. Could you...I think I interrupted you. But where were you going to go about once you have corrupted data? Like, it's unrecoverable. What happens then?

+ +

JOËL: Because, like, if I look at the database, do I know who the real owner of this...if I want to fix it, let's say I fix my schema, but now I've got all this data where I've got devices that have two different owners, and I don't know which one is the real one. And maybe the answer is, I just sort of pick one and say, "Oh, the one that was through this association is sort of the canonical one, and we can just sort of ignore the other one." Do I have confidence in that decision? Well, maybe depending on some of the other context maybe, I'm lucky that I can have that.

+ +

The doomsday scenario is that it's a little bit of one, a little bit of the other because there were different code paths that would write to one way or another. And there's no real way of knowing. If there's not too many devices, maybe I do an audit. Maybe I have to, like, follow up with all of my customers and say, "Hey, can you tell me which ones are really your devices?" That's not going to scale. Like, real worst case scenario, you almost have to do, like, a bit of a bankruptcy, where you say, "Hey, all the data prior to this date there's a bit of a question mark on it. We're not a hundred percent sure about it." And that does not feel great. So, now you're talking about mitigation strategies.

+ +

STEPHANIE: Oof. Wow. Yeah, you did make it sound [laughs] very scary. I think I've kind of been on the periphery of a situation like this before, where it's not just that we couldn't trust the code. It's that we couldn't trust the data in the database either to tell us how things work, you know, for our users and should work from a product perspective. And I was on a previous client project where they had to, yeah, like, hire a bunch of people to go through that data and kind of make those determinations, like you said, to kind of figure out it out for, you know, all of these customers to determine the source of truth there. And it did not sound like an easy feat at all, right? That's so much time and investment that you have to put into that once you get to that point.

+ +

JOËL: And there's a little bit of, like, different problems at different layers. You know, at the database layer, generally, you want all of that data to be really in a sort of single source of truth. Sometimes that makes it annoying to query because you've got to do all these joins. And so, there are various denormalization strategies that you can use to make that. Or sometimes it's a risk you're going to take. You're going to say, "Look, this table is not going to be totally normalized. There's going to be some amount of duplication, and we're comfortable with the risk if that comes up."

+ +

Sometimes you also build layers of abstractions on top, so you might have your data sort of at rest in database tables fully normalized and separated out, but it's really clunky to query. So, you build out a database view on top of that that returns data in sort of denormalized fashion. But that's okay because you can always get your correct answer by querying the underlying tables.

+ +

STEPHANIE: Wow. Okay. I have a lot of thoughts about this because I feel like database normalization, and I guess denormalization now, are skills that I am certainly not an expert at. And so, when it comes to, like, your average developer, how much do you think that people need to be thinking about this? Or what strategies do you have for, you know, a typical Rails dev in terms of how deep they should go [laughs]?

+ +

JOËL: So, the classic advice is you probably want to go to, like, third to fourth normal form, usually three. There's also like 3.5 for some reason. That's also, I think, sometimes called BNF. Anyway, sort of levels of how much you normalize. Some of these things are, like, really, really basic things that Rails just builds into its defaults with that convention over configuration, so things like every table should have a primary key. And that primary key should be something that's fixed and unique.

+ +

So, don't use something like combination of first name, last name as your primary key because there could be multiple people with the same name. Also, people change their names, and that's not great. But it's great that people can change their names. It's not great to rely on that as a primary key.

+ +

There are things like look for repeating columns. If you've got columns in your schema with a number prefix at the end, that's probably a sign that you want to extract a table. So, I don't know, you have a movie, and you want to list the actors for a movie. If your movie table has actor 1, actor 2, actor 3, actor 4, actor 5, you know, like, all the way up to actor 20, and you're just like, "Yeah, no, we fill, like, actor 1 through N, and if there's any space left over, we just put nulls in those columns," that's a pretty big sign that, hey, why don't you instead have a, like, actor's table, and then make a, like, has many association?

+ +

So, a lot of the, like, really basic normalization things, I think, are either built into Rails or built into sort of best practices around Rails. I think something that's really useful for developers to get as a sense beyond learning the actual different normal forms is think about it like DRY for your schema. Be wary of sort of multiple sources of truth for your data, and that will get you most of the way there.

+ +

When you're designing sort of models and tables, oftentimes, we think of DRY more in terms of code. Do you ever think about that a little bit in terms of your tables as well?

+ +

STEPHANIE: Yeah, I would say so. I think a lot of the time rather than references to another table just starting to grow on a certain model, I would usually lean towards introducing a join table there, both because it kind of encapsulates this idea that there is a connection, and it makes the space for that idea to grow if it needs to in the future.

+ +

I don't know if I have really been disciplined in thinking about like, oh, you know, there should really...every time I kind of am designing my database tables, thinking about, like, there should only be one source of truth. But I think that's a really good rule of thumb to follow. And in fact, I can actually think of an example right now where we are a little bit tempted to break that rule. And you're making me reconsider [laughter] if there's another way of doing so.

+ +

One thing that I have been kind of appreciative of lately is on my current client project; there's just, like, a lot of data. It's a very data-intensive and sensitive application. And so, when we introduce migrations, those PRs get tagged for review by someone over from the DevOps side, just to kind of provide some guidance around, you know, making sure that we're setting up our models to scale well. One of the things that he's been asking me on my couple of code changes I introduced was, like, when I introduced an index, like, it happened to be, like, a composite index with a couple of different columns, and the particular order of those columns mattered.

+ +

And he kind of prompted me to, like, share what my use cases for this index were, just to make sure that, like, some thought went into it, right? Like, it's not so much that the way that I had done it was wrong, but just that I had, like, thought about it. And I like that as a way of kind of thinking about things at the abstraction that I need to to do my dev work day to day and then kind of mapping that to, like you were saying, those best practices around keeping things kind of performant at the database level.

+ +

JOËL: I think there's a bit of a parallel world that people could really benefit from dipping a toe in, and that's sort of the typed programming world, this idea of making impossible states impossible or making illegal states unrepresentable. That in the sort of now it's not schemas of database tables or schemas of types that you're creating but trying to prevent data coming into a state where someone could plausibly construct an instance of your object or your type that would be nonsensical in the context of your app, kind of trying to lock that down.

+ +

And I think a lot of the ways that people in those communities think about...in a sense, it's kind of like database normalization for developers. So, if you're not wanting to, like, dip your toe in more of the sort of database-centric world and, like, read an article from a DBA, it might be worthwhile to look at some of those worlds as well. And I think a great starting point for that is a talk by Richard Feldman called Making Impossible States Impossible. It's for the Elm language. And there are equivalents, I think, in many others as well.

+ +

STEPHANIE: That's really cool that you are making that connection. I know we've kind of briefly talked about workshops in the past on the show. But if there were a workshop for, you know, that kind of database normalization for developers, I would be the first to sign up [laughs].

+ +

JOËL: Hint, hint, RailsConf idea. There's something from your original question that I think is interesting to circle back to, and that's the fact that it was awkward to work through in Ruby to do the work that you wanted to do because the tables were laid out in a certain way. And sometimes, there's certain ways that you need the tables to be in order to be sort of safe to represent data, but they're not the optimal way that we would like to interact with them at the Ruby level.

+ +

And I think it's okay for not everything in Ruby to be 100% reflective of the structure of the tables underneath. ActiveRecord gives us a great pattern, but everything is kind of one-to-one. And it's okay to layer on some things on top, add some extra methods to build some, like, connections in Ruby that rely on this normalized data underneath but that make life easier for you, or they better just represent or describe the relationships that you have.

+ +

STEPHANIE: 100%. I was really compelled by your idea of introducing helpers that use more descriptive adjectives for what that relationship is like. We've talked about how Rails abstracted things from the database level, you know, for our convenience, but that should not stop us from, like, leaning on that further, right? And kind of introducing our own abstractions for those connections that we see in our domain. So, I feel really inspired. I might even kind of reconsider the way I handled the original example and see what I can make of it.

+ +

JOËL: And I think your original solution of doing the delegation is a great example of this as well. You want the idea that a device belongs to a company or has an association called company, and you just don't want to go through that long chain, or at least you don't want that to be visible as an implementation detail. So, in this case, you delegate it through a chain of methods in Ruby.

+ +

It could also be that you have a much longer chain of tables, and maybe they don't all have associations in Rails and all that. And I think it would be totally fine as well to define a method on an object where, I don't know, a device, I don't know, has many...let's call it technicians, which is everybody who's ever touched this device or, you know, is on a log somewhere for having done maintenance. And maybe that list of technicians is not a thing you can just get through regular Rails associations. Maybe there's a whole, like, custom query underlying that, and that's okay.

+ +

STEPHANIE: Yeah, as you were saying that, I was thinking about that's actually kind of, like, active models are the great spot to put those methods and that logic. And I think you've made a really good case for that.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+6xQ9j99y + + ]]> + + Joël Quenneville + Stephanie Minn + + + 424: The Spectrum of Automated Processes for Your Dev Team + https://bikeshed.thoughtbot.com/424 + 63b768a2-36e7-46ac-b837-a7bb8dbb5532 + Tue, 30 Apr 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël shares his experience with the dry-rb suite of gems, focusing on how he's been using contracts to validate input data. Stephanie relates to Joël's insights with her preparation for RailsConf, discussing her methods for presenting code in slides and weighing the aesthetics and functionality of different tools like VS Code and Carbon.sh. She also encounters a CI test failure that prompts her to consider the implications of enforcing specific coding standards through CI processes. + +The conversation turns into a discussion on managing coding standards and tools effectively, ensuring that automated systems help rather than hinder development. Joël and Stephanie ponder the balance between enforcing strict coding standards through CI and allowing developers the flexibility to bypass specific rules when necessary, ensuring tools provide valuable feedback without becoming obstructions. + 36:47 + no + + Joël shares his experience with the dry-rb suite of gems, focusing on how he's been using contracts to validate input data. Stephanie relates to Joël's insights with her preparation for RailsConf, discussing her methods for presenting code in slides and weighing the aesthetics and functionality of different tools like VS Code and Carbon.sh. She also encounters a CI test failure that prompts her to consider the implications of enforcing specific coding standards through CI processes. +The conversation turns into a discussion on managing coding standards and tools effectively, ensuring that automated systems help rather than hinder development. Joël and Stephanie ponder the balance between enforcing strict coding standards through CI and allowing developers the flexibility to bypass specific rules when necessary, ensuring tools provide valuable feedback without becoming obstructions. +dry-rb (https://dry-rb.org/) +A broader take on parsing (https://thoughtbot.com/blog/a-broader-take-on-parsing) +Parse; don’t validate (https://thoughtbot.com/blog/a-broader-take-on-parsing) +Debugging at the boundaries (https://thoughtbot.com/blog/debugging-at-the-boundaries) +Specialized vocabulary (https://bikeshed.thoughtbot.com/356) +Carbon (https://carbon.now.sh/) +RailsConf 2024 (https://railsconf.org/) +Moving errors to the left (https://bikeshed.thoughtbot.com/295) +Contracts (https://www.hillelwayne.com/post/contracts/) +Linters shouldn’t be optional (https://jfmengels.net/disable-comments/) +Linter rules to avoid focused tests (https://thoughtbot.com/blog/avoid-merging-rspec-focused-tests) +Thoughtbot Rails guides (https://github.com/thoughtbot/guides/tree/main/rails) +Danger (https://github.com/danger/danger) +Transcript: +AD: +We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. +Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. +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: I've been working on a project that uses the dry-rb suite of gems. And one of the things we're doing there is we're validating inputs using this concept of a contract. So, you sort of describe the shape and requirements of this, like hash of attributes that you get, and it will then tell you whether it's valid or not, along with error messages. We then want to use those to eventually build some other sort of value object type things that we use in the app. And because there's, like, failure points at multiple places that you have to track, it gets a little bit clunky. +And I got to thinking a little bit about, like, forget about the internal machinery. What is it that I would actually like to happen here? And really, what I want is to say, I've got this, like, bunch of attributes, which may or may not be correct. I want to pass them into a method, and then either get back a value object that I was hoping to construct or some kind of error. +STEPHANIE: That sounds reasonable to me. +JOËL: And then, thinking about it just a little bit longer, I was like, wait a minute, this idea of, like, unstructured input goes into a method, you get back something more structured or an error, that's kind of the broad definition of parsing. I think what I'm looking for is a parser object. And this really fits well with a style of processing popularized in the functional programming community called parse, don't validate the idea that you use a parser like this to sort of transform data from more loose to more strict values, values where you can have more assumptions. +And so, I create an object, and I can take a contract. I can take a class and say, "Attempt to take the following attributes. If they're valid according to the construct, create this classroom." And it, you know, does a bunch of error handling and some...under the hood, dry-rb does all this monad stuff. So, I handled that all inside of the object, but it's actually really nice. +STEPHANIE: Cool. Yeah, I had a feeling that was where you were going to go. A while back, we had talked about really impactful articles that we had read over the course of the year, and you had shared one called Parse, Don't Validate. And that heuristic has actually been stuck in my head a little bit. And that was really cool that you found an opportunity to use it in, you know, previously trying to make something work that, like, you weren't really sure kind of how you wanted to implement that. +JOËL: I think I had a bit of a light bulb moment as I was trying to figure this out because, in my mind, there are sort of two broad approaches. There's the parse, don't validate where you have some inputs, and then you transform them into something stricter. Or there's more of that validation approach where you have inputs, you verify that they're correct, and then you pass them on to someone else. And you just say, "Trust me, I verified they're in the right shape." Dry-rb sort of contracts feel like they fit more under that validation approach rather than the parse, don't validate. +Where I think the kind of the light bulb turned on for me is the idea that if you pair a validation step and an object construction step, you've effectively approximated the idea of parse, don't validate. So, if I create a parser object that says, in sort of one step, I'm going to validate some inputs and then immediately use them if they're valid to construct an object, then I've kind of done a parse don't validate, even though the individual building blocks don't follow that pattern. +STEPHANIE: More like a parse and validate, if you will [laughs]. I have a question for you. Like, do you own those inputs kind of in your domain? +JOËL: In this particular case, sort of. They're coming from a form, so yes. But it's user input, so never trust that. +STEPHANIE: Gotcha. +JOËL: I think you can take this idea and go a little bit broader as well. It doesn't have to be, like, the dry-rb-related stuff. You could do, for example, a JSON schema, right? You're dealing with the input from a third-party API, and you say, "Okay, well, I'm going to have a sort of validation JSON schema." It will just tell you, "Is this data valid or not?" and give you some errors. +But what if you paired that with construction and you could create a little parser object, if you wanted to, that says, "Hey, I've got a payload coming in from a third-party API, validate it against this JSON schema, and attempt to construct this shopping cart object, and give me an error otherwise." And now you've sort of created a nice, little parse, don't validate pipeline which I find a really nice way to deal with data like that. +STEPHANIE: From a user perspective, I'm curious: Does this also improve the user experience? I'm kind of wondering about that. It seems like it could. But have you explored that? +JOËL: This is more about the developer experience. +STEPHANIE: Got it. +JOËL: The user experience, I think, would be either identical or, you know, you can play around with things to display better errors. But this is more about the ergonomics on the development side of things. It was a little bit clunky to sort of assemble all the parts together. And sometimes we didn't immediately do both steps together at the same time. So, you might sort of have parameters that we're like, oh, these are totally good, we promise. And we pass them on to someone else, who passes them on to someone else. And then, they might try to do something with them and hope that they've got the data in the right shape. +And so, saying, let's co-locate these two things. Let's say the validation of the inputs and then the creation of some richer object happen immediately one after another. We're always going to bundle them together. And then, in this particular case, because we're using dry-rb, there's all this monad stuff that has to happen. That was a little bit clunky. We've sort of hidden that in one object, and then nobody else ever has to deal with that. +So, it's easier for developers in terms of just, if you want to turn inputs into objects, now you're just passing them into one object, into one, like, parser, and it works. But it's a nicer developer experience, but also there's a little bit more safety in that because now you're sort of always working with these richer objects that have been validated. +STEPHANIE: Yeah, that makes sense. It sounds very cohesive because you've determined that these are two things that should always happen together. The problems arise when they start to actually get separated, and you don't have what you need in terms of using your interfaces. And that's very nice that you were able to bundle that in an abstraction that makes sense. +JOËL: A really interesting thing I think about abstractions is sometimes thinking of them as the combination of multiple other things. So, you could say that the combination of one thing and another thing, and all of a sudden, you have a new sort of combo thing that you have created. And, in this case, I think the combination of input validation and construction, and, you know, to a certain extent, error handling, so maybe it's a combination of three things gives you a thing you can call a parser. And knowing that that combination is a thing you can put a name on, I think, is really powerful, or at least it felt really powerful to me when that light bulb turned on. +STEPHANIE: Yeah, it's kind of like the whole is greater than the sum of its parts. +JOËL: Yeah. +STEPHANIE: Cool. +JOËL: And you and I did an episode on Specialized Vocabulary a while back. And that power of naming, saying that, oh, I don't just have a bunch of little atomic steps that do things. But the fact that the combination of three or four of them is a thing in and of itself that has a name that we can talk about has properties that we're familiar with, all of a sudden, that is a really powerful way to think about a system. +STEPHANIE: Absolutely. That's very exciting. +JOËL: So, Stephanie, what's new in your world? +STEPHANIE: So, I am plugging away at my RailsConf talk, and I reached the point where I'm starting to work on slides. And this talk will be the first one where I have a lot of code that I want to present on my slides. And so, I've been playing around with a couple of different tools to present code on slides or, I guess, you know, just being able to share code outside of an editor. And the two tools I'm trying are...VS Code actually has a copy with syntax functionality in its command palette. And so, that's cool because it basically, you know, just takes your editor styling and applies it wherever you paste that code snippet. +JOËL: Is that a screenshot or that's, like, formatted text that you can paste in, like, a rich text editor? +STEPHANIE: Yeah, it's the latter. +JOËL: Okay. +STEPHANIE: That was nice because if I needed to make changes in my slides once I had already put them there, I could do that. But then the other tool that I was giving a whirl is Carbon.sh. And that one, I think, is pretty popular because it looks very slick. It kind of looks like a little Mac window and is very minimal. But you can paste your code into their text editor, and then you can export PNGs of the code. So, those are just screenshots rather than editable text. And I [chuckles] was using that, exported a bunch of screenshots of all of my code in various stages, and then realized I had a typo [laughs]. +JOËL: Oh no! +STEPHANIE: Yeah, so I have not got around to fixing that yet. That was pretty frustrating because now I would have to go back and regenerate all of those exports. So, that's kind of where I'm at in terms of exploring sharing code. So, if anyone has any other tools that they would use and recommend, I am all ears. +JOËL: How do you feel about balancing sort of the quantity of code that you put on a slide? Do you tend to go with, like, a larger code slide and then maybe, like, highlight certain sections? Do you try to explain ideas in general and then only show, like, a couple of lines? Do you show, like, maybe a class that's got ten lines, and that's fine? Where do you find that balance in terms of how much code to put on a slide? Because I feel like that's always the big dilemma for me. +STEPHANIE: Yeah. Since this is my first time doing it, like, I really have no idea how it's going to turn out. But what I've been trying is focusing more on changes between each slide, so the progression of the code. And then, I can, hopefully, focus more on what has changed since the last snippet of code we were looking at. That has also required me to be more fiddly with the formatting because I don't want essentially, like, the window that's containing the code to be changing sizes [laughs] in between slide transitions. So, that was a little bit finicky. +And then, there's also a few other parts where I am highlighting with, like, a border or something around certain texts that I will probably pause and talk about, but yeah, it's tough. I feel like I've seen it done well, but it's a lot harder to and a lot more effort to [laughs] do in practice, I'm finding. +JOËL: When someone does it well, it looks effortless. And then, when somebody does it poorly, you're like, okay, I'm struggling to connect with this talk. +STEPHANIE: Yep. Yep. I hear that. I don't know if you would agree with this, but I get the sense that people who are able to make that look effortless have, like, a really deep and thorough understanding of the code they're showing and what exactly they think is important for the audience to pay attention to and understand in that given moment in their talk. That's the part that I'm finding a lot more work [laughs] because just thinking about, you know, the code I'm showing from a different lens or perspective. +JOËL: How do you sort of shrink it down to only what's essential for the point that you're trying to make? And then, more broadly, not just the point you're trying to make on this one slide, but how does this one slide fit into the broader narrative of the story you're trying to tell? +STEPHANIE: Right. So, we'll see how it goes for me. I'm sure it's one of those things that takes practice and experience, and this will be my first time, and we'll learn something from it. +JOËL: That's exciting. So, this is RailsConf in Detroit this year, I believe, May 7th through 9th. +STEPHANIE: Yep. That's right. So, recently on my client work, I encountered a CI failure on a PR of mine that I was surprised by. And basically, I had introduced a new association on a model, and this CI failure was saying like, "Hey, like, we see that you introduced this association. You should consider adding this to the presenter for this model." And I hadn't even known that that presenter existed [laughs]. So, it was kind of interesting to get a CI failure nudging me to consider if I need to be, like, making a different, you know, this other change somewhere else. +JOËL: That's a really fun use of CI. Do you think that was sort of helpful for you as a newer person on that codebase? Or was it more kind of annoying and, like, okay, this CI is over the top? +STEPHANIE: You know, I'm not sure [laughs]. For what it's worth, this presenter was actually for their admin dashboard, essentially. And so, the goal of what this workflow was trying to do was help folks who are using the admin dashboard have, like, all of the capabilities they need to do that job. And it makes sense that as you add behavior to your app, sometimes those things could get missed in terms of supporting, you know, not just your customers but developers, support product, you know, the other users of your app. +So, it was cool. And that was, you know, something that they cared enough to enforce. But yeah, I think there maybe is a bit of a slippery slope or at least some kind of line, or it might even be pretty blurry around what should our test failures really be doing. +JOËL: And CI is interesting because it can be a lot more than just tests. You can run all sorts of things. You can run a linter that fails. You could run various code quality tools that are not things like unit tests. And I think those are all valid uses of the CI process. What's interesting here is that it sounds like there were two systems that needed to stay in sync. And this particular CI check was about making sure that we didn't accidentally introduce code that would sort of drift apart in those two places. Does that sound about right? +STEPHANIE: Yeah, that does sound right. I think where it gets a little fuzzy, for me, is whether that kind of check was for code quality, was for a standard, or for a policy, right? It was kind of saying like, hey, like, this is the way that we've enforced developers to keep those two things from drifting. Whereas I think that could be also handled in different ways, right? +JOËL: Yeah. I guess in terms of, like, keeping two things in sync, I like to do that at almost, like, a code level, if possible. I mean, maybe you need a single source of truth, and then it just sort of happens automatically. Otherwise, maybe doing it in a way that will yell at you. So, you know, maybe there's a base class somewhere that will raise an error, and that will get caught by CI, or, you know, when you're manually testing and like, oh yeah, I need to keep this thing in sync. Maybe you can derive some things or get fancy with metaprogramming. +And the goal here is you don't have a situation where someone adds a new file in one place and then they accidentally break an admin dashboard because they weren't aware that you needed these two files to be one-to-one. If I can't do it just at a code level, I have done that before at, like, a unit test level, where maybe there's, like, a constant somewhere, and I just want to assert that every item in this constant array has a matching entry somewhere else or something like that, so that you don't end up effectively crashing the site for someone else because that is broken behavior. +STEPHANIE: Yeah, in this particular case, it wasn't necessarily broken. It was asking you "Hey, should this be added to the admin presenter?" which I thought was interesting. But I also hear what you're saying. It actually does remind me of what we were talking about earlier when you've identified two things that should happen, like mostly together and whether the code gives you affordances to do that. +JOËL: So, one of the things you said is really interesting, the idea that adding to the presenter might have been optional. Does that mean that CI failed for you but that you could merge anyway, or how does that work? +STEPHANIE: Right. I should have been more clear. This was actually a test failure, you know, that happened to be caught by CI because I don't run [laughs] the whole test suite locally. +JOËL: But it's an optional test failure, so you're allowed to let that test fail. +STEPHANIE: Basically, it told me, like, if I want this to be shown in the presenter, add it to this method, or if not, add it to...it was kind of like an allow list basically. +JOËL: I see. +STEPHANIE: Or an ignore list, yeah. +JOËL: I think that kind of makes sense because now you have sort of, like, a required consistency thing. So, you say, "Our system requires you...whenever you add a file in this directory, you must add it to either an allow list or an ignore list, which we have set up in this other file." And, you know, sometimes you might forget, or sometimes you're new, and it's your first time adding a file in this directory, and you didn't remember there's a different place where you have to effectively register it. That seems like a reasonable check to have in place if you're relying on these sort of allow lists for other parts of the system, and you need to keep them in sync. +STEPHANIE: So, I think this is one of the few instances where I might disagree with you, Joël. What I'm thinking is that it feels a bit weird to me to enforce a decision that was so far away from the code change that I made. You know, you're right. On one hand, I am newer to this codebase, maybe have less of that context of different features, things that need to happen. It's a big app. But I almost think this test reinforces this weird coupling of things that are very far away from each other [laughs]. +JOËL: So, it's maybe not the test itself you object to rather than the general architecture where these admin presenters are relying on these other objects. And by you introducing a file in a totally different part of the app, there's a chance that you might break the admin, and that feels weird to you. +STEPHANIE: Yeah, that does feel weird to me. And then, also that this implementation is, like, codified in this test, I guess, as opposed to a different kind of, like, acceptance test, rather than specifying specifically like, oh, I noticed, you know, you didn't add this new association or attribute to either the allow list or the ignore list. Maybe there is a more, like, higher level test that could steer us in keeping the features consistent without necessarily dictating, like, that it needs to happen in these particular methods. +JOËL: So, you're talking something like doing an integration test rather than a unit test? Or are you talking about something entirely different? +STEPHANIE: I think it could be an integration test or a system test. I'm not sure exactly. But I am wondering what options, you know, are out there for helping keeping standards in place without necessarily, like, prescribing too much about, like, how it needs to be done. +JOËL: So, you used the word standard here, which I tend to think about more in terms of, like, code style, things like that. What you're describing here feels a little bit less like a standard and more of what I would call a code invariant. +STEPHANIE: Ooh. +JOËL: It's sort of like in this architecture the way we've set up, there must always be sort of one-to-one matching between files in this directory and entries in this array. Now, that's annoying because they're sort of, like, two different places, and they can vary independently. So, locking those two in sync requires you to do some clunky things, but that's sort of the way the architecture has been designed. These two things must remain one-to-one. This is an invariant we want in the app. +STEPHANIE: Can you define invariant for me [laughs], the way that you're using it here? +JOËL: Yeah, so something that is required to be true of all elements in this class of things, sort of a rule or a law that you're applying to the way that these particular bits of code need to behave. So, in this case, the invariant is every file in this directory must have a matching entry in this array. There's a lot of ways to enforce that. The sort of traditional idea is sort of pushing a lot of that checking...they'll sometimes talk about pushing errors to the left. So, if you can handle this earlier in the sort of code execution pipeline, can you do it maybe with a type system if you're in a type language? Can you do it with some sort of input validation at runtime? +Some languages have the concept of contracts, so maybe you enforce invariants using that. You could even do something really ad hoc in Ruby, where you might say, "Hey, at boot time, when we load this particular array for the admin, just load this directory. Make sure that the entries in the array match the entries in the directory, and if they don't, raise an error." And I guess you would catch that probably in CI just because you tried to run your test suite, and you'd immediately get this boot error because the entries don't match. +So, I guess it kind of gets [inaudible 22:36] CI, but now it's not really a dedicated test anymore. It's more of, like, a property of the system. And so, in this case, I've sort of shifted the error checking or the checking of this invariant more into the architecture itself rather than in, like, things that exercise the architecture. But you can go the other way and say, "Well, let's shift it out of the architecture into tests," or maybe even beyond that, into, like, manual QA or, you know, other things that you can do to verify it. +STEPHANIE: Hmm. That is very compelling to me. +JOËL: So, we've been talking so far about the idea of invariants, but the thing about invariants is that they don't vary. They're always true. This is a sort of fundamental rule of how this system works. The class of problems that I often struggle with how to deal with in these sorts of situations are rules that you only sometimes want to apply. They're not consistent. Have you ever run into things like that? +STEPHANIE: Yeah, I have. And I think that's what was compelling to me about what you were sharing about code invariance because I wasn't totally convinced this particular situation was a very clear and absolute rule that had been decided, you know, it seemed a little bit more ambiguous. +When you're talking about, like, applying rules that sometimes you actually don't want to apply, I think of things like linters, where we want to disable, you know, certain rules because we just can't get around implementing the way we want to while following those standards. Or maybe, you know, sometimes you just have to do something that is not accessible [laughs], not that that's what I would recommend, but in the case where there aren't other levers to change, you maybe want to disable some kind of accessibility check. +JOËL: That's always interesting, right? Because sometimes, you might want, like, the idea of something that has an escape hatch in it, but that immediately adds a lot of complexity to things as well. This is getting into more controversial territory. But I read a really compelling article by Jeroen Engels about how being able to, like, locally disable your linter for particular methods actually makes your code, but also the linter itself, a worse tool. And it really kind of made me rethink a little bit of how I approach linters as a tool. +STEPHANIE: Ooh. +JOËL: And what makes sense in a linter. +STEPHANIE: What was the argument for the linter being a worse tool by doing that? +JOËL: You know, it's funny that you ask because now I can't remember, and it's been a little while since I've read the article. +STEPHANIE: I'll have to revisit it after the show [laughs]. +JOËL: Apparently, I didn't do the homework for this episode, but we'll definitely link to that article in the show notes. +STEPHANIE: So, how do you approach either introducing a new rule to something like a linter or maybe reconsidering an existing rule? Like, how would you go about finding, like, consensus on that from your team? +JOËL: That varies a lot by organizational culture, right? Some places will do it top-down, some of them will have a broader conversation and come to a consensus. And sometimes you just straight up don't get a choice. You're pulling in a tool like standard rb, and you're saying, "Look, we don't want to have a discussion about every little style thing, so whatever, you know, the community has agreed on for the standard rb linter is the style we're using. There are no discussions. Do what the linter tells you." +STEPHANIE: Yeah, that's true. I think I have to adapt to whatever, you know, client culture is like when I join new projects. You know, sometimes I do see people being like, "Hey, I think it's kind of weird that we have this," or, "Hey, I've noticed, for example, oh, we're merging focused RSpec tests. Like, let's introduce a rule to make sure that that doesn't happen." +I also think that a different approach is for those things not to be enforced at all by automation, but we, you know, there are still guidelines. I think the thoughtbot guides are an example of pretty opinionated guidelines around style and syntax. But I don't think that those kinds of things would, you know, ever be, like, enforced in a way that would be blocking. +JOËL: Those are kind of hard because they're not as consistent as you would think, so it's not a rule you can apply every time. It's more of a, here's some things to maybe keep in mind. Or if you're writing code in this way, think about some of the edge cases that might happen, or don't default to writing it in this way because things might go wrong. Make sure you know what you're doing. I love the phrase, "Must be able to justify this," or sometimes, "Must convince your pair that this is okay." So, default to writing in style A, avoid style B unless you can have a compelling reason to do so and can articulate that on your PR or, you know, convince your pair that that's the right way to go. +STEPHANIE: Interesting. It's kind of like the honor system, then [laughs]. +JOËL: And I think that's sort of the general way when you're working with developers, right? There's a lot of areas where there is ambiguity. There is no single best way to do it. And so, you rely on people's expertise to build systems that work well. There are some things where you say, look, having conversations about these things is not useful. We want to have some amount of standardization or uniformity about certain things. Maybe there's invariance you want to hold. Maybe there's certain things we're, like, this should never get to production. +Whenever you've got these, like, broad sweeping statements about things should be always true or never true, that's a great time to introduce something like a linting rule. When it's more up to personal judgment, and you just want to nudge that judgment one way or another, then maybe it's better to have something like a guide. +STEPHANIE: Yeah, what I'm hearing is there is a bit of a spectrum. +JOËL: For sure. From things that are always true to things that are, like, sometimes true. I think I'm sort of curious about the idea of going a level beyond that, though, beyond things like just code style or maybe even, like, invariance you want to hold or something, being able to make suggestions to developers based off the code that is written. So, now you're applying more like heuristics, but instead of asking a human to apply those heuristics at code review time and leave some comments, maybe there's a way to get automated feedback from a tool. +STEPHANIE: Yeah, I think we had mentioned code analysis tools earlier because some teams and organizations include those as part of their CI builds, right? And, you know, even Brakeman, right? Like, that's an analysis tool for security. But I can't recall if I've seen an organization use things like Flog metrics which measure code complexity in things like that. How would you feel if that were a check that was blocking your work? +JOËL: So, I've seen things like that be used if you're using, like, the Code Climate plugin for GitHub. And Code Climate internally does effectively flog and other things that are fancier on your code quality. And so, you can set a threshold to say, hey, if complexity gets higher than a certain amount, fail the build. +You can also...if you're doing things via GitHub, what's nice is that you can do effectively non-blocking comments. So, instead of failing CI to say, "Hey, this method looks really complex. You cannot merge until you have made this method less complex," maybe the sort of, like, next step up in ambiguity is to just leave a comment on a PR from a tool and say, "Hey, this method here is looking really complex. Consider breaking it up." +STEPHANIE: Yeah, there is a tool that I've seen but not used called Danger, and its tagline is, Stop saying, "You forgot to..." in code review [laughs]. And it basically does that, what you were saying, of, like, leaving probably a suggestion. I can imagine it's blocking, but a suggestive comment that just automates that rather than it being a manual process that humans have to remember or notice. +JOËL: And there's a lot of things that could be specific to your organization or your architecture. So, you say, "Hey, you introduced a file here. Would you consider also making an entry to this presenter file so that it's editable on the admin?" And maybe that's a better place to handle that. Just a comment. But you wouldn't necessarily want every code reviewer to have to think about that. +STEPHANIE: So, I do think that I am sometimes not necessarily suspicious, but I have also seen tools like that end up just getting in the way, and it just becomes something you ignore. It's something you end up always using the escape hatch for, or people just find ways around it because they're harming more than they're helping. Do you have any thoughts about how to kind of keep those things in check and make sure that the tools we introduce genuinely are kind of helping the organization do the right thing rather than kind of being these perhaps arbitrary blockers? +JOËL: I'm going to throw a fancy phrase at you. +STEPHANIE: Ooh, I'm ready. +JOËL: Signal-to-noise ratio. +STEPHANIE: Whoa, uh-huh. +JOËL: So, how often is the feedback from your tool actually helpful, and how often is it just noise that you have to dismiss, or manually override, or things like that? At some point, the ratio becomes so much that you lose the signal in all the noise. And so, maybe you even, like, because you're always just ignoring the feedback from this tool, you accidentally start overriding things that would be genuinely helpful. And, at that point, you've got the worst of both worlds. +So, sort of keeping track on what that ratio is, and there's not, like, a magic number. I'm not going to tell you, "Oh, this is an 80/20 principle. You need to have, you know, 80% of the time it's useful and only 20% of the time it's not useful." I don't have a number to give you, but keeping track on maybe, you know, is it more often than not useful? Is your team getting to the point where they're just ignoring feedback from this tool? And thinking in terms of that signal versus that noise, I think is useful—to go back to that word again, heuristic for managing whether a tool is still helpful. +STEPHANIE: Yeah. And I would even go on to say that, you know, I always appreciate when people in leadership roles keep an eye on these things. And they're like, "Oh, I've been hearing that people are just totally numb to this tool [laughs]" or, you know, "There's no engagement on this. People are just ignoring those signals." Any developer impacted by this, it is valid to bring it up if you're getting frustrated by it or just finding yourself, you know, having all of these obstacles getting in the way of your development process. +JOËL: Sometimes, this can be a symptom that you're mixing too many classes of problems together in one tool. So, maybe there are things that are, like, really dangerous to your product to go live with them. Maybe it's, you know, something like Brakeman where you're doing security checks, and you really, ideally, would not go to production with a failing security check. +And then, you've got some random other style things in there, and you're just like, oh yeah, whatever, it's this tool because it's mostly style things but occasionally gives you a security problem. And because you ignore it all the time, now you accidentally go to production with a security problem. So, splitting that out and say, "Look, we've got blocking and unblocking because we recognize these two classes of problems can be a helpful solution to this problem." +STEPHANIE: Joël, did you just apply an object-oriented design principle to an organizational system? +[laughter] +JOËL: I may be too much of a developer. +STEPHANIE: Cool. Well, I really appreciate your input on this because, you know, I was just kind of mulling over, like, how I felt about these kinds of things that I encounter as a developer. And I am glad that we got to kind of talk about it. And I think it gives me a more expanded vocabulary to, you know, analyze or reflect when I encounter these things on different client organizations. +JOËL: And every organization is different, right? Like, you've got to learn the culture, learn the different elements of that software. What are the things that are invariant? What are the things that are dangerous that we don't want to ship without? What are the things that we're doing just for consistency? What are things which are, like, these are culturally things that we'd like to do? There's all these levels, and it's a lot to pick up. +STEPHANIE: Yeah. At the end of the day, I think what I really liked about the last thing you said was being able to identify the problem, like the class of problem, and applying the right tool for the right job. It helps me take a step back and perhaps even think of different solutions that we might not have thought about earlier because we had just gotten so used to the one way of enforcing or checking things like that. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + software development, dry-rb gems, input validation, parsing data, developer experience, RailsConf, CI test failures, coding standards, continuous integration, code presentation tools, VS Code, Carbon.sh, automated coding feedback, development workflows, system design, tool integration. + + Joël shares his experience with the dry-rb suite of gems, focusing on how he's been using contracts to validate input data. Stephanie relates to Joël's insights with her preparation for RailsConf, discussing her methods for presenting code in slides and weighing the aesthetics and functionality of different tools like VS Code and Carbon.sh. She also encounters a CI test failure that prompts her to consider the implications of enforcing specific coding standards through CI processes.

+ +

The conversation turns into a discussion on managing coding standards and tools effectively, ensuring that automated systems help rather than hinder development. Joël and Stephanie ponder the balance between enforcing strict coding standards through CI and allowing developers the flexibility to bypass specific rules when necessary, ensuring tools provide valuable feedback without becoming obstructions.

+ + + +

Transcript:

+ +

AD:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

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: I've been working on a project that uses the dry-rb suite of gems. And one of the things we're doing there is we're validating inputs using this concept of a contract. So, you sort of describe the shape and requirements of this, like hash of attributes that you get, and it will then tell you whether it's valid or not, along with error messages. We then want to use those to eventually build some other sort of value object type things that we use in the app. And because there's, like, failure points at multiple places that you have to track, it gets a little bit clunky.

+ +

And I got to thinking a little bit about, like, forget about the internal machinery. What is it that I would actually like to happen here? And really, what I want is to say, I've got this, like, bunch of attributes, which may or may not be correct. I want to pass them into a method, and then either get back a value object that I was hoping to construct or some kind of error.

+ +

STEPHANIE: That sounds reasonable to me.

+ +

JOËL: And then, thinking about it just a little bit longer, I was like, wait a minute, this idea of, like, unstructured input goes into a method, you get back something more structured or an error, that's kind of the broad definition of parsing. I think what I'm looking for is a parser object. And this really fits well with a style of processing popularized in the functional programming community called parse, don't validate the idea that you use a parser like this to sort of transform data from more loose to more strict values, values where you can have more assumptions.

+ +

And so, I create an object, and I can take a contract. I can take a class and say, "Attempt to take the following attributes. If they're valid according to the construct, create this classroom." And it, you know, does a bunch of error handling and some...under the hood, dry-rb does all this monad stuff. So, I handled that all inside of the object, but it's actually really nice.

+ +

STEPHANIE: Cool. Yeah, I had a feeling that was where you were going to go. A while back, we had talked about really impactful articles that we had read over the course of the year, and you had shared one called Parse, Don't Validate. And that heuristic has actually been stuck in my head a little bit. And that was really cool that you found an opportunity to use it in, you know, previously trying to make something work that, like, you weren't really sure kind of how you wanted to implement that.

+ +

JOËL: I think I had a bit of a light bulb moment as I was trying to figure this out because, in my mind, there are sort of two broad approaches. There's the parse, don't validate where you have some inputs, and then you transform them into something stricter. Or there's more of that validation approach where you have inputs, you verify that they're correct, and then you pass them on to someone else. And you just say, "Trust me, I verified they're in the right shape." Dry-rb sort of contracts feel like they fit more under that validation approach rather than the parse, don't validate.

+ +

Where I think the kind of the light bulb turned on for me is the idea that if you pair a validation step and an object construction step, you've effectively approximated the idea of parse, don't validate. So, if I create a parser object that says, in sort of one step, I'm going to validate some inputs and then immediately use them if they're valid to construct an object, then I've kind of done a parse don't validate, even though the individual building blocks don't follow that pattern.

+ +

STEPHANIE: More like a parse and validate, if you will [laughs]. I have a question for you. Like, do you own those inputs kind of in your domain?

+ +

JOËL: In this particular case, sort of. They're coming from a form, so yes. But it's user input, so never trust that.

+ +

STEPHANIE: Gotcha.

+ +

JOËL: I think you can take this idea and go a little bit broader as well. It doesn't have to be, like, the dry-rb-related stuff. You could do, for example, a JSON schema, right? You're dealing with the input from a third-party API, and you say, "Okay, well, I'm going to have a sort of validation JSON schema." It will just tell you, "Is this data valid or not?" and give you some errors.

+ +

But what if you paired that with construction and you could create a little parser object, if you wanted to, that says, "Hey, I've got a payload coming in from a third-party API, validate it against this JSON schema, and attempt to construct this shopping cart object, and give me an error otherwise." And now you've sort of created a nice, little parse, don't validate pipeline which I find a really nice way to deal with data like that.

+ +

STEPHANIE: From a user perspective, I'm curious: Does this also improve the user experience? I'm kind of wondering about that. It seems like it could. But have you explored that?

+ +

JOËL: This is more about the developer experience.

+ +

STEPHANIE: Got it.

+ +

JOËL: The user experience, I think, would be either identical or, you know, you can play around with things to display better errors. But this is more about the ergonomics on the development side of things. It was a little bit clunky to sort of assemble all the parts together. And sometimes we didn't immediately do both steps together at the same time. So, you might sort of have parameters that we're like, oh, these are totally good, we promise. And we pass them on to someone else, who passes them on to someone else. And then, they might try to do something with them and hope that they've got the data in the right shape.

+ +

And so, saying, let's co-locate these two things. Let's say the validation of the inputs and then the creation of some richer object happen immediately one after another. We're always going to bundle them together. And then, in this particular case, because we're using dry-rb, there's all this monad stuff that has to happen. That was a little bit clunky. We've sort of hidden that in one object, and then nobody else ever has to deal with that.

+ +

So, it's easier for developers in terms of just, if you want to turn inputs into objects, now you're just passing them into one object, into one, like, parser, and it works. But it's a nicer developer experience, but also there's a little bit more safety in that because now you're sort of always working with these richer objects that have been validated.

+ +

STEPHANIE: Yeah, that makes sense. It sounds very cohesive because you've determined that these are two things that should always happen together. The problems arise when they start to actually get separated, and you don't have what you need in terms of using your interfaces. And that's very nice that you were able to bundle that in an abstraction that makes sense.

+ +

JOËL: A really interesting thing I think about abstractions is sometimes thinking of them as the combination of multiple other things. So, you could say that the combination of one thing and another thing, and all of a sudden, you have a new sort of combo thing that you have created. And, in this case, I think the combination of input validation and construction, and, you know, to a certain extent, error handling, so maybe it's a combination of three things gives you a thing you can call a parser. And knowing that that combination is a thing you can put a name on, I think, is really powerful, or at least it felt really powerful to me when that light bulb turned on.

+ +

STEPHANIE: Yeah, it's kind of like the whole is greater than the sum of its parts.

+ +

JOËL: Yeah.

+ +

STEPHANIE: Cool.

+ +

JOËL: And you and I did an episode on Specialized Vocabulary a while back. And that power of naming, saying that, oh, I don't just have a bunch of little atomic steps that do things. But the fact that the combination of three or four of them is a thing in and of itself that has a name that we can talk about has properties that we're familiar with, all of a sudden, that is a really powerful way to think about a system.

+ +

STEPHANIE: Absolutely. That's very exciting.

+ +

JOËL: So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I am plugging away at my RailsConf talk, and I reached the point where I'm starting to work on slides. And this talk will be the first one where I have a lot of code that I want to present on my slides. And so, I've been playing around with a couple of different tools to present code on slides or, I guess, you know, just being able to share code outside of an editor. And the two tools I'm trying are...VS Code actually has a copy with syntax functionality in its command palette. And so, that's cool because it basically, you know, just takes your editor styling and applies it wherever you paste that code snippet.

+ +

JOËL: Is that a screenshot or that's, like, formatted text that you can paste in, like, a rich text editor?

+ +

STEPHANIE: Yeah, it's the latter.

+ +

JOËL: Okay.

+ +

STEPHANIE: That was nice because if I needed to make changes in my slides once I had already put them there, I could do that. But then the other tool that I was giving a whirl is Carbon.sh. And that one, I think, is pretty popular because it looks very slick. It kind of looks like a little Mac window and is very minimal. But you can paste your code into their text editor, and then you can export PNGs of the code. So, those are just screenshots rather than editable text. And I [chuckles] was using that, exported a bunch of screenshots of all of my code in various stages, and then realized I had a typo [laughs].

+ +

JOËL: Oh no!

+ +

STEPHANIE: Yeah, so I have not got around to fixing that yet. That was pretty frustrating because now I would have to go back and regenerate all of those exports. So, that's kind of where I'm at in terms of exploring sharing code. So, if anyone has any other tools that they would use and recommend, I am all ears.

+ +

JOËL: How do you feel about balancing sort of the quantity of code that you put on a slide? Do you tend to go with, like, a larger code slide and then maybe, like, highlight certain sections? Do you try to explain ideas in general and then only show, like, a couple of lines? Do you show, like, maybe a class that's got ten lines, and that's fine? Where do you find that balance in terms of how much code to put on a slide? Because I feel like that's always the big dilemma for me.

+ +

STEPHANIE: Yeah. Since this is my first time doing it, like, I really have no idea how it's going to turn out. But what I've been trying is focusing more on changes between each slide, so the progression of the code. And then, I can, hopefully, focus more on what has changed since the last snippet of code we were looking at. That has also required me to be more fiddly with the formatting because I don't want essentially, like, the window that's containing the code to be changing sizes [laughs] in between slide transitions. So, that was a little bit finicky.

+ +

And then, there's also a few other parts where I am highlighting with, like, a border or something around certain texts that I will probably pause and talk about, but yeah, it's tough. I feel like I've seen it done well, but it's a lot harder to and a lot more effort to [laughs] do in practice, I'm finding.

+ +

JOËL: When someone does it well, it looks effortless. And then, when somebody does it poorly, you're like, okay, I'm struggling to connect with this talk.

+ +

STEPHANIE: Yep. Yep. I hear that. I don't know if you would agree with this, but I get the sense that people who are able to make that look effortless have, like, a really deep and thorough understanding of the code they're showing and what exactly they think is important for the audience to pay attention to and understand in that given moment in their talk. That's the part that I'm finding a lot more work [laughs] because just thinking about, you know, the code I'm showing from a different lens or perspective.

+ +

JOËL: How do you sort of shrink it down to only what's essential for the point that you're trying to make? And then, more broadly, not just the point you're trying to make on this one slide, but how does this one slide fit into the broader narrative of the story you're trying to tell?

+ +

STEPHANIE: Right. So, we'll see how it goes for me. I'm sure it's one of those things that takes practice and experience, and this will be my first time, and we'll learn something from it.

+ +

JOËL: That's exciting. So, this is RailsConf in Detroit this year, I believe, May 7th through 9th.

+ +

STEPHANIE: Yep. That's right. So, recently on my client work, I encountered a CI failure on a PR of mine that I was surprised by. And basically, I had introduced a new association on a model, and this CI failure was saying like, "Hey, like, we see that you introduced this association. You should consider adding this to the presenter for this model." And I hadn't even known that that presenter existed [laughs]. So, it was kind of interesting to get a CI failure nudging me to consider if I need to be, like, making a different, you know, this other change somewhere else.

+ +

JOËL: That's a really fun use of CI. Do you think that was sort of helpful for you as a newer person on that codebase? Or was it more kind of annoying and, like, okay, this CI is over the top?

+ +

STEPHANIE: You know, I'm not sure [laughs]. For what it's worth, this presenter was actually for their admin dashboard, essentially. And so, the goal of what this workflow was trying to do was help folks who are using the admin dashboard have, like, all of the capabilities they need to do that job. And it makes sense that as you add behavior to your app, sometimes those things could get missed in terms of supporting, you know, not just your customers but developers, support product, you know, the other users of your app.

+ +

So, it was cool. And that was, you know, something that they cared enough to enforce. But yeah, I think there maybe is a bit of a slippery slope or at least some kind of line, or it might even be pretty blurry around what should our test failures really be doing.

+ +

JOËL: And CI is interesting because it can be a lot more than just tests. You can run all sorts of things. You can run a linter that fails. You could run various code quality tools that are not things like unit tests. And I think those are all valid uses of the CI process. What's interesting here is that it sounds like there were two systems that needed to stay in sync. And this particular CI check was about making sure that we didn't accidentally introduce code that would sort of drift apart in those two places. Does that sound about right?

+ +

STEPHANIE: Yeah, that does sound right. I think where it gets a little fuzzy, for me, is whether that kind of check was for code quality, was for a standard, or for a policy, right? It was kind of saying like, hey, like, this is the way that we've enforced developers to keep those two things from drifting. Whereas I think that could be also handled in different ways, right?

+ +

JOËL: Yeah. I guess in terms of, like, keeping two things in sync, I like to do that at almost, like, a code level, if possible. I mean, maybe you need a single source of truth, and then it just sort of happens automatically. Otherwise, maybe doing it in a way that will yell at you. So, you know, maybe there's a base class somewhere that will raise an error, and that will get caught by CI, or, you know, when you're manually testing and like, oh yeah, I need to keep this thing in sync. Maybe you can derive some things or get fancy with metaprogramming.

+ +

And the goal here is you don't have a situation where someone adds a new file in one place and then they accidentally break an admin dashboard because they weren't aware that you needed these two files to be one-to-one. If I can't do it just at a code level, I have done that before at, like, a unit test level, where maybe there's, like, a constant somewhere, and I just want to assert that every item in this constant array has a matching entry somewhere else or something like that, so that you don't end up effectively crashing the site for someone else because that is broken behavior.

+ +

STEPHANIE: Yeah, in this particular case, it wasn't necessarily broken. It was asking you "Hey, should this be added to the admin presenter?" which I thought was interesting. But I also hear what you're saying. It actually does remind me of what we were talking about earlier when you've identified two things that should happen, like mostly together and whether the code gives you affordances to do that.

+ +

JOËL: So, one of the things you said is really interesting, the idea that adding to the presenter might have been optional. Does that mean that CI failed for you but that you could merge anyway, or how does that work?

+ +

STEPHANIE: Right. I should have been more clear. This was actually a test failure, you know, that happened to be caught by CI because I don't run [laughs] the whole test suite locally.

+ +

JOËL: But it's an optional test failure, so you're allowed to let that test fail.

+ +

STEPHANIE: Basically, it told me, like, if I want this to be shown in the presenter, add it to this method, or if not, add it to...it was kind of like an allow list basically.

+ +

JOËL: I see.

+ +

STEPHANIE: Or an ignore list, yeah.

+ +

JOËL: I think that kind of makes sense because now you have sort of, like, a required consistency thing. So, you say, "Our system requires you...whenever you add a file in this directory, you must add it to either an allow list or an ignore list, which we have set up in this other file." And, you know, sometimes you might forget, or sometimes you're new, and it's your first time adding a file in this directory, and you didn't remember there's a different place where you have to effectively register it. That seems like a reasonable check to have in place if you're relying on these sort of allow lists for other parts of the system, and you need to keep them in sync.

+ +

STEPHANIE: So, I think this is one of the few instances where I might disagree with you, Joël. What I'm thinking is that it feels a bit weird to me to enforce a decision that was so far away from the code change that I made. You know, you're right. On one hand, I am newer to this codebase, maybe have less of that context of different features, things that need to happen. It's a big app. But I almost think this test reinforces this weird coupling of things that are very far away from each other [laughs].

+ +

JOËL: So, it's maybe not the test itself you object to rather than the general architecture where these admin presenters are relying on these other objects. And by you introducing a file in a totally different part of the app, there's a chance that you might break the admin, and that feels weird to you.

+ +

STEPHANIE: Yeah, that does feel weird to me. And then, also that this implementation is, like, codified in this test, I guess, as opposed to a different kind of, like, acceptance test, rather than specifying specifically like, oh, I noticed, you know, you didn't add this new association or attribute to either the allow list or the ignore list. Maybe there is a more, like, higher level test that could steer us in keeping the features consistent without necessarily dictating, like, that it needs to happen in these particular methods.

+ +

JOËL: So, you're talking something like doing an integration test rather than a unit test? Or are you talking about something entirely different?

+ +

STEPHANIE: I think it could be an integration test or a system test. I'm not sure exactly. But I am wondering what options, you know, are out there for helping keeping standards in place without necessarily, like, prescribing too much about, like, how it needs to be done.

+ +

JOËL: So, you used the word standard here, which I tend to think about more in terms of, like, code style, things like that. What you're describing here feels a little bit less like a standard and more of what I would call a code invariant.

+ +

STEPHANIE: Ooh.

+ +

JOËL: It's sort of like in this architecture the way we've set up, there must always be sort of one-to-one matching between files in this directory and entries in this array. Now, that's annoying because they're sort of, like, two different places, and they can vary independently. So, locking those two in sync requires you to do some clunky things, but that's sort of the way the architecture has been designed. These two things must remain one-to-one. This is an invariant we want in the app.

+ +

STEPHANIE: Can you define invariant for me [laughs], the way that you're using it here?

+ +

JOËL: Yeah, so something that is required to be true of all elements in this class of things, sort of a rule or a law that you're applying to the way that these particular bits of code need to behave. So, in this case, the invariant is every file in this directory must have a matching entry in this array. There's a lot of ways to enforce that. The sort of traditional idea is sort of pushing a lot of that checking...they'll sometimes talk about pushing errors to the left. So, if you can handle this earlier in the sort of code execution pipeline, can you do it maybe with a type system if you're in a type language? Can you do it with some sort of input validation at runtime?

+ +

Some languages have the concept of contracts, so maybe you enforce invariants using that. You could even do something really ad hoc in Ruby, where you might say, "Hey, at boot time, when we load this particular array for the admin, just load this directory. Make sure that the entries in the array match the entries in the directory, and if they don't, raise an error." And I guess you would catch that probably in CI just because you tried to run your test suite, and you'd immediately get this boot error because the entries don't match.

+ +

So, I guess it kind of gets [inaudible 22:36] CI, but now it's not really a dedicated test anymore. It's more of, like, a property of the system. And so, in this case, I've sort of shifted the error checking or the checking of this invariant more into the architecture itself rather than in, like, things that exercise the architecture. But you can go the other way and say, "Well, let's shift it out of the architecture into tests," or maybe even beyond that, into, like, manual QA or, you know, other things that you can do to verify it.

+ +

STEPHANIE: Hmm. That is very compelling to me.

+ +

JOËL: So, we've been talking so far about the idea of invariants, but the thing about invariants is that they don't vary. They're always true. This is a sort of fundamental rule of how this system works. The class of problems that I often struggle with how to deal with in these sorts of situations are rules that you only sometimes want to apply. They're not consistent. Have you ever run into things like that?

+ +

STEPHANIE: Yeah, I have. And I think that's what was compelling to me about what you were sharing about code invariance because I wasn't totally convinced this particular situation was a very clear and absolute rule that had been decided, you know, it seemed a little bit more ambiguous.

+ +

When you're talking about, like, applying rules that sometimes you actually don't want to apply, I think of things like linters, where we want to disable, you know, certain rules because we just can't get around implementing the way we want to while following those standards. Or maybe, you know, sometimes you just have to do something that is not accessible [laughs], not that that's what I would recommend, but in the case where there aren't other levers to change, you maybe want to disable some kind of accessibility check.

+ +

JOËL: That's always interesting, right? Because sometimes, you might want, like, the idea of something that has an escape hatch in it, but that immediately adds a lot of complexity to things as well. This is getting into more controversial territory. But I read a really compelling article by Jeroen Engels about how being able to, like, locally disable your linter for particular methods actually makes your code, but also the linter itself, a worse tool. And it really kind of made me rethink a little bit of how I approach linters as a tool.

+ +

STEPHANIE: Ooh.

+ +

JOËL: And what makes sense in a linter.

+ +

STEPHANIE: What was the argument for the linter being a worse tool by doing that?

+ +

JOËL: You know, it's funny that you ask because now I can't remember, and it's been a little while since I've read the article.

+ +

STEPHANIE: I'll have to revisit it after the show [laughs].

+ +

JOËL: Apparently, I didn't do the homework for this episode, but we'll definitely link to that article in the show notes.

+ +

STEPHANIE: So, how do you approach either introducing a new rule to something like a linter or maybe reconsidering an existing rule? Like, how would you go about finding, like, consensus on that from your team?

+ +

JOËL: That varies a lot by organizational culture, right? Some places will do it top-down, some of them will have a broader conversation and come to a consensus. And sometimes you just straight up don't get a choice. You're pulling in a tool like standard rb, and you're saying, "Look, we don't want to have a discussion about every little style thing, so whatever, you know, the community has agreed on for the standard rb linter is the style we're using. There are no discussions. Do what the linter tells you."

+ +

STEPHANIE: Yeah, that's true. I think I have to adapt to whatever, you know, client culture is like when I join new projects. You know, sometimes I do see people being like, "Hey, I think it's kind of weird that we have this," or, "Hey, I've noticed, for example, oh, we're merging focused RSpec tests. Like, let's introduce a rule to make sure that that doesn't happen."

+ +

I also think that a different approach is for those things not to be enforced at all by automation, but we, you know, there are still guidelines. I think the thoughtbot guides are an example of pretty opinionated guidelines around style and syntax. But I don't think that those kinds of things would, you know, ever be, like, enforced in a way that would be blocking.

+ +

JOËL: Those are kind of hard because they're not as consistent as you would think, so it's not a rule you can apply every time. It's more of a, here's some things to maybe keep in mind. Or if you're writing code in this way, think about some of the edge cases that might happen, or don't default to writing it in this way because things might go wrong. Make sure you know what you're doing. I love the phrase, "Must be able to justify this," or sometimes, "Must convince your pair that this is okay." So, default to writing in style A, avoid style B unless you can have a compelling reason to do so and can articulate that on your PR or, you know, convince your pair that that's the right way to go.

+ +

STEPHANIE: Interesting. It's kind of like the honor system, then [laughs].

+ +

JOËL: And I think that's sort of the general way when you're working with developers, right? There's a lot of areas where there is ambiguity. There is no single best way to do it. And so, you rely on people's expertise to build systems that work well. There are some things where you say, look, having conversations about these things is not useful. We want to have some amount of standardization or uniformity about certain things. Maybe there's invariance you want to hold. Maybe there's certain things we're, like, this should never get to production.

+ +

Whenever you've got these, like, broad sweeping statements about things should be always true or never true, that's a great time to introduce something like a linting rule. When it's more up to personal judgment, and you just want to nudge that judgment one way or another, then maybe it's better to have something like a guide.

+ +

STEPHANIE: Yeah, what I'm hearing is there is a bit of a spectrum.

+ +

JOËL: For sure. From things that are always true to things that are, like, sometimes true. I think I'm sort of curious about the idea of going a level beyond that, though, beyond things like just code style or maybe even, like, invariance you want to hold or something, being able to make suggestions to developers based off the code that is written. So, now you're applying more like heuristics, but instead of asking a human to apply those heuristics at code review time and leave some comments, maybe there's a way to get automated feedback from a tool.

+ +

STEPHANIE: Yeah, I think we had mentioned code analysis tools earlier because some teams and organizations include those as part of their CI builds, right? And, you know, even Brakeman, right? Like, that's an analysis tool for security. But I can't recall if I've seen an organization use things like Flog metrics which measure code complexity in things like that. How would you feel if that were a check that was blocking your work?

+ +

JOËL: So, I've seen things like that be used if you're using, like, the Code Climate plugin for GitHub. And Code Climate internally does effectively flog and other things that are fancier on your code quality. And so, you can set a threshold to say, hey, if complexity gets higher than a certain amount, fail the build.

+ +

You can also...if you're doing things via GitHub, what's nice is that you can do effectively non-blocking comments. So, instead of failing CI to say, "Hey, this method looks really complex. You cannot merge until you have made this method less complex," maybe the sort of, like, next step up in ambiguity is to just leave a comment on a PR from a tool and say, "Hey, this method here is looking really complex. Consider breaking it up."

+ +

STEPHANIE: Yeah, there is a tool that I've seen but not used called Danger, and its tagline is, Stop saying, "You forgot to..." in code review [laughs]. And it basically does that, what you were saying, of, like, leaving probably a suggestion. I can imagine it's blocking, but a suggestive comment that just automates that rather than it being a manual process that humans have to remember or notice.

+ +

JOËL: And there's a lot of things that could be specific to your organization or your architecture. So, you say, "Hey, you introduced a file here. Would you consider also making an entry to this presenter file so that it's editable on the admin?" And maybe that's a better place to handle that. Just a comment. But you wouldn't necessarily want every code reviewer to have to think about that.

+ +

STEPHANIE: So, I do think that I am sometimes not necessarily suspicious, but I have also seen tools like that end up just getting in the way, and it just becomes something you ignore. It's something you end up always using the escape hatch for, or people just find ways around it because they're harming more than they're helping. Do you have any thoughts about how to kind of keep those things in check and make sure that the tools we introduce genuinely are kind of helping the organization do the right thing rather than kind of being these perhaps arbitrary blockers?

+ +

JOËL: I'm going to throw a fancy phrase at you.

+ +

STEPHANIE: Ooh, I'm ready.

+ +

JOËL: Signal-to-noise ratio.

+ +

STEPHANIE: Whoa, uh-huh.

+ +

JOËL: So, how often is the feedback from your tool actually helpful, and how often is it just noise that you have to dismiss, or manually override, or things like that? At some point, the ratio becomes so much that you lose the signal in all the noise. And so, maybe you even, like, because you're always just ignoring the feedback from this tool, you accidentally start overriding things that would be genuinely helpful. And, at that point, you've got the worst of both worlds.

+ +

So, sort of keeping track on what that ratio is, and there's not, like, a magic number. I'm not going to tell you, "Oh, this is an 80/20 principle. You need to have, you know, 80% of the time it's useful and only 20% of the time it's not useful." I don't have a number to give you, but keeping track on maybe, you know, is it more often than not useful? Is your team getting to the point where they're just ignoring feedback from this tool? And thinking in terms of that signal versus that noise, I think is useful—to go back to that word again, heuristic for managing whether a tool is still helpful.

+ +

STEPHANIE: Yeah. And I would even go on to say that, you know, I always appreciate when people in leadership roles keep an eye on these things. And they're like, "Oh, I've been hearing that people are just totally numb to this tool [laughs]" or, you know, "There's no engagement on this. People are just ignoring those signals." Any developer impacted by this, it is valid to bring it up if you're getting frustrated by it or just finding yourself, you know, having all of these obstacles getting in the way of your development process.

+ +

JOËL: Sometimes, this can be a symptom that you're mixing too many classes of problems together in one tool. So, maybe there are things that are, like, really dangerous to your product to go live with them. Maybe it's, you know, something like Brakeman where you're doing security checks, and you really, ideally, would not go to production with a failing security check.

+ +

And then, you've got some random other style things in there, and you're just like, oh yeah, whatever, it's this tool because it's mostly style things but occasionally gives you a security problem. And because you ignore it all the time, now you accidentally go to production with a security problem. So, splitting that out and say, "Look, we've got blocking and unblocking because we recognize these two classes of problems can be a helpful solution to this problem."

+ +

STEPHANIE: Joël, did you just apply an object-oriented design principle to an organizational system?

+ +

[laughter]

+ +

JOËL: I may be too much of a developer.

+ +

STEPHANIE: Cool. Well, I really appreciate your input on this because, you know, I was just kind of mulling over, like, how I felt about these kinds of things that I encounter as a developer. And I am glad that we got to kind of talk about it. And I think it gives me a more expanded vocabulary to, you know, analyze or reflect when I encounter these things on different client organizations.

+ +

JOËL: And every organization is different, right? Like, you've got to learn the culture, learn the different elements of that software. What are the things that are invariant? What are the things that are dangerous that we don't want to ship without? What are the things that we're doing just for consistency? What are things which are, like, these are culturally things that we'd like to do? There's all these levels, and it's a lot to pick up.

+ +

STEPHANIE: Yeah. At the end of the day, I think what I really liked about the last thing you said was being able to identify the problem, like the class of problem, and applying the right tool for the right job. It helps me take a step back and perhaps even think of different solutions that we might not have thought about earlier because we had just gotten so used to the one way of enforcing or checking things like that.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël shares his experience with the dry-rb suite of gems, focusing on how he's been using contracts to validate input data. Stephanie relates to Joël's insights with her preparation for RailsConf, discussing her methods for presenting code in slides and weighing the aesthetics and functionality of different tools like VS Code and Carbon.sh. She also encounters a CI test failure that prompts her to consider the implications of enforcing specific coding standards through CI processes.

+ +

The conversation turns into a discussion on managing coding standards and tools effectively, ensuring that automated systems help rather than hinder development. Joël and Stephanie ponder the balance between enforcing strict coding standards through CI and allowing developers the flexibility to bypass specific rules when necessary, ensuring tools provide valuable feedback without becoming obstructions.

+ + + +

Transcript:

+ +

AD:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

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: I've been working on a project that uses the dry-rb suite of gems. And one of the things we're doing there is we're validating inputs using this concept of a contract. So, you sort of describe the shape and requirements of this, like hash of attributes that you get, and it will then tell you whether it's valid or not, along with error messages. We then want to use those to eventually build some other sort of value object type things that we use in the app. And because there's, like, failure points at multiple places that you have to track, it gets a little bit clunky.

+ +

And I got to thinking a little bit about, like, forget about the internal machinery. What is it that I would actually like to happen here? And really, what I want is to say, I've got this, like, bunch of attributes, which may or may not be correct. I want to pass them into a method, and then either get back a value object that I was hoping to construct or some kind of error.

+ +

STEPHANIE: That sounds reasonable to me.

+ +

JOËL: And then, thinking about it just a little bit longer, I was like, wait a minute, this idea of, like, unstructured input goes into a method, you get back something more structured or an error, that's kind of the broad definition of parsing. I think what I'm looking for is a parser object. And this really fits well with a style of processing popularized in the functional programming community called parse, don't validate the idea that you use a parser like this to sort of transform data from more loose to more strict values, values where you can have more assumptions.

+ +

And so, I create an object, and I can take a contract. I can take a class and say, "Attempt to take the following attributes. If they're valid according to the construct, create this classroom." And it, you know, does a bunch of error handling and some...under the hood, dry-rb does all this monad stuff. So, I handled that all inside of the object, but it's actually really nice.

+ +

STEPHANIE: Cool. Yeah, I had a feeling that was where you were going to go. A while back, we had talked about really impactful articles that we had read over the course of the year, and you had shared one called Parse, Don't Validate. And that heuristic has actually been stuck in my head a little bit. And that was really cool that you found an opportunity to use it in, you know, previously trying to make something work that, like, you weren't really sure kind of how you wanted to implement that.

+ +

JOËL: I think I had a bit of a light bulb moment as I was trying to figure this out because, in my mind, there are sort of two broad approaches. There's the parse, don't validate where you have some inputs, and then you transform them into something stricter. Or there's more of that validation approach where you have inputs, you verify that they're correct, and then you pass them on to someone else. And you just say, "Trust me, I verified they're in the right shape." Dry-rb sort of contracts feel like they fit more under that validation approach rather than the parse, don't validate.

+ +

Where I think the kind of the light bulb turned on for me is the idea that if you pair a validation step and an object construction step, you've effectively approximated the idea of parse, don't validate. So, if I create a parser object that says, in sort of one step, I'm going to validate some inputs and then immediately use them if they're valid to construct an object, then I've kind of done a parse don't validate, even though the individual building blocks don't follow that pattern.

+ +

STEPHANIE: More like a parse and validate, if you will [laughs]. I have a question for you. Like, do you own those inputs kind of in your domain?

+ +

JOËL: In this particular case, sort of. They're coming from a form, so yes. But it's user input, so never trust that.

+ +

STEPHANIE: Gotcha.

+ +

JOËL: I think you can take this idea and go a little bit broader as well. It doesn't have to be, like, the dry-rb-related stuff. You could do, for example, a JSON schema, right? You're dealing with the input from a third-party API, and you say, "Okay, well, I'm going to have a sort of validation JSON schema." It will just tell you, "Is this data valid or not?" and give you some errors.

+ +

But what if you paired that with construction and you could create a little parser object, if you wanted to, that says, "Hey, I've got a payload coming in from a third-party API, validate it against this JSON schema, and attempt to construct this shopping cart object, and give me an error otherwise." And now you've sort of created a nice, little parse, don't validate pipeline which I find a really nice way to deal with data like that.

+ +

STEPHANIE: From a user perspective, I'm curious: Does this also improve the user experience? I'm kind of wondering about that. It seems like it could. But have you explored that?

+ +

JOËL: This is more about the developer experience.

+ +

STEPHANIE: Got it.

+ +

JOËL: The user experience, I think, would be either identical or, you know, you can play around with things to display better errors. But this is more about the ergonomics on the development side of things. It was a little bit clunky to sort of assemble all the parts together. And sometimes we didn't immediately do both steps together at the same time. So, you might sort of have parameters that we're like, oh, these are totally good, we promise. And we pass them on to someone else, who passes them on to someone else. And then, they might try to do something with them and hope that they've got the data in the right shape.

+ +

And so, saying, let's co-locate these two things. Let's say the validation of the inputs and then the creation of some richer object happen immediately one after another. We're always going to bundle them together. And then, in this particular case, because we're using dry-rb, there's all this monad stuff that has to happen. That was a little bit clunky. We've sort of hidden that in one object, and then nobody else ever has to deal with that.

+ +

So, it's easier for developers in terms of just, if you want to turn inputs into objects, now you're just passing them into one object, into one, like, parser, and it works. But it's a nicer developer experience, but also there's a little bit more safety in that because now you're sort of always working with these richer objects that have been validated.

+ +

STEPHANIE: Yeah, that makes sense. It sounds very cohesive because you've determined that these are two things that should always happen together. The problems arise when they start to actually get separated, and you don't have what you need in terms of using your interfaces. And that's very nice that you were able to bundle that in an abstraction that makes sense.

+ +

JOËL: A really interesting thing I think about abstractions is sometimes thinking of them as the combination of multiple other things. So, you could say that the combination of one thing and another thing, and all of a sudden, you have a new sort of combo thing that you have created. And, in this case, I think the combination of input validation and construction, and, you know, to a certain extent, error handling, so maybe it's a combination of three things gives you a thing you can call a parser. And knowing that that combination is a thing you can put a name on, I think, is really powerful, or at least it felt really powerful to me when that light bulb turned on.

+ +

STEPHANIE: Yeah, it's kind of like the whole is greater than the sum of its parts.

+ +

JOËL: Yeah.

+ +

STEPHANIE: Cool.

+ +

JOËL: And you and I did an episode on Specialized Vocabulary a while back. And that power of naming, saying that, oh, I don't just have a bunch of little atomic steps that do things. But the fact that the combination of three or four of them is a thing in and of itself that has a name that we can talk about has properties that we're familiar with, all of a sudden, that is a really powerful way to think about a system.

+ +

STEPHANIE: Absolutely. That's very exciting.

+ +

JOËL: So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I am plugging away at my RailsConf talk, and I reached the point where I'm starting to work on slides. And this talk will be the first one where I have a lot of code that I want to present on my slides. And so, I've been playing around with a couple of different tools to present code on slides or, I guess, you know, just being able to share code outside of an editor. And the two tools I'm trying are...VS Code actually has a copy with syntax functionality in its command palette. And so, that's cool because it basically, you know, just takes your editor styling and applies it wherever you paste that code snippet.

+ +

JOËL: Is that a screenshot or that's, like, formatted text that you can paste in, like, a rich text editor?

+ +

STEPHANIE: Yeah, it's the latter.

+ +

JOËL: Okay.

+ +

STEPHANIE: That was nice because if I needed to make changes in my slides once I had already put them there, I could do that. But then the other tool that I was giving a whirl is Carbon.sh. And that one, I think, is pretty popular because it looks very slick. It kind of looks like a little Mac window and is very minimal. But you can paste your code into their text editor, and then you can export PNGs of the code. So, those are just screenshots rather than editable text. And I [chuckles] was using that, exported a bunch of screenshots of all of my code in various stages, and then realized I had a typo [laughs].

+ +

JOËL: Oh no!

+ +

STEPHANIE: Yeah, so I have not got around to fixing that yet. That was pretty frustrating because now I would have to go back and regenerate all of those exports. So, that's kind of where I'm at in terms of exploring sharing code. So, if anyone has any other tools that they would use and recommend, I am all ears.

+ +

JOËL: How do you feel about balancing sort of the quantity of code that you put on a slide? Do you tend to go with, like, a larger code slide and then maybe, like, highlight certain sections? Do you try to explain ideas in general and then only show, like, a couple of lines? Do you show, like, maybe a class that's got ten lines, and that's fine? Where do you find that balance in terms of how much code to put on a slide? Because I feel like that's always the big dilemma for me.

+ +

STEPHANIE: Yeah. Since this is my first time doing it, like, I really have no idea how it's going to turn out. But what I've been trying is focusing more on changes between each slide, so the progression of the code. And then, I can, hopefully, focus more on what has changed since the last snippet of code we were looking at. That has also required me to be more fiddly with the formatting because I don't want essentially, like, the window that's containing the code to be changing sizes [laughs] in between slide transitions. So, that was a little bit finicky.

+ +

And then, there's also a few other parts where I am highlighting with, like, a border or something around certain texts that I will probably pause and talk about, but yeah, it's tough. I feel like I've seen it done well, but it's a lot harder to and a lot more effort to [laughs] do in practice, I'm finding.

+ +

JOËL: When someone does it well, it looks effortless. And then, when somebody does it poorly, you're like, okay, I'm struggling to connect with this talk.

+ +

STEPHANIE: Yep. Yep. I hear that. I don't know if you would agree with this, but I get the sense that people who are able to make that look effortless have, like, a really deep and thorough understanding of the code they're showing and what exactly they think is important for the audience to pay attention to and understand in that given moment in their talk. That's the part that I'm finding a lot more work [laughs] because just thinking about, you know, the code I'm showing from a different lens or perspective.

+ +

JOËL: How do you sort of shrink it down to only what's essential for the point that you're trying to make? And then, more broadly, not just the point you're trying to make on this one slide, but how does this one slide fit into the broader narrative of the story you're trying to tell?

+ +

STEPHANIE: Right. So, we'll see how it goes for me. I'm sure it's one of those things that takes practice and experience, and this will be my first time, and we'll learn something from it.

+ +

JOËL: That's exciting. So, this is RailsConf in Detroit this year, I believe, May 7th through 9th.

+ +

STEPHANIE: Yep. That's right. So, recently on my client work, I encountered a CI failure on a PR of mine that I was surprised by. And basically, I had introduced a new association on a model, and this CI failure was saying like, "Hey, like, we see that you introduced this association. You should consider adding this to the presenter for this model." And I hadn't even known that that presenter existed [laughs]. So, it was kind of interesting to get a CI failure nudging me to consider if I need to be, like, making a different, you know, this other change somewhere else.

+ +

JOËL: That's a really fun use of CI. Do you think that was sort of helpful for you as a newer person on that codebase? Or was it more kind of annoying and, like, okay, this CI is over the top?

+ +

STEPHANIE: You know, I'm not sure [laughs]. For what it's worth, this presenter was actually for their admin dashboard, essentially. And so, the goal of what this workflow was trying to do was help folks who are using the admin dashboard have, like, all of the capabilities they need to do that job. And it makes sense that as you add behavior to your app, sometimes those things could get missed in terms of supporting, you know, not just your customers but developers, support product, you know, the other users of your app.

+ +

So, it was cool. And that was, you know, something that they cared enough to enforce. But yeah, I think there maybe is a bit of a slippery slope or at least some kind of line, or it might even be pretty blurry around what should our test failures really be doing.

+ +

JOËL: And CI is interesting because it can be a lot more than just tests. You can run all sorts of things. You can run a linter that fails. You could run various code quality tools that are not things like unit tests. And I think those are all valid uses of the CI process. What's interesting here is that it sounds like there were two systems that needed to stay in sync. And this particular CI check was about making sure that we didn't accidentally introduce code that would sort of drift apart in those two places. Does that sound about right?

+ +

STEPHANIE: Yeah, that does sound right. I think where it gets a little fuzzy, for me, is whether that kind of check was for code quality, was for a standard, or for a policy, right? It was kind of saying like, hey, like, this is the way that we've enforced developers to keep those two things from drifting. Whereas I think that could be also handled in different ways, right?

+ +

JOËL: Yeah. I guess in terms of, like, keeping two things in sync, I like to do that at almost, like, a code level, if possible. I mean, maybe you need a single source of truth, and then it just sort of happens automatically. Otherwise, maybe doing it in a way that will yell at you. So, you know, maybe there's a base class somewhere that will raise an error, and that will get caught by CI, or, you know, when you're manually testing and like, oh yeah, I need to keep this thing in sync. Maybe you can derive some things or get fancy with metaprogramming.

+ +

And the goal here is you don't have a situation where someone adds a new file in one place and then they accidentally break an admin dashboard because they weren't aware that you needed these two files to be one-to-one. If I can't do it just at a code level, I have done that before at, like, a unit test level, where maybe there's, like, a constant somewhere, and I just want to assert that every item in this constant array has a matching entry somewhere else or something like that, so that you don't end up effectively crashing the site for someone else because that is broken behavior.

+ +

STEPHANIE: Yeah, in this particular case, it wasn't necessarily broken. It was asking you "Hey, should this be added to the admin presenter?" which I thought was interesting. But I also hear what you're saying. It actually does remind me of what we were talking about earlier when you've identified two things that should happen, like mostly together and whether the code gives you affordances to do that.

+ +

JOËL: So, one of the things you said is really interesting, the idea that adding to the presenter might have been optional. Does that mean that CI failed for you but that you could merge anyway, or how does that work?

+ +

STEPHANIE: Right. I should have been more clear. This was actually a test failure, you know, that happened to be caught by CI because I don't run [laughs] the whole test suite locally.

+ +

JOËL: But it's an optional test failure, so you're allowed to let that test fail.

+ +

STEPHANIE: Basically, it told me, like, if I want this to be shown in the presenter, add it to this method, or if not, add it to...it was kind of like an allow list basically.

+ +

JOËL: I see.

+ +

STEPHANIE: Or an ignore list, yeah.

+ +

JOËL: I think that kind of makes sense because now you have sort of, like, a required consistency thing. So, you say, "Our system requires you...whenever you add a file in this directory, you must add it to either an allow list or an ignore list, which we have set up in this other file." And, you know, sometimes you might forget, or sometimes you're new, and it's your first time adding a file in this directory, and you didn't remember there's a different place where you have to effectively register it. That seems like a reasonable check to have in place if you're relying on these sort of allow lists for other parts of the system, and you need to keep them in sync.

+ +

STEPHANIE: So, I think this is one of the few instances where I might disagree with you, Joël. What I'm thinking is that it feels a bit weird to me to enforce a decision that was so far away from the code change that I made. You know, you're right. On one hand, I am newer to this codebase, maybe have less of that context of different features, things that need to happen. It's a big app. But I almost think this test reinforces this weird coupling of things that are very far away from each other [laughs].

+ +

JOËL: So, it's maybe not the test itself you object to rather than the general architecture where these admin presenters are relying on these other objects. And by you introducing a file in a totally different part of the app, there's a chance that you might break the admin, and that feels weird to you.

+ +

STEPHANIE: Yeah, that does feel weird to me. And then, also that this implementation is, like, codified in this test, I guess, as opposed to a different kind of, like, acceptance test, rather than specifying specifically like, oh, I noticed, you know, you didn't add this new association or attribute to either the allow list or the ignore list. Maybe there is a more, like, higher level test that could steer us in keeping the features consistent without necessarily dictating, like, that it needs to happen in these particular methods.

+ +

JOËL: So, you're talking something like doing an integration test rather than a unit test? Or are you talking about something entirely different?

+ +

STEPHANIE: I think it could be an integration test or a system test. I'm not sure exactly. But I am wondering what options, you know, are out there for helping keeping standards in place without necessarily, like, prescribing too much about, like, how it needs to be done.

+ +

JOËL: So, you used the word standard here, which I tend to think about more in terms of, like, code style, things like that. What you're describing here feels a little bit less like a standard and more of what I would call a code invariant.

+ +

STEPHANIE: Ooh.

+ +

JOËL: It's sort of like in this architecture the way we've set up, there must always be sort of one-to-one matching between files in this directory and entries in this array. Now, that's annoying because they're sort of, like, two different places, and they can vary independently. So, locking those two in sync requires you to do some clunky things, but that's sort of the way the architecture has been designed. These two things must remain one-to-one. This is an invariant we want in the app.

+ +

STEPHANIE: Can you define invariant for me [laughs], the way that you're using it here?

+ +

JOËL: Yeah, so something that is required to be true of all elements in this class of things, sort of a rule or a law that you're applying to the way that these particular bits of code need to behave. So, in this case, the invariant is every file in this directory must have a matching entry in this array. There's a lot of ways to enforce that. The sort of traditional idea is sort of pushing a lot of that checking...they'll sometimes talk about pushing errors to the left. So, if you can handle this earlier in the sort of code execution pipeline, can you do it maybe with a type system if you're in a type language? Can you do it with some sort of input validation at runtime?

+ +

Some languages have the concept of contracts, so maybe you enforce invariants using that. You could even do something really ad hoc in Ruby, where you might say, "Hey, at boot time, when we load this particular array for the admin, just load this directory. Make sure that the entries in the array match the entries in the directory, and if they don't, raise an error." And I guess you would catch that probably in CI just because you tried to run your test suite, and you'd immediately get this boot error because the entries don't match.

+ +

So, I guess it kind of gets [inaudible 22:36] CI, but now it's not really a dedicated test anymore. It's more of, like, a property of the system. And so, in this case, I've sort of shifted the error checking or the checking of this invariant more into the architecture itself rather than in, like, things that exercise the architecture. But you can go the other way and say, "Well, let's shift it out of the architecture into tests," or maybe even beyond that, into, like, manual QA or, you know, other things that you can do to verify it.

+ +

STEPHANIE: Hmm. That is very compelling to me.

+ +

JOËL: So, we've been talking so far about the idea of invariants, but the thing about invariants is that they don't vary. They're always true. This is a sort of fundamental rule of how this system works. The class of problems that I often struggle with how to deal with in these sorts of situations are rules that you only sometimes want to apply. They're not consistent. Have you ever run into things like that?

+ +

STEPHANIE: Yeah, I have. And I think that's what was compelling to me about what you were sharing about code invariance because I wasn't totally convinced this particular situation was a very clear and absolute rule that had been decided, you know, it seemed a little bit more ambiguous.

+ +

When you're talking about, like, applying rules that sometimes you actually don't want to apply, I think of things like linters, where we want to disable, you know, certain rules because we just can't get around implementing the way we want to while following those standards. Or maybe, you know, sometimes you just have to do something that is not accessible [laughs], not that that's what I would recommend, but in the case where there aren't other levers to change, you maybe want to disable some kind of accessibility check.

+ +

JOËL: That's always interesting, right? Because sometimes, you might want, like, the idea of something that has an escape hatch in it, but that immediately adds a lot of complexity to things as well. This is getting into more controversial territory. But I read a really compelling article by Jeroen Engels about how being able to, like, locally disable your linter for particular methods actually makes your code, but also the linter itself, a worse tool. And it really kind of made me rethink a little bit of how I approach linters as a tool.

+ +

STEPHANIE: Ooh.

+ +

JOËL: And what makes sense in a linter.

+ +

STEPHANIE: What was the argument for the linter being a worse tool by doing that?

+ +

JOËL: You know, it's funny that you ask because now I can't remember, and it's been a little while since I've read the article.

+ +

STEPHANIE: I'll have to revisit it after the show [laughs].

+ +

JOËL: Apparently, I didn't do the homework for this episode, but we'll definitely link to that article in the show notes.

+ +

STEPHANIE: So, how do you approach either introducing a new rule to something like a linter or maybe reconsidering an existing rule? Like, how would you go about finding, like, consensus on that from your team?

+ +

JOËL: That varies a lot by organizational culture, right? Some places will do it top-down, some of them will have a broader conversation and come to a consensus. And sometimes you just straight up don't get a choice. You're pulling in a tool like standard rb, and you're saying, "Look, we don't want to have a discussion about every little style thing, so whatever, you know, the community has agreed on for the standard rb linter is the style we're using. There are no discussions. Do what the linter tells you."

+ +

STEPHANIE: Yeah, that's true. I think I have to adapt to whatever, you know, client culture is like when I join new projects. You know, sometimes I do see people being like, "Hey, I think it's kind of weird that we have this," or, "Hey, I've noticed, for example, oh, we're merging focused RSpec tests. Like, let's introduce a rule to make sure that that doesn't happen."

+ +

I also think that a different approach is for those things not to be enforced at all by automation, but we, you know, there are still guidelines. I think the thoughtbot guides are an example of pretty opinionated guidelines around style and syntax. But I don't think that those kinds of things would, you know, ever be, like, enforced in a way that would be blocking.

+ +

JOËL: Those are kind of hard because they're not as consistent as you would think, so it's not a rule you can apply every time. It's more of a, here's some things to maybe keep in mind. Or if you're writing code in this way, think about some of the edge cases that might happen, or don't default to writing it in this way because things might go wrong. Make sure you know what you're doing. I love the phrase, "Must be able to justify this," or sometimes, "Must convince your pair that this is okay." So, default to writing in style A, avoid style B unless you can have a compelling reason to do so and can articulate that on your PR or, you know, convince your pair that that's the right way to go.

+ +

STEPHANIE: Interesting. It's kind of like the honor system, then [laughs].

+ +

JOËL: And I think that's sort of the general way when you're working with developers, right? There's a lot of areas where there is ambiguity. There is no single best way to do it. And so, you rely on people's expertise to build systems that work well. There are some things where you say, look, having conversations about these things is not useful. We want to have some amount of standardization or uniformity about certain things. Maybe there's invariance you want to hold. Maybe there's certain things we're, like, this should never get to production.

+ +

Whenever you've got these, like, broad sweeping statements about things should be always true or never true, that's a great time to introduce something like a linting rule. When it's more up to personal judgment, and you just want to nudge that judgment one way or another, then maybe it's better to have something like a guide.

+ +

STEPHANIE: Yeah, what I'm hearing is there is a bit of a spectrum.

+ +

JOËL: For sure. From things that are always true to things that are, like, sometimes true. I think I'm sort of curious about the idea of going a level beyond that, though, beyond things like just code style or maybe even, like, invariance you want to hold or something, being able to make suggestions to developers based off the code that is written. So, now you're applying more like heuristics, but instead of asking a human to apply those heuristics at code review time and leave some comments, maybe there's a way to get automated feedback from a tool.

+ +

STEPHANIE: Yeah, I think we had mentioned code analysis tools earlier because some teams and organizations include those as part of their CI builds, right? And, you know, even Brakeman, right? Like, that's an analysis tool for security. But I can't recall if I've seen an organization use things like Flog metrics which measure code complexity in things like that. How would you feel if that were a check that was blocking your work?

+ +

JOËL: So, I've seen things like that be used if you're using, like, the Code Climate plugin for GitHub. And Code Climate internally does effectively flog and other things that are fancier on your code quality. And so, you can set a threshold to say, hey, if complexity gets higher than a certain amount, fail the build.

+ +

You can also...if you're doing things via GitHub, what's nice is that you can do effectively non-blocking comments. So, instead of failing CI to say, "Hey, this method looks really complex. You cannot merge until you have made this method less complex," maybe the sort of, like, next step up in ambiguity is to just leave a comment on a PR from a tool and say, "Hey, this method here is looking really complex. Consider breaking it up."

+ +

STEPHANIE: Yeah, there is a tool that I've seen but not used called Danger, and its tagline is, Stop saying, "You forgot to..." in code review [laughs]. And it basically does that, what you were saying, of, like, leaving probably a suggestion. I can imagine it's blocking, but a suggestive comment that just automates that rather than it being a manual process that humans have to remember or notice.

+ +

JOËL: And there's a lot of things that could be specific to your organization or your architecture. So, you say, "Hey, you introduced a file here. Would you consider also making an entry to this presenter file so that it's editable on the admin?" And maybe that's a better place to handle that. Just a comment. But you wouldn't necessarily want every code reviewer to have to think about that.

+ +

STEPHANIE: So, I do think that I am sometimes not necessarily suspicious, but I have also seen tools like that end up just getting in the way, and it just becomes something you ignore. It's something you end up always using the escape hatch for, or people just find ways around it because they're harming more than they're helping. Do you have any thoughts about how to kind of keep those things in check and make sure that the tools we introduce genuinely are kind of helping the organization do the right thing rather than kind of being these perhaps arbitrary blockers?

+ +

JOËL: I'm going to throw a fancy phrase at you.

+ +

STEPHANIE: Ooh, I'm ready.

+ +

JOËL: Signal-to-noise ratio.

+ +

STEPHANIE: Whoa, uh-huh.

+ +

JOËL: So, how often is the feedback from your tool actually helpful, and how often is it just noise that you have to dismiss, or manually override, or things like that? At some point, the ratio becomes so much that you lose the signal in all the noise. And so, maybe you even, like, because you're always just ignoring the feedback from this tool, you accidentally start overriding things that would be genuinely helpful. And, at that point, you've got the worst of both worlds.

+ +

So, sort of keeping track on what that ratio is, and there's not, like, a magic number. I'm not going to tell you, "Oh, this is an 80/20 principle. You need to have, you know, 80% of the time it's useful and only 20% of the time it's not useful." I don't have a number to give you, but keeping track on maybe, you know, is it more often than not useful? Is your team getting to the point where they're just ignoring feedback from this tool? And thinking in terms of that signal versus that noise, I think is useful—to go back to that word again, heuristic for managing whether a tool is still helpful.

+ +

STEPHANIE: Yeah. And I would even go on to say that, you know, I always appreciate when people in leadership roles keep an eye on these things. And they're like, "Oh, I've been hearing that people are just totally numb to this tool [laughs]" or, you know, "There's no engagement on this. People are just ignoring those signals." Any developer impacted by this, it is valid to bring it up if you're getting frustrated by it or just finding yourself, you know, having all of these obstacles getting in the way of your development process.

+ +

JOËL: Sometimes, this can be a symptom that you're mixing too many classes of problems together in one tool. So, maybe there are things that are, like, really dangerous to your product to go live with them. Maybe it's, you know, something like Brakeman where you're doing security checks, and you really, ideally, would not go to production with a failing security check.

+ +

And then, you've got some random other style things in there, and you're just like, oh yeah, whatever, it's this tool because it's mostly style things but occasionally gives you a security problem. And because you ignore it all the time, now you accidentally go to production with a security problem. So, splitting that out and say, "Look, we've got blocking and unblocking because we recognize these two classes of problems can be a helpful solution to this problem."

+ +

STEPHANIE: Joël, did you just apply an object-oriented design principle to an organizational system?

+ +

[laughter]

+ +

JOËL: I may be too much of a developer.

+ +

STEPHANIE: Cool. Well, I really appreciate your input on this because, you know, I was just kind of mulling over, like, how I felt about these kinds of things that I encounter as a developer. And I am glad that we got to kind of talk about it. And I think it gives me a more expanded vocabulary to, you know, analyze or reflect when I encounter these things on different client organizations.

+ +

JOËL: And every organization is different, right? Like, you've got to learn the culture, learn the different elements of that software. What are the things that are invariant? What are the things that are dangerous that we don't want to ship without? What are the things that we're doing just for consistency? What are things which are, like, these are culturally things that we'd like to do? There's all these levels, and it's a lot to pick up.

+ +

STEPHANIE: Yeah. At the end of the day, I think what I really liked about the last thing you said was being able to identify the problem, like the class of problem, and applying the right tool for the right job. It helps me take a step back and perhaps even think of different solutions that we might not have thought about earlier because we had just gotten so used to the one way of enforcing or checking things like that.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GNPFaVkt + + ]]> + + Joël Quenneville + Stephanie Minn + + + 423: Cognitive Strategies for Coders + https://bikeshed.thoughtbot.com/423 + 92230162-842b-4ce1-b0b9-764551f296f7 + Tue, 16 Apr 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie is back with a book recommendation: "Thinking in Systems" by Donella Meadows. This book has helped to bolster her understanding of complex systems in environmental, organizational, and software contexts, particularly through user interactions and system changes. Joël describes his transformative experience watching last week's total solar eclipse. + +Together, they explore how systems thinking influences software development and team dynamics by delving into practical applications in writing and reading code, suggesting that understanding complex systems can aid developers in navigating and optimizing codebases and team interactions. + 39:52 + no + + + Stephanie is back with a book recommendation: "Thinking in Systems" by Donella Meadows. This book has helped to bolster her understanding of complex systems in environmental, organizational, and software contexts, particularly through user interactions and system changes. Joël describes his transformative experience watching last week's total solar eclipse. +Together, they explore how systems thinking influences software development and team dynamics by delving into practical applications in writing and reading code, suggesting that understanding complex systems can aid developers in navigating and optimizing codebases and team interactions. +Thinking in Systems by Donella Meadows (https://www.chelseagreen.com/product/thinking-in-systems/) +Notetaking for developers episode (https://bikeshed.thoughtbot.com/357?t=0) +Call Graphs (https://en.wikipedia.org/wiki/Call_graph) +Flame Graphs (https://www.brendangregg.com/flamegraphs.html) +mermaid.live (https://mermaid.live/edit) +Obsidian (https://obsidian.md/) +rails-erd gem (https://github.com/voormedia/rails-erd) +Decision tables (https://www.hillelwayne.com/post/decision-table-patterns/) +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: I have a book recommendation today [laughs]. +JOËL: Oh, I love book recommendations. +STEPHANIE: It's been a little while, so I wanted to share what I've been reading that I think might be interesting to this audience. I'm reading Thinking in Systems by Donella Meadows. Joël, are you familiar with systems thinking theory at all? +JOËL: Very superficially. Hearing people talk about it on, I guess, X, now Twitter. +STEPHANIE: Yeah. Well, what I like about this book is the subtitle is A Primer on Thinking in Systems [chuckles], which is perfect for me as someone who also just kind of understood it very loosely, as just like, oh, like, I dunno, you look at things holistically and look at the stuff, not just its parts but from a higher perspective. +JOËL: Yeah. Is that accurate sort of your pre-book reading overview? Or do you think there's a bigger thing, a bigger idea there that the book unpacks? +STEPHANIE: Yeah. I think I'm only, like, a third of the way through so far. But what I have enjoyed about it is that, you know, in some ways, like, intuitively, that makes a lot of sense about, like, oh yeah, you want to make sure that you see the forest for the trees, right? +But one thing I've been surprised by is how it's also teaching me more technical language to talk about complex systems. And, in this case, she is talking about, essentially, living systems or systems that change over time where things are happening. I think that can be a little bit confusing when we also are, you know, talking about computer systems, but, in this case, you know, systems like environments, or communities, or even, you know, companies or organizations, which is actually where I'm finding a lot of the content really valuable. +But some of the language that I've learned that I am now trying to integrate a little bit more into how I view a lot of just, like, daily problems or experiences involve things like feedback loops that might be reinforcing or balancing and different, like, inputs and output flows and what is driving those things. So, I've appreciated just having more precise language for things that I think I kind of intuited but didn't exactly know how to, like, wrap up in a way to communicate to someone. +JOËL: Do you think the idea of thinking in terms of things like self-balancing versus sort of diverging input loops is something that's useful when actually writing code? Or do you think of it a little bit more in terms of, like, teams and how they organize general problem-solving approaches, things like that? +STEPHANIE: I think the answer is both. I actually gave this quite a bit of thought because I was trying to wrap my head around her definition of a system and how we talk about systems sometimes, like, a codebase, for example. And the conclusion I came to is that, really, it's not just the code static by itself that we care about. It's how it gets exercised, how users use it, how developers change it, how we interact with it when we, like, run tests, for example. +So, that was really helpful in kind of thinking about some of the problems we see in engineering organizations as a result of software being a thing that is used and written by humans, as opposed to it just existing in memories [chuckles] or, like, it's in a storage system somewhere. Like, that means it's kind of lifeless, and it's not changing anymore. But the point of kind of this framework is trying to understand it as it changes. +JOËL: So, kind of that blurry line between humans and computers and where those two overlap is where a lot of that systems thinking almost, like, mental model or vocabulary has been most helpful for you. +STEPHANIE: Yeah, I would say so. So, Joël, what's new in your world? +JOËL: So, I did the thing. I traveled to see the total solar eclipse this past weekend. It was mind-blowing. It was incredibly cool. I really loved it. For any of our listeners who have never seen a solar eclipse, in the coming years, have an opportunity to see one. I'd say it's worth traveling to see because it is really impressive. +STEPHANIE: Cool. What did it look like when it happened, when it was 100% eclipsed? +JOËL: So, what really impressed me was the fact that, like, most of the cool stuff happens in that, like, last half a percent. So, like, 95% eclipsed, still not that impressive. If that's all I'd seen, I would be disappointed. And then, in that last little bit, all of a sudden, everything goes dark. It's sort of, like, that twilight past sunset. You've got a glow on the horizon. The stars are out. +STEPHANIE: Wow. +JOËL: The animals are behaving like it's past sunset. They're getting ready to go to sleep. +STEPHANIE: Whoa. +JOËL: The sun itself is just a black dot with this, like, big fiery ring around it. Like all those pictures, icons, photos you see online, or drawings that look over the top, those things are real. That's what it looks like. +STEPHANIE: Wow, that's really neat. Could you see it without looking through the eclipse viewers? +JOËL: So, when you hit totality, you can look at it with a naked eye, and it is, yeah, magnificent. +STEPHANIE: Oh, that's so cool. How long did it last? +JOËL: So, it depends where you are in the path of totality. I was pretty much dead center. And it lasts, I think, three and a half minutes is what we had. +STEPHANIE: That's so cool. So, for me, here in Chicago, we did not have complete totality. It was about, like, 95%. So, I was watching it, just from that perspective. And I would say, yeah, it was not nearly as cool as what you described. It kind of just was like, oh, it got dark. It almost looked like I was viewing the world through sunglasses. +I did have one of those viewers that I used to, like, look at the sun and see how much of it had been covered. But yeah, it was cool. But what you said, I think now I feel like, wow, I really should have [laughter] traveled. I could have traveled just a few hours, you know, to, like, Indianapolis or something to have been on the path. That would have been really neat. And I don't think the next one will be until 2044 or something like that. +JOËL: Yeah. And that's the thing, right? I think if you're within a few hours of the path of a total eclipse, it is absolutely worth traveling to totality. The downside of that is that everybody else has the same idea. And so, you will be fighting traffic and a lot of things, especially if it goes through some, like, populated areas, like it did this time. +STEPHANIE: Yeah. Well, that's really neat that you got to see that. That's, I don't know, it sounds like not exactly once in a lifetime, but definitely very rare. +JOËL: For sure. I think with this experience now; I would definitely consider traveling again if there's one, like, anywhere near where I live, or, you know, maybe even, like, planning a vacation around going somewhere else to see one because it's short. You know, you're there for three minutes, and you see something cool. But that was really impressive. +So, something that really struck me when you were talking earlier about systems thinking is that you mentioned that it gave you a sort of a new vocabulary to talk about things. It almost gave you a sort of different way of thinking or some other mental models that you could use to apply when you are interacting in that sort of fussy boundary between people and code. +And I think that this idea of having language and having mental models is something that is incredibly valuable for us as programmers in a few different areas. And I'd be curious to see particularly for when we're reading other code, reading code that someone else has written or, you know, yourself from six months ago, do you have any sort of mental models that you like to reach for or techniques that you like to use to sort of give yourself that almost vocabulary to understand what somebody else is trying to do with their code? +STEPHANIE: Yeah, I would say so. You know, as you were talking about, like, how do you read code? I was thinking about how I read code is different from how I would read a book [laughs]. I almost rarely just read everything line by line and, like, file by file, you know, in some order that has been presented to me. I am usually a lot more involved. It's almost, like, more like a choose your own adventure kind of book [chuckles], where it's like, oh, go to this page to check if you want to check out what happened down this code path [chuckles]. +JOËL: Right, right. Oh, if you're reading a novel, are you the kind of person that will read the ending first? +STEPHANIE: Absolutely not. +[laughter] +JOËL: You have strong opinions here. +STEPHANIE: Even when I, like, really want to... okay, sometimes I will, like, maybe just kind of flip to the back and just see, like, oh, how many more pages or chapters do I have [laughs] left? If I am itching to know what might happen. But I definitely don't start a book by reading the end. I think there are people who do that, and maybe that works for them, but I don't understand it. +[laughter] +JOËL: But maybe that's the thing that you do with your code. +STEPHANIE: Yeah. When I read code, it's almost always with some kind of intention to understand a particular behavior, usually kind of kicked off by some action, like, done by the user or something automated. And I want to understand that process from start to finish. So, I'm less likely to read a whole class file [chuckles], as opposed to just following method and the messages that are sent along the way in a process. +JOËL: That makes sense. Do you tend to sort of go from kind of the origin point and then follow it down, or sort of the opposite, find some, like, terminal node and then work your way back? +STEPHANIE: Oh. +JOËL: And I could imagine this in a more concrete sense in a Rails app. You find, like, the route that you're going to hit because you know it's a URL, and then you find the controller, and then you read through the action. And then, you maybe follow a service and something like that or look into the view. Or maybe the opposite: there's a particular page that gets rendered. You look at a method, a helper method that gets called in a view, and then you sort of, like, follow a backtrace from there. +STEPHANIE: Yeah, I think both. It depends on what information I have available to me, I think. I can think of, recently, I was trying to figure out the process for which, like, a user in this application I'm working on can downgrade the tier of their account, and I didn't know what to grep for. And so, I asked, like, "Hey, like, what are the entry points for a user being able to do this?" +And someone gave me a couple of routes, and that was great because then I got to see, oh, that this is possible in multiple ways. Like, the user can do it themselves, or the admin can do it, and that was really helpful. Other times, I think I have been able to find a keyword on a page and start from, like, a view or a component, or something like that, and then work upwards. +JOËL: I love that question that you asked, "What are the entry points for this thing?" I feel like that's a fantastic question to sort of ask yourself when you're feeling stuck, but it's also a great question to ask other people that might know. +Do you find that you read code differently when you're just trying to, like, maybe understand a broader subsystem? Maybe you're sort of new to this area and you have to add a feature, as opposed to maybe you're debugging something and trying to understand why things went wrong. Are those two different kinds of reading? +STEPHANIE: Yeah, that's also a great point because I do think there's another time when I've just scanned the file structure of an app and looked at the model's directory and just kind of been like, okay, like, maybe some things are namespaced. And that helps me just know what the main concepts that I have to be dealing with or that I will be dealing with are. +But I find that sometimes less fruitful because of kind of what I mentioned earlier about thinking in systems, where I'm not sure how important those things will be yet because I don't know how they're used. They could not be used at all [laughs]. And then, I think I'm potentially, like, storing information that is not actually relevant in my brain. +JOËL: That's tough, right? Because systems are so big, we can't hold them entirely in our brain. So, sometimes, selectively deciding what will not be loaded in there is just as important as what will. +STEPHANIE: Yes. And I think that is actually advice that I would give to devs who are trying to get better at reading code. And this one's hard because when I am working with more early-career developers, it's hard to figure out, like, what are they seeing? How are they interpreting the code on the page? Because oftentimes, I see that they are getting stuck on the details, whereas I would like to encourage them to just be like, you don't really need to know what's going on in that method right now. Does the method name kind of communicate enough to you, like, what this thing is doing without having to understand all of the details? +But my advice would be to start figuring out what to ignore [laughs] because, like you said, it's impossible to, like, hold all of that information at one time. What do you think about that advice and, like, how do you teach that to someone? +JOËL: I think you're sort of hinting at two different ways of reducing the amount you have to load in your mind. The way I think about it, I think of it sort of spatially, so you can reduce the breadth of things you have to load into your head, so, realize, wait, there's all of these methods, and I don't need to know all of the methods in the file. There's only this one entry point I care about and everything downstream of that, and you just sort of prune everything off to the side, ignore it. That's not relevant right now. +But there's also sort of a depth. How deep of implementation do you really need to have? Maybe you only need to know about the high-level concepts. And then, you sort of, like, do this pruning where you say, "I'm not going to go deeper than this level," because the implementation is not really relevant to what I'm trying to understand right now. I mostly need to know what are these classes and how do they interact with each other? Or something along those lines. +And, ideally, you're may be doing a little bit of both. You probably don't need to go all the way to the deep implementation of every method, but you also don't necessarily need to know all of the high-level concepts and all of the objects in the system that interact. So, being able to prune in sort of both dimensions, breadth and depth, helps you to, I think, narrow the window of what you need to learn. +STEPHANIE: Yeah, that's a really great point. I have a couple more strategies that I just thought about as you were talking about that. One is kind of on the journey to let go of some things that I can't understand in the moment. If they seem important, I will write them down and, like, put them somewhere in a list to come back to later and be like, "This is a thing I don't fully understand yet," and just be okay with that. +I think, for me, there is some anxiety of like, oh, like, what if I'll need to know about it later? And at least putting it down somewhere as like, okay, like, I've done something with that anxious [laughs] energy of, like, recognizing that I don't understand this right now, and that's okay. But I can revisit it later. +And then, another one is almost the opposite, where it's like, what are my landmarks as I'm navigating through a codebase? Like, what are the files that I'm consistently opening? Because so many of the roads lead to this object. Even when I'm kind of going through different paths, it's like, I can hook into, like, the behavior that I'm looking for from these landmark objects or models because they are really important in this domain. So, it's like, I don't necessarily need to remember every step of the way, but if I can recall some of the more important methods, then I can kind of find my way back. +JOËL: Do you just try to, like, memorize those, or do you write them down? Like, how do you make a method or an object a landmark for you? +STEPHANIE: That has felt a little more, like, it becomes more, like, muscle memory, I think, because I'm revisiting them pretty frequently. I don't know, it's somehow the act of repeating, like, going through those files just gets encoded somewhere in my brain [laughs], and I don't have to worry as much about forgetting them. +JOËL: Strengthening that neural pathway. +STEPHANIE: Yeah, exactly. +JOËL: Or whatever is happening in the brain there. +STEPHANIE: [laughs] +JOËL: I like what you were saying earlier, though, about taking notes and sort of almost, like, a breadcrumbs approach. We did an episode almost two years ago where we talked about note-taking for various purposes and note-taking as an exploration exercise, and then note-taking when debugging, where we went deeper into that topic. And I think that would be really relevant to any of our listeners. We'll link that in the show notes. +STEPHANIE: Yeah. Leaving breadcrumbs. That's a great metaphor or just a way to describe it. Because I have a little shorthand for if I am leaving myself notes in a codebase as I'm trying to understand what's happening, and it's just, like, putting my initials in a comment and, like, including some observation or commentary about what I'm seeing or a question. +JOËL: Also, just a kind of meta observation here, but in the last, you know, 10-15 minutes we've been talking about this, we're already creating our own set of metaphors, and language, and mental models around understanding code. We're talking about breadcrumbs, and landmarks, and looking at code through a broad versus deep lens. That's exactly what we're talking about. +STEPHANIE: Joël, do you have any mental models that you use that we haven't really gotten into yet? +JOËL: I don't know if they're mental models per se, but I lean very heavily into diagramming as a form of understanding code. And maybe that's a way of sort of reducing the number of concepts because instead of now sort of thinking in terms of, like, lines of code, I'm thinking in terms of maybe some boxes and arrows, and that's a much higher-level way of looking at a system and can give me some really interesting insights. +And there are a ton of different diagrams you can use for different things, and I guess all of them are based on a different maybe mental model of what a system is. So, for example, I might actually write out the method call graph starting from some endpoint and just sort of saying, "Hey, when I call this method, what are all of the methods downstream that get called? And is there anything interesting at any of those steps?" + Variation on that if you're looking at, let's say, some kind of performance thing would be, like, a flame graph where you have sort of that but then it also shows you the amount of time spent in each of the methods. And that can give you a sense of where your bottlenecks are. +Another one that I really like is thinking in terms of a finite state machine. So, sort of following data, how does it change in response to different events that can come into the system? And I'm not talking about, oh, you're using one of the, like, state machine gems out there for your Rails app. This is more of a way of thinking about programs and how they act. +You can have just a plain, old Rails app, and you're thinking about, okay, well, how does a cart turn into an order, turn into a fulfillment request at the warehouse, turns into a tracking number for shipping? Modeling that as a state machine. And also, you know, can it move back along that path, or is it only linear move forward? Any kind of multi-state form a wizard often has paths where you move back. It's not linear. That very easily can be drawn out as a state machine. So, that is something that I really like to pull out when I'm trying to understand a, like, complex workflow. +STEPHANIE: Yeah, I think we've talked about this before a little bit, or maybe not even a little bit, a lot [laughs]. But I know that you're a big fan of Mermaid.js for creating diagrams in markdown that can be embedded in a pull request description or even in a commit message. When I was hearing you talk about state machines and just all the different paths that can lead to different states, I was like, I bet that's something that you would create using a diagram and stick for yourself and others when sharing code. +JOËL: Yes, Mermaid does support state machines as a graph type, which is really cool. +Another thing that you can do is embed those in tools like Obsidian, which is my current note-taking tool. So, if I'm doing some sort of notes as a sort of exploratory tool, I will often start writing a Mermaid graph directly in line, and it will render and everything. That's really nice. If I'm not in Obsidian and I just need some sort of one-off graph, I'll often lean on Mermaid.live, which just gives you an editor where you can write up some Mermaid code. It will render it, and then you can copy the PNG into somewhere else and share that with other people. So, if I just need a one-off thing to share in Slack or something like that, I like to lean on that. +Another type of diagram that I use pretty frequently is an entity-relationship diagram, so sort of what database tables are related to what others. On larger apps, there's just so many tables, and maybe a bunch of JOINS and things like that, and it's sometimes difficult to get the picture of what is happening, so I'll often draw out a graph of those. Now, it's not worth doing the entire database because that will be huge and overwhelming. So, I'll find, like, five or six tables that are relevant to me and then try to answer the question: How are they related to each other? +STEPHANIE: Yeah, I like that. I was going to ask if you do it manually or if you use a tool because I've worked in various apps that have used the Rails ERD gem that will generate an entity-relationship diagram for you every time the schema changes. But there's something very compelling, to me, about the idea of trying to just figure out if you know the relationships, if you could draw them out, as opposed to having a tool do it for you. +JOËL: Exactly. +STEPHANIE: And I think, like, also, you do have information that might not be encoded in the system. Like, you actually know, oh, these two tables are related, even if no one has defined an association on them. I think that is important in understanding actually how the system is working in real life, I guess. +JOËL: Agreed. So, we've been talking a lot about how we can use different tools, different mental models to take code that somebody else has written and kind of, like, almost read it from disk and load it into our brains. But what about the opposite? We're faced with a business problem, and we want to sort of write it to disk, turn it into code that somebody else will then read or that a machine will execute. I hear that happens occasionally. Are there sort of mental models or ways of approaching tackling a more, like, amorphous problem in the real world and turning that into code? Like, are they just the inverse of what we do when we read code, or are they, like, totally different set of skills? +STEPHANIE: For me personally, I don't follow this framework very strictly, but I think more intuitively how I like to go about it is more behavior-driven where...because that is the language of maybe our cross-functional partners. They're saying like, "Hey, like, when this happens, I want to be able to do this," and I kind of start there. Maybe I'll pick up some of the keywords that they're repeating pretty frequently as like, oh, like, this is a concept. +Actually, lately, the past couple of weeks, I've been test-driving almost all of my code as I work on a totally, like, greenfield feature. And that has been working really well for me, I think, because we did explore more granular, both, like, granular and abstract concepts when we were spiking this feature. And so, we had come up with some domain models. I had kind of thought about, like, how they might interact with each other. +But when you then have to actually, like, code that, there are so many little nuances and things to keep track of that I found test driving things from, like, behavior and user stories. Those are really helpful in keeping me, like, on track to making sure that I didn't just have all these little pieces of domain concepts that then didn't really interact in a meaningful way. +JOËL: Yeah, the sort of very, like, user or customer-centric approach to thinking about what is this app doing? Is a great way to think about it. And I guess the sort of translation of that, that first step of translation into code is some sort of, like, system spec. +STEPHANIE: Yeah, exactly. +JOËL: I like that because, you know, we have all these other abstractions that we use as developers. But at the end of the day, our customers and even, you know, our product people aren't thinking in terms of, like, objects and classes and all these other fun abstractions that we have. They're thinking in terms of behaviors and, you know, maybe subsystems, workflows, things like that. And then it's up to us to translate that into whatever paradigm of our language that we're using. +STEPHANIE: Do you do things differently from me? +JOËL: I don't think that I do it necessarily differently. I think it's one of several tools I have in my tool belt. Something that is similar but from a slightly different angle is inspiring myself with a lot of the ideas from domain-driven design. You know, we've been talking a lot about this idea of, like, mental models and having a vocabulary, things like that, about sort of the way that we work, but that exists at the product level as well. And what if we could encode a lot of that into our application itself? +So, is there a distinction between a subscriber and a payer in our system? Is there specialized vocabulary around different other concepts in the app? Maybe instead of just having those be things that product people talk about, what if we made them actual named entities in the system and have maybe our object graph, at least in some way, reflect the sort of idealized model of what our business actually does? +That often means that you're thinking of things at a higher level because you're thinking of things at the level that our product people are thinking about them. You might be thinking of things in terms of user journeys, or product workflows, or things like that, because you say, "Oh, well, a new payer has been added to this group account. And that has started a subscription, which then means that a user has access to these corporate features that they didn't have when they were in a solo account." +Like, I've just thrown ten different sort of product terms out there that, you know, if there are concepts in our code can help us think about less of the implementation. What does the app do, or how does the app do it? And more in terms of, like, product terms, what does the app do? How do people experience the behavior, or maybe how does data change over the life cycle of the app? So, those perspectives, I think, have helped me distill down sort of more vague product ideas into things that I can then start turning into code. +STEPHANIE: Absolutely. I think one way that this framework ends up falling short, at least for me a little bit sometimes, is making connections between behaviors that are similar but not exactly the same. Or when you think about them in more isolated ways, like, it's easy to miss that, like, they are the same idea and that there is, like, something a bit higher level that you can connect them, that you can create a more abstract class for, even though that's not actually how people talk about the things. +One example I can think of is things like concerns that are both related to domain language but then also, like, kind of specific to how things work in the code as a system because you might not necessarily call something a subscribable from a product perspective. Do you have any thoughts about identifying those pieces? +JOËL: So, what's interesting is I think there's a little bit of, like, layers above and below, the sort of domain layer where you're talking in terms of, like, what the product team would use. When you're doing a lot of the implementation, there will be things that are just, like, that's how we implemented them. They're in the nitty gritty, and they're not terms that the product team would necessarily use. +Things like array and string they're low-level details. We have to use them. That's not really relevant to the world of payers, and subscribers, and things like that. So, they're sort of lower layer. And I think that's totally fine to have things where we sort of have things that are sort of programmer only, as long as they're sort of contained within this higher-level layer because that allows people new to the app to sort of see what are the different things in the application to think about things in a higher level. +It also allows for smoother communication with the product team. So, ideally, you don't have a concept in the app that is the same as something that the product team, but you just both gave it different names, and then that's really annoying. Or maybe the dev team created something that's, like, almost exactly the same as what the product team talks about, but with some, like, slight variations. Now, you're just going to be talking past each other in every planning meeting, and that will be incredibly annoying. +STEPHANIE: Yeah. At one point, when I was trying to communicate, like, async about how a feature works, and there was like the product word for it and then the dev word for it, I would have to type out both [chuckles] because I wanted to make sure that no one was confused about what we were talking about, which was the same thing that just had two names. And yeah, I don't know how many seconds of my life I'll never get back as a result [chuckles]. +JOËL: Were these concepts that were identical and had just different names, or was this like, oh, well, our internal subscribed user is almost the same as when product talks about and, I don't know, employee, but our subscribed user has a couple of other extra behaviors that employees don't have, and now there's, like, this weird, like, overlap? +STEPHANIE: Yeah, both situations I have found myself in, but I think this one they were virtually identical. Like, they could be used interchangeably to mean the same thing by people who understand both of those definitions, but the problem was that we still had two words [laughs]. +JOËL: Yeah, yeah. I'm a big fan of, where possible, converging on the product team's definition. Although because code forces you to be more precise, sometimes that can then force some conversations with the product team about, like, "Hey, so we've been hand waving around this concept of a subscriber. Turns out we think there's actually two different kinds of concepts at work here: the person who's consuming the content and the person who's paying for it. And are they really the same thing, or should we sort of think about these as two different entities? And, in that case, what should the name be?" And that can force a really, I think, healthy conversation between development and product. +STEPHANIE: Yeah, I like that. You mentioned there was, like, a higher level and a lower level, but I don't think we've gotten to the higher one yet. +JOËL: Yeah. Sometimes, you want to build abstraction sort of over. You're talking about the idea of, like, subscribable things. I think that's where I'm a lot fuzzier. It's much more case-by-case. Where possible, I'd like to introduce some of those things as domain vocabulary so that we'd say, "Well, look, we have a, like, family of products, and they're all subscribable." And maybe, like, the adjective doesn't matter quite as much to our product people, but, you know, because we're using a module in Ruby, we want to lean into the adjective form, and that's fine. But I would at least want some loose connection there. +STEPHANIE: Yeah, that makes sense because I think that ultimately makes for a better product. If we're thinking about, like, how to present a hierarchy of information to a user, like a navigation menu, we would want to group those things that are under that family together, ideally, so that they know how to interact with it. +JOËL: Another thing that I think falls maybe under, like, this higher-level umbrella are things like design patterns. So, maybe because we want to be able to sort of, like, swap things in and out, we're using some form of strategy pattern. That feels like maybe it's a little bit higher level. It interacts with a lot of the domain concepts, but our product team doesn't really need to think in terms of, like, oh, strategies, and swappable things, and, like, flex points in your architecture. So, those would not necessarily be domain vocabulary. Although I could see, like, maybe there's a way where they do get a domain name, and that's great. +STEPHANIE: Oh, I think maybe this is where I disagree with you a little bit. Well, actually, I agreed with what you said at the end [laughs] in terms of how maybe they should be part of the domain vocabulary because I think...I've seen product not fully understand the complexity of the application as it grows over time. And that can lead to sometimes, like, not as great product experience or experience for the user, like, interacting with this product. +And maybe that is something we want to, as developers, if we're starting to see and feel and have maybe even introduced a pattern for...I can't claim to have done this too much, but it's definitely a skill I want to hone in on. But, like, how do I communicate to product folks so that we understand, oh, like, where is it possible for these different types of a subscriber to diverge? Because that is important, I think, in determining the future of a product and, like, where we want to invest in it and where we should focus, like, new features. +JOËL: And oftentimes, when there is that kind of divergence, there probably will be some sort of product-level thinking that needs to happen there. Are we saying, "Hey, we have one of three types of subscribers, and we want to think about that"? Or maybe we want to say, "We have three different ways of processing an application." Maybe it's derived automatically. Maybe it's a dropdown that you have to pick. But let's say it's a dropdown. What do we name that dropdown with the, like, kind of processing that we want to do to an application? The thing that we want to name that dropdown that's probably a good name for that, like, group of strategies, assuming we implement with a strategy pattern. Maybe we're doing it differently. +STEPHANIE: Yeah. The more you talk about that, the more I'm convinced that that's, like, the way I want to be working at least, because you have to know what's there in order to, like, name it. You know, you have to face it, essentially [laughs]. Whereas I think a lot of applications I've worked on fall into the trap of all of those things are obscured way down in the depths of the user flow, where it's like, oh, suddenly, for some reason, you can, like, have a dropdown here that totally changes the behavior, even though you've gotten this far in either the stack trace or even just, like the user journey, as I know you like to branch early in your code. +JOËL: [laughs]. +STEPHANIE: But you should also branch early from a user's experience [laughs]. +JOËL: In general, I'm just a big fan of having a communication loop between development and product, not only sort of receiving a lot of useful information from the product team about what we want to build. But then because we're encountering this more, like, technical spec that we're writing, have those conversations bubble back to product and say, "Hey, so we talked about a dropdown where there are sort of three different ways of processing an application. Let's talk a little bit more about what it means to have three different ways of processing. And what do we want to name that? Is that accessible to everyone, or are they sort of one-to-one tied with a type of user?" +And all of a sudden, that has just generated probably a lot of questions that product never even thought to ask because they're working on an infinite canvas of possibilities. And it's really helped you as a developer to have better names to write your code and sort of better sketch out the boundaries of the problem you're trying to solve. So, I think it's a really healthy loop to have. I strongly encourage it. +So, we've spent a lot of time talking about thinking about behavior and things like the domain-driven design movement. But a few other things I want to shout out as being really helpful, one is an exercise where you take a problem statement and just underline all of the nouns. That is a great way to get a sense of, like, what is going on here. +More generally, I think a lot of what we're talking about falls under the umbrella of what you might call analysis. And so, digging into different analytic techniques can be a great way to better understand the problem that you're working through. One such tool would be decision tables. So, you have a problem, and you say, "Well, given these inputs, what should the outputs be?" +STEPHANIE: Cool. If there were any techniques or tools that we missed in terms of how you load code in your brain or generate code from your brain [laughs], we would love to know. You can write in to us at hosts@bikeshed.fm. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + + Stephanie is back with a book recommendation: "Thinking in Systems" by Donella Meadows. This book has helped to bolster her understanding of complex systems in environmental, organizational, and software contexts, particularly through user interactions and system changes. Joël describes his transformative experience watching last week's total solar eclipse.

+ +

Together, they explore how systems thinking influences software development and team dynamics by delving into practical applications in writing and reading code, suggesting that understanding complex systems can aid developers in navigating and optimizing codebases and team interactions.

+ + + +

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: I have a book recommendation today [laughs].

+ +

JOËL: Oh, I love book recommendations.

+ +

STEPHANIE: It's been a little while, so I wanted to share what I've been reading that I think might be interesting to this audience. I'm reading Thinking in Systems by Donella Meadows. Joël, are you familiar with systems thinking theory at all?

+ +

JOËL: Very superficially. Hearing people talk about it on, I guess, X, now Twitter.

+ +

STEPHANIE: Yeah. Well, what I like about this book is the subtitle is A Primer on Thinking in Systems [chuckles], which is perfect for me as someone who also just kind of understood it very loosely, as just like, oh, like, I dunno, you look at things holistically and look at the stuff, not just its parts but from a higher perspective.

+ +

JOËL: Yeah. Is that accurate sort of your pre-book reading overview? Or do you think there's a bigger thing, a bigger idea there that the book unpacks?

+ +

STEPHANIE: Yeah. I think I'm only, like, a third of the way through so far. But what I have enjoyed about it is that, you know, in some ways, like, intuitively, that makes a lot of sense about, like, oh yeah, you want to make sure that you see the forest for the trees, right?

+ +

But one thing I've been surprised by is how it's also teaching me more technical language to talk about complex systems. And, in this case, she is talking about, essentially, living systems or systems that change over time where things are happening. I think that can be a little bit confusing when we also are, you know, talking about computer systems, but, in this case, you know, systems like environments, or communities, or even, you know, companies or organizations, which is actually where I'm finding a lot of the content really valuable.

+ +

But some of the language that I've learned that I am now trying to integrate a little bit more into how I view a lot of just, like, daily problems or experiences involve things like feedback loops that might be reinforcing or balancing and different, like, inputs and output flows and what is driving those things. So, I've appreciated just having more precise language for things that I think I kind of intuited but didn't exactly know how to, like, wrap up in a way to communicate to someone.

+ +

JOËL: Do you think the idea of thinking in terms of things like self-balancing versus sort of diverging input loops is something that's useful when actually writing code? Or do you think of it a little bit more in terms of, like, teams and how they organize general problem-solving approaches, things like that?

+ +

STEPHANIE: I think the answer is both. I actually gave this quite a bit of thought because I was trying to wrap my head around her definition of a system and how we talk about systems sometimes, like, a codebase, for example. And the conclusion I came to is that, really, it's not just the code static by itself that we care about. It's how it gets exercised, how users use it, how developers change it, how we interact with it when we, like, run tests, for example.

+ +

So, that was really helpful in kind of thinking about some of the problems we see in engineering organizations as a result of software being a thing that is used and written by humans, as opposed to it just existing in memories [chuckles] or, like, it's in a storage system somewhere. Like, that means it's kind of lifeless, and it's not changing anymore. But the point of kind of this framework is trying to understand it as it changes.

+ +

JOËL: So, kind of that blurry line between humans and computers and where those two overlap is where a lot of that systems thinking almost, like, mental model or vocabulary has been most helpful for you.

+ +

STEPHANIE: Yeah, I would say so. So, Joël, what's new in your world?

+ +

JOËL: So, I did the thing. I traveled to see the total solar eclipse this past weekend. It was mind-blowing. It was incredibly cool. I really loved it. For any of our listeners who have never seen a solar eclipse, in the coming years, have an opportunity to see one. I'd say it's worth traveling to see because it is really impressive.

+ +

STEPHANIE: Cool. What did it look like when it happened, when it was 100% eclipsed?

+ +

JOËL: So, what really impressed me was the fact that, like, most of the cool stuff happens in that, like, last half a percent. So, like, 95% eclipsed, still not that impressive. If that's all I'd seen, I would be disappointed. And then, in that last little bit, all of a sudden, everything goes dark. It's sort of, like, that twilight past sunset. You've got a glow on the horizon. The stars are out.

+ +

STEPHANIE: Wow.

+ +

JOËL: The animals are behaving like it's past sunset. They're getting ready to go to sleep.

+ +

STEPHANIE: Whoa.

+ +

JOËL: The sun itself is just a black dot with this, like, big fiery ring around it. Like all those pictures, icons, photos you see online, or drawings that look over the top, those things are real. That's what it looks like.

+ +

STEPHANIE: Wow, that's really neat. Could you see it without looking through the eclipse viewers?

+ +

JOËL: So, when you hit totality, you can look at it with a naked eye, and it is, yeah, magnificent.

+ +

STEPHANIE: Oh, that's so cool. How long did it last?

+ +

JOËL: So, it depends where you are in the path of totality. I was pretty much dead center. And it lasts, I think, three and a half minutes is what we had.

+ +

STEPHANIE: That's so cool. So, for me, here in Chicago, we did not have complete totality. It was about, like, 95%. So, I was watching it, just from that perspective. And I would say, yeah, it was not nearly as cool as what you described. It kind of just was like, oh, it got dark. It almost looked like I was viewing the world through sunglasses.

+ +

I did have one of those viewers that I used to, like, look at the sun and see how much of it had been covered. But yeah, it was cool. But what you said, I think now I feel like, wow, I really should have [laughter] traveled. I could have traveled just a few hours, you know, to, like, Indianapolis or something to have been on the path. That would have been really neat. And I don't think the next one will be until 2044 or something like that.

+ +

JOËL: Yeah. And that's the thing, right? I think if you're within a few hours of the path of a total eclipse, it is absolutely worth traveling to totality. The downside of that is that everybody else has the same idea. And so, you will be fighting traffic and a lot of things, especially if it goes through some, like, populated areas, like it did this time.

+ +

STEPHANIE: Yeah. Well, that's really neat that you got to see that. That's, I don't know, it sounds like not exactly once in a lifetime, but definitely very rare.

+ +

JOËL: For sure. I think with this experience now; I would definitely consider traveling again if there's one, like, anywhere near where I live, or, you know, maybe even, like, planning a vacation around going somewhere else to see one because it's short. You know, you're there for three minutes, and you see something cool. But that was really impressive.

+ +

So, something that really struck me when you were talking earlier about systems thinking is that you mentioned that it gave you a sort of a new vocabulary to talk about things. It almost gave you a sort of different way of thinking or some other mental models that you could use to apply when you are interacting in that sort of fussy boundary between people and code.

+ +

And I think that this idea of having language and having mental models is something that is incredibly valuable for us as programmers in a few different areas. And I'd be curious to see particularly for when we're reading other code, reading code that someone else has written or, you know, yourself from six months ago, do you have any sort of mental models that you like to reach for or techniques that you like to use to sort of give yourself that almost vocabulary to understand what somebody else is trying to do with their code?

+ +

STEPHANIE: Yeah, I would say so. You know, as you were talking about, like, how do you read code? I was thinking about how I read code is different from how I would read a book [laughs]. I almost rarely just read everything line by line and, like, file by file, you know, in some order that has been presented to me. I am usually a lot more involved. It's almost, like, more like a choose your own adventure kind of book [chuckles], where it's like, oh, go to this page to check if you want to check out what happened down this code path [chuckles].

+ +

JOËL: Right, right. Oh, if you're reading a novel, are you the kind of person that will read the ending first?

+ +

STEPHANIE: Absolutely not.

+ +

[laughter]

+ +

JOËL: You have strong opinions here.

+ +

STEPHANIE: Even when I, like, really want to... okay, sometimes I will, like, maybe just kind of flip to the back and just see, like, oh, how many more pages or chapters do I have [laughs] left? If I am itching to know what might happen. But I definitely don't start a book by reading the end. I think there are people who do that, and maybe that works for them, but I don't understand it.

+ +

[laughter]

+ +

JOËL: But maybe that's the thing that you do with your code.

+ +

STEPHANIE: Yeah. When I read code, it's almost always with some kind of intention to understand a particular behavior, usually kind of kicked off by some action, like, done by the user or something automated. And I want to understand that process from start to finish. So, I'm less likely to read a whole class file [chuckles], as opposed to just following method and the messages that are sent along the way in a process.

+ +

JOËL: That makes sense. Do you tend to sort of go from kind of the origin point and then follow it down, or sort of the opposite, find some, like, terminal node and then work your way back?

+ +

STEPHANIE: Oh.

+ +

JOËL: And I could imagine this in a more concrete sense in a Rails app. You find, like, the route that you're going to hit because you know it's a URL, and then you find the controller, and then you read through the action. And then, you maybe follow a service and something like that or look into the view. Or maybe the opposite: there's a particular page that gets rendered. You look at a method, a helper method that gets called in a view, and then you sort of, like, follow a backtrace from there.

+ +

STEPHANIE: Yeah, I think both. It depends on what information I have available to me, I think. I can think of, recently, I was trying to figure out the process for which, like, a user in this application I'm working on can downgrade the tier of their account, and I didn't know what to grep for. And so, I asked, like, "Hey, like, what are the entry points for a user being able to do this?"

+ +

And someone gave me a couple of routes, and that was great because then I got to see, oh, that this is possible in multiple ways. Like, the user can do it themselves, or the admin can do it, and that was really helpful. Other times, I think I have been able to find a keyword on a page and start from, like, a view or a component, or something like that, and then work upwards.

+ +

JOËL: I love that question that you asked, "What are the entry points for this thing?" I feel like that's a fantastic question to sort of ask yourself when you're feeling stuck, but it's also a great question to ask other people that might know.

+ +

Do you find that you read code differently when you're just trying to, like, maybe understand a broader subsystem? Maybe you're sort of new to this area and you have to add a feature, as opposed to maybe you're debugging something and trying to understand why things went wrong. Are those two different kinds of reading?

+ +

STEPHANIE: Yeah, that's also a great point because I do think there's another time when I've just scanned the file structure of an app and looked at the model's directory and just kind of been like, okay, like, maybe some things are namespaced. And that helps me just know what the main concepts that I have to be dealing with or that I will be dealing with are.

+ +

But I find that sometimes less fruitful because of kind of what I mentioned earlier about thinking in systems, where I'm not sure how important those things will be yet because I don't know how they're used. They could not be used at all [laughs]. And then, I think I'm potentially, like, storing information that is not actually relevant in my brain.

+ +

JOËL: That's tough, right? Because systems are so big, we can't hold them entirely in our brain. So, sometimes, selectively deciding what will not be loaded in there is just as important as what will.

+ +

STEPHANIE: Yes. And I think that is actually advice that I would give to devs who are trying to get better at reading code. And this one's hard because when I am working with more early-career developers, it's hard to figure out, like, what are they seeing? How are they interpreting the code on the page? Because oftentimes, I see that they are getting stuck on the details, whereas I would like to encourage them to just be like, you don't really need to know what's going on in that method right now. Does the method name kind of communicate enough to you, like, what this thing is doing without having to understand all of the details?

+ +

But my advice would be to start figuring out what to ignore [laughs] because, like you said, it's impossible to, like, hold all of that information at one time. What do you think about that advice and, like, how do you teach that to someone?

+ +

JOËL: I think you're sort of hinting at two different ways of reducing the amount you have to load in your mind. The way I think about it, I think of it sort of spatially, so you can reduce the breadth of things you have to load into your head, so, realize, wait, there's all of these methods, and I don't need to know all of the methods in the file. There's only this one entry point I care about and everything downstream of that, and you just sort of prune everything off to the side, ignore it. That's not relevant right now.

+ +

But there's also sort of a depth. How deep of implementation do you really need to have? Maybe you only need to know about the high-level concepts. And then, you sort of, like, do this pruning where you say, "I'm not going to go deeper than this level," because the implementation is not really relevant to what I'm trying to understand right now. I mostly need to know what are these classes and how do they interact with each other? Or something along those lines.

+ +

And, ideally, you're may be doing a little bit of both. You probably don't need to go all the way to the deep implementation of every method, but you also don't necessarily need to know all of the high-level concepts and all of the objects in the system that interact. So, being able to prune in sort of both dimensions, breadth and depth, helps you to, I think, narrow the window of what you need to learn.

+ +

STEPHANIE: Yeah, that's a really great point. I have a couple more strategies that I just thought about as you were talking about that. One is kind of on the journey to let go of some things that I can't understand in the moment. If they seem important, I will write them down and, like, put them somewhere in a list to come back to later and be like, "This is a thing I don't fully understand yet," and just be okay with that.

+ +

I think, for me, there is some anxiety of like, oh, like, what if I'll need to know about it later? And at least putting it down somewhere as like, okay, like, I've done something with that anxious [laughs] energy of, like, recognizing that I don't understand this right now, and that's okay. But I can revisit it later.

+ +

And then, another one is almost the opposite, where it's like, what are my landmarks as I'm navigating through a codebase? Like, what are the files that I'm consistently opening? Because so many of the roads lead to this object. Even when I'm kind of going through different paths, it's like, I can hook into, like, the behavior that I'm looking for from these landmark objects or models because they are really important in this domain. So, it's like, I don't necessarily need to remember every step of the way, but if I can recall some of the more important methods, then I can kind of find my way back.

+ +

JOËL: Do you just try to, like, memorize those, or do you write them down? Like, how do you make a method or an object a landmark for you?

+ +

STEPHANIE: That has felt a little more, like, it becomes more, like, muscle memory, I think, because I'm revisiting them pretty frequently. I don't know, it's somehow the act of repeating, like, going through those files just gets encoded somewhere in my brain [laughs], and I don't have to worry as much about forgetting them.

+ +

JOËL: Strengthening that neural pathway.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: Or whatever is happening in the brain there.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I like what you were saying earlier, though, about taking notes and sort of almost, like, a breadcrumbs approach. We did an episode almost two years ago where we talked about note-taking for various purposes and note-taking as an exploration exercise, and then note-taking when debugging, where we went deeper into that topic. And I think that would be really relevant to any of our listeners. We'll link that in the show notes.

+ +

STEPHANIE: Yeah. Leaving breadcrumbs. That's a great metaphor or just a way to describe it. Because I have a little shorthand for if I am leaving myself notes in a codebase as I'm trying to understand what's happening, and it's just, like, putting my initials in a comment and, like, including some observation or commentary about what I'm seeing or a question.

+ +

JOËL: Also, just a kind of meta observation here, but in the last, you know, 10-15 minutes we've been talking about this, we're already creating our own set of metaphors, and language, and mental models around understanding code. We're talking about breadcrumbs, and landmarks, and looking at code through a broad versus deep lens. That's exactly what we're talking about.

+ +

STEPHANIE: Joël, do you have any mental models that you use that we haven't really gotten into yet?

+ +

JOËL: I don't know if they're mental models per se, but I lean very heavily into diagramming as a form of understanding code. And maybe that's a way of sort of reducing the number of concepts because instead of now sort of thinking in terms of, like, lines of code, I'm thinking in terms of maybe some boxes and arrows, and that's a much higher-level way of looking at a system and can give me some really interesting insights.

+ +

And there are a ton of different diagrams you can use for different things, and I guess all of them are based on a different maybe mental model of what a system is. So, for example, I might actually write out the method call graph starting from some endpoint and just sort of saying, "Hey, when I call this method, what are all of the methods downstream that get called? And is there anything interesting at any of those steps?"

+ +

Variation on that if you're looking at, let's say, some kind of performance thing would be, like, a flame graph where you have sort of that but then it also shows you the amount of time spent in each of the methods. And that can give you a sense of where your bottlenecks are.

+ +

Another one that I really like is thinking in terms of a finite state machine. So, sort of following data, how does it change in response to different events that can come into the system? And I'm not talking about, oh, you're using one of the, like, state machine gems out there for your Rails app. This is more of a way of thinking about programs and how they act.

+ +

You can have just a plain, old Rails app, and you're thinking about, okay, well, how does a cart turn into an order, turn into a fulfillment request at the warehouse, turns into a tracking number for shipping? Modeling that as a state machine. And also, you know, can it move back along that path, or is it only linear move forward? Any kind of multi-state form a wizard often has paths where you move back. It's not linear. That very easily can be drawn out as a state machine. So, that is something that I really like to pull out when I'm trying to understand a, like, complex workflow.

+ +

STEPHANIE: Yeah, I think we've talked about this before a little bit, or maybe not even a little bit, a lot [laughs]. But I know that you're a big fan of Mermaid.js for creating diagrams in markdown that can be embedded in a pull request description or even in a commit message. When I was hearing you talk about state machines and just all the different paths that can lead to different states, I was like, I bet that's something that you would create using a diagram and stick for yourself and others when sharing code.

+ +

JOËL: Yes, Mermaid does support state machines as a graph type, which is really cool.

+ +

Another thing that you can do is embed those in tools like Obsidian, which is my current note-taking tool. So, if I'm doing some sort of notes as a sort of exploratory tool, I will often start writing a Mermaid graph directly in line, and it will render and everything. That's really nice. If I'm not in Obsidian and I just need some sort of one-off graph, I'll often lean on Mermaid.live, which just gives you an editor where you can write up some Mermaid code. It will render it, and then you can copy the PNG into somewhere else and share that with other people. So, if I just need a one-off thing to share in Slack or something like that, I like to lean on that.

+ +

Another type of diagram that I use pretty frequently is an entity-relationship diagram, so sort of what database tables are related to what others. On larger apps, there's just so many tables, and maybe a bunch of JOINS and things like that, and it's sometimes difficult to get the picture of what is happening, so I'll often draw out a graph of those. Now, it's not worth doing the entire database because that will be huge and overwhelming. So, I'll find, like, five or six tables that are relevant to me and then try to answer the question: How are they related to each other?

+ +

STEPHANIE: Yeah, I like that. I was going to ask if you do it manually or if you use a tool because I've worked in various apps that have used the Rails ERD gem that will generate an entity-relationship diagram for you every time the schema changes. But there's something very compelling, to me, about the idea of trying to just figure out if you know the relationships, if you could draw them out, as opposed to having a tool do it for you.

+ +

JOËL: Exactly.

+ +

STEPHANIE: And I think, like, also, you do have information that might not be encoded in the system. Like, you actually know, oh, these two tables are related, even if no one has defined an association on them. I think that is important in understanding actually how the system is working in real life, I guess.

+ +

JOËL: Agreed. So, we've been talking a lot about how we can use different tools, different mental models to take code that somebody else has written and kind of, like, almost read it from disk and load it into our brains. But what about the opposite? We're faced with a business problem, and we want to sort of write it to disk, turn it into code that somebody else will then read or that a machine will execute. I hear that happens occasionally. Are there sort of mental models or ways of approaching tackling a more, like, amorphous problem in the real world and turning that into code? Like, are they just the inverse of what we do when we read code, or are they, like, totally different set of skills?

+ +

STEPHANIE: For me personally, I don't follow this framework very strictly, but I think more intuitively how I like to go about it is more behavior-driven where...because that is the language of maybe our cross-functional partners. They're saying like, "Hey, like, when this happens, I want to be able to do this," and I kind of start there. Maybe I'll pick up some of the keywords that they're repeating pretty frequently as like, oh, like, this is a concept.

+ +

Actually, lately, the past couple of weeks, I've been test-driving almost all of my code as I work on a totally, like, greenfield feature. And that has been working really well for me, I think, because we did explore more granular, both, like, granular and abstract concepts when we were spiking this feature. And so, we had come up with some domain models. I had kind of thought about, like, how they might interact with each other.

+ +

But when you then have to actually, like, code that, there are so many little nuances and things to keep track of that I found test driving things from, like, behavior and user stories. Those are really helpful in keeping me, like, on track to making sure that I didn't just have all these little pieces of domain concepts that then didn't really interact in a meaningful way.

+ +

JOËL: Yeah, the sort of very, like, user or customer-centric approach to thinking about what is this app doing? Is a great way to think about it. And I guess the sort of translation of that, that first step of translation into code is some sort of, like, system spec.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I like that because, you know, we have all these other abstractions that we use as developers. But at the end of the day, our customers and even, you know, our product people aren't thinking in terms of, like, objects and classes and all these other fun abstractions that we have. They're thinking in terms of behaviors and, you know, maybe subsystems, workflows, things like that. And then it's up to us to translate that into whatever paradigm of our language that we're using.

+ +

STEPHANIE: Do you do things differently from me?

+ +

JOËL: I don't think that I do it necessarily differently. I think it's one of several tools I have in my tool belt. Something that is similar but from a slightly different angle is inspiring myself with a lot of the ideas from domain-driven design. You know, we've been talking a lot about this idea of, like, mental models and having a vocabulary, things like that, about sort of the way that we work, but that exists at the product level as well. And what if we could encode a lot of that into our application itself?

+ +

So, is there a distinction between a subscriber and a payer in our system? Is there specialized vocabulary around different other concepts in the app? Maybe instead of just having those be things that product people talk about, what if we made them actual named entities in the system and have maybe our object graph, at least in some way, reflect the sort of idealized model of what our business actually does?

+ +

That often means that you're thinking of things at a higher level because you're thinking of things at the level that our product people are thinking about them. You might be thinking of things in terms of user journeys, or product workflows, or things like that, because you say, "Oh, well, a new payer has been added to this group account. And that has started a subscription, which then means that a user has access to these corporate features that they didn't have when they were in a solo account."

+ +

Like, I've just thrown ten different sort of product terms out there that, you know, if there are concepts in our code can help us think about less of the implementation. What does the app do, or how does the app do it? And more in terms of, like, product terms, what does the app do? How do people experience the behavior, or maybe how does data change over the life cycle of the app? So, those perspectives, I think, have helped me distill down sort of more vague product ideas into things that I can then start turning into code.

+ +

STEPHANIE: Absolutely. I think one way that this framework ends up falling short, at least for me a little bit sometimes, is making connections between behaviors that are similar but not exactly the same. Or when you think about them in more isolated ways, like, it's easy to miss that, like, they are the same idea and that there is, like, something a bit higher level that you can connect them, that you can create a more abstract class for, even though that's not actually how people talk about the things.

+ +

One example I can think of is things like concerns that are both related to domain language but then also, like, kind of specific to how things work in the code as a system because you might not necessarily call something a subscribable from a product perspective. Do you have any thoughts about identifying those pieces?

+ +

JOËL: So, what's interesting is I think there's a little bit of, like, layers above and below, the sort of domain layer where you're talking in terms of, like, what the product team would use. When you're doing a lot of the implementation, there will be things that are just, like, that's how we implemented them. They're in the nitty gritty, and they're not terms that the product team would necessarily use.

+ +

Things like array and string they're low-level details. We have to use them. That's not really relevant to the world of payers, and subscribers, and things like that. So, they're sort of lower layer. And I think that's totally fine to have things where we sort of have things that are sort of programmer only, as long as they're sort of contained within this higher-level layer because that allows people new to the app to sort of see what are the different things in the application to think about things in a higher level.

+ +

It also allows for smoother communication with the product team. So, ideally, you don't have a concept in the app that is the same as something that the product team, but you just both gave it different names, and then that's really annoying. Or maybe the dev team created something that's, like, almost exactly the same as what the product team talks about, but with some, like, slight variations. Now, you're just going to be talking past each other in every planning meeting, and that will be incredibly annoying.

+ +

STEPHANIE: Yeah. At one point, when I was trying to communicate, like, async about how a feature works, and there was like the product word for it and then the dev word for it, I would have to type out both [chuckles] because I wanted to make sure that no one was confused about what we were talking about, which was the same thing that just had two names. And yeah, I don't know how many seconds of my life I'll never get back as a result [chuckles].

+ +

JOËL: Were these concepts that were identical and had just different names, or was this like, oh, well, our internal subscribed user is almost the same as when product talks about and, I don't know, employee, but our subscribed user has a couple of other extra behaviors that employees don't have, and now there's, like, this weird, like, overlap?

+ +

STEPHANIE: Yeah, both situations I have found myself in, but I think this one they were virtually identical. Like, they could be used interchangeably to mean the same thing by people who understand both of those definitions, but the problem was that we still had two words [laughs].

+ +

JOËL: Yeah, yeah. I'm a big fan of, where possible, converging on the product team's definition. Although because code forces you to be more precise, sometimes that can then force some conversations with the product team about, like, "Hey, so we've been hand waving around this concept of a subscriber. Turns out we think there's actually two different kinds of concepts at work here: the person who's consuming the content and the person who's paying for it. And are they really the same thing, or should we sort of think about these as two different entities? And, in that case, what should the name be?" And that can force a really, I think, healthy conversation between development and product.

+ +

STEPHANIE: Yeah, I like that. You mentioned there was, like, a higher level and a lower level, but I don't think we've gotten to the higher one yet.

+ +

JOËL: Yeah. Sometimes, you want to build abstraction sort of over. You're talking about the idea of, like, subscribable things. I think that's where I'm a lot fuzzier. It's much more case-by-case. Where possible, I'd like to introduce some of those things as domain vocabulary so that we'd say, "Well, look, we have a, like, family of products, and they're all subscribable." And maybe, like, the adjective doesn't matter quite as much to our product people, but, you know, because we're using a module in Ruby, we want to lean into the adjective form, and that's fine. But I would at least want some loose connection there.

+ +

STEPHANIE: Yeah, that makes sense because I think that ultimately makes for a better product. If we're thinking about, like, how to present a hierarchy of information to a user, like a navigation menu, we would want to group those things that are under that family together, ideally, so that they know how to interact with it.

+ +

JOËL: Another thing that I think falls maybe under, like, this higher-level umbrella are things like design patterns. So, maybe because we want to be able to sort of, like, swap things in and out, we're using some form of strategy pattern. That feels like maybe it's a little bit higher level. It interacts with a lot of the domain concepts, but our product team doesn't really need to think in terms of, like, oh, strategies, and swappable things, and, like, flex points in your architecture. So, those would not necessarily be domain vocabulary. Although I could see, like, maybe there's a way where they do get a domain name, and that's great.

+ +

STEPHANIE: Oh, I think maybe this is where I disagree with you a little bit. Well, actually, I agreed with what you said at the end [laughs] in terms of how maybe they should be part of the domain vocabulary because I think...I've seen product not fully understand the complexity of the application as it grows over time. And that can lead to sometimes, like, not as great product experience or experience for the user, like, interacting with this product.

+ +

And maybe that is something we want to, as developers, if we're starting to see and feel and have maybe even introduced a pattern for...I can't claim to have done this too much, but it's definitely a skill I want to hone in on. But, like, how do I communicate to product folks so that we understand, oh, like, where is it possible for these different types of a subscriber to diverge? Because that is important, I think, in determining the future of a product and, like, where we want to invest in it and where we should focus, like, new features.

+ +

JOËL: And oftentimes, when there is that kind of divergence, there probably will be some sort of product-level thinking that needs to happen there. Are we saying, "Hey, we have one of three types of subscribers, and we want to think about that"? Or maybe we want to say, "We have three different ways of processing an application." Maybe it's derived automatically. Maybe it's a dropdown that you have to pick. But let's say it's a dropdown. What do we name that dropdown with the, like, kind of processing that we want to do to an application? The thing that we want to name that dropdown that's probably a good name for that, like, group of strategies, assuming we implement with a strategy pattern. Maybe we're doing it differently.

+ +

STEPHANIE: Yeah. The more you talk about that, the more I'm convinced that that's, like, the way I want to be working at least, because you have to know what's there in order to, like, name it. You know, you have to face it, essentially [laughs]. Whereas I think a lot of applications I've worked on fall into the trap of all of those things are obscured way down in the depths of the user flow, where it's like, oh, suddenly, for some reason, you can, like, have a dropdown here that totally changes the behavior, even though you've gotten this far in either the stack trace or even just, like the user journey, as I know you like to branch early in your code.

+ +

JOËL: [laughs].

+ +

STEPHANIE: But you should also branch early from a user's experience [laughs].

+ +

JOËL: In general, I'm just a big fan of having a communication loop between development and product, not only sort of receiving a lot of useful information from the product team about what we want to build. But then because we're encountering this more, like, technical spec that we're writing, have those conversations bubble back to product and say, "Hey, so we talked about a dropdown where there are sort of three different ways of processing an application. Let's talk a little bit more about what it means to have three different ways of processing. And what do we want to name that? Is that accessible to everyone, or are they sort of one-to-one tied with a type of user?"

+ +

And all of a sudden, that has just generated probably a lot of questions that product never even thought to ask because they're working on an infinite canvas of possibilities. And it's really helped you as a developer to have better names to write your code and sort of better sketch out the boundaries of the problem you're trying to solve. So, I think it's a really healthy loop to have. I strongly encourage it.

+ +

So, we've spent a lot of time talking about thinking about behavior and things like the domain-driven design movement. But a few other things I want to shout out as being really helpful, one is an exercise where you take a problem statement and just underline all of the nouns. That is a great way to get a sense of, like, what is going on here.

+ +

More generally, I think a lot of what we're talking about falls under the umbrella of what you might call analysis. And so, digging into different analytic techniques can be a great way to better understand the problem that you're working through. One such tool would be decision tables. So, you have a problem, and you say, "Well, given these inputs, what should the outputs be?"

+ +

STEPHANIE: Cool. If there were any techniques or tools that we missed in terms of how you load code in your brain or generate code from your brain [laughs], we would love to know. You can write in to us at hosts@bikeshed.fm.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie is back with a book recommendation: "Thinking in Systems" by Donella Meadows. This book has helped to bolster her understanding of complex systems in environmental, organizational, and software contexts, particularly through user interactions and system changes. Joël describes his transformative experience watching last week's total solar eclipse.

+ +

Together, they explore how systems thinking influences software development and team dynamics by delving into practical applications in writing and reading code, suggesting that understanding complex systems can aid developers in navigating and optimizing codebases and team interactions.

+ + + +

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: I have a book recommendation today [laughs].

+ +

JOËL: Oh, I love book recommendations.

+ +

STEPHANIE: It's been a little while, so I wanted to share what I've been reading that I think might be interesting to this audience. I'm reading Thinking in Systems by Donella Meadows. Joël, are you familiar with systems thinking theory at all?

+ +

JOËL: Very superficially. Hearing people talk about it on, I guess, X, now Twitter.

+ +

STEPHANIE: Yeah. Well, what I like about this book is the subtitle is A Primer on Thinking in Systems [chuckles], which is perfect for me as someone who also just kind of understood it very loosely, as just like, oh, like, I dunno, you look at things holistically and look at the stuff, not just its parts but from a higher perspective.

+ +

JOËL: Yeah. Is that accurate sort of your pre-book reading overview? Or do you think there's a bigger thing, a bigger idea there that the book unpacks?

+ +

STEPHANIE: Yeah. I think I'm only, like, a third of the way through so far. But what I have enjoyed about it is that, you know, in some ways, like, intuitively, that makes a lot of sense about, like, oh yeah, you want to make sure that you see the forest for the trees, right?

+ +

But one thing I've been surprised by is how it's also teaching me more technical language to talk about complex systems. And, in this case, she is talking about, essentially, living systems or systems that change over time where things are happening. I think that can be a little bit confusing when we also are, you know, talking about computer systems, but, in this case, you know, systems like environments, or communities, or even, you know, companies or organizations, which is actually where I'm finding a lot of the content really valuable.

+ +

But some of the language that I've learned that I am now trying to integrate a little bit more into how I view a lot of just, like, daily problems or experiences involve things like feedback loops that might be reinforcing or balancing and different, like, inputs and output flows and what is driving those things. So, I've appreciated just having more precise language for things that I think I kind of intuited but didn't exactly know how to, like, wrap up in a way to communicate to someone.

+ +

JOËL: Do you think the idea of thinking in terms of things like self-balancing versus sort of diverging input loops is something that's useful when actually writing code? Or do you think of it a little bit more in terms of, like, teams and how they organize general problem-solving approaches, things like that?

+ +

STEPHANIE: I think the answer is both. I actually gave this quite a bit of thought because I was trying to wrap my head around her definition of a system and how we talk about systems sometimes, like, a codebase, for example. And the conclusion I came to is that, really, it's not just the code static by itself that we care about. It's how it gets exercised, how users use it, how developers change it, how we interact with it when we, like, run tests, for example.

+ +

So, that was really helpful in kind of thinking about some of the problems we see in engineering organizations as a result of software being a thing that is used and written by humans, as opposed to it just existing in memories [chuckles] or, like, it's in a storage system somewhere. Like, that means it's kind of lifeless, and it's not changing anymore. But the point of kind of this framework is trying to understand it as it changes.

+ +

JOËL: So, kind of that blurry line between humans and computers and where those two overlap is where a lot of that systems thinking almost, like, mental model or vocabulary has been most helpful for you.

+ +

STEPHANIE: Yeah, I would say so. So, Joël, what's new in your world?

+ +

JOËL: So, I did the thing. I traveled to see the total solar eclipse this past weekend. It was mind-blowing. It was incredibly cool. I really loved it. For any of our listeners who have never seen a solar eclipse, in the coming years, have an opportunity to see one. I'd say it's worth traveling to see because it is really impressive.

+ +

STEPHANIE: Cool. What did it look like when it happened, when it was 100% eclipsed?

+ +

JOËL: So, what really impressed me was the fact that, like, most of the cool stuff happens in that, like, last half a percent. So, like, 95% eclipsed, still not that impressive. If that's all I'd seen, I would be disappointed. And then, in that last little bit, all of a sudden, everything goes dark. It's sort of, like, that twilight past sunset. You've got a glow on the horizon. The stars are out.

+ +

STEPHANIE: Wow.

+ +

JOËL: The animals are behaving like it's past sunset. They're getting ready to go to sleep.

+ +

STEPHANIE: Whoa.

+ +

JOËL: The sun itself is just a black dot with this, like, big fiery ring around it. Like all those pictures, icons, photos you see online, or drawings that look over the top, those things are real. That's what it looks like.

+ +

STEPHANIE: Wow, that's really neat. Could you see it without looking through the eclipse viewers?

+ +

JOËL: So, when you hit totality, you can look at it with a naked eye, and it is, yeah, magnificent.

+ +

STEPHANIE: Oh, that's so cool. How long did it last?

+ +

JOËL: So, it depends where you are in the path of totality. I was pretty much dead center. And it lasts, I think, three and a half minutes is what we had.

+ +

STEPHANIE: That's so cool. So, for me, here in Chicago, we did not have complete totality. It was about, like, 95%. So, I was watching it, just from that perspective. And I would say, yeah, it was not nearly as cool as what you described. It kind of just was like, oh, it got dark. It almost looked like I was viewing the world through sunglasses.

+ +

I did have one of those viewers that I used to, like, look at the sun and see how much of it had been covered. But yeah, it was cool. But what you said, I think now I feel like, wow, I really should have [laughter] traveled. I could have traveled just a few hours, you know, to, like, Indianapolis or something to have been on the path. That would have been really neat. And I don't think the next one will be until 2044 or something like that.

+ +

JOËL: Yeah. And that's the thing, right? I think if you're within a few hours of the path of a total eclipse, it is absolutely worth traveling to totality. The downside of that is that everybody else has the same idea. And so, you will be fighting traffic and a lot of things, especially if it goes through some, like, populated areas, like it did this time.

+ +

STEPHANIE: Yeah. Well, that's really neat that you got to see that. That's, I don't know, it sounds like not exactly once in a lifetime, but definitely very rare.

+ +

JOËL: For sure. I think with this experience now; I would definitely consider traveling again if there's one, like, anywhere near where I live, or, you know, maybe even, like, planning a vacation around going somewhere else to see one because it's short. You know, you're there for three minutes, and you see something cool. But that was really impressive.

+ +

So, something that really struck me when you were talking earlier about systems thinking is that you mentioned that it gave you a sort of a new vocabulary to talk about things. It almost gave you a sort of different way of thinking or some other mental models that you could use to apply when you are interacting in that sort of fussy boundary between people and code.

+ +

And I think that this idea of having language and having mental models is something that is incredibly valuable for us as programmers in a few different areas. And I'd be curious to see particularly for when we're reading other code, reading code that someone else has written or, you know, yourself from six months ago, do you have any sort of mental models that you like to reach for or techniques that you like to use to sort of give yourself that almost vocabulary to understand what somebody else is trying to do with their code?

+ +

STEPHANIE: Yeah, I would say so. You know, as you were talking about, like, how do you read code? I was thinking about how I read code is different from how I would read a book [laughs]. I almost rarely just read everything line by line and, like, file by file, you know, in some order that has been presented to me. I am usually a lot more involved. It's almost, like, more like a choose your own adventure kind of book [chuckles], where it's like, oh, go to this page to check if you want to check out what happened down this code path [chuckles].

+ +

JOËL: Right, right. Oh, if you're reading a novel, are you the kind of person that will read the ending first?

+ +

STEPHANIE: Absolutely not.

+ +

[laughter]

+ +

JOËL: You have strong opinions here.

+ +

STEPHANIE: Even when I, like, really want to... okay, sometimes I will, like, maybe just kind of flip to the back and just see, like, oh, how many more pages or chapters do I have [laughs] left? If I am itching to know what might happen. But I definitely don't start a book by reading the end. I think there are people who do that, and maybe that works for them, but I don't understand it.

+ +

[laughter]

+ +

JOËL: But maybe that's the thing that you do with your code.

+ +

STEPHANIE: Yeah. When I read code, it's almost always with some kind of intention to understand a particular behavior, usually kind of kicked off by some action, like, done by the user or something automated. And I want to understand that process from start to finish. So, I'm less likely to read a whole class file [chuckles], as opposed to just following method and the messages that are sent along the way in a process.

+ +

JOËL: That makes sense. Do you tend to sort of go from kind of the origin point and then follow it down, or sort of the opposite, find some, like, terminal node and then work your way back?

+ +

STEPHANIE: Oh.

+ +

JOËL: And I could imagine this in a more concrete sense in a Rails app. You find, like, the route that you're going to hit because you know it's a URL, and then you find the controller, and then you read through the action. And then, you maybe follow a service and something like that or look into the view. Or maybe the opposite: there's a particular page that gets rendered. You look at a method, a helper method that gets called in a view, and then you sort of, like, follow a backtrace from there.

+ +

STEPHANIE: Yeah, I think both. It depends on what information I have available to me, I think. I can think of, recently, I was trying to figure out the process for which, like, a user in this application I'm working on can downgrade the tier of their account, and I didn't know what to grep for. And so, I asked, like, "Hey, like, what are the entry points for a user being able to do this?"

+ +

And someone gave me a couple of routes, and that was great because then I got to see, oh, that this is possible in multiple ways. Like, the user can do it themselves, or the admin can do it, and that was really helpful. Other times, I think I have been able to find a keyword on a page and start from, like, a view or a component, or something like that, and then work upwards.

+ +

JOËL: I love that question that you asked, "What are the entry points for this thing?" I feel like that's a fantastic question to sort of ask yourself when you're feeling stuck, but it's also a great question to ask other people that might know.

+ +

Do you find that you read code differently when you're just trying to, like, maybe understand a broader subsystem? Maybe you're sort of new to this area and you have to add a feature, as opposed to maybe you're debugging something and trying to understand why things went wrong. Are those two different kinds of reading?

+ +

STEPHANIE: Yeah, that's also a great point because I do think there's another time when I've just scanned the file structure of an app and looked at the model's directory and just kind of been like, okay, like, maybe some things are namespaced. And that helps me just know what the main concepts that I have to be dealing with or that I will be dealing with are.

+ +

But I find that sometimes less fruitful because of kind of what I mentioned earlier about thinking in systems, where I'm not sure how important those things will be yet because I don't know how they're used. They could not be used at all [laughs]. And then, I think I'm potentially, like, storing information that is not actually relevant in my brain.

+ +

JOËL: That's tough, right? Because systems are so big, we can't hold them entirely in our brain. So, sometimes, selectively deciding what will not be loaded in there is just as important as what will.

+ +

STEPHANIE: Yes. And I think that is actually advice that I would give to devs who are trying to get better at reading code. And this one's hard because when I am working with more early-career developers, it's hard to figure out, like, what are they seeing? How are they interpreting the code on the page? Because oftentimes, I see that they are getting stuck on the details, whereas I would like to encourage them to just be like, you don't really need to know what's going on in that method right now. Does the method name kind of communicate enough to you, like, what this thing is doing without having to understand all of the details?

+ +

But my advice would be to start figuring out what to ignore [laughs] because, like you said, it's impossible to, like, hold all of that information at one time. What do you think about that advice and, like, how do you teach that to someone?

+ +

JOËL: I think you're sort of hinting at two different ways of reducing the amount you have to load in your mind. The way I think about it, I think of it sort of spatially, so you can reduce the breadth of things you have to load into your head, so, realize, wait, there's all of these methods, and I don't need to know all of the methods in the file. There's only this one entry point I care about and everything downstream of that, and you just sort of prune everything off to the side, ignore it. That's not relevant right now.

+ +

But there's also sort of a depth. How deep of implementation do you really need to have? Maybe you only need to know about the high-level concepts. And then, you sort of, like, do this pruning where you say, "I'm not going to go deeper than this level," because the implementation is not really relevant to what I'm trying to understand right now. I mostly need to know what are these classes and how do they interact with each other? Or something along those lines.

+ +

And, ideally, you're may be doing a little bit of both. You probably don't need to go all the way to the deep implementation of every method, but you also don't necessarily need to know all of the high-level concepts and all of the objects in the system that interact. So, being able to prune in sort of both dimensions, breadth and depth, helps you to, I think, narrow the window of what you need to learn.

+ +

STEPHANIE: Yeah, that's a really great point. I have a couple more strategies that I just thought about as you were talking about that. One is kind of on the journey to let go of some things that I can't understand in the moment. If they seem important, I will write them down and, like, put them somewhere in a list to come back to later and be like, "This is a thing I don't fully understand yet," and just be okay with that.

+ +

I think, for me, there is some anxiety of like, oh, like, what if I'll need to know about it later? And at least putting it down somewhere as like, okay, like, I've done something with that anxious [laughs] energy of, like, recognizing that I don't understand this right now, and that's okay. But I can revisit it later.

+ +

And then, another one is almost the opposite, where it's like, what are my landmarks as I'm navigating through a codebase? Like, what are the files that I'm consistently opening? Because so many of the roads lead to this object. Even when I'm kind of going through different paths, it's like, I can hook into, like, the behavior that I'm looking for from these landmark objects or models because they are really important in this domain. So, it's like, I don't necessarily need to remember every step of the way, but if I can recall some of the more important methods, then I can kind of find my way back.

+ +

JOËL: Do you just try to, like, memorize those, or do you write them down? Like, how do you make a method or an object a landmark for you?

+ +

STEPHANIE: That has felt a little more, like, it becomes more, like, muscle memory, I think, because I'm revisiting them pretty frequently. I don't know, it's somehow the act of repeating, like, going through those files just gets encoded somewhere in my brain [laughs], and I don't have to worry as much about forgetting them.

+ +

JOËL: Strengthening that neural pathway.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: Or whatever is happening in the brain there.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I like what you were saying earlier, though, about taking notes and sort of almost, like, a breadcrumbs approach. We did an episode almost two years ago where we talked about note-taking for various purposes and note-taking as an exploration exercise, and then note-taking when debugging, where we went deeper into that topic. And I think that would be really relevant to any of our listeners. We'll link that in the show notes.

+ +

STEPHANIE: Yeah. Leaving breadcrumbs. That's a great metaphor or just a way to describe it. Because I have a little shorthand for if I am leaving myself notes in a codebase as I'm trying to understand what's happening, and it's just, like, putting my initials in a comment and, like, including some observation or commentary about what I'm seeing or a question.

+ +

JOËL: Also, just a kind of meta observation here, but in the last, you know, 10-15 minutes we've been talking about this, we're already creating our own set of metaphors, and language, and mental models around understanding code. We're talking about breadcrumbs, and landmarks, and looking at code through a broad versus deep lens. That's exactly what we're talking about.

+ +

STEPHANIE: Joël, do you have any mental models that you use that we haven't really gotten into yet?

+ +

JOËL: I don't know if they're mental models per se, but I lean very heavily into diagramming as a form of understanding code. And maybe that's a way of sort of reducing the number of concepts because instead of now sort of thinking in terms of, like, lines of code, I'm thinking in terms of maybe some boxes and arrows, and that's a much higher-level way of looking at a system and can give me some really interesting insights.

+ +

And there are a ton of different diagrams you can use for different things, and I guess all of them are based on a different maybe mental model of what a system is. So, for example, I might actually write out the method call graph starting from some endpoint and just sort of saying, "Hey, when I call this method, what are all of the methods downstream that get called? And is there anything interesting at any of those steps?"

+ +

Variation on that if you're looking at, let's say, some kind of performance thing would be, like, a flame graph where you have sort of that but then it also shows you the amount of time spent in each of the methods. And that can give you a sense of where your bottlenecks are.

+ +

Another one that I really like is thinking in terms of a finite state machine. So, sort of following data, how does it change in response to different events that can come into the system? And I'm not talking about, oh, you're using one of the, like, state machine gems out there for your Rails app. This is more of a way of thinking about programs and how they act.

+ +

You can have just a plain, old Rails app, and you're thinking about, okay, well, how does a cart turn into an order, turn into a fulfillment request at the warehouse, turns into a tracking number for shipping? Modeling that as a state machine. And also, you know, can it move back along that path, or is it only linear move forward? Any kind of multi-state form a wizard often has paths where you move back. It's not linear. That very easily can be drawn out as a state machine. So, that is something that I really like to pull out when I'm trying to understand a, like, complex workflow.

+ +

STEPHANIE: Yeah, I think we've talked about this before a little bit, or maybe not even a little bit, a lot [laughs]. But I know that you're a big fan of Mermaid.js for creating diagrams in markdown that can be embedded in a pull request description or even in a commit message. When I was hearing you talk about state machines and just all the different paths that can lead to different states, I was like, I bet that's something that you would create using a diagram and stick for yourself and others when sharing code.

+ +

JOËL: Yes, Mermaid does support state machines as a graph type, which is really cool.

+ +

Another thing that you can do is embed those in tools like Obsidian, which is my current note-taking tool. So, if I'm doing some sort of notes as a sort of exploratory tool, I will often start writing a Mermaid graph directly in line, and it will render and everything. That's really nice. If I'm not in Obsidian and I just need some sort of one-off graph, I'll often lean on Mermaid.live, which just gives you an editor where you can write up some Mermaid code. It will render it, and then you can copy the PNG into somewhere else and share that with other people. So, if I just need a one-off thing to share in Slack or something like that, I like to lean on that.

+ +

Another type of diagram that I use pretty frequently is an entity-relationship diagram, so sort of what database tables are related to what others. On larger apps, there's just so many tables, and maybe a bunch of JOINS and things like that, and it's sometimes difficult to get the picture of what is happening, so I'll often draw out a graph of those. Now, it's not worth doing the entire database because that will be huge and overwhelming. So, I'll find, like, five or six tables that are relevant to me and then try to answer the question: How are they related to each other?

+ +

STEPHANIE: Yeah, I like that. I was going to ask if you do it manually or if you use a tool because I've worked in various apps that have used the Rails ERD gem that will generate an entity-relationship diagram for you every time the schema changes. But there's something very compelling, to me, about the idea of trying to just figure out if you know the relationships, if you could draw them out, as opposed to having a tool do it for you.

+ +

JOËL: Exactly.

+ +

STEPHANIE: And I think, like, also, you do have information that might not be encoded in the system. Like, you actually know, oh, these two tables are related, even if no one has defined an association on them. I think that is important in understanding actually how the system is working in real life, I guess.

+ +

JOËL: Agreed. So, we've been talking a lot about how we can use different tools, different mental models to take code that somebody else has written and kind of, like, almost read it from disk and load it into our brains. But what about the opposite? We're faced with a business problem, and we want to sort of write it to disk, turn it into code that somebody else will then read or that a machine will execute. I hear that happens occasionally. Are there sort of mental models or ways of approaching tackling a more, like, amorphous problem in the real world and turning that into code? Like, are they just the inverse of what we do when we read code, or are they, like, totally different set of skills?

+ +

STEPHANIE: For me personally, I don't follow this framework very strictly, but I think more intuitively how I like to go about it is more behavior-driven where...because that is the language of maybe our cross-functional partners. They're saying like, "Hey, like, when this happens, I want to be able to do this," and I kind of start there. Maybe I'll pick up some of the keywords that they're repeating pretty frequently as like, oh, like, this is a concept.

+ +

Actually, lately, the past couple of weeks, I've been test-driving almost all of my code as I work on a totally, like, greenfield feature. And that has been working really well for me, I think, because we did explore more granular, both, like, granular and abstract concepts when we were spiking this feature. And so, we had come up with some domain models. I had kind of thought about, like, how they might interact with each other.

+ +

But when you then have to actually, like, code that, there are so many little nuances and things to keep track of that I found test driving things from, like, behavior and user stories. Those are really helpful in keeping me, like, on track to making sure that I didn't just have all these little pieces of domain concepts that then didn't really interact in a meaningful way.

+ +

JOËL: Yeah, the sort of very, like, user or customer-centric approach to thinking about what is this app doing? Is a great way to think about it. And I guess the sort of translation of that, that first step of translation into code is some sort of, like, system spec.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I like that because, you know, we have all these other abstractions that we use as developers. But at the end of the day, our customers and even, you know, our product people aren't thinking in terms of, like, objects and classes and all these other fun abstractions that we have. They're thinking in terms of behaviors and, you know, maybe subsystems, workflows, things like that. And then it's up to us to translate that into whatever paradigm of our language that we're using.

+ +

STEPHANIE: Do you do things differently from me?

+ +

JOËL: I don't think that I do it necessarily differently. I think it's one of several tools I have in my tool belt. Something that is similar but from a slightly different angle is inspiring myself with a lot of the ideas from domain-driven design. You know, we've been talking a lot about this idea of, like, mental models and having a vocabulary, things like that, about sort of the way that we work, but that exists at the product level as well. And what if we could encode a lot of that into our application itself?

+ +

So, is there a distinction between a subscriber and a payer in our system? Is there specialized vocabulary around different other concepts in the app? Maybe instead of just having those be things that product people talk about, what if we made them actual named entities in the system and have maybe our object graph, at least in some way, reflect the sort of idealized model of what our business actually does?

+ +

That often means that you're thinking of things at a higher level because you're thinking of things at the level that our product people are thinking about them. You might be thinking of things in terms of user journeys, or product workflows, or things like that, because you say, "Oh, well, a new payer has been added to this group account. And that has started a subscription, which then means that a user has access to these corporate features that they didn't have when they were in a solo account."

+ +

Like, I've just thrown ten different sort of product terms out there that, you know, if there are concepts in our code can help us think about less of the implementation. What does the app do, or how does the app do it? And more in terms of, like, product terms, what does the app do? How do people experience the behavior, or maybe how does data change over the life cycle of the app? So, those perspectives, I think, have helped me distill down sort of more vague product ideas into things that I can then start turning into code.

+ +

STEPHANIE: Absolutely. I think one way that this framework ends up falling short, at least for me a little bit sometimes, is making connections between behaviors that are similar but not exactly the same. Or when you think about them in more isolated ways, like, it's easy to miss that, like, they are the same idea and that there is, like, something a bit higher level that you can connect them, that you can create a more abstract class for, even though that's not actually how people talk about the things.

+ +

One example I can think of is things like concerns that are both related to domain language but then also, like, kind of specific to how things work in the code as a system because you might not necessarily call something a subscribable from a product perspective. Do you have any thoughts about identifying those pieces?

+ +

JOËL: So, what's interesting is I think there's a little bit of, like, layers above and below, the sort of domain layer where you're talking in terms of, like, what the product team would use. When you're doing a lot of the implementation, there will be things that are just, like, that's how we implemented them. They're in the nitty gritty, and they're not terms that the product team would necessarily use.

+ +

Things like array and string they're low-level details. We have to use them. That's not really relevant to the world of payers, and subscribers, and things like that. So, they're sort of lower layer. And I think that's totally fine to have things where we sort of have things that are sort of programmer only, as long as they're sort of contained within this higher-level layer because that allows people new to the app to sort of see what are the different things in the application to think about things in a higher level.

+ +

It also allows for smoother communication with the product team. So, ideally, you don't have a concept in the app that is the same as something that the product team, but you just both gave it different names, and then that's really annoying. Or maybe the dev team created something that's, like, almost exactly the same as what the product team talks about, but with some, like, slight variations. Now, you're just going to be talking past each other in every planning meeting, and that will be incredibly annoying.

+ +

STEPHANIE: Yeah. At one point, when I was trying to communicate, like, async about how a feature works, and there was like the product word for it and then the dev word for it, I would have to type out both [chuckles] because I wanted to make sure that no one was confused about what we were talking about, which was the same thing that just had two names. And yeah, I don't know how many seconds of my life I'll never get back as a result [chuckles].

+ +

JOËL: Were these concepts that were identical and had just different names, or was this like, oh, well, our internal subscribed user is almost the same as when product talks about and, I don't know, employee, but our subscribed user has a couple of other extra behaviors that employees don't have, and now there's, like, this weird, like, overlap?

+ +

STEPHANIE: Yeah, both situations I have found myself in, but I think this one they were virtually identical. Like, they could be used interchangeably to mean the same thing by people who understand both of those definitions, but the problem was that we still had two words [laughs].

+ +

JOËL: Yeah, yeah. I'm a big fan of, where possible, converging on the product team's definition. Although because code forces you to be more precise, sometimes that can then force some conversations with the product team about, like, "Hey, so we've been hand waving around this concept of a subscriber. Turns out we think there's actually two different kinds of concepts at work here: the person who's consuming the content and the person who's paying for it. And are they really the same thing, or should we sort of think about these as two different entities? And, in that case, what should the name be?" And that can force a really, I think, healthy conversation between development and product.

+ +

STEPHANIE: Yeah, I like that. You mentioned there was, like, a higher level and a lower level, but I don't think we've gotten to the higher one yet.

+ +

JOËL: Yeah. Sometimes, you want to build abstraction sort of over. You're talking about the idea of, like, subscribable things. I think that's where I'm a lot fuzzier. It's much more case-by-case. Where possible, I'd like to introduce some of those things as domain vocabulary so that we'd say, "Well, look, we have a, like, family of products, and they're all subscribable." And maybe, like, the adjective doesn't matter quite as much to our product people, but, you know, because we're using a module in Ruby, we want to lean into the adjective form, and that's fine. But I would at least want some loose connection there.

+ +

STEPHANIE: Yeah, that makes sense because I think that ultimately makes for a better product. If we're thinking about, like, how to present a hierarchy of information to a user, like a navigation menu, we would want to group those things that are under that family together, ideally, so that they know how to interact with it.

+ +

JOËL: Another thing that I think falls maybe under, like, this higher-level umbrella are things like design patterns. So, maybe because we want to be able to sort of, like, swap things in and out, we're using some form of strategy pattern. That feels like maybe it's a little bit higher level. It interacts with a lot of the domain concepts, but our product team doesn't really need to think in terms of, like, oh, strategies, and swappable things, and, like, flex points in your architecture. So, those would not necessarily be domain vocabulary. Although I could see, like, maybe there's a way where they do get a domain name, and that's great.

+ +

STEPHANIE: Oh, I think maybe this is where I disagree with you a little bit. Well, actually, I agreed with what you said at the end [laughs] in terms of how maybe they should be part of the domain vocabulary because I think...I've seen product not fully understand the complexity of the application as it grows over time. And that can lead to sometimes, like, not as great product experience or experience for the user, like, interacting with this product.

+ +

And maybe that is something we want to, as developers, if we're starting to see and feel and have maybe even introduced a pattern for...I can't claim to have done this too much, but it's definitely a skill I want to hone in on. But, like, how do I communicate to product folks so that we understand, oh, like, where is it possible for these different types of a subscriber to diverge? Because that is important, I think, in determining the future of a product and, like, where we want to invest in it and where we should focus, like, new features.

+ +

JOËL: And oftentimes, when there is that kind of divergence, there probably will be some sort of product-level thinking that needs to happen there. Are we saying, "Hey, we have one of three types of subscribers, and we want to think about that"? Or maybe we want to say, "We have three different ways of processing an application." Maybe it's derived automatically. Maybe it's a dropdown that you have to pick. But let's say it's a dropdown. What do we name that dropdown with the, like, kind of processing that we want to do to an application? The thing that we want to name that dropdown that's probably a good name for that, like, group of strategies, assuming we implement with a strategy pattern. Maybe we're doing it differently.

+ +

STEPHANIE: Yeah. The more you talk about that, the more I'm convinced that that's, like, the way I want to be working at least, because you have to know what's there in order to, like, name it. You know, you have to face it, essentially [laughs]. Whereas I think a lot of applications I've worked on fall into the trap of all of those things are obscured way down in the depths of the user flow, where it's like, oh, suddenly, for some reason, you can, like, have a dropdown here that totally changes the behavior, even though you've gotten this far in either the stack trace or even just, like the user journey, as I know you like to branch early in your code.

+ +

JOËL: [laughs].

+ +

STEPHANIE: But you should also branch early from a user's experience [laughs].

+ +

JOËL: In general, I'm just a big fan of having a communication loop between development and product, not only sort of receiving a lot of useful information from the product team about what we want to build. But then because we're encountering this more, like, technical spec that we're writing, have those conversations bubble back to product and say, "Hey, so we talked about a dropdown where there are sort of three different ways of processing an application. Let's talk a little bit more about what it means to have three different ways of processing. And what do we want to name that? Is that accessible to everyone, or are they sort of one-to-one tied with a type of user?"

+ +

And all of a sudden, that has just generated probably a lot of questions that product never even thought to ask because they're working on an infinite canvas of possibilities. And it's really helped you as a developer to have better names to write your code and sort of better sketch out the boundaries of the problem you're trying to solve. So, I think it's a really healthy loop to have. I strongly encourage it.

+ +

So, we've spent a lot of time talking about thinking about behavior and things like the domain-driven design movement. But a few other things I want to shout out as being really helpful, one is an exercise where you take a problem statement and just underline all of the nouns. That is a great way to get a sense of, like, what is going on here.

+ +

More generally, I think a lot of what we're talking about falls under the umbrella of what you might call analysis. And so, digging into different analytic techniques can be a great way to better understand the problem that you're working through. One such tool would be decision tables. So, you have a problem, and you say, "Well, given these inputs, what should the outputs be?"

+ +

STEPHANIE: Cool. If there were any techniques or tools that we missed in terms of how you load code in your brain or generate code from your brain [laughs], we would love to know. You can write in to us at hosts@bikeshed.fm.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+S7e9ZRNH + + ]]> + + Joël Quenneville + Stephanie Minn + + + 422: Listener Topics Grab Bag + https://bikeshed.thoughtbot.com/422 + 08823662-de22-4c3b-a34e-2731e2b8d5cd + Tue, 09 Apr 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël conducted a thoughtbot mini-workshop on query plans, which Stephanie found highly effective due to its interactive format. They then discuss the broader value of interactive workshops over traditional talks for deeper learning. + +Addressing listener questions, Stephanie and Joël explore the strategic use of if and else in programming for clearer code, the importance of thorough documentation in identifying bugs, and the use of Postgres' EXPLAIN ANALYZE, highlighting the need for environment-specific considerations in query optimization. + 35:23 + no + + + Joël conducted a thoughtbot mini-workshop on query plans, which Stephanie found highly effective due to its interactive format. They then discuss the broader value of interactive workshops over traditional talks for deeper learning. +Addressing listener questions, Stephanie and Joël explore the strategic use of if and else in programming for clearer code, the importance of thorough documentation in identifying bugs, and the use of Postgres' EXPLAIN ANALYZE, highlighting the need for environment-specific considerations in query optimization. +Episode mentioning query plans (https://bikeshed.thoughtbot.com/418) +Query plan visualizer (https://explain.dalibo.com/) +RailsConf 2024 (https://railsconf.org/) +Episode 349: Unpopular Opinions (https://bikeshed.thoughtbot.com/349) +Squint test (https://www.youtube.com/watch?v=8bZh5LMaSmE) +Episode 405: Retro on Sandi Metz rules (https://bikeshed.thoughtbot.com/405) +Structuring conditionals in a wizard (https://thoughtbot.com/blog/structuring-conditionals-in-a-wizard) +Episode 417: Module docs (https://bikeshed.thoughtbot.com/417) +Episode 416: Multidimensional numbers (https://bikeshed.thoughtbot.com/416) +ruby-units gem (https://github.com/olbrich/ruby-units) +Solargraph (https://marketplace.visualstudio.com/items?itemName=castwide.solargraph) +parity (https://github.com/thoughtbot/parity) +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: Just recently, I ran a sort of mini workshop for some colleagues here at thoughtbot to dig into the idea of query plans and, how to read them, how to use them. And, initially, this was going to be more of a kind of presentation style. And a colleague and I who were sharing this decided to go for a more interactive format where, you know, this is a, like, 45-minute slot. +And so, we set it up so that we did a sort of intro to query plans in about 10 minutes then 15 minutes of breakout rooms, where people got a chance to have a query plan. And they had some sort of comprehension questions to answer about it. And then, 15 minutes together to have each group share a little bit about what they had discovered in their query plan back with the rest of the group, so trying to balance some understanding, some application, some group discussion, trying to keep it engaging. It was a pretty fun approach to sharing information like that. +STEPHANIE: Yeah. I wholeheartedly agree. I got to attend that workshop, and it was really great. Now that I'm hearing you kind of talk about the three different components and what you wanted people attending to get out of it, I am impressed because [laughs] there is, like, a lot more thought, I think, that went into just participant engagement that reflecting on it now I'm like, oh yeah, like, I think that was really effective as opposed to just a presentation. Because you had, you know, sent us out into breakout rooms, and each group had a different query that they were analyzing. You had kind of set up links that had the query set up in the query analyzer. I forget what the tool was called that you used. +JOËL: I forget the name of it, but we will link it in the show notes. +STEPHANIE: Yeah. It was helpful for me, though, because, you know, I think if I were just to have learned about it in a presentation or even just looked at, you know, screenshots of it on a slide, that's different still from interacting with it and feeling more confident to use it next time I find myself in a situation where it might be helpful. +JOËL: It's really interesting because that was sort of the goal of it was to make it a bit more interactive and then, hopefully, helping people to retain more information than just a straight up, like, presentation would be. I don't know how you feel, I find that often when I go to a place like, let's say, RailsConf, I tend to stay away from more of the workshop-y style events and focus more on the talks. Is that something that you do as well? +STEPHANIE: Yeah. I have to confess that I've never attended a workshop [laughs] at a conference. I think it's partly my learning style and also partly just honestly, like, my energy level when I'm at the conference. I kind of just want to sit back. It's on my to-do list. Like, I definitely want to attend one just to see what it's like. And maybe that might even inspire me to want to create my own workshop. But it's like, once I'm in it, and, you know, like, everyone else is also participating, I'm very easily peer pressured [laughs]. So, in a group setting, I will find myself enjoying it a lot more. And I felt that kind of same way with the workshop you ran for our team. +Though, I will say a funny thing that happened was that when I went out into my breakout group with another co-worker, and we were trying to grok this query that you gave us, we found out that we got the hardest one, the most complicated one [laughs] because there were so many things going on. There was, like, multiple, like, you know, unions, some that were, like, nested, and then just, like, a lot of duplication as well, like, some conditions that were redundant because of a different condition happening inside of, like, an inner statement. And yeah, we were definitely scratching our heads for a bit and were very grateful that we got to come back together as a group and be like, "Can someone please help? [laughs] Let's figure out what's going on here." +JOËL: Sort of close that loop and like, "Hey, here's what we saw. What does everybody else see?" +STEPHANIE: Yeah, and I appreciated that you took queries from actual client projects that you were working on. +JOËL: Yeah, that was the really fun part of it was that these were not sort of made-up queries to illustrate a point. These were actual queries that I had spent some time trying to optimize and where I had had to spend a lot of time digging into the query plans to understand what was going on. And it sounds like, for you, workshops are something that is...they're generally more engaging, and you get more value out of them. But there's higher activation energy to get started. Does that sound right? +STEPHANIE: Yeah, that sounds right. I think, like, I've watched so many talks now, both in person and on YouTube, that a lot of them are easily forgettable [laughs], whereas I think a workshop would be a lot more memorable because of that interactivity and, you know, you get out of it what you put in a little bit. +JOËL: Yeah, that's true. Have you looked at the schedule for RailsConf 2024 yet? And are there any workshops on there that you're maybe considering or that maybe have piqued your interest? +STEPHANIE: I have, in fact, and maybe I will check off attending a workshop [laughs] off my bucket list this year. There are two that I'm excited about. Unfortunately, they're both at the same time slot, so I -- +JOËL: Oh no. You're going to have to choose. +STEPHANIE: I know. I imagine I'll have to choose. But I'm interested in the Let's Extend Rails With A Gem by Noel Rappin and Vision For Inclusion Workshop run by Todd Sedano. The Rails gem one I'm excited about because it's just something that I haven't had to do really in my dev career so far, and I think I would really appreciate having that guidance. And also, I think that would be motivation to just get that, like, hands-on experience with it. Otherwise, you know, this is something that I could say that I would want to do and then never get [chuckles] around to it. +JOËL: Right, right. And building a gem is the sort of thing that I think probably fits better in a workshop format than in a talk format. +STEPHANIE: Yeah. And I've really appreciated all of Noel's content out there. I've found it always really practical, so I imagine that the workshop would be the same. +JOËL: So, other than poring over the RailsConf schedule and planning your time there, what has been new for you this week? +STEPHANIE: I have a really silly one [laughs]. +JOËL: Okay. +STEPHANIE: Which is, yesterday I went out to eat dinner to celebrate my partner's birthday, and I experienced, for the first time, robots [laughter] at this restaurant. So, we went out to Hot Pot, and I guess they just have these, like, robot, you know, little, small dish delivery things. They were, like, as tall as me, almost, at least, like, four feet. They were cat-themed. +JOËL: [laughs] +STEPHANIE: So, they had, like...shaped like cat...they had cat ears, and then there was a screen, and on the screen, there was, like, a little face, and the face would, like, wink at you and smile. +JOËL: Aww. +STEPHANIE: And I guess how this works is we ordered our food on an iPad, and if you ordered some, like, side dishes and stuff, it would come out to you on this robot cat with wheels. +JOËL: Very fun. +STEPHANIE: This robot tower cat. I'm doing a poor job describing it because I'm still apparently bewildered [laughs]. But yeah, I was just so surprised, and I was not as...I think I was more, like, shocked than delighted. I imagine other people would find this, like, very fun. But I was a little bit bewildered [laughs]. +The other thing that was very funny about this experience is that these robots were kind of going down the aisle between tables, and the aisles were not quite big enough for, like, two-way traffic. And so, there were times where I would be, you know, walking up to go use the restroom, and I would turn the corner and find myself, like, face to face with one of these cat robot things, and, like, it's starting to go at me. I don't know if it will stop [laughs], and I'm the kind of person who doesn't want to find out. +JOËL: [laughs] +STEPHANIE: So, to avoid colliding with this, you know, food delivery robot, I just, like, ran away from it [laughs]. +JOËL: You don't know if they're, like, programmed to yield or something like that. +STEPHANIE: Listen, it did not seem like it was going to stop. +JOËL: [laughs] +STEPHANIE: It got, like, I was, you know, kind of standing there frozen in paralysis [laughs] for a little while. And then, once it got, I don't know, maybe two or three feet away from me, I was like, okay, like, this is too close for comfort [laughs]. So, that was my, I don't know, my experience at this robot restaurant. Definitely starting to feel like I'm in the, I don't know, is this the future? Someone, please let me know [laughs]. +JOËL: Is this a future that you're excited or happy about, or does this future seem a little bit dystopian to you? +STEPHANIE: I was definitely alarmed [laughter]. But I'm not, like, a super early adopter of new technology. These kinds of innovations, if you will, always surprise me, and I'm like, oh, I guess this is happening now [laughs]. And I will say that the one thing I did not enjoy about it is that there was not enough room to go around this robot. It definitely created just pedestrian traffic issues. So, perhaps this could be very cool and revolutionary, but also, maybe design robots for humans first. +JOËL: Or design your dining room to accommodate your vision for the robots. I'm sure that flying cars and robots will solve all of this, for sure. +STEPHANIE: Oh yeah [laughter]. Then I'll just have to worry about things colliding above my head. +JOËL: And for the listeners who cannot see my face right now, that was absolutely sarcasm [laughs]. Speaking of our listeners, today we're going to look at a group of different listener questions. And if you didn't know that, you could send in a question to have Stephanie and I discuss, you can do that. Just send us an email at hosts@bikeshed.fm. And sometimes, we put it into a regular episode. Sometimes, we combine a few and sort of make a listener question episode, which is what we're doing today. +STEPHANIE: Yeah. It's a little bit of a grab bag. +JOËL: Our first question comes from Yuri, and Yuri actually has a few different questions. But the first one is asking about Episode 349, which is pretty far back. It was my first episode when I was coming on with Chris and Steph, and they were sort of handing the baton to me as a host of the show. And we talked about a variety of hot takes or unpopular opinions. +Yuri mentions, you know, a few that stood out to him: one about SPAs being not so great, one about how you shouldn't need to have a side project to progress in your career as a developer, one about developer title inflation, one about DRY and how it can be dangerous for a mid-level dev, avoiding let in RSpec specs, the idea that every if should come with an else, and the idea that developers shouldn't be included in design and planning. And Yuri's question is specifically the question about if statements, that every if should come with an else. Is that still an opinion that we still have, and why do we feel that way? +STEPHANIE: Yeah, I'm excited to get into this because I was not a part of that episode. I was a listener back then when it was still Steph and Chris. So, I am hopefully coming in with a different, like, additional perspective to add as well while we kind of do a little bit of a throwback. So, the one about every if should come with an else, that was an unpopular opinion of yours. Do you mind kind of explaining what that means for you? +JOËL: Yeah. So, in general, Ruby is an expression-oriented language. So, if you have an if that does not include an else, it will implicitly return nil, which can burn you. There may be some super expert programmers out there that have never run into undefined method for nil nil class, but I'm still the kind of programmer who runs into that every now and then. And so, implicit nils popping up in my code is not something I generally like. I also generally like having explicit else for control flow purposes, making it a little bit clearer where flow of control goes and what are the actual paths through a particular method. +And then, finally, doing ifs and elses instead of doing them sort of inline or as trailing conditionals or things like that, by having them sort of all on each lines and balancing out. The indentation itself helps to scan the code a little bit more. So, deeper indentation tells you, okay, we're, like, nesting multiple conditions, or something like that. And so, it makes it a little bit easier to spot complexity in the code. You can apply, and I want to say this is from Sandi Metz, the squint test. +STEPHANIE: Yeah, it is. +JOËL: Where you just kind of, like, squint at your code so you're not looking at the actual characters, and more of the structure, and the indentation is actually a friend there rather than something to fight. So, that was sort of the original, I think, idea behind that. I'm curious, in your experience, if you would like to balance your conditionals, ifs with something else, or if you would like to do sort of hanging ifs. +STEPHANIE: Hanging ifs, I like that phrase that you just coined there. I agree with your opinion, and I think it's especially true if you're returning values, right? I mean, in Ruby, you kind of always are. But if you are caring about return values, like you said, to avoid that implicit nil situation, I find, especially if you're writing tests for that code, it's really easy, you know, if you spot that condition, you're like, okay, great. Like, this is a path I need to test. +But then, oftentimes, you don't test that implicit path, and if you don't enter the condition, then what happens, right? So, I think that's kind of what you're referring to when you talk about both. It's, like, easier to spot in terms of control flow, like, all the different paths of execution, as well as, yeah, like, saving you the headaches of some bugs down the line. +One thing that I thought about when I was kind of revisiting that opinion of yours is the idea of like, what are you trying to communicate is different or special about this condition when you are writing an if statement? And, in my head, I kind of came up with a few different situations you might find yourself in, which is, one, where you truly just have, like, a special case, and you're treating that completely differently. Another when you have more of a, like, binary situation, where it's you want to kind of highlight either...more of a dichotomy, right? It's not necessarily that there is a default but that these are two opposite things. And then, a third situation in which you have multiple conditions, but you only happen to have two right now. +JOËL: Interesting. And do you think that, like, breaking down those situations would lead you to pick different structures for writing your conditionals? +STEPHANIE: I think so. +JOËL: Which of those scenarios do you think you might be more likely to reach for an if that doesn't have an else that goes with it? +STEPHANIE: I think that first one, the special case one. And in Yuri's email, he actually asked, as a follow-up, "Do we avoid guard clauses as a result of this kind of heuristic or rule?" And I think that special case situation is where a guard clause would shine because you are highlighting it by putting it at the top of a method, and then saying like, you know, "Bail out of this" or, like, "Return this particular thing, and then don't even bother about the rest of this code." +JOËL: I like that. And I think guard clauses they're not the first thing I reach for, but they're not something I absolutely avoid. I think they need to be used with care. Like you said, they have to be in the top of your method. If you're adding returns and things that break out of your method, deep inside a conditional somewhere, 20 lines into your method, you don't get to call that a guard clause anymore. That's something else entirely. I think, ideally, guard clauses are also things that will break out of the method, so they're maybe raising exception. Maybe they're returning a value. But they are things that very quickly check edge cases and bail so that the body of the method can focus on expecting data in the correct shape. +STEPHANIE: I have a couple more thoughts about this; one is I'm reminded of back when we did that episode on kind of retroing Sandi Metz's Rules For Developers. I think one of the rules was: methods should only be five lines of code. And I recall we'd realized, at least I had realized for the first time, that if you write an if-else condition in Ruby, that's exactly five lines [laughs]. +And so, now that I'm thinking about this topic, it's cool to see that a couple of these rules converge a little bit, where there's a bit of explicitness in saying, like, you know, if you're starting to have more conditions that can't just be captured in a five-line if-else statement, then maybe you need something else there, right? Something perhaps like polymorphic or just some way to have branched earlier. +JOËL: That's true. And so, even, like, you were talking about the exceptional edge cases where you might want to bail. That could be a sign that your method is doing too much, trying to like, validate inputs and also run some sort of algorithm. Maybe this needs to be some sort of, like, two-step thing, where there's almost, like, a parsing phase that's handled by a different object or a different method that will attempt to standardize your inputs and raise the appropriate errors and everything. And then, your method that has the actual algorithm or code that you're trying to run can just assume that its inputs are in the correct shape, kind of that pushing the uncertainty to the edges. +And, you know, if you've only got one edge case to check, maybe it's not worth to, like, build this in layers, or separate out the responsibilities, or whatever. But if you're having a lot, then maybe it does make sense to say, "Let's break those two responsibilities out into two places." +STEPHANIE: Yeah. And then, the one last kind of situation I've observed, and I think you all talked about this in the Unpopular Opinions episode, but I'm kind of curious how you would handle it, is side effects that only need to be applied under a certain condition. Because I think that's when, if we're focusing less on return values and more just on behavior, that's when I will usually see, like, an if something, then do this that doesn't need to happen for the other path. +JOËL: Yes. I guess if you're doing some sort of side effect, like, I don't know, making a request to an API or writing to a file or something, having, like, else return nil or some other sentinel value feels a little bit weird because now you're caring about side effects rather than return values, something that you need to keep thinking of. And that's something where I think my thing has evolved since that episode is, once you start having multiple of these, how do they compose together? So, if you've got if condition, write to a file, no else, keep going. New if condition, make a request to an API endpoint, no else, continue. +What I've started calling independent conditions now, you have to think about all the different ways that they can combine, and what you end up having is a bit of a combinatorial explosion. So, here we've got two potential actions: writing to a file, making a request to an API. And we could have one or the other, or both, or neither could happen, depending on the inputs to your method, and maybe you actually want that, and that's cool. +Oftentimes, you didn't necessarily want all of those, especially once you start going to three, four, five. And now you've got that, you know, explosion, like, two to the five. That's a lot of paths through your method. And you probably didn't really need that many. And so, that can get really messy. And so, sometimes the way that an if and an else work where those two paths are mutually exclusive actually cuts down on the total number of paths through your method. +STEPHANIE: Hmm, I like that. That makes a lot of sense to me. I have definitely seen a lot of, like, procedural code, where it becomes really hard to tell how to even start relating some of these concepts together. So, if you happen to need to run a side effect, like writing to a file or, I don't know, one common one I can think of is notifying something or someone in a particular case, and maybe you put that in a condition. But then there's a different branching path that you also need to kind of notify someone for a similar reason, maybe even the same reason. +It starts to become hard to connect, like, those two reasons. It's not something that, like, you can really scan for or, like, necessarily make that connection because, at that point, you're going down different paths, right? And there might be other signals that are kind of confusing things along the way. And it makes it a lot harder, I think, to find a shared abstraction, which could ultimately make those really complicated nested conditions a little more manageable or just, like, easier to understand at a certain complexity. I definitely think there is a threshold. +JOËL: Right. And now you're talking about nested versus non-nested because when conditions are sort of siblings of each other, an if-else behaves differently from two ifs without an else. I think a classic situation where this pops up is when you're structuring code for a wizard, a multi-step form. And, oftentimes, people will have a bunch of checks. They're like, oh, if this field is present, do these things. If this field is present, do these things. +And then, it becomes very tricky to know what the flow of control is, what you can expect at what moment, and especially which actions might get shared across multiple steps. Is it safe to refactor in one place if you don't want to break step three? And so, learning to think about the different paths through your code and how different conditional structures will impact that, I think, was a big breakthrough for me in terms of taking the next logical step in terms of thinking, when do I want to balance my ifs and when do I not want to? I wrote a whole article on the topic. We'll link it in the show notes. +So, Yuri, thanks for a great question, bringing us back into a classic developer discussion. Yuri also asks or gives us a bit of a suggestion: What about revisiting this topic and doing an episode on hot takes or unpopular topics? Is that something that you'd be interested in, Stephanie? +STEPHANIE: Oh yeah, definitely, because I didn't get to, you know, share my hot topics the last episode [laughs]. [inaudible 24:23] +JOËL: You just got them queued up and ready to go. +STEPHANIE: Yeah, exactly. So, yeah, I will definitely be brainstorming some spicy takes for the show. +JOËL: So, Yuri, thanks for the questions and for the episode suggestion. +STEPHANIE: So, another listener, Kevin, wrote in to us following up from our episode on Module Docs and about a different episode about Multi-dimensional Numbers. And he mentioned a gem that he maintains. It's called Ruby Units. And it basically handles the nitty gritty of unit conversions for you, which I thought was really neat. +He mentioned that it has a numeric class, and it knows how to do math [laughs], which I would find really convenient because that is something that I have been grateful not to have to really do since college [laughs], at least those unit conversions and all the things that I'd probably learned in math and physics courses [laughs]. So, I thought that was really cool, definitely is one to check out if you frequently work with units. It seemed like it would be something that would make sense for a domain that is more science or deals in that kind of domain. +JOËL: I'm always a huge fan of anything that tags raw numbers that you're working with with a quantity rather than just floating raw numbers around. It's so easy to make a mistake to either treat a number as a quantity you didn't think of, or make some sort of invalid operation on it, or even to think you have a value in a different size than you do. You think you're dealing with...you know you have a time value, but you think it's in seconds. It's actually in milliseconds. And then, you get off by some big factor. +These are all mistakes that I have personally made in my career, so leaning on a library to help avoid those mistakes, have better information hiding for the things that really aren't relevant to the work that I'm trying to do, and also, kind of reify these ideas so that they have sort of a name, and they're, like, their own object, their own thing that we can interact with in the app rather than just numbers floating around, those are all big wins from my perspective. +STEPHANIE: I also just thought of a really silly use case for this that is, I don't know, maybe I'll have to experiment with this. But every now and then, I find the need to have to convert a unit, and I just pop into Google, and I'm like, please give me, you know, I'll search for 10 kilometers in miles or something [laughs]. But then I have to...sometimes Google will figure it out for me, and sometimes it will just list me with a bunch of weird conversion websites that all have really old-school UI [laughs]. Do you know what I'm talking about here? +Anyway, I would be curious to see if I could use this gem as a command-line interface [laughs] for me without having to go to my browser and roll the dice with freecalculator.com or something like that [laughs]. +JOËL: One thing that's really cool with this library that I saw is the ability to define your own units, and that's a thing that you'll often encounter having to deal with values that are maybe not one of the most commonly used units that are out there, dealing with numbers that might mean a thing that's very particular to your domain. So, that's great that the library supports that. I couldn't see if it supports multi-dimensional units. That was the episode that inspired the comment. But either way, this is a really cool library. And thank you, Kevin, for sharing this with us. +STEPHANIE: Kevin also mentions that he really enjoys using YARD docs. And we had done that whole episode on Module Docs and your experience writing them. So, you know, your people are out there [laughs]. +JOËL: Yay. +STEPHANIE: And we talked about this a little bit; I think that writing the docs, you know, on one hand, is great for future readers, but, also, I think has the benefit of forcing the author to really think about their inputs and outputs, as Kevin mentions. He's found bugs by simply just going through that process in designing his code, and also recommends Solargraph and Solargraph's VSCode extension, which I suspect really kind of makes it easy to navigate a complex codebase and kind of highlight just what you need to know when working with different APIs for your classes. So, I recently kind of switched to the Ruby LSP, build with Shopify, but I'm currently regretting it because nothing is working for me right now. So, that might be the push that I need [laughs] to go back to using Solargraph. +JOËL: It's interesting that Kevin mentions finding bugs while writing docs because that has absolutely been my experience. And even in this most recent round, I was documenting some code that was just sort of there. It wasn't new code that I was writing. And so, I had given myself the rule that this would be documentation-only PRs, no code changes. And I found some weird code, and I found some code that I'm 98% sure is broken. +And I had to have the discipline to just put a notice in the documentation to be like, "By the way, this is how the method should work. I'm pretty sure it's broken," and then, maybe come back to it later to fix it. But it's amazing how trying to document code, especially code that you didn't write yourself, really forces you to read it in a different way, interact with it in a different way, and really, like, understand it in a deep way that surprised me a little bit the first time I did it. +STEPHANIE: That's cool. I imagine it probably didn't feel good to be like, "Hey, I know that this is broken, and I can't fix it right now," but I'm glad you did. That takes a lot of, I don't know, I think, courage, in my opinion [laughs], to be like, "Yeah, I found this, and I'm going to, you know, like, raise my hand acknowledging that this is how it is," as supposed to just hiding behind a broken functionality that no one [laughs] has paid attention to. +JOËL: And it's a thing where if somebody else uses this method and it breaks in a way, and they're like, "Well, the docs say it should behave like this," that would be really frustrating. If the docs say, "Hey, it should behave like this, but it looks like it's broken," then, you know, I don't know, I would feel a little bit vindicated as a person who's annoyed at the code right now. +STEPHANIE: For sure. +JOËL: Finally, we have a message from Tim about using Postgres' EXPLAIN ANALYZE. Tim says, "Hey, Joël, in the last episode, you talked a bit about PG EXPLAIN ANALYZE. As you stated, it's a great tool to help figure out what's going on with your queries, but there is a caveat you need to keep in mind. The query planner uses statistics gathered on the database when making decisions about how to fetch records. If there's a big difference between your dev or staging database and production, the query may make different decisions. +For example, if a table has a low number of records in it, then the query planner may just do a table scan, but in production, it might use an index. Also, keep in mind that after a schema changes, it may not know about new indexes or whatever unless an explicit ANALYZE is done on the table." So, this is really interesting because, as Tim mentions, EXPLAIN ANALYZE doesn't behave exactly the same in production versus in your local development environment. +STEPHANIE: When you were trying to optimize some slow queries, where were you running the ANALYZE command? +JOËL: I used a combination. I mostly worked off of production data. I did a little bit on a staging database that had not the same amount of records and things. That was pretty significant. And so, I had to switch to production to get realistic results. So, yes, I encountered this kind of firsthand. +STEPHANIE: Nice. For some reason, this comment also made me think of..., and I wanted to plug a thoughtbot shell command that we have called Parity, which lets you basically download your production database into your local dev database if you use Heroku. And that has come in handy for me, obviously, in regular development, but would be really great in this use case. +JOËL: With all of the regular caveats around security, and PII, and all this stuff that come with dealing with production data. But if you're running real productions on production, you should be cleared and, like, trained for access to all of that. I also want to note that the queries that you all worked with on Friday are also from the production database. +STEPHANIE: Really? +JOËL: So, you got to see what it actually does, what the actual timings were. +STEPHANIE: I'm surprised by that because we were using, like, a web-based tool to visualize the query plans. Like, what were you kind of plugging into the tool for it to know? +JOËL: So, the tool accepts a query plan, which is a text output from running a SQL query. +STEPHANIE: Okay. So, it's just visualizing it. +JOËL: Correct. Yeah. So, you've got this query plan, which comes back as this very intimidating block of, like, text, and arrows, and things like that. And you plug it into this web UI, and now you've got something that is kind of interactive, and visual, and you can expand or collapse nodes. And it gives you tooltips on different types of information and where you're spending the most time. So, yeah, it's just a nicer way to visualize that data that comes from the query plan. +STEPHANIE: Gotcha. That makes sense. +JOËL: So, that's a very important caveat. I don't think that's something that we mentioned on the episode. So, thank you, Tim, for highlighting that. And for all of our listeners who were intrigued by leaning into EXPLAIN ANALYZE and query plan viewers to debug your slow queries, make sure you try it out in production because you might get different results otherwise. +STEPHANIE: So, yeah, that about wraps up our listener topics in recent months. On that note, Joël, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + interactive learning, query plans, thoughtbot workshop, breakout rooms, hands-on activities, group discussions, programming workshops, conference learning styles, query optimization, conditional logic in programming, code documentation benefits, Ruby on Rails, Postgres EXPLAIN ANALYZE, community engagement, listener questions, software development podcast, tech industry insights, developer engagement strategies, audio editing techniques, social media marketing for podcasts, operational efficiency in podcast production, inclusive technology advocacy, project management in tech + + Joël conducted a thoughtbot mini-workshop on query plans, which Stephanie found highly effective due to its interactive format. They then discuss the broader value of interactive workshops over traditional talks for deeper learning.

+ +

Addressing listener questions, Stephanie and Joël explore the strategic use of if and else in programming for clearer code, the importance of thorough documentation in identifying bugs, and the use of Postgres' EXPLAIN ANALYZE, highlighting the need for environment-specific considerations in query optimization.

+ + + +

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: Just recently, I ran a sort of mini workshop for some colleagues here at thoughtbot to dig into the idea of query plans and, how to read them, how to use them. And, initially, this was going to be more of a kind of presentation style. And a colleague and I who were sharing this decided to go for a more interactive format where, you know, this is a, like, 45-minute slot.

+ +

And so, we set it up so that we did a sort of intro to query plans in about 10 minutes then 15 minutes of breakout rooms, where people got a chance to have a query plan. And they had some sort of comprehension questions to answer about it. And then, 15 minutes together to have each group share a little bit about what they had discovered in their query plan back with the rest of the group, so trying to balance some understanding, some application, some group discussion, trying to keep it engaging. It was a pretty fun approach to sharing information like that.

+ +

STEPHANIE: Yeah. I wholeheartedly agree. I got to attend that workshop, and it was really great. Now that I'm hearing you kind of talk about the three different components and what you wanted people attending to get out of it, I am impressed because [laughs] there is, like, a lot more thought, I think, that went into just participant engagement that reflecting on it now I'm like, oh yeah, like, I think that was really effective as opposed to just a presentation. Because you had, you know, sent us out into breakout rooms, and each group had a different query that they were analyzing. You had kind of set up links that had the query set up in the query analyzer. I forget what the tool was called that you used.

+ +

JOËL: I forget the name of it, but we will link it in the show notes.

+ +

STEPHANIE: Yeah. It was helpful for me, though, because, you know, I think if I were just to have learned about it in a presentation or even just looked at, you know, screenshots of it on a slide, that's different still from interacting with it and feeling more confident to use it next time I find myself in a situation where it might be helpful.

+ +

JOËL: It's really interesting because that was sort of the goal of it was to make it a bit more interactive and then, hopefully, helping people to retain more information than just a straight up, like, presentation would be. I don't know how you feel, I find that often when I go to a place like, let's say, RailsConf, I tend to stay away from more of the workshop-y style events and focus more on the talks. Is that something that you do as well?

+ +

STEPHANIE: Yeah. I have to confess that I've never attended a workshop [laughs] at a conference. I think it's partly my learning style and also partly just honestly, like, my energy level when I'm at the conference. I kind of just want to sit back. It's on my to-do list. Like, I definitely want to attend one just to see what it's like. And maybe that might even inspire me to want to create my own workshop. But it's like, once I'm in it, and, you know, like, everyone else is also participating, I'm very easily peer pressured [laughs]. So, in a group setting, I will find myself enjoying it a lot more. And I felt that kind of same way with the workshop you ran for our team.

+ +

Though, I will say a funny thing that happened was that when I went out into my breakout group with another co-worker, and we were trying to grok this query that you gave us, we found out that we got the hardest one, the most complicated one [laughs] because there were so many things going on. There was, like, multiple, like, you know, unions, some that were, like, nested, and then just, like, a lot of duplication as well, like, some conditions that were redundant because of a different condition happening inside of, like, an inner statement. And yeah, we were definitely scratching our heads for a bit and were very grateful that we got to come back together as a group and be like, "Can someone please help? [laughs] Let's figure out what's going on here."

+ +

JOËL: Sort of close that loop and like, "Hey, here's what we saw. What does everybody else see?"

+ +

STEPHANIE: Yeah, and I appreciated that you took queries from actual client projects that you were working on.

+ +

JOËL: Yeah, that was the really fun part of it was that these were not sort of made-up queries to illustrate a point. These were actual queries that I had spent some time trying to optimize and where I had had to spend a lot of time digging into the query plans to understand what was going on. And it sounds like, for you, workshops are something that is...they're generally more engaging, and you get more value out of them. But there's higher activation energy to get started. Does that sound right?

+ +

STEPHANIE: Yeah, that sounds right. I think, like, I've watched so many talks now, both in person and on YouTube, that a lot of them are easily forgettable [laughs], whereas I think a workshop would be a lot more memorable because of that interactivity and, you know, you get out of it what you put in a little bit.

+ +

JOËL: Yeah, that's true. Have you looked at the schedule for RailsConf 2024 yet? And are there any workshops on there that you're maybe considering or that maybe have piqued your interest?

+ +

STEPHANIE: I have, in fact, and maybe I will check off attending a workshop [laughs] off my bucket list this year. There are two that I'm excited about. Unfortunately, they're both at the same time slot, so I --

+ +

JOËL: Oh no. You're going to have to choose.

+ +

STEPHANIE: I know. I imagine I'll have to choose. But I'm interested in the Let's Extend Rails With A Gem by Noel Rappin and Vision For Inclusion Workshop run by Todd Sedano. The Rails gem one I'm excited about because it's just something that I haven't had to do really in my dev career so far, and I think I would really appreciate having that guidance. And also, I think that would be motivation to just get that, like, hands-on experience with it. Otherwise, you know, this is something that I could say that I would want to do and then never get [chuckles] around to it.

+ +

JOËL: Right, right. And building a gem is the sort of thing that I think probably fits better in a workshop format than in a talk format.

+ +

STEPHANIE: Yeah. And I've really appreciated all of Noel's content out there. I've found it always really practical, so I imagine that the workshop would be the same.

+ +

JOËL: So, other than poring over the RailsConf schedule and planning your time there, what has been new for you this week?

+ +

STEPHANIE: I have a really silly one [laughs].

+ +

JOËL: Okay.

+ +

STEPHANIE: Which is, yesterday I went out to eat dinner to celebrate my partner's birthday, and I experienced, for the first time, robots [laughter] at this restaurant. So, we went out to Hot Pot, and I guess they just have these, like, robot, you know, little, small dish delivery things. They were, like, as tall as me, almost, at least, like, four feet. They were cat-themed.

+ +

JOËL: [laughs]

+ +

STEPHANIE: So, they had, like...shaped like cat...they had cat ears, and then there was a screen, and on the screen, there was, like, a little face, and the face would, like, wink at you and smile.

+ +

JOËL: Aww.

+ +

STEPHANIE: And I guess how this works is we ordered our food on an iPad, and if you ordered some, like, side dishes and stuff, it would come out to you on this robot cat with wheels.

+ +

JOËL: Very fun.

+ +

STEPHANIE: This robot tower cat. I'm doing a poor job describing it because I'm still apparently bewildered [laughs]. But yeah, I was just so surprised, and I was not as...I think I was more, like, shocked than delighted. I imagine other people would find this, like, very fun. But I was a little bit bewildered [laughs].

+ +

The other thing that was very funny about this experience is that these robots were kind of going down the aisle between tables, and the aisles were not quite big enough for, like, two-way traffic. And so, there were times where I would be, you know, walking up to go use the restroom, and I would turn the corner and find myself, like, face to face with one of these cat robot things, and, like, it's starting to go at me. I don't know if it will stop [laughs], and I'm the kind of person who doesn't want to find out.

+ +

JOËL: [laughs]

+ +

STEPHANIE: So, to avoid colliding with this, you know, food delivery robot, I just, like, ran away from it [laughs].

+ +

JOËL: You don't know if they're, like, programmed to yield or something like that.

+ +

STEPHANIE: Listen, it did not seem like it was going to stop.

+ +

JOËL: [laughs]

+ +

STEPHANIE: It got, like, I was, you know, kind of standing there frozen in paralysis [laughs] for a little while. And then, once it got, I don't know, maybe two or three feet away from me, I was like, okay, like, this is too close for comfort [laughs]. So, that was my, I don't know, my experience at this robot restaurant. Definitely starting to feel like I'm in the, I don't know, is this the future? Someone, please let me know [laughs].

+ +

JOËL: Is this a future that you're excited or happy about, or does this future seem a little bit dystopian to you?

+ +

STEPHANIE: I was definitely alarmed [laughter]. But I'm not, like, a super early adopter of new technology. These kinds of innovations, if you will, always surprise me, and I'm like, oh, I guess this is happening now [laughs]. And I will say that the one thing I did not enjoy about it is that there was not enough room to go around this robot. It definitely created just pedestrian traffic issues. So, perhaps this could be very cool and revolutionary, but also, maybe design robots for humans first.

+ +

JOËL: Or design your dining room to accommodate your vision for the robots. I'm sure that flying cars and robots will solve all of this, for sure.

+ +

STEPHANIE: Oh yeah [laughter]. Then I'll just have to worry about things colliding above my head.

+ +

JOËL: And for the listeners who cannot see my face right now, that was absolutely sarcasm [laughs]. Speaking of our listeners, today we're going to look at a group of different listener questions. And if you didn't know that, you could send in a question to have Stephanie and I discuss, you can do that. Just send us an email at hosts@bikeshed.fm. And sometimes, we put it into a regular episode. Sometimes, we combine a few and sort of make a listener question episode, which is what we're doing today.

+ +

STEPHANIE: Yeah. It's a little bit of a grab bag.

+ +

JOËL: Our first question comes from Yuri, and Yuri actually has a few different questions. But the first one is asking about Episode 349, which is pretty far back. It was my first episode when I was coming on with Chris and Steph, and they were sort of handing the baton to me as a host of the show. And we talked about a variety of hot takes or unpopular opinions.

+ +

Yuri mentions, you know, a few that stood out to him: one about SPAs being not so great, one about how you shouldn't need to have a side project to progress in your career as a developer, one about developer title inflation, one about DRY and how it can be dangerous for a mid-level dev, avoiding let in RSpec specs, the idea that every if should come with an else, and the idea that developers shouldn't be included in design and planning. And Yuri's question is specifically the question about if statements, that every if should come with an else. Is that still an opinion that we still have, and why do we feel that way?

+ +

STEPHANIE: Yeah, I'm excited to get into this because I was not a part of that episode. I was a listener back then when it was still Steph and Chris. So, I am hopefully coming in with a different, like, additional perspective to add as well while we kind of do a little bit of a throwback. So, the one about every if should come with an else, that was an unpopular opinion of yours. Do you mind kind of explaining what that means for you?

+ +

JOËL: Yeah. So, in general, Ruby is an expression-oriented language. So, if you have an if that does not include an else, it will implicitly return nil, which can burn you. There may be some super expert programmers out there that have never run into undefined method for nil nil class, but I'm still the kind of programmer who runs into that every now and then. And so, implicit nils popping up in my code is not something I generally like. I also generally like having explicit else for control flow purposes, making it a little bit clearer where flow of control goes and what are the actual paths through a particular method.

+ +

And then, finally, doing ifs and elses instead of doing them sort of inline or as trailing conditionals or things like that, by having them sort of all on each lines and balancing out. The indentation itself helps to scan the code a little bit more. So, deeper indentation tells you, okay, we're, like, nesting multiple conditions, or something like that. And so, it makes it a little bit easier to spot complexity in the code. You can apply, and I want to say this is from Sandi Metz, the squint test.

+ +

STEPHANIE: Yeah, it is.

+ +

JOËL: Where you just kind of, like, squint at your code so you're not looking at the actual characters, and more of the structure, and the indentation is actually a friend there rather than something to fight. So, that was sort of the original, I think, idea behind that. I'm curious, in your experience, if you would like to balance your conditionals, ifs with something else, or if you would like to do sort of hanging ifs.

+ +

STEPHANIE: Hanging ifs, I like that phrase that you just coined there. I agree with your opinion, and I think it's especially true if you're returning values, right? I mean, in Ruby, you kind of always are. But if you are caring about return values, like you said, to avoid that implicit nil situation, I find, especially if you're writing tests for that code, it's really easy, you know, if you spot that condition, you're like, okay, great. Like, this is a path I need to test.

+ +

But then, oftentimes, you don't test that implicit path, and if you don't enter the condition, then what happens, right? So, I think that's kind of what you're referring to when you talk about both. It's, like, easier to spot in terms of control flow, like, all the different paths of execution, as well as, yeah, like, saving you the headaches of some bugs down the line.

+ +

One thing that I thought about when I was kind of revisiting that opinion of yours is the idea of like, what are you trying to communicate is different or special about this condition when you are writing an if statement? And, in my head, I kind of came up with a few different situations you might find yourself in, which is, one, where you truly just have, like, a special case, and you're treating that completely differently. Another when you have more of a, like, binary situation, where it's you want to kind of highlight either...more of a dichotomy, right? It's not necessarily that there is a default but that these are two opposite things. And then, a third situation in which you have multiple conditions, but you only happen to have two right now.

+ +

JOËL: Interesting. And do you think that, like, breaking down those situations would lead you to pick different structures for writing your conditionals?

+ +

STEPHANIE: I think so.

+ +

JOËL: Which of those scenarios do you think you might be more likely to reach for an if that doesn't have an else that goes with it?

+ +

STEPHANIE: I think that first one, the special case one. And in Yuri's email, he actually asked, as a follow-up, "Do we avoid guard clauses as a result of this kind of heuristic or rule?" And I think that special case situation is where a guard clause would shine because you are highlighting it by putting it at the top of a method, and then saying like, you know, "Bail out of this" or, like, "Return this particular thing, and then don't even bother about the rest of this code."

+ +

JOËL: I like that. And I think guard clauses they're not the first thing I reach for, but they're not something I absolutely avoid. I think they need to be used with care. Like you said, they have to be in the top of your method. If you're adding returns and things that break out of your method, deep inside a conditional somewhere, 20 lines into your method, you don't get to call that a guard clause anymore. That's something else entirely. I think, ideally, guard clauses are also things that will break out of the method, so they're maybe raising exception. Maybe they're returning a value. But they are things that very quickly check edge cases and bail so that the body of the method can focus on expecting data in the correct shape.

+ +

STEPHANIE: I have a couple more thoughts about this; one is I'm reminded of back when we did that episode on kind of retroing Sandi Metz's Rules For Developers. I think one of the rules was: methods should only be five lines of code. And I recall we'd realized, at least I had realized for the first time, that if you write an if-else condition in Ruby, that's exactly five lines [laughs].

+ +

And so, now that I'm thinking about this topic, it's cool to see that a couple of these rules converge a little bit, where there's a bit of explicitness in saying, like, you know, if you're starting to have more conditions that can't just be captured in a five-line if-else statement, then maybe you need something else there, right? Something perhaps like polymorphic or just some way to have branched earlier.

+ +

JOËL: That's true. And so, even, like, you were talking about the exceptional edge cases where you might want to bail. That could be a sign that your method is doing too much, trying to like, validate inputs and also run some sort of algorithm. Maybe this needs to be some sort of, like, two-step thing, where there's almost, like, a parsing phase that's handled by a different object or a different method that will attempt to standardize your inputs and raise the appropriate errors and everything. And then, your method that has the actual algorithm or code that you're trying to run can just assume that its inputs are in the correct shape, kind of that pushing the uncertainty to the edges.

+ +

And, you know, if you've only got one edge case to check, maybe it's not worth to, like, build this in layers, or separate out the responsibilities, or whatever. But if you're having a lot, then maybe it does make sense to say, "Let's break those two responsibilities out into two places."

+ +

STEPHANIE: Yeah. And then, the one last kind of situation I've observed, and I think you all talked about this in the Unpopular Opinions episode, but I'm kind of curious how you would handle it, is side effects that only need to be applied under a certain condition. Because I think that's when, if we're focusing less on return values and more just on behavior, that's when I will usually see, like, an if something, then do this that doesn't need to happen for the other path.

+ +

JOËL: Yes. I guess if you're doing some sort of side effect, like, I don't know, making a request to an API or writing to a file or something, having, like, else return nil or some other sentinel value feels a little bit weird because now you're caring about side effects rather than return values, something that you need to keep thinking of. And that's something where I think my thing has evolved since that episode is, once you start having multiple of these, how do they compose together? So, if you've got if condition, write to a file, no else, keep going. New if condition, make a request to an API endpoint, no else, continue.

+ +

What I've started calling independent conditions now, you have to think about all the different ways that they can combine, and what you end up having is a bit of a combinatorial explosion. So, here we've got two potential actions: writing to a file, making a request to an API. And we could have one or the other, or both, or neither could happen, depending on the inputs to your method, and maybe you actually want that, and that's cool.

+ +

Oftentimes, you didn't necessarily want all of those, especially once you start going to three, four, five. And now you've got that, you know, explosion, like, two to the five. That's a lot of paths through your method. And you probably didn't really need that many. And so, that can get really messy. And so, sometimes the way that an if and an else work where those two paths are mutually exclusive actually cuts down on the total number of paths through your method.

+ +

STEPHANIE: Hmm, I like that. That makes a lot of sense to me. I have definitely seen a lot of, like, procedural code, where it becomes really hard to tell how to even start relating some of these concepts together. So, if you happen to need to run a side effect, like writing to a file or, I don't know, one common one I can think of is notifying something or someone in a particular case, and maybe you put that in a condition. But then there's a different branching path that you also need to kind of notify someone for a similar reason, maybe even the same reason.

+ +

It starts to become hard to connect, like, those two reasons. It's not something that, like, you can really scan for or, like, necessarily make that connection because, at that point, you're going down different paths, right? And there might be other signals that are kind of confusing things along the way. And it makes it a lot harder, I think, to find a shared abstraction, which could ultimately make those really complicated nested conditions a little more manageable or just, like, easier to understand at a certain complexity. I definitely think there is a threshold.

+ +

JOËL: Right. And now you're talking about nested versus non-nested because when conditions are sort of siblings of each other, an if-else behaves differently from two ifs without an else. I think a classic situation where this pops up is when you're structuring code for a wizard, a multi-step form. And, oftentimes, people will have a bunch of checks. They're like, oh, if this field is present, do these things. If this field is present, do these things.

+ +

And then, it becomes very tricky to know what the flow of control is, what you can expect at what moment, and especially which actions might get shared across multiple steps. Is it safe to refactor in one place if you don't want to break step three? And so, learning to think about the different paths through your code and how different conditional structures will impact that, I think, was a big breakthrough for me in terms of taking the next logical step in terms of thinking, when do I want to balance my ifs and when do I not want to? I wrote a whole article on the topic. We'll link it in the show notes.

+ +

So, Yuri, thanks for a great question, bringing us back into a classic developer discussion. Yuri also asks or gives us a bit of a suggestion: What about revisiting this topic and doing an episode on hot takes or unpopular topics? Is that something that you'd be interested in, Stephanie?

+ +

STEPHANIE: Oh yeah, definitely, because I didn't get to, you know, share my hot topics the last episode [laughs]. [inaudible 24:23]

+ +

JOËL: You just got them queued up and ready to go.

+ +

STEPHANIE: Yeah, exactly. So, yeah, I will definitely be brainstorming some spicy takes for the show.

+ +

JOËL: So, Yuri, thanks for the questions and for the episode suggestion.

+ +

STEPHANIE: So, another listener, Kevin, wrote in to us following up from our episode on Module Docs and about a different episode about Multi-dimensional Numbers. And he mentioned a gem that he maintains. It's called Ruby Units. And it basically handles the nitty gritty of unit conversions for you, which I thought was really neat.

+ +

He mentioned that it has a numeric class, and it knows how to do math [laughs], which I would find really convenient because that is something that I have been grateful not to have to really do since college [laughs], at least those unit conversions and all the things that I'd probably learned in math and physics courses [laughs]. So, I thought that was really cool, definitely is one to check out if you frequently work with units. It seemed like it would be something that would make sense for a domain that is more science or deals in that kind of domain.

+ +

JOËL: I'm always a huge fan of anything that tags raw numbers that you're working with with a quantity rather than just floating raw numbers around. It's so easy to make a mistake to either treat a number as a quantity you didn't think of, or make some sort of invalid operation on it, or even to think you have a value in a different size than you do. You think you're dealing with...you know you have a time value, but you think it's in seconds. It's actually in milliseconds. And then, you get off by some big factor.

+ +

These are all mistakes that I have personally made in my career, so leaning on a library to help avoid those mistakes, have better information hiding for the things that really aren't relevant to the work that I'm trying to do, and also, kind of reify these ideas so that they have sort of a name, and they're, like, their own object, their own thing that we can interact with in the app rather than just numbers floating around, those are all big wins from my perspective.

+ +

STEPHANIE: I also just thought of a really silly use case for this that is, I don't know, maybe I'll have to experiment with this. But every now and then, I find the need to have to convert a unit, and I just pop into Google, and I'm like, please give me, you know, I'll search for 10 kilometers in miles or something [laughs]. But then I have to...sometimes Google will figure it out for me, and sometimes it will just list me with a bunch of weird conversion websites that all have really old-school UI [laughs]. Do you know what I'm talking about here?

+ +

Anyway, I would be curious to see if I could use this gem as a command-line interface [laughs] for me without having to go to my browser and roll the dice with freecalculator.com or something like that [laughs].

+ +

JOËL: One thing that's really cool with this library that I saw is the ability to define your own units, and that's a thing that you'll often encounter having to deal with values that are maybe not one of the most commonly used units that are out there, dealing with numbers that might mean a thing that's very particular to your domain. So, that's great that the library supports that. I couldn't see if it supports multi-dimensional units. That was the episode that inspired the comment. But either way, this is a really cool library. And thank you, Kevin, for sharing this with us.

+ +

STEPHANIE: Kevin also mentions that he really enjoys using YARD docs. And we had done that whole episode on Module Docs and your experience writing them. So, you know, your people are out there [laughs].

+ +

JOËL: Yay.

+ +

STEPHANIE: And we talked about this a little bit; I think that writing the docs, you know, on one hand, is great for future readers, but, also, I think has the benefit of forcing the author to really think about their inputs and outputs, as Kevin mentions. He's found bugs by simply just going through that process in designing his code, and also recommends Solargraph and Solargraph's VSCode extension, which I suspect really kind of makes it easy to navigate a complex codebase and kind of highlight just what you need to know when working with different APIs for your classes. So, I recently kind of switched to the Ruby LSP, build with Shopify, but I'm currently regretting it because nothing is working for me right now. So, that might be the push that I need [laughs] to go back to using Solargraph.

+ +

JOËL: It's interesting that Kevin mentions finding bugs while writing docs because that has absolutely been my experience. And even in this most recent round, I was documenting some code that was just sort of there. It wasn't new code that I was writing. And so, I had given myself the rule that this would be documentation-only PRs, no code changes. And I found some weird code, and I found some code that I'm 98% sure is broken.

+ +

And I had to have the discipline to just put a notice in the documentation to be like, "By the way, this is how the method should work. I'm pretty sure it's broken," and then, maybe come back to it later to fix it. But it's amazing how trying to document code, especially code that you didn't write yourself, really forces you to read it in a different way, interact with it in a different way, and really, like, understand it in a deep way that surprised me a little bit the first time I did it.

+ +

STEPHANIE: That's cool. I imagine it probably didn't feel good to be like, "Hey, I know that this is broken, and I can't fix it right now," but I'm glad you did. That takes a lot of, I don't know, I think, courage, in my opinion [laughs], to be like, "Yeah, I found this, and I'm going to, you know, like, raise my hand acknowledging that this is how it is," as supposed to just hiding behind a broken functionality that no one [laughs] has paid attention to.

+ +

JOËL: And it's a thing where if somebody else uses this method and it breaks in a way, and they're like, "Well, the docs say it should behave like this," that would be really frustrating. If the docs say, "Hey, it should behave like this, but it looks like it's broken," then, you know, I don't know, I would feel a little bit vindicated as a person who's annoyed at the code right now.

+ +

STEPHANIE: For sure.

+ +

JOËL: Finally, we have a message from Tim about using Postgres' EXPLAIN ANALYZE. Tim says, "Hey, Joël, in the last episode, you talked a bit about PG EXPLAIN ANALYZE. As you stated, it's a great tool to help figure out what's going on with your queries, but there is a caveat you need to keep in mind. The query planner uses statistics gathered on the database when making decisions about how to fetch records. If there's a big difference between your dev or staging database and production, the query may make different decisions.

+ +

For example, if a table has a low number of records in it, then the query planner may just do a table scan, but in production, it might use an index. Also, keep in mind that after a schema changes, it may not know about new indexes or whatever unless an explicit ANALYZE is done on the table." So, this is really interesting because, as Tim mentions, EXPLAIN ANALYZE doesn't behave exactly the same in production versus in your local development environment.

+ +

STEPHANIE: When you were trying to optimize some slow queries, where were you running the ANALYZE command?

+ +

JOËL: I used a combination. I mostly worked off of production data. I did a little bit on a staging database that had not the same amount of records and things. That was pretty significant. And so, I had to switch to production to get realistic results. So, yes, I encountered this kind of firsthand.

+ +

STEPHANIE: Nice. For some reason, this comment also made me think of..., and I wanted to plug a thoughtbot shell command that we have called Parity, which lets you basically download your production database into your local dev database if you use Heroku. And that has come in handy for me, obviously, in regular development, but would be really great in this use case.

+ +

JOËL: With all of the regular caveats around security, and PII, and all this stuff that come with dealing with production data. But if you're running real productions on production, you should be cleared and, like, trained for access to all of that. I also want to note that the queries that you all worked with on Friday are also from the production database.

+ +

STEPHANIE: Really?

+ +

JOËL: So, you got to see what it actually does, what the actual timings were.

+ +

STEPHANIE: I'm surprised by that because we were using, like, a web-based tool to visualize the query plans. Like, what were you kind of plugging into the tool for it to know?

+ +

JOËL: So, the tool accepts a query plan, which is a text output from running a SQL query.

+ +

STEPHANIE: Okay. So, it's just visualizing it.

+ +

JOËL: Correct. Yeah. So, you've got this query plan, which comes back as this very intimidating block of, like, text, and arrows, and things like that. And you plug it into this web UI, and now you've got something that is kind of interactive, and visual, and you can expand or collapse nodes. And it gives you tooltips on different types of information and where you're spending the most time. So, yeah, it's just a nicer way to visualize that data that comes from the query plan.

+ +

STEPHANIE: Gotcha. That makes sense.

+ +

JOËL: So, that's a very important caveat. I don't think that's something that we mentioned on the episode. So, thank you, Tim, for highlighting that. And for all of our listeners who were intrigued by leaning into EXPLAIN ANALYZE and query plan viewers to debug your slow queries, make sure you try it out in production because you might get different results otherwise.

+ +

STEPHANIE: So, yeah, that about wraps up our listener topics in recent months. On that note, Joël, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël conducted a thoughtbot mini-workshop on query plans, which Stephanie found highly effective due to its interactive format. They then discuss the broader value of interactive workshops over traditional talks for deeper learning.

+ +

Addressing listener questions, Stephanie and Joël explore the strategic use of if and else in programming for clearer code, the importance of thorough documentation in identifying bugs, and the use of Postgres' EXPLAIN ANALYZE, highlighting the need for environment-specific considerations in query optimization.

+ + + +

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: Just recently, I ran a sort of mini workshop for some colleagues here at thoughtbot to dig into the idea of query plans and, how to read them, how to use them. And, initially, this was going to be more of a kind of presentation style. And a colleague and I who were sharing this decided to go for a more interactive format where, you know, this is a, like, 45-minute slot.

+ +

And so, we set it up so that we did a sort of intro to query plans in about 10 minutes then 15 minutes of breakout rooms, where people got a chance to have a query plan. And they had some sort of comprehension questions to answer about it. And then, 15 minutes together to have each group share a little bit about what they had discovered in their query plan back with the rest of the group, so trying to balance some understanding, some application, some group discussion, trying to keep it engaging. It was a pretty fun approach to sharing information like that.

+ +

STEPHANIE: Yeah. I wholeheartedly agree. I got to attend that workshop, and it was really great. Now that I'm hearing you kind of talk about the three different components and what you wanted people attending to get out of it, I am impressed because [laughs] there is, like, a lot more thought, I think, that went into just participant engagement that reflecting on it now I'm like, oh yeah, like, I think that was really effective as opposed to just a presentation. Because you had, you know, sent us out into breakout rooms, and each group had a different query that they were analyzing. You had kind of set up links that had the query set up in the query analyzer. I forget what the tool was called that you used.

+ +

JOËL: I forget the name of it, but we will link it in the show notes.

+ +

STEPHANIE: Yeah. It was helpful for me, though, because, you know, I think if I were just to have learned about it in a presentation or even just looked at, you know, screenshots of it on a slide, that's different still from interacting with it and feeling more confident to use it next time I find myself in a situation where it might be helpful.

+ +

JOËL: It's really interesting because that was sort of the goal of it was to make it a bit more interactive and then, hopefully, helping people to retain more information than just a straight up, like, presentation would be. I don't know how you feel, I find that often when I go to a place like, let's say, RailsConf, I tend to stay away from more of the workshop-y style events and focus more on the talks. Is that something that you do as well?

+ +

STEPHANIE: Yeah. I have to confess that I've never attended a workshop [laughs] at a conference. I think it's partly my learning style and also partly just honestly, like, my energy level when I'm at the conference. I kind of just want to sit back. It's on my to-do list. Like, I definitely want to attend one just to see what it's like. And maybe that might even inspire me to want to create my own workshop. But it's like, once I'm in it, and, you know, like, everyone else is also participating, I'm very easily peer pressured [laughs]. So, in a group setting, I will find myself enjoying it a lot more. And I felt that kind of same way with the workshop you ran for our team.

+ +

Though, I will say a funny thing that happened was that when I went out into my breakout group with another co-worker, and we were trying to grok this query that you gave us, we found out that we got the hardest one, the most complicated one [laughs] because there were so many things going on. There was, like, multiple, like, you know, unions, some that were, like, nested, and then just, like, a lot of duplication as well, like, some conditions that were redundant because of a different condition happening inside of, like, an inner statement. And yeah, we were definitely scratching our heads for a bit and were very grateful that we got to come back together as a group and be like, "Can someone please help? [laughs] Let's figure out what's going on here."

+ +

JOËL: Sort of close that loop and like, "Hey, here's what we saw. What does everybody else see?"

+ +

STEPHANIE: Yeah, and I appreciated that you took queries from actual client projects that you were working on.

+ +

JOËL: Yeah, that was the really fun part of it was that these were not sort of made-up queries to illustrate a point. These were actual queries that I had spent some time trying to optimize and where I had had to spend a lot of time digging into the query plans to understand what was going on. And it sounds like, for you, workshops are something that is...they're generally more engaging, and you get more value out of them. But there's higher activation energy to get started. Does that sound right?

+ +

STEPHANIE: Yeah, that sounds right. I think, like, I've watched so many talks now, both in person and on YouTube, that a lot of them are easily forgettable [laughs], whereas I think a workshop would be a lot more memorable because of that interactivity and, you know, you get out of it what you put in a little bit.

+ +

JOËL: Yeah, that's true. Have you looked at the schedule for RailsConf 2024 yet? And are there any workshops on there that you're maybe considering or that maybe have piqued your interest?

+ +

STEPHANIE: I have, in fact, and maybe I will check off attending a workshop [laughs] off my bucket list this year. There are two that I'm excited about. Unfortunately, they're both at the same time slot, so I --

+ +

JOËL: Oh no. You're going to have to choose.

+ +

STEPHANIE: I know. I imagine I'll have to choose. But I'm interested in the Let's Extend Rails With A Gem by Noel Rappin and Vision For Inclusion Workshop run by Todd Sedano. The Rails gem one I'm excited about because it's just something that I haven't had to do really in my dev career so far, and I think I would really appreciate having that guidance. And also, I think that would be motivation to just get that, like, hands-on experience with it. Otherwise, you know, this is something that I could say that I would want to do and then never get [chuckles] around to it.

+ +

JOËL: Right, right. And building a gem is the sort of thing that I think probably fits better in a workshop format than in a talk format.

+ +

STEPHANIE: Yeah. And I've really appreciated all of Noel's content out there. I've found it always really practical, so I imagine that the workshop would be the same.

+ +

JOËL: So, other than poring over the RailsConf schedule and planning your time there, what has been new for you this week?

+ +

STEPHANIE: I have a really silly one [laughs].

+ +

JOËL: Okay.

+ +

STEPHANIE: Which is, yesterday I went out to eat dinner to celebrate my partner's birthday, and I experienced, for the first time, robots [laughter] at this restaurant. So, we went out to Hot Pot, and I guess they just have these, like, robot, you know, little, small dish delivery things. They were, like, as tall as me, almost, at least, like, four feet. They were cat-themed.

+ +

JOËL: [laughs]

+ +

STEPHANIE: So, they had, like...shaped like cat...they had cat ears, and then there was a screen, and on the screen, there was, like, a little face, and the face would, like, wink at you and smile.

+ +

JOËL: Aww.

+ +

STEPHANIE: And I guess how this works is we ordered our food on an iPad, and if you ordered some, like, side dishes and stuff, it would come out to you on this robot cat with wheels.

+ +

JOËL: Very fun.

+ +

STEPHANIE: This robot tower cat. I'm doing a poor job describing it because I'm still apparently bewildered [laughs]. But yeah, I was just so surprised, and I was not as...I think I was more, like, shocked than delighted. I imagine other people would find this, like, very fun. But I was a little bit bewildered [laughs].

+ +

The other thing that was very funny about this experience is that these robots were kind of going down the aisle between tables, and the aisles were not quite big enough for, like, two-way traffic. And so, there were times where I would be, you know, walking up to go use the restroom, and I would turn the corner and find myself, like, face to face with one of these cat robot things, and, like, it's starting to go at me. I don't know if it will stop [laughs], and I'm the kind of person who doesn't want to find out.

+ +

JOËL: [laughs]

+ +

STEPHANIE: So, to avoid colliding with this, you know, food delivery robot, I just, like, ran away from it [laughs].

+ +

JOËL: You don't know if they're, like, programmed to yield or something like that.

+ +

STEPHANIE: Listen, it did not seem like it was going to stop.

+ +

JOËL: [laughs]

+ +

STEPHANIE: It got, like, I was, you know, kind of standing there frozen in paralysis [laughs] for a little while. And then, once it got, I don't know, maybe two or three feet away from me, I was like, okay, like, this is too close for comfort [laughs]. So, that was my, I don't know, my experience at this robot restaurant. Definitely starting to feel like I'm in the, I don't know, is this the future? Someone, please let me know [laughs].

+ +

JOËL: Is this a future that you're excited or happy about, or does this future seem a little bit dystopian to you?

+ +

STEPHANIE: I was definitely alarmed [laughter]. But I'm not, like, a super early adopter of new technology. These kinds of innovations, if you will, always surprise me, and I'm like, oh, I guess this is happening now [laughs]. And I will say that the one thing I did not enjoy about it is that there was not enough room to go around this robot. It definitely created just pedestrian traffic issues. So, perhaps this could be very cool and revolutionary, but also, maybe design robots for humans first.

+ +

JOËL: Or design your dining room to accommodate your vision for the robots. I'm sure that flying cars and robots will solve all of this, for sure.

+ +

STEPHANIE: Oh yeah [laughter]. Then I'll just have to worry about things colliding above my head.

+ +

JOËL: And for the listeners who cannot see my face right now, that was absolutely sarcasm [laughs]. Speaking of our listeners, today we're going to look at a group of different listener questions. And if you didn't know that, you could send in a question to have Stephanie and I discuss, you can do that. Just send us an email at hosts@bikeshed.fm. And sometimes, we put it into a regular episode. Sometimes, we combine a few and sort of make a listener question episode, which is what we're doing today.

+ +

STEPHANIE: Yeah. It's a little bit of a grab bag.

+ +

JOËL: Our first question comes from Yuri, and Yuri actually has a few different questions. But the first one is asking about Episode 349, which is pretty far back. It was my first episode when I was coming on with Chris and Steph, and they were sort of handing the baton to me as a host of the show. And we talked about a variety of hot takes or unpopular opinions.

+ +

Yuri mentions, you know, a few that stood out to him: one about SPAs being not so great, one about how you shouldn't need to have a side project to progress in your career as a developer, one about developer title inflation, one about DRY and how it can be dangerous for a mid-level dev, avoiding let in RSpec specs, the idea that every if should come with an else, and the idea that developers shouldn't be included in design and planning. And Yuri's question is specifically the question about if statements, that every if should come with an else. Is that still an opinion that we still have, and why do we feel that way?

+ +

STEPHANIE: Yeah, I'm excited to get into this because I was not a part of that episode. I was a listener back then when it was still Steph and Chris. So, I am hopefully coming in with a different, like, additional perspective to add as well while we kind of do a little bit of a throwback. So, the one about every if should come with an else, that was an unpopular opinion of yours. Do you mind kind of explaining what that means for you?

+ +

JOËL: Yeah. So, in general, Ruby is an expression-oriented language. So, if you have an if that does not include an else, it will implicitly return nil, which can burn you. There may be some super expert programmers out there that have never run into undefined method for nil nil class, but I'm still the kind of programmer who runs into that every now and then. And so, implicit nils popping up in my code is not something I generally like. I also generally like having explicit else for control flow purposes, making it a little bit clearer where flow of control goes and what are the actual paths through a particular method.

+ +

And then, finally, doing ifs and elses instead of doing them sort of inline or as trailing conditionals or things like that, by having them sort of all on each lines and balancing out. The indentation itself helps to scan the code a little bit more. So, deeper indentation tells you, okay, we're, like, nesting multiple conditions, or something like that. And so, it makes it a little bit easier to spot complexity in the code. You can apply, and I want to say this is from Sandi Metz, the squint test.

+ +

STEPHANIE: Yeah, it is.

+ +

JOËL: Where you just kind of, like, squint at your code so you're not looking at the actual characters, and more of the structure, and the indentation is actually a friend there rather than something to fight. So, that was sort of the original, I think, idea behind that. I'm curious, in your experience, if you would like to balance your conditionals, ifs with something else, or if you would like to do sort of hanging ifs.

+ +

STEPHANIE: Hanging ifs, I like that phrase that you just coined there. I agree with your opinion, and I think it's especially true if you're returning values, right? I mean, in Ruby, you kind of always are. But if you are caring about return values, like you said, to avoid that implicit nil situation, I find, especially if you're writing tests for that code, it's really easy, you know, if you spot that condition, you're like, okay, great. Like, this is a path I need to test.

+ +

But then, oftentimes, you don't test that implicit path, and if you don't enter the condition, then what happens, right? So, I think that's kind of what you're referring to when you talk about both. It's, like, easier to spot in terms of control flow, like, all the different paths of execution, as well as, yeah, like, saving you the headaches of some bugs down the line.

+ +

One thing that I thought about when I was kind of revisiting that opinion of yours is the idea of like, what are you trying to communicate is different or special about this condition when you are writing an if statement? And, in my head, I kind of came up with a few different situations you might find yourself in, which is, one, where you truly just have, like, a special case, and you're treating that completely differently. Another when you have more of a, like, binary situation, where it's you want to kind of highlight either...more of a dichotomy, right? It's not necessarily that there is a default but that these are two opposite things. And then, a third situation in which you have multiple conditions, but you only happen to have two right now.

+ +

JOËL: Interesting. And do you think that, like, breaking down those situations would lead you to pick different structures for writing your conditionals?

+ +

STEPHANIE: I think so.

+ +

JOËL: Which of those scenarios do you think you might be more likely to reach for an if that doesn't have an else that goes with it?

+ +

STEPHANIE: I think that first one, the special case one. And in Yuri's email, he actually asked, as a follow-up, "Do we avoid guard clauses as a result of this kind of heuristic or rule?" And I think that special case situation is where a guard clause would shine because you are highlighting it by putting it at the top of a method, and then saying like, you know, "Bail out of this" or, like, "Return this particular thing, and then don't even bother about the rest of this code."

+ +

JOËL: I like that. And I think guard clauses they're not the first thing I reach for, but they're not something I absolutely avoid. I think they need to be used with care. Like you said, they have to be in the top of your method. If you're adding returns and things that break out of your method, deep inside a conditional somewhere, 20 lines into your method, you don't get to call that a guard clause anymore. That's something else entirely. I think, ideally, guard clauses are also things that will break out of the method, so they're maybe raising exception. Maybe they're returning a value. But they are things that very quickly check edge cases and bail so that the body of the method can focus on expecting data in the correct shape.

+ +

STEPHANIE: I have a couple more thoughts about this; one is I'm reminded of back when we did that episode on kind of retroing Sandi Metz's Rules For Developers. I think one of the rules was: methods should only be five lines of code. And I recall we'd realized, at least I had realized for the first time, that if you write an if-else condition in Ruby, that's exactly five lines [laughs].

+ +

And so, now that I'm thinking about this topic, it's cool to see that a couple of these rules converge a little bit, where there's a bit of explicitness in saying, like, you know, if you're starting to have more conditions that can't just be captured in a five-line if-else statement, then maybe you need something else there, right? Something perhaps like polymorphic or just some way to have branched earlier.

+ +

JOËL: That's true. And so, even, like, you were talking about the exceptional edge cases where you might want to bail. That could be a sign that your method is doing too much, trying to like, validate inputs and also run some sort of algorithm. Maybe this needs to be some sort of, like, two-step thing, where there's almost, like, a parsing phase that's handled by a different object or a different method that will attempt to standardize your inputs and raise the appropriate errors and everything. And then, your method that has the actual algorithm or code that you're trying to run can just assume that its inputs are in the correct shape, kind of that pushing the uncertainty to the edges.

+ +

And, you know, if you've only got one edge case to check, maybe it's not worth to, like, build this in layers, or separate out the responsibilities, or whatever. But if you're having a lot, then maybe it does make sense to say, "Let's break those two responsibilities out into two places."

+ +

STEPHANIE: Yeah. And then, the one last kind of situation I've observed, and I think you all talked about this in the Unpopular Opinions episode, but I'm kind of curious how you would handle it, is side effects that only need to be applied under a certain condition. Because I think that's when, if we're focusing less on return values and more just on behavior, that's when I will usually see, like, an if something, then do this that doesn't need to happen for the other path.

+ +

JOËL: Yes. I guess if you're doing some sort of side effect, like, I don't know, making a request to an API or writing to a file or something, having, like, else return nil or some other sentinel value feels a little bit weird because now you're caring about side effects rather than return values, something that you need to keep thinking of. And that's something where I think my thing has evolved since that episode is, once you start having multiple of these, how do they compose together? So, if you've got if condition, write to a file, no else, keep going. New if condition, make a request to an API endpoint, no else, continue.

+ +

What I've started calling independent conditions now, you have to think about all the different ways that they can combine, and what you end up having is a bit of a combinatorial explosion. So, here we've got two potential actions: writing to a file, making a request to an API. And we could have one or the other, or both, or neither could happen, depending on the inputs to your method, and maybe you actually want that, and that's cool.

+ +

Oftentimes, you didn't necessarily want all of those, especially once you start going to three, four, five. And now you've got that, you know, explosion, like, two to the five. That's a lot of paths through your method. And you probably didn't really need that many. And so, that can get really messy. And so, sometimes the way that an if and an else work where those two paths are mutually exclusive actually cuts down on the total number of paths through your method.

+ +

STEPHANIE: Hmm, I like that. That makes a lot of sense to me. I have definitely seen a lot of, like, procedural code, where it becomes really hard to tell how to even start relating some of these concepts together. So, if you happen to need to run a side effect, like writing to a file or, I don't know, one common one I can think of is notifying something or someone in a particular case, and maybe you put that in a condition. But then there's a different branching path that you also need to kind of notify someone for a similar reason, maybe even the same reason.

+ +

It starts to become hard to connect, like, those two reasons. It's not something that, like, you can really scan for or, like, necessarily make that connection because, at that point, you're going down different paths, right? And there might be other signals that are kind of confusing things along the way. And it makes it a lot harder, I think, to find a shared abstraction, which could ultimately make those really complicated nested conditions a little more manageable or just, like, easier to understand at a certain complexity. I definitely think there is a threshold.

+ +

JOËL: Right. And now you're talking about nested versus non-nested because when conditions are sort of siblings of each other, an if-else behaves differently from two ifs without an else. I think a classic situation where this pops up is when you're structuring code for a wizard, a multi-step form. And, oftentimes, people will have a bunch of checks. They're like, oh, if this field is present, do these things. If this field is present, do these things.

+ +

And then, it becomes very tricky to know what the flow of control is, what you can expect at what moment, and especially which actions might get shared across multiple steps. Is it safe to refactor in one place if you don't want to break step three? And so, learning to think about the different paths through your code and how different conditional structures will impact that, I think, was a big breakthrough for me in terms of taking the next logical step in terms of thinking, when do I want to balance my ifs and when do I not want to? I wrote a whole article on the topic. We'll link it in the show notes.

+ +

So, Yuri, thanks for a great question, bringing us back into a classic developer discussion. Yuri also asks or gives us a bit of a suggestion: What about revisiting this topic and doing an episode on hot takes or unpopular topics? Is that something that you'd be interested in, Stephanie?

+ +

STEPHANIE: Oh yeah, definitely, because I didn't get to, you know, share my hot topics the last episode [laughs]. [inaudible 24:23]

+ +

JOËL: You just got them queued up and ready to go.

+ +

STEPHANIE: Yeah, exactly. So, yeah, I will definitely be brainstorming some spicy takes for the show.

+ +

JOËL: So, Yuri, thanks for the questions and for the episode suggestion.

+ +

STEPHANIE: So, another listener, Kevin, wrote in to us following up from our episode on Module Docs and about a different episode about Multi-dimensional Numbers. And he mentioned a gem that he maintains. It's called Ruby Units. And it basically handles the nitty gritty of unit conversions for you, which I thought was really neat.

+ +

He mentioned that it has a numeric class, and it knows how to do math [laughs], which I would find really convenient because that is something that I have been grateful not to have to really do since college [laughs], at least those unit conversions and all the things that I'd probably learned in math and physics courses [laughs]. So, I thought that was really cool, definitely is one to check out if you frequently work with units. It seemed like it would be something that would make sense for a domain that is more science or deals in that kind of domain.

+ +

JOËL: I'm always a huge fan of anything that tags raw numbers that you're working with with a quantity rather than just floating raw numbers around. It's so easy to make a mistake to either treat a number as a quantity you didn't think of, or make some sort of invalid operation on it, or even to think you have a value in a different size than you do. You think you're dealing with...you know you have a time value, but you think it's in seconds. It's actually in milliseconds. And then, you get off by some big factor.

+ +

These are all mistakes that I have personally made in my career, so leaning on a library to help avoid those mistakes, have better information hiding for the things that really aren't relevant to the work that I'm trying to do, and also, kind of reify these ideas so that they have sort of a name, and they're, like, their own object, their own thing that we can interact with in the app rather than just numbers floating around, those are all big wins from my perspective.

+ +

STEPHANIE: I also just thought of a really silly use case for this that is, I don't know, maybe I'll have to experiment with this. But every now and then, I find the need to have to convert a unit, and I just pop into Google, and I'm like, please give me, you know, I'll search for 10 kilometers in miles or something [laughs]. But then I have to...sometimes Google will figure it out for me, and sometimes it will just list me with a bunch of weird conversion websites that all have really old-school UI [laughs]. Do you know what I'm talking about here?

+ +

Anyway, I would be curious to see if I could use this gem as a command-line interface [laughs] for me without having to go to my browser and roll the dice with freecalculator.com or something like that [laughs].

+ +

JOËL: One thing that's really cool with this library that I saw is the ability to define your own units, and that's a thing that you'll often encounter having to deal with values that are maybe not one of the most commonly used units that are out there, dealing with numbers that might mean a thing that's very particular to your domain. So, that's great that the library supports that. I couldn't see if it supports multi-dimensional units. That was the episode that inspired the comment. But either way, this is a really cool library. And thank you, Kevin, for sharing this with us.

+ +

STEPHANIE: Kevin also mentions that he really enjoys using YARD docs. And we had done that whole episode on Module Docs and your experience writing them. So, you know, your people are out there [laughs].

+ +

JOËL: Yay.

+ +

STEPHANIE: And we talked about this a little bit; I think that writing the docs, you know, on one hand, is great for future readers, but, also, I think has the benefit of forcing the author to really think about their inputs and outputs, as Kevin mentions. He's found bugs by simply just going through that process in designing his code, and also recommends Solargraph and Solargraph's VSCode extension, which I suspect really kind of makes it easy to navigate a complex codebase and kind of highlight just what you need to know when working with different APIs for your classes. So, I recently kind of switched to the Ruby LSP, build with Shopify, but I'm currently regretting it because nothing is working for me right now. So, that might be the push that I need [laughs] to go back to using Solargraph.

+ +

JOËL: It's interesting that Kevin mentions finding bugs while writing docs because that has absolutely been my experience. And even in this most recent round, I was documenting some code that was just sort of there. It wasn't new code that I was writing. And so, I had given myself the rule that this would be documentation-only PRs, no code changes. And I found some weird code, and I found some code that I'm 98% sure is broken.

+ +

And I had to have the discipline to just put a notice in the documentation to be like, "By the way, this is how the method should work. I'm pretty sure it's broken," and then, maybe come back to it later to fix it. But it's amazing how trying to document code, especially code that you didn't write yourself, really forces you to read it in a different way, interact with it in a different way, and really, like, understand it in a deep way that surprised me a little bit the first time I did it.

+ +

STEPHANIE: That's cool. I imagine it probably didn't feel good to be like, "Hey, I know that this is broken, and I can't fix it right now," but I'm glad you did. That takes a lot of, I don't know, I think, courage, in my opinion [laughs], to be like, "Yeah, I found this, and I'm going to, you know, like, raise my hand acknowledging that this is how it is," as supposed to just hiding behind a broken functionality that no one [laughs] has paid attention to.

+ +

JOËL: And it's a thing where if somebody else uses this method and it breaks in a way, and they're like, "Well, the docs say it should behave like this," that would be really frustrating. If the docs say, "Hey, it should behave like this, but it looks like it's broken," then, you know, I don't know, I would feel a little bit vindicated as a person who's annoyed at the code right now.

+ +

STEPHANIE: For sure.

+ +

JOËL: Finally, we have a message from Tim about using Postgres' EXPLAIN ANALYZE. Tim says, "Hey, Joël, in the last episode, you talked a bit about PG EXPLAIN ANALYZE. As you stated, it's a great tool to help figure out what's going on with your queries, but there is a caveat you need to keep in mind. The query planner uses statistics gathered on the database when making decisions about how to fetch records. If there's a big difference between your dev or staging database and production, the query may make different decisions.

+ +

For example, if a table has a low number of records in it, then the query planner may just do a table scan, but in production, it might use an index. Also, keep in mind that after a schema changes, it may not know about new indexes or whatever unless an explicit ANALYZE is done on the table." So, this is really interesting because, as Tim mentions, EXPLAIN ANALYZE doesn't behave exactly the same in production versus in your local development environment.

+ +

STEPHANIE: When you were trying to optimize some slow queries, where were you running the ANALYZE command?

+ +

JOËL: I used a combination. I mostly worked off of production data. I did a little bit on a staging database that had not the same amount of records and things. That was pretty significant. And so, I had to switch to production to get realistic results. So, yes, I encountered this kind of firsthand.

+ +

STEPHANIE: Nice. For some reason, this comment also made me think of..., and I wanted to plug a thoughtbot shell command that we have called Parity, which lets you basically download your production database into your local dev database if you use Heroku. And that has come in handy for me, obviously, in regular development, but would be really great in this use case.

+ +

JOËL: With all of the regular caveats around security, and PII, and all this stuff that come with dealing with production data. But if you're running real productions on production, you should be cleared and, like, trained for access to all of that. I also want to note that the queries that you all worked with on Friday are also from the production database.

+ +

STEPHANIE: Really?

+ +

JOËL: So, you got to see what it actually does, what the actual timings were.

+ +

STEPHANIE: I'm surprised by that because we were using, like, a web-based tool to visualize the query plans. Like, what were you kind of plugging into the tool for it to know?

+ +

JOËL: So, the tool accepts a query plan, which is a text output from running a SQL query.

+ +

STEPHANIE: Okay. So, it's just visualizing it.

+ +

JOËL: Correct. Yeah. So, you've got this query plan, which comes back as this very intimidating block of, like, text, and arrows, and things like that. And you plug it into this web UI, and now you've got something that is kind of interactive, and visual, and you can expand or collapse nodes. And it gives you tooltips on different types of information and where you're spending the most time. So, yeah, it's just a nicer way to visualize that data that comes from the query plan.

+ +

STEPHANIE: Gotcha. That makes sense.

+ +

JOËL: So, that's a very important caveat. I don't think that's something that we mentioned on the episode. So, thank you, Tim, for highlighting that. And for all of our listeners who were intrigued by leaning into EXPLAIN ANALYZE and query plan viewers to debug your slow queries, make sure you try it out in production because you might get different results otherwise.

+ +

STEPHANIE: So, yeah, that about wraps up our listener topics in recent months. On that note, Joël, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+QW-rUE0M + + ]]> + + Joël Quenneville + Stephanie Minn + + + 421: The Idealistic vs. Pragmatic Programmer + https://bikeshed.thoughtbot.com/421 + 7e5b7569-f5b2-4b51-bc58-b678755e6f6f + Tue, 02 Apr 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie revisits the concept of "spiking"—a phase of exploration to determine the feasibility of a technical implementation or to address unknowns in feature requests—sharing her recent experiences with a legacy Rails application. Joël brings a different perspective by discussing his involvement with a client project that heavily utilizes the dry-rb suite of gems, highlighting the learning curve associated with adapting to new patterns and libraries. + +Joël used to be much more idealistic and has moved to be more pragmatic. Stephanie has moved the other way. So together, Stephanie and Joël engage in a philosophical discussion on being an idealistic versus a pragmatic programmer. They explore the concept of programming as a blend of science and art, where technical decisions are not only about solving problems but also about expressing ideas and building shared understandings within a team. + 41:01 + no + + + Stephanie revisits the concept of "spiking"—a phase of exploration to determine the feasibility of a technical implementation or to address unknowns in feature requests—sharing her recent experiences with a legacy Rails application. Joël brings a different perspective by discussing his involvement with a client project that heavily utilizes the dry-rb suite of gems, highlighting the learning curve associated with adapting to new patterns and libraries. +Joël used to be much more idealistic and has moved to be more pragmatic. Stephanie has moved the other way. So together, Stephanie and Joël engage in a philosophical discussion on being an idealistic versus a pragmatic programmer. They explore the concept of programming as a blend of science and art, where technical decisions are not only about solving problems but also about expressing ideas and building shared understandings within a team. +Spike tasks episode (https://bikeshed.thoughtbot.com/414) +dry-rb (https://dry-rb.org/) +Working with Maybe talk (https://www.youtube.com/watch?v=43eM4kNbb6c) +Problem solving with maybe (https://thoughtbot.com/blog/problem-solving-with-maybe) +Programming as Theory Building (https://pablo.rauzy.name/dev/naur1985programming.pdf) +The Pragmatic Programmer (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) +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, a few weeks ago, we did an episode on spiking in response to a listener question. And I wanted to kind of revisit that topic for a little bit because I've been doing a lot of spiking on my client project. And for those who are not familiar, the way that I understand or define spikes is kind of as an exploration phase to figure out if a technical implementation might work. Or if you have a feature request with some unknowns, you can spend some time-boxed spiking to figure out what those unknowns might be. +And I'm working on your typical legacy Rails application [laughs]. And I think one thing that we talked about last time was this idea of, at what point does spiking end up being just working on the feature [laughs]? And I think that's especially true in an older codebase, where you kind of have to go down a few rabbit holes, maybe, just to even find out if something will trip you up down the line. +And the way I approached that this time around was just, like, identifying the constraints and putting a little flag there for myself. Like, these were rabbit holes that I could go down, but, you know, towards the initial beginning phase of doing the spiking, I decided not to. I just kind of bookmarked it for later. +And once I had identified the main constraints, that was when I was like, okay, like, what kind of solutions can I come up with for these constraints? And that actually then helped me kind of decide which ones we're pursuing a little bit more to get, like, the information I needed to ultimately make a decision about whether this was worth doing, right? +It kind of kept me...I'm thinking about, you know, when you are bowling with those safety guards [laughs], it keeps your ball from just rolling into the gutter. I think it helped with not going too deep into places that I may or may not be super fruitful while also, I think, giving me enough information to have a more realistic understanding of, like, what this work would entail. +JOËL: Would you say that this approach that you're taking is inspired or maybe informed by the conversation we had on the episode? +STEPHANIE: I was especially interested in avoiding the kind of binary of like, no, we can't do this because the system just, you know, isn't able to support it, or it's just too...it would be too much work. That was something I was really, like you said, kind of inspired by after that conversation because I wanted to avoid that trap a little bit. +And I think another really helpful framing was the idea of, like, okay, what would need to be done in order to get us to a place where this could be possible? And that's why I think identifying those constraints was important because they're not constraints forever. Like, we could do something about them if we really wanted to, so kind of avoiding the, like, it's not possible, right? And saying like, "It could be. Here's all the things that we need to do in order to make it possible." But I think that helped shift the conversation, especially with stakeholders and stuff, to be a little bit more realistic and collaborative. +So, Joël, what's new in your world? +JOËL: So, I'm also on a new client project, and a thing that's been really interesting in this codebase is that they've been using the dry-rb suite of gems pretty heavily. And I've seen a lot about the suite of gems. I've read about them. Interestingly, this is kind of the first time that I've been on a codebase that sort of uses them as a main pattern in the app. So, there's been a bit of a learning curve there, and it's been really interesting. +STEPHANIE: This is exciting to me because I know you have a lot of functional programming background, also, so it's kind of surprising that you're only now, you know, using something that explicit from functional languages in Ruby. And I'm curious: what's the learning curve, if not the paradigm? Like, what are you kind of encountering? +JOËL: I think there's a little bit of just the translation. How do these gems sort of approach this? So, they have to do a couple of, like, clever Ruby things to make some of these features work. Some of these also will have different method names, so a lot of just familiarizing myself with the libraries. Like, oh, well, this thing that I'm used to having called a particular thing has a slightly different name here or maybe not having all of the utilities. I was like, oh, how do we traverse with this particular library? Then you have to, like, look it up. +So, it's a lot of like, how do I do this thing I know how to do in, let's say, Elm? How do I translate that into Ruby? But then, also, some of the interplay of how that works in code that also does some very kind of imperative side effecty things also written by a team that is getting used to the pattern. And so, you'll sort of see things where people are pulling things in, but maybe you don't fully understand the deeper underlying approach that's meant to be used. +STEPHANIE: Have you noticed any use cases where the dry-rb patterns really shine in your application? +JOËL: A thing that's nice is that I think it really forces you to think about your edge cases in a way that sometimes Ruby developers play very fast and loose with "Yeah, whatever, it will never be nil." Push to production immediately start getting NoMethodError in your bug tracker. I never do this, by the way, but you know. +STEPHANIE: [laughs]. +JOËL: Speaking from a friend's experience [laughs]. +STEPHANIE: Asking for a friend, yeah [laughs]. +JOËL: I think a thing that I've sort of had to figure out sort of every time I deal with these patterns in different languages is just the importance of good composition and good separation. Because you're adding these sort of wrapper context around things, if you're constantly wrapping and unwrapping, you're like, check things inside, and then do the next thing, and then unwrap again and branch and check and do the next thing, that code becomes really clunky in a way that you just sort of expect to do if you're just writing code in regular Ruby with a nil. But it doesn't really work with a dry-rb maybe or a result. +So, the pattern that I have found that works really well is to extract sort of every operation that can be, let's say, that could fail so that it would give you a result back. Extract that out into its own separate function that will construct a success or a failure, and then have your sort of main code that wants to then do a bunch of these things together. +All it does is use some of the dry-rb helper methods to compose all of these together, whether that's just some sort of, like, do notation, or binding, or fmap, or something like that, which allows you to have sort of individual chunks that can fail, and then one sort of aggregator piece of code that just finds a way to combine all of them nicely. And that avoids you having to do all this repetition. +STEPHANIE: Yeah, that makes a lot of sense. +JOËL: It's a pattern, I think; I had to learn the hard way when I was working with Elm. Because if you're taking a potential nullable value and then you want to do things with it but then that potential operation is also nullable because the input was potentially null, and then that just sort of propagates all the way down the chain. So, my whole chain of functions now is doing checks for nullability. And in Ruby, I could just be like, no, I checked it in the first function. I can then just trust that it's not null down the chain. +Elm doesn't do the like, trust me, bro. The compiler will force you to validate every time, and then the code just blows up, and it gets really painful. So, I had to start thinking about new models of thinking that would separate out code that actually needs to care and code that doesn't need to care about nullability. And I wrote an article about that. That turned into actually a conference talk as well. And these sort of ideas have served me really well at Elm. And I think these translate pretty well to dry-rb as well. That's something that I'm exploring, but the principles seem like they're not tied to a particular language. +STEPHANIE: Yeah, and it's kind of cool that you experienced all of that in working with Elm, where a compiler was there to yell at you [laughs] and kind of forcing you to...I don't know if do the right thing is the right word, but kind of think in the way that it wants you to think. And I can see people who are coming from Ruby and starting to experiment with dry-rb maybe needing a bit of that since it's not built-in in the tooling, just in a recoder view or just in conversations among devs. +JOËL: [inaudible 09:26] Beyond just the idea of wrapping your values and making sure you check them all the time, there are patterns that make that easier or more painful. And even in something like Elm, the compiler would yell at me would make sure I could not have a runtime error by forgetting to check for nullability. It did not prevent me from writing monstrosities of nested repeated conditionals checking if nil, if nil, if nil. That I had to figure out some sort of, like, higher-level patterns that play nicely with that kind of software. +And I think these are things that people have to sort of encounter, feel the pain, feel the frustration, and then move into those better patterns after the fact. And sometimes that's not easy because it's not obvious why that's a valuable pattern to approach. +STEPHANIE: Yeah, I agree completely. Speaking of following patterns and kind of arriving at maybe an ideal version of [chuckles], you know, what you'd like your code to do, you know, to build what you are looking to build [laughs]...this is my very poor attempt at a smooth transition that Joël [laughter] manages to be able to do [laughs] whenever we're trying to shift into the topic of the episode. Anyway, today, we were hoping to talk a little bit about this idea between being an idealistic programmer and a pragmatic programmer and the different journeys that we've each been on in arriving kind of how to balance the two. +JOËL: Yeah, you know, I think neither of these are absolutes, right? It's a spectrum. You probably move around that spectrum from day to day, and then probably, like, more general trends over your career. But I'm curious, for you today, if you had to pick one of those labels, like, which sort of zone of the spectrum would you put yourself in? Do you think you're more idealistic or more pragmatic? +STEPHANIE: I think I'm in a more of an idealistic zone right now. +JOËL: Would you say you're kind of like middle trending idealistic or kind of, like, pretty far down the idealistic side? +STEPHANIE: Middle trending idealistic. I like that way of describing it. I want to know where you are. And then I kind of wanted to try to take a step back and even define what that means for both of us. +JOËL: Right, right. I think the way I'd probably describe myself is a recovering idealist. +STEPHANIE: Oof. Yeah [laughs]. +JOËL: I think there was a time where I was really idealistic. I really like knowing sort of underlying theory of software construction, broader patterns. By patterns here, I don't mean necessarily, like, you know, the Gang of Four, but just general sort of approaches that work well and using that to guide my work. But I've also been trending a lot more into the, like, pragmatic side of things in the past few years. +STEPHANIE: So, could you kind of tell me a little bit about what does pragmatic mean for you and what does ideal mean for you? +JOËL: So, I think the pragmatic side of me it's about delivering working software. If you're not shipping anything, you know, the most beautiful piece of art that you've created just warms your heart is useless. So, I think I'm sort of at the extreme end of pragmatism, right? It's all about shipping and shipping fast. And, in the end, that's generally the goal of software. +On the more idealistic side, the sort of doing everything kind of perfect or by the book, or, you know, maybe in a way that brings you personal satisfaction, oftentimes, at the expense of shipping and vice versa. Sometimes shipping comes at the expense of writing absolutely terrible code, but, of course, you know, there's value in both. Shipping is what actually delivers value to your users, your company, yourself if you're using the software. +But if you're not following patterns and things, you're often stuck in a really short-term thinking loop, where you are maybe delivering value today at the cost of being able to deliver value tomorrow or writing code that is unreadable or code that is difficult to collaborate on. So, more than just me shipping an individual feature, I've got to think about, while I'm working with a team, how can I help them be able to ship features or build on top of my work for tomorrow? So, that's sort of how I visualize the field. I'm curious what the words idealism and pragmatism mean to you. +STEPHANIE: Yeah. I agree with you that pragmatism is, you know, this idea of delivering working software. And I think I have seen it very, you know, kind of condensed as, like, moving quickly, getting stuff out the door, basically, like, end result being, like, a thing that you can use, right? +I think I've personally been reassessing that idea a lot because I'm kind of almost wondering like, well, what are we moving quickly for [laughs]? I sometimes have seen pragmatism just end there being like, okay, like, it's all about velocity. And then, I'm kind of stuck being like, well, if you write working software for, you know, completely the wrong thing, is that still pragmatic? I don't know. So, that's kind of where I'm at these days with–I'm feeling a little bit more suspect of pragmatism, at least wanting to make sure that, especially with the people that I'm working with day to day, that we're agreeing on what that means and what success means. +And then, as for idealism, I think also, actually, I now have a little bit of duality in terms of how I understand that as well. One of them being, yes, definitely, like, by the book or, like, by the ideas that we've, you know, some very smart people [laughs] have figured out as, like, this is clean or good quality, or these are the patterns to, you know, make your code as, again, as clean, I don't know, kind of putting air quotes around that, as possible. +And then, I actually like what you really said about code that warms your heart [laughs] that you feel, like, really moved by or, like, just excited about or inspired by because I think that can also be a little bit different from just following theories that other people have defined. +The more I spend doing this stuff, the more I am convinced that writing software is actually a very creative practice. And that's something that I've, like, definitely had to balance with the pragmatism a bit more because there are days when it's just not coming [chuckles], you know, like, I just stare at a blank, new file. And I'm like, I can't even imagine what these classes would be because, like, that creative part of my brain just, like, isn't on that day. So, that's kind of where I'm sitting in terms of, like, what idealistic programming kind of seems to me. +JOËL: There's definitely an element of programming that feels like self-expression, you know, there are parameters around that. And working with a team, you probably all sort of, like, move towards some average. But I would definitely say that there is some element of self-expression in coding. +STEPHANIE: Yeah, 100%. Have you heard about this paper called Programming as Theory Building? +JOËL: The name sounds vaguely familiar, but I can't place the main idea in my mind right now. +STEPHANIE: It's, like, an academic-ish paper from the 80s. And I'll link to it in the show notes because I can't remember the author right now. But the idea is writing code is actually just one way of expressing a theory that we are building. In fact, that expression doesn't even....it's like, it's impossible for it to fully encapsulate everything that was involved in the building of the theory because every decision you make, you know, you decide what not to do as well, right? Like, all the things that you didn't encode in your application is still part of this theory, like stuff that you rejected in order to interpret and make abstract the things that you are translating from the quote, unquote "real world" into code. +That really stuck with me because, in that sense, I love this idea that you can create your own little world, right? Like, you're developing it when you code. And that is something that gets lost a little bit when we're just focused on the pragmatic side of things. +JOËL: Where things get tricky as well is that when you're working with a team, you're not just building your own little world. You're building a shared world with shared mental models, shared metaphors. That's where oftentimes it becomes important to make sure that the things that you are thinking about are expressed in a way that other people could read your code and then immediately pick up on what's happening. And that can be through things like documentation, code comments. It can also be through more rigorous data modeling. +So, for example, I am a huge fan of value objects in general. I tend to not have raw numbers floating around in an app. I like to wrap them in some kind of class and say, "Hey, these numbers that are floating around they actually represent a thing," and I'll name that thing so that other people can get a sense that, oh, it is one of the moving parts of this app, and then here are the behaviors that we expect on it. +And that is partly for sort of code correctness and things like that but also as a sort of way of communicating and a way of contributing to that shared reality that we're creating with the team in a way that if I just left a raw number, that would be almost, like, leaving something slightly undefined. Like, the number is there. It does a thing, but what it does is maybe a little bit more implied. I know in my mind that this is a dollar amount, and maybe there's even a comment above it that says, "Dollar amount." But it makes it a little bit harder for it to play in with everybody else's realities or view of the system than if it were its own object. +STEPHANIE: Yeah, I like what you said about you're building a shared world with your fellow colleagues. And that helped explain to me why, as some people say, naming is the hardest part about building software because, yeah, like you said, even just saying you are wanting to make a method or class expressive. And we talked about how code is a way of expressing yourself. You could, like, name all your stuff in Wingdings [laughs], but we don't. I actually don't know if you could do that. But that was, for some reason, what I imagined. I was like, it's possible, and you could deliver software in complete gibberish [laughs]. +JOËL: In theory, could you say that naming your variables as emoji is the most expressive way? Because now it's all emotions. +STEPHANIE: A picture is worth a thousand words, as they say. +JOËL: So, this variable is the frowny face, upside-down smile face. It doesn't get more expressive than that. +STEPHANIE: At a former company, in our Slack workspace, I had a co-worker who loved to use the circus tent emoji to react to things. And, like, I'm convinced that no one really knew what it meant, but we also kind of knew what it meant. We were just like, oh yeah, that's the emoji that she uses to express amusement or, like, something a little bit ironic. And we all kind of figured it out [laughs] eventually. So, again, I do think it's possible. I bet someone has done, like, a creative experiment with writing an application in just emojis. This is now going to be some research I do after this episode [laughter]. +JOËL: It is fun when you have, like, a teammate. You know they have the signature emoji that they respond to on things. +STEPHANIE: Yep. Absolutely. So, you know, we kind of spent a little bit of time talking about idealism. I actually wanted to pull back to the idea of pragmatism because, in preparation for this episode, I also revisited my copy of The Pragmatic Programmer. Are you familiar with this book? Have you read it at all? +JOËL: I have read it. It's been probably ten years. We did, I think, a book club at thoughtbot to go through the book. +STEPHANIE: I was skimming the table of contents because I was curious about, again, that, like, definition of pragmatism. You and I had kind of talked about how it can be short-sighted. But what I was actually pretty impressed with, and I imagine this is why the book holds up, you know, after decades, is success for them also means being able to continue to deliver quality software. And that idea of continuity kind of implied, to me, that there was an aspect of, like, making sure the quality meets a certain threshold and, like, incorporating these theories and doing the best practices because they're thinking about success over time, right? Not just the success of this particular piece that you're delivering. +JOËL: I would say most people in our industry are sort of balancing those two objectives, right? They're like, we want to have a decent velocity and ship things, but at the same time, we want to be able to keep delivering. We want a certain threshold of quality. +In between those two objectives, there is a sea of trade-offs, and how you manage them are probably a little bit part of your personality as a developer and is probably also, to a certain extent, a function of your experience, learning sort of when to lean more into taking some shortcuts to ship faster and when to double down on certain practices that increase code quality, and what aspects of quality value more than others because not all forms of quote, unquote, "quality" are the same. +I think a sort of source of danger, especially for newer developers, is you sort of start on almost, like, a hyper-pragmatic side of things because most people get into software because they want to build things. And the ultimate way to build is to ship, and then you sort of encounter problems where you realize, oh, this code is really clunky. It's harder and harder to ship. Let me learn some elements of code quality. Let's get better at my craft so that I can build software that has fewer bugs or that I can ship more consistently. And that's great. +And then, you sort of run into some, like, broader sort of theories of programming: patterns, structures, things like that. And it becomes very easy to sort of blindly copy-paste that everywhere to the point where I think it's almost a bit of a meme, the, like, intermediate programmer who's read Clean Code or the Design Patterns book and is just now, like, applying these things blindly to every piece of code they encounter to the annoyance of the entire team. +STEPHANIE: I think you just about described my trajectory [laughter], though hopefully, I was not so obnoxious about [laughs] it for my team having to deal with my, like, discovering [laughs] theories that have long been used. +JOËL: I think we kind of all go through that journey to a certain extent, right? It's a little bit different for every one of us, but I think this is a journey that is really common for developers. +STEPHANIE: Yeah. One thing I frequently think about a lot is how much I wished I had known some of that theory earlier. But I don't think I have an answer one way or another. It's like; I'm not sure if having that knowledge earlier really would have helped me because I've also definitely been in...I'm just thinking about, like, when I was in college in lectures trying to absorb theories that made no sense to me because I had no, like, practical experience to connect it to. It's almost, like, maybe there is, like, that perfect time [laughs] where it is the most valuable for what you're doing. And I don't know. I kind of believe that there is a way to bridge that gap. +JOËL: I mean, now we're kind of getting into an element of pedagogy. Do you sort of teach the theory first, and then show how to apply it to problems? Or do you show problems and then introduce bits of theory to help people get unstuck and maybe then cap it off by like, oh, these, like, five different, like, techniques I showed you to, like, solve five different problems, turns out they all fit in some grand unified theory? And, like, here's how the five things you thought were five different techniques are actually the same technique viewed from five different perspectives. Let me blow your mind. +STEPHANIE: That's a Joël approach [laughter] to teaching if I've ever heard one. +JOËL: I'm a huge fan of that approach. Going back to some of the, like, the functional programming ideas, I think that's one that really connected for me. I struggled to learn things like monads, and functors, and things like that. And I think, in my mind, these two approaches is like the Haskell school of teaching and the Elm school of teaching. +Haskell will sort of say, "Hey, let me teach you about this theory of monads and all these things, and then, we'll look at some ways where that can be applied practically." Whereas Elm will say, "No, you don't need to know about this. Let's look at some practical problems. Oh, you've got null values you need to check. Here's how you can, like, handle nullability in a safe way. Oh, you've got a bunch of HTTP requests that might resolve in random order, and you want to, like, deal with them when they all come back. Here's some tips on how you can do that." +And then, you have three or four things, and then, eventually, it just sort of lets you say, "Wait a minute, all of these problems are sort of all the same, and it turns out they all fit in some unified theory." And then, the light bulb goes off, and you're like, "Ooh, so now when I'm dealing with unknown blobs of Jason trying to parse data out of them, I'll bet I can use the same techniques I used for chaining HTTP requests to dig multiple dependent pieces of JSON." +STEPHANIE: Yeah. And that's so satisfying, right? It really is kind of leveling up in that Galaxy Brain meme sort of way. +JOËL: Yeah. And that's maybe to a certain extent even a value of idealism because if you build your system in such a way that it follows some of these patterns, then insights and intuitions that people have in one part of your code can then carry to other parts of your code, and that's incredibly powerful. +STEPHANIE: Yeah. And I almost wonder because you also mentioned kind of where you end up on the spectrum is a function of your experience. I wonder if us, you know, being consultants and seeing patterns across many applications also kind of contributes to the striving for idealism [laughs]. +JOËL: It's kind of both, right? Because there's very high incentive to ship pretty rapidly, especially if you're on a shorter engagement or if you're on a project that has a shorter timescale. But also, yes, because you've seen so many projects, you've seen how things can go wrong. Also, you've seen the same problem from 20 different perspectives that are all slightly different. And so, some of those broader patterns can start emerging in your head. +STEPHANIE: Yeah, honestly, I think that's kind of the work that I enjoy the most in consulting because a lot of clients bring us on when they're like, "Hey, like, we've reached a point where our velocity has slowed down. Like, can you help us unstick our developers?" And that's actually when I've found that leaning on the theories and maybe a little bit of idealism is actually really useful because I'm kind of providing those tools to developers at this time when they need it. That's kind of why I have been saying trending idealism because I have found that particularly useful at work. +JOËL: There's an element here of, like, looking at a bunch of different use cases and then finding some sort of unifying model or theory. And that's a word that I think programmers have a love-hate relationship with: Abstraction. I don't know about you, but designing abstractions is a lot of fun for me. I love designing abstractions. I have always loved designing abstractions. It's not always the best use of my time, and it's not always the best thing for a codebase. +STEPHANIE: Ooh, okay, okay. This was a good transition. I hear you that, like, yeah, love-hate relationship. It's hard. That's kind of where I've ended up. It's really hard. And I think it's because it requires that creative thinking. +JOËL: It requires that creative thinking. And then also, like, it requires you to sort of see more broadly, a more broad picture. What are the things that are connected, the things that are disconnected, even though they seem related? And, like, being able to sort of slice those similarities from each other. +STEPHANIE: Yeah. I agree. And the interesting part is that, like, a lot of the time you just don't know yet. And you kind of have to come back to reality and admit that you don't know yet, you know, got to come back to earth, take a look around, and, yeah, you can go through the thought exercise of thinking [laughs] about all of the possibilities, and I imagine you could do that forever [laughs]. +JOËL: I mean, that's why we have heuristics like the rule of three that says, "Don't abstract something out or attempt to DRY code until you've seen three use cases of it." So, maybe leave a little bit of duplication or a little bit of maybe not perfectly factored code until you have a couple of more examples. And the sort of real picture starts emerging a little bit more. +STEPHANIE: So, I think we are kind of at this topic already, but was there a moment or was there something that kind of helped you realize, like, oh, I can't be in that space of imagining abstractions [laughs] forever when I have to deliver software? Like, what changed for you to be the, as you said yourself, recovering idealist and having to maybe employ some more pragmatic heuristics? +JOËL: And I think, for me, it's partly being a consultant and being in a lot of projects and having that pressure to work with deadlines and sort of not having an infinite canvas to paint with, having to sort of fit some of my grand ideas into the reality of, we've got a week or two weeks to get this thing done, and also working with a team, and some ideas don't work well with every team. Every team is kind of at a different place. +And abstractions sort of only serve you as well as they are useful to not only you but the team at large. So, if a team is not comfortable with a set of abstractions, or it's sort of, like, too far down a path, then that can be really challenging. And that's where something like the dry-rb set of gems, which has some really fun abstractions like a mental model for doing things, depending on the team, that can be a really heavy lift. And so, as much as I like those patterns, I might think long and hard before I try to push this on a whole team. +STEPHANIE: Yeah, I kind of had to navigate a situation like that recently, where I was doing a code review, and I had left some suggestions about refactoring to encapsulate some responsibilities better. And then, I was like, oh, and then I noticed another thing that we could do to make that easier. And it, you know, definitely can start to spiral. And the author, you know, kind of responded to me and said, "Hey, like, I really appreciate these comments, but we are a bit tight on deadline for this project. So, is it okay if I, like, revisit this when we've delivered it?" +And, you know, I was just like, "Yeah, it's totally up to you." At the end of the day, I want whoever's authoring this code to have, like, full agency about how they want to move forward. And it was really helpful for me to get that context of, like, oh, they're a bit tight on the deadline because then I can start to meet them where they're at. And maybe I can give some suggestions for moving towards that ideal state, but ones that are lower left, and that is still better than nothing. +JOËL: That sounds awfully pragmatic. +STEPHANIE: [laughs] +JOËL: Moving in a positive direction, we're getting halfway. It's better than nothing. That's very pragmatic. +STEPHANIE: Hmm. Wow. But it's pragmatically moving towards idealism. +JOËL: [laughs] +STEPHANIE: If that is even possible [laughs]. +JOËL: Uh-huh. +STEPHANIE: That's maybe the book that I'm going to write, not The Pragmatic Programmer, but The Pragmatically Idealistic Programmer [laughs]. +JOËL: The Pragmatic Idealist. +STEPHANIE: Ooh, yeah, I like that. Okay. Watch out for that book coming 2030 [laughter], written by me and Joël. +JOËL: So, I think you brought up a really interesting point, which is the idea of pragmatism versus idealism when it comes to code review. Do you find that you think about these ideas differently when reviewing somebody else's code versus when you write your own? +STEPHANIE: Oooh, yeah. I'm not sure exactly why, but definitely, when I'm reviewing someone else's code, I'm already in the headspace of, you know, I have some separation, right? Like, I'm not in the mode of thinking very hard [laughs] about what I'm creating. I'm just, like, in the editing kind of phase. And then, I can actually pull more from different theories and ideas, and I find that actually quite easier. When I'm writing my own code, it's just whatever comes out, right? And then, hopefully, I have the time to revisit it and give it a scan, and then start to integrate the, like, idealistic theories and the patterns that I would like to be using. +But it definitely...for patterns that I feel a lot more confident about or more familiar with, they just come out mostly kind of oriented in that way if I have the time, or sometimes I will make the time, you know. I'll just say, "It's not done yet," because I know it can be better. I think that could be another, like, pragmatically idealist way of handling that. +JOËL: [laughs] +STEPHANIE: Right? It's just telling people, "I'm not done." [laughs] It's not done until I do at least give it an attempt. +JOËL: So, it's kind of a two-phase thing when you're writing your own code, whereas it's only a single phase when you're reviewing somebody else's. +STEPHANIE: Yeah. Yeah. But, like I said earlier, it's like, I also really believe that I don't want to impose any of my ideas [laughs] onto others. I really believe that people have to arrive at it on their own. So, it used to bother me a little bit more when I was just like, oh, but this way is better [laughs]. When people wouldn't get on board, I would be sad about it. But as long as I know that I, like, left that comment, then I can give myself a pat on the back for trying to move towards that ideal state. What about you [laughs]? +JOËL: I think this is probably also where I'm, like, now a recovering idealist. There was a time where I would leave a ton of comments on someone's PR. I almost had a view of like, how can I help you get your PR to be the best it can possibly be? And sometimes, if you start with something that's very rough around the edges, you're leaving a lot of comments. And I've been that guy who's left 50 comments on a PR. In retrospect, I think that was not being a good teammate. +STEPHANIE: Hmm. +JOËL: So, I think maybe my mental model or my, like, goal for PR review has changed a little bit. It's less about how can I help you make your code the best it can possibly be? And a how can I help you get your code to mergeable? And it's possible that mergeable means best that it can possibly be, but that's usually not the case. So, I'm going to give you some feedback: some things that confuse me, maybe raise one or two patterns that are existing in the app that maybe you weren't aware of that you should maybe consider applying. Maybe I'll raise a couple of ideas that are new, but that apply here. +And those might just be a, "Hey, let's just think about this. Maybe we don't want to do this in this PR, but maybe we want to look at them at some point. Or we should be thinking about this in a sort of rule of three situation. If we see this come up another time, maybe consider introducing a strategy pattern here, or maybe consider making this a value object, or separating these side effects from these pure behavior." But it's more of a dialogue about how can I help you get your PR to the point where it is mergeable? +STEPHANIE: Yeah. Another thing I thought about just now is both are meaningful or, like, both can provide meaning in different ways, and people ascribe different amounts of meaning to both; where I had worked with someone, a client developer before, who was not super interested in doing any kind of refactoring or, like, any, you know, second passes for quality. Because, for him, like, he just wanted to ship, right? That was where he found meaning in his work. +Whereas that actually made my work feel a lot more meaningless [chuckles] because I'm like, well, if we're just kind of hands on a keyboard, like robots shipping code, I don't know, that doesn't feel particularly motivating for me. You know, I do want to employ some of that craft a little bit more. +JOËL: And, I guess, yeah, idealism versus pragmatism is also...it's a personal individual thing. There's an element where it's a team decision, or at least a sense of, like, how much quality do we need at this point in the life cycle of the project? And what are the areas where we particularly want to emphasize quality? What are our quality standards? And that's, to a certain extent, consensus among the team that it's individual members. And it's also coming from team leadership. +STEPHANIE: Yeah. Yeah, exactly. I mentioned that, you know, just to, I think, shed a little bit of light that it's usually not personal, right [laughs]? There's that part of understanding that is really important to, yeah, like, keep building this shared world of writing software, and, hopefully, it should be meaningful for all of us. +JOËL: I think a few takeaways that I have would be, one, the value of, like, theory and idealism. These things help you to become a better developer. They help you to spot patterns. It's probably good to sort of have in the background always be learning some new thing, whether that's learning a new set of patterns, or learning some mental models, thinking about, oh, the difference between side effects and pure code, learning about particular ways of structuring code. These are all things that are good to have in your back pocket to be able to apply to the code that you're doing, even if it's a sort of after-the-fact, hey, I've done a similar task three different times. Is there a broader principle? +But then, also, take the time to really make sure that you're focusing on shipping code, and maybe that's learning to work in smaller chunks, working iteratively, learning to scope your work well. Because, in the end, delivering value is a thing that is something that we could all probably benefit from doing more of. +And then, finally, taking some time to self-reflect, a little bit of self-awareness in this area. What are the aspects of pragmatism and idealism that you find personally meaningful? What are the elements that you think bring value to your work, to your team? And let that sort of guide you on your next code writing or PR review. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + technical spiking, legacy Rails applications, dry-rb gems, functional programming in Ruby, exploring technical implementations, uncovering unknowns in feature requests, codebase exploration strategies, constraints identification, solution development for technical constraints, collaborative stakeholder communication, pragmatic programming approaches, idealistic programming philosophies, adapting functional programming to Ruby, software development best practices, team-based coding strategies, creating meaningful code, programming as self-expression, navigating team dynamics in software projects, operational efficiency in coding, Ruby on Rails code optimization, understanding dry-rb in practice, + + Stephanie revisits the concept of "spiking"—a phase of exploration to determine the feasibility of a technical implementation or to address unknowns in feature requests—sharing her recent experiences with a legacy Rails application. Joël brings a different perspective by discussing his involvement with a client project that heavily utilizes the dry-rb suite of gems, highlighting the learning curve associated with adapting to new patterns and libraries.

+ +

Joël used to be much more idealistic and has moved to be more pragmatic. Stephanie has moved the other way. So together, Stephanie and Joël engage in a philosophical discussion on being an idealistic versus a pragmatic programmer. They explore the concept of programming as a blend of science and art, where technical decisions are not only about solving problems but also about expressing ideas and building shared understandings within a team.

+ + + +

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, a few weeks ago, we did an episode on spiking in response to a listener question. And I wanted to kind of revisit that topic for a little bit because I've been doing a lot of spiking on my client project. And for those who are not familiar, the way that I understand or define spikes is kind of as an exploration phase to figure out if a technical implementation might work. Or if you have a feature request with some unknowns, you can spend some time-boxed spiking to figure out what those unknowns might be.

+ +

And I'm working on your typical legacy Rails application [laughs]. And I think one thing that we talked about last time was this idea of, at what point does spiking end up being just working on the feature [laughs]? And I think that's especially true in an older codebase, where you kind of have to go down a few rabbit holes, maybe, just to even find out if something will trip you up down the line.

+ +

And the way I approached that this time around was just, like, identifying the constraints and putting a little flag there for myself. Like, these were rabbit holes that I could go down, but, you know, towards the initial beginning phase of doing the spiking, I decided not to. I just kind of bookmarked it for later.

+ +

And once I had identified the main constraints, that was when I was like, okay, like, what kind of solutions can I come up with for these constraints? And that actually then helped me kind of decide which ones we're pursuing a little bit more to get, like, the information I needed to ultimately make a decision about whether this was worth doing, right?

+ +

It kind of kept me...I'm thinking about, you know, when you are bowling with those safety guards [laughs], it keeps your ball from just rolling into the gutter. I think it helped with not going too deep into places that I may or may not be super fruitful while also, I think, giving me enough information to have a more realistic understanding of, like, what this work would entail.

+ +

JOËL: Would you say that this approach that you're taking is inspired or maybe informed by the conversation we had on the episode?

+ +

STEPHANIE: I was especially interested in avoiding the kind of binary of like, no, we can't do this because the system just, you know, isn't able to support it, or it's just too...it would be too much work. That was something I was really, like you said, kind of inspired by after that conversation because I wanted to avoid that trap a little bit.

+ +

And I think another really helpful framing was the idea of, like, okay, what would need to be done in order to get us to a place where this could be possible? And that's why I think identifying those constraints was important because they're not constraints forever. Like, we could do something about them if we really wanted to, so kind of avoiding the, like, it's not possible, right? And saying like, "It could be. Here's all the things that we need to do in order to make it possible." But I think that helped shift the conversation, especially with stakeholders and stuff, to be a little bit more realistic and collaborative.

+ +

So, Joël, what's new in your world?

+ +

JOËL: So, I'm also on a new client project, and a thing that's been really interesting in this codebase is that they've been using the dry-rb suite of gems pretty heavily. And I've seen a lot about the suite of gems. I've read about them. Interestingly, this is kind of the first time that I've been on a codebase that sort of uses them as a main pattern in the app. So, there's been a bit of a learning curve there, and it's been really interesting.

+ +

STEPHANIE: This is exciting to me because I know you have a lot of functional programming background, also, so it's kind of surprising that you're only now, you know, using something that explicit from functional languages in Ruby. And I'm curious: what's the learning curve, if not the paradigm? Like, what are you kind of encountering?

+ +

JOËL: I think there's a little bit of just the translation. How do these gems sort of approach this? So, they have to do a couple of, like, clever Ruby things to make some of these features work. Some of these also will have different method names, so a lot of just familiarizing myself with the libraries. Like, oh, well, this thing that I'm used to having called a particular thing has a slightly different name here or maybe not having all of the utilities. I was like, oh, how do we traverse with this particular library? Then you have to, like, look it up.

+ +

So, it's a lot of like, how do I do this thing I know how to do in, let's say, Elm? How do I translate that into Ruby? But then, also, some of the interplay of how that works in code that also does some very kind of imperative side effecty things also written by a team that is getting used to the pattern. And so, you'll sort of see things where people are pulling things in, but maybe you don't fully understand the deeper underlying approach that's meant to be used.

+ +

STEPHANIE: Have you noticed any use cases where the dry-rb patterns really shine in your application?

+ +

JOËL: A thing that's nice is that I think it really forces you to think about your edge cases in a way that sometimes Ruby developers play very fast and loose with "Yeah, whatever, it will never be nil." Push to production immediately start getting NoMethodError in your bug tracker. I never do this, by the way, but you know.

+ +

STEPHANIE: [laughs].

+ +

JOËL: Speaking from a friend's experience [laughs].

+ +

STEPHANIE: Asking for a friend, yeah [laughs].

+ +

JOËL: I think a thing that I've sort of had to figure out sort of every time I deal with these patterns in different languages is just the importance of good composition and good separation. Because you're adding these sort of wrapper context around things, if you're constantly wrapping and unwrapping, you're like, check things inside, and then do the next thing, and then unwrap again and branch and check and do the next thing, that code becomes really clunky in a way that you just sort of expect to do if you're just writing code in regular Ruby with a nil. But it doesn't really work with a dry-rb maybe or a result.

+ +

So, the pattern that I have found that works really well is to extract sort of every operation that can be, let's say, that could fail so that it would give you a result back. Extract that out into its own separate function that will construct a success or a failure, and then have your sort of main code that wants to then do a bunch of these things together.

+ +

All it does is use some of the dry-rb helper methods to compose all of these together, whether that's just some sort of, like, do notation, or binding, or fmap, or something like that, which allows you to have sort of individual chunks that can fail, and then one sort of aggregator piece of code that just finds a way to combine all of them nicely. And that avoids you having to do all this repetition.

+ +

STEPHANIE: Yeah, that makes a lot of sense.

+ +

JOËL: It's a pattern, I think; I had to learn the hard way when I was working with Elm. Because if you're taking a potential nullable value and then you want to do things with it but then that potential operation is also nullable because the input was potentially null, and then that just sort of propagates all the way down the chain. So, my whole chain of functions now is doing checks for nullability. And in Ruby, I could just be like, no, I checked it in the first function. I can then just trust that it's not null down the chain.

+ +

Elm doesn't do the like, trust me, bro. The compiler will force you to validate every time, and then the code just blows up, and it gets really painful. So, I had to start thinking about new models of thinking that would separate out code that actually needs to care and code that doesn't need to care about nullability. And I wrote an article about that. That turned into actually a conference talk as well. And these sort of ideas have served me really well at Elm. And I think these translate pretty well to dry-rb as well. That's something that I'm exploring, but the principles seem like they're not tied to a particular language.

+ +

STEPHANIE: Yeah, and it's kind of cool that you experienced all of that in working with Elm, where a compiler was there to yell at you [laughs] and kind of forcing you to...I don't know if do the right thing is the right word, but kind of think in the way that it wants you to think. And I can see people who are coming from Ruby and starting to experiment with dry-rb maybe needing a bit of that since it's not built-in in the tooling, just in a recoder view or just in conversations among devs.

+ +

JOËL: [inaudible 09:26] Beyond just the idea of wrapping your values and making sure you check them all the time, there are patterns that make that easier or more painful. And even in something like Elm, the compiler would yell at me would make sure I could not have a runtime error by forgetting to check for nullability. It did not prevent me from writing monstrosities of nested repeated conditionals checking if nil, if nil, if nil. That I had to figure out some sort of, like, higher-level patterns that play nicely with that kind of software.

+ +

And I think these are things that people have to sort of encounter, feel the pain, feel the frustration, and then move into those better patterns after the fact. And sometimes that's not easy because it's not obvious why that's a valuable pattern to approach.

+ +

STEPHANIE: Yeah, I agree completely. Speaking of following patterns and kind of arriving at maybe an ideal version of [chuckles], you know, what you'd like your code to do, you know, to build what you are looking to build [laughs]...this is my very poor attempt at a smooth transition that Joël [laughter] manages to be able to do [laughs] whenever we're trying to shift into the topic of the episode. Anyway, today, we were hoping to talk a little bit about this idea between being an idealistic programmer and a pragmatic programmer and the different journeys that we've each been on in arriving kind of how to balance the two.

+ +

JOËL: Yeah, you know, I think neither of these are absolutes, right? It's a spectrum. You probably move around that spectrum from day to day, and then probably, like, more general trends over your career. But I'm curious, for you today, if you had to pick one of those labels, like, which sort of zone of the spectrum would you put yourself in? Do you think you're more idealistic or more pragmatic?

+ +

STEPHANIE: I think I'm in a more of an idealistic zone right now.

+ +

JOËL: Would you say you're kind of like middle trending idealistic or kind of, like, pretty far down the idealistic side?

+ +

STEPHANIE: Middle trending idealistic. I like that way of describing it. I want to know where you are. And then I kind of wanted to try to take a step back and even define what that means for both of us.

+ +

JOËL: Right, right. I think the way I'd probably describe myself is a recovering idealist.

+ +

STEPHANIE: Oof. Yeah [laughs].

+ +

JOËL: I think there was a time where I was really idealistic. I really like knowing sort of underlying theory of software construction, broader patterns. By patterns here, I don't mean necessarily, like, you know, the Gang of Four, but just general sort of approaches that work well and using that to guide my work. But I've also been trending a lot more into the, like, pragmatic side of things in the past few years.

+ +

STEPHANIE: So, could you kind of tell me a little bit about what does pragmatic mean for you and what does ideal mean for you?

+ +

JOËL: So, I think the pragmatic side of me it's about delivering working software. If you're not shipping anything, you know, the most beautiful piece of art that you've created just warms your heart is useless. So, I think I'm sort of at the extreme end of pragmatism, right? It's all about shipping and shipping fast. And, in the end, that's generally the goal of software.

+ +

On the more idealistic side, the sort of doing everything kind of perfect or by the book, or, you know, maybe in a way that brings you personal satisfaction, oftentimes, at the expense of shipping and vice versa. Sometimes shipping comes at the expense of writing absolutely terrible code, but, of course, you know, there's value in both. Shipping is what actually delivers value to your users, your company, yourself if you're using the software.

+ +

But if you're not following patterns and things, you're often stuck in a really short-term thinking loop, where you are maybe delivering value today at the cost of being able to deliver value tomorrow or writing code that is unreadable or code that is difficult to collaborate on. So, more than just me shipping an individual feature, I've got to think about, while I'm working with a team, how can I help them be able to ship features or build on top of my work for tomorrow? So, that's sort of how I visualize the field. I'm curious what the words idealism and pragmatism mean to you.

+ +

STEPHANIE: Yeah. I agree with you that pragmatism is, you know, this idea of delivering working software. And I think I have seen it very, you know, kind of condensed as, like, moving quickly, getting stuff out the door, basically, like, end result being, like, a thing that you can use, right?

+ +

I think I've personally been reassessing that idea a lot because I'm kind of almost wondering like, well, what are we moving quickly for [laughs]? I sometimes have seen pragmatism just end there being like, okay, like, it's all about velocity. And then, I'm kind of stuck being like, well, if you write working software for, you know, completely the wrong thing, is that still pragmatic? I don't know. So, that's kind of where I'm at these days with–I'm feeling a little bit more suspect of pragmatism, at least wanting to make sure that, especially with the people that I'm working with day to day, that we're agreeing on what that means and what success means.

+ +

And then, as for idealism, I think also, actually, I now have a little bit of duality in terms of how I understand that as well. One of them being, yes, definitely, like, by the book or, like, by the ideas that we've, you know, some very smart people [laughs] have figured out as, like, this is clean or good quality, or these are the patterns to, you know, make your code as, again, as clean, I don't know, kind of putting air quotes around that, as possible.

+ +

And then, I actually like what you really said about code that warms your heart [laughs] that you feel, like, really moved by or, like, just excited about or inspired by because I think that can also be a little bit different from just following theories that other people have defined.

+ +

The more I spend doing this stuff, the more I am convinced that writing software is actually a very creative practice. And that's something that I've, like, definitely had to balance with the pragmatism a bit more because there are days when it's just not coming [chuckles], you know, like, I just stare at a blank, new file. And I'm like, I can't even imagine what these classes would be because, like, that creative part of my brain just, like, isn't on that day. So, that's kind of where I'm sitting in terms of, like, what idealistic programming kind of seems to me.

+ +

JOËL: There's definitely an element of programming that feels like self-expression, you know, there are parameters around that. And working with a team, you probably all sort of, like, move towards some average. But I would definitely say that there is some element of self-expression in coding.

+ +

STEPHANIE: Yeah, 100%. Have you heard about this paper called Programming as Theory Building?

+ +

JOËL: The name sounds vaguely familiar, but I can't place the main idea in my mind right now.

+ +

STEPHANIE: It's, like, an academic-ish paper from the 80s. And I'll link to it in the show notes because I can't remember the author right now. But the idea is writing code is actually just one way of expressing a theory that we are building. In fact, that expression doesn't even....it's like, it's impossible for it to fully encapsulate everything that was involved in the building of the theory because every decision you make, you know, you decide what not to do as well, right? Like, all the things that you didn't encode in your application is still part of this theory, like stuff that you rejected in order to interpret and make abstract the things that you are translating from the quote, unquote "real world" into code.

+ +

That really stuck with me because, in that sense, I love this idea that you can create your own little world, right? Like, you're developing it when you code. And that is something that gets lost a little bit when we're just focused on the pragmatic side of things.

+ +

JOËL: Where things get tricky as well is that when you're working with a team, you're not just building your own little world. You're building a shared world with shared mental models, shared metaphors. That's where oftentimes it becomes important to make sure that the things that you are thinking about are expressed in a way that other people could read your code and then immediately pick up on what's happening. And that can be through things like documentation, code comments. It can also be through more rigorous data modeling.

+ +

So, for example, I am a huge fan of value objects in general. I tend to not have raw numbers floating around in an app. I like to wrap them in some kind of class and say, "Hey, these numbers that are floating around they actually represent a thing," and I'll name that thing so that other people can get a sense that, oh, it is one of the moving parts of this app, and then here are the behaviors that we expect on it.

+ +

And that is partly for sort of code correctness and things like that but also as a sort of way of communicating and a way of contributing to that shared reality that we're creating with the team in a way that if I just left a raw number, that would be almost, like, leaving something slightly undefined. Like, the number is there. It does a thing, but what it does is maybe a little bit more implied. I know in my mind that this is a dollar amount, and maybe there's even a comment above it that says, "Dollar amount." But it makes it a little bit harder for it to play in with everybody else's realities or view of the system than if it were its own object.

+ +

STEPHANIE: Yeah, I like what you said about you're building a shared world with your fellow colleagues. And that helped explain to me why, as some people say, naming is the hardest part about building software because, yeah, like you said, even just saying you are wanting to make a method or class expressive. And we talked about how code is a way of expressing yourself. You could, like, name all your stuff in Wingdings [laughs], but we don't. I actually don't know if you could do that. But that was, for some reason, what I imagined. I was like, it's possible, and you could deliver software in complete gibberish [laughs].

+ +

JOËL: In theory, could you say that naming your variables as emoji is the most expressive way? Because now it's all emotions.

+ +

STEPHANIE: A picture is worth a thousand words, as they say.

+ +

JOËL: So, this variable is the frowny face, upside-down smile face. It doesn't get more expressive than that.

+ +

STEPHANIE: At a former company, in our Slack workspace, I had a co-worker who loved to use the circus tent emoji to react to things. And, like, I'm convinced that no one really knew what it meant, but we also kind of knew what it meant. We were just like, oh yeah, that's the emoji that she uses to express amusement or, like, something a little bit ironic. And we all kind of figured it out [laughs] eventually. So, again, I do think it's possible. I bet someone has done, like, a creative experiment with writing an application in just emojis. This is now going to be some research I do after this episode [laughter].

+ +

JOËL: It is fun when you have, like, a teammate. You know they have the signature emoji that they respond to on things.

+ +

STEPHANIE: Yep. Absolutely. So, you know, we kind of spent a little bit of time talking about idealism. I actually wanted to pull back to the idea of pragmatism because, in preparation for this episode, I also revisited my copy of The Pragmatic Programmer. Are you familiar with this book? Have you read it at all?

+ +

JOËL: I have read it. It's been probably ten years. We did, I think, a book club at thoughtbot to go through the book.

+ +

STEPHANIE: I was skimming the table of contents because I was curious about, again, that, like, definition of pragmatism. You and I had kind of talked about how it can be short-sighted. But what I was actually pretty impressed with, and I imagine this is why the book holds up, you know, after decades, is success for them also means being able to continue to deliver quality software. And that idea of continuity kind of implied, to me, that there was an aspect of, like, making sure the quality meets a certain threshold and, like, incorporating these theories and doing the best practices because they're thinking about success over time, right? Not just the success of this particular piece that you're delivering.

+ +

JOËL: I would say most people in our industry are sort of balancing those two objectives, right? They're like, we want to have a decent velocity and ship things, but at the same time, we want to be able to keep delivering. We want a certain threshold of quality.

+ +

In between those two objectives, there is a sea of trade-offs, and how you manage them are probably a little bit part of your personality as a developer and is probably also, to a certain extent, a function of your experience, learning sort of when to lean more into taking some shortcuts to ship faster and when to double down on certain practices that increase code quality, and what aspects of quality value more than others because not all forms of quote, unquote, "quality" are the same.

+ +

I think a sort of source of danger, especially for newer developers, is you sort of start on almost, like, a hyper-pragmatic side of things because most people get into software because they want to build things. And the ultimate way to build is to ship, and then you sort of encounter problems where you realize, oh, this code is really clunky. It's harder and harder to ship. Let me learn some elements of code quality. Let's get better at my craft so that I can build software that has fewer bugs or that I can ship more consistently. And that's great.

+ +

And then, you sort of run into some, like, broader sort of theories of programming: patterns, structures, things like that. And it becomes very easy to sort of blindly copy-paste that everywhere to the point where I think it's almost a bit of a meme, the, like, intermediate programmer who's read Clean Code or the Design Patterns book and is just now, like, applying these things blindly to every piece of code they encounter to the annoyance of the entire team.

+ +

STEPHANIE: I think you just about described my trajectory [laughter], though hopefully, I was not so obnoxious about [laughs] it for my team having to deal with my, like, discovering [laughs] theories that have long been used.

+ +

JOËL: I think we kind of all go through that journey to a certain extent, right? It's a little bit different for every one of us, but I think this is a journey that is really common for developers.

+ +

STEPHANIE: Yeah. One thing I frequently think about a lot is how much I wished I had known some of that theory earlier. But I don't think I have an answer one way or another. It's like; I'm not sure if having that knowledge earlier really would have helped me because I've also definitely been in...I'm just thinking about, like, when I was in college in lectures trying to absorb theories that made no sense to me because I had no, like, practical experience to connect it to. It's almost, like, maybe there is, like, that perfect time [laughs] where it is the most valuable for what you're doing. And I don't know. I kind of believe that there is a way to bridge that gap.

+ +

JOËL: I mean, now we're kind of getting into an element of pedagogy. Do you sort of teach the theory first, and then show how to apply it to problems? Or do you show problems and then introduce bits of theory to help people get unstuck and maybe then cap it off by like, oh, these, like, five different, like, techniques I showed you to, like, solve five different problems, turns out they all fit in some grand unified theory? And, like, here's how the five things you thought were five different techniques are actually the same technique viewed from five different perspectives. Let me blow your mind.

+ +

STEPHANIE: That's a Joël approach [laughter] to teaching if I've ever heard one.

+ +

JOËL: I'm a huge fan of that approach. Going back to some of the, like, the functional programming ideas, I think that's one that really connected for me. I struggled to learn things like monads, and functors, and things like that. And I think, in my mind, these two approaches is like the Haskell school of teaching and the Elm school of teaching.

+ +

Haskell will sort of say, "Hey, let me teach you about this theory of monads and all these things, and then, we'll look at some ways where that can be applied practically." Whereas Elm will say, "No, you don't need to know about this. Let's look at some practical problems. Oh, you've got null values you need to check. Here's how you can, like, handle nullability in a safe way. Oh, you've got a bunch of HTTP requests that might resolve in random order, and you want to, like, deal with them when they all come back. Here's some tips on how you can do that."

+ +

And then, you have three or four things, and then, eventually, it just sort of lets you say, "Wait a minute, all of these problems are sort of all the same, and it turns out they all fit in some unified theory." And then, the light bulb goes off, and you're like, "Ooh, so now when I'm dealing with unknown blobs of Jason trying to parse data out of them, I'll bet I can use the same techniques I used for chaining HTTP requests to dig multiple dependent pieces of JSON."

+ +

STEPHANIE: Yeah. And that's so satisfying, right? It really is kind of leveling up in that Galaxy Brain meme sort of way.

+ +

JOËL: Yeah. And that's maybe to a certain extent even a value of idealism because if you build your system in such a way that it follows some of these patterns, then insights and intuitions that people have in one part of your code can then carry to other parts of your code, and that's incredibly powerful.

+ +

STEPHANIE: Yeah. And I almost wonder because you also mentioned kind of where you end up on the spectrum is a function of your experience. I wonder if us, you know, being consultants and seeing patterns across many applications also kind of contributes to the striving for idealism [laughs].

+ +

JOËL: It's kind of both, right? Because there's very high incentive to ship pretty rapidly, especially if you're on a shorter engagement or if you're on a project that has a shorter timescale. But also, yes, because you've seen so many projects, you've seen how things can go wrong. Also, you've seen the same problem from 20 different perspectives that are all slightly different. And so, some of those broader patterns can start emerging in your head.

+ +

STEPHANIE: Yeah, honestly, I think that's kind of the work that I enjoy the most in consulting because a lot of clients bring us on when they're like, "Hey, like, we've reached a point where our velocity has slowed down. Like, can you help us unstick our developers?" And that's actually when I've found that leaning on the theories and maybe a little bit of idealism is actually really useful because I'm kind of providing those tools to developers at this time when they need it. That's kind of why I have been saying trending idealism because I have found that particularly useful at work.

+ +

JOËL: There's an element here of, like, looking at a bunch of different use cases and then finding some sort of unifying model or theory. And that's a word that I think programmers have a love-hate relationship with: Abstraction. I don't know about you, but designing abstractions is a lot of fun for me. I love designing abstractions. I have always loved designing abstractions. It's not always the best use of my time, and it's not always the best thing for a codebase.

+ +

STEPHANIE: Ooh, okay, okay. This was a good transition. I hear you that, like, yeah, love-hate relationship. It's hard. That's kind of where I've ended up. It's really hard. And I think it's because it requires that creative thinking.

+ +

JOËL: It requires that creative thinking. And then also, like, it requires you to sort of see more broadly, a more broad picture. What are the things that are connected, the things that are disconnected, even though they seem related? And, like, being able to sort of slice those similarities from each other.

+ +

STEPHANIE: Yeah. I agree. And the interesting part is that, like, a lot of the time you just don't know yet. And you kind of have to come back to reality and admit that you don't know yet, you know, got to come back to earth, take a look around, and, yeah, you can go through the thought exercise of thinking [laughs] about all of the possibilities, and I imagine you could do that forever [laughs].

+ +

JOËL: I mean, that's why we have heuristics like the rule of three that says, "Don't abstract something out or attempt to DRY code until you've seen three use cases of it." So, maybe leave a little bit of duplication or a little bit of maybe not perfectly factored code until you have a couple of more examples. And the sort of real picture starts emerging a little bit more.

+ +

STEPHANIE: So, I think we are kind of at this topic already, but was there a moment or was there something that kind of helped you realize, like, oh, I can't be in that space of imagining abstractions [laughs] forever when I have to deliver software? Like, what changed for you to be the, as you said yourself, recovering idealist and having to maybe employ some more pragmatic heuristics?

+ +

JOËL: And I think, for me, it's partly being a consultant and being in a lot of projects and having that pressure to work with deadlines and sort of not having an infinite canvas to paint with, having to sort of fit some of my grand ideas into the reality of, we've got a week or two weeks to get this thing done, and also working with a team, and some ideas don't work well with every team. Every team is kind of at a different place.

+ +

And abstractions sort of only serve you as well as they are useful to not only you but the team at large. So, if a team is not comfortable with a set of abstractions, or it's sort of, like, too far down a path, then that can be really challenging. And that's where something like the dry-rb set of gems, which has some really fun abstractions like a mental model for doing things, depending on the team, that can be a really heavy lift. And so, as much as I like those patterns, I might think long and hard before I try to push this on a whole team.

+ +

STEPHANIE: Yeah, I kind of had to navigate a situation like that recently, where I was doing a code review, and I had left some suggestions about refactoring to encapsulate some responsibilities better. And then, I was like, oh, and then I noticed another thing that we could do to make that easier. And it, you know, definitely can start to spiral. And the author, you know, kind of responded to me and said, "Hey, like, I really appreciate these comments, but we are a bit tight on deadline for this project. So, is it okay if I, like, revisit this when we've delivered it?"

+ +

And, you know, I was just like, "Yeah, it's totally up to you." At the end of the day, I want whoever's authoring this code to have, like, full agency about how they want to move forward. And it was really helpful for me to get that context of, like, oh, they're a bit tight on the deadline because then I can start to meet them where they're at. And maybe I can give some suggestions for moving towards that ideal state, but ones that are lower left, and that is still better than nothing.

+ +

JOËL: That sounds awfully pragmatic.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Moving in a positive direction, we're getting halfway. It's better than nothing. That's very pragmatic.

+ +

STEPHANIE: Hmm. Wow. But it's pragmatically moving towards idealism.

+ +

JOËL: [laughs]

+ +

STEPHANIE: If that is even possible [laughs].

+ +

JOËL: Uh-huh.

+ +

STEPHANIE: That's maybe the book that I'm going to write, not The Pragmatic Programmer, but The Pragmatically Idealistic Programmer [laughs].

+ +

JOËL: The Pragmatic Idealist.

+ +

STEPHANIE: Ooh, yeah, I like that. Okay. Watch out for that book coming 2030 [laughter], written by me and Joël.

+ +

JOËL: So, I think you brought up a really interesting point, which is the idea of pragmatism versus idealism when it comes to code review. Do you find that you think about these ideas differently when reviewing somebody else's code versus when you write your own?

+ +

STEPHANIE: Oooh, yeah. I'm not sure exactly why, but definitely, when I'm reviewing someone else's code, I'm already in the headspace of, you know, I have some separation, right? Like, I'm not in the mode of thinking very hard [laughs] about what I'm creating. I'm just, like, in the editing kind of phase. And then, I can actually pull more from different theories and ideas, and I find that actually quite easier. When I'm writing my own code, it's just whatever comes out, right? And then, hopefully, I have the time to revisit it and give it a scan, and then start to integrate the, like, idealistic theories and the patterns that I would like to be using.

+ +

But it definitely...for patterns that I feel a lot more confident about or more familiar with, they just come out mostly kind of oriented in that way if I have the time, or sometimes I will make the time, you know. I'll just say, "It's not done yet," because I know it can be better. I think that could be another, like, pragmatically idealist way of handling that.

+ +

JOËL: [laughs]

+ +

STEPHANIE: Right? It's just telling people, "I'm not done." [laughs] It's not done until I do at least give it an attempt.

+ +

JOËL: So, it's kind of a two-phase thing when you're writing your own code, whereas it's only a single phase when you're reviewing somebody else's.

+ +

STEPHANIE: Yeah. Yeah. But, like I said earlier, it's like, I also really believe that I don't want to impose any of my ideas [laughs] onto others. I really believe that people have to arrive at it on their own. So, it used to bother me a little bit more when I was just like, oh, but this way is better [laughs]. When people wouldn't get on board, I would be sad about it. But as long as I know that I, like, left that comment, then I can give myself a pat on the back for trying to move towards that ideal state. What about you [laughs]?

+ +

JOËL: I think this is probably also where I'm, like, now a recovering idealist. There was a time where I would leave a ton of comments on someone's PR. I almost had a view of like, how can I help you get your PR to be the best it can possibly be? And sometimes, if you start with something that's very rough around the edges, you're leaving a lot of comments. And I've been that guy who's left 50 comments on a PR. In retrospect, I think that was not being a good teammate.

+ +

STEPHANIE: Hmm.

+ +

JOËL: So, I think maybe my mental model or my, like, goal for PR review has changed a little bit. It's less about how can I help you make your code the best it can possibly be? And a how can I help you get your code to mergeable? And it's possible that mergeable means best that it can possibly be, but that's usually not the case. So, I'm going to give you some feedback: some things that confuse me, maybe raise one or two patterns that are existing in the app that maybe you weren't aware of that you should maybe consider applying. Maybe I'll raise a couple of ideas that are new, but that apply here.

+ +

And those might just be a, "Hey, let's just think about this. Maybe we don't want to do this in this PR, but maybe we want to look at them at some point. Or we should be thinking about this in a sort of rule of three situation. If we see this come up another time, maybe consider introducing a strategy pattern here, or maybe consider making this a value object, or separating these side effects from these pure behavior." But it's more of a dialogue about how can I help you get your PR to the point where it is mergeable?

+ +

STEPHANIE: Yeah. Another thing I thought about just now is both are meaningful or, like, both can provide meaning in different ways, and people ascribe different amounts of meaning to both; where I had worked with someone, a client developer before, who was not super interested in doing any kind of refactoring or, like, any, you know, second passes for quality. Because, for him, like, he just wanted to ship, right? That was where he found meaning in his work.

+ +

Whereas that actually made my work feel a lot more meaningless [chuckles] because I'm like, well, if we're just kind of hands on a keyboard, like robots shipping code, I don't know, that doesn't feel particularly motivating for me. You know, I do want to employ some of that craft a little bit more.

+ +

JOËL: And, I guess, yeah, idealism versus pragmatism is also...it's a personal individual thing. There's an element where it's a team decision, or at least a sense of, like, how much quality do we need at this point in the life cycle of the project? And what are the areas where we particularly want to emphasize quality? What are our quality standards? And that's, to a certain extent, consensus among the team that it's individual members. And it's also coming from team leadership.

+ +

STEPHANIE: Yeah. Yeah, exactly. I mentioned that, you know, just to, I think, shed a little bit of light that it's usually not personal, right [laughs]? There's that part of understanding that is really important to, yeah, like, keep building this shared world of writing software, and, hopefully, it should be meaningful for all of us.

+ +

JOËL: I think a few takeaways that I have would be, one, the value of, like, theory and idealism. These things help you to become a better developer. They help you to spot patterns. It's probably good to sort of have in the background always be learning some new thing, whether that's learning a new set of patterns, or learning some mental models, thinking about, oh, the difference between side effects and pure code, learning about particular ways of structuring code. These are all things that are good to have in your back pocket to be able to apply to the code that you're doing, even if it's a sort of after-the-fact, hey, I've done a similar task three different times. Is there a broader principle?

+ +

But then, also, take the time to really make sure that you're focusing on shipping code, and maybe that's learning to work in smaller chunks, working iteratively, learning to scope your work well. Because, in the end, delivering value is a thing that is something that we could all probably benefit from doing more of.

+ +

And then, finally, taking some time to self-reflect, a little bit of self-awareness in this area. What are the aspects of pragmatism and idealism that you find personally meaningful? What are the elements that you think bring value to your work, to your team? And let that sort of guide you on your next code writing or PR review.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie revisits the concept of "spiking"—a phase of exploration to determine the feasibility of a technical implementation or to address unknowns in feature requests—sharing her recent experiences with a legacy Rails application. Joël brings a different perspective by discussing his involvement with a client project that heavily utilizes the dry-rb suite of gems, highlighting the learning curve associated with adapting to new patterns and libraries.

+ +

Joël used to be much more idealistic and has moved to be more pragmatic. Stephanie has moved the other way. So together, Stephanie and Joël engage in a philosophical discussion on being an idealistic versus a pragmatic programmer. They explore the concept of programming as a blend of science and art, where technical decisions are not only about solving problems but also about expressing ideas and building shared understandings within a team.

+ + + +

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, a few weeks ago, we did an episode on spiking in response to a listener question. And I wanted to kind of revisit that topic for a little bit because I've been doing a lot of spiking on my client project. And for those who are not familiar, the way that I understand or define spikes is kind of as an exploration phase to figure out if a technical implementation might work. Or if you have a feature request with some unknowns, you can spend some time-boxed spiking to figure out what those unknowns might be.

+ +

And I'm working on your typical legacy Rails application [laughs]. And I think one thing that we talked about last time was this idea of, at what point does spiking end up being just working on the feature [laughs]? And I think that's especially true in an older codebase, where you kind of have to go down a few rabbit holes, maybe, just to even find out if something will trip you up down the line.

+ +

And the way I approached that this time around was just, like, identifying the constraints and putting a little flag there for myself. Like, these were rabbit holes that I could go down, but, you know, towards the initial beginning phase of doing the spiking, I decided not to. I just kind of bookmarked it for later.

+ +

And once I had identified the main constraints, that was when I was like, okay, like, what kind of solutions can I come up with for these constraints? And that actually then helped me kind of decide which ones we're pursuing a little bit more to get, like, the information I needed to ultimately make a decision about whether this was worth doing, right?

+ +

It kind of kept me...I'm thinking about, you know, when you are bowling with those safety guards [laughs], it keeps your ball from just rolling into the gutter. I think it helped with not going too deep into places that I may or may not be super fruitful while also, I think, giving me enough information to have a more realistic understanding of, like, what this work would entail.

+ +

JOËL: Would you say that this approach that you're taking is inspired or maybe informed by the conversation we had on the episode?

+ +

STEPHANIE: I was especially interested in avoiding the kind of binary of like, no, we can't do this because the system just, you know, isn't able to support it, or it's just too...it would be too much work. That was something I was really, like you said, kind of inspired by after that conversation because I wanted to avoid that trap a little bit.

+ +

And I think another really helpful framing was the idea of, like, okay, what would need to be done in order to get us to a place where this could be possible? And that's why I think identifying those constraints was important because they're not constraints forever. Like, we could do something about them if we really wanted to, so kind of avoiding the, like, it's not possible, right? And saying like, "It could be. Here's all the things that we need to do in order to make it possible." But I think that helped shift the conversation, especially with stakeholders and stuff, to be a little bit more realistic and collaborative.

+ +

So, Joël, what's new in your world?

+ +

JOËL: So, I'm also on a new client project, and a thing that's been really interesting in this codebase is that they've been using the dry-rb suite of gems pretty heavily. And I've seen a lot about the suite of gems. I've read about them. Interestingly, this is kind of the first time that I've been on a codebase that sort of uses them as a main pattern in the app. So, there's been a bit of a learning curve there, and it's been really interesting.

+ +

STEPHANIE: This is exciting to me because I know you have a lot of functional programming background, also, so it's kind of surprising that you're only now, you know, using something that explicit from functional languages in Ruby. And I'm curious: what's the learning curve, if not the paradigm? Like, what are you kind of encountering?

+ +

JOËL: I think there's a little bit of just the translation. How do these gems sort of approach this? So, they have to do a couple of, like, clever Ruby things to make some of these features work. Some of these also will have different method names, so a lot of just familiarizing myself with the libraries. Like, oh, well, this thing that I'm used to having called a particular thing has a slightly different name here or maybe not having all of the utilities. I was like, oh, how do we traverse with this particular library? Then you have to, like, look it up.

+ +

So, it's a lot of like, how do I do this thing I know how to do in, let's say, Elm? How do I translate that into Ruby? But then, also, some of the interplay of how that works in code that also does some very kind of imperative side effecty things also written by a team that is getting used to the pattern. And so, you'll sort of see things where people are pulling things in, but maybe you don't fully understand the deeper underlying approach that's meant to be used.

+ +

STEPHANIE: Have you noticed any use cases where the dry-rb patterns really shine in your application?

+ +

JOËL: A thing that's nice is that I think it really forces you to think about your edge cases in a way that sometimes Ruby developers play very fast and loose with "Yeah, whatever, it will never be nil." Push to production immediately start getting NoMethodError in your bug tracker. I never do this, by the way, but you know.

+ +

STEPHANIE: [laughs].

+ +

JOËL: Speaking from a friend's experience [laughs].

+ +

STEPHANIE: Asking for a friend, yeah [laughs].

+ +

JOËL: I think a thing that I've sort of had to figure out sort of every time I deal with these patterns in different languages is just the importance of good composition and good separation. Because you're adding these sort of wrapper context around things, if you're constantly wrapping and unwrapping, you're like, check things inside, and then do the next thing, and then unwrap again and branch and check and do the next thing, that code becomes really clunky in a way that you just sort of expect to do if you're just writing code in regular Ruby with a nil. But it doesn't really work with a dry-rb maybe or a result.

+ +

So, the pattern that I have found that works really well is to extract sort of every operation that can be, let's say, that could fail so that it would give you a result back. Extract that out into its own separate function that will construct a success or a failure, and then have your sort of main code that wants to then do a bunch of these things together.

+ +

All it does is use some of the dry-rb helper methods to compose all of these together, whether that's just some sort of, like, do notation, or binding, or fmap, or something like that, which allows you to have sort of individual chunks that can fail, and then one sort of aggregator piece of code that just finds a way to combine all of them nicely. And that avoids you having to do all this repetition.

+ +

STEPHANIE: Yeah, that makes a lot of sense.

+ +

JOËL: It's a pattern, I think; I had to learn the hard way when I was working with Elm. Because if you're taking a potential nullable value and then you want to do things with it but then that potential operation is also nullable because the input was potentially null, and then that just sort of propagates all the way down the chain. So, my whole chain of functions now is doing checks for nullability. And in Ruby, I could just be like, no, I checked it in the first function. I can then just trust that it's not null down the chain.

+ +

Elm doesn't do the like, trust me, bro. The compiler will force you to validate every time, and then the code just blows up, and it gets really painful. So, I had to start thinking about new models of thinking that would separate out code that actually needs to care and code that doesn't need to care about nullability. And I wrote an article about that. That turned into actually a conference talk as well. And these sort of ideas have served me really well at Elm. And I think these translate pretty well to dry-rb as well. That's something that I'm exploring, but the principles seem like they're not tied to a particular language.

+ +

STEPHANIE: Yeah, and it's kind of cool that you experienced all of that in working with Elm, where a compiler was there to yell at you [laughs] and kind of forcing you to...I don't know if do the right thing is the right word, but kind of think in the way that it wants you to think. And I can see people who are coming from Ruby and starting to experiment with dry-rb maybe needing a bit of that since it's not built-in in the tooling, just in a recoder view or just in conversations among devs.

+ +

JOËL: [inaudible 09:26] Beyond just the idea of wrapping your values and making sure you check them all the time, there are patterns that make that easier or more painful. And even in something like Elm, the compiler would yell at me would make sure I could not have a runtime error by forgetting to check for nullability. It did not prevent me from writing monstrosities of nested repeated conditionals checking if nil, if nil, if nil. That I had to figure out some sort of, like, higher-level patterns that play nicely with that kind of software.

+ +

And I think these are things that people have to sort of encounter, feel the pain, feel the frustration, and then move into those better patterns after the fact. And sometimes that's not easy because it's not obvious why that's a valuable pattern to approach.

+ +

STEPHANIE: Yeah, I agree completely. Speaking of following patterns and kind of arriving at maybe an ideal version of [chuckles], you know, what you'd like your code to do, you know, to build what you are looking to build [laughs]...this is my very poor attempt at a smooth transition that Joël [laughter] manages to be able to do [laughs] whenever we're trying to shift into the topic of the episode. Anyway, today, we were hoping to talk a little bit about this idea between being an idealistic programmer and a pragmatic programmer and the different journeys that we've each been on in arriving kind of how to balance the two.

+ +

JOËL: Yeah, you know, I think neither of these are absolutes, right? It's a spectrum. You probably move around that spectrum from day to day, and then probably, like, more general trends over your career. But I'm curious, for you today, if you had to pick one of those labels, like, which sort of zone of the spectrum would you put yourself in? Do you think you're more idealistic or more pragmatic?

+ +

STEPHANIE: I think I'm in a more of an idealistic zone right now.

+ +

JOËL: Would you say you're kind of like middle trending idealistic or kind of, like, pretty far down the idealistic side?

+ +

STEPHANIE: Middle trending idealistic. I like that way of describing it. I want to know where you are. And then I kind of wanted to try to take a step back and even define what that means for both of us.

+ +

JOËL: Right, right. I think the way I'd probably describe myself is a recovering idealist.

+ +

STEPHANIE: Oof. Yeah [laughs].

+ +

JOËL: I think there was a time where I was really idealistic. I really like knowing sort of underlying theory of software construction, broader patterns. By patterns here, I don't mean necessarily, like, you know, the Gang of Four, but just general sort of approaches that work well and using that to guide my work. But I've also been trending a lot more into the, like, pragmatic side of things in the past few years.

+ +

STEPHANIE: So, could you kind of tell me a little bit about what does pragmatic mean for you and what does ideal mean for you?

+ +

JOËL: So, I think the pragmatic side of me it's about delivering working software. If you're not shipping anything, you know, the most beautiful piece of art that you've created just warms your heart is useless. So, I think I'm sort of at the extreme end of pragmatism, right? It's all about shipping and shipping fast. And, in the end, that's generally the goal of software.

+ +

On the more idealistic side, the sort of doing everything kind of perfect or by the book, or, you know, maybe in a way that brings you personal satisfaction, oftentimes, at the expense of shipping and vice versa. Sometimes shipping comes at the expense of writing absolutely terrible code, but, of course, you know, there's value in both. Shipping is what actually delivers value to your users, your company, yourself if you're using the software.

+ +

But if you're not following patterns and things, you're often stuck in a really short-term thinking loop, where you are maybe delivering value today at the cost of being able to deliver value tomorrow or writing code that is unreadable or code that is difficult to collaborate on. So, more than just me shipping an individual feature, I've got to think about, while I'm working with a team, how can I help them be able to ship features or build on top of my work for tomorrow? So, that's sort of how I visualize the field. I'm curious what the words idealism and pragmatism mean to you.

+ +

STEPHANIE: Yeah. I agree with you that pragmatism is, you know, this idea of delivering working software. And I think I have seen it very, you know, kind of condensed as, like, moving quickly, getting stuff out the door, basically, like, end result being, like, a thing that you can use, right?

+ +

I think I've personally been reassessing that idea a lot because I'm kind of almost wondering like, well, what are we moving quickly for [laughs]? I sometimes have seen pragmatism just end there being like, okay, like, it's all about velocity. And then, I'm kind of stuck being like, well, if you write working software for, you know, completely the wrong thing, is that still pragmatic? I don't know. So, that's kind of where I'm at these days with–I'm feeling a little bit more suspect of pragmatism, at least wanting to make sure that, especially with the people that I'm working with day to day, that we're agreeing on what that means and what success means.

+ +

And then, as for idealism, I think also, actually, I now have a little bit of duality in terms of how I understand that as well. One of them being, yes, definitely, like, by the book or, like, by the ideas that we've, you know, some very smart people [laughs] have figured out as, like, this is clean or good quality, or these are the patterns to, you know, make your code as, again, as clean, I don't know, kind of putting air quotes around that, as possible.

+ +

And then, I actually like what you really said about code that warms your heart [laughs] that you feel, like, really moved by or, like, just excited about or inspired by because I think that can also be a little bit different from just following theories that other people have defined.

+ +

The more I spend doing this stuff, the more I am convinced that writing software is actually a very creative practice. And that's something that I've, like, definitely had to balance with the pragmatism a bit more because there are days when it's just not coming [chuckles], you know, like, I just stare at a blank, new file. And I'm like, I can't even imagine what these classes would be because, like, that creative part of my brain just, like, isn't on that day. So, that's kind of where I'm sitting in terms of, like, what idealistic programming kind of seems to me.

+ +

JOËL: There's definitely an element of programming that feels like self-expression, you know, there are parameters around that. And working with a team, you probably all sort of, like, move towards some average. But I would definitely say that there is some element of self-expression in coding.

+ +

STEPHANIE: Yeah, 100%. Have you heard about this paper called Programming as Theory Building?

+ +

JOËL: The name sounds vaguely familiar, but I can't place the main idea in my mind right now.

+ +

STEPHANIE: It's, like, an academic-ish paper from the 80s. And I'll link to it in the show notes because I can't remember the author right now. But the idea is writing code is actually just one way of expressing a theory that we are building. In fact, that expression doesn't even....it's like, it's impossible for it to fully encapsulate everything that was involved in the building of the theory because every decision you make, you know, you decide what not to do as well, right? Like, all the things that you didn't encode in your application is still part of this theory, like stuff that you rejected in order to interpret and make abstract the things that you are translating from the quote, unquote "real world" into code.

+ +

That really stuck with me because, in that sense, I love this idea that you can create your own little world, right? Like, you're developing it when you code. And that is something that gets lost a little bit when we're just focused on the pragmatic side of things.

+ +

JOËL: Where things get tricky as well is that when you're working with a team, you're not just building your own little world. You're building a shared world with shared mental models, shared metaphors. That's where oftentimes it becomes important to make sure that the things that you are thinking about are expressed in a way that other people could read your code and then immediately pick up on what's happening. And that can be through things like documentation, code comments. It can also be through more rigorous data modeling.

+ +

So, for example, I am a huge fan of value objects in general. I tend to not have raw numbers floating around in an app. I like to wrap them in some kind of class and say, "Hey, these numbers that are floating around they actually represent a thing," and I'll name that thing so that other people can get a sense that, oh, it is one of the moving parts of this app, and then here are the behaviors that we expect on it.

+ +

And that is partly for sort of code correctness and things like that but also as a sort of way of communicating and a way of contributing to that shared reality that we're creating with the team in a way that if I just left a raw number, that would be almost, like, leaving something slightly undefined. Like, the number is there. It does a thing, but what it does is maybe a little bit more implied. I know in my mind that this is a dollar amount, and maybe there's even a comment above it that says, "Dollar amount." But it makes it a little bit harder for it to play in with everybody else's realities or view of the system than if it were its own object.

+ +

STEPHANIE: Yeah, I like what you said about you're building a shared world with your fellow colleagues. And that helped explain to me why, as some people say, naming is the hardest part about building software because, yeah, like you said, even just saying you are wanting to make a method or class expressive. And we talked about how code is a way of expressing yourself. You could, like, name all your stuff in Wingdings [laughs], but we don't. I actually don't know if you could do that. But that was, for some reason, what I imagined. I was like, it's possible, and you could deliver software in complete gibberish [laughs].

+ +

JOËL: In theory, could you say that naming your variables as emoji is the most expressive way? Because now it's all emotions.

+ +

STEPHANIE: A picture is worth a thousand words, as they say.

+ +

JOËL: So, this variable is the frowny face, upside-down smile face. It doesn't get more expressive than that.

+ +

STEPHANIE: At a former company, in our Slack workspace, I had a co-worker who loved to use the circus tent emoji to react to things. And, like, I'm convinced that no one really knew what it meant, but we also kind of knew what it meant. We were just like, oh yeah, that's the emoji that she uses to express amusement or, like, something a little bit ironic. And we all kind of figured it out [laughs] eventually. So, again, I do think it's possible. I bet someone has done, like, a creative experiment with writing an application in just emojis. This is now going to be some research I do after this episode [laughter].

+ +

JOËL: It is fun when you have, like, a teammate. You know they have the signature emoji that they respond to on things.

+ +

STEPHANIE: Yep. Absolutely. So, you know, we kind of spent a little bit of time talking about idealism. I actually wanted to pull back to the idea of pragmatism because, in preparation for this episode, I also revisited my copy of The Pragmatic Programmer. Are you familiar with this book? Have you read it at all?

+ +

JOËL: I have read it. It's been probably ten years. We did, I think, a book club at thoughtbot to go through the book.

+ +

STEPHANIE: I was skimming the table of contents because I was curious about, again, that, like, definition of pragmatism. You and I had kind of talked about how it can be short-sighted. But what I was actually pretty impressed with, and I imagine this is why the book holds up, you know, after decades, is success for them also means being able to continue to deliver quality software. And that idea of continuity kind of implied, to me, that there was an aspect of, like, making sure the quality meets a certain threshold and, like, incorporating these theories and doing the best practices because they're thinking about success over time, right? Not just the success of this particular piece that you're delivering.

+ +

JOËL: I would say most people in our industry are sort of balancing those two objectives, right? They're like, we want to have a decent velocity and ship things, but at the same time, we want to be able to keep delivering. We want a certain threshold of quality.

+ +

In between those two objectives, there is a sea of trade-offs, and how you manage them are probably a little bit part of your personality as a developer and is probably also, to a certain extent, a function of your experience, learning sort of when to lean more into taking some shortcuts to ship faster and when to double down on certain practices that increase code quality, and what aspects of quality value more than others because not all forms of quote, unquote, "quality" are the same.

+ +

I think a sort of source of danger, especially for newer developers, is you sort of start on almost, like, a hyper-pragmatic side of things because most people get into software because they want to build things. And the ultimate way to build is to ship, and then you sort of encounter problems where you realize, oh, this code is really clunky. It's harder and harder to ship. Let me learn some elements of code quality. Let's get better at my craft so that I can build software that has fewer bugs or that I can ship more consistently. And that's great.

+ +

And then, you sort of run into some, like, broader sort of theories of programming: patterns, structures, things like that. And it becomes very easy to sort of blindly copy-paste that everywhere to the point where I think it's almost a bit of a meme, the, like, intermediate programmer who's read Clean Code or the Design Patterns book and is just now, like, applying these things blindly to every piece of code they encounter to the annoyance of the entire team.

+ +

STEPHANIE: I think you just about described my trajectory [laughter], though hopefully, I was not so obnoxious about [laughs] it for my team having to deal with my, like, discovering [laughs] theories that have long been used.

+ +

JOËL: I think we kind of all go through that journey to a certain extent, right? It's a little bit different for every one of us, but I think this is a journey that is really common for developers.

+ +

STEPHANIE: Yeah. One thing I frequently think about a lot is how much I wished I had known some of that theory earlier. But I don't think I have an answer one way or another. It's like; I'm not sure if having that knowledge earlier really would have helped me because I've also definitely been in...I'm just thinking about, like, when I was in college in lectures trying to absorb theories that made no sense to me because I had no, like, practical experience to connect it to. It's almost, like, maybe there is, like, that perfect time [laughs] where it is the most valuable for what you're doing. And I don't know. I kind of believe that there is a way to bridge that gap.

+ +

JOËL: I mean, now we're kind of getting into an element of pedagogy. Do you sort of teach the theory first, and then show how to apply it to problems? Or do you show problems and then introduce bits of theory to help people get unstuck and maybe then cap it off by like, oh, these, like, five different, like, techniques I showed you to, like, solve five different problems, turns out they all fit in some grand unified theory? And, like, here's how the five things you thought were five different techniques are actually the same technique viewed from five different perspectives. Let me blow your mind.

+ +

STEPHANIE: That's a Joël approach [laughter] to teaching if I've ever heard one.

+ +

JOËL: I'm a huge fan of that approach. Going back to some of the, like, the functional programming ideas, I think that's one that really connected for me. I struggled to learn things like monads, and functors, and things like that. And I think, in my mind, these two approaches is like the Haskell school of teaching and the Elm school of teaching.

+ +

Haskell will sort of say, "Hey, let me teach you about this theory of monads and all these things, and then, we'll look at some ways where that can be applied practically." Whereas Elm will say, "No, you don't need to know about this. Let's look at some practical problems. Oh, you've got null values you need to check. Here's how you can, like, handle nullability in a safe way. Oh, you've got a bunch of HTTP requests that might resolve in random order, and you want to, like, deal with them when they all come back. Here's some tips on how you can do that."

+ +

And then, you have three or four things, and then, eventually, it just sort of lets you say, "Wait a minute, all of these problems are sort of all the same, and it turns out they all fit in some unified theory." And then, the light bulb goes off, and you're like, "Ooh, so now when I'm dealing with unknown blobs of Jason trying to parse data out of them, I'll bet I can use the same techniques I used for chaining HTTP requests to dig multiple dependent pieces of JSON."

+ +

STEPHANIE: Yeah. And that's so satisfying, right? It really is kind of leveling up in that Galaxy Brain meme sort of way.

+ +

JOËL: Yeah. And that's maybe to a certain extent even a value of idealism because if you build your system in such a way that it follows some of these patterns, then insights and intuitions that people have in one part of your code can then carry to other parts of your code, and that's incredibly powerful.

+ +

STEPHANIE: Yeah. And I almost wonder because you also mentioned kind of where you end up on the spectrum is a function of your experience. I wonder if us, you know, being consultants and seeing patterns across many applications also kind of contributes to the striving for idealism [laughs].

+ +

JOËL: It's kind of both, right? Because there's very high incentive to ship pretty rapidly, especially if you're on a shorter engagement or if you're on a project that has a shorter timescale. But also, yes, because you've seen so many projects, you've seen how things can go wrong. Also, you've seen the same problem from 20 different perspectives that are all slightly different. And so, some of those broader patterns can start emerging in your head.

+ +

STEPHANIE: Yeah, honestly, I think that's kind of the work that I enjoy the most in consulting because a lot of clients bring us on when they're like, "Hey, like, we've reached a point where our velocity has slowed down. Like, can you help us unstick our developers?" And that's actually when I've found that leaning on the theories and maybe a little bit of idealism is actually really useful because I'm kind of providing those tools to developers at this time when they need it. That's kind of why I have been saying trending idealism because I have found that particularly useful at work.

+ +

JOËL: There's an element here of, like, looking at a bunch of different use cases and then finding some sort of unifying model or theory. And that's a word that I think programmers have a love-hate relationship with: Abstraction. I don't know about you, but designing abstractions is a lot of fun for me. I love designing abstractions. I have always loved designing abstractions. It's not always the best use of my time, and it's not always the best thing for a codebase.

+ +

STEPHANIE: Ooh, okay, okay. This was a good transition. I hear you that, like, yeah, love-hate relationship. It's hard. That's kind of where I've ended up. It's really hard. And I think it's because it requires that creative thinking.

+ +

JOËL: It requires that creative thinking. And then also, like, it requires you to sort of see more broadly, a more broad picture. What are the things that are connected, the things that are disconnected, even though they seem related? And, like, being able to sort of slice those similarities from each other.

+ +

STEPHANIE: Yeah. I agree. And the interesting part is that, like, a lot of the time you just don't know yet. And you kind of have to come back to reality and admit that you don't know yet, you know, got to come back to earth, take a look around, and, yeah, you can go through the thought exercise of thinking [laughs] about all of the possibilities, and I imagine you could do that forever [laughs].

+ +

JOËL: I mean, that's why we have heuristics like the rule of three that says, "Don't abstract something out or attempt to DRY code until you've seen three use cases of it." So, maybe leave a little bit of duplication or a little bit of maybe not perfectly factored code until you have a couple of more examples. And the sort of real picture starts emerging a little bit more.

+ +

STEPHANIE: So, I think we are kind of at this topic already, but was there a moment or was there something that kind of helped you realize, like, oh, I can't be in that space of imagining abstractions [laughs] forever when I have to deliver software? Like, what changed for you to be the, as you said yourself, recovering idealist and having to maybe employ some more pragmatic heuristics?

+ +

JOËL: And I think, for me, it's partly being a consultant and being in a lot of projects and having that pressure to work with deadlines and sort of not having an infinite canvas to paint with, having to sort of fit some of my grand ideas into the reality of, we've got a week or two weeks to get this thing done, and also working with a team, and some ideas don't work well with every team. Every team is kind of at a different place.

+ +

And abstractions sort of only serve you as well as they are useful to not only you but the team at large. So, if a team is not comfortable with a set of abstractions, or it's sort of, like, too far down a path, then that can be really challenging. And that's where something like the dry-rb set of gems, which has some really fun abstractions like a mental model for doing things, depending on the team, that can be a really heavy lift. And so, as much as I like those patterns, I might think long and hard before I try to push this on a whole team.

+ +

STEPHANIE: Yeah, I kind of had to navigate a situation like that recently, where I was doing a code review, and I had left some suggestions about refactoring to encapsulate some responsibilities better. And then, I was like, oh, and then I noticed another thing that we could do to make that easier. And it, you know, definitely can start to spiral. And the author, you know, kind of responded to me and said, "Hey, like, I really appreciate these comments, but we are a bit tight on deadline for this project. So, is it okay if I, like, revisit this when we've delivered it?"

+ +

And, you know, I was just like, "Yeah, it's totally up to you." At the end of the day, I want whoever's authoring this code to have, like, full agency about how they want to move forward. And it was really helpful for me to get that context of, like, oh, they're a bit tight on the deadline because then I can start to meet them where they're at. And maybe I can give some suggestions for moving towards that ideal state, but ones that are lower left, and that is still better than nothing.

+ +

JOËL: That sounds awfully pragmatic.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Moving in a positive direction, we're getting halfway. It's better than nothing. That's very pragmatic.

+ +

STEPHANIE: Hmm. Wow. But it's pragmatically moving towards idealism.

+ +

JOËL: [laughs]

+ +

STEPHANIE: If that is even possible [laughs].

+ +

JOËL: Uh-huh.

+ +

STEPHANIE: That's maybe the book that I'm going to write, not The Pragmatic Programmer, but The Pragmatically Idealistic Programmer [laughs].

+ +

JOËL: The Pragmatic Idealist.

+ +

STEPHANIE: Ooh, yeah, I like that. Okay. Watch out for that book coming 2030 [laughter], written by me and Joël.

+ +

JOËL: So, I think you brought up a really interesting point, which is the idea of pragmatism versus idealism when it comes to code review. Do you find that you think about these ideas differently when reviewing somebody else's code versus when you write your own?

+ +

STEPHANIE: Oooh, yeah. I'm not sure exactly why, but definitely, when I'm reviewing someone else's code, I'm already in the headspace of, you know, I have some separation, right? Like, I'm not in the mode of thinking very hard [laughs] about what I'm creating. I'm just, like, in the editing kind of phase. And then, I can actually pull more from different theories and ideas, and I find that actually quite easier. When I'm writing my own code, it's just whatever comes out, right? And then, hopefully, I have the time to revisit it and give it a scan, and then start to integrate the, like, idealistic theories and the patterns that I would like to be using.

+ +

But it definitely...for patterns that I feel a lot more confident about or more familiar with, they just come out mostly kind of oriented in that way if I have the time, or sometimes I will make the time, you know. I'll just say, "It's not done yet," because I know it can be better. I think that could be another, like, pragmatically idealist way of handling that.

+ +

JOËL: [laughs]

+ +

STEPHANIE: Right? It's just telling people, "I'm not done." [laughs] It's not done until I do at least give it an attempt.

+ +

JOËL: So, it's kind of a two-phase thing when you're writing your own code, whereas it's only a single phase when you're reviewing somebody else's.

+ +

STEPHANIE: Yeah. Yeah. But, like I said earlier, it's like, I also really believe that I don't want to impose any of my ideas [laughs] onto others. I really believe that people have to arrive at it on their own. So, it used to bother me a little bit more when I was just like, oh, but this way is better [laughs]. When people wouldn't get on board, I would be sad about it. But as long as I know that I, like, left that comment, then I can give myself a pat on the back for trying to move towards that ideal state. What about you [laughs]?

+ +

JOËL: I think this is probably also where I'm, like, now a recovering idealist. There was a time where I would leave a ton of comments on someone's PR. I almost had a view of like, how can I help you get your PR to be the best it can possibly be? And sometimes, if you start with something that's very rough around the edges, you're leaving a lot of comments. And I've been that guy who's left 50 comments on a PR. In retrospect, I think that was not being a good teammate.

+ +

STEPHANIE: Hmm.

+ +

JOËL: So, I think maybe my mental model or my, like, goal for PR review has changed a little bit. It's less about how can I help you make your code the best it can possibly be? And a how can I help you get your code to mergeable? And it's possible that mergeable means best that it can possibly be, but that's usually not the case. So, I'm going to give you some feedback: some things that confuse me, maybe raise one or two patterns that are existing in the app that maybe you weren't aware of that you should maybe consider applying. Maybe I'll raise a couple of ideas that are new, but that apply here.

+ +

And those might just be a, "Hey, let's just think about this. Maybe we don't want to do this in this PR, but maybe we want to look at them at some point. Or we should be thinking about this in a sort of rule of three situation. If we see this come up another time, maybe consider introducing a strategy pattern here, or maybe consider making this a value object, or separating these side effects from these pure behavior." But it's more of a dialogue about how can I help you get your PR to the point where it is mergeable?

+ +

STEPHANIE: Yeah. Another thing I thought about just now is both are meaningful or, like, both can provide meaning in different ways, and people ascribe different amounts of meaning to both; where I had worked with someone, a client developer before, who was not super interested in doing any kind of refactoring or, like, any, you know, second passes for quality. Because, for him, like, he just wanted to ship, right? That was where he found meaning in his work.

+ +

Whereas that actually made my work feel a lot more meaningless [chuckles] because I'm like, well, if we're just kind of hands on a keyboard, like robots shipping code, I don't know, that doesn't feel particularly motivating for me. You know, I do want to employ some of that craft a little bit more.

+ +

JOËL: And, I guess, yeah, idealism versus pragmatism is also...it's a personal individual thing. There's an element where it's a team decision, or at least a sense of, like, how much quality do we need at this point in the life cycle of the project? And what are the areas where we particularly want to emphasize quality? What are our quality standards? And that's, to a certain extent, consensus among the team that it's individual members. And it's also coming from team leadership.

+ +

STEPHANIE: Yeah. Yeah, exactly. I mentioned that, you know, just to, I think, shed a little bit of light that it's usually not personal, right [laughs]? There's that part of understanding that is really important to, yeah, like, keep building this shared world of writing software, and, hopefully, it should be meaningful for all of us.

+ +

JOËL: I think a few takeaways that I have would be, one, the value of, like, theory and idealism. These things help you to become a better developer. They help you to spot patterns. It's probably good to sort of have in the background always be learning some new thing, whether that's learning a new set of patterns, or learning some mental models, thinking about, oh, the difference between side effects and pure code, learning about particular ways of structuring code. These are all things that are good to have in your back pocket to be able to apply to the code that you're doing, even if it's a sort of after-the-fact, hey, I've done a similar task three different times. Is there a broader principle?

+ +

But then, also, take the time to really make sure that you're focusing on shipping code, and maybe that's learning to work in smaller chunks, working iteratively, learning to scope your work well. Because, in the end, delivering value is a thing that is something that we could all probably benefit from doing more of.

+ +

And then, finally, taking some time to self-reflect, a little bit of self-awareness in this area. What are the aspects of pragmatism and idealism that you find personally meaningful? What are the elements that you think bring value to your work, to your team? And let that sort of guide you on your next code writing or PR review.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+5hbXLnS9 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 420: Test Database Woes + https://bikeshed.thoughtbot.com/420 + ea4448fb-72a6-4ecf-8eda-b7d004ddaa9c + Tue, 26 Mar 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël shares his recent project challenge with Tailwind CSS, where classes weren't generating as expected due to the dynamic nature of Tailwind's CSS generation and pruning. Stephanie introduces a personal productivity tool, a "thinking cap," to signal her thought process during meetings, which also serves as a physical boundary to separate work from personal life. + +The conversation shifts to testing methodologies within Rails applications, leading to an exploration of testing philosophies, including developers' assumptions about database cleanliness and their impact on writing tests. + 28:16 + no + + + Joël shares his recent project challenge with Tailwind CSS, where classes weren't generating as expected due to the dynamic nature of Tailwind's CSS generation and pruning. Stephanie introduces a personal productivity tool, a "thinking cap," to signal her thought process during meetings, which also serves as a physical boundary to separate work from personal life. +The conversation shifts to testing methodologies within Rails applications, leading to an exploration of testing philosophies, including developers' assumptions about database cleanliness and their impact on writing tests. +Avdi’s classic post on how to use database cleaner (https://avdi.codes/configuring-database_cleaner-with-rails-rspec-capybara-and-selenium/) +RSpec change matcher (https://rubydoc.info/gems/rspec-expectations/RSpec%2FMatchers:change) +Command/Query separation (https://martinfowler.com/bliki/CommandQuerySeparation.html) +When not to use factories (https://thoughtbot.com/blog/speed-up-tests-by-selectively-avoiding-factory-bot) +Why Factories? (https://thoughtbot.com/blog/why-factories) +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: I'm working on a new project, and this is a project that uses Tailwind CSS for its styling. And I ran into a bit of an annoying problem with it just getting started, where I was making changes and adding classes. And they were not changing the things I thought they would change in the UI. And so, I looked up the class in the documentation, and then I realized, oh, we're on an older version of the Tailwind Rails gem. So, maybe we're using...like, I'm looking at the most recent docs for Tailwind, but it's not relevant for the version I'm using. Turned out that was not the problem. +Then I decided to use the Web Inspector and actually look at the element in my browser to see is it being overwritten somehow by something else? And the class is there in the element, but when I look at the CSS panel, it does not show up there at all or having any effects. And that got me scratching my head. And then, eventually, I figured it out, and it's a bit of a facepalm moment [laughs]. +STEPHANIE: Oh, okay. +JOËL: Because Tailwind has to, effectively, generate all of these, and it will sort of generate and prune the things you don't need and all of that. They're not all, like, statically present. And so, if I was using a class that no one else in the app had used yet, it hadn't gotten generated. And so, it's just not there. There's a class on the element, but there's no CSS definition tied to it, so the class does nothing. +What you need to do is there's a rake task or some sort of task that you can run that will generate things. There's also, I believe, a watcher that you can run, some sort of, like, server that will auto-generate these for you in dev mode. I did not have that set up. So, I was not seeing that new class have any effect. Once I ran the task to generate things, sure enough, it worked. And Tailwind works exactly how the docs say they do. But that was a couple of hours of my life that I'm not getting back. +STEPHANIE: Yeah, that's rough. Sorry to hear. I've also definitely gone down that route of like, oh, it's not in the docs. The docs are wrong. Like, do they even know what they're talking about? I'm going to fix this for everyone. And similarly have been humbled by a facepalm solution when I'm like, oh, did I yarn [laughs]? No, I didn't [laughs]. +JOËL: Uh-huh. I'm curious, for you, when you have sort of moments where it's like the library is not behaving the way you think it is, is your default to blame yourself, or is it to blame the library? +STEPHANIE: [laughs]. Oh, good question. +JOËL: And the follow-up to that is, are you generally correct? +STEPHANIE: Yeah. Yep, yep, yep. Hmm, I will say I externalize the blame, but I will try to at least do, like, the basic troubleshooting steps of restarting my server [laughter], and then if...that's as far as I'll go. And then, I'll be like, oh, like, something must be wrong, you know, with this library, and I turn to Google. And if I'm not finding any fruitful results, again, you know, one path could be, oh, maybe I'm not Googling correctly, but the other path could be, maybe I've discovered something that no one else has before. +But to your follow-up question, I'm almost, like, always wrong [laughter]. I'm still waiting for the day when I, like, discover something that is an actual real problem, and I can go and open an issue [chuckles] and, hopefully, be validated by the library author. +JOËL: I think part of what I heard is that your debugging strategy is basic, but it's not as basic as Joël's because you remember to restart the server [chuckles]. +STEPHANIE: We all have our days [laughter]. +JOËL: Next time. So, Stephanie, what is new in your world? +STEPHANIE: I'm very excited to share this with you. And I recognize that this is an audio medium, so I will also describe the thing I'm about to show you [laughs]. +JOËL: Oh, this is an object. +STEPHANIE: It is an object. I got a hat [laughs]. +JOËL: Okay. +STEPHANIE: I'm going to put it on now. It's a cap that says "Thinking" on it [laughs] in, like, you know, fun sans serif font with a little bit of edge because the thinking is kind of slanted. So, it is designy, if you will. It's my thinking cap. And I've been wearing it at work all week, and I love it. +As a person who, in meetings and, you know, when I talk to people, I have to process before I respond a lot of the time, but that has been interpreted as, you know, maybe me not having anything to say or, you know, people aren't sure if I'm, you know, still thinking or if it's time to move on. And sometimes I [chuckles], you know, take a long time. My brain is just spinning. I think another funny hat design would be, like, the beach ball, macOS beach ball. +JOËL: That would be hilarious. +STEPHANIE: Yeah. Maybe I need to, like, stitch that on the back of this thinking cap. Anyway, I've been wearing it at work in meetings. And then, when I'm just silently processing, I'll just point to my hat and signal to everyone what's [laughs] going on. And it's also been really great for the end of my work day because then I take off the hat, and because I've taken it off, that's, like, my signal, you know, I have this physical totem that, like, now I'm done thinking about work, and that has been working. +JOËL: Oh, I love that. +STEPHANIE: Yeah, that's been working surprisingly well to kind of create a bit more of a boundary to separate work thoughts and life thoughts. +JOËL: Because you are working from home and so that boundary between professional life and personal life can get a little bit blurry. +STEPHANIE: Yeah. I will say I take it off and throw it on the floor kind of dramatically [laughter] at the end of my work day. So, that's what's new. It had a positive impact on my work-life balance. And yeah, if anyone else has the problem of people being confused about whether you're still thinking or not, recommend looking into a physical thinking cap. +JOËL: So, you are speaking at RailsConf this spring in Detroit. Do you plan to bring the thinking cap to the conference? +STEPHANIE: Oh yeah, absolutely. That's a great idea. If anyone else is going to RailsConf, find me in my thinking cap [laughs]. +JOËL: So, this is how people can recognize Bikeshed co-host Stephanie Minn. See someone walking around with a thinking cap. +STEPHANIE: Ooh. thinkingbot? +JOËL: Ooh. +STEPHANIE: Have I just designed new thoughtbot swag [laughter]? We'll see if this catches on. +JOËL: So, we were talking recently, and you'd mentioned that you were facing some really interesting dilemmas when it came to writing tests and particularly how tests interact with your test database. +STEPHANIE: Yeah. So, I recently, a few weeks ago, joined a new client project and, you know, one of the first things that I do is start to run those tests [laughs] in their codebase to get a sense of what's what. And I noticed that they were taking quite a long time to get set up before I even saw any progress in terms of successes or failures. So, I was kind of curious what was going on before the examples were even run. +And when I tailed the logs for the tests, I noticed that every time that you were running the test suite, it would truncate all of the tables in the test database. And that was a surprise to me because that's not a thing that I had really seen before. And so, basically, what happens is all of the data in the test database gets deleted using this truncation strategy. And this is one way of ensuring a clean slate when you run your tests. +JOËL: Was this happening once at the beginning of the test suite or before every test? +STEPHANIE: It was good that it was only running once before the test suite, but since, you know, in my local development, I'm running, like, a file at a time or sometimes even just targeting a specific line, this would happen on every run in that situation and was just adding a little bit of extra time to that feedback loop in terms of just making sure your code was working if that's part of your workflow. +JOËL: Do you know what version of Rails this project was in? Because I know this was popular in some older versions of Rails as a strategy. +STEPHANIE: Yeah. So, it is Rails 7 now, recently upgraded to Rails 7. It was on Rails 6 for a little while. +JOËL: Very nice. I want to say that truncation is generally not necessary as of Rails...I forget if it's 5 or 6. But back in the day, specifically for what are now called system tests, the sort of, like, Capybara UI-driven browser tests, you had, effectively, like, two threads that were trying to access the database. And so, you couldn't have your test data wrapped in a transaction the way you would for unit tests because then the UI thread would not have access to the data that had been created in a transaction just for the test thread. And so, people would use tools like Database Cleaner to use a truncation strategy to clear out everything between tests to allow a sort of clean slate for these UI-driven feature specs. +And then, I want to say it's Rails 5, it may have been Rails 6 when system tests were added. And one of the big things there was that they now could, like, share data in a transaction instead of having to do two separate threads and one didn't have access to it. And all of a sudden, now you could go back to transactional fixtures the way that you could with unit tests and really take advantage of something that's really nice and built into Rails. +STEPHANIE: That's cool. I didn't know that about system tests and that kind of shift happening. I do think that, in this case, it was one of those situations where, in the past, the database truncation, in this case, particular using the Database Cleaner gem was necessary, and that just never got reassessed as the years went by. +JOËL: That's one of the classic things, right? When you upgrade a Rails app over multiple versions, and sometimes you sort of get a new feature that comes in for free with the new version, and you might not be aware of it. And some of the patterns in the app just kind of keep going. And you don't realize, hey, this part of the app could actually be modernized. +STEPHANIE: So, another interesting thing about this testing situation is that I learned that, you know, if you ran these tests, you would experience this truncation strategy. But the engineering team had also kind of played around with having a different test setup that didn't clean the database at all unless you opted into it. +JOËL: So, your test database would just...each test would just keep writing to the database, but they're not wrapped in transactions. Or they are wrapped in transactions, but you may or may not have some additional data. +STEPHANIE: The latter. So, I think they were also using the transaction strategy there. But, you know, there are some reasons that you would still have some data persisted across test runs. I had actually learned that the use transactional fixtures config for RSpec doesn't roll back any data that might have been created in a before context hook. +JOËL: Yep, or a before all. Yeah, the transaction wraps the actual example, but not anything that happens outside of it. +STEPHANIE: Yeah, I thought that was an interesting little gotcha. So, you know, now we had these, like, two different ways to run tests. And I was chatting with a client developer about how that came to be. And we then got into an interesting conversation about, like, whether or not we each expect a clean database in the first place when we write our tests or when we run our tests, and that was an area that we disagreed. +And that was cool because I had not really, like, thought about like, oh, how did I even arrive at this assumption that my database would always be clean? I think it was just, you know, from experience having only worked in Rails apps of a certain age that really got onto the Database [laughs] Cleaner train. But it was interesting because I think that is a really big assumption to make that shapes how you then approach writing tests. +JOËL: And there's kind of a couple of variations on that. I think the sort of base camp approach of writing Rails with fixtures, you just sort of have, for the most part, an existing set of data that's there that you maybe layer on a few extra things on. But there's base level; you just expect a bunch of data to exist in your test database. So, it's almost going off the opposite assumption, where you can always assume that certain things are already there. Then there's the other extreme of, like, you always assume that it's empty. And it sounds like maybe there's a position in the middle of, like, you never know. There may be something. There may not be something, you know, spin the wheel. +STEPHANIE: Yeah. I guess I was surprised that it, you know, that was just a question that I never really asked myself prior to this conversation, but it could feel like different testing philosophies. But yeah, I was very interested in this, you know, kind of opinion that was a little bit different from mine about if you assume that your database, your test database, is not clean, that kind of perhaps nudges you in the direction of writing tests that are less coupled to the database if they don't need to be. +JOËL: What does coupling to the database mean in this situation? +STEPHANIE: So, I'm thinking about Rails tests that might be asserting on a change in database behavior, so the change matcher in RSpec is one that I see maybe sometimes used when it doesn't need to be used. And we're expecting, like, account to have changed the count of the number of records on it for a model have changed after doing some work, right? +JOËL: And the change matcher from RSpec is one that allows you to not care whether there are existing records or not. It sort of insulates you from that. +STEPHANIE: That's true. Though I guess I was thinking almost like, what if there was some return value to assert on instead? And would that kind of help you separate some side effects from methods that might be doing too much? And kind of when I start to see tests that have both or are asserting on something being returned, and then also something happening, that's one way of, like, figuring out what kind of coupling is going on inside this test. +JOËL: It's the classic command-query separation principle from object-oriented design. +STEPHANIE: I think another one that came to mind, another example, especially when you're talking about system tests, is when you might be using Capybara and you end up...maybe you're going through a flow that creates a record. But from the user perspective, they don't actually know what's going on at the database level. But you could assert that something was created, right? But it might be more realistic at that level of abstraction to be asserting some kind of visual element that had happened as a result of the flow that you're testing. +JOËL: Yeah. I would, in fact, go so far as to say that asserting on the state of your database in a system test is an anti-pattern. System tests are sort of, by design, meant to be all about user behavior trying to mimic the experience of a user. And a user of a website is not going to be able to...you hope they're not able to SSH into [chuckles] your database and check the records that have been created. If they can, you've got another problem. +STEPHANIE: I wonder if you could take this idea to the extreme, though. And do you think there is a world where you don't really test database-level concerns at all if you kind of believe this idea that it doesn't really matter what the state of it should be? +JOËL: I guess there's a few different things on, like, what it matters about the state of it because you are asserting on its state sort of indirectly in a sort of higher level integration test. You're asserting that you see certain things show up on the screen in a system test. And maybe you want to say, "I do certain tasks, and then I expect to see three items in an unordered list." Those three items probably come from the database, although, you know, you could have it where they come from an API or something like that. +So, the database is an implementation level. But if you had random data in your database, you might, in some tests, have four items in the list, some tests have five. And that's just going to be a flaky test, and that's going to be incredibly painful. So, while you're not asserting on the database, having control over it during sort of test setup, I think, does impact the way you assert. +STEPHANIE: Yeah, that makes sense. I was suddenly just thinking about, like, how that exercise can actually tell you perhaps, like, when it is important to, in your test setup, be persisting real records as opposed to how much you can get away with, like, not interacting with it because, like, you aren't testing at that integration level. +JOËL: That brings up a good point because a lot of tests probably you might need models, but you might not need persisted models to interact with them, if you're testing a method on a model that just does things based off its internal state and not any of the ActiveRecord database queries, or if you have some other service or something that consumes a model that doesn't necessarily need to query. +There's a classic blog post on the thoughtbot blog about when you should not reuse. There's a classic blog post on the thoughtbot blog about when not to use FactoryBot. And, you know, we are the makers of FactoryBot. It helps set up records in your database for testing. And people love to use it all the time. And we wrote an article about why, in many cases, you don't need to create something into the database. All you need is just something in memory, and that's going to be much faster than using FactoryBot because talking to the database is expensive. +STEPHANIE: Yeah, and I think we can see that in the shift from even, like, fixtures to factories as well, where test data was only persisted as needed and as needed in individual tests, rather than seeding it and having all of those records your entire test run. And it's cool to see that continuing, you know, that idea further of like, okay, now we have this new, popular tool that reduce some of that. But also, in most cases, we still don't need...it's still too much. +JOËL: And from a performance perspective, it's a bit of a see-saw in that fixtures are a lot faster because they get inserted once at the beginning of your test run. So, a SQL execution at the beginning of a test run and then every test after that is just doing its thing: maybe creating a record inside of a transaction, maybe not creating any records at all. And so, it can be a lot faster as opposed to using FactoryBot where you're creating records one at a time. Every create call in a test is a round trip to the database, and those are expensive. +So, FactoryBot tests tend to be more expensive than those that rely on fixtures. But you have the advantage of more control over what data is present and sort of more locality because you can see what has been created at the test level. But then, if you decide, hey, this is a test where I can just create records in memory, that's probably the best of all worlds in that you don't need anything created ahead with fixtures. You also don't need anything to be inserted using FactoryBot because you don't even need the database for this test. +STEPHANIE: I'm curious, is that the assumption that you start with, that you don't need a persisted object when you're writing a basic unit test? +JOËL: I think I will as much as possible try not to need to persist and only if necessary use persist records. There are strategies with FactoryBot that will allow you to also, like, build stubbed or just build in memory. So, there's a few different variations that will, like, partially do things for you. But oftentimes, you can just new up an object, and that's what I will often start with. +In many cases, I will already know what I'm trying to do. And so, I might not go through the steps of, oh, new up an object. Oh no, I'm getting a I can't do the thing I need to do. Now, I need to write to the database. So, if I'm testing, let's say, an ActiveRecord scope that's filtering down a series of records, I know that's a wrapper around a database query. I'm not going to start by newing up some records and then sort of accidentally discovering, oh yeah, it does write to the database because that was pretty clear to me from the beginning. +STEPHANIE: Yeah. Like, you have your mental shortcuts that you do. I guess I asked that question because I wonder if that is a good heuristic to share with maybe developers who are trying to figure out, like, should they create persisted records or, you know, use just regular instance in memory or, I don't know, even [laughs] use, like, a double [laughs]? +JOËL: Yeah, I've done that quite a bit as well. I would say maybe my heuristic is, is the method under test going to need to talk to the database? And, you know, I may or may not know that upfront because if I'm test driving, I'm writing the test first. So, sometimes, maybe I don't know, and I'll start with something in memory and then realize, oh, you know, I do need to talk to the database for this. And this is for unit tests, in particular. +For something more like an integration test or a system test that might require data in the database, system tests almost always do. You're not interacting with instances in memory when you're writing a system test, right? You're saying, "Given the database state is this when I visit this URL and do these things, this page reacts in such and such a way." So, system tests always write to the database to start with. So, maybe that's my heuristic there. But for unit tests, maybe think a little bit about does your method actually need to talk to the database? And maybe even almost give yourself a challenge. Can I get away with not talking to the database here? +STEPHANIE: Yeah, I like that because I've certainly seen a lot of unit tests that are integration tests in disguise [laughs]. +JOËL: Isn't that the truth? So, we kind of opened up this conversation with the idea of there are different ways to manage your database in terms of, do you clean or not clean before a test run? Where did you end up on this particular project? +STEPHANIE: So, I ended up with a currently open PR to remove the need to truncate the database on each run of the test suite and just stick with the transaction for each example strategy. And I do think that this will work for us as long as we decide we don't want to introduce something like fixtures, even though that is actually also a discussion that's still in the works. But I'm hoping with this change, like, right now, I can help people start running faster tests [chuckles]. +And should we ever introduce fixtures down the line, then we can revisit that. But it's one of those things that I think we've been living with this for too long [laughs]. And no one ever questioned, like, "Oh, why are we doing this?" Or, you know, maybe that was a need, however many years ago, that just got overlooked. And as a person new to the project, I saw it, and now I'm doing something about it [laughs]. +JOËL: I love that new person energy on a project and like, "Hey, we've got this config thing. Did you know that we didn't need this as of Rails 6?" And they're like, "Oh, I didn't even realize that." And then you add that, and it just moves you into the future a little bit. +So, if I understand the proposed change, then you're removing the truncation strategy, but you're still going to be in a situation where you have a clean database before each test because you're wrapping tests in transactions, which I think is the default Rails behavior. +STEPHANIE: Yeah, that's where we're at right now. So, yeah, I'm not sure, like, how things came to be this way, but it seemed obvious to me that we were kind of doing this whole extra step that wasn't really necessary, at least at this point in time. Because, at least to my knowledge [laughs], there's no data being seeded in any other place. +JOËL: It's interesting, right? When you have a situation where this was sort of a very popular practice for a long time, a lot of guides mentioned that. And so, even though Rails has made changes that mean that this is no longer necessary, there's still a long tail of apps that will still have this that may be upgraded later, and then didn't drop this, or maybe even new apps that got created but didn't quite realize that the guide they were following was outdated, or that a best practice that was in their head was also outdated. And so, you have a lot of apps that will still have these sort of, like, relics of the past. And you're like, "Oh yeah, that's how we used to do things." +STEPHANIE: So yeah, thanks, Joël, for going on this journey with me in terms of, you know, reassessing my assumptions about test databases. I'm wondering, like, if this is common, how other people, you know, approach what they expect from the test database, whether it be totally clean or have, you know, any required data for common flows and use cases of your system. But it does seem that little in between of, like, maybe it is using transactions to reset for each example, but then there's also some persistence that's happening somewhere else that could be a little tricky to manage. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + Tailwind CSS, debugging, thinking cap, work-life balance, Rails testing methodologies, database truncation, transactional fixtures, software development practices, continuous learning, development tools, test database management, professional communication, remote work challenges. + + Joël shares his recent project challenge with Tailwind CSS, where classes weren't generating as expected due to the dynamic nature of Tailwind's CSS generation and pruning. Stephanie introduces a personal productivity tool, a "thinking cap," to signal her thought process during meetings, which also serves as a physical boundary to separate work from personal life.

+ +

The conversation shifts to testing methodologies within Rails applications, leading to an exploration of testing philosophies, including developers' assumptions about database cleanliness and their impact on writing tests.

+ + + +

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: I'm working on a new project, and this is a project that uses Tailwind CSS for its styling. And I ran into a bit of an annoying problem with it just getting started, where I was making changes and adding classes. And they were not changing the things I thought they would change in the UI. And so, I looked up the class in the documentation, and then I realized, oh, we're on an older version of the Tailwind Rails gem. So, maybe we're using...like, I'm looking at the most recent docs for Tailwind, but it's not relevant for the version I'm using. Turned out that was not the problem.

+ +

Then I decided to use the Web Inspector and actually look at the element in my browser to see is it being overwritten somehow by something else? And the class is there in the element, but when I look at the CSS panel, it does not show up there at all or having any effects. And that got me scratching my head. And then, eventually, I figured it out, and it's a bit of a facepalm moment [laughs].

+ +

STEPHANIE: Oh, okay.

+ +

JOËL: Because Tailwind has to, effectively, generate all of these, and it will sort of generate and prune the things you don't need and all of that. They're not all, like, statically present. And so, if I was using a class that no one else in the app had used yet, it hadn't gotten generated. And so, it's just not there. There's a class on the element, but there's no CSS definition tied to it, so the class does nothing.

+ +

What you need to do is there's a rake task or some sort of task that you can run that will generate things. There's also, I believe, a watcher that you can run, some sort of, like, server that will auto-generate these for you in dev mode. I did not have that set up. So, I was not seeing that new class have any effect. Once I ran the task to generate things, sure enough, it worked. And Tailwind works exactly how the docs say they do. But that was a couple of hours of my life that I'm not getting back.

+ +

STEPHANIE: Yeah, that's rough. Sorry to hear. I've also definitely gone down that route of like, oh, it's not in the docs. The docs are wrong. Like, do they even know what they're talking about? I'm going to fix this for everyone. And similarly have been humbled by a facepalm solution when I'm like, oh, did I yarn [laughs]? No, I didn't [laughs].

+ +

JOËL: Uh-huh. I'm curious, for you, when you have sort of moments where it's like the library is not behaving the way you think it is, is your default to blame yourself, or is it to blame the library?

+ +

STEPHANIE: [laughs]. Oh, good question.

+ +

JOËL: And the follow-up to that is, are you generally correct?

+ +

STEPHANIE: Yeah. Yep, yep, yep. Hmm, I will say I externalize the blame, but I will try to at least do, like, the basic troubleshooting steps of restarting my server [laughter], and then if...that's as far as I'll go. And then, I'll be like, oh, like, something must be wrong, you know, with this library, and I turn to Google. And if I'm not finding any fruitful results, again, you know, one path could be, oh, maybe I'm not Googling correctly, but the other path could be, maybe I've discovered something that no one else has before.

+ +

But to your follow-up question, I'm almost, like, always wrong [laughter]. I'm still waiting for the day when I, like, discover something that is an actual real problem, and I can go and open an issue [chuckles] and, hopefully, be validated by the library author.

+ +

JOËL: I think part of what I heard is that your debugging strategy is basic, but it's not as basic as Joël's because you remember to restart the server [chuckles].

+ +

STEPHANIE: We all have our days [laughter].

+ +

JOËL: Next time. So, Stephanie, what is new in your world?

+ +

STEPHANIE: I'm very excited to share this with you. And I recognize that this is an audio medium, so I will also describe the thing I'm about to show you [laughs].

+ +

JOËL: Oh, this is an object.

+ +

STEPHANIE: It is an object. I got a hat [laughs].

+ +

JOËL: Okay.

+ +

STEPHANIE: I'm going to put it on now. It's a cap that says "Thinking" on it [laughs] in, like, you know, fun sans serif font with a little bit of edge because the thinking is kind of slanted. So, it is designy, if you will. It's my thinking cap. And I've been wearing it at work all week, and I love it.

+ +

As a person who, in meetings and, you know, when I talk to people, I have to process before I respond a lot of the time, but that has been interpreted as, you know, maybe me not having anything to say or, you know, people aren't sure if I'm, you know, still thinking or if it's time to move on. And sometimes I [chuckles], you know, take a long time. My brain is just spinning. I think another funny hat design would be, like, the beach ball, macOS beach ball.

+ +

JOËL: That would be hilarious.

+ +

STEPHANIE: Yeah. Maybe I need to, like, stitch that on the back of this thinking cap. Anyway, I've been wearing it at work in meetings. And then, when I'm just silently processing, I'll just point to my hat and signal to everyone what's [laughs] going on. And it's also been really great for the end of my work day because then I take off the hat, and because I've taken it off, that's, like, my signal, you know, I have this physical totem that, like, now I'm done thinking about work, and that has been working.

+ +

JOËL: Oh, I love that.

+ +

STEPHANIE: Yeah, that's been working surprisingly well to kind of create a bit more of a boundary to separate work thoughts and life thoughts.

+ +

JOËL: Because you are working from home and so that boundary between professional life and personal life can get a little bit blurry.

+ +

STEPHANIE: Yeah. I will say I take it off and throw it on the floor kind of dramatically [laughter] at the end of my work day. So, that's what's new. It had a positive impact on my work-life balance. And yeah, if anyone else has the problem of people being confused about whether you're still thinking or not, recommend looking into a physical thinking cap.

+ +

JOËL: So, you are speaking at RailsConf this spring in Detroit. Do you plan to bring the thinking cap to the conference?

+ +

STEPHANIE: Oh yeah, absolutely. That's a great idea. If anyone else is going to RailsConf, find me in my thinking cap [laughs].

+ +

JOËL: So, this is how people can recognize Bikeshed co-host Stephanie Minn. See someone walking around with a thinking cap.

+ +

STEPHANIE: Ooh. thinkingbot?

+ +

JOËL: Ooh.

+ +

STEPHANIE: Have I just designed new thoughtbot swag [laughter]? We'll see if this catches on.

+ +

JOËL: So, we were talking recently, and you'd mentioned that you were facing some really interesting dilemmas when it came to writing tests and particularly how tests interact with your test database.

+ +

STEPHANIE: Yeah. So, I recently, a few weeks ago, joined a new client project and, you know, one of the first things that I do is start to run those tests [laughs] in their codebase to get a sense of what's what. And I noticed that they were taking quite a long time to get set up before I even saw any progress in terms of successes or failures. So, I was kind of curious what was going on before the examples were even run.

+ +

And when I tailed the logs for the tests, I noticed that every time that you were running the test suite, it would truncate all of the tables in the test database. And that was a surprise to me because that's not a thing that I had really seen before. And so, basically, what happens is all of the data in the test database gets deleted using this truncation strategy. And this is one way of ensuring a clean slate when you run your tests.

+ +

JOËL: Was this happening once at the beginning of the test suite or before every test?

+ +

STEPHANIE: It was good that it was only running once before the test suite, but since, you know, in my local development, I'm running, like, a file at a time or sometimes even just targeting a specific line, this would happen on every run in that situation and was just adding a little bit of extra time to that feedback loop in terms of just making sure your code was working if that's part of your workflow.

+ +

JOËL: Do you know what version of Rails this project was in? Because I know this was popular in some older versions of Rails as a strategy.

+ +

STEPHANIE: Yeah. So, it is Rails 7 now, recently upgraded to Rails 7. It was on Rails 6 for a little while.

+ +

JOËL: Very nice. I want to say that truncation is generally not necessary as of Rails...I forget if it's 5 or 6. But back in the day, specifically for what are now called system tests, the sort of, like, Capybara UI-driven browser tests, you had, effectively, like, two threads that were trying to access the database. And so, you couldn't have your test data wrapped in a transaction the way you would for unit tests because then the UI thread would not have access to the data that had been created in a transaction just for the test thread. And so, people would use tools like Database Cleaner to use a truncation strategy to clear out everything between tests to allow a sort of clean slate for these UI-driven feature specs.

+ +

And then, I want to say it's Rails 5, it may have been Rails 6 when system tests were added. And one of the big things there was that they now could, like, share data in a transaction instead of having to do two separate threads and one didn't have access to it. And all of a sudden, now you could go back to transactional fixtures the way that you could with unit tests and really take advantage of something that's really nice and built into Rails.

+ +

STEPHANIE: That's cool. I didn't know that about system tests and that kind of shift happening. I do think that, in this case, it was one of those situations where, in the past, the database truncation, in this case, particular using the Database Cleaner gem was necessary, and that just never got reassessed as the years went by.

+ +

JOËL: That's one of the classic things, right? When you upgrade a Rails app over multiple versions, and sometimes you sort of get a new feature that comes in for free with the new version, and you might not be aware of it. And some of the patterns in the app just kind of keep going. And you don't realize, hey, this part of the app could actually be modernized.

+ +

STEPHANIE: So, another interesting thing about this testing situation is that I learned that, you know, if you ran these tests, you would experience this truncation strategy. But the engineering team had also kind of played around with having a different test setup that didn't clean the database at all unless you opted into it.

+ +

JOËL: So, your test database would just...each test would just keep writing to the database, but they're not wrapped in transactions. Or they are wrapped in transactions, but you may or may not have some additional data.

+ +

STEPHANIE: The latter. So, I think they were also using the transaction strategy there. But, you know, there are some reasons that you would still have some data persisted across test runs. I had actually learned that the use transactional fixtures config for RSpec doesn't roll back any data that might have been created in a before context hook.

+ +

JOËL: Yep, or a before all. Yeah, the transaction wraps the actual example, but not anything that happens outside of it.

+ +

STEPHANIE: Yeah, I thought that was an interesting little gotcha. So, you know, now we had these, like, two different ways to run tests. And I was chatting with a client developer about how that came to be. And we then got into an interesting conversation about, like, whether or not we each expect a clean database in the first place when we write our tests or when we run our tests, and that was an area that we disagreed.

+ +

And that was cool because I had not really, like, thought about like, oh, how did I even arrive at this assumption that my database would always be clean? I think it was just, you know, from experience having only worked in Rails apps of a certain age that really got onto the Database [laughs] Cleaner train. But it was interesting because I think that is a really big assumption to make that shapes how you then approach writing tests.

+ +

JOËL: And there's kind of a couple of variations on that. I think the sort of base camp approach of writing Rails with fixtures, you just sort of have, for the most part, an existing set of data that's there that you maybe layer on a few extra things on. But there's base level; you just expect a bunch of data to exist in your test database. So, it's almost going off the opposite assumption, where you can always assume that certain things are already there. Then there's the other extreme of, like, you always assume that it's empty. And it sounds like maybe there's a position in the middle of, like, you never know. There may be something. There may not be something, you know, spin the wheel.

+ +

STEPHANIE: Yeah. I guess I was surprised that it, you know, that was just a question that I never really asked myself prior to this conversation, but it could feel like different testing philosophies. But yeah, I was very interested in this, you know, kind of opinion that was a little bit different from mine about if you assume that your database, your test database, is not clean, that kind of perhaps nudges you in the direction of writing tests that are less coupled to the database if they don't need to be.

+ +

JOËL: What does coupling to the database mean in this situation?

+ +

STEPHANIE: So, I'm thinking about Rails tests that might be asserting on a change in database behavior, so the change matcher in RSpec is one that I see maybe sometimes used when it doesn't need to be used. And we're expecting, like, account to have changed the count of the number of records on it for a model have changed after doing some work, right?

+ +

JOËL: And the change matcher from RSpec is one that allows you to not care whether there are existing records or not. It sort of insulates you from that.

+ +

STEPHANIE: That's true. Though I guess I was thinking almost like, what if there was some return value to assert on instead? And would that kind of help you separate some side effects from methods that might be doing too much? And kind of when I start to see tests that have both or are asserting on something being returned, and then also something happening, that's one way of, like, figuring out what kind of coupling is going on inside this test.

+ +

JOËL: It's the classic command-query separation principle from object-oriented design.

+ +

STEPHANIE: I think another one that came to mind, another example, especially when you're talking about system tests, is when you might be using Capybara and you end up...maybe you're going through a flow that creates a record. But from the user perspective, they don't actually know what's going on at the database level. But you could assert that something was created, right? But it might be more realistic at that level of abstraction to be asserting some kind of visual element that had happened as a result of the flow that you're testing.

+ +

JOËL: Yeah. I would, in fact, go so far as to say that asserting on the state of your database in a system test is an anti-pattern. System tests are sort of, by design, meant to be all about user behavior trying to mimic the experience of a user. And a user of a website is not going to be able to...you hope they're not able to SSH into [chuckles] your database and check the records that have been created. If they can, you've got another problem.

+ +

STEPHANIE: I wonder if you could take this idea to the extreme, though. And do you think there is a world where you don't really test database-level concerns at all if you kind of believe this idea that it doesn't really matter what the state of it should be?

+ +

JOËL: I guess there's a few different things on, like, what it matters about the state of it because you are asserting on its state sort of indirectly in a sort of higher level integration test. You're asserting that you see certain things show up on the screen in a system test. And maybe you want to say, "I do certain tasks, and then I expect to see three items in an unordered list." Those three items probably come from the database, although, you know, you could have it where they come from an API or something like that.

+ +

So, the database is an implementation level. But if you had random data in your database, you might, in some tests, have four items in the list, some tests have five. And that's just going to be a flaky test, and that's going to be incredibly painful. So, while you're not asserting on the database, having control over it during sort of test setup, I think, does impact the way you assert.

+ +

STEPHANIE: Yeah, that makes sense. I was suddenly just thinking about, like, how that exercise can actually tell you perhaps, like, when it is important to, in your test setup, be persisting real records as opposed to how much you can get away with, like, not interacting with it because, like, you aren't testing at that integration level.

+ +

JOËL: That brings up a good point because a lot of tests probably you might need models, but you might not need persisted models to interact with them, if you're testing a method on a model that just does things based off its internal state and not any of the ActiveRecord database queries, or if you have some other service or something that consumes a model that doesn't necessarily need to query.

+ +

There's a classic blog post on the thoughtbot blog about when you should not reuse. There's a classic blog post on the thoughtbot blog about when not to use FactoryBot. And, you know, we are the makers of FactoryBot. It helps set up records in your database for testing. And people love to use it all the time. And we wrote an article about why, in many cases, you don't need to create something into the database. All you need is just something in memory, and that's going to be much faster than using FactoryBot because talking to the database is expensive.

+ +

STEPHANIE: Yeah, and I think we can see that in the shift from even, like, fixtures to factories as well, where test data was only persisted as needed and as needed in individual tests, rather than seeding it and having all of those records your entire test run. And it's cool to see that continuing, you know, that idea further of like, okay, now we have this new, popular tool that reduce some of that. But also, in most cases, we still don't need...it's still too much.

+ +

JOËL: And from a performance perspective, it's a bit of a see-saw in that fixtures are a lot faster because they get inserted once at the beginning of your test run. So, a SQL execution at the beginning of a test run and then every test after that is just doing its thing: maybe creating a record inside of a transaction, maybe not creating any records at all. And so, it can be a lot faster as opposed to using FactoryBot where you're creating records one at a time. Every create call in a test is a round trip to the database, and those are expensive.

+ +

So, FactoryBot tests tend to be more expensive than those that rely on fixtures. But you have the advantage of more control over what data is present and sort of more locality because you can see what has been created at the test level. But then, if you decide, hey, this is a test where I can just create records in memory, that's probably the best of all worlds in that you don't need anything created ahead with fixtures. You also don't need anything to be inserted using FactoryBot because you don't even need the database for this test.

+ +

STEPHANIE: I'm curious, is that the assumption that you start with, that you don't need a persisted object when you're writing a basic unit test?

+ +

JOËL: I think I will as much as possible try not to need to persist and only if necessary use persist records. There are strategies with FactoryBot that will allow you to also, like, build stubbed or just build in memory. So, there's a few different variations that will, like, partially do things for you. But oftentimes, you can just new up an object, and that's what I will often start with.

+ +

In many cases, I will already know what I'm trying to do. And so, I might not go through the steps of, oh, new up an object. Oh no, I'm getting a I can't do the thing I need to do. Now, I need to write to the database. So, if I'm testing, let's say, an ActiveRecord scope that's filtering down a series of records, I know that's a wrapper around a database query. I'm not going to start by newing up some records and then sort of accidentally discovering, oh yeah, it does write to the database because that was pretty clear to me from the beginning.

+ +

STEPHANIE: Yeah. Like, you have your mental shortcuts that you do. I guess I asked that question because I wonder if that is a good heuristic to share with maybe developers who are trying to figure out, like, should they create persisted records or, you know, use just regular instance in memory or, I don't know, even [laughs] use, like, a double [laughs]?

+ +

JOËL: Yeah, I've done that quite a bit as well. I would say maybe my heuristic is, is the method under test going to need to talk to the database? And, you know, I may or may not know that upfront because if I'm test driving, I'm writing the test first. So, sometimes, maybe I don't know, and I'll start with something in memory and then realize, oh, you know, I do need to talk to the database for this. And this is for unit tests, in particular.

+ +

For something more like an integration test or a system test that might require data in the database, system tests almost always do. You're not interacting with instances in memory when you're writing a system test, right? You're saying, "Given the database state is this when I visit this URL and do these things, this page reacts in such and such a way." So, system tests always write to the database to start with. So, maybe that's my heuristic there. But for unit tests, maybe think a little bit about does your method actually need to talk to the database? And maybe even almost give yourself a challenge. Can I get away with not talking to the database here?

+ +

STEPHANIE: Yeah, I like that because I've certainly seen a lot of unit tests that are integration tests in disguise [laughs].

+ +

JOËL: Isn't that the truth? So, we kind of opened up this conversation with the idea of there are different ways to manage your database in terms of, do you clean or not clean before a test run? Where did you end up on this particular project?

+ +

STEPHANIE: So, I ended up with a currently open PR to remove the need to truncate the database on each run of the test suite and just stick with the transaction for each example strategy. And I do think that this will work for us as long as we decide we don't want to introduce something like fixtures, even though that is actually also a discussion that's still in the works. But I'm hoping with this change, like, right now, I can help people start running faster tests [chuckles].

+ +

And should we ever introduce fixtures down the line, then we can revisit that. But it's one of those things that I think we've been living with this for too long [laughs]. And no one ever questioned, like, "Oh, why are we doing this?" Or, you know, maybe that was a need, however many years ago, that just got overlooked. And as a person new to the project, I saw it, and now I'm doing something about it [laughs].

+ +

JOËL: I love that new person energy on a project and like, "Hey, we've got this config thing. Did you know that we didn't need this as of Rails 6?" And they're like, "Oh, I didn't even realize that." And then you add that, and it just moves you into the future a little bit.

+ +

So, if I understand the proposed change, then you're removing the truncation strategy, but you're still going to be in a situation where you have a clean database before each test because you're wrapping tests in transactions, which I think is the default Rails behavior.

+ +

STEPHANIE: Yeah, that's where we're at right now. So, yeah, I'm not sure, like, how things came to be this way, but it seemed obvious to me that we were kind of doing this whole extra step that wasn't really necessary, at least at this point in time. Because, at least to my knowledge [laughs], there's no data being seeded in any other place.

+ +

JOËL: It's interesting, right? When you have a situation where this was sort of a very popular practice for a long time, a lot of guides mentioned that. And so, even though Rails has made changes that mean that this is no longer necessary, there's still a long tail of apps that will still have this that may be upgraded later, and then didn't drop this, or maybe even new apps that got created but didn't quite realize that the guide they were following was outdated, or that a best practice that was in their head was also outdated. And so, you have a lot of apps that will still have these sort of, like, relics of the past. And you're like, "Oh yeah, that's how we used to do things."

+ +

STEPHANIE: So yeah, thanks, Joël, for going on this journey with me in terms of, you know, reassessing my assumptions about test databases. I'm wondering, like, if this is common, how other people, you know, approach what they expect from the test database, whether it be totally clean or have, you know, any required data for common flows and use cases of your system. But it does seem that little in between of, like, maybe it is using transactions to reset for each example, but then there's also some persistence that's happening somewhere else that could be a little tricky to manage.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël shares his recent project challenge with Tailwind CSS, where classes weren't generating as expected due to the dynamic nature of Tailwind's CSS generation and pruning. Stephanie introduces a personal productivity tool, a "thinking cap," to signal her thought process during meetings, which also serves as a physical boundary to separate work from personal life.

+ +

The conversation shifts to testing methodologies within Rails applications, leading to an exploration of testing philosophies, including developers' assumptions about database cleanliness and their impact on writing tests.

+ + + +

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: I'm working on a new project, and this is a project that uses Tailwind CSS for its styling. And I ran into a bit of an annoying problem with it just getting started, where I was making changes and adding classes. And they were not changing the things I thought they would change in the UI. And so, I looked up the class in the documentation, and then I realized, oh, we're on an older version of the Tailwind Rails gem. So, maybe we're using...like, I'm looking at the most recent docs for Tailwind, but it's not relevant for the version I'm using. Turned out that was not the problem.

+ +

Then I decided to use the Web Inspector and actually look at the element in my browser to see is it being overwritten somehow by something else? And the class is there in the element, but when I look at the CSS panel, it does not show up there at all or having any effects. And that got me scratching my head. And then, eventually, I figured it out, and it's a bit of a facepalm moment [laughs].

+ +

STEPHANIE: Oh, okay.

+ +

JOËL: Because Tailwind has to, effectively, generate all of these, and it will sort of generate and prune the things you don't need and all of that. They're not all, like, statically present. And so, if I was using a class that no one else in the app had used yet, it hadn't gotten generated. And so, it's just not there. There's a class on the element, but there's no CSS definition tied to it, so the class does nothing.

+ +

What you need to do is there's a rake task or some sort of task that you can run that will generate things. There's also, I believe, a watcher that you can run, some sort of, like, server that will auto-generate these for you in dev mode. I did not have that set up. So, I was not seeing that new class have any effect. Once I ran the task to generate things, sure enough, it worked. And Tailwind works exactly how the docs say they do. But that was a couple of hours of my life that I'm not getting back.

+ +

STEPHANIE: Yeah, that's rough. Sorry to hear. I've also definitely gone down that route of like, oh, it's not in the docs. The docs are wrong. Like, do they even know what they're talking about? I'm going to fix this for everyone. And similarly have been humbled by a facepalm solution when I'm like, oh, did I yarn [laughs]? No, I didn't [laughs].

+ +

JOËL: Uh-huh. I'm curious, for you, when you have sort of moments where it's like the library is not behaving the way you think it is, is your default to blame yourself, or is it to blame the library?

+ +

STEPHANIE: [laughs]. Oh, good question.

+ +

JOËL: And the follow-up to that is, are you generally correct?

+ +

STEPHANIE: Yeah. Yep, yep, yep. Hmm, I will say I externalize the blame, but I will try to at least do, like, the basic troubleshooting steps of restarting my server [laughter], and then if...that's as far as I'll go. And then, I'll be like, oh, like, something must be wrong, you know, with this library, and I turn to Google. And if I'm not finding any fruitful results, again, you know, one path could be, oh, maybe I'm not Googling correctly, but the other path could be, maybe I've discovered something that no one else has before.

+ +

But to your follow-up question, I'm almost, like, always wrong [laughter]. I'm still waiting for the day when I, like, discover something that is an actual real problem, and I can go and open an issue [chuckles] and, hopefully, be validated by the library author.

+ +

JOËL: I think part of what I heard is that your debugging strategy is basic, but it's not as basic as Joël's because you remember to restart the server [chuckles].

+ +

STEPHANIE: We all have our days [laughter].

+ +

JOËL: Next time. So, Stephanie, what is new in your world?

+ +

STEPHANIE: I'm very excited to share this with you. And I recognize that this is an audio medium, so I will also describe the thing I'm about to show you [laughs].

+ +

JOËL: Oh, this is an object.

+ +

STEPHANIE: It is an object. I got a hat [laughs].

+ +

JOËL: Okay.

+ +

STEPHANIE: I'm going to put it on now. It's a cap that says "Thinking" on it [laughs] in, like, you know, fun sans serif font with a little bit of edge because the thinking is kind of slanted. So, it is designy, if you will. It's my thinking cap. And I've been wearing it at work all week, and I love it.

+ +

As a person who, in meetings and, you know, when I talk to people, I have to process before I respond a lot of the time, but that has been interpreted as, you know, maybe me not having anything to say or, you know, people aren't sure if I'm, you know, still thinking or if it's time to move on. And sometimes I [chuckles], you know, take a long time. My brain is just spinning. I think another funny hat design would be, like, the beach ball, macOS beach ball.

+ +

JOËL: That would be hilarious.

+ +

STEPHANIE: Yeah. Maybe I need to, like, stitch that on the back of this thinking cap. Anyway, I've been wearing it at work in meetings. And then, when I'm just silently processing, I'll just point to my hat and signal to everyone what's [laughs] going on. And it's also been really great for the end of my work day because then I take off the hat, and because I've taken it off, that's, like, my signal, you know, I have this physical totem that, like, now I'm done thinking about work, and that has been working.

+ +

JOËL: Oh, I love that.

+ +

STEPHANIE: Yeah, that's been working surprisingly well to kind of create a bit more of a boundary to separate work thoughts and life thoughts.

+ +

JOËL: Because you are working from home and so that boundary between professional life and personal life can get a little bit blurry.

+ +

STEPHANIE: Yeah. I will say I take it off and throw it on the floor kind of dramatically [laughter] at the end of my work day. So, that's what's new. It had a positive impact on my work-life balance. And yeah, if anyone else has the problem of people being confused about whether you're still thinking or not, recommend looking into a physical thinking cap.

+ +

JOËL: So, you are speaking at RailsConf this spring in Detroit. Do you plan to bring the thinking cap to the conference?

+ +

STEPHANIE: Oh yeah, absolutely. That's a great idea. If anyone else is going to RailsConf, find me in my thinking cap [laughs].

+ +

JOËL: So, this is how people can recognize Bikeshed co-host Stephanie Minn. See someone walking around with a thinking cap.

+ +

STEPHANIE: Ooh. thinkingbot?

+ +

JOËL: Ooh.

+ +

STEPHANIE: Have I just designed new thoughtbot swag [laughter]? We'll see if this catches on.

+ +

JOËL: So, we were talking recently, and you'd mentioned that you were facing some really interesting dilemmas when it came to writing tests and particularly how tests interact with your test database.

+ +

STEPHANIE: Yeah. So, I recently, a few weeks ago, joined a new client project and, you know, one of the first things that I do is start to run those tests [laughs] in their codebase to get a sense of what's what. And I noticed that they were taking quite a long time to get set up before I even saw any progress in terms of successes or failures. So, I was kind of curious what was going on before the examples were even run.

+ +

And when I tailed the logs for the tests, I noticed that every time that you were running the test suite, it would truncate all of the tables in the test database. And that was a surprise to me because that's not a thing that I had really seen before. And so, basically, what happens is all of the data in the test database gets deleted using this truncation strategy. And this is one way of ensuring a clean slate when you run your tests.

+ +

JOËL: Was this happening once at the beginning of the test suite or before every test?

+ +

STEPHANIE: It was good that it was only running once before the test suite, but since, you know, in my local development, I'm running, like, a file at a time or sometimes even just targeting a specific line, this would happen on every run in that situation and was just adding a little bit of extra time to that feedback loop in terms of just making sure your code was working if that's part of your workflow.

+ +

JOËL: Do you know what version of Rails this project was in? Because I know this was popular in some older versions of Rails as a strategy.

+ +

STEPHANIE: Yeah. So, it is Rails 7 now, recently upgraded to Rails 7. It was on Rails 6 for a little while.

+ +

JOËL: Very nice. I want to say that truncation is generally not necessary as of Rails...I forget if it's 5 or 6. But back in the day, specifically for what are now called system tests, the sort of, like, Capybara UI-driven browser tests, you had, effectively, like, two threads that were trying to access the database. And so, you couldn't have your test data wrapped in a transaction the way you would for unit tests because then the UI thread would not have access to the data that had been created in a transaction just for the test thread. And so, people would use tools like Database Cleaner to use a truncation strategy to clear out everything between tests to allow a sort of clean slate for these UI-driven feature specs.

+ +

And then, I want to say it's Rails 5, it may have been Rails 6 when system tests were added. And one of the big things there was that they now could, like, share data in a transaction instead of having to do two separate threads and one didn't have access to it. And all of a sudden, now you could go back to transactional fixtures the way that you could with unit tests and really take advantage of something that's really nice and built into Rails.

+ +

STEPHANIE: That's cool. I didn't know that about system tests and that kind of shift happening. I do think that, in this case, it was one of those situations where, in the past, the database truncation, in this case, particular using the Database Cleaner gem was necessary, and that just never got reassessed as the years went by.

+ +

JOËL: That's one of the classic things, right? When you upgrade a Rails app over multiple versions, and sometimes you sort of get a new feature that comes in for free with the new version, and you might not be aware of it. And some of the patterns in the app just kind of keep going. And you don't realize, hey, this part of the app could actually be modernized.

+ +

STEPHANIE: So, another interesting thing about this testing situation is that I learned that, you know, if you ran these tests, you would experience this truncation strategy. But the engineering team had also kind of played around with having a different test setup that didn't clean the database at all unless you opted into it.

+ +

JOËL: So, your test database would just...each test would just keep writing to the database, but they're not wrapped in transactions. Or they are wrapped in transactions, but you may or may not have some additional data.

+ +

STEPHANIE: The latter. So, I think they were also using the transaction strategy there. But, you know, there are some reasons that you would still have some data persisted across test runs. I had actually learned that the use transactional fixtures config for RSpec doesn't roll back any data that might have been created in a before context hook.

+ +

JOËL: Yep, or a before all. Yeah, the transaction wraps the actual example, but not anything that happens outside of it.

+ +

STEPHANIE: Yeah, I thought that was an interesting little gotcha. So, you know, now we had these, like, two different ways to run tests. And I was chatting with a client developer about how that came to be. And we then got into an interesting conversation about, like, whether or not we each expect a clean database in the first place when we write our tests or when we run our tests, and that was an area that we disagreed.

+ +

And that was cool because I had not really, like, thought about like, oh, how did I even arrive at this assumption that my database would always be clean? I think it was just, you know, from experience having only worked in Rails apps of a certain age that really got onto the Database [laughs] Cleaner train. But it was interesting because I think that is a really big assumption to make that shapes how you then approach writing tests.

+ +

JOËL: And there's kind of a couple of variations on that. I think the sort of base camp approach of writing Rails with fixtures, you just sort of have, for the most part, an existing set of data that's there that you maybe layer on a few extra things on. But there's base level; you just expect a bunch of data to exist in your test database. So, it's almost going off the opposite assumption, where you can always assume that certain things are already there. Then there's the other extreme of, like, you always assume that it's empty. And it sounds like maybe there's a position in the middle of, like, you never know. There may be something. There may not be something, you know, spin the wheel.

+ +

STEPHANIE: Yeah. I guess I was surprised that it, you know, that was just a question that I never really asked myself prior to this conversation, but it could feel like different testing philosophies. But yeah, I was very interested in this, you know, kind of opinion that was a little bit different from mine about if you assume that your database, your test database, is not clean, that kind of perhaps nudges you in the direction of writing tests that are less coupled to the database if they don't need to be.

+ +

JOËL: What does coupling to the database mean in this situation?

+ +

STEPHANIE: So, I'm thinking about Rails tests that might be asserting on a change in database behavior, so the change matcher in RSpec is one that I see maybe sometimes used when it doesn't need to be used. And we're expecting, like, account to have changed the count of the number of records on it for a model have changed after doing some work, right?

+ +

JOËL: And the change matcher from RSpec is one that allows you to not care whether there are existing records or not. It sort of insulates you from that.

+ +

STEPHANIE: That's true. Though I guess I was thinking almost like, what if there was some return value to assert on instead? And would that kind of help you separate some side effects from methods that might be doing too much? And kind of when I start to see tests that have both or are asserting on something being returned, and then also something happening, that's one way of, like, figuring out what kind of coupling is going on inside this test.

+ +

JOËL: It's the classic command-query separation principle from object-oriented design.

+ +

STEPHANIE: I think another one that came to mind, another example, especially when you're talking about system tests, is when you might be using Capybara and you end up...maybe you're going through a flow that creates a record. But from the user perspective, they don't actually know what's going on at the database level. But you could assert that something was created, right? But it might be more realistic at that level of abstraction to be asserting some kind of visual element that had happened as a result of the flow that you're testing.

+ +

JOËL: Yeah. I would, in fact, go so far as to say that asserting on the state of your database in a system test is an anti-pattern. System tests are sort of, by design, meant to be all about user behavior trying to mimic the experience of a user. And a user of a website is not going to be able to...you hope they're not able to SSH into [chuckles] your database and check the records that have been created. If they can, you've got another problem.

+ +

STEPHANIE: I wonder if you could take this idea to the extreme, though. And do you think there is a world where you don't really test database-level concerns at all if you kind of believe this idea that it doesn't really matter what the state of it should be?

+ +

JOËL: I guess there's a few different things on, like, what it matters about the state of it because you are asserting on its state sort of indirectly in a sort of higher level integration test. You're asserting that you see certain things show up on the screen in a system test. And maybe you want to say, "I do certain tasks, and then I expect to see three items in an unordered list." Those three items probably come from the database, although, you know, you could have it where they come from an API or something like that.

+ +

So, the database is an implementation level. But if you had random data in your database, you might, in some tests, have four items in the list, some tests have five. And that's just going to be a flaky test, and that's going to be incredibly painful. So, while you're not asserting on the database, having control over it during sort of test setup, I think, does impact the way you assert.

+ +

STEPHANIE: Yeah, that makes sense. I was suddenly just thinking about, like, how that exercise can actually tell you perhaps, like, when it is important to, in your test setup, be persisting real records as opposed to how much you can get away with, like, not interacting with it because, like, you aren't testing at that integration level.

+ +

JOËL: That brings up a good point because a lot of tests probably you might need models, but you might not need persisted models to interact with them, if you're testing a method on a model that just does things based off its internal state and not any of the ActiveRecord database queries, or if you have some other service or something that consumes a model that doesn't necessarily need to query.

+ +

There's a classic blog post on the thoughtbot blog about when you should not reuse. There's a classic blog post on the thoughtbot blog about when not to use FactoryBot. And, you know, we are the makers of FactoryBot. It helps set up records in your database for testing. And people love to use it all the time. And we wrote an article about why, in many cases, you don't need to create something into the database. All you need is just something in memory, and that's going to be much faster than using FactoryBot because talking to the database is expensive.

+ +

STEPHANIE: Yeah, and I think we can see that in the shift from even, like, fixtures to factories as well, where test data was only persisted as needed and as needed in individual tests, rather than seeding it and having all of those records your entire test run. And it's cool to see that continuing, you know, that idea further of like, okay, now we have this new, popular tool that reduce some of that. But also, in most cases, we still don't need...it's still too much.

+ +

JOËL: And from a performance perspective, it's a bit of a see-saw in that fixtures are a lot faster because they get inserted once at the beginning of your test run. So, a SQL execution at the beginning of a test run and then every test after that is just doing its thing: maybe creating a record inside of a transaction, maybe not creating any records at all. And so, it can be a lot faster as opposed to using FactoryBot where you're creating records one at a time. Every create call in a test is a round trip to the database, and those are expensive.

+ +

So, FactoryBot tests tend to be more expensive than those that rely on fixtures. But you have the advantage of more control over what data is present and sort of more locality because you can see what has been created at the test level. But then, if you decide, hey, this is a test where I can just create records in memory, that's probably the best of all worlds in that you don't need anything created ahead with fixtures. You also don't need anything to be inserted using FactoryBot because you don't even need the database for this test.

+ +

STEPHANIE: I'm curious, is that the assumption that you start with, that you don't need a persisted object when you're writing a basic unit test?

+ +

JOËL: I think I will as much as possible try not to need to persist and only if necessary use persist records. There are strategies with FactoryBot that will allow you to also, like, build stubbed or just build in memory. So, there's a few different variations that will, like, partially do things for you. But oftentimes, you can just new up an object, and that's what I will often start with.

+ +

In many cases, I will already know what I'm trying to do. And so, I might not go through the steps of, oh, new up an object. Oh no, I'm getting a I can't do the thing I need to do. Now, I need to write to the database. So, if I'm testing, let's say, an ActiveRecord scope that's filtering down a series of records, I know that's a wrapper around a database query. I'm not going to start by newing up some records and then sort of accidentally discovering, oh yeah, it does write to the database because that was pretty clear to me from the beginning.

+ +

STEPHANIE: Yeah. Like, you have your mental shortcuts that you do. I guess I asked that question because I wonder if that is a good heuristic to share with maybe developers who are trying to figure out, like, should they create persisted records or, you know, use just regular instance in memory or, I don't know, even [laughs] use, like, a double [laughs]?

+ +

JOËL: Yeah, I've done that quite a bit as well. I would say maybe my heuristic is, is the method under test going to need to talk to the database? And, you know, I may or may not know that upfront because if I'm test driving, I'm writing the test first. So, sometimes, maybe I don't know, and I'll start with something in memory and then realize, oh, you know, I do need to talk to the database for this. And this is for unit tests, in particular.

+ +

For something more like an integration test or a system test that might require data in the database, system tests almost always do. You're not interacting with instances in memory when you're writing a system test, right? You're saying, "Given the database state is this when I visit this URL and do these things, this page reacts in such and such a way." So, system tests always write to the database to start with. So, maybe that's my heuristic there. But for unit tests, maybe think a little bit about does your method actually need to talk to the database? And maybe even almost give yourself a challenge. Can I get away with not talking to the database here?

+ +

STEPHANIE: Yeah, I like that because I've certainly seen a lot of unit tests that are integration tests in disguise [laughs].

+ +

JOËL: Isn't that the truth? So, we kind of opened up this conversation with the idea of there are different ways to manage your database in terms of, do you clean or not clean before a test run? Where did you end up on this particular project?

+ +

STEPHANIE: So, I ended up with a currently open PR to remove the need to truncate the database on each run of the test suite and just stick with the transaction for each example strategy. And I do think that this will work for us as long as we decide we don't want to introduce something like fixtures, even though that is actually also a discussion that's still in the works. But I'm hoping with this change, like, right now, I can help people start running faster tests [chuckles].

+ +

And should we ever introduce fixtures down the line, then we can revisit that. But it's one of those things that I think we've been living with this for too long [laughs]. And no one ever questioned, like, "Oh, why are we doing this?" Or, you know, maybe that was a need, however many years ago, that just got overlooked. And as a person new to the project, I saw it, and now I'm doing something about it [laughs].

+ +

JOËL: I love that new person energy on a project and like, "Hey, we've got this config thing. Did you know that we didn't need this as of Rails 6?" And they're like, "Oh, I didn't even realize that." And then you add that, and it just moves you into the future a little bit.

+ +

So, if I understand the proposed change, then you're removing the truncation strategy, but you're still going to be in a situation where you have a clean database before each test because you're wrapping tests in transactions, which I think is the default Rails behavior.

+ +

STEPHANIE: Yeah, that's where we're at right now. So, yeah, I'm not sure, like, how things came to be this way, but it seemed obvious to me that we were kind of doing this whole extra step that wasn't really necessary, at least at this point in time. Because, at least to my knowledge [laughs], there's no data being seeded in any other place.

+ +

JOËL: It's interesting, right? When you have a situation where this was sort of a very popular practice for a long time, a lot of guides mentioned that. And so, even though Rails has made changes that mean that this is no longer necessary, there's still a long tail of apps that will still have this that may be upgraded later, and then didn't drop this, or maybe even new apps that got created but didn't quite realize that the guide they were following was outdated, or that a best practice that was in their head was also outdated. And so, you have a lot of apps that will still have these sort of, like, relics of the past. And you're like, "Oh yeah, that's how we used to do things."

+ +

STEPHANIE: So yeah, thanks, Joël, for going on this journey with me in terms of, you know, reassessing my assumptions about test databases. I'm wondering, like, if this is common, how other people, you know, approach what they expect from the test database, whether it be totally clean or have, you know, any required data for common flows and use cases of your system. But it does seem that little in between of, like, maybe it is using transactions to reset for each example, but then there's also some persistence that's happening somewhere else that could be a little tricky to manage.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Boma5p_e + + ]]> + + Joël Quenneville + Stephanie Minn + + + 419: What's New in Your World? (Extended Edition) + https://bikeshed.thoughtbot.com/419 + a67e8bcd-a762-4394-a9c0-a90288db2f0e + Tue, 19 Mar 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie introduces her ideal setup for enjoying coffee on a bike ride. Joël describes his afternoon tea ritual. Exciting news from the hosts: both have been accepted to speak at RailsConf! Stephanie's presentation, titled "So, Writing Tests Feels Painful. What now?" aims to tackle the issues developers encounter with testing while offering actionable advice to ease these pains. Joël's session will focus on utilizing Turbo to create a Dungeons & Dragons character sheet, combining his passion for gaming with technical expertise. + +Their conversation shifts to artificial intelligence and its potential in code refactoring and other applications, such as enhancing the code review process and solving complex software development problems. Joël shares his venture into combinatorics, illustrating how this mathematical approach helped him efficiently refactor a database query by systematically exploring and testing all potential combinations of query segments. + 37:13 + no + + + Stephanie introduces her ideal setup for enjoying coffee on a bike ride. Joël describes his afternoon tea ritual. Exciting news from the hosts: both have been accepted to speak at RailsConf! Stephanie's presentation, titled "So, Writing Tests Feels Painful. What now?" aims to tackle the issues developers encounter with testing while offering actionable advice to ease these pains. Joël's session will focus on utilizing Turbo to create a Dungeons & Dragons character sheet, combining his passion for gaming with technical expertise. +Their conversation shifts to artificial intelligence and its potential in code refactoring and other applications, such as enhancing the code review process and solving complex software development problems. Joël shares his venture into combinatorics, illustrating how this mathematical approach helped him efficiently refactor a database query by systematically exploring and testing all potential combinations of query segments. +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, today I went out for a coffee on my bike, and I feel like I finally have my perfect, like, on-the-go coffee setup. We have this thoughtbot branded travel mug. So, it's one of the little bits of swag that we got from the company. It's, like, perfectly leak-proof. I'll link the brand in the show notes. But it's perfectly leak-proof, which is great. And on my bike, I have a little stem bag, so it's just, like, a tiny kind of, like, cylindrical bag that sits on the, like, vertical part of my handlebars that connects to the rest of my bag. And it's just, like, the perfect size for a 12-ounce coffee. +And so, I put my little travel mug in there, and I just had a very refreshing morning. And I'd gone out on my bike for a little bit, stopping by for coffee and headed home to work. And I got to drink my coffee during my first meeting. So, it was a wonderful way to start the day. +JOËL: Do you just show up at the coffee shop with your refillable mug and say, "Hey, can you pour some coffee in this?" +STEPHANIE: Yeah. I think a lot of coffee places are really amenable to bringing your own travel mugs. So yeah, it's really nice because I get to use less plastic. And also, you know, when you get a to-go mug, it is not leak-proof, right? It could just slosh all over the place and spill, so not bike-friendly. But yeah, bring your own mug. It's very easy. +JOËL: Excellent. +STEPHANIE: So, Joël, what's new in your world? +JOËL: Also, warm beverages. Who would have thought? It's almost like it's cold in North America or something. I've been really enjoying making myself tea in the afternoons recently. And I've been drinking this brand of tea that is a little bit extra. Every flavor of tea they have comes with a description of how the tea feels. +STEPHANIE: Ooh. +JOËL: I don't know who came up with these, but they're kind of funny. So, one that I particularly enjoy is described as feels like stargazing on an empty beach. +STEPHANIE: Wow. That's very specific. +JOËL: They also give you tasting notes. This one has tastes of candied violet, elderberry, blackberry, and incense. +STEPHANIE: Ooh, that sounds lovely. Are you drinking, like, herbal tea in the afternoon, or do you drink caffeinated tea? +JOËL: I'll do caffeinated tea. I limit myself to one pot of coffee that I brew in the morning, and then, whenever that's done, I switch to tea. Tea I allow myself anything: herbal, black tea; that's fine. +STEPHANIE: Yeah, I can't have too much caffeine in the afternoon either. But I do love an extra tea. I wish I could remember, like, what even was in this tea or what brand it was, but once I had a tea that was a purplish color. But then, when you squeeze some lemon in it, or I guess maybe anything with a bit of acid, it would turn blue. +JOËL: Oh, that's so cool. +STEPHANIE: Yeah, I'll have to find what this tea was [laughs] and update the podcast for any tea lovers out there. But yeah, it was just, like, a little bit of extra whimsy to your regular routine. +JOËL: I love adding a little whimsy to my day, even if it's just seeing a random animated GIF that a coworker has sent or Tuple has some of the, like, reactions you can send if you're pairing with someone. And I don't use those very often, so whenever one of those comes through, and it's like, ship it or yay, that makes me very happy. +STEPHANIE: Agreed. +JOËL: This week is really fun because as we were prepping for this episode, we both realized that there is a lot that's been new in our world recently. And Stephanie, in particular, you've got some pretty big news that recently happened to you. +STEPHANIE: Yeah, it turns out we're making the what's new in your world segment the entire episode today [laughs]. But my news is that I am speaking at RailsConf this year, so that is May 7th through 9th in Detroit. And so, yeah, I haven't spoken at a RailsConf before, only a RubyConf. So, I'm looking forward to it. My talk is called: So, Writing Tests Feels Painful. What now? +JOËL: Wait, is writing tests ever painful [laughs]? +STEPHANIE: Maybe not for you, but for the rest of us [laughs]. +JOËL: No, it absolutely is. I, right before this recording, came from a pairing session where we were scratching our heads on an, like, awkward-to-write test. It happens to all of us. +STEPHANIE: Yeah. So, I was brainstorming topics, and I kind of realized, especially with a lot of our consulting experience, you know, we hear from developers or even maybe, like, engineering managers a lot of themes around like, "Oh, like, development is slowing down because our test suite is such a headache," or "It's really slow. It's really flaky. It's really complicated." And that is a pain point that a lot of tech leaders are also looking to address for their teams. +But I was really questioning this idea that, like, it always had to be some effort to improve the test suite, like, that had to be worked on at some later point or get, like, an initiative together to fix all of these problems, and that it couldn't just be baked into your normal development process, like, on an individual level. I do think it is really easy to feel a lot of pain when trying to write tests and then just be like, ugh, like, I wish someone would fix this, right? Or, you know, just kind of ignore the signals of that pain because you don't know, like, how to manage it yourself. +So, my talk is about when you do feel that pain, really trying to determine if there's anything you can do, even in just, like, the one test file that you're working in to make things a little bit easier for yourself, so it doesn't become this, like, chronic issue that just gets worse and worse. Is there something you could do to maybe reorganize the file as you're working in it to make some conditionals a little bit clearer? +Is there any, like, extra test setup that you're like, "Oh, actually, I don't need this anymore, and I can just start to get rid of it, not just for this one example, but for the rest in this file"? And do yourself a favor a little bit. So yeah, I'm excited to talk about that because I think that's perhaps, like, a skill that we don't focus enough on. +JOËL: Are you going to sort of focus in on the side of things where, like, a classic TDD mantra is that test pain reflects underlying code complexity? So, are you planning to focus on the idea of, oh, if you're feeling test pain, maybe take some time to refactor some of the code that's under test, maybe because there's some tight coupling? Or are you going to lean a little bit more into maybe, like, the Boy Scout rule, you know, 'Leave the campsite cleaner than you found it' for your test files? +STEPHANIE: Ooh, I like that framing. Definitely more of the former. But one thing I've also noticed working with a lot of client teams is that it's not always clear, like, how to refactor. I think a lot of intermediate developers start to feel that pain but don't know what to do about it. They don't know, like, maybe the code smells, or the patterns, or refactoring strategies, and that can certainly be taught. It will probably pull from that. But even if you don't know those skills yet, I'm wondering if there's, like, an opportunity to teach, like, developers at that level to start to reflect on the code and be like, "Hmm, what could I do to make this a little more flexible?" +And they might not know the names of the strategies to, like, extract a class, but just start to get them thinking about it. And then maybe when they come across that vocabulary later, it'll connect a lot easier because they'll have started to think about, you know, their experiences day to day with some of the more conceptual stuff. +JOËL: I really like that because I feel we've probably all heard that idea that test pain, especially when you're test driving, is a sign of maybe some anti-patterns or some code smells in the underlying code that you're testing. But translating that into something actionable and being able to say, "Okay, so my tests are painful. They're telling me something needs to be refactored. I'm looking at this code, and I don't know what to refactor." It's a big jump. It's almost the classic draw two circles; draw the rest of the owl meme. And so, I think bridging that gap is something that is really valuable for our community. +STEPHANIE: Yeah, that's exactly what I hope to do in my talk. So, Joël, you [chuckles] also didn't quite mention that you have big news as well. +JOËL: So, I also got accepted to speak at RailsConf. I'm giving a talk on Building a Dungeons & Dragons Character Sheet Using Turbo. +STEPHANIE: That's really awesome. I'm excited because I want to learn more about Turbo. I want someone else to tell me [laughs] what I can do with it. And as a person with a little bit of Dungeons & Dragons experience, I think a character sheet is kind of the perfect vehicle for that. +JOËL: Building a D&D character sheet has been kind of my go-to project to experiment with a new front-end framework because it's something that's pretty dynamic. And for those who don't know, there's a bunch of fields that you fill in with stats for different attributes that your character has, but then those impact other stats that get rendered. And sometimes there can be a chain two or three long where different numbers kind of combine together. And so, you've got this almost dependency tree of, like, a particular number. +Maybe your skill at acrobatics might depend on a number that you entered in the dexterity field, but it also depends on your proficiency bonus, and maybe also depends on the race that you picked and a few other things. And so, calculating those numbers all of a sudden becomes not quite so simple. And so, I find it's a really fun exercise to build when trying out a new interactive front-end technology. +STEPHANIE: Have you done this with a different implementation or a framework? +JOËL: I've done this, not completely, but I've attempted some parts of a D&D character sheet, I think, with Backbone.js with Ember. I may have done an Angular one at some point in original Angular, so Angular 1. I did this with Elm. Somehow, I skipped React. I don't think I did React to build a D&D character sheet. And now I'm kind of moving a little bit back to the backend. How much can we get done just with Turbo? Or do we need to pull in maybe Stimulus? These are all things that are going to be really fun to demonstrate. +STEPHANIE: Yeah. Speaking of injecting some whimsy earlier, I think it's kind of like just a little more fun than a regular to-do app, you know, or a blog to show how you can build, you know, something that people kind of understand with a different technology. +JOËL: Another really fun thing that I've been toying with this week has been using AI to help me refactor code. And this has been using just sort of a classic chat AI, not a tool like Copilot. And I was dealing with a query that was really slow, and I wanted to restructure it in a different way. And I described to the AI how I wanted it to refactor and explicitly said, "I want this to be the same before and after." And I asked it to do the refactor, and it gave me some pretty disappointing results where it did some, like, a couple of really obvious things that were not that useful. +And I was talking to a colleague about how I was really disappointed. I was thinking, well, AI should be able to do something better than this. And this colleague suggested changing the way I was asking for things and specifically asking for a step-by-step and asking it to prove every step using relational algebra, which is the branch of math that deals with everything that underlies relational databases, so the transformations that you would do where you keep everything the same, but you're saying, "Hey, these equations are all equivalent." And it sure did. It gave me a, like, 10-step process with all these, like, symbols and things. +My relational algebra is not that strong, and so I couldn't totally follow along. But then I asked it to give me a code example, like, show me the SQL at every step of this transformation and at the end. And, you know, it all kind of looked all right. I've not fully tested the final result it gave me to see if it does what it says on the tin. But I'm cautiously optimistic. I think it looks very similar to something that I came up with on my own. And so, I'm somewhat impressed, at least, like, much better than things were in the beginning with that first round. So, I'm really curious to see where I can take this. +STEPHANIE: Yeah, I think that's cool that you were able to prompt it differently and get something more useful. One of the reasons why I personally have been a little bit hesitant to get into the large language models is because I would love to see the AI show its work, essentially, like, tell me a little bit more about how it got from question to answer. And I thought that framing of kind of step-by-step show me code was a really interesting way, even to just, like, get some different results that do the same thing. +But you can kind of evaluate that a little bit more on your own rather than just using that first result that it gave you that was like, eh, like, I don't know if this really did anything for me. So, it would be cool, even if you don't end up using, like, the final one, right? If something along the way also is an improvement from what you started with that would be really interesting. +JOËL: Honestly, I think you kind of want the same thing if you're chatting with an AI chatbot or having a conversation in Slack with a colleague. They're just like, "Hey, can you help me refactor this?" And then a sort of, like, totally different chunk of code. And it's just like, "Trust me, it works." +STEPHANIE: [laughs]. +JOËL: And maybe it does. Maybe you plug it into your codebase and run the tests against it, and the tests are still green. And so, you trust that it works, but you don't really understand where it came from. That doesn't always feel good, even when it comes from a human. So, what I've appreciated with colleagues has been when they've given me a step-by-step. Sometimes, they give me the final product. They just say, "Hey. Try this. Does this work?" Plug it in to the test. It does pass. It's green. Great. "Tell me what black magic you did to get to that." +And then they give me the step-by-step and it's like, oh, that's so good because not only do I get a better understanding of what happens at every step, but now I'm equipped the next time I run into this problem to apply the same technique to figure it out on my own. +STEPHANIE: Yeah. And I liked, also, that relational algebra pro tip, right? It kind of ensures that what you're getting makes sense or is equivalent along the way [laughs]. +JOËL: We think, right? I don't know enough relational algebra to check its work. It is quite possible that it is making some subtle mistakes along the way, or, like, making inferences that it shouldn't be. I'm not going to say I trust that. But I think, specifically, when asking for SQL transformations, prompting it to do so using relational algebra in a step-by-step way seemed to be a way to get it to do something more reliably or at least give more interesting results. +STEPHANIE: Cool. +JOËL: I was interested in trying this out in part because I've been more curious about AI tools recently, and also because we're hoping to do a deeper dive into AI on a Bike Shed episode at some point later, so very much still in the gathering information phase. But this was a really cool experience. So, having an AI refactor a query for me using relational algebra, definitely something that's new in my world this week. +STEPHANIE: Speaking of refactoring and this idea of making improvements to your code and trying to figure out how to get from what you currently have to something new, I have been thinking a lot about how to make code reviews more actionable. And that's because, on my current client project, our team is struggling a little bit with code reviews, especially when you kind of want to give feedback on more of a design change in the code or thinking about some different abstractions. I have found that that is really hard to communicate async and also in a, like, a GitHub code review format where you can really just comment, like, line by line. +And I've found that, you know, when someone is leaving feedback, that's like, "I'm having a hard time reading this. And I'm imagining that we could organize the code a bit differently in these three different layers or abstractions," there's a lot of assumptions there, right [laughs]? That your message is being communicated to the author and that they are able to, like, visualize, or have a mental model for what you're explaining as well. +And then kind of what I've been seeing in this dynamic is, like, not really knowing what to do with that and to kind of just, like, I don't know where to go from here. So, I guess the next step is just to, like, merge it. Is that something you've experienced before or encountered when it comes to feedback? +JOËL: Broader changes are often challenging to explain, especially when they're...sometimes you get so abstract you can just write a quick paragraph. And sometimes it's like, hey, what if we, like, totally change our approach? I've definitely done the thing where I'll just ping someone and say, "Hey, can we talk about this synchronously? Can we get on a call and have a deeper conversation?" +How do you tend to approach if you're not going to hop on a call with someone and, like, have a 20 or 30-minute conversation? How do you approach doing that asynchronously on a pull request? Are you the type of person to put, like, a ton of, like, code blocks, like, "Here's what I was thinking. We could instead have this class and this thing"? And, like, pretty soon, it's, like, a page and a half of text. Or do you have another approach that you like to use? +STEPHANIE: Yeah. And I think that's where it can get really interesting. Because my process is, I'll usually just start commenting and maybe if I'm seeing some things that can be done differently. If it's not just, like, a really obvious change that I could just use English to describe, I'll add a little suggested change. But I also don't want to just rewrite this person's code [laughs] in a code review. +JOËL: That's the challenge, right? +STEPHANIE: Yeah. And I've definitely seen that be done before, too. Once I notice I'm at, like, four plus comments, and then they're not just, like, nitpicks about, like, syntax or something like that, that helps me clue into the idea that there is some kind of bigger change that I might be asking of the author. And I don't want to overwhelm them with, like, individual comments that really are trying to convey something more holistic. +JOËL: Right. I wonder if having a, like, specialized yet more abstract language is useful for these sorts of things where a whole paragraph in English or, you know, a ton of code examples might be a bit much. If you're able to say something like, "Hey, how would you feel about using a strategy pattern approach here instead of, you know, maybe a template object or some custom thing that we've built here?" that allows us to say a lot in a fairly sort of terse way. And it's the thing that you can leave more generically on the PR instead of, like, individually commenting in a bunch of places. And that can start a broader conversation at more of an architecture level. +STEPHANIE: Yes, I really like that. That's a great idea. I would follow that up with, like, I think at the end of the day, there are some conversations that do need to be had synchronously. And so, I like the idea of leaving a comment like that and just kind of giving them resources to learn what a strategy pattern is and then offering support because that's also a way to shorten that feedback loop of trying to communicate an idea. And I like that it's kind of guiding them, but also you're there to add some scaffolding if it ends up being, like, kind of a big ask for them to figure out what to do. +JOËL: There's also oftentimes, I think, a tone thing to manage where, especially if there's a difference in seniority or experience between the two people, it can be very easy for something to come across as an ask or a demand rather than a like, "Hey, let's think about some alternatives here." Or, like, "I have some concerns with your implementation. Let's sort of broadly explore some possible alternatives. Maybe a strategy pattern works." +But the person reading that who wrote the original code might be, like, receiving that as "Your code is bad. You should have done a strategy pattern instead." And that's not the conversation I want to have, right? I want to have a back-and-forth about, "Hey, what are the trade-offs involved? Do you have a third architecture you'd like to suggest?" And so, that can be a really tricky thing to avoid. +STEPHANIE: Yeah, I like that what you're saying also kind of suggested that it's okay if you don't have an idea yet for exactly how it should look like. Maybe you just are like, oh, like, I'm having a hard time understanding this, but I don't think just leaving it at that gives the author a lot to go on. +I think there's something to it about maybe the action part of actionable is just like, "Can you talk about it with me?" Or "Could you explain what you're trying to do here?" Or, you know, leave a comment about what this method is doing. There's a lot of ways, I think, that you can reach some amount of improvement, even if it doesn't end up being, like, the ideal code that you would write. +JOËL: Yes. There's also maybe a distinction in making it actionable by giving someone some code and saying, "Hey, you should copy-paste this code and make that..." or, you know, use a GitHub suggested code or something, which works on the small. And in the big, you can give some maybe examples and say, "Hey, what if you refactored in this way?" +But sometimes, you could even step back and let them do that work and say, "Hey, I have some concerns with the current architecture. It's not flexible in the ways that we need to be flexible. Here's my understanding of the requirements. And here's sort of how I see maybe this architecture not working with that. Let's think of some different ways we could approach this problem." And oftentimes, it's nice to give at least one or two different ideas to help start that. But it can be okay to just ask the person, "Hey, can you come up with some alternate implementations that would fulfill these sets of requirements?" +STEPHANIE: Yeah, I like that. And I can even see, like, maybe you do that work, and you don't end up pursuing it completely in addressing that feedback. But even asking someone to do the exercise itself, I think, can then spark new ideas and maybe other improvements. +In general, I like to think about...I'm a little hesitant to use this metaphor because I'm not actually giving code, like, letter grades when I review them, but the idea that, like, not all code has to get, like, an A [chuckles], but maybe getting it, like, from one letter grade up to, like, half a letter grade, like, higher, that is valuable, even if it's not always practical to go through multiple rounds of code review. And I think just making it actionable enough to be a little bit better, like, that is, in my opinion, the sweet spot. +JOËL: That's true. The sort of over-giving feedback to someone to try to get code perfect, rather than just saying, "Hey, can we make it slightly better?" And, you know, there are probably some minimum standards you need to hit. But at some point, it's a trade-off of like, how much time do we need to put polishing this versus shipping something? +STEPHANIE: Yeah, and I think that it is cumulative over time, right? That's how people learn. Yeah, it's like one of the biggest opportunities for developers to level up is from that feedback. And that's why I think it's important that it's actionable because, you know, and you put the time into, like, giving that review, and it's not just to make sure the code works, but it's also, like, one of the touch points for collaboration. +JOËL: So, if you had to summarize what makes code review comments actionable, do you have, like, top three tips that make a comment really actionable as opposed to something that's not helpful? Or maybe that's more of the journey that you're on, and you've not distilled it down to three pithy tips that you can put in a listicle. +STEPHANIE: Honestly, I think it does kind of just distill down to one, which is for every comment, you should have an idea of what you would like the author to do about it. And it's okay if it's nothing, but then tell them that it's nothing. You could just be expressing, "I thought this was kind of weird, [laughs]" or "This is not my favorite thing, but it's okay." +JOËL: And it can be okay for the thing you want the author to do. It doesn't have to be code. It could be a conversation. +STEPHANIE: Yeah, exactly. It could be a conversation. It could be asking for information, too, right? Like, "Did you consider alternatives, and could you share them with me?" But that request portion, I think is really important because, yeah, I think there's so much miscommunication that can happen along the way. So, definitely still trying to figure out how to best support that kind of code review culture on my team. +JOËL: This week's episode has been really fun because it's just been a combination of a lot of things that are new in our world, things that we've been trying, things that we've been learning. And kind of in an almost, like, a meta sense, one of the things I've been digging into is combinatorics, the branch of math that looks at how things combine and particularly how it works with combining a bunch of ActiveRecord query fragments where there's potential branching, so things like doing a union of two sort of sub queries or doing an or where you're combining two different where queries and trying to figure out what are the different paths through that. +STEPHANIE: Wow, what a great way to combine what we were talking about, Joël [laughs]. Did you apply combinatorics to this podcast episode [laughs]? +JOËL: Somehow, topics multiply with each other, something, something. +STEPHANIE: Yeah, that makes sense to me [laughs]. Okay. Will you tell me more about what you've been using it for in your queries? +JOËL: So, one thing I'm trying to do is because I've got these different branching paths through a query, I want to see sort of all the different ways because these are defined as ActiveRecord scopes, and I'm chaining them together. And it looks linear because I'm calling scope1 dot scope2 dot scope3. But each of those have branches inside of them. And so, there's all these different ways that data could get used or not. +And one way that I figured out, like, what are the different paths here, was actually drawing out a matrix, just putting together a table. In this case, I had two scopes, each of which had a two-way branch inside, and so I made a two by two matrix. And that gave me all of the combinations of, oh, if you go down one branch in one scope and down another branch in the other scope. And what I went through is then I went in in each square and filled in how many records I would expect to get back from the query from some basic set that I was working on in each of these combinations. +And one thing that was really interesting is that some of those combinations were sort of mutually exclusive, where a scope further down the line was filtering on the same field as an earlier one and would overwrite it or not overwrite it, but the two would then sort of you can't have both of those things be true at the same time. So, I'm looking for something that has a particular manager ID, and then I'm looking for something that has a particular different manager ID. And the way Rails combines these, if you just change scopes with where, is to and them together. There are no records that have both manager ID 1 and manager ID 2. You can only have one manager ID. +And so, as I'm filling out my matrix, there's some sections I can just zero out and be like, wait, this will always return zero record. And then I can start focusing on the parts that are not zeroed out. So, I've got two or three squares. What's special about those? And that helped me really understand what the combination of these multiple query fragments together were actually trying to do as a holistic whole. +STEPHANIE: Wow, yeah, that is really interesting because I hear you when you say it looks linear. And it would be really surprising to me for there to be branching paths. Like, that's not really what I think about when I think about SQL. But that makes a lot of sense that it could get so complicated that it's just impossible to get a certain kind of result. Like, what's going to be the outcome of applying combinatorics to this? Is there a refactoring opportunity, or is it really just to even understand what's going on? +JOËL: So, this was a refactoring that I was trying to do, but I didn't really understand the underlying behavior of the chain of scopes. I just knew that they were doing some complex things that were inefficient from a SQL perspective. And so, I was looking at ways to refactor, but I also wanted to get a sense of what is this actually trying to do other than just chaining a bunch of random bits of code together? So, the matrix really helped for that. +The other way that I used it was to write some tests because this query I was trying to refactor, this chain of scopes, was untested. And I wanted to write tests that were very thorough because I wanted to make sure that my refactor didn't break any edge cases. And I'm, you know, writing a few tests. Okay, well, here's a record that I definitely want to get returned by this query, and maybe here are a couple of records I don't want to get returned. +And the more I was, like, going into this and trying to write test cases, the more I was finding more edge cases that I didn't want to and, oh, but what about this? And what about the combination of these things? And it got to the point where it was just messing with my mind. I was, like, confusing myself and really struggling to write tests that would do anything useful. +STEPHANIE: Wow. Yeah. Honestly, I have already started to become a little bit suspicious of complex scopes, and this further pushes me in that direction [laughs] because yeah, once you start to...like, the benefit of them is that you can chain them, but it really hides a lot of the underlying behavior. So, you can easily just turn yourself around or, like, go, you know, kind of end up [laughs] in a little bit of a bind. +JOËL: Definitely, especially once it grows a little bit harder to hold in your head. And I don't know exactly where that level is for me. But in this particular situation, I identified, I think, five different dimensions that would impact the results of this query. And then each dimension had maybe three or four different values that we might care about. And, eventually, I just took the time to write this out. +So, I created five arrays and then just said, "Hey, here are the different managers that we care about. Here are the different project types we care about. Here are the different..." and we had, like, five of these, and each array had three or four elements in it. And then, in a series of nested loops, I iterated through all of these arrays and at the innermost loop, created the data that I wanted that matched that particular set of values. +Now, we're often told you should not be doing things in nested loops because you end up sort of multiplying all of these together, but, in this case, this is actually what I wanted to do. You know, it turns out that I had a hundred-ish records I had to create to sort of create a data set that would be all the possible edge cases I might want to filter on. And creating them all by hand with all of the different variations was going to be too much. And so, I ended up doing this with arrays and nested loops. And it got me the data that I needed. And it gave me then the confidence to know that my refactor did indeed work the way I was expecting. +STEPHANIE: Wow. That's truly hero's work [chuckles]. I'm, like, very excited because it sounds like that's a huge opportunity for some performance improvements as well. +JOËL: For the underlying code, yes. The test might be a little bit slow because I'm creating a hundred records in the database. And you might say, "Oh, do you really need to do that? Can you maybe collapse some of these cases?" In this particular case, I really wanted to have high confidence that the refactor was not changing anything. And so, I was okay creating a hundred records over a series of nested iterations. That was a price I was willing to pay. The refactored query, it turns out, I was able to write it in a way that was significantly faster. +STEPHANIE: Yeah, that's what I suspected. +JOËL: So, I had to rewrite it in a way that didn't take advantage of all the change scopes. I had to just sort of write something custom from scratch, which is often the case, right? Performance and reusability sometimes fight against each other, and it's a trade-off. So, I'm not reusing the scopes. I had to write something from scratch, but it's multiple hundreds of times faster. +STEPHANIE: Wow. Yeah. That seems worth it for a slow test [laughs] for the user experience to be a lot better, especially when you just reach that level of complexity. And it's a really awesome strategy that you applied to figure that out. I think it's a very unique one [laughs]. That's for sure. +JOËL: I've had an interest in sort of analytical tools to help me understand domain models, to help understand problems, to help understand code that I'm working with for a while now, and I think an understanding of combinatorics fits into that. And then, particular tools within that, such as drawing things out in a table, in a two by two matrix, or an end-by-end matrix to get something visual, that's a great tool for debugging or understanding a problem. +Thinking of problems as data that exists in multiple dimensions and then asking about the cardinality of that set it's the kind of analysis I did a lot when I was modeling using algebraic data types in Elm. But now I've sort of taken some of the tools and analysis I use from that world into thinking about things like SQL records, things like dealing with data in Ruby. And I'm able to bring those tools and that way of thinking to help me solve some problems that I might struggle to solve otherwise. +For any of our listeners who this, like, kind of piques their interest, combinatorics falls under a broader umbrella of mathematics called discrete math. And within that, there's a lot that I think is really useful, a lot of tools and techniques that we can apply to our day-to-day programming. We have a Bike Shed episode where we talked about is discrete math relevant to day-to-day programmers and what are the ways it's so? We'll link that in the show notes. I also gave a talk at RailsConf last year diving into that titled: The Math Every Programmer Needs. So, if you're looking for something that's accessible to someone who's not done a math degree, those are two great jumping-off points. +STEPHANIE: Yeah. And then, maybe you'll start drawing out arrays and applying combinatorics to figure out your performance problems. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + + Stephanie introduces her ideal setup for enjoying coffee on a bike ride. Joël describes his afternoon tea ritual. Exciting news from the hosts: both have been accepted to speak at RailsConf! Stephanie's presentation, titled "So, Writing Tests Feels Painful. What now?" aims to tackle the issues developers encounter with testing while offering actionable advice to ease these pains. Joël's session will focus on utilizing Turbo to create a Dungeons & Dragons character sheet, combining his passion for gaming with technical expertise.

+ +

Their conversation shifts to artificial intelligence and its potential in code refactoring and other applications, such as enhancing the code review process and solving complex software development problems. Joël shares his venture into combinatorics, illustrating how this mathematical approach helped him efficiently refactor a database query by systematically exploring and testing all potential combinations of query segments.

+ +

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, today I went out for a coffee on my bike, and I feel like I finally have my perfect, like, on-the-go coffee setup. We have this thoughtbot branded travel mug. So, it's one of the little bits of swag that we got from the company. It's, like, perfectly leak-proof. I'll link the brand in the show notes. But it's perfectly leak-proof, which is great. And on my bike, I have a little stem bag, so it's just, like, a tiny kind of, like, cylindrical bag that sits on the, like, vertical part of my handlebars that connects to the rest of my bag. And it's just, like, the perfect size for a 12-ounce coffee.

+ +

And so, I put my little travel mug in there, and I just had a very refreshing morning. And I'd gone out on my bike for a little bit, stopping by for coffee and headed home to work. And I got to drink my coffee during my first meeting. So, it was a wonderful way to start the day.

+ +

JOËL: Do you just show up at the coffee shop with your refillable mug and say, "Hey, can you pour some coffee in this?"

+ +

STEPHANIE: Yeah. I think a lot of coffee places are really amenable to bringing your own travel mugs. So yeah, it's really nice because I get to use less plastic. And also, you know, when you get a to-go mug, it is not leak-proof, right? It could just slosh all over the place and spill, so not bike-friendly. But yeah, bring your own mug. It's very easy.

+ +

JOËL: Excellent.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: Also, warm beverages. Who would have thought? It's almost like it's cold in North America or something. I've been really enjoying making myself tea in the afternoons recently. And I've been drinking this brand of tea that is a little bit extra. Every flavor of tea they have comes with a description of how the tea feels.

+ +

STEPHANIE: Ooh.

+ +

JOËL: I don't know who came up with these, but they're kind of funny. So, one that I particularly enjoy is described as feels like stargazing on an empty beach.

+ +

STEPHANIE: Wow. That's very specific.

+ +

JOËL: They also give you tasting notes. This one has tastes of candied violet, elderberry, blackberry, and incense.

+ +

STEPHANIE: Ooh, that sounds lovely. Are you drinking, like, herbal tea in the afternoon, or do you drink caffeinated tea?

+ +

JOËL: I'll do caffeinated tea. I limit myself to one pot of coffee that I brew in the morning, and then, whenever that's done, I switch to tea. Tea I allow myself anything: herbal, black tea; that's fine.

+ +

STEPHANIE: Yeah, I can't have too much caffeine in the afternoon either. But I do love an extra tea. I wish I could remember, like, what even was in this tea or what brand it was, but once I had a tea that was a purplish color. But then, when you squeeze some lemon in it, or I guess maybe anything with a bit of acid, it would turn blue.

+ +

JOËL: Oh, that's so cool.

+ +

STEPHANIE: Yeah, I'll have to find what this tea was [laughs] and update the podcast for any tea lovers out there. But yeah, it was just, like, a little bit of extra whimsy to your regular routine.

+ +

JOËL: I love adding a little whimsy to my day, even if it's just seeing a random animated GIF that a coworker has sent or Tuple has some of the, like, reactions you can send if you're pairing with someone. And I don't use those very often, so whenever one of those comes through, and it's like, ship it or yay, that makes me very happy.

+ +

STEPHANIE: Agreed.

+ +

JOËL: This week is really fun because as we were prepping for this episode, we both realized that there is a lot that's been new in our world recently. And Stephanie, in particular, you've got some pretty big news that recently happened to you.

+ +

STEPHANIE: Yeah, it turns out we're making the what's new in your world segment the entire episode today [laughs]. But my news is that I am speaking at RailsConf this year, so that is May 7th through 9th in Detroit. And so, yeah, I haven't spoken at a RailsConf before, only a RubyConf. So, I'm looking forward to it. My talk is called: So, Writing Tests Feels Painful. What now?

+ +

JOËL: Wait, is writing tests ever painful [laughs]?

+ +

STEPHANIE: Maybe not for you, but for the rest of us [laughs].

+ +

JOËL: No, it absolutely is. I, right before this recording, came from a pairing session where we were scratching our heads on an, like, awkward-to-write test. It happens to all of us.

+ +

STEPHANIE: Yeah. So, I was brainstorming topics, and I kind of realized, especially with a lot of our consulting experience, you know, we hear from developers or even maybe, like, engineering managers a lot of themes around like, "Oh, like, development is slowing down because our test suite is such a headache," or "It's really slow. It's really flaky. It's really complicated." And that is a pain point that a lot of tech leaders are also looking to address for their teams.

+ +

But I was really questioning this idea that, like, it always had to be some effort to improve the test suite, like, that had to be worked on at some later point or get, like, an initiative together to fix all of these problems, and that it couldn't just be baked into your normal development process, like, on an individual level. I do think it is really easy to feel a lot of pain when trying to write tests and then just be like, ugh, like, I wish someone would fix this, right? Or, you know, just kind of ignore the signals of that pain because you don't know, like, how to manage it yourself.

+ +

So, my talk is about when you do feel that pain, really trying to determine if there's anything you can do, even in just, like, the one test file that you're working in to make things a little bit easier for yourself, so it doesn't become this, like, chronic issue that just gets worse and worse. Is there something you could do to maybe reorganize the file as you're working in it to make some conditionals a little bit clearer?

+ +

Is there any, like, extra test setup that you're like, "Oh, actually, I don't need this anymore, and I can just start to get rid of it, not just for this one example, but for the rest in this file"? And do yourself a favor a little bit. So yeah, I'm excited to talk about that because I think that's perhaps, like, a skill that we don't focus enough on.

+ +

JOËL: Are you going to sort of focus in on the side of things where, like, a classic TDD mantra is that test pain reflects underlying code complexity? So, are you planning to focus on the idea of, oh, if you're feeling test pain, maybe take some time to refactor some of the code that's under test, maybe because there's some tight coupling? Or are you going to lean a little bit more into maybe, like, the Boy Scout rule, you know, 'Leave the campsite cleaner than you found it' for your test files?

+ +

STEPHANIE: Ooh, I like that framing. Definitely more of the former. But one thing I've also noticed working with a lot of client teams is that it's not always clear, like, how to refactor. I think a lot of intermediate developers start to feel that pain but don't know what to do about it. They don't know, like, maybe the code smells, or the patterns, or refactoring strategies, and that can certainly be taught. It will probably pull from that. But even if you don't know those skills yet, I'm wondering if there's, like, an opportunity to teach, like, developers at that level to start to reflect on the code and be like, "Hmm, what could I do to make this a little more flexible?"

+ +

And they might not know the names of the strategies to, like, extract a class, but just start to get them thinking about it. And then maybe when they come across that vocabulary later, it'll connect a lot easier because they'll have started to think about, you know, their experiences day to day with some of the more conceptual stuff.

+ +

JOËL: I really like that because I feel we've probably all heard that idea that test pain, especially when you're test driving, is a sign of maybe some anti-patterns or some code smells in the underlying code that you're testing. But translating that into something actionable and being able to say, "Okay, so my tests are painful. They're telling me something needs to be refactored. I'm looking at this code, and I don't know what to refactor." It's a big jump. It's almost the classic draw two circles; draw the rest of the owl meme. And so, I think bridging that gap is something that is really valuable for our community.

+ +

STEPHANIE: Yeah, that's exactly what I hope to do in my talk. So, Joël, you [chuckles] also didn't quite mention that you have big news as well.

+ +

JOËL: So, I also got accepted to speak at RailsConf. I'm giving a talk on Building a Dungeons & Dragons Character Sheet Using Turbo.

+ +

STEPHANIE: That's really awesome. I'm excited because I want to learn more about Turbo. I want someone else to tell me [laughs] what I can do with it. And as a person with a little bit of Dungeons & Dragons experience, I think a character sheet is kind of the perfect vehicle for that.

+ +

JOËL: Building a D&D character sheet has been kind of my go-to project to experiment with a new front-end framework because it's something that's pretty dynamic. And for those who don't know, there's a bunch of fields that you fill in with stats for different attributes that your character has, but then those impact other stats that get rendered. And sometimes there can be a chain two or three long where different numbers kind of combine together. And so, you've got this almost dependency tree of, like, a particular number.

+ +

Maybe your skill at acrobatics might depend on a number that you entered in the dexterity field, but it also depends on your proficiency bonus, and maybe also depends on the race that you picked and a few other things. And so, calculating those numbers all of a sudden becomes not quite so simple. And so, I find it's a really fun exercise to build when trying out a new interactive front-end technology.

+ +

STEPHANIE: Have you done this with a different implementation or a framework?

+ +

JOËL: I've done this, not completely, but I've attempted some parts of a D&D character sheet, I think, with Backbone.js with Ember. I may have done an Angular one at some point in original Angular, so Angular 1. I did this with Elm. Somehow, I skipped React. I don't think I did React to build a D&D character sheet. And now I'm kind of moving a little bit back to the backend. How much can we get done just with Turbo? Or do we need to pull in maybe Stimulus? These are all things that are going to be really fun to demonstrate.

+ +

STEPHANIE: Yeah. Speaking of injecting some whimsy earlier, I think it's kind of like just a little more fun than a regular to-do app, you know, or a blog to show how you can build, you know, something that people kind of understand with a different technology.

+ +

JOËL: Another really fun thing that I've been toying with this week has been using AI to help me refactor code. And this has been using just sort of a classic chat AI, not a tool like Copilot. And I was dealing with a query that was really slow, and I wanted to restructure it in a different way. And I described to the AI how I wanted it to refactor and explicitly said, "I want this to be the same before and after." And I asked it to do the refactor, and it gave me some pretty disappointing results where it did some, like, a couple of really obvious things that were not that useful.

+ +

And I was talking to a colleague about how I was really disappointed. I was thinking, well, AI should be able to do something better than this. And this colleague suggested changing the way I was asking for things and specifically asking for a step-by-step and asking it to prove every step using relational algebra, which is the branch of math that deals with everything that underlies relational databases, so the transformations that you would do where you keep everything the same, but you're saying, "Hey, these equations are all equivalent." And it sure did. It gave me a, like, 10-step process with all these, like, symbols and things.

+ +

My relational algebra is not that strong, and so I couldn't totally follow along. But then I asked it to give me a code example, like, show me the SQL at every step of this transformation and at the end. And, you know, it all kind of looked all right. I've not fully tested the final result it gave me to see if it does what it says on the tin. But I'm cautiously optimistic. I think it looks very similar to something that I came up with on my own. And so, I'm somewhat impressed, at least, like, much better than things were in the beginning with that first round. So, I'm really curious to see where I can take this.

+ +

STEPHANIE: Yeah, I think that's cool that you were able to prompt it differently and get something more useful. One of the reasons why I personally have been a little bit hesitant to get into the large language models is because I would love to see the AI show its work, essentially, like, tell me a little bit more about how it got from question to answer. And I thought that framing of kind of step-by-step show me code was a really interesting way, even to just, like, get some different results that do the same thing.

+ +

But you can kind of evaluate that a little bit more on your own rather than just using that first result that it gave you that was like, eh, like, I don't know if this really did anything for me. So, it would be cool, even if you don't end up using, like, the final one, right? If something along the way also is an improvement from what you started with that would be really interesting.

+ +

JOËL: Honestly, I think you kind of want the same thing if you're chatting with an AI chatbot or having a conversation in Slack with a colleague. They're just like, "Hey, can you help me refactor this?" And then a sort of, like, totally different chunk of code. And it's just like, "Trust me, it works."

+ +

STEPHANIE: [laughs].

+ +

JOËL: And maybe it does. Maybe you plug it into your codebase and run the tests against it, and the tests are still green. And so, you trust that it works, but you don't really understand where it came from. That doesn't always feel good, even when it comes from a human. So, what I've appreciated with colleagues has been when they've given me a step-by-step. Sometimes, they give me the final product. They just say, "Hey. Try this. Does this work?" Plug it in to the test. It does pass. It's green. Great. "Tell me what black magic you did to get to that."

+ +

And then they give me the step-by-step and it's like, oh, that's so good because not only do I get a better understanding of what happens at every step, but now I'm equipped the next time I run into this problem to apply the same technique to figure it out on my own.

+ +

STEPHANIE: Yeah. And I liked, also, that relational algebra pro tip, right? It kind of ensures that what you're getting makes sense or is equivalent along the way [laughs].

+ +

JOËL: We think, right? I don't know enough relational algebra to check its work. It is quite possible that it is making some subtle mistakes along the way, or, like, making inferences that it shouldn't be. I'm not going to say I trust that. But I think, specifically, when asking for SQL transformations, prompting it to do so using relational algebra in a step-by-step way seemed to be a way to get it to do something more reliably or at least give more interesting results.

+ +

STEPHANIE: Cool.

+ +

JOËL: I was interested in trying this out in part because I've been more curious about AI tools recently, and also because we're hoping to do a deeper dive into AI on a Bike Shed episode at some point later, so very much still in the gathering information phase. But this was a really cool experience. So, having an AI refactor a query for me using relational algebra, definitely something that's new in my world this week.

+ +

STEPHANIE: Speaking of refactoring and this idea of making improvements to your code and trying to figure out how to get from what you currently have to something new, I have been thinking a lot about how to make code reviews more actionable. And that's because, on my current client project, our team is struggling a little bit with code reviews, especially when you kind of want to give feedback on more of a design change in the code or thinking about some different abstractions. I have found that that is really hard to communicate async and also in a, like, a GitHub code review format where you can really just comment, like, line by line.

+ +

And I've found that, you know, when someone is leaving feedback, that's like, "I'm having a hard time reading this. And I'm imagining that we could organize the code a bit differently in these three different layers or abstractions," there's a lot of assumptions there, right [laughs]? That your message is being communicated to the author and that they are able to, like, visualize, or have a mental model for what you're explaining as well.

+ +

And then kind of what I've been seeing in this dynamic is, like, not really knowing what to do with that and to kind of just, like, I don't know where to go from here. So, I guess the next step is just to, like, merge it. Is that something you've experienced before or encountered when it comes to feedback?

+ +

JOËL: Broader changes are often challenging to explain, especially when they're...sometimes you get so abstract you can just write a quick paragraph. And sometimes it's like, hey, what if we, like, totally change our approach? I've definitely done the thing where I'll just ping someone and say, "Hey, can we talk about this synchronously? Can we get on a call and have a deeper conversation?"

+ +

How do you tend to approach if you're not going to hop on a call with someone and, like, have a 20 or 30-minute conversation? How do you approach doing that asynchronously on a pull request? Are you the type of person to put, like, a ton of, like, code blocks, like, "Here's what I was thinking. We could instead have this class and this thing"? And, like, pretty soon, it's, like, a page and a half of text. Or do you have another approach that you like to use?

+ +

STEPHANIE: Yeah. And I think that's where it can get really interesting. Because my process is, I'll usually just start commenting and maybe if I'm seeing some things that can be done differently. If it's not just, like, a really obvious change that I could just use English to describe, I'll add a little suggested change. But I also don't want to just rewrite this person's code [laughs] in a code review.

+ +

JOËL: That's the challenge, right?

+ +

STEPHANIE: Yeah. And I've definitely seen that be done before, too. Once I notice I'm at, like, four plus comments, and then they're not just, like, nitpicks about, like, syntax or something like that, that helps me clue into the idea that there is some kind of bigger change that I might be asking of the author. And I don't want to overwhelm them with, like, individual comments that really are trying to convey something more holistic.

+ +

JOËL: Right. I wonder if having a, like, specialized yet more abstract language is useful for these sorts of things where a whole paragraph in English or, you know, a ton of code examples might be a bit much. If you're able to say something like, "Hey, how would you feel about using a strategy pattern approach here instead of, you know, maybe a template object or some custom thing that we've built here?" that allows us to say a lot in a fairly sort of terse way. And it's the thing that you can leave more generically on the PR instead of, like, individually commenting in a bunch of places. And that can start a broader conversation at more of an architecture level.

+ +

STEPHANIE: Yes, I really like that. That's a great idea. I would follow that up with, like, I think at the end of the day, there are some conversations that do need to be had synchronously. And so, I like the idea of leaving a comment like that and just kind of giving them resources to learn what a strategy pattern is and then offering support because that's also a way to shorten that feedback loop of trying to communicate an idea. And I like that it's kind of guiding them, but also you're there to add some scaffolding if it ends up being, like, kind of a big ask for them to figure out what to do.

+ +

JOËL: There's also oftentimes, I think, a tone thing to manage where, especially if there's a difference in seniority or experience between the two people, it can be very easy for something to come across as an ask or a demand rather than a like, "Hey, let's think about some alternatives here." Or, like, "I have some concerns with your implementation. Let's sort of broadly explore some possible alternatives. Maybe a strategy pattern works."

+ +

But the person reading that who wrote the original code might be, like, receiving that as "Your code is bad. You should have done a strategy pattern instead." And that's not the conversation I want to have, right? I want to have a back-and-forth about, "Hey, what are the trade-offs involved? Do you have a third architecture you'd like to suggest?" And so, that can be a really tricky thing to avoid.

+ +

STEPHANIE: Yeah, I like that what you're saying also kind of suggested that it's okay if you don't have an idea yet for exactly how it should look like. Maybe you just are like, oh, like, I'm having a hard time understanding this, but I don't think just leaving it at that gives the author a lot to go on.

+ +

I think there's something to it about maybe the action part of actionable is just like, "Can you talk about it with me?" Or "Could you explain what you're trying to do here?" Or, you know, leave a comment about what this method is doing. There's a lot of ways, I think, that you can reach some amount of improvement, even if it doesn't end up being, like, the ideal code that you would write.

+ +

JOËL: Yes. There's also maybe a distinction in making it actionable by giving someone some code and saying, "Hey, you should copy-paste this code and make that..." or, you know, use a GitHub suggested code or something, which works on the small. And in the big, you can give some maybe examples and say, "Hey, what if you refactored in this way?"

+ +

But sometimes, you could even step back and let them do that work and say, "Hey, I have some concerns with the current architecture. It's not flexible in the ways that we need to be flexible. Here's my understanding of the requirements. And here's sort of how I see maybe this architecture not working with that. Let's think of some different ways we could approach this problem." And oftentimes, it's nice to give at least one or two different ideas to help start that. But it can be okay to just ask the person, "Hey, can you come up with some alternate implementations that would fulfill these sets of requirements?"

+ +

STEPHANIE: Yeah, I like that. And I can even see, like, maybe you do that work, and you don't end up pursuing it completely in addressing that feedback. But even asking someone to do the exercise itself, I think, can then spark new ideas and maybe other improvements.

+ +

In general, I like to think about...I'm a little hesitant to use this metaphor because I'm not actually giving code, like, letter grades when I review them, but the idea that, like, not all code has to get, like, an A [chuckles], but maybe getting it, like, from one letter grade up to, like, half a letter grade, like, higher, that is valuable, even if it's not always practical to go through multiple rounds of code review. And I think just making it actionable enough to be a little bit better, like, that is, in my opinion, the sweet spot.

+ +

JOËL: That's true. The sort of over-giving feedback to someone to try to get code perfect, rather than just saying, "Hey, can we make it slightly better?" And, you know, there are probably some minimum standards you need to hit. But at some point, it's a trade-off of like, how much time do we need to put polishing this versus shipping something?

+ +

STEPHANIE: Yeah, and I think that it is cumulative over time, right? That's how people learn. Yeah, it's like one of the biggest opportunities for developers to level up is from that feedback. And that's why I think it's important that it's actionable because, you know, and you put the time into, like, giving that review, and it's not just to make sure the code works, but it's also, like, one of the touch points for collaboration.

+ +

JOËL: So, if you had to summarize what makes code review comments actionable, do you have, like, top three tips that make a comment really actionable as opposed to something that's not helpful? Or maybe that's more of the journey that you're on, and you've not distilled it down to three pithy tips that you can put in a listicle.

+ +

STEPHANIE: Honestly, I think it does kind of just distill down to one, which is for every comment, you should have an idea of what you would like the author to do about it. And it's okay if it's nothing, but then tell them that it's nothing. You could just be expressing, "I thought this was kind of weird, [laughs]" or "This is not my favorite thing, but it's okay."

+ +

JOËL: And it can be okay for the thing you want the author to do. It doesn't have to be code. It could be a conversation.

+ +

STEPHANIE: Yeah, exactly. It could be a conversation. It could be asking for information, too, right? Like, "Did you consider alternatives, and could you share them with me?" But that request portion, I think is really important because, yeah, I think there's so much miscommunication that can happen along the way. So, definitely still trying to figure out how to best support that kind of code review culture on my team.

+ +

JOËL: This week's episode has been really fun because it's just been a combination of a lot of things that are new in our world, things that we've been trying, things that we've been learning. And kind of in an almost, like, a meta sense, one of the things I've been digging into is combinatorics, the branch of math that looks at how things combine and particularly how it works with combining a bunch of ActiveRecord query fragments where there's potential branching, so things like doing a union of two sort of sub queries or doing an or where you're combining two different where queries and trying to figure out what are the different paths through that.

+ +

STEPHANIE: Wow, what a great way to combine what we were talking about, Joël [laughs]. Did you apply combinatorics to this podcast episode [laughs]?

+ +

JOËL: Somehow, topics multiply with each other, something, something.

+ +

STEPHANIE: Yeah, that makes sense to me [laughs]. Okay. Will you tell me more about what you've been using it for in your queries?

+ +

JOËL: So, one thing I'm trying to do is because I've got these different branching paths through a query, I want to see sort of all the different ways because these are defined as ActiveRecord scopes, and I'm chaining them together. And it looks linear because I'm calling scope1 dot scope2 dot scope3. But each of those have branches inside of them. And so, there's all these different ways that data could get used or not.

+ +

And one way that I figured out, like, what are the different paths here, was actually drawing out a matrix, just putting together a table. In this case, I had two scopes, each of which had a two-way branch inside, and so I made a two by two matrix. And that gave me all of the combinations of, oh, if you go down one branch in one scope and down another branch in the other scope. And what I went through is then I went in in each square and filled in how many records I would expect to get back from the query from some basic set that I was working on in each of these combinations.

+ +

And one thing that was really interesting is that some of those combinations were sort of mutually exclusive, where a scope further down the line was filtering on the same field as an earlier one and would overwrite it or not overwrite it, but the two would then sort of you can't have both of those things be true at the same time. So, I'm looking for something that has a particular manager ID, and then I'm looking for something that has a particular different manager ID. And the way Rails combines these, if you just change scopes with where, is to and them together. There are no records that have both manager ID 1 and manager ID 2. You can only have one manager ID.

+ +

And so, as I'm filling out my matrix, there's some sections I can just zero out and be like, wait, this will always return zero record. And then I can start focusing on the parts that are not zeroed out. So, I've got two or three squares. What's special about those? And that helped me really understand what the combination of these multiple query fragments together were actually trying to do as a holistic whole.

+ +

STEPHANIE: Wow, yeah, that is really interesting because I hear you when you say it looks linear. And it would be really surprising to me for there to be branching paths. Like, that's not really what I think about when I think about SQL. But that makes a lot of sense that it could get so complicated that it's just impossible to get a certain kind of result. Like, what's going to be the outcome of applying combinatorics to this? Is there a refactoring opportunity, or is it really just to even understand what's going on?

+ +

JOËL: So, this was a refactoring that I was trying to do, but I didn't really understand the underlying behavior of the chain of scopes. I just knew that they were doing some complex things that were inefficient from a SQL perspective. And so, I was looking at ways to refactor, but I also wanted to get a sense of what is this actually trying to do other than just chaining a bunch of random bits of code together? So, the matrix really helped for that.

+ +

The other way that I used it was to write some tests because this query I was trying to refactor, this chain of scopes, was untested. And I wanted to write tests that were very thorough because I wanted to make sure that my refactor didn't break any edge cases. And I'm, you know, writing a few tests. Okay, well, here's a record that I definitely want to get returned by this query, and maybe here are a couple of records I don't want to get returned.

+ +

And the more I was, like, going into this and trying to write test cases, the more I was finding more edge cases that I didn't want to and, oh, but what about this? And what about the combination of these things? And it got to the point where it was just messing with my mind. I was, like, confusing myself and really struggling to write tests that would do anything useful.

+ +

STEPHANIE: Wow. Yeah. Honestly, I have already started to become a little bit suspicious of complex scopes, and this further pushes me in that direction [laughs] because yeah, once you start to...like, the benefit of them is that you can chain them, but it really hides a lot of the underlying behavior. So, you can easily just turn yourself around or, like, go, you know, kind of end up [laughs] in a little bit of a bind.

+ +

JOËL: Definitely, especially once it grows a little bit harder to hold in your head. And I don't know exactly where that level is for me. But in this particular situation, I identified, I think, five different dimensions that would impact the results of this query. And then each dimension had maybe three or four different values that we might care about. And, eventually, I just took the time to write this out.

+ +

So, I created five arrays and then just said, "Hey, here are the different managers that we care about. Here are the different project types we care about. Here are the different..." and we had, like, five of these, and each array had three or four elements in it. And then, in a series of nested loops, I iterated through all of these arrays and at the innermost loop, created the data that I wanted that matched that particular set of values.

+ +

Now, we're often told you should not be doing things in nested loops because you end up sort of multiplying all of these together, but, in this case, this is actually what I wanted to do. You know, it turns out that I had a hundred-ish records I had to create to sort of create a data set that would be all the possible edge cases I might want to filter on. And creating them all by hand with all of the different variations was going to be too much. And so, I ended up doing this with arrays and nested loops. And it got me the data that I needed. And it gave me then the confidence to know that my refactor did indeed work the way I was expecting.

+ +

STEPHANIE: Wow. That's truly hero's work [chuckles]. I'm, like, very excited because it sounds like that's a huge opportunity for some performance improvements as well.

+ +

JOËL: For the underlying code, yes. The test might be a little bit slow because I'm creating a hundred records in the database. And you might say, "Oh, do you really need to do that? Can you maybe collapse some of these cases?" In this particular case, I really wanted to have high confidence that the refactor was not changing anything. And so, I was okay creating a hundred records over a series of nested iterations. That was a price I was willing to pay. The refactored query, it turns out, I was able to write it in a way that was significantly faster.

+ +

STEPHANIE: Yeah, that's what I suspected.

+ +

JOËL: So, I had to rewrite it in a way that didn't take advantage of all the change scopes. I had to just sort of write something custom from scratch, which is often the case, right? Performance and reusability sometimes fight against each other, and it's a trade-off. So, I'm not reusing the scopes. I had to write something from scratch, but it's multiple hundreds of times faster.

+ +

STEPHANIE: Wow. Yeah. That seems worth it for a slow test [laughs] for the user experience to be a lot better, especially when you just reach that level of complexity. And it's a really awesome strategy that you applied to figure that out. I think it's a very unique one [laughs]. That's for sure.

+ +

JOËL: I've had an interest in sort of analytical tools to help me understand domain models, to help understand problems, to help understand code that I'm working with for a while now, and I think an understanding of combinatorics fits into that. And then, particular tools within that, such as drawing things out in a table, in a two by two matrix, or an end-by-end matrix to get something visual, that's a great tool for debugging or understanding a problem.

+ +

Thinking of problems as data that exists in multiple dimensions and then asking about the cardinality of that set it's the kind of analysis I did a lot when I was modeling using algebraic data types in Elm. But now I've sort of taken some of the tools and analysis I use from that world into thinking about things like SQL records, things like dealing with data in Ruby. And I'm able to bring those tools and that way of thinking to help me solve some problems that I might struggle to solve otherwise.

+ +

For any of our listeners who this, like, kind of piques their interest, combinatorics falls under a broader umbrella of mathematics called discrete math. And within that, there's a lot that I think is really useful, a lot of tools and techniques that we can apply to our day-to-day programming. We have a Bike Shed episode where we talked about is discrete math relevant to day-to-day programmers and what are the ways it's so? We'll link that in the show notes. I also gave a talk at RailsConf last year diving into that titled: The Math Every Programmer Needs. So, if you're looking for something that's accessible to someone who's not done a math degree, those are two great jumping-off points.

+ +

STEPHANIE: Yeah. And then, maybe you'll start drawing out arrays and applying combinatorics to figure out your performance problems.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie introduces her ideal setup for enjoying coffee on a bike ride. Joël describes his afternoon tea ritual. Exciting news from the hosts: both have been accepted to speak at RailsConf! Stephanie's presentation, titled "So, Writing Tests Feels Painful. What now?" aims to tackle the issues developers encounter with testing while offering actionable advice to ease these pains. Joël's session will focus on utilizing Turbo to create a Dungeons & Dragons character sheet, combining his passion for gaming with technical expertise.

+ +

Their conversation shifts to artificial intelligence and its potential in code refactoring and other applications, such as enhancing the code review process and solving complex software development problems. Joël shares his venture into combinatorics, illustrating how this mathematical approach helped him efficiently refactor a database query by systematically exploring and testing all potential combinations of query segments.

+ +

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, today I went out for a coffee on my bike, and I feel like I finally have my perfect, like, on-the-go coffee setup. We have this thoughtbot branded travel mug. So, it's one of the little bits of swag that we got from the company. It's, like, perfectly leak-proof. I'll link the brand in the show notes. But it's perfectly leak-proof, which is great. And on my bike, I have a little stem bag, so it's just, like, a tiny kind of, like, cylindrical bag that sits on the, like, vertical part of my handlebars that connects to the rest of my bag. And it's just, like, the perfect size for a 12-ounce coffee.

+ +

And so, I put my little travel mug in there, and I just had a very refreshing morning. And I'd gone out on my bike for a little bit, stopping by for coffee and headed home to work. And I got to drink my coffee during my first meeting. So, it was a wonderful way to start the day.

+ +

JOËL: Do you just show up at the coffee shop with your refillable mug and say, "Hey, can you pour some coffee in this?"

+ +

STEPHANIE: Yeah. I think a lot of coffee places are really amenable to bringing your own travel mugs. So yeah, it's really nice because I get to use less plastic. And also, you know, when you get a to-go mug, it is not leak-proof, right? It could just slosh all over the place and spill, so not bike-friendly. But yeah, bring your own mug. It's very easy.

+ +

JOËL: Excellent.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: Also, warm beverages. Who would have thought? It's almost like it's cold in North America or something. I've been really enjoying making myself tea in the afternoons recently. And I've been drinking this brand of tea that is a little bit extra. Every flavor of tea they have comes with a description of how the tea feels.

+ +

STEPHANIE: Ooh.

+ +

JOËL: I don't know who came up with these, but they're kind of funny. So, one that I particularly enjoy is described as feels like stargazing on an empty beach.

+ +

STEPHANIE: Wow. That's very specific.

+ +

JOËL: They also give you tasting notes. This one has tastes of candied violet, elderberry, blackberry, and incense.

+ +

STEPHANIE: Ooh, that sounds lovely. Are you drinking, like, herbal tea in the afternoon, or do you drink caffeinated tea?

+ +

JOËL: I'll do caffeinated tea. I limit myself to one pot of coffee that I brew in the morning, and then, whenever that's done, I switch to tea. Tea I allow myself anything: herbal, black tea; that's fine.

+ +

STEPHANIE: Yeah, I can't have too much caffeine in the afternoon either. But I do love an extra tea. I wish I could remember, like, what even was in this tea or what brand it was, but once I had a tea that was a purplish color. But then, when you squeeze some lemon in it, or I guess maybe anything with a bit of acid, it would turn blue.

+ +

JOËL: Oh, that's so cool.

+ +

STEPHANIE: Yeah, I'll have to find what this tea was [laughs] and update the podcast for any tea lovers out there. But yeah, it was just, like, a little bit of extra whimsy to your regular routine.

+ +

JOËL: I love adding a little whimsy to my day, even if it's just seeing a random animated GIF that a coworker has sent or Tuple has some of the, like, reactions you can send if you're pairing with someone. And I don't use those very often, so whenever one of those comes through, and it's like, ship it or yay, that makes me very happy.

+ +

STEPHANIE: Agreed.

+ +

JOËL: This week is really fun because as we were prepping for this episode, we both realized that there is a lot that's been new in our world recently. And Stephanie, in particular, you've got some pretty big news that recently happened to you.

+ +

STEPHANIE: Yeah, it turns out we're making the what's new in your world segment the entire episode today [laughs]. But my news is that I am speaking at RailsConf this year, so that is May 7th through 9th in Detroit. And so, yeah, I haven't spoken at a RailsConf before, only a RubyConf. So, I'm looking forward to it. My talk is called: So, Writing Tests Feels Painful. What now?

+ +

JOËL: Wait, is writing tests ever painful [laughs]?

+ +

STEPHANIE: Maybe not for you, but for the rest of us [laughs].

+ +

JOËL: No, it absolutely is. I, right before this recording, came from a pairing session where we were scratching our heads on an, like, awkward-to-write test. It happens to all of us.

+ +

STEPHANIE: Yeah. So, I was brainstorming topics, and I kind of realized, especially with a lot of our consulting experience, you know, we hear from developers or even maybe, like, engineering managers a lot of themes around like, "Oh, like, development is slowing down because our test suite is such a headache," or "It's really slow. It's really flaky. It's really complicated." And that is a pain point that a lot of tech leaders are also looking to address for their teams.

+ +

But I was really questioning this idea that, like, it always had to be some effort to improve the test suite, like, that had to be worked on at some later point or get, like, an initiative together to fix all of these problems, and that it couldn't just be baked into your normal development process, like, on an individual level. I do think it is really easy to feel a lot of pain when trying to write tests and then just be like, ugh, like, I wish someone would fix this, right? Or, you know, just kind of ignore the signals of that pain because you don't know, like, how to manage it yourself.

+ +

So, my talk is about when you do feel that pain, really trying to determine if there's anything you can do, even in just, like, the one test file that you're working in to make things a little bit easier for yourself, so it doesn't become this, like, chronic issue that just gets worse and worse. Is there something you could do to maybe reorganize the file as you're working in it to make some conditionals a little bit clearer?

+ +

Is there any, like, extra test setup that you're like, "Oh, actually, I don't need this anymore, and I can just start to get rid of it, not just for this one example, but for the rest in this file"? And do yourself a favor a little bit. So yeah, I'm excited to talk about that because I think that's perhaps, like, a skill that we don't focus enough on.

+ +

JOËL: Are you going to sort of focus in on the side of things where, like, a classic TDD mantra is that test pain reflects underlying code complexity? So, are you planning to focus on the idea of, oh, if you're feeling test pain, maybe take some time to refactor some of the code that's under test, maybe because there's some tight coupling? Or are you going to lean a little bit more into maybe, like, the Boy Scout rule, you know, 'Leave the campsite cleaner than you found it' for your test files?

+ +

STEPHANIE: Ooh, I like that framing. Definitely more of the former. But one thing I've also noticed working with a lot of client teams is that it's not always clear, like, how to refactor. I think a lot of intermediate developers start to feel that pain but don't know what to do about it. They don't know, like, maybe the code smells, or the patterns, or refactoring strategies, and that can certainly be taught. It will probably pull from that. But even if you don't know those skills yet, I'm wondering if there's, like, an opportunity to teach, like, developers at that level to start to reflect on the code and be like, "Hmm, what could I do to make this a little more flexible?"

+ +

And they might not know the names of the strategies to, like, extract a class, but just start to get them thinking about it. And then maybe when they come across that vocabulary later, it'll connect a lot easier because they'll have started to think about, you know, their experiences day to day with some of the more conceptual stuff.

+ +

JOËL: I really like that because I feel we've probably all heard that idea that test pain, especially when you're test driving, is a sign of maybe some anti-patterns or some code smells in the underlying code that you're testing. But translating that into something actionable and being able to say, "Okay, so my tests are painful. They're telling me something needs to be refactored. I'm looking at this code, and I don't know what to refactor." It's a big jump. It's almost the classic draw two circles; draw the rest of the owl meme. And so, I think bridging that gap is something that is really valuable for our community.

+ +

STEPHANIE: Yeah, that's exactly what I hope to do in my talk. So, Joël, you [chuckles] also didn't quite mention that you have big news as well.

+ +

JOËL: So, I also got accepted to speak at RailsConf. I'm giving a talk on Building a Dungeons & Dragons Character Sheet Using Turbo.

+ +

STEPHANIE: That's really awesome. I'm excited because I want to learn more about Turbo. I want someone else to tell me [laughs] what I can do with it. And as a person with a little bit of Dungeons & Dragons experience, I think a character sheet is kind of the perfect vehicle for that.

+ +

JOËL: Building a D&D character sheet has been kind of my go-to project to experiment with a new front-end framework because it's something that's pretty dynamic. And for those who don't know, there's a bunch of fields that you fill in with stats for different attributes that your character has, but then those impact other stats that get rendered. And sometimes there can be a chain two or three long where different numbers kind of combine together. And so, you've got this almost dependency tree of, like, a particular number.

+ +

Maybe your skill at acrobatics might depend on a number that you entered in the dexterity field, but it also depends on your proficiency bonus, and maybe also depends on the race that you picked and a few other things. And so, calculating those numbers all of a sudden becomes not quite so simple. And so, I find it's a really fun exercise to build when trying out a new interactive front-end technology.

+ +

STEPHANIE: Have you done this with a different implementation or a framework?

+ +

JOËL: I've done this, not completely, but I've attempted some parts of a D&D character sheet, I think, with Backbone.js with Ember. I may have done an Angular one at some point in original Angular, so Angular 1. I did this with Elm. Somehow, I skipped React. I don't think I did React to build a D&D character sheet. And now I'm kind of moving a little bit back to the backend. How much can we get done just with Turbo? Or do we need to pull in maybe Stimulus? These are all things that are going to be really fun to demonstrate.

+ +

STEPHANIE: Yeah. Speaking of injecting some whimsy earlier, I think it's kind of like just a little more fun than a regular to-do app, you know, or a blog to show how you can build, you know, something that people kind of understand with a different technology.

+ +

JOËL: Another really fun thing that I've been toying with this week has been using AI to help me refactor code. And this has been using just sort of a classic chat AI, not a tool like Copilot. And I was dealing with a query that was really slow, and I wanted to restructure it in a different way. And I described to the AI how I wanted it to refactor and explicitly said, "I want this to be the same before and after." And I asked it to do the refactor, and it gave me some pretty disappointing results where it did some, like, a couple of really obvious things that were not that useful.

+ +

And I was talking to a colleague about how I was really disappointed. I was thinking, well, AI should be able to do something better than this. And this colleague suggested changing the way I was asking for things and specifically asking for a step-by-step and asking it to prove every step using relational algebra, which is the branch of math that deals with everything that underlies relational databases, so the transformations that you would do where you keep everything the same, but you're saying, "Hey, these equations are all equivalent." And it sure did. It gave me a, like, 10-step process with all these, like, symbols and things.

+ +

My relational algebra is not that strong, and so I couldn't totally follow along. But then I asked it to give me a code example, like, show me the SQL at every step of this transformation and at the end. And, you know, it all kind of looked all right. I've not fully tested the final result it gave me to see if it does what it says on the tin. But I'm cautiously optimistic. I think it looks very similar to something that I came up with on my own. And so, I'm somewhat impressed, at least, like, much better than things were in the beginning with that first round. So, I'm really curious to see where I can take this.

+ +

STEPHANIE: Yeah, I think that's cool that you were able to prompt it differently and get something more useful. One of the reasons why I personally have been a little bit hesitant to get into the large language models is because I would love to see the AI show its work, essentially, like, tell me a little bit more about how it got from question to answer. And I thought that framing of kind of step-by-step show me code was a really interesting way, even to just, like, get some different results that do the same thing.

+ +

But you can kind of evaluate that a little bit more on your own rather than just using that first result that it gave you that was like, eh, like, I don't know if this really did anything for me. So, it would be cool, even if you don't end up using, like, the final one, right? If something along the way also is an improvement from what you started with that would be really interesting.

+ +

JOËL: Honestly, I think you kind of want the same thing if you're chatting with an AI chatbot or having a conversation in Slack with a colleague. They're just like, "Hey, can you help me refactor this?" And then a sort of, like, totally different chunk of code. And it's just like, "Trust me, it works."

+ +

STEPHANIE: [laughs].

+ +

JOËL: And maybe it does. Maybe you plug it into your codebase and run the tests against it, and the tests are still green. And so, you trust that it works, but you don't really understand where it came from. That doesn't always feel good, even when it comes from a human. So, what I've appreciated with colleagues has been when they've given me a step-by-step. Sometimes, they give me the final product. They just say, "Hey. Try this. Does this work?" Plug it in to the test. It does pass. It's green. Great. "Tell me what black magic you did to get to that."

+ +

And then they give me the step-by-step and it's like, oh, that's so good because not only do I get a better understanding of what happens at every step, but now I'm equipped the next time I run into this problem to apply the same technique to figure it out on my own.

+ +

STEPHANIE: Yeah. And I liked, also, that relational algebra pro tip, right? It kind of ensures that what you're getting makes sense or is equivalent along the way [laughs].

+ +

JOËL: We think, right? I don't know enough relational algebra to check its work. It is quite possible that it is making some subtle mistakes along the way, or, like, making inferences that it shouldn't be. I'm not going to say I trust that. But I think, specifically, when asking for SQL transformations, prompting it to do so using relational algebra in a step-by-step way seemed to be a way to get it to do something more reliably or at least give more interesting results.

+ +

STEPHANIE: Cool.

+ +

JOËL: I was interested in trying this out in part because I've been more curious about AI tools recently, and also because we're hoping to do a deeper dive into AI on a Bike Shed episode at some point later, so very much still in the gathering information phase. But this was a really cool experience. So, having an AI refactor a query for me using relational algebra, definitely something that's new in my world this week.

+ +

STEPHANIE: Speaking of refactoring and this idea of making improvements to your code and trying to figure out how to get from what you currently have to something new, I have been thinking a lot about how to make code reviews more actionable. And that's because, on my current client project, our team is struggling a little bit with code reviews, especially when you kind of want to give feedback on more of a design change in the code or thinking about some different abstractions. I have found that that is really hard to communicate async and also in a, like, a GitHub code review format where you can really just comment, like, line by line.

+ +

And I've found that, you know, when someone is leaving feedback, that's like, "I'm having a hard time reading this. And I'm imagining that we could organize the code a bit differently in these three different layers or abstractions," there's a lot of assumptions there, right [laughs]? That your message is being communicated to the author and that they are able to, like, visualize, or have a mental model for what you're explaining as well.

+ +

And then kind of what I've been seeing in this dynamic is, like, not really knowing what to do with that and to kind of just, like, I don't know where to go from here. So, I guess the next step is just to, like, merge it. Is that something you've experienced before or encountered when it comes to feedback?

+ +

JOËL: Broader changes are often challenging to explain, especially when they're...sometimes you get so abstract you can just write a quick paragraph. And sometimes it's like, hey, what if we, like, totally change our approach? I've definitely done the thing where I'll just ping someone and say, "Hey, can we talk about this synchronously? Can we get on a call and have a deeper conversation?"

+ +

How do you tend to approach if you're not going to hop on a call with someone and, like, have a 20 or 30-minute conversation? How do you approach doing that asynchronously on a pull request? Are you the type of person to put, like, a ton of, like, code blocks, like, "Here's what I was thinking. We could instead have this class and this thing"? And, like, pretty soon, it's, like, a page and a half of text. Or do you have another approach that you like to use?

+ +

STEPHANIE: Yeah. And I think that's where it can get really interesting. Because my process is, I'll usually just start commenting and maybe if I'm seeing some things that can be done differently. If it's not just, like, a really obvious change that I could just use English to describe, I'll add a little suggested change. But I also don't want to just rewrite this person's code [laughs] in a code review.

+ +

JOËL: That's the challenge, right?

+ +

STEPHANIE: Yeah. And I've definitely seen that be done before, too. Once I notice I'm at, like, four plus comments, and then they're not just, like, nitpicks about, like, syntax or something like that, that helps me clue into the idea that there is some kind of bigger change that I might be asking of the author. And I don't want to overwhelm them with, like, individual comments that really are trying to convey something more holistic.

+ +

JOËL: Right. I wonder if having a, like, specialized yet more abstract language is useful for these sorts of things where a whole paragraph in English or, you know, a ton of code examples might be a bit much. If you're able to say something like, "Hey, how would you feel about using a strategy pattern approach here instead of, you know, maybe a template object or some custom thing that we've built here?" that allows us to say a lot in a fairly sort of terse way. And it's the thing that you can leave more generically on the PR instead of, like, individually commenting in a bunch of places. And that can start a broader conversation at more of an architecture level.

+ +

STEPHANIE: Yes, I really like that. That's a great idea. I would follow that up with, like, I think at the end of the day, there are some conversations that do need to be had synchronously. And so, I like the idea of leaving a comment like that and just kind of giving them resources to learn what a strategy pattern is and then offering support because that's also a way to shorten that feedback loop of trying to communicate an idea. And I like that it's kind of guiding them, but also you're there to add some scaffolding if it ends up being, like, kind of a big ask for them to figure out what to do.

+ +

JOËL: There's also oftentimes, I think, a tone thing to manage where, especially if there's a difference in seniority or experience between the two people, it can be very easy for something to come across as an ask or a demand rather than a like, "Hey, let's think about some alternatives here." Or, like, "I have some concerns with your implementation. Let's sort of broadly explore some possible alternatives. Maybe a strategy pattern works."

+ +

But the person reading that who wrote the original code might be, like, receiving that as "Your code is bad. You should have done a strategy pattern instead." And that's not the conversation I want to have, right? I want to have a back-and-forth about, "Hey, what are the trade-offs involved? Do you have a third architecture you'd like to suggest?" And so, that can be a really tricky thing to avoid.

+ +

STEPHANIE: Yeah, I like that what you're saying also kind of suggested that it's okay if you don't have an idea yet for exactly how it should look like. Maybe you just are like, oh, like, I'm having a hard time understanding this, but I don't think just leaving it at that gives the author a lot to go on.

+ +

I think there's something to it about maybe the action part of actionable is just like, "Can you talk about it with me?" Or "Could you explain what you're trying to do here?" Or, you know, leave a comment about what this method is doing. There's a lot of ways, I think, that you can reach some amount of improvement, even if it doesn't end up being, like, the ideal code that you would write.

+ +

JOËL: Yes. There's also maybe a distinction in making it actionable by giving someone some code and saying, "Hey, you should copy-paste this code and make that..." or, you know, use a GitHub suggested code or something, which works on the small. And in the big, you can give some maybe examples and say, "Hey, what if you refactored in this way?"

+ +

But sometimes, you could even step back and let them do that work and say, "Hey, I have some concerns with the current architecture. It's not flexible in the ways that we need to be flexible. Here's my understanding of the requirements. And here's sort of how I see maybe this architecture not working with that. Let's think of some different ways we could approach this problem." And oftentimes, it's nice to give at least one or two different ideas to help start that. But it can be okay to just ask the person, "Hey, can you come up with some alternate implementations that would fulfill these sets of requirements?"

+ +

STEPHANIE: Yeah, I like that. And I can even see, like, maybe you do that work, and you don't end up pursuing it completely in addressing that feedback. But even asking someone to do the exercise itself, I think, can then spark new ideas and maybe other improvements.

+ +

In general, I like to think about...I'm a little hesitant to use this metaphor because I'm not actually giving code, like, letter grades when I review them, but the idea that, like, not all code has to get, like, an A [chuckles], but maybe getting it, like, from one letter grade up to, like, half a letter grade, like, higher, that is valuable, even if it's not always practical to go through multiple rounds of code review. And I think just making it actionable enough to be a little bit better, like, that is, in my opinion, the sweet spot.

+ +

JOËL: That's true. The sort of over-giving feedback to someone to try to get code perfect, rather than just saying, "Hey, can we make it slightly better?" And, you know, there are probably some minimum standards you need to hit. But at some point, it's a trade-off of like, how much time do we need to put polishing this versus shipping something?

+ +

STEPHANIE: Yeah, and I think that it is cumulative over time, right? That's how people learn. Yeah, it's like one of the biggest opportunities for developers to level up is from that feedback. And that's why I think it's important that it's actionable because, you know, and you put the time into, like, giving that review, and it's not just to make sure the code works, but it's also, like, one of the touch points for collaboration.

+ +

JOËL: So, if you had to summarize what makes code review comments actionable, do you have, like, top three tips that make a comment really actionable as opposed to something that's not helpful? Or maybe that's more of the journey that you're on, and you've not distilled it down to three pithy tips that you can put in a listicle.

+ +

STEPHANIE: Honestly, I think it does kind of just distill down to one, which is for every comment, you should have an idea of what you would like the author to do about it. And it's okay if it's nothing, but then tell them that it's nothing. You could just be expressing, "I thought this was kind of weird, [laughs]" or "This is not my favorite thing, but it's okay."

+ +

JOËL: And it can be okay for the thing you want the author to do. It doesn't have to be code. It could be a conversation.

+ +

STEPHANIE: Yeah, exactly. It could be a conversation. It could be asking for information, too, right? Like, "Did you consider alternatives, and could you share them with me?" But that request portion, I think is really important because, yeah, I think there's so much miscommunication that can happen along the way. So, definitely still trying to figure out how to best support that kind of code review culture on my team.

+ +

JOËL: This week's episode has been really fun because it's just been a combination of a lot of things that are new in our world, things that we've been trying, things that we've been learning. And kind of in an almost, like, a meta sense, one of the things I've been digging into is combinatorics, the branch of math that looks at how things combine and particularly how it works with combining a bunch of ActiveRecord query fragments where there's potential branching, so things like doing a union of two sort of sub queries or doing an or where you're combining two different where queries and trying to figure out what are the different paths through that.

+ +

STEPHANIE: Wow, what a great way to combine what we were talking about, Joël [laughs]. Did you apply combinatorics to this podcast episode [laughs]?

+ +

JOËL: Somehow, topics multiply with each other, something, something.

+ +

STEPHANIE: Yeah, that makes sense to me [laughs]. Okay. Will you tell me more about what you've been using it for in your queries?

+ +

JOËL: So, one thing I'm trying to do is because I've got these different branching paths through a query, I want to see sort of all the different ways because these are defined as ActiveRecord scopes, and I'm chaining them together. And it looks linear because I'm calling scope1 dot scope2 dot scope3. But each of those have branches inside of them. And so, there's all these different ways that data could get used or not.

+ +

And one way that I figured out, like, what are the different paths here, was actually drawing out a matrix, just putting together a table. In this case, I had two scopes, each of which had a two-way branch inside, and so I made a two by two matrix. And that gave me all of the combinations of, oh, if you go down one branch in one scope and down another branch in the other scope. And what I went through is then I went in in each square and filled in how many records I would expect to get back from the query from some basic set that I was working on in each of these combinations.

+ +

And one thing that was really interesting is that some of those combinations were sort of mutually exclusive, where a scope further down the line was filtering on the same field as an earlier one and would overwrite it or not overwrite it, but the two would then sort of you can't have both of those things be true at the same time. So, I'm looking for something that has a particular manager ID, and then I'm looking for something that has a particular different manager ID. And the way Rails combines these, if you just change scopes with where, is to and them together. There are no records that have both manager ID 1 and manager ID 2. You can only have one manager ID.

+ +

And so, as I'm filling out my matrix, there's some sections I can just zero out and be like, wait, this will always return zero record. And then I can start focusing on the parts that are not zeroed out. So, I've got two or three squares. What's special about those? And that helped me really understand what the combination of these multiple query fragments together were actually trying to do as a holistic whole.

+ +

STEPHANIE: Wow, yeah, that is really interesting because I hear you when you say it looks linear. And it would be really surprising to me for there to be branching paths. Like, that's not really what I think about when I think about SQL. But that makes a lot of sense that it could get so complicated that it's just impossible to get a certain kind of result. Like, what's going to be the outcome of applying combinatorics to this? Is there a refactoring opportunity, or is it really just to even understand what's going on?

+ +

JOËL: So, this was a refactoring that I was trying to do, but I didn't really understand the underlying behavior of the chain of scopes. I just knew that they were doing some complex things that were inefficient from a SQL perspective. And so, I was looking at ways to refactor, but I also wanted to get a sense of what is this actually trying to do other than just chaining a bunch of random bits of code together? So, the matrix really helped for that.

+ +

The other way that I used it was to write some tests because this query I was trying to refactor, this chain of scopes, was untested. And I wanted to write tests that were very thorough because I wanted to make sure that my refactor didn't break any edge cases. And I'm, you know, writing a few tests. Okay, well, here's a record that I definitely want to get returned by this query, and maybe here are a couple of records I don't want to get returned.

+ +

And the more I was, like, going into this and trying to write test cases, the more I was finding more edge cases that I didn't want to and, oh, but what about this? And what about the combination of these things? And it got to the point where it was just messing with my mind. I was, like, confusing myself and really struggling to write tests that would do anything useful.

+ +

STEPHANIE: Wow. Yeah. Honestly, I have already started to become a little bit suspicious of complex scopes, and this further pushes me in that direction [laughs] because yeah, once you start to...like, the benefit of them is that you can chain them, but it really hides a lot of the underlying behavior. So, you can easily just turn yourself around or, like, go, you know, kind of end up [laughs] in a little bit of a bind.

+ +

JOËL: Definitely, especially once it grows a little bit harder to hold in your head. And I don't know exactly where that level is for me. But in this particular situation, I identified, I think, five different dimensions that would impact the results of this query. And then each dimension had maybe three or four different values that we might care about. And, eventually, I just took the time to write this out.

+ +

So, I created five arrays and then just said, "Hey, here are the different managers that we care about. Here are the different project types we care about. Here are the different..." and we had, like, five of these, and each array had three or four elements in it. And then, in a series of nested loops, I iterated through all of these arrays and at the innermost loop, created the data that I wanted that matched that particular set of values.

+ +

Now, we're often told you should not be doing things in nested loops because you end up sort of multiplying all of these together, but, in this case, this is actually what I wanted to do. You know, it turns out that I had a hundred-ish records I had to create to sort of create a data set that would be all the possible edge cases I might want to filter on. And creating them all by hand with all of the different variations was going to be too much. And so, I ended up doing this with arrays and nested loops. And it got me the data that I needed. And it gave me then the confidence to know that my refactor did indeed work the way I was expecting.

+ +

STEPHANIE: Wow. That's truly hero's work [chuckles]. I'm, like, very excited because it sounds like that's a huge opportunity for some performance improvements as well.

+ +

JOËL: For the underlying code, yes. The test might be a little bit slow because I'm creating a hundred records in the database. And you might say, "Oh, do you really need to do that? Can you maybe collapse some of these cases?" In this particular case, I really wanted to have high confidence that the refactor was not changing anything. And so, I was okay creating a hundred records over a series of nested iterations. That was a price I was willing to pay. The refactored query, it turns out, I was able to write it in a way that was significantly faster.

+ +

STEPHANIE: Yeah, that's what I suspected.

+ +

JOËL: So, I had to rewrite it in a way that didn't take advantage of all the change scopes. I had to just sort of write something custom from scratch, which is often the case, right? Performance and reusability sometimes fight against each other, and it's a trade-off. So, I'm not reusing the scopes. I had to write something from scratch, but it's multiple hundreds of times faster.

+ +

STEPHANIE: Wow. Yeah. That seems worth it for a slow test [laughs] for the user experience to be a lot better, especially when you just reach that level of complexity. And it's a really awesome strategy that you applied to figure that out. I think it's a very unique one [laughs]. That's for sure.

+ +

JOËL: I've had an interest in sort of analytical tools to help me understand domain models, to help understand problems, to help understand code that I'm working with for a while now, and I think an understanding of combinatorics fits into that. And then, particular tools within that, such as drawing things out in a table, in a two by two matrix, or an end-by-end matrix to get something visual, that's a great tool for debugging or understanding a problem.

+ +

Thinking of problems as data that exists in multiple dimensions and then asking about the cardinality of that set it's the kind of analysis I did a lot when I was modeling using algebraic data types in Elm. But now I've sort of taken some of the tools and analysis I use from that world into thinking about things like SQL records, things like dealing with data in Ruby. And I'm able to bring those tools and that way of thinking to help me solve some problems that I might struggle to solve otherwise.

+ +

For any of our listeners who this, like, kind of piques their interest, combinatorics falls under a broader umbrella of mathematics called discrete math. And within that, there's a lot that I think is really useful, a lot of tools and techniques that we can apply to our day-to-day programming. We have a Bike Shed episode where we talked about is discrete math relevant to day-to-day programmers and what are the ways it's so? We'll link that in the show notes. I also gave a talk at RailsConf last year diving into that titled: The Math Every Programmer Needs. So, if you're looking for something that's accessible to someone who's not done a math degree, those are two great jumping-off points.

+ +

STEPHANIE: Yeah. And then, maybe you'll start drawing out arrays and applying combinatorics to figure out your performance problems.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+RE-ewrLc + + ]]> + + Joël Quenneville + Stephanie Minn + + + 418: Mental Models For Reduce Functions + https://bikeshed.thoughtbot.com/418 + 44552974-33ae-4cdf-9ad5-bf9dbff5a4d3 + Tue, 12 Mar 2024 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël talks about his difficulties optimizing queries in ActiveRecord, especially with complex scopes and unions, resulting in slow queries. He emphasizes the importance of optimizing subqueries in unions to boost performance despite challenges such as query duplication and difficulty reusing scopes. Stephanie discusses upgrading a client's app to Rails 7, highlighting the importance of patience, detailed attention, and the benefits of collaborative work with a fellow developer. + +The conversation shifts to Ruby's reduce method (inject), exploring its complexity and various mental models to understand it. Joël and Stephanie discuss when it's preferable to use reduce over other methods like each, map, or loops and the importance of understanding the underlying operation you wish to apply to two elements before scaling up with reduce. The episode also touches on monoids and how they relate to reduce, suggesting that a deep understanding of functional programming concepts can help simplify reduce expressions. + 42:50 + no + + + Joël talks about his difficulties optimizing queries in ActiveRecord, especially with complex scopes and unions, resulting in slow queries. He emphasizes the importance of optimizing subqueries in unions to boost performance despite challenges such as query duplication and difficulty reusing scopes. Stephanie discusses upgrading a client's app to Rails 7, highlighting the importance of patience, detailed attention, and the benefits of collaborative work with a fellow developer. +The conversation shifts to Ruby's reduce method (inject), exploring its complexity and various mental models to understand it. Joël and Stephanie discuss when it's preferable to use reduce over other methods like each, map, or loops and the importance of understanding the underlying operation you wish to apply to two elements before scaling up with reduce. The episode also touches on monoids and how they relate to reduce, suggesting that a deep understanding of functional programming concepts can help simplify reduce expressions. +Rails 7 EXPLAIN ANALYZE (https://www.bigbinary.com/blog/rails-7-1-adds-options-to-activerecord-relation-explain) +Blocks, symbol to proc, and symbols arguments for reduce (https://thoughtbot.com/blog/blocks-procs-and-enumerable) +Ruby tally (https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a5fb11ea) +Performance considerations for reduce in JavaScript (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#when_to_not_use_reduce) +Persistant data structures (https://www.youtube.com/watch?v=gTClDj9Zl1g) +Avoid passing a block to map and reduce (https://thoughtbot.com/blog/avoid-putting-logic-in-map-blocks) +Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (https://ris.utwente.nl/ws/portalfiles/portal/6142049/meijer91functional.pdf) +monoids (https://blog.ploeh.dk/2017/10/06/monoids/) +iteration anti-patterns (https://thoughtbot.com/blog/iteration-as-an-anti-pattern) +Joël’s talk on “constructor replacement” (https://www.youtube.com/watch?v=dSMB3rsufC8) +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: I've been doing a bunch of fiddling with query optimization this week, and I've sort of run across an interesting...but maybe it's more of an interesting realization because it's interesting in the sort of annoying way. And that is that, using ActiveRecord scopes with certain more complex query pieces, particularly unions, can lead to queries that are really slow, and you have to rewrite them differently in a way that's not reusable in order to make them fast. +In particular, if you have sort of two other scopes that involve joins and then you combine them using a union, you're unioning two sort of joins. Later on, you want to change some other scope that does some wares or something like that. That can end up being really expensive, particularly if some of the underlying tables being joined are huge. Because your database, in my case, Postgres, will pull a lot of this data into the giant sort of in-memory table as it's, like, building all these things together and to filter them out. And it doesn't have the ability to optimize the way it would on a more traditional relation. +A solution to this is to make sure that the sort of subqueries that are getting unioned are optimized individually. And that can mean moving conditions that are outside the union inside. So, if I'm chaining, I don't know, where active is true on the outer query; on the union itself, I might need to move that inside each of the subqueries. So, now, in the two or three subqueries that I'm unioning, each of them needs to have a 'where active true' chained on it. +STEPHANIE: Interesting. I have heard this about using ActiveRecord scopes before, that if the scopes are quite complex, chaining them might not lead to the most performant query. That is interesting. By optimizing the subqueries, did you kind of change the meaning of them? Was that something that ended up happening? +JOËL: So, the annoying thing is that I have a scope that has the union in it, and it does some things sort of on its own. And it's used in some places. There are also other places that will try to take that scope that has the union on it, chain some other scopes that do other joins and some more filters, and that is horribly inefficient. So, I need to sort of rewrite the sort of subqueries that get union to include all these new conditions that only happen in this one use case and not in the, like, three or four others that rely on that union. +So, now I end up with some, like, awkward query duplication in different call sites that I'm not super comfortable about, but, unfortunately, I've not found a good way to make this sort of nicely reusable. Because when you want to chain sort of more things onto the union, you need to shove them in, and there's no clean way of doing that. +STEPHANIE: Yeah. I think another way I've seen this resolved is just writing it in SQL if it's really complex and it becoming just a bespoke query. We're no longer trying to use the scope that could be reusable. +JOËL: Right. Right. In this case, I guess, I'm, like, halfway in between in that I'm using the ActiveRecord DSL, but I am not reusing scopes and things. So, I sort of have the, I don't know, naive union implementation that can be fine in all of the simpler use cases that are using it. And then the query that tries to combine the union with some other fancy stuff it just gets its own separate implementation different than the others that it has optimized. So, there are sort of two separate paths, two separate implementations. I did not drop down to writing raw SQL because I could use the ActiveRecord DSL. So, that's what I've been working with. +What's new in your world this week? +STEPHANIE: So, a couple of weeks ago, I think, I mentioned that I was working on a Rails 7 upgrade, and we have gotten it out the door. So, now the client application I'm working on is on Rails 7, which is exciting for the team. But in an effort to make the upgrade as incremental as possible, we did, like, back out of a few of the new application config changes that would have led us down a path of more work. And now we're kind of following up a little bit to try to turn some of those configs on to enable them. +And it was very exciting to kind of, like, officially be on Rails 7. But I do feel like we tried to go for, like, the minimal amount of work possible in that initial big change. And now we're having to kind of backfill a little bit on some of the work that was a little bit more like, oh, I'm not really sure, like, how big this will end up being. +And it's been really interesting work, I think, because it requires, like, two different mindsets. Like, one of them is being really patient and focused on tedious work. Like, okay, what happens when we enable this config option? Like, what changes? What errors do we see? And then having to turn it back off and then go in and fix them. +But then another, I think, like, headspace that we have to be in is making decisions about what to do when we come to a crossroads around, like, okay, now that we are starting to see all the changes that are coming about from enabling this config, is this even what we want to do? And it can be really hard to switch between those two modes of thinking. +JOËL: Yeah. How do you try to balance between the two? +STEPHANIE: So, I luckily have been pairing with another dev, and I've actually found that to be really effective because he has, I guess, just, like, a little bit more of that patience to do the more tedious, mundane [laughs] aspects of, like, driving the code changes. And I have been riding along. +But then I can sense, like, once he gets to the point of like, "Oh, I'm not sure if we should keep going down this road," I can step in a little bit more and be like, "Okay, like, you know, I've seen us do this, like, five times now, and maybe we don't want to do that." Or maybe being like, "Okay, we don't have a really clear answer, but, like, who can we talk to to find out a little bit more or get their input?" +And that's been working really well for me because I've not had a lot of energy to do more of that, like, more manual or tedious labor [chuckles] that comes with working on that low level of stuff. So yeah, I've just been pleasantly surprised by how well we are aligning our superpowers. +JOËL: To use some classic business speech, how does it feel to be in the future on Rails 7? +STEPHANIE: Well, we're not quite up, you know, up to modern days yet, but it does feel like we're getting close. And, like, I think now we're starting to entertain the idea of, like, hmm, like, could we be even on main? I don't think it's really going to happen, but it feels a little bit more possible. And, in general, like, the team thinks that that could be, like, really exciting. Or it's easier, I think, once you're a little bit more on top of it. Like, the worst is when you get quite behind, and you end up just feeling like you're constantly playing catch up. It just feels a little bit more manageable now, which is good. +JOËL: I learned this week a fun fact about Rails 7.1, in particular, which is that the analyze method on ActiveRecord queries, which allowed you to sort of get SQL EXPLAIN statements, now has the ability to pass in a couple of extra parameters. So, there are symbols, and you can pass in things like analyze or verbose, which allows you to get sort of more data out of your EXPLAIN query, which can be quite nice when you're debugging for performance. +So, if you're in the future and you're on Rails 7.1 and you want sort of the in-depth query plans, you don't need to copy the SQL into a Postgres console to get access to the sort of fully developed EXPLAIN plan. You can now do it by passing arguments to EXPLAIN, which I'm very happy for. +STEPHANIE: That's really nice. +JOËL: So, we've mentioned before that we have a developers' channel on Slack here at thoughtbot, and there's all sorts of fun conversations that happen there. And there was one recently that really got me interested, where people were talking about Ruby's reduce method, also known as inject. And it's one of those methods that's kind of complicated, or it can be really confusing. +And there was a whole thread where people were talking about different mental models that they had around the reduce method and how they sort of understand the way it works. And I'd be curious to sort of dig into each other's mental models of that today. To kick us off, like, how comfortable do you feel with Ruby's reduce method? And do you have any mental models to kind of hold it in your head? +STEPHANIE: Yeah, I think reduce is so hard to wrap your head around, or it might be one of the most difficult, I guess, like, functions a new developer encounters, you know, in trying to understand the tools available to them. I always have to look up the order of the arguments [laughs] for reduce. +JOËL: Every time. +STEPHANIE: Yep. But I feel like I finally have a more intuitive sense of when to use it. And my mental model for it is collapsing a collection into one value, and, actually, that's why I prefer calling it reduce rather than the inject alias because reduce kind of signals to me this idea of going from many things to one canonical thing, I suppose. +JOËL: Yeah, that's a very common use case for reducing, and I guess the name itself, reducing, kind of has almost that connotation. You're taking many things, and you're going to reduce that down to a single thing. +STEPHANIE: What was really interesting to me about that conversation was that some people kind of had the opposite mental model where it made a bit more sense for them to think about injecting and, specifically, like, the idea of the accumulator being injected with values, I suppose. And I kind of realized that, in some ways, they're kind of antonyms [chuckles] a little bit because if you're focused on the accumulator, you're kind of thinking about something getting bigger. And that kind of blew my mind a little bit when I realized that, in some ways, they can be considered opposites. +JOËL: That's really fascinating. It is really interesting, I think, the way that we can take the name of a method and then almost, like, tell ourselves a story about what it does that then becomes our way of remembering how this method works. And the story we tell for the same method name, or in this case, maybe there's a few different method names that are aliases, can be different from person to person. +I know I tend to think of inject less in terms of injecting things into the accumulator and more in terms of injecting some kind of operator between every item in the collection. So, if we have an array of numbers and we're injecting plus, in my mind, I'm like, oh yeah, in between each of the numbers in the collection, just inject a little plus sign, and then do the math. We're summing all the items in the collection. +STEPHANIE: Does that still hold up when the operator becomes a little more complex than just, you know, like, a mathematical operator, like, say, a function? +JOËL: Well, when you start passing a block and doing custom logic, no, that mental model kind of falls apart. In order for it to work, it also has to be something that you can visualize as some form of infix operator, something that goes between two values rather than, like, a method name, which is typically in prefix position. +I do want to get at this idea, though: the difference between sort of the block version versus passing. There are ways where you can just do a symbol, and that will call a method on each of the items. Because I have a bit of a hot take when it comes to writing reduce blocks or inject blocks that are more accessible, easier to understand. +And that is, generally, that you shouldn't, or more specifically, you should not have a big block body. In general, you should be either using the symbol version or just calling a method within the block, and it's a one-liner. Which means that if you have some complex behavior, you need to find a way to move that out of this sort of collection operation and into instance methods on the objects being iterated. +STEPHANIE: Hmm, interesting. By one-liner do you mean passing the name of the method as a proc or actually, like, having your block that then calls the method? Because I can see it becoming even simpler if you have already extracted a method. +JOËL: Yeah, if you can do symbol to proc, that's amazing, or even if you can use just the straight-up symbol way of invoking reduce or inject. That typically means you have to start thinking about the types of objects that you are working with and what methods can be moved onto them. And sometimes, if you're working with hashes or something like that that don't have domain methods for what you want, that gets really awkward. And so, then maybe that becomes maybe a hint that you've got some primitive obsession happening and that this hash that sort of wants a domain object or some kind of domain method probably should be extracted to its own object. +STEPHANIE: I'll do you with another kind of spicy take. I think, in that case, maybe you don't want a reduce at all. If you're starting to find that...well, okay, I think it maybe could depend because there could be some very, like, domain-specific logic. But I have seen reduce end up being used to transform the structure of the initial collection when either a different higher-order function can be used or, I don't know, maybe you're just better off writing it with a regular loop [laughs]. It could be clearer that way. +JOËL: Well, that's really interesting because...so, you mentioned the idea that we could use a different higher-order function, and, you know, higher-order function is that fancy term, just a method that accepts another method as an argument. In Ruby, that just means your method accepts a block. Reduce can be used to implement pretty much the entirety of enumerable. Under the hood, enumerable is built in terms of each. You could implement it in terms of reduce. +So, sometimes it's easy to re-implement one of the enumerable methods yourself, accidentally, using reduce. So, you've written this, like, complex reduce block, and then somebody in review comes and looks at it and is like, "Hey, you realize that's just map. You've just recreated map. What if we used map here?" +STEPHANIE: Yeah. Another one I've seen a lot in JavaScript land where there are, you know, fewer utility functions is what we now have in Ruby, tally. I feel like that was a common one I would see a lot when you're trying to count instances of something, and I've seen it done with reduce. I've seen it done with a for each. And, you know, I'm sure there are libraries that actually provide a tally-like function for you in JS. But I guess that actually makes me feel even more strongly about this idea that reduce is best used for collapsing something as opposed to just, like, transforming a data structure into something else. +JOËL: There's an interesting other mental model for reduce that I think is hiding under what we're talking about here, and that is the idea that it is a sort of mid-level abstraction for dealing with collections, as opposed to something like map or select or some of those other enumerable helpers because those can all be implemented in terms of reduce. And so, in many cases, you don't need to write the reduce because the library maintainer has already used reduce or something equivalent to build these higher-level helpers for you. +STEPHANIE: Yeah, it's kind of in that weird point between, like, very powerful [chuckles] so that people can start to do some funky things with it, but also sometimes just necessary because it can feel a little bit more concise that way. +JOËL: I've done a fair amount of functional programming in languages like Elm. And there, if you're building a custom data structure, the sort of lowest-level way you have of looping is doing a recursion, and recursions are messy. And so, what you can do instead as a library developer is say, "You know what, I don't want to be writing recursions for all of these." I don't know; maybe I'm building a tree library. I don't want to write a recursion for every different function that goes over trees if I want to map or filter or whatever. I'm going to write reduce using recursion, and then everything else can be written in terms of reduce. +And then, if people want to do custom things, they don't need to recurse over my tree. They can use this reduce function, which allows them to do most of the traversals they want on the tree without needing to touch manual recursion. So, there's almost, like, a low-level, mid-level, high-level in the library design, where, like, lowest level is recursion. Ideally, nobody touches that. Mid-level, you've got reducing that's built out on top of recursion. And then, on top of that, you've got all sorts of other helpers, like mapping, like filtering, things like that. +STEPHANIE: Hmm. I'm wondering, do you know of any performance considerations when it comes to using reduce built off a recursion? +JOËL: So, one of the things that can be really nice is that writing a recursion yourself is dangerous. It's so easy to, like, accidentally introduce Stack Overflow. You could also write a really inefficient one. So, ideally, what you do is that you write a reduce that is safe and that is fast. And then, everybody else can just use that to not have to worry about the sort of mechanics of traversing the collection. And then, just use this. It already has all of the safety and speed features built in. You do have to be careful, though, because reduce, by nature, traverses the entire collection. And if you want to break out early of something expensive, then reduce might not be the tool for you. +STEPHANIE: I was also reading a little bit about how, in JavaScript, a lot of developers like to stick to that idea of a pure function and try to basically copy the entire accumulator for every iteration and creating a new object for that. And that has led to some memory issues as well. As opposed to just mutating the accumulator, having, especially when you, you know, are going through a collection, like, really large, making that copy every single time and creating, yeah [chuckles], just a lot of issues that way. So, that's kind of what prompted that question. +JOËL: Yeah, that can vary a lot by language and by data structure. In more functional languages that try to not mutate, they often have this idea of what they call persistent data structures, where you can sort of create copies that have small modifications that don't force you to copy the whole object under the hood. They're just, like, pointers. So, like, hey, we, like, are the same as this other object, but with this extra element added, or something like that. So, if you're growing an array or something like that, you don't end up with 10,000 copies of the array with, like, a new element every time. +STEPHANIE: Yeah, that is interesting. And I feel like trying to adopt different paradigms for different tools, you know, is not always as straightforward as some wish it were [laughs]. +JOËL: I do want to give a shout-out to an academic paper that is...it is infamously dense. The title of it is Functional Programming with Bananas, Lenses, and Barbed Wire. +STEPHANIE: It doesn't sound dense; it sounds fun. Well, I don't about barbed wire. +JOËL: It sounds fun, right? +STEPHANIE: Yeah, but certainly quirky [laughs]. +JOËL: It is incredibly dense. And they've, like, created this custom math notation and all this stuff. But the idea that they pioneered there is really cool, this idea that kind of like I was talking about sort of building libraries in different levels. Their idea is that recursion is generally something that's unsafe and that library and language designers should take care of all of the recursion and instead provide some of these sort of mid-level helper methods to do things. Reducing is one of them, but their proposal is that it's not the only one. There's a whole sort of family of similar methods that are there that would be useful in different use cases. +So, reduce allows you to sort of traverse the whole thing. It does not allow you to break out early. It does not allow you to keep sort of track of a sort of extra context element if you want to, like, be traversing a collection but have a sort of look forward, look back, something like that. So, there are other variations that could handle those. There are variations that are the opposite of reduce, where you're, like, inflating, starting from a few parameters and building a collection out of them. +So, this whole concept is called recursion schemes, and you can get, like, really deep into some theory there. You'll hear fancy words like catamorphisms and anamorphisms. There's a whole world to explore in that area. But at its core, it's this idea that you can sort of slice up things into this sort of low-level recursion, mid-level helpers, and then, like, kind of userland helpers built on top of that. +STEPHANIE: Wow. That is very intense; it sounds like [chuckles]. I'm happy not to ever have to write a recursion ever again, probably [laughs]. Have you ever, as just a web developer in your day-to-day programming, found a really good use case for dropping down to that level? Or are you kind of convinced that, like, you won't really ever need to? +JOËL: I think it depends on the paradigm of the language you're working in. In Ruby, I've very rarely needed to write a recursion. In something like Elm, I've had to do that, eh, not infrequently. Again, it depends, like, if I'm doing more library-esque code versus more application code. If I'm writing application code and I'm using an existing, let's say, tree library, then I typically don't need to write a recursion because they've already written traversals for me. If I'm making my own and I have made my own tree libraries, then yes, I'm writing recursions myself and building those traversals so that other people don't have to. +STEPHANIE: Yeah, that makes sense. I'd much rather someone who has read that paper [laughs] write some traversal methods for me. +JOËL: And, you know, for those who are curious about it, we will put a link to this paper in the description. +So, we've talked about a sort of very academic mental model way of thinking about reducing. I want to shift gears and talk about one that I have found is incredibly practical, and that is the idea that reduce is a way to scale an operation that works on two objects to an operation that works on sort of an unlimited number of objects. +To make it more concrete, take something like addition. I can add two numbers. The plus operator allows me to take one number, add another, get a sum. But what if I want to not just add two numbers? I want to add an arbitrary number of numbers together. Reduce allows me to take that plus operator and then just scale it up to as many numbers as I want. I can just plug that into, you know, I have an array of numbers, and I just call dot reduce plus operator, and, boom, it can now scale to as many numbers as I want, and I can sum the whole thing. +STEPHANIE: That dovetails quite nicely with your take earlier about how you shouldn't pass a block to reduce. You should extract that into a method. Don't you think? +JOËL: I think it does, yes. And then maybe it's, like, sort of two sides of a coin because I think what this leads to is an approach that I really like for reducing because sometimes, you know, here, I'm starting with addition. I'm like, oh, I have addition. Now, I want to scale it up. How do I do that? I can use reduce. Oftentimes, I'm faced with sort of the opposite problem. I'm like, oh, I need to add all these numbers together. How do I do that? I'm like, probably with a reduce. But then I start writing the block, and, like, I get way too into my head about the accumulator and what's going to happen. +So, my strategy for writing reduce expressions is to, instead of trying to figure out how to, like, do the whole thing together, first ask myself, how do I want to combine any two elements that are in the array? So, I've got an array of numbers, and I want to sum them all. What is the thing I need to do to combine just two of those? Forget the array. Figure that out. +And then, once I have that figured out, maybe it's an existing method like plus. Maybe it's a method I need to define on it if it's a custom object. Maybe it's a method that I write somewhere. Then, once I have that, I can say, okay, I can do it for two items. Now, I'm going to scale it up to work for the whole array, and I can plug it into reduce. And, at that point, the work is already basically done, so I don't end up with a really complex block. I don't end up, like, almost ending in, like, a recursive infinite loop in my head because I do that. +STEPHANIE: [laughs]. +JOËL: So, that approach of saying, start by figuring out what is the operation you want to do to combine two elements, and then use reduce as a way to scale that to your whole array is a way that I've used to keep things simple in my mind. +STEPHANIE: Yeah, I like that a lot as a supplement to the model I shared earlier because, for me, when I think about reducing as, like, collapsing into a value, you kind of are just like, well, okay, I start with the collection, and then somehow I get to my single value. But the challenge is figuring out how that happens [laughs], like, the magic that happens in between that. +And I think another alias that we haven't mentioned yet for reduce that is used in a lot of other languages is fold. And I actually like that one a lot, and I think it relates to your mental model. Because when I think about folding, I'm picturing folding up a paper like an accordion. And you have to figure out, like, what is the first fold that I can make? And just repeating that over and over to get to your little stack of accordion paper [laughs]. And if you can figure out just that first step, then you pretty much, like, have the recipe for getting from your initial input to, like, your desired output. +JOËL: Yeah. I think fold is interesting in that some languages will make a distinction between fold and reduce. They will have both. And typically, fold will require you to pass an initial value, like a starting accumulator, to start it off. Whereas reduce will sort of assume that your array can use the first element of the array as the first accumulator. +STEPHANIE: Oh, I just came up with another visual metaphor for this, which is, like, folding butter into croissant pastry when the butter is your initial value [laughs]. +JOËL: And then the crust is, I guess, the elements in the array. +STEPHANIE: Yeah. Yeah. And then you get a croissant out of it [laughs]. Don't ask me how it gets to a perfectly baked, flaky, beautiful croissant, but somehow that happens [laughs]. +JOËL: So, there's an interesting sort of subtlety here that I think happens because there are sort of two slightly different ways that you can interact with a reduce. Sometimes, your accumulator is of the same type as the elements in your array. So, you're summing an array of numbers, and your accumulator is the sum, but each of the elements in the array are also numbers. So, it's numbers all the way through. And sometimes, your accumulator has a different type than the items in the array. So, maybe you have an array of words, and you want to get the sum of all of the characters and all the words. And so, now your accumulator is a number, but each of the items in the array are strings. +STEPHANIE: Yeah, that's an interesting distinction because I think that's where you start to see the complex blocks being passed and reduced. +JOËL: The complex blocks, definitely; I think they tend to show up when your accumulator has a different type than the individual items. So, maybe that's, like, a slightly more complicated use case. Oftentimes, too, the accumulator ends up being some, like, more complex, like, hash or something that maybe would really benefit from being a custom object. +STEPHANIE: I've never done that before, but I can see why that would be really useful. Do you have an example of when you used a custom object as the accumulator? +JOËL: So, I've done it for situations where I'm working with objects that are doing tally-like operations, but I'm not doing just a generic tally. There's some domain-specific stuff happening. So, it's some sort of aggregate counter on multiple dimensions that you can use, and that can get really ugly. And you can either do it with a reduce or you can have some sort of, like, initial version of the hash outside and do an each and mutate the hash and stuff like that. All of these tend to be a little bit ugly. So, in those situations, I've often created some sort of custom object that has some instance methods that allow to sort of easily add new elements to it. +STEPHANIE: That's really interesting because now I'm starting to think, what if the elements in the collection were also a custom object? [chuckles] And then things could, I feel like, could be really powerful [laughs]. +JOËL: There's often a lot of value, right? Because if the items in the collection are also a custom object, you can then have methods on them. And then, again, the sort of complexity of the reduce can sort of, like, fade away because it doesn't own any of the logic. All it does is saying, hey, there's a thing you can do to combine two items. Let's scale it up to work on a collection of items. And now you've sort of, like, really simplified what logic is actually owned inside the reduce. +I do want to shout out for those listeners who are theory nerds and want to dig into this. When you have a reduce, and you've got an operation where all the values are of the same type, including the accumulator, typically, what you've got here is some form of monoid. It may be a semigroup. So, if you want to dig into some theory, those are the words to Google and to go a deep dive on. +The main thing about monoids, in particular, is that monoids are any objects that have both a sort of a base case, a sort of empty version of themselves, and they have some sort of combining method that allows you to combine two values of that type. If your object has these things and follows...there's a few rules that have to be true. You have a monoid. And they can then be sort of guaranteed to be folded nicely because you can plug in their base case as your initial accumulator. And you can plug in their combining method as just the value of the block, and everything else just falls into place. +A classic here is addition for numbers. So, if you want to add two numbers, your combining operator is a plus. And your sort of empty value is a zero. So, you would say, reduce initial value is zero, array of numbers. And your block is just plus, and it won't sum all of the numbers. You could do something similar with strings, where you can combine strings together with plus, and, you know, your empty string is your base case. So, now you're doing sort of string concatenation over arbitrary number of strings. +Turns out there's a lot of operations that fall into that, and you can even define some of those on your custom object. So, you're like, oh, I've got a custom object. Maybe I want some way of, like, combining two of them together. You might be heading in the direction of doing something that is monoidal, and if so, that's a really good hint to know that it can sort of, like, just drop into place with a fold or a reduce and that that is a tool that you have available to you. +STEPHANIE: Yeah, well, I think my eyes, like, widened a little bit when you first dropped the term monoid [laughs]. I do want to spend the last bit of our time talking about when not to use reduce, and, you know, we did talk a lot about recursion. But when do you think a regular old loop will just be enough? +JOËL: So, you're suggesting when would you want to use something like an each rather than a reduce? +STEPHANIE: Yeah. In my mind, you know, you did offer, like, a lot of ways to make reduce simpler, a lot of strategies to end up with some really nice-looking syntax [chuckles], I think. But, oftentimes, I think it can be equally as clear storing your accumulator outside of the iteration and that, like, is enough for me to understand. And reduce takes a little bit of extra overhead to figure out what I'm looking at. Do you have any thoughts about when you would prefer to do that? Or do you think that you would usually reach for something else? +JOËL: Personally, I generally don't like the pattern of using each to iterate over a collection and then mutate some external accumulator. That, to me, is a bit of a code smell. It's a sign that each is not quite powerful enough to do the thing that I want to do and that I'm probably needing some sort of more specialized form of iteration. Sometimes, that's reduce. Oftentimes, because each can suffer from the same problem you mentioned from reduce, where it's like, oh, you're doing this thing where you mutate an external accumulator. Turns out what you're really doing is just map. So, use map or use select or, you know, some of the other built-in iterators from the enumerable library. +There's a blog post on the thoughtbot blog that I continually link to people. And when I see the pattern of, like, mutating an external variable with each, yeah, I tend to see that as a bit of a code smell. I don't know that I would never do it, but whenever I see that, it's a sign to me to, like, pause and be like, wait a minute, is there a better way to do this? +STEPHANIE: Yeah, that's fair. I like the idea that, like, if there's already a method available to you that is more specific to go with that. But I also think that sometimes I'd rather, like, come across that pattern of mutating a variable outside of the iteration over, like, someone trying to do something clever with the reduce. +JOËL: Yeah, I guess reduce, especially if it's got, like, a giant block and you've got then, like, things in there that break or call next to skip iterations and things like that, that gets really mind-bending really quickly. I think a case where I might consider using an each over a reduce, and that's maybe generally when I tend to use each, is when I'm doing side effects. If I'm using a reduce, it's because I care about the accumulated value at the end. If I'm using each, it's typically because I am trying to do some amount of side effects. +STEPHANIE: Yeah, that's a really good call out. I had that written down in my notes, and I'm glad you brought it up because I've seen them get conflated a little bit, and perhaps maybe that's the source of the pain that I'm talking about. But I really like that heuristic of reduce as, you know, you're caring about the output, as opposed to what's going on inside. Like, you don't want any unexpected behavior. +JOËL: And I think that applies to something like map as well. My sort of heuristic is, if I'm doing side effects, I want each. If I want transformed values that are sort of one-to-one in the collection, I want map. If I want a single sort of aggregate value, then I want reduce. +STEPHANIE: I think that's the cool thing about mixing paradigms sometimes, where all the strategies you talked about in terms of, you know, using custom, like, objects for your accumulator, or the elements in your collection, like, that's something that we get because, you know, we're using an object-oriented language like Ruby. But then, like, you also are kind of bringing the functional programming lens to, like, when you would use reduce in the first place. And yeah, I am just really excited now [chuckles] to start looking for some places I can use reduce after this conversation and see what comes out of it. +JOËL: I think I went on a bit of an interesting journey where, as a newer programmer, reduce was just, like, really intense. And I struggled to understand it. And I was like, ban it from code. I don't want to ever see it. And then, I got into functional programming. I was like, I'm going to do reduce everywhere. And, honestly, it was kind of messy. +And then I, like, went really deep on a lot of functional theory, and I think understood some things that then I was able to take back to my code and actually write reduce expressions that are much simpler so that now my heuristic is like, I love reduce; I want to use it, but I want as little as possible in the reduce itself. And because I understand some of these other concepts, I have the ability to know what things can be extracted in a way that will feel very natural, in a way that myself from five years ago would have just been like, oh, I don't know. I've got this, you know, 30-line reduce expression that I know is complicated, but I don't know how to improve. +And so, a little bit of the underlying theory, I don't think it's necessary to understand these simplified reduces, but as an author who's writing them, I think it helps me write reduces that are simpler. So, that's been my journey using reduce. +STEPHANIE: Yeah. Well, thanks for sharing. And I'm really excited. I hope our listeners have learned some new things about reduce and can look at it from a different light. +JOËL: There are so many different perspectives. And I think we keep discovering new mental models as we talk to different people. It's like, oh, this particular perspective. And there's one that we didn't really dig into but that I think makes more sense in a functional world that's around sort of deconstructing a structure and then rebuilding it with different components. The shorthand name of this mental model, which is a fairly common one, is constructor replacement. For anyone who's interested in digging into that, we'll link it in the show notes. +I gave a talk at an Elm meetup where I sort of dug into some of that theory, which is really interesting and kind of mind-blowing. Not as relevant, I think, for Rubyists, but if you're in a language that particularly allows you to build custom structures out of recursive types or what are sometimes called algebraic data types, or tagged unions, or discriminated unions, this thing goes by a bajillion names, that is a really interesting other mental model to look at. +And, again, I don't think the list that we've covered today is exhaustive. You know, I would love it for any of our listeners; if you have your own mental models for how to think about folding, injecting, reducing, send them in: hosts@bikeshed.fm. We'd love to hear them. +STEPHANIE: And on that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Joël talks about his difficulties optimizing queries in ActiveRecord, especially with complex scopes and unions, resulting in slow queries. He emphasizes the importance of optimizing subqueries in unions to boost performance despite challenges such as query duplication and difficulty reusing scopes. Stephanie discusses upgrading a client's app to Rails 7, highlighting the importance of patience, detailed attention, and the benefits of collaborative work with a fellow developer.

+ +

The conversation shifts to Ruby's reduce method (inject), exploring its complexity and various mental models to understand it. Joël and Stephanie discuss when it's preferable to use reduce over other methods like each, map, or loops and the importance of understanding the underlying operation you wish to apply to two elements before scaling up with reduce. The episode also touches on monoids and how they relate to reduce, suggesting that a deep understanding of functional programming concepts can help simplify reduce expressions.

+ + + +

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: I've been doing a bunch of fiddling with query optimization this week, and I've sort of run across an interesting...but maybe it's more of an interesting realization because it's interesting in the sort of annoying way. And that is that, using ActiveRecord scopes with certain more complex query pieces, particularly unions, can lead to queries that are really slow, and you have to rewrite them differently in a way that's not reusable in order to make them fast.

+ +

In particular, if you have sort of two other scopes that involve joins and then you combine them using a union, you're unioning two sort of joins. Later on, you want to change some other scope that does some wares or something like that. That can end up being really expensive, particularly if some of the underlying tables being joined are huge. Because your database, in my case, Postgres, will pull a lot of this data into the giant sort of in-memory table as it's, like, building all these things together and to filter them out. And it doesn't have the ability to optimize the way it would on a more traditional relation.

+ +

A solution to this is to make sure that the sort of subqueries that are getting unioned are optimized individually. And that can mean moving conditions that are outside the union inside. So, if I'm chaining, I don't know, where active is true on the outer query; on the union itself, I might need to move that inside each of the subqueries. So, now, in the two or three subqueries that I'm unioning, each of them needs to have a 'where active true' chained on it.

+ +

STEPHANIE: Interesting. I have heard this about using ActiveRecord scopes before, that if the scopes are quite complex, chaining them might not lead to the most performant query. That is interesting. By optimizing the subqueries, did you kind of change the meaning of them? Was that something that ended up happening?

+ +

JOËL: So, the annoying thing is that I have a scope that has the union in it, and it does some things sort of on its own. And it's used in some places. There are also other places that will try to take that scope that has the union on it, chain some other scopes that do other joins and some more filters, and that is horribly inefficient. So, I need to sort of rewrite the sort of subqueries that get union to include all these new conditions that only happen in this one use case and not in the, like, three or four others that rely on that union.

+ +

So, now I end up with some, like, awkward query duplication in different call sites that I'm not super comfortable about, but, unfortunately, I've not found a good way to make this sort of nicely reusable. Because when you want to chain sort of more things onto the union, you need to shove them in, and there's no clean way of doing that.

+ +

STEPHANIE: Yeah. I think another way I've seen this resolved is just writing it in SQL if it's really complex and it becoming just a bespoke query. We're no longer trying to use the scope that could be reusable.

+ +

JOËL: Right. Right. In this case, I guess, I'm, like, halfway in between in that I'm using the ActiveRecord DSL, but I am not reusing scopes and things. So, I sort of have the, I don't know, naive union implementation that can be fine in all of the simpler use cases that are using it. And then the query that tries to combine the union with some other fancy stuff it just gets its own separate implementation different than the others that it has optimized. So, there are sort of two separate paths, two separate implementations. I did not drop down to writing raw SQL because I could use the ActiveRecord DSL. So, that's what I've been working with.

+ +

What's new in your world this week?

+ +

STEPHANIE: So, a couple of weeks ago, I think, I mentioned that I was working on a Rails 7 upgrade, and we have gotten it out the door. So, now the client application I'm working on is on Rails 7, which is exciting for the team. But in an effort to make the upgrade as incremental as possible, we did, like, back out of a few of the new application config changes that would have led us down a path of more work. And now we're kind of following up a little bit to try to turn some of those configs on to enable them.

+ +

And it was very exciting to kind of, like, officially be on Rails 7. But I do feel like we tried to go for, like, the minimal amount of work possible in that initial big change. And now we're having to kind of backfill a little bit on some of the work that was a little bit more like, oh, I'm not really sure, like, how big this will end up being.

+ +

And it's been really interesting work, I think, because it requires, like, two different mindsets. Like, one of them is being really patient and focused on tedious work. Like, okay, what happens when we enable this config option? Like, what changes? What errors do we see? And then having to turn it back off and then go in and fix them.

+ +

But then another, I think, like, headspace that we have to be in is making decisions about what to do when we come to a crossroads around, like, okay, now that we are starting to see all the changes that are coming about from enabling this config, is this even what we want to do? And it can be really hard to switch between those two modes of thinking.

+ +

JOËL: Yeah. How do you try to balance between the two?

+ +

STEPHANIE: So, I luckily have been pairing with another dev, and I've actually found that to be really effective because he has, I guess, just, like, a little bit more of that patience to do the more tedious, mundane [laughs] aspects of, like, driving the code changes. And I have been riding along.

+ +

But then I can sense, like, once he gets to the point of like, "Oh, I'm not sure if we should keep going down this road," I can step in a little bit more and be like, "Okay, like, you know, I've seen us do this, like, five times now, and maybe we don't want to do that." Or maybe being like, "Okay, we don't have a really clear answer, but, like, who can we talk to to find out a little bit more or get their input?"

+ +

And that's been working really well for me because I've not had a lot of energy to do more of that, like, more manual or tedious labor [chuckles] that comes with working on that low level of stuff. So yeah, I've just been pleasantly surprised by how well we are aligning our superpowers.

+ +

JOËL: To use some classic business speech, how does it feel to be in the future on Rails 7?

+ +

STEPHANIE: Well, we're not quite up, you know, up to modern days yet, but it does feel like we're getting close. And, like, I think now we're starting to entertain the idea of, like, hmm, like, could we be even on main? I don't think it's really going to happen, but it feels a little bit more possible. And, in general, like, the team thinks that that could be, like, really exciting. Or it's easier, I think, once you're a little bit more on top of it. Like, the worst is when you get quite behind, and you end up just feeling like you're constantly playing catch up. It just feels a little bit more manageable now, which is good.

+ +

JOËL: I learned this week a fun fact about Rails 7.1, in particular, which is that the analyze method on ActiveRecord queries, which allowed you to sort of get SQL EXPLAIN statements, now has the ability to pass in a couple of extra parameters. So, there are symbols, and you can pass in things like analyze or verbose, which allows you to get sort of more data out of your EXPLAIN query, which can be quite nice when you're debugging for performance.

+ +

So, if you're in the future and you're on Rails 7.1 and you want sort of the in-depth query plans, you don't need to copy the SQL into a Postgres console to get access to the sort of fully developed EXPLAIN plan. You can now do it by passing arguments to EXPLAIN, which I'm very happy for.

+ +

STEPHANIE: That's really nice.

+ +

JOËL: So, we've mentioned before that we have a developers' channel on Slack here at thoughtbot, and there's all sorts of fun conversations that happen there. And there was one recently that really got me interested, where people were talking about Ruby's reduce method, also known as inject. And it's one of those methods that's kind of complicated, or it can be really confusing.

+ +

And there was a whole thread where people were talking about different mental models that they had around the reduce method and how they sort of understand the way it works. And I'd be curious to sort of dig into each other's mental models of that today. To kick us off, like, how comfortable do you feel with Ruby's reduce method? And do you have any mental models to kind of hold it in your head?

+ +

STEPHANIE: Yeah, I think reduce is so hard to wrap your head around, or it might be one of the most difficult, I guess, like, functions a new developer encounters, you know, in trying to understand the tools available to them. I always have to look up the order of the arguments [laughs] for reduce.

+ +

JOËL: Every time.

+ +

STEPHANIE: Yep. But I feel like I finally have a more intuitive sense of when to use it. And my mental model for it is collapsing a collection into one value, and, actually, that's why I prefer calling it reduce rather than the inject alias because reduce kind of signals to me this idea of going from many things to one canonical thing, I suppose.

+ +

JOËL: Yeah, that's a very common use case for reducing, and I guess the name itself, reducing, kind of has almost that connotation. You're taking many things, and you're going to reduce that down to a single thing.

+ +

STEPHANIE: What was really interesting to me about that conversation was that some people kind of had the opposite mental model where it made a bit more sense for them to think about injecting and, specifically, like, the idea of the accumulator being injected with values, I suppose. And I kind of realized that, in some ways, they're kind of antonyms [chuckles] a little bit because if you're focused on the accumulator, you're kind of thinking about something getting bigger. And that kind of blew my mind a little bit when I realized that, in some ways, they can be considered opposites.

+ +

JOËL: That's really fascinating. It is really interesting, I think, the way that we can take the name of a method and then almost, like, tell ourselves a story about what it does that then becomes our way of remembering how this method works. And the story we tell for the same method name, or in this case, maybe there's a few different method names that are aliases, can be different from person to person.

+ +

I know I tend to think of inject less in terms of injecting things into the accumulator and more in terms of injecting some kind of operator between every item in the collection. So, if we have an array of numbers and we're injecting plus, in my mind, I'm like, oh yeah, in between each of the numbers in the collection, just inject a little plus sign, and then do the math. We're summing all the items in the collection.

+ +

STEPHANIE: Does that still hold up when the operator becomes a little more complex than just, you know, like, a mathematical operator, like, say, a function?

+ +

JOËL: Well, when you start passing a block and doing custom logic, no, that mental model kind of falls apart. In order for it to work, it also has to be something that you can visualize as some form of infix operator, something that goes between two values rather than, like, a method name, which is typically in prefix position.

+ +

I do want to get at this idea, though: the difference between sort of the block version versus passing. There are ways where you can just do a symbol, and that will call a method on each of the items. Because I have a bit of a hot take when it comes to writing reduce blocks or inject blocks that are more accessible, easier to understand.

+ +

And that is, generally, that you shouldn't, or more specifically, you should not have a big block body. In general, you should be either using the symbol version or just calling a method within the block, and it's a one-liner. Which means that if you have some complex behavior, you need to find a way to move that out of this sort of collection operation and into instance methods on the objects being iterated.

+ +

STEPHANIE: Hmm, interesting. By one-liner do you mean passing the name of the method as a proc or actually, like, having your block that then calls the method? Because I can see it becoming even simpler if you have already extracted a method.

+ +

JOËL: Yeah, if you can do symbol to proc, that's amazing, or even if you can use just the straight-up symbol way of invoking reduce or inject. That typically means you have to start thinking about the types of objects that you are working with and what methods can be moved onto them. And sometimes, if you're working with hashes or something like that that don't have domain methods for what you want, that gets really awkward. And so, then maybe that becomes maybe a hint that you've got some primitive obsession happening and that this hash that sort of wants a domain object or some kind of domain method probably should be extracted to its own object.

+ +

STEPHANIE: I'll do you with another kind of spicy take. I think, in that case, maybe you don't want a reduce at all. If you're starting to find that...well, okay, I think it maybe could depend because there could be some very, like, domain-specific logic. But I have seen reduce end up being used to transform the structure of the initial collection when either a different higher-order function can be used or, I don't know, maybe you're just better off writing it with a regular loop [laughs]. It could be clearer that way.

+ +

JOËL: Well, that's really interesting because...so, you mentioned the idea that we could use a different higher-order function, and, you know, higher-order function is that fancy term, just a method that accepts another method as an argument. In Ruby, that just means your method accepts a block. Reduce can be used to implement pretty much the entirety of enumerable. Under the hood, enumerable is built in terms of each. You could implement it in terms of reduce.

+ +

So, sometimes it's easy to re-implement one of the enumerable methods yourself, accidentally, using reduce. So, you've written this, like, complex reduce block, and then somebody in review comes and looks at it and is like, "Hey, you realize that's just map. You've just recreated map. What if we used map here?"

+ +

STEPHANIE: Yeah. Another one I've seen a lot in JavaScript land where there are, you know, fewer utility functions is what we now have in Ruby, tally. I feel like that was a common one I would see a lot when you're trying to count instances of something, and I've seen it done with reduce. I've seen it done with a for each. And, you know, I'm sure there are libraries that actually provide a tally-like function for you in JS. But I guess that actually makes me feel even more strongly about this idea that reduce is best used for collapsing something as opposed to just, like, transforming a data structure into something else.

+ +

JOËL: There's an interesting other mental model for reduce that I think is hiding under what we're talking about here, and that is the idea that it is a sort of mid-level abstraction for dealing with collections, as opposed to something like map or select or some of those other enumerable helpers because those can all be implemented in terms of reduce. And so, in many cases, you don't need to write the reduce because the library maintainer has already used reduce or something equivalent to build these higher-level helpers for you.

+ +

STEPHANIE: Yeah, it's kind of in that weird point between, like, very powerful [chuckles] so that people can start to do some funky things with it, but also sometimes just necessary because it can feel a little bit more concise that way.

+ +

JOËL: I've done a fair amount of functional programming in languages like Elm. And there, if you're building a custom data structure, the sort of lowest-level way you have of looping is doing a recursion, and recursions are messy. And so, what you can do instead as a library developer is say, "You know what, I don't want to be writing recursions for all of these." I don't know; maybe I'm building a tree library. I don't want to write a recursion for every different function that goes over trees if I want to map or filter or whatever. I'm going to write reduce using recursion, and then everything else can be written in terms of reduce.

+ +

And then, if people want to do custom things, they don't need to recurse over my tree. They can use this reduce function, which allows them to do most of the traversals they want on the tree without needing to touch manual recursion. So, there's almost, like, a low-level, mid-level, high-level in the library design, where, like, lowest level is recursion. Ideally, nobody touches that. Mid-level, you've got reducing that's built out on top of recursion. And then, on top of that, you've got all sorts of other helpers, like mapping, like filtering, things like that.

+ +

STEPHANIE: Hmm. I'm wondering, do you know of any performance considerations when it comes to using reduce built off a recursion?

+ +

JOËL: So, one of the things that can be really nice is that writing a recursion yourself is dangerous. It's so easy to, like, accidentally introduce Stack Overflow. You could also write a really inefficient one. So, ideally, what you do is that you write a reduce that is safe and that is fast. And then, everybody else can just use that to not have to worry about the sort of mechanics of traversing the collection. And then, just use this. It already has all of the safety and speed features built in. You do have to be careful, though, because reduce, by nature, traverses the entire collection. And if you want to break out early of something expensive, then reduce might not be the tool for you.

+ +

STEPHANIE: I was also reading a little bit about how, in JavaScript, a lot of developers like to stick to that idea of a pure function and try to basically copy the entire accumulator for every iteration and creating a new object for that. And that has led to some memory issues as well. As opposed to just mutating the accumulator, having, especially when you, you know, are going through a collection, like, really large, making that copy every single time and creating, yeah [chuckles], just a lot of issues that way. So, that's kind of what prompted that question.

+ +

JOËL: Yeah, that can vary a lot by language and by data structure. In more functional languages that try to not mutate, they often have this idea of what they call persistent data structures, where you can sort of create copies that have small modifications that don't force you to copy the whole object under the hood. They're just, like, pointers. So, like, hey, we, like, are the same as this other object, but with this extra element added, or something like that. So, if you're growing an array or something like that, you don't end up with 10,000 copies of the array with, like, a new element every time.

+ +

STEPHANIE: Yeah, that is interesting. And I feel like trying to adopt different paradigms for different tools, you know, is not always as straightforward as some wish it were [laughs].

+ +

JOËL: I do want to give a shout-out to an academic paper that is...it is infamously dense. The title of it is Functional Programming with Bananas, Lenses, and Barbed Wire.

+ +

STEPHANIE: It doesn't sound dense; it sounds fun. Well, I don't about barbed wire.

+ +

JOËL: It sounds fun, right?

+ +

STEPHANIE: Yeah, but certainly quirky [laughs].

+ +

JOËL: It is incredibly dense. And they've, like, created this custom math notation and all this stuff. But the idea that they pioneered there is really cool, this idea that kind of like I was talking about sort of building libraries in different levels. Their idea is that recursion is generally something that's unsafe and that library and language designers should take care of all of the recursion and instead provide some of these sort of mid-level helper methods to do things. Reducing is one of them, but their proposal is that it's not the only one. There's a whole sort of family of similar methods that are there that would be useful in different use cases.

+ +

So, reduce allows you to sort of traverse the whole thing. It does not allow you to break out early. It does not allow you to keep sort of track of a sort of extra context element if you want to, like, be traversing a collection but have a sort of look forward, look back, something like that. So, there are other variations that could handle those. There are variations that are the opposite of reduce, where you're, like, inflating, starting from a few parameters and building a collection out of them.

+ +

So, this whole concept is called recursion schemes, and you can get, like, really deep into some theory there. You'll hear fancy words like catamorphisms and anamorphisms. There's a whole world to explore in that area. But at its core, it's this idea that you can sort of slice up things into this sort of low-level recursion, mid-level helpers, and then, like, kind of userland helpers built on top of that.

+ +

STEPHANIE: Wow. That is very intense; it sounds like [chuckles]. I'm happy not to ever have to write a recursion ever again, probably [laughs]. Have you ever, as just a web developer in your day-to-day programming, found a really good use case for dropping down to that level? Or are you kind of convinced that, like, you won't really ever need to?

+ +

JOËL: I think it depends on the paradigm of the language you're working in. In Ruby, I've very rarely needed to write a recursion. In something like Elm, I've had to do that, eh, not infrequently. Again, it depends, like, if I'm doing more library-esque code versus more application code. If I'm writing application code and I'm using an existing, let's say, tree library, then I typically don't need to write a recursion because they've already written traversals for me. If I'm making my own and I have made my own tree libraries, then yes, I'm writing recursions myself and building those traversals so that other people don't have to.

+ +

STEPHANIE: Yeah, that makes sense. I'd much rather someone who has read that paper [laughs] write some traversal methods for me.

+ +

JOËL: And, you know, for those who are curious about it, we will put a link to this paper in the description.

+ +

So, we've talked about a sort of very academic mental model way of thinking about reducing. I want to shift gears and talk about one that I have found is incredibly practical, and that is the idea that reduce is a way to scale an operation that works on two objects to an operation that works on sort of an unlimited number of objects.

+ +

To make it more concrete, take something like addition. I can add two numbers. The plus operator allows me to take one number, add another, get a sum. But what if I want to not just add two numbers? I want to add an arbitrary number of numbers together. Reduce allows me to take that plus operator and then just scale it up to as many numbers as I want. I can just plug that into, you know, I have an array of numbers, and I just call dot reduce plus operator, and, boom, it can now scale to as many numbers as I want, and I can sum the whole thing.

+ +

STEPHANIE: That dovetails quite nicely with your take earlier about how you shouldn't pass a block to reduce. You should extract that into a method. Don't you think?

+ +

JOËL: I think it does, yes. And then maybe it's, like, sort of two sides of a coin because I think what this leads to is an approach that I really like for reducing because sometimes, you know, here, I'm starting with addition. I'm like, oh, I have addition. Now, I want to scale it up. How do I do that? I can use reduce. Oftentimes, I'm faced with sort of the opposite problem. I'm like, oh, I need to add all these numbers together. How do I do that? I'm like, probably with a reduce. But then I start writing the block, and, like, I get way too into my head about the accumulator and what's going to happen.

+ +

So, my strategy for writing reduce expressions is to, instead of trying to figure out how to, like, do the whole thing together, first ask myself, how do I want to combine any two elements that are in the array? So, I've got an array of numbers, and I want to sum them all. What is the thing I need to do to combine just two of those? Forget the array. Figure that out.

+ +

And then, once I have that figured out, maybe it's an existing method like plus. Maybe it's a method I need to define on it if it's a custom object. Maybe it's a method that I write somewhere. Then, once I have that, I can say, okay, I can do it for two items. Now, I'm going to scale it up to work for the whole array, and I can plug it into reduce. And, at that point, the work is already basically done, so I don't end up with a really complex block. I don't end up, like, almost ending in, like, a recursive infinite loop in my head because I do that.

+ +

STEPHANIE: [laughs].

+ +

JOËL: So, that approach of saying, start by figuring out what is the operation you want to do to combine two elements, and then use reduce as a way to scale that to your whole array is a way that I've used to keep things simple in my mind.

+ +

STEPHANIE: Yeah, I like that a lot as a supplement to the model I shared earlier because, for me, when I think about reducing as, like, collapsing into a value, you kind of are just like, well, okay, I start with the collection, and then somehow I get to my single value. But the challenge is figuring out how that happens [laughs], like, the magic that happens in between that.

+ +

And I think another alias that we haven't mentioned yet for reduce that is used in a lot of other languages is fold. And I actually like that one a lot, and I think it relates to your mental model. Because when I think about folding, I'm picturing folding up a paper like an accordion. And you have to figure out, like, what is the first fold that I can make? And just repeating that over and over to get to your little stack of accordion paper [laughs]. And if you can figure out just that first step, then you pretty much, like, have the recipe for getting from your initial input to, like, your desired output.

+ +

JOËL: Yeah. I think fold is interesting in that some languages will make a distinction between fold and reduce. They will have both. And typically, fold will require you to pass an initial value, like a starting accumulator, to start it off. Whereas reduce will sort of assume that your array can use the first element of the array as the first accumulator.

+ +

STEPHANIE: Oh, I just came up with another visual metaphor for this, which is, like, folding butter into croissant pastry when the butter is your initial value [laughs].

+ +

JOËL: And then the crust is, I guess, the elements in the array.

+ +

STEPHANIE: Yeah. Yeah. And then you get a croissant out of it [laughs]. Don't ask me how it gets to a perfectly baked, flaky, beautiful croissant, but somehow that happens [laughs].

+ +

JOËL: So, there's an interesting sort of subtlety here that I think happens because there are sort of two slightly different ways that you can interact with a reduce. Sometimes, your accumulator is of the same type as the elements in your array. So, you're summing an array of numbers, and your accumulator is the sum, but each of the elements in the array are also numbers. So, it's numbers all the way through. And sometimes, your accumulator has a different type than the items in the array. So, maybe you have an array of words, and you want to get the sum of all of the characters and all the words. And so, now your accumulator is a number, but each of the items in the array are strings.

+ +

STEPHANIE: Yeah, that's an interesting distinction because I think that's where you start to see the complex blocks being passed and reduced.

+ +

JOËL: The complex blocks, definitely; I think they tend to show up when your accumulator has a different type than the individual items. So, maybe that's, like, a slightly more complicated use case. Oftentimes, too, the accumulator ends up being some, like, more complex, like, hash or something that maybe would really benefit from being a custom object.

+ +

STEPHANIE: I've never done that before, but I can see why that would be really useful. Do you have an example of when you used a custom object as the accumulator?

+ +

JOËL: So, I've done it for situations where I'm working with objects that are doing tally-like operations, but I'm not doing just a generic tally. There's some domain-specific stuff happening. So, it's some sort of aggregate counter on multiple dimensions that you can use, and that can get really ugly. And you can either do it with a reduce or you can have some sort of, like, initial version of the hash outside and do an each and mutate the hash and stuff like that. All of these tend to be a little bit ugly. So, in those situations, I've often created some sort of custom object that has some instance methods that allow to sort of easily add new elements to it.

+ +

STEPHANIE: That's really interesting because now I'm starting to think, what if the elements in the collection were also a custom object? [chuckles] And then things could, I feel like, could be really powerful [laughs].

+ +

JOËL: There's often a lot of value, right? Because if the items in the collection are also a custom object, you can then have methods on them. And then, again, the sort of complexity of the reduce can sort of, like, fade away because it doesn't own any of the logic. All it does is saying, hey, there's a thing you can do to combine two items. Let's scale it up to work on a collection of items. And now you've sort of, like, really simplified what logic is actually owned inside the reduce.

+ +

I do want to shout out for those listeners who are theory nerds and want to dig into this. When you have a reduce, and you've got an operation where all the values are of the same type, including the accumulator, typically, what you've got here is some form of monoid. It may be a semigroup. So, if you want to dig into some theory, those are the words to Google and to go a deep dive on.

+ +

The main thing about monoids, in particular, is that monoids are any objects that have both a sort of a base case, a sort of empty version of themselves, and they have some sort of combining method that allows you to combine two values of that type. If your object has these things and follows...there's a few rules that have to be true. You have a monoid. And they can then be sort of guaranteed to be folded nicely because you can plug in their base case as your initial accumulator. And you can plug in their combining method as just the value of the block, and everything else just falls into place.

+ +

A classic here is addition for numbers. So, if you want to add two numbers, your combining operator is a plus. And your sort of empty value is a zero. So, you would say, reduce initial value is zero, array of numbers. And your block is just plus, and it won't sum all of the numbers. You could do something similar with strings, where you can combine strings together with plus, and, you know, your empty string is your base case. So, now you're doing sort of string concatenation over arbitrary number of strings.

+ +

Turns out there's a lot of operations that fall into that, and you can even define some of those on your custom object. So, you're like, oh, I've got a custom object. Maybe I want some way of, like, combining two of them together. You might be heading in the direction of doing something that is monoidal, and if so, that's a really good hint to know that it can sort of, like, just drop into place with a fold or a reduce and that that is a tool that you have available to you.

+ +

STEPHANIE: Yeah, well, I think my eyes, like, widened a little bit when you first dropped the term monoid [laughs]. I do want to spend the last bit of our time talking about when not to use reduce, and, you know, we did talk a lot about recursion. But when do you think a regular old loop will just be enough?

+ +

JOËL: So, you're suggesting when would you want to use something like an each rather than a reduce?

+ +

STEPHANIE: Yeah. In my mind, you know, you did offer, like, a lot of ways to make reduce simpler, a lot of strategies to end up with some really nice-looking syntax [chuckles], I think. But, oftentimes, I think it can be equally as clear storing your accumulator outside of the iteration and that, like, is enough for me to understand. And reduce takes a little bit of extra overhead to figure out what I'm looking at. Do you have any thoughts about when you would prefer to do that? Or do you think that you would usually reach for something else?

+ +

JOËL: Personally, I generally don't like the pattern of using each to iterate over a collection and then mutate some external accumulator. That, to me, is a bit of a code smell. It's a sign that each is not quite powerful enough to do the thing that I want to do and that I'm probably needing some sort of more specialized form of iteration. Sometimes, that's reduce. Oftentimes, because each can suffer from the same problem you mentioned from reduce, where it's like, oh, you're doing this thing where you mutate an external accumulator. Turns out what you're really doing is just map. So, use map or use select or, you know, some of the other built-in iterators from the enumerable library.

+ +

There's a blog post on the thoughtbot blog that I continually link to people. And when I see the pattern of, like, mutating an external variable with each, yeah, I tend to see that as a bit of a code smell. I don't know that I would never do it, but whenever I see that, it's a sign to me to, like, pause and be like, wait a minute, is there a better way to do this?

+ +

STEPHANIE: Yeah, that's fair. I like the idea that, like, if there's already a method available to you that is more specific to go with that. But I also think that sometimes I'd rather, like, come across that pattern of mutating a variable outside of the iteration over, like, someone trying to do something clever with the reduce.

+ +

JOËL: Yeah, I guess reduce, especially if it's got, like, a giant block and you've got then, like, things in there that break or call next to skip iterations and things like that, that gets really mind-bending really quickly. I think a case where I might consider using an each over a reduce, and that's maybe generally when I tend to use each, is when I'm doing side effects. If I'm using a reduce, it's because I care about the accumulated value at the end. If I'm using each, it's typically because I am trying to do some amount of side effects.

+ +

STEPHANIE: Yeah, that's a really good call out. I had that written down in my notes, and I'm glad you brought it up because I've seen them get conflated a little bit, and perhaps maybe that's the source of the pain that I'm talking about. But I really like that heuristic of reduce as, you know, you're caring about the output, as opposed to what's going on inside. Like, you don't want any unexpected behavior.

+ +

JOËL: And I think that applies to something like map as well. My sort of heuristic is, if I'm doing side effects, I want each. If I want transformed values that are sort of one-to-one in the collection, I want map. If I want a single sort of aggregate value, then I want reduce.

+ +

STEPHANIE: I think that's the cool thing about mixing paradigms sometimes, where all the strategies you talked about in terms of, you know, using custom, like, objects for your accumulator, or the elements in your collection, like, that's something that we get because, you know, we're using an object-oriented language like Ruby. But then, like, you also are kind of bringing the functional programming lens to, like, when you would use reduce in the first place. And yeah, I am just really excited now [chuckles] to start looking for some places I can use reduce after this conversation and see what comes out of it.

+ +

JOËL: I think I went on a bit of an interesting journey where, as a newer programmer, reduce was just, like, really intense. And I struggled to understand it. And I was like, ban it from code. I don't want to ever see it. And then, I got into functional programming. I was like, I'm going to do reduce everywhere. And, honestly, it was kind of messy.

+ +

And then I, like, went really deep on a lot of functional theory, and I think understood some things that then I was able to take back to my code and actually write reduce expressions that are much simpler so that now my heuristic is like, I love reduce; I want to use it, but I want as little as possible in the reduce itself. And because I understand some of these other concepts, I have the ability to know what things can be extracted in a way that will feel very natural, in a way that myself from five years ago would have just been like, oh, I don't know. I've got this, you know, 30-line reduce expression that I know is complicated, but I don't know how to improve.

+ +

And so, a little bit of the underlying theory, I don't think it's necessary to understand these simplified reduces, but as an author who's writing them, I think it helps me write reduces that are simpler. So, that's been my journey using reduce.

+ +

STEPHANIE: Yeah. Well, thanks for sharing. And I'm really excited. I hope our listeners have learned some new things about reduce and can look at it from a different light.

+ +

JOËL: There are so many different perspectives. And I think we keep discovering new mental models as we talk to different people. It's like, oh, this particular perspective. And there's one that we didn't really dig into but that I think makes more sense in a functional world that's around sort of deconstructing a structure and then rebuilding it with different components. The shorthand name of this mental model, which is a fairly common one, is constructor replacement. For anyone who's interested in digging into that, we'll link it in the show notes.

+ +

I gave a talk at an Elm meetup where I sort of dug into some of that theory, which is really interesting and kind of mind-blowing. Not as relevant, I think, for Rubyists, but if you're in a language that particularly allows you to build custom structures out of recursive types or what are sometimes called algebraic data types, or tagged unions, or discriminated unions, this thing goes by a bajillion names, that is a really interesting other mental model to look at.

+ +

And, again, I don't think the list that we've covered today is exhaustive. You know, I would love it for any of our listeners; if you have your own mental models for how to think about folding, injecting, reducing, send them in: hosts@bikeshed.fm. We'd love to hear them.

+ +

STEPHANIE: And on that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël talks about his difficulties optimizing queries in ActiveRecord, especially with complex scopes and unions, resulting in slow queries. He emphasizes the importance of optimizing subqueries in unions to boost performance despite challenges such as query duplication and difficulty reusing scopes. Stephanie discusses upgrading a client's app to Rails 7, highlighting the importance of patience, detailed attention, and the benefits of collaborative work with a fellow developer.

+ +

The conversation shifts to Ruby's reduce method (inject), exploring its complexity and various mental models to understand it. Joël and Stephanie discuss when it's preferable to use reduce over other methods like each, map, or loops and the importance of understanding the underlying operation you wish to apply to two elements before scaling up with reduce. The episode also touches on monoids and how they relate to reduce, suggesting that a deep understanding of functional programming concepts can help simplify reduce expressions.

+ + + +

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: I've been doing a bunch of fiddling with query optimization this week, and I've sort of run across an interesting...but maybe it's more of an interesting realization because it's interesting in the sort of annoying way. And that is that, using ActiveRecord scopes with certain more complex query pieces, particularly unions, can lead to queries that are really slow, and you have to rewrite them differently in a way that's not reusable in order to make them fast.

+ +

In particular, if you have sort of two other scopes that involve joins and then you combine them using a union, you're unioning two sort of joins. Later on, you want to change some other scope that does some wares or something like that. That can end up being really expensive, particularly if some of the underlying tables being joined are huge. Because your database, in my case, Postgres, will pull a lot of this data into the giant sort of in-memory table as it's, like, building all these things together and to filter them out. And it doesn't have the ability to optimize the way it would on a more traditional relation.

+ +

A solution to this is to make sure that the sort of subqueries that are getting unioned are optimized individually. And that can mean moving conditions that are outside the union inside. So, if I'm chaining, I don't know, where active is true on the outer query; on the union itself, I might need to move that inside each of the subqueries. So, now, in the two or three subqueries that I'm unioning, each of them needs to have a 'where active true' chained on it.

+ +

STEPHANIE: Interesting. I have heard this about using ActiveRecord scopes before, that if the scopes are quite complex, chaining them might not lead to the most performant query. That is interesting. By optimizing the subqueries, did you kind of change the meaning of them? Was that something that ended up happening?

+ +

JOËL: So, the annoying thing is that I have a scope that has the union in it, and it does some things sort of on its own. And it's used in some places. There are also other places that will try to take that scope that has the union on it, chain some other scopes that do other joins and some more filters, and that is horribly inefficient. So, I need to sort of rewrite the sort of subqueries that get union to include all these new conditions that only happen in this one use case and not in the, like, three or four others that rely on that union.

+ +

So, now I end up with some, like, awkward query duplication in different call sites that I'm not super comfortable about, but, unfortunately, I've not found a good way to make this sort of nicely reusable. Because when you want to chain sort of more things onto the union, you need to shove them in, and there's no clean way of doing that.

+ +

STEPHANIE: Yeah. I think another way I've seen this resolved is just writing it in SQL if it's really complex and it becoming just a bespoke query. We're no longer trying to use the scope that could be reusable.

+ +

JOËL: Right. Right. In this case, I guess, I'm, like, halfway in between in that I'm using the ActiveRecord DSL, but I am not reusing scopes and things. So, I sort of have the, I don't know, naive union implementation that can be fine in all of the simpler use cases that are using it. And then the query that tries to combine the union with some other fancy stuff it just gets its own separate implementation different than the others that it has optimized. So, there are sort of two separate paths, two separate implementations. I did not drop down to writing raw SQL because I could use the ActiveRecord DSL. So, that's what I've been working with.

+ +

What's new in your world this week?

+ +

STEPHANIE: So, a couple of weeks ago, I think, I mentioned that I was working on a Rails 7 upgrade, and we have gotten it out the door. So, now the client application I'm working on is on Rails 7, which is exciting for the team. But in an effort to make the upgrade as incremental as possible, we did, like, back out of a few of the new application config changes that would have led us down a path of more work. And now we're kind of following up a little bit to try to turn some of those configs on to enable them.

+ +

And it was very exciting to kind of, like, officially be on Rails 7. But I do feel like we tried to go for, like, the minimal amount of work possible in that initial big change. And now we're having to kind of backfill a little bit on some of the work that was a little bit more like, oh, I'm not really sure, like, how big this will end up being.

+ +

And it's been really interesting work, I think, because it requires, like, two different mindsets. Like, one of them is being really patient and focused on tedious work. Like, okay, what happens when we enable this config option? Like, what changes? What errors do we see? And then having to turn it back off and then go in and fix them.

+ +

But then another, I think, like, headspace that we have to be in is making decisions about what to do when we come to a crossroads around, like, okay, now that we are starting to see all the changes that are coming about from enabling this config, is this even what we want to do? And it can be really hard to switch between those two modes of thinking.

+ +

JOËL: Yeah. How do you try to balance between the two?

+ +

STEPHANIE: So, I luckily have been pairing with another dev, and I've actually found that to be really effective because he has, I guess, just, like, a little bit more of that patience to do the more tedious, mundane [laughs] aspects of, like, driving the code changes. And I have been riding along.

+ +

But then I can sense, like, once he gets to the point of like, "Oh, I'm not sure if we should keep going down this road," I can step in a little bit more and be like, "Okay, like, you know, I've seen us do this, like, five times now, and maybe we don't want to do that." Or maybe being like, "Okay, we don't have a really clear answer, but, like, who can we talk to to find out a little bit more or get their input?"

+ +

And that's been working really well for me because I've not had a lot of energy to do more of that, like, more manual or tedious labor [chuckles] that comes with working on that low level of stuff. So yeah, I've just been pleasantly surprised by how well we are aligning our superpowers.

+ +

JOËL: To use some classic business speech, how does it feel to be in the future on Rails 7?

+ +

STEPHANIE: Well, we're not quite up, you know, up to modern days yet, but it does feel like we're getting close. And, like, I think now we're starting to entertain the idea of, like, hmm, like, could we be even on main? I don't think it's really going to happen, but it feels a little bit more possible. And, in general, like, the team thinks that that could be, like, really exciting. Or it's easier, I think, once you're a little bit more on top of it. Like, the worst is when you get quite behind, and you end up just feeling like you're constantly playing catch up. It just feels a little bit more manageable now, which is good.

+ +

JOËL: I learned this week a fun fact about Rails 7.1, in particular, which is that the analyze method on ActiveRecord queries, which allowed you to sort of get SQL EXPLAIN statements, now has the ability to pass in a couple of extra parameters. So, there are symbols, and you can pass in things like analyze or verbose, which allows you to get sort of more data out of your EXPLAIN query, which can be quite nice when you're debugging for performance.

+ +

So, if you're in the future and you're on Rails 7.1 and you want sort of the in-depth query plans, you don't need to copy the SQL into a Postgres console to get access to the sort of fully developed EXPLAIN plan. You can now do it by passing arguments to EXPLAIN, which I'm very happy for.

+ +

STEPHANIE: That's really nice.

+ +

JOËL: So, we've mentioned before that we have a developers' channel on Slack here at thoughtbot, and there's all sorts of fun conversations that happen there. And there was one recently that really got me interested, where people were talking about Ruby's reduce method, also known as inject. And it's one of those methods that's kind of complicated, or it can be really confusing.

+ +

And there was a whole thread where people were talking about different mental models that they had around the reduce method and how they sort of understand the way it works. And I'd be curious to sort of dig into each other's mental models of that today. To kick us off, like, how comfortable do you feel with Ruby's reduce method? And do you have any mental models to kind of hold it in your head?

+ +

STEPHANIE: Yeah, I think reduce is so hard to wrap your head around, or it might be one of the most difficult, I guess, like, functions a new developer encounters, you know, in trying to understand the tools available to them. I always have to look up the order of the arguments [laughs] for reduce.

+ +

JOËL: Every time.

+ +

STEPHANIE: Yep. But I feel like I finally have a more intuitive sense of when to use it. And my mental model for it is collapsing a collection into one value, and, actually, that's why I prefer calling it reduce rather than the inject alias because reduce kind of signals to me this idea of going from many things to one canonical thing, I suppose.

+ +

JOËL: Yeah, that's a very common use case for reducing, and I guess the name itself, reducing, kind of has almost that connotation. You're taking many things, and you're going to reduce that down to a single thing.

+ +

STEPHANIE: What was really interesting to me about that conversation was that some people kind of had the opposite mental model where it made a bit more sense for them to think about injecting and, specifically, like, the idea of the accumulator being injected with values, I suppose. And I kind of realized that, in some ways, they're kind of antonyms [chuckles] a little bit because if you're focused on the accumulator, you're kind of thinking about something getting bigger. And that kind of blew my mind a little bit when I realized that, in some ways, they can be considered opposites.

+ +

JOËL: That's really fascinating. It is really interesting, I think, the way that we can take the name of a method and then almost, like, tell ourselves a story about what it does that then becomes our way of remembering how this method works. And the story we tell for the same method name, or in this case, maybe there's a few different method names that are aliases, can be different from person to person.

+ +

I know I tend to think of inject less in terms of injecting things into the accumulator and more in terms of injecting some kind of operator between every item in the collection. So, if we have an array of numbers and we're injecting plus, in my mind, I'm like, oh yeah, in between each of the numbers in the collection, just inject a little plus sign, and then do the math. We're summing all the items in the collection.

+ +

STEPHANIE: Does that still hold up when the operator becomes a little more complex than just, you know, like, a mathematical operator, like, say, a function?

+ +

JOËL: Well, when you start passing a block and doing custom logic, no, that mental model kind of falls apart. In order for it to work, it also has to be something that you can visualize as some form of infix operator, something that goes between two values rather than, like, a method name, which is typically in prefix position.

+ +

I do want to get at this idea, though: the difference between sort of the block version versus passing. There are ways where you can just do a symbol, and that will call a method on each of the items. Because I have a bit of a hot take when it comes to writing reduce blocks or inject blocks that are more accessible, easier to understand.

+ +

And that is, generally, that you shouldn't, or more specifically, you should not have a big block body. In general, you should be either using the symbol version or just calling a method within the block, and it's a one-liner. Which means that if you have some complex behavior, you need to find a way to move that out of this sort of collection operation and into instance methods on the objects being iterated.

+ +

STEPHANIE: Hmm, interesting. By one-liner do you mean passing the name of the method as a proc or actually, like, having your block that then calls the method? Because I can see it becoming even simpler if you have already extracted a method.

+ +

JOËL: Yeah, if you can do symbol to proc, that's amazing, or even if you can use just the straight-up symbol way of invoking reduce or inject. That typically means you have to start thinking about the types of objects that you are working with and what methods can be moved onto them. And sometimes, if you're working with hashes or something like that that don't have domain methods for what you want, that gets really awkward. And so, then maybe that becomes maybe a hint that you've got some primitive obsession happening and that this hash that sort of wants a domain object or some kind of domain method probably should be extracted to its own object.

+ +

STEPHANIE: I'll do you with another kind of spicy take. I think, in that case, maybe you don't want a reduce at all. If you're starting to find that...well, okay, I think it maybe could depend because there could be some very, like, domain-specific logic. But I have seen reduce end up being used to transform the structure of the initial collection when either a different higher-order function can be used or, I don't know, maybe you're just better off writing it with a regular loop [laughs]. It could be clearer that way.

+ +

JOËL: Well, that's really interesting because...so, you mentioned the idea that we could use a different higher-order function, and, you know, higher-order function is that fancy term, just a method that accepts another method as an argument. In Ruby, that just means your method accepts a block. Reduce can be used to implement pretty much the entirety of enumerable. Under the hood, enumerable is built in terms of each. You could implement it in terms of reduce.

+ +

So, sometimes it's easy to re-implement one of the enumerable methods yourself, accidentally, using reduce. So, you've written this, like, complex reduce block, and then somebody in review comes and looks at it and is like, "Hey, you realize that's just map. You've just recreated map. What if we used map here?"

+ +

STEPHANIE: Yeah. Another one I've seen a lot in JavaScript land where there are, you know, fewer utility functions is what we now have in Ruby, tally. I feel like that was a common one I would see a lot when you're trying to count instances of something, and I've seen it done with reduce. I've seen it done with a for each. And, you know, I'm sure there are libraries that actually provide a tally-like function for you in JS. But I guess that actually makes me feel even more strongly about this idea that reduce is best used for collapsing something as opposed to just, like, transforming a data structure into something else.

+ +

JOËL: There's an interesting other mental model for reduce that I think is hiding under what we're talking about here, and that is the idea that it is a sort of mid-level abstraction for dealing with collections, as opposed to something like map or select or some of those other enumerable helpers because those can all be implemented in terms of reduce. And so, in many cases, you don't need to write the reduce because the library maintainer has already used reduce or something equivalent to build these higher-level helpers for you.

+ +

STEPHANIE: Yeah, it's kind of in that weird point between, like, very powerful [chuckles] so that people can start to do some funky things with it, but also sometimes just necessary because it can feel a little bit more concise that way.

+ +

JOËL: I've done a fair amount of functional programming in languages like Elm. And there, if you're building a custom data structure, the sort of lowest-level way you have of looping is doing a recursion, and recursions are messy. And so, what you can do instead as a library developer is say, "You know what, I don't want to be writing recursions for all of these." I don't know; maybe I'm building a tree library. I don't want to write a recursion for every different function that goes over trees if I want to map or filter or whatever. I'm going to write reduce using recursion, and then everything else can be written in terms of reduce.

+ +

And then, if people want to do custom things, they don't need to recurse over my tree. They can use this reduce function, which allows them to do most of the traversals they want on the tree without needing to touch manual recursion. So, there's almost, like, a low-level, mid-level, high-level in the library design, where, like, lowest level is recursion. Ideally, nobody touches that. Mid-level, you've got reducing that's built out on top of recursion. And then, on top of that, you've got all sorts of other helpers, like mapping, like filtering, things like that.

+ +

STEPHANIE: Hmm. I'm wondering, do you know of any performance considerations when it comes to using reduce built off a recursion?

+ +

JOËL: So, one of the things that can be really nice is that writing a recursion yourself is dangerous. It's so easy to, like, accidentally introduce Stack Overflow. You could also write a really inefficient one. So, ideally, what you do is that you write a reduce that is safe and that is fast. And then, everybody else can just use that to not have to worry about the sort of mechanics of traversing the collection. And then, just use this. It already has all of the safety and speed features built in. You do have to be careful, though, because reduce, by nature, traverses the entire collection. And if you want to break out early of something expensive, then reduce might not be the tool for you.

+ +

STEPHANIE: I was also reading a little bit about how, in JavaScript, a lot of developers like to stick to that idea of a pure function and try to basically copy the entire accumulator for every iteration and creating a new object for that. And that has led to some memory issues as well. As opposed to just mutating the accumulator, having, especially when you, you know, are going through a collection, like, really large, making that copy every single time and creating, yeah [chuckles], just a lot of issues that way. So, that's kind of what prompted that question.

+ +

JOËL: Yeah, that can vary a lot by language and by data structure. In more functional languages that try to not mutate, they often have this idea of what they call persistent data structures, where you can sort of create copies that have small modifications that don't force you to copy the whole object under the hood. They're just, like, pointers. So, like, hey, we, like, are the same as this other object, but with this extra element added, or something like that. So, if you're growing an array or something like that, you don't end up with 10,000 copies of the array with, like, a new element every time.

+ +

STEPHANIE: Yeah, that is interesting. And I feel like trying to adopt different paradigms for different tools, you know, is not always as straightforward as some wish it were [laughs].

+ +

JOËL: I do want to give a shout-out to an academic paper that is...it is infamously dense. The title of it is Functional Programming with Bananas, Lenses, and Barbed Wire.

+ +

STEPHANIE: It doesn't sound dense; it sounds fun. Well, I don't about barbed wire.

+ +

JOËL: It sounds fun, right?

+ +

STEPHANIE: Yeah, but certainly quirky [laughs].

+ +

JOËL: It is incredibly dense. And they've, like, created this custom math notation and all this stuff. But the idea that they pioneered there is really cool, this idea that kind of like I was talking about sort of building libraries in different levels. Their idea is that recursion is generally something that's unsafe and that library and language designers should take care of all of the recursion and instead provide some of these sort of mid-level helper methods to do things. Reducing is one of them, but their proposal is that it's not the only one. There's a whole sort of family of similar methods that are there that would be useful in different use cases.

+ +

So, reduce allows you to sort of traverse the whole thing. It does not allow you to break out early. It does not allow you to keep sort of track of a sort of extra context element if you want to, like, be traversing a collection but have a sort of look forward, look back, something like that. So, there are other variations that could handle those. There are variations that are the opposite of reduce, where you're, like, inflating, starting from a few parameters and building a collection out of them.

+ +

So, this whole concept is called recursion schemes, and you can get, like, really deep into some theory there. You'll hear fancy words like catamorphisms and anamorphisms. There's a whole world to explore in that area. But at its core, it's this idea that you can sort of slice up things into this sort of low-level recursion, mid-level helpers, and then, like, kind of userland helpers built on top of that.

+ +

STEPHANIE: Wow. That is very intense; it sounds like [chuckles]. I'm happy not to ever have to write a recursion ever again, probably [laughs]. Have you ever, as just a web developer in your day-to-day programming, found a really good use case for dropping down to that level? Or are you kind of convinced that, like, you won't really ever need to?

+ +

JOËL: I think it depends on the paradigm of the language you're working in. In Ruby, I've very rarely needed to write a recursion. In something like Elm, I've had to do that, eh, not infrequently. Again, it depends, like, if I'm doing more library-esque code versus more application code. If I'm writing application code and I'm using an existing, let's say, tree library, then I typically don't need to write a recursion because they've already written traversals for me. If I'm making my own and I have made my own tree libraries, then yes, I'm writing recursions myself and building those traversals so that other people don't have to.

+ +

STEPHANIE: Yeah, that makes sense. I'd much rather someone who has read that paper [laughs] write some traversal methods for me.

+ +

JOËL: And, you know, for those who are curious about it, we will put a link to this paper in the description.

+ +

So, we've talked about a sort of very academic mental model way of thinking about reducing. I want to shift gears and talk about one that I have found is incredibly practical, and that is the idea that reduce is a way to scale an operation that works on two objects to an operation that works on sort of an unlimited number of objects.

+ +

To make it more concrete, take something like addition. I can add two numbers. The plus operator allows me to take one number, add another, get a sum. But what if I want to not just add two numbers? I want to add an arbitrary number of numbers together. Reduce allows me to take that plus operator and then just scale it up to as many numbers as I want. I can just plug that into, you know, I have an array of numbers, and I just call dot reduce plus operator, and, boom, it can now scale to as many numbers as I want, and I can sum the whole thing.

+ +

STEPHANIE: That dovetails quite nicely with your take earlier about how you shouldn't pass a block to reduce. You should extract that into a method. Don't you think?

+ +

JOËL: I think it does, yes. And then maybe it's, like, sort of two sides of a coin because I think what this leads to is an approach that I really like for reducing because sometimes, you know, here, I'm starting with addition. I'm like, oh, I have addition. Now, I want to scale it up. How do I do that? I can use reduce. Oftentimes, I'm faced with sort of the opposite problem. I'm like, oh, I need to add all these numbers together. How do I do that? I'm like, probably with a reduce. But then I start writing the block, and, like, I get way too into my head about the accumulator and what's going to happen.

+ +

So, my strategy for writing reduce expressions is to, instead of trying to figure out how to, like, do the whole thing together, first ask myself, how do I want to combine any two elements that are in the array? So, I've got an array of numbers, and I want to sum them all. What is the thing I need to do to combine just two of those? Forget the array. Figure that out.

+ +

And then, once I have that figured out, maybe it's an existing method like plus. Maybe it's a method I need to define on it if it's a custom object. Maybe it's a method that I write somewhere. Then, once I have that, I can say, okay, I can do it for two items. Now, I'm going to scale it up to work for the whole array, and I can plug it into reduce. And, at that point, the work is already basically done, so I don't end up with a really complex block. I don't end up, like, almost ending in, like, a recursive infinite loop in my head because I do that.

+ +

STEPHANIE: [laughs].

+ +

JOËL: So, that approach of saying, start by figuring out what is the operation you want to do to combine two elements, and then use reduce as a way to scale that to your whole array is a way that I've used to keep things simple in my mind.

+ +

STEPHANIE: Yeah, I like that a lot as a supplement to the model I shared earlier because, for me, when I think about reducing as, like, collapsing into a value, you kind of are just like, well, okay, I start with the collection, and then somehow I get to my single value. But the challenge is figuring out how that happens [laughs], like, the magic that happens in between that.

+ +

And I think another alias that we haven't mentioned yet for reduce that is used in a lot of other languages is fold. And I actually like that one a lot, and I think it relates to your mental model. Because when I think about folding, I'm picturing folding up a paper like an accordion. And you have to figure out, like, what is the first fold that I can make? And just repeating that over and over to get to your little stack of accordion paper [laughs]. And if you can figure out just that first step, then you pretty much, like, have the recipe for getting from your initial input to, like, your desired output.

+ +

JOËL: Yeah. I think fold is interesting in that some languages will make a distinction between fold and reduce. They will have both. And typically, fold will require you to pass an initial value, like a starting accumulator, to start it off. Whereas reduce will sort of assume that your array can use the first element of the array as the first accumulator.

+ +

STEPHANIE: Oh, I just came up with another visual metaphor for this, which is, like, folding butter into croissant pastry when the butter is your initial value [laughs].

+ +

JOËL: And then the crust is, I guess, the elements in the array.

+ +

STEPHANIE: Yeah. Yeah. And then you get a croissant out of it [laughs]. Don't ask me how it gets to a perfectly baked, flaky, beautiful croissant, but somehow that happens [laughs].

+ +

JOËL: So, there's an interesting sort of subtlety here that I think happens because there are sort of two slightly different ways that you can interact with a reduce. Sometimes, your accumulator is of the same type as the elements in your array. So, you're summing an array of numbers, and your accumulator is the sum, but each of the elements in the array are also numbers. So, it's numbers all the way through. And sometimes, your accumulator has a different type than the items in the array. So, maybe you have an array of words, and you want to get the sum of all of the characters and all the words. And so, now your accumulator is a number, but each of the items in the array are strings.

+ +

STEPHANIE: Yeah, that's an interesting distinction because I think that's where you start to see the complex blocks being passed and reduced.

+ +

JOËL: The complex blocks, definitely; I think they tend to show up when your accumulator has a different type than the individual items. So, maybe that's, like, a slightly more complicated use case. Oftentimes, too, the accumulator ends up being some, like, more complex, like, hash or something that maybe would really benefit from being a custom object.

+ +

STEPHANIE: I've never done that before, but I can see why that would be really useful. Do you have an example of when you used a custom object as the accumulator?

+ +

JOËL: So, I've done it for situations where I'm working with objects that are doing tally-like operations, but I'm not doing just a generic tally. There's some domain-specific stuff happening. So, it's some sort of aggregate counter on multiple dimensions that you can use, and that can get really ugly. And you can either do it with a reduce or you can have some sort of, like, initial version of the hash outside and do an each and mutate the hash and stuff like that. All of these tend to be a little bit ugly. So, in those situations, I've often created some sort of custom object that has some instance methods that allow to sort of easily add new elements to it.

+ +

STEPHANIE: That's really interesting because now I'm starting to think, what if the elements in the collection were also a custom object? [chuckles] And then things could, I feel like, could be really powerful [laughs].

+ +

JOËL: There's often a lot of value, right? Because if the items in the collection are also a custom object, you can then have methods on them. And then, again, the sort of complexity of the reduce can sort of, like, fade away because it doesn't own any of the logic. All it does is saying, hey, there's a thing you can do to combine two items. Let's scale it up to work on a collection of items. And now you've sort of, like, really simplified what logic is actually owned inside the reduce.

+ +

I do want to shout out for those listeners who are theory nerds and want to dig into this. When you have a reduce, and you've got an operation where all the values are of the same type, including the accumulator, typically, what you've got here is some form of monoid. It may be a semigroup. So, if you want to dig into some theory, those are the words to Google and to go a deep dive on.

+ +

The main thing about monoids, in particular, is that monoids are any objects that have both a sort of a base case, a sort of empty version of themselves, and they have some sort of combining method that allows you to combine two values of that type. If your object has these things and follows...there's a few rules that have to be true. You have a monoid. And they can then be sort of guaranteed to be folded nicely because you can plug in their base case as your initial accumulator. And you can plug in their combining method as just the value of the block, and everything else just falls into place.

+ +

A classic here is addition for numbers. So, if you want to add two numbers, your combining operator is a plus. And your sort of empty value is a zero. So, you would say, reduce initial value is zero, array of numbers. And your block is just plus, and it won't sum all of the numbers. You could do something similar with strings, where you can combine strings together with plus, and, you know, your empty string is your base case. So, now you're doing sort of string concatenation over arbitrary number of strings.

+ +

Turns out there's a lot of operations that fall into that, and you can even define some of those on your custom object. So, you're like, oh, I've got a custom object. Maybe I want some way of, like, combining two of them together. You might be heading in the direction of doing something that is monoidal, and if so, that's a really good hint to know that it can sort of, like, just drop into place with a fold or a reduce and that that is a tool that you have available to you.

+ +

STEPHANIE: Yeah, well, I think my eyes, like, widened a little bit when you first dropped the term monoid [laughs]. I do want to spend the last bit of our time talking about when not to use reduce, and, you know, we did talk a lot about recursion. But when do you think a regular old loop will just be enough?

+ +

JOËL: So, you're suggesting when would you want to use something like an each rather than a reduce?

+ +

STEPHANIE: Yeah. In my mind, you know, you did offer, like, a lot of ways to make reduce simpler, a lot of strategies to end up with some really nice-looking syntax [chuckles], I think. But, oftentimes, I think it can be equally as clear storing your accumulator outside of the iteration and that, like, is enough for me to understand. And reduce takes a little bit of extra overhead to figure out what I'm looking at. Do you have any thoughts about when you would prefer to do that? Or do you think that you would usually reach for something else?

+ +

JOËL: Personally, I generally don't like the pattern of using each to iterate over a collection and then mutate some external accumulator. That, to me, is a bit of a code smell. It's a sign that each is not quite powerful enough to do the thing that I want to do and that I'm probably needing some sort of more specialized form of iteration. Sometimes, that's reduce. Oftentimes, because each can suffer from the same problem you mentioned from reduce, where it's like, oh, you're doing this thing where you mutate an external accumulator. Turns out what you're really doing is just map. So, use map or use select or, you know, some of the other built-in iterators from the enumerable library.

+ +

There's a blog post on the thoughtbot blog that I continually link to people. And when I see the pattern of, like, mutating an external variable with each, yeah, I tend to see that as a bit of a code smell. I don't know that I would never do it, but whenever I see that, it's a sign to me to, like, pause and be like, wait a minute, is there a better way to do this?

+ +

STEPHANIE: Yeah, that's fair. I like the idea that, like, if there's already a method available to you that is more specific to go with that. But I also think that sometimes I'd rather, like, come across that pattern of mutating a variable outside of the iteration over, like, someone trying to do something clever with the reduce.

+ +

JOËL: Yeah, I guess reduce, especially if it's got, like, a giant block and you've got then, like, things in there that break or call next to skip iterations and things like that, that gets really mind-bending really quickly. I think a case where I might consider using an each over a reduce, and that's maybe generally when I tend to use each, is when I'm doing side effects. If I'm using a reduce, it's because I care about the accumulated value at the end. If I'm using each, it's typically because I am trying to do some amount of side effects.

+ +

STEPHANIE: Yeah, that's a really good call out. I had that written down in my notes, and I'm glad you brought it up because I've seen them get conflated a little bit, and perhaps maybe that's the source of the pain that I'm talking about. But I really like that heuristic of reduce as, you know, you're caring about the output, as opposed to what's going on inside. Like, you don't want any unexpected behavior.

+ +

JOËL: And I think that applies to something like map as well. My sort of heuristic is, if I'm doing side effects, I want each. If I want transformed values that are sort of one-to-one in the collection, I want map. If I want a single sort of aggregate value, then I want reduce.

+ +

STEPHANIE: I think that's the cool thing about mixing paradigms sometimes, where all the strategies you talked about in terms of, you know, using custom, like, objects for your accumulator, or the elements in your collection, like, that's something that we get because, you know, we're using an object-oriented language like Ruby. But then, like, you also are kind of bringing the functional programming lens to, like, when you would use reduce in the first place. And yeah, I am just really excited now [chuckles] to start looking for some places I can use reduce after this conversation and see what comes out of it.

+ +

JOËL: I think I went on a bit of an interesting journey where, as a newer programmer, reduce was just, like, really intense. And I struggled to understand it. And I was like, ban it from code. I don't want to ever see it. And then, I got into functional programming. I was like, I'm going to do reduce everywhere. And, honestly, it was kind of messy.

+ +

And then I, like, went really deep on a lot of functional theory, and I think understood some things that then I was able to take back to my code and actually write reduce expressions that are much simpler so that now my heuristic is like, I love reduce; I want to use it, but I want as little as possible in the reduce itself. And because I understand some of these other concepts, I have the ability to know what things can be extracted in a way that will feel very natural, in a way that myself from five years ago would have just been like, oh, I don't know. I've got this, you know, 30-line reduce expression that I know is complicated, but I don't know how to improve.

+ +

And so, a little bit of the underlying theory, I don't think it's necessary to understand these simplified reduces, but as an author who's writing them, I think it helps me write reduces that are simpler. So, that's been my journey using reduce.

+ +

STEPHANIE: Yeah. Well, thanks for sharing. And I'm really excited. I hope our listeners have learned some new things about reduce and can look at it from a different light.

+ +

JOËL: There are so many different perspectives. And I think we keep discovering new mental models as we talk to different people. It's like, oh, this particular perspective. And there's one that we didn't really dig into but that I think makes more sense in a functional world that's around sort of deconstructing a structure and then rebuilding it with different components. The shorthand name of this mental model, which is a fairly common one, is constructor replacement. For anyone who's interested in digging into that, we'll link it in the show notes.

+ +

I gave a talk at an Elm meetup where I sort of dug into some of that theory, which is really interesting and kind of mind-blowing. Not as relevant, I think, for Rubyists, but if you're in a language that particularly allows you to build custom structures out of recursive types or what are sometimes called algebraic data types, or tagged unions, or discriminated unions, this thing goes by a bajillion names, that is a really interesting other mental model to look at.

+ +

And, again, I don't think the list that we've covered today is exhaustive. You know, I would love it for any of our listeners; if you have your own mental models for how to think about folding, injecting, reducing, send them in: hosts@bikeshed.fm. We'd love to hear them.

+ +

STEPHANIE: And on that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-kRcQGfa + + ]]> + + Joël Quenneville + Stephanie Minn + + + 417: Module Docs + https://bikeshed.thoughtbot.com/417 + 88cb3031-0842-42d3-bed6-fceac6de4e2f + Tue, 05 Mar 2024 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie shares about her vacation at Disney World, particularly emphasizing the technological advancements in the park's mobile app that made her visit remarkably frictionless. Joël had a conversation about a topic he loves: units of measure, and he got to go deep into the idea of dimensional analysis with someone this week. + +Together, Joël and Stephanie talk about module documentation within software development. Joël shares his recent experience writing module docs for a Ruby project using the YARD documentation system. He highlights the time-consuming nature of crafting good documentation for each public method in a class, emphasizing that while it's a demanding task, it significantly benefits those who will use the code in the future. They explore the attributes of good documentation, including providing code examples, explaining expected usage, suggesting alternatives, discussing edge cases, linking to external resources, and detailing inputs, outputs, and potential side effects. + 39:32 + no + + + Stephanie shares about her vacation at Disney World, particularly emphasizing the technological advancements in the park's mobile app that made her visit remarkably frictionless. Joël had a conversation about a topic he loves: units of measure, and he got to go deep into the idea of dimensional analysis with someone this week. +Together, Joël and Stephanie talk about module documentation within software development. Joël shares his recent experience writing module docs for a Ruby project using the YARD documentation system. He highlights the time-consuming nature of crafting good documentation for each public method in a class, emphasizing that while it's a demanding task, it significantly benefits those who will use the code in the future. They explore the attributes of good documentation, including providing code examples, explaining expected usage, suggesting alternatives, discussing edge cases, linking to external resources, and detailing inputs, outputs, and potential side effects. +Multidimensional numbers episode (https://bikeshed.thoughtbot.com/416) +YARD docs (https://yardoc.org/) +New factory_bot documentation (https://thoughtbot.com/blog/new-docs-for-factory_bot) +Dash (https://kapeli.com/dash) +Solargraph (https://solargraph.org/) +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, I recently was on vacation, and I'm excited [chuckles] to tell our listeners all about it. I went to Disney World [laughs]. And honestly, I was especially struck by the tech that they used there. As a person who works in tech, I always kind of have a little bit of a different experience knowing a bit more about software, I suppose, than just your regular person [laughs], citizen. And so, at Disney World, I was really impressed by how seamlessly the like, quote, unquote, "real life experience" integrated with their use of their branded app to pair with, like, your time at the theme park. +JOËL: This is, like, an app that runs on your mobile device? +STEPHANIE: Yeah, it's a mobile app. I haven't been to Disney in a really long time. I think the last time I went was just as a kid, like, this was, you know, pre-mobile phones. So, I recall when you get into the line at a ride, you can skip the line by getting what's called a fast pass. And so, you kind of take a ticket, and it tells you a designated time to come back so that you could get into the fast line, and you don't have to wait as long. +And now all this stuff is on your mobile app, and I basically did not wait in [laughs] a single line for more than, like, five minutes to go on any of the rides I wanted. It just made a lot of sense that all these things that previously had more, like, physical touchstones, were made a bit more convenient. And I hesitate to use the word frictionless, but I would say that accurately describes the experience. +JOËL: That's kind of amazing; the idea that you can use tech to make a place that's incredibly busy also feel seamless and where you don't have to wait in line. +STEPHANIE: Yeah and, actually, I think the coolest part was it blended both your, like, physical experience really well with your digital one. I think that's kind of a gripe I have as a technologist [laughs] when I'm just kind of too immersed in my screen as opposed to the world around me. But I was really impressed by the way that they managed to make it, like, a really good supplement to your experience being there. +JOËL: So, you're not hyped for a future world where you can visit Disney in VR? +STEPHANIE: I mean, I just don't think it's the same. I rode a ride [laughs] where it was kind of like a mini roller coaster. It was called Expedition Everest. And there's a moment, this is, like, mostly indoors, but there's a moment where the roller coaster is going down outside, and you're getting that freefall, like, drop feeling in your stomach. And it also happened to be, like, drizzling that day that we were out there, and I could feel it, you know, like, pelting my head [laughs]. And until VR can replicate that experience [chuckles], I still think that going to Disney is pretty fun. +JOËL: Amazing. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I'm really excited because I had a conversation about a topic that I like to talk about: units of measure. And I got to go deep into the idea of dimensional analysis with someone this week. This is a technique where you can look at a calculation or a function and sort of spot-check whether it's correct by looking at whether the unit for the measure that would come out match what you would expect. So, you do math on the units and ignore the numbers coming into your formula. And, you know, let's say you're calculating the speed of something, and you get a distance and the amount of time it took you to take to go that distance. +And let's say your method implements this as distance times time. Forget about doing the actual math with the numbers here; just look at the units and say, okay, we've got our meters, and we've got our seconds, and we're multiplying them together. The unit that comes out of this method is meters times seconds. You happen to know that speeds are not measured in meters times seconds. They're measured in meters divided by seconds or meters per second. So, immediately, you get a sense of, like, wait a minute, something's wrong here. I must have a bug in my function. +STEPHANIE: Interesting. I'm curious how you're representing that data to, like, know if there's a bug or not. In my head, when you were talking about that, I'm like, oh yeah, I definitely recall doing, like, math problems for homework [laughs] where I had, you know, my meters per second. You have your little fractions written out, and then when you multiply or divide, you know how to, like, deal with the units on your piece of paper where you're showing your work. But I'm having a hard time imagining what that looks like as a programmer dealing with that problem. +JOËL: You could do it just all in your head based off of maybe some comments that you might have or the name of the variable or something. So, you're like, okay, well, I have a distance in meters and a time in seconds, and I'm multiplying the two. Therefore, what should be coming out is a value that is in meters times seconds. If you want to get fancier, you can do things with value objects of different types. So, you say, okay, I have a distance, and I have a time. And so, now I have sort of a multiplication of a distance and a time, and sort of what is that coming out as? +That can sometimes help you prevent from having some of these mistakes because you might have some kind of error that gets raised at runtime where it's like, hey, you're trying to multiply two units that shouldn't be multiplied, or whatever it is. You can also, in some languages, do this sort of thing automatically at the type level. So, instead of looking at it yourself and sort of inferring it all on your own based off of the written code, languages like F# have built-in unit-of-measure systems where once you sort of tag numbers as just being of a particular unit of measure, any time you do math with those numbers, it will then tag the result with whatever compound unit comes from that operation. +So, you have meters, and you have seconds. You divide one by the other, and now the result gets tagged as meters per second. And then, if you have another calculation that takes the output of the first one and it comes in, you can tell the compiler via type signature, hey, the input for this method needs to be in meters per second. And if the other calculation sort of automatically builds something that's of a different unit, you'll get a compilation error. So, it's really cool what it can do. +STEPHANIE: Yeah, that is really neat. I like all of those built-in guardrails, I suppose, to help you, you know, make sure that your answer is correct. Definitely could have used that [chuckles]. Turns out I just needed a calculator to take my math test with [laughs]. +JOËL: I think what I find valuable more than sort of the very rigorous approach is the mindset. So, anytime you're dealing with numbers, thinking in your mind, what is the unit of this number? When I do math with it with a different number, is it the same unit? Is it a different unit? What is the unit of the thing that's coming out? Does this operation make sense in the domain of my application? Because it's easy to sometimes think you're doing a math operation that makes sense, and then when you look at the unit, you're like, wait a minute, this does not make sense. +And I would go so far as to say that, you know, you might think, oh, I'm not doing a physics app. I don't care about units of measure. Most numbers in your app that are actually numbers are going to have some kind of unit of measure associated to them. Occasionally, you might have something where it's just, like, a straight-up, like, quantity or something like that. It's a dimensionless number. But most things will have some sort of unit. Maybe it's a number of dollars. Maybe it is an amount of time, a duration. It could be a distance. It could be all sorts of things. Typically, there is some sort of unit that should attach to it. +STEPHANIE: Yeah. That makes sense that you would want to be careful about making sure that your mathematical operations that you're doing when you're doing objects make sense. And we did talk about this in the last episode about multidimensional numbers a little bit. And I suppose I appreciate you saying that because I think I have mostly benefited from other people having thought in that mindset before and encoding, like I mentioned, those guardrails. +So, I can recall an app where I was working with, you know, some kind of currency or money object, and that error was raised when I would try to divide by zero because rather than kind of having to find out later with some, not a number or infinite [laughs] amount of money bug, it just didn't let me do that. And that wasn't something that I had really thought about, you know, I just hadn't considered that zero value edge case when I was working on whatever feature I was building. +JOËL: Yeah, or even just generally the idea of dividing money. What does that even mean? Are you taking an amount of money and splitting it into two equivalent piles to split among multiple people? That kind of makes sense. Are you dividing money by another money value? That's now asking a very different kind of question. +You're asking, like, what is the ratio between these two, I guess, piles of money if we want to make it, you know, in the physical world? Is that a thing that makes sense in your application? But also, realize that that ratio that you get back is not itself an amount of money. And so, there are some subtle bugs that can happen around that when you don't keep track of what your quantities are. +So, this past week, I've been working on a project where I ended up having to write module docs for the code in question. This is a Ruby project, so I'm writing docs using the YARD documentation system, where you effectively just write code comments at the sort of high level covering the entire class and then, also, individual documentation comments on each of the methods. And that's been really interesting because I have done this in other languages, but I'd never done it in Ruby before. And this is a piece of code that was kind of gnarly and had been tricky for me to figure out. And I figured that a couple of these classes could really benefit from some more in-depth documentation. +And I'm curious, in your experience, Stephanie, as someone who's writing code, using code from other people, and who I assume occasionally reads documentation, what are the things that you like to see in good sort of method-level docs? +STEPHANIE: Personally, I'm really only reading method-level docs when, you know, at this point, I'm, like, reaching for a method. I want to figure out how to use it in my use case right now [laughs]. So, I'm going to search API documentation for it. And I really am just scanning for inputs, especially, I think, and maybe looking at, you know, some potential various, like, options or, like, variations of how to use the method. But I'm kind of just searching for that at a glance and then moving on [laughs] with my day. That is kind of my main interaction with module docs like that, and especially ones for Ruby and Rails methods. +JOËL: And for clarity's sake, I think when we're talking about module docs here, I'm generally thinking of, like, any sort of documentation that sort of comments in code meant to document. It could be the whole modular class. It could be on a per-method level, things like RDoc or YARD docs on Ruby classes. You used the word API docs here. I think that's a pretty similar idea. +STEPHANIE: I really haven't given the idea of writing this kind of documentation a lot of thought because I've never had to do too much of it before, but I know, recently, you have been diving deep into it because, you know, like you said, you found these classes that you were working with a bit ambiguous, I suppose, or just confusing. And I'm wondering what kind of came out of that journey. What are some of the most interesting aspects of doing this exercise? +JOËL: And one of the big ones, and it's not a fun one, but it is time-consuming. Writing good docs per method for a couple of classes takes a lot of time, and I understand why people don't do it all the time. +STEPHANIE: What kinds of things were you finding warranted that time? Like, you know, you had to, at some point, decide, like, whether or not you're going to document any particular method. And what were some of the things you were looking out for as good reasons to do it? +JOËL: I was making the decisions to document or not document on a class level, and then every public method gets documentation. If there's a big public API, that means every single one of those methods is getting some documentation comments, explaining what they do, how they're meant to be used, things like that. I think my kind of conclusion, having worked with this, is that the sort of sweet spot for this sort of documentation is for anything that is library-like, so a lot of things that maybe would go into a Rails lib directory might make sense. Anything you're turning into a gem that probably makes sense. +And sometimes you have things in your Rails codebase that are effectively kind of library-like, and that was the case for the code that I was dealing with. It was almost like a mini ORM style kind of ActiveRecord-inspired series of base classes that had a bunch of metaprogramming to allow you to write models that were backed by not a database but a headless CMS, a content management system. And so, these classes are not extracted to the lib directory or, like, made into a gem, but they feel very library-esque in that way. +STEPHANIE: Library-like; I like that descriptor a lot because it immediately made me think of another example of a time when I've used or at least, like, consumed this type of documentation in a, like, SaaS repo. Rather, you know, I'm not really seeing that level of documentation around domain objects, but I noticed that they really did a lot of extending of the application record class because they just had some performance needs that they needed to write some, like, custom code to handle. +And so, they ended up kind of writing a lot of their own ORM-like methods for just some, like, custom callbacks on persisting and some just, like, bulk insertion functionality. And those came with a lot of different ways to use them. And I really appreciated that they were heavily documented, kind of like you would expect those ActiveRecord methods to be as well. +JOËL: So, I've been having some conversations with other members at thoughtbot about when they like to use the style of module doc. What are some of the alternatives? And one that kept coming up for different people that they would contrast with this is what they would call the big README approach, and this could be for a whole gem, or it could be maybe some directory with a few classes in your application that's got a README in the root of the directory. +And instead of documenting each method, you just write a giant README trying to answer sort of all of the questions that you anticipate people will ask. Is that something that you've seen, and how do you feel about that as a tool when you're looking for help? +STEPHANIE: Yes. I actually really like that style of documentation. I find that I just want examples to get me started, especially; I guess this is especially true for libraries that I'm not super familiar with but need to just get a working knowledge about kind of immediately. So, I like to see examples, the getting started, the just, like, here's what you need to know. And as I start to use them, that will get me rolling. But then, if I find I need more details, then I will try to seek out more specific information that might come in the form of class method documentation. +But I'm actually thinking about how FactoryBot has one of the best big README-esque [laughs] style of documentation, and I think they did a really big refresh of the docs not too long ago. It has all that high-level stuff, and then it has more specific information on how to use, you know, the most common methods to construct your factories. But those are very detailed, and yet they do sit, like, separately from inline, like, code documentation in the style of module docs that we're talking about. +So, it is kind of an interesting mix of both that I think is helpful for me personally when I want both the “what do I need to know now?” And the, “like, okay, I know where to look for if I need something a little more detailed.” +JOËL: Yeah. The two don't need to be mutually exclusive. I thought it was interesting that you mentioned how much examples are valuable to you because...I don't know if this is controversial, but an opinion that I have about sort of per-method documentation is that you should always default to having a code example for every method. I don't care how simple it is or how obvious it is what it does. Show me a code example because, as a developer, examples are really, really helpful. And so, seeing that makes documentation a lot more valuable than just a couple of lines that explain something that was maybe already obvious from the title of the method. I want to see it in action. +STEPHANIE: Interesting. Do you want to see it where the method definition is? +JOËL: Yes. Because sometimes the method definition, like, the implementation, might be sort of complex. And so, just seeing a couple of examples, like, oh, you call with this input, you get that. Call with this other input; you get this other thing. And we see this in, you know, some of the core docs for things like the enumerable methods where having an example there to be like, oh, so that's how map works. It returns this thing under these circumstances. That sort of thing is really helpful. +And then, I'll try to do it at a sort of a bigger level for that class itself. You have a whole paragraph about here's the purpose of the class. Here's how you should use it. And then, here's an example of how you might use it. Particularly, if this is some sort of, like, base class you're meant to inherit from, here's the circumstances you would want to subclass this, and then here's the methods you would likely want to override. +And maybe here are the DSLs you might want to have and to kind of package that in, like, a little example of, in this case, if you wanted a model that read from the headless CMS, here's what an example of such a little model might look like. So, it's kind of that putting it all together, which I think is nice in the module docs. It could probably also live in the big README at some level. +STEPHANIE: Yeah. As you are saying that, I also thought about how I usually go search for tests to find examples of usage, but I tend to get really overwhelmed when I see inline, like, that much inline documentation. I have to, like, either actively ignore it, choose to ignore it, or be like, okay, I'm reading this now [laughs]. Because it just takes up so much visual space, honestly. +And I know you put a lot of work into it, a lot of time, but maybe it's because of the color of my editor theme where comments are just that, like, light gray [laughs]. I find them quite easy to just ignore. But I'm sure there will be some time where I'm like, okay, like, if I need them, I know they're there. +JOËL: Yeah, that is, I think, a downside, right? It makes it harder to browse the code sometimes because maybe your entire screen is almost taken up by documentation, and then, you know, you have one method up, and you've got to, like, scroll through another page of documentation before you hit the next method, and that makes it harder to browse. And maybe that's something that plays into the idea of that separation between library-esque code versus application code. +When you browse library-esque code, when you're actually browsing the source, you're probably doing it for different reasons than you would for code in your application because, at that point, you're effectively source diving, sometimes being like, oh, I know this class probably has a method that will do the thing I want. Where is it? Or you're like, there's an edge case I don't understand on this method. I wonder what it does. Let me look at the implementation. Or even some existing code in the app is using this library method. I don't know what it does, but they call this method, and I can't figure out why they're using it. Let me look at the source of the library and see what it does under the hood. +STEPHANIE: Yeah. I like the distinction of it is kind of a different mindset that you're reading the code at, where, like, sometimes my brain is already ready to just read code and try to figure out inputs and outputs that way. And other times, I'm like, oh, like, I actually can't parse this right now [chuckles]. Like, I want to read just English, like, telling me what to expect or, like, what to look out for, especially when, like you said, I'm not really, like, trying to figure out some strange bug that would lead me to diving deep in the source code. It's I'm at the level where I'm just reaching for a method and wanting to use it. +We're writing these YARD docs. I think I also heard you mention that you gave some, like, tips or maybe some gotchas about how to use certain methods. I'm curious why that couldn't have been captured in a more, like, self-documenting way. Or was there a way that you could have written the code for that not to have been needed as a comment or documented as that? And was there a way that method names could have been clear to signal, like, the intention that you were trying to convey through your documentation? +JOËL: I'm a big fan of using method names as a form of documentation, but they're frequently not good enough. And I think comments, whether they're just regular inline comments or more official documentation, can be really good to help avoid sort of common pitfalls. And one that I was working with was, there were two methods, and one would find by a UID, so it would search up a document by UID. And another one would search by ID. +And when I was attempting to use these before I even started documenting, I used the wrong one, and it took me a while to realize, oh wait, these things have both UIDs and IDs, and they're slightly different, and sometimes you want to use one or the other. The method names, you know, said like, "Find by ID" or "Find by UID." I didn't realize there were both at the time because I wasn't browsing the source. I was just seeing a place where someone had used it. And then, when I did find it in the source, I'm like, well, what is the difference? +And so, something that I did when I wrote the docs was sort of call out on both of those methods; by the way, there is also find by UID. If you're searching by UID, consider using the other one. If you don't know what the difference is, here's a sentence summarizing the difference. And then, here's a link to external documentation if you want to dive into the nitty gritty of why there are two and what the differences are. And I think that's something you can't capture in just a method name. +STEPHANIE: Yeah, that's true. I like that a lot. Another use case you can think of is when method names are aliased, and it's like, I don't know how I would have possibly known that until I, you know, go through the journey of realizing [laughs] that these two methods do the same thing or, like, stumbling upon where the aliasing happens. +But if that were captured in, like, a little note when I'm in, like, a documentation viewer or something, it's just kind of, like, a little tidbit of knowledge [laughs] that I get to gain along the way that ends up, you know, being useful later because I will have just kind of...I will likely remember having seen something like that. And I can at least start my search with a little bit more context than when you don't know what you don't know. +JOËL: I put a lot of those sorts of notes on different methods. A lot of them are probably based on a personal story where I made a mistaken assumption about this method, and then it burned me. But I'm like, okay, nobody else is going to make that mistake. By the way, if you think this is what the method does, it does something slightly different and, you know, here's why you need to know that. +STEPHANIE: Yeah, you're just looking out for other devs. +JOËL: And, you know, trying to, like, take my maybe negative experience and saying like, "How can I get value out of that?" Maybe it doesn't feel great that I lost an hour to something weird about a method. But now that I have spent that hour, can I get value out of it? Is the sort of perspective I try to have on that. +So, you mentioned kind of offhand earlier the idea of a documentation viewer, which would be separate than just reading these, I guess, code comments directly in your code editor. What sort of documentation viewers do you like to use? +STEPHANIE: I mostly search in my browser, you know, just the official documentation websites for Rails, at least. And then I know that there are also various options for Ruby as well. And I think I had mentioned it before but using DuckDuckGo as my search engine. I have nice bang commands that will just take me straight to the search for those websites, which is really nice. Though, I have paired with people before who used various, like, macOS applications to do something similar. I think Alfred might have some built-in workflows for that. And then, a former co-worker used to use one called Dash, that I have seen before, too. So, it's another one of those just handy just, like, search productivity extensions. +JOËL: You mentioned the Rails documentation, and this is separate from the guides. But the actual Rails docs are generated from comments like this inline in code. So, all the different ActiveRecord methods, when you search on the Rails documentation you're like, oh yeah, how does find_by work? And they've got a whole, like, paragraph explaining how it works with a couple of examples. That's this kind of documentation. If you open up that particular file in the source code, you'll find the comments. +And it makes sense for Rails because Rails is more of, you know, library-esque code. And you and I search these docs pretty frequently, although we don't tend to do it, like, by opening the Rails gem and, like, grepping through the source to find the code comment. We do it through either a documentation site that's been compiled from that source or that documentation that's been extracted into an offline tool, like you'd mentioned, Dash. +STEPHANIE: Yeah, I realized how conflicting, I suppose, it is for me to say that I find inline documentation really overwhelming or visually distracting, whereas I recognize that the only reason I can have that nice, you know, viewing experience is because documentation viewers use the code comments in that format to be generated. +JOËL: I wonder if there's like a sort of...I don't know what this pattern is called, but a bit of a, like, middle-quality trap where if you're going to source dive, like, you'd rather just look at the code and not have too much clutter from sort of mediocre comments. But if the documentation is really good and you have the tooling to read it, then you don't even need to source dive at all. You can just read the documentation, and that's sufficient. +So, both extremes are good, but that sort of middle kind of one foot in each camp is sort of the worst of both worlds experience. Because I assume when you look for Rails documentation, you never open up the actual codebase to search. The documentation is good enough that you don't even need to look at the files with the comments and the code. +STEPHANIE: Yeah, and I'm just recalling now there's, like, a UI feature to view the source from the documentation viewer page. +JOËL: Yes. +STEPHANIE: I use that actually quite a bit if the comments are a little bit sparse and I need just the code to supplement my understanding, and that is really nice. But you're right, like, I very rarely would be source diving, unless it's a last resort [laughs], let's be honest. +JOËL: So, we've talked about documentation viewers and how that can make things nice, and you're able to read documentation for things. But a lot of other tooling can benefit from this sort of model documentation as well, and I'm thinking, in particular, Solargraph, which is Ruby's language server protocol. And it has plugins for VS Code, for Vim, for a few different editors, takes advantage of that to provide all sorts of things. +So, you can get smart expansion of code and good suggestions. You can get documentation for what's under your cursor. Maybe you're reading somebody else's code that they've written, and you're like, why are they calling this parameterized method here? What does that even do? Like, in VS Code, you could just hover over it, and it will pop up and show you documentation, including the, like, inputs and return types, and things like that. That's pretty nifty. +STEPHANIE: Yeah, that is cool. I use VS Code, but I've not seen that too much yet because I don't think I've worked in enough codebases with really comprehensive [laughs] YARD docs. I'm actually wondering, tooling-wise, did you use any helpful tools when you were writing them or were you hand-documenting each? +JOËL: I was hand-documenting everything. +STEPHANIE: Class. Okay. +JOËL: The thing that I did use is the YARD gem, which you don't need to have the gem to write YARD-style documentation. But if you have the gem, you can run a local server and then preview a documentation site that is generated from your comments that has everything in there. And that was incredibly helpful for me as I was trying to sort of see an overview of, okay, what would someone who's looking at the docs generated from this see when they're trying to look for what the documentation of a particular method does? +STEPHANIE: Yeah, and that's really nice. +JOËL: Something that I am curious about that I've not really had a lot of experience with is whether or not having extra documentation like that can help AI tools give us better suggestions. +STEPHANIE: Yeah, I don't know the answer to that either, but I would be really curious to know if that is already something that happens with something like Copilot. +JOËL: Do better docs help machines, or are they for humans only? +STEPHANIE: Whoa, that's a very [laughs] philosophical question, I think. It would make sense, though, that if we already have ways to parse and compile this kind of documentation, then I can see that incorporating them into the types of, like, generative problems that AI quote, unquote "solves" [chuckles] would be really interesting to find out. But anyone listening who kind of knows the answer to that or has experience working with AI tools and various types of code comment documentation would be really curious to know what your experience is like and if it improves your development workflow. +So, for people who might be interested in getting better at documenting their code in the style of module docs, what would you say are some really great attributes of good documentation in this form? +JOËL: I think, first of all, you have to write from the motivation of, like, if you were confused and wanting to better understand what a method does, what would you like to see? And I think coming from that perspective, and that was, in my case, I had been that person, and then I was like, okay, now that I've figured it out, I'm going to write it so that the next person is not confused. +I have five or six things that I think were really valuable to add to the docs, a few of which we've already mentioned. But rapid fire, first of all, code example. I love code examples. I want a code example on every method. An explanation of expected usage. Here's what the method does. Here's how we expect you to use this method in any extra context about sort of intended use. +Callouts for suggested alternatives. If there are methods that are similar, or there's maybe a sort of common mistake that you would reach for this method, put some sort of call out to say, "Hey, you probably came here trying to do X. If that's what you were actually trying to do, you should use method Y." Beyond that, a discussion of edge cases, so any sort of weird ways the method behaves. You know, when you pass nil to it, does it behave differently? If you call it in a different context, does it behave differently? I want to know that so that I'm not totally surprised. +Links to external resources–really great if I want to, like, dig deeper. Is this method built on some sort of, like, algorithm that's documented elsewhere? Please link to that algorithm. Is this method integrating with some, like, third-party API? You know, they have some documentation that we could link to to go deeper into, like, what these search options do. Link to that. External links are great. I could probably find it by Googling myself, but you are going to make me very happy as a developer if you already give me the link. +You'd mentioned capturing inputs and outputs. That's a great thing to scan for. Inputs and outputs, though, are more sometimes than just the arguments and return values. Although if we're talking about arguments, any sort of options hash, please document the keys that go in that because that's often not obvious from the code. And I've spent a lot of time source diving and jumping between methods trying to figure out like, what are the options I can pass to this hash? +Beyond the explicit inputs and outputs, though, anything that is global state that you rely on. So, do you need to read something from an environment variable or even a global variable or something like that that might make this method behave differently in different situations? Please document that. Any situations where you might raise an error that I might not expect or that I might want to rescue from, let me know what are the potential errors that might get raised. +And then, finally, any sorts of side effects. Does this method make a network call? Are you writing to the file system? I'd like to know that, and I'd have to, like, figure it out by trial and error. And sometimes, it will be obvious in just the description of the method, right? Oh, this method pulls data from a third-party API. That's pretty clear. But maybe it does some sort of, like, caching in the background or something to a file that's not really important. But maybe I'm trying to do a unit test that involves this, and now, all of a sudden, I have to do some weird stubbing. I'd like to know that upfront. +So, those are kind of all the things I would love to have in my sort of ideal documentation comment that would make my life easier as a developer when trying to use some code. +STEPHANIE: Wow. What a passionate plea [laughs]. I was very into listening to you list all of that. You got very animated. And it makes a lot of sense because I feel like these are kind of just the day-to-day developer issues we run into in our work and would be so awesome if, especially as the, you know, author where you have figured all of this stuff out, the author of a, you know, a method or a class, to just kind of tell us these things so we don't have to figure it out ourselves. +I guess I also have to respond to that by saying, on one hand, I totally get, like, you want to be saved [chuckles] from those common pitfalls. But I think that part of our work is just going through that and playing around and exploring with the code in front of us, and we learn all of that along the way. And, ultimately, even if that is all provided to you, there is something about, like, going through it yourself that gives you a different perspective on it. +And, I don't know, maybe it's just my bias against [laughs] all the inline text, but I've also seen a lot of that type of information captured at different levels of documentation. So, maybe it is a Confluence doc or in a wiki talking about, you know, common gotchas for this particular problem that they were trying to solve. And I think what's really cool is that, you know, everyone can kind of be served and that people have different needs that different styles of documentation can meet. +So, for anyone diving deep in the source code, they can see all of those examples inline. But, for me, as a big Googler [laughs], I want to see just a nice, little web app to get me the information that I need to find. I'm happy having that a little bit more, like, extracted from my source code. +JOËL: Right. You don't want to have to read the source code with all the comments in it. I think that's a fair criticism and, yeah, probably a downside of this. And I'm wondering, there might be some editor tooling that allows you to just collapse all comments and hide them if you wanted to focus on just the code. +STEPHANIE: Yeah, someone, please build that for me. That's my passionate plea [laughs]. And on that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Bye. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Stephanie shares about her vacation at Disney World, particularly emphasizing the technological advancements in the park's mobile app that made her visit remarkably frictionless. Joël had a conversation about a topic he loves: units of measure, and he got to go deep into the idea of dimensional analysis with someone this week.

+ +

Together, Joël and Stephanie talk about module documentation within software development. Joël shares his recent experience writing module docs for a Ruby project using the YARD documentation system. He highlights the time-consuming nature of crafting good documentation for each public method in a class, emphasizing that while it's a demanding task, it significantly benefits those who will use the code in the future. They explore the attributes of good documentation, including providing code examples, explaining expected usage, suggesting alternatives, discussing edge cases, linking to external resources, and detailing inputs, outputs, and potential side effects.

+ +
+ + + +

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, I recently was on vacation, and I'm excited [chuckles] to tell our listeners all about it. I went to Disney World [laughs]. And honestly, I was especially struck by the tech that they used there. As a person who works in tech, I always kind of have a little bit of a different experience knowing a bit more about software, I suppose, than just your regular person [laughs], citizen. And so, at Disney World, I was really impressed by how seamlessly the like, quote, unquote, "real life experience" integrated with their use of their branded app to pair with, like, your time at the theme park.

+ +

JOËL: This is, like, an app that runs on your mobile device?

+ +

STEPHANIE: Yeah, it's a mobile app. I haven't been to Disney in a really long time. I think the last time I went was just as a kid, like, this was, you know, pre-mobile phones. So, I recall when you get into the line at a ride, you can skip the line by getting what's called a fast pass. And so, you kind of take a ticket, and it tells you a designated time to come back so that you could get into the fast line, and you don't have to wait as long.

+ +

And now all this stuff is on your mobile app, and I basically did not wait in [laughs] a single line for more than, like, five minutes to go on any of the rides I wanted. It just made a lot of sense that all these things that previously had more, like, physical touchstones, were made a bit more convenient. And I hesitate to use the word frictionless, but I would say that accurately describes the experience.

+ +

JOËL: That's kind of amazing; the idea that you can use tech to make a place that's incredibly busy also feel seamless and where you don't have to wait in line.

+ +

STEPHANIE: Yeah and, actually, I think the coolest part was it blended both your, like, physical experience really well with your digital one. I think that's kind of a gripe I have as a technologist [laughs] when I'm just kind of too immersed in my screen as opposed to the world around me. But I was really impressed by the way that they managed to make it, like, a really good supplement to your experience being there.

+ +

JOËL: So, you're not hyped for a future world where you can visit Disney in VR?

+ +

STEPHANIE: I mean, I just don't think it's the same. I rode a ride [laughs] where it was kind of like a mini roller coaster. It was called Expedition Everest. And there's a moment, this is, like, mostly indoors, but there's a moment where the roller coaster is going down outside, and you're getting that freefall, like, drop feeling in your stomach. And it also happened to be, like, drizzling that day that we were out there, and I could feel it, you know, like, pelting my head [laughs]. And until VR can replicate that experience [chuckles], I still think that going to Disney is pretty fun.

+ +

JOËL: Amazing.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I'm really excited because I had a conversation about a topic that I like to talk about: units of measure. And I got to go deep into the idea of dimensional analysis with someone this week. This is a technique where you can look at a calculation or a function and sort of spot-check whether it's correct by looking at whether the unit for the measure that would come out match what you would expect. So, you do math on the units and ignore the numbers coming into your formula. And, you know, let's say you're calculating the speed of something, and you get a distance and the amount of time it took you to take to go that distance.

+ +

And let's say your method implements this as distance times time. Forget about doing the actual math with the numbers here; just look at the units and say, okay, we've got our meters, and we've got our seconds, and we're multiplying them together. The unit that comes out of this method is meters times seconds. You happen to know that speeds are not measured in meters times seconds. They're measured in meters divided by seconds or meters per second. So, immediately, you get a sense of, like, wait a minute, something's wrong here. I must have a bug in my function.

+ +

STEPHANIE: Interesting. I'm curious how you're representing that data to, like, know if there's a bug or not. In my head, when you were talking about that, I'm like, oh yeah, I definitely recall doing, like, math problems for homework [laughs] where I had, you know, my meters per second. You have your little fractions written out, and then when you multiply or divide, you know how to, like, deal with the units on your piece of paper where you're showing your work. But I'm having a hard time imagining what that looks like as a programmer dealing with that problem.

+ +

JOËL: You could do it just all in your head based off of maybe some comments that you might have or the name of the variable or something. So, you're like, okay, well, I have a distance in meters and a time in seconds, and I'm multiplying the two. Therefore, what should be coming out is a value that is in meters times seconds. If you want to get fancier, you can do things with value objects of different types. So, you say, okay, I have a distance, and I have a time. And so, now I have sort of a multiplication of a distance and a time, and sort of what is that coming out as?

+ +

That can sometimes help you prevent from having some of these mistakes because you might have some kind of error that gets raised at runtime where it's like, hey, you're trying to multiply two units that shouldn't be multiplied, or whatever it is. You can also, in some languages, do this sort of thing automatically at the type level. So, instead of looking at it yourself and sort of inferring it all on your own based off of the written code, languages like F# have built-in unit-of-measure systems where once you sort of tag numbers as just being of a particular unit of measure, any time you do math with those numbers, it will then tag the result with whatever compound unit comes from that operation.

+ +

So, you have meters, and you have seconds. You divide one by the other, and now the result gets tagged as meters per second. And then, if you have another calculation that takes the output of the first one and it comes in, you can tell the compiler via type signature, hey, the input for this method needs to be in meters per second. And if the other calculation sort of automatically builds something that's of a different unit, you'll get a compilation error. So, it's really cool what it can do.

+ +

STEPHANIE: Yeah, that is really neat. I like all of those built-in guardrails, I suppose, to help you, you know, make sure that your answer is correct. Definitely could have used that [chuckles]. Turns out I just needed a calculator to take my math test with [laughs].

+ +

JOËL: I think what I find valuable more than sort of the very rigorous approach is the mindset. So, anytime you're dealing with numbers, thinking in your mind, what is the unit of this number? When I do math with it with a different number, is it the same unit? Is it a different unit? What is the unit of the thing that's coming out? Does this operation make sense in the domain of my application? Because it's easy to sometimes think you're doing a math operation that makes sense, and then when you look at the unit, you're like, wait a minute, this does not make sense.

+ +

And I would go so far as to say that, you know, you might think, oh, I'm not doing a physics app. I don't care about units of measure. Most numbers in your app that are actually numbers are going to have some kind of unit of measure associated to them. Occasionally, you might have something where it's just, like, a straight-up, like, quantity or something like that. It's a dimensionless number. But most things will have some sort of unit. Maybe it's a number of dollars. Maybe it is an amount of time, a duration. It could be a distance. It could be all sorts of things. Typically, there is some sort of unit that should attach to it.

+ +

STEPHANIE: Yeah. That makes sense that you would want to be careful about making sure that your mathematical operations that you're doing when you're doing objects make sense. And we did talk about this in the last episode about multidimensional numbers a little bit. And I suppose I appreciate you saying that because I think I have mostly benefited from other people having thought in that mindset before and encoding, like I mentioned, those guardrails.

+ +

So, I can recall an app where I was working with, you know, some kind of currency or money object, and that error was raised when I would try to divide by zero because rather than kind of having to find out later with some, not a number or infinite [laughs] amount of money bug, it just didn't let me do that. And that wasn't something that I had really thought about, you know, I just hadn't considered that zero value edge case when I was working on whatever feature I was building.

+ +

JOËL: Yeah, or even just generally the idea of dividing money. What does that even mean? Are you taking an amount of money and splitting it into two equivalent piles to split among multiple people? That kind of makes sense. Are you dividing money by another money value? That's now asking a very different kind of question.

+ +

You're asking, like, what is the ratio between these two, I guess, piles of money if we want to make it, you know, in the physical world? Is that a thing that makes sense in your application? But also, realize that that ratio that you get back is not itself an amount of money. And so, there are some subtle bugs that can happen around that when you don't keep track of what your quantities are.

+ +

So, this past week, I've been working on a project where I ended up having to write module docs for the code in question. This is a Ruby project, so I'm writing docs using the YARD documentation system, where you effectively just write code comments at the sort of high level covering the entire class and then, also, individual documentation comments on each of the methods. And that's been really interesting because I have done this in other languages, but I'd never done it in Ruby before. And this is a piece of code that was kind of gnarly and had been tricky for me to figure out. And I figured that a couple of these classes could really benefit from some more in-depth documentation.

+ +

And I'm curious, in your experience, Stephanie, as someone who's writing code, using code from other people, and who I assume occasionally reads documentation, what are the things that you like to see in good sort of method-level docs?

+ +

STEPHANIE: Personally, I'm really only reading method-level docs when, you know, at this point, I'm, like, reaching for a method. I want to figure out how to use it in my use case right now [laughs]. So, I'm going to search API documentation for it. And I really am just scanning for inputs, especially, I think, and maybe looking at, you know, some potential various, like, options or, like, variations of how to use the method. But I'm kind of just searching for that at a glance and then moving on [laughs] with my day. That is kind of my main interaction with module docs like that, and especially ones for Ruby and Rails methods.

+ +

JOËL: And for clarity's sake, I think when we're talking about module docs here, I'm generally thinking of, like, any sort of documentation that sort of comments in code meant to document. It could be the whole modular class. It could be on a per-method level, things like RDoc or YARD docs on Ruby classes. You used the word API docs here. I think that's a pretty similar idea.

+ +

STEPHANIE: I really haven't given the idea of writing this kind of documentation a lot of thought because I've never had to do too much of it before, but I know, recently, you have been diving deep into it because, you know, like you said, you found these classes that you were working with a bit ambiguous, I suppose, or just confusing. And I'm wondering what kind of came out of that journey. What are some of the most interesting aspects of doing this exercise?

+ +

JOËL: And one of the big ones, and it's not a fun one, but it is time-consuming. Writing good docs per method for a couple of classes takes a lot of time, and I understand why people don't do it all the time.

+ +

STEPHANIE: What kinds of things were you finding warranted that time? Like, you know, you had to, at some point, decide, like, whether or not you're going to document any particular method. And what were some of the things you were looking out for as good reasons to do it?

+ +

JOËL: I was making the decisions to document or not document on a class level, and then every public method gets documentation. If there's a big public API, that means every single one of those methods is getting some documentation comments, explaining what they do, how they're meant to be used, things like that. I think my kind of conclusion, having worked with this, is that the sort of sweet spot for this sort of documentation is for anything that is library-like, so a lot of things that maybe would go into a Rails lib directory might make sense. Anything you're turning into a gem that probably makes sense.

+ +

And sometimes you have things in your Rails codebase that are effectively kind of library-like, and that was the case for the code that I was dealing with. It was almost like a mini ORM style kind of ActiveRecord-inspired series of base classes that had a bunch of metaprogramming to allow you to write models that were backed by not a database but a headless CMS, a content management system. And so, these classes are not extracted to the lib directory or, like, made into a gem, but they feel very library-esque in that way.

+ +

STEPHANIE: Library-like; I like that descriptor a lot because it immediately made me think of another example of a time when I've used or at least, like, consumed this type of documentation in a, like, SaaS repo. Rather, you know, I'm not really seeing that level of documentation around domain objects, but I noticed that they really did a lot of extending of the application record class because they just had some performance needs that they needed to write some, like, custom code to handle.

+ +

And so, they ended up kind of writing a lot of their own ORM-like methods for just some, like, custom callbacks on persisting and some just, like, bulk insertion functionality. And those came with a lot of different ways to use them. And I really appreciated that they were heavily documented, kind of like you would expect those ActiveRecord methods to be as well.

+ +

JOËL: So, I've been having some conversations with other members at thoughtbot about when they like to use the style of module doc. What are some of the alternatives? And one that kept coming up for different people that they would contrast with this is what they would call the big README approach, and this could be for a whole gem, or it could be maybe some directory with a few classes in your application that's got a README in the root of the directory.

+ +

And instead of documenting each method, you just write a giant README trying to answer sort of all of the questions that you anticipate people will ask. Is that something that you've seen, and how do you feel about that as a tool when you're looking for help?

+ +

STEPHANIE: Yes. I actually really like that style of documentation. I find that I just want examples to get me started, especially; I guess this is especially true for libraries that I'm not super familiar with but need to just get a working knowledge about kind of immediately. So, I like to see examples, the getting started, the just, like, here's what you need to know. And as I start to use them, that will get me rolling. But then, if I find I need more details, then I will try to seek out more specific information that might come in the form of class method documentation.

+ +

But I'm actually thinking about how FactoryBot has one of the best big README-esque [laughs] style of documentation, and I think they did a really big refresh of the docs not too long ago. It has all that high-level stuff, and then it has more specific information on how to use, you know, the most common methods to construct your factories. But those are very detailed, and yet they do sit, like, separately from inline, like, code documentation in the style of module docs that we're talking about.

+ +

So, it is kind of an interesting mix of both that I think is helpful for me personally when I want both the “what do I need to know now?” And the, “like, okay, I know where to look for if I need something a little more detailed.”

+ +

JOËL: Yeah. The two don't need to be mutually exclusive. I thought it was interesting that you mentioned how much examples are valuable to you because...I don't know if this is controversial, but an opinion that I have about sort of per-method documentation is that you should always default to having a code example for every method. I don't care how simple it is or how obvious it is what it does. Show me a code example because, as a developer, examples are really, really helpful. And so, seeing that makes documentation a lot more valuable than just a couple of lines that explain something that was maybe already obvious from the title of the method. I want to see it in action.

+ +

STEPHANIE: Interesting. Do you want to see it where the method definition is?

+ +

JOËL: Yes. Because sometimes the method definition, like, the implementation, might be sort of complex. And so, just seeing a couple of examples, like, oh, you call with this input, you get that. Call with this other input; you get this other thing. And we see this in, you know, some of the core docs for things like the enumerable methods where having an example there to be like, oh, so that's how map works. It returns this thing under these circumstances. That sort of thing is really helpful.

+ +

And then, I'll try to do it at a sort of a bigger level for that class itself. You have a whole paragraph about here's the purpose of the class. Here's how you should use it. And then, here's an example of how you might use it. Particularly, if this is some sort of, like, base class you're meant to inherit from, here's the circumstances you would want to subclass this, and then here's the methods you would likely want to override.

+ +

And maybe here are the DSLs you might want to have and to kind of package that in, like, a little example of, in this case, if you wanted a model that read from the headless CMS, here's what an example of such a little model might look like. So, it's kind of that putting it all together, which I think is nice in the module docs. It could probably also live in the big README at some level.

+ +

STEPHANIE: Yeah. As you are saying that, I also thought about how I usually go search for tests to find examples of usage, but I tend to get really overwhelmed when I see inline, like, that much inline documentation. I have to, like, either actively ignore it, choose to ignore it, or be like, okay, I'm reading this now [laughs]. Because it just takes up so much visual space, honestly.

+ +

And I know you put a lot of work into it, a lot of time, but maybe it's because of the color of my editor theme where comments are just that, like, light gray [laughs]. I find them quite easy to just ignore. But I'm sure there will be some time where I'm like, okay, like, if I need them, I know they're there.

+ +

JOËL: Yeah, that is, I think, a downside, right? It makes it harder to browse the code sometimes because maybe your entire screen is almost taken up by documentation, and then, you know, you have one method up, and you've got to, like, scroll through another page of documentation before you hit the next method, and that makes it harder to browse. And maybe that's something that plays into the idea of that separation between library-esque code versus application code.

+ +

When you browse library-esque code, when you're actually browsing the source, you're probably doing it for different reasons than you would for code in your application because, at that point, you're effectively source diving, sometimes being like, oh, I know this class probably has a method that will do the thing I want. Where is it? Or you're like, there's an edge case I don't understand on this method. I wonder what it does. Let me look at the implementation. Or even some existing code in the app is using this library method. I don't know what it does, but they call this method, and I can't figure out why they're using it. Let me look at the source of the library and see what it does under the hood.

+ +

STEPHANIE: Yeah. I like the distinction of it is kind of a different mindset that you're reading the code at, where, like, sometimes my brain is already ready to just read code and try to figure out inputs and outputs that way. And other times, I'm like, oh, like, I actually can't parse this right now [chuckles]. Like, I want to read just English, like, telling me what to expect or, like, what to look out for, especially when, like you said, I'm not really, like, trying to figure out some strange bug that would lead me to diving deep in the source code. It's I'm at the level where I'm just reaching for a method and wanting to use it.

+ +

We're writing these YARD docs. I think I also heard you mention that you gave some, like, tips or maybe some gotchas about how to use certain methods. I'm curious why that couldn't have been captured in a more, like, self-documenting way. Or was there a way that you could have written the code for that not to have been needed as a comment or documented as that? And was there a way that method names could have been clear to signal, like, the intention that you were trying to convey through your documentation?

+ +

JOËL: I'm a big fan of using method names as a form of documentation, but they're frequently not good enough. And I think comments, whether they're just regular inline comments or more official documentation, can be really good to help avoid sort of common pitfalls. And one that I was working with was, there were two methods, and one would find by a UID, so it would search up a document by UID. And another one would search by ID.

+ +

And when I was attempting to use these before I even started documenting, I used the wrong one, and it took me a while to realize, oh wait, these things have both UIDs and IDs, and they're slightly different, and sometimes you want to use one or the other. The method names, you know, said like, "Find by ID" or "Find by UID." I didn't realize there were both at the time because I wasn't browsing the source. I was just seeing a place where someone had used it. And then, when I did find it in the source, I'm like, well, what is the difference?

+ +

And so, something that I did when I wrote the docs was sort of call out on both of those methods; by the way, there is also find by UID. If you're searching by UID, consider using the other one. If you don't know what the difference is, here's a sentence summarizing the difference. And then, here's a link to external documentation if you want to dive into the nitty gritty of why there are two and what the differences are. And I think that's something you can't capture in just a method name.

+ +

STEPHANIE: Yeah, that's true. I like that a lot. Another use case you can think of is when method names are aliased, and it's like, I don't know how I would have possibly known that until I, you know, go through the journey of realizing [laughs] that these two methods do the same thing or, like, stumbling upon where the aliasing happens.

+ +

But if that were captured in, like, a little note when I'm in, like, a documentation viewer or something, it's just kind of, like, a little tidbit of knowledge [laughs] that I get to gain along the way that ends up, you know, being useful later because I will have just kind of...I will likely remember having seen something like that. And I can at least start my search with a little bit more context than when you don't know what you don't know.

+ +

JOËL: I put a lot of those sorts of notes on different methods. A lot of them are probably based on a personal story where I made a mistaken assumption about this method, and then it burned me. But I'm like, okay, nobody else is going to make that mistake. By the way, if you think this is what the method does, it does something slightly different and, you know, here's why you need to know that.

+ +

STEPHANIE: Yeah, you're just looking out for other devs.

+ +

JOËL: And, you know, trying to, like, take my maybe negative experience and saying like, "How can I get value out of that?" Maybe it doesn't feel great that I lost an hour to something weird about a method. But now that I have spent that hour, can I get value out of it? Is the sort of perspective I try to have on that.

+ +

So, you mentioned kind of offhand earlier the idea of a documentation viewer, which would be separate than just reading these, I guess, code comments directly in your code editor. What sort of documentation viewers do you like to use?

+ +

STEPHANIE: I mostly search in my browser, you know, just the official documentation websites for Rails, at least. And then I know that there are also various options for Ruby as well. And I think I had mentioned it before but using DuckDuckGo as my search engine. I have nice bang commands that will just take me straight to the search for those websites, which is really nice. Though, I have paired with people before who used various, like, macOS applications to do something similar. I think Alfred might have some built-in workflows for that. And then, a former co-worker used to use one called Dash, that I have seen before, too. So, it's another one of those just handy just, like, search productivity extensions.

+ +

JOËL: You mentioned the Rails documentation, and this is separate from the guides. But the actual Rails docs are generated from comments like this inline in code. So, all the different ActiveRecord methods, when you search on the Rails documentation you're like, oh yeah, how does find_by work? And they've got a whole, like, paragraph explaining how it works with a couple of examples. That's this kind of documentation. If you open up that particular file in the source code, you'll find the comments.

+ +

And it makes sense for Rails because Rails is more of, you know, library-esque code. And you and I search these docs pretty frequently, although we don't tend to do it, like, by opening the Rails gem and, like, grepping through the source to find the code comment. We do it through either a documentation site that's been compiled from that source or that documentation that's been extracted into an offline tool, like you'd mentioned, Dash.

+ +

STEPHANIE: Yeah, I realized how conflicting, I suppose, it is for me to say that I find inline documentation really overwhelming or visually distracting, whereas I recognize that the only reason I can have that nice, you know, viewing experience is because documentation viewers use the code comments in that format to be generated.

+ +

JOËL: I wonder if there's like a sort of...I don't know what this pattern is called, but a bit of a, like, middle-quality trap where if you're going to source dive, like, you'd rather just look at the code and not have too much clutter from sort of mediocre comments. But if the documentation is really good and you have the tooling to read it, then you don't even need to source dive at all. You can just read the documentation, and that's sufficient.

+ +

So, both extremes are good, but that sort of middle kind of one foot in each camp is sort of the worst of both worlds experience. Because I assume when you look for Rails documentation, you never open up the actual codebase to search. The documentation is good enough that you don't even need to look at the files with the comments and the code.

+ +

STEPHANIE: Yeah, and I'm just recalling now there's, like, a UI feature to view the source from the documentation viewer page.

+ +

JOËL: Yes.

+ +

STEPHANIE: I use that actually quite a bit if the comments are a little bit sparse and I need just the code to supplement my understanding, and that is really nice. But you're right, like, I very rarely would be source diving, unless it's a last resort [laughs], let's be honest.

+ +

JOËL: So, we've talked about documentation viewers and how that can make things nice, and you're able to read documentation for things. But a lot of other tooling can benefit from this sort of model documentation as well, and I'm thinking, in particular, Solargraph, which is Ruby's language server protocol. And it has plugins for VS Code, for Vim, for a few different editors, takes advantage of that to provide all sorts of things.

+ +

So, you can get smart expansion of code and good suggestions. You can get documentation for what's under your cursor. Maybe you're reading somebody else's code that they've written, and you're like, why are they calling this parameterized method here? What does that even do? Like, in VS Code, you could just hover over it, and it will pop up and show you documentation, including the, like, inputs and return types, and things like that. That's pretty nifty.

+ +

STEPHANIE: Yeah, that is cool. I use VS Code, but I've not seen that too much yet because I don't think I've worked in enough codebases with really comprehensive [laughs] YARD docs. I'm actually wondering, tooling-wise, did you use any helpful tools when you were writing them or were you hand-documenting each?

+ +

JOËL: I was hand-documenting everything.

+ +

STEPHANIE: Class. Okay.

+ +

JOËL: The thing that I did use is the YARD gem, which you don't need to have the gem to write YARD-style documentation. But if you have the gem, you can run a local server and then preview a documentation site that is generated from your comments that has everything in there. And that was incredibly helpful for me as I was trying to sort of see an overview of, okay, what would someone who's looking at the docs generated from this see when they're trying to look for what the documentation of a particular method does?

+ +

STEPHANIE: Yeah, and that's really nice.

+ +

JOËL: Something that I am curious about that I've not really had a lot of experience with is whether or not having extra documentation like that can help AI tools give us better suggestions.

+ +

STEPHANIE: Yeah, I don't know the answer to that either, but I would be really curious to know if that is already something that happens with something like Copilot.

+ +

JOËL: Do better docs help machines, or are they for humans only?

+ +

STEPHANIE: Whoa, that's a very [laughs] philosophical question, I think. It would make sense, though, that if we already have ways to parse and compile this kind of documentation, then I can see that incorporating them into the types of, like, generative problems that AI quote, unquote "solves" [chuckles] would be really interesting to find out. But anyone listening who kind of knows the answer to that or has experience working with AI tools and various types of code comment documentation would be really curious to know what your experience is like and if it improves your development workflow.

+ +

So, for people who might be interested in getting better at documenting their code in the style of module docs, what would you say are some really great attributes of good documentation in this form?

+ +

JOËL: I think, first of all, you have to write from the motivation of, like, if you were confused and wanting to better understand what a method does, what would you like to see? And I think coming from that perspective, and that was, in my case, I had been that person, and then I was like, okay, now that I've figured it out, I'm going to write it so that the next person is not confused.

+ +

I have five or six things that I think were really valuable to add to the docs, a few of which we've already mentioned. But rapid fire, first of all, code example. I love code examples. I want a code example on every method. An explanation of expected usage. Here's what the method does. Here's how we expect you to use this method in any extra context about sort of intended use.

+ +

Callouts for suggested alternatives. If there are methods that are similar, or there's maybe a sort of common mistake that you would reach for this method, put some sort of call out to say, "Hey, you probably came here trying to do X. If that's what you were actually trying to do, you should use method Y." Beyond that, a discussion of edge cases, so any sort of weird ways the method behaves. You know, when you pass nil to it, does it behave differently? If you call it in a different context, does it behave differently? I want to know that so that I'm not totally surprised.

+ +

Links to external resources–really great if I want to, like, dig deeper. Is this method built on some sort of, like, algorithm that's documented elsewhere? Please link to that algorithm. Is this method integrating with some, like, third-party API? You know, they have some documentation that we could link to to go deeper into, like, what these search options do. Link to that. External links are great. I could probably find it by Googling myself, but you are going to make me very happy as a developer if you already give me the link.

+ +

You'd mentioned capturing inputs and outputs. That's a great thing to scan for. Inputs and outputs, though, are more sometimes than just the arguments and return values. Although if we're talking about arguments, any sort of options hash, please document the keys that go in that because that's often not obvious from the code. And I've spent a lot of time source diving and jumping between methods trying to figure out like, what are the options I can pass to this hash?

+ +

Beyond the explicit inputs and outputs, though, anything that is global state that you rely on. So, do you need to read something from an environment variable or even a global variable or something like that that might make this method behave differently in different situations? Please document that. Any situations where you might raise an error that I might not expect or that I might want to rescue from, let me know what are the potential errors that might get raised.

+ +

And then, finally, any sorts of side effects. Does this method make a network call? Are you writing to the file system? I'd like to know that, and I'd have to, like, figure it out by trial and error. And sometimes, it will be obvious in just the description of the method, right? Oh, this method pulls data from a third-party API. That's pretty clear. But maybe it does some sort of, like, caching in the background or something to a file that's not really important. But maybe I'm trying to do a unit test that involves this, and now, all of a sudden, I have to do some weird stubbing. I'd like to know that upfront.

+ +

So, those are kind of all the things I would love to have in my sort of ideal documentation comment that would make my life easier as a developer when trying to use some code.

+ +

STEPHANIE: Wow. What a passionate plea [laughs]. I was very into listening to you list all of that. You got very animated. And it makes a lot of sense because I feel like these are kind of just the day-to-day developer issues we run into in our work and would be so awesome if, especially as the, you know, author where you have figured all of this stuff out, the author of a, you know, a method or a class, to just kind of tell us these things so we don't have to figure it out ourselves.

+ +

I guess I also have to respond to that by saying, on one hand, I totally get, like, you want to be saved [chuckles] from those common pitfalls. But I think that part of our work is just going through that and playing around and exploring with the code in front of us, and we learn all of that along the way. And, ultimately, even if that is all provided to you, there is something about, like, going through it yourself that gives you a different perspective on it.

+ +

And, I don't know, maybe it's just my bias against [laughs] all the inline text, but I've also seen a lot of that type of information captured at different levels of documentation. So, maybe it is a Confluence doc or in a wiki talking about, you know, common gotchas for this particular problem that they were trying to solve. And I think what's really cool is that, you know, everyone can kind of be served and that people have different needs that different styles of documentation can meet.

+ +

So, for anyone diving deep in the source code, they can see all of those examples inline. But, for me, as a big Googler [laughs], I want to see just a nice, little web app to get me the information that I need to find. I'm happy having that a little bit more, like, extracted from my source code.

+ +

JOËL: Right. You don't want to have to read the source code with all the comments in it. I think that's a fair criticism and, yeah, probably a downside of this. And I'm wondering, there might be some editor tooling that allows you to just collapse all comments and hide them if you wanted to focus on just the code.

+ +

STEPHANIE: Yeah, someone, please build that for me. That's my passionate plea [laughs]. And on that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Bye.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie shares about her vacation at Disney World, particularly emphasizing the technological advancements in the park's mobile app that made her visit remarkably frictionless. Joël had a conversation about a topic he loves: units of measure, and he got to go deep into the idea of dimensional analysis with someone this week.

+ +

Together, Joël and Stephanie talk about module documentation within software development. Joël shares his recent experience writing module docs for a Ruby project using the YARD documentation system. He highlights the time-consuming nature of crafting good documentation for each public method in a class, emphasizing that while it's a demanding task, it significantly benefits those who will use the code in the future. They explore the attributes of good documentation, including providing code examples, explaining expected usage, suggesting alternatives, discussing edge cases, linking to external resources, and detailing inputs, outputs, and potential side effects.

+ +
+ + + +

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, I recently was on vacation, and I'm excited [chuckles] to tell our listeners all about it. I went to Disney World [laughs]. And honestly, I was especially struck by the tech that they used there. As a person who works in tech, I always kind of have a little bit of a different experience knowing a bit more about software, I suppose, than just your regular person [laughs], citizen. And so, at Disney World, I was really impressed by how seamlessly the like, quote, unquote, "real life experience" integrated with their use of their branded app to pair with, like, your time at the theme park.

+ +

JOËL: This is, like, an app that runs on your mobile device?

+ +

STEPHANIE: Yeah, it's a mobile app. I haven't been to Disney in a really long time. I think the last time I went was just as a kid, like, this was, you know, pre-mobile phones. So, I recall when you get into the line at a ride, you can skip the line by getting what's called a fast pass. And so, you kind of take a ticket, and it tells you a designated time to come back so that you could get into the fast line, and you don't have to wait as long.

+ +

And now all this stuff is on your mobile app, and I basically did not wait in [laughs] a single line for more than, like, five minutes to go on any of the rides I wanted. It just made a lot of sense that all these things that previously had more, like, physical touchstones, were made a bit more convenient. And I hesitate to use the word frictionless, but I would say that accurately describes the experience.

+ +

JOËL: That's kind of amazing; the idea that you can use tech to make a place that's incredibly busy also feel seamless and where you don't have to wait in line.

+ +

STEPHANIE: Yeah and, actually, I think the coolest part was it blended both your, like, physical experience really well with your digital one. I think that's kind of a gripe I have as a technologist [laughs] when I'm just kind of too immersed in my screen as opposed to the world around me. But I was really impressed by the way that they managed to make it, like, a really good supplement to your experience being there.

+ +

JOËL: So, you're not hyped for a future world where you can visit Disney in VR?

+ +

STEPHANIE: I mean, I just don't think it's the same. I rode a ride [laughs] where it was kind of like a mini roller coaster. It was called Expedition Everest. And there's a moment, this is, like, mostly indoors, but there's a moment where the roller coaster is going down outside, and you're getting that freefall, like, drop feeling in your stomach. And it also happened to be, like, drizzling that day that we were out there, and I could feel it, you know, like, pelting my head [laughs]. And until VR can replicate that experience [chuckles], I still think that going to Disney is pretty fun.

+ +

JOËL: Amazing.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I'm really excited because I had a conversation about a topic that I like to talk about: units of measure. And I got to go deep into the idea of dimensional analysis with someone this week. This is a technique where you can look at a calculation or a function and sort of spot-check whether it's correct by looking at whether the unit for the measure that would come out match what you would expect. So, you do math on the units and ignore the numbers coming into your formula. And, you know, let's say you're calculating the speed of something, and you get a distance and the amount of time it took you to take to go that distance.

+ +

And let's say your method implements this as distance times time. Forget about doing the actual math with the numbers here; just look at the units and say, okay, we've got our meters, and we've got our seconds, and we're multiplying them together. The unit that comes out of this method is meters times seconds. You happen to know that speeds are not measured in meters times seconds. They're measured in meters divided by seconds or meters per second. So, immediately, you get a sense of, like, wait a minute, something's wrong here. I must have a bug in my function.

+ +

STEPHANIE: Interesting. I'm curious how you're representing that data to, like, know if there's a bug or not. In my head, when you were talking about that, I'm like, oh yeah, I definitely recall doing, like, math problems for homework [laughs] where I had, you know, my meters per second. You have your little fractions written out, and then when you multiply or divide, you know how to, like, deal with the units on your piece of paper where you're showing your work. But I'm having a hard time imagining what that looks like as a programmer dealing with that problem.

+ +

JOËL: You could do it just all in your head based off of maybe some comments that you might have or the name of the variable or something. So, you're like, okay, well, I have a distance in meters and a time in seconds, and I'm multiplying the two. Therefore, what should be coming out is a value that is in meters times seconds. If you want to get fancier, you can do things with value objects of different types. So, you say, okay, I have a distance, and I have a time. And so, now I have sort of a multiplication of a distance and a time, and sort of what is that coming out as?

+ +

That can sometimes help you prevent from having some of these mistakes because you might have some kind of error that gets raised at runtime where it's like, hey, you're trying to multiply two units that shouldn't be multiplied, or whatever it is. You can also, in some languages, do this sort of thing automatically at the type level. So, instead of looking at it yourself and sort of inferring it all on your own based off of the written code, languages like F# have built-in unit-of-measure systems where once you sort of tag numbers as just being of a particular unit of measure, any time you do math with those numbers, it will then tag the result with whatever compound unit comes from that operation.

+ +

So, you have meters, and you have seconds. You divide one by the other, and now the result gets tagged as meters per second. And then, if you have another calculation that takes the output of the first one and it comes in, you can tell the compiler via type signature, hey, the input for this method needs to be in meters per second. And if the other calculation sort of automatically builds something that's of a different unit, you'll get a compilation error. So, it's really cool what it can do.

+ +

STEPHANIE: Yeah, that is really neat. I like all of those built-in guardrails, I suppose, to help you, you know, make sure that your answer is correct. Definitely could have used that [chuckles]. Turns out I just needed a calculator to take my math test with [laughs].

+ +

JOËL: I think what I find valuable more than sort of the very rigorous approach is the mindset. So, anytime you're dealing with numbers, thinking in your mind, what is the unit of this number? When I do math with it with a different number, is it the same unit? Is it a different unit? What is the unit of the thing that's coming out? Does this operation make sense in the domain of my application? Because it's easy to sometimes think you're doing a math operation that makes sense, and then when you look at the unit, you're like, wait a minute, this does not make sense.

+ +

And I would go so far as to say that, you know, you might think, oh, I'm not doing a physics app. I don't care about units of measure. Most numbers in your app that are actually numbers are going to have some kind of unit of measure associated to them. Occasionally, you might have something where it's just, like, a straight-up, like, quantity or something like that. It's a dimensionless number. But most things will have some sort of unit. Maybe it's a number of dollars. Maybe it is an amount of time, a duration. It could be a distance. It could be all sorts of things. Typically, there is some sort of unit that should attach to it.

+ +

STEPHANIE: Yeah. That makes sense that you would want to be careful about making sure that your mathematical operations that you're doing when you're doing objects make sense. And we did talk about this in the last episode about multidimensional numbers a little bit. And I suppose I appreciate you saying that because I think I have mostly benefited from other people having thought in that mindset before and encoding, like I mentioned, those guardrails.

+ +

So, I can recall an app where I was working with, you know, some kind of currency or money object, and that error was raised when I would try to divide by zero because rather than kind of having to find out later with some, not a number or infinite [laughs] amount of money bug, it just didn't let me do that. And that wasn't something that I had really thought about, you know, I just hadn't considered that zero value edge case when I was working on whatever feature I was building.

+ +

JOËL: Yeah, or even just generally the idea of dividing money. What does that even mean? Are you taking an amount of money and splitting it into two equivalent piles to split among multiple people? That kind of makes sense. Are you dividing money by another money value? That's now asking a very different kind of question.

+ +

You're asking, like, what is the ratio between these two, I guess, piles of money if we want to make it, you know, in the physical world? Is that a thing that makes sense in your application? But also, realize that that ratio that you get back is not itself an amount of money. And so, there are some subtle bugs that can happen around that when you don't keep track of what your quantities are.

+ +

So, this past week, I've been working on a project where I ended up having to write module docs for the code in question. This is a Ruby project, so I'm writing docs using the YARD documentation system, where you effectively just write code comments at the sort of high level covering the entire class and then, also, individual documentation comments on each of the methods. And that's been really interesting because I have done this in other languages, but I'd never done it in Ruby before. And this is a piece of code that was kind of gnarly and had been tricky for me to figure out. And I figured that a couple of these classes could really benefit from some more in-depth documentation.

+ +

And I'm curious, in your experience, Stephanie, as someone who's writing code, using code from other people, and who I assume occasionally reads documentation, what are the things that you like to see in good sort of method-level docs?

+ +

STEPHANIE: Personally, I'm really only reading method-level docs when, you know, at this point, I'm, like, reaching for a method. I want to figure out how to use it in my use case right now [laughs]. So, I'm going to search API documentation for it. And I really am just scanning for inputs, especially, I think, and maybe looking at, you know, some potential various, like, options or, like, variations of how to use the method. But I'm kind of just searching for that at a glance and then moving on [laughs] with my day. That is kind of my main interaction with module docs like that, and especially ones for Ruby and Rails methods.

+ +

JOËL: And for clarity's sake, I think when we're talking about module docs here, I'm generally thinking of, like, any sort of documentation that sort of comments in code meant to document. It could be the whole modular class. It could be on a per-method level, things like RDoc or YARD docs on Ruby classes. You used the word API docs here. I think that's a pretty similar idea.

+ +

STEPHANIE: I really haven't given the idea of writing this kind of documentation a lot of thought because I've never had to do too much of it before, but I know, recently, you have been diving deep into it because, you know, like you said, you found these classes that you were working with a bit ambiguous, I suppose, or just confusing. And I'm wondering what kind of came out of that journey. What are some of the most interesting aspects of doing this exercise?

+ +

JOËL: And one of the big ones, and it's not a fun one, but it is time-consuming. Writing good docs per method for a couple of classes takes a lot of time, and I understand why people don't do it all the time.

+ +

STEPHANIE: What kinds of things were you finding warranted that time? Like, you know, you had to, at some point, decide, like, whether or not you're going to document any particular method. And what were some of the things you were looking out for as good reasons to do it?

+ +

JOËL: I was making the decisions to document or not document on a class level, and then every public method gets documentation. If there's a big public API, that means every single one of those methods is getting some documentation comments, explaining what they do, how they're meant to be used, things like that. I think my kind of conclusion, having worked with this, is that the sort of sweet spot for this sort of documentation is for anything that is library-like, so a lot of things that maybe would go into a Rails lib directory might make sense. Anything you're turning into a gem that probably makes sense.

+ +

And sometimes you have things in your Rails codebase that are effectively kind of library-like, and that was the case for the code that I was dealing with. It was almost like a mini ORM style kind of ActiveRecord-inspired series of base classes that had a bunch of metaprogramming to allow you to write models that were backed by not a database but a headless CMS, a content management system. And so, these classes are not extracted to the lib directory or, like, made into a gem, but they feel very library-esque in that way.

+ +

STEPHANIE: Library-like; I like that descriptor a lot because it immediately made me think of another example of a time when I've used or at least, like, consumed this type of documentation in a, like, SaaS repo. Rather, you know, I'm not really seeing that level of documentation around domain objects, but I noticed that they really did a lot of extending of the application record class because they just had some performance needs that they needed to write some, like, custom code to handle.

+ +

And so, they ended up kind of writing a lot of their own ORM-like methods for just some, like, custom callbacks on persisting and some just, like, bulk insertion functionality. And those came with a lot of different ways to use them. And I really appreciated that they were heavily documented, kind of like you would expect those ActiveRecord methods to be as well.

+ +

JOËL: So, I've been having some conversations with other members at thoughtbot about when they like to use the style of module doc. What are some of the alternatives? And one that kept coming up for different people that they would contrast with this is what they would call the big README approach, and this could be for a whole gem, or it could be maybe some directory with a few classes in your application that's got a README in the root of the directory.

+ +

And instead of documenting each method, you just write a giant README trying to answer sort of all of the questions that you anticipate people will ask. Is that something that you've seen, and how do you feel about that as a tool when you're looking for help?

+ +

STEPHANIE: Yes. I actually really like that style of documentation. I find that I just want examples to get me started, especially; I guess this is especially true for libraries that I'm not super familiar with but need to just get a working knowledge about kind of immediately. So, I like to see examples, the getting started, the just, like, here's what you need to know. And as I start to use them, that will get me rolling. But then, if I find I need more details, then I will try to seek out more specific information that might come in the form of class method documentation.

+ +

But I'm actually thinking about how FactoryBot has one of the best big README-esque [laughs] style of documentation, and I think they did a really big refresh of the docs not too long ago. It has all that high-level stuff, and then it has more specific information on how to use, you know, the most common methods to construct your factories. But those are very detailed, and yet they do sit, like, separately from inline, like, code documentation in the style of module docs that we're talking about.

+ +

So, it is kind of an interesting mix of both that I think is helpful for me personally when I want both the “what do I need to know now?” And the, “like, okay, I know where to look for if I need something a little more detailed.”

+ +

JOËL: Yeah. The two don't need to be mutually exclusive. I thought it was interesting that you mentioned how much examples are valuable to you because...I don't know if this is controversial, but an opinion that I have about sort of per-method documentation is that you should always default to having a code example for every method. I don't care how simple it is or how obvious it is what it does. Show me a code example because, as a developer, examples are really, really helpful. And so, seeing that makes documentation a lot more valuable than just a couple of lines that explain something that was maybe already obvious from the title of the method. I want to see it in action.

+ +

STEPHANIE: Interesting. Do you want to see it where the method definition is?

+ +

JOËL: Yes. Because sometimes the method definition, like, the implementation, might be sort of complex. And so, just seeing a couple of examples, like, oh, you call with this input, you get that. Call with this other input; you get this other thing. And we see this in, you know, some of the core docs for things like the enumerable methods where having an example there to be like, oh, so that's how map works. It returns this thing under these circumstances. That sort of thing is really helpful.

+ +

And then, I'll try to do it at a sort of a bigger level for that class itself. You have a whole paragraph about here's the purpose of the class. Here's how you should use it. And then, here's an example of how you might use it. Particularly, if this is some sort of, like, base class you're meant to inherit from, here's the circumstances you would want to subclass this, and then here's the methods you would likely want to override.

+ +

And maybe here are the DSLs you might want to have and to kind of package that in, like, a little example of, in this case, if you wanted a model that read from the headless CMS, here's what an example of such a little model might look like. So, it's kind of that putting it all together, which I think is nice in the module docs. It could probably also live in the big README at some level.

+ +

STEPHANIE: Yeah. As you are saying that, I also thought about how I usually go search for tests to find examples of usage, but I tend to get really overwhelmed when I see inline, like, that much inline documentation. I have to, like, either actively ignore it, choose to ignore it, or be like, okay, I'm reading this now [laughs]. Because it just takes up so much visual space, honestly.

+ +

And I know you put a lot of work into it, a lot of time, but maybe it's because of the color of my editor theme where comments are just that, like, light gray [laughs]. I find them quite easy to just ignore. But I'm sure there will be some time where I'm like, okay, like, if I need them, I know they're there.

+ +

JOËL: Yeah, that is, I think, a downside, right? It makes it harder to browse the code sometimes because maybe your entire screen is almost taken up by documentation, and then, you know, you have one method up, and you've got to, like, scroll through another page of documentation before you hit the next method, and that makes it harder to browse. And maybe that's something that plays into the idea of that separation between library-esque code versus application code.

+ +

When you browse library-esque code, when you're actually browsing the source, you're probably doing it for different reasons than you would for code in your application because, at that point, you're effectively source diving, sometimes being like, oh, I know this class probably has a method that will do the thing I want. Where is it? Or you're like, there's an edge case I don't understand on this method. I wonder what it does. Let me look at the implementation. Or even some existing code in the app is using this library method. I don't know what it does, but they call this method, and I can't figure out why they're using it. Let me look at the source of the library and see what it does under the hood.

+ +

STEPHANIE: Yeah. I like the distinction of it is kind of a different mindset that you're reading the code at, where, like, sometimes my brain is already ready to just read code and try to figure out inputs and outputs that way. And other times, I'm like, oh, like, I actually can't parse this right now [chuckles]. Like, I want to read just English, like, telling me what to expect or, like, what to look out for, especially when, like you said, I'm not really, like, trying to figure out some strange bug that would lead me to diving deep in the source code. It's I'm at the level where I'm just reaching for a method and wanting to use it.

+ +

We're writing these YARD docs. I think I also heard you mention that you gave some, like, tips or maybe some gotchas about how to use certain methods. I'm curious why that couldn't have been captured in a more, like, self-documenting way. Or was there a way that you could have written the code for that not to have been needed as a comment or documented as that? And was there a way that method names could have been clear to signal, like, the intention that you were trying to convey through your documentation?

+ +

JOËL: I'm a big fan of using method names as a form of documentation, but they're frequently not good enough. And I think comments, whether they're just regular inline comments or more official documentation, can be really good to help avoid sort of common pitfalls. And one that I was working with was, there were two methods, and one would find by a UID, so it would search up a document by UID. And another one would search by ID.

+ +

And when I was attempting to use these before I even started documenting, I used the wrong one, and it took me a while to realize, oh wait, these things have both UIDs and IDs, and they're slightly different, and sometimes you want to use one or the other. The method names, you know, said like, "Find by ID" or "Find by UID." I didn't realize there were both at the time because I wasn't browsing the source. I was just seeing a place where someone had used it. And then, when I did find it in the source, I'm like, well, what is the difference?

+ +

And so, something that I did when I wrote the docs was sort of call out on both of those methods; by the way, there is also find by UID. If you're searching by UID, consider using the other one. If you don't know what the difference is, here's a sentence summarizing the difference. And then, here's a link to external documentation if you want to dive into the nitty gritty of why there are two and what the differences are. And I think that's something you can't capture in just a method name.

+ +

STEPHANIE: Yeah, that's true. I like that a lot. Another use case you can think of is when method names are aliased, and it's like, I don't know how I would have possibly known that until I, you know, go through the journey of realizing [laughs] that these two methods do the same thing or, like, stumbling upon where the aliasing happens.

+ +

But if that were captured in, like, a little note when I'm in, like, a documentation viewer or something, it's just kind of, like, a little tidbit of knowledge [laughs] that I get to gain along the way that ends up, you know, being useful later because I will have just kind of...I will likely remember having seen something like that. And I can at least start my search with a little bit more context than when you don't know what you don't know.

+ +

JOËL: I put a lot of those sorts of notes on different methods. A lot of them are probably based on a personal story where I made a mistaken assumption about this method, and then it burned me. But I'm like, okay, nobody else is going to make that mistake. By the way, if you think this is what the method does, it does something slightly different and, you know, here's why you need to know that.

+ +

STEPHANIE: Yeah, you're just looking out for other devs.

+ +

JOËL: And, you know, trying to, like, take my maybe negative experience and saying like, "How can I get value out of that?" Maybe it doesn't feel great that I lost an hour to something weird about a method. But now that I have spent that hour, can I get value out of it? Is the sort of perspective I try to have on that.

+ +

So, you mentioned kind of offhand earlier the idea of a documentation viewer, which would be separate than just reading these, I guess, code comments directly in your code editor. What sort of documentation viewers do you like to use?

+ +

STEPHANIE: I mostly search in my browser, you know, just the official documentation websites for Rails, at least. And then I know that there are also various options for Ruby as well. And I think I had mentioned it before but using DuckDuckGo as my search engine. I have nice bang commands that will just take me straight to the search for those websites, which is really nice. Though, I have paired with people before who used various, like, macOS applications to do something similar. I think Alfred might have some built-in workflows for that. And then, a former co-worker used to use one called Dash, that I have seen before, too. So, it's another one of those just handy just, like, search productivity extensions.

+ +

JOËL: You mentioned the Rails documentation, and this is separate from the guides. But the actual Rails docs are generated from comments like this inline in code. So, all the different ActiveRecord methods, when you search on the Rails documentation you're like, oh yeah, how does find_by work? And they've got a whole, like, paragraph explaining how it works with a couple of examples. That's this kind of documentation. If you open up that particular file in the source code, you'll find the comments.

+ +

And it makes sense for Rails because Rails is more of, you know, library-esque code. And you and I search these docs pretty frequently, although we don't tend to do it, like, by opening the Rails gem and, like, grepping through the source to find the code comment. We do it through either a documentation site that's been compiled from that source or that documentation that's been extracted into an offline tool, like you'd mentioned, Dash.

+ +

STEPHANIE: Yeah, I realized how conflicting, I suppose, it is for me to say that I find inline documentation really overwhelming or visually distracting, whereas I recognize that the only reason I can have that nice, you know, viewing experience is because documentation viewers use the code comments in that format to be generated.

+ +

JOËL: I wonder if there's like a sort of...I don't know what this pattern is called, but a bit of a, like, middle-quality trap where if you're going to source dive, like, you'd rather just look at the code and not have too much clutter from sort of mediocre comments. But if the documentation is really good and you have the tooling to read it, then you don't even need to source dive at all. You can just read the documentation, and that's sufficient.

+ +

So, both extremes are good, but that sort of middle kind of one foot in each camp is sort of the worst of both worlds experience. Because I assume when you look for Rails documentation, you never open up the actual codebase to search. The documentation is good enough that you don't even need to look at the files with the comments and the code.

+ +

STEPHANIE: Yeah, and I'm just recalling now there's, like, a UI feature to view the source from the documentation viewer page.

+ +

JOËL: Yes.

+ +

STEPHANIE: I use that actually quite a bit if the comments are a little bit sparse and I need just the code to supplement my understanding, and that is really nice. But you're right, like, I very rarely would be source diving, unless it's a last resort [laughs], let's be honest.

+ +

JOËL: So, we've talked about documentation viewers and how that can make things nice, and you're able to read documentation for things. But a lot of other tooling can benefit from this sort of model documentation as well, and I'm thinking, in particular, Solargraph, which is Ruby's language server protocol. And it has plugins for VS Code, for Vim, for a few different editors, takes advantage of that to provide all sorts of things.

+ +

So, you can get smart expansion of code and good suggestions. You can get documentation for what's under your cursor. Maybe you're reading somebody else's code that they've written, and you're like, why are they calling this parameterized method here? What does that even do? Like, in VS Code, you could just hover over it, and it will pop up and show you documentation, including the, like, inputs and return types, and things like that. That's pretty nifty.

+ +

STEPHANIE: Yeah, that is cool. I use VS Code, but I've not seen that too much yet because I don't think I've worked in enough codebases with really comprehensive [laughs] YARD docs. I'm actually wondering, tooling-wise, did you use any helpful tools when you were writing them or were you hand-documenting each?

+ +

JOËL: I was hand-documenting everything.

+ +

STEPHANIE: Class. Okay.

+ +

JOËL: The thing that I did use is the YARD gem, which you don't need to have the gem to write YARD-style documentation. But if you have the gem, you can run a local server and then preview a documentation site that is generated from your comments that has everything in there. And that was incredibly helpful for me as I was trying to sort of see an overview of, okay, what would someone who's looking at the docs generated from this see when they're trying to look for what the documentation of a particular method does?

+ +

STEPHANIE: Yeah, and that's really nice.

+ +

JOËL: Something that I am curious about that I've not really had a lot of experience with is whether or not having extra documentation like that can help AI tools give us better suggestions.

+ +

STEPHANIE: Yeah, I don't know the answer to that either, but I would be really curious to know if that is already something that happens with something like Copilot.

+ +

JOËL: Do better docs help machines, or are they for humans only?

+ +

STEPHANIE: Whoa, that's a very [laughs] philosophical question, I think. It would make sense, though, that if we already have ways to parse and compile this kind of documentation, then I can see that incorporating them into the types of, like, generative problems that AI quote, unquote "solves" [chuckles] would be really interesting to find out. But anyone listening who kind of knows the answer to that or has experience working with AI tools and various types of code comment documentation would be really curious to know what your experience is like and if it improves your development workflow.

+ +

So, for people who might be interested in getting better at documenting their code in the style of module docs, what would you say are some really great attributes of good documentation in this form?

+ +

JOËL: I think, first of all, you have to write from the motivation of, like, if you were confused and wanting to better understand what a method does, what would you like to see? And I think coming from that perspective, and that was, in my case, I had been that person, and then I was like, okay, now that I've figured it out, I'm going to write it so that the next person is not confused.

+ +

I have five or six things that I think were really valuable to add to the docs, a few of which we've already mentioned. But rapid fire, first of all, code example. I love code examples. I want a code example on every method. An explanation of expected usage. Here's what the method does. Here's how we expect you to use this method in any extra context about sort of intended use.

+ +

Callouts for suggested alternatives. If there are methods that are similar, or there's maybe a sort of common mistake that you would reach for this method, put some sort of call out to say, "Hey, you probably came here trying to do X. If that's what you were actually trying to do, you should use method Y." Beyond that, a discussion of edge cases, so any sort of weird ways the method behaves. You know, when you pass nil to it, does it behave differently? If you call it in a different context, does it behave differently? I want to know that so that I'm not totally surprised.

+ +

Links to external resources–really great if I want to, like, dig deeper. Is this method built on some sort of, like, algorithm that's documented elsewhere? Please link to that algorithm. Is this method integrating with some, like, third-party API? You know, they have some documentation that we could link to to go deeper into, like, what these search options do. Link to that. External links are great. I could probably find it by Googling myself, but you are going to make me very happy as a developer if you already give me the link.

+ +

You'd mentioned capturing inputs and outputs. That's a great thing to scan for. Inputs and outputs, though, are more sometimes than just the arguments and return values. Although if we're talking about arguments, any sort of options hash, please document the keys that go in that because that's often not obvious from the code. And I've spent a lot of time source diving and jumping between methods trying to figure out like, what are the options I can pass to this hash?

+ +

Beyond the explicit inputs and outputs, though, anything that is global state that you rely on. So, do you need to read something from an environment variable or even a global variable or something like that that might make this method behave differently in different situations? Please document that. Any situations where you might raise an error that I might not expect or that I might want to rescue from, let me know what are the potential errors that might get raised.

+ +

And then, finally, any sorts of side effects. Does this method make a network call? Are you writing to the file system? I'd like to know that, and I'd have to, like, figure it out by trial and error. And sometimes, it will be obvious in just the description of the method, right? Oh, this method pulls data from a third-party API. That's pretty clear. But maybe it does some sort of, like, caching in the background or something to a file that's not really important. But maybe I'm trying to do a unit test that involves this, and now, all of a sudden, I have to do some weird stubbing. I'd like to know that upfront.

+ +

So, those are kind of all the things I would love to have in my sort of ideal documentation comment that would make my life easier as a developer when trying to use some code.

+ +

STEPHANIE: Wow. What a passionate plea [laughs]. I was very into listening to you list all of that. You got very animated. And it makes a lot of sense because I feel like these are kind of just the day-to-day developer issues we run into in our work and would be so awesome if, especially as the, you know, author where you have figured all of this stuff out, the author of a, you know, a method or a class, to just kind of tell us these things so we don't have to figure it out ourselves.

+ +

I guess I also have to respond to that by saying, on one hand, I totally get, like, you want to be saved [chuckles] from those common pitfalls. But I think that part of our work is just going through that and playing around and exploring with the code in front of us, and we learn all of that along the way. And, ultimately, even if that is all provided to you, there is something about, like, going through it yourself that gives you a different perspective on it.

+ +

And, I don't know, maybe it's just my bias against [laughs] all the inline text, but I've also seen a lot of that type of information captured at different levels of documentation. So, maybe it is a Confluence doc or in a wiki talking about, you know, common gotchas for this particular problem that they were trying to solve. And I think what's really cool is that, you know, everyone can kind of be served and that people have different needs that different styles of documentation can meet.

+ +

So, for anyone diving deep in the source code, they can see all of those examples inline. But, for me, as a big Googler [laughs], I want to see just a nice, little web app to get me the information that I need to find. I'm happy having that a little bit more, like, extracted from my source code.

+ +

JOËL: Right. You don't want to have to read the source code with all the comments in it. I think that's a fair criticism and, yeah, probably a downside of this. And I'm wondering, there might be some editor tooling that allows you to just collapse all comments and hide them if you wanted to focus on just the code.

+ +

STEPHANIE: Yeah, someone, please build that for me. That's my passionate plea [laughs]. And on that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Bye.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+aig-WOdQ + + ]]> + + Joël Quenneville + Stephanie Minn + + + 416: Multi-Dimensional Numbers + https://bikeshed.thoughtbot.com/416 + daec6c2e-48af-451c-a6fb-b55e3ed1fd6d + Tue, 27 Feb 2024 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël discusses the challenges he encountered while optimizing slow SQL queries in a non-Rails application. Stephanie shares her experience with canary deploys in a Rails upgrade. Together, Stephanie and Joël address a listener's question about replacing the wkhtml2pdf tool, which is no longer maintained. + +The episode's main topic revolves around the concept of multidimensional numbers and their applications in software development. Joël introduces the idea of treating objects containing multiple numbers as single entities, using the example of 2D points in space to illustrate how custom classes can define mathematical operations like addition and subtraction for complex data types. They explore how this approach can simplify operations on data structures, such as inventories of T-shirt sizes, by treating them as mathematical objects. + 39:31 + no + + + Joël discusses the challenges he encountered while optimizing slow SQL queries in a non-Rails application. Stephanie shares her experience with canary deploys in a Rails upgrade. Together, Stephanie and Joël address a listener's question about replacing the wkhtml2pdf tool, which is no longer maintained. +The episode's main topic revolves around the concept of multidimensional numbers and their applications in software development. Joël introduces the idea of treating objects containing multiple numbers as single entities, using the example of 2D points in space to illustrate how custom classes can define mathematical operations like addition and subtraction for complex data types. They explore how this approach can simplify operations on data structures, such as inventories of T-shirt sizes, by treating them as mathematical objects. +EXPLAIN ANALYZE visualizer (https://explain.dalibo.com/) +Canary in a coal mine (https://en.wikipedia.org/wiki/Sentinel_species#Canaries) +Episode 413: Developer Tales of Package Management (https://bikeshed.thoughtbot.com/413) +Docs for media-specific CSS (https://developer.mozilla.org/en-US/docs/Web/CSS/@media) +Episode 386: Value Objects Revisited: The Tally Edition (https://bikeshed.thoughtbot.com/386) +Money gem (https://github.com/RubyMoney/money) +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: I've recently been trying to do some performance enhancements to some very slow queries. This isn't a Rails app, so we're sort of combining together a bunch of different scopes. And the way they're composing together is turning out to be really slow. And I've reached for a tool that is just really fun. It's a visualizer for SQL query plans. +You can put the SQL keywords in front of a query: 'EXPLAIN ANALYZE,' and it will then output a query plan, sort of how it's going to attempt to do the work. And that might be like, oh, we're going to use this index on this table to join on this other thing, and then we're going to...maybe this is a table that we think we're going to do a sequential scan through and, you know, it builds out a whole thing. +It's a big block of text, and it's kind of intimidating to look at. So, there are a few websites out there that will do this. You just paste a query plan in, and they will build you a nice, little visualization, almost like a tree of, like, tasks to be done. Oftentimes, they'll also annotate it with metadata that they pulled from the query plan. So, oh, this particular node is the really expensive one because we're doing a sequential scan of this table that has 15 million rows in it. And so, it's really useful to then sort of pinpoint what are the areas that you could optimize. +STEPHANIE: Nice. I have known that you could do that EXPLAIN ANALYZE on a SQL query, but I've never had to do it before. Is this your first time, or is it just your first time using the visualizer? +JOËL: I've played around with EXPLAIN ANALYZE a little bit before. Pro tip: In Rails, if you've got a scope, you can just chain dot explain on the end, and instead of running the query, it will run the EXPLAIN version of it and return the query plan. So, you don't need to, like, turn into SQL then manually run it in your database system to get the EXPLAIN. You can just tack a dot explain on there to get the query plan. +It's still kind of intimidating, especially if you've got a really complex query that's...this thing might be 50 lines long of EXPLAIN with all this indentation and other stuff. So, putting it into a sort of online visualizer was really helpful for the work that I was doing. So, it was my first time using an online visualizer. There are a few out there. I'll link to the one that I used in the show notes. But I would do that again, would recommend. +STEPHANIE: Nice. +JOËL: So, Stephanie, what's new in your world? +STEPHANIE: So, I actually just stepped away from being in the middle of doing a Rails upgrade [chuckles] and releasing it to production just a few minutes before getting on to record with you on this podcast. And the reason I was able to do that, you know, without feeling like I had to just monitor to see how it was going is because I'm on a project where the client is using canary deploys. And I was so pleasantly surprised by how easy it made this experience where we had decided to send the canary release earlier this morning. +And the way that they have it set up is that the canary goes to 10% of traffic. 10% of the users were on Rails 7 for their sessions. And we saw a couple of errors in our error monitoring service. And we are like, "Okay, like, let's take a look at this, see what's going on." And it turns out it was not too big of a deal because it had to do with, like, a specific page. And, for the most part, if a user did encounter this error, they probably wouldn't again after refreshing because they had, like, a 90% chance [chuckles] of being directed to the previous version where everything is working. +And we were kind of making that trade-off of like, oh, we could hotfix this right now on the canary release. But then, as we were starting to debug a little bit, it was a bit hairier than we expected originally. And so, you know, I said, "I have to hop on to go record The Bike Shed. So, why don't we just take this canary down just for the time being to take that time pressure off? And it's Friday, so we're heading into the weekend. And maybe we can revisit the issue with some fresh eyes." So, I'm feeling really good, actually. And I'm glad that we were able to do something that seems scary, but there were guardrails in place to make it a lot more chill. +JOËL: Yay for the ability to roll back. You used the term canary release. That's not one that I'm familiar with. Can you explain what a canary release is? +STEPHANIE: Oh yeah. Have you heard of the phrase 'Canary in the coal mine'? +JOËL: I have. +STEPHANIE: Okay. So, I believe it's the same idea where you are, in this case, releasing a potentially risky change, but you don't want to immediately make it available to, like, all of your users. And so, you send this change to, like, a small reach, I suppose, and give it a little bit of a test and see [chuckles] what comes back. And that can help inform you of any issues or risks that might happen before kind of committing to deploying a potentially risky change with a bigger impact. +JOËL: Is this handled with something like a feature flag framework? Or is this, like, at an infrastructure level where you're just like, "Hey, we've got the canary image in, like, one container on one server, and then we'll redirect 10% of traffic to that to be served by that one and the other 90% to be served by the old container or something like that"? +STEPHANIE: Yeah, in this case, it was at the infrastructure level. And I have also seen something similar at a feature flag level, too, where you're able to have some more granularity around what percent of users are seeing a feature. But I think with something like a Rails upgrade, it was nice to be able to have that at that infrastructure level. It's not necessarily, like, a particular page or feature to show or not show. +JOËL: Yeah, I think you would probably want that at a higher level when you're changing over the entire app. Is this something that you had to custom-build yourself or something that just sort of came out of the box with some of the infrastructure tools you're using? +STEPHANIE: It came out of the box, actually. I just joined this client project this week and was very delighted to see just some really great deployment infrastructure and getting to meet the DevOps engineers, too, who built it. And they're really proud of it. They kind of walked us through our first release earlier this week. And he was telling me, the DevOps engineer, that this was actually his favorite part of the job, is walking people through their first release and being their buddy while they do it. Because I think he gets to also see users interact with the tool that he built, and he had a lot of pride in that, so it was a very delightful experience. +JOËL: That's so wonderful. I've been on so many projects where the sort of infrastructure side of things is not the team's strong point, and releasing can be really scary. And it's great to hear the opposite of that. +We recently received a question for Stephanie based on an earlier episode. So, the question asks, "In episode 413, Stephanie discussed a recent issue she encountered with wkhtml2pdf. The episode turned into a deeper discussion about package management, but I don't think it ever cycled back to the conclusion. I'm curious: how did Stephanie solve this dilemma? We're facing the same issue on a project that my team maintains. It's an old codebase, and there are bits of old code that use wkhtml2pdf to generate print views of our data in our application. +The situation is fairly dire. wkhtml2pdf is no longer maintained. In fact, it won't even be available to install from our operating system's package repositories in June. We're on FreeBSD, but I assume the same will be eventually true for other operating systems. And so, unless you want to maintain some build step to check out and compile the source code for an application that will no longer receive security updates, just living with it isn't really an option. +There are three options we're considering. One, eliminate the dependency entirely. Based on user feedback, it sounds like our old developers were using this library to generate PDFs when what users really wanted was an easy way to print. So, instead of downloading a PDF, just ensure the screen has a good print style sheet and register an onload handler to call window dot print. We're thinking we could implement this as an A/B test to the feature to test this theory. Or two, replace wkhtml2pdf with a call to Headless Chrome and use that to generate the PDF. Or, three, replace wkhtml2pdf with a language-level package. For us, that might be the dompdf library available via Composer because we're a PHP shop." +Yeah, a lot to unpack here. Any high-level thoughts, Stephanie? +STEPHANIE: My first thought while I was listening to you read that question is that wkhtml2pdf is such a mouthful [laughs]. And I was impressed how you managed to say it at least, like, five times. +JOËL: So, I try to say that five times fast. +STEPHANIE: And then, my second high-level thought was, I'm so sorry to Brian, our listener who wrote in, because I did not really solve this dilemma [chuckles] for my project and team. I kind of kicked the can down the road, and that's because this was during a support and maintenance rotation that I've talked a little bit about before on the show. I was only working on this project for about a week. +And what we thought was a small bug to figure out why PDFs were a little bit broken turned out, as you mentioned, to be this kind of big, dire dilemma where I did not feel like I had enough information to make a good call about what to do. So, I kind of just shared my findings that, like, hey, there is kind of a risk and hoping that someone else [laughs] would be able to make a better determination. +But I really was struck by the options that you were considering because it was actually a bit of a similar situation to the bug I was sharing where the PDF that was being generated that was slightly broken. I don't think it was, like, super valuable to our users that it be in the form of a PDF. It really was just a way for them to print something to have on handy as a reference from, you know, some data that was generated from the app. So, yeah, based on what you're sharing, I feel really excited about the first one. Joël, I'm sure you have some opinions about this as well. +JOËL: I love sort of the bigger picture thinking that Brian is doing here, sort of stepping back and being like, wait, why do we even need PDF here, and how are our customers using it? I think those are the really good questions to ask before sinking a ton of time into coming up with something that might be, like, a bit of a technical wonder. Like, hey, we managed to, like, do this PDF generation thing that we had to, like, cobble together so many other things. And it's so cool technically, but does it actually solve the underlying problem? So, shout out to Brian for thinking about it in those terms. I love that. +Second cool thing that I wanted to shout out, because I think this is a feature of browsers that not many people are aware of; you can have multiple style sheets for your page, and you can tag them to be for different media. So, you can have a style sheet that only gets applied when you print versus when you display on screen. And there are a couple of others. I don't remember exactly what they are. I'll link to the docs in the show notes. +But taking advantage of this, like, this is old technology but making that available and saying, "Yeah, we'll make it so that it's nice when you print, and we'll maybe even, you know, a link or a button with JavaScript so that you could just Command-P or Control-P to print. But we'll have a button in there as well that will allow you to print to PDF," and that solves your problem right there. +STEPHANIE: Yeah, that's really cool. I didn't know that about being able to tag style sheets for different media types. That's really fascinating. And I like that, yeah, we're just eliminating this dependency on something, like, potentially really complex with a, hopefully, kind of elegant and modern solution, maybe. +JOËL: And your browser is already able to do so many of these things. Why do we sort of try to recreate it? Printing is a thing browsers have been able to do for a long time. Printing to PDF is a thing that you can do for a long time. I will sometimes use that on sites where I need to, let's say I'm purchasing something, and I need some sort of receipt to expense, but they won't give me a download, a PDF download that I can send to the accounting team, so I will print to PDF the, like, HTML view. And that works just fine. It's kind of a workaround hack. +Sometimes, it doesn't work well because the HTML page is just not well set up to, like, show up on a PDF page. You get some, like, weird, like, pagination issues or things like that. But, you know, just a little bit of thought for a print style sheet, especially for something you know that people are likely going to want to print or to save to PDF, that's a nice touch. +STEPHANIE: Yeah. So, good luck, Brian, and let us know how this goes and any outcomes you find successful. So, for today's longer topic, I was excited because I saw, Joël, you dropped something in our topic backlog: Multidimensional Numbers. I'm curious what prompted this idea and what you wanted to say about it. +JOËL: We did an episode a while back where we talked about value objects, wrapping numbers, wrapping collections. This is Episode 386, and we were talking about tallying, specifically working with collections of T-shirt sizes and doing math on these sort of objects that might contain multiple numbers. And a sort of sidebar from that that we didn't really get into is the idea that objects that contain sort of multiple numbers can be treated as a number themselves. +And I think a great example of this is something like a point in two-dimensional space. It's got an x coordinate, a y coordinate. It's two numbers, but you can treat sort of the combination of the two of them together as a single number. There's a whole set of coordinate math that you can do to do things like add coordinates together, subtract them, find the distance between them. There's a whole field of vector math that we can do on those. +And I think learning to recognize that numbers are not just instances of the integer or the float class but that there could be these more complex things that are also numbers is maybe an important realization and something that, as developers, if we think of these sort of more complex values as numbers, or at least mathematical objects, then that will help us write better code. +STEPHANIE: Cool. Yeah. When you were first talking about 2D points, I was thinking about if I have experience working with that before or, like, having to build something really heavily based off of, like, a canvas or, you know, a coordinate system. And I couldn't think of any really good examples until I thought about, like, geographic locations. +JOËL: Oh yeah, like a latitude, longitude. +STEPHANIE: Yeah, exactly. Like, that is a lot more common, I think, for various types of just, like, production applications than 2D points if you're not working on, like, a video game or something like that, I think. +JOËL: Right, right. I think you're much more likely to be working with 2D points on some more sort of front-end-heavy application. I was talking with someone this week about managing a seat map for concerts and events like that and sort of creating a seat map and have it be really interactive, and you can, like, click on seats and things like that. And depending on the level of libraries you're using to build that, you may have to do a lot of 2D math to make it all come together. +STEPHANIE: Yeah. So, I would love to get into, you know, maybe we've realized, okay, we have some kind of compound number. What are some good reasons for using them differently than you would a primitive? +JOËL: So, you mentioned primitives, and I think this is where maybe I'm developing a reputation about, like, always wanting value objects for everything. But it would be really easy, let's say, for an xy point to be just an array of two numbers or maybe even a hash with an x key and a y key. +What's tricky about that is that then you don't have the ability to do math on them. Arrays do define the plus operator, but they don't do what you want them to do with points. It's the set union. So, adding two points would not at all do what you want, or subtracting two points. So, instead, if you have a custom 2D point class and you can define plus and minus on there to do the right thing, now they're not pairs of numbers, two values; they're a single value, and you can treat them as if they are just a single number. +STEPHANIE: You mentioned that arrays don't do the right thing when you try to add them up. What is the right thing that you're thinking of then? +JOËL: It probably depends a little bit on the type of object you're working with. So, with 2D points, you're probably trying to do vector addition where you're effectively saying almost, like, "Shift this point in 2D space by the amount of this other point." Or if you're doing a subtraction, you might even be asking, like, "What is the distance between these two points?" Euclidean distance, I think, is the technical term for this. +There's also a couple of different ways you can multiply values. You can multiply a 2D point by just a sort of, not by another point, but by just an integer. That's called scaling. So, you're just like, oh, take this point in 2D space, but make it bigger, make it five times bigger or five times further from the origin. Or you can do some stuff with other points. But what you don't want to do is turn this into, if you're starting with arrays, you don't want to turn this into an array of four points. When you add two points in 2D space, you're not trying to create a point in 4D space. +STEPHANIE: Whoa, I mean [laughs], maybe you're not. +JOËL: You could but -- [laughter] +STEPHANIE: Yeah. While you were saying that, I guess that is what is really cool about wrapping, encapsulating them in objects is that you get to decide what that means for you and your application, and -- +JOËL: Yeah. Well, plus can mean different things, right? +STEPHANIE: Yeah. +JOËL: On arrays, plus means combining two arrays together. On integers, it means you do integer math. And on points, it might be vector addition. +STEPHANIE: Are there any other arithmetic operators you can think of that would be useful to implement if you were trying to create some functionality on a point? +JOËL: That's a good question because I think realizing the inverse of that is also a really powerful thing. Just because you create a sort of new mathematical object, a point in 2D space, doesn't mean that necessarily every arithmetic operator makes sense on it. Does it make sense to divide a point by another point? Maybe not. And so, instead of going with the mindset of, oh, a point is a mathematical object, I now need to implement all of arithmetic on this, instead, think in terms of your domain. What are the operations that make sense? What are the operations you need for this point? +And, you know, maybe the answer is look up what are the common sort of vector math operations and implement those on your 2D point. Some of them will map to arithmetic operators like plus and minus, and then some of them might just be some sort of custom method where maybe you say, "Oh, I want the Euclidean distance between these two points." That's just a thing. Maybe it's just a named instance method on there. But yeah, don't feel like you need to implement all of the math operators because that's a mistake that I have made and then have ended up, like, implementing nonsensical things. +STEPHANIE: [laughs] Creating your own math. +JOËL: Yes, creating my own math. I've done this even on where I've done value objects to wrap single values. I was doing a class to represent currency, and I was like, well, clearly, you need, like, methods to, like, add or subtract your currency, and that's another thing. If you have, let's say, a plus method, now you can plug it into, let's say, reduce plus. And you can just sum a list of these currency objects and get back a new currency. It's not even going to give you back an integer. You just get a sort of new currency object that is the sum of all the other ones, and that's really nice. +STEPHANIE: Yeah, that's really cool. It reminds me of all the magic of enumerable that you had talked about in a previous conference talk, where, you know, you just get so much out of implementing those basic operators that, like, kind of scales in handiness. +JOËL: Yes. Turns out Ruby is actually a pretty nice system. If you have objects that respond to some common methods and you plug them into enumerable, and it just all kind of works. +STEPHANIE: So, one thing you had said earlier that I've felt kind of excited about and wanted to highlight was you mentioned all the different ways that you could represent a 2D point with more primitive data stores, so, you know, an array of two integers, a hash with xy keys. It got me thinking about how, yeah, like, maybe if your system has to talk to another system and you're importing data or exporting data, it might eventually need to take those forms. +But what is cool about having an encapsulated object in your application is you can kind of control those boundaries a little bit and have more confidence in terms of the data types that you're using within your system by having various ways to construct that, like, domain object, even if the data coming in is in a different shape. +JOËL: And I think that you're hitting on one of the real beauties of object-oriented programming, where the sort of users of your object don't need to know about the internal representation. Maybe you store an array internally. Maybe it's two separate instance variables. Maybe it's something else entirely. But all that the users of your, let's say, 2D point object really need to care about is, hey, the constructor wants values in this shape, and then I can call these domain methods on it, and then the rest just sort of happens. It's an implementation detail. It doesn't matter. +And you alluded, I think, to the idea that you can sort of create multiple constructors. You called them constructors. I tend to call them that as well. But they're really just class methods that will kind of, like, add some sugar on top of the constructor. So, you might have, like, a from array pair or from hash or something like that that allows you to maybe do a little bit of massaging of the data before you pass it into your constructor that might want some underlying form. And I think that's a pattern that's really nice. +STEPHANIE: Yeah, I agree. +JOËL: Something that can be interesting there, too, is that mathematically, there are multiple ways you can think of a 2D point. An xy coordinate pair is a common one, but another sort of system for representing a point in 2D space is called the polar coordinate system. So, you have some sort of, like, origin point. You're 0,0. And then, instead of saying so many to the left and so many up from that origin point, you give an angle and a distance, and that's where your point is. So, an angle and distance point, I think, you know, theta and magnitude are the fancy terms for this. +You could, instead of creating a separate, like, oh, I have a polar coordinate point and a Cartesian coordinate point, and those are separate things, you can say, no, I just have a point in 2D space. They can be constructed from either an xy coordinate pair or a magnitude angle pair. +Internally, maybe you convert one to the other for internal representation because it makes the math easier or whatever. Your users never need to know that. They just pass in the values that they want, use the constructor that is most convenient for them, and it might be both. Maybe some parts of the app require polar coordinates; some require Cartesian coordinates. You could even construct one of each, and now you can do math with each other because they're just instances of the same class. +STEPHANIE: Whoa. Yeah, I was trying to think about transforming between the two types as well. It's all possible [laughs]. +JOËL: Yes. Because you could have reader-type methods on your object that say, oh, for this point, give me its x coordinate; give me its y coordinate. Give me its distance from the origin. Give me its angle from the origin. And those are all questions you can ask that object, and it can calculate them. And you don't need to care what its internal representation is to be able to get all four of those. +So, we've been talking about a lot of these sort of composite numbers, not composite numbers, that's a separate mathematical thing, but numbers that are composed of sort of multiple sub-numbers. And what about situations where you have two things, and one of them is not a number? I'm thinking of all sorts of units of measure. So, I don't just have three. I have three, maybe...and we were talking about currency earlier, so maybe three U.S. dollars. Or I don't just have five; I have five, you know, let's say, meters of distance. Would you consider something like that to be one of these compound number things? +STEPHANIE: Right. I think I was–when we were originally talking about this, conflating the two. But I realized that, you know, just because we're adding context to a number and potentially packaging it as a value object, it's still different from what we're talking about today where, you know, there's multiple components to the number that are integral or required for it to mean what we intended to mean, if that makes sense. +JOËL: Yeah. +STEPHANIE: So yeah, I guess we did want to kind of make a distinction between value objects that while the additional context is important and you can implement a lot of different functionality based on what it represents, at the end of the day, it only kind of has one magnitude or, like, one integer to kind of encapsulate it represented as a number. Does that sound right? +JOËL: Yeah. You did throw out the words encapsulation and value object. So, in a situation maybe where I have three US dollars, would you create some kind of custom object to wrap that? Or is that a situation where you'd be more comfortable using some kind of primitive? Like, I don't know, maybe an array pair of three and the symbol USD or something like that. +STEPHANIE: Oh, I would definitely not do that [laughter]. Yeah. Like I, you know, for the most part, I think I've seen that as a currency object, and that expands the world of what we can do with it, converting into a lot of different other currencies. And yeah, just making sure those things don't get divorced from each other because that context is what gives it meaning. But when it comes to our compound numbers, it's like, without all of the components, it doesn't make sense, or it doesn't even represent the same, like, numerical value that we were trying to convey. +JOËL: Right. You need both, or, you know, it could be more than two. It could be three, four, or five numbers together to mean something. You mentioned conversions, which I think is something that's also interesting because a lot of units of measure have sort of multiple ways of measuring, and you often want to convert between them. And maybe that's another case where encapsulation is really nice where, you know, maybe you have a distance object. And you have five meters, and you put that into your distance object, but then somebody wants it in feet somewhere else or in centimeters, or something like that. And it can just do all the conversion math safely inside that object, and the user doesn't have to worry about it. +STEPHANIE: Right. This is maybe a bit of a tangent, but as a Canadian living in the U.S., I don't know [laughs] if you have any opinions about converting meters and feet. +JOËL: The one I actually do the most often is converting Celsius to Fahrenheit and vice versa. You know, I've been here, what, 11 years now? I don't have a great intuition for Fahrenheit temperatures. So, I'm converting in my head just [laughs] on a daily basis. +STEPHANIE: Yeah, that makes sense. Conversions: they're important. They help out our friends who [laughs] are on different systems of measurement. +JOËL: There's a classic story that I love about unit conversions. I think it's one of the NASA Mars missions. +STEPHANIE: Oh yeah. +JOËL: You've heard of this one. It was trying to land on Mars, and it burned up in the atmosphere because two different teams had been building different components and used different unit systems, both according to spec for their own module. But then, when the modules try to talk to each other, they're sending over numbers in meters instead of feet or something like that. And it just caused [laughs] this, like, multi-year, multi-billion dollar project to just burn up. +STEPHANIE: That's right. So, lesson of the day is don't do that. I can think of another example where there might be a little bit of misconceptions in terms of how to represent it. And I'm thinking about time and when that has been represented in multiple parts, such as in hours and, minutes and seconds. Do you have any initial impressions about a piece of data like that? +JOËL: So, that's really interesting, right? Because, at first glance, it looks like, oh, it's, like, a triplet of hour, minute, seconds. It's sort of another one of these sort of compound numbers, and I guess you could implement it that way. But in reality, you're tracking a single quantity, the amount of time elapsed, and that can be represented with a single number. +So, if you're representing, let's say, time of day, what would show up on your clock? That could be, depending on the resolution, number of, let's say, seconds since midnight, and that's a single counter. And then, you can do some math on it to get hours, minutes, seconds for a particular moment. But really, it's a single quantity, and we can do that with time. We can't do that with a 2D point. Like, it has to have two components. +STEPHANIE: So, do you have a recommendation for what unit of time time would best be stored? I'm just thinking of all the times that I've had to do that millisecond, you know, that conversion of, you know, however many thousands of milliseconds in my head into something that actually means [laughs] something to me as a human being who measures time in hours and minutes. +JOËL: My recommendation is absolutely go for a single number that you store in your, let's say, time of day object. It makes the math so much easier. You don't have to worry about, like, overflowing from one number into another when you're doing math or anything like that. And then the number that you count should be at the whatever the smallest resolution you care at. +So, is there ever any time where you want to distinguish between two different milliseconds in time? Or maybe you're like, you know what? These are, like, we're tracking time of day for appointments. We don't care about the difference between two milliseconds. We don't need to track them independently. We don't even care about seconds. The most granular we ever care about things is by the minute. And so, maybe then your internal number that you track is a counter of minutes since midnight. But if you need more precision, you can go down to seconds or milliseconds or nanoseconds. +But yeah, find what is the sort of the least resolution you want to get away with and then make that the unit of measure for a single counter in your object. And then encapsulate that so that nobody else needs to care that, internally, your time of day object is doing milliseconds because nobody wants to do that math. Just give me a nice, like, hours and minutes method on your object, and I will use that. I don't need to know internally what it's using. +Please don't just pass around integers; wrap it in an object, especially because integers, there's enough times where you're doing seconds versus milliseconds. And when I just have an integer, I never know if the person storing this integer means seconds or milliseconds. So, I'm just like, oh, I'm going to pass to this, like, user object, a, like, time integer. And unless there's a comment or a constant, you know, that's named something duration in milliseconds or something like that, you know, or sometimes even, like, one year in milliseconds, or there's no way of knowing. +STEPHANIE: Yeah. That makes a lot of sense. When you kind of choose a standard of a standard unit, it's, like, possible to make it easier [laughs]. +JOËL: So, circling back to sort of the initial thing that sparked this conversation, the previous episode about T-shirt inventories, there we were dealing with what started off as, like, a hash of different T-shirt sizes and quantities of T-shirts that we had in that size, so small (five), medium (three), large (four). And then, we eventually turned that into a value object that represented...I think we called it a tally, but maybe we called it inventory. +And this may be wrong, so tell me if I'm wrong here, I think we can kind of treat that as a number, as, like, one of these compound numbers. It's a sort of multidimensional number where you say, well, we have sort of three dimensions where we can have numbers that sort of increase and decrease independently. We can do math on these because we can take inventories or tallies and add and subtract them. And that's what we ended up having to do. We created a value object. We implemented plus and minus on it. There are rules for how the math works. I think this is a multidimensional number with the definition we're working on this show. Am I wrong here? +STEPHANIE: I wouldn't say that you're wrong. I think I would have to think a little [laughs] more to say definitively that you're right. But I know that this example came from, you know, an application I was actually working on. And one of the main things that we had to do with these representations [laughs], I'm hesitant to call them a number, especially, but we had to compare these representations frequently because an inventory, for example, in a warehouse, wanting to make sure that it is equal to or there's enough of the inventory if someone was placing an order, which would also contain, like, a representation of T-shirt size inventory. +And that was kind of where some of that math happened because, you know, maybe we don't want to let someone place an order if the inventory at the warehouse is smaller than their order, right? So, there is something really compelling about the comparison operations that we were doing that kind of is leaning me in the direction of, like, yeah, like, it makes sense to me to use this in a way that I would compare, like, quantities or numbers of something. +JOËL: I think one thing that was really compelling to me, and that kind of blew my mind, was that we were trying to, like, figure out some things like, oh, we've got so many people with these size preferences, and we've got so many T-shirts across different warehouses. And we're summing them up and we're trying to say like, "How many do we need to purchase if there is a deficit?" +And we can come up with effectively a formula for this. We're like, sum these numbers, when we're talking about just before we introduce sizes when it's just like, oh, people have T-shirts. They all get the count of people and a count of T-shirts in our warehouse, and we find, you know, the difference between that. And there's a few extra math operations we do. +Then you introduce size, and you break it down by, oh, we've got so many of each. And now the whole thing gets really kind of messy and complicated. And you're doing these reduces and everything. When we start treating the tally of T-shirts as an object, and now it's a number that responds to plus and minus, all of a sudden, you can just plug those back into the original formula, and it all just works. The original formula doesn't care whether the numbers you're doing this formula on are simple integers or these sort of multidimensional numbers. And that blew my mind, and it was so cool. +STEPHANIE: Yeah, that is really neat. And you get a lot of added benefits, too. +I think the other important piece in the T-shirt size example was kind of tracking the state change, and that's so much easier when you have an object. There's just a lot more you can do with it. And even if, you know, you're not persisting every single version of the representation, you know, because sometimes you don't want to, sometimes you're really just kind of only holding it in memory to figure out if you need to, you know, do something else. But other times, you do want to persist it. And it just plugs in really well with, like, the rest of object-oriented programming [laughs] in terms of interacting with the rest of your business needs, I think, in your app. +JOËL: Yeah, turns out objects, they're kind of nice. And you can do math with them. Who knew? Math is not just about integers. +STEPHANIE: And on that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Joël discusses the challenges he encountered while optimizing slow SQL queries in a non-Rails application. Stephanie shares her experience with canary deploys in a Rails upgrade. Together, Stephanie and Joël address a listener's question about replacing the wkhtml2pdf tool, which is no longer maintained.

+ +

The episode's main topic revolves around the concept of multidimensional numbers and their applications in software development. Joël introduces the idea of treating objects containing multiple numbers as single entities, using the example of 2D points in space to illustrate how custom classes can define mathematical operations like addition and subtraction for complex data types. They explore how this approach can simplify operations on data structures, such as inventories of T-shirt sizes, by treating them as mathematical objects.

+ + + +

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: I've recently been trying to do some performance enhancements to some very slow queries. This isn't a Rails app, so we're sort of combining together a bunch of different scopes. And the way they're composing together is turning out to be really slow. And I've reached for a tool that is just really fun. It's a visualizer for SQL query plans.

+ +

You can put the SQL keywords in front of a query: 'EXPLAIN ANALYZE,' and it will then output a query plan, sort of how it's going to attempt to do the work. And that might be like, oh, we're going to use this index on this table to join on this other thing, and then we're going to...maybe this is a table that we think we're going to do a sequential scan through and, you know, it builds out a whole thing.

+ +

It's a big block of text, and it's kind of intimidating to look at. So, there are a few websites out there that will do this. You just paste a query plan in, and they will build you a nice, little visualization, almost like a tree of, like, tasks to be done. Oftentimes, they'll also annotate it with metadata that they pulled from the query plan. So, oh, this particular node is the really expensive one because we're doing a sequential scan of this table that has 15 million rows in it. And so, it's really useful to then sort of pinpoint what are the areas that you could optimize.

+ +

STEPHANIE: Nice. I have known that you could do that EXPLAIN ANALYZE on a SQL query, but I've never had to do it before. Is this your first time, or is it just your first time using the visualizer?

+ +

JOËL: I've played around with EXPLAIN ANALYZE a little bit before. Pro tip: In Rails, if you've got a scope, you can just chain dot explain on the end, and instead of running the query, it will run the EXPLAIN version of it and return the query plan. So, you don't need to, like, turn into SQL then manually run it in your database system to get the EXPLAIN. You can just tack a dot explain on there to get the query plan.

+ +

It's still kind of intimidating, especially if you've got a really complex query that's...this thing might be 50 lines long of EXPLAIN with all this indentation and other stuff. So, putting it into a sort of online visualizer was really helpful for the work that I was doing. So, it was my first time using an online visualizer. There are a few out there. I'll link to the one that I used in the show notes. But I would do that again, would recommend.

+ +

STEPHANIE: Nice.

+ +

JOËL: So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I actually just stepped away from being in the middle of doing a Rails upgrade [chuckles] and releasing it to production just a few minutes before getting on to record with you on this podcast. And the reason I was able to do that, you know, without feeling like I had to just monitor to see how it was going is because I'm on a project where the client is using canary deploys. And I was so pleasantly surprised by how easy it made this experience where we had decided to send the canary release earlier this morning.

+ +

And the way that they have it set up is that the canary goes to 10% of traffic. 10% of the users were on Rails 7 for their sessions. And we saw a couple of errors in our error monitoring service. And we are like, "Okay, like, let's take a look at this, see what's going on." And it turns out it was not too big of a deal because it had to do with, like, a specific page. And, for the most part, if a user did encounter this error, they probably wouldn't again after refreshing because they had, like, a 90% chance [chuckles] of being directed to the previous version where everything is working.

+ +

And we were kind of making that trade-off of like, oh, we could hotfix this right now on the canary release. But then, as we were starting to debug a little bit, it was a bit hairier than we expected originally. And so, you know, I said, "I have to hop on to go record The Bike Shed. So, why don't we just take this canary down just for the time being to take that time pressure off? And it's Friday, so we're heading into the weekend. And maybe we can revisit the issue with some fresh eyes." So, I'm feeling really good, actually. And I'm glad that we were able to do something that seems scary, but there were guardrails in place to make it a lot more chill.

+ +

JOËL: Yay for the ability to roll back. You used the term canary release. That's not one that I'm familiar with. Can you explain what a canary release is?

+ +

STEPHANIE: Oh yeah. Have you heard of the phrase 'Canary in the coal mine'?

+ +

JOËL: I have.

+ +

STEPHANIE: Okay. So, I believe it's the same idea where you are, in this case, releasing a potentially risky change, but you don't want to immediately make it available to, like, all of your users. And so, you send this change to, like, a small reach, I suppose, and give it a little bit of a test and see [chuckles] what comes back. And that can help inform you of any issues or risks that might happen before kind of committing to deploying a potentially risky change with a bigger impact.

+ +

JOËL: Is this handled with something like a feature flag framework? Or is this, like, at an infrastructure level where you're just like, "Hey, we've got the canary image in, like, one container on one server, and then we'll redirect 10% of traffic to that to be served by that one and the other 90% to be served by the old container or something like that"?

+ +

STEPHANIE: Yeah, in this case, it was at the infrastructure level. And I have also seen something similar at a feature flag level, too, where you're able to have some more granularity around what percent of users are seeing a feature. But I think with something like a Rails upgrade, it was nice to be able to have that at that infrastructure level. It's not necessarily, like, a particular page or feature to show or not show.

+ +

JOËL: Yeah, I think you would probably want that at a higher level when you're changing over the entire app. Is this something that you had to custom-build yourself or something that just sort of came out of the box with some of the infrastructure tools you're using?

+ +

STEPHANIE: It came out of the box, actually. I just joined this client project this week and was very delighted to see just some really great deployment infrastructure and getting to meet the DevOps engineers, too, who built it. And they're really proud of it. They kind of walked us through our first release earlier this week. And he was telling me, the DevOps engineer, that this was actually his favorite part of the job, is walking people through their first release and being their buddy while they do it. Because I think he gets to also see users interact with the tool that he built, and he had a lot of pride in that, so it was a very delightful experience.

+ +

JOËL: That's so wonderful. I've been on so many projects where the sort of infrastructure side of things is not the team's strong point, and releasing can be really scary. And it's great to hear the opposite of that.

+ +

We recently received a question for Stephanie based on an earlier episode. So, the question asks, "In episode 413, Stephanie discussed a recent issue she encountered with wkhtml2pdf. The episode turned into a deeper discussion about package management, but I don't think it ever cycled back to the conclusion. I'm curious: how did Stephanie solve this dilemma? We're facing the same issue on a project that my team maintains. It's an old codebase, and there are bits of old code that use wkhtml2pdf to generate print views of our data in our application.

+ +

The situation is fairly dire. wkhtml2pdf is no longer maintained. In fact, it won't even be available to install from our operating system's package repositories in June. We're on FreeBSD, but I assume the same will be eventually true for other operating systems. And so, unless you want to maintain some build step to check out and compile the source code for an application that will no longer receive security updates, just living with it isn't really an option.

+ +

There are three options we're considering. One, eliminate the dependency entirely. Based on user feedback, it sounds like our old developers were using this library to generate PDFs when what users really wanted was an easy way to print. So, instead of downloading a PDF, just ensure the screen has a good print style sheet and register an onload handler to call window dot print. We're thinking we could implement this as an A/B test to the feature to test this theory. Or two, replace wkhtml2pdf with a call to Headless Chrome and use that to generate the PDF. Or, three, replace wkhtml2pdf with a language-level package. For us, that might be the dompdf library available via Composer because we're a PHP shop."

+ +

Yeah, a lot to unpack here. Any high-level thoughts, Stephanie?

+ +

STEPHANIE: My first thought while I was listening to you read that question is that wkhtml2pdf is such a mouthful [laughs]. And I was impressed how you managed to say it at least, like, five times.

+ +

JOËL: So, I try to say that five times fast.

+ +

STEPHANIE: And then, my second high-level thought was, I'm so sorry to Brian, our listener who wrote in, because I did not really solve this dilemma [chuckles] for my project and team. I kind of kicked the can down the road, and that's because this was during a support and maintenance rotation that I've talked a little bit about before on the show. I was only working on this project for about a week.

+ +

And what we thought was a small bug to figure out why PDFs were a little bit broken turned out, as you mentioned, to be this kind of big, dire dilemma where I did not feel like I had enough information to make a good call about what to do. So, I kind of just shared my findings that, like, hey, there is kind of a risk and hoping that someone else [laughs] would be able to make a better determination.

+ +

But I really was struck by the options that you were considering because it was actually a bit of a similar situation to the bug I was sharing where the PDF that was being generated that was slightly broken. I don't think it was, like, super valuable to our users that it be in the form of a PDF. It really was just a way for them to print something to have on handy as a reference from, you know, some data that was generated from the app. So, yeah, based on what you're sharing, I feel really excited about the first one. Joël, I'm sure you have some opinions about this as well.

+ +

JOËL: I love sort of the bigger picture thinking that Brian is doing here, sort of stepping back and being like, wait, why do we even need PDF here, and how are our customers using it? I think those are the really good questions to ask before sinking a ton of time into coming up with something that might be, like, a bit of a technical wonder. Like, hey, we managed to, like, do this PDF generation thing that we had to, like, cobble together so many other things. And it's so cool technically, but does it actually solve the underlying problem? So, shout out to Brian for thinking about it in those terms. I love that.

+ +

Second cool thing that I wanted to shout out, because I think this is a feature of browsers that not many people are aware of; you can have multiple style sheets for your page, and you can tag them to be for different media. So, you can have a style sheet that only gets applied when you print versus when you display on screen. And there are a couple of others. I don't remember exactly what they are. I'll link to the docs in the show notes.

+ +

But taking advantage of this, like, this is old technology but making that available and saying, "Yeah, we'll make it so that it's nice when you print, and we'll maybe even, you know, a link or a button with JavaScript so that you could just Command-P or Control-P to print. But we'll have a button in there as well that will allow you to print to PDF," and that solves your problem right there.

+ +

STEPHANIE: Yeah, that's really cool. I didn't know that about being able to tag style sheets for different media types. That's really fascinating. And I like that, yeah, we're just eliminating this dependency on something, like, potentially really complex with a, hopefully, kind of elegant and modern solution, maybe.

+ +

JOËL: And your browser is already able to do so many of these things. Why do we sort of try to recreate it? Printing is a thing browsers have been able to do for a long time. Printing to PDF is a thing that you can do for a long time. I will sometimes use that on sites where I need to, let's say I'm purchasing something, and I need some sort of receipt to expense, but they won't give me a download, a PDF download that I can send to the accounting team, so I will print to PDF the, like, HTML view. And that works just fine. It's kind of a workaround hack.

+ +

Sometimes, it doesn't work well because the HTML page is just not well set up to, like, show up on a PDF page. You get some, like, weird, like, pagination issues or things like that. But, you know, just a little bit of thought for a print style sheet, especially for something you know that people are likely going to want to print or to save to PDF, that's a nice touch.

+ +

STEPHANIE: Yeah. So, good luck, Brian, and let us know how this goes and any outcomes you find successful. So, for today's longer topic, I was excited because I saw, Joël, you dropped something in our topic backlog: Multidimensional Numbers. I'm curious what prompted this idea and what you wanted to say about it.

+ +

JOËL: We did an episode a while back where we talked about value objects, wrapping numbers, wrapping collections. This is Episode 386, and we were talking about tallying, specifically working with collections of T-shirt sizes and doing math on these sort of objects that might contain multiple numbers. And a sort of sidebar from that that we didn't really get into is the idea that objects that contain sort of multiple numbers can be treated as a number themselves.

+ +

And I think a great example of this is something like a point in two-dimensional space. It's got an x coordinate, a y coordinate. It's two numbers, but you can treat sort of the combination of the two of them together as a single number. There's a whole set of coordinate math that you can do to do things like add coordinates together, subtract them, find the distance between them. There's a whole field of vector math that we can do on those.

+ +

And I think learning to recognize that numbers are not just instances of the integer or the float class but that there could be these more complex things that are also numbers is maybe an important realization and something that, as developers, if we think of these sort of more complex values as numbers, or at least mathematical objects, then that will help us write better code.

+ +

STEPHANIE: Cool. Yeah. When you were first talking about 2D points, I was thinking about if I have experience working with that before or, like, having to build something really heavily based off of, like, a canvas or, you know, a coordinate system. And I couldn't think of any really good examples until I thought about, like, geographic locations.

+ +

JOËL: Oh yeah, like a latitude, longitude.

+ +

STEPHANIE: Yeah, exactly. Like, that is a lot more common, I think, for various types of just, like, production applications than 2D points if you're not working on, like, a video game or something like that, I think.

+ +

JOËL: Right, right. I think you're much more likely to be working with 2D points on some more sort of front-end-heavy application. I was talking with someone this week about managing a seat map for concerts and events like that and sort of creating a seat map and have it be really interactive, and you can, like, click on seats and things like that. And depending on the level of libraries you're using to build that, you may have to do a lot of 2D math to make it all come together.

+ +

STEPHANIE: Yeah. So, I would love to get into, you know, maybe we've realized, okay, we have some kind of compound number. What are some good reasons for using them differently than you would a primitive?

+ +

JOËL: So, you mentioned primitives, and I think this is where maybe I'm developing a reputation about, like, always wanting value objects for everything. But it would be really easy, let's say, for an xy point to be just an array of two numbers or maybe even a hash with an x key and a y key.

+ +

What's tricky about that is that then you don't have the ability to do math on them. Arrays do define the plus operator, but they don't do what you want them to do with points. It's the set union. So, adding two points would not at all do what you want, or subtracting two points. So, instead, if you have a custom 2D point class and you can define plus and minus on there to do the right thing, now they're not pairs of numbers, two values; they're a single value, and you can treat them as if they are just a single number.

+ +

STEPHANIE: You mentioned that arrays don't do the right thing when you try to add them up. What is the right thing that you're thinking of then?

+ +

JOËL: It probably depends a little bit on the type of object you're working with. So, with 2D points, you're probably trying to do vector addition where you're effectively saying almost, like, "Shift this point in 2D space by the amount of this other point." Or if you're doing a subtraction, you might even be asking, like, "What is the distance between these two points?" Euclidean distance, I think, is the technical term for this.

+ +

There's also a couple of different ways you can multiply values. You can multiply a 2D point by just a sort of, not by another point, but by just an integer. That's called scaling. So, you're just like, oh, take this point in 2D space, but make it bigger, make it five times bigger or five times further from the origin. Or you can do some stuff with other points. But what you don't want to do is turn this into, if you're starting with arrays, you don't want to turn this into an array of four points. When you add two points in 2D space, you're not trying to create a point in 4D space.

+ +

STEPHANIE: Whoa, I mean [laughs], maybe you're not.

+ +

JOËL: You could but -- [laughter]

+ +

STEPHANIE: Yeah. While you were saying that, I guess that is what is really cool about wrapping, encapsulating them in objects is that you get to decide what that means for you and your application, and --

+ +

JOËL: Yeah. Well, plus can mean different things, right?

+ +

STEPHANIE: Yeah.

+ +

JOËL: On arrays, plus means combining two arrays together. On integers, it means you do integer math. And on points, it might be vector addition.

+ +

STEPHANIE: Are there any other arithmetic operators you can think of that would be useful to implement if you were trying to create some functionality on a point?

+ +

JOËL: That's a good question because I think realizing the inverse of that is also a really powerful thing. Just because you create a sort of new mathematical object, a point in 2D space, doesn't mean that necessarily every arithmetic operator makes sense on it. Does it make sense to divide a point by another point? Maybe not. And so, instead of going with the mindset of, oh, a point is a mathematical object, I now need to implement all of arithmetic on this, instead, think in terms of your domain. What are the operations that make sense? What are the operations you need for this point?

+ +

And, you know, maybe the answer is look up what are the common sort of vector math operations and implement those on your 2D point. Some of them will map to arithmetic operators like plus and minus, and then some of them might just be some sort of custom method where maybe you say, "Oh, I want the Euclidean distance between these two points." That's just a thing. Maybe it's just a named instance method on there. But yeah, don't feel like you need to implement all of the math operators because that's a mistake that I have made and then have ended up, like, implementing nonsensical things.

+ +

STEPHANIE: [laughs] Creating your own math.

+ +

JOËL: Yes, creating my own math. I've done this even on where I've done value objects to wrap single values. I was doing a class to represent currency, and I was like, well, clearly, you need, like, methods to, like, add or subtract your currency, and that's another thing. If you have, let's say, a plus method, now you can plug it into, let's say, reduce plus. And you can just sum a list of these currency objects and get back a new currency. It's not even going to give you back an integer. You just get a sort of new currency object that is the sum of all the other ones, and that's really nice.

+ +

STEPHANIE: Yeah, that's really cool. It reminds me of all the magic of enumerable that you had talked about in a previous conference talk, where, you know, you just get so much out of implementing those basic operators that, like, kind of scales in handiness.

+ +

JOËL: Yes. Turns out Ruby is actually a pretty nice system. If you have objects that respond to some common methods and you plug them into enumerable, and it just all kind of works.

+ +

STEPHANIE: So, one thing you had said earlier that I've felt kind of excited about and wanted to highlight was you mentioned all the different ways that you could represent a 2D point with more primitive data stores, so, you know, an array of two integers, a hash with xy keys. It got me thinking about how, yeah, like, maybe if your system has to talk to another system and you're importing data or exporting data, it might eventually need to take those forms.

+ +

But what is cool about having an encapsulated object in your application is you can kind of control those boundaries a little bit and have more confidence in terms of the data types that you're using within your system by having various ways to construct that, like, domain object, even if the data coming in is in a different shape.

+ +

JOËL: And I think that you're hitting on one of the real beauties of object-oriented programming, where the sort of users of your object don't need to know about the internal representation. Maybe you store an array internally. Maybe it's two separate instance variables. Maybe it's something else entirely. But all that the users of your, let's say, 2D point object really need to care about is, hey, the constructor wants values in this shape, and then I can call these domain methods on it, and then the rest just sort of happens. It's an implementation detail. It doesn't matter.

+ +

And you alluded, I think, to the idea that you can sort of create multiple constructors. You called them constructors. I tend to call them that as well. But they're really just class methods that will kind of, like, add some sugar on top of the constructor. So, you might have, like, a from array pair or from hash or something like that that allows you to maybe do a little bit of massaging of the data before you pass it into your constructor that might want some underlying form. And I think that's a pattern that's really nice.

+ +

STEPHANIE: Yeah, I agree.

+ +

JOËL: Something that can be interesting there, too, is that mathematically, there are multiple ways you can think of a 2D point. An xy coordinate pair is a common one, but another sort of system for representing a point in 2D space is called the polar coordinate system. So, you have some sort of, like, origin point. You're 0,0. And then, instead of saying so many to the left and so many up from that origin point, you give an angle and a distance, and that's where your point is. So, an angle and distance point, I think, you know, theta and magnitude are the fancy terms for this.

+ +

You could, instead of creating a separate, like, oh, I have a polar coordinate point and a Cartesian coordinate point, and those are separate things, you can say, no, I just have a point in 2D space. They can be constructed from either an xy coordinate pair or a magnitude angle pair.

+ +

Internally, maybe you convert one to the other for internal representation because it makes the math easier or whatever. Your users never need to know that. They just pass in the values that they want, use the constructor that is most convenient for them, and it might be both. Maybe some parts of the app require polar coordinates; some require Cartesian coordinates. You could even construct one of each, and now you can do math with each other because they're just instances of the same class.

+ +

STEPHANIE: Whoa. Yeah, I was trying to think about transforming between the two types as well. It's all possible [laughs].

+ +

JOËL: Yes. Because you could have reader-type methods on your object that say, oh, for this point, give me its x coordinate; give me its y coordinate. Give me its distance from the origin. Give me its angle from the origin. And those are all questions you can ask that object, and it can calculate them. And you don't need to care what its internal representation is to be able to get all four of those.

+ +

So, we've been talking about a lot of these sort of composite numbers, not composite numbers, that's a separate mathematical thing, but numbers that are composed of sort of multiple sub-numbers. And what about situations where you have two things, and one of them is not a number? I'm thinking of all sorts of units of measure. So, I don't just have three. I have three, maybe...and we were talking about currency earlier, so maybe three U.S. dollars. Or I don't just have five; I have five, you know, let's say, meters of distance. Would you consider something like that to be one of these compound number things?

+ +

STEPHANIE: Right. I think I was–when we were originally talking about this, conflating the two. But I realized that, you know, just because we're adding context to a number and potentially packaging it as a value object, it's still different from what we're talking about today where, you know, there's multiple components to the number that are integral or required for it to mean what we intended to mean, if that makes sense.

+ +

JOËL: Yeah.

+ +

STEPHANIE: So yeah, I guess we did want to kind of make a distinction between value objects that while the additional context is important and you can implement a lot of different functionality based on what it represents, at the end of the day, it only kind of has one magnitude or, like, one integer to kind of encapsulate it represented as a number. Does that sound right?

+ +

JOËL: Yeah. You did throw out the words encapsulation and value object. So, in a situation maybe where I have three US dollars, would you create some kind of custom object to wrap that? Or is that a situation where you'd be more comfortable using some kind of primitive? Like, I don't know, maybe an array pair of three and the symbol USD or something like that.

+ +

STEPHANIE: Oh, I would definitely not do that [laughter]. Yeah. Like I, you know, for the most part, I think I've seen that as a currency object, and that expands the world of what we can do with it, converting into a lot of different other currencies. And yeah, just making sure those things don't get divorced from each other because that context is what gives it meaning. But when it comes to our compound numbers, it's like, without all of the components, it doesn't make sense, or it doesn't even represent the same, like, numerical value that we were trying to convey.

+ +

JOËL: Right. You need both, or, you know, it could be more than two. It could be three, four, or five numbers together to mean something. You mentioned conversions, which I think is something that's also interesting because a lot of units of measure have sort of multiple ways of measuring, and you often want to convert between them. And maybe that's another case where encapsulation is really nice where, you know, maybe you have a distance object. And you have five meters, and you put that into your distance object, but then somebody wants it in feet somewhere else or in centimeters, or something like that. And it can just do all the conversion math safely inside that object, and the user doesn't have to worry about it.

+ +

STEPHANIE: Right. This is maybe a bit of a tangent, but as a Canadian living in the U.S., I don't know [laughs] if you have any opinions about converting meters and feet.

+ +

JOËL: The one I actually do the most often is converting Celsius to Fahrenheit and vice versa. You know, I've been here, what, 11 years now? I don't have a great intuition for Fahrenheit temperatures. So, I'm converting in my head just [laughs] on a daily basis.

+ +

STEPHANIE: Yeah, that makes sense. Conversions: they're important. They help out our friends who [laughs] are on different systems of measurement.

+ +

JOËL: There's a classic story that I love about unit conversions. I think it's one of the NASA Mars missions.

+ +

STEPHANIE: Oh yeah.

+ +

JOËL: You've heard of this one. It was trying to land on Mars, and it burned up in the atmosphere because two different teams had been building different components and used different unit systems, both according to spec for their own module. But then, when the modules try to talk to each other, they're sending over numbers in meters instead of feet or something like that. And it just caused [laughs] this, like, multi-year, multi-billion dollar project to just burn up.

+ +

STEPHANIE: That's right. So, lesson of the day is don't do that. I can think of another example where there might be a little bit of misconceptions in terms of how to represent it. And I'm thinking about time and when that has been represented in multiple parts, such as in hours and, minutes and seconds. Do you have any initial impressions about a piece of data like that?

+ +

JOËL: So, that's really interesting, right? Because, at first glance, it looks like, oh, it's, like, a triplet of hour, minute, seconds. It's sort of another one of these sort of compound numbers, and I guess you could implement it that way. But in reality, you're tracking a single quantity, the amount of time elapsed, and that can be represented with a single number.

+ +

So, if you're representing, let's say, time of day, what would show up on your clock? That could be, depending on the resolution, number of, let's say, seconds since midnight, and that's a single counter. And then, you can do some math on it to get hours, minutes, seconds for a particular moment. But really, it's a single quantity, and we can do that with time. We can't do that with a 2D point. Like, it has to have two components.

+ +

STEPHANIE: So, do you have a recommendation for what unit of time time would best be stored? I'm just thinking of all the times that I've had to do that millisecond, you know, that conversion of, you know, however many thousands of milliseconds in my head into something that actually means [laughs] something to me as a human being who measures time in hours and minutes.

+ +

JOËL: My recommendation is absolutely go for a single number that you store in your, let's say, time of day object. It makes the math so much easier. You don't have to worry about, like, overflowing from one number into another when you're doing math or anything like that. And then the number that you count should be at the whatever the smallest resolution you care at.

+ +

So, is there ever any time where you want to distinguish between two different milliseconds in time? Or maybe you're like, you know what? These are, like, we're tracking time of day for appointments. We don't care about the difference between two milliseconds. We don't need to track them independently. We don't even care about seconds. The most granular we ever care about things is by the minute. And so, maybe then your internal number that you track is a counter of minutes since midnight. But if you need more precision, you can go down to seconds or milliseconds or nanoseconds.

+ +

But yeah, find what is the sort of the least resolution you want to get away with and then make that the unit of measure for a single counter in your object. And then encapsulate that so that nobody else needs to care that, internally, your time of day object is doing milliseconds because nobody wants to do that math. Just give me a nice, like, hours and minutes method on your object, and I will use that. I don't need to know internally what it's using.

+ +

Please don't just pass around integers; wrap it in an object, especially because integers, there's enough times where you're doing seconds versus milliseconds. And when I just have an integer, I never know if the person storing this integer means seconds or milliseconds. So, I'm just like, oh, I'm going to pass to this, like, user object, a, like, time integer. And unless there's a comment or a constant, you know, that's named something duration in milliseconds or something like that, you know, or sometimes even, like, one year in milliseconds, or there's no way of knowing.

+ +

STEPHANIE: Yeah. That makes a lot of sense. When you kind of choose a standard of a standard unit, it's, like, possible to make it easier [laughs].

+ +

JOËL: So, circling back to sort of the initial thing that sparked this conversation, the previous episode about T-shirt inventories, there we were dealing with what started off as, like, a hash of different T-shirt sizes and quantities of T-shirts that we had in that size, so small (five), medium (three), large (four). And then, we eventually turned that into a value object that represented...I think we called it a tally, but maybe we called it inventory.

+ +

And this may be wrong, so tell me if I'm wrong here, I think we can kind of treat that as a number, as, like, one of these compound numbers. It's a sort of multidimensional number where you say, well, we have sort of three dimensions where we can have numbers that sort of increase and decrease independently. We can do math on these because we can take inventories or tallies and add and subtract them. And that's what we ended up having to do. We created a value object. We implemented plus and minus on it. There are rules for how the math works. I think this is a multidimensional number with the definition we're working on this show. Am I wrong here?

+ +

STEPHANIE: I wouldn't say that you're wrong. I think I would have to think a little [laughs] more to say definitively that you're right. But I know that this example came from, you know, an application I was actually working on. And one of the main things that we had to do with these representations [laughs], I'm hesitant to call them a number, especially, but we had to compare these representations frequently because an inventory, for example, in a warehouse, wanting to make sure that it is equal to or there's enough of the inventory if someone was placing an order, which would also contain, like, a representation of T-shirt size inventory.

+ +

And that was kind of where some of that math happened because, you know, maybe we don't want to let someone place an order if the inventory at the warehouse is smaller than their order, right? So, there is something really compelling about the comparison operations that we were doing that kind of is leaning me in the direction of, like, yeah, like, it makes sense to me to use this in a way that I would compare, like, quantities or numbers of something.

+ +

JOËL: I think one thing that was really compelling to me, and that kind of blew my mind, was that we were trying to, like, figure out some things like, oh, we've got so many people with these size preferences, and we've got so many T-shirts across different warehouses. And we're summing them up and we're trying to say like, "How many do we need to purchase if there is a deficit?"

+ +

And we can come up with effectively a formula for this. We're like, sum these numbers, when we're talking about just before we introduce sizes when it's just like, oh, people have T-shirts. They all get the count of people and a count of T-shirts in our warehouse, and we find, you know, the difference between that. And there's a few extra math operations we do.

+ +

Then you introduce size, and you break it down by, oh, we've got so many of each. And now the whole thing gets really kind of messy and complicated. And you're doing these reduces and everything. When we start treating the tally of T-shirts as an object, and now it's a number that responds to plus and minus, all of a sudden, you can just plug those back into the original formula, and it all just works. The original formula doesn't care whether the numbers you're doing this formula on are simple integers or these sort of multidimensional numbers. And that blew my mind, and it was so cool.

+ +

STEPHANIE: Yeah, that is really neat. And you get a lot of added benefits, too.

+ +

I think the other important piece in the T-shirt size example was kind of tracking the state change, and that's so much easier when you have an object. There's just a lot more you can do with it. And even if, you know, you're not persisting every single version of the representation, you know, because sometimes you don't want to, sometimes you're really just kind of only holding it in memory to figure out if you need to, you know, do something else. But other times, you do want to persist it. And it just plugs in really well with, like, the rest of object-oriented programming [laughs] in terms of interacting with the rest of your business needs, I think, in your app.

+ +

JOËL: Yeah, turns out objects, they're kind of nice. And you can do math with them. Who knew? Math is not just about integers.

+ +

STEPHANIE: And on that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël discusses the challenges he encountered while optimizing slow SQL queries in a non-Rails application. Stephanie shares her experience with canary deploys in a Rails upgrade. Together, Stephanie and Joël address a listener's question about replacing the wkhtml2pdf tool, which is no longer maintained.

+ +

The episode's main topic revolves around the concept of multidimensional numbers and their applications in software development. Joël introduces the idea of treating objects containing multiple numbers as single entities, using the example of 2D points in space to illustrate how custom classes can define mathematical operations like addition and subtraction for complex data types. They explore how this approach can simplify operations on data structures, such as inventories of T-shirt sizes, by treating them as mathematical objects.

+ + + +

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: I've recently been trying to do some performance enhancements to some very slow queries. This isn't a Rails app, so we're sort of combining together a bunch of different scopes. And the way they're composing together is turning out to be really slow. And I've reached for a tool that is just really fun. It's a visualizer for SQL query plans.

+ +

You can put the SQL keywords in front of a query: 'EXPLAIN ANALYZE,' and it will then output a query plan, sort of how it's going to attempt to do the work. And that might be like, oh, we're going to use this index on this table to join on this other thing, and then we're going to...maybe this is a table that we think we're going to do a sequential scan through and, you know, it builds out a whole thing.

+ +

It's a big block of text, and it's kind of intimidating to look at. So, there are a few websites out there that will do this. You just paste a query plan in, and they will build you a nice, little visualization, almost like a tree of, like, tasks to be done. Oftentimes, they'll also annotate it with metadata that they pulled from the query plan. So, oh, this particular node is the really expensive one because we're doing a sequential scan of this table that has 15 million rows in it. And so, it's really useful to then sort of pinpoint what are the areas that you could optimize.

+ +

STEPHANIE: Nice. I have known that you could do that EXPLAIN ANALYZE on a SQL query, but I've never had to do it before. Is this your first time, or is it just your first time using the visualizer?

+ +

JOËL: I've played around with EXPLAIN ANALYZE a little bit before. Pro tip: In Rails, if you've got a scope, you can just chain dot explain on the end, and instead of running the query, it will run the EXPLAIN version of it and return the query plan. So, you don't need to, like, turn into SQL then manually run it in your database system to get the EXPLAIN. You can just tack a dot explain on there to get the query plan.

+ +

It's still kind of intimidating, especially if you've got a really complex query that's...this thing might be 50 lines long of EXPLAIN with all this indentation and other stuff. So, putting it into a sort of online visualizer was really helpful for the work that I was doing. So, it was my first time using an online visualizer. There are a few out there. I'll link to the one that I used in the show notes. But I would do that again, would recommend.

+ +

STEPHANIE: Nice.

+ +

JOËL: So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I actually just stepped away from being in the middle of doing a Rails upgrade [chuckles] and releasing it to production just a few minutes before getting on to record with you on this podcast. And the reason I was able to do that, you know, without feeling like I had to just monitor to see how it was going is because I'm on a project where the client is using canary deploys. And I was so pleasantly surprised by how easy it made this experience where we had decided to send the canary release earlier this morning.

+ +

And the way that they have it set up is that the canary goes to 10% of traffic. 10% of the users were on Rails 7 for their sessions. And we saw a couple of errors in our error monitoring service. And we are like, "Okay, like, let's take a look at this, see what's going on." And it turns out it was not too big of a deal because it had to do with, like, a specific page. And, for the most part, if a user did encounter this error, they probably wouldn't again after refreshing because they had, like, a 90% chance [chuckles] of being directed to the previous version where everything is working.

+ +

And we were kind of making that trade-off of like, oh, we could hotfix this right now on the canary release. But then, as we were starting to debug a little bit, it was a bit hairier than we expected originally. And so, you know, I said, "I have to hop on to go record The Bike Shed. So, why don't we just take this canary down just for the time being to take that time pressure off? And it's Friday, so we're heading into the weekend. And maybe we can revisit the issue with some fresh eyes." So, I'm feeling really good, actually. And I'm glad that we were able to do something that seems scary, but there were guardrails in place to make it a lot more chill.

+ +

JOËL: Yay for the ability to roll back. You used the term canary release. That's not one that I'm familiar with. Can you explain what a canary release is?

+ +

STEPHANIE: Oh yeah. Have you heard of the phrase 'Canary in the coal mine'?

+ +

JOËL: I have.

+ +

STEPHANIE: Okay. So, I believe it's the same idea where you are, in this case, releasing a potentially risky change, but you don't want to immediately make it available to, like, all of your users. And so, you send this change to, like, a small reach, I suppose, and give it a little bit of a test and see [chuckles] what comes back. And that can help inform you of any issues or risks that might happen before kind of committing to deploying a potentially risky change with a bigger impact.

+ +

JOËL: Is this handled with something like a feature flag framework? Or is this, like, at an infrastructure level where you're just like, "Hey, we've got the canary image in, like, one container on one server, and then we'll redirect 10% of traffic to that to be served by that one and the other 90% to be served by the old container or something like that"?

+ +

STEPHANIE: Yeah, in this case, it was at the infrastructure level. And I have also seen something similar at a feature flag level, too, where you're able to have some more granularity around what percent of users are seeing a feature. But I think with something like a Rails upgrade, it was nice to be able to have that at that infrastructure level. It's not necessarily, like, a particular page or feature to show or not show.

+ +

JOËL: Yeah, I think you would probably want that at a higher level when you're changing over the entire app. Is this something that you had to custom-build yourself or something that just sort of came out of the box with some of the infrastructure tools you're using?

+ +

STEPHANIE: It came out of the box, actually. I just joined this client project this week and was very delighted to see just some really great deployment infrastructure and getting to meet the DevOps engineers, too, who built it. And they're really proud of it. They kind of walked us through our first release earlier this week. And he was telling me, the DevOps engineer, that this was actually his favorite part of the job, is walking people through their first release and being their buddy while they do it. Because I think he gets to also see users interact with the tool that he built, and he had a lot of pride in that, so it was a very delightful experience.

+ +

JOËL: That's so wonderful. I've been on so many projects where the sort of infrastructure side of things is not the team's strong point, and releasing can be really scary. And it's great to hear the opposite of that.

+ +

We recently received a question for Stephanie based on an earlier episode. So, the question asks, "In episode 413, Stephanie discussed a recent issue she encountered with wkhtml2pdf. The episode turned into a deeper discussion about package management, but I don't think it ever cycled back to the conclusion. I'm curious: how did Stephanie solve this dilemma? We're facing the same issue on a project that my team maintains. It's an old codebase, and there are bits of old code that use wkhtml2pdf to generate print views of our data in our application.

+ +

The situation is fairly dire. wkhtml2pdf is no longer maintained. In fact, it won't even be available to install from our operating system's package repositories in June. We're on FreeBSD, but I assume the same will be eventually true for other operating systems. And so, unless you want to maintain some build step to check out and compile the source code for an application that will no longer receive security updates, just living with it isn't really an option.

+ +

There are three options we're considering. One, eliminate the dependency entirely. Based on user feedback, it sounds like our old developers were using this library to generate PDFs when what users really wanted was an easy way to print. So, instead of downloading a PDF, just ensure the screen has a good print style sheet and register an onload handler to call window dot print. We're thinking we could implement this as an A/B test to the feature to test this theory. Or two, replace wkhtml2pdf with a call to Headless Chrome and use that to generate the PDF. Or, three, replace wkhtml2pdf with a language-level package. For us, that might be the dompdf library available via Composer because we're a PHP shop."

+ +

Yeah, a lot to unpack here. Any high-level thoughts, Stephanie?

+ +

STEPHANIE: My first thought while I was listening to you read that question is that wkhtml2pdf is such a mouthful [laughs]. And I was impressed how you managed to say it at least, like, five times.

+ +

JOËL: So, I try to say that five times fast.

+ +

STEPHANIE: And then, my second high-level thought was, I'm so sorry to Brian, our listener who wrote in, because I did not really solve this dilemma [chuckles] for my project and team. I kind of kicked the can down the road, and that's because this was during a support and maintenance rotation that I've talked a little bit about before on the show. I was only working on this project for about a week.

+ +

And what we thought was a small bug to figure out why PDFs were a little bit broken turned out, as you mentioned, to be this kind of big, dire dilemma where I did not feel like I had enough information to make a good call about what to do. So, I kind of just shared my findings that, like, hey, there is kind of a risk and hoping that someone else [laughs] would be able to make a better determination.

+ +

But I really was struck by the options that you were considering because it was actually a bit of a similar situation to the bug I was sharing where the PDF that was being generated that was slightly broken. I don't think it was, like, super valuable to our users that it be in the form of a PDF. It really was just a way for them to print something to have on handy as a reference from, you know, some data that was generated from the app. So, yeah, based on what you're sharing, I feel really excited about the first one. Joël, I'm sure you have some opinions about this as well.

+ +

JOËL: I love sort of the bigger picture thinking that Brian is doing here, sort of stepping back and being like, wait, why do we even need PDF here, and how are our customers using it? I think those are the really good questions to ask before sinking a ton of time into coming up with something that might be, like, a bit of a technical wonder. Like, hey, we managed to, like, do this PDF generation thing that we had to, like, cobble together so many other things. And it's so cool technically, but does it actually solve the underlying problem? So, shout out to Brian for thinking about it in those terms. I love that.

+ +

Second cool thing that I wanted to shout out, because I think this is a feature of browsers that not many people are aware of; you can have multiple style sheets for your page, and you can tag them to be for different media. So, you can have a style sheet that only gets applied when you print versus when you display on screen. And there are a couple of others. I don't remember exactly what they are. I'll link to the docs in the show notes.

+ +

But taking advantage of this, like, this is old technology but making that available and saying, "Yeah, we'll make it so that it's nice when you print, and we'll maybe even, you know, a link or a button with JavaScript so that you could just Command-P or Control-P to print. But we'll have a button in there as well that will allow you to print to PDF," and that solves your problem right there.

+ +

STEPHANIE: Yeah, that's really cool. I didn't know that about being able to tag style sheets for different media types. That's really fascinating. And I like that, yeah, we're just eliminating this dependency on something, like, potentially really complex with a, hopefully, kind of elegant and modern solution, maybe.

+ +

JOËL: And your browser is already able to do so many of these things. Why do we sort of try to recreate it? Printing is a thing browsers have been able to do for a long time. Printing to PDF is a thing that you can do for a long time. I will sometimes use that on sites where I need to, let's say I'm purchasing something, and I need some sort of receipt to expense, but they won't give me a download, a PDF download that I can send to the accounting team, so I will print to PDF the, like, HTML view. And that works just fine. It's kind of a workaround hack.

+ +

Sometimes, it doesn't work well because the HTML page is just not well set up to, like, show up on a PDF page. You get some, like, weird, like, pagination issues or things like that. But, you know, just a little bit of thought for a print style sheet, especially for something you know that people are likely going to want to print or to save to PDF, that's a nice touch.

+ +

STEPHANIE: Yeah. So, good luck, Brian, and let us know how this goes and any outcomes you find successful. So, for today's longer topic, I was excited because I saw, Joël, you dropped something in our topic backlog: Multidimensional Numbers. I'm curious what prompted this idea and what you wanted to say about it.

+ +

JOËL: We did an episode a while back where we talked about value objects, wrapping numbers, wrapping collections. This is Episode 386, and we were talking about tallying, specifically working with collections of T-shirt sizes and doing math on these sort of objects that might contain multiple numbers. And a sort of sidebar from that that we didn't really get into is the idea that objects that contain sort of multiple numbers can be treated as a number themselves.

+ +

And I think a great example of this is something like a point in two-dimensional space. It's got an x coordinate, a y coordinate. It's two numbers, but you can treat sort of the combination of the two of them together as a single number. There's a whole set of coordinate math that you can do to do things like add coordinates together, subtract them, find the distance between them. There's a whole field of vector math that we can do on those.

+ +

And I think learning to recognize that numbers are not just instances of the integer or the float class but that there could be these more complex things that are also numbers is maybe an important realization and something that, as developers, if we think of these sort of more complex values as numbers, or at least mathematical objects, then that will help us write better code.

+ +

STEPHANIE: Cool. Yeah. When you were first talking about 2D points, I was thinking about if I have experience working with that before or, like, having to build something really heavily based off of, like, a canvas or, you know, a coordinate system. And I couldn't think of any really good examples until I thought about, like, geographic locations.

+ +

JOËL: Oh yeah, like a latitude, longitude.

+ +

STEPHANIE: Yeah, exactly. Like, that is a lot more common, I think, for various types of just, like, production applications than 2D points if you're not working on, like, a video game or something like that, I think.

+ +

JOËL: Right, right. I think you're much more likely to be working with 2D points on some more sort of front-end-heavy application. I was talking with someone this week about managing a seat map for concerts and events like that and sort of creating a seat map and have it be really interactive, and you can, like, click on seats and things like that. And depending on the level of libraries you're using to build that, you may have to do a lot of 2D math to make it all come together.

+ +

STEPHANIE: Yeah. So, I would love to get into, you know, maybe we've realized, okay, we have some kind of compound number. What are some good reasons for using them differently than you would a primitive?

+ +

JOËL: So, you mentioned primitives, and I think this is where maybe I'm developing a reputation about, like, always wanting value objects for everything. But it would be really easy, let's say, for an xy point to be just an array of two numbers or maybe even a hash with an x key and a y key.

+ +

What's tricky about that is that then you don't have the ability to do math on them. Arrays do define the plus operator, but they don't do what you want them to do with points. It's the set union. So, adding two points would not at all do what you want, or subtracting two points. So, instead, if you have a custom 2D point class and you can define plus and minus on there to do the right thing, now they're not pairs of numbers, two values; they're a single value, and you can treat them as if they are just a single number.

+ +

STEPHANIE: You mentioned that arrays don't do the right thing when you try to add them up. What is the right thing that you're thinking of then?

+ +

JOËL: It probably depends a little bit on the type of object you're working with. So, with 2D points, you're probably trying to do vector addition where you're effectively saying almost, like, "Shift this point in 2D space by the amount of this other point." Or if you're doing a subtraction, you might even be asking, like, "What is the distance between these two points?" Euclidean distance, I think, is the technical term for this.

+ +

There's also a couple of different ways you can multiply values. You can multiply a 2D point by just a sort of, not by another point, but by just an integer. That's called scaling. So, you're just like, oh, take this point in 2D space, but make it bigger, make it five times bigger or five times further from the origin. Or you can do some stuff with other points. But what you don't want to do is turn this into, if you're starting with arrays, you don't want to turn this into an array of four points. When you add two points in 2D space, you're not trying to create a point in 4D space.

+ +

STEPHANIE: Whoa, I mean [laughs], maybe you're not.

+ +

JOËL: You could but -- [laughter]

+ +

STEPHANIE: Yeah. While you were saying that, I guess that is what is really cool about wrapping, encapsulating them in objects is that you get to decide what that means for you and your application, and --

+ +

JOËL: Yeah. Well, plus can mean different things, right?

+ +

STEPHANIE: Yeah.

+ +

JOËL: On arrays, plus means combining two arrays together. On integers, it means you do integer math. And on points, it might be vector addition.

+ +

STEPHANIE: Are there any other arithmetic operators you can think of that would be useful to implement if you were trying to create some functionality on a point?

+ +

JOËL: That's a good question because I think realizing the inverse of that is also a really powerful thing. Just because you create a sort of new mathematical object, a point in 2D space, doesn't mean that necessarily every arithmetic operator makes sense on it. Does it make sense to divide a point by another point? Maybe not. And so, instead of going with the mindset of, oh, a point is a mathematical object, I now need to implement all of arithmetic on this, instead, think in terms of your domain. What are the operations that make sense? What are the operations you need for this point?

+ +

And, you know, maybe the answer is look up what are the common sort of vector math operations and implement those on your 2D point. Some of them will map to arithmetic operators like plus and minus, and then some of them might just be some sort of custom method where maybe you say, "Oh, I want the Euclidean distance between these two points." That's just a thing. Maybe it's just a named instance method on there. But yeah, don't feel like you need to implement all of the math operators because that's a mistake that I have made and then have ended up, like, implementing nonsensical things.

+ +

STEPHANIE: [laughs] Creating your own math.

+ +

JOËL: Yes, creating my own math. I've done this even on where I've done value objects to wrap single values. I was doing a class to represent currency, and I was like, well, clearly, you need, like, methods to, like, add or subtract your currency, and that's another thing. If you have, let's say, a plus method, now you can plug it into, let's say, reduce plus. And you can just sum a list of these currency objects and get back a new currency. It's not even going to give you back an integer. You just get a sort of new currency object that is the sum of all the other ones, and that's really nice.

+ +

STEPHANIE: Yeah, that's really cool. It reminds me of all the magic of enumerable that you had talked about in a previous conference talk, where, you know, you just get so much out of implementing those basic operators that, like, kind of scales in handiness.

+ +

JOËL: Yes. Turns out Ruby is actually a pretty nice system. If you have objects that respond to some common methods and you plug them into enumerable, and it just all kind of works.

+ +

STEPHANIE: So, one thing you had said earlier that I've felt kind of excited about and wanted to highlight was you mentioned all the different ways that you could represent a 2D point with more primitive data stores, so, you know, an array of two integers, a hash with xy keys. It got me thinking about how, yeah, like, maybe if your system has to talk to another system and you're importing data or exporting data, it might eventually need to take those forms.

+ +

But what is cool about having an encapsulated object in your application is you can kind of control those boundaries a little bit and have more confidence in terms of the data types that you're using within your system by having various ways to construct that, like, domain object, even if the data coming in is in a different shape.

+ +

JOËL: And I think that you're hitting on one of the real beauties of object-oriented programming, where the sort of users of your object don't need to know about the internal representation. Maybe you store an array internally. Maybe it's two separate instance variables. Maybe it's something else entirely. But all that the users of your, let's say, 2D point object really need to care about is, hey, the constructor wants values in this shape, and then I can call these domain methods on it, and then the rest just sort of happens. It's an implementation detail. It doesn't matter.

+ +

And you alluded, I think, to the idea that you can sort of create multiple constructors. You called them constructors. I tend to call them that as well. But they're really just class methods that will kind of, like, add some sugar on top of the constructor. So, you might have, like, a from array pair or from hash or something like that that allows you to maybe do a little bit of massaging of the data before you pass it into your constructor that might want some underlying form. And I think that's a pattern that's really nice.

+ +

STEPHANIE: Yeah, I agree.

+ +

JOËL: Something that can be interesting there, too, is that mathematically, there are multiple ways you can think of a 2D point. An xy coordinate pair is a common one, but another sort of system for representing a point in 2D space is called the polar coordinate system. So, you have some sort of, like, origin point. You're 0,0. And then, instead of saying so many to the left and so many up from that origin point, you give an angle and a distance, and that's where your point is. So, an angle and distance point, I think, you know, theta and magnitude are the fancy terms for this.

+ +

You could, instead of creating a separate, like, oh, I have a polar coordinate point and a Cartesian coordinate point, and those are separate things, you can say, no, I just have a point in 2D space. They can be constructed from either an xy coordinate pair or a magnitude angle pair.

+ +

Internally, maybe you convert one to the other for internal representation because it makes the math easier or whatever. Your users never need to know that. They just pass in the values that they want, use the constructor that is most convenient for them, and it might be both. Maybe some parts of the app require polar coordinates; some require Cartesian coordinates. You could even construct one of each, and now you can do math with each other because they're just instances of the same class.

+ +

STEPHANIE: Whoa. Yeah, I was trying to think about transforming between the two types as well. It's all possible [laughs].

+ +

JOËL: Yes. Because you could have reader-type methods on your object that say, oh, for this point, give me its x coordinate; give me its y coordinate. Give me its distance from the origin. Give me its angle from the origin. And those are all questions you can ask that object, and it can calculate them. And you don't need to care what its internal representation is to be able to get all four of those.

+ +

So, we've been talking about a lot of these sort of composite numbers, not composite numbers, that's a separate mathematical thing, but numbers that are composed of sort of multiple sub-numbers. And what about situations where you have two things, and one of them is not a number? I'm thinking of all sorts of units of measure. So, I don't just have three. I have three, maybe...and we were talking about currency earlier, so maybe three U.S. dollars. Or I don't just have five; I have five, you know, let's say, meters of distance. Would you consider something like that to be one of these compound number things?

+ +

STEPHANIE: Right. I think I was–when we were originally talking about this, conflating the two. But I realized that, you know, just because we're adding context to a number and potentially packaging it as a value object, it's still different from what we're talking about today where, you know, there's multiple components to the number that are integral or required for it to mean what we intended to mean, if that makes sense.

+ +

JOËL: Yeah.

+ +

STEPHANIE: So yeah, I guess we did want to kind of make a distinction between value objects that while the additional context is important and you can implement a lot of different functionality based on what it represents, at the end of the day, it only kind of has one magnitude or, like, one integer to kind of encapsulate it represented as a number. Does that sound right?

+ +

JOËL: Yeah. You did throw out the words encapsulation and value object. So, in a situation maybe where I have three US dollars, would you create some kind of custom object to wrap that? Or is that a situation where you'd be more comfortable using some kind of primitive? Like, I don't know, maybe an array pair of three and the symbol USD or something like that.

+ +

STEPHANIE: Oh, I would definitely not do that [laughter]. Yeah. Like I, you know, for the most part, I think I've seen that as a currency object, and that expands the world of what we can do with it, converting into a lot of different other currencies. And yeah, just making sure those things don't get divorced from each other because that context is what gives it meaning. But when it comes to our compound numbers, it's like, without all of the components, it doesn't make sense, or it doesn't even represent the same, like, numerical value that we were trying to convey.

+ +

JOËL: Right. You need both, or, you know, it could be more than two. It could be three, four, or five numbers together to mean something. You mentioned conversions, which I think is something that's also interesting because a lot of units of measure have sort of multiple ways of measuring, and you often want to convert between them. And maybe that's another case where encapsulation is really nice where, you know, maybe you have a distance object. And you have five meters, and you put that into your distance object, but then somebody wants it in feet somewhere else or in centimeters, or something like that. And it can just do all the conversion math safely inside that object, and the user doesn't have to worry about it.

+ +

STEPHANIE: Right. This is maybe a bit of a tangent, but as a Canadian living in the U.S., I don't know [laughs] if you have any opinions about converting meters and feet.

+ +

JOËL: The one I actually do the most often is converting Celsius to Fahrenheit and vice versa. You know, I've been here, what, 11 years now? I don't have a great intuition for Fahrenheit temperatures. So, I'm converting in my head just [laughs] on a daily basis.

+ +

STEPHANIE: Yeah, that makes sense. Conversions: they're important. They help out our friends who [laughs] are on different systems of measurement.

+ +

JOËL: There's a classic story that I love about unit conversions. I think it's one of the NASA Mars missions.

+ +

STEPHANIE: Oh yeah.

+ +

JOËL: You've heard of this one. It was trying to land on Mars, and it burned up in the atmosphere because two different teams had been building different components and used different unit systems, both according to spec for their own module. But then, when the modules try to talk to each other, they're sending over numbers in meters instead of feet or something like that. And it just caused [laughs] this, like, multi-year, multi-billion dollar project to just burn up.

+ +

STEPHANIE: That's right. So, lesson of the day is don't do that. I can think of another example where there might be a little bit of misconceptions in terms of how to represent it. And I'm thinking about time and when that has been represented in multiple parts, such as in hours and, minutes and seconds. Do you have any initial impressions about a piece of data like that?

+ +

JOËL: So, that's really interesting, right? Because, at first glance, it looks like, oh, it's, like, a triplet of hour, minute, seconds. It's sort of another one of these sort of compound numbers, and I guess you could implement it that way. But in reality, you're tracking a single quantity, the amount of time elapsed, and that can be represented with a single number.

+ +

So, if you're representing, let's say, time of day, what would show up on your clock? That could be, depending on the resolution, number of, let's say, seconds since midnight, and that's a single counter. And then, you can do some math on it to get hours, minutes, seconds for a particular moment. But really, it's a single quantity, and we can do that with time. We can't do that with a 2D point. Like, it has to have two components.

+ +

STEPHANIE: So, do you have a recommendation for what unit of time time would best be stored? I'm just thinking of all the times that I've had to do that millisecond, you know, that conversion of, you know, however many thousands of milliseconds in my head into something that actually means [laughs] something to me as a human being who measures time in hours and minutes.

+ +

JOËL: My recommendation is absolutely go for a single number that you store in your, let's say, time of day object. It makes the math so much easier. You don't have to worry about, like, overflowing from one number into another when you're doing math or anything like that. And then the number that you count should be at the whatever the smallest resolution you care at.

+ +

So, is there ever any time where you want to distinguish between two different milliseconds in time? Or maybe you're like, you know what? These are, like, we're tracking time of day for appointments. We don't care about the difference between two milliseconds. We don't need to track them independently. We don't even care about seconds. The most granular we ever care about things is by the minute. And so, maybe then your internal number that you track is a counter of minutes since midnight. But if you need more precision, you can go down to seconds or milliseconds or nanoseconds.

+ +

But yeah, find what is the sort of the least resolution you want to get away with and then make that the unit of measure for a single counter in your object. And then encapsulate that so that nobody else needs to care that, internally, your time of day object is doing milliseconds because nobody wants to do that math. Just give me a nice, like, hours and minutes method on your object, and I will use that. I don't need to know internally what it's using.

+ +

Please don't just pass around integers; wrap it in an object, especially because integers, there's enough times where you're doing seconds versus milliseconds. And when I just have an integer, I never know if the person storing this integer means seconds or milliseconds. So, I'm just like, oh, I'm going to pass to this, like, user object, a, like, time integer. And unless there's a comment or a constant, you know, that's named something duration in milliseconds or something like that, you know, or sometimes even, like, one year in milliseconds, or there's no way of knowing.

+ +

STEPHANIE: Yeah. That makes a lot of sense. When you kind of choose a standard of a standard unit, it's, like, possible to make it easier [laughs].

+ +

JOËL: So, circling back to sort of the initial thing that sparked this conversation, the previous episode about T-shirt inventories, there we were dealing with what started off as, like, a hash of different T-shirt sizes and quantities of T-shirts that we had in that size, so small (five), medium (three), large (four). And then, we eventually turned that into a value object that represented...I think we called it a tally, but maybe we called it inventory.

+ +

And this may be wrong, so tell me if I'm wrong here, I think we can kind of treat that as a number, as, like, one of these compound numbers. It's a sort of multidimensional number where you say, well, we have sort of three dimensions where we can have numbers that sort of increase and decrease independently. We can do math on these because we can take inventories or tallies and add and subtract them. And that's what we ended up having to do. We created a value object. We implemented plus and minus on it. There are rules for how the math works. I think this is a multidimensional number with the definition we're working on this show. Am I wrong here?

+ +

STEPHANIE: I wouldn't say that you're wrong. I think I would have to think a little [laughs] more to say definitively that you're right. But I know that this example came from, you know, an application I was actually working on. And one of the main things that we had to do with these representations [laughs], I'm hesitant to call them a number, especially, but we had to compare these representations frequently because an inventory, for example, in a warehouse, wanting to make sure that it is equal to or there's enough of the inventory if someone was placing an order, which would also contain, like, a representation of T-shirt size inventory.

+ +

And that was kind of where some of that math happened because, you know, maybe we don't want to let someone place an order if the inventory at the warehouse is smaller than their order, right? So, there is something really compelling about the comparison operations that we were doing that kind of is leaning me in the direction of, like, yeah, like, it makes sense to me to use this in a way that I would compare, like, quantities or numbers of something.

+ +

JOËL: I think one thing that was really compelling to me, and that kind of blew my mind, was that we were trying to, like, figure out some things like, oh, we've got so many people with these size preferences, and we've got so many T-shirts across different warehouses. And we're summing them up and we're trying to say like, "How many do we need to purchase if there is a deficit?"

+ +

And we can come up with effectively a formula for this. We're like, sum these numbers, when we're talking about just before we introduce sizes when it's just like, oh, people have T-shirts. They all get the count of people and a count of T-shirts in our warehouse, and we find, you know, the difference between that. And there's a few extra math operations we do.

+ +

Then you introduce size, and you break it down by, oh, we've got so many of each. And now the whole thing gets really kind of messy and complicated. And you're doing these reduces and everything. When we start treating the tally of T-shirts as an object, and now it's a number that responds to plus and minus, all of a sudden, you can just plug those back into the original formula, and it all just works. The original formula doesn't care whether the numbers you're doing this formula on are simple integers or these sort of multidimensional numbers. And that blew my mind, and it was so cool.

+ +

STEPHANIE: Yeah, that is really neat. And you get a lot of added benefits, too.

+ +

I think the other important piece in the T-shirt size example was kind of tracking the state change, and that's so much easier when you have an object. There's just a lot more you can do with it. And even if, you know, you're not persisting every single version of the representation, you know, because sometimes you don't want to, sometimes you're really just kind of only holding it in memory to figure out if you need to, you know, do something else. But other times, you do want to persist it. And it just plugs in really well with, like, the rest of object-oriented programming [laughs] in terms of interacting with the rest of your business needs, I think, in your app.

+ +

JOËL: Yeah, turns out objects, they're kind of nice. And you can do math with them. Who knew? Math is not just about integers.

+ +

STEPHANIE: And on that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+hSrIEEkE + + ]]> + + Joël Quenneville + Stephanie Minn + + + 415: Codebase Calibration + https://bikeshed.thoughtbot.com/415 + 535f3683-574d-4cec-8c11-5c6c80266b6c + Tue, 06 Feb 2024 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie has a delightful and cute Ruby thing to share: Honeybadger, the error monitoring service, has created exceptionalcreatures.com, where they've illustrated and characterized various common Ruby errors into little monsters, and they're adorable. Meanwhile, Joël encourages folks to submit proposals for RailsConf. + +Together, Stephanie and Joël delve into the nuances of adapting to and working within new codebases, akin to aligning with a shared mental model or vision. They ponder several vital questions that every developer faces when encountering a new project: the balance between exploring a codebase to understand its structure and diving straight into tasks, the decision-making process behind adopting new patterns versus adhering to established ones, and the strategies teams can employ to assist developers who are familiarizing themselves with a new environment. + 30:54 + no + + + Stephanie has a delightful and cute Ruby thing to share: Honeybadger, the error monitoring service, has created exceptionalcreatures.com, where they've illustrated and characterized various common Ruby errors into little monsters, and they're adorable. Meanwhile, Joël encourages folks to submit proposals for RailsConf. +Together, Stephanie and Joël delve into the nuances of adapting to and working within new codebases, akin to aligning with a shared mental model or vision. They ponder several vital questions that every developer faces when encountering a new project: the balance between exploring a codebase to understand its structure and diving straight into tasks, the decision-making process behind adopting new patterns versus adhering to established ones, and the strategies teams can employ to assist developers who are familiarizing themselves with a new environment. +Honeybadger's Exceptional Creatures (https://www.exceptionalcreatures.com/) +RailsConf CFP coaching sessions (https://docs.google.com/forms/d/e/1FAIpQLScZxDFaHZg8ncQaOiq5tjX0IXvYmQrTfjzpKaM_Bnj5HHaNdw/viewform) +HTTP Cats (https://http.cat/) +Support and Maintenance Episode (https://bikeshed.thoughtbot.com/409) +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: I have a delightful and cute Ruby thing to share I'd seen just in our internal company Slack. Honeybadger, the error monitoring service, has created a cute little webpage called exceptionalcreatures.com, where they've basically illustrated and characterized various common Ruby errors into little monsters [laughs], and I find them adorable. I think their goal is also to make it a really helpful resource for people encountering these kinds of errors, learning about them for the first time, and figuring how to triage or debug them. +And I just think it's a really cool way of, like, making it super approachable, debugging and, you know, when you first encounter a scary error message, can be really overwhelming, and then Googling about it can also be equally [chuckles] overwhelming. So, I just really liked the whimsy that they kind of injected into something that could be really hard to learn about. Like, there are so many different error messages in Ruby and in Rails and whatever other libraries you're using. And so, that's kind of a...I think they've created a one-stop shop for, you know, figuring out how to move forward with common errors. +And I also like that it's a bit of a collective effort. They're calling it, like, a bestiary for all the little creatures [laughs] that they've discovered. And I think you can, like, submit your own favorite Ruby error and any guidance you might have for someone trying to debug it. +JOËL: That's adorable. It reminds me a little bit of HTTP status codes as cat memes site. It has that same energy. One thing that I think is really interesting is that because it's Honeybadger, they have stats on, like, frequency of these errors, and a lot of these ones are tied to...I think they're picking some of the most commonly surfaced errors. +STEPHANIE: Yeah, there's little, like, ratings, too, for how frequently they occur, kind of just like, I don't know, Pokémon [laughs] [inaudible 02:31]. I think it's really neat that they're using something like a learning from their business or maybe even some, like, proprietary information and sharing it with the world so that we can learn from it. +JOËL: I think one thing that's worth specifying as well is that these are specific exception classes that get raised. So, they're not just, like, random error strings that you see in the wild. They don't often have a whole lot of documentation around them, so it's nice to see a dedicated page for each and a little bit of maybe how this is used in the real world versus maybe how they were designed to be used. Maybe there's a line or two in the docs about, you know, core Ruby when a NoMethodError should be raised. How does NoMethodError actually get used, you know, in real life, and the exceptions that Honeybadger is capturing. That's really interesting to see. +STEPHANIE: Yeah, I like how each page for the exception class, and I'm glad you made that distinction, is kind of, like, crowdsourced guidance and information from the community, so I think you could even, you know, contribute to it if you wanted. But yeah, just a fun, little website to bring you some delight when you're on your next head-smacking, debugging adventure [laughs]. +JOËL: And I love that it brings some joy to the topic, but, honestly, I think it's a pretty good reference. I could see myself linking to this anytime I want to have a deeper discussion on exceptions. So, maybe there's a code review, and maybe I want to suggest that we raise a different error than the one that we're doing. I could see myself in that GitHub comment being like, "Oh, instead of, you know, raising an exception here, why don't we instead raise a NoMethodError or something like that?" And then link to the bestiary page. +STEPHANIE: So, Joël, what's new in your world? +JOËL: So, just recently, RailsConf announced their call for proposals. It's a fairly short period this year, only about three-ish weeks long. So, I've been really encouraging colleagues to submit and trying to be a resource for people who are interested in speaking at conferences. We did a Q&A session with a fellow thoughtboter, Aji Slater, who's also a former RailsConf speaker, about what makes for a good talk, what is it like to submit to a call for proposals, you know, kind of everything from the process from having an idea all the way to stage presence and delivering. And there's a lot of great questions that got asked and some good discussion that happened there. +STEPHANIE: Nice. Yeah, I think I have noticed that you are doing a lot more to help, especially first-time speakers give their first conference talk this year. And I'm wondering if there's anything you've learned or any hopes and dreams you have for kind of the amount of time you're investing into supporting others. +JOËL: What I'd like to see is a lot of people submitting proposals; that's always a great thing. And, a proposal, even if it doesn't get accepted, is a thing that you can resubmit. And so, having gone through the effort of building a proposal and especially getting it maybe peer-reviewed by some colleagues to polish your idea, I think is already just a really great exercise, and it's one that you can shop around. It's one that you can maybe convert into a blog post if you need to. You can convert that into some kind of podcast appearance. So, I think it's a great way to take an idea you're excited about and focus it, even if you can't get into RailsConf. +STEPHANIE: I really like that metric for success. It reminds me of a writer friend I have who actually was a guest on the show, Nicole Zhu. She submits a lot of short stories to magazines and applications to writing fellowships, and she celebrates every rejection. I think at the end of the year, she, like, celebrates herself for having received, you know, like, 15 rejections or something that year because that meant that she just went for it and, you know, did the hard part of doing the work, putting yourself out there. And that is just as important, you know, if not more than whatever achievement or goal or the idea of having something accepted. +JOËL: Yeah, I have to admit; rejection hurts. It's not a fun thing to go through. But I think even if you sort of make it to that final stage of having written a proposal and it gets rejected, you get a lot of value out of that journey sort of regardless of whether you get accepted or not. So, I encourage more people to do that. +To any of our listeners who are interested, the RailsConf call for proposals goes through February 13th, 2024. So, if you are listening before then and are inspired, I recommend submitting. If you're unsure of what makes for a good CFP, RailsConf is currently offering coaching sessions to help craft better proposals. They have one on February 5th, one on February 6th, and one on February 7th, so those are also options to look into if this is maybe your first time and you're not sure. There's a signup form. We'll link to it in the show notes. +STEPHANIE: So, another update I have that I'm excited to get into for the rest of the episode is my recent work on our support and maintenance team, which I've talked about on the show before. But for any listeners who don't know, it's a kind of sub-team at thoughtbot that is focused on helping maintain multiple client projects at a time. But, at this point, you know, there's not as much active feature development, but the work is focused on keeping the codebase up to date, making any dependency upgrades, fixing any bugs that come up, and general support. So, clients have a team to kind of address those things as they come up. +And when I had last talked about it on the podcast, I was really excited because it was a bit of a different way of working. I felt like it was very novel to be, you know, have a lot of different projects and domains to be getting into. And knowing that I was working on this team, like, short-term and, you know, it may not be me in the future continuing what I might have started during my rotation, I thought it was really interesting to be optimizing towards, like, completion of a task. And that had kind of changed my workflow a bit and my process. +JOËL: So, now that you've been doing work on the support and maintenance team for a while and you've kind of maybe gotten more comfortable with it, how are you generally feeling about this idea of sort of jumping into new codebases all the time? +STEPHANIE: It is both fun and more challenging than I thought it would be. I tend to actually really enjoy that period of joining a new team or a project and exploring, you know, a codebase and getting up to speed, and that's something that we do a lot as consultants. But I think I started to realize that it's a bit of a tricky balance to figure out how much time should I be spending understanding what this codebase is doing? Like, how much of the application do I need to be understanding, and how much poking around should I be doing before just trying to get started on my first task, the first starter ticket that I'm given? +There's a bit of a balance there because, on one hand, you could just immediately start on the task and kind of just, you know, have your blinders [chuckles] on and not really care too much about what the rest of the code is doing outside of the change that you're trying to make. But that also means that you don't have that context of why certain things are the way they are. Maybe, like, the way that you want to be building something actually won't work because of some unexpected complexity with the app. +So, I think there, you know, needs to be time spent digging around a little bit, but then you could also be digging around for a long time [chuckles] before you feel like, okay, I finally have enough understanding of this new codebase to, like, build a feature exactly how a seasoned developer on the team might. +JOËL: I imagine that probably varies a little bit based on the task that you're doing. So, something like, oh, we want to upgrade this codebase to Ruby 3.3, probably requires you to have a very different understanding of the codebase than there's a bug where submitting a comment double posts it, and you have to dig into that. Both of those require you to understand the application on very different levels and kind of understand different mental models of what the app is doing. +STEPHANIE: Yeah, absolutely. That's a really good point that it can depend on what you are first asked to work on. And, in fact, I actually think that is a good guidepost for where you should be looking because you could develop a mental model that is just completely unrelated [chuckles] to what you're asked to do. And so, I suppose that is, you know, usually a good place to start, at least is like, okay, I have this first task, and there's some understanding and acceptance that, like, the more you work on this codebase, the more you'll explore and discover other parts of it, and that can be on a need to know kind of basis. +JOËL: So, I'm thinking that if you are doing something like a Ruby upgrade or even a Rails upgrade, a lot of what you care about the app is going to be on a more mechanical level. So, you want to know what gems you're using. You want to know what different patterns are being used, maybe how callbacks are happening, any particular features that are version-specific that are being used, things like that. +Whereas if you're, you know, say, fixing a bug, you might care a lot more about some of the product-level concerns. What are we actually trying to do here? What is the expected user experience? How does this deviate from that? What were the underlying mental models of the developers? So, there's almost, like, two lenses you can look at the code. Now, I almost want to make this a two-dimensional thing, where you can look at it either from, like, a very kind of mechanical lens or a product lens in one axis. +And then, on the other axis, you could look at it from a very high-level 10,000-foot view and maybe zoom in a little bit where you need, versus a very localized view; here's where the bug is happening on this page, and then sort of zoom out as necessary. And I could see different sorts of tasks falling in different quadrants there of, do I need a more mechanical view? Do I need a more product-focused view? And do I need to be looking locally versus globally? +STEPHANIE: Wow. I can't believe you just created a Cartesian graph [laughs] for this problem on the fly. But I love it because I do think that actually lines up with different strategies I've taken before. It's like, how much do you even look at the code before deciding that you can't really get a good picture of it, of what the product is, without just poking around from the app itself? +I actually think that I tend to start from the code. Like, maybe I'll see a screenshot that someone has shared of the app, you know, like a bug or something that they want me to fix, and then looking for that text in the code first, and then trying to kind of follow that path, whereas it's also, you know, perfectly viable to try to see the app being used in production, or staging, or something first to get a better understanding of some of the business problems it's trying to solve. +JOËL: When you jump into a new codebase, do you sort of consciously take the time to plan your approach or sort of think about, like, how much knowledge of this new codebase do I need before I can, like, actually look at the problem at hand? +STEPHANIE: Ooh, that's kind of a hard question to answer because I think my experience has told me enough times that it's never what I think it's going to [laughs] be, not never, but it frequently surprises me. It has surprised me enough times that it's kind of hard to know off the bat because it's not...as much as we work in frameworks that have opinions and conventions, a lot of the work that happens is understanding how this particular codebase and team does things and then having to maybe shift or adjust from there. +So, I think I don't do a lot of planning. I don't really have an idea about how much time it'll take me because I can't really know until I dive in a little bit. So, that is usually my first instinct, even if someone is wanting to, like, talk to me about an approach or be, like, "Hey, like, how long do you think this might take based on your experience as a consultant?" This is my first task. Oftentimes, I really can't say until I've had a little bit of downtime to, in some ways, like, acquire the knowledge [chuckles] to figure that out or answer that question. +JOËL: How much knowledge do you like to get upfront about an app before you dive into actually doing the task at hand? Are there any things, like, when you get access to a new codebase, that you'll always want to look at to get a sense of the project before you look at any tickets? +STEPHANIE: I actually start at the model level. Usually, I am curious about what kinds of objects we're working with. In fact, I think that is really helpful for me. They're like building blocks, in order for me to, like, conceptually understand this world that's being represented by a codebase. And I kind of either go outwards or inwards from there. Usually, if there's a model that is, like, calling to me as like, oh, I'll probably need to interact with, then I'll go and seek out, like, where that model is created, maybe through controllers, maybe through background jobs, or something like that, and start to piece together entry points into the application. +I find that helpful because a lot of the times, it can be hard to know whether certain pages or routes are even used at all anymore. They could just be dead code and could be a bit misleading. I've certainly been misled [chuckles] more than once. And so, I think if I'm able to pull out the main domain objects that I notice in a ticket or just hear people talk about on the team, that's usually where I gravitate towards first. What about you? Do you have a place you like to start when it comes to exploring a new codebase like that? +JOËL: The routes file is always a good sort of overview of, like, what is going on in the app. Scanning the models directory is also a great start in a Rails app to get a sense of what is this app about? What are the core nouns in our vocabulary? Another thing that's good to look for in a codebase is what are the big types of patterns that they tend to use? +The Rails ecosystem goes through fads, and, over time, different patterns will be more popular than others. And so, it's often useful to see, oh, is this an app where everything happens in service objects, or is this an app that likes to rely on view components to render their views? Things like that. Once you get a sense of that, you get a little bit of a better sense of how things are architected beyond just the basic MVC. +STEPHANIE: I like that you mentioned fads because I think I can definitely tell, you know, how modern an app is or kind of where it might be stuck in time [chuckles] a little bit based on those patterns and libraries that it's heavily utilizing, which I actually find to be an interesting and kind of challenging position to be in because how do you approach making changes to a codebase that is using a lot of patterns or styles from back in the day? Would you continue following those same patterns, or do you feel motivated to introduce something new or kind of what might be trendy now? +JOËL: This is the boring answer, but it's almost never worth it to, like, rewrite the codebase just to use a new pattern. Just introducing the new pattern in some of the new things means there are now two patterns. That's also not a great outcome for the team. So, without some other compelling reason, I default to using the established patterns. +STEPHANIE: Even if it's something you don't like? +JOËL: Yes. I'm not a huge fan of service objects, but I work in plenty of codebases that have them, and so where it makes sense, I will use service objects there. Service objects are not mutually exclusive with other things, and so sometimes it might make sense to say, look, I don't feel like I can justify a service object here. I'll do this logic in a view, or maybe I'll pull this out into some other object that's not a service object and that can live alongside nicely. But I'm not necessarily introducing a new pattern. I'm just deciding that this particular extraction might not necessarily need a service object. +STEPHANIE: That's an interesting way to describe it, not as a pattern, but as kind of, like, choosing not to use the existing [chuckles] pattern. But that doesn't mean, like, totally shifting the architecture or even how you're asking other people to understand the codebase. And I think I'm in agreement. I'm actually a bit of a follower, too, [laughs], where I want to, I don't know, just make things match a little bit with what's already been created, follow that style. That becomes pretty important to me when integrating with a team in a codebase. +But I actually think that, you know, when you are calibrating to a codebase, you're in a position where you don't have all that baggage and history about how things need to be. And maybe you might be empowered to have a little bit more freedom to question existing patterns or bring some new ideas to the team to, hopefully, like, help the code evolve. I think that's something that I struggle with sometimes is feeling compelled to follow what came before me and also wanting to introduce some new things just to see what the team might think about them. +JOËL: A lot of that can vary depending on what is the pattern you want to introduce and sort of what your role is going to be on that team. But that is something that's nice about someone new coming onto a project. They haven't just sort of accepted that things are the way they are, especially for things that the team already doesn't like but doesn't feel like they have the energy to do anything better about it. +So, maybe you're in a codebase where there's a ton of Ruby code in your ERB templates, and it's not really a pattern that you're following. It's just a thing that's there. It's been sort of the path of least resistance for a long time, and it's easier to add more lines in there, but nobody likes it. New person joins the team, and their naive exuberance is just like, "We can fix it. We can make it better." +And maybe that's, you know, going back and rewriting all of your views. That's probably not the best use of their time. But it could be maybe the first time they have to touch one of these views, cleaning up that one and starting a conversation among the team. "Hey, here are some patterns that we might like to clean up some of these views instead," or "Here are maybe some guidelines for anything new that we write that we want to do to keep our views clean," and sort of start moving the needle in a positive direction. +STEPHANIE: I like the idea of moving the needle. Even though I tend to not want to stir the pot with any big changes, one thing that I do find myself doing is in a couple of places in the specs, just trying to refactor a bit away from using lets. There were some kind of forward-thinking decisions made before when RSpec was basically going to deprecate using the describe block without prepending it with their module, so just kind of throwing that in there whenever I would touch a spec and asking other people to do the same. +And then, recently, one kind of, like, small syntax thing that I hadn't seen before, and maybe this is just because of the age of the codebases in which I'm working, the argument forwarding syntax in Ruby that has been new, I mean, it's like not totally new anymore [laughs], but throwing that in there a little every now and then to just kind of shift away from this, you know, dated version of the code kind of towards things that other people are seeing and in newer projects. +JOËL: I love harnessing that energy of being new on a project and wanting to make things better. How do you avoid just being, you know, that developer, though, that's new, comes in, and just wants to change everything for the sake of change or for your own personal opinions and just kind of moves things around, stirs the pot, but doesn't really contribute anything net positive to the team? Because I've definitely seen that as well, and that's not a good first contribution or, you know, contribution in general as a newer team member. How do we avoid being that person while still capitalizing on that energy of being someone new and wanting to make a positive impact? +STEPHANIE: Yeah, that's a great point, and I kind of alluded to this earlier when I asked, like, oh, like, even if you don't like an existing syntax or pattern you'll still follow it? And I think liking something a different way is not a good enough reason [chuckles]. But if you are able to have a good reason, like I mentioned with the RSpec prepending, you know, it didn't need to happen now, but if we would hope to upgrade that gem eventually, then yeah, that was a good reason to make that change as opposed to just purely aesthetic [laughs]. +JOËL: That's one where there is pretty much a single right answer to. If you plan to keep staying up to date with versions of RSpec, you will eventually need to do all these code changes because, you know, they're deprecating the old way. Getting ahead of that gradually as we touch spec files, there's kind of no downside to it. +STEPHANIE: That's true, though maybe there is a person who exists out there who's like, "I love this old version of RSpec, and I will die on this hill that we have to stay on [laughs] it." +But I also think that I have preferences, but I'm not so attached to them. Ideally, you know, what I would love to receive is just, like, curiosity about like, "Oh, like, why did you make this change?" And just kind of share my reasoning. And sometimes in that process, I realize, you know, I don't have a great reason, and I'll just say, "I don't have a great reason. This is just the way I like it. But if it doesn't work for you, like, tell me, and I'll consider changing it back. [chuckles]" +JOËL: Maybe that's where there's a lot of benefit is the sort of curiosity on the part of the existing team and sort of openness to both learn about existing practices but also share about different practices from the new teammate. And maybe that's you're coming in, and you have a different style where you like to write tests, maybe without using RSpec's let syntax; the team is using it. Maybe you can have a conversation with the team. It's almost certainly not worth it for you to go and rewrite the entire test suite to not use let and be like, "Hey, first PR. I made your test better." +STEPHANIE: Hundreds of files changed, thousands [laughs] of lines of code. I think that's actually a good segue into the question of how can a team support a new hire or a new developer who is still calibrating to a codebase? I think I'm curious about this being different from onboarding because, you know, there are a lot of things that we already kind of expect to give some extra time and leeway for someone who's new coming in. But what might be some ways to support a new developer that are less well known? +JOËL: One that I really like is getting them involved as early as possible in code review because then they get to see the patterns that are coming in, and they can be involved in conversations on those. The first PR you're reviewing, and you see a bunch of tests leaning heavily on let, and maybe you ask a question, "Is this a pattern that we're following in this codebase? Did we have a particular motivation for why we chose this?" +And, you know, and you don't want to do it in a sort of, like, passive-aggressive way because you're trying to push something else. It has to come from a place of genuine curiosity, but you're allowing the new teammate to both see a lot of the existing patterns kind of in very quick succession because you see a pretty good cross-section of those when you review code. +And also, to have conversations about them, to ask anything like, "Oh, that's unusual. I didn't know we were doing that." Or, "Hey, is this a pattern that we're doing kind of just local to this subsystem, or is this something that's happening all the way? Is this a pattern that we're using and liking? Is this a thing that we were doing five years ago that we're phasing out, but there's still a few of them left?" Those are all, I think, great questions to ask when you're getting started. +STEPHANIE: That makes a lot of sense. It's different from saying, "This is how we do things here," and expecting them to adapt or, you know, change to fit into that style or culture, and being open to letting it evolve based on the new team, the new people on the team and what they might be bringing to the table. +I like to ask the question, "What do you need to know?" Or "What do you need to be successful?" as opposed to telling them what I think they need [laughs]. I think that is something that I actually kind of recently, not regret exactly, but I was kind of helping out some folks who were going to be joining the team and just trying to, like, shove all this information down their throats and be like, "Oh, and watch out for these gotchas. And this app uses a lot of callbacks, and they're really complex." +And I think I was maybe coloring their [chuckles] experience a little bit and expecting them to be able to drink from the fire hose, as opposed to trusting that they can see for themselves, you know, like, what is going on, and form opinions about it, and ask questions that will support them in whatever they are looking to do. When we talked earlier about the four different quadrants, like, the kind of information they need to know will differ based off of their task, based off of their experience. So, that's one way that I am thinking about to, like, make space for a new developer to help shape that culture, rather than insisting that things are the way they are. +JOËL: It can be a fine balance where you want to be open to change while also you have to remain kind of ruthlessly pragmatic about the fact that change can be expensive. And so, a lot of changes you need to be justified, and you don't want to just be rewriting your patterns for every new employee or, you know, just to follow the latest trends because we've seen a lot of trends come and go in the Rails ecosystem, and getting on all of them is just not worth our time. +STEPHANIE: And that's the hard truth of there's always trade-offs [laughs] in software development, isn't that right? +JOËL: It sure is. You can't always chase the newest shiny, as fun as that is. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Stephanie has a delightful and cute Ruby thing to share: Honeybadger, the error monitoring service, has created exceptionalcreatures.com, where they've illustrated and characterized various common Ruby errors into little monsters, and they're adorable. Meanwhile, Joël encourages folks to submit proposals for RailsConf.

+ +

Together, Stephanie and Joël delve into the nuances of adapting to and working within new codebases, akin to aligning with a shared mental model or vision. They ponder several vital questions that every developer faces when encountering a new project: the balance between exploring a codebase to understand its structure and diving straight into tasks, the decision-making process behind adopting new patterns versus adhering to established ones, and the strategies teams can employ to assist developers who are familiarizing themselves with a new environment.

+ +

Honeybadger's Exceptional Creatures
+RailsConf CFP coaching sessions
+HTTP Cats
+Support and Maintenance Episode

+ +

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: I have a delightful and cute Ruby thing to share I'd seen just in our internal company Slack. Honeybadger, the error monitoring service, has created a cute little webpage called exceptionalcreatures.com, where they've basically illustrated and characterized various common Ruby errors into little monsters [laughs], and I find them adorable. I think their goal is also to make it a really helpful resource for people encountering these kinds of errors, learning about them for the first time, and figuring how to triage or debug them.

+ +

And I just think it's a really cool way of, like, making it super approachable, debugging and, you know, when you first encounter a scary error message, can be really overwhelming, and then Googling about it can also be equally [chuckles] overwhelming. So, I just really liked the whimsy that they kind of injected into something that could be really hard to learn about. Like, there are so many different error messages in Ruby and in Rails and whatever other libraries you're using. And so, that's kind of a...I think they've created a one-stop shop for, you know, figuring out how to move forward with common errors.

+ +

And I also like that it's a bit of a collective effort. They're calling it, like, a bestiary for all the little creatures [laughs] that they've discovered. And I think you can, like, submit your own favorite Ruby error and any guidance you might have for someone trying to debug it.

+ +

JOËL: That's adorable. It reminds me a little bit of HTTP status codes as cat memes site. It has that same energy. One thing that I think is really interesting is that because it's Honeybadger, they have stats on, like, frequency of these errors, and a lot of these ones are tied to...I think they're picking some of the most commonly surfaced errors.

+ +

STEPHANIE: Yeah, there's little, like, ratings, too, for how frequently they occur, kind of just like, I don't know, Pokémon [laughs] [inaudible 02:31]. I think it's really neat that they're using something like a learning from their business or maybe even some, like, proprietary information and sharing it with the world so that we can learn from it.

+ +

JOËL: I think one thing that's worth specifying as well is that these are specific exception classes that get raised. So, they're not just, like, random error strings that you see in the wild. They don't often have a whole lot of documentation around them, so it's nice to see a dedicated page for each and a little bit of maybe how this is used in the real world versus maybe how they were designed to be used. Maybe there's a line or two in the docs about, you know, core Ruby when a NoMethodError should be raised. How does NoMethodError actually get used, you know, in real life, and the exceptions that Honeybadger is capturing. That's really interesting to see.

+ +

STEPHANIE: Yeah, I like how each page for the exception class, and I'm glad you made that distinction, is kind of, like, crowdsourced guidance and information from the community, so I think you could even, you know, contribute to it if you wanted. But yeah, just a fun, little website to bring you some delight when you're on your next head-smacking, debugging adventure [laughs].

+ +

JOËL: And I love that it brings some joy to the topic, but, honestly, I think it's a pretty good reference. I could see myself linking to this anytime I want to have a deeper discussion on exceptions. So, maybe there's a code review, and maybe I want to suggest that we raise a different error than the one that we're doing. I could see myself in that GitHub comment being like, "Oh, instead of, you know, raising an exception here, why don't we instead raise a NoMethodError or something like that?" And then link to the bestiary page.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So, just recently, RailsConf announced their call for proposals. It's a fairly short period this year, only about three-ish weeks long. So, I've been really encouraging colleagues to submit and trying to be a resource for people who are interested in speaking at conferences. We did a Q&A session with a fellow thoughtboter, Aji Slater, who's also a former RailsConf speaker, about what makes for a good talk, what is it like to submit to a call for proposals, you know, kind of everything from the process from having an idea all the way to stage presence and delivering. And there's a lot of great questions that got asked and some good discussion that happened there.

+ +

STEPHANIE: Nice. Yeah, I think I have noticed that you are doing a lot more to help, especially first-time speakers give their first conference talk this year. And I'm wondering if there's anything you've learned or any hopes and dreams you have for kind of the amount of time you're investing into supporting others.

+ +

JOËL: What I'd like to see is a lot of people submitting proposals; that's always a great thing. And, a proposal, even if it doesn't get accepted, is a thing that you can resubmit. And so, having gone through the effort of building a proposal and especially getting it maybe peer-reviewed by some colleagues to polish your idea, I think is already just a really great exercise, and it's one that you can shop around. It's one that you can maybe convert into a blog post if you need to. You can convert that into some kind of podcast appearance. So, I think it's a great way to take an idea you're excited about and focus it, even if you can't get into RailsConf.

+ +

STEPHANIE: I really like that metric for success. It reminds me of a writer friend I have who actually was a guest on the show, Nicole Zhu. She submits a lot of short stories to magazines and applications to writing fellowships, and she celebrates every rejection. I think at the end of the year, she, like, celebrates herself for having received, you know, like, 15 rejections or something that year because that meant that she just went for it and, you know, did the hard part of doing the work, putting yourself out there. And that is just as important, you know, if not more than whatever achievement or goal or the idea of having something accepted.

+ +

JOËL: Yeah, I have to admit; rejection hurts. It's not a fun thing to go through. But I think even if you sort of make it to that final stage of having written a proposal and it gets rejected, you get a lot of value out of that journey sort of regardless of whether you get accepted or not. So, I encourage more people to do that.

+ +

To any of our listeners who are interested, the RailsConf call for proposals goes through February 13th, 2024. So, if you are listening before then and are inspired, I recommend submitting. If you're unsure of what makes for a good CFP, RailsConf is currently offering coaching sessions to help craft better proposals. They have one on February 5th, one on February 6th, and one on February 7th, so those are also options to look into if this is maybe your first time and you're not sure. There's a signup form. We'll link to it in the show notes.

+ +

STEPHANIE: So, another update I have that I'm excited to get into for the rest of the episode is my recent work on our support and maintenance team, which I've talked about on the show before. But for any listeners who don't know, it's a kind of sub-team at thoughtbot that is focused on helping maintain multiple client projects at a time. But, at this point, you know, there's not as much active feature development, but the work is focused on keeping the codebase up to date, making any dependency upgrades, fixing any bugs that come up, and general support. So, clients have a team to kind of address those things as they come up.

+ +

And when I had last talked about it on the podcast, I was really excited because it was a bit of a different way of working. I felt like it was very novel to be, you know, have a lot of different projects and domains to be getting into. And knowing that I was working on this team, like, short-term and, you know, it may not be me in the future continuing what I might have started during my rotation, I thought it was really interesting to be optimizing towards, like, completion of a task. And that had kind of changed my workflow a bit and my process.

+ +

JOËL: So, now that you've been doing work on the support and maintenance team for a while and you've kind of maybe gotten more comfortable with it, how are you generally feeling about this idea of sort of jumping into new codebases all the time?

+ +

STEPHANIE: It is both fun and more challenging than I thought it would be. I tend to actually really enjoy that period of joining a new team or a project and exploring, you know, a codebase and getting up to speed, and that's something that we do a lot as consultants. But I think I started to realize that it's a bit of a tricky balance to figure out how much time should I be spending understanding what this codebase is doing? Like, how much of the application do I need to be understanding, and how much poking around should I be doing before just trying to get started on my first task, the first starter ticket that I'm given?

+ +

There's a bit of a balance there because, on one hand, you could just immediately start on the task and kind of just, you know, have your blinders [chuckles] on and not really care too much about what the rest of the code is doing outside of the change that you're trying to make. But that also means that you don't have that context of why certain things are the way they are. Maybe, like, the way that you want to be building something actually won't work because of some unexpected complexity with the app.

+ +

So, I think there, you know, needs to be time spent digging around a little bit, but then you could also be digging around for a long time [chuckles] before you feel like, okay, I finally have enough understanding of this new codebase to, like, build a feature exactly how a seasoned developer on the team might.

+ +

JOËL: I imagine that probably varies a little bit based on the task that you're doing. So, something like, oh, we want to upgrade this codebase to Ruby 3.3, probably requires you to have a very different understanding of the codebase than there's a bug where submitting a comment double posts it, and you have to dig into that. Both of those require you to understand the application on very different levels and kind of understand different mental models of what the app is doing.

+ +

STEPHANIE: Yeah, absolutely. That's a really good point that it can depend on what you are first asked to work on. And, in fact, I actually think that is a good guidepost for where you should be looking because you could develop a mental model that is just completely unrelated [chuckles] to what you're asked to do. And so, I suppose that is, you know, usually a good place to start, at least is like, okay, I have this first task, and there's some understanding and acceptance that, like, the more you work on this codebase, the more you'll explore and discover other parts of it, and that can be on a need to know kind of basis.

+ +

JOËL: So, I'm thinking that if you are doing something like a Ruby upgrade or even a Rails upgrade, a lot of what you care about the app is going to be on a more mechanical level. So, you want to know what gems you're using. You want to know what different patterns are being used, maybe how callbacks are happening, any particular features that are version-specific that are being used, things like that.

+ +

Whereas if you're, you know, say, fixing a bug, you might care a lot more about some of the product-level concerns. What are we actually trying to do here? What is the expected user experience? How does this deviate from that? What were the underlying mental models of the developers? So, there's almost, like, two lenses you can look at the code. Now, I almost want to make this a two-dimensional thing, where you can look at it either from, like, a very kind of mechanical lens or a product lens in one axis.

+ +

And then, on the other axis, you could look at it from a very high-level 10,000-foot view and maybe zoom in a little bit where you need, versus a very localized view; here's where the bug is happening on this page, and then sort of zoom out as necessary. And I could see different sorts of tasks falling in different quadrants there of, do I need a more mechanical view? Do I need a more product-focused view? And do I need to be looking locally versus globally?

+ +

STEPHANIE: Wow. I can't believe you just created a Cartesian graph [laughs] for this problem on the fly. But I love it because I do think that actually lines up with different strategies I've taken before. It's like, how much do you even look at the code before deciding that you can't really get a good picture of it, of what the product is, without just poking around from the app itself?

+ +

I actually think that I tend to start from the code. Like, maybe I'll see a screenshot that someone has shared of the app, you know, like a bug or something that they want me to fix, and then looking for that text in the code first, and then trying to kind of follow that path, whereas it's also, you know, perfectly viable to try to see the app being used in production, or staging, or something first to get a better understanding of some of the business problems it's trying to solve.

+ +

JOËL: When you jump into a new codebase, do you sort of consciously take the time to plan your approach or sort of think about, like, how much knowledge of this new codebase do I need before I can, like, actually look at the problem at hand?

+ +

STEPHANIE: Ooh, that's kind of a hard question to answer because I think my experience has told me enough times that it's never what I think it's going to [laughs] be, not never, but it frequently surprises me. It has surprised me enough times that it's kind of hard to know off the bat because it's not...as much as we work in frameworks that have opinions and conventions, a lot of the work that happens is understanding how this particular codebase and team does things and then having to maybe shift or adjust from there.

+ +

So, I think I don't do a lot of planning. I don't really have an idea about how much time it'll take me because I can't really know until I dive in a little bit. So, that is usually my first instinct, even if someone is wanting to, like, talk to me about an approach or be, like, "Hey, like, how long do you think this might take based on your experience as a consultant?" This is my first task. Oftentimes, I really can't say until I've had a little bit of downtime to, in some ways, like, acquire the knowledge [chuckles] to figure that out or answer that question.

+ +

JOËL: How much knowledge do you like to get upfront about an app before you dive into actually doing the task at hand? Are there any things, like, when you get access to a new codebase, that you'll always want to look at to get a sense of the project before you look at any tickets?

+ +

STEPHANIE: I actually start at the model level. Usually, I am curious about what kinds of objects we're working with. In fact, I think that is really helpful for me. They're like building blocks, in order for me to, like, conceptually understand this world that's being represented by a codebase. And I kind of either go outwards or inwards from there. Usually, if there's a model that is, like, calling to me as like, oh, I'll probably need to interact with, then I'll go and seek out, like, where that model is created, maybe through controllers, maybe through background jobs, or something like that, and start to piece together entry points into the application.

+ +

I find that helpful because a lot of the times, it can be hard to know whether certain pages or routes are even used at all anymore. They could just be dead code and could be a bit misleading. I've certainly been misled [chuckles] more than once. And so, I think if I'm able to pull out the main domain objects that I notice in a ticket or just hear people talk about on the team, that's usually where I gravitate towards first. What about you? Do you have a place you like to start when it comes to exploring a new codebase like that?

+ +

JOËL: The routes file is always a good sort of overview of, like, what is going on in the app. Scanning the models directory is also a great start in a Rails app to get a sense of what is this app about? What are the core nouns in our vocabulary? Another thing that's good to look for in a codebase is what are the big types of patterns that they tend to use?

+ +

The Rails ecosystem goes through fads, and, over time, different patterns will be more popular than others. And so, it's often useful to see, oh, is this an app where everything happens in service objects, or is this an app that likes to rely on view components to render their views? Things like that. Once you get a sense of that, you get a little bit of a better sense of how things are architected beyond just the basic MVC.

+ +

STEPHANIE: I like that you mentioned fads because I think I can definitely tell, you know, how modern an app is or kind of where it might be stuck in time [chuckles] a little bit based on those patterns and libraries that it's heavily utilizing, which I actually find to be an interesting and kind of challenging position to be in because how do you approach making changes to a codebase that is using a lot of patterns or styles from back in the day? Would you continue following those same patterns, or do you feel motivated to introduce something new or kind of what might be trendy now?

+ +

JOËL: This is the boring answer, but it's almost never worth it to, like, rewrite the codebase just to use a new pattern. Just introducing the new pattern in some of the new things means there are now two patterns. That's also not a great outcome for the team. So, without some other compelling reason, I default to using the established patterns.

+ +

STEPHANIE: Even if it's something you don't like?

+ +

JOËL: Yes. I'm not a huge fan of service objects, but I work in plenty of codebases that have them, and so where it makes sense, I will use service objects there. Service objects are not mutually exclusive with other things, and so sometimes it might make sense to say, look, I don't feel like I can justify a service object here. I'll do this logic in a view, or maybe I'll pull this out into some other object that's not a service object and that can live alongside nicely. But I'm not necessarily introducing a new pattern. I'm just deciding that this particular extraction might not necessarily need a service object.

+ +

STEPHANIE: That's an interesting way to describe it, not as a pattern, but as kind of, like, choosing not to use the existing [chuckles] pattern. But that doesn't mean, like, totally shifting the architecture or even how you're asking other people to understand the codebase. And I think I'm in agreement. I'm actually a bit of a follower, too, [laughs], where I want to, I don't know, just make things match a little bit with what's already been created, follow that style. That becomes pretty important to me when integrating with a team in a codebase.

+ +

But I actually think that, you know, when you are calibrating to a codebase, you're in a position where you don't have all that baggage and history about how things need to be. And maybe you might be empowered to have a little bit more freedom to question existing patterns or bring some new ideas to the team to, hopefully, like, help the code evolve. I think that's something that I struggle with sometimes is feeling compelled to follow what came before me and also wanting to introduce some new things just to see what the team might think about them.

+ +

JOËL: A lot of that can vary depending on what is the pattern you want to introduce and sort of what your role is going to be on that team. But that is something that's nice about someone new coming onto a project. They haven't just sort of accepted that things are the way they are, especially for things that the team already doesn't like but doesn't feel like they have the energy to do anything better about it.

+ +

So, maybe you're in a codebase where there's a ton of Ruby code in your ERB templates, and it's not really a pattern that you're following. It's just a thing that's there. It's been sort of the path of least resistance for a long time, and it's easier to add more lines in there, but nobody likes it. New person joins the team, and their naive exuberance is just like, "We can fix it. We can make it better."

+ +

And maybe that's, you know, going back and rewriting all of your views. That's probably not the best use of their time. But it could be maybe the first time they have to touch one of these views, cleaning up that one and starting a conversation among the team. "Hey, here are some patterns that we might like to clean up some of these views instead," or "Here are maybe some guidelines for anything new that we write that we want to do to keep our views clean," and sort of start moving the needle in a positive direction.

+ +

STEPHANIE: I like the idea of moving the needle. Even though I tend to not want to stir the pot with any big changes, one thing that I do find myself doing is in a couple of places in the specs, just trying to refactor a bit away from using lets. There were some kind of forward-thinking decisions made before when RSpec was basically going to deprecate using the describe block without prepending it with their module, so just kind of throwing that in there whenever I would touch a spec and asking other people to do the same.

+ +

And then, recently, one kind of, like, small syntax thing that I hadn't seen before, and maybe this is just because of the age of the codebases in which I'm working, the argument forwarding syntax in Ruby that has been new, I mean, it's like not totally new anymore [laughs], but throwing that in there a little every now and then to just kind of shift away from this, you know, dated version of the code kind of towards things that other people are seeing and in newer projects.

+ +

JOËL: I love harnessing that energy of being new on a project and wanting to make things better. How do you avoid just being, you know, that developer, though, that's new, comes in, and just wants to change everything for the sake of change or for your own personal opinions and just kind of moves things around, stirs the pot, but doesn't really contribute anything net positive to the team? Because I've definitely seen that as well, and that's not a good first contribution or, you know, contribution in general as a newer team member. How do we avoid being that person while still capitalizing on that energy of being someone new and wanting to make a positive impact?

+ +

STEPHANIE: Yeah, that's a great point, and I kind of alluded to this earlier when I asked, like, oh, like, even if you don't like an existing syntax or pattern you'll still follow it? And I think liking something a different way is not a good enough reason [chuckles]. But if you are able to have a good reason, like I mentioned with the RSpec prepending, you know, it didn't need to happen now, but if we would hope to upgrade that gem eventually, then yeah, that was a good reason to make that change as opposed to just purely aesthetic [laughs].

+ +

JOËL: That's one where there is pretty much a single right answer to. If you plan to keep staying up to date with versions of RSpec, you will eventually need to do all these code changes because, you know, they're deprecating the old way. Getting ahead of that gradually as we touch spec files, there's kind of no downside to it.

+ +

STEPHANIE: That's true, though maybe there is a person who exists out there who's like, "I love this old version of RSpec, and I will die on this hill that we have to stay on [laughs] it."

+ +

But I also think that I have preferences, but I'm not so attached to them. Ideally, you know, what I would love to receive is just, like, curiosity about like, "Oh, like, why did you make this change?" And just kind of share my reasoning. And sometimes in that process, I realize, you know, I don't have a great reason, and I'll just say, "I don't have a great reason. This is just the way I like it. But if it doesn't work for you, like, tell me, and I'll consider changing it back. [chuckles]"

+ +

JOËL: Maybe that's where there's a lot of benefit is the sort of curiosity on the part of the existing team and sort of openness to both learn about existing practices but also share about different practices from the new teammate. And maybe that's you're coming in, and you have a different style where you like to write tests, maybe without using RSpec's let syntax; the team is using it. Maybe you can have a conversation with the team. It's almost certainly not worth it for you to go and rewrite the entire test suite to not use let and be like, "Hey, first PR. I made your test better."

+ +

STEPHANIE: Hundreds of files changed, thousands [laughs] of lines of code. I think that's actually a good segue into the question of how can a team support a new hire or a new developer who is still calibrating to a codebase? I think I'm curious about this being different from onboarding because, you know, there are a lot of things that we already kind of expect to give some extra time and leeway for someone who's new coming in. But what might be some ways to support a new developer that are less well known?

+ +

JOËL: One that I really like is getting them involved as early as possible in code review because then they get to see the patterns that are coming in, and they can be involved in conversations on those. The first PR you're reviewing, and you see a bunch of tests leaning heavily on let, and maybe you ask a question, "Is this a pattern that we're following in this codebase? Did we have a particular motivation for why we chose this?"

+ +

And, you know, and you don't want to do it in a sort of, like, passive-aggressive way because you're trying to push something else. It has to come from a place of genuine curiosity, but you're allowing the new teammate to both see a lot of the existing patterns kind of in very quick succession because you see a pretty good cross-section of those when you review code.

+ +

And also, to have conversations about them, to ask anything like, "Oh, that's unusual. I didn't know we were doing that." Or, "Hey, is this a pattern that we're doing kind of just local to this subsystem, or is this something that's happening all the way? Is this a pattern that we're using and liking? Is this a thing that we were doing five years ago that we're phasing out, but there's still a few of them left?" Those are all, I think, great questions to ask when you're getting started.

+ +

STEPHANIE: That makes a lot of sense. It's different from saying, "This is how we do things here," and expecting them to adapt or, you know, change to fit into that style or culture, and being open to letting it evolve based on the new team, the new people on the team and what they might be bringing to the table.

+ +

I like to ask the question, "What do you need to know?" Or "What do you need to be successful?" as opposed to telling them what I think they need [laughs]. I think that is something that I actually kind of recently, not regret exactly, but I was kind of helping out some folks who were going to be joining the team and just trying to, like, shove all this information down their throats and be like, "Oh, and watch out for these gotchas. And this app uses a lot of callbacks, and they're really complex."

+ +

And I think I was maybe coloring their [chuckles] experience a little bit and expecting them to be able to drink from the fire hose, as opposed to trusting that they can see for themselves, you know, like, what is going on, and form opinions about it, and ask questions that will support them in whatever they are looking to do. When we talked earlier about the four different quadrants, like, the kind of information they need to know will differ based off of their task, based off of their experience. So, that's one way that I am thinking about to, like, make space for a new developer to help shape that culture, rather than insisting that things are the way they are.

+ +

JOËL: It can be a fine balance where you want to be open to change while also you have to remain kind of ruthlessly pragmatic about the fact that change can be expensive. And so, a lot of changes you need to be justified, and you don't want to just be rewriting your patterns for every new employee or, you know, just to follow the latest trends because we've seen a lot of trends come and go in the Rails ecosystem, and getting on all of them is just not worth our time.

+ +

STEPHANIE: And that's the hard truth of there's always trade-offs [laughs] in software development, isn't that right?

+ +

JOËL: It sure is. You can't always chase the newest shiny, as fun as that is.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie has a delightful and cute Ruby thing to share: Honeybadger, the error monitoring service, has created exceptionalcreatures.com, where they've illustrated and characterized various common Ruby errors into little monsters, and they're adorable. Meanwhile, Joël encourages folks to submit proposals for RailsConf.

+ +

Together, Stephanie and Joël delve into the nuances of adapting to and working within new codebases, akin to aligning with a shared mental model or vision. They ponder several vital questions that every developer faces when encountering a new project: the balance between exploring a codebase to understand its structure and diving straight into tasks, the decision-making process behind adopting new patterns versus adhering to established ones, and the strategies teams can employ to assist developers who are familiarizing themselves with a new environment.

+ +

Honeybadger's Exceptional Creatures
+RailsConf CFP coaching sessions
+HTTP Cats
+Support and Maintenance Episode

+ +

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: I have a delightful and cute Ruby thing to share I'd seen just in our internal company Slack. Honeybadger, the error monitoring service, has created a cute little webpage called exceptionalcreatures.com, where they've basically illustrated and characterized various common Ruby errors into little monsters [laughs], and I find them adorable. I think their goal is also to make it a really helpful resource for people encountering these kinds of errors, learning about them for the first time, and figuring how to triage or debug them.

+ +

And I just think it's a really cool way of, like, making it super approachable, debugging and, you know, when you first encounter a scary error message, can be really overwhelming, and then Googling about it can also be equally [chuckles] overwhelming. So, I just really liked the whimsy that they kind of injected into something that could be really hard to learn about. Like, there are so many different error messages in Ruby and in Rails and whatever other libraries you're using. And so, that's kind of a...I think they've created a one-stop shop for, you know, figuring out how to move forward with common errors.

+ +

And I also like that it's a bit of a collective effort. They're calling it, like, a bestiary for all the little creatures [laughs] that they've discovered. And I think you can, like, submit your own favorite Ruby error and any guidance you might have for someone trying to debug it.

+ +

JOËL: That's adorable. It reminds me a little bit of HTTP status codes as cat memes site. It has that same energy. One thing that I think is really interesting is that because it's Honeybadger, they have stats on, like, frequency of these errors, and a lot of these ones are tied to...I think they're picking some of the most commonly surfaced errors.

+ +

STEPHANIE: Yeah, there's little, like, ratings, too, for how frequently they occur, kind of just like, I don't know, Pokémon [laughs] [inaudible 02:31]. I think it's really neat that they're using something like a learning from their business or maybe even some, like, proprietary information and sharing it with the world so that we can learn from it.

+ +

JOËL: I think one thing that's worth specifying as well is that these are specific exception classes that get raised. So, they're not just, like, random error strings that you see in the wild. They don't often have a whole lot of documentation around them, so it's nice to see a dedicated page for each and a little bit of maybe how this is used in the real world versus maybe how they were designed to be used. Maybe there's a line or two in the docs about, you know, core Ruby when a NoMethodError should be raised. How does NoMethodError actually get used, you know, in real life, and the exceptions that Honeybadger is capturing. That's really interesting to see.

+ +

STEPHANIE: Yeah, I like how each page for the exception class, and I'm glad you made that distinction, is kind of, like, crowdsourced guidance and information from the community, so I think you could even, you know, contribute to it if you wanted. But yeah, just a fun, little website to bring you some delight when you're on your next head-smacking, debugging adventure [laughs].

+ +

JOËL: And I love that it brings some joy to the topic, but, honestly, I think it's a pretty good reference. I could see myself linking to this anytime I want to have a deeper discussion on exceptions. So, maybe there's a code review, and maybe I want to suggest that we raise a different error than the one that we're doing. I could see myself in that GitHub comment being like, "Oh, instead of, you know, raising an exception here, why don't we instead raise a NoMethodError or something like that?" And then link to the bestiary page.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So, just recently, RailsConf announced their call for proposals. It's a fairly short period this year, only about three-ish weeks long. So, I've been really encouraging colleagues to submit and trying to be a resource for people who are interested in speaking at conferences. We did a Q&A session with a fellow thoughtboter, Aji Slater, who's also a former RailsConf speaker, about what makes for a good talk, what is it like to submit to a call for proposals, you know, kind of everything from the process from having an idea all the way to stage presence and delivering. And there's a lot of great questions that got asked and some good discussion that happened there.

+ +

STEPHANIE: Nice. Yeah, I think I have noticed that you are doing a lot more to help, especially first-time speakers give their first conference talk this year. And I'm wondering if there's anything you've learned or any hopes and dreams you have for kind of the amount of time you're investing into supporting others.

+ +

JOËL: What I'd like to see is a lot of people submitting proposals; that's always a great thing. And, a proposal, even if it doesn't get accepted, is a thing that you can resubmit. And so, having gone through the effort of building a proposal and especially getting it maybe peer-reviewed by some colleagues to polish your idea, I think is already just a really great exercise, and it's one that you can shop around. It's one that you can maybe convert into a blog post if you need to. You can convert that into some kind of podcast appearance. So, I think it's a great way to take an idea you're excited about and focus it, even if you can't get into RailsConf.

+ +

STEPHANIE: I really like that metric for success. It reminds me of a writer friend I have who actually was a guest on the show, Nicole Zhu. She submits a lot of short stories to magazines and applications to writing fellowships, and she celebrates every rejection. I think at the end of the year, she, like, celebrates herself for having received, you know, like, 15 rejections or something that year because that meant that she just went for it and, you know, did the hard part of doing the work, putting yourself out there. And that is just as important, you know, if not more than whatever achievement or goal or the idea of having something accepted.

+ +

JOËL: Yeah, I have to admit; rejection hurts. It's not a fun thing to go through. But I think even if you sort of make it to that final stage of having written a proposal and it gets rejected, you get a lot of value out of that journey sort of regardless of whether you get accepted or not. So, I encourage more people to do that.

+ +

To any of our listeners who are interested, the RailsConf call for proposals goes through February 13th, 2024. So, if you are listening before then and are inspired, I recommend submitting. If you're unsure of what makes for a good CFP, RailsConf is currently offering coaching sessions to help craft better proposals. They have one on February 5th, one on February 6th, and one on February 7th, so those are also options to look into if this is maybe your first time and you're not sure. There's a signup form. We'll link to it in the show notes.

+ +

STEPHANIE: So, another update I have that I'm excited to get into for the rest of the episode is my recent work on our support and maintenance team, which I've talked about on the show before. But for any listeners who don't know, it's a kind of sub-team at thoughtbot that is focused on helping maintain multiple client projects at a time. But, at this point, you know, there's not as much active feature development, but the work is focused on keeping the codebase up to date, making any dependency upgrades, fixing any bugs that come up, and general support. So, clients have a team to kind of address those things as they come up.

+ +

And when I had last talked about it on the podcast, I was really excited because it was a bit of a different way of working. I felt like it was very novel to be, you know, have a lot of different projects and domains to be getting into. And knowing that I was working on this team, like, short-term and, you know, it may not be me in the future continuing what I might have started during my rotation, I thought it was really interesting to be optimizing towards, like, completion of a task. And that had kind of changed my workflow a bit and my process.

+ +

JOËL: So, now that you've been doing work on the support and maintenance team for a while and you've kind of maybe gotten more comfortable with it, how are you generally feeling about this idea of sort of jumping into new codebases all the time?

+ +

STEPHANIE: It is both fun and more challenging than I thought it would be. I tend to actually really enjoy that period of joining a new team or a project and exploring, you know, a codebase and getting up to speed, and that's something that we do a lot as consultants. But I think I started to realize that it's a bit of a tricky balance to figure out how much time should I be spending understanding what this codebase is doing? Like, how much of the application do I need to be understanding, and how much poking around should I be doing before just trying to get started on my first task, the first starter ticket that I'm given?

+ +

There's a bit of a balance there because, on one hand, you could just immediately start on the task and kind of just, you know, have your blinders [chuckles] on and not really care too much about what the rest of the code is doing outside of the change that you're trying to make. But that also means that you don't have that context of why certain things are the way they are. Maybe, like, the way that you want to be building something actually won't work because of some unexpected complexity with the app.

+ +

So, I think there, you know, needs to be time spent digging around a little bit, but then you could also be digging around for a long time [chuckles] before you feel like, okay, I finally have enough understanding of this new codebase to, like, build a feature exactly how a seasoned developer on the team might.

+ +

JOËL: I imagine that probably varies a little bit based on the task that you're doing. So, something like, oh, we want to upgrade this codebase to Ruby 3.3, probably requires you to have a very different understanding of the codebase than there's a bug where submitting a comment double posts it, and you have to dig into that. Both of those require you to understand the application on very different levels and kind of understand different mental models of what the app is doing.

+ +

STEPHANIE: Yeah, absolutely. That's a really good point that it can depend on what you are first asked to work on. And, in fact, I actually think that is a good guidepost for where you should be looking because you could develop a mental model that is just completely unrelated [chuckles] to what you're asked to do. And so, I suppose that is, you know, usually a good place to start, at least is like, okay, I have this first task, and there's some understanding and acceptance that, like, the more you work on this codebase, the more you'll explore and discover other parts of it, and that can be on a need to know kind of basis.

+ +

JOËL: So, I'm thinking that if you are doing something like a Ruby upgrade or even a Rails upgrade, a lot of what you care about the app is going to be on a more mechanical level. So, you want to know what gems you're using. You want to know what different patterns are being used, maybe how callbacks are happening, any particular features that are version-specific that are being used, things like that.

+ +

Whereas if you're, you know, say, fixing a bug, you might care a lot more about some of the product-level concerns. What are we actually trying to do here? What is the expected user experience? How does this deviate from that? What were the underlying mental models of the developers? So, there's almost, like, two lenses you can look at the code. Now, I almost want to make this a two-dimensional thing, where you can look at it either from, like, a very kind of mechanical lens or a product lens in one axis.

+ +

And then, on the other axis, you could look at it from a very high-level 10,000-foot view and maybe zoom in a little bit where you need, versus a very localized view; here's where the bug is happening on this page, and then sort of zoom out as necessary. And I could see different sorts of tasks falling in different quadrants there of, do I need a more mechanical view? Do I need a more product-focused view? And do I need to be looking locally versus globally?

+ +

STEPHANIE: Wow. I can't believe you just created a Cartesian graph [laughs] for this problem on the fly. But I love it because I do think that actually lines up with different strategies I've taken before. It's like, how much do you even look at the code before deciding that you can't really get a good picture of it, of what the product is, without just poking around from the app itself?

+ +

I actually think that I tend to start from the code. Like, maybe I'll see a screenshot that someone has shared of the app, you know, like a bug or something that they want me to fix, and then looking for that text in the code first, and then trying to kind of follow that path, whereas it's also, you know, perfectly viable to try to see the app being used in production, or staging, or something first to get a better understanding of some of the business problems it's trying to solve.

+ +

JOËL: When you jump into a new codebase, do you sort of consciously take the time to plan your approach or sort of think about, like, how much knowledge of this new codebase do I need before I can, like, actually look at the problem at hand?

+ +

STEPHANIE: Ooh, that's kind of a hard question to answer because I think my experience has told me enough times that it's never what I think it's going to [laughs] be, not never, but it frequently surprises me. It has surprised me enough times that it's kind of hard to know off the bat because it's not...as much as we work in frameworks that have opinions and conventions, a lot of the work that happens is understanding how this particular codebase and team does things and then having to maybe shift or adjust from there.

+ +

So, I think I don't do a lot of planning. I don't really have an idea about how much time it'll take me because I can't really know until I dive in a little bit. So, that is usually my first instinct, even if someone is wanting to, like, talk to me about an approach or be, like, "Hey, like, how long do you think this might take based on your experience as a consultant?" This is my first task. Oftentimes, I really can't say until I've had a little bit of downtime to, in some ways, like, acquire the knowledge [chuckles] to figure that out or answer that question.

+ +

JOËL: How much knowledge do you like to get upfront about an app before you dive into actually doing the task at hand? Are there any things, like, when you get access to a new codebase, that you'll always want to look at to get a sense of the project before you look at any tickets?

+ +

STEPHANIE: I actually start at the model level. Usually, I am curious about what kinds of objects we're working with. In fact, I think that is really helpful for me. They're like building blocks, in order for me to, like, conceptually understand this world that's being represented by a codebase. And I kind of either go outwards or inwards from there. Usually, if there's a model that is, like, calling to me as like, oh, I'll probably need to interact with, then I'll go and seek out, like, where that model is created, maybe through controllers, maybe through background jobs, or something like that, and start to piece together entry points into the application.

+ +

I find that helpful because a lot of the times, it can be hard to know whether certain pages or routes are even used at all anymore. They could just be dead code and could be a bit misleading. I've certainly been misled [chuckles] more than once. And so, I think if I'm able to pull out the main domain objects that I notice in a ticket or just hear people talk about on the team, that's usually where I gravitate towards first. What about you? Do you have a place you like to start when it comes to exploring a new codebase like that?

+ +

JOËL: The routes file is always a good sort of overview of, like, what is going on in the app. Scanning the models directory is also a great start in a Rails app to get a sense of what is this app about? What are the core nouns in our vocabulary? Another thing that's good to look for in a codebase is what are the big types of patterns that they tend to use?

+ +

The Rails ecosystem goes through fads, and, over time, different patterns will be more popular than others. And so, it's often useful to see, oh, is this an app where everything happens in service objects, or is this an app that likes to rely on view components to render their views? Things like that. Once you get a sense of that, you get a little bit of a better sense of how things are architected beyond just the basic MVC.

+ +

STEPHANIE: I like that you mentioned fads because I think I can definitely tell, you know, how modern an app is or kind of where it might be stuck in time [chuckles] a little bit based on those patterns and libraries that it's heavily utilizing, which I actually find to be an interesting and kind of challenging position to be in because how do you approach making changes to a codebase that is using a lot of patterns or styles from back in the day? Would you continue following those same patterns, or do you feel motivated to introduce something new or kind of what might be trendy now?

+ +

JOËL: This is the boring answer, but it's almost never worth it to, like, rewrite the codebase just to use a new pattern. Just introducing the new pattern in some of the new things means there are now two patterns. That's also not a great outcome for the team. So, without some other compelling reason, I default to using the established patterns.

+ +

STEPHANIE: Even if it's something you don't like?

+ +

JOËL: Yes. I'm not a huge fan of service objects, but I work in plenty of codebases that have them, and so where it makes sense, I will use service objects there. Service objects are not mutually exclusive with other things, and so sometimes it might make sense to say, look, I don't feel like I can justify a service object here. I'll do this logic in a view, or maybe I'll pull this out into some other object that's not a service object and that can live alongside nicely. But I'm not necessarily introducing a new pattern. I'm just deciding that this particular extraction might not necessarily need a service object.

+ +

STEPHANIE: That's an interesting way to describe it, not as a pattern, but as kind of, like, choosing not to use the existing [chuckles] pattern. But that doesn't mean, like, totally shifting the architecture or even how you're asking other people to understand the codebase. And I think I'm in agreement. I'm actually a bit of a follower, too, [laughs], where I want to, I don't know, just make things match a little bit with what's already been created, follow that style. That becomes pretty important to me when integrating with a team in a codebase.

+ +

But I actually think that, you know, when you are calibrating to a codebase, you're in a position where you don't have all that baggage and history about how things need to be. And maybe you might be empowered to have a little bit more freedom to question existing patterns or bring some new ideas to the team to, hopefully, like, help the code evolve. I think that's something that I struggle with sometimes is feeling compelled to follow what came before me and also wanting to introduce some new things just to see what the team might think about them.

+ +

JOËL: A lot of that can vary depending on what is the pattern you want to introduce and sort of what your role is going to be on that team. But that is something that's nice about someone new coming onto a project. They haven't just sort of accepted that things are the way they are, especially for things that the team already doesn't like but doesn't feel like they have the energy to do anything better about it.

+ +

So, maybe you're in a codebase where there's a ton of Ruby code in your ERB templates, and it's not really a pattern that you're following. It's just a thing that's there. It's been sort of the path of least resistance for a long time, and it's easier to add more lines in there, but nobody likes it. New person joins the team, and their naive exuberance is just like, "We can fix it. We can make it better."

+ +

And maybe that's, you know, going back and rewriting all of your views. That's probably not the best use of their time. But it could be maybe the first time they have to touch one of these views, cleaning up that one and starting a conversation among the team. "Hey, here are some patterns that we might like to clean up some of these views instead," or "Here are maybe some guidelines for anything new that we write that we want to do to keep our views clean," and sort of start moving the needle in a positive direction.

+ +

STEPHANIE: I like the idea of moving the needle. Even though I tend to not want to stir the pot with any big changes, one thing that I do find myself doing is in a couple of places in the specs, just trying to refactor a bit away from using lets. There were some kind of forward-thinking decisions made before when RSpec was basically going to deprecate using the describe block without prepending it with their module, so just kind of throwing that in there whenever I would touch a spec and asking other people to do the same.

+ +

And then, recently, one kind of, like, small syntax thing that I hadn't seen before, and maybe this is just because of the age of the codebases in which I'm working, the argument forwarding syntax in Ruby that has been new, I mean, it's like not totally new anymore [laughs], but throwing that in there a little every now and then to just kind of shift away from this, you know, dated version of the code kind of towards things that other people are seeing and in newer projects.

+ +

JOËL: I love harnessing that energy of being new on a project and wanting to make things better. How do you avoid just being, you know, that developer, though, that's new, comes in, and just wants to change everything for the sake of change or for your own personal opinions and just kind of moves things around, stirs the pot, but doesn't really contribute anything net positive to the team? Because I've definitely seen that as well, and that's not a good first contribution or, you know, contribution in general as a newer team member. How do we avoid being that person while still capitalizing on that energy of being someone new and wanting to make a positive impact?

+ +

STEPHANIE: Yeah, that's a great point, and I kind of alluded to this earlier when I asked, like, oh, like, even if you don't like an existing syntax or pattern you'll still follow it? And I think liking something a different way is not a good enough reason [chuckles]. But if you are able to have a good reason, like I mentioned with the RSpec prepending, you know, it didn't need to happen now, but if we would hope to upgrade that gem eventually, then yeah, that was a good reason to make that change as opposed to just purely aesthetic [laughs].

+ +

JOËL: That's one where there is pretty much a single right answer to. If you plan to keep staying up to date with versions of RSpec, you will eventually need to do all these code changes because, you know, they're deprecating the old way. Getting ahead of that gradually as we touch spec files, there's kind of no downside to it.

+ +

STEPHANIE: That's true, though maybe there is a person who exists out there who's like, "I love this old version of RSpec, and I will die on this hill that we have to stay on [laughs] it."

+ +

But I also think that I have preferences, but I'm not so attached to them. Ideally, you know, what I would love to receive is just, like, curiosity about like, "Oh, like, why did you make this change?" And just kind of share my reasoning. And sometimes in that process, I realize, you know, I don't have a great reason, and I'll just say, "I don't have a great reason. This is just the way I like it. But if it doesn't work for you, like, tell me, and I'll consider changing it back. [chuckles]"

+ +

JOËL: Maybe that's where there's a lot of benefit is the sort of curiosity on the part of the existing team and sort of openness to both learn about existing practices but also share about different practices from the new teammate. And maybe that's you're coming in, and you have a different style where you like to write tests, maybe without using RSpec's let syntax; the team is using it. Maybe you can have a conversation with the team. It's almost certainly not worth it for you to go and rewrite the entire test suite to not use let and be like, "Hey, first PR. I made your test better."

+ +

STEPHANIE: Hundreds of files changed, thousands [laughs] of lines of code. I think that's actually a good segue into the question of how can a team support a new hire or a new developer who is still calibrating to a codebase? I think I'm curious about this being different from onboarding because, you know, there are a lot of things that we already kind of expect to give some extra time and leeway for someone who's new coming in. But what might be some ways to support a new developer that are less well known?

+ +

JOËL: One that I really like is getting them involved as early as possible in code review because then they get to see the patterns that are coming in, and they can be involved in conversations on those. The first PR you're reviewing, and you see a bunch of tests leaning heavily on let, and maybe you ask a question, "Is this a pattern that we're following in this codebase? Did we have a particular motivation for why we chose this?"

+ +

And, you know, and you don't want to do it in a sort of, like, passive-aggressive way because you're trying to push something else. It has to come from a place of genuine curiosity, but you're allowing the new teammate to both see a lot of the existing patterns kind of in very quick succession because you see a pretty good cross-section of those when you review code.

+ +

And also, to have conversations about them, to ask anything like, "Oh, that's unusual. I didn't know we were doing that." Or, "Hey, is this a pattern that we're doing kind of just local to this subsystem, or is this something that's happening all the way? Is this a pattern that we're using and liking? Is this a thing that we were doing five years ago that we're phasing out, but there's still a few of them left?" Those are all, I think, great questions to ask when you're getting started.

+ +

STEPHANIE: That makes a lot of sense. It's different from saying, "This is how we do things here," and expecting them to adapt or, you know, change to fit into that style or culture, and being open to letting it evolve based on the new team, the new people on the team and what they might be bringing to the table.

+ +

I like to ask the question, "What do you need to know?" Or "What do you need to be successful?" as opposed to telling them what I think they need [laughs]. I think that is something that I actually kind of recently, not regret exactly, but I was kind of helping out some folks who were going to be joining the team and just trying to, like, shove all this information down their throats and be like, "Oh, and watch out for these gotchas. And this app uses a lot of callbacks, and they're really complex."

+ +

And I think I was maybe coloring their [chuckles] experience a little bit and expecting them to be able to drink from the fire hose, as opposed to trusting that they can see for themselves, you know, like, what is going on, and form opinions about it, and ask questions that will support them in whatever they are looking to do. When we talked earlier about the four different quadrants, like, the kind of information they need to know will differ based off of their task, based off of their experience. So, that's one way that I am thinking about to, like, make space for a new developer to help shape that culture, rather than insisting that things are the way they are.

+ +

JOËL: It can be a fine balance where you want to be open to change while also you have to remain kind of ruthlessly pragmatic about the fact that change can be expensive. And so, a lot of changes you need to be justified, and you don't want to just be rewriting your patterns for every new employee or, you know, just to follow the latest trends because we've seen a lot of trends come and go in the Rails ecosystem, and getting on all of them is just not worth our time.

+ +

STEPHANIE: And that's the hard truth of there's always trade-offs [laughs] in software development, isn't that right?

+ +

JOËL: It sure is. You can't always chase the newest shiny, as fun as that is.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+s9CtKiE9 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 414: Spike Tasks + https://bikeshed.thoughtbot.com/414 + e04b1ca3-55bc-4ab9-8cfc-abee2d680f36 + Tue, 30 Jan 2024 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël shares his recent experience with Turbo, a JavaScript framework that simplifies adding interactivity to websites without extensive JavaScript coding. Stephanie gives an update on her quest to work from her office more, and the birds have arrived—most notably, chickadees. + +Stephanie and Joël address a listener question from Edward about the concept of a "spike" in software development. They discuss the nature of spikes, emphasizing that they are typically throwaway work aimed at learning and de-risking rather than producing final code, and explore how spikes can lead to better decision-making and prioritization in software development, especially in complex codebases. + 31:46 + no + + + Joël shares his recent experience with Turbo, a JavaScript framework that simplifies adding interactivity to websites without extensive JavaScript coding. Stephanie gives an update on her quest to work from her office more, and the birds have arrived—most notably, chickadees. +Stephanie and Joël address a listener question from Edward about the concept of a "spike" in software development. They discuss the nature of spikes, emphasizing that they are typically throwaway work aimed at learning and de-risking rather than producing final code, and explore how spikes can lead to better decision-making and prioritization in software development, especially in complex codebases. +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: I'm pretty excited because this week, I actually got to use a little bit of Turbo for the first time. Turbo is Rails'...I guess it's not technically just for Rails. It's a sort of unobtrusive JavaScript framework that allows you to build a lot of interactive functionality without actually having to write a lot of JavaScript yourself, just by writing some HTML in a certain way. And you can add a lot of functionality and interactivity to your site without having to drop to custom writing some JavaScript. +STEPHANIE: Cool. Yeah, that is exciting. I personally have not gotten to use too much of it in a production/client setting; only played around with it a little bit on my own to keep up with what's new and just kind of reading about how other people are excited to use it. So, what are your first impressions so far? +JOËL: It's pretty nice. It, you know, works as advertised. My situation, I was rendering a calendar view of a lot of events, and this is completely server-rendered. And I realized, wait a minute, there are some days where I've got, like, 20 events, and I really, like, I want my calendar squares to say sort of equally sized. So, I wanted to limit myself to only showing four or five events per calendar day. +And so, I added a little link at the bottom of the calendar day that says, you know, "See more." And when you click that link, it does some Turbo stuff, and it pulls in other events so that you can now sort of expand it to get the whole day. So, it's just a little bit of interactivity that you kind of get for free with Turbo just by wrapping a particular HTML tag around it and having the Turbo library loaded. +STEPHANIE: That's cool. I'm excited to try it out next time I'm working on a Rails project that just needs a little bit of that interactivity, you know, just to make that experience a little bit richer. And it seems like a really good, like, low-effort way to add some of those enhancements. Based on what you described, it sounds really easy. +JOËL: Yeah, I was impressed with just how low effort it all was, which is what you want, right? It works out of the box. So, for anyone who's kind of curious about it, Turbo Frames is the little bit that I used, and it worked really well. +Oh, something I'm actually excited about it as well; it plays nicely with clients that have disabled JavaScript. So, this link that I click to pull in the rest of the events, if somebody has JavaScript disabled, or if they command-click or control-click to open in a new tab, it doesn't just do nothing like it would often do in many sort of front-end framework-y places that have hijacked the URL click handler. Instead, it actually opens up the full list of items in a new page, just as if you'd clicked a normal link. +So, it really gives you that progressive enhancement feel where I can click a link, and it goes to another page with a list of all the 30 events if I don't have JavaScript. But if I do, maybe I get a slightly better experience where, instead of taking me to a new page, it just expands the list, and I get to see the full list. So, it plays nicely on both sides. +STEPHANIE: That's really cool. As someone who's just starting to dabble in some alternative browsers outside of the main popular ones [chuckles], I have noticed how many websites do not work for me anymore [laughs]. And that sounds, like, nice from a user perspective. +JOËL: So, other than dabbling with the new browsers, what's new in your world? +STEPHANIE: A few weeks ago, I talked about [laughs] sitting more at my desk and, you know, various incentives that I gave myself to do that. And I'd like to say that I've been doing a pretty good job [laughs]. So, what's new in my world is that I've followed up on my commitment to sit at my desk more, feel a little bit more organized in my workday. And that's especially true because the birds have finally discovered my bird feeder [laughs]. +JOËL: Oh, that's really cool. +STEPHANIE: There were a few weeks where I was not really getting any visitors, and, you know, I was just like, when are they going to come and eat this delicious birdseed that I've [laughs] put out for them? And it seems like a flock of chickadees that normally like to hang out on the apple tree in my backyard have figured out this new source of food, and they'll sometimes, five of them at a time, will come, and sometimes they even fight [laughs] to get on the ledge to hang out at the bird feeder. +And yeah, it turns out that the six pounds of bird feed that I bought, I'll start to turn through [laughs] that a little bit quicker now, so I'm excited about that and just to also see other birds and species come and go as time goes on. So, that's been an exciting new development. +JOËL: So, the six pounds of birdseed might not last you through the winter. +STEPHANIE: I was debating between six pounds and, like, a 20-pound bag [laughs], which that would have been a lot. And so far, I think the six pounds has been serving me well. We'll see how long it lasts, but yeah, it's finally starting. I might have to refill it soon, so, you know, I was hopefully not going to have to store all that bird feed [laughs] just, like, in my house for a long time. +JOËL: Any birds that have shown up that have been particularly fun to watch or that are maybe your favorites? +STEPHANIE: I mentioned the chickadees because they seem to come as a group, and I really like watching them interact with each other. It's just kind of like bird TV, you know, it's not just a single bird. It's just watching these animals that are a collective do their thing. And I've been enjoying that a lot. +JOËL: Now I'm just imagining a reality TV but the Chickadee edition. +STEPHANIE: Oh yeah, definitely. I know some people put, like, cameras at their bird feeders to either live stream, which is funny because most of the time, there's nothing happening [laughs]. Usually, the birds are really in and out. Or they'll have, like, a really fancy camera to take, like, really beautiful up-close photos. +There's a blog that I discovered recently where someone posts about the birds that visit them at their place in Michigan. I'll link to it in the show notes, but it's really cool to see these, like, up-close and personal photos of basically the bird's mouth. Sometimes, they're open [laughs], so you can see right in them. I don't know; maybe there's a time where I'll get so into it that I'll create my own bird feeder blog. +JOËL: Well, if you do, you should definitely share it with the listeners on the podcast. Speaking of listeners on the podcast, we've recently had a listener question from Edward that I thought was a really interesting topic, and I wanted to take a whole episode to dig into. +And Edward asks about the concept of a spike. Sometimes, we're asked to investigate a complex new feature, and you might want to do some evaluation on the feasibility and complexity and build out just enough of it to make a well-informed opinion. And ideally, you're doing that in a way that reduces risk of spending too much time with unproven impact. +The problem is that in any reasonably complex codebase, that investigation work can be most of the work needed to build the feature. And Edward gives an example: if you're adding a system admin role, the core of the work is adding a new role with all of the abilities, but the real work is ensuring that it interacts with the entire system in the appropriate way. So, how do you manage making sure that you're doing spikes well? +And Edward asks if this is something that we've experienced a sort of feeling that we're doing 90% of the work in the spike. He also asks, does this say something about the codebase that you're working on? If it's hard to spike in it, does that say something about the underlying codebase, or are we just all doing spikes wrong? So yeah, I'm curious, Stephanie: do you occasionally spike things out in code on your projects? +STEPHANIE: Yeah, I do. I think one piece that was left a little bit unsaid is that I think spiking usually comes up when the team can't really estimate how long a task will take, you know, assuming that you use estimates on your team [chuckles]. That calls for a spike ticket, right? And someone will spend some time. And I think on some teams, this is usually time-boxed as well to maybe do a proof of concept or, yeah, do some of that initial exploration. +JOËL: Before we go too deep, I think it's probably useful to define spike in that I think it's a little bit easy and probably varies from team to team and even from a developer to developer. I think, for me, when I think of a spike, it's throwaway work. The code that I write will not get shipped, and this is not code that will just get improved later. It is entirely throwaway work. And the purpose of it is to learn something about the project that's being done. +Typically, it's in a sort of de-risking fashion, so to say, look, we've got a feature that's got a lot of unknowns in it. And if we commit to it right now or we start investing time into it, it could become a bit of a time pit. Let's try to answer some questions about it. Let's try to resolve some of those unknowns so that we can better make decisions around maybe estimation, but maybe even just prioritization. If this seems like something that would be really challenging to do, maybe we don't want to prioritize it this quarter. Is that similar to how you think of spikes, or do you have a different sort of definition of it? +STEPHANIE: Yeah, I am glad you mentioned that it's throwaway work. I think I was a little hesitant to commit to that definition with conviction because even based off of what Edward was saying, there's kind of, like, maybe different ideas about that or different expectations. But I sometimes think that, depending, spiking doesn't even necessarily need to lead to code. Like, it could just be answering questions. And so, at the same time, I think it is, I like what you said, work that helps you learn more about the system, whether or not there's some code written as, like, a potential path at the end of it. +JOËL: Interesting. So, you would put some things that don't involve code at all in the spike bucket. +STEPHANIE: I think there have been times where I've done a spike, and I've not coded out anything, but I've answered some questions, and I've left comments about unearthing some of the uncertainty that led us to want to explore the idea in the first place. Then, again, I also have gone down the path of, like, trying out a solution and maybe even multiple and then evaluating afterwards which ones I think were more suitable. So, it could mean both. I think that is actually something that's within the power of whoever is assigned this work to determine whatever is valuable to them in order to get enough information to figure out how you want to move forward. +JOËL: Another element of spikes that I think is often implied is that because this is throwaway work, you're not necessarily putting in all the work to make everything sort of clean, or well-structured, or reusable, or anything like that. So, it's quite possible that you would not even test this. You might not break this out into objects in the way that you would if this had to be reused. You might have duplication all over, and that's okay because the purpose of this code is not to be sort of production-grade; it's to answer some questions, and then you're going to throw it away and, using those answers, build something correctly. +STEPHANIE: Yeah, I think that's true. And it's kind of an interesting distinction from, you know, what you might consider your regular work in which the expectation is that it will be shipped [chuckles]. And there's also some amount of conflating the two, I think because if, you know, you and I are saying like, yeah, like, this exploration should be standalone, and it is not going to be used to be built on top of necessarily, there is some amount of revisiting. And you're not starting from scratch because you have an idea, but you are starting fresh if you will. +And so, you know, when you are doing that spiking, I think it allows you to move a little bit faster, but that doesn't mean that the work is, like, any X percent [laughs] done at the end of it. +JOËL: The work is still kind of, I guess, 0% done, again, because this is throwaway code, in our definition of a spike anyway. Would you distinguish between the terms spike and prototype? +STEPHANIE: Oh, interesting. My initial reaction is that a prototype would then be user-tested [laughs] in some way. Like, the point is to then show someone and then get them interacting with it, any initial reactions from that. Whereas a spike is really for the developer and maybe the team to discuss. +JOËL: I like that distinction. I definitely think that a spike, for me, is purely technical. We're not spiking out a feature by putting a thing live in production behind a feature flag, showing it to 10% of users, and seeing how they respond to that. That's not a spike. So, I think something a little bit more like that, or where you're showing things maybe to users, or you're wanting to do maybe some user testing with something. And it can be throwaway code still. I think now you're starting to get something more that you would call a prototype. So, I like that distinction of, is this sort of internal or external? +But in the way they're used, they can often be similar, and that oftentimes both will sort of...they're built to be as cheap as possible to answer the questions you're trying to get answered, whether that's from a user or just technical reasons. And so, the whole thing can be a little bit of smoke and mirrors, a little bit of duct tape and toothpicks, as long as you only have...like, the only solid parts you need are the parts that are going to help you answer your question. And so, any hack or cheat you can get to to bypass everything else is time you've saved, and that's a good thing. +STEPHANIE: Oh, I'm very curious about this idea of time saved because I think sometimes an underappreciated outcome of a spike is what not to do or is choosing not to do something. And it can feel not great to have spent hours or even days exploring a path just to realize that it's not worth it. I'm curious, like, when you know to stop and also, how you get other people kind of onboard that even just figuring out an initial idea was not a viable solution, how that could be a valuable insight to the rest of the team. +JOËL: Something that I think can be really useful is before you even start spiking out something, write a list of questions that you're trying to answer with this code, and then don't let yourself get distracted. Write the minimum amount of code that will allow you to answer those questions. So, maybe that is a question around, is it possible to connect this external API to our systems? There are some questions around, like, how credentials and things will work or how complex that will be. +It might be a question around, like, maybe there's even, like, a performance thing. We want to talk to an external system and, you know, the responses back need to be within a certain amount of time. Otherwise, this whole approach where we're going to try to fetch data live is not feasible. So, the answer we need there is, can we do it live, or do we need to consider some sort of background fetching, or caching approach, or something like that? So, write the minimum amount of code that it would take to do that. +And maybe the minimum amount of code, like you said, is not even really code. Maybe it's a script or even just trying out some curl commands and timing them at the command line. It could be a lot of things. But I think having a list of questions up front really helps you focus on the purpose of the spike. +And I think it helps me a little bit as well with emotional attachment in that success is not necessarily coming to a yes on all of those questions. It is having an answer, going from question mark to some answer. So, if I can answer that question, if I can find even a clever way to answer that question faster, that is success. I have done a good job with my spike. +STEPHANIE: I like that a lot. I think some people might struggle with spikes because they're so ambiguous. And if it's just, like, explore this potential feature, or, like, maybe not even that, but even saying, like, we want to build this admin role, to use Edward's example. And to constrain it to how should we do that, it already kind of guides the spike in a certain direction that may or may not be exactly what you're looking for. And so, there's some value in figuring out what questions to ask with the product team, even to get alignment on what the purpose of this task is. +And, you know, this is true of regular feature work, too. When those decisions have kind of already been made about what we're working on without a lot of input from developers who will be working on it, it can be really hard to, like, go back and be like, "Oh, actually, that's not really possible." But if the questions are like, "Is this possible?" or like, what it costs to do this, I think it prevents some of that friction and misalignment that might be had when the outcome of a spike turns out to be maybe not what someone wants to hear. +JOËL: And I think the questions you ask don't necessarily have to be yes or no questions. They could be some sort of list, right? It could be, look, we're looking at two different implementations or two general approaches, families of solutions for our super admin role. What are the trade-offs of each? +And so, a spike might be exploring. Can we come up with a list of pros and cons for each approach? And maybe some of them we just know from experience at developing, but maybe some of them might involve actually doing a little bit of work to play out the pros and cons. Maybe that's in our app. Maybe that's even spinning up a little app on the side, right? If we're comparing maybe two gems or something like that to see how we feel about throwing a few different scenarios and exploring edge cases. So, the questions don't need to be straight-up yes or no. +So, you mentioned earlier the idea that sometimes one developer might do the spike, and then another one might do the actual work, maybe inspired by the answers that were on that spike. And I think that can lead to some really interesting dynamics, especially if the developer who did the first spike has done kind of, like, what Edward describes, what feels like 90% of the feature. +It may be not so great code quality. And then this is a branch on GitHub, and they're like, "Okay, do the rest. Make it good. I've already explored the possibilities here," and then you're the developer who has to pick that up. Have you ever experienced that? And if so, how do you feel picking up a ticket like that? +STEPHANIE: Yeah, I have experienced it, and I think there is always something lost when that happens when you are not the person who did the research. And then having to just go from whatever was left in the notes or from the code and, you know, I don't know how feasible it is for whoever spiked to always be doing the implementing, but I certainly end up having a lot of questions, I think. Like, you can't document or even code out, like, every single thing you learned in that process, right? There's always from big to small decisions or alternatives considered that won't make it into however that communication or expression or knowledge transfer happens. +And I think the two choices that I have as a developer picking that up is either to just trust [laughs] that the work the other person did is taking me down a good path or to spend more time rebuilding some of that context and making some of my own evaluations along the way and deciding for myself whether I'm like, oh yeah, this is a good idea, or maybe, like, I might change something here. So, I think that there is some time lost, too. And I think that's a really good thing to point out when someone might think like, oh, this is mostly done. That's kind of my first reaction in terms of the context loss in an exchange like that. +JOËL: Do you feel like this is a situation where you would want to have the same developer do both the spike and the final implementation? Or is this maybe a situation where spikes aren't being done correctly, and maybe a branch with some code that's kind of half-written is maybe the wrong artifact to hand off from one developer to the other? +STEPHANIE: Oh, that's really interesting about if that's the wrong artifact to hand off because it could be misleading. Maybe it's not always, and maybe there's some really great code that comes out of it if someone builds on top of a work-in-progress branch or a spike branch. +Honestly, I think, and I haven't even really gotten to experience this all too much because maybe there is some perception that it's backtracking or, you know, it's more work or more time, but it would be really cool for whoever had spiked it to then bring someone along to pair on it and start fresh, like we mentioned, where they're kind of coming to each decision to be made with an idea, but it's not necessarily set in stone, right? There could be that discussion. It could be, like, a generative experience to either refine that code that had initially been spiked out or discover new things along the way. It's not like the outcome has already been decided because of the spike. It is information, and that's that. +JOËL: And we on this podcast are very pro-discovering new things along the way. I think sometimes as a developer, if I get sort of a, you know, maybe a 90% branch done that's get passed on to me from somebody else who did a spike, it feels a little bit like the finish the rest of the owl meme, except that now I'm not even, like, just trying to follow a tutorial. Just somebody did the first couple of circles and then is like, "Oh yeah, you finish the rest of the owl. I did the hard work. You just need to polish it up." +On the one hand, it's like, dude, if you're, like, doing 90%, you may as well finish it. I don't want to just be polishing somebody else's work. And, you know, oftentimes, it might feel like it's done 90% of the time, but it's actually, like, there's a lot of edge cases and nuance that have not been handled. And, you know, a spike is meant to be throwaway work to start with. So, I felt like those sorts of handoffs often, I don't know, they don't sit with me well. +STEPHANIE: Yeah. You could also come in and be like, this doesn't even look like an owl at all [laughs]. +JOËL: I feel like maybe in my ideal world, a branch with partly written code is, I guess, an intermediate artifact that might be useful to show. But what I really want from a spike is answers to questions that will allow me, when I build the thing from scratch to make intelligent decisions. +So, probably what I want out of a spike is something that's closer to documentation, a list of questions that we were asking, and then the answers we came to by doing the spike work. And that might be maybe a list of trade-offs, or maybe we didn't really know the correct endpoints from this undocumented API, and we tried some stuff, and we, like, figured out what endpoints we needed, or what the shape of the JSON payload needed to be, things like that. +Maybe we tried a couple of different implementations, or we did some exploration around, like, what gem we'd like to use, and we have a recommendation for a gem. Those are all, I think, very concrete outcomes from a spike that I can then use when I'm building it from scratch. And I'm not just, like, branching off your branch or having it open in another browser and copy-pasting snippets while trying to, like, add some testing and maybe modularizing it a little bit. +I think that leads to probably a better outcome for the person who's doing the spike because they have a tighter scope and also a better outcome for me, who's then trying to build that feature correctly from the ground up. I think that would be my sort of ideal workflow. +STEPHANIE: While you were saying that, I thought about how a lot of those points sounded like requirements for a feature. And that, I think, is also a good outcome when a spike then leads to more concrete requirements because those are all decisions that were thought through, right? And even better is if that also documents things that were tried and the trade-offs that came with them or, like, the reasons why they were less viable or not ideal for that added context because that is also work that happened [laughs] and should be captured so someone can know that that might not be time they need to spend on that. +I am really interested in one piece that we haven't quite touched on is the complexity of the app and what it means for spiking to be a challenge because of the complexity of the app. +JOËL: Yeah. And I think sort of inherent in there is that maybe the idea that if you have a really complex app, it sort of forces you to go to the 90% of the work done in order to successfully answer the questions you wanted to answer with your spike in a way that maybe a better-structured app would not. Do you think that's true? +STEPHANIE: Well, I actually think that if the app is complex, you're actually seeing that affect all parts of feature development, not just spiking, where everything takes longer [laughs] because you maybe feel less confident. You're nervous about breaking something. Edward called the real work ensuring that it interacts with the entire system correctly, and that's true of, I think, just software development in general. And so, I wonder if, you know, spiking happens to be one way that it manifests, but if there are signals that it's affecting, you know, all parts of your workflow. +JOËL: There definitely is a cost, right? Complex software imposes costs everywhere. In some way, I think maybe spiking is attempting to get around some of those, in that there are some decisions that we can just say, you know what? We'll build the feature, and we'll just kind of figure it out as we go along, and we'll, like, build the thing. +Spiking attempts to say, look, let's not build the whole thing. Let's fake out a bunch of parts because, really, we have a big question that we want to answer about a thing that is three steps down, you know. And maybe the question is, look, we're trying to build the super admin role, and we know it's got all these, like, edge cases we need to deal with. Maybe we need a list of the edge cases, and maybe that's how we, like, try to drive them out. +But maybe this is a, hey, do we want to go with more of a, like, a role hierarchy inheritance-based approach, or do we want to go with some sort of escalating defaults? Or whatever the couple of different strategies you might want to do. And the spike might be trying to answer the question, how can we, as cheaply as possible while doing the minimum amount of work, sort of explore which of these implementations works best? And in a complex system, is it possible to get to the answer to those questions without building out 90% of the feature itself? I think, going to what you said, you might have to do more work if it's a complex system. +But I would also encourage everyone to go absolute minimalist, like, keep your goal in mind: what is the question you're trying to answer? And then ruthlessly cut everything you need to get to your point where you can answer that question. Do you need to hard code? Do you need to metaprogram? Do you need to do just, like, the worst, dirtiest code that you've ever written? That's okay because, like, the implementation does not matter. The fact that you're not exercising the full system does not matter, as long as the part that you're trying to exercise and answer your questions does get used. +STEPHANIE: Yeah, I like that a lot. And I wonder if the impulse to want to spike something is coming out of nervousness about how complicated the ask is. And it's like, well, I don't want to tell you that it's going to take a long time because this app is extremely complex, and everything takes a long time. You know, it's like not wanting to face that hard question of either we need to just set our expectations that things take longer, or we need to make some kind of change to make that easier to work with. And that is a lot of thought and effort. +And so, it's kind of an answer to be like, well, like, let me spike this out and then see [laughs]. And so it may be a way to appease someone making a request for a feature. I don't know; I'm perhaps projecting a little bit here [chuckles]. But it could also be an important question to ask yourself if you find your team, like, needing to lean on spikes a lot because you just don't know. +JOËL: That's really interesting because I think that maybe connects to a recent episode we did on breaking features down into smaller chunks. Spikes can often manifest, or the need for a spike can often manifest when you've got a larger, less well-defined feature that you want to do. So, sometimes, breaking things into smaller pieces will help you have something that's a little bit more well-defined that you feel confident jumping into without doing a spike. +Or maybe the act of trying to split this sort of large, undefined task into smaller pieces will reveal questions that need to be answered and say, look, I don't know where the seam should be, where to split this task because I don't know the answer to this one question. If I could know the answer to this one question, I would know where to split this feature. That's your spike right there. +Do the minimum amount of code to answer that one question, and then you can split your feature and confidently work on the two smaller pieces. And I think that's a win for everyone. +STEPHANIE: Yeah. And you can listen back to our vertical slice episode [laughs] for some inspiration on that. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Joël shares his recent experience with Turbo, a JavaScript framework that simplifies adding interactivity to websites without extensive JavaScript coding. Stephanie gives an update on her quest to work from her office more, and the birds have arrived—most notably, chickadees.

+ +

Stephanie and Joël address a listener question from Edward about the concept of a "spike" in software development. They discuss the nature of spikes, emphasizing that they are typically throwaway work aimed at learning and de-risking rather than producing final code, and explore how spikes can lead to better decision-making and prioritization in software development, especially in complex codebases.

+ +

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: I'm pretty excited because this week, I actually got to use a little bit of Turbo for the first time. Turbo is Rails'...I guess it's not technically just for Rails. It's a sort of unobtrusive JavaScript framework that allows you to build a lot of interactive functionality without actually having to write a lot of JavaScript yourself, just by writing some HTML in a certain way. And you can add a lot of functionality and interactivity to your site without having to drop to custom writing some JavaScript.

+ +

STEPHANIE: Cool. Yeah, that is exciting. I personally have not gotten to use too much of it in a production/client setting; only played around with it a little bit on my own to keep up with what's new and just kind of reading about how other people are excited to use it. So, what are your first impressions so far?

+ +

JOËL: It's pretty nice. It, you know, works as advertised. My situation, I was rendering a calendar view of a lot of events, and this is completely server-rendered. And I realized, wait a minute, there are some days where I've got, like, 20 events, and I really, like, I want my calendar squares to say sort of equally sized. So, I wanted to limit myself to only showing four or five events per calendar day.

+ +

And so, I added a little link at the bottom of the calendar day that says, you know, "See more." And when you click that link, it does some Turbo stuff, and it pulls in other events so that you can now sort of expand it to get the whole day. So, it's just a little bit of interactivity that you kind of get for free with Turbo just by wrapping a particular HTML tag around it and having the Turbo library loaded.

+ +

STEPHANIE: That's cool. I'm excited to try it out next time I'm working on a Rails project that just needs a little bit of that interactivity, you know, just to make that experience a little bit richer. And it seems like a really good, like, low-effort way to add some of those enhancements. Based on what you described, it sounds really easy.

+ +

JOËL: Yeah, I was impressed with just how low effort it all was, which is what you want, right? It works out of the box. So, for anyone who's kind of curious about it, Turbo Frames is the little bit that I used, and it worked really well.

+ +

Oh, something I'm actually excited about it as well; it plays nicely with clients that have disabled JavaScript. So, this link that I click to pull in the rest of the events, if somebody has JavaScript disabled, or if they command-click or control-click to open in a new tab, it doesn't just do nothing like it would often do in many sort of front-end framework-y places that have hijacked the URL click handler. Instead, it actually opens up the full list of items in a new page, just as if you'd clicked a normal link.

+ +

So, it really gives you that progressive enhancement feel where I can click a link, and it goes to another page with a list of all the 30 events if I don't have JavaScript. But if I do, maybe I get a slightly better experience where, instead of taking me to a new page, it just expands the list, and I get to see the full list. So, it plays nicely on both sides.

+ +

STEPHANIE: That's really cool. As someone who's just starting to dabble in some alternative browsers outside of the main popular ones [chuckles], I have noticed how many websites do not work for me anymore [laughs]. And that sounds, like, nice from a user perspective.

+ +

JOËL: So, other than dabbling with the new browsers, what's new in your world?

+ +

STEPHANIE: A few weeks ago, I talked about [laughs] sitting more at my desk and, you know, various incentives that I gave myself to do that. And I'd like to say that I've been doing a pretty good job [laughs]. So, what's new in my world is that I've followed up on my commitment to sit at my desk more, feel a little bit more organized in my workday. And that's especially true because the birds have finally discovered my bird feeder [laughs].

+ +

JOËL: Oh, that's really cool.

+ +

STEPHANIE: There were a few weeks where I was not really getting any visitors, and, you know, I was just like, when are they going to come and eat this delicious birdseed that I've [laughs] put out for them? And it seems like a flock of chickadees that normally like to hang out on the apple tree in my backyard have figured out this new source of food, and they'll sometimes, five of them at a time, will come, and sometimes they even fight [laughs] to get on the ledge to hang out at the bird feeder.

+ +

And yeah, it turns out that the six pounds of bird feed that I bought, I'll start to turn through [laughs] that a little bit quicker now, so I'm excited about that and just to also see other birds and species come and go as time goes on. So, that's been an exciting new development.

+ +

JOËL: So, the six pounds of birdseed might not last you through the winter.

+ +

STEPHANIE: I was debating between six pounds and, like, a 20-pound bag [laughs], which that would have been a lot. And so far, I think the six pounds has been serving me well. We'll see how long it lasts, but yeah, it's finally starting. I might have to refill it soon, so, you know, I was hopefully not going to have to store all that bird feed [laughs] just, like, in my house for a long time.

+ +

JOËL: Any birds that have shown up that have been particularly fun to watch or that are maybe your favorites?

+ +

STEPHANIE: I mentioned the chickadees because they seem to come as a group, and I really like watching them interact with each other. It's just kind of like bird TV, you know, it's not just a single bird. It's just watching these animals that are a collective do their thing. And I've been enjoying that a lot.

+ +

JOËL: Now I'm just imagining a reality TV but the Chickadee edition.

+ +

STEPHANIE: Oh yeah, definitely. I know some people put, like, cameras at their bird feeders to either live stream, which is funny because most of the time, there's nothing happening [laughs]. Usually, the birds are really in and out. Or they'll have, like, a really fancy camera to take, like, really beautiful up-close photos.

+ +

There's a blog that I discovered recently where someone posts about the birds that visit them at their place in Michigan. I'll link to it in the show notes, but it's really cool to see these, like, up-close and personal photos of basically the bird's mouth. Sometimes, they're open [laughs], so you can see right in them. I don't know; maybe there's a time where I'll get so into it that I'll create my own bird feeder blog.

+ +

JOËL: Well, if you do, you should definitely share it with the listeners on the podcast. Speaking of listeners on the podcast, we've recently had a listener question from Edward that I thought was a really interesting topic, and I wanted to take a whole episode to dig into.

+ +

And Edward asks about the concept of a spike. Sometimes, we're asked to investigate a complex new feature, and you might want to do some evaluation on the feasibility and complexity and build out just enough of it to make a well-informed opinion. And ideally, you're doing that in a way that reduces risk of spending too much time with unproven impact.

+ +

The problem is that in any reasonably complex codebase, that investigation work can be most of the work needed to build the feature. And Edward gives an example: if you're adding a system admin role, the core of the work is adding a new role with all of the abilities, but the real work is ensuring that it interacts with the entire system in the appropriate way. So, how do you manage making sure that you're doing spikes well?

+ +

And Edward asks if this is something that we've experienced a sort of feeling that we're doing 90% of the work in the spike. He also asks, does this say something about the codebase that you're working on? If it's hard to spike in it, does that say something about the underlying codebase, or are we just all doing spikes wrong? So yeah, I'm curious, Stephanie: do you occasionally spike things out in code on your projects?

+ +

STEPHANIE: Yeah, I do. I think one piece that was left a little bit unsaid is that I think spiking usually comes up when the team can't really estimate how long a task will take, you know, assuming that you use estimates on your team [chuckles]. That calls for a spike ticket, right? And someone will spend some time. And I think on some teams, this is usually time-boxed as well to maybe do a proof of concept or, yeah, do some of that initial exploration.

+ +

JOËL: Before we go too deep, I think it's probably useful to define spike in that I think it's a little bit easy and probably varies from team to team and even from a developer to developer. I think, for me, when I think of a spike, it's throwaway work. The code that I write will not get shipped, and this is not code that will just get improved later. It is entirely throwaway work. And the purpose of it is to learn something about the project that's being done.

+ +

Typically, it's in a sort of de-risking fashion, so to say, look, we've got a feature that's got a lot of unknowns in it. And if we commit to it right now or we start investing time into it, it could become a bit of a time pit. Let's try to answer some questions about it. Let's try to resolve some of those unknowns so that we can better make decisions around maybe estimation, but maybe even just prioritization. If this seems like something that would be really challenging to do, maybe we don't want to prioritize it this quarter. Is that similar to how you think of spikes, or do you have a different sort of definition of it?

+ +

STEPHANIE: Yeah, I am glad you mentioned that it's throwaway work. I think I was a little hesitant to commit to that definition with conviction because even based off of what Edward was saying, there's kind of, like, maybe different ideas about that or different expectations. But I sometimes think that, depending, spiking doesn't even necessarily need to lead to code. Like, it could just be answering questions. And so, at the same time, I think it is, I like what you said, work that helps you learn more about the system, whether or not there's some code written as, like, a potential path at the end of it.

+ +

JOËL: Interesting. So, you would put some things that don't involve code at all in the spike bucket.

+ +

STEPHANIE: I think there have been times where I've done a spike, and I've not coded out anything, but I've answered some questions, and I've left comments about unearthing some of the uncertainty that led us to want to explore the idea in the first place. Then, again, I also have gone down the path of, like, trying out a solution and maybe even multiple and then evaluating afterwards which ones I think were more suitable. So, it could mean both. I think that is actually something that's within the power of whoever is assigned this work to determine whatever is valuable to them in order to get enough information to figure out how you want to move forward.

+ +

JOËL: Another element of spikes that I think is often implied is that because this is throwaway work, you're not necessarily putting in all the work to make everything sort of clean, or well-structured, or reusable, or anything like that. So, it's quite possible that you would not even test this. You might not break this out into objects in the way that you would if this had to be reused. You might have duplication all over, and that's okay because the purpose of this code is not to be sort of production-grade; it's to answer some questions, and then you're going to throw it away and, using those answers, build something correctly.

+ +

STEPHANIE: Yeah, I think that's true. And it's kind of an interesting distinction from, you know, what you might consider your regular work in which the expectation is that it will be shipped [chuckles]. And there's also some amount of conflating the two, I think because if, you know, you and I are saying like, yeah, like, this exploration should be standalone, and it is not going to be used to be built on top of necessarily, there is some amount of revisiting. And you're not starting from scratch because you have an idea, but you are starting fresh if you will.

+ +

And so, you know, when you are doing that spiking, I think it allows you to move a little bit faster, but that doesn't mean that the work is, like, any X percent [laughs] done at the end of it.

+ +

JOËL: The work is still kind of, I guess, 0% done, again, because this is throwaway code, in our definition of a spike anyway. Would you distinguish between the terms spike and prototype?

+ +

STEPHANIE: Oh, interesting. My initial reaction is that a prototype would then be user-tested [laughs] in some way. Like, the point is to then show someone and then get them interacting with it, any initial reactions from that. Whereas a spike is really for the developer and maybe the team to discuss.

+ +

JOËL: I like that distinction. I definitely think that a spike, for me, is purely technical. We're not spiking out a feature by putting a thing live in production behind a feature flag, showing it to 10% of users, and seeing how they respond to that. That's not a spike. So, I think something a little bit more like that, or where you're showing things maybe to users, or you're wanting to do maybe some user testing with something. And it can be throwaway code still. I think now you're starting to get something more that you would call a prototype. So, I like that distinction of, is this sort of internal or external?

+ +

But in the way they're used, they can often be similar, and that oftentimes both will sort of...they're built to be as cheap as possible to answer the questions you're trying to get answered, whether that's from a user or just technical reasons. And so, the whole thing can be a little bit of smoke and mirrors, a little bit of duct tape and toothpicks, as long as you only have...like, the only solid parts you need are the parts that are going to help you answer your question. And so, any hack or cheat you can get to to bypass everything else is time you've saved, and that's a good thing.

+ +

STEPHANIE: Oh, I'm very curious about this idea of time saved because I think sometimes an underappreciated outcome of a spike is what not to do or is choosing not to do something. And it can feel not great to have spent hours or even days exploring a path just to realize that it's not worth it. I'm curious, like, when you know to stop and also, how you get other people kind of onboard that even just figuring out an initial idea was not a viable solution, how that could be a valuable insight to the rest of the team.

+ +

JOËL: Something that I think can be really useful is before you even start spiking out something, write a list of questions that you're trying to answer with this code, and then don't let yourself get distracted. Write the minimum amount of code that will allow you to answer those questions. So, maybe that is a question around, is it possible to connect this external API to our systems? There are some questions around, like, how credentials and things will work or how complex that will be.

+ +

It might be a question around, like, maybe there's even, like, a performance thing. We want to talk to an external system and, you know, the responses back need to be within a certain amount of time. Otherwise, this whole approach where we're going to try to fetch data live is not feasible. So, the answer we need there is, can we do it live, or do we need to consider some sort of background fetching, or caching approach, or something like that? So, write the minimum amount of code that it would take to do that.

+ +

And maybe the minimum amount of code, like you said, is not even really code. Maybe it's a script or even just trying out some curl commands and timing them at the command line. It could be a lot of things. But I think having a list of questions up front really helps you focus on the purpose of the spike.

+ +

And I think it helps me a little bit as well with emotional attachment in that success is not necessarily coming to a yes on all of those questions. It is having an answer, going from question mark to some answer. So, if I can answer that question, if I can find even a clever way to answer that question faster, that is success. I have done a good job with my spike.

+ +

STEPHANIE: I like that a lot. I think some people might struggle with spikes because they're so ambiguous. And if it's just, like, explore this potential feature, or, like, maybe not even that, but even saying, like, we want to build this admin role, to use Edward's example. And to constrain it to how should we do that, it already kind of guides the spike in a certain direction that may or may not be exactly what you're looking for. And so, there's some value in figuring out what questions to ask with the product team, even to get alignment on what the purpose of this task is.

+ +

And, you know, this is true of regular feature work, too. When those decisions have kind of already been made about what we're working on without a lot of input from developers who will be working on it, it can be really hard to, like, go back and be like, "Oh, actually, that's not really possible." But if the questions are like, "Is this possible?" or like, what it costs to do this, I think it prevents some of that friction and misalignment that might be had when the outcome of a spike turns out to be maybe not what someone wants to hear.

+ +

JOËL: And I think the questions you ask don't necessarily have to be yes or no questions. They could be some sort of list, right? It could be, look, we're looking at two different implementations or two general approaches, families of solutions for our super admin role. What are the trade-offs of each?

+ +

And so, a spike might be exploring. Can we come up with a list of pros and cons for each approach? And maybe some of them we just know from experience at developing, but maybe some of them might involve actually doing a little bit of work to play out the pros and cons. Maybe that's in our app. Maybe that's even spinning up a little app on the side, right? If we're comparing maybe two gems or something like that to see how we feel about throwing a few different scenarios and exploring edge cases. So, the questions don't need to be straight-up yes or no.

+ +

So, you mentioned earlier the idea that sometimes one developer might do the spike, and then another one might do the actual work, maybe inspired by the answers that were on that spike. And I think that can lead to some really interesting dynamics, especially if the developer who did the first spike has done kind of, like, what Edward describes, what feels like 90% of the feature.

+ +

It may be not so great code quality. And then this is a branch on GitHub, and they're like, "Okay, do the rest. Make it good. I've already explored the possibilities here," and then you're the developer who has to pick that up. Have you ever experienced that? And if so, how do you feel picking up a ticket like that?

+ +

STEPHANIE: Yeah, I have experienced it, and I think there is always something lost when that happens when you are not the person who did the research. And then having to just go from whatever was left in the notes or from the code and, you know, I don't know how feasible it is for whoever spiked to always be doing the implementing, but I certainly end up having a lot of questions, I think. Like, you can't document or even code out, like, every single thing you learned in that process, right? There's always from big to small decisions or alternatives considered that won't make it into however that communication or expression or knowledge transfer happens.

+ +

And I think the two choices that I have as a developer picking that up is either to just trust [laughs] that the work the other person did is taking me down a good path or to spend more time rebuilding some of that context and making some of my own evaluations along the way and deciding for myself whether I'm like, oh yeah, this is a good idea, or maybe, like, I might change something here. So, I think that there is some time lost, too. And I think that's a really good thing to point out when someone might think like, oh, this is mostly done. That's kind of my first reaction in terms of the context loss in an exchange like that.

+ +

JOËL: Do you feel like this is a situation where you would want to have the same developer do both the spike and the final implementation? Or is this maybe a situation where spikes aren't being done correctly, and maybe a branch with some code that's kind of half-written is maybe the wrong artifact to hand off from one developer to the other?

+ +

STEPHANIE: Oh, that's really interesting about if that's the wrong artifact to hand off because it could be misleading. Maybe it's not always, and maybe there's some really great code that comes out of it if someone builds on top of a work-in-progress branch or a spike branch.

+ +

Honestly, I think, and I haven't even really gotten to experience this all too much because maybe there is some perception that it's backtracking or, you know, it's more work or more time, but it would be really cool for whoever had spiked it to then bring someone along to pair on it and start fresh, like we mentioned, where they're kind of coming to each decision to be made with an idea, but it's not necessarily set in stone, right? There could be that discussion. It could be, like, a generative experience to either refine that code that had initially been spiked out or discover new things along the way. It's not like the outcome has already been decided because of the spike. It is information, and that's that.

+ +

JOËL: And we on this podcast are very pro-discovering new things along the way. I think sometimes as a developer, if I get sort of a, you know, maybe a 90% branch done that's get passed on to me from somebody else who did a spike, it feels a little bit like the finish the rest of the owl meme, except that now I'm not even, like, just trying to follow a tutorial. Just somebody did the first couple of circles and then is like, "Oh yeah, you finish the rest of the owl. I did the hard work. You just need to polish it up."

+ +

On the one hand, it's like, dude, if you're, like, doing 90%, you may as well finish it. I don't want to just be polishing somebody else's work. And, you know, oftentimes, it might feel like it's done 90% of the time, but it's actually, like, there's a lot of edge cases and nuance that have not been handled. And, you know, a spike is meant to be throwaway work to start with. So, I felt like those sorts of handoffs often, I don't know, they don't sit with me well.

+ +

STEPHANIE: Yeah. You could also come in and be like, this doesn't even look like an owl at all [laughs].

+ +

JOËL: I feel like maybe in my ideal world, a branch with partly written code is, I guess, an intermediate artifact that might be useful to show. But what I really want from a spike is answers to questions that will allow me, when I build the thing from scratch to make intelligent decisions.

+ +

So, probably what I want out of a spike is something that's closer to documentation, a list of questions that we were asking, and then the answers we came to by doing the spike work. And that might be maybe a list of trade-offs, or maybe we didn't really know the correct endpoints from this undocumented API, and we tried some stuff, and we, like, figured out what endpoints we needed, or what the shape of the JSON payload needed to be, things like that.

+ +

Maybe we tried a couple of different implementations, or we did some exploration around, like, what gem we'd like to use, and we have a recommendation for a gem. Those are all, I think, very concrete outcomes from a spike that I can then use when I'm building it from scratch. And I'm not just, like, branching off your branch or having it open in another browser and copy-pasting snippets while trying to, like, add some testing and maybe modularizing it a little bit.

+ +

I think that leads to probably a better outcome for the person who's doing the spike because they have a tighter scope and also a better outcome for me, who's then trying to build that feature correctly from the ground up. I think that would be my sort of ideal workflow.

+ +

STEPHANIE: While you were saying that, I thought about how a lot of those points sounded like requirements for a feature. And that, I think, is also a good outcome when a spike then leads to more concrete requirements because those are all decisions that were thought through, right? And even better is if that also documents things that were tried and the trade-offs that came with them or, like, the reasons why they were less viable or not ideal for that added context because that is also work that happened [laughs] and should be captured so someone can know that that might not be time they need to spend on that.

+ +

I am really interested in one piece that we haven't quite touched on is the complexity of the app and what it means for spiking to be a challenge because of the complexity of the app.

+ +

JOËL: Yeah. And I think sort of inherent in there is that maybe the idea that if you have a really complex app, it sort of forces you to go to the 90% of the work done in order to successfully answer the questions you wanted to answer with your spike in a way that maybe a better-structured app would not. Do you think that's true?

+ +

STEPHANIE: Well, I actually think that if the app is complex, you're actually seeing that affect all parts of feature development, not just spiking, where everything takes longer [laughs] because you maybe feel less confident. You're nervous about breaking something. Edward called the real work ensuring that it interacts with the entire system correctly, and that's true of, I think, just software development in general. And so, I wonder if, you know, spiking happens to be one way that it manifests, but if there are signals that it's affecting, you know, all parts of your workflow.

+ +

JOËL: There definitely is a cost, right? Complex software imposes costs everywhere. In some way, I think maybe spiking is attempting to get around some of those, in that there are some decisions that we can just say, you know what? We'll build the feature, and we'll just kind of figure it out as we go along, and we'll, like, build the thing.

+ +

Spiking attempts to say, look, let's not build the whole thing. Let's fake out a bunch of parts because, really, we have a big question that we want to answer about a thing that is three steps down, you know. And maybe the question is, look, we're trying to build the super admin role, and we know it's got all these, like, edge cases we need to deal with. Maybe we need a list of the edge cases, and maybe that's how we, like, try to drive them out.

+ +

But maybe this is a, hey, do we want to go with more of a, like, a role hierarchy inheritance-based approach, or do we want to go with some sort of escalating defaults? Or whatever the couple of different strategies you might want to do. And the spike might be trying to answer the question, how can we, as cheaply as possible while doing the minimum amount of work, sort of explore which of these implementations works best? And in a complex system, is it possible to get to the answer to those questions without building out 90% of the feature itself? I think, going to what you said, you might have to do more work if it's a complex system.

+ +

But I would also encourage everyone to go absolute minimalist, like, keep your goal in mind: what is the question you're trying to answer? And then ruthlessly cut everything you need to get to your point where you can answer that question. Do you need to hard code? Do you need to metaprogram? Do you need to do just, like, the worst, dirtiest code that you've ever written? That's okay because, like, the implementation does not matter. The fact that you're not exercising the full system does not matter, as long as the part that you're trying to exercise and answer your questions does get used.

+ +

STEPHANIE: Yeah, I like that a lot. And I wonder if the impulse to want to spike something is coming out of nervousness about how complicated the ask is. And it's like, well, I don't want to tell you that it's going to take a long time because this app is extremely complex, and everything takes a long time. You know, it's like not wanting to face that hard question of either we need to just set our expectations that things take longer, or we need to make some kind of change to make that easier to work with. And that is a lot of thought and effort.

+ +

And so, it's kind of an answer to be like, well, like, let me spike this out and then see [laughs]. And so it may be a way to appease someone making a request for a feature. I don't know; I'm perhaps projecting a little bit here [chuckles]. But it could also be an important question to ask yourself if you find your team, like, needing to lean on spikes a lot because you just don't know.

+ +

JOËL: That's really interesting because I think that maybe connects to a recent episode we did on breaking features down into smaller chunks. Spikes can often manifest, or the need for a spike can often manifest when you've got a larger, less well-defined feature that you want to do. So, sometimes, breaking things into smaller pieces will help you have something that's a little bit more well-defined that you feel confident jumping into without doing a spike.

+ +

Or maybe the act of trying to split this sort of large, undefined task into smaller pieces will reveal questions that need to be answered and say, look, I don't know where the seam should be, where to split this task because I don't know the answer to this one question. If I could know the answer to this one question, I would know where to split this feature. That's your spike right there.

+ +

Do the minimum amount of code to answer that one question, and then you can split your feature and confidently work on the two smaller pieces. And I think that's a win for everyone.

+ +

STEPHANIE: Yeah. And you can listen back to our vertical slice episode [laughs] for some inspiration on that.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël shares his recent experience with Turbo, a JavaScript framework that simplifies adding interactivity to websites without extensive JavaScript coding. Stephanie gives an update on her quest to work from her office more, and the birds have arrived—most notably, chickadees.

+ +

Stephanie and Joël address a listener question from Edward about the concept of a "spike" in software development. They discuss the nature of spikes, emphasizing that they are typically throwaway work aimed at learning and de-risking rather than producing final code, and explore how spikes can lead to better decision-making and prioritization in software development, especially in complex codebases.

+ +

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: I'm pretty excited because this week, I actually got to use a little bit of Turbo for the first time. Turbo is Rails'...I guess it's not technically just for Rails. It's a sort of unobtrusive JavaScript framework that allows you to build a lot of interactive functionality without actually having to write a lot of JavaScript yourself, just by writing some HTML in a certain way. And you can add a lot of functionality and interactivity to your site without having to drop to custom writing some JavaScript.

+ +

STEPHANIE: Cool. Yeah, that is exciting. I personally have not gotten to use too much of it in a production/client setting; only played around with it a little bit on my own to keep up with what's new and just kind of reading about how other people are excited to use it. So, what are your first impressions so far?

+ +

JOËL: It's pretty nice. It, you know, works as advertised. My situation, I was rendering a calendar view of a lot of events, and this is completely server-rendered. And I realized, wait a minute, there are some days where I've got, like, 20 events, and I really, like, I want my calendar squares to say sort of equally sized. So, I wanted to limit myself to only showing four or five events per calendar day.

+ +

And so, I added a little link at the bottom of the calendar day that says, you know, "See more." And when you click that link, it does some Turbo stuff, and it pulls in other events so that you can now sort of expand it to get the whole day. So, it's just a little bit of interactivity that you kind of get for free with Turbo just by wrapping a particular HTML tag around it and having the Turbo library loaded.

+ +

STEPHANIE: That's cool. I'm excited to try it out next time I'm working on a Rails project that just needs a little bit of that interactivity, you know, just to make that experience a little bit richer. And it seems like a really good, like, low-effort way to add some of those enhancements. Based on what you described, it sounds really easy.

+ +

JOËL: Yeah, I was impressed with just how low effort it all was, which is what you want, right? It works out of the box. So, for anyone who's kind of curious about it, Turbo Frames is the little bit that I used, and it worked really well.

+ +

Oh, something I'm actually excited about it as well; it plays nicely with clients that have disabled JavaScript. So, this link that I click to pull in the rest of the events, if somebody has JavaScript disabled, or if they command-click or control-click to open in a new tab, it doesn't just do nothing like it would often do in many sort of front-end framework-y places that have hijacked the URL click handler. Instead, it actually opens up the full list of items in a new page, just as if you'd clicked a normal link.

+ +

So, it really gives you that progressive enhancement feel where I can click a link, and it goes to another page with a list of all the 30 events if I don't have JavaScript. But if I do, maybe I get a slightly better experience where, instead of taking me to a new page, it just expands the list, and I get to see the full list. So, it plays nicely on both sides.

+ +

STEPHANIE: That's really cool. As someone who's just starting to dabble in some alternative browsers outside of the main popular ones [chuckles], I have noticed how many websites do not work for me anymore [laughs]. And that sounds, like, nice from a user perspective.

+ +

JOËL: So, other than dabbling with the new browsers, what's new in your world?

+ +

STEPHANIE: A few weeks ago, I talked about [laughs] sitting more at my desk and, you know, various incentives that I gave myself to do that. And I'd like to say that I've been doing a pretty good job [laughs]. So, what's new in my world is that I've followed up on my commitment to sit at my desk more, feel a little bit more organized in my workday. And that's especially true because the birds have finally discovered my bird feeder [laughs].

+ +

JOËL: Oh, that's really cool.

+ +

STEPHANIE: There were a few weeks where I was not really getting any visitors, and, you know, I was just like, when are they going to come and eat this delicious birdseed that I've [laughs] put out for them? And it seems like a flock of chickadees that normally like to hang out on the apple tree in my backyard have figured out this new source of food, and they'll sometimes, five of them at a time, will come, and sometimes they even fight [laughs] to get on the ledge to hang out at the bird feeder.

+ +

And yeah, it turns out that the six pounds of bird feed that I bought, I'll start to turn through [laughs] that a little bit quicker now, so I'm excited about that and just to also see other birds and species come and go as time goes on. So, that's been an exciting new development.

+ +

JOËL: So, the six pounds of birdseed might not last you through the winter.

+ +

STEPHANIE: I was debating between six pounds and, like, a 20-pound bag [laughs], which that would have been a lot. And so far, I think the six pounds has been serving me well. We'll see how long it lasts, but yeah, it's finally starting. I might have to refill it soon, so, you know, I was hopefully not going to have to store all that bird feed [laughs] just, like, in my house for a long time.

+ +

JOËL: Any birds that have shown up that have been particularly fun to watch or that are maybe your favorites?

+ +

STEPHANIE: I mentioned the chickadees because they seem to come as a group, and I really like watching them interact with each other. It's just kind of like bird TV, you know, it's not just a single bird. It's just watching these animals that are a collective do their thing. And I've been enjoying that a lot.

+ +

JOËL: Now I'm just imagining a reality TV but the Chickadee edition.

+ +

STEPHANIE: Oh yeah, definitely. I know some people put, like, cameras at their bird feeders to either live stream, which is funny because most of the time, there's nothing happening [laughs]. Usually, the birds are really in and out. Or they'll have, like, a really fancy camera to take, like, really beautiful up-close photos.

+ +

There's a blog that I discovered recently where someone posts about the birds that visit them at their place in Michigan. I'll link to it in the show notes, but it's really cool to see these, like, up-close and personal photos of basically the bird's mouth. Sometimes, they're open [laughs], so you can see right in them. I don't know; maybe there's a time where I'll get so into it that I'll create my own bird feeder blog.

+ +

JOËL: Well, if you do, you should definitely share it with the listeners on the podcast. Speaking of listeners on the podcast, we've recently had a listener question from Edward that I thought was a really interesting topic, and I wanted to take a whole episode to dig into.

+ +

And Edward asks about the concept of a spike. Sometimes, we're asked to investigate a complex new feature, and you might want to do some evaluation on the feasibility and complexity and build out just enough of it to make a well-informed opinion. And ideally, you're doing that in a way that reduces risk of spending too much time with unproven impact.

+ +

The problem is that in any reasonably complex codebase, that investigation work can be most of the work needed to build the feature. And Edward gives an example: if you're adding a system admin role, the core of the work is adding a new role with all of the abilities, but the real work is ensuring that it interacts with the entire system in the appropriate way. So, how do you manage making sure that you're doing spikes well?

+ +

And Edward asks if this is something that we've experienced a sort of feeling that we're doing 90% of the work in the spike. He also asks, does this say something about the codebase that you're working on? If it's hard to spike in it, does that say something about the underlying codebase, or are we just all doing spikes wrong? So yeah, I'm curious, Stephanie: do you occasionally spike things out in code on your projects?

+ +

STEPHANIE: Yeah, I do. I think one piece that was left a little bit unsaid is that I think spiking usually comes up when the team can't really estimate how long a task will take, you know, assuming that you use estimates on your team [chuckles]. That calls for a spike ticket, right? And someone will spend some time. And I think on some teams, this is usually time-boxed as well to maybe do a proof of concept or, yeah, do some of that initial exploration.

+ +

JOËL: Before we go too deep, I think it's probably useful to define spike in that I think it's a little bit easy and probably varies from team to team and even from a developer to developer. I think, for me, when I think of a spike, it's throwaway work. The code that I write will not get shipped, and this is not code that will just get improved later. It is entirely throwaway work. And the purpose of it is to learn something about the project that's being done.

+ +

Typically, it's in a sort of de-risking fashion, so to say, look, we've got a feature that's got a lot of unknowns in it. And if we commit to it right now or we start investing time into it, it could become a bit of a time pit. Let's try to answer some questions about it. Let's try to resolve some of those unknowns so that we can better make decisions around maybe estimation, but maybe even just prioritization. If this seems like something that would be really challenging to do, maybe we don't want to prioritize it this quarter. Is that similar to how you think of spikes, or do you have a different sort of definition of it?

+ +

STEPHANIE: Yeah, I am glad you mentioned that it's throwaway work. I think I was a little hesitant to commit to that definition with conviction because even based off of what Edward was saying, there's kind of, like, maybe different ideas about that or different expectations. But I sometimes think that, depending, spiking doesn't even necessarily need to lead to code. Like, it could just be answering questions. And so, at the same time, I think it is, I like what you said, work that helps you learn more about the system, whether or not there's some code written as, like, a potential path at the end of it.

+ +

JOËL: Interesting. So, you would put some things that don't involve code at all in the spike bucket.

+ +

STEPHANIE: I think there have been times where I've done a spike, and I've not coded out anything, but I've answered some questions, and I've left comments about unearthing some of the uncertainty that led us to want to explore the idea in the first place. Then, again, I also have gone down the path of, like, trying out a solution and maybe even multiple and then evaluating afterwards which ones I think were more suitable. So, it could mean both. I think that is actually something that's within the power of whoever is assigned this work to determine whatever is valuable to them in order to get enough information to figure out how you want to move forward.

+ +

JOËL: Another element of spikes that I think is often implied is that because this is throwaway work, you're not necessarily putting in all the work to make everything sort of clean, or well-structured, or reusable, or anything like that. So, it's quite possible that you would not even test this. You might not break this out into objects in the way that you would if this had to be reused. You might have duplication all over, and that's okay because the purpose of this code is not to be sort of production-grade; it's to answer some questions, and then you're going to throw it away and, using those answers, build something correctly.

+ +

STEPHANIE: Yeah, I think that's true. And it's kind of an interesting distinction from, you know, what you might consider your regular work in which the expectation is that it will be shipped [chuckles]. And there's also some amount of conflating the two, I think because if, you know, you and I are saying like, yeah, like, this exploration should be standalone, and it is not going to be used to be built on top of necessarily, there is some amount of revisiting. And you're not starting from scratch because you have an idea, but you are starting fresh if you will.

+ +

And so, you know, when you are doing that spiking, I think it allows you to move a little bit faster, but that doesn't mean that the work is, like, any X percent [laughs] done at the end of it.

+ +

JOËL: The work is still kind of, I guess, 0% done, again, because this is throwaway code, in our definition of a spike anyway. Would you distinguish between the terms spike and prototype?

+ +

STEPHANIE: Oh, interesting. My initial reaction is that a prototype would then be user-tested [laughs] in some way. Like, the point is to then show someone and then get them interacting with it, any initial reactions from that. Whereas a spike is really for the developer and maybe the team to discuss.

+ +

JOËL: I like that distinction. I definitely think that a spike, for me, is purely technical. We're not spiking out a feature by putting a thing live in production behind a feature flag, showing it to 10% of users, and seeing how they respond to that. That's not a spike. So, I think something a little bit more like that, or where you're showing things maybe to users, or you're wanting to do maybe some user testing with something. And it can be throwaway code still. I think now you're starting to get something more that you would call a prototype. So, I like that distinction of, is this sort of internal or external?

+ +

But in the way they're used, they can often be similar, and that oftentimes both will sort of...they're built to be as cheap as possible to answer the questions you're trying to get answered, whether that's from a user or just technical reasons. And so, the whole thing can be a little bit of smoke and mirrors, a little bit of duct tape and toothpicks, as long as you only have...like, the only solid parts you need are the parts that are going to help you answer your question. And so, any hack or cheat you can get to to bypass everything else is time you've saved, and that's a good thing.

+ +

STEPHANIE: Oh, I'm very curious about this idea of time saved because I think sometimes an underappreciated outcome of a spike is what not to do or is choosing not to do something. And it can feel not great to have spent hours or even days exploring a path just to realize that it's not worth it. I'm curious, like, when you know to stop and also, how you get other people kind of onboard that even just figuring out an initial idea was not a viable solution, how that could be a valuable insight to the rest of the team.

+ +

JOËL: Something that I think can be really useful is before you even start spiking out something, write a list of questions that you're trying to answer with this code, and then don't let yourself get distracted. Write the minimum amount of code that will allow you to answer those questions. So, maybe that is a question around, is it possible to connect this external API to our systems? There are some questions around, like, how credentials and things will work or how complex that will be.

+ +

It might be a question around, like, maybe there's even, like, a performance thing. We want to talk to an external system and, you know, the responses back need to be within a certain amount of time. Otherwise, this whole approach where we're going to try to fetch data live is not feasible. So, the answer we need there is, can we do it live, or do we need to consider some sort of background fetching, or caching approach, or something like that? So, write the minimum amount of code that it would take to do that.

+ +

And maybe the minimum amount of code, like you said, is not even really code. Maybe it's a script or even just trying out some curl commands and timing them at the command line. It could be a lot of things. But I think having a list of questions up front really helps you focus on the purpose of the spike.

+ +

And I think it helps me a little bit as well with emotional attachment in that success is not necessarily coming to a yes on all of those questions. It is having an answer, going from question mark to some answer. So, if I can answer that question, if I can find even a clever way to answer that question faster, that is success. I have done a good job with my spike.

+ +

STEPHANIE: I like that a lot. I think some people might struggle with spikes because they're so ambiguous. And if it's just, like, explore this potential feature, or, like, maybe not even that, but even saying, like, we want to build this admin role, to use Edward's example. And to constrain it to how should we do that, it already kind of guides the spike in a certain direction that may or may not be exactly what you're looking for. And so, there's some value in figuring out what questions to ask with the product team, even to get alignment on what the purpose of this task is.

+ +

And, you know, this is true of regular feature work, too. When those decisions have kind of already been made about what we're working on without a lot of input from developers who will be working on it, it can be really hard to, like, go back and be like, "Oh, actually, that's not really possible." But if the questions are like, "Is this possible?" or like, what it costs to do this, I think it prevents some of that friction and misalignment that might be had when the outcome of a spike turns out to be maybe not what someone wants to hear.

+ +

JOËL: And I think the questions you ask don't necessarily have to be yes or no questions. They could be some sort of list, right? It could be, look, we're looking at two different implementations or two general approaches, families of solutions for our super admin role. What are the trade-offs of each?

+ +

And so, a spike might be exploring. Can we come up with a list of pros and cons for each approach? And maybe some of them we just know from experience at developing, but maybe some of them might involve actually doing a little bit of work to play out the pros and cons. Maybe that's in our app. Maybe that's even spinning up a little app on the side, right? If we're comparing maybe two gems or something like that to see how we feel about throwing a few different scenarios and exploring edge cases. So, the questions don't need to be straight-up yes or no.

+ +

So, you mentioned earlier the idea that sometimes one developer might do the spike, and then another one might do the actual work, maybe inspired by the answers that were on that spike. And I think that can lead to some really interesting dynamics, especially if the developer who did the first spike has done kind of, like, what Edward describes, what feels like 90% of the feature.

+ +

It may be not so great code quality. And then this is a branch on GitHub, and they're like, "Okay, do the rest. Make it good. I've already explored the possibilities here," and then you're the developer who has to pick that up. Have you ever experienced that? And if so, how do you feel picking up a ticket like that?

+ +

STEPHANIE: Yeah, I have experienced it, and I think there is always something lost when that happens when you are not the person who did the research. And then having to just go from whatever was left in the notes or from the code and, you know, I don't know how feasible it is for whoever spiked to always be doing the implementing, but I certainly end up having a lot of questions, I think. Like, you can't document or even code out, like, every single thing you learned in that process, right? There's always from big to small decisions or alternatives considered that won't make it into however that communication or expression or knowledge transfer happens.

+ +

And I think the two choices that I have as a developer picking that up is either to just trust [laughs] that the work the other person did is taking me down a good path or to spend more time rebuilding some of that context and making some of my own evaluations along the way and deciding for myself whether I'm like, oh yeah, this is a good idea, or maybe, like, I might change something here. So, I think that there is some time lost, too. And I think that's a really good thing to point out when someone might think like, oh, this is mostly done. That's kind of my first reaction in terms of the context loss in an exchange like that.

+ +

JOËL: Do you feel like this is a situation where you would want to have the same developer do both the spike and the final implementation? Or is this maybe a situation where spikes aren't being done correctly, and maybe a branch with some code that's kind of half-written is maybe the wrong artifact to hand off from one developer to the other?

+ +

STEPHANIE: Oh, that's really interesting about if that's the wrong artifact to hand off because it could be misleading. Maybe it's not always, and maybe there's some really great code that comes out of it if someone builds on top of a work-in-progress branch or a spike branch.

+ +

Honestly, I think, and I haven't even really gotten to experience this all too much because maybe there is some perception that it's backtracking or, you know, it's more work or more time, but it would be really cool for whoever had spiked it to then bring someone along to pair on it and start fresh, like we mentioned, where they're kind of coming to each decision to be made with an idea, but it's not necessarily set in stone, right? There could be that discussion. It could be, like, a generative experience to either refine that code that had initially been spiked out or discover new things along the way. It's not like the outcome has already been decided because of the spike. It is information, and that's that.

+ +

JOËL: And we on this podcast are very pro-discovering new things along the way. I think sometimes as a developer, if I get sort of a, you know, maybe a 90% branch done that's get passed on to me from somebody else who did a spike, it feels a little bit like the finish the rest of the owl meme, except that now I'm not even, like, just trying to follow a tutorial. Just somebody did the first couple of circles and then is like, "Oh yeah, you finish the rest of the owl. I did the hard work. You just need to polish it up."

+ +

On the one hand, it's like, dude, if you're, like, doing 90%, you may as well finish it. I don't want to just be polishing somebody else's work. And, you know, oftentimes, it might feel like it's done 90% of the time, but it's actually, like, there's a lot of edge cases and nuance that have not been handled. And, you know, a spike is meant to be throwaway work to start with. So, I felt like those sorts of handoffs often, I don't know, they don't sit with me well.

+ +

STEPHANIE: Yeah. You could also come in and be like, this doesn't even look like an owl at all [laughs].

+ +

JOËL: I feel like maybe in my ideal world, a branch with partly written code is, I guess, an intermediate artifact that might be useful to show. But what I really want from a spike is answers to questions that will allow me, when I build the thing from scratch to make intelligent decisions.

+ +

So, probably what I want out of a spike is something that's closer to documentation, a list of questions that we were asking, and then the answers we came to by doing the spike work. And that might be maybe a list of trade-offs, or maybe we didn't really know the correct endpoints from this undocumented API, and we tried some stuff, and we, like, figured out what endpoints we needed, or what the shape of the JSON payload needed to be, things like that.

+ +

Maybe we tried a couple of different implementations, or we did some exploration around, like, what gem we'd like to use, and we have a recommendation for a gem. Those are all, I think, very concrete outcomes from a spike that I can then use when I'm building it from scratch. And I'm not just, like, branching off your branch or having it open in another browser and copy-pasting snippets while trying to, like, add some testing and maybe modularizing it a little bit.

+ +

I think that leads to probably a better outcome for the person who's doing the spike because they have a tighter scope and also a better outcome for me, who's then trying to build that feature correctly from the ground up. I think that would be my sort of ideal workflow.

+ +

STEPHANIE: While you were saying that, I thought about how a lot of those points sounded like requirements for a feature. And that, I think, is also a good outcome when a spike then leads to more concrete requirements because those are all decisions that were thought through, right? And even better is if that also documents things that were tried and the trade-offs that came with them or, like, the reasons why they were less viable or not ideal for that added context because that is also work that happened [laughs] and should be captured so someone can know that that might not be time they need to spend on that.

+ +

I am really interested in one piece that we haven't quite touched on is the complexity of the app and what it means for spiking to be a challenge because of the complexity of the app.

+ +

JOËL: Yeah. And I think sort of inherent in there is that maybe the idea that if you have a really complex app, it sort of forces you to go to the 90% of the work done in order to successfully answer the questions you wanted to answer with your spike in a way that maybe a better-structured app would not. Do you think that's true?

+ +

STEPHANIE: Well, I actually think that if the app is complex, you're actually seeing that affect all parts of feature development, not just spiking, where everything takes longer [laughs] because you maybe feel less confident. You're nervous about breaking something. Edward called the real work ensuring that it interacts with the entire system correctly, and that's true of, I think, just software development in general. And so, I wonder if, you know, spiking happens to be one way that it manifests, but if there are signals that it's affecting, you know, all parts of your workflow.

+ +

JOËL: There definitely is a cost, right? Complex software imposes costs everywhere. In some way, I think maybe spiking is attempting to get around some of those, in that there are some decisions that we can just say, you know what? We'll build the feature, and we'll just kind of figure it out as we go along, and we'll, like, build the thing.

+ +

Spiking attempts to say, look, let's not build the whole thing. Let's fake out a bunch of parts because, really, we have a big question that we want to answer about a thing that is three steps down, you know. And maybe the question is, look, we're trying to build the super admin role, and we know it's got all these, like, edge cases we need to deal with. Maybe we need a list of the edge cases, and maybe that's how we, like, try to drive them out.

+ +

But maybe this is a, hey, do we want to go with more of a, like, a role hierarchy inheritance-based approach, or do we want to go with some sort of escalating defaults? Or whatever the couple of different strategies you might want to do. And the spike might be trying to answer the question, how can we, as cheaply as possible while doing the minimum amount of work, sort of explore which of these implementations works best? And in a complex system, is it possible to get to the answer to those questions without building out 90% of the feature itself? I think, going to what you said, you might have to do more work if it's a complex system.

+ +

But I would also encourage everyone to go absolute minimalist, like, keep your goal in mind: what is the question you're trying to answer? And then ruthlessly cut everything you need to get to your point where you can answer that question. Do you need to hard code? Do you need to metaprogram? Do you need to do just, like, the worst, dirtiest code that you've ever written? That's okay because, like, the implementation does not matter. The fact that you're not exercising the full system does not matter, as long as the part that you're trying to exercise and answer your questions does get used.

+ +

STEPHANIE: Yeah, I like that a lot. And I wonder if the impulse to want to spike something is coming out of nervousness about how complicated the ask is. And it's like, well, I don't want to tell you that it's going to take a long time because this app is extremely complex, and everything takes a long time. You know, it's like not wanting to face that hard question of either we need to just set our expectations that things take longer, or we need to make some kind of change to make that easier to work with. And that is a lot of thought and effort.

+ +

And so, it's kind of an answer to be like, well, like, let me spike this out and then see [laughs]. And so it may be a way to appease someone making a request for a feature. I don't know; I'm perhaps projecting a little bit here [chuckles]. But it could also be an important question to ask yourself if you find your team, like, needing to lean on spikes a lot because you just don't know.

+ +

JOËL: That's really interesting because I think that maybe connects to a recent episode we did on breaking features down into smaller chunks. Spikes can often manifest, or the need for a spike can often manifest when you've got a larger, less well-defined feature that you want to do. So, sometimes, breaking things into smaller pieces will help you have something that's a little bit more well-defined that you feel confident jumping into without doing a spike.

+ +

Or maybe the act of trying to split this sort of large, undefined task into smaller pieces will reveal questions that need to be answered and say, look, I don't know where the seam should be, where to split this task because I don't know the answer to this one question. If I could know the answer to this one question, I would know where to split this feature. That's your spike right there.

+ +

Do the minimum amount of code to answer that one question, and then you can split your feature and confidently work on the two smaller pieces. And I think that's a win for everyone.

+ +

STEPHANIE: Yeah. And you can listen back to our vertical slice episode [laughs] for some inspiration on that.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+i-ALMdpK + + ]]> + + Joël Quenneville + Stephanie Minn + + + 413: Developer Tales of Package Management + https://bikeshed.thoughtbot.com/413 + ace66b4c-a94a-4051-8dcb-30837e0e925a + Tue, 23 Jan 2024 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces. + +Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker. + 33:33 + no + + + Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces. +Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker. +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, this week, I got to have some fun working on some internal thoughtbot work. And what I focused on was retiring one of our just, like, small internal self-hosted on Heroku apps in favor of going with a third-party service for this functionality. We basically had a tiny, little app that we used as a link-shortening service. So, if you've ever seen a tbot.io short link out in the world, we were using our just, like, an in-house app to do that, you know, but for various reasons, we wanted to...just it wasn't worth maintaining anymore. So, we wanted to just use a purchased service. +But today, I got to just, like, do the little bit of, like, tidying up, you know, in preparation to archive a repo and kind of delete the app from Heroku, and I hadn't done that before. So, it felt a little bit celebratory and a little bit mournful even [laughs] to, you know, retire something like that. And I was pairing with another thoughtbot developer, and we used a pairing app called Tuple. And you can just send, like, fun reactions to each other. Like, you could send, like, a fire emoji [laughs] or something if that's what you're feeling. +And so, I sent some, like, confetti when we clicked the, "I understand what deleting this app means on GitHub." But I joked that "Actually, I feel like what I really needed was a, like, a salute kind of like thank you for your service [laughs] type of reaction." +JOËL: I love those moments when you're kind of you're hitting those kind of milestone-y moments, and then you get to send a reaction. I should do that more often in Tuple. Those are fun. +STEPHANIE: They are fun. There's also a, like, table flip reaction, too, is one that I really enjoy [laughs], you know, you just have to manifest that energy somehow. And then, after we kind of sent out an email to the company saying like, "Oh yeah, we're not using our app anymore for link shortening," someone had a great suggestion to make our archived repo public instead of private. I kind of liked it as a way of, like, memorializing this application and let community members see, you know, real code in a real...the application that we used here at thoughtbot. So, hopefully, if not me, then someone else will be able to do that and maybe publish a little blog post about that. +JOËL: That's exciting. So, it's not currently public, the repo, but it might be at some point in the future. +STEPHANIE: Yeah, that's right. +JOËL: We'll definitely have to mention it on a future episode if that happens so that people following along with the story can go check out the code. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I've been doing a deep dive into how ActiveRecord works. Particularly, I am debugging some pretty significant slowdowns in querying ActiveRecord models that are backed not by a regular Postgres database but instead a Snowflake data warehouse via an ODBC connection. So, there's a bunch of moving pieces going on here, and it would just take forever to make any queries. +And sure, the actual reported query time is longer than for a local Postgres database, but then there's this sort of mystery extra waiting time, and I couldn't figure out why is it taking so much longer than the actual sort of recorded query time. And I started digging into all of this, and it turns out that in addition to executing queries to pull actual data in, ActiveRecord needs to, at various points, query the schema of your data store to pull things like names of tables and what are the indexes and primary keys and things like that. +STEPHANIE: Wow. That sounds really cool and something that I have never needed to do before. I'm curious if you noticed...you said that it takes, I guess, longer to query Snowflake than it would a more common Postgres database. Were you noticing this performance slowness locally or on production? +JOËL: Both places. So, the nice thing is I can reproduce it locally, and locally, I mean running the Rails app locally. I'm still talking to a remote Snowflake data warehouse, which is fine. I can reproduce that slowness locally, which has made it much easier to experiment and try things. And so, from there, it's really just been a bit of a detective case trying to, I guess, narrow the possibility space and try to understand what are the parts that trigger slowness. So, I'm printing timestamps in different places. I've got different things that get measured. +I've not done, like, a profiling tool to generate a flame graph or anything like that. That might have been something cool to try. I just did old-school print statements in a couple of places where I, like, time before, time after, print the delta, and that's gotten me pretty far. +STEPHANIE: That's pretty cool. What do you think will be an outcome of this? Because I remember you saying you're digging a little bit into ActiveRecord internals. So, based on, like, what you're exploring, what do you think you could do as a developer to increase some of the performance there? +JOËL: I think probably what this ends up being is finding that the Snowflake adapter that I'm using for ActiveRecord maybe has some sort of small bug in it or some implementation that's a little bit too naive that needs to be fine-tuned. And so, probably what ends up happening here is that this finishes as, like, an open-source pull request to the Snowflake Adapter gem. +STEPHANIE: Yeah, that's where I thought maybe that might go. And that's pretty cool, too, and to, you know, just be investigating something on your app and being able to make a contribution that it benefits the community. +JOËL: And that's what's so great about open source because not only am I able to get the source to go source diving through all of this, because I absolutely need to do that, but also, then if I make a fix, I can push that fix back out to the community, and everybody gets to benefit. +STEPHANIE: Cool. Well, that's another thing that I look forward to hearing more on the development of [laughs] later if it pans out that way. +JOËL: One thing that has been interesting with this Snowflake work is that there are a lot of moving parts and multiple different packages that I need to install to get this all to work. So, I mentioned that I might be doing a pull request against the Snowflake Adapter for ActiveRecord, but all of this talks through a sort of lower-level technology protocol called ODBC, which is a sort of generic protocol for speaking to data stores, and that actually has two different pieces. I had to install two different packages. +There is a sort of low-level executable that I had to install on my local dev machine and that I have to install on our servers. And on my Mac, I'm installing that via Homebrew, which is a system package. And then to get Ruby bindings for that, there is a Ruby gem that I install that allows Ruby code to talk to ODBC, and that's installed via RubyGems or Bundler. +And that got me thinking about sort of these two separate ecosystems that I tend to work with every day. We've got sort of the system packages and the, I don't know what you want to call them, language packages maybe, things like RubyGems, but that could also be NPM or whatever your language of choice is, and realizing that we kind of have things split into two different zones, and sometimes we need both and wondering a little bit about why is that difference necessary. +STEPHANIE: Yeah, I don't have an answer to that [laughs] question right now, but I can say that that was an area that really tripped me up, I think, when I was first a fledgling developer. And I was really confused about where all of these dependencies were coming from and going through, you know, setting up my first project and being, like, asked to install Postgres on my machine but then also Bundler, which then also installs more dependencies [laughs]. +The lines between those ecosystems were not super clear to me. And, you know, even now, like, I find myself really just kind of, like, learning what I need to know to get by [laughs] with my day-to-day work. But I do like what you said about these are kind of the two main layers that you're working with in terms of package management. And it's really helpful to have that knowledge so you can troubleshoot when there is an issue at one or the other. +JOËL: And you mentioned Postgres. That's another one that's interesting because there are components in both of those ecosystems. Postgres itself is typically installed via a system package manager, so something like Homebrew on a Mac or apt-get on a Linux machine. But then, if you're interacting with Postgres in a Ruby app, you're probably also installing the pg gem, which are Ruby's bindings for Postgres to allow Ruby to talk to Postgres, and that lives in the package ecosystem on RubyGems. +STEPHANIE: Yeah, I've certainly been in the position of, you know, again, as consultants, we oftentimes are also setting up new laptops entirely [laughs] like client laptops and such and bundling and the pg gem is installed. And then at least I have, you know, I have to give thanks to the very clear error message that [laughs] tells me that I don't have Postgres installed on my machine. Because when I mentioned, you know, troubleshooting earlier, I've certainly been in positions where it was really unclear what was going on in terms of the interaction between what I guess we're calling the Ruby package ecosystem and our system level one. +JOËL: Especially for things like the pg gem, which need to compile against some existing libraries, those always get interesting where sometimes they'll fail to compile because there's a path to some C compiler that's not set correctly or something like that. For me, typically, that means I need to update the macOS command line tools or the Xcode command line tools; I forget what the name of that package is. And, usually, that does the trick. That might happen if I've upgraded my OS version recently and haven't downloaded the latest version of the command line tools. +STEPHANIE: Yeah. Speaking of OS versions, I have a bit of a story to share about using...I've never said this name out loud, but I am pretty sure that it would just be pronounced as wkhtmltopdf [laughs]. For some reason, whenever I see words like that in my brain, I want to, like, make it into a pronounceable thing [laughs]. +JOËL: Right, just insert some vowels in there. +STEPHANIE: Yeah, wkhtmltopdf [laughs]. Anyway, that was being used in an app to generate PDF invoices or something. It's a pretty old tool. It's a CLI tool, and it's, as far as I can tell, it's been around for a long time but was recently no longer maintained. And so, as I was working on this app, I was running into a bug where that library was causing some issues with the PDF that was generated. So, I had to go down this route of actually finding a Ruby gem that would figure out which package binary to use, you know, based off of my system. And that worked great locally, and I was like, okay, cool, I fixed the issue. +And then, once I pushed my change, it turns out that it did not work on CI because CI was running on Ubuntu. And I guess the binary didn't work with the latest version of Ubuntu that was running on CI, so there was just so many incompatibilities there. And I was wanting to fix this bug. But the next step I took was looking into community-provided packages because there just simply weren't any, like, up-to-date binaries that would likely work with these new operating systems. And I kind of stopped at that point because I just wasn't really sure, like, how trustworthy were these community packages. That was an ecosystem I didn't know enough about. +In particular, I was having to install some using apt from, you know, just, like, some Linux community. But yeah, I think I normally have a little bit more experience and confidence in terms of the Ruby package ecosystem and can tell, like, what gems are popular, which ones are trustworthy. There are different heuristics I have for evaluating what dependency to pull in. But here I ended up just kind of bailing out of that endeavor because I just didn't have enough time to go down that rabbit hole. +JOËL: It is interesting that learning how to evaluate packages is a skill you have to learn that varies from package community to package community. I know that when I used to be very involved with Elm, we would often have people who would come to the Elm community from the JavaScript community who were used to evaluating NPM packages. And one of the metrics that was very popular in the JavaScript community is just stars on GitHub. That's a really important metric. And that wasn't really much of a thing in the Elm community. +And so, people would come and be like, "Wait, how do I know which package is good? I don't see any stars on GitHub." And then, it turns out that there are other metrics that people would use. And similarly, you know, in Ruby, there are different ways that you might use to evaluate Ruby gems that may or may not involve stars on GitHub. It might be something entirely different. +STEPHANIE: Yeah. Speaking of that, I wanted to plug a website that I have used before called the Ruby Toolbox, and that gives some suggestions for open-source Ruby libraries of various categories. So, if you're looking for, like, a JSON parser, it has some of the more popular ones. If you're looking for, you know, it stores them by category, and I think it is also based on things like stars and forks like that, so that's a good one to know. +JOËL: You could probably also look at something like download numbers to see what's popular, although sometimes it's sort of, like, an emergent gem that's more popular. Some of that almost you just need to be a little bit in the community, like, hearing, you know, maybe listening to podcasts like this one, subscribing to Ruby newsletters, going to conferences, things like that, and to realize, okay, maybe, you know, we had sort of an old staple for JSON parsing, but there's a new thing that's twice as fast. And this is sort of becoming the new standard, and the community is shifting towards that. You might not know that just by looking at raw stats. So, there's a human component to it as well. +STEPHANIE: Yeah, absolutely. I think an extension of knowing how to evaluate different package systems is this question of like, how much does an average developer need to know about package management? [laughs] +JOËL: Yeah, a little bit to a medium amount, and then if you're writing your own packages, you probably need to know a little bit more. But there are some things that are really maybe best left to the maintainers of package managers. Package managers are actually pretty complex pieces of software in terms of all of the dependency management and making sure that when you say, "Oh, I've got Rails, and this other gem, and this other gem, and it's going to find the exact versions of all those gems that play nicely together," that's non-trivial. +As a sort of working developer, you don't need to know all of the algorithms or the graph theory or any of that that underlies a package manager to be able to be productive in your career. And even as a package developer, you probably don't need to really know a whole lot of that. +STEPHANIE: Yeah, that makes sense. I actually had referred to our internal at thoughtbot here, our kind of, like, expectations for skill levels for developers. And I would say for an average developer, we kind of just expect a basic understanding of these more complex parts of our toolchain, I think, specifically, like, command line tools and package management. And I think I'd mentioned earlier that, for me, it is a very need-to-know basis. +And so, yeah, when I was going down that little bit of exploration around why wkhtmltopdf [chuckles] wasn't working [chuckles], it was a bit of a twisty and turning journey where I, you know, wasn't really sure where to go. I was getting very obtuse error messages, and, you know, I had to dive deep into all these forums [laughs] for all the various platforms [laughs] about why libraries weren't working. +And I think what I did come away with was that like, oh, like, even though I'm mostly working on my local machine for development, there was some amount of knowledge I needed to have about the systems that my CI and, you know, production servers are running on. The project I was working on happened to have, like, a Docker file for those environments, and, you know, kind of knowing how to configure them to install the packages I needed to install and just knowing a little bit about the different ways of doing that on systems outside of my usual daily workflows. +JOËL: And I think that gets back to some of the interesting distinctions between what we might call language packages versus system packages is that language packages more or less work the same across all operating systems. They might have a build step that's slightly different or something like that, but system packages might be pretty different between different operating systems. +So, development, for me, is a Mac, and I'm probably installing system packages via something like Homebrew. If I then want that Rails app to run on CI or some Linux server somewhere, I can't use Homebrew to install things there. It's going to be a slightly different package ecosystem. And so, now I need to find something that will install Postgres for Linux, something that will install, I guess, wkhtmltopdf [laughs] for Linux. +And so, when I'm building that Docker file, that might be a little bit different for Mac versus for...or I guess when you run a Docker file, you're running a containerized system. So, the goal there is to make this system the same everywhere for everyone. But when you're setting that up, typically, it's more of a Linux-like system. And so running inside the Docker container versus outside on the native Mac might involve a totally different set of packages and a different package tool. As opposed to something like Bundler, you've got your gem file; you bundle install. It doesn't matter if you're on Linux or macOS. +STEPHANIE: Yes, I think you're right. I think we kind of answered our own question at the top of the show [laughs] about differences and what do you need to know about them. And I also like how you pointed out, oh yeah, like, Docker is supposed to [laughs], you know, make sure that we're all developing in the same system, essentially. But, you know, sometimes you have different use cases for it. +And, yeah, when you were talking about installing an application on your native Mac and using Homebrew, but even, you know, not everyone even uses Homebrew, right? You can install manually [laughs] through whatever official installer that application might provide. So, there's just so many different ways of doing something. And I had the thought that it's too bad that we both [chuckles] develop on Mac because it could be really interesting to get a Linux user's perspective in here. +JOËL: You mentioned not installing via Homebrew. A kind of glaring example of that in my personal setup is that I use Postgres.app to manage Postgres on my machine rather than using Homebrew. I've just...over the years, the Homebrew version every time I upgrade my operating system or something, it's just such a pain to update, and I've lost too many hours to it, and Postgres.app just works, and so I've switched to that. Most other things, I'll use the Homebrew version, but Postgres it's now Postgres.app. It's not even a command line install, and it works fine for me. +STEPHANIE: Nice. Yeah. That's interesting. That's a good tip. I'll have to look into that next time because I have also certainly had to just install so many [laughs] various versions of Postgres and figure out what's going on with them every time I upgrade my OS. I'm with you, though, in terms of the packages world I'm looking for, it works [laughs]. +JOËL: So, you'd mentioned earlier that packages is sort of an area that's a bit of a need-to-know basis for you. Are there, like, particular moments in your career that you remember like, oh, that's the moment where I needed to, like, take some time and learn a little bit of the next level of packages? +STEPHANIE: That's a great question. I think the very beginnings of understanding how package versions work when you have multiple projects on your machine; I just remember that being really confusing for me. When I started out, like, you know, as soon as I cloned my second repo [laughs], and was very confused about, like, I'm sure I went through the process of not installing gems using Bundler, and then just having so much chaos [laughs] wrecked in my development environment and, you know, having to ask someone, "I don't understand how this works. Like, why is it saying I have multiple versions of this library or whatever?" +JOËL: Have you ever sudo gem installed a gem? +STEPHANIE: Oh yeah, I definitely have. I can't [laughs], like, even give a good reason for why I have done it, but I probably was just, like, pulling my hair out, and that's what Stack Overflow told me to do. I don't know if I can recommend that, but it is [chuckles] one thing to do when you just are kind of totally stuck. +JOËL: There was a time where I think that that was in the READMEs for most projects. +STEPHANIE: Yeah, that's a really good point. +JOËL: So, that's probably why a lot of people end up doing that, but then it tends to install it for your system Ruby rather than for...because if you're using something like Rbenv or RVM or ASDF to manage multiple Ruby versions, those end up being what's using or even Homebrew to manage your Ruby. It wouldn't be installing it for those versions of Ruby. It would be installing it for the one that shipped with your Mac. +I actually...you know what? I don't even know if Mac still ships with Ruby. It used to. It used to ship with a really old version of Ruby, and so the advice was like, "Hey, every repo tells you to install it with sudo; don't do that. It will mess you up." +STEPHANIE: Huh. I think Mac still does ship with Ruby, but don't quote me on that [laughter]. And I think that's really funny that, like, yeah, people were just writing those instructions in READMEs. And I'm glad that we've collectively [laughs] figured out that difference and want to, hopefully, not let other developers fall into that trap [laughs]. Do you have a particular memory or experience when you had to kind of level up your knowledge about the package ecosystem? +JOËL: I think one sort of moment where I really had to level up is when I started really needing to understand how install paths worked, especially when you have, let's say, multiple versions of a gem installed because you have different projects. And you want to know, like, how does it know which one it's using? And then you see, oh, there are different paths that point to different directories with the installs. +Or when you might have an executable you've installed via Homebrew, and it's like, oh yeah, so I've got this, like, command that I run on my shell, but actually that points to a very particular path, you know, in my Homebrew directory. But maybe it could also point to some, like, pre-installed system binaries or some other custom things I've done. So, there was a time where I had to really learn about how the path shell variable worked on a machine in order to really understand how the packages I installed were sometimes showing up when I invoked a binary and sometimes not. +STEPHANIE: Yeah, that is another really great example that I have memories of [laughs] being really frustrated by, especially if...because, you know, we had talked earlier about all the different ways that you can install applications on your system, and you don't always know where they end up [laughs]. +JOËL: And this particular memory is tied to debugging Postgres because, you know, you're installing Postgres, and some paths aren't working. Or maybe you try to update Postgres and now it's like, oh, but, like, I'm still loading the wrong one. And why does PSQL not do the thing that I think it does? And so, that forced me to learn a little bit about, like, under the hood, what happens when I type brew install PostgreSQL? And how does that mesh with the way my shell interprets commands and things like that? So, it was maybe a little bit of a painful experience but eye-opening and definitely then led to me, I think, being able to debug my setup much more effectively in the future. +STEPHANIE: Yeah. I like that you also pointed out how it was interacting with your shell because that's, like, another can of worms, right? [laughs] In terms of just the complexity of how these things are talking to each other. +JOËL: And for those of our listeners who are not familiar with this, there is a shell command that you can use called which, W-H-I-C-H. And you can prefix that in front of another command, and it will tell you the path that it's using for that binary. So, in my case, if I'm looking like, why is this PSQL behaving weirdly or seems to be using the old version, I can type 'which space psql', and it'll say, "Oh, it's going to this path." +And I can look at it and be like, oh, it's using my system install of Postgres. It's not using the Homebrew one. Or, oh, maybe it's using the Homebrew install, not my Postgres.app version. I need to, like, tinker with the paths a little bit. So, that has definitely helped me debug my package system more than once. +STEPHANIE: Yeah, that's a really good tip. I can recall just totally uninstalling everything [laughs] and reinstalling and fingers crossed it would figure out a route to the right thing [laughs]. +JOËL: You know what? That works. It's not the, like, most precise solution but resetting your environment when all else fails it's not a bad solution. +So, we've been talking a lot about what it's like to interact with a package ecosystem as developers, as users of packages, but what if you're a package developer? Sometimes, there's a very clear-cut place where to publish, and sometimes it's a little bit grayer. So, I could see, you know, I'm developing a database, and I want that to be on operating systems, probably should be a system-level package rather than a Ruby gem. +But what if I'm building some kind of command line tool, and I write it in Ruby because I like writing Ruby? Should I publish that as a gem, or should I publish that as some kind of system package that's installed via Homebrew? Any opinions or heuristics that you would use to choose where to publish on one side or the other? +STEPHANIE: As not a package developer [laughs], I can only answer from that point of view. That is interesting because if you publish on a, you know, like, a system repository, then yeah, like, you might get a lot more people using your tool out there because you're not just targeting a specific language's community. +But I don't know if I have always enjoyed downloading various things to my system's OS. I think that actually, like, is a bit complicated for me or, like, I try to avoid it if I can because if something can be categorized or, like, containerized in a way that, like, feels right for my mental model, you know, if it's written in Ruby or something really related to things I use Ruby in, it could be nice to have that installed in my, like, systems RubyGems. But I would be really interested to hear if other people have opinions about where they might want to publish a package and what kind of developers they're hoping to find to use their tool. +JOËL: I like the heuristic that you mentioned here, the idea of who the audience is because, yeah, as a Ruby developer who already has a Ruby setup, it might be easier for me to install something via a gem. But if I'm not a Ruby developer who wants to use the packages maybe a little bit more generic, you know, let's say, I don't know, it's some sort of command line tool for interacting with GitHub or something like that. And, like, it happens to be written in Ruby, but you don't particularly care about that as a user of this. Maybe you don't have Ruby installed and now you've got to, like, juggle, like, oh, what is RubyGems, and Bundler, and all this stuff? +And I've definitely felt that occasionally downloading packages sort of like, oh, this is a Python package. And you're going to need to, like, set up all this stuff. And it's maybe designed for a Python audience. And so, it's like, oh, you're going to set up a virtual environment and all these things. I'm like, I just want your command line tools. I don't want to install a whole language. And so, sometimes there can be some frustration there. +STEPHANIE: Yeah, that is very true. Before you even said that, I was like, oh, I've definitely wanted to download a command line tool and be like, first install [laughs] Python. And I'm like, nope, I'm bailing out of this. +JOËL: On the other hand, as a developer, it can be a lot harder to write something that's a bit more cross-platform and managing all that. And I've had to deal a little bit with this for thoughtbot's Parity tool, which is a command-line tool for working with Heroku. It allows you to basically run commands on either staging or production by giving you a staging command and a production command for common Heroku CLI tasks, which makes it really nice if you're working and you're having to do some local, some development, some staging, and some production things all from your command line. +It initially started as a gem, and we thought, you know what? This is mostly command line, and it's not just Rubyists who use Heroku. Let's try to put this on Homebrew. But then it depends on Ruby because it's written in Ruby. And now we had to make sure that we marked Ruby as a dependency in Homebrew, which meant that Homebrew would then also pull in Ruby as a dependency. And that got a little bit messy. +For a while, we even experimented with sort of briefly available technology called Traveling Ruby that allowed you to embed Ruby in your binary, and you could compile against that. That had some drawbacks. So, we ended up rolling that back as well. And eventually, just for maintenance ease, we went back to making this a Ruby gem and saying, "Look, you install it via RubyGems." It does mean that we're targeting more of the Ruby community. It's going to be a little bit harder for other people to install, but it is easier for us to maintain. +STEPHANIE: That's really interesting. I didn't know that history about Parity. It's a tool that I have used recently and really enjoyed. But yeah, I think I remember someone having some issues between installing it as a gem and installing it via Homebrew and some conflicts there as well. So, I can also see how trying to decide or maybe going down one path and then realizing, oh, like, maybe we want to try something else is certainly not trivial. +JOËL: I think, in me, I have a little bit of the idealist and the pragmatist that fight. The idealist says, "Hey, if it's not, like, aimed for Ruby developers as a, like, you can pull this into your codebase, if it's just command line tools and the fact that it's written in Ruby is an implementation detail, that should be a system package. Do not distribute binaries via RubyGems." That's the idealist in me. The pragmatist says, "Oh, that's a lot of work and not always worth it for both the maintainers and sometimes for the users, and so it's totally okay to ship binaries as RubyGems." +STEPHANIE: I was totally thinking that I'm sure that you've been in that position of being a user and trying to download a system package and then seeing it start to download, like, another language. And you're like, wait, what? [laughter] That's not what I want. +JOËL: So, you and I have shared some of our heuristics in the way we approach this problem. Now, I'm curious to hear from the audience. What are some heuristics that you use to decide whether your package is better shipped on RubyGems versus, let's say, Homebrew? Or maybe as a user, what do you prefer to consume? +STEPHANIE: Yes. And speaking of getting listener feedback, we're also looking for some listener questions. We're hoping to do a bit of a grab-bag episode where we answer your questions. So, if you have anything that you're wanting to hear me and Joël's thoughts on, write us at hosts@bikeshed.fm. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces.

+ +

Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker.

+ +

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, this week, I got to have some fun working on some internal thoughtbot work. And what I focused on was retiring one of our just, like, small internal self-hosted on Heroku apps in favor of going with a third-party service for this functionality. We basically had a tiny, little app that we used as a link-shortening service. So, if you've ever seen a tbot.io short link out in the world, we were using our just, like, an in-house app to do that, you know, but for various reasons, we wanted to...just it wasn't worth maintaining anymore. So, we wanted to just use a purchased service.

+ +

But today, I got to just, like, do the little bit of, like, tidying up, you know, in preparation to archive a repo and kind of delete the app from Heroku, and I hadn't done that before. So, it felt a little bit celebratory and a little bit mournful even [laughs] to, you know, retire something like that. And I was pairing with another thoughtbot developer, and we used a pairing app called Tuple. And you can just send, like, fun reactions to each other. Like, you could send, like, a fire emoji [laughs] or something if that's what you're feeling.

+ +

And so, I sent some, like, confetti when we clicked the, "I understand what deleting this app means on GitHub." But I joked that "Actually, I feel like what I really needed was a, like, a salute kind of like thank you for your service [laughs] type of reaction."

+ +

JOËL: I love those moments when you're kind of you're hitting those kind of milestone-y moments, and then you get to send a reaction. I should do that more often in Tuple. Those are fun.

+ +

STEPHANIE: They are fun. There's also a, like, table flip reaction, too, is one that I really enjoy [laughs], you know, you just have to manifest that energy somehow. And then, after we kind of sent out an email to the company saying like, "Oh yeah, we're not using our app anymore for link shortening," someone had a great suggestion to make our archived repo public instead of private. I kind of liked it as a way of, like, memorializing this application and let community members see, you know, real code in a real...the application that we used here at thoughtbot. So, hopefully, if not me, then someone else will be able to do that and maybe publish a little blog post about that.

+ +

JOËL: That's exciting. So, it's not currently public, the repo, but it might be at some point in the future.

+ +

STEPHANIE: Yeah, that's right.

+ +

JOËL: We'll definitely have to mention it on a future episode if that happens so that people following along with the story can go check out the code.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been doing a deep dive into how ActiveRecord works. Particularly, I am debugging some pretty significant slowdowns in querying ActiveRecord models that are backed not by a regular Postgres database but instead a Snowflake data warehouse via an ODBC connection. So, there's a bunch of moving pieces going on here, and it would just take forever to make any queries.

+ +

And sure, the actual reported query time is longer than for a local Postgres database, but then there's this sort of mystery extra waiting time, and I couldn't figure out why is it taking so much longer than the actual sort of recorded query time. And I started digging into all of this, and it turns out that in addition to executing queries to pull actual data in, ActiveRecord needs to, at various points, query the schema of your data store to pull things like names of tables and what are the indexes and primary keys and things like that.

+ +

STEPHANIE: Wow. That sounds really cool and something that I have never needed to do before. I'm curious if you noticed...you said that it takes, I guess, longer to query Snowflake than it would a more common Postgres database. Were you noticing this performance slowness locally or on production?

+ +

JOËL: Both places. So, the nice thing is I can reproduce it locally, and locally, I mean running the Rails app locally. I'm still talking to a remote Snowflake data warehouse, which is fine. I can reproduce that slowness locally, which has made it much easier to experiment and try things. And so, from there, it's really just been a bit of a detective case trying to, I guess, narrow the possibility space and try to understand what are the parts that trigger slowness. So, I'm printing timestamps in different places. I've got different things that get measured.

+ +

I've not done, like, a profiling tool to generate a flame graph or anything like that. That might have been something cool to try. I just did old-school print statements in a couple of places where I, like, time before, time after, print the delta, and that's gotten me pretty far.

+ +

STEPHANIE: That's pretty cool. What do you think will be an outcome of this? Because I remember you saying you're digging a little bit into ActiveRecord internals. So, based on, like, what you're exploring, what do you think you could do as a developer to increase some of the performance there?

+ +

JOËL: I think probably what this ends up being is finding that the Snowflake adapter that I'm using for ActiveRecord maybe has some sort of small bug in it or some implementation that's a little bit too naive that needs to be fine-tuned. And so, probably what ends up happening here is that this finishes as, like, an open-source pull request to the Snowflake Adapter gem.

+ +

STEPHANIE: Yeah, that's where I thought maybe that might go. And that's pretty cool, too, and to, you know, just be investigating something on your app and being able to make a contribution that it benefits the community.

+ +

JOËL: And that's what's so great about open source because not only am I able to get the source to go source diving through all of this, because I absolutely need to do that, but also, then if I make a fix, I can push that fix back out to the community, and everybody gets to benefit.

+ +

STEPHANIE: Cool. Well, that's another thing that I look forward to hearing more on the development of [laughs] later if it pans out that way.

+ +

JOËL: One thing that has been interesting with this Snowflake work is that there are a lot of moving parts and multiple different packages that I need to install to get this all to work. So, I mentioned that I might be doing a pull request against the Snowflake Adapter for ActiveRecord, but all of this talks through a sort of lower-level technology protocol called ODBC, which is a sort of generic protocol for speaking to data stores, and that actually has two different pieces. I had to install two different packages.

+ +

There is a sort of low-level executable that I had to install on my local dev machine and that I have to install on our servers. And on my Mac, I'm installing that via Homebrew, which is a system package. And then to get Ruby bindings for that, there is a Ruby gem that I install that allows Ruby code to talk to ODBC, and that's installed via RubyGems or Bundler.

+ +

And that got me thinking about sort of these two separate ecosystems that I tend to work with every day. We've got sort of the system packages and the, I don't know what you want to call them, language packages maybe, things like RubyGems, but that could also be NPM or whatever your language of choice is, and realizing that we kind of have things split into two different zones, and sometimes we need both and wondering a little bit about why is that difference necessary.

+ +

STEPHANIE: Yeah, I don't have an answer to that [laughs] question right now, but I can say that that was an area that really tripped me up, I think, when I was first a fledgling developer. And I was really confused about where all of these dependencies were coming from and going through, you know, setting up my first project and being, like, asked to install Postgres on my machine but then also Bundler, which then also installs more dependencies [laughs].

+ +

The lines between those ecosystems were not super clear to me. And, you know, even now, like, I find myself really just kind of, like, learning what I need to know to get by [laughs] with my day-to-day work. But I do like what you said about these are kind of the two main layers that you're working with in terms of package management. And it's really helpful to have that knowledge so you can troubleshoot when there is an issue at one or the other.

+ +

JOËL: And you mentioned Postgres. That's another one that's interesting because there are components in both of those ecosystems. Postgres itself is typically installed via a system package manager, so something like Homebrew on a Mac or apt-get on a Linux machine. But then, if you're interacting with Postgres in a Ruby app, you're probably also installing the pg gem, which are Ruby's bindings for Postgres to allow Ruby to talk to Postgres, and that lives in the package ecosystem on RubyGems.

+ +

STEPHANIE: Yeah, I've certainly been in the position of, you know, again, as consultants, we oftentimes are also setting up new laptops entirely [laughs] like client laptops and such and bundling and the pg gem is installed. And then at least I have, you know, I have to give thanks to the very clear error message that [laughs] tells me that I don't have Postgres installed on my machine. Because when I mentioned, you know, troubleshooting earlier, I've certainly been in positions where it was really unclear what was going on in terms of the interaction between what I guess we're calling the Ruby package ecosystem and our system level one.

+ +

JOËL: Especially for things like the pg gem, which need to compile against some existing libraries, those always get interesting where sometimes they'll fail to compile because there's a path to some C compiler that's not set correctly or something like that. For me, typically, that means I need to update the macOS command line tools or the Xcode command line tools; I forget what the name of that package is. And, usually, that does the trick. That might happen if I've upgraded my OS version recently and haven't downloaded the latest version of the command line tools.

+ +

STEPHANIE: Yeah. Speaking of OS versions, I have a bit of a story to share about using...I've never said this name out loud, but I am pretty sure that it would just be pronounced as wkhtmltopdf [laughs]. For some reason, whenever I see words like that in my brain, I want to, like, make it into a pronounceable thing [laughs].

+ +

JOËL: Right, just insert some vowels in there.

+ +

STEPHANIE: Yeah, wkhtmltopdf [laughs]. Anyway, that was being used in an app to generate PDF invoices or something. It's a pretty old tool. It's a CLI tool, and it's, as far as I can tell, it's been around for a long time but was recently no longer maintained. And so, as I was working on this app, I was running into a bug where that library was causing some issues with the PDF that was generated. So, I had to go down this route of actually finding a Ruby gem that would figure out which package binary to use, you know, based off of my system. And that worked great locally, and I was like, okay, cool, I fixed the issue.

+ +

And then, once I pushed my change, it turns out that it did not work on CI because CI was running on Ubuntu. And I guess the binary didn't work with the latest version of Ubuntu that was running on CI, so there was just so many incompatibilities there. And I was wanting to fix this bug. But the next step I took was looking into community-provided packages because there just simply weren't any, like, up-to-date binaries that would likely work with these new operating systems. And I kind of stopped at that point because I just wasn't really sure, like, how trustworthy were these community packages. That was an ecosystem I didn't know enough about.

+ +

In particular, I was having to install some using apt from, you know, just, like, some Linux community. But yeah, I think I normally have a little bit more experience and confidence in terms of the Ruby package ecosystem and can tell, like, what gems are popular, which ones are trustworthy. There are different heuristics I have for evaluating what dependency to pull in. But here I ended up just kind of bailing out of that endeavor because I just didn't have enough time to go down that rabbit hole.

+ +

JOËL: It is interesting that learning how to evaluate packages is a skill you have to learn that varies from package community to package community. I know that when I used to be very involved with Elm, we would often have people who would come to the Elm community from the JavaScript community who were used to evaluating NPM packages. And one of the metrics that was very popular in the JavaScript community is just stars on GitHub. That's a really important metric. And that wasn't really much of a thing in the Elm community.

+ +

And so, people would come and be like, "Wait, how do I know which package is good? I don't see any stars on GitHub." And then, it turns out that there are other metrics that people would use. And similarly, you know, in Ruby, there are different ways that you might use to evaluate Ruby gems that may or may not involve stars on GitHub. It might be something entirely different.

+ +

STEPHANIE: Yeah. Speaking of that, I wanted to plug a website that I have used before called the Ruby Toolbox, and that gives some suggestions for open-source Ruby libraries of various categories. So, if you're looking for, like, a JSON parser, it has some of the more popular ones. If you're looking for, you know, it stores them by category, and I think it is also based on things like stars and forks like that, so that's a good one to know.

+ +

JOËL: You could probably also look at something like download numbers to see what's popular, although sometimes it's sort of, like, an emergent gem that's more popular. Some of that almost you just need to be a little bit in the community, like, hearing, you know, maybe listening to podcasts like this one, subscribing to Ruby newsletters, going to conferences, things like that, and to realize, okay, maybe, you know, we had sort of an old staple for JSON parsing, but there's a new thing that's twice as fast. And this is sort of becoming the new standard, and the community is shifting towards that. You might not know that just by looking at raw stats. So, there's a human component to it as well.

+ +

STEPHANIE: Yeah, absolutely. I think an extension of knowing how to evaluate different package systems is this question of like, how much does an average developer need to know about package management? [laughs]

+ +

JOËL: Yeah, a little bit to a medium amount, and then if you're writing your own packages, you probably need to know a little bit more. But there are some things that are really maybe best left to the maintainers of package managers. Package managers are actually pretty complex pieces of software in terms of all of the dependency management and making sure that when you say, "Oh, I've got Rails, and this other gem, and this other gem, and it's going to find the exact versions of all those gems that play nicely together," that's non-trivial.

+ +

As a sort of working developer, you don't need to know all of the algorithms or the graph theory or any of that that underlies a package manager to be able to be productive in your career. And even as a package developer, you probably don't need to really know a whole lot of that.

+ +

STEPHANIE: Yeah, that makes sense. I actually had referred to our internal at thoughtbot here, our kind of, like, expectations for skill levels for developers. And I would say for an average developer, we kind of just expect a basic understanding of these more complex parts of our toolchain, I think, specifically, like, command line tools and package management. And I think I'd mentioned earlier that, for me, it is a very need-to-know basis.

+ +

And so, yeah, when I was going down that little bit of exploration around why wkhtmltopdf [chuckles] wasn't working [chuckles], it was a bit of a twisty and turning journey where I, you know, wasn't really sure where to go. I was getting very obtuse error messages, and, you know, I had to dive deep into all these forums [laughs] for all the various platforms [laughs] about why libraries weren't working.

+ +

And I think what I did come away with was that like, oh, like, even though I'm mostly working on my local machine for development, there was some amount of knowledge I needed to have about the systems that my CI and, you know, production servers are running on. The project I was working on happened to have, like, a Docker file for those environments, and, you know, kind of knowing how to configure them to install the packages I needed to install and just knowing a little bit about the different ways of doing that on systems outside of my usual daily workflows.

+ +

JOËL: And I think that gets back to some of the interesting distinctions between what we might call language packages versus system packages is that language packages more or less work the same across all operating systems. They might have a build step that's slightly different or something like that, but system packages might be pretty different between different operating systems.

+ +

So, development, for me, is a Mac, and I'm probably installing system packages via something like Homebrew. If I then want that Rails app to run on CI or some Linux server somewhere, I can't use Homebrew to install things there. It's going to be a slightly different package ecosystem. And so, now I need to find something that will install Postgres for Linux, something that will install, I guess, wkhtmltopdf [laughs] for Linux.

+ +

And so, when I'm building that Docker file, that might be a little bit different for Mac versus for...or I guess when you run a Docker file, you're running a containerized system. So, the goal there is to make this system the same everywhere for everyone. But when you're setting that up, typically, it's more of a Linux-like system. And so running inside the Docker container versus outside on the native Mac might involve a totally different set of packages and a different package tool. As opposed to something like Bundler, you've got your gem file; you bundle install. It doesn't matter if you're on Linux or macOS.

+ +

STEPHANIE: Yes, I think you're right. I think we kind of answered our own question at the top of the show [laughs] about differences and what do you need to know about them. And I also like how you pointed out, oh yeah, like, Docker is supposed to [laughs], you know, make sure that we're all developing in the same system, essentially. But, you know, sometimes you have different use cases for it.

+ +

And, yeah, when you were talking about installing an application on your native Mac and using Homebrew, but even, you know, not everyone even uses Homebrew, right? You can install manually [laughs] through whatever official installer that application might provide. So, there's just so many different ways of doing something. And I had the thought that it's too bad that we both [chuckles] develop on Mac because it could be really interesting to get a Linux user's perspective in here.

+ +

JOËL: You mentioned not installing via Homebrew. A kind of glaring example of that in my personal setup is that I use Postgres.app to manage Postgres on my machine rather than using Homebrew. I've just...over the years, the Homebrew version every time I upgrade my operating system or something, it's just such a pain to update, and I've lost too many hours to it, and Postgres.app just works, and so I've switched to that. Most other things, I'll use the Homebrew version, but Postgres it's now Postgres.app. It's not even a command line install, and it works fine for me.

+ +

STEPHANIE: Nice. Yeah. That's interesting. That's a good tip. I'll have to look into that next time because I have also certainly had to just install so many [laughs] various versions of Postgres and figure out what's going on with them every time I upgrade my OS. I'm with you, though, in terms of the packages world I'm looking for, it works [laughs].

+ +

JOËL: So, you'd mentioned earlier that packages is sort of an area that's a bit of a need-to-know basis for you. Are there, like, particular moments in your career that you remember like, oh, that's the moment where I needed to, like, take some time and learn a little bit of the next level of packages?

+ +

STEPHANIE: That's a great question. I think the very beginnings of understanding how package versions work when you have multiple projects on your machine; I just remember that being really confusing for me. When I started out, like, you know, as soon as I cloned my second repo [laughs], and was very confused about, like, I'm sure I went through the process of not installing gems using Bundler, and then just having so much chaos [laughs] wrecked in my development environment and, you know, having to ask someone, "I don't understand how this works. Like, why is it saying I have multiple versions of this library or whatever?"

+ +

JOËL: Have you ever sudo gem installed a gem?

+ +

STEPHANIE: Oh yeah, I definitely have. I can't [laughs], like, even give a good reason for why I have done it, but I probably was just, like, pulling my hair out, and that's what Stack Overflow told me to do. I don't know if I can recommend that, but it is [chuckles] one thing to do when you just are kind of totally stuck.

+ +

JOËL: There was a time where I think that that was in the READMEs for most projects.

+ +

STEPHANIE: Yeah, that's a really good point.

+ +

JOËL: So, that's probably why a lot of people end up doing that, but then it tends to install it for your system Ruby rather than for...because if you're using something like Rbenv or RVM or ASDF to manage multiple Ruby versions, those end up being what's using or even Homebrew to manage your Ruby. It wouldn't be installing it for those versions of Ruby. It would be installing it for the one that shipped with your Mac.

+ +

I actually...you know what? I don't even know if Mac still ships with Ruby. It used to. It used to ship with a really old version of Ruby, and so the advice was like, "Hey, every repo tells you to install it with sudo; don't do that. It will mess you up."

+ +

STEPHANIE: Huh. I think Mac still does ship with Ruby, but don't quote me on that [laughter]. And I think that's really funny that, like, yeah, people were just writing those instructions in READMEs. And I'm glad that we've collectively [laughs] figured out that difference and want to, hopefully, not let other developers fall into that trap [laughs]. Do you have a particular memory or experience when you had to kind of level up your knowledge about the package ecosystem?

+ +

JOËL: I think one sort of moment where I really had to level up is when I started really needing to understand how install paths worked, especially when you have, let's say, multiple versions of a gem installed because you have different projects. And you want to know, like, how does it know which one it's using? And then you see, oh, there are different paths that point to different directories with the installs.

+ +

Or when you might have an executable you've installed via Homebrew, and it's like, oh yeah, so I've got this, like, command that I run on my shell, but actually that points to a very particular path, you know, in my Homebrew directory. But maybe it could also point to some, like, pre-installed system binaries or some other custom things I've done. So, there was a time where I had to really learn about how the path shell variable worked on a machine in order to really understand how the packages I installed were sometimes showing up when I invoked a binary and sometimes not.

+ +

STEPHANIE: Yeah, that is another really great example that I have memories of [laughs] being really frustrated by, especially if...because, you know, we had talked earlier about all the different ways that you can install applications on your system, and you don't always know where they end up [laughs].

+ +

JOËL: And this particular memory is tied to debugging Postgres because, you know, you're installing Postgres, and some paths aren't working. Or maybe you try to update Postgres and now it's like, oh, but, like, I'm still loading the wrong one. And why does PSQL not do the thing that I think it does? And so, that forced me to learn a little bit about, like, under the hood, what happens when I type brew install PostgreSQL? And how does that mesh with the way my shell interprets commands and things like that? So, it was maybe a little bit of a painful experience but eye-opening and definitely then led to me, I think, being able to debug my setup much more effectively in the future.

+ +

STEPHANIE: Yeah. I like that you also pointed out how it was interacting with your shell because that's, like, another can of worms, right? [laughs] In terms of just the complexity of how these things are talking to each other.

+ +

JOËL: And for those of our listeners who are not familiar with this, there is a shell command that you can use called which, W-H-I-C-H. And you can prefix that in front of another command, and it will tell you the path that it's using for that binary. So, in my case, if I'm looking like, why is this PSQL behaving weirdly or seems to be using the old version, I can type 'which space psql', and it'll say, "Oh, it's going to this path."

+ +

And I can look at it and be like, oh, it's using my system install of Postgres. It's not using the Homebrew one. Or, oh, maybe it's using the Homebrew install, not my Postgres.app version. I need to, like, tinker with the paths a little bit. So, that has definitely helped me debug my package system more than once.

+ +

STEPHANIE: Yeah, that's a really good tip. I can recall just totally uninstalling everything [laughs] and reinstalling and fingers crossed it would figure out a route to the right thing [laughs].

+ +

JOËL: You know what? That works. It's not the, like, most precise solution but resetting your environment when all else fails it's not a bad solution.

+ +

So, we've been talking a lot about what it's like to interact with a package ecosystem as developers, as users of packages, but what if you're a package developer? Sometimes, there's a very clear-cut place where to publish, and sometimes it's a little bit grayer. So, I could see, you know, I'm developing a database, and I want that to be on operating systems, probably should be a system-level package rather than a Ruby gem.

+ +

But what if I'm building some kind of command line tool, and I write it in Ruby because I like writing Ruby? Should I publish that as a gem, or should I publish that as some kind of system package that's installed via Homebrew? Any opinions or heuristics that you would use to choose where to publish on one side or the other?

+ +

STEPHANIE: As not a package developer [laughs], I can only answer from that point of view. That is interesting because if you publish on a, you know, like, a system repository, then yeah, like, you might get a lot more people using your tool out there because you're not just targeting a specific language's community.

+ +

But I don't know if I have always enjoyed downloading various things to my system's OS. I think that actually, like, is a bit complicated for me or, like, I try to avoid it if I can because if something can be categorized or, like, containerized in a way that, like, feels right for my mental model, you know, if it's written in Ruby or something really related to things I use Ruby in, it could be nice to have that installed in my, like, systems RubyGems. But I would be really interested to hear if other people have opinions about where they might want to publish a package and what kind of developers they're hoping to find to use their tool.

+ +

JOËL: I like the heuristic that you mentioned here, the idea of who the audience is because, yeah, as a Ruby developer who already has a Ruby setup, it might be easier for me to install something via a gem. But if I'm not a Ruby developer who wants to use the packages maybe a little bit more generic, you know, let's say, I don't know, it's some sort of command line tool for interacting with GitHub or something like that. And, like, it happens to be written in Ruby, but you don't particularly care about that as a user of this. Maybe you don't have Ruby installed and now you've got to, like, juggle, like, oh, what is RubyGems, and Bundler, and all this stuff?

+ +

And I've definitely felt that occasionally downloading packages sort of like, oh, this is a Python package. And you're going to need to, like, set up all this stuff. And it's maybe designed for a Python audience. And so, it's like, oh, you're going to set up a virtual environment and all these things. I'm like, I just want your command line tools. I don't want to install a whole language. And so, sometimes there can be some frustration there.

+ +

STEPHANIE: Yeah, that is very true. Before you even said that, I was like, oh, I've definitely wanted to download a command line tool and be like, first install [laughs] Python. And I'm like, nope, I'm bailing out of this.

+ +

JOËL: On the other hand, as a developer, it can be a lot harder to write something that's a bit more cross-platform and managing all that. And I've had to deal a little bit with this for thoughtbot's Parity tool, which is a command-line tool for working with Heroku. It allows you to basically run commands on either staging or production by giving you a staging command and a production command for common Heroku CLI tasks, which makes it really nice if you're working and you're having to do some local, some development, some staging, and some production things all from your command line.

+ +

It initially started as a gem, and we thought, you know what? This is mostly command line, and it's not just Rubyists who use Heroku. Let's try to put this on Homebrew. But then it depends on Ruby because it's written in Ruby. And now we had to make sure that we marked Ruby as a dependency in Homebrew, which meant that Homebrew would then also pull in Ruby as a dependency. And that got a little bit messy.

+ +

For a while, we even experimented with sort of briefly available technology called Traveling Ruby that allowed you to embed Ruby in your binary, and you could compile against that. That had some drawbacks. So, we ended up rolling that back as well. And eventually, just for maintenance ease, we went back to making this a Ruby gem and saying, "Look, you install it via RubyGems." It does mean that we're targeting more of the Ruby community. It's going to be a little bit harder for other people to install, but it is easier for us to maintain.

+ +

STEPHANIE: That's really interesting. I didn't know that history about Parity. It's a tool that I have used recently and really enjoyed. But yeah, I think I remember someone having some issues between installing it as a gem and installing it via Homebrew and some conflicts there as well. So, I can also see how trying to decide or maybe going down one path and then realizing, oh, like, maybe we want to try something else is certainly not trivial.

+ +

JOËL: I think, in me, I have a little bit of the idealist and the pragmatist that fight. The idealist says, "Hey, if it's not, like, aimed for Ruby developers as a, like, you can pull this into your codebase, if it's just command line tools and the fact that it's written in Ruby is an implementation detail, that should be a system package. Do not distribute binaries via RubyGems." That's the idealist in me. The pragmatist says, "Oh, that's a lot of work and not always worth it for both the maintainers and sometimes for the users, and so it's totally okay to ship binaries as RubyGems."

+ +

STEPHANIE: I was totally thinking that I'm sure that you've been in that position of being a user and trying to download a system package and then seeing it start to download, like, another language. And you're like, wait, what? [laughter] That's not what I want.

+ +

JOËL: So, you and I have shared some of our heuristics in the way we approach this problem. Now, I'm curious to hear from the audience. What are some heuristics that you use to decide whether your package is better shipped on RubyGems versus, let's say, Homebrew? Or maybe as a user, what do you prefer to consume?

+ +

STEPHANIE: Yes. And speaking of getting listener feedback, we're also looking for some listener questions. We're hoping to do a bit of a grab-bag episode where we answer your questions. So, if you have anything that you're wanting to hear me and Joël's thoughts on, write us at hosts@bikeshed.fm.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces.

+ +

Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker.

+ +

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, this week, I got to have some fun working on some internal thoughtbot work. And what I focused on was retiring one of our just, like, small internal self-hosted on Heroku apps in favor of going with a third-party service for this functionality. We basically had a tiny, little app that we used as a link-shortening service. So, if you've ever seen a tbot.io short link out in the world, we were using our just, like, an in-house app to do that, you know, but for various reasons, we wanted to...just it wasn't worth maintaining anymore. So, we wanted to just use a purchased service.

+ +

But today, I got to just, like, do the little bit of, like, tidying up, you know, in preparation to archive a repo and kind of delete the app from Heroku, and I hadn't done that before. So, it felt a little bit celebratory and a little bit mournful even [laughs] to, you know, retire something like that. And I was pairing with another thoughtbot developer, and we used a pairing app called Tuple. And you can just send, like, fun reactions to each other. Like, you could send, like, a fire emoji [laughs] or something if that's what you're feeling.

+ +

And so, I sent some, like, confetti when we clicked the, "I understand what deleting this app means on GitHub." But I joked that "Actually, I feel like what I really needed was a, like, a salute kind of like thank you for your service [laughs] type of reaction."

+ +

JOËL: I love those moments when you're kind of you're hitting those kind of milestone-y moments, and then you get to send a reaction. I should do that more often in Tuple. Those are fun.

+ +

STEPHANIE: They are fun. There's also a, like, table flip reaction, too, is one that I really enjoy [laughs], you know, you just have to manifest that energy somehow. And then, after we kind of sent out an email to the company saying like, "Oh yeah, we're not using our app anymore for link shortening," someone had a great suggestion to make our archived repo public instead of private. I kind of liked it as a way of, like, memorializing this application and let community members see, you know, real code in a real...the application that we used here at thoughtbot. So, hopefully, if not me, then someone else will be able to do that and maybe publish a little blog post about that.

+ +

JOËL: That's exciting. So, it's not currently public, the repo, but it might be at some point in the future.

+ +

STEPHANIE: Yeah, that's right.

+ +

JOËL: We'll definitely have to mention it on a future episode if that happens so that people following along with the story can go check out the code.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been doing a deep dive into how ActiveRecord works. Particularly, I am debugging some pretty significant slowdowns in querying ActiveRecord models that are backed not by a regular Postgres database but instead a Snowflake data warehouse via an ODBC connection. So, there's a bunch of moving pieces going on here, and it would just take forever to make any queries.

+ +

And sure, the actual reported query time is longer than for a local Postgres database, but then there's this sort of mystery extra waiting time, and I couldn't figure out why is it taking so much longer than the actual sort of recorded query time. And I started digging into all of this, and it turns out that in addition to executing queries to pull actual data in, ActiveRecord needs to, at various points, query the schema of your data store to pull things like names of tables and what are the indexes and primary keys and things like that.

+ +

STEPHANIE: Wow. That sounds really cool and something that I have never needed to do before. I'm curious if you noticed...you said that it takes, I guess, longer to query Snowflake than it would a more common Postgres database. Were you noticing this performance slowness locally or on production?

+ +

JOËL: Both places. So, the nice thing is I can reproduce it locally, and locally, I mean running the Rails app locally. I'm still talking to a remote Snowflake data warehouse, which is fine. I can reproduce that slowness locally, which has made it much easier to experiment and try things. And so, from there, it's really just been a bit of a detective case trying to, I guess, narrow the possibility space and try to understand what are the parts that trigger slowness. So, I'm printing timestamps in different places. I've got different things that get measured.

+ +

I've not done, like, a profiling tool to generate a flame graph or anything like that. That might have been something cool to try. I just did old-school print statements in a couple of places where I, like, time before, time after, print the delta, and that's gotten me pretty far.

+ +

STEPHANIE: That's pretty cool. What do you think will be an outcome of this? Because I remember you saying you're digging a little bit into ActiveRecord internals. So, based on, like, what you're exploring, what do you think you could do as a developer to increase some of the performance there?

+ +

JOËL: I think probably what this ends up being is finding that the Snowflake adapter that I'm using for ActiveRecord maybe has some sort of small bug in it or some implementation that's a little bit too naive that needs to be fine-tuned. And so, probably what ends up happening here is that this finishes as, like, an open-source pull request to the Snowflake Adapter gem.

+ +

STEPHANIE: Yeah, that's where I thought maybe that might go. And that's pretty cool, too, and to, you know, just be investigating something on your app and being able to make a contribution that it benefits the community.

+ +

JOËL: And that's what's so great about open source because not only am I able to get the source to go source diving through all of this, because I absolutely need to do that, but also, then if I make a fix, I can push that fix back out to the community, and everybody gets to benefit.

+ +

STEPHANIE: Cool. Well, that's another thing that I look forward to hearing more on the development of [laughs] later if it pans out that way.

+ +

JOËL: One thing that has been interesting with this Snowflake work is that there are a lot of moving parts and multiple different packages that I need to install to get this all to work. So, I mentioned that I might be doing a pull request against the Snowflake Adapter for ActiveRecord, but all of this talks through a sort of lower-level technology protocol called ODBC, which is a sort of generic protocol for speaking to data stores, and that actually has two different pieces. I had to install two different packages.

+ +

There is a sort of low-level executable that I had to install on my local dev machine and that I have to install on our servers. And on my Mac, I'm installing that via Homebrew, which is a system package. And then to get Ruby bindings for that, there is a Ruby gem that I install that allows Ruby code to talk to ODBC, and that's installed via RubyGems or Bundler.

+ +

And that got me thinking about sort of these two separate ecosystems that I tend to work with every day. We've got sort of the system packages and the, I don't know what you want to call them, language packages maybe, things like RubyGems, but that could also be NPM or whatever your language of choice is, and realizing that we kind of have things split into two different zones, and sometimes we need both and wondering a little bit about why is that difference necessary.

+ +

STEPHANIE: Yeah, I don't have an answer to that [laughs] question right now, but I can say that that was an area that really tripped me up, I think, when I was first a fledgling developer. And I was really confused about where all of these dependencies were coming from and going through, you know, setting up my first project and being, like, asked to install Postgres on my machine but then also Bundler, which then also installs more dependencies [laughs].

+ +

The lines between those ecosystems were not super clear to me. And, you know, even now, like, I find myself really just kind of, like, learning what I need to know to get by [laughs] with my day-to-day work. But I do like what you said about these are kind of the two main layers that you're working with in terms of package management. And it's really helpful to have that knowledge so you can troubleshoot when there is an issue at one or the other.

+ +

JOËL: And you mentioned Postgres. That's another one that's interesting because there are components in both of those ecosystems. Postgres itself is typically installed via a system package manager, so something like Homebrew on a Mac or apt-get on a Linux machine. But then, if you're interacting with Postgres in a Ruby app, you're probably also installing the pg gem, which are Ruby's bindings for Postgres to allow Ruby to talk to Postgres, and that lives in the package ecosystem on RubyGems.

+ +

STEPHANIE: Yeah, I've certainly been in the position of, you know, again, as consultants, we oftentimes are also setting up new laptops entirely [laughs] like client laptops and such and bundling and the pg gem is installed. And then at least I have, you know, I have to give thanks to the very clear error message that [laughs] tells me that I don't have Postgres installed on my machine. Because when I mentioned, you know, troubleshooting earlier, I've certainly been in positions where it was really unclear what was going on in terms of the interaction between what I guess we're calling the Ruby package ecosystem and our system level one.

+ +

JOËL: Especially for things like the pg gem, which need to compile against some existing libraries, those always get interesting where sometimes they'll fail to compile because there's a path to some C compiler that's not set correctly or something like that. For me, typically, that means I need to update the macOS command line tools or the Xcode command line tools; I forget what the name of that package is. And, usually, that does the trick. That might happen if I've upgraded my OS version recently and haven't downloaded the latest version of the command line tools.

+ +

STEPHANIE: Yeah. Speaking of OS versions, I have a bit of a story to share about using...I've never said this name out loud, but I am pretty sure that it would just be pronounced as wkhtmltopdf [laughs]. For some reason, whenever I see words like that in my brain, I want to, like, make it into a pronounceable thing [laughs].

+ +

JOËL: Right, just insert some vowels in there.

+ +

STEPHANIE: Yeah, wkhtmltopdf [laughs]. Anyway, that was being used in an app to generate PDF invoices or something. It's a pretty old tool. It's a CLI tool, and it's, as far as I can tell, it's been around for a long time but was recently no longer maintained. And so, as I was working on this app, I was running into a bug where that library was causing some issues with the PDF that was generated. So, I had to go down this route of actually finding a Ruby gem that would figure out which package binary to use, you know, based off of my system. And that worked great locally, and I was like, okay, cool, I fixed the issue.

+ +

And then, once I pushed my change, it turns out that it did not work on CI because CI was running on Ubuntu. And I guess the binary didn't work with the latest version of Ubuntu that was running on CI, so there was just so many incompatibilities there. And I was wanting to fix this bug. But the next step I took was looking into community-provided packages because there just simply weren't any, like, up-to-date binaries that would likely work with these new operating systems. And I kind of stopped at that point because I just wasn't really sure, like, how trustworthy were these community packages. That was an ecosystem I didn't know enough about.

+ +

In particular, I was having to install some using apt from, you know, just, like, some Linux community. But yeah, I think I normally have a little bit more experience and confidence in terms of the Ruby package ecosystem and can tell, like, what gems are popular, which ones are trustworthy. There are different heuristics I have for evaluating what dependency to pull in. But here I ended up just kind of bailing out of that endeavor because I just didn't have enough time to go down that rabbit hole.

+ +

JOËL: It is interesting that learning how to evaluate packages is a skill you have to learn that varies from package community to package community. I know that when I used to be very involved with Elm, we would often have people who would come to the Elm community from the JavaScript community who were used to evaluating NPM packages. And one of the metrics that was very popular in the JavaScript community is just stars on GitHub. That's a really important metric. And that wasn't really much of a thing in the Elm community.

+ +

And so, people would come and be like, "Wait, how do I know which package is good? I don't see any stars on GitHub." And then, it turns out that there are other metrics that people would use. And similarly, you know, in Ruby, there are different ways that you might use to evaluate Ruby gems that may or may not involve stars on GitHub. It might be something entirely different.

+ +

STEPHANIE: Yeah. Speaking of that, I wanted to plug a website that I have used before called the Ruby Toolbox, and that gives some suggestions for open-source Ruby libraries of various categories. So, if you're looking for, like, a JSON parser, it has some of the more popular ones. If you're looking for, you know, it stores them by category, and I think it is also based on things like stars and forks like that, so that's a good one to know.

+ +

JOËL: You could probably also look at something like download numbers to see what's popular, although sometimes it's sort of, like, an emergent gem that's more popular. Some of that almost you just need to be a little bit in the community, like, hearing, you know, maybe listening to podcasts like this one, subscribing to Ruby newsletters, going to conferences, things like that, and to realize, okay, maybe, you know, we had sort of an old staple for JSON parsing, but there's a new thing that's twice as fast. And this is sort of becoming the new standard, and the community is shifting towards that. You might not know that just by looking at raw stats. So, there's a human component to it as well.

+ +

STEPHANIE: Yeah, absolutely. I think an extension of knowing how to evaluate different package systems is this question of like, how much does an average developer need to know about package management? [laughs]

+ +

JOËL: Yeah, a little bit to a medium amount, and then if you're writing your own packages, you probably need to know a little bit more. But there are some things that are really maybe best left to the maintainers of package managers. Package managers are actually pretty complex pieces of software in terms of all of the dependency management and making sure that when you say, "Oh, I've got Rails, and this other gem, and this other gem, and it's going to find the exact versions of all those gems that play nicely together," that's non-trivial.

+ +

As a sort of working developer, you don't need to know all of the algorithms or the graph theory or any of that that underlies a package manager to be able to be productive in your career. And even as a package developer, you probably don't need to really know a whole lot of that.

+ +

STEPHANIE: Yeah, that makes sense. I actually had referred to our internal at thoughtbot here, our kind of, like, expectations for skill levels for developers. And I would say for an average developer, we kind of just expect a basic understanding of these more complex parts of our toolchain, I think, specifically, like, command line tools and package management. And I think I'd mentioned earlier that, for me, it is a very need-to-know basis.

+ +

And so, yeah, when I was going down that little bit of exploration around why wkhtmltopdf [chuckles] wasn't working [chuckles], it was a bit of a twisty and turning journey where I, you know, wasn't really sure where to go. I was getting very obtuse error messages, and, you know, I had to dive deep into all these forums [laughs] for all the various platforms [laughs] about why libraries weren't working.

+ +

And I think what I did come away with was that like, oh, like, even though I'm mostly working on my local machine for development, there was some amount of knowledge I needed to have about the systems that my CI and, you know, production servers are running on. The project I was working on happened to have, like, a Docker file for those environments, and, you know, kind of knowing how to configure them to install the packages I needed to install and just knowing a little bit about the different ways of doing that on systems outside of my usual daily workflows.

+ +

JOËL: And I think that gets back to some of the interesting distinctions between what we might call language packages versus system packages is that language packages more or less work the same across all operating systems. They might have a build step that's slightly different or something like that, but system packages might be pretty different between different operating systems.

+ +

So, development, for me, is a Mac, and I'm probably installing system packages via something like Homebrew. If I then want that Rails app to run on CI or some Linux server somewhere, I can't use Homebrew to install things there. It's going to be a slightly different package ecosystem. And so, now I need to find something that will install Postgres for Linux, something that will install, I guess, wkhtmltopdf [laughs] for Linux.

+ +

And so, when I'm building that Docker file, that might be a little bit different for Mac versus for...or I guess when you run a Docker file, you're running a containerized system. So, the goal there is to make this system the same everywhere for everyone. But when you're setting that up, typically, it's more of a Linux-like system. And so running inside the Docker container versus outside on the native Mac might involve a totally different set of packages and a different package tool. As opposed to something like Bundler, you've got your gem file; you bundle install. It doesn't matter if you're on Linux or macOS.

+ +

STEPHANIE: Yes, I think you're right. I think we kind of answered our own question at the top of the show [laughs] about differences and what do you need to know about them. And I also like how you pointed out, oh yeah, like, Docker is supposed to [laughs], you know, make sure that we're all developing in the same system, essentially. But, you know, sometimes you have different use cases for it.

+ +

And, yeah, when you were talking about installing an application on your native Mac and using Homebrew, but even, you know, not everyone even uses Homebrew, right? You can install manually [laughs] through whatever official installer that application might provide. So, there's just so many different ways of doing something. And I had the thought that it's too bad that we both [chuckles] develop on Mac because it could be really interesting to get a Linux user's perspective in here.

+ +

JOËL: You mentioned not installing via Homebrew. A kind of glaring example of that in my personal setup is that I use Postgres.app to manage Postgres on my machine rather than using Homebrew. I've just...over the years, the Homebrew version every time I upgrade my operating system or something, it's just such a pain to update, and I've lost too many hours to it, and Postgres.app just works, and so I've switched to that. Most other things, I'll use the Homebrew version, but Postgres it's now Postgres.app. It's not even a command line install, and it works fine for me.

+ +

STEPHANIE: Nice. Yeah. That's interesting. That's a good tip. I'll have to look into that next time because I have also certainly had to just install so many [laughs] various versions of Postgres and figure out what's going on with them every time I upgrade my OS. I'm with you, though, in terms of the packages world I'm looking for, it works [laughs].

+ +

JOËL: So, you'd mentioned earlier that packages is sort of an area that's a bit of a need-to-know basis for you. Are there, like, particular moments in your career that you remember like, oh, that's the moment where I needed to, like, take some time and learn a little bit of the next level of packages?

+ +

STEPHANIE: That's a great question. I think the very beginnings of understanding how package versions work when you have multiple projects on your machine; I just remember that being really confusing for me. When I started out, like, you know, as soon as I cloned my second repo [laughs], and was very confused about, like, I'm sure I went through the process of not installing gems using Bundler, and then just having so much chaos [laughs] wrecked in my development environment and, you know, having to ask someone, "I don't understand how this works. Like, why is it saying I have multiple versions of this library or whatever?"

+ +

JOËL: Have you ever sudo gem installed a gem?

+ +

STEPHANIE: Oh yeah, I definitely have. I can't [laughs], like, even give a good reason for why I have done it, but I probably was just, like, pulling my hair out, and that's what Stack Overflow told me to do. I don't know if I can recommend that, but it is [chuckles] one thing to do when you just are kind of totally stuck.

+ +

JOËL: There was a time where I think that that was in the READMEs for most projects.

+ +

STEPHANIE: Yeah, that's a really good point.

+ +

JOËL: So, that's probably why a lot of people end up doing that, but then it tends to install it for your system Ruby rather than for...because if you're using something like Rbenv or RVM or ASDF to manage multiple Ruby versions, those end up being what's using or even Homebrew to manage your Ruby. It wouldn't be installing it for those versions of Ruby. It would be installing it for the one that shipped with your Mac.

+ +

I actually...you know what? I don't even know if Mac still ships with Ruby. It used to. It used to ship with a really old version of Ruby, and so the advice was like, "Hey, every repo tells you to install it with sudo; don't do that. It will mess you up."

+ +

STEPHANIE: Huh. I think Mac still does ship with Ruby, but don't quote me on that [laughter]. And I think that's really funny that, like, yeah, people were just writing those instructions in READMEs. And I'm glad that we've collectively [laughs] figured out that difference and want to, hopefully, not let other developers fall into that trap [laughs]. Do you have a particular memory or experience when you had to kind of level up your knowledge about the package ecosystem?

+ +

JOËL: I think one sort of moment where I really had to level up is when I started really needing to understand how install paths worked, especially when you have, let's say, multiple versions of a gem installed because you have different projects. And you want to know, like, how does it know which one it's using? And then you see, oh, there are different paths that point to different directories with the installs.

+ +

Or when you might have an executable you've installed via Homebrew, and it's like, oh yeah, so I've got this, like, command that I run on my shell, but actually that points to a very particular path, you know, in my Homebrew directory. But maybe it could also point to some, like, pre-installed system binaries or some other custom things I've done. So, there was a time where I had to really learn about how the path shell variable worked on a machine in order to really understand how the packages I installed were sometimes showing up when I invoked a binary and sometimes not.

+ +

STEPHANIE: Yeah, that is another really great example that I have memories of [laughs] being really frustrated by, especially if...because, you know, we had talked earlier about all the different ways that you can install applications on your system, and you don't always know where they end up [laughs].

+ +

JOËL: And this particular memory is tied to debugging Postgres because, you know, you're installing Postgres, and some paths aren't working. Or maybe you try to update Postgres and now it's like, oh, but, like, I'm still loading the wrong one. And why does PSQL not do the thing that I think it does? And so, that forced me to learn a little bit about, like, under the hood, what happens when I type brew install PostgreSQL? And how does that mesh with the way my shell interprets commands and things like that? So, it was maybe a little bit of a painful experience but eye-opening and definitely then led to me, I think, being able to debug my setup much more effectively in the future.

+ +

STEPHANIE: Yeah. I like that you also pointed out how it was interacting with your shell because that's, like, another can of worms, right? [laughs] In terms of just the complexity of how these things are talking to each other.

+ +

JOËL: And for those of our listeners who are not familiar with this, there is a shell command that you can use called which, W-H-I-C-H. And you can prefix that in front of another command, and it will tell you the path that it's using for that binary. So, in my case, if I'm looking like, why is this PSQL behaving weirdly or seems to be using the old version, I can type 'which space psql', and it'll say, "Oh, it's going to this path."

+ +

And I can look at it and be like, oh, it's using my system install of Postgres. It's not using the Homebrew one. Or, oh, maybe it's using the Homebrew install, not my Postgres.app version. I need to, like, tinker with the paths a little bit. So, that has definitely helped me debug my package system more than once.

+ +

STEPHANIE: Yeah, that's a really good tip. I can recall just totally uninstalling everything [laughs] and reinstalling and fingers crossed it would figure out a route to the right thing [laughs].

+ +

JOËL: You know what? That works. It's not the, like, most precise solution but resetting your environment when all else fails it's not a bad solution.

+ +

So, we've been talking a lot about what it's like to interact with a package ecosystem as developers, as users of packages, but what if you're a package developer? Sometimes, there's a very clear-cut place where to publish, and sometimes it's a little bit grayer. So, I could see, you know, I'm developing a database, and I want that to be on operating systems, probably should be a system-level package rather than a Ruby gem.

+ +

But what if I'm building some kind of command line tool, and I write it in Ruby because I like writing Ruby? Should I publish that as a gem, or should I publish that as some kind of system package that's installed via Homebrew? Any opinions or heuristics that you would use to choose where to publish on one side or the other?

+ +

STEPHANIE: As not a package developer [laughs], I can only answer from that point of view. That is interesting because if you publish on a, you know, like, a system repository, then yeah, like, you might get a lot more people using your tool out there because you're not just targeting a specific language's community.

+ +

But I don't know if I have always enjoyed downloading various things to my system's OS. I think that actually, like, is a bit complicated for me or, like, I try to avoid it if I can because if something can be categorized or, like, containerized in a way that, like, feels right for my mental model, you know, if it's written in Ruby or something really related to things I use Ruby in, it could be nice to have that installed in my, like, systems RubyGems. But I would be really interested to hear if other people have opinions about where they might want to publish a package and what kind of developers they're hoping to find to use their tool.

+ +

JOËL: I like the heuristic that you mentioned here, the idea of who the audience is because, yeah, as a Ruby developer who already has a Ruby setup, it might be easier for me to install something via a gem. But if I'm not a Ruby developer who wants to use the packages maybe a little bit more generic, you know, let's say, I don't know, it's some sort of command line tool for interacting with GitHub or something like that. And, like, it happens to be written in Ruby, but you don't particularly care about that as a user of this. Maybe you don't have Ruby installed and now you've got to, like, juggle, like, oh, what is RubyGems, and Bundler, and all this stuff?

+ +

And I've definitely felt that occasionally downloading packages sort of like, oh, this is a Python package. And you're going to need to, like, set up all this stuff. And it's maybe designed for a Python audience. And so, it's like, oh, you're going to set up a virtual environment and all these things. I'm like, I just want your command line tools. I don't want to install a whole language. And so, sometimes there can be some frustration there.

+ +

STEPHANIE: Yeah, that is very true. Before you even said that, I was like, oh, I've definitely wanted to download a command line tool and be like, first install [laughs] Python. And I'm like, nope, I'm bailing out of this.

+ +

JOËL: On the other hand, as a developer, it can be a lot harder to write something that's a bit more cross-platform and managing all that. And I've had to deal a little bit with this for thoughtbot's Parity tool, which is a command-line tool for working with Heroku. It allows you to basically run commands on either staging or production by giving you a staging command and a production command for common Heroku CLI tasks, which makes it really nice if you're working and you're having to do some local, some development, some staging, and some production things all from your command line.

+ +

It initially started as a gem, and we thought, you know what? This is mostly command line, and it's not just Rubyists who use Heroku. Let's try to put this on Homebrew. But then it depends on Ruby because it's written in Ruby. And now we had to make sure that we marked Ruby as a dependency in Homebrew, which meant that Homebrew would then also pull in Ruby as a dependency. And that got a little bit messy.

+ +

For a while, we even experimented with sort of briefly available technology called Traveling Ruby that allowed you to embed Ruby in your binary, and you could compile against that. That had some drawbacks. So, we ended up rolling that back as well. And eventually, just for maintenance ease, we went back to making this a Ruby gem and saying, "Look, you install it via RubyGems." It does mean that we're targeting more of the Ruby community. It's going to be a little bit harder for other people to install, but it is easier for us to maintain.

+ +

STEPHANIE: That's really interesting. I didn't know that history about Parity. It's a tool that I have used recently and really enjoyed. But yeah, I think I remember someone having some issues between installing it as a gem and installing it via Homebrew and some conflicts there as well. So, I can also see how trying to decide or maybe going down one path and then realizing, oh, like, maybe we want to try something else is certainly not trivial.

+ +

JOËL: I think, in me, I have a little bit of the idealist and the pragmatist that fight. The idealist says, "Hey, if it's not, like, aimed for Ruby developers as a, like, you can pull this into your codebase, if it's just command line tools and the fact that it's written in Ruby is an implementation detail, that should be a system package. Do not distribute binaries via RubyGems." That's the idealist in me. The pragmatist says, "Oh, that's a lot of work and not always worth it for both the maintainers and sometimes for the users, and so it's totally okay to ship binaries as RubyGems."

+ +

STEPHANIE: I was totally thinking that I'm sure that you've been in that position of being a user and trying to download a system package and then seeing it start to download, like, another language. And you're like, wait, what? [laughter] That's not what I want.

+ +

JOËL: So, you and I have shared some of our heuristics in the way we approach this problem. Now, I'm curious to hear from the audience. What are some heuristics that you use to decide whether your package is better shipped on RubyGems versus, let's say, Homebrew? Or maybe as a user, what do you prefer to consume?

+ +

STEPHANIE: Yes. And speaking of getting listener feedback, we're also looking for some listener questions. We're hoping to do a bit of a grab-bag episode where we answer your questions. So, if you have anything that you're wanting to hear me and Joël's thoughts on, write us at hosts@bikeshed.fm.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+HXZFlUjI + + ]]> + + Joël Quenneville + Stephanie Minn + + + 412: Vertical Slices + https://bikeshed.thoughtbot.com/412 + dbe4b960-530b-440b-9f02-c20d90364c2a + Tue, 16 Jan 2024 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël shares a unique, time-specific bug he encountered, which causes a page to crash only in January. This bug has been fixed in previous years, only to reemerge due to subsequent changes. Stephanie talks about her efforts to bring more structure to her work-from-home environment. She describes how setting up a bird feeder near her desk and keeping chocolates at her desk serve as incentives to work more from her desk. + +Together, Stephanie and Joël take a deep dive into the challenges of breaking down software development tasks into smaller, more manageable chunks. They explore the concept of 'vertical slice' development, where features are implemented in thin, fully functional segments, contrasting it with the more traditional 'horizontal slice' approach. This discussion leads to insights on collaborative work, the importance of iterative development, and strategies for efficient and effective software engineering. + 32:23 + no + + + Joël shares a unique, time-specific bug he encountered, which causes a page to crash only in January. This bug has been fixed in previous years, only to reemerge due to subsequent changes. Stephanie talks about her efforts to bring more structure to her work-from-home environment. She describes how setting up a bird feeder near her desk and keeping chocolates at her desk serve as incentives to work more from her desk. +Together, Stephanie and Joël take a deep dive into the challenges of breaking down software development tasks into smaller, more manageable chunks. They explore the concept of 'vertical slice' development, where features are implemented in thin, fully functional segments, contrasting it with the more traditional 'horizontal slice' approach. This discussion leads to insights on collaborative work, the importance of iterative development, and strategies for efficient and effective software engineering. +thoughtbot Live Streams (https://www.youtube.com/@thoughtbot/streams?themeRefresh=1) +Stephanie’s Live Stream (https://www.youtube.com/watch?v=jWmCOMbOxTs) +Joël’s Talk on Time (https://www.youtube.com/watch?v=54Hs2E7zsQg) +Finish the Owl Meme (https://knowyourmeme.com/photos/572078-how-to-draw-an-owl) +Full Stack Slices (https://thoughtbot.com/blog/break-apart-your-features-into-full-stack-slices) +Elephant Carpaccio (https://blog.crisp.se/2013/07/25/henrikkniberg/elephant-carpaccio-facilitation-guide) +Outside-in Feature Development (https://thoughtbot.com/blog/testing-from-the-outsidein) +Working Iteratively (https://thoughtbot.com/blog/working-iteratively) +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 in the year 2024? +JOËL: Yeah, it's 2024. New year, new me. Or, in this case, maybe new year, new bugs? I'm working on a project where I ran into a really interesting time-specific bug. This particular page on the site only crashes in the month of January. There's some date logic that has a weird boundary condition there, and if you load that page during the month of January, it will crash, but during the entire rest of the year, it's fine. +STEPHANIE: That's a fun New Year's tradition for this project [laughs], fixing this bug [laughs] every year. +JOËL: It's been interesting because I looked a little bit at the git history of this bug, and it looks like it's been fixed in past Januarys, but then the fix changes the behavior slightly, so people bring the behavior back correct during the rest of the year that also happens to reintroduce the bug in January, and now I'm back to fixing it in January. So, it is a little bit of a tradition. +STEPHANIE: Yeah, that is really funny. I was also recently debugging something, and we were having some flakiness with a test that we wrote. And we were trying to figure out because we had some date/time logic as well. And we were like, is there anything strange about this current time period that we are in that would potentially, you know, lead to a flaky test? +And we were looking at the clock and we're like, "I don't think it's like, you know, midnight UTC or anything [laughs] like that." But, I mean, I don't know. It's like, how could you possibly think of, like, all of the various weird edge cases, you know, related to that kind of thing? I don't think I would ever be like, huh, it's January, so, surely, that must [laughs] mean that that's this particular edge case I'm seeing. +JOËL: It's interesting because I feel like there's a couple of types of time-specific bugs that we see pretty frequently. If you're near the daylight savings boundary, let's say a week before sometimes, or whatever you're...if you're doing, like, a week from now logic or something like that, typically, I'll see failures in the test suite or maybe actual crashes in the code a week before springing forward and a week before falling back. And then, like you said, sometimes you see failures at the end of the day, Eastern time for me, when you approach that midnight UTC time boundary. I think this is the first time I've seen a failure in January due to the month being, like, a month boundary...or it's a year boundary really is what's happening. +STEPHANIE: Yeah. That just sounds like another [laughs] thing you have to look out for. I'm curious: are you going to fix this bug for real or leave it for [laughs] 2025? +JOËL: I've got a fix that I think is for real and that, like, not only fixes the break in January but also during the rest of the year gives the desired behavior. I think part of what's really interesting about this bug is that there are some subtle behavioral changes between a few different use cases where this code is called, part of which depend on when in the year you're calling it and whether you want to see it for today's date versus you can also specify a date that you want to see this report. And so, it turns out that there are a lot more edge cases than might be initially obvious. +So, this turned into effectively a product discussion, and realizing, wait a minute, the code isn't telling the full story. There's more at a product level we need to discuss. And actually, I think I learned a lot about the product there. So, while it was maybe a surprising and kind of humorous bug to come across, I think it was actually a really good experience. +STEPHANIE: Nice. That's awesome. That's a pretty good way to start the year, I would say. +JOËL: I'd say so. How about you? What's new in your world? +STEPHANIE: So, I don't know, I think towards the end of the year, last year, I was in a bit of a slump where I was in that work-from-couch phase of [laughs] the year, you know, like, things are slowing down and I, you know, winter was starting here. I wanted to be cozy, so I'd, you know, set up on the couch with a blanket. +And I realized that I really wasn't sitting at my desk at all, and I kind of wanted to bring a little bit of that structure back into my workday, so I [chuckles] added some incentives for me to sit at my desk, which include I recently got a bird feeder that attaches to the window in my office. So, when I sit at my desk, I can hopefully see some birds hanging out. +They are very flighty, so I've only seen birds when I'm, like, in the other room. And I'm like, oh, like, there's a bird at the bird feeder. Like, let me get up close to, like, get to admire them. And then as soon as I, like [laughs], get up close to the window, they fly away. So, I'm hoping that if I sit at my desk more, I'll spontaneously see more birds, and maybe they'll get used to, like, a presence closer to the window. And then my second incentive is I now have little chocolates at my desk [laughs]. +JOËL: Nice. +STEPHANIE: I've just been enjoying, like, a little treat and trying to keep them as a...okay, I've worked at my desk for an hour, and now I get a little reward for that [laughs]. +JOËL: I like that. Do you know what kind of species of birds have been coming to your feeder? +STEPHANIE: Ooh, yes. So, we got this birdseed mix called Cardinal and Friends [laughs]. +JOËL: I love that. +STEPHANIE: So, I have seen, like, a really beautiful red male cardinal come by. We get some robins and some chickadees, I think. Part of what I'm excited for this winter is to learn more how to identify more bird species. And I usually like to be out in nature and stuff, and winter is a hard time to do that. So, this is kind of my way of [chuckles] bringing that more into my life during the season. +So, this is our first episode after a little bit of a break for the holidays. There actually has been some content of ours that has been published out in the world on the internet [laughs] during this time. And just wanted to point out in the few weeks that there weren't any Bike Shed episodes, I ended up doing a thoughtbot Rails development livestream with thoughtbot CEO Chad Pytel, and that was my first-time live streaming code [laughs]. +And it was a really cool experience. I'm glad I had this podcast experience. So, I'm like, okay, well I have, you know, that, like, ability to do stuff kind of off script and present in the moment. But yeah, that was a really cool thing that I got to do, and I feel a little bit more confident about doing those kinds in the future. +JOËL: And for those who are not aware, Chad does–I think it's a weekly live stream on Fridays where he's doing various types of code. So, he's done some work on some internal projects. He did a series where he upgraded, I think, a Rails 2 app all the way to Rails 7, typically with a guest who's another teammate from thoughtbot working on a thing. So, for those of our listeners that might find interesting, we'll put a link in the show notes where you can go see that. I think it's on YouTube and on Twitch. +STEPHANIE: Yes. +JOËL: What did you pair on? What kind of project were you doing for the livestream? +STEPHANIE: So, we were working on thoughtbot's internal application called Hub, which is where we have, like, our internal messaging features. It's where we do a lot of our business operations-y things [laughs]. So, all of the, like, agency work that we do, we use our in-house software for that, and so Chad and I were working on a feature to introduce something that would help out with how we staff team members on projects. +In other content news [laughs], Joël, I think you have something to share as well. +JOËL: Yeah. So, we've mentioned on past episodes that I gave a talk at RubyConf this past November all about what the concept of time actually means within a program and the different ways of representing it, and the fact that time isn't really a single thing but actually kind of multiple related quantities. And over the holiday break, the talks from that conference got published. I'm pretty excited that that is now out there. We'd mentioned that as a highlight in the previous episode, highlighting accomplishments for the year, but it just wasn't quite out yet. We couldn't link it there. So, I'll leave a link in the show notes for this episode for anyone who's interested in seeing that. +STEPHANIE: Sounds like that talk is also timely for a debug you -- +JOËL: Ha ha ha! +STEPHANIE: Were also mentioning earlier in the episode. So, a few episodes ago, I believe we mentioned that we had recently had, like, our company internal hackathon type thing where we have two days to get together and work with team members who we might not normally work with and get some cool projects started or do some team bonding, that kind of thing. +And since I'm still, you know, unbooked on client work, I've been doing a lot of internal thoughtbot stuff, like continuing to work on the Hub app I mentioned just a bit ago. And from the hackathon, there was some work that was unfinished by, like, a project team that I decided to pick up this week as part of my internal work. +And as I was kind of trying to gauge how much progress was made and, like, what was left to accomplish to get it over the finish line so it could be shipped, I noticed that because there were a couple of different people working on it, they had broken up this feature which was basically introducing, like, a new report for one of our teams to get some data on how certain projects are going. +And there was, like, a UI portion and then some back-end portion, and then part of the back-end portion also involved a bit of a complex query that was pulled out as a separate ticket on its own. And so, all of those things were slightly, you know, were mostly done but just needed those, like, finishing touches, and then it also needed to come together. +And I ended up pairing on this with another thoughtboter, and we spent the same amount of time that the hackathon was, so two days. We spent those two days on that, like, aspect of putting it all together. And I think I was a bit surprised by how much work that was, you know, we had kind of assumed that like, oh, like, all these pieces are mostly finished, but then the bulk of what we spended our time doing was integrating the components together. +JOËL: Does this feel like a bit of a finish the rest of the OWL meme? +STEPHANIE: What is that meme? I'm not familiar with it, but now I really want to know [laughs]. +JOËL: It's a meme kind of making fun of some of these drawing tutorials where they're like, oh; first you draw, like, three circles. +STEPHANIE: [laughs] +JOËL: And then just finish the rest of the owl. +STEPHANIE: [laughs] +JOËL: And I was thinking of this beautifully drawn picture. +STEPHANIE: Oh, that's so funny. Okay, yeah, I can see it in my head [laughs] now. It's like how to go from three circles, you know, to a recognizable [laughs] owl animal. +JOËL: So, especially, they're like, oh, you know, like, we put in all the core classes and everything. It's all just basically there. You just need to connect it all together, and it's basically done [laughs]. And then you spend a lot of time actually getting that what feels like maybe the last 20 or 10% but takes maybe 80% of the time. +STEPHANIE: Yeah, that sounds about right. So, you know, kind of working on that got me thinking about the alternative, which is honestly something that I'm still working on getting better at doing in my day-to-day. But there is this idea of a vertical slice or a full-stack slice, and that, basically, involves splitting a large feature into those full-stack slices. So, you have, like, a fully implemented piece rather than breaking them apart by layers of the stack. +So, you know, I just see pretty frequently that, like, maybe you'll have a back-end ticket to do the database migration, to create your models, just whatever, maybe your controllers, or maybe that is even, like, another piece and then, like, the UI component. And those are worked on separately, maybe even by different people. But this vertical slice theory talks about how what you really want is to have a very thin piece of the feature that still delivers value but fully works. +JOËL: As opposed to what you might call a horizontal slice, which would be something like, oh, I've built three Rails models. They're there. They're in the code. They talk to tables in the database, but there's nothing else happening with them. So, you've done work, but it's also more or less dead code. +STEPHANIE: Yeah, that's a good point. I have definitely seen a lot of unused code paths [laughs] when you kind of go about it that way and maybe, like, that UI ticket never gets completed. +JOËL: What are some tips for trying to do some of these narrower slices? Like, I have a ticket, and I have some work I need to do. And I want to break it down because I know it's going to be too big, and maybe the, like, intuitive way to do it is to split it by layers of your stack where I might do all the models, commit, ship that, deploy, then do some controllers, then do some view, or something like that, and you're suggesting instead going full stack. How do you break down the ticket more when all the pieces are interrelated? +STEPHANIE: Yeah, that's a great point. One easy way to visualize it, especially if you have designs or something for this feature, right? Oftentimes, you can start to parse out sections or components of the user interface to be shipped separately. Like, yes, you would want all of it to have that rich feature, but if it's a view of some cards or something, and then, yeah, there's, like, the you can filter by them. You can search by them. All of those bits can be broken up to be like, well, like, the very basic thing that a customer would want to see is just that list of cards, and you can start there. +JOËL: So, aggressively breaking down the card at, like, almost a product level. Instead of breaking it down by technical pieces, say, like, can we get even smaller amounts of behavior while still delivering value? +STEPHANIE: Yeah, yeah, exactly. I like that you said product level because I think another axis of that could also be complexity. So, oftentimes, you know, I'll get a feature, and we're like, oh, we want to support these X number of things that we've identified [laughs]. You know, if it's like an e-com app you're building, you know, you're like, "Do we have all these products that we want to make sure to support?" And, you know, one way to break that down into that vertical slice is to ask, like, what if we started with just supporting one before we add variants or something like that? +Teasing out, like, what would end up being the added complexity as you're developing, once you have to start considering multiple parameters, I think that is a good way to be able to start working more iteratively. And so, you don't have to hold all of that complexity in your head. +JOËL: It's almost a bit of like a YAGNI principle but applied to features rather than to code. +STEPHANIE: Yeah. Yeah. I like that. At first, I hesitated a little bit because I've certainly been in the position where someone has said like, "Well, we do really need this [laughs]." +JOËL: Uh-huh. And, sometimes, the answer is, yes, we do need that, but what if I gave you a smaller version of that today, and we can do the other thing tomorrow? +STEPHANIE: Right. Yeah, it's not like you're rejecting the idea that it's necessary but the way that you get about to that end result, right? +JOËL: So, you keep using the term vertical slice or full-stack slice. I think when I hear that term, I think of specifically an article written by former thoughtboter, German Velasco, on our blog. But I don't know if that's maybe a term that has broader use in the industry. Is that a term that you've heard elsewhere? +STEPHANIE: That's a good question. I think I mostly hear, you know, some form of like, "Can we break this ticket down further?" and not necessarily, like, if you think about how, right? I'm, like, kind of doing a motion with my hand [chuckles] of, like, slicing from top to bottom as opposed to, you know, horizontal. +Yeah, I think that it may not be as common as I wish it were. Even if there's still some amount of adapting or, like, persuading your team members to get on board with this idea, like, I would be interested in, like, introducing that concept or that vocabulary to get teams talking about, like, how do they break down tickets? You know, like, what are they considering? Like, what alternatives are there? Like, are horizontal slices working for them or not? +JOËL: A term that I've heard floating around and I haven't really pinned down is Elephant Carpaccio. Have you heard that before? +STEPHANIE: I have, only because I, like, discovered a, like, workshop facilitation guide to run an exercise that is basically, like, helping people learn how to identify, like, smaller and smaller full-stack slices. But with the Elephant Carpaccio analogy, it's kind of like you're imagining a feature as big as an elephant. And you can create, like, a really thin slice out of them, and you can have infinite number of slices, but they still end up creating this elephant. And I guess you still get the value of [chuckles] a little carpaccio, a delicious [laughs] appetizer of thinly sliced meat. +JOËL: I love a colorful metaphor. So, I'm curious: in your own practice, do you have any sort of guidelines or even heuristics that you like to use to help work in a more, I guess, iterative fashion by working with these smaller slices? +STEPHANIE: Yeah, one thought that I had about it is that it plays really well with Outside-In Test Driven Development. +JOËL: Hmmm. +STEPHANIE: Yeah. So, if, you know, you are starting with a feature test, you have to start somewhere and, you know, maybe starting with, like, the most valuable piece of the feature, right? And you are starting at that level of user interaction if you're using Capybara, for example. And then it kind of forces you to drop down deeper into those layers. +But once you go through that whole process of outside-in and then you arrive back to the top, you've created your full-stack feature [laughs], and that is shippable or, like, committable and, you know, potentially even shippable in and of itself. And you already have full test coverage with it. And that was a cool way that I saw some of those two concepts work well together. +JOËL: Yeah, there is something really fun about the sort of Red-Green-Refactor cycle that TDD forces on you and that you're typically writing the minimum code required to pass a test. And it really forces you out of that developer brain where you're just like, oh, I've got to cover my edge cases. I've got to engineer for some things. And then maybe you realize you've written code that wasn't necessary. And so, I've found that often when I do, like, actually TDD a feature, I end up with code that's a lot leaner than I would otherwise. +STEPHANIE: Yes, lean like a thin slice of Elephant Carpaccio. +[laughter] +JOËL: One thing you did mention that I wanted to highlight was the fact that when you do this outside-in approach for your tiny slice, at the end, it is shippable. And I think that is a core sort of tenet of this idea is that even though you're breaking things down into smaller and smaller slices, every slice is shippable to production. Like, it doesn't break the build. It doesn't break the website. And it provides some kind of value to the user. +STEPHANIE: Yeah, absolutely. I think one thing that I still kind of get hung up on sometimes, and I'm trying to, you know, revisit this assumption is that idea of, like, is this too small? Like, is this valuable enough? When I mentioned earlier that I was working on a report, I think there was a part of me that's like, could I just ship a report with two columns [laughs]? And the answer is yes, right? Like, I thought about it, and I was like, well, if that data is, like, not available anywhere else, then, yeah, like, that would be valuable to just get out there. +But I think the idea that, like, you know, originally, the hope was to have all of these things, these pieces of information, you know, available through this report, I think that, like, held me back a little bit from wanting to break it down. And I held it a little bit too closely and to be like, well, I really want to, like, you know, deliver something impressive. When you click on it, it's like, wow, like, look at all this data [laughs]. So, I'm trying to push back a little bit on my own preconceived notions that, like, there is such a thing as, like, a too small of a demo. +JOËL: I've often worked with this at a commit level, trying to see, like, how small can I get a commit, and what is too small? And now you get into sort of the fraught question of what is a, you know, atomic commit? And I think, for me, where I've sort of come down is that a commit must pass CI. Like, I don't want a commit that's going to go into the main branch. I'm totally pro-work-in-progress commits on a branch; that's fine. But if it's going to get shipped into the main branch, it needs to be green. And it also cannot introduce dead code. +STEPHANIE: Ooh. +JOËL: So, if you're getting to the point where you're breaking either of those, you've got some sort of, like, partial commit that's maybe too small that needs more to be functional. Or you maybe need to restructure to say, look, instead of adding just ten models, can I add one model but also a little bit of a controller and a view? And now I've got a vertical slice. +STEPHANIE: Yeah, which might even be less code [laughs] in the end. +JOËL: Yes, it might be less code. +STEPHANIE: I really like that heuristic of not introducing dead code, that being a goal. I'm going to think about that a lot [laughs] and try to start introducing that into when I think something is ready. +JOËL: Another thing that I'll often do, I guess, that's almost like it doesn't quite fit in the slice metaphor, but it's trying to separate out any kind of refactor work into its own commit that is, you know, still follows those rules: it does not introduce dead code; it does not break the build; it's independently shippable. But that might be something that I do that sets me up for success when I want to do that next slice. +So, maybe I'm trying to add a new feature, but just the way we built some of the internal models, they don't have the interface that I need right now, and that's fine because I don't want to build these models in anticipation of the future. I can change them in the future if I need. But now the future has come, and I need a slightly different shape. So, I start by refactoring, commit, maybe even ship that deploy. Maybe I then do my small feature afterwards. Maybe I come back next week and do the small feature, but there are two independent things, two different commits, maybe two different deploys. +I don't know that I would call that refactor a slice and that it maybe goes across the full stack; maybe it doesn't. It doesn't show to the user because a refactor, by definition, is just changing the implementation without changing behavior. But I do like to break that out and keep it separate. And I guess it helps keep my slices lean, but I'm not quite sure where refactors fit into this metaphor. +STEPHANIE: Yeah, that's interesting because, in my head, as I was listening to you talk about that, I was visualizing the owl again, the [laughs] owl meme. And I'm imagining, like, the refactoring making the slice richer, right? It's like you're adding details, and you're...it's like when you end up with the full animal, or the owl, the elephant, whatever, it's not just, like, a shoddy-looking drawing [laughs]. Like, ideally, you know, it has those details. Maybe it has some feathers. It's shaded in, and it is very fleshed out. That's just my weird, little brain trying [laughs] to stretch this metaphor to make it work. +Another thing that I want to kind of touch a little bit more about when we're talking about how a lot of the work I was spending recently was that glue work, you know, the putting the pieces together, I think there was some aspect of discovery involved that was missed the first time around when these tickets were broken up more horizontally. I think that one really important piece that I was doing was trying to reconcile the different mental models that each person had when they were working on their separate piece. +And so, maybe there's, like, an API, and then the frontend is expecting some sort of data, and, you know, you communicate it in a way that's, like, kind of hand-off-esque. And then when you put it together, it turns out that, oh, the pieces don't quite fit together, and how do you actually decide, like, what that mental model should be? Naming, especially, too, I've, you know, seen so many times when the name...like, an attribute on the frontend is named a little bit different than whatever is on the backend, and it takes a lot of work to unify that, like, to make that decision about, should they be the same? Should they be different? A lot of thought goes into putting those pieces together. +And I think the benefit of a full-stack slice is that that work doesn't get lost. Especially if you are doing stuff like estimating, you're kind of discovering that earlier on. And I think what I just talked about, honestly, is what prevents those features from getting shipped in the end if you were working in a more horizontal way. +JOËL: Yeah. It's so easy to have, like, big chunks of work in progress forever and never actually shipping. And one of the benefits of these narrower slices is that you're shipping more frequently. And that's, you know, interesting from a coding perspective, but it's kind of an agile methodology thing as well, the, like, ship smaller chunks more frequently. Even though you're maybe taking a little bit more overhead because you're having to, like, take the time to break down tasks, it will make your project move faster as a whole. +An aspect that's really interesting to me, though, is what you highlighted about collaboration and the fact that every teammate has a slightly different mental model. And I think if you take the full-stack slice and every member is able to use their mental model, and then close the loop and actually, like, do a complete thing and ship it, I think it allows every other member who's going to have a slightly different mental model of the problem to kind of, yes, and... the other person rather than all sort of independently doing their things and having to reconcile them at the end. +STEPHANIE: Yeah, I agree. I think I find, you know, a lot of work broken out into backend and frontend frequently because team members might have different specialties or different preferences about where they would like to be working. But that could also be, like, a really awesome opportunity for pairing [laughs]. Like, if you have someone who's more comfortable in the backend or someone more comfortable in the frontend to work on that full-stack piece together, like, even outside of the in-the-weeds coding aspects of it, it's like you're, at the very least, making sure that those two folks have that same mental model. +Or I like what you said about yes, and... because it gets further refined when you have people who are maybe more familiar with, like, something about the app, and they're like, "Oh, like, don't forget about we should consider this." I think that, like, diversity of experience, too, ends up being really valuable in getting that abstraction to be more accurate so that it best represents what you're trying to build. +JOËL: Early on, when I was pretty new working at thoughtbot, somebody else at the company had given me the advice that if I wanted to be more effective and work faster on projects, I needed to start breaking my work down into smaller chunks, and this is, you know, fairly junior developer at the time. The advice sounds solid, and everything we've talked about today sounds really solid. Doing it in practice is hard, and it's taken me, you know, a decade, and I'm still working on getting better at it. +And I wrote an article about working iteratively that covers a lot of different elements where I've kind of pulled on threads and found out ways where you can get better at this. But I do want to acknowledge that this is not something that's easy and that just like the code that we're working on iteratively, our technique for breaking things down is something that we improve on iteratively. And it's a journey we're all on together. +STEPHANIE: I'm really glad that you brought up how hard it is because as I was thinking about this topic, I was considering barriers into working in that vertical slice way, and barriers that I personally experience, as well as just I have seen on other teams. I had alluded to some earlier about, like, the perception of if I ship this small thing, is it impressive enough, or is it valuable enough? And I think I realized that, like, I was getting caught up in, like, the perception part, right? And maybe it doesn't matter [chuckles], and I just need to kind of shift the way I'm thinking about it. +And then, there are more real barriers or, like, concrete barriers that are tough. Long feedback loops is one that I've encountered on a team where it's just really hard to ship frequently because PR reviews aren't happening fast enough or your CI or deployment process is just so long that you're like, I want to stuff everything into [chuckles] this one PR so that at least I won't have to sit and wait [laughs]. +And that can be really hard to work against, but it could also be a really interesting signal about whether your processes are working for you. It could be an opportunity to be like, "I would like to work this way, but here are the things that are preventing me from really embracing it. And is there any improvement I can make in those areas?" +JOËL: Yeah. There's a bit of a, like, vicious cycle that happens there sometimes, especially around PR review, where when it takes a long time to get reviews, you tend to decide, well, I'm going to not make a bunch of PRs; I'm going to make one big one. But then big PRs are very, like, time intensive and require you to commit a lot of, like, focus and energy to them, which means that when you ask me for a review, I'm going to wait longer before I review it, which is going to incentivize you to build bigger PRs, which is going to incentivize me to wait longer, and now we just...it's a vicious cycle. +So, I know I've definitely been on projects where a question the team has had is, "How can we improve our process? We want faster code review." And there's some aspect of that that's like, look, everybody just needs to be more disciplined or more alert and try to review things more frequently. But there's also an element of if you do make things smaller, you make it much easier for people to review your code in between other things. +STEPHANIE: Yeah, I really liked you mentioning incentives because I think that could be a really good place to start if you or your team are interested in making a change like this, you know, making an effort to look at your team processes and being like, what is incentivized here, and what does our system encourage or discourage? And if you want to be making that shift, like, that could be a good place to start in identifying places for improvement. +JOËL: And that happens on a broader system level as well. If you look at what does it take to go from a problem that is going to turn into a ticket to in-production in front of a client, how long is that loop? How complex are the steps to get there? The longer that loop is, the slower you're iterating. And the easier it is for things to just get hung up or for you to waste time, the harder it is for you to change course. +And so, oftentimes, I've come on to projects with clients and sort of seen something like that, and sort of seen other pain points that the team has and sort of found that one of the root causes is saying, "Look, we need to tighten that feedback loop, and that's going to improve all these other things that are kind of constellation around it." +STEPHANIE: Agreed. On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Joël shares a unique, time-specific bug he encountered, which causes a page to crash only in January. This bug has been fixed in previous years, only to reemerge due to subsequent changes. Stephanie talks about her efforts to bring more structure to her work-from-home environment. She describes how setting up a bird feeder near her desk and keeping chocolates at her desk serve as incentives to work more from her desk.

+ +

Together, Stephanie and Joël take a deep dive into the challenges of breaking down software development tasks into smaller, more manageable chunks. They explore the concept of 'vertical slice' development, where features are implemented in thin, fully functional segments, contrasting it with the more traditional 'horizontal slice' approach. This discussion leads to insights on collaborative work, the importance of iterative development, and strategies for efficient and effective software engineering.

+ + + +

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 in the year 2024?

+ +

JOËL: Yeah, it's 2024. New year, new me. Or, in this case, maybe new year, new bugs? I'm working on a project where I ran into a really interesting time-specific bug. This particular page on the site only crashes in the month of January. There's some date logic that has a weird boundary condition there, and if you load that page during the month of January, it will crash, but during the entire rest of the year, it's fine.

+ +

STEPHANIE: That's a fun New Year's tradition for this project [laughs], fixing this bug [laughs] every year.

+ +

JOËL: It's been interesting because I looked a little bit at the git history of this bug, and it looks like it's been fixed in past Januarys, but then the fix changes the behavior slightly, so people bring the behavior back correct during the rest of the year that also happens to reintroduce the bug in January, and now I'm back to fixing it in January. So, it is a little bit of a tradition.

+ +

STEPHANIE: Yeah, that is really funny. I was also recently debugging something, and we were having some flakiness with a test that we wrote. And we were trying to figure out because we had some date/time logic as well. And we were like, is there anything strange about this current time period that we are in that would potentially, you know, lead to a flaky test?

+ +

And we were looking at the clock and we're like, "I don't think it's like, you know, midnight UTC or anything [laughs] like that." But, I mean, I don't know. It's like, how could you possibly think of, like, all of the various weird edge cases, you know, related to that kind of thing? I don't think I would ever be like, huh, it's January, so, surely, that must [laughs] mean that that's this particular edge case I'm seeing.

+ +

JOËL: It's interesting because I feel like there's a couple of types of time-specific bugs that we see pretty frequently. If you're near the daylight savings boundary, let's say a week before sometimes, or whatever you're...if you're doing, like, a week from now logic or something like that, typically, I'll see failures in the test suite or maybe actual crashes in the code a week before springing forward and a week before falling back. And then, like you said, sometimes you see failures at the end of the day, Eastern time for me, when you approach that midnight UTC time boundary. I think this is the first time I've seen a failure in January due to the month being, like, a month boundary...or it's a year boundary really is what's happening.

+ +

STEPHANIE: Yeah. That just sounds like another [laughs] thing you have to look out for. I'm curious: are you going to fix this bug for real or leave it for [laughs] 2025?

+ +

JOËL: I've got a fix that I think is for real and that, like, not only fixes the break in January but also during the rest of the year gives the desired behavior. I think part of what's really interesting about this bug is that there are some subtle behavioral changes between a few different use cases where this code is called, part of which depend on when in the year you're calling it and whether you want to see it for today's date versus you can also specify a date that you want to see this report. And so, it turns out that there are a lot more edge cases than might be initially obvious.

+ +

So, this turned into effectively a product discussion, and realizing, wait a minute, the code isn't telling the full story. There's more at a product level we need to discuss. And actually, I think I learned a lot about the product there. So, while it was maybe a surprising and kind of humorous bug to come across, I think it was actually a really good experience.

+ +

STEPHANIE: Nice. That's awesome. That's a pretty good way to start the year, I would say.

+ +

JOËL: I'd say so. How about you? What's new in your world?

+ +

STEPHANIE: So, I don't know, I think towards the end of the year, last year, I was in a bit of a slump where I was in that work-from-couch phase of [laughs] the year, you know, like, things are slowing down and I, you know, winter was starting here. I wanted to be cozy, so I'd, you know, set up on the couch with a blanket.

+ +

And I realized that I really wasn't sitting at my desk at all, and I kind of wanted to bring a little bit of that structure back into my workday, so I [chuckles] added some incentives for me to sit at my desk, which include I recently got a bird feeder that attaches to the window in my office. So, when I sit at my desk, I can hopefully see some birds hanging out.

+ +

They are very flighty, so I've only seen birds when I'm, like, in the other room. And I'm like, oh, like, there's a bird at the bird feeder. Like, let me get up close to, like, get to admire them. And then as soon as I, like [laughs], get up close to the window, they fly away. So, I'm hoping that if I sit at my desk more, I'll spontaneously see more birds, and maybe they'll get used to, like, a presence closer to the window. And then my second incentive is I now have little chocolates at my desk [laughs].

+ +

JOËL: Nice.

+ +

STEPHANIE: I've just been enjoying, like, a little treat and trying to keep them as a...okay, I've worked at my desk for an hour, and now I get a little reward for that [laughs].

+ +

JOËL: I like that. Do you know what kind of species of birds have been coming to your feeder?

+ +

STEPHANIE: Ooh, yes. So, we got this birdseed mix called Cardinal and Friends [laughs].

+ +

JOËL: I love that.

+ +

STEPHANIE: So, I have seen, like, a really beautiful red male cardinal come by. We get some robins and some chickadees, I think. Part of what I'm excited for this winter is to learn more how to identify more bird species. And I usually like to be out in nature and stuff, and winter is a hard time to do that. So, this is kind of my way of [chuckles] bringing that more into my life during the season.

+ +

So, this is our first episode after a little bit of a break for the holidays. There actually has been some content of ours that has been published out in the world on the internet [laughs] during this time. And just wanted to point out in the few weeks that there weren't any Bike Shed episodes, I ended up doing a thoughtbot Rails development livestream with thoughtbot CEO Chad Pytel, and that was my first-time live streaming code [laughs].

+ +

And it was a really cool experience. I'm glad I had this podcast experience. So, I'm like, okay, well I have, you know, that, like, ability to do stuff kind of off script and present in the moment. But yeah, that was a really cool thing that I got to do, and I feel a little bit more confident about doing those kinds in the future.

+ +

JOËL: And for those who are not aware, Chad does–I think it's a weekly live stream on Fridays where he's doing various types of code. So, he's done some work on some internal projects. He did a series where he upgraded, I think, a Rails 2 app all the way to Rails 7, typically with a guest who's another teammate from thoughtbot working on a thing. So, for those of our listeners that might find interesting, we'll put a link in the show notes where you can go see that. I think it's on YouTube and on Twitch.

+ +

STEPHANIE: Yes.

+ +

JOËL: What did you pair on? What kind of project were you doing for the livestream?

+ +

STEPHANIE: So, we were working on thoughtbot's internal application called Hub, which is where we have, like, our internal messaging features. It's where we do a lot of our business operations-y things [laughs]. So, all of the, like, agency work that we do, we use our in-house software for that, and so Chad and I were working on a feature to introduce something that would help out with how we staff team members on projects.

+ +

In other content news [laughs], Joël, I think you have something to share as well.

+ +

JOËL: Yeah. So, we've mentioned on past episodes that I gave a talk at RubyConf this past November all about what the concept of time actually means within a program and the different ways of representing it, and the fact that time isn't really a single thing but actually kind of multiple related quantities. And over the holiday break, the talks from that conference got published. I'm pretty excited that that is now out there. We'd mentioned that as a highlight in the previous episode, highlighting accomplishments for the year, but it just wasn't quite out yet. We couldn't link it there. So, I'll leave a link in the show notes for this episode for anyone who's interested in seeing that.

+ +

STEPHANIE: Sounds like that talk is also timely for a debug you --

+ +

JOËL: Ha ha ha!

+ +

STEPHANIE: Were also mentioning earlier in the episode. So, a few episodes ago, I believe we mentioned that we had recently had, like, our company internal hackathon type thing where we have two days to get together and work with team members who we might not normally work with and get some cool projects started or do some team bonding, that kind of thing.

+ +

And since I'm still, you know, unbooked on client work, I've been doing a lot of internal thoughtbot stuff, like continuing to work on the Hub app I mentioned just a bit ago. And from the hackathon, there was some work that was unfinished by, like, a project team that I decided to pick up this week as part of my internal work.

+ +

And as I was kind of trying to gauge how much progress was made and, like, what was left to accomplish to get it over the finish line so it could be shipped, I noticed that because there were a couple of different people working on it, they had broken up this feature which was basically introducing, like, a new report for one of our teams to get some data on how certain projects are going.

+ +

And there was, like, a UI portion and then some back-end portion, and then part of the back-end portion also involved a bit of a complex query that was pulled out as a separate ticket on its own. And so, all of those things were slightly, you know, were mostly done but just needed those, like, finishing touches, and then it also needed to come together.

+ +

And I ended up pairing on this with another thoughtboter, and we spent the same amount of time that the hackathon was, so two days. We spent those two days on that, like, aspect of putting it all together. And I think I was a bit surprised by how much work that was, you know, we had kind of assumed that like, oh, like, all these pieces are mostly finished, but then the bulk of what we spended our time doing was integrating the components together.

+ +

JOËL: Does this feel like a bit of a finish the rest of the OWL meme?

+ +

STEPHANIE: What is that meme? I'm not familiar with it, but now I really want to know [laughs].

+ +

JOËL: It's a meme kind of making fun of some of these drawing tutorials where they're like, oh; first you draw, like, three circles.

+ +

STEPHANIE: [laughs]

+ +

JOËL: And then just finish the rest of the owl.

+ +

STEPHANIE: [laughs]

+ +

JOËL: And I was thinking of this beautifully drawn picture.

+ +

STEPHANIE: Oh, that's so funny. Okay, yeah, I can see it in my head [laughs] now. It's like how to go from three circles, you know, to a recognizable [laughs] owl animal.

+ +

JOËL: So, especially, they're like, oh, you know, like, we put in all the core classes and everything. It's all just basically there. You just need to connect it all together, and it's basically done [laughs]. And then you spend a lot of time actually getting that what feels like maybe the last 20 or 10% but takes maybe 80% of the time.

+ +

STEPHANIE: Yeah, that sounds about right. So, you know, kind of working on that got me thinking about the alternative, which is honestly something that I'm still working on getting better at doing in my day-to-day. But there is this idea of a vertical slice or a full-stack slice, and that, basically, involves splitting a large feature into those full-stack slices. So, you have, like, a fully implemented piece rather than breaking them apart by layers of the stack.

+ +

So, you know, I just see pretty frequently that, like, maybe you'll have a back-end ticket to do the database migration, to create your models, just whatever, maybe your controllers, or maybe that is even, like, another piece and then, like, the UI component. And those are worked on separately, maybe even by different people. But this vertical slice theory talks about how what you really want is to have a very thin piece of the feature that still delivers value but fully works.

+ +

JOËL: As opposed to what you might call a horizontal slice, which would be something like, oh, I've built three Rails models. They're there. They're in the code. They talk to tables in the database, but there's nothing else happening with them. So, you've done work, but it's also more or less dead code.

+ +

STEPHANIE: Yeah, that's a good point. I have definitely seen a lot of unused code paths [laughs] when you kind of go about it that way and maybe, like, that UI ticket never gets completed.

+ +

JOËL: What are some tips for trying to do some of these narrower slices? Like, I have a ticket, and I have some work I need to do. And I want to break it down because I know it's going to be too big, and maybe the, like, intuitive way to do it is to split it by layers of your stack where I might do all the models, commit, ship that, deploy, then do some controllers, then do some view, or something like that, and you're suggesting instead going full stack. How do you break down the ticket more when all the pieces are interrelated?

+ +

STEPHANIE: Yeah, that's a great point. One easy way to visualize it, especially if you have designs or something for this feature, right? Oftentimes, you can start to parse out sections or components of the user interface to be shipped separately. Like, yes, you would want all of it to have that rich feature, but if it's a view of some cards or something, and then, yeah, there's, like, the you can filter by them. You can search by them. All of those bits can be broken up to be like, well, like, the very basic thing that a customer would want to see is just that list of cards, and you can start there.

+ +

JOËL: So, aggressively breaking down the card at, like, almost a product level. Instead of breaking it down by technical pieces, say, like, can we get even smaller amounts of behavior while still delivering value?

+ +

STEPHANIE: Yeah, yeah, exactly. I like that you said product level because I think another axis of that could also be complexity. So, oftentimes, you know, I'll get a feature, and we're like, oh, we want to support these X number of things that we've identified [laughs]. You know, if it's like an e-com app you're building, you know, you're like, "Do we have all these products that we want to make sure to support?" And, you know, one way to break that down into that vertical slice is to ask, like, what if we started with just supporting one before we add variants or something like that?

+ +

Teasing out, like, what would end up being the added complexity as you're developing, once you have to start considering multiple parameters, I think that is a good way to be able to start working more iteratively. And so, you don't have to hold all of that complexity in your head.

+ +

JOËL: It's almost a bit of like a YAGNI principle but applied to features rather than to code.

+ +

STEPHANIE: Yeah. Yeah. I like that. At first, I hesitated a little bit because I've certainly been in the position where someone has said like, "Well, we do really need this [laughs]."

+ +

JOËL: Uh-huh. And, sometimes, the answer is, yes, we do need that, but what if I gave you a smaller version of that today, and we can do the other thing tomorrow?

+ +

STEPHANIE: Right. Yeah, it's not like you're rejecting the idea that it's necessary but the way that you get about to that end result, right?

+ +

JOËL: So, you keep using the term vertical slice or full-stack slice. I think when I hear that term, I think of specifically an article written by former thoughtboter, German Velasco, on our blog. But I don't know if that's maybe a term that has broader use in the industry. Is that a term that you've heard elsewhere?

+ +

STEPHANIE: That's a good question. I think I mostly hear, you know, some form of like, "Can we break this ticket down further?" and not necessarily, like, if you think about how, right? I'm, like, kind of doing a motion with my hand [chuckles] of, like, slicing from top to bottom as opposed to, you know, horizontal.

+ +

Yeah, I think that it may not be as common as I wish it were. Even if there's still some amount of adapting or, like, persuading your team members to get on board with this idea, like, I would be interested in, like, introducing that concept or that vocabulary to get teams talking about, like, how do they break down tickets? You know, like, what are they considering? Like, what alternatives are there? Like, are horizontal slices working for them or not?

+ +

JOËL: A term that I've heard floating around and I haven't really pinned down is Elephant Carpaccio. Have you heard that before?

+ +

STEPHANIE: I have, only because I, like, discovered a, like, workshop facilitation guide to run an exercise that is basically, like, helping people learn how to identify, like, smaller and smaller full-stack slices. But with the Elephant Carpaccio analogy, it's kind of like you're imagining a feature as big as an elephant. And you can create, like, a really thin slice out of them, and you can have infinite number of slices, but they still end up creating this elephant. And I guess you still get the value of [chuckles] a little carpaccio, a delicious [laughs] appetizer of thinly sliced meat.

+ +

JOËL: I love a colorful metaphor. So, I'm curious: in your own practice, do you have any sort of guidelines or even heuristics that you like to use to help work in a more, I guess, iterative fashion by working with these smaller slices?

+ +

STEPHANIE: Yeah, one thought that I had about it is that it plays really well with Outside-In Test Driven Development.

+ +

JOËL: Hmmm.

+ +

STEPHANIE: Yeah. So, if, you know, you are starting with a feature test, you have to start somewhere and, you know, maybe starting with, like, the most valuable piece of the feature, right? And you are starting at that level of user interaction if you're using Capybara, for example. And then it kind of forces you to drop down deeper into those layers.

+ +

But once you go through that whole process of outside-in and then you arrive back to the top, you've created your full-stack feature [laughs], and that is shippable or, like, committable and, you know, potentially even shippable in and of itself. And you already have full test coverage with it. And that was a cool way that I saw some of those two concepts work well together.

+ +

JOËL: Yeah, there is something really fun about the sort of Red-Green-Refactor cycle that TDD forces on you and that you're typically writing the minimum code required to pass a test. And it really forces you out of that developer brain where you're just like, oh, I've got to cover my edge cases. I've got to engineer for some things. And then maybe you realize you've written code that wasn't necessary. And so, I've found that often when I do, like, actually TDD a feature, I end up with code that's a lot leaner than I would otherwise.

+ +

STEPHANIE: Yes, lean like a thin slice of Elephant Carpaccio.

+ +

[laughter]

+ +

JOËL: One thing you did mention that I wanted to highlight was the fact that when you do this outside-in approach for your tiny slice, at the end, it is shippable. And I think that is a core sort of tenet of this idea is that even though you're breaking things down into smaller and smaller slices, every slice is shippable to production. Like, it doesn't break the build. It doesn't break the website. And it provides some kind of value to the user.

+ +

STEPHANIE: Yeah, absolutely. I think one thing that I still kind of get hung up on sometimes, and I'm trying to, you know, revisit this assumption is that idea of, like, is this too small? Like, is this valuable enough? When I mentioned earlier that I was working on a report, I think there was a part of me that's like, could I just ship a report with two columns [laughs]? And the answer is yes, right? Like, I thought about it, and I was like, well, if that data is, like, not available anywhere else, then, yeah, like, that would be valuable to just get out there.

+ +

But I think the idea that, like, you know, originally, the hope was to have all of these things, these pieces of information, you know, available through this report, I think that, like, held me back a little bit from wanting to break it down. And I held it a little bit too closely and to be like, well, I really want to, like, you know, deliver something impressive. When you click on it, it's like, wow, like, look at all this data [laughs]. So, I'm trying to push back a little bit on my own preconceived notions that, like, there is such a thing as, like, a too small of a demo.

+ +

JOËL: I've often worked with this at a commit level, trying to see, like, how small can I get a commit, and what is too small? And now you get into sort of the fraught question of what is a, you know, atomic commit? And I think, for me, where I've sort of come down is that a commit must pass CI. Like, I don't want a commit that's going to go into the main branch. I'm totally pro-work-in-progress commits on a branch; that's fine. But if it's going to get shipped into the main branch, it needs to be green. And it also cannot introduce dead code.

+ +

STEPHANIE: Ooh.

+ +

JOËL: So, if you're getting to the point where you're breaking either of those, you've got some sort of, like, partial commit that's maybe too small that needs more to be functional. Or you maybe need to restructure to say, look, instead of adding just ten models, can I add one model but also a little bit of a controller and a view? And now I've got a vertical slice.

+ +

STEPHANIE: Yeah, which might even be less code [laughs] in the end.

+ +

JOËL: Yes, it might be less code.

+ +

STEPHANIE: I really like that heuristic of not introducing dead code, that being a goal. I'm going to think about that a lot [laughs] and try to start introducing that into when I think something is ready.

+ +

JOËL: Another thing that I'll often do, I guess, that's almost like it doesn't quite fit in the slice metaphor, but it's trying to separate out any kind of refactor work into its own commit that is, you know, still follows those rules: it does not introduce dead code; it does not break the build; it's independently shippable. But that might be something that I do that sets me up for success when I want to do that next slice.

+ +

So, maybe I'm trying to add a new feature, but just the way we built some of the internal models, they don't have the interface that I need right now, and that's fine because I don't want to build these models in anticipation of the future. I can change them in the future if I need. But now the future has come, and I need a slightly different shape. So, I start by refactoring, commit, maybe even ship that deploy. Maybe I then do my small feature afterwards. Maybe I come back next week and do the small feature, but there are two independent things, two different commits, maybe two different deploys.

+ +

I don't know that I would call that refactor a slice and that it maybe goes across the full stack; maybe it doesn't. It doesn't show to the user because a refactor, by definition, is just changing the implementation without changing behavior. But I do like to break that out and keep it separate. And I guess it helps keep my slices lean, but I'm not quite sure where refactors fit into this metaphor.

+ +

STEPHANIE: Yeah, that's interesting because, in my head, as I was listening to you talk about that, I was visualizing the owl again, the [laughs] owl meme. And I'm imagining, like, the refactoring making the slice richer, right? It's like you're adding details, and you're...it's like when you end up with the full animal, or the owl, the elephant, whatever, it's not just, like, a shoddy-looking drawing [laughs]. Like, ideally, you know, it has those details. Maybe it has some feathers. It's shaded in, and it is very fleshed out. That's just my weird, little brain trying [laughs] to stretch this metaphor to make it work.

+ +

Another thing that I want to kind of touch a little bit more about when we're talking about how a lot of the work I was spending recently was that glue work, you know, the putting the pieces together, I think there was some aspect of discovery involved that was missed the first time around when these tickets were broken up more horizontally. I think that one really important piece that I was doing was trying to reconcile the different mental models that each person had when they were working on their separate piece.

+ +

And so, maybe there's, like, an API, and then the frontend is expecting some sort of data, and, you know, you communicate it in a way that's, like, kind of hand-off-esque. And then when you put it together, it turns out that, oh, the pieces don't quite fit together, and how do you actually decide, like, what that mental model should be? Naming, especially, too, I've, you know, seen so many times when the name...like, an attribute on the frontend is named a little bit different than whatever is on the backend, and it takes a lot of work to unify that, like, to make that decision about, should they be the same? Should they be different? A lot of thought goes into putting those pieces together.

+ +

And I think the benefit of a full-stack slice is that that work doesn't get lost. Especially if you are doing stuff like estimating, you're kind of discovering that earlier on. And I think what I just talked about, honestly, is what prevents those features from getting shipped in the end if you were working in a more horizontal way.

+ +

JOËL: Yeah. It's so easy to have, like, big chunks of work in progress forever and never actually shipping. And one of the benefits of these narrower slices is that you're shipping more frequently. And that's, you know, interesting from a coding perspective, but it's kind of an agile methodology thing as well, the, like, ship smaller chunks more frequently. Even though you're maybe taking a little bit more overhead because you're having to, like, take the time to break down tasks, it will make your project move faster as a whole.

+ +

An aspect that's really interesting to me, though, is what you highlighted about collaboration and the fact that every teammate has a slightly different mental model. And I think if you take the full-stack slice and every member is able to use their mental model, and then close the loop and actually, like, do a complete thing and ship it, I think it allows every other member who's going to have a slightly different mental model of the problem to kind of, yes, and... the other person rather than all sort of independently doing their things and having to reconcile them at the end.

+ +

STEPHANIE: Yeah, I agree. I think I find, you know, a lot of work broken out into backend and frontend frequently because team members might have different specialties or different preferences about where they would like to be working. But that could also be, like, a really awesome opportunity for pairing [laughs]. Like, if you have someone who's more comfortable in the backend or someone more comfortable in the frontend to work on that full-stack piece together, like, even outside of the in-the-weeds coding aspects of it, it's like you're, at the very least, making sure that those two folks have that same mental model.

+ +

Or I like what you said about yes, and... because it gets further refined when you have people who are maybe more familiar with, like, something about the app, and they're like, "Oh, like, don't forget about we should consider this." I think that, like, diversity of experience, too, ends up being really valuable in getting that abstraction to be more accurate so that it best represents what you're trying to build.

+ +

JOËL: Early on, when I was pretty new working at thoughtbot, somebody else at the company had given me the advice that if I wanted to be more effective and work faster on projects, I needed to start breaking my work down into smaller chunks, and this is, you know, fairly junior developer at the time. The advice sounds solid, and everything we've talked about today sounds really solid. Doing it in practice is hard, and it's taken me, you know, a decade, and I'm still working on getting better at it.

+ +

And I wrote an article about working iteratively that covers a lot of different elements where I've kind of pulled on threads and found out ways where you can get better at this. But I do want to acknowledge that this is not something that's easy and that just like the code that we're working on iteratively, our technique for breaking things down is something that we improve on iteratively. And it's a journey we're all on together.

+ +

STEPHANIE: I'm really glad that you brought up how hard it is because as I was thinking about this topic, I was considering barriers into working in that vertical slice way, and barriers that I personally experience, as well as just I have seen on other teams. I had alluded to some earlier about, like, the perception of if I ship this small thing, is it impressive enough, or is it valuable enough? And I think I realized that, like, I was getting caught up in, like, the perception part, right? And maybe it doesn't matter [chuckles], and I just need to kind of shift the way I'm thinking about it.

+ +

And then, there are more real barriers or, like, concrete barriers that are tough. Long feedback loops is one that I've encountered on a team where it's just really hard to ship frequently because PR reviews aren't happening fast enough or your CI or deployment process is just so long that you're like, I want to stuff everything into [chuckles] this one PR so that at least I won't have to sit and wait [laughs].

+ +

And that can be really hard to work against, but it could also be a really interesting signal about whether your processes are working for you. It could be an opportunity to be like, "I would like to work this way, but here are the things that are preventing me from really embracing it. And is there any improvement I can make in those areas?"

+ +

JOËL: Yeah. There's a bit of a, like, vicious cycle that happens there sometimes, especially around PR review, where when it takes a long time to get reviews, you tend to decide, well, I'm going to not make a bunch of PRs; I'm going to make one big one. But then big PRs are very, like, time intensive and require you to commit a lot of, like, focus and energy to them, which means that when you ask me for a review, I'm going to wait longer before I review it, which is going to incentivize you to build bigger PRs, which is going to incentivize me to wait longer, and now we just...it's a vicious cycle.

+ +

So, I know I've definitely been on projects where a question the team has had is, "How can we improve our process? We want faster code review." And there's some aspect of that that's like, look, everybody just needs to be more disciplined or more alert and try to review things more frequently. But there's also an element of if you do make things smaller, you make it much easier for people to review your code in between other things.

+ +

STEPHANIE: Yeah, I really liked you mentioning incentives because I think that could be a really good place to start if you or your team are interested in making a change like this, you know, making an effort to look at your team processes and being like, what is incentivized here, and what does our system encourage or discourage? And if you want to be making that shift, like, that could be a good place to start in identifying places for improvement.

+ +

JOËL: And that happens on a broader system level as well. If you look at what does it take to go from a problem that is going to turn into a ticket to in-production in front of a client, how long is that loop? How complex are the steps to get there? The longer that loop is, the slower you're iterating. And the easier it is for things to just get hung up or for you to waste time, the harder it is for you to change course.

+ +

And so, oftentimes, I've come on to projects with clients and sort of seen something like that, and sort of seen other pain points that the team has and sort of found that one of the root causes is saying, "Look, we need to tighten that feedback loop, and that's going to improve all these other things that are kind of constellation around it."

+ +

STEPHANIE: Agreed. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël shares a unique, time-specific bug he encountered, which causes a page to crash only in January. This bug has been fixed in previous years, only to reemerge due to subsequent changes. Stephanie talks about her efforts to bring more structure to her work-from-home environment. She describes how setting up a bird feeder near her desk and keeping chocolates at her desk serve as incentives to work more from her desk.

+ +

Together, Stephanie and Joël take a deep dive into the challenges of breaking down software development tasks into smaller, more manageable chunks. They explore the concept of 'vertical slice' development, where features are implemented in thin, fully functional segments, contrasting it with the more traditional 'horizontal slice' approach. This discussion leads to insights on collaborative work, the importance of iterative development, and strategies for efficient and effective software engineering.

+ + + +

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 in the year 2024?

+ +

JOËL: Yeah, it's 2024. New year, new me. Or, in this case, maybe new year, new bugs? I'm working on a project where I ran into a really interesting time-specific bug. This particular page on the site only crashes in the month of January. There's some date logic that has a weird boundary condition there, and if you load that page during the month of January, it will crash, but during the entire rest of the year, it's fine.

+ +

STEPHANIE: That's a fun New Year's tradition for this project [laughs], fixing this bug [laughs] every year.

+ +

JOËL: It's been interesting because I looked a little bit at the git history of this bug, and it looks like it's been fixed in past Januarys, but then the fix changes the behavior slightly, so people bring the behavior back correct during the rest of the year that also happens to reintroduce the bug in January, and now I'm back to fixing it in January. So, it is a little bit of a tradition.

+ +

STEPHANIE: Yeah, that is really funny. I was also recently debugging something, and we were having some flakiness with a test that we wrote. And we were trying to figure out because we had some date/time logic as well. And we were like, is there anything strange about this current time period that we are in that would potentially, you know, lead to a flaky test?

+ +

And we were looking at the clock and we're like, "I don't think it's like, you know, midnight UTC or anything [laughs] like that." But, I mean, I don't know. It's like, how could you possibly think of, like, all of the various weird edge cases, you know, related to that kind of thing? I don't think I would ever be like, huh, it's January, so, surely, that must [laughs] mean that that's this particular edge case I'm seeing.

+ +

JOËL: It's interesting because I feel like there's a couple of types of time-specific bugs that we see pretty frequently. If you're near the daylight savings boundary, let's say a week before sometimes, or whatever you're...if you're doing, like, a week from now logic or something like that, typically, I'll see failures in the test suite or maybe actual crashes in the code a week before springing forward and a week before falling back. And then, like you said, sometimes you see failures at the end of the day, Eastern time for me, when you approach that midnight UTC time boundary. I think this is the first time I've seen a failure in January due to the month being, like, a month boundary...or it's a year boundary really is what's happening.

+ +

STEPHANIE: Yeah. That just sounds like another [laughs] thing you have to look out for. I'm curious: are you going to fix this bug for real or leave it for [laughs] 2025?

+ +

JOËL: I've got a fix that I think is for real and that, like, not only fixes the break in January but also during the rest of the year gives the desired behavior. I think part of what's really interesting about this bug is that there are some subtle behavioral changes between a few different use cases where this code is called, part of which depend on when in the year you're calling it and whether you want to see it for today's date versus you can also specify a date that you want to see this report. And so, it turns out that there are a lot more edge cases than might be initially obvious.

+ +

So, this turned into effectively a product discussion, and realizing, wait a minute, the code isn't telling the full story. There's more at a product level we need to discuss. And actually, I think I learned a lot about the product there. So, while it was maybe a surprising and kind of humorous bug to come across, I think it was actually a really good experience.

+ +

STEPHANIE: Nice. That's awesome. That's a pretty good way to start the year, I would say.

+ +

JOËL: I'd say so. How about you? What's new in your world?

+ +

STEPHANIE: So, I don't know, I think towards the end of the year, last year, I was in a bit of a slump where I was in that work-from-couch phase of [laughs] the year, you know, like, things are slowing down and I, you know, winter was starting here. I wanted to be cozy, so I'd, you know, set up on the couch with a blanket.

+ +

And I realized that I really wasn't sitting at my desk at all, and I kind of wanted to bring a little bit of that structure back into my workday, so I [chuckles] added some incentives for me to sit at my desk, which include I recently got a bird feeder that attaches to the window in my office. So, when I sit at my desk, I can hopefully see some birds hanging out.

+ +

They are very flighty, so I've only seen birds when I'm, like, in the other room. And I'm like, oh, like, there's a bird at the bird feeder. Like, let me get up close to, like, get to admire them. And then as soon as I, like [laughs], get up close to the window, they fly away. So, I'm hoping that if I sit at my desk more, I'll spontaneously see more birds, and maybe they'll get used to, like, a presence closer to the window. And then my second incentive is I now have little chocolates at my desk [laughs].

+ +

JOËL: Nice.

+ +

STEPHANIE: I've just been enjoying, like, a little treat and trying to keep them as a...okay, I've worked at my desk for an hour, and now I get a little reward for that [laughs].

+ +

JOËL: I like that. Do you know what kind of species of birds have been coming to your feeder?

+ +

STEPHANIE: Ooh, yes. So, we got this birdseed mix called Cardinal and Friends [laughs].

+ +

JOËL: I love that.

+ +

STEPHANIE: So, I have seen, like, a really beautiful red male cardinal come by. We get some robins and some chickadees, I think. Part of what I'm excited for this winter is to learn more how to identify more bird species. And I usually like to be out in nature and stuff, and winter is a hard time to do that. So, this is kind of my way of [chuckles] bringing that more into my life during the season.

+ +

So, this is our first episode after a little bit of a break for the holidays. There actually has been some content of ours that has been published out in the world on the internet [laughs] during this time. And just wanted to point out in the few weeks that there weren't any Bike Shed episodes, I ended up doing a thoughtbot Rails development livestream with thoughtbot CEO Chad Pytel, and that was my first-time live streaming code [laughs].

+ +

And it was a really cool experience. I'm glad I had this podcast experience. So, I'm like, okay, well I have, you know, that, like, ability to do stuff kind of off script and present in the moment. But yeah, that was a really cool thing that I got to do, and I feel a little bit more confident about doing those kinds in the future.

+ +

JOËL: And for those who are not aware, Chad does–I think it's a weekly live stream on Fridays where he's doing various types of code. So, he's done some work on some internal projects. He did a series where he upgraded, I think, a Rails 2 app all the way to Rails 7, typically with a guest who's another teammate from thoughtbot working on a thing. So, for those of our listeners that might find interesting, we'll put a link in the show notes where you can go see that. I think it's on YouTube and on Twitch.

+ +

STEPHANIE: Yes.

+ +

JOËL: What did you pair on? What kind of project were you doing for the livestream?

+ +

STEPHANIE: So, we were working on thoughtbot's internal application called Hub, which is where we have, like, our internal messaging features. It's where we do a lot of our business operations-y things [laughs]. So, all of the, like, agency work that we do, we use our in-house software for that, and so Chad and I were working on a feature to introduce something that would help out with how we staff team members on projects.

+ +

In other content news [laughs], Joël, I think you have something to share as well.

+ +

JOËL: Yeah. So, we've mentioned on past episodes that I gave a talk at RubyConf this past November all about what the concept of time actually means within a program and the different ways of representing it, and the fact that time isn't really a single thing but actually kind of multiple related quantities. And over the holiday break, the talks from that conference got published. I'm pretty excited that that is now out there. We'd mentioned that as a highlight in the previous episode, highlighting accomplishments for the year, but it just wasn't quite out yet. We couldn't link it there. So, I'll leave a link in the show notes for this episode for anyone who's interested in seeing that.

+ +

STEPHANIE: Sounds like that talk is also timely for a debug you --

+ +

JOËL: Ha ha ha!

+ +

STEPHANIE: Were also mentioning earlier in the episode. So, a few episodes ago, I believe we mentioned that we had recently had, like, our company internal hackathon type thing where we have two days to get together and work with team members who we might not normally work with and get some cool projects started or do some team bonding, that kind of thing.

+ +

And since I'm still, you know, unbooked on client work, I've been doing a lot of internal thoughtbot stuff, like continuing to work on the Hub app I mentioned just a bit ago. And from the hackathon, there was some work that was unfinished by, like, a project team that I decided to pick up this week as part of my internal work.

+ +

And as I was kind of trying to gauge how much progress was made and, like, what was left to accomplish to get it over the finish line so it could be shipped, I noticed that because there were a couple of different people working on it, they had broken up this feature which was basically introducing, like, a new report for one of our teams to get some data on how certain projects are going.

+ +

And there was, like, a UI portion and then some back-end portion, and then part of the back-end portion also involved a bit of a complex query that was pulled out as a separate ticket on its own. And so, all of those things were slightly, you know, were mostly done but just needed those, like, finishing touches, and then it also needed to come together.

+ +

And I ended up pairing on this with another thoughtboter, and we spent the same amount of time that the hackathon was, so two days. We spent those two days on that, like, aspect of putting it all together. And I think I was a bit surprised by how much work that was, you know, we had kind of assumed that like, oh, like, all these pieces are mostly finished, but then the bulk of what we spended our time doing was integrating the components together.

+ +

JOËL: Does this feel like a bit of a finish the rest of the OWL meme?

+ +

STEPHANIE: What is that meme? I'm not familiar with it, but now I really want to know [laughs].

+ +

JOËL: It's a meme kind of making fun of some of these drawing tutorials where they're like, oh; first you draw, like, three circles.

+ +

STEPHANIE: [laughs]

+ +

JOËL: And then just finish the rest of the owl.

+ +

STEPHANIE: [laughs]

+ +

JOËL: And I was thinking of this beautifully drawn picture.

+ +

STEPHANIE: Oh, that's so funny. Okay, yeah, I can see it in my head [laughs] now. It's like how to go from three circles, you know, to a recognizable [laughs] owl animal.

+ +

JOËL: So, especially, they're like, oh, you know, like, we put in all the core classes and everything. It's all just basically there. You just need to connect it all together, and it's basically done [laughs]. And then you spend a lot of time actually getting that what feels like maybe the last 20 or 10% but takes maybe 80% of the time.

+ +

STEPHANIE: Yeah, that sounds about right. So, you know, kind of working on that got me thinking about the alternative, which is honestly something that I'm still working on getting better at doing in my day-to-day. But there is this idea of a vertical slice or a full-stack slice, and that, basically, involves splitting a large feature into those full-stack slices. So, you have, like, a fully implemented piece rather than breaking them apart by layers of the stack.

+ +

So, you know, I just see pretty frequently that, like, maybe you'll have a back-end ticket to do the database migration, to create your models, just whatever, maybe your controllers, or maybe that is even, like, another piece and then, like, the UI component. And those are worked on separately, maybe even by different people. But this vertical slice theory talks about how what you really want is to have a very thin piece of the feature that still delivers value but fully works.

+ +

JOËL: As opposed to what you might call a horizontal slice, which would be something like, oh, I've built three Rails models. They're there. They're in the code. They talk to tables in the database, but there's nothing else happening with them. So, you've done work, but it's also more or less dead code.

+ +

STEPHANIE: Yeah, that's a good point. I have definitely seen a lot of unused code paths [laughs] when you kind of go about it that way and maybe, like, that UI ticket never gets completed.

+ +

JOËL: What are some tips for trying to do some of these narrower slices? Like, I have a ticket, and I have some work I need to do. And I want to break it down because I know it's going to be too big, and maybe the, like, intuitive way to do it is to split it by layers of your stack where I might do all the models, commit, ship that, deploy, then do some controllers, then do some view, or something like that, and you're suggesting instead going full stack. How do you break down the ticket more when all the pieces are interrelated?

+ +

STEPHANIE: Yeah, that's a great point. One easy way to visualize it, especially if you have designs or something for this feature, right? Oftentimes, you can start to parse out sections or components of the user interface to be shipped separately. Like, yes, you would want all of it to have that rich feature, but if it's a view of some cards or something, and then, yeah, there's, like, the you can filter by them. You can search by them. All of those bits can be broken up to be like, well, like, the very basic thing that a customer would want to see is just that list of cards, and you can start there.

+ +

JOËL: So, aggressively breaking down the card at, like, almost a product level. Instead of breaking it down by technical pieces, say, like, can we get even smaller amounts of behavior while still delivering value?

+ +

STEPHANIE: Yeah, yeah, exactly. I like that you said product level because I think another axis of that could also be complexity. So, oftentimes, you know, I'll get a feature, and we're like, oh, we want to support these X number of things that we've identified [laughs]. You know, if it's like an e-com app you're building, you know, you're like, "Do we have all these products that we want to make sure to support?" And, you know, one way to break that down into that vertical slice is to ask, like, what if we started with just supporting one before we add variants or something like that?

+ +

Teasing out, like, what would end up being the added complexity as you're developing, once you have to start considering multiple parameters, I think that is a good way to be able to start working more iteratively. And so, you don't have to hold all of that complexity in your head.

+ +

JOËL: It's almost a bit of like a YAGNI principle but applied to features rather than to code.

+ +

STEPHANIE: Yeah. Yeah. I like that. At first, I hesitated a little bit because I've certainly been in the position where someone has said like, "Well, we do really need this [laughs]."

+ +

JOËL: Uh-huh. And, sometimes, the answer is, yes, we do need that, but what if I gave you a smaller version of that today, and we can do the other thing tomorrow?

+ +

STEPHANIE: Right. Yeah, it's not like you're rejecting the idea that it's necessary but the way that you get about to that end result, right?

+ +

JOËL: So, you keep using the term vertical slice or full-stack slice. I think when I hear that term, I think of specifically an article written by former thoughtboter, German Velasco, on our blog. But I don't know if that's maybe a term that has broader use in the industry. Is that a term that you've heard elsewhere?

+ +

STEPHANIE: That's a good question. I think I mostly hear, you know, some form of like, "Can we break this ticket down further?" and not necessarily, like, if you think about how, right? I'm, like, kind of doing a motion with my hand [chuckles] of, like, slicing from top to bottom as opposed to, you know, horizontal.

+ +

Yeah, I think that it may not be as common as I wish it were. Even if there's still some amount of adapting or, like, persuading your team members to get on board with this idea, like, I would be interested in, like, introducing that concept or that vocabulary to get teams talking about, like, how do they break down tickets? You know, like, what are they considering? Like, what alternatives are there? Like, are horizontal slices working for them or not?

+ +

JOËL: A term that I've heard floating around and I haven't really pinned down is Elephant Carpaccio. Have you heard that before?

+ +

STEPHANIE: I have, only because I, like, discovered a, like, workshop facilitation guide to run an exercise that is basically, like, helping people learn how to identify, like, smaller and smaller full-stack slices. But with the Elephant Carpaccio analogy, it's kind of like you're imagining a feature as big as an elephant. And you can create, like, a really thin slice out of them, and you can have infinite number of slices, but they still end up creating this elephant. And I guess you still get the value of [chuckles] a little carpaccio, a delicious [laughs] appetizer of thinly sliced meat.

+ +

JOËL: I love a colorful metaphor. So, I'm curious: in your own practice, do you have any sort of guidelines or even heuristics that you like to use to help work in a more, I guess, iterative fashion by working with these smaller slices?

+ +

STEPHANIE: Yeah, one thought that I had about it is that it plays really well with Outside-In Test Driven Development.

+ +

JOËL: Hmmm.

+ +

STEPHANIE: Yeah. So, if, you know, you are starting with a feature test, you have to start somewhere and, you know, maybe starting with, like, the most valuable piece of the feature, right? And you are starting at that level of user interaction if you're using Capybara, for example. And then it kind of forces you to drop down deeper into those layers.

+ +

But once you go through that whole process of outside-in and then you arrive back to the top, you've created your full-stack feature [laughs], and that is shippable or, like, committable and, you know, potentially even shippable in and of itself. And you already have full test coverage with it. And that was a cool way that I saw some of those two concepts work well together.

+ +

JOËL: Yeah, there is something really fun about the sort of Red-Green-Refactor cycle that TDD forces on you and that you're typically writing the minimum code required to pass a test. And it really forces you out of that developer brain where you're just like, oh, I've got to cover my edge cases. I've got to engineer for some things. And then maybe you realize you've written code that wasn't necessary. And so, I've found that often when I do, like, actually TDD a feature, I end up with code that's a lot leaner than I would otherwise.

+ +

STEPHANIE: Yes, lean like a thin slice of Elephant Carpaccio.

+ +

[laughter]

+ +

JOËL: One thing you did mention that I wanted to highlight was the fact that when you do this outside-in approach for your tiny slice, at the end, it is shippable. And I think that is a core sort of tenet of this idea is that even though you're breaking things down into smaller and smaller slices, every slice is shippable to production. Like, it doesn't break the build. It doesn't break the website. And it provides some kind of value to the user.

+ +

STEPHANIE: Yeah, absolutely. I think one thing that I still kind of get hung up on sometimes, and I'm trying to, you know, revisit this assumption is that idea of, like, is this too small? Like, is this valuable enough? When I mentioned earlier that I was working on a report, I think there was a part of me that's like, could I just ship a report with two columns [laughs]? And the answer is yes, right? Like, I thought about it, and I was like, well, if that data is, like, not available anywhere else, then, yeah, like, that would be valuable to just get out there.

+ +

But I think the idea that, like, you know, originally, the hope was to have all of these things, these pieces of information, you know, available through this report, I think that, like, held me back a little bit from wanting to break it down. And I held it a little bit too closely and to be like, well, I really want to, like, you know, deliver something impressive. When you click on it, it's like, wow, like, look at all this data [laughs]. So, I'm trying to push back a little bit on my own preconceived notions that, like, there is such a thing as, like, a too small of a demo.

+ +

JOËL: I've often worked with this at a commit level, trying to see, like, how small can I get a commit, and what is too small? And now you get into sort of the fraught question of what is a, you know, atomic commit? And I think, for me, where I've sort of come down is that a commit must pass CI. Like, I don't want a commit that's going to go into the main branch. I'm totally pro-work-in-progress commits on a branch; that's fine. But if it's going to get shipped into the main branch, it needs to be green. And it also cannot introduce dead code.

+ +

STEPHANIE: Ooh.

+ +

JOËL: So, if you're getting to the point where you're breaking either of those, you've got some sort of, like, partial commit that's maybe too small that needs more to be functional. Or you maybe need to restructure to say, look, instead of adding just ten models, can I add one model but also a little bit of a controller and a view? And now I've got a vertical slice.

+ +

STEPHANIE: Yeah, which might even be less code [laughs] in the end.

+ +

JOËL: Yes, it might be less code.

+ +

STEPHANIE: I really like that heuristic of not introducing dead code, that being a goal. I'm going to think about that a lot [laughs] and try to start introducing that into when I think something is ready.

+ +

JOËL: Another thing that I'll often do, I guess, that's almost like it doesn't quite fit in the slice metaphor, but it's trying to separate out any kind of refactor work into its own commit that is, you know, still follows those rules: it does not introduce dead code; it does not break the build; it's independently shippable. But that might be something that I do that sets me up for success when I want to do that next slice.

+ +

So, maybe I'm trying to add a new feature, but just the way we built some of the internal models, they don't have the interface that I need right now, and that's fine because I don't want to build these models in anticipation of the future. I can change them in the future if I need. But now the future has come, and I need a slightly different shape. So, I start by refactoring, commit, maybe even ship that deploy. Maybe I then do my small feature afterwards. Maybe I come back next week and do the small feature, but there are two independent things, two different commits, maybe two different deploys.

+ +

I don't know that I would call that refactor a slice and that it maybe goes across the full stack; maybe it doesn't. It doesn't show to the user because a refactor, by definition, is just changing the implementation without changing behavior. But I do like to break that out and keep it separate. And I guess it helps keep my slices lean, but I'm not quite sure where refactors fit into this metaphor.

+ +

STEPHANIE: Yeah, that's interesting because, in my head, as I was listening to you talk about that, I was visualizing the owl again, the [laughs] owl meme. And I'm imagining, like, the refactoring making the slice richer, right? It's like you're adding details, and you're...it's like when you end up with the full animal, or the owl, the elephant, whatever, it's not just, like, a shoddy-looking drawing [laughs]. Like, ideally, you know, it has those details. Maybe it has some feathers. It's shaded in, and it is very fleshed out. That's just my weird, little brain trying [laughs] to stretch this metaphor to make it work.

+ +

Another thing that I want to kind of touch a little bit more about when we're talking about how a lot of the work I was spending recently was that glue work, you know, the putting the pieces together, I think there was some aspect of discovery involved that was missed the first time around when these tickets were broken up more horizontally. I think that one really important piece that I was doing was trying to reconcile the different mental models that each person had when they were working on their separate piece.

+ +

And so, maybe there's, like, an API, and then the frontend is expecting some sort of data, and, you know, you communicate it in a way that's, like, kind of hand-off-esque. And then when you put it together, it turns out that, oh, the pieces don't quite fit together, and how do you actually decide, like, what that mental model should be? Naming, especially, too, I've, you know, seen so many times when the name...like, an attribute on the frontend is named a little bit different than whatever is on the backend, and it takes a lot of work to unify that, like, to make that decision about, should they be the same? Should they be different? A lot of thought goes into putting those pieces together.

+ +

And I think the benefit of a full-stack slice is that that work doesn't get lost. Especially if you are doing stuff like estimating, you're kind of discovering that earlier on. And I think what I just talked about, honestly, is what prevents those features from getting shipped in the end if you were working in a more horizontal way.

+ +

JOËL: Yeah. It's so easy to have, like, big chunks of work in progress forever and never actually shipping. And one of the benefits of these narrower slices is that you're shipping more frequently. And that's, you know, interesting from a coding perspective, but it's kind of an agile methodology thing as well, the, like, ship smaller chunks more frequently. Even though you're maybe taking a little bit more overhead because you're having to, like, take the time to break down tasks, it will make your project move faster as a whole.

+ +

An aspect that's really interesting to me, though, is what you highlighted about collaboration and the fact that every teammate has a slightly different mental model. And I think if you take the full-stack slice and every member is able to use their mental model, and then close the loop and actually, like, do a complete thing and ship it, I think it allows every other member who's going to have a slightly different mental model of the problem to kind of, yes, and... the other person rather than all sort of independently doing their things and having to reconcile them at the end.

+ +

STEPHANIE: Yeah, I agree. I think I find, you know, a lot of work broken out into backend and frontend frequently because team members might have different specialties or different preferences about where they would like to be working. But that could also be, like, a really awesome opportunity for pairing [laughs]. Like, if you have someone who's more comfortable in the backend or someone more comfortable in the frontend to work on that full-stack piece together, like, even outside of the in-the-weeds coding aspects of it, it's like you're, at the very least, making sure that those two folks have that same mental model.

+ +

Or I like what you said about yes, and... because it gets further refined when you have people who are maybe more familiar with, like, something about the app, and they're like, "Oh, like, don't forget about we should consider this." I think that, like, diversity of experience, too, ends up being really valuable in getting that abstraction to be more accurate so that it best represents what you're trying to build.

+ +

JOËL: Early on, when I was pretty new working at thoughtbot, somebody else at the company had given me the advice that if I wanted to be more effective and work faster on projects, I needed to start breaking my work down into smaller chunks, and this is, you know, fairly junior developer at the time. The advice sounds solid, and everything we've talked about today sounds really solid. Doing it in practice is hard, and it's taken me, you know, a decade, and I'm still working on getting better at it.

+ +

And I wrote an article about working iteratively that covers a lot of different elements where I've kind of pulled on threads and found out ways where you can get better at this. But I do want to acknowledge that this is not something that's easy and that just like the code that we're working on iteratively, our technique for breaking things down is something that we improve on iteratively. And it's a journey we're all on together.

+ +

STEPHANIE: I'm really glad that you brought up how hard it is because as I was thinking about this topic, I was considering barriers into working in that vertical slice way, and barriers that I personally experience, as well as just I have seen on other teams. I had alluded to some earlier about, like, the perception of if I ship this small thing, is it impressive enough, or is it valuable enough? And I think I realized that, like, I was getting caught up in, like, the perception part, right? And maybe it doesn't matter [chuckles], and I just need to kind of shift the way I'm thinking about it.

+ +

And then, there are more real barriers or, like, concrete barriers that are tough. Long feedback loops is one that I've encountered on a team where it's just really hard to ship frequently because PR reviews aren't happening fast enough or your CI or deployment process is just so long that you're like, I want to stuff everything into [chuckles] this one PR so that at least I won't have to sit and wait [laughs].

+ +

And that can be really hard to work against, but it could also be a really interesting signal about whether your processes are working for you. It could be an opportunity to be like, "I would like to work this way, but here are the things that are preventing me from really embracing it. And is there any improvement I can make in those areas?"

+ +

JOËL: Yeah. There's a bit of a, like, vicious cycle that happens there sometimes, especially around PR review, where when it takes a long time to get reviews, you tend to decide, well, I'm going to not make a bunch of PRs; I'm going to make one big one. But then big PRs are very, like, time intensive and require you to commit a lot of, like, focus and energy to them, which means that when you ask me for a review, I'm going to wait longer before I review it, which is going to incentivize you to build bigger PRs, which is going to incentivize me to wait longer, and now we just...it's a vicious cycle.

+ +

So, I know I've definitely been on projects where a question the team has had is, "How can we improve our process? We want faster code review." And there's some aspect of that that's like, look, everybody just needs to be more disciplined or more alert and try to review things more frequently. But there's also an element of if you do make things smaller, you make it much easier for people to review your code in between other things.

+ +

STEPHANIE: Yeah, I really liked you mentioning incentives because I think that could be a really good place to start if you or your team are interested in making a change like this, you know, making an effort to look at your team processes and being like, what is incentivized here, and what does our system encourage or discourage? And if you want to be making that shift, like, that could be a good place to start in identifying places for improvement.

+ +

JOËL: And that happens on a broader system level as well. If you look at what does it take to go from a problem that is going to turn into a ticket to in-production in front of a client, how long is that loop? How complex are the steps to get there? The longer that loop is, the slower you're iterating. And the easier it is for things to just get hung up or for you to waste time, the harder it is for you to change course.

+ +

And so, oftentimes, I've come on to projects with clients and sort of seen something like that, and sort of seen other pain points that the team has and sort of found that one of the root causes is saying, "Look, we need to tighten that feedback loop, and that's going to improve all these other things that are kind of constellation around it."

+ +

STEPHANIE: Agreed. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+sKOYAiM_ + + ]]> + + Joël Quenneville + Stephanie Minn + + + 411: Celebrating and Recapping 2023! + https://bikeshed.thoughtbot.com/411 + fcdf1d7b-367a-4b22-a79c-8a55483ef628 + Tue, 19 Dec 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza. + +We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they’ve read and loved, and other highlights of 2023 (projects, conferences, etc). + 38:40 + no + + + Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza. +We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they’ve read and loved, and other highlights of 2023 (projects, conferences, etc). +Olive Oil Sugar Cookies With Pistachios & Lemon Glaze (https://food52.com/recipes/82228-olive-oil-sugar-cookies-recipe-with-pistachios-lemon) +thoughtbot’s Blog (https://thoughtbot.com/blog) +Episode 398: Developing Heuristics For Writing Software (https://www.bikeshed.fm/398) +Episode 374: Discrete Math (https://www.bikeshed.fm/374) +Episode 405: Sandi Metz’s Rules (https://www.bikeshed.fm/405) +Episode 391: Learn with APPL (https://www.bikeshed.fm/391) +Engineering Management for the Rest of Us (https://www.engmanagement.dev/) +Confident Ruby (https://pragprog.com/titles/agcr/confident-ruby/) +Working with Maybe from Elm Europe (https://www.youtube.com/watch?v=43eM4kNbb6c) +Sustainable Rails Book (https://sustainable-rails.com/) +Episode 368: Sustainable Web Development (https://www.bikeshed.fm/368) +Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) +Simplifying Tests by Extracting Side Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) +The Math Every Programmer Needs (https://www.youtube.com/watch?v=wzYYT40T8G8) +Mermaid.js sequence diagrams (https://mermaid.js.org/syntax/sequenc) +Sense of Belonging and Software Teams (https://www.drcathicks.com/post/sense-of-belonging-and-software-teams) +Preemptive Pluralization is (Probably) Not Evil (https://www.swyx.io/preemptive-pluralization) +Digging through the ashes (https://everythingchanges.us/blog/digging-through-the-ashes/) +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: I am so excited to talk about this. I'm, like, literally smiling [chuckles] because I'm so pumped. Sometimes, you know, we get on to record, and I'm like, oh, I got to think of something that's new, like, my life is so boring. I have nothing to share. But today, I am excited to tell you about [chuckles] the holiday cookie swap that I'm hosting this Sunday [laughs] that I haven't been able to stop thinking about or just thinking about all the cookies that I'm going to get to eat. +It's going to be my first time throwing this kind of shindig, and I'm so pleased with myself because it's such a great idea. You know, it's like, you get to share cookies, and you get to have all different types of cookies, and then people get to take them home. And I get to see all my friends. And I'm really [chuckles] looking forward to it. +JOËL: I don't think I've ever been to a cookie swap event. How does that work? Everybody shows up with cookies, and then you leave with what you want? +STEPHANIE: That's kind of the plan. I think it's not really a...there's no rules [laughs]. You can make it whatever you want it to be. But I'm asking everyone to bring, like, two dozen cookies. And, you know, I'm hoping for a lot of fun variety. Myself I'm planning on making these pistachio olive oil cookies with a lemon glaze and also, maybe, like, a chewy ginger cookie. I haven't decided if I'm going to go so extra to make two types, but we'll see. +And yeah, we'll, you know, probably have some drinks and be playing Christmas music, and yeah, we'll just hang out. And I'm hoping that everyone can kind of, like, take home a little goodie bag of cookies as well because I don't think we'll be going through all of them. +JOËL: Hearing you talk about this gave me an absolutely terrible idea. +STEPHANIE: Terrible or terribly awesome? [laughs] +JOËL: So, imagine you have the equivalent of, let's say, a LAN party. You all show up with your laptops. +STEPHANIE: [laughs] +JOËL: You're on a network, and then you swap browser cookies randomly. +STEPHANIE: [laughs] Oh no. That would be really funny. That's a developer's take on a cookie party [laughs] if I've ever heard one. +JOËL: Slightly terrifying. Now I'm just browsing, and all of a sudden, I guess I'm logged into your Facebook or something. Maybe you only swap the tracking cookies. So, I'm not actually logged into your Facebook, but I just get to see the different ad networks it would typically show you, and you would see my ads. That's maybe kind of fun or maybe terrifying, depending on what kind of ads you normally see. +STEPHANIE: That's really funny. I'm thinking about how it would just be probably very misleading and confusing for those [laughs] analytics spenders, but that's totally fine, too. Might I suggest also having real cookies to munch on as well while you are enjoying [laughs] this browser cookie-swapping party? +JOËL: I 100% agree. +STEPHANIE: [laughs] +JOËL: I'm curious: where do you stand on raisins in oatmeal cookies? +STEPHANIE: Ooh. +JOËL: This is a divisive question. +STEPHANIE: They're fine. I'll let other people eat them. And occasionally, I will also eat an oatmeal cookie with raisins, but I much prefer if the raisins are chocolate chips [chuckles]. +JOËL: That is the correct answer. +STEPHANIE: [laughs] Thank you. You know, I understand that people like them. They're not for me [laughs]. +JOËL: It's okay. Fans can send us hate mail about why we're wrong about oatmeal cookies. +STEPHANIE: Yeah, honestly, that's something that I'm okay with being wrong about on the internet [laughs]. So, Joël, what's new in your world? +JOËL: So, as of this recording, we've just recently done thoughtbot's end-of-the-year hackathon, what we call Ralphapalooza. And this is sort of a time where you kind of get to do pretty much any sort of company or programming-related activity that you want as long as...you have to pitch it and get at least two other colleagues to join you on the project, and then you've got two days to work on it. And then you can share back to the team what you've done. +I was on a project where we were trying to write a lot of blog posts for the thoughtbot blog. And so, we're just kind of getting together and pitching ideas, reviewing each other's articles, writing things at a pretty intense rate for a couple of days, trying to flood the blog with articles for the next few weeks. So, if you're following the blog and as the time this episode gets released, you're like, "Wow, there's been a lot of articles from the thoughtbot blog recently," that's why. +STEPHANIE: Yes, that's awesome. I love how much energy that the blog post-writing party garnered. Like, I was just kind of observing from afar, but it sounds like, you know, people who maybe had started posts, like, throughout the year had dedicated time and a good reason to revisit them, even if they had been, you know, kind of just, like, sitting in a draft for a while. And I think what also seemed really nice was people were just around to support, to review, and were able to make that a priority. And it was really cool to see all the blog posts that are queued up for December as a result. +JOËL: People wrote some great stuff. So, I'm excited to see all of those come out. I think we've got pretty much a blog post every day coming out through almost the end of December. So, it's exciting to see that much content created. +STEPHANIE: Yeah. If our listeners want more thoughtbot content, check out our blog. +JOËL: So, as mentioned, we're recording this at the end of the year. And I thought it might be fun to do a bit of a retrospective on what this year has been like for you and I, Stephanie, both in terms of different work that we've done, the learnings we've had, but maybe also look back a little bit on 2023 for The Bike Shed and what that looked like. +STEPHANIE: Yes. I really enjoyed thinking about my year and kind of just reveling and having been doing this podcast for over a year now. And yeah, I'm excited to look back a little bit on both things we have mentioned on the show before and things maybe we haven't. To start, I'm wondering if you want to talk a little bit about some of our favorite episodes. +JOËL: Favorite episodes, yes. So, I've got a couple that are among my favorites. We did a lot of good episodes this year. I really liked them. But I really appreciated the episode we did on heuristics, that's Episode 398, where we got to talk a little bit about what goes into a good heuristic, how we tend to come up with them. A lot of those, like, guidelines and best practices that you hear people talk about in the software world and how to make your own but then also how to deal with the ones you hear from others in the software community. So, I think that was an episode that the idea, on the surface, seemed really basic, and then we went pretty deep with it. And that was really fun. +I think a second one that I really enjoyed was also the one that I did with Sara Jackson as a guest, talking about discrete math and its relevance to the day-to-day work that we do. That's Episode 374. We just had a lot of fun with that. I think that's a topic that more developers, more web developers, would benefit from just getting a little bit more discrete math in their lives. And also, there's a clip in there where Sara reinterprets a classic marketing jingle with some discrete math terms in there instead. It was a lot of fun. So, we'd recommend people checking that one out. +STEPHANIE: Nice. Yes. I also loved those episodes. The heuristics one was really great. I'm glad you mentioned it because one of my favorite episodes is kind of along a similar vein. It's one of the more recent ones that we did. It's Episode 405, where we did a bit of a retro on Sandi Metz' Rules For Developers. And those essentially are heuristics, right? And we got to kind of be like, hey, these are someone else's heuristics. How do we feel about them? Have we embodied them ourselves? Do we follow them? What parts do we take or leave? And I just remember having a really enjoyable conversation with you about that. +You and I have kind of treated this podcast a little bit like our own two-person book club [laughs]. So, it felt a little bit like that, right? Where we were kind of responding to, you know, something that we both have read up on, or tried, or whatever. So, that was a good one. +Another one of my favorite episodes was Episode 391: Learn with APPL [laughs], in which we basically developed our own learning framework, or actually, credit goes to former Bike Shed host, Steph Viccari, who came up with this fun, little acronym to talk about different things that we all kind of need in our work lives to be fulfilled. Our APPL stands for Adventure, Passion, Profit, and Low risk. +And that one was really fun just because it was, like, the opposite of what I just described where we're not discussing someone else's work but discovered our own thing out of, you know, these conversations that we have on the show, conversations we have with our co-workers. And yeah, I'm trying to make it a thing, so I'm plugging it again [laughs]. +JOËL: I did really like that episode. One, I think, you know, this APPL framework is a little bit playful, which makes it fun. But also, I think digging into it really gives some insight on the different aspects that are relevant when planning out further growth or where you want to invest your sort of professional development time. And so, breaking down those four elements led to some really insightful conversation around where do I want to invest time learning in the next year? +STEPHANIE: Yeah, absolutely. +JOËL: By the way, we're mentioning a bunch of our favorite things, some past episodes, and we'll be talking about a lot of other types of resources. We will be linking all of these in the show notes. So, for any of our listeners who are like, "Oh, I wonder what is that thing they mentioned," there's going to be a giant list that you can check out. +STEPHANIE: Yeah. I love whenever we are able to put out an episode with a long list of things [laughs]. +JOËL: It's one of the fun things that we get to do is like, oh yeah, we referenced all these things. And there is this sort of, like, further reading, more threads to pull on for people who might be interested. +So, you'd mentioned, Stephanie, that, you know, sometimes we kind of treat this as our own little mini, like, two-person book club. I know that you're a voracious reader, and you've mentioned so many books over the course of the year. Do you have maybe one or two books that have been kind of your favorites or that have stood out to you over 2023? +STEPHANIE: I do. I went back through my reading list in preparation for this episode and wanted to call out the couple of books that I finished. And I think I have, you know, I mentioned I was reading them along the way. But now I get to kind of see how having read them influenced my work life this past year, which is pretty cool. +So, one of them is Engineering Management for the Rest of Us by Sarah Drasner. And that's actually one that really stuck with me, even though I'm not a manager; I don't have any plans to become a manager. But one thing that she talks about early on is this idea of having a shared value system. And you can have that at the company level, right? You have your kind of corporate values. You can have that at the team level with this smaller group of people that you get to know better and kind of form relationships with. And then also, part of that is, like, knowing your individual values. +And having alignment in all three of those tiers is really important in being a functioning and fulfilled team, I think. And that is something that I don't think was really spelled out very explicitly for me before, but it was helpful in framing, like, past work experiences, where maybe I, like, didn't have that alignment and now identify why. And it has helped me this year as I think about my client work, too, and kind of where I sit from that perspective and helps me realize like, oh, like, this is why I'm feeling this way, and this is why it's not quite working. And, like, what do I do about it now? So, I really enjoyed that. +JOËL: Would you recommend this book to others who are maybe not considering a management path? +STEPHANIE: Yeah. +JOËL: So, even if you're staying in the IC track, at least for now, you think that's a really powerful book for other people. +STEPHANIE: Yeah, I would say so. You know, maybe not, like, all of it, but there's definitely parts that, you know, she's writing for the rest of us, like, all of us maybe not necessarily natural born leaders who knew that that's kind of what we wanted. And so, I can see how people, you know, who are uncertain or maybe even, like, really clearly, like, "I don't think that's for me," being able to get something out of, like, either those lessons in leadership or just to feel a bit, like, validated [laughs] about the type of work that they aren't interested in. +Another book that I want to plug real quick is Confident Ruby by Avdi Grimm. That one was one I referenced a lot this year, working with newer developers especially. And it actually provided a good heuristic [laughs] for me to talk about areas that we could improve code during code review. I think that wasn't really vocabulary that I'd used, you know, saying, like, "Hey, how confident is this code? How confident is this method and what it will receive and what it's returning?" And I remember, like, several conversations that I ended up having on my teams about, like, return types as a result and them having learned, like, a new way to view their code, and I thought that was really cool. +JOËL: I mean, learning to deal with uncertainty and nil in Ruby or maybe even, like, error states is just such a core part of writing software. I feel like this is something that I almost wish everyone was sort of assigned maybe, like, a year into their programming career because, you know, I think the first year there's just so many things you've got to learn, right? Like basic programming and, like, all these things. +But, like, you're looking maybe I can start going a little bit deeper into some topic. I think that some topic, like, pretty high up, would be building a mental model for how to deal with uncertainty because it's such a source of bugs. And Avdi Grimm's book, Confident Ruby, is...I would put that, yeah, definitely on a recommended reading list for everybody. +STEPHANIE: Yeah, I agree. And I think that's why I found myself, you know, then recommending it to other people on my team and kind of having something I can point to. And that was really helpful in the kind of mentorship that I wanted to offer. +JOËL: I did a deep dive into uncertainty and edge cases in programs several years back when I was getting into Elm. And I was giving a talk at Elm Europe about how Elm handles uncertainty, which is a little bit different than how Ruby does it. But a lot of the underlying concepts are very similar in terms of quarantining uncertainty and pushing it to the edges and things like that. Trying to write code that is more confident that is definitely a term that I used. And so Confident Ruby ended up being a little bit of an inspiration for my own journey there, and then, eventually, the talk that I gave that summarized my learnings there. +STEPHANIE: Nice. Do you have any reading recommendations or books that stood out to you this year? +JOËL: So, I've been reading two technical books kind of in tandem this year. I have not finished either of them, but I have been enjoying them. One is Sustainable Rails by David Bryant Copeland. We had an episode at the beginning of this year where we talked a little bit about our initial impressions from, I think, the first chapter of the book. But I really love that vocabulary of writing Ruby and Rails code, in particular, in a way that is sustainable for a team. And that premise, I think, just gives a really powerful mindset to approach structuring Rails apps. +And the other book that I've been reading is Domain Modeling Made Functional, so kind of looking at some domain-driven design ideas. But most of the literature is typically written to an object-oriented audience, so taking a look at it from more of a functional programming perspective has been really interesting. And then I've been, weirdly enough, taking some of those ideas and translating back into the object-oriented world to apply to code I'm writing in Ruby. I think that has been a very useful exercise. +STEPHANIE: That's awesome. And it's weird and cool how all those things end up converging, right? And exploring different paradigms really just lets you develop more insight into wherever you're working. +JOËL: Sometimes the sort of conversion step that you have to do, that translation, can be a good tool for kind of solidifying learnings or better understanding. So, I'm doing this sort of deep learning thing where I'm taking notes as I go along. And those notes are typically around, what other concepts can I connect ideas in the book? +So, I'll be reading and say, okay, on page 150, he mentioned this concept. This reminds me of this idea from TDD. I could see this applying in a different way in an object-oriented world. And interestingly, if you apply this, it sort of converges on maybe single responsibility or whatever other OO principle. And that's a really interesting connection. I always love it when you do see sort of two or three different angles converging together on the same idea. +STEPHANIE: Yeah, absolutely. +JOËL: I've written a blog post, I think, two years ago around how some theory from functional programming sort of OO best practices and then TDD all kind of converge on sort of the same approach to designing software. So, you can sort of go from either direction, and you kind of end in the same place or sort of end up rediscovering principles from the other two. We'll link that in the show notes. But that's something that I found was really exciting. It didn't directly come from this book because, again, I wrote this a couple of years ago. But it is always fun when you're exploring two or three different paradigms, and you find a convergence. It really deepens your understanding of what's happening. +STEPHANIE: Yeah, absolutely. I like what you said about how this book is different because it is making that connection between things that maybe seem less related on the surface. Like you're saying, there's other literature written about how domain modeling and object-oriented programming make more sense a little bit more together. But it is that, like, bringing in of different schools of thought that can lead to a lot of really interesting discovery about those foundational concepts. +JOËL: I feel like dabbling in other paradigms and in other languages has made me a better Ruby developer and a better OO programmer, a lot of the work I've done in Elm. This book that I'm reading is written in F#. And all these things I can kind of bring back, and I think, have made me a better Ruby developer. Have you had any experiences like that? +STEPHANIE: Yeah. I think I've talked a little bit about it on the show before, but I can't exactly recall. There were times when my exploration in static typing ended up giving me that different mindset in terms of the next time I was coding in Ruby after being in TypeScript for a while, I was, like, thinking in types a lot more, and I think maybe swung a little bit towards, like, not wanting to metaprogram as much [laughs]. But I think that it was a useful, like you said, exercise sometimes, too, and just, like, doing that conversion or translating in your head to see more options available to you, and then deciding where to go from there. +So, we've talked a bit about technical books that we've read. And now I kind of want to get into some in-person highlights for the year because you and I are both on the conference circuit and had some fun trips this year. +JOËL: Yeah. So, I spoke at RailsConf this spring. I gave a talk on discrete math and how it is relevant in day-to-day work for developers, actually inspired by that Bike Shed episode that I mentioned earlier. So, that was kind of fun, turning a Bike Shed episode into a conference talk. +And then just recently, I was at RubyConf in San Diego, and I gave a talk there around time. We often talk about time as a single quantity, but there's some subtle distinctions, so the difference between a moment in time versus a duration and some of the math that happens around that. And I gave a few sort of visual mental models to help people keep track of that. As of this recording, the talk is not out yet, so we're not going to be able to link to it. But if you're listening to this later in 2024, you can probably just Google RubyConf "Which Time Is It?" That's the name of the talk. And you'll be able to find it. +STEPHANIE: Awesome. So, as someone who is giving talks and attending conferences every year, I'm wondering, was this year particularly different in any way? Was there something that you've, like, experienced or felt differently community-wise in 2023? +JOËL: Conferences still feel a little bit smaller than they were pre-COVID. I think they are still bouncing back. But there's definitely an energy that's there that's nice to have on the conference scene. I don't know, have you experienced something similar? +STEPHANIE: I think I know what you're talking about where, you know, there was that time when we weren't really meeting in person. And so, now we're still kind of riding that wave of, like, getting together again and being able to celebrate and have fun in that way. I, this year, got to speak at Blue Ridge Ruby in June. And that was a first-time regional conference. And so, that was, I think, something I had noticed, too, is the emergence of regional conferences as being more viable options after not having conferences for a few years. +And as a regional conference, it was even smaller than the bigger national Ruby Central conferences. I really enjoyed the intimacy of that, where it was just a single track. So, everyone was watching talks together and then was on breaks together, so you could mingle. There was no FOMO of like, oh, like, I can't make this talk because I want to watch this other one. And that was kind of nice because I could, like, ask anyone, "What did you think of, like, X talk or like the one that we just kind of came out of and had that shared experience?" That was really great. +And I got to go tubing for the first time [laughs] in Asheville. That's a memory, but I am still thinking about that as we get into winter. I'm like, oh yeah, the glorious days of summer [laughs] when I was getting to float down a lazy river. +JOËL: Nice. I wasn't sure if this was floating down a lazy river on an inner tube or if this was someone takes you out on a lake with a speed boat, and you're getting pulled. +STEPHANIE: [laughs] That's true. As a person who likes to relax [laughs], I definitely prefer that kind of tubing over a speed boat [laughs]. +JOËL: What was the topic of your talk? +STEPHANIE: So, I got to give my talk about nonviolent communication in pair programming for a second time. And that was also my first time giving a talk for a second time [laughs]. That was cool, too, because I got to revisit something and go deeper and kind of integrate even more experiences I had. I just kind of realized that even if you produce content once, like, there's always ways to deepen it or shape it a little better, kind of, you know, just continually improving it and as you learn more and as you get more experience and change. +JOËL: Yeah. I've never given a talk twice, and now you've got me wondering if that's something I should do. Because making a bespoke talk for every conference is a lot of work, and it might be nice to be able to use it more than once. Especially I think for some of the regional conferences, there might be some value there in people who might not be able to go to a big national conference but would still like to see your talk live. Having a mix of maybe original content and then content that is sort of being reshared is probably a great combo for a regional conference. +STEPHANIE: Yeah, definitely. That's actually a really good idea, yeah, to just be able to have more people see that content and access it. I like that a lot. And I think it could be really cool for you because we were just talking about all the ways that our mental models evolve the more stuff that we read and consume. And I think there's a lot of value there. +One other conference that I went to this year that I just want to highlight because it was really cool that I got to do this: I went to RubyKaigi in Japan [laughs] back in the spring. And I had never gone to an international conference before, and now I'm itching to do more of that. So, it would be remiss not to mention it [laughs]. I'm definitely inspired to maybe check out some of the conferences outside of the U.S. in 2024. +I think I had always been a little intimidated. I was like, oh, like, it's so far [laughs]. Do I really have, like, that good of a reason to make a trip out there? But being able to meet Rubyists from different countries and seeing how it's being used in other parts of the world, I think, made me realize that like, oh yeah, like, beyond my little bubble, there's so many cool things happening and people out there who, again, like, have that shared love of Ruby. And connecting with them was, yeah, just so new and something that I would want to do more of. +So, another thing that we haven't yet gotten into is our actual work-work or our client work [laughs] that we do at thoughtbot for this year. Joël, I'm wondering, was there anything especially fun or anything that really stood out to you in terms of client work that you had to do this year? +JOËL: So, two things come to mind that were novel for me. One is I did a Rails integration against Snowflake, the data warehouse, using an ODBC connection. We're not going through an API; we're going through this DB connection. And I never had to do that before. I also got to work with the new-ish Rails multi-database support, which actually worked quite nice. That was, I think, a great learning experience. +Definitely ran into some weird edge cases, or some days, I was really frustrated. Some days, I was actually, like, digging into the source code of the C bindings of the ODBC gem. Those were not the best days. But definitely, I think, that kind of integration and then Snowflake as a technology was really interesting to explore. +The other one that's been really interesting, I think, has been going much deeper into the single sign-on world. I've been doing an integration against a kind of enterprise SAML server that wants to initiate sign-in requests from their portal. And this is a bit of an alphabet soup, but the term here is IdP-initiated SSO. +And so, I've been working with...it's a combination of this third-party kind of corporate SAML system, our application, which is a Rails app, and then Auth0 kind of sitting in the middle and getting all of them to talk to each other. There's a ridiculous number of redirects because we're talking SAML on one side and OIDC on the other and getting everything to line up correctly. But that's been a really fun, new set of things to learn. +STEPHANIE: Yeah, that does sound complicated [laughs] just based on what you shared with me, but very cool. And I was excited to hear that you had had a good experience with the Rails multi-database part because that was another thing that I remember being...it had piqued my interest when it first came out. I hope I get to, you know, utilize that feature on a project soon because that sounds really fun. +JOËL: One thing I've had to do for this SSO project is lean a lot on sequence diagrams, which are those diagrams that sort of show you, like, being redirected from different places, and, like, okay, server one talks to server two talks, to the browser. And so, when I've got so many different actors and sort of controllers being passed around everywhere, it's been hard to keep track of it in my head. And so, I've been doing a lot of these diagrams, both for myself to help understand it during development, and then also as documentation to share back with the team. +And I found that Mermaid.js supports sequence diagrams as a diagram type. Long-term listeners of the show will know that I am a sucker for a good diagram. I love using Mermaid for a lot of things because it's supported. You can embed it in a lot of places, including in GitHub comments, pull requests. You can use it in various note systems like Notion or Obsidian. And you can also just generate your own on mermaid.live. +And so, that's been really helpful to communicate with the rest of the team, like, "Hey, we've got this whole process where we've got 14 redirects across four different servers. Here's what it looks like. And here, like, we're getting a bug on, you know, redirect number 8 of 14. I wonder why," and then you can start a conversation around debugging that. +STEPHANIE: Cool. I was just about to ask what tool you're using to generate your sequence diagrams. I didn't know that Mermaid supported them. So, that's really neat. +JOËL: So, last year, when we kind of looked back over 2022, one thing that was really interesting that we did is we talked about what are articles that you find yourself linking to a lot that are just kind of things that maybe were on your mind or that were a big part of conversations that happened over the year? So, maybe for you, Stephanie, in 2023, what are one or two articles that you find yourself sort of constantly linking to other people? +STEPHANIE: Yes. I'm excited you asked about this. One of them is an article by a person named Cat Hicks, who has a PhD in experimental psychology. She's a data scientist and social scientist. And lately, she's been doing a lot of research into the sense of belonging on software teams. And I think that's a theme that I am personally really interested in, and I think has kind of been something more people are talking about in the last few years. And she is kind of taking that maybe more squishy idea and getting numbers for it and getting statistics, and I think that's really cool. +She points out belonging as, like, a different experience from just, like, happiness and fulfillment, and that really having an impact on how well a team is functioning. I got to share this with a few people who were, you know, just in that same boat of, like, trying to figure out, what are the behaviors kind of on my team that make me feel supported or not supported? +And there were a lot of interesting discussions that came out of sharing this article and kind of talking about, especially in software, where we can be a little bit dogmatic. And we've kind of actually joked about it on the podcast [chuckles] before about, like, we TDD or don't TDD, or, you know, we use X tool, and that's just like what we have to do here. She writes a little bit about how that can end up, you know, not encouraging people offering, like, differing opinions and being able to feel like they have a say in kind of, like, the team's direction. And yeah, I just really enjoyed a different way of thinking about it. Joël, what about you? What are some articles you got bookmarked? [chuckles] +JOËL: This year, I started using a bookmark manager, Raindrop.io. That's been nice because, for this episode, I could just look back on, what are some of my bookmarks this year? And be like, oh yeah, this is the thing that I have been using a lot. +So, an article that I've been linking is an article called Preemptive Pluralization is (Probably) Not Evil. And it kind of talks a little bit about how going from code that works over a collection of two items to a collection of, you know, 20 items is very easy. But sometimes, going from one to two can be really challenging. And when are the times where you might want to preemptively make something more than one item? So, maybe using it has many association rather than it has one or making an attribute a collection rather than a single item. +Controversial is not the word for it, but I think challenges a little bit of the way people typically like to write code. But across this year, I've run into multiple projects where they have been transitioning from one to many. That's been an interesting article to surface as part of those conversations. Whether your team wants to do this preemptively or whether they want to put it off and say in classic YAGNI (You Aren't Gonna Need It) form, "We'll make it single for now, and then we'll go plural," that's a conversation for your team. But I think this article is a great way to maybe frame the conversation. +STEPHANIE: Cool. Yeah, I really like that almost, like, a counterpoint to YAGNI [laughs], which I don't think I've ever heard anyone say that out loud [laughs] before. But as soon as you said preemptive pluralization is not evil, I thought about all the times that I've had to, like, write code, text in which a thing, a variable could be either one or many [laughs] things. And I was like, ooh, maybe this will solve that problem for me [laughs]. +JOËL: Speaking of pluralization, I'm sure you've been linking to more than just one article this year. Do you have another one that you find yourself coming up in conversations where you've always kind of like, "Hey, dropping this link," where it's almost like your thing? +STEPHANIE: Yes. And that is basically everything written by Mandy Brown [laughs], who is a work coach that I actually started working with this year. And one of the articles that really inspired me or really has been a topic of conversation among my friends and co-workers is she has a blog post called Digging Through the Ashes. And it's kind of a meditation on, like, post burnout or, like, what's next, and how we have used this word as kind of a catch-all to describe, you know, this collective sense of being just really tired or demoralized or just, like, in need of a break. +And what she offers in that post is kind of, like, some suggestions about, like, how can we be more specific here and really, you know, identify what it is that you're needing so that you can change how you engage with work? Because burnout can mean just that you are bored. It can mean that you are overworked. It can mean a lot of things for different people, right? +And so, I definitely don't think I'm alone [laughs] in kind of having to realize that, like, oh, these are the ways that my work is or isn't changing and, like, where do I want to go next so that I might feel more sustainable? I know that's, like, a keyword that we talked about earlier, too. And that, on one hand, is both personal but also technical, right? It, like, informs the kinds of decisions that we make around our codebase and what we are optimizing for. And yeah, it is both technical and cultural. And it's been a big theme for me this year [laughs]. +JOËL: Yeah. Would you say it's safe to say that sustainability would be, if you want to, like, put a single word on your theme for the year? Would that be a fair word to put there? +STEPHANIE: Yeah, I think so. Definitely discovering what that means for me and helping other people discover what that means for them, too. +JOËL: I feel like we kicked off the year 2023 by having that discussion of Sustainable Rails and how different technical practices can make the work there feel sustainable. So, I think that seems to have really carried through as a theme through the year for you. So, that's really cool to have seen that. And I'm sure listeners throughout the year have heard you mention these different books and articles. Maybe you've also been able to pick up a little bit on that. +So, I'm glad that we do this show because you get a little bit of, like, all the bits and pieces in the day-to-day, and then we aggregate it over a year, and you can look back. You can be like, "Oh yeah, I definitely see that theme in your work." +STEPHANIE: Yeah, I'm glad you pointed that out. It is actually really interesting to see how something that we had talked about early, early on just had that thread throughout the year. And speaking of sustainability, we are taking a little break from the show to enjoy the holidays. We'll be off for a few weeks, and we will be back with a new Bike Shed in January. +JOËL: Cheers to a new year. +STEPHANIE: Yeah, cheers to a new year. Wrapping up 2023. And we will see you all in 2024. +JOËL: On that note, shall we wrap up the whole year? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/ +referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza.

+ +

We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they’ve read and loved, and other highlights of 2023 (projects, conferences, etc).

+ +
+ + + +

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: I am so excited to talk about this. I'm, like, literally smiling [chuckles] because I'm so pumped. Sometimes, you know, we get on to record, and I'm like, oh, I got to think of something that's new, like, my life is so boring. I have nothing to share. But today, I am excited to tell you about [chuckles] the holiday cookie swap that I'm hosting this Sunday [laughs] that I haven't been able to stop thinking about or just thinking about all the cookies that I'm going to get to eat.

+ +

It's going to be my first time throwing this kind of shindig, and I'm so pleased with myself because it's such a great idea. You know, it's like, you get to share cookies, and you get to have all different types of cookies, and then people get to take them home. And I get to see all my friends. And I'm really [chuckles] looking forward to it.

+ +

JOËL: I don't think I've ever been to a cookie swap event. How does that work? Everybody shows up with cookies, and then you leave with what you want?

+ +

STEPHANIE: That's kind of the plan. I think it's not really a...there's no rules [laughs]. You can make it whatever you want it to be. But I'm asking everyone to bring, like, two dozen cookies. And, you know, I'm hoping for a lot of fun variety. Myself I'm planning on making these pistachio olive oil cookies with a lemon glaze and also, maybe, like, a chewy ginger cookie. I haven't decided if I'm going to go so extra to make two types, but we'll see.

+ +

And yeah, we'll, you know, probably have some drinks and be playing Christmas music, and yeah, we'll just hang out. And I'm hoping that everyone can kind of, like, take home a little goodie bag of cookies as well because I don't think we'll be going through all of them.

+ +

JOËL: Hearing you talk about this gave me an absolutely terrible idea.

+ +

STEPHANIE: Terrible or terribly awesome? [laughs]

+ +

JOËL: So, imagine you have the equivalent of, let's say, a LAN party. You all show up with your laptops.

+ +

STEPHANIE: [laughs]

+ +

JOËL: You're on a network, and then you swap browser cookies randomly.

+ +

STEPHANIE: [laughs] Oh no. That would be really funny. That's a developer's take on a cookie party [laughs] if I've ever heard one.

+ +

JOËL: Slightly terrifying. Now I'm just browsing, and all of a sudden, I guess I'm logged into your Facebook or something. Maybe you only swap the tracking cookies. So, I'm not actually logged into your Facebook, but I just get to see the different ad networks it would typically show you, and you would see my ads. That's maybe kind of fun or maybe terrifying, depending on what kind of ads you normally see.

+ +

STEPHANIE: That's really funny. I'm thinking about how it would just be probably very misleading and confusing for those [laughs] analytics spenders, but that's totally fine, too. Might I suggest also having real cookies to munch on as well while you are enjoying [laughs] this browser cookie-swapping party?

+ +

JOËL: I 100% agree.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I'm curious: where do you stand on raisins in oatmeal cookies?

+ +

STEPHANIE: Ooh.

+ +

JOËL: This is a divisive question.

+ +

STEPHANIE: They're fine. I'll let other people eat them. And occasionally, I will also eat an oatmeal cookie with raisins, but I much prefer if the raisins are chocolate chips [chuckles].

+ +

JOËL: That is the correct answer.

+ +

STEPHANIE: [laughs] Thank you. You know, I understand that people like them. They're not for me [laughs].

+ +

JOËL: It's okay. Fans can send us hate mail about why we're wrong about oatmeal cookies.

+ +

STEPHANIE: Yeah, honestly, that's something that I'm okay with being wrong about on the internet [laughs]. So, Joël, what's new in your world?

+ +

JOËL: So, as of this recording, we've just recently done thoughtbot's end-of-the-year hackathon, what we call Ralphapalooza. And this is sort of a time where you kind of get to do pretty much any sort of company or programming-related activity that you want as long as...you have to pitch it and get at least two other colleagues to join you on the project, and then you've got two days to work on it. And then you can share back to the team what you've done.

+ +

I was on a project where we were trying to write a lot of blog posts for the thoughtbot blog. And so, we're just kind of getting together and pitching ideas, reviewing each other's articles, writing things at a pretty intense rate for a couple of days, trying to flood the blog with articles for the next few weeks. So, if you're following the blog and as the time this episode gets released, you're like, "Wow, there's been a lot of articles from the thoughtbot blog recently," that's why.

+ +

STEPHANIE: Yes, that's awesome. I love how much energy that the blog post-writing party garnered. Like, I was just kind of observing from afar, but it sounds like, you know, people who maybe had started posts, like, throughout the year had dedicated time and a good reason to revisit them, even if they had been, you know, kind of just, like, sitting in a draft for a while. And I think what also seemed really nice was people were just around to support, to review, and were able to make that a priority. And it was really cool to see all the blog posts that are queued up for December as a result.

+ +

JOËL: People wrote some great stuff. So, I'm excited to see all of those come out. I think we've got pretty much a blog post every day coming out through almost the end of December. So, it's exciting to see that much content created.

+ +

STEPHANIE: Yeah. If our listeners want more thoughtbot content, check out our blog.

+ +

JOËL: So, as mentioned, we're recording this at the end of the year. And I thought it might be fun to do a bit of a retrospective on what this year has been like for you and I, Stephanie, both in terms of different work that we've done, the learnings we've had, but maybe also look back a little bit on 2023 for The Bike Shed and what that looked like.

+ +

STEPHANIE: Yes. I really enjoyed thinking about my year and kind of just reveling and having been doing this podcast for over a year now. And yeah, I'm excited to look back a little bit on both things we have mentioned on the show before and things maybe we haven't. To start, I'm wondering if you want to talk a little bit about some of our favorite episodes.

+ +

JOËL: Favorite episodes, yes. So, I've got a couple that are among my favorites. We did a lot of good episodes this year. I really liked them. But I really appreciated the episode we did on heuristics, that's Episode 398, where we got to talk a little bit about what goes into a good heuristic, how we tend to come up with them. A lot of those, like, guidelines and best practices that you hear people talk about in the software world and how to make your own but then also how to deal with the ones you hear from others in the software community. So, I think that was an episode that the idea, on the surface, seemed really basic, and then we went pretty deep with it. And that was really fun.

+ +

I think a second one that I really enjoyed was also the one that I did with Sara Jackson as a guest, talking about discrete math and its relevance to the day-to-day work that we do. That's Episode 374. We just had a lot of fun with that. I think that's a topic that more developers, more web developers, would benefit from just getting a little bit more discrete math in their lives. And also, there's a clip in there where Sara reinterprets a classic marketing jingle with some discrete math terms in there instead. It was a lot of fun. So, we'd recommend people checking that one out.

+ +

STEPHANIE: Nice. Yes. I also loved those episodes. The heuristics one was really great. I'm glad you mentioned it because one of my favorite episodes is kind of along a similar vein. It's one of the more recent ones that we did. It's Episode 405, where we did a bit of a retro on Sandi Metz' Rules For Developers. And those essentially are heuristics, right? And we got to kind of be like, hey, these are someone else's heuristics. How do we feel about them? Have we embodied them ourselves? Do we follow them? What parts do we take or leave? And I just remember having a really enjoyable conversation with you about that.

+ +

You and I have kind of treated this podcast a little bit like our own two-person book club [laughs]. So, it felt a little bit like that, right? Where we were kind of responding to, you know, something that we both have read up on, or tried, or whatever. So, that was a good one.

+ +

Another one of my favorite episodes was Episode 391: Learn with APPL [laughs], in which we basically developed our own learning framework, or actually, credit goes to former Bike Shed host, Steph Viccari, who came up with this fun, little acronym to talk about different things that we all kind of need in our work lives to be fulfilled. Our APPL stands for Adventure, Passion, Profit, and Low risk.

+ +

And that one was really fun just because it was, like, the opposite of what I just described where we're not discussing someone else's work but discovered our own thing out of, you know, these conversations that we have on the show, conversations we have with our co-workers. And yeah, I'm trying to make it a thing, so I'm plugging it again [laughs].

+ +

JOËL: I did really like that episode. One, I think, you know, this APPL framework is a little bit playful, which makes it fun. But also, I think digging into it really gives some insight on the different aspects that are relevant when planning out further growth or where you want to invest your sort of professional development time. And so, breaking down those four elements led to some really insightful conversation around where do I want to invest time learning in the next year?

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: By the way, we're mentioning a bunch of our favorite things, some past episodes, and we'll be talking about a lot of other types of resources. We will be linking all of these in the show notes. So, for any of our listeners who are like, "Oh, I wonder what is that thing they mentioned," there's going to be a giant list that you can check out.

+ +

STEPHANIE: Yeah. I love whenever we are able to put out an episode with a long list of things [laughs].

+ +

JOËL: It's one of the fun things that we get to do is like, oh yeah, we referenced all these things. And there is this sort of, like, further reading, more threads to pull on for people who might be interested.

+ +

So, you'd mentioned, Stephanie, that, you know, sometimes we kind of treat this as our own little mini, like, two-person book club. I know that you're a voracious reader, and you've mentioned so many books over the course of the year. Do you have maybe one or two books that have been kind of your favorites or that have stood out to you over 2023?

+ +

STEPHANIE: I do. I went back through my reading list in preparation for this episode and wanted to call out the couple of books that I finished. And I think I have, you know, I mentioned I was reading them along the way. But now I get to kind of see how having read them influenced my work life this past year, which is pretty cool.

+ +

So, one of them is Engineering Management for the Rest of Us by Sarah Drasner. And that's actually one that really stuck with me, even though I'm not a manager; I don't have any plans to become a manager. But one thing that she talks about early on is this idea of having a shared value system. And you can have that at the company level, right? You have your kind of corporate values. You can have that at the team level with this smaller group of people that you get to know better and kind of form relationships with. And then also, part of that is, like, knowing your individual values.

+ +

And having alignment in all three of those tiers is really important in being a functioning and fulfilled team, I think. And that is something that I don't think was really spelled out very explicitly for me before, but it was helpful in framing, like, past work experiences, where maybe I, like, didn't have that alignment and now identify why. And it has helped me this year as I think about my client work, too, and kind of where I sit from that perspective and helps me realize like, oh, like, this is why I'm feeling this way, and this is why it's not quite working. And, like, what do I do about it now? So, I really enjoyed that.

+ +

JOËL: Would you recommend this book to others who are maybe not considering a management path?

+ +

STEPHANIE: Yeah.

+ +

JOËL: So, even if you're staying in the IC track, at least for now, you think that's a really powerful book for other people.

+ +

STEPHANIE: Yeah, I would say so. You know, maybe not, like, all of it, but there's definitely parts that, you know, she's writing for the rest of us, like, all of us maybe not necessarily natural born leaders who knew that that's kind of what we wanted. And so, I can see how people, you know, who are uncertain or maybe even, like, really clearly, like, "I don't think that's for me," being able to get something out of, like, either those lessons in leadership or just to feel a bit, like, validated [laughs] about the type of work that they aren't interested in.

+ +

Another book that I want to plug real quick is Confident Ruby by Avdi Grimm. That one was one I referenced a lot this year, working with newer developers especially. And it actually provided a good heuristic [laughs] for me to talk about areas that we could improve code during code review. I think that wasn't really vocabulary that I'd used, you know, saying, like, "Hey, how confident is this code? How confident is this method and what it will receive and what it's returning?" And I remember, like, several conversations that I ended up having on my teams about, like, return types as a result and them having learned, like, a new way to view their code, and I thought that was really cool.

+ +

JOËL: I mean, learning to deal with uncertainty and nil in Ruby or maybe even, like, error states is just such a core part of writing software. I feel like this is something that I almost wish everyone was sort of assigned maybe, like, a year into their programming career because, you know, I think the first year there's just so many things you've got to learn, right? Like basic programming and, like, all these things.

+ +

But, like, you're looking maybe I can start going a little bit deeper into some topic. I think that some topic, like, pretty high up, would be building a mental model for how to deal with uncertainty because it's such a source of bugs. And Avdi Grimm's book, Confident Ruby, is...I would put that, yeah, definitely on a recommended reading list for everybody.

+ +

STEPHANIE: Yeah, I agree. And I think that's why I found myself, you know, then recommending it to other people on my team and kind of having something I can point to. And that was really helpful in the kind of mentorship that I wanted to offer.

+ +

JOËL: I did a deep dive into uncertainty and edge cases in programs several years back when I was getting into Elm. And I was giving a talk at Elm Europe about how Elm handles uncertainty, which is a little bit different than how Ruby does it. But a lot of the underlying concepts are very similar in terms of quarantining uncertainty and pushing it to the edges and things like that. Trying to write code that is more confident that is definitely a term that I used. And so Confident Ruby ended up being a little bit of an inspiration for my own journey there, and then, eventually, the talk that I gave that summarized my learnings there.

+ +

STEPHANIE: Nice. Do you have any reading recommendations or books that stood out to you this year?

+ +

JOËL: So, I've been reading two technical books kind of in tandem this year. I have not finished either of them, but I have been enjoying them. One is Sustainable Rails by David Bryant Copeland. We had an episode at the beginning of this year where we talked a little bit about our initial impressions from, I think, the first chapter of the book. But I really love that vocabulary of writing Ruby and Rails code, in particular, in a way that is sustainable for a team. And that premise, I think, just gives a really powerful mindset to approach structuring Rails apps.

+ +

And the other book that I've been reading is Domain Modeling Made Functional, so kind of looking at some domain-driven design ideas. But most of the literature is typically written to an object-oriented audience, so taking a look at it from more of a functional programming perspective has been really interesting. And then I've been, weirdly enough, taking some of those ideas and translating back into the object-oriented world to apply to code I'm writing in Ruby. I think that has been a very useful exercise.

+ +

STEPHANIE: That's awesome. And it's weird and cool how all those things end up converging, right? And exploring different paradigms really just lets you develop more insight into wherever you're working.

+ +

JOËL: Sometimes the sort of conversion step that you have to do, that translation, can be a good tool for kind of solidifying learnings or better understanding. So, I'm doing this sort of deep learning thing where I'm taking notes as I go along. And those notes are typically around, what other concepts can I connect ideas in the book?

+ +

So, I'll be reading and say, okay, on page 150, he mentioned this concept. This reminds me of this idea from TDD. I could see this applying in a different way in an object-oriented world. And interestingly, if you apply this, it sort of converges on maybe single responsibility or whatever other OO principle. And that's a really interesting connection. I always love it when you do see sort of two or three different angles converging together on the same idea.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I've written a blog post, I think, two years ago around how some theory from functional programming sort of OO best practices and then TDD all kind of converge on sort of the same approach to designing software. So, you can sort of go from either direction, and you kind of end in the same place or sort of end up rediscovering principles from the other two. We'll link that in the show notes. But that's something that I found was really exciting. It didn't directly come from this book because, again, I wrote this a couple of years ago. But it is always fun when you're exploring two or three different paradigms, and you find a convergence. It really deepens your understanding of what's happening.

+ +

STEPHANIE: Yeah, absolutely. I like what you said about how this book is different because it is making that connection between things that maybe seem less related on the surface. Like you're saying, there's other literature written about how domain modeling and object-oriented programming make more sense a little bit more together. But it is that, like, bringing in of different schools of thought that can lead to a lot of really interesting discovery about those foundational concepts.

+ +

JOËL: I feel like dabbling in other paradigms and in other languages has made me a better Ruby developer and a better OO programmer, a lot of the work I've done in Elm. This book that I'm reading is written in F#. And all these things I can kind of bring back, and I think, have made me a better Ruby developer. Have you had any experiences like that?

+ +

STEPHANIE: Yeah. I think I've talked a little bit about it on the show before, but I can't exactly recall. There were times when my exploration in static typing ended up giving me that different mindset in terms of the next time I was coding in Ruby after being in TypeScript for a while, I was, like, thinking in types a lot more, and I think maybe swung a little bit towards, like, not wanting to metaprogram as much [laughs]. But I think that it was a useful, like you said, exercise sometimes, too, and just, like, doing that conversion or translating in your head to see more options available to you, and then deciding where to go from there.

+ +

So, we've talked a bit about technical books that we've read. And now I kind of want to get into some in-person highlights for the year because you and I are both on the conference circuit and had some fun trips this year.

+ +

JOËL: Yeah. So, I spoke at RailsConf this spring. I gave a talk on discrete math and how it is relevant in day-to-day work for developers, actually inspired by that Bike Shed episode that I mentioned earlier. So, that was kind of fun, turning a Bike Shed episode into a conference talk.

+ +

And then just recently, I was at RubyConf in San Diego, and I gave a talk there around time. We often talk about time as a single quantity, but there's some subtle distinctions, so the difference between a moment in time versus a duration and some of the math that happens around that. And I gave a few sort of visual mental models to help people keep track of that. As of this recording, the talk is not out yet, so we're not going to be able to link to it. But if you're listening to this later in 2024, you can probably just Google RubyConf "Which Time Is It?" That's the name of the talk. And you'll be able to find it.

+ +

STEPHANIE: Awesome. So, as someone who is giving talks and attending conferences every year, I'm wondering, was this year particularly different in any way? Was there something that you've, like, experienced or felt differently community-wise in 2023?

+ +

JOËL: Conferences still feel a little bit smaller than they were pre-COVID. I think they are still bouncing back. But there's definitely an energy that's there that's nice to have on the conference scene. I don't know, have you experienced something similar?

+ +

STEPHANIE: I think I know what you're talking about where, you know, there was that time when we weren't really meeting in person. And so, now we're still kind of riding that wave of, like, getting together again and being able to celebrate and have fun in that way. I, this year, got to speak at Blue Ridge Ruby in June. And that was a first-time regional conference. And so, that was, I think, something I had noticed, too, is the emergence of regional conferences as being more viable options after not having conferences for a few years.

+ +

And as a regional conference, it was even smaller than the bigger national Ruby Central conferences. I really enjoyed the intimacy of that, where it was just a single track. So, everyone was watching talks together and then was on breaks together, so you could mingle. There was no FOMO of like, oh, like, I can't make this talk because I want to watch this other one. And that was kind of nice because I could, like, ask anyone, "What did you think of, like, X talk or like the one that we just kind of came out of and had that shared experience?" That was really great.

+ +

And I got to go tubing for the first time [laughs] in Asheville. That's a memory, but I am still thinking about that as we get into winter. I'm like, oh yeah, the glorious days of summer [laughs] when I was getting to float down a lazy river.

+ +

JOËL: Nice. I wasn't sure if this was floating down a lazy river on an inner tube or if this was someone takes you out on a lake with a speed boat, and you're getting pulled.

+ +

STEPHANIE: [laughs] That's true. As a person who likes to relax [laughs], I definitely prefer that kind of tubing over a speed boat [laughs].

+ +

JOËL: What was the topic of your talk?

+ +

STEPHANIE: So, I got to give my talk about nonviolent communication in pair programming for a second time. And that was also my first time giving a talk for a second time [laughs]. That was cool, too, because I got to revisit something and go deeper and kind of integrate even more experiences I had. I just kind of realized that even if you produce content once, like, there's always ways to deepen it or shape it a little better, kind of, you know, just continually improving it and as you learn more and as you get more experience and change.

+ +

JOËL: Yeah. I've never given a talk twice, and now you've got me wondering if that's something I should do. Because making a bespoke talk for every conference is a lot of work, and it might be nice to be able to use it more than once. Especially I think for some of the regional conferences, there might be some value there in people who might not be able to go to a big national conference but would still like to see your talk live. Having a mix of maybe original content and then content that is sort of being reshared is probably a great combo for a regional conference.

+ +

STEPHANIE: Yeah, definitely. That's actually a really good idea, yeah, to just be able to have more people see that content and access it. I like that a lot. And I think it could be really cool for you because we were just talking about all the ways that our mental models evolve the more stuff that we read and consume. And I think there's a lot of value there.

+ +

One other conference that I went to this year that I just want to highlight because it was really cool that I got to do this: I went to RubyKaigi in Japan [laughs] back in the spring. And I had never gone to an international conference before, and now I'm itching to do more of that. So, it would be remiss not to mention it [laughs]. I'm definitely inspired to maybe check out some of the conferences outside of the U.S. in 2024.

+ +

I think I had always been a little intimidated. I was like, oh, like, it's so far [laughs]. Do I really have, like, that good of a reason to make a trip out there? But being able to meet Rubyists from different countries and seeing how it's being used in other parts of the world, I think, made me realize that like, oh yeah, like, beyond my little bubble, there's so many cool things happening and people out there who, again, like, have that shared love of Ruby. And connecting with them was, yeah, just so new and something that I would want to do more of.

+ +

So, another thing that we haven't yet gotten into is our actual work-work or our client work [laughs] that we do at thoughtbot for this year. Joël, I'm wondering, was there anything especially fun or anything that really stood out to you in terms of client work that you had to do this year?

+ +

JOËL: So, two things come to mind that were novel for me. One is I did a Rails integration against Snowflake, the data warehouse, using an ODBC connection. We're not going through an API; we're going through this DB connection. And I never had to do that before. I also got to work with the new-ish Rails multi-database support, which actually worked quite nice. That was, I think, a great learning experience.

+ +

Definitely ran into some weird edge cases, or some days, I was really frustrated. Some days, I was actually, like, digging into the source code of the C bindings of the ODBC gem. Those were not the best days. But definitely, I think, that kind of integration and then Snowflake as a technology was really interesting to explore.

+ +

The other one that's been really interesting, I think, has been going much deeper into the single sign-on world. I've been doing an integration against a kind of enterprise SAML server that wants to initiate sign-in requests from their portal. And this is a bit of an alphabet soup, but the term here is IdP-initiated SSO.

+ +

And so, I've been working with...it's a combination of this third-party kind of corporate SAML system, our application, which is a Rails app, and then Auth0 kind of sitting in the middle and getting all of them to talk to each other. There's a ridiculous number of redirects because we're talking SAML on one side and OIDC on the other and getting everything to line up correctly. But that's been a really fun, new set of things to learn.

+ +

STEPHANIE: Yeah, that does sound complicated [laughs] just based on what you shared with me, but very cool. And I was excited to hear that you had had a good experience with the Rails multi-database part because that was another thing that I remember being...it had piqued my interest when it first came out. I hope I get to, you know, utilize that feature on a project soon because that sounds really fun.

+ +

JOËL: One thing I've had to do for this SSO project is lean a lot on sequence diagrams, which are those diagrams that sort of show you, like, being redirected from different places, and, like, okay, server one talks to server two talks, to the browser. And so, when I've got so many different actors and sort of controllers being passed around everywhere, it's been hard to keep track of it in my head. And so, I've been doing a lot of these diagrams, both for myself to help understand it during development, and then also as documentation to share back with the team.

+ +

And I found that Mermaid.js supports sequence diagrams as a diagram type. Long-term listeners of the show will know that I am a sucker for a good diagram. I love using Mermaid for a lot of things because it's supported. You can embed it in a lot of places, including in GitHub comments, pull requests. You can use it in various note systems like Notion or Obsidian. And you can also just generate your own on mermaid.live.

+ +

And so, that's been really helpful to communicate with the rest of the team, like, "Hey, we've got this whole process where we've got 14 redirects across four different servers. Here's what it looks like. And here, like, we're getting a bug on, you know, redirect number 8 of 14. I wonder why," and then you can start a conversation around debugging that.

+ +

STEPHANIE: Cool. I was just about to ask what tool you're using to generate your sequence diagrams. I didn't know that Mermaid supported them. So, that's really neat.

+ +

JOËL: So, last year, when we kind of looked back over 2022, one thing that was really interesting that we did is we talked about what are articles that you find yourself linking to a lot that are just kind of things that maybe were on your mind or that were a big part of conversations that happened over the year? So, maybe for you, Stephanie, in 2023, what are one or two articles that you find yourself sort of constantly linking to other people?

+ +

STEPHANIE: Yes. I'm excited you asked about this. One of them is an article by a person named Cat Hicks, who has a PhD in experimental psychology. She's a data scientist and social scientist. And lately, she's been doing a lot of research into the sense of belonging on software teams. And I think that's a theme that I am personally really interested in, and I think has kind of been something more people are talking about in the last few years. And she is kind of taking that maybe more squishy idea and getting numbers for it and getting statistics, and I think that's really cool.

+ +

She points out belonging as, like, a different experience from just, like, happiness and fulfillment, and that really having an impact on how well a team is functioning. I got to share this with a few people who were, you know, just in that same boat of, like, trying to figure out, what are the behaviors kind of on my team that make me feel supported or not supported?

+ +

And there were a lot of interesting discussions that came out of sharing this article and kind of talking about, especially in software, where we can be a little bit dogmatic. And we've kind of actually joked about it on the podcast [chuckles] before about, like, we TDD or don't TDD, or, you know, we use X tool, and that's just like what we have to do here. She writes a little bit about how that can end up, you know, not encouraging people offering, like, differing opinions and being able to feel like they have a say in kind of, like, the team's direction. And yeah, I just really enjoyed a different way of thinking about it. Joël, what about you? What are some articles you got bookmarked? [chuckles]

+ +

JOËL: This year, I started using a bookmark manager, Raindrop.io. That's been nice because, for this episode, I could just look back on, what are some of my bookmarks this year? And be like, oh yeah, this is the thing that I have been using a lot.

+ +

So, an article that I've been linking is an article called Preemptive Pluralization is (Probably) Not Evil. And it kind of talks a little bit about how going from code that works over a collection of two items to a collection of, you know, 20 items is very easy. But sometimes, going from one to two can be really challenging. And when are the times where you might want to preemptively make something more than one item? So, maybe using it has many association rather than it has one or making an attribute a collection rather than a single item.

+ +

Controversial is not the word for it, but I think challenges a little bit of the way people typically like to write code. But across this year, I've run into multiple projects where they have been transitioning from one to many. That's been an interesting article to surface as part of those conversations. Whether your team wants to do this preemptively or whether they want to put it off and say in classic YAGNI (You Aren't Gonna Need It) form, "We'll make it single for now, and then we'll go plural," that's a conversation for your team. But I think this article is a great way to maybe frame the conversation.

+ +

STEPHANIE: Cool. Yeah, I really like that almost, like, a counterpoint to YAGNI [laughs], which I don't think I've ever heard anyone say that out loud [laughs] before. But as soon as you said preemptive pluralization is not evil, I thought about all the times that I've had to, like, write code, text in which a thing, a variable could be either one or many [laughs] things. And I was like, ooh, maybe this will solve that problem for me [laughs].

+ +

JOËL: Speaking of pluralization, I'm sure you've been linking to more than just one article this year. Do you have another one that you find yourself coming up in conversations where you've always kind of like, "Hey, dropping this link," where it's almost like your thing?

+ +

STEPHANIE: Yes. And that is basically everything written by Mandy Brown [laughs], who is a work coach that I actually started working with this year. And one of the articles that really inspired me or really has been a topic of conversation among my friends and co-workers is she has a blog post called Digging Through the Ashes. And it's kind of a meditation on, like, post burnout or, like, what's next, and how we have used this word as kind of a catch-all to describe, you know, this collective sense of being just really tired or demoralized or just, like, in need of a break.

+ +

And what she offers in that post is kind of, like, some suggestions about, like, how can we be more specific here and really, you know, identify what it is that you're needing so that you can change how you engage with work? Because burnout can mean just that you are bored. It can mean that you are overworked. It can mean a lot of things for different people, right?

+ +

And so, I definitely don't think I'm alone [laughs] in kind of having to realize that, like, oh, these are the ways that my work is or isn't changing and, like, where do I want to go next so that I might feel more sustainable? I know that's, like, a keyword that we talked about earlier, too. And that, on one hand, is both personal but also technical, right? It, like, informs the kinds of decisions that we make around our codebase and what we are optimizing for. And yeah, it is both technical and cultural. And it's been a big theme for me this year [laughs].

+ +

JOËL: Yeah. Would you say it's safe to say that sustainability would be, if you want to, like, put a single word on your theme for the year? Would that be a fair word to put there?

+ +

STEPHANIE: Yeah, I think so. Definitely discovering what that means for me and helping other people discover what that means for them, too.

+ +

JOËL: I feel like we kicked off the year 2023 by having that discussion of Sustainable Rails and how different technical practices can make the work there feel sustainable. So, I think that seems to have really carried through as a theme through the year for you. So, that's really cool to have seen that. And I'm sure listeners throughout the year have heard you mention these different books and articles. Maybe you've also been able to pick up a little bit on that.

+ +

So, I'm glad that we do this show because you get a little bit of, like, all the bits and pieces in the day-to-day, and then we aggregate it over a year, and you can look back. You can be like, "Oh yeah, I definitely see that theme in your work."

+ +

STEPHANIE: Yeah, I'm glad you pointed that out. It is actually really interesting to see how something that we had talked about early, early on just had that thread throughout the year. And speaking of sustainability, we are taking a little break from the show to enjoy the holidays. We'll be off for a few weeks, and we will be back with a new Bike Shed in January.

+ +

JOËL: Cheers to a new year.

+ +

STEPHANIE: Yeah, cheers to a new year. Wrapping up 2023. And we will see you all in 2024.

+ +

JOËL: On that note, shall we wrap up the whole year?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/
+referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza.

+ +

We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they’ve read and loved, and other highlights of 2023 (projects, conferences, etc).

+ +
+ + + +

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: I am so excited to talk about this. I'm, like, literally smiling [chuckles] because I'm so pumped. Sometimes, you know, we get on to record, and I'm like, oh, I got to think of something that's new, like, my life is so boring. I have nothing to share. But today, I am excited to tell you about [chuckles] the holiday cookie swap that I'm hosting this Sunday [laughs] that I haven't been able to stop thinking about or just thinking about all the cookies that I'm going to get to eat.

+ +

It's going to be my first time throwing this kind of shindig, and I'm so pleased with myself because it's such a great idea. You know, it's like, you get to share cookies, and you get to have all different types of cookies, and then people get to take them home. And I get to see all my friends. And I'm really [chuckles] looking forward to it.

+ +

JOËL: I don't think I've ever been to a cookie swap event. How does that work? Everybody shows up with cookies, and then you leave with what you want?

+ +

STEPHANIE: That's kind of the plan. I think it's not really a...there's no rules [laughs]. You can make it whatever you want it to be. But I'm asking everyone to bring, like, two dozen cookies. And, you know, I'm hoping for a lot of fun variety. Myself I'm planning on making these pistachio olive oil cookies with a lemon glaze and also, maybe, like, a chewy ginger cookie. I haven't decided if I'm going to go so extra to make two types, but we'll see.

+ +

And yeah, we'll, you know, probably have some drinks and be playing Christmas music, and yeah, we'll just hang out. And I'm hoping that everyone can kind of, like, take home a little goodie bag of cookies as well because I don't think we'll be going through all of them.

+ +

JOËL: Hearing you talk about this gave me an absolutely terrible idea.

+ +

STEPHANIE: Terrible or terribly awesome? [laughs]

+ +

JOËL: So, imagine you have the equivalent of, let's say, a LAN party. You all show up with your laptops.

+ +

STEPHANIE: [laughs]

+ +

JOËL: You're on a network, and then you swap browser cookies randomly.

+ +

STEPHANIE: [laughs] Oh no. That would be really funny. That's a developer's take on a cookie party [laughs] if I've ever heard one.

+ +

JOËL: Slightly terrifying. Now I'm just browsing, and all of a sudden, I guess I'm logged into your Facebook or something. Maybe you only swap the tracking cookies. So, I'm not actually logged into your Facebook, but I just get to see the different ad networks it would typically show you, and you would see my ads. That's maybe kind of fun or maybe terrifying, depending on what kind of ads you normally see.

+ +

STEPHANIE: That's really funny. I'm thinking about how it would just be probably very misleading and confusing for those [laughs] analytics spenders, but that's totally fine, too. Might I suggest also having real cookies to munch on as well while you are enjoying [laughs] this browser cookie-swapping party?

+ +

JOËL: I 100% agree.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I'm curious: where do you stand on raisins in oatmeal cookies?

+ +

STEPHANIE: Ooh.

+ +

JOËL: This is a divisive question.

+ +

STEPHANIE: They're fine. I'll let other people eat them. And occasionally, I will also eat an oatmeal cookie with raisins, but I much prefer if the raisins are chocolate chips [chuckles].

+ +

JOËL: That is the correct answer.

+ +

STEPHANIE: [laughs] Thank you. You know, I understand that people like them. They're not for me [laughs].

+ +

JOËL: It's okay. Fans can send us hate mail about why we're wrong about oatmeal cookies.

+ +

STEPHANIE: Yeah, honestly, that's something that I'm okay with being wrong about on the internet [laughs]. So, Joël, what's new in your world?

+ +

JOËL: So, as of this recording, we've just recently done thoughtbot's end-of-the-year hackathon, what we call Ralphapalooza. And this is sort of a time where you kind of get to do pretty much any sort of company or programming-related activity that you want as long as...you have to pitch it and get at least two other colleagues to join you on the project, and then you've got two days to work on it. And then you can share back to the team what you've done.

+ +

I was on a project where we were trying to write a lot of blog posts for the thoughtbot blog. And so, we're just kind of getting together and pitching ideas, reviewing each other's articles, writing things at a pretty intense rate for a couple of days, trying to flood the blog with articles for the next few weeks. So, if you're following the blog and as the time this episode gets released, you're like, "Wow, there's been a lot of articles from the thoughtbot blog recently," that's why.

+ +

STEPHANIE: Yes, that's awesome. I love how much energy that the blog post-writing party garnered. Like, I was just kind of observing from afar, but it sounds like, you know, people who maybe had started posts, like, throughout the year had dedicated time and a good reason to revisit them, even if they had been, you know, kind of just, like, sitting in a draft for a while. And I think what also seemed really nice was people were just around to support, to review, and were able to make that a priority. And it was really cool to see all the blog posts that are queued up for December as a result.

+ +

JOËL: People wrote some great stuff. So, I'm excited to see all of those come out. I think we've got pretty much a blog post every day coming out through almost the end of December. So, it's exciting to see that much content created.

+ +

STEPHANIE: Yeah. If our listeners want more thoughtbot content, check out our blog.

+ +

JOËL: So, as mentioned, we're recording this at the end of the year. And I thought it might be fun to do a bit of a retrospective on what this year has been like for you and I, Stephanie, both in terms of different work that we've done, the learnings we've had, but maybe also look back a little bit on 2023 for The Bike Shed and what that looked like.

+ +

STEPHANIE: Yes. I really enjoyed thinking about my year and kind of just reveling and having been doing this podcast for over a year now. And yeah, I'm excited to look back a little bit on both things we have mentioned on the show before and things maybe we haven't. To start, I'm wondering if you want to talk a little bit about some of our favorite episodes.

+ +

JOËL: Favorite episodes, yes. So, I've got a couple that are among my favorites. We did a lot of good episodes this year. I really liked them. But I really appreciated the episode we did on heuristics, that's Episode 398, where we got to talk a little bit about what goes into a good heuristic, how we tend to come up with them. A lot of those, like, guidelines and best practices that you hear people talk about in the software world and how to make your own but then also how to deal with the ones you hear from others in the software community. So, I think that was an episode that the idea, on the surface, seemed really basic, and then we went pretty deep with it. And that was really fun.

+ +

I think a second one that I really enjoyed was also the one that I did with Sara Jackson as a guest, talking about discrete math and its relevance to the day-to-day work that we do. That's Episode 374. We just had a lot of fun with that. I think that's a topic that more developers, more web developers, would benefit from just getting a little bit more discrete math in their lives. And also, there's a clip in there where Sara reinterprets a classic marketing jingle with some discrete math terms in there instead. It was a lot of fun. So, we'd recommend people checking that one out.

+ +

STEPHANIE: Nice. Yes. I also loved those episodes. The heuristics one was really great. I'm glad you mentioned it because one of my favorite episodes is kind of along a similar vein. It's one of the more recent ones that we did. It's Episode 405, where we did a bit of a retro on Sandi Metz' Rules For Developers. And those essentially are heuristics, right? And we got to kind of be like, hey, these are someone else's heuristics. How do we feel about them? Have we embodied them ourselves? Do we follow them? What parts do we take or leave? And I just remember having a really enjoyable conversation with you about that.

+ +

You and I have kind of treated this podcast a little bit like our own two-person book club [laughs]. So, it felt a little bit like that, right? Where we were kind of responding to, you know, something that we both have read up on, or tried, or whatever. So, that was a good one.

+ +

Another one of my favorite episodes was Episode 391: Learn with APPL [laughs], in which we basically developed our own learning framework, or actually, credit goes to former Bike Shed host, Steph Viccari, who came up with this fun, little acronym to talk about different things that we all kind of need in our work lives to be fulfilled. Our APPL stands for Adventure, Passion, Profit, and Low risk.

+ +

And that one was really fun just because it was, like, the opposite of what I just described where we're not discussing someone else's work but discovered our own thing out of, you know, these conversations that we have on the show, conversations we have with our co-workers. And yeah, I'm trying to make it a thing, so I'm plugging it again [laughs].

+ +

JOËL: I did really like that episode. One, I think, you know, this APPL framework is a little bit playful, which makes it fun. But also, I think digging into it really gives some insight on the different aspects that are relevant when planning out further growth or where you want to invest your sort of professional development time. And so, breaking down those four elements led to some really insightful conversation around where do I want to invest time learning in the next year?

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: By the way, we're mentioning a bunch of our favorite things, some past episodes, and we'll be talking about a lot of other types of resources. We will be linking all of these in the show notes. So, for any of our listeners who are like, "Oh, I wonder what is that thing they mentioned," there's going to be a giant list that you can check out.

+ +

STEPHANIE: Yeah. I love whenever we are able to put out an episode with a long list of things [laughs].

+ +

JOËL: It's one of the fun things that we get to do is like, oh yeah, we referenced all these things. And there is this sort of, like, further reading, more threads to pull on for people who might be interested.

+ +

So, you'd mentioned, Stephanie, that, you know, sometimes we kind of treat this as our own little mini, like, two-person book club. I know that you're a voracious reader, and you've mentioned so many books over the course of the year. Do you have maybe one or two books that have been kind of your favorites or that have stood out to you over 2023?

+ +

STEPHANIE: I do. I went back through my reading list in preparation for this episode and wanted to call out the couple of books that I finished. And I think I have, you know, I mentioned I was reading them along the way. But now I get to kind of see how having read them influenced my work life this past year, which is pretty cool.

+ +

So, one of them is Engineering Management for the Rest of Us by Sarah Drasner. And that's actually one that really stuck with me, even though I'm not a manager; I don't have any plans to become a manager. But one thing that she talks about early on is this idea of having a shared value system. And you can have that at the company level, right? You have your kind of corporate values. You can have that at the team level with this smaller group of people that you get to know better and kind of form relationships with. And then also, part of that is, like, knowing your individual values.

+ +

And having alignment in all three of those tiers is really important in being a functioning and fulfilled team, I think. And that is something that I don't think was really spelled out very explicitly for me before, but it was helpful in framing, like, past work experiences, where maybe I, like, didn't have that alignment and now identify why. And it has helped me this year as I think about my client work, too, and kind of where I sit from that perspective and helps me realize like, oh, like, this is why I'm feeling this way, and this is why it's not quite working. And, like, what do I do about it now? So, I really enjoyed that.

+ +

JOËL: Would you recommend this book to others who are maybe not considering a management path?

+ +

STEPHANIE: Yeah.

+ +

JOËL: So, even if you're staying in the IC track, at least for now, you think that's a really powerful book for other people.

+ +

STEPHANIE: Yeah, I would say so. You know, maybe not, like, all of it, but there's definitely parts that, you know, she's writing for the rest of us, like, all of us maybe not necessarily natural born leaders who knew that that's kind of what we wanted. And so, I can see how people, you know, who are uncertain or maybe even, like, really clearly, like, "I don't think that's for me," being able to get something out of, like, either those lessons in leadership or just to feel a bit, like, validated [laughs] about the type of work that they aren't interested in.

+ +

Another book that I want to plug real quick is Confident Ruby by Avdi Grimm. That one was one I referenced a lot this year, working with newer developers especially. And it actually provided a good heuristic [laughs] for me to talk about areas that we could improve code during code review. I think that wasn't really vocabulary that I'd used, you know, saying, like, "Hey, how confident is this code? How confident is this method and what it will receive and what it's returning?" And I remember, like, several conversations that I ended up having on my teams about, like, return types as a result and them having learned, like, a new way to view their code, and I thought that was really cool.

+ +

JOËL: I mean, learning to deal with uncertainty and nil in Ruby or maybe even, like, error states is just such a core part of writing software. I feel like this is something that I almost wish everyone was sort of assigned maybe, like, a year into their programming career because, you know, I think the first year there's just so many things you've got to learn, right? Like basic programming and, like, all these things.

+ +

But, like, you're looking maybe I can start going a little bit deeper into some topic. I think that some topic, like, pretty high up, would be building a mental model for how to deal with uncertainty because it's such a source of bugs. And Avdi Grimm's book, Confident Ruby, is...I would put that, yeah, definitely on a recommended reading list for everybody.

+ +

STEPHANIE: Yeah, I agree. And I think that's why I found myself, you know, then recommending it to other people on my team and kind of having something I can point to. And that was really helpful in the kind of mentorship that I wanted to offer.

+ +

JOËL: I did a deep dive into uncertainty and edge cases in programs several years back when I was getting into Elm. And I was giving a talk at Elm Europe about how Elm handles uncertainty, which is a little bit different than how Ruby does it. But a lot of the underlying concepts are very similar in terms of quarantining uncertainty and pushing it to the edges and things like that. Trying to write code that is more confident that is definitely a term that I used. And so Confident Ruby ended up being a little bit of an inspiration for my own journey there, and then, eventually, the talk that I gave that summarized my learnings there.

+ +

STEPHANIE: Nice. Do you have any reading recommendations or books that stood out to you this year?

+ +

JOËL: So, I've been reading two technical books kind of in tandem this year. I have not finished either of them, but I have been enjoying them. One is Sustainable Rails by David Bryant Copeland. We had an episode at the beginning of this year where we talked a little bit about our initial impressions from, I think, the first chapter of the book. But I really love that vocabulary of writing Ruby and Rails code, in particular, in a way that is sustainable for a team. And that premise, I think, just gives a really powerful mindset to approach structuring Rails apps.

+ +

And the other book that I've been reading is Domain Modeling Made Functional, so kind of looking at some domain-driven design ideas. But most of the literature is typically written to an object-oriented audience, so taking a look at it from more of a functional programming perspective has been really interesting. And then I've been, weirdly enough, taking some of those ideas and translating back into the object-oriented world to apply to code I'm writing in Ruby. I think that has been a very useful exercise.

+ +

STEPHANIE: That's awesome. And it's weird and cool how all those things end up converging, right? And exploring different paradigms really just lets you develop more insight into wherever you're working.

+ +

JOËL: Sometimes the sort of conversion step that you have to do, that translation, can be a good tool for kind of solidifying learnings or better understanding. So, I'm doing this sort of deep learning thing where I'm taking notes as I go along. And those notes are typically around, what other concepts can I connect ideas in the book?

+ +

So, I'll be reading and say, okay, on page 150, he mentioned this concept. This reminds me of this idea from TDD. I could see this applying in a different way in an object-oriented world. And interestingly, if you apply this, it sort of converges on maybe single responsibility or whatever other OO principle. And that's a really interesting connection. I always love it when you do see sort of two or three different angles converging together on the same idea.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I've written a blog post, I think, two years ago around how some theory from functional programming sort of OO best practices and then TDD all kind of converge on sort of the same approach to designing software. So, you can sort of go from either direction, and you kind of end in the same place or sort of end up rediscovering principles from the other two. We'll link that in the show notes. But that's something that I found was really exciting. It didn't directly come from this book because, again, I wrote this a couple of years ago. But it is always fun when you're exploring two or three different paradigms, and you find a convergence. It really deepens your understanding of what's happening.

+ +

STEPHANIE: Yeah, absolutely. I like what you said about how this book is different because it is making that connection between things that maybe seem less related on the surface. Like you're saying, there's other literature written about how domain modeling and object-oriented programming make more sense a little bit more together. But it is that, like, bringing in of different schools of thought that can lead to a lot of really interesting discovery about those foundational concepts.

+ +

JOËL: I feel like dabbling in other paradigms and in other languages has made me a better Ruby developer and a better OO programmer, a lot of the work I've done in Elm. This book that I'm reading is written in F#. And all these things I can kind of bring back, and I think, have made me a better Ruby developer. Have you had any experiences like that?

+ +

STEPHANIE: Yeah. I think I've talked a little bit about it on the show before, but I can't exactly recall. There were times when my exploration in static typing ended up giving me that different mindset in terms of the next time I was coding in Ruby after being in TypeScript for a while, I was, like, thinking in types a lot more, and I think maybe swung a little bit towards, like, not wanting to metaprogram as much [laughs]. But I think that it was a useful, like you said, exercise sometimes, too, and just, like, doing that conversion or translating in your head to see more options available to you, and then deciding where to go from there.

+ +

So, we've talked a bit about technical books that we've read. And now I kind of want to get into some in-person highlights for the year because you and I are both on the conference circuit and had some fun trips this year.

+ +

JOËL: Yeah. So, I spoke at RailsConf this spring. I gave a talk on discrete math and how it is relevant in day-to-day work for developers, actually inspired by that Bike Shed episode that I mentioned earlier. So, that was kind of fun, turning a Bike Shed episode into a conference talk.

+ +

And then just recently, I was at RubyConf in San Diego, and I gave a talk there around time. We often talk about time as a single quantity, but there's some subtle distinctions, so the difference between a moment in time versus a duration and some of the math that happens around that. And I gave a few sort of visual mental models to help people keep track of that. As of this recording, the talk is not out yet, so we're not going to be able to link to it. But if you're listening to this later in 2024, you can probably just Google RubyConf "Which Time Is It?" That's the name of the talk. And you'll be able to find it.

+ +

STEPHANIE: Awesome. So, as someone who is giving talks and attending conferences every year, I'm wondering, was this year particularly different in any way? Was there something that you've, like, experienced or felt differently community-wise in 2023?

+ +

JOËL: Conferences still feel a little bit smaller than they were pre-COVID. I think they are still bouncing back. But there's definitely an energy that's there that's nice to have on the conference scene. I don't know, have you experienced something similar?

+ +

STEPHANIE: I think I know what you're talking about where, you know, there was that time when we weren't really meeting in person. And so, now we're still kind of riding that wave of, like, getting together again and being able to celebrate and have fun in that way. I, this year, got to speak at Blue Ridge Ruby in June. And that was a first-time regional conference. And so, that was, I think, something I had noticed, too, is the emergence of regional conferences as being more viable options after not having conferences for a few years.

+ +

And as a regional conference, it was even smaller than the bigger national Ruby Central conferences. I really enjoyed the intimacy of that, where it was just a single track. So, everyone was watching talks together and then was on breaks together, so you could mingle. There was no FOMO of like, oh, like, I can't make this talk because I want to watch this other one. And that was kind of nice because I could, like, ask anyone, "What did you think of, like, X talk or like the one that we just kind of came out of and had that shared experience?" That was really great.

+ +

And I got to go tubing for the first time [laughs] in Asheville. That's a memory, but I am still thinking about that as we get into winter. I'm like, oh yeah, the glorious days of summer [laughs] when I was getting to float down a lazy river.

+ +

JOËL: Nice. I wasn't sure if this was floating down a lazy river on an inner tube or if this was someone takes you out on a lake with a speed boat, and you're getting pulled.

+ +

STEPHANIE: [laughs] That's true. As a person who likes to relax [laughs], I definitely prefer that kind of tubing over a speed boat [laughs].

+ +

JOËL: What was the topic of your talk?

+ +

STEPHANIE: So, I got to give my talk about nonviolent communication in pair programming for a second time. And that was also my first time giving a talk for a second time [laughs]. That was cool, too, because I got to revisit something and go deeper and kind of integrate even more experiences I had. I just kind of realized that even if you produce content once, like, there's always ways to deepen it or shape it a little better, kind of, you know, just continually improving it and as you learn more and as you get more experience and change.

+ +

JOËL: Yeah. I've never given a talk twice, and now you've got me wondering if that's something I should do. Because making a bespoke talk for every conference is a lot of work, and it might be nice to be able to use it more than once. Especially I think for some of the regional conferences, there might be some value there in people who might not be able to go to a big national conference but would still like to see your talk live. Having a mix of maybe original content and then content that is sort of being reshared is probably a great combo for a regional conference.

+ +

STEPHANIE: Yeah, definitely. That's actually a really good idea, yeah, to just be able to have more people see that content and access it. I like that a lot. And I think it could be really cool for you because we were just talking about all the ways that our mental models evolve the more stuff that we read and consume. And I think there's a lot of value there.

+ +

One other conference that I went to this year that I just want to highlight because it was really cool that I got to do this: I went to RubyKaigi in Japan [laughs] back in the spring. And I had never gone to an international conference before, and now I'm itching to do more of that. So, it would be remiss not to mention it [laughs]. I'm definitely inspired to maybe check out some of the conferences outside of the U.S. in 2024.

+ +

I think I had always been a little intimidated. I was like, oh, like, it's so far [laughs]. Do I really have, like, that good of a reason to make a trip out there? But being able to meet Rubyists from different countries and seeing how it's being used in other parts of the world, I think, made me realize that like, oh yeah, like, beyond my little bubble, there's so many cool things happening and people out there who, again, like, have that shared love of Ruby. And connecting with them was, yeah, just so new and something that I would want to do more of.

+ +

So, another thing that we haven't yet gotten into is our actual work-work or our client work [laughs] that we do at thoughtbot for this year. Joël, I'm wondering, was there anything especially fun or anything that really stood out to you in terms of client work that you had to do this year?

+ +

JOËL: So, two things come to mind that were novel for me. One is I did a Rails integration against Snowflake, the data warehouse, using an ODBC connection. We're not going through an API; we're going through this DB connection. And I never had to do that before. I also got to work with the new-ish Rails multi-database support, which actually worked quite nice. That was, I think, a great learning experience.

+ +

Definitely ran into some weird edge cases, or some days, I was really frustrated. Some days, I was actually, like, digging into the source code of the C bindings of the ODBC gem. Those were not the best days. But definitely, I think, that kind of integration and then Snowflake as a technology was really interesting to explore.

+ +

The other one that's been really interesting, I think, has been going much deeper into the single sign-on world. I've been doing an integration against a kind of enterprise SAML server that wants to initiate sign-in requests from their portal. And this is a bit of an alphabet soup, but the term here is IdP-initiated SSO.

+ +

And so, I've been working with...it's a combination of this third-party kind of corporate SAML system, our application, which is a Rails app, and then Auth0 kind of sitting in the middle and getting all of them to talk to each other. There's a ridiculous number of redirects because we're talking SAML on one side and OIDC on the other and getting everything to line up correctly. But that's been a really fun, new set of things to learn.

+ +

STEPHANIE: Yeah, that does sound complicated [laughs] just based on what you shared with me, but very cool. And I was excited to hear that you had had a good experience with the Rails multi-database part because that was another thing that I remember being...it had piqued my interest when it first came out. I hope I get to, you know, utilize that feature on a project soon because that sounds really fun.

+ +

JOËL: One thing I've had to do for this SSO project is lean a lot on sequence diagrams, which are those diagrams that sort of show you, like, being redirected from different places, and, like, okay, server one talks to server two talks, to the browser. And so, when I've got so many different actors and sort of controllers being passed around everywhere, it's been hard to keep track of it in my head. And so, I've been doing a lot of these diagrams, both for myself to help understand it during development, and then also as documentation to share back with the team.

+ +

And I found that Mermaid.js supports sequence diagrams as a diagram type. Long-term listeners of the show will know that I am a sucker for a good diagram. I love using Mermaid for a lot of things because it's supported. You can embed it in a lot of places, including in GitHub comments, pull requests. You can use it in various note systems like Notion or Obsidian. And you can also just generate your own on mermaid.live.

+ +

And so, that's been really helpful to communicate with the rest of the team, like, "Hey, we've got this whole process where we've got 14 redirects across four different servers. Here's what it looks like. And here, like, we're getting a bug on, you know, redirect number 8 of 14. I wonder why," and then you can start a conversation around debugging that.

+ +

STEPHANIE: Cool. I was just about to ask what tool you're using to generate your sequence diagrams. I didn't know that Mermaid supported them. So, that's really neat.

+ +

JOËL: So, last year, when we kind of looked back over 2022, one thing that was really interesting that we did is we talked about what are articles that you find yourself linking to a lot that are just kind of things that maybe were on your mind or that were a big part of conversations that happened over the year? So, maybe for you, Stephanie, in 2023, what are one or two articles that you find yourself sort of constantly linking to other people?

+ +

STEPHANIE: Yes. I'm excited you asked about this. One of them is an article by a person named Cat Hicks, who has a PhD in experimental psychology. She's a data scientist and social scientist. And lately, she's been doing a lot of research into the sense of belonging on software teams. And I think that's a theme that I am personally really interested in, and I think has kind of been something more people are talking about in the last few years. And she is kind of taking that maybe more squishy idea and getting numbers for it and getting statistics, and I think that's really cool.

+ +

She points out belonging as, like, a different experience from just, like, happiness and fulfillment, and that really having an impact on how well a team is functioning. I got to share this with a few people who were, you know, just in that same boat of, like, trying to figure out, what are the behaviors kind of on my team that make me feel supported or not supported?

+ +

And there were a lot of interesting discussions that came out of sharing this article and kind of talking about, especially in software, where we can be a little bit dogmatic. And we've kind of actually joked about it on the podcast [chuckles] before about, like, we TDD or don't TDD, or, you know, we use X tool, and that's just like what we have to do here. She writes a little bit about how that can end up, you know, not encouraging people offering, like, differing opinions and being able to feel like they have a say in kind of, like, the team's direction. And yeah, I just really enjoyed a different way of thinking about it. Joël, what about you? What are some articles you got bookmarked? [chuckles]

+ +

JOËL: This year, I started using a bookmark manager, Raindrop.io. That's been nice because, for this episode, I could just look back on, what are some of my bookmarks this year? And be like, oh yeah, this is the thing that I have been using a lot.

+ +

So, an article that I've been linking is an article called Preemptive Pluralization is (Probably) Not Evil. And it kind of talks a little bit about how going from code that works over a collection of two items to a collection of, you know, 20 items is very easy. But sometimes, going from one to two can be really challenging. And when are the times where you might want to preemptively make something more than one item? So, maybe using it has many association rather than it has one or making an attribute a collection rather than a single item.

+ +

Controversial is not the word for it, but I think challenges a little bit of the way people typically like to write code. But across this year, I've run into multiple projects where they have been transitioning from one to many. That's been an interesting article to surface as part of those conversations. Whether your team wants to do this preemptively or whether they want to put it off and say in classic YAGNI (You Aren't Gonna Need It) form, "We'll make it single for now, and then we'll go plural," that's a conversation for your team. But I think this article is a great way to maybe frame the conversation.

+ +

STEPHANIE: Cool. Yeah, I really like that almost, like, a counterpoint to YAGNI [laughs], which I don't think I've ever heard anyone say that out loud [laughs] before. But as soon as you said preemptive pluralization is not evil, I thought about all the times that I've had to, like, write code, text in which a thing, a variable could be either one or many [laughs] things. And I was like, ooh, maybe this will solve that problem for me [laughs].

+ +

JOËL: Speaking of pluralization, I'm sure you've been linking to more than just one article this year. Do you have another one that you find yourself coming up in conversations where you've always kind of like, "Hey, dropping this link," where it's almost like your thing?

+ +

STEPHANIE: Yes. And that is basically everything written by Mandy Brown [laughs], who is a work coach that I actually started working with this year. And one of the articles that really inspired me or really has been a topic of conversation among my friends and co-workers is she has a blog post called Digging Through the Ashes. And it's kind of a meditation on, like, post burnout or, like, what's next, and how we have used this word as kind of a catch-all to describe, you know, this collective sense of being just really tired or demoralized or just, like, in need of a break.

+ +

And what she offers in that post is kind of, like, some suggestions about, like, how can we be more specific here and really, you know, identify what it is that you're needing so that you can change how you engage with work? Because burnout can mean just that you are bored. It can mean that you are overworked. It can mean a lot of things for different people, right?

+ +

And so, I definitely don't think I'm alone [laughs] in kind of having to realize that, like, oh, these are the ways that my work is or isn't changing and, like, where do I want to go next so that I might feel more sustainable? I know that's, like, a keyword that we talked about earlier, too. And that, on one hand, is both personal but also technical, right? It, like, informs the kinds of decisions that we make around our codebase and what we are optimizing for. And yeah, it is both technical and cultural. And it's been a big theme for me this year [laughs].

+ +

JOËL: Yeah. Would you say it's safe to say that sustainability would be, if you want to, like, put a single word on your theme for the year? Would that be a fair word to put there?

+ +

STEPHANIE: Yeah, I think so. Definitely discovering what that means for me and helping other people discover what that means for them, too.

+ +

JOËL: I feel like we kicked off the year 2023 by having that discussion of Sustainable Rails and how different technical practices can make the work there feel sustainable. So, I think that seems to have really carried through as a theme through the year for you. So, that's really cool to have seen that. And I'm sure listeners throughout the year have heard you mention these different books and articles. Maybe you've also been able to pick up a little bit on that.

+ +

So, I'm glad that we do this show because you get a little bit of, like, all the bits and pieces in the day-to-day, and then we aggregate it over a year, and you can look back. You can be like, "Oh yeah, I definitely see that theme in your work."

+ +

STEPHANIE: Yeah, I'm glad you pointed that out. It is actually really interesting to see how something that we had talked about early, early on just had that thread throughout the year. And speaking of sustainability, we are taking a little break from the show to enjoy the holidays. We'll be off for a few weeks, and we will be back with a new Bike Shed in January.

+ +

JOËL: Cheers to a new year.

+ +

STEPHANIE: Yeah, cheers to a new year. Wrapping up 2023. And we will see you all in 2024.

+ +

JOËL: On that note, shall we wrap up the whole year?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/
+referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+5Aojgf6_ + + ]]> + + Joël Quenneville + Stephanie Minn + + + 410: All About Documentation + https://bikeshed.thoughtbot.com/410 + 79b38f8a-f929-43b7-8025-6fbbd082c908 + Tue, 12 Dec 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël shares his experiences with handling JSON in a Postgres database. He talks about his challenges with ActiveRecord and JSONB columns, particularly the unexpected behavior of storing and retrieving JSON data. Stephanie shares her recent discovery of bookmarklets and highlights a bookmarklet named "Check This Out," which streamlines searching for books on Libby, an ebook and audiobook lending app. + +The conversation shifts to using constants in code as a form of documentation. Stephanie and Joël discuss how constants might not always accurately reflect current system behavior or logic, leading to potential misunderstandings and the importance of maintaining accurate documentation. + 32:02 + no + + + Joël shares his experiences with handling JSON in a Postgres database. He talks about his challenges with ActiveRecord and JSONB columns, particularly the unexpected behavior of storing and retrieving JSON data. Stephanie shares her recent discovery of bookmarklets and highlights a bookmarklet named "Check This Out," which streamlines searching for books on Libby, an ebook and audiobook lending app. +The conversation shifts to using constants in code as a form of documentation. Stephanie and Joël discuss how constants might not always accurately reflect current system behavior or logic, leading to potential misunderstandings and the importance of maintaining accurate documentation. +Bookmarklets (https://www.freecodecamp.org/news/what-are-bookmarklets/) +"Check This Out" Bookmarklet (https://checkthisout.today/) +Libby (https://libbyapp.com/interview/welcome#doYouHaveACard) +Productivity Tricks (https://www.bikeshed.fm/403) +12 Factor App Config (https://12factor.net/config) +A Hierarchy of Documentation (https://challahscript.com/hiearchy_of_documentation) +Sustainable Rails (https://sustainable-rails.com/) +rails-erd gem (https://github.com/voormedia/rails-erd) +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: What's new in my world is JSON and how to deal with it in a Postgres database. So, I'm dealing with a situation where I have an ActiveRecord model, and one of the columns is a JSONB column. And, you know, ActiveRecord is really nice. You can just throw a bunch of different data at it, and it knows the column type, and it will do some conversions for you automatically. +So, if I'm submitting a form and, you know, form values might come in as strings because, you know, I typed in a number in a text field, but ActiveRecord will automatically parse that into an integer because it knows we're saving that to an integer column. So, I don't need to do all these, like, manual conversions. +Well, I have a form that has a string of JSON in it that I'm trying to save in a JSONB column. And I expected ActiveRecord to just parse that into a hash and store it in Postgres. That is not what happens. It just stores a raw string, so when I pull it out again, I don't have a hash. I have a raw string that I need to deal with. And I can't query it because, again, it is a raw string. So, that was a bit of an unexpected behavior that I saw there. +STEPHANIE: Yeah, that is unexpected. So, is this a field that has been used for a while now? I'm kind of surprised that there hasn't been already some implementations for, like, deserializing it. +JOËL: So, here's the thing: I don't think you can have an automatic deserialization there because there's no way of knowing whether or not you should be deserializing. The reason is that JSON is not just objects or, in Ruby parlance, hashes. You can also have arrays. But just raw numbers not wrapped in hashes are also valid JSON as are raw strings. +And if I just give you a string and say, put this in a JSON field, you have no way of knowing, is this some serialized JSON that you need to deserialize and then save? Or is it just a string that you should save because strings are already JSON? So, that's kind of on you as the programmer to make that distinction because you can't tell at runtime which one of these it is. +STEPHANIE: Yeah, you're right. I just realized it's [laughs] kind of, like, an anything goes [laughs] situation, not anything but strings are JSON, are valid JSON, yep [laughs]. That sounds like one of those things that's, like, not what you think about immediately when dealing with that kind of data structure, but... +JOËL: Right. So, the idea that strings are valid JSON values, but also all JSON values can get serialized as strings. And so, you never know: are you dealing with an unserialized string that's just a JSON value, or are you dealing with some JSON blob that got serialized into a string? And only in one of those do you want to then serialize before writing into the database. +STEPHANIE: So, have you come to a solution or a way to make your problem work? +JOËL: So, the solution that I did is just calling a JSON parse before setting that attribute on my model because this value is coming in from a form. I believe I'm doing this when I'm defining the strong parameters for that particular form. I'm also transforming that string by parsing it into a hash with the JSON dot parse, which then gets passed to the model. And then I'm not sure what JSONB serializes as under the hood. When you give it a hash, it might store it as a string, but it might also have some kind of binary format or some internal AST that it uses for storage. I'm not sure what the implementation is. +STEPHANIE: Are the values in the JSONB something that can be variable or dynamic? I've seen some people, you know, put that in getter so that it's just kind of done for you for anyone who needs to access that field. +JOËL: Right now, there is a sort of semi-consistent schema to that. I think it will probably evolve to where I'll pull some of these out to be columns on the table. But it is right now kind of an everything else sort of dumping ground from an API. +STEPHANIE: Yeah, that's okay, too, sometimes [laughs]. +JOËL: Yeah. So, interesting journey into some of the fun edge cases of dealing with a format whose serialized form is also a valid instance of that format. What's been new in your world? +STEPHANIE: So, I discovered something new that has been around on the internet for a while, but I just haven't been aware of it. Do you know what a bookmarklet is? +JOËL: Oh, like a JavaScript code that runs in a bookmark? +STEPHANIE: Yeah, exactly. So, you know, in your little browser bookmark where you might normally put a URL, you can actually stick some JavaScript in there. And it will run whenever you click your bookmark in your browser [chuckles]. So, that was a fun little internet tidbit that I just found out about. And the reason is because I stumbled upon a bookmarklet made by someone. It's called Check This Out. +And what it does is there's another app/website called Libby that is used to check out ebooks and audiobooks for free from your local public library. And what this Check This Out bookmarklet does is you can kind of select any just, like, text on a web page, and then when you click the bookmarklet, it then just kind of sticks it into the query params for Libby's search engine. And it takes you straight to the results for that book or that author, and it saves you a few extra manual steps to go from finding out about a book to checking it out. +So, that was really neat and cute. And I was really surprised that you could do that. I was like, whoa [laughs]. At first, I was like, is this okay? [laughs] If you, like, you can't read, you know, you don't know what the JavaScript is doing, I can see it being a little sketchy. But –- +JOËL: Be careful of executing arbitrary JavaScript. +STEPHANIE: Yeah, yeah. When I did look up bookmarklets, though, I kind of saw that it was, you know, just kind of a fun thing for people who might be learning to code for the first time to play around with. And some fun ideas they had for what you could do with it was turning all the font on a web page to Comic Sans [laughs]. So yeah, I thought that was really cute. +JOËL: Has that inspired you to write your own? +STEPHANIE: Well, we did an episode a while ago on productivity tricks. And I was thinking like, oh yeah, there's definitely some things that I could do to, you know, just stick some automated tasks that I have into a bookmarklet. And that could be a really fun kind of, like, old-school way of doing it, as opposed to, you know, coding my little snippets or getting into a new, like, Omnibar app [laughs]. +JOËL: So, something that is maybe a little bit less effort than building yourself a browser extension or something like that. +STEPHANIE: Yeah, exactly. +JOËL: I had a client project once that involved a...I think it was, like, a five-step wizard or something like that. It was really tedious to step through it all to manually test things. And so, I wrote a bookmarklet that would just go through and fill out all the fields and hit submit on, like, five pages worth of these things. And if anything didn't work, it would just pause there, and then you could see it. In some way, it was moving towards the direction of, like, an automated like Capybara style test. But this was something that was helping for manual QA. So, that was a really fun use of a bookmarklet. +STEPHANIE: Yeah, I like that. Like, just an in-between thing you could try to speed up that manual testing without getting into, like you said, an automated test framework for your browser. +JOËL: The nice thing about that is that this could be used without having to set up pretty much anything, right? You paste a bit of JavaScript into your bookmark bar, and then you just click the button. That's all you need to do. No need to make sure that you've got Ruby installed on your machine or any of these other things that you would need for some kind of testing framework. You don't need Selenium. You don't need ChromeDriver. It just...it works. +So, I was working...this was a greenfield startup project. So, I was working with a non-technical founder who didn't have all these things, you know, dev tooling on his machine. So, he wanted to try out things but not spend his days filling out forms. And so, having just a button he could click was a really nice shortcut. +STEPHANIE: That's really cool. I like that a lot. I wasn't even thinking about how I might be able to bring that in more into just my daily work, as opposed to just something kind of fun. But that's an awesome idea. And I hope that maybe I'll have a good use for one in the future. +JOËL: It feels like the thing that has a lot of potential, and yet I have not since written...I don't think I've written any bookmarklets for myself. It feels like it's the kind of thing where I should be able to do this for all sorts of fun tooling and just automate my life away. Somehow, I haven't done that. +STEPHANIE: Bring back the bookmarklet [laughs]. That's what I have to say. +JOËL: So, I mentioned earlier that I was working with a JSONB column and storing JSON on an ActiveRecord model. And then I wanted to interact with it, but the problem is that this JSON is somewhat arbitrary, and there are a lot of magic strings in there. All of the key names might change. And I was really concerned that if the schema of that JSON ever changed, if we changed some of the key names or something like that, we might accidentally break code in multiple parts of the app. +So, I was very careful while building that model to quarantine any references to any raw strings only within that model, which meant that I leaned really heavily on constants. And, in some way, those constants end up kind of documenting what we think the schema of that JSON should be. And that got me thinking; you were telling me recently about a scenario where some code you were working with relied heavily on constants as a form of documentation, and that documentation kind of lied to you. +STEPHANIE: Yeah, it did. And I think you mentioned something that I wanted to point out, which is that the magic strings that you think might change, and you wanted to pull that out into a constant, you know, so at least it's kind of defined in one place. And if it ever does change, you know, you don't have to change it in all of those places. +And I do think that, normally, you know, if there's opportunities to extract those magic strings and give a name to them, that is beneficial. But I was gripping a little bit about when constants become, I guess, like, too wieldy, or there's just kind of, like, too much of a dependency on them as the things documenting how the app should work when it's constantly changing. I realized that I just used constant and constantly [laughs]. +JOËL: The only constant is that it is not constant. +STEPHANIE: Right. And so, the situation that I found myself in—this was on a client project a little bit ago—was that the constants became, like, gatekeepers of that logic where dev had to change it if the app's behavior changed, and maybe we wanted to change the value of it. And also, one thing that I noticed a lot was that we, as developers, were getting questions about, "Hey, like, how does this actually work?" +Like, we were using the constants for things like pricing of products, for things like what is a compatible version for this feature. And because that was only documented in the code, other people who didn't have access to it actually were left in the dark. And because those were changing with somewhat frequency, I was just kind of realizing how that was no longer working for us. +JOËL: Would you say that some of these values that we stored as constants were almost more like config rather than constants or maybe they're just straight-up application data? I can imagine something like price of an item you probably want that to be a value in the database that can be updated by an admin. And some of these other things maybe are more like config that you change through some kind of environment variable or something like that. +STEPHANIE: Yeah, that's a good point. I do think that they evolved to become things that needed to be configured, right? I suppose maybe there wasn't as much information or foresight at the beginning of like, oh, this is something that we expect to change. But, you know, kind of when you're doing that first pass and you're told, like, hey, like, this value should be the price of something, or, like, the duration of something, or whatever that may be. It gets codified [chuckles]. And there is some amount of lift to change it from something that is, at first, just really just documenting what that decision was at the time to something that ends up evolving. +JOËL: How would you draw a distinction between something that should be a constant versus something that maybe would be considered config or some other kind of value? Because it's pretty easy, right? As developers, we see magic numbers. We see magic strings. And our first thought is, oh, we've seen this problem before—constant. Do you have maybe a personal heuristic for when to reach for a constant versus when to reach for something else? +STEPHANIE: Yeah, that's a good question. I think when I started to see it a lot was especially when the constants were arrays or hashes [laughs]. And I guess that is actually kind of a signal, right? You will likely be adding more stuff [laughs] into that data structure [laughs]. And, again, like, maybe it's okay, like, the first couple of times. But once you're seeing that request happen more frequently, that could be a good way to advocate for storing it in the database or, like, building a lightweight admin kind of thing so that people outside of the dev team can make those configuration changes. +I think also just asking, right? Hey, like, how often do we suspect this will change? Or what's on the horizon for the product or the team where we might want to introduce a way to make the implementation a bit more flexible to something that, you know, we think we know now, but we might want to adjust for? +JOËL: So, it's really about change and how much we think this might change in the future. +STEPHANIE: Speaking of change, this actually kind of gets into the broader topic of documentation and how to document a changing and evolving entity [chuckles], you know, that being, like, the codebase or the way that decisions are made that impact how an application works. And you had shared, in preparation for this topic, an article that I read and enjoyed called Hierarchy of Documentation. +And one thing that I liked about it is that it kind of presented all of the places that you could put information from, you know, straight in the code, to in your commit messages, to your issue management system, and to even wikis for your repo or your team. And I think that's actually something that we would want to share with new developers, you know, who might be wondering, like, where do I find or even put information? I really liked how it was kind of, like, laid out and gave, like, different reasons for where you might want to put something or not. +JOËL: We think a lot about documentation as code writers. I'm curious what your experience is as a code reader. How do you tend to try to read code and understand documentation about how code works? And, apparently, the answer is, don't read the constants because these constants lie. +STEPHANIE: I think you are onto something, though, because I was just thinking about how distrustful I've become of certain types of documentation. Like, when I think of code comments, on one hand, they should be a signal, right? They should kind of draw your attention to something maybe weird or just, like, something to note about the code that it's commenting on, or where it's kind of located in a file. +But I sometimes tune them out, I'm not going to lie. When I see a really big block of code [chuckles] comment, I'm like, ugh, like, do I really have to read all of this? I'm also not positive that it's still relevant to the code below it, right? Like, I don't always have git blame, like, visually enabled in my editor. But oftentimes, when I do a little bit of digging, that comment is left over from maybe when that code was initially introduced. But, man, there have been lots of commits [chuckles] in the corresponding, you know, like, function sense, and I'm not really sure how relevant it is anymore. +Do you struggle with the signal versus noise issue with code comments? How much do you trust them, and how much do you kind of, like, give credence to them? +JOËL: I think I do tend to trust them with maybe some slight skepticism. It really depends on the codebase. Some codebases are really bad sort of comment hygiene and just the types of comments that they put in there, and then others are pretty good at it. The ones that I tend to particularly appreciate are where you have maybe some, like, weird function and you're like, what is going on here? And then you've got a nice, little paragraph up top explaining what's going on there, or maybe an explanation of ways you might be tempted to modify that piece of code and, like, why it is the way it is. +So, like, hey, you might be wanting to add an extra branch here to cover this edge case. Don't do that. We tried it, and it causes problems for XY reasons. And sometimes it might be, like, a performance thing where you say, look, the code quality person in you is going to look at this and say, hey, this is hard to read. It would be better if we did this more kind of normalized form. Know that we've particularly written this in a way that's hard to read because it is more performant, and here are the numbers. This is why we want it in this way. Here's a link to maybe the issue, or the commit, or whatever where this happened. +And then if you want to start that discussion up again and say, "Hey, do we really need performance here at the cost of readability?", you can start it up again. But at least you're not going to just be like, oh, while I'm here, I'm going to clean up this messy code and accidentally cause a regression. +STEPHANIE: Yeah. I like what you said about comment hygiene being definitely just kind of, like, variable depending on the culture and the codebase. +JOËL: I feel like, for myself, I used to be pretty far on the spectrum of no comments. If I feel the need to write a comment, that's a smell. I should find other ways to communicate that information. And I think I went pretty far down that extreme, and then I've been slowly kind of coming back. And I've probably kind of passed the center, where now I'm, like, slightly leaning towards comments are actually nice sometimes. And they are now a part of my toolkit. So, we'll see if I keep going there. +Maybe I'll hit some point where I realize that I'm putting too much work into comments or comments are not being helpful, and I need to come back towards the center again and focus on other ways of communicating. But right now, I'm in that phase of doing more comments than I used to. How about you? Where do you stand on that sort of spectrum of all information should be communicated in code tokens versus comments? +STEPHANIE: Yeah, I think I'm also somewhere in the middle. I think I have developed an intuition of when it feels useful, right? In my gut, I'm like, oh, I'm doing something weird. I wish I didn't have to do this [chuckles]. I think it's another kind of intuition that I have now. I might leave a comment about why, and I think that is more of that signal, right? +Though I also recently have been using them more as just, like, personal notes for myself as I'm, you know, in my normal development workflow, and then I will end up cleaning them up later. I was working on a codebase where there was a soft delete functionality. And that was just, like, a concern that was included in some of the models. And I didn't realize that that's what was going on. So, when I, you know, I was calling destroy, I thought it was actually being deleted, and it turns out it wasn't. And so, that was when I left a little comment for myself that was like, "Hey, like, this is soft deleted." +And some of those things I do end up leaving if I'm like, yes, other people won't have the same context as me. And then if it's something that, like, well, people who work in this app should know that they have soft delete, so then I'll go ahead and clean that up, even though it had been useful for me at the time. +JOËL: Do you capture that information and then put it somewhere else then? Or is it just it was useful for you as a stepping-stone on the journey but then you don't need it at the end and nobody else needs to care about it? +STEPHANIE: Oh, you know what? That's actually a really great point. I don't think I had considered saving that information. I had only thought about it as, you know, just stuff for me in this particular moment in time. But that would be really great information to pull out and put somewhere else [chuckles], perhaps in something like a wiki, or like a README, or somewhere that documents things about the system as a whole. Yeah, should we get into how to document kind of, like, bigger-picture stuff? +JOËL: How do you feel about wikis? Because I feel like I've got a bit of a love-hate relationship with them. +STEPHANIE: I've seen a couple of different flavors of them, right? Sometimes you have your GitHub wiki. Sometimes you have your Confluence ecosystem [laughs]. I have found that they work better if they're smaller [laughs], where you can actually, like, navigate them pretty well, and you have a sense of what is in there, as opposed to it just being this huge knowledge base that ends up actually, I think, working against you a little bit [laughs]. +Because so much information gets duplicated if it's hard to find and people start contributing to it maybe without keeping in mind, like, the audience, right? I've seen a lot of people putting in, like, their own personal little scripts [laughs] in a wiki, and it works for them but then doesn't end up working for really anyone else. What's your love-hate relationship to them? +JOËL: I think it's similar to what you were saying, a little bit of structure is nice. When they've just become dumping grounds of information that is maybe not up to date because over the course of several years, you end up with a lot of maybe conflicting articles, and you don't know which one is the right thing to do, it becomes hard to find things. +So, when it just becomes a dumping ground for random information related to the company or the app, sometimes it becomes really challenging to find the information I need and to find information that's relevant, to the point where oftentimes looking something up in the wiki is my last resort. Like, I'm hoping I will find the answer to my question elsewhere and only fallback to the wiki if I can't. +STEPHANIE: Yeah, that's, like, the sign that the wiki is really not trustworthy. And it kind of is diminishing returns from there a bit. I think I fell into this experience on my last project where it was a really, really big wiki for a really big codebase for a lot of developers. And there was kind of a bit of a tragedy of the commons situation, where on one hand, there were some things that were so manual that the steps needed to be very explicitly documented, but then they didn't work a lot of the time [laughs]. +But it was hard to tell if they weren't working for you or because it was genuinely something wrong with, like, the way the documentation laid out the steps. And it was kind of like, well, I'm going to fix it for myself, but I don't know how to fix it for everyone else. So, I don't feel confident in updating this information. +JOËL: I think that's what's really nice about the article that you mentioned about the hierarchy of documentation. It's that all of these different forms—code, comments, commit messages, pull requests, wikis—they don't have to be mutually exclusive. But sometimes they work sort of in addition to each other sort of each adding more context. +But also, sometimes it's you sort of choose the one that's the highest up on that list that makes sense for what you're trying to do, so something like documenting a series of steps to do something maybe a wiki is a good place for that. But maybe it's better to have that be executable. Could that be a script somewhere? And then maybe that can be a thing that is almost, like, living documentation, but also where you don't need to maybe even think about the individual steps anymore because the script is running, you know, 10 different things. +And I think that's something that I really appreciated from the book Sustainable Rails is there's a whole section there talking about the value of setup scripts and how people who are getting started on your app don't want to have to care about all the different things to set it up, just run a script. And also, that becomes living documentation for what the app needs, as opposed to maybe having a bulleted list with 10 elements in it in your project README. +STEPHANIE: Yeah, absolutely. In the vein of living documentation, I think one thing that wikis can be kind of nice for is for putting visual supplements. So, I've seen them have, like, really great graphs. But at the same time, you could use a gem like Rails-ERD that generates the entity relationship diagram as the schema of your database changes, right? So, it's always up to date. +I've seen that work well, too, when you want to have, like I said, those, like, system-level documentation that sometimes they do change frequently and, you know, sometimes they don't. But that's definitely worth keeping in mind when you choose, like, how you want to have that exist as information. +JOËL: How do you feel about deleting documentation? Because I feel like we put so much work into writing documentation, kind of like we do when writing tests. It feels like more is always better. Do you ever go back and maybe sort of prune some of your docs, or try to delete some things that you think might no longer be relevant or helpful? +STEPHANIE: I was also thinking of tests when you first posed that question. I don't know if I have it in my practice to, like, set aside time and be like, hmm, like, what looks outdated these days? I am starting to feel more confident in deleting things as I come across them if I'm like, I just completely ignored this or, like, this was just straight up wrong [laughs]. You know, that can be scary at first when you aren't sure if you can make that determination. +But rather than thrust that, you know, someone else going through that same process of spending time, you know, trying to think about if this information was useful or not, you can just delete it [laughs]. You can just delete tests that have been skipped for months because they don't work. Like, you can delete information that's just no longer relevant and, in some ways, causing you more pain because they are cluttering up your wiki ecosystem so that no one [laughs] feels that any of that information is relevant anymore. +JOËL: I'll be honest, I don't think I've ever deleted a wiki article that was out of date or no longer relevant. I think probably the most I've done is go to Slack and complain about how an out-of-date wiki page led me down the wrong path, which is probably not the most productive way to channel those feelings. So, maybe I should have just gone back and deleted the wiki page. +STEPHANIE: I do like to give a heads up, I think. It's like, "Hey, I want to delete this thing. Are there any qualms?" And if no one on your team can see a reason to keep it and you feel good about that it's not really, like, serving its purpose, I don't know, maybe consider just doing it. +JOËL: To kind of wrap up this topic, I've got a spicy question for you. +STEPHANIE: Okay, I'm ready. +JOËL: Do you think that AI is going to radically change the way that we interact with documentation? Imagine you have an LLM that you train on maybe not just your code but the Git history. It has all the Git comments and maybe your wiki. And then, you can just ask it, "Why does function foo do this thing?" And it will reference a commit message or find the correct wiki article. Do you think that's the future of understanding codebases? +STEPHANIE: I don't know. I'm aware that some people kind of can see that as a use case for LLMs, but I think I'm still a little bit nervous about the not knowing how they got there kind of part of it where, you know, yes, like I am doing this manual labor of trying to sort out, like, is this information good or trustworthy or not? But at least that is something I'm determining for myself. So, that is where my skepticism comes in a little bit. But I also haven't really seen what it can do yet or seen the outcomes of it. So, that's kind of where I'm at right now. +JOËL: So, you think, for you, the sort of the journey of trying to find and understand the documentation is a sort of necessary part of building the understanding of what the code is doing. +STEPHANIE: I think it can be. Also, I don't know, maybe my life would be better by having all that cut out for me, or I could be burned by it because it turns out that it was bad information [laughs]. So, I can't say for sure. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + + Joël shares his experiences with handling JSON in a Postgres database. He talks about his challenges with ActiveRecord and JSONB columns, particularly the unexpected behavior of storing and retrieving JSON data. Stephanie shares her recent discovery of bookmarklets and highlights a bookmarklet named "Check This Out," which streamlines searching for books on Libby, an ebook and audiobook lending app.

+ +

The conversation shifts to using constants in code as a form of documentation. Stephanie and Joël discuss how constants might not always accurately reflect current system behavior or logic, leading to potential misunderstandings and the importance of maintaining accurate documentation.

+ +
+ + + +

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: What's new in my world is JSON and how to deal with it in a Postgres database. So, I'm dealing with a situation where I have an ActiveRecord model, and one of the columns is a JSONB column. And, you know, ActiveRecord is really nice. You can just throw a bunch of different data at it, and it knows the column type, and it will do some conversions for you automatically.

+ +

So, if I'm submitting a form and, you know, form values might come in as strings because, you know, I typed in a number in a text field, but ActiveRecord will automatically parse that into an integer because it knows we're saving that to an integer column. So, I don't need to do all these, like, manual conversions.

+ +

Well, I have a form that has a string of JSON in it that I'm trying to save in a JSONB column. And I expected ActiveRecord to just parse that into a hash and store it in Postgres. That is not what happens. It just stores a raw string, so when I pull it out again, I don't have a hash. I have a raw string that I need to deal with. And I can't query it because, again, it is a raw string. So, that was a bit of an unexpected behavior that I saw there.

+ +

STEPHANIE: Yeah, that is unexpected. So, is this a field that has been used for a while now? I'm kind of surprised that there hasn't been already some implementations for, like, deserializing it.

+ +

JOËL: So, here's the thing: I don't think you can have an automatic deserialization there because there's no way of knowing whether or not you should be deserializing. The reason is that JSON is not just objects or, in Ruby parlance, hashes. You can also have arrays. But just raw numbers not wrapped in hashes are also valid JSON as are raw strings.

+ +

And if I just give you a string and say, put this in a JSON field, you have no way of knowing, is this some serialized JSON that you need to deserialize and then save? Or is it just a string that you should save because strings are already JSON? So, that's kind of on you as the programmer to make that distinction because you can't tell at runtime which one of these it is.

+ +

STEPHANIE: Yeah, you're right. I just realized it's [laughs] kind of, like, an anything goes [laughs] situation, not anything but strings are JSON, are valid JSON, yep [laughs]. That sounds like one of those things that's, like, not what you think about immediately when dealing with that kind of data structure, but...

+ +

JOËL: Right. So, the idea that strings are valid JSON values, but also all JSON values can get serialized as strings. And so, you never know: are you dealing with an unserialized string that's just a JSON value, or are you dealing with some JSON blob that got serialized into a string? And only in one of those do you want to then serialize before writing into the database.

+ +

STEPHANIE: So, have you come to a solution or a way to make your problem work?

+ +

JOËL: So, the solution that I did is just calling a JSON parse before setting that attribute on my model because this value is coming in from a form. I believe I'm doing this when I'm defining the strong parameters for that particular form. I'm also transforming that string by parsing it into a hash with the JSON dot parse, which then gets passed to the model. And then I'm not sure what JSONB serializes as under the hood. When you give it a hash, it might store it as a string, but it might also have some kind of binary format or some internal AST that it uses for storage. I'm not sure what the implementation is.

+ +

STEPHANIE: Are the values in the JSONB something that can be variable or dynamic? I've seen some people, you know, put that in getter so that it's just kind of done for you for anyone who needs to access that field.

+ +

JOËL: Right now, there is a sort of semi-consistent schema to that. I think it will probably evolve to where I'll pull some of these out to be columns on the table. But it is right now kind of an everything else sort of dumping ground from an API.

+ +

STEPHANIE: Yeah, that's okay, too, sometimes [laughs].

+ +

JOËL: Yeah. So, interesting journey into some of the fun edge cases of dealing with a format whose serialized form is also a valid instance of that format. What's been new in your world?

+ +

STEPHANIE: So, I discovered something new that has been around on the internet for a while, but I just haven't been aware of it. Do you know what a bookmarklet is?

+ +

JOËL: Oh, like a JavaScript code that runs in a bookmark?

+ +

STEPHANIE: Yeah, exactly. So, you know, in your little browser bookmark where you might normally put a URL, you can actually stick some JavaScript in there. And it will run whenever you click your bookmark in your browser [chuckles]. So, that was a fun little internet tidbit that I just found out about. And the reason is because I stumbled upon a bookmarklet made by someone. It's called Check This Out.

+ +

And what it does is there's another app/website called Libby that is used to check out ebooks and audiobooks for free from your local public library. And what this Check This Out bookmarklet does is you can kind of select any just, like, text on a web page, and then when you click the bookmarklet, it then just kind of sticks it into the query params for Libby's search engine. And it takes you straight to the results for that book or that author, and it saves you a few extra manual steps to go from finding out about a book to checking it out.

+ +

So, that was really neat and cute. And I was really surprised that you could do that. I was like, whoa [laughs]. At first, I was like, is this okay? [laughs] If you, like, you can't read, you know, you don't know what the JavaScript is doing, I can see it being a little sketchy. But –-

+ +

JOËL: Be careful of executing arbitrary JavaScript.

+ +

STEPHANIE: Yeah, yeah. When I did look up bookmarklets, though, I kind of saw that it was, you know, just kind of a fun thing for people who might be learning to code for the first time to play around with. And some fun ideas they had for what you could do with it was turning all the font on a web page to Comic Sans [laughs]. So yeah, I thought that was really cute.

+ +

JOËL: Has that inspired you to write your own?

+ +

STEPHANIE: Well, we did an episode a while ago on productivity tricks. And I was thinking like, oh yeah, there's definitely some things that I could do to, you know, just stick some automated tasks that I have into a bookmarklet. And that could be a really fun kind of, like, old-school way of doing it, as opposed to, you know, coding my little snippets or getting into a new, like, Omnibar app [laughs].

+ +

JOËL: So, something that is maybe a little bit less effort than building yourself a browser extension or something like that.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I had a client project once that involved a...I think it was, like, a five-step wizard or something like that. It was really tedious to step through it all to manually test things. And so, I wrote a bookmarklet that would just go through and fill out all the fields and hit submit on, like, five pages worth of these things. And if anything didn't work, it would just pause there, and then you could see it. In some way, it was moving towards the direction of, like, an automated like Capybara style test. But this was something that was helping for manual QA. So, that was a really fun use of a bookmarklet.

+ +

STEPHANIE: Yeah, I like that. Like, just an in-between thing you could try to speed up that manual testing without getting into, like you said, an automated test framework for your browser.

+ +

JOËL: The nice thing about that is that this could be used without having to set up pretty much anything, right? You paste a bit of JavaScript into your bookmark bar, and then you just click the button. That's all you need to do. No need to make sure that you've got Ruby installed on your machine or any of these other things that you would need for some kind of testing framework. You don't need Selenium. You don't need ChromeDriver. It just...it works.

+ +

So, I was working...this was a greenfield startup project. So, I was working with a non-technical founder who didn't have all these things, you know, dev tooling on his machine. So, he wanted to try out things but not spend his days filling out forms. And so, having just a button he could click was a really nice shortcut.

+ +

STEPHANIE: That's really cool. I like that a lot. I wasn't even thinking about how I might be able to bring that in more into just my daily work, as opposed to just something kind of fun. But that's an awesome idea. And I hope that maybe I'll have a good use for one in the future.

+ +

JOËL: It feels like the thing that has a lot of potential, and yet I have not since written...I don't think I've written any bookmarklets for myself. It feels like it's the kind of thing where I should be able to do this for all sorts of fun tooling and just automate my life away. Somehow, I haven't done that.

+ +

STEPHANIE: Bring back the bookmarklet [laughs]. That's what I have to say.

+ +

JOËL: So, I mentioned earlier that I was working with a JSONB column and storing JSON on an ActiveRecord model. And then I wanted to interact with it, but the problem is that this JSON is somewhat arbitrary, and there are a lot of magic strings in there. All of the key names might change. And I was really concerned that if the schema of that JSON ever changed, if we changed some of the key names or something like that, we might accidentally break code in multiple parts of the app.

+ +

So, I was very careful while building that model to quarantine any references to any raw strings only within that model, which meant that I leaned really heavily on constants. And, in some way, those constants end up kind of documenting what we think the schema of that JSON should be. And that got me thinking; you were telling me recently about a scenario where some code you were working with relied heavily on constants as a form of documentation, and that documentation kind of lied to you.

+ +

STEPHANIE: Yeah, it did. And I think you mentioned something that I wanted to point out, which is that the magic strings that you think might change, and you wanted to pull that out into a constant, you know, so at least it's kind of defined in one place. And if it ever does change, you know, you don't have to change it in all of those places.

+ +

And I do think that, normally, you know, if there's opportunities to extract those magic strings and give a name to them, that is beneficial. But I was gripping a little bit about when constants become, I guess, like, too wieldy, or there's just kind of, like, too much of a dependency on them as the things documenting how the app should work when it's constantly changing. I realized that I just used constant and constantly [laughs].

+ +

JOËL: The only constant is that it is not constant.

+ +

STEPHANIE: Right. And so, the situation that I found myself in—this was on a client project a little bit ago—was that the constants became, like, gatekeepers of that logic where dev had to change it if the app's behavior changed, and maybe we wanted to change the value of it. And also, one thing that I noticed a lot was that we, as developers, were getting questions about, "Hey, like, how does this actually work?"

+ +

Like, we were using the constants for things like pricing of products, for things like what is a compatible version for this feature. And because that was only documented in the code, other people who didn't have access to it actually were left in the dark. And because those were changing with somewhat frequency, I was just kind of realizing how that was no longer working for us.

+ +

JOËL: Would you say that some of these values that we stored as constants were almost more like config rather than constants or maybe they're just straight-up application data? I can imagine something like price of an item you probably want that to be a value in the database that can be updated by an admin. And some of these other things maybe are more like config that you change through some kind of environment variable or something like that.

+ +

STEPHANIE: Yeah, that's a good point. I do think that they evolved to become things that needed to be configured, right? I suppose maybe there wasn't as much information or foresight at the beginning of like, oh, this is something that we expect to change. But, you know, kind of when you're doing that first pass and you're told, like, hey, like, this value should be the price of something, or, like, the duration of something, or whatever that may be. It gets codified [chuckles]. And there is some amount of lift to change it from something that is, at first, just really just documenting what that decision was at the time to something that ends up evolving.

+ +

JOËL: How would you draw a distinction between something that should be a constant versus something that maybe would be considered config or some other kind of value? Because it's pretty easy, right? As developers, we see magic numbers. We see magic strings. And our first thought is, oh, we've seen this problem before—constant. Do you have maybe a personal heuristic for when to reach for a constant versus when to reach for something else?

+ +

STEPHANIE: Yeah, that's a good question. I think when I started to see it a lot was especially when the constants were arrays or hashes [laughs]. And I guess that is actually kind of a signal, right? You will likely be adding more stuff [laughs] into that data structure [laughs]. And, again, like, maybe it's okay, like, the first couple of times. But once you're seeing that request happen more frequently, that could be a good way to advocate for storing it in the database or, like, building a lightweight admin kind of thing so that people outside of the dev team can make those configuration changes.

+ +

I think also just asking, right? Hey, like, how often do we suspect this will change? Or what's on the horizon for the product or the team where we might want to introduce a way to make the implementation a bit more flexible to something that, you know, we think we know now, but we might want to adjust for?

+ +

JOËL: So, it's really about change and how much we think this might change in the future.

+ +

STEPHANIE: Speaking of change, this actually kind of gets into the broader topic of documentation and how to document a changing and evolving entity [chuckles], you know, that being, like, the codebase or the way that decisions are made that impact how an application works. And you had shared, in preparation for this topic, an article that I read and enjoyed called Hierarchy of Documentation.

+ +

And one thing that I liked about it is that it kind of presented all of the places that you could put information from, you know, straight in the code, to in your commit messages, to your issue management system, and to even wikis for your repo or your team. And I think that's actually something that we would want to share with new developers, you know, who might be wondering, like, where do I find or even put information? I really liked how it was kind of, like, laid out and gave, like, different reasons for where you might want to put something or not.

+ +

JOËL: We think a lot about documentation as code writers. I'm curious what your experience is as a code reader. How do you tend to try to read code and understand documentation about how code works? And, apparently, the answer is, don't read the constants because these constants lie.

+ +

STEPHANIE: I think you are onto something, though, because I was just thinking about how distrustful I've become of certain types of documentation. Like, when I think of code comments, on one hand, they should be a signal, right? They should kind of draw your attention to something maybe weird or just, like, something to note about the code that it's commenting on, or where it's kind of located in a file.

+ +

But I sometimes tune them out, I'm not going to lie. When I see a really big block of code [chuckles] comment, I'm like, ugh, like, do I really have to read all of this? I'm also not positive that it's still relevant to the code below it, right? Like, I don't always have git blame, like, visually enabled in my editor. But oftentimes, when I do a little bit of digging, that comment is left over from maybe when that code was initially introduced. But, man, there have been lots of commits [chuckles] in the corresponding, you know, like, function sense, and I'm not really sure how relevant it is anymore.

+ +

Do you struggle with the signal versus noise issue with code comments? How much do you trust them, and how much do you kind of, like, give credence to them?

+ +

JOËL: I think I do tend to trust them with maybe some slight skepticism. It really depends on the codebase. Some codebases are really bad sort of comment hygiene and just the types of comments that they put in there, and then others are pretty good at it. The ones that I tend to particularly appreciate are where you have maybe some, like, weird function and you're like, what is going on here? And then you've got a nice, little paragraph up top explaining what's going on there, or maybe an explanation of ways you might be tempted to modify that piece of code and, like, why it is the way it is.

+ +

So, like, hey, you might be wanting to add an extra branch here to cover this edge case. Don't do that. We tried it, and it causes problems for XY reasons. And sometimes it might be, like, a performance thing where you say, look, the code quality person in you is going to look at this and say, hey, this is hard to read. It would be better if we did this more kind of normalized form. Know that we've particularly written this in a way that's hard to read because it is more performant, and here are the numbers. This is why we want it in this way. Here's a link to maybe the issue, or the commit, or whatever where this happened.

+ +

And then if you want to start that discussion up again and say, "Hey, do we really need performance here at the cost of readability?", you can start it up again. But at least you're not going to just be like, oh, while I'm here, I'm going to clean up this messy code and accidentally cause a regression.

+ +

STEPHANIE: Yeah. I like what you said about comment hygiene being definitely just kind of, like, variable depending on the culture and the codebase.

+ +

JOËL: I feel like, for myself, I used to be pretty far on the spectrum of no comments. If I feel the need to write a comment, that's a smell. I should find other ways to communicate that information. And I think I went pretty far down that extreme, and then I've been slowly kind of coming back. And I've probably kind of passed the center, where now I'm, like, slightly leaning towards comments are actually nice sometimes. And they are now a part of my toolkit. So, we'll see if I keep going there.

+ +

Maybe I'll hit some point where I realize that I'm putting too much work into comments or comments are not being helpful, and I need to come back towards the center again and focus on other ways of communicating. But right now, I'm in that phase of doing more comments than I used to. How about you? Where do you stand on that sort of spectrum of all information should be communicated in code tokens versus comments?

+ +

STEPHANIE: Yeah, I think I'm also somewhere in the middle. I think I have developed an intuition of when it feels useful, right? In my gut, I'm like, oh, I'm doing something weird. I wish I didn't have to do this [chuckles]. I think it's another kind of intuition that I have now. I might leave a comment about why, and I think that is more of that signal, right?

+ +

Though I also recently have been using them more as just, like, personal notes for myself as I'm, you know, in my normal development workflow, and then I will end up cleaning them up later. I was working on a codebase where there was a soft delete functionality. And that was just, like, a concern that was included in some of the models. And I didn't realize that that's what was going on. So, when I, you know, I was calling destroy, I thought it was actually being deleted, and it turns out it wasn't. And so, that was when I left a little comment for myself that was like, "Hey, like, this is soft deleted."

+ +

And some of those things I do end up leaving if I'm like, yes, other people won't have the same context as me. And then if it's something that, like, well, people who work in this app should know that they have soft delete, so then I'll go ahead and clean that up, even though it had been useful for me at the time.

+ +

JOËL: Do you capture that information and then put it somewhere else then? Or is it just it was useful for you as a stepping-stone on the journey but then you don't need it at the end and nobody else needs to care about it?

+ +

STEPHANIE: Oh, you know what? That's actually a really great point. I don't think I had considered saving that information. I had only thought about it as, you know, just stuff for me in this particular moment in time. But that would be really great information to pull out and put somewhere else [chuckles], perhaps in something like a wiki, or like a README, or somewhere that documents things about the system as a whole. Yeah, should we get into how to document kind of, like, bigger-picture stuff?

+ +

JOËL: How do you feel about wikis? Because I feel like I've got a bit of a love-hate relationship with them.

+ +

STEPHANIE: I've seen a couple of different flavors of them, right? Sometimes you have your GitHub wiki. Sometimes you have your Confluence ecosystem [laughs]. I have found that they work better if they're smaller [laughs], where you can actually, like, navigate them pretty well, and you have a sense of what is in there, as opposed to it just being this huge knowledge base that ends up actually, I think, working against you a little bit [laughs].

+ +

Because so much information gets duplicated if it's hard to find and people start contributing to it maybe without keeping in mind, like, the audience, right? I've seen a lot of people putting in, like, their own personal little scripts [laughs] in a wiki, and it works for them but then doesn't end up working for really anyone else. What's your love-hate relationship to them?

+ +

JOËL: I think it's similar to what you were saying, a little bit of structure is nice. When they've just become dumping grounds of information that is maybe not up to date because over the course of several years, you end up with a lot of maybe conflicting articles, and you don't know which one is the right thing to do, it becomes hard to find things.

+ +

So, when it just becomes a dumping ground for random information related to the company or the app, sometimes it becomes really challenging to find the information I need and to find information that's relevant, to the point where oftentimes looking something up in the wiki is my last resort. Like, I'm hoping I will find the answer to my question elsewhere and only fallback to the wiki if I can't.

+ +

STEPHANIE: Yeah, that's, like, the sign that the wiki is really not trustworthy. And it kind of is diminishing returns from there a bit. I think I fell into this experience on my last project where it was a really, really big wiki for a really big codebase for a lot of developers. And there was kind of a bit of a tragedy of the commons situation, where on one hand, there were some things that were so manual that the steps needed to be very explicitly documented, but then they didn't work a lot of the time [laughs].

+ +

But it was hard to tell if they weren't working for you or because it was genuinely something wrong with, like, the way the documentation laid out the steps. And it was kind of like, well, I'm going to fix it for myself, but I don't know how to fix it for everyone else. So, I don't feel confident in updating this information.

+ +

JOËL: I think that's what's really nice about the article that you mentioned about the hierarchy of documentation. It's that all of these different forms—code, comments, commit messages, pull requests, wikis—they don't have to be mutually exclusive. But sometimes they work sort of in addition to each other sort of each adding more context.

+ +

But also, sometimes it's you sort of choose the one that's the highest up on that list that makes sense for what you're trying to do, so something like documenting a series of steps to do something maybe a wiki is a good place for that. But maybe it's better to have that be executable. Could that be a script somewhere? And then maybe that can be a thing that is almost, like, living documentation, but also where you don't need to maybe even think about the individual steps anymore because the script is running, you know, 10 different things.

+ +

And I think that's something that I really appreciated from the book Sustainable Rails is there's a whole section there talking about the value of setup scripts and how people who are getting started on your app don't want to have to care about all the different things to set it up, just run a script. And also, that becomes living documentation for what the app needs, as opposed to maybe having a bulleted list with 10 elements in it in your project README.

+ +

STEPHANIE: Yeah, absolutely. In the vein of living documentation, I think one thing that wikis can be kind of nice for is for putting visual supplements. So, I've seen them have, like, really great graphs. But at the same time, you could use a gem like Rails-ERD that generates the entity relationship diagram as the schema of your database changes, right? So, it's always up to date.

+ +

I've seen that work well, too, when you want to have, like I said, those, like, system-level documentation that sometimes they do change frequently and, you know, sometimes they don't. But that's definitely worth keeping in mind when you choose, like, how you want to have that exist as information.

+ +

JOËL: How do you feel about deleting documentation? Because I feel like we put so much work into writing documentation, kind of like we do when writing tests. It feels like more is always better. Do you ever go back and maybe sort of prune some of your docs, or try to delete some things that you think might no longer be relevant or helpful?

+ +

STEPHANIE: I was also thinking of tests when you first posed that question. I don't know if I have it in my practice to, like, set aside time and be like, hmm, like, what looks outdated these days? I am starting to feel more confident in deleting things as I come across them if I'm like, I just completely ignored this or, like, this was just straight up wrong [laughs]. You know, that can be scary at first when you aren't sure if you can make that determination.

+ +

But rather than thrust that, you know, someone else going through that same process of spending time, you know, trying to think about if this information was useful or not, you can just delete it [laughs]. You can just delete tests that have been skipped for months because they don't work. Like, you can delete information that's just no longer relevant and, in some ways, causing you more pain because they are cluttering up your wiki ecosystem so that no one [laughs] feels that any of that information is relevant anymore.

+ +

JOËL: I'll be honest, I don't think I've ever deleted a wiki article that was out of date or no longer relevant. I think probably the most I've done is go to Slack and complain about how an out-of-date wiki page led me down the wrong path, which is probably not the most productive way to channel those feelings. So, maybe I should have just gone back and deleted the wiki page.

+ +

STEPHANIE: I do like to give a heads up, I think. It's like, "Hey, I want to delete this thing. Are there any qualms?" And if no one on your team can see a reason to keep it and you feel good about that it's not really, like, serving its purpose, I don't know, maybe consider just doing it.

+ +

JOËL: To kind of wrap up this topic, I've got a spicy question for you.

+ +

STEPHANIE: Okay, I'm ready.

+ +

JOËL: Do you think that AI is going to radically change the way that we interact with documentation? Imagine you have an LLM that you train on maybe not just your code but the Git history. It has all the Git comments and maybe your wiki. And then, you can just ask it, "Why does function foo do this thing?" And it will reference a commit message or find the correct wiki article. Do you think that's the future of understanding codebases?

+ +

STEPHANIE: I don't know. I'm aware that some people kind of can see that as a use case for LLMs, but I think I'm still a little bit nervous about the not knowing how they got there kind of part of it where, you know, yes, like I am doing this manual labor of trying to sort out, like, is this information good or trustworthy or not? But at least that is something I'm determining for myself. So, that is where my skepticism comes in a little bit. But I also haven't really seen what it can do yet or seen the outcomes of it. So, that's kind of where I'm at right now.

+ +

JOËL: So, you think, for you, the sort of the journey of trying to find and understand the documentation is a sort of necessary part of building the understanding of what the code is doing.

+ +

STEPHANIE: I think it can be. Also, I don't know, maybe my life would be better by having all that cut out for me, or I could be burned by it because it turns out that it was bad information [laughs]. So, I can't say for sure.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël shares his experiences with handling JSON in a Postgres database. He talks about his challenges with ActiveRecord and JSONB columns, particularly the unexpected behavior of storing and retrieving JSON data. Stephanie shares her recent discovery of bookmarklets and highlights a bookmarklet named "Check This Out," which streamlines searching for books on Libby, an ebook and audiobook lending app.

+ +

The conversation shifts to using constants in code as a form of documentation. Stephanie and Joël discuss how constants might not always accurately reflect current system behavior or logic, leading to potential misunderstandings and the importance of maintaining accurate documentation.

+ +
+ + + +

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: What's new in my world is JSON and how to deal with it in a Postgres database. So, I'm dealing with a situation where I have an ActiveRecord model, and one of the columns is a JSONB column. And, you know, ActiveRecord is really nice. You can just throw a bunch of different data at it, and it knows the column type, and it will do some conversions for you automatically.

+ +

So, if I'm submitting a form and, you know, form values might come in as strings because, you know, I typed in a number in a text field, but ActiveRecord will automatically parse that into an integer because it knows we're saving that to an integer column. So, I don't need to do all these, like, manual conversions.

+ +

Well, I have a form that has a string of JSON in it that I'm trying to save in a JSONB column. And I expected ActiveRecord to just parse that into a hash and store it in Postgres. That is not what happens. It just stores a raw string, so when I pull it out again, I don't have a hash. I have a raw string that I need to deal with. And I can't query it because, again, it is a raw string. So, that was a bit of an unexpected behavior that I saw there.

+ +

STEPHANIE: Yeah, that is unexpected. So, is this a field that has been used for a while now? I'm kind of surprised that there hasn't been already some implementations for, like, deserializing it.

+ +

JOËL: So, here's the thing: I don't think you can have an automatic deserialization there because there's no way of knowing whether or not you should be deserializing. The reason is that JSON is not just objects or, in Ruby parlance, hashes. You can also have arrays. But just raw numbers not wrapped in hashes are also valid JSON as are raw strings.

+ +

And if I just give you a string and say, put this in a JSON field, you have no way of knowing, is this some serialized JSON that you need to deserialize and then save? Or is it just a string that you should save because strings are already JSON? So, that's kind of on you as the programmer to make that distinction because you can't tell at runtime which one of these it is.

+ +

STEPHANIE: Yeah, you're right. I just realized it's [laughs] kind of, like, an anything goes [laughs] situation, not anything but strings are JSON, are valid JSON, yep [laughs]. That sounds like one of those things that's, like, not what you think about immediately when dealing with that kind of data structure, but...

+ +

JOËL: Right. So, the idea that strings are valid JSON values, but also all JSON values can get serialized as strings. And so, you never know: are you dealing with an unserialized string that's just a JSON value, or are you dealing with some JSON blob that got serialized into a string? And only in one of those do you want to then serialize before writing into the database.

+ +

STEPHANIE: So, have you come to a solution or a way to make your problem work?

+ +

JOËL: So, the solution that I did is just calling a JSON parse before setting that attribute on my model because this value is coming in from a form. I believe I'm doing this when I'm defining the strong parameters for that particular form. I'm also transforming that string by parsing it into a hash with the JSON dot parse, which then gets passed to the model. And then I'm not sure what JSONB serializes as under the hood. When you give it a hash, it might store it as a string, but it might also have some kind of binary format or some internal AST that it uses for storage. I'm not sure what the implementation is.

+ +

STEPHANIE: Are the values in the JSONB something that can be variable or dynamic? I've seen some people, you know, put that in getter so that it's just kind of done for you for anyone who needs to access that field.

+ +

JOËL: Right now, there is a sort of semi-consistent schema to that. I think it will probably evolve to where I'll pull some of these out to be columns on the table. But it is right now kind of an everything else sort of dumping ground from an API.

+ +

STEPHANIE: Yeah, that's okay, too, sometimes [laughs].

+ +

JOËL: Yeah. So, interesting journey into some of the fun edge cases of dealing with a format whose serialized form is also a valid instance of that format. What's been new in your world?

+ +

STEPHANIE: So, I discovered something new that has been around on the internet for a while, but I just haven't been aware of it. Do you know what a bookmarklet is?

+ +

JOËL: Oh, like a JavaScript code that runs in a bookmark?

+ +

STEPHANIE: Yeah, exactly. So, you know, in your little browser bookmark where you might normally put a URL, you can actually stick some JavaScript in there. And it will run whenever you click your bookmark in your browser [chuckles]. So, that was a fun little internet tidbit that I just found out about. And the reason is because I stumbled upon a bookmarklet made by someone. It's called Check This Out.

+ +

And what it does is there's another app/website called Libby that is used to check out ebooks and audiobooks for free from your local public library. And what this Check This Out bookmarklet does is you can kind of select any just, like, text on a web page, and then when you click the bookmarklet, it then just kind of sticks it into the query params for Libby's search engine. And it takes you straight to the results for that book or that author, and it saves you a few extra manual steps to go from finding out about a book to checking it out.

+ +

So, that was really neat and cute. And I was really surprised that you could do that. I was like, whoa [laughs]. At first, I was like, is this okay? [laughs] If you, like, you can't read, you know, you don't know what the JavaScript is doing, I can see it being a little sketchy. But –-

+ +

JOËL: Be careful of executing arbitrary JavaScript.

+ +

STEPHANIE: Yeah, yeah. When I did look up bookmarklets, though, I kind of saw that it was, you know, just kind of a fun thing for people who might be learning to code for the first time to play around with. And some fun ideas they had for what you could do with it was turning all the font on a web page to Comic Sans [laughs]. So yeah, I thought that was really cute.

+ +

JOËL: Has that inspired you to write your own?

+ +

STEPHANIE: Well, we did an episode a while ago on productivity tricks. And I was thinking like, oh yeah, there's definitely some things that I could do to, you know, just stick some automated tasks that I have into a bookmarklet. And that could be a really fun kind of, like, old-school way of doing it, as opposed to, you know, coding my little snippets or getting into a new, like, Omnibar app [laughs].

+ +

JOËL: So, something that is maybe a little bit less effort than building yourself a browser extension or something like that.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: I had a client project once that involved a...I think it was, like, a five-step wizard or something like that. It was really tedious to step through it all to manually test things. And so, I wrote a bookmarklet that would just go through and fill out all the fields and hit submit on, like, five pages worth of these things. And if anything didn't work, it would just pause there, and then you could see it. In some way, it was moving towards the direction of, like, an automated like Capybara style test. But this was something that was helping for manual QA. So, that was a really fun use of a bookmarklet.

+ +

STEPHANIE: Yeah, I like that. Like, just an in-between thing you could try to speed up that manual testing without getting into, like you said, an automated test framework for your browser.

+ +

JOËL: The nice thing about that is that this could be used without having to set up pretty much anything, right? You paste a bit of JavaScript into your bookmark bar, and then you just click the button. That's all you need to do. No need to make sure that you've got Ruby installed on your machine or any of these other things that you would need for some kind of testing framework. You don't need Selenium. You don't need ChromeDriver. It just...it works.

+ +

So, I was working...this was a greenfield startup project. So, I was working with a non-technical founder who didn't have all these things, you know, dev tooling on his machine. So, he wanted to try out things but not spend his days filling out forms. And so, having just a button he could click was a really nice shortcut.

+ +

STEPHANIE: That's really cool. I like that a lot. I wasn't even thinking about how I might be able to bring that in more into just my daily work, as opposed to just something kind of fun. But that's an awesome idea. And I hope that maybe I'll have a good use for one in the future.

+ +

JOËL: It feels like the thing that has a lot of potential, and yet I have not since written...I don't think I've written any bookmarklets for myself. It feels like it's the kind of thing where I should be able to do this for all sorts of fun tooling and just automate my life away. Somehow, I haven't done that.

+ +

STEPHANIE: Bring back the bookmarklet [laughs]. That's what I have to say.

+ +

JOËL: So, I mentioned earlier that I was working with a JSONB column and storing JSON on an ActiveRecord model. And then I wanted to interact with it, but the problem is that this JSON is somewhat arbitrary, and there are a lot of magic strings in there. All of the key names might change. And I was really concerned that if the schema of that JSON ever changed, if we changed some of the key names or something like that, we might accidentally break code in multiple parts of the app.

+ +

So, I was very careful while building that model to quarantine any references to any raw strings only within that model, which meant that I leaned really heavily on constants. And, in some way, those constants end up kind of documenting what we think the schema of that JSON should be. And that got me thinking; you were telling me recently about a scenario where some code you were working with relied heavily on constants as a form of documentation, and that documentation kind of lied to you.

+ +

STEPHANIE: Yeah, it did. And I think you mentioned something that I wanted to point out, which is that the magic strings that you think might change, and you wanted to pull that out into a constant, you know, so at least it's kind of defined in one place. And if it ever does change, you know, you don't have to change it in all of those places.

+ +

And I do think that, normally, you know, if there's opportunities to extract those magic strings and give a name to them, that is beneficial. But I was gripping a little bit about when constants become, I guess, like, too wieldy, or there's just kind of, like, too much of a dependency on them as the things documenting how the app should work when it's constantly changing. I realized that I just used constant and constantly [laughs].

+ +

JOËL: The only constant is that it is not constant.

+ +

STEPHANIE: Right. And so, the situation that I found myself in—this was on a client project a little bit ago—was that the constants became, like, gatekeepers of that logic where dev had to change it if the app's behavior changed, and maybe we wanted to change the value of it. And also, one thing that I noticed a lot was that we, as developers, were getting questions about, "Hey, like, how does this actually work?"

+ +

Like, we were using the constants for things like pricing of products, for things like what is a compatible version for this feature. And because that was only documented in the code, other people who didn't have access to it actually were left in the dark. And because those were changing with somewhat frequency, I was just kind of realizing how that was no longer working for us.

+ +

JOËL: Would you say that some of these values that we stored as constants were almost more like config rather than constants or maybe they're just straight-up application data? I can imagine something like price of an item you probably want that to be a value in the database that can be updated by an admin. And some of these other things maybe are more like config that you change through some kind of environment variable or something like that.

+ +

STEPHANIE: Yeah, that's a good point. I do think that they evolved to become things that needed to be configured, right? I suppose maybe there wasn't as much information or foresight at the beginning of like, oh, this is something that we expect to change. But, you know, kind of when you're doing that first pass and you're told, like, hey, like, this value should be the price of something, or, like, the duration of something, or whatever that may be. It gets codified [chuckles]. And there is some amount of lift to change it from something that is, at first, just really just documenting what that decision was at the time to something that ends up evolving.

+ +

JOËL: How would you draw a distinction between something that should be a constant versus something that maybe would be considered config or some other kind of value? Because it's pretty easy, right? As developers, we see magic numbers. We see magic strings. And our first thought is, oh, we've seen this problem before—constant. Do you have maybe a personal heuristic for when to reach for a constant versus when to reach for something else?

+ +

STEPHANIE: Yeah, that's a good question. I think when I started to see it a lot was especially when the constants were arrays or hashes [laughs]. And I guess that is actually kind of a signal, right? You will likely be adding more stuff [laughs] into that data structure [laughs]. And, again, like, maybe it's okay, like, the first couple of times. But once you're seeing that request happen more frequently, that could be a good way to advocate for storing it in the database or, like, building a lightweight admin kind of thing so that people outside of the dev team can make those configuration changes.

+ +

I think also just asking, right? Hey, like, how often do we suspect this will change? Or what's on the horizon for the product or the team where we might want to introduce a way to make the implementation a bit more flexible to something that, you know, we think we know now, but we might want to adjust for?

+ +

JOËL: So, it's really about change and how much we think this might change in the future.

+ +

STEPHANIE: Speaking of change, this actually kind of gets into the broader topic of documentation and how to document a changing and evolving entity [chuckles], you know, that being, like, the codebase or the way that decisions are made that impact how an application works. And you had shared, in preparation for this topic, an article that I read and enjoyed called Hierarchy of Documentation.

+ +

And one thing that I liked about it is that it kind of presented all of the places that you could put information from, you know, straight in the code, to in your commit messages, to your issue management system, and to even wikis for your repo or your team. And I think that's actually something that we would want to share with new developers, you know, who might be wondering, like, where do I find or even put information? I really liked how it was kind of, like, laid out and gave, like, different reasons for where you might want to put something or not.

+ +

JOËL: We think a lot about documentation as code writers. I'm curious what your experience is as a code reader. How do you tend to try to read code and understand documentation about how code works? And, apparently, the answer is, don't read the constants because these constants lie.

+ +

STEPHANIE: I think you are onto something, though, because I was just thinking about how distrustful I've become of certain types of documentation. Like, when I think of code comments, on one hand, they should be a signal, right? They should kind of draw your attention to something maybe weird or just, like, something to note about the code that it's commenting on, or where it's kind of located in a file.

+ +

But I sometimes tune them out, I'm not going to lie. When I see a really big block of code [chuckles] comment, I'm like, ugh, like, do I really have to read all of this? I'm also not positive that it's still relevant to the code below it, right? Like, I don't always have git blame, like, visually enabled in my editor. But oftentimes, when I do a little bit of digging, that comment is left over from maybe when that code was initially introduced. But, man, there have been lots of commits [chuckles] in the corresponding, you know, like, function sense, and I'm not really sure how relevant it is anymore.

+ +

Do you struggle with the signal versus noise issue with code comments? How much do you trust them, and how much do you kind of, like, give credence to them?

+ +

JOËL: I think I do tend to trust them with maybe some slight skepticism. It really depends on the codebase. Some codebases are really bad sort of comment hygiene and just the types of comments that they put in there, and then others are pretty good at it. The ones that I tend to particularly appreciate are where you have maybe some, like, weird function and you're like, what is going on here? And then you've got a nice, little paragraph up top explaining what's going on there, or maybe an explanation of ways you might be tempted to modify that piece of code and, like, why it is the way it is.

+ +

So, like, hey, you might be wanting to add an extra branch here to cover this edge case. Don't do that. We tried it, and it causes problems for XY reasons. And sometimes it might be, like, a performance thing where you say, look, the code quality person in you is going to look at this and say, hey, this is hard to read. It would be better if we did this more kind of normalized form. Know that we've particularly written this in a way that's hard to read because it is more performant, and here are the numbers. This is why we want it in this way. Here's a link to maybe the issue, or the commit, or whatever where this happened.

+ +

And then if you want to start that discussion up again and say, "Hey, do we really need performance here at the cost of readability?", you can start it up again. But at least you're not going to just be like, oh, while I'm here, I'm going to clean up this messy code and accidentally cause a regression.

+ +

STEPHANIE: Yeah. I like what you said about comment hygiene being definitely just kind of, like, variable depending on the culture and the codebase.

+ +

JOËL: I feel like, for myself, I used to be pretty far on the spectrum of no comments. If I feel the need to write a comment, that's a smell. I should find other ways to communicate that information. And I think I went pretty far down that extreme, and then I've been slowly kind of coming back. And I've probably kind of passed the center, where now I'm, like, slightly leaning towards comments are actually nice sometimes. And they are now a part of my toolkit. So, we'll see if I keep going there.

+ +

Maybe I'll hit some point where I realize that I'm putting too much work into comments or comments are not being helpful, and I need to come back towards the center again and focus on other ways of communicating. But right now, I'm in that phase of doing more comments than I used to. How about you? Where do you stand on that sort of spectrum of all information should be communicated in code tokens versus comments?

+ +

STEPHANIE: Yeah, I think I'm also somewhere in the middle. I think I have developed an intuition of when it feels useful, right? In my gut, I'm like, oh, I'm doing something weird. I wish I didn't have to do this [chuckles]. I think it's another kind of intuition that I have now. I might leave a comment about why, and I think that is more of that signal, right?

+ +

Though I also recently have been using them more as just, like, personal notes for myself as I'm, you know, in my normal development workflow, and then I will end up cleaning them up later. I was working on a codebase where there was a soft delete functionality. And that was just, like, a concern that was included in some of the models. And I didn't realize that that's what was going on. So, when I, you know, I was calling destroy, I thought it was actually being deleted, and it turns out it wasn't. And so, that was when I left a little comment for myself that was like, "Hey, like, this is soft deleted."

+ +

And some of those things I do end up leaving if I'm like, yes, other people won't have the same context as me. And then if it's something that, like, well, people who work in this app should know that they have soft delete, so then I'll go ahead and clean that up, even though it had been useful for me at the time.

+ +

JOËL: Do you capture that information and then put it somewhere else then? Or is it just it was useful for you as a stepping-stone on the journey but then you don't need it at the end and nobody else needs to care about it?

+ +

STEPHANIE: Oh, you know what? That's actually a really great point. I don't think I had considered saving that information. I had only thought about it as, you know, just stuff for me in this particular moment in time. But that would be really great information to pull out and put somewhere else [chuckles], perhaps in something like a wiki, or like a README, or somewhere that documents things about the system as a whole. Yeah, should we get into how to document kind of, like, bigger-picture stuff?

+ +

JOËL: How do you feel about wikis? Because I feel like I've got a bit of a love-hate relationship with them.

+ +

STEPHANIE: I've seen a couple of different flavors of them, right? Sometimes you have your GitHub wiki. Sometimes you have your Confluence ecosystem [laughs]. I have found that they work better if they're smaller [laughs], where you can actually, like, navigate them pretty well, and you have a sense of what is in there, as opposed to it just being this huge knowledge base that ends up actually, I think, working against you a little bit [laughs].

+ +

Because so much information gets duplicated if it's hard to find and people start contributing to it maybe without keeping in mind, like, the audience, right? I've seen a lot of people putting in, like, their own personal little scripts [laughs] in a wiki, and it works for them but then doesn't end up working for really anyone else. What's your love-hate relationship to them?

+ +

JOËL: I think it's similar to what you were saying, a little bit of structure is nice. When they've just become dumping grounds of information that is maybe not up to date because over the course of several years, you end up with a lot of maybe conflicting articles, and you don't know which one is the right thing to do, it becomes hard to find things.

+ +

So, when it just becomes a dumping ground for random information related to the company or the app, sometimes it becomes really challenging to find the information I need and to find information that's relevant, to the point where oftentimes looking something up in the wiki is my last resort. Like, I'm hoping I will find the answer to my question elsewhere and only fallback to the wiki if I can't.

+ +

STEPHANIE: Yeah, that's, like, the sign that the wiki is really not trustworthy. And it kind of is diminishing returns from there a bit. I think I fell into this experience on my last project where it was a really, really big wiki for a really big codebase for a lot of developers. And there was kind of a bit of a tragedy of the commons situation, where on one hand, there were some things that were so manual that the steps needed to be very explicitly documented, but then they didn't work a lot of the time [laughs].

+ +

But it was hard to tell if they weren't working for you or because it was genuinely something wrong with, like, the way the documentation laid out the steps. And it was kind of like, well, I'm going to fix it for myself, but I don't know how to fix it for everyone else. So, I don't feel confident in updating this information.

+ +

JOËL: I think that's what's really nice about the article that you mentioned about the hierarchy of documentation. It's that all of these different forms—code, comments, commit messages, pull requests, wikis—they don't have to be mutually exclusive. But sometimes they work sort of in addition to each other sort of each adding more context.

+ +

But also, sometimes it's you sort of choose the one that's the highest up on that list that makes sense for what you're trying to do, so something like documenting a series of steps to do something maybe a wiki is a good place for that. But maybe it's better to have that be executable. Could that be a script somewhere? And then maybe that can be a thing that is almost, like, living documentation, but also where you don't need to maybe even think about the individual steps anymore because the script is running, you know, 10 different things.

+ +

And I think that's something that I really appreciated from the book Sustainable Rails is there's a whole section there talking about the value of setup scripts and how people who are getting started on your app don't want to have to care about all the different things to set it up, just run a script. And also, that becomes living documentation for what the app needs, as opposed to maybe having a bulleted list with 10 elements in it in your project README.

+ +

STEPHANIE: Yeah, absolutely. In the vein of living documentation, I think one thing that wikis can be kind of nice for is for putting visual supplements. So, I've seen them have, like, really great graphs. But at the same time, you could use a gem like Rails-ERD that generates the entity relationship diagram as the schema of your database changes, right? So, it's always up to date.

+ +

I've seen that work well, too, when you want to have, like I said, those, like, system-level documentation that sometimes they do change frequently and, you know, sometimes they don't. But that's definitely worth keeping in mind when you choose, like, how you want to have that exist as information.

+ +

JOËL: How do you feel about deleting documentation? Because I feel like we put so much work into writing documentation, kind of like we do when writing tests. It feels like more is always better. Do you ever go back and maybe sort of prune some of your docs, or try to delete some things that you think might no longer be relevant or helpful?

+ +

STEPHANIE: I was also thinking of tests when you first posed that question. I don't know if I have it in my practice to, like, set aside time and be like, hmm, like, what looks outdated these days? I am starting to feel more confident in deleting things as I come across them if I'm like, I just completely ignored this or, like, this was just straight up wrong [laughs]. You know, that can be scary at first when you aren't sure if you can make that determination.

+ +

But rather than thrust that, you know, someone else going through that same process of spending time, you know, trying to think about if this information was useful or not, you can just delete it [laughs]. You can just delete tests that have been skipped for months because they don't work. Like, you can delete information that's just no longer relevant and, in some ways, causing you more pain because they are cluttering up your wiki ecosystem so that no one [laughs] feels that any of that information is relevant anymore.

+ +

JOËL: I'll be honest, I don't think I've ever deleted a wiki article that was out of date or no longer relevant. I think probably the most I've done is go to Slack and complain about how an out-of-date wiki page led me down the wrong path, which is probably not the most productive way to channel those feelings. So, maybe I should have just gone back and deleted the wiki page.

+ +

STEPHANIE: I do like to give a heads up, I think. It's like, "Hey, I want to delete this thing. Are there any qualms?" And if no one on your team can see a reason to keep it and you feel good about that it's not really, like, serving its purpose, I don't know, maybe consider just doing it.

+ +

JOËL: To kind of wrap up this topic, I've got a spicy question for you.

+ +

STEPHANIE: Okay, I'm ready.

+ +

JOËL: Do you think that AI is going to radically change the way that we interact with documentation? Imagine you have an LLM that you train on maybe not just your code but the Git history. It has all the Git comments and maybe your wiki. And then, you can just ask it, "Why does function foo do this thing?" And it will reference a commit message or find the correct wiki article. Do you think that's the future of understanding codebases?

+ +

STEPHANIE: I don't know. I'm aware that some people kind of can see that as a use case for LLMs, but I think I'm still a little bit nervous about the not knowing how they got there kind of part of it where, you know, yes, like I am doing this manual labor of trying to sort out, like, is this information good or trustworthy or not? But at least that is something I'm determining for myself. So, that is where my skepticism comes in a little bit. But I also haven't really seen what it can do yet or seen the outcomes of it. So, that's kind of where I'm at right now.

+ +

JOËL: So, you think, for you, the sort of the journey of trying to find and understand the documentation is a sort of necessary part of building the understanding of what the code is doing.

+ +

STEPHANIE: I think it can be. Also, I don't know, maybe my life would be better by having all that cut out for me, or I could be burned by it because it turns out that it was bad information [laughs]. So, I can't say for sure.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+o4Nw69K- + + ]]> + + Joël Quenneville + Stephanie Minn + + + 409: Support & Maintenance and Rotating Developers + https://bikeshed.thoughtbot.com/409 + f783ee05-d6c7-4d4f-96f1-3793aa48e70b + Tue, 05 Dec 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie recommends "Blue Eye Samurai" and a new ceramic pot (donabe) for cooking. Joël talks about the joy of holding a warm beverage in a unique mug. + +Stephanie discusses her shift to a part-time support and maintenance role at thoughtbot, contrasting it with her full-time development work. She highlights the importance of communication, documentation, and workplace flexibility in this role. Stephanie appreciates the professional growth opportunities and aligns this flexible work style with her long-term career goals. + 28:07 + no + + + Stephanie recommends "Blue Eye Samurai" and a new ceramic pot (donabe) for cooking. Joël talks about the joy of holding a warm beverage in a unique mug. +Stephanie discusses her shift to a part-time support and maintenance role at thoughtbot, contrasting it with her full-time development work. She highlights the importance of communication, documentation, and workplace flexibility in this role. Stephanie appreciates the professional growth opportunities and aligns this flexible work style with her long-term career goals. +Blue Eye Samurai (https://www.netflix.com/title/81144203) +Donabe pots (https://jinenstore.com/collections/nagatani-en) +thoughtbot’s Support & Maintenance services (https://thoughtbot.com/services/rails-maintenance) +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: I have a TV show recommendation this week. I think this is my first time having TV or movies to recommend, so this will be fun. My partner and I just finished watching Blue Eye Samurai on Netflix, which is an animated historical Samurai drama. +But the really cool thing about it is that the protagonist she's a woman who is disguising herself as a man, and she is half Japanese and half White, which the show takes place during Edo, Japan. And so that was a time when Japan was locked down, and there were no outsiders allowed in the country. And so, to be mixed race like that was to be, like, kind of, like, demonized and to be really excluded and shamed. And so, the main character is on, like, a revenge mission. +And it was such a cool show. I was kind of, like, on the edge of my seat the whole time. And it's very beautifully animated. There were just a lot of really awesome things about it. And I think it's very different from what I've been seeing on TV these days. +JOËL: Is this a single-season show? +STEPHANIE: So far, there's just one season. I think it's pretty new, yeah. It's very watchable in a couple of weekends. +[laughter] +JOËL: Dangerously so. +STEPHANIE: Yeah, exactly [laughs]. +JOËL: How do you feel about the way they end the arc in season one? Do they kind of leave you on a cliffhanger, or does it feel like a pretty satisfying place? +STEPHANIE: Ooh, I think both, which is the sweet spot, in my opinion, where it's not, like, cliffhanger for the sake of, like, ugh, now I feel like I have to just watch the next part to see what happens because I was left unsatisfied. I like when seasons are kind of like chapters of the story, right? And the characters are also well written, too, and really fleshed out even, you know, some of the side characters. They all have their arcs that are really satisfying. And, again, I just was left very impressed. +JOËL: I guess that's the power of good storytelling. +STEPHANIE: Yeah. I was reading a review of the show. And that was kind of the theme of–it was just that, like, this is really good storytelling, and I would have to agree. Yeah, I highly recommend checking it out. It was very fun. It was very bloody, but [chuckles], for me, it being animated actually made it a little more palatable for me [laughs]. The fight scenes, the action scenes were really cool. +I think the way that it's been described is kind of, like, you know, if you like historical dramas, or if you like things like Game of Thrones, there's kind of something for everyone. I recommend checking it out. Joël, what's new in your world? +JOËL: Listeners of the show don't know this, but you and I are on a video call while we're recording this. And you'd commented earlier that I was holding a cool mug. It's got a rock climbing hold as a handle, which is pretty fun. I enjoy a lot of bouldering. That makes it a fun mug. +But I was recently thinking about just how much pleasure I get from holding a mug with a warm beverage. It's such a small thing, but it makes me so happy. And that got me thinking more broadly about what are things in life that are kind of like that. They're small things that have, like, an outsized impact on your happiness. Do you have anything like that? +STEPHANIE: Oh yes, absolutely. You were talking about the warmth of a hot beverage in your hands. And I was thinking about something similar, too, because I'm pretty sure this time of year last year, I talked about something that was new in my world that was just, like, a thing that I got to make winter more tolerable for me here in Chicago, and I think it was, like, a heated blanket [laughs]. +And I am similarly in that space this year of like, what can I do or get to make this winter better than last winter? So, this year, what I got that I'm really excited to use— it actually just came in the mail—is this ceramic pot called the donabe that's kind of mainly used for Japanese cooking, especially, like, hot pot. And so, it will be a huge improvement to my soup game this year [laughs]. +Similarly, it's kind of, like, one of those small things where you can take it from the stovetop where you're cooking straight to the table, and I'm so looking forward to that. It's kind of like your hot beverage in your hand but, like, three times the size [laughs]. +JOËL: Right. The family-style version of it. +STEPHANIE: Yeah, exactly. So, that's what I'm really looking forward to this year as something that is just, like, I don't know, a little small upgrade to my regular soup routine. But I think I will get a lot of pleasure [laughs] out of it. +JOËL: What do you normally cook in that style of pot? Is it typically you do a hot pot in there, or is it meant for soups? +STEPHANIE: Yeah, it holds heat really well, so I think that's why it's used for soup a lot. And the one that I got specifically has a little ceramic steamer plate as well. And so, I'm looking forward to having, like, this setup that's made for steaming, where you don't have to have any, like, too many extra bits. And, again, it can go from stove to table, and that's one less thing I [chuckles] need to wash. +JOËL: I love it. So, something else that is kind of new in your world is you'd mentioned on a recent episode you'd wrapped up with your current client. And you've rotated on to not exactly a new client but a new almost line of business. You're doing a rotation with our support and maintenance team. Can you tell us a little bit about what that is like? +STEPHANIE: Yeah. I'm excited to share more about it because this is my first time on this team doing this work. And it's pretty new for thoughtbot, too. I think it's only, like, a year old that we have had this sub-team of the one that you and I are on, Boost. In the sub-team, support and maintenance is focused on providing flexible part-time work for clients who are just needing some dedicated hours, not necessarily for, you know, a lot of, like, intense new feature work, but making sure that things are running smoothly. +A lot of the clients, you know, have had Rails apps that are several years old, that are chugging along [chuckles], just need that, like, attention every now and then to make sure that upgrades are happening, fix any bugs, kind of as the app just continues to work and provide value. And then, occasionally, there is a little bit of feature work. +But the interesting thing about being on this team is that instead of being on one client full-time, you are working on a lot of different clients at the same time, and a lot of them are on retainers. So, they maybe have, like, 20 hours a month of work that gets filled with kind of whatever tasks need to be done during that time. So yeah, I recently joined a few days ago and have been very surprised by kind of this style of work. It's different from what I'm used to. +JOËL: That seems pretty different than the sort of traditional thoughtbot client engagement. Typically, if I'm a client and I'm hiring a team from thoughtbot, as a client, I get sort of a dedicated team. And they're probably either building some things for me or maybe working with my team and sort of full-time building features. +Whereas if I hire the support and maintenance team, it sounds like it's a bit more ad hoc. And it's things I assume it's like, oh, we probably need to upgrade our Rails version since a new release came out last month. Can you do that? Here's a small bug that was reported. Can somebody fix that? Things along those lines. Is that pretty approximate of what the experience is for a client? +STEPHANIE: Yeah, I would say so. I think the other surprising thing has been there have been a little bit of more DevOps type of tasks as well mixed in there. Because oftentimes, these are smaller clients who maybe have, like, a few developers actively working on new features and that type of stuff. But there is, like, so much of the connecting work that needs to happen when you have an application. And if you don't have a full in-house team for that, that often gets put on developers' plates. But it's kind of nice to have this flexible support and maintenance team, again, to, like, do the work as it comes up. +A lot of it is not necessarily, like, stuff that can be planned in advance. It's kind of like, oh, we're hitting, like, our usage limit for this Heroku add-on. Let's evaluate if this is still working for us, if this is a good tier to be on. Like, should we upgrade? Are there other levers we could pull or adjustments we can make? +So, that's actually been some of the stuff that I've been working on, too, which is, again, a little bit different from normal development work but also still very much related. And it's all kind of part of the job. And, you know, a lot of the skills are transferable. And to know how to do development in a framework then sets you up, I think, really well to, like, be able to make those kinds of evaluations. +JOËL: So, it sounds like you almost, in a sense, provide a bit of a velocity cushion for clients so that if something does come up where they would maybe normally need to pull a dev off of feature work to do some side thing for a couple of days, you can come in and handle that so that their dev team stays focused on shipping features. +STEPHANIE: Yeah, I like that phrase you used: velocity cushion. That's cool. I like it. The other surprising thing that I have kind of quite enjoyed, at least for now, is because we bill a little bit differently on this work; we have to track our hours more explicitly. And that has actually helped me focus a lot more on what I'm doing and if I should continue to be doing what I'm doing. I'm timeboxing things a lot more because I know that if there is a ceiling on the number of hours, I want to make sure that that time is spent in the most valuable way. +And I also really enjoy, like, the boundaries of timeboxing, yes, but also, like, the tasks are usually scoped pretty narrowly so that they are things that you can accomplish, definitely in the week, because you don't know if you'll kind of still be working for this client next week but even more so, like, within a few days. +And that is nice because I can kind of, like, you know, track my hours, finish the task, and then feel a little bit more free to go do something else without being, like, okay, like, what's the next thing that I need to be doing? There's a little bit more freedom, I think, when you're kind of, like, optimizing towards, like, finishing each item. +JOËL: Do the stories of the work that you have to do does it typically come kind of pre-scoped? Are you involved in making sure that it has, like, very aggressive scoping? +STEPHANIE: Yeah. So far, I've not been involved in doing the scoping work, and it has come pre-scoped, which has been nice. This was also, again, just different. Because I was on a client team previously, a lot of the work to be done was the disambiguating, the, like, figuring out what to be doing. Whereas here, because, again, we're kind of optimized for people coming in and out, if there is uncertainty or lack of clarity, it's pointed out early, and someone is like, "Okay, I will take care of this. Like, I'll take the lead on this so that it can be handed off." +One client that I'm working on is using Basecamp's Shape Up methodology, which I actually hadn't worked with in a very explicit way before. And that has been interesting to learn about a little bit, too. One thing that I have enjoyed about it is instead of sprints, they're called cycles. And I like that a lot because, you know, sprints kind of have the connotation of, like, you're running as fast as you can but also, like, you can't run that way forever [laughs]. And so, even that, like, little bit of rewording change is really nice. The variable part is scope, right? It's we're focused on delivering something completely and very intentionally cutting scope as kind of the main lever. +JOËL: How do you maintain sort of focus and flow if you're jumping across multiple clients? Because you said, you work with multiple clients as part of this team. And I feel like I can get a little bit frustrated sometimes, even just jumping between, like, tickets within one project. And so, I could imagine that jumping between different clients during the week or even the day might be really disruptive. Have you found techniques to help you stay in the flow? +STEPHANIE: Yeah, that is a tough one because, also, every client has their different application; you then have to start up on [laughs] your local machine, and that is kind of annoying. You know, I do still tend to kind of, like, bundle similar work together. If, like, there's a few things I can do for a client on one day, I'll make sure to focus on that. +But what I mentioned earlier about, like, seeing something to completion has been really, I want to say, fun even. Because it then kind of, like, frees up that mental space of, like, okay, I don't have to, like, have this thing that I'm working on lingering in my head about, like, oh, did I forget to do something? Or, you know, have, like, shower thoughts of like, oh, I just thought of a new way to implement this [laughs] feature because it doesn't spill over as much as maybe larger initiatives anyway. +And so, I am context-switching, but it's only kind of after I've gotten something to a good place where I've left all of the notes. And that's another thing that I'm now kind of compelled to do a little more actively. It's like, every single day, I'm kind of making sure that the work that I've done has been reported on, one, because I have to track my hours, so, you know, and I sometimes leave notes about what that time was spent on doing. +And also, when the expectation is that someone else will be picking up, then there's no, like, oh, like, let me hold on to this, and only when I know that I have to hand off something that's when I'll do the, like, dedicated knowledge dumping. It's kind of just built into the process a little more frequently. +JOËL: So, you're setting up for, like, an imminent vacation factor. +STEPHANIE: Yeah. Which I kind of like because then I can take a vacation [laughs] whenever I want and not have to worry too much about, oh, did I do everything I needed to do before I leave? +JOËL: So, you know, these practices that you're doing are specifically adapted for the style of work that you have. Are there any that you think you would bring to your own practice if you ever rotated back on to a dedicated client project, anything that you would do there that you would want to include from your practice here? +STEPHANIE: Yeah. It does sound kind of weird because part of what's nice about being on a full-time team is that there is less, oh, if I don't get something done today, I have tomorrow to do it [laughs]. And it seems like that would be like, oh, like, kind of take the pressure off a little bit. +But I would be really curious to continue having, like, such an intense awareness about how I'm spending my time. Because I've certainly gotten a little bit lax on, like, full-time development work when you just go down a rabbit hole [laughs] and you come out, like, three hours later, and you're like, "What did I just do?" [laughs] And, you know, maybe that's what needed to be done, and that's fine. +But if you have the information that it took you three hours, you can at least make a better-informed decision about, like, oh, maybe I should have stopped a little earlier or, like, yeah, it took about three hours, and that's okay. I think that would be an interesting area to incorporate and to be able to report more frequently. And I also like to know how other people spend their time, too. So, just, like, that sharing of information would also be really beneficial even to, like, a team. +JOËL: What about the more aggressive documentation? Is that something that...because that can be really time-consuming, I imagine, as well. Is that something that you would value in a kind of, more focused full-time project context? +STEPHANIE: Yeah. One part I've enjoyed about it is that I'm documenting, like, decision-making a lot more actively where, you know, I'm kind of, like, surfacing to be like, hey, here's the outcomes of, like, my research. We're not as, you know, embedded in the business, and we don't have as much of that, like, context and knowledge about what the best solutions are all the time. I'm documenting all of that, you know, usually, for the client stakeholder to be like, "Hey, here's my recommendations, like, how do you want to...what do you think is the best way to go? +On one hand, it's kind of nice not to have to, like, be solely responsible for making that decision, right? And I'm kind of, like, leaning on, like, hey, like, you're the expert of your application and your product, you know, here's what I've learned. And now I've, like, put this all, like, for you and presented it to you. +And I think that, for me, has gotten lost sometimes when I end up being the same person of, like, doing the research and then deciding, and it just kind of ends up being held in my head. And that, I think, is something really important to document, even if it's just for other people to, like, see how that process might work or, like, what things I already considered or didn't try. That exercise, I think, can be really important. +So, so far, the documentation has not necessarily been, like, code level, but more, like, for each task, it's, like, showing your work, right? And not in a, like, you're being monitored [laughs] sort of way but in a way that supports it getting done with a lot of that turnover. +JOËL: It's almost like a mini report that you're doing. So, you'd mentioned, for example, an application running into memory problems on Heroku. It sounds like you would then go maybe investigate that and then make some recommendations on whether they need to increase some dynos or maybe make some internal changes. It sounds like you may or may not be the one to execute those changes. But you would write up some, like, a mini report and submit that to the client, and then they can make their own execution choices. +STEPHANIE: Yeah, exactly. And they can execute it themselves or then create a new ticket for the next person rotating on to support and maintenance to tackle it in a different cycle. +JOËL: So, support and maintenance doesn't just do the investigation. Your team might do the execution as well. It's just that the sort of more research-y stuff and the execution stuff gets split out into different tickets because it's so tightly scoped. +STEPHANIE: Yeah, that sounds right. +JOËL: I like that. +STEPHANIE: One area that I wasn't sure that I was going to like so much about this kind of work is, you know, when you're not kind of embedded on a team, I was thinking that I might not feel as connected, or I would miss a bit of that getting to know people and just, like, seeing people face to face on a daily basis. +I'm still evaluating how that would go so far because it has definitely been, like, mostly asynchronous communication, you know, which is what works well for this type of the style of team or project. But I think what has been helpful is realizing that, like, oh yeah, like, I can also get that elsewhere, you know, with thoughtbot folks like with you doing this podcast every week. +And right now, there are, like, two Boost members who are doing support and maintenance full time, and folks who are unbooked kind of come in and out. And I can see that there's still a team. So, it's not nearly as kind of, like, isolating as what I had thought it would be. +JOËL: There's something that's really curious to me, I think, sitting at the intersection of the idea of fostering more team interactions and the sort of, like, mini reports that you write. And that's that I would love to see more sharing among all of us at thoughtbot about different interesting problems that we've had to solve or that we're tackling on different client work. Because I think in that case, it's a situation where we all just learn something, you know, maybe I've never had to deal with a memory leak or might not even have an idea of, like, how to approach memory issues on Heroku. +So, seeing your little mini report, if you'd maybe share that, and, you know, maybe it can be anonymized in some way if needs to, I think would be really nice, at the very least, something that could be done, like, internally. So, I almost wonder if, like, building that practice of, you know, maybe not for every ticket that I do because, you know, I don't want to just be dumping my tickets in the thoughtbot Slack. But I run into something interesting and be like, oh, let me tell a little story about this and do a little write-up. That might be something that's good for the whole team and not just for folks who are on support and maintenance. +STEPHANIE: Yeah, absolutely. As you were saying that, I was thinking about how it does kind of encourage me to find support outside of my, like, immediate team, right? Because I don't necessarily have one with the client and to, I don't know, I'm imagining, like, these roots growing in terms of different communities I'm a part of and bringing those problems just outside of my internal world, and kind of getting that outside feedback because by necessity a little bit, right? But also, with the added benefit of, you know, I think that's also how a lot of people end up writing content that gets shared with the world. +So, I had the misconception that I would be kind of just, like, on my own off doing things like just tickets and being a little coding robot, but I've been surprised by it feels very fresh and new. So, I think, I guess, I was needing a little bit of that [laughs]. +JOËL: I was having a conversation with another thoughtboter recently about how valuable sometimes change can be for its own sake and how that can sort of refresh. You want it just at the rate where you have a chance to build some stability. You don't want chaos. But sometimes change can sort of take you out of a rut, give you energy, maybe sort of restart some good habits that you had sort of let atrophy. And that finding, like, just that right level of shaking things up can really help a team, you know, get their effectiveness to the next level. +STEPHANIE: Yeah. I like what you said about good habits, for sure. A couple of other random, little things that I just thought of about what I've liked is, I don't know, maybe this is a little silly. But we, you know, use shared credentials for logging into different services and applications or third parties that clients are using. And that has actually been something that has been so easy [laughs] and very low friction compared to, you know, joining a new project and manually be added as, like, your individual account to all of the different things. And things inevitably get forgotten, and then you have to rely on someone else to do it. And sometimes they don't get back to you [laughs] for a while. +The self-serviceness of this work has been cool, too. And I just, yeah, wanted to say that I really appreciated the thought that went into making it as easy as possible to be like, yeah, I can find the credentials here. It is, you know, a bit more anonymized because I'm just using, like, a shared account. +JOËL: Like a generic thoughtbot account on a client system rather than stephanie@thoughtbot. +STEPHANIE: Yeah, exactly. But I think I saved so much time [laughs] this week just being able to do all of that myself and, you know, knowing where to look first before having to ask. +JOËL: I guess you'd need something like that, right? If you're only jumping in on a project for the first time, for a couple of hours or something like that, you don't want to go through a whole onboarding process because that might then, like, easily double. You know, instead of doing two hours on this project, you're now doing four. +STEPHANIE: Yeah, exactly. I guess the other takeaway, for me, was like, oh, definitely, if I were to have to set up accounts [laughs] for an application, you know, I've obviously seen where it was like, very clearly, like, the founder having created all these personal accounts for this services, and people are still using their credentials many years later [laughs], even though they probably, like, maybe may not even work for the company anymore. +But yeah, the shared credentials and using that generic account that anyone can kind of get into when needed has really lowered the barrier to jump into doing that work, right? And especially because, like you said, it reduces that time. And we're, you know, billing by the hour anyway. So, it's kind of a win-win situation. +JOËL: And I totally understand why you would not want something like that for a longer engagement. But for something like support and maintenance, it sounds like it was the right choice. +STEPHANIE: Yeah, yeah. Again, I just mentioned it because it's just different. And so, maybe if this sparks any ideas for our listeners about how processes could be different or, like, the styles or ways of working can be different, I think that would be cool. +JOËL: And just to be clear here, it sounds like what you're doing is for sort of each client; you create a separate set of credentials that are for that client but that are about thoughtbot generically. You don't have, like, one thoughtbot email and password that we reuse for every client. +STEPHANIE: [laughs] Oh yes. That would be not so good [laughs] if we got hacked and suddenly, now they have access to everything. +JOËL: So, every client gets its own unique email password combo. We're using security best practices here. And then, since you do have to share them through a team, are you doing some sort of, like, shared 1Password vault or something along those lines? +STEPHANIE: Yeah, we are using a shared 1Password vault. That is definitely what I meant [laughs] the first time when I was mentioning the shared credentials, where that was basically the only thing I had to get onboarded to, the vault, for support and maintenance to be able to hit the ground running. +JOËL: So, this sounds like a pretty exciting new style of project for you. Is this something that you would see yourself preferring to do longer term, to sort of focus on this style of project? Or do you think that you'd like to come back to more classic project work in the near future? +STEPHANIE: I'm not sure yet, but I'm also hoping to have an answer to that question. And it definitely does feel like an experiment for me personally. I can see liking it, and that also fitting well with some of my longer-term goals of being able to, like, step back from work. Maybe working fewer days a week is something that I've, like, thought about in terms of, like, a long-term goal of mine because I'm not as needed [laughs] on a team. +Which I think, in the past, I also had a bit of a misconception that, like, in order to be a good developer, I had to have all the domain knowledge, and be indispensable, and, like, be the go-to person to answer all the questions. But now I'm at a point where I don't want to [laughs] necessarily have to answer, like, every question because that creates, like, a dependency on me. And if I need to step away from work, then that could be tough, right? The vacation factor that you mentioned. +So, this style of work is very interesting in terms of if it might provide me a little bit more of that, not exactly work-life balance, but just kind of be closer to my goals in terms of what I want out of work and my time. And, hopefully, I'm going to be doing this next week, but I don't know because that's the nature of it [laughs]. But if I am, then I'll definitely have more to say about it. Probably. +JOËL: Well, it definitely sounds like we'll have to check in again on what's, I guess, not so new in your world on a future episode. On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Stephanie recommends "Blue Eye Samurai" and a new ceramic pot (donabe) for cooking. Joël talks about the joy of holding a warm beverage in a unique mug.

+ +

Stephanie discusses her shift to a part-time support and maintenance role at thoughtbot, contrasting it with her full-time development work. She highlights the importance of communication, documentation, and workplace flexibility in this role. Stephanie appreciates the professional growth opportunities and aligns this flexible work style with her long-term career goals.

+ +
+ + + +

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: I have a TV show recommendation this week. I think this is my first time having TV or movies to recommend, so this will be fun. My partner and I just finished watching Blue Eye Samurai on Netflix, which is an animated historical Samurai drama.

+ +

But the really cool thing about it is that the protagonist she's a woman who is disguising herself as a man, and she is half Japanese and half White, which the show takes place during Edo, Japan. And so that was a time when Japan was locked down, and there were no outsiders allowed in the country. And so, to be mixed race like that was to be, like, kind of, like, demonized and to be really excluded and shamed. And so, the main character is on, like, a revenge mission.

+ +

And it was such a cool show. I was kind of, like, on the edge of my seat the whole time. And it's very beautifully animated. There were just a lot of really awesome things about it. And I think it's very different from what I've been seeing on TV these days.

+ +

JOËL: Is this a single-season show?

+ +

STEPHANIE: So far, there's just one season. I think it's pretty new, yeah. It's very watchable in a couple of weekends.

+ +

[laughter]

+ +

JOËL: Dangerously so.

+ +

STEPHANIE: Yeah, exactly [laughs].

+ +

JOËL: How do you feel about the way they end the arc in season one? Do they kind of leave you on a cliffhanger, or does it feel like a pretty satisfying place?

+ +

STEPHANIE: Ooh, I think both, which is the sweet spot, in my opinion, where it's not, like, cliffhanger for the sake of, like, ugh, now I feel like I have to just watch the next part to see what happens because I was left unsatisfied. I like when seasons are kind of like chapters of the story, right? And the characters are also well written, too, and really fleshed out even, you know, some of the side characters. They all have their arcs that are really satisfying. And, again, I just was left very impressed.

+ +

JOËL: I guess that's the power of good storytelling.

+ +

STEPHANIE: Yeah. I was reading a review of the show. And that was kind of the theme of–it was just that, like, this is really good storytelling, and I would have to agree. Yeah, I highly recommend checking it out. It was very fun. It was very bloody, but [chuckles], for me, it being animated actually made it a little more palatable for me [laughs]. The fight scenes, the action scenes were really cool.

+ +

I think the way that it's been described is kind of, like, you know, if you like historical dramas, or if you like things like Game of Thrones, there's kind of something for everyone. I recommend checking it out. Joël, what's new in your world?

+ +

JOËL: Listeners of the show don't know this, but you and I are on a video call while we're recording this. And you'd commented earlier that I was holding a cool mug. It's got a rock climbing hold as a handle, which is pretty fun. I enjoy a lot of bouldering. That makes it a fun mug.

+ +

But I was recently thinking about just how much pleasure I get from holding a mug with a warm beverage. It's such a small thing, but it makes me so happy. And that got me thinking more broadly about what are things in life that are kind of like that. They're small things that have, like, an outsized impact on your happiness. Do you have anything like that?

+ +

STEPHANIE: Oh yes, absolutely. You were talking about the warmth of a hot beverage in your hands. And I was thinking about something similar, too, because I'm pretty sure this time of year last year, I talked about something that was new in my world that was just, like, a thing that I got to make winter more tolerable for me here in Chicago, and I think it was, like, a heated blanket [laughs].

+ +

And I am similarly in that space this year of like, what can I do or get to make this winter better than last winter? So, this year, what I got that I'm really excited to use— it actually just came in the mail—is this ceramic pot called the donabe that's kind of mainly used for Japanese cooking, especially, like, hot pot. And so, it will be a huge improvement to my soup game this year [laughs].

+ +

Similarly, it's kind of, like, one of those small things where you can take it from the stovetop where you're cooking straight to the table, and I'm so looking forward to that. It's kind of like your hot beverage in your hand but, like, three times the size [laughs].

+ +

JOËL: Right. The family-style version of it.

+ +

STEPHANIE: Yeah, exactly. So, that's what I'm really looking forward to this year as something that is just, like, I don't know, a little small upgrade to my regular soup routine. But I think I will get a lot of pleasure [laughs] out of it.

+ +

JOËL: What do you normally cook in that style of pot? Is it typically you do a hot pot in there, or is it meant for soups?

+ +

STEPHANIE: Yeah, it holds heat really well, so I think that's why it's used for soup a lot. And the one that I got specifically has a little ceramic steamer plate as well. And so, I'm looking forward to having, like, this setup that's made for steaming, where you don't have to have any, like, too many extra bits. And, again, it can go from stove to table, and that's one less thing I [chuckles] need to wash.

+ +

JOËL: I love it. So, something else that is kind of new in your world is you'd mentioned on a recent episode you'd wrapped up with your current client. And you've rotated on to not exactly a new client but a new almost line of business. You're doing a rotation with our support and maintenance team. Can you tell us a little bit about what that is like?

+ +

STEPHANIE: Yeah. I'm excited to share more about it because this is my first time on this team doing this work. And it's pretty new for thoughtbot, too. I think it's only, like, a year old that we have had this sub-team of the one that you and I are on, Boost. In the sub-team, support and maintenance is focused on providing flexible part-time work for clients who are just needing some dedicated hours, not necessarily for, you know, a lot of, like, intense new feature work, but making sure that things are running smoothly.

+ +

A lot of the clients, you know, have had Rails apps that are several years old, that are chugging along [chuckles], just need that, like, attention every now and then to make sure that upgrades are happening, fix any bugs, kind of as the app just continues to work and provide value. And then, occasionally, there is a little bit of feature work.

+ +

But the interesting thing about being on this team is that instead of being on one client full-time, you are working on a lot of different clients at the same time, and a lot of them are on retainers. So, they maybe have, like, 20 hours a month of work that gets filled with kind of whatever tasks need to be done during that time. So yeah, I recently joined a few days ago and have been very surprised by kind of this style of work. It's different from what I'm used to.

+ +

JOËL: That seems pretty different than the sort of traditional thoughtbot client engagement. Typically, if I'm a client and I'm hiring a team from thoughtbot, as a client, I get sort of a dedicated team. And they're probably either building some things for me or maybe working with my team and sort of full-time building features.

+ +

Whereas if I hire the support and maintenance team, it sounds like it's a bit more ad hoc. And it's things I assume it's like, oh, we probably need to upgrade our Rails version since a new release came out last month. Can you do that? Here's a small bug that was reported. Can somebody fix that? Things along those lines. Is that pretty approximate of what the experience is for a client?

+ +

STEPHANIE: Yeah, I would say so. I think the other surprising thing has been there have been a little bit of more DevOps type of tasks as well mixed in there. Because oftentimes, these are smaller clients who maybe have, like, a few developers actively working on new features and that type of stuff. But there is, like, so much of the connecting work that needs to happen when you have an application. And if you don't have a full in-house team for that, that often gets put on developers' plates. But it's kind of nice to have this flexible support and maintenance team, again, to, like, do the work as it comes up.

+ +

A lot of it is not necessarily, like, stuff that can be planned in advance. It's kind of like, oh, we're hitting, like, our usage limit for this Heroku add-on. Let's evaluate if this is still working for us, if this is a good tier to be on. Like, should we upgrade? Are there other levers we could pull or adjustments we can make?

+ +

So, that's actually been some of the stuff that I've been working on, too, which is, again, a little bit different from normal development work but also still very much related. And it's all kind of part of the job. And, you know, a lot of the skills are transferable. And to know how to do development in a framework then sets you up, I think, really well to, like, be able to make those kinds of evaluations.

+ +

JOËL: So, it sounds like you almost, in a sense, provide a bit of a velocity cushion for clients so that if something does come up where they would maybe normally need to pull a dev off of feature work to do some side thing for a couple of days, you can come in and handle that so that their dev team stays focused on shipping features.

+ +

STEPHANIE: Yeah, I like that phrase you used: velocity cushion. That's cool. I like it. The other surprising thing that I have kind of quite enjoyed, at least for now, is because we bill a little bit differently on this work; we have to track our hours more explicitly. And that has actually helped me focus a lot more on what I'm doing and if I should continue to be doing what I'm doing. I'm timeboxing things a lot more because I know that if there is a ceiling on the number of hours, I want to make sure that that time is spent in the most valuable way.

+ +

And I also really enjoy, like, the boundaries of timeboxing, yes, but also, like, the tasks are usually scoped pretty narrowly so that they are things that you can accomplish, definitely in the week, because you don't know if you'll kind of still be working for this client next week but even more so, like, within a few days.

+ +

And that is nice because I can kind of, like, you know, track my hours, finish the task, and then feel a little bit more free to go do something else without being, like, okay, like, what's the next thing that I need to be doing? There's a little bit more freedom, I think, when you're kind of, like, optimizing towards, like, finishing each item.

+ +

JOËL: Do the stories of the work that you have to do does it typically come kind of pre-scoped? Are you involved in making sure that it has, like, very aggressive scoping?

+ +

STEPHANIE: Yeah. So far, I've not been involved in doing the scoping work, and it has come pre-scoped, which has been nice. This was also, again, just different. Because I was on a client team previously, a lot of the work to be done was the disambiguating, the, like, figuring out what to be doing. Whereas here, because, again, we're kind of optimized for people coming in and out, if there is uncertainty or lack of clarity, it's pointed out early, and someone is like, "Okay, I will take care of this. Like, I'll take the lead on this so that it can be handed off."

+ +

One client that I'm working on is using Basecamp's Shape Up methodology, which I actually hadn't worked with in a very explicit way before. And that has been interesting to learn about a little bit, too. One thing that I have enjoyed about it is instead of sprints, they're called cycles. And I like that a lot because, you know, sprints kind of have the connotation of, like, you're running as fast as you can but also, like, you can't run that way forever [laughs]. And so, even that, like, little bit of rewording change is really nice. The variable part is scope, right? It's we're focused on delivering something completely and very intentionally cutting scope as kind of the main lever.

+ +

JOËL: How do you maintain sort of focus and flow if you're jumping across multiple clients? Because you said, you work with multiple clients as part of this team. And I feel like I can get a little bit frustrated sometimes, even just jumping between, like, tickets within one project. And so, I could imagine that jumping between different clients during the week or even the day might be really disruptive. Have you found techniques to help you stay in the flow?

+ +

STEPHANIE: Yeah, that is a tough one because, also, every client has their different application; you then have to start up on [laughs] your local machine, and that is kind of annoying. You know, I do still tend to kind of, like, bundle similar work together. If, like, there's a few things I can do for a client on one day, I'll make sure to focus on that.

+ +

But what I mentioned earlier about, like, seeing something to completion has been really, I want to say, fun even. Because it then kind of, like, frees up that mental space of, like, okay, I don't have to, like, have this thing that I'm working on lingering in my head about, like, oh, did I forget to do something? Or, you know, have, like, shower thoughts of like, oh, I just thought of a new way to implement this [laughs] feature because it doesn't spill over as much as maybe larger initiatives anyway.

+ +

And so, I am context-switching, but it's only kind of after I've gotten something to a good place where I've left all of the notes. And that's another thing that I'm now kind of compelled to do a little more actively. It's like, every single day, I'm kind of making sure that the work that I've done has been reported on, one, because I have to track my hours, so, you know, and I sometimes leave notes about what that time was spent on doing.

+ +

And also, when the expectation is that someone else will be picking up, then there's no, like, oh, like, let me hold on to this, and only when I know that I have to hand off something that's when I'll do the, like, dedicated knowledge dumping. It's kind of just built into the process a little more frequently.

+ +

JOËL: So, you're setting up for, like, an imminent vacation factor.

+ +

STEPHANIE: Yeah. Which I kind of like because then I can take a vacation [laughs] whenever I want and not have to worry too much about, oh, did I do everything I needed to do before I leave?

+ +

JOËL: So, you know, these practices that you're doing are specifically adapted for the style of work that you have. Are there any that you think you would bring to your own practice if you ever rotated back on to a dedicated client project, anything that you would do there that you would want to include from your practice here?

+ +

STEPHANIE: Yeah. It does sound kind of weird because part of what's nice about being on a full-time team is that there is less, oh, if I don't get something done today, I have tomorrow to do it [laughs]. And it seems like that would be like, oh, like, kind of take the pressure off a little bit.

+ +

But I would be really curious to continue having, like, such an intense awareness about how I'm spending my time. Because I've certainly gotten a little bit lax on, like, full-time development work when you just go down a rabbit hole [laughs] and you come out, like, three hours later, and you're like, "What did I just do?" [laughs] And, you know, maybe that's what needed to be done, and that's fine.

+ +

But if you have the information that it took you three hours, you can at least make a better-informed decision about, like, oh, maybe I should have stopped a little earlier or, like, yeah, it took about three hours, and that's okay. I think that would be an interesting area to incorporate and to be able to report more frequently. And I also like to know how other people spend their time, too. So, just, like, that sharing of information would also be really beneficial even to, like, a team.

+ +

JOËL: What about the more aggressive documentation? Is that something that...because that can be really time-consuming, I imagine, as well. Is that something that you would value in a kind of, more focused full-time project context?

+ +

STEPHANIE: Yeah. One part I've enjoyed about it is that I'm documenting, like, decision-making a lot more actively where, you know, I'm kind of, like, surfacing to be like, hey, here's the outcomes of, like, my research. We're not as, you know, embedded in the business, and we don't have as much of that, like, context and knowledge about what the best solutions are all the time. I'm documenting all of that, you know, usually, for the client stakeholder to be like, "Hey, here's my recommendations, like, how do you want to...what do you think is the best way to go?

+ +

On one hand, it's kind of nice not to have to, like, be solely responsible for making that decision, right? And I'm kind of, like, leaning on, like, hey, like, you're the expert of your application and your product, you know, here's what I've learned. And now I've, like, put this all, like, for you and presented it to you.

+ +

And I think that, for me, has gotten lost sometimes when I end up being the same person of, like, doing the research and then deciding, and it just kind of ends up being held in my head. And that, I think, is something really important to document, even if it's just for other people to, like, see how that process might work or, like, what things I already considered or didn't try. That exercise, I think, can be really important.

+ +

So, so far, the documentation has not necessarily been, like, code level, but more, like, for each task, it's, like, showing your work, right? And not in a, like, you're being monitored [laughs] sort of way but in a way that supports it getting done with a lot of that turnover.

+ +

JOËL: It's almost like a mini report that you're doing. So, you'd mentioned, for example, an application running into memory problems on Heroku. It sounds like you would then go maybe investigate that and then make some recommendations on whether they need to increase some dynos or maybe make some internal changes. It sounds like you may or may not be the one to execute those changes. But you would write up some, like, a mini report and submit that to the client, and then they can make their own execution choices.

+ +

STEPHANIE: Yeah, exactly. And they can execute it themselves or then create a new ticket for the next person rotating on to support and maintenance to tackle it in a different cycle.

+ +

JOËL: So, support and maintenance doesn't just do the investigation. Your team might do the execution as well. It's just that the sort of more research-y stuff and the execution stuff gets split out into different tickets because it's so tightly scoped.

+ +

STEPHANIE: Yeah, that sounds right.

+ +

JOËL: I like that.

+ +

STEPHANIE: One area that I wasn't sure that I was going to like so much about this kind of work is, you know, when you're not kind of embedded on a team, I was thinking that I might not feel as connected, or I would miss a bit of that getting to know people and just, like, seeing people face to face on a daily basis.

+ +

I'm still evaluating how that would go so far because it has definitely been, like, mostly asynchronous communication, you know, which is what works well for this type of the style of team or project. But I think what has been helpful is realizing that, like, oh yeah, like, I can also get that elsewhere, you know, with thoughtbot folks like with you doing this podcast every week.

+ +

And right now, there are, like, two Boost members who are doing support and maintenance full time, and folks who are unbooked kind of come in and out. And I can see that there's still a team. So, it's not nearly as kind of, like, isolating as what I had thought it would be.

+ +

JOËL: There's something that's really curious to me, I think, sitting at the intersection of the idea of fostering more team interactions and the sort of, like, mini reports that you write. And that's that I would love to see more sharing among all of us at thoughtbot about different interesting problems that we've had to solve or that we're tackling on different client work. Because I think in that case, it's a situation where we all just learn something, you know, maybe I've never had to deal with a memory leak or might not even have an idea of, like, how to approach memory issues on Heroku.

+ +

So, seeing your little mini report, if you'd maybe share that, and, you know, maybe it can be anonymized in some way if needs to, I think would be really nice, at the very least, something that could be done, like, internally. So, I almost wonder if, like, building that practice of, you know, maybe not for every ticket that I do because, you know, I don't want to just be dumping my tickets in the thoughtbot Slack. But I run into something interesting and be like, oh, let me tell a little story about this and do a little write-up. That might be something that's good for the whole team and not just for folks who are on support and maintenance.

+ +

STEPHANIE: Yeah, absolutely. As you were saying that, I was thinking about how it does kind of encourage me to find support outside of my, like, immediate team, right? Because I don't necessarily have one with the client and to, I don't know, I'm imagining, like, these roots growing in terms of different communities I'm a part of and bringing those problems just outside of my internal world, and kind of getting that outside feedback because by necessity a little bit, right? But also, with the added benefit of, you know, I think that's also how a lot of people end up writing content that gets shared with the world.

+ +

So, I had the misconception that I would be kind of just, like, on my own off doing things like just tickets and being a little coding robot, but I've been surprised by it feels very fresh and new. So, I think, I guess, I was needing a little bit of that [laughs].

+ +

JOËL: I was having a conversation with another thoughtboter recently about how valuable sometimes change can be for its own sake and how that can sort of refresh. You want it just at the rate where you have a chance to build some stability. You don't want chaos. But sometimes change can sort of take you out of a rut, give you energy, maybe sort of restart some good habits that you had sort of let atrophy. And that finding, like, just that right level of shaking things up can really help a team, you know, get their effectiveness to the next level.

+ +

STEPHANIE: Yeah. I like what you said about good habits, for sure. A couple of other random, little things that I just thought of about what I've liked is, I don't know, maybe this is a little silly. But we, you know, use shared credentials for logging into different services and applications or third parties that clients are using. And that has actually been something that has been so easy [laughs] and very low friction compared to, you know, joining a new project and manually be added as, like, your individual account to all of the different things. And things inevitably get forgotten, and then you have to rely on someone else to do it. And sometimes they don't get back to you [laughs] for a while.

+ +

The self-serviceness of this work has been cool, too. And I just, yeah, wanted to say that I really appreciated the thought that went into making it as easy as possible to be like, yeah, I can find the credentials here. It is, you know, a bit more anonymized because I'm just using, like, a shared account.

+ +

JOËL: Like a generic thoughtbot account on a client system rather than stephanie@thoughtbot.

+ +

STEPHANIE: Yeah, exactly. But I think I saved so much time [laughs] this week just being able to do all of that myself and, you know, knowing where to look first before having to ask.

+ +

JOËL: I guess you'd need something like that, right? If you're only jumping in on a project for the first time, for a couple of hours or something like that, you don't want to go through a whole onboarding process because that might then, like, easily double. You know, instead of doing two hours on this project, you're now doing four.

+ +

STEPHANIE: Yeah, exactly. I guess the other takeaway, for me, was like, oh, definitely, if I were to have to set up accounts [laughs] for an application, you know, I've obviously seen where it was like, very clearly, like, the founder having created all these personal accounts for this services, and people are still using their credentials many years later [laughs], even though they probably, like, maybe may not even work for the company anymore.

+ +

But yeah, the shared credentials and using that generic account that anyone can kind of get into when needed has really lowered the barrier to jump into doing that work, right? And especially because, like you said, it reduces that time. And we're, you know, billing by the hour anyway. So, it's kind of a win-win situation.

+ +

JOËL: And I totally understand why you would not want something like that for a longer engagement. But for something like support and maintenance, it sounds like it was the right choice.

+ +

STEPHANIE: Yeah, yeah. Again, I just mentioned it because it's just different. And so, maybe if this sparks any ideas for our listeners about how processes could be different or, like, the styles or ways of working can be different, I think that would be cool.

+ +

JOËL: And just to be clear here, it sounds like what you're doing is for sort of each client; you create a separate set of credentials that are for that client but that are about thoughtbot generically. You don't have, like, one thoughtbot email and password that we reuse for every client.

+ +

STEPHANIE: [laughs] Oh yes. That would be not so good [laughs] if we got hacked and suddenly, now they have access to everything.

+ +

JOËL: So, every client gets its own unique email password combo. We're using security best practices here. And then, since you do have to share them through a team, are you doing some sort of, like, shared 1Password vault or something along those lines?

+ +

STEPHANIE: Yeah, we are using a shared 1Password vault. That is definitely what I meant [laughs] the first time when I was mentioning the shared credentials, where that was basically the only thing I had to get onboarded to, the vault, for support and maintenance to be able to hit the ground running.

+ +

JOËL: So, this sounds like a pretty exciting new style of project for you. Is this something that you would see yourself preferring to do longer term, to sort of focus on this style of project? Or do you think that you'd like to come back to more classic project work in the near future?

+ +

STEPHANIE: I'm not sure yet, but I'm also hoping to have an answer to that question. And it definitely does feel like an experiment for me personally. I can see liking it, and that also fitting well with some of my longer-term goals of being able to, like, step back from work. Maybe working fewer days a week is something that I've, like, thought about in terms of, like, a long-term goal of mine because I'm not as needed [laughs] on a team.

+ +

Which I think, in the past, I also had a bit of a misconception that, like, in order to be a good developer, I had to have all the domain knowledge, and be indispensable, and, like, be the go-to person to answer all the questions. But now I'm at a point where I don't want to [laughs] necessarily have to answer, like, every question because that creates, like, a dependency on me. And if I need to step away from work, then that could be tough, right? The vacation factor that you mentioned.

+ +

So, this style of work is very interesting in terms of if it might provide me a little bit more of that, not exactly work-life balance, but just kind of be closer to my goals in terms of what I want out of work and my time. And, hopefully, I'm going to be doing this next week, but I don't know because that's the nature of it [laughs]. But if I am, then I'll definitely have more to say about it. Probably.

+ +

JOËL: Well, it definitely sounds like we'll have to check in again on what's, I guess, not so new in your world on a future episode. On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie recommends "Blue Eye Samurai" and a new ceramic pot (donabe) for cooking. Joël talks about the joy of holding a warm beverage in a unique mug.

+ +

Stephanie discusses her shift to a part-time support and maintenance role at thoughtbot, contrasting it with her full-time development work. She highlights the importance of communication, documentation, and workplace flexibility in this role. Stephanie appreciates the professional growth opportunities and aligns this flexible work style with her long-term career goals.

+ +
+ + + +

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: I have a TV show recommendation this week. I think this is my first time having TV or movies to recommend, so this will be fun. My partner and I just finished watching Blue Eye Samurai on Netflix, which is an animated historical Samurai drama.

+ +

But the really cool thing about it is that the protagonist she's a woman who is disguising herself as a man, and she is half Japanese and half White, which the show takes place during Edo, Japan. And so that was a time when Japan was locked down, and there were no outsiders allowed in the country. And so, to be mixed race like that was to be, like, kind of, like, demonized and to be really excluded and shamed. And so, the main character is on, like, a revenge mission.

+ +

And it was such a cool show. I was kind of, like, on the edge of my seat the whole time. And it's very beautifully animated. There were just a lot of really awesome things about it. And I think it's very different from what I've been seeing on TV these days.

+ +

JOËL: Is this a single-season show?

+ +

STEPHANIE: So far, there's just one season. I think it's pretty new, yeah. It's very watchable in a couple of weekends.

+ +

[laughter]

+ +

JOËL: Dangerously so.

+ +

STEPHANIE: Yeah, exactly [laughs].

+ +

JOËL: How do you feel about the way they end the arc in season one? Do they kind of leave you on a cliffhanger, or does it feel like a pretty satisfying place?

+ +

STEPHANIE: Ooh, I think both, which is the sweet spot, in my opinion, where it's not, like, cliffhanger for the sake of, like, ugh, now I feel like I have to just watch the next part to see what happens because I was left unsatisfied. I like when seasons are kind of like chapters of the story, right? And the characters are also well written, too, and really fleshed out even, you know, some of the side characters. They all have their arcs that are really satisfying. And, again, I just was left very impressed.

+ +

JOËL: I guess that's the power of good storytelling.

+ +

STEPHANIE: Yeah. I was reading a review of the show. And that was kind of the theme of–it was just that, like, this is really good storytelling, and I would have to agree. Yeah, I highly recommend checking it out. It was very fun. It was very bloody, but [chuckles], for me, it being animated actually made it a little more palatable for me [laughs]. The fight scenes, the action scenes were really cool.

+ +

I think the way that it's been described is kind of, like, you know, if you like historical dramas, or if you like things like Game of Thrones, there's kind of something for everyone. I recommend checking it out. Joël, what's new in your world?

+ +

JOËL: Listeners of the show don't know this, but you and I are on a video call while we're recording this. And you'd commented earlier that I was holding a cool mug. It's got a rock climbing hold as a handle, which is pretty fun. I enjoy a lot of bouldering. That makes it a fun mug.

+ +

But I was recently thinking about just how much pleasure I get from holding a mug with a warm beverage. It's such a small thing, but it makes me so happy. And that got me thinking more broadly about what are things in life that are kind of like that. They're small things that have, like, an outsized impact on your happiness. Do you have anything like that?

+ +

STEPHANIE: Oh yes, absolutely. You were talking about the warmth of a hot beverage in your hands. And I was thinking about something similar, too, because I'm pretty sure this time of year last year, I talked about something that was new in my world that was just, like, a thing that I got to make winter more tolerable for me here in Chicago, and I think it was, like, a heated blanket [laughs].

+ +

And I am similarly in that space this year of like, what can I do or get to make this winter better than last winter? So, this year, what I got that I'm really excited to use— it actually just came in the mail—is this ceramic pot called the donabe that's kind of mainly used for Japanese cooking, especially, like, hot pot. And so, it will be a huge improvement to my soup game this year [laughs].

+ +

Similarly, it's kind of, like, one of those small things where you can take it from the stovetop where you're cooking straight to the table, and I'm so looking forward to that. It's kind of like your hot beverage in your hand but, like, three times the size [laughs].

+ +

JOËL: Right. The family-style version of it.

+ +

STEPHANIE: Yeah, exactly. So, that's what I'm really looking forward to this year as something that is just, like, I don't know, a little small upgrade to my regular soup routine. But I think I will get a lot of pleasure [laughs] out of it.

+ +

JOËL: What do you normally cook in that style of pot? Is it typically you do a hot pot in there, or is it meant for soups?

+ +

STEPHANIE: Yeah, it holds heat really well, so I think that's why it's used for soup a lot. And the one that I got specifically has a little ceramic steamer plate as well. And so, I'm looking forward to having, like, this setup that's made for steaming, where you don't have to have any, like, too many extra bits. And, again, it can go from stove to table, and that's one less thing I [chuckles] need to wash.

+ +

JOËL: I love it. So, something else that is kind of new in your world is you'd mentioned on a recent episode you'd wrapped up with your current client. And you've rotated on to not exactly a new client but a new almost line of business. You're doing a rotation with our support and maintenance team. Can you tell us a little bit about what that is like?

+ +

STEPHANIE: Yeah. I'm excited to share more about it because this is my first time on this team doing this work. And it's pretty new for thoughtbot, too. I think it's only, like, a year old that we have had this sub-team of the one that you and I are on, Boost. In the sub-team, support and maintenance is focused on providing flexible part-time work for clients who are just needing some dedicated hours, not necessarily for, you know, a lot of, like, intense new feature work, but making sure that things are running smoothly.

+ +

A lot of the clients, you know, have had Rails apps that are several years old, that are chugging along [chuckles], just need that, like, attention every now and then to make sure that upgrades are happening, fix any bugs, kind of as the app just continues to work and provide value. And then, occasionally, there is a little bit of feature work.

+ +

But the interesting thing about being on this team is that instead of being on one client full-time, you are working on a lot of different clients at the same time, and a lot of them are on retainers. So, they maybe have, like, 20 hours a month of work that gets filled with kind of whatever tasks need to be done during that time. So yeah, I recently joined a few days ago and have been very surprised by kind of this style of work. It's different from what I'm used to.

+ +

JOËL: That seems pretty different than the sort of traditional thoughtbot client engagement. Typically, if I'm a client and I'm hiring a team from thoughtbot, as a client, I get sort of a dedicated team. And they're probably either building some things for me or maybe working with my team and sort of full-time building features.

+ +

Whereas if I hire the support and maintenance team, it sounds like it's a bit more ad hoc. And it's things I assume it's like, oh, we probably need to upgrade our Rails version since a new release came out last month. Can you do that? Here's a small bug that was reported. Can somebody fix that? Things along those lines. Is that pretty approximate of what the experience is for a client?

+ +

STEPHANIE: Yeah, I would say so. I think the other surprising thing has been there have been a little bit of more DevOps type of tasks as well mixed in there. Because oftentimes, these are smaller clients who maybe have, like, a few developers actively working on new features and that type of stuff. But there is, like, so much of the connecting work that needs to happen when you have an application. And if you don't have a full in-house team for that, that often gets put on developers' plates. But it's kind of nice to have this flexible support and maintenance team, again, to, like, do the work as it comes up.

+ +

A lot of it is not necessarily, like, stuff that can be planned in advance. It's kind of like, oh, we're hitting, like, our usage limit for this Heroku add-on. Let's evaluate if this is still working for us, if this is a good tier to be on. Like, should we upgrade? Are there other levers we could pull or adjustments we can make?

+ +

So, that's actually been some of the stuff that I've been working on, too, which is, again, a little bit different from normal development work but also still very much related. And it's all kind of part of the job. And, you know, a lot of the skills are transferable. And to know how to do development in a framework then sets you up, I think, really well to, like, be able to make those kinds of evaluations.

+ +

JOËL: So, it sounds like you almost, in a sense, provide a bit of a velocity cushion for clients so that if something does come up where they would maybe normally need to pull a dev off of feature work to do some side thing for a couple of days, you can come in and handle that so that their dev team stays focused on shipping features.

+ +

STEPHANIE: Yeah, I like that phrase you used: velocity cushion. That's cool. I like it. The other surprising thing that I have kind of quite enjoyed, at least for now, is because we bill a little bit differently on this work; we have to track our hours more explicitly. And that has actually helped me focus a lot more on what I'm doing and if I should continue to be doing what I'm doing. I'm timeboxing things a lot more because I know that if there is a ceiling on the number of hours, I want to make sure that that time is spent in the most valuable way.

+ +

And I also really enjoy, like, the boundaries of timeboxing, yes, but also, like, the tasks are usually scoped pretty narrowly so that they are things that you can accomplish, definitely in the week, because you don't know if you'll kind of still be working for this client next week but even more so, like, within a few days.

+ +

And that is nice because I can kind of, like, you know, track my hours, finish the task, and then feel a little bit more free to go do something else without being, like, okay, like, what's the next thing that I need to be doing? There's a little bit more freedom, I think, when you're kind of, like, optimizing towards, like, finishing each item.

+ +

JOËL: Do the stories of the work that you have to do does it typically come kind of pre-scoped? Are you involved in making sure that it has, like, very aggressive scoping?

+ +

STEPHANIE: Yeah. So far, I've not been involved in doing the scoping work, and it has come pre-scoped, which has been nice. This was also, again, just different. Because I was on a client team previously, a lot of the work to be done was the disambiguating, the, like, figuring out what to be doing. Whereas here, because, again, we're kind of optimized for people coming in and out, if there is uncertainty or lack of clarity, it's pointed out early, and someone is like, "Okay, I will take care of this. Like, I'll take the lead on this so that it can be handed off."

+ +

One client that I'm working on is using Basecamp's Shape Up methodology, which I actually hadn't worked with in a very explicit way before. And that has been interesting to learn about a little bit, too. One thing that I have enjoyed about it is instead of sprints, they're called cycles. And I like that a lot because, you know, sprints kind of have the connotation of, like, you're running as fast as you can but also, like, you can't run that way forever [laughs]. And so, even that, like, little bit of rewording change is really nice. The variable part is scope, right? It's we're focused on delivering something completely and very intentionally cutting scope as kind of the main lever.

+ +

JOËL: How do you maintain sort of focus and flow if you're jumping across multiple clients? Because you said, you work with multiple clients as part of this team. And I feel like I can get a little bit frustrated sometimes, even just jumping between, like, tickets within one project. And so, I could imagine that jumping between different clients during the week or even the day might be really disruptive. Have you found techniques to help you stay in the flow?

+ +

STEPHANIE: Yeah, that is a tough one because, also, every client has their different application; you then have to start up on [laughs] your local machine, and that is kind of annoying. You know, I do still tend to kind of, like, bundle similar work together. If, like, there's a few things I can do for a client on one day, I'll make sure to focus on that.

+ +

But what I mentioned earlier about, like, seeing something to completion has been really, I want to say, fun even. Because it then kind of, like, frees up that mental space of, like, okay, I don't have to, like, have this thing that I'm working on lingering in my head about, like, oh, did I forget to do something? Or, you know, have, like, shower thoughts of like, oh, I just thought of a new way to implement this [laughs] feature because it doesn't spill over as much as maybe larger initiatives anyway.

+ +

And so, I am context-switching, but it's only kind of after I've gotten something to a good place where I've left all of the notes. And that's another thing that I'm now kind of compelled to do a little more actively. It's like, every single day, I'm kind of making sure that the work that I've done has been reported on, one, because I have to track my hours, so, you know, and I sometimes leave notes about what that time was spent on doing.

+ +

And also, when the expectation is that someone else will be picking up, then there's no, like, oh, like, let me hold on to this, and only when I know that I have to hand off something that's when I'll do the, like, dedicated knowledge dumping. It's kind of just built into the process a little more frequently.

+ +

JOËL: So, you're setting up for, like, an imminent vacation factor.

+ +

STEPHANIE: Yeah. Which I kind of like because then I can take a vacation [laughs] whenever I want and not have to worry too much about, oh, did I do everything I needed to do before I leave?

+ +

JOËL: So, you know, these practices that you're doing are specifically adapted for the style of work that you have. Are there any that you think you would bring to your own practice if you ever rotated back on to a dedicated client project, anything that you would do there that you would want to include from your practice here?

+ +

STEPHANIE: Yeah. It does sound kind of weird because part of what's nice about being on a full-time team is that there is less, oh, if I don't get something done today, I have tomorrow to do it [laughs]. And it seems like that would be like, oh, like, kind of take the pressure off a little bit.

+ +

But I would be really curious to continue having, like, such an intense awareness about how I'm spending my time. Because I've certainly gotten a little bit lax on, like, full-time development work when you just go down a rabbit hole [laughs] and you come out, like, three hours later, and you're like, "What did I just do?" [laughs] And, you know, maybe that's what needed to be done, and that's fine.

+ +

But if you have the information that it took you three hours, you can at least make a better-informed decision about, like, oh, maybe I should have stopped a little earlier or, like, yeah, it took about three hours, and that's okay. I think that would be an interesting area to incorporate and to be able to report more frequently. And I also like to know how other people spend their time, too. So, just, like, that sharing of information would also be really beneficial even to, like, a team.

+ +

JOËL: What about the more aggressive documentation? Is that something that...because that can be really time-consuming, I imagine, as well. Is that something that you would value in a kind of, more focused full-time project context?

+ +

STEPHANIE: Yeah. One part I've enjoyed about it is that I'm documenting, like, decision-making a lot more actively where, you know, I'm kind of, like, surfacing to be like, hey, here's the outcomes of, like, my research. We're not as, you know, embedded in the business, and we don't have as much of that, like, context and knowledge about what the best solutions are all the time. I'm documenting all of that, you know, usually, for the client stakeholder to be like, "Hey, here's my recommendations, like, how do you want to...what do you think is the best way to go?

+ +

On one hand, it's kind of nice not to have to, like, be solely responsible for making that decision, right? And I'm kind of, like, leaning on, like, hey, like, you're the expert of your application and your product, you know, here's what I've learned. And now I've, like, put this all, like, for you and presented it to you.

+ +

And I think that, for me, has gotten lost sometimes when I end up being the same person of, like, doing the research and then deciding, and it just kind of ends up being held in my head. And that, I think, is something really important to document, even if it's just for other people to, like, see how that process might work or, like, what things I already considered or didn't try. That exercise, I think, can be really important.

+ +

So, so far, the documentation has not necessarily been, like, code level, but more, like, for each task, it's, like, showing your work, right? And not in a, like, you're being monitored [laughs] sort of way but in a way that supports it getting done with a lot of that turnover.

+ +

JOËL: It's almost like a mini report that you're doing. So, you'd mentioned, for example, an application running into memory problems on Heroku. It sounds like you would then go maybe investigate that and then make some recommendations on whether they need to increase some dynos or maybe make some internal changes. It sounds like you may or may not be the one to execute those changes. But you would write up some, like, a mini report and submit that to the client, and then they can make their own execution choices.

+ +

STEPHANIE: Yeah, exactly. And they can execute it themselves or then create a new ticket for the next person rotating on to support and maintenance to tackle it in a different cycle.

+ +

JOËL: So, support and maintenance doesn't just do the investigation. Your team might do the execution as well. It's just that the sort of more research-y stuff and the execution stuff gets split out into different tickets because it's so tightly scoped.

+ +

STEPHANIE: Yeah, that sounds right.

+ +

JOËL: I like that.

+ +

STEPHANIE: One area that I wasn't sure that I was going to like so much about this kind of work is, you know, when you're not kind of embedded on a team, I was thinking that I might not feel as connected, or I would miss a bit of that getting to know people and just, like, seeing people face to face on a daily basis.

+ +

I'm still evaluating how that would go so far because it has definitely been, like, mostly asynchronous communication, you know, which is what works well for this type of the style of team or project. But I think what has been helpful is realizing that, like, oh yeah, like, I can also get that elsewhere, you know, with thoughtbot folks like with you doing this podcast every week.

+ +

And right now, there are, like, two Boost members who are doing support and maintenance full time, and folks who are unbooked kind of come in and out. And I can see that there's still a team. So, it's not nearly as kind of, like, isolating as what I had thought it would be.

+ +

JOËL: There's something that's really curious to me, I think, sitting at the intersection of the idea of fostering more team interactions and the sort of, like, mini reports that you write. And that's that I would love to see more sharing among all of us at thoughtbot about different interesting problems that we've had to solve or that we're tackling on different client work. Because I think in that case, it's a situation where we all just learn something, you know, maybe I've never had to deal with a memory leak or might not even have an idea of, like, how to approach memory issues on Heroku.

+ +

So, seeing your little mini report, if you'd maybe share that, and, you know, maybe it can be anonymized in some way if needs to, I think would be really nice, at the very least, something that could be done, like, internally. So, I almost wonder if, like, building that practice of, you know, maybe not for every ticket that I do because, you know, I don't want to just be dumping my tickets in the thoughtbot Slack. But I run into something interesting and be like, oh, let me tell a little story about this and do a little write-up. That might be something that's good for the whole team and not just for folks who are on support and maintenance.

+ +

STEPHANIE: Yeah, absolutely. As you were saying that, I was thinking about how it does kind of encourage me to find support outside of my, like, immediate team, right? Because I don't necessarily have one with the client and to, I don't know, I'm imagining, like, these roots growing in terms of different communities I'm a part of and bringing those problems just outside of my internal world, and kind of getting that outside feedback because by necessity a little bit, right? But also, with the added benefit of, you know, I think that's also how a lot of people end up writing content that gets shared with the world.

+ +

So, I had the misconception that I would be kind of just, like, on my own off doing things like just tickets and being a little coding robot, but I've been surprised by it feels very fresh and new. So, I think, I guess, I was needing a little bit of that [laughs].

+ +

JOËL: I was having a conversation with another thoughtboter recently about how valuable sometimes change can be for its own sake and how that can sort of refresh. You want it just at the rate where you have a chance to build some stability. You don't want chaos. But sometimes change can sort of take you out of a rut, give you energy, maybe sort of restart some good habits that you had sort of let atrophy. And that finding, like, just that right level of shaking things up can really help a team, you know, get their effectiveness to the next level.

+ +

STEPHANIE: Yeah. I like what you said about good habits, for sure. A couple of other random, little things that I just thought of about what I've liked is, I don't know, maybe this is a little silly. But we, you know, use shared credentials for logging into different services and applications or third parties that clients are using. And that has actually been something that has been so easy [laughs] and very low friction compared to, you know, joining a new project and manually be added as, like, your individual account to all of the different things. And things inevitably get forgotten, and then you have to rely on someone else to do it. And sometimes they don't get back to you [laughs] for a while.

+ +

The self-serviceness of this work has been cool, too. And I just, yeah, wanted to say that I really appreciated the thought that went into making it as easy as possible to be like, yeah, I can find the credentials here. It is, you know, a bit more anonymized because I'm just using, like, a shared account.

+ +

JOËL: Like a generic thoughtbot account on a client system rather than stephanie@thoughtbot.

+ +

STEPHANIE: Yeah, exactly. But I think I saved so much time [laughs] this week just being able to do all of that myself and, you know, knowing where to look first before having to ask.

+ +

JOËL: I guess you'd need something like that, right? If you're only jumping in on a project for the first time, for a couple of hours or something like that, you don't want to go through a whole onboarding process because that might then, like, easily double. You know, instead of doing two hours on this project, you're now doing four.

+ +

STEPHANIE: Yeah, exactly. I guess the other takeaway, for me, was like, oh, definitely, if I were to have to set up accounts [laughs] for an application, you know, I've obviously seen where it was like, very clearly, like, the founder having created all these personal accounts for this services, and people are still using their credentials many years later [laughs], even though they probably, like, maybe may not even work for the company anymore.

+ +

But yeah, the shared credentials and using that generic account that anyone can kind of get into when needed has really lowered the barrier to jump into doing that work, right? And especially because, like you said, it reduces that time. And we're, you know, billing by the hour anyway. So, it's kind of a win-win situation.

+ +

JOËL: And I totally understand why you would not want something like that for a longer engagement. But for something like support and maintenance, it sounds like it was the right choice.

+ +

STEPHANIE: Yeah, yeah. Again, I just mentioned it because it's just different. And so, maybe if this sparks any ideas for our listeners about how processes could be different or, like, the styles or ways of working can be different, I think that would be cool.

+ +

JOËL: And just to be clear here, it sounds like what you're doing is for sort of each client; you create a separate set of credentials that are for that client but that are about thoughtbot generically. You don't have, like, one thoughtbot email and password that we reuse for every client.

+ +

STEPHANIE: [laughs] Oh yes. That would be not so good [laughs] if we got hacked and suddenly, now they have access to everything.

+ +

JOËL: So, every client gets its own unique email password combo. We're using security best practices here. And then, since you do have to share them through a team, are you doing some sort of, like, shared 1Password vault or something along those lines?

+ +

STEPHANIE: Yeah, we are using a shared 1Password vault. That is definitely what I meant [laughs] the first time when I was mentioning the shared credentials, where that was basically the only thing I had to get onboarded to, the vault, for support and maintenance to be able to hit the ground running.

+ +

JOËL: So, this sounds like a pretty exciting new style of project for you. Is this something that you would see yourself preferring to do longer term, to sort of focus on this style of project? Or do you think that you'd like to come back to more classic project work in the near future?

+ +

STEPHANIE: I'm not sure yet, but I'm also hoping to have an answer to that question. And it definitely does feel like an experiment for me personally. I can see liking it, and that also fitting well with some of my longer-term goals of being able to, like, step back from work. Maybe working fewer days a week is something that I've, like, thought about in terms of, like, a long-term goal of mine because I'm not as needed [laughs] on a team.

+ +

Which I think, in the past, I also had a bit of a misconception that, like, in order to be a good developer, I had to have all the domain knowledge, and be indispensable, and, like, be the go-to person to answer all the questions. But now I'm at a point where I don't want to [laughs] necessarily have to answer, like, every question because that creates, like, a dependency on me. And if I need to step away from work, then that could be tough, right? The vacation factor that you mentioned.

+ +

So, this style of work is very interesting in terms of if it might provide me a little bit more of that, not exactly work-life balance, but just kind of be closer to my goals in terms of what I want out of work and my time. And, hopefully, I'm going to be doing this next week, but I don't know because that's the nature of it [laughs]. But if I am, then I'll definitely have more to say about it. Probably.

+ +

JOËL: Well, it definitely sounds like we'll have to check in again on what's, I guess, not so new in your world on a future episode. On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MDeeZK3A + + ]]> + + Joël Quenneville + Stephanie Minn + + + 408: Work Device Management + https://bikeshed.thoughtbot.com/408 + bc108cbe-0dd2-4fa6-833e-a57f95869cbc + Tue, 28 Nov 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël recaps his time at RubyConf! He shares insights from his talk about different aspects of time in software development, emphasizing the interaction with the audience and the importance of post-talk discussions. Stephanie talks about wrapping up a long-term client project, the benefits of change and variety in consulting, and maintaining a balance between project engagement and avoiding burnout. + +They also discuss strategies for maintaining work-life balance, such as physical separation and device management, particularly in a remote work environment. + 32:57 + no + + + Joël recaps his time at RubyConf! He shares insights from his talk about different aspects of time in software development, emphasizing the interaction with the audience and the importance of post-talk discussions. Stephanie talks about wrapping up a long-term client project, the benefits of change and variety in consulting, and maintaining a balance between project engagement and avoiding burnout. +They also discuss strategies for maintaining work-life balance, such as physical separation and device management, particularly in a remote work environment. +Rubyconf (https://rubyconf.org/) +Joël’s talk slides (https://speakerdeck.com/joelq/which-time-is-it) +Flaky test summary slide (https://speakerdeck.com/aridlehoover/the-secret-ingredient-how-to-understand-and-resolve-just-about-any-flaky-test?slide=170) +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: Well, as of this recording, I have just gotten back from spending the week in San Diego for RubyConf. +STEPHANIE: Yay, so fun. +JOËL: It's always so much fun to connect with the community over there, talk to other people from different companies who work in Ruby, to be inspired by the talks. This year, I was speaking, so I gave a talk on time and how it's not a single thing but multiple different quantities. In particular, I distinguish between a moment in time like a point, a duration and amount of time, and then a time of day, which is time unconnected to a particular day, and how those all connect together in the software that we write. +STEPHANIE: Awesome. How did it go? How was it received? +JOËL: It was very well received. I got a lot of people come up to me afterwards and make a variety of time puns, which those are so easy to make. I had to hold myself back not to put too many in the talk itself. I think I kept it pretty clean. There were definitely a couple of time puns in the description of the talk, though. +STEPHANIE: Yeah, absolutely. You have to keep some in there. But I hear you that you don't want it to become too punny [laughs]. What I really love about conferences, and we've talked a little bit about this before, is the, you know, like, engagement and being able to connect with people. And you give a talk, but then that ends up leading to a lot of, like, discussions about it and related topics afterwards in the hallway or sitting together over a meal. +JOËL: I like to, in my talks, give little kind of hooks for people who want to have those conversations in the hallway. You know, sometimes it's intimidating to just go up to a speaker and be like, oh, I want to, like, dig into their talk a little bit. But I don't have anything to say other than just, like, "I liked your talk." So, if there's any sort of side trails I had to cut for the talk, I might give a shout-out to it and say, "Hey, if you want to learn more about this aspect, come talk to me afterwards." +So, one thing that I put in this particular talk was like, "Hey, we're looking at these different graphical ways to think about time. These are similar to but not the same as thinking of time as a one-dimensional vector and applying vector math to it, which is a whole other side topic. If you want to nerd out about that, come find me in the hallway afterwards, and I'd love to go deeper on it." And yeah, some people did. +STEPHANIE: That's really smart. I like that a lot. You're inviting more conversation about it, which I know, like, you also really enjoy just, like, taking it further or, like, caring about other people's experiences or their thoughts about vector math [laughs]. +JOËL: I think it serves two purposes, right? It allows people to connect with me as a speaker. And it also allows me to feel better about pruning certain parts of my talk and saying, look, this didn't make sense to keep in the talk, but it's cool material. I'd love to have a continuing conversation about this. So, here's a path we could have taken. I'm choosing not to, as a speaker, but if you want to take that branch with me, let's have that afterwards in the hallway. +STEPHANIE: Yeah. Or even as, like, new content for yourself or for someone else to take with them if they want to explore that further because, you know, there's always something more to explore [chuckles]. +JOËL: I've absolutely done that with past talks. I've taken a thing I had to prune and turned it into a blog post. A recent example of that was when I gave a talk at RailsConf Portland, which I guess is not so recent. I was talking about ways to deal with a test suite that's making too many database requests. And talking about how sometimes misusing let in your RSpec tests can lead to more database requests than you expect. +And I had a whole section about how to better understand what database requests will actually be made by a series of let expressions and dealing with the eager versus lazy and all of that. I had to cut it. But I was then able to make a blog post about it and then talk about this really cool technique involving dependency graphs. And that was really fun. So, that was a thing where I was able to say, look, here's some content that didn't make it into the talk because I needed to focus on other things. But as its own little, like, side piece of content, it absolutely works, and here's a blog post. +STEPHANIE: Yeah. And then I think it turned into a Bike Shed episode, too [laughs]. +JOËL: I think it did, yes. I think, in many ways, creativity begets creativity. It's hard to get started writing or producing content or whatever, but once you do, every idea you have kind of spawns new ideas. And then, pretty soon, you have a backlog that you can't go through. +STEPHANIE: That's awesome. Any other highlights from the conference you want to shout out? +JOËL: I'd love to give a shout-out to a couple of talks that I went to, Aji Slater's talk on the Enigma machine as a German code machine from World War II and how we can sort of implement our own in Ruby and an exploration of object-oriented programming was fantastic. Aji is just a masterful storyteller. So, that was really great. +And then Alan Ridlehoover's talk on dealing with flaky tests that one, I think, was particularly useful because I think it's one of the talks that is going to be immediately relevant on Monday morning for, like, every developer that was in that room and is going back to their regular day job. And they can immediately use all of those principles that Alan talked about to deal with the flaky tests in their test suite. +And there's, in particular, at the end of his presentation, Alan has this summary slide. He kind of broke down flakiness across three different categories and then talked about different strategies for identifying and then fixing tests that were flaky because of those reasons. +And he has this table where he sort of summarizes basically the entire talk. And I feel like that's the kind of thing that I'm going to save as a cheat sheet. And that can be, like, I'm going to link to this and share it all over because it's really useful. Alan has already put his slides up online. It's all linked to that particular slide in the show notes because I think that all of you would benefit from seeing that. +The talks themselves are recorded, but they're not going to be out for a couple of weeks. I'm sure when they do, we're going to go through and watch some and probably comment on some of the talks as well. +So, Stephanie, what is new in your world? +STEPHANIE: Yeah. So, I'm celebrating wrapping up a client project after a nine-month engagement. +JOËL: Whoa, that's a pretty long project. +STEPHANIE: Yeah, that's definitely on the longer side for thoughtbot. And I'm, I don't know, just, like, feeling really excited for a change, feeling really, you know, proud of kind of, like, all of the work that we had done. You know, we had been working with this client for a long time and had been, you know, continuing to deliver value to them to want to keep working with us for that long. But I'm, yeah, just looking forward to a refresh. +And I think that's one of my favorite things about consulting is that, you know, you can inject something new into your work life at a kind of regular cadence. And, at least for me, that's really important in reducing or, like, preventing the burnout. So, this time around, I kind of started to notice, and other people, too, like my manager, that I was maybe losing a bit of steam on this client project because I had been working on it for so long. +And part of, you know, what success at thoughtbot means is that, like, we as employees are also feeling fulfilled, right? And, you know, what are the different ways that we can try to make sure that that remains the case? And kind of rotating folks on different projects and kind of making sure that things do feel fresh and exciting is really important. +And so, I feel very grateful that other people were able to point that out for me, too, when I wasn't even fully realizing it. You know, I had people checking in on me and being like, "Hey, like, you've been on this for a while now. Kind of what I've been hearing is that, like, maybe you do need something new." I'm just excited to get that change. +JOËL: How do you find the balance between sort of feeling fulfilled and maybe, you know, finding that point where maybe you're feeling you're running out of steam–versus, you know, some projects are really complex, take a while to ramp up; you want to feel productive; you want to feel like you have contributed in a significant way to a project? How do you navigate that balance? +STEPHANIE: Yeah. So, the flip side is, like, I also don't think I would enjoy having to be changing projects all the time like every couple of months. That maybe is a little too much for me because I do like to...on our team, Boost, we embed on our team. We get to know our teammates. We are, like, building relationships with them, and supporting them, and teaching them. And all of that is really also fulfilling for me, but you can't really do that as much if you're on more shorter-term engagements. +And then all of that, like, becomes worthwhile once you're kind of in that, like, maybe four or five six month period where you're like, you've finally gotten your groove. And you're like, I'm contributing. I know how this team works. I can start to see patterns or, like, maybe opportunities or gaps. And that is all really cool, and I think also another part of what I really like about being on Boost. +But yeah, I think what I...that losing steam feeling, I started to identify, like, I didn't have as much energy or excitement to push forward change. When you kind of get a little bit too comfortable or start to get that feeling of, well, these things are the way they are [laughs], -- +JOËL: Right. Right. +STEPHANIE: I've now identified that that is kind of, like, a signal, right? +JOËL: Maybe time for a new project. +STEPHANIE: Right. Like starting to feel a little bit less motivated or, like, less excited to push myself and push the team a little bit in areas that it needs to be pushed. And so, that might be a good time for someone else at thoughtbot to, like, rotate in or maybe kind of close the chapter on what we've been able to do for a client. +JOËL: It's hard to be at 100% all the time and sort of always have that motivation to push things to the max, and yeah, variety definitely helps with that. How do you feel about finding signals that maybe you need a break, maybe not from the project but just in general? The idea of taking PTO or having kind of a rest day. +STEPHANIE: Oh yeah. I, this year, have tried out taking time off but not going anywhere just, like, being at home but being on vacation. And that was really great because then it was kind of, like, less about, like, oh, I want to take this trip in this time of year to this place and more like, oh, I need some rest or, like, I just need a little break. And that can be at home, right? Maybe during the day, I'm able to do stuff that I keep putting off or trying out new things that I just can't seem to find the time to do [chuckles] during my normal work schedule. So, that has been fun. +JOËL: I think, yeah, sometimes, for me, I will sort of hit that moment where I feel like I don't have the ability to give 100%. And sometimes that can be a signal to be like, hey, have you taken any time off recently? Maybe you should schedule something. Because being able to refresh, even short-term, can sort of give an extra boost of energy in a way where...maybe it's not time for a rotation yet, but just taking a little bit of a break in there can sort of, I guess, extend the time where I feel like I'm contributing at the level that I want to be. +STEPHANIE: Yeah. And I actually want to point out that a lot of that can also be, like, investing in your life outside of work, too, so that you can come to work with a different approach. I've mentioned the month that I spent in the Hudson Valley in New York and, like, when I was there, I felt, like, so different. I was, you know, just, like, so much more excited about all the, like, novel things that I was experiencing that I could show up to work and be like, oh yeah, like, I'm feeling good today. So, I have all this, you know, energy to bring to the tasks that I have at work. +And yeah, so even though it wasn't necessarily time off, it was investing in other things in my life that then brought that refresh at work, even though nothing at work really changed [laughs]. +JOËL: I think there's something to be said for the sort of energy boost you get from novelty and change, and some of that you get it from maybe rotating to a different project. But like you were saying, you can change your environment, and that can happen as well. And, you know, sometimes it's going halfway across the country to live in a place for a month. +I sometimes do that in a smaller way by saying, oh, I'm going to work this morning from a coffee shop or something like that. And just say, look, by changing the environment, I can maybe get some focus or some energy that I wouldn't have if I were just doing same old, same old. +STEPHANIE: Yeah, that's a good point. +So, one particularly surprising refresh that I experienced in offboarding from my client work is coming back to my thoughtbot, like, internal company laptop, which had been sitting gathering dust [laughs] a little bit because I had a client-issued laptop that I was working in most of the time. And yeah, I didn't realize how different it would feel. +I had, you know, gotten everything set up on my, you know, my thoughtbot computer just the way that I liked it, stuff that I'd never kind of bothered to set up on my other client-issued laptop. And then I came back to it, and then it ended up being a little bit surprising. I was like, oh, the icons are smaller on this [laughs] computer than the other computer. +But it definitely did feel like returning to home, I think, instead of, like, being a guest in someone else's house that you haven't quite, like, put all your clothes in the closet or in the drawers. You're still maybe, like, living out of a suitcase a little bit [laughs]. So yeah, I was kind of very excited to be in my own space on my computer again. +JOËL: I love the metaphor of coming home, and yeah, being in your own space, sleeping in your own bed. There's definitely some of that that I feel, I think, when I come back to my thoughtbot laptop as well. +Do you feel like you get a different sense of connection with the rest of our thoughtbot colleagues when you're working on the thoughtbot-issued laptop versus a client-issued one? +STEPHANIE: Yeah. Even though on my client-issued computer I had the thoughtbot Slack, like, open on there so I could be checking in, I wasn't necessarily in, like, other thoughtbot digital spaces as much, right? So, our, like, project management tools and our, like, internal company web app, those were things that I was on less of naturally because, like, the majority of my work was client work, and I was all in their digital spaces. +But coming back and checking in on, like, all the GitHub discussions that have been happening while I haven't had enough time to catch up on them, just realizing that things were happening [laughs] even when I was doing something else, that is both cool and also like, oh wow, like, kind of sad that I [chuckles] missed out on some of this as it was going on. +JOËL: That's pretty similar to my experience. For me, it almost feels a little bit like the difference between back when we used to be in person because thoughtbot is now fully remote. I would go, usually, depending on the client, maybe a couple of days a week working from their offices if they had an office. Versus some clients, they would come to our office, and we would work all week out of the thoughtbot offices, particularly if it was like a startup founder or something, and they might not already have office space. +And that difference and feeling the connection that I would have from the rest of the thoughtbot team if I were, let's say, four days a week out of a client office versus two or four days a week out of the thoughtbot office feels kind of similar to what it's like working on a client-issued laptop versus on a thoughtbot-issued one. +STEPHANIE: Another thing that I guess I forgot about or, like, wasn't expecting to do was all the cleanup, just the updating of things on my laptop as I kind of had it been sitting. And it reminded me to, I guess, extend that, like, coming home metaphor a little bit more. In the game Animal Crossing, if you haven't played the game in a while because it tracks, like, real-time, so it knows if you haven't, you know, played the game in a few months, when you wake up in your home, there's a bunch of cockroaches running around [laughs], and you have to go and chase and, like, squash them to clean it up. +JOËL: Oh no. +STEPHANIE: And it kind of felt like that opening my computer. I was like, oh, like, my, like, you know, OS is out of date. My browsers are out of date. I decided to get an internal company project running in my local development again, and I had to update so many things, you know, like, install the new Ruby version that the app had, you know, been upgraded to and upgrade, like, OpenSSL and all of that stuff on my machine to, yeah, get the app running again. +And like I mentioned earlier, just the idea of like, oh yeah, this has evolved and changed, like, without me [laughs] was just, you know, interesting to see. And catching myself up to speed on that was not trivial work. So yeah, like, all that maintenance stuff still got to do it. It's, like, the digital cleanup, right? +JOËL: Exactly. So, you mentioned that on the client machine, you still had the thoughtbot Slack. So, you were able to keep up at least some messages there on one device. I'm curious about the experience, maybe going the other way. How much does thoughtbot stuff bleed into your personal devices, if at all? +STEPHANIE: Barely. I am very strict about that, I think. I used to have Slack on my phone, I don't know, just, like, in an earlier time in my career. But now I have it a rule to keep it off. I think the only thing that I have is my calendar, so no email either. Like, that is something that I, like, don't like to check on my personal time. Yeah, so it really just is calendar just in case I'm, like, out in the morning and need to be, like, oh, when is my first meeting? +But [laughs] I will say that the one kind of silly thing is that I also refuse to sign into my Google account for work. So, I just have the calendar, like, added to my personal calendar but all the events are private. So, I can't actually see what the events are [laughs]. I just know that I have something going on at, like, 10:00 a.m. So, I got to make sure I'm back home by then [laughs], which is not so ideal. But at the risk of being signed in and having other things bleed into my personal devices, I'm just living with that for now [laughs]. +JOËL: What I'm hearing is that I could put some mystery events on your calendar, and you would have a fun surprise in the morning because you wouldn't know what it is. +STEPHANIE: Yeah, that is true [laughs]. If you put, like, a meeting at, like, 8:00 a.m., [laughs] then I'm like, oh no, what's this? And then I arrive, and it's just, like [laughs], a fun prank meeting. +So, you know, you were talking about how you were at the conference this week. And I'm wondering, how connected were you to work life? +JOËL: Uh, not very. I tried to be very present in the moment at the conference. So, I'm, you know, connected to all the other thoughtboters who were there and connecting with the attendees. I do have Slack on my phone, so if I do need to check it for something. There was a little bit of communication that was going on for different things regarding the conference, so I did check in for that. But otherwise, I tried to really stay focused on the in-person things that are happening. +I'm not doing any client work during those days that I'm at RubyConf, and so I don't need to deal with anything there. I had my thoughtbot laptop with me because that's what I used to give my presentation. But once the presentation was done, I closed that laptop and didn't open it again, and, honestly, that felt kind of good. +STEPHANIE: Yeah, that is really nice. I'm the same way, where I try to be pretty connected at conferences, and, like, I will actually redownload Slack sometimes just for, like, coordinating purposes with other folks who are there. But I think I make it pretty clear that I'm, like, away. You know, like, I'm not actually...like, even though I'm on work time, I'm not doing any other work besides just being present there. +JOËL: So, you mentioned the idea of work time. Do you have, like, a pretty strict boundary between personal time and work time and, like, try not to allow either to bleed into each other? +STEPHANIE: Yeah. I can't remember if I've mentioned this on the show. I think I have, but I'm going to again because one of my favorite things that I picked up from The Bike Shed back when Chris Toomey and Steph Viccari were hosting the show is Chris had, like, a little ritual that he would do every day to signal that he was done with work. He would close his laptop and say, "Schedule shutdown complete," I think. +And I've started adopting it because then it helps me be like, I'm not going to reopen my laptop after this because I have said the words. And even if I think of something that I maybe need to add to my to-do list, I will, instead of opening my computer and adding to my, like, whatever digital to-do list, I will, like, write it down on a piece of paper instead for the sake of, you know, not risking getting sucked back into, you know, whatever might be going on after the time that I've, like, decided that I need to be done. +JOËL: So, you have a very strict divisioning between work time and personal time. +STEPHANIE: Yeah, I would say so. I think it's important for me because even when I take time off, you know, sometimes folks might work a half day or something, right? I really struggle with having even a half day feel like, once I'm done with work, having that feel like okay, like, now I'm back in my personal time. I'd much prefer not working the entire day at all because that is kind of the only way that I can feel like I've totally reclaimed that time. +Otherwise, it's like, once I start thinking about work stuff, it's like I need a mental boundary, right? Because if I'm thinking about a work problem, or, like, an interaction or, like, just anything, it's frustrating because it doesn't feel like time in my own brain [laughs] is my own. +What do work and personal time boundaries look like for you? +JOËL: I think it's evolved over time. Device usage is definitely a little bit more blurry for me. One thing that I have started doing since we've gone fully remote as the pandemic has been winding down and, you know, you can do things, but we're still working from home, is that more days than not, I work from home during the day, and then I leave my home during the evening. I do a variety of social activities. And because I like to be sort of present in the moment, that means that by being physically gone, I have totally disconnected because I'm not checking emails or anything like that. +Even though I do have thoughtbot email on my phone, Gmail allows me to like log into my personal account and my thoughtbot account. I have to, like, switch between the two accounts, and so, that's, like, more work than I would want. I don't have any notifications come in for the thoughtbot account. So, unless I'm, like, really wanting to see if a particular email I'm waiting for has come in, I don't even look at it, ever. It's mostly just there in case I need to see something. +And then, by being focused in the moment doing social things with other people, I don't find too much of a temptation to, like, let work life bleed into personal life. So, there's a bit of a physical disconnect that ends up happening by moving out of the space I work in into leaving my home. +STEPHANIE: Yeah. And I'm sure it's different for everyone. As you were saying that, I was reminded of a funny meme that I saw a long time ago. I don't think I could find it if I tried to search for it. But basically, it's this guy who is, you know, sitting on one side of the couch, clearly working. And he's kind of hunched over and, like, typing and looking very serious. +And then he, like, closes his laptop, moves over, like, just slides to the other side of the couch, opens his laptop. And then you see him, like, lay back, like, legs up on the coffee table. And it's, like, work computer, personal computer, but it's the same computer [laughs]. It's just the, like, how you've decided like, oh, it's time for, you know, legs up, Netflix watching [laughs]. +JOËL: Yeah. Yeah. I'm curious: do you use your thoughtbot computer for any personal things? Or is it just you shut that down; you do the closing ritual, and then you do things on a separate device? +STEPHANIE: Yeah, I do things on a separate device. I think the only thing there might be some overlap for are, like, career-related extracurriculars or just, like, development stuff that I'm interested in doing, like, separate from what I am paid to do. But that, you know, kind of overlaps a little bit because of, like, the tools and the stuff I have installed on my computer. And, you know, with our investment time, too, that ends up having a bit of a crossover. +JOËL: I think I'm similar in that I'll tend to do development things on my thoughtbot machine, even though they're not necessarily thoughtbot-related, although they could be things that might slot into something like investment time. +STEPHANIE: Yeah, yeah. And it's because you have all your stuff set up for it. Like, you're not [laughs] trying to install the latest Ruby version on two different machines, probably [laughs]. +JOËL: Yeah. Also, my personal device is a Windows machine. And I've not wanted to bother learning how to set that up or use the Windows Subsystem for Linux or any of those tools, which, you know, may be good professional learning activities. But that's not where I've decided to invest my time. +STEPHANIE: That makes sense. I had an interesting conversation with someone else today, actually, about devices because I had mentioned that, you know, sometimes I still need to incorporate my personal devices into work stuff, especially, like, two-factor authentication. And specifically on my last client project...I have a very old iPhone [laughs]. I need to start out by saying it's an iPhone 8 that I've had for, like, six or seven years. And so, it's old. +Like, one time I went to the Apple store, and I was like, "Oh, I'm looking for a screen protector for this." And they're like, "Oh, it's an iPhone 8. Yikes." [laughs] This was, you know, like, not too long ago [laughs]. And the multi-factor authentication policy for my client was that, you know, we had to use this specific app. And it also had, like, security checks. Like, there's a security policy that it needed to be updated to the latest iOS. So, even if I personally didn't want to update my iOS [laughs], I felt compelled to because, otherwise, I would be locked out of the things that I needed to do at work [laughs]. +JOËL: Yeah, that can be a challenge sometimes when you're adding work things to personal devices, maybe not because it's convenient and you want to, but because you don't have a choice for things like two-factor auth. +STEPHANIE: Yeah, yeah. And then the person I was talking to actually suggested something I hadn't even thought about, which is like, "Oh, you know, if you really can't make it work, then, like, consider having that company issue another device for you to do the things that they're, like, requiring of you." And I hadn't even thought of that, so... And I'm not quite at the point where I'm like, everything has to be, like, completely separate [laughs], including two-factor auth. But, I don't know, something to consider, like, maybe that might be a place I get to if I'm feeling like I really want to keep those boundaries strict. +JOËL: And I think it's interesting because, you know, when you think of the kind of work that we do, it's like, oh, we work with computers, but there are so many subfields within it. And device management and, just maybe, corporate IT, in general, is a whole subfield that is separate and almost a little bit alien. +Two, I feel like me, as a software developer, I'm just aware of a little bit...like, I've read a couple of articles around...and this was, you know, years ago when the trend was starting called Bring Your Own Device. So, people who want to say, "Hey, I want to use my phone. I want to have my work email on my phone." But then does that mean that potentially you're leaking company memos and things? So, how do you secure that kind of thing? And everything that IT had to think through in order to allow that, the pros and cons. +So, I think we're just kind of, as users of that system, touching the surface of it. But there's a lot of thought and discussion that, as an industry, the kind of corporate IT folks have gone through to struggle with how to balance a lot of those things. +STEPHANIE: Yeah, yeah. I bet there's a lot of complexity or nuance there. I mean, we're just talking about, like, ways that we do or don't mix work and personal life. And for that kind of work, you know, that's, like, the job is to think really thoroughly about how people use their devices and what should and shouldn't be permissible. +The last thing that I wanted to kind of ask about in terms of device management or, like, work and personal intermixing is the idea of being on call and your device being a way for work to reach you and that being a requirement, right? I feel very lucky to obviously not really be in that position. As consultants, like, we're not usually so embedded into a team that we're then brought into, like, an on-call rotation, and I think that's good for me. Like, I don't think that that is something I'd be interested in doing anytime soon. Do you have any experience with that? +JOËL: I have not been on a project where I've had to be on call, and I think that's generally true for most of us at thoughtbot who are doing software development. I know those who are doing more kind of platformy SRE-type things are on call. And, in fact, we have specifically hired people in different regions around the world so that we can provide 24-hour coverage for that kind of thing. +STEPHANIE: Yeah. And I imagine kind of like what we're talking about with work device management looks even different for that kind of role, where maybe you do need a lot more access to things, like, wherever you might be. +JOËL: And maybe the answer there is you get issued a work-specific device and a work phone or something like that, or an old-school work pager. +STEPHANIE: [laughs] +JOËL: PagerDuty is not just a metaphoric thing. Back in the day, they used actual pagers. +STEPHANIE: Yeah, that would be very funny. +JOËL: So yeah, I can't speak to it from personal experience, but I could imagine that maybe some of the dynamics there might be a little bit different. And, you know, for some people, maybe it's fine to just have an app on your phone that pings you when something happens, and you have to be on call. And you're able to be present while waiting, like, in case you get pinged, but also let it go while you're on call. I can imagine that's, like, a really weird kind of, like, shadow, like, working, not working experience that I can't really speak to because I have not been in that position. +STEPHANIE: Yeah. As you were saying that, I also had the thought that, like, our ability to step away from work and our devices is also very much dependent on, like, a company culture and those types of factors, right? Where, you know, it is okay for me to not be able to look at that stuff and just come back to it Monday morning, and I am very grateful [laughs] for that. Because I recognize that, like, not everyone is in that position where there might be a lot more pressure or urgency to be on top of that. But right now, for this time in my life, like, that's kind of how I like to work. +JOËL: I think it kind of sits at the intersection of a few different things, right? There's sort of where you are personally. It might be a combination, like, personality and maybe, like, mental health, things like that, how you respond to how sharp or blurry those lines between work and personal life can be. +Like you said, it's also an element of company culture. If there's a company culture that's really pushing to get into your personal life, maybe you need firmer boundaries. And then, finally, what we spent most of this episode talking about: technical solutions, whether that's, like, physically separating everything such that there are two devices. And you close down your laptop, and you're done for the day. And whether or not you allow any apps on your personal phone to carry with you after you leave for the day. +So, I think at the intersection of those three is sort of how you're going to experience that, and every person is going to be a little bit different. Because those three...I guess I'm thinking of a Venn diagram. Those three circles are going to be different for everyone. +STEPHANIE: Yeah, that makes complete sense. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + + Joël recaps his time at RubyConf! He shares insights from his talk about different aspects of time in software development, emphasizing the interaction with the audience and the importance of post-talk discussions. Stephanie talks about wrapping up a long-term client project, the benefits of change and variety in consulting, and maintaining a balance between project engagement and avoiding burnout.

+ +

They also discuss strategies for maintaining work-life balance, such as physical separation and device management, particularly in a remote work environment.

+ +
+ + + +

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: Well, as of this recording, I have just gotten back from spending the week in San Diego for RubyConf.

+ +

STEPHANIE: Yay, so fun.

+ +

JOËL: It's always so much fun to connect with the community over there, talk to other people from different companies who work in Ruby, to be inspired by the talks. This year, I was speaking, so I gave a talk on time and how it's not a single thing but multiple different quantities. In particular, I distinguish between a moment in time like a point, a duration and amount of time, and then a time of day, which is time unconnected to a particular day, and how those all connect together in the software that we write.

+ +

STEPHANIE: Awesome. How did it go? How was it received?

+ +

JOËL: It was very well received. I got a lot of people come up to me afterwards and make a variety of time puns, which those are so easy to make. I had to hold myself back not to put too many in the talk itself. I think I kept it pretty clean. There were definitely a couple of time puns in the description of the talk, though.

+ +

STEPHANIE: Yeah, absolutely. You have to keep some in there. But I hear you that you don't want it to become too punny [laughs]. What I really love about conferences, and we've talked a little bit about this before, is the, you know, like, engagement and being able to connect with people. And you give a talk, but then that ends up leading to a lot of, like, discussions about it and related topics afterwards in the hallway or sitting together over a meal.

+ +

JOËL: I like to, in my talks, give little kind of hooks for people who want to have those conversations in the hallway. You know, sometimes it's intimidating to just go up to a speaker and be like, oh, I want to, like, dig into their talk a little bit. But I don't have anything to say other than just, like, "I liked your talk." So, if there's any sort of side trails I had to cut for the talk, I might give a shout-out to it and say, "Hey, if you want to learn more about this aspect, come talk to me afterwards."

+ +

So, one thing that I put in this particular talk was like, "Hey, we're looking at these different graphical ways to think about time. These are similar to but not the same as thinking of time as a one-dimensional vector and applying vector math to it, which is a whole other side topic. If you want to nerd out about that, come find me in the hallway afterwards, and I'd love to go deeper on it." And yeah, some people did.

+ +

STEPHANIE: That's really smart. I like that a lot. You're inviting more conversation about it, which I know, like, you also really enjoy just, like, taking it further or, like, caring about other people's experiences or their thoughts about vector math [laughs].

+ +

JOËL: I think it serves two purposes, right? It allows people to connect with me as a speaker. And it also allows me to feel better about pruning certain parts of my talk and saying, look, this didn't make sense to keep in the talk, but it's cool material. I'd love to have a continuing conversation about this. So, here's a path we could have taken. I'm choosing not to, as a speaker, but if you want to take that branch with me, let's have that afterwards in the hallway.

+ +

STEPHANIE: Yeah. Or even as, like, new content for yourself or for someone else to take with them if they want to explore that further because, you know, there's always something more to explore [chuckles].

+ +

JOËL: I've absolutely done that with past talks. I've taken a thing I had to prune and turned it into a blog post. A recent example of that was when I gave a talk at RailsConf Portland, which I guess is not so recent. I was talking about ways to deal with a test suite that's making too many database requests. And talking about how sometimes misusing let in your RSpec tests can lead to more database requests than you expect.

+ +

And I had a whole section about how to better understand what database requests will actually be made by a series of let expressions and dealing with the eager versus lazy and all of that. I had to cut it. But I was then able to make a blog post about it and then talk about this really cool technique involving dependency graphs. And that was really fun. So, that was a thing where I was able to say, look, here's some content that didn't make it into the talk because I needed to focus on other things. But as its own little, like, side piece of content, it absolutely works, and here's a blog post.

+ +

STEPHANIE: Yeah. And then I think it turned into a Bike Shed episode, too [laughs].

+ +

JOËL: I think it did, yes. I think, in many ways, creativity begets creativity. It's hard to get started writing or producing content or whatever, but once you do, every idea you have kind of spawns new ideas. And then, pretty soon, you have a backlog that you can't go through.

+ +

STEPHANIE: That's awesome. Any other highlights from the conference you want to shout out?

+ +

JOËL: I'd love to give a shout-out to a couple of talks that I went to, Aji Slater's talk on the Enigma machine as a German code machine from World War II and how we can sort of implement our own in Ruby and an exploration of object-oriented programming was fantastic. Aji is just a masterful storyteller. So, that was really great.

+ +

And then Alan Ridlehoover's talk on dealing with flaky tests that one, I think, was particularly useful because I think it's one of the talks that is going to be immediately relevant on Monday morning for, like, every developer that was in that room and is going back to their regular day job. And they can immediately use all of those principles that Alan talked about to deal with the flaky tests in their test suite.

+ +

And there's, in particular, at the end of his presentation, Alan has this summary slide. He kind of broke down flakiness across three different categories and then talked about different strategies for identifying and then fixing tests that were flaky because of those reasons.

+ +

And he has this table where he sort of summarizes basically the entire talk. And I feel like that's the kind of thing that I'm going to save as a cheat sheet. And that can be, like, I'm going to link to this and share it all over because it's really useful. Alan has already put his slides up online. It's all linked to that particular slide in the show notes because I think that all of you would benefit from seeing that.

+ +

The talks themselves are recorded, but they're not going to be out for a couple of weeks. I'm sure when they do, we're going to go through and watch some and probably comment on some of the talks as well.

+ +

So, Stephanie, what is new in your world?

+ +

STEPHANIE: Yeah. So, I'm celebrating wrapping up a client project after a nine-month engagement.

+ +

JOËL: Whoa, that's a pretty long project.

+ +

STEPHANIE: Yeah, that's definitely on the longer side for thoughtbot. And I'm, I don't know, just, like, feeling really excited for a change, feeling really, you know, proud of kind of, like, all of the work that we had done. You know, we had been working with this client for a long time and had been, you know, continuing to deliver value to them to want to keep working with us for that long. But I'm, yeah, just looking forward to a refresh.

+ +

And I think that's one of my favorite things about consulting is that, you know, you can inject something new into your work life at a kind of regular cadence. And, at least for me, that's really important in reducing or, like, preventing the burnout. So, this time around, I kind of started to notice, and other people, too, like my manager, that I was maybe losing a bit of steam on this client project because I had been working on it for so long.

+ +

And part of, you know, what success at thoughtbot means is that, like, we as employees are also feeling fulfilled, right? And, you know, what are the different ways that we can try to make sure that that remains the case? And kind of rotating folks on different projects and kind of making sure that things do feel fresh and exciting is really important.

+ +

And so, I feel very grateful that other people were able to point that out for me, too, when I wasn't even fully realizing it. You know, I had people checking in on me and being like, "Hey, like, you've been on this for a while now. Kind of what I've been hearing is that, like, maybe you do need something new." I'm just excited to get that change.

+ +

JOËL: How do you find the balance between sort of feeling fulfilled and maybe, you know, finding that point where maybe you're feeling you're running out of steam–versus, you know, some projects are really complex, take a while to ramp up; you want to feel productive; you want to feel like you have contributed in a significant way to a project? How do you navigate that balance?

+ +

STEPHANIE: Yeah. So, the flip side is, like, I also don't think I would enjoy having to be changing projects all the time like every couple of months. That maybe is a little too much for me because I do like to...on our team, Boost, we embed on our team. We get to know our teammates. We are, like, building relationships with them, and supporting them, and teaching them. And all of that is really also fulfilling for me, but you can't really do that as much if you're on more shorter-term engagements.

+ +

And then all of that, like, becomes worthwhile once you're kind of in that, like, maybe four or five six month period where you're like, you've finally gotten your groove. And you're like, I'm contributing. I know how this team works. I can start to see patterns or, like, maybe opportunities or gaps. And that is all really cool, and I think also another part of what I really like about being on Boost.

+ +

But yeah, I think what I...that losing steam feeling, I started to identify, like, I didn't have as much energy or excitement to push forward change. When you kind of get a little bit too comfortable or start to get that feeling of, well, these things are the way they are [laughs], --

+ +

JOËL: Right. Right.

+ +

STEPHANIE: I've now identified that that is kind of, like, a signal, right?

+ +

JOËL: Maybe time for a new project.

+ +

STEPHANIE: Right. Like starting to feel a little bit less motivated or, like, less excited to push myself and push the team a little bit in areas that it needs to be pushed. And so, that might be a good time for someone else at thoughtbot to, like, rotate in or maybe kind of close the chapter on what we've been able to do for a client.

+ +

JOËL: It's hard to be at 100% all the time and sort of always have that motivation to push things to the max, and yeah, variety definitely helps with that. How do you feel about finding signals that maybe you need a break, maybe not from the project but just in general? The idea of taking PTO or having kind of a rest day.

+ +

STEPHANIE: Oh yeah. I, this year, have tried out taking time off but not going anywhere just, like, being at home but being on vacation. And that was really great because then it was kind of, like, less about, like, oh, I want to take this trip in this time of year to this place and more like, oh, I need some rest or, like, I just need a little break. And that can be at home, right? Maybe during the day, I'm able to do stuff that I keep putting off or trying out new things that I just can't seem to find the time to do [chuckles] during my normal work schedule. So, that has been fun.

+ +

JOËL: I think, yeah, sometimes, for me, I will sort of hit that moment where I feel like I don't have the ability to give 100%. And sometimes that can be a signal to be like, hey, have you taken any time off recently? Maybe you should schedule something. Because being able to refresh, even short-term, can sort of give an extra boost of energy in a way where...maybe it's not time for a rotation yet, but just taking a little bit of a break in there can sort of, I guess, extend the time where I feel like I'm contributing at the level that I want to be.

+ +

STEPHANIE: Yeah. And I actually want to point out that a lot of that can also be, like, investing in your life outside of work, too, so that you can come to work with a different approach. I've mentioned the month that I spent in the Hudson Valley in New York and, like, when I was there, I felt, like, so different. I was, you know, just, like, so much more excited about all the, like, novel things that I was experiencing that I could show up to work and be like, oh yeah, like, I'm feeling good today. So, I have all this, you know, energy to bring to the tasks that I have at work.

+ +

And yeah, so even though it wasn't necessarily time off, it was investing in other things in my life that then brought that refresh at work, even though nothing at work really changed [laughs].

+ +

JOËL: I think there's something to be said for the sort of energy boost you get from novelty and change, and some of that you get it from maybe rotating to a different project. But like you were saying, you can change your environment, and that can happen as well. And, you know, sometimes it's going halfway across the country to live in a place for a month.

+ +

I sometimes do that in a smaller way by saying, oh, I'm going to work this morning from a coffee shop or something like that. And just say, look, by changing the environment, I can maybe get some focus or some energy that I wouldn't have if I were just doing same old, same old.

+ +

STEPHANIE: Yeah, that's a good point.

+ +

So, one particularly surprising refresh that I experienced in offboarding from my client work is coming back to my thoughtbot, like, internal company laptop, which had been sitting gathering dust [laughs] a little bit because I had a client-issued laptop that I was working in most of the time. And yeah, I didn't realize how different it would feel.

+ +

I had, you know, gotten everything set up on my, you know, my thoughtbot computer just the way that I liked it, stuff that I'd never kind of bothered to set up on my other client-issued laptop. And then I came back to it, and then it ended up being a little bit surprising. I was like, oh, the icons are smaller on this [laughs] computer than the other computer.

+ +

But it definitely did feel like returning to home, I think, instead of, like, being a guest in someone else's house that you haven't quite, like, put all your clothes in the closet or in the drawers. You're still maybe, like, living out of a suitcase a little bit [laughs]. So yeah, I was kind of very excited to be in my own space on my computer again.

+ +

JOËL: I love the metaphor of coming home, and yeah, being in your own space, sleeping in your own bed. There's definitely some of that that I feel, I think, when I come back to my thoughtbot laptop as well.

+ +

Do you feel like you get a different sense of connection with the rest of our thoughtbot colleagues when you're working on the thoughtbot-issued laptop versus a client-issued one?

+ +

STEPHANIE: Yeah. Even though on my client-issued computer I had the thoughtbot Slack, like, open on there so I could be checking in, I wasn't necessarily in, like, other thoughtbot digital spaces as much, right? So, our, like, project management tools and our, like, internal company web app, those were things that I was on less of naturally because, like, the majority of my work was client work, and I was all in their digital spaces.

+ +

But coming back and checking in on, like, all the GitHub discussions that have been happening while I haven't had enough time to catch up on them, just realizing that things were happening [laughs] even when I was doing something else, that is both cool and also like, oh wow, like, kind of sad that I [chuckles] missed out on some of this as it was going on.

+ +

JOËL: That's pretty similar to my experience. For me, it almost feels a little bit like the difference between back when we used to be in person because thoughtbot is now fully remote. I would go, usually, depending on the client, maybe a couple of days a week working from their offices if they had an office. Versus some clients, they would come to our office, and we would work all week out of the thoughtbot offices, particularly if it was like a startup founder or something, and they might not already have office space.

+ +

And that difference and feeling the connection that I would have from the rest of the thoughtbot team if I were, let's say, four days a week out of a client office versus two or four days a week out of the thoughtbot office feels kind of similar to what it's like working on a client-issued laptop versus on a thoughtbot-issued one.

+ +

STEPHANIE: Another thing that I guess I forgot about or, like, wasn't expecting to do was all the cleanup, just the updating of things on my laptop as I kind of had it been sitting. And it reminded me to, I guess, extend that, like, coming home metaphor a little bit more. In the game Animal Crossing, if you haven't played the game in a while because it tracks, like, real-time, so it knows if you haven't, you know, played the game in a few months, when you wake up in your home, there's a bunch of cockroaches running around [laughs], and you have to go and chase and, like, squash them to clean it up.

+ +

JOËL: Oh no.

+ +

STEPHANIE: And it kind of felt like that opening my computer. I was like, oh, like, my, like, you know, OS is out of date. My browsers are out of date. I decided to get an internal company project running in my local development again, and I had to update so many things, you know, like, install the new Ruby version that the app had, you know, been upgraded to and upgrade, like, OpenSSL and all of that stuff on my machine to, yeah, get the app running again.

+ +

And like I mentioned earlier, just the idea of like, oh yeah, this has evolved and changed, like, without me [laughs] was just, you know, interesting to see. And catching myself up to speed on that was not trivial work. So yeah, like, all that maintenance stuff still got to do it. It's, like, the digital cleanup, right?

+ +

JOËL: Exactly. So, you mentioned that on the client machine, you still had the thoughtbot Slack. So, you were able to keep up at least some messages there on one device. I'm curious about the experience, maybe going the other way. How much does thoughtbot stuff bleed into your personal devices, if at all?

+ +

STEPHANIE: Barely. I am very strict about that, I think. I used to have Slack on my phone, I don't know, just, like, in an earlier time in my career. But now I have it a rule to keep it off. I think the only thing that I have is my calendar, so no email either. Like, that is something that I, like, don't like to check on my personal time. Yeah, so it really just is calendar just in case I'm, like, out in the morning and need to be, like, oh, when is my first meeting?

+ +

But [laughs] I will say that the one kind of silly thing is that I also refuse to sign into my Google account for work. So, I just have the calendar, like, added to my personal calendar but all the events are private. So, I can't actually see what the events are [laughs]. I just know that I have something going on at, like, 10:00 a.m. So, I got to make sure I'm back home by then [laughs], which is not so ideal. But at the risk of being signed in and having other things bleed into my personal devices, I'm just living with that for now [laughs].

+ +

JOËL: What I'm hearing is that I could put some mystery events on your calendar, and you would have a fun surprise in the morning because you wouldn't know what it is.

+ +

STEPHANIE: Yeah, that is true [laughs]. If you put, like, a meeting at, like, 8:00 a.m., [laughs] then I'm like, oh no, what's this? And then I arrive, and it's just, like [laughs], a fun prank meeting.

+ +

So, you know, you were talking about how you were at the conference this week. And I'm wondering, how connected were you to work life?

+ +

JOËL: Uh, not very. I tried to be very present in the moment at the conference. So, I'm, you know, connected to all the other thoughtboters who were there and connecting with the attendees. I do have Slack on my phone, so if I do need to check it for something. There was a little bit of communication that was going on for different things regarding the conference, so I did check in for that. But otherwise, I tried to really stay focused on the in-person things that are happening.

+ +

I'm not doing any client work during those days that I'm at RubyConf, and so I don't need to deal with anything there. I had my thoughtbot laptop with me because that's what I used to give my presentation. But once the presentation was done, I closed that laptop and didn't open it again, and, honestly, that felt kind of good.

+ +

STEPHANIE: Yeah, that is really nice. I'm the same way, where I try to be pretty connected at conferences, and, like, I will actually redownload Slack sometimes just for, like, coordinating purposes with other folks who are there. But I think I make it pretty clear that I'm, like, away. You know, like, I'm not actually...like, even though I'm on work time, I'm not doing any other work besides just being present there.

+ +

JOËL: So, you mentioned the idea of work time. Do you have, like, a pretty strict boundary between personal time and work time and, like, try not to allow either to bleed into each other?

+ +

STEPHANIE: Yeah. I can't remember if I've mentioned this on the show. I think I have, but I'm going to again because one of my favorite things that I picked up from The Bike Shed back when Chris Toomey and Steph Viccari were hosting the show is Chris had, like, a little ritual that he would do every day to signal that he was done with work. He would close his laptop and say, "Schedule shutdown complete," I think.

+ +

And I've started adopting it because then it helps me be like, I'm not going to reopen my laptop after this because I have said the words. And even if I think of something that I maybe need to add to my to-do list, I will, instead of opening my computer and adding to my, like, whatever digital to-do list, I will, like, write it down on a piece of paper instead for the sake of, you know, not risking getting sucked back into, you know, whatever might be going on after the time that I've, like, decided that I need to be done.

+ +

JOËL: So, you have a very strict divisioning between work time and personal time.

+ +

STEPHANIE: Yeah, I would say so. I think it's important for me because even when I take time off, you know, sometimes folks might work a half day or something, right? I really struggle with having even a half day feel like, once I'm done with work, having that feel like okay, like, now I'm back in my personal time. I'd much prefer not working the entire day at all because that is kind of the only way that I can feel like I've totally reclaimed that time.

+ +

Otherwise, it's like, once I start thinking about work stuff, it's like I need a mental boundary, right? Because if I'm thinking about a work problem, or, like, an interaction or, like, just anything, it's frustrating because it doesn't feel like time in my own brain [laughs] is my own.

+ +

What do work and personal time boundaries look like for you?

+ +

JOËL: I think it's evolved over time. Device usage is definitely a little bit more blurry for me. One thing that I have started doing since we've gone fully remote as the pandemic has been winding down and, you know, you can do things, but we're still working from home, is that more days than not, I work from home during the day, and then I leave my home during the evening. I do a variety of social activities. And because I like to be sort of present in the moment, that means that by being physically gone, I have totally disconnected because I'm not checking emails or anything like that.

+ +

Even though I do have thoughtbot email on my phone, Gmail allows me to like log into my personal account and my thoughtbot account. I have to, like, switch between the two accounts, and so, that's, like, more work than I would want. I don't have any notifications come in for the thoughtbot account. So, unless I'm, like, really wanting to see if a particular email I'm waiting for has come in, I don't even look at it, ever. It's mostly just there in case I need to see something.

+ +

And then, by being focused in the moment doing social things with other people, I don't find too much of a temptation to, like, let work life bleed into personal life. So, there's a bit of a physical disconnect that ends up happening by moving out of the space I work in into leaving my home.

+ +

STEPHANIE: Yeah. And I'm sure it's different for everyone. As you were saying that, I was reminded of a funny meme that I saw a long time ago. I don't think I could find it if I tried to search for it. But basically, it's this guy who is, you know, sitting on one side of the couch, clearly working. And he's kind of hunched over and, like, typing and looking very serious.

+ +

And then he, like, closes his laptop, moves over, like, just slides to the other side of the couch, opens his laptop. And then you see him, like, lay back, like, legs up on the coffee table. And it's, like, work computer, personal computer, but it's the same computer [laughs]. It's just the, like, how you've decided like, oh, it's time for, you know, legs up, Netflix watching [laughs].

+ +

JOËL: Yeah. Yeah. I'm curious: do you use your thoughtbot computer for any personal things? Or is it just you shut that down; you do the closing ritual, and then you do things on a separate device?

+ +

STEPHANIE: Yeah, I do things on a separate device. I think the only thing there might be some overlap for are, like, career-related extracurriculars or just, like, development stuff that I'm interested in doing, like, separate from what I am paid to do. But that, you know, kind of overlaps a little bit because of, like, the tools and the stuff I have installed on my computer. And, you know, with our investment time, too, that ends up having a bit of a crossover.

+ +

JOËL: I think I'm similar in that I'll tend to do development things on my thoughtbot machine, even though they're not necessarily thoughtbot-related, although they could be things that might slot into something like investment time.

+ +

STEPHANIE: Yeah, yeah. And it's because you have all your stuff set up for it. Like, you're not [laughs] trying to install the latest Ruby version on two different machines, probably [laughs].

+ +

JOËL: Yeah. Also, my personal device is a Windows machine. And I've not wanted to bother learning how to set that up or use the Windows Subsystem for Linux or any of those tools, which, you know, may be good professional learning activities. But that's not where I've decided to invest my time.

+ +

STEPHANIE: That makes sense. I had an interesting conversation with someone else today, actually, about devices because I had mentioned that, you know, sometimes I still need to incorporate my personal devices into work stuff, especially, like, two-factor authentication. And specifically on my last client project...I have a very old iPhone [laughs]. I need to start out by saying it's an iPhone 8 that I've had for, like, six or seven years. And so, it's old.

+ +

Like, one time I went to the Apple store, and I was like, "Oh, I'm looking for a screen protector for this." And they're like, "Oh, it's an iPhone 8. Yikes." [laughs] This was, you know, like, not too long ago [laughs]. And the multi-factor authentication policy for my client was that, you know, we had to use this specific app. And it also had, like, security checks. Like, there's a security policy that it needed to be updated to the latest iOS. So, even if I personally didn't want to update my iOS [laughs], I felt compelled to because, otherwise, I would be locked out of the things that I needed to do at work [laughs].

+ +

JOËL: Yeah, that can be a challenge sometimes when you're adding work things to personal devices, maybe not because it's convenient and you want to, but because you don't have a choice for things like two-factor auth.

+ +

STEPHANIE: Yeah, yeah. And then the person I was talking to actually suggested something I hadn't even thought about, which is like, "Oh, you know, if you really can't make it work, then, like, consider having that company issue another device for you to do the things that they're, like, requiring of you." And I hadn't even thought of that, so... And I'm not quite at the point where I'm like, everything has to be, like, completely separate [laughs], including two-factor auth. But, I don't know, something to consider, like, maybe that might be a place I get to if I'm feeling like I really want to keep those boundaries strict.

+ +

JOËL: And I think it's interesting because, you know, when you think of the kind of work that we do, it's like, oh, we work with computers, but there are so many subfields within it. And device management and, just maybe, corporate IT, in general, is a whole subfield that is separate and almost a little bit alien.

+ +

Two, I feel like me, as a software developer, I'm just aware of a little bit...like, I've read a couple of articles around...and this was, you know, years ago when the trend was starting called Bring Your Own Device. So, people who want to say, "Hey, I want to use my phone. I want to have my work email on my phone." But then does that mean that potentially you're leaking company memos and things? So, how do you secure that kind of thing? And everything that IT had to think through in order to allow that, the pros and cons.

+ +

So, I think we're just kind of, as users of that system, touching the surface of it. But there's a lot of thought and discussion that, as an industry, the kind of corporate IT folks have gone through to struggle with how to balance a lot of those things.

+ +

STEPHANIE: Yeah, yeah. I bet there's a lot of complexity or nuance there. I mean, we're just talking about, like, ways that we do or don't mix work and personal life. And for that kind of work, you know, that's, like, the job is to think really thoroughly about how people use their devices and what should and shouldn't be permissible.

+ +

The last thing that I wanted to kind of ask about in terms of device management or, like, work and personal intermixing is the idea of being on call and your device being a way for work to reach you and that being a requirement, right? I feel very lucky to obviously not really be in that position. As consultants, like, we're not usually so embedded into a team that we're then brought into, like, an on-call rotation, and I think that's good for me. Like, I don't think that that is something I'd be interested in doing anytime soon. Do you have any experience with that?

+ +

JOËL: I have not been on a project where I've had to be on call, and I think that's generally true for most of us at thoughtbot who are doing software development. I know those who are doing more kind of platformy SRE-type things are on call. And, in fact, we have specifically hired people in different regions around the world so that we can provide 24-hour coverage for that kind of thing.

+ +

STEPHANIE: Yeah. And I imagine kind of like what we're talking about with work device management looks even different for that kind of role, where maybe you do need a lot more access to things, like, wherever you might be.

+ +

JOËL: And maybe the answer there is you get issued a work-specific device and a work phone or something like that, or an old-school work pager.

+ +

STEPHANIE: [laughs]

+ +

JOËL: PagerDuty is not just a metaphoric thing. Back in the day, they used actual pagers.

+ +

STEPHANIE: Yeah, that would be very funny.

+ +

JOËL: So yeah, I can't speak to it from personal experience, but I could imagine that maybe some of the dynamics there might be a little bit different. And, you know, for some people, maybe it's fine to just have an app on your phone that pings you when something happens, and you have to be on call. And you're able to be present while waiting, like, in case you get pinged, but also let it go while you're on call. I can imagine that's, like, a really weird kind of, like, shadow, like, working, not working experience that I can't really speak to because I have not been in that position.

+ +

STEPHANIE: Yeah. As you were saying that, I also had the thought that, like, our ability to step away from work and our devices is also very much dependent on, like, a company culture and those types of factors, right? Where, you know, it is okay for me to not be able to look at that stuff and just come back to it Monday morning, and I am very grateful [laughs] for that. Because I recognize that, like, not everyone is in that position where there might be a lot more pressure or urgency to be on top of that. But right now, for this time in my life, like, that's kind of how I like to work.

+ +

JOËL: I think it kind of sits at the intersection of a few different things, right? There's sort of where you are personally. It might be a combination, like, personality and maybe, like, mental health, things like that, how you respond to how sharp or blurry those lines between work and personal life can be.

+ +

Like you said, it's also an element of company culture. If there's a company culture that's really pushing to get into your personal life, maybe you need firmer boundaries. And then, finally, what we spent most of this episode talking about: technical solutions, whether that's, like, physically separating everything such that there are two devices. And you close down your laptop, and you're done for the day. And whether or not you allow any apps on your personal phone to carry with you after you leave for the day.

+ +

So, I think at the intersection of those three is sort of how you're going to experience that, and every person is going to be a little bit different. Because those three...I guess I'm thinking of a Venn diagram. Those three circles are going to be different for everyone.

+ +

STEPHANIE: Yeah, that makes complete sense.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël recaps his time at RubyConf! He shares insights from his talk about different aspects of time in software development, emphasizing the interaction with the audience and the importance of post-talk discussions. Stephanie talks about wrapping up a long-term client project, the benefits of change and variety in consulting, and maintaining a balance between project engagement and avoiding burnout.

+ +

They also discuss strategies for maintaining work-life balance, such as physical separation and device management, particularly in a remote work environment.

+ +
+ + + +

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: Well, as of this recording, I have just gotten back from spending the week in San Diego for RubyConf.

+ +

STEPHANIE: Yay, so fun.

+ +

JOËL: It's always so much fun to connect with the community over there, talk to other people from different companies who work in Ruby, to be inspired by the talks. This year, I was speaking, so I gave a talk on time and how it's not a single thing but multiple different quantities. In particular, I distinguish between a moment in time like a point, a duration and amount of time, and then a time of day, which is time unconnected to a particular day, and how those all connect together in the software that we write.

+ +

STEPHANIE: Awesome. How did it go? How was it received?

+ +

JOËL: It was very well received. I got a lot of people come up to me afterwards and make a variety of time puns, which those are so easy to make. I had to hold myself back not to put too many in the talk itself. I think I kept it pretty clean. There were definitely a couple of time puns in the description of the talk, though.

+ +

STEPHANIE: Yeah, absolutely. You have to keep some in there. But I hear you that you don't want it to become too punny [laughs]. What I really love about conferences, and we've talked a little bit about this before, is the, you know, like, engagement and being able to connect with people. And you give a talk, but then that ends up leading to a lot of, like, discussions about it and related topics afterwards in the hallway or sitting together over a meal.

+ +

JOËL: I like to, in my talks, give little kind of hooks for people who want to have those conversations in the hallway. You know, sometimes it's intimidating to just go up to a speaker and be like, oh, I want to, like, dig into their talk a little bit. But I don't have anything to say other than just, like, "I liked your talk." So, if there's any sort of side trails I had to cut for the talk, I might give a shout-out to it and say, "Hey, if you want to learn more about this aspect, come talk to me afterwards."

+ +

So, one thing that I put in this particular talk was like, "Hey, we're looking at these different graphical ways to think about time. These are similar to but not the same as thinking of time as a one-dimensional vector and applying vector math to it, which is a whole other side topic. If you want to nerd out about that, come find me in the hallway afterwards, and I'd love to go deeper on it." And yeah, some people did.

+ +

STEPHANIE: That's really smart. I like that a lot. You're inviting more conversation about it, which I know, like, you also really enjoy just, like, taking it further or, like, caring about other people's experiences or their thoughts about vector math [laughs].

+ +

JOËL: I think it serves two purposes, right? It allows people to connect with me as a speaker. And it also allows me to feel better about pruning certain parts of my talk and saying, look, this didn't make sense to keep in the talk, but it's cool material. I'd love to have a continuing conversation about this. So, here's a path we could have taken. I'm choosing not to, as a speaker, but if you want to take that branch with me, let's have that afterwards in the hallway.

+ +

STEPHANIE: Yeah. Or even as, like, new content for yourself or for someone else to take with them if they want to explore that further because, you know, there's always something more to explore [chuckles].

+ +

JOËL: I've absolutely done that with past talks. I've taken a thing I had to prune and turned it into a blog post. A recent example of that was when I gave a talk at RailsConf Portland, which I guess is not so recent. I was talking about ways to deal with a test suite that's making too many database requests. And talking about how sometimes misusing let in your RSpec tests can lead to more database requests than you expect.

+ +

And I had a whole section about how to better understand what database requests will actually be made by a series of let expressions and dealing with the eager versus lazy and all of that. I had to cut it. But I was then able to make a blog post about it and then talk about this really cool technique involving dependency graphs. And that was really fun. So, that was a thing where I was able to say, look, here's some content that didn't make it into the talk because I needed to focus on other things. But as its own little, like, side piece of content, it absolutely works, and here's a blog post.

+ +

STEPHANIE: Yeah. And then I think it turned into a Bike Shed episode, too [laughs].

+ +

JOËL: I think it did, yes. I think, in many ways, creativity begets creativity. It's hard to get started writing or producing content or whatever, but once you do, every idea you have kind of spawns new ideas. And then, pretty soon, you have a backlog that you can't go through.

+ +

STEPHANIE: That's awesome. Any other highlights from the conference you want to shout out?

+ +

JOËL: I'd love to give a shout-out to a couple of talks that I went to, Aji Slater's talk on the Enigma machine as a German code machine from World War II and how we can sort of implement our own in Ruby and an exploration of object-oriented programming was fantastic. Aji is just a masterful storyteller. So, that was really great.

+ +

And then Alan Ridlehoover's talk on dealing with flaky tests that one, I think, was particularly useful because I think it's one of the talks that is going to be immediately relevant on Monday morning for, like, every developer that was in that room and is going back to their regular day job. And they can immediately use all of those principles that Alan talked about to deal with the flaky tests in their test suite.

+ +

And there's, in particular, at the end of his presentation, Alan has this summary slide. He kind of broke down flakiness across three different categories and then talked about different strategies for identifying and then fixing tests that were flaky because of those reasons.

+ +

And he has this table where he sort of summarizes basically the entire talk. And I feel like that's the kind of thing that I'm going to save as a cheat sheet. And that can be, like, I'm going to link to this and share it all over because it's really useful. Alan has already put his slides up online. It's all linked to that particular slide in the show notes because I think that all of you would benefit from seeing that.

+ +

The talks themselves are recorded, but they're not going to be out for a couple of weeks. I'm sure when they do, we're going to go through and watch some and probably comment on some of the talks as well.

+ +

So, Stephanie, what is new in your world?

+ +

STEPHANIE: Yeah. So, I'm celebrating wrapping up a client project after a nine-month engagement.

+ +

JOËL: Whoa, that's a pretty long project.

+ +

STEPHANIE: Yeah, that's definitely on the longer side for thoughtbot. And I'm, I don't know, just, like, feeling really excited for a change, feeling really, you know, proud of kind of, like, all of the work that we had done. You know, we had been working with this client for a long time and had been, you know, continuing to deliver value to them to want to keep working with us for that long. But I'm, yeah, just looking forward to a refresh.

+ +

And I think that's one of my favorite things about consulting is that, you know, you can inject something new into your work life at a kind of regular cadence. And, at least for me, that's really important in reducing or, like, preventing the burnout. So, this time around, I kind of started to notice, and other people, too, like my manager, that I was maybe losing a bit of steam on this client project because I had been working on it for so long.

+ +

And part of, you know, what success at thoughtbot means is that, like, we as employees are also feeling fulfilled, right? And, you know, what are the different ways that we can try to make sure that that remains the case? And kind of rotating folks on different projects and kind of making sure that things do feel fresh and exciting is really important.

+ +

And so, I feel very grateful that other people were able to point that out for me, too, when I wasn't even fully realizing it. You know, I had people checking in on me and being like, "Hey, like, you've been on this for a while now. Kind of what I've been hearing is that, like, maybe you do need something new." I'm just excited to get that change.

+ +

JOËL: How do you find the balance between sort of feeling fulfilled and maybe, you know, finding that point where maybe you're feeling you're running out of steam–versus, you know, some projects are really complex, take a while to ramp up; you want to feel productive; you want to feel like you have contributed in a significant way to a project? How do you navigate that balance?

+ +

STEPHANIE: Yeah. So, the flip side is, like, I also don't think I would enjoy having to be changing projects all the time like every couple of months. That maybe is a little too much for me because I do like to...on our team, Boost, we embed on our team. We get to know our teammates. We are, like, building relationships with them, and supporting them, and teaching them. And all of that is really also fulfilling for me, but you can't really do that as much if you're on more shorter-term engagements.

+ +

And then all of that, like, becomes worthwhile once you're kind of in that, like, maybe four or five six month period where you're like, you've finally gotten your groove. And you're like, I'm contributing. I know how this team works. I can start to see patterns or, like, maybe opportunities or gaps. And that is all really cool, and I think also another part of what I really like about being on Boost.

+ +

But yeah, I think what I...that losing steam feeling, I started to identify, like, I didn't have as much energy or excitement to push forward change. When you kind of get a little bit too comfortable or start to get that feeling of, well, these things are the way they are [laughs], --

+ +

JOËL: Right. Right.

+ +

STEPHANIE: I've now identified that that is kind of, like, a signal, right?

+ +

JOËL: Maybe time for a new project.

+ +

STEPHANIE: Right. Like starting to feel a little bit less motivated or, like, less excited to push myself and push the team a little bit in areas that it needs to be pushed. And so, that might be a good time for someone else at thoughtbot to, like, rotate in or maybe kind of close the chapter on what we've been able to do for a client.

+ +

JOËL: It's hard to be at 100% all the time and sort of always have that motivation to push things to the max, and yeah, variety definitely helps with that. How do you feel about finding signals that maybe you need a break, maybe not from the project but just in general? The idea of taking PTO or having kind of a rest day.

+ +

STEPHANIE: Oh yeah. I, this year, have tried out taking time off but not going anywhere just, like, being at home but being on vacation. And that was really great because then it was kind of, like, less about, like, oh, I want to take this trip in this time of year to this place and more like, oh, I need some rest or, like, I just need a little break. And that can be at home, right? Maybe during the day, I'm able to do stuff that I keep putting off or trying out new things that I just can't seem to find the time to do [chuckles] during my normal work schedule. So, that has been fun.

+ +

JOËL: I think, yeah, sometimes, for me, I will sort of hit that moment where I feel like I don't have the ability to give 100%. And sometimes that can be a signal to be like, hey, have you taken any time off recently? Maybe you should schedule something. Because being able to refresh, even short-term, can sort of give an extra boost of energy in a way where...maybe it's not time for a rotation yet, but just taking a little bit of a break in there can sort of, I guess, extend the time where I feel like I'm contributing at the level that I want to be.

+ +

STEPHANIE: Yeah. And I actually want to point out that a lot of that can also be, like, investing in your life outside of work, too, so that you can come to work with a different approach. I've mentioned the month that I spent in the Hudson Valley in New York and, like, when I was there, I felt, like, so different. I was, you know, just, like, so much more excited about all the, like, novel things that I was experiencing that I could show up to work and be like, oh yeah, like, I'm feeling good today. So, I have all this, you know, energy to bring to the tasks that I have at work.

+ +

And yeah, so even though it wasn't necessarily time off, it was investing in other things in my life that then brought that refresh at work, even though nothing at work really changed [laughs].

+ +

JOËL: I think there's something to be said for the sort of energy boost you get from novelty and change, and some of that you get it from maybe rotating to a different project. But like you were saying, you can change your environment, and that can happen as well. And, you know, sometimes it's going halfway across the country to live in a place for a month.

+ +

I sometimes do that in a smaller way by saying, oh, I'm going to work this morning from a coffee shop or something like that. And just say, look, by changing the environment, I can maybe get some focus or some energy that I wouldn't have if I were just doing same old, same old.

+ +

STEPHANIE: Yeah, that's a good point.

+ +

So, one particularly surprising refresh that I experienced in offboarding from my client work is coming back to my thoughtbot, like, internal company laptop, which had been sitting gathering dust [laughs] a little bit because I had a client-issued laptop that I was working in most of the time. And yeah, I didn't realize how different it would feel.

+ +

I had, you know, gotten everything set up on my, you know, my thoughtbot computer just the way that I liked it, stuff that I'd never kind of bothered to set up on my other client-issued laptop. And then I came back to it, and then it ended up being a little bit surprising. I was like, oh, the icons are smaller on this [laughs] computer than the other computer.

+ +

But it definitely did feel like returning to home, I think, instead of, like, being a guest in someone else's house that you haven't quite, like, put all your clothes in the closet or in the drawers. You're still maybe, like, living out of a suitcase a little bit [laughs]. So yeah, I was kind of very excited to be in my own space on my computer again.

+ +

JOËL: I love the metaphor of coming home, and yeah, being in your own space, sleeping in your own bed. There's definitely some of that that I feel, I think, when I come back to my thoughtbot laptop as well.

+ +

Do you feel like you get a different sense of connection with the rest of our thoughtbot colleagues when you're working on the thoughtbot-issued laptop versus a client-issued one?

+ +

STEPHANIE: Yeah. Even though on my client-issued computer I had the thoughtbot Slack, like, open on there so I could be checking in, I wasn't necessarily in, like, other thoughtbot digital spaces as much, right? So, our, like, project management tools and our, like, internal company web app, those were things that I was on less of naturally because, like, the majority of my work was client work, and I was all in their digital spaces.

+ +

But coming back and checking in on, like, all the GitHub discussions that have been happening while I haven't had enough time to catch up on them, just realizing that things were happening [laughs] even when I was doing something else, that is both cool and also like, oh wow, like, kind of sad that I [chuckles] missed out on some of this as it was going on.

+ +

JOËL: That's pretty similar to my experience. For me, it almost feels a little bit like the difference between back when we used to be in person because thoughtbot is now fully remote. I would go, usually, depending on the client, maybe a couple of days a week working from their offices if they had an office. Versus some clients, they would come to our office, and we would work all week out of the thoughtbot offices, particularly if it was like a startup founder or something, and they might not already have office space.

+ +

And that difference and feeling the connection that I would have from the rest of the thoughtbot team if I were, let's say, four days a week out of a client office versus two or four days a week out of the thoughtbot office feels kind of similar to what it's like working on a client-issued laptop versus on a thoughtbot-issued one.

+ +

STEPHANIE: Another thing that I guess I forgot about or, like, wasn't expecting to do was all the cleanup, just the updating of things on my laptop as I kind of had it been sitting. And it reminded me to, I guess, extend that, like, coming home metaphor a little bit more. In the game Animal Crossing, if you haven't played the game in a while because it tracks, like, real-time, so it knows if you haven't, you know, played the game in a few months, when you wake up in your home, there's a bunch of cockroaches running around [laughs], and you have to go and chase and, like, squash them to clean it up.

+ +

JOËL: Oh no.

+ +

STEPHANIE: And it kind of felt like that opening my computer. I was like, oh, like, my, like, you know, OS is out of date. My browsers are out of date. I decided to get an internal company project running in my local development again, and I had to update so many things, you know, like, install the new Ruby version that the app had, you know, been upgraded to and upgrade, like, OpenSSL and all of that stuff on my machine to, yeah, get the app running again.

+ +

And like I mentioned earlier, just the idea of like, oh yeah, this has evolved and changed, like, without me [laughs] was just, you know, interesting to see. And catching myself up to speed on that was not trivial work. So yeah, like, all that maintenance stuff still got to do it. It's, like, the digital cleanup, right?

+ +

JOËL: Exactly. So, you mentioned that on the client machine, you still had the thoughtbot Slack. So, you were able to keep up at least some messages there on one device. I'm curious about the experience, maybe going the other way. How much does thoughtbot stuff bleed into your personal devices, if at all?

+ +

STEPHANIE: Barely. I am very strict about that, I think. I used to have Slack on my phone, I don't know, just, like, in an earlier time in my career. But now I have it a rule to keep it off. I think the only thing that I have is my calendar, so no email either. Like, that is something that I, like, don't like to check on my personal time. Yeah, so it really just is calendar just in case I'm, like, out in the morning and need to be, like, oh, when is my first meeting?

+ +

But [laughs] I will say that the one kind of silly thing is that I also refuse to sign into my Google account for work. So, I just have the calendar, like, added to my personal calendar but all the events are private. So, I can't actually see what the events are [laughs]. I just know that I have something going on at, like, 10:00 a.m. So, I got to make sure I'm back home by then [laughs], which is not so ideal. But at the risk of being signed in and having other things bleed into my personal devices, I'm just living with that for now [laughs].

+ +

JOËL: What I'm hearing is that I could put some mystery events on your calendar, and you would have a fun surprise in the morning because you wouldn't know what it is.

+ +

STEPHANIE: Yeah, that is true [laughs]. If you put, like, a meeting at, like, 8:00 a.m., [laughs] then I'm like, oh no, what's this? And then I arrive, and it's just, like [laughs], a fun prank meeting.

+ +

So, you know, you were talking about how you were at the conference this week. And I'm wondering, how connected were you to work life?

+ +

JOËL: Uh, not very. I tried to be very present in the moment at the conference. So, I'm, you know, connected to all the other thoughtboters who were there and connecting with the attendees. I do have Slack on my phone, so if I do need to check it for something. There was a little bit of communication that was going on for different things regarding the conference, so I did check in for that. But otherwise, I tried to really stay focused on the in-person things that are happening.

+ +

I'm not doing any client work during those days that I'm at RubyConf, and so I don't need to deal with anything there. I had my thoughtbot laptop with me because that's what I used to give my presentation. But once the presentation was done, I closed that laptop and didn't open it again, and, honestly, that felt kind of good.

+ +

STEPHANIE: Yeah, that is really nice. I'm the same way, where I try to be pretty connected at conferences, and, like, I will actually redownload Slack sometimes just for, like, coordinating purposes with other folks who are there. But I think I make it pretty clear that I'm, like, away. You know, like, I'm not actually...like, even though I'm on work time, I'm not doing any other work besides just being present there.

+ +

JOËL: So, you mentioned the idea of work time. Do you have, like, a pretty strict boundary between personal time and work time and, like, try not to allow either to bleed into each other?

+ +

STEPHANIE: Yeah. I can't remember if I've mentioned this on the show. I think I have, but I'm going to again because one of my favorite things that I picked up from The Bike Shed back when Chris Toomey and Steph Viccari were hosting the show is Chris had, like, a little ritual that he would do every day to signal that he was done with work. He would close his laptop and say, "Schedule shutdown complete," I think.

+ +

And I've started adopting it because then it helps me be like, I'm not going to reopen my laptop after this because I have said the words. And even if I think of something that I maybe need to add to my to-do list, I will, instead of opening my computer and adding to my, like, whatever digital to-do list, I will, like, write it down on a piece of paper instead for the sake of, you know, not risking getting sucked back into, you know, whatever might be going on after the time that I've, like, decided that I need to be done.

+ +

JOËL: So, you have a very strict divisioning between work time and personal time.

+ +

STEPHANIE: Yeah, I would say so. I think it's important for me because even when I take time off, you know, sometimes folks might work a half day or something, right? I really struggle with having even a half day feel like, once I'm done with work, having that feel like okay, like, now I'm back in my personal time. I'd much prefer not working the entire day at all because that is kind of the only way that I can feel like I've totally reclaimed that time.

+ +

Otherwise, it's like, once I start thinking about work stuff, it's like I need a mental boundary, right? Because if I'm thinking about a work problem, or, like, an interaction or, like, just anything, it's frustrating because it doesn't feel like time in my own brain [laughs] is my own.

+ +

What do work and personal time boundaries look like for you?

+ +

JOËL: I think it's evolved over time. Device usage is definitely a little bit more blurry for me. One thing that I have started doing since we've gone fully remote as the pandemic has been winding down and, you know, you can do things, but we're still working from home, is that more days than not, I work from home during the day, and then I leave my home during the evening. I do a variety of social activities. And because I like to be sort of present in the moment, that means that by being physically gone, I have totally disconnected because I'm not checking emails or anything like that.

+ +

Even though I do have thoughtbot email on my phone, Gmail allows me to like log into my personal account and my thoughtbot account. I have to, like, switch between the two accounts, and so, that's, like, more work than I would want. I don't have any notifications come in for the thoughtbot account. So, unless I'm, like, really wanting to see if a particular email I'm waiting for has come in, I don't even look at it, ever. It's mostly just there in case I need to see something.

+ +

And then, by being focused in the moment doing social things with other people, I don't find too much of a temptation to, like, let work life bleed into personal life. So, there's a bit of a physical disconnect that ends up happening by moving out of the space I work in into leaving my home.

+ +

STEPHANIE: Yeah. And I'm sure it's different for everyone. As you were saying that, I was reminded of a funny meme that I saw a long time ago. I don't think I could find it if I tried to search for it. But basically, it's this guy who is, you know, sitting on one side of the couch, clearly working. And he's kind of hunched over and, like, typing and looking very serious.

+ +

And then he, like, closes his laptop, moves over, like, just slides to the other side of the couch, opens his laptop. And then you see him, like, lay back, like, legs up on the coffee table. And it's, like, work computer, personal computer, but it's the same computer [laughs]. It's just the, like, how you've decided like, oh, it's time for, you know, legs up, Netflix watching [laughs].

+ +

JOËL: Yeah. Yeah. I'm curious: do you use your thoughtbot computer for any personal things? Or is it just you shut that down; you do the closing ritual, and then you do things on a separate device?

+ +

STEPHANIE: Yeah, I do things on a separate device. I think the only thing there might be some overlap for are, like, career-related extracurriculars or just, like, development stuff that I'm interested in doing, like, separate from what I am paid to do. But that, you know, kind of overlaps a little bit because of, like, the tools and the stuff I have installed on my computer. And, you know, with our investment time, too, that ends up having a bit of a crossover.

+ +

JOËL: I think I'm similar in that I'll tend to do development things on my thoughtbot machine, even though they're not necessarily thoughtbot-related, although they could be things that might slot into something like investment time.

+ +

STEPHANIE: Yeah, yeah. And it's because you have all your stuff set up for it. Like, you're not [laughs] trying to install the latest Ruby version on two different machines, probably [laughs].

+ +

JOËL: Yeah. Also, my personal device is a Windows machine. And I've not wanted to bother learning how to set that up or use the Windows Subsystem for Linux or any of those tools, which, you know, may be good professional learning activities. But that's not where I've decided to invest my time.

+ +

STEPHANIE: That makes sense. I had an interesting conversation with someone else today, actually, about devices because I had mentioned that, you know, sometimes I still need to incorporate my personal devices into work stuff, especially, like, two-factor authentication. And specifically on my last client project...I have a very old iPhone [laughs]. I need to start out by saying it's an iPhone 8 that I've had for, like, six or seven years. And so, it's old.

+ +

Like, one time I went to the Apple store, and I was like, "Oh, I'm looking for a screen protector for this." And they're like, "Oh, it's an iPhone 8. Yikes." [laughs] This was, you know, like, not too long ago [laughs]. And the multi-factor authentication policy for my client was that, you know, we had to use this specific app. And it also had, like, security checks. Like, there's a security policy that it needed to be updated to the latest iOS. So, even if I personally didn't want to update my iOS [laughs], I felt compelled to because, otherwise, I would be locked out of the things that I needed to do at work [laughs].

+ +

JOËL: Yeah, that can be a challenge sometimes when you're adding work things to personal devices, maybe not because it's convenient and you want to, but because you don't have a choice for things like two-factor auth.

+ +

STEPHANIE: Yeah, yeah. And then the person I was talking to actually suggested something I hadn't even thought about, which is like, "Oh, you know, if you really can't make it work, then, like, consider having that company issue another device for you to do the things that they're, like, requiring of you." And I hadn't even thought of that, so... And I'm not quite at the point where I'm like, everything has to be, like, completely separate [laughs], including two-factor auth. But, I don't know, something to consider, like, maybe that might be a place I get to if I'm feeling like I really want to keep those boundaries strict.

+ +

JOËL: And I think it's interesting because, you know, when you think of the kind of work that we do, it's like, oh, we work with computers, but there are so many subfields within it. And device management and, just maybe, corporate IT, in general, is a whole subfield that is separate and almost a little bit alien.

+ +

Two, I feel like me, as a software developer, I'm just aware of a little bit...like, I've read a couple of articles around...and this was, you know, years ago when the trend was starting called Bring Your Own Device. So, people who want to say, "Hey, I want to use my phone. I want to have my work email on my phone." But then does that mean that potentially you're leaking company memos and things? So, how do you secure that kind of thing? And everything that IT had to think through in order to allow that, the pros and cons.

+ +

So, I think we're just kind of, as users of that system, touching the surface of it. But there's a lot of thought and discussion that, as an industry, the kind of corporate IT folks have gone through to struggle with how to balance a lot of those things.

+ +

STEPHANIE: Yeah, yeah. I bet there's a lot of complexity or nuance there. I mean, we're just talking about, like, ways that we do or don't mix work and personal life. And for that kind of work, you know, that's, like, the job is to think really thoroughly about how people use their devices and what should and shouldn't be permissible.

+ +

The last thing that I wanted to kind of ask about in terms of device management or, like, work and personal intermixing is the idea of being on call and your device being a way for work to reach you and that being a requirement, right? I feel very lucky to obviously not really be in that position. As consultants, like, we're not usually so embedded into a team that we're then brought into, like, an on-call rotation, and I think that's good for me. Like, I don't think that that is something I'd be interested in doing anytime soon. Do you have any experience with that?

+ +

JOËL: I have not been on a project where I've had to be on call, and I think that's generally true for most of us at thoughtbot who are doing software development. I know those who are doing more kind of platformy SRE-type things are on call. And, in fact, we have specifically hired people in different regions around the world so that we can provide 24-hour coverage for that kind of thing.

+ +

STEPHANIE: Yeah. And I imagine kind of like what we're talking about with work device management looks even different for that kind of role, where maybe you do need a lot more access to things, like, wherever you might be.

+ +

JOËL: And maybe the answer there is you get issued a work-specific device and a work phone or something like that, or an old-school work pager.

+ +

STEPHANIE: [laughs]

+ +

JOËL: PagerDuty is not just a metaphoric thing. Back in the day, they used actual pagers.

+ +

STEPHANIE: Yeah, that would be very funny.

+ +

JOËL: So yeah, I can't speak to it from personal experience, but I could imagine that maybe some of the dynamics there might be a little bit different. And, you know, for some people, maybe it's fine to just have an app on your phone that pings you when something happens, and you have to be on call. And you're able to be present while waiting, like, in case you get pinged, but also let it go while you're on call. I can imagine that's, like, a really weird kind of, like, shadow, like, working, not working experience that I can't really speak to because I have not been in that position.

+ +

STEPHANIE: Yeah. As you were saying that, I also had the thought that, like, our ability to step away from work and our devices is also very much dependent on, like, a company culture and those types of factors, right? Where, you know, it is okay for me to not be able to look at that stuff and just come back to it Monday morning, and I am very grateful [laughs] for that. Because I recognize that, like, not everyone is in that position where there might be a lot more pressure or urgency to be on top of that. But right now, for this time in my life, like, that's kind of how I like to work.

+ +

JOËL: I think it kind of sits at the intersection of a few different things, right? There's sort of where you are personally. It might be a combination, like, personality and maybe, like, mental health, things like that, how you respond to how sharp or blurry those lines between work and personal life can be.

+ +

Like you said, it's also an element of company culture. If there's a company culture that's really pushing to get into your personal life, maybe you need firmer boundaries. And then, finally, what we spent most of this episode talking about: technical solutions, whether that's, like, physically separating everything such that there are two devices. And you close down your laptop, and you're done for the day. And whether or not you allow any apps on your personal phone to carry with you after you leave for the day.

+ +

So, I think at the intersection of those three is sort of how you're going to experience that, and every person is going to be a little bit different. Because those three...I guess I'm thinking of a Venn diagram. Those three circles are going to be different for everyone.

+ +

STEPHANIE: Yeah, that makes complete sense.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3idCcYQ2 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 407: Tech Opinions Online with Edward Loveall + https://bikeshed.thoughtbot.com/407 + bb117fcc-416f-46d4-bc27-de88a786fb83 + Tue, 21 Nov 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie interviews Edward Loveall, a former thoughtbotter, now software developer at Relevant Healthcare. + +Part of their discussion centers around Edward's blog post on the tech industry's over-reliance on GitHub. He argues for the importance of exploring alternatives to avoid dependency on a single platform and encourages readers to make informed technological choices. The conversation broadens to include how to form opinions on technology, the balance between personal preferences and team decisions, and the importance of empathy and nuance in professional interactions. Both Stephanie and Edward highlight the value of considering various perspectives and tools in software development, advocating for a flexible, open-minded approach to technology and problem-solving in the tech industry. + 36:44 + no + + + Stephanie interviews Edward Loveall, a former thoughtbotter, now software developer at Relevant Healthcare. +Part of their discussion centers around Edward's blog post on the tech industry's over-reliance on GitHub. He argues for the importance of exploring alternatives to avoid dependency on a single platform and encourages readers to make informed technological choices. The conversation broadens to include how to form opinions on technology, the balance between personal preferences and team decisions, and the importance of empathy and nuance in professional interactions. Both Stephanie and Edward highlight the value of considering various perspectives and tools in software development, advocating for a flexible, open-minded approach to technology and problem-solving in the tech industry. +Relevant (https://relevant.healthcare/) +Let's make sure Github doesn't become the only option (https://blog.edwardloveall.com/lets-make-sure-github-doesnt-become-the-only-option) +And not but (https://blog.edwardloveall.com/and-not-but) +Empathy Online (https://thoughtbot.com/blog/empathy-online) +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. And today, I'm joined by a very special guest, a friend of the pod and former thoughtboter, Edward Loveall. +EDWARD: Hello, thanks for having me. +STEPHANIE: Edward, would you share a little bit about yourself and what you're doing these days? +EDWARD: Yes, I am a software developer at a company called Relevant Healthcare. We do a lot of things, but the maybe high-level summary is we take very complicated medical data and help federally-funded health centers actually understand that data and help their population's health, which is really fun and really great. +STEPHANIE: Awesome. So, Edward, what is new in your world? +EDWARD: Let's see, this weekend...I live in a dense city. I live in Cambridge, Massachusetts, and it's pretty dense there. And a lot of houses are very tightly packed. And delivery drivers struggle to find the numbers on the houses sometimes because A, they're old and B, there is many of them. +And so, we put up house numbers because I live in, like, a three-story kind of building, but there are two different addresses in the same three stories, which is very weird. And so [laughs], delivery drivers are like, "Where is number 10 or 15?" or whatever. And so, there's two different numbers. And so, we finally put up numbers after living here for, like, four years [chuckles]. So, now, hopefully, delivery drivers in the holiday busy season will be able to find our house [laughs]. +STEPHANIE: That's great. Yeah, I have kind of a similar problem where, a lot of the times, delivery folks will think that my house is the big building next door. And the worst is those at the building next door they drop off their packages inside the little, like, entryway that is locked for people who don't live there. And so, I will see my package in the window and, you know, it has my name on it. It has, like, my address on it. +And [laughs] some strategies that I've used is leaving a note on the door [laughter] that is, like, "Please redeliver my package over there," and, like, I'll draw an arrow to the direction of my house. Or sometimes I've been that person to just, like, buzz random [laughter] units and just hope that they, like, let me in, and then I'll grab my package. And, you know, if I know the neighbors, I'll, like, try to apologize the next time I see them. But sometimes I'll just be like, I just need to get my package [laughs]. +EDWARD: You're writing documentation for those people working out in the streets. +STEPHANIE: Yeah. But I'm glad you got that sorted. +EDWARD: Yeah. What about you? What's new in your world? +STEPHANIE: Well, I wanted to talk a little bit about a thing that you and I have been doing lately that I have been enjoying a lot. First of all, are you familiar with the group chat trend these days? Do you know what I'm talking about? +EDWARD: No. +STEPHANIE: Okay. It's basically this idea that, like, everyone is just connecting with their friends via a group chat now as opposed to social media. But as a person who is not a big group chat person, I can't, like, keep up with [chuckles], like, chatting with multiple people [laughter] at once. I much prefer, like, one-on-one interaction. +And, like, a month ago, I asked you if you would be willing to try having a shared note, like, a shared iOS note that we have for items that we want to discuss with each other but, you know, the next time we either talk on the phone or, I don't know, things that are, like, less urgent than a text message would communicate but, like, stuff that we don't want to forget. +EDWARD: Yeah. You're, like, putting a little message in my inbox and vice versa. And yeah, we get to just kind of, whenever we want, respond to it, or think about it, or use it as a topic for a conversation later. +STEPHANIE: Yeah. And I think it is kind of a playbook from, like, a one-on-one with a manager. I know that that's, like, a strategy that some folks use. But I think it works well in the context of our friendship because it's just gotten, like, richer over time. You know, maybe in the beginning, we're like, oh, like, I don't know, here are some random things that I've thought about. But now we're having, like, whole discussions in the note [laughter]. Like, we will respond to each other, like, with sub-bullets [laughs]. And then we end up not even needing to talk about it on the phone because we've already had a whole conversation about it in the note. +EDWARD: Which is good because neither of us are particularly brief when talking on the phone. And [laughs] we only dedicate, like, half an hour every two weeks. It sort of helps clear the decks a little. +STEPHANIE: Yeah, yeah. So, that's what I recommend. Try a shared note for [laughs] your next friendship hangout. +EDWARD: Yeah, it's great. I heartily recommend it. +STEPHANIE: So, one of the things that we end up talking about a lot is various things that we've been reading about tech on the web [laughs]. And we share with each other a lot of, like, blog posts, or articles, various links, and recently, something of yours kind of resurfaced. You wrote a blog post about GitHub a little while ago about how, you know, as an industry, we should make sure that GitHub doesn't become our only option. +EDWARD: Yeah, this was a post I wrote, I think, back in May, or at least earlier this year, and it got a bunch of traction. And it's a somewhat, I would say, controversial article or take. GitHub just had their developer conference, and it resurfaced again. +And I don't have a habit of writing particularly controversial articles, I don't think. Most of my writing history has been technical posts like tutorials. Like, I wrote a whole tutorial on how to write SQL, or I did write one about how to communicate online. But I wasn't, like, so much responding to, like, a particular person's communication or a company's communication. +And this is the first big post I've written that has been a lot more very heavily opinionated, very, like, targeted at a particular thing or entity, I guess you'd say. It's been received well, I think, mostly, and I'm proud of it. But it's a different little world for me, and it's a little scary, honestly. +STEPHANIE: Yeah, I hear that, having an opinion [laughs], a very strong and maybe, like, a less popular opinion, and publishing that for the world. Could you recap what the thesis of it is for our listeners? +EDWARD: Yeah, and I think you did a great job of it, too. I see GitHub or really any singular piece of technology that we have in...I'll say our stack with air quotes, but it's, you know, all the tools that we use and all the things that we use. It's a risk if you only have one of those things, let's say GitHub. Like, if the only way you know how to contribute to a code repository with, you know, 17 people all committing to that repository, if the only way you know how to do that is a pull request and GitHub goes away, and you don't have pull requests anymore, how are you going to contribute to code? +It's not that you couldn't figure it out, or there aren't multiple ways or even other pull request equivalents on other sites. But it is a risk to rely on one company to provide all of the things that you potentially need, or even many of the things that you potentially need, without any alternatives. +So, I wanted to try to lay out A: those risks, and B: encourage people to try alternatives, to say that GitHub is not necessarily bad, although they may not actually fit what you need for various reasons, or someone else for various reasons. But you should have an alternative in your back pocket so that in case something changes, or you get locked out, or they go away, or they decide to cancel that feature, or any number of other scenarios, you have greatly diminished that risk. So, that's the main thrust of the post. +STEPHANIE: Yeah, I really appreciated it because, you know, I think a lot of us probably take GitHub for granted [laughs]. And, you know, every new thing that they kind of add to the platform is like, oh, like, cool, like, I can now do this. In the post, you kind of lay out all of the different features that GitHub has rolled out over the last, you know, couple of years. And when you see it all like that, you know, like, in addition to being, like, a code repository, you now have, like, GitHub Actions for CI/CD, you know, you can deploy static pages with it. +It now has, like, an in-browser editor, and then, you know, Copilot, which, like, the more things that they [laughs] roll out, the more it's becoming, like, the one-stop shop, right? That, like, do all of your work here. And I appreciated kind of, like, seeing that and being like, oh, like, is this what I want? +EDWARD: Right. Yeah, exactly. Yeah. And you mentioned a bunch. There's also issues and discussions. You mentioned their in-browser editor. But so many people use VS Code, which, while it was technically made by Microsoft, it's based on Electron, which was developed at GitHub. And GitHub even, like, took away their other Electron-based editor, Atom. And then now officially recommends VS Code. +And everything from deploying all the way down to, like, thinking about and prioritizing features and editing the code and all of that pretty much could happen on GitHub. I think maybe the only thing they don't currently do is host non-static sites, maybe [laughs]. That's maybe about it. And who knows? Maybe they're working on that; as far as I know, they are, so... +STEPHANIE: Yeah, absolutely. You also mentioned one thing that I really liked about the content in the post was that you talked about alternatives to GitHub, even, like, alternatives to all of the different features that we mentioned. I guess I'm wondering, like, what were you hoping that a reader from your blog post, like, what they would get out of reading and, like, what they would take away from kind of sharing your opinion? +EDWARD: I wanted to try to meet people where I think they might be because I think a lot of people do use GitHub, and they do take it for granted. And they do sort of see it as this thing that they must use, or they want to use even, and that's fine. That's not necessarily a bad thing. I want them to see those alternatives and have at least some idea that there is something else out there, that GitHub doesn't become just not only the default, but, like, the only thing. +I mean, to just [chuckles] re-paraphrase the title of the post, I want to make sure GitHub does not become the only option, right? I want people to realize that there are other options out there and be encouraged to try them. And I have found, for me, at least, the better way to do that is not to only focus on, like, hey, don't use GitHub. Like, I hope people did not come away with only that message or even that message at all. But that it is more, hey, maybe try something else out and to encourage you to try something out. +I'm going to A: share the risks with you and B: give you some actual things to try. So, I talk about the things I'm using and some other platforms and different paradigms to think about and use. So, I hope they take those. We'll see what happens in the next, you know, months or years. And I'll probably never know if it was actually just from me or from many other conversations, and thoughts, and articles, and all that kind of stuff. But that's what it takes, so... +STEPHANIE: Yeah. I think the other fun thing about kind of the, like, meta-conversation we're having about having an opinion and, like, sharing it with the world is that you don't even really say like, "This is better than GitHub," or, like, kind of make a statement about, like, you shouldn't use...you don't even say, "You shouldn't use GitHub," right? The message is, like, here are some options: try it out, and, like, decide for yourself. +EDWARD: Yeah, exactly. I want to empower people to do that. I don't think it would have been useful if I'd just go and say, "Hey, don't do this." It's very frustrating to me to see posts that are only negatives. And, honestly, I've probably written those posts, like, I'm not above them necessarily. +But I have found that trying to help people do what you want them to do, as silly and maybe obvious as that sounds, is a more effective way to get them to do what you want them to do [laughs], as opposed to say, "Hey, stop doing the thing I don't want you to do," or attack their identity, or their job, or some other aspect of their life. Human behavior does not respond well to that generally, at least in my experience. +Like, having your identity tied up in a tool or a platform is, unfortunately, pretty common in, like, a tech space. Like, oh, like, Ruby on Rails is the best piece of software or something like that. And it's like, well, you might like it, and that might be the best thing for you. And personally, I really like Ruby on Rails. I think it does a great job of what it does. But as an example, I would not use Ruby on Rails to maybe build an iOS app. I could; I think that's possible, but I don't think that's maybe the best tool for that job. And so, trying to, again, meet people where they are. +STEPHANIE: I guess it kind of goes back to what you're saying. It's like, you want to help people do what they are trying to do. +EDWARD: Yeah. Maybe there's a little paternalistic thinking, too, of, like, what's good for the industry, even if it feels bad for you right now. I don't love that sort of paternalistic thinking. But if it's a real risk, it seems worth at least addressing or pointing out and letting people make that decision for themselves. +STEPHANIE: Yeah, absolutely. I am actually kind of curious about how do you, like, decide something for yourself? You know, like, how do you form your own opinion about technology? I think, yeah, like, a lot of people take GitHub for granted. They use it because that's just what's used, and that may or may not be a good reason for doing so. +But that was a position I was in for a long time, right? You know, especially when you're newer to the industry, you're like, oh, well, this is what the company uses, or this is what, like, the industry uses. But, like, how do you start to figure out for yourself, like, do I actually like this? Does this help me meet my goals and needs? Is it doing what I want it to be doing? Do you have any thoughts about that? +EDWARD: Yeah. I imagine most people listening to this have tried lots of different pieces of software and found them great, or terrible, or somewhere in between. And I don't think there's necessarily one way to do this. But I think my way has been to try lots of things, unsurprisingly, and evaluate them based on the thing that I'm trying to do. +Sometimes I'll go into a new field, or a new area, or a new product, or whatever, and you just sort of use what's there, or what people have told you about, or what you heard about last, and that's fine. That's a great place to start, right? And then you start seeing maybe where it falls down, or where it is frustrating or doesn't quite meet those needs. And it takes a bit of stepping back. +Again, I don't think I'm, like, going to blow anyone's mind here by this amazing secretive technique that I have for, like, discovering good software. But it's, like, sitting there and going through this iterative loop of try it, evaluate it. Be honest with, is it meeting or not meeting some particular needs? And then try something else. Or now you have a little more info to arm yourself to get to the next piece that is potentially good. +As you go on in your career and you've tried many, many, many pieces of things, you start to see patterns, right? And you know, like, oh, it's not like, oh, this is how I make websites. It's like, ah, I understand that websites are made with a combination of HTML, and CSS, and JavaScript and sometimes use frameworks. And there's a database layer with an ORM. And you start to understand all the different parts. And now that you have those keywords and those pieces a little more under your control or you have more experience with them, you can use all that experience to then seek out particular pieces. +I'm looking for an ORM that's built with Rust because that's the thing I need to do it for; that's the platform I need to work with. And I needed to make sure that it supports MySQL and Postgres, right? Like, it's a very targeted thing that you wouldn't know when you're starting out. But over years of experience, you understand the difference and the reasons why you might need something like that. +And sometimes it's about kind of evaluating options and maybe making little test projects to play around with those things or side projects. That's why something like investment time or 20% time is so helpful and useful for that if you're the kind of person who, you know, enjoys programming on your own in your own free time like I am. And that's also a great time to do it, although it's certainly not required. And so, that's kind of how I go through and evaluate whatever tool it is that I need. +For something maybe more professional or higher stakes, there's a little more evaluation upfront, right? You want to make sure you make the right choice before you spend thousands of hours using it and potentially regretting [laughs] it and having to roll it back, causing even more thousands of hours of time. So, there's obviously some scrutiny there. But, again, that also takes experience and understanding the kind of need that you have. +So, yeah, it's kind of a trade-off of, like, your time, and your energy, and your experience, and your interest. You will have many different inputs from colleagues, from websites, from posts on the internet, from Twitter, or fediverse-type kind of blogging and everything in between, right? So, you take all that in, and you try a bunch of stuff, and you come out on the other side, and then you do it again. +STEPHANIE: Yeah, it sounds like you really like to just experiment, and I think that's really great. And I actually have to say that I am not someone who likes to do that [laughs]. Like, it's not where I focus a lot of my time. And it's why I'm, like, glad I'm friends with you, first of all. +EDWARD: [laughs] +STEPHANIE: But also, I've realized I'm much more of, like, a gatherer in terms of information and opinions. Like, I like hearing about other people's experience to then, like, help inform an opinion that I might develop myself. And, you know, it's not to say that, like, I am, like, oh yeah, like, so and so said this, and so, therefore, yeah, I completely believe what they have to say. +But as someone who does not particularly want to spend a ton of my time trying out things, it is really helpful to know people who do like to do that, know people who I do trust, right? And then kind of like you had mentioned, just, like, having all these different inputs. +And one thing that has changed for me with more experience is, previously, a lot of, like, the basis of what I thought was the quote, unquote, "right way" to develop software was, like, asking, like, other people and, you know, their opinions becoming my own. And, you know, at some point, though, that, like, has shifted, right? Where it's like, oh, like, you know, I remember learning this from so and so, and, like, actually, I think I disagree now. +Or maybe it's like, I will take one part of it and be like, yeah, I really like test-driven development in this particular way that I have figured out how I do it, but it is different still from, like, who I learned it from. And even though, like, that was kind of what I thought previously as, like, oh yeah, like, this is the way that I've adopted without room for adjustment. +I think that has been a growth, I guess, that I can point to and be like, oh yeah, like, I once was in a position where maybe opinions weren't necessarily my own. But now I spend a lot more time thinking about, like, oh, like, how do I feel about this? And I think there is, like, some amount of self-reflection required, right? A lot, honestly. Like, you try things, and then you think about, like, did I like that? [laughs] One without the other doesn't necessarily fully informed opinion make. +EDWARD: Yeah, absolutely. I mean, I'm really glad you brought up that, like, you've heard an opinion, or a suggestion, or an idea from somebody, and you kind of adopt it as your own for a little bit. I like to think of it as trying on ideas like you try on clothing. Or something like, let me try on this jacket. Does this fit? And maybe you like it a little bit. Or maybe you look ridiculous, and it's [laughs] not quite for you. And you don't feel like it's for you. But you have to try. You have to, like, actually do it. +And that is a completely valid way to, like, kick-starting some of those opinions, getting input from friends or colleagues, or just the world around you. And, like, hearing those things and trying them is 100% valid. And I'm glad you mentioned that because if I mentioned it, I think I kind of skipped over it or went through it very quickly. So, absolutely. And you're talking about how you just take, like, one part of it maybe. That nuance, that is, I think, really critical to that whole thought, too. +Everything works differently for different people. And every tool is good for other, like, different jobs. Like, it will be like saying a hammer is the best tool, and it's, like, well, it's a good tool for the right thing. But, like, I wouldn't use a hammer to, like, I don't know, level the new house numbers I put on my house, right? But I might use them to, like, hit the nail to get them in. So, it's a silly analogy, but, like, there is always nuance and different ways to apply these different tools and opinions. +STEPHANIE: I like that analogy. I think it would be really funny if there was someone out there who claimed that the hammer is the best tool ever invented [laughs]. +EDWARD: Oh, I'm sure. I'm sure there is, you know. I'm not going to use a drill to paint my house, though [laughs]. +STEPHANIE: That's a fair point, and you don't have to [chuckles]. +EDWARD: Thank you [laughs]. +STEPHANIE: But, I guess, to extend this thought further, I completely and wholeheartedly agree that, like, yeah, everyone gets to decide for themselves what works for them. But also, we work in relation with others. And I'm very interested in the balance of having your own ideas and opinions about tooling, software practices, like, whatever, and then how to bring that back into, like, working on a team or, like, working with others. +EDWARD: Yeah. Well, I don't know if this is exactly what you're asking, but it makes me think of: you've gone off; you've discovered a whole bunch of stuff that you think works really well for you. And then you go to work, or you go to a community that is using a very different way of working, or different tools, or different technologies. +That can be a piece of friction sometimes of, like, "Oh my gosh, I love Ruby on Rails. It's the best." And someone else is like, "I really, really don't like Ruby on Rails for reasons XYZ. And we don't use it here." And that can be really tough and, honestly, sometimes even disheartening, depending on how strongly you feel about that tool and how strongly they feel about their tools. +And as a young developer many years ago, I definitely had a lot more of my identity wrapped up in the tools and technologies that I used. And that has been very useful to try to separate those two. I don't claim to be perfect at it or done with that work yet. But the more I can step away and say, you know, like, this is only a tool. It is not the tool. It is not the best tool. It is a tool that can be very effective at certain things. And I've found, at least right now, the more useful thing is to get to the root of the problem you're trying to solve and make sure you agree with everybody on that premise. +So, yes, you may have come from a world where fast iteration and a really fluent language interface like Ruby has and a really fast iteration cycle like Rails has, is, like, the most important need to be solved because other things have been solved. You understand what you're doing for your product, or maybe you need to iterate quickly on that product. You've figured out an audience. You're getting payroll. You're meeting all that as a business. +But then you go into a business that's potentially, like, let's say, much less funded. Or they have their market fit, and now they're working on, like, extreme performance optimization, or they're working on getting, like, government compliance, or something like that. And maybe Rails is still great. This is maybe a...the analogy may fall apart here. But let's pretend it isn't for some reason. You have to agree that, hey, like, yes, we've solved problem X that Rails really helps you solve. And now we're moving on to problem Y, and Rails may not help you solve that, or whatever technology you're using may not help you solve that. +And I've found it to be much more useful to stop worrying about the means, and the tools, the things in between, and worry about the ends, worry about the goal, worry about the problems you're actually trying to solve. And then you can feel really invested in trying to solve that problem together as a group, as a team, as a community. I've found that to be very helpful. +And I would also like to say it is extremely difficult to let some of that stuff go. It takes a lot of work. I see you nodding along. Like, it's really, really hard. And, like I said, I'm not totally done with it either. But that's, I think, it's something I'm really working on now and something I feel really strongly about. +STEPHANIE: Yeah. You mentioned the friction of, like, working in an environment where there are different opinions, which is, you know, I don't know, just, like, reality, I guess [laughs]. +EDWARD: Human nature. +STEPHANIE: Yeah, exactly. And one thing I was thinking about recently was, like, okay, like, so someone else maybe made a decision about using a type of technology or, like, made a decision about architecture before my time or, like, above me, or whatever, right? Like, I wasn't there, and that is okay. But also, like, how do I maintain what I believe in and hold fast to, like, my opinions based on my value system, at least, without complaining? [laughs] +Because I've only seen that a little bit before, right? When it just becomes, like, venting, right? It's like, ugh, like, you know, I have seen people who are coming from maybe, like, microservices or more of a JavaScript world, and they're like, ugh, like, what is going on with Rails? Like, this sucks [laughs]. +And one thing I've been trying lately is just, like, communicating when I don't agree that something's a great idea. But also, like, acknowledging that, like, yeah, but this is how it is for this team, and I'm also not in a position to change it. Or, like, I don't feel so strongly about it that I'm like, "Hey, we should totally rethink using this, like, background job [laughs] platform." +But I will be like, "Hey, like, I don't like this particular thing about it. And, you know, maybe here are some things that I did to mitigate whatever thing I'm not super into," or, like, "If I had more time, this is what I would do," and just putting it out there. Sometimes, I don't get, like, engagement on it. But it's a good practice for me to be, like, this is how I can still have opinions about things, even if I'm not, at least in this particular moment, in a position to change anything. +EDWARD: It sounds to me like you in, at least at the lowest level, like, you want to be acknowledged, and you want to, like, be heard. You want to be part of a process. And yes, it doesn't always go with Stephanie's initial thought, or even final thought, or Edward's final thought. But it is very helpful to know that you are heard and you are respected. And it isn't someone just, like, completely disregarding any feeling that you have. +As much as we like to say programming is this very, like, I don't know, value neutral, zero emotion kind of job, like, there's tons of emotion in this job. We want to do good things for the world. We want our technology to serve the people, ultimately, at least I do, and I know you do. But we sometimes disagree on the way to do that. +And so, you want to make sure you're heard. And if you can't get that at work, like, and I know you do this, but I would encourage anyone listening out there to, like, get a buddy that you can vent to or get somebody that you can express, and they will hear you. That is so valuable just as a release, in some ways, to kind of get through what you need to get through sometimes. Because it is a job, and you aren't always the person that's going to make the decisions. +And, honestly, like, you do still have one decision left, which is you can go work somewhere else if it really is that bad. And, like, it's useful to know that you are staying where you are because you appreciate the trade-offs that you have: a steady paycheck, or the colleagues that you work with, or whatever. And that's fine. That's an okay trade-off. And at some point, you might want to make a different trade-off, and that's also fine. We're getting real managery and real here. But I think it's useful. Like you said, this can be a very emotional career, and it's worth acknowledging that. +STEPHANIE: Yeah, you just, you know, raised a bunch of, like, very excellent points. Yeah, at the end of the day, like, you know, you can do your best to, like, propose changes or, like, introduce new tooling and, like, see how other people feel about it. But, like, yeah, if you fundamentally do not enjoy working with a critical tool that, you know, a lot of the foundation of the work that you're doing day to day is built off of, then maybe there is a place where, like, another company that's using tools that you do feel excited or, like, passionate or, like, are a better alignment with what you hope to be doing. +Kind of just going back to that theme that we were talking about earlier, like, everyone gets to decide for themselves, right? Like, the tools to help them do what they want to be doing. +EDWARD: And you could even, like, reframe it for yourself, where instead of it being about the tools, maybe it's about the problem. Like, you start being more invested in, like, the problem that you're solving and, okay, maybe you don't want to use microservices or whatever, but, like, maybe you can get behind that if you realign yourself. The thing you're trying to solve is not the tool. The thing you're trying to solve is the problem. And that can be a useful, like, way to mitigate that or to, like, help yourself feel okay about the thing, whatever that is. +STEPHANIE: Yeah. Now, how do I have this conversation with everyone [laughter] who claims on the internet that X is the solution to all their problems or the silver bullet, [laughs] or whatever? +EDWARD: Yeah, that's tough because there are some very strong opinions on the internet, as I'm sure [laughs] you've observed. I don't know if I have the answer [laughs]. Once again, nuance and indecisions. +I have been currently approaching it from kind of a meta-perspective of, like, if someone says, "X is the best tool," you know, "A hammer is the best tool," right? I'm not going to go write the post that's like, "No, hammer is, in fact, not the best tool. Don't use hammers." I would maybe instead write a post that's like, "Consider what makes the best tool." I've effectively, like, raised up one level of abstraction from, we're no longer talking about is X, or Y, or Z, the best tool? We're talking about how do we even decide that? How do we even think about that? +One post...I'm now just promoting my blog posts, so get ready. But one thing I wrote was this post called And Not But. And I tried to make the case that instead of saying the word but in a sentence, so, like, yeah, yeah, we might want to use hammers, but we have to use drills or whatever. I'm trying to make the case that you can use and instead. So yeah, hammers are really good, and drills are really good in these other scenarios. +And trying to get that nuance in there, like, really, really putting that in there and getting people to, like, feel that better, I think, has been really helpful, for me, certainly to get through. And part of the best thing about writing a blog post is just getting your own thoughts...I mean, it's another way to vent, right? It's getting your own thoughts out somewhere. +And sometimes people respond to them. You'd be surprised who just reaches out and been like, "Hey, yeah, like, I really appreciated that post. That was really great." You weren't trying to reach that person, but now you have another connection. So, a side benefit for writing blog posts [inaudible 30:17] do it, or just even getting your thoughts out via a podcast, via a video, whatever. So, I've kind of addressed that. +I also wrote a post when I worked at thoughtbot called Empathy Online. And that came out of, like, frustration with seeing people being too divisive or, in my opinion, unempathetic or inconsiderate. And instead of, again, trying to just say, "Stop it, don't do that," [laughs] but trying to, like, help use what I have learned when communicating in a medium that is kind of inherently difficult to get across emotion and empathy. +And so, again, it's, in some ways, unsatisfying because what you really want to do is go talk to that person that says, "Hammer is the best tool," and say, "No, stop it [laughs]," and, like, slap them on the head or whatever, politely. But I think that probably will not get you very far. And so, if your goal, really, is to change the way people think about these things, I find it way more effective to, like, zoom out and talk about that on that sort of more meta-level and that higher level. +STEPHANIE: Yeah. I liked how you called it, like, a higher level of abstraction. And, honestly, the other thing I was thinking about as you were talking about the, like, divisiveness that opinions can create, there's also some aspect of it, as a reader, realizing that one person sharing their opinion does not take away your ability to have a differing opinion [laughs]. +And sometimes it's tough when someone's like, "Tailwind sucks [laughs], and it is a backward step in, you know, how we write CSS," or whatever. Yes, like, sometimes that can be kind of, like, inflammatory. But if you, like, kind of are translating it or, like, reading between the lines, they're just writing about their perspective from the things that they value. And it is okay for you to value different things and, for that reason, have a different perspective on the same thing. +And, I don't know, that has helped me sometimes avoid getting into that, like, headspace of wanting to argue with someone [laughs] on the internet. Or they'll be like, "This is why I am right." [laughs] Now I have to write something and share it on the internet in response [laughs]. +EDWARD: There's this idea of the narcissism of minor differences. And I believe the idea is this, like, you know, you're more likely to argue with someone who, like, 90% agrees with you. But you're just, like, quibbling over that last 10%. I mean, one might call it bikeshedding. I don't know if you've heard that phrase. +But the thing that I have often found, too, is that, like the GitHub post, I will get people arguing with me, like, there's the kind of stuff I expected, where it's like, "Oh, but GitHub is really good," and XYZ and that's fine. And we can have that conversation. But it's kind of surprising, and I should have expected it, that people will sometimes be like, "Hey, you didn't go far enough. You should tell people to, like, completely delete their GitHub or, like, you know, go protest in the street." And, like, maybe that's true. I'm not saying it is or isn't. +But I think one thing I try to think about is, in any post, in any trying convincing argument, like, you're potentially moving someone 1 step forward, even if there's ten steps to go. But they're never going to make those ten steps if they don't make the first 1. And so, you can kind of help them get there. And someone else's post can absolutely take them from step 5 to 6 or 6 to 7 or 7 to 8. And you won't accomplish it all at once, and it's kind of a silly thing to try, and your efforts are probably lost [laughs]. +Unfortunately, it's a little bit of preaching to the choir because, like, yeah, the people that are going to respond to, like, the extreme, the end are, like, the people that already get it. And the people that you're trying to convince and move along are not going to get that thing. I do want to say that I could see this being perceived as, like, a very privileged position of, like, if there's some, like, genuine atrocity happening in the world, like, it is appropriate to go to extremes many times and sometimes, and that's fine, and people are allowed to be there. I don't want to invalidate that. It's a really tricky balance. +And I'm trying to say that if your goal is to vent, that's fine. And if your goal is to move people from step 3 to 4, you have to meet people at step 3. And all that's valid and okay to try to help people move in that way. But it is very tricky. And I don't want to invalidate someone who's extremely frustrated because they're at step 10, and no one else is seeing the harm that not everybody else being at step 10 is. Like, that's an incredibly reasonable place to be and an okay place to be. +STEPHANIE: Yeah, yeah. The other thing you just sparked, for me, is also the, like, power of, yeah, being able to say like, "Yeah, I agree with this 50%, or 60%, or, like, 90%." And also, there's this 10% that I'm like, oh, like, I wish were different, or I wish they'd gone further, or I wish they didn't say that. Or, you know, I just straight up disagree with this step 1 sentence, but the rest of the article, you know, I really related to. +And, like, teasing that apart has been very useful for me, right? Because then I'm no longer like being like, oh, was this post good or bad? Do I agree with it or don't agree with it? It's like, there's room for [laughs] all of it. +EDWARD: Yeah, that's that nuance that, you know, I liked this post, and I did not agree with these two parts of it, or whatever. It's so useful. +STEPHANIE: Well, thanks, Edward, so much for coming on the show and bringing that nuance to this conversation. I feel really excited about kind of what we talked about, and hopefully, it resonates with some of our listeners. +EDWARD: Yeah, I hope so too. I hope I can take them from step 2 to step 3 [laughs]. +STEPHANIE: On that note, shall we wrap up? +EDWARD: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Stephanie interviews Edward Loveall, a former thoughtbotter, now software developer at Relevant Healthcare.

+ +

Part of their discussion centers around Edward's blog post on the tech industry's over-reliance on GitHub. He argues for the importance of exploring alternatives to avoid dependency on a single platform and encourages readers to make informed technological choices. The conversation broadens to include how to form opinions on technology, the balance between personal preferences and team decisions, and the importance of empathy and nuance in professional interactions. Both Stephanie and Edward highlight the value of considering various perspectives and tools in software development, advocating for a flexible, open-minded approach to technology and problem-solving in the tech industry.

+ +
+ + + +

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. And today, I'm joined by a very special guest, a friend of the pod and former thoughtboter, Edward Loveall.

+ +

EDWARD: Hello, thanks for having me.

+ +

STEPHANIE: Edward, would you share a little bit about yourself and what you're doing these days?

+ +

EDWARD: Yes, I am a software developer at a company called Relevant Healthcare. We do a lot of things, but the maybe high-level summary is we take very complicated medical data and help federally-funded health centers actually understand that data and help their population's health, which is really fun and really great.

+ +

STEPHANIE: Awesome. So, Edward, what is new in your world?

+ +

EDWARD: Let's see, this weekend...I live in a dense city. I live in Cambridge, Massachusetts, and it's pretty dense there. And a lot of houses are very tightly packed. And delivery drivers struggle to find the numbers on the houses sometimes because A, they're old and B, there is many of them.

+ +

And so, we put up house numbers because I live in, like, a three-story kind of building, but there are two different addresses in the same three stories, which is very weird. And so [laughs], delivery drivers are like, "Where is number 10 or 15?" or whatever. And so, there's two different numbers. And so, we finally put up numbers after living here for, like, four years [chuckles]. So, now, hopefully, delivery drivers in the holiday busy season will be able to find our house [laughs].

+ +

STEPHANIE: That's great. Yeah, I have kind of a similar problem where, a lot of the times, delivery folks will think that my house is the big building next door. And the worst is those at the building next door they drop off their packages inside the little, like, entryway that is locked for people who don't live there. And so, I will see my package in the window and, you know, it has my name on it. It has, like, my address on it.

+ +

And [laughs] some strategies that I've used is leaving a note on the door [laughter] that is, like, "Please redeliver my package over there," and, like, I'll draw an arrow to the direction of my house. Or sometimes I've been that person to just, like, buzz random [laughter] units and just hope that they, like, let me in, and then I'll grab my package. And, you know, if I know the neighbors, I'll, like, try to apologize the next time I see them. But sometimes I'll just be like, I just need to get my package [laughs].

+ +

EDWARD: You're writing documentation for those people working out in the streets.

+ +

STEPHANIE: Yeah. But I'm glad you got that sorted.

+ +

EDWARD: Yeah. What about you? What's new in your world?

+ +

STEPHANIE: Well, I wanted to talk a little bit about a thing that you and I have been doing lately that I have been enjoying a lot. First of all, are you familiar with the group chat trend these days? Do you know what I'm talking about?

+ +

EDWARD: No.

+ +

STEPHANIE: Okay. It's basically this idea that, like, everyone is just connecting with their friends via a group chat now as opposed to social media. But as a person who is not a big group chat person, I can't, like, keep up with [chuckles], like, chatting with multiple people [laughter] at once. I much prefer, like, one-on-one interaction.

+ +

And, like, a month ago, I asked you if you would be willing to try having a shared note, like, a shared iOS note that we have for items that we want to discuss with each other but, you know, the next time we either talk on the phone or, I don't know, things that are, like, less urgent than a text message would communicate but, like, stuff that we don't want to forget.

+ +

EDWARD: Yeah. You're, like, putting a little message in my inbox and vice versa. And yeah, we get to just kind of, whenever we want, respond to it, or think about it, or use it as a topic for a conversation later.

+ +

STEPHANIE: Yeah. And I think it is kind of a playbook from, like, a one-on-one with a manager. I know that that's, like, a strategy that some folks use. But I think it works well in the context of our friendship because it's just gotten, like, richer over time. You know, maybe in the beginning, we're like, oh, like, I don't know, here are some random things that I've thought about. But now we're having, like, whole discussions in the note [laughter]. Like, we will respond to each other, like, with sub-bullets [laughs]. And then we end up not even needing to talk about it on the phone because we've already had a whole conversation about it in the note.

+ +

EDWARD: Which is good because neither of us are particularly brief when talking on the phone. And [laughs] we only dedicate, like, half an hour every two weeks. It sort of helps clear the decks a little.

+ +

STEPHANIE: Yeah, yeah. So, that's what I recommend. Try a shared note for [laughs] your next friendship hangout.

+ +

EDWARD: Yeah, it's great. I heartily recommend it.

+ +

STEPHANIE: So, one of the things that we end up talking about a lot is various things that we've been reading about tech on the web [laughs]. And we share with each other a lot of, like, blog posts, or articles, various links, and recently, something of yours kind of resurfaced. You wrote a blog post about GitHub a little while ago about how, you know, as an industry, we should make sure that GitHub doesn't become our only option.

+ +

EDWARD: Yeah, this was a post I wrote, I think, back in May, or at least earlier this year, and it got a bunch of traction. And it's a somewhat, I would say, controversial article or take. GitHub just had their developer conference, and it resurfaced again.

+ +

And I don't have a habit of writing particularly controversial articles, I don't think. Most of my writing history has been technical posts like tutorials. Like, I wrote a whole tutorial on how to write SQL, or I did write one about how to communicate online. But I wasn't, like, so much responding to, like, a particular person's communication or a company's communication.

+ +

And this is the first big post I've written that has been a lot more very heavily opinionated, very, like, targeted at a particular thing or entity, I guess you'd say. It's been received well, I think, mostly, and I'm proud of it. But it's a different little world for me, and it's a little scary, honestly.

+ +

STEPHANIE: Yeah, I hear that, having an opinion [laughs], a very strong and maybe, like, a less popular opinion, and publishing that for the world. Could you recap what the thesis of it is for our listeners?

+ +

EDWARD: Yeah, and I think you did a great job of it, too. I see GitHub or really any singular piece of technology that we have in...I'll say our stack with air quotes, but it's, you know, all the tools that we use and all the things that we use. It's a risk if you only have one of those things, let's say GitHub. Like, if the only way you know how to contribute to a code repository with, you know, 17 people all committing to that repository, if the only way you know how to do that is a pull request and GitHub goes away, and you don't have pull requests anymore, how are you going to contribute to code?

+ +

It's not that you couldn't figure it out, or there aren't multiple ways or even other pull request equivalents on other sites. But it is a risk to rely on one company to provide all of the things that you potentially need, or even many of the things that you potentially need, without any alternatives.

+ +

So, I wanted to try to lay out A: those risks, and B: encourage people to try alternatives, to say that GitHub is not necessarily bad, although they may not actually fit what you need for various reasons, or someone else for various reasons. But you should have an alternative in your back pocket so that in case something changes, or you get locked out, or they go away, or they decide to cancel that feature, or any number of other scenarios, you have greatly diminished that risk. So, that's the main thrust of the post.

+ +

STEPHANIE: Yeah, I really appreciated it because, you know, I think a lot of us probably take GitHub for granted [laughs]. And, you know, every new thing that they kind of add to the platform is like, oh, like, cool, like, I can now do this. In the post, you kind of lay out all of the different features that GitHub has rolled out over the last, you know, couple of years. And when you see it all like that, you know, like, in addition to being, like, a code repository, you now have, like, GitHub Actions for CI/CD, you know, you can deploy static pages with it.

+ +

It now has, like, an in-browser editor, and then, you know, Copilot, which, like, the more things that they [laughs] roll out, the more it's becoming, like, the one-stop shop, right? That, like, do all of your work here. And I appreciated kind of, like, seeing that and being like, oh, like, is this what I want?

+ +

EDWARD: Right. Yeah, exactly. Yeah. And you mentioned a bunch. There's also issues and discussions. You mentioned their in-browser editor. But so many people use VS Code, which, while it was technically made by Microsoft, it's based on Electron, which was developed at GitHub. And GitHub even, like, took away their other Electron-based editor, Atom. And then now officially recommends VS Code.

+ +

And everything from deploying all the way down to, like, thinking about and prioritizing features and editing the code and all of that pretty much could happen on GitHub. I think maybe the only thing they don't currently do is host non-static sites, maybe [laughs]. That's maybe about it. And who knows? Maybe they're working on that; as far as I know, they are, so...

+ +

STEPHANIE: Yeah, absolutely. You also mentioned one thing that I really liked about the content in the post was that you talked about alternatives to GitHub, even, like, alternatives to all of the different features that we mentioned. I guess I'm wondering, like, what were you hoping that a reader from your blog post, like, what they would get out of reading and, like, what they would take away from kind of sharing your opinion?

+ +

EDWARD: I wanted to try to meet people where I think they might be because I think a lot of people do use GitHub, and they do take it for granted. And they do sort of see it as this thing that they must use, or they want to use even, and that's fine. That's not necessarily a bad thing. I want them to see those alternatives and have at least some idea that there is something else out there, that GitHub doesn't become just not only the default, but, like, the only thing.

+ +

I mean, to just [chuckles] re-paraphrase the title of the post, I want to make sure GitHub does not become the only option, right? I want people to realize that there are other options out there and be encouraged to try them. And I have found, for me, at least, the better way to do that is not to only focus on, like, hey, don't use GitHub. Like, I hope people did not come away with only that message or even that message at all. But that it is more, hey, maybe try something else out and to encourage you to try something out.

+ +

I'm going to A: share the risks with you and B: give you some actual things to try. So, I talk about the things I'm using and some other platforms and different paradigms to think about and use. So, I hope they take those. We'll see what happens in the next, you know, months or years. And I'll probably never know if it was actually just from me or from many other conversations, and thoughts, and articles, and all that kind of stuff. But that's what it takes, so...

+ +

STEPHANIE: Yeah. I think the other fun thing about kind of the, like, meta-conversation we're having about having an opinion and, like, sharing it with the world is that you don't even really say like, "This is better than GitHub," or, like, kind of make a statement about, like, you shouldn't use...you don't even say, "You shouldn't use GitHub," right? The message is, like, here are some options: try it out, and, like, decide for yourself.

+ +

EDWARD: Yeah, exactly. I want to empower people to do that. I don't think it would have been useful if I'd just go and say, "Hey, don't do this." It's very frustrating to me to see posts that are only negatives. And, honestly, I've probably written those posts, like, I'm not above them necessarily.

+ +

But I have found that trying to help people do what you want them to do, as silly and maybe obvious as that sounds, is a more effective way to get them to do what you want them to do [laughs], as opposed to say, "Hey, stop doing the thing I don't want you to do," or attack their identity, or their job, or some other aspect of their life. Human behavior does not respond well to that generally, at least in my experience.

+ +

Like, having your identity tied up in a tool or a platform is, unfortunately, pretty common in, like, a tech space. Like, oh, like, Ruby on Rails is the best piece of software or something like that. And it's like, well, you might like it, and that might be the best thing for you. And personally, I really like Ruby on Rails. I think it does a great job of what it does. But as an example, I would not use Ruby on Rails to maybe build an iOS app. I could; I think that's possible, but I don't think that's maybe the best tool for that job. And so, trying to, again, meet people where they are.

+ +

STEPHANIE: I guess it kind of goes back to what you're saying. It's like, you want to help people do what they are trying to do.

+ +

EDWARD: Yeah. Maybe there's a little paternalistic thinking, too, of, like, what's good for the industry, even if it feels bad for you right now. I don't love that sort of paternalistic thinking. But if it's a real risk, it seems worth at least addressing or pointing out and letting people make that decision for themselves.

+ +

STEPHANIE: Yeah, absolutely. I am actually kind of curious about how do you, like, decide something for yourself? You know, like, how do you form your own opinion about technology? I think, yeah, like, a lot of people take GitHub for granted. They use it because that's just what's used, and that may or may not be a good reason for doing so.

+ +

But that was a position I was in for a long time, right? You know, especially when you're newer to the industry, you're like, oh, well, this is what the company uses, or this is what, like, the industry uses. But, like, how do you start to figure out for yourself, like, do I actually like this? Does this help me meet my goals and needs? Is it doing what I want it to be doing? Do you have any thoughts about that?

+ +

EDWARD: Yeah. I imagine most people listening to this have tried lots of different pieces of software and found them great, or terrible, or somewhere in between. And I don't think there's necessarily one way to do this. But I think my way has been to try lots of things, unsurprisingly, and evaluate them based on the thing that I'm trying to do.

+ +

Sometimes I'll go into a new field, or a new area, or a new product, or whatever, and you just sort of use what's there, or what people have told you about, or what you heard about last, and that's fine. That's a great place to start, right? And then you start seeing maybe where it falls down, or where it is frustrating or doesn't quite meet those needs. And it takes a bit of stepping back.

+ +

Again, I don't think I'm, like, going to blow anyone's mind here by this amazing secretive technique that I have for, like, discovering good software. But it's, like, sitting there and going through this iterative loop of try it, evaluate it. Be honest with, is it meeting or not meeting some particular needs? And then try something else. Or now you have a little more info to arm yourself to get to the next piece that is potentially good.

+ +

As you go on in your career and you've tried many, many, many pieces of things, you start to see patterns, right? And you know, like, oh, it's not like, oh, this is how I make websites. It's like, ah, I understand that websites are made with a combination of HTML, and CSS, and JavaScript and sometimes use frameworks. And there's a database layer with an ORM. And you start to understand all the different parts. And now that you have those keywords and those pieces a little more under your control or you have more experience with them, you can use all that experience to then seek out particular pieces.

+ +

I'm looking for an ORM that's built with Rust because that's the thing I need to do it for; that's the platform I need to work with. And I needed to make sure that it supports MySQL and Postgres, right? Like, it's a very targeted thing that you wouldn't know when you're starting out. But over years of experience, you understand the difference and the reasons why you might need something like that.

+ +

And sometimes it's about kind of evaluating options and maybe making little test projects to play around with those things or side projects. That's why something like investment time or 20% time is so helpful and useful for that if you're the kind of person who, you know, enjoys programming on your own in your own free time like I am. And that's also a great time to do it, although it's certainly not required. And so, that's kind of how I go through and evaluate whatever tool it is that I need.

+ +

For something maybe more professional or higher stakes, there's a little more evaluation upfront, right? You want to make sure you make the right choice before you spend thousands of hours using it and potentially regretting [laughs] it and having to roll it back, causing even more thousands of hours of time. So, there's obviously some scrutiny there. But, again, that also takes experience and understanding the kind of need that you have.

+ +

So, yeah, it's kind of a trade-off of, like, your time, and your energy, and your experience, and your interest. You will have many different inputs from colleagues, from websites, from posts on the internet, from Twitter, or fediverse-type kind of blogging and everything in between, right? So, you take all that in, and you try a bunch of stuff, and you come out on the other side, and then you do it again.

+ +

STEPHANIE: Yeah, it sounds like you really like to just experiment, and I think that's really great. And I actually have to say that I am not someone who likes to do that [laughs]. Like, it's not where I focus a lot of my time. And it's why I'm, like, glad I'm friends with you, first of all.

+ +

EDWARD: [laughs]

+ +

STEPHANIE: But also, I've realized I'm much more of, like, a gatherer in terms of information and opinions. Like, I like hearing about other people's experience to then, like, help inform an opinion that I might develop myself. And, you know, it's not to say that, like, I am, like, oh yeah, like, so and so said this, and so, therefore, yeah, I completely believe what they have to say.

+ +

But as someone who does not particularly want to spend a ton of my time trying out things, it is really helpful to know people who do like to do that, know people who I do trust, right? And then kind of like you had mentioned, just, like, having all these different inputs.

+ +

And one thing that has changed for me with more experience is, previously, a lot of, like, the basis of what I thought was the quote, unquote, "right way" to develop software was, like, asking, like, other people and, you know, their opinions becoming my own. And, you know, at some point, though, that, like, has shifted, right? Where it's like, oh, like, you know, I remember learning this from so and so, and, like, actually, I think I disagree now.

+ +

Or maybe it's like, I will take one part of it and be like, yeah, I really like test-driven development in this particular way that I have figured out how I do it, but it is different still from, like, who I learned it from. And even though, like, that was kind of what I thought previously as, like, oh yeah, like, this is the way that I've adopted without room for adjustment.

+ +

I think that has been a growth, I guess, that I can point to and be like, oh yeah, like, I once was in a position where maybe opinions weren't necessarily my own. But now I spend a lot more time thinking about, like, oh, like, how do I feel about this? And I think there is, like, some amount of self-reflection required, right? A lot, honestly. Like, you try things, and then you think about, like, did I like that? [laughs] One without the other doesn't necessarily fully informed opinion make.

+ +

EDWARD: Yeah, absolutely. I mean, I'm really glad you brought up that, like, you've heard an opinion, or a suggestion, or an idea from somebody, and you kind of adopt it as your own for a little bit. I like to think of it as trying on ideas like you try on clothing. Or something like, let me try on this jacket. Does this fit? And maybe you like it a little bit. Or maybe you look ridiculous, and it's [laughs] not quite for you. And you don't feel like it's for you. But you have to try. You have to, like, actually do it.

+ +

And that is a completely valid way to, like, kick-starting some of those opinions, getting input from friends or colleagues, or just the world around you. And, like, hearing those things and trying them is 100% valid. And I'm glad you mentioned that because if I mentioned it, I think I kind of skipped over it or went through it very quickly. So, absolutely. And you're talking about how you just take, like, one part of it maybe. That nuance, that is, I think, really critical to that whole thought, too.

+ +

Everything works differently for different people. And every tool is good for other, like, different jobs. Like, it will be like saying a hammer is the best tool, and it's, like, well, it's a good tool for the right thing. But, like, I wouldn't use a hammer to, like, I don't know, level the new house numbers I put on my house, right? But I might use them to, like, hit the nail to get them in. So, it's a silly analogy, but, like, there is always nuance and different ways to apply these different tools and opinions.

+ +

STEPHANIE: I like that analogy. I think it would be really funny if there was someone out there who claimed that the hammer is the best tool ever invented [laughs].

+ +

EDWARD: Oh, I'm sure. I'm sure there is, you know. I'm not going to use a drill to paint my house, though [laughs].

+ +

STEPHANIE: That's a fair point, and you don't have to [chuckles].

+ +

EDWARD: Thank you [laughs].

+ +

STEPHANIE: But, I guess, to extend this thought further, I completely and wholeheartedly agree that, like, yeah, everyone gets to decide for themselves what works for them. But also, we work in relation with others. And I'm very interested in the balance of having your own ideas and opinions about tooling, software practices, like, whatever, and then how to bring that back into, like, working on a team or, like, working with others.

+ +

EDWARD: Yeah. Well, I don't know if this is exactly what you're asking, but it makes me think of: you've gone off; you've discovered a whole bunch of stuff that you think works really well for you. And then you go to work, or you go to a community that is using a very different way of working, or different tools, or different technologies.

+ +

That can be a piece of friction sometimes of, like, "Oh my gosh, I love Ruby on Rails. It's the best." And someone else is like, "I really, really don't like Ruby on Rails for reasons XYZ. And we don't use it here." And that can be really tough and, honestly, sometimes even disheartening, depending on how strongly you feel about that tool and how strongly they feel about their tools.

+ +

And as a young developer many years ago, I definitely had a lot more of my identity wrapped up in the tools and technologies that I used. And that has been very useful to try to separate those two. I don't claim to be perfect at it or done with that work yet. But the more I can step away and say, you know, like, this is only a tool. It is not the tool. It is not the best tool. It is a tool that can be very effective at certain things. And I've found, at least right now, the more useful thing is to get to the root of the problem you're trying to solve and make sure you agree with everybody on that premise.

+ +

So, yes, you may have come from a world where fast iteration and a really fluent language interface like Ruby has and a really fast iteration cycle like Rails has, is, like, the most important need to be solved because other things have been solved. You understand what you're doing for your product, or maybe you need to iterate quickly on that product. You've figured out an audience. You're getting payroll. You're meeting all that as a business.

+ +

But then you go into a business that's potentially, like, let's say, much less funded. Or they have their market fit, and now they're working on, like, extreme performance optimization, or they're working on getting, like, government compliance, or something like that. And maybe Rails is still great. This is maybe a...the analogy may fall apart here. But let's pretend it isn't for some reason. You have to agree that, hey, like, yes, we've solved problem X that Rails really helps you solve. And now we're moving on to problem Y, and Rails may not help you solve that, or whatever technology you're using may not help you solve that.

+ +

And I've found it to be much more useful to stop worrying about the means, and the tools, the things in between, and worry about the ends, worry about the goal, worry about the problems you're actually trying to solve. And then you can feel really invested in trying to solve that problem together as a group, as a team, as a community. I've found that to be very helpful.

+ +

And I would also like to say it is extremely difficult to let some of that stuff go. It takes a lot of work. I see you nodding along. Like, it's really, really hard. And, like I said, I'm not totally done with it either. But that's, I think, it's something I'm really working on now and something I feel really strongly about.

+ +

STEPHANIE: Yeah. You mentioned the friction of, like, working in an environment where there are different opinions, which is, you know, I don't know, just, like, reality, I guess [laughs].

+ +

EDWARD: Human nature.

+ +

STEPHANIE: Yeah, exactly. And one thing I was thinking about recently was, like, okay, like, so someone else maybe made a decision about using a type of technology or, like, made a decision about architecture before my time or, like, above me, or whatever, right? Like, I wasn't there, and that is okay. But also, like, how do I maintain what I believe in and hold fast to, like, my opinions based on my value system, at least, without complaining? [laughs]

+ +

Because I've only seen that a little bit before, right? When it just becomes, like, venting, right? It's like, ugh, like, you know, I have seen people who are coming from maybe, like, microservices or more of a JavaScript world, and they're like, ugh, like, what is going on with Rails? Like, this sucks [laughs].

+ +

And one thing I've been trying lately is just, like, communicating when I don't agree that something's a great idea. But also, like, acknowledging that, like, yeah, but this is how it is for this team, and I'm also not in a position to change it. Or, like, I don't feel so strongly about it that I'm like, "Hey, we should totally rethink using this, like, background job [laughs] platform."

+ +

But I will be like, "Hey, like, I don't like this particular thing about it. And, you know, maybe here are some things that I did to mitigate whatever thing I'm not super into," or, like, "If I had more time, this is what I would do," and just putting it out there. Sometimes, I don't get, like, engagement on it. But it's a good practice for me to be, like, this is how I can still have opinions about things, even if I'm not, at least in this particular moment, in a position to change anything.

+ +

EDWARD: It sounds to me like you in, at least at the lowest level, like, you want to be acknowledged, and you want to, like, be heard. You want to be part of a process. And yes, it doesn't always go with Stephanie's initial thought, or even final thought, or Edward's final thought. But it is very helpful to know that you are heard and you are respected. And it isn't someone just, like, completely disregarding any feeling that you have.

+ +

As much as we like to say programming is this very, like, I don't know, value neutral, zero emotion kind of job, like, there's tons of emotion in this job. We want to do good things for the world. We want our technology to serve the people, ultimately, at least I do, and I know you do. But we sometimes disagree on the way to do that.

+ +

And so, you want to make sure you're heard. And if you can't get that at work, like, and I know you do this, but I would encourage anyone listening out there to, like, get a buddy that you can vent to or get somebody that you can express, and they will hear you. That is so valuable just as a release, in some ways, to kind of get through what you need to get through sometimes. Because it is a job, and you aren't always the person that's going to make the decisions.

+ +

And, honestly, like, you do still have one decision left, which is you can go work somewhere else if it really is that bad. And, like, it's useful to know that you are staying where you are because you appreciate the trade-offs that you have: a steady paycheck, or the colleagues that you work with, or whatever. And that's fine. That's an okay trade-off. And at some point, you might want to make a different trade-off, and that's also fine. We're getting real managery and real here. But I think it's useful. Like you said, this can be a very emotional career, and it's worth acknowledging that.

+ +

STEPHANIE: Yeah, you just, you know, raised a bunch of, like, very excellent points. Yeah, at the end of the day, like, you know, you can do your best to, like, propose changes or, like, introduce new tooling and, like, see how other people feel about it. But, like, yeah, if you fundamentally do not enjoy working with a critical tool that, you know, a lot of the foundation of the work that you're doing day to day is built off of, then maybe there is a place where, like, another company that's using tools that you do feel excited or, like, passionate or, like, are a better alignment with what you hope to be doing.

+ +

Kind of just going back to that theme that we were talking about earlier, like, everyone gets to decide for themselves, right? Like, the tools to help them do what they want to be doing.

+ +

EDWARD: And you could even, like, reframe it for yourself, where instead of it being about the tools, maybe it's about the problem. Like, you start being more invested in, like, the problem that you're solving and, okay, maybe you don't want to use microservices or whatever, but, like, maybe you can get behind that if you realign yourself. The thing you're trying to solve is not the tool. The thing you're trying to solve is the problem. And that can be a useful, like, way to mitigate that or to, like, help yourself feel okay about the thing, whatever that is.

+ +

STEPHANIE: Yeah. Now, how do I have this conversation with everyone [laughter] who claims on the internet that X is the solution to all their problems or the silver bullet, [laughs] or whatever?

+ +

EDWARD: Yeah, that's tough because there are some very strong opinions on the internet, as I'm sure [laughs] you've observed. I don't know if I have the answer [laughs]. Once again, nuance and indecisions.

+ +

I have been currently approaching it from kind of a meta-perspective of, like, if someone says, "X is the best tool," you know, "A hammer is the best tool," right? I'm not going to go write the post that's like, "No, hammer is, in fact, not the best tool. Don't use hammers." I would maybe instead write a post that's like, "Consider what makes the best tool." I've effectively, like, raised up one level of abstraction from, we're no longer talking about is X, or Y, or Z, the best tool? We're talking about how do we even decide that? How do we even think about that?

+ +

One post...I'm now just promoting my blog posts, so get ready. But one thing I wrote was this post called And Not But. And I tried to make the case that instead of saying the word but in a sentence, so, like, yeah, yeah, we might want to use hammers, but we have to use drills or whatever. I'm trying to make the case that you can use and instead. So yeah, hammers are really good, and drills are really good in these other scenarios.

+ +

And trying to get that nuance in there, like, really, really putting that in there and getting people to, like, feel that better, I think, has been really helpful, for me, certainly to get through. And part of the best thing about writing a blog post is just getting your own thoughts...I mean, it's another way to vent, right? It's getting your own thoughts out somewhere.

+ +

And sometimes people respond to them. You'd be surprised who just reaches out and been like, "Hey, yeah, like, I really appreciated that post. That was really great." You weren't trying to reach that person, but now you have another connection. So, a side benefit for writing blog posts [inaudible 30:17] do it, or just even getting your thoughts out via a podcast, via a video, whatever. So, I've kind of addressed that.

+ +

I also wrote a post when I worked at thoughtbot called Empathy Online. And that came out of, like, frustration with seeing people being too divisive or, in my opinion, unempathetic or inconsiderate. And instead of, again, trying to just say, "Stop it, don't do that," [laughs] but trying to, like, help use what I have learned when communicating in a medium that is kind of inherently difficult to get across emotion and empathy.

+ +

And so, again, it's, in some ways, unsatisfying because what you really want to do is go talk to that person that says, "Hammer is the best tool," and say, "No, stop it [laughs]," and, like, slap them on the head or whatever, politely. But I think that probably will not get you very far. And so, if your goal, really, is to change the way people think about these things, I find it way more effective to, like, zoom out and talk about that on that sort of more meta-level and that higher level.

+ +

STEPHANIE: Yeah. I liked how you called it, like, a higher level of abstraction. And, honestly, the other thing I was thinking about as you were talking about the, like, divisiveness that opinions can create, there's also some aspect of it, as a reader, realizing that one person sharing their opinion does not take away your ability to have a differing opinion [laughs].

+ +

And sometimes it's tough when someone's like, "Tailwind sucks [laughs], and it is a backward step in, you know, how we write CSS," or whatever. Yes, like, sometimes that can be kind of, like, inflammatory. But if you, like, kind of are translating it or, like, reading between the lines, they're just writing about their perspective from the things that they value. And it is okay for you to value different things and, for that reason, have a different perspective on the same thing.

+ +

And, I don't know, that has helped me sometimes avoid getting into that, like, headspace of wanting to argue with someone [laughs] on the internet. Or they'll be like, "This is why I am right." [laughs] Now I have to write something and share it on the internet in response [laughs].

+ +

EDWARD: There's this idea of the narcissism of minor differences. And I believe the idea is this, like, you know, you're more likely to argue with someone who, like, 90% agrees with you. But you're just, like, quibbling over that last 10%. I mean, one might call it bikeshedding. I don't know if you've heard that phrase.

+ +

But the thing that I have often found, too, is that, like the GitHub post, I will get people arguing with me, like, there's the kind of stuff I expected, where it's like, "Oh, but GitHub is really good," and XYZ and that's fine. And we can have that conversation. But it's kind of surprising, and I should have expected it, that people will sometimes be like, "Hey, you didn't go far enough. You should tell people to, like, completely delete their GitHub or, like, you know, go protest in the street." And, like, maybe that's true. I'm not saying it is or isn't.

+ +

But I think one thing I try to think about is, in any post, in any trying convincing argument, like, you're potentially moving someone 1 step forward, even if there's ten steps to go. But they're never going to make those ten steps if they don't make the first 1. And so, you can kind of help them get there. And someone else's post can absolutely take them from step 5 to 6 or 6 to 7 or 7 to 8. And you won't accomplish it all at once, and it's kind of a silly thing to try, and your efforts are probably lost [laughs].

+ +

Unfortunately, it's a little bit of preaching to the choir because, like, yeah, the people that are going to respond to, like, the extreme, the end are, like, the people that already get it. And the people that you're trying to convince and move along are not going to get that thing. I do want to say that I could see this being perceived as, like, a very privileged position of, like, if there's some, like, genuine atrocity happening in the world, like, it is appropriate to go to extremes many times and sometimes, and that's fine, and people are allowed to be there. I don't want to invalidate that. It's a really tricky balance.

+ +

And I'm trying to say that if your goal is to vent, that's fine. And if your goal is to move people from step 3 to 4, you have to meet people at step 3. And all that's valid and okay to try to help people move in that way. But it is very tricky. And I don't want to invalidate someone who's extremely frustrated because they're at step 10, and no one else is seeing the harm that not everybody else being at step 10 is. Like, that's an incredibly reasonable place to be and an okay place to be.

+ +

STEPHANIE: Yeah, yeah. The other thing you just sparked, for me, is also the, like, power of, yeah, being able to say like, "Yeah, I agree with this 50%, or 60%, or, like, 90%." And also, there's this 10% that I'm like, oh, like, I wish were different, or I wish they'd gone further, or I wish they didn't say that. Or, you know, I just straight up disagree with this step 1 sentence, but the rest of the article, you know, I really related to.

+ +

And, like, teasing that apart has been very useful for me, right? Because then I'm no longer like being like, oh, was this post good or bad? Do I agree with it or don't agree with it? It's like, there's room for [laughs] all of it.

+ +

EDWARD: Yeah, that's that nuance that, you know, I liked this post, and I did not agree with these two parts of it, or whatever. It's so useful.

+ +

STEPHANIE: Well, thanks, Edward, so much for coming on the show and bringing that nuance to this conversation. I feel really excited about kind of what we talked about, and hopefully, it resonates with some of our listeners.

+ +

EDWARD: Yeah, I hope so too. I hope I can take them from step 2 to step 3 [laughs].

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

EDWARD: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie interviews Edward Loveall, a former thoughtbotter, now software developer at Relevant Healthcare.

+ +

Part of their discussion centers around Edward's blog post on the tech industry's over-reliance on GitHub. He argues for the importance of exploring alternatives to avoid dependency on a single platform and encourages readers to make informed technological choices. The conversation broadens to include how to form opinions on technology, the balance between personal preferences and team decisions, and the importance of empathy and nuance in professional interactions. Both Stephanie and Edward highlight the value of considering various perspectives and tools in software development, advocating for a flexible, open-minded approach to technology and problem-solving in the tech industry.

+ +
+ + + +

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. And today, I'm joined by a very special guest, a friend of the pod and former thoughtboter, Edward Loveall.

+ +

EDWARD: Hello, thanks for having me.

+ +

STEPHANIE: Edward, would you share a little bit about yourself and what you're doing these days?

+ +

EDWARD: Yes, I am a software developer at a company called Relevant Healthcare. We do a lot of things, but the maybe high-level summary is we take very complicated medical data and help federally-funded health centers actually understand that data and help their population's health, which is really fun and really great.

+ +

STEPHANIE: Awesome. So, Edward, what is new in your world?

+ +

EDWARD: Let's see, this weekend...I live in a dense city. I live in Cambridge, Massachusetts, and it's pretty dense there. And a lot of houses are very tightly packed. And delivery drivers struggle to find the numbers on the houses sometimes because A, they're old and B, there is many of them.

+ +

And so, we put up house numbers because I live in, like, a three-story kind of building, but there are two different addresses in the same three stories, which is very weird. And so [laughs], delivery drivers are like, "Where is number 10 or 15?" or whatever. And so, there's two different numbers. And so, we finally put up numbers after living here for, like, four years [chuckles]. So, now, hopefully, delivery drivers in the holiday busy season will be able to find our house [laughs].

+ +

STEPHANIE: That's great. Yeah, I have kind of a similar problem where, a lot of the times, delivery folks will think that my house is the big building next door. And the worst is those at the building next door they drop off their packages inside the little, like, entryway that is locked for people who don't live there. And so, I will see my package in the window and, you know, it has my name on it. It has, like, my address on it.

+ +

And [laughs] some strategies that I've used is leaving a note on the door [laughter] that is, like, "Please redeliver my package over there," and, like, I'll draw an arrow to the direction of my house. Or sometimes I've been that person to just, like, buzz random [laughter] units and just hope that they, like, let me in, and then I'll grab my package. And, you know, if I know the neighbors, I'll, like, try to apologize the next time I see them. But sometimes I'll just be like, I just need to get my package [laughs].

+ +

EDWARD: You're writing documentation for those people working out in the streets.

+ +

STEPHANIE: Yeah. But I'm glad you got that sorted.

+ +

EDWARD: Yeah. What about you? What's new in your world?

+ +

STEPHANIE: Well, I wanted to talk a little bit about a thing that you and I have been doing lately that I have been enjoying a lot. First of all, are you familiar with the group chat trend these days? Do you know what I'm talking about?

+ +

EDWARD: No.

+ +

STEPHANIE: Okay. It's basically this idea that, like, everyone is just connecting with their friends via a group chat now as opposed to social media. But as a person who is not a big group chat person, I can't, like, keep up with [chuckles], like, chatting with multiple people [laughter] at once. I much prefer, like, one-on-one interaction.

+ +

And, like, a month ago, I asked you if you would be willing to try having a shared note, like, a shared iOS note that we have for items that we want to discuss with each other but, you know, the next time we either talk on the phone or, I don't know, things that are, like, less urgent than a text message would communicate but, like, stuff that we don't want to forget.

+ +

EDWARD: Yeah. You're, like, putting a little message in my inbox and vice versa. And yeah, we get to just kind of, whenever we want, respond to it, or think about it, or use it as a topic for a conversation later.

+ +

STEPHANIE: Yeah. And I think it is kind of a playbook from, like, a one-on-one with a manager. I know that that's, like, a strategy that some folks use. But I think it works well in the context of our friendship because it's just gotten, like, richer over time. You know, maybe in the beginning, we're like, oh, like, I don't know, here are some random things that I've thought about. But now we're having, like, whole discussions in the note [laughter]. Like, we will respond to each other, like, with sub-bullets [laughs]. And then we end up not even needing to talk about it on the phone because we've already had a whole conversation about it in the note.

+ +

EDWARD: Which is good because neither of us are particularly brief when talking on the phone. And [laughs] we only dedicate, like, half an hour every two weeks. It sort of helps clear the decks a little.

+ +

STEPHANIE: Yeah, yeah. So, that's what I recommend. Try a shared note for [laughs] your next friendship hangout.

+ +

EDWARD: Yeah, it's great. I heartily recommend it.

+ +

STEPHANIE: So, one of the things that we end up talking about a lot is various things that we've been reading about tech on the web [laughs]. And we share with each other a lot of, like, blog posts, or articles, various links, and recently, something of yours kind of resurfaced. You wrote a blog post about GitHub a little while ago about how, you know, as an industry, we should make sure that GitHub doesn't become our only option.

+ +

EDWARD: Yeah, this was a post I wrote, I think, back in May, or at least earlier this year, and it got a bunch of traction. And it's a somewhat, I would say, controversial article or take. GitHub just had their developer conference, and it resurfaced again.

+ +

And I don't have a habit of writing particularly controversial articles, I don't think. Most of my writing history has been technical posts like tutorials. Like, I wrote a whole tutorial on how to write SQL, or I did write one about how to communicate online. But I wasn't, like, so much responding to, like, a particular person's communication or a company's communication.

+ +

And this is the first big post I've written that has been a lot more very heavily opinionated, very, like, targeted at a particular thing or entity, I guess you'd say. It's been received well, I think, mostly, and I'm proud of it. But it's a different little world for me, and it's a little scary, honestly.

+ +

STEPHANIE: Yeah, I hear that, having an opinion [laughs], a very strong and maybe, like, a less popular opinion, and publishing that for the world. Could you recap what the thesis of it is for our listeners?

+ +

EDWARD: Yeah, and I think you did a great job of it, too. I see GitHub or really any singular piece of technology that we have in...I'll say our stack with air quotes, but it's, you know, all the tools that we use and all the things that we use. It's a risk if you only have one of those things, let's say GitHub. Like, if the only way you know how to contribute to a code repository with, you know, 17 people all committing to that repository, if the only way you know how to do that is a pull request and GitHub goes away, and you don't have pull requests anymore, how are you going to contribute to code?

+ +

It's not that you couldn't figure it out, or there aren't multiple ways or even other pull request equivalents on other sites. But it is a risk to rely on one company to provide all of the things that you potentially need, or even many of the things that you potentially need, without any alternatives.

+ +

So, I wanted to try to lay out A: those risks, and B: encourage people to try alternatives, to say that GitHub is not necessarily bad, although they may not actually fit what you need for various reasons, or someone else for various reasons. But you should have an alternative in your back pocket so that in case something changes, or you get locked out, or they go away, or they decide to cancel that feature, or any number of other scenarios, you have greatly diminished that risk. So, that's the main thrust of the post.

+ +

STEPHANIE: Yeah, I really appreciated it because, you know, I think a lot of us probably take GitHub for granted [laughs]. And, you know, every new thing that they kind of add to the platform is like, oh, like, cool, like, I can now do this. In the post, you kind of lay out all of the different features that GitHub has rolled out over the last, you know, couple of years. And when you see it all like that, you know, like, in addition to being, like, a code repository, you now have, like, GitHub Actions for CI/CD, you know, you can deploy static pages with it.

+ +

It now has, like, an in-browser editor, and then, you know, Copilot, which, like, the more things that they [laughs] roll out, the more it's becoming, like, the one-stop shop, right? That, like, do all of your work here. And I appreciated kind of, like, seeing that and being like, oh, like, is this what I want?

+ +

EDWARD: Right. Yeah, exactly. Yeah. And you mentioned a bunch. There's also issues and discussions. You mentioned their in-browser editor. But so many people use VS Code, which, while it was technically made by Microsoft, it's based on Electron, which was developed at GitHub. And GitHub even, like, took away their other Electron-based editor, Atom. And then now officially recommends VS Code.

+ +

And everything from deploying all the way down to, like, thinking about and prioritizing features and editing the code and all of that pretty much could happen on GitHub. I think maybe the only thing they don't currently do is host non-static sites, maybe [laughs]. That's maybe about it. And who knows? Maybe they're working on that; as far as I know, they are, so...

+ +

STEPHANIE: Yeah, absolutely. You also mentioned one thing that I really liked about the content in the post was that you talked about alternatives to GitHub, even, like, alternatives to all of the different features that we mentioned. I guess I'm wondering, like, what were you hoping that a reader from your blog post, like, what they would get out of reading and, like, what they would take away from kind of sharing your opinion?

+ +

EDWARD: I wanted to try to meet people where I think they might be because I think a lot of people do use GitHub, and they do take it for granted. And they do sort of see it as this thing that they must use, or they want to use even, and that's fine. That's not necessarily a bad thing. I want them to see those alternatives and have at least some idea that there is something else out there, that GitHub doesn't become just not only the default, but, like, the only thing.

+ +

I mean, to just [chuckles] re-paraphrase the title of the post, I want to make sure GitHub does not become the only option, right? I want people to realize that there are other options out there and be encouraged to try them. And I have found, for me, at least, the better way to do that is not to only focus on, like, hey, don't use GitHub. Like, I hope people did not come away with only that message or even that message at all. But that it is more, hey, maybe try something else out and to encourage you to try something out.

+ +

I'm going to A: share the risks with you and B: give you some actual things to try. So, I talk about the things I'm using and some other platforms and different paradigms to think about and use. So, I hope they take those. We'll see what happens in the next, you know, months or years. And I'll probably never know if it was actually just from me or from many other conversations, and thoughts, and articles, and all that kind of stuff. But that's what it takes, so...

+ +

STEPHANIE: Yeah. I think the other fun thing about kind of the, like, meta-conversation we're having about having an opinion and, like, sharing it with the world is that you don't even really say like, "This is better than GitHub," or, like, kind of make a statement about, like, you shouldn't use...you don't even say, "You shouldn't use GitHub," right? The message is, like, here are some options: try it out, and, like, decide for yourself.

+ +

EDWARD: Yeah, exactly. I want to empower people to do that. I don't think it would have been useful if I'd just go and say, "Hey, don't do this." It's very frustrating to me to see posts that are only negatives. And, honestly, I've probably written those posts, like, I'm not above them necessarily.

+ +

But I have found that trying to help people do what you want them to do, as silly and maybe obvious as that sounds, is a more effective way to get them to do what you want them to do [laughs], as opposed to say, "Hey, stop doing the thing I don't want you to do," or attack their identity, or their job, or some other aspect of their life. Human behavior does not respond well to that generally, at least in my experience.

+ +

Like, having your identity tied up in a tool or a platform is, unfortunately, pretty common in, like, a tech space. Like, oh, like, Ruby on Rails is the best piece of software or something like that. And it's like, well, you might like it, and that might be the best thing for you. And personally, I really like Ruby on Rails. I think it does a great job of what it does. But as an example, I would not use Ruby on Rails to maybe build an iOS app. I could; I think that's possible, but I don't think that's maybe the best tool for that job. And so, trying to, again, meet people where they are.

+ +

STEPHANIE: I guess it kind of goes back to what you're saying. It's like, you want to help people do what they are trying to do.

+ +

EDWARD: Yeah. Maybe there's a little paternalistic thinking, too, of, like, what's good for the industry, even if it feels bad for you right now. I don't love that sort of paternalistic thinking. But if it's a real risk, it seems worth at least addressing or pointing out and letting people make that decision for themselves.

+ +

STEPHANIE: Yeah, absolutely. I am actually kind of curious about how do you, like, decide something for yourself? You know, like, how do you form your own opinion about technology? I think, yeah, like, a lot of people take GitHub for granted. They use it because that's just what's used, and that may or may not be a good reason for doing so.

+ +

But that was a position I was in for a long time, right? You know, especially when you're newer to the industry, you're like, oh, well, this is what the company uses, or this is what, like, the industry uses. But, like, how do you start to figure out for yourself, like, do I actually like this? Does this help me meet my goals and needs? Is it doing what I want it to be doing? Do you have any thoughts about that?

+ +

EDWARD: Yeah. I imagine most people listening to this have tried lots of different pieces of software and found them great, or terrible, or somewhere in between. And I don't think there's necessarily one way to do this. But I think my way has been to try lots of things, unsurprisingly, and evaluate them based on the thing that I'm trying to do.

+ +

Sometimes I'll go into a new field, or a new area, or a new product, or whatever, and you just sort of use what's there, or what people have told you about, or what you heard about last, and that's fine. That's a great place to start, right? And then you start seeing maybe where it falls down, or where it is frustrating or doesn't quite meet those needs. And it takes a bit of stepping back.

+ +

Again, I don't think I'm, like, going to blow anyone's mind here by this amazing secretive technique that I have for, like, discovering good software. But it's, like, sitting there and going through this iterative loop of try it, evaluate it. Be honest with, is it meeting or not meeting some particular needs? And then try something else. Or now you have a little more info to arm yourself to get to the next piece that is potentially good.

+ +

As you go on in your career and you've tried many, many, many pieces of things, you start to see patterns, right? And you know, like, oh, it's not like, oh, this is how I make websites. It's like, ah, I understand that websites are made with a combination of HTML, and CSS, and JavaScript and sometimes use frameworks. And there's a database layer with an ORM. And you start to understand all the different parts. And now that you have those keywords and those pieces a little more under your control or you have more experience with them, you can use all that experience to then seek out particular pieces.

+ +

I'm looking for an ORM that's built with Rust because that's the thing I need to do it for; that's the platform I need to work with. And I needed to make sure that it supports MySQL and Postgres, right? Like, it's a very targeted thing that you wouldn't know when you're starting out. But over years of experience, you understand the difference and the reasons why you might need something like that.

+ +

And sometimes it's about kind of evaluating options and maybe making little test projects to play around with those things or side projects. That's why something like investment time or 20% time is so helpful and useful for that if you're the kind of person who, you know, enjoys programming on your own in your own free time like I am. And that's also a great time to do it, although it's certainly not required. And so, that's kind of how I go through and evaluate whatever tool it is that I need.

+ +

For something maybe more professional or higher stakes, there's a little more evaluation upfront, right? You want to make sure you make the right choice before you spend thousands of hours using it and potentially regretting [laughs] it and having to roll it back, causing even more thousands of hours of time. So, there's obviously some scrutiny there. But, again, that also takes experience and understanding the kind of need that you have.

+ +

So, yeah, it's kind of a trade-off of, like, your time, and your energy, and your experience, and your interest. You will have many different inputs from colleagues, from websites, from posts on the internet, from Twitter, or fediverse-type kind of blogging and everything in between, right? So, you take all that in, and you try a bunch of stuff, and you come out on the other side, and then you do it again.

+ +

STEPHANIE: Yeah, it sounds like you really like to just experiment, and I think that's really great. And I actually have to say that I am not someone who likes to do that [laughs]. Like, it's not where I focus a lot of my time. And it's why I'm, like, glad I'm friends with you, first of all.

+ +

EDWARD: [laughs]

+ +

STEPHANIE: But also, I've realized I'm much more of, like, a gatherer in terms of information and opinions. Like, I like hearing about other people's experience to then, like, help inform an opinion that I might develop myself. And, you know, it's not to say that, like, I am, like, oh yeah, like, so and so said this, and so, therefore, yeah, I completely believe what they have to say.

+ +

But as someone who does not particularly want to spend a ton of my time trying out things, it is really helpful to know people who do like to do that, know people who I do trust, right? And then kind of like you had mentioned, just, like, having all these different inputs.

+ +

And one thing that has changed for me with more experience is, previously, a lot of, like, the basis of what I thought was the quote, unquote, "right way" to develop software was, like, asking, like, other people and, you know, their opinions becoming my own. And, you know, at some point, though, that, like, has shifted, right? Where it's like, oh, like, you know, I remember learning this from so and so, and, like, actually, I think I disagree now.

+ +

Or maybe it's like, I will take one part of it and be like, yeah, I really like test-driven development in this particular way that I have figured out how I do it, but it is different still from, like, who I learned it from. And even though, like, that was kind of what I thought previously as, like, oh yeah, like, this is the way that I've adopted without room for adjustment.

+ +

I think that has been a growth, I guess, that I can point to and be like, oh yeah, like, I once was in a position where maybe opinions weren't necessarily my own. But now I spend a lot more time thinking about, like, oh, like, how do I feel about this? And I think there is, like, some amount of self-reflection required, right? A lot, honestly. Like, you try things, and then you think about, like, did I like that? [laughs] One without the other doesn't necessarily fully informed opinion make.

+ +

EDWARD: Yeah, absolutely. I mean, I'm really glad you brought up that, like, you've heard an opinion, or a suggestion, or an idea from somebody, and you kind of adopt it as your own for a little bit. I like to think of it as trying on ideas like you try on clothing. Or something like, let me try on this jacket. Does this fit? And maybe you like it a little bit. Or maybe you look ridiculous, and it's [laughs] not quite for you. And you don't feel like it's for you. But you have to try. You have to, like, actually do it.

+ +

And that is a completely valid way to, like, kick-starting some of those opinions, getting input from friends or colleagues, or just the world around you. And, like, hearing those things and trying them is 100% valid. And I'm glad you mentioned that because if I mentioned it, I think I kind of skipped over it or went through it very quickly. So, absolutely. And you're talking about how you just take, like, one part of it maybe. That nuance, that is, I think, really critical to that whole thought, too.

+ +

Everything works differently for different people. And every tool is good for other, like, different jobs. Like, it will be like saying a hammer is the best tool, and it's, like, well, it's a good tool for the right thing. But, like, I wouldn't use a hammer to, like, I don't know, level the new house numbers I put on my house, right? But I might use them to, like, hit the nail to get them in. So, it's a silly analogy, but, like, there is always nuance and different ways to apply these different tools and opinions.

+ +

STEPHANIE: I like that analogy. I think it would be really funny if there was someone out there who claimed that the hammer is the best tool ever invented [laughs].

+ +

EDWARD: Oh, I'm sure. I'm sure there is, you know. I'm not going to use a drill to paint my house, though [laughs].

+ +

STEPHANIE: That's a fair point, and you don't have to [chuckles].

+ +

EDWARD: Thank you [laughs].

+ +

STEPHANIE: But, I guess, to extend this thought further, I completely and wholeheartedly agree that, like, yeah, everyone gets to decide for themselves what works for them. But also, we work in relation with others. And I'm very interested in the balance of having your own ideas and opinions about tooling, software practices, like, whatever, and then how to bring that back into, like, working on a team or, like, working with others.

+ +

EDWARD: Yeah. Well, I don't know if this is exactly what you're asking, but it makes me think of: you've gone off; you've discovered a whole bunch of stuff that you think works really well for you. And then you go to work, or you go to a community that is using a very different way of working, or different tools, or different technologies.

+ +

That can be a piece of friction sometimes of, like, "Oh my gosh, I love Ruby on Rails. It's the best." And someone else is like, "I really, really don't like Ruby on Rails for reasons XYZ. And we don't use it here." And that can be really tough and, honestly, sometimes even disheartening, depending on how strongly you feel about that tool and how strongly they feel about their tools.

+ +

And as a young developer many years ago, I definitely had a lot more of my identity wrapped up in the tools and technologies that I used. And that has been very useful to try to separate those two. I don't claim to be perfect at it or done with that work yet. But the more I can step away and say, you know, like, this is only a tool. It is not the tool. It is not the best tool. It is a tool that can be very effective at certain things. And I've found, at least right now, the more useful thing is to get to the root of the problem you're trying to solve and make sure you agree with everybody on that premise.

+ +

So, yes, you may have come from a world where fast iteration and a really fluent language interface like Ruby has and a really fast iteration cycle like Rails has, is, like, the most important need to be solved because other things have been solved. You understand what you're doing for your product, or maybe you need to iterate quickly on that product. You've figured out an audience. You're getting payroll. You're meeting all that as a business.

+ +

But then you go into a business that's potentially, like, let's say, much less funded. Or they have their market fit, and now they're working on, like, extreme performance optimization, or they're working on getting, like, government compliance, or something like that. And maybe Rails is still great. This is maybe a...the analogy may fall apart here. But let's pretend it isn't for some reason. You have to agree that, hey, like, yes, we've solved problem X that Rails really helps you solve. And now we're moving on to problem Y, and Rails may not help you solve that, or whatever technology you're using may not help you solve that.

+ +

And I've found it to be much more useful to stop worrying about the means, and the tools, the things in between, and worry about the ends, worry about the goal, worry about the problems you're actually trying to solve. And then you can feel really invested in trying to solve that problem together as a group, as a team, as a community. I've found that to be very helpful.

+ +

And I would also like to say it is extremely difficult to let some of that stuff go. It takes a lot of work. I see you nodding along. Like, it's really, really hard. And, like I said, I'm not totally done with it either. But that's, I think, it's something I'm really working on now and something I feel really strongly about.

+ +

STEPHANIE: Yeah. You mentioned the friction of, like, working in an environment where there are different opinions, which is, you know, I don't know, just, like, reality, I guess [laughs].

+ +

EDWARD: Human nature.

+ +

STEPHANIE: Yeah, exactly. And one thing I was thinking about recently was, like, okay, like, so someone else maybe made a decision about using a type of technology or, like, made a decision about architecture before my time or, like, above me, or whatever, right? Like, I wasn't there, and that is okay. But also, like, how do I maintain what I believe in and hold fast to, like, my opinions based on my value system, at least, without complaining? [laughs]

+ +

Because I've only seen that a little bit before, right? When it just becomes, like, venting, right? It's like, ugh, like, you know, I have seen people who are coming from maybe, like, microservices or more of a JavaScript world, and they're like, ugh, like, what is going on with Rails? Like, this sucks [laughs].

+ +

And one thing I've been trying lately is just, like, communicating when I don't agree that something's a great idea. But also, like, acknowledging that, like, yeah, but this is how it is for this team, and I'm also not in a position to change it. Or, like, I don't feel so strongly about it that I'm like, "Hey, we should totally rethink using this, like, background job [laughs] platform."

+ +

But I will be like, "Hey, like, I don't like this particular thing about it. And, you know, maybe here are some things that I did to mitigate whatever thing I'm not super into," or, like, "If I had more time, this is what I would do," and just putting it out there. Sometimes, I don't get, like, engagement on it. But it's a good practice for me to be, like, this is how I can still have opinions about things, even if I'm not, at least in this particular moment, in a position to change anything.

+ +

EDWARD: It sounds to me like you in, at least at the lowest level, like, you want to be acknowledged, and you want to, like, be heard. You want to be part of a process. And yes, it doesn't always go with Stephanie's initial thought, or even final thought, or Edward's final thought. But it is very helpful to know that you are heard and you are respected. And it isn't someone just, like, completely disregarding any feeling that you have.

+ +

As much as we like to say programming is this very, like, I don't know, value neutral, zero emotion kind of job, like, there's tons of emotion in this job. We want to do good things for the world. We want our technology to serve the people, ultimately, at least I do, and I know you do. But we sometimes disagree on the way to do that.

+ +

And so, you want to make sure you're heard. And if you can't get that at work, like, and I know you do this, but I would encourage anyone listening out there to, like, get a buddy that you can vent to or get somebody that you can express, and they will hear you. That is so valuable just as a release, in some ways, to kind of get through what you need to get through sometimes. Because it is a job, and you aren't always the person that's going to make the decisions.

+ +

And, honestly, like, you do still have one decision left, which is you can go work somewhere else if it really is that bad. And, like, it's useful to know that you are staying where you are because you appreciate the trade-offs that you have: a steady paycheck, or the colleagues that you work with, or whatever. And that's fine. That's an okay trade-off. And at some point, you might want to make a different trade-off, and that's also fine. We're getting real managery and real here. But I think it's useful. Like you said, this can be a very emotional career, and it's worth acknowledging that.

+ +

STEPHANIE: Yeah, you just, you know, raised a bunch of, like, very excellent points. Yeah, at the end of the day, like, you know, you can do your best to, like, propose changes or, like, introduce new tooling and, like, see how other people feel about it. But, like, yeah, if you fundamentally do not enjoy working with a critical tool that, you know, a lot of the foundation of the work that you're doing day to day is built off of, then maybe there is a place where, like, another company that's using tools that you do feel excited or, like, passionate or, like, are a better alignment with what you hope to be doing.

+ +

Kind of just going back to that theme that we were talking about earlier, like, everyone gets to decide for themselves, right? Like, the tools to help them do what they want to be doing.

+ +

EDWARD: And you could even, like, reframe it for yourself, where instead of it being about the tools, maybe it's about the problem. Like, you start being more invested in, like, the problem that you're solving and, okay, maybe you don't want to use microservices or whatever, but, like, maybe you can get behind that if you realign yourself. The thing you're trying to solve is not the tool. The thing you're trying to solve is the problem. And that can be a useful, like, way to mitigate that or to, like, help yourself feel okay about the thing, whatever that is.

+ +

STEPHANIE: Yeah. Now, how do I have this conversation with everyone [laughter] who claims on the internet that X is the solution to all their problems or the silver bullet, [laughs] or whatever?

+ +

EDWARD: Yeah, that's tough because there are some very strong opinions on the internet, as I'm sure [laughs] you've observed. I don't know if I have the answer [laughs]. Once again, nuance and indecisions.

+ +

I have been currently approaching it from kind of a meta-perspective of, like, if someone says, "X is the best tool," you know, "A hammer is the best tool," right? I'm not going to go write the post that's like, "No, hammer is, in fact, not the best tool. Don't use hammers." I would maybe instead write a post that's like, "Consider what makes the best tool." I've effectively, like, raised up one level of abstraction from, we're no longer talking about is X, or Y, or Z, the best tool? We're talking about how do we even decide that? How do we even think about that?

+ +

One post...I'm now just promoting my blog posts, so get ready. But one thing I wrote was this post called And Not But. And I tried to make the case that instead of saying the word but in a sentence, so, like, yeah, yeah, we might want to use hammers, but we have to use drills or whatever. I'm trying to make the case that you can use and instead. So yeah, hammers are really good, and drills are really good in these other scenarios.

+ +

And trying to get that nuance in there, like, really, really putting that in there and getting people to, like, feel that better, I think, has been really helpful, for me, certainly to get through. And part of the best thing about writing a blog post is just getting your own thoughts...I mean, it's another way to vent, right? It's getting your own thoughts out somewhere.

+ +

And sometimes people respond to them. You'd be surprised who just reaches out and been like, "Hey, yeah, like, I really appreciated that post. That was really great." You weren't trying to reach that person, but now you have another connection. So, a side benefit for writing blog posts [inaudible 30:17] do it, or just even getting your thoughts out via a podcast, via a video, whatever. So, I've kind of addressed that.

+ +

I also wrote a post when I worked at thoughtbot called Empathy Online. And that came out of, like, frustration with seeing people being too divisive or, in my opinion, unempathetic or inconsiderate. And instead of, again, trying to just say, "Stop it, don't do that," [laughs] but trying to, like, help use what I have learned when communicating in a medium that is kind of inherently difficult to get across emotion and empathy.

+ +

And so, again, it's, in some ways, unsatisfying because what you really want to do is go talk to that person that says, "Hammer is the best tool," and say, "No, stop it [laughs]," and, like, slap them on the head or whatever, politely. But I think that probably will not get you very far. And so, if your goal, really, is to change the way people think about these things, I find it way more effective to, like, zoom out and talk about that on that sort of more meta-level and that higher level.

+ +

STEPHANIE: Yeah. I liked how you called it, like, a higher level of abstraction. And, honestly, the other thing I was thinking about as you were talking about the, like, divisiveness that opinions can create, there's also some aspect of it, as a reader, realizing that one person sharing their opinion does not take away your ability to have a differing opinion [laughs].

+ +

And sometimes it's tough when someone's like, "Tailwind sucks [laughs], and it is a backward step in, you know, how we write CSS," or whatever. Yes, like, sometimes that can be kind of, like, inflammatory. But if you, like, kind of are translating it or, like, reading between the lines, they're just writing about their perspective from the things that they value. And it is okay for you to value different things and, for that reason, have a different perspective on the same thing.

+ +

And, I don't know, that has helped me sometimes avoid getting into that, like, headspace of wanting to argue with someone [laughs] on the internet. Or they'll be like, "This is why I am right." [laughs] Now I have to write something and share it on the internet in response [laughs].

+ +

EDWARD: There's this idea of the narcissism of minor differences. And I believe the idea is this, like, you know, you're more likely to argue with someone who, like, 90% agrees with you. But you're just, like, quibbling over that last 10%. I mean, one might call it bikeshedding. I don't know if you've heard that phrase.

+ +

But the thing that I have often found, too, is that, like the GitHub post, I will get people arguing with me, like, there's the kind of stuff I expected, where it's like, "Oh, but GitHub is really good," and XYZ and that's fine. And we can have that conversation. But it's kind of surprising, and I should have expected it, that people will sometimes be like, "Hey, you didn't go far enough. You should tell people to, like, completely delete their GitHub or, like, you know, go protest in the street." And, like, maybe that's true. I'm not saying it is or isn't.

+ +

But I think one thing I try to think about is, in any post, in any trying convincing argument, like, you're potentially moving someone 1 step forward, even if there's ten steps to go. But they're never going to make those ten steps if they don't make the first 1. And so, you can kind of help them get there. And someone else's post can absolutely take them from step 5 to 6 or 6 to 7 or 7 to 8. And you won't accomplish it all at once, and it's kind of a silly thing to try, and your efforts are probably lost [laughs].

+ +

Unfortunately, it's a little bit of preaching to the choir because, like, yeah, the people that are going to respond to, like, the extreme, the end are, like, the people that already get it. And the people that you're trying to convince and move along are not going to get that thing. I do want to say that I could see this being perceived as, like, a very privileged position of, like, if there's some, like, genuine atrocity happening in the world, like, it is appropriate to go to extremes many times and sometimes, and that's fine, and people are allowed to be there. I don't want to invalidate that. It's a really tricky balance.

+ +

And I'm trying to say that if your goal is to vent, that's fine. And if your goal is to move people from step 3 to 4, you have to meet people at step 3. And all that's valid and okay to try to help people move in that way. But it is very tricky. And I don't want to invalidate someone who's extremely frustrated because they're at step 10, and no one else is seeing the harm that not everybody else being at step 10 is. Like, that's an incredibly reasonable place to be and an okay place to be.

+ +

STEPHANIE: Yeah, yeah. The other thing you just sparked, for me, is also the, like, power of, yeah, being able to say like, "Yeah, I agree with this 50%, or 60%, or, like, 90%." And also, there's this 10% that I'm like, oh, like, I wish were different, or I wish they'd gone further, or I wish they didn't say that. Or, you know, I just straight up disagree with this step 1 sentence, but the rest of the article, you know, I really related to.

+ +

And, like, teasing that apart has been very useful for me, right? Because then I'm no longer like being like, oh, was this post good or bad? Do I agree with it or don't agree with it? It's like, there's room for [laughs] all of it.

+ +

EDWARD: Yeah, that's that nuance that, you know, I liked this post, and I did not agree with these two parts of it, or whatever. It's so useful.

+ +

STEPHANIE: Well, thanks, Edward, so much for coming on the show and bringing that nuance to this conversation. I feel really excited about kind of what we talked about, and hopefully, it resonates with some of our listeners.

+ +

EDWARD: Yeah, I hope so too. I hope I can take them from step 2 to step 3 [laughs].

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

EDWARD: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+wVhHRBXA + + ]]> + + Stephanie Minn + + + 406: Working Solo + https://bikeshed.thoughtbot.com/406 + d6b25191-e19d-4954-80b4-e21c63a40700 + Tue, 14 Nov 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël got to do some pretty fancy single sign-on work. And when it came time to commit, he documented the ridiculous number of redirects to give people a sense of what was happening. Stephanie has been exploring Rails callbacks and Ruby debugging tools, using methods like `save_callbacks` and `Kernel.caller`, and creating a function call graph to better understand and manage complex code dependencies. + +Stephanie is also engaged in an independent project and seeking strategies to navigate the challenges of solo work. She and Joël explore how to find external support and combat isolation, consider ways to stimulate creativity, and obtain feedback on her work without a direct team. Additionally, they ponder succession planning to ensure project continuity after her involvement ends. They also reflect on the unique benefits of solo work, such as personal growth and flexibility. Stephanie's focus is on balancing the demands of working independently while maintaining a connected and sustainable professional approach. + 32:27 + no + + + Joël got to do some pretty fancy single sign-on work. And when it came time to commit, he documented the ridiculous number of redirects to give people a sense of what was happening. Stephanie has been exploring Rails callbacks and Ruby debugging tools, using methods like save_callbacks and Kernel.caller, and creating a function call graph to better understand and manage complex code dependencies. +Stephanie is also engaged in an independent project and seeking strategies to navigate the challenges of solo work. She and Joël explore how to find external support and combat isolation, consider ways to stimulate creativity, and obtain feedback on her work without a direct team. Additionally, they ponder succession planning to ensure project continuity after her involvement ends. They also reflect on the unique benefits of solo work, such as personal growth and flexibility. Stephanie's focus is on balancing the demands of working independently while maintaining a connected and sustainable professional approach. +ASCII Sequence Diagram Creator (https://textart.io/sequence) +Callback debugging methods (https://andycroll.com/ruby/find-list-debug-active-record-callbacks-in-the-console/) +Kernel.caller (https://ruby-doc.org/core-3.0.2/Kernel.html#method-i-caller) +Method.source_location (https://ruby-doc.org/core-3.0.2/Method.html#method-i-source_location) +Building web apps by your lonesome by Jeremy Smith (https://www.youtube.com/watch?v=Rr871vmV4YM) +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: I got to do something really fun this week, where I was doing some pretty fancy single sign-on work. And when it came time to commit, I wanted to document the kind of ridiculous number of redirects that happen and give people a sense of what was going on. +And for my own self, what I had been doing is, I had done a sequence diagram that sort of shows, like, three different services that are all talking to each other and where they redirect to each other as they all go through the sequence to sign someone in. And I was like, how could I embed that in the commit message? Because I think it would be really useful context for someone trying to get an overview of what this commit is doing. +And the answer, for me, was, can I get this sequence diagram in ASCII form somewhere? And I found a website that allows me to do this in ASCII art. It's the textart.io/sequence. And that allows me to create a sequence diagram that gets generated as ASCII art. I can copy-paste that into a commit message. And now anybody else who is like, "What is it that Joël is trying to do here?" can look at that and be like, "Oh, oh okay, so, we got these, like, four different places that are all talking to each other in this order. Now I see what's happening." +STEPHANIE: That's super neat. I love the idea of having it directly in your commit message just because, you know, you don't have to go and find a graph elsewhere if you want to understand what's going on. It's right there for you, for future commit explorers [laughs] trying to understand what was going on in this snippet of time. +JOËL: I try as much as possible to include those sorts of things directly in the commit message because you never know who's reading the commit. They might not have access to some sort of linked resource. So, if I were like, "Hey, go to our wiki and see this link," like, sure, that would be helpful, but maybe the person reading it doesn't have access to the wiki. Maybe they do have access, but they're not on the internet right now, and so they don't have access to the wiki. Maybe the wiki no longer exists, and that's a dead link. So, as much as possible, I try to embed context directly in my commit messages. +STEPHANIE: That's really cool. And just another shout out to ASCII art, you know [laughs], persevering through all the times with our fancy tools. It's still going strong [laughs]. +JOËL: Something about text, right? +STEPHANIE: Exactly. I actually also have a diagram graph thing to share about what's new in my world that is kind of in a similar vein. Another thoughtboter and former guest on the show, Sara Jackson, shared in our dev channel about this really cool mural graph that she made to figure out what was going on with callbacks because she was working on, you know, understanding the lifecycle of this model and was running into, like, a lot of complex behavior. +And she linked to a really neat blog post by Andy Croll, too, that included a little snippet sharing a few callback debugging methods that are provided by ActiveRecord. So, basically, you can have your model and just call double underscore callbacks. And it returns a list of all the callbacks that are defined for that model, and I thought that was really neat. So, I played around with it and copypastad [laughs] the snippet into my Rails console to figure out what's going on with basically, like, the god object of that that I work in. +And the first issue I ran into was that it was undefined because it turns out that my application was on an older [laughs] version of Rails than that method was provided on. But, there are more specific methods for the types of callbacks. So, if you are looking specifically for all the callbacks related to a save or a destroy, I think it's save underscore callbacks, right? And that was available on the Rails version I was on, which was, I think, 4. But that was a lot of fun to play around with. +And then, I ended up chatting with Sara afterwards about her process for creating the diagram after, you know, getting a list of all these methods. And I actually really liked this hybrid approach she took where, you know, she automated some parts but then also manually, like, went through and stepped through the code and, like, annotated notes for the methods as she was traversing them. +And, you know, sometimes I think about, like, wow, like, it would be so cool if this graph just generated automatically, but I also think there is some value to actually creating it yourself. And there's some amount of, like, mental processing that happens when you do that, as opposed to, like, looking at a thing that was just, you know, generated afterwards, I think. +JOËL: Do you know what kind of graph Sara generated? Was it some kind of, like, function call graph, or was it some other way of visualizing the callbacks? +STEPHANIE: I think it was a function call graph, essentially. It even kind of showed a lot of the dependencies, too, because some of the callback functions were quite complicated and then would call other classes. So, there was a lot of, I think, hidden dependencies there that were unexpected, you know, when you think you're just going to create a regular old [laughs] record. +JOËL: Yeah, I've been burned by unexpected callbacks or callbacks that do things that you wouldn't want in a particular context and then creating bad data or firing off external services that you really didn't want, and that can be an unpleasant surprise. I appreciate it when the framework offers debugging tools and methods kind of built-in, so these helpers, which I was not aware of. It's really cool because they allow you to kind of introspect and understand the code that you're going through. Do you have any others like that from Rails or Ruby that you find yourself using from time to time to help better understand the code? +STEPHANIE: I think one I discovered recently was Kernel.caller, which gives you the stack trace wherever you are when executing. And that was really helpful when you're not raising an exception in certain places, and you need to figure out the flow of the code. I think that was definitely a later discovery. And I'm glad to have it in my back pocket now as something I can use in any kind of Ruby code. +JOËL: That can, yeah, definitely be a really useful context to have even just in, like, an interactive console. You're like, wait a minute, where's this coming from? What is the call stack right now? +STEPHANIE: Do you have any debugging tools or methods that you like to use that maybe are under the radar a little bit? +JOËL: One that I really appreciate that's built into Ruby is the source location method on the method object, so Ruby has a method object. And so, when you're dealing with some sort of method and, like, maybe it got generated programmatically through metaprogramming, or maybe it's coming from a gem or something like that, and you're just like, where is this define? I'm trying to find it. +If you're in your editor and you're doing stuff, maybe you could run some sort of search, or maybe it has some sort of keyword lookup where you can just find the definition of what's under your cursor. But if you're in an interactive console, you can create a method object for that method name and then call dot source location on it. And it will tell you, here's where it's defined. So, very handy in the right circumstances. +STEPHANIE: Awesome. That's a great tip. +JOËL: Of course, one of the most effective debugging tools is having a pair, having somebody else work with you, but that's not always something that you have. And you and I were talking recently about what it's like to work solo on a project. Because you're currently on a project, you're solo, at least from the thoughtbot side of things. You're embedding with a team, with a client. Are you working on kind of, like, a solo subtask within that, or are you still kind of embedding and interacting with the other teammates on a regular basis? +STEPHANIE: Yeah. So, the past couple of weeks, I am working on more of a solo initiative. The other members of my client team are kind of ramping up on some other projects for this next quarter. And since my engagement is ending soon, I'm kind of left working on some more residual tasks by myself. And this is new for me, actually. I've not really worked in a super siloed by-myself kind of way before. I usually have at least one other dev who I'm, like, kind of partnering up with on a project, or an epic, or something like that. +And so, I've had a very quiet week where no one is, you know, kind of, like, reaching out to me and asking me to review their code, or kind of checking in, or, you know, asking me to check in with them. And yeah, it's just a little bit different than how I think I like to normally work. I do like to work with other people. So, this week has been interesting in terms of just kind of being a more different experience where I'm not as actively collaborating with others. +JOËL: What do you think are some of the biggest challenges of being kind of a little bit out in your own world? +STEPHANIE: I think the challenges for me can definitely be the isolation [laughs], and also, what kind of goes hand in hand with that is when you need help, you know, who can you turn to? There's not as much of an obvious person on your team to reach out to, especially if they're, like, involved with other work, right? And that can be kind of tough. +Some of the other ones that I've been thinking about have been, you know, on one hand, like, I get to make all of the decisions that I want [laughs], but sometimes you kind of get, like, really in your own head about it. And you're not in that space of, like, evaluating different solutions that you maybe might not think of. And I've been trying to figure out how to, like, mitigate some of that risk. +JOËL: What are some of the strategies that you use to try to balance, like making good decisions when you're a bit more solo? Do you try to pull in someone from another team to talk ideas through? Do you have some sort of internal framework that you use to try to figure out things on your own? What does that look like? +STEPHANIE: Yeah, luckily, the feature I'm working on is not a huge project. Well, if it were, I think then I wouldn't be alone on it. But, you know, sometimes you find yourself kind of tasked with one big thing for a while, and you are responsible for from start to finish, like all of the architectural decisions to implementation. But, at least for me, the scope is a little more narrow. And so, I don't feel as much of a need to get a lot of heads together because I at least feel somewhat confident in what I'm doing [laughs]. +But I have found myself being a bit more compelled to kind of just verbalize what I'm doing more frequently, even to, like, myself in Slack sometimes. It's just like, I don't know who's reading this, but I'm just going to put it out there because maybe someone will see this and jump in and say, "Oh, like, interesting. Here's some other context that I have that maybe might steer you away from that," or even validating what I have to say, right? Like, "That sounds like a good idea," or, you know, just giving me an emoji reaction [laughs] is sometimes all I need. +So, either in Slack or when we give our daily sync updates, I am, I think, offering a little more details than I might if I already was working with someone who I was more in touch with in an organic way. +JOËL: And I think that's really powerful because it benefits you. Sort of by having to verbalize that or type it out, you, you know, gain a little bit of self-awareness about what you're trying to do, what the struggles are. But also, it allows anybody else who has potentially helpful information to jump in. I think that's not my natural tendency. When I'm on something solo, I tend to kind of, like, zoom in and focus in on something and, like, ignore a little bit of the world around me. Like, that's almost the time when I should look at overcommunicating. +So, I think most times I've been on something solo, I sort of keep relearning this lesson of, like, you know, it's really important to constantly be talking out about the things that you're doing so that other people who are in a broader orbit around you can jump in where necessary. +STEPHANIE: Yeah, I think you actually kind of touched on one of the unexpected positives, at least for me. Something I wasn't expecting was how much time I would have to just be with my thoughts. You know, as I'm implementing or just in my head, I'm mulling over a problem. I have less frequent, not distractions necessarily, but interruptions. And sometimes, that has been a blessing because I am not in a spot where I have a lot of meetings right now. And so, I didn't realize how much generative thought happens when you are just kind of, like, doing your own thing for a little bit. +I'm curious, for you, is that, like, a space that you enjoy being when you're working by yourself? And I guess, you know, you were saying that it's not your natural state to kind of, like, share what's going on until maybe you've fully formed an idea. +JOËL: I think I often will regret not having shared out before everything is done. The times that I have done it, I've been like, that was a really positive experience; I should do that more. I think it's easy to sort of wait too long before sharing something out. And with so many things, it feels like there's only one more small task before it's done. Like, I just need to get this one test to go green, and then I can just put up a PR, and then we'll have a conversation about it. But then, oh, this other test broke, or this dependency isn't installing correctly. +And before you know it, you've spent a whole day chasing down these things and still haven't talked. And so, I think if some of those things were discussed earlier, it would help both to help me feel more plugged in, but also, I think everybody else feels like they're getting a chance to participate as well. +STEPHANIE: So, you mentioned, you know, obviously, there's, like, the time spent just arriving at the solution before sharing it out for feedback. But have you ever been in a position where there is no one to give you feedback and, like, not even a person to review your code? +JOËL: That's really challenging. So, occasionally, if I'm working on a project, maybe it would be, like, very early-stage startup that maybe just has, like, a founder, and then I'm, like, the only technical person on the team, generally, what I'll try to do is to have some kind of review buddy within thoughtbot, so some other developer who's not staffed on my project but who has access to the code such that I can ask them to say, "Hey, can you just take a look at this and give me a code review?" That's the ideal situation. +You know, some companies tend to lock things down a lot more if you're dealing with something like healthcare or something like that, where there might be some concerns around personal information, that kind of thing. But generally, in those cases, you can find somebody else within the company who will have some technical knowledge who can take a look at your code; at least, that's been my experience. +STEPHANIE: Nice. I don't think I've quite been in that position before; again, I've really mostly worked within a team. But there was a conference talk I watched a little bit ago from Jeremy Smith, and it was called Building Web Apps by Your Lonesome. And he is a, like, one-man agency. And he talked about, you know, what it's like to be in that position where you pretty much don't have other people to collaborate with, to review your code. And one thing that he said that I really liked was shifting between writer and editor mode. +If you are the person who has to kind of just decide when your code is good enough to merge, I like that transition between, like, okay, I just spent however many hours putting together the solution, and now I'm going to look at it with a critical eye. And sometimes I think that might require stepping away for a little bit or, like, revisiting it even the next day. That might be able to help see things that you weren't able to notice when you were in that writing mode. But I have found that distinction of roles really helpful because it does feel different when you're looking at it from those two lenses. +JOËL: I've definitely done that for some, like, personal solo projects, where I'm participating in a game jam or something, and then I am the only person to review my code. And so, I will definitely, at that point, do a sort of, like, personal code review where I'll look at it. Maybe I'm doing PRs on GitHub, and I'm just merging. Maybe I'm just doing a git diff and looking at a commit in the command line on my own machine. +But it is useful, even for myself, to sort of switch into that editor mode and just kind of look at everything there and say, "Is it in a good place?" Ideally, I think I do that before putting it out for a co-worker's review, so you kind of get both. But on a solo project, that has worked actually pretty well for me as well. +STEPHANIE: One thing that you and I have talked about before in a different context, I think, when we have chatted about writing conference talks, is you are really great about focusing on the audience. And I was thinking about this in relation to working solo because even when you are working by yourself on a project, you're not writing the code for yourself, even though you might feel like [laughs] it in the moment. +And I also kind of like the idea of asking, like, who are you building for? You know, can you ask the stakeholder or whoever has hired you, like, "Who will maintain this project in the future?" Because likely, it won't be you. Hopefully, it won't be you unless that's what you want to be doing. +There's also what my friend coined the circus factor as opposed to the bus factor, which is, like, if you ran away to the circus tomorrow [laughs], you know, what is the impact that would have? And yeah, I think working solo, you know, some people might think, like, oh, that gives me free rein to just write the code exactly how I want to, how I want to read it. But I think there is something to be said about thinking about the future of who will be [inaudible 18:10] what you just happen to be working on right now. +JOËL: And keep in mind that that person might be future you who might be coming back and be like, "What is going on here?" So, yeah, audience, I think, is a really important thing to keep in mind. I like to ask the question, if somebody else were looking at this code, and somebody else might be future me, what parts would they be confused by? If I was walking somebody else through the code for the first time, where would they kind of stop me through the walkthrough and be like, "Hey, why is this happening? What's the connection between these two things? I can see they're calling each other, but I don't know why." +And that's where maybe you put in a comment. Maybe you find a better method or a class name to better explain what happens. Maybe you need to put more context in a commit message. There's all sorts of tools that we can use to better increase documentation. But having that pause and asking, "What will confuse someone?" is, I think, one of the more powerful techniques I do when I'm doing self-review. +STEPHANIE: That's really cool. I'm glad you mentioned that, you know, it could also be future you. Because another thing that Jeremy says in this talk that I was just thinking about is the idea of optimizing for autonomy. And there's a lot to be said there because autonomy is like, yeah, like, you end up being the person who has to deal with problems [laughs], you know, if you run into something that you can't figure out, and, ideally, you'll have set yourself up for success. +But I think working solo doesn't mean that you are in your own universe by yourself completely. And thinking about future, you, too, is kind of, like, part of the idea that the person in this moment writing code will change [laughs]. You'll get new information. Maybe, like, you'll find out about, like, who might be working on this in the future. And it is kind of a fine balance between making sure that you're set up to handle problems, but at the same time, maybe it's that, like, you set anyone up to be able to take it away from where you left it. +JOËL: I want to take a few moments to sort of talk a little bit about what it means to be solo because I think there are sort of multiple different solo experiences that can be very different but also kind of converge on some similar themes. Maybe some of our listeners are listening to us talking and being like, "Well, I'm not at a consultancy, so this never happens to me." But you might find yourself in that position. +And I think one that we mentioned was maybe you are embedded on a team, but you're kind of on a bit of a larger project where you're staffed solo. So, even though you are part of a larger team, you do feel like the initiative that you're on is siloed to you a little bit. Are there any others that you'd like to highlight? +STEPHANIE: I think we also mentioned, you know, if you're a single developer working on an application because you might be the first technical hire, or a one-person agency, or something, that is different still, right? Because then your community is not even your company, but you have to kind of seek out external communities on social networks, or Slack groups, or whatever. +I've also really been interested in the idea of developers kind of being able to be rotated with some kind of frequency where you don't end up being the one person who knows everything about a system and kind of becomes this dependency, right? But how can we make projects so, like, well functioning that, like, anyone can step in to do some work and then move on? If that's just for a couple of weeks, for a couple of months. Do you have any thoughts about working solo in that kind of situation where you're just stepping into something, maybe even to help someone out who's, you know, on vacation, or kind of had to take an unexpected leave? +JOËL: Yeah, that can be challenging. And I think, ideally, as a team, if you want to make that easier, you have to set up some things both on a, like, social level and on a tactical level, so all the classic code quality things that you want in place, well structured, encapsulated code, good documentation, things like that. To a certain extent, even breaking down tasks into smaller sort of self-sufficient stories. I talk a lot about working incrementally. +But it's a lot easier to say, "Hey, we've got this larger story. It was broken down into 20 smaller pieces that can all be shipped independently, and a colleague got three of them done and then had to go on leave for some reason. Can you step in and do stories 4 through 20?" As opposed to, "Hey, we have this big, amorphous story, and your colleague did some work, and it kind of is done. There's a branch with some code on it. They left a few notes or maybe sent us an email. But they had to go on leave unexpectedly. Can you figure it out and get it done?" The second scenario is going to be much more challenging. +STEPHANIE: Yeah, I was just thinking about basically what you described, right? Where you might be working on your own, and you're like, well, I have this one ticket, and it's capturing everything, and I know all that's going on [laughs], even though it's not quite documented in the ticket. But it's, you know, maybe on my branch, or in my head, or, worst of all, on my local machine [laughs] without being pushed up. +JOËL: I think maybe that's an anti-pattern of working solo, right? A lot of these disciplines that you build when you're working in a team, such as breaking up tickets into smaller pieces, it's easy to kind of get a little bit lazy with them when you're working solo and let your tickets inflate a little bit, or just have stuff thrown together in branches on your local machine, which then makes it harder if somebody does need to come in to either collaborate with you or take over from you if you ever need to step aside. +STEPHANIE: Right. I have definitely seen some people, even just for their personal projects, use, like, a Trello board or some other project management tool. And I think that's really neat because then, you know, obviously, it's maybe just for their own, like, self-organization needs, but it's, like, that recognition that it's still a complicated project. And just because they're working by themselves doesn't mean that they can't utilize a tool for project management that is meant for teams or not even teams [laughs], you know, people use them for their own personal stuff all the time. +But I really like that you can choose different levels of how much you're documenting for your future self or for anyone else. You had mentioned earlier kind of the difference between opening up a PR for you...you have to merge your branch into main or whatever versus just committing to main. And that distinction might seem, like, if you were just working on a personal project, like, oh, you know, why go through the extra step? But that can be really valuable in terms of just seeing, like, that history, right? +JOËL: I think on solo projects, it can really depend on the way you tend to treat your commit history. I'm very careful with the history on the main branch where I want it to tell a sort of, like, cohesive story. Each commit is kind of, like, crafted a little bit. So, even when I'm working solo and I'm committing directly to master or to the main branch, I'm not just, like, throwing random things there. Ideally, every commit is green and builds and is, like, self-contained. +If you don't have that discipline, then it might be particularly valuable to go through the, like, a branching system or a PR system. Or if you just want, like, a place to experiment, just throw a bunch of code together, a bunch of things break; nothing is cohesive, that's fine. It's all a work in progress until you finally get to your endpoint, and then you squash it down, or you merge it, or whatever your workflow is, and then it goes back into the main branch. +So, I think that for myself, I have found that, oftentimes, I get not really a whole lot of extra value by going through a branching and PR system when it's, like, a truly solo project, you know, I'm building a side project, something like that. But that's not necessarily true for everyone. +STEPHANIE: I think one thing I've seen in other people's solo projects is using a PR description and, you know, having the branching strategy, even just to jot down future improvements or future ideas that they might take with the work, especially if you haven't kind of, like, taken the next step of having that project management system that we talked about. But there is, like, a little more room for some extra context or to, like, leave yourself little notes that you might not want necessarily in your commit history but is maybe more related to this project being, like, a work in progress where it could go in a lot of different directions, and you're figuring that out by yourself. +JOËL: Yeah, I mean, definitely something like a draft PR can be a great place to have work in progress and experiment and things like that. Something you were saying got me wondering what distinction you typically have between what you would put in a commit message versus something that you would put in a PR description, particularly given that if you've got, like, a single commit PR, GitHub will automatically make the commit message your PR message as well. +STEPHANIE: This has actually evolved for me over time, where I used to be a lot more reliant on PR descriptions holding a lot of the context in terms of the decision-making. I think that was because I thought that, like, that was the most accessible place of information for reviewers to find out, you know, like, why certain decisions were made. And we were using, you know, PR templates and stuff like that. +But now the team that I'm working on uses commit message templates that kind of contain the information I would have put in a PR, including, like, motivation for the change, any risks, even deployment steps. So, I have enjoyed that because I think it kind of shortens the feedback loop, too, right? You know, you might be committing more frequently but not, you know, opening a PR until later. And then you have to revisit your commits to figure out, like, okay, what did I do here? But if you are putting that thought as soon as you have to commit, that can save you a little bit of work down the line. +What you said about GitHub just pulling your commit message into the PR description has been really nice because then I could just, like, open a thing [laughs]. And that has been nice. +I think one aspect that I really like about the PR is leaving myself or reviewers, like, notes via comments, like, annotating things that should not necessarily live in a more permanent form. But maybe I will link to documentation for a method that I'm using that's a little less common or just add some more information about why I made this decision over another at a more granular level. +JOËL: Yeah, I think that's probably one of the main things that I tend to put in a PR message rather than the commit message is any sort of extra information that will be helpful at review time. So, maybe it's a comment that says, "Hey, there is a lot of churn in this PR. You will probably have a better experience if you review this in split view versus unified view," things like that. +So, kind of, like, meta comments about how you might want to approach reviewing this PR, as opposed to something that, let's say somebody is reviewing the history or is, like, browsing the code later, that wouldn't be relevant to them because they're not in a code review mindset. They're in a, like, code reading, code understanding mindset or looking at the message to say, "Why did you make the changes? I saw this weird method. Why did you introduce that?" So, hopefully, all of that context is in the commit message. +STEPHANIE: Yeah, you reminded me of something else that I do, which is leave notes to my future self to revisit something if I'm like, oh, like, this was the first idea I had for the, you know, the way to solve this problem but, you know, note to self to look at this again tomorrow, just in case I have another idea or even to, like, you know, do some more research or ask someone about it and see if they have any other ideas for how to implement what I was aiming for. +And I think that is the editor mode that we were talking about earlier that can be really valuable when you're working by yourself to spend a little extra time doing. You know, you are essentially optimizing for autonomy by being your own reviewer or your own critic in a healthy and positive way [laughs], hopefully. +JOËL: Exactly. +STEPHANIE: So, at the beginning of this episode, I mentioned that this is a new experience for me, and I'm not sure that I would love to do it all of the time. But I'm wondering, Joël, if there are any, you know, benefits or positives to working solo that you enjoy and find that you like to do just at least for a short or temporary amount of time. +JOËL: I think one that I appreciate that's maybe a classic developer response is the heads downtime, the focus, being able to just sit down with a problem and a code editor and trying to figure it out. There are times where you really need to break out of that. You need somebody else to challenge you to get through a problem. But there are also just amazing times where you're in that flow state, and you're getting things done. And that can be really nice when you're solo. +STEPHANIE: Yeah, I agree. I have been enjoying that, too. But I also definitely am looking forward to working with others on a team, so it's kind of fun having to get to experience both ways of operating. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeeeeee!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Joël got to do some pretty fancy single sign-on work. And when it came time to commit, he documented the ridiculous number of redirects to give people a sense of what was happening. Stephanie has been exploring Rails callbacks and Ruby debugging tools, using methods like save_callbacks and Kernel.caller, and creating a function call graph to better understand and manage complex code dependencies.

+ +

Stephanie is also engaged in an independent project and seeking strategies to navigate the challenges of solo work. She and Joël explore how to find external support and combat isolation, consider ways to stimulate creativity, and obtain feedback on her work without a direct team. Additionally, they ponder succession planning to ensure project continuity after her involvement ends. They also reflect on the unique benefits of solo work, such as personal growth and flexibility. Stephanie's focus is on balancing the demands of working independently while maintaining a connected and sustainable professional approach.

+ +
+ +

ASCII Sequence Diagram Creator
+Callback debugging methods
+Kernel.caller
+Method.source_location
+Building web apps by your lonesome by Jeremy Smith

+ +
+ +

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: I got to do something really fun this week, where I was doing some pretty fancy single sign-on work. And when it came time to commit, I wanted to document the kind of ridiculous number of redirects that happen and give people a sense of what was going on.

+ +

And for my own self, what I had been doing is, I had done a sequence diagram that sort of shows, like, three different services that are all talking to each other and where they redirect to each other as they all go through the sequence to sign someone in. And I was like, how could I embed that in the commit message? Because I think it would be really useful context for someone trying to get an overview of what this commit is doing.

+ +

And the answer, for me, was, can I get this sequence diagram in ASCII form somewhere? And I found a website that allows me to do this in ASCII art. It's the textart.io/sequence. And that allows me to create a sequence diagram that gets generated as ASCII art. I can copy-paste that into a commit message. And now anybody else who is like, "What is it that Joël is trying to do here?" can look at that and be like, "Oh, oh okay, so, we got these, like, four different places that are all talking to each other in this order. Now I see what's happening."

+ +

STEPHANIE: That's super neat. I love the idea of having it directly in your commit message just because, you know, you don't have to go and find a graph elsewhere if you want to understand what's going on. It's right there for you, for future commit explorers [laughs] trying to understand what was going on in this snippet of time.

+ +

JOËL: I try as much as possible to include those sorts of things directly in the commit message because you never know who's reading the commit. They might not have access to some sort of linked resource. So, if I were like, "Hey, go to our wiki and see this link," like, sure, that would be helpful, but maybe the person reading it doesn't have access to the wiki. Maybe they do have access, but they're not on the internet right now, and so they don't have access to the wiki. Maybe the wiki no longer exists, and that's a dead link. So, as much as possible, I try to embed context directly in my commit messages.

+ +

STEPHANIE: That's really cool. And just another shout out to ASCII art, you know [laughs], persevering through all the times with our fancy tools. It's still going strong [laughs].

+ +

JOËL: Something about text, right?

+ +

STEPHANIE: Exactly. I actually also have a diagram graph thing to share about what's new in my world that is kind of in a similar vein. Another thoughtboter and former guest on the show, Sara Jackson, shared in our dev channel about this really cool mural graph that she made to figure out what was going on with callbacks because she was working on, you know, understanding the lifecycle of this model and was running into, like, a lot of complex behavior.

+ +

And she linked to a really neat blog post by Andy Croll, too, that included a little snippet sharing a few callback debugging methods that are provided by ActiveRecord. So, basically, you can have your model and just call double underscore callbacks. And it returns a list of all the callbacks that are defined for that model, and I thought that was really neat. So, I played around with it and copypastad [laughs] the snippet into my Rails console to figure out what's going on with basically, like, the god object of that that I work in.

+ +

And the first issue I ran into was that it was undefined because it turns out that my application was on an older [laughs] version of Rails than that method was provided on. But, there are more specific methods for the types of callbacks. So, if you are looking specifically for all the callbacks related to a save or a destroy, I think it's save underscore callbacks, right? And that was available on the Rails version I was on, which was, I think, 4. But that was a lot of fun to play around with.

+ +

And then, I ended up chatting with Sara afterwards about her process for creating the diagram after, you know, getting a list of all these methods. And I actually really liked this hybrid approach she took where, you know, she automated some parts but then also manually, like, went through and stepped through the code and, like, annotated notes for the methods as she was traversing them.

+ +

And, you know, sometimes I think about, like, wow, like, it would be so cool if this graph just generated automatically, but I also think there is some value to actually creating it yourself. And there's some amount of, like, mental processing that happens when you do that, as opposed to, like, looking at a thing that was just, you know, generated afterwards, I think.

+ +

JOËL: Do you know what kind of graph Sara generated? Was it some kind of, like, function call graph, or was it some other way of visualizing the callbacks?

+ +

STEPHANIE: I think it was a function call graph, essentially. It even kind of showed a lot of the dependencies, too, because some of the callback functions were quite complicated and then would call other classes. So, there was a lot of, I think, hidden dependencies there that were unexpected, you know, when you think you're just going to create a regular old [laughs] record.

+ +

JOËL: Yeah, I've been burned by unexpected callbacks or callbacks that do things that you wouldn't want in a particular context and then creating bad data or firing off external services that you really didn't want, and that can be an unpleasant surprise. I appreciate it when the framework offers debugging tools and methods kind of built-in, so these helpers, which I was not aware of. It's really cool because they allow you to kind of introspect and understand the code that you're going through. Do you have any others like that from Rails or Ruby that you find yourself using from time to time to help better understand the code?

+ +

STEPHANIE: I think one I discovered recently was Kernel.caller, which gives you the stack trace wherever you are when executing. And that was really helpful when you're not raising an exception in certain places, and you need to figure out the flow of the code. I think that was definitely a later discovery. And I'm glad to have it in my back pocket now as something I can use in any kind of Ruby code.

+ +

JOËL: That can, yeah, definitely be a really useful context to have even just in, like, an interactive console. You're like, wait a minute, where's this coming from? What is the call stack right now?

+ +

STEPHANIE: Do you have any debugging tools or methods that you like to use that maybe are under the radar a little bit?

+ +

JOËL: One that I really appreciate that's built into Ruby is the source location method on the method object, so Ruby has a method object. And so, when you're dealing with some sort of method and, like, maybe it got generated programmatically through metaprogramming, or maybe it's coming from a gem or something like that, and you're just like, where is this define? I'm trying to find it.

+ +

If you're in your editor and you're doing stuff, maybe you could run some sort of search, or maybe it has some sort of keyword lookup where you can just find the definition of what's under your cursor. But if you're in an interactive console, you can create a method object for that method name and then call dot source location on it. And it will tell you, here's where it's defined. So, very handy in the right circumstances.

+ +

STEPHANIE: Awesome. That's a great tip.

+ +

JOËL: Of course, one of the most effective debugging tools is having a pair, having somebody else work with you, but that's not always something that you have. And you and I were talking recently about what it's like to work solo on a project. Because you're currently on a project, you're solo, at least from the thoughtbot side of things. You're embedding with a team, with a client. Are you working on kind of, like, a solo subtask within that, or are you still kind of embedding and interacting with the other teammates on a regular basis?

+ +

STEPHANIE: Yeah. So, the past couple of weeks, I am working on more of a solo initiative. The other members of my client team are kind of ramping up on some other projects for this next quarter. And since my engagement is ending soon, I'm kind of left working on some more residual tasks by myself. And this is new for me, actually. I've not really worked in a super siloed by-myself kind of way before. I usually have at least one other dev who I'm, like, kind of partnering up with on a project, or an epic, or something like that.

+ +

And so, I've had a very quiet week where no one is, you know, kind of, like, reaching out to me and asking me to review their code, or kind of checking in, or, you know, asking me to check in with them. And yeah, it's just a little bit different than how I think I like to normally work. I do like to work with other people. So, this week has been interesting in terms of just kind of being a more different experience where I'm not as actively collaborating with others.

+ +

JOËL: What do you think are some of the biggest challenges of being kind of a little bit out in your own world?

+ +

STEPHANIE: I think the challenges for me can definitely be the isolation [laughs], and also, what kind of goes hand in hand with that is when you need help, you know, who can you turn to? There's not as much of an obvious person on your team to reach out to, especially if they're, like, involved with other work, right? And that can be kind of tough.

+ +

Some of the other ones that I've been thinking about have been, you know, on one hand, like, I get to make all of the decisions that I want [laughs], but sometimes you kind of get, like, really in your own head about it. And you're not in that space of, like, evaluating different solutions that you maybe might not think of. And I've been trying to figure out how to, like, mitigate some of that risk.

+ +

JOËL: What are some of the strategies that you use to try to balance, like making good decisions when you're a bit more solo? Do you try to pull in someone from another team to talk ideas through? Do you have some sort of internal framework that you use to try to figure out things on your own? What does that look like?

+ +

STEPHANIE: Yeah, luckily, the feature I'm working on is not a huge project. Well, if it were, I think then I wouldn't be alone on it. But, you know, sometimes you find yourself kind of tasked with one big thing for a while, and you are responsible for from start to finish, like all of the architectural decisions to implementation. But, at least for me, the scope is a little more narrow. And so, I don't feel as much of a need to get a lot of heads together because I at least feel somewhat confident in what I'm doing [laughs].

+ +

But I have found myself being a bit more compelled to kind of just verbalize what I'm doing more frequently, even to, like, myself in Slack sometimes. It's just like, I don't know who's reading this, but I'm just going to put it out there because maybe someone will see this and jump in and say, "Oh, like, interesting. Here's some other context that I have that maybe might steer you away from that," or even validating what I have to say, right? Like, "That sounds like a good idea," or, you know, just giving me an emoji reaction [laughs] is sometimes all I need.

+ +

So, either in Slack or when we give our daily sync updates, I am, I think, offering a little more details than I might if I already was working with someone who I was more in touch with in an organic way.

+ +

JOËL: And I think that's really powerful because it benefits you. Sort of by having to verbalize that or type it out, you, you know, gain a little bit of self-awareness about what you're trying to do, what the struggles are. But also, it allows anybody else who has potentially helpful information to jump in. I think that's not my natural tendency. When I'm on something solo, I tend to kind of, like, zoom in and focus in on something and, like, ignore a little bit of the world around me. Like, that's almost the time when I should look at overcommunicating.

+ +

So, I think most times I've been on something solo, I sort of keep relearning this lesson of, like, you know, it's really important to constantly be talking out about the things that you're doing so that other people who are in a broader orbit around you can jump in where necessary.

+ +

STEPHANIE: Yeah, I think you actually kind of touched on one of the unexpected positives, at least for me. Something I wasn't expecting was how much time I would have to just be with my thoughts. You know, as I'm implementing or just in my head, I'm mulling over a problem. I have less frequent, not distractions necessarily, but interruptions. And sometimes, that has been a blessing because I am not in a spot where I have a lot of meetings right now. And so, I didn't realize how much generative thought happens when you are just kind of, like, doing your own thing for a little bit.

+ +

I'm curious, for you, is that, like, a space that you enjoy being when you're working by yourself? And I guess, you know, you were saying that it's not your natural state to kind of, like, share what's going on until maybe you've fully formed an idea.

+ +

JOËL: I think I often will regret not having shared out before everything is done. The times that I have done it, I've been like, that was a really positive experience; I should do that more. I think it's easy to sort of wait too long before sharing something out. And with so many things, it feels like there's only one more small task before it's done. Like, I just need to get this one test to go green, and then I can just put up a PR, and then we'll have a conversation about it. But then, oh, this other test broke, or this dependency isn't installing correctly.

+ +

And before you know it, you've spent a whole day chasing down these things and still haven't talked. And so, I think if some of those things were discussed earlier, it would help both to help me feel more plugged in, but also, I think everybody else feels like they're getting a chance to participate as well.

+ +

STEPHANIE: So, you mentioned, you know, obviously, there's, like, the time spent just arriving at the solution before sharing it out for feedback. But have you ever been in a position where there is no one to give you feedback and, like, not even a person to review your code?

+ +

JOËL: That's really challenging. So, occasionally, if I'm working on a project, maybe it would be, like, very early-stage startup that maybe just has, like, a founder, and then I'm, like, the only technical person on the team, generally, what I'll try to do is to have some kind of review buddy within thoughtbot, so some other developer who's not staffed on my project but who has access to the code such that I can ask them to say, "Hey, can you just take a look at this and give me a code review?" That's the ideal situation.

+ +

You know, some companies tend to lock things down a lot more if you're dealing with something like healthcare or something like that, where there might be some concerns around personal information, that kind of thing. But generally, in those cases, you can find somebody else within the company who will have some technical knowledge who can take a look at your code; at least, that's been my experience.

+ +

STEPHANIE: Nice. I don't think I've quite been in that position before; again, I've really mostly worked within a team. But there was a conference talk I watched a little bit ago from Jeremy Smith, and it was called Building Web Apps by Your Lonesome. And he is a, like, one-man agency. And he talked about, you know, what it's like to be in that position where you pretty much don't have other people to collaborate with, to review your code. And one thing that he said that I really liked was shifting between writer and editor mode.

+ +

If you are the person who has to kind of just decide when your code is good enough to merge, I like that transition between, like, okay, I just spent however many hours putting together the solution, and now I'm going to look at it with a critical eye. And sometimes I think that might require stepping away for a little bit or, like, revisiting it even the next day. That might be able to help see things that you weren't able to notice when you were in that writing mode. But I have found that distinction of roles really helpful because it does feel different when you're looking at it from those two lenses.

+ +

JOËL: I've definitely done that for some, like, personal solo projects, where I'm participating in a game jam or something, and then I am the only person to review my code. And so, I will definitely, at that point, do a sort of, like, personal code review where I'll look at it. Maybe I'm doing PRs on GitHub, and I'm just merging. Maybe I'm just doing a git diff and looking at a commit in the command line on my own machine.

+ +

But it is useful, even for myself, to sort of switch into that editor mode and just kind of look at everything there and say, "Is it in a good place?" Ideally, I think I do that before putting it out for a co-worker's review, so you kind of get both. But on a solo project, that has worked actually pretty well for me as well.

+ +

STEPHANIE: One thing that you and I have talked about before in a different context, I think, when we have chatted about writing conference talks, is you are really great about focusing on the audience. And I was thinking about this in relation to working solo because even when you are working by yourself on a project, you're not writing the code for yourself, even though you might feel like [laughs] it in the moment.

+ +

And I also kind of like the idea of asking, like, who are you building for? You know, can you ask the stakeholder or whoever has hired you, like, "Who will maintain this project in the future?" Because likely, it won't be you. Hopefully, it won't be you unless that's what you want to be doing.

+ +

There's also what my friend coined the circus factor as opposed to the bus factor, which is, like, if you ran away to the circus tomorrow [laughs], you know, what is the impact that would have? And yeah, I think working solo, you know, some people might think, like, oh, that gives me free rein to just write the code exactly how I want to, how I want to read it. But I think there is something to be said about thinking about the future of who will be [inaudible 18:10] what you just happen to be working on right now.

+ +

JOËL: And keep in mind that that person might be future you who might be coming back and be like, "What is going on here?" So, yeah, audience, I think, is a really important thing to keep in mind. I like to ask the question, if somebody else were looking at this code, and somebody else might be future me, what parts would they be confused by? If I was walking somebody else through the code for the first time, where would they kind of stop me through the walkthrough and be like, "Hey, why is this happening? What's the connection between these two things? I can see they're calling each other, but I don't know why."

+ +

And that's where maybe you put in a comment. Maybe you find a better method or a class name to better explain what happens. Maybe you need to put more context in a commit message. There's all sorts of tools that we can use to better increase documentation. But having that pause and asking, "What will confuse someone?" is, I think, one of the more powerful techniques I do when I'm doing self-review.

+ +

STEPHANIE: That's really cool. I'm glad you mentioned that, you know, it could also be future you. Because another thing that Jeremy says in this talk that I was just thinking about is the idea of optimizing for autonomy. And there's a lot to be said there because autonomy is like, yeah, like, you end up being the person who has to deal with problems [laughs], you know, if you run into something that you can't figure out, and, ideally, you'll have set yourself up for success.

+ +

But I think working solo doesn't mean that you are in your own universe by yourself completely. And thinking about future, you, too, is kind of, like, part of the idea that the person in this moment writing code will change [laughs]. You'll get new information. Maybe, like, you'll find out about, like, who might be working on this in the future. And it is kind of a fine balance between making sure that you're set up to handle problems, but at the same time, maybe it's that, like, you set anyone up to be able to take it away from where you left it.

+ +

JOËL: I want to take a few moments to sort of talk a little bit about what it means to be solo because I think there are sort of multiple different solo experiences that can be very different but also kind of converge on some similar themes. Maybe some of our listeners are listening to us talking and being like, "Well, I'm not at a consultancy, so this never happens to me." But you might find yourself in that position.

+ +

And I think one that we mentioned was maybe you are embedded on a team, but you're kind of on a bit of a larger project where you're staffed solo. So, even though you are part of a larger team, you do feel like the initiative that you're on is siloed to you a little bit. Are there any others that you'd like to highlight?

+ +

STEPHANIE: I think we also mentioned, you know, if you're a single developer working on an application because you might be the first technical hire, or a one-person agency, or something, that is different still, right? Because then your community is not even your company, but you have to kind of seek out external communities on social networks, or Slack groups, or whatever.

+ +

I've also really been interested in the idea of developers kind of being able to be rotated with some kind of frequency where you don't end up being the one person who knows everything about a system and kind of becomes this dependency, right? But how can we make projects so, like, well functioning that, like, anyone can step in to do some work and then move on? If that's just for a couple of weeks, for a couple of months. Do you have any thoughts about working solo in that kind of situation where you're just stepping into something, maybe even to help someone out who's, you know, on vacation, or kind of had to take an unexpected leave?

+ +

JOËL: Yeah, that can be challenging. And I think, ideally, as a team, if you want to make that easier, you have to set up some things both on a, like, social level and on a tactical level, so all the classic code quality things that you want in place, well structured, encapsulated code, good documentation, things like that. To a certain extent, even breaking down tasks into smaller sort of self-sufficient stories. I talk a lot about working incrementally.

+ +

But it's a lot easier to say, "Hey, we've got this larger story. It was broken down into 20 smaller pieces that can all be shipped independently, and a colleague got three of them done and then had to go on leave for some reason. Can you step in and do stories 4 through 20?" As opposed to, "Hey, we have this big, amorphous story, and your colleague did some work, and it kind of is done. There's a branch with some code on it. They left a few notes or maybe sent us an email. But they had to go on leave unexpectedly. Can you figure it out and get it done?" The second scenario is going to be much more challenging.

+ +

STEPHANIE: Yeah, I was just thinking about basically what you described, right? Where you might be working on your own, and you're like, well, I have this one ticket, and it's capturing everything, and I know all that's going on [laughs], even though it's not quite documented in the ticket. But it's, you know, maybe on my branch, or in my head, or, worst of all, on my local machine [laughs] without being pushed up.

+ +

JOËL: I think maybe that's an anti-pattern of working solo, right? A lot of these disciplines that you build when you're working in a team, such as breaking up tickets into smaller pieces, it's easy to kind of get a little bit lazy with them when you're working solo and let your tickets inflate a little bit, or just have stuff thrown together in branches on your local machine, which then makes it harder if somebody does need to come in to either collaborate with you or take over from you if you ever need to step aside.

+ +

STEPHANIE: Right. I have definitely seen some people, even just for their personal projects, use, like, a Trello board or some other project management tool. And I think that's really neat because then, you know, obviously, it's maybe just for their own, like, self-organization needs, but it's, like, that recognition that it's still a complicated project. And just because they're working by themselves doesn't mean that they can't utilize a tool for project management that is meant for teams or not even teams [laughs], you know, people use them for their own personal stuff all the time.

+ +

But I really like that you can choose different levels of how much you're documenting for your future self or for anyone else. You had mentioned earlier kind of the difference between opening up a PR for you...you have to merge your branch into main or whatever versus just committing to main. And that distinction might seem, like, if you were just working on a personal project, like, oh, you know, why go through the extra step? But that can be really valuable in terms of just seeing, like, that history, right?

+ +

JOËL: I think on solo projects, it can really depend on the way you tend to treat your commit history. I'm very careful with the history on the main branch where I want it to tell a sort of, like, cohesive story. Each commit is kind of, like, crafted a little bit. So, even when I'm working solo and I'm committing directly to master or to the main branch, I'm not just, like, throwing random things there. Ideally, every commit is green and builds and is, like, self-contained.

+ +

If you don't have that discipline, then it might be particularly valuable to go through the, like, a branching system or a PR system. Or if you just want, like, a place to experiment, just throw a bunch of code together, a bunch of things break; nothing is cohesive, that's fine. It's all a work in progress until you finally get to your endpoint, and then you squash it down, or you merge it, or whatever your workflow is, and then it goes back into the main branch.

+ +

So, I think that for myself, I have found that, oftentimes, I get not really a whole lot of extra value by going through a branching and PR system when it's, like, a truly solo project, you know, I'm building a side project, something like that. But that's not necessarily true for everyone.

+ +

STEPHANIE: I think one thing I've seen in other people's solo projects is using a PR description and, you know, having the branching strategy, even just to jot down future improvements or future ideas that they might take with the work, especially if you haven't kind of, like, taken the next step of having that project management system that we talked about. But there is, like, a little more room for some extra context or to, like, leave yourself little notes that you might not want necessarily in your commit history but is maybe more related to this project being, like, a work in progress where it could go in a lot of different directions, and you're figuring that out by yourself.

+ +

JOËL: Yeah, I mean, definitely something like a draft PR can be a great place to have work in progress and experiment and things like that. Something you were saying got me wondering what distinction you typically have between what you would put in a commit message versus something that you would put in a PR description, particularly given that if you've got, like, a single commit PR, GitHub will automatically make the commit message your PR message as well.

+ +

STEPHANIE: This has actually evolved for me over time, where I used to be a lot more reliant on PR descriptions holding a lot of the context in terms of the decision-making. I think that was because I thought that, like, that was the most accessible place of information for reviewers to find out, you know, like, why certain decisions were made. And we were using, you know, PR templates and stuff like that.

+ +

But now the team that I'm working on uses commit message templates that kind of contain the information I would have put in a PR, including, like, motivation for the change, any risks, even deployment steps. So, I have enjoyed that because I think it kind of shortens the feedback loop, too, right? You know, you might be committing more frequently but not, you know, opening a PR until later. And then you have to revisit your commits to figure out, like, okay, what did I do here? But if you are putting that thought as soon as you have to commit, that can save you a little bit of work down the line.

+ +

What you said about GitHub just pulling your commit message into the PR description has been really nice because then I could just, like, open a thing [laughs]. And that has been nice.

+ +

I think one aspect that I really like about the PR is leaving myself or reviewers, like, notes via comments, like, annotating things that should not necessarily live in a more permanent form. But maybe I will link to documentation for a method that I'm using that's a little less common or just add some more information about why I made this decision over another at a more granular level.

+ +

JOËL: Yeah, I think that's probably one of the main things that I tend to put in a PR message rather than the commit message is any sort of extra information that will be helpful at review time. So, maybe it's a comment that says, "Hey, there is a lot of churn in this PR. You will probably have a better experience if you review this in split view versus unified view," things like that.

+ +

So, kind of, like, meta comments about how you might want to approach reviewing this PR, as opposed to something that, let's say somebody is reviewing the history or is, like, browsing the code later, that wouldn't be relevant to them because they're not in a code review mindset. They're in a, like, code reading, code understanding mindset or looking at the message to say, "Why did you make the changes? I saw this weird method. Why did you introduce that?" So, hopefully, all of that context is in the commit message.

+ +

STEPHANIE: Yeah, you reminded me of something else that I do, which is leave notes to my future self to revisit something if I'm like, oh, like, this was the first idea I had for the, you know, the way to solve this problem but, you know, note to self to look at this again tomorrow, just in case I have another idea or even to, like, you know, do some more research or ask someone about it and see if they have any other ideas for how to implement what I was aiming for.

+ +

And I think that is the editor mode that we were talking about earlier that can be really valuable when you're working by yourself to spend a little extra time doing. You know, you are essentially optimizing for autonomy by being your own reviewer or your own critic in a healthy and positive way [laughs], hopefully.

+ +

JOËL: Exactly.

+ +

STEPHANIE: So, at the beginning of this episode, I mentioned that this is a new experience for me, and I'm not sure that I would love to do it all of the time. But I'm wondering, Joël, if there are any, you know, benefits or positives to working solo that you enjoy and find that you like to do just at least for a short or temporary amount of time.

+ +

JOËL: I think one that I appreciate that's maybe a classic developer response is the heads downtime, the focus, being able to just sit down with a problem and a code editor and trying to figure it out. There are times where you really need to break out of that. You need somebody else to challenge you to get through a problem. But there are also just amazing times where you're in that flow state, and you're getting things done. And that can be really nice when you're solo.

+ +

STEPHANIE: Yeah, I agree. I have been enjoying that, too. But I also definitely am looking forward to working with others on a team, so it's kind of fun having to get to experience both ways of operating.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël got to do some pretty fancy single sign-on work. And when it came time to commit, he documented the ridiculous number of redirects to give people a sense of what was happening. Stephanie has been exploring Rails callbacks and Ruby debugging tools, using methods like save_callbacks and Kernel.caller, and creating a function call graph to better understand and manage complex code dependencies.

+ +

Stephanie is also engaged in an independent project and seeking strategies to navigate the challenges of solo work. She and Joël explore how to find external support and combat isolation, consider ways to stimulate creativity, and obtain feedback on her work without a direct team. Additionally, they ponder succession planning to ensure project continuity after her involvement ends. They also reflect on the unique benefits of solo work, such as personal growth and flexibility. Stephanie's focus is on balancing the demands of working independently while maintaining a connected and sustainable professional approach.

+ +
+ +

ASCII Sequence Diagram Creator
+Callback debugging methods
+Kernel.caller
+Method.source_location
+Building web apps by your lonesome by Jeremy Smith

+ +
+ +

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: I got to do something really fun this week, where I was doing some pretty fancy single sign-on work. And when it came time to commit, I wanted to document the kind of ridiculous number of redirects that happen and give people a sense of what was going on.

+ +

And for my own self, what I had been doing is, I had done a sequence diagram that sort of shows, like, three different services that are all talking to each other and where they redirect to each other as they all go through the sequence to sign someone in. And I was like, how could I embed that in the commit message? Because I think it would be really useful context for someone trying to get an overview of what this commit is doing.

+ +

And the answer, for me, was, can I get this sequence diagram in ASCII form somewhere? And I found a website that allows me to do this in ASCII art. It's the textart.io/sequence. And that allows me to create a sequence diagram that gets generated as ASCII art. I can copy-paste that into a commit message. And now anybody else who is like, "What is it that Joël is trying to do here?" can look at that and be like, "Oh, oh okay, so, we got these, like, four different places that are all talking to each other in this order. Now I see what's happening."

+ +

STEPHANIE: That's super neat. I love the idea of having it directly in your commit message just because, you know, you don't have to go and find a graph elsewhere if you want to understand what's going on. It's right there for you, for future commit explorers [laughs] trying to understand what was going on in this snippet of time.

+ +

JOËL: I try as much as possible to include those sorts of things directly in the commit message because you never know who's reading the commit. They might not have access to some sort of linked resource. So, if I were like, "Hey, go to our wiki and see this link," like, sure, that would be helpful, but maybe the person reading it doesn't have access to the wiki. Maybe they do have access, but they're not on the internet right now, and so they don't have access to the wiki. Maybe the wiki no longer exists, and that's a dead link. So, as much as possible, I try to embed context directly in my commit messages.

+ +

STEPHANIE: That's really cool. And just another shout out to ASCII art, you know [laughs], persevering through all the times with our fancy tools. It's still going strong [laughs].

+ +

JOËL: Something about text, right?

+ +

STEPHANIE: Exactly. I actually also have a diagram graph thing to share about what's new in my world that is kind of in a similar vein. Another thoughtboter and former guest on the show, Sara Jackson, shared in our dev channel about this really cool mural graph that she made to figure out what was going on with callbacks because she was working on, you know, understanding the lifecycle of this model and was running into, like, a lot of complex behavior.

+ +

And she linked to a really neat blog post by Andy Croll, too, that included a little snippet sharing a few callback debugging methods that are provided by ActiveRecord. So, basically, you can have your model and just call double underscore callbacks. And it returns a list of all the callbacks that are defined for that model, and I thought that was really neat. So, I played around with it and copypastad [laughs] the snippet into my Rails console to figure out what's going on with basically, like, the god object of that that I work in.

+ +

And the first issue I ran into was that it was undefined because it turns out that my application was on an older [laughs] version of Rails than that method was provided on. But, there are more specific methods for the types of callbacks. So, if you are looking specifically for all the callbacks related to a save or a destroy, I think it's save underscore callbacks, right? And that was available on the Rails version I was on, which was, I think, 4. But that was a lot of fun to play around with.

+ +

And then, I ended up chatting with Sara afterwards about her process for creating the diagram after, you know, getting a list of all these methods. And I actually really liked this hybrid approach she took where, you know, she automated some parts but then also manually, like, went through and stepped through the code and, like, annotated notes for the methods as she was traversing them.

+ +

And, you know, sometimes I think about, like, wow, like, it would be so cool if this graph just generated automatically, but I also think there is some value to actually creating it yourself. And there's some amount of, like, mental processing that happens when you do that, as opposed to, like, looking at a thing that was just, you know, generated afterwards, I think.

+ +

JOËL: Do you know what kind of graph Sara generated? Was it some kind of, like, function call graph, or was it some other way of visualizing the callbacks?

+ +

STEPHANIE: I think it was a function call graph, essentially. It even kind of showed a lot of the dependencies, too, because some of the callback functions were quite complicated and then would call other classes. So, there was a lot of, I think, hidden dependencies there that were unexpected, you know, when you think you're just going to create a regular old [laughs] record.

+ +

JOËL: Yeah, I've been burned by unexpected callbacks or callbacks that do things that you wouldn't want in a particular context and then creating bad data or firing off external services that you really didn't want, and that can be an unpleasant surprise. I appreciate it when the framework offers debugging tools and methods kind of built-in, so these helpers, which I was not aware of. It's really cool because they allow you to kind of introspect and understand the code that you're going through. Do you have any others like that from Rails or Ruby that you find yourself using from time to time to help better understand the code?

+ +

STEPHANIE: I think one I discovered recently was Kernel.caller, which gives you the stack trace wherever you are when executing. And that was really helpful when you're not raising an exception in certain places, and you need to figure out the flow of the code. I think that was definitely a later discovery. And I'm glad to have it in my back pocket now as something I can use in any kind of Ruby code.

+ +

JOËL: That can, yeah, definitely be a really useful context to have even just in, like, an interactive console. You're like, wait a minute, where's this coming from? What is the call stack right now?

+ +

STEPHANIE: Do you have any debugging tools or methods that you like to use that maybe are under the radar a little bit?

+ +

JOËL: One that I really appreciate that's built into Ruby is the source location method on the method object, so Ruby has a method object. And so, when you're dealing with some sort of method and, like, maybe it got generated programmatically through metaprogramming, or maybe it's coming from a gem or something like that, and you're just like, where is this define? I'm trying to find it.

+ +

If you're in your editor and you're doing stuff, maybe you could run some sort of search, or maybe it has some sort of keyword lookup where you can just find the definition of what's under your cursor. But if you're in an interactive console, you can create a method object for that method name and then call dot source location on it. And it will tell you, here's where it's defined. So, very handy in the right circumstances.

+ +

STEPHANIE: Awesome. That's a great tip.

+ +

JOËL: Of course, one of the most effective debugging tools is having a pair, having somebody else work with you, but that's not always something that you have. And you and I were talking recently about what it's like to work solo on a project. Because you're currently on a project, you're solo, at least from the thoughtbot side of things. You're embedding with a team, with a client. Are you working on kind of, like, a solo subtask within that, or are you still kind of embedding and interacting with the other teammates on a regular basis?

+ +

STEPHANIE: Yeah. So, the past couple of weeks, I am working on more of a solo initiative. The other members of my client team are kind of ramping up on some other projects for this next quarter. And since my engagement is ending soon, I'm kind of left working on some more residual tasks by myself. And this is new for me, actually. I've not really worked in a super siloed by-myself kind of way before. I usually have at least one other dev who I'm, like, kind of partnering up with on a project, or an epic, or something like that.

+ +

And so, I've had a very quiet week where no one is, you know, kind of, like, reaching out to me and asking me to review their code, or kind of checking in, or, you know, asking me to check in with them. And yeah, it's just a little bit different than how I think I like to normally work. I do like to work with other people. So, this week has been interesting in terms of just kind of being a more different experience where I'm not as actively collaborating with others.

+ +

JOËL: What do you think are some of the biggest challenges of being kind of a little bit out in your own world?

+ +

STEPHANIE: I think the challenges for me can definitely be the isolation [laughs], and also, what kind of goes hand in hand with that is when you need help, you know, who can you turn to? There's not as much of an obvious person on your team to reach out to, especially if they're, like, involved with other work, right? And that can be kind of tough.

+ +

Some of the other ones that I've been thinking about have been, you know, on one hand, like, I get to make all of the decisions that I want [laughs], but sometimes you kind of get, like, really in your own head about it. And you're not in that space of, like, evaluating different solutions that you maybe might not think of. And I've been trying to figure out how to, like, mitigate some of that risk.

+ +

JOËL: What are some of the strategies that you use to try to balance, like making good decisions when you're a bit more solo? Do you try to pull in someone from another team to talk ideas through? Do you have some sort of internal framework that you use to try to figure out things on your own? What does that look like?

+ +

STEPHANIE: Yeah, luckily, the feature I'm working on is not a huge project. Well, if it were, I think then I wouldn't be alone on it. But, you know, sometimes you find yourself kind of tasked with one big thing for a while, and you are responsible for from start to finish, like all of the architectural decisions to implementation. But, at least for me, the scope is a little more narrow. And so, I don't feel as much of a need to get a lot of heads together because I at least feel somewhat confident in what I'm doing [laughs].

+ +

But I have found myself being a bit more compelled to kind of just verbalize what I'm doing more frequently, even to, like, myself in Slack sometimes. It's just like, I don't know who's reading this, but I'm just going to put it out there because maybe someone will see this and jump in and say, "Oh, like, interesting. Here's some other context that I have that maybe might steer you away from that," or even validating what I have to say, right? Like, "That sounds like a good idea," or, you know, just giving me an emoji reaction [laughs] is sometimes all I need.

+ +

So, either in Slack or when we give our daily sync updates, I am, I think, offering a little more details than I might if I already was working with someone who I was more in touch with in an organic way.

+ +

JOËL: And I think that's really powerful because it benefits you. Sort of by having to verbalize that or type it out, you, you know, gain a little bit of self-awareness about what you're trying to do, what the struggles are. But also, it allows anybody else who has potentially helpful information to jump in. I think that's not my natural tendency. When I'm on something solo, I tend to kind of, like, zoom in and focus in on something and, like, ignore a little bit of the world around me. Like, that's almost the time when I should look at overcommunicating.

+ +

So, I think most times I've been on something solo, I sort of keep relearning this lesson of, like, you know, it's really important to constantly be talking out about the things that you're doing so that other people who are in a broader orbit around you can jump in where necessary.

+ +

STEPHANIE: Yeah, I think you actually kind of touched on one of the unexpected positives, at least for me. Something I wasn't expecting was how much time I would have to just be with my thoughts. You know, as I'm implementing or just in my head, I'm mulling over a problem. I have less frequent, not distractions necessarily, but interruptions. And sometimes, that has been a blessing because I am not in a spot where I have a lot of meetings right now. And so, I didn't realize how much generative thought happens when you are just kind of, like, doing your own thing for a little bit.

+ +

I'm curious, for you, is that, like, a space that you enjoy being when you're working by yourself? And I guess, you know, you were saying that it's not your natural state to kind of, like, share what's going on until maybe you've fully formed an idea.

+ +

JOËL: I think I often will regret not having shared out before everything is done. The times that I have done it, I've been like, that was a really positive experience; I should do that more. I think it's easy to sort of wait too long before sharing something out. And with so many things, it feels like there's only one more small task before it's done. Like, I just need to get this one test to go green, and then I can just put up a PR, and then we'll have a conversation about it. But then, oh, this other test broke, or this dependency isn't installing correctly.

+ +

And before you know it, you've spent a whole day chasing down these things and still haven't talked. And so, I think if some of those things were discussed earlier, it would help both to help me feel more plugged in, but also, I think everybody else feels like they're getting a chance to participate as well.

+ +

STEPHANIE: So, you mentioned, you know, obviously, there's, like, the time spent just arriving at the solution before sharing it out for feedback. But have you ever been in a position where there is no one to give you feedback and, like, not even a person to review your code?

+ +

JOËL: That's really challenging. So, occasionally, if I'm working on a project, maybe it would be, like, very early-stage startup that maybe just has, like, a founder, and then I'm, like, the only technical person on the team, generally, what I'll try to do is to have some kind of review buddy within thoughtbot, so some other developer who's not staffed on my project but who has access to the code such that I can ask them to say, "Hey, can you just take a look at this and give me a code review?" That's the ideal situation.

+ +

You know, some companies tend to lock things down a lot more if you're dealing with something like healthcare or something like that, where there might be some concerns around personal information, that kind of thing. But generally, in those cases, you can find somebody else within the company who will have some technical knowledge who can take a look at your code; at least, that's been my experience.

+ +

STEPHANIE: Nice. I don't think I've quite been in that position before; again, I've really mostly worked within a team. But there was a conference talk I watched a little bit ago from Jeremy Smith, and it was called Building Web Apps by Your Lonesome. And he is a, like, one-man agency. And he talked about, you know, what it's like to be in that position where you pretty much don't have other people to collaborate with, to review your code. And one thing that he said that I really liked was shifting between writer and editor mode.

+ +

If you are the person who has to kind of just decide when your code is good enough to merge, I like that transition between, like, okay, I just spent however many hours putting together the solution, and now I'm going to look at it with a critical eye. And sometimes I think that might require stepping away for a little bit or, like, revisiting it even the next day. That might be able to help see things that you weren't able to notice when you were in that writing mode. But I have found that distinction of roles really helpful because it does feel different when you're looking at it from those two lenses.

+ +

JOËL: I've definitely done that for some, like, personal solo projects, where I'm participating in a game jam or something, and then I am the only person to review my code. And so, I will definitely, at that point, do a sort of, like, personal code review where I'll look at it. Maybe I'm doing PRs on GitHub, and I'm just merging. Maybe I'm just doing a git diff and looking at a commit in the command line on my own machine.

+ +

But it is useful, even for myself, to sort of switch into that editor mode and just kind of look at everything there and say, "Is it in a good place?" Ideally, I think I do that before putting it out for a co-worker's review, so you kind of get both. But on a solo project, that has worked actually pretty well for me as well.

+ +

STEPHANIE: One thing that you and I have talked about before in a different context, I think, when we have chatted about writing conference talks, is you are really great about focusing on the audience. And I was thinking about this in relation to working solo because even when you are working by yourself on a project, you're not writing the code for yourself, even though you might feel like [laughs] it in the moment.

+ +

And I also kind of like the idea of asking, like, who are you building for? You know, can you ask the stakeholder or whoever has hired you, like, "Who will maintain this project in the future?" Because likely, it won't be you. Hopefully, it won't be you unless that's what you want to be doing.

+ +

There's also what my friend coined the circus factor as opposed to the bus factor, which is, like, if you ran away to the circus tomorrow [laughs], you know, what is the impact that would have? And yeah, I think working solo, you know, some people might think, like, oh, that gives me free rein to just write the code exactly how I want to, how I want to read it. But I think there is something to be said about thinking about the future of who will be [inaudible 18:10] what you just happen to be working on right now.

+ +

JOËL: And keep in mind that that person might be future you who might be coming back and be like, "What is going on here?" So, yeah, audience, I think, is a really important thing to keep in mind. I like to ask the question, if somebody else were looking at this code, and somebody else might be future me, what parts would they be confused by? If I was walking somebody else through the code for the first time, where would they kind of stop me through the walkthrough and be like, "Hey, why is this happening? What's the connection between these two things? I can see they're calling each other, but I don't know why."

+ +

And that's where maybe you put in a comment. Maybe you find a better method or a class name to better explain what happens. Maybe you need to put more context in a commit message. There's all sorts of tools that we can use to better increase documentation. But having that pause and asking, "What will confuse someone?" is, I think, one of the more powerful techniques I do when I'm doing self-review.

+ +

STEPHANIE: That's really cool. I'm glad you mentioned that, you know, it could also be future you. Because another thing that Jeremy says in this talk that I was just thinking about is the idea of optimizing for autonomy. And there's a lot to be said there because autonomy is like, yeah, like, you end up being the person who has to deal with problems [laughs], you know, if you run into something that you can't figure out, and, ideally, you'll have set yourself up for success.

+ +

But I think working solo doesn't mean that you are in your own universe by yourself completely. And thinking about future, you, too, is kind of, like, part of the idea that the person in this moment writing code will change [laughs]. You'll get new information. Maybe, like, you'll find out about, like, who might be working on this in the future. And it is kind of a fine balance between making sure that you're set up to handle problems, but at the same time, maybe it's that, like, you set anyone up to be able to take it away from where you left it.

+ +

JOËL: I want to take a few moments to sort of talk a little bit about what it means to be solo because I think there are sort of multiple different solo experiences that can be very different but also kind of converge on some similar themes. Maybe some of our listeners are listening to us talking and being like, "Well, I'm not at a consultancy, so this never happens to me." But you might find yourself in that position.

+ +

And I think one that we mentioned was maybe you are embedded on a team, but you're kind of on a bit of a larger project where you're staffed solo. So, even though you are part of a larger team, you do feel like the initiative that you're on is siloed to you a little bit. Are there any others that you'd like to highlight?

+ +

STEPHANIE: I think we also mentioned, you know, if you're a single developer working on an application because you might be the first technical hire, or a one-person agency, or something, that is different still, right? Because then your community is not even your company, but you have to kind of seek out external communities on social networks, or Slack groups, or whatever.

+ +

I've also really been interested in the idea of developers kind of being able to be rotated with some kind of frequency where you don't end up being the one person who knows everything about a system and kind of becomes this dependency, right? But how can we make projects so, like, well functioning that, like, anyone can step in to do some work and then move on? If that's just for a couple of weeks, for a couple of months. Do you have any thoughts about working solo in that kind of situation where you're just stepping into something, maybe even to help someone out who's, you know, on vacation, or kind of had to take an unexpected leave?

+ +

JOËL: Yeah, that can be challenging. And I think, ideally, as a team, if you want to make that easier, you have to set up some things both on a, like, social level and on a tactical level, so all the classic code quality things that you want in place, well structured, encapsulated code, good documentation, things like that. To a certain extent, even breaking down tasks into smaller sort of self-sufficient stories. I talk a lot about working incrementally.

+ +

But it's a lot easier to say, "Hey, we've got this larger story. It was broken down into 20 smaller pieces that can all be shipped independently, and a colleague got three of them done and then had to go on leave for some reason. Can you step in and do stories 4 through 20?" As opposed to, "Hey, we have this big, amorphous story, and your colleague did some work, and it kind of is done. There's a branch with some code on it. They left a few notes or maybe sent us an email. But they had to go on leave unexpectedly. Can you figure it out and get it done?" The second scenario is going to be much more challenging.

+ +

STEPHANIE: Yeah, I was just thinking about basically what you described, right? Where you might be working on your own, and you're like, well, I have this one ticket, and it's capturing everything, and I know all that's going on [laughs], even though it's not quite documented in the ticket. But it's, you know, maybe on my branch, or in my head, or, worst of all, on my local machine [laughs] without being pushed up.

+ +

JOËL: I think maybe that's an anti-pattern of working solo, right? A lot of these disciplines that you build when you're working in a team, such as breaking up tickets into smaller pieces, it's easy to kind of get a little bit lazy with them when you're working solo and let your tickets inflate a little bit, or just have stuff thrown together in branches on your local machine, which then makes it harder if somebody does need to come in to either collaborate with you or take over from you if you ever need to step aside.

+ +

STEPHANIE: Right. I have definitely seen some people, even just for their personal projects, use, like, a Trello board or some other project management tool. And I think that's really neat because then, you know, obviously, it's maybe just for their own, like, self-organization needs, but it's, like, that recognition that it's still a complicated project. And just because they're working by themselves doesn't mean that they can't utilize a tool for project management that is meant for teams or not even teams [laughs], you know, people use them for their own personal stuff all the time.

+ +

But I really like that you can choose different levels of how much you're documenting for your future self or for anyone else. You had mentioned earlier kind of the difference between opening up a PR for you...you have to merge your branch into main or whatever versus just committing to main. And that distinction might seem, like, if you were just working on a personal project, like, oh, you know, why go through the extra step? But that can be really valuable in terms of just seeing, like, that history, right?

+ +

JOËL: I think on solo projects, it can really depend on the way you tend to treat your commit history. I'm very careful with the history on the main branch where I want it to tell a sort of, like, cohesive story. Each commit is kind of, like, crafted a little bit. So, even when I'm working solo and I'm committing directly to master or to the main branch, I'm not just, like, throwing random things there. Ideally, every commit is green and builds and is, like, self-contained.

+ +

If you don't have that discipline, then it might be particularly valuable to go through the, like, a branching system or a PR system. Or if you just want, like, a place to experiment, just throw a bunch of code together, a bunch of things break; nothing is cohesive, that's fine. It's all a work in progress until you finally get to your endpoint, and then you squash it down, or you merge it, or whatever your workflow is, and then it goes back into the main branch.

+ +

So, I think that for myself, I have found that, oftentimes, I get not really a whole lot of extra value by going through a branching and PR system when it's, like, a truly solo project, you know, I'm building a side project, something like that. But that's not necessarily true for everyone.

+ +

STEPHANIE: I think one thing I've seen in other people's solo projects is using a PR description and, you know, having the branching strategy, even just to jot down future improvements or future ideas that they might take with the work, especially if you haven't kind of, like, taken the next step of having that project management system that we talked about. But there is, like, a little more room for some extra context or to, like, leave yourself little notes that you might not want necessarily in your commit history but is maybe more related to this project being, like, a work in progress where it could go in a lot of different directions, and you're figuring that out by yourself.

+ +

JOËL: Yeah, I mean, definitely something like a draft PR can be a great place to have work in progress and experiment and things like that. Something you were saying got me wondering what distinction you typically have between what you would put in a commit message versus something that you would put in a PR description, particularly given that if you've got, like, a single commit PR, GitHub will automatically make the commit message your PR message as well.

+ +

STEPHANIE: This has actually evolved for me over time, where I used to be a lot more reliant on PR descriptions holding a lot of the context in terms of the decision-making. I think that was because I thought that, like, that was the most accessible place of information for reviewers to find out, you know, like, why certain decisions were made. And we were using, you know, PR templates and stuff like that.

+ +

But now the team that I'm working on uses commit message templates that kind of contain the information I would have put in a PR, including, like, motivation for the change, any risks, even deployment steps. So, I have enjoyed that because I think it kind of shortens the feedback loop, too, right? You know, you might be committing more frequently but not, you know, opening a PR until later. And then you have to revisit your commits to figure out, like, okay, what did I do here? But if you are putting that thought as soon as you have to commit, that can save you a little bit of work down the line.

+ +

What you said about GitHub just pulling your commit message into the PR description has been really nice because then I could just, like, open a thing [laughs]. And that has been nice.

+ +

I think one aspect that I really like about the PR is leaving myself or reviewers, like, notes via comments, like, annotating things that should not necessarily live in a more permanent form. But maybe I will link to documentation for a method that I'm using that's a little less common or just add some more information about why I made this decision over another at a more granular level.

+ +

JOËL: Yeah, I think that's probably one of the main things that I tend to put in a PR message rather than the commit message is any sort of extra information that will be helpful at review time. So, maybe it's a comment that says, "Hey, there is a lot of churn in this PR. You will probably have a better experience if you review this in split view versus unified view," things like that.

+ +

So, kind of, like, meta comments about how you might want to approach reviewing this PR, as opposed to something that, let's say somebody is reviewing the history or is, like, browsing the code later, that wouldn't be relevant to them because they're not in a code review mindset. They're in a, like, code reading, code understanding mindset or looking at the message to say, "Why did you make the changes? I saw this weird method. Why did you introduce that?" So, hopefully, all of that context is in the commit message.

+ +

STEPHANIE: Yeah, you reminded me of something else that I do, which is leave notes to my future self to revisit something if I'm like, oh, like, this was the first idea I had for the, you know, the way to solve this problem but, you know, note to self to look at this again tomorrow, just in case I have another idea or even to, like, you know, do some more research or ask someone about it and see if they have any other ideas for how to implement what I was aiming for.

+ +

And I think that is the editor mode that we were talking about earlier that can be really valuable when you're working by yourself to spend a little extra time doing. You know, you are essentially optimizing for autonomy by being your own reviewer or your own critic in a healthy and positive way [laughs], hopefully.

+ +

JOËL: Exactly.

+ +

STEPHANIE: So, at the beginning of this episode, I mentioned that this is a new experience for me, and I'm not sure that I would love to do it all of the time. But I'm wondering, Joël, if there are any, you know, benefits or positives to working solo that you enjoy and find that you like to do just at least for a short or temporary amount of time.

+ +

JOËL: I think one that I appreciate that's maybe a classic developer response is the heads downtime, the focus, being able to just sit down with a problem and a code editor and trying to figure it out. There are times where you really need to break out of that. You need somebody else to challenge you to get through a problem. But there are also just amazing times where you're in that flow state, and you're getting things done. And that can be really nice when you're solo.

+ +

STEPHANIE: Yeah, I agree. I have been enjoying that, too. But I also definitely am looking forward to working with others on a team, so it's kind of fun having to get to experience both ways of operating.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeeee!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+iGFCJscy + + ]]> + + Joël Quenneville + Stephanie Minn + + + 405: Retro: Sandi Metz Rules + https://bikeshed.thoughtbot.com/405 + ed004dcf-e6ea-4cd8-ade7-ee6794965038 + Tue, 07 Nov 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie discovered a new book: The Staff Engineer's Path! Joël's got some D&D goodness. + +Together, they revisit a decade-old blog post initially published in 2013, which discussed the application of Sandi Metz's coding guidelines and whether these rules remain relevant and practiced among developers today. + 31:58 + no + + + Stephanie discovered a new book: The Staff Engineer's Path! Joël's got some D&D goodness. +Together, they revisit a decade-old blog post initially published in 2013, which discussed the application of Sandi Metz's coding guidelines and whether these rules remain relevant and practiced among developers today. +The Manager’s Path (https://www.goodreads.com/en/book/show/33369254) +The Staff Engineer’s Path (https://www.goodreads.com/en/book/show/61058107) +Not Another D&D Podcast (https://naddpod.com/) +Sandi Metz rules for developers (https://thoughtbot.com/blog/sandi-metz-rules-for-developers) +Bike Shed episode on heuristics (https://www.bikeshed.fm/398) +In Relentless Pursuit of REST (https://www.youtube.com/watch?v=HctYHe-YjnE) +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, I picked up a new book from the library [laughs], which that in itself is not very new. That is [laughs] a common occurrence in my world. But it was kind of a fun coincidence that I was just walking around the aisles of what's new in nonfiction, and staring me right in the face was an O'Reilly book, The Staff Engineer's Path. And I think in the past, I've plugged The Manager's Path by Camille Fournier on the show. +And in recent years, this one was published, and it's by Tanya Reilly. And it is kind of, like, the other half of a career path for software engineers moving up in seniority at those higher levels. And it has been a really interesting companion to The Manager's Path, which I had read even though I wasn't really sure I wanted to be manager [laughs]. +And now I think I get that, like, accompaniment of like, okay, like, instead of walking that path, like, what does a staff plus engineer look like? And kind of learning a little bit more about that because I know it can be really vague or ambiguous or look very different at a lot of different companies. And that has been really helpful for me, kind of looking ahead a bit. I'm not too far into it yet. But I'm looking forward to reading more and bringing back some of those learnings to the show. +JOËL: I feel like at the end of the year, Stephanie, you and I are probably going to have to sit down and talk through maybe your reading list for the year and, you know, maybe shout out some favorites. I think your reading list is probably significantly longer than mine. But you're constantly referencing cool books. I think that would probably be a fun, either end-of-year episode or a beginning-of-year episode for 2024. +One thing that's really interesting, though, about the contrast of these two particular books you're talking about is how it really lines up with this, like, fork in the road that a lot of us have in our careers as we get more senior. You either move into more of a management role, which can be a pretty significant departure from what you have to do as a developer, or you kind of go into this, like, ultra-senior individual contributor path. But how that looks day to day can be very different from your sort of just traditional sitting down and banging out tickets. So, it's really cool there's two books looking at both of those paths. +STEPHANIE: Yeah, absolutely. And I think the mission that they were going for with these books was to kind of illuminate a little bit more about that fork and that decision because, you know, it can be easy for people to maybe just default into one or the other based on what their organization wants for them without, like, fully knowing what that means. And the more senior you get, the more vague and, like, figure it out yourself [laughs] the work becomes. +And it can be very daunting to kind of just be thrown into that and be like, well, I'm in this leadership position now. People are looking to me, and I have all this responsibility, but, like, what do I do? Yeah, so I'm kind of enjoying this book, that is...it's not a technical book, which is actually kind of what I like about it. It's actually more of a leadership book, which is really important for that kind of role. Even though, you know, they are still in that IC track, but it does come with a lot of leadership responsibility. +JOËL: Yes, leadership in a very different way than management. But—and this may be counterintuitive for some people, especially earlier on in their careers—going further up that individual contributor track doesn't just mean getting more intense technically. It often means you've got to focus on things more like leadership, like being a bit more strategic, aligning technical initiatives with strategic goals. +STEPHANIE: Yeah, and having a bigger impact and being a force multiplier, even in both the manager and, like, the staff plus role, like, that, you know, is the thing that ties the rising level. +JOËL: Yeah, in many ways, maybe the individual contributor track is slightly misnamed because while, yes, you're not managing a sort of sub-organization within the company, it's still about being a force multiplier. +STEPHANIE: Yeah, that's a really great point [laughs]. Maybe we'll be able to come up with a better [laughs] name for that. +JOËL: I've mentioned several times on this podcast that I've been enjoying playing Dungeons & Dragons, D&D, with some friends and some colleagues. And something that was particularly fun that some friends and I did this summer is we hired a professional DM to run one shot for us. And that was just an absolutely lovely experience. Well, as a result of that, I am now subscribed to this guy's newsletter. And he'll do, like, various D&D events at different times. +One thing that was really cool that I found out recently...as we're recording this, it's the week before election day in the U.S. And because a lot of voting happens in schools, typically, schools have the day off. And so, this guy sent out an email saying he was offering to run a, like, all day...effectively, a little mini-D&D camp for school-age kids on election day so that you can do your work. You can go vote, and you don't have to...basically, he'll watch your kids for you and, like, get them introduced to playing D&D, which I think is just a really cool thing to do. +STEPHANIE: I love that. It's so heartwarming [laughs]. And it's such a great idea because, oftentimes, people are still working, and so they need childcare, like, on those kinds of days. And yeah, I think D&D is such a fun thing for kids to get into, too. You know, it requires so much, like, imagination, and I can imagine it's such a blast. +JOËL: I got that email, and I was like, that is such a perfect idea. I love it so much. +STEPHANIE: I wanted to plug my D&D recommendation. I'm pretty sure I have mentioned it on the show before. But there is a podcast that I listen to called Not Another D&D Podcast, which is, you know, a live play Dungeons & Dragons podcast campaign that's hosted by these comedians, formerly of CollegeHumor, and it's very fun. I always laugh. +They have this, like, a kind of offshoot of the main show that they do called D&D Court, which is very fun. Because, as you were saying, like, you know, you hired a DM to run your game. And I know that...I'm sure lots of people have fun stories about their home games and, like, the drama that happens [laughs] with their friends. +JOËL: Absolutely. Absolutely. +STEPHANIE: And so, with D&D Court, listeners can write in with their drama or their conflicts and get an official ruling from the hosts about who was right [laughs] in the situation that they write in about. +JOËL: So, you get to bring your best rules lawyering to the D&D Court. +STEPHANIE: Yeah, exactly [laughs]. +JOËL: That sounds kind of amazing. +Recently, I had someone reach out to me asking about an older blog post that we'd written about the Sandi Metz Rules. This blog post was initially published in 2013, so ten years ago, and was talking about some guidelines that Sandi Metz at the time was talking about that she was using in some of her code. And we talked about how our experience was applying those to some of our work as well. And so, the question was, you know, ten years later, is that still something that thoughtbot developers like to follow in their code? +We'll link to the article in the show notes. But I'll just read out the rules here real quick. So, there's four of them. The first one is a class can be no longer than 100 lines of code. The second is a method can be no longer than five lines of code. The third is pass no more than four parameters into a method, and hash options count, so no getting clever with those. And then, finally, controllers can only instantiate one object. You only get one instance variable. And views can only talk to that one instance variable. +Had you or are you familiar with these rules? Is that something that you think about or use in your daily writing of code? +STEPHANIE: Yeah. So, when you proposed this topic, I had to revisit these rules. And I can't recall if I had seen them before. They seemed familiar. And I've read, you know, a couple of Sandi Metz's books, so maybe those were places where she had mentioned them. +But the one thing that really struck me when I was first reading the rules was how declarative they were in terms of, like, kind of just telling you what the results should be without really saying how. So, for example, the one where you said, you know, a method should not be more than five lines [laughs], I had the silly thought of, like, well, you could just, you know, stuff everything into a single line [laughs] and just completely disregard line limit if you wanted, and it would technically still follow the rule. +JOËL: If they didn't want us to do that, they wouldn't give us semicolons in Ruby. +STEPHANIE: Exactly [laughs]. So, that is kind of what struck me at first. Is that something you noticed? +JOËL: I think what is interesting with them is that there's not always a ton of rationale given behind them. Our article talks a little bit about some of the why that might be helpful and how that might look like in practice. I'm not sure what Sandi's original...I don't know if it was one of her books or maybe on a...it might have been on a podcast appearance she talked about them, so she might go more in-depth there. But yeah, they are a little bit declarative. It's just like, hey, here's...it's almost basically the kind of thing that can be enforced by a linter, which is perhaps the point. +STEPHANIE: Ooh, that's really interesting. It's like, on one hand, I like how simple they are, right? It's like, they're very obvious. If you're not following them, you can tell. But on the other hand, they seem to be more of a supplement to the gained knowledge and experience that you kind of get from knowing how to implement those rules. I think you and I will both agree that we don't want to stuff everything [laughs] into a single line with semicolons. But if someone who maybe is newer to development and is coming to these rules, I think they might be wondering, like, how do I do this? +JOËL: Do you follow these rules in your own code? +STEPHANIE: I think the ones that are easier to follow, for me, and that I think I've come to do more instinctually, are the rules about class line length and method line length just because I'm kind of looking out for opportunities to pull out a method or, you know, make sure that this class is just doing one thing. And if it's starting to seem to cover a couple of different responsibilities, I'm a little bit more on the lookout. But I do like these rules as like, you know, like, hey, once you hit, you know, 100 lines in a class, like, maybe that's your cue to start thinking about opportunities for extraction. +JOËL: Do you sort of consciously follow these rules or have them maybe even encoded in a linter? Or is it more you're following other things, and somehow, it just lines up with these principles? +STEPHANIE: I would say that, like, I'm not thinking about them very actively. But that could be a very interesting exercise, and I think, you know, that's what folks did in the blog post. They were like, hey, we took these rules, and we really kept them in mind as we were developing. But I think kind of what we were talking about earlier about, like, what we've learned or the strategies we've learned to implement kind of converge on these rules. And the rules actually are more of the result of other ideas or heuristics that we follow. +JOËL: I mean, you dropped the keyword heuristics there. And I think that brings me back to an earlier episode we did where we talked about heuristics. And one of the things that came up on that episode was the idea that, oftentimes, we use heuristics as a way to sort of flatten a lot of experience and knowledge into sort of one, like, short rule, or short phrase, or something, one guideline, even though it's sort of trying to just summarize a mountain of wisdom. +And so, oftentimes, you can look at something like these rules and be like, okay, well, what's the point? Or maybe you even just follow it to the letter without really thinking about the why behind it, and that can sometimes be problematic. And on the other hand, you might know all of the ideas that go behind them. And without necessarily knowing the rule itself, you just kind of happen to follow it because you're intimately familiar with all of these other software principles that converge on those same ideas. +STEPHANIE: Yeah, agreed. I think that the more interesting ones to me are the no more than four method arguments and only one instance variable per controller. +JOËL: Interesting. +STEPHANIE: I'm curious if those are sparking anything for you [laughs]. +JOËL: I think the no more than four method arguments, to me, is probably the least controversial. It's generally accepted that having many arguments to a method is a code smell. And there's a few different code smells that are related to that. There's forms of coupling incandescence; there are data clumps, things like that. +I've often heard a sort of rule of three. And so, if you're going more than three, then you might want to revisit the structure of what you're building. Four is a bit of an arbitrary cut-off, I'll agree. Most of these are arbitrary cut-offs. But I think the idea to maybe keep your method to fewer arguments is generally a good thing to do. +STEPHANIE: I liked that the rule points out that hash options account because I think that's maybe where people get a little more hand-wavy, or you have your ops hash [laughs] that can be just a catch-all for anything. You know, it's like, once you start putting stuff in there, I don't know, I feel like it's a like a law of the universe. It's like, oh, people will just stuff more things in there [laughs]. And it takes obviously more effort or, like, specific energy to, like, think through what those things might represent, or some alternative ways of handling those arguments. +We definitely do have, I think, a couple of episodes on value objects. But that's something that we have talked a lot about before in terms of, you know, how can we take some kind of primitive data, hashes included, and turn them into a richer object that can then be passed on its own? +JOËL: Right. And an options hash is generally...it's too much of a catch-all to really have an identity as its own sort of value object. It doesn't really represent any single thing. It's just everything else bag of data. One thing that's interesting that the article notes is that a lot of the helpers in Rails take a lot of arguments and that it is absolutely not worth trying to fight the framework to try to follow these rules. So, the article does take a very pragmatic approach, I think, to the idea of these rules. +STEPHANIE: Yeah. And I think there is even a caveat to the rules where it's like, you can break them if you have a good reason, or if you're working with someone else and they give you the thumbs up [laughs], which I really like a lot because it almost kind of compels you to stop and be like, do I have a good reason of doing this? Just making sure, or I'll run it by a friend. And shifting that, I guess, that focus from kind of just coding from, like, your default mode of thinking to a more active one. +JOËL: Right. There is a rule zero, which says you can break any of the other rules as long as you convince either your pair or your reviewer to give you a thumbs up on breaking the rule. +So, you'd mentioned the fourth rule about a single instance variable in a controller kind of was one of the ones that stood out to you. What is particularly striking about that rule? +STEPHANIE: I think this one is hard to follow, and I think the blog post mentions that as well. Because at least I've seen our web applications grow more and more complex. And it can be really challenging to just be like, what is this page doing? Like, what, you know, data does it need to know? And have that be the single thing. Because really, a lot of our web apps have a lot of things [laughs] that they're doing, and sometimes it feels like you have to capture more than one object or at least, like, a responsibility in this way. +I think that's the one that I, you know, in my ideal world, I'm like, yeah, like, we have all these, like, perfectly RESTful routes. And, you know, we're only dealing with, you know, a single resource. But once you start to have some more complexity, I think that can be a little more challenging. +JOËL: I think it's interesting that you mentioned RESTful routing because I think that is maybe one of the bigger things that does trigger having more instance variables in your controller actions. If you're following sort of the traditional Rails RESTful routes, every page is generally focused on a singular resource. Now, that may not necessarily line up with a table in your database, and that's fine. But you're dealing with a singular thing or perhaps, you know, in the case of an index page, a singular collection of things, which can be represented with a single instance variable. +Once you start adding custom routes that may not be necessarily tied to a particular resource, now you can very easily kind of have a proliferation of all sorts of different things that interact with each other because you're no longer centered on a single thing. +STEPHANIE: Yeah, that's true, which actually reminds me of something we've talked about before, too, when we were both reading Sustainable Rails. The author talks about custom routes and actually advocates for making all routes RESTful. And if you need a vanity URL or something like that, you can always alias it. That I liked, right? It's like, okay, even if, you know, your resource is not something that's like, ActiveRecord-backed, is there some abstraction or concept of a resource in there? +And I actually did really like in the blog post in the example; that is one that I've used before, too. They were dealing with this idea of a dashboard, which I would, you know, say is pretty common in a lot of web applications these days. And it's funny because a dashboard can hold so much data, right? It's really, like, a composite of a lot of different things, you know, what is most, like, useful for the user to see in one place. But they were in the blog post. And this, again, this is kind of something that I've done before. They were able to capture that with the idea of, like, a dashboard as an object and that being codified using a presenter or a facade. +JOËL: Right. So, instead of having a group, and a status, and a user, and all these, like, separate things that your page that you're showing is a sort of collection of all these different types of objects, you wrap them together in a dashboard object that's kind of a facade. And I guess that really does line up with the idea of RESTful routing because you're likely going to have a dashboard's controller show action that's showing the user's dashboard. So, it makes sense, you know, that show page is rendering a dashboard object. +STEPHANIE: Can we talk a little bit about things not to do, or maybe things that might be a little more questionable [laughs], and if you've seen them and how you felt about them? +JOËL: I think it is sometimes tricky to define your boundaries right in that sometimes you create a facade object that really is just...it doesn't really represent anything. It's just there to wrap around some other things. And sometimes that can be awkward. I think the dashboard works partly because it lines up so neatly with the sort of RESTful routing and thinking in terms of resources that you want to do at the controller layer. +But drawing boundaries incorrectly or just trying to throw everything in some kind of grab bag object can...it's not a magic bullet, right? You've got to put some thought into the data modeling, even when you are pulling the facade pattern. +STEPHANIE: Yeah, I think other things that I've seen before that could theoretically follow this rule maybe [laughs], you know, I'd love to hear your thoughts about it. When you start, you're like, oh, like, my controller action method does just, you know, set one instance variable. But it turns out that there's all these other instance variables that either through a hook or, like, in the parent controller or even in the view I've seen before, too [laughs]. And I'm just kind of curious if that kind of raises your eyebrow at all or if you've seen any good reasons for doing so. +JOËL: I think setting instance variables in a view would absolutely cause me to raise an eyebrow. +STEPHANIE: [laughs] Agreed. +JOËL: Generally, don't put logic in the view. I think that we definitely have in parent controllers; we'll set other instance variables for things like maybe a current user, right? That's how we store that state. And I think that is totally fine to have around. Typically, we don't access that instance variable directly. We're referencing some kind of helper method. But yeah, I would not consider that a violation of the rule. +I think another common one that might come up is when you have some kind of nested resource. And so, in your URL, you might have a nested resource where you're saying, "Oh, I'm looking at specifically this comment under this article or something like that." And then, you want to have access to both objects in the controller. So, I think that's a pretty common scenario where you might want to have both instance variables. +Something that I'm thinking about...this is not a fully formed thought, so I'm curious about your opinions here. Is there an interesting distinction between variables in code that you want to use within a controller versus variables that you want to be accessible from a view? Because instance variables in a controller are kind of overloaded. They're a way of having state in a controller, but they're also a way of passing data into a view. And so, that sort of dual purpose there maybe causes them to be a little bit trickier to reason about than instance variables in a random Ruby object. What do you think? +STEPHANIE: Yeah, I was actually having the same thought as you were going there, which is that it is kind of interesting that the view, you know, is that level of what you want to display to your user. But it can have access to, like, whatever you put in the controller [laughs], and that is...and, you know, in some ways, it's like, that connection needs to happen somewhere, right? And it's here. But I think that can definitely be abused sometimes, too. +So, this, you know, fourth rule that we're talking about really has to do with a more traditional Rails app. But, again, with the complexity of web apps in 2023 [chuckles], you know, we also see Rails used just as an API a lot with a separate front-end framework. And your controller is rendering some JSON, which I think has that harder boundary between what is the data that the server is involved with and what we want to send to our client. And I'm curious if you have any thoughts about how this rule applies in that situation. +JOËL: I think I tend to see not really any difference there. If I'm building an API, typically, I'm trying to do so in a pretty RESTful manner. Maybe I'm doing a GraphQL API, and things might be different for that. But for a traditional REST API, yeah, typically, you're fetching one resource or some sort of compound resource, in which case, you're representing that with a facade object. +And yep, you can generally get away, I think, with a single instance variable with, you know, a few exceptions around maybe some extra context about maybe something like the current user, or a parent object, or something like that. I guess the view is really you're using a different mechanism for rendering JSON, and there are a bunch out there that the community uses. I think I don't really see a difference between rendering to HTML versus rendering to JSON, or XML, or whatever. How about you? +STEPHANIE: That's a good point. I think I'm with you where the rule still applies. But I have also seen things get really loosey-goosey [laughs] when we decide we're rendering JSON, and now we're suddenly putting the instance variables into a hash along with other stuff. +But what you said was interesting about, like, sometimes you do need that extra context, right? And, like, figuring out what the best way to package that requires a bit of, like, sustained thought, I think, because it can, you know, be really easy to be like, oh well, this is the one interface that I have to get data from the server. So, if I just sneak this in here [laughs], what's the matter? But yeah, I think, you know, that's probably why rules like this exist [laughs] to help provide some guardrails and make us think a little deeper about it. +JOËL: I think sometimes, as a community, we maybe exaggerate the differences between, like, RESTful HTML view and a RESTful JSON API. I tend to think of them as more or less the same. We just have, you know, a different representation the V layer of our MVC framework. Everything else still kind of lines up. +STEPHANIE: Yeah, that's a really good point. I actually hadn't thought about it that way. Because I think maybe I have been influenced by the world of GraphQL [laughs] a little bit, or it's kind of hard to have a foot in both worlds, where you maybe have to context switch a little bit about, like, the paradigms, and then you find them influencing you in different ways. Because I have seen sometimes, like, what maybe initially were meant to be traditional more, like, RESTful JSON APIs kind of start to turn into that, like, how do we get what we need from this endpoint? +JOËL: I'm curious how you feel in general about the facade pattern. Is that something that you've used, something that you like? +STEPHANIE: I think I would say that I don't actually reach for it, like, upfront, right? Usually, I'm still trying to maybe put some things in my models [laughs]. But I have used it before once; it kind of became clear that, like, a lot of the methods on the model had to do with more really server-side concerns. And I was, like, wanting to just pull out some presentational pieces. I think the hardest part with the facade pattern is naming. I have really struggled sometimes to think of, like, it's not quite the component that makes it up. So, what is it instead? +JOËL: Right. Right. I think, for me, sometimes the naming goes the other way around in that I'll start more to kind of, like, routing our resource level and try to think about, okay, this particular view of the data that I want to have, or this particular operation that I want to do, what am I actually dealing with? What is the resource here? So, maybe I'm viewing a dashboard. Or maybe what I'm doing is creating or destroying a subscription, even though those are not necessarily tables in the database. And once I have that underlying concept, then I can start creating an object that represents that, which might be a combination of multiple ActiveRecord models that represent tables. +STEPHANIE: Yeah. You're actually pointing out, like, a really great use case that we see a lot, I think, is when you start to have to reach for resources, you know, that are different ActiveRecord classes. And how do you combine them together to represent the idea that you want, you know, for your feature? +JOËL: I think it's more of, like, an outside-facing perspective rather than an inside-facing perspective. So, instead of looking at, hey, these are the set of ActiveRecord classes I have because these are my database tables, how can I, like, tack on to them to make this operation work? I'll sort of start almost from, like, a zoomed-out perspective, blank slate to say, "Hey, this is the kind of operation that I'm trying to do. What sort of resource am I dealing with ideally?" +And, you know, maybe the idea is, okay, I'm dealing with a dashboard. I'm trying to subscribe to something...a newsletter, so the idea is I'm creating a subscription. Then, from there, I can start looking at, okay, do I have the concept of a subscription in this application? Oh, I don't. There is no subscriptions table because that's not a thing that we track in our data mode. That's fine. But I probably need at least some kind of in-memory object to track the idea of a subscription, and then maybe from there, that grows. So, I'm kind of working from the problem towards the database rather than from the database out. +STEPHANIE: Yeah, I like that a lot. The outside-in phrase that you used really triggered something for me, which is being product engineers, right? Like, having a seat at the table when the feature is in that, like, ideation phase, I think is also really important because that's where you really learn what that like, abstraction is at the user level. And also, it could be a really good place to give your input if the feature is being designed in a way that doesn't really support the, you know, kind of quality of code and, like, separation that you would like. That's the part that I'm still working on and still learning how to do. +But sometimes, you know, it's, like, really critical to the job to, like, be in that room and be like, these designs; what are some places that we could extract it at that level even? And kind of, like, separate things out from there rather than having to deal with it [laughs] deep in your codebase. +JOËL: I think what I'm really kind of hearing and emphasizing in what you just said is the importance of not just writing code but being involved in the product and how that really enriches you because you know the problem domain. And that allows you to then write the code that you need at the different levels of the app to best model the situation you're working with. +So, we've kind of gone through all the rules and talked about them. I'm curious, though, for you, are these rules that you follow in your code? How closely do you adhere to this set of rules? Is this still something that's relevant to you in 2023 as much as it was to the authors of that blog post in 2013? +STEPHANIE: I have to say they're not ones that I have thought about on a daily basis, but after this conversation, maybe they will be. And I am kind of excited to maybe, like, bring this up to other people on my team and be like, "What do you think about these rules?" Just, like, revisiting them as a group or just, like, having that conversation. Because I think that's, you know, where I am most interested in is, like, is wondering how other people incorporate them into their work and hearing different opinions from the team. And I think there's a lot of, like, generative discussion that ultimately leads to better code as a result. +JOËL: I think for myself, I'm not following the rules directly. But a lot of my code ends up approximating those rules anyway because of other principles that I follow. So, in practice, while my code doesn't strictly follow those rules, it does look pretty close to that anyway. +STEPHANIE: I almost think this could be a great, you know, discussion for your team, too, like, if any listeners want to...not quite a book club but kind of an article club, if you will [laughs], and see how other people on your team feel about it. Because I think that's kind of where there is, like, a really sweet spot in terms of learning and development. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Stephanie discovered a new book: The Staff Engineer's Path! Joël's got some D&D goodness.

+ +

Together, they revisit a decade-old blog post initially published in 2013, which discussed the application of Sandi Metz's coding guidelines and whether these rules remain relevant and practiced among developers today.

+ +
+ +

The Manager’s Path
+The Staff Engineer’s Path
+Not Another D&D Podcast
+Sandi Metz rules for developers
+Bike Shed episode on heuristics
+In Relentless Pursuit of REST

+ +
+ +

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, I picked up a new book from the library [laughs], which that in itself is not very new. That is [laughs] a common occurrence in my world. But it was kind of a fun coincidence that I was just walking around the aisles of what's new in nonfiction, and staring me right in the face was an O'Reilly book, The Staff Engineer's Path. And I think in the past, I've plugged The Manager's Path by Camille Fournier on the show.

+ +

And in recent years, this one was published, and it's by Tanya Reilly. And it is kind of, like, the other half of a career path for software engineers moving up in seniority at those higher levels. And it has been a really interesting companion to The Manager's Path, which I had read even though I wasn't really sure I wanted to be manager [laughs].

+ +

And now I think I get that, like, accompaniment of like, okay, like, instead of walking that path, like, what does a staff plus engineer look like? And kind of learning a little bit more about that because I know it can be really vague or ambiguous or look very different at a lot of different companies. And that has been really helpful for me, kind of looking ahead a bit. I'm not too far into it yet. But I'm looking forward to reading more and bringing back some of those learnings to the show.

+ +

JOËL: I feel like at the end of the year, Stephanie, you and I are probably going to have to sit down and talk through maybe your reading list for the year and, you know, maybe shout out some favorites. I think your reading list is probably significantly longer than mine. But you're constantly referencing cool books. I think that would probably be a fun, either end-of-year episode or a beginning-of-year episode for 2024.

+ +

One thing that's really interesting, though, about the contrast of these two particular books you're talking about is how it really lines up with this, like, fork in the road that a lot of us have in our careers as we get more senior. You either move into more of a management role, which can be a pretty significant departure from what you have to do as a developer, or you kind of go into this, like, ultra-senior individual contributor path. But how that looks day to day can be very different from your sort of just traditional sitting down and banging out tickets. So, it's really cool there's two books looking at both of those paths.

+ +

STEPHANIE: Yeah, absolutely. And I think the mission that they were going for with these books was to kind of illuminate a little bit more about that fork and that decision because, you know, it can be easy for people to maybe just default into one or the other based on what their organization wants for them without, like, fully knowing what that means. And the more senior you get, the more vague and, like, figure it out yourself [laughs] the work becomes.

+ +

And it can be very daunting to kind of just be thrown into that and be like, well, I'm in this leadership position now. People are looking to me, and I have all this responsibility, but, like, what do I do? Yeah, so I'm kind of enjoying this book, that is...it's not a technical book, which is actually kind of what I like about it. It's actually more of a leadership book, which is really important for that kind of role. Even though, you know, they are still in that IC track, but it does come with a lot of leadership responsibility.

+ +

JOËL: Yes, leadership in a very different way than management. But—and this may be counterintuitive for some people, especially earlier on in their careers—going further up that individual contributor track doesn't just mean getting more intense technically. It often means you've got to focus on things more like leadership, like being a bit more strategic, aligning technical initiatives with strategic goals.

+ +

STEPHANIE: Yeah, and having a bigger impact and being a force multiplier, even in both the manager and, like, the staff plus role, like, that, you know, is the thing that ties the rising level.

+ +

JOËL: Yeah, in many ways, maybe the individual contributor track is slightly misnamed because while, yes, you're not managing a sort of sub-organization within the company, it's still about being a force multiplier.

+ +

STEPHANIE: Yeah, that's a really great point [laughs]. Maybe we'll be able to come up with a better [laughs] name for that.

+ +

JOËL: I've mentioned several times on this podcast that I've been enjoying playing Dungeons & Dragons, D&D, with some friends and some colleagues. And something that was particularly fun that some friends and I did this summer is we hired a professional DM to run one shot for us. And that was just an absolutely lovely experience. Well, as a result of that, I am now subscribed to this guy's newsletter. And he'll do, like, various D&D events at different times.

+ +

One thing that was really cool that I found out recently...as we're recording this, it's the week before election day in the U.S. And because a lot of voting happens in schools, typically, schools have the day off. And so, this guy sent out an email saying he was offering to run a, like, all day...effectively, a little mini-D&D camp for school-age kids on election day so that you can do your work. You can go vote, and you don't have to...basically, he'll watch your kids for you and, like, get them introduced to playing D&D, which I think is just a really cool thing to do.

+ +

STEPHANIE: I love that. It's so heartwarming [laughs]. And it's such a great idea because, oftentimes, people are still working, and so they need childcare, like, on those kinds of days. And yeah, I think D&D is such a fun thing for kids to get into, too. You know, it requires so much, like, imagination, and I can imagine it's such a blast.

+ +

JOËL: I got that email, and I was like, that is such a perfect idea. I love it so much.

+ +

STEPHANIE: I wanted to plug my D&D recommendation. I'm pretty sure I have mentioned it on the show before. But there is a podcast that I listen to called Not Another D&D Podcast, which is, you know, a live play Dungeons & Dragons podcast campaign that's hosted by these comedians, formerly of CollegeHumor, and it's very fun. I always laugh.

+ +

They have this, like, a kind of offshoot of the main show that they do called D&D Court, which is very fun. Because, as you were saying, like, you know, you hired a DM to run your game. And I know that...I'm sure lots of people have fun stories about their home games and, like, the drama that happens [laughs] with their friends.

+ +

JOËL: Absolutely. Absolutely.

+ +

STEPHANIE: And so, with D&D Court, listeners can write in with their drama or their conflicts and get an official ruling from the hosts about who was right [laughs] in the situation that they write in about.

+ +

JOËL: So, you get to bring your best rules lawyering to the D&D Court.

+ +

STEPHANIE: Yeah, exactly [laughs].

+ +

JOËL: That sounds kind of amazing.

+ +

Recently, I had someone reach out to me asking about an older blog post that we'd written about the Sandi Metz Rules. This blog post was initially published in 2013, so ten years ago, and was talking about some guidelines that Sandi Metz at the time was talking about that she was using in some of her code. And we talked about how our experience was applying those to some of our work as well. And so, the question was, you know, ten years later, is that still something that thoughtbot developers like to follow in their code?

+ +

We'll link to the article in the show notes. But I'll just read out the rules here real quick. So, there's four of them. The first one is a class can be no longer than 100 lines of code. The second is a method can be no longer than five lines of code. The third is pass no more than four parameters into a method, and hash options count, so no getting clever with those. And then, finally, controllers can only instantiate one object. You only get one instance variable. And views can only talk to that one instance variable.

+ +

Had you or are you familiar with these rules? Is that something that you think about or use in your daily writing of code?

+ +

STEPHANIE: Yeah. So, when you proposed this topic, I had to revisit these rules. And I can't recall if I had seen them before. They seemed familiar. And I've read, you know, a couple of Sandi Metz's books, so maybe those were places where she had mentioned them.

+ +

But the one thing that really struck me when I was first reading the rules was how declarative they were in terms of, like, kind of just telling you what the results should be without really saying how. So, for example, the one where you said, you know, a method should not be more than five lines [laughs], I had the silly thought of, like, well, you could just, you know, stuff everything into a single line [laughs] and just completely disregard line limit if you wanted, and it would technically still follow the rule.

+ +

JOËL: If they didn't want us to do that, they wouldn't give us semicolons in Ruby.

+ +

STEPHANIE: Exactly [laughs]. So, that is kind of what struck me at first. Is that something you noticed?

+ +

JOËL: I think what is interesting with them is that there's not always a ton of rationale given behind them. Our article talks a little bit about some of the why that might be helpful and how that might look like in practice. I'm not sure what Sandi's original...I don't know if it was one of her books or maybe on a...it might have been on a podcast appearance she talked about them, so she might go more in-depth there. But yeah, they are a little bit declarative. It's just like, hey, here's...it's almost basically the kind of thing that can be enforced by a linter, which is perhaps the point.

+ +

STEPHANIE: Ooh, that's really interesting. It's like, on one hand, I like how simple they are, right? It's like, they're very obvious. If you're not following them, you can tell. But on the other hand, they seem to be more of a supplement to the gained knowledge and experience that you kind of get from knowing how to implement those rules. I think you and I will both agree that we don't want to stuff everything [laughs] into a single line with semicolons. But if someone who maybe is newer to development and is coming to these rules, I think they might be wondering, like, how do I do this?

+ +

JOËL: Do you follow these rules in your own code?

+ +

STEPHANIE: I think the ones that are easier to follow, for me, and that I think I've come to do more instinctually, are the rules about class line length and method line length just because I'm kind of looking out for opportunities to pull out a method or, you know, make sure that this class is just doing one thing. And if it's starting to seem to cover a couple of different responsibilities, I'm a little bit more on the lookout. But I do like these rules as like, you know, like, hey, once you hit, you know, 100 lines in a class, like, maybe that's your cue to start thinking about opportunities for extraction.

+ +

JOËL: Do you sort of consciously follow these rules or have them maybe even encoded in a linter? Or is it more you're following other things, and somehow, it just lines up with these principles?

+ +

STEPHANIE: I would say that, like, I'm not thinking about them very actively. But that could be a very interesting exercise, and I think, you know, that's what folks did in the blog post. They were like, hey, we took these rules, and we really kept them in mind as we were developing. But I think kind of what we were talking about earlier about, like, what we've learned or the strategies we've learned to implement kind of converge on these rules. And the rules actually are more of the result of other ideas or heuristics that we follow.

+ +

JOËL: I mean, you dropped the keyword heuristics there. And I think that brings me back to an earlier episode we did where we talked about heuristics. And one of the things that came up on that episode was the idea that, oftentimes, we use heuristics as a way to sort of flatten a lot of experience and knowledge into sort of one, like, short rule, or short phrase, or something, one guideline, even though it's sort of trying to just summarize a mountain of wisdom.

+ +

And so, oftentimes, you can look at something like these rules and be like, okay, well, what's the point? Or maybe you even just follow it to the letter without really thinking about the why behind it, and that can sometimes be problematic. And on the other hand, you might know all of the ideas that go behind them. And without necessarily knowing the rule itself, you just kind of happen to follow it because you're intimately familiar with all of these other software principles that converge on those same ideas.

+ +

STEPHANIE: Yeah, agreed. I think that the more interesting ones to me are the no more than four method arguments and only one instance variable per controller.

+ +

JOËL: Interesting.

+ +

STEPHANIE: I'm curious if those are sparking anything for you [laughs].

+ +

JOËL: I think the no more than four method arguments, to me, is probably the least controversial. It's generally accepted that having many arguments to a method is a code smell. And there's a few different code smells that are related to that. There's forms of coupling incandescence; there are data clumps, things like that.

+ +

I've often heard a sort of rule of three. And so, if you're going more than three, then you might want to revisit the structure of what you're building. Four is a bit of an arbitrary cut-off, I'll agree. Most of these are arbitrary cut-offs. But I think the idea to maybe keep your method to fewer arguments is generally a good thing to do.

+ +

STEPHANIE: I liked that the rule points out that hash options account because I think that's maybe where people get a little more hand-wavy, or you have your ops hash [laughs] that can be just a catch-all for anything. You know, it's like, once you start putting stuff in there, I don't know, I feel like it's a like a law of the universe. It's like, oh, people will just stuff more things in there [laughs]. And it takes obviously more effort or, like, specific energy to, like, think through what those things might represent, or some alternative ways of handling those arguments.

+ +

We definitely do have, I think, a couple of episodes on value objects. But that's something that we have talked a lot about before in terms of, you know, how can we take some kind of primitive data, hashes included, and turn them into a richer object that can then be passed on its own?

+ +

JOËL: Right. And an options hash is generally...it's too much of a catch-all to really have an identity as its own sort of value object. It doesn't really represent any single thing. It's just everything else bag of data. One thing that's interesting that the article notes is that a lot of the helpers in Rails take a lot of arguments and that it is absolutely not worth trying to fight the framework to try to follow these rules. So, the article does take a very pragmatic approach, I think, to the idea of these rules.

+ +

STEPHANIE: Yeah. And I think there is even a caveat to the rules where it's like, you can break them if you have a good reason, or if you're working with someone else and they give you the thumbs up [laughs], which I really like a lot because it almost kind of compels you to stop and be like, do I have a good reason of doing this? Just making sure, or I'll run it by a friend. And shifting that, I guess, that focus from kind of just coding from, like, your default mode of thinking to a more active one.

+ +

JOËL: Right. There is a rule zero, which says you can break any of the other rules as long as you convince either your pair or your reviewer to give you a thumbs up on breaking the rule.

+ +

So, you'd mentioned the fourth rule about a single instance variable in a controller kind of was one of the ones that stood out to you. What is particularly striking about that rule?

+ +

STEPHANIE: I think this one is hard to follow, and I think the blog post mentions that as well. Because at least I've seen our web applications grow more and more complex. And it can be really challenging to just be like, what is this page doing? Like, what, you know, data does it need to know? And have that be the single thing. Because really, a lot of our web apps have a lot of things [laughs] that they're doing, and sometimes it feels like you have to capture more than one object or at least, like, a responsibility in this way.

+ +

I think that's the one that I, you know, in my ideal world, I'm like, yeah, like, we have all these, like, perfectly RESTful routes. And, you know, we're only dealing with, you know, a single resource. But once you start to have some more complexity, I think that can be a little more challenging.

+ +

JOËL: I think it's interesting that you mentioned RESTful routing because I think that is maybe one of the bigger things that does trigger having more instance variables in your controller actions. If you're following sort of the traditional Rails RESTful routes, every page is generally focused on a singular resource. Now, that may not necessarily line up with a table in your database, and that's fine. But you're dealing with a singular thing or perhaps, you know, in the case of an index page, a singular collection of things, which can be represented with a single instance variable.

+ +

Once you start adding custom routes that may not be necessarily tied to a particular resource, now you can very easily kind of have a proliferation of all sorts of different things that interact with each other because you're no longer centered on a single thing.

+ +

STEPHANIE: Yeah, that's true, which actually reminds me of something we've talked about before, too, when we were both reading Sustainable Rails. The author talks about custom routes and actually advocates for making all routes RESTful. And if you need a vanity URL or something like that, you can always alias it. That I liked, right? It's like, okay, even if, you know, your resource is not something that's like, ActiveRecord-backed, is there some abstraction or concept of a resource in there?

+ +

And I actually did really like in the blog post in the example; that is one that I've used before, too. They were dealing with this idea of a dashboard, which I would, you know, say is pretty common in a lot of web applications these days. And it's funny because a dashboard can hold so much data, right? It's really, like, a composite of a lot of different things, you know, what is most, like, useful for the user to see in one place. But they were in the blog post. And this, again, this is kind of something that I've done before. They were able to capture that with the idea of, like, a dashboard as an object and that being codified using a presenter or a facade.

+ +

JOËL: Right. So, instead of having a group, and a status, and a user, and all these, like, separate things that your page that you're showing is a sort of collection of all these different types of objects, you wrap them together in a dashboard object that's kind of a facade. And I guess that really does line up with the idea of RESTful routing because you're likely going to have a dashboard's controller show action that's showing the user's dashboard. So, it makes sense, you know, that show page is rendering a dashboard object.

+ +

STEPHANIE: Can we talk a little bit about things not to do, or maybe things that might be a little more questionable [laughs], and if you've seen them and how you felt about them?

+ +

JOËL: I think it is sometimes tricky to define your boundaries right in that sometimes you create a facade object that really is just...it doesn't really represent anything. It's just there to wrap around some other things. And sometimes that can be awkward. I think the dashboard works partly because it lines up so neatly with the sort of RESTful routing and thinking in terms of resources that you want to do at the controller layer.

+ +

But drawing boundaries incorrectly or just trying to throw everything in some kind of grab bag object can...it's not a magic bullet, right? You've got to put some thought into the data modeling, even when you are pulling the facade pattern.

+ +

STEPHANIE: Yeah, I think other things that I've seen before that could theoretically follow this rule maybe [laughs], you know, I'd love to hear your thoughts about it. When you start, you're like, oh, like, my controller action method does just, you know, set one instance variable. But it turns out that there's all these other instance variables that either through a hook or, like, in the parent controller or even in the view I've seen before, too [laughs]. And I'm just kind of curious if that kind of raises your eyebrow at all or if you've seen any good reasons for doing so.

+ +

JOËL: I think setting instance variables in a view would absolutely cause me to raise an eyebrow.

+ +

STEPHANIE: [laughs] Agreed.

+ +

JOËL: Generally, don't put logic in the view. I think that we definitely have in parent controllers; we'll set other instance variables for things like maybe a current user, right? That's how we store that state. And I think that is totally fine to have around. Typically, we don't access that instance variable directly. We're referencing some kind of helper method. But yeah, I would not consider that a violation of the rule.

+ +

I think another common one that might come up is when you have some kind of nested resource. And so, in your URL, you might have a nested resource where you're saying, "Oh, I'm looking at specifically this comment under this article or something like that." And then, you want to have access to both objects in the controller. So, I think that's a pretty common scenario where you might want to have both instance variables.

+ +

Something that I'm thinking about...this is not a fully formed thought, so I'm curious about your opinions here. Is there an interesting distinction between variables in code that you want to use within a controller versus variables that you want to be accessible from a view? Because instance variables in a controller are kind of overloaded. They're a way of having state in a controller, but they're also a way of passing data into a view. And so, that sort of dual purpose there maybe causes them to be a little bit trickier to reason about than instance variables in a random Ruby object. What do you think?

+ +

STEPHANIE: Yeah, I was actually having the same thought as you were going there, which is that it is kind of interesting that the view, you know, is that level of what you want to display to your user. But it can have access to, like, whatever you put in the controller [laughs], and that is...and, you know, in some ways, it's like, that connection needs to happen somewhere, right? And it's here. But I think that can definitely be abused sometimes, too.

+ +

So, this, you know, fourth rule that we're talking about really has to do with a more traditional Rails app. But, again, with the complexity of web apps in 2023 [chuckles], you know, we also see Rails used just as an API a lot with a separate front-end framework. And your controller is rendering some JSON, which I think has that harder boundary between what is the data that the server is involved with and what we want to send to our client. And I'm curious if you have any thoughts about how this rule applies in that situation.

+ +

JOËL: I think I tend to see not really any difference there. If I'm building an API, typically, I'm trying to do so in a pretty RESTful manner. Maybe I'm doing a GraphQL API, and things might be different for that. But for a traditional REST API, yeah, typically, you're fetching one resource or some sort of compound resource, in which case, you're representing that with a facade object.

+ +

And yep, you can generally get away, I think, with a single instance variable with, you know, a few exceptions around maybe some extra context about maybe something like the current user, or a parent object, or something like that. I guess the view is really you're using a different mechanism for rendering JSON, and there are a bunch out there that the community uses. I think I don't really see a difference between rendering to HTML versus rendering to JSON, or XML, or whatever. How about you?

+ +

STEPHANIE: That's a good point. I think I'm with you where the rule still applies. But I have also seen things get really loosey-goosey [laughs] when we decide we're rendering JSON, and now we're suddenly putting the instance variables into a hash along with other stuff.

+ +

But what you said was interesting about, like, sometimes you do need that extra context, right? And, like, figuring out what the best way to package that requires a bit of, like, sustained thought, I think, because it can, you know, be really easy to be like, oh well, this is the one interface that I have to get data from the server. So, if I just sneak this in here [laughs], what's the matter? But yeah, I think, you know, that's probably why rules like this exist [laughs] to help provide some guardrails and make us think a little deeper about it.

+ +

JOËL: I think sometimes, as a community, we maybe exaggerate the differences between, like, RESTful HTML view and a RESTful JSON API. I tend to think of them as more or less the same. We just have, you know, a different representation the V layer of our MVC framework. Everything else still kind of lines up.

+ +

STEPHANIE: Yeah, that's a really good point. I actually hadn't thought about it that way. Because I think maybe I have been influenced by the world of GraphQL [laughs] a little bit, or it's kind of hard to have a foot in both worlds, where you maybe have to context switch a little bit about, like, the paradigms, and then you find them influencing you in different ways. Because I have seen sometimes, like, what maybe initially were meant to be traditional more, like, RESTful JSON APIs kind of start to turn into that, like, how do we get what we need from this endpoint?

+ +

JOËL: I'm curious how you feel in general about the facade pattern. Is that something that you've used, something that you like?

+ +

STEPHANIE: I think I would say that I don't actually reach for it, like, upfront, right? Usually, I'm still trying to maybe put some things in my models [laughs]. But I have used it before once; it kind of became clear that, like, a lot of the methods on the model had to do with more really server-side concerns. And I was, like, wanting to just pull out some presentational pieces. I think the hardest part with the facade pattern is naming. I have really struggled sometimes to think of, like, it's not quite the component that makes it up. So, what is it instead?

+ +

JOËL: Right. Right. I think, for me, sometimes the naming goes the other way around in that I'll start more to kind of, like, routing our resource level and try to think about, okay, this particular view of the data that I want to have, or this particular operation that I want to do, what am I actually dealing with? What is the resource here? So, maybe I'm viewing a dashboard. Or maybe what I'm doing is creating or destroying a subscription, even though those are not necessarily tables in the database. And once I have that underlying concept, then I can start creating an object that represents that, which might be a combination of multiple ActiveRecord models that represent tables.

+ +

STEPHANIE: Yeah. You're actually pointing out, like, a really great use case that we see a lot, I think, is when you start to have to reach for resources, you know, that are different ActiveRecord classes. And how do you combine them together to represent the idea that you want, you know, for your feature?

+ +

JOËL: I think it's more of, like, an outside-facing perspective rather than an inside-facing perspective. So, instead of looking at, hey, these are the set of ActiveRecord classes I have because these are my database tables, how can I, like, tack on to them to make this operation work? I'll sort of start almost from, like, a zoomed-out perspective, blank slate to say, "Hey, this is the kind of operation that I'm trying to do. What sort of resource am I dealing with ideally?"

+ +

And, you know, maybe the idea is, okay, I'm dealing with a dashboard. I'm trying to subscribe to something...a newsletter, so the idea is I'm creating a subscription. Then, from there, I can start looking at, okay, do I have the concept of a subscription in this application? Oh, I don't. There is no subscriptions table because that's not a thing that we track in our data mode. That's fine. But I probably need at least some kind of in-memory object to track the idea of a subscription, and then maybe from there, that grows. So, I'm kind of working from the problem towards the database rather than from the database out.

+ +

STEPHANIE: Yeah, I like that a lot. The outside-in phrase that you used really triggered something for me, which is being product engineers, right? Like, having a seat at the table when the feature is in that, like, ideation phase, I think is also really important because that's where you really learn what that like, abstraction is at the user level. And also, it could be a really good place to give your input if the feature is being designed in a way that doesn't really support the, you know, kind of quality of code and, like, separation that you would like. That's the part that I'm still working on and still learning how to do.

+ +

But sometimes, you know, it's, like, really critical to the job to, like, be in that room and be like, these designs; what are some places that we could extract it at that level even? And kind of, like, separate things out from there rather than having to deal with it [laughs] deep in your codebase.

+ +

JOËL: I think what I'm really kind of hearing and emphasizing in what you just said is the importance of not just writing code but being involved in the product and how that really enriches you because you know the problem domain. And that allows you to then write the code that you need at the different levels of the app to best model the situation you're working with.

+ +

So, we've kind of gone through all the rules and talked about them. I'm curious, though, for you, are these rules that you follow in your code? How closely do you adhere to this set of rules? Is this still something that's relevant to you in 2023 as much as it was to the authors of that blog post in 2013?

+ +

STEPHANIE: I have to say they're not ones that I have thought about on a daily basis, but after this conversation, maybe they will be. And I am kind of excited to maybe, like, bring this up to other people on my team and be like, "What do you think about these rules?" Just, like, revisiting them as a group or just, like, having that conversation. Because I think that's, you know, where I am most interested in is, like, is wondering how other people incorporate them into their work and hearing different opinions from the team. And I think there's a lot of, like, generative discussion that ultimately leads to better code as a result.

+ +

JOËL: I think for myself, I'm not following the rules directly. But a lot of my code ends up approximating those rules anyway because of other principles that I follow. So, in practice, while my code doesn't strictly follow those rules, it does look pretty close to that anyway.

+ +

STEPHANIE: I almost think this could be a great, you know, discussion for your team, too, like, if any listeners want to...not quite a book club but kind of an article club, if you will [laughs], and see how other people on your team feel about it. Because I think that's kind of where there is, like, a really sweet spot in terms of learning and development.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Stephanie discovered a new book: The Staff Engineer's Path! Joël's got some D&D goodness.

+ +

Together, they revisit a decade-old blog post initially published in 2013, which discussed the application of Sandi Metz's coding guidelines and whether these rules remain relevant and practiced among developers today.

+ +
+ +

The Manager’s Path
+The Staff Engineer’s Path
+Not Another D&D Podcast
+Sandi Metz rules for developers
+Bike Shed episode on heuristics
+In Relentless Pursuit of REST

+ +
+ +

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, I picked up a new book from the library [laughs], which that in itself is not very new. That is [laughs] a common occurrence in my world. But it was kind of a fun coincidence that I was just walking around the aisles of what's new in nonfiction, and staring me right in the face was an O'Reilly book, The Staff Engineer's Path. And I think in the past, I've plugged The Manager's Path by Camille Fournier on the show.

+ +

And in recent years, this one was published, and it's by Tanya Reilly. And it is kind of, like, the other half of a career path for software engineers moving up in seniority at those higher levels. And it has been a really interesting companion to The Manager's Path, which I had read even though I wasn't really sure I wanted to be manager [laughs].

+ +

And now I think I get that, like, accompaniment of like, okay, like, instead of walking that path, like, what does a staff plus engineer look like? And kind of learning a little bit more about that because I know it can be really vague or ambiguous or look very different at a lot of different companies. And that has been really helpful for me, kind of looking ahead a bit. I'm not too far into it yet. But I'm looking forward to reading more and bringing back some of those learnings to the show.

+ +

JOËL: I feel like at the end of the year, Stephanie, you and I are probably going to have to sit down and talk through maybe your reading list for the year and, you know, maybe shout out some favorites. I think your reading list is probably significantly longer than mine. But you're constantly referencing cool books. I think that would probably be a fun, either end-of-year episode or a beginning-of-year episode for 2024.

+ +

One thing that's really interesting, though, about the contrast of these two particular books you're talking about is how it really lines up with this, like, fork in the road that a lot of us have in our careers as we get more senior. You either move into more of a management role, which can be a pretty significant departure from what you have to do as a developer, or you kind of go into this, like, ultra-senior individual contributor path. But how that looks day to day can be very different from your sort of just traditional sitting down and banging out tickets. So, it's really cool there's two books looking at both of those paths.

+ +

STEPHANIE: Yeah, absolutely. And I think the mission that they were going for with these books was to kind of illuminate a little bit more about that fork and that decision because, you know, it can be easy for people to maybe just default into one or the other based on what their organization wants for them without, like, fully knowing what that means. And the more senior you get, the more vague and, like, figure it out yourself [laughs] the work becomes.

+ +

And it can be very daunting to kind of just be thrown into that and be like, well, I'm in this leadership position now. People are looking to me, and I have all this responsibility, but, like, what do I do? Yeah, so I'm kind of enjoying this book, that is...it's not a technical book, which is actually kind of what I like about it. It's actually more of a leadership book, which is really important for that kind of role. Even though, you know, they are still in that IC track, but it does come with a lot of leadership responsibility.

+ +

JOËL: Yes, leadership in a very different way than management. But—and this may be counterintuitive for some people, especially earlier on in their careers—going further up that individual contributor track doesn't just mean getting more intense technically. It often means you've got to focus on things more like leadership, like being a bit more strategic, aligning technical initiatives with strategic goals.

+ +

STEPHANIE: Yeah, and having a bigger impact and being a force multiplier, even in both the manager and, like, the staff plus role, like, that, you know, is the thing that ties the rising level.

+ +

JOËL: Yeah, in many ways, maybe the individual contributor track is slightly misnamed because while, yes, you're not managing a sort of sub-organization within the company, it's still about being a force multiplier.

+ +

STEPHANIE: Yeah, that's a really great point [laughs]. Maybe we'll be able to come up with a better [laughs] name for that.

+ +

JOËL: I've mentioned several times on this podcast that I've been enjoying playing Dungeons & Dragons, D&D, with some friends and some colleagues. And something that was particularly fun that some friends and I did this summer is we hired a professional DM to run one shot for us. And that was just an absolutely lovely experience. Well, as a result of that, I am now subscribed to this guy's newsletter. And he'll do, like, various D&D events at different times.

+ +

One thing that was really cool that I found out recently...as we're recording this, it's the week before election day in the U.S. And because a lot of voting happens in schools, typically, schools have the day off. And so, this guy sent out an email saying he was offering to run a, like, all day...effectively, a little mini-D&D camp for school-age kids on election day so that you can do your work. You can go vote, and you don't have to...basically, he'll watch your kids for you and, like, get them introduced to playing D&D, which I think is just a really cool thing to do.

+ +

STEPHANIE: I love that. It's so heartwarming [laughs]. And it's such a great idea because, oftentimes, people are still working, and so they need childcare, like, on those kinds of days. And yeah, I think D&D is such a fun thing for kids to get into, too. You know, it requires so much, like, imagination, and I can imagine it's such a blast.

+ +

JOËL: I got that email, and I was like, that is such a perfect idea. I love it so much.

+ +

STEPHANIE: I wanted to plug my D&D recommendation. I'm pretty sure I have mentioned it on the show before. But there is a podcast that I listen to called Not Another D&D Podcast, which is, you know, a live play Dungeons & Dragons podcast campaign that's hosted by these comedians, formerly of CollegeHumor, and it's very fun. I always laugh.

+ +

They have this, like, a kind of offshoot of the main show that they do called D&D Court, which is very fun. Because, as you were saying, like, you know, you hired a DM to run your game. And I know that...I'm sure lots of people have fun stories about their home games and, like, the drama that happens [laughs] with their friends.

+ +

JOËL: Absolutely. Absolutely.

+ +

STEPHANIE: And so, with D&D Court, listeners can write in with their drama or their conflicts and get an official ruling from the hosts about who was right [laughs] in the situation that they write in about.

+ +

JOËL: So, you get to bring your best rules lawyering to the D&D Court.

+ +

STEPHANIE: Yeah, exactly [laughs].

+ +

JOËL: That sounds kind of amazing.

+ +

Recently, I had someone reach out to me asking about an older blog post that we'd written about the Sandi Metz Rules. This blog post was initially published in 2013, so ten years ago, and was talking about some guidelines that Sandi Metz at the time was talking about that she was using in some of her code. And we talked about how our experience was applying those to some of our work as well. And so, the question was, you know, ten years later, is that still something that thoughtbot developers like to follow in their code?

+ +

We'll link to the article in the show notes. But I'll just read out the rules here real quick. So, there's four of them. The first one is a class can be no longer than 100 lines of code. The second is a method can be no longer than five lines of code. The third is pass no more than four parameters into a method, and hash options count, so no getting clever with those. And then, finally, controllers can only instantiate one object. You only get one instance variable. And views can only talk to that one instance variable.

+ +

Had you or are you familiar with these rules? Is that something that you think about or use in your daily writing of code?

+ +

STEPHANIE: Yeah. So, when you proposed this topic, I had to revisit these rules. And I can't recall if I had seen them before. They seemed familiar. And I've read, you know, a couple of Sandi Metz's books, so maybe those were places where she had mentioned them.

+ +

But the one thing that really struck me when I was first reading the rules was how declarative they were in terms of, like, kind of just telling you what the results should be without really saying how. So, for example, the one where you said, you know, a method should not be more than five lines [laughs], I had the silly thought of, like, well, you could just, you know, stuff everything into a single line [laughs] and just completely disregard line limit if you wanted, and it would technically still follow the rule.

+ +

JOËL: If they didn't want us to do that, they wouldn't give us semicolons in Ruby.

+ +

STEPHANIE: Exactly [laughs]. So, that is kind of what struck me at first. Is that something you noticed?

+ +

JOËL: I think what is interesting with them is that there's not always a ton of rationale given behind them. Our article talks a little bit about some of the why that might be helpful and how that might look like in practice. I'm not sure what Sandi's original...I don't know if it was one of her books or maybe on a...it might have been on a podcast appearance she talked about them, so she might go more in-depth there. But yeah, they are a little bit declarative. It's just like, hey, here's...it's almost basically the kind of thing that can be enforced by a linter, which is perhaps the point.

+ +

STEPHANIE: Ooh, that's really interesting. It's like, on one hand, I like how simple they are, right? It's like, they're very obvious. If you're not following them, you can tell. But on the other hand, they seem to be more of a supplement to the gained knowledge and experience that you kind of get from knowing how to implement those rules. I think you and I will both agree that we don't want to stuff everything [laughs] into a single line with semicolons. But if someone who maybe is newer to development and is coming to these rules, I think they might be wondering, like, how do I do this?

+ +

JOËL: Do you follow these rules in your own code?

+ +

STEPHANIE: I think the ones that are easier to follow, for me, and that I think I've come to do more instinctually, are the rules about class line length and method line length just because I'm kind of looking out for opportunities to pull out a method or, you know, make sure that this class is just doing one thing. And if it's starting to seem to cover a couple of different responsibilities, I'm a little bit more on the lookout. But I do like these rules as like, you know, like, hey, once you hit, you know, 100 lines in a class, like, maybe that's your cue to start thinking about opportunities for extraction.

+ +

JOËL: Do you sort of consciously follow these rules or have them maybe even encoded in a linter? Or is it more you're following other things, and somehow, it just lines up with these principles?

+ +

STEPHANIE: I would say that, like, I'm not thinking about them very actively. But that could be a very interesting exercise, and I think, you know, that's what folks did in the blog post. They were like, hey, we took these rules, and we really kept them in mind as we were developing. But I think kind of what we were talking about earlier about, like, what we've learned or the strategies we've learned to implement kind of converge on these rules. And the rules actually are more of the result of other ideas or heuristics that we follow.

+ +

JOËL: I mean, you dropped the keyword heuristics there. And I think that brings me back to an earlier episode we did where we talked about heuristics. And one of the things that came up on that episode was the idea that, oftentimes, we use heuristics as a way to sort of flatten a lot of experience and knowledge into sort of one, like, short rule, or short phrase, or something, one guideline, even though it's sort of trying to just summarize a mountain of wisdom.

+ +

And so, oftentimes, you can look at something like these rules and be like, okay, well, what's the point? Or maybe you even just follow it to the letter without really thinking about the why behind it, and that can sometimes be problematic. And on the other hand, you might know all of the ideas that go behind them. And without necessarily knowing the rule itself, you just kind of happen to follow it because you're intimately familiar with all of these other software principles that converge on those same ideas.

+ +

STEPHANIE: Yeah, agreed. I think that the more interesting ones to me are the no more than four method arguments and only one instance variable per controller.

+ +

JOËL: Interesting.

+ +

STEPHANIE: I'm curious if those are sparking anything for you [laughs].

+ +

JOËL: I think the no more than four method arguments, to me, is probably the least controversial. It's generally accepted that having many arguments to a method is a code smell. And there's a few different code smells that are related to that. There's forms of coupling incandescence; there are data clumps, things like that.

+ +

I've often heard a sort of rule of three. And so, if you're going more than three, then you might want to revisit the structure of what you're building. Four is a bit of an arbitrary cut-off, I'll agree. Most of these are arbitrary cut-offs. But I think the idea to maybe keep your method to fewer arguments is generally a good thing to do.

+ +

STEPHANIE: I liked that the rule points out that hash options account because I think that's maybe where people get a little more hand-wavy, or you have your ops hash [laughs] that can be just a catch-all for anything. You know, it's like, once you start putting stuff in there, I don't know, I feel like it's a like a law of the universe. It's like, oh, people will just stuff more things in there [laughs]. And it takes obviously more effort or, like, specific energy to, like, think through what those things might represent, or some alternative ways of handling those arguments.

+ +

We definitely do have, I think, a couple of episodes on value objects. But that's something that we have talked a lot about before in terms of, you know, how can we take some kind of primitive data, hashes included, and turn them into a richer object that can then be passed on its own?

+ +

JOËL: Right. And an options hash is generally...it's too much of a catch-all to really have an identity as its own sort of value object. It doesn't really represent any single thing. It's just everything else bag of data. One thing that's interesting that the article notes is that a lot of the helpers in Rails take a lot of arguments and that it is absolutely not worth trying to fight the framework to try to follow these rules. So, the article does take a very pragmatic approach, I think, to the idea of these rules.

+ +

STEPHANIE: Yeah. And I think there is even a caveat to the rules where it's like, you can break them if you have a good reason, or if you're working with someone else and they give you the thumbs up [laughs], which I really like a lot because it almost kind of compels you to stop and be like, do I have a good reason of doing this? Just making sure, or I'll run it by a friend. And shifting that, I guess, that focus from kind of just coding from, like, your default mode of thinking to a more active one.

+ +

JOËL: Right. There is a rule zero, which says you can break any of the other rules as long as you convince either your pair or your reviewer to give you a thumbs up on breaking the rule.

+ +

So, you'd mentioned the fourth rule about a single instance variable in a controller kind of was one of the ones that stood out to you. What is particularly striking about that rule?

+ +

STEPHANIE: I think this one is hard to follow, and I think the blog post mentions that as well. Because at least I've seen our web applications grow more and more complex. And it can be really challenging to just be like, what is this page doing? Like, what, you know, data does it need to know? And have that be the single thing. Because really, a lot of our web apps have a lot of things [laughs] that they're doing, and sometimes it feels like you have to capture more than one object or at least, like, a responsibility in this way.

+ +

I think that's the one that I, you know, in my ideal world, I'm like, yeah, like, we have all these, like, perfectly RESTful routes. And, you know, we're only dealing with, you know, a single resource. But once you start to have some more complexity, I think that can be a little more challenging.

+ +

JOËL: I think it's interesting that you mentioned RESTful routing because I think that is maybe one of the bigger things that does trigger having more instance variables in your controller actions. If you're following sort of the traditional Rails RESTful routes, every page is generally focused on a singular resource. Now, that may not necessarily line up with a table in your database, and that's fine. But you're dealing with a singular thing or perhaps, you know, in the case of an index page, a singular collection of things, which can be represented with a single instance variable.

+ +

Once you start adding custom routes that may not be necessarily tied to a particular resource, now you can very easily kind of have a proliferation of all sorts of different things that interact with each other because you're no longer centered on a single thing.

+ +

STEPHANIE: Yeah, that's true, which actually reminds me of something we've talked about before, too, when we were both reading Sustainable Rails. The author talks about custom routes and actually advocates for making all routes RESTful. And if you need a vanity URL or something like that, you can always alias it. That I liked, right? It's like, okay, even if, you know, your resource is not something that's like, ActiveRecord-backed, is there some abstraction or concept of a resource in there?

+ +

And I actually did really like in the blog post in the example; that is one that I've used before, too. They were dealing with this idea of a dashboard, which I would, you know, say is pretty common in a lot of web applications these days. And it's funny because a dashboard can hold so much data, right? It's really, like, a composite of a lot of different things, you know, what is most, like, useful for the user to see in one place. But they were in the blog post. And this, again, this is kind of something that I've done before. They were able to capture that with the idea of, like, a dashboard as an object and that being codified using a presenter or a facade.

+ +

JOËL: Right. So, instead of having a group, and a status, and a user, and all these, like, separate things that your page that you're showing is a sort of collection of all these different types of objects, you wrap them together in a dashboard object that's kind of a facade. And I guess that really does line up with the idea of RESTful routing because you're likely going to have a dashboard's controller show action that's showing the user's dashboard. So, it makes sense, you know, that show page is rendering a dashboard object.

+ +

STEPHANIE: Can we talk a little bit about things not to do, or maybe things that might be a little more questionable [laughs], and if you've seen them and how you felt about them?

+ +

JOËL: I think it is sometimes tricky to define your boundaries right in that sometimes you create a facade object that really is just...it doesn't really represent anything. It's just there to wrap around some other things. And sometimes that can be awkward. I think the dashboard works partly because it lines up so neatly with the sort of RESTful routing and thinking in terms of resources that you want to do at the controller layer.

+ +

But drawing boundaries incorrectly or just trying to throw everything in some kind of grab bag object can...it's not a magic bullet, right? You've got to put some thought into the data modeling, even when you are pulling the facade pattern.

+ +

STEPHANIE: Yeah, I think other things that I've seen before that could theoretically follow this rule maybe [laughs], you know, I'd love to hear your thoughts about it. When you start, you're like, oh, like, my controller action method does just, you know, set one instance variable. But it turns out that there's all these other instance variables that either through a hook or, like, in the parent controller or even in the view I've seen before, too [laughs]. And I'm just kind of curious if that kind of raises your eyebrow at all or if you've seen any good reasons for doing so.

+ +

JOËL: I think setting instance variables in a view would absolutely cause me to raise an eyebrow.

+ +

STEPHANIE: [laughs] Agreed.

+ +

JOËL: Generally, don't put logic in the view. I think that we definitely have in parent controllers; we'll set other instance variables for things like maybe a current user, right? That's how we store that state. And I think that is totally fine to have around. Typically, we don't access that instance variable directly. We're referencing some kind of helper method. But yeah, I would not consider that a violation of the rule.

+ +

I think another common one that might come up is when you have some kind of nested resource. And so, in your URL, you might have a nested resource where you're saying, "Oh, I'm looking at specifically this comment under this article or something like that." And then, you want to have access to both objects in the controller. So, I think that's a pretty common scenario where you might want to have both instance variables.

+ +

Something that I'm thinking about...this is not a fully formed thought, so I'm curious about your opinions here. Is there an interesting distinction between variables in code that you want to use within a controller versus variables that you want to be accessible from a view? Because instance variables in a controller are kind of overloaded. They're a way of having state in a controller, but they're also a way of passing data into a view. And so, that sort of dual purpose there maybe causes them to be a little bit trickier to reason about than instance variables in a random Ruby object. What do you think?

+ +

STEPHANIE: Yeah, I was actually having the same thought as you were going there, which is that it is kind of interesting that the view, you know, is that level of what you want to display to your user. But it can have access to, like, whatever you put in the controller [laughs], and that is...and, you know, in some ways, it's like, that connection needs to happen somewhere, right? And it's here. But I think that can definitely be abused sometimes, too.

+ +

So, this, you know, fourth rule that we're talking about really has to do with a more traditional Rails app. But, again, with the complexity of web apps in 2023 [chuckles], you know, we also see Rails used just as an API a lot with a separate front-end framework. And your controller is rendering some JSON, which I think has that harder boundary between what is the data that the server is involved with and what we want to send to our client. And I'm curious if you have any thoughts about how this rule applies in that situation.

+ +

JOËL: I think I tend to see not really any difference there. If I'm building an API, typically, I'm trying to do so in a pretty RESTful manner. Maybe I'm doing a GraphQL API, and things might be different for that. But for a traditional REST API, yeah, typically, you're fetching one resource or some sort of compound resource, in which case, you're representing that with a facade object.

+ +

And yep, you can generally get away, I think, with a single instance variable with, you know, a few exceptions around maybe some extra context about maybe something like the current user, or a parent object, or something like that. I guess the view is really you're using a different mechanism for rendering JSON, and there are a bunch out there that the community uses. I think I don't really see a difference between rendering to HTML versus rendering to JSON, or XML, or whatever. How about you?

+ +

STEPHANIE: That's a good point. I think I'm with you where the rule still applies. But I have also seen things get really loosey-goosey [laughs] when we decide we're rendering JSON, and now we're suddenly putting the instance variables into a hash along with other stuff.

+ +

But what you said was interesting about, like, sometimes you do need that extra context, right? And, like, figuring out what the best way to package that requires a bit of, like, sustained thought, I think, because it can, you know, be really easy to be like, oh well, this is the one interface that I have to get data from the server. So, if I just sneak this in here [laughs], what's the matter? But yeah, I think, you know, that's probably why rules like this exist [laughs] to help provide some guardrails and make us think a little deeper about it.

+ +

JOËL: I think sometimes, as a community, we maybe exaggerate the differences between, like, RESTful HTML view and a RESTful JSON API. I tend to think of them as more or less the same. We just have, you know, a different representation the V layer of our MVC framework. Everything else still kind of lines up.

+ +

STEPHANIE: Yeah, that's a really good point. I actually hadn't thought about it that way. Because I think maybe I have been influenced by the world of GraphQL [laughs] a little bit, or it's kind of hard to have a foot in both worlds, where you maybe have to context switch a little bit about, like, the paradigms, and then you find them influencing you in different ways. Because I have seen sometimes, like, what maybe initially were meant to be traditional more, like, RESTful JSON APIs kind of start to turn into that, like, how do we get what we need from this endpoint?

+ +

JOËL: I'm curious how you feel in general about the facade pattern. Is that something that you've used, something that you like?

+ +

STEPHANIE: I think I would say that I don't actually reach for it, like, upfront, right? Usually, I'm still trying to maybe put some things in my models [laughs]. But I have used it before once; it kind of became clear that, like, a lot of the methods on the model had to do with more really server-side concerns. And I was, like, wanting to just pull out some presentational pieces. I think the hardest part with the facade pattern is naming. I have really struggled sometimes to think of, like, it's not quite the component that makes it up. So, what is it instead?

+ +

JOËL: Right. Right. I think, for me, sometimes the naming goes the other way around in that I'll start more to kind of, like, routing our resource level and try to think about, okay, this particular view of the data that I want to have, or this particular operation that I want to do, what am I actually dealing with? What is the resource here? So, maybe I'm viewing a dashboard. Or maybe what I'm doing is creating or destroying a subscription, even though those are not necessarily tables in the database. And once I have that underlying concept, then I can start creating an object that represents that, which might be a combination of multiple ActiveRecord models that represent tables.

+ +

STEPHANIE: Yeah. You're actually pointing out, like, a really great use case that we see a lot, I think, is when you start to have to reach for resources, you know, that are different ActiveRecord classes. And how do you combine them together to represent the idea that you want, you know, for your feature?

+ +

JOËL: I think it's more of, like, an outside-facing perspective rather than an inside-facing perspective. So, instead of looking at, hey, these are the set of ActiveRecord classes I have because these are my database tables, how can I, like, tack on to them to make this operation work? I'll sort of start almost from, like, a zoomed-out perspective, blank slate to say, "Hey, this is the kind of operation that I'm trying to do. What sort of resource am I dealing with ideally?"

+ +

And, you know, maybe the idea is, okay, I'm dealing with a dashboard. I'm trying to subscribe to something...a newsletter, so the idea is I'm creating a subscription. Then, from there, I can start looking at, okay, do I have the concept of a subscription in this application? Oh, I don't. There is no subscriptions table because that's not a thing that we track in our data mode. That's fine. But I probably need at least some kind of in-memory object to track the idea of a subscription, and then maybe from there, that grows. So, I'm kind of working from the problem towards the database rather than from the database out.

+ +

STEPHANIE: Yeah, I like that a lot. The outside-in phrase that you used really triggered something for me, which is being product engineers, right? Like, having a seat at the table when the feature is in that, like, ideation phase, I think is also really important because that's where you really learn what that like, abstraction is at the user level. And also, it could be a really good place to give your input if the feature is being designed in a way that doesn't really support the, you know, kind of quality of code and, like, separation that you would like. That's the part that I'm still working on and still learning how to do.

+ +

But sometimes, you know, it's, like, really critical to the job to, like, be in that room and be like, these designs; what are some places that we could extract it at that level even? And kind of, like, separate things out from there rather than having to deal with it [laughs] deep in your codebase.

+ +

JOËL: I think what I'm really kind of hearing and emphasizing in what you just said is the importance of not just writing code but being involved in the product and how that really enriches you because you know the problem domain. And that allows you to then write the code that you need at the different levels of the app to best model the situation you're working with.

+ +

So, we've kind of gone through all the rules and talked about them. I'm curious, though, for you, are these rules that you follow in your code? How closely do you adhere to this set of rules? Is this still something that's relevant to you in 2023 as much as it was to the authors of that blog post in 2013?

+ +

STEPHANIE: I have to say they're not ones that I have thought about on a daily basis, but after this conversation, maybe they will be. And I am kind of excited to maybe, like, bring this up to other people on my team and be like, "What do you think about these rules?" Just, like, revisiting them as a group or just, like, having that conversation. Because I think that's, you know, where I am most interested in is, like, is wondering how other people incorporate them into their work and hearing different opinions from the team. And I think there's a lot of, like, generative discussion that ultimately leads to better code as a result.

+ +

JOËL: I think for myself, I'm not following the rules directly. But a lot of my code ends up approximating those rules anyway because of other principles that I follow. So, in practice, while my code doesn't strictly follow those rules, it does look pretty close to that anyway.

+ +

STEPHANIE: I almost think this could be a great, you know, discussion for your team, too, like, if any listeners want to...not quite a book club but kind of an article club, if you will [laughs], and see how other people on your team feel about it. Because I think that's kind of where there is, like, a really sweet spot in terms of learning and development.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+PEiP_wIB + + ]]> + + Joël Quenneville + Stephanie Minn + + + 404: Estimation + https://bikeshed.thoughtbot.com/404 + e1671b1c-a14a-48b3-a123-b17604965f58 + Tue, 17 Oct 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël was selected to speak at RubyConf in San Diego! After spending a month testing out living in Upstate New York, Stephanie is back in Chicago. + +Stephanie reflects on a recent experience where she had to provide an estimate for a project, even though she didn't have enough information to do so accurately. In this episode, Stephanie and Joël explore the challenges of providing estimates, the importance of acknowledging uncertainty, and the need for clear communication and transparency when dealing with project timelines and scope. + 22:49 + no + + + Joël was selected to speak at RubyConf in San Diego! After spending a month testing out living in Upstate New York, Stephanie is back in Chicago. +Stephanie reflects on a recent experience where she had to provide an estimate for a project, even though she didn't have enough information to do so accurately. In this episode, Stephanie and Joël explore the challenges of providing estimates, the importance of acknowledging uncertainty, and the need for clear communication and transparency when dealing with project timelines and scope. +RubyConf 2023 (https://rubyconf.org/) +How to estimate well (https://thoughtbot.com/blog/how-to-estimate-feature-development-time-maybe-don-t) +XKCD hard problems (https://xkcd.com/1425/) +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: Big piece of news in my world: I recently got accepted to speak at RubyConf in San Diego next month in November. I'm really excited. I'm going to be talking about the concept of time and how that's actually multiple different things and the types of interactions that do and do not make sense when working with time. +STEPHANIE: Yay. That's so exciting. Congratulations. I am very excited about this topic. I'm wondering, is this something that you've been thinking about doing for a while now, or was it just an idea that was sparked recently? +JOËL: It's definitely a topic I've been thinking about for a long time. +STEPHANIE: Time? [laughs] +JOËL: Haha. +STEPHANIE: Sorry, that was an easy one [laughs]. +JOËL: The idea that we often use the English word time to refer to a bunch of, like, fundamentally different quantities and that, oftentimes, that can sort of blur into one another. So, the idea that a particular point in time might be different from a duration, might be different from a time of day, might be different to various other quantities that we refer to generically as time is something that's been in the back of my mind for quite a while. But I think turning that into a conference talk was a more recent idea. +STEPHANIE: Yeah, I'm curious, I guess, like, what was it that made you feel like, oh, like, this would be beneficial for other people? Did everything just come together, and you're like, oh, I finally have figured out time [laughs]; now I have this very clear mental model of it that I want to share with the world? +JOËL: I think it was sparked by a conversation I had with another member of the thoughtbot team. And it was just one of those where it's like, hey, I just had this really interesting conversation pulling on this idea that's been in the back of my mind for years. You know, it's conference season, and why not make that into a talk proposal? +As often, you know, the best talk proposals are, at least for me, I don't always think ahead of time, oh, this would be a great topic. But then, all of a sudden, it comes up in a conversation with a colleague or a client, or it becomes really relevant in some work that I'm doing. It happens to be conference season, and like, oh, that's something I want to talk about now. +STEPHANIE: Yeah, I like that a lot. I was just thinking about something I read recently. It was about creativity and art and how long a piece of work takes. And someone basically said it really just takes your whole life sometimes, right? It's like all of your experiences accumulated together that becomes whatever the body of work is. Like, all of that time spent maybe turning the idea in your head or just kind of, like, sitting with it or having those conversations, all the bugs you've probably encountered [laughs] involving date times, and all of that coalescing into something you want to create. +JOËL: And you build this sort of big web of ideas, not all that makes sense to talk about in a conference talk. So, one of the classic sources of bugs when dealing with time are time zone and daylight savings. I've chosen not to include those as part of this talk. I think other people have talked about them. I think it's less interesting or less connected to the core idea that I have that, like, there are different types of time. Let's dig into what that means for us. So, I purposefully left that out. But there's definitely a lot that could be said for those. +STEPHANIE: Awesome. Well, I really look forward to watching your talk when it is released to the public. +JOËL: So, our listeners won't be able to tell, but we're on a video call right now. And I can see from your background that you are back at home in Chicago. It's been a few weeks since we've recorded together. And, in the last episode we did, you were trying out living somewhere in Upstate New York. How was that experience? And what has the transition back to Chicago been for you? +STEPHANIE: Yeah, thanks for asking. I was in Upstate New York for the whole month of September. And then I took the last two weeks off of work to, you know, just really enjoy being there and make sure I got to do everything that I wanted to do out there before I came home to, you know, figure out, like, is this a place where I want to move? And yeah, this is my first, like, real full week back at work, back at home. +And I have to say it's kind of bittersweet. I think we really enjoyed our time out there, my partner and I. And coming back home, especially, you know, when you're in a stage of life where you're wanting to make a change, it can be a little tough to be like, uh, okay, like, now I have to go back [laughs] to what my life was like before. +But we've been very intentional about trying to bring back some of the things that we enjoyed being out there, like, back into just our regular day-to-day lives. So, over the weekend, we were making sure that we wanted to spend some time in nature because that's something that we were able to do a lot of during our time in New York. And, yeah, I think just bringing a bit of that, like, vacation energy into day-to-day life so the grind of kind of work doesn't become too much. +JOËL: Anything in particular that you've tried to bring back from that experience to your daily life in Chicago? +STEPHANIE: Yeah. I think, you know, when you're in a new place, everything is very exciting and, like, novel. Before work or, like, during my breaks, I would go out into the world and take a little walk and, like, look at the houses on the street that I was staying at. Or there's just a sense of wonder, I suppose, where everywhere you look, you're like, oh, like, this is all new. And I felt very, like, present when I was doing that. +And over time, when you've been somewhere for a long time, you lose a little bit of that sense of, like, willingness to be open to new things, or just, like, yeah, that sense of like, oh, like, curiosity, because you feel like you know somewhere and, like, you kind of start to expect oh, like, this street will be exactly like how I've walked a million times [laughs]. +But trying to look around a little more, right? Like, be a little aware and be like, oh, like, Halloween is coming around the corner. And so, enjoying that as, like, the thing that I notice around me, even if I am still on the same block, you know, in my same neighborhood, and, yeah, wanting to really appreciate, like, my time here before we leave. Like, I don't want to just spend it kind of waiting for the next thing to happen. Because I'm sure there will also be a time where I miss [laughs] Chicago here once we do decide to move. +JOËL: I don't know about you, but I feel like a sense of change, even if it is cyclical, is really helpful for me to kind of maintain a little bit of that wonder, even though I've lived in one place for a decade. So, I live in New England in the Northeast U.S. We have pretty marked seasons that change. And so, seeing that happen, you know, kind of a warm summer, and now we're transitioning into fall, and the weather is getting colder. The trees are turning all these colors. +So, there's always kind of within, like, a few weeks or a few months something to look forward to, something that's changing. Life never feels stagnant, even though it is cyclical. And I don't know if that's been a similar experience for you. +STEPHANIE: Yeah, I like that a lot because I think one of the issues around feeling kind of stuck here in Chicago was that things were starting to feel stagnant, right? Like, we're wanting to make a big change in our life. That's still on the table, and that's still our plan. But noticing change, even when you think like, ugh, like, this again? [laughs] I think that could really shift your perspective a little bit or at least change how you feel about being somewhere. And that's definitely what I'm trying to do, kind of even when I am in a place of, like, waiting to figure out what the next step is. +Speaking of change, I had a recent lesson learned or, I suppose, a story to share with you about a new insight or perspective I had about how I show up at work that I'd like to share. +JOËL: What is this new perspective? +STEPHANIE: Well, I guess, [chuckles], first of all, I'm curious to get your reaction on this. Have you ever heard anyone tell you estimates are lies? +JOËL: Yes, a lot. It's maybe cynical, but there are a lot of cynics in our industry. +STEPHANIE: That's true. Part of this story is me giving an estimate that was a lie. So, in some ways, there is a grain of truth to it [laughs]. But I wanted to share with you this experience I had a few weeks ago where I was in kind of a like, project status update meeting. And I was coming to this meeting for the first time actually. And so, it was with a group of people who I hadn't really met before. It was kind of a large meeting. So, there were a handful of people that I wasn't super familiar with. And I was coming in to share with this bigger group, like, how the work I had been doing was going. +And during that time, we had gotten some new information that was kind of making us reassess a few things about the work, trying to figure out, like, where to go next and how to meet our ultimate goal for delivering this feature. With that new information in mind, one of the project managers was asking me how long I thought it might take. And I did not have enough information to feel particularly confident about an answer, you know, I just didn't know. +And I mentioned that this was kind of my first time in this meeting. There were a lot of people I didn't know, including the person who was asking the question. And they were saying, "Oh, well, you can just guess or, like, you know, it doesn't have to be perfect. But could you give us a date?" And I felt really hard-pressed to give them an answer in that moment because, you know, I kind of was stalling a little bit. And there was still this, like, air of expectancy. +I eventually, I have to say, I made something up [laughs]. I was like, "Well, I don't know, like, three weeks," you know, just really pulling it out of thin air. And, you know, that's what they put down on the spreadsheet, and then they moved on [laughs] to the next item. And then, I sat there in the rest of the meeting. +And afterwards, I felt really bad. I, like, really regretted it, I think, because I knew that the answer I gave was mostly BS, right? Like, I can't even say how I came up with that. Just that I, like, wanted to maybe give us some extra time, in case the task ends up being complicated, or, you know, there are all these unknowns. But yeah, it really didn't feel good. +JOËL: I'm curious why that felt bad. Was it the uncertainty around that number or the fact that the number maybe you felt like you'd given, like, a ridiculously large number? Typically, I feel like when estimates are for a story, it's, like, in the order of a few days, not a few weeks. Or is it something else, the fact that you felt like you made it up? +STEPHANIE: I think both, where it was such a big task. The larger and higher level the task is, the harder it is to come up with an answer, let alone an accurate one. But it was knowing that, like, I didn't have the information. And even though I was doing as they asked of me [chuckles], it was almost like I lost a little bit of my own integrity, right? In terms of kind of based on my experience doing software development, like, I know when I don't know, and I wasn't able to say it. At least in that moment, didn't feel comfortable saying it. +JOËL: Because they're not taking no for an answer. +STEPHANIE: Yeah, yeah, or at least that was my interpretation of the conversation. But the insight or the learning that I took away from it was that I actually don't want to feel that way again [laughs], that I don't want to give a lie as an estimate because it didn't feel good for me. And the experience that I have knowing that I don't have an answer now, but there are, like, ways to get the answer, right? +What I wish I had said in that meeting was that I didn't know, but I could find out, or, like, I would let them know as soon as I did have more information. Or, like, here is the information that I do need to come up with something that is more useful to them, honestly, and could make it, like, a win for all of us. But yeah, I've been reflecting on [chuckles] that a lot. Because, in a sense, like, I really needed to trust myself and, like, trust my gut to have been able to do my best work. +JOËL: I wonder if there's maybe also a sense in which, you know, generally, you're a very kind of earnest person. And maybe by giving a ridiculous number there just to, like, check a box, maybe felt like you gave way to a certain level of cynicism that wasn't, like, true to who you are as a person. +STEPHANIE: Yeah, yeah, that feels real [laughs]. +JOËL: Have you ever done estimation sessions where you put error bars on your number? So, you say, hey, this is my estimate, but plus or minus. And, like, the more uncertainty there is around a number, the larger those plus or minus values are to the point where I could imagine something as ridiculous as like, oh, this is going to take three weeks, plus or minus three weeks. +STEPHANIE: I like that. That's funny. No, I have not ever done that before or even heard of that. That is a really interesting technique because that seems just more real to me, where, again, people have different opinions about estimation and how effective or useful it is. But for organizations where, like, it is somewhat valuable, or it is just part of the process, I like the idea of at least acknowledging the uncertainty or the ambiguity or, like, the level of confidence, right? That seems like an important piece of context to that information. +JOËL: And that can probably lead to some really interesting conversations as well because just getting a big number by itself, you might have a pretty high certainty. I mean, three weeks is big enough that you might say, okay, there's definitely going to be some fuzziness around that. But getting a sense of the certainty can, in certain contexts, I find, drive really interesting conversations about why things are uncertain. +And then, that can lead to some really good conversations around scoping about, okay, so we have this larger story. What are the elements of it that are uncertain that you might even talk in terms of risk? What are the risky elements of this story or maybe even a project? And how do we de-risk those? Is there a way that we could remove maybe a small part of the story and then, all of a sudden, those error bars of plus or minus three weeks drop down to plus or minus three days? Because that might be possible by having that conversation. +STEPHANIE: Yeah, I like what you said about scope because the way that it was presented as this really big chunk of work that was very critical to this deadline, there was no room to do scope, right? Because we weren't even talking about what makes up this feature task. We hadn't really broken it down. +In some ways, I think it was very, like, wishful, right? To be like, oh yeah, we want this feature. We're not going to talk too much about, like, the specific details [laughs], as opposed to the idea of it, right? And that, I think, is, you know, was part of what led to that ambiguity of, like, I can't even begin to estimate this because, like, it could mean so many different things. +JOËL: Right. And software problems, often, a slight change in the scope can make a massive change in complexity. I always think of a classic xkcd comic where two people are talking about a task, and somebody starts by describing something that kind of sounds complex. But the person implementing it is like, "Oh yeah, no, that's, you know, it's super easy. I can do that in half a day." And then, like, the person making the ask is like, "Oh, and, by the way, one small detail," and they add, like, one small thing that seems inconsequential, and the person is just like, "Okay, sorry, I'm going to need a research team and a couple of PhDs. And it's going to take us five years." +STEPHANIE: That's really funny. I haven't seen this comic before, but I need to [laughs] because I feel that so much where it's like, you just have different expectations about how long things will take. And I think maybe that is where, like, I felt really disappointed afterwards. Because in my inability to, like, just really speak up and say, like, "In my experience, like, this is kind of what happens when we don't have this information or when we aren't sure," yeah, I just wasn't able to bring that to the table in that, you know, meeting. +And I really am glad we're having this conversation now because I've been thinking about, like, okay, when I find myself in this position again, how would I like to respond differently? And even just that comic feels really validating [laughs] in terms of like, oh yeah, like, other people have experienced this before, where when we don't have that shared understanding or, like, if we're not being super transparent about how long does a thing really take, and why does it make it complex, or, like, what is challenging about it, it can be, like, speaking in [chuckles] two different languages sometimes. +JOËL: I think what I'm hearing almost is that in a situation like what you found yourself in, you're almost sort of wishing that you'd picked one extreme or the other, either sort of, like, standing up to—I assume this is a project manager or someone...to say, "Look, there's no number I can give you that's going to make sense. I'm not going to play this game. I have no number I can give you," and kind of ending it there. +Or, on the other hand, leaning into, say, "Okay, let's have a nuanced conversation, and we'll try to understand this. And we'll try to maybe scope it and maybe put some error bars on this or something and try to come up with a number that's a little bit more realistic." But by kind of, like, trying to maybe do a middle path where you just kind of give a ridiculously large number that's meaningless, maybe everybody feels unfulfilled, and that feels, like, maybe the worst of the paths you could have taken. +STEPHANIE: Yeah, I agree. I like that everyone [laughs] feels slightly unfulfilled point. Because, you know, my estimate is likely wrong. And, like, what impact will that have on other folks and, you know, their work? +While you were saying, like, oh yeah, here were the kind of two different options I could have chosen, I was thinking about the idea of, like, yeah, like, there are different strategies depending on the audience and depending who you're working with. And that is something I want to keep in mind, too, of, like, is this the right group to even have the, like, okay, let's figure this out conversation? Because it's not always the case, right? And sometimes you do need to just really stand firm and say, like, "I can't give you an answer. And I will go and find the people [laughs] who I can work this out with so that I can come back with what you need." +JOËL: And sometimes there may be a place for some sort of, like, placeholder data that is obviously wrong, but you need to put a value there, as long as everybody's clear on that's more or less what's happening. I had to do something kind of like that today. I'm connecting with a third-party SAML for authentication using the service Auth0. And this third party I'm talking to...so there's data that they need from me, and there's data that I need from them. They're not going to give me data until I give them our data first, so this is, like, you know, callback URLs, and entity IDs, and things like that you need to pass. +In order to have those, I need to stand up a SAML connection on the Auth0 side of things. In order to create that, Auth0 has a bunch of required fields, including some of the data that the third party would have given me. So, we've got a weird thing where, like, I need to give them data so they can stand up their end. But I can't really stand up my end until they give me some data. +STEPHANIE: Sounds like a circular dependency, if I've ever heard one [laughs]. +JOËL: It kind of is, right? And so, I wanted to get this rolling. I put in a bunch of fake values for these callback URLs and things like that in the places where it would not affect the data that I'm giving to the third party. And so, it will generate as a metadata file that gets generated and stuff like that. And so, I was able to get that data and send it over. But I did have to put a callback URL whose domain may or may not be example.com. +STEPHANIE: [laughs] Right. +JOËL: So, it is a placeholder. I have to remember to go and change it later on. But that was a situation where I felt better about doing that than about asking the third party, "Hey, can I get your information first?" +STEPHANIE: Yeah, I like that as sometimes, like, you recognize that in order to move forward, you need to put something or fill in that gap. And I think that, you know, there was always an opportunity afterwards to fix it or, like, to reassess and revisit it. +JOËL: With the caveat that, in software, there's nothing quite so permanent as a temporary fix. +STEPHANIE: Oof, yeah [laughs]. That's real. +JOËL: So, you know, caution advised, but yes. Don't always feel bad about placeholders if it allows you to unblock yourself. +STEPHANIE: So, I'm really glad I got to bring up this topic and tell you this story because it really got me thinking about what estimates mean to me. I'm curious if any of our listeners if you all have any input. Do you love estimates? Do you hate them? Did our conversation make you think about them differently? Feel free to write to us at hosts@bikeshed.fm. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeeeeee!!!!! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Joël was selected to speak at RubyConf in San Diego! After spending a month testing out living in Upstate New York, Stephanie is back in Chicago.

+ +

Stephanie reflects on a recent experience where she had to provide an estimate for a project, even though she didn't have enough information to do so accurately. In this episode, Stephanie and Joël explore the challenges of providing estimates, the importance of acknowledging uncertainty, and the need for clear communication and transparency when dealing with project timelines and scope.

+ +
+ + + +
+ +

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: Big piece of news in my world: I recently got accepted to speak at RubyConf in San Diego next month in November. I'm really excited. I'm going to be talking about the concept of time and how that's actually multiple different things and the types of interactions that do and do not make sense when working with time.

+ +

STEPHANIE: Yay. That's so exciting. Congratulations. I am very excited about this topic. I'm wondering, is this something that you've been thinking about doing for a while now, or was it just an idea that was sparked recently?

+ +

JOËL: It's definitely a topic I've been thinking about for a long time.

+ +

STEPHANIE: Time? [laughs]

+ +

JOËL: Haha.

+ +

STEPHANIE: Sorry, that was an easy one [laughs].

+ +

JOËL: The idea that we often use the English word time to refer to a bunch of, like, fundamentally different quantities and that, oftentimes, that can sort of blur into one another. So, the idea that a particular point in time might be different from a duration, might be different from a time of day, might be different to various other quantities that we refer to generically as time is something that's been in the back of my mind for quite a while. But I think turning that into a conference talk was a more recent idea.

+ +

STEPHANIE: Yeah, I'm curious, I guess, like, what was it that made you feel like, oh, like, this would be beneficial for other people? Did everything just come together, and you're like, oh, I finally have figured out time [laughs]; now I have this very clear mental model of it that I want to share with the world?

+ +

JOËL: I think it was sparked by a conversation I had with another member of the thoughtbot team. And it was just one of those where it's like, hey, I just had this really interesting conversation pulling on this idea that's been in the back of my mind for years. You know, it's conference season, and why not make that into a talk proposal?

+ +

As often, you know, the best talk proposals are, at least for me, I don't always think ahead of time, oh, this would be a great topic. But then, all of a sudden, it comes up in a conversation with a colleague or a client, or it becomes really relevant in some work that I'm doing. It happens to be conference season, and like, oh, that's something I want to talk about now.

+ +

STEPHANIE: Yeah, I like that a lot. I was just thinking about something I read recently. It was about creativity and art and how long a piece of work takes. And someone basically said it really just takes your whole life sometimes, right? It's like all of your experiences accumulated together that becomes whatever the body of work is. Like, all of that time spent maybe turning the idea in your head or just kind of, like, sitting with it or having those conversations, all the bugs you've probably encountered [laughs] involving date times, and all of that coalescing into something you want to create.

+ +

JOËL: And you build this sort of big web of ideas, not all that makes sense to talk about in a conference talk. So, one of the classic sources of bugs when dealing with time are time zone and daylight savings. I've chosen not to include those as part of this talk. I think other people have talked about them. I think it's less interesting or less connected to the core idea that I have that, like, there are different types of time. Let's dig into what that means for us. So, I purposefully left that out. But there's definitely a lot that could be said for those.

+ +

STEPHANIE: Awesome. Well, I really look forward to watching your talk when it is released to the public.

+ +

JOËL: So, our listeners won't be able to tell, but we're on a video call right now. And I can see from your background that you are back at home in Chicago. It's been a few weeks since we've recorded together. And, in the last episode we did, you were trying out living somewhere in Upstate New York. How was that experience? And what has the transition back to Chicago been for you?

+ +

STEPHANIE: Yeah, thanks for asking. I was in Upstate New York for the whole month of September. And then I took the last two weeks off of work to, you know, just really enjoy being there and make sure I got to do everything that I wanted to do out there before I came home to, you know, figure out, like, is this a place where I want to move? And yeah, this is my first, like, real full week back at work, back at home.

+ +

And I have to say it's kind of bittersweet. I think we really enjoyed our time out there, my partner and I. And coming back home, especially, you know, when you're in a stage of life where you're wanting to make a change, it can be a little tough to be like, uh, okay, like, now I have to go back [laughs] to what my life was like before.

+ +

But we've been very intentional about trying to bring back some of the things that we enjoyed being out there, like, back into just our regular day-to-day lives. So, over the weekend, we were making sure that we wanted to spend some time in nature because that's something that we were able to do a lot of during our time in New York. And, yeah, I think just bringing a bit of that, like, vacation energy into day-to-day life so the grind of kind of work doesn't become too much.

+ +

JOËL: Anything in particular that you've tried to bring back from that experience to your daily life in Chicago?

+ +

STEPHANIE: Yeah. I think, you know, when you're in a new place, everything is very exciting and, like, novel. Before work or, like, during my breaks, I would go out into the world and take a little walk and, like, look at the houses on the street that I was staying at. Or there's just a sense of wonder, I suppose, where everywhere you look, you're like, oh, like, this is all new. And I felt very, like, present when I was doing that.

+ +

And over time, when you've been somewhere for a long time, you lose a little bit of that sense of, like, willingness to be open to new things, or just, like, yeah, that sense of like, oh, like, curiosity, because you feel like you know somewhere and, like, you kind of start to expect oh, like, this street will be exactly like how I've walked a million times [laughs].

+ +

But trying to look around a little more, right? Like, be a little aware and be like, oh, like, Halloween is coming around the corner. And so, enjoying that as, like, the thing that I notice around me, even if I am still on the same block, you know, in my same neighborhood, and, yeah, wanting to really appreciate, like, my time here before we leave. Like, I don't want to just spend it kind of waiting for the next thing to happen. Because I'm sure there will also be a time where I miss [laughs] Chicago here once we do decide to move.

+ +

JOËL: I don't know about you, but I feel like a sense of change, even if it is cyclical, is really helpful for me to kind of maintain a little bit of that wonder, even though I've lived in one place for a decade. So, I live in New England in the Northeast U.S. We have pretty marked seasons that change. And so, seeing that happen, you know, kind of a warm summer, and now we're transitioning into fall, and the weather is getting colder. The trees are turning all these colors.

+ +

So, there's always kind of within, like, a few weeks or a few months something to look forward to, something that's changing. Life never feels stagnant, even though it is cyclical. And I don't know if that's been a similar experience for you.

+ +

STEPHANIE: Yeah, I like that a lot because I think one of the issues around feeling kind of stuck here in Chicago was that things were starting to feel stagnant, right? Like, we're wanting to make a big change in our life. That's still on the table, and that's still our plan. But noticing change, even when you think like, ugh, like, this again? [laughs] I think that could really shift your perspective a little bit or at least change how you feel about being somewhere. And that's definitely what I'm trying to do, kind of even when I am in a place of, like, waiting to figure out what the next step is.

+ +

Speaking of change, I had a recent lesson learned or, I suppose, a story to share with you about a new insight or perspective I had about how I show up at work that I'd like to share.

+ +

JOËL: What is this new perspective?

+ +

STEPHANIE: Well, I guess, [chuckles], first of all, I'm curious to get your reaction on this. Have you ever heard anyone tell you estimates are lies?

+ +

JOËL: Yes, a lot. It's maybe cynical, but there are a lot of cynics in our industry.

+ +

STEPHANIE: That's true. Part of this story is me giving an estimate that was a lie. So, in some ways, there is a grain of truth to it [laughs]. But I wanted to share with you this experience I had a few weeks ago where I was in kind of a like, project status update meeting. And I was coming to this meeting for the first time actually. And so, it was with a group of people who I hadn't really met before. It was kind of a large meeting. So, there were a handful of people that I wasn't super familiar with. And I was coming in to share with this bigger group, like, how the work I had been doing was going.

+ +

And during that time, we had gotten some new information that was kind of making us reassess a few things about the work, trying to figure out, like, where to go next and how to meet our ultimate goal for delivering this feature. With that new information in mind, one of the project managers was asking me how long I thought it might take. And I did not have enough information to feel particularly confident about an answer, you know, I just didn't know.

+ +

And I mentioned that this was kind of my first time in this meeting. There were a lot of people I didn't know, including the person who was asking the question. And they were saying, "Oh, well, you can just guess or, like, you know, it doesn't have to be perfect. But could you give us a date?" And I felt really hard-pressed to give them an answer in that moment because, you know, I kind of was stalling a little bit. And there was still this, like, air of expectancy.

+ +

I eventually, I have to say, I made something up [laughs]. I was like, "Well, I don't know, like, three weeks," you know, just really pulling it out of thin air. And, you know, that's what they put down on the spreadsheet, and then they moved on [laughs] to the next item. And then, I sat there in the rest of the meeting.

+ +

And afterwards, I felt really bad. I, like, really regretted it, I think, because I knew that the answer I gave was mostly BS, right? Like, I can't even say how I came up with that. Just that I, like, wanted to maybe give us some extra time, in case the task ends up being complicated, or, you know, there are all these unknowns. But yeah, it really didn't feel good.

+ +

JOËL: I'm curious why that felt bad. Was it the uncertainty around that number or the fact that the number maybe you felt like you'd given, like, a ridiculously large number? Typically, I feel like when estimates are for a story, it's, like, in the order of a few days, not a few weeks. Or is it something else, the fact that you felt like you made it up?

+ +

STEPHANIE: I think both, where it was such a big task. The larger and higher level the task is, the harder it is to come up with an answer, let alone an accurate one. But it was knowing that, like, I didn't have the information. And even though I was doing as they asked of me [chuckles], it was almost like I lost a little bit of my own integrity, right? In terms of kind of based on my experience doing software development, like, I know when I don't know, and I wasn't able to say it. At least in that moment, didn't feel comfortable saying it.

+ +

JOËL: Because they're not taking no for an answer.

+ +

STEPHANIE: Yeah, yeah, or at least that was my interpretation of the conversation. But the insight or the learning that I took away from it was that I actually don't want to feel that way again [laughs], that I don't want to give a lie as an estimate because it didn't feel good for me. And the experience that I have knowing that I don't have an answer now, but there are, like, ways to get the answer, right?

+ +

What I wish I had said in that meeting was that I didn't know, but I could find out, or, like, I would let them know as soon as I did have more information. Or, like, here is the information that I do need to come up with something that is more useful to them, honestly, and could make it, like, a win for all of us. But yeah, I've been reflecting on [chuckles] that a lot. Because, in a sense, like, I really needed to trust myself and, like, trust my gut to have been able to do my best work.

+ +

JOËL: I wonder if there's maybe also a sense in which, you know, generally, you're a very kind of earnest person. And maybe by giving a ridiculous number there just to, like, check a box, maybe felt like you gave way to a certain level of cynicism that wasn't, like, true to who you are as a person.

+ +

STEPHANIE: Yeah, yeah, that feels real [laughs].

+ +

JOËL: Have you ever done estimation sessions where you put error bars on your number? So, you say, hey, this is my estimate, but plus or minus. And, like, the more uncertainty there is around a number, the larger those plus or minus values are to the point where I could imagine something as ridiculous as like, oh, this is going to take three weeks, plus or minus three weeks.

+ +

STEPHANIE: I like that. That's funny. No, I have not ever done that before or even heard of that. That is a really interesting technique because that seems just more real to me, where, again, people have different opinions about estimation and how effective or useful it is. But for organizations where, like, it is somewhat valuable, or it is just part of the process, I like the idea of at least acknowledging the uncertainty or the ambiguity or, like, the level of confidence, right? That seems like an important piece of context to that information.

+ +

JOËL: And that can probably lead to some really interesting conversations as well because just getting a big number by itself, you might have a pretty high certainty. I mean, three weeks is big enough that you might say, okay, there's definitely going to be some fuzziness around that. But getting a sense of the certainty can, in certain contexts, I find, drive really interesting conversations about why things are uncertain.

+ +

And then, that can lead to some really good conversations around scoping about, okay, so we have this larger story. What are the elements of it that are uncertain that you might even talk in terms of risk? What are the risky elements of this story or maybe even a project? And how do we de-risk those? Is there a way that we could remove maybe a small part of the story and then, all of a sudden, those error bars of plus or minus three weeks drop down to plus or minus three days? Because that might be possible by having that conversation.

+ +

STEPHANIE: Yeah, I like what you said about scope because the way that it was presented as this really big chunk of work that was very critical to this deadline, there was no room to do scope, right? Because we weren't even talking about what makes up this feature task. We hadn't really broken it down.

+ +

In some ways, I think it was very, like, wishful, right? To be like, oh yeah, we want this feature. We're not going to talk too much about, like, the specific details [laughs], as opposed to the idea of it, right? And that, I think, is, you know, was part of what led to that ambiguity of, like, I can't even begin to estimate this because, like, it could mean so many different things.

+ +

JOËL: Right. And software problems, often, a slight change in the scope can make a massive change in complexity. I always think of a classic xkcd comic where two people are talking about a task, and somebody starts by describing something that kind of sounds complex. But the person implementing it is like, "Oh yeah, no, that's, you know, it's super easy. I can do that in half a day." And then, like, the person making the ask is like, "Oh, and, by the way, one small detail," and they add, like, one small thing that seems inconsequential, and the person is just like, "Okay, sorry, I'm going to need a research team and a couple of PhDs. And it's going to take us five years."

+ +

STEPHANIE: That's really funny. I haven't seen this comic before, but I need to [laughs] because I feel that so much where it's like, you just have different expectations about how long things will take. And I think maybe that is where, like, I felt really disappointed afterwards. Because in my inability to, like, just really speak up and say, like, "In my experience, like, this is kind of what happens when we don't have this information or when we aren't sure," yeah, I just wasn't able to bring that to the table in that, you know, meeting.

+ +

And I really am glad we're having this conversation now because I've been thinking about, like, okay, when I find myself in this position again, how would I like to respond differently? And even just that comic feels really validating [laughs] in terms of like, oh yeah, like, other people have experienced this before, where when we don't have that shared understanding or, like, if we're not being super transparent about how long does a thing really take, and why does it make it complex, or, like, what is challenging about it, it can be, like, speaking in [chuckles] two different languages sometimes.

+ +

JOËL: I think what I'm hearing almost is that in a situation like what you found yourself in, you're almost sort of wishing that you'd picked one extreme or the other, either sort of, like, standing up to—I assume this is a project manager or someone...to say, "Look, there's no number I can give you that's going to make sense. I'm not going to play this game. I have no number I can give you," and kind of ending it there.

+ +

Or, on the other hand, leaning into, say, "Okay, let's have a nuanced conversation, and we'll try to understand this. And we'll try to maybe scope it and maybe put some error bars on this or something and try to come up with a number that's a little bit more realistic." But by kind of, like, trying to maybe do a middle path where you just kind of give a ridiculously large number that's meaningless, maybe everybody feels unfulfilled, and that feels, like, maybe the worst of the paths you could have taken.

+ +

STEPHANIE: Yeah, I agree. I like that everyone [laughs] feels slightly unfulfilled point. Because, you know, my estimate is likely wrong. And, like, what impact will that have on other folks and, you know, their work?

+ +

While you were saying, like, oh yeah, here were the kind of two different options I could have chosen, I was thinking about the idea of, like, yeah, like, there are different strategies depending on the audience and depending who you're working with. And that is something I want to keep in mind, too, of, like, is this the right group to even have the, like, okay, let's figure this out conversation? Because it's not always the case, right? And sometimes you do need to just really stand firm and say, like, "I can't give you an answer. And I will go and find the people [laughs] who I can work this out with so that I can come back with what you need."

+ +

JOËL: And sometimes there may be a place for some sort of, like, placeholder data that is obviously wrong, but you need to put a value there, as long as everybody's clear on that's more or less what's happening. I had to do something kind of like that today. I'm connecting with a third-party SAML for authentication using the service Auth0. And this third party I'm talking to...so there's data that they need from me, and there's data that I need from them. They're not going to give me data until I give them our data first, so this is, like, you know, callback URLs, and entity IDs, and things like that you need to pass.

+ +

In order to have those, I need to stand up a SAML connection on the Auth0 side of things. In order to create that, Auth0 has a bunch of required fields, including some of the data that the third party would have given me. So, we've got a weird thing where, like, I need to give them data so they can stand up their end. But I can't really stand up my end until they give me some data.

+ +

STEPHANIE: Sounds like a circular dependency, if I've ever heard one [laughs].

+ +

JOËL: It kind of is, right? And so, I wanted to get this rolling. I put in a bunch of fake values for these callback URLs and things like that in the places where it would not affect the data that I'm giving to the third party. And so, it will generate as a metadata file that gets generated and stuff like that. And so, I was able to get that data and send it over. But I did have to put a callback URL whose domain may or may not be example.com.

+ +

STEPHANIE: [laughs] Right.

+ +

JOËL: So, it is a placeholder. I have to remember to go and change it later on. But that was a situation where I felt better about doing that than about asking the third party, "Hey, can I get your information first?"

+ +

STEPHANIE: Yeah, I like that as sometimes, like, you recognize that in order to move forward, you need to put something or fill in that gap. And I think that, you know, there was always an opportunity afterwards to fix it or, like, to reassess and revisit it.

+ +

JOËL: With the caveat that, in software, there's nothing quite so permanent as a temporary fix.

+ +

STEPHANIE: Oof, yeah [laughs]. That's real.

+ +

JOËL: So, you know, caution advised, but yes. Don't always feel bad about placeholders if it allows you to unblock yourself.

+ +

STEPHANIE: So, I'm really glad I got to bring up this topic and tell you this story because it really got me thinking about what estimates mean to me. I'm curious if any of our listeners if you all have any input. Do you love estimates? Do you hate them? Did our conversation make you think about them differently? Feel free to write to us at hosts@bikeshed.fm.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeeee!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + + Joël was selected to speak at RubyConf in San Diego! After spending a month testing out living in Upstate New York, Stephanie is back in Chicago.

+ +

Stephanie reflects on a recent experience where she had to provide an estimate for a project, even though she didn't have enough information to do so accurately. In this episode, Stephanie and Joël explore the challenges of providing estimates, the importance of acknowledging uncertainty, and the need for clear communication and transparency when dealing with project timelines and scope.

+ +
+ + + +
+ +

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: Big piece of news in my world: I recently got accepted to speak at RubyConf in San Diego next month in November. I'm really excited. I'm going to be talking about the concept of time and how that's actually multiple different things and the types of interactions that do and do not make sense when working with time.

+ +

STEPHANIE: Yay. That's so exciting. Congratulations. I am very excited about this topic. I'm wondering, is this something that you've been thinking about doing for a while now, or was it just an idea that was sparked recently?

+ +

JOËL: It's definitely a topic I've been thinking about for a long time.

+ +

STEPHANIE: Time? [laughs]

+ +

JOËL: Haha.

+ +

STEPHANIE: Sorry, that was an easy one [laughs].

+ +

JOËL: The idea that we often use the English word time to refer to a bunch of, like, fundamentally different quantities and that, oftentimes, that can sort of blur into one another. So, the idea that a particular point in time might be different from a duration, might be different from a time of day, might be different to various other quantities that we refer to generically as time is something that's been in the back of my mind for quite a while. But I think turning that into a conference talk was a more recent idea.

+ +

STEPHANIE: Yeah, I'm curious, I guess, like, what was it that made you feel like, oh, like, this would be beneficial for other people? Did everything just come together, and you're like, oh, I finally have figured out time [laughs]; now I have this very clear mental model of it that I want to share with the world?

+ +

JOËL: I think it was sparked by a conversation I had with another member of the thoughtbot team. And it was just one of those where it's like, hey, I just had this really interesting conversation pulling on this idea that's been in the back of my mind for years. You know, it's conference season, and why not make that into a talk proposal?

+ +

As often, you know, the best talk proposals are, at least for me, I don't always think ahead of time, oh, this would be a great topic. But then, all of a sudden, it comes up in a conversation with a colleague or a client, or it becomes really relevant in some work that I'm doing. It happens to be conference season, and like, oh, that's something I want to talk about now.

+ +

STEPHANIE: Yeah, I like that a lot. I was just thinking about something I read recently. It was about creativity and art and how long a piece of work takes. And someone basically said it really just takes your whole life sometimes, right? It's like all of your experiences accumulated together that becomes whatever the body of work is. Like, all of that time spent maybe turning the idea in your head or just kind of, like, sitting with it or having those conversations, all the bugs you've probably encountered [laughs] involving date times, and all of that coalescing into something you want to create.

+ +

JOËL: And you build this sort of big web of ideas, not all that makes sense to talk about in a conference talk. So, one of the classic sources of bugs when dealing with time are time zone and daylight savings. I've chosen not to include those as part of this talk. I think other people have talked about them. I think it's less interesting or less connected to the core idea that I have that, like, there are different types of time. Let's dig into what that means for us. So, I purposefully left that out. But there's definitely a lot that could be said for those.

+ +

STEPHANIE: Awesome. Well, I really look forward to watching your talk when it is released to the public.

+ +

JOËL: So, our listeners won't be able to tell, but we're on a video call right now. And I can see from your background that you are back at home in Chicago. It's been a few weeks since we've recorded together. And, in the last episode we did, you were trying out living somewhere in Upstate New York. How was that experience? And what has the transition back to Chicago been for you?

+ +

STEPHANIE: Yeah, thanks for asking. I was in Upstate New York for the whole month of September. And then I took the last two weeks off of work to, you know, just really enjoy being there and make sure I got to do everything that I wanted to do out there before I came home to, you know, figure out, like, is this a place where I want to move? And yeah, this is my first, like, real full week back at work, back at home.

+ +

And I have to say it's kind of bittersweet. I think we really enjoyed our time out there, my partner and I. And coming back home, especially, you know, when you're in a stage of life where you're wanting to make a change, it can be a little tough to be like, uh, okay, like, now I have to go back [laughs] to what my life was like before.

+ +

But we've been very intentional about trying to bring back some of the things that we enjoyed being out there, like, back into just our regular day-to-day lives. So, over the weekend, we were making sure that we wanted to spend some time in nature because that's something that we were able to do a lot of during our time in New York. And, yeah, I think just bringing a bit of that, like, vacation energy into day-to-day life so the grind of kind of work doesn't become too much.

+ +

JOËL: Anything in particular that you've tried to bring back from that experience to your daily life in Chicago?

+ +

STEPHANIE: Yeah. I think, you know, when you're in a new place, everything is very exciting and, like, novel. Before work or, like, during my breaks, I would go out into the world and take a little walk and, like, look at the houses on the street that I was staying at. Or there's just a sense of wonder, I suppose, where everywhere you look, you're like, oh, like, this is all new. And I felt very, like, present when I was doing that.

+ +

And over time, when you've been somewhere for a long time, you lose a little bit of that sense of, like, willingness to be open to new things, or just, like, yeah, that sense of like, oh, like, curiosity, because you feel like you know somewhere and, like, you kind of start to expect oh, like, this street will be exactly like how I've walked a million times [laughs].

+ +

But trying to look around a little more, right? Like, be a little aware and be like, oh, like, Halloween is coming around the corner. And so, enjoying that as, like, the thing that I notice around me, even if I am still on the same block, you know, in my same neighborhood, and, yeah, wanting to really appreciate, like, my time here before we leave. Like, I don't want to just spend it kind of waiting for the next thing to happen. Because I'm sure there will also be a time where I miss [laughs] Chicago here once we do decide to move.

+ +

JOËL: I don't know about you, but I feel like a sense of change, even if it is cyclical, is really helpful for me to kind of maintain a little bit of that wonder, even though I've lived in one place for a decade. So, I live in New England in the Northeast U.S. We have pretty marked seasons that change. And so, seeing that happen, you know, kind of a warm summer, and now we're transitioning into fall, and the weather is getting colder. The trees are turning all these colors.

+ +

So, there's always kind of within, like, a few weeks or a few months something to look forward to, something that's changing. Life never feels stagnant, even though it is cyclical. And I don't know if that's been a similar experience for you.

+ +

STEPHANIE: Yeah, I like that a lot because I think one of the issues around feeling kind of stuck here in Chicago was that things were starting to feel stagnant, right? Like, we're wanting to make a big change in our life. That's still on the table, and that's still our plan. But noticing change, even when you think like, ugh, like, this again? [laughs] I think that could really shift your perspective a little bit or at least change how you feel about being somewhere. And that's definitely what I'm trying to do, kind of even when I am in a place of, like, waiting to figure out what the next step is.

+ +

Speaking of change, I had a recent lesson learned or, I suppose, a story to share with you about a new insight or perspective I had about how I show up at work that I'd like to share.

+ +

JOËL: What is this new perspective?

+ +

STEPHANIE: Well, I guess, [chuckles], first of all, I'm curious to get your reaction on this. Have you ever heard anyone tell you estimates are lies?

+ +

JOËL: Yes, a lot. It's maybe cynical, but there are a lot of cynics in our industry.

+ +

STEPHANIE: That's true. Part of this story is me giving an estimate that was a lie. So, in some ways, there is a grain of truth to it [laughs]. But I wanted to share with you this experience I had a few weeks ago where I was in kind of a like, project status update meeting. And I was coming to this meeting for the first time actually. And so, it was with a group of people who I hadn't really met before. It was kind of a large meeting. So, there were a handful of people that I wasn't super familiar with. And I was coming in to share with this bigger group, like, how the work I had been doing was going.

+ +

And during that time, we had gotten some new information that was kind of making us reassess a few things about the work, trying to figure out, like, where to go next and how to meet our ultimate goal for delivering this feature. With that new information in mind, one of the project managers was asking me how long I thought it might take. And I did not have enough information to feel particularly confident about an answer, you know, I just didn't know.

+ +

And I mentioned that this was kind of my first time in this meeting. There were a lot of people I didn't know, including the person who was asking the question. And they were saying, "Oh, well, you can just guess or, like, you know, it doesn't have to be perfect. But could you give us a date?" And I felt really hard-pressed to give them an answer in that moment because, you know, I kind of was stalling a little bit. And there was still this, like, air of expectancy.

+ +

I eventually, I have to say, I made something up [laughs]. I was like, "Well, I don't know, like, three weeks," you know, just really pulling it out of thin air. And, you know, that's what they put down on the spreadsheet, and then they moved on [laughs] to the next item. And then, I sat there in the rest of the meeting.

+ +

And afterwards, I felt really bad. I, like, really regretted it, I think, because I knew that the answer I gave was mostly BS, right? Like, I can't even say how I came up with that. Just that I, like, wanted to maybe give us some extra time, in case the task ends up being complicated, or, you know, there are all these unknowns. But yeah, it really didn't feel good.

+ +

JOËL: I'm curious why that felt bad. Was it the uncertainty around that number or the fact that the number maybe you felt like you'd given, like, a ridiculously large number? Typically, I feel like when estimates are for a story, it's, like, in the order of a few days, not a few weeks. Or is it something else, the fact that you felt like you made it up?

+ +

STEPHANIE: I think both, where it was such a big task. The larger and higher level the task is, the harder it is to come up with an answer, let alone an accurate one. But it was knowing that, like, I didn't have the information. And even though I was doing as they asked of me [chuckles], it was almost like I lost a little bit of my own integrity, right? In terms of kind of based on my experience doing software development, like, I know when I don't know, and I wasn't able to say it. At least in that moment, didn't feel comfortable saying it.

+ +

JOËL: Because they're not taking no for an answer.

+ +

STEPHANIE: Yeah, yeah, or at least that was my interpretation of the conversation. But the insight or the learning that I took away from it was that I actually don't want to feel that way again [laughs], that I don't want to give a lie as an estimate because it didn't feel good for me. And the experience that I have knowing that I don't have an answer now, but there are, like, ways to get the answer, right?

+ +

What I wish I had said in that meeting was that I didn't know, but I could find out, or, like, I would let them know as soon as I did have more information. Or, like, here is the information that I do need to come up with something that is more useful to them, honestly, and could make it, like, a win for all of us. But yeah, I've been reflecting on [chuckles] that a lot. Because, in a sense, like, I really needed to trust myself and, like, trust my gut to have been able to do my best work.

+ +

JOËL: I wonder if there's maybe also a sense in which, you know, generally, you're a very kind of earnest person. And maybe by giving a ridiculous number there just to, like, check a box, maybe felt like you gave way to a certain level of cynicism that wasn't, like, true to who you are as a person.

+ +

STEPHANIE: Yeah, yeah, that feels real [laughs].

+ +

JOËL: Have you ever done estimation sessions where you put error bars on your number? So, you say, hey, this is my estimate, but plus or minus. And, like, the more uncertainty there is around a number, the larger those plus or minus values are to the point where I could imagine something as ridiculous as like, oh, this is going to take three weeks, plus or minus three weeks.

+ +

STEPHANIE: I like that. That's funny. No, I have not ever done that before or even heard of that. That is a really interesting technique because that seems just more real to me, where, again, people have different opinions about estimation and how effective or useful it is. But for organizations where, like, it is somewhat valuable, or it is just part of the process, I like the idea of at least acknowledging the uncertainty or the ambiguity or, like, the level of confidence, right? That seems like an important piece of context to that information.

+ +

JOËL: And that can probably lead to some really interesting conversations as well because just getting a big number by itself, you might have a pretty high certainty. I mean, three weeks is big enough that you might say, okay, there's definitely going to be some fuzziness around that. But getting a sense of the certainty can, in certain contexts, I find, drive really interesting conversations about why things are uncertain.

+ +

And then, that can lead to some really good conversations around scoping about, okay, so we have this larger story. What are the elements of it that are uncertain that you might even talk in terms of risk? What are the risky elements of this story or maybe even a project? And how do we de-risk those? Is there a way that we could remove maybe a small part of the story and then, all of a sudden, those error bars of plus or minus three weeks drop down to plus or minus three days? Because that might be possible by having that conversation.

+ +

STEPHANIE: Yeah, I like what you said about scope because the way that it was presented as this really big chunk of work that was very critical to this deadline, there was no room to do scope, right? Because we weren't even talking about what makes up this feature task. We hadn't really broken it down.

+ +

In some ways, I think it was very, like, wishful, right? To be like, oh yeah, we want this feature. We're not going to talk too much about, like, the specific details [laughs], as opposed to the idea of it, right? And that, I think, is, you know, was part of what led to that ambiguity of, like, I can't even begin to estimate this because, like, it could mean so many different things.

+ +

JOËL: Right. And software problems, often, a slight change in the scope can make a massive change in complexity. I always think of a classic xkcd comic where two people are talking about a task, and somebody starts by describing something that kind of sounds complex. But the person implementing it is like, "Oh yeah, no, that's, you know, it's super easy. I can do that in half a day." And then, like, the person making the ask is like, "Oh, and, by the way, one small detail," and they add, like, one small thing that seems inconsequential, and the person is just like, "Okay, sorry, I'm going to need a research team and a couple of PhDs. And it's going to take us five years."

+ +

STEPHANIE: That's really funny. I haven't seen this comic before, but I need to [laughs] because I feel that so much where it's like, you just have different expectations about how long things will take. And I think maybe that is where, like, I felt really disappointed afterwards. Because in my inability to, like, just really speak up and say, like, "In my experience, like, this is kind of what happens when we don't have this information or when we aren't sure," yeah, I just wasn't able to bring that to the table in that, you know, meeting.

+ +

And I really am glad we're having this conversation now because I've been thinking about, like, okay, when I find myself in this position again, how would I like to respond differently? And even just that comic feels really validating [laughs] in terms of like, oh yeah, like, other people have experienced this before, where when we don't have that shared understanding or, like, if we're not being super transparent about how long does a thing really take, and why does it make it complex, or, like, what is challenging about it, it can be, like, speaking in [chuckles] two different languages sometimes.

+ +

JOËL: I think what I'm hearing almost is that in a situation like what you found yourself in, you're almost sort of wishing that you'd picked one extreme or the other, either sort of, like, standing up to—I assume this is a project manager or someone...to say, "Look, there's no number I can give you that's going to make sense. I'm not going to play this game. I have no number I can give you," and kind of ending it there.

+ +

Or, on the other hand, leaning into, say, "Okay, let's have a nuanced conversation, and we'll try to understand this. And we'll try to maybe scope it and maybe put some error bars on this or something and try to come up with a number that's a little bit more realistic." But by kind of, like, trying to maybe do a middle path where you just kind of give a ridiculously large number that's meaningless, maybe everybody feels unfulfilled, and that feels, like, maybe the worst of the paths you could have taken.

+ +

STEPHANIE: Yeah, I agree. I like that everyone [laughs] feels slightly unfulfilled point. Because, you know, my estimate is likely wrong. And, like, what impact will that have on other folks and, you know, their work?

+ +

While you were saying, like, oh yeah, here were the kind of two different options I could have chosen, I was thinking about the idea of, like, yeah, like, there are different strategies depending on the audience and depending who you're working with. And that is something I want to keep in mind, too, of, like, is this the right group to even have the, like, okay, let's figure this out conversation? Because it's not always the case, right? And sometimes you do need to just really stand firm and say, like, "I can't give you an answer. And I will go and find the people [laughs] who I can work this out with so that I can come back with what you need."

+ +

JOËL: And sometimes there may be a place for some sort of, like, placeholder data that is obviously wrong, but you need to put a value there, as long as everybody's clear on that's more or less what's happening. I had to do something kind of like that today. I'm connecting with a third-party SAML for authentication using the service Auth0. And this third party I'm talking to...so there's data that they need from me, and there's data that I need from them. They're not going to give me data until I give them our data first, so this is, like, you know, callback URLs, and entity IDs, and things like that you need to pass.

+ +

In order to have those, I need to stand up a SAML connection on the Auth0 side of things. In order to create that, Auth0 has a bunch of required fields, including some of the data that the third party would have given me. So, we've got a weird thing where, like, I need to give them data so they can stand up their end. But I can't really stand up my end until they give me some data.

+ +

STEPHANIE: Sounds like a circular dependency, if I've ever heard one [laughs].

+ +

JOËL: It kind of is, right? And so, I wanted to get this rolling. I put in a bunch of fake values for these callback URLs and things like that in the places where it would not affect the data that I'm giving to the third party. And so, it will generate as a metadata file that gets generated and stuff like that. And so, I was able to get that data and send it over. But I did have to put a callback URL whose domain may or may not be example.com.

+ +

STEPHANIE: [laughs] Right.

+ +

JOËL: So, it is a placeholder. I have to remember to go and change it later on. But that was a situation where I felt better about doing that than about asking the third party, "Hey, can I get your information first?"

+ +

STEPHANIE: Yeah, I like that as sometimes, like, you recognize that in order to move forward, you need to put something or fill in that gap. And I think that, you know, there was always an opportunity afterwards to fix it or, like, to reassess and revisit it.

+ +

JOËL: With the caveat that, in software, there's nothing quite so permanent as a temporary fix.

+ +

STEPHANIE: Oof, yeah [laughs]. That's real.

+ +

JOËL: So, you know, caution advised, but yes. Don't always feel bad about placeholders if it allows you to unblock yourself.

+ +

STEPHANIE: So, I'm really glad I got to bring up this topic and tell you this story because it really got me thinking about what estimates mean to me. I'm curious if any of our listeners if you all have any input. Do you love estimates? Do you hate them? Did our conversation make you think about them differently? Feel free to write to us at hosts@bikeshed.fm.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeeee!!!!!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+c12RFMt1 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 403: Productivity Tricks + https://bikeshed.thoughtbot.com/403 + f2e4c32f-33a0-4768-9275-fa892b60ced3 + Tue, 26 Sep 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie is engrossed in Kent Beck's Substack newsletter, which she appreciates for its "working thoughts" format. Unlike traditional media that undergo rigorous editing, Kent's content is more of a work-in-progress, focusing on thought processes and evolving ideas. Joël has been putting a lot of thought into various tools and techniques and realized that they all fall under one umbrella term: analysis. + +From there, Stephanie and Joël discuss all the productivity tricks they like to use in their daily workflows. Do you have some keyboard shortcuts you like? Are you an Alfred wizard? What are some tools or mindsets around productivity that make YOUR life better? + 37:49 + no + + + Stephanie is engrossed in Kent Beck's Substack newsletter, which she appreciates for its "working thoughts" format. Unlike traditional media that undergo rigorous editing, Kent's content is more of a work-in-progress, focusing on thought processes and evolving ideas. Joël has been putting a lot of thought into various tools and techniques and realized that they all fall under one umbrella term: analysis. +From there, Stephanie and Joël discuss all the productivity tricks they like to use in their daily workflows. Do you have some keyboard shortcuts you like? Are you an Alfred wizard? What are some tools or mindsets around productivity that make YOUR life better? +Kent Beck’s Substack Tidy First? (https://tidyfirst.substack.com/) +Debugging: Listing Your Assumptions (https://thoughtbot.com/blog/debugging-listing-your-assumptions) +Dash (https://kapeli.com/dash) +Alfred (https://www.alfredapp.com/) +Rectangle (https://rectangleapp.com/) +Meeter (https://apps.apple.com/us/app/meeter-for-zoom-teams-co/id1510445899) +Vim plugins (https://github.com/thoughtbot/dotfiles/blob/main/vimrc.bundles#L32-L50) from thoughtbot’s dotfiles, including vim-projectionist () for alternate files +Go To Spec VS Code plugin (https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec) +Feedbin (https://feedbin.com/) +Energy Makes Time by Mandy Brown (https://everythingchanges.us/blog/energy-makes-time/) +Transcript: +AD: +Ruby developers, The Rocky Mountain Ruby Conference returns to Boulder, Colorado, on October 5th and 6th. Join us for two days of insightful talks from experienced Ruby developers and plenty of opportunities to connect with your Ruby community. +But that's not all. Nestled on the edge of the breathtaking Rocky Mountains, Boulder is a haven for outdoor lovers of all stripes. Take a break from coding. Come learn and enjoy at the conference and explore the charm of Downtown Boulder: eclectic shops, first-class restaurants and bars, and incredible street art everywhere. Immerse yourself in the vibrant culture and the many microbrew pubs that Boulder has to offer. +Grab your tickets now at rockymtnruby.dev and be a part of the 2023 Rocky Mountain Ruby Conference. That's rockymtnruby.dev, October 5th and 6th in Boulder. See you there. +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, I have a new piece of content that I'm consuming lately. That is Kent Beck's Substack [chuckles], Kent Beck of Agile Manifesto and Extreme Programming notoriety. I have been really enjoying this trend of independent content creation in the newsletter format lately, and I subscribe to a lot of newsletters for things outside of work as well. I've been using an RSS feed to like, keep track of all of the dispatches I'm following in that way so that it also kind of keeps out of my inbox. And it's purely just for when I'm in an internet-reading kind of mood. +But I subscribed to Kent's Substack. Most of his content is behind a subscription. And I've been really enjoying it because he treats it as a place for a lot of his working thoughts, kind of a space that he uses to explore topics that could be whole books. But he is still in the phase of kind of, like, thinking them through and, like, integrating, you know, different things he's learning, and acknowledging that, like, yeah, like, not all of these ideas are fully fleshed, but they are still worth publishing for people who might be interested in kind of his thought process or where his head is at. +And I think that is really cool and very different from just, like, other types of content I consume, where there has been, like, a lot of, especially more traditional media, where there has been, like, more editing involved and a lot of time and effort to reach a final product. And I'm curious about this, like I mentioned, trend towards a little less polished and people just publishing things as they're working through them and acknowledging that the way they're thinking about things can change over time. +JOËL: It sounds like this is kind of halfway between a book which has gone through a lot of editing and, you know, a tweet thread, which is pure stream of consciousness. +STEPHANIE: Yeah, that's a really great insight, actually. And I think that might be my sweet spot in terms of things I enjoy consuming or reading because I like that room for change and that there is a bit of a, you know, community aspect to Substack where you can comment on posts. But, at least in my experience, has seemed, like, relatively healthy because it is, you know, you're kind of with a community of people who are at least invested or willing to pay [chuckles] for the content. So, there is some amount of good faith involved. +His newsletter title itself it's called "Tidy First?" And so, that almost implies that it's, like, something he's still exploring or experimenting with, which I think is really cool. It's not like a I have discovered, like, the perfect way to do things, and, you know, you must always tidy first before you do your software development. He's kind of in the position of, this is what I think works, and this is my space for continuing to refine this idea. +JOËL: I'm curious: are there any sort of articles that you've read or just thoughts in general that you've seen from Kent that are particularly impactful or memorable to you? +STEPHANIE: Yeah. One I read today during my investment time is called Accountability in Software Development. And it was a very interesting take on the idea of accountability, not necessarily, like, when it's forced by others or external forces like a manager or, you know, your organization, but when it comes from yourself. And he describes it as a way to feel comfortable and confident in the work that he's doing and also building trust in himself and in his work but also in his teams. +By being transparent and literally accounting for the things that he's doing and sharing them, communicating them publicly, that almost ends up diminishing any kind of, like, distrust, or shame, or any of those weird kind of squishy things that can happen when you hide those things or, like, hide what you're doing. It becomes a way to foster the good parts of working with other people but not in a necessarily like, resentful way or in a hierarchical way. I was really interested in the idea of accountability, ultimately, like, for yourself, and then that ends up just propagating to the team. +JOËL: That's a really interesting topic because I think it sort of sits at the intersection of the personal and the technical. +STEPHANIE: Yeah, absolutely. He mentions more technical strategies or tasks that kind of do the same thing. You know, he mentions test-driven development, as well as, like, a way of holding yourself accountable to writing software that, you know, doesn't have bugs in it. So, I think that it can be applied to, you know, exactly both of those, like, interpersonal stuff and also technical aspects too, anyway, that's what's new in my world. Joël, what about you? +JOËL: So, this year, I've been putting a lot of thought into a variety of tools and processes. And I think I've come to the realization that they all really fall under one kind of umbrella term, and that would be analysis. It's a common step in some definitions of the traditional software development lifecycle. And it's where you try to after you've kind of gathered the requirements, try to break them down and understand what exactly that means from a technical perspective, what needs to happen. And so, a lot of the things that have been really fascinating to me this year have been different techniques that I can use to become better at that sort of phase. +STEPHANIE: Wow. That's very powerful, I think. And honestly, the first thing that comes to mind is, how do you make time for it? +JOËL: I think we all do it to a certain extent. You know, you pick up a ticket, and there is a prose description of some work to be done, hopefully not telling you directly, like, just go make a change to this class, but here's a business problem to be solved. And then you have to sort of figure out how to break it down. So, this can be as simple as, oh, what objects, what classes do I need to introduce for this change? But it might be more subtle in terms of thinking, okay, well, what are the edge cases I need to think about? Where are things that could fail, and how am I going to handle failure? +So, there's a variety of techniques that you can use to get better at all of these. You can use them kind of at the micro level when thinking about just a ticket. You can use them when working on a larger epic, a larger initiative, a whole project because I think analysis fits into kind of all of these levels. And so, I think those are the techniques that have been most exciting to me this year and that have really connected. +STEPHANIE: That is very exciting. It's triggering a lot of thoughts for me about how I incorporate analysis into my work and how that has actually evolved; where I think before, earlier in my career, I assumed that the analysis had been done by someone else who knew better than me or who knew more than me. And that by the time that you know, a piece of work kind of landed in my lap, I was like, okay, well, I just want to know what to do, right? Like, I want someone else to tell me what to do [laughs]. But now I think I have taken it upon myself to do more of that and, like, have realized that it's part of my role. +And sometimes it will now be kind of a flag or, like, a signal to me when that hasn't been done. And I can tell when I receive a ticket, and it's, like, maybe missing the business problem or doesn't have enough information. And determining whether that is information that I need to go and find out, or if there's someone else who I can work together with to do that analysis with, or having a better understanding of, like, what is within my realm of analysis to do, and what I need to encourage other people to do analysis for before the work is ready for me. +JOËL: I think there is an interesting distinction between more traditional requirements gathering and analysis, where traditional requirements gathering is getting all that business problem information from product people, from customers, things like that. The analysis step is often a little bit more about breaking down a business problem into, like, what are the technical ramifications of that? +But there can be a little of a synergy there where sometimes, once you start exploring the technical side of it, it might bring up a lot of edge cases that have impacts on the product side, on the business side. And then you have to go back to the businesspeople and say, "Hey, we only talked about sort of the happy path. What happens if payment is declined? What do we want to do there?" And now we're back in sort of that requirements gathering phase a little bit more rather than purely analysis. +But it can come out of an analysis phase where you've done maybe some state machine diagramming to try to better understand how things flow from one phase to another. Or maybe you were building out a truth table for some complex logic and realized, wait a minute, there's an edge case I didn't handle. It's not a strictly linear process. The two kind of feed into each other and, honestly, into the implementation side as well. +STEPHANIE: Yeah, I'm with you there. I'm thinking about a piece of work that I've been working on, where we were thinking of doing a database migration and adding some new columns to a table. But the more I dug into it, the more I realized that that was the first idea or the immediate idea that came from a need that I had limited information about. And what was nice was I was able to sit on it for a little bit, get some input from others. And I realized that there were all of these things that I couldn't answer yet. +And someone, I think literally asked in a code review if you've already done this analysis, between knowing that these columns will be the kind of extent of what you need versus, you know, will the data end up needing more columns? And should the data model be a little more flexible to that potential change? And they said, "If you had already done this analysis, then, like, otherwise, it looks good to me." And I was like, "Oh, I didn't." [laughs] +And that encouraged me to go back to some cross-functional members of the team and ask more questions. And that has taken more time. That was another challenge that I had to encounter was saying like, "Yeah, we started this, and we made some progress. But actually, we need to revisit a few things, like a few parts of the premise, before continuing on." +JOËL: Are there any techniques or approaches that you particularly enjoy when it comes to doing an analysis or that maybe are go-to's for you? +STEPHANIE: Reminding myself to revisit my assumptions [laughs], or at least even starting by being really clear about what I'm assuming, right? Because I think that has to happen first before you can even revisit them is having an awareness of what assumptions you're making. And I actually think this is where collaboration has been really helpful, where I've been working on this task with another developer on my team. And when we've been talking about it, I found myself saying, "Oh, I'm assuming this," right? Or, like, I'm assuming that the stakeholder knows what they need [laughs]. And that's why we're going to do it this way, where we were kind of given the pieces of data that we should be persisting. +And the more that we had that conversation, the more I realized, like, actually, like, I'm not convinced that they have that full picture of, like, what they need in the future. And because we're making this decision now, like, we are turning, you know, literally from, like, the abstract into, like, a concrete change [chuckles] in the database, now seems like...now that we're faced with that decision, it seems like a good time to revisit the assumption that I was making. +And that has proved helpful in making ultimately, like, a more informed decision about, like, which way to go technically. But I personally have found a lot of value in verbally processing it with someone else. It's a lot harder for me to identify them, I think, when I'm in my own head. +JOËL: That's really interesting that you keyed in on the idea of assumptions. I typically think of assumptions being, like, so important mostly in debugging rather than analysis. In fact, I wrote a whole blog post about why listing your assumptions is so important as part of your debugging process. +Now, like, my mind is spinning a little bit. I'm like, oh, I wonder if I could use some of those, like, debugging techniques as part of more of my analysis step. And could that make me better? So, I think you've put me on a whole, like, thought track of, like, oh, how many of these debugging techniques can I use to make my analysis better? So, that's really cool. +STEPHANIE: Yeah, and vice versa. So, a few minutes ago, I'd asked you how you make time for that analysis. Because I was thinking that, you know, in my day-to-day work, I'm juggling so many things. I often find myself running out of time and not able to do all of it. And that, I think, leads us really well into our topic for this episode, which is productivity tricks and ways that we make the most use out of our limited time. +JOËL: I think I may have a maybe a bit of a controversial opinion on productivity tricks. I feel like a lot of productivity tricks don't actually make me that much faster. Like, maybe I save a couple of minutes a day, maybe 5 or 10 a day with productivity tricks. And, sure, that adds up over the course of a year. But there are other things I could do in terms of, like, maybe better habits, better managing of my schedule that probably have a much more significant impact. +Where I think they are incredibly valuable, though, is not directly making me better with my time management but managing my focus, allowing me to kind of keep in the flow and get things done without getting sidetracked. Or just kind of giving me the things that I need in the moment that I need them so that I'm not getting on to a subtask that I don't really need to be doing. +STEPHANIE: Yeah. I really like that reframing of what helps you focus because as I was brainstorming ways that I stay on track for my work, I think I ended up discovering a similar theme where it wasn't so much, like, little snippets and tools for me, as opposed to how I structure all of the noise, I guess, in my day-to-day work and being able to see what it is that I need to care about the most right now. +JOËL: I think one of the things that I've tried to do for myself is to make it easy to have access to the information and the tools that I need. Probably one of the most useful bits of that is a combination of the documentation viewer Dash and the...I'm not sure what it would be called– launcher, productivity manager tool for Mac. Alfred, with a CMD + Space, it brings up this bar I can type into. And then you can trigger all sorts of things from there. +And so I can type the name of a language or some kind of keyword that I have set up and the name of a method. And then, all of a sudden, it'll show me everything like, you know, top five results. And I can hit Enter, and it will bring up the documentation for that. +So, if I want to say, oh yeah, what is the order of the arguments for Enumerable's inject method (which I constantly forget)? You know, it's a few keyboard shortcuts, you know, CMD + Space Ruby Enumerable inject. It's fuzzy finding, so I probably don't even need to type all of that. Hit Enter, and I have the documentation right in front of me. So, that makes it so that I can get access to that with very little amount of context shifting. +STEPHANIE: Yeah. I like what you said about how the tools are really helping you, like, narrow down, like, the views of, like, what is most important for you in that moment, and it's doing a little bit of that work for you. I think the couple of tools and apps that I actually did want to share are kind of similar. +One MacOS app I really like is called Rectangle for windows management, which is really crucial for me because I don't enjoy like, swiping and tabbing between applications. I would much prefer just seeing, usually, just two things. I try to keep my screen limited to two different windows at once because once it gets more than that, I'm already just, like, overwhelmed [laughs]. +And as I'm trying to focus a little bit more on just having, like, one thing be the focus of my attention at a time, Rectangle has been really nice in just really quickly being able to do my windows resizing. So, I usually have, like, either things split between my screen half and half. Like, right now, I have your face on my screen as we record this podcast, and then my notes editing software for taking notes about what we talk about. +During my development workflow, it's usually, you know, just my editor, my terminal, and then maybe my browser ends up being, like, the thing that I tab into. But I'm able to just, like, set that all up, and as I need those windows to change depending on what my focus has been shifted to, to kind of make more space for whatever I'm reading, or looking at, or processing visually. The keyboard shortcuts that Rectangle...that I have now, you know, ingrained into my fingers [laughs] has been really helpful. It's like, I'm not fussing with just, like, too many things open. +JOËL: I have yet to, like, dive into a window manager. I'm still in the clunky world of CMD tabbing. But maybe I should give that a try. +STEPHANIE: For me, it has helped even just, like, identify the things that I need to give more space to on my screen and aggressively, like, cut everything else [laughs]. So, that's a really great MacOS app. +And then, the other one is actually kind of a similar vein. It's called Meeter, M-E-E-T-E-R. And it has been really helpful for managing my meetings, especially my video call meetings where the video call software that's being used for the meeting may be variable. And also, when I have multiple email addresses that meetings are being sent to, you're able to sign into all of your calendar accounts. And it provides a really nice view of all of your meetings. +It has a really, like, minimal, I guess, design in your toolbar, where it shows you how many minutes until your next meeting. And from that toolbar button, you can click to go to the video conferencing software directly for whatever meeting is up next. And you don't have to, you know, scramble to open Google Meet, or Zoom, or Webex, or whatever it is. And that's [chuckles] been nice, again, just kind of, like, cutting down on the amount of stuff that I need to remember and shift through to get to my destination. +JOËL: I think I'm hearing kind of two themes emerge out of some of the things that we've shared. And I'd like to maybe explore them a little bit; one is the power of keyboard shortcuts. And I think that's maybe what a lot of us think of when we think of productivity apps, at least developers, right? We love keyboard shortcuts. +And then, secondly, I think I'm hearing automation, right? So, you don't have to go through and, like, find that email or calendar link to find the Zoom link or whatever. It shows up in your toolbar. So, maybe we can dig into a little bit of the idea of keyboard shortcuts. Are you a person who like customizes a lot of keyboard shortcuts? And is that a part of your kind of productivity setup? +STEPHANIE: Well, a while ago, we had talked about not keyboard shortcuts in the context of productivity, but I think I had mentioned that I was trying to use my mouse less [chuckles] because I was getting a little bit of wrist pain. And I think that actually has rolled into a little bit of, you know, just, like, more efficient navigation on my computer. +I think my keyboard shortcut usage is mostly around window management, like I mentioned. I do feel like I have, like, a medium amount of efficiency in my editor. Sometimes, when I'm pairing with other people who use Vim, I'm, like, shook by how fast they're moving. And I have figured out what works for me in VS Code, and I don't think I need to get any faster. You know, I've just accepted that [laughs]. +In fact, it's almost, like, the amount of speed and friction that I have, in my experience, is actually a little more beneficial for the speed that my mind works [laughs]. It kind of helps me slow down when I need to think about what I'm doing as opposed to just, like, being able to, like, do anything at my fingertips, and kind of my brain is just not able to think that fast. +And then navigating Slack, which is where I also spend a lot of my time on my computer. Now, using Slack with my keyboard shortcuts has been really helpful because, again, I'm not, like, mindlessly browsing or clicking around. I'm just looking at my unread messages. One non-keyboard shortcut I really like with Slack is Command + K, which is the jump-to feature. And so, I'm using that to go to a specific channel that I know I'm looking for or my own personal DMs, where I keep a lot of notes as well. And, honestly, I think that's, like, the extent of my keyboard shortcut usage. I'm curious what your setup is in regards to that, though. +JOËL: I think I'm similar to you in that I have not kind of maxed out the productivity around keyboard shortcuts. You'd mentioned the jump to in Slack. Several pieces of software have something kind of like that. It might be some sort of omnibar, or a command palette, or something like that, where you really just need to know...CMD + K, or CMD + P, CTRL + P are common ones. Then you can sort of, like, type a few characters to just describe the thing you want to do, or a search you want to make, or something like that. +Just knowing that one keyboard shortcut for your one piece of software gets you, I don't know, 80% of the productivity that you want. It's kind of amazing. I love the idea of an omnibar. +STEPHANIE: Yeah, I hadn't heard of omnibar as a phrase before, but that feels very accurate. I like that a lot, too, where it's, like, oftentimes, I don't do whatever particular thing enough necessarily for it to justify a keyboard shortcut, for me at least. I'm still able to be fast enough to get to, like I said, that final destination or the action that I want to take with a more universal shortcut like that. +JOËL: In my editor...so I use Vim, and I got used to Vim's keyboard-based navigation. And that is something that I deeply appreciate, maybe not so much for speed but being able to almost kind of feel one with the machine. And the cursor moves around, and I don't have to, like, think about moving it. It's really a magical sort of feeling. And it's become so much muscle memory now that I can just sort of...the cursor jumps around, things change out. And I'm not, like, constantly thinking about it to the point where now, if I'm in any other editor, I really want to get those shortcuts or, I guess, maybe not shortcuts but a Vim-style navigation, keyboard-based navigation. +STEPHANIE: Yeah, it sounds like it's not so much the time savings but the power that you have or the control that you have over your tools. +JOËL: Yes. And I think, again, the idea of focus. Navigation has stopped becoming a thing where I have to actively think about it. And I feel like I really do just sort of think my fingers are on the keyboard. I'm not having to, like, do a physical motion where I switch my hands. Like, I'm typing, and I'm writing code, then I have to switch my hand away to a mouse to shift around or, like, move my hand off the home row to, like, find the arrow keys and, like, move around. I just kind of think, and the cursor jumps up. It's great. +Maybe I'd be the same if I'd put a lot of time into getting really good at, you know, maybe arrow-based navigation. I still think the mouse you have to move your hand off. It breaks just in the tiniest little way the flow. So, for me, I really appreciate being fully keyboard-based when I'm writing code. +STEPHANIE: Right. Being one with the keyboard. As you were talking about that, I very viscerally felt, you know, when you encounter a new piece of technology, and you're trying to navigate it for the first time, and you're like, wow, like, that takes so much mental overhead that it's, you know, just completely disruptive to the goal that you're trying to achieve with the software itself. +JOËL: Yeah, it is a steep learning curve. +So, we've talked about custom keyboard shortcuts in the editor. But it's common for people to augment their editor with plugins, maybe even some kind of, like, snippet manager to maybe expand snippets or to paste common pieces in. Is that something that you've done in your editor setup? I think you said you use VS Code as your sort of daily editor. +STEPHANIE: Yeah, that's right. I actually think I almost forgot about some of my little bits of automation because they are just so spelled for me [laughs] that I don't have to think about them. But you prompting me just now reminded me that there are a few that I'd like to shut out. +Snippets-wise, I mostly use them for when I'm writing tests and just having the it blocks or the context blocks expand out for me so I don't have to do any of that typing of the setup there. And since I do use a terminal outside of my editor...I know that some people really like kind of having that integrated and being able to run tests even faster without having to switch to a different application, but I like having them separate. +There is a really great plugin called Go to Spec where you can be in any, you know, application code file, and it will pull up the spec file for you. I've been really enjoying that, and that is what helps my test writing be a little more automated, even though I'm having it in separate applications. +JOËL: That is really useful. So, as a Vim user, I also have a plugin that does something similar, where I can switch to what's considered the alternate for a particular file, which is typically the spec, or if I'm in the spec, it'll switch to the source file that the spec is testing. +STEPHANIE: And then, I do have one really silly one, which is that I got so sick and tired of not remembering how to, you know, type the symbols for string interpolation in Ruby that has also become a snippet where the hash key and the [inaudible 28:48] brackets can [laughs] populate it for me. +JOËL: I love it. +So, Stephanie, I'd like to go back to something you were talking about earlier in the show. When you were sharing about what was new in your world and, you mentioned that you subscribe to the Substack and that you subscribe to, actually, a lot of newsletters, and you said something that really caught my attention. You were saying that you don't want these all cluttering up your email inbox. And instead, you send all of these to an RSS reader application. What kind of application do you like to use? +STEPHANIE: I use Feedbin for this. And I actually think that this was recommended by Chris Toomey back in the day on a previous Bike Shed episode before you and I hosted the show. But that has been really awesome. It has a just, like, randomly generated email address you can use when you sign up for newsletters. You use that instead. +And I really like having that distinction because I honestly treat my email inbox as a bit of a to-do list, where I am archiving or deleting a lot of stuff. And then the things that remain in my inbox are things that I need to either respond to, or do, or get back to in some way. And then yeah, when I've completed it, then that's when I archive or delete. +But now that we do have all this great content back in email form, I needed a separate space for that, where I similarly kind of treat it as, like, a to-read list. And yeah, like, I look at my unreads in the newsletter RSS reader that I'm using and go through that when I'm in a blog-reading kind of mood. +JOËL: I really like that separation because I'm kind of like you. I treat my inbox as a to-do list. And it's hard to have newsletters come in and, like, I'm not ready to read them. But I don't want them in my to-do, or, like, they'll just kind of sit there and get mixed in and maybe, like, filtered down to the bottom. So, having that explicit separation to say, hey, here's the place I go to when I am in a reading mood, then I can read things. +I think there's also I've sort of trained myself to only check my email during certain times. So, for example, I will not check my work email outside of working hours. But if I'm on the subway going somewhere and I've got some time where I could do some reading, it would probably be a good thing to be going through some kind of newsletter or something like that. So, I either have to remember to go back to it, or what I tend to do is just scroll Twitter and hope that someone has shared that link, and then I read it there, which is not a particularly effective way of doing things. So, I might try the RSS feed reader tool. What was it called? +STEPHANIE: Feedbin. +JOËL: Feedbin. All right, I might try to get into that. +STEPHANIE: Yeah, I look forward to hearing if that ends up working for you because I agree, having the two separate spaces has been really helpful because I don't want to get distracted by my email/to-do list inbox if I'm just wanting to do a bit of reading, enjoy some content. +So, one more theme around productivity that I don't think we've quite mentioned yet, but maybe we've talked a little bit around, is the idea that it's, at least for me, it's a product of time and energy. So, even if you have all the time in the world, you know, you can just stare into space or, like, stare at a line of code and not get [laughs] anything done. +JOËL: I know the feeling. +STEPHANIE: Right? I am kind of curious how or if you have any techniques for managing that aspect. When your focus is low like, how can you kind of get that back so that you can get back to doing your tasks or getting what you need to do done? +JOËL: If I have the time, taking a break is a really powerful thing, particularly taking a break and doing something physical. So, if I can go outside and take a walk around the block, that's really helpful. And if I need a shorter thing that can be done in, like, five minutes or something, I have a pull-up bar set up in my place. So, I'll just go up and do a few sets there and get a little bit of the heart rate slightly up, do a little bit of blood pumping. And that sometimes can help reset a little bit. +STEPHANIE: Nice. Yes, I'm all for doing something else [chuckles]. Even when you know that this is a priority or is kind of urgent or whatever, but you just can't get yourself to do it, I've found that asking myself the question, "What would make this task easier for me right now?" has been helpful during those moments. And, for me, that might be grabbing a friend, like, maybe I'm blocked because I'm really just unmotivated. But having someone along can kind of inject some of that energy for me. +And then, there's a really great blog post by a woman named Mandy Brown. It's called Energy Makes Time. And she talks about how doing the things that fill our cup, actually, you know, even though it seems like how could we possibly have time to be creative, or, like you said, maybe do something physical, those seem, like, lower on the priority list. +But when you kind of get to the point where you just feel so overwhelmed and can't do anything else, and you just go do those things that you know feel good for you, you kind of come back with a renewed perspective on your to-do list. And you can see, like, what things actually aren't that critical and can be taken off. Or you just find that you have the capacity or the energy to get the things that you are really dreading out of the way. +So, that has been really helpful when I just am feeling blocked. Instead of, like, feeling bad about how unproductive [chuckles] I'm being, I take that as a sign of an opportunity to do something else that might set me up for success later. +JOËL: Yeah. I think oftentimes, it's easy to think of productivity in terms of, like, how can I maybe eliminate some tasks that are not high value through clever automation, or keyboard shortcuts, or things like that? But oftentimes, it can be more about just sort of managing your focus, managing your energy. And by doing that, you might have a much higher impact on both how productive you feel—because that's an important thing as well, in terms of motivation—and, you know, how productive you actually are at getting things done. +STEPHANIE: Right. At least for me, like, not all TDM is bad and needs to be automated away, but, like, my ability to, like, handle it in the moment. Whereas yeah, sometimes maybe I've just run the same few lines that should be just a script [chuckles], that should just be, you know, one command, enough times that I'm like, oh, like, I can't even do this anymore because of just, like, other things going on. But other times, like, it's really not a big deal for me to just, you know, run a few extra commands. And, like, that is perfectly fine. +JOËL: I love writing a good Vim macro. Yeah. So, it's important to think beyond just the fun tools and the code that we can write. Kind of think a little bit more at that energy and that mental level. +That said, there are a ton of great tools out there. We've named-dropped a bunch of them in this episode. For our listeners who are wondering or who weren't, like, necessarily taking notes, we've linked all of them in the show notes: bikeshed.fm. You can find them there. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeee!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie is engrossed in Kent Beck's Substack newsletter, which she appreciates for its "working thoughts" format. Unlike traditional media that undergo rigorous editing, Kent's content is more of a work-in-progress, focusing on thought processes and evolving ideas. Joël has been putting a lot of thought into various tools and techniques and realized that they all fall under one umbrella term: analysis.

+ +

From there, Stephanie and Joël discuss all the productivity tricks they like to use in their daily workflows. Do you have some keyboard shortcuts you like? Are you an Alfred wizard? What are some tools or mindsets around productivity that make YOUR life better?

+ +
+ + + +

Transcript:

+ +

AD:

+ +

Ruby developers, The Rocky Mountain Ruby Conference returns to Boulder, Colorado, on October 5th and 6th. Join us for two days of insightful talks from experienced Ruby developers and plenty of opportunities to connect with your Ruby community.

+ +

But that's not all. Nestled on the edge of the breathtaking Rocky Mountains, Boulder is a haven for outdoor lovers of all stripes. Take a break from coding. Come learn and enjoy at the conference and explore the charm of Downtown Boulder: eclectic shops, first-class restaurants and bars, and incredible street art everywhere. Immerse yourself in the vibrant culture and the many microbrew pubs that Boulder has to offer.

+ +

Grab your tickets now at rockymtnruby.dev and be a part of the 2023 Rocky Mountain Ruby Conference. That's rockymtnruby.dev, October 5th and 6th in Boulder. See you there.

+ +

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, I have a new piece of content that I'm consuming lately. That is Kent Beck's Substack [chuckles], Kent Beck of Agile Manifesto and Extreme Programming notoriety. I have been really enjoying this trend of independent content creation in the newsletter format lately, and I subscribe to a lot of newsletters for things outside of work as well. I've been using an RSS feed to like, keep track of all of the dispatches I'm following in that way so that it also kind of keeps out of my inbox. And it's purely just for when I'm in an internet-reading kind of mood.

+ +

But I subscribed to Kent's Substack. Most of his content is behind a subscription. And I've been really enjoying it because he treats it as a place for a lot of his working thoughts, kind of a space that he uses to explore topics that could be whole books. But he is still in the phase of kind of, like, thinking them through and, like, integrating, you know, different things he's learning, and acknowledging that, like, yeah, like, not all of these ideas are fully fleshed, but they are still worth publishing for people who might be interested in kind of his thought process or where his head is at.

+ +

And I think that is really cool and very different from just, like, other types of content I consume, where there has been, like, a lot of, especially more traditional media, where there has been, like, more editing involved and a lot of time and effort to reach a final product. And I'm curious about this, like I mentioned, trend towards a little less polished and people just publishing things as they're working through them and acknowledging that the way they're thinking about things can change over time.

+ +

JOËL: It sounds like this is kind of halfway between a book which has gone through a lot of editing and, you know, a tweet thread, which is pure stream of consciousness.

+ +

STEPHANIE: Yeah, that's a really great insight, actually. And I think that might be my sweet spot in terms of things I enjoy consuming or reading because I like that room for change and that there is a bit of a, you know, community aspect to Substack where you can comment on posts. But, at least in my experience, has seemed, like, relatively healthy because it is, you know, you're kind of with a community of people who are at least invested or willing to pay [chuckles] for the content. So, there is some amount of good faith involved.

+ +

His newsletter title itself it's called "Tidy First?" And so, that almost implies that it's, like, something he's still exploring or experimenting with, which I think is really cool. It's not like a I have discovered, like, the perfect way to do things, and, you know, you must always tidy first before you do your software development. He's kind of in the position of, this is what I think works, and this is my space for continuing to refine this idea.

+ +

JOËL: I'm curious: are there any sort of articles that you've read or just thoughts in general that you've seen from Kent that are particularly impactful or memorable to you?

+ +

STEPHANIE: Yeah. One I read today during my investment time is called Accountability in Software Development. And it was a very interesting take on the idea of accountability, not necessarily, like, when it's forced by others or external forces like a manager or, you know, your organization, but when it comes from yourself. And he describes it as a way to feel comfortable and confident in the work that he's doing and also building trust in himself and in his work but also in his teams.

+ +

By being transparent and literally accounting for the things that he's doing and sharing them, communicating them publicly, that almost ends up diminishing any kind of, like, distrust, or shame, or any of those weird kind of squishy things that can happen when you hide those things or, like, hide what you're doing. It becomes a way to foster the good parts of working with other people but not in a necessarily like, resentful way or in a hierarchical way. I was really interested in the idea of accountability, ultimately, like, for yourself, and then that ends up just propagating to the team.

+ +

JOËL: That's a really interesting topic because I think it sort of sits at the intersection of the personal and the technical.

+ +

STEPHANIE: Yeah, absolutely. He mentions more technical strategies or tasks that kind of do the same thing. You know, he mentions test-driven development, as well as, like, a way of holding yourself accountable to writing software that, you know, doesn't have bugs in it. So, I think that it can be applied to, you know, exactly both of those, like, interpersonal stuff and also technical aspects too, anyway, that's what's new in my world. Joël, what about you?

+ +

JOËL: So, this year, I've been putting a lot of thought into a variety of tools and processes. And I think I've come to the realization that they all really fall under one kind of umbrella term, and that would be analysis. It's a common step in some definitions of the traditional software development lifecycle. And it's where you try to after you've kind of gathered the requirements, try to break them down and understand what exactly that means from a technical perspective, what needs to happen. And so, a lot of the things that have been really fascinating to me this year have been different techniques that I can use to become better at that sort of phase.

+ +

STEPHANIE: Wow. That's very powerful, I think. And honestly, the first thing that comes to mind is, how do you make time for it?

+ +

JOËL: I think we all do it to a certain extent. You know, you pick up a ticket, and there is a prose description of some work to be done, hopefully not telling you directly, like, just go make a change to this class, but here's a business problem to be solved. And then you have to sort of figure out how to break it down. So, this can be as simple as, oh, what objects, what classes do I need to introduce for this change? But it might be more subtle in terms of thinking, okay, well, what are the edge cases I need to think about? Where are things that could fail, and how am I going to handle failure?

+ +

So, there's a variety of techniques that you can use to get better at all of these. You can use them kind of at the micro level when thinking about just a ticket. You can use them when working on a larger epic, a larger initiative, a whole project because I think analysis fits into kind of all of these levels. And so, I think those are the techniques that have been most exciting to me this year and that have really connected.

+ +

STEPHANIE: That is very exciting. It's triggering a lot of thoughts for me about how I incorporate analysis into my work and how that has actually evolved; where I think before, earlier in my career, I assumed that the analysis had been done by someone else who knew better than me or who knew more than me. And that by the time that you know, a piece of work kind of landed in my lap, I was like, okay, well, I just want to know what to do, right? Like, I want someone else to tell me what to do [laughs]. But now I think I have taken it upon myself to do more of that and, like, have realized that it's part of my role.

+ +

And sometimes it will now be kind of a flag or, like, a signal to me when that hasn't been done. And I can tell when I receive a ticket, and it's, like, maybe missing the business problem or doesn't have enough information. And determining whether that is information that I need to go and find out, or if there's someone else who I can work together with to do that analysis with, or having a better understanding of, like, what is within my realm of analysis to do, and what I need to encourage other people to do analysis for before the work is ready for me.

+ +

JOËL: I think there is an interesting distinction between more traditional requirements gathering and analysis, where traditional requirements gathering is getting all that business problem information from product people, from customers, things like that. The analysis step is often a little bit more about breaking down a business problem into, like, what are the technical ramifications of that?

+ +

But there can be a little of a synergy there where sometimes, once you start exploring the technical side of it, it might bring up a lot of edge cases that have impacts on the product side, on the business side. And then you have to go back to the businesspeople and say, "Hey, we only talked about sort of the happy path. What happens if payment is declined? What do we want to do there?" And now we're back in sort of that requirements gathering phase a little bit more rather than purely analysis.

+ +

But it can come out of an analysis phase where you've done maybe some state machine diagramming to try to better understand how things flow from one phase to another. Or maybe you were building out a truth table for some complex logic and realized, wait a minute, there's an edge case I didn't handle. It's not a strictly linear process. The two kind of feed into each other and, honestly, into the implementation side as well.

+ +

STEPHANIE: Yeah, I'm with you there. I'm thinking about a piece of work that I've been working on, where we were thinking of doing a database migration and adding some new columns to a table. But the more I dug into it, the more I realized that that was the first idea or the immediate idea that came from a need that I had limited information about. And what was nice was I was able to sit on it for a little bit, get some input from others. And I realized that there were all of these things that I couldn't answer yet.

+ +

And someone, I think literally asked in a code review if you've already done this analysis, between knowing that these columns will be the kind of extent of what you need versus, you know, will the data end up needing more columns? And should the data model be a little more flexible to that potential change? And they said, "If you had already done this analysis, then, like, otherwise, it looks good to me." And I was like, "Oh, I didn't." [laughs]

+ +

And that encouraged me to go back to some cross-functional members of the team and ask more questions. And that has taken more time. That was another challenge that I had to encounter was saying like, "Yeah, we started this, and we made some progress. But actually, we need to revisit a few things, like a few parts of the premise, before continuing on."

+ +

JOËL: Are there any techniques or approaches that you particularly enjoy when it comes to doing an analysis or that maybe are go-to's for you?

+ +

STEPHANIE: Reminding myself to revisit my assumptions [laughs], or at least even starting by being really clear about what I'm assuming, right? Because I think that has to happen first before you can even revisit them is having an awareness of what assumptions you're making. And I actually think this is where collaboration has been really helpful, where I've been working on this task with another developer on my team. And when we've been talking about it, I found myself saying, "Oh, I'm assuming this," right? Or, like, I'm assuming that the stakeholder knows what they need [laughs]. And that's why we're going to do it this way, where we were kind of given the pieces of data that we should be persisting.

+ +

And the more that we had that conversation, the more I realized, like, actually, like, I'm not convinced that they have that full picture of, like, what they need in the future. And because we're making this decision now, like, we are turning, you know, literally from, like, the abstract into, like, a concrete change [chuckles] in the database, now seems like...now that we're faced with that decision, it seems like a good time to revisit the assumption that I was making.

+ +

And that has proved helpful in making ultimately, like, a more informed decision about, like, which way to go technically. But I personally have found a lot of value in verbally processing it with someone else. It's a lot harder for me to identify them, I think, when I'm in my own head.

+ +

JOËL: That's really interesting that you keyed in on the idea of assumptions. I typically think of assumptions being, like, so important mostly in debugging rather than analysis. In fact, I wrote a whole blog post about why listing your assumptions is so important as part of your debugging process.

+ +

Now, like, my mind is spinning a little bit. I'm like, oh, I wonder if I could use some of those, like, debugging techniques as part of more of my analysis step. And could that make me better? So, I think you've put me on a whole, like, thought track of, like, oh, how many of these debugging techniques can I use to make my analysis better? So, that's really cool.

+ +

STEPHANIE: Yeah, and vice versa. So, a few minutes ago, I'd asked you how you make time for that analysis. Because I was thinking that, you know, in my day-to-day work, I'm juggling so many things. I often find myself running out of time and not able to do all of it. And that, I think, leads us really well into our topic for this episode, which is productivity tricks and ways that we make the most use out of our limited time.

+ +

JOËL: I think I may have a maybe a bit of a controversial opinion on productivity tricks. I feel like a lot of productivity tricks don't actually make me that much faster. Like, maybe I save a couple of minutes a day, maybe 5 or 10 a day with productivity tricks. And, sure, that adds up over the course of a year. But there are other things I could do in terms of, like, maybe better habits, better managing of my schedule that probably have a much more significant impact.

+ +

Where I think they are incredibly valuable, though, is not directly making me better with my time management but managing my focus, allowing me to kind of keep in the flow and get things done without getting sidetracked. Or just kind of giving me the things that I need in the moment that I need them so that I'm not getting on to a subtask that I don't really need to be doing.

+ +

STEPHANIE: Yeah. I really like that reframing of what helps you focus because as I was brainstorming ways that I stay on track for my work, I think I ended up discovering a similar theme where it wasn't so much, like, little snippets and tools for me, as opposed to how I structure all of the noise, I guess, in my day-to-day work and being able to see what it is that I need to care about the most right now.

+ +

JOËL: I think one of the things that I've tried to do for myself is to make it easy to have access to the information and the tools that I need. Probably one of the most useful bits of that is a combination of the documentation viewer Dash and the...I'm not sure what it would be called– launcher, productivity manager tool for Mac. Alfred, with a CMD + Space, it brings up this bar I can type into. And then you can trigger all sorts of things from there.

+ +

And so I can type the name of a language or some kind of keyword that I have set up and the name of a method. And then, all of a sudden, it'll show me everything like, you know, top five results. And I can hit Enter, and it will bring up the documentation for that.

+ +

So, if I want to say, oh yeah, what is the order of the arguments for Enumerable's inject method (which I constantly forget)? You know, it's a few keyboard shortcuts, you know, CMD + Space Ruby Enumerable inject. It's fuzzy finding, so I probably don't even need to type all of that. Hit Enter, and I have the documentation right in front of me. So, that makes it so that I can get access to that with very little amount of context shifting.

+ +

STEPHANIE: Yeah. I like what you said about how the tools are really helping you, like, narrow down, like, the views of, like, what is most important for you in that moment, and it's doing a little bit of that work for you. I think the couple of tools and apps that I actually did want to share are kind of similar.

+ +

One MacOS app I really like is called Rectangle for windows management, which is really crucial for me because I don't enjoy like, swiping and tabbing between applications. I would much prefer just seeing, usually, just two things. I try to keep my screen limited to two different windows at once because once it gets more than that, I'm already just, like, overwhelmed [laughs].

+ +

And as I'm trying to focus a little bit more on just having, like, one thing be the focus of my attention at a time, Rectangle has been really nice in just really quickly being able to do my windows resizing. So, I usually have, like, either things split between my screen half and half. Like, right now, I have your face on my screen as we record this podcast, and then my notes editing software for taking notes about what we talk about.

+ +

During my development workflow, it's usually, you know, just my editor, my terminal, and then maybe my browser ends up being, like, the thing that I tab into. But I'm able to just, like, set that all up, and as I need those windows to change depending on what my focus has been shifted to, to kind of make more space for whatever I'm reading, or looking at, or processing visually. The keyboard shortcuts that Rectangle...that I have now, you know, ingrained into my fingers [laughs] has been really helpful. It's like, I'm not fussing with just, like, too many things open.

+ +

JOËL: I have yet to, like, dive into a window manager. I'm still in the clunky world of CMD tabbing. But maybe I should give that a try.

+ +

STEPHANIE: For me, it has helped even just, like, identify the things that I need to give more space to on my screen and aggressively, like, cut everything else [laughs]. So, that's a really great MacOS app.

+ +

And then, the other one is actually kind of a similar vein. It's called Meeter, M-E-E-T-E-R. And it has been really helpful for managing my meetings, especially my video call meetings where the video call software that's being used for the meeting may be variable. And also, when I have multiple email addresses that meetings are being sent to, you're able to sign into all of your calendar accounts. And it provides a really nice view of all of your meetings.

+ +

It has a really, like, minimal, I guess, design in your toolbar, where it shows you how many minutes until your next meeting. And from that toolbar button, you can click to go to the video conferencing software directly for whatever meeting is up next. And you don't have to, you know, scramble to open Google Meet, or Zoom, or Webex, or whatever it is. And that's [chuckles] been nice, again, just kind of, like, cutting down on the amount of stuff that I need to remember and shift through to get to my destination.

+ +

JOËL: I think I'm hearing kind of two themes emerge out of some of the things that we've shared. And I'd like to maybe explore them a little bit; one is the power of keyboard shortcuts. And I think that's maybe what a lot of us think of when we think of productivity apps, at least developers, right? We love keyboard shortcuts.

+ +

And then, secondly, I think I'm hearing automation, right? So, you don't have to go through and, like, find that email or calendar link to find the Zoom link or whatever. It shows up in your toolbar. So, maybe we can dig into a little bit of the idea of keyboard shortcuts. Are you a person who like customizes a lot of keyboard shortcuts? And is that a part of your kind of productivity setup?

+ +

STEPHANIE: Well, a while ago, we had talked about not keyboard shortcuts in the context of productivity, but I think I had mentioned that I was trying to use my mouse less [chuckles] because I was getting a little bit of wrist pain. And I think that actually has rolled into a little bit of, you know, just, like, more efficient navigation on my computer.

+ +

I think my keyboard shortcut usage is mostly around window management, like I mentioned. I do feel like I have, like, a medium amount of efficiency in my editor. Sometimes, when I'm pairing with other people who use Vim, I'm, like, shook by how fast they're moving. And I have figured out what works for me in VS Code, and I don't think I need to get any faster. You know, I've just accepted that [laughs].

+ +

In fact, it's almost, like, the amount of speed and friction that I have, in my experience, is actually a little more beneficial for the speed that my mind works [laughs]. It kind of helps me slow down when I need to think about what I'm doing as opposed to just, like, being able to, like, do anything at my fingertips, and kind of my brain is just not able to think that fast.

+ +

And then navigating Slack, which is where I also spend a lot of my time on my computer. Now, using Slack with my keyboard shortcuts has been really helpful because, again, I'm not, like, mindlessly browsing or clicking around. I'm just looking at my unread messages. One non-keyboard shortcut I really like with Slack is Command + K, which is the jump-to feature. And so, I'm using that to go to a specific channel that I know I'm looking for or my own personal DMs, where I keep a lot of notes as well. And, honestly, I think that's, like, the extent of my keyboard shortcut usage. I'm curious what your setup is in regards to that, though.

+ +

JOËL: I think I'm similar to you in that I have not kind of maxed out the productivity around keyboard shortcuts. You'd mentioned the jump to in Slack. Several pieces of software have something kind of like that. It might be some sort of omnibar, or a command palette, or something like that, where you really just need to know...CMD + K, or CMD + P, CTRL + P are common ones. Then you can sort of, like, type a few characters to just describe the thing you want to do, or a search you want to make, or something like that.

+ +

Just knowing that one keyboard shortcut for your one piece of software gets you, I don't know, 80% of the productivity that you want. It's kind of amazing. I love the idea of an omnibar.

+ +

STEPHANIE: Yeah, I hadn't heard of omnibar as a phrase before, but that feels very accurate. I like that a lot, too, where it's, like, oftentimes, I don't do whatever particular thing enough necessarily for it to justify a keyboard shortcut, for me at least. I'm still able to be fast enough to get to, like I said, that final destination or the action that I want to take with a more universal shortcut like that.

+ +

JOËL: In my editor...so I use Vim, and I got used to Vim's keyboard-based navigation. And that is something that I deeply appreciate, maybe not so much for speed but being able to almost kind of feel one with the machine. And the cursor moves around, and I don't have to, like, think about moving it. It's really a magical sort of feeling. And it's become so much muscle memory now that I can just sort of...the cursor jumps around, things change out. And I'm not, like, constantly thinking about it to the point where now, if I'm in any other editor, I really want to get those shortcuts or, I guess, maybe not shortcuts but a Vim-style navigation, keyboard-based navigation.

+ +

STEPHANIE: Yeah, it sounds like it's not so much the time savings but the power that you have or the control that you have over your tools.

+ +

JOËL: Yes. And I think, again, the idea of focus. Navigation has stopped becoming a thing where I have to actively think about it. And I feel like I really do just sort of think my fingers are on the keyboard. I'm not having to, like, do a physical motion where I switch my hands. Like, I'm typing, and I'm writing code, then I have to switch my hand away to a mouse to shift around or, like, move my hand off the home row to, like, find the arrow keys and, like, move around. I just kind of think, and the cursor jumps up. It's great.

+ +

Maybe I'd be the same if I'd put a lot of time into getting really good at, you know, maybe arrow-based navigation. I still think the mouse you have to move your hand off. It breaks just in the tiniest little way the flow. So, for me, I really appreciate being fully keyboard-based when I'm writing code.

+ +

STEPHANIE: Right. Being one with the keyboard. As you were talking about that, I very viscerally felt, you know, when you encounter a new piece of technology, and you're trying to navigate it for the first time, and you're like, wow, like, that takes so much mental overhead that it's, you know, just completely disruptive to the goal that you're trying to achieve with the software itself.

+ +

JOËL: Yeah, it is a steep learning curve.

+ +

So, we've talked about custom keyboard shortcuts in the editor. But it's common for people to augment their editor with plugins, maybe even some kind of, like, snippet manager to maybe expand snippets or to paste common pieces in. Is that something that you've done in your editor setup? I think you said you use VS Code as your sort of daily editor.

+ +

STEPHANIE: Yeah, that's right. I actually think I almost forgot about some of my little bits of automation because they are just so spelled for me [laughs] that I don't have to think about them. But you prompting me just now reminded me that there are a few that I'd like to shut out.

+ +

Snippets-wise, I mostly use them for when I'm writing tests and just having the it blocks or the context blocks expand out for me so I don't have to do any of that typing of the setup there. And since I do use a terminal outside of my editor...I know that some people really like kind of having that integrated and being able to run tests even faster without having to switch to a different application, but I like having them separate.

+ +

There is a really great plugin called Go to Spec where you can be in any, you know, application code file, and it will pull up the spec file for you. I've been really enjoying that, and that is what helps my test writing be a little more automated, even though I'm having it in separate applications.

+ +

JOËL: That is really useful. So, as a Vim user, I also have a plugin that does something similar, where I can switch to what's considered the alternate for a particular file, which is typically the spec, or if I'm in the spec, it'll switch to the source file that the spec is testing.

+ +

STEPHANIE: And then, I do have one really silly one, which is that I got so sick and tired of not remembering how to, you know, type the symbols for string interpolation in Ruby that has also become a snippet where the hash key and the [inaudible 28:48] brackets can [laughs] populate it for me.

+ +

JOËL: I love it.

+ +

So, Stephanie, I'd like to go back to something you were talking about earlier in the show. When you were sharing about what was new in your world and, you mentioned that you subscribe to the Substack and that you subscribe to, actually, a lot of newsletters, and you said something that really caught my attention. You were saying that you don't want these all cluttering up your email inbox. And instead, you send all of these to an RSS reader application. What kind of application do you like to use?

+ +

STEPHANIE: I use Feedbin for this. And I actually think that this was recommended by Chris Toomey back in the day on a previous Bike Shed episode before you and I hosted the show. But that has been really awesome. It has a just, like, randomly generated email address you can use when you sign up for newsletters. You use that instead.

+ +

And I really like having that distinction because I honestly treat my email inbox as a bit of a to-do list, where I am archiving or deleting a lot of stuff. And then the things that remain in my inbox are things that I need to either respond to, or do, or get back to in some way. And then yeah, when I've completed it, then that's when I archive or delete.

+ +

But now that we do have all this great content back in email form, I needed a separate space for that, where I similarly kind of treat it as, like, a to-read list. And yeah, like, I look at my unreads in the newsletter RSS reader that I'm using and go through that when I'm in a blog-reading kind of mood.

+ +

JOËL: I really like that separation because I'm kind of like you. I treat my inbox as a to-do list. And it's hard to have newsletters come in and, like, I'm not ready to read them. But I don't want them in my to-do, or, like, they'll just kind of sit there and get mixed in and maybe, like, filtered down to the bottom. So, having that explicit separation to say, hey, here's the place I go to when I am in a reading mood, then I can read things.

+ +

I think there's also I've sort of trained myself to only check my email during certain times. So, for example, I will not check my work email outside of working hours. But if I'm on the subway going somewhere and I've got some time where I could do some reading, it would probably be a good thing to be going through some kind of newsletter or something like that. So, I either have to remember to go back to it, or what I tend to do is just scroll Twitter and hope that someone has shared that link, and then I read it there, which is not a particularly effective way of doing things. So, I might try the RSS feed reader tool. What was it called?

+ +

STEPHANIE: Feedbin.

+ +

JOËL: Feedbin. All right, I might try to get into that.

+ +

STEPHANIE: Yeah, I look forward to hearing if that ends up working for you because I agree, having the two separate spaces has been really helpful because I don't want to get distracted by my email/to-do list inbox if I'm just wanting to do a bit of reading, enjoy some content.

+ +

So, one more theme around productivity that I don't think we've quite mentioned yet, but maybe we've talked a little bit around, is the idea that it's, at least for me, it's a product of time and energy. So, even if you have all the time in the world, you know, you can just stare into space or, like, stare at a line of code and not get [laughs] anything done.

+ +

JOËL: I know the feeling.

+ +

STEPHANIE: Right? I am kind of curious how or if you have any techniques for managing that aspect. When your focus is low like, how can you kind of get that back so that you can get back to doing your tasks or getting what you need to do done?

+ +

JOËL: If I have the time, taking a break is a really powerful thing, particularly taking a break and doing something physical. So, if I can go outside and take a walk around the block, that's really helpful. And if I need a shorter thing that can be done in, like, five minutes or something, I have a pull-up bar set up in my place. So, I'll just go up and do a few sets there and get a little bit of the heart rate slightly up, do a little bit of blood pumping. And that sometimes can help reset a little bit.

+ +

STEPHANIE: Nice. Yes, I'm all for doing something else [chuckles]. Even when you know that this is a priority or is kind of urgent or whatever, but you just can't get yourself to do it, I've found that asking myself the question, "What would make this task easier for me right now?" has been helpful during those moments. And, for me, that might be grabbing a friend, like, maybe I'm blocked because I'm really just unmotivated. But having someone along can kind of inject some of that energy for me.

+ +

And then, there's a really great blog post by a woman named Mandy Brown. It's called Energy Makes Time. And she talks about how doing the things that fill our cup, actually, you know, even though it seems like how could we possibly have time to be creative, or, like you said, maybe do something physical, those seem, like, lower on the priority list.

+ +

But when you kind of get to the point where you just feel so overwhelmed and can't do anything else, and you just go do those things that you know feel good for you, you kind of come back with a renewed perspective on your to-do list. And you can see, like, what things actually aren't that critical and can be taken off. Or you just find that you have the capacity or the energy to get the things that you are really dreading out of the way.

+ +

So, that has been really helpful when I just am feeling blocked. Instead of, like, feeling bad about how unproductive [chuckles] I'm being, I take that as a sign of an opportunity to do something else that might set me up for success later.

+ +

JOËL: Yeah. I think oftentimes, it's easy to think of productivity in terms of, like, how can I maybe eliminate some tasks that are not high value through clever automation, or keyboard shortcuts, or things like that? But oftentimes, it can be more about just sort of managing your focus, managing your energy. And by doing that, you might have a much higher impact on both how productive you feel—because that's an important thing as well, in terms of motivation—and, you know, how productive you actually are at getting things done.

+ +

STEPHANIE: Right. At least for me, like, not all TDM is bad and needs to be automated away, but, like, my ability to, like, handle it in the moment. Whereas yeah, sometimes maybe I've just run the same few lines that should be just a script [chuckles], that should just be, you know, one command, enough times that I'm like, oh, like, I can't even do this anymore because of just, like, other things going on. But other times, like, it's really not a big deal for me to just, you know, run a few extra commands. And, like, that is perfectly fine.

+ +

JOËL: I love writing a good Vim macro. Yeah. So, it's important to think beyond just the fun tools and the code that we can write. Kind of think a little bit more at that energy and that mental level.

+ +

That said, there are a ton of great tools out there. We've named-dropped a bunch of them in this episode. For our listeners who are wondering or who weren't, like, necessarily taking notes, we've linked all of them in the show notes: bikeshed.fm. You can find them there.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie is engrossed in Kent Beck's Substack newsletter, which she appreciates for its "working thoughts" format. Unlike traditional media that undergo rigorous editing, Kent's content is more of a work-in-progress, focusing on thought processes and evolving ideas. Joël has been putting a lot of thought into various tools and techniques and realized that they all fall under one umbrella term: analysis.

+ +

From there, Stephanie and Joël discuss all the productivity tricks they like to use in their daily workflows. Do you have some keyboard shortcuts you like? Are you an Alfred wizard? What are some tools or mindsets around productivity that make YOUR life better?

+ +
+ + + +

Transcript:

+ +

AD:

+ +

Ruby developers, The Rocky Mountain Ruby Conference returns to Boulder, Colorado, on October 5th and 6th. Join us for two days of insightful talks from experienced Ruby developers and plenty of opportunities to connect with your Ruby community.

+ +

But that's not all. Nestled on the edge of the breathtaking Rocky Mountains, Boulder is a haven for outdoor lovers of all stripes. Take a break from coding. Come learn and enjoy at the conference and explore the charm of Downtown Boulder: eclectic shops, first-class restaurants and bars, and incredible street art everywhere. Immerse yourself in the vibrant culture and the many microbrew pubs that Boulder has to offer.

+ +

Grab your tickets now at rockymtnruby.dev and be a part of the 2023 Rocky Mountain Ruby Conference. That's rockymtnruby.dev, October 5th and 6th in Boulder. See you there.

+ +

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, I have a new piece of content that I'm consuming lately. That is Kent Beck's Substack [chuckles], Kent Beck of Agile Manifesto and Extreme Programming notoriety. I have been really enjoying this trend of independent content creation in the newsletter format lately, and I subscribe to a lot of newsletters for things outside of work as well. I've been using an RSS feed to like, keep track of all of the dispatches I'm following in that way so that it also kind of keeps out of my inbox. And it's purely just for when I'm in an internet-reading kind of mood.

+ +

But I subscribed to Kent's Substack. Most of his content is behind a subscription. And I've been really enjoying it because he treats it as a place for a lot of his working thoughts, kind of a space that he uses to explore topics that could be whole books. But he is still in the phase of kind of, like, thinking them through and, like, integrating, you know, different things he's learning, and acknowledging that, like, yeah, like, not all of these ideas are fully fleshed, but they are still worth publishing for people who might be interested in kind of his thought process or where his head is at.

+ +

And I think that is really cool and very different from just, like, other types of content I consume, where there has been, like, a lot of, especially more traditional media, where there has been, like, more editing involved and a lot of time and effort to reach a final product. And I'm curious about this, like I mentioned, trend towards a little less polished and people just publishing things as they're working through them and acknowledging that the way they're thinking about things can change over time.

+ +

JOËL: It sounds like this is kind of halfway between a book which has gone through a lot of editing and, you know, a tweet thread, which is pure stream of consciousness.

+ +

STEPHANIE: Yeah, that's a really great insight, actually. And I think that might be my sweet spot in terms of things I enjoy consuming or reading because I like that room for change and that there is a bit of a, you know, community aspect to Substack where you can comment on posts. But, at least in my experience, has seemed, like, relatively healthy because it is, you know, you're kind of with a community of people who are at least invested or willing to pay [chuckles] for the content. So, there is some amount of good faith involved.

+ +

His newsletter title itself it's called "Tidy First?" And so, that almost implies that it's, like, something he's still exploring or experimenting with, which I think is really cool. It's not like a I have discovered, like, the perfect way to do things, and, you know, you must always tidy first before you do your software development. He's kind of in the position of, this is what I think works, and this is my space for continuing to refine this idea.

+ +

JOËL: I'm curious: are there any sort of articles that you've read or just thoughts in general that you've seen from Kent that are particularly impactful or memorable to you?

+ +

STEPHANIE: Yeah. One I read today during my investment time is called Accountability in Software Development. And it was a very interesting take on the idea of accountability, not necessarily, like, when it's forced by others or external forces like a manager or, you know, your organization, but when it comes from yourself. And he describes it as a way to feel comfortable and confident in the work that he's doing and also building trust in himself and in his work but also in his teams.

+ +

By being transparent and literally accounting for the things that he's doing and sharing them, communicating them publicly, that almost ends up diminishing any kind of, like, distrust, or shame, or any of those weird kind of squishy things that can happen when you hide those things or, like, hide what you're doing. It becomes a way to foster the good parts of working with other people but not in a necessarily like, resentful way or in a hierarchical way. I was really interested in the idea of accountability, ultimately, like, for yourself, and then that ends up just propagating to the team.

+ +

JOËL: That's a really interesting topic because I think it sort of sits at the intersection of the personal and the technical.

+ +

STEPHANIE: Yeah, absolutely. He mentions more technical strategies or tasks that kind of do the same thing. You know, he mentions test-driven development, as well as, like, a way of holding yourself accountable to writing software that, you know, doesn't have bugs in it. So, I think that it can be applied to, you know, exactly both of those, like, interpersonal stuff and also technical aspects too, anyway, that's what's new in my world. Joël, what about you?

+ +

JOËL: So, this year, I've been putting a lot of thought into a variety of tools and processes. And I think I've come to the realization that they all really fall under one kind of umbrella term, and that would be analysis. It's a common step in some definitions of the traditional software development lifecycle. And it's where you try to after you've kind of gathered the requirements, try to break them down and understand what exactly that means from a technical perspective, what needs to happen. And so, a lot of the things that have been really fascinating to me this year have been different techniques that I can use to become better at that sort of phase.

+ +

STEPHANIE: Wow. That's very powerful, I think. And honestly, the first thing that comes to mind is, how do you make time for it?

+ +

JOËL: I think we all do it to a certain extent. You know, you pick up a ticket, and there is a prose description of some work to be done, hopefully not telling you directly, like, just go make a change to this class, but here's a business problem to be solved. And then you have to sort of figure out how to break it down. So, this can be as simple as, oh, what objects, what classes do I need to introduce for this change? But it might be more subtle in terms of thinking, okay, well, what are the edge cases I need to think about? Where are things that could fail, and how am I going to handle failure?

+ +

So, there's a variety of techniques that you can use to get better at all of these. You can use them kind of at the micro level when thinking about just a ticket. You can use them when working on a larger epic, a larger initiative, a whole project because I think analysis fits into kind of all of these levels. And so, I think those are the techniques that have been most exciting to me this year and that have really connected.

+ +

STEPHANIE: That is very exciting. It's triggering a lot of thoughts for me about how I incorporate analysis into my work and how that has actually evolved; where I think before, earlier in my career, I assumed that the analysis had been done by someone else who knew better than me or who knew more than me. And that by the time that you know, a piece of work kind of landed in my lap, I was like, okay, well, I just want to know what to do, right? Like, I want someone else to tell me what to do [laughs]. But now I think I have taken it upon myself to do more of that and, like, have realized that it's part of my role.

+ +

And sometimes it will now be kind of a flag or, like, a signal to me when that hasn't been done. And I can tell when I receive a ticket, and it's, like, maybe missing the business problem or doesn't have enough information. And determining whether that is information that I need to go and find out, or if there's someone else who I can work together with to do that analysis with, or having a better understanding of, like, what is within my realm of analysis to do, and what I need to encourage other people to do analysis for before the work is ready for me.

+ +

JOËL: I think there is an interesting distinction between more traditional requirements gathering and analysis, where traditional requirements gathering is getting all that business problem information from product people, from customers, things like that. The analysis step is often a little bit more about breaking down a business problem into, like, what are the technical ramifications of that?

+ +

But there can be a little of a synergy there where sometimes, once you start exploring the technical side of it, it might bring up a lot of edge cases that have impacts on the product side, on the business side. And then you have to go back to the businesspeople and say, "Hey, we only talked about sort of the happy path. What happens if payment is declined? What do we want to do there?" And now we're back in sort of that requirements gathering phase a little bit more rather than purely analysis.

+ +

But it can come out of an analysis phase where you've done maybe some state machine diagramming to try to better understand how things flow from one phase to another. Or maybe you were building out a truth table for some complex logic and realized, wait a minute, there's an edge case I didn't handle. It's not a strictly linear process. The two kind of feed into each other and, honestly, into the implementation side as well.

+ +

STEPHANIE: Yeah, I'm with you there. I'm thinking about a piece of work that I've been working on, where we were thinking of doing a database migration and adding some new columns to a table. But the more I dug into it, the more I realized that that was the first idea or the immediate idea that came from a need that I had limited information about. And what was nice was I was able to sit on it for a little bit, get some input from others. And I realized that there were all of these things that I couldn't answer yet.

+ +

And someone, I think literally asked in a code review if you've already done this analysis, between knowing that these columns will be the kind of extent of what you need versus, you know, will the data end up needing more columns? And should the data model be a little more flexible to that potential change? And they said, "If you had already done this analysis, then, like, otherwise, it looks good to me." And I was like, "Oh, I didn't." [laughs]

+ +

And that encouraged me to go back to some cross-functional members of the team and ask more questions. And that has taken more time. That was another challenge that I had to encounter was saying like, "Yeah, we started this, and we made some progress. But actually, we need to revisit a few things, like a few parts of the premise, before continuing on."

+ +

JOËL: Are there any techniques or approaches that you particularly enjoy when it comes to doing an analysis or that maybe are go-to's for you?

+ +

STEPHANIE: Reminding myself to revisit my assumptions [laughs], or at least even starting by being really clear about what I'm assuming, right? Because I think that has to happen first before you can even revisit them is having an awareness of what assumptions you're making. And I actually think this is where collaboration has been really helpful, where I've been working on this task with another developer on my team. And when we've been talking about it, I found myself saying, "Oh, I'm assuming this," right? Or, like, I'm assuming that the stakeholder knows what they need [laughs]. And that's why we're going to do it this way, where we were kind of given the pieces of data that we should be persisting.

+ +

And the more that we had that conversation, the more I realized, like, actually, like, I'm not convinced that they have that full picture of, like, what they need in the future. And because we're making this decision now, like, we are turning, you know, literally from, like, the abstract into, like, a concrete change [chuckles] in the database, now seems like...now that we're faced with that decision, it seems like a good time to revisit the assumption that I was making.

+ +

And that has proved helpful in making ultimately, like, a more informed decision about, like, which way to go technically. But I personally have found a lot of value in verbally processing it with someone else. It's a lot harder for me to identify them, I think, when I'm in my own head.

+ +

JOËL: That's really interesting that you keyed in on the idea of assumptions. I typically think of assumptions being, like, so important mostly in debugging rather than analysis. In fact, I wrote a whole blog post about why listing your assumptions is so important as part of your debugging process.

+ +

Now, like, my mind is spinning a little bit. I'm like, oh, I wonder if I could use some of those, like, debugging techniques as part of more of my analysis step. And could that make me better? So, I think you've put me on a whole, like, thought track of, like, oh, how many of these debugging techniques can I use to make my analysis better? So, that's really cool.

+ +

STEPHANIE: Yeah, and vice versa. So, a few minutes ago, I'd asked you how you make time for that analysis. Because I was thinking that, you know, in my day-to-day work, I'm juggling so many things. I often find myself running out of time and not able to do all of it. And that, I think, leads us really well into our topic for this episode, which is productivity tricks and ways that we make the most use out of our limited time.

+ +

JOËL: I think I may have a maybe a bit of a controversial opinion on productivity tricks. I feel like a lot of productivity tricks don't actually make me that much faster. Like, maybe I save a couple of minutes a day, maybe 5 or 10 a day with productivity tricks. And, sure, that adds up over the course of a year. But there are other things I could do in terms of, like, maybe better habits, better managing of my schedule that probably have a much more significant impact.

+ +

Where I think they are incredibly valuable, though, is not directly making me better with my time management but managing my focus, allowing me to kind of keep in the flow and get things done without getting sidetracked. Or just kind of giving me the things that I need in the moment that I need them so that I'm not getting on to a subtask that I don't really need to be doing.

+ +

STEPHANIE: Yeah. I really like that reframing of what helps you focus because as I was brainstorming ways that I stay on track for my work, I think I ended up discovering a similar theme where it wasn't so much, like, little snippets and tools for me, as opposed to how I structure all of the noise, I guess, in my day-to-day work and being able to see what it is that I need to care about the most right now.

+ +

JOËL: I think one of the things that I've tried to do for myself is to make it easy to have access to the information and the tools that I need. Probably one of the most useful bits of that is a combination of the documentation viewer Dash and the...I'm not sure what it would be called– launcher, productivity manager tool for Mac. Alfred, with a CMD + Space, it brings up this bar I can type into. And then you can trigger all sorts of things from there.

+ +

And so I can type the name of a language or some kind of keyword that I have set up and the name of a method. And then, all of a sudden, it'll show me everything like, you know, top five results. And I can hit Enter, and it will bring up the documentation for that.

+ +

So, if I want to say, oh yeah, what is the order of the arguments for Enumerable's inject method (which I constantly forget)? You know, it's a few keyboard shortcuts, you know, CMD + Space Ruby Enumerable inject. It's fuzzy finding, so I probably don't even need to type all of that. Hit Enter, and I have the documentation right in front of me. So, that makes it so that I can get access to that with very little amount of context shifting.

+ +

STEPHANIE: Yeah. I like what you said about how the tools are really helping you, like, narrow down, like, the views of, like, what is most important for you in that moment, and it's doing a little bit of that work for you. I think the couple of tools and apps that I actually did want to share are kind of similar.

+ +

One MacOS app I really like is called Rectangle for windows management, which is really crucial for me because I don't enjoy like, swiping and tabbing between applications. I would much prefer just seeing, usually, just two things. I try to keep my screen limited to two different windows at once because once it gets more than that, I'm already just, like, overwhelmed [laughs].

+ +

And as I'm trying to focus a little bit more on just having, like, one thing be the focus of my attention at a time, Rectangle has been really nice in just really quickly being able to do my windows resizing. So, I usually have, like, either things split between my screen half and half. Like, right now, I have your face on my screen as we record this podcast, and then my notes editing software for taking notes about what we talk about.

+ +

During my development workflow, it's usually, you know, just my editor, my terminal, and then maybe my browser ends up being, like, the thing that I tab into. But I'm able to just, like, set that all up, and as I need those windows to change depending on what my focus has been shifted to, to kind of make more space for whatever I'm reading, or looking at, or processing visually. The keyboard shortcuts that Rectangle...that I have now, you know, ingrained into my fingers [laughs] has been really helpful. It's like, I'm not fussing with just, like, too many things open.

+ +

JOËL: I have yet to, like, dive into a window manager. I'm still in the clunky world of CMD tabbing. But maybe I should give that a try.

+ +

STEPHANIE: For me, it has helped even just, like, identify the things that I need to give more space to on my screen and aggressively, like, cut everything else [laughs]. So, that's a really great MacOS app.

+ +

And then, the other one is actually kind of a similar vein. It's called Meeter, M-E-E-T-E-R. And it has been really helpful for managing my meetings, especially my video call meetings where the video call software that's being used for the meeting may be variable. And also, when I have multiple email addresses that meetings are being sent to, you're able to sign into all of your calendar accounts. And it provides a really nice view of all of your meetings.

+ +

It has a really, like, minimal, I guess, design in your toolbar, where it shows you how many minutes until your next meeting. And from that toolbar button, you can click to go to the video conferencing software directly for whatever meeting is up next. And you don't have to, you know, scramble to open Google Meet, or Zoom, or Webex, or whatever it is. And that's [chuckles] been nice, again, just kind of, like, cutting down on the amount of stuff that I need to remember and shift through to get to my destination.

+ +

JOËL: I think I'm hearing kind of two themes emerge out of some of the things that we've shared. And I'd like to maybe explore them a little bit; one is the power of keyboard shortcuts. And I think that's maybe what a lot of us think of when we think of productivity apps, at least developers, right? We love keyboard shortcuts.

+ +

And then, secondly, I think I'm hearing automation, right? So, you don't have to go through and, like, find that email or calendar link to find the Zoom link or whatever. It shows up in your toolbar. So, maybe we can dig into a little bit of the idea of keyboard shortcuts. Are you a person who like customizes a lot of keyboard shortcuts? And is that a part of your kind of productivity setup?

+ +

STEPHANIE: Well, a while ago, we had talked about not keyboard shortcuts in the context of productivity, but I think I had mentioned that I was trying to use my mouse less [chuckles] because I was getting a little bit of wrist pain. And I think that actually has rolled into a little bit of, you know, just, like, more efficient navigation on my computer.

+ +

I think my keyboard shortcut usage is mostly around window management, like I mentioned. I do feel like I have, like, a medium amount of efficiency in my editor. Sometimes, when I'm pairing with other people who use Vim, I'm, like, shook by how fast they're moving. And I have figured out what works for me in VS Code, and I don't think I need to get any faster. You know, I've just accepted that [laughs].

+ +

In fact, it's almost, like, the amount of speed and friction that I have, in my experience, is actually a little more beneficial for the speed that my mind works [laughs]. It kind of helps me slow down when I need to think about what I'm doing as opposed to just, like, being able to, like, do anything at my fingertips, and kind of my brain is just not able to think that fast.

+ +

And then navigating Slack, which is where I also spend a lot of my time on my computer. Now, using Slack with my keyboard shortcuts has been really helpful because, again, I'm not, like, mindlessly browsing or clicking around. I'm just looking at my unread messages. One non-keyboard shortcut I really like with Slack is Command + K, which is the jump-to feature. And so, I'm using that to go to a specific channel that I know I'm looking for or my own personal DMs, where I keep a lot of notes as well. And, honestly, I think that's, like, the extent of my keyboard shortcut usage. I'm curious what your setup is in regards to that, though.

+ +

JOËL: I think I'm similar to you in that I have not kind of maxed out the productivity around keyboard shortcuts. You'd mentioned the jump to in Slack. Several pieces of software have something kind of like that. It might be some sort of omnibar, or a command palette, or something like that, where you really just need to know...CMD + K, or CMD + P, CTRL + P are common ones. Then you can sort of, like, type a few characters to just describe the thing you want to do, or a search you want to make, or something like that.

+ +

Just knowing that one keyboard shortcut for your one piece of software gets you, I don't know, 80% of the productivity that you want. It's kind of amazing. I love the idea of an omnibar.

+ +

STEPHANIE: Yeah, I hadn't heard of omnibar as a phrase before, but that feels very accurate. I like that a lot, too, where it's, like, oftentimes, I don't do whatever particular thing enough necessarily for it to justify a keyboard shortcut, for me at least. I'm still able to be fast enough to get to, like I said, that final destination or the action that I want to take with a more universal shortcut like that.

+ +

JOËL: In my editor...so I use Vim, and I got used to Vim's keyboard-based navigation. And that is something that I deeply appreciate, maybe not so much for speed but being able to almost kind of feel one with the machine. And the cursor moves around, and I don't have to, like, think about moving it. It's really a magical sort of feeling. And it's become so much muscle memory now that I can just sort of...the cursor jumps around, things change out. And I'm not, like, constantly thinking about it to the point where now, if I'm in any other editor, I really want to get those shortcuts or, I guess, maybe not shortcuts but a Vim-style navigation, keyboard-based navigation.

+ +

STEPHANIE: Yeah, it sounds like it's not so much the time savings but the power that you have or the control that you have over your tools.

+ +

JOËL: Yes. And I think, again, the idea of focus. Navigation has stopped becoming a thing where I have to actively think about it. And I feel like I really do just sort of think my fingers are on the keyboard. I'm not having to, like, do a physical motion where I switch my hands. Like, I'm typing, and I'm writing code, then I have to switch my hand away to a mouse to shift around or, like, move my hand off the home row to, like, find the arrow keys and, like, move around. I just kind of think, and the cursor jumps up. It's great.

+ +

Maybe I'd be the same if I'd put a lot of time into getting really good at, you know, maybe arrow-based navigation. I still think the mouse you have to move your hand off. It breaks just in the tiniest little way the flow. So, for me, I really appreciate being fully keyboard-based when I'm writing code.

+ +

STEPHANIE: Right. Being one with the keyboard. As you were talking about that, I very viscerally felt, you know, when you encounter a new piece of technology, and you're trying to navigate it for the first time, and you're like, wow, like, that takes so much mental overhead that it's, you know, just completely disruptive to the goal that you're trying to achieve with the software itself.

+ +

JOËL: Yeah, it is a steep learning curve.

+ +

So, we've talked about custom keyboard shortcuts in the editor. But it's common for people to augment their editor with plugins, maybe even some kind of, like, snippet manager to maybe expand snippets or to paste common pieces in. Is that something that you've done in your editor setup? I think you said you use VS Code as your sort of daily editor.

+ +

STEPHANIE: Yeah, that's right. I actually think I almost forgot about some of my little bits of automation because they are just so spelled for me [laughs] that I don't have to think about them. But you prompting me just now reminded me that there are a few that I'd like to shut out.

+ +

Snippets-wise, I mostly use them for when I'm writing tests and just having the it blocks or the context blocks expand out for me so I don't have to do any of that typing of the setup there. And since I do use a terminal outside of my editor...I know that some people really like kind of having that integrated and being able to run tests even faster without having to switch to a different application, but I like having them separate.

+ +

There is a really great plugin called Go to Spec where you can be in any, you know, application code file, and it will pull up the spec file for you. I've been really enjoying that, and that is what helps my test writing be a little more automated, even though I'm having it in separate applications.

+ +

JOËL: That is really useful. So, as a Vim user, I also have a plugin that does something similar, where I can switch to what's considered the alternate for a particular file, which is typically the spec, or if I'm in the spec, it'll switch to the source file that the spec is testing.

+ +

STEPHANIE: And then, I do have one really silly one, which is that I got so sick and tired of not remembering how to, you know, type the symbols for string interpolation in Ruby that has also become a snippet where the hash key and the [inaudible 28:48] brackets can [laughs] populate it for me.

+ +

JOËL: I love it.

+ +

So, Stephanie, I'd like to go back to something you were talking about earlier in the show. When you were sharing about what was new in your world and, you mentioned that you subscribe to the Substack and that you subscribe to, actually, a lot of newsletters, and you said something that really caught my attention. You were saying that you don't want these all cluttering up your email inbox. And instead, you send all of these to an RSS reader application. What kind of application do you like to use?

+ +

STEPHANIE: I use Feedbin for this. And I actually think that this was recommended by Chris Toomey back in the day on a previous Bike Shed episode before you and I hosted the show. But that has been really awesome. It has a just, like, randomly generated email address you can use when you sign up for newsletters. You use that instead.

+ +

And I really like having that distinction because I honestly treat my email inbox as a bit of a to-do list, where I am archiving or deleting a lot of stuff. And then the things that remain in my inbox are things that I need to either respond to, or do, or get back to in some way. And then yeah, when I've completed it, then that's when I archive or delete.

+ +

But now that we do have all this great content back in email form, I needed a separate space for that, where I similarly kind of treat it as, like, a to-read list. And yeah, like, I look at my unreads in the newsletter RSS reader that I'm using and go through that when I'm in a blog-reading kind of mood.

+ +

JOËL: I really like that separation because I'm kind of like you. I treat my inbox as a to-do list. And it's hard to have newsletters come in and, like, I'm not ready to read them. But I don't want them in my to-do, or, like, they'll just kind of sit there and get mixed in and maybe, like, filtered down to the bottom. So, having that explicit separation to say, hey, here's the place I go to when I am in a reading mood, then I can read things.

+ +

I think there's also I've sort of trained myself to only check my email during certain times. So, for example, I will not check my work email outside of working hours. But if I'm on the subway going somewhere and I've got some time where I could do some reading, it would probably be a good thing to be going through some kind of newsletter or something like that. So, I either have to remember to go back to it, or what I tend to do is just scroll Twitter and hope that someone has shared that link, and then I read it there, which is not a particularly effective way of doing things. So, I might try the RSS feed reader tool. What was it called?

+ +

STEPHANIE: Feedbin.

+ +

JOËL: Feedbin. All right, I might try to get into that.

+ +

STEPHANIE: Yeah, I look forward to hearing if that ends up working for you because I agree, having the two separate spaces has been really helpful because I don't want to get distracted by my email/to-do list inbox if I'm just wanting to do a bit of reading, enjoy some content.

+ +

So, one more theme around productivity that I don't think we've quite mentioned yet, but maybe we've talked a little bit around, is the idea that it's, at least for me, it's a product of time and energy. So, even if you have all the time in the world, you know, you can just stare into space or, like, stare at a line of code and not get [laughs] anything done.

+ +

JOËL: I know the feeling.

+ +

STEPHANIE: Right? I am kind of curious how or if you have any techniques for managing that aspect. When your focus is low like, how can you kind of get that back so that you can get back to doing your tasks or getting what you need to do done?

+ +

JOËL: If I have the time, taking a break is a really powerful thing, particularly taking a break and doing something physical. So, if I can go outside and take a walk around the block, that's really helpful. And if I need a shorter thing that can be done in, like, five minutes or something, I have a pull-up bar set up in my place. So, I'll just go up and do a few sets there and get a little bit of the heart rate slightly up, do a little bit of blood pumping. And that sometimes can help reset a little bit.

+ +

STEPHANIE: Nice. Yes, I'm all for doing something else [chuckles]. Even when you know that this is a priority or is kind of urgent or whatever, but you just can't get yourself to do it, I've found that asking myself the question, "What would make this task easier for me right now?" has been helpful during those moments. And, for me, that might be grabbing a friend, like, maybe I'm blocked because I'm really just unmotivated. But having someone along can kind of inject some of that energy for me.

+ +

And then, there's a really great blog post by a woman named Mandy Brown. It's called Energy Makes Time. And she talks about how doing the things that fill our cup, actually, you know, even though it seems like how could we possibly have time to be creative, or, like you said, maybe do something physical, those seem, like, lower on the priority list.

+ +

But when you kind of get to the point where you just feel so overwhelmed and can't do anything else, and you just go do those things that you know feel good for you, you kind of come back with a renewed perspective on your to-do list. And you can see, like, what things actually aren't that critical and can be taken off. Or you just find that you have the capacity or the energy to get the things that you are really dreading out of the way.

+ +

So, that has been really helpful when I just am feeling blocked. Instead of, like, feeling bad about how unproductive [chuckles] I'm being, I take that as a sign of an opportunity to do something else that might set me up for success later.

+ +

JOËL: Yeah. I think oftentimes, it's easy to think of productivity in terms of, like, how can I maybe eliminate some tasks that are not high value through clever automation, or keyboard shortcuts, or things like that? But oftentimes, it can be more about just sort of managing your focus, managing your energy. And by doing that, you might have a much higher impact on both how productive you feel—because that's an important thing as well, in terms of motivation—and, you know, how productive you actually are at getting things done.

+ +

STEPHANIE: Right. At least for me, like, not all TDM is bad and needs to be automated away, but, like, my ability to, like, handle it in the moment. Whereas yeah, sometimes maybe I've just run the same few lines that should be just a script [chuckles], that should just be, you know, one command, enough times that I'm like, oh, like, I can't even do this anymore because of just, like, other things going on. But other times, like, it's really not a big deal for me to just, you know, run a few extra commands. And, like, that is perfectly fine.

+ +

JOËL: I love writing a good Vim macro. Yeah. So, it's important to think beyond just the fun tools and the code that we can write. Kind of think a little bit more at that energy and that mental level.

+ +

That said, there are a ton of great tools out there. We've named-dropped a bunch of them in this episode. For our listeners who are wondering or who weren't, like, necessarily taking notes, we've linked all of them in the show notes: bikeshed.fm. You can find them there.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MIjdhmV4 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 402: Musings on Mentorship + https://bikeshed.thoughtbot.com/402 + bade29c6-bf96-4528-872e-95400d7bfbad + Tue, 19 Sep 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël describes an old-school object orientation exercise that involves circling nouns in a business problem description. The purpose is determining which nouns could become entities or objects in a system. Stephanie shares she's working from the Hudson Valley in New York as a trial run for potentially relocating there. She enjoys the rail trails for biking and contrasts it with urban biking in Chicago. + +The conversation between Joël and Stephanie revolves around mentorship, both one-on-one and within a group setting. They introduce a new initiative at thoughbot where team members pair up with principal developers for weekly sessions, emphasizing sharing perspectives and experiences. + 37:56 + no + + + Joël describes an old-school object orientation exercise that involves circling nouns in a business problem description. The purpose is determining which nouns could become entities or objects in a system. Stephanie shares she's working from the Hudson Valley in New York as a trial run for potentially relocating there. She enjoys the rail trails for biking and contrasts it with urban biking in Chicago. +The conversation between Joël and Stephanie revolves around mentorship, both one-on-one and within a group setting. They introduce a new initiative at thoughbot where team members pair up with principal developers for weekly sessions, emphasizing sharing perspectives and experiences. +Socratic method (https://tilt.colostate.edu/the-socratic-method/) +Mentorship in 3 Acts by Adam Cuppy (https://www.youtube.com/watch?v=eDX5WH1uLz8) +Exercism mentoring (https://exercism.org/mentoring) +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: I was recently having a conversation with a colleague about some old-school object orientation exercises that people used to do when trying to do more of the analysis phase of software, ones that I haven't seen come up a lot in the past; you know, 5, 10 years. +The particular one that I'm thinking about is an exercise where you write out the sort of business problem, and then you go through and you circle all of the nouns in that paragraph. And then, from there, you have a conversation around which one of these are kind of the same thing and are just synonyms? Which ones might be slight variations on an idea? And which ones should become entities in your system? Because, likely, these things are then going to be objects in the system that you're creating. +STEPHANIE: Wow, that sounds really cool. I'm surprised that it's considered old school or, I guess, I haven't heard of it before. So, it's not something in my toolbox these days. But I really like that idea. I guess, you know if you're doing it on pen and paper, it's obviously kind of timeless to me. +JOËL: And you could easily do it, you know, in a Google Doc and underline, or highlight, or whatever you want to do. But it's not an exercise that I see people really doing even at the larger scale but even at, the smaller scale, where you have maybe a ticket in your ticketing system, and it has a paragraph there kind of describing what needs to be done. We tend to just kind of jump into, oh, we're going to build a story and do the work and maybe not always think about what are the entities that need to happen out of that. +STEPHANIE: I think the other thing that I really like about this idea is the aligning on shared vocabulary. So, if you find yourself using different words for the same idea, is that an opportunity to pick the vocabulary that best represents what this means? Rather than a situation that I often find myself in, where we're all talking about the same things but using different words and sometimes causing a little bit more confusion than I think is necessary. +JOËL: Definitely. It can also be a good opportunity to connect with the product or businesspeople around; hey, here are two words that sound like they're probably meaning the same thing. Is there a distinction in your business? And then, you realize, wait a minute, a shopping cart and an order actually do have some slight differences. And now you can go into those. And that probably sparks some really valuable learning about the problem that you're trying to solve that might not come up otherwise, or maybe that only comes up at code review time, or maybe even during the QA phase rather than during the analysis phase. +STEPHANIE: Yeah. I think that's really important for us as developers because, as we know, naming is often the hardest part of writing code, right? And, you know, at that point, you are making that decision or that distinction between maybe a couple of different terms that you're using to describe an idea and putting that down then will continue on to be read. And just propagating that down the line of, is this name actually what we mean? Or maybe we are using words that, at this lower level, make more sense, but when interacting or communicating with business stakeholders or product folks, they are using a different term. +And I really like the idea of that activity being a cross-functional one where you can kind of agree on how to move forward there. Because lately, I've been finding myself oftentimes using both words where the product folks are describing it this way, and then we've, on the engineering side, have decided that, okay, we're actually going to call our database table this other thing, and now having to type out both [chuckles] meanings each time because I know that my audience is in both camps. +JOËL: Yeah. There's, I think, a lot of value in using the business terms where possible. If you don't use them, there has to be a good reason. There's a slight distinction for the technical term. We're using it to say, hey, it's different from the business idea in interesting ways that only matter to the dev team. +STEPHANIE: Is there a name for this activity? +JOËL: I don't know, just circling nouns or underlining nouns. +STEPHANIE: Cool. Maybe we can come up with something. [laughs] Or someone else can tell us if they know what this kind of exercise is called. +JOËL: Gotta name the naming activity. So, how about you, Stephanie, what's new in your world? +STEPHANIE: So, I have a pretty exciting life development to share. I am currently working from a different location than my home in Chicago. I'm in the Hudson Valley in New York for the next month because my partner and I are considering moving out here. And we are just kind of looking for a different pace of life a little bit. And we are taking this month as a trial run to see if we want to, you know, be out here permanently. And I've been having a great time so far. +One thing that I've really enjoyed is all of the rail trails out here. So, a lot of old railroad tracks have been repurposed for outdoor recreation, and they are great for biking, or running, or even just walking. And I've been able to hop on my bike, you know, and bike a few minutes, and then I'm on the trail and just kind of surrounded by trees and forests. And that's been really nice because I missed having access to nature kind of, like, right outside my door. +JOËL: So, you used to do quite a bit of urban biking in Chicago. But it sounds like now you're getting a chance to do more kind of nature biking. +STEPHANIE: Yeah, it's a big difference for me because urban biking was always pretty rough or a little scary just, you know, having to bike with traffic. And I got a lot better at it. But now I'm, you know, biking completely off the roads. And I don't have to worry too much about cars. And I can, you know, just enjoy the fresh air around me and just be a lot more relaxed, I think, than I was able to when I was commuting in the city. +JOËL: So, here's the real question. At this new location that you're staying at, do you have a bike shed? +STEPHANIE: Not yet. But we now could have a bike shed because there's a lot more space out here, too. So, I could theoretically have my bike shed in my nice, big yard right next to my garden. And these are all [laughs] the hopes and dreams I have for my future life. +JOËL: Before you build the bike shed, you can have six months of discussion about what color you want to paint it. +STEPHANIE: Yeah, that's why I have this podcast, actually. [laughter] So, look out for that in what's new in my world is considering paint colors for a theoretical future bike shed in a place where I yet don't live. +JOËL: You're going to become an expert in the Pantone color palettes. +STEPHANIE: I hope so. That would be a great addition to my title. So, another thing that's new in both of our shared worlds is a new initiative on Boost, the team we're on, that you have been involved in. It's pairing sessions with the principal developer. +JOËL: Yes. So myself and, another principal developer at thoughtbot have been doing weekly pairing sessions, where we take Tuesday afternoons and pair with one of the other members of the team on their client project doing whatever. So, it's not, a, like, pull someone in when you need help or anything that's more kind of targeted in that way. It's more of a you sign up for this ahead of time. And you just know that on this week, you get someone to pair with you who can hopefully bring in a different perspective a lot of experience, and pair with you on your particular project. +STEPHANIE: Yeah. I'm so excited about this initiative because I've not been staffed on a project with you before or the other principal developer who's involved. And I have really wanted to work with you all and be able to learn from you. And I think this is a really cool way to make that expertise more accessible if you just don't happen to be working on a project together. +JOËL: Yeah. One of the challenges I think of the principal role is that we want it to be a role that has a high impact on the team as a whole. But also, we are people who can be staffed on pretty much any client project that gets thrown at us and can easily be staffed on projects that require solo work. Whereas there are some teammates who I think it's the developer position that we guarantee they're never staffed solo. +And so, that can often mean that our principals get staffed on to the really technically challenging problems or the solo problems, but then there's maybe not as much room to have interactions with the rest of the team on a day-to-day basis. +STEPHANIE: Yeah. I think the key word you said that had me nodding my head was impact. And I'm curious what your hopes are for this effort and what kind of impact you want to be having for our team. +JOËL: I think it's impact on a few different levels, definitely some form of knowledge sharing. Myself and the other principal developer have decade plus experience each in the field, have deep knowledge in a lot of different things like test-driven development, object modeling, security, things like that that build on top of kind of more basic developer skills that we all have. And those are all, I think, great ways that we can support our team if there's any interest in those particular skills or if they come up on a particular project. +And knowledge sharing works both ways, right? I think anytime you're pairing with someone else, there's an opportunity to learn on both sides. And so, I think a really important thing when you're pairing with someone, even if you're kind of maybe more explicitly the mentor figure, is to kind of keep that open mind and look for not only what can I give, how can I teach, but what can I learn from this other person? +STEPHANIE: Yeah, absolutely. I guess I'm wondering...and I know this is a pretty new programming so far, but is there anything you've learned or anything that surprised you that you weren't expecting when you, you know, first conceived of the idea based on how it's been going? +JOËL: Something that really surprised me, there's some feedback I got after one of the pairing sessions, where this colleague who we'd paired together...and I felt like I hadn't contributed a ton, like, this colleague just really had it and was just kind of going through and doing things. So, I was kind of, like, leaving that pairing session being like, oh, I don't know if I added a ton of value here. +And then, this colleague reached out to me and said, "Oh, you know, I felt, like, this huge boost of confidence because we were pairing together, and you were just kind of nodding along and basically saying yes to all of my choices." And I hadn't really considered that that can be a really valuable aspect of this sort of pairing. Sometimes you know the right thing to do, like, you've got it. But it's really easy to second-guess yourself. And just having someone along to, you know, give you that thumbs of like, yeah, this is the thing to do, can give you that confidence boost and kind of keep you moving in a way that feels really positive. +STEPHANIE: Wow. I love that. That's really powerful, and I get that. Because, you know, obviously, it's very valuable to have your colleagues help generate different ideas that you might not have considered. But that validation can be really useful. And, you know, that's just not something you get when with a rubber duck. [laughs] The rubber duck can't respond, and [laughs] nod along. +So, I think that's really cool that you were able to provide some of that confidence. And, in fact, I think that is contributing to their growth, right? In terms of helping identify, you know, those aspects that they're already really strong at, as well as developing that relationship so they know you're available to them next time if they do need someone to either do that invalidating or validating of an idea. +JOËL: Yeah, there's a lot of power, I think, in kind of calling out people's strength and providing validation in a way that can really help someone get to the next level in their career. And it feels like such a simple thing. But yeah, sometimes you can have the biggest impact not by kind of going in and helping but just kind of maybe, like, standing back a little bit and giving someone a thumbs up. So, definitely one of the biggest surprises or, I think, one of the biggest lessons learned for me in the past few weeks of doing this. +STEPHANIE: That's very cool. +JOËL: So, Stephanie, you've also been doing some pairing or some mentoring from what I hear. +STEPHANIE: Yeah. So, on my current client work, I have been pairing with a new hire on my client team who recently graduated from college. And this is his first job in software development. And I have been thinking and learning a lot through this experience because one of my goals was to get better at coaching, specifically the idea of asking guiding questions to help someone, you know, arrive at their own solution instead of, you know, making the suggestions myself or kind of dictating where to go. +And this has kind of been a progression for me of kind of starting from, well, you know, I have the way that I want to do it. And the person I'm working with who maybe has less experience, like, they might not know where to go. So, we're just going to go along with my idea. And then the next step was offering a few different ideas, like a menu of options and kind of having that discussion about which way to go. +And now, I really wanting to practice letting someone else lead entirely and helping them start thinking about the right things but ultimately not giving them the answer. But hopefully, like, the questions I've been asking means that they are able to get to a well-informed answer where they've thought through some of the things that I would think about if I were in the position of making the decision or figuring out how to implement. +JOËL: Is this mostly asking questions to get them to think about edge cases, or is this, like, a Socratic approach to teaching? +STEPHANIE: Could you describe Socratic approach for me? +JOËL: So, the Socratic approach is a teaching approach that is question-based, where you kind of help the student come to the conclusions themselves by answering questions rather than by telling them the answer. +STEPHANIE: Oh, interesting. I think a little bit of both. Where it's true, I am able to see some edge cases that folks with less experience might not consider because they just haven't had to run into them before or fight the fires when [laughs] their code in production ends up being a big issue or causes a bug. +But I think that's just part of the work where there is kind of, like, a default dynamic that might be fallen into when two people are working together, and their experience levels differ, where the person who has less experience is wanting to lean on the more senior person to tell them where to go, or to expect to be in that position of just learning from them and not necessarily doing as much of the active thinking. But I was really interested in flipping that and doing a bit of a role reversal because I think it can be really impactful and, you know, help folks earlier in their career, like, really level up even more quickly than just watching, but actually doing. +And so, the questions I've been asking have been a lot more open-ended in terms of, like, asking, "What do you think about this code that we're looking at?" Or, like, "Where do you want to go next?" And based on, you know, their answers, digging in a little more, and, at the end, maybe, like, giving that validation that we were talking about earlier. I was like, "Great. Like, I think that's a great path forward," or, "I think that's a good idea to spend our time on right now." +But the open-ended questions, I think, are also ones that I also would have liked when I was in that position of learning, where having someone trust that I could draw on my past experience but, like, also knowing that they were there to support and maybe orient me if I ended up straying too far off the path. +JOËL: How have you navigated situations where maybe you're asking a question about "What do you want to do next?" and they pick something that maybe would work but is not your sort of preferred approach, or maybe something that seems like it would work well enough but, you know, there's maybe a better approach? How do you navigate that? Do you let them take their approach and maybe kind of let them run into some of the edge cases and problems and then say, "Hey, let me show you something new"? Do you probe a little bit earlier? Or do you say, "Hey, that's good, but why don't we try my way"? How do you navigate that kind of situation? +STEPHANIE: That is so hard. It's really challenging. Because if you kind of know that there's maybe a more effective way, or a cleaner way, or whatever, and you're seeing your pair or your mentee kind of go down a different path, you know, it's so easy to just kind of jump in and be like, "Oh, actually, like, let me save you some time, and effort, and pain and just kind of tell you that there's something else we could try." +But I think I've been trying to sit on my hands a little bit and let them go down that path or at least let them finish explaining kind of what their thought process is and giving them the opportunity to do that act of thinking to see it through without interrupting them because I think it's really important to, you know, just honor the process that they're going through. +I will say, though, that I also try to keep an eye on the time. And I am also, like, holding in my head a bit of a higher level, like, the project status, any deadlines, what's on our plate for the sprint. And so, if I'm seeing that maybe the path they want to go down might end up taking a while or we don't quite have enough time for that, to then come back and revisit and adjust and reiterate on, like, their first solution. Then that is usually an opportunity where I might offer them another way or say, like, "Hey, like, this is what I'm thinking," because of those things I mentioned before with deadlines or something I'm considering. +But I generally try not to impose any of that as, like, this is what we will do so much as saying, "This is what I think we should do." Because I really want to hone in on the idea that, like, everyone just has opinions [laughs] about how they want to do things. And I'm not claiming mine is the perfect way or even the best way, but just what I'm thinking in this moment. +JOËL: Yeah, time permitting, I've really appreciated scenarios where you give people a chance to do the non-optimal solution and run into edge cases that kind of show why that solution is not optimal and then backtrack out of it and then go to the optimal path. I think that's a lesson that really sticks much longer. So, I've even done that in scenarios where I'm building some training material. And I'll kind of purposely have the group go down the sort of obvious path, but that turns out to be non-optimal. +And then, you hit a wall where things don't work, and then you have to backtrack. And it's like, okay, so that's why we don't do it that way that may have seemed obvious. Because then everybody remembers as opposed to...I mean, you could just go down this other path, and somebody asks you a question, "Why don't we go down this thing?" And then, they just...maybe they have to remember it, or it becomes a thing where it's like, oh, but, like, we were told that's a bad way to do it. And now you have this sort of, like, weird, like, absolutism about, like, oh, but, you know, Joël said that was bad. So, we just got to remember that's the bad thing. +And it's not about the morality of that choice that I think can come through when you're kind of declaring a path good and a path bad, but instead, having experienced, hey, we went down this path. There were some drawbacks to it, which is why we prefer this other path. And I think that tends to stick a lot more with students. +STEPHANIE: Yeah. I really like what you said about not wanting to inject that, like, morality argument or even kind of deny them the opportunity to decide for themselves how they thought that path went or, like, how they thought the solution was. If you just tell them like, "No, don't go there," you're kind of closing the door on it. And, yeah, they might spend a lot of time afterwards thinking that, like, that will always be a bad option without really forming an opinion for themselves, which I think is really important. Because, you know, once you do get more experience, that is pretty much, like, the work [laughs] that we're doing all of the time. +But another thing that I think is also such a skill is assessing your own work, like, after you go down the path or, like, once you have something working, being able to come back to it and look at it and be like, oh, like, can this be better, right? And I think that can only happen once you have something to look at, once you have, like, a first draft, if you will, or do the less optimal implementation or naive implementation. +JOËL: So, when you're trying to prompt someone to kind of build that skill of self-review or self-reflection on some of the work that they've done, how do you as a pair or a mentor help stimulate that? +STEPHANIE: Yeah. I think with early career folks, one thing that is an easy way to start the conversation is asking, "Are there any places that could be more readable?" Because that's, I think, an aspect that often gets forgotten because they're trying to hold so much in their heads that they are really just getting the code to work. And I think readability is something that we all kind of understand. It doesn't include any jargon about design patterns that they might not have learned yet. You know, even asking about extracting or refactoring might be not where they are at yet. +And so, starting with readability, for example, often gets you some of those techniques that we've learned that have, you know, specialized vocabulary. But I have found that it helps meet them where they're at. And then, in time, when they do learn about those things, they can kind of apply what they've already been doing when kind of prompted with that question as, like, oh, it turns out that I was already kind of considering this in just a different form. +JOËL: And I think one thing that you gain with experience is that you have kind of a live compiler or interpreter of the language in your head. And so, sometimes for more complex code, I, as an experienced developer, can look at it and immediately be like, oh yeah, here's some edge cases where this code isn't going to work that someone newer to the language would not have thought of. +And so, sometimes the way I like to approach that is either ask about, "Oh, what happens in this scenario?" Or sometimes it's something along the lines of, "Hey, now that we've kind of done the main workflow, there's a couple of edge cases that I want to make sure also work. Let's write out a couple of test cases." So, I'll write a couple of unit tests for edge cases that I know will break the code. +But even when we write the unit tests, my pair might assume that these tests will pass. And so, we'll write them; we'll run them and be like, "Oh no, look at that. They're red. I wonder why." And, you know, you don't want to do it in a patronizing way. But there's a way to do that that is, I think, really helpful. And then you can talk about, okay, well, why are these things failing? And what do we need to change about the code to make sure that we correctly handle those edge cases? +STEPHANIE: Yeah, that's really great. And now, they also have learned a technique for figuring out how to move forward when they think there might be some edge cases. They're like, oh, I could write a test, and they end up [laughs] maybe learning how to do TDD along the way. But yeah, offering that strategy, I think, as a supplement to having supported them in their workflow, I think, is a really cool way to both help them learn a different strategy or tactic while also not asking them to, like, completely change the way that they do their development. +JOËL: So, we've talked about ways that we can coach and mentor in a more of a one-on-one setting. But it can also happen in more of a group setting. And an initiative that I've been involved in recently is, once a quarter, the principals on thoughtbot's Boost team are running a training session on a topic that we choose. +And we chose this month to make it really interactive. We created an exercise. We talked a little bit about it, had people break out into breakout rooms for a pretty short time—it was like 20 minutes—and come up with a solution. And then brought it back to the big group to talk through some of the solutions. All of that within 45 minutes, so it's a very kind of dense-packed thing. And I think it went really well. +STEPHANIE: Yeah. So, hearing that makes me think that the group wasn't actually going to get to a solution in necessarily that short amount of time. But I'm wondering if that was maybe intentional. Like it was never really about coming to the optimal solution but just the act of thinking about it or practicing how you would do that problem-solving without as much of a focus on the outcome. +JOËL: So, yes and no. I think, as you said, the discussion, the journey is more important than the outcome. But also, because we wanted people to have a realistic chance at coming up with some kind of solution, we specifically said, "We don't want code. Don't write a code solution to this." Instead, we suggested people come up with some kind of diagram. +So, the problem was, we have some sort of business process where you start by...you have an endpoint that needs to receive some kind of shopping cart JSON and then goes through a few different steps. You have to validate it. You have to attempt to charge their card, and then eventually, it has to be sent off to a warehouse to be fulfilled. +And so, we're asking them to diagram this while thinking a little bit about data modeling and a little bit about potential edge cases and errors. People came up with some really interesting diagrams for this because there's multiple different lenses from which you could approach that problem. +STEPHANIE: That's cool. I really like that you left it up to the groups to figure out, you know, what kind of tools they wanted to use and the how. You mentioned different lenses. So, I'm taking it that you didn't necessarily share what the steps of starting to consider the data modeling would be. Did you prompt the group in any way? How did you set them up before they broke out? +JOËL: So, we had a document that had a problem definition; part of this involved talking to a few external services, so things like attempting to charge their card. I think there was a user service they needed to do to pull some user information. And then, there's that fulfillment center that we submit to the warehouse with your completed order. And so, we had sample JSONs for all of these. Again, the goal is not for them to write any code that deals with it but more to think about: okay, we need information from this payload to plug into this one. And then, if they want to add any sort of intermediate steps, they can do that. +And I think sort of two common lenses that you could look at this is from more of an action standpoint, so to say, okay, well, first, we receive this payload, and then we make a call to this endpoint, and we try to do a thing and then success or failure, and then kind of go down this path and success or failure, and kind of keep going down that path until you finally reach that fulfillment endpoint. +So, it's almost like a control flow diagram. But you could also take more of a data-centered approach and talk about how the data evolves as it goes through this process. And so, you start with, like, a raw JSON payload. And maybe that gets parsed into a shopping cart object, which then gets turned into a temporary order, which then gets turned into a validated order, which then is combined with a credit card charge to create a fulfillment order, which can then be sent off to the warehouse. And that perspective will completely change the way you think about what the code actually needs to be when you create it. +STEPHANIE: Got it. That's cool. So, I'm curious, you know, what went into figuring out what the prompt would look like? I guess, like, where did you start? Did you already know that there would be these two different ways of thinking about or lenses to data modeling that you're, like, oh, like, maybe these groups will go down this route? Or was it, I guess, a bit of a surprise that when you came together, you found out kind of the different approaches? +JOËL: We already knew that there would be multiple approaches, and we chose not to specify which one to take. I think now this is getting into almost like curriculum design and more kind of the pedagogy side of things, which I'm, you know, excited and passionate about. I don't know, is that something that you've done at all for some of your projects or areas where you've been coaching people? +STEPHANIE: It's not been. But I actually do think it's a bit of a goal of mine to lead a workshop at some point at a conference because I really like the hands-on stuff that I get to do day-to-day, you know, working one-on-one with people. And, you know, I also am on the conference circuit. [laughs] And I was thinking that maybe workshops could be a really cool way to bring together those two things of like, well, I am enjoying that experience of working one-on-one, but it is, oftentimes, you know, just on our regular day-to-day work. And so, I would be really curious about how to develop that kind of curriculum for teaching purposes. +Do you find yourself starting with problems you see on client work and kind of stripping that down into something maybe a little more general, or do these problems kind of just come up spontaneously? [chuckles] +JOËL: So, workshop design is, I think, its own really fascinating topic, and honestly, we could probably do a whole episode on it. But the short of it is I typically work backwards from an end goal. So, just like when I'm writing a blog post, I have one big thing I want people to learn from a workshop, and then everything works backwards from there. Anything that is part of the workshop has to be building towards that big goal, that one thing I want people to learn. Otherwise, I strip it out. +So, it's an exercise in ruthlessly cutting to make sure that I'm not overwhelming people and, you know, that we can fit in the time that we have because there's always not enough time in a workshop. And people can very easily get sidetracked or overwhelmed. So, as much as possible, have everything focusing in towards one goal. +Circling back to the mentoring side of things, I'm curious what you see is maybe some of the biggest challenges as a mentor or a coach. +STEPHANIE: Well, I think, for me, it was, in some ways, like, seeing myself in that role as mentor. Like, oftentimes, that was decided for me by someone else as, like, "Oh, hey. We have a new hire, and, like, would you be their onboarding buddy?" Or, you know, a manager kind of identifying, like, oh, like, Stephanie has been in this role for, you know, a few years now. She's surely ready to mentor [laughs] new folks or people joining the team. +And that was really hard for me because I was like, well, I still have so much to learn [laughs], you know, like, how could I possibly be in that position now? You know, I am still learning from all these other people who are mentors to me. +So, one thing that took me a long time was learning that I did have things that I knew that other people didn't. And I started to think of it more as this, like, ring of overlapping circles where, you know, we all probably do share some common knowledge. But we all are also experts in different things, and everyone always has something to teach. Even if you're just, like, a few months or, like, a year ahead of someone else, that is actually a really powerful spot to cultivate peer mentorship, and where I think learning can really thrive. +There's a really great talk about this by Adam Cuppy called Mentorship in Three Acts, where he talks about that peer mentorship, where someone just knows, like, a little more than someone else. That can be really powerful and can be a good entry point for people who are interested in getting into mentorship but are kind of worried that, like, oh, they are, you know, not a senior yet. +You know, when you're at a similar experience level as who you're working with, there is a little bit less of what we were describing earlier of, like, that dynamic of knowing what to do but kind of wanting to hold back and let them discover for themselves. In that peer mentorship dynamic, you know, both people are, like, really deep in it, kind of trying things out, experimenting, learning, and that ends up being really fruitful time for both of them. +JOËL: Based on your experience, would you say that maybe that's the best place to start for someone who's looking to get into mentorship, so kind of pursue more of a peer mentorship scenario? +STEPHANIE: Yeah. I would definitely say that it has helped me a lot. I've had a lot of peer mentorship relationships in the past, where maybe there just wasn't someone on the team who could mentor me at the time. Or maybe I was wanting to collaborate a little bit more and feeling like I did have some ideas and opinions that I wanted to talk about, or share, or get some feedback on. Reaching across my level was really helpful in starting to create that space. +Yeah, I was really surprised by all the things that I was learning and all the things that the other person was learning from me that I think was a good wealth of experience for me to then bring to the next step when I found myself kind of in that position of supporting others who were more junior. +JOËL: I'd like to also shout out Exercism.io as a great place to get started with mentoring. For those who are not aware, Exercism is a platform where they have a bunch of exercises that you can go through to learn a language. And you can go through them on your own, but you can also go through them with a mentor. Somebody will basically give you a little mini code review on your exercise or maybe help you out if you're stuck. And this all happens asynchronously. +And it's volunteer-run. So, they just have people from the community who volunteer to be mentors on there to help coach people through the exercises. We'll put a link in the show notes to the page they have, kind of explaining how the mentorship works and how to sign up. But I did that for a while. And it was a really rewarding experience for me. I thought that I'd be mostly helping and teaching, but honestly, I learned so much as part of the process. +So, I would strongly recommend that to anybody who wants to maybe dip their toe a little bit in the mentoring coaching world but maybe feels like they're not quite ready for it. I think it's a great way to start. +STEPHANIE: Ooh, that sounds really cool. Yeah, I know that, especially for folks who maybe are working a little bit more independently, or are a bit isolated, or don't have a lot of people on a team that they're able to access; that sounds like a really great solution for folks who are looking for that kind of support outside of their immediate circle. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël describes an old-school object orientation exercise that involves circling nouns in a business problem description. The purpose is determining which nouns could become entities or objects in a system. Stephanie shares she's working from the Hudson Valley in New York as a trial run for potentially relocating there. She enjoys the rail trails for biking and contrasts it with urban biking in Chicago.

+ +

The conversation between Joël and Stephanie revolves around mentorship, both one-on-one and within a group setting. They introduce a new initiative at thoughbot where team members pair up with principal developers for weekly sessions, emphasizing sharing perspectives and experiences.

+ +
+ + + +

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: I was recently having a conversation with a colleague about some old-school object orientation exercises that people used to do when trying to do more of the analysis phase of software, ones that I haven't seen come up a lot in the past; you know, 5, 10 years.

+ +

The particular one that I'm thinking about is an exercise where you write out the sort of business problem, and then you go through and you circle all of the nouns in that paragraph. And then, from there, you have a conversation around which one of these are kind of the same thing and are just synonyms? Which ones might be slight variations on an idea? And which ones should become entities in your system? Because, likely, these things are then going to be objects in the system that you're creating.

+ +

STEPHANIE: Wow, that sounds really cool. I'm surprised that it's considered old school or, I guess, I haven't heard of it before. So, it's not something in my toolbox these days. But I really like that idea. I guess, you know if you're doing it on pen and paper, it's obviously kind of timeless to me.

+ +

JOËL: And you could easily do it, you know, in a Google Doc and underline, or highlight, or whatever you want to do. But it's not an exercise that I see people really doing even at the larger scale but even at, the smaller scale, where you have maybe a ticket in your ticketing system, and it has a paragraph there kind of describing what needs to be done. We tend to just kind of jump into, oh, we're going to build a story and do the work and maybe not always think about what are the entities that need to happen out of that.

+ +

STEPHANIE: I think the other thing that I really like about this idea is the aligning on shared vocabulary. So, if you find yourself using different words for the same idea, is that an opportunity to pick the vocabulary that best represents what this means? Rather than a situation that I often find myself in, where we're all talking about the same things but using different words and sometimes causing a little bit more confusion than I think is necessary.

+ +

JOËL: Definitely. It can also be a good opportunity to connect with the product or businesspeople around; hey, here are two words that sound like they're probably meaning the same thing. Is there a distinction in your business? And then, you realize, wait a minute, a shopping cart and an order actually do have some slight differences. And now you can go into those. And that probably sparks some really valuable learning about the problem that you're trying to solve that might not come up otherwise, or maybe that only comes up at code review time, or maybe even during the QA phase rather than during the analysis phase.

+ +

STEPHANIE: Yeah. I think that's really important for us as developers because, as we know, naming is often the hardest part of writing code, right? And, you know, at that point, you are making that decision or that distinction between maybe a couple of different terms that you're using to describe an idea and putting that down then will continue on to be read. And just propagating that down the line of, is this name actually what we mean? Or maybe we are using words that, at this lower level, make more sense, but when interacting or communicating with business stakeholders or product folks, they are using a different term.

+ +

And I really like the idea of that activity being a cross-functional one where you can kind of agree on how to move forward there. Because lately, I've been finding myself oftentimes using both words where the product folks are describing it this way, and then we've, on the engineering side, have decided that, okay, we're actually going to call our database table this other thing, and now having to type out both [chuckles] meanings each time because I know that my audience is in both camps.

+ +

JOËL: Yeah. There's, I think, a lot of value in using the business terms where possible. If you don't use them, there has to be a good reason. There's a slight distinction for the technical term. We're using it to say, hey, it's different from the business idea in interesting ways that only matter to the dev team.

+ +

STEPHANIE: Is there a name for this activity?

+ +

JOËL: I don't know, just circling nouns or underlining nouns.

+ +

STEPHANIE: Cool. Maybe we can come up with something. [laughs] Or someone else can tell us if they know what this kind of exercise is called.

+ +

JOËL: Gotta name the naming activity. So, how about you, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I have a pretty exciting life development to share. I am currently working from a different location than my home in Chicago. I'm in the Hudson Valley in New York for the next month because my partner and I are considering moving out here. And we are just kind of looking for a different pace of life a little bit. And we are taking this month as a trial run to see if we want to, you know, be out here permanently. And I've been having a great time so far.

+ +

One thing that I've really enjoyed is all of the rail trails out here. So, a lot of old railroad tracks have been repurposed for outdoor recreation, and they are great for biking, or running, or even just walking. And I've been able to hop on my bike, you know, and bike a few minutes, and then I'm on the trail and just kind of surrounded by trees and forests. And that's been really nice because I missed having access to nature kind of, like, right outside my door.

+ +

JOËL: So, you used to do quite a bit of urban biking in Chicago. But it sounds like now you're getting a chance to do more kind of nature biking.

+ +

STEPHANIE: Yeah, it's a big difference for me because urban biking was always pretty rough or a little scary just, you know, having to bike with traffic. And I got a lot better at it. But now I'm, you know, biking completely off the roads. And I don't have to worry too much about cars. And I can, you know, just enjoy the fresh air around me and just be a lot more relaxed, I think, than I was able to when I was commuting in the city.

+ +

JOËL: So, here's the real question. At this new location that you're staying at, do you have a bike shed?

+ +

STEPHANIE: Not yet. But we now could have a bike shed because there's a lot more space out here, too. So, I could theoretically have my bike shed in my nice, big yard right next to my garden. And these are all [laughs] the hopes and dreams I have for my future life.

+ +

JOËL: Before you build the bike shed, you can have six months of discussion about what color you want to paint it.

+ +

STEPHANIE: Yeah, that's why I have this podcast, actually. [laughter] So, look out for that in what's new in my world is considering paint colors for a theoretical future bike shed in a place where I yet don't live.

+ +

JOËL: You're going to become an expert in the Pantone color palettes.

+ +

STEPHANIE: I hope so. That would be a great addition to my title. So, another thing that's new in both of our shared worlds is a new initiative on Boost, the team we're on, that you have been involved in. It's pairing sessions with the principal developer.

+ +

JOËL: Yes. So myself and, another principal developer at thoughtbot have been doing weekly pairing sessions, where we take Tuesday afternoons and pair with one of the other members of the team on their client project doing whatever. So, it's not, a, like, pull someone in when you need help or anything that's more kind of targeted in that way. It's more of a you sign up for this ahead of time. And you just know that on this week, you get someone to pair with you who can hopefully bring in a different perspective a lot of experience, and pair with you on your particular project.

+ +

STEPHANIE: Yeah. I'm so excited about this initiative because I've not been staffed on a project with you before or the other principal developer who's involved. And I have really wanted to work with you all and be able to learn from you. And I think this is a really cool way to make that expertise more accessible if you just don't happen to be working on a project together.

+ +

JOËL: Yeah. One of the challenges I think of the principal role is that we want it to be a role that has a high impact on the team as a whole. But also, we are people who can be staffed on pretty much any client project that gets thrown at us and can easily be staffed on projects that require solo work. Whereas there are some teammates who I think it's the developer position that we guarantee they're never staffed solo.

+ +

And so, that can often mean that our principals get staffed on to the really technically challenging problems or the solo problems, but then there's maybe not as much room to have interactions with the rest of the team on a day-to-day basis.

+ +

STEPHANIE: Yeah. I think the key word you said that had me nodding my head was impact. And I'm curious what your hopes are for this effort and what kind of impact you want to be having for our team.

+ +

JOËL: I think it's impact on a few different levels, definitely some form of knowledge sharing. Myself and the other principal developer have decade plus experience each in the field, have deep knowledge in a lot of different things like test-driven development, object modeling, security, things like that that build on top of kind of more basic developer skills that we all have. And those are all, I think, great ways that we can support our team if there's any interest in those particular skills or if they come up on a particular project.

+ +

And knowledge sharing works both ways, right? I think anytime you're pairing with someone else, there's an opportunity to learn on both sides. And so, I think a really important thing when you're pairing with someone, even if you're kind of maybe more explicitly the mentor figure, is to kind of keep that open mind and look for not only what can I give, how can I teach, but what can I learn from this other person?

+ +

STEPHANIE: Yeah, absolutely. I guess I'm wondering...and I know this is a pretty new programming so far, but is there anything you've learned or anything that surprised you that you weren't expecting when you, you know, first conceived of the idea based on how it's been going?

+ +

JOËL: Something that really surprised me, there's some feedback I got after one of the pairing sessions, where this colleague who we'd paired together...and I felt like I hadn't contributed a ton, like, this colleague just really had it and was just kind of going through and doing things. So, I was kind of, like, leaving that pairing session being like, oh, I don't know if I added a ton of value here.

+ +

And then, this colleague reached out to me and said, "Oh, you know, I felt, like, this huge boost of confidence because we were pairing together, and you were just kind of nodding along and basically saying yes to all of my choices." And I hadn't really considered that that can be a really valuable aspect of this sort of pairing. Sometimes you know the right thing to do, like, you've got it. But it's really easy to second-guess yourself. And just having someone along to, you know, give you that thumbs of like, yeah, this is the thing to do, can give you that confidence boost and kind of keep you moving in a way that feels really positive.

+ +

STEPHANIE: Wow. I love that. That's really powerful, and I get that. Because, you know, obviously, it's very valuable to have your colleagues help generate different ideas that you might not have considered. But that validation can be really useful. And, you know, that's just not something you get when with a rubber duck. [laughs] The rubber duck can't respond, and [laughs] nod along.

+ +

So, I think that's really cool that you were able to provide some of that confidence. And, in fact, I think that is contributing to their growth, right? In terms of helping identify, you know, those aspects that they're already really strong at, as well as developing that relationship so they know you're available to them next time if they do need someone to either do that invalidating or validating of an idea.

+ +

JOËL: Yeah, there's a lot of power, I think, in kind of calling out people's strength and providing validation in a way that can really help someone get to the next level in their career. And it feels like such a simple thing. But yeah, sometimes you can have the biggest impact not by kind of going in and helping but just kind of maybe, like, standing back a little bit and giving someone a thumbs up. So, definitely one of the biggest surprises or, I think, one of the biggest lessons learned for me in the past few weeks of doing this.

+ +

STEPHANIE: That's very cool.

+ +

JOËL: So, Stephanie, you've also been doing some pairing or some mentoring from what I hear.

+ +

STEPHANIE: Yeah. So, on my current client work, I have been pairing with a new hire on my client team who recently graduated from college. And this is his first job in software development. And I have been thinking and learning a lot through this experience because one of my goals was to get better at coaching, specifically the idea of asking guiding questions to help someone, you know, arrive at their own solution instead of, you know, making the suggestions myself or kind of dictating where to go.

+ +

And this has kind of been a progression for me of kind of starting from, well, you know, I have the way that I want to do it. And the person I'm working with who maybe has less experience, like, they might not know where to go. So, we're just going to go along with my idea. And then the next step was offering a few different ideas, like a menu of options and kind of having that discussion about which way to go.

+ +

And now, I really wanting to practice letting someone else lead entirely and helping them start thinking about the right things but ultimately not giving them the answer. But hopefully, like, the questions I've been asking means that they are able to get to a well-informed answer where they've thought through some of the things that I would think about if I were in the position of making the decision or figuring out how to implement.

+ +

JOËL: Is this mostly asking questions to get them to think about edge cases, or is this, like, a Socratic approach to teaching?

+ +

STEPHANIE: Could you describe Socratic approach for me?

+ +

JOËL: So, the Socratic approach is a teaching approach that is question-based, where you kind of help the student come to the conclusions themselves by answering questions rather than by telling them the answer.

+ +

STEPHANIE: Oh, interesting. I think a little bit of both. Where it's true, I am able to see some edge cases that folks with less experience might not consider because they just haven't had to run into them before or fight the fires when [laughs] their code in production ends up being a big issue or causes a bug.

+ +

But I think that's just part of the work where there is kind of, like, a default dynamic that might be fallen into when two people are working together, and their experience levels differ, where the person who has less experience is wanting to lean on the more senior person to tell them where to go, or to expect to be in that position of just learning from them and not necessarily doing as much of the active thinking. But I was really interested in flipping that and doing a bit of a role reversal because I think it can be really impactful and, you know, help folks earlier in their career, like, really level up even more quickly than just watching, but actually doing.

+ +

And so, the questions I've been asking have been a lot more open-ended in terms of, like, asking, "What do you think about this code that we're looking at?" Or, like, "Where do you want to go next?" And based on, you know, their answers, digging in a little more, and, at the end, maybe, like, giving that validation that we were talking about earlier. I was like, "Great. Like, I think that's a great path forward," or, "I think that's a good idea to spend our time on right now."

+ +

But the open-ended questions, I think, are also ones that I also would have liked when I was in that position of learning, where having someone trust that I could draw on my past experience but, like, also knowing that they were there to support and maybe orient me if I ended up straying too far off the path.

+ +

JOËL: How have you navigated situations where maybe you're asking a question about "What do you want to do next?" and they pick something that maybe would work but is not your sort of preferred approach, or maybe something that seems like it would work well enough but, you know, there's maybe a better approach? How do you navigate that? Do you let them take their approach and maybe kind of let them run into some of the edge cases and problems and then say, "Hey, let me show you something new"? Do you probe a little bit earlier? Or do you say, "Hey, that's good, but why don't we try my way"? How do you navigate that kind of situation?

+ +

STEPHANIE: That is so hard. It's really challenging. Because if you kind of know that there's maybe a more effective way, or a cleaner way, or whatever, and you're seeing your pair or your mentee kind of go down a different path, you know, it's so easy to just kind of jump in and be like, "Oh, actually, like, let me save you some time, and effort, and pain and just kind of tell you that there's something else we could try."

+ +

But I think I've been trying to sit on my hands a little bit and let them go down that path or at least let them finish explaining kind of what their thought process is and giving them the opportunity to do that act of thinking to see it through without interrupting them because I think it's really important to, you know, just honor the process that they're going through.

+ +

I will say, though, that I also try to keep an eye on the time. And I am also, like, holding in my head a bit of a higher level, like, the project status, any deadlines, what's on our plate for the sprint. And so, if I'm seeing that maybe the path they want to go down might end up taking a while or we don't quite have enough time for that, to then come back and revisit and adjust and reiterate on, like, their first solution. Then that is usually an opportunity where I might offer them another way or say, like, "Hey, like, this is what I'm thinking," because of those things I mentioned before with deadlines or something I'm considering.

+ +

But I generally try not to impose any of that as, like, this is what we will do so much as saying, "This is what I think we should do." Because I really want to hone in on the idea that, like, everyone just has opinions [laughs] about how they want to do things. And I'm not claiming mine is the perfect way or even the best way, but just what I'm thinking in this moment.

+ +

JOËL: Yeah, time permitting, I've really appreciated scenarios where you give people a chance to do the non-optimal solution and run into edge cases that kind of show why that solution is not optimal and then backtrack out of it and then go to the optimal path. I think that's a lesson that really sticks much longer. So, I've even done that in scenarios where I'm building some training material. And I'll kind of purposely have the group go down the sort of obvious path, but that turns out to be non-optimal.

+ +

And then, you hit a wall where things don't work, and then you have to backtrack. And it's like, okay, so that's why we don't do it that way that may have seemed obvious. Because then everybody remembers as opposed to...I mean, you could just go down this other path, and somebody asks you a question, "Why don't we go down this thing?" And then, they just...maybe they have to remember it, or it becomes a thing where it's like, oh, but, like, we were told that's a bad way to do it. And now you have this sort of, like, weird, like, absolutism about, like, oh, but, you know, Joël said that was bad. So, we just got to remember that's the bad thing.

+ +

And it's not about the morality of that choice that I think can come through when you're kind of declaring a path good and a path bad, but instead, having experienced, hey, we went down this path. There were some drawbacks to it, which is why we prefer this other path. And I think that tends to stick a lot more with students.

+ +

STEPHANIE: Yeah. I really like what you said about not wanting to inject that, like, morality argument or even kind of deny them the opportunity to decide for themselves how they thought that path went or, like, how they thought the solution was. If you just tell them like, "No, don't go there," you're kind of closing the door on it. And, yeah, they might spend a lot of time afterwards thinking that, like, that will always be a bad option without really forming an opinion for themselves, which I think is really important. Because, you know, once you do get more experience, that is pretty much, like, the work [laughs] that we're doing all of the time.

+ +

But another thing that I think is also such a skill is assessing your own work, like, after you go down the path or, like, once you have something working, being able to come back to it and look at it and be like, oh, like, can this be better, right? And I think that can only happen once you have something to look at, once you have, like, a first draft, if you will, or do the less optimal implementation or naive implementation.

+ +

JOËL: So, when you're trying to prompt someone to kind of build that skill of self-review or self-reflection on some of the work that they've done, how do you as a pair or a mentor help stimulate that?

+ +

STEPHANIE: Yeah. I think with early career folks, one thing that is an easy way to start the conversation is asking, "Are there any places that could be more readable?" Because that's, I think, an aspect that often gets forgotten because they're trying to hold so much in their heads that they are really just getting the code to work. And I think readability is something that we all kind of understand. It doesn't include any jargon about design patterns that they might not have learned yet. You know, even asking about extracting or refactoring might be not where they are at yet.

+ +

And so, starting with readability, for example, often gets you some of those techniques that we've learned that have, you know, specialized vocabulary. But I have found that it helps meet them where they're at. And then, in time, when they do learn about those things, they can kind of apply what they've already been doing when kind of prompted with that question as, like, oh, it turns out that I was already kind of considering this in just a different form.

+ +

JOËL: And I think one thing that you gain with experience is that you have kind of a live compiler or interpreter of the language in your head. And so, sometimes for more complex code, I, as an experienced developer, can look at it and immediately be like, oh yeah, here's some edge cases where this code isn't going to work that someone newer to the language would not have thought of.

+ +

And so, sometimes the way I like to approach that is either ask about, "Oh, what happens in this scenario?" Or sometimes it's something along the lines of, "Hey, now that we've kind of done the main workflow, there's a couple of edge cases that I want to make sure also work. Let's write out a couple of test cases." So, I'll write a couple of unit tests for edge cases that I know will break the code.

+ +

But even when we write the unit tests, my pair might assume that these tests will pass. And so, we'll write them; we'll run them and be like, "Oh no, look at that. They're red. I wonder why." And, you know, you don't want to do it in a patronizing way. But there's a way to do that that is, I think, really helpful. And then you can talk about, okay, well, why are these things failing? And what do we need to change about the code to make sure that we correctly handle those edge cases?

+ +

STEPHANIE: Yeah, that's really great. And now, they also have learned a technique for figuring out how to move forward when they think there might be some edge cases. They're like, oh, I could write a test, and they end up [laughs] maybe learning how to do TDD along the way. But yeah, offering that strategy, I think, as a supplement to having supported them in their workflow, I think, is a really cool way to both help them learn a different strategy or tactic while also not asking them to, like, completely change the way that they do their development.

+ +

JOËL: So, we've talked about ways that we can coach and mentor in a more of a one-on-one setting. But it can also happen in more of a group setting. And an initiative that I've been involved in recently is, once a quarter, the principals on thoughtbot's Boost team are running a training session on a topic that we choose.

+ +

And we chose this month to make it really interactive. We created an exercise. We talked a little bit about it, had people break out into breakout rooms for a pretty short time—it was like 20 minutes—and come up with a solution. And then brought it back to the big group to talk through some of the solutions. All of that within 45 minutes, so it's a very kind of dense-packed thing. And I think it went really well.

+ +

STEPHANIE: Yeah. So, hearing that makes me think that the group wasn't actually going to get to a solution in necessarily that short amount of time. But I'm wondering if that was maybe intentional. Like it was never really about coming to the optimal solution but just the act of thinking about it or practicing how you would do that problem-solving without as much of a focus on the outcome.

+ +

JOËL: So, yes and no. I think, as you said, the discussion, the journey is more important than the outcome. But also, because we wanted people to have a realistic chance at coming up with some kind of solution, we specifically said, "We don't want code. Don't write a code solution to this." Instead, we suggested people come up with some kind of diagram.

+ +

So, the problem was, we have some sort of business process where you start by...you have an endpoint that needs to receive some kind of shopping cart JSON and then goes through a few different steps. You have to validate it. You have to attempt to charge their card, and then eventually, it has to be sent off to a warehouse to be fulfilled.

+ +

And so, we're asking them to diagram this while thinking a little bit about data modeling and a little bit about potential edge cases and errors. People came up with some really interesting diagrams for this because there's multiple different lenses from which you could approach that problem.

+ +

STEPHANIE: That's cool. I really like that you left it up to the groups to figure out, you know, what kind of tools they wanted to use and the how. You mentioned different lenses. So, I'm taking it that you didn't necessarily share what the steps of starting to consider the data modeling would be. Did you prompt the group in any way? How did you set them up before they broke out?

+ +

JOËL: So, we had a document that had a problem definition; part of this involved talking to a few external services, so things like attempting to charge their card. I think there was a user service they needed to do to pull some user information. And then, there's that fulfillment center that we submit to the warehouse with your completed order. And so, we had sample JSONs for all of these. Again, the goal is not for them to write any code that deals with it but more to think about: okay, we need information from this payload to plug into this one. And then, if they want to add any sort of intermediate steps, they can do that.

+ +

And I think sort of two common lenses that you could look at this is from more of an action standpoint, so to say, okay, well, first, we receive this payload, and then we make a call to this endpoint, and we try to do a thing and then success or failure, and then kind of go down this path and success or failure, and kind of keep going down that path until you finally reach that fulfillment endpoint.

+ +

So, it's almost like a control flow diagram. But you could also take more of a data-centered approach and talk about how the data evolves as it goes through this process. And so, you start with, like, a raw JSON payload. And maybe that gets parsed into a shopping cart object, which then gets turned into a temporary order, which then gets turned into a validated order, which then is combined with a credit card charge to create a fulfillment order, which can then be sent off to the warehouse. And that perspective will completely change the way you think about what the code actually needs to be when you create it.

+ +

STEPHANIE: Got it. That's cool. So, I'm curious, you know, what went into figuring out what the prompt would look like? I guess, like, where did you start? Did you already know that there would be these two different ways of thinking about or lenses to data modeling that you're, like, oh, like, maybe these groups will go down this route? Or was it, I guess, a bit of a surprise that when you came together, you found out kind of the different approaches?

+ +

JOËL: We already knew that there would be multiple approaches, and we chose not to specify which one to take. I think now this is getting into almost like curriculum design and more kind of the pedagogy side of things, which I'm, you know, excited and passionate about. I don't know, is that something that you've done at all for some of your projects or areas where you've been coaching people?

+ +

STEPHANIE: It's not been. But I actually do think it's a bit of a goal of mine to lead a workshop at some point at a conference because I really like the hands-on stuff that I get to do day-to-day, you know, working one-on-one with people. And, you know, I also am on the conference circuit. [laughs] And I was thinking that maybe workshops could be a really cool way to bring together those two things of like, well, I am enjoying that experience of working one-on-one, but it is, oftentimes, you know, just on our regular day-to-day work. And so, I would be really curious about how to develop that kind of curriculum for teaching purposes.

+ +

Do you find yourself starting with problems you see on client work and kind of stripping that down into something maybe a little more general, or do these problems kind of just come up spontaneously? [chuckles]

+ +

JOËL: So, workshop design is, I think, its own really fascinating topic, and honestly, we could probably do a whole episode on it. But the short of it is I typically work backwards from an end goal. So, just like when I'm writing a blog post, I have one big thing I want people to learn from a workshop, and then everything works backwards from there. Anything that is part of the workshop has to be building towards that big goal, that one thing I want people to learn. Otherwise, I strip it out.

+ +

So, it's an exercise in ruthlessly cutting to make sure that I'm not overwhelming people and, you know, that we can fit in the time that we have because there's always not enough time in a workshop. And people can very easily get sidetracked or overwhelmed. So, as much as possible, have everything focusing in towards one goal.

+ +

Circling back to the mentoring side of things, I'm curious what you see is maybe some of the biggest challenges as a mentor or a coach.

+ +

STEPHANIE: Well, I think, for me, it was, in some ways, like, seeing myself in that role as mentor. Like, oftentimes, that was decided for me by someone else as, like, "Oh, hey. We have a new hire, and, like, would you be their onboarding buddy?" Or, you know, a manager kind of identifying, like, oh, like, Stephanie has been in this role for, you know, a few years now. She's surely ready to mentor [laughs] new folks or people joining the team.

+ +

And that was really hard for me because I was like, well, I still have so much to learn [laughs], you know, like, how could I possibly be in that position now? You know, I am still learning from all these other people who are mentors to me.

+ +

So, one thing that took me a long time was learning that I did have things that I knew that other people didn't. And I started to think of it more as this, like, ring of overlapping circles where, you know, we all probably do share some common knowledge. But we all are also experts in different things, and everyone always has something to teach. Even if you're just, like, a few months or, like, a year ahead of someone else, that is actually a really powerful spot to cultivate peer mentorship, and where I think learning can really thrive.

+ +

There's a really great talk about this by Adam Cuppy called Mentorship in Three Acts, where he talks about that peer mentorship, where someone just knows, like, a little more than someone else. That can be really powerful and can be a good entry point for people who are interested in getting into mentorship but are kind of worried that, like, oh, they are, you know, not a senior yet.

+ +

You know, when you're at a similar experience level as who you're working with, there is a little bit less of what we were describing earlier of, like, that dynamic of knowing what to do but kind of wanting to hold back and let them discover for themselves. In that peer mentorship dynamic, you know, both people are, like, really deep in it, kind of trying things out, experimenting, learning, and that ends up being really fruitful time for both of them.

+ +

JOËL: Based on your experience, would you say that maybe that's the best place to start for someone who's looking to get into mentorship, so kind of pursue more of a peer mentorship scenario?

+ +

STEPHANIE: Yeah. I would definitely say that it has helped me a lot. I've had a lot of peer mentorship relationships in the past, where maybe there just wasn't someone on the team who could mentor me at the time. Or maybe I was wanting to collaborate a little bit more and feeling like I did have some ideas and opinions that I wanted to talk about, or share, or get some feedback on. Reaching across my level was really helpful in starting to create that space.

+ +

Yeah, I was really surprised by all the things that I was learning and all the things that the other person was learning from me that I think was a good wealth of experience for me to then bring to the next step when I found myself kind of in that position of supporting others who were more junior.

+ +

JOËL: I'd like to also shout out Exercism.io as a great place to get started with mentoring. For those who are not aware, Exercism is a platform where they have a bunch of exercises that you can go through to learn a language. And you can go through them on your own, but you can also go through them with a mentor. Somebody will basically give you a little mini code review on your exercise or maybe help you out if you're stuck. And this all happens asynchronously.

+ +

And it's volunteer-run. So, they just have people from the community who volunteer to be mentors on there to help coach people through the exercises. We'll put a link in the show notes to the page they have, kind of explaining how the mentorship works and how to sign up. But I did that for a while. And it was a really rewarding experience for me. I thought that I'd be mostly helping and teaching, but honestly, I learned so much as part of the process.

+ +

So, I would strongly recommend that to anybody who wants to maybe dip their toe a little bit in the mentoring coaching world but maybe feels like they're not quite ready for it. I think it's a great way to start.

+ +

STEPHANIE: Ooh, that sounds really cool. Yeah, I know that, especially for folks who maybe are working a little bit more independently, or are a bit isolated, or don't have a lot of people on a team that they're able to access; that sounds like a really great solution for folks who are looking for that kind of support outside of their immediate circle.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Joël describes an old-school object orientation exercise that involves circling nouns in a business problem description. The purpose is determining which nouns could become entities or objects in a system. Stephanie shares she's working from the Hudson Valley in New York as a trial run for potentially relocating there. She enjoys the rail trails for biking and contrasts it with urban biking in Chicago.

+ +

The conversation between Joël and Stephanie revolves around mentorship, both one-on-one and within a group setting. They introduce a new initiative at thoughbot where team members pair up with principal developers for weekly sessions, emphasizing sharing perspectives and experiences.

+ +
+ + + +

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: I was recently having a conversation with a colleague about some old-school object orientation exercises that people used to do when trying to do more of the analysis phase of software, ones that I haven't seen come up a lot in the past; you know, 5, 10 years.

+ +

The particular one that I'm thinking about is an exercise where you write out the sort of business problem, and then you go through and you circle all of the nouns in that paragraph. And then, from there, you have a conversation around which one of these are kind of the same thing and are just synonyms? Which ones might be slight variations on an idea? And which ones should become entities in your system? Because, likely, these things are then going to be objects in the system that you're creating.

+ +

STEPHANIE: Wow, that sounds really cool. I'm surprised that it's considered old school or, I guess, I haven't heard of it before. So, it's not something in my toolbox these days. But I really like that idea. I guess, you know if you're doing it on pen and paper, it's obviously kind of timeless to me.

+ +

JOËL: And you could easily do it, you know, in a Google Doc and underline, or highlight, or whatever you want to do. But it's not an exercise that I see people really doing even at the larger scale but even at, the smaller scale, where you have maybe a ticket in your ticketing system, and it has a paragraph there kind of describing what needs to be done. We tend to just kind of jump into, oh, we're going to build a story and do the work and maybe not always think about what are the entities that need to happen out of that.

+ +

STEPHANIE: I think the other thing that I really like about this idea is the aligning on shared vocabulary. So, if you find yourself using different words for the same idea, is that an opportunity to pick the vocabulary that best represents what this means? Rather than a situation that I often find myself in, where we're all talking about the same things but using different words and sometimes causing a little bit more confusion than I think is necessary.

+ +

JOËL: Definitely. It can also be a good opportunity to connect with the product or businesspeople around; hey, here are two words that sound like they're probably meaning the same thing. Is there a distinction in your business? And then, you realize, wait a minute, a shopping cart and an order actually do have some slight differences. And now you can go into those. And that probably sparks some really valuable learning about the problem that you're trying to solve that might not come up otherwise, or maybe that only comes up at code review time, or maybe even during the QA phase rather than during the analysis phase.

+ +

STEPHANIE: Yeah. I think that's really important for us as developers because, as we know, naming is often the hardest part of writing code, right? And, you know, at that point, you are making that decision or that distinction between maybe a couple of different terms that you're using to describe an idea and putting that down then will continue on to be read. And just propagating that down the line of, is this name actually what we mean? Or maybe we are using words that, at this lower level, make more sense, but when interacting or communicating with business stakeholders or product folks, they are using a different term.

+ +

And I really like the idea of that activity being a cross-functional one where you can kind of agree on how to move forward there. Because lately, I've been finding myself oftentimes using both words where the product folks are describing it this way, and then we've, on the engineering side, have decided that, okay, we're actually going to call our database table this other thing, and now having to type out both [chuckles] meanings each time because I know that my audience is in both camps.

+ +

JOËL: Yeah. There's, I think, a lot of value in using the business terms where possible. If you don't use them, there has to be a good reason. There's a slight distinction for the technical term. We're using it to say, hey, it's different from the business idea in interesting ways that only matter to the dev team.

+ +

STEPHANIE: Is there a name for this activity?

+ +

JOËL: I don't know, just circling nouns or underlining nouns.

+ +

STEPHANIE: Cool. Maybe we can come up with something. [laughs] Or someone else can tell us if they know what this kind of exercise is called.

+ +

JOËL: Gotta name the naming activity. So, how about you, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I have a pretty exciting life development to share. I am currently working from a different location than my home in Chicago. I'm in the Hudson Valley in New York for the next month because my partner and I are considering moving out here. And we are just kind of looking for a different pace of life a little bit. And we are taking this month as a trial run to see if we want to, you know, be out here permanently. And I've been having a great time so far.

+ +

One thing that I've really enjoyed is all of the rail trails out here. So, a lot of old railroad tracks have been repurposed for outdoor recreation, and they are great for biking, or running, or even just walking. And I've been able to hop on my bike, you know, and bike a few minutes, and then I'm on the trail and just kind of surrounded by trees and forests. And that's been really nice because I missed having access to nature kind of, like, right outside my door.

+ +

JOËL: So, you used to do quite a bit of urban biking in Chicago. But it sounds like now you're getting a chance to do more kind of nature biking.

+ +

STEPHANIE: Yeah, it's a big difference for me because urban biking was always pretty rough or a little scary just, you know, having to bike with traffic. And I got a lot better at it. But now I'm, you know, biking completely off the roads. And I don't have to worry too much about cars. And I can, you know, just enjoy the fresh air around me and just be a lot more relaxed, I think, than I was able to when I was commuting in the city.

+ +

JOËL: So, here's the real question. At this new location that you're staying at, do you have a bike shed?

+ +

STEPHANIE: Not yet. But we now could have a bike shed because there's a lot more space out here, too. So, I could theoretically have my bike shed in my nice, big yard right next to my garden. And these are all [laughs] the hopes and dreams I have for my future life.

+ +

JOËL: Before you build the bike shed, you can have six months of discussion about what color you want to paint it.

+ +

STEPHANIE: Yeah, that's why I have this podcast, actually. [laughter] So, look out for that in what's new in my world is considering paint colors for a theoretical future bike shed in a place where I yet don't live.

+ +

JOËL: You're going to become an expert in the Pantone color palettes.

+ +

STEPHANIE: I hope so. That would be a great addition to my title. So, another thing that's new in both of our shared worlds is a new initiative on Boost, the team we're on, that you have been involved in. It's pairing sessions with the principal developer.

+ +

JOËL: Yes. So myself and, another principal developer at thoughtbot have been doing weekly pairing sessions, where we take Tuesday afternoons and pair with one of the other members of the team on their client project doing whatever. So, it's not, a, like, pull someone in when you need help or anything that's more kind of targeted in that way. It's more of a you sign up for this ahead of time. And you just know that on this week, you get someone to pair with you who can hopefully bring in a different perspective a lot of experience, and pair with you on your particular project.

+ +

STEPHANIE: Yeah. I'm so excited about this initiative because I've not been staffed on a project with you before or the other principal developer who's involved. And I have really wanted to work with you all and be able to learn from you. And I think this is a really cool way to make that expertise more accessible if you just don't happen to be working on a project together.

+ +

JOËL: Yeah. One of the challenges I think of the principal role is that we want it to be a role that has a high impact on the team as a whole. But also, we are people who can be staffed on pretty much any client project that gets thrown at us and can easily be staffed on projects that require solo work. Whereas there are some teammates who I think it's the developer position that we guarantee they're never staffed solo.

+ +

And so, that can often mean that our principals get staffed on to the really technically challenging problems or the solo problems, but then there's maybe not as much room to have interactions with the rest of the team on a day-to-day basis.

+ +

STEPHANIE: Yeah. I think the key word you said that had me nodding my head was impact. And I'm curious what your hopes are for this effort and what kind of impact you want to be having for our team.

+ +

JOËL: I think it's impact on a few different levels, definitely some form of knowledge sharing. Myself and the other principal developer have decade plus experience each in the field, have deep knowledge in a lot of different things like test-driven development, object modeling, security, things like that that build on top of kind of more basic developer skills that we all have. And those are all, I think, great ways that we can support our team if there's any interest in those particular skills or if they come up on a particular project.

+ +

And knowledge sharing works both ways, right? I think anytime you're pairing with someone else, there's an opportunity to learn on both sides. And so, I think a really important thing when you're pairing with someone, even if you're kind of maybe more explicitly the mentor figure, is to kind of keep that open mind and look for not only what can I give, how can I teach, but what can I learn from this other person?

+ +

STEPHANIE: Yeah, absolutely. I guess I'm wondering...and I know this is a pretty new programming so far, but is there anything you've learned or anything that surprised you that you weren't expecting when you, you know, first conceived of the idea based on how it's been going?

+ +

JOËL: Something that really surprised me, there's some feedback I got after one of the pairing sessions, where this colleague who we'd paired together...and I felt like I hadn't contributed a ton, like, this colleague just really had it and was just kind of going through and doing things. So, I was kind of, like, leaving that pairing session being like, oh, I don't know if I added a ton of value here.

+ +

And then, this colleague reached out to me and said, "Oh, you know, I felt, like, this huge boost of confidence because we were pairing together, and you were just kind of nodding along and basically saying yes to all of my choices." And I hadn't really considered that that can be a really valuable aspect of this sort of pairing. Sometimes you know the right thing to do, like, you've got it. But it's really easy to second-guess yourself. And just having someone along to, you know, give you that thumbs of like, yeah, this is the thing to do, can give you that confidence boost and kind of keep you moving in a way that feels really positive.

+ +

STEPHANIE: Wow. I love that. That's really powerful, and I get that. Because, you know, obviously, it's very valuable to have your colleagues help generate different ideas that you might not have considered. But that validation can be really useful. And, you know, that's just not something you get when with a rubber duck. [laughs] The rubber duck can't respond, and [laughs] nod along.

+ +

So, I think that's really cool that you were able to provide some of that confidence. And, in fact, I think that is contributing to their growth, right? In terms of helping identify, you know, those aspects that they're already really strong at, as well as developing that relationship so they know you're available to them next time if they do need someone to either do that invalidating or validating of an idea.

+ +

JOËL: Yeah, there's a lot of power, I think, in kind of calling out people's strength and providing validation in a way that can really help someone get to the next level in their career. And it feels like such a simple thing. But yeah, sometimes you can have the biggest impact not by kind of going in and helping but just kind of maybe, like, standing back a little bit and giving someone a thumbs up. So, definitely one of the biggest surprises or, I think, one of the biggest lessons learned for me in the past few weeks of doing this.

+ +

STEPHANIE: That's very cool.

+ +

JOËL: So, Stephanie, you've also been doing some pairing or some mentoring from what I hear.

+ +

STEPHANIE: Yeah. So, on my current client work, I have been pairing with a new hire on my client team who recently graduated from college. And this is his first job in software development. And I have been thinking and learning a lot through this experience because one of my goals was to get better at coaching, specifically the idea of asking guiding questions to help someone, you know, arrive at their own solution instead of, you know, making the suggestions myself or kind of dictating where to go.

+ +

And this has kind of been a progression for me of kind of starting from, well, you know, I have the way that I want to do it. And the person I'm working with who maybe has less experience, like, they might not know where to go. So, we're just going to go along with my idea. And then the next step was offering a few different ideas, like a menu of options and kind of having that discussion about which way to go.

+ +

And now, I really wanting to practice letting someone else lead entirely and helping them start thinking about the right things but ultimately not giving them the answer. But hopefully, like, the questions I've been asking means that they are able to get to a well-informed answer where they've thought through some of the things that I would think about if I were in the position of making the decision or figuring out how to implement.

+ +

JOËL: Is this mostly asking questions to get them to think about edge cases, or is this, like, a Socratic approach to teaching?

+ +

STEPHANIE: Could you describe Socratic approach for me?

+ +

JOËL: So, the Socratic approach is a teaching approach that is question-based, where you kind of help the student come to the conclusions themselves by answering questions rather than by telling them the answer.

+ +

STEPHANIE: Oh, interesting. I think a little bit of both. Where it's true, I am able to see some edge cases that folks with less experience might not consider because they just haven't had to run into them before or fight the fires when [laughs] their code in production ends up being a big issue or causes a bug.

+ +

But I think that's just part of the work where there is kind of, like, a default dynamic that might be fallen into when two people are working together, and their experience levels differ, where the person who has less experience is wanting to lean on the more senior person to tell them where to go, or to expect to be in that position of just learning from them and not necessarily doing as much of the active thinking. But I was really interested in flipping that and doing a bit of a role reversal because I think it can be really impactful and, you know, help folks earlier in their career, like, really level up even more quickly than just watching, but actually doing.

+ +

And so, the questions I've been asking have been a lot more open-ended in terms of, like, asking, "What do you think about this code that we're looking at?" Or, like, "Where do you want to go next?" And based on, you know, their answers, digging in a little more, and, at the end, maybe, like, giving that validation that we were talking about earlier. I was like, "Great. Like, I think that's a great path forward," or, "I think that's a good idea to spend our time on right now."

+ +

But the open-ended questions, I think, are also ones that I also would have liked when I was in that position of learning, where having someone trust that I could draw on my past experience but, like, also knowing that they were there to support and maybe orient me if I ended up straying too far off the path.

+ +

JOËL: How have you navigated situations where maybe you're asking a question about "What do you want to do next?" and they pick something that maybe would work but is not your sort of preferred approach, or maybe something that seems like it would work well enough but, you know, there's maybe a better approach? How do you navigate that? Do you let them take their approach and maybe kind of let them run into some of the edge cases and problems and then say, "Hey, let me show you something new"? Do you probe a little bit earlier? Or do you say, "Hey, that's good, but why don't we try my way"? How do you navigate that kind of situation?

+ +

STEPHANIE: That is so hard. It's really challenging. Because if you kind of know that there's maybe a more effective way, or a cleaner way, or whatever, and you're seeing your pair or your mentee kind of go down a different path, you know, it's so easy to just kind of jump in and be like, "Oh, actually, like, let me save you some time, and effort, and pain and just kind of tell you that there's something else we could try."

+ +

But I think I've been trying to sit on my hands a little bit and let them go down that path or at least let them finish explaining kind of what their thought process is and giving them the opportunity to do that act of thinking to see it through without interrupting them because I think it's really important to, you know, just honor the process that they're going through.

+ +

I will say, though, that I also try to keep an eye on the time. And I am also, like, holding in my head a bit of a higher level, like, the project status, any deadlines, what's on our plate for the sprint. And so, if I'm seeing that maybe the path they want to go down might end up taking a while or we don't quite have enough time for that, to then come back and revisit and adjust and reiterate on, like, their first solution. Then that is usually an opportunity where I might offer them another way or say, like, "Hey, like, this is what I'm thinking," because of those things I mentioned before with deadlines or something I'm considering.

+ +

But I generally try not to impose any of that as, like, this is what we will do so much as saying, "This is what I think we should do." Because I really want to hone in on the idea that, like, everyone just has opinions [laughs] about how they want to do things. And I'm not claiming mine is the perfect way or even the best way, but just what I'm thinking in this moment.

+ +

JOËL: Yeah, time permitting, I've really appreciated scenarios where you give people a chance to do the non-optimal solution and run into edge cases that kind of show why that solution is not optimal and then backtrack out of it and then go to the optimal path. I think that's a lesson that really sticks much longer. So, I've even done that in scenarios where I'm building some training material. And I'll kind of purposely have the group go down the sort of obvious path, but that turns out to be non-optimal.

+ +

And then, you hit a wall where things don't work, and then you have to backtrack. And it's like, okay, so that's why we don't do it that way that may have seemed obvious. Because then everybody remembers as opposed to...I mean, you could just go down this other path, and somebody asks you a question, "Why don't we go down this thing?" And then, they just...maybe they have to remember it, or it becomes a thing where it's like, oh, but, like, we were told that's a bad way to do it. And now you have this sort of, like, weird, like, absolutism about, like, oh, but, you know, Joël said that was bad. So, we just got to remember that's the bad thing.

+ +

And it's not about the morality of that choice that I think can come through when you're kind of declaring a path good and a path bad, but instead, having experienced, hey, we went down this path. There were some drawbacks to it, which is why we prefer this other path. And I think that tends to stick a lot more with students.

+ +

STEPHANIE: Yeah. I really like what you said about not wanting to inject that, like, morality argument or even kind of deny them the opportunity to decide for themselves how they thought that path went or, like, how they thought the solution was. If you just tell them like, "No, don't go there," you're kind of closing the door on it. And, yeah, they might spend a lot of time afterwards thinking that, like, that will always be a bad option without really forming an opinion for themselves, which I think is really important. Because, you know, once you do get more experience, that is pretty much, like, the work [laughs] that we're doing all of the time.

+ +

But another thing that I think is also such a skill is assessing your own work, like, after you go down the path or, like, once you have something working, being able to come back to it and look at it and be like, oh, like, can this be better, right? And I think that can only happen once you have something to look at, once you have, like, a first draft, if you will, or do the less optimal implementation or naive implementation.

+ +

JOËL: So, when you're trying to prompt someone to kind of build that skill of self-review or self-reflection on some of the work that they've done, how do you as a pair or a mentor help stimulate that?

+ +

STEPHANIE: Yeah. I think with early career folks, one thing that is an easy way to start the conversation is asking, "Are there any places that could be more readable?" Because that's, I think, an aspect that often gets forgotten because they're trying to hold so much in their heads that they are really just getting the code to work. And I think readability is something that we all kind of understand. It doesn't include any jargon about design patterns that they might not have learned yet. You know, even asking about extracting or refactoring might be not where they are at yet.

+ +

And so, starting with readability, for example, often gets you some of those techniques that we've learned that have, you know, specialized vocabulary. But I have found that it helps meet them where they're at. And then, in time, when they do learn about those things, they can kind of apply what they've already been doing when kind of prompted with that question as, like, oh, it turns out that I was already kind of considering this in just a different form.

+ +

JOËL: And I think one thing that you gain with experience is that you have kind of a live compiler or interpreter of the language in your head. And so, sometimes for more complex code, I, as an experienced developer, can look at it and immediately be like, oh yeah, here's some edge cases where this code isn't going to work that someone newer to the language would not have thought of.

+ +

And so, sometimes the way I like to approach that is either ask about, "Oh, what happens in this scenario?" Or sometimes it's something along the lines of, "Hey, now that we've kind of done the main workflow, there's a couple of edge cases that I want to make sure also work. Let's write out a couple of test cases." So, I'll write a couple of unit tests for edge cases that I know will break the code.

+ +

But even when we write the unit tests, my pair might assume that these tests will pass. And so, we'll write them; we'll run them and be like, "Oh no, look at that. They're red. I wonder why." And, you know, you don't want to do it in a patronizing way. But there's a way to do that that is, I think, really helpful. And then you can talk about, okay, well, why are these things failing? And what do we need to change about the code to make sure that we correctly handle those edge cases?

+ +

STEPHANIE: Yeah, that's really great. And now, they also have learned a technique for figuring out how to move forward when they think there might be some edge cases. They're like, oh, I could write a test, and they end up [laughs] maybe learning how to do TDD along the way. But yeah, offering that strategy, I think, as a supplement to having supported them in their workflow, I think, is a really cool way to both help them learn a different strategy or tactic while also not asking them to, like, completely change the way that they do their development.

+ +

JOËL: So, we've talked about ways that we can coach and mentor in a more of a one-on-one setting. But it can also happen in more of a group setting. And an initiative that I've been involved in recently is, once a quarter, the principals on thoughtbot's Boost team are running a training session on a topic that we choose.

+ +

And we chose this month to make it really interactive. We created an exercise. We talked a little bit about it, had people break out into breakout rooms for a pretty short time—it was like 20 minutes—and come up with a solution. And then brought it back to the big group to talk through some of the solutions. All of that within 45 minutes, so it's a very kind of dense-packed thing. And I think it went really well.

+ +

STEPHANIE: Yeah. So, hearing that makes me think that the group wasn't actually going to get to a solution in necessarily that short amount of time. But I'm wondering if that was maybe intentional. Like it was never really about coming to the optimal solution but just the act of thinking about it or practicing how you would do that problem-solving without as much of a focus on the outcome.

+ +

JOËL: So, yes and no. I think, as you said, the discussion, the journey is more important than the outcome. But also, because we wanted people to have a realistic chance at coming up with some kind of solution, we specifically said, "We don't want code. Don't write a code solution to this." Instead, we suggested people come up with some kind of diagram.

+ +

So, the problem was, we have some sort of business process where you start by...you have an endpoint that needs to receive some kind of shopping cart JSON and then goes through a few different steps. You have to validate it. You have to attempt to charge their card, and then eventually, it has to be sent off to a warehouse to be fulfilled.

+ +

And so, we're asking them to diagram this while thinking a little bit about data modeling and a little bit about potential edge cases and errors. People came up with some really interesting diagrams for this because there's multiple different lenses from which you could approach that problem.

+ +

STEPHANIE: That's cool. I really like that you left it up to the groups to figure out, you know, what kind of tools they wanted to use and the how. You mentioned different lenses. So, I'm taking it that you didn't necessarily share what the steps of starting to consider the data modeling would be. Did you prompt the group in any way? How did you set them up before they broke out?

+ +

JOËL: So, we had a document that had a problem definition; part of this involved talking to a few external services, so things like attempting to charge their card. I think there was a user service they needed to do to pull some user information. And then, there's that fulfillment center that we submit to the warehouse with your completed order. And so, we had sample JSONs for all of these. Again, the goal is not for them to write any code that deals with it but more to think about: okay, we need information from this payload to plug into this one. And then, if they want to add any sort of intermediate steps, they can do that.

+ +

And I think sort of two common lenses that you could look at this is from more of an action standpoint, so to say, okay, well, first, we receive this payload, and then we make a call to this endpoint, and we try to do a thing and then success or failure, and then kind of go down this path and success or failure, and kind of keep going down that path until you finally reach that fulfillment endpoint.

+ +

So, it's almost like a control flow diagram. But you could also take more of a data-centered approach and talk about how the data evolves as it goes through this process. And so, you start with, like, a raw JSON payload. And maybe that gets parsed into a shopping cart object, which then gets turned into a temporary order, which then gets turned into a validated order, which then is combined with a credit card charge to create a fulfillment order, which can then be sent off to the warehouse. And that perspective will completely change the way you think about what the code actually needs to be when you create it.

+ +

STEPHANIE: Got it. That's cool. So, I'm curious, you know, what went into figuring out what the prompt would look like? I guess, like, where did you start? Did you already know that there would be these two different ways of thinking about or lenses to data modeling that you're, like, oh, like, maybe these groups will go down this route? Or was it, I guess, a bit of a surprise that when you came together, you found out kind of the different approaches?

+ +

JOËL: We already knew that there would be multiple approaches, and we chose not to specify which one to take. I think now this is getting into almost like curriculum design and more kind of the pedagogy side of things, which I'm, you know, excited and passionate about. I don't know, is that something that you've done at all for some of your projects or areas where you've been coaching people?

+ +

STEPHANIE: It's not been. But I actually do think it's a bit of a goal of mine to lead a workshop at some point at a conference because I really like the hands-on stuff that I get to do day-to-day, you know, working one-on-one with people. And, you know, I also am on the conference circuit. [laughs] And I was thinking that maybe workshops could be a really cool way to bring together those two things of like, well, I am enjoying that experience of working one-on-one, but it is, oftentimes, you know, just on our regular day-to-day work. And so, I would be really curious about how to develop that kind of curriculum for teaching purposes.

+ +

Do you find yourself starting with problems you see on client work and kind of stripping that down into something maybe a little more general, or do these problems kind of just come up spontaneously? [chuckles]

+ +

JOËL: So, workshop design is, I think, its own really fascinating topic, and honestly, we could probably do a whole episode on it. But the short of it is I typically work backwards from an end goal. So, just like when I'm writing a blog post, I have one big thing I want people to learn from a workshop, and then everything works backwards from there. Anything that is part of the workshop has to be building towards that big goal, that one thing I want people to learn. Otherwise, I strip it out.

+ +

So, it's an exercise in ruthlessly cutting to make sure that I'm not overwhelming people and, you know, that we can fit in the time that we have because there's always not enough time in a workshop. And people can very easily get sidetracked or overwhelmed. So, as much as possible, have everything focusing in towards one goal.

+ +

Circling back to the mentoring side of things, I'm curious what you see is maybe some of the biggest challenges as a mentor or a coach.

+ +

STEPHANIE: Well, I think, for me, it was, in some ways, like, seeing myself in that role as mentor. Like, oftentimes, that was decided for me by someone else as, like, "Oh, hey. We have a new hire, and, like, would you be their onboarding buddy?" Or, you know, a manager kind of identifying, like, oh, like, Stephanie has been in this role for, you know, a few years now. She's surely ready to mentor [laughs] new folks or people joining the team.

+ +

And that was really hard for me because I was like, well, I still have so much to learn [laughs], you know, like, how could I possibly be in that position now? You know, I am still learning from all these other people who are mentors to me.

+ +

So, one thing that took me a long time was learning that I did have things that I knew that other people didn't. And I started to think of it more as this, like, ring of overlapping circles where, you know, we all probably do share some common knowledge. But we all are also experts in different things, and everyone always has something to teach. Even if you're just, like, a few months or, like, a year ahead of someone else, that is actually a really powerful spot to cultivate peer mentorship, and where I think learning can really thrive.

+ +

There's a really great talk about this by Adam Cuppy called Mentorship in Three Acts, where he talks about that peer mentorship, where someone just knows, like, a little more than someone else. That can be really powerful and can be a good entry point for people who are interested in getting into mentorship but are kind of worried that, like, oh, they are, you know, not a senior yet.

+ +

You know, when you're at a similar experience level as who you're working with, there is a little bit less of what we were describing earlier of, like, that dynamic of knowing what to do but kind of wanting to hold back and let them discover for themselves. In that peer mentorship dynamic, you know, both people are, like, really deep in it, kind of trying things out, experimenting, learning, and that ends up being really fruitful time for both of them.

+ +

JOËL: Based on your experience, would you say that maybe that's the best place to start for someone who's looking to get into mentorship, so kind of pursue more of a peer mentorship scenario?

+ +

STEPHANIE: Yeah. I would definitely say that it has helped me a lot. I've had a lot of peer mentorship relationships in the past, where maybe there just wasn't someone on the team who could mentor me at the time. Or maybe I was wanting to collaborate a little bit more and feeling like I did have some ideas and opinions that I wanted to talk about, or share, or get some feedback on. Reaching across my level was really helpful in starting to create that space.

+ +

Yeah, I was really surprised by all the things that I was learning and all the things that the other person was learning from me that I think was a good wealth of experience for me to then bring to the next step when I found myself kind of in that position of supporting others who were more junior.

+ +

JOËL: I'd like to also shout out Exercism.io as a great place to get started with mentoring. For those who are not aware, Exercism is a platform where they have a bunch of exercises that you can go through to learn a language. And you can go through them on your own, but you can also go through them with a mentor. Somebody will basically give you a little mini code review on your exercise or maybe help you out if you're stuck. And this all happens asynchronously.

+ +

And it's volunteer-run. So, they just have people from the community who volunteer to be mentors on there to help coach people through the exercises. We'll put a link in the show notes to the page they have, kind of explaining how the mentorship works and how to sign up. But I did that for a while. And it was a really rewarding experience for me. I thought that I'd be mostly helping and teaching, but honestly, I learned so much as part of the process.

+ +

So, I would strongly recommend that to anybody who wants to maybe dip their toe a little bit in the mentoring coaching world but maybe feels like they're not quite ready for it. I think it's a great way to start.

+ +

STEPHANIE: Ooh, that sounds really cool. Yeah, I know that, especially for folks who maybe are working a little bit more independently, or are a bit isolated, or don't have a lot of people on a team that they're able to access; that sounds like a really great solution for folks who are looking for that kind of support outside of their immediate circle.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+hxEMZen1 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 401: Making the Right Thing Easy + https://bikeshed.thoughtbot.com/401 + 50bac40b-6aa0-4685-bca6-716d9996122f + Tue, 12 Sep 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie has another debugging mystery to share. Earlier this year, Joël mentioned that he was experimenting with a bookmark manager to keep track of helpful and interesting articles. He's happy to report that it's working very well for him! + +Together, they discuss tactics to ensure the easiest route also upholds app health and aids fellow developers. They explore streamlining test fixes over mere re-runs and how to motivate desired actions across teams and individuals. + 31:24 + no + + + Stephanie has another debugging mystery to share. Earlier this year, Joël mentioned that he was experimenting with a bookmark manager to keep track of helpful and interesting articles. He's happy to report that it's working very well for him! +Together, they discuss tactics to ensure the easiest route also upholds app health and aids fellow developers. They explore streamlining test fixes over mere re-runs and how to motivate desired actions across teams and individuals. +Raindrop.io (https://raindrop.io/) +Railway Oriented Programming (https://fsharpforfunandprofit.com/rop/) +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, I have another debugging mystery to share with the group. I was working on a bug fix and was trying to figure out what went wrong with some plain text that we're rendering from a controller with ERB. And I was looking at the ERB file, and I was like, great, like, I see the method in question that I need to go, you know, figure out why it's not returning what we think it's supposed to return. I went down to go check out that method. I read through it ran the tests. +Things were looking all fine and dandy, but I did know that the bug was specific to a particular, I guess, type of the class that the method was being called on, where this type was configured via a column in the database. You know, if it was set to true or not, then that signaled that this was a special thing. You know, I made sure that the test case for that specific type of object was returning what we thought it was supposed to. But strangely, the output in the plain text was different from what our method was returning. +And I was really confused for a while because I thought, surely, it must be the method that is the problem here [laughs]. But it turns out, in our controller, we were actually doing a side effect on that particular type of object if it were the case. So, after it was set to an instance variable, we called another method that essentially overwrote all of its associations and really changed the way that you would interact with that method, right? And that was the source of the bug is that we were expecting the associations to return what we, you know, thought it would, but this side effect was very subvertly changing that behavior. +JOËL: Would it be fair to call this a classic mutation bug? +STEPHANIE: Yeah. I didn't know there was a way to describe that, but that sounds exactly right. It was a classic mutation bug. And I think the assumption that I was making was that the controller code was, hopefully, just pretty straightforward, right? I was thinking, oh, it's just rendering plain text, so not [laughs] much stuff could really be happening in there, and that it must be the method in question that was causing the issues. +But, you know, once I had to revisit that assumption and took a look at the controller code, I was like, oh, that is clearly incorrect. And from there, I was able to spot some, you know, suspicious-looking lines that led me to that line that did the mutation and, ultimately, the answer to our mystery. +JOËL: Was the mutation happening directly in the controller? Or was this a situation where you're passing this object to a method somewhere, and that method, you know, in another object or some other file is doing the mutation on the record that you passed in? +STEPHANIE: Yeah, that's a great question. I think that could have been a very likely situation. But, in this particular case, it was a little more obvious just in the controller code, which was nice, right? Because then I didn't have to go digging into all of these other functions that may or may not be the ones that is doing the mutation. But the thing that was really interesting is that it seems like that method that does this mutating is pretty key to the type of object that we're working with, as in most places it's used, that mutation happens. And yet, it's kind of separated from the construction of that object. +And I was, I think, a little bit surprised that it wasn't super obvious that throughout the application, this is the way that we treat this special object. And I had wished that maybe that was a bit more cohesive or that it was kind of clear that this is how we use this in our domain. And it was, like, lacking that bit of clarity around how things are used in practice as opposed to trying to keep those in isolation. +JOËL: Yeah. Because now you have sort of two different diverging use cases for using this object that are incompatible, one that's trying to use the object as is and the other that's depending on this mutation. Now you can't have both. +STEPHANIE: Right. As far as I can tell, in most cases, you know, we're using it with a mutation, and maybe there is a good reason for those ideas to be separate. But it certainly did not make my life easier trying to solve this particular bug. +JOËL: I'm hearing you mention the idea of ideas being separate; definitely kind of triggers some pathways in my modeling brain, where I'm already thinking, oh, maybe this should be a decorator, or maybe this is just a straight-up transformation. We just have a completely different kind of object rather than mutating the underlying record. +STEPHANIE: Yeah, definitely. I think there could have been some alternative paths taken. At the time, that was kind of decided as the way forward for how to treat this particular domain object. So, that's my fun, little mystery where I got to, you know, play the detective role for a bit. Joël, what's new in your world? +JOËL: So, earlier this year, on an episode of The Bike Shed, I mentioned that I was experimenting with a bookmark manager to kind of keep track of articles that I find are helpful that I might want to reference later on. I wasn't sure if it was going to be worthwhile and mentioned that I'd report back. I'm happy to report that it is working very well for me. +So, the tool is Raindrop.io. They have an app. They have a website. And I have been sort of slowly filling it with some of my most commonly referenced articles. I had pulled some in initially, and then kind of over time, when I find myself referencing an article using my old-fashioned approach, which was just remember the keywords in the title and Google them, now I'll do that, link the article to someone else, and then add it to Raindrop so that the next time I'm starting to look for things, I have these resources available. +And I try to curate a little bit by doing things like tagging them and categorizing them so that when I need references for something, I don't just have to go through my personal memory and be like, oh yeah, what articles do I have on data modeling that I think might be a good fit here? Instead, I can just go to the data modeling section of Raindrop and be like, oh yeah, these five are, like, my favorites that I link to all the time. +STEPHANIE: Wow. We did a whole episode on how to search recently. And we totally forgot to mention things like bookmark managers or curating your own little catalog of go-to articles. In some ways, now you have to search within your bookmark manager [laughs]. +JOËL: That's true. Sometimes, it's searching if I'm looking for a particular article, and sometimes, it's more browsing where I'm looking at a category, or a tag, or something like that, which maybe would have been another interesting distinction to explore on the How to Search episode. +I do want to give a shout-out to the most recent article that I looked up in my bookmark manager here, Railway-Oriented Programming. It's an article on how to deal with pieces of code that can error and how to sort of compose those sorts of methods. So, you now have a whole sort of chain of different functions that can error or not in different sorts of ways. +And it uses this really powerful metaphor of railway with different types of junctions and how you might try to, like, fit them all together so that everything connects nicely. And it's just a really beautiful metaphor. And I was doing some work on error handling, in particular, and I wanted to reference something and that was a great resource for that piece of work. +STEPHANIE: Very cool. I'm really intrigued. I love a good metaphor. I am curious: is this programming language and framework agnostic and not about Rails? +JOËL: Actually, so this is written on an F# blog. So, the code is all in F#. And it leans a little bit into some functional programming concepts, but the metaphor is more generic. So, it's a really fun way to think about when you're programming, and you're not just going through the happy path. But what are all the side branches that you might have to deal with, and how do those side branches come back into the flow of your program? +STEPHANIE: Very cool. I can also see some really excellent visuals here if you were to use this metaphor as a way of understanding complexity. +JOËL: Absolutely. In fact, this article has some pretty amazing visuals, so strong recommend. We'll link it in the show notes. +STEPHANIE: So, a few episodes ago, we talked about code ownership at scale because my client project that I'm working on is for a company with hundreds of developers. So, it's quite a big codebase, quite a big team. One of the main issues that I, at least, struggle with on a day to day is flaky tests in CI. When I, you know, I'm wanting to merge a change, I often have to run the test suite a few times to get to green and be able to merge and deploy. +And this is an interesting topic to me because when you're really trying to just get your changes through and mark that ticket as done, it's very tempting to just hit that, you know, retry button and let it sit and just hope for the best, as opposed to maybe investigate a little further about why that test was flaking and see if there's something that you could do about it. +So, I wanted to talk to you about the idea of making the right thing easy or how, at both a team level and an individual level, we can set ourselves and our team up for success rather than shoulder this burden [laughs] and just assume that things are the way they are. +JOËL: That's a really powerful question. Because I think by default, oftentimes, the less helpful thing is the path of least resistance, so, in this case, hitting that rerun button on a test suite, which I've absolutely done. But there's a lot of other situations in our work where, just sort of by default, the path of least resistance is the thing that's maybe less helpful for the team. +STEPHANIE: Ooh, I noticed that you kind of reframed what I said. I was using the term, you know, the right thing, but you then reworded it into the helpful thing. And that actually gets me thinking about these words are kind of subjective, right? What is helpful to someone could be different to what's helpful to someone else. And I'm kind of curious about your definition of the helpful thing. +JOËL: Yeah, I mean, sometimes it's very easy to sort of bring absolutes and [inaudible 11:26] judgments to code, you know, when we talk about writing good code, and being good programmers, being good at our jobs, not doing the bad things. And I think that sort of absolutism sometimes can, like, be very restrictive, and kind of takes us down paths that are not optimal for ourselves, for our teams, for our products. So, I'd like to think a little bit more relativistically have a little bit more of elasticity in the way that we formulate some of these ideas. +STEPHANIE: Yeah. I really like that reframing, and I appreciate the nuance there. I think for me, when I think of doing the helpful thing, I'm hoping to ease the day-to-day workflow for other developers because that also includes myself, right? Like, I've certainly been there feeling frustrated or just kind of tired of retrying [laughs] the test suite over and over again. +I'm also thinking about helpful, as in what will be helpful for future developers regarding the product? And can we make it robust now so that we're not dealing with bug reports later for things that we maybe we're trying to throw under the rug or just kind of glance over? Do you have any other guiding principles around what is helpful and what's not? +JOËL: I think that the time horizon you mentioned is really interesting because you have to balance sometimes short-term value versus kind of long-term. And is it worth it to maybe not fix that flaky test today so that we can ship as soon as possible? Or is it worth investing a little bit of time today so that tomorrow or next week is better? If you're a solo developer on a tiny project, that might be of personal benefit only. But on a larger team, you know, that might benefit not just you but a larger amount of people. +STEPHANIE: I just imagined the trolley problem [laughs] a little bit about, you know, the future developers and whose lives, not lives but whose happiness, the developer happiness you'll save [laughs] when you're on that track and making the decision about benefit now versus benefit later. +JOËL: No connection to railway-oriented programming, by the way. +STEPHANIE: I am really interested in also talking about barriers to doing the helpful thing or taking that extra step, right? Because I think identifying those barriers is really important to then, hopefully, break them down so that we are creating that path of least resistance. +JOËL: That's interesting that you mentioned these as barriers because I think, in my mind, I was thinking about the same idea but from, like, a completely mirror perspective, the idea of incentives. Why do incentives push you in one way versus the other? +STEPHANIE: I like that a lot. I think maybe there are, like, two different levers, right? Or maybe they are two sides of the same coin, where you do have incentive, and then you also have things that disincentivize you. +JOËL: This reminds me a little bit of the idea of the tragedy of the commons. So, in the case of flaky tests, everybody as a whole on your project has a worse experience. And project velocity slows when there are flaky tests. But you, as an individual developer, are incentivized to ship features quickly and efficiently. And the fastest way you can get your individual feature to production is by hitting that rerun button. Even though, collectively as a whole, every time we do that, instead of fixing the flakiness, we're adding a tiny, little bit of extra slowness that will accrete over time. +STEPHANIE: Yeah. It's kind of difficult to imagine really the negative impact that it's having collectively, right? You're kind of like, oh, I'm feeling this pain, but you're not always, like, really hearing about it from others, and we might just be silently suffering together [laughs]. I do think that once it's been identified as like, oh, like, we're all actually, like, really impacted by this, okay, great, let's make it a priority. +And so, now, let's say I am slightly incentivized to go and investigate the flakiness of a test rather than hit the rerun button this time around. I am wanting to talk about those barriers I was referring to a little bit because I've been in this position where I'm like, okay, like, I have some extra time today. So, why don't I look into this? +But then I go down that path, and now I'm looking at a test written by someone many years ago, you know, I don't know this person, and I don't know this domain. I don't know who to talk to to figure out even where to start. I may or may not feel equipped with the right tools to be able to address it. +And then, I think the biggest challenge is not feeling like it matters, right? Once I'm hitting this barrier, I'm like, is it worth the effort? At that point, maybe a little bit demoralized because, well, this is just one, and we have so many other flaky tests, like, what's one more? +JOËL: That's really interesting that you mentioned that sort of morale factor because it's absolutely the case on every flaky test suite I've seen. I think that kind of points to almost, like, an exponential cost to ignoring the problem. If someone fixed it early, yeah, it's slightly annoying, but you get it done. You fix it, and then you move on. When it feels like there's now this insurmountable pile of these and that any work you do here doesn't bring you any closer to the goal because it's effectively infinite, yeah, now, there is no incentive at all to do that work. +STEPHANIE: So, to avoid that, we talked about incentives, right? And I'm kind of curious: what ways have you seen or experienced that did make you feel motivated to take that extra step or at least try to avoid that point of thinking that nothing matters? [laughs] +JOËL: So, I'm going to start with, I think, what's maybe a classic developer answer, and I'm curious to get your thoughts on it because I think I have very mixed feelings about this. The idea of programmer discipline—we just need to kind of take more pride in our craft and pursue excellence, choose to do the right thing, even when it's hard every day. Because I hear a lot of that in our communities. How do you feel about that sort of maybe a bit of a mindset change? And how effective has that been? +STEPHANIE: Whoa, yeah, that's a really great point because I think I also feel quite conflicted about it. Because sometimes I can find it in myself to be, like, you know, I have the energy today to want to uphold, like, a certain level of quality that would make me feel good about doing my best work. And then, there are other days where I am, you know, just tired, [laughs] or feeling a little bit lazy, feeling just not confident that it will be worth it. Because there's also, I think, some external forces, right? +I've certainly been in the position where we were only rewarded or celebrated for shipping fast. That was the praise we were getting at retros. But then that actually really disincentivized me from wanting to do the helpful thing when the time came, right? When I'm in my development process, and I'm at, like, that crossroads. Because I'm like, well, I've been trying to do the right thing, but, like, no one is celebrating me for it. What if it takes away time from doing the thing that is considered successful? And, like, does it have an impact on me and my job? +So, you can, you know, kind of go down that spiral pretty quickly. And, in that case, like, no amount of personal, like, individual [laughs] feelings of responsibility can really overcome those consequences if, like, you're working on a team where that is just simply not valued, and there are other people who have authority to impart consequences, I suppose. +JOËL: Yeah. It's, you know, you have that maybe some amount of personal motivation. You feel like you're swimming upstream. And so, maybe the question then is, how do we reorient maybe some of the incentive structures in a team to try to make it so that if you are, let's just say, chasing some of those extrinsic rewards and you're trying to get praise from your teammates, or move forward in your career, whatever it is that is rewarded and valued on your team, how can that be harnessed to push people in a direction to get some of these extra tasks done? +STEPHANIE: Yeah. I will say, though, it is a little bit of both. And I think that was maybe why we're both kind of conflicted about it. Because on the individual level and, in general, knowing what my values are and, like, wanting to do good work and uphold quality, there are times where I don't always behave according to those values. Like I said, I am feeling tired, or maybe it's, like, almost 5:00 o'clock, and I just want to, you know, push my thing [laughs] so I can go and go on with my day. +What has helped me is having an accountability buddy. Maybe it's in code review, or maybe it's when I'm pairing, or maybe just talking about a problem that we're facing, right? And I might get into that sort of lizard-brain mentality of just wanting to do the easy thing. But as soon as someone else points it out or is, like, you know, like, "That's not quite aligning with what I know your, like, hopes and goals are for this project or how you want to do your work," usually, that's enough to be like, "Yeah, you're right." [laughs] And I'll take another pass at it. +JOËL: And I think we've kind of come back full circle here in that you mentioned that sort of the lizard brain side of you wants to just do the easy thing with the implication that, in this case, the easy thing is the thing that's maybe not useful to the team long term. What if we could restructure things a little bit so that the easy thing was the most beneficial thing for the team? And now you're not having to use discipline to fight the lizard brain side of you, but you're actually working with it. +One thing I've seen teams do with flaky tests is to not necessarily fix them immediately. Like, maybe you do rerun them, but when they happen, create a ticket for them and put them into the planning board. And so, now, these are things that get prioritized. They're things that might be fairly quick to do. So, it might be a fun, like, fast ticket for someone to pick up at the end of the week. It now counts towards velocity if tracked, so people, hopefully, get rewarded for doing that work. Is that something that you've seen? And how effective do you think that is in maybe making fixing flaky tests easier thing for a team? +STEPHANIE: Yeah, that is actually something that we are doing on my team right now, and I think it's great. I like the idea of tracking it, right? Because then you could also see over time, like, whether we have been getting better at reducing flaky tests, you know, then it's also really clear when someone is preoccupied with that work, and they don't get assigned something else. +One way that I've seen it not work as well as we hoped is when other work consistently gets prioritized over those flaky test tickets, and, you know, sometimes it happens. I think that's also information, though, about the team and how the team is spending its time compared to how the team thinks it should be ideally spending its time where, you know, we can say all we want, like, yes, like, we really want to make sure our test suite is robust. But when other things are consistently getting prioritized over it, then you can point to it and say, do we actually believe this if we're consistently not behaving according to that belief? +I found that challenging to have that conversation. But I do think that the concreteness of adding it to our workload for a given period of time is at least providing information rather than it being things that, like, developers are doing one-off or kind of just on their own time. +JOËL: Another solution that I've seen people do, and this is a classic developer solution, is tooling. If you have better tooling around a particular problem, sometimes you can shift that cost, that time of work it takes so that it's easier to do the best thing rather than to not...or at least make it easy enough that it's less of a big decision, like, oh, do I really want to invest that much work into something? +And a classic example of this, I think, is when you're trying to get into more of a test-driven development workflow. Having a test suite that's fast and, really importantly, having a near-instant way to run a test from your code editor makes a big difference in terms of adopting that workflow. +Because if the cost of running a test is too high, then yeah, the easy path is to just say, you know what? I'm not going to run a test. I'm going to just run it once at the end after I've written 100 lines of code or an entire feature. And now I am not getting the benefits of TDD. And that might kind of get into a negative cycle where because I'm not seeing the benefits, I do it even less. And then eventually, I'm just, like, you know what? Forget this whole thing. +STEPHANIE: I think that also applies to testing in general, where if it, you know, is feeling really challenging. I have definitely seen people start to get into that mindset of, is this worth my time to do at all? And it's a very slippery slope, I think. +That almost makes me think about, like, okay, like, what are some other ways to lift that task up and to elevate it into something that's worthy of saying, like, "Hey, like, that was really hard, and you did a great job. And that was really awesome that you persevered through that challenging thing." Sharing the pain points is really important, not only to, like I mentioned earlier, to, like, communicate that, oh, maybe, like, more people than you think are going through the same thing, but also to be able to identify when someone went out of their way to do the helpful thing and seeing that someone was willing to do it because, for them, being helpful is important. +When I see someone on my team take on kind of a difficult task to make things easier for others and then share about it, I feel really inspired because I think, wow, like, that could be me as well. You know, there's that saying that many hands make light work. And I also think that's true of tackling these kinds of barriers, where if we all feel this collective responsibility or, like, wanting to help out the group, it ends up literally being easier. +JOËL: I think something I'm hearing here as well is the value of giving praise. If somebody goes out of their way to make life easier for the rest of your team, give them a shout-out, whether that's in your team's Slack channel, maybe it's at an all-hands meeting, and you shout out some work that they've done or, you know, you put their name on a slide in your slide deck at some point, or whatever it is the mechanism within your team. Having a way to shout out people who've done some of this work that can be sometimes a little bit thankless is a great way to motivate seeing more of that. +STEPHANIE: Yeah. I was just thinking that it can be really powerful because, like you said, a lot of it is thankless, but also, we may not even realize the impact it's having on others until you give that shout-out and express, like, "Wow, like, that change, you know, I've been bothered by this issue for so long and, you know, that really made an impact on me," just keeping that cycle of gratitude going. +JOËL: So, I think we've kind of identified three maybe main areas of ways where you can help to incentivize these behaviors. You can do it through kind of process. We talked about the example of pulling the flaky tests as actual cards to be worked through on a board. +It can be technical by introducing some tooling that makes it much easier to do the work that you're trying to do. +And it can be personal by praising people, preferably in public, for taking that extra step. And I think all three of those can be part of a strategy to make it easier or more attractive for people to do work that benefits the team as a whole, even if they don't see an immediate return to that on a per-day level. +STEPHANIE: Yeah. I like that we kind of talked about these three different categories. And people in all different types of roles can, hopefully, take something from what we've shared, right? If you are a manager or leader of a team, maybe you can investigate your processes. If you're an individual contributor and you notice your colleague doing something that you, you know, kept meaning to but just didn't have time for, recognize that work. It really does take a holistic approach, but I think an impact can be made at every level. +JOËL: Agreed. I think for managers and more senior team members, that's really almost, like, part of their job description is to think about these kinds of things. How can we incentivize this work? How can we shift the team in a particular direction? There's a particular onus on them to do this right, to think about this, to model some of this behavior. +STEPHANIE: Yeah, absolutely. +JOËL: For someone who's really senior on a team also, they're often the ones who are tasked or who maybe take the initiative to build some of this more complex tooling so that these tasks are easier for more junior people. Maybe that's tinkering with some things and building an editor plugin that makes it easier to do some work. Maybe it's building a Rails generator so that the proper files get generated that maybe people wouldn't think to have when they're building certain work. Maybe it's building an RSpec matcher to make it easier for people to test some of the nuances of what we're hoping to do, catching some of these edge cases. +Whatever it is, sometimes there are things that the more junior members of our teams aren't aware of, and having a senior person take time out of their day to build these things so that now the entire team can be more productive can be a really helpful thing to do. +STEPHANIE: Yeah, that's a great point. And I think that also comes from having a pulse on what people are struggling with, right? So, you know, oh, it would be good to invest my energy into building a script to make this manual process easier because I keep hearing about people having issues with it or it being a challenge. +So, I would even recommend posing the question of, like, how do people feel about being able to fix that flaky test, right? Like, is it intimidating? What are those barriers? Because your team knows best about what that experience is like. And if that is not something on your radar, maybe there are opportunities to incorporate it into where you're evaluating team morale and happiness. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie has another debugging mystery to share. Earlier this year, Joël mentioned that he was experimenting with a bookmark manager to keep track of helpful and interesting articles. He's happy to report that it's working very well for him!

+ +

Together, they discuss tactics to ensure the easiest route also upholds app health and aids fellow developers. They explore streamlining test fixes over mere re-runs and how to motivate desired actions across teams and individuals.

+ +
+ + + +

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, I have another debugging mystery to share with the group. I was working on a bug fix and was trying to figure out what went wrong with some plain text that we're rendering from a controller with ERB. And I was looking at the ERB file, and I was like, great, like, I see the method in question that I need to go, you know, figure out why it's not returning what we think it's supposed to return. I went down to go check out that method. I read through it ran the tests.

+ +

Things were looking all fine and dandy, but I did know that the bug was specific to a particular, I guess, type of the class that the method was being called on, where this type was configured via a column in the database. You know, if it was set to true or not, then that signaled that this was a special thing. You know, I made sure that the test case for that specific type of object was returning what we thought it was supposed to. But strangely, the output in the plain text was different from what our method was returning.

+ +

And I was really confused for a while because I thought, surely, it must be the method that is the problem here [laughs]. But it turns out, in our controller, we were actually doing a side effect on that particular type of object if it were the case. So, after it was set to an instance variable, we called another method that essentially overwrote all of its associations and really changed the way that you would interact with that method, right? And that was the source of the bug is that we were expecting the associations to return what we, you know, thought it would, but this side effect was very subvertly changing that behavior.

+ +

JOËL: Would it be fair to call this a classic mutation bug?

+ +

STEPHANIE: Yeah. I didn't know there was a way to describe that, but that sounds exactly right. It was a classic mutation bug. And I think the assumption that I was making was that the controller code was, hopefully, just pretty straightforward, right? I was thinking, oh, it's just rendering plain text, so not [laughs] much stuff could really be happening in there, and that it must be the method in question that was causing the issues.

+ +

But, you know, once I had to revisit that assumption and took a look at the controller code, I was like, oh, that is clearly incorrect. And from there, I was able to spot some, you know, suspicious-looking lines that led me to that line that did the mutation and, ultimately, the answer to our mystery.

+ +

JOËL: Was the mutation happening directly in the controller? Or was this a situation where you're passing this object to a method somewhere, and that method, you know, in another object or some other file is doing the mutation on the record that you passed in?

+ +

STEPHANIE: Yeah, that's a great question. I think that could have been a very likely situation. But, in this particular case, it was a little more obvious just in the controller code, which was nice, right? Because then I didn't have to go digging into all of these other functions that may or may not be the ones that is doing the mutation. But the thing that was really interesting is that it seems like that method that does this mutating is pretty key to the type of object that we're working with, as in most places it's used, that mutation happens. And yet, it's kind of separated from the construction of that object.

+ +

And I was, I think, a little bit surprised that it wasn't super obvious that throughout the application, this is the way that we treat this special object. And I had wished that maybe that was a bit more cohesive or that it was kind of clear that this is how we use this in our domain. And it was, like, lacking that bit of clarity around how things are used in practice as opposed to trying to keep those in isolation.

+ +

JOËL: Yeah. Because now you have sort of two different diverging use cases for using this object that are incompatible, one that's trying to use the object as is and the other that's depending on this mutation. Now you can't have both.

+ +

STEPHANIE: Right. As far as I can tell, in most cases, you know, we're using it with a mutation, and maybe there is a good reason for those ideas to be separate. But it certainly did not make my life easier trying to solve this particular bug.

+ +

JOËL: I'm hearing you mention the idea of ideas being separate; definitely kind of triggers some pathways in my modeling brain, where I'm already thinking, oh, maybe this should be a decorator, or maybe this is just a straight-up transformation. We just have a completely different kind of object rather than mutating the underlying record.

+ +

STEPHANIE: Yeah, definitely. I think there could have been some alternative paths taken. At the time, that was kind of decided as the way forward for how to treat this particular domain object. So, that's my fun, little mystery where I got to, you know, play the detective role for a bit. Joël, what's new in your world?

+ +

JOËL: So, earlier this year, on an episode of The Bike Shed, I mentioned that I was experimenting with a bookmark manager to kind of keep track of articles that I find are helpful that I might want to reference later on. I wasn't sure if it was going to be worthwhile and mentioned that I'd report back. I'm happy to report that it is working very well for me.

+ +

So, the tool is Raindrop.io. They have an app. They have a website. And I have been sort of slowly filling it with some of my most commonly referenced articles. I had pulled some in initially, and then kind of over time, when I find myself referencing an article using my old-fashioned approach, which was just remember the keywords in the title and Google them, now I'll do that, link the article to someone else, and then add it to Raindrop so that the next time I'm starting to look for things, I have these resources available.

+ +

And I try to curate a little bit by doing things like tagging them and categorizing them so that when I need references for something, I don't just have to go through my personal memory and be like, oh yeah, what articles do I have on data modeling that I think might be a good fit here? Instead, I can just go to the data modeling section of Raindrop and be like, oh yeah, these five are, like, my favorites that I link to all the time.

+ +

STEPHANIE: Wow. We did a whole episode on how to search recently. And we totally forgot to mention things like bookmark managers or curating your own little catalog of go-to articles. In some ways, now you have to search within your bookmark manager [laughs].

+ +

JOËL: That's true. Sometimes, it's searching if I'm looking for a particular article, and sometimes, it's more browsing where I'm looking at a category, or a tag, or something like that, which maybe would have been another interesting distinction to explore on the How to Search episode.

+ +

I do want to give a shout-out to the most recent article that I looked up in my bookmark manager here, Railway-Oriented Programming. It's an article on how to deal with pieces of code that can error and how to sort of compose those sorts of methods. So, you now have a whole sort of chain of different functions that can error or not in different sorts of ways.

+ +

And it uses this really powerful metaphor of railway with different types of junctions and how you might try to, like, fit them all together so that everything connects nicely. And it's just a really beautiful metaphor. And I was doing some work on error handling, in particular, and I wanted to reference something and that was a great resource for that piece of work.

+ +

STEPHANIE: Very cool. I'm really intrigued. I love a good metaphor. I am curious: is this programming language and framework agnostic and not about Rails?

+ +

JOËL: Actually, so this is written on an F# blog. So, the code is all in F#. And it leans a little bit into some functional programming concepts, but the metaphor is more generic. So, it's a really fun way to think about when you're programming, and you're not just going through the happy path. But what are all the side branches that you might have to deal with, and how do those side branches come back into the flow of your program?

+ +

STEPHANIE: Very cool. I can also see some really excellent visuals here if you were to use this metaphor as a way of understanding complexity.

+ +

JOËL: Absolutely. In fact, this article has some pretty amazing visuals, so strong recommend. We'll link it in the show notes.

+ +

STEPHANIE: So, a few episodes ago, we talked about code ownership at scale because my client project that I'm working on is for a company with hundreds of developers. So, it's quite a big codebase, quite a big team. One of the main issues that I, at least, struggle with on a day to day is flaky tests in CI. When I, you know, I'm wanting to merge a change, I often have to run the test suite a few times to get to green and be able to merge and deploy.

+ +

And this is an interesting topic to me because when you're really trying to just get your changes through and mark that ticket as done, it's very tempting to just hit that, you know, retry button and let it sit and just hope for the best, as opposed to maybe investigate a little further about why that test was flaking and see if there's something that you could do about it.

+ +

So, I wanted to talk to you about the idea of making the right thing easy or how, at both a team level and an individual level, we can set ourselves and our team up for success rather than shoulder this burden [laughs] and just assume that things are the way they are.

+ +

JOËL: That's a really powerful question. Because I think by default, oftentimes, the less helpful thing is the path of least resistance, so, in this case, hitting that rerun button on a test suite, which I've absolutely done. But there's a lot of other situations in our work where, just sort of by default, the path of least resistance is the thing that's maybe less helpful for the team.

+ +

STEPHANIE: Ooh, I noticed that you kind of reframed what I said. I was using the term, you know, the right thing, but you then reworded it into the helpful thing. And that actually gets me thinking about these words are kind of subjective, right? What is helpful to someone could be different to what's helpful to someone else. And I'm kind of curious about your definition of the helpful thing.

+ +

JOËL: Yeah, I mean, sometimes it's very easy to sort of bring absolutes and [inaudible 11:26] judgments to code, you know, when we talk about writing good code, and being good programmers, being good at our jobs, not doing the bad things. And I think that sort of absolutism sometimes can, like, be very restrictive, and kind of takes us down paths that are not optimal for ourselves, for our teams, for our products. So, I'd like to think a little bit more relativistically have a little bit more of elasticity in the way that we formulate some of these ideas.

+ +

STEPHANIE: Yeah. I really like that reframing, and I appreciate the nuance there. I think for me, when I think of doing the helpful thing, I'm hoping to ease the day-to-day workflow for other developers because that also includes myself, right? Like, I've certainly been there feeling frustrated or just kind of tired of retrying [laughs] the test suite over and over again.

+ +

I'm also thinking about helpful, as in what will be helpful for future developers regarding the product? And can we make it robust now so that we're not dealing with bug reports later for things that we maybe we're trying to throw under the rug or just kind of glance over? Do you have any other guiding principles around what is helpful and what's not?

+ +

JOËL: I think that the time horizon you mentioned is really interesting because you have to balance sometimes short-term value versus kind of long-term. And is it worth it to maybe not fix that flaky test today so that we can ship as soon as possible? Or is it worth investing a little bit of time today so that tomorrow or next week is better? If you're a solo developer on a tiny project, that might be of personal benefit only. But on a larger team, you know, that might benefit not just you but a larger amount of people.

+ +

STEPHANIE: I just imagined the trolley problem [laughs] a little bit about, you know, the future developers and whose lives, not lives but whose happiness, the developer happiness you'll save [laughs] when you're on that track and making the decision about benefit now versus benefit later.

+ +

JOËL: No connection to railway-oriented programming, by the way.

+ +

STEPHANIE: I am really interested in also talking about barriers to doing the helpful thing or taking that extra step, right? Because I think identifying those barriers is really important to then, hopefully, break them down so that we are creating that path of least resistance.

+ +

JOËL: That's interesting that you mentioned these as barriers because I think, in my mind, I was thinking about the same idea but from, like, a completely mirror perspective, the idea of incentives. Why do incentives push you in one way versus the other?

+ +

STEPHANIE: I like that a lot. I think maybe there are, like, two different levers, right? Or maybe they are two sides of the same coin, where you do have incentive, and then you also have things that disincentivize you.

+ +

JOËL: This reminds me a little bit of the idea of the tragedy of the commons. So, in the case of flaky tests, everybody as a whole on your project has a worse experience. And project velocity slows when there are flaky tests. But you, as an individual developer, are incentivized to ship features quickly and efficiently. And the fastest way you can get your individual feature to production is by hitting that rerun button. Even though, collectively as a whole, every time we do that, instead of fixing the flakiness, we're adding a tiny, little bit of extra slowness that will accrete over time.

+ +

STEPHANIE: Yeah. It's kind of difficult to imagine really the negative impact that it's having collectively, right? You're kind of like, oh, I'm feeling this pain, but you're not always, like, really hearing about it from others, and we might just be silently suffering together [laughs]. I do think that once it's been identified as like, oh, like, we're all actually, like, really impacted by this, okay, great, let's make it a priority.

+ +

And so, now, let's say I am slightly incentivized to go and investigate the flakiness of a test rather than hit the rerun button this time around. I am wanting to talk about those barriers I was referring to a little bit because I've been in this position where I'm like, okay, like, I have some extra time today. So, why don't I look into this?

+ +

But then I go down that path, and now I'm looking at a test written by someone many years ago, you know, I don't know this person, and I don't know this domain. I don't know who to talk to to figure out even where to start. I may or may not feel equipped with the right tools to be able to address it.

+ +

And then, I think the biggest challenge is not feeling like it matters, right? Once I'm hitting this barrier, I'm like, is it worth the effort? At that point, maybe a little bit demoralized because, well, this is just one, and we have so many other flaky tests, like, what's one more?

+ +

JOËL: That's really interesting that you mentioned that sort of morale factor because it's absolutely the case on every flaky test suite I've seen. I think that kind of points to almost, like, an exponential cost to ignoring the problem. If someone fixed it early, yeah, it's slightly annoying, but you get it done. You fix it, and then you move on. When it feels like there's now this insurmountable pile of these and that any work you do here doesn't bring you any closer to the goal because it's effectively infinite, yeah, now, there is no incentive at all to do that work.

+ +

STEPHANIE: So, to avoid that, we talked about incentives, right? And I'm kind of curious: what ways have you seen or experienced that did make you feel motivated to take that extra step or at least try to avoid that point of thinking that nothing matters? [laughs]

+ +

JOËL: So, I'm going to start with, I think, what's maybe a classic developer answer, and I'm curious to get your thoughts on it because I think I have very mixed feelings about this. The idea of programmer discipline—we just need to kind of take more pride in our craft and pursue excellence, choose to do the right thing, even when it's hard every day. Because I hear a lot of that in our communities. How do you feel about that sort of maybe a bit of a mindset change? And how effective has that been?

+ +

STEPHANIE: Whoa, yeah, that's a really great point because I think I also feel quite conflicted about it. Because sometimes I can find it in myself to be, like, you know, I have the energy today to want to uphold, like, a certain level of quality that would make me feel good about doing my best work. And then, there are other days where I am, you know, just tired, [laughs] or feeling a little bit lazy, feeling just not confident that it will be worth it. Because there's also, I think, some external forces, right?

+ +

I've certainly been in the position where we were only rewarded or celebrated for shipping fast. That was the praise we were getting at retros. But then that actually really disincentivized me from wanting to do the helpful thing when the time came, right? When I'm in my development process, and I'm at, like, that crossroads. Because I'm like, well, I've been trying to do the right thing, but, like, no one is celebrating me for it. What if it takes away time from doing the thing that is considered successful? And, like, does it have an impact on me and my job?

+ +

So, you can, you know, kind of go down that spiral pretty quickly. And, in that case, like, no amount of personal, like, individual [laughs] feelings of responsibility can really overcome those consequences if, like, you're working on a team where that is just simply not valued, and there are other people who have authority to impart consequences, I suppose.

+ +

JOËL: Yeah. It's, you know, you have that maybe some amount of personal motivation. You feel like you're swimming upstream. And so, maybe the question then is, how do we reorient maybe some of the incentive structures in a team to try to make it so that if you are, let's just say, chasing some of those extrinsic rewards and you're trying to get praise from your teammates, or move forward in your career, whatever it is that is rewarded and valued on your team, how can that be harnessed to push people in a direction to get some of these extra tasks done?

+ +

STEPHANIE: Yeah. I will say, though, it is a little bit of both. And I think that was maybe why we're both kind of conflicted about it. Because on the individual level and, in general, knowing what my values are and, like, wanting to do good work and uphold quality, there are times where I don't always behave according to those values. Like I said, I am feeling tired, or maybe it's, like, almost 5:00 o'clock, and I just want to, you know, push my thing [laughs] so I can go and go on with my day.

+ +

What has helped me is having an accountability buddy. Maybe it's in code review, or maybe it's when I'm pairing, or maybe just talking about a problem that we're facing, right? And I might get into that sort of lizard-brain mentality of just wanting to do the easy thing. But as soon as someone else points it out or is, like, you know, like, "That's not quite aligning with what I know your, like, hopes and goals are for this project or how you want to do your work," usually, that's enough to be like, "Yeah, you're right." [laughs] And I'll take another pass at it.

+ +

JOËL: And I think we've kind of come back full circle here in that you mentioned that sort of the lizard brain side of you wants to just do the easy thing with the implication that, in this case, the easy thing is the thing that's maybe not useful to the team long term. What if we could restructure things a little bit so that the easy thing was the most beneficial thing for the team? And now you're not having to use discipline to fight the lizard brain side of you, but you're actually working with it.

+ +

One thing I've seen teams do with flaky tests is to not necessarily fix them immediately. Like, maybe you do rerun them, but when they happen, create a ticket for them and put them into the planning board. And so, now, these are things that get prioritized. They're things that might be fairly quick to do. So, it might be a fun, like, fast ticket for someone to pick up at the end of the week. It now counts towards velocity if tracked, so people, hopefully, get rewarded for doing that work. Is that something that you've seen? And how effective do you think that is in maybe making fixing flaky tests easier thing for a team?

+ +

STEPHANIE: Yeah, that is actually something that we are doing on my team right now, and I think it's great. I like the idea of tracking it, right? Because then you could also see over time, like, whether we have been getting better at reducing flaky tests, you know, then it's also really clear when someone is preoccupied with that work, and they don't get assigned something else.

+ +

One way that I've seen it not work as well as we hoped is when other work consistently gets prioritized over those flaky test tickets, and, you know, sometimes it happens. I think that's also information, though, about the team and how the team is spending its time compared to how the team thinks it should be ideally spending its time where, you know, we can say all we want, like, yes, like, we really want to make sure our test suite is robust. But when other things are consistently getting prioritized over it, then you can point to it and say, do we actually believe this if we're consistently not behaving according to that belief?

+ +

I found that challenging to have that conversation. But I do think that the concreteness of adding it to our workload for a given period of time is at least providing information rather than it being things that, like, developers are doing one-off or kind of just on their own time.

+ +

JOËL: Another solution that I've seen people do, and this is a classic developer solution, is tooling. If you have better tooling around a particular problem, sometimes you can shift that cost, that time of work it takes so that it's easier to do the best thing rather than to not...or at least make it easy enough that it's less of a big decision, like, oh, do I really want to invest that much work into something?

+ +

And a classic example of this, I think, is when you're trying to get into more of a test-driven development workflow. Having a test suite that's fast and, really importantly, having a near-instant way to run a test from your code editor makes a big difference in terms of adopting that workflow.

+ +

Because if the cost of running a test is too high, then yeah, the easy path is to just say, you know what? I'm not going to run a test. I'm going to just run it once at the end after I've written 100 lines of code or an entire feature. And now I am not getting the benefits of TDD. And that might kind of get into a negative cycle where because I'm not seeing the benefits, I do it even less. And then eventually, I'm just, like, you know what? Forget this whole thing.

+ +

STEPHANIE: I think that also applies to testing in general, where if it, you know, is feeling really challenging. I have definitely seen people start to get into that mindset of, is this worth my time to do at all? And it's a very slippery slope, I think.

+ +

That almost makes me think about, like, okay, like, what are some other ways to lift that task up and to elevate it into something that's worthy of saying, like, "Hey, like, that was really hard, and you did a great job. And that was really awesome that you persevered through that challenging thing." Sharing the pain points is really important, not only to, like I mentioned earlier, to, like, communicate that, oh, maybe, like, more people than you think are going through the same thing, but also to be able to identify when someone went out of their way to do the helpful thing and seeing that someone was willing to do it because, for them, being helpful is important.

+ +

When I see someone on my team take on kind of a difficult task to make things easier for others and then share about it, I feel really inspired because I think, wow, like, that could be me as well. You know, there's that saying that many hands make light work. And I also think that's true of tackling these kinds of barriers, where if we all feel this collective responsibility or, like, wanting to help out the group, it ends up literally being easier.

+ +

JOËL: I think something I'm hearing here as well is the value of giving praise. If somebody goes out of their way to make life easier for the rest of your team, give them a shout-out, whether that's in your team's Slack channel, maybe it's at an all-hands meeting, and you shout out some work that they've done or, you know, you put their name on a slide in your slide deck at some point, or whatever it is the mechanism within your team. Having a way to shout out people who've done some of this work that can be sometimes a little bit thankless is a great way to motivate seeing more of that.

+ +

STEPHANIE: Yeah. I was just thinking that it can be really powerful because, like you said, a lot of it is thankless, but also, we may not even realize the impact it's having on others until you give that shout-out and express, like, "Wow, like, that change, you know, I've been bothered by this issue for so long and, you know, that really made an impact on me," just keeping that cycle of gratitude going.

+ +

JOËL: So, I think we've kind of identified three maybe main areas of ways where you can help to incentivize these behaviors. You can do it through kind of process. We talked about the example of pulling the flaky tests as actual cards to be worked through on a board.

+ +

It can be technical by introducing some tooling that makes it much easier to do the work that you're trying to do.

+ +

And it can be personal by praising people, preferably in public, for taking that extra step. And I think all three of those can be part of a strategy to make it easier or more attractive for people to do work that benefits the team as a whole, even if they don't see an immediate return to that on a per-day level.

+ +

STEPHANIE: Yeah. I like that we kind of talked about these three different categories. And people in all different types of roles can, hopefully, take something from what we've shared, right? If you are a manager or leader of a team, maybe you can investigate your processes. If you're an individual contributor and you notice your colleague doing something that you, you know, kept meaning to but just didn't have time for, recognize that work. It really does take a holistic approach, but I think an impact can be made at every level.

+ +

JOËL: Agreed. I think for managers and more senior team members, that's really almost, like, part of their job description is to think about these kinds of things. How can we incentivize this work? How can we shift the team in a particular direction? There's a particular onus on them to do this right, to think about this, to model some of this behavior.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: For someone who's really senior on a team also, they're often the ones who are tasked or who maybe take the initiative to build some of this more complex tooling so that these tasks are easier for more junior people. Maybe that's tinkering with some things and building an editor plugin that makes it easier to do some work. Maybe it's building a Rails generator so that the proper files get generated that maybe people wouldn't think to have when they're building certain work. Maybe it's building an RSpec matcher to make it easier for people to test some of the nuances of what we're hoping to do, catching some of these edge cases.

+ +

Whatever it is, sometimes there are things that the more junior members of our teams aren't aware of, and having a senior person take time out of their day to build these things so that now the entire team can be more productive can be a really helpful thing to do.

+ +

STEPHANIE: Yeah, that's a great point. And I think that also comes from having a pulse on what people are struggling with, right? So, you know, oh, it would be good to invest my energy into building a script to make this manual process easier because I keep hearing about people having issues with it or it being a challenge.

+ +

So, I would even recommend posing the question of, like, how do people feel about being able to fix that flaky test, right? Like, is it intimidating? What are those barriers? Because your team knows best about what that experience is like. And if that is not something on your radar, maybe there are opportunities to incorporate it into where you're evaluating team morale and happiness.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie has another debugging mystery to share. Earlier this year, Joël mentioned that he was experimenting with a bookmark manager to keep track of helpful and interesting articles. He's happy to report that it's working very well for him!

+ +

Together, they discuss tactics to ensure the easiest route also upholds app health and aids fellow developers. They explore streamlining test fixes over mere re-runs and how to motivate desired actions across teams and individuals.

+ +
+ + + +

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, I have another debugging mystery to share with the group. I was working on a bug fix and was trying to figure out what went wrong with some plain text that we're rendering from a controller with ERB. And I was looking at the ERB file, and I was like, great, like, I see the method in question that I need to go, you know, figure out why it's not returning what we think it's supposed to return. I went down to go check out that method. I read through it ran the tests.

+ +

Things were looking all fine and dandy, but I did know that the bug was specific to a particular, I guess, type of the class that the method was being called on, where this type was configured via a column in the database. You know, if it was set to true or not, then that signaled that this was a special thing. You know, I made sure that the test case for that specific type of object was returning what we thought it was supposed to. But strangely, the output in the plain text was different from what our method was returning.

+ +

And I was really confused for a while because I thought, surely, it must be the method that is the problem here [laughs]. But it turns out, in our controller, we were actually doing a side effect on that particular type of object if it were the case. So, after it was set to an instance variable, we called another method that essentially overwrote all of its associations and really changed the way that you would interact with that method, right? And that was the source of the bug is that we were expecting the associations to return what we, you know, thought it would, but this side effect was very subvertly changing that behavior.

+ +

JOËL: Would it be fair to call this a classic mutation bug?

+ +

STEPHANIE: Yeah. I didn't know there was a way to describe that, but that sounds exactly right. It was a classic mutation bug. And I think the assumption that I was making was that the controller code was, hopefully, just pretty straightforward, right? I was thinking, oh, it's just rendering plain text, so not [laughs] much stuff could really be happening in there, and that it must be the method in question that was causing the issues.

+ +

But, you know, once I had to revisit that assumption and took a look at the controller code, I was like, oh, that is clearly incorrect. And from there, I was able to spot some, you know, suspicious-looking lines that led me to that line that did the mutation and, ultimately, the answer to our mystery.

+ +

JOËL: Was the mutation happening directly in the controller? Or was this a situation where you're passing this object to a method somewhere, and that method, you know, in another object or some other file is doing the mutation on the record that you passed in?

+ +

STEPHANIE: Yeah, that's a great question. I think that could have been a very likely situation. But, in this particular case, it was a little more obvious just in the controller code, which was nice, right? Because then I didn't have to go digging into all of these other functions that may or may not be the ones that is doing the mutation. But the thing that was really interesting is that it seems like that method that does this mutating is pretty key to the type of object that we're working with, as in most places it's used, that mutation happens. And yet, it's kind of separated from the construction of that object.

+ +

And I was, I think, a little bit surprised that it wasn't super obvious that throughout the application, this is the way that we treat this special object. And I had wished that maybe that was a bit more cohesive or that it was kind of clear that this is how we use this in our domain. And it was, like, lacking that bit of clarity around how things are used in practice as opposed to trying to keep those in isolation.

+ +

JOËL: Yeah. Because now you have sort of two different diverging use cases for using this object that are incompatible, one that's trying to use the object as is and the other that's depending on this mutation. Now you can't have both.

+ +

STEPHANIE: Right. As far as I can tell, in most cases, you know, we're using it with a mutation, and maybe there is a good reason for those ideas to be separate. But it certainly did not make my life easier trying to solve this particular bug.

+ +

JOËL: I'm hearing you mention the idea of ideas being separate; definitely kind of triggers some pathways in my modeling brain, where I'm already thinking, oh, maybe this should be a decorator, or maybe this is just a straight-up transformation. We just have a completely different kind of object rather than mutating the underlying record.

+ +

STEPHANIE: Yeah, definitely. I think there could have been some alternative paths taken. At the time, that was kind of decided as the way forward for how to treat this particular domain object. So, that's my fun, little mystery where I got to, you know, play the detective role for a bit. Joël, what's new in your world?

+ +

JOËL: So, earlier this year, on an episode of The Bike Shed, I mentioned that I was experimenting with a bookmark manager to kind of keep track of articles that I find are helpful that I might want to reference later on. I wasn't sure if it was going to be worthwhile and mentioned that I'd report back. I'm happy to report that it is working very well for me.

+ +

So, the tool is Raindrop.io. They have an app. They have a website. And I have been sort of slowly filling it with some of my most commonly referenced articles. I had pulled some in initially, and then kind of over time, when I find myself referencing an article using my old-fashioned approach, which was just remember the keywords in the title and Google them, now I'll do that, link the article to someone else, and then add it to Raindrop so that the next time I'm starting to look for things, I have these resources available.

+ +

And I try to curate a little bit by doing things like tagging them and categorizing them so that when I need references for something, I don't just have to go through my personal memory and be like, oh yeah, what articles do I have on data modeling that I think might be a good fit here? Instead, I can just go to the data modeling section of Raindrop and be like, oh yeah, these five are, like, my favorites that I link to all the time.

+ +

STEPHANIE: Wow. We did a whole episode on how to search recently. And we totally forgot to mention things like bookmark managers or curating your own little catalog of go-to articles. In some ways, now you have to search within your bookmark manager [laughs].

+ +

JOËL: That's true. Sometimes, it's searching if I'm looking for a particular article, and sometimes, it's more browsing where I'm looking at a category, or a tag, or something like that, which maybe would have been another interesting distinction to explore on the How to Search episode.

+ +

I do want to give a shout-out to the most recent article that I looked up in my bookmark manager here, Railway-Oriented Programming. It's an article on how to deal with pieces of code that can error and how to sort of compose those sorts of methods. So, you now have a whole sort of chain of different functions that can error or not in different sorts of ways.

+ +

And it uses this really powerful metaphor of railway with different types of junctions and how you might try to, like, fit them all together so that everything connects nicely. And it's just a really beautiful metaphor. And I was doing some work on error handling, in particular, and I wanted to reference something and that was a great resource for that piece of work.

+ +

STEPHANIE: Very cool. I'm really intrigued. I love a good metaphor. I am curious: is this programming language and framework agnostic and not about Rails?

+ +

JOËL: Actually, so this is written on an F# blog. So, the code is all in F#. And it leans a little bit into some functional programming concepts, but the metaphor is more generic. So, it's a really fun way to think about when you're programming, and you're not just going through the happy path. But what are all the side branches that you might have to deal with, and how do those side branches come back into the flow of your program?

+ +

STEPHANIE: Very cool. I can also see some really excellent visuals here if you were to use this metaphor as a way of understanding complexity.

+ +

JOËL: Absolutely. In fact, this article has some pretty amazing visuals, so strong recommend. We'll link it in the show notes.

+ +

STEPHANIE: So, a few episodes ago, we talked about code ownership at scale because my client project that I'm working on is for a company with hundreds of developers. So, it's quite a big codebase, quite a big team. One of the main issues that I, at least, struggle with on a day to day is flaky tests in CI. When I, you know, I'm wanting to merge a change, I often have to run the test suite a few times to get to green and be able to merge and deploy.

+ +

And this is an interesting topic to me because when you're really trying to just get your changes through and mark that ticket as done, it's very tempting to just hit that, you know, retry button and let it sit and just hope for the best, as opposed to maybe investigate a little further about why that test was flaking and see if there's something that you could do about it.

+ +

So, I wanted to talk to you about the idea of making the right thing easy or how, at both a team level and an individual level, we can set ourselves and our team up for success rather than shoulder this burden [laughs] and just assume that things are the way they are.

+ +

JOËL: That's a really powerful question. Because I think by default, oftentimes, the less helpful thing is the path of least resistance, so, in this case, hitting that rerun button on a test suite, which I've absolutely done. But there's a lot of other situations in our work where, just sort of by default, the path of least resistance is the thing that's maybe less helpful for the team.

+ +

STEPHANIE: Ooh, I noticed that you kind of reframed what I said. I was using the term, you know, the right thing, but you then reworded it into the helpful thing. And that actually gets me thinking about these words are kind of subjective, right? What is helpful to someone could be different to what's helpful to someone else. And I'm kind of curious about your definition of the helpful thing.

+ +

JOËL: Yeah, I mean, sometimes it's very easy to sort of bring absolutes and [inaudible 11:26] judgments to code, you know, when we talk about writing good code, and being good programmers, being good at our jobs, not doing the bad things. And I think that sort of absolutism sometimes can, like, be very restrictive, and kind of takes us down paths that are not optimal for ourselves, for our teams, for our products. So, I'd like to think a little bit more relativistically have a little bit more of elasticity in the way that we formulate some of these ideas.

+ +

STEPHANIE: Yeah. I really like that reframing, and I appreciate the nuance there. I think for me, when I think of doing the helpful thing, I'm hoping to ease the day-to-day workflow for other developers because that also includes myself, right? Like, I've certainly been there feeling frustrated or just kind of tired of retrying [laughs] the test suite over and over again.

+ +

I'm also thinking about helpful, as in what will be helpful for future developers regarding the product? And can we make it robust now so that we're not dealing with bug reports later for things that we maybe we're trying to throw under the rug or just kind of glance over? Do you have any other guiding principles around what is helpful and what's not?

+ +

JOËL: I think that the time horizon you mentioned is really interesting because you have to balance sometimes short-term value versus kind of long-term. And is it worth it to maybe not fix that flaky test today so that we can ship as soon as possible? Or is it worth investing a little bit of time today so that tomorrow or next week is better? If you're a solo developer on a tiny project, that might be of personal benefit only. But on a larger team, you know, that might benefit not just you but a larger amount of people.

+ +

STEPHANIE: I just imagined the trolley problem [laughs] a little bit about, you know, the future developers and whose lives, not lives but whose happiness, the developer happiness you'll save [laughs] when you're on that track and making the decision about benefit now versus benefit later.

+ +

JOËL: No connection to railway-oriented programming, by the way.

+ +

STEPHANIE: I am really interested in also talking about barriers to doing the helpful thing or taking that extra step, right? Because I think identifying those barriers is really important to then, hopefully, break them down so that we are creating that path of least resistance.

+ +

JOËL: That's interesting that you mentioned these as barriers because I think, in my mind, I was thinking about the same idea but from, like, a completely mirror perspective, the idea of incentives. Why do incentives push you in one way versus the other?

+ +

STEPHANIE: I like that a lot. I think maybe there are, like, two different levers, right? Or maybe they are two sides of the same coin, where you do have incentive, and then you also have things that disincentivize you.

+ +

JOËL: This reminds me a little bit of the idea of the tragedy of the commons. So, in the case of flaky tests, everybody as a whole on your project has a worse experience. And project velocity slows when there are flaky tests. But you, as an individual developer, are incentivized to ship features quickly and efficiently. And the fastest way you can get your individual feature to production is by hitting that rerun button. Even though, collectively as a whole, every time we do that, instead of fixing the flakiness, we're adding a tiny, little bit of extra slowness that will accrete over time.

+ +

STEPHANIE: Yeah. It's kind of difficult to imagine really the negative impact that it's having collectively, right? You're kind of like, oh, I'm feeling this pain, but you're not always, like, really hearing about it from others, and we might just be silently suffering together [laughs]. I do think that once it's been identified as like, oh, like, we're all actually, like, really impacted by this, okay, great, let's make it a priority.

+ +

And so, now, let's say I am slightly incentivized to go and investigate the flakiness of a test rather than hit the rerun button this time around. I am wanting to talk about those barriers I was referring to a little bit because I've been in this position where I'm like, okay, like, I have some extra time today. So, why don't I look into this?

+ +

But then I go down that path, and now I'm looking at a test written by someone many years ago, you know, I don't know this person, and I don't know this domain. I don't know who to talk to to figure out even where to start. I may or may not feel equipped with the right tools to be able to address it.

+ +

And then, I think the biggest challenge is not feeling like it matters, right? Once I'm hitting this barrier, I'm like, is it worth the effort? At that point, maybe a little bit demoralized because, well, this is just one, and we have so many other flaky tests, like, what's one more?

+ +

JOËL: That's really interesting that you mentioned that sort of morale factor because it's absolutely the case on every flaky test suite I've seen. I think that kind of points to almost, like, an exponential cost to ignoring the problem. If someone fixed it early, yeah, it's slightly annoying, but you get it done. You fix it, and then you move on. When it feels like there's now this insurmountable pile of these and that any work you do here doesn't bring you any closer to the goal because it's effectively infinite, yeah, now, there is no incentive at all to do that work.

+ +

STEPHANIE: So, to avoid that, we talked about incentives, right? And I'm kind of curious: what ways have you seen or experienced that did make you feel motivated to take that extra step or at least try to avoid that point of thinking that nothing matters? [laughs]

+ +

JOËL: So, I'm going to start with, I think, what's maybe a classic developer answer, and I'm curious to get your thoughts on it because I think I have very mixed feelings about this. The idea of programmer discipline—we just need to kind of take more pride in our craft and pursue excellence, choose to do the right thing, even when it's hard every day. Because I hear a lot of that in our communities. How do you feel about that sort of maybe a bit of a mindset change? And how effective has that been?

+ +

STEPHANIE: Whoa, yeah, that's a really great point because I think I also feel quite conflicted about it. Because sometimes I can find it in myself to be, like, you know, I have the energy today to want to uphold, like, a certain level of quality that would make me feel good about doing my best work. And then, there are other days where I am, you know, just tired, [laughs] or feeling a little bit lazy, feeling just not confident that it will be worth it. Because there's also, I think, some external forces, right?

+ +

I've certainly been in the position where we were only rewarded or celebrated for shipping fast. That was the praise we were getting at retros. But then that actually really disincentivized me from wanting to do the helpful thing when the time came, right? When I'm in my development process, and I'm at, like, that crossroads. Because I'm like, well, I've been trying to do the right thing, but, like, no one is celebrating me for it. What if it takes away time from doing the thing that is considered successful? And, like, does it have an impact on me and my job?

+ +

So, you can, you know, kind of go down that spiral pretty quickly. And, in that case, like, no amount of personal, like, individual [laughs] feelings of responsibility can really overcome those consequences if, like, you're working on a team where that is just simply not valued, and there are other people who have authority to impart consequences, I suppose.

+ +

JOËL: Yeah. It's, you know, you have that maybe some amount of personal motivation. You feel like you're swimming upstream. And so, maybe the question then is, how do we reorient maybe some of the incentive structures in a team to try to make it so that if you are, let's just say, chasing some of those extrinsic rewards and you're trying to get praise from your teammates, or move forward in your career, whatever it is that is rewarded and valued on your team, how can that be harnessed to push people in a direction to get some of these extra tasks done?

+ +

STEPHANIE: Yeah. I will say, though, it is a little bit of both. And I think that was maybe why we're both kind of conflicted about it. Because on the individual level and, in general, knowing what my values are and, like, wanting to do good work and uphold quality, there are times where I don't always behave according to those values. Like I said, I am feeling tired, or maybe it's, like, almost 5:00 o'clock, and I just want to, you know, push my thing [laughs] so I can go and go on with my day.

+ +

What has helped me is having an accountability buddy. Maybe it's in code review, or maybe it's when I'm pairing, or maybe just talking about a problem that we're facing, right? And I might get into that sort of lizard-brain mentality of just wanting to do the easy thing. But as soon as someone else points it out or is, like, you know, like, "That's not quite aligning with what I know your, like, hopes and goals are for this project or how you want to do your work," usually, that's enough to be like, "Yeah, you're right." [laughs] And I'll take another pass at it.

+ +

JOËL: And I think we've kind of come back full circle here in that you mentioned that sort of the lizard brain side of you wants to just do the easy thing with the implication that, in this case, the easy thing is the thing that's maybe not useful to the team long term. What if we could restructure things a little bit so that the easy thing was the most beneficial thing for the team? And now you're not having to use discipline to fight the lizard brain side of you, but you're actually working with it.

+ +

One thing I've seen teams do with flaky tests is to not necessarily fix them immediately. Like, maybe you do rerun them, but when they happen, create a ticket for them and put them into the planning board. And so, now, these are things that get prioritized. They're things that might be fairly quick to do. So, it might be a fun, like, fast ticket for someone to pick up at the end of the week. It now counts towards velocity if tracked, so people, hopefully, get rewarded for doing that work. Is that something that you've seen? And how effective do you think that is in maybe making fixing flaky tests easier thing for a team?

+ +

STEPHANIE: Yeah, that is actually something that we are doing on my team right now, and I think it's great. I like the idea of tracking it, right? Because then you could also see over time, like, whether we have been getting better at reducing flaky tests, you know, then it's also really clear when someone is preoccupied with that work, and they don't get assigned something else.

+ +

One way that I've seen it not work as well as we hoped is when other work consistently gets prioritized over those flaky test tickets, and, you know, sometimes it happens. I think that's also information, though, about the team and how the team is spending its time compared to how the team thinks it should be ideally spending its time where, you know, we can say all we want, like, yes, like, we really want to make sure our test suite is robust. But when other things are consistently getting prioritized over it, then you can point to it and say, do we actually believe this if we're consistently not behaving according to that belief?

+ +

I found that challenging to have that conversation. But I do think that the concreteness of adding it to our workload for a given period of time is at least providing information rather than it being things that, like, developers are doing one-off or kind of just on their own time.

+ +

JOËL: Another solution that I've seen people do, and this is a classic developer solution, is tooling. If you have better tooling around a particular problem, sometimes you can shift that cost, that time of work it takes so that it's easier to do the best thing rather than to not...or at least make it easy enough that it's less of a big decision, like, oh, do I really want to invest that much work into something?

+ +

And a classic example of this, I think, is when you're trying to get into more of a test-driven development workflow. Having a test suite that's fast and, really importantly, having a near-instant way to run a test from your code editor makes a big difference in terms of adopting that workflow.

+ +

Because if the cost of running a test is too high, then yeah, the easy path is to just say, you know what? I'm not going to run a test. I'm going to just run it once at the end after I've written 100 lines of code or an entire feature. And now I am not getting the benefits of TDD. And that might kind of get into a negative cycle where because I'm not seeing the benefits, I do it even less. And then eventually, I'm just, like, you know what? Forget this whole thing.

+ +

STEPHANIE: I think that also applies to testing in general, where if it, you know, is feeling really challenging. I have definitely seen people start to get into that mindset of, is this worth my time to do at all? And it's a very slippery slope, I think.

+ +

That almost makes me think about, like, okay, like, what are some other ways to lift that task up and to elevate it into something that's worthy of saying, like, "Hey, like, that was really hard, and you did a great job. And that was really awesome that you persevered through that challenging thing." Sharing the pain points is really important, not only to, like I mentioned earlier, to, like, communicate that, oh, maybe, like, more people than you think are going through the same thing, but also to be able to identify when someone went out of their way to do the helpful thing and seeing that someone was willing to do it because, for them, being helpful is important.

+ +

When I see someone on my team take on kind of a difficult task to make things easier for others and then share about it, I feel really inspired because I think, wow, like, that could be me as well. You know, there's that saying that many hands make light work. And I also think that's true of tackling these kinds of barriers, where if we all feel this collective responsibility or, like, wanting to help out the group, it ends up literally being easier.

+ +

JOËL: I think something I'm hearing here as well is the value of giving praise. If somebody goes out of their way to make life easier for the rest of your team, give them a shout-out, whether that's in your team's Slack channel, maybe it's at an all-hands meeting, and you shout out some work that they've done or, you know, you put their name on a slide in your slide deck at some point, or whatever it is the mechanism within your team. Having a way to shout out people who've done some of this work that can be sometimes a little bit thankless is a great way to motivate seeing more of that.

+ +

STEPHANIE: Yeah. I was just thinking that it can be really powerful because, like you said, a lot of it is thankless, but also, we may not even realize the impact it's having on others until you give that shout-out and express, like, "Wow, like, that change, you know, I've been bothered by this issue for so long and, you know, that really made an impact on me," just keeping that cycle of gratitude going.

+ +

JOËL: So, I think we've kind of identified three maybe main areas of ways where you can help to incentivize these behaviors. You can do it through kind of process. We talked about the example of pulling the flaky tests as actual cards to be worked through on a board.

+ +

It can be technical by introducing some tooling that makes it much easier to do the work that you're trying to do.

+ +

And it can be personal by praising people, preferably in public, for taking that extra step. And I think all three of those can be part of a strategy to make it easier or more attractive for people to do work that benefits the team as a whole, even if they don't see an immediate return to that on a per-day level.

+ +

STEPHANIE: Yeah. I like that we kind of talked about these three different categories. And people in all different types of roles can, hopefully, take something from what we've shared, right? If you are a manager or leader of a team, maybe you can investigate your processes. If you're an individual contributor and you notice your colleague doing something that you, you know, kept meaning to but just didn't have time for, recognize that work. It really does take a holistic approach, but I think an impact can be made at every level.

+ +

JOËL: Agreed. I think for managers and more senior team members, that's really almost, like, part of their job description is to think about these kinds of things. How can we incentivize this work? How can we shift the team in a particular direction? There's a particular onus on them to do this right, to think about this, to model some of this behavior.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: For someone who's really senior on a team also, they're often the ones who are tasked or who maybe take the initiative to build some of this more complex tooling so that these tasks are easier for more junior people. Maybe that's tinkering with some things and building an editor plugin that makes it easier to do some work. Maybe it's building a Rails generator so that the proper files get generated that maybe people wouldn't think to have when they're building certain work. Maybe it's building an RSpec matcher to make it easier for people to test some of the nuances of what we're hoping to do, catching some of these edge cases.

+ +

Whatever it is, sometimes there are things that the more junior members of our teams aren't aware of, and having a senior person take time out of their day to build these things so that now the entire team can be more productive can be a really helpful thing to do.

+ +

STEPHANIE: Yeah, that's a great point. And I think that also comes from having a pulse on what people are struggling with, right? So, you know, oh, it would be good to invest my energy into building a script to make this manual process easier because I keep hearing about people having issues with it or it being a challenge.

+ +

So, I would even recommend posing the question of, like, how do people feel about being able to fix that flaky test, right? Like, is it intimidating? What are those barriers? Because your team knows best about what that experience is like. And if that is not something on your radar, maybe there are opportunities to incorporate it into where you're evaluating team morale and happiness.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+YO4_faRB + + ]]> + + Joël Quenneville + Stephanie Minn + + + 400: How To Search + https://bikeshed.thoughtbot.com/400 + 9e0ebabe-bcd8-4379-ba1c-6b67192634e9 + Tue, 05 Sep 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël shares he has been getting more into long-form reading. Stephanie talks about the challenges she faced in a new project that required integrating with another company's system. + +Together, they delve into the importance of search techniques for developers, covering various approaches to finding information online. + 36:02 + no + + + Joël shares he has been getting more into long-form reading. Stephanie talks about the challenges she faced in a new project that required integrating with another company's system. +Together, they delve into the importance of search techniques for developers, covering various approaches to finding information online. +Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) +Episode on heuristics (https://www.bikeshed.fm/398) +Episode on specialized vocabulary (https://www.bikeshed.fm/356) +Episode on discrete math (https://www.bikeshed.fm/374) +Joël’s discrete math talk at RailsConf (https://www.youtube.com/watch?v=wzYYT40T8G8) +Dash (https://kapeli.com/dash) +Alfred (https://www.alfredapp.com/) +Indiana Jones and the Crypt of Cryptic Error Messages (https://thoughtbot.com/blog/indiana-jones-and-the-crypt-of-cryptic-error-messages) +Browser History confessional by Kevin Murphy (https://www.youtube.com/watch?v=R7LkHjJdH9o) +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 I've been trying to do recently is get more into long-form reading. I read quite a bit of technical content, but most of it are short articles, blog posts, that kind of thing. And I've not read, like, an actual software-related book in a few years, or at least not completed a software-related book. I've started a few chapters in a few. So, something I've been trying to do recently is set aside some time. It's on my calendar. Every week, I've got an hour sit down, read a long-form book, and take notes. +STEPHANIE: That's really cool. I actually really enjoy reading technical stuff in a long-form format. In fact, I was similarly kind of trying to do it, you know, once a week, spend a little bit of time in the mornings. And what was really nice about that is, especially if I had, like, a physical copy of the book, I could close my computer and just be completely focused on the content itself. +I also love blog posts and articles. We are always talking on the show about, you know, stuff we've read on the internet. But I think there's something very comprehensive, and you can dig really deep and get a very deeper understanding of a topic through a book that kind of has that continuity. +JOËL: Right. You can build up a larger idea have more depth. A larger idea can also cover more breadth. A good blog post, typically, is very focused on a single thing, the kind of thing that would really probably only be a single chapter in a book. +STEPHANIE: Has your note-taking system differed when you're applying it to something longer than just an article? +JOËL: So, what I try to do when I'm reading is I have just one giant note for the whole book. And I'm not trying to capture elements or, like, summarize a chapter necessarily. Instead, I'm trying to capture connections that I make. So, if there's a concept or an argument that reminds me of something perhaps similar in a different domain or a similar argument that I saw made by someone else in a different place, I'll capture notes on that. Or maybe it reminds me of a diagram that I drew the other day or of some work I did on a client six months ago. +And so, it's capturing all those connections is what I'm trying to do in my notes. And then, later on, I can kind of go back and synthesize those and say, okay, is there anything interesting here that I might want to pull out as an actual kind of idea note in my larger note-taking system? +STEPHANIE: Cool, yeah. I also do a similar thing where I have one big note for the whole book. And when I was doing this, I was even trying to summarize each chapter if I could or at least like jot down some takeaways or some insights or lines that I like felt were really compelling to me. And, like, something I would want to, in some ways, like, have created some, like, marker for me to remember, oh, I really liked something in this chapter. And then, from there, if I didn't capture the whole idea in my note, I knew where I could go to revisit the content. +JOËL: And did you find that was helpful for you when you came back to the book? +STEPHANIE: Yeah, it did. I usually can recall how, like, I felt reading something. You know, if something was really inspiring to me or really relatable, I can recall that, like, I had that experience or emotion. And it's just, like, trying to find where that was and that this is a system that has worked well for me. +Though, I will say that summarizing each chapter did kind of remind me of, like, how we learned how to take notes in school. [laughs] And I think, you know, middle school, or whatever, I recall a particular note-taking format, where you, you know, split the page up into, like, an outline with all the chapters, and you tried to summarize it. And so, it did feel a little bit like homework [laughs]. But I can also see the value in why they taught me how to do that. +JOËL: I was recently having a conversation with someone else about the idea of almost, like, assigning yourself the college-style essay question after finishing a book to try to synthesize what you learned. +STEPHANIE: Whoa, that's really cool. I can see how that would really, like, push you to synthesize and process what you might have just consumed. And, also, I'm so glad I'm not in school anymore [laughs] so that I don't have to do that on a regular basis. [laughs] I'm curious, Joël, what book are you reading right now? +JOËL: I've been reading Domain Modeling Made Functional, which is a really interesting intersection between functional programming, Domain-Driven Design (DDD), and a lot of interesting kind of type theory. And so, that sort of intersection of those three Venn diagrams leads to this really fascinating book that I've been going through. And I think it connects with a lot of other things that I've been thinking about. +So, I'll be reading and be like, oh, this reminds me of this concept that we have in test-driven development. Or this reminds me of this idea that we do when we do a product design sprint. And this reminds me of this principle from object-oriented design. And now I'm starting to make all these really interesting connections. +STEPHANIE: Awesome. Well, I hope to hear more about what you've learned or kind of what you're thinking about going through this book in future episodes. +JOËL: This is not the last time we hear about this book, I'm pretty sure. So, Stephanie, what's new in your world? +STEPHANIE: So, I have a little bit of a work update to share. So, lately, I've been brought in to work on a feature that is integrating with another company's system. And the way that I was brought into this work was honestly just being assigned a task. And I was picking up this work, and I was kind of going through the requirements that had been specked out for me, and I was trying to get started. And then, I realized that I actually had a lot of questions. It just wasn't quite fully fleshed out for the level of detail that I needed for implementing. +And for the past couple of weeks, we've been chatting in Slack back and forth as I tried to get some of my questions answered. They are trying to help me, but also the things that I'm saying end up confusing them as well. And then, I end up having to try and figure out what they're looking for in order to properly respond to them. +And I had not met these people before. These are folks from that other company. And, you know, I'd only just seen their little Slack profile pictures. So, I didn't know who they were. I didn't know what role they had and kind of, like, what perspective they were coming to these conversations from. And after a while, I was feeling a little stressed out because we just kept having this back and forth, and not a lot of answers were coming to fruition. +And I really ended up needing the nudge of the manager on my client team to set up a meeting for us to all just talk synchronously. And I think I had...not that I had been avoiding it necessarily, but I guess I was under the impression that we were at the point where we could just, you know, shoot off a question in Slack and that there would be a clear path forward. But the more we kept pulling on that thread, the more I realized that, oh, like, we have a lot of ambiguity here. +And it really helped to meet them finally, not in person but, like, over a video call. [laughs] So, this happened yesterday. And, you know, even just, like, going around doing introductions, like, sharing what their role was at the company helped me just understand, like, who I was talking to. You know, I realized, oh, like, the level of technical details that I had been providing was maybe too much for this group. +And I was able to have a better understanding of what their needs were, like hearing kind of the problem that they had on their end. And I realized that, oh, like, they actually aren't going to provide me the details for implementation that I was looking for. That's up to me. But at least now I know what their higher-level needs are so that I can make the most informed decisions that I can. +JOËL: Fascinating. So, you thought that this was going to be, like, the technical team you're going to work with. And it turns out that this was not who they were. +STEPHANIE: In some ways. I think I thought by providing more technical details that would be helpful, but it ended up being more confusing for them. And I think I was similarly kind of frustrated because the ways that I was asking questions or communicating also wasn't getting me the answers that I needed as well. +But I felt really great after the meeting because I'm like, wow, you know, it doesn't have to be as stressful. You know, when you start getting into that back and forth on Slack, at least I find it a bit stressful. And it turns out that the antidote to that was just getting together and getting to know each other and hashing out the ambiguity, which does seem to work better in a more synchronous format. +JOËL: Do you have kind of a preference for synchronous versus asynchronous when it comes to communication? +STEPHANIE: That's a good question. I think it's kind of a pendulum for me. I'm in my asynchronous communication is a bit better for me right now phase, but only because I am just so burnt out on meetings a lot of the time that I'm like, oh, like, I really don't want to add another meeting to my calendar, especially because...I amend my statement; I'm burned out of meetings that don't go well. [laughs] +And this meeting, in particular, was different because, you know, I realized, like, oh, like, we are not on the same page, and so how can we get there? And kind of making sure that we were focused on that as an agenda. And I found that ultimately worked out better than the async situation that I was describing, which I'm thinking now, you know when things aren't clear, text-based communication certainly does not help with that. +JOËL: So, meetings, sometimes they're actually good. +STEPHANIE: Yeah, that's my enlightened discovery this week. +JOËL: So, this episode is kind of a special one. We've just hit 400 episodes of The Bike Shed. So, this is episode number 400. It's also my 50th Episode as a co-host. +STEPHANIE: Right. That's a huge deal. 400 is a really big number. I don't know if I've ever done 400 of anything before [laughs]. +JOËL: The Bike Shed has been going on for almost ten years now. The first episode up on the website is from October 31st, 2014, so just about nine years from that first episode. +STEPHANIE: Wow. And it's still going strong. That's really awesome. I think it's really special to be a part of something that has been going on for this long. And, I don't know, maybe there are still listeners today from back in 2014. I would be really excited to hear if anyone out there has been listening to The Bike Shed throughout its whole lifespan. That's really cool. +JOËL: Looking back over the last 50-ish episodes you and I have done, do you have a favorite episode that we've recorded? +STEPHANIE: This may be a bit of recency bias. But the episode that we did about Software Heuristics I really enjoyed. Because I think we got to bring to the table some of the things we believe and the way we like to do things and kind of compare and contrast that with each other. And I always find people's processes very fascinating. Like, I want to know how you think and where your brain is at when you approach a problem. So, I really enjoyed that topic. What about you? Do you have any highlight episodes? +JOËL: I think there's probably two for me. One is the episode that you and I did on Specialized Vocabulary. I think this really touched on a lot of really interesting aspects of writing software that's going to scale, software that works for a team, and also kind of personal growth and exploration. +The second one that I think was really fun was the episode I did with Sara Jackson as a guest talking about Discrete Math because that's an episode that I got really excited about the topic. And right after recording the episode, it was the last day of the call for proposals for RailsConf. And I just took that raw excitement, put together a proposal, hit submit before the deadline. And it got accepted and got turned into a talk that I got to give on stage. So, that was, like, just a really fun journey from exciting episode with Sara and then, like, randomly turned into a conference talk. +STEPHANIE: That's awesome. That makes me feel so happy. Because it just reminds me about how the stuff we talk about on the show can really resonate with people, you know, enough to become a conference talk that people want to attend. +And I also really like that a lot of the topics we've gotten into in the past 50 episodes when we've taken over the show have been a bit more evergreen and just about, you know, the software development experience and a little bit less tied to specific news within the community. +Speaking of evergreen topics, today, I wanted to discuss with you an evergreen software skill, and that is searching or Search-Driven Development, even if you will. +JOËL: Gotta always get that three-letter acronym, something DD. +STEPHANIE: Yeah. I am really curious about how we're going to approach this topic because a lot of folks might joke that a big part of writing software is knowing what to Google. Do you agree with that statement or not? +JOËL: Yes and no. There's definitely value in knowing what to Google. It really depends on the kind of work that you're doing. I find that I don't Google that much these days. There are other tools that I use when I'm particularly, like, searching through documentation, but they tend to be less sort of open-ended questions and more where it's like, oh, let's get the actual documentation for this particular class or this particular method from the standard library. +STEPHANIE: Oh, interesting. I like that you pointed out that there are different scopes of things you might want to search for. So, am I hearing correctly that when you have something specific in mind that you are just trying to recall or wanting to look up, you know, you're still using search that way, but less so if you are trying to figure out how to approach solving a problem? +JOËL: So, oftentimes, if I'm working with a language that I already have familiarity with or a framework that I have familiarity with, I'm going to lean on something more specific. So, I'm going to say, okay, well, I don't exactly remember, like, the argument order for Enumerable's inject method. Is it memo then item, or item then memo? So, I'll just look it up. But I know that the inject method exists. I know what it does. I just don't remember the exact specifics of how to do that. +Or maybe I want to write a file to disk, and I don't remember the exact method or syntax to do that. There are some ways that you can do it using a bunch of instance methods. But I think there's also a class method that allows you to kind of do it all at once. So, maybe I just want to look up the documentation for the file class in Ruby and read through that a little bit. That's the kind of thing where I suppose I could also Google, you know, how to save file Ruby, something like that. But for those sorts of things where I already roughly know what I want to do, I find it's often easier just to go directly to the docs. +STEPHANIE: Yeah, yeah, that's a great tip. And I actually have a little shortcut to share. I started using DuckDuckGo as my search engine in the past year or so. And there's this really cool feature called Bangs for directly searching on specific sites. From my search bar, I can do, let's say, bang Rails and then my query. And it will search directly the Rails Guides website for me instead of, you know, just showing the normal other results that might come up in my regular search engine. And the same goes for bang Ruby doc. That one shows ruby-doc.org, which is my preferred [laughs] Ruby documentation website. +I've really been enjoying it because, you know, it just takes that extra step out of having to either navigate to the site itself first or starting more broadly with my search engine and then just scrolling to find the site that I'm looking for. +JOËL: Yeah. I think having some kind of dedicated flow helps a lot. I have a system that I use on my machine. It is Mac-specific. But I use a combination of the application Dash and the application Alfred. It allows me, with just a few keyboard shortcuts, to type out language names. So, I might say, you know, Ruby inject, and then it'll show me all the classes that have that method defined on it, hit Enter, and it pops up the documentation. It's downloaded on my machine, so it works offline. And it's just, you know, a few key presses. And that works really nicely for me. +STEPHANIE: Oh, offline search. That's really nice. Because then if you're coding on a plane or something, then [laughs] you don't have to be blocked because you can't look up that little, small piece of information you need to move forward. That's very cool. +JOËL: That is really cool. I don't know how often I've really leaned into the offline part of it. I don't know about you; I feel like I don't code on airplanes as much as I thought I would. +STEPHANIE: That's fair. I also don't code on airplanes, but the idea that I could is very compelling to me. [laughs] +JOËL: Absolutely. So, that's the kind of searches that I tend to do when I'm working in a language that I already know, kind of a day-to-day language that I'm using, or a framework that I'm already pretty familiar with. And this is just looking at all the things I haven't gotten to the point where I've fully memorized, but I have a good understanding of. +What about situations where maybe you're a little bit less familiar with? So maybe it's a new framework, or even, like, a situation where you're not really sure how to proceed. How do you search when there's more uncertainty? +STEPHANIE: Yeah, that's a good question. I do think I start a bit naively. The reason that we're able to be more specific and know exactly where to go is because we've built up this experience over time of scrolling through search results and clicking, you know, maybe all of them on the first page, even, and looking at them and being like, oh, like, this is not what I want. And then, seeing something else, it's like, oh, this is more helpful and kind of arrived at sources that we trust. +And so, if it's something new, I don't really mind just going for a basic search, right? And starting more broadly might even be helpful in that process of building up the experience to figure out which places are reputable for the thing that I'm trying to figure out. +JOËL: Yeah, especially when there's a whole new landscape, right? You don't really know what are the places that have good information and the ones that don't. For some things, there might be, like, an obvious first place to start. So, recently, I was on a project where I was trying to do an integration between a Rails app and a Snowflake data warehouse. And so, the first thing I did—I'm not randomly Googling—I went to the Snowflake website, their developer portal, and started reading through documentation for things. +Unfortunately, a lot of the documentation is a bit more corporatey and not really helpful for Ruby-specific implementation. So, there's a few pieces that were useful. There were some links that they had that sent me to some good places. But beyond that, I did have to drop to Google search and try to find out what kinds of other things the community had done that could be helpful. +Now, that first pass, though, did teach me some interesting things. It gave me some good keywords to search for. So, more than just Ruby plus Snowflake or something like that like, I knew that I likely was going to want to do some kind of connection via ODBC. So, now I could say, okay, Ruby plus ODBC integration, or Ruby plus ODBC driver and see what's happening there. And it turns out that one of the really common use cases for ODBC and Ruby is specifically to talk to Snowflake. And one of the top results was an article saying, "Hey, here's how you can use ODBC to get your Rails app to talk to Rails." And then I knew I struck gold. +STEPHANIE: That's really cool. The thing that I was picking up on in what you were saying is the idea of finding what is most relevant to you. And maybe that is something that the algorithm serves you because, like, it's, like, what a lot of people are searching for, you know, a lot of people are engaging with, or matching with all these keywords that you're using. +My little hack that I've been [chuckles] using is to use Slack and lean on other people who have maybe a little more, even just, like, a little more experience than me on the subject, and seeing, like, what things they're linking to, and what resources they're sharing. And I've found that to be really helpful as a place to start. Because, at that point like, my co-workers are narrowing down the really broad landscape for me. +JOËL: I really like how you're sort of you're redefining the question a little bit here. And that, I think, when we talk about search, there's almost this implicit assumption that search is going to be searching the public internet through Google or some other alternative search engine. But you're talking about actually searching from my private corpus of data, in this case, either thoughtbot or maybe the client's Slack conversations, and pulling up information there that might be much more relevant or much more specific to the work that you're trying to do. +STEPHANIE: Yeah. In some ways, I like to think of it as crowd-sourced but, like, a crowd that I trust and, you know, know is relevant to me and what I'm working on. I actually have a fun fact for you. Did you know that Slack is actually an acronym? +JOËL: No, I did not know that. What does it stand for? +STEPHANIE: It stands for Searchable Log of All Communication and Knowledge. +JOËL: That is incredibly clever. I wonder, is this the thing where they came up with that when they made the original name? Or did someone go back later on, you know, a few years into Slack's life and was like, you know what? Our name could be a cool acronym; here's an idea. +STEPHANIE: I'm pretty sure it was created in Slack's early days. And I think it might have even helped decide that Slack was going to be called Slack as opposed to some of the other contenders for the name of the software. But I think it's very accurate. And that could just be how I use Slack. I'm a very heavy search power user in Slack. [laughs]. So, I find it very apt. +You know, obviously, I use it a lot for finding conversations that happened. But I really do enjoy it as a source of discovery for a specific topic, or, you know, technical question or idea that I'm wanting to just, like, filter down a little bit beyond, like you said, the public internet. In fact, I have found it really useful for when you encounter errors that actually are specific to your domain or your app. +Obviously like, you will probably be less successful searching in your search engine for that because it includes, you know, context from your app that other people in the world don't have. But once you are narrowing it down to people at your company, I've been able to get over a lot of troubleshooting humps that way by searching in Slack because likely someone within my team has encountered it before. +JOËL: So, you mentioned searching for error messages in particular. And I feel like that is, like, its own, like, very specific searching skill separate from more general, like, how do I X-style questions. Does that distinction kind of line up with your mental map of the searching landscape? +STEPHANIE: Yeah. I guess the way that I just talked about it now was potentially a bit confusing because I was saying instead of how you might search for errors normally, but I did not talk about how you might search for errors normally. [laughs] But specifically, you know, if I'm popping error messages into my search engine, I am removing the parts of the stack trace that are specific to my app, right? Because I know that that will only kind of, like, clutter up my query and not be getting me towards a more helpful answer as to the source of my issue, especially if the issue is not my application code. +JOËL: Right. I want to give a shout-out to an article on the thoughtbot Blog with a wonderful name: Indiana Jones and the Crypt of Cryptic Error Messages by Louis Antonopoulos. All about how to take an error message that you get from some process in your console and how to make that give you results when you paste it into a search engine. +STEPHANIE: I love that name. Very cool. +JOËL: So, you've talked a little bit about the idea of searching some things that are not on the public internet. How do you feel about kind of internet knowledge bases, private wikis, that kind of thing? Have you had good success searching through those kinds of things? +STEPHANIE: Hmm, I would say mixed success, to be honest. But that's because of maybe more so the way that a team or a company documents information. The reason I say mixed results is because, a lot of the time, the results are outdated, and they're no longer relevant to me. And it doesn't take that much time to pass for something to become outdated, right? Because, like, the code is always changing. And if, you know, someone didn't go and update the documentation about the way that a system has changed, then I usually have to take the stuff that I'm kind of seeing in private wikis with a bit more skepticism, I would say. +JOËL: Yeah, I think my experience mirrors yours as well. Also, some private wikis have just become absolutely huge. And so, searches just return a lot of results that are not really relevant to what I'm searching for. The searching algorithms that these systems use are often much less powerful than something like Google. So, they often don't sort results in a way that are bringing relevant things up to the top. So, it's more work to kind of sift through all of the things I don't care about. +STEPHANIE: Yeah, bringing up the size of a wiki and, like, all of the pages, that is a good point because I see a lot of duplicate stuff, but that's just, like, slightly different. So, I'm not sure which one I'm supposed to believe. One really funny encounter that I had with a private wiki, or actually it was, like, a knowledge base article that was for the internal team...it was documenting actually a code process. So, it was documenting in more human-readable terms, like the steps an algorithm took to determine some result. But the whole document was prefaced by, "This information came from an email that was sent way long ago." [laughs] +JOËL: That's an epic start to a Wiki article. +STEPHANIE: Yeah. And there was another really funny line that said, "The reason for this logic is because of a decision made by (This person's name.)," like a business decision that (some random person name). No last name either, so I have no idea [laughs] who they could be referring to and any of the, like, historical context of why that happened. But I thought it was really funny as just a piece of, like, an artifact, of, at the time, when this was written, that meant something to someone, and that knowledge kind of has been diluted [laughs] over the years. +JOËL: Yeah, internal wikis, I feel like, are full of that, especially if they've had a few years to grow and the company has changed and evolved. +So, now it's time for hot takes. +STEPHANIE: Yeah, I'm ready for them. +JOËL: We are now in the fancy, new age of AI. Is ChatGPT going to make all of this episode obsolete? +STEPHANIE: I'm going to say no, but I'm also biased, and I'm not a ChatGPT enthusiast. I've said it on air. [laughs] I can't even say that I've used it. So, that's kind of where I'm coming from with all this. But I have heard from folks that, convenient as it may be, it is not always 100% accurate or successful. +And I think that one of the things I really like about kind of having agency over my search is that I can verify, as a human, the information that I'm seeing. So, you know, when you're, like, browsing a bunch of Stack Overflow questions and you see, you know, all these answers, at least you can, like, do a little bit of, like, investigation using context clues about who is answering the question, you know, like, what experience might they have? +If you encounter something on a blog post, for example, you can go to the about page on this person's blog and be like, who are you? [chuckles] And, like, what qualifies you to give this information? And I think that is really valuable for me in terms of evaluating whether I want to go down a path based on what I'm seeing. +JOËL: So, I've played with it a tiny, little bit, so not enough to have a good sample size. And I think it can be interesting for some of those less constrained kind of how do I style questions. I'm not necessarily looking for, like, an exact code sample. But even if it just points me towards, oh, I need to be looking at this particular class in this standard library and read through that documentation to build the thing that I want. Or maybe it links me to kind of the classic blog posts that people refer to when talking about this thing. +It's a good way sometimes to just narrow down when you're kind of faced with, you know, the infinity of the internet, and you're kind of like, oh, I don't even know where to start. It gives you some keywords or some threads to follow up on that I think can be really interesting. +STEPHANIE: The infinity of the internet. I love that phrase. I don't think I've heard it before, but it's very evocative for me [laughs]. And I like what you said about it helping you give a direction and to kind of surface those keywords. In fact, it almost kind of sounds like what I was mentioning earlier about using Slack for, right? And, in that case, the hive mind that I'm pulling from is my co-workers. But also, I can see how powerful it would be to leverage a tool that is guiding you based on the software community at large. +JOËL: Something I'd be curious to maybe lean into a little bit more are some of those slightly more specified questions where it does give you a code snippet, so something like writing a file to disk where, right now, it's, you know, five characters. I just pop up Alfred and type up Ruby F, and it gives you the file docs, and it's, you know, right there. There's usually an example at the top of the file. I copy-paste that and get working. +But maybe this would be a situation where some AI-assisted tools would be better. It could be searching through something like ChatGPT. It could be maybe even something like Co-pilot, where, you know, you just start typing a little bit, and it just fills out that skeleton of, like, oh, you want to write a file to disk in Ruby. Here's how it's typically done. +STEPHANIE: Yeah, you bring up a good point that, in some ways, even the approaches to searching we were talking about originally is still just building off of algorithms helping us to find what we're looking for, right? +Though, I did really want to recommend an awesome talk from Kevin Murphy, from a RailsConf a couple of years ago, that's called Browser History Confessional: Searching My Recent Searches. The main message that I really enjoyed from this talk was the idea of thinking about what you're searching for and why because that will, I think, help add a bit of, like, intentionality into that process. You know, it can be very overwhelming, but let that guide you a little bit. +One of the things that he mentions is the idea of revisiting your own assumptions with search. So, even if you think you know how to do something, or you might even know, like, how you might want to do it, just going to search to see if there's any other implementations that you haven't thought of that other people are doing that might inform how you approach a problem, or at least, like, make you feel even more confident about your original approach in the first place. +I thought that was really cool. That's not something that I do now, but definitely, something that I want to try is to be, like, I think I know how to do this, but let me see what other people are doing because that might spark something new. +JOËL: We'll put a link in the show notes to this talk. But I was lucky enough to see it in person. And also would like to second that recommendation. It is worth watching. +From this conversation that you and I have had, I'm having, like, two main takeaways. One is kind of what you just said, the idea of being a little bit more cognizant of, what kind of search am I doing? Is this a sort of broad how do I X, where I don't even really know where to start? Is this, like, something really specific where you just don't know what kind of syntax you want to use? Is it an error message where you just want to see what other people have done when they've encountered this? Or any other, like, more specific subcategories. And how being aware of that can help you search more effectively. +And secondly, don't limit yourself to the public internet. There's a lot of great information in your company's Slack or other instant messaging service, maybe some kind of documentation system internal, some kind of wiki. And those can be a great place to search as well. +STEPHANIE: If we missed any other cool searching tips or tricks or ways that we might be able to improve our processes for searching as developers, I would really love to hear about them. So, if any listeners out there want to write in with their thoughts, that would be super awesome. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël shares he has been getting more into long-form reading. Stephanie talks about the challenges she faced in a new project that required integrating with another company's system.

+ +

Together, they delve into the importance of search techniques for developers, covering various approaches to finding information online.

+ +
+ + + +

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 I've been trying to do recently is get more into long-form reading. I read quite a bit of technical content, but most of it are short articles, blog posts, that kind of thing. And I've not read, like, an actual software-related book in a few years, or at least not completed a software-related book. I've started a few chapters in a few. So, something I've been trying to do recently is set aside some time. It's on my calendar. Every week, I've got an hour sit down, read a long-form book, and take notes.

+ +

STEPHANIE: That's really cool. I actually really enjoy reading technical stuff in a long-form format. In fact, I was similarly kind of trying to do it, you know, once a week, spend a little bit of time in the mornings. And what was really nice about that is, especially if I had, like, a physical copy of the book, I could close my computer and just be completely focused on the content itself.

+ +

I also love blog posts and articles. We are always talking on the show about, you know, stuff we've read on the internet. But I think there's something very comprehensive, and you can dig really deep and get a very deeper understanding of a topic through a book that kind of has that continuity.

+ +

JOËL: Right. You can build up a larger idea have more depth. A larger idea can also cover more breadth. A good blog post, typically, is very focused on a single thing, the kind of thing that would really probably only be a single chapter in a book.

+ +

STEPHANIE: Has your note-taking system differed when you're applying it to something longer than just an article?

+ +

JOËL: So, what I try to do when I'm reading is I have just one giant note for the whole book. And I'm not trying to capture elements or, like, summarize a chapter necessarily. Instead, I'm trying to capture connections that I make. So, if there's a concept or an argument that reminds me of something perhaps similar in a different domain or a similar argument that I saw made by someone else in a different place, I'll capture notes on that. Or maybe it reminds me of a diagram that I drew the other day or of some work I did on a client six months ago.

+ +

And so, it's capturing all those connections is what I'm trying to do in my notes. And then, later on, I can kind of go back and synthesize those and say, okay, is there anything interesting here that I might want to pull out as an actual kind of idea note in my larger note-taking system?

+ +

STEPHANIE: Cool, yeah. I also do a similar thing where I have one big note for the whole book. And when I was doing this, I was even trying to summarize each chapter if I could or at least like jot down some takeaways or some insights or lines that I like felt were really compelling to me. And, like, something I would want to, in some ways, like, have created some, like, marker for me to remember, oh, I really liked something in this chapter. And then, from there, if I didn't capture the whole idea in my note, I knew where I could go to revisit the content.

+ +

JOËL: And did you find that was helpful for you when you came back to the book?

+ +

STEPHANIE: Yeah, it did. I usually can recall how, like, I felt reading something. You know, if something was really inspiring to me or really relatable, I can recall that, like, I had that experience or emotion. And it's just, like, trying to find where that was and that this is a system that has worked well for me.

+ +

Though, I will say that summarizing each chapter did kind of remind me of, like, how we learned how to take notes in school. [laughs] And I think, you know, middle school, or whatever, I recall a particular note-taking format, where you, you know, split the page up into, like, an outline with all the chapters, and you tried to summarize it. And so, it did feel a little bit like homework [laughs]. But I can also see the value in why they taught me how to do that.

+ +

JOËL: I was recently having a conversation with someone else about the idea of almost, like, assigning yourself the college-style essay question after finishing a book to try to synthesize what you learned.

+ +

STEPHANIE: Whoa, that's really cool. I can see how that would really, like, push you to synthesize and process what you might have just consumed. And, also, I'm so glad I'm not in school anymore [laughs] so that I don't have to do that on a regular basis. [laughs] I'm curious, Joël, what book are you reading right now?

+ +

JOËL: I've been reading Domain Modeling Made Functional, which is a really interesting intersection between functional programming, Domain-Driven Design (DDD), and a lot of interesting kind of type theory. And so, that sort of intersection of those three Venn diagrams leads to this really fascinating book that I've been going through. And I think it connects with a lot of other things that I've been thinking about.

+ +

So, I'll be reading and be like, oh, this reminds me of this concept that we have in test-driven development. Or this reminds me of this idea that we do when we do a product design sprint. And this reminds me of this principle from object-oriented design. And now I'm starting to make all these really interesting connections.

+ +

STEPHANIE: Awesome. Well, I hope to hear more about what you've learned or kind of what you're thinking about going through this book in future episodes.

+ +

JOËL: This is not the last time we hear about this book, I'm pretty sure. So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I have a little bit of a work update to share. So, lately, I've been brought in to work on a feature that is integrating with another company's system. And the way that I was brought into this work was honestly just being assigned a task. And I was picking up this work, and I was kind of going through the requirements that had been specked out for me, and I was trying to get started. And then, I realized that I actually had a lot of questions. It just wasn't quite fully fleshed out for the level of detail that I needed for implementing.

+ +

And for the past couple of weeks, we've been chatting in Slack back and forth as I tried to get some of my questions answered. They are trying to help me, but also the things that I'm saying end up confusing them as well. And then, I end up having to try and figure out what they're looking for in order to properly respond to them.

+ +

And I had not met these people before. These are folks from that other company. And, you know, I'd only just seen their little Slack profile pictures. So, I didn't know who they were. I didn't know what role they had and kind of, like, what perspective they were coming to these conversations from. And after a while, I was feeling a little stressed out because we just kept having this back and forth, and not a lot of answers were coming to fruition.

+ +

And I really ended up needing the nudge of the manager on my client team to set up a meeting for us to all just talk synchronously. And I think I had...not that I had been avoiding it necessarily, but I guess I was under the impression that we were at the point where we could just, you know, shoot off a question in Slack and that there would be a clear path forward. But the more we kept pulling on that thread, the more I realized that, oh, like, we have a lot of ambiguity here.

+ +

And it really helped to meet them finally, not in person but, like, over a video call. [laughs] So, this happened yesterday. And, you know, even just, like, going around doing introductions, like, sharing what their role was at the company helped me just understand, like, who I was talking to. You know, I realized, oh, like, the level of technical details that I had been providing was maybe too much for this group.

+ +

And I was able to have a better understanding of what their needs were, like hearing kind of the problem that they had on their end. And I realized that, oh, like, they actually aren't going to provide me the details for implementation that I was looking for. That's up to me. But at least now I know what their higher-level needs are so that I can make the most informed decisions that I can.

+ +

JOËL: Fascinating. So, you thought that this was going to be, like, the technical team you're going to work with. And it turns out that this was not who they were.

+ +

STEPHANIE: In some ways. I think I thought by providing more technical details that would be helpful, but it ended up being more confusing for them. And I think I was similarly kind of frustrated because the ways that I was asking questions or communicating also wasn't getting me the answers that I needed as well.

+ +

But I felt really great after the meeting because I'm like, wow, you know, it doesn't have to be as stressful. You know, when you start getting into that back and forth on Slack, at least I find it a bit stressful. And it turns out that the antidote to that was just getting together and getting to know each other and hashing out the ambiguity, which does seem to work better in a more synchronous format.

+ +

JOËL: Do you have kind of a preference for synchronous versus asynchronous when it comes to communication?

+ +

STEPHANIE: That's a good question. I think it's kind of a pendulum for me. I'm in my asynchronous communication is a bit better for me right now phase, but only because I am just so burnt out on meetings a lot of the time that I'm like, oh, like, I really don't want to add another meeting to my calendar, especially because...I amend my statement; I'm burned out of meetings that don't go well. [laughs]

+ +

And this meeting, in particular, was different because, you know, I realized, like, oh, like, we are not on the same page, and so how can we get there? And kind of making sure that we were focused on that as an agenda. And I found that ultimately worked out better than the async situation that I was describing, which I'm thinking now, you know when things aren't clear, text-based communication certainly does not help with that.

+ +

JOËL: So, meetings, sometimes they're actually good.

+ +

STEPHANIE: Yeah, that's my enlightened discovery this week.

+ +

JOËL: So, this episode is kind of a special one. We've just hit 400 episodes of The Bike Shed. So, this is episode number 400. It's also my 50th Episode as a co-host.

+ +

STEPHANIE: Right. That's a huge deal. 400 is a really big number. I don't know if I've ever done 400 of anything before [laughs].

+ +

JOËL: The Bike Shed has been going on for almost ten years now. The first episode up on the website is from October 31st, 2014, so just about nine years from that first episode.

+ +

STEPHANIE: Wow. And it's still going strong. That's really awesome. I think it's really special to be a part of something that has been going on for this long. And, I don't know, maybe there are still listeners today from back in 2014. I would be really excited to hear if anyone out there has been listening to The Bike Shed throughout its whole lifespan. That's really cool.

+ +

JOËL: Looking back over the last 50-ish episodes you and I have done, do you have a favorite episode that we've recorded?

+ +

STEPHANIE: This may be a bit of recency bias. But the episode that we did about Software Heuristics I really enjoyed. Because I think we got to bring to the table some of the things we believe and the way we like to do things and kind of compare and contrast that with each other. And I always find people's processes very fascinating. Like, I want to know how you think and where your brain is at when you approach a problem. So, I really enjoyed that topic. What about you? Do you have any highlight episodes?

+ +

JOËL: I think there's probably two for me. One is the episode that you and I did on Specialized Vocabulary. I think this really touched on a lot of really interesting aspects of writing software that's going to scale, software that works for a team, and also kind of personal growth and exploration.

+ +

The second one that I think was really fun was the episode I did with Sara Jackson as a guest talking about Discrete Math because that's an episode that I got really excited about the topic. And right after recording the episode, it was the last day of the call for proposals for RailsConf. And I just took that raw excitement, put together a proposal, hit submit before the deadline. And it got accepted and got turned into a talk that I got to give on stage. So, that was, like, just a really fun journey from exciting episode with Sara and then, like, randomly turned into a conference talk.

+ +

STEPHANIE: That's awesome. That makes me feel so happy. Because it just reminds me about how the stuff we talk about on the show can really resonate with people, you know, enough to become a conference talk that people want to attend.

+ +

And I also really like that a lot of the topics we've gotten into in the past 50 episodes when we've taken over the show have been a bit more evergreen and just about, you know, the software development experience and a little bit less tied to specific news within the community.

+ +

Speaking of evergreen topics, today, I wanted to discuss with you an evergreen software skill, and that is searching or Search-Driven Development, even if you will.

+ +

JOËL: Gotta always get that three-letter acronym, something DD.

+ +

STEPHANIE: Yeah. I am really curious about how we're going to approach this topic because a lot of folks might joke that a big part of writing software is knowing what to Google. Do you agree with that statement or not?

+ +

JOËL: Yes and no. There's definitely value in knowing what to Google. It really depends on the kind of work that you're doing. I find that I don't Google that much these days. There are other tools that I use when I'm particularly, like, searching through documentation, but they tend to be less sort of open-ended questions and more where it's like, oh, let's get the actual documentation for this particular class or this particular method from the standard library.

+ +

STEPHANIE: Oh, interesting. I like that you pointed out that there are different scopes of things you might want to search for. So, am I hearing correctly that when you have something specific in mind that you are just trying to recall or wanting to look up, you know, you're still using search that way, but less so if you are trying to figure out how to approach solving a problem?

+ +

JOËL: So, oftentimes, if I'm working with a language that I already have familiarity with or a framework that I have familiarity with, I'm going to lean on something more specific. So, I'm going to say, okay, well, I don't exactly remember, like, the argument order for Enumerable's inject method. Is it memo then item, or item then memo? So, I'll just look it up. But I know that the inject method exists. I know what it does. I just don't remember the exact specifics of how to do that.

+ +

Or maybe I want to write a file to disk, and I don't remember the exact method or syntax to do that. There are some ways that you can do it using a bunch of instance methods. But I think there's also a class method that allows you to kind of do it all at once. So, maybe I just want to look up the documentation for the file class in Ruby and read through that a little bit. That's the kind of thing where I suppose I could also Google, you know, how to save file Ruby, something like that. But for those sorts of things where I already roughly know what I want to do, I find it's often easier just to go directly to the docs.

+ +

STEPHANIE: Yeah, yeah, that's a great tip. And I actually have a little shortcut to share. I started using DuckDuckGo as my search engine in the past year or so. And there's this really cool feature called Bangs for directly searching on specific sites. From my search bar, I can do, let's say, bang Rails and then my query. And it will search directly the Rails Guides website for me instead of, you know, just showing the normal other results that might come up in my regular search engine. And the same goes for bang Ruby doc. That one shows ruby-doc.org, which is my preferred [laughs] Ruby documentation website.

+ +

I've really been enjoying it because, you know, it just takes that extra step out of having to either navigate to the site itself first or starting more broadly with my search engine and then just scrolling to find the site that I'm looking for.

+ +

JOËL: Yeah. I think having some kind of dedicated flow helps a lot. I have a system that I use on my machine. It is Mac-specific. But I use a combination of the application Dash and the application Alfred. It allows me, with just a few keyboard shortcuts, to type out language names. So, I might say, you know, Ruby inject, and then it'll show me all the classes that have that method defined on it, hit Enter, and it pops up the documentation. It's downloaded on my machine, so it works offline. And it's just, you know, a few key presses. And that works really nicely for me.

+ +

STEPHANIE: Oh, offline search. That's really nice. Because then if you're coding on a plane or something, then [laughs] you don't have to be blocked because you can't look up that little, small piece of information you need to move forward. That's very cool.

+ +

JOËL: That is really cool. I don't know how often I've really leaned into the offline part of it. I don't know about you; I feel like I don't code on airplanes as much as I thought I would.

+ +

STEPHANIE: That's fair. I also don't code on airplanes, but the idea that I could is very compelling to me. [laughs]

+ +

JOËL: Absolutely. So, that's the kind of searches that I tend to do when I'm working in a language that I already know, kind of a day-to-day language that I'm using, or a framework that I'm already pretty familiar with. And this is just looking at all the things I haven't gotten to the point where I've fully memorized, but I have a good understanding of.

+ +

What about situations where maybe you're a little bit less familiar with? So maybe it's a new framework, or even, like, a situation where you're not really sure how to proceed. How do you search when there's more uncertainty?

+ +

STEPHANIE: Yeah, that's a good question. I do think I start a bit naively. The reason that we're able to be more specific and know exactly where to go is because we've built up this experience over time of scrolling through search results and clicking, you know, maybe all of them on the first page, even, and looking at them and being like, oh, like, this is not what I want. And then, seeing something else, it's like, oh, this is more helpful and kind of arrived at sources that we trust.

+ +

And so, if it's something new, I don't really mind just going for a basic search, right? And starting more broadly might even be helpful in that process of building up the experience to figure out which places are reputable for the thing that I'm trying to figure out.

+ +

JOËL: Yeah, especially when there's a whole new landscape, right? You don't really know what are the places that have good information and the ones that don't. For some things, there might be, like, an obvious first place to start. So, recently, I was on a project where I was trying to do an integration between a Rails app and a Snowflake data warehouse. And so, the first thing I did—I'm not randomly Googling—I went to the Snowflake website, their developer portal, and started reading through documentation for things.

+ +

Unfortunately, a lot of the documentation is a bit more corporatey and not really helpful for Ruby-specific implementation. So, there's a few pieces that were useful. There were some links that they had that sent me to some good places. But beyond that, I did have to drop to Google search and try to find out what kinds of other things the community had done that could be helpful.

+ +

Now, that first pass, though, did teach me some interesting things. It gave me some good keywords to search for. So, more than just Ruby plus Snowflake or something like that like, I knew that I likely was going to want to do some kind of connection via ODBC. So, now I could say, okay, Ruby plus ODBC integration, or Ruby plus ODBC driver and see what's happening there. And it turns out that one of the really common use cases for ODBC and Ruby is specifically to talk to Snowflake. And one of the top results was an article saying, "Hey, here's how you can use ODBC to get your Rails app to talk to Rails." And then I knew I struck gold.

+ +

STEPHANIE: That's really cool. The thing that I was picking up on in what you were saying is the idea of finding what is most relevant to you. And maybe that is something that the algorithm serves you because, like, it's, like, what a lot of people are searching for, you know, a lot of people are engaging with, or matching with all these keywords that you're using.

+ +

My little hack that I've been [chuckles] using is to use Slack and lean on other people who have maybe a little more, even just, like, a little more experience than me on the subject, and seeing, like, what things they're linking to, and what resources they're sharing. And I've found that to be really helpful as a place to start. Because, at that point like, my co-workers are narrowing down the really broad landscape for me.

+ +

JOËL: I really like how you're sort of you're redefining the question a little bit here. And that, I think, when we talk about search, there's almost this implicit assumption that search is going to be searching the public internet through Google or some other alternative search engine. But you're talking about actually searching from my private corpus of data, in this case, either thoughtbot or maybe the client's Slack conversations, and pulling up information there that might be much more relevant or much more specific to the work that you're trying to do.

+ +

STEPHANIE: Yeah. In some ways, I like to think of it as crowd-sourced but, like, a crowd that I trust and, you know, know is relevant to me and what I'm working on. I actually have a fun fact for you. Did you know that Slack is actually an acronym?

+ +

JOËL: No, I did not know that. What does it stand for?

+ +

STEPHANIE: It stands for Searchable Log of All Communication and Knowledge.

+ +

JOËL: That is incredibly clever. I wonder, is this the thing where they came up with that when they made the original name? Or did someone go back later on, you know, a few years into Slack's life and was like, you know what? Our name could be a cool acronym; here's an idea.

+ +

STEPHANIE: I'm pretty sure it was created in Slack's early days. And I think it might have even helped decide that Slack was going to be called Slack as opposed to some of the other contenders for the name of the software. But I think it's very accurate. And that could just be how I use Slack. I'm a very heavy search power user in Slack. [laughs]. So, I find it very apt.

+ +

You know, obviously, I use it a lot for finding conversations that happened. But I really do enjoy it as a source of discovery for a specific topic, or, you know, technical question or idea that I'm wanting to just, like, filter down a little bit beyond, like you said, the public internet. In fact, I have found it really useful for when you encounter errors that actually are specific to your domain or your app.

+ +

Obviously like, you will probably be less successful searching in your search engine for that because it includes, you know, context from your app that other people in the world don't have. But once you are narrowing it down to people at your company, I've been able to get over a lot of troubleshooting humps that way by searching in Slack because likely someone within my team has encountered it before.

+ +

JOËL: So, you mentioned searching for error messages in particular. And I feel like that is, like, its own, like, very specific searching skill separate from more general, like, how do I X-style questions. Does that distinction kind of line up with your mental map of the searching landscape?

+ +

STEPHANIE: Yeah. I guess the way that I just talked about it now was potentially a bit confusing because I was saying instead of how you might search for errors normally, but I did not talk about how you might search for errors normally. [laughs] But specifically, you know, if I'm popping error messages into my search engine, I am removing the parts of the stack trace that are specific to my app, right? Because I know that that will only kind of, like, clutter up my query and not be getting me towards a more helpful answer as to the source of my issue, especially if the issue is not my application code.

+ +

JOËL: Right. I want to give a shout-out to an article on the thoughtbot Blog with a wonderful name: Indiana Jones and the Crypt of Cryptic Error Messages by Louis Antonopoulos. All about how to take an error message that you get from some process in your console and how to make that give you results when you paste it into a search engine.

+ +

STEPHANIE: I love that name. Very cool.

+ +

JOËL: So, you've talked a little bit about the idea of searching some things that are not on the public internet. How do you feel about kind of internet knowledge bases, private wikis, that kind of thing? Have you had good success searching through those kinds of things?

+ +

STEPHANIE: Hmm, I would say mixed success, to be honest. But that's because of maybe more so the way that a team or a company documents information. The reason I say mixed results is because, a lot of the time, the results are outdated, and they're no longer relevant to me. And it doesn't take that much time to pass for something to become outdated, right? Because, like, the code is always changing. And if, you know, someone didn't go and update the documentation about the way that a system has changed, then I usually have to take the stuff that I'm kind of seeing in private wikis with a bit more skepticism, I would say.

+ +

JOËL: Yeah, I think my experience mirrors yours as well. Also, some private wikis have just become absolutely huge. And so, searches just return a lot of results that are not really relevant to what I'm searching for. The searching algorithms that these systems use are often much less powerful than something like Google. So, they often don't sort results in a way that are bringing relevant things up to the top. So, it's more work to kind of sift through all of the things I don't care about.

+ +

STEPHANIE: Yeah, bringing up the size of a wiki and, like, all of the pages, that is a good point because I see a lot of duplicate stuff, but that's just, like, slightly different. So, I'm not sure which one I'm supposed to believe. One really funny encounter that I had with a private wiki, or actually it was, like, a knowledge base article that was for the internal team...it was documenting actually a code process. So, it was documenting in more human-readable terms, like the steps an algorithm took to determine some result. But the whole document was prefaced by, "This information came from an email that was sent way long ago." [laughs]

+ +

JOËL: That's an epic start to a Wiki article.

+ +

STEPHANIE: Yeah. And there was another really funny line that said, "The reason for this logic is because of a decision made by (This person's name.)," like a business decision that (some random person name). No last name either, so I have no idea [laughs] who they could be referring to and any of the, like, historical context of why that happened. But I thought it was really funny as just a piece of, like, an artifact, of, at the time, when this was written, that meant something to someone, and that knowledge kind of has been diluted [laughs] over the years.

+ +

JOËL: Yeah, internal wikis, I feel like, are full of that, especially if they've had a few years to grow and the company has changed and evolved.

+ +

So, now it's time for hot takes.

+ +

STEPHANIE: Yeah, I'm ready for them.

+ +

JOËL: We are now in the fancy, new age of AI. Is ChatGPT going to make all of this episode obsolete?

+ +

STEPHANIE: I'm going to say no, but I'm also biased, and I'm not a ChatGPT enthusiast. I've said it on air. [laughs] I can't even say that I've used it. So, that's kind of where I'm coming from with all this. But I have heard from folks that, convenient as it may be, it is not always 100% accurate or successful.

+ +

And I think that one of the things I really like about kind of having agency over my search is that I can verify, as a human, the information that I'm seeing. So, you know, when you're, like, browsing a bunch of Stack Overflow questions and you see, you know, all these answers, at least you can, like, do a little bit of, like, investigation using context clues about who is answering the question, you know, like, what experience might they have?

+ +

If you encounter something on a blog post, for example, you can go to the about page on this person's blog and be like, who are you? [chuckles] And, like, what qualifies you to give this information? And I think that is really valuable for me in terms of evaluating whether I want to go down a path based on what I'm seeing.

+ +

JOËL: So, I've played with it a tiny, little bit, so not enough to have a good sample size. And I think it can be interesting for some of those less constrained kind of how do I style questions. I'm not necessarily looking for, like, an exact code sample. But even if it just points me towards, oh, I need to be looking at this particular class in this standard library and read through that documentation to build the thing that I want. Or maybe it links me to kind of the classic blog posts that people refer to when talking about this thing.

+ +

It's a good way sometimes to just narrow down when you're kind of faced with, you know, the infinity of the internet, and you're kind of like, oh, I don't even know where to start. It gives you some keywords or some threads to follow up on that I think can be really interesting.

+ +

STEPHANIE: The infinity of the internet. I love that phrase. I don't think I've heard it before, but it's very evocative for me [laughs]. And I like what you said about it helping you give a direction and to kind of surface those keywords. In fact, it almost kind of sounds like what I was mentioning earlier about using Slack for, right? And, in that case, the hive mind that I'm pulling from is my co-workers. But also, I can see how powerful it would be to leverage a tool that is guiding you based on the software community at large.

+ +

JOËL: Something I'd be curious to maybe lean into a little bit more are some of those slightly more specified questions where it does give you a code snippet, so something like writing a file to disk where, right now, it's, you know, five characters. I just pop up Alfred and type up Ruby F, and it gives you the file docs, and it's, you know, right there. There's usually an example at the top of the file. I copy-paste that and get working.

+ +

But maybe this would be a situation where some AI-assisted tools would be better. It could be searching through something like ChatGPT. It could be maybe even something like Co-pilot, where, you know, you just start typing a little bit, and it just fills out that skeleton of, like, oh, you want to write a file to disk in Ruby. Here's how it's typically done.

+ +

STEPHANIE: Yeah, you bring up a good point that, in some ways, even the approaches to searching we were talking about originally is still just building off of algorithms helping us to find what we're looking for, right?

+ +

Though, I did really want to recommend an awesome talk from Kevin Murphy, from a RailsConf a couple of years ago, that's called Browser History Confessional: Searching My Recent Searches. The main message that I really enjoyed from this talk was the idea of thinking about what you're searching for and why because that will, I think, help add a bit of, like, intentionality into that process. You know, it can be very overwhelming, but let that guide you a little bit.

+ +

One of the things that he mentions is the idea of revisiting your own assumptions with search. So, even if you think you know how to do something, or you might even know, like, how you might want to do it, just going to search to see if there's any other implementations that you haven't thought of that other people are doing that might inform how you approach a problem, or at least, like, make you feel even more confident about your original approach in the first place.

+ +

I thought that was really cool. That's not something that I do now, but definitely, something that I want to try is to be, like, I think I know how to do this, but let me see what other people are doing because that might spark something new.

+ +

JOËL: We'll put a link in the show notes to this talk. But I was lucky enough to see it in person. And also would like to second that recommendation. It is worth watching.

+ +

From this conversation that you and I have had, I'm having, like, two main takeaways. One is kind of what you just said, the idea of being a little bit more cognizant of, what kind of search am I doing? Is this a sort of broad how do I X, where I don't even really know where to start? Is this, like, something really specific where you just don't know what kind of syntax you want to use? Is it an error message where you just want to see what other people have done when they've encountered this? Or any other, like, more specific subcategories. And how being aware of that can help you search more effectively.

+ +

And secondly, don't limit yourself to the public internet. There's a lot of great information in your company's Slack or other instant messaging service, maybe some kind of documentation system internal, some kind of wiki. And those can be a great place to search as well.

+ +

STEPHANIE: If we missed any other cool searching tips or tricks or ways that we might be able to improve our processes for searching as developers, I would really love to hear about them. So, if any listeners out there want to write in with their thoughts, that would be super awesome.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Joël shares he has been getting more into long-form reading. Stephanie talks about the challenges she faced in a new project that required integrating with another company's system.

+ +

Together, they delve into the importance of search techniques for developers, covering various approaches to finding information online.

+ +
+ + + +

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 I've been trying to do recently is get more into long-form reading. I read quite a bit of technical content, but most of it are short articles, blog posts, that kind of thing. And I've not read, like, an actual software-related book in a few years, or at least not completed a software-related book. I've started a few chapters in a few. So, something I've been trying to do recently is set aside some time. It's on my calendar. Every week, I've got an hour sit down, read a long-form book, and take notes.

+ +

STEPHANIE: That's really cool. I actually really enjoy reading technical stuff in a long-form format. In fact, I was similarly kind of trying to do it, you know, once a week, spend a little bit of time in the mornings. And what was really nice about that is, especially if I had, like, a physical copy of the book, I could close my computer and just be completely focused on the content itself.

+ +

I also love blog posts and articles. We are always talking on the show about, you know, stuff we've read on the internet. But I think there's something very comprehensive, and you can dig really deep and get a very deeper understanding of a topic through a book that kind of has that continuity.

+ +

JOËL: Right. You can build up a larger idea have more depth. A larger idea can also cover more breadth. A good blog post, typically, is very focused on a single thing, the kind of thing that would really probably only be a single chapter in a book.

+ +

STEPHANIE: Has your note-taking system differed when you're applying it to something longer than just an article?

+ +

JOËL: So, what I try to do when I'm reading is I have just one giant note for the whole book. And I'm not trying to capture elements or, like, summarize a chapter necessarily. Instead, I'm trying to capture connections that I make. So, if there's a concept or an argument that reminds me of something perhaps similar in a different domain or a similar argument that I saw made by someone else in a different place, I'll capture notes on that. Or maybe it reminds me of a diagram that I drew the other day or of some work I did on a client six months ago.

+ +

And so, it's capturing all those connections is what I'm trying to do in my notes. And then, later on, I can kind of go back and synthesize those and say, okay, is there anything interesting here that I might want to pull out as an actual kind of idea note in my larger note-taking system?

+ +

STEPHANIE: Cool, yeah. I also do a similar thing where I have one big note for the whole book. And when I was doing this, I was even trying to summarize each chapter if I could or at least like jot down some takeaways or some insights or lines that I like felt were really compelling to me. And, like, something I would want to, in some ways, like, have created some, like, marker for me to remember, oh, I really liked something in this chapter. And then, from there, if I didn't capture the whole idea in my note, I knew where I could go to revisit the content.

+ +

JOËL: And did you find that was helpful for you when you came back to the book?

+ +

STEPHANIE: Yeah, it did. I usually can recall how, like, I felt reading something. You know, if something was really inspiring to me or really relatable, I can recall that, like, I had that experience or emotion. And it's just, like, trying to find where that was and that this is a system that has worked well for me.

+ +

Though, I will say that summarizing each chapter did kind of remind me of, like, how we learned how to take notes in school. [laughs] And I think, you know, middle school, or whatever, I recall a particular note-taking format, where you, you know, split the page up into, like, an outline with all the chapters, and you tried to summarize it. And so, it did feel a little bit like homework [laughs]. But I can also see the value in why they taught me how to do that.

+ +

JOËL: I was recently having a conversation with someone else about the idea of almost, like, assigning yourself the college-style essay question after finishing a book to try to synthesize what you learned.

+ +

STEPHANIE: Whoa, that's really cool. I can see how that would really, like, push you to synthesize and process what you might have just consumed. And, also, I'm so glad I'm not in school anymore [laughs] so that I don't have to do that on a regular basis. [laughs] I'm curious, Joël, what book are you reading right now?

+ +

JOËL: I've been reading Domain Modeling Made Functional, which is a really interesting intersection between functional programming, Domain-Driven Design (DDD), and a lot of interesting kind of type theory. And so, that sort of intersection of those three Venn diagrams leads to this really fascinating book that I've been going through. And I think it connects with a lot of other things that I've been thinking about.

+ +

So, I'll be reading and be like, oh, this reminds me of this concept that we have in test-driven development. Or this reminds me of this idea that we do when we do a product design sprint. And this reminds me of this principle from object-oriented design. And now I'm starting to make all these really interesting connections.

+ +

STEPHANIE: Awesome. Well, I hope to hear more about what you've learned or kind of what you're thinking about going through this book in future episodes.

+ +

JOËL: This is not the last time we hear about this book, I'm pretty sure. So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, I have a little bit of a work update to share. So, lately, I've been brought in to work on a feature that is integrating with another company's system. And the way that I was brought into this work was honestly just being assigned a task. And I was picking up this work, and I was kind of going through the requirements that had been specked out for me, and I was trying to get started. And then, I realized that I actually had a lot of questions. It just wasn't quite fully fleshed out for the level of detail that I needed for implementing.

+ +

And for the past couple of weeks, we've been chatting in Slack back and forth as I tried to get some of my questions answered. They are trying to help me, but also the things that I'm saying end up confusing them as well. And then, I end up having to try and figure out what they're looking for in order to properly respond to them.

+ +

And I had not met these people before. These are folks from that other company. And, you know, I'd only just seen their little Slack profile pictures. So, I didn't know who they were. I didn't know what role they had and kind of, like, what perspective they were coming to these conversations from. And after a while, I was feeling a little stressed out because we just kept having this back and forth, and not a lot of answers were coming to fruition.

+ +

And I really ended up needing the nudge of the manager on my client team to set up a meeting for us to all just talk synchronously. And I think I had...not that I had been avoiding it necessarily, but I guess I was under the impression that we were at the point where we could just, you know, shoot off a question in Slack and that there would be a clear path forward. But the more we kept pulling on that thread, the more I realized that, oh, like, we have a lot of ambiguity here.

+ +

And it really helped to meet them finally, not in person but, like, over a video call. [laughs] So, this happened yesterday. And, you know, even just, like, going around doing introductions, like, sharing what their role was at the company helped me just understand, like, who I was talking to. You know, I realized, oh, like, the level of technical details that I had been providing was maybe too much for this group.

+ +

And I was able to have a better understanding of what their needs were, like hearing kind of the problem that they had on their end. And I realized that, oh, like, they actually aren't going to provide me the details for implementation that I was looking for. That's up to me. But at least now I know what their higher-level needs are so that I can make the most informed decisions that I can.

+ +

JOËL: Fascinating. So, you thought that this was going to be, like, the technical team you're going to work with. And it turns out that this was not who they were.

+ +

STEPHANIE: In some ways. I think I thought by providing more technical details that would be helpful, but it ended up being more confusing for them. And I think I was similarly kind of frustrated because the ways that I was asking questions or communicating also wasn't getting me the answers that I needed as well.

+ +

But I felt really great after the meeting because I'm like, wow, you know, it doesn't have to be as stressful. You know, when you start getting into that back and forth on Slack, at least I find it a bit stressful. And it turns out that the antidote to that was just getting together and getting to know each other and hashing out the ambiguity, which does seem to work better in a more synchronous format.

+ +

JOËL: Do you have kind of a preference for synchronous versus asynchronous when it comes to communication?

+ +

STEPHANIE: That's a good question. I think it's kind of a pendulum for me. I'm in my asynchronous communication is a bit better for me right now phase, but only because I am just so burnt out on meetings a lot of the time that I'm like, oh, like, I really don't want to add another meeting to my calendar, especially because...I amend my statement; I'm burned out of meetings that don't go well. [laughs]

+ +

And this meeting, in particular, was different because, you know, I realized, like, oh, like, we are not on the same page, and so how can we get there? And kind of making sure that we were focused on that as an agenda. And I found that ultimately worked out better than the async situation that I was describing, which I'm thinking now, you know when things aren't clear, text-based communication certainly does not help with that.

+ +

JOËL: So, meetings, sometimes they're actually good.

+ +

STEPHANIE: Yeah, that's my enlightened discovery this week.

+ +

JOËL: So, this episode is kind of a special one. We've just hit 400 episodes of The Bike Shed. So, this is episode number 400. It's also my 50th Episode as a co-host.

+ +

STEPHANIE: Right. That's a huge deal. 400 is a really big number. I don't know if I've ever done 400 of anything before [laughs].

+ +

JOËL: The Bike Shed has been going on for almost ten years now. The first episode up on the website is from October 31st, 2014, so just about nine years from that first episode.

+ +

STEPHANIE: Wow. And it's still going strong. That's really awesome. I think it's really special to be a part of something that has been going on for this long. And, I don't know, maybe there are still listeners today from back in 2014. I would be really excited to hear if anyone out there has been listening to The Bike Shed throughout its whole lifespan. That's really cool.

+ +

JOËL: Looking back over the last 50-ish episodes you and I have done, do you have a favorite episode that we've recorded?

+ +

STEPHANIE: This may be a bit of recency bias. But the episode that we did about Software Heuristics I really enjoyed. Because I think we got to bring to the table some of the things we believe and the way we like to do things and kind of compare and contrast that with each other. And I always find people's processes very fascinating. Like, I want to know how you think and where your brain is at when you approach a problem. So, I really enjoyed that topic. What about you? Do you have any highlight episodes?

+ +

JOËL: I think there's probably two for me. One is the episode that you and I did on Specialized Vocabulary. I think this really touched on a lot of really interesting aspects of writing software that's going to scale, software that works for a team, and also kind of personal growth and exploration.

+ +

The second one that I think was really fun was the episode I did with Sara Jackson as a guest talking about Discrete Math because that's an episode that I got really excited about the topic. And right after recording the episode, it was the last day of the call for proposals for RailsConf. And I just took that raw excitement, put together a proposal, hit submit before the deadline. And it got accepted and got turned into a talk that I got to give on stage. So, that was, like, just a really fun journey from exciting episode with Sara and then, like, randomly turned into a conference talk.

+ +

STEPHANIE: That's awesome. That makes me feel so happy. Because it just reminds me about how the stuff we talk about on the show can really resonate with people, you know, enough to become a conference talk that people want to attend.

+ +

And I also really like that a lot of the topics we've gotten into in the past 50 episodes when we've taken over the show have been a bit more evergreen and just about, you know, the software development experience and a little bit less tied to specific news within the community.

+ +

Speaking of evergreen topics, today, I wanted to discuss with you an evergreen software skill, and that is searching or Search-Driven Development, even if you will.

+ +

JOËL: Gotta always get that three-letter acronym, something DD.

+ +

STEPHANIE: Yeah. I am really curious about how we're going to approach this topic because a lot of folks might joke that a big part of writing software is knowing what to Google. Do you agree with that statement or not?

+ +

JOËL: Yes and no. There's definitely value in knowing what to Google. It really depends on the kind of work that you're doing. I find that I don't Google that much these days. There are other tools that I use when I'm particularly, like, searching through documentation, but they tend to be less sort of open-ended questions and more where it's like, oh, let's get the actual documentation for this particular class or this particular method from the standard library.

+ +

STEPHANIE: Oh, interesting. I like that you pointed out that there are different scopes of things you might want to search for. So, am I hearing correctly that when you have something specific in mind that you are just trying to recall or wanting to look up, you know, you're still using search that way, but less so if you are trying to figure out how to approach solving a problem?

+ +

JOËL: So, oftentimes, if I'm working with a language that I already have familiarity with or a framework that I have familiarity with, I'm going to lean on something more specific. So, I'm going to say, okay, well, I don't exactly remember, like, the argument order for Enumerable's inject method. Is it memo then item, or item then memo? So, I'll just look it up. But I know that the inject method exists. I know what it does. I just don't remember the exact specifics of how to do that.

+ +

Or maybe I want to write a file to disk, and I don't remember the exact method or syntax to do that. There are some ways that you can do it using a bunch of instance methods. But I think there's also a class method that allows you to kind of do it all at once. So, maybe I just want to look up the documentation for the file class in Ruby and read through that a little bit. That's the kind of thing where I suppose I could also Google, you know, how to save file Ruby, something like that. But for those sorts of things where I already roughly know what I want to do, I find it's often easier just to go directly to the docs.

+ +

STEPHANIE: Yeah, yeah, that's a great tip. And I actually have a little shortcut to share. I started using DuckDuckGo as my search engine in the past year or so. And there's this really cool feature called Bangs for directly searching on specific sites. From my search bar, I can do, let's say, bang Rails and then my query. And it will search directly the Rails Guides website for me instead of, you know, just showing the normal other results that might come up in my regular search engine. And the same goes for bang Ruby doc. That one shows ruby-doc.org, which is my preferred [laughs] Ruby documentation website.

+ +

I've really been enjoying it because, you know, it just takes that extra step out of having to either navigate to the site itself first or starting more broadly with my search engine and then just scrolling to find the site that I'm looking for.

+ +

JOËL: Yeah. I think having some kind of dedicated flow helps a lot. I have a system that I use on my machine. It is Mac-specific. But I use a combination of the application Dash and the application Alfred. It allows me, with just a few keyboard shortcuts, to type out language names. So, I might say, you know, Ruby inject, and then it'll show me all the classes that have that method defined on it, hit Enter, and it pops up the documentation. It's downloaded on my machine, so it works offline. And it's just, you know, a few key presses. And that works really nicely for me.

+ +

STEPHANIE: Oh, offline search. That's really nice. Because then if you're coding on a plane or something, then [laughs] you don't have to be blocked because you can't look up that little, small piece of information you need to move forward. That's very cool.

+ +

JOËL: That is really cool. I don't know how often I've really leaned into the offline part of it. I don't know about you; I feel like I don't code on airplanes as much as I thought I would.

+ +

STEPHANIE: That's fair. I also don't code on airplanes, but the idea that I could is very compelling to me. [laughs]

+ +

JOËL: Absolutely. So, that's the kind of searches that I tend to do when I'm working in a language that I already know, kind of a day-to-day language that I'm using, or a framework that I'm already pretty familiar with. And this is just looking at all the things I haven't gotten to the point where I've fully memorized, but I have a good understanding of.

+ +

What about situations where maybe you're a little bit less familiar with? So maybe it's a new framework, or even, like, a situation where you're not really sure how to proceed. How do you search when there's more uncertainty?

+ +

STEPHANIE: Yeah, that's a good question. I do think I start a bit naively. The reason that we're able to be more specific and know exactly where to go is because we've built up this experience over time of scrolling through search results and clicking, you know, maybe all of them on the first page, even, and looking at them and being like, oh, like, this is not what I want. And then, seeing something else, it's like, oh, this is more helpful and kind of arrived at sources that we trust.

+ +

And so, if it's something new, I don't really mind just going for a basic search, right? And starting more broadly might even be helpful in that process of building up the experience to figure out which places are reputable for the thing that I'm trying to figure out.

+ +

JOËL: Yeah, especially when there's a whole new landscape, right? You don't really know what are the places that have good information and the ones that don't. For some things, there might be, like, an obvious first place to start. So, recently, I was on a project where I was trying to do an integration between a Rails app and a Snowflake data warehouse. And so, the first thing I did—I'm not randomly Googling—I went to the Snowflake website, their developer portal, and started reading through documentation for things.

+ +

Unfortunately, a lot of the documentation is a bit more corporatey and not really helpful for Ruby-specific implementation. So, there's a few pieces that were useful. There were some links that they had that sent me to some good places. But beyond that, I did have to drop to Google search and try to find out what kinds of other things the community had done that could be helpful.

+ +

Now, that first pass, though, did teach me some interesting things. It gave me some good keywords to search for. So, more than just Ruby plus Snowflake or something like that like, I knew that I likely was going to want to do some kind of connection via ODBC. So, now I could say, okay, Ruby plus ODBC integration, or Ruby plus ODBC driver and see what's happening there. And it turns out that one of the really common use cases for ODBC and Ruby is specifically to talk to Snowflake. And one of the top results was an article saying, "Hey, here's how you can use ODBC to get your Rails app to talk to Rails." And then I knew I struck gold.

+ +

STEPHANIE: That's really cool. The thing that I was picking up on in what you were saying is the idea of finding what is most relevant to you. And maybe that is something that the algorithm serves you because, like, it's, like, what a lot of people are searching for, you know, a lot of people are engaging with, or matching with all these keywords that you're using.

+ +

My little hack that I've been [chuckles] using is to use Slack and lean on other people who have maybe a little more, even just, like, a little more experience than me on the subject, and seeing, like, what things they're linking to, and what resources they're sharing. And I've found that to be really helpful as a place to start. Because, at that point like, my co-workers are narrowing down the really broad landscape for me.

+ +

JOËL: I really like how you're sort of you're redefining the question a little bit here. And that, I think, when we talk about search, there's almost this implicit assumption that search is going to be searching the public internet through Google or some other alternative search engine. But you're talking about actually searching from my private corpus of data, in this case, either thoughtbot or maybe the client's Slack conversations, and pulling up information there that might be much more relevant or much more specific to the work that you're trying to do.

+ +

STEPHANIE: Yeah. In some ways, I like to think of it as crowd-sourced but, like, a crowd that I trust and, you know, know is relevant to me and what I'm working on. I actually have a fun fact for you. Did you know that Slack is actually an acronym?

+ +

JOËL: No, I did not know that. What does it stand for?

+ +

STEPHANIE: It stands for Searchable Log of All Communication and Knowledge.

+ +

JOËL: That is incredibly clever. I wonder, is this the thing where they came up with that when they made the original name? Or did someone go back later on, you know, a few years into Slack's life and was like, you know what? Our name could be a cool acronym; here's an idea.

+ +

STEPHANIE: I'm pretty sure it was created in Slack's early days. And I think it might have even helped decide that Slack was going to be called Slack as opposed to some of the other contenders for the name of the software. But I think it's very accurate. And that could just be how I use Slack. I'm a very heavy search power user in Slack. [laughs]. So, I find it very apt.

+ +

You know, obviously, I use it a lot for finding conversations that happened. But I really do enjoy it as a source of discovery for a specific topic, or, you know, technical question or idea that I'm wanting to just, like, filter down a little bit beyond, like you said, the public internet. In fact, I have found it really useful for when you encounter errors that actually are specific to your domain or your app.

+ +

Obviously like, you will probably be less successful searching in your search engine for that because it includes, you know, context from your app that other people in the world don't have. But once you are narrowing it down to people at your company, I've been able to get over a lot of troubleshooting humps that way by searching in Slack because likely someone within my team has encountered it before.

+ +

JOËL: So, you mentioned searching for error messages in particular. And I feel like that is, like, its own, like, very specific searching skill separate from more general, like, how do I X-style questions. Does that distinction kind of line up with your mental map of the searching landscape?

+ +

STEPHANIE: Yeah. I guess the way that I just talked about it now was potentially a bit confusing because I was saying instead of how you might search for errors normally, but I did not talk about how you might search for errors normally. [laughs] But specifically, you know, if I'm popping error messages into my search engine, I am removing the parts of the stack trace that are specific to my app, right? Because I know that that will only kind of, like, clutter up my query and not be getting me towards a more helpful answer as to the source of my issue, especially if the issue is not my application code.

+ +

JOËL: Right. I want to give a shout-out to an article on the thoughtbot Blog with a wonderful name: Indiana Jones and the Crypt of Cryptic Error Messages by Louis Antonopoulos. All about how to take an error message that you get from some process in your console and how to make that give you results when you paste it into a search engine.

+ +

STEPHANIE: I love that name. Very cool.

+ +

JOËL: So, you've talked a little bit about the idea of searching some things that are not on the public internet. How do you feel about kind of internet knowledge bases, private wikis, that kind of thing? Have you had good success searching through those kinds of things?

+ +

STEPHANIE: Hmm, I would say mixed success, to be honest. But that's because of maybe more so the way that a team or a company documents information. The reason I say mixed results is because, a lot of the time, the results are outdated, and they're no longer relevant to me. And it doesn't take that much time to pass for something to become outdated, right? Because, like, the code is always changing. And if, you know, someone didn't go and update the documentation about the way that a system has changed, then I usually have to take the stuff that I'm kind of seeing in private wikis with a bit more skepticism, I would say.

+ +

JOËL: Yeah, I think my experience mirrors yours as well. Also, some private wikis have just become absolutely huge. And so, searches just return a lot of results that are not really relevant to what I'm searching for. The searching algorithms that these systems use are often much less powerful than something like Google. So, they often don't sort results in a way that are bringing relevant things up to the top. So, it's more work to kind of sift through all of the things I don't care about.

+ +

STEPHANIE: Yeah, bringing up the size of a wiki and, like, all of the pages, that is a good point because I see a lot of duplicate stuff, but that's just, like, slightly different. So, I'm not sure which one I'm supposed to believe. One really funny encounter that I had with a private wiki, or actually it was, like, a knowledge base article that was for the internal team...it was documenting actually a code process. So, it was documenting in more human-readable terms, like the steps an algorithm took to determine some result. But the whole document was prefaced by, "This information came from an email that was sent way long ago." [laughs]

+ +

JOËL: That's an epic start to a Wiki article.

+ +

STEPHANIE: Yeah. And there was another really funny line that said, "The reason for this logic is because of a decision made by (This person's name.)," like a business decision that (some random person name). No last name either, so I have no idea [laughs] who they could be referring to and any of the, like, historical context of why that happened. But I thought it was really funny as just a piece of, like, an artifact, of, at the time, when this was written, that meant something to someone, and that knowledge kind of has been diluted [laughs] over the years.

+ +

JOËL: Yeah, internal wikis, I feel like, are full of that, especially if they've had a few years to grow and the company has changed and evolved.

+ +

So, now it's time for hot takes.

+ +

STEPHANIE: Yeah, I'm ready for them.

+ +

JOËL: We are now in the fancy, new age of AI. Is ChatGPT going to make all of this episode obsolete?

+ +

STEPHANIE: I'm going to say no, but I'm also biased, and I'm not a ChatGPT enthusiast. I've said it on air. [laughs] I can't even say that I've used it. So, that's kind of where I'm coming from with all this. But I have heard from folks that, convenient as it may be, it is not always 100% accurate or successful.

+ +

And I think that one of the things I really like about kind of having agency over my search is that I can verify, as a human, the information that I'm seeing. So, you know, when you're, like, browsing a bunch of Stack Overflow questions and you see, you know, all these answers, at least you can, like, do a little bit of, like, investigation using context clues about who is answering the question, you know, like, what experience might they have?

+ +

If you encounter something on a blog post, for example, you can go to the about page on this person's blog and be like, who are you? [chuckles] And, like, what qualifies you to give this information? And I think that is really valuable for me in terms of evaluating whether I want to go down a path based on what I'm seeing.

+ +

JOËL: So, I've played with it a tiny, little bit, so not enough to have a good sample size. And I think it can be interesting for some of those less constrained kind of how do I style questions. I'm not necessarily looking for, like, an exact code sample. But even if it just points me towards, oh, I need to be looking at this particular class in this standard library and read through that documentation to build the thing that I want. Or maybe it links me to kind of the classic blog posts that people refer to when talking about this thing.

+ +

It's a good way sometimes to just narrow down when you're kind of faced with, you know, the infinity of the internet, and you're kind of like, oh, I don't even know where to start. It gives you some keywords or some threads to follow up on that I think can be really interesting.

+ +

STEPHANIE: The infinity of the internet. I love that phrase. I don't think I've heard it before, but it's very evocative for me [laughs]. And I like what you said about it helping you give a direction and to kind of surface those keywords. In fact, it almost kind of sounds like what I was mentioning earlier about using Slack for, right? And, in that case, the hive mind that I'm pulling from is my co-workers. But also, I can see how powerful it would be to leverage a tool that is guiding you based on the software community at large.

+ +

JOËL: Something I'd be curious to maybe lean into a little bit more are some of those slightly more specified questions where it does give you a code snippet, so something like writing a file to disk where, right now, it's, you know, five characters. I just pop up Alfred and type up Ruby F, and it gives you the file docs, and it's, you know, right there. There's usually an example at the top of the file. I copy-paste that and get working.

+ +

But maybe this would be a situation where some AI-assisted tools would be better. It could be searching through something like ChatGPT. It could be maybe even something like Co-pilot, where, you know, you just start typing a little bit, and it just fills out that skeleton of, like, oh, you want to write a file to disk in Ruby. Here's how it's typically done.

+ +

STEPHANIE: Yeah, you bring up a good point that, in some ways, even the approaches to searching we were talking about originally is still just building off of algorithms helping us to find what we're looking for, right?

+ +

Though, I did really want to recommend an awesome talk from Kevin Murphy, from a RailsConf a couple of years ago, that's called Browser History Confessional: Searching My Recent Searches. The main message that I really enjoyed from this talk was the idea of thinking about what you're searching for and why because that will, I think, help add a bit of, like, intentionality into that process. You know, it can be very overwhelming, but let that guide you a little bit.

+ +

One of the things that he mentions is the idea of revisiting your own assumptions with search. So, even if you think you know how to do something, or you might even know, like, how you might want to do it, just going to search to see if there's any other implementations that you haven't thought of that other people are doing that might inform how you approach a problem, or at least, like, make you feel even more confident about your original approach in the first place.

+ +

I thought that was really cool. That's not something that I do now, but definitely, something that I want to try is to be, like, I think I know how to do this, but let me see what other people are doing because that might spark something new.

+ +

JOËL: We'll put a link in the show notes to this talk. But I was lucky enough to see it in person. And also would like to second that recommendation. It is worth watching.

+ +

From this conversation that you and I have had, I'm having, like, two main takeaways. One is kind of what you just said, the idea of being a little bit more cognizant of, what kind of search am I doing? Is this a sort of broad how do I X, where I don't even really know where to start? Is this, like, something really specific where you just don't know what kind of syntax you want to use? Is it an error message where you just want to see what other people have done when they've encountered this? Or any other, like, more specific subcategories. And how being aware of that can help you search more effectively.

+ +

And secondly, don't limit yourself to the public internet. There's a lot of great information in your company's Slack or other instant messaging service, maybe some kind of documentation system internal, some kind of wiki. And those can be a great place to search as well.

+ +

STEPHANIE: If we missed any other cool searching tips or tricks or ways that we might be able to improve our processes for searching as developers, I would really love to hear about them. So, if any listeners out there want to write in with their thoughts, that would be super awesome.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+v_dmp2B_ + + ]]> + + Joël Quenneville + Stephanie Minn + + + 399: Scaling Code Ownership and Accountability + https://bikeshed.thoughtbot.com/399 + 67b986cf-2958-4537-8eff-e84acea9dd57 + Tue, 29 Aug 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie experienced bike camping. Joël describes his experience during a week when he's in between projects. + +Stephanie and Joël discuss the concept of code ownership, the mechanisms to enforce it, and the balance between bureaucracy and collaboration. They highlight the challenges and benefits of these systems in large codebases and emphasize that scaling a team is as much a social challenge as it is a technical one. + 34:16 + no + + + Stephanie experienced bike camping. Joël describes his experience during a week when he's in between projects. +Stephanie and Joël discuss the concept of code ownership, the mechanisms to enforce it, and the balance between bureaucracy and collaboration. They highlight the challenges and benefits of these systems in large codebases and emphasize that scaling a team is as much a social challenge as it is a technical one. +Out Our Front Door (https://www.oofd.org/) +Conway’s Law (https://en.wikipedia.org/wiki/Conway%27s_law) +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: This weekend, I went bike camping for the first time. So, it was my turn to try out the padded bike shorts and go out on a long ride, combining two things that I really enjoy: biking and camping. It was so awesome. We did about 30 miles outside of the city of Chicago to close to the Indiana border. And we were at a campground that's owned by the forest preserves where I'm at. It was so much fun. +I packed all my stuff, including my tent and sleeping bags. And it was something that I never really imagined myself doing, but I'm really glad I did because I think it'll be something that I want to kind of do more of in the future, maybe even do multi-day bike camping trips. +JOËL: So, what's your verdict on the bike shorts? +STEPHANIE: Definitely a big help. Instead of feeling a little bit sore an hour or so along the bike ride, it kind of helped me stay comfortable quite a bit longer, which was really nice. +JOËL: Would you do this kind of trip again? +STEPHANIE: I think I would do it again. I think the next step for me is maybe to go even farther, maybe do multiple stops. Yeah, I was talking to my partner about it who came along with me, and he was saying, like, "Yeah, now that you've done that many miles in one day and, you know, camped overnight, you can really go anywhere. [laughs] You can go as far as you want." +And I thought that was pretty cool because, yeah, he's kind of right, where I can just pack up and go and, you know, who knows where I'll end up? Not that I would actually do that because of my need to plan. [laughs] I'm not that go-with-the-flow. But there was definitely something really special about being able to get from A to B with just, like, my physical body and not relying on any other kind of transportation. +JOËL: Yeah, there's a certain freedom to that spontaneity that's really nice. +STEPHANIE: Yeah. And I actually went with a group called Out Our Front Door. And if anyone is in Chicago and is interested in doing this kind of thing, they do group bike camping adventures, and they make it really accessible. So, it's a very easy pace. You are with a group, so it's just really fun. They make it really safe. And I had a really great time. There was about 60 of us actually at camp, and they had rented out the entire campground, so it was just our group. +And they even had a live reggae band come out and play music for us while we had dinner. And that was a really nice way for me to do it as a first-timer because there was stuff already planned for me, like meals. And I didn't have to worry about that because I was already, you know, just worrying about making sure I got there with all of my stuff. So, if that sounds interesting to you and you're in Chicagoland, definitely check them out. +JOËL: That's a great way to bring in newer people to say, let's have a semi-organized thing, where all you have to focus on is the skill itself, you know, can I bike the 30 miles? Rather than planning all the logistics around it. +STEPHANIE: Yeah, exactly. Joël, what's new in your world? +JOËL: So, speaking of planning and logistics, this week, I'm in between projects at thoughtbot. And on the Boost team that I'm on, we've introduced a kind of special rotation for people who are in between projects where we have an internal project, where just internal strategic initiatives that we want to push forward. Whoever is unbooked gets to work on that. So, it's a small team with a very high churn. +And one of the things that we do is every week; we have somebody act as the project manager for that team. And I was in between projects this week. I was assigned that project manager job. And so, I've been doing that in addition to some of the tickets myself, and that's been really interesting. +STEPHANIE: Cool. I really like how that role is rotated among team members. +JOËL: Yes. And the whole team itself is very high churn. So, somebody might be on that for just one week and then rotate off, and a new person comes in; maybe someone's on there a couple of weeks while we're waiting to find them a project. +But we're always looking to prioritize booking people onto new client projects. And so, whoever is on that team, typically, is there for a short period of time. And so that means that the project manager role has to rotate a lot. But also, just in general, as you're managing tickets, you have to deal with the fact that people are not going to be on this project long-term. This is just, they're here for a few days, and they get some things done, and then they're moving off. And I think that presents some unique challenges in terms of the project management side of things. +STEPHANIE: Yeah. What kind of challenges did you find interesting in this role for the week that you were on it? +JOËL: So, in particular, I think making sure that outstanding work from the previous week gets done, especially when the people who were working on that ticket are no longer working on it. So, they may have done some partial work and then moved on to something else. And then, you have to ascertain the state of the ticket. Has it been completed? If it's only partial, what parts have and haven't? Can this be passed on to somebody else? Is there some unique knowledge that the previous person had? Has the code been pushed up? That kind of thing. +STEPHANIE: So, that reminds me of something I heard about the idea of being expendable. You know, there are certain industries where anyone else with that skill set can kind of step in and take over for another worker without a lot of issues, and they can continue on doing that work. So, I'm thinking about, you know, maybe doctors or pharmacists where they have that, like, shared skill set, and everything is documented enough so that they can just take whatever their case is. And if someone is out, it's not a big deal because people can just step in. And I'm curious about if this is something that could work for software development. +JOËL: I think it is important to have a team where nobody is irreplaceable. When it comes down to individual tickets, one of the things that I've been pushing for is that, at the end of the week, I would like to not see any tickets remain in the in-progress column. We're using a Kanban-style board. So, ideally, all work either moves to the done column or moves to the to-be-done column for next week. And it's no longer owned by anyone, so people have removed their faces from it. Ideally, though, if you pick up a ticket during the week, you get it to completion. +So, one thing that I've been really pushing with our team this week is splitting tickets up. If this feels like it's bigger than a few days, then it needs to be split up, and part of it gets done moves to the done column. Part of it might be some work that somebody else is going to pick up next week; move that to the to-do column. And so, that way, at the end of the week, we have, ideally, a column full of things that were pushed over the finish line that are done. +And then, we have a column of things to be done next week that nobody has kind of called dibs on yet. So that then next week, when we have a new group of people coming in, you don't just look at this column of to-do things. It's like, well, all of these have someone's face on them. I'm not able to pick up anything, so now what do I do? By having those all kind of fresh and available to be picked up, you make it easy for the next batch of people to hit the ground running on Monday morning. +STEPHANIE: That's really interesting. You said you were doing this Kanban style, but it almost kind of sounds like one-week sprints in a way. +JOËL: Kind of, because the way we book people onto clients is typically on a per-week basis. And so, if there's going to be a gap between clients, typically, it's in increments of a week. Because they're on the project for a week, it doesn't necessarily mean that we're tracking the tickets on a per-week thing. So, it's not like, oh, we're committing to doing all of these tickets by the end of a particular time or anything like that. +We are working in a more Kanban style where there's a backlog, and you pull tickets, and whatever gets done gets done. What we do try to do, though, is not have individual tickets hang in the in-progress column over a week boundary. So, there's a nuance there. I guess there's some ways in which maybe it feels a little bit sprint-like. But I think we are running in much more of a Kanban-style workflow. +STEPHANIE: Yeah, that makes sense. +JOËL: It's really to deal with that churn and the idea that even though the ticket might stick around for a while or maybe it gets split up into multiple small tickets, the people are switching constantly. And so, making the workflow play nicely with the fact that the team is churning on a weekly basis kind of adds an extra, you know, a little bit of spice to the project management side of things. +STEPHANIE: Did you find yourself being the one to break down tickets to make sure that they weren't larger than a week's worth of work? Or did you work with the developer themselves to find opportunities to break out what they were working on if we got to the mid-week and progress wasn't looking like it would be completed by the end? +JOËL: I've left this up to individual developers. This is more of a broad conversation I had with our team, kind of saying, "Hey, here's our goal. We want to get some things done by the end of the week. If we don't think we can get them done, here are some strategies I recommend. I'm available to pair if people want it." But I didn't go through and estimate all the tickets and split them up. +I did a little bit of, like, grooming ahead of time. So, I had a sense of when we started the week if tickets felt roughly sized correctly. But oftentimes, you know, that kind of thing, you start working on it, and then you realize, wait a minute, this is a bigger ticket than I thought. +STEPHANIE: Yeah. I think even just having someone check in and be like, "Hey, how is progress? Can I support you in making sure that you're able to get to somewhere that feels completed by the end of the week so that the rest of the work is set up for someone new to take on?" That seems really valuable to me. +Because as an individual, I'm like, yeah, I don't know, I'm maybe heads down just deep and trying to get my thing done, but maybe not so aware of progress and relative to how much time I've spent on it. And having just someone prompt me on that could help kind of pull myself out a little bit, you know, come out for some air and be like, oh, actually, you know, this is a good spot for me to break this down. +Do you have any insights into this week that you might be bringing with you into client work or anything like that? +JOËL: And I think this has just given me an even deeper appreciation for breaking tickets down. Because of that arbitrary end-of-the-week deadline, I think that forces more tickets to break down in a way that I might say, oh, well, I picked up a ticket on Thursday for a client. It can totally bleed into next week; that's fine. It's still a fairly short ticket, just, you know, I started the work later. And so, trying to make sure that tickets get scoped down really tightly, I think, is an area where I could probably benefit from that discipline on client projects as well. You know, even if I'm not doing it to the extreme, I'm doing it this week. +STEPHANIE: Yeah. I would be really curious to find out if next week the folks who are on this project feel like they're in a good spot to, you know, keep on making forward momentum because they can just pull from the backlog and not have to go and do that knowledge transfer. +JOËL: Right. I will see with all of this, right? Maybe even with all the conversations and things, maybe we'll end the week, and I'll have 10 cards in the in-progress column. And it'll be like, okay, we tried a thing this week, mixed success. How do we want to iterate on that idea next week? Potentially with a different team. +STEPHANIE: Right, exactly. +JOËL: I feel like one way to maybe summarize the type of work that I was doing this week is that it's a kind of a scaling challenge. But over time, the team itself is small, but it's constantly churning. And I think you've been working on a team where it's kind of had a similar problem but in a different dimension. You're scaling over team size, actually a massively large team, and seeing some of the challenges there. What are some of the things that you've been facing? +STEPHANIE: Yeah. So, my current client project, I'm working on a codebase where there are hundreds of developers also working and committing to this codebase daily. And this codebase is really massive. There is so much stuff going on. And I've really only explored the world of the particular team that I'm on. +But I recently had to do a little bit of work in some code that is owned by a different team. And I actually really appreciated the way that we were able to collaborate across, I guess, ownership boundaries. And I was really interested in talking about some of the different ways that we've seen the idea of, like, who is owning, and, like, who is accountable for areas of the codebase once you reach a certain size. +So, what was really convenient about the way that I was working was that in my pull request, there was an automated step that told me I needed specific owner approval on the code that I was writing because I was touching some files that were owned by a different team. And it gave me all of the handles for the people on that team. So, I knew who to go talk to. +And it ended up being that that team had a public Slack channel specifically for people outside to ask them questions about their domain. And they had a rotating ambassador system. And so, in the Slack channel, in the channel topic, it said who was the ambassador for that week. So, you know, I saw who it was. I got to @ them and say, like, "Hey, like, I'm working on some of these files for this feature for my team. And, like, here's my pull request. Could you give me a review?" +JOËL: The more you're describing this, the more this is feeling very large team, almost bureaucratic systems. I'm hearing public Slack channels, which implies that teams have private Slack channels. I'm hearing, like, a rotating ambassador. +One word that you mentioned that I'd like to dig into a little bit is the idea of ownership because I think that the concept of ownership is present on probably most teams, but it probably means wildly varying things. And it sounds like on your team, it's a very kind of codified thing. So, what does ownership look like on your project? +STEPHANIE: Yeah, I love that you asked that question because you're right; it is codified, literally, in the codebase. There are ownership files that are in the repo itself where they've specified, like, all of the models that a team owns, you know, down to the names of the files themselves, or maybe a namespace. It has the team name and all of the team members' handles. So, that's how it was able to tell me in an automated way, like, hey, reach out to these people. +It was really interesting because it was pretty frictionless on my end, where all I had to do was see that, you know, I couldn't submit my pull request until I got that approval. But it was enough friction to be, like, well, you can't just, you know, change files in this domain without someone with extra context taking a look. +JOËL: This reminds me a little bit of a system that GitHub has where you have this CODEOWNERS file that you can add to a repo. Have you messed around with that at all, or kind of seen how that looks? +STEPHANIE: I have a little bit. I think I've only seen it in the context of being notified that someone is wanting to submit a pull request, but I'm not sure if it does gate merging based on ownership. Do you know if that's the case? +JOËL: I don't. I think you can set it up to automatically request reviews from owners. And on a large repo, the owner could be...I assume this is based maybe on directories, or it might be a regex pattern. I forget the exact details. But you can have owners for partial parts of the code instead of owners of the entire repository. So, then, if you make a change to a particular part of the code, it would ping the correct person automatically to review your code, which sounds like a really nice feature. +STEPHANIE: Yeah, absolutely. I think for the project that I'm working on, this definitely seemed like a custom process that they, at one point, decided to enforce. I'm not really sure about the history of how this came to be. But I found it actually quite a good way to meet people who are working in other parts of the codebase. +The person who happened to be ambassador that I pinged was so helpful in just, you know, making sure that I kind of understood the parts of the code that they owned that were honestly, like, quite complex. Like, I would not have felt confident just going ahead and making those changes necessarily myself because this is a pretty legacy codebase. There are quite a few gotchas, and they were able to point some [laughs] of them out to me. +Yeah, having that extra confidence was helpful for the particular feature I was working on. But it did also kind of give me a little pause because I've not worked at such a scale where there was so much uncertainty about the domain and that being so diffused across like I mentioned, hundreds of people. +JOËL: Do you think that this ownership system that's in place helps manage the complexity of scaling up to a team of hundreds of developers? Or does it feel like it kind of just adds a lot of process that gets in your way? +STEPHANIE: Ooh, that's a good question. It seems like kind of a chicken-and-the-egg situation because I felt better with someone else's input, right? Like, with someone else with more domain knowledge than me about what I was touching to be, like, "Yeah, like, this looks good to me," giving the plus one. +Whereas if that didn't exist, maybe I would have tried to seek it out on my own. But I would not have known where to start, right? I would have to ask around and be like, "Hey, like, who has worked in this directory before?" or whatever. Or I could have just went ahead and merged my code and hope my lack of context didn't really cause any huge problems, like outside of what was covered by the tests. But this is helpful for, like, where the codebase is at, you know, and the size it has grown. +JOËL: Do you think requiring an owner to review the code puts maybe an undue burden on the person who's the owner and that they might end up spending a lot of time reviewing code because they now kind of manage that part of the app? +STEPHANIE: Yeah, that's a really good question. I think it can. But I also feel a little better that that role is rotated, that everyone on the team gets the opportunity to really, like, focus on that. And I'm pretty sure the way it works is that that is their main focus for the sprint, or the week, or whatever, and that they're not assigned any other feature work but to prioritize being that ambassador. So, in some ways, that is a lot of process, right? +And there is that trade-off of having to allocate someone specific to answer people's questions. But at least from what I've seen, it does seem like a necessity because people do have questions, right? And I think they have figured out a system where it's very clear who you're supposed to talk to, and that accountability aspect of it has been met. Because I've also, like, worked on teams where that role is not well defined. People don't want to do it. And it's almost kind of a bystander effect where someone asks a question, but no one is specifically responsible for answering it, and so no one answers it. +JOËL: Oh yeah. Yes. And then you get kind of the cost of the bureaucracy without the benefits of kind of diffusing that knowledge. +So, we've been talking a lot about how this kind of ownership system can be really beneficial despite the overhead for a team that's 200 or 300 developers and where nobody knows all of the code or all of the nuances. And kind of at the other extreme, it's absolutely not worth it for a team of two or three developers where everybody knows the code, and there's kind of shared ownership of the project. +Somewhere in between, there is where you start having maybe some of those conversations about scaling the team, and do we need to introduce more process? In your experience, where do you think introducing some sort of ownership system like this starts becoming valuable? Or maybe what are some of the questions that a team should ask themselves to gauge, like, at the size we're at right now, would we get value from an ownership system? +STEPHANIE: Yeah, that's a really good point because as you were saying that, I was just starting to think of, yeah, I've certainly worked on projects where I have reviewed every piece of code that is to be merged, right? And then, at some point, that starts to change where, like, I can't do that anymore. And that transition has always been really interesting to me. +And then, I think there is, like you mentioned, another one where it's like, okay, now we aren't able to review everything, but, like, how do we trust that the code that is being merged, even if we don't all share that same context, is up to the quality we want it or is bug-free? Because without that context, there's always the opportunity that something might be missed. +I think I've seen that on teams, you know, really look like more bugs than usual, right? And maybe there is, like, actually, like, a big problem, and the site is down. And maybe there is, like, a post-mortem or something to discuss, like, why this happened. And, you know, it turns out that the siloing or, like, the lack of context sharing was partly involved. +And so, I do think there are definitely symptoms when we're starting to firefight a little more [chuckles] that might be kind of an indicator that the app has grown to a point where some context is being lost, and there are not guardrails in place to do our best to, like, share it, like, when we can and not when it's too late. +JOËL: Would it be fair to say that your recommendation is the team should not have an ownership system and kind of stick to everybody reviews all the code as they grow until they start hitting actual pain points, such as real bugs caused and, at that point, let that pain or maybe even the post-mortem be the thing that triggers the introduction of an ownership system? +STEPHANIE: I think so. I have not seen something like that proactively introduced. I would be curious if anyone has experienced something like that. But, you know, I think it's okay for change to be a little painful, right? And that's part of the growing pains of becoming a larger team, or organization, or codebase and continuing to reevaluate. Though, I guess I would be a little cautious about, you know, jumping straight to introducing processes or policies, right? Because those can be really hard to undo if they end up not being actually helpful for the root cause of the problem. +But, like, how you experimented with making sure that, you know, we didn't have any in-progress tickets for that project. The idea of just trying something and seeing how it works and kind of getting the team's feedback that is really valuable to me, at least as an IC. And, yeah, just making sure, like, you know, hearing from all of your team members on how those processes are changing the way they work and if it's feeling good or not. +Like I said, I enjoyed the process on my client project because it helped me feel more confident that the code that I was changing...because I can't possibly gain all of the knowledge that the owners of that area of the code have. It's just not going to happen. But also, I can imagine it being maybe not so good for someone else, right? It kind of being a barrier or being frustrating because, oh no, they really need to merge the code. And maybe they made the smallest change in a file owned by another team, right? And having to jump through that hoop. +JOËL: Yeah, that has absolutely never happened to me. +STEPHANIE: Really? Because it sounds like it has. +[laughter] +JOËL: Yes, it absolutely has. We've been kind of throwing around the idea of ownership the idea of team almost interchangeably as if they're one-to-one. And I want to lean a little bit into this idea of the team. Because I think there's an implicit assumption here that, within a team, there's enough knowledge sharing that happens, enough shared context, that everybody can kind of understand all of the code for their team, and that knowledge is just shared around, so you don't need these extra processes within teams. +But maybe once you start having multiple teams as part of your engineering department, then there starts to be some friction or some lost context that needs some mechanism to get around. Does that sound about right to you? +STEPHANIE: Ooh, I think that depends because even within my team, we are working on different projects, and I am definitely not on top of, you know, what some other folks are working on. And even within our team, there are silos. The difference there, though, is that I know who they are. Like I still am in contact with them in our daily syncs, that the barrier to finding someone who has the right information is much lower. +So, yeah, I think that is definitely a part of it, too, if, like...I think just the social barrier, even of, like, reaching out to someone you don't know and being like, "Hey, like, can you review my code?" that is [laughs] kind of...can be a little scary. And the dynamics definitely feel different within a team and between teams. +JOËL: Yeah, and definitely just the idea of, like, someone you see every day for your daily sync, you're going to feel much more comfortable reaching out to them for help or for a quick review than to a total stranger. +So, it's interesting that you mentioned the social aspects of things. I don't know if you're familiar with Conway's Law, the idea that the technical structures of our code, over time, end up reflecting the social structures of our teams. +STEPHANIE: Yeah, that is something that makes a lot of sense on the project that I'm working on now, where the boundaries, like I mentioned, between teams and between different namespaces are semi-rigid, I suppose, right? Rigid enough that, you know, there is a process but not so high that it becomes a burden, at least in my opinion. +But for another feature that I worked on, I actually had to interact with an external system that's owned more by the parent company of my current client. And that process was definitely more rigid. And I had to figure out who to email and had to, you know, look up this person's profile in the company directory to make sure that, you know, I was talking to the right person who had information that was relevant to me. +And then, you know, even, like, the technical aspect of talking to this external service had a lot of various barriers and, you know, special authorization and configuration that I needed to set up. So, definitely felt that in terms of the different levels of ease and talking to systems owned by different parties. +JOËL: So, the fact that there's, like, an actual, like, departmental or even, like, corporate boundary, definitely showed up in, like, a very hard boundary in the code as well. +STEPHANIE: Yeah, absolutely. +JOËL: And I think taking this to an extreme, I've seen this happen when teams want to introduce microservices. And oftentimes, the boundaries of those microservices are not necessarily driven entirely by technical reasons, but they're often by social reasons. So, we can say, hey, this team is going to own this service, and everybody else only needs to interact with a public API. And we can make all sorts of changes internally, and you never need to know that. They will never break your code. And also, we don't need to bother each other or feel the need to fully deeply understand the internals of each system. +STEPHANIE: Yeah. Once you're introducing APIs that are accessible to a certain group of people and having to navigate, you know, making changes to the API or aligning in the expected structure of the, you know, communication that you're sending between them, that is definitely a pretty rigid boundary [laughs] and ends up being a lot of overhead to talk to those systems. And I certainly have been in the position of trying to communicate with the people who built and designed those systems and figuring out how to get on the same page. +And even just recently, I was accidentally sending something as an array, and they were expecting it as a string. And that caused all these problems of making the request happen, you know, successfully. And we didn't even realize it until someone pulled out the doc that had the API schema and pointed out that there was some miscommunication along the way. +JOËL: And that can be such a hard boundary around even, like, the idea of ownership. So, you were talking about how, earlier, when you were working in code that's maybe owned by another team, they might want to review it before it gets merged. So, there's a bit of a gatekeeping there. +When a team transitions fully to microservices, I've seen it go almost, like, more extreme where it's even, like, you don't even change the code. You submit a ticket into our system. We will prioritize it, and then eventually, we will build your feature. But you don't even get to make a change to the code and have us approve it. We're going to make all that because we own it. So, it kind of feels like taking that ownership idea and then just really running to a full extreme. +STEPHANIE: Yeah, right. That makes a lot of sense in the lens of Conway's Law if those are the processes they have in place for navigating cross-team collaboration or communication. Because, at some point, maybe they just reached a level where it had to be enforced that way because maybe things were getting dropped, or more casual lower barrier connection was too overwhelming or just not working for the organization. +JOËL: I think what I've been hearing just now and then just more broadly throughout the episode is that while there's a lot of interesting technical solutions that can make things better, at its root, scaling a team is a social problem. And it's all about how your teams communicate with each other so that you can scale smoothly and that the system doesn't suffer from adding more people. +STEPHANIE: Yeah. I think this is an area where I would love to hear any thoughts from our listeners about how their organizations handle something similar because I find all of this really interesting. And, you know, it ends up impacting my day-to-day work in a very real way. And so, if other places have figured out how that scaling and, you know, social and technical boundaries work in a way that feels good, I would love to know. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. +Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie experienced bike camping. Joël describes his experience during a week when he's in between projects.

+ +

Stephanie and Joël discuss the concept of code ownership, the mechanisms to enforce it, and the balance between bureaucracy and collaboration. They highlight the challenges and benefits of these systems in large codebases and emphasize that scaling a team is as much a social challenge as it is a technical one.

+ +
+ + + +

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: This weekend, I went bike camping for the first time. So, it was my turn to try out the padded bike shorts and go out on a long ride, combining two things that I really enjoy: biking and camping. It was so awesome. We did about 30 miles outside of the city of Chicago to close to the Indiana border. And we were at a campground that's owned by the forest preserves where I'm at. It was so much fun.

+ +

I packed all my stuff, including my tent and sleeping bags. And it was something that I never really imagined myself doing, but I'm really glad I did because I think it'll be something that I want to kind of do more of in the future, maybe even do multi-day bike camping trips.

+ +

JOËL: So, what's your verdict on the bike shorts?

+ +

STEPHANIE: Definitely a big help. Instead of feeling a little bit sore an hour or so along the bike ride, it kind of helped me stay comfortable quite a bit longer, which was really nice.

+ +

JOËL: Would you do this kind of trip again?

+ +

STEPHANIE: I think I would do it again. I think the next step for me is maybe to go even farther, maybe do multiple stops. Yeah, I was talking to my partner about it who came along with me, and he was saying, like, "Yeah, now that you've done that many miles in one day and, you know, camped overnight, you can really go anywhere. [laughs] You can go as far as you want."

+ +

And I thought that was pretty cool because, yeah, he's kind of right, where I can just pack up and go and, you know, who knows where I'll end up? Not that I would actually do that because of my need to plan. [laughs] I'm not that go-with-the-flow. But there was definitely something really special about being able to get from A to B with just, like, my physical body and not relying on any other kind of transportation.

+ +

JOËL: Yeah, there's a certain freedom to that spontaneity that's really nice.

+ +

STEPHANIE: Yeah. And I actually went with a group called Out Our Front Door. And if anyone is in Chicago and is interested in doing this kind of thing, they do group bike camping adventures, and they make it really accessible. So, it's a very easy pace. You are with a group, so it's just really fun. They make it really safe. And I had a really great time. There was about 60 of us actually at camp, and they had rented out the entire campground, so it was just our group.

+ +

And they even had a live reggae band come out and play music for us while we had dinner. And that was a really nice way for me to do it as a first-timer because there was stuff already planned for me, like meals. And I didn't have to worry about that because I was already, you know, just worrying about making sure I got there with all of my stuff. So, if that sounds interesting to you and you're in Chicagoland, definitely check them out.

+ +

JOËL: That's a great way to bring in newer people to say, let's have a semi-organized thing, where all you have to focus on is the skill itself, you know, can I bike the 30 miles? Rather than planning all the logistics around it.

+ +

STEPHANIE: Yeah, exactly. Joël, what's new in your world?

+ +

JOËL: So, speaking of planning and logistics, this week, I'm in between projects at thoughtbot. And on the Boost team that I'm on, we've introduced a kind of special rotation for people who are in between projects where we have an internal project, where just internal strategic initiatives that we want to push forward. Whoever is unbooked gets to work on that. So, it's a small team with a very high churn.

+ +

And one of the things that we do is every week; we have somebody act as the project manager for that team. And I was in between projects this week. I was assigned that project manager job. And so, I've been doing that in addition to some of the tickets myself, and that's been really interesting.

+ +

STEPHANIE: Cool. I really like how that role is rotated among team members.

+ +

JOËL: Yes. And the whole team itself is very high churn. So, somebody might be on that for just one week and then rotate off, and a new person comes in; maybe someone's on there a couple of weeks while we're waiting to find them a project.

+ +

But we're always looking to prioritize booking people onto new client projects. And so, whoever is on that team, typically, is there for a short period of time. And so that means that the project manager role has to rotate a lot. But also, just in general, as you're managing tickets, you have to deal with the fact that people are not going to be on this project long-term. This is just, they're here for a few days, and they get some things done, and then they're moving off. And I think that presents some unique challenges in terms of the project management side of things.

+ +

STEPHANIE: Yeah. What kind of challenges did you find interesting in this role for the week that you were on it?

+ +

JOËL: So, in particular, I think making sure that outstanding work from the previous week gets done, especially when the people who were working on that ticket are no longer working on it. So, they may have done some partial work and then moved on to something else. And then, you have to ascertain the state of the ticket. Has it been completed? If it's only partial, what parts have and haven't? Can this be passed on to somebody else? Is there some unique knowledge that the previous person had? Has the code been pushed up? That kind of thing.

+ +

STEPHANIE: So, that reminds me of something I heard about the idea of being expendable. You know, there are certain industries where anyone else with that skill set can kind of step in and take over for another worker without a lot of issues, and they can continue on doing that work. So, I'm thinking about, you know, maybe doctors or pharmacists where they have that, like, shared skill set, and everything is documented enough so that they can just take whatever their case is. And if someone is out, it's not a big deal because people can just step in. And I'm curious about if this is something that could work for software development.

+ +

JOËL: I think it is important to have a team where nobody is irreplaceable. When it comes down to individual tickets, one of the things that I've been pushing for is that, at the end of the week, I would like to not see any tickets remain in the in-progress column. We're using a Kanban-style board. So, ideally, all work either moves to the done column or moves to the to-be-done column for next week. And it's no longer owned by anyone, so people have removed their faces from it. Ideally, though, if you pick up a ticket during the week, you get it to completion.

+ +

So, one thing that I've been really pushing with our team this week is splitting tickets up. If this feels like it's bigger than a few days, then it needs to be split up, and part of it gets done moves to the done column. Part of it might be some work that somebody else is going to pick up next week; move that to the to-do column. And so, that way, at the end of the week, we have, ideally, a column full of things that were pushed over the finish line that are done.

+ +

And then, we have a column of things to be done next week that nobody has kind of called dibs on yet. So that then next week, when we have a new group of people coming in, you don't just look at this column of to-do things. It's like, well, all of these have someone's face on them. I'm not able to pick up anything, so now what do I do? By having those all kind of fresh and available to be picked up, you make it easy for the next batch of people to hit the ground running on Monday morning.

+ +

STEPHANIE: That's really interesting. You said you were doing this Kanban style, but it almost kind of sounds like one-week sprints in a way.

+ +

JOËL: Kind of, because the way we book people onto clients is typically on a per-week basis. And so, if there's going to be a gap between clients, typically, it's in increments of a week. Because they're on the project for a week, it doesn't necessarily mean that we're tracking the tickets on a per-week thing. So, it's not like, oh, we're committing to doing all of these tickets by the end of a particular time or anything like that.

+ +

We are working in a more Kanban style where there's a backlog, and you pull tickets, and whatever gets done gets done. What we do try to do, though, is not have individual tickets hang in the in-progress column over a week boundary. So, there's a nuance there. I guess there's some ways in which maybe it feels a little bit sprint-like. But I think we are running in much more of a Kanban-style workflow.

+ +

STEPHANIE: Yeah, that makes sense.

+ +

JOËL: It's really to deal with that churn and the idea that even though the ticket might stick around for a while or maybe it gets split up into multiple small tickets, the people are switching constantly. And so, making the workflow play nicely with the fact that the team is churning on a weekly basis kind of adds an extra, you know, a little bit of spice to the project management side of things.

+ +

STEPHANIE: Did you find yourself being the one to break down tickets to make sure that they weren't larger than a week's worth of work? Or did you work with the developer themselves to find opportunities to break out what they were working on if we got to the mid-week and progress wasn't looking like it would be completed by the end?

+ +

JOËL: I've left this up to individual developers. This is more of a broad conversation I had with our team, kind of saying, "Hey, here's our goal. We want to get some things done by the end of the week. If we don't think we can get them done, here are some strategies I recommend. I'm available to pair if people want it." But I didn't go through and estimate all the tickets and split them up.

+ +

I did a little bit of, like, grooming ahead of time. So, I had a sense of when we started the week if tickets felt roughly sized correctly. But oftentimes, you know, that kind of thing, you start working on it, and then you realize, wait a minute, this is a bigger ticket than I thought.

+ +

STEPHANIE: Yeah. I think even just having someone check in and be like, "Hey, how is progress? Can I support you in making sure that you're able to get to somewhere that feels completed by the end of the week so that the rest of the work is set up for someone new to take on?" That seems really valuable to me.

+ +

Because as an individual, I'm like, yeah, I don't know, I'm maybe heads down just deep and trying to get my thing done, but maybe not so aware of progress and relative to how much time I've spent on it. And having just someone prompt me on that could help kind of pull myself out a little bit, you know, come out for some air and be like, oh, actually, you know, this is a good spot for me to break this down.

+ +

Do you have any insights into this week that you might be bringing with you into client work or anything like that?

+ +

JOËL: And I think this has just given me an even deeper appreciation for breaking tickets down. Because of that arbitrary end-of-the-week deadline, I think that forces more tickets to break down in a way that I might say, oh, well, I picked up a ticket on Thursday for a client. It can totally bleed into next week; that's fine. It's still a fairly short ticket, just, you know, I started the work later. And so, trying to make sure that tickets get scoped down really tightly, I think, is an area where I could probably benefit from that discipline on client projects as well. You know, even if I'm not doing it to the extreme, I'm doing it this week.

+ +

STEPHANIE: Yeah. I would be really curious to find out if next week the folks who are on this project feel like they're in a good spot to, you know, keep on making forward momentum because they can just pull from the backlog and not have to go and do that knowledge transfer.

+ +

JOËL: Right. I will see with all of this, right? Maybe even with all the conversations and things, maybe we'll end the week, and I'll have 10 cards in the in-progress column. And it'll be like, okay, we tried a thing this week, mixed success. How do we want to iterate on that idea next week? Potentially with a different team.

+ +

STEPHANIE: Right, exactly.

+ +

JOËL: I feel like one way to maybe summarize the type of work that I was doing this week is that it's a kind of a scaling challenge. But over time, the team itself is small, but it's constantly churning. And I think you've been working on a team where it's kind of had a similar problem but in a different dimension. You're scaling over team size, actually a massively large team, and seeing some of the challenges there. What are some of the things that you've been facing?

+ +

STEPHANIE: Yeah. So, my current client project, I'm working on a codebase where there are hundreds of developers also working and committing to this codebase daily. And this codebase is really massive. There is so much stuff going on. And I've really only explored the world of the particular team that I'm on.

+ +

But I recently had to do a little bit of work in some code that is owned by a different team. And I actually really appreciated the way that we were able to collaborate across, I guess, ownership boundaries. And I was really interested in talking about some of the different ways that we've seen the idea of, like, who is owning, and, like, who is accountable for areas of the codebase once you reach a certain size.

+ +

So, what was really convenient about the way that I was working was that in my pull request, there was an automated step that told me I needed specific owner approval on the code that I was writing because I was touching some files that were owned by a different team. And it gave me all of the handles for the people on that team. So, I knew who to go talk to.

+ +

And it ended up being that that team had a public Slack channel specifically for people outside to ask them questions about their domain. And they had a rotating ambassador system. And so, in the Slack channel, in the channel topic, it said who was the ambassador for that week. So, you know, I saw who it was. I got to @ them and say, like, "Hey, like, I'm working on some of these files for this feature for my team. And, like, here's my pull request. Could you give me a review?"

+ +

JOËL: The more you're describing this, the more this is feeling very large team, almost bureaucratic systems. I'm hearing public Slack channels, which implies that teams have private Slack channels. I'm hearing, like, a rotating ambassador.

+ +

One word that you mentioned that I'd like to dig into a little bit is the idea of ownership because I think that the concept of ownership is present on probably most teams, but it probably means wildly varying things. And it sounds like on your team, it's a very kind of codified thing. So, what does ownership look like on your project?

+ +

STEPHANIE: Yeah, I love that you asked that question because you're right; it is codified, literally, in the codebase. There are ownership files that are in the repo itself where they've specified, like, all of the models that a team owns, you know, down to the names of the files themselves, or maybe a namespace. It has the team name and all of the team members' handles. So, that's how it was able to tell me in an automated way, like, hey, reach out to these people.

+ +

It was really interesting because it was pretty frictionless on my end, where all I had to do was see that, you know, I couldn't submit my pull request until I got that approval. But it was enough friction to be, like, well, you can't just, you know, change files in this domain without someone with extra context taking a look.

+ +

JOËL: This reminds me a little bit of a system that GitHub has where you have this CODEOWNERS file that you can add to a repo. Have you messed around with that at all, or kind of seen how that looks?

+ +

STEPHANIE: I have a little bit. I think I've only seen it in the context of being notified that someone is wanting to submit a pull request, but I'm not sure if it does gate merging based on ownership. Do you know if that's the case?

+ +

JOËL: I don't. I think you can set it up to automatically request reviews from owners. And on a large repo, the owner could be...I assume this is based maybe on directories, or it might be a regex pattern. I forget the exact details. But you can have owners for partial parts of the code instead of owners of the entire repository. So, then, if you make a change to a particular part of the code, it would ping the correct person automatically to review your code, which sounds like a really nice feature.

+ +

STEPHANIE: Yeah, absolutely. I think for the project that I'm working on, this definitely seemed like a custom process that they, at one point, decided to enforce. I'm not really sure about the history of how this came to be. But I found it actually quite a good way to meet people who are working in other parts of the codebase.

+ +

The person who happened to be ambassador that I pinged was so helpful in just, you know, making sure that I kind of understood the parts of the code that they owned that were honestly, like, quite complex. Like, I would not have felt confident just going ahead and making those changes necessarily myself because this is a pretty legacy codebase. There are quite a few gotchas, and they were able to point some [laughs] of them out to me.

+ +

Yeah, having that extra confidence was helpful for the particular feature I was working on. But it did also kind of give me a little pause because I've not worked at such a scale where there was so much uncertainty about the domain and that being so diffused across like I mentioned, hundreds of people.

+ +

JOËL: Do you think that this ownership system that's in place helps manage the complexity of scaling up to a team of hundreds of developers? Or does it feel like it kind of just adds a lot of process that gets in your way?

+ +

STEPHANIE: Ooh, that's a good question. It seems like kind of a chicken-and-the-egg situation because I felt better with someone else's input, right? Like, with someone else with more domain knowledge than me about what I was touching to be, like, "Yeah, like, this looks good to me," giving the plus one.

+ +

Whereas if that didn't exist, maybe I would have tried to seek it out on my own. But I would not have known where to start, right? I would have to ask around and be like, "Hey, like, who has worked in this directory before?" or whatever. Or I could have just went ahead and merged my code and hope my lack of context didn't really cause any huge problems, like outside of what was covered by the tests. But this is helpful for, like, where the codebase is at, you know, and the size it has grown.

+ +

JOËL: Do you think requiring an owner to review the code puts maybe an undue burden on the person who's the owner and that they might end up spending a lot of time reviewing code because they now kind of manage that part of the app?

+ +

STEPHANIE: Yeah, that's a really good question. I think it can. But I also feel a little better that that role is rotated, that everyone on the team gets the opportunity to really, like, focus on that. And I'm pretty sure the way it works is that that is their main focus for the sprint, or the week, or whatever, and that they're not assigned any other feature work but to prioritize being that ambassador. So, in some ways, that is a lot of process, right?

+ +

And there is that trade-off of having to allocate someone specific to answer people's questions. But at least from what I've seen, it does seem like a necessity because people do have questions, right? And I think they have figured out a system where it's very clear who you're supposed to talk to, and that accountability aspect of it has been met. Because I've also, like, worked on teams where that role is not well defined. People don't want to do it. And it's almost kind of a bystander effect where someone asks a question, but no one is specifically responsible for answering it, and so no one answers it.

+ +

JOËL: Oh yeah. Yes. And then you get kind of the cost of the bureaucracy without the benefits of kind of diffusing that knowledge.

+ +

So, we've been talking a lot about how this kind of ownership system can be really beneficial despite the overhead for a team that's 200 or 300 developers and where nobody knows all of the code or all of the nuances. And kind of at the other extreme, it's absolutely not worth it for a team of two or three developers where everybody knows the code, and there's kind of shared ownership of the project.

+ +

Somewhere in between, there is where you start having maybe some of those conversations about scaling the team, and do we need to introduce more process? In your experience, where do you think introducing some sort of ownership system like this starts becoming valuable? Or maybe what are some of the questions that a team should ask themselves to gauge, like, at the size we're at right now, would we get value from an ownership system?

+ +

STEPHANIE: Yeah, that's a really good point because as you were saying that, I was just starting to think of, yeah, I've certainly worked on projects where I have reviewed every piece of code that is to be merged, right? And then, at some point, that starts to change where, like, I can't do that anymore. And that transition has always been really interesting to me.

+ +

And then, I think there is, like you mentioned, another one where it's like, okay, now we aren't able to review everything, but, like, how do we trust that the code that is being merged, even if we don't all share that same context, is up to the quality we want it or is bug-free? Because without that context, there's always the opportunity that something might be missed.

+ +

I think I've seen that on teams, you know, really look like more bugs than usual, right? And maybe there is, like, actually, like, a big problem, and the site is down. And maybe there is, like, a post-mortem or something to discuss, like, why this happened. And, you know, it turns out that the siloing or, like, the lack of context sharing was partly involved.

+ +

And so, I do think there are definitely symptoms when we're starting to firefight a little more [chuckles] that might be kind of an indicator that the app has grown to a point where some context is being lost, and there are not guardrails in place to do our best to, like, share it, like, when we can and not when it's too late.

+ +

JOËL: Would it be fair to say that your recommendation is the team should not have an ownership system and kind of stick to everybody reviews all the code as they grow until they start hitting actual pain points, such as real bugs caused and, at that point, let that pain or maybe even the post-mortem be the thing that triggers the introduction of an ownership system?

+ +

STEPHANIE: I think so. I have not seen something like that proactively introduced. I would be curious if anyone has experienced something like that. But, you know, I think it's okay for change to be a little painful, right? And that's part of the growing pains of becoming a larger team, or organization, or codebase and continuing to reevaluate. Though, I guess I would be a little cautious about, you know, jumping straight to introducing processes or policies, right? Because those can be really hard to undo if they end up not being actually helpful for the root cause of the problem.

+ +

But, like, how you experimented with making sure that, you know, we didn't have any in-progress tickets for that project. The idea of just trying something and seeing how it works and kind of getting the team's feedback that is really valuable to me, at least as an IC. And, yeah, just making sure, like, you know, hearing from all of your team members on how those processes are changing the way they work and if it's feeling good or not.

+ +

Like I said, I enjoyed the process on my client project because it helped me feel more confident that the code that I was changing...because I can't possibly gain all of the knowledge that the owners of that area of the code have. It's just not going to happen. But also, I can imagine it being maybe not so good for someone else, right? It kind of being a barrier or being frustrating because, oh no, they really need to merge the code. And maybe they made the smallest change in a file owned by another team, right? And having to jump through that hoop.

+ +

JOËL: Yeah, that has absolutely never happened to me.

+ +

STEPHANIE: Really? Because it sounds like it has.

+ +

[laughter]

+ +

JOËL: Yes, it absolutely has. We've been kind of throwing around the idea of ownership the idea of team almost interchangeably as if they're one-to-one. And I want to lean a little bit into this idea of the team. Because I think there's an implicit assumption here that, within a team, there's enough knowledge sharing that happens, enough shared context, that everybody can kind of understand all of the code for their team, and that knowledge is just shared around, so you don't need these extra processes within teams.

+ +

But maybe once you start having multiple teams as part of your engineering department, then there starts to be some friction or some lost context that needs some mechanism to get around. Does that sound about right to you?

+ +

STEPHANIE: Ooh, I think that depends because even within my team, we are working on different projects, and I am definitely not on top of, you know, what some other folks are working on. And even within our team, there are silos. The difference there, though, is that I know who they are. Like I still am in contact with them in our daily syncs, that the barrier to finding someone who has the right information is much lower.

+ +

So, yeah, I think that is definitely a part of it, too, if, like...I think just the social barrier, even of, like, reaching out to someone you don't know and being like, "Hey, like, can you review my code?" that is [laughs] kind of...can be a little scary. And the dynamics definitely feel different within a team and between teams.

+ +

JOËL: Yeah, and definitely just the idea of, like, someone you see every day for your daily sync, you're going to feel much more comfortable reaching out to them for help or for a quick review than to a total stranger.

+ +

So, it's interesting that you mentioned the social aspects of things. I don't know if you're familiar with Conway's Law, the idea that the technical structures of our code, over time, end up reflecting the social structures of our teams.

+ +

STEPHANIE: Yeah, that is something that makes a lot of sense on the project that I'm working on now, where the boundaries, like I mentioned, between teams and between different namespaces are semi-rigid, I suppose, right? Rigid enough that, you know, there is a process but not so high that it becomes a burden, at least in my opinion.

+ +

But for another feature that I worked on, I actually had to interact with an external system that's owned more by the parent company of my current client. And that process was definitely more rigid. And I had to figure out who to email and had to, you know, look up this person's profile in the company directory to make sure that, you know, I was talking to the right person who had information that was relevant to me.

+ +

And then, you know, even, like, the technical aspect of talking to this external service had a lot of various barriers and, you know, special authorization and configuration that I needed to set up. So, definitely felt that in terms of the different levels of ease and talking to systems owned by different parties.

+ +

JOËL: So, the fact that there's, like, an actual, like, departmental or even, like, corporate boundary, definitely showed up in, like, a very hard boundary in the code as well.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: And I think taking this to an extreme, I've seen this happen when teams want to introduce microservices. And oftentimes, the boundaries of those microservices are not necessarily driven entirely by technical reasons, but they're often by social reasons. So, we can say, hey, this team is going to own this service, and everybody else only needs to interact with a public API. And we can make all sorts of changes internally, and you never need to know that. They will never break your code. And also, we don't need to bother each other or feel the need to fully deeply understand the internals of each system.

+ +

STEPHANIE: Yeah. Once you're introducing APIs that are accessible to a certain group of people and having to navigate, you know, making changes to the API or aligning in the expected structure of the, you know, communication that you're sending between them, that is definitely a pretty rigid boundary [laughs] and ends up being a lot of overhead to talk to those systems. And I certainly have been in the position of trying to communicate with the people who built and designed those systems and figuring out how to get on the same page.

+ +

And even just recently, I was accidentally sending something as an array, and they were expecting it as a string. And that caused all these problems of making the request happen, you know, successfully. And we didn't even realize it until someone pulled out the doc that had the API schema and pointed out that there was some miscommunication along the way.

+ +

JOËL: And that can be such a hard boundary around even, like, the idea of ownership. So, you were talking about how, earlier, when you were working in code that's maybe owned by another team, they might want to review it before it gets merged. So, there's a bit of a gatekeeping there.

+ +

When a team transitions fully to microservices, I've seen it go almost, like, more extreme where it's even, like, you don't even change the code. You submit a ticket into our system. We will prioritize it, and then eventually, we will build your feature. But you don't even get to make a change to the code and have us approve it. We're going to make all that because we own it. So, it kind of feels like taking that ownership idea and then just really running to a full extreme.

+ +

STEPHANIE: Yeah, right. That makes a lot of sense in the lens of Conway's Law if those are the processes they have in place for navigating cross-team collaboration or communication. Because, at some point, maybe they just reached a level where it had to be enforced that way because maybe things were getting dropped, or more casual lower barrier connection was too overwhelming or just not working for the organization.

+ +

JOËL: I think what I've been hearing just now and then just more broadly throughout the episode is that while there's a lot of interesting technical solutions that can make things better, at its root, scaling a team is a social problem. And it's all about how your teams communicate with each other so that you can scale smoothly and that the system doesn't suffer from adding more people.

+ +

STEPHANIE: Yeah. I think this is an area where I would love to hear any thoughts from our listeners about how their organizations handle something similar because I find all of this really interesting. And, you know, it ends up impacting my day-to-day work in a very real way. And so, if other places have figured out how that scaling and, you know, social and technical boundaries work in a way that feels good, I would love to know.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie experienced bike camping. Joël describes his experience during a week when he's in between projects.

+ +

Stephanie and Joël discuss the concept of code ownership, the mechanisms to enforce it, and the balance between bureaucracy and collaboration. They highlight the challenges and benefits of these systems in large codebases and emphasize that scaling a team is as much a social challenge as it is a technical one.

+ +
+ + + +

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: This weekend, I went bike camping for the first time. So, it was my turn to try out the padded bike shorts and go out on a long ride, combining two things that I really enjoy: biking and camping. It was so awesome. We did about 30 miles outside of the city of Chicago to close to the Indiana border. And we were at a campground that's owned by the forest preserves where I'm at. It was so much fun.

+ +

I packed all my stuff, including my tent and sleeping bags. And it was something that I never really imagined myself doing, but I'm really glad I did because I think it'll be something that I want to kind of do more of in the future, maybe even do multi-day bike camping trips.

+ +

JOËL: So, what's your verdict on the bike shorts?

+ +

STEPHANIE: Definitely a big help. Instead of feeling a little bit sore an hour or so along the bike ride, it kind of helped me stay comfortable quite a bit longer, which was really nice.

+ +

JOËL: Would you do this kind of trip again?

+ +

STEPHANIE: I think I would do it again. I think the next step for me is maybe to go even farther, maybe do multiple stops. Yeah, I was talking to my partner about it who came along with me, and he was saying, like, "Yeah, now that you've done that many miles in one day and, you know, camped overnight, you can really go anywhere. [laughs] You can go as far as you want."

+ +

And I thought that was pretty cool because, yeah, he's kind of right, where I can just pack up and go and, you know, who knows where I'll end up? Not that I would actually do that because of my need to plan. [laughs] I'm not that go-with-the-flow. But there was definitely something really special about being able to get from A to B with just, like, my physical body and not relying on any other kind of transportation.

+ +

JOËL: Yeah, there's a certain freedom to that spontaneity that's really nice.

+ +

STEPHANIE: Yeah. And I actually went with a group called Out Our Front Door. And if anyone is in Chicago and is interested in doing this kind of thing, they do group bike camping adventures, and they make it really accessible. So, it's a very easy pace. You are with a group, so it's just really fun. They make it really safe. And I had a really great time. There was about 60 of us actually at camp, and they had rented out the entire campground, so it was just our group.

+ +

And they even had a live reggae band come out and play music for us while we had dinner. And that was a really nice way for me to do it as a first-timer because there was stuff already planned for me, like meals. And I didn't have to worry about that because I was already, you know, just worrying about making sure I got there with all of my stuff. So, if that sounds interesting to you and you're in Chicagoland, definitely check them out.

+ +

JOËL: That's a great way to bring in newer people to say, let's have a semi-organized thing, where all you have to focus on is the skill itself, you know, can I bike the 30 miles? Rather than planning all the logistics around it.

+ +

STEPHANIE: Yeah, exactly. Joël, what's new in your world?

+ +

JOËL: So, speaking of planning and logistics, this week, I'm in between projects at thoughtbot. And on the Boost team that I'm on, we've introduced a kind of special rotation for people who are in between projects where we have an internal project, where just internal strategic initiatives that we want to push forward. Whoever is unbooked gets to work on that. So, it's a small team with a very high churn.

+ +

And one of the things that we do is every week; we have somebody act as the project manager for that team. And I was in between projects this week. I was assigned that project manager job. And so, I've been doing that in addition to some of the tickets myself, and that's been really interesting.

+ +

STEPHANIE: Cool. I really like how that role is rotated among team members.

+ +

JOËL: Yes. And the whole team itself is very high churn. So, somebody might be on that for just one week and then rotate off, and a new person comes in; maybe someone's on there a couple of weeks while we're waiting to find them a project.

+ +

But we're always looking to prioritize booking people onto new client projects. And so, whoever is on that team, typically, is there for a short period of time. And so that means that the project manager role has to rotate a lot. But also, just in general, as you're managing tickets, you have to deal with the fact that people are not going to be on this project long-term. This is just, they're here for a few days, and they get some things done, and then they're moving off. And I think that presents some unique challenges in terms of the project management side of things.

+ +

STEPHANIE: Yeah. What kind of challenges did you find interesting in this role for the week that you were on it?

+ +

JOËL: So, in particular, I think making sure that outstanding work from the previous week gets done, especially when the people who were working on that ticket are no longer working on it. So, they may have done some partial work and then moved on to something else. And then, you have to ascertain the state of the ticket. Has it been completed? If it's only partial, what parts have and haven't? Can this be passed on to somebody else? Is there some unique knowledge that the previous person had? Has the code been pushed up? That kind of thing.

+ +

STEPHANIE: So, that reminds me of something I heard about the idea of being expendable. You know, there are certain industries where anyone else with that skill set can kind of step in and take over for another worker without a lot of issues, and they can continue on doing that work. So, I'm thinking about, you know, maybe doctors or pharmacists where they have that, like, shared skill set, and everything is documented enough so that they can just take whatever their case is. And if someone is out, it's not a big deal because people can just step in. And I'm curious about if this is something that could work for software development.

+ +

JOËL: I think it is important to have a team where nobody is irreplaceable. When it comes down to individual tickets, one of the things that I've been pushing for is that, at the end of the week, I would like to not see any tickets remain in the in-progress column. We're using a Kanban-style board. So, ideally, all work either moves to the done column or moves to the to-be-done column for next week. And it's no longer owned by anyone, so people have removed their faces from it. Ideally, though, if you pick up a ticket during the week, you get it to completion.

+ +

So, one thing that I've been really pushing with our team this week is splitting tickets up. If this feels like it's bigger than a few days, then it needs to be split up, and part of it gets done moves to the done column. Part of it might be some work that somebody else is going to pick up next week; move that to the to-do column. And so, that way, at the end of the week, we have, ideally, a column full of things that were pushed over the finish line that are done.

+ +

And then, we have a column of things to be done next week that nobody has kind of called dibs on yet. So that then next week, when we have a new group of people coming in, you don't just look at this column of to-do things. It's like, well, all of these have someone's face on them. I'm not able to pick up anything, so now what do I do? By having those all kind of fresh and available to be picked up, you make it easy for the next batch of people to hit the ground running on Monday morning.

+ +

STEPHANIE: That's really interesting. You said you were doing this Kanban style, but it almost kind of sounds like one-week sprints in a way.

+ +

JOËL: Kind of, because the way we book people onto clients is typically on a per-week basis. And so, if there's going to be a gap between clients, typically, it's in increments of a week. Because they're on the project for a week, it doesn't necessarily mean that we're tracking the tickets on a per-week thing. So, it's not like, oh, we're committing to doing all of these tickets by the end of a particular time or anything like that.

+ +

We are working in a more Kanban style where there's a backlog, and you pull tickets, and whatever gets done gets done. What we do try to do, though, is not have individual tickets hang in the in-progress column over a week boundary. So, there's a nuance there. I guess there's some ways in which maybe it feels a little bit sprint-like. But I think we are running in much more of a Kanban-style workflow.

+ +

STEPHANIE: Yeah, that makes sense.

+ +

JOËL: It's really to deal with that churn and the idea that even though the ticket might stick around for a while or maybe it gets split up into multiple small tickets, the people are switching constantly. And so, making the workflow play nicely with the fact that the team is churning on a weekly basis kind of adds an extra, you know, a little bit of spice to the project management side of things.

+ +

STEPHANIE: Did you find yourself being the one to break down tickets to make sure that they weren't larger than a week's worth of work? Or did you work with the developer themselves to find opportunities to break out what they were working on if we got to the mid-week and progress wasn't looking like it would be completed by the end?

+ +

JOËL: I've left this up to individual developers. This is more of a broad conversation I had with our team, kind of saying, "Hey, here's our goal. We want to get some things done by the end of the week. If we don't think we can get them done, here are some strategies I recommend. I'm available to pair if people want it." But I didn't go through and estimate all the tickets and split them up.

+ +

I did a little bit of, like, grooming ahead of time. So, I had a sense of when we started the week if tickets felt roughly sized correctly. But oftentimes, you know, that kind of thing, you start working on it, and then you realize, wait a minute, this is a bigger ticket than I thought.

+ +

STEPHANIE: Yeah. I think even just having someone check in and be like, "Hey, how is progress? Can I support you in making sure that you're able to get to somewhere that feels completed by the end of the week so that the rest of the work is set up for someone new to take on?" That seems really valuable to me.

+ +

Because as an individual, I'm like, yeah, I don't know, I'm maybe heads down just deep and trying to get my thing done, but maybe not so aware of progress and relative to how much time I've spent on it. And having just someone prompt me on that could help kind of pull myself out a little bit, you know, come out for some air and be like, oh, actually, you know, this is a good spot for me to break this down.

+ +

Do you have any insights into this week that you might be bringing with you into client work or anything like that?

+ +

JOËL: And I think this has just given me an even deeper appreciation for breaking tickets down. Because of that arbitrary end-of-the-week deadline, I think that forces more tickets to break down in a way that I might say, oh, well, I picked up a ticket on Thursday for a client. It can totally bleed into next week; that's fine. It's still a fairly short ticket, just, you know, I started the work later. And so, trying to make sure that tickets get scoped down really tightly, I think, is an area where I could probably benefit from that discipline on client projects as well. You know, even if I'm not doing it to the extreme, I'm doing it this week.

+ +

STEPHANIE: Yeah. I would be really curious to find out if next week the folks who are on this project feel like they're in a good spot to, you know, keep on making forward momentum because they can just pull from the backlog and not have to go and do that knowledge transfer.

+ +

JOËL: Right. I will see with all of this, right? Maybe even with all the conversations and things, maybe we'll end the week, and I'll have 10 cards in the in-progress column. And it'll be like, okay, we tried a thing this week, mixed success. How do we want to iterate on that idea next week? Potentially with a different team.

+ +

STEPHANIE: Right, exactly.

+ +

JOËL: I feel like one way to maybe summarize the type of work that I was doing this week is that it's a kind of a scaling challenge. But over time, the team itself is small, but it's constantly churning. And I think you've been working on a team where it's kind of had a similar problem but in a different dimension. You're scaling over team size, actually a massively large team, and seeing some of the challenges there. What are some of the things that you've been facing?

+ +

STEPHANIE: Yeah. So, my current client project, I'm working on a codebase where there are hundreds of developers also working and committing to this codebase daily. And this codebase is really massive. There is so much stuff going on. And I've really only explored the world of the particular team that I'm on.

+ +

But I recently had to do a little bit of work in some code that is owned by a different team. And I actually really appreciated the way that we were able to collaborate across, I guess, ownership boundaries. And I was really interested in talking about some of the different ways that we've seen the idea of, like, who is owning, and, like, who is accountable for areas of the codebase once you reach a certain size.

+ +

So, what was really convenient about the way that I was working was that in my pull request, there was an automated step that told me I needed specific owner approval on the code that I was writing because I was touching some files that were owned by a different team. And it gave me all of the handles for the people on that team. So, I knew who to go talk to.

+ +

And it ended up being that that team had a public Slack channel specifically for people outside to ask them questions about their domain. And they had a rotating ambassador system. And so, in the Slack channel, in the channel topic, it said who was the ambassador for that week. So, you know, I saw who it was. I got to @ them and say, like, "Hey, like, I'm working on some of these files for this feature for my team. And, like, here's my pull request. Could you give me a review?"

+ +

JOËL: The more you're describing this, the more this is feeling very large team, almost bureaucratic systems. I'm hearing public Slack channels, which implies that teams have private Slack channels. I'm hearing, like, a rotating ambassador.

+ +

One word that you mentioned that I'd like to dig into a little bit is the idea of ownership because I think that the concept of ownership is present on probably most teams, but it probably means wildly varying things. And it sounds like on your team, it's a very kind of codified thing. So, what does ownership look like on your project?

+ +

STEPHANIE: Yeah, I love that you asked that question because you're right; it is codified, literally, in the codebase. There are ownership files that are in the repo itself where they've specified, like, all of the models that a team owns, you know, down to the names of the files themselves, or maybe a namespace. It has the team name and all of the team members' handles. So, that's how it was able to tell me in an automated way, like, hey, reach out to these people.

+ +

It was really interesting because it was pretty frictionless on my end, where all I had to do was see that, you know, I couldn't submit my pull request until I got that approval. But it was enough friction to be, like, well, you can't just, you know, change files in this domain without someone with extra context taking a look.

+ +

JOËL: This reminds me a little bit of a system that GitHub has where you have this CODEOWNERS file that you can add to a repo. Have you messed around with that at all, or kind of seen how that looks?

+ +

STEPHANIE: I have a little bit. I think I've only seen it in the context of being notified that someone is wanting to submit a pull request, but I'm not sure if it does gate merging based on ownership. Do you know if that's the case?

+ +

JOËL: I don't. I think you can set it up to automatically request reviews from owners. And on a large repo, the owner could be...I assume this is based maybe on directories, or it might be a regex pattern. I forget the exact details. But you can have owners for partial parts of the code instead of owners of the entire repository. So, then, if you make a change to a particular part of the code, it would ping the correct person automatically to review your code, which sounds like a really nice feature.

+ +

STEPHANIE: Yeah, absolutely. I think for the project that I'm working on, this definitely seemed like a custom process that they, at one point, decided to enforce. I'm not really sure about the history of how this came to be. But I found it actually quite a good way to meet people who are working in other parts of the codebase.

+ +

The person who happened to be ambassador that I pinged was so helpful in just, you know, making sure that I kind of understood the parts of the code that they owned that were honestly, like, quite complex. Like, I would not have felt confident just going ahead and making those changes necessarily myself because this is a pretty legacy codebase. There are quite a few gotchas, and they were able to point some [laughs] of them out to me.

+ +

Yeah, having that extra confidence was helpful for the particular feature I was working on. But it did also kind of give me a little pause because I've not worked at such a scale where there was so much uncertainty about the domain and that being so diffused across like I mentioned, hundreds of people.

+ +

JOËL: Do you think that this ownership system that's in place helps manage the complexity of scaling up to a team of hundreds of developers? Or does it feel like it kind of just adds a lot of process that gets in your way?

+ +

STEPHANIE: Ooh, that's a good question. It seems like kind of a chicken-and-the-egg situation because I felt better with someone else's input, right? Like, with someone else with more domain knowledge than me about what I was touching to be, like, "Yeah, like, this looks good to me," giving the plus one.

+ +

Whereas if that didn't exist, maybe I would have tried to seek it out on my own. But I would not have known where to start, right? I would have to ask around and be like, "Hey, like, who has worked in this directory before?" or whatever. Or I could have just went ahead and merged my code and hope my lack of context didn't really cause any huge problems, like outside of what was covered by the tests. But this is helpful for, like, where the codebase is at, you know, and the size it has grown.

+ +

JOËL: Do you think requiring an owner to review the code puts maybe an undue burden on the person who's the owner and that they might end up spending a lot of time reviewing code because they now kind of manage that part of the app?

+ +

STEPHANIE: Yeah, that's a really good question. I think it can. But I also feel a little better that that role is rotated, that everyone on the team gets the opportunity to really, like, focus on that. And I'm pretty sure the way it works is that that is their main focus for the sprint, or the week, or whatever, and that they're not assigned any other feature work but to prioritize being that ambassador. So, in some ways, that is a lot of process, right?

+ +

And there is that trade-off of having to allocate someone specific to answer people's questions. But at least from what I've seen, it does seem like a necessity because people do have questions, right? And I think they have figured out a system where it's very clear who you're supposed to talk to, and that accountability aspect of it has been met. Because I've also, like, worked on teams where that role is not well defined. People don't want to do it. And it's almost kind of a bystander effect where someone asks a question, but no one is specifically responsible for answering it, and so no one answers it.

+ +

JOËL: Oh yeah. Yes. And then you get kind of the cost of the bureaucracy without the benefits of kind of diffusing that knowledge.

+ +

So, we've been talking a lot about how this kind of ownership system can be really beneficial despite the overhead for a team that's 200 or 300 developers and where nobody knows all of the code or all of the nuances. And kind of at the other extreme, it's absolutely not worth it for a team of two or three developers where everybody knows the code, and there's kind of shared ownership of the project.

+ +

Somewhere in between, there is where you start having maybe some of those conversations about scaling the team, and do we need to introduce more process? In your experience, where do you think introducing some sort of ownership system like this starts becoming valuable? Or maybe what are some of the questions that a team should ask themselves to gauge, like, at the size we're at right now, would we get value from an ownership system?

+ +

STEPHANIE: Yeah, that's a really good point because as you were saying that, I was just starting to think of, yeah, I've certainly worked on projects where I have reviewed every piece of code that is to be merged, right? And then, at some point, that starts to change where, like, I can't do that anymore. And that transition has always been really interesting to me.

+ +

And then, I think there is, like you mentioned, another one where it's like, okay, now we aren't able to review everything, but, like, how do we trust that the code that is being merged, even if we don't all share that same context, is up to the quality we want it or is bug-free? Because without that context, there's always the opportunity that something might be missed.

+ +

I think I've seen that on teams, you know, really look like more bugs than usual, right? And maybe there is, like, actually, like, a big problem, and the site is down. And maybe there is, like, a post-mortem or something to discuss, like, why this happened. And, you know, it turns out that the siloing or, like, the lack of context sharing was partly involved.

+ +

And so, I do think there are definitely symptoms when we're starting to firefight a little more [chuckles] that might be kind of an indicator that the app has grown to a point where some context is being lost, and there are not guardrails in place to do our best to, like, share it, like, when we can and not when it's too late.

+ +

JOËL: Would it be fair to say that your recommendation is the team should not have an ownership system and kind of stick to everybody reviews all the code as they grow until they start hitting actual pain points, such as real bugs caused and, at that point, let that pain or maybe even the post-mortem be the thing that triggers the introduction of an ownership system?

+ +

STEPHANIE: I think so. I have not seen something like that proactively introduced. I would be curious if anyone has experienced something like that. But, you know, I think it's okay for change to be a little painful, right? And that's part of the growing pains of becoming a larger team, or organization, or codebase and continuing to reevaluate. Though, I guess I would be a little cautious about, you know, jumping straight to introducing processes or policies, right? Because those can be really hard to undo if they end up not being actually helpful for the root cause of the problem.

+ +

But, like, how you experimented with making sure that, you know, we didn't have any in-progress tickets for that project. The idea of just trying something and seeing how it works and kind of getting the team's feedback that is really valuable to me, at least as an IC. And, yeah, just making sure, like, you know, hearing from all of your team members on how those processes are changing the way they work and if it's feeling good or not.

+ +

Like I said, I enjoyed the process on my client project because it helped me feel more confident that the code that I was changing...because I can't possibly gain all of the knowledge that the owners of that area of the code have. It's just not going to happen. But also, I can imagine it being maybe not so good for someone else, right? It kind of being a barrier or being frustrating because, oh no, they really need to merge the code. And maybe they made the smallest change in a file owned by another team, right? And having to jump through that hoop.

+ +

JOËL: Yeah, that has absolutely never happened to me.

+ +

STEPHANIE: Really? Because it sounds like it has.

+ +

[laughter]

+ +

JOËL: Yes, it absolutely has. We've been kind of throwing around the idea of ownership the idea of team almost interchangeably as if they're one-to-one. And I want to lean a little bit into this idea of the team. Because I think there's an implicit assumption here that, within a team, there's enough knowledge sharing that happens, enough shared context, that everybody can kind of understand all of the code for their team, and that knowledge is just shared around, so you don't need these extra processes within teams.

+ +

But maybe once you start having multiple teams as part of your engineering department, then there starts to be some friction or some lost context that needs some mechanism to get around. Does that sound about right to you?

+ +

STEPHANIE: Ooh, I think that depends because even within my team, we are working on different projects, and I am definitely not on top of, you know, what some other folks are working on. And even within our team, there are silos. The difference there, though, is that I know who they are. Like I still am in contact with them in our daily syncs, that the barrier to finding someone who has the right information is much lower.

+ +

So, yeah, I think that is definitely a part of it, too, if, like...I think just the social barrier, even of, like, reaching out to someone you don't know and being like, "Hey, like, can you review my code?" that is [laughs] kind of...can be a little scary. And the dynamics definitely feel different within a team and between teams.

+ +

JOËL: Yeah, and definitely just the idea of, like, someone you see every day for your daily sync, you're going to feel much more comfortable reaching out to them for help or for a quick review than to a total stranger.

+ +

So, it's interesting that you mentioned the social aspects of things. I don't know if you're familiar with Conway's Law, the idea that the technical structures of our code, over time, end up reflecting the social structures of our teams.

+ +

STEPHANIE: Yeah, that is something that makes a lot of sense on the project that I'm working on now, where the boundaries, like I mentioned, between teams and between different namespaces are semi-rigid, I suppose, right? Rigid enough that, you know, there is a process but not so high that it becomes a burden, at least in my opinion.

+ +

But for another feature that I worked on, I actually had to interact with an external system that's owned more by the parent company of my current client. And that process was definitely more rigid. And I had to figure out who to email and had to, you know, look up this person's profile in the company directory to make sure that, you know, I was talking to the right person who had information that was relevant to me.

+ +

And then, you know, even, like, the technical aspect of talking to this external service had a lot of various barriers and, you know, special authorization and configuration that I needed to set up. So, definitely felt that in terms of the different levels of ease and talking to systems owned by different parties.

+ +

JOËL: So, the fact that there's, like, an actual, like, departmental or even, like, corporate boundary, definitely showed up in, like, a very hard boundary in the code as well.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: And I think taking this to an extreme, I've seen this happen when teams want to introduce microservices. And oftentimes, the boundaries of those microservices are not necessarily driven entirely by technical reasons, but they're often by social reasons. So, we can say, hey, this team is going to own this service, and everybody else only needs to interact with a public API. And we can make all sorts of changes internally, and you never need to know that. They will never break your code. And also, we don't need to bother each other or feel the need to fully deeply understand the internals of each system.

+ +

STEPHANIE: Yeah. Once you're introducing APIs that are accessible to a certain group of people and having to navigate, you know, making changes to the API or aligning in the expected structure of the, you know, communication that you're sending between them, that is definitely a pretty rigid boundary [laughs] and ends up being a lot of overhead to talk to those systems. And I certainly have been in the position of trying to communicate with the people who built and designed those systems and figuring out how to get on the same page.

+ +

And even just recently, I was accidentally sending something as an array, and they were expecting it as a string. And that caused all these problems of making the request happen, you know, successfully. And we didn't even realize it until someone pulled out the doc that had the API schema and pointed out that there was some miscommunication along the way.

+ +

JOËL: And that can be such a hard boundary around even, like, the idea of ownership. So, you were talking about how, earlier, when you were working in code that's maybe owned by another team, they might want to review it before it gets merged. So, there's a bit of a gatekeeping there.

+ +

When a team transitions fully to microservices, I've seen it go almost, like, more extreme where it's even, like, you don't even change the code. You submit a ticket into our system. We will prioritize it, and then eventually, we will build your feature. But you don't even get to make a change to the code and have us approve it. We're going to make all that because we own it. So, it kind of feels like taking that ownership idea and then just really running to a full extreme.

+ +

STEPHANIE: Yeah, right. That makes a lot of sense in the lens of Conway's Law if those are the processes they have in place for navigating cross-team collaboration or communication. Because, at some point, maybe they just reached a level where it had to be enforced that way because maybe things were getting dropped, or more casual lower barrier connection was too overwhelming or just not working for the organization.

+ +

JOËL: I think what I've been hearing just now and then just more broadly throughout the episode is that while there's a lot of interesting technical solutions that can make things better, at its root, scaling a team is a social problem. And it's all about how your teams communicate with each other so that you can scale smoothly and that the system doesn't suffer from adding more people.

+ +

STEPHANIE: Yeah. I think this is an area where I would love to hear any thoughts from our listeners about how their organizations handle something similar because I find all of this really interesting. And, you know, it ends up impacting my day-to-day work in a very real way. And so, if other places have figured out how that scaling and, you know, social and technical boundaries work in a way that feels good, I would love to know.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+EN1caz3e + + ]]> + + Joël Quenneville + Stephanie Minn + + + 398: Developing Heuristics For Writing Software + https://bikeshed.thoughtbot.com/398 + 483b3f12-ad3e-4283-8c1f-fb3a2d216b88 + Tue, 22 Aug 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Want a cool cucumber salad? Joël's got you covered. Stephanie has evolved and found some pickles she enjoys. + +Experienced programmers use a lot of heuristics or "rules of thumb" about what makes their code better. These aren't always true, but they work in most situations. Stephanie and Joël discuss a range of heuristics, how to use them, how to come up with them, how to know when to break them, and how to teach them to more junior devs. + 34:07 + no + + + Want a cool cucumber salad? Joël's got you covered. Stephanie has evolved and found some pickles she enjoys. +Experienced programmers use a lot of heuristics or "rules of thumb" about what makes their code better. These aren't always true, but they work in most situations. Stephanie and Joël discuss a range of heuristics, how to use them, how to come up with them, how to know when to break them, and how to teach them to more junior devs. +Pickled mustard seeds (https://www.youtube.com/watch?v=aLMFGk7Ylw0) +The purpose of a system is what it does (https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does) +Intro to empirical software engineering by Hillel Wayne (https://www.youtube.com/watch?v=WELBnE33dpY) +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, as of the recording of this, summer is in full swing, and it's the time of year where we have all these, you know, fresh vegetables out, so I've been really enjoying a lot of those. I think this week; in particular, I've been going into, like, all the variations on cucumber salads. +STEPHANIE: Ooh. +JOËL: Yeah. So, that's been kind of fun for me. A fun thing I've been doing to spice this up is pickling mustard seeds to add as a topping. That's actually really amazing. It adds just a little bit of acidity, a little bit of crunch, a little bit of texture. And it's pretty. +STEPHANIE: That sounds so delicious. And also, I was going to share something about pickles about what's new in my world. [laughs] But first, I am curious, what has been your go-to cucumber salad that you put this pickled mustard seed situation on top? +JOËL: So, cucumbers and tomatoes is just the base of everything. And then, it kind of goes with random things I have in my fridge. A little bit of goat cheese on top can be a great topping, big fan of balsamic glaze. You can just get, like, a bottle of that at the grocery store, the pickled mustard seeds. I've recently been trying topping with a fried egg. +STEPHANIE: Ooh, that sounds really fun. It kind of, like, adds a bit of savoriness and creaminess and maybe even, like, the crunchy fried edges. That sounds really yummy. +JOËL: Particularly if you do it over easy where the center is not fully cooked. When the egg breaks, you effectively get salad dressing for free. +STEPHANIE: That sounds so delicious. +JOËL: Summer vegetables, they're great. +STEPHANIE: They are great. Last year, I did have a cucumber garden, as in a garden, and a few cucumber plants that were too prolific for me, to be honest. I found myself overrun with cucumbers and having to give them away because we just didn't eat them enough. And this year, we scaled back a little bit [laughs] on the cucs. But I am so excited to bring up what's new in my world now because it's, like, so related, and we did not plan this at all. But I have a silly little thing to share about my own pickle journey. So, I used to be a pickle hater. +JOËL: You know what? Same. +STEPHANIE: Oh my gosh, incredible. Another new thing we've learned about each other. I really, like, wanted to like pickles because, you know, when you order a sandwich in a restaurant, it always comes with the pickle spear. And neither me nor my partner were into pickles, and we would always leave the spear uneaten on the plate, and we felt so bad about it. I felt really bad about it. +And so, every, like, three to six months or so, I'd be like, okay, I'm going to gather the courage to try the pickle again and see if maybe my taste buds have changed, and this time I'll like it. And, you know, I would try a bite and just be like, no, no, I don't think it's for me. [laughs] But I guess I was just so primed to do something about, like, wanting to eliminate this really inconsequential food waste. But every time it happened, I would just, you know, [laughs] be, like, oh, if only I loved pickles. +And I got my friend, who is a pickle connoisseur, to help me figure out, like, what pickles I might like. So, I asked her to come up with, like, a pickle sampler for me because I really hadn't tried all too many. And that actually really helped me find which ones were a little more palatable to me. So, I found out that I liked the sweeter ones. There's, like, a bread and butter pickle that can be quite sweet. Your diner pickle can be very different from a jar of, like, fancy pickles. [laughs] +JOËL: Definitely. +STEPHANIE: One day, she gifted me a jar of, like, Polish gherkins that were delicious. +JOËL: Hmmm. +STEPHANIE: I was like, wow, I can just snack on these. So, the thing that's new is that this time, I went to an Eastern European grocery store, and I bought my own jar of pickled gherkins. And that was something that Stephanie, like, two years ago, would never even do. [laughs] +JOËL: That's really cool that you got a chance to sort of explore a broader range of what was available in the pickle world and then were able to find kind of your niche there and discover something new that you actually like. +STEPHANIE: Yeah, it was very fun. And now I feel like my whole world has opened up to, you know, pickley and fermented things and just, like, get to enjoy even more snacks. +So, to move away from pickles, recently, on my client project, I've been pairing a lot more with other client developers. And one thing that has come up is, you know, talking about our reasoning or our thought process for when we're pairing on some code. And I realized that I have built up a lot of either intuition or maybe some rules that I like to follow when I'm writing code, writing a test, or even doing a code review. And I've realized that you know, as developers, we often use these kinds of shortcuts or heuristics to help orient us as we're doing our work. +JOËL: Yeah. I think that's definitely something that either comes yourself from experience or sometimes is passed along, and you get to benefit from somebody else's experience. They learned the hard way a lot of these tips and tricks, and now they kind of pass on some of these guidelines to us. Do you have any favorites that you reach for frequently? +STEPHANIE: So, one way I like to approach a problem is to start messy [laughs] and to kind of see what that gets me and then where to go from there. I find that it's a little bit easier for me to draw on things that I've, you know, learned or picked up and tips once I have something in front of me to react to. So, maybe I will just go with the naive implementation and just write all of the code in one method, you know, in a class. And from there, now that it's out of my system, can I kind of come back in with a finer tooth comb and then apply more of a sustained effort to clean things up, right? +And, to me, the question I find myself asking is, like, can this be extracted further? And so, you know, if I have everything in one giant method, then yes, [laughs] there is likely, you know, many opportunities to extract that, and maybe I will see something like, oh, the way that I spaced out this code that might be a signal to me that, like, these are some ideas that are grouped together, and I can pull something out there. +JOËL: Do you have a heuristic around when to stop extracting? +STEPHANIE: That's a good point. I think I tend to stop when I have kind of pulled out the classes that make sense to me. And, at that point, you know, like, maybe there is more extraction that can be done. But at a certain point, you know, you then get these really tiny classes that maybe don't hold their weight. And I think that's also true of methods that then call other methods, and that's the only thing that they do. +Then it's like, well, is this too extracted that it's not really giving a future reader helpful information, right? I want the extraction to improve readability. And that tends to be another lens through which I am applying to this idea of, like, can I extract further? Is this extraction helpful for understanding this code? +JOËL: I like the idea of looking at the code through multiple lenses. And so, sometimes you look at it through the lens of, yeah, are there enough moving parts here? Or does it feel kind of brittle and all in one place? And then sometimes completely shifting your lens and saying, you know what? Let's put myself in the seat of someone who's looking at this code for the first time. Can I understand it? +So, structuring and extracting code is a big part of the work that we do. And I also happen to have a couple of heuristics that I like to use. One is separate branching code from doing code. So, if I have an if...else condition, I try not to put ten lines of logic inside each branch; instead, I have just a call out to a method so that the only thing the conditional does is to choose which path you go, and then each individual path is its own method. +Similarly, if I'm writing a method, I'm not going to have a bunch of logic then a conditional mixed in together. So, my heuristic is a method gets to do one of two things. It either gets to choose a path to take or it gets to do a thing, but you can't mix and match both. +STEPHANIE: Yeah, that makes a lot of sense. I really appreciate a well-named method that is, you know, determining, like, what condition needs to happen because then that helps me, yeah, like, avoid having to hold all of this information about this condition or this other condition, and this other condition in order to figure out what path I'm trying to take. +JOËL: And the naming and the readability, I think, is a big part of this. Another heuristic that I like to use that kind of converges on the same result is trying to write each method at a single level of abstraction. So, if I am writing a method that has some kind of high-level terms it's using, I'm not going to also mix in a lot of low-level implementation. And then, similarly, if it's a method that's doing a lot of, like, low-level nuts and bolts things, I'm going to try not to pull in some of these higher-level domain name methods in there. +And so, by separating things out so that every method reads one level of abstraction, you make it much easier for the reader to go through and figure out what's happening. Are we kind of getting that more 10,000-foot view, getting a sense of what's happening, and saying, okay, we want to process the user form, and then we want to send off an email, and then we want to, you know, write to a file? Or are we going through, okay, we're going to increment a counter so that we get exponential back off on our [inaudible 10:28] request? Those two things do not belong together in the same method. +STEPHANIE: Yeah, absolutely. I really like this heuristic. And I have been applying it more and more and found it really useful for making sure that you're handling your errors correctly, especially because, at different levels of abstraction, you want to do different things with your errors, right? +An implementation error that's raised because, you know, you're calling something accidentally on nil, or maybe a third-party service is down, and you get a custom error, whatever that is, those concerns are different from how you want to handle things at the controller level. And oftentimes, I see those things really mixed together, and honestly, I think leads to a lot of buggy code when you're trying to handle things that can go wrong at the wrong level of abstraction. +JOËL: Yeah. Is there a good heuristic around what level you think is best to trigger an exception? Or maybe, more generally, just being aware of different levels of abstraction and knowing that catching or triggering errors at each level will have different impacts. +STEPHANIE: I think more of the latter, the having an awareness of what kinds of errors might be possible and what impact that has on the user, right? The user being either an actual customer or, you know, another developer who has to read a notification from an error monitoring service. [laughs] +JOËL: This is really interesting to me because I think we've now bridged the concept of heuristics into the idea of mental models. So, the heuristic is write your methods at a single level of abstraction, but that then leads into a mental model where maybe code is structured in three or four different layers. You've got a low level, a mid-level, a high level, something like that, of abstraction. And now, you can use that mental model to start thinking about what are the impacts of exceptions at each layer? +And then, maybe you complete the circle by creating a heuristic that relies on that mental model, maybe, I don't know, raise in the low-level rescue at the top level or something. I'm making something absolutely arbitrary up right now. But somehow, we've gone from heuristic, which creates a mental model, which then allows us to build new heuristics on top of that, and that seems like a virtuous cycle to me. +STEPHANIE: Yeah, absolutely. I think what I'm also picking up is the idea that you do need a mental model, or you do need to draw on your own ideas about something in order to apply the heuristic, right? You know, someone could tell you to separate branching code from doing code. But maybe you don't know what that means or, like, maybe you don't see why that's important. And sure, you can still apply it and try your best to follow it. But, in some ways, I think that the best heuristics are ones that you've kind of developed for yourself based on your own experience. +JOËL: That's really interesting. I think once you've built from your own experience, I definitely feel like they're really impactful because you've kind of synthesized 2, 5, 10, 20 years of experience doing some of this work into, oftentimes, like, you know, a pithy one-line sentence, 5, 6 words that convey an approach that you've found works best, you know, maybe 80% or 90% of the time. The power of synthesis for your own self-learning I think it's really hard to understate. +So, I'm curious if there's any other heuristics that you commonly use that you kind of created yourself based off your own experience rather than just having it be more of a broadly received idea from the community. +STEPHANIE: I think, for me, it's more so that the experience has helped affirm certain heuristics and also made me feel more comfortable with letting others go. And one that I heard a lot but, like, didn't quite understand until really working through it deeper is the idea of feeling pain when you write a test, and that being a signal of opportunities to try different design with your code. And I just didn't know what that pain was at the beginning. Like, what does that even mean? [laughs] Like, how can a test cause me pain? +But on my own, I realized, oh, like, actually, I get really frustrated when I need to stub out a whole method chain, right? And I find myself having to go look up how to do that or just spending a lot of time having to do something that I haven't done before. Maybe the pain comes from having to change a lot of files because, oh no, like, I also broke 20 other tests in the process. +But when you're first starting out, oftentimes, you, like, don't know that that is not normal [laughs]; at least, that was true for me. And so, that was something that I had heard about, like, if you are feeling pain when writing a test, then, like, maybe reconsider your code design. But when you don't know how to identify what that pain is, and you also, like, don't know where to go from there, I find that, you know, the heuristic can only help you so much. +JOËL: Yeah. Maybe that's something that's challenging with a heuristic in that they're often expressed as these pithy sentences. But if you're not familiar with some of the underlying concepts, that might make them harder to apply, which is unfortunate because, oftentimes, these heuristics that we've developed as a community are targeted to newcomers to help them kind of avoid the mistakes that we've made along the way. +STEPHANIE: I think what really helped me the most in connecting a heuristic that's commonly expressed and my own experience is when I've had someone ask me about how I'm feeling when I'm, you know, making some kind of decision or when I'm reading some code. Like, what do I think of this, or what has been my experience with this? And giving me the opportunity on the spot to synthesize that information. Because otherwise, it's hard to figure out, you know, like, what is just normal? This is just life as a developer [laughs]. And what are opportunities to maybe gain some more insight about the work itself? +JOËL: One thing that I've learned over time as a developer, and I'm not sure if this quite rises to the level of a heuristic, but a lot of, like, pain and frustration in development doesn't necessarily have to be that way. And it's not necessarily because I'm bad at the job or I'm too new to the technology or whatever. It can often be a sign of underlying design issues or the fact that the system was modeled with certain assumptions that are no longer true. These can often be signals that you can make things better. +So, I think if I had to reduce this idea down to a clever one-liner, it'd be something along the lines of, it can be better, or it doesn't have to be this bad. You're writing a test, and it's really annoying. There might be a better way to structure the underlying code that would make the test better. You're having to do some, like, really clunky code to deal with something. Is there maybe a better object design that would make a lot of that pain go away, or at least kind of quarantine it in a certain part of the codebase? +STEPHANIE: I actually think you're really onto something because what I was just hearing, I love that, like, it can be better. It's less prescribed, I guess, than some other heuristics, like, you know, do not repeat yourself, or whatever. +JOËL: Classic. +STEPHANIE: [laughs] It really encourages, like, the individual to think a little deeper. And it actually reminded me of another...this is actually a bit of a pithy saying, but I find it to be really useful. And I'm curious if you've heard it before. It's a systems thinking heuristic, and the phrase is, the purpose of a system is what it does. +JOËL: Ooh, I have heard that, and I'm trying to remember what context. +STEPHANIE: So, it was coined by a systems thinking expert. Stafford Beer, I think, is his name. And I recently learned about it from a friend. But I think the cool thing is that it can be applied to literally anything [laughs] because everything is a system, you know, or not just software. But I have found a lot of value in applying it to just, like, is this function doing what it says it does, right? Or is it actually also doing, like, a side effect? And turns out, maybe we want to bring that into alignment with what the name of the function is, or try pulling that out, or whatever. I think it can also be true of test suites. +I don't know if this is a heuristic or not. But the idea that we should always be testing or all tests are good, yeah, I guess that could pass as a heuristic. By bringing this perspective of the purpose of a system is what it does, it's like, well, is the test suite also so bloated and takes so long and so flaky that it is actually hindering development? And if that is the case, then maybe there is some reevaluation necessary, right? Rather than just claiming that it's helping us have more confidence in our code when that may or may not be true. +JOËL: You brought up an interesting idea here, which is that heuristics aren't always right. So, you're talking about the idea that a heuristic like good code is tested code might not be correct in 100% of the cases. Like, how accurate does a heuristic need to be in order for it to be really valuable? You know, you're hoping for something that's, like, 90% correct that you can follow most of the time, except in some edge cases, or something maybe as low as, like, 50% where it's a coin toss whether the heuristic applies in the situation or not. Are those still useful? Or are they maybe more confusing than otherwise? +STEPHANIE: Oh wow. That's a really interesting way to frame it because I don't know if I've ever stored information about how well my heuristics are serving me. [laughs] But I do really like the idea that you can use a heuristic as a guiding principle just to try and that you can always back out of it, right? +So, if you're wanting to take DRY to the extremist of extremes, just for fun or just to see how that might go, you can go down that path and, at any point, decide, okay, like, I like this, or I don't like this, and choose a different path. But the idea of kind of tracking, like, how well they're working for you that is really interesting to me, and not something I've tried before. +JOËL: I love the idea of taking a heuristic and, like, doing a side project whose whole goal is just to kind of push that heuristic to the extreme, to the breaking point so that, that way, you get an intuition of, like, when does it work for you? When does it not? That sounds like a really fun exercise for someone to do. Is that something that you've done yourself? +STEPHANIE: Not to the point of a whole side project, but just like I like to try pickles randomly every now and then to see if I like them, [laughs] will just try a new technique and see how it goes. In an episode a while back, we talked about whether we TDD or not, and, to be honest, I don't do it, you know, 100% of the time or all the time. But one day, I did decide to TDD a full-stack feature from start to finish just for fun [laughs], and I enjoyed it. I learned some things about it. +And I think now I've kind of integrated the parts that I liked about it into my development flow. Like, I'm not always going to do it. But I think it also just helped me figure out, like, okay, like, what is this thing about that people claim that is the pinnacle of how we should be writing our code? And how can I decide for myself, like, whether it works for me or just pick and choose the parts of it that work for me? +JOËL: Yeah. That just seems like a really valuable exercise. There are definitely too many heuristics out there to do that for everything. But I guess I've never thought of it quite so concretely. But I almost wonder if I should, like, add this to my kind of personal growth plan to say, like, once a year, I'm going to take a heuristic and kind of push it to an extreme and see what I can learn about it. +STEPHANIE: I actually think what's really cool is the process of, like, any individual developer figuring out what kinds of heuristics they want to follow, as opposed to, you know, like, a mass proclamation that, like, this is the way, right? Are there any heuristics that you have maybe picked up and then let go of because you realized that, you know, they weren't working enough or frequently enough for you or that you just didn't like? +JOËL: I don't know about, like, fully letting go, but definitely kind of recontextualize and sometimes even sort of rewrote them a little bit to work for me. So, a classic one would be the idea that shorter code is more readable. So, it's common to see comments on a pull request sort of like, "Hey, you could make this shorter by doing this." And that can be true to a certain extent. When you get to the point where you're playing code golf, it becomes absolutely unreadable. +But also, there's a point where sometimes using some other heuristics will result in longer code but actually make it more readable on the whole. And so, packing everything into one method might be overall shorter, so it's fewer lines to read going through a class. But maybe extracting some methods or doing that separating branching code from doing code might lead to an overall longer class but an also overall more readable one. So, I think there's probably a lot of caveats that go with that idea. Oftentimes, shorter can be more readable with, you know, two or three asterisks that maybe go a little bit more into the why that is the case. +STEPHANIE: Yeah. I like the contextualizing. That actually reminded me of a talk that I watched recently by Hillel Wayne. It's called Intro to Empirical Software Engineering. And he basically, like, does a deep dive into all these studies about software practices that we think are, quote, unquote, "good," like, as a community or as an industry. And it's like, well, like, how do we actually know? Like, show me the research, right? +And one of the studies that he included was trying to determine if using abbreviations for variable names or using the full words made the code easier to debug or not. And so, the main example that he was using was employee number as a variable, and the abbreviation was EMP num. And it turns out that there was no difference in how easy it was to debug. But the approach that each group that was studied differed. +So, the folks who had the full names, the full words for the variable names, were kind of using an approach of just scanning the code and being able to understand at a higher level the domain, right? Whereas the folks who were debugging with just abbreviations had to work at a bit of a lower level and, you know, or maybe using breakpoints and debugging the code that way. +And I thought that was really cool because, first of all, I think it kind of was trying to prove that, like, we don't actually know if one is better or not. But what is important and interesting to me is the idea that, like, you can choose the method that you like better or that works for you and the human side of it, right? The impact it has on our process. +JOËL: That's really cool. I'll have to go and watch that talk. Building this kind of context and nuance around a heuristic, though, takes a lot of time, takes experience. And part of the value of a heuristic is that we're collapsing down maybe our own experience or somebody else's experience into something that doesn't require you to necessarily do all that work upfront. +How do you feel about sharing and kind of targeting a lot of these heuristics to newer coders who are kind of trying to get better at their craft and looking for ways to improve without necessarily having to do, you know, five years of experience digging into a particular topic? Do you think heuristics are helpful, or do they maybe mislead? +STEPHANIE: I really value when they're presented as an opinion, as opposed to a true fact about code. [laughs] Because I really appreciate when someone is able to explain to me why they chose readability in this particular scenario or why they chose speed and performance. Or maybe they were making a trade-off between accessibility and, you know, something else. To just, like, tell someone, "Oh yeah, like, DRY code is better code," or to just tell someone that without the explanation with, like, offering them the opportunity to reflect themselves on, like, oh, like, where have I seen DRY code that was easier for me to read? That seems a little less helpful in terms of investing in their growth. +JOËL: Yeah. Definitely, I think sharing some of the purpose behind it can often be really useful because most of these heuristics are never an end unto themselves. They're a means to some other end. So, you're not writing code that's DRY just because you want to be cool. You're writing code to be DRY because you're trying to improve readability, make it easier to change so you don't have to change it in multiple places. You want to maybe reduce the chance of certain types of bugs. +These are all actual purposes of what you want to do in your code. DRY is just one way of getting there. But oftentimes, we might skip that part and just be like, hey, you should make your code DRY because DRY is the best. And it can be, but it's in service to these other goals. +STEPHANIE: I think when I am sharing those types of heuristics that are more commonly held, I also do like to preface, like, some people think this, or some people like to do things this way, just to be clear that they don't have to like it or do it. In general, I always prefer injecting more nuance [laughs] into the conversation. But yeah, like, it is a really personal process, I think, and figuring out, like, how any individual makes decisions about, like, all the code they're writing. You have to make a million [laughs] decisions every time you do it. +So, yes, like, those heuristics do provide a shortcut. And also, I think it's worth taking the time to think about if it's working, especially for the specific context that you're applying it, right? Because that also can change. And, I don't know, maybe I'm just skeptical of any one size fits all solution. +JOËL: I think for myself, with many heuristics, as a beginner coder, I had a bit of, like, a spiral journey, or maybe kind of going up a set of stairs. So, as a brand-new developer, I would make a lot of duplication bugs in my code, where, you know, I would have the same value in multiple places, and then I'd change it in one place, and I don't remember to change it in other places, and the code breaks. +And so, being introduced to the idea of DRY actually helped my code get quite a bit better. It was, like, a net positive on my experience because I was not getting burned by all these bugs quite so frequently. And so, for a while, just throwing more DRY into my code just made my life better. And then, eventually, you kind of hit that plateau where I don't run into the pain of these bugs anymore. But now I keep doing more DRY somewhat mindlessly. And I end up with this pile of abstractions that are actually really brittle or frustrating to work with. And now, I have to rethink some of the assumptions behind the heuristic. +And then, at that point, yep, maybe recontextualize a little bit, learn about when it's good, when are the trade-offs not worth it. Now I have a better understanding, and I kind of go on another growth bit where it makes a lot of my code better until maybe I hit another plateau. I've kind of maxed out the benefits. I start seeing some of the pain, and then, again, I have to go through this cycle again. And maybe the approach you were talking about earlier, where you do a side project and kind of push a heuristic to its breaking point, is a way to kind of speed run that process. +STEPHANIE: Yeah, that's really interesting because you're just committing to it and trying to learn everything you can from it in a very concentrated setting. I also wonder, and it's totally fine if you don't know, but if someone had told you kind of all of those reasons you listed about why DRY code, like, what that achieves, if that may have reframed how you were thinking about applying it. Or was that also something that had to come from doing it enough? +JOËL: I think as a brand-new developer, a lot of that would have gone over my head. I was still really shaky on the concept of abstraction. When is it useful? When is it not? So, a lot of those more subtle pitfalls, I think, would not have been relevant to me at that point in my career, even the concept of readability, right? When I'm a brand-new programmer, I'm still getting used to reading a lot of code. +And so, the idea that code might be written in a way that's unreadable or more challenging to read, it might just feel like, oh, I just need to get better, improve myself. It's not that the code is written in a hard-to-read way. It's just I don't have enough experience at reading code. And I think that's a common thing that we do as beginners at everything, right? We start by blaming ourselves when things get hard. +STEPHANIE: Yeah. I was just thinking that, you know, if you are sharing heuristics with a newer developer or an early-career developer, at the end of the day, like, really, I'm not sure about the value of just dropping it on them and letting them run [laughs] with it. But I think what could be really, really effective is just having a sustained relationship with them and, like, continuing that conversation. It's, like, maybe in a code review or in a pairing session being like, "Oh yeah, like, I see you're practicing DRY. Like, what do you think about how this made this piece of code different?" And kind of baking in that process of self-discovery along the way and speeding it up in that way as well. +JOËL: So, what you're really saying is the one heuristic to rule them all is code in community. +STEPHANIE: I love that. I'm totally with you. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. +Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Want a cool cucumber salad? Joël's got you covered. Stephanie has evolved and found some pickles she enjoys.

+ +

Experienced programmers use a lot of heuristics or "rules of thumb" about what makes their code better. These aren't always true, but they work in most situations. Stephanie and Joël discuss a range of heuristics, how to use them, how to come up with them, how to know when to break them, and how to teach them to more junior devs.

+ +
+ + + +

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, as of the recording of this, summer is in full swing, and it's the time of year where we have all these, you know, fresh vegetables out, so I've been really enjoying a lot of those. I think this week; in particular, I've been going into, like, all the variations on cucumber salads.

+ +

STEPHANIE: Ooh.

+ +

JOËL: Yeah. So, that's been kind of fun for me. A fun thing I've been doing to spice this up is pickling mustard seeds to add as a topping. That's actually really amazing. It adds just a little bit of acidity, a little bit of crunch, a little bit of texture. And it's pretty.

+ +

STEPHANIE: That sounds so delicious. And also, I was going to share something about pickles about what's new in my world. [laughs] But first, I am curious, what has been your go-to cucumber salad that you put this pickled mustard seed situation on top?

+ +

JOËL: So, cucumbers and tomatoes is just the base of everything. And then, it kind of goes with random things I have in my fridge. A little bit of goat cheese on top can be a great topping, big fan of balsamic glaze. You can just get, like, a bottle of that at the grocery store, the pickled mustard seeds. I've recently been trying topping with a fried egg.

+ +

STEPHANIE: Ooh, that sounds really fun. It kind of, like, adds a bit of savoriness and creaminess and maybe even, like, the crunchy fried edges. That sounds really yummy.

+ +

JOËL: Particularly if you do it over easy where the center is not fully cooked. When the egg breaks, you effectively get salad dressing for free.

+ +

STEPHANIE: That sounds so delicious.

+ +

JOËL: Summer vegetables, they're great.

+ +

STEPHANIE: They are great. Last year, I did have a cucumber garden, as in a garden, and a few cucumber plants that were too prolific for me, to be honest. I found myself overrun with cucumbers and having to give them away because we just didn't eat them enough. And this year, we scaled back a little bit [laughs] on the cucs. But I am so excited to bring up what's new in my world now because it's, like, so related, and we did not plan this at all. But I have a silly little thing to share about my own pickle journey. So, I used to be a pickle hater.

+ +

JOËL: You know what? Same.

+ +

STEPHANIE: Oh my gosh, incredible. Another new thing we've learned about each other. I really, like, wanted to like pickles because, you know, when you order a sandwich in a restaurant, it always comes with the pickle spear. And neither me nor my partner were into pickles, and we would always leave the spear uneaten on the plate, and we felt so bad about it. I felt really bad about it.

+ +

And so, every, like, three to six months or so, I'd be like, okay, I'm going to gather the courage to try the pickle again and see if maybe my taste buds have changed, and this time I'll like it. And, you know, I would try a bite and just be like, no, no, I don't think it's for me. [laughs] But I guess I was just so primed to do something about, like, wanting to eliminate this really inconsequential food waste. But every time it happened, I would just, you know, [laughs] be, like, oh, if only I loved pickles.

+ +

And I got my friend, who is a pickle connoisseur, to help me figure out, like, what pickles I might like. So, I asked her to come up with, like, a pickle sampler for me because I really hadn't tried all too many. And that actually really helped me find which ones were a little more palatable to me. So, I found out that I liked the sweeter ones. There's, like, a bread and butter pickle that can be quite sweet. Your diner pickle can be very different from a jar of, like, fancy pickles. [laughs]

+ +

JOËL: Definitely.

+ +

STEPHANIE: One day, she gifted me a jar of, like, Polish gherkins that were delicious.

+ +

JOËL: Hmmm.

+ +

STEPHANIE: I was like, wow, I can just snack on these. So, the thing that's new is that this time, I went to an Eastern European grocery store, and I bought my own jar of pickled gherkins. And that was something that Stephanie, like, two years ago, would never even do. [laughs]

+ +

JOËL: That's really cool that you got a chance to sort of explore a broader range of what was available in the pickle world and then were able to find kind of your niche there and discover something new that you actually like.

+ +

STEPHANIE: Yeah, it was very fun. And now I feel like my whole world has opened up to, you know, pickley and fermented things and just, like, get to enjoy even more snacks.

+ +

So, to move away from pickles, recently, on my client project, I've been pairing a lot more with other client developers. And one thing that has come up is, you know, talking about our reasoning or our thought process for when we're pairing on some code. And I realized that I have built up a lot of either intuition or maybe some rules that I like to follow when I'm writing code, writing a test, or even doing a code review. And I've realized that you know, as developers, we often use these kinds of shortcuts or heuristics to help orient us as we're doing our work.

+ +

JOËL: Yeah. I think that's definitely something that either comes yourself from experience or sometimes is passed along, and you get to benefit from somebody else's experience. They learned the hard way a lot of these tips and tricks, and now they kind of pass on some of these guidelines to us. Do you have any favorites that you reach for frequently?

+ +

STEPHANIE: So, one way I like to approach a problem is to start messy [laughs] and to kind of see what that gets me and then where to go from there. I find that it's a little bit easier for me to draw on things that I've, you know, learned or picked up and tips once I have something in front of me to react to. So, maybe I will just go with the naive implementation and just write all of the code in one method, you know, in a class. And from there, now that it's out of my system, can I kind of come back in with a finer tooth comb and then apply more of a sustained effort to clean things up, right?

+ +

And, to me, the question I find myself asking is, like, can this be extracted further? And so, you know, if I have everything in one giant method, then yes, [laughs] there is likely, you know, many opportunities to extract that, and maybe I will see something like, oh, the way that I spaced out this code that might be a signal to me that, like, these are some ideas that are grouped together, and I can pull something out there.

+ +

JOËL: Do you have a heuristic around when to stop extracting?

+ +

STEPHANIE: That's a good point. I think I tend to stop when I have kind of pulled out the classes that make sense to me. And, at that point, you know, like, maybe there is more extraction that can be done. But at a certain point, you know, you then get these really tiny classes that maybe don't hold their weight. And I think that's also true of methods that then call other methods, and that's the only thing that they do.

+ +

Then it's like, well, is this too extracted that it's not really giving a future reader helpful information, right? I want the extraction to improve readability. And that tends to be another lens through which I am applying to this idea of, like, can I extract further? Is this extraction helpful for understanding this code?

+ +

JOËL: I like the idea of looking at the code through multiple lenses. And so, sometimes you look at it through the lens of, yeah, are there enough moving parts here? Or does it feel kind of brittle and all in one place? And then sometimes completely shifting your lens and saying, you know what? Let's put myself in the seat of someone who's looking at this code for the first time. Can I understand it?

+ +

So, structuring and extracting code is a big part of the work that we do. And I also happen to have a couple of heuristics that I like to use. One is separate branching code from doing code. So, if I have an if...else condition, I try not to put ten lines of logic inside each branch; instead, I have just a call out to a method so that the only thing the conditional does is to choose which path you go, and then each individual path is its own method.

+ +

Similarly, if I'm writing a method, I'm not going to have a bunch of logic then a conditional mixed in together. So, my heuristic is a method gets to do one of two things. It either gets to choose a path to take or it gets to do a thing, but you can't mix and match both.

+ +

STEPHANIE: Yeah, that makes a lot of sense. I really appreciate a well-named method that is, you know, determining, like, what condition needs to happen because then that helps me, yeah, like, avoid having to hold all of this information about this condition or this other condition, and this other condition in order to figure out what path I'm trying to take.

+ +

JOËL: And the naming and the readability, I think, is a big part of this. Another heuristic that I like to use that kind of converges on the same result is trying to write each method at a single level of abstraction. So, if I am writing a method that has some kind of high-level terms it's using, I'm not going to also mix in a lot of low-level implementation. And then, similarly, if it's a method that's doing a lot of, like, low-level nuts and bolts things, I'm going to try not to pull in some of these higher-level domain name methods in there.

+ +

And so, by separating things out so that every method reads one level of abstraction, you make it much easier for the reader to go through and figure out what's happening. Are we kind of getting that more 10,000-foot view, getting a sense of what's happening, and saying, okay, we want to process the user form, and then we want to send off an email, and then we want to, you know, write to a file? Or are we going through, okay, we're going to increment a counter so that we get exponential back off on our [inaudible 10:28] request? Those two things do not belong together in the same method.

+ +

STEPHANIE: Yeah, absolutely. I really like this heuristic. And I have been applying it more and more and found it really useful for making sure that you're handling your errors correctly, especially because, at different levels of abstraction, you want to do different things with your errors, right?

+ +

An implementation error that's raised because, you know, you're calling something accidentally on nil, or maybe a third-party service is down, and you get a custom error, whatever that is, those concerns are different from how you want to handle things at the controller level. And oftentimes, I see those things really mixed together, and honestly, I think leads to a lot of buggy code when you're trying to handle things that can go wrong at the wrong level of abstraction.

+ +

JOËL: Yeah. Is there a good heuristic around what level you think is best to trigger an exception? Or maybe, more generally, just being aware of different levels of abstraction and knowing that catching or triggering errors at each level will have different impacts.

+ +

STEPHANIE: I think more of the latter, the having an awareness of what kinds of errors might be possible and what impact that has on the user, right? The user being either an actual customer or, you know, another developer who has to read a notification from an error monitoring service. [laughs]

+ +

JOËL: This is really interesting to me because I think we've now bridged the concept of heuristics into the idea of mental models. So, the heuristic is write your methods at a single level of abstraction, but that then leads into a mental model where maybe code is structured in three or four different layers. You've got a low level, a mid-level, a high level, something like that, of abstraction. And now, you can use that mental model to start thinking about what are the impacts of exceptions at each layer?

+ +

And then, maybe you complete the circle by creating a heuristic that relies on that mental model, maybe, I don't know, raise in the low-level rescue at the top level or something. I'm making something absolutely arbitrary up right now. But somehow, we've gone from heuristic, which creates a mental model, which then allows us to build new heuristics on top of that, and that seems like a virtuous cycle to me.

+ +

STEPHANIE: Yeah, absolutely. I think what I'm also picking up is the idea that you do need a mental model, or you do need to draw on your own ideas about something in order to apply the heuristic, right? You know, someone could tell you to separate branching code from doing code. But maybe you don't know what that means or, like, maybe you don't see why that's important. And sure, you can still apply it and try your best to follow it. But, in some ways, I think that the best heuristics are ones that you've kind of developed for yourself based on your own experience.

+ +

JOËL: That's really interesting. I think once you've built from your own experience, I definitely feel like they're really impactful because you've kind of synthesized 2, 5, 10, 20 years of experience doing some of this work into, oftentimes, like, you know, a pithy one-line sentence, 5, 6 words that convey an approach that you've found works best, you know, maybe 80% or 90% of the time. The power of synthesis for your own self-learning I think it's really hard to understate.

+ +

So, I'm curious if there's any other heuristics that you commonly use that you kind of created yourself based off your own experience rather than just having it be more of a broadly received idea from the community.

+ +

STEPHANIE: I think, for me, it's more so that the experience has helped affirm certain heuristics and also made me feel more comfortable with letting others go. And one that I heard a lot but, like, didn't quite understand until really working through it deeper is the idea of feeling pain when you write a test, and that being a signal of opportunities to try different design with your code. And I just didn't know what that pain was at the beginning. Like, what does that even mean? [laughs] Like, how can a test cause me pain?

+ +

But on my own, I realized, oh, like, actually, I get really frustrated when I need to stub out a whole method chain, right? And I find myself having to go look up how to do that or just spending a lot of time having to do something that I haven't done before. Maybe the pain comes from having to change a lot of files because, oh no, like, I also broke 20 other tests in the process.

+ +

But when you're first starting out, oftentimes, you, like, don't know that that is not normal [laughs]; at least, that was true for me. And so, that was something that I had heard about, like, if you are feeling pain when writing a test, then, like, maybe reconsider your code design. But when you don't know how to identify what that pain is, and you also, like, don't know where to go from there, I find that, you know, the heuristic can only help you so much.

+ +

JOËL: Yeah. Maybe that's something that's challenging with a heuristic in that they're often expressed as these pithy sentences. But if you're not familiar with some of the underlying concepts, that might make them harder to apply, which is unfortunate because, oftentimes, these heuristics that we've developed as a community are targeted to newcomers to help them kind of avoid the mistakes that we've made along the way.

+ +

STEPHANIE: I think what really helped me the most in connecting a heuristic that's commonly expressed and my own experience is when I've had someone ask me about how I'm feeling when I'm, you know, making some kind of decision or when I'm reading some code. Like, what do I think of this, or what has been my experience with this? And giving me the opportunity on the spot to synthesize that information. Because otherwise, it's hard to figure out, you know, like, what is just normal? This is just life as a developer [laughs]. And what are opportunities to maybe gain some more insight about the work itself?

+ +

JOËL: One thing that I've learned over time as a developer, and I'm not sure if this quite rises to the level of a heuristic, but a lot of, like, pain and frustration in development doesn't necessarily have to be that way. And it's not necessarily because I'm bad at the job or I'm too new to the technology or whatever. It can often be a sign of underlying design issues or the fact that the system was modeled with certain assumptions that are no longer true. These can often be signals that you can make things better.

+ +

So, I think if I had to reduce this idea down to a clever one-liner, it'd be something along the lines of, it can be better, or it doesn't have to be this bad. You're writing a test, and it's really annoying. There might be a better way to structure the underlying code that would make the test better. You're having to do some, like, really clunky code to deal with something. Is there maybe a better object design that would make a lot of that pain go away, or at least kind of quarantine it in a certain part of the codebase?

+ +

STEPHANIE: I actually think you're really onto something because what I was just hearing, I love that, like, it can be better. It's less prescribed, I guess, than some other heuristics, like, you know, do not repeat yourself, or whatever.

+ +

JOËL: Classic.

+ +

STEPHANIE: [laughs] It really encourages, like, the individual to think a little deeper. And it actually reminded me of another...this is actually a bit of a pithy saying, but I find it to be really useful. And I'm curious if you've heard it before. It's a systems thinking heuristic, and the phrase is, the purpose of a system is what it does.

+ +

JOËL: Ooh, I have heard that, and I'm trying to remember what context.

+ +

STEPHANIE: So, it was coined by a systems thinking expert. Stafford Beer, I think, is his name. And I recently learned about it from a friend. But I think the cool thing is that it can be applied to literally anything [laughs] because everything is a system, you know, or not just software. But I have found a lot of value in applying it to just, like, is this function doing what it says it does, right? Or is it actually also doing, like, a side effect? And turns out, maybe we want to bring that into alignment with what the name of the function is, or try pulling that out, or whatever. I think it can also be true of test suites.

+ +

I don't know if this is a heuristic or not. But the idea that we should always be testing or all tests are good, yeah, I guess that could pass as a heuristic. By bringing this perspective of the purpose of a system is what it does, it's like, well, is the test suite also so bloated and takes so long and so flaky that it is actually hindering development? And if that is the case, then maybe there is some reevaluation necessary, right? Rather than just claiming that it's helping us have more confidence in our code when that may or may not be true.

+ +

JOËL: You brought up an interesting idea here, which is that heuristics aren't always right. So, you're talking about the idea that a heuristic like good code is tested code might not be correct in 100% of the cases. Like, how accurate does a heuristic need to be in order for it to be really valuable? You know, you're hoping for something that's, like, 90% correct that you can follow most of the time, except in some edge cases, or something maybe as low as, like, 50% where it's a coin toss whether the heuristic applies in the situation or not. Are those still useful? Or are they maybe more confusing than otherwise?

+ +

STEPHANIE: Oh wow. That's a really interesting way to frame it because I don't know if I've ever stored information about how well my heuristics are serving me. [laughs] But I do really like the idea that you can use a heuristic as a guiding principle just to try and that you can always back out of it, right?

+ +

So, if you're wanting to take DRY to the extremist of extremes, just for fun or just to see how that might go, you can go down that path and, at any point, decide, okay, like, I like this, or I don't like this, and choose a different path. But the idea of kind of tracking, like, how well they're working for you that is really interesting to me, and not something I've tried before.

+ +

JOËL: I love the idea of taking a heuristic and, like, doing a side project whose whole goal is just to kind of push that heuristic to the extreme, to the breaking point so that, that way, you get an intuition of, like, when does it work for you? When does it not? That sounds like a really fun exercise for someone to do. Is that something that you've done yourself?

+ +

STEPHANIE: Not to the point of a whole side project, but just like I like to try pickles randomly every now and then to see if I like them, [laughs] will just try a new technique and see how it goes. In an episode a while back, we talked about whether we TDD or not, and, to be honest, I don't do it, you know, 100% of the time or all the time. But one day, I did decide to TDD a full-stack feature from start to finish just for fun [laughs], and I enjoyed it. I learned some things about it.

+ +

And I think now I've kind of integrated the parts that I liked about it into my development flow. Like, I'm not always going to do it. But I think it also just helped me figure out, like, okay, like, what is this thing about that people claim that is the pinnacle of how we should be writing our code? And how can I decide for myself, like, whether it works for me or just pick and choose the parts of it that work for me?

+ +

JOËL: Yeah. That just seems like a really valuable exercise. There are definitely too many heuristics out there to do that for everything. But I guess I've never thought of it quite so concretely. But I almost wonder if I should, like, add this to my kind of personal growth plan to say, like, once a year, I'm going to take a heuristic and kind of push it to an extreme and see what I can learn about it.

+ +

STEPHANIE: I actually think what's really cool is the process of, like, any individual developer figuring out what kinds of heuristics they want to follow, as opposed to, you know, like, a mass proclamation that, like, this is the way, right? Are there any heuristics that you have maybe picked up and then let go of because you realized that, you know, they weren't working enough or frequently enough for you or that you just didn't like?

+ +

JOËL: I don't know about, like, fully letting go, but definitely kind of recontextualize and sometimes even sort of rewrote them a little bit to work for me. So, a classic one would be the idea that shorter code is more readable. So, it's common to see comments on a pull request sort of like, "Hey, you could make this shorter by doing this." And that can be true to a certain extent. When you get to the point where you're playing code golf, it becomes absolutely unreadable.

+ +

But also, there's a point where sometimes using some other heuristics will result in longer code but actually make it more readable on the whole. And so, packing everything into one method might be overall shorter, so it's fewer lines to read going through a class. But maybe extracting some methods or doing that separating branching code from doing code might lead to an overall longer class but an also overall more readable one. So, I think there's probably a lot of caveats that go with that idea. Oftentimes, shorter can be more readable with, you know, two or three asterisks that maybe go a little bit more into the why that is the case.

+ +

STEPHANIE: Yeah. I like the contextualizing. That actually reminded me of a talk that I watched recently by Hillel Wayne. It's called Intro to Empirical Software Engineering. And he basically, like, does a deep dive into all these studies about software practices that we think are, quote, unquote, "good," like, as a community or as an industry. And it's like, well, like, how do we actually know? Like, show me the research, right?

+ +

And one of the studies that he included was trying to determine if using abbreviations for variable names or using the full words made the code easier to debug or not. And so, the main example that he was using was employee number as a variable, and the abbreviation was EMP num. And it turns out that there was no difference in how easy it was to debug. But the approach that each group that was studied differed.

+ +

So, the folks who had the full names, the full words for the variable names, were kind of using an approach of just scanning the code and being able to understand at a higher level the domain, right? Whereas the folks who were debugging with just abbreviations had to work at a bit of a lower level and, you know, or maybe using breakpoints and debugging the code that way.

+ +

And I thought that was really cool because, first of all, I think it kind of was trying to prove that, like, we don't actually know if one is better or not. But what is important and interesting to me is the idea that, like, you can choose the method that you like better or that works for you and the human side of it, right? The impact it has on our process.

+ +

JOËL: That's really cool. I'll have to go and watch that talk. Building this kind of context and nuance around a heuristic, though, takes a lot of time, takes experience. And part of the value of a heuristic is that we're collapsing down maybe our own experience or somebody else's experience into something that doesn't require you to necessarily do all that work upfront.

+ +

How do you feel about sharing and kind of targeting a lot of these heuristics to newer coders who are kind of trying to get better at their craft and looking for ways to improve without necessarily having to do, you know, five years of experience digging into a particular topic? Do you think heuristics are helpful, or do they maybe mislead?

+ +

STEPHANIE: I really value when they're presented as an opinion, as opposed to a true fact about code. [laughs] Because I really appreciate when someone is able to explain to me why they chose readability in this particular scenario or why they chose speed and performance. Or maybe they were making a trade-off between accessibility and, you know, something else. To just, like, tell someone, "Oh yeah, like, DRY code is better code," or to just tell someone that without the explanation with, like, offering them the opportunity to reflect themselves on, like, oh, like, where have I seen DRY code that was easier for me to read? That seems a little less helpful in terms of investing in their growth.

+ +

JOËL: Yeah. Definitely, I think sharing some of the purpose behind it can often be really useful because most of these heuristics are never an end unto themselves. They're a means to some other end. So, you're not writing code that's DRY just because you want to be cool. You're writing code to be DRY because you're trying to improve readability, make it easier to change so you don't have to change it in multiple places. You want to maybe reduce the chance of certain types of bugs.

+ +

These are all actual purposes of what you want to do in your code. DRY is just one way of getting there. But oftentimes, we might skip that part and just be like, hey, you should make your code DRY because DRY is the best. And it can be, but it's in service to these other goals.

+ +

STEPHANIE: I think when I am sharing those types of heuristics that are more commonly held, I also do like to preface, like, some people think this, or some people like to do things this way, just to be clear that they don't have to like it or do it. In general, I always prefer injecting more nuance [laughs] into the conversation. But yeah, like, it is a really personal process, I think, and figuring out, like, how any individual makes decisions about, like, all the code they're writing. You have to make a million [laughs] decisions every time you do it.

+ +

So, yes, like, those heuristics do provide a shortcut. And also, I think it's worth taking the time to think about if it's working, especially for the specific context that you're applying it, right? Because that also can change. And, I don't know, maybe I'm just skeptical of any one size fits all solution.

+ +

JOËL: I think for myself, with many heuristics, as a beginner coder, I had a bit of, like, a spiral journey, or maybe kind of going up a set of stairs. So, as a brand-new developer, I would make a lot of duplication bugs in my code, where, you know, I would have the same value in multiple places, and then I'd change it in one place, and I don't remember to change it in other places, and the code breaks.

+ +

And so, being introduced to the idea of DRY actually helped my code get quite a bit better. It was, like, a net positive on my experience because I was not getting burned by all these bugs quite so frequently. And so, for a while, just throwing more DRY into my code just made my life better. And then, eventually, you kind of hit that plateau where I don't run into the pain of these bugs anymore. But now I keep doing more DRY somewhat mindlessly. And I end up with this pile of abstractions that are actually really brittle or frustrating to work with. And now, I have to rethink some of the assumptions behind the heuristic.

+ +

And then, at that point, yep, maybe recontextualize a little bit, learn about when it's good, when are the trade-offs not worth it. Now I have a better understanding, and I kind of go on another growth bit where it makes a lot of my code better until maybe I hit another plateau. I've kind of maxed out the benefits. I start seeing some of the pain, and then, again, I have to go through this cycle again. And maybe the approach you were talking about earlier, where you do a side project and kind of push a heuristic to its breaking point, is a way to kind of speed run that process.

+ +

STEPHANIE: Yeah, that's really interesting because you're just committing to it and trying to learn everything you can from it in a very concentrated setting. I also wonder, and it's totally fine if you don't know, but if someone had told you kind of all of those reasons you listed about why DRY code, like, what that achieves, if that may have reframed how you were thinking about applying it. Or was that also something that had to come from doing it enough?

+ +

JOËL: I think as a brand-new developer, a lot of that would have gone over my head. I was still really shaky on the concept of abstraction. When is it useful? When is it not? So, a lot of those more subtle pitfalls, I think, would not have been relevant to me at that point in my career, even the concept of readability, right? When I'm a brand-new programmer, I'm still getting used to reading a lot of code.

+ +

And so, the idea that code might be written in a way that's unreadable or more challenging to read, it might just feel like, oh, I just need to get better, improve myself. It's not that the code is written in a hard-to-read way. It's just I don't have enough experience at reading code. And I think that's a common thing that we do as beginners at everything, right? We start by blaming ourselves when things get hard.

+ +

STEPHANIE: Yeah. I was just thinking that, you know, if you are sharing heuristics with a newer developer or an early-career developer, at the end of the day, like, really, I'm not sure about the value of just dropping it on them and letting them run [laughs] with it. But I think what could be really, really effective is just having a sustained relationship with them and, like, continuing that conversation. It's, like, maybe in a code review or in a pairing session being like, "Oh yeah, like, I see you're practicing DRY. Like, what do you think about how this made this piece of code different?" And kind of baking in that process of self-discovery along the way and speeding it up in that way as well.

+ +

JOËL: So, what you're really saying is the one heuristic to rule them all is code in community.

+ +

STEPHANIE: I love that. I'm totally with you.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Want a cool cucumber salad? Joël's got you covered. Stephanie has evolved and found some pickles she enjoys.

+ +

Experienced programmers use a lot of heuristics or "rules of thumb" about what makes their code better. These aren't always true, but they work in most situations. Stephanie and Joël discuss a range of heuristics, how to use them, how to come up with them, how to know when to break them, and how to teach them to more junior devs.

+ +
+ + + +

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, as of the recording of this, summer is in full swing, and it's the time of year where we have all these, you know, fresh vegetables out, so I've been really enjoying a lot of those. I think this week; in particular, I've been going into, like, all the variations on cucumber salads.

+ +

STEPHANIE: Ooh.

+ +

JOËL: Yeah. So, that's been kind of fun for me. A fun thing I've been doing to spice this up is pickling mustard seeds to add as a topping. That's actually really amazing. It adds just a little bit of acidity, a little bit of crunch, a little bit of texture. And it's pretty.

+ +

STEPHANIE: That sounds so delicious. And also, I was going to share something about pickles about what's new in my world. [laughs] But first, I am curious, what has been your go-to cucumber salad that you put this pickled mustard seed situation on top?

+ +

JOËL: So, cucumbers and tomatoes is just the base of everything. And then, it kind of goes with random things I have in my fridge. A little bit of goat cheese on top can be a great topping, big fan of balsamic glaze. You can just get, like, a bottle of that at the grocery store, the pickled mustard seeds. I've recently been trying topping with a fried egg.

+ +

STEPHANIE: Ooh, that sounds really fun. It kind of, like, adds a bit of savoriness and creaminess and maybe even, like, the crunchy fried edges. That sounds really yummy.

+ +

JOËL: Particularly if you do it over easy where the center is not fully cooked. When the egg breaks, you effectively get salad dressing for free.

+ +

STEPHANIE: That sounds so delicious.

+ +

JOËL: Summer vegetables, they're great.

+ +

STEPHANIE: They are great. Last year, I did have a cucumber garden, as in a garden, and a few cucumber plants that were too prolific for me, to be honest. I found myself overrun with cucumbers and having to give them away because we just didn't eat them enough. And this year, we scaled back a little bit [laughs] on the cucs. But I am so excited to bring up what's new in my world now because it's, like, so related, and we did not plan this at all. But I have a silly little thing to share about my own pickle journey. So, I used to be a pickle hater.

+ +

JOËL: You know what? Same.

+ +

STEPHANIE: Oh my gosh, incredible. Another new thing we've learned about each other. I really, like, wanted to like pickles because, you know, when you order a sandwich in a restaurant, it always comes with the pickle spear. And neither me nor my partner were into pickles, and we would always leave the spear uneaten on the plate, and we felt so bad about it. I felt really bad about it.

+ +

And so, every, like, three to six months or so, I'd be like, okay, I'm going to gather the courage to try the pickle again and see if maybe my taste buds have changed, and this time I'll like it. And, you know, I would try a bite and just be like, no, no, I don't think it's for me. [laughs] But I guess I was just so primed to do something about, like, wanting to eliminate this really inconsequential food waste. But every time it happened, I would just, you know, [laughs] be, like, oh, if only I loved pickles.

+ +

And I got my friend, who is a pickle connoisseur, to help me figure out, like, what pickles I might like. So, I asked her to come up with, like, a pickle sampler for me because I really hadn't tried all too many. And that actually really helped me find which ones were a little more palatable to me. So, I found out that I liked the sweeter ones. There's, like, a bread and butter pickle that can be quite sweet. Your diner pickle can be very different from a jar of, like, fancy pickles. [laughs]

+ +

JOËL: Definitely.

+ +

STEPHANIE: One day, she gifted me a jar of, like, Polish gherkins that were delicious.

+ +

JOËL: Hmmm.

+ +

STEPHANIE: I was like, wow, I can just snack on these. So, the thing that's new is that this time, I went to an Eastern European grocery store, and I bought my own jar of pickled gherkins. And that was something that Stephanie, like, two years ago, would never even do. [laughs]

+ +

JOËL: That's really cool that you got a chance to sort of explore a broader range of what was available in the pickle world and then were able to find kind of your niche there and discover something new that you actually like.

+ +

STEPHANIE: Yeah, it was very fun. And now I feel like my whole world has opened up to, you know, pickley and fermented things and just, like, get to enjoy even more snacks.

+ +

So, to move away from pickles, recently, on my client project, I've been pairing a lot more with other client developers. And one thing that has come up is, you know, talking about our reasoning or our thought process for when we're pairing on some code. And I realized that I have built up a lot of either intuition or maybe some rules that I like to follow when I'm writing code, writing a test, or even doing a code review. And I've realized that you know, as developers, we often use these kinds of shortcuts or heuristics to help orient us as we're doing our work.

+ +

JOËL: Yeah. I think that's definitely something that either comes yourself from experience or sometimes is passed along, and you get to benefit from somebody else's experience. They learned the hard way a lot of these tips and tricks, and now they kind of pass on some of these guidelines to us. Do you have any favorites that you reach for frequently?

+ +

STEPHANIE: So, one way I like to approach a problem is to start messy [laughs] and to kind of see what that gets me and then where to go from there. I find that it's a little bit easier for me to draw on things that I've, you know, learned or picked up and tips once I have something in front of me to react to. So, maybe I will just go with the naive implementation and just write all of the code in one method, you know, in a class. And from there, now that it's out of my system, can I kind of come back in with a finer tooth comb and then apply more of a sustained effort to clean things up, right?

+ +

And, to me, the question I find myself asking is, like, can this be extracted further? And so, you know, if I have everything in one giant method, then yes, [laughs] there is likely, you know, many opportunities to extract that, and maybe I will see something like, oh, the way that I spaced out this code that might be a signal to me that, like, these are some ideas that are grouped together, and I can pull something out there.

+ +

JOËL: Do you have a heuristic around when to stop extracting?

+ +

STEPHANIE: That's a good point. I think I tend to stop when I have kind of pulled out the classes that make sense to me. And, at that point, you know, like, maybe there is more extraction that can be done. But at a certain point, you know, you then get these really tiny classes that maybe don't hold their weight. And I think that's also true of methods that then call other methods, and that's the only thing that they do.

+ +

Then it's like, well, is this too extracted that it's not really giving a future reader helpful information, right? I want the extraction to improve readability. And that tends to be another lens through which I am applying to this idea of, like, can I extract further? Is this extraction helpful for understanding this code?

+ +

JOËL: I like the idea of looking at the code through multiple lenses. And so, sometimes you look at it through the lens of, yeah, are there enough moving parts here? Or does it feel kind of brittle and all in one place? And then sometimes completely shifting your lens and saying, you know what? Let's put myself in the seat of someone who's looking at this code for the first time. Can I understand it?

+ +

So, structuring and extracting code is a big part of the work that we do. And I also happen to have a couple of heuristics that I like to use. One is separate branching code from doing code. So, if I have an if...else condition, I try not to put ten lines of logic inside each branch; instead, I have just a call out to a method so that the only thing the conditional does is to choose which path you go, and then each individual path is its own method.

+ +

Similarly, if I'm writing a method, I'm not going to have a bunch of logic then a conditional mixed in together. So, my heuristic is a method gets to do one of two things. It either gets to choose a path to take or it gets to do a thing, but you can't mix and match both.

+ +

STEPHANIE: Yeah, that makes a lot of sense. I really appreciate a well-named method that is, you know, determining, like, what condition needs to happen because then that helps me, yeah, like, avoid having to hold all of this information about this condition or this other condition, and this other condition in order to figure out what path I'm trying to take.

+ +

JOËL: And the naming and the readability, I think, is a big part of this. Another heuristic that I like to use that kind of converges on the same result is trying to write each method at a single level of abstraction. So, if I am writing a method that has some kind of high-level terms it's using, I'm not going to also mix in a lot of low-level implementation. And then, similarly, if it's a method that's doing a lot of, like, low-level nuts and bolts things, I'm going to try not to pull in some of these higher-level domain name methods in there.

+ +

And so, by separating things out so that every method reads one level of abstraction, you make it much easier for the reader to go through and figure out what's happening. Are we kind of getting that more 10,000-foot view, getting a sense of what's happening, and saying, okay, we want to process the user form, and then we want to send off an email, and then we want to, you know, write to a file? Or are we going through, okay, we're going to increment a counter so that we get exponential back off on our [inaudible 10:28] request? Those two things do not belong together in the same method.

+ +

STEPHANIE: Yeah, absolutely. I really like this heuristic. And I have been applying it more and more and found it really useful for making sure that you're handling your errors correctly, especially because, at different levels of abstraction, you want to do different things with your errors, right?

+ +

An implementation error that's raised because, you know, you're calling something accidentally on nil, or maybe a third-party service is down, and you get a custom error, whatever that is, those concerns are different from how you want to handle things at the controller level. And oftentimes, I see those things really mixed together, and honestly, I think leads to a lot of buggy code when you're trying to handle things that can go wrong at the wrong level of abstraction.

+ +

JOËL: Yeah. Is there a good heuristic around what level you think is best to trigger an exception? Or maybe, more generally, just being aware of different levels of abstraction and knowing that catching or triggering errors at each level will have different impacts.

+ +

STEPHANIE: I think more of the latter, the having an awareness of what kinds of errors might be possible and what impact that has on the user, right? The user being either an actual customer or, you know, another developer who has to read a notification from an error monitoring service. [laughs]

+ +

JOËL: This is really interesting to me because I think we've now bridged the concept of heuristics into the idea of mental models. So, the heuristic is write your methods at a single level of abstraction, but that then leads into a mental model where maybe code is structured in three or four different layers. You've got a low level, a mid-level, a high level, something like that, of abstraction. And now, you can use that mental model to start thinking about what are the impacts of exceptions at each layer?

+ +

And then, maybe you complete the circle by creating a heuristic that relies on that mental model, maybe, I don't know, raise in the low-level rescue at the top level or something. I'm making something absolutely arbitrary up right now. But somehow, we've gone from heuristic, which creates a mental model, which then allows us to build new heuristics on top of that, and that seems like a virtuous cycle to me.

+ +

STEPHANIE: Yeah, absolutely. I think what I'm also picking up is the idea that you do need a mental model, or you do need to draw on your own ideas about something in order to apply the heuristic, right? You know, someone could tell you to separate branching code from doing code. But maybe you don't know what that means or, like, maybe you don't see why that's important. And sure, you can still apply it and try your best to follow it. But, in some ways, I think that the best heuristics are ones that you've kind of developed for yourself based on your own experience.

+ +

JOËL: That's really interesting. I think once you've built from your own experience, I definitely feel like they're really impactful because you've kind of synthesized 2, 5, 10, 20 years of experience doing some of this work into, oftentimes, like, you know, a pithy one-line sentence, 5, 6 words that convey an approach that you've found works best, you know, maybe 80% or 90% of the time. The power of synthesis for your own self-learning I think it's really hard to understate.

+ +

So, I'm curious if there's any other heuristics that you commonly use that you kind of created yourself based off your own experience rather than just having it be more of a broadly received idea from the community.

+ +

STEPHANIE: I think, for me, it's more so that the experience has helped affirm certain heuristics and also made me feel more comfortable with letting others go. And one that I heard a lot but, like, didn't quite understand until really working through it deeper is the idea of feeling pain when you write a test, and that being a signal of opportunities to try different design with your code. And I just didn't know what that pain was at the beginning. Like, what does that even mean? [laughs] Like, how can a test cause me pain?

+ +

But on my own, I realized, oh, like, actually, I get really frustrated when I need to stub out a whole method chain, right? And I find myself having to go look up how to do that or just spending a lot of time having to do something that I haven't done before. Maybe the pain comes from having to change a lot of files because, oh no, like, I also broke 20 other tests in the process.

+ +

But when you're first starting out, oftentimes, you, like, don't know that that is not normal [laughs]; at least, that was true for me. And so, that was something that I had heard about, like, if you are feeling pain when writing a test, then, like, maybe reconsider your code design. But when you don't know how to identify what that pain is, and you also, like, don't know where to go from there, I find that, you know, the heuristic can only help you so much.

+ +

JOËL: Yeah. Maybe that's something that's challenging with a heuristic in that they're often expressed as these pithy sentences. But if you're not familiar with some of the underlying concepts, that might make them harder to apply, which is unfortunate because, oftentimes, these heuristics that we've developed as a community are targeted to newcomers to help them kind of avoid the mistakes that we've made along the way.

+ +

STEPHANIE: I think what really helped me the most in connecting a heuristic that's commonly expressed and my own experience is when I've had someone ask me about how I'm feeling when I'm, you know, making some kind of decision or when I'm reading some code. Like, what do I think of this, or what has been my experience with this? And giving me the opportunity on the spot to synthesize that information. Because otherwise, it's hard to figure out, you know, like, what is just normal? This is just life as a developer [laughs]. And what are opportunities to maybe gain some more insight about the work itself?

+ +

JOËL: One thing that I've learned over time as a developer, and I'm not sure if this quite rises to the level of a heuristic, but a lot of, like, pain and frustration in development doesn't necessarily have to be that way. And it's not necessarily because I'm bad at the job or I'm too new to the technology or whatever. It can often be a sign of underlying design issues or the fact that the system was modeled with certain assumptions that are no longer true. These can often be signals that you can make things better.

+ +

So, I think if I had to reduce this idea down to a clever one-liner, it'd be something along the lines of, it can be better, or it doesn't have to be this bad. You're writing a test, and it's really annoying. There might be a better way to structure the underlying code that would make the test better. You're having to do some, like, really clunky code to deal with something. Is there maybe a better object design that would make a lot of that pain go away, or at least kind of quarantine it in a certain part of the codebase?

+ +

STEPHANIE: I actually think you're really onto something because what I was just hearing, I love that, like, it can be better. It's less prescribed, I guess, than some other heuristics, like, you know, do not repeat yourself, or whatever.

+ +

JOËL: Classic.

+ +

STEPHANIE: [laughs] It really encourages, like, the individual to think a little deeper. And it actually reminded me of another...this is actually a bit of a pithy saying, but I find it to be really useful. And I'm curious if you've heard it before. It's a systems thinking heuristic, and the phrase is, the purpose of a system is what it does.

+ +

JOËL: Ooh, I have heard that, and I'm trying to remember what context.

+ +

STEPHANIE: So, it was coined by a systems thinking expert. Stafford Beer, I think, is his name. And I recently learned about it from a friend. But I think the cool thing is that it can be applied to literally anything [laughs] because everything is a system, you know, or not just software. But I have found a lot of value in applying it to just, like, is this function doing what it says it does, right? Or is it actually also doing, like, a side effect? And turns out, maybe we want to bring that into alignment with what the name of the function is, or try pulling that out, or whatever. I think it can also be true of test suites.

+ +

I don't know if this is a heuristic or not. But the idea that we should always be testing or all tests are good, yeah, I guess that could pass as a heuristic. By bringing this perspective of the purpose of a system is what it does, it's like, well, is the test suite also so bloated and takes so long and so flaky that it is actually hindering development? And if that is the case, then maybe there is some reevaluation necessary, right? Rather than just claiming that it's helping us have more confidence in our code when that may or may not be true.

+ +

JOËL: You brought up an interesting idea here, which is that heuristics aren't always right. So, you're talking about the idea that a heuristic like good code is tested code might not be correct in 100% of the cases. Like, how accurate does a heuristic need to be in order for it to be really valuable? You know, you're hoping for something that's, like, 90% correct that you can follow most of the time, except in some edge cases, or something maybe as low as, like, 50% where it's a coin toss whether the heuristic applies in the situation or not. Are those still useful? Or are they maybe more confusing than otherwise?

+ +

STEPHANIE: Oh wow. That's a really interesting way to frame it because I don't know if I've ever stored information about how well my heuristics are serving me. [laughs] But I do really like the idea that you can use a heuristic as a guiding principle just to try and that you can always back out of it, right?

+ +

So, if you're wanting to take DRY to the extremist of extremes, just for fun or just to see how that might go, you can go down that path and, at any point, decide, okay, like, I like this, or I don't like this, and choose a different path. But the idea of kind of tracking, like, how well they're working for you that is really interesting to me, and not something I've tried before.

+ +

JOËL: I love the idea of taking a heuristic and, like, doing a side project whose whole goal is just to kind of push that heuristic to the extreme, to the breaking point so that, that way, you get an intuition of, like, when does it work for you? When does it not? That sounds like a really fun exercise for someone to do. Is that something that you've done yourself?

+ +

STEPHANIE: Not to the point of a whole side project, but just like I like to try pickles randomly every now and then to see if I like them, [laughs] will just try a new technique and see how it goes. In an episode a while back, we talked about whether we TDD or not, and, to be honest, I don't do it, you know, 100% of the time or all the time. But one day, I did decide to TDD a full-stack feature from start to finish just for fun [laughs], and I enjoyed it. I learned some things about it.

+ +

And I think now I've kind of integrated the parts that I liked about it into my development flow. Like, I'm not always going to do it. But I think it also just helped me figure out, like, okay, like, what is this thing about that people claim that is the pinnacle of how we should be writing our code? And how can I decide for myself, like, whether it works for me or just pick and choose the parts of it that work for me?

+ +

JOËL: Yeah. That just seems like a really valuable exercise. There are definitely too many heuristics out there to do that for everything. But I guess I've never thought of it quite so concretely. But I almost wonder if I should, like, add this to my kind of personal growth plan to say, like, once a year, I'm going to take a heuristic and kind of push it to an extreme and see what I can learn about it.

+ +

STEPHANIE: I actually think what's really cool is the process of, like, any individual developer figuring out what kinds of heuristics they want to follow, as opposed to, you know, like, a mass proclamation that, like, this is the way, right? Are there any heuristics that you have maybe picked up and then let go of because you realized that, you know, they weren't working enough or frequently enough for you or that you just didn't like?

+ +

JOËL: I don't know about, like, fully letting go, but definitely kind of recontextualize and sometimes even sort of rewrote them a little bit to work for me. So, a classic one would be the idea that shorter code is more readable. So, it's common to see comments on a pull request sort of like, "Hey, you could make this shorter by doing this." And that can be true to a certain extent. When you get to the point where you're playing code golf, it becomes absolutely unreadable.

+ +

But also, there's a point where sometimes using some other heuristics will result in longer code but actually make it more readable on the whole. And so, packing everything into one method might be overall shorter, so it's fewer lines to read going through a class. But maybe extracting some methods or doing that separating branching code from doing code might lead to an overall longer class but an also overall more readable one. So, I think there's probably a lot of caveats that go with that idea. Oftentimes, shorter can be more readable with, you know, two or three asterisks that maybe go a little bit more into the why that is the case.

+ +

STEPHANIE: Yeah. I like the contextualizing. That actually reminded me of a talk that I watched recently by Hillel Wayne. It's called Intro to Empirical Software Engineering. And he basically, like, does a deep dive into all these studies about software practices that we think are, quote, unquote, "good," like, as a community or as an industry. And it's like, well, like, how do we actually know? Like, show me the research, right?

+ +

And one of the studies that he included was trying to determine if using abbreviations for variable names or using the full words made the code easier to debug or not. And so, the main example that he was using was employee number as a variable, and the abbreviation was EMP num. And it turns out that there was no difference in how easy it was to debug. But the approach that each group that was studied differed.

+ +

So, the folks who had the full names, the full words for the variable names, were kind of using an approach of just scanning the code and being able to understand at a higher level the domain, right? Whereas the folks who were debugging with just abbreviations had to work at a bit of a lower level and, you know, or maybe using breakpoints and debugging the code that way.

+ +

And I thought that was really cool because, first of all, I think it kind of was trying to prove that, like, we don't actually know if one is better or not. But what is important and interesting to me is the idea that, like, you can choose the method that you like better or that works for you and the human side of it, right? The impact it has on our process.

+ +

JOËL: That's really cool. I'll have to go and watch that talk. Building this kind of context and nuance around a heuristic, though, takes a lot of time, takes experience. And part of the value of a heuristic is that we're collapsing down maybe our own experience or somebody else's experience into something that doesn't require you to necessarily do all that work upfront.

+ +

How do you feel about sharing and kind of targeting a lot of these heuristics to newer coders who are kind of trying to get better at their craft and looking for ways to improve without necessarily having to do, you know, five years of experience digging into a particular topic? Do you think heuristics are helpful, or do they maybe mislead?

+ +

STEPHANIE: I really value when they're presented as an opinion, as opposed to a true fact about code. [laughs] Because I really appreciate when someone is able to explain to me why they chose readability in this particular scenario or why they chose speed and performance. Or maybe they were making a trade-off between accessibility and, you know, something else. To just, like, tell someone, "Oh yeah, like, DRY code is better code," or to just tell someone that without the explanation with, like, offering them the opportunity to reflect themselves on, like, oh, like, where have I seen DRY code that was easier for me to read? That seems a little less helpful in terms of investing in their growth.

+ +

JOËL: Yeah. Definitely, I think sharing some of the purpose behind it can often be really useful because most of these heuristics are never an end unto themselves. They're a means to some other end. So, you're not writing code that's DRY just because you want to be cool. You're writing code to be DRY because you're trying to improve readability, make it easier to change so you don't have to change it in multiple places. You want to maybe reduce the chance of certain types of bugs.

+ +

These are all actual purposes of what you want to do in your code. DRY is just one way of getting there. But oftentimes, we might skip that part and just be like, hey, you should make your code DRY because DRY is the best. And it can be, but it's in service to these other goals.

+ +

STEPHANIE: I think when I am sharing those types of heuristics that are more commonly held, I also do like to preface, like, some people think this, or some people like to do things this way, just to be clear that they don't have to like it or do it. In general, I always prefer injecting more nuance [laughs] into the conversation. But yeah, like, it is a really personal process, I think, and figuring out, like, how any individual makes decisions about, like, all the code they're writing. You have to make a million [laughs] decisions every time you do it.

+ +

So, yes, like, those heuristics do provide a shortcut. And also, I think it's worth taking the time to think about if it's working, especially for the specific context that you're applying it, right? Because that also can change. And, I don't know, maybe I'm just skeptical of any one size fits all solution.

+ +

JOËL: I think for myself, with many heuristics, as a beginner coder, I had a bit of, like, a spiral journey, or maybe kind of going up a set of stairs. So, as a brand-new developer, I would make a lot of duplication bugs in my code, where, you know, I would have the same value in multiple places, and then I'd change it in one place, and I don't remember to change it in other places, and the code breaks.

+ +

And so, being introduced to the idea of DRY actually helped my code get quite a bit better. It was, like, a net positive on my experience because I was not getting burned by all these bugs quite so frequently. And so, for a while, just throwing more DRY into my code just made my life better. And then, eventually, you kind of hit that plateau where I don't run into the pain of these bugs anymore. But now I keep doing more DRY somewhat mindlessly. And I end up with this pile of abstractions that are actually really brittle or frustrating to work with. And now, I have to rethink some of the assumptions behind the heuristic.

+ +

And then, at that point, yep, maybe recontextualize a little bit, learn about when it's good, when are the trade-offs not worth it. Now I have a better understanding, and I kind of go on another growth bit where it makes a lot of my code better until maybe I hit another plateau. I've kind of maxed out the benefits. I start seeing some of the pain, and then, again, I have to go through this cycle again. And maybe the approach you were talking about earlier, where you do a side project and kind of push a heuristic to its breaking point, is a way to kind of speed run that process.

+ +

STEPHANIE: Yeah, that's really interesting because you're just committing to it and trying to learn everything you can from it in a very concentrated setting. I also wonder, and it's totally fine if you don't know, but if someone had told you kind of all of those reasons you listed about why DRY code, like, what that achieves, if that may have reframed how you were thinking about applying it. Or was that also something that had to come from doing it enough?

+ +

JOËL: I think as a brand-new developer, a lot of that would have gone over my head. I was still really shaky on the concept of abstraction. When is it useful? When is it not? So, a lot of those more subtle pitfalls, I think, would not have been relevant to me at that point in my career, even the concept of readability, right? When I'm a brand-new programmer, I'm still getting used to reading a lot of code.

+ +

And so, the idea that code might be written in a way that's unreadable or more challenging to read, it might just feel like, oh, I just need to get better, improve myself. It's not that the code is written in a hard-to-read way. It's just I don't have enough experience at reading code. And I think that's a common thing that we do as beginners at everything, right? We start by blaming ourselves when things get hard.

+ +

STEPHANIE: Yeah. I was just thinking that, you know, if you are sharing heuristics with a newer developer or an early-career developer, at the end of the day, like, really, I'm not sure about the value of just dropping it on them and letting them run [laughs] with it. But I think what could be really, really effective is just having a sustained relationship with them and, like, continuing that conversation. It's, like, maybe in a code review or in a pairing session being like, "Oh yeah, like, I see you're practicing DRY. Like, what do you think about how this made this piece of code different?" And kind of baking in that process of self-discovery along the way and speeding it up in that way as well.

+ +

JOËL: So, what you're really saying is the one heuristic to rule them all is code in community.

+ +

STEPHANIE: I love that. I'm totally with you.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+9rMLndh3 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 397: Dependency Graphs + https://bikeshed.thoughtbot.com/397 + f067fa7d-0ad6-42d7-9f38-3c2ba66cedea + Tue, 15 Aug 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie is consciously trying to make meetings better for herself by limiting distractions. A few episodes ago, Joël talked about a frustrating bug he was chasing down and couldn't get closure on, so he had to move on. This week, that bug popped up again and he chased it down! AND he got to use binary search to find its source–which was pretty cool! + +Together, Stephanie and Joël discuss dependency graphs as a mental model, and while they apply to code, they also help when it comes to planning tasks and systems. They talk about coupling, cycles, re-structuring, and visualizations. + 42:53 + no + + + Stephanie is consciously trying to make meetings better for herself by limiting distractions. A few episodes ago, Joël talked about a frustrating bug he was chasing down and couldn't get closure on, so he had to move on. This week, that bug popped up again and he chased it down! AND he got to use binary search to find its source–which was pretty cool! +Together, Stephanie and Joël discuss dependency graphs as a mental model, and while they apply to code, they also help when it comes to planning tasks and systems. They talk about coupling, cycles, re-structuring, and visualizations. +Ruby Graph Library (https://github.com/monora/rgl) +Graphviz (https://graphviz.org/) +Using a Dependency Graph to Visualize RSpec let (https://thoughtbot.com/blog/using-a-dependency-graph-to-visualize-rspec-let) +Mermaid.js (https://mermaid.js.org/) +Strangler Fig pattern (https://martinfowler.com/bliki/StranglerFigApplication.html) +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, I'm always trying to make meetings better for me [chuckles], more tolerable or more enjoyable. And in meetings a lot, I find myself getting distracted when I don't necessarily want to be. You know, oftentimes, I really do want to try to pay attention to just what I'm doing in that meeting in the moment. In fact, just now, I was thinking about the little tidbit I had shared on a previous episode about priorities, where really, you know, you can only have one priority [laughs] at a time. And so, in that moment, hopefully, my priority is the meeting that I'm in. +But, you know, I find myself, like, accidentally opening Slack or, like, oh, was I running the test suite just a few minutes before the meeting started? Let me just go check on that really quick. And, oh no, there's a failure, oh God, that red is really, you know, drawing my eye. And, like, could I just debug it really quick and get that satisfying green so then I can pay attention to the meeting? And so on and so forth. I'm sure I'm not alone in this [laughs]. And I end up not giving the meeting my full attention, even though I want to be, even though I should be. +So, one thing that I started doing about a year ago is origami. [laughs] And that ended up being a thing that I would do with my hands during meetings so that I wasn't using my mouse, using my keyboard, and just, like, looking at other stuff in the remote meeting world that I live in. So, I started with paper stars, made many, many paper stars, [laughs] and then, I graduated to paper cranes. [laughs] And so, that's been my origami craft of choice lately. +Then now, I have little cranes everywhere around the house. I've kind of created a little paper crane army. [laughs] And my partner has enjoyed putting them in random places around the house for me [laughs] to find. So, maybe I'll open a cabinet, and suddenly, [laughs] a paper crane is just there. And I think I realized that I've actually gotten quite good at doing these crafts. +And it's been interesting to kind of be putting in the hours of doing this craft but also not be investing time, like, outside of meetings. And I'm finding that I'm getting better at this thing, so that seemed pretty cool. And it is mindless enough that I'm mentally just paying attention but, yeah, like, building that muscle memory to perfecting the craft of origami. +JOËL: I'm curious, for your army of paper cranes, is there a standard size that you make, or do you have, like, a variety of sizes? +STEPHANIE: I have this huge stack of, like, 500 sheets of origami paper that are all the same size. So, they're all about, let's say, two or three inches large. But I think the tiny ones I've seen, really small paper cranes, maybe that would be, like, the next level to tackle because working with smaller paper seems, you know, even more challenging. +JOËL: I'd imagine the ratio of, like, paper thickness to the size of the thing that you're making is different. +STEPHANIE: At this point, they say that if you make 1,000, then you bring good luck. I think I'm well on my way [laughs] to hopefully being blessed with good luck in this household of my little paper crane army. +JOËL: It's interesting that you mentioned the power of having something tactile to do with your hands during a meeting, and I definitely relate to that. I feel like it's so easy, even, like, mindlessly, to just hit Command-Tab when I'm doing things on a screen. Like, my hands are on the keyboard. If I'm not doing something, I'm just going to mindlessly hit Command-Tab. It's kind of like on your phone sometimes. I don't know if you do this, like, just scrolling side to side. You're not actually doing anything. You just want motion with your fingers. +STEPHANIE: Yes. I know exactly what you're talking about. And it's funny because it's a bit of a duality where, you know, when you are in your development workflow, you want things to be as quick and convenient as possible, so that Command-Tab, you know, is very easy. It's just built in, and that helps speed up your, you know, day-to-day work. But then it's also that little bit of mindlessness, I think, that can get you down the distraction path. +When I was first looking for something to do with my hands, to have, like, a little tactile thing to keep me focused in meetings, I did explore getting one of those fidget cubes; I have to say. [laughs] It's just a little toy, you know, that comes with a bunch of different settings for you to fidget with. +There's, like, a ball you can roll, you know, with your thumb, or maybe some buttons to click, and it gives you that really satisfying tactile experience. And I know they work really well for a lot of people, but I've really enjoyed the, I guess, the unexpected benefits [chuckles] of getting better at a hobby [laughs] while spending my time at my work. +Joël, what is new with you? +JOËL: So, a few episodes ago, I talked about a really kind of frustrating bug that I was chasing down that was due to some, like, non-determinism in the environment. And it kind of came, and then it went away. And I wasn't able to get sort of closure on that and had to move on. Well, this week, that bug popped up again, and this time, I was actually able to chase it down. So, that felt really exciting. And I got to use binary search to try to find the source of it, which made me feel really cool. +STEPHANIE: Oooh, do tell. What ended up being the issue? +JOËL: I'm connecting to an external Snowflake data warehouse, and ActiveRecord tries to fetch the schema and crashes as part of that with some cryptic error that originates from the C extension ODBC Ruby driver package. I figured out that it's probably something to do with, like, a particular table name or something in the table metadata when we're pulling this schema that we're not happy about. But I don't know which table is the one that it's not happy with. +Well, this time, I was able to figure out, by reading through some of the documentation, that I can pull subsets of the schema. So, I can pull the first n values of that schema, and it won't crash. It only crashes if I try to fetch the entire set, which is what is happening under the hood. At that point, you know, I could fetch each row individually, but there's hundreds of these. So, you know, I try, okay, what happens if I try to fetch 1,000 of these? Is it going to crash? Because it's a massive system. So, yes, I get a crash. +So, I know that a table less than a thousandth in the list of tables is what's causing the problems. So, okay, fetch 500 halfway in between there. It's still going to crash. Okay, 250, 125. I then kind of keep halving all the time until I find one that doesn't crash. And now I know that it is somewhere between the last crash and this one. So, I think it was between 125 and 250. And now I can say, okay, well, let's fetch the first, you know, maybe 200 tables, okay, that crashes. And I keep halving that space until you finally find it. And then, like, okay, so it's this one right here. +Now, the problem is the bad table actually crashes. So, I think it ended up being, like, number 175 or something like that. So, I never get to see the actual table itself. But because the list of tables is in alphabetical order, and I can see because I can fetch the first 174 and it succeeds, so I can tell what the previous 5, 6, you know, previous 174 are. +I can pretty easily go and look at the actual database and the list of tables and say, okay, well, it's in the same order. And the next one is this one, and hey, look, there is some metadata there that has some very long fields that are longer than one might expect, specifically going over a potentially implied 256-character limit. That seems somewhat suspicious. And, oh, if we remove this table, all of a sudden, everything works. +STEPHANIE: Wow, binary search, an excellent debugging tool [laughs] when you have no idea, you know, what could possibly be causing your issue. +JOËL: It's such a cool tool. Like, I'm always so happy when I get a chance to use it. The problem is, you need a way to be able to answer the question, like, have I found it? Yes or no? Or, generally, is it greater or less than this current position? +STEPHANIE: Well, that's really exciting that you ended up figuring out how to solve the bug. I know last time we talked about it, you kind of had left off in a space of, hopefully, we won't run into this issue again because it's no longer happening. But it seems like you were also set up this time around to be able to debug once it cropped up again. +JOËL: Yes. So, binary search is really cool. It's got this, like, very, like, fancy computer science name. But in reality, it's a fairly simple, straightforward technique that I use fairly frequently in my development. And there's another kind of computer sciency fancy-sounding concept that I use all the time. You've all heard me reference this multiple times on the show. You're right; we're finally doing it. This is the dependency graph episode. +STEPHANIE: Woo. [laughter] It's time. I'm excited to really dig into it because, you know, as someone who has heard you talk about it a lot, you know, and is maybe a little less familiar with graph theory and how, you know, it can be applied to my day to day work, I'm really excited to dig into a little bit about, you know, what a regular developer needs to know about dependency graphs to add to their toolbox of skills. +JOËL: So, I think at its core, the idea of a dependency graph is that you have a group of entities, some of which depend on each other. They can't do a task, or they can't be created unless some other subtasks or dependent actions take place. And so, we have a sort of formal structural way of describing these things. Visually, we often draw these things out where each of the pieces is like a little bubble or a circle, and then we draw arrows towards the things that it depends on. +So, if A cannot be done without B being done first, we draw an arrow from A to B. That's kind of how it is in the abstract. More concretely, this kind of thing shows up constantly throughout the work that we do because a lot of what we do as developers is managing things that are connected to each other or that depend on each other. We build complex systems out of smaller components that all rely on each other. +STEPHANIE: Yeah, I think it's interesting because I use the word dependency, you know, very frequently when talking about normal work that I'm doing, you know, dependencies as in libraries, right? That we've pulled into our application, or dependencies, like, talking about other classes that are referenced in this class that I'm working in. And I never really thought about what could be explored further or, like, what could be learned from really digging into those connections. +JOËL: It's a really powerful mental model. And, like you said, dependencies exist all over our work, and we often use that word. So, you mentioned something like packages, where your application depends on Rails, which in turn depends on ActiveRecord, which in turn depends on a bunch of other things. And so, you've got this whole chain of maybe immediate dependencies, and then those dependencies have dependencies, and those dependencies have dependencies, and it kind of, like, grows outward from there. +And in a very kind of simplistic model, you might think, oh, well, it's more, like, a kind of a tree structure. But oftentimes, you'll have things like branches on one side that connect back to branches on the other. And now you've got something that's no longer really tree-like. It's more of a sort of interconnected web, and that is a graph. +STEPHANIE: I think understanding the dependencies of your system has also become more important to me as I learn about things that can go wrong when I don't know enough about what my system is, you know, relying on that I had kind of taken for granted previously. I'm especially thinking about packages like we were mentioning, and, you know, not realizing that your application is dependent on this other library, right? That's brought in by a gem that you're using. And there's maybe, like, a security issue, right? With that. +And suddenly, you have this problem on your hands that you didn't realize before. And I know that that has been more of a common discussion now in terms of security practices, just being more aware of all the things that you are depending on as really our work becomes more and more interconnected with the things available to us with open source. +JOËL: I think where understanding the graph-like nature of this becomes really important is when you're doing something like an upgrade. So, let's say you do have a gem that has a security problem, and you want to upgrade it to fix that security issue. But the upgrade that includes the security patch is also a breaking upgrade. And so, now everything else in your system that depends on that gem or on that package is going to break unless you have them in a version that is compatible with the new version of that gem. +And so, you might have to then go downstream and upgrade those packages in a way that's compatible with your app before you can bring in the security patch. And a lot of that can be done automatically by Bundler. Bundler is software that is built around navigating dependency graphs like that and finding versions that are compatible with each other. +But sometimes, your code will need to change in order to upgrade one of these downstream gems so that you can then pull in the upgrade from the gem that needs a security patch. And so, understanding a little bit of that graph is going to be important to safely upgrading that gem. +STEPHANIE: So, I know another application of dependency graphs that you have thought about and written a blog post for is RSpec let declarations and how a lot of the time when we are using let, you know, we are likely calling other variables defined by let. And so, when you are encountering a test file, it can be really hard to grok what data is being set up in your test. +JOËL: Yeah, so that is really interesting because you can define something that will get executed in a lazy fashion if it gets referenced. But then not only is the let lazy and will not trigger unless it's referenced, but a let can reference other lets, which are also lazy, and only get triggered if they get referenced. +So, you might have a bunch of lets defined in any order you want throughout a file, and they're all kind of interconnected with these references to each other. But they only get triggered if something calls it directly or it's in this, like, chain of dependencies. And getting a grasp on what actually gets created, which lets will actually execute, which ones don't in a file can quickly get out of hand. And so, thinking of this in terms of a dependency graph has been a really helpful mental model for me to understand what's going on in a complex test file. +STEPHANIE: Yeah, absolutely. Especially when sometimes the lets are coming from all over the place, you know, maybe a describe block hundreds of lines away, or even a completely different file if you are using a shared context that's being pulled in. So, I can see why this was a complex problem that could be made a little simpler with plotting out a dependency graph. +And in preparation for this episode, I was doing a little bit of my own exploration on this because I certainly know, you know, the pain of trying to figure out what is being executed in my tests when there are a lot of lets that reference each other. And in the blog post, you kind of gave a little step-by-step of how you could start with creating a dependency graph for the test that you're working with. +And I was really curious if this process could be automated because, you know, I do enjoy, you know, pulling out the pen and paper [chuckles] every now and then. But I'm not, like, a particularly visual person. God forbid I, like, draw a circle, but then, like, don't have enough space for the rest of the circles. [laughs] So, I was really hoping for a tool that could do this for me, especially if, you know, you do, you have a lot of tests that you have to try to understand in a relatively short amount of time. And so, I ended up doing something kind of hacky with RSpec and overriding let definitions to automate this process. +JOËL: That's really cool. So, is the tool that you're trying to build something where you feed it in a spec file, and it gives you some kind of graphical representation like an SVG or something as output? +STEPHANIE: Yeah. I did consider that approach first, where you feed in the file, but then I ended up going with something more dynamic where you are running the test, and then as it gets executed, tracing the let definitions and then registering them to build your dependency graph. +JOËL: So, you've got some sort of internal modeling that describes a dependency graph. And then, somehow, you're going to turn that, you know, a series of Ruby objects into some kind of visual. +STEPHANIE: Yeah, exactly. And the bulk of that work was actually done with a library called RGL, which stands for just Ruby Graph Library. [laughs] And what's nice is that it has a really easy interface for plugging in the vertices and edges of the dependency graph that you want to build. And then, it is already hooked up with Graphviz to, you know, write the SVG to a file. And so, I ended up really just having to build up an array of my dependencies and the connections to each other and then feed it into the constructor of the graph. +JOËL: And for all of our listeners, you mentioned Graphviz. That is a third-party tool that can be installed on your machine that can generate these SVG diagrams from...I believe it has its own sort of syntax. So, you create, I believe it's dot, D-O-T, so dot dot file. And based off of that, it generates all sorts of things, but SVG being potentially one of them. +STEPHANIE: Yeah. The nice thing was that I actually didn't end up having to use the DSL of Graphviz because the RGL gem was doing them for me. +JOËL: Nice. So, it plugs in directly. +STEPHANIE: Yeah, exactly. And I was really curious about using this gem because I, you know, just wanted to write Ruby, especially to plug into other things that are already in Ruby. And I found that surprisingly easy, thanks to all of the RSpec config options that they make available to you, including an option to extend the example group class, which is actually where let and let bang is defined. +And so, I ended up overriding those classes and using, you know, the name of the let that you're defining and then the block to basically register the dependencies. And I also ended up exploring a little bit with using Ruby's built-in parser to figure out in the block that's being passed to the let, what parts of that block could potentially be a reference to another let. +JOËL: That's really cool. Did you get any fun results from that? +STEPHANIE: I did. It worked pretty well in being able to capture all of the let declarations, and other lets that it references. And so, I was able to successfully, you know, like, generate a visual dependency graph of all of the lets, so that was really neat. +The part that I was really kind of excited about trying next, though I didn't end up having time to yet, was figuring out which of those let values are executed by way of the let bang, right? Which is eager or what is referenced in the test that then gets executed as well. And so, the RGL library is pretty neat and has some formatting options, too, with the Graphviz output. So, you can change the font color or styling options for different, you know, nodes and edges. And so, I was really curious to pursue this further, maybe, and use it to show exactly what gets evaluated now that I have successfully mapped my let graph. +JOËL: Right. Because the whole point of this exercise is that not the entire graph is going to get evaluated. The underlying question is, what data actually gets created when my test runs? And so, you build out this whole dependency graph, and then you can follow a few simple rules to say, okay, this branch gets called, this branch gets called, this series of things gets called. And okay, this subset of let blocks trigger, and therefore this data has been created for my given test. +STEPHANIE: Yeah. Though I will say that even where I got so far to, just seeing all of the let definitions in a spec file was really helpful to have a better understanding, you know, if I do have to add a test in here, and I'm thinking about reaching for a pre-existing let declaration, to be like, oh, like, it actually, you know, goes on to reference all of these other things that may be factories [chuckles] that are created might make me, you know, think twice, or just have a little better understanding of what I'm really dealing with. +JOËL: Right. The idea that when you're calling out to a let, or a factory, or something else that's just a node in a large graph, you're not necessarily referencing just one thing. You might actually be referencing the head of a very long chain of things that maybe you don't intend to trigger the whole thing. +STEPHANIE: Yeah, exactly. +JOËL: So, in that sense, having a sort of visual or at least an idea of the graph can give you a much better sense of the cost of certain operations that you might have to do. +STEPHANIE: The cost of the operations certainly, especially when, you know, you are working in a legacy codebase, and you, you know, like, maybe don't know how everything plays together or is connected. And it's very tempting to just reach for [chuckles] the things that have been, you know, created or built for you. And I'm certainly guilty of that sometimes on this client project, where the domain is so complex, and there are so many associated models. +And I'm like, well, like, let me just, you know, use this let that already, you know, has a factory set up for what I think I need for this test. But then realizing, oh, actually, like, it is creating all these things, and do I really need them? I think it can be really challenging to unravel all of that in your head. And so, with this very scrappy tool that I [chuckles] built for my own purposes, you know, maybe it makes it, like, one step easier to try to fully understand what I'm working with and maybe do something different. +JOËL: One aspect that I think is really powerful about dependency graphs is that it takes this kind of, like, abstract concept that we oftentimes have an intuitive sense around, the idea that we have different components that depend on each other, and it shows it to us visually on, like, a 2D plane. And that can be really helpful to get an understanding or an overview of a system. +You mentioned that RGL uses Graphviz to generate some SVGs. A visual tool that I've been using to draw some of my dependency graphs has been mermaid.js. It has a syntax that's, like, a text-based syntax, but it's almost visual in that you have a piece of text and name of a node. And then, you'll draw a little ASCII arrow, you know, two dashes and a greater than sign to say this thing depends on, and then write another name, and just have a row, like, a bunch of entries to say; A depends on B. A also depends on C. C depends on D, and so on, and, like, build up that list. And then Mermaid will just generate that diagram for you. +STEPHANIE: Yeah. I've used Mermaid a few times. One really helpful use that I had for it was diagramming out a bunch of React components that I had and wanting to understand the connections between them. And I think you can even paste the Mermaid syntax into your GitHub pull request description, and it'll render as the graph image. +JOËL: Yeah, that's what's really cool is that Mermaid syntax has become embedded in a lot of other places in the past few years. So, it's really easy to embed graphs now into all sorts of things. You mentioned GitHub. It works in pull requests descriptions, comments, I think pretty much anywhere that Markdown is accepted. So, you could put one in your README if you wanted. +Another place that I use a lot, Obsidian, my note-taking tool, allows me to embed graphs directly in there, which is really much nicer than previously; sometimes, when I wanted to express something as a visual, I would use some sort of drawing tool to do something and export an image, and then embed that in my note. But now I can just put in this text, and it will automatically render that as a diagram. +And part of what's really nice about that is that then it's really easy for me to go and change that if I'm like, oh, but actually, I want to add one more connection in here. I don't have to re go back to, hopefully, a file that I've saved somewhere and, like, change an image file and re-export it. I just, you know, I add one line of text to my note, and it just works. +STEPHANIE: That's awesome. Yeah, the ability to change it seems really useful. +So, we've talked a little bit about tools for creating a visual aid for understanding our dependencies. And now that we have our graph, maybe we might have some concerning observations about what we see, especially when perhaps some of our dependencies are pointing back to each other. +JOËL: Yes. So, I think you're referencing cycles, in particular. That would be the formal term for it. And those are really interesting. They happen in dependency graphs. And I would say, in many cases, they can be a bit of a smell. There's definitely situations where they're fine. But there are things that you look at, and you're like, okay, this is going to be a more complex kind of tricky bit of the graph to work with. +Some cases, you just straight up can't have them. So, I want to say that the way RSpec lets are set up, you cannot write code that produces cycles. But you might have...I think Ruby allows classes to reference each other in such a way that it creates a cycle, and not all languages do that. So, Elm and F#, I believe, require that modules cannot reference each other. The fancy term for this is a dependent acyclic graph, or DAG, which basically just means that there are no cycles in that graph. +STEPHANIE: Yeah. What you said about classes referencing each other is very interesting because I've definitely seen that. And then, if I have to go about changing something, maybe even it's just the class name, right? Now there's no way in which I can really make just one change. I have to kind of do it all in one go. +JOËL: I think that's a common property of a cycle, and a graph is that changes that happen somewhere in that cycle often need to be all shipped together as one piece. You can't break it up into smaller chunks because everything depends on everything else. So, it has to be kind of boxed together and shipped as one thing. +STEPHANIE: And you'd mentioned that cycles, you know, can be a bit of a code smell. And if the goal is to be able to break it up so that it is a little bit more manageable to work with, how would you go about breaking a cycle? +JOËL: So, I think breaking a cycle is going to vary a little bit based on your problem domain. So, are you modeling a series of classes that are referencing each other? Is this a function call graph? Is this even, like, a series of tasks that you're trying to do? But typically, what you want to do is make sure that eventually, at some point, like, something doesn't loop back to referencing something higher up in your hierarchy. And so, oftentimes, it ends up being about what is allowed to know about what? Do you have higher-level concepts that can know and depend on lower-level concepts but not vice versa? +And again, we are talking about this a little bit at the abstract level. But in terms of, let's say, different code modules, or classes, or something like that, commonly, you might say, well, we want some sort of layering where we have almost, like, more primitive types of classes at the bottom. And they don't get to know about anything above them. But the ones above that might be more complex that are composed of smaller pieces know about the ones below them. And you might have multiple layers kind of like that that all kind of point down, but nothing points up. +STEPHANIE: That is a very common heuristic. [chuckles] I think you were basically just describing how I also understand creating React components, where you want to separate your presentational ones from your functional ones. And, yeah, it makes a lot of sense that as soon as you start adding that complexity of, you know, those primitive classes at the bottom, starting to, you know, point to things higher up or to know about things higher up, that is where a cycle may be accidentally introduced. +JOËL: It's interesting just how many design principles that we have in software. If you dig into them a little bit, you find out that they're about decoupling things, and oftentimes, it's specifically breaking up cycles. So, one way that you might have something like this that actually has dependency in the name, the dependency inversion principle, where what you're effectively doing is you're taking one of those dependency arrows, and you're flipping it the other way. So, instead of A depending on B, you're flipping it. Now B depends on A, and that can be enough to break a cycle. +STEPHANIE: So, one thing I've picked up from our conversations about dependency graphs is that oftentimes, you know, when you're trying to figure out where to start, you want to look for those areas or those nodes where there's nothing else that depends on it. +JOËL: Yeah. I think you have those nodes that, if this were a tree, you would call them the leaf nodes. In the case of a graph, I'm not sure if that's technically correct, but they don't depend on anything. They're kind of your base case. And so, you can, you know, if it's a function, you can run it. If it's a file, you can load it; if it's a class, also you can load it up and not have to do anything else because it has no dependencies. And knowing that those are there, I think, can be really useful in terms of knowing an order you might want to execute something in. And this is really interesting for one of my favorite uses of a graph, which is breaking down a series of tasks that you need to do. +So, commonly, you might say, okay, I have a large task I need to do. I break it down into a series of subtasks. And, you know, maybe I draw out, like, a bulleted list and, you know, task 1, 2, 3, 4, 5. The problem is that they're not necessarily just a flat list. They all have, like, orders, like dependencies between each other. So, maybe one has to happen before 2, but it also has to happen before 3, which needs to happen before two, and, like, there's all these interconnections. +And then, you find out that you can't ship them independently the way you thought initially. So, by building up a graph, you end up with something that shows you exactly what depends on what. And then, like you said, the parts that are really interesting where you can start doing work are the ones that have no dependencies themselves. Other things might depend on them, but they have no dependencies. Therefore, they can be safely built, shipped, deployed to production, and they can be done independently of the other subtasks. +STEPHANIE: Yeah. I was also thinking about things that could be done in parallel as well. So, if you do have multiple of those items with no dependencies, like, that is a really good way to be able to break up that work and, yeah, identify things that are not blocked. +JOËL: For a complex set of tasks, it's great to see, okay, these two pieces have no dependencies. We can have them be done in parallel, shipped independently. And then you can just kind of keep repeating that process. Because once all of the tasks that have no dependencies have been done, well, you can almost, like, remove them from the graph and see, okay, what's the new set of things that have no dependencies? And then, keep doing that until you've eventually done the whole graph. +And that may sound like, oh okay, we're just kind of using a little bit of intuition and working through the graph. It turns out that this is a, like, actual, like, formal thing. When it comes to graphs, it's a traversal algorithm called topological sort is the fancy name for it, and it basically, yeah, it goes through that. It gives you a list of nodes in order where each node that you're given has no dependencies that have not been evaluated yet. +So, it works from effectively to use our tree terminology, from the leaf nodes to the root, potentially roots plural, of the graph, and each step is independent. So that's a lot of, like, fancy terminology, and getting a little bit of, like, computer science graph theory into here. +So, my, like, general heuristic is that graphs should be evaluated from the bottom up when you're trying to evaluate each piece independently. So, when you do that, you get to do each piece independently, as opposed to if you're evaluating from the top down. So, starting from the one thing that depends on everything else, well, it can't be shipped until all of its dependencies have been shipped. +And all the transitional dependencies can't be shipped until their dependencies have been shipped. And so, you end up being not able to ship anything until you've built the entire graph. And that's when you end up with, you know, a 2,000-line PR that took you multiple weeks and might be buggy. And it's going to take a long time to review. And it's just not what anybody wants. +STEPHANIE: I'm glad you brought this up because I think this is where I am really curious to get better at because oftentimes, when I am breaking down a complex task, it's quite hard for me to see all of the steps that need to happen. And so, you know, you maybe start out with that, like, top-level node, like, the task that needs to be done as you understand it immediately. And it's really hard to actually identify the dependencies and, like, the smaller pieces along the way. And because you're not able to identify that, you think that you do have to just do it all in one go. +JOËL: Yeah, that sort of root node is typically the overarching task, the goal of what you want to do. And a common, I think, scenario for something like this would be, let's say, you're doing a Rails upgrade. And so, that root node is upgrade Rails. And a common thing that you might want to do is say, okay, let's go to the gem file, upgrade Rails, see what breaks, and then just keep fixing those things. That's working from the top down. +And you're going to be in a long-running branch, and you're going to keep fixing things, fixing things, fixing things until you have found all the things but done all the things. And then you do a big bang upgrade that may have taken you weeks. As opposed to if you're working from the bottom up, you try to figure out, okay, what are all the subtasks? And that might take some exploration. You might not know upfront. +But then you might say, okay, here, I can upgrade RSpec versus a dependency, or I need to change the interface of this class and ship all these pieces one at a time. And then, the final step is flipping that upgrade in the gem file, saying, okay, now I've upgraded Rails from 4 to 5, or whatever the version is that you're trying to do. +STEPHANIE: I think you've really hit the nail on the head when it comes to trying to do something but not knowing what subtasks may compose of it and getting into that problem of, you know, having not broken it down, like, enough to really see all the dependencies. +And, you know, maybe this is a conversation [chuckles] for another episode, but the skill of breaking up those tasks and exploring what those dependencies are, and being able to figure them out upfront before you start to just do that upgrade and then see what happens, that's definitely an area that I want to keep investing in. And I'm sure other people would be really curious about, too, to help them make their jobs easier. +JOËL: I think one tip that I've learned that's really fun and that connects into all of this is sometimes you do end up with a cycle in your dependencies of tasks. A technique for breaking that up is a pattern that I have pitched multiple times on the show: the strangler fig pattern. And part of why it's so powerful is that it allows you to work incrementally by breaking up some of these cycles in your dependency graph. +And one of the lessons that I've learned from that is that just because you have sort of an initial set of subtasks and you have a graph of them doesn't mean that you can't change them. If you're following strangler fig, what you're actually doing is introducing one or more new subtasks to that graph. But the way you introduce them breaks up that cycle. So, you can always add new tasks or split up existing ones as you get a better understanding of the work you need to do. It's not something that is fixed or set in stone upfront. +STEPHANIE: Yeah, that's a really great tip. I think next time, what I really want to explore, you know, your heuristic of going from bottom up, yeah, sure, it sounds all fine and dandy. But how to get to a point where you're able to see everything at the bottom, right? And, like, when you are tasked, or you do start with the thing at the top, like, the end goal. Yeah, I'm sure that's something we'll explore [chuckles] another day. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. +Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie is consciously trying to make meetings better for herself by limiting distractions. A few episodes ago, Joël talked about a frustrating bug he was chasing down and couldn't get closure on, so he had to move on. This week, that bug popped up again and he chased it down! AND he got to use binary search to find its source–which was pretty cool!

+ +

Together, Stephanie and Joël discuss dependency graphs as a mental model, and while they apply to code, they also help when it comes to planning tasks and systems. They talk about coupling, cycles, re-structuring, and visualizations.

+ +
+ + + +

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, I'm always trying to make meetings better for me [chuckles], more tolerable or more enjoyable. And in meetings a lot, I find myself getting distracted when I don't necessarily want to be. You know, oftentimes, I really do want to try to pay attention to just what I'm doing in that meeting in the moment. In fact, just now, I was thinking about the little tidbit I had shared on a previous episode about priorities, where really, you know, you can only have one priority [laughs] at a time. And so, in that moment, hopefully, my priority is the meeting that I'm in.

+ +

But, you know, I find myself, like, accidentally opening Slack or, like, oh, was I running the test suite just a few minutes before the meeting started? Let me just go check on that really quick. And, oh no, there's a failure, oh God, that red is really, you know, drawing my eye. And, like, could I just debug it really quick and get that satisfying green so then I can pay attention to the meeting? And so on and so forth. I'm sure I'm not alone in this [laughs]. And I end up not giving the meeting my full attention, even though I want to be, even though I should be.

+ +

So, one thing that I started doing about a year ago is origami. [laughs] And that ended up being a thing that I would do with my hands during meetings so that I wasn't using my mouse, using my keyboard, and just, like, looking at other stuff in the remote meeting world that I live in. So, I started with paper stars, made many, many paper stars, [laughs] and then, I graduated to paper cranes. [laughs] And so, that's been my origami craft of choice lately.

+ +

Then now, I have little cranes everywhere around the house. I've kind of created a little paper crane army. [laughs] And my partner has enjoyed putting them in random places around the house for me [laughs] to find. So, maybe I'll open a cabinet, and suddenly, [laughs] a paper crane is just there. And I think I realized that I've actually gotten quite good at doing these crafts.

+ +

And it's been interesting to kind of be putting in the hours of doing this craft but also not be investing time, like, outside of meetings. And I'm finding that I'm getting better at this thing, so that seemed pretty cool. And it is mindless enough that I'm mentally just paying attention but, yeah, like, building that muscle memory to perfecting the craft of origami.

+ +

JOËL: I'm curious, for your army of paper cranes, is there a standard size that you make, or do you have, like, a variety of sizes?

+ +

STEPHANIE: I have this huge stack of, like, 500 sheets of origami paper that are all the same size. So, they're all about, let's say, two or three inches large. But I think the tiny ones I've seen, really small paper cranes, maybe that would be, like, the next level to tackle because working with smaller paper seems, you know, even more challenging.

+ +

JOËL: I'd imagine the ratio of, like, paper thickness to the size of the thing that you're making is different.

+ +

STEPHANIE: At this point, they say that if you make 1,000, then you bring good luck. I think I'm well on my way [laughs] to hopefully being blessed with good luck in this household of my little paper crane army.

+ +

JOËL: It's interesting that you mentioned the power of having something tactile to do with your hands during a meeting, and I definitely relate to that. I feel like it's so easy, even, like, mindlessly, to just hit Command-Tab when I'm doing things on a screen. Like, my hands are on the keyboard. If I'm not doing something, I'm just going to mindlessly hit Command-Tab. It's kind of like on your phone sometimes. I don't know if you do this, like, just scrolling side to side. You're not actually doing anything. You just want motion with your fingers.

+ +

STEPHANIE: Yes. I know exactly what you're talking about. And it's funny because it's a bit of a duality where, you know, when you are in your development workflow, you want things to be as quick and convenient as possible, so that Command-Tab, you know, is very easy. It's just built in, and that helps speed up your, you know, day-to-day work. But then it's also that little bit of mindlessness, I think, that can get you down the distraction path.

+ +

When I was first looking for something to do with my hands, to have, like, a little tactile thing to keep me focused in meetings, I did explore getting one of those fidget cubes; I have to say. [laughs] It's just a little toy, you know, that comes with a bunch of different settings for you to fidget with.

+ +

There's, like, a ball you can roll, you know, with your thumb, or maybe some buttons to click, and it gives you that really satisfying tactile experience. And I know they work really well for a lot of people, but I've really enjoyed the, I guess, the unexpected benefits [chuckles] of getting better at a hobby [laughs] while spending my time at my work.

+ +

Joël, what is new with you?

+ +

JOËL: So, a few episodes ago, I talked about a really kind of frustrating bug that I was chasing down that was due to some, like, non-determinism in the environment. And it kind of came, and then it went away. And I wasn't able to get sort of closure on that and had to move on. Well, this week, that bug popped up again, and this time, I was actually able to chase it down. So, that felt really exciting. And I got to use binary search to try to find the source of it, which made me feel really cool.

+ +

STEPHANIE: Oooh, do tell. What ended up being the issue?

+ +

JOËL: I'm connecting to an external Snowflake data warehouse, and ActiveRecord tries to fetch the schema and crashes as part of that with some cryptic error that originates from the C extension ODBC Ruby driver package. I figured out that it's probably something to do with, like, a particular table name or something in the table metadata when we're pulling this schema that we're not happy about. But I don't know which table is the one that it's not happy with.

+ +

Well, this time, I was able to figure out, by reading through some of the documentation, that I can pull subsets of the schema. So, I can pull the first n values of that schema, and it won't crash. It only crashes if I try to fetch the entire set, which is what is happening under the hood. At that point, you know, I could fetch each row individually, but there's hundreds of these. So, you know, I try, okay, what happens if I try to fetch 1,000 of these? Is it going to crash? Because it's a massive system. So, yes, I get a crash.

+ +

So, I know that a table less than a thousandth in the list of tables is what's causing the problems. So, okay, fetch 500 halfway in between there. It's still going to crash. Okay, 250, 125. I then kind of keep halving all the time until I find one that doesn't crash. And now I know that it is somewhere between the last crash and this one. So, I think it was between 125 and 250. And now I can say, okay, well, let's fetch the first, you know, maybe 200 tables, okay, that crashes. And I keep halving that space until you finally find it. And then, like, okay, so it's this one right here.

+ +

Now, the problem is the bad table actually crashes. So, I think it ended up being, like, number 175 or something like that. So, I never get to see the actual table itself. But because the list of tables is in alphabetical order, and I can see because I can fetch the first 174 and it succeeds, so I can tell what the previous 5, 6, you know, previous 174 are.

+ +

I can pretty easily go and look at the actual database and the list of tables and say, okay, well, it's in the same order. And the next one is this one, and hey, look, there is some metadata there that has some very long fields that are longer than one might expect, specifically going over a potentially implied 256-character limit. That seems somewhat suspicious. And, oh, if we remove this table, all of a sudden, everything works.

+ +

STEPHANIE: Wow, binary search, an excellent debugging tool [laughs] when you have no idea, you know, what could possibly be causing your issue.

+ +

JOËL: It's such a cool tool. Like, I'm always so happy when I get a chance to use it. The problem is, you need a way to be able to answer the question, like, have I found it? Yes or no? Or, generally, is it greater or less than this current position?

+ +

STEPHANIE: Well, that's really exciting that you ended up figuring out how to solve the bug. I know last time we talked about it, you kind of had left off in a space of, hopefully, we won't run into this issue again because it's no longer happening. But it seems like you were also set up this time around to be able to debug once it cropped up again.

+ +

JOËL: Yes. So, binary search is really cool. It's got this, like, very, like, fancy computer science name. But in reality, it's a fairly simple, straightforward technique that I use fairly frequently in my development. And there's another kind of computer sciency fancy-sounding concept that I use all the time. You've all heard me reference this multiple times on the show. You're right; we're finally doing it. This is the dependency graph episode.

+ +

STEPHANIE: Woo. [laughter] It's time. I'm excited to really dig into it because, you know, as someone who has heard you talk about it a lot, you know, and is maybe a little less familiar with graph theory and how, you know, it can be applied to my day to day work, I'm really excited to dig into a little bit about, you know, what a regular developer needs to know about dependency graphs to add to their toolbox of skills.

+ +

JOËL: So, I think at its core, the idea of a dependency graph is that you have a group of entities, some of which depend on each other. They can't do a task, or they can't be created unless some other subtasks or dependent actions take place. And so, we have a sort of formal structural way of describing these things. Visually, we often draw these things out where each of the pieces is like a little bubble or a circle, and then we draw arrows towards the things that it depends on.

+ +

So, if A cannot be done without B being done first, we draw an arrow from A to B. That's kind of how it is in the abstract. More concretely, this kind of thing shows up constantly throughout the work that we do because a lot of what we do as developers is managing things that are connected to each other or that depend on each other. We build complex systems out of smaller components that all rely on each other.

+ +

STEPHANIE: Yeah, I think it's interesting because I use the word dependency, you know, very frequently when talking about normal work that I'm doing, you know, dependencies as in libraries, right? That we've pulled into our application, or dependencies, like, talking about other classes that are referenced in this class that I'm working in. And I never really thought about what could be explored further or, like, what could be learned from really digging into those connections.

+ +

JOËL: It's a really powerful mental model. And, like you said, dependencies exist all over our work, and we often use that word. So, you mentioned something like packages, where your application depends on Rails, which in turn depends on ActiveRecord, which in turn depends on a bunch of other things. And so, you've got this whole chain of maybe immediate dependencies, and then those dependencies have dependencies, and those dependencies have dependencies, and it kind of, like, grows outward from there.

+ +

And in a very kind of simplistic model, you might think, oh, well, it's more, like, a kind of a tree structure. But oftentimes, you'll have things like branches on one side that connect back to branches on the other. And now you've got something that's no longer really tree-like. It's more of a sort of interconnected web, and that is a graph.

+ +

STEPHANIE: I think understanding the dependencies of your system has also become more important to me as I learn about things that can go wrong when I don't know enough about what my system is, you know, relying on that I had kind of taken for granted previously. I'm especially thinking about packages like we were mentioning, and, you know, not realizing that your application is dependent on this other library, right? That's brought in by a gem that you're using. And there's maybe, like, a security issue, right? With that.

+ +

And suddenly, you have this problem on your hands that you didn't realize before. And I know that that has been more of a common discussion now in terms of security practices, just being more aware of all the things that you are depending on as really our work becomes more and more interconnected with the things available to us with open source.

+ +

JOËL: I think where understanding the graph-like nature of this becomes really important is when you're doing something like an upgrade. So, let's say you do have a gem that has a security problem, and you want to upgrade it to fix that security issue. But the upgrade that includes the security patch is also a breaking upgrade. And so, now everything else in your system that depends on that gem or on that package is going to break unless you have them in a version that is compatible with the new version of that gem.

+ +

And so, you might have to then go downstream and upgrade those packages in a way that's compatible with your app before you can bring in the security patch. And a lot of that can be done automatically by Bundler. Bundler is software that is built around navigating dependency graphs like that and finding versions that are compatible with each other.

+ +

But sometimes, your code will need to change in order to upgrade one of these downstream gems so that you can then pull in the upgrade from the gem that needs a security patch. And so, understanding a little bit of that graph is going to be important to safely upgrading that gem.

+ +

STEPHANIE: So, I know another application of dependency graphs that you have thought about and written a blog post for is RSpec let declarations and how a lot of the time when we are using let, you know, we are likely calling other variables defined by let. And so, when you are encountering a test file, it can be really hard to grok what data is being set up in your test.

+ +

JOËL: Yeah, so that is really interesting because you can define something that will get executed in a lazy fashion if it gets referenced. But then not only is the let lazy and will not trigger unless it's referenced, but a let can reference other lets, which are also lazy, and only get triggered if they get referenced.

+ +

So, you might have a bunch of lets defined in any order you want throughout a file, and they're all kind of interconnected with these references to each other. But they only get triggered if something calls it directly or it's in this, like, chain of dependencies. And getting a grasp on what actually gets created, which lets will actually execute, which ones don't in a file can quickly get out of hand. And so, thinking of this in terms of a dependency graph has been a really helpful mental model for me to understand what's going on in a complex test file.

+ +

STEPHANIE: Yeah, absolutely. Especially when sometimes the lets are coming from all over the place, you know, maybe a describe block hundreds of lines away, or even a completely different file if you are using a shared context that's being pulled in. So, I can see why this was a complex problem that could be made a little simpler with plotting out a dependency graph.

+ +

And in preparation for this episode, I was doing a little bit of my own exploration on this because I certainly know, you know, the pain of trying to figure out what is being executed in my tests when there are a lot of lets that reference each other. And in the blog post, you kind of gave a little step-by-step of how you could start with creating a dependency graph for the test that you're working with.

+ +

And I was really curious if this process could be automated because, you know, I do enjoy, you know, pulling out the pen and paper [chuckles] every now and then. But I'm not, like, a particularly visual person. God forbid I, like, draw a circle, but then, like, don't have enough space for the rest of the circles. [laughs] So, I was really hoping for a tool that could do this for me, especially if, you know, you do, you have a lot of tests that you have to try to understand in a relatively short amount of time. And so, I ended up doing something kind of hacky with RSpec and overriding let definitions to automate this process.

+ +

JOËL: That's really cool. So, is the tool that you're trying to build something where you feed it in a spec file, and it gives you some kind of graphical representation like an SVG or something as output?

+ +

STEPHANIE: Yeah. I did consider that approach first, where you feed in the file, but then I ended up going with something more dynamic where you are running the test, and then as it gets executed, tracing the let definitions and then registering them to build your dependency graph.

+ +

JOËL: So, you've got some sort of internal modeling that describes a dependency graph. And then, somehow, you're going to turn that, you know, a series of Ruby objects into some kind of visual.

+ +

STEPHANIE: Yeah, exactly. And the bulk of that work was actually done with a library called RGL, which stands for just Ruby Graph Library. [laughs] And what's nice is that it has a really easy interface for plugging in the vertices and edges of the dependency graph that you want to build. And then, it is already hooked up with Graphviz to, you know, write the SVG to a file. And so, I ended up really just having to build up an array of my dependencies and the connections to each other and then feed it into the constructor of the graph.

+ +

JOËL: And for all of our listeners, you mentioned Graphviz. That is a third-party tool that can be installed on your machine that can generate these SVG diagrams from...I believe it has its own sort of syntax. So, you create, I believe it's dot, D-O-T, so dot dot file. And based off of that, it generates all sorts of things, but SVG being potentially one of them.

+ +

STEPHANIE: Yeah. The nice thing was that I actually didn't end up having to use the DSL of Graphviz because the RGL gem was doing them for me.

+ +

JOËL: Nice. So, it plugs in directly.

+ +

STEPHANIE: Yeah, exactly. And I was really curious about using this gem because I, you know, just wanted to write Ruby, especially to plug into other things that are already in Ruby. And I found that surprisingly easy, thanks to all of the RSpec config options that they make available to you, including an option to extend the example group class, which is actually where let and let bang is defined.

+ +

And so, I ended up overriding those classes and using, you know, the name of the let that you're defining and then the block to basically register the dependencies. And I also ended up exploring a little bit with using Ruby's built-in parser to figure out in the block that's being passed to the let, what parts of that block could potentially be a reference to another let.

+ +

JOËL: That's really cool. Did you get any fun results from that?

+ +

STEPHANIE: I did. It worked pretty well in being able to capture all of the let declarations, and other lets that it references. And so, I was able to successfully, you know, like, generate a visual dependency graph of all of the lets, so that was really neat.

+ +

The part that I was really kind of excited about trying next, though I didn't end up having time to yet, was figuring out which of those let values are executed by way of the let bang, right? Which is eager or what is referenced in the test that then gets executed as well. And so, the RGL library is pretty neat and has some formatting options, too, with the Graphviz output. So, you can change the font color or styling options for different, you know, nodes and edges. And so, I was really curious to pursue this further, maybe, and use it to show exactly what gets evaluated now that I have successfully mapped my let graph.

+ +

JOËL: Right. Because the whole point of this exercise is that not the entire graph is going to get evaluated. The underlying question is, what data actually gets created when my test runs? And so, you build out this whole dependency graph, and then you can follow a few simple rules to say, okay, this branch gets called, this branch gets called, this series of things gets called. And okay, this subset of let blocks trigger, and therefore this data has been created for my given test.

+ +

STEPHANIE: Yeah. Though I will say that even where I got so far to, just seeing all of the let definitions in a spec file was really helpful to have a better understanding, you know, if I do have to add a test in here, and I'm thinking about reaching for a pre-existing let declaration, to be like, oh, like, it actually, you know, goes on to reference all of these other things that may be factories [chuckles] that are created might make me, you know, think twice, or just have a little better understanding of what I'm really dealing with.

+ +

JOËL: Right. The idea that when you're calling out to a let, or a factory, or something else that's just a node in a large graph, you're not necessarily referencing just one thing. You might actually be referencing the head of a very long chain of things that maybe you don't intend to trigger the whole thing.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: So, in that sense, having a sort of visual or at least an idea of the graph can give you a much better sense of the cost of certain operations that you might have to do.

+ +

STEPHANIE: The cost of the operations certainly, especially when, you know, you are working in a legacy codebase, and you, you know, like, maybe don't know how everything plays together or is connected. And it's very tempting to just reach for [chuckles] the things that have been, you know, created or built for you. And I'm certainly guilty of that sometimes on this client project, where the domain is so complex, and there are so many associated models.

+ +

And I'm like, well, like, let me just, you know, use this let that already, you know, has a factory set up for what I think I need for this test. But then realizing, oh, actually, like, it is creating all these things, and do I really need them? I think it can be really challenging to unravel all of that in your head. And so, with this very scrappy tool that I [chuckles] built for my own purposes, you know, maybe it makes it, like, one step easier to try to fully understand what I'm working with and maybe do something different.

+ +

JOËL: One aspect that I think is really powerful about dependency graphs is that it takes this kind of, like, abstract concept that we oftentimes have an intuitive sense around, the idea that we have different components that depend on each other, and it shows it to us visually on, like, a 2D plane. And that can be really helpful to get an understanding or an overview of a system.

+ +

You mentioned that RGL uses Graphviz to generate some SVGs. A visual tool that I've been using to draw some of my dependency graphs has been mermaid.js. It has a syntax that's, like, a text-based syntax, but it's almost visual in that you have a piece of text and name of a node. And then, you'll draw a little ASCII arrow, you know, two dashes and a greater than sign to say this thing depends on, and then write another name, and just have a row, like, a bunch of entries to say; A depends on B. A also depends on C. C depends on D, and so on, and, like, build up that list. And then Mermaid will just generate that diagram for you.

+ +

STEPHANIE: Yeah. I've used Mermaid a few times. One really helpful use that I had for it was diagramming out a bunch of React components that I had and wanting to understand the connections between them. And I think you can even paste the Mermaid syntax into your GitHub pull request description, and it'll render as the graph image.

+ +

JOËL: Yeah, that's what's really cool is that Mermaid syntax has become embedded in a lot of other places in the past few years. So, it's really easy to embed graphs now into all sorts of things. You mentioned GitHub. It works in pull requests descriptions, comments, I think pretty much anywhere that Markdown is accepted. So, you could put one in your README if you wanted.

+ +

Another place that I use a lot, Obsidian, my note-taking tool, allows me to embed graphs directly in there, which is really much nicer than previously; sometimes, when I wanted to express something as a visual, I would use some sort of drawing tool to do something and export an image, and then embed that in my note. But now I can just put in this text, and it will automatically render that as a diagram.

+ +

And part of what's really nice about that is that then it's really easy for me to go and change that if I'm like, oh, but actually, I want to add one more connection in here. I don't have to re go back to, hopefully, a file that I've saved somewhere and, like, change an image file and re-export it. I just, you know, I add one line of text to my note, and it just works.

+ +

STEPHANIE: That's awesome. Yeah, the ability to change it seems really useful.

+ +

So, we've talked a little bit about tools for creating a visual aid for understanding our dependencies. And now that we have our graph, maybe we might have some concerning observations about what we see, especially when perhaps some of our dependencies are pointing back to each other.

+ +

JOËL: Yes. So, I think you're referencing cycles, in particular. That would be the formal term for it. And those are really interesting. They happen in dependency graphs. And I would say, in many cases, they can be a bit of a smell. There's definitely situations where they're fine. But there are things that you look at, and you're like, okay, this is going to be a more complex kind of tricky bit of the graph to work with.

+ +

Some cases, you just straight up can't have them. So, I want to say that the way RSpec lets are set up, you cannot write code that produces cycles. But you might have...I think Ruby allows classes to reference each other in such a way that it creates a cycle, and not all languages do that. So, Elm and F#, I believe, require that modules cannot reference each other. The fancy term for this is a dependent acyclic graph, or DAG, which basically just means that there are no cycles in that graph.

+ +

STEPHANIE: Yeah. What you said about classes referencing each other is very interesting because I've definitely seen that. And then, if I have to go about changing something, maybe even it's just the class name, right? Now there's no way in which I can really make just one change. I have to kind of do it all in one go.

+ +

JOËL: I think that's a common property of a cycle, and a graph is that changes that happen somewhere in that cycle often need to be all shipped together as one piece. You can't break it up into smaller chunks because everything depends on everything else. So, it has to be kind of boxed together and shipped as one thing.

+ +

STEPHANIE: And you'd mentioned that cycles, you know, can be a bit of a code smell. And if the goal is to be able to break it up so that it is a little bit more manageable to work with, how would you go about breaking a cycle?

+ +

JOËL: So, I think breaking a cycle is going to vary a little bit based on your problem domain. So, are you modeling a series of classes that are referencing each other? Is this a function call graph? Is this even, like, a series of tasks that you're trying to do? But typically, what you want to do is make sure that eventually, at some point, like, something doesn't loop back to referencing something higher up in your hierarchy. And so, oftentimes, it ends up being about what is allowed to know about what? Do you have higher-level concepts that can know and depend on lower-level concepts but not vice versa?

+ +

And again, we are talking about this a little bit at the abstract level. But in terms of, let's say, different code modules, or classes, or something like that, commonly, you might say, well, we want some sort of layering where we have almost, like, more primitive types of classes at the bottom. And they don't get to know about anything above them. But the ones above that might be more complex that are composed of smaller pieces know about the ones below them. And you might have multiple layers kind of like that that all kind of point down, but nothing points up.

+ +

STEPHANIE: That is a very common heuristic. [chuckles] I think you were basically just describing how I also understand creating React components, where you want to separate your presentational ones from your functional ones. And, yeah, it makes a lot of sense that as soon as you start adding that complexity of, you know, those primitive classes at the bottom, starting to, you know, point to things higher up or to know about things higher up, that is where a cycle may be accidentally introduced.

+ +

JOËL: It's interesting just how many design principles that we have in software. If you dig into them a little bit, you find out that they're about decoupling things, and oftentimes, it's specifically breaking up cycles. So, one way that you might have something like this that actually has dependency in the name, the dependency inversion principle, where what you're effectively doing is you're taking one of those dependency arrows, and you're flipping it the other way. So, instead of A depending on B, you're flipping it. Now B depends on A, and that can be enough to break a cycle.

+ +

STEPHANIE: So, one thing I've picked up from our conversations about dependency graphs is that oftentimes, you know, when you're trying to figure out where to start, you want to look for those areas or those nodes where there's nothing else that depends on it.

+ +

JOËL: Yeah. I think you have those nodes that, if this were a tree, you would call them the leaf nodes. In the case of a graph, I'm not sure if that's technically correct, but they don't depend on anything. They're kind of your base case. And so, you can, you know, if it's a function, you can run it. If it's a file, you can load it; if it's a class, also you can load it up and not have to do anything else because it has no dependencies. And knowing that those are there, I think, can be really useful in terms of knowing an order you might want to execute something in. And this is really interesting for one of my favorite uses of a graph, which is breaking down a series of tasks that you need to do.

+ +

So, commonly, you might say, okay, I have a large task I need to do. I break it down into a series of subtasks. And, you know, maybe I draw out, like, a bulleted list and, you know, task 1, 2, 3, 4, 5. The problem is that they're not necessarily just a flat list. They all have, like, orders, like dependencies between each other. So, maybe one has to happen before 2, but it also has to happen before 3, which needs to happen before two, and, like, there's all these interconnections.

+ +

And then, you find out that you can't ship them independently the way you thought initially. So, by building up a graph, you end up with something that shows you exactly what depends on what. And then, like you said, the parts that are really interesting where you can start doing work are the ones that have no dependencies themselves. Other things might depend on them, but they have no dependencies. Therefore, they can be safely built, shipped, deployed to production, and they can be done independently of the other subtasks.

+ +

STEPHANIE: Yeah. I was also thinking about things that could be done in parallel as well. So, if you do have multiple of those items with no dependencies, like, that is a really good way to be able to break up that work and, yeah, identify things that are not blocked.

+ +

JOËL: For a complex set of tasks, it's great to see, okay, these two pieces have no dependencies. We can have them be done in parallel, shipped independently. And then you can just kind of keep repeating that process. Because once all of the tasks that have no dependencies have been done, well, you can almost, like, remove them from the graph and see, okay, what's the new set of things that have no dependencies? And then, keep doing that until you've eventually done the whole graph.

+ +

And that may sound like, oh okay, we're just kind of using a little bit of intuition and working through the graph. It turns out that this is a, like, actual, like, formal thing. When it comes to graphs, it's a traversal algorithm called topological sort is the fancy name for it, and it basically, yeah, it goes through that. It gives you a list of nodes in order where each node that you're given has no dependencies that have not been evaluated yet.

+ +

So, it works from effectively to use our tree terminology, from the leaf nodes to the root, potentially roots plural, of the graph, and each step is independent. So that's a lot of, like, fancy terminology, and getting a little bit of, like, computer science graph theory into here.

+ +

So, my, like, general heuristic is that graphs should be evaluated from the bottom up when you're trying to evaluate each piece independently. So, when you do that, you get to do each piece independently, as opposed to if you're evaluating from the top down. So, starting from the one thing that depends on everything else, well, it can't be shipped until all of its dependencies have been shipped.

+ +

And all the transitional dependencies can't be shipped until their dependencies have been shipped. And so, you end up being not able to ship anything until you've built the entire graph. And that's when you end up with, you know, a 2,000-line PR that took you multiple weeks and might be buggy. And it's going to take a long time to review. And it's just not what anybody wants.

+ +

STEPHANIE: I'm glad you brought this up because I think this is where I am really curious to get better at because oftentimes, when I am breaking down a complex task, it's quite hard for me to see all of the steps that need to happen. And so, you know, you maybe start out with that, like, top-level node, like, the task that needs to be done as you understand it immediately. And it's really hard to actually identify the dependencies and, like, the smaller pieces along the way. And because you're not able to identify that, you think that you do have to just do it all in one go.

+ +

JOËL: Yeah, that sort of root node is typically the overarching task, the goal of what you want to do. And a common, I think, scenario for something like this would be, let's say, you're doing a Rails upgrade. And so, that root node is upgrade Rails. And a common thing that you might want to do is say, okay, let's go to the gem file, upgrade Rails, see what breaks, and then just keep fixing those things. That's working from the top down.

+ +

And you're going to be in a long-running branch, and you're going to keep fixing things, fixing things, fixing things until you have found all the things but done all the things. And then you do a big bang upgrade that may have taken you weeks. As opposed to if you're working from the bottom up, you try to figure out, okay, what are all the subtasks? And that might take some exploration. You might not know upfront.

+ +

But then you might say, okay, here, I can upgrade RSpec versus a dependency, or I need to change the interface of this class and ship all these pieces one at a time. And then, the final step is flipping that upgrade in the gem file, saying, okay, now I've upgraded Rails from 4 to 5, or whatever the version is that you're trying to do.

+ +

STEPHANIE: I think you've really hit the nail on the head when it comes to trying to do something but not knowing what subtasks may compose of it and getting into that problem of, you know, having not broken it down, like, enough to really see all the dependencies.

+ +

And, you know, maybe this is a conversation [chuckles] for another episode, but the skill of breaking up those tasks and exploring what those dependencies are, and being able to figure them out upfront before you start to just do that upgrade and then see what happens, that's definitely an area that I want to keep investing in. And I'm sure other people would be really curious about, too, to help them make their jobs easier.

+ +

JOËL: I think one tip that I've learned that's really fun and that connects into all of this is sometimes you do end up with a cycle in your dependencies of tasks. A technique for breaking that up is a pattern that I have pitched multiple times on the show: the strangler fig pattern. And part of why it's so powerful is that it allows you to work incrementally by breaking up some of these cycles in your dependency graph.

+ +

And one of the lessons that I've learned from that is that just because you have sort of an initial set of subtasks and you have a graph of them doesn't mean that you can't change them. If you're following strangler fig, what you're actually doing is introducing one or more new subtasks to that graph. But the way you introduce them breaks up that cycle. So, you can always add new tasks or split up existing ones as you get a better understanding of the work you need to do. It's not something that is fixed or set in stone upfront.

+ +

STEPHANIE: Yeah, that's a really great tip. I think next time, what I really want to explore, you know, your heuristic of going from bottom up, yeah, sure, it sounds all fine and dandy. But how to get to a point where you're able to see everything at the bottom, right? And, like, when you are tasked, or you do start with the thing at the top, like, the end goal. Yeah, I'm sure that's something we'll explore [chuckles] another day.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie is consciously trying to make meetings better for herself by limiting distractions. A few episodes ago, Joël talked about a frustrating bug he was chasing down and couldn't get closure on, so he had to move on. This week, that bug popped up again and he chased it down! AND he got to use binary search to find its source–which was pretty cool!

+ +

Together, Stephanie and Joël discuss dependency graphs as a mental model, and while they apply to code, they also help when it comes to planning tasks and systems. They talk about coupling, cycles, re-structuring, and visualizations.

+ +
+ + + +

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, I'm always trying to make meetings better for me [chuckles], more tolerable or more enjoyable. And in meetings a lot, I find myself getting distracted when I don't necessarily want to be. You know, oftentimes, I really do want to try to pay attention to just what I'm doing in that meeting in the moment. In fact, just now, I was thinking about the little tidbit I had shared on a previous episode about priorities, where really, you know, you can only have one priority [laughs] at a time. And so, in that moment, hopefully, my priority is the meeting that I'm in.

+ +

But, you know, I find myself, like, accidentally opening Slack or, like, oh, was I running the test suite just a few minutes before the meeting started? Let me just go check on that really quick. And, oh no, there's a failure, oh God, that red is really, you know, drawing my eye. And, like, could I just debug it really quick and get that satisfying green so then I can pay attention to the meeting? And so on and so forth. I'm sure I'm not alone in this [laughs]. And I end up not giving the meeting my full attention, even though I want to be, even though I should be.

+ +

So, one thing that I started doing about a year ago is origami. [laughs] And that ended up being a thing that I would do with my hands during meetings so that I wasn't using my mouse, using my keyboard, and just, like, looking at other stuff in the remote meeting world that I live in. So, I started with paper stars, made many, many paper stars, [laughs] and then, I graduated to paper cranes. [laughs] And so, that's been my origami craft of choice lately.

+ +

Then now, I have little cranes everywhere around the house. I've kind of created a little paper crane army. [laughs] And my partner has enjoyed putting them in random places around the house for me [laughs] to find. So, maybe I'll open a cabinet, and suddenly, [laughs] a paper crane is just there. And I think I realized that I've actually gotten quite good at doing these crafts.

+ +

And it's been interesting to kind of be putting in the hours of doing this craft but also not be investing time, like, outside of meetings. And I'm finding that I'm getting better at this thing, so that seemed pretty cool. And it is mindless enough that I'm mentally just paying attention but, yeah, like, building that muscle memory to perfecting the craft of origami.

+ +

JOËL: I'm curious, for your army of paper cranes, is there a standard size that you make, or do you have, like, a variety of sizes?

+ +

STEPHANIE: I have this huge stack of, like, 500 sheets of origami paper that are all the same size. So, they're all about, let's say, two or three inches large. But I think the tiny ones I've seen, really small paper cranes, maybe that would be, like, the next level to tackle because working with smaller paper seems, you know, even more challenging.

+ +

JOËL: I'd imagine the ratio of, like, paper thickness to the size of the thing that you're making is different.

+ +

STEPHANIE: At this point, they say that if you make 1,000, then you bring good luck. I think I'm well on my way [laughs] to hopefully being blessed with good luck in this household of my little paper crane army.

+ +

JOËL: It's interesting that you mentioned the power of having something tactile to do with your hands during a meeting, and I definitely relate to that. I feel like it's so easy, even, like, mindlessly, to just hit Command-Tab when I'm doing things on a screen. Like, my hands are on the keyboard. If I'm not doing something, I'm just going to mindlessly hit Command-Tab. It's kind of like on your phone sometimes. I don't know if you do this, like, just scrolling side to side. You're not actually doing anything. You just want motion with your fingers.

+ +

STEPHANIE: Yes. I know exactly what you're talking about. And it's funny because it's a bit of a duality where, you know, when you are in your development workflow, you want things to be as quick and convenient as possible, so that Command-Tab, you know, is very easy. It's just built in, and that helps speed up your, you know, day-to-day work. But then it's also that little bit of mindlessness, I think, that can get you down the distraction path.

+ +

When I was first looking for something to do with my hands, to have, like, a little tactile thing to keep me focused in meetings, I did explore getting one of those fidget cubes; I have to say. [laughs] It's just a little toy, you know, that comes with a bunch of different settings for you to fidget with.

+ +

There's, like, a ball you can roll, you know, with your thumb, or maybe some buttons to click, and it gives you that really satisfying tactile experience. And I know they work really well for a lot of people, but I've really enjoyed the, I guess, the unexpected benefits [chuckles] of getting better at a hobby [laughs] while spending my time at my work.

+ +

Joël, what is new with you?

+ +

JOËL: So, a few episodes ago, I talked about a really kind of frustrating bug that I was chasing down that was due to some, like, non-determinism in the environment. And it kind of came, and then it went away. And I wasn't able to get sort of closure on that and had to move on. Well, this week, that bug popped up again, and this time, I was actually able to chase it down. So, that felt really exciting. And I got to use binary search to try to find the source of it, which made me feel really cool.

+ +

STEPHANIE: Oooh, do tell. What ended up being the issue?

+ +

JOËL: I'm connecting to an external Snowflake data warehouse, and ActiveRecord tries to fetch the schema and crashes as part of that with some cryptic error that originates from the C extension ODBC Ruby driver package. I figured out that it's probably something to do with, like, a particular table name or something in the table metadata when we're pulling this schema that we're not happy about. But I don't know which table is the one that it's not happy with.

+ +

Well, this time, I was able to figure out, by reading through some of the documentation, that I can pull subsets of the schema. So, I can pull the first n values of that schema, and it won't crash. It only crashes if I try to fetch the entire set, which is what is happening under the hood. At that point, you know, I could fetch each row individually, but there's hundreds of these. So, you know, I try, okay, what happens if I try to fetch 1,000 of these? Is it going to crash? Because it's a massive system. So, yes, I get a crash.

+ +

So, I know that a table less than a thousandth in the list of tables is what's causing the problems. So, okay, fetch 500 halfway in between there. It's still going to crash. Okay, 250, 125. I then kind of keep halving all the time until I find one that doesn't crash. And now I know that it is somewhere between the last crash and this one. So, I think it was between 125 and 250. And now I can say, okay, well, let's fetch the first, you know, maybe 200 tables, okay, that crashes. And I keep halving that space until you finally find it. And then, like, okay, so it's this one right here.

+ +

Now, the problem is the bad table actually crashes. So, I think it ended up being, like, number 175 or something like that. So, I never get to see the actual table itself. But because the list of tables is in alphabetical order, and I can see because I can fetch the first 174 and it succeeds, so I can tell what the previous 5, 6, you know, previous 174 are.

+ +

I can pretty easily go and look at the actual database and the list of tables and say, okay, well, it's in the same order. And the next one is this one, and hey, look, there is some metadata there that has some very long fields that are longer than one might expect, specifically going over a potentially implied 256-character limit. That seems somewhat suspicious. And, oh, if we remove this table, all of a sudden, everything works.

+ +

STEPHANIE: Wow, binary search, an excellent debugging tool [laughs] when you have no idea, you know, what could possibly be causing your issue.

+ +

JOËL: It's such a cool tool. Like, I'm always so happy when I get a chance to use it. The problem is, you need a way to be able to answer the question, like, have I found it? Yes or no? Or, generally, is it greater or less than this current position?

+ +

STEPHANIE: Well, that's really exciting that you ended up figuring out how to solve the bug. I know last time we talked about it, you kind of had left off in a space of, hopefully, we won't run into this issue again because it's no longer happening. But it seems like you were also set up this time around to be able to debug once it cropped up again.

+ +

JOËL: Yes. So, binary search is really cool. It's got this, like, very, like, fancy computer science name. But in reality, it's a fairly simple, straightforward technique that I use fairly frequently in my development. And there's another kind of computer sciency fancy-sounding concept that I use all the time. You've all heard me reference this multiple times on the show. You're right; we're finally doing it. This is the dependency graph episode.

+ +

STEPHANIE: Woo. [laughter] It's time. I'm excited to really dig into it because, you know, as someone who has heard you talk about it a lot, you know, and is maybe a little less familiar with graph theory and how, you know, it can be applied to my day to day work, I'm really excited to dig into a little bit about, you know, what a regular developer needs to know about dependency graphs to add to their toolbox of skills.

+ +

JOËL: So, I think at its core, the idea of a dependency graph is that you have a group of entities, some of which depend on each other. They can't do a task, or they can't be created unless some other subtasks or dependent actions take place. And so, we have a sort of formal structural way of describing these things. Visually, we often draw these things out where each of the pieces is like a little bubble or a circle, and then we draw arrows towards the things that it depends on.

+ +

So, if A cannot be done without B being done first, we draw an arrow from A to B. That's kind of how it is in the abstract. More concretely, this kind of thing shows up constantly throughout the work that we do because a lot of what we do as developers is managing things that are connected to each other or that depend on each other. We build complex systems out of smaller components that all rely on each other.

+ +

STEPHANIE: Yeah, I think it's interesting because I use the word dependency, you know, very frequently when talking about normal work that I'm doing, you know, dependencies as in libraries, right? That we've pulled into our application, or dependencies, like, talking about other classes that are referenced in this class that I'm working in. And I never really thought about what could be explored further or, like, what could be learned from really digging into those connections.

+ +

JOËL: It's a really powerful mental model. And, like you said, dependencies exist all over our work, and we often use that word. So, you mentioned something like packages, where your application depends on Rails, which in turn depends on ActiveRecord, which in turn depends on a bunch of other things. And so, you've got this whole chain of maybe immediate dependencies, and then those dependencies have dependencies, and those dependencies have dependencies, and it kind of, like, grows outward from there.

+ +

And in a very kind of simplistic model, you might think, oh, well, it's more, like, a kind of a tree structure. But oftentimes, you'll have things like branches on one side that connect back to branches on the other. And now you've got something that's no longer really tree-like. It's more of a sort of interconnected web, and that is a graph.

+ +

STEPHANIE: I think understanding the dependencies of your system has also become more important to me as I learn about things that can go wrong when I don't know enough about what my system is, you know, relying on that I had kind of taken for granted previously. I'm especially thinking about packages like we were mentioning, and, you know, not realizing that your application is dependent on this other library, right? That's brought in by a gem that you're using. And there's maybe, like, a security issue, right? With that.

+ +

And suddenly, you have this problem on your hands that you didn't realize before. And I know that that has been more of a common discussion now in terms of security practices, just being more aware of all the things that you are depending on as really our work becomes more and more interconnected with the things available to us with open source.

+ +

JOËL: I think where understanding the graph-like nature of this becomes really important is when you're doing something like an upgrade. So, let's say you do have a gem that has a security problem, and you want to upgrade it to fix that security issue. But the upgrade that includes the security patch is also a breaking upgrade. And so, now everything else in your system that depends on that gem or on that package is going to break unless you have them in a version that is compatible with the new version of that gem.

+ +

And so, you might have to then go downstream and upgrade those packages in a way that's compatible with your app before you can bring in the security patch. And a lot of that can be done automatically by Bundler. Bundler is software that is built around navigating dependency graphs like that and finding versions that are compatible with each other.

+ +

But sometimes, your code will need to change in order to upgrade one of these downstream gems so that you can then pull in the upgrade from the gem that needs a security patch. And so, understanding a little bit of that graph is going to be important to safely upgrading that gem.

+ +

STEPHANIE: So, I know another application of dependency graphs that you have thought about and written a blog post for is RSpec let declarations and how a lot of the time when we are using let, you know, we are likely calling other variables defined by let. And so, when you are encountering a test file, it can be really hard to grok what data is being set up in your test.

+ +

JOËL: Yeah, so that is really interesting because you can define something that will get executed in a lazy fashion if it gets referenced. But then not only is the let lazy and will not trigger unless it's referenced, but a let can reference other lets, which are also lazy, and only get triggered if they get referenced.

+ +

So, you might have a bunch of lets defined in any order you want throughout a file, and they're all kind of interconnected with these references to each other. But they only get triggered if something calls it directly or it's in this, like, chain of dependencies. And getting a grasp on what actually gets created, which lets will actually execute, which ones don't in a file can quickly get out of hand. And so, thinking of this in terms of a dependency graph has been a really helpful mental model for me to understand what's going on in a complex test file.

+ +

STEPHANIE: Yeah, absolutely. Especially when sometimes the lets are coming from all over the place, you know, maybe a describe block hundreds of lines away, or even a completely different file if you are using a shared context that's being pulled in. So, I can see why this was a complex problem that could be made a little simpler with plotting out a dependency graph.

+ +

And in preparation for this episode, I was doing a little bit of my own exploration on this because I certainly know, you know, the pain of trying to figure out what is being executed in my tests when there are a lot of lets that reference each other. And in the blog post, you kind of gave a little step-by-step of how you could start with creating a dependency graph for the test that you're working with.

+ +

And I was really curious if this process could be automated because, you know, I do enjoy, you know, pulling out the pen and paper [chuckles] every now and then. But I'm not, like, a particularly visual person. God forbid I, like, draw a circle, but then, like, don't have enough space for the rest of the circles. [laughs] So, I was really hoping for a tool that could do this for me, especially if, you know, you do, you have a lot of tests that you have to try to understand in a relatively short amount of time. And so, I ended up doing something kind of hacky with RSpec and overriding let definitions to automate this process.

+ +

JOËL: That's really cool. So, is the tool that you're trying to build something where you feed it in a spec file, and it gives you some kind of graphical representation like an SVG or something as output?

+ +

STEPHANIE: Yeah. I did consider that approach first, where you feed in the file, but then I ended up going with something more dynamic where you are running the test, and then as it gets executed, tracing the let definitions and then registering them to build your dependency graph.

+ +

JOËL: So, you've got some sort of internal modeling that describes a dependency graph. And then, somehow, you're going to turn that, you know, a series of Ruby objects into some kind of visual.

+ +

STEPHANIE: Yeah, exactly. And the bulk of that work was actually done with a library called RGL, which stands for just Ruby Graph Library. [laughs] And what's nice is that it has a really easy interface for plugging in the vertices and edges of the dependency graph that you want to build. And then, it is already hooked up with Graphviz to, you know, write the SVG to a file. And so, I ended up really just having to build up an array of my dependencies and the connections to each other and then feed it into the constructor of the graph.

+ +

JOËL: And for all of our listeners, you mentioned Graphviz. That is a third-party tool that can be installed on your machine that can generate these SVG diagrams from...I believe it has its own sort of syntax. So, you create, I believe it's dot, D-O-T, so dot dot file. And based off of that, it generates all sorts of things, but SVG being potentially one of them.

+ +

STEPHANIE: Yeah. The nice thing was that I actually didn't end up having to use the DSL of Graphviz because the RGL gem was doing them for me.

+ +

JOËL: Nice. So, it plugs in directly.

+ +

STEPHANIE: Yeah, exactly. And I was really curious about using this gem because I, you know, just wanted to write Ruby, especially to plug into other things that are already in Ruby. And I found that surprisingly easy, thanks to all of the RSpec config options that they make available to you, including an option to extend the example group class, which is actually where let and let bang is defined.

+ +

And so, I ended up overriding those classes and using, you know, the name of the let that you're defining and then the block to basically register the dependencies. And I also ended up exploring a little bit with using Ruby's built-in parser to figure out in the block that's being passed to the let, what parts of that block could potentially be a reference to another let.

+ +

JOËL: That's really cool. Did you get any fun results from that?

+ +

STEPHANIE: I did. It worked pretty well in being able to capture all of the let declarations, and other lets that it references. And so, I was able to successfully, you know, like, generate a visual dependency graph of all of the lets, so that was really neat.

+ +

The part that I was really kind of excited about trying next, though I didn't end up having time to yet, was figuring out which of those let values are executed by way of the let bang, right? Which is eager or what is referenced in the test that then gets executed as well. And so, the RGL library is pretty neat and has some formatting options, too, with the Graphviz output. So, you can change the font color or styling options for different, you know, nodes and edges. And so, I was really curious to pursue this further, maybe, and use it to show exactly what gets evaluated now that I have successfully mapped my let graph.

+ +

JOËL: Right. Because the whole point of this exercise is that not the entire graph is going to get evaluated. The underlying question is, what data actually gets created when my test runs? And so, you build out this whole dependency graph, and then you can follow a few simple rules to say, okay, this branch gets called, this branch gets called, this series of things gets called. And okay, this subset of let blocks trigger, and therefore this data has been created for my given test.

+ +

STEPHANIE: Yeah. Though I will say that even where I got so far to, just seeing all of the let definitions in a spec file was really helpful to have a better understanding, you know, if I do have to add a test in here, and I'm thinking about reaching for a pre-existing let declaration, to be like, oh, like, it actually, you know, goes on to reference all of these other things that may be factories [chuckles] that are created might make me, you know, think twice, or just have a little better understanding of what I'm really dealing with.

+ +

JOËL: Right. The idea that when you're calling out to a let, or a factory, or something else that's just a node in a large graph, you're not necessarily referencing just one thing. You might actually be referencing the head of a very long chain of things that maybe you don't intend to trigger the whole thing.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: So, in that sense, having a sort of visual or at least an idea of the graph can give you a much better sense of the cost of certain operations that you might have to do.

+ +

STEPHANIE: The cost of the operations certainly, especially when, you know, you are working in a legacy codebase, and you, you know, like, maybe don't know how everything plays together or is connected. And it's very tempting to just reach for [chuckles] the things that have been, you know, created or built for you. And I'm certainly guilty of that sometimes on this client project, where the domain is so complex, and there are so many associated models.

+ +

And I'm like, well, like, let me just, you know, use this let that already, you know, has a factory set up for what I think I need for this test. But then realizing, oh, actually, like, it is creating all these things, and do I really need them? I think it can be really challenging to unravel all of that in your head. And so, with this very scrappy tool that I [chuckles] built for my own purposes, you know, maybe it makes it, like, one step easier to try to fully understand what I'm working with and maybe do something different.

+ +

JOËL: One aspect that I think is really powerful about dependency graphs is that it takes this kind of, like, abstract concept that we oftentimes have an intuitive sense around, the idea that we have different components that depend on each other, and it shows it to us visually on, like, a 2D plane. And that can be really helpful to get an understanding or an overview of a system.

+ +

You mentioned that RGL uses Graphviz to generate some SVGs. A visual tool that I've been using to draw some of my dependency graphs has been mermaid.js. It has a syntax that's, like, a text-based syntax, but it's almost visual in that you have a piece of text and name of a node. And then, you'll draw a little ASCII arrow, you know, two dashes and a greater than sign to say this thing depends on, and then write another name, and just have a row, like, a bunch of entries to say; A depends on B. A also depends on C. C depends on D, and so on, and, like, build up that list. And then Mermaid will just generate that diagram for you.

+ +

STEPHANIE: Yeah. I've used Mermaid a few times. One really helpful use that I had for it was diagramming out a bunch of React components that I had and wanting to understand the connections between them. And I think you can even paste the Mermaid syntax into your GitHub pull request description, and it'll render as the graph image.

+ +

JOËL: Yeah, that's what's really cool is that Mermaid syntax has become embedded in a lot of other places in the past few years. So, it's really easy to embed graphs now into all sorts of things. You mentioned GitHub. It works in pull requests descriptions, comments, I think pretty much anywhere that Markdown is accepted. So, you could put one in your README if you wanted.

+ +

Another place that I use a lot, Obsidian, my note-taking tool, allows me to embed graphs directly in there, which is really much nicer than previously; sometimes, when I wanted to express something as a visual, I would use some sort of drawing tool to do something and export an image, and then embed that in my note. But now I can just put in this text, and it will automatically render that as a diagram.

+ +

And part of what's really nice about that is that then it's really easy for me to go and change that if I'm like, oh, but actually, I want to add one more connection in here. I don't have to re go back to, hopefully, a file that I've saved somewhere and, like, change an image file and re-export it. I just, you know, I add one line of text to my note, and it just works.

+ +

STEPHANIE: That's awesome. Yeah, the ability to change it seems really useful.

+ +

So, we've talked a little bit about tools for creating a visual aid for understanding our dependencies. And now that we have our graph, maybe we might have some concerning observations about what we see, especially when perhaps some of our dependencies are pointing back to each other.

+ +

JOËL: Yes. So, I think you're referencing cycles, in particular. That would be the formal term for it. And those are really interesting. They happen in dependency graphs. And I would say, in many cases, they can be a bit of a smell. There's definitely situations where they're fine. But there are things that you look at, and you're like, okay, this is going to be a more complex kind of tricky bit of the graph to work with.

+ +

Some cases, you just straight up can't have them. So, I want to say that the way RSpec lets are set up, you cannot write code that produces cycles. But you might have...I think Ruby allows classes to reference each other in such a way that it creates a cycle, and not all languages do that. So, Elm and F#, I believe, require that modules cannot reference each other. The fancy term for this is a dependent acyclic graph, or DAG, which basically just means that there are no cycles in that graph.

+ +

STEPHANIE: Yeah. What you said about classes referencing each other is very interesting because I've definitely seen that. And then, if I have to go about changing something, maybe even it's just the class name, right? Now there's no way in which I can really make just one change. I have to kind of do it all in one go.

+ +

JOËL: I think that's a common property of a cycle, and a graph is that changes that happen somewhere in that cycle often need to be all shipped together as one piece. You can't break it up into smaller chunks because everything depends on everything else. So, it has to be kind of boxed together and shipped as one thing.

+ +

STEPHANIE: And you'd mentioned that cycles, you know, can be a bit of a code smell. And if the goal is to be able to break it up so that it is a little bit more manageable to work with, how would you go about breaking a cycle?

+ +

JOËL: So, I think breaking a cycle is going to vary a little bit based on your problem domain. So, are you modeling a series of classes that are referencing each other? Is this a function call graph? Is this even, like, a series of tasks that you're trying to do? But typically, what you want to do is make sure that eventually, at some point, like, something doesn't loop back to referencing something higher up in your hierarchy. And so, oftentimes, it ends up being about what is allowed to know about what? Do you have higher-level concepts that can know and depend on lower-level concepts but not vice versa?

+ +

And again, we are talking about this a little bit at the abstract level. But in terms of, let's say, different code modules, or classes, or something like that, commonly, you might say, well, we want some sort of layering where we have almost, like, more primitive types of classes at the bottom. And they don't get to know about anything above them. But the ones above that might be more complex that are composed of smaller pieces know about the ones below them. And you might have multiple layers kind of like that that all kind of point down, but nothing points up.

+ +

STEPHANIE: That is a very common heuristic. [chuckles] I think you were basically just describing how I also understand creating React components, where you want to separate your presentational ones from your functional ones. And, yeah, it makes a lot of sense that as soon as you start adding that complexity of, you know, those primitive classes at the bottom, starting to, you know, point to things higher up or to know about things higher up, that is where a cycle may be accidentally introduced.

+ +

JOËL: It's interesting just how many design principles that we have in software. If you dig into them a little bit, you find out that they're about decoupling things, and oftentimes, it's specifically breaking up cycles. So, one way that you might have something like this that actually has dependency in the name, the dependency inversion principle, where what you're effectively doing is you're taking one of those dependency arrows, and you're flipping it the other way. So, instead of A depending on B, you're flipping it. Now B depends on A, and that can be enough to break a cycle.

+ +

STEPHANIE: So, one thing I've picked up from our conversations about dependency graphs is that oftentimes, you know, when you're trying to figure out where to start, you want to look for those areas or those nodes where there's nothing else that depends on it.

+ +

JOËL: Yeah. I think you have those nodes that, if this were a tree, you would call them the leaf nodes. In the case of a graph, I'm not sure if that's technically correct, but they don't depend on anything. They're kind of your base case. And so, you can, you know, if it's a function, you can run it. If it's a file, you can load it; if it's a class, also you can load it up and not have to do anything else because it has no dependencies. And knowing that those are there, I think, can be really useful in terms of knowing an order you might want to execute something in. And this is really interesting for one of my favorite uses of a graph, which is breaking down a series of tasks that you need to do.

+ +

So, commonly, you might say, okay, I have a large task I need to do. I break it down into a series of subtasks. And, you know, maybe I draw out, like, a bulleted list and, you know, task 1, 2, 3, 4, 5. The problem is that they're not necessarily just a flat list. They all have, like, orders, like dependencies between each other. So, maybe one has to happen before 2, but it also has to happen before 3, which needs to happen before two, and, like, there's all these interconnections.

+ +

And then, you find out that you can't ship them independently the way you thought initially. So, by building up a graph, you end up with something that shows you exactly what depends on what. And then, like you said, the parts that are really interesting where you can start doing work are the ones that have no dependencies themselves. Other things might depend on them, but they have no dependencies. Therefore, they can be safely built, shipped, deployed to production, and they can be done independently of the other subtasks.

+ +

STEPHANIE: Yeah. I was also thinking about things that could be done in parallel as well. So, if you do have multiple of those items with no dependencies, like, that is a really good way to be able to break up that work and, yeah, identify things that are not blocked.

+ +

JOËL: For a complex set of tasks, it's great to see, okay, these two pieces have no dependencies. We can have them be done in parallel, shipped independently. And then you can just kind of keep repeating that process. Because once all of the tasks that have no dependencies have been done, well, you can almost, like, remove them from the graph and see, okay, what's the new set of things that have no dependencies? And then, keep doing that until you've eventually done the whole graph.

+ +

And that may sound like, oh okay, we're just kind of using a little bit of intuition and working through the graph. It turns out that this is a, like, actual, like, formal thing. When it comes to graphs, it's a traversal algorithm called topological sort is the fancy name for it, and it basically, yeah, it goes through that. It gives you a list of nodes in order where each node that you're given has no dependencies that have not been evaluated yet.

+ +

So, it works from effectively to use our tree terminology, from the leaf nodes to the root, potentially roots plural, of the graph, and each step is independent. So that's a lot of, like, fancy terminology, and getting a little bit of, like, computer science graph theory into here.

+ +

So, my, like, general heuristic is that graphs should be evaluated from the bottom up when you're trying to evaluate each piece independently. So, when you do that, you get to do each piece independently, as opposed to if you're evaluating from the top down. So, starting from the one thing that depends on everything else, well, it can't be shipped until all of its dependencies have been shipped.

+ +

And all the transitional dependencies can't be shipped until their dependencies have been shipped. And so, you end up being not able to ship anything until you've built the entire graph. And that's when you end up with, you know, a 2,000-line PR that took you multiple weeks and might be buggy. And it's going to take a long time to review. And it's just not what anybody wants.

+ +

STEPHANIE: I'm glad you brought this up because I think this is where I am really curious to get better at because oftentimes, when I am breaking down a complex task, it's quite hard for me to see all of the steps that need to happen. And so, you know, you maybe start out with that, like, top-level node, like, the task that needs to be done as you understand it immediately. And it's really hard to actually identify the dependencies and, like, the smaller pieces along the way. And because you're not able to identify that, you think that you do have to just do it all in one go.

+ +

JOËL: Yeah, that sort of root node is typically the overarching task, the goal of what you want to do. And a common, I think, scenario for something like this would be, let's say, you're doing a Rails upgrade. And so, that root node is upgrade Rails. And a common thing that you might want to do is say, okay, let's go to the gem file, upgrade Rails, see what breaks, and then just keep fixing those things. That's working from the top down.

+ +

And you're going to be in a long-running branch, and you're going to keep fixing things, fixing things, fixing things until you have found all the things but done all the things. And then you do a big bang upgrade that may have taken you weeks. As opposed to if you're working from the bottom up, you try to figure out, okay, what are all the subtasks? And that might take some exploration. You might not know upfront.

+ +

But then you might say, okay, here, I can upgrade RSpec versus a dependency, or I need to change the interface of this class and ship all these pieces one at a time. And then, the final step is flipping that upgrade in the gem file, saying, okay, now I've upgraded Rails from 4 to 5, or whatever the version is that you're trying to do.

+ +

STEPHANIE: I think you've really hit the nail on the head when it comes to trying to do something but not knowing what subtasks may compose of it and getting into that problem of, you know, having not broken it down, like, enough to really see all the dependencies.

+ +

And, you know, maybe this is a conversation [chuckles] for another episode, but the skill of breaking up those tasks and exploring what those dependencies are, and being able to figure them out upfront before you start to just do that upgrade and then see what happens, that's definitely an area that I want to keep investing in. And I'm sure other people would be really curious about, too, to help them make their jobs easier.

+ +

JOËL: I think one tip that I've learned that's really fun and that connects into all of this is sometimes you do end up with a cycle in your dependencies of tasks. A technique for breaking that up is a pattern that I have pitched multiple times on the show: the strangler fig pattern. And part of why it's so powerful is that it allows you to work incrementally by breaking up some of these cycles in your dependency graph.

+ +

And one of the lessons that I've learned from that is that just because you have sort of an initial set of subtasks and you have a graph of them doesn't mean that you can't change them. If you're following strangler fig, what you're actually doing is introducing one or more new subtasks to that graph. But the way you introduce them breaks up that cycle. So, you can always add new tasks or split up existing ones as you get a better understanding of the work you need to do. It's not something that is fixed or set in stone upfront.

+ +

STEPHANIE: Yeah, that's a really great tip. I think next time, what I really want to explore, you know, your heuristic of going from bottom up, yeah, sure, it sounds all fine and dandy. But how to get to a point where you're able to see everything at the bottom, right? And, like, when you are tasked, or you do start with the thing at the top, like, the end goal. Yeah, I'm sure that's something we'll explore [chuckles] another day.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+gpZSEPCW + + ]]> + + Joël Quenneville + Stephanie Minn + + + 396: Build vs. Buy + https://bikeshed.thoughtbot.com/396 + d544e9b1-b9fd-436f-adad-d674c1731ef5 + Tue, 08 Aug 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël has been fighting a frustrating bug where he's integrating with a third-party database, and some queries just crash. Stephanie shares her own debugging story about a leaky stub that caused flaky tests. + +Additionally, they discuss the build vs. buy decision when integrating with third-party systems. They consider the time and cost implications of building their own integration versus using off-the-shelf components and conclude that the decision often depends on the specific needs and priorities of the project, including how quickly a solution is needed and whether the integration is core to the business's value proposition. + 33:57 + no + + + Joël has been fighting a frustrating bug where he's integrating with a third-party database, and some queries just crash. Stephanie shares her own debugging story about a leaky stub that caused flaky tests. +Additionally, they discuss the build vs. buy decision when integrating with third-party systems. They consider the time and cost implications of building their own integration versus using off-the-shelf components and conclude that the decision often depends on the specific needs and priorities of the project, including how quickly a solution is needed and whether the integration is core to the business's value proposition. +Ruby class instance variables (https://www.codegram.com/blog/understanding-class-instance-variables-in-ruby/) +Build vs Buy by Josh Clayton (https://thoughtbot.com/blog/build-vs-buy-considerations-for-new-products) +Sustainable Rails (https://sustainable-rails.com/) +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: My world has been kind of frustrating recently. I've been fighting a really frustrating bug where I'm integrating with a third-party database. And there are queries that just straight-up crash. Any query that instantiates an instance of an ActiveRecord object will just straight-up fail. And that's because before, we make the actual query, almost like a preflight query that fetches the schema of the database, particularly the list of tables that the database has, and there's something in this schema that the code doesn't like, and everything just crashes. +Specifically, I'm using an ODBC connection. I forget exactly what the acronym stands for, Open Database connection, maybe? Which is a standard put up by Microsoft. The way I'm integrating it via Ruby is there's a gem that's a C extension. And somewhere deep in the C extension, this whole thing is crashing. So, I've had to sort of dust off some C a little bit to look through. And it's not super clear exactly why things are crashing. So, I've spent several days trying to figure out what's going on there. And it's been really cryptic. +STEPHANIE: Yeah, that does sound frustrating. And it seems like maybe you are a little bit out of your depth in terms of your usual tools for figuring out a bug are not so helpful here. +JOËL: Yeah, yeah. It's a lot harder to just go through and put in a print or a debug statement because now I have to recompile some C. And, you know, you can mess around with some things by passing different flags. But it is a lot more difficult than just doing, like, a bundle open and binding to RB in the code. +My ultimate solution was asking for help. So, I got another thoughtboter to help me, and we paired on it. We got to a solution that worked. And then, right before I went to deploy this change, because this was breaking on the staging website, I refreshed the website just to make sure that everything was breaking before I pushed the fix to see that everything is working. This is a habit I've picked up from test-driven development. You always want to see your test break before you see it succeed. +And this is a situation where this habit paid off because the website was just working. My changes were not deployed. It just started working again. Now it's gotten me just completely questioning whether my solution fixes anything. The difficulty is because I am integrating [inaudible 03:20] third-party database; it's non-deterministic. The schema on there is changing rather frequently. +I think the reason things are crashing is because there's some kind of bad data or data that the ODBC adapter doesn't like in this third-party system. But it just got introduced one day; everything started breaking, and then somehow it got removed, and everything is working again without any input or code changes on my end. So, now I don't trust my fix. +STEPHANIE: Oh no. Yeah, I would struggle with that because your reality has come crashing down, [laughs] or how you understood reality. That's tough. Where do you think you'll go from here? If it's no longer really an issue in this current state of the schema, is it worth pursuing further at this time? +JOËL: So, that's interesting because it turns into a prioritization problem. And for this particular project, with the deadlines that we have, we've decided it's not worth it. I've opened up a PR with my fix, with some pretty in-depth documentation for why I thought that was the fix and what I think the underlying problem is. If this shows up again in the next few days, I'll have that PR that I can pull in and see if it fixes things, and if it doesn't, I'll probably just close that PR, but it'll be available for us if we ever run into this again. +I've also looked at a few potential mitigating situations. Part of the problem is that this is a, like, massive system. The Rails app that I'm using really doesn't need to deal with this massive database. I think there's, you know, almost 1,000 tables, and I really only care about a subset of tables in, like, one underlying schema. And so, I think by reducing the permissions of my database user to only those tables that I care about, there's a lower chance of me triggering something like this. +STEPHANIE: Interesting. What you mentioned about, you know, having that PR continue to exist will be really helpful for future folks who might come across the same problem, right? Because then they can see, like, all of the research and investigation you've already done. And you may have already done this, but if you do think it's a schema issue, I'm curious about whether the snapshot of the schema could be captured from when it was failing to when it has magically gotten fixed. And I wonder if there may be some clues there for some future investigator. +JOËL: Yeah. I'm not sure what our backup situation is because this is a third-party system, so I'd have to figure out what things are like in the admin interface there. But yeah, if there is some kind of auditing, or snapshots, or backups, or something there, and I have rough, you know, if I know it's within a 24-hour period, maybe there's something there that would tell me what's happening. +My best guess is that there's some string that is longer than expected or maybe being marked as a CHAR when it should be a VARCHAR, or maybe something that's not a non-UTF-8 encoded character, or something weird like that. So, I never know exactly what was wrong in the schema. There's some weird string thing happening that's causing the Ruby adapter to blow up. +STEPHANIE: That also feels so unsatisfying [laughs] for you. I could imagine. +JOËL: Yeah, there's no, like, clean resolution, right? It's a, well, the bug is gone for now. We're trying to make it less likely for it to pop up again in the future. I'm trying to leave some documentation for the next person who's going to come along, and I'm moving forward, fingers crossed. Is that something you've ever had to do on one of your projects? +STEPHANIE: Given up? Yes. [laughter] I think I have definitely had to learn how to timebox debugging and have some action items for when I just can't figure it out. And, you know, like we mentioned, leaving some documentation for the next person to pick up, adding some additional logging so that maybe we can get more clues next time. But, you know, realizing that I do have to move on and that's the best that I can do is really challenging. +JOËL: So, you used two words here to describe the situation: one was giving up, and the other one was timebox. I think I really like the idea of describing this as timeboxing. Giving up feels kind of like, defeatist. You know, there's so many things that we can do with our time, and we really have to be strategic with how we prioritize. So, I like the idea of describing this as a timeboxing situation. +STEPHANIE: Yeah, I agree. Maybe I should celebrate every time that I successfully timebox something [laughs] according to how I planned to. [laughs] +JOËL: There's always room to extend the timebox, right? +STEPHANIE: [laughs] It's funny you bring up a debugging mystery because I have one of my own to share today. And I do have to say that it ended up being resolved, [chuckles] so it was a win in my book. But I will call this the case of the leaky stub. +JOËL: That sounds slightly scary. +STEPHANIE: It really was. The premise of what we were trying to figure out here was that we were having some flaky tests that were failing with a runtime error, so that was already kind of interesting. But it was quickly determined it was flaky because of the tests running in a certain order, so-- +JOËL: Classic. +STEPHANIE: Right. So, I knew something was happening, and any tests that came after it were running into this error. And I was taking a look, and I figured out how to recreate it. And we even isolated to the test itself that was running before everything else, that would then cause some problems. And so, looking into this test, I saw that it was stubbing the find method on an ActiveRecord model. +JOËL: Interesting. +STEPHANIE: Yeah. And the stubbed value that we were choosing to return ended up being referenced in the tests that followed. So, that was really strange to me because it went against everything I understood about how RSpec cleans up stubs between tests, right? +JOËL: Yeah, that is really strange. +STEPHANIE: Yeah, and I knew that it was referencing the stub value because we had set a really custom, like, ID value to it. So, when I was seeing this exact ID value showing up in a test that seemed totally unrelated, that was kind of a clue that there was some leakage happening. +JOËL: So, what did you do next? +STEPHANIE: The next discovery was that the error was actually raised in the factory setup for the failing tests and not even getting to running the examples at all. So, that was really strange. And digging into the factories was also its own adventure because there was a lot of complexity in the factories. A lot of them used hooks as well that then called some application code. And it was a wild goose chase. +But ultimately, I realized that in the factory setup, we were calling some application code for that model where we had stubbed the find, and it had used the find method to memoize a class instance variable. +JOËL: Oh no. I can see where this is going. +STEPHANIE: Yeah. So, at some point, our model.find() returned our, you know, stub value that we had wanted in the previous test. And it got cached and just continued to leak into everything else that eventually would try to call that memoized method when it really should have tried to do that look-up for a separate record. +JOËL: And class instance variables will persist between tests as long as they're on the same thread, right? +STEPHANIE: Yeah, as far as I understand it. +JOËL: That sounds like a really frustrating journey. And then that moment when you see the class instance variable, and you're like, oh no, I can't believe this is happening. +STEPHANIE: Right? It was a real recipe for disaster, I think, where we had some, you know, really complicated factories. We had some sneaky caching issues, and this, you know, totally seemingly random runtime error that was being raised. And it was a real wild goose chase because there was not a lot of directness in going down the debugging path. I feel like I went around all over the codebase to get to the root of it. And, in the end, you know, we were trying to come up with some takeaways. +And what was unfortunate was that you know, like, normally, stubbing find can be okay if you are, you know, really wanting to make sure that you are returning your mocked value that you may have, like, stubbed some other stuff on in your test. But because of all this, we were like, well, should we just not stub find on this really particular model? And that didn't seem particularly sustainable to make as a takeaway for other developers who want to avoid this problem. +So, in the end, I think we scoped the stub to be a little more specific with the arguments that we wanted to target. And that was the way that we went forward with the particular flaky test at hand. +JOËL: It sounds like the root cause of the problem was not so much the stub as it was the fact that this value is getting cached at the class level. Is that right? +STEPHANIE: Yes and no. It seems like a real pain for running the tests. But I'm assuming that it was done for a good reason in production, maybe, maybe not. To be fair, I think we didn't need to cache it at all because it's calling a find, which is, you know, should be pretty quick and doesn't need to be cached. But who knows? It's hard to tell. It was really old code. And I think we were feeling also a little nervous to adjust something that we weren't sure what the impact would be. +JOËL: I'm always really skeptical of caching. Caching has its place. But I think a lot of developers are a little too happy to introduce one, especially doing it preemptively that, oh well, we might need a cache here, so why not? Let's add that. Or even sometimes, just as a blind solution to any kind of slowness, oh, the site is slow; let's throw a cache here and hope for the best. +And the, like, bedrock, like, rule zero of any kind of performance tuning is you've got to measure before and after and make sure that the change that you introduce actually makes things better. And then, also, is it better enough speed-wise that you're willing to pay any kind of costs associated to maintaining the code now that it's more complex? And a lot of caches can have some higher carrying costs. +STEPHANIE: Yeah, that's a great point. This debugging mystery an example of one of them. +JOËL: How long did it take you to figure out the solution here? +STEPHANIE: So, like you, I actually was on a bit of the incorrect path for a little while. And it was only because this issue affected a different flaky test that someone else was investigating that they were able to connect the dots and be like, I think these, you know, two issues are related. And they were the ones who ultimately were able to point us out to the offending test if you will. So, you know, it took me a few days. And I imagine it took the other developer a few days. So, our combined effort was, like, over a week. +JOËL: Yep. So, for all our listeners out there, you just heard that Stephanie and I [laughs] both went on multi-day debugging journeys. That happens to everyone. Just because we've been doing this job for years doesn't mean that every bug is, like, a thing that we figure out immediately. +So, separately from this bug that I've been working on, a big issue that's been front of mind for me on this project has been the classic build versus buy decision. Because we're integrating with a third-party system, we have to look at either building our own integration or trying to use some off-the-shelf components. And there's a few different levels of this. +There are some parts where you can actually, like, literally buy an integration and think through some of the decisions there. And then there's some situations where maybe there's an open-source component that we can use. And there's always trade-offs with both the commercial and the open-source situation. And we have to decide, are we willing to use this, or do we want to build our own? And those have been some really interesting discussions to have. +STEPHANIE: Yeah. I think you actually expanded this decision-making problem into a build versus buy versus open source because they are kind of, you know, really different solutions with different outcomes in terms of, you know, maintenance and dependencies, right? And that all have, like, a little bit of a different way to engage with them. +JOËL: Interesting. I think I tend to think of the buy category, including both like commercial off-the-shelf software and also open-source off-the-shelf software, things that we wouldn't build custom for ourselves but that are third-party components that we can pull in. +STEPHANIE: Yeah, that's interesting because I had a bit of a different mental model because, in my head, when you're buying a commercial solution, you, you know, are maybe losing out on some opportunities for customization or even, like, forking it on your own. So, with an open-source solution, there could be an aspect of making it work for you. Whereas for a commercial solution, you really become dependent on that other company and whether they are willing to cater [laughs] to your needs or not. +JOËL: That's fair. For something that's closed-source where you don't actually have access to the code, say it's more of a software as a service situation, then, yeah, you're kind of locked in and hoping that they can provide the needs that you have. On the flip side, you are generally paying for some level of support. The quality of that varies sometimes from one vendor to another. But if something goes wrong, usually, there's someone you can email, someone you can call, and they will tell you how to fix the problem, or they will fix it on their end. +STEPHANIE: For the purposes of this conversation, should we talk about the differences, you know, building yourself or leaning on an existing built-out solution for you? +JOËL: The project I'm working on is integrating with a Snowflake data warehouse, which is an external place that stores data accessible through something SQL-like. And one of the things that's attractive about this is that you can pull in data from a variety of different sources, transform it, and have it all stored in a kind of standardized structure that you can then integrate with. So, for pulling data in, you can build your own sort of ingestion pipeline, if you want, with code, and their APIs, and things. +But there are also third-party vendors that will give you kind of off-the-shelf components that you can use for a lot of popular other data sources that you might want to pull. So, you're saying; I want to pull from this external service. They've probably got a pre-built connector for it. They can also do things like pull from an arbitrary Postgres database on some other server if that's something you have access to. +It becomes really attractive because all you need to do is create an account on this website, plug in a few, like, API keys and URLs. And, all of a sudden, data is just flowing from one third-party system into your Snowflake data Warehouse, and it all just kind of works. And you don't have to bother with APIs, or ODBC, or any of that kind of stuff. +STEPHANIE: Got it. Yeah, that does sound convenient. As you were talking about this, I was thinking about how if I were in the position of trying to decide how to make that integration happen, the idea of building it would seem kind of scary, especially if it's something that I don't have a lot of expertise in. +JOËL: Yeah, so this was really interesting. In the beginning of the project, I looked into a little bit of what goes into building these, and it's fairly simple in terms of the architecture. You just need something that writes data files to typically something like an S3 bucket. And then you can point Snowflake to periodically pull from that bucket, and you write an import script to, you know, parse the columns and write them to the right tables in the structure that you want inside Snowflake. +Where things get tricky is the actual integration on the other end. So, you have some sort of third-party service. And now, how do you sort of, on a timer maybe, pull data from that? And if there are data changes that you're synchronizing, is it just all append-only data? Or are you allowing the third-party service to say, "Hey, I deleted this record, and you should reflect that in Snowflake?" Or maybe dealing with an update. So, all of these things you have to think about, as well as synchronization. +What you end up having to do is you probably boot up some kind of small service and, you know, maybe this is a small Ruby app that you have on Heroku, maybe this is, like, an AWS Lambda kind of thing. And you probably end up running this every so many seconds or so many minutes, do some work, potentially write some files to S3. And there's a lot of edge cases you have to think about to do it properly. And so, not having to think about all of those edge cases becomes really enticing when you're looking to potentially pay a third party to do this for you. +STEPHANIE: Yeah, when you used the words new service, I bristled a little bit [laughs] because I've definitely seen this happen maybe on a bit of a bigger scale for a tool or solution for some need, right? Where some team is formed, or maybe we kind of add some more responsibilities to an existing team to spin up a new service with a new repo with its own pipeline, and it becomes yet another thing to maintain. And I have definitely seen issues with the longevity of that kind of approach. +JOËL: The idea of maintaining a fleet of little services for each of our integrations seemed very unappealing to me, especially given that setting something like this up using the commercial approach probably takes 30 minutes per third-party service. There's no way I'm standing up an app and doing this whole querying every so many minutes, and getting data, and transforming it, and writing it to S3, and addressing all the edge cases in 30 minutes. And it's building something that's robust. +And, you know, maybe if I want to go, like, really low tech, there's something fun I could do with, like, a Zapier hook and just, like, duct tape a few services together and make this, like, a no-code solution. I still don't know that it would have the robustness of the vendor. And I don't think that I could do it in the same amount of time. +STEPHANIE: Yeah. I like the keyword robustness here because, at first, you were saying, like, you know, this looked relatively small in scope, right? The code that you had to write. But introducing all of the variables of things that could go wrong [laughs] beyond the custom part that you actually care about seemed quite cumbersome. +JOËL: I think there's also, at this point, a lot of really interesting prioritization questions. There are money questions, but there are also time questions you have to think about. So, how much dev time do we want to devote upfront to building out these integrations? And if you're trying to move fast and get a proof of concept out, or even get, like, an MVP out in front of customers, it might be worth paying more money upfront to a third-party vendor because it allows you to ship something this week rather than next month. +STEPHANIE: Yeah. The "How soon do you need it?" is a very good question to ask. Another one that I have learned to include in my arsenal of, you know, evaluating this kind of stuff comes from a thoughtbot blog by Josh Clayton, where he, you know, talks about the build versus buy problem. And his takeaway is that you should buy when your business is not dependent on it. +JOËL: When it's not part of, like, the core, like, value-add that your business is doing. Why spend developer time on something that's not, like, the core thing that your product is when you can pay someone else to do it for you? And like we said earlier, a lot of that time ends up being sunk into edge cases and robustness and things like that to the point where now you have to build an expertise in a, like, secondary thing that your business doesn't really care about. +STEPHANIE: Yeah, absolutely. I think this is also perhaps where very clear business goals or a vision would come in handy as well. Because if you're considering building something that doesn't quite support that vision, then it will likely end up continuing to be deprioritized over the long term until it becomes this thing that no one is accountable for maintaining and caring for. +And just causes a lot of, honestly, morale issues is what I've seen when some service that was spun up to try to solve a particular problem is kind of on its last legs and has been really neglected, and no one wants to work on it. But it ends up causing issues for the rest of the development team. But then they're also really focused on initiatives that actually do provide the business value. That is a really hard balancing act that I've seen teams struggle with. +JOËL: Earlier this year, we were talking about the book Sustainable Rails. And it really hammers home the idea of a carrying cost for the code, and I think that's exactly what we're talking about here. And that carrying cost can be time and money. But I like that you also mentioned the morale effects. You know, that's a carrying cost that just sort of depresses the productivity of your team when morale is low. +STEPHANIE: Yeah, absolutely. I'm curious if we could discuss some of the carrying costs of buying a solution and where you've seen that become tricky. +JOËL: The first thing to look at is the literal cost, the money aspect of things. And I think it's a really interesting situation for the business models for these types of Snowflake connectors because they typically charge by the amount of data that you're transmitting, so per row of data that you're transmitting. And so, that cost will fluctuate depending on whether the third-party service you're integrating with is, like, really chatty or not. +When you contrast that to building, building typically has a relatively fixed cost. It's a big upfront cost, and then there's some maintenance cost to go with it. So, if I'm building some kind of integration for, let's say, Shopify, then there's the cost I need to build up front to integrate that. And if that takes me, I don't know, a week or two weeks, or however long it is, you know, that's a pretty big chunk of time. And my time is money. +And so, you can actually do the math and say, "Well, if we know that we're getting so many rows per day at this rate from the commercial vendor, how many weeks do we have to pay for the commercial one before we break even and it becomes more expensive than building it upfront, just in terms of my time?" And sometimes you do that math, and you're like, wow, you know, we could be going on this commercial thing for, like, two years before we break even. In that case, from a purely financial point of view, it's probably worth paying for that connector. +And so, now it becomes really interesting. You say, okay, well, which are the connectors that we have that are low volume, and which are the ones that are high volume? Because each of them is going to have a different break-even point. The ones that you break even after, you know, three or four weeks might be the ones that become more interesting to have a conversation about building. Whereas some of the others, it's clearly not worth our time to build it ourselves. +STEPHANIE: The way you described this problem was really interesting to me because it almost sounds like you found the solution somewhere in the middle, potentially, where, you know, you may try building the ones that are highest priority, and you end up learning a lot from that experience, right? That could make it easier or at least, like, set you up to consider doing that moving forward in the future if you find, like, that is what is valuable. +But it's interesting to me that you kind of have the best of both worlds of, like, getting the commercial solutions now for the things that are lower value and then doing what you can to get the most out of building a solution. +JOËL: Yeah. So, my final recommendation ended up being, let's go all commercial for now. And then, once we've built out something, and because speed is also an issue here, once we've built out something and it's out with customers, and we're starting to see value from this, then we can start looking at how much are we paying per week for each of these connectors? And is it worth maybe going back and building our own for some of these higher-volume connectors? But starting with the commercial one for everything. +STEPHANIE: Yeah, I actually think that's generally a pretty good path forward because then you are also learning about how you use the commercial solution and, you know, which features of it are critical so that if you do eventually find yourselves, like, maybe considering a shift to building in-house, like, you could start with a more clear MVP, right? Because you know how your team is using an existing product and can focus on the parts that your business are dependent on. +JOËL: Yeah, it's that classic iterative development style. I think here it's also kind of inspired by a strategy I typically use for performance, which is make it work before you try to make it fast. And, actually, make it work, then profile, then measure, find the hotspots, and then focus on making those things fast. So, in this case, instead of speed, we're talking about money. So, it's make it work, then profile, find the parts that are expensive, and make the trade-off of, like, okay, is it worth investing into making that part less expensive in terms of resources? +STEPHANIE: I like that as a framework a lot. +JOËL: A lot of what we do as programmers is optimization, right? And sometimes, we're optimizing for execution time. Sometimes we're optimizing for memory cost, and sometimes we're optimizing for dollars. +STEPHANIE: Yeah, that's really interesting because, with the buy solution, you know very clearly, like, how much the thing will cost. Whereas I've definitely seen teams go down the building route, and it always takes longer than expected [laughs], and that is money, right? In terms of the developer's time, for sure. +JOËL: Yeah, definitely, like, add some kind of multiplier when you're budgeting out that build alternative because, quite likely, there are some edge cases that you haven't thought about that the commercial partner has, and you will have to spend more time on that than you expected. +STEPHANIE: Yeah, in addition to whatever opportunity cost of not working on something that is driving revenue for the business right now. +JOËL: Exactly. +STEPHANIE: So, the direction of this conversation ended up going kind of towards, like, what is best for the team at, like, a product and company level. But I think that we make these decisions a lot more frequently, even when it comes to whether we pull in a gem or, you know, use an open-source tool or not. And I would be really interested in discussing more of that in another episode. +JOËL: Yeah. That gets into some controversial takes, right? It's the evergreen topic of: do we build it ourselves, or do we pull in some kind of third-party package? +STEPHANIE: Something for the future to look forward to. On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël has been fighting a frustrating bug where he's integrating with a third-party database, and some queries just crash. Stephanie shares her own debugging story about a leaky stub that caused flaky tests.

+ +

Additionally, they discuss the build vs. buy decision when integrating with third-party systems. They consider the time and cost implications of building their own integration versus using off-the-shelf components and conclude that the decision often depends on the specific needs and priorities of the project, including how quickly a solution is needed and whether the integration is core to the business's value proposition.

+ +
+ + + +

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: My world has been kind of frustrating recently. I've been fighting a really frustrating bug where I'm integrating with a third-party database. And there are queries that just straight-up crash. Any query that instantiates an instance of an ActiveRecord object will just straight-up fail. And that's because before, we make the actual query, almost like a preflight query that fetches the schema of the database, particularly the list of tables that the database has, and there's something in this schema that the code doesn't like, and everything just crashes.

+ +

Specifically, I'm using an ODBC connection. I forget exactly what the acronym stands for, Open Database connection, maybe? Which is a standard put up by Microsoft. The way I'm integrating it via Ruby is there's a gem that's a C extension. And somewhere deep in the C extension, this whole thing is crashing. So, I've had to sort of dust off some C a little bit to look through. And it's not super clear exactly why things are crashing. So, I've spent several days trying to figure out what's going on there. And it's been really cryptic.

+ +

STEPHANIE: Yeah, that does sound frustrating. And it seems like maybe you are a little bit out of your depth in terms of your usual tools for figuring out a bug are not so helpful here.

+ +

JOËL: Yeah, yeah. It's a lot harder to just go through and put in a print or a debug statement because now I have to recompile some C. And, you know, you can mess around with some things by passing different flags. But it is a lot more difficult than just doing, like, a bundle open and binding to RB in the code.

+ +

My ultimate solution was asking for help. So, I got another thoughtboter to help me, and we paired on it. We got to a solution that worked. And then, right before I went to deploy this change, because this was breaking on the staging website, I refreshed the website just to make sure that everything was breaking before I pushed the fix to see that everything is working. This is a habit I've picked up from test-driven development. You always want to see your test break before you see it succeed.

+ +

And this is a situation where this habit paid off because the website was just working. My changes were not deployed. It just started working again. Now it's gotten me just completely questioning whether my solution fixes anything. The difficulty is because I am integrating [inaudible 03:20] third-party database; it's non-deterministic. The schema on there is changing rather frequently.

+ +

I think the reason things are crashing is because there's some kind of bad data or data that the ODBC adapter doesn't like in this third-party system. But it just got introduced one day; everything started breaking, and then somehow it got removed, and everything is working again without any input or code changes on my end. So, now I don't trust my fix.

+ +

STEPHANIE: Oh no. Yeah, I would struggle with that because your reality has come crashing down, [laughs] or how you understood reality. That's tough. Where do you think you'll go from here? If it's no longer really an issue in this current state of the schema, is it worth pursuing further at this time?

+ +

JOËL: So, that's interesting because it turns into a prioritization problem. And for this particular project, with the deadlines that we have, we've decided it's not worth it. I've opened up a PR with my fix, with some pretty in-depth documentation for why I thought that was the fix and what I think the underlying problem is. If this shows up again in the next few days, I'll have that PR that I can pull in and see if it fixes things, and if it doesn't, I'll probably just close that PR, but it'll be available for us if we ever run into this again.

+ +

I've also looked at a few potential mitigating situations. Part of the problem is that this is a, like, massive system. The Rails app that I'm using really doesn't need to deal with this massive database. I think there's, you know, almost 1,000 tables, and I really only care about a subset of tables in, like, one underlying schema. And so, I think by reducing the permissions of my database user to only those tables that I care about, there's a lower chance of me triggering something like this.

+ +

STEPHANIE: Interesting. What you mentioned about, you know, having that PR continue to exist will be really helpful for future folks who might come across the same problem, right? Because then they can see, like, all of the research and investigation you've already done. And you may have already done this, but if you do think it's a schema issue, I'm curious about whether the snapshot of the schema could be captured from when it was failing to when it has magically gotten fixed. And I wonder if there may be some clues there for some future investigator.

+ +

JOËL: Yeah. I'm not sure what our backup situation is because this is a third-party system, so I'd have to figure out what things are like in the admin interface there. But yeah, if there is some kind of auditing, or snapshots, or backups, or something there, and I have rough, you know, if I know it's within a 24-hour period, maybe there's something there that would tell me what's happening.

+ +

My best guess is that there's some string that is longer than expected or maybe being marked as a CHAR when it should be a VARCHAR, or maybe something that's not a non-UTF-8 encoded character, or something weird like that. So, I never know exactly what was wrong in the schema. There's some weird string thing happening that's causing the Ruby adapter to blow up.

+ +

STEPHANIE: That also feels so unsatisfying [laughs] for you. I could imagine.

+ +

JOËL: Yeah, there's no, like, clean resolution, right? It's a, well, the bug is gone for now. We're trying to make it less likely for it to pop up again in the future. I'm trying to leave some documentation for the next person who's going to come along, and I'm moving forward, fingers crossed. Is that something you've ever had to do on one of your projects?

+ +

STEPHANIE: Given up? Yes. [laughter] I think I have definitely had to learn how to timebox debugging and have some action items for when I just can't figure it out. And, you know, like we mentioned, leaving some documentation for the next person to pick up, adding some additional logging so that maybe we can get more clues next time. But, you know, realizing that I do have to move on and that's the best that I can do is really challenging.

+ +

JOËL: So, you used two words here to describe the situation: one was giving up, and the other one was timebox. I think I really like the idea of describing this as timeboxing. Giving up feels kind of like, defeatist. You know, there's so many things that we can do with our time, and we really have to be strategic with how we prioritize. So, I like the idea of describing this as a timeboxing situation.

+ +

STEPHANIE: Yeah, I agree. Maybe I should celebrate every time that I successfully timebox something [laughs] according to how I planned to. [laughs]

+ +

JOËL: There's always room to extend the timebox, right?

+ +

STEPHANIE: [laughs] It's funny you bring up a debugging mystery because I have one of my own to share today. And I do have to say that it ended up being resolved, [chuckles] so it was a win in my book. But I will call this the case of the leaky stub.

+ +

JOËL: That sounds slightly scary.

+ +

STEPHANIE: It really was. The premise of what we were trying to figure out here was that we were having some flaky tests that were failing with a runtime error, so that was already kind of interesting. But it was quickly determined it was flaky because of the tests running in a certain order, so--

+ +

JOËL: Classic.

+ +

STEPHANIE: Right. So, I knew something was happening, and any tests that came after it were running into this error. And I was taking a look, and I figured out how to recreate it. And we even isolated to the test itself that was running before everything else, that would then cause some problems. And so, looking into this test, I saw that it was stubbing the find method on an ActiveRecord model.

+ +

JOËL: Interesting.

+ +

STEPHANIE: Yeah. And the stubbed value that we were choosing to return ended up being referenced in the tests that followed. So, that was really strange to me because it went against everything I understood about how RSpec cleans up stubs between tests, right?

+ +

JOËL: Yeah, that is really strange.

+ +

STEPHANIE: Yeah, and I knew that it was referencing the stub value because we had set a really custom, like, ID value to it. So, when I was seeing this exact ID value showing up in a test that seemed totally unrelated, that was kind of a clue that there was some leakage happening.

+ +

JOËL: So, what did you do next?

+ +

STEPHANIE: The next discovery was that the error was actually raised in the factory setup for the failing tests and not even getting to running the examples at all. So, that was really strange. And digging into the factories was also its own adventure because there was a lot of complexity in the factories. A lot of them used hooks as well that then called some application code. And it was a wild goose chase.

+ +

But ultimately, I realized that in the factory setup, we were calling some application code for that model where we had stubbed the find, and it had used the find method to memoize a class instance variable.

+ +

JOËL: Oh no. I can see where this is going.

+ +

STEPHANIE: Yeah. So, at some point, our model.find() returned our, you know, stub value that we had wanted in the previous test. And it got cached and just continued to leak into everything else that eventually would try to call that memoized method when it really should have tried to do that look-up for a separate record.

+ +

JOËL: And class instance variables will persist between tests as long as they're on the same thread, right?

+ +

STEPHANIE: Yeah, as far as I understand it.

+ +

JOËL: That sounds like a really frustrating journey. And then that moment when you see the class instance variable, and you're like, oh no, I can't believe this is happening.

+ +

STEPHANIE: Right? It was a real recipe for disaster, I think, where we had some, you know, really complicated factories. We had some sneaky caching issues, and this, you know, totally seemingly random runtime error that was being raised. And it was a real wild goose chase because there was not a lot of directness in going down the debugging path. I feel like I went around all over the codebase to get to the root of it. And, in the end, you know, we were trying to come up with some takeaways.

+ +

And what was unfortunate was that you know, like, normally, stubbing find can be okay if you are, you know, really wanting to make sure that you are returning your mocked value that you may have, like, stubbed some other stuff on in your test. But because of all this, we were like, well, should we just not stub find on this really particular model? And that didn't seem particularly sustainable to make as a takeaway for other developers who want to avoid this problem.

+ +

So, in the end, I think we scoped the stub to be a little more specific with the arguments that we wanted to target. And that was the way that we went forward with the particular flaky test at hand.

+ +

JOËL: It sounds like the root cause of the problem was not so much the stub as it was the fact that this value is getting cached at the class level. Is that right?

+ +

STEPHANIE: Yes and no. It seems like a real pain for running the tests. But I'm assuming that it was done for a good reason in production, maybe, maybe not. To be fair, I think we didn't need to cache it at all because it's calling a find, which is, you know, should be pretty quick and doesn't need to be cached. But who knows? It's hard to tell. It was really old code. And I think we were feeling also a little nervous to adjust something that we weren't sure what the impact would be.

+ +

JOËL: I'm always really skeptical of caching. Caching has its place. But I think a lot of developers are a little too happy to introduce one, especially doing it preemptively that, oh well, we might need a cache here, so why not? Let's add that. Or even sometimes, just as a blind solution to any kind of slowness, oh, the site is slow; let's throw a cache here and hope for the best.

+ +

And the, like, bedrock, like, rule zero of any kind of performance tuning is you've got to measure before and after and make sure that the change that you introduce actually makes things better. And then, also, is it better enough speed-wise that you're willing to pay any kind of costs associated to maintaining the code now that it's more complex? And a lot of caches can have some higher carrying costs.

+ +

STEPHANIE: Yeah, that's a great point. This debugging mystery an example of one of them.

+ +

JOËL: How long did it take you to figure out the solution here?

+ +

STEPHANIE: So, like you, I actually was on a bit of the incorrect path for a little while. And it was only because this issue affected a different flaky test that someone else was investigating that they were able to connect the dots and be like, I think these, you know, two issues are related. And they were the ones who ultimately were able to point us out to the offending test if you will. So, you know, it took me a few days. And I imagine it took the other developer a few days. So, our combined effort was, like, over a week.

+ +

JOËL: Yep. So, for all our listeners out there, you just heard that Stephanie and I [laughs] both went on multi-day debugging journeys. That happens to everyone. Just because we've been doing this job for years doesn't mean that every bug is, like, a thing that we figure out immediately.

+ +

So, separately from this bug that I've been working on, a big issue that's been front of mind for me on this project has been the classic build versus buy decision. Because we're integrating with a third-party system, we have to look at either building our own integration or trying to use some off-the-shelf components. And there's a few different levels of this.

+ +

There are some parts where you can actually, like, literally buy an integration and think through some of the decisions there. And then there's some situations where maybe there's an open-source component that we can use. And there's always trade-offs with both the commercial and the open-source situation. And we have to decide, are we willing to use this, or do we want to build our own? And those have been some really interesting discussions to have.

+ +

STEPHANIE: Yeah. I think you actually expanded this decision-making problem into a build versus buy versus open source because they are kind of, you know, really different solutions with different outcomes in terms of, you know, maintenance and dependencies, right? And that all have, like, a little bit of a different way to engage with them.

+ +

JOËL: Interesting. I think I tend to think of the buy category, including both like commercial off-the-shelf software and also open-source off-the-shelf software, things that we wouldn't build custom for ourselves but that are third-party components that we can pull in.

+ +

STEPHANIE: Yeah, that's interesting because I had a bit of a different mental model because, in my head, when you're buying a commercial solution, you, you know, are maybe losing out on some opportunities for customization or even, like, forking it on your own. So, with an open-source solution, there could be an aspect of making it work for you. Whereas for a commercial solution, you really become dependent on that other company and whether they are willing to cater [laughs] to your needs or not.

+ +

JOËL: That's fair. For something that's closed-source where you don't actually have access to the code, say it's more of a software as a service situation, then, yeah, you're kind of locked in and hoping that they can provide the needs that you have. On the flip side, you are generally paying for some level of support. The quality of that varies sometimes from one vendor to another. But if something goes wrong, usually, there's someone you can email, someone you can call, and they will tell you how to fix the problem, or they will fix it on their end.

+ +

STEPHANIE: For the purposes of this conversation, should we talk about the differences, you know, building yourself or leaning on an existing built-out solution for you?

+ +

JOËL: The project I'm working on is integrating with a Snowflake data warehouse, which is an external place that stores data accessible through something SQL-like. And one of the things that's attractive about this is that you can pull in data from a variety of different sources, transform it, and have it all stored in a kind of standardized structure that you can then integrate with. So, for pulling data in, you can build your own sort of ingestion pipeline, if you want, with code, and their APIs, and things.

+ +

But there are also third-party vendors that will give you kind of off-the-shelf components that you can use for a lot of popular other data sources that you might want to pull. So, you're saying; I want to pull from this external service. They've probably got a pre-built connector for it. They can also do things like pull from an arbitrary Postgres database on some other server if that's something you have access to.

+ +

It becomes really attractive because all you need to do is create an account on this website, plug in a few, like, API keys and URLs. And, all of a sudden, data is just flowing from one third-party system into your Snowflake data Warehouse, and it all just kind of works. And you don't have to bother with APIs, or ODBC, or any of that kind of stuff.

+ +

STEPHANIE: Got it. Yeah, that does sound convenient. As you were talking about this, I was thinking about how if I were in the position of trying to decide how to make that integration happen, the idea of building it would seem kind of scary, especially if it's something that I don't have a lot of expertise in.

+ +

JOËL: Yeah, so this was really interesting. In the beginning of the project, I looked into a little bit of what goes into building these, and it's fairly simple in terms of the architecture. You just need something that writes data files to typically something like an S3 bucket. And then you can point Snowflake to periodically pull from that bucket, and you write an import script to, you know, parse the columns and write them to the right tables in the structure that you want inside Snowflake.

+ +

Where things get tricky is the actual integration on the other end. So, you have some sort of third-party service. And now, how do you sort of, on a timer maybe, pull data from that? And if there are data changes that you're synchronizing, is it just all append-only data? Or are you allowing the third-party service to say, "Hey, I deleted this record, and you should reflect that in Snowflake?" Or maybe dealing with an update. So, all of these things you have to think about, as well as synchronization.

+ +

What you end up having to do is you probably boot up some kind of small service and, you know, maybe this is a small Ruby app that you have on Heroku, maybe this is, like, an AWS Lambda kind of thing. And you probably end up running this every so many seconds or so many minutes, do some work, potentially write some files to S3. And there's a lot of edge cases you have to think about to do it properly. And so, not having to think about all of those edge cases becomes really enticing when you're looking to potentially pay a third party to do this for you.

+ +

STEPHANIE: Yeah, when you used the words new service, I bristled a little bit [laughs] because I've definitely seen this happen maybe on a bit of a bigger scale for a tool or solution for some need, right? Where some team is formed, or maybe we kind of add some more responsibilities to an existing team to spin up a new service with a new repo with its own pipeline, and it becomes yet another thing to maintain. And I have definitely seen issues with the longevity of that kind of approach.

+ +

JOËL: The idea of maintaining a fleet of little services for each of our integrations seemed very unappealing to me, especially given that setting something like this up using the commercial approach probably takes 30 minutes per third-party service. There's no way I'm standing up an app and doing this whole querying every so many minutes, and getting data, and transforming it, and writing it to S3, and addressing all the edge cases in 30 minutes. And it's building something that's robust.

+ +

And, you know, maybe if I want to go, like, really low tech, there's something fun I could do with, like, a Zapier hook and just, like, duct tape a few services together and make this, like, a no-code solution. I still don't know that it would have the robustness of the vendor. And I don't think that I could do it in the same amount of time.

+ +

STEPHANIE: Yeah. I like the keyword robustness here because, at first, you were saying, like, you know, this looked relatively small in scope, right? The code that you had to write. But introducing all of the variables of things that could go wrong [laughs] beyond the custom part that you actually care about seemed quite cumbersome.

+ +

JOËL: I think there's also, at this point, a lot of really interesting prioritization questions. There are money questions, but there are also time questions you have to think about. So, how much dev time do we want to devote upfront to building out these integrations? And if you're trying to move fast and get a proof of concept out, or even get, like, an MVP out in front of customers, it might be worth paying more money upfront to a third-party vendor because it allows you to ship something this week rather than next month.

+ +

STEPHANIE: Yeah. The "How soon do you need it?" is a very good question to ask. Another one that I have learned to include in my arsenal of, you know, evaluating this kind of stuff comes from a thoughtbot blog by Josh Clayton, where he, you know, talks about the build versus buy problem. And his takeaway is that you should buy when your business is not dependent on it.

+ +

JOËL: When it's not part of, like, the core, like, value-add that your business is doing. Why spend developer time on something that's not, like, the core thing that your product is when you can pay someone else to do it for you? And like we said earlier, a lot of that time ends up being sunk into edge cases and robustness and things like that to the point where now you have to build an expertise in a, like, secondary thing that your business doesn't really care about.

+ +

STEPHANIE: Yeah, absolutely. I think this is also perhaps where very clear business goals or a vision would come in handy as well. Because if you're considering building something that doesn't quite support that vision, then it will likely end up continuing to be deprioritized over the long term until it becomes this thing that no one is accountable for maintaining and caring for.

+ +

And just causes a lot of, honestly, morale issues is what I've seen when some service that was spun up to try to solve a particular problem is kind of on its last legs and has been really neglected, and no one wants to work on it. But it ends up causing issues for the rest of the development team. But then they're also really focused on initiatives that actually do provide the business value. That is a really hard balancing act that I've seen teams struggle with.

+ +

JOËL: Earlier this year, we were talking about the book Sustainable Rails. And it really hammers home the idea of a carrying cost for the code, and I think that's exactly what we're talking about here. And that carrying cost can be time and money. But I like that you also mentioned the morale effects. You know, that's a carrying cost that just sort of depresses the productivity of your team when morale is low.

+ +

STEPHANIE: Yeah, absolutely. I'm curious if we could discuss some of the carrying costs of buying a solution and where you've seen that become tricky.

+ +

JOËL: The first thing to look at is the literal cost, the money aspect of things. And I think it's a really interesting situation for the business models for these types of Snowflake connectors because they typically charge by the amount of data that you're transmitting, so per row of data that you're transmitting. And so, that cost will fluctuate depending on whether the third-party service you're integrating with is, like, really chatty or not.

+ +

When you contrast that to building, building typically has a relatively fixed cost. It's a big upfront cost, and then there's some maintenance cost to go with it. So, if I'm building some kind of integration for, let's say, Shopify, then there's the cost I need to build up front to integrate that. And if that takes me, I don't know, a week or two weeks, or however long it is, you know, that's a pretty big chunk of time. And my time is money.

+ +

And so, you can actually do the math and say, "Well, if we know that we're getting so many rows per day at this rate from the commercial vendor, how many weeks do we have to pay for the commercial one before we break even and it becomes more expensive than building it upfront, just in terms of my time?" And sometimes you do that math, and you're like, wow, you know, we could be going on this commercial thing for, like, two years before we break even. In that case, from a purely financial point of view, it's probably worth paying for that connector.

+ +

And so, now it becomes really interesting. You say, okay, well, which are the connectors that we have that are low volume, and which are the ones that are high volume? Because each of them is going to have a different break-even point. The ones that you break even after, you know, three or four weeks might be the ones that become more interesting to have a conversation about building. Whereas some of the others, it's clearly not worth our time to build it ourselves.

+ +

STEPHANIE: The way you described this problem was really interesting to me because it almost sounds like you found the solution somewhere in the middle, potentially, where, you know, you may try building the ones that are highest priority, and you end up learning a lot from that experience, right? That could make it easier or at least, like, set you up to consider doing that moving forward in the future if you find, like, that is what is valuable.

+ +

But it's interesting to me that you kind of have the best of both worlds of, like, getting the commercial solutions now for the things that are lower value and then doing what you can to get the most out of building a solution.

+ +

JOËL: Yeah. So, my final recommendation ended up being, let's go all commercial for now. And then, once we've built out something, and because speed is also an issue here, once we've built out something and it's out with customers, and we're starting to see value from this, then we can start looking at how much are we paying per week for each of these connectors? And is it worth maybe going back and building our own for some of these higher-volume connectors? But starting with the commercial one for everything.

+ +

STEPHANIE: Yeah, I actually think that's generally a pretty good path forward because then you are also learning about how you use the commercial solution and, you know, which features of it are critical so that if you do eventually find yourselves, like, maybe considering a shift to building in-house, like, you could start with a more clear MVP, right? Because you know how your team is using an existing product and can focus on the parts that your business are dependent on.

+ +

JOËL: Yeah, it's that classic iterative development style. I think here it's also kind of inspired by a strategy I typically use for performance, which is make it work before you try to make it fast. And, actually, make it work, then profile, then measure, find the hotspots, and then focus on making those things fast. So, in this case, instead of speed, we're talking about money. So, it's make it work, then profile, find the parts that are expensive, and make the trade-off of, like, okay, is it worth investing into making that part less expensive in terms of resources?

+ +

STEPHANIE: I like that as a framework a lot.

+ +

JOËL: A lot of what we do as programmers is optimization, right? And sometimes, we're optimizing for execution time. Sometimes we're optimizing for memory cost, and sometimes we're optimizing for dollars.

+ +

STEPHANIE: Yeah, that's really interesting because, with the buy solution, you know very clearly, like, how much the thing will cost. Whereas I've definitely seen teams go down the building route, and it always takes longer than expected [laughs], and that is money, right? In terms of the developer's time, for sure.

+ +

JOËL: Yeah, definitely, like, add some kind of multiplier when you're budgeting out that build alternative because, quite likely, there are some edge cases that you haven't thought about that the commercial partner has, and you will have to spend more time on that than you expected.

+ +

STEPHANIE: Yeah, in addition to whatever opportunity cost of not working on something that is driving revenue for the business right now.

+ +

JOËL: Exactly.

+ +

STEPHANIE: So, the direction of this conversation ended up going kind of towards, like, what is best for the team at, like, a product and company level. But I think that we make these decisions a lot more frequently, even when it comes to whether we pull in a gem or, you know, use an open-source tool or not. And I would be really interested in discussing more of that in another episode.

+ +

JOËL: Yeah. That gets into some controversial takes, right? It's the evergreen topic of: do we build it ourselves, or do we pull in some kind of third-party package?

+ +

STEPHANIE: Something for the future to look forward to. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Joël has been fighting a frustrating bug where he's integrating with a third-party database, and some queries just crash. Stephanie shares her own debugging story about a leaky stub that caused flaky tests.

+ +

Additionally, they discuss the build vs. buy decision when integrating with third-party systems. They consider the time and cost implications of building their own integration versus using off-the-shelf components and conclude that the decision often depends on the specific needs and priorities of the project, including how quickly a solution is needed and whether the integration is core to the business's value proposition.

+ +
+ + + +

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: My world has been kind of frustrating recently. I've been fighting a really frustrating bug where I'm integrating with a third-party database. And there are queries that just straight-up crash. Any query that instantiates an instance of an ActiveRecord object will just straight-up fail. And that's because before, we make the actual query, almost like a preflight query that fetches the schema of the database, particularly the list of tables that the database has, and there's something in this schema that the code doesn't like, and everything just crashes.

+ +

Specifically, I'm using an ODBC connection. I forget exactly what the acronym stands for, Open Database connection, maybe? Which is a standard put up by Microsoft. The way I'm integrating it via Ruby is there's a gem that's a C extension. And somewhere deep in the C extension, this whole thing is crashing. So, I've had to sort of dust off some C a little bit to look through. And it's not super clear exactly why things are crashing. So, I've spent several days trying to figure out what's going on there. And it's been really cryptic.

+ +

STEPHANIE: Yeah, that does sound frustrating. And it seems like maybe you are a little bit out of your depth in terms of your usual tools for figuring out a bug are not so helpful here.

+ +

JOËL: Yeah, yeah. It's a lot harder to just go through and put in a print or a debug statement because now I have to recompile some C. And, you know, you can mess around with some things by passing different flags. But it is a lot more difficult than just doing, like, a bundle open and binding to RB in the code.

+ +

My ultimate solution was asking for help. So, I got another thoughtboter to help me, and we paired on it. We got to a solution that worked. And then, right before I went to deploy this change, because this was breaking on the staging website, I refreshed the website just to make sure that everything was breaking before I pushed the fix to see that everything is working. This is a habit I've picked up from test-driven development. You always want to see your test break before you see it succeed.

+ +

And this is a situation where this habit paid off because the website was just working. My changes were not deployed. It just started working again. Now it's gotten me just completely questioning whether my solution fixes anything. The difficulty is because I am integrating [inaudible 03:20] third-party database; it's non-deterministic. The schema on there is changing rather frequently.

+ +

I think the reason things are crashing is because there's some kind of bad data or data that the ODBC adapter doesn't like in this third-party system. But it just got introduced one day; everything started breaking, and then somehow it got removed, and everything is working again without any input or code changes on my end. So, now I don't trust my fix.

+ +

STEPHANIE: Oh no. Yeah, I would struggle with that because your reality has come crashing down, [laughs] or how you understood reality. That's tough. Where do you think you'll go from here? If it's no longer really an issue in this current state of the schema, is it worth pursuing further at this time?

+ +

JOËL: So, that's interesting because it turns into a prioritization problem. And for this particular project, with the deadlines that we have, we've decided it's not worth it. I've opened up a PR with my fix, with some pretty in-depth documentation for why I thought that was the fix and what I think the underlying problem is. If this shows up again in the next few days, I'll have that PR that I can pull in and see if it fixes things, and if it doesn't, I'll probably just close that PR, but it'll be available for us if we ever run into this again.

+ +

I've also looked at a few potential mitigating situations. Part of the problem is that this is a, like, massive system. The Rails app that I'm using really doesn't need to deal with this massive database. I think there's, you know, almost 1,000 tables, and I really only care about a subset of tables in, like, one underlying schema. And so, I think by reducing the permissions of my database user to only those tables that I care about, there's a lower chance of me triggering something like this.

+ +

STEPHANIE: Interesting. What you mentioned about, you know, having that PR continue to exist will be really helpful for future folks who might come across the same problem, right? Because then they can see, like, all of the research and investigation you've already done. And you may have already done this, but if you do think it's a schema issue, I'm curious about whether the snapshot of the schema could be captured from when it was failing to when it has magically gotten fixed. And I wonder if there may be some clues there for some future investigator.

+ +

JOËL: Yeah. I'm not sure what our backup situation is because this is a third-party system, so I'd have to figure out what things are like in the admin interface there. But yeah, if there is some kind of auditing, or snapshots, or backups, or something there, and I have rough, you know, if I know it's within a 24-hour period, maybe there's something there that would tell me what's happening.

+ +

My best guess is that there's some string that is longer than expected or maybe being marked as a CHAR when it should be a VARCHAR, or maybe something that's not a non-UTF-8 encoded character, or something weird like that. So, I never know exactly what was wrong in the schema. There's some weird string thing happening that's causing the Ruby adapter to blow up.

+ +

STEPHANIE: That also feels so unsatisfying [laughs] for you. I could imagine.

+ +

JOËL: Yeah, there's no, like, clean resolution, right? It's a, well, the bug is gone for now. We're trying to make it less likely for it to pop up again in the future. I'm trying to leave some documentation for the next person who's going to come along, and I'm moving forward, fingers crossed. Is that something you've ever had to do on one of your projects?

+ +

STEPHANIE: Given up? Yes. [laughter] I think I have definitely had to learn how to timebox debugging and have some action items for when I just can't figure it out. And, you know, like we mentioned, leaving some documentation for the next person to pick up, adding some additional logging so that maybe we can get more clues next time. But, you know, realizing that I do have to move on and that's the best that I can do is really challenging.

+ +

JOËL: So, you used two words here to describe the situation: one was giving up, and the other one was timebox. I think I really like the idea of describing this as timeboxing. Giving up feels kind of like, defeatist. You know, there's so many things that we can do with our time, and we really have to be strategic with how we prioritize. So, I like the idea of describing this as a timeboxing situation.

+ +

STEPHANIE: Yeah, I agree. Maybe I should celebrate every time that I successfully timebox something [laughs] according to how I planned to. [laughs]

+ +

JOËL: There's always room to extend the timebox, right?

+ +

STEPHANIE: [laughs] It's funny you bring up a debugging mystery because I have one of my own to share today. And I do have to say that it ended up being resolved, [chuckles] so it was a win in my book. But I will call this the case of the leaky stub.

+ +

JOËL: That sounds slightly scary.

+ +

STEPHANIE: It really was. The premise of what we were trying to figure out here was that we were having some flaky tests that were failing with a runtime error, so that was already kind of interesting. But it was quickly determined it was flaky because of the tests running in a certain order, so--

+ +

JOËL: Classic.

+ +

STEPHANIE: Right. So, I knew something was happening, and any tests that came after it were running into this error. And I was taking a look, and I figured out how to recreate it. And we even isolated to the test itself that was running before everything else, that would then cause some problems. And so, looking into this test, I saw that it was stubbing the find method on an ActiveRecord model.

+ +

JOËL: Interesting.

+ +

STEPHANIE: Yeah. And the stubbed value that we were choosing to return ended up being referenced in the tests that followed. So, that was really strange to me because it went against everything I understood about how RSpec cleans up stubs between tests, right?

+ +

JOËL: Yeah, that is really strange.

+ +

STEPHANIE: Yeah, and I knew that it was referencing the stub value because we had set a really custom, like, ID value to it. So, when I was seeing this exact ID value showing up in a test that seemed totally unrelated, that was kind of a clue that there was some leakage happening.

+ +

JOËL: So, what did you do next?

+ +

STEPHANIE: The next discovery was that the error was actually raised in the factory setup for the failing tests and not even getting to running the examples at all. So, that was really strange. And digging into the factories was also its own adventure because there was a lot of complexity in the factories. A lot of them used hooks as well that then called some application code. And it was a wild goose chase.

+ +

But ultimately, I realized that in the factory setup, we were calling some application code for that model where we had stubbed the find, and it had used the find method to memoize a class instance variable.

+ +

JOËL: Oh no. I can see where this is going.

+ +

STEPHANIE: Yeah. So, at some point, our model.find() returned our, you know, stub value that we had wanted in the previous test. And it got cached and just continued to leak into everything else that eventually would try to call that memoized method when it really should have tried to do that look-up for a separate record.

+ +

JOËL: And class instance variables will persist between tests as long as they're on the same thread, right?

+ +

STEPHANIE: Yeah, as far as I understand it.

+ +

JOËL: That sounds like a really frustrating journey. And then that moment when you see the class instance variable, and you're like, oh no, I can't believe this is happening.

+ +

STEPHANIE: Right? It was a real recipe for disaster, I think, where we had some, you know, really complicated factories. We had some sneaky caching issues, and this, you know, totally seemingly random runtime error that was being raised. And it was a real wild goose chase because there was not a lot of directness in going down the debugging path. I feel like I went around all over the codebase to get to the root of it. And, in the end, you know, we were trying to come up with some takeaways.

+ +

And what was unfortunate was that you know, like, normally, stubbing find can be okay if you are, you know, really wanting to make sure that you are returning your mocked value that you may have, like, stubbed some other stuff on in your test. But because of all this, we were like, well, should we just not stub find on this really particular model? And that didn't seem particularly sustainable to make as a takeaway for other developers who want to avoid this problem.

+ +

So, in the end, I think we scoped the stub to be a little more specific with the arguments that we wanted to target. And that was the way that we went forward with the particular flaky test at hand.

+ +

JOËL: It sounds like the root cause of the problem was not so much the stub as it was the fact that this value is getting cached at the class level. Is that right?

+ +

STEPHANIE: Yes and no. It seems like a real pain for running the tests. But I'm assuming that it was done for a good reason in production, maybe, maybe not. To be fair, I think we didn't need to cache it at all because it's calling a find, which is, you know, should be pretty quick and doesn't need to be cached. But who knows? It's hard to tell. It was really old code. And I think we were feeling also a little nervous to adjust something that we weren't sure what the impact would be.

+ +

JOËL: I'm always really skeptical of caching. Caching has its place. But I think a lot of developers are a little too happy to introduce one, especially doing it preemptively that, oh well, we might need a cache here, so why not? Let's add that. Or even sometimes, just as a blind solution to any kind of slowness, oh, the site is slow; let's throw a cache here and hope for the best.

+ +

And the, like, bedrock, like, rule zero of any kind of performance tuning is you've got to measure before and after and make sure that the change that you introduce actually makes things better. And then, also, is it better enough speed-wise that you're willing to pay any kind of costs associated to maintaining the code now that it's more complex? And a lot of caches can have some higher carrying costs.

+ +

STEPHANIE: Yeah, that's a great point. This debugging mystery an example of one of them.

+ +

JOËL: How long did it take you to figure out the solution here?

+ +

STEPHANIE: So, like you, I actually was on a bit of the incorrect path for a little while. And it was only because this issue affected a different flaky test that someone else was investigating that they were able to connect the dots and be like, I think these, you know, two issues are related. And they were the ones who ultimately were able to point us out to the offending test if you will. So, you know, it took me a few days. And I imagine it took the other developer a few days. So, our combined effort was, like, over a week.

+ +

JOËL: Yep. So, for all our listeners out there, you just heard that Stephanie and I [laughs] both went on multi-day debugging journeys. That happens to everyone. Just because we've been doing this job for years doesn't mean that every bug is, like, a thing that we figure out immediately.

+ +

So, separately from this bug that I've been working on, a big issue that's been front of mind for me on this project has been the classic build versus buy decision. Because we're integrating with a third-party system, we have to look at either building our own integration or trying to use some off-the-shelf components. And there's a few different levels of this.

+ +

There are some parts where you can actually, like, literally buy an integration and think through some of the decisions there. And then there's some situations where maybe there's an open-source component that we can use. And there's always trade-offs with both the commercial and the open-source situation. And we have to decide, are we willing to use this, or do we want to build our own? And those have been some really interesting discussions to have.

+ +

STEPHANIE: Yeah. I think you actually expanded this decision-making problem into a build versus buy versus open source because they are kind of, you know, really different solutions with different outcomes in terms of, you know, maintenance and dependencies, right? And that all have, like, a little bit of a different way to engage with them.

+ +

JOËL: Interesting. I think I tend to think of the buy category, including both like commercial off-the-shelf software and also open-source off-the-shelf software, things that we wouldn't build custom for ourselves but that are third-party components that we can pull in.

+ +

STEPHANIE: Yeah, that's interesting because I had a bit of a different mental model because, in my head, when you're buying a commercial solution, you, you know, are maybe losing out on some opportunities for customization or even, like, forking it on your own. So, with an open-source solution, there could be an aspect of making it work for you. Whereas for a commercial solution, you really become dependent on that other company and whether they are willing to cater [laughs] to your needs or not.

+ +

JOËL: That's fair. For something that's closed-source where you don't actually have access to the code, say it's more of a software as a service situation, then, yeah, you're kind of locked in and hoping that they can provide the needs that you have. On the flip side, you are generally paying for some level of support. The quality of that varies sometimes from one vendor to another. But if something goes wrong, usually, there's someone you can email, someone you can call, and they will tell you how to fix the problem, or they will fix it on their end.

+ +

STEPHANIE: For the purposes of this conversation, should we talk about the differences, you know, building yourself or leaning on an existing built-out solution for you?

+ +

JOËL: The project I'm working on is integrating with a Snowflake data warehouse, which is an external place that stores data accessible through something SQL-like. And one of the things that's attractive about this is that you can pull in data from a variety of different sources, transform it, and have it all stored in a kind of standardized structure that you can then integrate with. So, for pulling data in, you can build your own sort of ingestion pipeline, if you want, with code, and their APIs, and things.

+ +

But there are also third-party vendors that will give you kind of off-the-shelf components that you can use for a lot of popular other data sources that you might want to pull. So, you're saying; I want to pull from this external service. They've probably got a pre-built connector for it. They can also do things like pull from an arbitrary Postgres database on some other server if that's something you have access to.

+ +

It becomes really attractive because all you need to do is create an account on this website, plug in a few, like, API keys and URLs. And, all of a sudden, data is just flowing from one third-party system into your Snowflake data Warehouse, and it all just kind of works. And you don't have to bother with APIs, or ODBC, or any of that kind of stuff.

+ +

STEPHANIE: Got it. Yeah, that does sound convenient. As you were talking about this, I was thinking about how if I were in the position of trying to decide how to make that integration happen, the idea of building it would seem kind of scary, especially if it's something that I don't have a lot of expertise in.

+ +

JOËL: Yeah, so this was really interesting. In the beginning of the project, I looked into a little bit of what goes into building these, and it's fairly simple in terms of the architecture. You just need something that writes data files to typically something like an S3 bucket. And then you can point Snowflake to periodically pull from that bucket, and you write an import script to, you know, parse the columns and write them to the right tables in the structure that you want inside Snowflake.

+ +

Where things get tricky is the actual integration on the other end. So, you have some sort of third-party service. And now, how do you sort of, on a timer maybe, pull data from that? And if there are data changes that you're synchronizing, is it just all append-only data? Or are you allowing the third-party service to say, "Hey, I deleted this record, and you should reflect that in Snowflake?" Or maybe dealing with an update. So, all of these things you have to think about, as well as synchronization.

+ +

What you end up having to do is you probably boot up some kind of small service and, you know, maybe this is a small Ruby app that you have on Heroku, maybe this is, like, an AWS Lambda kind of thing. And you probably end up running this every so many seconds or so many minutes, do some work, potentially write some files to S3. And there's a lot of edge cases you have to think about to do it properly. And so, not having to think about all of those edge cases becomes really enticing when you're looking to potentially pay a third party to do this for you.

+ +

STEPHANIE: Yeah, when you used the words new service, I bristled a little bit [laughs] because I've definitely seen this happen maybe on a bit of a bigger scale for a tool or solution for some need, right? Where some team is formed, or maybe we kind of add some more responsibilities to an existing team to spin up a new service with a new repo with its own pipeline, and it becomes yet another thing to maintain. And I have definitely seen issues with the longevity of that kind of approach.

+ +

JOËL: The idea of maintaining a fleet of little services for each of our integrations seemed very unappealing to me, especially given that setting something like this up using the commercial approach probably takes 30 minutes per third-party service. There's no way I'm standing up an app and doing this whole querying every so many minutes, and getting data, and transforming it, and writing it to S3, and addressing all the edge cases in 30 minutes. And it's building something that's robust.

+ +

And, you know, maybe if I want to go, like, really low tech, there's something fun I could do with, like, a Zapier hook and just, like, duct tape a few services together and make this, like, a no-code solution. I still don't know that it would have the robustness of the vendor. And I don't think that I could do it in the same amount of time.

+ +

STEPHANIE: Yeah. I like the keyword robustness here because, at first, you were saying, like, you know, this looked relatively small in scope, right? The code that you had to write. But introducing all of the variables of things that could go wrong [laughs] beyond the custom part that you actually care about seemed quite cumbersome.

+ +

JOËL: I think there's also, at this point, a lot of really interesting prioritization questions. There are money questions, but there are also time questions you have to think about. So, how much dev time do we want to devote upfront to building out these integrations? And if you're trying to move fast and get a proof of concept out, or even get, like, an MVP out in front of customers, it might be worth paying more money upfront to a third-party vendor because it allows you to ship something this week rather than next month.

+ +

STEPHANIE: Yeah. The "How soon do you need it?" is a very good question to ask. Another one that I have learned to include in my arsenal of, you know, evaluating this kind of stuff comes from a thoughtbot blog by Josh Clayton, where he, you know, talks about the build versus buy problem. And his takeaway is that you should buy when your business is not dependent on it.

+ +

JOËL: When it's not part of, like, the core, like, value-add that your business is doing. Why spend developer time on something that's not, like, the core thing that your product is when you can pay someone else to do it for you? And like we said earlier, a lot of that time ends up being sunk into edge cases and robustness and things like that to the point where now you have to build an expertise in a, like, secondary thing that your business doesn't really care about.

+ +

STEPHANIE: Yeah, absolutely. I think this is also perhaps where very clear business goals or a vision would come in handy as well. Because if you're considering building something that doesn't quite support that vision, then it will likely end up continuing to be deprioritized over the long term until it becomes this thing that no one is accountable for maintaining and caring for.

+ +

And just causes a lot of, honestly, morale issues is what I've seen when some service that was spun up to try to solve a particular problem is kind of on its last legs and has been really neglected, and no one wants to work on it. But it ends up causing issues for the rest of the development team. But then they're also really focused on initiatives that actually do provide the business value. That is a really hard balancing act that I've seen teams struggle with.

+ +

JOËL: Earlier this year, we were talking about the book Sustainable Rails. And it really hammers home the idea of a carrying cost for the code, and I think that's exactly what we're talking about here. And that carrying cost can be time and money. But I like that you also mentioned the morale effects. You know, that's a carrying cost that just sort of depresses the productivity of your team when morale is low.

+ +

STEPHANIE: Yeah, absolutely. I'm curious if we could discuss some of the carrying costs of buying a solution and where you've seen that become tricky.

+ +

JOËL: The first thing to look at is the literal cost, the money aspect of things. And I think it's a really interesting situation for the business models for these types of Snowflake connectors because they typically charge by the amount of data that you're transmitting, so per row of data that you're transmitting. And so, that cost will fluctuate depending on whether the third-party service you're integrating with is, like, really chatty or not.

+ +

When you contrast that to building, building typically has a relatively fixed cost. It's a big upfront cost, and then there's some maintenance cost to go with it. So, if I'm building some kind of integration for, let's say, Shopify, then there's the cost I need to build up front to integrate that. And if that takes me, I don't know, a week or two weeks, or however long it is, you know, that's a pretty big chunk of time. And my time is money.

+ +

And so, you can actually do the math and say, "Well, if we know that we're getting so many rows per day at this rate from the commercial vendor, how many weeks do we have to pay for the commercial one before we break even and it becomes more expensive than building it upfront, just in terms of my time?" And sometimes you do that math, and you're like, wow, you know, we could be going on this commercial thing for, like, two years before we break even. In that case, from a purely financial point of view, it's probably worth paying for that connector.

+ +

And so, now it becomes really interesting. You say, okay, well, which are the connectors that we have that are low volume, and which are the ones that are high volume? Because each of them is going to have a different break-even point. The ones that you break even after, you know, three or four weeks might be the ones that become more interesting to have a conversation about building. Whereas some of the others, it's clearly not worth our time to build it ourselves.

+ +

STEPHANIE: The way you described this problem was really interesting to me because it almost sounds like you found the solution somewhere in the middle, potentially, where, you know, you may try building the ones that are highest priority, and you end up learning a lot from that experience, right? That could make it easier or at least, like, set you up to consider doing that moving forward in the future if you find, like, that is what is valuable.

+ +

But it's interesting to me that you kind of have the best of both worlds of, like, getting the commercial solutions now for the things that are lower value and then doing what you can to get the most out of building a solution.

+ +

JOËL: Yeah. So, my final recommendation ended up being, let's go all commercial for now. And then, once we've built out something, and because speed is also an issue here, once we've built out something and it's out with customers, and we're starting to see value from this, then we can start looking at how much are we paying per week for each of these connectors? And is it worth maybe going back and building our own for some of these higher-volume connectors? But starting with the commercial one for everything.

+ +

STEPHANIE: Yeah, I actually think that's generally a pretty good path forward because then you are also learning about how you use the commercial solution and, you know, which features of it are critical so that if you do eventually find yourselves, like, maybe considering a shift to building in-house, like, you could start with a more clear MVP, right? Because you know how your team is using an existing product and can focus on the parts that your business are dependent on.

+ +

JOËL: Yeah, it's that classic iterative development style. I think here it's also kind of inspired by a strategy I typically use for performance, which is make it work before you try to make it fast. And, actually, make it work, then profile, then measure, find the hotspots, and then focus on making those things fast. So, in this case, instead of speed, we're talking about money. So, it's make it work, then profile, find the parts that are expensive, and make the trade-off of, like, okay, is it worth investing into making that part less expensive in terms of resources?

+ +

STEPHANIE: I like that as a framework a lot.

+ +

JOËL: A lot of what we do as programmers is optimization, right? And sometimes, we're optimizing for execution time. Sometimes we're optimizing for memory cost, and sometimes we're optimizing for dollars.

+ +

STEPHANIE: Yeah, that's really interesting because, with the buy solution, you know very clearly, like, how much the thing will cost. Whereas I've definitely seen teams go down the building route, and it always takes longer than expected [laughs], and that is money, right? In terms of the developer's time, for sure.

+ +

JOËL: Yeah, definitely, like, add some kind of multiplier when you're budgeting out that build alternative because, quite likely, there are some edge cases that you haven't thought about that the commercial partner has, and you will have to spend more time on that than you expected.

+ +

STEPHANIE: Yeah, in addition to whatever opportunity cost of not working on something that is driving revenue for the business right now.

+ +

JOËL: Exactly.

+ +

STEPHANIE: So, the direction of this conversation ended up going kind of towards, like, what is best for the team at, like, a product and company level. But I think that we make these decisions a lot more frequently, even when it comes to whether we pull in a gem or, you know, use an open-source tool or not. And I would be really interested in discussing more of that in another episode.

+ +

JOËL: Yeah. That gets into some controversial takes, right? It's the evergreen topic of: do we build it ourselves, or do we pull in some kind of third-party package?

+ +

STEPHANIE: Something for the future to look forward to. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+fCbAnRWj + + ]]> + + Joël Quenneville + Stephanie Minn + + + 395: Human Connection in a Virtual (Work) World + https://bikeshed.thoughtbot.com/395 + fb7919f9-1984-477d-9bc0-b2a1c67dc1d4 + Tue, 01 Aug 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie had a small consulting win: saying no to a client. GeoGuessr is all the rage for thoughtbot's remote working culture, which leads to today's topic of forming human connections in a virtual (work) environment. + 30:59 + no + + + Stephanie had a small consulting win: saying no to a client. GeoGuessr is all the rage for thoughtbot's remote working culture, which leads to today's topic of forming human connections in a virtual (work) environment. +GeoGuessr (https://www.geoguessr.com/) +Strategies for saying no by Elle Meredith (https://www.youtube.com/watch?v=_2zWwwjnuUA) +NYT Let’s Ignore Each Other in the Same Room (https://www.nytimes.com/2021/09/24/well/live/parallel-play-for-adults.html) +Random question generator (https://standup-questions.vercel.app/) +Transcript: +JOËL: And this is just where it ends. +[laughter] +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, I have a small consulting win, or even just a small, like, win as a human being [laughs] that I want to share, which is that I feel good about a way that I handled saying no to a stakeholder recently. And, you know, I really got to take them where I can get it because that is so challenging for me. But I feel really glad because we ended up kind of coming out the other side of it having a better understanding of each other's goals and needs. +And so, basically, what happened was I was working on a task, and our product owner on our team asked me if it could be done by next week. And immediately, I wanted to say, "Absolutely not." [laughs] But, you know, I took a second and, you know, I had the wherewithal to ask why. You know, I was kind of curious, like, where was this deadline coming from? Like, what was on her radar that, like, wasn't on mine? +And she had shared that, oh, you know, if we were able to get it out before this big launch, she was thinking that it actually might make our customer support team's lives easier because we were kind of taking away access to something before some new features rolled out. And, you know, there might be some customers who would complain. And with that information, you know, that was really helpful in helping me understand. And I'm like, yeah, like, that seems like a helpful thing to know, so I could try to strive for it. Because I also, like, want to make that process go easier as well. +But I told her that I'd let her know because I honestly wasn't sure if it was possible to do by next week. And after a little bit of, you know, more digging, kind of seeing how my progress was going, in the end, I had to say that I didn't feel confident that we could finish it in time for that deadline because of the other risks, right? Like, I didn't want to just release this thing without feeling good about the plan that we had. And so, that was my small, little win in saying no, and I feel very proud of myself for it. +JOËL: I'm proud of you too. That's not easy to just do in the first place, and then to do it well is a whole other level. It sounds, though, that you came out of the other side with the client with almost, like, a better relationship. +STEPHANIE: Yeah, I think so. In general, you know, I really struggle when people do end up getting into that debate of, like, "Well, I need this." And someone else says, "Well, I need this other thing." And, you know, at some point, it kind of gets a bit unproductive, right? But I think this was a very helpful way for me to see a path forward when maybe we, like, have different priorities. But, like, can we better understand each other and the impact of them to ultimately, like, make the best decision? +The other thing that I wanted to share that I learned recently was there was a recent RailsConf talk by Elle Meredith, and it was about strategies to say no, and I watched it. And one really cool thing that I learned was that the word priority, you know, when it was first created, it actually didn't really have, like, a plural form. There was really only ever, like, a singular priority. And it wasn't until, I think, you know, the recent century or something like that, that people started to use it in a plural form. And that was really enlightening to me. +I think it made me rethink the word and how I use it, and it made a lot of sense, too. Because at any given moment, you know, really, you can't be doing more than one thing; I mean, you can try. I know that I have been guilty of multitasking. But that, you know, doesn't always serve me. I never end up doing all of the things that I'm trying to do well. And I would be really curious to kind of, you know, when I do feel that urge, like, think a little bit about, like, what is the one thing that I should be doing right now that is the highest priority? +JOËL: I would definitely second that recommendation for this talk. I actually got to see it live at RailsConf, and it was excellent. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I got to participate in a really fun event at thoughtbot today. We got together with some other people on the Boost Team and played a few rounds of GeoGuessr. And for those who are not familiar with this game, it drops you randomly somewhere in the world in Google Street View. You can move around. And there's a timer, and you have to drop a pin on a map where you think you are. +So, you're walking through the streets, and you're like, okay, well, I don't know this language. I'm not sure where we're going. You know, with the vibes going here, I'll bet, you know, this looks like maybe southern China, and then you drop a pin. And oh no, turns out it was actually Singapore. And there's all these little hints and things. People who are really into it have learned all these tricks, and they can be really good. Sara Jackson, who is our resident GeoGuessr expert, is excellent at this. But it was a good time. +STEPHANIE: Yeah, it was really fun. I liked that we played a cooperative mode where we were all kind of helping each other out. And so, maybe someone is, like, exploring on the map and sees a street sign and is like, "Oh, like, that looks like this language." And someone else is like, "Oh yeah, like, that is that." Or like, "No, I think it's actually this other language," and sharing all of the different, like, pieces of information that we're finding to get closer and closer to what it might be. +And then we celebrate whoever ends up getting the closest because, at some point, it's kind of just, like, just a luck of the pin, right? Where maybe you happen to click on, like, the right place. But it's always really exciting when we're like, wow, like, Sara was only 500 kilometers away in finding the exact place that we were served. So, I had a good time as well. +JOËL: So, speaking of cooperative events, this was a work event that we did. We just got together and played a game. And, for me, that was a really fun way to connect with some of my colleagues. I'm curious, what are your thoughts on things that you've seen done well in companies that are remote-first that really foster a sense of connection and community among a team? +STEPHANIE: I think this worked especially well today because it was kind of scheduled in regular time that we have as a team to me. And sometimes, you know, the meeting topics are a bit more work-focused. But what I really like is that anyone on the team can host one of these meetings. We have them biweekly, and we just call them Boost biweeklies. Boost is the team that Joël and I are on. +JOËL: Naming is the hardest problem in computer science. +STEPHANIE: It really is. But I really like that people can bring, you know, a little bit of their own flavor to this meeting. So, whoever is host just kind of comes up with something to do. And sometimes it's like show and tell. You know, other times it is more of like, you know, what's the update on some of the projects that we're doing? Other times, it's the Spicy Takes Lightning Talks that we've kind of mentioned on the podcast before. And yeah, it is just a really nice, like, time for us to get together. +And I also feel like I learn something about my co-workers every time that we meet, whether it's the person who is hosting the meeting and kind of where their interests are. I think someone even did, like, chair yoga once and guided the team in doing that. Or because they are more casual, right? Sometimes we just play a game, and I really enjoy that nice break in my day. +JOËL: Do you find that the particular style of these meetings makes you feel more connected to your colleagues? Would you prefer just kind of game day one, like we had today, versus maybe, like, lightning talks or a presentation on security or something like that? +STEPHANIE: I actually think the diversity is what makes it special. I get to see, you know, a bunch of different sides of my co-workers and, you know, some days, the topic is a little more serious, and that can be really connecting. Another Boost Team member had hosted a biweekly where we kind of shared the challenges of, like, consulting work and, like, onboarding onto a new project and sharing what might be difficult and, like, how we might be feeling when we do join a new project. +And I think that was really helpful because it was very validating for something that I thought, like, maybe I felt a little bit more alone in. And the tone was a little bit more, like, earnest and serious. But I came away with it feeling very supported by my team, right? And other times, it is just silliness and fun [laughs], which, you know, is also important. Like, we need to have fun every once in a while. +JOËL: That's awesome. Do you feel like when you go to these meetings, you're looking more for knowledge or looking more for connection? +STEPHANIE: I think both because knowledge sharing is also, you know, can be really helpful. Like, I have enjoyed learning that, you know, so and so is, like, a GeoGuessr expert, Sara, right? And so, if I ever, like, find myself needing [chuckles] someone to go to about my Google Street View or world geography questions, I know that I can go to her. And, like, knowing that about her, like, makes me feel more connected to her. So, I think both are true. +So, we have been talking about a meeting style form of connecting in a remote workplace, but I'm really curious about your thoughts on asynchronous versus synchronous communication and how you find connection with a format that is more asynchronous, not just, you know, being in a meeting together. +JOËL: That's really challenging. I think I personally find that something that's mostly synchronous with maybe a little bit of a lag works pretty well for me, so something like Slack, where it's not exactly real-time because someone could take some time to come back to me. But for working hours overlap, there's likely some close-to-synchronous conversation happening. +But, you know, I can still get up and, you know, refill my cup of coffee, or it's not quite like I'm sitting in front of a camera. So, I think that, for many things, hits the sweet spot for myself. But there's definitely some things where I think you want a higher, like, information density. And that's, I think, where the synchronous face-to-face meeting really shines. +STEPHANIE: Information density. I haven't heard that phrase before, but I like it. +JOËL: The idea being, you know, how much information or how many words are you sharing back and forth, you know, per minute or something like that. And when you're talking on a call, you can do a lot more of that than you can going back and forth over Slack or writing an email. +STEPHANIE: So, I would say that at thoughtbot, we have a pretty asynchronous Slack culture, which I think can be quite different from other, you know, places I've worked at before or other Slack spaces that I've seen. And I actually find it a little bit harder to engage in that way. We have a dev channel where, you know, people chat about different technical topics. And sometimes, you know, those threads go, like, 40 replies long. And I think you tend to engage a lot more in those. +And I'm curious, like, does that scratch the itch for you in terms of that perfect, like, async, kind of some amount of lag for you to be doing other things, kind of doing your work, but then being able to come back and pick up the conversation where I left off? +JOËL: Yes, that is really nice because, you know, maybe I have a meeting or something, and I'm not there when the conversation starts, but I don't miss out. And I get to join in, you know, maybe 30 minutes after everyone else. You know, sometimes you don't want to just, like, restart a conversation that's happened and is done. But some of these things will kind of be going on and off all day. And those can be really fun, especially sometimes, like, a new person joins the thread and brings in a totally new perspective or a new angle that kind of, like, breathes new life into it and kind of gives everyone a new perspective. +STEPHANIE: Nice. I also think there's something to the idea of seeing more people engage with something that then invites other people to engage with it. +JOËL: I would agree with that. It's definitely exciting to see a thread, and it's not like, oh, it's empty, and I'm the only one who's put a response in here. When there is a lot of back and forth, you can almost feel the excitement. And that gets me hyped to, like, keep it going. +STEPHANIE: At a previous workplace in our Slack, we had a, like, virtual Jeopardy channel. +JOËL: Ooh. +STEPHANIE: And so, there was a little Jeopardy bot. And I guess whenever someone, you know, had a low on what they were doing, they would just start, you know, tagging the bot to pose a question. And anyone can answer, right? But once you kind of got the ball rolling, you would see other people start playing as well. And it would get really active for segments of 30 minutes or so. +And I always really enjoyed that because, yeah, it was a way for me to remember like, oh yeah, there's, like, other people also, like, typing away on their little keyboards, and we're all here together. But it was really interesting to see, like, when someone got it rolling, like, oh, other people, like, joined in. +JOËL: Yeah, being able to see small things like that can really build a sense of connection, even if you're not yourself directly participating. +STEPHANIE: Yeah. I think another thing I've been trying out lately is letting people know that I'm in a meeting space and offering to virtually co-work. So, you know, during the early days of when thoughtbot went remote, we had a lounge virtual meeting space for people to hang out with and, you know, get that face time that they weren't getting anymore since we weren't in the office. And, you know, I think that has kind of decreased in terms of engagement over, you know, several years now. And obviously, people have a lot of meeting fatigue and stuff like that. +But I was kind of in a mood to revive it a little bit because, yeah, I kind of got over the meeting fatigue and was wanting more face time with people. And the unfortunate thing, though, is that, like, no one was showing up to this room anymore. So, you know, even if someone wanted to hang out in it, you know, they go in. They see no one's there, you know, maybe they stay for a few minutes, but then they're like, okay, well, I'm just going to leave now. +And a couple of thoughtboters and I have been trying to revive it where we'll post in our general channel, like, "Hey, like, I'm in this meeting room. Like, come hang out for the next hour if you would like." And that's been working well for me. I have had a few, like, really nice lounge, virtual co-working hangout sessions. Even if one person shows up, honestly, like, that fulfills my want to just, like, speak to another human. [laughs] +JOËL: What does virtual co-working look like? Are you just kind of each doing work, but you've got a video camera on, and you're just aware of the presence of someone else? Do you kind of have, like, random breaks where you talk? What is that experience like? +STEPHANIE: Oh yeah, that's a good question. I have to say; for me, I'm just talking to the other [laughs] person at that point. I'm not really doing a whole lot of work. And, you know, in some ways, I almost think that, like, in those moments, I am really wanting to chat with someone and, like, that's okay, right? +JOËL: It's like a virtual water cooler for you. +STEPHANIE: Yeah, exactly. Like, that would be the moment if I were working in office that I would wander into the kitchen looking for a snack but also an unsuspecting victim to start [laughs] a conversation with. +JOËL: I feel you. I feel you. I have absolutely done that. +STEPHANIE: Yeah. And that's actually what makes me feel a little less guilty about it. Because, you know, when I was working in the office, like, that was such a big part of my day, and it's kind of what kept me motivated. And at home, I do find myself, like, a lot more productive. In fact, like, I think I am because I'm, you know, not spending that time wandering into the kitchen. But at what cost? [laughs] At the cost of, like, me feeling very, like, lonely and, like, kind of burnt out at the end of the day. +So, injecting my day with some of these moments, I think, is important to me. And also, again, like, I know that I'm being really productive in my, like, heads-down-time that I want to, you know, allow myself to just like, get that dose of connection. +JOËL: I know, for me, when we were doing things like this in person as well, those conversations that happen, yes, there's some random, frivolous stuff, but sometimes, it is a conversation related to work that I'm doing. Because, you know, someone who's not on my project is like, "Hey, how's your project going?" Or whatever. I'm like, "Oh, well, I'm, you know, doing this ODBC connection, and I'm kind of stuck." And, you know, we kind of talk about a few things. It's like, "Oh, did you know about this gem?" And it's like, "Wait, why didn't I talk to you earlier? Because this totally solves my problem." +STEPHANIE: Yeah, I think that being a sounding board is so valuable as well. So, I guess I enjoy virtual co-working, not necessarily, you know, us, like, sitting together and doing our work separately. Though I know that there's value in that, especially in real life. Like, I remember reading an article. I'll try to find it and link it. But the idea of just, like, sharing space with someone can be, like, a form of bonding. +But I do really enjoy just hearing about what other people are working on and just kind of, like, asking questions about it, right? And maybe we do take away, like, a new perspective or, like, have some insights about, like, the work itself. And, yeah, we don't really get that when we're working remotely by ourselves because there's no one to turn to and be like, "Hey, what do you think about this problem?" +JOËL: I love how no matter what the topic is that we're discussing on this show, you always have a book or an article or something that you've read that you can reference. And I think that's amazing. +STEPHANIE: Thank you. +JOËL: So, you're talking about things that have really helped you feel a deeper sense of connection. I had a realization recently about the power of physical items. In particular, as consultants, sometimes we work with clients who, for security reasons, want us to work on a dedicated laptop for this particular client. And so, we'll have clients maybe—well, now that we're remote—ship us a laptop, and we work on that laptop when we're doing client stuff, and then on our thoughtbot laptops when we're doing thoughtbot things. +And when I've been on clients like that, I have felt much more isolated from the thoughtbot team. And just, like, physically switching over to the thoughtbot laptop, all of a sudden, gives me that feeling of connection. And there's something I can't quite explain about the power of the physical item. And, say, I'm working on the thoughtbot laptop today with, you know, thoughtbot Slack in the background or whatever, and I feel more connected to my colleagues. +STEPHANIE: Yeah, that is really curious. Did you also have thoughtbot communication channels open in your client laptop during that time? +JOËL: I did, and yet still felt more separation. +STEPHANIE: Yeah, that's really interesting. The way you're describing it, it was almost like, you know, the main laptop that you work with, with your, like, all of the settings that you like, all of your little shortcuts, you know, the autocomplete to the whatever, like, channels of communication that you are used to seeing. In some ways, that almost feels like home a little bit. And I wonder if working on a client laptop almost kind of feels like, you know, being in a stranger's house, right? +JOËL: There's definitely an element of that. Yeah, all the little things I've fine-tuned, some of the productivity software I have on there that are just, you know, I can one by one set them up on the client laptop, depending on permissions. But yeah, it's never quite the same. +STEPHANIE: So, when you are in a situation where you're mostly working from a client laptop and maybe embedded in their Slack workspace, embedded in their team, how do you go about investing in connection with your client team? +JOËL: So, you know what's kind of weird? Is that when I'm on a client laptop, I feel less connected to my colleagues at thoughtbot, but the reverse is not necessarily true. I don't feel more connected to colleagues on a client team on a client laptop than I would on my thoughtbot laptop. So, I'm not exactly sure what the psychology is going on there. But I feel kind of most connected to both when I'm working on my thoughtbot laptop, which is perhaps a bit strange. +STEPHANIE: Oh, yeah, that is interesting. I think, in general, there's an aspect of joining a new client team and trying to figure out the culture there and how you might engage with it, right? And how what you bring to the table kind of fits in with how they do things, and how they talk about things, and how they behave. In some ways, it's kind of, like, you know, an outsider joining this, like, in-group, right? So, I've definitely realized that the ways that I engage and feel connected at thoughtbot, like, may or may not work for the client team that I'm joining. +JOËL: Yeah. And onboarding onto a client team is not just a technical exercise, right? It's also a social process where you want to get to know the other people on your team, get to sort of integrate into the way they work, their processes, hopefully, build a little bit of, like, personal connection with individuals because all of those are going to help me do my job better tomorrow, and the day after, and the week after that. +STEPHANIE: Yeah. I had mentioned previously that one thing that I've been enjoying on my client team is our daily sync question. So, a random question will be generated, you know, like, "What are you eating for dinner today?" Or, like, "What are you looking forward to this weekend?" And folks are able to share. And the fun thing is that sometimes the answer to the question is longer than their work update itself. +JOËL: Nice. +STEPHANIE: But that is actually the, you know, the beauty of it because we all just, like, get to laugh and get to, you know, chime in. And I'm like, "Oh yeah, like, that sounds delicious, like, what you're eating for dinner tonight." But, like, that would not work for our Boost Team's sync because, you know, it's a much bigger meeting with sometimes up to, you know, 20 to almost 30 people and, like, we can't quite have as much time spent talking about the fun question of the day. So, I definitely think that, you know, it depends your team size, and makeup, and whatnot. +JOËL: Are those questions kind of preset, or do you all get to contribute questions to the list? +STEPHANIE: We brainstormed the questions one retro when we were realizing that we were kind of getting a little bored of the existing question that we had. And we came up with a handful that is plugged into, like, a website, or, like, an app that randomly, you know, picks the question of the day. And so, I think, again, when we get a little bored of the ones that we have in rotation, we'll throw in some curveballs in there. +JOËL: Have you ever considered adding "What's new in your world?" to this rotation? +STEPHANIE: It's funny you mentioned that because it's actually the question that we got a little bit stale on. [laughs] +JOËL: Really? +STEPHANIE: And we needed to inject some new life into, yeah. It's a classic, you know. But I think the variety is nice, especially since we're meeting almost every day. And before we started recording, you and I were just talking about how even sometimes it's tough to think of something that's new in our world [laughs] because we don't always live the most interesting and, you know, new lives. And sometimes, we kind of just have to dig deep to come up with something, and we only meet weekly. [laughs] +JOËL: I can definitely see how doing this daily might be more challenging. I think there's also value in questions that are a little bit more focused. Part of what's fun for this podcast is that "What's new in your world?" is so kind of broad. But maybe for something daily, having something really specific, like, what did you eat for dinner tonight? Means that you aren't just kind of drawing blanks in your mind, like, uh, uh, what is new in my world? What have I done? I don't know; I have a boring life. I don't do anything. Kind of panic mode that you can sometimes get when you hit a meeting. +And so, I do know that when I've been sometimes in situations with people where you have questions like that, I've tended to really appreciate the more targeted ones. +STEPHANIE: Yeah, that's so interesting you mentioned that because I think in social situations, there's usually maybe, like, someone who is really good at asking those, like, specific questions to get the group talking and, like, you know, engaged in a fun conversation, and that specificity helps. +One thing that I was just wondering about is the value of meeting every day in a sync kind of format, and I'm curious if you think that is important to you. If you have been on other teams that don't meet every day, maybe they have, like, a virtual check-in, right? Like, a virtual reminder to share what they're working on as opposed to meeting synchronously. +JOËL: I think I've seen sort of different purposes for sync meetings. Sometimes it's very kind of project-heavy, right? You're talking about the tickets you're working on for today. The reason you're having that is specifically for status updates or because you are blocked, and you want somebody else to help unblock you. So, it's very process-focused. I think that varies team to team, but it can be really helpful. +Even I've been on projects where it's maybe me and one other person, and we'll have kind of an informal just call each other up every morning and say, "Hey, here's what I'm working on today. Here's kind of roughly the strategy I plan to take on it. And we'll go back and forth." And for something like that, it inevitably also somewhat turns into a bit of a social call, so that's planning and social. And I think that can be really strong. +STEPHANIE: Yeah, I like that a lot. +JOËL: That's not necessarily going to be the case for every team, every project, especially with larger teams. And I feel like for something like the Boost Team at thoughtbot, we have a daily sync. We're not all working on the same project. So, I don't want to know about the specific details of the ticket you're working on. I'm more interested in getting just a little bit of face time with the whole of our team to feel a connection. +And, you know, maybe if you've got something cool that you want to share, and that can be a win. It can even be a struggle. And we can all kind of empathize, right? That, like, "Oh, I dropped production database this morning, and I'm kind of freaking out," is a totally fine thing to share. But "I am working on ticket 1, 2, 3, 4 to add some text to a part of the page," that's not particularly useful to me in the kind of sync that we have for the thoughtbot Boost Team. +STEPHANIE: Yeah, absolutely. I think knowing, like, who the audience is of the meeting and, like, how they might be able to support you or be there for you is helpful in making them feel a little more relevant and personal. And I had mentioned that our Boost daily meetings or daily syncs, you know, are a little too big for people to really get into, you know, sharing a fun, personal anecdote, or whatever. +But one thing that I really enjoy is that whoever goes last in giving their update gets to choose the sign-off for everyone. So maybe that's like, okay, we'll just go out on a wave, and we all wave. Or maybe it's, you know, like, making a little heart with your hands. And then there's some folks on the team who go really wild and, you know, come up with something totally unexpected. And I think, you know, that spontaneity is so fun. And we all share it in this collective act of...I'm trying to think of a funny one lately, maybe, like, sinking down into your chair until you disappear from the view [laughs]. That's a good one. +JOËL: Sometimes it's those, like, small social rituals that can be really meaningful. +STEPHANIE: Absolutely. Do you have a favorite sign-off that you have either requested or have done? +JOËL: So, I typically just go for the wave if I'm last because I've not thought about it. But I generally think it's fun to have everybody try to mimic an emoji. So, it might be like, oh, everybody do the, you know, See-No-Evil emoji, or everybody do the party parrot. Those are pretty fun to sign off on. +STEPHANIE: Oh yeah, [inaudible 29:15] pausing is good. I think another one I like is, "Everyone do your best impression of a tree." [laughs] +JOËL: Sometimes, too, it's fun to do something that's relevant to the particular day. If there's something special happening that day, you get something relevant. I've done before, if it's on a Friday, say, "Everybody do your best Rebecca Black impression." +STEPHANIE: Yeah, also excellent. +JOËL: Because, you know, it's Friday. +STEPHANIE: Yeah, like, a little moment of collective celebration for the weekend. On that note, it's a Friday we're recording this episode. Shall we wrap up and look forward to the weekend? +JOËL: [laughter] Fun, fun, fun, fun. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie had a small consulting win: saying no to a client. GeoGuessr is all the rage for thoughtbot's remote working culture, which leads to today's topic of forming human connections in a virtual (work) environment.

+ +
+ + + +

Transcript:

+ +

JOËL: And this is just where it ends.

+ +

[laughter]

+ +

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, I have a small consulting win, or even just a small, like, win as a human being [laughs] that I want to share, which is that I feel good about a way that I handled saying no to a stakeholder recently. And, you know, I really got to take them where I can get it because that is so challenging for me. But I feel really glad because we ended up kind of coming out the other side of it having a better understanding of each other's goals and needs.

+ +

And so, basically, what happened was I was working on a task, and our product owner on our team asked me if it could be done by next week. And immediately, I wanted to say, "Absolutely not." [laughs] But, you know, I took a second and, you know, I had the wherewithal to ask why. You know, I was kind of curious, like, where was this deadline coming from? Like, what was on her radar that, like, wasn't on mine?

+ +

And she had shared that, oh, you know, if we were able to get it out before this big launch, she was thinking that it actually might make our customer support team's lives easier because we were kind of taking away access to something before some new features rolled out. And, you know, there might be some customers who would complain. And with that information, you know, that was really helpful in helping me understand. And I'm like, yeah, like, that seems like a helpful thing to know, so I could try to strive for it. Because I also, like, want to make that process go easier as well.

+ +

But I told her that I'd let her know because I honestly wasn't sure if it was possible to do by next week. And after a little bit of, you know, more digging, kind of seeing how my progress was going, in the end, I had to say that I didn't feel confident that we could finish it in time for that deadline because of the other risks, right? Like, I didn't want to just release this thing without feeling good about the plan that we had. And so, that was my small, little win in saying no, and I feel very proud of myself for it.

+ +

JOËL: I'm proud of you too. That's not easy to just do in the first place, and then to do it well is a whole other level. It sounds, though, that you came out of the other side with the client with almost, like, a better relationship.

+ +

STEPHANIE: Yeah, I think so. In general, you know, I really struggle when people do end up getting into that debate of, like, "Well, I need this." And someone else says, "Well, I need this other thing." And, you know, at some point, it kind of gets a bit unproductive, right? But I think this was a very helpful way for me to see a path forward when maybe we, like, have different priorities. But, like, can we better understand each other and the impact of them to ultimately, like, make the best decision?

+ +

The other thing that I wanted to share that I learned recently was there was a recent RailsConf talk by Elle Meredith, and it was about strategies to say no, and I watched it. And one really cool thing that I learned was that the word priority, you know, when it was first created, it actually didn't really have, like, a plural form. There was really only ever, like, a singular priority. And it wasn't until, I think, you know, the recent century or something like that, that people started to use it in a plural form. And that was really enlightening to me.

+ +

I think it made me rethink the word and how I use it, and it made a lot of sense, too. Because at any given moment, you know, really, you can't be doing more than one thing; I mean, you can try. I know that I have been guilty of multitasking. But that, you know, doesn't always serve me. I never end up doing all of the things that I'm trying to do well. And I would be really curious to kind of, you know, when I do feel that urge, like, think a little bit about, like, what is the one thing that I should be doing right now that is the highest priority?

+ +

JOËL: I would definitely second that recommendation for this talk. I actually got to see it live at RailsConf, and it was excellent.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I got to participate in a really fun event at thoughtbot today. We got together with some other people on the Boost Team and played a few rounds of GeoGuessr. And for those who are not familiar with this game, it drops you randomly somewhere in the world in Google Street View. You can move around. And there's a timer, and you have to drop a pin on a map where you think you are.

+ +

So, you're walking through the streets, and you're like, okay, well, I don't know this language. I'm not sure where we're going. You know, with the vibes going here, I'll bet, you know, this looks like maybe southern China, and then you drop a pin. And oh no, turns out it was actually Singapore. And there's all these little hints and things. People who are really into it have learned all these tricks, and they can be really good. Sara Jackson, who is our resident GeoGuessr expert, is excellent at this. But it was a good time.

+ +

STEPHANIE: Yeah, it was really fun. I liked that we played a cooperative mode where we were all kind of helping each other out. And so, maybe someone is, like, exploring on the map and sees a street sign and is like, "Oh, like, that looks like this language." And someone else is like, "Oh yeah, like, that is that." Or like, "No, I think it's actually this other language," and sharing all of the different, like, pieces of information that we're finding to get closer and closer to what it might be.

+ +

And then we celebrate whoever ends up getting the closest because, at some point, it's kind of just, like, just a luck of the pin, right? Where maybe you happen to click on, like, the right place. But it's always really exciting when we're like, wow, like, Sara was only 500 kilometers away in finding the exact place that we were served. So, I had a good time as well.

+ +

JOËL: So, speaking of cooperative events, this was a work event that we did. We just got together and played a game. And, for me, that was a really fun way to connect with some of my colleagues. I'm curious, what are your thoughts on things that you've seen done well in companies that are remote-first that really foster a sense of connection and community among a team?

+ +

STEPHANIE: I think this worked especially well today because it was kind of scheduled in regular time that we have as a team to me. And sometimes, you know, the meeting topics are a bit more work-focused. But what I really like is that anyone on the team can host one of these meetings. We have them biweekly, and we just call them Boost biweeklies. Boost is the team that Joël and I are on.

+ +

JOËL: Naming is the hardest problem in computer science.

+ +

STEPHANIE: It really is. But I really like that people can bring, you know, a little bit of their own flavor to this meeting. So, whoever is host just kind of comes up with something to do. And sometimes it's like show and tell. You know, other times it is more of like, you know, what's the update on some of the projects that we're doing? Other times, it's the Spicy Takes Lightning Talks that we've kind of mentioned on the podcast before. And yeah, it is just a really nice, like, time for us to get together.

+ +

And I also feel like I learn something about my co-workers every time that we meet, whether it's the person who is hosting the meeting and kind of where their interests are. I think someone even did, like, chair yoga once and guided the team in doing that. Or because they are more casual, right? Sometimes we just play a game, and I really enjoy that nice break in my day.

+ +

JOËL: Do you find that the particular style of these meetings makes you feel more connected to your colleagues? Would you prefer just kind of game day one, like we had today, versus maybe, like, lightning talks or a presentation on security or something like that?

+ +

STEPHANIE: I actually think the diversity is what makes it special. I get to see, you know, a bunch of different sides of my co-workers and, you know, some days, the topic is a little more serious, and that can be really connecting. Another Boost Team member had hosted a biweekly where we kind of shared the challenges of, like, consulting work and, like, onboarding onto a new project and sharing what might be difficult and, like, how we might be feeling when we do join a new project.

+ +

And I think that was really helpful because it was very validating for something that I thought, like, maybe I felt a little bit more alone in. And the tone was a little bit more, like, earnest and serious. But I came away with it feeling very supported by my team, right? And other times, it is just silliness and fun [laughs], which, you know, is also important. Like, we need to have fun every once in a while.

+ +

JOËL: That's awesome. Do you feel like when you go to these meetings, you're looking more for knowledge or looking more for connection?

+ +

STEPHANIE: I think both because knowledge sharing is also, you know, can be really helpful. Like, I have enjoyed learning that, you know, so and so is, like, a GeoGuessr expert, Sara, right? And so, if I ever, like, find myself needing [chuckles] someone to go to about my Google Street View or world geography questions, I know that I can go to her. And, like, knowing that about her, like, makes me feel more connected to her. So, I think both are true.

+ +

So, we have been talking about a meeting style form of connecting in a remote workplace, but I'm really curious about your thoughts on asynchronous versus synchronous communication and how you find connection with a format that is more asynchronous, not just, you know, being in a meeting together.

+ +

JOËL: That's really challenging. I think I personally find that something that's mostly synchronous with maybe a little bit of a lag works pretty well for me, so something like Slack, where it's not exactly real-time because someone could take some time to come back to me. But for working hours overlap, there's likely some close-to-synchronous conversation happening.

+ +

But, you know, I can still get up and, you know, refill my cup of coffee, or it's not quite like I'm sitting in front of a camera. So, I think that, for many things, hits the sweet spot for myself. But there's definitely some things where I think you want a higher, like, information density. And that's, I think, where the synchronous face-to-face meeting really shines.

+ +

STEPHANIE: Information density. I haven't heard that phrase before, but I like it.

+ +

JOËL: The idea being, you know, how much information or how many words are you sharing back and forth, you know, per minute or something like that. And when you're talking on a call, you can do a lot more of that than you can going back and forth over Slack or writing an email.

+ +

STEPHANIE: So, I would say that at thoughtbot, we have a pretty asynchronous Slack culture, which I think can be quite different from other, you know, places I've worked at before or other Slack spaces that I've seen. And I actually find it a little bit harder to engage in that way. We have a dev channel where, you know, people chat about different technical topics. And sometimes, you know, those threads go, like, 40 replies long. And I think you tend to engage a lot more in those.

+ +

And I'm curious, like, does that scratch the itch for you in terms of that perfect, like, async, kind of some amount of lag for you to be doing other things, kind of doing your work, but then being able to come back and pick up the conversation where I left off?

+ +

JOËL: Yes, that is really nice because, you know, maybe I have a meeting or something, and I'm not there when the conversation starts, but I don't miss out. And I get to join in, you know, maybe 30 minutes after everyone else. You know, sometimes you don't want to just, like, restart a conversation that's happened and is done. But some of these things will kind of be going on and off all day. And those can be really fun, especially sometimes, like, a new person joins the thread and brings in a totally new perspective or a new angle that kind of, like, breathes new life into it and kind of gives everyone a new perspective.

+ +

STEPHANIE: Nice. I also think there's something to the idea of seeing more people engage with something that then invites other people to engage with it.

+ +

JOËL: I would agree with that. It's definitely exciting to see a thread, and it's not like, oh, it's empty, and I'm the only one who's put a response in here. When there is a lot of back and forth, you can almost feel the excitement. And that gets me hyped to, like, keep it going.

+ +

STEPHANIE: At a previous workplace in our Slack, we had a, like, virtual Jeopardy channel.

+ +

JOËL: Ooh.

+ +

STEPHANIE: And so, there was a little Jeopardy bot. And I guess whenever someone, you know, had a low on what they were doing, they would just start, you know, tagging the bot to pose a question. And anyone can answer, right? But once you kind of got the ball rolling, you would see other people start playing as well. And it would get really active for segments of 30 minutes or so.

+ +

And I always really enjoyed that because, yeah, it was a way for me to remember like, oh yeah, there's, like, other people also, like, typing away on their little keyboards, and we're all here together. But it was really interesting to see, like, when someone got it rolling, like, oh, other people, like, joined in.

+ +

JOËL: Yeah, being able to see small things like that can really build a sense of connection, even if you're not yourself directly participating.

+ +

STEPHANIE: Yeah. I think another thing I've been trying out lately is letting people know that I'm in a meeting space and offering to virtually co-work. So, you know, during the early days of when thoughtbot went remote, we had a lounge virtual meeting space for people to hang out with and, you know, get that face time that they weren't getting anymore since we weren't in the office. And, you know, I think that has kind of decreased in terms of engagement over, you know, several years now. And obviously, people have a lot of meeting fatigue and stuff like that.

+ +

But I was kind of in a mood to revive it a little bit because, yeah, I kind of got over the meeting fatigue and was wanting more face time with people. And the unfortunate thing, though, is that, like, no one was showing up to this room anymore. So, you know, even if someone wanted to hang out in it, you know, they go in. They see no one's there, you know, maybe they stay for a few minutes, but then they're like, okay, well, I'm just going to leave now.

+ +

And a couple of thoughtboters and I have been trying to revive it where we'll post in our general channel, like, "Hey, like, I'm in this meeting room. Like, come hang out for the next hour if you would like." And that's been working well for me. I have had a few, like, really nice lounge, virtual co-working hangout sessions. Even if one person shows up, honestly, like, that fulfills my want to just, like, speak to another human. [laughs]

+ +

JOËL: What does virtual co-working look like? Are you just kind of each doing work, but you've got a video camera on, and you're just aware of the presence of someone else? Do you kind of have, like, random breaks where you talk? What is that experience like?

+ +

STEPHANIE: Oh yeah, that's a good question. I have to say; for me, I'm just talking to the other [laughs] person at that point. I'm not really doing a whole lot of work. And, you know, in some ways, I almost think that, like, in those moments, I am really wanting to chat with someone and, like, that's okay, right?

+ +

JOËL: It's like a virtual water cooler for you.

+ +

STEPHANIE: Yeah, exactly. Like, that would be the moment if I were working in office that I would wander into the kitchen looking for a snack but also an unsuspecting victim to start [laughs] a conversation with.

+ +

JOËL: I feel you. I feel you. I have absolutely done that.

+ +

STEPHANIE: Yeah. And that's actually what makes me feel a little less guilty about it. Because, you know, when I was working in the office, like, that was such a big part of my day, and it's kind of what kept me motivated. And at home, I do find myself, like, a lot more productive. In fact, like, I think I am because I'm, you know, not spending that time wandering into the kitchen. But at what cost? [laughs] At the cost of, like, me feeling very, like, lonely and, like, kind of burnt out at the end of the day.

+ +

So, injecting my day with some of these moments, I think, is important to me. And also, again, like, I know that I'm being really productive in my, like, heads-down-time that I want to, you know, allow myself to just like, get that dose of connection.

+ +

JOËL: I know, for me, when we were doing things like this in person as well, those conversations that happen, yes, there's some random, frivolous stuff, but sometimes, it is a conversation related to work that I'm doing. Because, you know, someone who's not on my project is like, "Hey, how's your project going?" Or whatever. I'm like, "Oh, well, I'm, you know, doing this ODBC connection, and I'm kind of stuck." And, you know, we kind of talk about a few things. It's like, "Oh, did you know about this gem?" And it's like, "Wait, why didn't I talk to you earlier? Because this totally solves my problem."

+ +

STEPHANIE: Yeah, I think that being a sounding board is so valuable as well. So, I guess I enjoy virtual co-working, not necessarily, you know, us, like, sitting together and doing our work separately. Though I know that there's value in that, especially in real life. Like, I remember reading an article. I'll try to find it and link it. But the idea of just, like, sharing space with someone can be, like, a form of bonding.

+ +

But I do really enjoy just hearing about what other people are working on and just kind of, like, asking questions about it, right? And maybe we do take away, like, a new perspective or, like, have some insights about, like, the work itself. And, yeah, we don't really get that when we're working remotely by ourselves because there's no one to turn to and be like, "Hey, what do you think about this problem?"

+ +

JOËL: I love how no matter what the topic is that we're discussing on this show, you always have a book or an article or something that you've read that you can reference. And I think that's amazing.

+ +

STEPHANIE: Thank you.

+ +

JOËL: So, you're talking about things that have really helped you feel a deeper sense of connection. I had a realization recently about the power of physical items. In particular, as consultants, sometimes we work with clients who, for security reasons, want us to work on a dedicated laptop for this particular client. And so, we'll have clients maybe—well, now that we're remote—ship us a laptop, and we work on that laptop when we're doing client stuff, and then on our thoughtbot laptops when we're doing thoughtbot things.

+ +

And when I've been on clients like that, I have felt much more isolated from the thoughtbot team. And just, like, physically switching over to the thoughtbot laptop, all of a sudden, gives me that feeling of connection. And there's something I can't quite explain about the power of the physical item. And, say, I'm working on the thoughtbot laptop today with, you know, thoughtbot Slack in the background or whatever, and I feel more connected to my colleagues.

+ +

STEPHANIE: Yeah, that is really curious. Did you also have thoughtbot communication channels open in your client laptop during that time?

+ +

JOËL: I did, and yet still felt more separation.

+ +

STEPHANIE: Yeah, that's really interesting. The way you're describing it, it was almost like, you know, the main laptop that you work with, with your, like, all of the settings that you like, all of your little shortcuts, you know, the autocomplete to the whatever, like, channels of communication that you are used to seeing. In some ways, that almost feels like home a little bit. And I wonder if working on a client laptop almost kind of feels like, you know, being in a stranger's house, right?

+ +

JOËL: There's definitely an element of that. Yeah, all the little things I've fine-tuned, some of the productivity software I have on there that are just, you know, I can one by one set them up on the client laptop, depending on permissions. But yeah, it's never quite the same.

+ +

STEPHANIE: So, when you are in a situation where you're mostly working from a client laptop and maybe embedded in their Slack workspace, embedded in their team, how do you go about investing in connection with your client team?

+ +

JOËL: So, you know what's kind of weird? Is that when I'm on a client laptop, I feel less connected to my colleagues at thoughtbot, but the reverse is not necessarily true. I don't feel more connected to colleagues on a client team on a client laptop than I would on my thoughtbot laptop. So, I'm not exactly sure what the psychology is going on there. But I feel kind of most connected to both when I'm working on my thoughtbot laptop, which is perhaps a bit strange.

+ +

STEPHANIE: Oh, yeah, that is interesting. I think, in general, there's an aspect of joining a new client team and trying to figure out the culture there and how you might engage with it, right? And how what you bring to the table kind of fits in with how they do things, and how they talk about things, and how they behave. In some ways, it's kind of, like, you know, an outsider joining this, like, in-group, right? So, I've definitely realized that the ways that I engage and feel connected at thoughtbot, like, may or may not work for the client team that I'm joining.

+ +

JOËL: Yeah. And onboarding onto a client team is not just a technical exercise, right? It's also a social process where you want to get to know the other people on your team, get to sort of integrate into the way they work, their processes, hopefully, build a little bit of, like, personal connection with individuals because all of those are going to help me do my job better tomorrow, and the day after, and the week after that.

+ +

STEPHANIE: Yeah. I had mentioned previously that one thing that I've been enjoying on my client team is our daily sync question. So, a random question will be generated, you know, like, "What are you eating for dinner today?" Or, like, "What are you looking forward to this weekend?" And folks are able to share. And the fun thing is that sometimes the answer to the question is longer than their work update itself.

+ +

JOËL: Nice.

+ +

STEPHANIE: But that is actually the, you know, the beauty of it because we all just, like, get to laugh and get to, you know, chime in. And I'm like, "Oh yeah, like, that sounds delicious, like, what you're eating for dinner tonight." But, like, that would not work for our Boost Team's sync because, you know, it's a much bigger meeting with sometimes up to, you know, 20 to almost 30 people and, like, we can't quite have as much time spent talking about the fun question of the day. So, I definitely think that, you know, it depends your team size, and makeup, and whatnot.

+ +

JOËL: Are those questions kind of preset, or do you all get to contribute questions to the list?

+ +

STEPHANIE: We brainstormed the questions one retro when we were realizing that we were kind of getting a little bored of the existing question that we had. And we came up with a handful that is plugged into, like, a website, or, like, an app that randomly, you know, picks the question of the day. And so, I think, again, when we get a little bored of the ones that we have in rotation, we'll throw in some curveballs in there.

+ +

JOËL: Have you ever considered adding "What's new in your world?" to this rotation?

+ +

STEPHANIE: It's funny you mentioned that because it's actually the question that we got a little bit stale on. [laughs]

+ +

JOËL: Really?

+ +

STEPHANIE: And we needed to inject some new life into, yeah. It's a classic, you know. But I think the variety is nice, especially since we're meeting almost every day. And before we started recording, you and I were just talking about how even sometimes it's tough to think of something that's new in our world [laughs] because we don't always live the most interesting and, you know, new lives. And sometimes, we kind of just have to dig deep to come up with something, and we only meet weekly. [laughs]

+ +

JOËL: I can definitely see how doing this daily might be more challenging. I think there's also value in questions that are a little bit more focused. Part of what's fun for this podcast is that "What's new in your world?" is so kind of broad. But maybe for something daily, having something really specific, like, what did you eat for dinner tonight? Means that you aren't just kind of drawing blanks in your mind, like, uh, uh, what is new in my world? What have I done? I don't know; I have a boring life. I don't do anything. Kind of panic mode that you can sometimes get when you hit a meeting.

+ +

And so, I do know that when I've been sometimes in situations with people where you have questions like that, I've tended to really appreciate the more targeted ones.

+ +

STEPHANIE: Yeah, that's so interesting you mentioned that because I think in social situations, there's usually maybe, like, someone who is really good at asking those, like, specific questions to get the group talking and, like, you know, engaged in a fun conversation, and that specificity helps.

+ +

One thing that I was just wondering about is the value of meeting every day in a sync kind of format, and I'm curious if you think that is important to you. If you have been on other teams that don't meet every day, maybe they have, like, a virtual check-in, right? Like, a virtual reminder to share what they're working on as opposed to meeting synchronously.

+ +

JOËL: I think I've seen sort of different purposes for sync meetings. Sometimes it's very kind of project-heavy, right? You're talking about the tickets you're working on for today. The reason you're having that is specifically for status updates or because you are blocked, and you want somebody else to help unblock you. So, it's very process-focused. I think that varies team to team, but it can be really helpful.

+ +

Even I've been on projects where it's maybe me and one other person, and we'll have kind of an informal just call each other up every morning and say, "Hey, here's what I'm working on today. Here's kind of roughly the strategy I plan to take on it. And we'll go back and forth." And for something like that, it inevitably also somewhat turns into a bit of a social call, so that's planning and social. And I think that can be really strong.

+ +

STEPHANIE: Yeah, I like that a lot.

+ +

JOËL: That's not necessarily going to be the case for every team, every project, especially with larger teams. And I feel like for something like the Boost Team at thoughtbot, we have a daily sync. We're not all working on the same project. So, I don't want to know about the specific details of the ticket you're working on. I'm more interested in getting just a little bit of face time with the whole of our team to feel a connection.

+ +

And, you know, maybe if you've got something cool that you want to share, and that can be a win. It can even be a struggle. And we can all kind of empathize, right? That, like, "Oh, I dropped production database this morning, and I'm kind of freaking out," is a totally fine thing to share. But "I am working on ticket 1, 2, 3, 4 to add some text to a part of the page," that's not particularly useful to me in the kind of sync that we have for the thoughtbot Boost Team.

+ +

STEPHANIE: Yeah, absolutely. I think knowing, like, who the audience is of the meeting and, like, how they might be able to support you or be there for you is helpful in making them feel a little more relevant and personal. And I had mentioned that our Boost daily meetings or daily syncs, you know, are a little too big for people to really get into, you know, sharing a fun, personal anecdote, or whatever.

+ +

But one thing that I really enjoy is that whoever goes last in giving their update gets to choose the sign-off for everyone. So maybe that's like, okay, we'll just go out on a wave, and we all wave. Or maybe it's, you know, like, making a little heart with your hands. And then there's some folks on the team who go really wild and, you know, come up with something totally unexpected. And I think, you know, that spontaneity is so fun. And we all share it in this collective act of...I'm trying to think of a funny one lately, maybe, like, sinking down into your chair until you disappear from the view [laughs]. That's a good one.

+ +

JOËL: Sometimes it's those, like, small social rituals that can be really meaningful.

+ +

STEPHANIE: Absolutely. Do you have a favorite sign-off that you have either requested or have done?

+ +

JOËL: So, I typically just go for the wave if I'm last because I've not thought about it. But I generally think it's fun to have everybody try to mimic an emoji. So, it might be like, oh, everybody do the, you know, See-No-Evil emoji, or everybody do the party parrot. Those are pretty fun to sign off on.

+ +

STEPHANIE: Oh yeah, [inaudible 29:15] pausing is good. I think another one I like is, "Everyone do your best impression of a tree." [laughs]

+ +

JOËL: Sometimes, too, it's fun to do something that's relevant to the particular day. If there's something special happening that day, you get something relevant. I've done before, if it's on a Friday, say, "Everybody do your best Rebecca Black impression."

+ +

STEPHANIE: Yeah, also excellent.

+ +

JOËL: Because, you know, it's Friday.

+ +

STEPHANIE: Yeah, like, a little moment of collective celebration for the weekend. On that note, it's a Friday we're recording this episode. Shall we wrap up and look forward to the weekend?

+ +

JOËL: [laughter] Fun, fun, fun, fun.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie had a small consulting win: saying no to a client. GeoGuessr is all the rage for thoughtbot's remote working culture, which leads to today's topic of forming human connections in a virtual (work) environment.

+ +
+ + + +

Transcript:

+ +

JOËL: And this is just where it ends.

+ +

[laughter]

+ +

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, I have a small consulting win, or even just a small, like, win as a human being [laughs] that I want to share, which is that I feel good about a way that I handled saying no to a stakeholder recently. And, you know, I really got to take them where I can get it because that is so challenging for me. But I feel really glad because we ended up kind of coming out the other side of it having a better understanding of each other's goals and needs.

+ +

And so, basically, what happened was I was working on a task, and our product owner on our team asked me if it could be done by next week. And immediately, I wanted to say, "Absolutely not." [laughs] But, you know, I took a second and, you know, I had the wherewithal to ask why. You know, I was kind of curious, like, where was this deadline coming from? Like, what was on her radar that, like, wasn't on mine?

+ +

And she had shared that, oh, you know, if we were able to get it out before this big launch, she was thinking that it actually might make our customer support team's lives easier because we were kind of taking away access to something before some new features rolled out. And, you know, there might be some customers who would complain. And with that information, you know, that was really helpful in helping me understand. And I'm like, yeah, like, that seems like a helpful thing to know, so I could try to strive for it. Because I also, like, want to make that process go easier as well.

+ +

But I told her that I'd let her know because I honestly wasn't sure if it was possible to do by next week. And after a little bit of, you know, more digging, kind of seeing how my progress was going, in the end, I had to say that I didn't feel confident that we could finish it in time for that deadline because of the other risks, right? Like, I didn't want to just release this thing without feeling good about the plan that we had. And so, that was my small, little win in saying no, and I feel very proud of myself for it.

+ +

JOËL: I'm proud of you too. That's not easy to just do in the first place, and then to do it well is a whole other level. It sounds, though, that you came out of the other side with the client with almost, like, a better relationship.

+ +

STEPHANIE: Yeah, I think so. In general, you know, I really struggle when people do end up getting into that debate of, like, "Well, I need this." And someone else says, "Well, I need this other thing." And, you know, at some point, it kind of gets a bit unproductive, right? But I think this was a very helpful way for me to see a path forward when maybe we, like, have different priorities. But, like, can we better understand each other and the impact of them to ultimately, like, make the best decision?

+ +

The other thing that I wanted to share that I learned recently was there was a recent RailsConf talk by Elle Meredith, and it was about strategies to say no, and I watched it. And one really cool thing that I learned was that the word priority, you know, when it was first created, it actually didn't really have, like, a plural form. There was really only ever, like, a singular priority. And it wasn't until, I think, you know, the recent century or something like that, that people started to use it in a plural form. And that was really enlightening to me.

+ +

I think it made me rethink the word and how I use it, and it made a lot of sense, too. Because at any given moment, you know, really, you can't be doing more than one thing; I mean, you can try. I know that I have been guilty of multitasking. But that, you know, doesn't always serve me. I never end up doing all of the things that I'm trying to do well. And I would be really curious to kind of, you know, when I do feel that urge, like, think a little bit about, like, what is the one thing that I should be doing right now that is the highest priority?

+ +

JOËL: I would definitely second that recommendation for this talk. I actually got to see it live at RailsConf, and it was excellent.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I got to participate in a really fun event at thoughtbot today. We got together with some other people on the Boost Team and played a few rounds of GeoGuessr. And for those who are not familiar with this game, it drops you randomly somewhere in the world in Google Street View. You can move around. And there's a timer, and you have to drop a pin on a map where you think you are.

+ +

So, you're walking through the streets, and you're like, okay, well, I don't know this language. I'm not sure where we're going. You know, with the vibes going here, I'll bet, you know, this looks like maybe southern China, and then you drop a pin. And oh no, turns out it was actually Singapore. And there's all these little hints and things. People who are really into it have learned all these tricks, and they can be really good. Sara Jackson, who is our resident GeoGuessr expert, is excellent at this. But it was a good time.

+ +

STEPHANIE: Yeah, it was really fun. I liked that we played a cooperative mode where we were all kind of helping each other out. And so, maybe someone is, like, exploring on the map and sees a street sign and is like, "Oh, like, that looks like this language." And someone else is like, "Oh yeah, like, that is that." Or like, "No, I think it's actually this other language," and sharing all of the different, like, pieces of information that we're finding to get closer and closer to what it might be.

+ +

And then we celebrate whoever ends up getting the closest because, at some point, it's kind of just, like, just a luck of the pin, right? Where maybe you happen to click on, like, the right place. But it's always really exciting when we're like, wow, like, Sara was only 500 kilometers away in finding the exact place that we were served. So, I had a good time as well.

+ +

JOËL: So, speaking of cooperative events, this was a work event that we did. We just got together and played a game. And, for me, that was a really fun way to connect with some of my colleagues. I'm curious, what are your thoughts on things that you've seen done well in companies that are remote-first that really foster a sense of connection and community among a team?

+ +

STEPHANIE: I think this worked especially well today because it was kind of scheduled in regular time that we have as a team to me. And sometimes, you know, the meeting topics are a bit more work-focused. But what I really like is that anyone on the team can host one of these meetings. We have them biweekly, and we just call them Boost biweeklies. Boost is the team that Joël and I are on.

+ +

JOËL: Naming is the hardest problem in computer science.

+ +

STEPHANIE: It really is. But I really like that people can bring, you know, a little bit of their own flavor to this meeting. So, whoever is host just kind of comes up with something to do. And sometimes it's like show and tell. You know, other times it is more of like, you know, what's the update on some of the projects that we're doing? Other times, it's the Spicy Takes Lightning Talks that we've kind of mentioned on the podcast before. And yeah, it is just a really nice, like, time for us to get together.

+ +

And I also feel like I learn something about my co-workers every time that we meet, whether it's the person who is hosting the meeting and kind of where their interests are. I think someone even did, like, chair yoga once and guided the team in doing that. Or because they are more casual, right? Sometimes we just play a game, and I really enjoy that nice break in my day.

+ +

JOËL: Do you find that the particular style of these meetings makes you feel more connected to your colleagues? Would you prefer just kind of game day one, like we had today, versus maybe, like, lightning talks or a presentation on security or something like that?

+ +

STEPHANIE: I actually think the diversity is what makes it special. I get to see, you know, a bunch of different sides of my co-workers and, you know, some days, the topic is a little more serious, and that can be really connecting. Another Boost Team member had hosted a biweekly where we kind of shared the challenges of, like, consulting work and, like, onboarding onto a new project and sharing what might be difficult and, like, how we might be feeling when we do join a new project.

+ +

And I think that was really helpful because it was very validating for something that I thought, like, maybe I felt a little bit more alone in. And the tone was a little bit more, like, earnest and serious. But I came away with it feeling very supported by my team, right? And other times, it is just silliness and fun [laughs], which, you know, is also important. Like, we need to have fun every once in a while.

+ +

JOËL: That's awesome. Do you feel like when you go to these meetings, you're looking more for knowledge or looking more for connection?

+ +

STEPHANIE: I think both because knowledge sharing is also, you know, can be really helpful. Like, I have enjoyed learning that, you know, so and so is, like, a GeoGuessr expert, Sara, right? And so, if I ever, like, find myself needing [chuckles] someone to go to about my Google Street View or world geography questions, I know that I can go to her. And, like, knowing that about her, like, makes me feel more connected to her. So, I think both are true.

+ +

So, we have been talking about a meeting style form of connecting in a remote workplace, but I'm really curious about your thoughts on asynchronous versus synchronous communication and how you find connection with a format that is more asynchronous, not just, you know, being in a meeting together.

+ +

JOËL: That's really challenging. I think I personally find that something that's mostly synchronous with maybe a little bit of a lag works pretty well for me, so something like Slack, where it's not exactly real-time because someone could take some time to come back to me. But for working hours overlap, there's likely some close-to-synchronous conversation happening.

+ +

But, you know, I can still get up and, you know, refill my cup of coffee, or it's not quite like I'm sitting in front of a camera. So, I think that, for many things, hits the sweet spot for myself. But there's definitely some things where I think you want a higher, like, information density. And that's, I think, where the synchronous face-to-face meeting really shines.

+ +

STEPHANIE: Information density. I haven't heard that phrase before, but I like it.

+ +

JOËL: The idea being, you know, how much information or how many words are you sharing back and forth, you know, per minute or something like that. And when you're talking on a call, you can do a lot more of that than you can going back and forth over Slack or writing an email.

+ +

STEPHANIE: So, I would say that at thoughtbot, we have a pretty asynchronous Slack culture, which I think can be quite different from other, you know, places I've worked at before or other Slack spaces that I've seen. And I actually find it a little bit harder to engage in that way. We have a dev channel where, you know, people chat about different technical topics. And sometimes, you know, those threads go, like, 40 replies long. And I think you tend to engage a lot more in those.

+ +

And I'm curious, like, does that scratch the itch for you in terms of that perfect, like, async, kind of some amount of lag for you to be doing other things, kind of doing your work, but then being able to come back and pick up the conversation where I left off?

+ +

JOËL: Yes, that is really nice because, you know, maybe I have a meeting or something, and I'm not there when the conversation starts, but I don't miss out. And I get to join in, you know, maybe 30 minutes after everyone else. You know, sometimes you don't want to just, like, restart a conversation that's happened and is done. But some of these things will kind of be going on and off all day. And those can be really fun, especially sometimes, like, a new person joins the thread and brings in a totally new perspective or a new angle that kind of, like, breathes new life into it and kind of gives everyone a new perspective.

+ +

STEPHANIE: Nice. I also think there's something to the idea of seeing more people engage with something that then invites other people to engage with it.

+ +

JOËL: I would agree with that. It's definitely exciting to see a thread, and it's not like, oh, it's empty, and I'm the only one who's put a response in here. When there is a lot of back and forth, you can almost feel the excitement. And that gets me hyped to, like, keep it going.

+ +

STEPHANIE: At a previous workplace in our Slack, we had a, like, virtual Jeopardy channel.

+ +

JOËL: Ooh.

+ +

STEPHANIE: And so, there was a little Jeopardy bot. And I guess whenever someone, you know, had a low on what they were doing, they would just start, you know, tagging the bot to pose a question. And anyone can answer, right? But once you kind of got the ball rolling, you would see other people start playing as well. And it would get really active for segments of 30 minutes or so.

+ +

And I always really enjoyed that because, yeah, it was a way for me to remember like, oh yeah, there's, like, other people also, like, typing away on their little keyboards, and we're all here together. But it was really interesting to see, like, when someone got it rolling, like, oh, other people, like, joined in.

+ +

JOËL: Yeah, being able to see small things like that can really build a sense of connection, even if you're not yourself directly participating.

+ +

STEPHANIE: Yeah. I think another thing I've been trying out lately is letting people know that I'm in a meeting space and offering to virtually co-work. So, you know, during the early days of when thoughtbot went remote, we had a lounge virtual meeting space for people to hang out with and, you know, get that face time that they weren't getting anymore since we weren't in the office. And, you know, I think that has kind of decreased in terms of engagement over, you know, several years now. And obviously, people have a lot of meeting fatigue and stuff like that.

+ +

But I was kind of in a mood to revive it a little bit because, yeah, I kind of got over the meeting fatigue and was wanting more face time with people. And the unfortunate thing, though, is that, like, no one was showing up to this room anymore. So, you know, even if someone wanted to hang out in it, you know, they go in. They see no one's there, you know, maybe they stay for a few minutes, but then they're like, okay, well, I'm just going to leave now.

+ +

And a couple of thoughtboters and I have been trying to revive it where we'll post in our general channel, like, "Hey, like, I'm in this meeting room. Like, come hang out for the next hour if you would like." And that's been working well for me. I have had a few, like, really nice lounge, virtual co-working hangout sessions. Even if one person shows up, honestly, like, that fulfills my want to just, like, speak to another human. [laughs]

+ +

JOËL: What does virtual co-working look like? Are you just kind of each doing work, but you've got a video camera on, and you're just aware of the presence of someone else? Do you kind of have, like, random breaks where you talk? What is that experience like?

+ +

STEPHANIE: Oh yeah, that's a good question. I have to say; for me, I'm just talking to the other [laughs] person at that point. I'm not really doing a whole lot of work. And, you know, in some ways, I almost think that, like, in those moments, I am really wanting to chat with someone and, like, that's okay, right?

+ +

JOËL: It's like a virtual water cooler for you.

+ +

STEPHANIE: Yeah, exactly. Like, that would be the moment if I were working in office that I would wander into the kitchen looking for a snack but also an unsuspecting victim to start [laughs] a conversation with.

+ +

JOËL: I feel you. I feel you. I have absolutely done that.

+ +

STEPHANIE: Yeah. And that's actually what makes me feel a little less guilty about it. Because, you know, when I was working in the office, like, that was such a big part of my day, and it's kind of what kept me motivated. And at home, I do find myself, like, a lot more productive. In fact, like, I think I am because I'm, you know, not spending that time wandering into the kitchen. But at what cost? [laughs] At the cost of, like, me feeling very, like, lonely and, like, kind of burnt out at the end of the day.

+ +

So, injecting my day with some of these moments, I think, is important to me. And also, again, like, I know that I'm being really productive in my, like, heads-down-time that I want to, you know, allow myself to just like, get that dose of connection.

+ +

JOËL: I know, for me, when we were doing things like this in person as well, those conversations that happen, yes, there's some random, frivolous stuff, but sometimes, it is a conversation related to work that I'm doing. Because, you know, someone who's not on my project is like, "Hey, how's your project going?" Or whatever. I'm like, "Oh, well, I'm, you know, doing this ODBC connection, and I'm kind of stuck." And, you know, we kind of talk about a few things. It's like, "Oh, did you know about this gem?" And it's like, "Wait, why didn't I talk to you earlier? Because this totally solves my problem."

+ +

STEPHANIE: Yeah, I think that being a sounding board is so valuable as well. So, I guess I enjoy virtual co-working, not necessarily, you know, us, like, sitting together and doing our work separately. Though I know that there's value in that, especially in real life. Like, I remember reading an article. I'll try to find it and link it. But the idea of just, like, sharing space with someone can be, like, a form of bonding.

+ +

But I do really enjoy just hearing about what other people are working on and just kind of, like, asking questions about it, right? And maybe we do take away, like, a new perspective or, like, have some insights about, like, the work itself. And, yeah, we don't really get that when we're working remotely by ourselves because there's no one to turn to and be like, "Hey, what do you think about this problem?"

+ +

JOËL: I love how no matter what the topic is that we're discussing on this show, you always have a book or an article or something that you've read that you can reference. And I think that's amazing.

+ +

STEPHANIE: Thank you.

+ +

JOËL: So, you're talking about things that have really helped you feel a deeper sense of connection. I had a realization recently about the power of physical items. In particular, as consultants, sometimes we work with clients who, for security reasons, want us to work on a dedicated laptop for this particular client. And so, we'll have clients maybe—well, now that we're remote—ship us a laptop, and we work on that laptop when we're doing client stuff, and then on our thoughtbot laptops when we're doing thoughtbot things.

+ +

And when I've been on clients like that, I have felt much more isolated from the thoughtbot team. And just, like, physically switching over to the thoughtbot laptop, all of a sudden, gives me that feeling of connection. And there's something I can't quite explain about the power of the physical item. And, say, I'm working on the thoughtbot laptop today with, you know, thoughtbot Slack in the background or whatever, and I feel more connected to my colleagues.

+ +

STEPHANIE: Yeah, that is really curious. Did you also have thoughtbot communication channels open in your client laptop during that time?

+ +

JOËL: I did, and yet still felt more separation.

+ +

STEPHANIE: Yeah, that's really interesting. The way you're describing it, it was almost like, you know, the main laptop that you work with, with your, like, all of the settings that you like, all of your little shortcuts, you know, the autocomplete to the whatever, like, channels of communication that you are used to seeing. In some ways, that almost feels like home a little bit. And I wonder if working on a client laptop almost kind of feels like, you know, being in a stranger's house, right?

+ +

JOËL: There's definitely an element of that. Yeah, all the little things I've fine-tuned, some of the productivity software I have on there that are just, you know, I can one by one set them up on the client laptop, depending on permissions. But yeah, it's never quite the same.

+ +

STEPHANIE: So, when you are in a situation where you're mostly working from a client laptop and maybe embedded in their Slack workspace, embedded in their team, how do you go about investing in connection with your client team?

+ +

JOËL: So, you know what's kind of weird? Is that when I'm on a client laptop, I feel less connected to my colleagues at thoughtbot, but the reverse is not necessarily true. I don't feel more connected to colleagues on a client team on a client laptop than I would on my thoughtbot laptop. So, I'm not exactly sure what the psychology is going on there. But I feel kind of most connected to both when I'm working on my thoughtbot laptop, which is perhaps a bit strange.

+ +

STEPHANIE: Oh, yeah, that is interesting. I think, in general, there's an aspect of joining a new client team and trying to figure out the culture there and how you might engage with it, right? And how what you bring to the table kind of fits in with how they do things, and how they talk about things, and how they behave. In some ways, it's kind of, like, you know, an outsider joining this, like, in-group, right? So, I've definitely realized that the ways that I engage and feel connected at thoughtbot, like, may or may not work for the client team that I'm joining.

+ +

JOËL: Yeah. And onboarding onto a client team is not just a technical exercise, right? It's also a social process where you want to get to know the other people on your team, get to sort of integrate into the way they work, their processes, hopefully, build a little bit of, like, personal connection with individuals because all of those are going to help me do my job better tomorrow, and the day after, and the week after that.

+ +

STEPHANIE: Yeah. I had mentioned previously that one thing that I've been enjoying on my client team is our daily sync question. So, a random question will be generated, you know, like, "What are you eating for dinner today?" Or, like, "What are you looking forward to this weekend?" And folks are able to share. And the fun thing is that sometimes the answer to the question is longer than their work update itself.

+ +

JOËL: Nice.

+ +

STEPHANIE: But that is actually the, you know, the beauty of it because we all just, like, get to laugh and get to, you know, chime in. And I'm like, "Oh yeah, like, that sounds delicious, like, what you're eating for dinner tonight." But, like, that would not work for our Boost Team's sync because, you know, it's a much bigger meeting with sometimes up to, you know, 20 to almost 30 people and, like, we can't quite have as much time spent talking about the fun question of the day. So, I definitely think that, you know, it depends your team size, and makeup, and whatnot.

+ +

JOËL: Are those questions kind of preset, or do you all get to contribute questions to the list?

+ +

STEPHANIE: We brainstormed the questions one retro when we were realizing that we were kind of getting a little bored of the existing question that we had. And we came up with a handful that is plugged into, like, a website, or, like, an app that randomly, you know, picks the question of the day. And so, I think, again, when we get a little bored of the ones that we have in rotation, we'll throw in some curveballs in there.

+ +

JOËL: Have you ever considered adding "What's new in your world?" to this rotation?

+ +

STEPHANIE: It's funny you mentioned that because it's actually the question that we got a little bit stale on. [laughs]

+ +

JOËL: Really?

+ +

STEPHANIE: And we needed to inject some new life into, yeah. It's a classic, you know. But I think the variety is nice, especially since we're meeting almost every day. And before we started recording, you and I were just talking about how even sometimes it's tough to think of something that's new in our world [laughs] because we don't always live the most interesting and, you know, new lives. And sometimes, we kind of just have to dig deep to come up with something, and we only meet weekly. [laughs]

+ +

JOËL: I can definitely see how doing this daily might be more challenging. I think there's also value in questions that are a little bit more focused. Part of what's fun for this podcast is that "What's new in your world?" is so kind of broad. But maybe for something daily, having something really specific, like, what did you eat for dinner tonight? Means that you aren't just kind of drawing blanks in your mind, like, uh, uh, what is new in my world? What have I done? I don't know; I have a boring life. I don't do anything. Kind of panic mode that you can sometimes get when you hit a meeting.

+ +

And so, I do know that when I've been sometimes in situations with people where you have questions like that, I've tended to really appreciate the more targeted ones.

+ +

STEPHANIE: Yeah, that's so interesting you mentioned that because I think in social situations, there's usually maybe, like, someone who is really good at asking those, like, specific questions to get the group talking and, like, you know, engaged in a fun conversation, and that specificity helps.

+ +

One thing that I was just wondering about is the value of meeting every day in a sync kind of format, and I'm curious if you think that is important to you. If you have been on other teams that don't meet every day, maybe they have, like, a virtual check-in, right? Like, a virtual reminder to share what they're working on as opposed to meeting synchronously.

+ +

JOËL: I think I've seen sort of different purposes for sync meetings. Sometimes it's very kind of project-heavy, right? You're talking about the tickets you're working on for today. The reason you're having that is specifically for status updates or because you are blocked, and you want somebody else to help unblock you. So, it's very process-focused. I think that varies team to team, but it can be really helpful.

+ +

Even I've been on projects where it's maybe me and one other person, and we'll have kind of an informal just call each other up every morning and say, "Hey, here's what I'm working on today. Here's kind of roughly the strategy I plan to take on it. And we'll go back and forth." And for something like that, it inevitably also somewhat turns into a bit of a social call, so that's planning and social. And I think that can be really strong.

+ +

STEPHANIE: Yeah, I like that a lot.

+ +

JOËL: That's not necessarily going to be the case for every team, every project, especially with larger teams. And I feel like for something like the Boost Team at thoughtbot, we have a daily sync. We're not all working on the same project. So, I don't want to know about the specific details of the ticket you're working on. I'm more interested in getting just a little bit of face time with the whole of our team to feel a connection.

+ +

And, you know, maybe if you've got something cool that you want to share, and that can be a win. It can even be a struggle. And we can all kind of empathize, right? That, like, "Oh, I dropped production database this morning, and I'm kind of freaking out," is a totally fine thing to share. But "I am working on ticket 1, 2, 3, 4 to add some text to a part of the page," that's not particularly useful to me in the kind of sync that we have for the thoughtbot Boost Team.

+ +

STEPHANIE: Yeah, absolutely. I think knowing, like, who the audience is of the meeting and, like, how they might be able to support you or be there for you is helpful in making them feel a little more relevant and personal. And I had mentioned that our Boost daily meetings or daily syncs, you know, are a little too big for people to really get into, you know, sharing a fun, personal anecdote, or whatever.

+ +

But one thing that I really enjoy is that whoever goes last in giving their update gets to choose the sign-off for everyone. So maybe that's like, okay, we'll just go out on a wave, and we all wave. Or maybe it's, you know, like, making a little heart with your hands. And then there's some folks on the team who go really wild and, you know, come up with something totally unexpected. And I think, you know, that spontaneity is so fun. And we all share it in this collective act of...I'm trying to think of a funny one lately, maybe, like, sinking down into your chair until you disappear from the view [laughs]. That's a good one.

+ +

JOËL: Sometimes it's those, like, small social rituals that can be really meaningful.

+ +

STEPHANIE: Absolutely. Do you have a favorite sign-off that you have either requested or have done?

+ +

JOËL: So, I typically just go for the wave if I'm last because I've not thought about it. But I generally think it's fun to have everybody try to mimic an emoji. So, it might be like, oh, everybody do the, you know, See-No-Evil emoji, or everybody do the party parrot. Those are pretty fun to sign off on.

+ +

STEPHANIE: Oh yeah, [inaudible 29:15] pausing is good. I think another one I like is, "Everyone do your best impression of a tree." [laughs]

+ +

JOËL: Sometimes, too, it's fun to do something that's relevant to the particular day. If there's something special happening that day, you get something relevant. I've done before, if it's on a Friday, say, "Everybody do your best Rebecca Black impression."

+ +

STEPHANIE: Yeah, also excellent.

+ +

JOËL: Because, you know, it's Friday.

+ +

STEPHANIE: Yeah, like, a little moment of collective celebration for the weekend. On that note, it's a Friday we're recording this episode. Shall we wrap up and look forward to the weekend?

+ +

JOËL: [laughter] Fun, fun, fun, fun.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+c6cOp4-1 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 394: Submitting a Conference Talk Proposal from Start to Finish + https://bikeshed.thoughtbot.com/394 + 1ac55d12-6c36-4b14-ba34-91e47de5b64c + Tue, 25 Jul 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël recently had a fascinating conversation with some friends about the power of celebrating and highlighting small wins in their lives. He talks about bringing this into his work life. May Stephanie interest you in a secret she learned regarding homemade pizza? + +RubyConf is coming! Who's submitting talks?! It's hekkin scary. Don't fret! Joël and Stephannie are here to help. Today, they discussed submitting a conference talk proposal from start to finish. + 38:53 + no + + + Joël recently had a fascinating conversation with some friends about the power of celebrating and highlighting small wins in their lives. He talks about bringing this into his work life. May Stephanie interest you in a secret she learned regarding homemade pizza? +RubyConf is coming! Who's submitting talks?! It's hekkin scary. Don't fret! Joël and Stephannie are here to help. Today, they discussed submitting a conference talk proposal from start to finish. +Sheet pan pizza (https://anewsletter.alisoneroman.com/p/may-we-interest-you-in-a-party-of) +RubyConf CFP (https://sessionize.com/rubyconf-2023/) +Speakerline.io (https://speakerline.io/) +WNB.rb (https://www.wnb-rb.dev/) +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've come 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: I've been having a really interesting conversation with some of my friends recently about the power of celebrating and highlighting small wins in our lives, both in, like, kind of sharing it with each other, like, you know, if something small happens, it's good for me to share it with my friends. But also, where it becomes really cool is where the friend group kind of gets together and celebrates that small win for one person, and how that can be, like, a small step to take, but it's just really powerful and encouraging for a friend group. And I think that applies not just among friends but in a team or other grouping in the workplace. +STEPHANIE: That's so fun. How are you celebrating these small wins, like, over text? Is that the main way you're communicating something good that happened? +JOËL: It depends on the friend group. I think, like, different friend groups will have, like, a different kind of cadence for the kind of things they do. And do they all hang out together? Do they have a group text, things like that? +One of the friend groups I'm a part of, we meet weekly to go climbing at a rock-climbing gym, so that's kind of our hang-out. And [inaudible 01:34], we're there to do stuff at the gym, but it's also a social thing. And it's an opportunity to be like, "Oh, you know, did that thing workout, you know, at work?" "You know, good for you," Or "Did you get this project accepted?" And yeah, when small wins come up, it's a great time to celebrate. +STEPHANIE: That's awesome. I think having regular time that you see people and being able to ask them about something that they had mentioned previously is so special and really important to me, like, in bonding and building the relationship. +I also love the idea of celebrating milestones. So, this is, I guess, more of a bigger win, but milestones that aren't traditionally celebrated. You know, so, yeah, we'll have, like, a party when someone graduates or someone gets married. But I also have really enjoyed celebrating when someone gets a promotion at work. And, you know, maybe that's not, like, a once-in-a-lifetime thing, but it's still so worthy of going out for dinner or buying them a drink. +I also will maybe, like, send my friends a little treat if I know that they did something small but hard for them, right? And sometimes that's even, like, responding to a scary email that they had sitting in their inbox for a while. Yeah, I really love that idea of supporting people, even in the small things in life that they do. +JOËL: Yeah, and that's really validating, I think when you've done something hard and then a friend or a colleague reaches out to you. And it's kind of like, hey, I saw that. Good for you. +STEPHANIE: How have you been thinking about bringing this into your work life? +JOËL: I think it's about being on the lookout for things that other people do. And I think one thing I like to do is kind of publicly calling that out. It sounds like a negative thing, right? But just giving people kind of a public shout-out when they've succeeded at something. I think we're all kind of socialized not to maybe talk too much about accomplishments, especially if they feel kind of small and mundane. +Being somebody else, I think, gives you a lot more leeway to say, "Hey, no, Stephanie, I see that you did that thing. And maybe it feels kind of like, oh no, you're just doing your job, but I think that's cool. And I want to, you know, just give you a shout-out in the company Slack channel or something." It doesn't have to be something big. You know, I'm not sending champagne to your home. But having that opportunity to just kind of celebrate something small and say, "Wait a minute, let's pause and acknowledge that you just did something cool." +STEPHANIE: Yeah, I was thinking about how that's kind of, like, amplifying the win a little bit. I've definitely done this before, too, when I see someone share a win of theirs, maybe in a smaller Slack channel or kind of a personal level, or even just to me individually. And I really want other people to know that that happened to you and that they, you know, did an awesome job. And so, I have enjoyed, you know, sharing them more publicly on their behalf if they are comfortable with it. +JOËL: And I'll say on the other end of that, I think it feels really good to be acknowledged by someone else that you've done something that they recognize. It's fun to share a win with other people because you're excited, but it's doubly fun when somebody else shares it for you. +STEPHANIE: I agree. I think one thing that you, Joël, do really well, actually, is sharing your own personal wins in a very casual way. That's something I've always admired about you is how you recognize the small wins for yourself. +JOËL: It's taken me, I think, a long time to get to that and find a way where, you know, you are sharing things that are fun for other people to see, things that might be inspiring, things that are kind of cool, and that are not just kind of, like, self-aggrandizing, like, bragging about stuff. It can be a fine line to walk. And, to a certain extent, you're a little bit marketing yourself. But yeah, I think I've kind of hit that right balance. +STEPHANIE: Yeah, I think the thing that makes it work is that there's usually, like, a challenge or something that maybe you, like, went through a journey or overcame a little bit. And I think that's what is the inspiring part that makes me feel like, oh, okay, so, like, this is a realistic thing that, you know, Joël went through and, you know, he struggled with it maybe. But then, like, ultimately, you know, had some insights or came out the other side with some learnings. And I like that it's real, right? It's not just, "Hey, like, I did this, like, cool thing." It's like, "I went on this journey." And I find that really motivating when I am in that kind of situation next time. +JOËL: There's a power to stories, right? And I think especially when you can make something relatable to other people. So, it's not just like, "Hey, I did a cool thing," which, you know, is also fun. But being able to say, "Hey, I messed up," or "I, you know, had this challenging problem dropped in my lap, and here's the journey I went on to resolve it. Hopefully, it acts a little bit as like a here's a template you could follow if you're ever in that situation." But maybe also a little bit of, like, inspiration for others as well, just being like, hey, Joël, messes up sometimes. +So, Stephanie, what is new in your world? +STEPHANIE: Speaking of small wins, I have finally perfected our at-home pizza situation for making pizza at home, which I have been struggling with for so long. Because I always was excited by the idea of making pizza and, you know, sometimes we would make our own dough. And sometimes, we would buy store-bought dough, but it never ended up being as crispy and cooked well-done the way that I want it to. +It was always, like, a little bit mushy on the inside. The dough wasn't totally baked. And I would inevitably be disappointed when I had been, you know, building that excitement for pizza. And the other week, I found a new recipe to try, and I think it will be my new go-to recipe for making pizza at home. +JOËL: I don't know if I'm allowed to ask this on air, but what's the secret? +STEPHANIE: The secret? Well, okay, the first secret and/or learning that I've gathered is to not put as much sauce, cheese, and toppings as you think you want to because that's definitely what contributes to the under-doneness of the dough. But I pivoted to trying a more grandma-style crust that is kind of more like focaccia; really, you know, it involves a lot of olive oil. And you're cooking it for a while on pretty high heat to ensure the crispness and, you know, that it's cooked through. +And, I mean, I love focaccia bread, so I don't mind it as, you know, the base of my pizza. It is a bit different from, you know, other kinds of pizzas. And if we had, like, a really, you know, fancy pizza oven to do the, like, super high heat, like, Neapolitan-style deal, I would also really enjoy that. But you know what? That's just not the reality of my home kitchen. +So, I have really been enjoying this pizza recipe by Alison Roman that I will link in the show notes. But yeah, it has really changed my at-home pizza game. And I hopefully won't have any of my, you know, soggy dough bottom problems anymore. +JOËL: So, you mentioned just kind of offhand, like, oh yeah, you know, the crust is just kind of, like, how you make focaccia. It sounds like you've made focaccia yourself before. +STEPHANIE: I have made focaccia at home, and so I think applying it to Pizza was a real, like, light bulb moment for me. But, you know, it's not, like, totally effortless. But I think it's a lot more forgiving than other types of bread and, therefore, other types of pizza crust. +And the one really enjoyable thing about making focaccia is there's a step where you use your fingers, and you're kind of holding your hands like you're playing a piano. And you, like, press into the dough after it has risen a little bit to create dimples and, you know, lets the oil kind of seep into the little holes. And it's very satisfying. It's a very good feeling. +JOËL: The kind of the tactile aspect of it? +STEPHANIE: Yeah, exactly. It's very fun. [chuckles] So, yeah, it's just an added bonus to my pizza adventures. +JOËL: A win on top of a win. We'll take it. +So, there's some news in the Ruby community this week because RubyConf has just opened their CFP, their call for proposals. And so, they're asking for people to submit their ideas for conference talks, and if you're lucky, you get picked to speak at the conference. +And, Stephanie, I know that over the course of a year, you have a document where you collect conference talk ideas so that you have ideas to work on when the CFP comes around. Are you looking at any of them to potentially submit to RubyConf this year? +STEPHANIE: Joël, I have to be honest with you; so far, I only have one idea on that list. [laughs] But that is one that I suppose could eventually become a conference talk proposal. +So, when I heard the news, I definitely went down the rabbit hole of revisiting that idea and kind of starting to think about if it's something I wanted to pursue. I think the answer is yes. I definitely got a big push of motivation when I was like, oh, it's open. Like, now I can just get started if I want to. And then I was like, well, it's open for a month, so I could also just sit on it a little longer, you know, put it aside and revisit it when I have a little more time. +But yeah, I was pretty excited because I think it gave me the motivation I needed to really think a little more deeply about this idea that I have. Otherwise, I think it would have continued to sit half-baked in my document for a long time. +JOËL: And just for all of our listeners, the CFP just opened on July 12th, and it closes on August 20th. So, if you are listening and it's before August 20th, you still have a shot to submit your idea to be a speaker. +STEPHANIE: Something that I've talked about with my other friends who enjoy speaking at conferences is how they come up with proposals, and I found that we all have different approaches. And I am really interested in digging into this further with you. +But I realized that, for me, I really struggle with just, like, throwing out ideas and submitting them before I feel really confident that it's something that I have interesting things to say really, or, like, kind of adding a new perspective, or maybe approaching a topic that hasn't been approached before. I feel sometimes a bit hindered by my process, where I need to feel really confident before submitting something. +Because a friend of mine she was telling me that her approach is to submit CFP for topic ideas that she wants to explore further. So, maybe it is something that she doesn't know a lot about yet, and she's using this process to learn more and dive deeper, and that, you know, gives her a reason to do that, whereas that seems really scary to me. +JOËL: That's really interesting because it sounds like kind of an underlying motivation for your friend for submitting these talks is curiosity, exploration. And thinking back to myself, I think I usually submit ideas that have me excited or passionate, so that's kind of my underlying motivation for a talk. What would you say is maybe your underlying motivation when you're pitching an idea? +STEPHANIE: Yeah, I think, for me, it is impact and, like, having an impact, especially for something that I've struggled with and wanting to share my experience and, hopefully, sharing something where other people can relate to. +It's funny you mentioned that your motivators are, you know, excitement and passion. Because another person that I kind of had this conversation with mentioned that she writes talks based on experiences that have been very aggravating [chuckles] and painful for her. So, that ends up being, you know, a big motivator because she's so frustrated. [laughs] And, you know, wants to share this journey that she went on from a point of, I guess, maybe similar to me, like, making it easier for someone else who might find themselves struggling with the same problem. +JOËL: I kind of like the idea of taking that to an extreme, and you're, like, rage submitting. +STEPHANIE: Yeah, I feel like there would just be an infinite number [laughs] of topics that you could come up with in that case. +JOËL: Like, I'm so angry at this bug. It cost me a week of my life. And now, it is going to get the spotlight on it at RubyConf. And I get to share that moment with everyone, express a lot of emotions, and, hopefully, save everyone else from having to do the same thing I did. +STEPHANIE: Yeah. Or this terrible bug cost me a week of my life, and now you all get to hear about it. [laughter] Let me tell you -- +JOËL: Yes. +STEPHANIE: Exactly all the problems that I had to deal with. +JOËL: And, honestly, as a narrative, it kind of works, right? There are different types of talks. Sometimes you go to a talk because you really want to learn a deep topic. Sometimes I just want to go and listen to, like, a good horror story. If someone's a good storyteller, like, yes, there are lessons I can take away from it, and I can be like, okay, this is what I can do. And I heard Stephanie talk about this bug, and so I'm going to use inspiration from that the next time I hit a bug. +But sometimes it's also just good to, like, go there and sit and be, like, yes, I've been there. Yeah, kind of following along with the story and, you know, kind of the ups and downs because it is so relatable. +STEPHANIE: Yeah. And I like that you mentioned that there are different types of talks that leave the audience, you know, with different things. Because I know some people who have been interested in speaking in the past maybe feel a bit hesitant to because they don't think they have something to say, or, like, they don't have something to share that other people might find interesting. +And to that, I really believe that everyone has something that they are knowledgeable about and something that they can bring to others that is valuable. Even if it's not for every single person at the conference if you give a talk that is meaningful to a handful of people, right? Especially because, you know, there's people of all different kinds of levels at these conferences. Those are really important too. In fact, I think it can be even more powerful because they are targeting a specific audience. +JOËL: And I think you've hit on a key point, that is, it's great when you're building the talk, but even when you're pitching the idea is, who is this talk for? Who is the audience for this talk? And if the audience is whoever shows up at the conference center, maybe you need to workshop a little bit more. +STEPHANIE: Yeah, because one thing can't really be for everyone. +JOËL: Right. You're kind of diffusing its impact at that point. You were talking about how sometimes it's difficult to take an idea, flesh it out, and submit it until you're feeling, like, 100% confident about it. I'm curious how the transition goes from kind of the earlier phase of, like, you have a document, and I assume these are, like, bullet points with, like, one sentence, or maybe even just title idea. How does it go from bullet point to multiple paragraphs that might be submittable? +STEPHANIE: Yeah, that's a good question. I think it starts as a bullet point because maybe I notice something that caused me pain or caused a teammate pain, and maybe we had, like, kind of an interesting discussion about it. And, yeah, I write it down as something to explore further as, like, is this an idea that can be a little broader in scope, can have a few more applications beyond this particular instance that sparked it? +And so, maybe from there, I will think about, like, okay, like, the pain point that I jotted down was coupling and tests, right? And let me go, you know, jog through my memory of other times where I kind of felt a similar thing or was doing some code review and also noted a similar problem. +And I think if I am able to find enough, like, supporting examples that might go along with this, for me, it's really a feeling. [laughs] Then I'll try to extract that a little further and come up with a theme, right? A theme that's a little more encompassing because what I hope to do is to be able to come up with some kind of takeaway that can be a strong thesis for a conference proposal. +JOËL: And that's kind of how conference proposals work, right? There's a few different sections you have to fill out. But the really important one is the abstract, which is usually just a few sentences. It's character limited. And that's what is got to sell your talk both to the committee, but then also, that's what's going to be publicly viewable. And so, that's what's going to get people excited to show up at your conference room. +So, my kind of secret trick for writing a proposal is to do the abstract last. Even though it's that first section on the form, I struggle to write a compelling abstract. And so, I'll go through and fill out some of the other fields that are only for the committee, and there'll be, you know, a lot of detail in there. And then, sometimes, I find that I put, like, really good compelling sentences in there, and I'll pull them out and put them in the abstract and kind of use that to start. +But those other sections, like pitch and all that I think they're a great place to start because you get to go a little bit more into detail. And you can talk about here are the themes I want to address. Here are maybe the examples I'm going to be building around. Here's the audience that I want to speak to. +STEPHANIE: Audience is interesting for me because I tend to write the kind of talks that I wish I had watched earlier or, like, what really speaks to me. In fact, one of my first conference talks was literally called The Intro to Abstraction I Wish I'd Received. [laughs] So, that is a good place for me to start, is thinking about like, well, like, who was I at the time? Like, what kind of developer was I at the time that I, like, really needed this information or really wished for this information? +And similarly, I had mentioned, you know, like, maybe my ideas are coming from conversations I've had with other people. So, I'm imagining those other people, and I'm asking myself, like, who are they? Like, where are they in their development careers? And is there a specific demographic or audience persona that kind of fits them, and, you know, usually there is, right? +And what is nice is I can kind of go to them as well and be like, "Hey, like, I have this idea. Do you think this would be helpful for you? Or is this something you would be interested in watching?" And that at least helps me ground it in an audience that is real to me as opposed to kind of trying to imagine who might show up without a clear idea, like, of what they might get a takeaway or, like, be wanting in a conference talk. +JOËL: Would it be fair to say that when you're coming up with an idea for a presentation, the audience you have in mind is you or maybe a particular version of you, so you two years ago or you five years ago? +STEPHANIE: Yeah, I think that's a really compelling way for me to write these because, you know, I almost think it kind of goes back to the idea that everyone has something to say, right? It's like I have something to say to me, my past self. And I believe that other people, you know, are in that position as well. And so, that's been my approach. +But I'm curious about yours because I think the types of talks that you write are maybe less about, like, what you wished you had learned earlier and more for a different kind of audience. +JOËL: Yeah, I think they are...I start with a topic that I'm excited about. And then, sometimes, I have to find what element of it that I want to pull out because it can be kind of a whole kind of cloud of themes, and I have to pick one to commit to. Depending on the one I commit to and the approach I want to take, it will define the audience that...or vice versa. I can say, okay, this is specifically for this audience, and that will show how I want to approach it. +So, for example, I gave a talk at RailsConf this past spring on the math every programmer needs, talking a little bit about discrete math and how it's applicable in day-to-day programming. And I think I very quickly came to the realization that I wanted this talk to be for people who had never done a formal, like, discrete math class, likely people who don't have a traditional, like, CS background. +And so, once I knew this is the audience I'm speaking to, that really shaped how I pitched the talk, what elements I want to bring in, what examples I'm using, what do I want to emphasize during this talk. Finding that audience really helped that proposal come together. Even though I knew...before I found the audience, I knew I wanted to talk about discrete math and how cool and relevant it was to day-to-day programming. But that's not enough. I needed to really fit it to an audience. +STEPHANIE: Yeah, I have two thoughts about this. One was that when you were writing the proposal for this talk, I remember you had shared a bunch of your different ideas about the topic to your co-workers. And it was almost kind of, like, a buffet of topics. And you were asking for feedback about, like, hey, like, what is interesting to you? Like, what would be, like, helpful for you to know? And I think that ended up really helping you focus on, like, what your audience would want. +But I'm curious, do you recall, like, how you decided that you wanted to target people who didn't have that traditional CS background? Like, why was that important to you? +JOËL: I think I'm generally most excited about taking some, like, larger technical insights and bringing them to people who maybe have some of the intuition but don't always know why the things they do work the way they do and kind of bridging a little bit of that, like, practical, theoretical gap. That's the space that I'm probably most excited about when it comes to sharing and teaching, helping people go from things that are really practical and then just throwing just enough theory at them. But keeping it really grounded so that they can kind of hit the next level of where they want to be. Because that's an area that I think I thrive in, an area that gets me most excited to share about. +And so, I think, naturally, I'm kind of moving in that direction. But also, like you said, it's talking to other people and seeing, like, what are the elements that are interesting to you? And then, like, once you start seeing some of these, it's like, okay, well, what is exciting in talking about Boolean algebra? Do I want to go really deep on some of the theory? Do I want to say, you know, if someone has a vague notion of this because they've been writing code for several years but don't know the theoreticals behind it? That interaction, I think, was more compelling to me. +STEPHANIE: Got it. It's almost like knowledge sharing at just this really high level, or, like, at a really large scale. I like that a lot. +JOËL: So, you highlighted something interesting, and that is that writing a proposal doesn't have to be a solo activity, and getting feedback on ideas can totally transform your proposal. Do you find that you reach out to a lot of people to get feedback on your proposals? And what does that look like in practice? +STEPHANIE: Oh yeah, I definitely need someone to rubber-duck an idea for me. [laughs] +JOËL: So, even at the idea stage. So, you've got that topic sentence or whatever, and then you say, "Someone, can you sit down with me, and we'll just talk through places this might go?" +STEPHANIE: Yeah. I have found that really helpful for me. Otherwise, I think I get a little too precious about it, right? If I've just been working on it by myself. And then it feels really scary to submit it and be like, okay, I don't know if this is any good. It might get rejected. +But the first time that I did a conference talk, WNB.rb, the women and non-binary Ruby group I'm in, they had organized a CFP working group channel. And so, there were, you know, a handful of people, some of them writing conference talks for the first time, some of them having done it before, just getting together and holding each other accountable, and checking in and asking for feedback. +And, yeah, I think finding other people who either have done it before. I've also, you know, reached out to people whose conference talks I loved and felt really inspired by. And if they were available, like, kind of asking them how to get started. +But also, like, peer support as well, other people doing it for the first time can be really important in just making it feel a little more manageable, a little less lonely. I think there are, like, more people out there who are interested in dipping their toe in conference speaking than one might think because it can definitely feel very overwhelming. But with a support group, I think it makes it a lot easier. +JOËL: So, you've gotten feedback. You've gotten support. You've put this idea together. You're feeling pretty confident. You hit that submit button. And now you can't take it back. [laughs] How does that feel at that point? +STEPHANIE: Terrifying. [laughter] Like, for me, I have to exercise it from my mind and not think about it, not dwell on it at all. And like, ideally, you know, when I hear back, I will have forgotten all about it so that, you know, I didn't spend the whole month or however many weeks, like, ruminating about whether or not it was accepted. +Yeah, I really struggle with that part, I think, because I, yeah, have a hard time with rejection, you know, I'm just going to say it. [laughs] And, you know, it's hard for me not to take it personally. But I think that's actually one area that I want to get better at is to feel a little less, like, personally attached. And I think working with others helps me with that because it's not just something I've, you know, like, squirreled away and feel very attached to. +Working with others and then, like, hopefully, coming up with other ideas along the way, right? Within conversations that we have that might spark ideas for the future. So, knowing that if this one doesn't end up being submitted, there's always next time. There's always another conference season. And also, you know, celebrating others when their conference talks do get accepted that is also really buoying because it helps me direct that energy into wanting to celebrate my friends and inspiring me for next time. +Joël, I know you oftentimes submit more than one proposal, and I'm wondering if that helps with those feelings of being too attached to a topic idea or, you know, worrying about whether they will be accepted. +JOËL: I think it definitely helps with the attachment thing that I've not kind of put all of my work and all of my...like, pinned all of my hopes on one topic idea. Sometimes it can hurt, you know, if you've got, like, you know, two or three and, like, you just get multiple rejection notices in a day. That kind of sucks sometimes. But I think, in some ways, yes, it does help with that feeling of rejection because you've not tied yourself emotionally so much to a single idea that has to, like, succeed or fail. +STEPHANIE: Do you then submit those ideas to other conferences? +JOËL: The ones that get rejected? Yes. I've definitely resubmitted ideas. In fact, I plan to resubmit a rejection to RubyConf this year, so we'll see how that goes. Actually, now that I think of it, that could be a really fun opening line for a talk. Like, let's say it gets accepted. And, like, you know, you're on the stage, and you open it, and you're just like, "This talk got rejected." That'd be a fun intro. +STEPHANIE: Yeah, it would be. I think, oftentimes, you know, it's not always even about the idea itself, right? It's just about maybe the theme of the conference that year, and what they were looking for, and the direction they wanted to go. And there are other conferences or other another year, right? Where maybe there isn't another talk that touches on the same, like, area. And that will be the opportunity that it is a fit for the conference. +JOËL: Yeah, definitely. It is a little bit haphazard to get in. And just because your talk gets rejected does not mean it's a bad idea. It just means that it wasn't the best fit for that conference at that time. +STEPHANIE: I actually want to plug a website, speakerline.io, where people can post all of their, you know, proposals that they've submitted, whether they were accepted or rejected. And I found that resource really helpful in, you know, just knowing that, like, very good ideas get rejected sometimes, and that's okay. As well as, you know, kind of trying to get a sense of, you know, for the ones that were accepted, okay, like, what about these proposals really stood out or, like, really shine? And how might I get some inspiration from that to incorporate next time around? +JOËL: So, you've submitted a proposal. Terrifying. You're trying to not think about it for a couple of weeks, assuming you're submitting ahead a couple of weeks, I don't know. Are you a last-minute kind of submitter? +STEPHANIE: I'm a probably two or three days before the deadline kind of submitter. +JOËL: So, you've submitted the talk two or three days to the deadline. I guess, like, a couple of weeks after that to get review. And then, you get that notification that says, you know, you've got a response on your talk from the committee. Are you the kind of person that, like, drops everything and immediately looks at it? Do you kind of, like, wait for, like, maybe a moment where you're, like, more in a good zone emotionally before you open that email to find out if you're accepted or rejected? What's your strategy? +STEPHANIE: Oh God, I don't think I have the willpower to wait until I'm, you know, in an emotionally good state. I will just click on that thing. And yeah, I think, I mean, having been on the receiving end of accepting those rejections and once waitlisted, [laughs] which was a real doozy because it's like, great, like, now I have to write a talk. But, like, I don't know if it will actually be given or not. +I think this is also where the support group really shines as well because maybe some of my other friends are also sharing the results and making it okay, like, sharing a rejection, right? And I think it's nice to just have, like, an outlet for that, whatever the outcome is, and not having to just, like, sit alone in either the sadness or the happiness, right? Like, we're talking about celebrating small wins. Like, it really is even more special when someone else can validate your success. +JOËL: Have you ever had to navigate kind of, like, slight feelings of jealousy where it's, like, another friend gets in? Or maybe somebody else gets in with, like, your topic, and their talk got picked instead of yours? +STEPHANIE: Yeah, for sure. I think it's totally natural and human. I think one nice thing, though, is that there are so many conferences all of the time. You know, this is not a once-in-a-lifetime situation, right? And maybe the next conference, you know, the people who submit will be different, the people who review will be different. And you've kind of already done the hard part of writing the thing. +I actually was just thinking about a few of my friends are writers, and the submission process for them, you know, of spinning a book proposal or short stories for, like, a magazine or something like that, it's, like, fraught with rejections. And they've really built that muscle of acceptance and, like, knowing that it's not a reflection of their value, and building the resilience to keep trying. +And so, yeah, I think definitely going through that process has helped me feel a little bit more comfortable with that, not completely, but I guess it's like exposure therapy, [laughs], isn't it? +JOËL: I think that the not helpful answer here is that it gets better when you've given more talks. When you're trying to break in and give your first talk, right? It is such a big deal. And, you know, the high of getting accepted is just, you know, mountain top. But the feelings of rejection are also similarly intense. As opposed to when you've done a few, then it's like, you know what? Win some, lose some. And it's much easier to move on. +STEPHANIE: I think another suggestion that I might have would be to maybe start smaller, right? Even giving a talk at work for your co-workers, or even the next step is giving a talk at your local meetup or then a small regional conference. There are so many in-between steps, I think, that exist that bestow the benefits of giving a conference talk, and meeting new people, and feeling good about the impact you're having beyond some of the bigger, more traditional conferences. +So, if that does seem really scary or, you know, maybe you've given it a shot and feel a little bit demoralized from trying again, there is a group out there who will benefit and be interested in hearing what you have to say. +JOËL: That's a really important reminder because just because a conference rejected your talk doesn't mean that it's a bad idea. And yes, you can shop it around and bring it to other conferences, but maybe think about other venues for the idea. You've already done the hard work of crafting a pitch, so maybe turn it into a blog post and share it that way. +Maybe turn it into a pitch to be a guest on a podcast that you enjoy. Podcasts that do weekly guests are constantly looking for interesting people to talk to. And you've kind of, like, done all the work for them, where you can say, "Hey, here's the thing I'm an expert on. Ask me questions about this." And most places will gladly bring you on. +STEPHANIE: Yeah, I like to think of conference talks as really, like, a supplement of what you're learning and investing in in your career, right? You know, it is nice to be able to share all of those things in a perfectly wrapped package. But also, there are so many different ways for that to manifest. And there are people who know that speaking is not for them and really focus on writing, and that's, like, their avenue. But yeah, it's not...I don't think it's, like, a pinnacle of, like, something you have to do in your career at all. It's just something that can be fun. +JOËL: Yeah, and sharing takes many different forms. It can be a talk in a conference room, but it can just as easily turn into maybe some kind of video, some kind of written work. Like I said, it could be an interview on a podcast. There are so many different ways that you can share your ideas. And just because it didn't fit in one place, now that you've done the work to kind of polish that gem a little bit, oftentimes, it's very little additional work to just convert it to a different form. +STEPHANIE: Yeah, I like what you just said about polishing a gem. Really, I think the value for me is having a channel to funnel and reflect on my experiences, and, you know, conference talks happen to be, like, one form of that for me. But I hate to say it's about the journey, not the destination, but sometimes it is. And, yeah, I think everyone kind of has to, like, figure that out for themselves. +JOËL: That being said, sometimes the destination is pretty exciting. And when you open that email that says, "Congratulations, your talk has been accepted," wow, what a rush. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël recently had a fascinating conversation with some friends about the power of celebrating and highlighting small wins in their lives. He talks about bringing this into his work life. May Stephanie interest you in a secret she learned regarding homemade pizza?

+ +

RubyConf is coming! Who's submitting talks?! It's hekkin scary. Don't fret! Joël and Stephannie are here to help. Today, they discussed submitting a conference talk proposal from start to finish.

+ +
+ + + +

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've come 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: I've been having a really interesting conversation with some of my friends recently about the power of celebrating and highlighting small wins in our lives, both in, like, kind of sharing it with each other, like, you know, if something small happens, it's good for me to share it with my friends. But also, where it becomes really cool is where the friend group kind of gets together and celebrates that small win for one person, and how that can be, like, a small step to take, but it's just really powerful and encouraging for a friend group. And I think that applies not just among friends but in a team or other grouping in the workplace.

+ +

STEPHANIE: That's so fun. How are you celebrating these small wins, like, over text? Is that the main way you're communicating something good that happened?

+ +

JOËL: It depends on the friend group. I think, like, different friend groups will have, like, a different kind of cadence for the kind of things they do. And do they all hang out together? Do they have a group text, things like that?

+ +

One of the friend groups I'm a part of, we meet weekly to go climbing at a rock-climbing gym, so that's kind of our hang-out. And [inaudible 01:34], we're there to do stuff at the gym, but it's also a social thing. And it's an opportunity to be like, "Oh, you know, did that thing workout, you know, at work?" "You know, good for you," Or "Did you get this project accepted?" And yeah, when small wins come up, it's a great time to celebrate.

+ +

STEPHANIE: That's awesome. I think having regular time that you see people and being able to ask them about something that they had mentioned previously is so special and really important to me, like, in bonding and building the relationship.

+ +

I also love the idea of celebrating milestones. So, this is, I guess, more of a bigger win, but milestones that aren't traditionally celebrated. You know, so, yeah, we'll have, like, a party when someone graduates or someone gets married. But I also have really enjoyed celebrating when someone gets a promotion at work. And, you know, maybe that's not, like, a once-in-a-lifetime thing, but it's still so worthy of going out for dinner or buying them a drink.

+ +

I also will maybe, like, send my friends a little treat if I know that they did something small but hard for them, right? And sometimes that's even, like, responding to a scary email that they had sitting in their inbox for a while. Yeah, I really love that idea of supporting people, even in the small things in life that they do.

+ +

JOËL: Yeah, and that's really validating, I think when you've done something hard and then a friend or a colleague reaches out to you. And it's kind of like, hey, I saw that. Good for you.

+ +

STEPHANIE: How have you been thinking about bringing this into your work life?

+ +

JOËL: I think it's about being on the lookout for things that other people do. And I think one thing I like to do is kind of publicly calling that out. It sounds like a negative thing, right? But just giving people kind of a public shout-out when they've succeeded at something. I think we're all kind of socialized not to maybe talk too much about accomplishments, especially if they feel kind of small and mundane.

+ +

Being somebody else, I think, gives you a lot more leeway to say, "Hey, no, Stephanie, I see that you did that thing. And maybe it feels kind of like, oh no, you're just doing your job, but I think that's cool. And I want to, you know, just give you a shout-out in the company Slack channel or something." It doesn't have to be something big. You know, I'm not sending champagne to your home. But having that opportunity to just kind of celebrate something small and say, "Wait a minute, let's pause and acknowledge that you just did something cool."

+ +

STEPHANIE: Yeah, I was thinking about how that's kind of, like, amplifying the win a little bit. I've definitely done this before, too, when I see someone share a win of theirs, maybe in a smaller Slack channel or kind of a personal level, or even just to me individually. And I really want other people to know that that happened to you and that they, you know, did an awesome job. And so, I have enjoyed, you know, sharing them more publicly on their behalf if they are comfortable with it.

+ +

JOËL: And I'll say on the other end of that, I think it feels really good to be acknowledged by someone else that you've done something that they recognize. It's fun to share a win with other people because you're excited, but it's doubly fun when somebody else shares it for you.

+ +

STEPHANIE: I agree. I think one thing that you, Joël, do really well, actually, is sharing your own personal wins in a very casual way. That's something I've always admired about you is how you recognize the small wins for yourself.

+ +

JOËL: It's taken me, I think, a long time to get to that and find a way where, you know, you are sharing things that are fun for other people to see, things that might be inspiring, things that are kind of cool, and that are not just kind of, like, self-aggrandizing, like, bragging about stuff. It can be a fine line to walk. And, to a certain extent, you're a little bit marketing yourself. But yeah, I think I've kind of hit that right balance.

+ +

STEPHANIE: Yeah, I think the thing that makes it work is that there's usually, like, a challenge or something that maybe you, like, went through a journey or overcame a little bit. And I think that's what is the inspiring part that makes me feel like, oh, okay, so, like, this is a realistic thing that, you know, Joël went through and, you know, he struggled with it maybe. But then, like, ultimately, you know, had some insights or came out the other side with some learnings. And I like that it's real, right? It's not just, "Hey, like, I did this, like, cool thing." It's like, "I went on this journey." And I find that really motivating when I am in that kind of situation next time.

+ +

JOËL: There's a power to stories, right? And I think especially when you can make something relatable to other people. So, it's not just like, "Hey, I did a cool thing," which, you know, is also fun. But being able to say, "Hey, I messed up," or "I, you know, had this challenging problem dropped in my lap, and here's the journey I went on to resolve it. Hopefully, it acts a little bit as like a here's a template you could follow if you're ever in that situation." But maybe also a little bit of, like, inspiration for others as well, just being like, hey, Joël, messes up sometimes.

+ +

So, Stephanie, what is new in your world?

+ +

STEPHANIE: Speaking of small wins, I have finally perfected our at-home pizza situation for making pizza at home, which I have been struggling with for so long. Because I always was excited by the idea of making pizza and, you know, sometimes we would make our own dough. And sometimes, we would buy store-bought dough, but it never ended up being as crispy and cooked well-done the way that I want it to.

+ +

It was always, like, a little bit mushy on the inside. The dough wasn't totally baked. And I would inevitably be disappointed when I had been, you know, building that excitement for pizza. And the other week, I found a new recipe to try, and I think it will be my new go-to recipe for making pizza at home.

+ +

JOËL: I don't know if I'm allowed to ask this on air, but what's the secret?

+ +

STEPHANIE: The secret? Well, okay, the first secret and/or learning that I've gathered is to not put as much sauce, cheese, and toppings as you think you want to because that's definitely what contributes to the under-doneness of the dough. But I pivoted to trying a more grandma-style crust that is kind of more like focaccia; really, you know, it involves a lot of olive oil. And you're cooking it for a while on pretty high heat to ensure the crispness and, you know, that it's cooked through.

+ +

And, I mean, I love focaccia bread, so I don't mind it as, you know, the base of my pizza. It is a bit different from, you know, other kinds of pizzas. And if we had, like, a really, you know, fancy pizza oven to do the, like, super high heat, like, Neapolitan-style deal, I would also really enjoy that. But you know what? That's just not the reality of my home kitchen.

+ +

So, I have really been enjoying this pizza recipe by Alison Roman that I will link in the show notes. But yeah, it has really changed my at-home pizza game. And I hopefully won't have any of my, you know, soggy dough bottom problems anymore.

+ +

JOËL: So, you mentioned just kind of offhand, like, oh yeah, you know, the crust is just kind of, like, how you make focaccia. It sounds like you've made focaccia yourself before.

+ +

STEPHANIE: I have made focaccia at home, and so I think applying it to Pizza was a real, like, light bulb moment for me. But, you know, it's not, like, totally effortless. But I think it's a lot more forgiving than other types of bread and, therefore, other types of pizza crust.

+ +

And the one really enjoyable thing about making focaccia is there's a step where you use your fingers, and you're kind of holding your hands like you're playing a piano. And you, like, press into the dough after it has risen a little bit to create dimples and, you know, lets the oil kind of seep into the little holes. And it's very satisfying. It's a very good feeling.

+ +

JOËL: The kind of the tactile aspect of it?

+ +

STEPHANIE: Yeah, exactly. It's very fun. [chuckles] So, yeah, it's just an added bonus to my pizza adventures.

+ +

JOËL: A win on top of a win. We'll take it.

+ +

So, there's some news in the Ruby community this week because RubyConf has just opened their CFP, their call for proposals. And so, they're asking for people to submit their ideas for conference talks, and if you're lucky, you get picked to speak at the conference.

+ +

And, Stephanie, I know that over the course of a year, you have a document where you collect conference talk ideas so that you have ideas to work on when the CFP comes around. Are you looking at any of them to potentially submit to RubyConf this year?

+ +

STEPHANIE: Joël, I have to be honest with you; so far, I only have one idea on that list. [laughs] But that is one that I suppose could eventually become a conference talk proposal.

+ +

So, when I heard the news, I definitely went down the rabbit hole of revisiting that idea and kind of starting to think about if it's something I wanted to pursue. I think the answer is yes. I definitely got a big push of motivation when I was like, oh, it's open. Like, now I can just get started if I want to. And then I was like, well, it's open for a month, so I could also just sit on it a little longer, you know, put it aside and revisit it when I have a little more time.

+ +

But yeah, I was pretty excited because I think it gave me the motivation I needed to really think a little more deeply about this idea that I have. Otherwise, I think it would have continued to sit half-baked in my document for a long time.

+ +

JOËL: And just for all of our listeners, the CFP just opened on July 12th, and it closes on August 20th. So, if you are listening and it's before August 20th, you still have a shot to submit your idea to be a speaker.

+ +

STEPHANIE: Something that I've talked about with my other friends who enjoy speaking at conferences is how they come up with proposals, and I found that we all have different approaches. And I am really interested in digging into this further with you.

+ +

But I realized that, for me, I really struggle with just, like, throwing out ideas and submitting them before I feel really confident that it's something that I have interesting things to say really, or, like, kind of adding a new perspective, or maybe approaching a topic that hasn't been approached before. I feel sometimes a bit hindered by my process, where I need to feel really confident before submitting something.

+ +

Because a friend of mine she was telling me that her approach is to submit CFP for topic ideas that she wants to explore further. So, maybe it is something that she doesn't know a lot about yet, and she's using this process to learn more and dive deeper, and that, you know, gives her a reason to do that, whereas that seems really scary to me.

+ +

JOËL: That's really interesting because it sounds like kind of an underlying motivation for your friend for submitting these talks is curiosity, exploration. And thinking back to myself, I think I usually submit ideas that have me excited or passionate, so that's kind of my underlying motivation for a talk. What would you say is maybe your underlying motivation when you're pitching an idea?

+ +

STEPHANIE: Yeah, I think, for me, it is impact and, like, having an impact, especially for something that I've struggled with and wanting to share my experience and, hopefully, sharing something where other people can relate to.

+ +

It's funny you mentioned that your motivators are, you know, excitement and passion. Because another person that I kind of had this conversation with mentioned that she writes talks based on experiences that have been very aggravating [chuckles] and painful for her. So, that ends up being, you know, a big motivator because she's so frustrated. [laughs] And, you know, wants to share this journey that she went on from a point of, I guess, maybe similar to me, like, making it easier for someone else who might find themselves struggling with the same problem.

+ +

JOËL: I kind of like the idea of taking that to an extreme, and you're, like, rage submitting.

+ +

STEPHANIE: Yeah, I feel like there would just be an infinite number [laughs] of topics that you could come up with in that case.

+ +

JOËL: Like, I'm so angry at this bug. It cost me a week of my life. And now, it is going to get the spotlight on it at RubyConf. And I get to share that moment with everyone, express a lot of emotions, and, hopefully, save everyone else from having to do the same thing I did.

+ +

STEPHANIE: Yeah. Or this terrible bug cost me a week of my life, and now you all get to hear about it. [laughter] Let me tell you --

+ +

JOËL: Yes.

+ +

STEPHANIE: Exactly all the problems that I had to deal with.

+ +

JOËL: And, honestly, as a narrative, it kind of works, right? There are different types of talks. Sometimes you go to a talk because you really want to learn a deep topic. Sometimes I just want to go and listen to, like, a good horror story. If someone's a good storyteller, like, yes, there are lessons I can take away from it, and I can be like, okay, this is what I can do. And I heard Stephanie talk about this bug, and so I'm going to use inspiration from that the next time I hit a bug.

+ +

But sometimes it's also just good to, like, go there and sit and be, like, yes, I've been there. Yeah, kind of following along with the story and, you know, kind of the ups and downs because it is so relatable.

+ +

STEPHANIE: Yeah. And I like that you mentioned that there are different types of talks that leave the audience, you know, with different things. Because I know some people who have been interested in speaking in the past maybe feel a bit hesitant to because they don't think they have something to say, or, like, they don't have something to share that other people might find interesting.

+ +

And to that, I really believe that everyone has something that they are knowledgeable about and something that they can bring to others that is valuable. Even if it's not for every single person at the conference if you give a talk that is meaningful to a handful of people, right? Especially because, you know, there's people of all different kinds of levels at these conferences. Those are really important too. In fact, I think it can be even more powerful because they are targeting a specific audience.

+ +

JOËL: And I think you've hit on a key point, that is, it's great when you're building the talk, but even when you're pitching the idea is, who is this talk for? Who is the audience for this talk? And if the audience is whoever shows up at the conference center, maybe you need to workshop a little bit more.

+ +

STEPHANIE: Yeah, because one thing can't really be for everyone.

+ +

JOËL: Right. You're kind of diffusing its impact at that point. You were talking about how sometimes it's difficult to take an idea, flesh it out, and submit it until you're feeling, like, 100% confident about it. I'm curious how the transition goes from kind of the earlier phase of, like, you have a document, and I assume these are, like, bullet points with, like, one sentence, or maybe even just title idea. How does it go from bullet point to multiple paragraphs that might be submittable?

+ +

STEPHANIE: Yeah, that's a good question. I think it starts as a bullet point because maybe I notice something that caused me pain or caused a teammate pain, and maybe we had, like, kind of an interesting discussion about it. And, yeah, I write it down as something to explore further as, like, is this an idea that can be a little broader in scope, can have a few more applications beyond this particular instance that sparked it?

+ +

And so, maybe from there, I will think about, like, okay, like, the pain point that I jotted down was coupling and tests, right? And let me go, you know, jog through my memory of other times where I kind of felt a similar thing or was doing some code review and also noted a similar problem.

+ +

And I think if I am able to find enough, like, supporting examples that might go along with this, for me, it's really a feeling. [laughs] Then I'll try to extract that a little further and come up with a theme, right? A theme that's a little more encompassing because what I hope to do is to be able to come up with some kind of takeaway that can be a strong thesis for a conference proposal.

+ +

JOËL: And that's kind of how conference proposals work, right? There's a few different sections you have to fill out. But the really important one is the abstract, which is usually just a few sentences. It's character limited. And that's what is got to sell your talk both to the committee, but then also, that's what's going to be publicly viewable. And so, that's what's going to get people excited to show up at your conference room.

+ +

So, my kind of secret trick for writing a proposal is to do the abstract last. Even though it's that first section on the form, I struggle to write a compelling abstract. And so, I'll go through and fill out some of the other fields that are only for the committee, and there'll be, you know, a lot of detail in there. And then, sometimes, I find that I put, like, really good compelling sentences in there, and I'll pull them out and put them in the abstract and kind of use that to start.

+ +

But those other sections, like pitch and all that I think they're a great place to start because you get to go a little bit more into detail. And you can talk about here are the themes I want to address. Here are maybe the examples I'm going to be building around. Here's the audience that I want to speak to.

+ +

STEPHANIE: Audience is interesting for me because I tend to write the kind of talks that I wish I had watched earlier or, like, what really speaks to me. In fact, one of my first conference talks was literally called The Intro to Abstraction I Wish I'd Received. [laughs] So, that is a good place for me to start, is thinking about like, well, like, who was I at the time? Like, what kind of developer was I at the time that I, like, really needed this information or really wished for this information?

+ +

And similarly, I had mentioned, you know, like, maybe my ideas are coming from conversations I've had with other people. So, I'm imagining those other people, and I'm asking myself, like, who are they? Like, where are they in their development careers? And is there a specific demographic or audience persona that kind of fits them, and, you know, usually there is, right?

+ +

And what is nice is I can kind of go to them as well and be like, "Hey, like, I have this idea. Do you think this would be helpful for you? Or is this something you would be interested in watching?" And that at least helps me ground it in an audience that is real to me as opposed to kind of trying to imagine who might show up without a clear idea, like, of what they might get a takeaway or, like, be wanting in a conference talk.

+ +

JOËL: Would it be fair to say that when you're coming up with an idea for a presentation, the audience you have in mind is you or maybe a particular version of you, so you two years ago or you five years ago?

+ +

STEPHANIE: Yeah, I think that's a really compelling way for me to write these because, you know, I almost think it kind of goes back to the idea that everyone has something to say, right? It's like I have something to say to me, my past self. And I believe that other people, you know, are in that position as well. And so, that's been my approach.

+ +

But I'm curious about yours because I think the types of talks that you write are maybe less about, like, what you wished you had learned earlier and more for a different kind of audience.

+ +

JOËL: Yeah, I think they are...I start with a topic that I'm excited about. And then, sometimes, I have to find what element of it that I want to pull out because it can be kind of a whole kind of cloud of themes, and I have to pick one to commit to. Depending on the one I commit to and the approach I want to take, it will define the audience that...or vice versa. I can say, okay, this is specifically for this audience, and that will show how I want to approach it.

+ +

So, for example, I gave a talk at RailsConf this past spring on the math every programmer needs, talking a little bit about discrete math and how it's applicable in day-to-day programming. And I think I very quickly came to the realization that I wanted this talk to be for people who had never done a formal, like, discrete math class, likely people who don't have a traditional, like, CS background.

+ +

And so, once I knew this is the audience I'm speaking to, that really shaped how I pitched the talk, what elements I want to bring in, what examples I'm using, what do I want to emphasize during this talk. Finding that audience really helped that proposal come together. Even though I knew...before I found the audience, I knew I wanted to talk about discrete math and how cool and relevant it was to day-to-day programming. But that's not enough. I needed to really fit it to an audience.

+ +

STEPHANIE: Yeah, I have two thoughts about this. One was that when you were writing the proposal for this talk, I remember you had shared a bunch of your different ideas about the topic to your co-workers. And it was almost kind of, like, a buffet of topics. And you were asking for feedback about, like, hey, like, what is interesting to you? Like, what would be, like, helpful for you to know? And I think that ended up really helping you focus on, like, what your audience would want.

+ +

But I'm curious, do you recall, like, how you decided that you wanted to target people who didn't have that traditional CS background? Like, why was that important to you?

+ +

JOËL: I think I'm generally most excited about taking some, like, larger technical insights and bringing them to people who maybe have some of the intuition but don't always know why the things they do work the way they do and kind of bridging a little bit of that, like, practical, theoretical gap. That's the space that I'm probably most excited about when it comes to sharing and teaching, helping people go from things that are really practical and then just throwing just enough theory at them. But keeping it really grounded so that they can kind of hit the next level of where they want to be. Because that's an area that I think I thrive in, an area that gets me most excited to share about.

+ +

And so, I think, naturally, I'm kind of moving in that direction. But also, like you said, it's talking to other people and seeing, like, what are the elements that are interesting to you? And then, like, once you start seeing some of these, it's like, okay, well, what is exciting in talking about Boolean algebra? Do I want to go really deep on some of the theory? Do I want to say, you know, if someone has a vague notion of this because they've been writing code for several years but don't know the theoreticals behind it? That interaction, I think, was more compelling to me.

+ +

STEPHANIE: Got it. It's almost like knowledge sharing at just this really high level, or, like, at a really large scale. I like that a lot.

+ +

JOËL: So, you highlighted something interesting, and that is that writing a proposal doesn't have to be a solo activity, and getting feedback on ideas can totally transform your proposal. Do you find that you reach out to a lot of people to get feedback on your proposals? And what does that look like in practice?

+ +

STEPHANIE: Oh yeah, I definitely need someone to rubber-duck an idea for me. [laughs]

+ +

JOËL: So, even at the idea stage. So, you've got that topic sentence or whatever, and then you say, "Someone, can you sit down with me, and we'll just talk through places this might go?"

+ +

STEPHANIE: Yeah. I have found that really helpful for me. Otherwise, I think I get a little too precious about it, right? If I've just been working on it by myself. And then it feels really scary to submit it and be like, okay, I don't know if this is any good. It might get rejected.

+ +

But the first time that I did a conference talk, WNB.rb, the women and non-binary Ruby group I'm in, they had organized a CFP working group channel. And so, there were, you know, a handful of people, some of them writing conference talks for the first time, some of them having done it before, just getting together and holding each other accountable, and checking in and asking for feedback.

+ +

And, yeah, I think finding other people who either have done it before. I've also, you know, reached out to people whose conference talks I loved and felt really inspired by. And if they were available, like, kind of asking them how to get started.

+ +

But also, like, peer support as well, other people doing it for the first time can be really important in just making it feel a little more manageable, a little less lonely. I think there are, like, more people out there who are interested in dipping their toe in conference speaking than one might think because it can definitely feel very overwhelming. But with a support group, I think it makes it a lot easier.

+ +

JOËL: So, you've gotten feedback. You've gotten support. You've put this idea together. You're feeling pretty confident. You hit that submit button. And now you can't take it back. [laughs] How does that feel at that point?

+ +

STEPHANIE: Terrifying. [laughter] Like, for me, I have to exercise it from my mind and not think about it, not dwell on it at all. And like, ideally, you know, when I hear back, I will have forgotten all about it so that, you know, I didn't spend the whole month or however many weeks, like, ruminating about whether or not it was accepted.

+ +

Yeah, I really struggle with that part, I think, because I, yeah, have a hard time with rejection, you know, I'm just going to say it. [laughs] And, you know, it's hard for me not to take it personally. But I think that's actually one area that I want to get better at is to feel a little less, like, personally attached. And I think working with others helps me with that because it's not just something I've, you know, like, squirreled away and feel very attached to.

+ +

Working with others and then, like, hopefully, coming up with other ideas along the way, right? Within conversations that we have that might spark ideas for the future. So, knowing that if this one doesn't end up being submitted, there's always next time. There's always another conference season. And also, you know, celebrating others when their conference talks do get accepted that is also really buoying because it helps me direct that energy into wanting to celebrate my friends and inspiring me for next time.

+ +

Joël, I know you oftentimes submit more than one proposal, and I'm wondering if that helps with those feelings of being too attached to a topic idea or, you know, worrying about whether they will be accepted.

+ +

JOËL: I think it definitely helps with the attachment thing that I've not kind of put all of my work and all of my...like, pinned all of my hopes on one topic idea. Sometimes it can hurt, you know, if you've got, like, you know, two or three and, like, you just get multiple rejection notices in a day. That kind of sucks sometimes. But I think, in some ways, yes, it does help with that feeling of rejection because you've not tied yourself emotionally so much to a single idea that has to, like, succeed or fail.

+ +

STEPHANIE: Do you then submit those ideas to other conferences?

+ +

JOËL: The ones that get rejected? Yes. I've definitely resubmitted ideas. In fact, I plan to resubmit a rejection to RubyConf this year, so we'll see how that goes. Actually, now that I think of it, that could be a really fun opening line for a talk. Like, let's say it gets accepted. And, like, you know, you're on the stage, and you open it, and you're just like, "This talk got rejected." That'd be a fun intro.

+ +

STEPHANIE: Yeah, it would be. I think, oftentimes, you know, it's not always even about the idea itself, right? It's just about maybe the theme of the conference that year, and what they were looking for, and the direction they wanted to go. And there are other conferences or other another year, right? Where maybe there isn't another talk that touches on the same, like, area. And that will be the opportunity that it is a fit for the conference.

+ +

JOËL: Yeah, definitely. It is a little bit haphazard to get in. And just because your talk gets rejected does not mean it's a bad idea. It just means that it wasn't the best fit for that conference at that time.

+ +

STEPHANIE: I actually want to plug a website, speakerline.io, where people can post all of their, you know, proposals that they've submitted, whether they were accepted or rejected. And I found that resource really helpful in, you know, just knowing that, like, very good ideas get rejected sometimes, and that's okay. As well as, you know, kind of trying to get a sense of, you know, for the ones that were accepted, okay, like, what about these proposals really stood out or, like, really shine? And how might I get some inspiration from that to incorporate next time around?

+ +

JOËL: So, you've submitted a proposal. Terrifying. You're trying to not think about it for a couple of weeks, assuming you're submitting ahead a couple of weeks, I don't know. Are you a last-minute kind of submitter?

+ +

STEPHANIE: I'm a probably two or three days before the deadline kind of submitter.

+ +

JOËL: So, you've submitted the talk two or three days to the deadline. I guess, like, a couple of weeks after that to get review. And then, you get that notification that says, you know, you've got a response on your talk from the committee. Are you the kind of person that, like, drops everything and immediately looks at it? Do you kind of, like, wait for, like, maybe a moment where you're, like, more in a good zone emotionally before you open that email to find out if you're accepted or rejected? What's your strategy?

+ +

STEPHANIE: Oh God, I don't think I have the willpower to wait until I'm, you know, in an emotionally good state. I will just click on that thing. And yeah, I think, I mean, having been on the receiving end of accepting those rejections and once waitlisted, [laughs] which was a real doozy because it's like, great, like, now I have to write a talk. But, like, I don't know if it will actually be given or not.

+ +

I think this is also where the support group really shines as well because maybe some of my other friends are also sharing the results and making it okay, like, sharing a rejection, right? And I think it's nice to just have, like, an outlet for that, whatever the outcome is, and not having to just, like, sit alone in either the sadness or the happiness, right? Like, we're talking about celebrating small wins. Like, it really is even more special when someone else can validate your success.

+ +

JOËL: Have you ever had to navigate kind of, like, slight feelings of jealousy where it's, like, another friend gets in? Or maybe somebody else gets in with, like, your topic, and their talk got picked instead of yours?

+ +

STEPHANIE: Yeah, for sure. I think it's totally natural and human. I think one nice thing, though, is that there are so many conferences all of the time. You know, this is not a once-in-a-lifetime situation, right? And maybe the next conference, you know, the people who submit will be different, the people who review will be different. And you've kind of already done the hard part of writing the thing.

+ +

I actually was just thinking about a few of my friends are writers, and the submission process for them, you know, of spinning a book proposal or short stories for, like, a magazine or something like that, it's, like, fraught with rejections. And they've really built that muscle of acceptance and, like, knowing that it's not a reflection of their value, and building the resilience to keep trying.

+ +

And so, yeah, I think definitely going through that process has helped me feel a little bit more comfortable with that, not completely, but I guess it's like exposure therapy, [laughs], isn't it?

+ +

JOËL: I think that the not helpful answer here is that it gets better when you've given more talks. When you're trying to break in and give your first talk, right? It is such a big deal. And, you know, the high of getting accepted is just, you know, mountain top. But the feelings of rejection are also similarly intense. As opposed to when you've done a few, then it's like, you know what? Win some, lose some. And it's much easier to move on.

+ +

STEPHANIE: I think another suggestion that I might have would be to maybe start smaller, right? Even giving a talk at work for your co-workers, or even the next step is giving a talk at your local meetup or then a small regional conference. There are so many in-between steps, I think, that exist that bestow the benefits of giving a conference talk, and meeting new people, and feeling good about the impact you're having beyond some of the bigger, more traditional conferences.

+ +

So, if that does seem really scary or, you know, maybe you've given it a shot and feel a little bit demoralized from trying again, there is a group out there who will benefit and be interested in hearing what you have to say.

+ +

JOËL: That's a really important reminder because just because a conference rejected your talk doesn't mean that it's a bad idea. And yes, you can shop it around and bring it to other conferences, but maybe think about other venues for the idea. You've already done the hard work of crafting a pitch, so maybe turn it into a blog post and share it that way.

+ +

Maybe turn it into a pitch to be a guest on a podcast that you enjoy. Podcasts that do weekly guests are constantly looking for interesting people to talk to. And you've kind of, like, done all the work for them, where you can say, "Hey, here's the thing I'm an expert on. Ask me questions about this." And most places will gladly bring you on.

+ +

STEPHANIE: Yeah, I like to think of conference talks as really, like, a supplement of what you're learning and investing in in your career, right? You know, it is nice to be able to share all of those things in a perfectly wrapped package. But also, there are so many different ways for that to manifest. And there are people who know that speaking is not for them and really focus on writing, and that's, like, their avenue. But yeah, it's not...I don't think it's, like, a pinnacle of, like, something you have to do in your career at all. It's just something that can be fun.

+ +

JOËL: Yeah, and sharing takes many different forms. It can be a talk in a conference room, but it can just as easily turn into maybe some kind of video, some kind of written work. Like I said, it could be an interview on a podcast. There are so many different ways that you can share your ideas. And just because it didn't fit in one place, now that you've done the work to kind of polish that gem a little bit, oftentimes, it's very little additional work to just convert it to a different form.

+ +

STEPHANIE: Yeah, I like what you just said about polishing a gem. Really, I think the value for me is having a channel to funnel and reflect on my experiences, and, you know, conference talks happen to be, like, one form of that for me. But I hate to say it's about the journey, not the destination, but sometimes it is. And, yeah, I think everyone kind of has to, like, figure that out for themselves.

+ +

JOËL: That being said, sometimes the destination is pretty exciting. And when you open that email that says, "Congratulations, your talk has been accepted," wow, what a rush.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Joël recently had a fascinating conversation with some friends about the power of celebrating and highlighting small wins in their lives. He talks about bringing this into his work life. May Stephanie interest you in a secret she learned regarding homemade pizza?

+ +

RubyConf is coming! Who's submitting talks?! It's hekkin scary. Don't fret! Joël and Stephannie are here to help. Today, they discussed submitting a conference talk proposal from start to finish.

+ +
+ + + +

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've come 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: I've been having a really interesting conversation with some of my friends recently about the power of celebrating and highlighting small wins in our lives, both in, like, kind of sharing it with each other, like, you know, if something small happens, it's good for me to share it with my friends. But also, where it becomes really cool is where the friend group kind of gets together and celebrates that small win for one person, and how that can be, like, a small step to take, but it's just really powerful and encouraging for a friend group. And I think that applies not just among friends but in a team or other grouping in the workplace.

+ +

STEPHANIE: That's so fun. How are you celebrating these small wins, like, over text? Is that the main way you're communicating something good that happened?

+ +

JOËL: It depends on the friend group. I think, like, different friend groups will have, like, a different kind of cadence for the kind of things they do. And do they all hang out together? Do they have a group text, things like that?

+ +

One of the friend groups I'm a part of, we meet weekly to go climbing at a rock-climbing gym, so that's kind of our hang-out. And [inaudible 01:34], we're there to do stuff at the gym, but it's also a social thing. And it's an opportunity to be like, "Oh, you know, did that thing workout, you know, at work?" "You know, good for you," Or "Did you get this project accepted?" And yeah, when small wins come up, it's a great time to celebrate.

+ +

STEPHANIE: That's awesome. I think having regular time that you see people and being able to ask them about something that they had mentioned previously is so special and really important to me, like, in bonding and building the relationship.

+ +

I also love the idea of celebrating milestones. So, this is, I guess, more of a bigger win, but milestones that aren't traditionally celebrated. You know, so, yeah, we'll have, like, a party when someone graduates or someone gets married. But I also have really enjoyed celebrating when someone gets a promotion at work. And, you know, maybe that's not, like, a once-in-a-lifetime thing, but it's still so worthy of going out for dinner or buying them a drink.

+ +

I also will maybe, like, send my friends a little treat if I know that they did something small but hard for them, right? And sometimes that's even, like, responding to a scary email that they had sitting in their inbox for a while. Yeah, I really love that idea of supporting people, even in the small things in life that they do.

+ +

JOËL: Yeah, and that's really validating, I think when you've done something hard and then a friend or a colleague reaches out to you. And it's kind of like, hey, I saw that. Good for you.

+ +

STEPHANIE: How have you been thinking about bringing this into your work life?

+ +

JOËL: I think it's about being on the lookout for things that other people do. And I think one thing I like to do is kind of publicly calling that out. It sounds like a negative thing, right? But just giving people kind of a public shout-out when they've succeeded at something. I think we're all kind of socialized not to maybe talk too much about accomplishments, especially if they feel kind of small and mundane.

+ +

Being somebody else, I think, gives you a lot more leeway to say, "Hey, no, Stephanie, I see that you did that thing. And maybe it feels kind of like, oh no, you're just doing your job, but I think that's cool. And I want to, you know, just give you a shout-out in the company Slack channel or something." It doesn't have to be something big. You know, I'm not sending champagne to your home. But having that opportunity to just kind of celebrate something small and say, "Wait a minute, let's pause and acknowledge that you just did something cool."

+ +

STEPHANIE: Yeah, I was thinking about how that's kind of, like, amplifying the win a little bit. I've definitely done this before, too, when I see someone share a win of theirs, maybe in a smaller Slack channel or kind of a personal level, or even just to me individually. And I really want other people to know that that happened to you and that they, you know, did an awesome job. And so, I have enjoyed, you know, sharing them more publicly on their behalf if they are comfortable with it.

+ +

JOËL: And I'll say on the other end of that, I think it feels really good to be acknowledged by someone else that you've done something that they recognize. It's fun to share a win with other people because you're excited, but it's doubly fun when somebody else shares it for you.

+ +

STEPHANIE: I agree. I think one thing that you, Joël, do really well, actually, is sharing your own personal wins in a very casual way. That's something I've always admired about you is how you recognize the small wins for yourself.

+ +

JOËL: It's taken me, I think, a long time to get to that and find a way where, you know, you are sharing things that are fun for other people to see, things that might be inspiring, things that are kind of cool, and that are not just kind of, like, self-aggrandizing, like, bragging about stuff. It can be a fine line to walk. And, to a certain extent, you're a little bit marketing yourself. But yeah, I think I've kind of hit that right balance.

+ +

STEPHANIE: Yeah, I think the thing that makes it work is that there's usually, like, a challenge or something that maybe you, like, went through a journey or overcame a little bit. And I think that's what is the inspiring part that makes me feel like, oh, okay, so, like, this is a realistic thing that, you know, Joël went through and, you know, he struggled with it maybe. But then, like, ultimately, you know, had some insights or came out the other side with some learnings. And I like that it's real, right? It's not just, "Hey, like, I did this, like, cool thing." It's like, "I went on this journey." And I find that really motivating when I am in that kind of situation next time.

+ +

JOËL: There's a power to stories, right? And I think especially when you can make something relatable to other people. So, it's not just like, "Hey, I did a cool thing," which, you know, is also fun. But being able to say, "Hey, I messed up," or "I, you know, had this challenging problem dropped in my lap, and here's the journey I went on to resolve it. Hopefully, it acts a little bit as like a here's a template you could follow if you're ever in that situation." But maybe also a little bit of, like, inspiration for others as well, just being like, hey, Joël, messes up sometimes.

+ +

So, Stephanie, what is new in your world?

+ +

STEPHANIE: Speaking of small wins, I have finally perfected our at-home pizza situation for making pizza at home, which I have been struggling with for so long. Because I always was excited by the idea of making pizza and, you know, sometimes we would make our own dough. And sometimes, we would buy store-bought dough, but it never ended up being as crispy and cooked well-done the way that I want it to.

+ +

It was always, like, a little bit mushy on the inside. The dough wasn't totally baked. And I would inevitably be disappointed when I had been, you know, building that excitement for pizza. And the other week, I found a new recipe to try, and I think it will be my new go-to recipe for making pizza at home.

+ +

JOËL: I don't know if I'm allowed to ask this on air, but what's the secret?

+ +

STEPHANIE: The secret? Well, okay, the first secret and/or learning that I've gathered is to not put as much sauce, cheese, and toppings as you think you want to because that's definitely what contributes to the under-doneness of the dough. But I pivoted to trying a more grandma-style crust that is kind of more like focaccia; really, you know, it involves a lot of olive oil. And you're cooking it for a while on pretty high heat to ensure the crispness and, you know, that it's cooked through.

+ +

And, I mean, I love focaccia bread, so I don't mind it as, you know, the base of my pizza. It is a bit different from, you know, other kinds of pizzas. And if we had, like, a really, you know, fancy pizza oven to do the, like, super high heat, like, Neapolitan-style deal, I would also really enjoy that. But you know what? That's just not the reality of my home kitchen.

+ +

So, I have really been enjoying this pizza recipe by Alison Roman that I will link in the show notes. But yeah, it has really changed my at-home pizza game. And I hopefully won't have any of my, you know, soggy dough bottom problems anymore.

+ +

JOËL: So, you mentioned just kind of offhand, like, oh yeah, you know, the crust is just kind of, like, how you make focaccia. It sounds like you've made focaccia yourself before.

+ +

STEPHANIE: I have made focaccia at home, and so I think applying it to Pizza was a real, like, light bulb moment for me. But, you know, it's not, like, totally effortless. But I think it's a lot more forgiving than other types of bread and, therefore, other types of pizza crust.

+ +

And the one really enjoyable thing about making focaccia is there's a step where you use your fingers, and you're kind of holding your hands like you're playing a piano. And you, like, press into the dough after it has risen a little bit to create dimples and, you know, lets the oil kind of seep into the little holes. And it's very satisfying. It's a very good feeling.

+ +

JOËL: The kind of the tactile aspect of it?

+ +

STEPHANIE: Yeah, exactly. It's very fun. [chuckles] So, yeah, it's just an added bonus to my pizza adventures.

+ +

JOËL: A win on top of a win. We'll take it.

+ +

So, there's some news in the Ruby community this week because RubyConf has just opened their CFP, their call for proposals. And so, they're asking for people to submit their ideas for conference talks, and if you're lucky, you get picked to speak at the conference.

+ +

And, Stephanie, I know that over the course of a year, you have a document where you collect conference talk ideas so that you have ideas to work on when the CFP comes around. Are you looking at any of them to potentially submit to RubyConf this year?

+ +

STEPHANIE: Joël, I have to be honest with you; so far, I only have one idea on that list. [laughs] But that is one that I suppose could eventually become a conference talk proposal.

+ +

So, when I heard the news, I definitely went down the rabbit hole of revisiting that idea and kind of starting to think about if it's something I wanted to pursue. I think the answer is yes. I definitely got a big push of motivation when I was like, oh, it's open. Like, now I can just get started if I want to. And then I was like, well, it's open for a month, so I could also just sit on it a little longer, you know, put it aside and revisit it when I have a little more time.

+ +

But yeah, I was pretty excited because I think it gave me the motivation I needed to really think a little more deeply about this idea that I have. Otherwise, I think it would have continued to sit half-baked in my document for a long time.

+ +

JOËL: And just for all of our listeners, the CFP just opened on July 12th, and it closes on August 20th. So, if you are listening and it's before August 20th, you still have a shot to submit your idea to be a speaker.

+ +

STEPHANIE: Something that I've talked about with my other friends who enjoy speaking at conferences is how they come up with proposals, and I found that we all have different approaches. And I am really interested in digging into this further with you.

+ +

But I realized that, for me, I really struggle with just, like, throwing out ideas and submitting them before I feel really confident that it's something that I have interesting things to say really, or, like, kind of adding a new perspective, or maybe approaching a topic that hasn't been approached before. I feel sometimes a bit hindered by my process, where I need to feel really confident before submitting something.

+ +

Because a friend of mine she was telling me that her approach is to submit CFP for topic ideas that she wants to explore further. So, maybe it is something that she doesn't know a lot about yet, and she's using this process to learn more and dive deeper, and that, you know, gives her a reason to do that, whereas that seems really scary to me.

+ +

JOËL: That's really interesting because it sounds like kind of an underlying motivation for your friend for submitting these talks is curiosity, exploration. And thinking back to myself, I think I usually submit ideas that have me excited or passionate, so that's kind of my underlying motivation for a talk. What would you say is maybe your underlying motivation when you're pitching an idea?

+ +

STEPHANIE: Yeah, I think, for me, it is impact and, like, having an impact, especially for something that I've struggled with and wanting to share my experience and, hopefully, sharing something where other people can relate to.

+ +

It's funny you mentioned that your motivators are, you know, excitement and passion. Because another person that I kind of had this conversation with mentioned that she writes talks based on experiences that have been very aggravating [chuckles] and painful for her. So, that ends up being, you know, a big motivator because she's so frustrated. [laughs] And, you know, wants to share this journey that she went on from a point of, I guess, maybe similar to me, like, making it easier for someone else who might find themselves struggling with the same problem.

+ +

JOËL: I kind of like the idea of taking that to an extreme, and you're, like, rage submitting.

+ +

STEPHANIE: Yeah, I feel like there would just be an infinite number [laughs] of topics that you could come up with in that case.

+ +

JOËL: Like, I'm so angry at this bug. It cost me a week of my life. And now, it is going to get the spotlight on it at RubyConf. And I get to share that moment with everyone, express a lot of emotions, and, hopefully, save everyone else from having to do the same thing I did.

+ +

STEPHANIE: Yeah. Or this terrible bug cost me a week of my life, and now you all get to hear about it. [laughter] Let me tell you --

+ +

JOËL: Yes.

+ +

STEPHANIE: Exactly all the problems that I had to deal with.

+ +

JOËL: And, honestly, as a narrative, it kind of works, right? There are different types of talks. Sometimes you go to a talk because you really want to learn a deep topic. Sometimes I just want to go and listen to, like, a good horror story. If someone's a good storyteller, like, yes, there are lessons I can take away from it, and I can be like, okay, this is what I can do. And I heard Stephanie talk about this bug, and so I'm going to use inspiration from that the next time I hit a bug.

+ +

But sometimes it's also just good to, like, go there and sit and be, like, yes, I've been there. Yeah, kind of following along with the story and, you know, kind of the ups and downs because it is so relatable.

+ +

STEPHANIE: Yeah. And I like that you mentioned that there are different types of talks that leave the audience, you know, with different things. Because I know some people who have been interested in speaking in the past maybe feel a bit hesitant to because they don't think they have something to say, or, like, they don't have something to share that other people might find interesting.

+ +

And to that, I really believe that everyone has something that they are knowledgeable about and something that they can bring to others that is valuable. Even if it's not for every single person at the conference if you give a talk that is meaningful to a handful of people, right? Especially because, you know, there's people of all different kinds of levels at these conferences. Those are really important too. In fact, I think it can be even more powerful because they are targeting a specific audience.

+ +

JOËL: And I think you've hit on a key point, that is, it's great when you're building the talk, but even when you're pitching the idea is, who is this talk for? Who is the audience for this talk? And if the audience is whoever shows up at the conference center, maybe you need to workshop a little bit more.

+ +

STEPHANIE: Yeah, because one thing can't really be for everyone.

+ +

JOËL: Right. You're kind of diffusing its impact at that point. You were talking about how sometimes it's difficult to take an idea, flesh it out, and submit it until you're feeling, like, 100% confident about it. I'm curious how the transition goes from kind of the earlier phase of, like, you have a document, and I assume these are, like, bullet points with, like, one sentence, or maybe even just title idea. How does it go from bullet point to multiple paragraphs that might be submittable?

+ +

STEPHANIE: Yeah, that's a good question. I think it starts as a bullet point because maybe I notice something that caused me pain or caused a teammate pain, and maybe we had, like, kind of an interesting discussion about it. And, yeah, I write it down as something to explore further as, like, is this an idea that can be a little broader in scope, can have a few more applications beyond this particular instance that sparked it?

+ +

And so, maybe from there, I will think about, like, okay, like, the pain point that I jotted down was coupling and tests, right? And let me go, you know, jog through my memory of other times where I kind of felt a similar thing or was doing some code review and also noted a similar problem.

+ +

And I think if I am able to find enough, like, supporting examples that might go along with this, for me, it's really a feeling. [laughs] Then I'll try to extract that a little further and come up with a theme, right? A theme that's a little more encompassing because what I hope to do is to be able to come up with some kind of takeaway that can be a strong thesis for a conference proposal.

+ +

JOËL: And that's kind of how conference proposals work, right? There's a few different sections you have to fill out. But the really important one is the abstract, which is usually just a few sentences. It's character limited. And that's what is got to sell your talk both to the committee, but then also, that's what's going to be publicly viewable. And so, that's what's going to get people excited to show up at your conference room.

+ +

So, my kind of secret trick for writing a proposal is to do the abstract last. Even though it's that first section on the form, I struggle to write a compelling abstract. And so, I'll go through and fill out some of the other fields that are only for the committee, and there'll be, you know, a lot of detail in there. And then, sometimes, I find that I put, like, really good compelling sentences in there, and I'll pull them out and put them in the abstract and kind of use that to start.

+ +

But those other sections, like pitch and all that I think they're a great place to start because you get to go a little bit more into detail. And you can talk about here are the themes I want to address. Here are maybe the examples I'm going to be building around. Here's the audience that I want to speak to.

+ +

STEPHANIE: Audience is interesting for me because I tend to write the kind of talks that I wish I had watched earlier or, like, what really speaks to me. In fact, one of my first conference talks was literally called The Intro to Abstraction I Wish I'd Received. [laughs] So, that is a good place for me to start, is thinking about like, well, like, who was I at the time? Like, what kind of developer was I at the time that I, like, really needed this information or really wished for this information?

+ +

And similarly, I had mentioned, you know, like, maybe my ideas are coming from conversations I've had with other people. So, I'm imagining those other people, and I'm asking myself, like, who are they? Like, where are they in their development careers? And is there a specific demographic or audience persona that kind of fits them, and, you know, usually there is, right?

+ +

And what is nice is I can kind of go to them as well and be like, "Hey, like, I have this idea. Do you think this would be helpful for you? Or is this something you would be interested in watching?" And that at least helps me ground it in an audience that is real to me as opposed to kind of trying to imagine who might show up without a clear idea, like, of what they might get a takeaway or, like, be wanting in a conference talk.

+ +

JOËL: Would it be fair to say that when you're coming up with an idea for a presentation, the audience you have in mind is you or maybe a particular version of you, so you two years ago or you five years ago?

+ +

STEPHANIE: Yeah, I think that's a really compelling way for me to write these because, you know, I almost think it kind of goes back to the idea that everyone has something to say, right? It's like I have something to say to me, my past self. And I believe that other people, you know, are in that position as well. And so, that's been my approach.

+ +

But I'm curious about yours because I think the types of talks that you write are maybe less about, like, what you wished you had learned earlier and more for a different kind of audience.

+ +

JOËL: Yeah, I think they are...I start with a topic that I'm excited about. And then, sometimes, I have to find what element of it that I want to pull out because it can be kind of a whole kind of cloud of themes, and I have to pick one to commit to. Depending on the one I commit to and the approach I want to take, it will define the audience that...or vice versa. I can say, okay, this is specifically for this audience, and that will show how I want to approach it.

+ +

So, for example, I gave a talk at RailsConf this past spring on the math every programmer needs, talking a little bit about discrete math and how it's applicable in day-to-day programming. And I think I very quickly came to the realization that I wanted this talk to be for people who had never done a formal, like, discrete math class, likely people who don't have a traditional, like, CS background.

+ +

And so, once I knew this is the audience I'm speaking to, that really shaped how I pitched the talk, what elements I want to bring in, what examples I'm using, what do I want to emphasize during this talk. Finding that audience really helped that proposal come together. Even though I knew...before I found the audience, I knew I wanted to talk about discrete math and how cool and relevant it was to day-to-day programming. But that's not enough. I needed to really fit it to an audience.

+ +

STEPHANIE: Yeah, I have two thoughts about this. One was that when you were writing the proposal for this talk, I remember you had shared a bunch of your different ideas about the topic to your co-workers. And it was almost kind of, like, a buffet of topics. And you were asking for feedback about, like, hey, like, what is interesting to you? Like, what would be, like, helpful for you to know? And I think that ended up really helping you focus on, like, what your audience would want.

+ +

But I'm curious, do you recall, like, how you decided that you wanted to target people who didn't have that traditional CS background? Like, why was that important to you?

+ +

JOËL: I think I'm generally most excited about taking some, like, larger technical insights and bringing them to people who maybe have some of the intuition but don't always know why the things they do work the way they do and kind of bridging a little bit of that, like, practical, theoretical gap. That's the space that I'm probably most excited about when it comes to sharing and teaching, helping people go from things that are really practical and then just throwing just enough theory at them. But keeping it really grounded so that they can kind of hit the next level of where they want to be. Because that's an area that I think I thrive in, an area that gets me most excited to share about.

+ +

And so, I think, naturally, I'm kind of moving in that direction. But also, like you said, it's talking to other people and seeing, like, what are the elements that are interesting to you? And then, like, once you start seeing some of these, it's like, okay, well, what is exciting in talking about Boolean algebra? Do I want to go really deep on some of the theory? Do I want to say, you know, if someone has a vague notion of this because they've been writing code for several years but don't know the theoreticals behind it? That interaction, I think, was more compelling to me.

+ +

STEPHANIE: Got it. It's almost like knowledge sharing at just this really high level, or, like, at a really large scale. I like that a lot.

+ +

JOËL: So, you highlighted something interesting, and that is that writing a proposal doesn't have to be a solo activity, and getting feedback on ideas can totally transform your proposal. Do you find that you reach out to a lot of people to get feedback on your proposals? And what does that look like in practice?

+ +

STEPHANIE: Oh yeah, I definitely need someone to rubber-duck an idea for me. [laughs]

+ +

JOËL: So, even at the idea stage. So, you've got that topic sentence or whatever, and then you say, "Someone, can you sit down with me, and we'll just talk through places this might go?"

+ +

STEPHANIE: Yeah. I have found that really helpful for me. Otherwise, I think I get a little too precious about it, right? If I've just been working on it by myself. And then it feels really scary to submit it and be like, okay, I don't know if this is any good. It might get rejected.

+ +

But the first time that I did a conference talk, WNB.rb, the women and non-binary Ruby group I'm in, they had organized a CFP working group channel. And so, there were, you know, a handful of people, some of them writing conference talks for the first time, some of them having done it before, just getting together and holding each other accountable, and checking in and asking for feedback.

+ +

And, yeah, I think finding other people who either have done it before. I've also, you know, reached out to people whose conference talks I loved and felt really inspired by. And if they were available, like, kind of asking them how to get started.

+ +

But also, like, peer support as well, other people doing it for the first time can be really important in just making it feel a little more manageable, a little less lonely. I think there are, like, more people out there who are interested in dipping their toe in conference speaking than one might think because it can definitely feel very overwhelming. But with a support group, I think it makes it a lot easier.

+ +

JOËL: So, you've gotten feedback. You've gotten support. You've put this idea together. You're feeling pretty confident. You hit that submit button. And now you can't take it back. [laughs] How does that feel at that point?

+ +

STEPHANIE: Terrifying. [laughter] Like, for me, I have to exercise it from my mind and not think about it, not dwell on it at all. And like, ideally, you know, when I hear back, I will have forgotten all about it so that, you know, I didn't spend the whole month or however many weeks, like, ruminating about whether or not it was accepted.

+ +

Yeah, I really struggle with that part, I think, because I, yeah, have a hard time with rejection, you know, I'm just going to say it. [laughs] And, you know, it's hard for me not to take it personally. But I think that's actually one area that I want to get better at is to feel a little less, like, personally attached. And I think working with others helps me with that because it's not just something I've, you know, like, squirreled away and feel very attached to.

+ +

Working with others and then, like, hopefully, coming up with other ideas along the way, right? Within conversations that we have that might spark ideas for the future. So, knowing that if this one doesn't end up being submitted, there's always next time. There's always another conference season. And also, you know, celebrating others when their conference talks do get accepted that is also really buoying because it helps me direct that energy into wanting to celebrate my friends and inspiring me for next time.

+ +

Joël, I know you oftentimes submit more than one proposal, and I'm wondering if that helps with those feelings of being too attached to a topic idea or, you know, worrying about whether they will be accepted.

+ +

JOËL: I think it definitely helps with the attachment thing that I've not kind of put all of my work and all of my...like, pinned all of my hopes on one topic idea. Sometimes it can hurt, you know, if you've got, like, you know, two or three and, like, you just get multiple rejection notices in a day. That kind of sucks sometimes. But I think, in some ways, yes, it does help with that feeling of rejection because you've not tied yourself emotionally so much to a single idea that has to, like, succeed or fail.

+ +

STEPHANIE: Do you then submit those ideas to other conferences?

+ +

JOËL: The ones that get rejected? Yes. I've definitely resubmitted ideas. In fact, I plan to resubmit a rejection to RubyConf this year, so we'll see how that goes. Actually, now that I think of it, that could be a really fun opening line for a talk. Like, let's say it gets accepted. And, like, you know, you're on the stage, and you open it, and you're just like, "This talk got rejected." That'd be a fun intro.

+ +

STEPHANIE: Yeah, it would be. I think, oftentimes, you know, it's not always even about the idea itself, right? It's just about maybe the theme of the conference that year, and what they were looking for, and the direction they wanted to go. And there are other conferences or other another year, right? Where maybe there isn't another talk that touches on the same, like, area. And that will be the opportunity that it is a fit for the conference.

+ +

JOËL: Yeah, definitely. It is a little bit haphazard to get in. And just because your talk gets rejected does not mean it's a bad idea. It just means that it wasn't the best fit for that conference at that time.

+ +

STEPHANIE: I actually want to plug a website, speakerline.io, where people can post all of their, you know, proposals that they've submitted, whether they were accepted or rejected. And I found that resource really helpful in, you know, just knowing that, like, very good ideas get rejected sometimes, and that's okay. As well as, you know, kind of trying to get a sense of, you know, for the ones that were accepted, okay, like, what about these proposals really stood out or, like, really shine? And how might I get some inspiration from that to incorporate next time around?

+ +

JOËL: So, you've submitted a proposal. Terrifying. You're trying to not think about it for a couple of weeks, assuming you're submitting ahead a couple of weeks, I don't know. Are you a last-minute kind of submitter?

+ +

STEPHANIE: I'm a probably two or three days before the deadline kind of submitter.

+ +

JOËL: So, you've submitted the talk two or three days to the deadline. I guess, like, a couple of weeks after that to get review. And then, you get that notification that says, you know, you've got a response on your talk from the committee. Are you the kind of person that, like, drops everything and immediately looks at it? Do you kind of, like, wait for, like, maybe a moment where you're, like, more in a good zone emotionally before you open that email to find out if you're accepted or rejected? What's your strategy?

+ +

STEPHANIE: Oh God, I don't think I have the willpower to wait until I'm, you know, in an emotionally good state. I will just click on that thing. And yeah, I think, I mean, having been on the receiving end of accepting those rejections and once waitlisted, [laughs] which was a real doozy because it's like, great, like, now I have to write a talk. But, like, I don't know if it will actually be given or not.

+ +

I think this is also where the support group really shines as well because maybe some of my other friends are also sharing the results and making it okay, like, sharing a rejection, right? And I think it's nice to just have, like, an outlet for that, whatever the outcome is, and not having to just, like, sit alone in either the sadness or the happiness, right? Like, we're talking about celebrating small wins. Like, it really is even more special when someone else can validate your success.

+ +

JOËL: Have you ever had to navigate kind of, like, slight feelings of jealousy where it's, like, another friend gets in? Or maybe somebody else gets in with, like, your topic, and their talk got picked instead of yours?

+ +

STEPHANIE: Yeah, for sure. I think it's totally natural and human. I think one nice thing, though, is that there are so many conferences all of the time. You know, this is not a once-in-a-lifetime situation, right? And maybe the next conference, you know, the people who submit will be different, the people who review will be different. And you've kind of already done the hard part of writing the thing.

+ +

I actually was just thinking about a few of my friends are writers, and the submission process for them, you know, of spinning a book proposal or short stories for, like, a magazine or something like that, it's, like, fraught with rejections. And they've really built that muscle of acceptance and, like, knowing that it's not a reflection of their value, and building the resilience to keep trying.

+ +

And so, yeah, I think definitely going through that process has helped me feel a little bit more comfortable with that, not completely, but I guess it's like exposure therapy, [laughs], isn't it?

+ +

JOËL: I think that the not helpful answer here is that it gets better when you've given more talks. When you're trying to break in and give your first talk, right? It is such a big deal. And, you know, the high of getting accepted is just, you know, mountain top. But the feelings of rejection are also similarly intense. As opposed to when you've done a few, then it's like, you know what? Win some, lose some. And it's much easier to move on.

+ +

STEPHANIE: I think another suggestion that I might have would be to maybe start smaller, right? Even giving a talk at work for your co-workers, or even the next step is giving a talk at your local meetup or then a small regional conference. There are so many in-between steps, I think, that exist that bestow the benefits of giving a conference talk, and meeting new people, and feeling good about the impact you're having beyond some of the bigger, more traditional conferences.

+ +

So, if that does seem really scary or, you know, maybe you've given it a shot and feel a little bit demoralized from trying again, there is a group out there who will benefit and be interested in hearing what you have to say.

+ +

JOËL: That's a really important reminder because just because a conference rejected your talk doesn't mean that it's a bad idea. And yes, you can shop it around and bring it to other conferences, but maybe think about other venues for the idea. You've already done the hard work of crafting a pitch, so maybe turn it into a blog post and share it that way.

+ +

Maybe turn it into a pitch to be a guest on a podcast that you enjoy. Podcasts that do weekly guests are constantly looking for interesting people to talk to. And you've kind of, like, done all the work for them, where you can say, "Hey, here's the thing I'm an expert on. Ask me questions about this." And most places will gladly bring you on.

+ +

STEPHANIE: Yeah, I like to think of conference talks as really, like, a supplement of what you're learning and investing in in your career, right? You know, it is nice to be able to share all of those things in a perfectly wrapped package. But also, there are so many different ways for that to manifest. And there are people who know that speaking is not for them and really focus on writing, and that's, like, their avenue. But yeah, it's not...I don't think it's, like, a pinnacle of, like, something you have to do in your career at all. It's just something that can be fun.

+ +

JOËL: Yeah, and sharing takes many different forms. It can be a talk in a conference room, but it can just as easily turn into maybe some kind of video, some kind of written work. Like I said, it could be an interview on a podcast. There are so many different ways that you can share your ideas. And just because it didn't fit in one place, now that you've done the work to kind of polish that gem a little bit, oftentimes, it's very little additional work to just convert it to a different form.

+ +

STEPHANIE: Yeah, I like what you just said about polishing a gem. Really, I think the value for me is having a channel to funnel and reflect on my experiences, and, you know, conference talks happen to be, like, one form of that for me. But I hate to say it's about the journey, not the destination, but sometimes it is. And, yeah, I think everyone kind of has to, like, figure that out for themselves.

+ +

JOËL: That being said, sometimes the destination is pretty exciting. And when you open that email that says, "Congratulations, your talk has been accepted," wow, what a rush.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3BwvdkAs + + ]]> + + Joël Quenneville + Stephanie Minn + + + 393: Is REST the Best? APIs and Domain Modeling + https://bikeshed.thoughtbot.com/393 + a4d6bcc9-4bce-4363-ba1f-6f7c8227d277 + Tue, 18 Jul 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + It's updates on the work front today! Stephanie was tasked with removing a six-year-old feature flag from a codebase. Joël's been doing a lot of small database migrations. + +A listener question sparked today's main discussion on gerunds' interesting relationship to data modeling. + 33:49 + no + + + It's updates on the work front today! Stephanie was tasked with removing a six-year-old feature flag from a codebase. Joël's been doing a lot of small database migrations. +A listener question sparked today's main discussion on gerunds' interesting relationship to data modeling. +Episode 386: Value Objects Revisited: The Tally Edition (https://www.bikeshed.fm/386) +RailsConf 2017: In Relentless Pursuit of REST by Derek Prior (https://www.youtube.com/watch?v=HctYHe-YjnE) +REST Turns Humans Into Database Clients (https://chrislwhite.com/rest-contortion/) +Parse, don’t validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) +Wikipedia Getting to Philosophy (https://en.wikipedia.org/wiki/Wikipedia:Getting_to_Philosophy) +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, this week, I've been tasked with something that I've been finding very fun, which is removing a six-year-old feature flag from the codebase that is still very much in use in the sense that it is actually a mechanism for providing customers access to a feature that had been originally launched as a beta. And that was why the feature flag was introduced. +But in the years since, you know, the business has shifted to a model where you have to pay for those features. And some customers are still hanging on to this beta feature flag that lets them get the features for free. So one of the ways that we're trying to convert those people to be paying for the feature is to, you know, gradually remove the feature flag and maybe, you know, give them a heads up that this is happening. +I'm also getting to improve the codebase with this change as well because it has really been propagating [laughs] in there. There wasn't necessarily a single, I guess, entry point for determining whether customers should get access to this feature through the flag or not. So it ended up being repeated in a bunch of different places because the feature set has grown. And so, now we have to do this check for the flag in several places, like, different pages of the application. And it's been really interesting to see just how this kind of stuff can grow and mutate over several years. +JOËL: So, if I understand correctly, there's kind of two overlapping conditions now around this feature. So you have access to it if you've either paid for the feature or if you were a beta tester. +STEPHANIE: Yeah, exactly. And the interesting thought that I had about this was it actually sounds a lot like the strangler fig pattern, which we've talked about before, where we've now introduced the new source of data that we want to be using moving forward. But we still have this, you know, old limb or branch hanging on that hasn't quite been removed or pruned off [chuckles] yet. So that's what I'm doing now. +And it's nice in the sense that I can trust that we are already sending the correct data that we want to be consuming, and it's just the cleanup part. So, in some ways, we had been in that half-step for several years, and they're now getting to the point where we can finally remove it. +JOËL: I think in kind of true strangler fig pattern, you would probably move all of your users off of that feature flag so that the people that have it active are zero, at which point it is effectively dead code, and then you can remove it. +STEPHANIE: Yeah, that's a great point. And we had considered doing that first, but the thing that we had kind of come away with was that removing all of those customers from that feature flag would probably require a script or, you know, updating the production data. And that seemed a bit riskier actually to us because it wasn't as reversible as a code change. +JOËL: I think you bring up a really interesting point, which is that production data changes, in general, are just scarier than code changes. At least for me, it feels like it's fairly easy generally to revert a code change. Whereas if I've messed up the production database, [laughs] that's going to be unpleasant few days. +STEPHANIE: What's interesting is that this feature flag is not really supported by a nice user interface for managing it. And so, we inevitably had to do a more developer-focused solution to remove these customers from being able to access this feature. And so, the two options, you know, that we had available were to do it through data, like I mentioned, or do it through that code change. And again, I think we evaluated both options. But what's kind of nice about doing it with the code change is that when we eventually get to delete those feature flag records, it will be really nice and easy. +JOËL: That's really exciting. One thing that's different about kind of more mature projects is that we often get to do some kind of change management, unlike a greenfield app where you just get to, oh, let's introduce this new thing, cool. Oftentimes, on a more mature project, before you introduce the new thing, you have to figure out, like, what is the migration path towards that? Is that a kind of work that you enjoy? +STEPHANIE: I think this was definitely an exercise in thinking about how to break this down into steps. So, yeah, that change management process you mentioned, I, like, did find a lot of satisfaction in trying to break it up, you know, especially because I was also thinking that you know, maybe I am not able to see the complete, like, cleanup and removal, and, like, where can someone pick up after me? In some ways, I feel like I was kind of stepping into that migration, you know, six years [laughs] in the making from beta to the paid product. +But I think I will feel really satisfied if I'm able to see this thing through and get to celebrate the success of saying, hey, like, I removed...at this point, it's a few hundred lines of code. [laughs] And also, you know, with the added business value of encouraging more customers to pay for the product. But I think I also I'm maybe figuring out how to accept like, okay, like, how could I, like, step away from this in the middle and be able to feel good that I've left it in a place that someone else could see through? +JOËL: So you mentioned you're taking this over from somebody else, and this has been kind of six years in the making. I'm curious, is the person who introduced this feature flag six years ago are they even still at the company? +STEPHANIE: No, they are not, which I think is pretty typical, you know, it's, like, really common for someone who had all that context about how it came to be. In fact, I actually didn't even realize that the feature flag was the original beta version of the product because that's not what it's called. [laughs] And it was when I was first onboarding onto this project, and I was like, "Hey, like, what is this? Like, why is this still here?" Knowing that the canonical, you know, version that customers were using was the paid version. +And the team was like, "Oh, yeah, like, that's this whole thing that we've been meaning to remove for a long time." So it's really interesting to see the lifecycle, like, as to some of this code a little bit. And sometimes, it can be really frustrating, but this has felt a little more like an archaeology dig a little bit. +JOËL: That sounds like a really interesting project to be on. +STEPHANIE: Yeah. What about you, Joël, what's new in your world? +JOËL: So, on my project, I've been having to do a lot of small database migrations. So I've got a bunch of these little features to do that all involve doing database migrations. They're not building on each other. So I'm just doing them all, like, in different feature branches, and pushing them all up to GitHub to get reviewed, kind of working on them in parallel. +And the problem that happens is that when you switch from one branch where you've run a migration to another and then run migrations again, some local database state persists between the branch switch, which means that when you run the migrations, then this app uses a structure.sql. And the structure.sql has a bunch of extra junk from other branches you've been on that you don't want as part of your diff. And beyond, like, two or three branches, this becomes an absolute mess. +STEPHANIE: Oh, I have been there. [laughs] It's always really frustrating when I switch branches and then try to do my development and then realize that I have had my leftover database changes. And then having to go back and then always forgetting what order of operations to do to reverse the migration and then having to re-migrate. I know that pain very well. +JOËL: Something I've been doing for this project is when I switch branches, making sure that my structure SQL is checked out to the latest version from the main branch. So I have a clean structure SQL then I drop my local database, recreate an empty one, and run a rake db:schema:load. And that will load that structure file as it is on the main branch into the database schema. +That does not have any of the migrations on this branch run, so, at that point, I can run a rake db:migrate. And I will get exactly what's on main plus what gets generated on this branch and nothing else. And so, that's been a way that I've been able to kind of switch between branches and run database operations without getting any cross-contamination. +STEPHANIE: Cross-contamination. I like that term. Have you automated this at all, or are you doing this manually? +JOËL: Entirely manually. I could probably script some of this. Right now...so it's three steps, right? Drop, create, schema load. I just have them in one command because you can chain Unix commands with a double ampersand. So that's what I'm doing right now. I want to say there's a db:reset task, but I think that it uses migrate rather than schema load. And I don't want to actually run migrations. +STEPHANIE: Yeah, that would take longer. That's funny. I do love the up arrow key [laughs] in your terminal for, you know, going back to the thing you're running over and over again. +I also appreciate the couple extra seconds that you're spending in waiting for your database to recreate. Like, you're paying that cost upfront rather than down the line when you are in the middle of doing [laughs] what you're trying to do and realize, oh no, my database is not in the state that I want it to be for this branch. +JOËL: Or I'm dealing with some awful git conflict when trying to merge some of these branches. Or, you know, somebody comments on my PR and says, "Why are you touching the orders table? This change has nothing to do with orders." I'm like, "Oh, sorry, that actually came out of a different thing that I did." So, yep, keeping those diffs small. +STEPHANIE: Nice. Well, I'm glad that you found a way to manage it. +JOËL: So you mentioned the up arrow key and how that's really nice in the terminal. Something that I've been relying on a lot recently is reverse history search, CTRL+R in the terminal. That allows me to, instead of, like, going one by one in order of the history, filter for something that matches the thing that I've written. So, in this case, I'll hit CTRL+R, type, you know, Rails DB or whatever, then immediately it shows me, oh, did you want this long command? Hit enter, and I'm done. Even if I've done, you know, 20 git commands between then and the last time I ran it. +STEPHANIE: Yeah, that's a great tip. +So, a few weeks ago, we received a listener question from John, and he was responding to an episode where I'd asked about what the grammatical term is for verbs that are also nouns. He told us about the phrase, a verbal noun, for which there's a specific term called gerund, which is basically, in English, the words ending in ING. So, the gerund version of bike would be biking. +And he pointed out a really interesting relationship that gerunds have to data modeling, where you can use a gerund to model something that you might describe as a verb, especially as a user interaction, but can be turned into a noun to form a resource that you might want to introduce CRUD operations for in your application. +So one example that he was telling us about is the idea of maybe confirming a reservation. And, you know, we think of that as an action, but there is also a noun form of that, which is a confirmation. And so, confirmation could be a new resource, right? It could even be backed at the database level. And now you have a simpler way of representing the idea of confirming a reservation that is more about the confirmation as the resource itself rather than some kind of append them to a reservation itself. +JOËL: That's really cool. We get to have a crossover between grammar terms and programming, and being able to connect those two is always a fun day for me. +STEPHANIE: Yeah, I actually find it quite difficult, I think, to come up with noun forms of verbs on my own. Like, I just don't really think about resources that way. I'm so used to thinking about them in a more tangible way, I suppose. And it's really kind of cool that, you know, in the English language, we have turned these abstract ideas, these actions into, like, an object form. +JOËL: And this is particularly useful when we're trying to design RESTful either APIs or even just resources for a Rails app that's server-rendered so that instead of trying to create all these, like, extra actions on our controller that are verbs, we might decide to instead create new resources in the system, new nouns that people can do the standard 7 to. +STEPHANIE: Yes. I like that better than introducing custom controller actions or routes that deviate from RESTful conventions because, you know, I probably have seen a slash confirm reservation [laughs] URL. And, you know, this is, I think, an interesting way of avoiding having too many of those deviating endpoints. +JOËL: Yeah, I found that while Rails does have support for those, just all the built-in things play much more nicely if you're restricting yourself to the classic seven. And I think, in general, it's easier to model and think about things in a Rails app when you have a lot of noun resources rather than one giant controller with a bunch of kind of verb actions that you can do to it. In the more formal jargon, I think we might refer to that as RESTful style versus RPC style, a Remote Procedure Call. +STEPHANIE: Could you tell me more about Remote Procedure Calls and what that means? +JOËL: The general idea is that it's almost like doing a method call on an object somewhere. And so, you would say, hey, I've got an account, and I want to call the confirm method on it because I know that maybe underlying this is an ActiveRecord account model. And the API or the web UI is just a really thin layer over those objects. And so, more or less, whatever your methods on your object are, can be accessed through the API. So the two kind of mirror each other. +STEPHANIE: Got it. That's interesting because I can see how someone might want to do that, especially if, you know, the account is the domain object they're using at the, you know, persistence layer, and maybe they're not quite able to see an abstraction for something else. And so, they kind of want to try to fit that into their API design. +JOËL: So I have a perhaps controversial opinion, which is that the resources in your Rails application, so your controllers, shouldn't map one-to-one with your database tables, your models. +STEPHANIE: So, are you saying that you are more likely to have more abstractions or various resources than what you might have at the database level? +JOËL: Well, you know what? Maybe more, but I would say, in general, different. And I think because both layers, the controller layer, and the model layer, are playing with very different sets of constraints. So when I'm designing database tables, I'm thinking in terms of normalization. And so, maybe I would take one big concept and split it up into smaller concepts, smaller tables because I need this data to be normalized so that there's no ambiguity when I'm making queries. So maybe something that's one resource at the controller layer might actually be multiple tables at the database layer. +But the inverse could also be true, right? You might have, in the example that John gave, you know, an account that has a single table in the database with just a Boolean field confirmed yes or no. And maybe there's just a generic account resource. But then, separately, there's also a confirmation resource. And so, now we've got more resources at the controller layer than at the database layer. So I think it can go either way, but they're just not tightly coupled to each other. +STEPHANIE: Yeah, that makes sense. I think another way that I've seen this manifest is when, like you said, like, maybe multiple database tables need to be updated by, you know, a request to this endpoint. And now we get into [chuckles] what some people may call services or that territory of basically something. And what's interesting is that a lot of the service classes are named as verbs, right? So order, creator. And, like, whatever order of operations that needs to happen on multiple database objects that happens as a result of a user placing an order. But the idea that those are frequently named as verbs was kind of interesting to me and a bit of a connection to our new gerund tip. +JOËL: That's really interesting. I had not made that connection before. Because I think my first instinct would be to avoid a service object there and instead use something closer to a form object that takes the same idea and represents it as a noun, potentially with the same name as the resource. So maybe leaning really heavily into that idea of the verbal noun, not just in describing the controller or the route but then also maybe the object backing it, even if it's not connecting directly to a database table. +STEPHANIE: Interesting. So, in this case, would the form object be mapped closer to your controller resource? +JOËL: Potentially, yes. So maybe I do have some kind of, like, object that represents a confirmation and makes it nicer to render the confirmation form on the edit page or the new page. In this case, you know, it's probably just one checkbox, so maybe it's not worth creating an object. But if there were multiple fields, then yes, maybe it's nice to create an in-memory object that has the same name as the resource. Similar maybe for a resource that represents multiple underlying database tables. It can be nice to have kind of one object that represents all of them, almost like a facade, I guess. +STEPHANIE: Yeah, that's really interesting. I like that idea of a facade, or it's, like, something at a higher level representing hopefully, like, some kind of meaning of all of these database objects together. +JOËL: I want to give a shout-out to talk from a former thoughtboter, Derek Prior—actually, former Bike Shed host—from RailsConf 2017 called In Relentless Pursuit of REST, where he digs into a lot of these concepts, particularly how to model resources in your Rails app that don't necessarily map one to one with a database table, and why that can be a good thing. Have you seen that talk? +STEPHANIE: I haven't, but I love the title of it. It's a great pun. It's very evocative, I think because I'm really curious about this idea of a relentless pursuit. Because I think another way to react to that could be to be done with REST entirely and maybe go with something like GraphQL. +JOËL: So instead of a relentless pursuit, it's a relentless...what's the opposite of pursuing? Fleeing? +STEPHANIE: Fleeing? [laughs] I like how we arrived there at the same time. Yes. So now I'm thinking of I had mentioned a little bit ago on the show we had our spicy takes Lightning Talks on our Boost Team. And a fellow thoughtboter, Chris White, he had given a talk about Why REST Is Not the Best and for -- +JOËL: Also, a great title. +STEPHANIE: Yes, also, a great title. +JOËL: I love the rhyming there. +STEPHANIE: Yeah. And his reaction to the idea of trying to conform user interactions that don't quite map to a noun or an obvious resource was to potentially introduce GraphQL, where you have one endpoint that can service really anything that you can think of, I suppose. But, in his example, he was making the argument that human interactions are not database resources, right? +And maybe if you're not able to find that abstraction as a noun or object, with GraphQL, you can encapsulate those ideas as closer to actions, but in the GraphQL world, like, I think they're called mutations. But it is, I think, a whole world of, like, deciding what you want to be changed on the server side that is a little less constrained to having to come up with the right abstraction. +JOËL: I feel like GraphQL kind of takes that, like, complete opposite philosophy in that instead of saying, hey, let's have, like, this decoupling between the API layer and the database, GraphQL almost says, "No, let's lean into that." And yeah, you want to traverse the graph of, like, tables under the hood? Absolutely. You get to know the tables. You get to know how they're related to each other. +I guess, in theory, you could build a middle layer, and that's the graph that gets traversed rather than the graph of the tables. In practice, I think most people build it so that the API layer more or less has access directly to tables. Has that been your experience? +STEPHANIE: That's really interesting that you brought that up. I haven't worked with GraphQL in a while, but I was reading up on it before we started recording because I was kind of curious about how it might play with what we're talking about now. But the idea that it's graphed based, to me, was like, oh, like, that naturally, it could look very much like, you know, an entity graph of your relational database. +But the more I was reading about the GraphQL schema and different types, I realized that it could actually look quite different. And because it is a little bit closer to your UI layer, like, maybe you are building an abstraction that is more for serving that as that middle layer between your front end and your back end. +JOËL: That's really interesting that you mentioned that because I feel like the sort of traditional way that APIs are built is that they are built by the back-end team. And oftentimes, they will reflect the database schema. But you kind of mentioned with GraphQL here, sometimes it's the opposite that happens. Instead of being driven kind of from the back towards the front, it might be driven from the front towards the back where the UI team is building something that says, hey, we need these objects. We need these connections. Can you expose them to us? And then they get access to them. +What has been your experience when you've been working with front ends that are backed by a GraphQL API? +STEPHANIE: I think I've tended to see a GraphQL API when you do have a pretty rich client-side application with a lot of user interactions that then need to, you know, go and fetch some data. And you, like, really, you know, obviously don't want a page reload, right? +So it's really interesting, actually, that you pointed out that it's, like, perhaps the front end or the UI driving the API. Because, on one hand, the flexibility is really nice. And there's a lot more freedom even in maybe, like, what the product can do or how it would look. On the other hand, what I've kind of also seen is that eventually, maybe we do just want an API that we can talk to separate from, you know, any kind of UI. And, at that point, we have to go and build a separate thing [laughs] for the same data. +JOËL: So we've been talking about structuring APIs and, like, boundaries and things like that. I think my personal favorite feature of GraphQL is not the graph part but the fact that it comes with a built-in schema. And that plays really nicely with some typed technologies. Particularly, I've used Elm with some of the GraphQL libraries there, and that experience is just really nice. Where it will tell you if your front-end code is not compatible with the current API schema, and it will generate some things based off the schema. +So you have this really nice feedback cycle where somebody makes a change to the API, or you want to make a change to the code, and it will tell you immediately is your front end compatible with the current state of the back end? Which is a classic problem with developing front-end code. +STEPHANIE: First of all, I think it's very funny that you admitted to not preferring the graph part of GraphQL as a graph enthusiast yourself. [laughs] But I think I'm in agreement with you because, like, normally, I'm looking at it in its schema format. And that makes a lot of sense to me. +But what you said was really interesting because, in some ways, we're now kind of going back to the idea of maybe boundaries blurring because the types that you are creating for GraphQL are kind of then servicing both your front end and your back end. Do you think that's accurate? +JOËL: Ooh. That is an important distinction. I think you can. And I want to say that in some TypeScript implementations, you do use the types on both sides. In Elm, typically, you would not unless there's something really primitive, like a string or something like that. +STEPHANIE: Okay, how does that work? +JOËL: So you have some conversion layer that happens. +STEPHANIE: Got it. +JOËL: Honestly, I think that's my preference, and not just at the front end versus API layer but kind of all throughout. So the shape of an object in the database should not be the same shape as the object in the business logic that runs on the back end, which should not be the same shape as the object in transport, so JSON or whatever, which is also not the same shape as the object in your front-end code. Those might be similar, but each of these layers has different responsibilities, different things it's trying to optimize for. +Your code should be built, in my opinion, in a way that allows all four of those layers to diverge in their interpretation of not only what maybe common entities are, so maybe a user looks slightly different at each of these layers, but maybe even what the entities are to start with. And that maybe in the database what, we don't have a full user, we've got a profile and an account, and those get merged somehow. And eventually, when it gets to the front end, all we care about is the concept of a user because that's what we need in that context. +STEPHANIE: Yeah, that's really interesting because now it almost sounds like separate systems, which they kind of are, and then finding a way to make them work also as one bigger [laughs] system. I would love to ask, though, what that conversion looks like to you. Or, like, how have you implemented that? Or, like, what kind of pattern would you use for that? +JOËL: So I'm going to give a shout-out to the article that I always give a shout-out to: Parse, Don't Validate. In general, yeah, you do a transformation, and potentially it can fail. Let's say I'm pulling data from a GraphQL API into an Elm app. Elm has some built-in libraries for doing those transformations and will tell you at compile time if you're incorrectly transforming the data that comes from the shape that we expect from the schema. +But just because the schema comes in as, like, a flat object with certain fields or maybe it's a deeply nested chain of objects in GraphQL, it doesn't mean that it has to be that way in your Elm app. So that transformation step, you get to sort of make it whatever you want. +So my general approach is, at each layer, forget what other people are sending you and just design the entities that you would like to. I've heard the term wish-driven development, which I really like. So just, you know, if you could have, like, to make your life easy, what would the entities look like? And then kind of work backwards from there to make that sort of perfect world a reality for you and make it play nicely with other systems. And, to me, that's true at every layer of the application. +STEPHANIE: Interesting. So I'm also imagining that the transformation kind of has to happen both ways, right? Like, the server needs a way to transform data from the front end or some, you know, whatever, third party. But that's also true of the front end because what you're kind of saying is that these will be different. [laughs] +JOËL: Right. And, in many ways, it has to be because JSON is a very limited format. But some of the fancier things that you might have access to either on the back end or on the front end might be challenging to represent natively in JSON. And a classic one would be what Elm calls a custom type. You know, they're also called tagged unions, discriminated unions, algebraic data types. These things go by a bajillion names, and it's confusing. +But they're really kind of awkward and hard, almost impossible to represent in straight-up JSON because JSON is a very limited kind of transportation format. So you have to almost, like, have a rehydration step on one side and a kind of packing down step on the other when you're reading or writing from a JSON API. +STEPHANIE: Have you ever heard of or played that Wikipedia game Getting to Philosophy? +JOËL: I've done, I think, variations on it, the idea that you have a start and an end article, and then you have to either get through in the fewest amount of clicks, or it might be a timed thing, whoever can get to the target article first. Is that what you're referring to? +STEPHANIE: Yeah. So, in this case, I'm thinking, how many clicks through Wikipedia to get to the Wiki article about philosophy? And that's how I'm thinking about how we end up getting to [laughs] talking about types and parsing, and graphs even [laughs] on the show. +JOËL: It's all connected, almost as if it forms a graph of knowledge. +STEPHANIE: Learning that's another common topic on the show. [laughs] I think it's great. It's a lot of interesting lenses to view, like, the same things and just digging further and further deeper into them to always, like, come away with a little more perspective. +JOËL: So, in the vein of wish-driven development, if you're starting a brand-new front-end UI, what is your sort of dream approach for working with an API? +STEPHANIE: Wish-driven development is very visceral to me because I often think about when I'm working with legacy code and what my wishes and dreams were for the, you know, the stack or the technology or whatever. But, at that point, I don't really have the power to change it. You know, it's like I have what I have. And that's different from being in the driver's seat of a greenfield application where you're not just wishing. You're just deciding for yourself. You get to choose. +At the end of the day, though, I think, you know, you're likely starting from a simple application. And you haven't gotten to the point where you have, like, a lot of features that you have to figure out how to support and, like, complexity to manage. And, you know, you don't even know if you're going to get there. So I would probably start with REST. +JOËL: So we started this episode from a very back-end perspective where we're talking about Rails, and routes, and controllers. And we kind of ended it talking from a very front-end perspective. We also contrasted kind of a more RESTful approach, versus GraphQL, versus more kind of old-school RPC-style routing. +And now, I'm almost starting to wonder if there's some kind of correlation between whether someone primarily works from the back end and maybe likes, let's say, REST versus maybe somebody on the front end maybe preferring GraphQL. So I'd be happy for any of our listeners who have strong opinions preferring GraphQL, or REST, or something else; message us at hosts@bikeshed.fm and let us know. And, if you do, please let us know if you're primarily a front-end or a back-end developer because I think it would be really fun to see any connections there. +STEPHANIE: Absolutely. On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + It's updates on the work front today! Stephanie was tasked with removing a six-year-old feature flag from a codebase. Joël's been doing a lot of small database migrations.

+ +

A listener question sparked today's main discussion on gerunds' interesting relationship to data modeling.

+ +
+ + + +

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, this week, I've been tasked with something that I've been finding very fun, which is removing a six-year-old feature flag from the codebase that is still very much in use in the sense that it is actually a mechanism for providing customers access to a feature that had been originally launched as a beta. And that was why the feature flag was introduced.

+ +

But in the years since, you know, the business has shifted to a model where you have to pay for those features. And some customers are still hanging on to this beta feature flag that lets them get the features for free. So one of the ways that we're trying to convert those people to be paying for the feature is to, you know, gradually remove the feature flag and maybe, you know, give them a heads up that this is happening.

+ +

I'm also getting to improve the codebase with this change as well because it has really been propagating [laughs] in there. There wasn't necessarily a single, I guess, entry point for determining whether customers should get access to this feature through the flag or not. So it ended up being repeated in a bunch of different places because the feature set has grown. And so, now we have to do this check for the flag in several places, like, different pages of the application. And it's been really interesting to see just how this kind of stuff can grow and mutate over several years.

+ +

JOËL: So, if I understand correctly, there's kind of two overlapping conditions now around this feature. So you have access to it if you've either paid for the feature or if you were a beta tester.

+ +

STEPHANIE: Yeah, exactly. And the interesting thought that I had about this was it actually sounds a lot like the strangler fig pattern, which we've talked about before, where we've now introduced the new source of data that we want to be using moving forward. But we still have this, you know, old limb or branch hanging on that hasn't quite been removed or pruned off [chuckles] yet. So that's what I'm doing now.

+ +

And it's nice in the sense that I can trust that we are already sending the correct data that we want to be consuming, and it's just the cleanup part. So, in some ways, we had been in that half-step for several years, and they're now getting to the point where we can finally remove it.

+ +

JOËL: I think in kind of true strangler fig pattern, you would probably move all of your users off of that feature flag so that the people that have it active are zero, at which point it is effectively dead code, and then you can remove it.

+ +

STEPHANIE: Yeah, that's a great point. And we had considered doing that first, but the thing that we had kind of come away with was that removing all of those customers from that feature flag would probably require a script or, you know, updating the production data. And that seemed a bit riskier actually to us because it wasn't as reversible as a code change.

+ +

JOËL: I think you bring up a really interesting point, which is that production data changes, in general, are just scarier than code changes. At least for me, it feels like it's fairly easy generally to revert a code change. Whereas if I've messed up the production database, [laughs] that's going to be unpleasant few days.

+ +

STEPHANIE: What's interesting is that this feature flag is not really supported by a nice user interface for managing it. And so, we inevitably had to do a more developer-focused solution to remove these customers from being able to access this feature. And so, the two options, you know, that we had available were to do it through data, like I mentioned, or do it through that code change. And again, I think we evaluated both options. But what's kind of nice about doing it with the code change is that when we eventually get to delete those feature flag records, it will be really nice and easy.

+ +

JOËL: That's really exciting. One thing that's different about kind of more mature projects is that we often get to do some kind of change management, unlike a greenfield app where you just get to, oh, let's introduce this new thing, cool. Oftentimes, on a more mature project, before you introduce the new thing, you have to figure out, like, what is the migration path towards that? Is that a kind of work that you enjoy?

+ +

STEPHANIE: I think this was definitely an exercise in thinking about how to break this down into steps. So, yeah, that change management process you mentioned, I, like, did find a lot of satisfaction in trying to break it up, you know, especially because I was also thinking that you know, maybe I am not able to see the complete, like, cleanup and removal, and, like, where can someone pick up after me? In some ways, I feel like I was kind of stepping into that migration, you know, six years [laughs] in the making from beta to the paid product.

+ +

But I think I will feel really satisfied if I'm able to see this thing through and get to celebrate the success of saying, hey, like, I removed...at this point, it's a few hundred lines of code. [laughs] And also, you know, with the added business value of encouraging more customers to pay for the product. But I think I also I'm maybe figuring out how to accept like, okay, like, how could I, like, step away from this in the middle and be able to feel good that I've left it in a place that someone else could see through?

+ +

JOËL: So you mentioned you're taking this over from somebody else, and this has been kind of six years in the making. I'm curious, is the person who introduced this feature flag six years ago are they even still at the company?

+ +

STEPHANIE: No, they are not, which I think is pretty typical, you know, it's, like, really common for someone who had all that context about how it came to be. In fact, I actually didn't even realize that the feature flag was the original beta version of the product because that's not what it's called. [laughs] And it was when I was first onboarding onto this project, and I was like, "Hey, like, what is this? Like, why is this still here?" Knowing that the canonical, you know, version that customers were using was the paid version.

+ +

And the team was like, "Oh, yeah, like, that's this whole thing that we've been meaning to remove for a long time." So it's really interesting to see the lifecycle, like, as to some of this code a little bit. And sometimes, it can be really frustrating, but this has felt a little more like an archaeology dig a little bit.

+ +

JOËL: That sounds like a really interesting project to be on.

+ +

STEPHANIE: Yeah. What about you, Joël, what's new in your world?

+ +

JOËL: So, on my project, I've been having to do a lot of small database migrations. So I've got a bunch of these little features to do that all involve doing database migrations. They're not building on each other. So I'm just doing them all, like, in different feature branches, and pushing them all up to GitHub to get reviewed, kind of working on them in parallel.

+ +

And the problem that happens is that when you switch from one branch where you've run a migration to another and then run migrations again, some local database state persists between the branch switch, which means that when you run the migrations, then this app uses a structure.sql. And the structure.sql has a bunch of extra junk from other branches you've been on that you don't want as part of your diff. And beyond, like, two or three branches, this becomes an absolute mess.

+ +

STEPHANIE: Oh, I have been there. [laughs] It's always really frustrating when I switch branches and then try to do my development and then realize that I have had my leftover database changes. And then having to go back and then always forgetting what order of operations to do to reverse the migration and then having to re-migrate. I know that pain very well.

+ +

JOËL: Something I've been doing for this project is when I switch branches, making sure that my structure SQL is checked out to the latest version from the main branch. So I have a clean structure SQL then I drop my local database, recreate an empty one, and run a rake db:schema:load. And that will load that structure file as it is on the main branch into the database schema.

+ +

That does not have any of the migrations on this branch run, so, at that point, I can run a rake db:migrate. And I will get exactly what's on main plus what gets generated on this branch and nothing else. And so, that's been a way that I've been able to kind of switch between branches and run database operations without getting any cross-contamination.

+ +

STEPHANIE: Cross-contamination. I like that term. Have you automated this at all, or are you doing this manually?

+ +

JOËL: Entirely manually. I could probably script some of this. Right now...so it's three steps, right? Drop, create, schema load. I just have them in one command because you can chain Unix commands with a double ampersand. So that's what I'm doing right now. I want to say there's a db:reset task, but I think that it uses migrate rather than schema load. And I don't want to actually run migrations.

+ +

STEPHANIE: Yeah, that would take longer. That's funny. I do love the up arrow key [laughs] in your terminal for, you know, going back to the thing you're running over and over again.

+ +

I also appreciate the couple extra seconds that you're spending in waiting for your database to recreate. Like, you're paying that cost upfront rather than down the line when you are in the middle of doing [laughs] what you're trying to do and realize, oh no, my database is not in the state that I want it to be for this branch.

+ +

JOËL: Or I'm dealing with some awful git conflict when trying to merge some of these branches. Or, you know, somebody comments on my PR and says, "Why are you touching the orders table? This change has nothing to do with orders." I'm like, "Oh, sorry, that actually came out of a different thing that I did." So, yep, keeping those diffs small.

+ +

STEPHANIE: Nice. Well, I'm glad that you found a way to manage it.

+ +

JOËL: So you mentioned the up arrow key and how that's really nice in the terminal. Something that I've been relying on a lot recently is reverse history search, CTRL+R in the terminal. That allows me to, instead of, like, going one by one in order of the history, filter for something that matches the thing that I've written. So, in this case, I'll hit CTRL+R, type, you know, Rails DB or whatever, then immediately it shows me, oh, did you want this long command? Hit enter, and I'm done. Even if I've done, you know, 20 git commands between then and the last time I ran it.

+ +

STEPHANIE: Yeah, that's a great tip.

+ +

So, a few weeks ago, we received a listener question from John, and he was responding to an episode where I'd asked about what the grammatical term is for verbs that are also nouns. He told us about the phrase, a verbal noun, for which there's a specific term called gerund, which is basically, in English, the words ending in ING. So, the gerund version of bike would be biking.

+ +

And he pointed out a really interesting relationship that gerunds have to data modeling, where you can use a gerund to model something that you might describe as a verb, especially as a user interaction, but can be turned into a noun to form a resource that you might want to introduce CRUD operations for in your application.

+ +

So one example that he was telling us about is the idea of maybe confirming a reservation. And, you know, we think of that as an action, but there is also a noun form of that, which is a confirmation. And so, confirmation could be a new resource, right? It could even be backed at the database level. And now you have a simpler way of representing the idea of confirming a reservation that is more about the confirmation as the resource itself rather than some kind of append them to a reservation itself.

+ +

JOËL: That's really cool. We get to have a crossover between grammar terms and programming, and being able to connect those two is always a fun day for me.

+ +

STEPHANIE: Yeah, I actually find it quite difficult, I think, to come up with noun forms of verbs on my own. Like, I just don't really think about resources that way. I'm so used to thinking about them in a more tangible way, I suppose. And it's really kind of cool that, you know, in the English language, we have turned these abstract ideas, these actions into, like, an object form.

+ +

JOËL: And this is particularly useful when we're trying to design RESTful either APIs or even just resources for a Rails app that's server-rendered so that instead of trying to create all these, like, extra actions on our controller that are verbs, we might decide to instead create new resources in the system, new nouns that people can do the standard 7 to.

+ +

STEPHANIE: Yes. I like that better than introducing custom controller actions or routes that deviate from RESTful conventions because, you know, I probably have seen a slash confirm reservation [laughs] URL. And, you know, this is, I think, an interesting way of avoiding having too many of those deviating endpoints.

+ +

JOËL: Yeah, I found that while Rails does have support for those, just all the built-in things play much more nicely if you're restricting yourself to the classic seven. And I think, in general, it's easier to model and think about things in a Rails app when you have a lot of noun resources rather than one giant controller with a bunch of kind of verb actions that you can do to it. In the more formal jargon, I think we might refer to that as RESTful style versus RPC style, a Remote Procedure Call.

+ +

STEPHANIE: Could you tell me more about Remote Procedure Calls and what that means?

+ +

JOËL: The general idea is that it's almost like doing a method call on an object somewhere. And so, you would say, hey, I've got an account, and I want to call the confirm method on it because I know that maybe underlying this is an ActiveRecord account model. And the API or the web UI is just a really thin layer over those objects. And so, more or less, whatever your methods on your object are, can be accessed through the API. So the two kind of mirror each other.

+ +

STEPHANIE: Got it. That's interesting because I can see how someone might want to do that, especially if, you know, the account is the domain object they're using at the, you know, persistence layer, and maybe they're not quite able to see an abstraction for something else. And so, they kind of want to try to fit that into their API design.

+ +

JOËL: So I have a perhaps controversial opinion, which is that the resources in your Rails application, so your controllers, shouldn't map one-to-one with your database tables, your models.

+ +

STEPHANIE: So, are you saying that you are more likely to have more abstractions or various resources than what you might have at the database level?

+ +

JOËL: Well, you know what? Maybe more, but I would say, in general, different. And I think because both layers, the controller layer, and the model layer, are playing with very different sets of constraints. So when I'm designing database tables, I'm thinking in terms of normalization. And so, maybe I would take one big concept and split it up into smaller concepts, smaller tables because I need this data to be normalized so that there's no ambiguity when I'm making queries. So maybe something that's one resource at the controller layer might actually be multiple tables at the database layer.

+ +

But the inverse could also be true, right? You might have, in the example that John gave, you know, an account that has a single table in the database with just a Boolean field confirmed yes or no. And maybe there's just a generic account resource. But then, separately, there's also a confirmation resource. And so, now we've got more resources at the controller layer than at the database layer. So I think it can go either way, but they're just not tightly coupled to each other.

+ +

STEPHANIE: Yeah, that makes sense. I think another way that I've seen this manifest is when, like you said, like, maybe multiple database tables need to be updated by, you know, a request to this endpoint. And now we get into [chuckles] what some people may call services or that territory of basically something. And what's interesting is that a lot of the service classes are named as verbs, right? So order, creator. And, like, whatever order of operations that needs to happen on multiple database objects that happens as a result of a user placing an order. But the idea that those are frequently named as verbs was kind of interesting to me and a bit of a connection to our new gerund tip.

+ +

JOËL: That's really interesting. I had not made that connection before. Because I think my first instinct would be to avoid a service object there and instead use something closer to a form object that takes the same idea and represents it as a noun, potentially with the same name as the resource. So maybe leaning really heavily into that idea of the verbal noun, not just in describing the controller or the route but then also maybe the object backing it, even if it's not connecting directly to a database table.

+ +

STEPHANIE: Interesting. So, in this case, would the form object be mapped closer to your controller resource?

+ +

JOËL: Potentially, yes. So maybe I do have some kind of, like, object that represents a confirmation and makes it nicer to render the confirmation form on the edit page or the new page. In this case, you know, it's probably just one checkbox, so maybe it's not worth creating an object. But if there were multiple fields, then yes, maybe it's nice to create an in-memory object that has the same name as the resource. Similar maybe for a resource that represents multiple underlying database tables. It can be nice to have kind of one object that represents all of them, almost like a facade, I guess.

+ +

STEPHANIE: Yeah, that's really interesting. I like that idea of a facade, or it's, like, something at a higher level representing hopefully, like, some kind of meaning of all of these database objects together.

+ +

JOËL: I want to give a shout-out to talk from a former thoughtboter, Derek Prior—actually, former Bike Shed host—from RailsConf 2017 called In Relentless Pursuit of REST, where he digs into a lot of these concepts, particularly how to model resources in your Rails app that don't necessarily map one to one with a database table, and why that can be a good thing. Have you seen that talk?

+ +

STEPHANIE: I haven't, but I love the title of it. It's a great pun. It's very evocative, I think because I'm really curious about this idea of a relentless pursuit. Because I think another way to react to that could be to be done with REST entirely and maybe go with something like GraphQL.

+ +

JOËL: So instead of a relentless pursuit, it's a relentless...what's the opposite of pursuing? Fleeing?

+ +

STEPHANIE: Fleeing? [laughs] I like how we arrived there at the same time. Yes. So now I'm thinking of I had mentioned a little bit ago on the show we had our spicy takes Lightning Talks on our Boost Team. And a fellow thoughtboter, Chris White, he had given a talk about Why REST Is Not the Best and for --

+ +

JOËL: Also, a great title.

+ +

STEPHANIE: Yes, also, a great title.

+ +

JOËL: I love the rhyming there.

+ +

STEPHANIE: Yeah. And his reaction to the idea of trying to conform user interactions that don't quite map to a noun or an obvious resource was to potentially introduce GraphQL, where you have one endpoint that can service really anything that you can think of, I suppose. But, in his example, he was making the argument that human interactions are not database resources, right?

+ +

And maybe if you're not able to find that abstraction as a noun or object, with GraphQL, you can encapsulate those ideas as closer to actions, but in the GraphQL world, like, I think they're called mutations. But it is, I think, a whole world of, like, deciding what you want to be changed on the server side that is a little less constrained to having to come up with the right abstraction.

+ +

JOËL: I feel like GraphQL kind of takes that, like, complete opposite philosophy in that instead of saying, hey, let's have, like, this decoupling between the API layer and the database, GraphQL almost says, "No, let's lean into that." And yeah, you want to traverse the graph of, like, tables under the hood? Absolutely. You get to know the tables. You get to know how they're related to each other.

+ +

I guess, in theory, you could build a middle layer, and that's the graph that gets traversed rather than the graph of the tables. In practice, I think most people build it so that the API layer more or less has access directly to tables. Has that been your experience?

+ +

STEPHANIE: That's really interesting that you brought that up. I haven't worked with GraphQL in a while, but I was reading up on it before we started recording because I was kind of curious about how it might play with what we're talking about now. But the idea that it's graphed based, to me, was like, oh, like, that naturally, it could look very much like, you know, an entity graph of your relational database.

+ +

But the more I was reading about the GraphQL schema and different types, I realized that it could actually look quite different. And because it is a little bit closer to your UI layer, like, maybe you are building an abstraction that is more for serving that as that middle layer between your front end and your back end.

+ +

JOËL: That's really interesting that you mentioned that because I feel like the sort of traditional way that APIs are built is that they are built by the back-end team. And oftentimes, they will reflect the database schema. But you kind of mentioned with GraphQL here, sometimes it's the opposite that happens. Instead of being driven kind of from the back towards the front, it might be driven from the front towards the back where the UI team is building something that says, hey, we need these objects. We need these connections. Can you expose them to us? And then they get access to them.

+ +

What has been your experience when you've been working with front ends that are backed by a GraphQL API?

+ +

STEPHANIE: I think I've tended to see a GraphQL API when you do have a pretty rich client-side application with a lot of user interactions that then need to, you know, go and fetch some data. And you, like, really, you know, obviously don't want a page reload, right?

+ +

So it's really interesting, actually, that you pointed out that it's, like, perhaps the front end or the UI driving the API. Because, on one hand, the flexibility is really nice. And there's a lot more freedom even in maybe, like, what the product can do or how it would look. On the other hand, what I've kind of also seen is that eventually, maybe we do just want an API that we can talk to separate from, you know, any kind of UI. And, at that point, we have to go and build a separate thing [laughs] for the same data.

+ +

JOËL: So we've been talking about structuring APIs and, like, boundaries and things like that. I think my personal favorite feature of GraphQL is not the graph part but the fact that it comes with a built-in schema. And that plays really nicely with some typed technologies. Particularly, I've used Elm with some of the GraphQL libraries there, and that experience is just really nice. Where it will tell you if your front-end code is not compatible with the current API schema, and it will generate some things based off the schema.

+ +

So you have this really nice feedback cycle where somebody makes a change to the API, or you want to make a change to the code, and it will tell you immediately is your front end compatible with the current state of the back end? Which is a classic problem with developing front-end code.

+ +

STEPHANIE: First of all, I think it's very funny that you admitted to not preferring the graph part of GraphQL as a graph enthusiast yourself. [laughs] But I think I'm in agreement with you because, like, normally, I'm looking at it in its schema format. And that makes a lot of sense to me.

+ +

But what you said was really interesting because, in some ways, we're now kind of going back to the idea of maybe boundaries blurring because the types that you are creating for GraphQL are kind of then servicing both your front end and your back end. Do you think that's accurate?

+ +

JOËL: Ooh. That is an important distinction. I think you can. And I want to say that in some TypeScript implementations, you do use the types on both sides. In Elm, typically, you would not unless there's something really primitive, like a string or something like that.

+ +

STEPHANIE: Okay, how does that work?

+ +

JOËL: So you have some conversion layer that happens.

+ +

STEPHANIE: Got it.

+ +

JOËL: Honestly, I think that's my preference, and not just at the front end versus API layer but kind of all throughout. So the shape of an object in the database should not be the same shape as the object in the business logic that runs on the back end, which should not be the same shape as the object in transport, so JSON or whatever, which is also not the same shape as the object in your front-end code. Those might be similar, but each of these layers has different responsibilities, different things it's trying to optimize for.

+ +

Your code should be built, in my opinion, in a way that allows all four of those layers to diverge in their interpretation of not only what maybe common entities are, so maybe a user looks slightly different at each of these layers, but maybe even what the entities are to start with. And that maybe in the database what, we don't have a full user, we've got a profile and an account, and those get merged somehow. And eventually, when it gets to the front end, all we care about is the concept of a user because that's what we need in that context.

+ +

STEPHANIE: Yeah, that's really interesting because now it almost sounds like separate systems, which they kind of are, and then finding a way to make them work also as one bigger [laughs] system. I would love to ask, though, what that conversion looks like to you. Or, like, how have you implemented that? Or, like, what kind of pattern would you use for that?

+ +

JOËL: So I'm going to give a shout-out to the article that I always give a shout-out to: Parse, Don't Validate. In general, yeah, you do a transformation, and potentially it can fail. Let's say I'm pulling data from a GraphQL API into an Elm app. Elm has some built-in libraries for doing those transformations and will tell you at compile time if you're incorrectly transforming the data that comes from the shape that we expect from the schema.

+ +

But just because the schema comes in as, like, a flat object with certain fields or maybe it's a deeply nested chain of objects in GraphQL, it doesn't mean that it has to be that way in your Elm app. So that transformation step, you get to sort of make it whatever you want.

+ +

So my general approach is, at each layer, forget what other people are sending you and just design the entities that you would like to. I've heard the term wish-driven development, which I really like. So just, you know, if you could have, like, to make your life easy, what would the entities look like? And then kind of work backwards from there to make that sort of perfect world a reality for you and make it play nicely with other systems. And, to me, that's true at every layer of the application.

+ +

STEPHANIE: Interesting. So I'm also imagining that the transformation kind of has to happen both ways, right? Like, the server needs a way to transform data from the front end or some, you know, whatever, third party. But that's also true of the front end because what you're kind of saying is that these will be different. [laughs]

+ +

JOËL: Right. And, in many ways, it has to be because JSON is a very limited format. But some of the fancier things that you might have access to either on the back end or on the front end might be challenging to represent natively in JSON. And a classic one would be what Elm calls a custom type. You know, they're also called tagged unions, discriminated unions, algebraic data types. These things go by a bajillion names, and it's confusing.

+ +

But they're really kind of awkward and hard, almost impossible to represent in straight-up JSON because JSON is a very limited kind of transportation format. So you have to almost, like, have a rehydration step on one side and a kind of packing down step on the other when you're reading or writing from a JSON API.

+ +

STEPHANIE: Have you ever heard of or played that Wikipedia game Getting to Philosophy?

+ +

JOËL: I've done, I think, variations on it, the idea that you have a start and an end article, and then you have to either get through in the fewest amount of clicks, or it might be a timed thing, whoever can get to the target article first. Is that what you're referring to?

+ +

STEPHANIE: Yeah. So, in this case, I'm thinking, how many clicks through Wikipedia to get to the Wiki article about philosophy? And that's how I'm thinking about how we end up getting to [laughs] talking about types and parsing, and graphs even [laughs] on the show.

+ +

JOËL: It's all connected, almost as if it forms a graph of knowledge.

+ +

STEPHANIE: Learning that's another common topic on the show. [laughs] I think it's great. It's a lot of interesting lenses to view, like, the same things and just digging further and further deeper into them to always, like, come away with a little more perspective.

+ +

JOËL: So, in the vein of wish-driven development, if you're starting a brand-new front-end UI, what is your sort of dream approach for working with an API?

+ +

STEPHANIE: Wish-driven development is very visceral to me because I often think about when I'm working with legacy code and what my wishes and dreams were for the, you know, the stack or the technology or whatever. But, at that point, I don't really have the power to change it. You know, it's like I have what I have. And that's different from being in the driver's seat of a greenfield application where you're not just wishing. You're just deciding for yourself. You get to choose.

+ +

At the end of the day, though, I think, you know, you're likely starting from a simple application. And you haven't gotten to the point where you have, like, a lot of features that you have to figure out how to support and, like, complexity to manage. And, you know, you don't even know if you're going to get there. So I would probably start with REST.

+ +

JOËL: So we started this episode from a very back-end perspective where we're talking about Rails, and routes, and controllers. And we kind of ended it talking from a very front-end perspective. We also contrasted kind of a more RESTful approach, versus GraphQL, versus more kind of old-school RPC-style routing.

+ +

And now, I'm almost starting to wonder if there's some kind of correlation between whether someone primarily works from the back end and maybe likes, let's say, REST versus maybe somebody on the front end maybe preferring GraphQL. So I'd be happy for any of our listeners who have strong opinions preferring GraphQL, or REST, or something else; message us at hosts@bikeshed.fm and let us know. And, if you do, please let us know if you're primarily a front-end or a back-end developer because I think it would be really fun to see any connections there.

+ +

STEPHANIE: Absolutely. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + It's updates on the work front today! Stephanie was tasked with removing a six-year-old feature flag from a codebase. Joël's been doing a lot of small database migrations.

+ +

A listener question sparked today's main discussion on gerunds' interesting relationship to data modeling.

+ +
+ + + +

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, this week, I've been tasked with something that I've been finding very fun, which is removing a six-year-old feature flag from the codebase that is still very much in use in the sense that it is actually a mechanism for providing customers access to a feature that had been originally launched as a beta. And that was why the feature flag was introduced.

+ +

But in the years since, you know, the business has shifted to a model where you have to pay for those features. And some customers are still hanging on to this beta feature flag that lets them get the features for free. So one of the ways that we're trying to convert those people to be paying for the feature is to, you know, gradually remove the feature flag and maybe, you know, give them a heads up that this is happening.

+ +

I'm also getting to improve the codebase with this change as well because it has really been propagating [laughs] in there. There wasn't necessarily a single, I guess, entry point for determining whether customers should get access to this feature through the flag or not. So it ended up being repeated in a bunch of different places because the feature set has grown. And so, now we have to do this check for the flag in several places, like, different pages of the application. And it's been really interesting to see just how this kind of stuff can grow and mutate over several years.

+ +

JOËL: So, if I understand correctly, there's kind of two overlapping conditions now around this feature. So you have access to it if you've either paid for the feature or if you were a beta tester.

+ +

STEPHANIE: Yeah, exactly. And the interesting thought that I had about this was it actually sounds a lot like the strangler fig pattern, which we've talked about before, where we've now introduced the new source of data that we want to be using moving forward. But we still have this, you know, old limb or branch hanging on that hasn't quite been removed or pruned off [chuckles] yet. So that's what I'm doing now.

+ +

And it's nice in the sense that I can trust that we are already sending the correct data that we want to be consuming, and it's just the cleanup part. So, in some ways, we had been in that half-step for several years, and they're now getting to the point where we can finally remove it.

+ +

JOËL: I think in kind of true strangler fig pattern, you would probably move all of your users off of that feature flag so that the people that have it active are zero, at which point it is effectively dead code, and then you can remove it.

+ +

STEPHANIE: Yeah, that's a great point. And we had considered doing that first, but the thing that we had kind of come away with was that removing all of those customers from that feature flag would probably require a script or, you know, updating the production data. And that seemed a bit riskier actually to us because it wasn't as reversible as a code change.

+ +

JOËL: I think you bring up a really interesting point, which is that production data changes, in general, are just scarier than code changes. At least for me, it feels like it's fairly easy generally to revert a code change. Whereas if I've messed up the production database, [laughs] that's going to be unpleasant few days.

+ +

STEPHANIE: What's interesting is that this feature flag is not really supported by a nice user interface for managing it. And so, we inevitably had to do a more developer-focused solution to remove these customers from being able to access this feature. And so, the two options, you know, that we had available were to do it through data, like I mentioned, or do it through that code change. And again, I think we evaluated both options. But what's kind of nice about doing it with the code change is that when we eventually get to delete those feature flag records, it will be really nice and easy.

+ +

JOËL: That's really exciting. One thing that's different about kind of more mature projects is that we often get to do some kind of change management, unlike a greenfield app where you just get to, oh, let's introduce this new thing, cool. Oftentimes, on a more mature project, before you introduce the new thing, you have to figure out, like, what is the migration path towards that? Is that a kind of work that you enjoy?

+ +

STEPHANIE: I think this was definitely an exercise in thinking about how to break this down into steps. So, yeah, that change management process you mentioned, I, like, did find a lot of satisfaction in trying to break it up, you know, especially because I was also thinking that you know, maybe I am not able to see the complete, like, cleanup and removal, and, like, where can someone pick up after me? In some ways, I feel like I was kind of stepping into that migration, you know, six years [laughs] in the making from beta to the paid product.

+ +

But I think I will feel really satisfied if I'm able to see this thing through and get to celebrate the success of saying, hey, like, I removed...at this point, it's a few hundred lines of code. [laughs] And also, you know, with the added business value of encouraging more customers to pay for the product. But I think I also I'm maybe figuring out how to accept like, okay, like, how could I, like, step away from this in the middle and be able to feel good that I've left it in a place that someone else could see through?

+ +

JOËL: So you mentioned you're taking this over from somebody else, and this has been kind of six years in the making. I'm curious, is the person who introduced this feature flag six years ago are they even still at the company?

+ +

STEPHANIE: No, they are not, which I think is pretty typical, you know, it's, like, really common for someone who had all that context about how it came to be. In fact, I actually didn't even realize that the feature flag was the original beta version of the product because that's not what it's called. [laughs] And it was when I was first onboarding onto this project, and I was like, "Hey, like, what is this? Like, why is this still here?" Knowing that the canonical, you know, version that customers were using was the paid version.

+ +

And the team was like, "Oh, yeah, like, that's this whole thing that we've been meaning to remove for a long time." So it's really interesting to see the lifecycle, like, as to some of this code a little bit. And sometimes, it can be really frustrating, but this has felt a little more like an archaeology dig a little bit.

+ +

JOËL: That sounds like a really interesting project to be on.

+ +

STEPHANIE: Yeah. What about you, Joël, what's new in your world?

+ +

JOËL: So, on my project, I've been having to do a lot of small database migrations. So I've got a bunch of these little features to do that all involve doing database migrations. They're not building on each other. So I'm just doing them all, like, in different feature branches, and pushing them all up to GitHub to get reviewed, kind of working on them in parallel.

+ +

And the problem that happens is that when you switch from one branch where you've run a migration to another and then run migrations again, some local database state persists between the branch switch, which means that when you run the migrations, then this app uses a structure.sql. And the structure.sql has a bunch of extra junk from other branches you've been on that you don't want as part of your diff. And beyond, like, two or three branches, this becomes an absolute mess.

+ +

STEPHANIE: Oh, I have been there. [laughs] It's always really frustrating when I switch branches and then try to do my development and then realize that I have had my leftover database changes. And then having to go back and then always forgetting what order of operations to do to reverse the migration and then having to re-migrate. I know that pain very well.

+ +

JOËL: Something I've been doing for this project is when I switch branches, making sure that my structure SQL is checked out to the latest version from the main branch. So I have a clean structure SQL then I drop my local database, recreate an empty one, and run a rake db:schema:load. And that will load that structure file as it is on the main branch into the database schema.

+ +

That does not have any of the migrations on this branch run, so, at that point, I can run a rake db:migrate. And I will get exactly what's on main plus what gets generated on this branch and nothing else. And so, that's been a way that I've been able to kind of switch between branches and run database operations without getting any cross-contamination.

+ +

STEPHANIE: Cross-contamination. I like that term. Have you automated this at all, or are you doing this manually?

+ +

JOËL: Entirely manually. I could probably script some of this. Right now...so it's three steps, right? Drop, create, schema load. I just have them in one command because you can chain Unix commands with a double ampersand. So that's what I'm doing right now. I want to say there's a db:reset task, but I think that it uses migrate rather than schema load. And I don't want to actually run migrations.

+ +

STEPHANIE: Yeah, that would take longer. That's funny. I do love the up arrow key [laughs] in your terminal for, you know, going back to the thing you're running over and over again.

+ +

I also appreciate the couple extra seconds that you're spending in waiting for your database to recreate. Like, you're paying that cost upfront rather than down the line when you are in the middle of doing [laughs] what you're trying to do and realize, oh no, my database is not in the state that I want it to be for this branch.

+ +

JOËL: Or I'm dealing with some awful git conflict when trying to merge some of these branches. Or, you know, somebody comments on my PR and says, "Why are you touching the orders table? This change has nothing to do with orders." I'm like, "Oh, sorry, that actually came out of a different thing that I did." So, yep, keeping those diffs small.

+ +

STEPHANIE: Nice. Well, I'm glad that you found a way to manage it.

+ +

JOËL: So you mentioned the up arrow key and how that's really nice in the terminal. Something that I've been relying on a lot recently is reverse history search, CTRL+R in the terminal. That allows me to, instead of, like, going one by one in order of the history, filter for something that matches the thing that I've written. So, in this case, I'll hit CTRL+R, type, you know, Rails DB or whatever, then immediately it shows me, oh, did you want this long command? Hit enter, and I'm done. Even if I've done, you know, 20 git commands between then and the last time I ran it.

+ +

STEPHANIE: Yeah, that's a great tip.

+ +

So, a few weeks ago, we received a listener question from John, and he was responding to an episode where I'd asked about what the grammatical term is for verbs that are also nouns. He told us about the phrase, a verbal noun, for which there's a specific term called gerund, which is basically, in English, the words ending in ING. So, the gerund version of bike would be biking.

+ +

And he pointed out a really interesting relationship that gerunds have to data modeling, where you can use a gerund to model something that you might describe as a verb, especially as a user interaction, but can be turned into a noun to form a resource that you might want to introduce CRUD operations for in your application.

+ +

So one example that he was telling us about is the idea of maybe confirming a reservation. And, you know, we think of that as an action, but there is also a noun form of that, which is a confirmation. And so, confirmation could be a new resource, right? It could even be backed at the database level. And now you have a simpler way of representing the idea of confirming a reservation that is more about the confirmation as the resource itself rather than some kind of append them to a reservation itself.

+ +

JOËL: That's really cool. We get to have a crossover between grammar terms and programming, and being able to connect those two is always a fun day for me.

+ +

STEPHANIE: Yeah, I actually find it quite difficult, I think, to come up with noun forms of verbs on my own. Like, I just don't really think about resources that way. I'm so used to thinking about them in a more tangible way, I suppose. And it's really kind of cool that, you know, in the English language, we have turned these abstract ideas, these actions into, like, an object form.

+ +

JOËL: And this is particularly useful when we're trying to design RESTful either APIs or even just resources for a Rails app that's server-rendered so that instead of trying to create all these, like, extra actions on our controller that are verbs, we might decide to instead create new resources in the system, new nouns that people can do the standard 7 to.

+ +

STEPHANIE: Yes. I like that better than introducing custom controller actions or routes that deviate from RESTful conventions because, you know, I probably have seen a slash confirm reservation [laughs] URL. And, you know, this is, I think, an interesting way of avoiding having too many of those deviating endpoints.

+ +

JOËL: Yeah, I found that while Rails does have support for those, just all the built-in things play much more nicely if you're restricting yourself to the classic seven. And I think, in general, it's easier to model and think about things in a Rails app when you have a lot of noun resources rather than one giant controller with a bunch of kind of verb actions that you can do to it. In the more formal jargon, I think we might refer to that as RESTful style versus RPC style, a Remote Procedure Call.

+ +

STEPHANIE: Could you tell me more about Remote Procedure Calls and what that means?

+ +

JOËL: The general idea is that it's almost like doing a method call on an object somewhere. And so, you would say, hey, I've got an account, and I want to call the confirm method on it because I know that maybe underlying this is an ActiveRecord account model. And the API or the web UI is just a really thin layer over those objects. And so, more or less, whatever your methods on your object are, can be accessed through the API. So the two kind of mirror each other.

+ +

STEPHANIE: Got it. That's interesting because I can see how someone might want to do that, especially if, you know, the account is the domain object they're using at the, you know, persistence layer, and maybe they're not quite able to see an abstraction for something else. And so, they kind of want to try to fit that into their API design.

+ +

JOËL: So I have a perhaps controversial opinion, which is that the resources in your Rails application, so your controllers, shouldn't map one-to-one with your database tables, your models.

+ +

STEPHANIE: So, are you saying that you are more likely to have more abstractions or various resources than what you might have at the database level?

+ +

JOËL: Well, you know what? Maybe more, but I would say, in general, different. And I think because both layers, the controller layer, and the model layer, are playing with very different sets of constraints. So when I'm designing database tables, I'm thinking in terms of normalization. And so, maybe I would take one big concept and split it up into smaller concepts, smaller tables because I need this data to be normalized so that there's no ambiguity when I'm making queries. So maybe something that's one resource at the controller layer might actually be multiple tables at the database layer.

+ +

But the inverse could also be true, right? You might have, in the example that John gave, you know, an account that has a single table in the database with just a Boolean field confirmed yes or no. And maybe there's just a generic account resource. But then, separately, there's also a confirmation resource. And so, now we've got more resources at the controller layer than at the database layer. So I think it can go either way, but they're just not tightly coupled to each other.

+ +

STEPHANIE: Yeah, that makes sense. I think another way that I've seen this manifest is when, like you said, like, maybe multiple database tables need to be updated by, you know, a request to this endpoint. And now we get into [chuckles] what some people may call services or that territory of basically something. And what's interesting is that a lot of the service classes are named as verbs, right? So order, creator. And, like, whatever order of operations that needs to happen on multiple database objects that happens as a result of a user placing an order. But the idea that those are frequently named as verbs was kind of interesting to me and a bit of a connection to our new gerund tip.

+ +

JOËL: That's really interesting. I had not made that connection before. Because I think my first instinct would be to avoid a service object there and instead use something closer to a form object that takes the same idea and represents it as a noun, potentially with the same name as the resource. So maybe leaning really heavily into that idea of the verbal noun, not just in describing the controller or the route but then also maybe the object backing it, even if it's not connecting directly to a database table.

+ +

STEPHANIE: Interesting. So, in this case, would the form object be mapped closer to your controller resource?

+ +

JOËL: Potentially, yes. So maybe I do have some kind of, like, object that represents a confirmation and makes it nicer to render the confirmation form on the edit page or the new page. In this case, you know, it's probably just one checkbox, so maybe it's not worth creating an object. But if there were multiple fields, then yes, maybe it's nice to create an in-memory object that has the same name as the resource. Similar maybe for a resource that represents multiple underlying database tables. It can be nice to have kind of one object that represents all of them, almost like a facade, I guess.

+ +

STEPHANIE: Yeah, that's really interesting. I like that idea of a facade, or it's, like, something at a higher level representing hopefully, like, some kind of meaning of all of these database objects together.

+ +

JOËL: I want to give a shout-out to talk from a former thoughtboter, Derek Prior—actually, former Bike Shed host—from RailsConf 2017 called In Relentless Pursuit of REST, where he digs into a lot of these concepts, particularly how to model resources in your Rails app that don't necessarily map one to one with a database table, and why that can be a good thing. Have you seen that talk?

+ +

STEPHANIE: I haven't, but I love the title of it. It's a great pun. It's very evocative, I think because I'm really curious about this idea of a relentless pursuit. Because I think another way to react to that could be to be done with REST entirely and maybe go with something like GraphQL.

+ +

JOËL: So instead of a relentless pursuit, it's a relentless...what's the opposite of pursuing? Fleeing?

+ +

STEPHANIE: Fleeing? [laughs] I like how we arrived there at the same time. Yes. So now I'm thinking of I had mentioned a little bit ago on the show we had our spicy takes Lightning Talks on our Boost Team. And a fellow thoughtboter, Chris White, he had given a talk about Why REST Is Not the Best and for --

+ +

JOËL: Also, a great title.

+ +

STEPHANIE: Yes, also, a great title.

+ +

JOËL: I love the rhyming there.

+ +

STEPHANIE: Yeah. And his reaction to the idea of trying to conform user interactions that don't quite map to a noun or an obvious resource was to potentially introduce GraphQL, where you have one endpoint that can service really anything that you can think of, I suppose. But, in his example, he was making the argument that human interactions are not database resources, right?

+ +

And maybe if you're not able to find that abstraction as a noun or object, with GraphQL, you can encapsulate those ideas as closer to actions, but in the GraphQL world, like, I think they're called mutations. But it is, I think, a whole world of, like, deciding what you want to be changed on the server side that is a little less constrained to having to come up with the right abstraction.

+ +

JOËL: I feel like GraphQL kind of takes that, like, complete opposite philosophy in that instead of saying, hey, let's have, like, this decoupling between the API layer and the database, GraphQL almost says, "No, let's lean into that." And yeah, you want to traverse the graph of, like, tables under the hood? Absolutely. You get to know the tables. You get to know how they're related to each other.

+ +

I guess, in theory, you could build a middle layer, and that's the graph that gets traversed rather than the graph of the tables. In practice, I think most people build it so that the API layer more or less has access directly to tables. Has that been your experience?

+ +

STEPHANIE: That's really interesting that you brought that up. I haven't worked with GraphQL in a while, but I was reading up on it before we started recording because I was kind of curious about how it might play with what we're talking about now. But the idea that it's graphed based, to me, was like, oh, like, that naturally, it could look very much like, you know, an entity graph of your relational database.

+ +

But the more I was reading about the GraphQL schema and different types, I realized that it could actually look quite different. And because it is a little bit closer to your UI layer, like, maybe you are building an abstraction that is more for serving that as that middle layer between your front end and your back end.

+ +

JOËL: That's really interesting that you mentioned that because I feel like the sort of traditional way that APIs are built is that they are built by the back-end team. And oftentimes, they will reflect the database schema. But you kind of mentioned with GraphQL here, sometimes it's the opposite that happens. Instead of being driven kind of from the back towards the front, it might be driven from the front towards the back where the UI team is building something that says, hey, we need these objects. We need these connections. Can you expose them to us? And then they get access to them.

+ +

What has been your experience when you've been working with front ends that are backed by a GraphQL API?

+ +

STEPHANIE: I think I've tended to see a GraphQL API when you do have a pretty rich client-side application with a lot of user interactions that then need to, you know, go and fetch some data. And you, like, really, you know, obviously don't want a page reload, right?

+ +

So it's really interesting, actually, that you pointed out that it's, like, perhaps the front end or the UI driving the API. Because, on one hand, the flexibility is really nice. And there's a lot more freedom even in maybe, like, what the product can do or how it would look. On the other hand, what I've kind of also seen is that eventually, maybe we do just want an API that we can talk to separate from, you know, any kind of UI. And, at that point, we have to go and build a separate thing [laughs] for the same data.

+ +

JOËL: So we've been talking about structuring APIs and, like, boundaries and things like that. I think my personal favorite feature of GraphQL is not the graph part but the fact that it comes with a built-in schema. And that plays really nicely with some typed technologies. Particularly, I've used Elm with some of the GraphQL libraries there, and that experience is just really nice. Where it will tell you if your front-end code is not compatible with the current API schema, and it will generate some things based off the schema.

+ +

So you have this really nice feedback cycle where somebody makes a change to the API, or you want to make a change to the code, and it will tell you immediately is your front end compatible with the current state of the back end? Which is a classic problem with developing front-end code.

+ +

STEPHANIE: First of all, I think it's very funny that you admitted to not preferring the graph part of GraphQL as a graph enthusiast yourself. [laughs] But I think I'm in agreement with you because, like, normally, I'm looking at it in its schema format. And that makes a lot of sense to me.

+ +

But what you said was really interesting because, in some ways, we're now kind of going back to the idea of maybe boundaries blurring because the types that you are creating for GraphQL are kind of then servicing both your front end and your back end. Do you think that's accurate?

+ +

JOËL: Ooh. That is an important distinction. I think you can. And I want to say that in some TypeScript implementations, you do use the types on both sides. In Elm, typically, you would not unless there's something really primitive, like a string or something like that.

+ +

STEPHANIE: Okay, how does that work?

+ +

JOËL: So you have some conversion layer that happens.

+ +

STEPHANIE: Got it.

+ +

JOËL: Honestly, I think that's my preference, and not just at the front end versus API layer but kind of all throughout. So the shape of an object in the database should not be the same shape as the object in the business logic that runs on the back end, which should not be the same shape as the object in transport, so JSON or whatever, which is also not the same shape as the object in your front-end code. Those might be similar, but each of these layers has different responsibilities, different things it's trying to optimize for.

+ +

Your code should be built, in my opinion, in a way that allows all four of those layers to diverge in their interpretation of not only what maybe common entities are, so maybe a user looks slightly different at each of these layers, but maybe even what the entities are to start with. And that maybe in the database what, we don't have a full user, we've got a profile and an account, and those get merged somehow. And eventually, when it gets to the front end, all we care about is the concept of a user because that's what we need in that context.

+ +

STEPHANIE: Yeah, that's really interesting because now it almost sounds like separate systems, which they kind of are, and then finding a way to make them work also as one bigger [laughs] system. I would love to ask, though, what that conversion looks like to you. Or, like, how have you implemented that? Or, like, what kind of pattern would you use for that?

+ +

JOËL: So I'm going to give a shout-out to the article that I always give a shout-out to: Parse, Don't Validate. In general, yeah, you do a transformation, and potentially it can fail. Let's say I'm pulling data from a GraphQL API into an Elm app. Elm has some built-in libraries for doing those transformations and will tell you at compile time if you're incorrectly transforming the data that comes from the shape that we expect from the schema.

+ +

But just because the schema comes in as, like, a flat object with certain fields or maybe it's a deeply nested chain of objects in GraphQL, it doesn't mean that it has to be that way in your Elm app. So that transformation step, you get to sort of make it whatever you want.

+ +

So my general approach is, at each layer, forget what other people are sending you and just design the entities that you would like to. I've heard the term wish-driven development, which I really like. So just, you know, if you could have, like, to make your life easy, what would the entities look like? And then kind of work backwards from there to make that sort of perfect world a reality for you and make it play nicely with other systems. And, to me, that's true at every layer of the application.

+ +

STEPHANIE: Interesting. So I'm also imagining that the transformation kind of has to happen both ways, right? Like, the server needs a way to transform data from the front end or some, you know, whatever, third party. But that's also true of the front end because what you're kind of saying is that these will be different. [laughs]

+ +

JOËL: Right. And, in many ways, it has to be because JSON is a very limited format. But some of the fancier things that you might have access to either on the back end or on the front end might be challenging to represent natively in JSON. And a classic one would be what Elm calls a custom type. You know, they're also called tagged unions, discriminated unions, algebraic data types. These things go by a bajillion names, and it's confusing.

+ +

But they're really kind of awkward and hard, almost impossible to represent in straight-up JSON because JSON is a very limited kind of transportation format. So you have to almost, like, have a rehydration step on one side and a kind of packing down step on the other when you're reading or writing from a JSON API.

+ +

STEPHANIE: Have you ever heard of or played that Wikipedia game Getting to Philosophy?

+ +

JOËL: I've done, I think, variations on it, the idea that you have a start and an end article, and then you have to either get through in the fewest amount of clicks, or it might be a timed thing, whoever can get to the target article first. Is that what you're referring to?

+ +

STEPHANIE: Yeah. So, in this case, I'm thinking, how many clicks through Wikipedia to get to the Wiki article about philosophy? And that's how I'm thinking about how we end up getting to [laughs] talking about types and parsing, and graphs even [laughs] on the show.

+ +

JOËL: It's all connected, almost as if it forms a graph of knowledge.

+ +

STEPHANIE: Learning that's another common topic on the show. [laughs] I think it's great. It's a lot of interesting lenses to view, like, the same things and just digging further and further deeper into them to always, like, come away with a little more perspective.

+ +

JOËL: So, in the vein of wish-driven development, if you're starting a brand-new front-end UI, what is your sort of dream approach for working with an API?

+ +

STEPHANIE: Wish-driven development is very visceral to me because I often think about when I'm working with legacy code and what my wishes and dreams were for the, you know, the stack or the technology or whatever. But, at that point, I don't really have the power to change it. You know, it's like I have what I have. And that's different from being in the driver's seat of a greenfield application where you're not just wishing. You're just deciding for yourself. You get to choose.

+ +

At the end of the day, though, I think, you know, you're likely starting from a simple application. And you haven't gotten to the point where you have, like, a lot of features that you have to figure out how to support and, like, complexity to manage. And, you know, you don't even know if you're going to get there. So I would probably start with REST.

+ +

JOËL: So we started this episode from a very back-end perspective where we're talking about Rails, and routes, and controllers. And we kind of ended it talking from a very front-end perspective. We also contrasted kind of a more RESTful approach, versus GraphQL, versus more kind of old-school RPC-style routing.

+ +

And now, I'm almost starting to wonder if there's some kind of correlation between whether someone primarily works from the back end and maybe likes, let's say, REST versus maybe somebody on the front end maybe preferring GraphQL. So I'd be happy for any of our listeners who have strong opinions preferring GraphQL, or REST, or something else; message us at hosts@bikeshed.fm and let us know. And, if you do, please let us know if you're primarily a front-end or a back-end developer because I think it would be really fun to see any connections there.

+ +

STEPHANIE: Absolutely. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+TyxnQCYl + + ]]> + + Joël Quenneville + Stephanie Minn + + + 392: Managing Changing Business Requirements + https://bikeshed.thoughtbot.com/392 + 1e221f2e-ff2a-48bd-9a07-b4d082aed90c + Tue, 11 Jul 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël has a fascinating discovery! He learned a new nuance around working with dependency graphs. Stephanie just finished playing a 100-hour video game on Nintendo Switch: a Japanese role-playing game called Octopath Traveler II. On the work front, she is struggling with a lot of churn in acceptance criteria and ideas about how features should work. + +* How do these get documented? +* What happens when they change? +* What happens when people lose this context over time? + 39:14 + no + + + Joël has a fascinating discovery! He learned a new nuance around working with dependency graphs. Stephanie just finished playing a 100-hour video game on Nintendo Switch: a Japanese role-playing game called Octopath Traveler II. On the work front, she is struggling with a lot of churn in acceptance criteria and ideas about how features should work. +How do these get documented? +What happens when they change? +What happens when people lose this context over time? +Strangler Fig Pattern (https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) +Octopath Traveler 2 (https://octopathtraveler2.square-enix-games.com/en-us/) +Empowering other departments (https://www.bikeshed.fm/388) +Transcript: +JOËL: You're the one who controls the pacing here. +STEPHANIE: Oh, I am. Okay, great. +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 long-time Bike Shed listeners will know that I'm a huge fan of dependency graphs for modeling all sorts of problems and particularly when trying to figure out how to work in an iterative fashion where you can do a bunch of small chunks of work that are independent, that can be shipped one at a time without having your software be in a breaking state in all of these intermediate steps. And I recently made a really exciting discovery, or I learned a new nuance around working with dependency graphs. +So the idea is that if you have a series of entities that have dependencies on each other, so maybe you're trying to build, let's say, some kind of object model or maybe a series of database tables that will reference each other, that kind of thing, if you draw a dependency graph where each bubble on your graph points to other bubbles that it depends on, that means that it can't be created without those other things already existing. Then, in order to create all of those entities for the first time, let's say they're database tables, you need to work your way from kind of the outside in. +You start with any bubbles on your graph that have no arrows going out from them. That means they have no dependencies. They can be safely built on their own, and then you kind of work your way backwards up the arrows. And that's how I've sort of thought about working with dependency graphs for a long time. +Recently, I've been doing some work that involves deleting entities in such a graph. So, again, let's say we're talking about database tables. What I came to realize is that deleting works in the opposite order. So, if you have a table that have other tables that depend on it, but it doesn't depend on anything, that's the first one you want to create. But it's also the last one you want to delete. So, when you're deleting, you want to start with the table that maybe has dependencies on other tables, but no other tables depend on it. It is going to be kind of like the root node of your dependency graph. +So I guess the short guideline here is when you're creating, work from the bottom up or work from the leaves inward, and when you're deleting, work from the top-down or work from the root outward or roots because a graph can have multiple roots; it's not a tree. +STEPHANIE: That is interesting. I'm wondering, did you have a mental model for managing deleting of dependencies prior? +JOËL: No. I've always worked with creating new things. And I went into this task thinking that deleting would be just like creating and then was like, wait a minute, that doesn't work. And then, you know, a few cycles later, realized, oh, wait, deleting is the opposite of creating when you're navigating the graph. And, all of a sudden, I feel like I've got a much clearer mental model or just another way of thinking about how to work with something like this. +STEPHANIE: Cool. That actually got me thinking about a case where you might have a circular dependency. Is that something you've considered yet? +JOËL: Yes. So, when you have a dependency graph, and you've got a circular dependency, that's a big problem because...so, in the creating model, there is no leaf node, if you will, because they both reference each other. So that means that each of these entities cannot be created on its own, the entire cycle. And maybe you've got only two, but maybe your cycle is, you know, ten entities big. The entire cycle is going to be shipped as one massive change. +So something that I often try to do is if I draw a dependency graph out and notice, wait a minute, I do have cyclical dependencies, the question then becomes, can I break that cycle to allow myself to work iteratively? Because otherwise, I know that there's a big chunk that can't be done iteratively. It just has to be done all at once. +STEPHANIE: Yeah, that's really interesting because I've certainly been in that situation where I don't realize until it's too late, where I've started going down the path thinking that, you know, I could just remove this one thing, or make this one change, and then find myself suddenly, you know, coming to the realization, oh, this other thing is now going to have to change. +And then, at that point, there's almost kind of like the sunken cost fallacy [laughs] a little bit where you're like, well, I'm already in it. So, why don't I keep going? But your strategy of trying to find a way to break that cyclica...that is two words combined. [laughs] I meant to say circular dependency [laughs] is the right way to avoid just having to do it all in one go. Have you had to break up a cycle like that before? +JOËL: Yes. I do it on a semi-frequent basis. The fancy term here for what I'm looking for when I'm building out a dependency graph is a directed acyclic graph. That's a graph theory or a computer science term that you'll hear thrown around a lot, DAG. I often like to...when building out a series of tasks that might also form a graph because you don't just model entities in your system; you might model a series of tasks as a graph. +If there's a cycle in the graph, typically, I can break that using something like the strangler fig pattern, which is a way to kind of have some intermediate steps that are non-breaking that then lead you to the refactor that you want. And I've used the strangler fig pattern for a long time, never realizing until later that, oh, what I'm actually doing is breaking cycles in my task dependency graph. +STEPHANIE: Hmm. I'm curious if you have noticed how these cycles come to be because I almost imagine that they get introduced over time, where you maybe did start with a parent and then you, you know, had dependencies. But then, over time, somehow, that circular dependency gets introduced. And I'm wondering if part of figuring out how to break that cycle is determining how things were introduced, like, over time. +JOËL: In my experience, this happens in a lot of different ways because I'm using dependency graphs like this to give myself a mental model for a lot of different kinds of things. So maybe I'm thinking in terms of database tables. And so those might get a circular dependency that gets added over time as the system grows. +But I'm also using it sometimes to model maybe a series of tasks. So I take a large task, and I break it down into subtasks that are all connected to each other. And that doesn't tend to sort of evolve over time in the same way that a series of database tables do. So I think it's very context-dependent. But there are definitely situations where it will be like you said, something that kind of evolves over time. +STEPHANIE: That makes sense. Well, I'm excited for you to get to deleting some potential code or database tables that are no longer in use. That sounds like a developer's dream [laughs] to clean up all that stuff. +JOËL: It's interesting because it's...a move operation is effectively what's happening. So I'm recreating tables in another system, pointing the ActiveRecord to this new system, and then deleting the existing ones in the local database. So, in a sense, I'm kind of traveling up this dependency graph from the leaf nodes into the root and then back down from the root to the leaves as I'm creating and then deleting everything or creating in one system, and then going back and deleting in the other system. +STEPHANIE: Got it. Okay, so not necessarily a net negative but, like you said, a move or just having to gradually replace to use a new system. +JOËL: That's right. And we're trying not to do this as, you know, okay, we're going to take the system down and move 50 tables from one system to another. But instead, saying, like, you know, one at a time, we're going to move these things over. And it's going to be small, incremental change over the course of a couple of weeks. And they're all pretty safe to deploy, and we feel good about them. +STEPHANIE: That's good. I'm glad you feel good. [laughs] We should all be able to feel good when we make changes like that. +JOËL: It's going to make my Fridays just so much more low-key just, like, yeah, hit that deploy button. It's okay. +So, Stephanie, what is new in your world? +STEPHANIE: So this is not work-related at all. But I just finished playing a 100-hour video game on my Nintendo Switch. [laughs] I finished a Japanese role-playing game called Octopath Traveler II. And I have never really played a game like this before. I've not, you know, put in many, many hours into something that then had an end, like, a completion. +So, at the end of this very long game that had a very, you know, compelling and engaging story and I was invested in all of these characters, and by the time the credits were rolling, I felt a little sad to be leaving this world that I have been in many evenings over the last couple of months. Yeah, I don't know, I'm feeling both a little sad because, you know like I said, I got really invested in this game, but now I'm also kind of glad to have some free time back in [laughs] my life because that has definitely been the primary, like, evening activity that I've been doing to relax. +JOËL: It sounds like this game had a very, like, a particularly immersive world that really pulled you in. +STEPHANIE: It did. It did. It has these eight, like, different characters that you follow, like, different chapters and all of their stories, and then they all kind of come together as well. And the world was huge in this game. There were so many little towns to explore. And I didn't realize I was a completionist type. But I found myself running around opening every chest, talking to every NPC, and making sure that I, you know, collected all of my items [chuckles] before moving on. +I also finished all of the side quests, which is, I think, you know, how I managed to put in over 100 hours into it. But yeah, it was very immersive, and I really enjoyed it. I don't know if this will become a norm for me. I know there are some people who are, you know, JRPG diehards and play a lot of these kinds of games, but they're a real, like, time investment for sure. +JOËL: Are there achievements for completing everything? +STEPHANIE: Not that I can tell on the Switch. I do know that, like, on other systems, you can see your progress on having done all of the things there are to do. But I think it's actually kind of better for me to just play [laughs] to just, like, think that I've done it all but not really, like, have something that tells me whether or not I've done it because then I would feel a lot more neurotic, I think, about being able to let it go where I am now. [laughs] +JOËL: Right. If we've got, like, an explicit checklist of things or a progress bar, then it feels like you got to get to all the things. +STEPHANIE: Yeah, exactly. I think there are still, you know, a couple more things that I wrote down on my little checklist of tasks that I would want to do once I feel like I want to come back to the game. But for now, like I said, I watched the credits roll. I teared up a little bit, you know, thinking about and reminiscing on my adventure with these characters, and I'm ready to put it down for a bit. +JOËL: Did I hear correctly that you made a checklist for this game of things you wanted to do? +STEPHANIE: Yes, [laughs] I did. +JOËL: That's amazing. I love that. +STEPHANIE: Yeah, you know, there are just so many things almost kind of like work where I had to, like, break down some of my goals. I wanted to, like, hit a certain level. I wanted to, you know, make sure I defeat these bosses that would help me get to those levels. And yeah, I got very into it. It was definitely a big part of my life for a couple of months. +I got it originally because I needed a game to play on my flight to Asia back when I went to Japan. And I'm like, oh, like, this looks, you know, fun and engaging, and it will distract me for my, you know, over 10-hour flight. Turns out it distracted me for many, many more hours over several months [laughs] since then. But I had a great time. So yeah, that's what's new for me. Again, it's something I'd never really done before. I will say though I am very behind on my reading goal as a result. [chuckles] +JOËL: I feel like this is a classic developer thing to do is, like, use the tools that we're used to in our job and then apply them to other parts of our life. And now it's just like, okay, well, I made a Kanban board to track my progress in this video game. You know, or, in my case, I'm definitely guilty of having drawn a dependency graph for the crafting tree for some video game. So I feel you really strongly there. +STEPHANIE: Yes, I'm nodding heavily in agreement. I think it just scratches the same kind of itch of, you know, achieving, like, little things and then achieving one big thing. +JOËL: So, speaking of places that are nice to have checklists and, like, well-defined requirements, you and I were talking earlier, and you have recently found some frustration around having user stories be defined well on your current project. +STEPHANIE: Yes. So I've been reflecting a little bit about my current project and noticing what I think I might call product smells; I'm not quite sure, just some things I'm seeing in our day-to-day workflow that is getting me thinking. And I'm curious to hear if you've experienced something similar. +But I find myself being tasked with a ticket that is quite vague. And maybe this was written by a product owner, or maybe it was written by another developer. And it is not quite actionable yet, so I have to go through the process of figuring out what I'm really needing to do here. +I think another thing that has been quite frustrating is, you know, maybe we do find out what we want to do. And, like, I'll go back into the ticket, write down the requirements that I gathered, and do the ticket. I'll ship whatever change was required, and then I'll hear back from someone in a meeting or either as a one-off request in Slack. And it'll be like, "Hey, like, actually, you know, we want this to be different." And maybe you previously said that "Oh, the value for something would be 30. But now we found out more information; it should be 20. And so could you, like, make that change?" +And then I'm not really sure what the best way to document a change like that is because it, you know, maybe existed in the previous ticket, but now it has changed. And do I create a new ticket for this, or do I just go ahead and make the code change? Like, who would know this information that we're now carrying about 20 being the value for, let's say, like, days or not meaning something in the code that we're writing? +And I guess I've just been really curious about how to make sure that this doesn't become the norm where a lot of these conversations are just happening, and, you know, the people who happen to be in them know that this change happened. But then later on, someone is asking questions about, like, hey, like, when did this change? Or I expected this to be 30. But is this, you know, behaving as expected? +So that was [laughs] a bit of a nebulous way of describing just, like, this churn that I feel with being the executor of work. But then, like, a lot of these things changing above me or separate from me and figuring out how to manage that. +JOËL: When you were describing this scenario where you've done the work, and then someone's like, "Oh, could we change this value from, like, 30 to 20?" I'm thinking in my mind of the sort of beam that a lot of our designers face where it's like, you know, they have a design. They work on it; they do it. And then show it to a client, and the client is like, "I love this design. But could we just shift this box over, like, one pixel?" +Like, they're, like, tiny, tiny, little changes that are kind of requested for change after you've done, like, this big thing. And, oftentimes, those pile-up. It's like, you shift it one pixel. It's like, oh, actually, you know what? Why don't we do it two pixels? And then it's like never-ending cycles, sometimes of, like, minute little changes. +STEPHANIE: Yeah. But the minute changes really add up into, I think, really different behavior than what you maybe had decided as a team originally. And in the process of changing and evolving, I don't really know where documentation fits in. +I've been working on this project that had a pretty comprehensive product design doc, where they had decided upfront on, you know, how the application is going to behave in many different scenarios. But again, like, that has changed over time. And when I recently had to onboard someone new to this project, you know, we sent over this document, and we're like, yeah, you can, you know, feel free to peruse it. But it's actually quite outdated. +And then, similarly, right now, since the features that I'm working on are going through QA, there's been a lot of back and forth about, I'm seeing this, but the doc said that Y is supposed to happen, and I'm not sure if that's a bug or not. And I or someone else has to respond with that context that we were holding in our head about when that change happened. +JOËL: That's really interesting. And I think it varies a lot based off the size of the organization. In a smaller organization, you're probably doing a lot of the requirements gathering yourself. You're talking to all the stakeholders. You're probably doing the QA yourself, or you're walking somebody else through QA. Versus a large organization, there might be an entirely separate product team, and a separate QA team, and a separate dev team. +And a danger that I've often seen is where all of these teams are just kind of tossing work over the fence. And all you're given is a, you know, a ticket of, like, execute on this. Basically, turn these specs into code. And then you do that, and then you toss it over the fence to the QA team. And they check does the code do these things? And there's so much context that can easily get lost from one step to another. That being said, I think a lot of devs find it frustrating to do some of the requirements gathering work. +How do you feel in general about scoping out a ticket or doing follow-up conversations with the product team about, like, "Hey, your idea for the ticket is this. How do you feel about doing these things? Or what if we cut these things?" Are those conversations that you enjoy having? Is that a fun part of the developer role for you? Or do you kind of wish that, like, somebody else did all of that so that you could, like, go heads down just writing code? +STEPHANIE: I think it depends. That's a great question. Actually, I have so many thoughts in response. So let me try to figure out where I want to go from here. +But I think I used to not like it. I used to be stressed out by it, and sometimes I still am. But when I thought my role was purely executing, to receive a ticket that is a bit vague, you know, I might have been left feeling, like, stuck, like, not knowing where to go from there. +But now that has changed a bit because I received some really helpful feedback from an old manager of mine who was kind of invested in my growth. And she really suggested learning to become more comfortable with ambiguity because that just becomes more and more your job, I think, as you progress in your career. And so now I at least know what information I need to go get and have, you know, strategies for doing so. +And also knowing that it's my job, like, knowing that no one else might be doing it, and it might just be me so that I can therefore get this ticket done. Because, like you said, that problem of throwing the work over the fence to someone else, at some point, that doesn't work because everyone has too much on their plates. And you have to just decide to be the one to seek the information that you need. +JOËL: I think one way that, as developers, we bring a lot of value is that we help to cut through a lot of that ambiguity. I think if we see our role as merely translating a requirements document into code, that's a very simplistic point of view of what a talented developer does. So, like you said, as we grow in our careers, we start dealing with less and less defined things. We often have to start defining the problems that we're given. +And we have to have these conversations with other teams to figure out what exactly we want to do. And maybe better understand why is it that we want to do this thing. What is the purpose of it? How are we going to get there? And my favorite: Do we have to do all of these things to hit the minimum value of this goal? Can I split this into multiple tickets? I love breaking down work. If I can make the ticket smaller, I'm all about that. +STEPHANIE: Yes. I'm well aware. It's interesting about what you said, though, is that, like, yes, that becomes, in some ways, our superpower. But, for me, where the pain comes in is when that's not part of the expectations, where I am maybe tasked with something that is not clear enough, and yet, the time that I need to find that clarity is not given the respect that it, I think, deserves to build a good product because the expectation is that I should already be making progress on this ticket and that it will be delivered soon. +You know, in that situation, I wish I had been in the room earlier. I wish I had been part of the process for developing the product strategy, or even just, like, have come in earlier to be able to ask, you know, why are we building this? And, like, what are some of the limitations on the technical side that we have? Because often, I find that it is a little too...not necessarily too late, but it is quite down the road that we then have to have these conversations, and it doesn't feel good. +JOËL: I think that's one of the powerful things that came out of the agile movement was the idea that you have these cross-functional teams, that you don't have a separate product team, a separate dev team, a separate QA team, a separate design team that are all these isolated islands. But instead, you say, okay, we have a cross-functional team that is working on this aspect of the product. And it will be some product people, some dev people, some designers kind of all working together and communicating with each other. I know, shocking concept. +And even depending on the context, a big idea is that the client or the customer is a part of that team. So, when we at thoughtbot work with a client, especially when they are maybe a smaller client like a startup founder, we make sure that they feel like they are a part of the team. They are involved in various meetings where we decide things. They have input. You know, they're part of that feedback cycle that we build. But that can also be the case for a larger company where your internal stakeholders are kind of built-in to be sort of part of your team. +STEPHANIE: I've seen so many different flavors of trying to do Agile [laughs] that it has lost a little bit of meaning for me these days. And maybe we've incorporated some aspects of it. But then that idea of the tight feedback loops and then a cross-functional team where everyone is communicating that part has gotten a little bit lost, at least on my project. And I imagine that this is common, and our listeners might be finding themselves in a similar situation where things are starting to feel a little more like handing off and a little more like waterfall. [laughs] +I'm curious, though, if you found yourself being requested to make a change from what the original decision was, how would you go about documenting that or not documenting it? Where do you think the best place for that information about how this feature now is supposed to work where should that live? +JOËL: Are you talking about where do we document that a decision was made to change the original requirements of a task? +STEPHANIE: Yes. +JOËL: In general, I think that should live on the ticket just because as long as the ticket is live, I think it's good to have all the context on that ticket for whoever's working on it to have access at a glance. +Sometimes it's worth it to say, you know what? We don't want to just keep this ticket live for weeks or maybe months on end. Let's ship this ticket, and create a follow-up to make a change later, especially if it's a change that's less important where it's like, you know what? It would be nice to have if...but, again, like, scope creep is a real danger. And so, again, me with the aggressive breaking up of tickets, I love to say, "That's a great idea. It would make a great change, not part of this ticket." So oftentimes, those changes I will push them into another ticket. +STEPHANIE: That's interesting. What about documentation beyond the current work? So I'm thinking about once, you know, a feature is delivered, how do people in the organization then know how this feature is supposed to work? Like moving forward as something that is customer-facing. +JOËL: That can vary a lot by organization, I think because there's a couple of different aspects to this. You have maybe some internal-facing documentation; maybe some customer support people need to know about the way the interface has changed. And then you also have customer-facing documentation where maybe you want some sort of, you know, you want a blog post talking about the new feature or some kind of release notes or something like that to be shared with your customers. And compiling that might look very different than what you do for your internal service reps. +STEPHANIE: Yeah, I like that. It's true that the customer documentation is really helpful. At least for, the product that I'm working on, it has very comprehensive documentation about how to use that for its customers. And that has been really helpful because, hopefully, that should be the truest [laughs] information out there. +But sometimes, you know, I find myself in meetings where none of us really know what happens. For example, a question that was asked recently is our product has a free trial capability. But it was unclear what happens to all of the data that the customer is getting access to as a feature. Like, what happens to that data after the free trial ends? Like, if they then have purchased a license, do they still have access to their free trial data? If, you know, there's a lapse between then, does it just get deleted, or will it show up again? And no one really knew the answer to that. +And I think that was another area that got my spidey senses tingling a little bit; I think because it reminded me of...there was a definition I read somewhere of legacy code that is basically when the person who has the most context about how a piece of code works and then they leave the company and that institutional knowledge no longer exists, like, that is legacy code. And I almost think that that also applies to product a little bit where a legacy product is something where no one quite knows what is supposed to happen, but it's still being used by users. +JOËL: That's a really fun definition there. I think there's sort of two related questions that are slightly different here, which is, one, how does the code behave? So, what happens when someone's trial period expires? And it's quite possible that no one on the team knows what actually happens when that time expires. +And then the second question is, what should happen when a trial expires? And it's possible, again, that the product team didn't think through any of the edge cases. They only went for the happy path. And so it's possible if that is also fully undefined and no one knows. +STEPHANIE: Yeah, I like that distinction you made a lot because they definitely go hand in hand, where someone realizes that some weird edge case happened, and then suddenly, they're asking those questions. And, you know, we realized, like, oh, like, that just didn't have enough, like, intention or thought behind how it was coded. So, like, it really is; who knows, right? Just whatever seems to happen. +And I think that this actually kind of reminds me of a previous episode we did about empowering other departments in the company because, ultimately, a lot of those questions about, like, how does this work? What happens? Ends up going to a developer who has to go and read the code and report back. And while, you know, we do have that power, it can also be a bit of a curse, I think. [laughs] +JOËL: I think this is an area where, as developers, we're maybe particularly skilled. Because of the work that we do, our brains are kind of wired to think about all of the edge cases, and sometimes they can be really annoying. +But I think there's a lot of value sometimes when maybe the product team comes to us with a maybe somewhat nebulously scoped ticket or a series of tickets for, let's say, a free trial period feature that only goes through the happy path. And then sometimes it's up to us to push back or to follow up and say, "Okay, great. We've got a bunch of tickets for a free trial period. Have you thought about what happens after a trial expires but the person hasn't converted to a paying customer?" And then, oftentimes, the answer is like, "Oh, no, we didn't think about that." +And I think oftentimes, as developers, our job is to kind of, like, seek out a lot of those edge cases. And we have a lot of techniques and methodologies that we use to try to find edge cases, things like test-driven development, various modeling tools that we'll try to use to make sure that we don't just crash or do something bad in our code. +But what should the actual behavior be? That's a conversation that we need to have. And hopefully, that's one that maybe the product team has already had on their own. But oftentimes, the benefit of having that cross-functional team is the ability to kind of have that back and forth and say, "Hey, what about this edge case? Have we thought about that? How do we want that to behave?" +STEPHANIE: Yeah, that actually made me think about the idea of tech debt but almost at a product level, where, hey, it turns out that we have all of these things that we didn't quite think through, and it's now causing problems. But how much do we invest in revisiting it? Because, you know, maybe this feature is several years old, and it was working just okay enough for it to, you know, be valuable. But we're now discovering these things and, you know, like, do we invest in them? Or are we more focused on, you know, coming up with new things and new features for our customers? +JOËL: That's a classic prioritization problem. It also kind of reminds me of the idea of an MVP. What are the actual, like, minimum set of features that you need in order to try out something or to ship something to customers? And, you know, maybe we don't need some special behavior if your trial account doesn't convert. Maybe we're okay [laughs] that you log in, and the app just crashes. Probably not, because we would probably want you to convert to a paying customer at some point. But maybe we're okay if you just get a screen that says, "You have no projects," when, in fact, you did have projects. It's just that you're no longer on the free trial. +Again, for business reasons, probably we want a call to action there that says, "You have five projects. They are not available to you. Please pay to unlock your projects again." That probably converts better. But, again, now that is a business decision. And that becomes a prioritization question that the team as a whole gets to address. +Sometimes it can also be some really fun prioritization things where if you're on a really tight schedule, you might ship some features live knowing that you have a time limit, but you don't have to necessarily ship other things. So let's say you've got a 30-day trial, and maybe you ship that before you've even implemented what the dashboard will look like after your free trial has expired, and that's fine because no one's going to hit that condition for 30 days. So now you've got 30 days to go out and handle that condition. +And maybe that's okay because it allowed you to get to market a little bit faster, allowed you to cut scope, break those tickets, yes, and just move that much faster. But it does require discipline because now you're on the clock. You've got 30 days to fix that edge case or potentially face some unhappy customers. +STEPHANIE: Yeah, I think that's quite a funny way to handle it. It's really ruthless prioritization [laughs] there. +But what you said was very interesting to me because I was thinking about how there is such a focus on new feature development and that being the thing that will attract customers or generate more money. But there is something to be said about investigating some of our old features of our existing system and finding opportunities there. And oftentimes, revisiting them will reduce the amount of pain [chuckles] that, you know, developers feel having to kind of keep track or have an eye on, like, where things are airing out, but then don't have the time to really invest in making it better or making that part of the product better. +JOËL: I think that's a great opportunity then to have a conversation with other parts of the team. Typically, I think you have to convert some of those into more of a business case. So the business people in the company or the product people might not care about the sort of raw metrics that you see as a developer. Oh, we got an exception with a stack trace in this part of our app. What does that even mean? +But if you say, hey, people who signed up for a free trial and then didn't immediately convert within 30 days who want to come back a month later and convert are unable to do so. And we've seen that that's about 10% of the people who signed up for a free trial. Well, now that's an interesting business question. +Are we losing out on potentially 10% of customer acquisition? I'll bet the sales and marketing people care a lot about that. I'll bet the business people care a lot about that. The product people probably care a lot about that. And now we can have a conversation about should we prioritize this thing? Are these metrics that we should improve? Is this a part of our code that's worth investing in? +STEPHANIE: Yeah, I like that because, in some ways, asking those questions about how does it work? Like, that is really an opportunity because then you can find out, and then you can make decisions about whether it's currently providing enough value as is or if there is something hiding under there to leverage. +JOËL: And I think that's one of the other places where, as developers, we provide value to clients is that we can sort of talk both languages. We can talk product language. We can talk business language. But we can also talk code. And so when we see things like that in code, sort of translate that into, like, what are the business impacts of this code change? Which then allows everyone to make the best possible decisions for the mission of the organization that you're a part of. +So we've talked about a variety of sort of patterns and anti-patterns that surround working through some of this churn on a product. I'm curious, Stephanie, for you, what's maybe one concrete thing that you've done recently that you've found has really helped you navigate this and maybe help reduce some of the stress that you feel as you navigate through this? +STEPHANIE: Yeah, I think, for me, one of the worst things is when that discussion is had in a meeting or a [inaudible 35:45] and then is not put anywhere. And so, one thing I've been making sure to do is either asking the person who made the request to write it down, either on the ticket or in Slack. Or I will write it down, you know, I will document the outcomes of what we talked about and putting it in a public space so that people are aware. +I think that small action has been helpful because we hold so much of this in our heads. And I've been finding that it ends up being hard for people to rotate onto different projects and, you know, get onboarded and up to speed effectively because there's so much knowledge and context transfer happening. But even just putting it in a place where maybe it's not relevant to everyone, but at least they see it. And then the next time that they're asked or maybe, like, do come around to working on this, they, like, have some fragment of a memory that they saw something about this. So that has been really helpful. +It actually dovetails really nicely into what we were talking about with opportunities, too, because once it's out there, like, maybe someone else will see it and have an idea about how it could be better or that change not being what they expected, and they can weigh in a little more. So that's what I'm trying to do. +And I think it's also nice to see how often that happens, right? If we're constantly seeing things changing because we have a written record of it, that could be helpful in bringing up and investigating further as to, like, why is this happening? Like, why do we experience this churn? And is that something we want to address? +JOËL: Yeah, because an element that we haven't talked at all about is any sort of feedback cycle or retrospective, where we can talk about these things and having that written trail and saying, "Oh, we changed this decision five times in the past week, like, really churned there." Now maybe that prioritizes it to be an important thing to talk about and to improve for the next cycle. +STEPHANIE: What I feel really strongly about is when, you know, each individual on a team is feeling this pain, but it not being known that it's actually a collective issue. Because maybe these things are happening in one-on-one conversations, and we don't realize that, like, oh, maybe there is something bigger here that we could improve on. And so the more eyes on it there are, the more visible it is, I think, that the easier it is to address. +JOËL: I love that, the power of writing things down. On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël has a fascinating discovery! He learned a new nuance around working with dependency graphs. Stephanie just finished playing a 100-hour video game on Nintendo Switch: a Japanese role-playing game called Octopath Traveler II. On the work front, she is struggling with a lot of churn in acceptance criteria and ideas about how features should work.

+ +
    +
  • How do these get documented?
    • +
  • What happens when they change?
    • +
  • What happens when people lose this context over time?
    • +
+ +
+ + + +

Transcript:

+ +

JOËL: You're the one who controls the pacing here.

+ +

STEPHANIE: Oh, I am. Okay, great.

+ +

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 long-time Bike Shed listeners will know that I'm a huge fan of dependency graphs for modeling all sorts of problems and particularly when trying to figure out how to work in an iterative fashion where you can do a bunch of small chunks of work that are independent, that can be shipped one at a time without having your software be in a breaking state in all of these intermediate steps. And I recently made a really exciting discovery, or I learned a new nuance around working with dependency graphs.

+ +

So the idea is that if you have a series of entities that have dependencies on each other, so maybe you're trying to build, let's say, some kind of object model or maybe a series of database tables that will reference each other, that kind of thing, if you draw a dependency graph where each bubble on your graph points to other bubbles that it depends on, that means that it can't be created without those other things already existing. Then, in order to create all of those entities for the first time, let's say they're database tables, you need to work your way from kind of the outside in.

+ +

You start with any bubbles on your graph that have no arrows going out from them. That means they have no dependencies. They can be safely built on their own, and then you kind of work your way backwards up the arrows. And that's how I've sort of thought about working with dependency graphs for a long time.

+ +

Recently, I've been doing some work that involves deleting entities in such a graph. So, again, let's say we're talking about database tables. What I came to realize is that deleting works in the opposite order. So, if you have a table that have other tables that depend on it, but it doesn't depend on anything, that's the first one you want to create. But it's also the last one you want to delete. So, when you're deleting, you want to start with the table that maybe has dependencies on other tables, but no other tables depend on it. It is going to be kind of like the root node of your dependency graph.

+ +

So I guess the short guideline here is when you're creating, work from the bottom up or work from the leaves inward, and when you're deleting, work from the top-down or work from the root outward or roots because a graph can have multiple roots; it's not a tree.

+ +

STEPHANIE: That is interesting. I'm wondering, did you have a mental model for managing deleting of dependencies prior?

+ +

JOËL: No. I've always worked with creating new things. And I went into this task thinking that deleting would be just like creating and then was like, wait a minute, that doesn't work. And then, you know, a few cycles later, realized, oh, wait, deleting is the opposite of creating when you're navigating the graph. And, all of a sudden, I feel like I've got a much clearer mental model or just another way of thinking about how to work with something like this.

+ +

STEPHANIE: Cool. That actually got me thinking about a case where you might have a circular dependency. Is that something you've considered yet?

+ +

JOËL: Yes. So, when you have a dependency graph, and you've got a circular dependency, that's a big problem because...so, in the creating model, there is no leaf node, if you will, because they both reference each other. So that means that each of these entities cannot be created on its own, the entire cycle. And maybe you've got only two, but maybe your cycle is, you know, ten entities big. The entire cycle is going to be shipped as one massive change.

+ +

So something that I often try to do is if I draw a dependency graph out and notice, wait a minute, I do have cyclical dependencies, the question then becomes, can I break that cycle to allow myself to work iteratively? Because otherwise, I know that there's a big chunk that can't be done iteratively. It just has to be done all at once.

+ +

STEPHANIE: Yeah, that's really interesting because I've certainly been in that situation where I don't realize until it's too late, where I've started going down the path thinking that, you know, I could just remove this one thing, or make this one change, and then find myself suddenly, you know, coming to the realization, oh, this other thing is now going to have to change.

+ +

And then, at that point, there's almost kind of like the sunken cost fallacy [laughs] a little bit where you're like, well, I'm already in it. So, why don't I keep going? But your strategy of trying to find a way to break that cyclica...that is two words combined. [laughs] I meant to say circular dependency [laughs] is the right way to avoid just having to do it all in one go. Have you had to break up a cycle like that before?

+ +

JOËL: Yes. I do it on a semi-frequent basis. The fancy term here for what I'm looking for when I'm building out a dependency graph is a directed acyclic graph. That's a graph theory or a computer science term that you'll hear thrown around a lot, DAG. I often like to...when building out a series of tasks that might also form a graph because you don't just model entities in your system; you might model a series of tasks as a graph.

+ +

If there's a cycle in the graph, typically, I can break that using something like the strangler fig pattern, which is a way to kind of have some intermediate steps that are non-breaking that then lead you to the refactor that you want. And I've used the strangler fig pattern for a long time, never realizing until later that, oh, what I'm actually doing is breaking cycles in my task dependency graph.

+ +

STEPHANIE: Hmm. I'm curious if you have noticed how these cycles come to be because I almost imagine that they get introduced over time, where you maybe did start with a parent and then you, you know, had dependencies. But then, over time, somehow, that circular dependency gets introduced. And I'm wondering if part of figuring out how to break that cycle is determining how things were introduced, like, over time.

+ +

JOËL: In my experience, this happens in a lot of different ways because I'm using dependency graphs like this to give myself a mental model for a lot of different kinds of things. So maybe I'm thinking in terms of database tables. And so those might get a circular dependency that gets added over time as the system grows.

+ +

But I'm also using it sometimes to model maybe a series of tasks. So I take a large task, and I break it down into subtasks that are all connected to each other. And that doesn't tend to sort of evolve over time in the same way that a series of database tables do. So I think it's very context-dependent. But there are definitely situations where it will be like you said, something that kind of evolves over time.

+ +

STEPHANIE: That makes sense. Well, I'm excited for you to get to deleting some potential code or database tables that are no longer in use. That sounds like a developer's dream [laughs] to clean up all that stuff.

+ +

JOËL: It's interesting because it's...a move operation is effectively what's happening. So I'm recreating tables in another system, pointing the ActiveRecord to this new system, and then deleting the existing ones in the local database. So, in a sense, I'm kind of traveling up this dependency graph from the leaf nodes into the root and then back down from the root to the leaves as I'm creating and then deleting everything or creating in one system, and then going back and deleting in the other system.

+ +

STEPHANIE: Got it. Okay, so not necessarily a net negative but, like you said, a move or just having to gradually replace to use a new system.

+ +

JOËL: That's right. And we're trying not to do this as, you know, okay, we're going to take the system down and move 50 tables from one system to another. But instead, saying, like, you know, one at a time, we're going to move these things over. And it's going to be small, incremental change over the course of a couple of weeks. And they're all pretty safe to deploy, and we feel good about them.

+ +

STEPHANIE: That's good. I'm glad you feel good. [laughs] We should all be able to feel good when we make changes like that.

+ +

JOËL: It's going to make my Fridays just so much more low-key just, like, yeah, hit that deploy button. It's okay.

+ +

So, Stephanie, what is new in your world?

+ +

STEPHANIE: So this is not work-related at all. But I just finished playing a 100-hour video game on my Nintendo Switch. [laughs] I finished a Japanese role-playing game called Octopath Traveler II. And I have never really played a game like this before. I've not, you know, put in many, many hours into something that then had an end, like, a completion.

+ +

So, at the end of this very long game that had a very, you know, compelling and engaging story and I was invested in all of these characters, and by the time the credits were rolling, I felt a little sad to be leaving this world that I have been in many evenings over the last couple of months. Yeah, I don't know, I'm feeling both a little sad because, you know like I said, I got really invested in this game, but now I'm also kind of glad to have some free time back in [laughs] my life because that has definitely been the primary, like, evening activity that I've been doing to relax.

+ +

JOËL: It sounds like this game had a very, like, a particularly immersive world that really pulled you in.

+ +

STEPHANIE: It did. It did. It has these eight, like, different characters that you follow, like, different chapters and all of their stories, and then they all kind of come together as well. And the world was huge in this game. There were so many little towns to explore. And I didn't realize I was a completionist type. But I found myself running around opening every chest, talking to every NPC, and making sure that I, you know, collected all of my items [chuckles] before moving on.

+ +

I also finished all of the side quests, which is, I think, you know, how I managed to put in over 100 hours into it. But yeah, it was very immersive, and I really enjoyed it. I don't know if this will become a norm for me. I know there are some people who are, you know, JRPG diehards and play a lot of these kinds of games, but they're a real, like, time investment for sure.

+ +

JOËL: Are there achievements for completing everything?

+ +

STEPHANIE: Not that I can tell on the Switch. I do know that, like, on other systems, you can see your progress on having done all of the things there are to do. But I think it's actually kind of better for me to just play [laughs] to just, like, think that I've done it all but not really, like, have something that tells me whether or not I've done it because then I would feel a lot more neurotic, I think, about being able to let it go where I am now. [laughs]

+ +

JOËL: Right. If we've got, like, an explicit checklist of things or a progress bar, then it feels like you got to get to all the things.

+ +

STEPHANIE: Yeah, exactly. I think there are still, you know, a couple more things that I wrote down on my little checklist of tasks that I would want to do once I feel like I want to come back to the game. But for now, like I said, I watched the credits roll. I teared up a little bit, you know, thinking about and reminiscing on my adventure with these characters, and I'm ready to put it down for a bit.

+ +

JOËL: Did I hear correctly that you made a checklist for this game of things you wanted to do?

+ +

STEPHANIE: Yes, [laughs] I did.

+ +

JOËL: That's amazing. I love that.

+ +

STEPHANIE: Yeah, you know, there are just so many things almost kind of like work where I had to, like, break down some of my goals. I wanted to, like, hit a certain level. I wanted to, you know, make sure I defeat these bosses that would help me get to those levels. And yeah, I got very into it. It was definitely a big part of my life for a couple of months.

+ +

I got it originally because I needed a game to play on my flight to Asia back when I went to Japan. And I'm like, oh, like, this looks, you know, fun and engaging, and it will distract me for my, you know, over 10-hour flight. Turns out it distracted me for many, many more hours over several months [laughs] since then. But I had a great time. So yeah, that's what's new for me. Again, it's something I'd never really done before. I will say though I am very behind on my reading goal as a result. [chuckles]

+ +

JOËL: I feel like this is a classic developer thing to do is, like, use the tools that we're used to in our job and then apply them to other parts of our life. And now it's just like, okay, well, I made a Kanban board to track my progress in this video game. You know, or, in my case, I'm definitely guilty of having drawn a dependency graph for the crafting tree for some video game. So I feel you really strongly there.

+ +

STEPHANIE: Yes, I'm nodding heavily in agreement. I think it just scratches the same kind of itch of, you know, achieving, like, little things and then achieving one big thing.

+ +

JOËL: So, speaking of places that are nice to have checklists and, like, well-defined requirements, you and I were talking earlier, and you have recently found some frustration around having user stories be defined well on your current project.

+ +

STEPHANIE: Yes. So I've been reflecting a little bit about my current project and noticing what I think I might call product smells; I'm not quite sure, just some things I'm seeing in our day-to-day workflow that is getting me thinking. And I'm curious to hear if you've experienced something similar.

+ +

But I find myself being tasked with a ticket that is quite vague. And maybe this was written by a product owner, or maybe it was written by another developer. And it is not quite actionable yet, so I have to go through the process of figuring out what I'm really needing to do here.

+ +

I think another thing that has been quite frustrating is, you know, maybe we do find out what we want to do. And, like, I'll go back into the ticket, write down the requirements that I gathered, and do the ticket. I'll ship whatever change was required, and then I'll hear back from someone in a meeting or either as a one-off request in Slack. And it'll be like, "Hey, like, actually, you know, we want this to be different." And maybe you previously said that "Oh, the value for something would be 30. But now we found out more information; it should be 20. And so could you, like, make that change?"

+ +

And then I'm not really sure what the best way to document a change like that is because it, you know, maybe existed in the previous ticket, but now it has changed. And do I create a new ticket for this, or do I just go ahead and make the code change? Like, who would know this information that we're now carrying about 20 being the value for, let's say, like, days or not meaning something in the code that we're writing?

+ +

And I guess I've just been really curious about how to make sure that this doesn't become the norm where a lot of these conversations are just happening, and, you know, the people who happen to be in them know that this change happened. But then later on, someone is asking questions about, like, hey, like, when did this change? Or I expected this to be 30. But is this, you know, behaving as expected?

+ +

So that was [laughs] a bit of a nebulous way of describing just, like, this churn that I feel with being the executor of work. But then, like, a lot of these things changing above me or separate from me and figuring out how to manage that.

+ +

JOËL: When you were describing this scenario where you've done the work, and then someone's like, "Oh, could we change this value from, like, 30 to 20?" I'm thinking in my mind of the sort of beam that a lot of our designers face where it's like, you know, they have a design. They work on it; they do it. And then show it to a client, and the client is like, "I love this design. But could we just shift this box over, like, one pixel?"

+ +

Like, they're, like, tiny, tiny, little changes that are kind of requested for change after you've done, like, this big thing. And, oftentimes, those pile-up. It's like, you shift it one pixel. It's like, oh, actually, you know what? Why don't we do it two pixels? And then it's like never-ending cycles, sometimes of, like, minute little changes.

+ +

STEPHANIE: Yeah. But the minute changes really add up into, I think, really different behavior than what you maybe had decided as a team originally. And in the process of changing and evolving, I don't really know where documentation fits in.

+ +

I've been working on this project that had a pretty comprehensive product design doc, where they had decided upfront on, you know, how the application is going to behave in many different scenarios. But again, like, that has changed over time. And when I recently had to onboard someone new to this project, you know, we sent over this document, and we're like, yeah, you can, you know, feel free to peruse it. But it's actually quite outdated.

+ +

And then, similarly, right now, since the features that I'm working on are going through QA, there's been a lot of back and forth about, I'm seeing this, but the doc said that Y is supposed to happen, and I'm not sure if that's a bug or not. And I or someone else has to respond with that context that we were holding in our head about when that change happened.

+ +

JOËL: That's really interesting. And I think it varies a lot based off the size of the organization. In a smaller organization, you're probably doing a lot of the requirements gathering yourself. You're talking to all the stakeholders. You're probably doing the QA yourself, or you're walking somebody else through QA. Versus a large organization, there might be an entirely separate product team, and a separate QA team, and a separate dev team.

+ +

And a danger that I've often seen is where all of these teams are just kind of tossing work over the fence. And all you're given is a, you know, a ticket of, like, execute on this. Basically, turn these specs into code. And then you do that, and then you toss it over the fence to the QA team. And they check does the code do these things? And there's so much context that can easily get lost from one step to another. That being said, I think a lot of devs find it frustrating to do some of the requirements gathering work.

+ +

How do you feel in general about scoping out a ticket or doing follow-up conversations with the product team about, like, "Hey, your idea for the ticket is this. How do you feel about doing these things? Or what if we cut these things?" Are those conversations that you enjoy having? Is that a fun part of the developer role for you? Or do you kind of wish that, like, somebody else did all of that so that you could, like, go heads down just writing code?

+ +

STEPHANIE: I think it depends. That's a great question. Actually, I have so many thoughts in response. So let me try to figure out where I want to go from here.

+ +

But I think I used to not like it. I used to be stressed out by it, and sometimes I still am. But when I thought my role was purely executing, to receive a ticket that is a bit vague, you know, I might have been left feeling, like, stuck, like, not knowing where to go from there.

+ +

But now that has changed a bit because I received some really helpful feedback from an old manager of mine who was kind of invested in my growth. And she really suggested learning to become more comfortable with ambiguity because that just becomes more and more your job, I think, as you progress in your career. And so now I at least know what information I need to go get and have, you know, strategies for doing so.

+ +

And also knowing that it's my job, like, knowing that no one else might be doing it, and it might just be me so that I can therefore get this ticket done. Because, like you said, that problem of throwing the work over the fence to someone else, at some point, that doesn't work because everyone has too much on their plates. And you have to just decide to be the one to seek the information that you need.

+ +

JOËL: I think one way that, as developers, we bring a lot of value is that we help to cut through a lot of that ambiguity. I think if we see our role as merely translating a requirements document into code, that's a very simplistic point of view of what a talented developer does. So, like you said, as we grow in our careers, we start dealing with less and less defined things. We often have to start defining the problems that we're given.

+ +

And we have to have these conversations with other teams to figure out what exactly we want to do. And maybe better understand why is it that we want to do this thing. What is the purpose of it? How are we going to get there? And my favorite: Do we have to do all of these things to hit the minimum value of this goal? Can I split this into multiple tickets? I love breaking down work. If I can make the ticket smaller, I'm all about that.

+ +

STEPHANIE: Yes. I'm well aware. It's interesting about what you said, though, is that, like, yes, that becomes, in some ways, our superpower. But, for me, where the pain comes in is when that's not part of the expectations, where I am maybe tasked with something that is not clear enough, and yet, the time that I need to find that clarity is not given the respect that it, I think, deserves to build a good product because the expectation is that I should already be making progress on this ticket and that it will be delivered soon.

+ +

You know, in that situation, I wish I had been in the room earlier. I wish I had been part of the process for developing the product strategy, or even just, like, have come in earlier to be able to ask, you know, why are we building this? And, like, what are some of the limitations on the technical side that we have? Because often, I find that it is a little too...not necessarily too late, but it is quite down the road that we then have to have these conversations, and it doesn't feel good.

+ +

JOËL: I think that's one of the powerful things that came out of the agile movement was the idea that you have these cross-functional teams, that you don't have a separate product team, a separate dev team, a separate QA team, a separate design team that are all these isolated islands. But instead, you say, okay, we have a cross-functional team that is working on this aspect of the product. And it will be some product people, some dev people, some designers kind of all working together and communicating with each other. I know, shocking concept.

+ +

And even depending on the context, a big idea is that the client or the customer is a part of that team. So, when we at thoughtbot work with a client, especially when they are maybe a smaller client like a startup founder, we make sure that they feel like they are a part of the team. They are involved in various meetings where we decide things. They have input. You know, they're part of that feedback cycle that we build. But that can also be the case for a larger company where your internal stakeholders are kind of built-in to be sort of part of your team.

+ +

STEPHANIE: I've seen so many different flavors of trying to do Agile [laughs] that it has lost a little bit of meaning for me these days. And maybe we've incorporated some aspects of it. But then that idea of the tight feedback loops and then a cross-functional team where everyone is communicating that part has gotten a little bit lost, at least on my project. And I imagine that this is common, and our listeners might be finding themselves in a similar situation where things are starting to feel a little more like handing off and a little more like waterfall. [laughs]

+ +

I'm curious, though, if you found yourself being requested to make a change from what the original decision was, how would you go about documenting that or not documenting it? Where do you think the best place for that information about how this feature now is supposed to work where should that live?

+ +

JOËL: Are you talking about where do we document that a decision was made to change the original requirements of a task?

+ +

STEPHANIE: Yes.

+ +

JOËL: In general, I think that should live on the ticket just because as long as the ticket is live, I think it's good to have all the context on that ticket for whoever's working on it to have access at a glance.

+ +

Sometimes it's worth it to say, you know what? We don't want to just keep this ticket live for weeks or maybe months on end. Let's ship this ticket, and create a follow-up to make a change later, especially if it's a change that's less important where it's like, you know what? It would be nice to have if...but, again, like, scope creep is a real danger. And so, again, me with the aggressive breaking up of tickets, I love to say, "That's a great idea. It would make a great change, not part of this ticket." So oftentimes, those changes I will push them into another ticket.

+ +

STEPHANIE: That's interesting. What about documentation beyond the current work? So I'm thinking about once, you know, a feature is delivered, how do people in the organization then know how this feature is supposed to work? Like moving forward as something that is customer-facing.

+ +

JOËL: That can vary a lot by organization, I think because there's a couple of different aspects to this. You have maybe some internal-facing documentation; maybe some customer support people need to know about the way the interface has changed. And then you also have customer-facing documentation where maybe you want some sort of, you know, you want a blog post talking about the new feature or some kind of release notes or something like that to be shared with your customers. And compiling that might look very different than what you do for your internal service reps.

+ +

STEPHANIE: Yeah, I like that. It's true that the customer documentation is really helpful. At least for, the product that I'm working on, it has very comprehensive documentation about how to use that for its customers. And that has been really helpful because, hopefully, that should be the truest [laughs] information out there.

+ +

But sometimes, you know, I find myself in meetings where none of us really know what happens. For example, a question that was asked recently is our product has a free trial capability. But it was unclear what happens to all of the data that the customer is getting access to as a feature. Like, what happens to that data after the free trial ends? Like, if they then have purchased a license, do they still have access to their free trial data? If, you know, there's a lapse between then, does it just get deleted, or will it show up again? And no one really knew the answer to that.

+ +

And I think that was another area that got my spidey senses tingling a little bit; I think because it reminded me of...there was a definition I read somewhere of legacy code that is basically when the person who has the most context about how a piece of code works and then they leave the company and that institutional knowledge no longer exists, like, that is legacy code. And I almost think that that also applies to product a little bit where a legacy product is something where no one quite knows what is supposed to happen, but it's still being used by users.

+ +

JOËL: That's a really fun definition there. I think there's sort of two related questions that are slightly different here, which is, one, how does the code behave? So, what happens when someone's trial period expires? And it's quite possible that no one on the team knows what actually happens when that time expires.

+ +

And then the second question is, what should happen when a trial expires? And it's possible, again, that the product team didn't think through any of the edge cases. They only went for the happy path. And so it's possible if that is also fully undefined and no one knows.

+ +

STEPHANIE: Yeah, I like that distinction you made a lot because they definitely go hand in hand, where someone realizes that some weird edge case happened, and then suddenly, they're asking those questions. And, you know, we realized, like, oh, like, that just didn't have enough, like, intention or thought behind how it was coded. So, like, it really is; who knows, right? Just whatever seems to happen.

+ +

And I think that this actually kind of reminds me of a previous episode we did about empowering other departments in the company because, ultimately, a lot of those questions about, like, how does this work? What happens? Ends up going to a developer who has to go and read the code and report back. And while, you know, we do have that power, it can also be a bit of a curse, I think. [laughs]

+ +

JOËL: I think this is an area where, as developers, we're maybe particularly skilled. Because of the work that we do, our brains are kind of wired to think about all of the edge cases, and sometimes they can be really annoying.

+ +

But I think there's a lot of value sometimes when maybe the product team comes to us with a maybe somewhat nebulously scoped ticket or a series of tickets for, let's say, a free trial period feature that only goes through the happy path. And then sometimes it's up to us to push back or to follow up and say, "Okay, great. We've got a bunch of tickets for a free trial period. Have you thought about what happens after a trial expires but the person hasn't converted to a paying customer?" And then, oftentimes, the answer is like, "Oh, no, we didn't think about that."

+ +

And I think oftentimes, as developers, our job is to kind of, like, seek out a lot of those edge cases. And we have a lot of techniques and methodologies that we use to try to find edge cases, things like test-driven development, various modeling tools that we'll try to use to make sure that we don't just crash or do something bad in our code.

+ +

But what should the actual behavior be? That's a conversation that we need to have. And hopefully, that's one that maybe the product team has already had on their own. But oftentimes, the benefit of having that cross-functional team is the ability to kind of have that back and forth and say, "Hey, what about this edge case? Have we thought about that? How do we want that to behave?"

+ +

STEPHANIE: Yeah, that actually made me think about the idea of tech debt but almost at a product level, where, hey, it turns out that we have all of these things that we didn't quite think through, and it's now causing problems. But how much do we invest in revisiting it? Because, you know, maybe this feature is several years old, and it was working just okay enough for it to, you know, be valuable. But we're now discovering these things and, you know, like, do we invest in them? Or are we more focused on, you know, coming up with new things and new features for our customers?

+ +

JOËL: That's a classic prioritization problem. It also kind of reminds me of the idea of an MVP. What are the actual, like, minimum set of features that you need in order to try out something or to ship something to customers? And, you know, maybe we don't need some special behavior if your trial account doesn't convert. Maybe we're okay [laughs] that you log in, and the app just crashes. Probably not, because we would probably want you to convert to a paying customer at some point. But maybe we're okay if you just get a screen that says, "You have no projects," when, in fact, you did have projects. It's just that you're no longer on the free trial.

+ +

Again, for business reasons, probably we want a call to action there that says, "You have five projects. They are not available to you. Please pay to unlock your projects again." That probably converts better. But, again, now that is a business decision. And that becomes a prioritization question that the team as a whole gets to address.

+ +

Sometimes it can also be some really fun prioritization things where if you're on a really tight schedule, you might ship some features live knowing that you have a time limit, but you don't have to necessarily ship other things. So let's say you've got a 30-day trial, and maybe you ship that before you've even implemented what the dashboard will look like after your free trial has expired, and that's fine because no one's going to hit that condition for 30 days. So now you've got 30 days to go out and handle that condition.

+ +

And maybe that's okay because it allowed you to get to market a little bit faster, allowed you to cut scope, break those tickets, yes, and just move that much faster. But it does require discipline because now you're on the clock. You've got 30 days to fix that edge case or potentially face some unhappy customers.

+ +

STEPHANIE: Yeah, I think that's quite a funny way to handle it. It's really ruthless prioritization [laughs] there.

+ +

But what you said was very interesting to me because I was thinking about how there is such a focus on new feature development and that being the thing that will attract customers or generate more money. But there is something to be said about investigating some of our old features of our existing system and finding opportunities there. And oftentimes, revisiting them will reduce the amount of pain [chuckles] that, you know, developers feel having to kind of keep track or have an eye on, like, where things are airing out, but then don't have the time to really invest in making it better or making that part of the product better.

+ +

JOËL: I think that's a great opportunity then to have a conversation with other parts of the team. Typically, I think you have to convert some of those into more of a business case. So the business people in the company or the product people might not care about the sort of raw metrics that you see as a developer. Oh, we got an exception with a stack trace in this part of our app. What does that even mean?

+ +

But if you say, hey, people who signed up for a free trial and then didn't immediately convert within 30 days who want to come back a month later and convert are unable to do so. And we've seen that that's about 10% of the people who signed up for a free trial. Well, now that's an interesting business question.

+ +

Are we losing out on potentially 10% of customer acquisition? I'll bet the sales and marketing people care a lot about that. I'll bet the business people care a lot about that. The product people probably care a lot about that. And now we can have a conversation about should we prioritize this thing? Are these metrics that we should improve? Is this a part of our code that's worth investing in?

+ +

STEPHANIE: Yeah, I like that because, in some ways, asking those questions about how does it work? Like, that is really an opportunity because then you can find out, and then you can make decisions about whether it's currently providing enough value as is or if there is something hiding under there to leverage.

+ +

JOËL: And I think that's one of the other places where, as developers, we provide value to clients is that we can sort of talk both languages. We can talk product language. We can talk business language. But we can also talk code. And so when we see things like that in code, sort of translate that into, like, what are the business impacts of this code change? Which then allows everyone to make the best possible decisions for the mission of the organization that you're a part of.

+ +

So we've talked about a variety of sort of patterns and anti-patterns that surround working through some of this churn on a product. I'm curious, Stephanie, for you, what's maybe one concrete thing that you've done recently that you've found has really helped you navigate this and maybe help reduce some of the stress that you feel as you navigate through this?

+ +

STEPHANIE: Yeah, I think, for me, one of the worst things is when that discussion is had in a meeting or a [inaudible 35:45] and then is not put anywhere. And so, one thing I've been making sure to do is either asking the person who made the request to write it down, either on the ticket or in Slack. Or I will write it down, you know, I will document the outcomes of what we talked about and putting it in a public space so that people are aware.

+ +

I think that small action has been helpful because we hold so much of this in our heads. And I've been finding that it ends up being hard for people to rotate onto different projects and, you know, get onboarded and up to speed effectively because there's so much knowledge and context transfer happening. But even just putting it in a place where maybe it's not relevant to everyone, but at least they see it. And then the next time that they're asked or maybe, like, do come around to working on this, they, like, have some fragment of a memory that they saw something about this. So that has been really helpful.

+ +

It actually dovetails really nicely into what we were talking about with opportunities, too, because once it's out there, like, maybe someone else will see it and have an idea about how it could be better or that change not being what they expected, and they can weigh in a little more. So that's what I'm trying to do.

+ +

And I think it's also nice to see how often that happens, right? If we're constantly seeing things changing because we have a written record of it, that could be helpful in bringing up and investigating further as to, like, why is this happening? Like, why do we experience this churn? And is that something we want to address?

+ +

JOËL: Yeah, because an element that we haven't talked at all about is any sort of feedback cycle or retrospective, where we can talk about these things and having that written trail and saying, "Oh, we changed this decision five times in the past week, like, really churned there." Now maybe that prioritizes it to be an important thing to talk about and to improve for the next cycle.

+ +

STEPHANIE: What I feel really strongly about is when, you know, each individual on a team is feeling this pain, but it not being known that it's actually a collective issue. Because maybe these things are happening in one-on-one conversations, and we don't realize that, like, oh, maybe there is something bigger here that we could improve on. And so the more eyes on it there are, the more visible it is, I think, that the easier it is to address.

+ +

JOËL: I love that, the power of writing things down. On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Joël has a fascinating discovery! He learned a new nuance around working with dependency graphs. Stephanie just finished playing a 100-hour video game on Nintendo Switch: a Japanese role-playing game called Octopath Traveler II. On the work front, she is struggling with a lot of churn in acceptance criteria and ideas about how features should work.

+ +
    +
  • How do these get documented?
    • +
  • What happens when they change?
    • +
  • What happens when people lose this context over time?
    • +
+ +
+ + + +

Transcript:

+ +

JOËL: You're the one who controls the pacing here.

+ +

STEPHANIE: Oh, I am. Okay, great.

+ +

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 long-time Bike Shed listeners will know that I'm a huge fan of dependency graphs for modeling all sorts of problems and particularly when trying to figure out how to work in an iterative fashion where you can do a bunch of small chunks of work that are independent, that can be shipped one at a time without having your software be in a breaking state in all of these intermediate steps. And I recently made a really exciting discovery, or I learned a new nuance around working with dependency graphs.

+ +

So the idea is that if you have a series of entities that have dependencies on each other, so maybe you're trying to build, let's say, some kind of object model or maybe a series of database tables that will reference each other, that kind of thing, if you draw a dependency graph where each bubble on your graph points to other bubbles that it depends on, that means that it can't be created without those other things already existing. Then, in order to create all of those entities for the first time, let's say they're database tables, you need to work your way from kind of the outside in.

+ +

You start with any bubbles on your graph that have no arrows going out from them. That means they have no dependencies. They can be safely built on their own, and then you kind of work your way backwards up the arrows. And that's how I've sort of thought about working with dependency graphs for a long time.

+ +

Recently, I've been doing some work that involves deleting entities in such a graph. So, again, let's say we're talking about database tables. What I came to realize is that deleting works in the opposite order. So, if you have a table that have other tables that depend on it, but it doesn't depend on anything, that's the first one you want to create. But it's also the last one you want to delete. So, when you're deleting, you want to start with the table that maybe has dependencies on other tables, but no other tables depend on it. It is going to be kind of like the root node of your dependency graph.

+ +

So I guess the short guideline here is when you're creating, work from the bottom up or work from the leaves inward, and when you're deleting, work from the top-down or work from the root outward or roots because a graph can have multiple roots; it's not a tree.

+ +

STEPHANIE: That is interesting. I'm wondering, did you have a mental model for managing deleting of dependencies prior?

+ +

JOËL: No. I've always worked with creating new things. And I went into this task thinking that deleting would be just like creating and then was like, wait a minute, that doesn't work. And then, you know, a few cycles later, realized, oh, wait, deleting is the opposite of creating when you're navigating the graph. And, all of a sudden, I feel like I've got a much clearer mental model or just another way of thinking about how to work with something like this.

+ +

STEPHANIE: Cool. That actually got me thinking about a case where you might have a circular dependency. Is that something you've considered yet?

+ +

JOËL: Yes. So, when you have a dependency graph, and you've got a circular dependency, that's a big problem because...so, in the creating model, there is no leaf node, if you will, because they both reference each other. So that means that each of these entities cannot be created on its own, the entire cycle. And maybe you've got only two, but maybe your cycle is, you know, ten entities big. The entire cycle is going to be shipped as one massive change.

+ +

So something that I often try to do is if I draw a dependency graph out and notice, wait a minute, I do have cyclical dependencies, the question then becomes, can I break that cycle to allow myself to work iteratively? Because otherwise, I know that there's a big chunk that can't be done iteratively. It just has to be done all at once.

+ +

STEPHANIE: Yeah, that's really interesting because I've certainly been in that situation where I don't realize until it's too late, where I've started going down the path thinking that, you know, I could just remove this one thing, or make this one change, and then find myself suddenly, you know, coming to the realization, oh, this other thing is now going to have to change.

+ +

And then, at that point, there's almost kind of like the sunken cost fallacy [laughs] a little bit where you're like, well, I'm already in it. So, why don't I keep going? But your strategy of trying to find a way to break that cyclica...that is two words combined. [laughs] I meant to say circular dependency [laughs] is the right way to avoid just having to do it all in one go. Have you had to break up a cycle like that before?

+ +

JOËL: Yes. I do it on a semi-frequent basis. The fancy term here for what I'm looking for when I'm building out a dependency graph is a directed acyclic graph. That's a graph theory or a computer science term that you'll hear thrown around a lot, DAG. I often like to...when building out a series of tasks that might also form a graph because you don't just model entities in your system; you might model a series of tasks as a graph.

+ +

If there's a cycle in the graph, typically, I can break that using something like the strangler fig pattern, which is a way to kind of have some intermediate steps that are non-breaking that then lead you to the refactor that you want. And I've used the strangler fig pattern for a long time, never realizing until later that, oh, what I'm actually doing is breaking cycles in my task dependency graph.

+ +

STEPHANIE: Hmm. I'm curious if you have noticed how these cycles come to be because I almost imagine that they get introduced over time, where you maybe did start with a parent and then you, you know, had dependencies. But then, over time, somehow, that circular dependency gets introduced. And I'm wondering if part of figuring out how to break that cycle is determining how things were introduced, like, over time.

+ +

JOËL: In my experience, this happens in a lot of different ways because I'm using dependency graphs like this to give myself a mental model for a lot of different kinds of things. So maybe I'm thinking in terms of database tables. And so those might get a circular dependency that gets added over time as the system grows.

+ +

But I'm also using it sometimes to model maybe a series of tasks. So I take a large task, and I break it down into subtasks that are all connected to each other. And that doesn't tend to sort of evolve over time in the same way that a series of database tables do. So I think it's very context-dependent. But there are definitely situations where it will be like you said, something that kind of evolves over time.

+ +

STEPHANIE: That makes sense. Well, I'm excited for you to get to deleting some potential code or database tables that are no longer in use. That sounds like a developer's dream [laughs] to clean up all that stuff.

+ +

JOËL: It's interesting because it's...a move operation is effectively what's happening. So I'm recreating tables in another system, pointing the ActiveRecord to this new system, and then deleting the existing ones in the local database. So, in a sense, I'm kind of traveling up this dependency graph from the leaf nodes into the root and then back down from the root to the leaves as I'm creating and then deleting everything or creating in one system, and then going back and deleting in the other system.

+ +

STEPHANIE: Got it. Okay, so not necessarily a net negative but, like you said, a move or just having to gradually replace to use a new system.

+ +

JOËL: That's right. And we're trying not to do this as, you know, okay, we're going to take the system down and move 50 tables from one system to another. But instead, saying, like, you know, one at a time, we're going to move these things over. And it's going to be small, incremental change over the course of a couple of weeks. And they're all pretty safe to deploy, and we feel good about them.

+ +

STEPHANIE: That's good. I'm glad you feel good. [laughs] We should all be able to feel good when we make changes like that.

+ +

JOËL: It's going to make my Fridays just so much more low-key just, like, yeah, hit that deploy button. It's okay.

+ +

So, Stephanie, what is new in your world?

+ +

STEPHANIE: So this is not work-related at all. But I just finished playing a 100-hour video game on my Nintendo Switch. [laughs] I finished a Japanese role-playing game called Octopath Traveler II. And I have never really played a game like this before. I've not, you know, put in many, many hours into something that then had an end, like, a completion.

+ +

So, at the end of this very long game that had a very, you know, compelling and engaging story and I was invested in all of these characters, and by the time the credits were rolling, I felt a little sad to be leaving this world that I have been in many evenings over the last couple of months. Yeah, I don't know, I'm feeling both a little sad because, you know like I said, I got really invested in this game, but now I'm also kind of glad to have some free time back in [laughs] my life because that has definitely been the primary, like, evening activity that I've been doing to relax.

+ +

JOËL: It sounds like this game had a very, like, a particularly immersive world that really pulled you in.

+ +

STEPHANIE: It did. It did. It has these eight, like, different characters that you follow, like, different chapters and all of their stories, and then they all kind of come together as well. And the world was huge in this game. There were so many little towns to explore. And I didn't realize I was a completionist type. But I found myself running around opening every chest, talking to every NPC, and making sure that I, you know, collected all of my items [chuckles] before moving on.

+ +

I also finished all of the side quests, which is, I think, you know, how I managed to put in over 100 hours into it. But yeah, it was very immersive, and I really enjoyed it. I don't know if this will become a norm for me. I know there are some people who are, you know, JRPG diehards and play a lot of these kinds of games, but they're a real, like, time investment for sure.

+ +

JOËL: Are there achievements for completing everything?

+ +

STEPHANIE: Not that I can tell on the Switch. I do know that, like, on other systems, you can see your progress on having done all of the things there are to do. But I think it's actually kind of better for me to just play [laughs] to just, like, think that I've done it all but not really, like, have something that tells me whether or not I've done it because then I would feel a lot more neurotic, I think, about being able to let it go where I am now. [laughs]

+ +

JOËL: Right. If we've got, like, an explicit checklist of things or a progress bar, then it feels like you got to get to all the things.

+ +

STEPHANIE: Yeah, exactly. I think there are still, you know, a couple more things that I wrote down on my little checklist of tasks that I would want to do once I feel like I want to come back to the game. But for now, like I said, I watched the credits roll. I teared up a little bit, you know, thinking about and reminiscing on my adventure with these characters, and I'm ready to put it down for a bit.

+ +

JOËL: Did I hear correctly that you made a checklist for this game of things you wanted to do?

+ +

STEPHANIE: Yes, [laughs] I did.

+ +

JOËL: That's amazing. I love that.

+ +

STEPHANIE: Yeah, you know, there are just so many things almost kind of like work where I had to, like, break down some of my goals. I wanted to, like, hit a certain level. I wanted to, you know, make sure I defeat these bosses that would help me get to those levels. And yeah, I got very into it. It was definitely a big part of my life for a couple of months.

+ +

I got it originally because I needed a game to play on my flight to Asia back when I went to Japan. And I'm like, oh, like, this looks, you know, fun and engaging, and it will distract me for my, you know, over 10-hour flight. Turns out it distracted me for many, many more hours over several months [laughs] since then. But I had a great time. So yeah, that's what's new for me. Again, it's something I'd never really done before. I will say though I am very behind on my reading goal as a result. [chuckles]

+ +

JOËL: I feel like this is a classic developer thing to do is, like, use the tools that we're used to in our job and then apply them to other parts of our life. And now it's just like, okay, well, I made a Kanban board to track my progress in this video game. You know, or, in my case, I'm definitely guilty of having drawn a dependency graph for the crafting tree for some video game. So I feel you really strongly there.

+ +

STEPHANIE: Yes, I'm nodding heavily in agreement. I think it just scratches the same kind of itch of, you know, achieving, like, little things and then achieving one big thing.

+ +

JOËL: So, speaking of places that are nice to have checklists and, like, well-defined requirements, you and I were talking earlier, and you have recently found some frustration around having user stories be defined well on your current project.

+ +

STEPHANIE: Yes. So I've been reflecting a little bit about my current project and noticing what I think I might call product smells; I'm not quite sure, just some things I'm seeing in our day-to-day workflow that is getting me thinking. And I'm curious to hear if you've experienced something similar.

+ +

But I find myself being tasked with a ticket that is quite vague. And maybe this was written by a product owner, or maybe it was written by another developer. And it is not quite actionable yet, so I have to go through the process of figuring out what I'm really needing to do here.

+ +

I think another thing that has been quite frustrating is, you know, maybe we do find out what we want to do. And, like, I'll go back into the ticket, write down the requirements that I gathered, and do the ticket. I'll ship whatever change was required, and then I'll hear back from someone in a meeting or either as a one-off request in Slack. And it'll be like, "Hey, like, actually, you know, we want this to be different." And maybe you previously said that "Oh, the value for something would be 30. But now we found out more information; it should be 20. And so could you, like, make that change?"

+ +

And then I'm not really sure what the best way to document a change like that is because it, you know, maybe existed in the previous ticket, but now it has changed. And do I create a new ticket for this, or do I just go ahead and make the code change? Like, who would know this information that we're now carrying about 20 being the value for, let's say, like, days or not meaning something in the code that we're writing?

+ +

And I guess I've just been really curious about how to make sure that this doesn't become the norm where a lot of these conversations are just happening, and, you know, the people who happen to be in them know that this change happened. But then later on, someone is asking questions about, like, hey, like, when did this change? Or I expected this to be 30. But is this, you know, behaving as expected?

+ +

So that was [laughs] a bit of a nebulous way of describing just, like, this churn that I feel with being the executor of work. But then, like, a lot of these things changing above me or separate from me and figuring out how to manage that.

+ +

JOËL: When you were describing this scenario where you've done the work, and then someone's like, "Oh, could we change this value from, like, 30 to 20?" I'm thinking in my mind of the sort of beam that a lot of our designers face where it's like, you know, they have a design. They work on it; they do it. And then show it to a client, and the client is like, "I love this design. But could we just shift this box over, like, one pixel?"

+ +

Like, they're, like, tiny, tiny, little changes that are kind of requested for change after you've done, like, this big thing. And, oftentimes, those pile-up. It's like, you shift it one pixel. It's like, oh, actually, you know what? Why don't we do it two pixels? And then it's like never-ending cycles, sometimes of, like, minute little changes.

+ +

STEPHANIE: Yeah. But the minute changes really add up into, I think, really different behavior than what you maybe had decided as a team originally. And in the process of changing and evolving, I don't really know where documentation fits in.

+ +

I've been working on this project that had a pretty comprehensive product design doc, where they had decided upfront on, you know, how the application is going to behave in many different scenarios. But again, like, that has changed over time. And when I recently had to onboard someone new to this project, you know, we sent over this document, and we're like, yeah, you can, you know, feel free to peruse it. But it's actually quite outdated.

+ +

And then, similarly, right now, since the features that I'm working on are going through QA, there's been a lot of back and forth about, I'm seeing this, but the doc said that Y is supposed to happen, and I'm not sure if that's a bug or not. And I or someone else has to respond with that context that we were holding in our head about when that change happened.

+ +

JOËL: That's really interesting. And I think it varies a lot based off the size of the organization. In a smaller organization, you're probably doing a lot of the requirements gathering yourself. You're talking to all the stakeholders. You're probably doing the QA yourself, or you're walking somebody else through QA. Versus a large organization, there might be an entirely separate product team, and a separate QA team, and a separate dev team.

+ +

And a danger that I've often seen is where all of these teams are just kind of tossing work over the fence. And all you're given is a, you know, a ticket of, like, execute on this. Basically, turn these specs into code. And then you do that, and then you toss it over the fence to the QA team. And they check does the code do these things? And there's so much context that can easily get lost from one step to another. That being said, I think a lot of devs find it frustrating to do some of the requirements gathering work.

+ +

How do you feel in general about scoping out a ticket or doing follow-up conversations with the product team about, like, "Hey, your idea for the ticket is this. How do you feel about doing these things? Or what if we cut these things?" Are those conversations that you enjoy having? Is that a fun part of the developer role for you? Or do you kind of wish that, like, somebody else did all of that so that you could, like, go heads down just writing code?

+ +

STEPHANIE: I think it depends. That's a great question. Actually, I have so many thoughts in response. So let me try to figure out where I want to go from here.

+ +

But I think I used to not like it. I used to be stressed out by it, and sometimes I still am. But when I thought my role was purely executing, to receive a ticket that is a bit vague, you know, I might have been left feeling, like, stuck, like, not knowing where to go from there.

+ +

But now that has changed a bit because I received some really helpful feedback from an old manager of mine who was kind of invested in my growth. And she really suggested learning to become more comfortable with ambiguity because that just becomes more and more your job, I think, as you progress in your career. And so now I at least know what information I need to go get and have, you know, strategies for doing so.

+ +

And also knowing that it's my job, like, knowing that no one else might be doing it, and it might just be me so that I can therefore get this ticket done. Because, like you said, that problem of throwing the work over the fence to someone else, at some point, that doesn't work because everyone has too much on their plates. And you have to just decide to be the one to seek the information that you need.

+ +

JOËL: I think one way that, as developers, we bring a lot of value is that we help to cut through a lot of that ambiguity. I think if we see our role as merely translating a requirements document into code, that's a very simplistic point of view of what a talented developer does. So, like you said, as we grow in our careers, we start dealing with less and less defined things. We often have to start defining the problems that we're given.

+ +

And we have to have these conversations with other teams to figure out what exactly we want to do. And maybe better understand why is it that we want to do this thing. What is the purpose of it? How are we going to get there? And my favorite: Do we have to do all of these things to hit the minimum value of this goal? Can I split this into multiple tickets? I love breaking down work. If I can make the ticket smaller, I'm all about that.

+ +

STEPHANIE: Yes. I'm well aware. It's interesting about what you said, though, is that, like, yes, that becomes, in some ways, our superpower. But, for me, where the pain comes in is when that's not part of the expectations, where I am maybe tasked with something that is not clear enough, and yet, the time that I need to find that clarity is not given the respect that it, I think, deserves to build a good product because the expectation is that I should already be making progress on this ticket and that it will be delivered soon.

+ +

You know, in that situation, I wish I had been in the room earlier. I wish I had been part of the process for developing the product strategy, or even just, like, have come in earlier to be able to ask, you know, why are we building this? And, like, what are some of the limitations on the technical side that we have? Because often, I find that it is a little too...not necessarily too late, but it is quite down the road that we then have to have these conversations, and it doesn't feel good.

+ +

JOËL: I think that's one of the powerful things that came out of the agile movement was the idea that you have these cross-functional teams, that you don't have a separate product team, a separate dev team, a separate QA team, a separate design team that are all these isolated islands. But instead, you say, okay, we have a cross-functional team that is working on this aspect of the product. And it will be some product people, some dev people, some designers kind of all working together and communicating with each other. I know, shocking concept.

+ +

And even depending on the context, a big idea is that the client or the customer is a part of that team. So, when we at thoughtbot work with a client, especially when they are maybe a smaller client like a startup founder, we make sure that they feel like they are a part of the team. They are involved in various meetings where we decide things. They have input. You know, they're part of that feedback cycle that we build. But that can also be the case for a larger company where your internal stakeholders are kind of built-in to be sort of part of your team.

+ +

STEPHANIE: I've seen so many different flavors of trying to do Agile [laughs] that it has lost a little bit of meaning for me these days. And maybe we've incorporated some aspects of it. But then that idea of the tight feedback loops and then a cross-functional team where everyone is communicating that part has gotten a little bit lost, at least on my project. And I imagine that this is common, and our listeners might be finding themselves in a similar situation where things are starting to feel a little more like handing off and a little more like waterfall. [laughs]

+ +

I'm curious, though, if you found yourself being requested to make a change from what the original decision was, how would you go about documenting that or not documenting it? Where do you think the best place for that information about how this feature now is supposed to work where should that live?

+ +

JOËL: Are you talking about where do we document that a decision was made to change the original requirements of a task?

+ +

STEPHANIE: Yes.

+ +

JOËL: In general, I think that should live on the ticket just because as long as the ticket is live, I think it's good to have all the context on that ticket for whoever's working on it to have access at a glance.

+ +

Sometimes it's worth it to say, you know what? We don't want to just keep this ticket live for weeks or maybe months on end. Let's ship this ticket, and create a follow-up to make a change later, especially if it's a change that's less important where it's like, you know what? It would be nice to have if...but, again, like, scope creep is a real danger. And so, again, me with the aggressive breaking up of tickets, I love to say, "That's a great idea. It would make a great change, not part of this ticket." So oftentimes, those changes I will push them into another ticket.

+ +

STEPHANIE: That's interesting. What about documentation beyond the current work? So I'm thinking about once, you know, a feature is delivered, how do people in the organization then know how this feature is supposed to work? Like moving forward as something that is customer-facing.

+ +

JOËL: That can vary a lot by organization, I think because there's a couple of different aspects to this. You have maybe some internal-facing documentation; maybe some customer support people need to know about the way the interface has changed. And then you also have customer-facing documentation where maybe you want some sort of, you know, you want a blog post talking about the new feature or some kind of release notes or something like that to be shared with your customers. And compiling that might look very different than what you do for your internal service reps.

+ +

STEPHANIE: Yeah, I like that. It's true that the customer documentation is really helpful. At least for, the product that I'm working on, it has very comprehensive documentation about how to use that for its customers. And that has been really helpful because, hopefully, that should be the truest [laughs] information out there.

+ +

But sometimes, you know, I find myself in meetings where none of us really know what happens. For example, a question that was asked recently is our product has a free trial capability. But it was unclear what happens to all of the data that the customer is getting access to as a feature. Like, what happens to that data after the free trial ends? Like, if they then have purchased a license, do they still have access to their free trial data? If, you know, there's a lapse between then, does it just get deleted, or will it show up again? And no one really knew the answer to that.

+ +

And I think that was another area that got my spidey senses tingling a little bit; I think because it reminded me of...there was a definition I read somewhere of legacy code that is basically when the person who has the most context about how a piece of code works and then they leave the company and that institutional knowledge no longer exists, like, that is legacy code. And I almost think that that also applies to product a little bit where a legacy product is something where no one quite knows what is supposed to happen, but it's still being used by users.

+ +

JOËL: That's a really fun definition there. I think there's sort of two related questions that are slightly different here, which is, one, how does the code behave? So, what happens when someone's trial period expires? And it's quite possible that no one on the team knows what actually happens when that time expires.

+ +

And then the second question is, what should happen when a trial expires? And it's possible, again, that the product team didn't think through any of the edge cases. They only went for the happy path. And so it's possible if that is also fully undefined and no one knows.

+ +

STEPHANIE: Yeah, I like that distinction you made a lot because they definitely go hand in hand, where someone realizes that some weird edge case happened, and then suddenly, they're asking those questions. And, you know, we realized, like, oh, like, that just didn't have enough, like, intention or thought behind how it was coded. So, like, it really is; who knows, right? Just whatever seems to happen.

+ +

And I think that this actually kind of reminds me of a previous episode we did about empowering other departments in the company because, ultimately, a lot of those questions about, like, how does this work? What happens? Ends up going to a developer who has to go and read the code and report back. And while, you know, we do have that power, it can also be a bit of a curse, I think. [laughs]

+ +

JOËL: I think this is an area where, as developers, we're maybe particularly skilled. Because of the work that we do, our brains are kind of wired to think about all of the edge cases, and sometimes they can be really annoying.

+ +

But I think there's a lot of value sometimes when maybe the product team comes to us with a maybe somewhat nebulously scoped ticket or a series of tickets for, let's say, a free trial period feature that only goes through the happy path. And then sometimes it's up to us to push back or to follow up and say, "Okay, great. We've got a bunch of tickets for a free trial period. Have you thought about what happens after a trial expires but the person hasn't converted to a paying customer?" And then, oftentimes, the answer is like, "Oh, no, we didn't think about that."

+ +

And I think oftentimes, as developers, our job is to kind of, like, seek out a lot of those edge cases. And we have a lot of techniques and methodologies that we use to try to find edge cases, things like test-driven development, various modeling tools that we'll try to use to make sure that we don't just crash or do something bad in our code.

+ +

But what should the actual behavior be? That's a conversation that we need to have. And hopefully, that's one that maybe the product team has already had on their own. But oftentimes, the benefit of having that cross-functional team is the ability to kind of have that back and forth and say, "Hey, what about this edge case? Have we thought about that? How do we want that to behave?"

+ +

STEPHANIE: Yeah, that actually made me think about the idea of tech debt but almost at a product level, where, hey, it turns out that we have all of these things that we didn't quite think through, and it's now causing problems. But how much do we invest in revisiting it? Because, you know, maybe this feature is several years old, and it was working just okay enough for it to, you know, be valuable. But we're now discovering these things and, you know, like, do we invest in them? Or are we more focused on, you know, coming up with new things and new features for our customers?

+ +

JOËL: That's a classic prioritization problem. It also kind of reminds me of the idea of an MVP. What are the actual, like, minimum set of features that you need in order to try out something or to ship something to customers? And, you know, maybe we don't need some special behavior if your trial account doesn't convert. Maybe we're okay [laughs] that you log in, and the app just crashes. Probably not, because we would probably want you to convert to a paying customer at some point. But maybe we're okay if you just get a screen that says, "You have no projects," when, in fact, you did have projects. It's just that you're no longer on the free trial.

+ +

Again, for business reasons, probably we want a call to action there that says, "You have five projects. They are not available to you. Please pay to unlock your projects again." That probably converts better. But, again, now that is a business decision. And that becomes a prioritization question that the team as a whole gets to address.

+ +

Sometimes it can also be some really fun prioritization things where if you're on a really tight schedule, you might ship some features live knowing that you have a time limit, but you don't have to necessarily ship other things. So let's say you've got a 30-day trial, and maybe you ship that before you've even implemented what the dashboard will look like after your free trial has expired, and that's fine because no one's going to hit that condition for 30 days. So now you've got 30 days to go out and handle that condition.

+ +

And maybe that's okay because it allowed you to get to market a little bit faster, allowed you to cut scope, break those tickets, yes, and just move that much faster. But it does require discipline because now you're on the clock. You've got 30 days to fix that edge case or potentially face some unhappy customers.

+ +

STEPHANIE: Yeah, I think that's quite a funny way to handle it. It's really ruthless prioritization [laughs] there.

+ +

But what you said was very interesting to me because I was thinking about how there is such a focus on new feature development and that being the thing that will attract customers or generate more money. But there is something to be said about investigating some of our old features of our existing system and finding opportunities there. And oftentimes, revisiting them will reduce the amount of pain [chuckles] that, you know, developers feel having to kind of keep track or have an eye on, like, where things are airing out, but then don't have the time to really invest in making it better or making that part of the product better.

+ +

JOËL: I think that's a great opportunity then to have a conversation with other parts of the team. Typically, I think you have to convert some of those into more of a business case. So the business people in the company or the product people might not care about the sort of raw metrics that you see as a developer. Oh, we got an exception with a stack trace in this part of our app. What does that even mean?

+ +

But if you say, hey, people who signed up for a free trial and then didn't immediately convert within 30 days who want to come back a month later and convert are unable to do so. And we've seen that that's about 10% of the people who signed up for a free trial. Well, now that's an interesting business question.

+ +

Are we losing out on potentially 10% of customer acquisition? I'll bet the sales and marketing people care a lot about that. I'll bet the business people care a lot about that. The product people probably care a lot about that. And now we can have a conversation about should we prioritize this thing? Are these metrics that we should improve? Is this a part of our code that's worth investing in?

+ +

STEPHANIE: Yeah, I like that because, in some ways, asking those questions about how does it work? Like, that is really an opportunity because then you can find out, and then you can make decisions about whether it's currently providing enough value as is or if there is something hiding under there to leverage.

+ +

JOËL: And I think that's one of the other places where, as developers, we provide value to clients is that we can sort of talk both languages. We can talk product language. We can talk business language. But we can also talk code. And so when we see things like that in code, sort of translate that into, like, what are the business impacts of this code change? Which then allows everyone to make the best possible decisions for the mission of the organization that you're a part of.

+ +

So we've talked about a variety of sort of patterns and anti-patterns that surround working through some of this churn on a product. I'm curious, Stephanie, for you, what's maybe one concrete thing that you've done recently that you've found has really helped you navigate this and maybe help reduce some of the stress that you feel as you navigate through this?

+ +

STEPHANIE: Yeah, I think, for me, one of the worst things is when that discussion is had in a meeting or a [inaudible 35:45] and then is not put anywhere. And so, one thing I've been making sure to do is either asking the person who made the request to write it down, either on the ticket or in Slack. Or I will write it down, you know, I will document the outcomes of what we talked about and putting it in a public space so that people are aware.

+ +

I think that small action has been helpful because we hold so much of this in our heads. And I've been finding that it ends up being hard for people to rotate onto different projects and, you know, get onboarded and up to speed effectively because there's so much knowledge and context transfer happening. But even just putting it in a place where maybe it's not relevant to everyone, but at least they see it. And then the next time that they're asked or maybe, like, do come around to working on this, they, like, have some fragment of a memory that they saw something about this. So that has been really helpful.

+ +

It actually dovetails really nicely into what we were talking about with opportunities, too, because once it's out there, like, maybe someone else will see it and have an idea about how it could be better or that change not being what they expected, and they can weigh in a little more. So that's what I'm trying to do.

+ +

And I think it's also nice to see how often that happens, right? If we're constantly seeing things changing because we have a written record of it, that could be helpful in bringing up and investigating further as to, like, why is this happening? Like, why do we experience this churn? And is that something we want to address?

+ +

JOËL: Yeah, because an element that we haven't talked at all about is any sort of feedback cycle or retrospective, where we can talk about these things and having that written trail and saying, "Oh, we changed this decision five times in the past week, like, really churned there." Now maybe that prioritizes it to be an important thing to talk about and to improve for the next cycle.

+ +

STEPHANIE: What I feel really strongly about is when, you know, each individual on a team is feeling this pain, but it not being known that it's actually a collective issue. Because maybe these things are happening in one-on-one conversations, and we don't realize that, like, oh, maybe there is something bigger here that we could improve on. And so the more eyes on it there are, the more visible it is, I think, that the easier it is to address.

+ +

JOËL: I love that, the power of writing things down. On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4iQ1AK3P + + ]]> + + Joël Quenneville + Stephanie Minn + + + 391: Learn with APPL + https://bikeshed.thoughtbot.com/391 + 00531566-9372-4957-915f-36af536528d5 + Wed, 05 Jul 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie went to her first WNBA game. Also: Bingo. Joël's new project has him trying to bring in multiple databases to back their ActiveRecord models. He's never done multi-database setups in Rails before, and he doesn't hate it. + +Stephanie shares bits from a discussion with former Bike Shed host Steph Viccari about learning goals. Four elements stood out: + +**A**dventure (try something new) +**P**assion (topic) +**P**rofit (from recent learnings) +**L**ow-risk (applicable today) + += APPL + +Stephanie and Joël discuss what motivates them, what they find interesting vs. what has immediate business value, and how they advocate for themselves in these situations. They ponder if these topics can bring long-term value and discuss the impact that learning Elm had on Joël's client work. + 40:45 + no + + + Stephanie went to her first WNBA game. Also: Bingo. Joël's new project has him trying to bring in multiple databases to back their ActiveRecord models. He's never done multi-database setups in Rails before, and he doesn't hate it. +Stephanie shares bits from a discussion with former Bike Shed host Steph Viccari about learning goals. Four elements stood out: +Adventure (try something new) +Passion (topic) +Profit (from recent learnings) +Low-risk (applicable today) += APPL +Stephanie and Joël discuss what motivates them, what they find interesting vs. what has immediate business value, and how they advocate for themselves in these situations. They ponder if these topics can bring long-term value and discuss the impact that learning Elm had on Joël's client work. +Elm (https://elm-lang.org/) +Practical Object-Oriented Design in Ruby (https://www.poodr.com/) +Design Patterns in Ruby (http://designpatternsinruby.com/) +Quarter Life (https://www.penguinrandomhouse.com/books/579928/quarterlife-by-satya-doyle-byock/) +Working Iteratively (https://thoughtbot.com/blog/working-iteratively) +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: All right, I have a new-new thing and an old-new thing to share with you today. So the new-new thing is that I went to my first WNBA game [laughs] last week, which is also my third professional sports game ever, probably. I am not a sports person. But a rather new friend of mine invited me to go with her because they are fans, and so I was like, yeah, sure. I'll try anything once. And I went, and I had a great time. It was very exciting. +I mean, I know the basic rules of basketball, right? Get the ball in the hoop. But I was very surprised to see how fast-paced it was. And, you know, I was like, wow, like, this is so much fun. There's so much going on, like, the music, you know, the crowd. It was very energizing. And then my friend actually told me that that was a pretty slow game, [chuckles] relative to how they normally go. And I was like, oh, wow, like, if that was slow, then I can't wait for a real competitive [laughs] game next time. +So that's my new-new thing. I had a good time. Will do it again. I'm just, like, a 15-minute bike ride from the stadium for our team in Chicago. It's called The Sky. That's our WNBA team. So yeah, I'm looking forward to being basketball Stephanie, I guess. [chuckles] +JOËL: That's really cool. How does the speed compare to other sports you've gone to see? +STEPHANIE: I think this is why I was interested because I've really only seen baseball, for which I know very little. And that, I think, is, like, a much slower-paced kind of sport. Yeah, I have some memories of going to, like, college football games, which also, like, quite slow. I just remember standing around for a while. [laughs] So I think basketball might be the thing for me, at least in terms of engaging my interest. +JOËL: You want something that actually engages you with the sport the whole time. It's not just a social event themed around occasionally watching someone do something. +STEPHANIE: Yes, exactly. I also enjoyed the half-time performances, you know, there was just, like, a local dance team. And I thought that was all just very fun. And, yes, I had a lot to, you know, just, like, point to and ask questions about because there was just so much going on, as opposed to sitting and waiting, at least that was my experience [laughs] at other kinds of sports games. +As for the old-new thing, now that it's summer, there is a local bar near me that does bingo every week. But it's not just normal bingo. It's called veggie bingo, which I realize is kind of confusing [chuckles] if you just, like, call it veggie bingo, but it's bingo where you win vegetables or, like, produce from local community gardens and other, you know, small batch food items. And I had a great time doing it last year. I met some new friends. It just became our weekly hangout. And so I'm looking forward to doing that again. +And, I don't know, I'm just glad I have fun things to share about what's new in my world now that the weather is warm and I'm doing stuff again. I feel like there was one point in the winter where I was coming [chuckles] onto the show and sharing how I had just gotten a heated blanket in the middle of winter, and that was the most exciting thing going on for me. So it feels good to be able to bring up some new stuff. +JOËL: Seasonality is a thing, right? And, you know, there are rhythms in life. And sometimes things are more fast-paced, sometimes they're a bit slower. That's really exciting. Did you take any produce home, or did you win anything when you went to play? +STEPHANIE: I did. I won a big bag of produce the last time that I went. At this point, it was last season. But it was right before I was about to go on vacation. So I ended up -- +JOËL: Oh no. +STEPHANIE: [chuckles] Right. I ended up not being able to, you know, keep it in the fridge and just giving it away to my friends who did not win. So I think it was a good situation overall. That's my tip, is go to bingo or any kind of prize-winning hang out as a group, and then you can share the rewards. It's very exciting. Even if you don't win, you know, like, probably someone else at your table will win, and that is equally fun. +JOËL: I think the closest I've been to that experience is going to play, like, bar trivia with some friends and then winning a gift card that covers our dinner and drinks for the evening. +STEPHANIE: Yeah, yeah, that's great. I used to go to a local trivia around me too. The best part about bingo, though, is that it requires no skill at all. [laughs] I, yeah, didn't realize, again, how into these kinds of things I would be until I just tried it out. Like, that was...bingo is another thing I don't think I would have internally decided to go do. But yeah, my friends just have all these great ideas about fun things to do, and I will happily join them. +So, Joël, what's new in your world? +JOËL: So I've recently started a new client project. And one of the really interesting things that I've been doing on this project is trying to bring in multiple databases to back our ActiveRecord models. This is a Rails app. I've never done multi-database setups in Rails before. It's been a feature since Rails 6, but this is my first time interacting with that system. And, you know, it's actually pretty nice. +STEPHANIE: Really? It ended up being pretty straightforward or pretty easy to set up? +JOËL: Yeah. There's a little bit of futzing around you have to do with the database YAML configuration file. And then what you end up doing is setting up another base class for your ActiveRecord models to inherit from. So, typically, you have that application record that you would inherit from for your primary database. But for other databases, if you want a model to be backed by a table from that system, then you would have a separate base class that all of those models inherit from, and that's pretty much it. Everything else just works. +A bunch of your Rake tasks get a little bit different. So you've got to, like, configure your setup scripts and your test scripts and all that thing a little bit differently. But yeah, you can just query, do all the normal things you do with an ActiveRecord model, but it's reading from a different database. +STEPHANIE: That's really cool that it ended up being pretty painless. And I'm thinking, for the most part, as a developer, you know, working in that kind of codebase; maybe they don't really need to know too much about the details of the other databases. And they can just rely on the typical Rails conventions and things they know how to do via Rails. +Do you suspect that there might be some future where that might become a gotcha or something that someone has to debug a little further because of the multi-database setup? +JOËL: There are some infrastructure things, but I think I'm handling all of them upfront. So like I said, configuring various setup scripts, or test scripts, or CI, that kind of thing to make sure that they all work. Once that's all done, I think it should pretty much just work. And people can use them like they would normal ActiveRecord models. +The one gotcha is that you can't join models across two different databases. You can't use ActiveRecord to write a query that would try to join two tables that are in different databases because the SQL won't allow for that. So, if you're ever trying to do something like that or you have some kind of association where you're trying to do some special join, that would not work. So, if somebody attempts that, they might get an unexpected error. Other than that, I think it just keeps working as normal, and people can treat it more or less as if it's one database. +STEPHANIE: That's interesting. How do you model relationships between tables on the two different databases, then? Like, how would that work? +JOËL: I've not gotten that far yet. For some things, I imagine just it's two queries. I'm not sure if the ActiveRecord associations handle that automatically for you. I think they probably will. So you probably can get away with an association where one model lives in one database. Let's say your article lives in one database, and it has many comments that live in a different database. +Because then you would make one query to load the article, get the article ID, and then you would do another query to the second database and say, hey, find all the comments with this article ID, which is already, I think, what ActiveRecord does in one single database. It is making two queries. It's just that now those two queries are going to be two different databases rather than to a single one. +STEPHANIE: Interesting. Okay. I did think that maybe ActiveRecord did some fancy join thing under the hood. And when you mentioned that that wouldn't be possible when the two tables are on different databases, I was kind of curious about how that would work. But that makes sense. That would be really cool if it is, you know, that straightforward. And, hopefully, it just doesn't become too big of an issue that comes back to haunt someone later. +JOËL: Right. So pretty much, if there is a situation where you were relying on a JOIN, you will now have to make two separate queries and then combine the results yourself. +STEPHANIE: Right. I also want to give you kudos for doing all the good work of setting it up so that, hopefully, future developers don't have to think about it. +JOËL: Kudos to the Rails team as well. It's nice to have that just kind of built into the framework. Again, it's not something I've needed in, you know, a decade of doing Rails, but then, you know, now that I have run into a situation where I need that, it just works out of the box. So that's been really nice. +So, a couple of weeks ago, we talked about the fact that we were going through review season and that we had to fill out reviews for ourselves then also fill out peer reviews for each other. You had brought up a really interesting conversation you had about reaching out to other people and trying to get feedback on what kind of review or feedback would be helpful for them. +STEPHANIE: I did, yeah. Though, I think in this case, the person writing that feedback actually reached out to me, but certainly, it goes both ways. Spoiler alert - that person was Steph Viccari, former [laughs] host of The Bike Shed. +JOËL: So Steph also reached out to me with similar questions. And that spawned a really interesting conversation around personal goals and what it looks like, particularly when it comes to what to learn next in technology. We started discussing things, and I listed out some different things that I was interested in. And then just kind of out of nowhere, Steph just pulls out this, like, oh, I noticed these four elements. And I'm going to list them out here because it's really cool. +So these four elements were adventure, so trying something new. Passion, so something that's really exciting to you. Profit something where you can leverage some recent things that you've done to get more value out of some work you've already done. And then finally, low risk, something that would be applicable today. And it just kind of turns out that this makes a funny little acronym: APPL. And apples are often a symbol of learning. So that was kind of a fun coincidence. +STEPHANIE: I love when someone is able to just pull apart or to tease out pieces of, you know, something that you might have just, like, kind of dumped all of into a message or something, and then to get, like, a second eye to really pick out the themes is so valuable, I think. And I'm obsessed with this framework. I think we might have come across something new that could really be helpful for a lot of other people. +JOËL: It's definitely...I think it shows capacity for a higher level of thinking when someone's able to just look at a bunch of concrete things and say, wait a minute; I'm seeing some larger themes emerge from what you're talking about. And I always really appreciate it when I'm having a conversation with someone, and they're like, "Hey, I think what I'm hearing is this." And you're like, "Whoa, you're totally right. And I did not even know that that's where I was going." +STEPHANIE: Absolutely. I'd love to go through this acronym and talk about a few different things that we've learned in our careers that kind of correspond with each of these elements. +JOËL: Yeah, that sounds great. So I think, you know, the first one here is adventure, trying something new. So, what's something where you tried something new or adventurous that you think was worthwhile? +STEPHANIE: Hosting this podcast. [laughs] It was a huge adventure for me and a really big stretch, I think. And that's what the idea of adventure evokes for me is, like, maybe it's uncharted territory for you, and you might have some reservations about it. But, you know, obviously, the flip side of an adventure is how fun and exciting and just new and stimulating it can be. +And so I think, yeah, like, when I first started doing this with you, and even when you first asked me, I was pretty nervous. I was really hesitant. It took me a long time to, you know, think it over. I was like, do I want to commit to something that I have never done before, and it's, like, a pretty longer-term commitment? And I'm really glad I did it. +It's certainly been an adventure. It's, you know, got its ups and downs. You know, not every week do I feel like that went really well, like, that was a great episode. Sometimes I'm like, that was just an okay episode, [laughs] and, you know, that's fine too. +But I feel like this was really important in helping me feel more confident in sharing my technical opinions, helping me feel more comfortable just kind of, like, sharing where I am and not feeling like I should be somewhere else, like, some other level or have already known something. Like, the point is for us to share the journey week by week, and that was something that was really hard for me. So being on this Bike Shed adventure with you has been very valuable for me. +JOËL: Yeah, it's sharing these new things we've learned along the way. +STEPHANIE: Literally. Yes. What about you? Do you have something adventurous that you learned? +JOËL: I think an important inflection point where I tried something new was when I learned the Elm programming language. So I had mostly done procedural languages back in the day. And then I got into Ruby, did a lot of OO. And then I got into Elm, which is statically-typed, purely functional, all these things that are kind of opposite of Ruby in some ways. But I think it shares with Ruby that same focus on developer happiness and developer productivity. So, in some ways, I felt really at home. +But I had to learn just a whole new way of programming. And, one, it's cool. I have a new tool in my belt. And I think it's been a couple of years just learning how to use this language and how to be effective with it. But then afterwards, I spent a couple of years just kind of synthesizing the lessons learned there and trying to see, are there broader principles at play here? Are there ideas here that I can bring back to my work in Ruby? +And then maybe even are there some ideas here that intersect with some theories and things that I know from Ruby? So maybe some ways of structuring data or structuring code from functional programming where some best practices there kind of converge on similar ideas as maybe some object-oriented best practices, or maybe some ideas from test-driven development converge on similar ideas from functional programming. And I think that's where, all of a sudden, I was unlocking all these new insights that made me a better Ruby developer because I'd gone on an adventure and done something completely out of left field. +STEPHANIE: Yeah, absolutely. Do you remember what was hard about that when you first embarked on learning Elm? +JOËL: All the things you're used to doing, you just can't do. So you don't have looping constructs in Elm. The only thing you can do is recursion, which, you know, it's been a long time since CS classes. And you don't typically write recursion in Ruby. So I had to learn a whole new thing. And then it turns out that most people don't write recursion. There's all these other ways of doing things that you have to learn. You have to learn to do folds or to use maps and things like that. +Yeah, you're just like, oh, how do I do X in Elm? And you have to figure it out. And then maybe sometimes it turns out you're asking the wrong question. So it's like, oh, how do I do the equivalent of a for loop with array indexes in Elm to, like, iterate through a data structure? And it's like, well, kind of here's technically the way you could do that, but you would never solve a problem in that way. +You've got to learn a new way of thinking, a new way of approaching problems. And I think it was that underlying new paradigm that was really difficult to get. But once I did get it, now that I have two paradigms, I think it made me a much more solid developer. +STEPHANIE: Right. That sounds very humbling, too, to kind of have to invert what you thought you knew and just be in that, you know, beginner's mindset, which we've talked about a little bit before. +JOËL: I think in some ways now being on the other side of it, it's similar to the insights you get from speaking multiple human languages, so being bilingual or trilingual or something like that where instead of just having assumptions about, oh, this is just how language works, because that's how your personal language works, now that you have more than one example to draw on, you can be like, oh, well, here's how languages tend to do things differently. Here's how languages are similar. +And I think it gives you a much better and richer feeling for how languages work and how communication works. And similar to having multiple paradigms in programming, I think this has given me a much richer foundation now for exploring and building programs. +STEPHANIE: That's really cool. I guess that actually leads quite well into the next element, which is passion. Because once you've tried some new things, you get the information of do I like this thing, or do I not like this thing? And then from there, you know, you gravitate towards the things you are passionate about to get a deeper understanding. And it becomes less about like, oh, just testing out the waters and like, knowing, hey, like, I constantly find myself thinking about this, like, let me keep going. +JOËL: Yeah. Or sometimes, it's deciding what do I want to learn next? And you just pick something that's interesting to you without necessarily being like, oh, strategically, I think this is another paradigm that's going to expand my mind. Or this is going to make me, you know, help me get that promotion next quarter, purely based off of interest. Like, this sounds fun. +STEPHANIE: That's really interesting because I think I actually came to it from a different angle, where one thing that I think was very helpful in my learning that came just, like, completely internally, like, no one told me to do this was reading books about design patterns. And that was something that I did a couple of years into my career because I was quite puzzled, I suppose, by my day-to-day experience in terms of wanting to solve a problem or develop a feature but not having a very good framework for steps to go about it, or not feeling very confident that I had a good strategy for doing it. +It was very, for me, it felt very just kind of, like, throwing pasta to the wall and seeing what would stick. And I was really interested in reducing that pain, basically. And so that led me to read books. And, again, that was not something, like, someone was like, hey, I really think that you could benefit from this. It was just like, well, I want to improve my own experience. +And, you know, some of the ones that I remember reading (And this was based off of recommendations from others kind of when I floated the idea.) was, you know, Sandi Metz's Practical Object-Oriented Design in Ruby. Design Patterns in Ruby by Ross Olsen. Those were just, like, purely out of interest. Yeah, I guess I'm curious, for you, what fun and passion look like. +JOËL: Yeah, I think one thing that's a really fun side effect of passion learning is that I find that I tend to learn a lot faster and go a lot deeper, or I get more for every individual hour I put into learning just because passion or interest is such a multiplier. +Similar to you, I think I went through a time where I was just gobbling up everything I could see on design patterns, and code structure, things like that. Yeah, I've always been really excited about data modeling in general and how to structure programs to make them easy to change while also not putting a high maintenance burden on it, learning those trade-offs, learning those principles, learning a lot of those ideas. +I think that desire came out of some pain I felt pretty early on in my programming career, where I was just writing purely self-taught at this point from a few tutorials online. Code beyond a few hundred lines would just kind of implode under the weight of its own complexity. And so, like, I know that professional programmers are writing massively larger programs that are totally fine. So what am I missing? And so I think that sort of spurred an interest. And I've kind of been chasing that ever since. Even though I'm at the point where that is no longer a problem in my daily life, it is still an interest that I keep. +STEPHANIE: Yeah. If I were to pull out another interest of yours that I've noticed that kind of seems in the same realm of, you know, you can just chase this forever, is working incrementally, right? And just all the ways that you can incorporate that into your day-to-day. And I know that's something we've talked about a lot. But I think that's really cool because, yeah, it just comes from just a pure desire on your own front to, like, see how far you can take it. +JOËL: I think you pulled out something interesting there. Because sometimes, you have an interest in a whole new topic, and sometimes the interest is more about taking something I already know and just seeing can I take it to an extreme? What happens when I really go to the boundaries of this idea? And maybe I don't need to go there ever for a client project. But let me put up a proof of concept somewhere and try it out just for the fun of it to see can I take this idea, then push it to an extreme and see does it break at an extreme? Does it behave weirdly? And that is just an enriching journey in and of itself. +Have you ever done, like, a...maybe not a whole learning journey but, you know, taken a few hours, or maybe even, like, some time on one of our investment Fridays to just explore some random idea and try it out? And it's like, huh, that was cool; that was a journey. And then maybe you move on to something next week because it's not like a big planned thing. But you're taking a few hours to dig into something totally random. +STEPHANIE: I actually think I'm less inclined to do that than maybe you or other folks are. I find the things I choose to spend my time on do have to feel more relevant to me in the moment or at least in my day-to-day work. +And I think that actually is another excellent transition into the last couple of elements in the APPL framework that we've now coined. The next being profit or, I guess, the idea of being valuable to you in your job in that moment, I suppose. Or I guess not even in that moment, but kind of connecting what you're learning to something that would provide you value. +So I know you were talking about learning Elm, and now you're able to see all of the value that it has provided, but maybe at the time, that was a little bit less of your focus. But for me, I find that, like, a driver for how I choose to spend my time. Often it's because, yeah, for the goal of reducing pain. +Being consultants, we work on a lot of different projects, sometimes in different frameworks, or languages, or new technologies. Like, you've mentioned having to, just now, on your new client project learning how to interact with different databases, and it sounds like older software that you might not have encountered before. +And I think that ends up falling higher on my priority list depending on the timing of what I'm currently working on is, oh, like, you know, TypeScript is something that has, like, kind of come and go as my projects have shifted. And so when it comes back to working on something using it, I'm like, oh, like, I really want to focus on this right now because it has very clear value to me in the next three to six months, or however long. But I have also noticed that once I'm off of that project, that priority definitely recedes. +JOËL: Yeah, I think that plays into that final element as well of the APPL, the low risk things that are applicable today that have value right now. Those tend to be things like, oh, I see that I'm going to be scheduled on a client that needs this technology next month. Maybe I should learn that, or maybe I should refresh this idea or go a little bit deeper because this is something new that I'm going to need. So, at some point, I knew that there was a Python project coming down the line. I was like, okay, well, maybe I'm going to spend a couple of Fridays digging into some Django tutorials and compare and contrast with Rails. +STEPHANIE: The low-risk element is interesting to me because I found it to be a challenging balance to figure out how much time to invest in becoming really comfortable in a new technology. I find myself sometimes learning just enough to get what I need to get done. And then other times really feeling like, wow, like, I wish I knew this better because that would make my life easier, or I would just feel a lot better about what I'm doing. And kind of struggling with when to spend that time, especially when there's, you know, other expectations of me in terms of my delivery. +JOËL: Yeah, that almost sounds like a contrast between technologies that fall in that low-risk bucket, like, immediately useful, versus ones that fall in the passion bucket that you're interested in taking deeply and maybe even to an extreme. +STEPHANIE: That's really interesting. What I like about this list of themes that we've pulled out is that, like, one thing can fall into a number of different categories. And so it's really quite flexible. +It actually reminds me of a book that I just finished reading. The book is called Quarterlife. And the thing that stuck out to me the most is the author, who is a psychotherapist; she has basically come up with two types of people, or at least two things, that end up being really big drivers of, like, human motivation and behavior. And that's stability types and meaning types, and the goal is to have a little bit of both. +So you may be more inclined towards stability and wanting to learn the things that you need to know for your job, to do well in your role, kind of like we were talking about to reduce that pain, to feel a little more in control, or have a little more autonomy over your day to day and how you work. And then there's the seeking meaning, and when we talked about adventure and passion, it kind of reminded me of that. Like, those are things that we do because we want to feel something or understand something or because it's fun. +And ironically, this list of four things has two that kind of fall into each category. And ultimately, the author, she, you know, was very upfront about needing both in our lives. And I thought that was a really cool distinction. And it was helpful for me to understand, like, oh yeah, like, in the early years of my career, I did really focus on learning things that would be profitable, or valuable, or low risk because those were the things that I needed in my job, like, right now. +And I am now feeling stable enough to explore the meaningful aspects and feel excited by trying out things that I think I just wasn't ready for back in the day. But it actually sounds like you may kind of have a different leaning than I do. +JOËL: That is really interesting. I think what was really fascinating as you mentioned those two sort of types of people. And, in my mind, now I'm immediately seeing some kind of two-dimensional graph, and now we've got four quadrants. And so are we leaning towards stability versus...was it adventure was the other one? Or meaning. +STEPHANIE: Meaning, yes. +JOËL: So now you've got, like, your quadrant that is high stability, high meaning, low stability, high meaning, like, all those four quadrants. And maybe these four things happen to fall into that, or maybe there's some other slightly different set of qualities that you could build a quadrant for here. +One that is interesting, and I don't know how closely it intersects with this idea of stability versus meaning, is how quickly the things you learn become useful. So that low risk, like that L from APPL, those are things that are immediately useful. So you put a little bit of work learning this, and you can immediately use it on the job. In fact, that's probably why you're learning it. +Whereas me going off and learning Elm is not because we've got any clients in the pipeline using Elm. It's purely for interest. Is it going to pay off? I think most learning pays off long-term, especially if it helps you build a richer understanding of the different ways software works or helps you have new mental models, new tools for doing things. And so I think, you know, 5, 6, 7 years later, learning Elm has been one of the highest payoff things that I've done to kind of take my coding career to the next level. That being said, I would not have seen that at the time. So the payoff is much more long-term. +How do you kind of navigate when you're trying to learn something, whether you want something with a short-term payoff or a longer-term payoff? +STEPHANIE: Yeah, that's so interesting. I wonder if there was maybe someone who could have helped you identify the ways that Elm could have possibly paid off. And I know, you know, you're looking back on it in retrospect, and it's easy to see, especially after many years and a lot of deep thinking about it. But kind of referring back to this idea of seeking meaning and that just being important to feeling happy at your job, like, maybe it was just valuable because you needed to scratch that itch and to experience something that would be interesting or stimulating in that way to prevent burning out or something like that. +JOËL: Oh, I like that. So the idea that you're learning a thing, not specifically because you're expecting some payoff in the long term but because of the joy of learning, is reward in and of itself, and how that actually keeps you fresh in the moment to keep going on a career that might, you know, last 5, 10, 20, 30 years, and how that keeps you refreshed rather than like, oh, but, like, I'm going to see a payoff in five years where now, all of a sudden, I'm faced with a problem. And I can be like, ah, yes, of course, monads are what we need here. And that's a nice side effect, but maybe not the main thing you look for when you're going for something in that passion bucket. +STEPHANIE: Yeah, absolutely. To go back to your question a little bit, I had mentioned that I was wondering if there was someone who could help point out ways that your interests might be useful. And I think that would be a strategy that I would try if I find myself in that conundrum, I suppose, of, like, being like, hey, like, this is really interesting to me. I'm not able to see any super immediate benefits, but maybe I can go find an expert in this who can share with me, like, from their experience, what diving deep into that topic helped them. +And if that's something that I need to then kind of justify to a manager or just kind of explain, like, hey, this is why I'm spending my time doing this is because of this insight that I got from someone else. That would be, I think, a really great strategy if you find yourself needing to kind of explain your reasoning. But yeah, I also think it's, like, incredibly important to just have passion and joy in your work. And that should be a priority, right? Even if it's not immediately clear, the tangible or valuable to the company benefits in the current moment. +JOËL: And I think what I'm hearing is that maybe it's a bit of a false premise to say there are some things that you follow for passion that only pay off in the long term. Because if you are in it for passion, then you're getting an immediate payoff regardless. You may also get an additional payoff in the long term. But you're absolutely getting some kind of payoff immediately as well. +STEPHANIE: Yeah, I think that's true for adventure because knowing what you don't like is also really valuable information. So, if you try something and it ends up not panning out for you, you know, I think some people might feel a little bit disappointed or discouraged. They think, oh, like, they kind of wasted time. But I don't know; I think that's all part of the discovery process. And that brings you closer and closer to, yeah, knowing what you want out of your learning and your career. +JOËL: So I'm really curious now. This whole, you know, APPL framework came out of a very random conversation. Is this something that maybe you're going to take into your own sort of goal-setting moving forward? Maybe try to identify, like, okay, what is something adventurous that I want to do, something I want to do for passion, something that I think for profit, and then something low risk? And then maybe have that inform where you put some energy in the next quarter, the next year, whatever timeline you're planning for. +STEPHANIE: Yeah, I thought about this a little bit before we started recording. But one very loose goal of mine...and this actually, I think, came up a little more tangibly after coming back from RubyKaigi and being so inspired by all of the cool open-source tooling and hearing how meaningful it was for people to be working on something that they knew would have an impact on a lot of people in their development experience. +Having an impact is something that I feel very passionate about and very interested in. And the adventure part for me might be, like, dabbling a little bit into open-source tooling and seeing if there might be a project that I would be interested or comfortable in dipping my feet into. +What about you? Do you have anything in the near or long-term future that might fall into one of these buckets? +JOËL: So I do have a list of things. I don't know that I will pursue all of them or maybe any of them. But here's my kind of rough APPL here. So something adventurous, something new would be digging into the language Rust. Again, the idea is to try a completely new paradigm, something low-level, something typed, something that deals with a lot of memory, something that does well with concurrency and parallelism. These are all things that I've not explored quite as much. So this would be covering new ground. +Something that is a passion, something that's interesting to me, would be formal methods, so I'm thinking maybe a language like TLA+ or Alloy. Data modeling, in general, is something that really excites me. These techniques that I think build on some of the ideas that I have from types but that go, like, to an extreme and also in a slightly different direction are really intriguing to me. So, if there's something that maybe I'm staying up in the evenings to do, I think that might be the most intriguing thing for me right now. +Something that might be more profitable, I think, would be digging into the world of data science, particularly looking at Notebooks as a technology. Right now, when I need to crunch data, I'm mostly just doing spreadsheets. But I think there are some really cool things that we could do with Notebooks that come up in client work. I manage to do them when you're with a random command-line script or sometimes with Excel. But I think having that tool would probably be something that allows me to do that job better. +And then, finally, something low-risk that I know we could use on a client project would be digging in more into TypeScript. I know just enough to be dangerous, but we do TypeScript all the time. And so, mastering TypeScript would definitely be something that would pay off on a client project. +STEPHANIE: I love that list. Thank you for sharing. +JOËL: Also, I just want to note that there are only four things here. It doesn't fully spell APPL because there's no E at the end. And so when I see the acronym now, I think it looks like a stock ticker. +STEPHANIE: It really does. But I think it's pretty trendy to have an acronym that's basically a word or a noun but then missing a vowel so... +JOËL: Oh, absolutely. Time to register that applframework.com domain. +STEPHANIE: Yeah, I agree. I also love what you said. You called it a rough APPL. And that was very [laughs] evocative for me as well. And just thinking about an apple that someone has, like, bitten into a little bit [laughs] and has some rough edges. But yeah, I hope that people, you know, maybe find some insight into the kinds of learnings and goals that they are interested in or are thinking about. And using these themes to communicate it to other people, I think, is really important, or even to yourself. Maybe yourself first and then to others because that's how your co-workers can know how to support you. +JOËL: That's really interesting that you are thinking of it in terms of a tool for communication to others. I think when I first encountered this idea, it was more as a tool of self-discovery, trying to better understand why I was interested in different things and maybe better understanding how I want to divide up the energy that I have or the time that I have into different topics. But I can definitely see how that would be useful for communicating with team members as well. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie went to her first WNBA game. Also: Bingo. Joël's new project has him trying to bring in multiple databases to back their ActiveRecord models. He's never done multi-database setups in Rails before, and he doesn't hate it.

+ +

Stephanie shares bits from a discussion with former Bike Shed host Steph Viccari about learning goals. Four elements stood out:

+ +

Adventure (try something new)
+Passion (topic)
+Profit (from recent learnings)
+Low-risk (applicable today)

+ +

= APPL

+ +

Stephanie and Joël discuss what motivates them, what they find interesting vs. what has immediate business value, and how they advocate for themselves in these situations. They ponder if these topics can bring long-term value and discuss the impact that learning Elm had on Joël's client work.

+ +
+ + + +

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: All right, I have a new-new thing and an old-new thing to share with you today. So the new-new thing is that I went to my first WNBA game [laughs] last week, which is also my third professional sports game ever, probably. I am not a sports person. But a rather new friend of mine invited me to go with her because they are fans, and so I was like, yeah, sure. I'll try anything once. And I went, and I had a great time. It was very exciting.

+ +

I mean, I know the basic rules of basketball, right? Get the ball in the hoop. But I was very surprised to see how fast-paced it was. And, you know, I was like, wow, like, this is so much fun. There's so much going on, like, the music, you know, the crowd. It was very energizing. And then my friend actually told me that that was a pretty slow game, [chuckles] relative to how they normally go. And I was like, oh, wow, like, if that was slow, then I can't wait for a real competitive [laughs] game next time.

+ +

So that's my new-new thing. I had a good time. Will do it again. I'm just, like, a 15-minute bike ride from the stadium for our team in Chicago. It's called The Sky. That's our WNBA team. So yeah, I'm looking forward to being basketball Stephanie, I guess. [chuckles]

+ +

JOËL: That's really cool. How does the speed compare to other sports you've gone to see?

+ +

STEPHANIE: I think this is why I was interested because I've really only seen baseball, for which I know very little. And that, I think, is, like, a much slower-paced kind of sport. Yeah, I have some memories of going to, like, college football games, which also, like, quite slow. I just remember standing around for a while. [laughs] So I think basketball might be the thing for me, at least in terms of engaging my interest.

+ +

JOËL: You want something that actually engages you with the sport the whole time. It's not just a social event themed around occasionally watching someone do something.

+ +

STEPHANIE: Yes, exactly. I also enjoyed the half-time performances, you know, there was just, like, a local dance team. And I thought that was all just very fun. And, yes, I had a lot to, you know, just, like, point to and ask questions about because there was just so much going on, as opposed to sitting and waiting, at least that was my experience [laughs] at other kinds of sports games.

+ +

As for the old-new thing, now that it's summer, there is a local bar near me that does bingo every week. But it's not just normal bingo. It's called veggie bingo, which I realize is kind of confusing [chuckles] if you just, like, call it veggie bingo, but it's bingo where you win vegetables or, like, produce from local community gardens and other, you know, small batch food items. And I had a great time doing it last year. I met some new friends. It just became our weekly hangout. And so I'm looking forward to doing that again.

+ +

And, I don't know, I'm just glad I have fun things to share about what's new in my world now that the weather is warm and I'm doing stuff again. I feel like there was one point in the winter where I was coming [chuckles] onto the show and sharing how I had just gotten a heated blanket in the middle of winter, and that was the most exciting thing going on for me. So it feels good to be able to bring up some new stuff.

+ +

JOËL: Seasonality is a thing, right? And, you know, there are rhythms in life. And sometimes things are more fast-paced, sometimes they're a bit slower. That's really exciting. Did you take any produce home, or did you win anything when you went to play?

+ +

STEPHANIE: I did. I won a big bag of produce the last time that I went. At this point, it was last season. But it was right before I was about to go on vacation. So I ended up --

+ +

JOËL: Oh no.

+ +

STEPHANIE: [chuckles] Right. I ended up not being able to, you know, keep it in the fridge and just giving it away to my friends who did not win. So I think it was a good situation overall. That's my tip, is go to bingo or any kind of prize-winning hang out as a group, and then you can share the rewards. It's very exciting. Even if you don't win, you know, like, probably someone else at your table will win, and that is equally fun.

+ +

JOËL: I think the closest I've been to that experience is going to play, like, bar trivia with some friends and then winning a gift card that covers our dinner and drinks for the evening.

+ +

STEPHANIE: Yeah, yeah, that's great. I used to go to a local trivia around me too. The best part about bingo, though, is that it requires no skill at all. [laughs] I, yeah, didn't realize, again, how into these kinds of things I would be until I just tried it out. Like, that was...bingo is another thing I don't think I would have internally decided to go do. But yeah, my friends just have all these great ideas about fun things to do, and I will happily join them.

+ +

So, Joël, what's new in your world?

+ +

JOËL: So I've recently started a new client project. And one of the really interesting things that I've been doing on this project is trying to bring in multiple databases to back our ActiveRecord models. This is a Rails app. I've never done multi-database setups in Rails before. It's been a feature since Rails 6, but this is my first time interacting with that system. And, you know, it's actually pretty nice.

+ +

STEPHANIE: Really? It ended up being pretty straightforward or pretty easy to set up?

+ +

JOËL: Yeah. There's a little bit of futzing around you have to do with the database YAML configuration file. And then what you end up doing is setting up another base class for your ActiveRecord models to inherit from. So, typically, you have that application record that you would inherit from for your primary database. But for other databases, if you want a model to be backed by a table from that system, then you would have a separate base class that all of those models inherit from, and that's pretty much it. Everything else just works.

+ +

A bunch of your Rake tasks get a little bit different. So you've got to, like, configure your setup scripts and your test scripts and all that thing a little bit differently. But yeah, you can just query, do all the normal things you do with an ActiveRecord model, but it's reading from a different database.

+ +

STEPHANIE: That's really cool that it ended up being pretty painless. And I'm thinking, for the most part, as a developer, you know, working in that kind of codebase; maybe they don't really need to know too much about the details of the other databases. And they can just rely on the typical Rails conventions and things they know how to do via Rails.

+ +

Do you suspect that there might be some future where that might become a gotcha or something that someone has to debug a little further because of the multi-database setup?

+ +

JOËL: There are some infrastructure things, but I think I'm handling all of them upfront. So like I said, configuring various setup scripts, or test scripts, or CI, that kind of thing to make sure that they all work. Once that's all done, I think it should pretty much just work. And people can use them like they would normal ActiveRecord models.

+ +

The one gotcha is that you can't join models across two different databases. You can't use ActiveRecord to write a query that would try to join two tables that are in different databases because the SQL won't allow for that. So, if you're ever trying to do something like that or you have some kind of association where you're trying to do some special join, that would not work. So, if somebody attempts that, they might get an unexpected error. Other than that, I think it just keeps working as normal, and people can treat it more or less as if it's one database.

+ +

STEPHANIE: That's interesting. How do you model relationships between tables on the two different databases, then? Like, how would that work?

+ +

JOËL: I've not gotten that far yet. For some things, I imagine just it's two queries. I'm not sure if the ActiveRecord associations handle that automatically for you. I think they probably will. So you probably can get away with an association where one model lives in one database. Let's say your article lives in one database, and it has many comments that live in a different database.

+ +

Because then you would make one query to load the article, get the article ID, and then you would do another query to the second database and say, hey, find all the comments with this article ID, which is already, I think, what ActiveRecord does in one single database. It is making two queries. It's just that now those two queries are going to be two different databases rather than to a single one.

+ +

STEPHANIE: Interesting. Okay. I did think that maybe ActiveRecord did some fancy join thing under the hood. And when you mentioned that that wouldn't be possible when the two tables are on different databases, I was kind of curious about how that would work. But that makes sense. That would be really cool if it is, you know, that straightforward. And, hopefully, it just doesn't become too big of an issue that comes back to haunt someone later.

+ +

JOËL: Right. So pretty much, if there is a situation where you were relying on a JOIN, you will now have to make two separate queries and then combine the results yourself.

+ +

STEPHANIE: Right. I also want to give you kudos for doing all the good work of setting it up so that, hopefully, future developers don't have to think about it.

+ +

JOËL: Kudos to the Rails team as well. It's nice to have that just kind of built into the framework. Again, it's not something I've needed in, you know, a decade of doing Rails, but then, you know, now that I have run into a situation where I need that, it just works out of the box. So that's been really nice.

+ +

So, a couple of weeks ago, we talked about the fact that we were going through review season and that we had to fill out reviews for ourselves then also fill out peer reviews for each other. You had brought up a really interesting conversation you had about reaching out to other people and trying to get feedback on what kind of review or feedback would be helpful for them.

+ +

STEPHANIE: I did, yeah. Though, I think in this case, the person writing that feedback actually reached out to me, but certainly, it goes both ways. Spoiler alert - that person was Steph Viccari, former [laughs] host of The Bike Shed.

+ +

JOËL: So Steph also reached out to me with similar questions. And that spawned a really interesting conversation around personal goals and what it looks like, particularly when it comes to what to learn next in technology. We started discussing things, and I listed out some different things that I was interested in. And then just kind of out of nowhere, Steph just pulls out this, like, oh, I noticed these four elements. And I'm going to list them out here because it's really cool.

+ +

So these four elements were adventure, so trying something new. Passion, so something that's really exciting to you. Profit something where you can leverage some recent things that you've done to get more value out of some work you've already done. And then finally, low risk, something that would be applicable today. And it just kind of turns out that this makes a funny little acronym: APPL. And apples are often a symbol of learning. So that was kind of a fun coincidence.

+ +

STEPHANIE: I love when someone is able to just pull apart or to tease out pieces of, you know, something that you might have just, like, kind of dumped all of into a message or something, and then to get, like, a second eye to really pick out the themes is so valuable, I think. And I'm obsessed with this framework. I think we might have come across something new that could really be helpful for a lot of other people.

+ +

JOËL: It's definitely...I think it shows capacity for a higher level of thinking when someone's able to just look at a bunch of concrete things and say, wait a minute; I'm seeing some larger themes emerge from what you're talking about. And I always really appreciate it when I'm having a conversation with someone, and they're like, "Hey, I think what I'm hearing is this." And you're like, "Whoa, you're totally right. And I did not even know that that's where I was going."

+ +

STEPHANIE: Absolutely. I'd love to go through this acronym and talk about a few different things that we've learned in our careers that kind of correspond with each of these elements.

+ +

JOËL: Yeah, that sounds great. So I think, you know, the first one here is adventure, trying something new. So, what's something where you tried something new or adventurous that you think was worthwhile?

+ +

STEPHANIE: Hosting this podcast. [laughs] It was a huge adventure for me and a really big stretch, I think. And that's what the idea of adventure evokes for me is, like, maybe it's uncharted territory for you, and you might have some reservations about it. But, you know, obviously, the flip side of an adventure is how fun and exciting and just new and stimulating it can be.

+ +

And so I think, yeah, like, when I first started doing this with you, and even when you first asked me, I was pretty nervous. I was really hesitant. It took me a long time to, you know, think it over. I was like, do I want to commit to something that I have never done before, and it's, like, a pretty longer-term commitment? And I'm really glad I did it.

+ +

It's certainly been an adventure. It's, you know, got its ups and downs. You know, not every week do I feel like that went really well, like, that was a great episode. Sometimes I'm like, that was just an okay episode, [laughs] and, you know, that's fine too.

+ +

But I feel like this was really important in helping me feel more confident in sharing my technical opinions, helping me feel more comfortable just kind of, like, sharing where I am and not feeling like I should be somewhere else, like, some other level or have already known something. Like, the point is for us to share the journey week by week, and that was something that was really hard for me. So being on this Bike Shed adventure with you has been very valuable for me.

+ +

JOËL: Yeah, it's sharing these new things we've learned along the way.

+ +

STEPHANIE: Literally. Yes. What about you? Do you have something adventurous that you learned?

+ +

JOËL: I think an important inflection point where I tried something new was when I learned the Elm programming language. So I had mostly done procedural languages back in the day. And then I got into Ruby, did a lot of OO. And then I got into Elm, which is statically-typed, purely functional, all these things that are kind of opposite of Ruby in some ways. But I think it shares with Ruby that same focus on developer happiness and developer productivity. So, in some ways, I felt really at home.

+ +

But I had to learn just a whole new way of programming. And, one, it's cool. I have a new tool in my belt. And I think it's been a couple of years just learning how to use this language and how to be effective with it. But then afterwards, I spent a couple of years just kind of synthesizing the lessons learned there and trying to see, are there broader principles at play here? Are there ideas here that I can bring back to my work in Ruby?

+ +

And then maybe even are there some ideas here that intersect with some theories and things that I know from Ruby? So maybe some ways of structuring data or structuring code from functional programming where some best practices there kind of converge on similar ideas as maybe some object-oriented best practices, or maybe some ideas from test-driven development converge on similar ideas from functional programming. And I think that's where, all of a sudden, I was unlocking all these new insights that made me a better Ruby developer because I'd gone on an adventure and done something completely out of left field.

+ +

STEPHANIE: Yeah, absolutely. Do you remember what was hard about that when you first embarked on learning Elm?

+ +

JOËL: All the things you're used to doing, you just can't do. So you don't have looping constructs in Elm. The only thing you can do is recursion, which, you know, it's been a long time since CS classes. And you don't typically write recursion in Ruby. So I had to learn a whole new thing. And then it turns out that most people don't write recursion. There's all these other ways of doing things that you have to learn. You have to learn to do folds or to use maps and things like that.

+ +

Yeah, you're just like, oh, how do I do X in Elm? And you have to figure it out. And then maybe sometimes it turns out you're asking the wrong question. So it's like, oh, how do I do the equivalent of a for loop with array indexes in Elm to, like, iterate through a data structure? And it's like, well, kind of here's technically the way you could do that, but you would never solve a problem in that way.

+ +

You've got to learn a new way of thinking, a new way of approaching problems. And I think it was that underlying new paradigm that was really difficult to get. But once I did get it, now that I have two paradigms, I think it made me a much more solid developer.

+ +

STEPHANIE: Right. That sounds very humbling, too, to kind of have to invert what you thought you knew and just be in that, you know, beginner's mindset, which we've talked about a little bit before.

+ +

JOËL: I think in some ways now being on the other side of it, it's similar to the insights you get from speaking multiple human languages, so being bilingual or trilingual or something like that where instead of just having assumptions about, oh, this is just how language works, because that's how your personal language works, now that you have more than one example to draw on, you can be like, oh, well, here's how languages tend to do things differently. Here's how languages are similar.

+ +

And I think it gives you a much better and richer feeling for how languages work and how communication works. And similar to having multiple paradigms in programming, I think this has given me a much richer foundation now for exploring and building programs.

+ +

STEPHANIE: That's really cool. I guess that actually leads quite well into the next element, which is passion. Because once you've tried some new things, you get the information of do I like this thing, or do I not like this thing? And then from there, you know, you gravitate towards the things you are passionate about to get a deeper understanding. And it becomes less about like, oh, just testing out the waters and like, knowing, hey, like, I constantly find myself thinking about this, like, let me keep going.

+ +

JOËL: Yeah. Or sometimes, it's deciding what do I want to learn next? And you just pick something that's interesting to you without necessarily being like, oh, strategically, I think this is another paradigm that's going to expand my mind. Or this is going to make me, you know, help me get that promotion next quarter, purely based off of interest. Like, this sounds fun.

+ +

STEPHANIE: That's really interesting because I think I actually came to it from a different angle, where one thing that I think was very helpful in my learning that came just, like, completely internally, like, no one told me to do this was reading books about design patterns. And that was something that I did a couple of years into my career because I was quite puzzled, I suppose, by my day-to-day experience in terms of wanting to solve a problem or develop a feature but not having a very good framework for steps to go about it, or not feeling very confident that I had a good strategy for doing it.

+ +

It was very, for me, it felt very just kind of, like, throwing pasta to the wall and seeing what would stick. And I was really interested in reducing that pain, basically. And so that led me to read books. And, again, that was not something, like, someone was like, hey, I really think that you could benefit from this. It was just like, well, I want to improve my own experience.

+ +

And, you know, some of the ones that I remember reading (And this was based off of recommendations from others kind of when I floated the idea.) was, you know, Sandi Metz's Practical Object-Oriented Design in Ruby. Design Patterns in Ruby by Ross Olsen. Those were just, like, purely out of interest. Yeah, I guess I'm curious, for you, what fun and passion look like.

+ +

JOËL: Yeah, I think one thing that's a really fun side effect of passion learning is that I find that I tend to learn a lot faster and go a lot deeper, or I get more for every individual hour I put into learning just because passion or interest is such a multiplier.

+ +

Similar to you, I think I went through a time where I was just gobbling up everything I could see on design patterns, and code structure, things like that. Yeah, I've always been really excited about data modeling in general and how to structure programs to make them easy to change while also not putting a high maintenance burden on it, learning those trade-offs, learning those principles, learning a lot of those ideas.

+ +

I think that desire came out of some pain I felt pretty early on in my programming career, where I was just writing purely self-taught at this point from a few tutorials online. Code beyond a few hundred lines would just kind of implode under the weight of its own complexity. And so, like, I know that professional programmers are writing massively larger programs that are totally fine. So what am I missing? And so I think that sort of spurred an interest. And I've kind of been chasing that ever since. Even though I'm at the point where that is no longer a problem in my daily life, it is still an interest that I keep.

+ +

STEPHANIE: Yeah. If I were to pull out another interest of yours that I've noticed that kind of seems in the same realm of, you know, you can just chase this forever, is working incrementally, right? And just all the ways that you can incorporate that into your day-to-day. And I know that's something we've talked about a lot. But I think that's really cool because, yeah, it just comes from just a pure desire on your own front to, like, see how far you can take it.

+ +

JOËL: I think you pulled out something interesting there. Because sometimes, you have an interest in a whole new topic, and sometimes the interest is more about taking something I already know and just seeing can I take it to an extreme? What happens when I really go to the boundaries of this idea? And maybe I don't need to go there ever for a client project. But let me put up a proof of concept somewhere and try it out just for the fun of it to see can I take this idea, then push it to an extreme and see does it break at an extreme? Does it behave weirdly? And that is just an enriching journey in and of itself.

+ +

Have you ever done, like, a...maybe not a whole learning journey but, you know, taken a few hours, or maybe even, like, some time on one of our investment Fridays to just explore some random idea and try it out? And it's like, huh, that was cool; that was a journey. And then maybe you move on to something next week because it's not like a big planned thing. But you're taking a few hours to dig into something totally random.

+ +

STEPHANIE: I actually think I'm less inclined to do that than maybe you or other folks are. I find the things I choose to spend my time on do have to feel more relevant to me in the moment or at least in my day-to-day work.

+ +

And I think that actually is another excellent transition into the last couple of elements in the APPL framework that we've now coined. The next being profit or, I guess, the idea of being valuable to you in your job in that moment, I suppose. Or I guess not even in that moment, but kind of connecting what you're learning to something that would provide you value.

+ +

So I know you were talking about learning Elm, and now you're able to see all of the value that it has provided, but maybe at the time, that was a little bit less of your focus. But for me, I find that, like, a driver for how I choose to spend my time. Often it's because, yeah, for the goal of reducing pain.

+ +

Being consultants, we work on a lot of different projects, sometimes in different frameworks, or languages, or new technologies. Like, you've mentioned having to, just now, on your new client project learning how to interact with different databases, and it sounds like older software that you might not have encountered before.

+ +

And I think that ends up falling higher on my priority list depending on the timing of what I'm currently working on is, oh, like, you know, TypeScript is something that has, like, kind of come and go as my projects have shifted. And so when it comes back to working on something using it, I'm like, oh, like, I really want to focus on this right now because it has very clear value to me in the next three to six months, or however long. But I have also noticed that once I'm off of that project, that priority definitely recedes.

+ +

JOËL: Yeah, I think that plays into that final element as well of the APPL, the low risk things that are applicable today that have value right now. Those tend to be things like, oh, I see that I'm going to be scheduled on a client that needs this technology next month. Maybe I should learn that, or maybe I should refresh this idea or go a little bit deeper because this is something new that I'm going to need. So, at some point, I knew that there was a Python project coming down the line. I was like, okay, well, maybe I'm going to spend a couple of Fridays digging into some Django tutorials and compare and contrast with Rails.

+ +

STEPHANIE: The low-risk element is interesting to me because I found it to be a challenging balance to figure out how much time to invest in becoming really comfortable in a new technology. I find myself sometimes learning just enough to get what I need to get done. And then other times really feeling like, wow, like, I wish I knew this better because that would make my life easier, or I would just feel a lot better about what I'm doing. And kind of struggling with when to spend that time, especially when there's, you know, other expectations of me in terms of my delivery.

+ +

JOËL: Yeah, that almost sounds like a contrast between technologies that fall in that low-risk bucket, like, immediately useful, versus ones that fall in the passion bucket that you're interested in taking deeply and maybe even to an extreme.

+ +

STEPHANIE: That's really interesting. What I like about this list of themes that we've pulled out is that, like, one thing can fall into a number of different categories. And so it's really quite flexible.

+ +

It actually reminds me of a book that I just finished reading. The book is called Quarterlife. And the thing that stuck out to me the most is the author, who is a psychotherapist; she has basically come up with two types of people, or at least two things, that end up being really big drivers of, like, human motivation and behavior. And that's stability types and meaning types, and the goal is to have a little bit of both.

+ +

So you may be more inclined towards stability and wanting to learn the things that you need to know for your job, to do well in your role, kind of like we were talking about to reduce that pain, to feel a little more in control, or have a little more autonomy over your day to day and how you work. And then there's the seeking meaning, and when we talked about adventure and passion, it kind of reminded me of that. Like, those are things that we do because we want to feel something or understand something or because it's fun.

+ +

And ironically, this list of four things has two that kind of fall into each category. And ultimately, the author, she, you know, was very upfront about needing both in our lives. And I thought that was a really cool distinction. And it was helpful for me to understand, like, oh yeah, like, in the early years of my career, I did really focus on learning things that would be profitable, or valuable, or low risk because those were the things that I needed in my job, like, right now.

+ +

And I am now feeling stable enough to explore the meaningful aspects and feel excited by trying out things that I think I just wasn't ready for back in the day. But it actually sounds like you may kind of have a different leaning than I do.

+ +

JOËL: That is really interesting. I think what was really fascinating as you mentioned those two sort of types of people. And, in my mind, now I'm immediately seeing some kind of two-dimensional graph, and now we've got four quadrants. And so are we leaning towards stability versus...was it adventure was the other one? Or meaning.

+ +

STEPHANIE: Meaning, yes.

+ +

JOËL: So now you've got, like, your quadrant that is high stability, high meaning, low stability, high meaning, like, all those four quadrants. And maybe these four things happen to fall into that, or maybe there's some other slightly different set of qualities that you could build a quadrant for here.

+ +

One that is interesting, and I don't know how closely it intersects with this idea of stability versus meaning, is how quickly the things you learn become useful. So that low risk, like that L from APPL, those are things that are immediately useful. So you put a little bit of work learning this, and you can immediately use it on the job. In fact, that's probably why you're learning it.

+ +

Whereas me going off and learning Elm is not because we've got any clients in the pipeline using Elm. It's purely for interest. Is it going to pay off? I think most learning pays off long-term, especially if it helps you build a richer understanding of the different ways software works or helps you have new mental models, new tools for doing things. And so I think, you know, 5, 6, 7 years later, learning Elm has been one of the highest payoff things that I've done to kind of take my coding career to the next level. That being said, I would not have seen that at the time. So the payoff is much more long-term.

+ +

How do you kind of navigate when you're trying to learn something, whether you want something with a short-term payoff or a longer-term payoff?

+ +

STEPHANIE: Yeah, that's so interesting. I wonder if there was maybe someone who could have helped you identify the ways that Elm could have possibly paid off. And I know, you know, you're looking back on it in retrospect, and it's easy to see, especially after many years and a lot of deep thinking about it. But kind of referring back to this idea of seeking meaning and that just being important to feeling happy at your job, like, maybe it was just valuable because you needed to scratch that itch and to experience something that would be interesting or stimulating in that way to prevent burning out or something like that.

+ +

JOËL: Oh, I like that. So the idea that you're learning a thing, not specifically because you're expecting some payoff in the long term but because of the joy of learning, is reward in and of itself, and how that actually keeps you fresh in the moment to keep going on a career that might, you know, last 5, 10, 20, 30 years, and how that keeps you refreshed rather than like, oh, but, like, I'm going to see a payoff in five years where now, all of a sudden, I'm faced with a problem. And I can be like, ah, yes, of course, monads are what we need here. And that's a nice side effect, but maybe not the main thing you look for when you're going for something in that passion bucket.

+ +

STEPHANIE: Yeah, absolutely. To go back to your question a little bit, I had mentioned that I was wondering if there was someone who could help point out ways that your interests might be useful. And I think that would be a strategy that I would try if I find myself in that conundrum, I suppose, of, like, being like, hey, like, this is really interesting to me. I'm not able to see any super immediate benefits, but maybe I can go find an expert in this who can share with me, like, from their experience, what diving deep into that topic helped them.

+ +

And if that's something that I need to then kind of justify to a manager or just kind of explain, like, hey, this is why I'm spending my time doing this is because of this insight that I got from someone else. That would be, I think, a really great strategy if you find yourself needing to kind of explain your reasoning. But yeah, I also think it's, like, incredibly important to just have passion and joy in your work. And that should be a priority, right? Even if it's not immediately clear, the tangible or valuable to the company benefits in the current moment.

+ +

JOËL: And I think what I'm hearing is that maybe it's a bit of a false premise to say there are some things that you follow for passion that only pay off in the long term. Because if you are in it for passion, then you're getting an immediate payoff regardless. You may also get an additional payoff in the long term. But you're absolutely getting some kind of payoff immediately as well.

+ +

STEPHANIE: Yeah, I think that's true for adventure because knowing what you don't like is also really valuable information. So, if you try something and it ends up not panning out for you, you know, I think some people might feel a little bit disappointed or discouraged. They think, oh, like, they kind of wasted time. But I don't know; I think that's all part of the discovery process. And that brings you closer and closer to, yeah, knowing what you want out of your learning and your career.

+ +

JOËL: So I'm really curious now. This whole, you know, APPL framework came out of a very random conversation. Is this something that maybe you're going to take into your own sort of goal-setting moving forward? Maybe try to identify, like, okay, what is something adventurous that I want to do, something I want to do for passion, something that I think for profit, and then something low risk? And then maybe have that inform where you put some energy in the next quarter, the next year, whatever timeline you're planning for.

+ +

STEPHANIE: Yeah, I thought about this a little bit before we started recording. But one very loose goal of mine...and this actually, I think, came up a little more tangibly after coming back from RubyKaigi and being so inspired by all of the cool open-source tooling and hearing how meaningful it was for people to be working on something that they knew would have an impact on a lot of people in their development experience.

+ +

Having an impact is something that I feel very passionate about and very interested in. And the adventure part for me might be, like, dabbling a little bit into open-source tooling and seeing if there might be a project that I would be interested or comfortable in dipping my feet into.

+ +

What about you? Do you have anything in the near or long-term future that might fall into one of these buckets?

+ +

JOËL: So I do have a list of things. I don't know that I will pursue all of them or maybe any of them. But here's my kind of rough APPL here. So something adventurous, something new would be digging into the language Rust. Again, the idea is to try a completely new paradigm, something low-level, something typed, something that deals with a lot of memory, something that does well with concurrency and parallelism. These are all things that I've not explored quite as much. So this would be covering new ground.

+ +

Something that is a passion, something that's interesting to me, would be formal methods, so I'm thinking maybe a language like TLA+ or Alloy. Data modeling, in general, is something that really excites me. These techniques that I think build on some of the ideas that I have from types but that go, like, to an extreme and also in a slightly different direction are really intriguing to me. So, if there's something that maybe I'm staying up in the evenings to do, I think that might be the most intriguing thing for me right now.

+ +

Something that might be more profitable, I think, would be digging into the world of data science, particularly looking at Notebooks as a technology. Right now, when I need to crunch data, I'm mostly just doing spreadsheets. But I think there are some really cool things that we could do with Notebooks that come up in client work. I manage to do them when you're with a random command-line script or sometimes with Excel. But I think having that tool would probably be something that allows me to do that job better.

+ +

And then, finally, something low-risk that I know we could use on a client project would be digging in more into TypeScript. I know just enough to be dangerous, but we do TypeScript all the time. And so, mastering TypeScript would definitely be something that would pay off on a client project.

+ +

STEPHANIE: I love that list. Thank you for sharing.

+ +

JOËL: Also, I just want to note that there are only four things here. It doesn't fully spell APPL because there's no E at the end. And so when I see the acronym now, I think it looks like a stock ticker.

+ +

STEPHANIE: It really does. But I think it's pretty trendy to have an acronym that's basically a word or a noun but then missing a vowel so...

+ +

JOËL: Oh, absolutely. Time to register that applframework.com domain.

+ +

STEPHANIE: Yeah, I agree. I also love what you said. You called it a rough APPL. And that was very [laughs] evocative for me as well. And just thinking about an apple that someone has, like, bitten into a little bit [laughs] and has some rough edges. But yeah, I hope that people, you know, maybe find some insight into the kinds of learnings and goals that they are interested in or are thinking about. And using these themes to communicate it to other people, I think, is really important, or even to yourself. Maybe yourself first and then to others because that's how your co-workers can know how to support you.

+ +

JOËL: That's really interesting that you are thinking of it in terms of a tool for communication to others. I think when I first encountered this idea, it was more as a tool of self-discovery, trying to better understand why I was interested in different things and maybe better understanding how I want to divide up the energy that I have or the time that I have into different topics. But I can definitely see how that would be useful for communicating with team members as well.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie went to her first WNBA game. Also: Bingo. Joël's new project has him trying to bring in multiple databases to back their ActiveRecord models. He's never done multi-database setups in Rails before, and he doesn't hate it.

+ +

Stephanie shares bits from a discussion with former Bike Shed host Steph Viccari about learning goals. Four elements stood out:

+ +

Adventure (try something new)
+Passion (topic)
+Profit (from recent learnings)
+Low-risk (applicable today)

+ +

= APPL

+ +

Stephanie and Joël discuss what motivates them, what they find interesting vs. what has immediate business value, and how they advocate for themselves in these situations. They ponder if these topics can bring long-term value and discuss the impact that learning Elm had on Joël's client work.

+ +
+ + + +

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: All right, I have a new-new thing and an old-new thing to share with you today. So the new-new thing is that I went to my first WNBA game [laughs] last week, which is also my third professional sports game ever, probably. I am not a sports person. But a rather new friend of mine invited me to go with her because they are fans, and so I was like, yeah, sure. I'll try anything once. And I went, and I had a great time. It was very exciting.

+ +

I mean, I know the basic rules of basketball, right? Get the ball in the hoop. But I was very surprised to see how fast-paced it was. And, you know, I was like, wow, like, this is so much fun. There's so much going on, like, the music, you know, the crowd. It was very energizing. And then my friend actually told me that that was a pretty slow game, [chuckles] relative to how they normally go. And I was like, oh, wow, like, if that was slow, then I can't wait for a real competitive [laughs] game next time.

+ +

So that's my new-new thing. I had a good time. Will do it again. I'm just, like, a 15-minute bike ride from the stadium for our team in Chicago. It's called The Sky. That's our WNBA team. So yeah, I'm looking forward to being basketball Stephanie, I guess. [chuckles]

+ +

JOËL: That's really cool. How does the speed compare to other sports you've gone to see?

+ +

STEPHANIE: I think this is why I was interested because I've really only seen baseball, for which I know very little. And that, I think, is, like, a much slower-paced kind of sport. Yeah, I have some memories of going to, like, college football games, which also, like, quite slow. I just remember standing around for a while. [laughs] So I think basketball might be the thing for me, at least in terms of engaging my interest.

+ +

JOËL: You want something that actually engages you with the sport the whole time. It's not just a social event themed around occasionally watching someone do something.

+ +

STEPHANIE: Yes, exactly. I also enjoyed the half-time performances, you know, there was just, like, a local dance team. And I thought that was all just very fun. And, yes, I had a lot to, you know, just, like, point to and ask questions about because there was just so much going on, as opposed to sitting and waiting, at least that was my experience [laughs] at other kinds of sports games.

+ +

As for the old-new thing, now that it's summer, there is a local bar near me that does bingo every week. But it's not just normal bingo. It's called veggie bingo, which I realize is kind of confusing [chuckles] if you just, like, call it veggie bingo, but it's bingo where you win vegetables or, like, produce from local community gardens and other, you know, small batch food items. And I had a great time doing it last year. I met some new friends. It just became our weekly hangout. And so I'm looking forward to doing that again.

+ +

And, I don't know, I'm just glad I have fun things to share about what's new in my world now that the weather is warm and I'm doing stuff again. I feel like there was one point in the winter where I was coming [chuckles] onto the show and sharing how I had just gotten a heated blanket in the middle of winter, and that was the most exciting thing going on for me. So it feels good to be able to bring up some new stuff.

+ +

JOËL: Seasonality is a thing, right? And, you know, there are rhythms in life. And sometimes things are more fast-paced, sometimes they're a bit slower. That's really exciting. Did you take any produce home, or did you win anything when you went to play?

+ +

STEPHANIE: I did. I won a big bag of produce the last time that I went. At this point, it was last season. But it was right before I was about to go on vacation. So I ended up --

+ +

JOËL: Oh no.

+ +

STEPHANIE: [chuckles] Right. I ended up not being able to, you know, keep it in the fridge and just giving it away to my friends who did not win. So I think it was a good situation overall. That's my tip, is go to bingo or any kind of prize-winning hang out as a group, and then you can share the rewards. It's very exciting. Even if you don't win, you know, like, probably someone else at your table will win, and that is equally fun.

+ +

JOËL: I think the closest I've been to that experience is going to play, like, bar trivia with some friends and then winning a gift card that covers our dinner and drinks for the evening.

+ +

STEPHANIE: Yeah, yeah, that's great. I used to go to a local trivia around me too. The best part about bingo, though, is that it requires no skill at all. [laughs] I, yeah, didn't realize, again, how into these kinds of things I would be until I just tried it out. Like, that was...bingo is another thing I don't think I would have internally decided to go do. But yeah, my friends just have all these great ideas about fun things to do, and I will happily join them.

+ +

So, Joël, what's new in your world?

+ +

JOËL: So I've recently started a new client project. And one of the really interesting things that I've been doing on this project is trying to bring in multiple databases to back our ActiveRecord models. This is a Rails app. I've never done multi-database setups in Rails before. It's been a feature since Rails 6, but this is my first time interacting with that system. And, you know, it's actually pretty nice.

+ +

STEPHANIE: Really? It ended up being pretty straightforward or pretty easy to set up?

+ +

JOËL: Yeah. There's a little bit of futzing around you have to do with the database YAML configuration file. And then what you end up doing is setting up another base class for your ActiveRecord models to inherit from. So, typically, you have that application record that you would inherit from for your primary database. But for other databases, if you want a model to be backed by a table from that system, then you would have a separate base class that all of those models inherit from, and that's pretty much it. Everything else just works.

+ +

A bunch of your Rake tasks get a little bit different. So you've got to, like, configure your setup scripts and your test scripts and all that thing a little bit differently. But yeah, you can just query, do all the normal things you do with an ActiveRecord model, but it's reading from a different database.

+ +

STEPHANIE: That's really cool that it ended up being pretty painless. And I'm thinking, for the most part, as a developer, you know, working in that kind of codebase; maybe they don't really need to know too much about the details of the other databases. And they can just rely on the typical Rails conventions and things they know how to do via Rails.

+ +

Do you suspect that there might be some future where that might become a gotcha or something that someone has to debug a little further because of the multi-database setup?

+ +

JOËL: There are some infrastructure things, but I think I'm handling all of them upfront. So like I said, configuring various setup scripts, or test scripts, or CI, that kind of thing to make sure that they all work. Once that's all done, I think it should pretty much just work. And people can use them like they would normal ActiveRecord models.

+ +

The one gotcha is that you can't join models across two different databases. You can't use ActiveRecord to write a query that would try to join two tables that are in different databases because the SQL won't allow for that. So, if you're ever trying to do something like that or you have some kind of association where you're trying to do some special join, that would not work. So, if somebody attempts that, they might get an unexpected error. Other than that, I think it just keeps working as normal, and people can treat it more or less as if it's one database.

+ +

STEPHANIE: That's interesting. How do you model relationships between tables on the two different databases, then? Like, how would that work?

+ +

JOËL: I've not gotten that far yet. For some things, I imagine just it's two queries. I'm not sure if the ActiveRecord associations handle that automatically for you. I think they probably will. So you probably can get away with an association where one model lives in one database. Let's say your article lives in one database, and it has many comments that live in a different database.

+ +

Because then you would make one query to load the article, get the article ID, and then you would do another query to the second database and say, hey, find all the comments with this article ID, which is already, I think, what ActiveRecord does in one single database. It is making two queries. It's just that now those two queries are going to be two different databases rather than to a single one.

+ +

STEPHANIE: Interesting. Okay. I did think that maybe ActiveRecord did some fancy join thing under the hood. And when you mentioned that that wouldn't be possible when the two tables are on different databases, I was kind of curious about how that would work. But that makes sense. That would be really cool if it is, you know, that straightforward. And, hopefully, it just doesn't become too big of an issue that comes back to haunt someone later.

+ +

JOËL: Right. So pretty much, if there is a situation where you were relying on a JOIN, you will now have to make two separate queries and then combine the results yourself.

+ +

STEPHANIE: Right. I also want to give you kudos for doing all the good work of setting it up so that, hopefully, future developers don't have to think about it.

+ +

JOËL: Kudos to the Rails team as well. It's nice to have that just kind of built into the framework. Again, it's not something I've needed in, you know, a decade of doing Rails, but then, you know, now that I have run into a situation where I need that, it just works out of the box. So that's been really nice.

+ +

So, a couple of weeks ago, we talked about the fact that we were going through review season and that we had to fill out reviews for ourselves then also fill out peer reviews for each other. You had brought up a really interesting conversation you had about reaching out to other people and trying to get feedback on what kind of review or feedback would be helpful for them.

+ +

STEPHANIE: I did, yeah. Though, I think in this case, the person writing that feedback actually reached out to me, but certainly, it goes both ways. Spoiler alert - that person was Steph Viccari, former [laughs] host of The Bike Shed.

+ +

JOËL: So Steph also reached out to me with similar questions. And that spawned a really interesting conversation around personal goals and what it looks like, particularly when it comes to what to learn next in technology. We started discussing things, and I listed out some different things that I was interested in. And then just kind of out of nowhere, Steph just pulls out this, like, oh, I noticed these four elements. And I'm going to list them out here because it's really cool.

+ +

So these four elements were adventure, so trying something new. Passion, so something that's really exciting to you. Profit something where you can leverage some recent things that you've done to get more value out of some work you've already done. And then finally, low risk, something that would be applicable today. And it just kind of turns out that this makes a funny little acronym: APPL. And apples are often a symbol of learning. So that was kind of a fun coincidence.

+ +

STEPHANIE: I love when someone is able to just pull apart or to tease out pieces of, you know, something that you might have just, like, kind of dumped all of into a message or something, and then to get, like, a second eye to really pick out the themes is so valuable, I think. And I'm obsessed with this framework. I think we might have come across something new that could really be helpful for a lot of other people.

+ +

JOËL: It's definitely...I think it shows capacity for a higher level of thinking when someone's able to just look at a bunch of concrete things and say, wait a minute; I'm seeing some larger themes emerge from what you're talking about. And I always really appreciate it when I'm having a conversation with someone, and they're like, "Hey, I think what I'm hearing is this." And you're like, "Whoa, you're totally right. And I did not even know that that's where I was going."

+ +

STEPHANIE: Absolutely. I'd love to go through this acronym and talk about a few different things that we've learned in our careers that kind of correspond with each of these elements.

+ +

JOËL: Yeah, that sounds great. So I think, you know, the first one here is adventure, trying something new. So, what's something where you tried something new or adventurous that you think was worthwhile?

+ +

STEPHANIE: Hosting this podcast. [laughs] It was a huge adventure for me and a really big stretch, I think. And that's what the idea of adventure evokes for me is, like, maybe it's uncharted territory for you, and you might have some reservations about it. But, you know, obviously, the flip side of an adventure is how fun and exciting and just new and stimulating it can be.

+ +

And so I think, yeah, like, when I first started doing this with you, and even when you first asked me, I was pretty nervous. I was really hesitant. It took me a long time to, you know, think it over. I was like, do I want to commit to something that I have never done before, and it's, like, a pretty longer-term commitment? And I'm really glad I did it.

+ +

It's certainly been an adventure. It's, you know, got its ups and downs. You know, not every week do I feel like that went really well, like, that was a great episode. Sometimes I'm like, that was just an okay episode, [laughs] and, you know, that's fine too.

+ +

But I feel like this was really important in helping me feel more confident in sharing my technical opinions, helping me feel more comfortable just kind of, like, sharing where I am and not feeling like I should be somewhere else, like, some other level or have already known something. Like, the point is for us to share the journey week by week, and that was something that was really hard for me. So being on this Bike Shed adventure with you has been very valuable for me.

+ +

JOËL: Yeah, it's sharing these new things we've learned along the way.

+ +

STEPHANIE: Literally. Yes. What about you? Do you have something adventurous that you learned?

+ +

JOËL: I think an important inflection point where I tried something new was when I learned the Elm programming language. So I had mostly done procedural languages back in the day. And then I got into Ruby, did a lot of OO. And then I got into Elm, which is statically-typed, purely functional, all these things that are kind of opposite of Ruby in some ways. But I think it shares with Ruby that same focus on developer happiness and developer productivity. So, in some ways, I felt really at home.

+ +

But I had to learn just a whole new way of programming. And, one, it's cool. I have a new tool in my belt. And I think it's been a couple of years just learning how to use this language and how to be effective with it. But then afterwards, I spent a couple of years just kind of synthesizing the lessons learned there and trying to see, are there broader principles at play here? Are there ideas here that I can bring back to my work in Ruby?

+ +

And then maybe even are there some ideas here that intersect with some theories and things that I know from Ruby? So maybe some ways of structuring data or structuring code from functional programming where some best practices there kind of converge on similar ideas as maybe some object-oriented best practices, or maybe some ideas from test-driven development converge on similar ideas from functional programming. And I think that's where, all of a sudden, I was unlocking all these new insights that made me a better Ruby developer because I'd gone on an adventure and done something completely out of left field.

+ +

STEPHANIE: Yeah, absolutely. Do you remember what was hard about that when you first embarked on learning Elm?

+ +

JOËL: All the things you're used to doing, you just can't do. So you don't have looping constructs in Elm. The only thing you can do is recursion, which, you know, it's been a long time since CS classes. And you don't typically write recursion in Ruby. So I had to learn a whole new thing. And then it turns out that most people don't write recursion. There's all these other ways of doing things that you have to learn. You have to learn to do folds or to use maps and things like that.

+ +

Yeah, you're just like, oh, how do I do X in Elm? And you have to figure it out. And then maybe sometimes it turns out you're asking the wrong question. So it's like, oh, how do I do the equivalent of a for loop with array indexes in Elm to, like, iterate through a data structure? And it's like, well, kind of here's technically the way you could do that, but you would never solve a problem in that way.

+ +

You've got to learn a new way of thinking, a new way of approaching problems. And I think it was that underlying new paradigm that was really difficult to get. But once I did get it, now that I have two paradigms, I think it made me a much more solid developer.

+ +

STEPHANIE: Right. That sounds very humbling, too, to kind of have to invert what you thought you knew and just be in that, you know, beginner's mindset, which we've talked about a little bit before.

+ +

JOËL: I think in some ways now being on the other side of it, it's similar to the insights you get from speaking multiple human languages, so being bilingual or trilingual or something like that where instead of just having assumptions about, oh, this is just how language works, because that's how your personal language works, now that you have more than one example to draw on, you can be like, oh, well, here's how languages tend to do things differently. Here's how languages are similar.

+ +

And I think it gives you a much better and richer feeling for how languages work and how communication works. And similar to having multiple paradigms in programming, I think this has given me a much richer foundation now for exploring and building programs.

+ +

STEPHANIE: That's really cool. I guess that actually leads quite well into the next element, which is passion. Because once you've tried some new things, you get the information of do I like this thing, or do I not like this thing? And then from there, you know, you gravitate towards the things you are passionate about to get a deeper understanding. And it becomes less about like, oh, just testing out the waters and like, knowing, hey, like, I constantly find myself thinking about this, like, let me keep going.

+ +

JOËL: Yeah. Or sometimes, it's deciding what do I want to learn next? And you just pick something that's interesting to you without necessarily being like, oh, strategically, I think this is another paradigm that's going to expand my mind. Or this is going to make me, you know, help me get that promotion next quarter, purely based off of interest. Like, this sounds fun.

+ +

STEPHANIE: That's really interesting because I think I actually came to it from a different angle, where one thing that I think was very helpful in my learning that came just, like, completely internally, like, no one told me to do this was reading books about design patterns. And that was something that I did a couple of years into my career because I was quite puzzled, I suppose, by my day-to-day experience in terms of wanting to solve a problem or develop a feature but not having a very good framework for steps to go about it, or not feeling very confident that I had a good strategy for doing it.

+ +

It was very, for me, it felt very just kind of, like, throwing pasta to the wall and seeing what would stick. And I was really interested in reducing that pain, basically. And so that led me to read books. And, again, that was not something, like, someone was like, hey, I really think that you could benefit from this. It was just like, well, I want to improve my own experience.

+ +

And, you know, some of the ones that I remember reading (And this was based off of recommendations from others kind of when I floated the idea.) was, you know, Sandi Metz's Practical Object-Oriented Design in Ruby. Design Patterns in Ruby by Ross Olsen. Those were just, like, purely out of interest. Yeah, I guess I'm curious, for you, what fun and passion look like.

+ +

JOËL: Yeah, I think one thing that's a really fun side effect of passion learning is that I find that I tend to learn a lot faster and go a lot deeper, or I get more for every individual hour I put into learning just because passion or interest is such a multiplier.

+ +

Similar to you, I think I went through a time where I was just gobbling up everything I could see on design patterns, and code structure, things like that. Yeah, I've always been really excited about data modeling in general and how to structure programs to make them easy to change while also not putting a high maintenance burden on it, learning those trade-offs, learning those principles, learning a lot of those ideas.

+ +

I think that desire came out of some pain I felt pretty early on in my programming career, where I was just writing purely self-taught at this point from a few tutorials online. Code beyond a few hundred lines would just kind of implode under the weight of its own complexity. And so, like, I know that professional programmers are writing massively larger programs that are totally fine. So what am I missing? And so I think that sort of spurred an interest. And I've kind of been chasing that ever since. Even though I'm at the point where that is no longer a problem in my daily life, it is still an interest that I keep.

+ +

STEPHANIE: Yeah. If I were to pull out another interest of yours that I've noticed that kind of seems in the same realm of, you know, you can just chase this forever, is working incrementally, right? And just all the ways that you can incorporate that into your day-to-day. And I know that's something we've talked about a lot. But I think that's really cool because, yeah, it just comes from just a pure desire on your own front to, like, see how far you can take it.

+ +

JOËL: I think you pulled out something interesting there. Because sometimes, you have an interest in a whole new topic, and sometimes the interest is more about taking something I already know and just seeing can I take it to an extreme? What happens when I really go to the boundaries of this idea? And maybe I don't need to go there ever for a client project. But let me put up a proof of concept somewhere and try it out just for the fun of it to see can I take this idea, then push it to an extreme and see does it break at an extreme? Does it behave weirdly? And that is just an enriching journey in and of itself.

+ +

Have you ever done, like, a...maybe not a whole learning journey but, you know, taken a few hours, or maybe even, like, some time on one of our investment Fridays to just explore some random idea and try it out? And it's like, huh, that was cool; that was a journey. And then maybe you move on to something next week because it's not like a big planned thing. But you're taking a few hours to dig into something totally random.

+ +

STEPHANIE: I actually think I'm less inclined to do that than maybe you or other folks are. I find the things I choose to spend my time on do have to feel more relevant to me in the moment or at least in my day-to-day work.

+ +

And I think that actually is another excellent transition into the last couple of elements in the APPL framework that we've now coined. The next being profit or, I guess, the idea of being valuable to you in your job in that moment, I suppose. Or I guess not even in that moment, but kind of connecting what you're learning to something that would provide you value.

+ +

So I know you were talking about learning Elm, and now you're able to see all of the value that it has provided, but maybe at the time, that was a little bit less of your focus. But for me, I find that, like, a driver for how I choose to spend my time. Often it's because, yeah, for the goal of reducing pain.

+ +

Being consultants, we work on a lot of different projects, sometimes in different frameworks, or languages, or new technologies. Like, you've mentioned having to, just now, on your new client project learning how to interact with different databases, and it sounds like older software that you might not have encountered before.

+ +

And I think that ends up falling higher on my priority list depending on the timing of what I'm currently working on is, oh, like, you know, TypeScript is something that has, like, kind of come and go as my projects have shifted. And so when it comes back to working on something using it, I'm like, oh, like, I really want to focus on this right now because it has very clear value to me in the next three to six months, or however long. But I have also noticed that once I'm off of that project, that priority definitely recedes.

+ +

JOËL: Yeah, I think that plays into that final element as well of the APPL, the low risk things that are applicable today that have value right now. Those tend to be things like, oh, I see that I'm going to be scheduled on a client that needs this technology next month. Maybe I should learn that, or maybe I should refresh this idea or go a little bit deeper because this is something new that I'm going to need. So, at some point, I knew that there was a Python project coming down the line. I was like, okay, well, maybe I'm going to spend a couple of Fridays digging into some Django tutorials and compare and contrast with Rails.

+ +

STEPHANIE: The low-risk element is interesting to me because I found it to be a challenging balance to figure out how much time to invest in becoming really comfortable in a new technology. I find myself sometimes learning just enough to get what I need to get done. And then other times really feeling like, wow, like, I wish I knew this better because that would make my life easier, or I would just feel a lot better about what I'm doing. And kind of struggling with when to spend that time, especially when there's, you know, other expectations of me in terms of my delivery.

+ +

JOËL: Yeah, that almost sounds like a contrast between technologies that fall in that low-risk bucket, like, immediately useful, versus ones that fall in the passion bucket that you're interested in taking deeply and maybe even to an extreme.

+ +

STEPHANIE: That's really interesting. What I like about this list of themes that we've pulled out is that, like, one thing can fall into a number of different categories. And so it's really quite flexible.

+ +

It actually reminds me of a book that I just finished reading. The book is called Quarterlife. And the thing that stuck out to me the most is the author, who is a psychotherapist; she has basically come up with two types of people, or at least two things, that end up being really big drivers of, like, human motivation and behavior. And that's stability types and meaning types, and the goal is to have a little bit of both.

+ +

So you may be more inclined towards stability and wanting to learn the things that you need to know for your job, to do well in your role, kind of like we were talking about to reduce that pain, to feel a little more in control, or have a little more autonomy over your day to day and how you work. And then there's the seeking meaning, and when we talked about adventure and passion, it kind of reminded me of that. Like, those are things that we do because we want to feel something or understand something or because it's fun.

+ +

And ironically, this list of four things has two that kind of fall into each category. And ultimately, the author, she, you know, was very upfront about needing both in our lives. And I thought that was a really cool distinction. And it was helpful for me to understand, like, oh yeah, like, in the early years of my career, I did really focus on learning things that would be profitable, or valuable, or low risk because those were the things that I needed in my job, like, right now.

+ +

And I am now feeling stable enough to explore the meaningful aspects and feel excited by trying out things that I think I just wasn't ready for back in the day. But it actually sounds like you may kind of have a different leaning than I do.

+ +

JOËL: That is really interesting. I think what was really fascinating as you mentioned those two sort of types of people. And, in my mind, now I'm immediately seeing some kind of two-dimensional graph, and now we've got four quadrants. And so are we leaning towards stability versus...was it adventure was the other one? Or meaning.

+ +

STEPHANIE: Meaning, yes.

+ +

JOËL: So now you've got, like, your quadrant that is high stability, high meaning, low stability, high meaning, like, all those four quadrants. And maybe these four things happen to fall into that, or maybe there's some other slightly different set of qualities that you could build a quadrant for here.

+ +

One that is interesting, and I don't know how closely it intersects with this idea of stability versus meaning, is how quickly the things you learn become useful. So that low risk, like that L from APPL, those are things that are immediately useful. So you put a little bit of work learning this, and you can immediately use it on the job. In fact, that's probably why you're learning it.

+ +

Whereas me going off and learning Elm is not because we've got any clients in the pipeline using Elm. It's purely for interest. Is it going to pay off? I think most learning pays off long-term, especially if it helps you build a richer understanding of the different ways software works or helps you have new mental models, new tools for doing things. And so I think, you know, 5, 6, 7 years later, learning Elm has been one of the highest payoff things that I've done to kind of take my coding career to the next level. That being said, I would not have seen that at the time. So the payoff is much more long-term.

+ +

How do you kind of navigate when you're trying to learn something, whether you want something with a short-term payoff or a longer-term payoff?

+ +

STEPHANIE: Yeah, that's so interesting. I wonder if there was maybe someone who could have helped you identify the ways that Elm could have possibly paid off. And I know, you know, you're looking back on it in retrospect, and it's easy to see, especially after many years and a lot of deep thinking about it. But kind of referring back to this idea of seeking meaning and that just being important to feeling happy at your job, like, maybe it was just valuable because you needed to scratch that itch and to experience something that would be interesting or stimulating in that way to prevent burning out or something like that.

+ +

JOËL: Oh, I like that. So the idea that you're learning a thing, not specifically because you're expecting some payoff in the long term but because of the joy of learning, is reward in and of itself, and how that actually keeps you fresh in the moment to keep going on a career that might, you know, last 5, 10, 20, 30 years, and how that keeps you refreshed rather than like, oh, but, like, I'm going to see a payoff in five years where now, all of a sudden, I'm faced with a problem. And I can be like, ah, yes, of course, monads are what we need here. And that's a nice side effect, but maybe not the main thing you look for when you're going for something in that passion bucket.

+ +

STEPHANIE: Yeah, absolutely. To go back to your question a little bit, I had mentioned that I was wondering if there was someone who could help point out ways that your interests might be useful. And I think that would be a strategy that I would try if I find myself in that conundrum, I suppose, of, like, being like, hey, like, this is really interesting to me. I'm not able to see any super immediate benefits, but maybe I can go find an expert in this who can share with me, like, from their experience, what diving deep into that topic helped them.

+ +

And if that's something that I need to then kind of justify to a manager or just kind of explain, like, hey, this is why I'm spending my time doing this is because of this insight that I got from someone else. That would be, I think, a really great strategy if you find yourself needing to kind of explain your reasoning. But yeah, I also think it's, like, incredibly important to just have passion and joy in your work. And that should be a priority, right? Even if it's not immediately clear, the tangible or valuable to the company benefits in the current moment.

+ +

JOËL: And I think what I'm hearing is that maybe it's a bit of a false premise to say there are some things that you follow for passion that only pay off in the long term. Because if you are in it for passion, then you're getting an immediate payoff regardless. You may also get an additional payoff in the long term. But you're absolutely getting some kind of payoff immediately as well.

+ +

STEPHANIE: Yeah, I think that's true for adventure because knowing what you don't like is also really valuable information. So, if you try something and it ends up not panning out for you, you know, I think some people might feel a little bit disappointed or discouraged. They think, oh, like, they kind of wasted time. But I don't know; I think that's all part of the discovery process. And that brings you closer and closer to, yeah, knowing what you want out of your learning and your career.

+ +

JOËL: So I'm really curious now. This whole, you know, APPL framework came out of a very random conversation. Is this something that maybe you're going to take into your own sort of goal-setting moving forward? Maybe try to identify, like, okay, what is something adventurous that I want to do, something I want to do for passion, something that I think for profit, and then something low risk? And then maybe have that inform where you put some energy in the next quarter, the next year, whatever timeline you're planning for.

+ +

STEPHANIE: Yeah, I thought about this a little bit before we started recording. But one very loose goal of mine...and this actually, I think, came up a little more tangibly after coming back from RubyKaigi and being so inspired by all of the cool open-source tooling and hearing how meaningful it was for people to be working on something that they knew would have an impact on a lot of people in their development experience.

+ +

Having an impact is something that I feel very passionate about and very interested in. And the adventure part for me might be, like, dabbling a little bit into open-source tooling and seeing if there might be a project that I would be interested or comfortable in dipping my feet into.

+ +

What about you? Do you have anything in the near or long-term future that might fall into one of these buckets?

+ +

JOËL: So I do have a list of things. I don't know that I will pursue all of them or maybe any of them. But here's my kind of rough APPL here. So something adventurous, something new would be digging into the language Rust. Again, the idea is to try a completely new paradigm, something low-level, something typed, something that deals with a lot of memory, something that does well with concurrency and parallelism. These are all things that I've not explored quite as much. So this would be covering new ground.

+ +

Something that is a passion, something that's interesting to me, would be formal methods, so I'm thinking maybe a language like TLA+ or Alloy. Data modeling, in general, is something that really excites me. These techniques that I think build on some of the ideas that I have from types but that go, like, to an extreme and also in a slightly different direction are really intriguing to me. So, if there's something that maybe I'm staying up in the evenings to do, I think that might be the most intriguing thing for me right now.

+ +

Something that might be more profitable, I think, would be digging into the world of data science, particularly looking at Notebooks as a technology. Right now, when I need to crunch data, I'm mostly just doing spreadsheets. But I think there are some really cool things that we could do with Notebooks that come up in client work. I manage to do them when you're with a random command-line script or sometimes with Excel. But I think having that tool would probably be something that allows me to do that job better.

+ +

And then, finally, something low-risk that I know we could use on a client project would be digging in more into TypeScript. I know just enough to be dangerous, but we do TypeScript all the time. And so, mastering TypeScript would definitely be something that would pay off on a client project.

+ +

STEPHANIE: I love that list. Thank you for sharing.

+ +

JOËL: Also, I just want to note that there are only four things here. It doesn't fully spell APPL because there's no E at the end. And so when I see the acronym now, I think it looks like a stock ticker.

+ +

STEPHANIE: It really does. But I think it's pretty trendy to have an acronym that's basically a word or a noun but then missing a vowel so...

+ +

JOËL: Oh, absolutely. Time to register that applframework.com domain.

+ +

STEPHANIE: Yeah, I agree. I also love what you said. You called it a rough APPL. And that was very [laughs] evocative for me as well. And just thinking about an apple that someone has, like, bitten into a little bit [laughs] and has some rough edges. But yeah, I hope that people, you know, maybe find some insight into the kinds of learnings and goals that they are interested in or are thinking about. And using these themes to communicate it to other people, I think, is really important, or even to yourself. Maybe yourself first and then to others because that's how your co-workers can know how to support you.

+ +

JOËL: That's really interesting that you are thinking of it in terms of a tool for communication to others. I think when I first encountered this idea, it was more as a tool of self-discovery, trying to better understand why I was interested in different things and maybe better understanding how I want to divide up the energy that I have or the time that I have into different topics. But I can definitely see how that would be useful for communicating with team members as well.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Yp84qhcB + + ]]> + + Joël Quenneville + Stephanie Minn + + + 390: The Truth about Truthiness + https://bikeshed.thoughtbot.com/390 + b2a40fb1-4b59-456b-b947-43943a9f53cf + Tue, 27 Jun 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël's new work project involves tricky date formats. Stephanie has been working with former Bike Shed host Steph Viccari and loved her peer review feedback. + +The concept of truthiness is tough to grasp sometimes, and JavaScript and Ruby differ in their implementation of truthiness. + +* Is this a problem? +* Do you prefer one model over the other? +* What can we learn about these design decisions? +* How can we avoid common pitfalls? + 39:58 + no + + + Joël's new work project involves tricky date formats. Stephanie has been working with former Bike Shed host Steph Viccari and loved her peer review feedback. +The concept of truthiness is tough to grasp sometimes, and JavaScript and Ruby differ in their implementation of truthiness. +Is this a problem? +Do you prefer one model over the other? +What can we learn about these design decisions? +How can we avoid common pitfalls? +[EDI](https://www.stedi.com/blog/date-and-time-in-edi](https:/www.stedi.com/blog/date-and-time-in-edi) +[Booleans don’t exist in Ruby](https://thoughtbot.com/blog/what-is-a-boolean](https://thoughtbot.com/blog/what-is-a-boolean) +[Rails valid? method](https://api.rubyonrails.org/classes/ActiveRecord/Validations.html#method-i-valid-3F](https://api.rubyonrails.org/classes/ActiveRecord/Validations.html#method-i-valid-3F) +Parse, don’t validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) +Javascript falsiness rules (https://www.sitepoint.com/javascript-truthy-falsy/) +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 little bit of what we've learned along the way. +STEPHANIE: So, Joël, what's new in your world? +JOËL: So I'm on a new project at work. And I'm doing some really interesting work where I'm connecting to a remote database third-party system directly and pulling data from that database into our system, so not via some kind of API. And one thing that's been really kind of tricky to work with are the date formats on this third-party database. +STEPHANIE: Is the date being stored in an unexpected format or something like that? +JOËL: Yes. So there's a few things that are weird with it. So this is a value that represents a point in time, and it's not stored as a date-time value. Instead, it's stored separately as a date column and a time column. So a little bit of weirdness there. We can work with it, except that the time column isn't actually a time value. It is an integer. +STEPHANIE: Oh no. +JOËL: Yeah. And if you're thinking, oh, okay, an integer, it's going to be milliseconds since midnight or something like that, which is basically how Postgres' time of day works under the hood, nope, that's not how it works. It's a positional digit thing. So, if you've got the number, you know, 1040, that means 10:40 a.m. +STEPHANIE: Oh my gosh. Is this in military time or something like that, at least? +JOËL: Yes, it is military time. But it does allow for all these, like, weird invalid values to creep in. Because, in theory, you should never go beyond 2359. But even within the hours that are allowed, let's say, between 1000 and 1100, so between 10:00 and 11:00 a.m., a clock only goes up to 59 minutes. But our base 10 number system goes up to 99, so it's possible to have 1099, which is just an invalid time. +STEPHANIE: Right. And I imagine this isn't validated or anything like that. So it is possible to store some impossible time value in this database. +JOËL: I don't know for sure if the data is validated or not, but I'm not going to trust that it is. So I have to validate it on my end. +STEPHANIE: That's fair. One thing that is striking me is what time is zero? +JOËL: So zero in military time or just 24-hour clocks in general is midnight. So 0000, 4 zeros, is midnight. What gets interesting, though, is that because it's an integer, if you put the number, you know, 0001 into the database, it's just going to store it as 1. So I can't even say, oh, the first two digits are the hours, and the second two digits are the minutes. And I'm actually dealing with, I think, seconds and then some fractional part of seconds afterwards. But I can't say that because the number of digits I have is going to be inconsistent. +So, first, I need to zero pad. Well, I have to, like, turn it into a string, zero pad the numbers so it's eight characters long. And then, start slicing out pairs of numbers, converting them back into integers, validating them within a range of either 0 to 23 or 0 to 59, and then reconstructing a time object out of that. +STEPHANIE: That sounds quite painful. +JOËL: It's a journey for sure. +STEPHANIE: Do you have any idea why this is the case or why it was created like this originally? +JOËL: I'm not sure. I have a couple of theories. I've seen this kind of thing happen before. And I think it's a common way for developers who maybe haven't put a lot of thought into how time works to just sort of think, oh, the human representation. I need something to go in the database. On my digital clock, I have four digits, so why not put four digits in the database? Simple enough. And then don't always realize that there's all these edge cases to think about and that human representations aren't always the best way to store data. +STEPHANIE: I like how you just said that that, you know, we as humans have developed systems that are not quite, you know, the same as how a computer would. But what was interesting to me...something you said earlier about time being a fixed point. And that is different from time being a value, right? And so here in this situation, it sounds like we're storing time as a value, but really, it's more of the idea of, like, a point. +JOËL: Interesting. What is the difference for you between a point and a value? +STEPHANIE: I suppose a value to me...And I think we talked about this a little bit on a previous episode about value objects and also how we stored numbers, like phone numbers and credit card numbers and stuff like that. But a value, like, I might want to do math on. But I don't really want to do math on time. Or, specifically, if I have this idea of a specific point in time, like, that is fixed and not something that I could mutate and expect it to be the same thing that I was trying to express the first time around. +JOËL: Oh, that's interesting because I think when it comes to time and specifically points in time, I sometimes do want to do math on them. And so, specifically, I might want to say, what is the time that has elapsed between two points in time? Maybe I have a start time and an end time, and I want to say how much distance is there between the two? If you use this time system where you're storing it as an integer number where the digits have positional values, because there's all those gaps between, you know, 59 and 99 that are not valid, math breaks down. You've broken math by storing it that way. +So you can't get an accurate difference by doing math on that, as opposed to if you store it as a counter, which is what databases do under the hood, but you could do manually. If you just wanted to use an integer column, then you can do math because it's just a number of seconds since the beginning of the day. And you can subtract those from each other. And now you have these number of seconds between the two of them. And if you want them in minutes or hours, you divide by six here, 3600, and you get the correct response. +STEPHANIE: Yeah, that is really interesting because [chuckles] in this situation, you have the worst of both worlds, it seems like. [laughs] +JOËL: The one potential benefit is, I think, it's maybe more human-readable. Although, at that point, I would say if you're not doing math on it and you want something human-readable, you probably don't want an integer. You probably want a string. And maybe you even store it as, like, ISO 8601 time string in the database, or even just hour:minute:second split by a colon or whatever it is but just as a string. Now it's human-readable. +You can still sort by it if you go from largest to smallest increment in your format. You can't do math, but then you weren't doing math on it anyway. So that's probably a nice compromise solution. But, ideally, you'd use a native, you know, time of day column or a date-time or something like that. +STEPHANIE: For sure. Well, it sounds like something fun to contend with. [laughs] +JOËL: One thing that was brought to my attention that I'd never heard about before is that potentially a reason it's stored that way is because of an old data format called EDI—I think it's Electronic Data Interchange—that dates from ages ago, you know, the '60s or '70s, something like that. Before, we had a lot of standards for data; this is how...an emerging standard that came for moving data between systems. And it has a lot of, like, weird things with the way it's set up. +But if you're dealing with any sort of older data warehouses or older business systems, they will often exchange. And sometimes, you're going to store data in something that approximates this older EDI format. And, apparently, it has some weirdness around dates where it kind of does something like this. +So someone was suggesting, oh, well, if you're interacting with maybe an older, you know, a lot of, like, e-commerce platforms or banking systems, probably airline systems, the kind of things you'd expect to be written in, let's say, COBOL... +STEPHANIE: [laughs] +JOËL: Have a system that's kind of like this. So maybe that wouldn't be quite as surprising. +STEPHANIE: Yeah, that is really interesting. It just sounds like sometimes you're limited by the technology that you're interacting with. And I guess the one plus side is that, in your system, you can make the EDI work for you, hopefully. [laughs] Whereas perhaps if you are talking to some of those older technologies that don't know how else to convert date types and things like that, like, you just kind of have to work with what's available to you. +JOËL: Yeah. And that's got me realizing that a lot of these older, archaic systems are still online and very much a part of our software ecosystem and that there's a lot of value in learning some software history so that I'm able to recognize them and sort of work constructively with them when I have to interact with that kind of system. +STEPHANIE: Yeah, I really like that mindset. +JOËL: So, Stephanie, what's new in your world? +STEPHANIE: So, last week, we talked about writing reviews for ourselves and our peers. And one thing that happened in between the last episode and this one is Steph Viccari, former co-host of this podcast, who I've been working with really closely on this project of mine; she was writing a peer review for me. And one thing that she did that I really loved was she sent me a message and asked me a few questions about the direction of the review that I was wanting and what kind of feedback would be helpful for me. +And some of the things she asked were, you know, "Is there a skill that you're actively working on? Is there a skill you'd like to start working on?" And, like, what my goals are for the feedback. Like, how can she tailor this feedback to things that would help my progression and what I hope to achieve? And then my favorite question that she asked was, "What else should I know but didn't think to ask?" And I thought that was a really cool way of approaching. +You know, she's coming to this, like, wanting to be helpful, but then even still, like, there are things that she knows that I am kind of the expert on in my own career progression, and I really liked that. I think I'd mentioned last week that part of the feedback you want to be giving is, you know, something that will be helpful for that person, and centering them in it, instead of you is just a really awesome way to do that. So I was very appreciative that she asked me those questions. +JOËL: That's incredibly thoughtful. I really appreciate that she sent that out to you. What did you respond for the is there something else I should know but didn't know to ask? +STEPHANIE: Yeah. I mentioned that more and more, I'm realizing that I am not interested in management. And so what would be really helpful for me was to ground most of the feedback in terms of my, like, technical contributions. And also, that one thing that I'm thinking about a lot is how to be an individual contributor and still have an impact on team health and culture because that is something I care about. And so I wanted to share that with her because if there are things that she can identify in those aspects, that would be really awesome for me. And that can kind of help guide her away from a path that I'm not interested in. +JOËL: I think having that kind of self-awareness is really powerful for yourself. But then, when you can leverage that to get better reviews that will help you get even further down the path that you're hoping to go, and, wow, isn't that just, like, a virtuous cycle right there that's just building on itself? +STEPHANIE: Yeah, for sure. I think the other thing I wanted to share about what's new in my world that has been just a real boost to my mood is how long the days are right now because it's summer in North America. And yesterday was the summer solstice, and so we had the longest day of the year. The sun didn't set until 8:30 p.m. And I just took the opportunity to be outside. I took a swim in the lake, which was my first swim of the season, which was really special. And my friend had just a nice, little, like, backyard campfire hang out. And we got to roast some marshmallows and just be outside till the sunset. And that was really nice. +JOËL: When you say the lake, is that Lake Michigan? +STEPHANIE: Yes, I do mean Lake Michigan. [laughs] I forget that some people just don't have a giant lake next to them [laughs] that they refer to as the lake. +JOËL: It's practically an inland sea. +STEPHANIE: Yes, you can't see the other side of it. So, to me, it kind of feels like an ocean. And yesterday, when I was in the water, I also was thinking that I felt like I was just in a giant bathtub. [chuckles] +JOËL: So I'm in New England, and most of the bodies of water here are not called lakes. They're called ponds. +STEPHANIE: Really? +JOËL: No matter the size. +STEPHANIE: Oh. +JOËL: I guess lakes is reserved for things like what you have that are absolutely massive, and everything else is a pond. +STEPHANIE: That's so funny because I think of ponds as much smaller in scale, like a quaint, little pond. But that's a really fun piece of regional vocabulary. +So one interesting thing happened on my client project this week that I wanted to get your input on because I've definitely seen this problem before, and still, it continues to crop up. But I was working on a background job that we were passing a Boolean value into as one of the parameters that we would then, you know, use down the line in determining some logic. +And we, you know, made this change, and then we were surprised to find out that it continued to not work the way we expected. So we got some bug reports that we weren't getting into one of the branches of the conditional based on that Boolean value that we were passing in. And we learned, after a little bit of digging, that it turns out that those values are serialized because this job is actually saved in -- +JOËL: Oh no. +STEPHANIE: [chuckles] Yeah. It inherits from the ActiveRecord, actually, and is saved in our database. And so, in that process, the Boolean value got serialized into a string and then did not get converted [chuckles] back into a Boolean. And so when we do that if variable check, it was always evaluating to true because strings are truthy in Ruby. +JOËL: Right. The string false is still truthy. +STEPHANIE: A string false is still truthy. And we ended up having to coerce it into a Boolean value to fix our little bug. But it was just one of those things that was really frustrating, you know when you feel really confident that you know what you're doing. You're just writing a conditional statement. And it turns out the language beguiled you. [laughs] +JOËL: I've run into similar bugs when I'm reading from environment variables because environment variables are always strings. But it's common that you'll be setting some kind of flag. So when you're setting the environment variable, you're setting something to true or false. But then, when you're reading it, you have to explicitly check if this environment variable double equals the string true, then do the thing. Because if you just check for the value, it will never be false. +STEPHANIE: Right. And I kind of hate seeing code like that. I don't know; something about it just rubs me the wrong way because it just seems so strange, I suppose. +JOËL: Is it just, like, those edge cases where you specifically have to do some kind of, like, double equals check on a value that feels like it should be a Boolean? Or do you kind of feel a bit weird about the concept of truthiness in general? +STEPHANIE: I think the concept of truthiness is very hard to grasp sometimes. And, you know, when you're talking about that edge case where we are setting...we're checking if the string is the string true. That means that everything else is false, right? So, in some ways, I think it's just really confusing because we've expanded the definition of what true and false mean to be anything. +JOËL: That's really interesting because now you have to pick. Are you checking against the string true, or are you negatively checking against the string false? And those are not equivalent because, like you said, now you're excluding every other string. So, is the string "Hello, World" put you in the false branch or the true branch? +STEPHANIE: Who's to say? [laughs] I think a similar conundrum also occurs when we use predicate matchers in our tests. I think this is a gripe that I've talked about a little bit with others when we're writing tests and especially if we're writing a predicate method, and then that's what we're testing, right? We kind of are expecting a true or false value. +And when our test expects something to be truthy rather than explicitly saying that we expect the return value to be true, that is sometimes a bit confusing to me as well because someone could theoretically change this method and just have it return "Hello, World," like you said, as a string, like, anything else. And that would still pass the test. +JOËL: And it might even pass your code in most places. +STEPHANIE: Right. And I suppose that's okay. Is it okay? I don't know. I'm not sure where I land on this. +JOËL: I used to be a kind of hardcore Boolean person. +STEPHANIE: [laughs] That's a sentence no one has ever [laughs] said. +JOËL: I like my explicit trues and falses. I don't like the ambiguity of saying, like, oh, if person do a thing, it's, like, oh, what is person here? Is this a nil check? Is it explicitly false? Do you just want to know that this person is non-empty? Well, what exactly are you checking? So I like the explicitness of saying, oh, if person dot present, or if person dot empty, or if person dot nil. +And I think maybe spending some time in some more strongly typed languages has also kind of pushed me a little bit in that direction, where it's nice to have something that is explicitly either just true or just false. And then you completely eliminate that problem of, like, oh, but what if it's neither true nor false, then what do we do for that branch there? And the answer is your compiler will reject that program or say, "You've written a bad program." And you never reach that point where there's a bug. +I've slowly been softening my stance. A fellow thoughtbot colleague has written an article why there is no such thing as a Boolean in Ruby. Everything is just shades of gray and truthiness and falsiness. But from the perspective of a program, there is no such thing as a Boolean. And that really opened my eyes to a different perspective. I don't know that I fully agree, but I'm kind of begrudgingly acknowledging that Mike makes a good point. +STEPHANIE: Yes, I read the blog post that he wrote about this exact problem. And I think it's called "Booleans Don't Exist in Ruby." And I think I similarly, like, came away with, like, yeah, I think I get it if I just suspend my disbelief, you know, hard enough. [laughs] But what you were saying about, like, liking the explicitness, right? And liking the lack of ambiguity, right? Because when you start to believe that Booleans don't exist, I think that really messes with your [laughs] head a little bit. +And one takeaway that I got from that blog post, kind of like we mentioned earlier, is that there is such thing as false, and then everything else is true. And I guess that's kind of how Ruby operates. +JOËL: Sort of, because then you have the problem of nil, which is also falsy. +STEPHANIE: That's true, but nil is nothing. [laughs] +JOËL: That's one of the classic problems as well when you're trying to do a nil check, or maybe some memoization, or maybe even, say, cache this value, or store this value, or initialize this value if it's not set. And assuming that doing nil is falsy, so you'll do some kind of, like, or equals, or just some kind of expression with an or in it thinking, oh, do this extra work if it's nil because then it will trigger the branch. But that all breaks down if potential for your value to be false because false and nil get treated the same in conditional code. +STEPHANIE: Right. I think this could be a whole separate conversation about nil and the idea of nothingness. But I do think that, as Ruby developers, at least in the Ruby world, based on what I've seen, is that we lean on nil in ways that we maybe shouldn't. And we end up having to be very defensive about this idea of nil being falsy. But that's because we aren't necessarily thinking as hard about our return values and what our arguments are that; it ends up causing problems in evaluating truthiness when we're having to check those objects that could be nil. +JOËL: In terms of the way we communicate with the readers of our code, and, as a reader, I generally assume that a Ruby method that ends with a question mark will return a true Boolean, either true or false. Is that generally your expectation as well? +STEPHANIE: I want to say yes, but I've clearly experienced enough times where that's not the case that, you know, it's like, my ideal world and then reality [laughs] and having to figure out how to hold both of those things. +JOËL: It's one of those things that's mostly true. +STEPHANIE: I want to believe it because predicate methods and, like, the Ruby Standard Library mostly return Boolean values, at least to my knowledge. And if we all kind of followed that [laughs] pattern, then it would be clear. But I think there's a part of me that these days mostly believes it to be true that I will be getting a Boolean value (And, wow, even as I say this, I realize how confusing [laughs] this is starting to sound.) and that until I'm not, right? Until I'm surprised at some point. +JOËL: I think there's two things I expect of predicate methods in Ruby. One is that they will return, like, a hard Boolean, either true or false. The second is that they are purely query methods; they don't do side effects. Neither of those are consistent across the ecosystem. +And a classic example of violating that second guideline I have in my mind is the valid question mark method from Rails. And this really surprised me the first time I tripped into this because when you call that on an object, it doesn't just tell you whether or not the object is valid. It actually mutates the underlying object by populating the error messages' hash. So if you have an invalid object and you examine its error messages' hash, it will be empty until you call the valid question mark method. +So sometimes, you don't even care about the return value. You're just calling valid to mutate the object so that you can access the underlying hash, which is that's weird code when you call a predicate method but then totally ignore the output. +STEPHANIE: Yeah, that is strange because I have definitely seen it where we are calling the valid method to validate, and then we end up using the error messages that are set on that object later. I think that's tough because, in some ways, you do care about whether the object is valid or not. But then also, the error messages are helpful usually and when you're trying to use that method. The point is to validate it so that you can hopefully, like, tell the user or, like, the consumer of your system, like, what's wrong in validation. But it is almost, like, two separate things. +JOËL: It is. And sometimes, it's really hard to split those two apart. So I'm not throwing shade at the Rails dev team here. Some of these design decisions are legitimately difficult to make. And what's most useful for the most people the most time is often a compromise. I think you brought up the idea of separating those two things. And I think there's a general principle here called command-query separation. That's, like, the fancy way of talking about what you were saying. +STEPHANIE: One thing that I was just thinking about kind of when we initially picked off this conversation was the idea of how things outside the Ruby ecosystem or the Ruby world interact with what we're returning in terms of Boolean values. And so when I mentioned the object being serialized because of, you know, our database and, like, background job system, that's an entity that's figuring out what to do with the things that we are returning from Ruby. +And similarly, when you're talking about environment variables, it's like, our computer system talking to now our language and those things being a bit different. Because when we, like, suspend our disbelief about what is truthy or falsy in Ruby, at least we're doing it in, like, the world of Ruby. And as soon as we have to interact with something else, like, maybe that's when things can get a little hairy because there's different ideas about truthiness there. And so I'm kind of also thinking about what we return in APIs and maybe, like, that being an area where some explicitness is more required. +JOËL: Whenever I'm consuming third-party data, I'm a big fan of having some kind of transformation or parse step. This is inspired in part by the "Parse, Don't Validate" article, which I'll link in the show notes. So, if I'm reading data from a third-party API and I want it to be a Boolean, then maybe I should do the transformation myself. So maybe I check literally, is it the string true or the string false, and anything else gets rejected? +Maybe I have...and maybe I'm a little bit more permissive, where I also accept capital T or capital F, and I have, like, some rules for transforming that. But the important thing is I have an explicit conversion step and reject any bad output. And so for something like an environment variable, maybe that would look like looking for true or false and raising if anything else is there. So that we try to boot the app, and it immediately crashes because, hey, we've got some, like, undefined, like, bad configuration that we're trying to load the app with. Don't even try to keep running. Hard crash immediately. Fix it, and then come back. +STEPHANIE: Yeah, I like that a lot because the way we ended up fixing this issue with the background job that I mentioned was just coercing our string value into a Ruby Boolean in the job that we were then, like, running the conditional in. But really, what we should have done is have fixed that at a higher level and where we parse and deserialize, like, the values we're getting from the job to prevent this kind of in the future because right now, someone can do this again, and that's a real bummer. +JOËL: I always love those deeper conversations that happen after you've had a bug that are like, how do we prevent this from happening again? Because sometimes that's where you have the deepest learnings or the most interesting insights or, you know, ideas for Bike Shed episodes. +I'm really curious to contrast JavaScript's approach to truthiness to Ruby's because even though they both use the same idea, they kind of go about it differently. +STEPHANIE: Tell me more. +JOËL: So, in Ruby, an empty array and an empty string are truthy. JavaScript decided that empty things are falsy. And I forget...there's a whole table that shows the things that are truthy and falsy in JavaScript. I want to say zero is falsy in JavaScript but don't quote me on that, which can also lead to some interesting edge cases you have to think about. +STEPHANIE: Okay, yes. This is coming back to me now. I think depending on what, you know, ecosystem or language or world I'm in, I have to just only be able to think about what is true in this world [laughs] and then do that context switching when I am working in something else. But yeah, that is a really interesting idea. Someone decided [laughs] that this was their idea of true or false. +JOËL: I'm curious if you have a preference for sort of JavaScript's approach to falsiness where a lot more types of values are falsy versus Ruby, which said pretty much only nil and false are falsy. Everything else is truthy. +STEPHANIE: Hmm, that is an interesting question. +JOËL: Because in Ruby then or, I guess, in Rails, we end up with the present predicate method that is specifically checking for not only nil and false but also for empty array, empty string, those kinds of things. So, if you find yourself writing a lot of present matchers in your code, you're kind of leaning on something that's closer to JavaScript's definition of falsiness than Ruby's. But maybe you're making it more explicit. +STEPHANIE: Right. In JavaScript, I see a lot of double bangs in lieu of those predicate methods. But I suppose by nature of having to write those predicate methods in Ruby, we're, like, really wanting something else, I think. And maybe...I guess it is just a question of explicitness like you're saying, and which I prefer. Is it that I need to be explicit to convey the idea that I want, or is it nice that the language has just been encoded that way for me? +JOËL: Or maybe when you write conditionals, if you find yourself doing a lot of presence checks, do you find that you typically are trying to branch on if not null, not false, not empty more frequently than just if not null, not false? Because that's kind of the difference between Ruby's model and JavaScript's model. +STEPHANIE: Hmm, the way you posed that question is interesting because it makes me think that sometimes it's quite defensive because we have to check for all these possible return values. We are unsure of what we are getting back. And so this is kind of, like, a catch-all for things that we aren't really sure about. +JOËL: Yeah, I mean, that's the fun of dynamic programming languages. You never know exactly what you're going to get as long as things respond to certain methods. You really lean into the duck typing. And I think that's Mike's argument in his article that "Booleans Don't Exist" in that as long as something is responding to methods that you care about, it doesn't matter if you're dealing with a true Boolean or some kind of other value. +STEPHANIE: Right. So I suppose the ideas of truthiness then are a little bit more dependent on how people are using the language though it seems like a chicken-and-egg situation to me. [laughs] +JOËL: It is really interesting to me in terms of maybe thinking about use cases in my own code if I'm having to...if I'm writing code that leans on truthiness where I can say just, you know if user. But then knowing that, oh, that doesn't account for, like, an empty value. Do I then also need to add an extra check for emptiness? And maybe if I'm in a Rails project, I would reach for that present matcher where I wouldn't have to do that in JavaScript because I can just say, if user, and that already automatically checks for presence. +So I'm kind of wondering now in my mind, like, which default would fit my use cases more? Or, if I go back to an older version of myself, I will say I don't want any of these defaults. They're all too ambiguous. I'm going to put explicitly if user dot nil question mark, if that's the thing that I'm checking for, or if user dot empty question mark because I want my reader to know what condition I'm checking. +STEPHANIE: Yeah, that is interesting, this idea of, like, which mode do you find yourself needing to use more and if that is accommodated for you because that's just the more common, like, use case or problem. +I think that's something that I will be thinking about the next time I write a conditional [laughs] because, like I was saying earlier, I think I end up just leaning on what someone else has decided for me in terms of truthiness and not so much how I would like it to work for me. +JOËL: And sometimes we don't want to fight the language too much, you know if I'm writing Elm, that everything is hard Booleans. And I know I'm never going to get a nil in a place where I'd expect true or false because the compiler would prevent that from happening. I know that I'm not going to get an empty value, potentially. +There's ways you can do things with a type system where you can explicitly say no empty values are even allowed at this point. And if you do allow them, then the type system will say, "Hey, you forgot to check for the empty case. Bad program. I'm rejecting that." And then you have to write that explicit branch for, oh, if empty versus if present. So I really appreciate that style of programming. +But then, when you're in a language like Ruby where you're not dealing with explicit types on purpose, how do you shift that mindset so that you don't need to know the type of the value that you're dealing with? You only want to say, hey, in this context, here's the minimal interface that I want it to conform to. And maybe it's just the truthy or falsiness interface, and everything beyond that is not relevant. +STEPHANIE: I think it's kind of wild to me that this idea of a binary that theoretically seems very clear turns out is actually quite confusing, ambiguous, philosophical, even. [chuckles] +JOËL: Yeah. It's definitely...you can get into some deep, philosophical questions there, language design as well. +One aspect, though, that I'm really curious about your thoughts is bringing new people in who are learning a language. It's really common for people who are learning a language for the first time, learning to code for the first time to write code that you and I would immediately know, like, that's not going to work. You can't add a Boolean and a number. You're just learning to code. You've never done that before. You don't know. And then how the language reacts to that kind of thing can help guide that experience. +So, do you think that truthiness maybe makes things more confusing for newcomers? Or, maybe on the other side, it helps to smooth that learning curve because you don't have to be like, oh, wait, I have a user here. I can't put that in a condition because that's not a strict true or false. I'm going to coerce it, or I've got to find a predicate method or something. You can just be like, no, put it in. The interpreter will figure it out for you. +STEPHANIE: Wow. That's a great question. I'm trying to put myself in the beginner's mindset a little bit and think about what it's like to just try something and the magic of it working. Because, like you said, the interpreter does it for you, or whatever, and something happens, and you're like, wow, like, that was really cool. And I didn't have to know all of the ins and outs of the types of things I was working with. +That can be really helpful in just getting them, like, started and getting them just, like, on the ground writing code. And having that feeling of satisfaction that, like, that they didn't have to, you know, have to learn all these things that can be really scary to make their program work. +But I do think it also kind of bites them later once they really realize [laughs] what is going on and the minute that they get that, like, unexpected behavior, right? Like, that becomes a time when you do have to figure out what might be going on under the hood. So two sides of the same coin. +JOËL: What you're saying there about, like, maybe smoothing that initial curve but then it biting them later got me thinking. You know how we have the concept of technical debt where we write code in a way that's maybe not quite as clean today so we can move faster but that then later on we have to pay it back? And I almost wonder if what we have here is almost like a pedagogical debt where it's going to cost us a month from now, but today it helps us move faster and actually kind of get that momentum going. +STEPHANIE: Pedagogical debt. I like that. I think you've coined a new term. Because I really relate to that where you learn just enough to do the thing now. But, you know, it's probably not, like, the right way or, like, the most informed—I think most informed is probably how I would best describe it—way of doing it. And later, you, yeah, just have to invest a little more into it. And I think that's okay. +I think sometimes I do tend to, like, beat myself up over something down the line when I have to deal with some piece of less-than-ideal code that I'd written earlier. Like, I think that, oh, I could have avoided this if only I knew. But the whole point is that I didn't know. [laughs] And, like, that's okay, like, maybe I didn't need to know at the time. +JOËL: Yeah, and code that's never shipped is of zero value. So having something that you could ship is better than having something perfect that you didn't ship. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël's new work project involves tricky date formats. Stephanie has been working with former Bike Shed host Steph Viccari and loved her peer review feedback.

+ +

The concept of truthiness is tough to grasp sometimes, and JavaScript and Ruby differ in their implementation of truthiness.

+ +
    +
  • Is this a problem?
    • +
  • Do you prefer one model over the other?
    • +
  • What can we learn about these design decisions?
    • +
  • How can we avoid common pitfalls?
    • +
+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So I'm on a new project at work. And I'm doing some really interesting work where I'm connecting to a remote database third-party system directly and pulling data from that database into our system, so not via some kind of API. And one thing that's been really kind of tricky to work with are the date formats on this third-party database.

+ +

STEPHANIE: Is the date being stored in an unexpected format or something like that?

+ +

JOËL: Yes. So there's a few things that are weird with it. So this is a value that represents a point in time, and it's not stored as a date-time value. Instead, it's stored separately as a date column and a time column. So a little bit of weirdness there. We can work with it, except that the time column isn't actually a time value. It is an integer.

+ +

STEPHANIE: Oh no.

+ +

JOËL: Yeah. And if you're thinking, oh, okay, an integer, it's going to be milliseconds since midnight or something like that, which is basically how Postgres' time of day works under the hood, nope, that's not how it works. It's a positional digit thing. So, if you've got the number, you know, 1040, that means 10:40 a.m.

+ +

STEPHANIE: Oh my gosh. Is this in military time or something like that, at least?

+ +

JOËL: Yes, it is military time. But it does allow for all these, like, weird invalid values to creep in. Because, in theory, you should never go beyond 2359. But even within the hours that are allowed, let's say, between 1000 and 1100, so between 10:00 and 11:00 a.m., a clock only goes up to 59 minutes. But our base 10 number system goes up to 99, so it's possible to have 1099, which is just an invalid time.

+ +

STEPHANIE: Right. And I imagine this isn't validated or anything like that. So it is possible to store some impossible time value in this database.

+ +

JOËL: I don't know for sure if the data is validated or not, but I'm not going to trust that it is. So I have to validate it on my end.

+ +

STEPHANIE: That's fair. One thing that is striking me is what time is zero?

+ +

JOËL: So zero in military time or just 24-hour clocks in general is midnight. So 0000, 4 zeros, is midnight. What gets interesting, though, is that because it's an integer, if you put the number, you know, 0001 into the database, it's just going to store it as 1. So I can't even say, oh, the first two digits are the hours, and the second two digits are the minutes. And I'm actually dealing with, I think, seconds and then some fractional part of seconds afterwards. But I can't say that because the number of digits I have is going to be inconsistent.

+ +

So, first, I need to zero pad. Well, I have to, like, turn it into a string, zero pad the numbers so it's eight characters long. And then, start slicing out pairs of numbers, converting them back into integers, validating them within a range of either 0 to 23 or 0 to 59, and then reconstructing a time object out of that.

+ +

STEPHANIE: That sounds quite painful.

+ +

JOËL: It's a journey for sure.

+ +

STEPHANIE: Do you have any idea why this is the case or why it was created like this originally?

+ +

JOËL: I'm not sure. I have a couple of theories. I've seen this kind of thing happen before. And I think it's a common way for developers who maybe haven't put a lot of thought into how time works to just sort of think, oh, the human representation. I need something to go in the database. On my digital clock, I have four digits, so why not put four digits in the database? Simple enough. And then don't always realize that there's all these edge cases to think about and that human representations aren't always the best way to store data.

+ +

STEPHANIE: I like how you just said that that, you know, we as humans have developed systems that are not quite, you know, the same as how a computer would. But what was interesting to me...something you said earlier about time being a fixed point. And that is different from time being a value, right? And so here in this situation, it sounds like we're storing time as a value, but really, it's more of the idea of, like, a point.

+ +

JOËL: Interesting. What is the difference for you between a point and a value?

+ +

STEPHANIE: I suppose a value to me...And I think we talked about this a little bit on a previous episode about value objects and also how we stored numbers, like phone numbers and credit card numbers and stuff like that. But a value, like, I might want to do math on. But I don't really want to do math on time. Or, specifically, if I have this idea of a specific point in time, like, that is fixed and not something that I could mutate and expect it to be the same thing that I was trying to express the first time around.

+ +

JOËL: Oh, that's interesting because I think when it comes to time and specifically points in time, I sometimes do want to do math on them. And so, specifically, I might want to say, what is the time that has elapsed between two points in time? Maybe I have a start time and an end time, and I want to say how much distance is there between the two? If you use this time system where you're storing it as an integer number where the digits have positional values, because there's all those gaps between, you know, 59 and 99 that are not valid, math breaks down. You've broken math by storing it that way.

+ +

So you can't get an accurate difference by doing math on that, as opposed to if you store it as a counter, which is what databases do under the hood, but you could do manually. If you just wanted to use an integer column, then you can do math because it's just a number of seconds since the beginning of the day. And you can subtract those from each other. And now you have these number of seconds between the two of them. And if you want them in minutes or hours, you divide by six here, 3600, and you get the correct response.

+ +

STEPHANIE: Yeah, that is really interesting because [chuckles] in this situation, you have the worst of both worlds, it seems like. [laughs]

+ +

JOËL: The one potential benefit is, I think, it's maybe more human-readable. Although, at that point, I would say if you're not doing math on it and you want something human-readable, you probably don't want an integer. You probably want a string. And maybe you even store it as, like, ISO 8601 time string in the database, or even just hour:minute:second split by a colon or whatever it is but just as a string. Now it's human-readable.

+ +

You can still sort by it if you go from largest to smallest increment in your format. You can't do math, but then you weren't doing math on it anyway. So that's probably a nice compromise solution. But, ideally, you'd use a native, you know, time of day column or a date-time or something like that.

+ +

STEPHANIE: For sure. Well, it sounds like something fun to contend with. [laughs]

+ +

JOËL: One thing that was brought to my attention that I'd never heard about before is that potentially a reason it's stored that way is because of an old data format called EDI—I think it's Electronic Data Interchange—that dates from ages ago, you know, the '60s or '70s, something like that. Before, we had a lot of standards for data; this is how...an emerging standard that came for moving data between systems. And it has a lot of, like, weird things with the way it's set up.

+ +

But if you're dealing with any sort of older data warehouses or older business systems, they will often exchange. And sometimes, you're going to store data in something that approximates this older EDI format. And, apparently, it has some weirdness around dates where it kind of does something like this.

+ +

So someone was suggesting, oh, well, if you're interacting with maybe an older, you know, a lot of, like, e-commerce platforms or banking systems, probably airline systems, the kind of things you'd expect to be written in, let's say, COBOL...

+ +

STEPHANIE: [laughs]

+ +

JOËL: Have a system that's kind of like this. So maybe that wouldn't be quite as surprising.

+ +

STEPHANIE: Yeah, that is really interesting. It just sounds like sometimes you're limited by the technology that you're interacting with. And I guess the one plus side is that, in your system, you can make the EDI work for you, hopefully. [laughs] Whereas perhaps if you are talking to some of those older technologies that don't know how else to convert date types and things like that, like, you just kind of have to work with what's available to you.

+ +

JOËL: Yeah. And that's got me realizing that a lot of these older, archaic systems are still online and very much a part of our software ecosystem and that there's a lot of value in learning some software history so that I'm able to recognize them and sort of work constructively with them when I have to interact with that kind of system.

+ +

STEPHANIE: Yeah, I really like that mindset.

+ +

JOËL: So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, last week, we talked about writing reviews for ourselves and our peers. And one thing that happened in between the last episode and this one is Steph Viccari, former co-host of this podcast, who I've been working with really closely on this project of mine; she was writing a peer review for me. And one thing that she did that I really loved was she sent me a message and asked me a few questions about the direction of the review that I was wanting and what kind of feedback would be helpful for me.

+ +

And some of the things she asked were, you know, "Is there a skill that you're actively working on? Is there a skill you'd like to start working on?" And, like, what my goals are for the feedback. Like, how can she tailor this feedback to things that would help my progression and what I hope to achieve? And then my favorite question that she asked was, "What else should I know but didn't think to ask?" And I thought that was a really cool way of approaching.

+ +

You know, she's coming to this, like, wanting to be helpful, but then even still, like, there are things that she knows that I am kind of the expert on in my own career progression, and I really liked that. I think I'd mentioned last week that part of the feedback you want to be giving is, you know, something that will be helpful for that person, and centering them in it, instead of you is just a really awesome way to do that. So I was very appreciative that she asked me those questions.

+ +

JOËL: That's incredibly thoughtful. I really appreciate that she sent that out to you. What did you respond for the is there something else I should know but didn't know to ask?

+ +

STEPHANIE: Yeah. I mentioned that more and more, I'm realizing that I am not interested in management. And so what would be really helpful for me was to ground most of the feedback in terms of my, like, technical contributions. And also, that one thing that I'm thinking about a lot is how to be an individual contributor and still have an impact on team health and culture because that is something I care about. And so I wanted to share that with her because if there are things that she can identify in those aspects, that would be really awesome for me. And that can kind of help guide her away from a path that I'm not interested in.

+ +

JOËL: I think having that kind of self-awareness is really powerful for yourself. But then, when you can leverage that to get better reviews that will help you get even further down the path that you're hoping to go, and, wow, isn't that just, like, a virtuous cycle right there that's just building on itself?

+ +

STEPHANIE: Yeah, for sure. I think the other thing I wanted to share about what's new in my world that has been just a real boost to my mood is how long the days are right now because it's summer in North America. And yesterday was the summer solstice, and so we had the longest day of the year. The sun didn't set until 8:30 p.m. And I just took the opportunity to be outside. I took a swim in the lake, which was my first swim of the season, which was really special. And my friend had just a nice, little, like, backyard campfire hang out. And we got to roast some marshmallows and just be outside till the sunset. And that was really nice.

+ +

JOËL: When you say the lake, is that Lake Michigan?

+ +

STEPHANIE: Yes, I do mean Lake Michigan. [laughs] I forget that some people just don't have a giant lake next to them [laughs] that they refer to as the lake.

+ +

JOËL: It's practically an inland sea.

+ +

STEPHANIE: Yes, you can't see the other side of it. So, to me, it kind of feels like an ocean. And yesterday, when I was in the water, I also was thinking that I felt like I was just in a giant bathtub. [chuckles]

+ +

JOËL: So I'm in New England, and most of the bodies of water here are not called lakes. They're called ponds.

+ +

STEPHANIE: Really?

+ +

JOËL: No matter the size.

+ +

STEPHANIE: Oh.

+ +

JOËL: I guess lakes is reserved for things like what you have that are absolutely massive, and everything else is a pond.

+ +

STEPHANIE: That's so funny because I think of ponds as much smaller in scale, like a quaint, little pond. But that's a really fun piece of regional vocabulary.

+ +

So one interesting thing happened on my client project this week that I wanted to get your input on because I've definitely seen this problem before, and still, it continues to crop up. But I was working on a background job that we were passing a Boolean value into as one of the parameters that we would then, you know, use down the line in determining some logic.

+ +

And we, you know, made this change, and then we were surprised to find out that it continued to not work the way we expected. So we got some bug reports that we weren't getting into one of the branches of the conditional based on that Boolean value that we were passing in. And we learned, after a little bit of digging, that it turns out that those values are serialized because this job is actually saved in --

+ +

JOËL: Oh no.

+ +

STEPHANIE: [chuckles] Yeah. It inherits from the ActiveRecord, actually, and is saved in our database. And so, in that process, the Boolean value got serialized into a string and then did not get converted [chuckles] back into a Boolean. And so when we do that if variable check, it was always evaluating to true because strings are truthy in Ruby.

+ +

JOËL: Right. The string false is still truthy.

+ +

STEPHANIE: A string false is still truthy. And we ended up having to coerce it into a Boolean value to fix our little bug. But it was just one of those things that was really frustrating, you know when you feel really confident that you know what you're doing. You're just writing a conditional statement. And it turns out the language beguiled you. [laughs]

+ +

JOËL: I've run into similar bugs when I'm reading from environment variables because environment variables are always strings. But it's common that you'll be setting some kind of flag. So when you're setting the environment variable, you're setting something to true or false. But then, when you're reading it, you have to explicitly check if this environment variable double equals the string true, then do the thing. Because if you just check for the value, it will never be false.

+ +

STEPHANIE: Right. And I kind of hate seeing code like that. I don't know; something about it just rubs me the wrong way because it just seems so strange, I suppose.

+ +

JOËL: Is it just, like, those edge cases where you specifically have to do some kind of, like, double equals check on a value that feels like it should be a Boolean? Or do you kind of feel a bit weird about the concept of truthiness in general?

+ +

STEPHANIE: I think the concept of truthiness is very hard to grasp sometimes. And, you know, when you're talking about that edge case where we are setting...we're checking if the string is the string true. That means that everything else is false, right? So, in some ways, I think it's just really confusing because we've expanded the definition of what true and false mean to be anything.

+ +

JOËL: That's really interesting because now you have to pick. Are you checking against the string true, or are you negatively checking against the string false? And those are not equivalent because, like you said, now you're excluding every other string. So, is the string "Hello, World" put you in the false branch or the true branch?

+ +

STEPHANIE: Who's to say? [laughs] I think a similar conundrum also occurs when we use predicate matchers in our tests. I think this is a gripe that I've talked about a little bit with others when we're writing tests and especially if we're writing a predicate method, and then that's what we're testing, right? We kind of are expecting a true or false value.

+ +

And when our test expects something to be truthy rather than explicitly saying that we expect the return value to be true, that is sometimes a bit confusing to me as well because someone could theoretically change this method and just have it return "Hello, World," like you said, as a string, like, anything else. And that would still pass the test.

+ +

JOËL: And it might even pass your code in most places.

+ +

STEPHANIE: Right. And I suppose that's okay. Is it okay? I don't know. I'm not sure where I land on this.

+ +

JOËL: I used to be a kind of hardcore Boolean person.

+ +

STEPHANIE: [laughs] That's a sentence no one has ever [laughs] said.

+ +

JOËL: I like my explicit trues and falses. I don't like the ambiguity of saying, like, oh, if person do a thing, it's, like, oh, what is person here? Is this a nil check? Is it explicitly false? Do you just want to know that this person is non-empty? Well, what exactly are you checking? So I like the explicitness of saying, oh, if person dot present, or if person dot empty, or if person dot nil.

+ +

And I think maybe spending some time in some more strongly typed languages has also kind of pushed me a little bit in that direction, where it's nice to have something that is explicitly either just true or just false. And then you completely eliminate that problem of, like, oh, but what if it's neither true nor false, then what do we do for that branch there? And the answer is your compiler will reject that program or say, "You've written a bad program." And you never reach that point where there's a bug.

+ +

I've slowly been softening my stance. A fellow thoughtbot colleague has written an article why there is no such thing as a Boolean in Ruby. Everything is just shades of gray and truthiness and falsiness. But from the perspective of a program, there is no such thing as a Boolean. And that really opened my eyes to a different perspective. I don't know that I fully agree, but I'm kind of begrudgingly acknowledging that Mike makes a good point.

+ +

STEPHANIE: Yes, I read the blog post that he wrote about this exact problem. And I think it's called "Booleans Don't Exist in Ruby." And I think I similarly, like, came away with, like, yeah, I think I get it if I just suspend my disbelief, you know, hard enough. [laughs] But what you were saying about, like, liking the explicitness, right? And liking the lack of ambiguity, right? Because when you start to believe that Booleans don't exist, I think that really messes with your [laughs] head a little bit.

+ +

And one takeaway that I got from that blog post, kind of like we mentioned earlier, is that there is such thing as false, and then everything else is true. And I guess that's kind of how Ruby operates.

+ +

JOËL: Sort of, because then you have the problem of nil, which is also falsy.

+ +

STEPHANIE: That's true, but nil is nothing. [laughs]

+ +

JOËL: That's one of the classic problems as well when you're trying to do a nil check, or maybe some memoization, or maybe even, say, cache this value, or store this value, or initialize this value if it's not set. And assuming that doing nil is falsy, so you'll do some kind of, like, or equals, or just some kind of expression with an or in it thinking, oh, do this extra work if it's nil because then it will trigger the branch. But that all breaks down if potential for your value to be false because false and nil get treated the same in conditional code.

+ +

STEPHANIE: Right. I think this could be a whole separate conversation about nil and the idea of nothingness. But I do think that, as Ruby developers, at least in the Ruby world, based on what I've seen, is that we lean on nil in ways that we maybe shouldn't. And we end up having to be very defensive about this idea of nil being falsy. But that's because we aren't necessarily thinking as hard about our return values and what our arguments are that; it ends up causing problems in evaluating truthiness when we're having to check those objects that could be nil.

+ +

JOËL: In terms of the way we communicate with the readers of our code, and, as a reader, I generally assume that a Ruby method that ends with a question mark will return a true Boolean, either true or false. Is that generally your expectation as well?

+ +

STEPHANIE: I want to say yes, but I've clearly experienced enough times where that's not the case that, you know, it's like, my ideal world and then reality [laughs] and having to figure out how to hold both of those things.

+ +

JOËL: It's one of those things that's mostly true.

+ +

STEPHANIE: I want to believe it because predicate methods and, like, the Ruby Standard Library mostly return Boolean values, at least to my knowledge. And if we all kind of followed that [laughs] pattern, then it would be clear. But I think there's a part of me that these days mostly believes it to be true that I will be getting a Boolean value (And, wow, even as I say this, I realize how confusing [laughs] this is starting to sound.) and that until I'm not, right? Until I'm surprised at some point.

+ +

JOËL: I think there's two things I expect of predicate methods in Ruby. One is that they will return, like, a hard Boolean, either true or false. The second is that they are purely query methods; they don't do side effects. Neither of those are consistent across the ecosystem.

+ +

And a classic example of violating that second guideline I have in my mind is the valid question mark method from Rails. And this really surprised me the first time I tripped into this because when you call that on an object, it doesn't just tell you whether or not the object is valid. It actually mutates the underlying object by populating the error messages' hash. So if you have an invalid object and you examine its error messages' hash, it will be empty until you call the valid question mark method.

+ +

So sometimes, you don't even care about the return value. You're just calling valid to mutate the object so that you can access the underlying hash, which is that's weird code when you call a predicate method but then totally ignore the output.

+ +

STEPHANIE: Yeah, that is strange because I have definitely seen it where we are calling the valid method to validate, and then we end up using the error messages that are set on that object later. I think that's tough because, in some ways, you do care about whether the object is valid or not. But then also, the error messages are helpful usually and when you're trying to use that method. The point is to validate it so that you can hopefully, like, tell the user or, like, the consumer of your system, like, what's wrong in validation. But it is almost, like, two separate things.

+ +

JOËL: It is. And sometimes, it's really hard to split those two apart. So I'm not throwing shade at the Rails dev team here. Some of these design decisions are legitimately difficult to make. And what's most useful for the most people the most time is often a compromise. I think you brought up the idea of separating those two things. And I think there's a general principle here called command-query separation. That's, like, the fancy way of talking about what you were saying.

+ +

STEPHANIE: One thing that I was just thinking about kind of when we initially picked off this conversation was the idea of how things outside the Ruby ecosystem or the Ruby world interact with what we're returning in terms of Boolean values. And so when I mentioned the object being serialized because of, you know, our database and, like, background job system, that's an entity that's figuring out what to do with the things that we are returning from Ruby.

+ +

And similarly, when you're talking about environment variables, it's like, our computer system talking to now our language and those things being a bit different. Because when we, like, suspend our disbelief about what is truthy or falsy in Ruby, at least we're doing it in, like, the world of Ruby. And as soon as we have to interact with something else, like, maybe that's when things can get a little hairy because there's different ideas about truthiness there. And so I'm kind of also thinking about what we return in APIs and maybe, like, that being an area where some explicitness is more required.

+ +

JOËL: Whenever I'm consuming third-party data, I'm a big fan of having some kind of transformation or parse step. This is inspired in part by the "Parse, Don't Validate" article, which I'll link in the show notes. So, if I'm reading data from a third-party API and I want it to be a Boolean, then maybe I should do the transformation myself. So maybe I check literally, is it the string true or the string false, and anything else gets rejected?

+ +

Maybe I have...and maybe I'm a little bit more permissive, where I also accept capital T or capital F, and I have, like, some rules for transforming that. But the important thing is I have an explicit conversion step and reject any bad output. And so for something like an environment variable, maybe that would look like looking for true or false and raising if anything else is there. So that we try to boot the app, and it immediately crashes because, hey, we've got some, like, undefined, like, bad configuration that we're trying to load the app with. Don't even try to keep running. Hard crash immediately. Fix it, and then come back.

+ +

STEPHANIE: Yeah, I like that a lot because the way we ended up fixing this issue with the background job that I mentioned was just coercing our string value into a Ruby Boolean in the job that we were then, like, running the conditional in. But really, what we should have done is have fixed that at a higher level and where we parse and deserialize, like, the values we're getting from the job to prevent this kind of in the future because right now, someone can do this again, and that's a real bummer.

+ +

JOËL: I always love those deeper conversations that happen after you've had a bug that are like, how do we prevent this from happening again? Because sometimes that's where you have the deepest learnings or the most interesting insights or, you know, ideas for Bike Shed episodes.

+ +

I'm really curious to contrast JavaScript's approach to truthiness to Ruby's because even though they both use the same idea, they kind of go about it differently.

+ +

STEPHANIE: Tell me more.

+ +

JOËL: So, in Ruby, an empty array and an empty string are truthy. JavaScript decided that empty things are falsy. And I forget...there's a whole table that shows the things that are truthy and falsy in JavaScript. I want to say zero is falsy in JavaScript but don't quote me on that, which can also lead to some interesting edge cases you have to think about.

+ +

STEPHANIE: Okay, yes. This is coming back to me now. I think depending on what, you know, ecosystem or language or world I'm in, I have to just only be able to think about what is true in this world [laughs] and then do that context switching when I am working in something else. But yeah, that is a really interesting idea. Someone decided [laughs] that this was their idea of true or false.

+ +

JOËL: I'm curious if you have a preference for sort of JavaScript's approach to falsiness where a lot more types of values are falsy versus Ruby, which said pretty much only nil and false are falsy. Everything else is truthy.

+ +

STEPHANIE: Hmm, that is an interesting question.

+ +

JOËL: Because in Ruby then or, I guess, in Rails, we end up with the present predicate method that is specifically checking for not only nil and false but also for empty array, empty string, those kinds of things. So, if you find yourself writing a lot of present matchers in your code, you're kind of leaning on something that's closer to JavaScript's definition of falsiness than Ruby's. But maybe you're making it more explicit.

+ +

STEPHANIE: Right. In JavaScript, I see a lot of double bangs in lieu of those predicate methods. But I suppose by nature of having to write those predicate methods in Ruby, we're, like, really wanting something else, I think. And maybe...I guess it is just a question of explicitness like you're saying, and which I prefer. Is it that I need to be explicit to convey the idea that I want, or is it nice that the language has just been encoded that way for me?

+ +

JOËL: Or maybe when you write conditionals, if you find yourself doing a lot of presence checks, do you find that you typically are trying to branch on if not null, not false, not empty more frequently than just if not null, not false? Because that's kind of the difference between Ruby's model and JavaScript's model.

+ +

STEPHANIE: Hmm, the way you posed that question is interesting because it makes me think that sometimes it's quite defensive because we have to check for all these possible return values. We are unsure of what we are getting back. And so this is kind of, like, a catch-all for things that we aren't really sure about.

+ +

JOËL: Yeah, I mean, that's the fun of dynamic programming languages. You never know exactly what you're going to get as long as things respond to certain methods. You really lean into the duck typing. And I think that's Mike's argument in his article that "Booleans Don't Exist" in that as long as something is responding to methods that you care about, it doesn't matter if you're dealing with a true Boolean or some kind of other value.

+ +

STEPHANIE: Right. So I suppose the ideas of truthiness then are a little bit more dependent on how people are using the language though it seems like a chicken-and-egg situation to me. [laughs]

+ +

JOËL: It is really interesting to me in terms of maybe thinking about use cases in my own code if I'm having to...if I'm writing code that leans on truthiness where I can say just, you know if user. But then knowing that, oh, that doesn't account for, like, an empty value. Do I then also need to add an extra check for emptiness? And maybe if I'm in a Rails project, I would reach for that present matcher where I wouldn't have to do that in JavaScript because I can just say, if user, and that already automatically checks for presence.

+ +

So I'm kind of wondering now in my mind, like, which default would fit my use cases more? Or, if I go back to an older version of myself, I will say I don't want any of these defaults. They're all too ambiguous. I'm going to put explicitly if user dot nil question mark, if that's the thing that I'm checking for, or if user dot empty question mark because I want my reader to know what condition I'm checking.

+ +

STEPHANIE: Yeah, that is interesting, this idea of, like, which mode do you find yourself needing to use more and if that is accommodated for you because that's just the more common, like, use case or problem.

+ +

I think that's something that I will be thinking about the next time I write a conditional [laughs] because, like I was saying earlier, I think I end up just leaning on what someone else has decided for me in terms of truthiness and not so much how I would like it to work for me.

+ +

JOËL: And sometimes we don't want to fight the language too much, you know if I'm writing Elm, that everything is hard Booleans. And I know I'm never going to get a nil in a place where I'd expect true or false because the compiler would prevent that from happening. I know that I'm not going to get an empty value, potentially.

+ +

There's ways you can do things with a type system where you can explicitly say no empty values are even allowed at this point. And if you do allow them, then the type system will say, "Hey, you forgot to check for the empty case. Bad program. I'm rejecting that." And then you have to write that explicit branch for, oh, if empty versus if present. So I really appreciate that style of programming.

+ +

But then, when you're in a language like Ruby where you're not dealing with explicit types on purpose, how do you shift that mindset so that you don't need to know the type of the value that you're dealing with? You only want to say, hey, in this context, here's the minimal interface that I want it to conform to. And maybe it's just the truthy or falsiness interface, and everything beyond that is not relevant.

+ +

STEPHANIE: I think it's kind of wild to me that this idea of a binary that theoretically seems very clear turns out is actually quite confusing, ambiguous, philosophical, even. [chuckles]

+ +

JOËL: Yeah. It's definitely...you can get into some deep, philosophical questions there, language design as well.

+ +

One aspect, though, that I'm really curious about your thoughts is bringing new people in who are learning a language. It's really common for people who are learning a language for the first time, learning to code for the first time to write code that you and I would immediately know, like, that's not going to work. You can't add a Boolean and a number. You're just learning to code. You've never done that before. You don't know. And then how the language reacts to that kind of thing can help guide that experience.

+ +

So, do you think that truthiness maybe makes things more confusing for newcomers? Or, maybe on the other side, it helps to smooth that learning curve because you don't have to be like, oh, wait, I have a user here. I can't put that in a condition because that's not a strict true or false. I'm going to coerce it, or I've got to find a predicate method or something. You can just be like, no, put it in. The interpreter will figure it out for you.

+ +

STEPHANIE: Wow. That's a great question. I'm trying to put myself in the beginner's mindset a little bit and think about what it's like to just try something and the magic of it working. Because, like you said, the interpreter does it for you, or whatever, and something happens, and you're like, wow, like, that was really cool. And I didn't have to know all of the ins and outs of the types of things I was working with.

+ +

That can be really helpful in just getting them, like, started and getting them just, like, on the ground writing code. And having that feeling of satisfaction that, like, that they didn't have to, you know, have to learn all these things that can be really scary to make their program work.

+ +

But I do think it also kind of bites them later once they really realize [laughs] what is going on and the minute that they get that, like, unexpected behavior, right? Like, that becomes a time when you do have to figure out what might be going on under the hood. So two sides of the same coin.

+ +

JOËL: What you're saying there about, like, maybe smoothing that initial curve but then it biting them later got me thinking. You know how we have the concept of technical debt where we write code in a way that's maybe not quite as clean today so we can move faster but that then later on we have to pay it back? And I almost wonder if what we have here is almost like a pedagogical debt where it's going to cost us a month from now, but today it helps us move faster and actually kind of get that momentum going.

+ +

STEPHANIE: Pedagogical debt. I like that. I think you've coined a new term. Because I really relate to that where you learn just enough to do the thing now. But, you know, it's probably not, like, the right way or, like, the most informed—I think most informed is probably how I would best describe it—way of doing it. And later, you, yeah, just have to invest a little more into it. And I think that's okay.

+ +

I think sometimes I do tend to, like, beat myself up over something down the line when I have to deal with some piece of less-than-ideal code that I'd written earlier. Like, I think that, oh, I could have avoided this if only I knew. But the whole point is that I didn't know. [laughs] And, like, that's okay, like, maybe I didn't need to know at the time.

+ +

JOËL: Yeah, and code that's never shipped is of zero value. So having something that you could ship is better than having something perfect that you didn't ship.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Joël's new work project involves tricky date formats. Stephanie has been working with former Bike Shed host Steph Viccari and loved her peer review feedback.

+ +

The concept of truthiness is tough to grasp sometimes, and JavaScript and Ruby differ in their implementation of truthiness.

+ +
    +
  • Is this a problem?
    • +
  • Do you prefer one model over the other?
    • +
  • What can we learn about these design decisions?
    • +
  • How can we avoid common pitfalls?
    • +
+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So I'm on a new project at work. And I'm doing some really interesting work where I'm connecting to a remote database third-party system directly and pulling data from that database into our system, so not via some kind of API. And one thing that's been really kind of tricky to work with are the date formats on this third-party database.

+ +

STEPHANIE: Is the date being stored in an unexpected format or something like that?

+ +

JOËL: Yes. So there's a few things that are weird with it. So this is a value that represents a point in time, and it's not stored as a date-time value. Instead, it's stored separately as a date column and a time column. So a little bit of weirdness there. We can work with it, except that the time column isn't actually a time value. It is an integer.

+ +

STEPHANIE: Oh no.

+ +

JOËL: Yeah. And if you're thinking, oh, okay, an integer, it's going to be milliseconds since midnight or something like that, which is basically how Postgres' time of day works under the hood, nope, that's not how it works. It's a positional digit thing. So, if you've got the number, you know, 1040, that means 10:40 a.m.

+ +

STEPHANIE: Oh my gosh. Is this in military time or something like that, at least?

+ +

JOËL: Yes, it is military time. But it does allow for all these, like, weird invalid values to creep in. Because, in theory, you should never go beyond 2359. But even within the hours that are allowed, let's say, between 1000 and 1100, so between 10:00 and 11:00 a.m., a clock only goes up to 59 minutes. But our base 10 number system goes up to 99, so it's possible to have 1099, which is just an invalid time.

+ +

STEPHANIE: Right. And I imagine this isn't validated or anything like that. So it is possible to store some impossible time value in this database.

+ +

JOËL: I don't know for sure if the data is validated or not, but I'm not going to trust that it is. So I have to validate it on my end.

+ +

STEPHANIE: That's fair. One thing that is striking me is what time is zero?

+ +

JOËL: So zero in military time or just 24-hour clocks in general is midnight. So 0000, 4 zeros, is midnight. What gets interesting, though, is that because it's an integer, if you put the number, you know, 0001 into the database, it's just going to store it as 1. So I can't even say, oh, the first two digits are the hours, and the second two digits are the minutes. And I'm actually dealing with, I think, seconds and then some fractional part of seconds afterwards. But I can't say that because the number of digits I have is going to be inconsistent.

+ +

So, first, I need to zero pad. Well, I have to, like, turn it into a string, zero pad the numbers so it's eight characters long. And then, start slicing out pairs of numbers, converting them back into integers, validating them within a range of either 0 to 23 or 0 to 59, and then reconstructing a time object out of that.

+ +

STEPHANIE: That sounds quite painful.

+ +

JOËL: It's a journey for sure.

+ +

STEPHANIE: Do you have any idea why this is the case or why it was created like this originally?

+ +

JOËL: I'm not sure. I have a couple of theories. I've seen this kind of thing happen before. And I think it's a common way for developers who maybe haven't put a lot of thought into how time works to just sort of think, oh, the human representation. I need something to go in the database. On my digital clock, I have four digits, so why not put four digits in the database? Simple enough. And then don't always realize that there's all these edge cases to think about and that human representations aren't always the best way to store data.

+ +

STEPHANIE: I like how you just said that that, you know, we as humans have developed systems that are not quite, you know, the same as how a computer would. But what was interesting to me...something you said earlier about time being a fixed point. And that is different from time being a value, right? And so here in this situation, it sounds like we're storing time as a value, but really, it's more of the idea of, like, a point.

+ +

JOËL: Interesting. What is the difference for you between a point and a value?

+ +

STEPHANIE: I suppose a value to me...And I think we talked about this a little bit on a previous episode about value objects and also how we stored numbers, like phone numbers and credit card numbers and stuff like that. But a value, like, I might want to do math on. But I don't really want to do math on time. Or, specifically, if I have this idea of a specific point in time, like, that is fixed and not something that I could mutate and expect it to be the same thing that I was trying to express the first time around.

+ +

JOËL: Oh, that's interesting because I think when it comes to time and specifically points in time, I sometimes do want to do math on them. And so, specifically, I might want to say, what is the time that has elapsed between two points in time? Maybe I have a start time and an end time, and I want to say how much distance is there between the two? If you use this time system where you're storing it as an integer number where the digits have positional values, because there's all those gaps between, you know, 59 and 99 that are not valid, math breaks down. You've broken math by storing it that way.

+ +

So you can't get an accurate difference by doing math on that, as opposed to if you store it as a counter, which is what databases do under the hood, but you could do manually. If you just wanted to use an integer column, then you can do math because it's just a number of seconds since the beginning of the day. And you can subtract those from each other. And now you have these number of seconds between the two of them. And if you want them in minutes or hours, you divide by six here, 3600, and you get the correct response.

+ +

STEPHANIE: Yeah, that is really interesting because [chuckles] in this situation, you have the worst of both worlds, it seems like. [laughs]

+ +

JOËL: The one potential benefit is, I think, it's maybe more human-readable. Although, at that point, I would say if you're not doing math on it and you want something human-readable, you probably don't want an integer. You probably want a string. And maybe you even store it as, like, ISO 8601 time string in the database, or even just hour:minute:second split by a colon or whatever it is but just as a string. Now it's human-readable.

+ +

You can still sort by it if you go from largest to smallest increment in your format. You can't do math, but then you weren't doing math on it anyway. So that's probably a nice compromise solution. But, ideally, you'd use a native, you know, time of day column or a date-time or something like that.

+ +

STEPHANIE: For sure. Well, it sounds like something fun to contend with. [laughs]

+ +

JOËL: One thing that was brought to my attention that I'd never heard about before is that potentially a reason it's stored that way is because of an old data format called EDI—I think it's Electronic Data Interchange—that dates from ages ago, you know, the '60s or '70s, something like that. Before, we had a lot of standards for data; this is how...an emerging standard that came for moving data between systems. And it has a lot of, like, weird things with the way it's set up.

+ +

But if you're dealing with any sort of older data warehouses or older business systems, they will often exchange. And sometimes, you're going to store data in something that approximates this older EDI format. And, apparently, it has some weirdness around dates where it kind of does something like this.

+ +

So someone was suggesting, oh, well, if you're interacting with maybe an older, you know, a lot of, like, e-commerce platforms or banking systems, probably airline systems, the kind of things you'd expect to be written in, let's say, COBOL...

+ +

STEPHANIE: [laughs]

+ +

JOËL: Have a system that's kind of like this. So maybe that wouldn't be quite as surprising.

+ +

STEPHANIE: Yeah, that is really interesting. It just sounds like sometimes you're limited by the technology that you're interacting with. And I guess the one plus side is that, in your system, you can make the EDI work for you, hopefully. [laughs] Whereas perhaps if you are talking to some of those older technologies that don't know how else to convert date types and things like that, like, you just kind of have to work with what's available to you.

+ +

JOËL: Yeah. And that's got me realizing that a lot of these older, archaic systems are still online and very much a part of our software ecosystem and that there's a lot of value in learning some software history so that I'm able to recognize them and sort of work constructively with them when I have to interact with that kind of system.

+ +

STEPHANIE: Yeah, I really like that mindset.

+ +

JOËL: So, Stephanie, what's new in your world?

+ +

STEPHANIE: So, last week, we talked about writing reviews for ourselves and our peers. And one thing that happened in between the last episode and this one is Steph Viccari, former co-host of this podcast, who I've been working with really closely on this project of mine; she was writing a peer review for me. And one thing that she did that I really loved was she sent me a message and asked me a few questions about the direction of the review that I was wanting and what kind of feedback would be helpful for me.

+ +

And some of the things she asked were, you know, "Is there a skill that you're actively working on? Is there a skill you'd like to start working on?" And, like, what my goals are for the feedback. Like, how can she tailor this feedback to things that would help my progression and what I hope to achieve? And then my favorite question that she asked was, "What else should I know but didn't think to ask?" And I thought that was a really cool way of approaching.

+ +

You know, she's coming to this, like, wanting to be helpful, but then even still, like, there are things that she knows that I am kind of the expert on in my own career progression, and I really liked that. I think I'd mentioned last week that part of the feedback you want to be giving is, you know, something that will be helpful for that person, and centering them in it, instead of you is just a really awesome way to do that. So I was very appreciative that she asked me those questions.

+ +

JOËL: That's incredibly thoughtful. I really appreciate that she sent that out to you. What did you respond for the is there something else I should know but didn't know to ask?

+ +

STEPHANIE: Yeah. I mentioned that more and more, I'm realizing that I am not interested in management. And so what would be really helpful for me was to ground most of the feedback in terms of my, like, technical contributions. And also, that one thing that I'm thinking about a lot is how to be an individual contributor and still have an impact on team health and culture because that is something I care about. And so I wanted to share that with her because if there are things that she can identify in those aspects, that would be really awesome for me. And that can kind of help guide her away from a path that I'm not interested in.

+ +

JOËL: I think having that kind of self-awareness is really powerful for yourself. But then, when you can leverage that to get better reviews that will help you get even further down the path that you're hoping to go, and, wow, isn't that just, like, a virtuous cycle right there that's just building on itself?

+ +

STEPHANIE: Yeah, for sure. I think the other thing I wanted to share about what's new in my world that has been just a real boost to my mood is how long the days are right now because it's summer in North America. And yesterday was the summer solstice, and so we had the longest day of the year. The sun didn't set until 8:30 p.m. And I just took the opportunity to be outside. I took a swim in the lake, which was my first swim of the season, which was really special. And my friend had just a nice, little, like, backyard campfire hang out. And we got to roast some marshmallows and just be outside till the sunset. And that was really nice.

+ +

JOËL: When you say the lake, is that Lake Michigan?

+ +

STEPHANIE: Yes, I do mean Lake Michigan. [laughs] I forget that some people just don't have a giant lake next to them [laughs] that they refer to as the lake.

+ +

JOËL: It's practically an inland sea.

+ +

STEPHANIE: Yes, you can't see the other side of it. So, to me, it kind of feels like an ocean. And yesterday, when I was in the water, I also was thinking that I felt like I was just in a giant bathtub. [chuckles]

+ +

JOËL: So I'm in New England, and most of the bodies of water here are not called lakes. They're called ponds.

+ +

STEPHANIE: Really?

+ +

JOËL: No matter the size.

+ +

STEPHANIE: Oh.

+ +

JOËL: I guess lakes is reserved for things like what you have that are absolutely massive, and everything else is a pond.

+ +

STEPHANIE: That's so funny because I think of ponds as much smaller in scale, like a quaint, little pond. But that's a really fun piece of regional vocabulary.

+ +

So one interesting thing happened on my client project this week that I wanted to get your input on because I've definitely seen this problem before, and still, it continues to crop up. But I was working on a background job that we were passing a Boolean value into as one of the parameters that we would then, you know, use down the line in determining some logic.

+ +

And we, you know, made this change, and then we were surprised to find out that it continued to not work the way we expected. So we got some bug reports that we weren't getting into one of the branches of the conditional based on that Boolean value that we were passing in. And we learned, after a little bit of digging, that it turns out that those values are serialized because this job is actually saved in --

+ +

JOËL: Oh no.

+ +

STEPHANIE: [chuckles] Yeah. It inherits from the ActiveRecord, actually, and is saved in our database. And so, in that process, the Boolean value got serialized into a string and then did not get converted [chuckles] back into a Boolean. And so when we do that if variable check, it was always evaluating to true because strings are truthy in Ruby.

+ +

JOËL: Right. The string false is still truthy.

+ +

STEPHANIE: A string false is still truthy. And we ended up having to coerce it into a Boolean value to fix our little bug. But it was just one of those things that was really frustrating, you know when you feel really confident that you know what you're doing. You're just writing a conditional statement. And it turns out the language beguiled you. [laughs]

+ +

JOËL: I've run into similar bugs when I'm reading from environment variables because environment variables are always strings. But it's common that you'll be setting some kind of flag. So when you're setting the environment variable, you're setting something to true or false. But then, when you're reading it, you have to explicitly check if this environment variable double equals the string true, then do the thing. Because if you just check for the value, it will never be false.

+ +

STEPHANIE: Right. And I kind of hate seeing code like that. I don't know; something about it just rubs me the wrong way because it just seems so strange, I suppose.

+ +

JOËL: Is it just, like, those edge cases where you specifically have to do some kind of, like, double equals check on a value that feels like it should be a Boolean? Or do you kind of feel a bit weird about the concept of truthiness in general?

+ +

STEPHANIE: I think the concept of truthiness is very hard to grasp sometimes. And, you know, when you're talking about that edge case where we are setting...we're checking if the string is the string true. That means that everything else is false, right? So, in some ways, I think it's just really confusing because we've expanded the definition of what true and false mean to be anything.

+ +

JOËL: That's really interesting because now you have to pick. Are you checking against the string true, or are you negatively checking against the string false? And those are not equivalent because, like you said, now you're excluding every other string. So, is the string "Hello, World" put you in the false branch or the true branch?

+ +

STEPHANIE: Who's to say? [laughs] I think a similar conundrum also occurs when we use predicate matchers in our tests. I think this is a gripe that I've talked about a little bit with others when we're writing tests and especially if we're writing a predicate method, and then that's what we're testing, right? We kind of are expecting a true or false value.

+ +

And when our test expects something to be truthy rather than explicitly saying that we expect the return value to be true, that is sometimes a bit confusing to me as well because someone could theoretically change this method and just have it return "Hello, World," like you said, as a string, like, anything else. And that would still pass the test.

+ +

JOËL: And it might even pass your code in most places.

+ +

STEPHANIE: Right. And I suppose that's okay. Is it okay? I don't know. I'm not sure where I land on this.

+ +

JOËL: I used to be a kind of hardcore Boolean person.

+ +

STEPHANIE: [laughs] That's a sentence no one has ever [laughs] said.

+ +

JOËL: I like my explicit trues and falses. I don't like the ambiguity of saying, like, oh, if person do a thing, it's, like, oh, what is person here? Is this a nil check? Is it explicitly false? Do you just want to know that this person is non-empty? Well, what exactly are you checking? So I like the explicitness of saying, oh, if person dot present, or if person dot empty, or if person dot nil.

+ +

And I think maybe spending some time in some more strongly typed languages has also kind of pushed me a little bit in that direction, where it's nice to have something that is explicitly either just true or just false. And then you completely eliminate that problem of, like, oh, but what if it's neither true nor false, then what do we do for that branch there? And the answer is your compiler will reject that program or say, "You've written a bad program." And you never reach that point where there's a bug.

+ +

I've slowly been softening my stance. A fellow thoughtbot colleague has written an article why there is no such thing as a Boolean in Ruby. Everything is just shades of gray and truthiness and falsiness. But from the perspective of a program, there is no such thing as a Boolean. And that really opened my eyes to a different perspective. I don't know that I fully agree, but I'm kind of begrudgingly acknowledging that Mike makes a good point.

+ +

STEPHANIE: Yes, I read the blog post that he wrote about this exact problem. And I think it's called "Booleans Don't Exist in Ruby." And I think I similarly, like, came away with, like, yeah, I think I get it if I just suspend my disbelief, you know, hard enough. [laughs] But what you were saying about, like, liking the explicitness, right? And liking the lack of ambiguity, right? Because when you start to believe that Booleans don't exist, I think that really messes with your [laughs] head a little bit.

+ +

And one takeaway that I got from that blog post, kind of like we mentioned earlier, is that there is such thing as false, and then everything else is true. And I guess that's kind of how Ruby operates.

+ +

JOËL: Sort of, because then you have the problem of nil, which is also falsy.

+ +

STEPHANIE: That's true, but nil is nothing. [laughs]

+ +

JOËL: That's one of the classic problems as well when you're trying to do a nil check, or maybe some memoization, or maybe even, say, cache this value, or store this value, or initialize this value if it's not set. And assuming that doing nil is falsy, so you'll do some kind of, like, or equals, or just some kind of expression with an or in it thinking, oh, do this extra work if it's nil because then it will trigger the branch. But that all breaks down if potential for your value to be false because false and nil get treated the same in conditional code.

+ +

STEPHANIE: Right. I think this could be a whole separate conversation about nil and the idea of nothingness. But I do think that, as Ruby developers, at least in the Ruby world, based on what I've seen, is that we lean on nil in ways that we maybe shouldn't. And we end up having to be very defensive about this idea of nil being falsy. But that's because we aren't necessarily thinking as hard about our return values and what our arguments are that; it ends up causing problems in evaluating truthiness when we're having to check those objects that could be nil.

+ +

JOËL: In terms of the way we communicate with the readers of our code, and, as a reader, I generally assume that a Ruby method that ends with a question mark will return a true Boolean, either true or false. Is that generally your expectation as well?

+ +

STEPHANIE: I want to say yes, but I've clearly experienced enough times where that's not the case that, you know, it's like, my ideal world and then reality [laughs] and having to figure out how to hold both of those things.

+ +

JOËL: It's one of those things that's mostly true.

+ +

STEPHANIE: I want to believe it because predicate methods and, like, the Ruby Standard Library mostly return Boolean values, at least to my knowledge. And if we all kind of followed that [laughs] pattern, then it would be clear. But I think there's a part of me that these days mostly believes it to be true that I will be getting a Boolean value (And, wow, even as I say this, I realize how confusing [laughs] this is starting to sound.) and that until I'm not, right? Until I'm surprised at some point.

+ +

JOËL: I think there's two things I expect of predicate methods in Ruby. One is that they will return, like, a hard Boolean, either true or false. The second is that they are purely query methods; they don't do side effects. Neither of those are consistent across the ecosystem.

+ +

And a classic example of violating that second guideline I have in my mind is the valid question mark method from Rails. And this really surprised me the first time I tripped into this because when you call that on an object, it doesn't just tell you whether or not the object is valid. It actually mutates the underlying object by populating the error messages' hash. So if you have an invalid object and you examine its error messages' hash, it will be empty until you call the valid question mark method.

+ +

So sometimes, you don't even care about the return value. You're just calling valid to mutate the object so that you can access the underlying hash, which is that's weird code when you call a predicate method but then totally ignore the output.

+ +

STEPHANIE: Yeah, that is strange because I have definitely seen it where we are calling the valid method to validate, and then we end up using the error messages that are set on that object later. I think that's tough because, in some ways, you do care about whether the object is valid or not. But then also, the error messages are helpful usually and when you're trying to use that method. The point is to validate it so that you can hopefully, like, tell the user or, like, the consumer of your system, like, what's wrong in validation. But it is almost, like, two separate things.

+ +

JOËL: It is. And sometimes, it's really hard to split those two apart. So I'm not throwing shade at the Rails dev team here. Some of these design decisions are legitimately difficult to make. And what's most useful for the most people the most time is often a compromise. I think you brought up the idea of separating those two things. And I think there's a general principle here called command-query separation. That's, like, the fancy way of talking about what you were saying.

+ +

STEPHANIE: One thing that I was just thinking about kind of when we initially picked off this conversation was the idea of how things outside the Ruby ecosystem or the Ruby world interact with what we're returning in terms of Boolean values. And so when I mentioned the object being serialized because of, you know, our database and, like, background job system, that's an entity that's figuring out what to do with the things that we are returning from Ruby.

+ +

And similarly, when you're talking about environment variables, it's like, our computer system talking to now our language and those things being a bit different. Because when we, like, suspend our disbelief about what is truthy or falsy in Ruby, at least we're doing it in, like, the world of Ruby. And as soon as we have to interact with something else, like, maybe that's when things can get a little hairy because there's different ideas about truthiness there. And so I'm kind of also thinking about what we return in APIs and maybe, like, that being an area where some explicitness is more required.

+ +

JOËL: Whenever I'm consuming third-party data, I'm a big fan of having some kind of transformation or parse step. This is inspired in part by the "Parse, Don't Validate" article, which I'll link in the show notes. So, if I'm reading data from a third-party API and I want it to be a Boolean, then maybe I should do the transformation myself. So maybe I check literally, is it the string true or the string false, and anything else gets rejected?

+ +

Maybe I have...and maybe I'm a little bit more permissive, where I also accept capital T or capital F, and I have, like, some rules for transforming that. But the important thing is I have an explicit conversion step and reject any bad output. And so for something like an environment variable, maybe that would look like looking for true or false and raising if anything else is there. So that we try to boot the app, and it immediately crashes because, hey, we've got some, like, undefined, like, bad configuration that we're trying to load the app with. Don't even try to keep running. Hard crash immediately. Fix it, and then come back.

+ +

STEPHANIE: Yeah, I like that a lot because the way we ended up fixing this issue with the background job that I mentioned was just coercing our string value into a Ruby Boolean in the job that we were then, like, running the conditional in. But really, what we should have done is have fixed that at a higher level and where we parse and deserialize, like, the values we're getting from the job to prevent this kind of in the future because right now, someone can do this again, and that's a real bummer.

+ +

JOËL: I always love those deeper conversations that happen after you've had a bug that are like, how do we prevent this from happening again? Because sometimes that's where you have the deepest learnings or the most interesting insights or, you know, ideas for Bike Shed episodes.

+ +

I'm really curious to contrast JavaScript's approach to truthiness to Ruby's because even though they both use the same idea, they kind of go about it differently.

+ +

STEPHANIE: Tell me more.

+ +

JOËL: So, in Ruby, an empty array and an empty string are truthy. JavaScript decided that empty things are falsy. And I forget...there's a whole table that shows the things that are truthy and falsy in JavaScript. I want to say zero is falsy in JavaScript but don't quote me on that, which can also lead to some interesting edge cases you have to think about.

+ +

STEPHANIE: Okay, yes. This is coming back to me now. I think depending on what, you know, ecosystem or language or world I'm in, I have to just only be able to think about what is true in this world [laughs] and then do that context switching when I am working in something else. But yeah, that is a really interesting idea. Someone decided [laughs] that this was their idea of true or false.

+ +

JOËL: I'm curious if you have a preference for sort of JavaScript's approach to falsiness where a lot more types of values are falsy versus Ruby, which said pretty much only nil and false are falsy. Everything else is truthy.

+ +

STEPHANIE: Hmm, that is an interesting question.

+ +

JOËL: Because in Ruby then or, I guess, in Rails, we end up with the present predicate method that is specifically checking for not only nil and false but also for empty array, empty string, those kinds of things. So, if you find yourself writing a lot of present matchers in your code, you're kind of leaning on something that's closer to JavaScript's definition of falsiness than Ruby's. But maybe you're making it more explicit.

+ +

STEPHANIE: Right. In JavaScript, I see a lot of double bangs in lieu of those predicate methods. But I suppose by nature of having to write those predicate methods in Ruby, we're, like, really wanting something else, I think. And maybe...I guess it is just a question of explicitness like you're saying, and which I prefer. Is it that I need to be explicit to convey the idea that I want, or is it nice that the language has just been encoded that way for me?

+ +

JOËL: Or maybe when you write conditionals, if you find yourself doing a lot of presence checks, do you find that you typically are trying to branch on if not null, not false, not empty more frequently than just if not null, not false? Because that's kind of the difference between Ruby's model and JavaScript's model.

+ +

STEPHANIE: Hmm, the way you posed that question is interesting because it makes me think that sometimes it's quite defensive because we have to check for all these possible return values. We are unsure of what we are getting back. And so this is kind of, like, a catch-all for things that we aren't really sure about.

+ +

JOËL: Yeah, I mean, that's the fun of dynamic programming languages. You never know exactly what you're going to get as long as things respond to certain methods. You really lean into the duck typing. And I think that's Mike's argument in his article that "Booleans Don't Exist" in that as long as something is responding to methods that you care about, it doesn't matter if you're dealing with a true Boolean or some kind of other value.

+ +

STEPHANIE: Right. So I suppose the ideas of truthiness then are a little bit more dependent on how people are using the language though it seems like a chicken-and-egg situation to me. [laughs]

+ +

JOËL: It is really interesting to me in terms of maybe thinking about use cases in my own code if I'm having to...if I'm writing code that leans on truthiness where I can say just, you know if user. But then knowing that, oh, that doesn't account for, like, an empty value. Do I then also need to add an extra check for emptiness? And maybe if I'm in a Rails project, I would reach for that present matcher where I wouldn't have to do that in JavaScript because I can just say, if user, and that already automatically checks for presence.

+ +

So I'm kind of wondering now in my mind, like, which default would fit my use cases more? Or, if I go back to an older version of myself, I will say I don't want any of these defaults. They're all too ambiguous. I'm going to put explicitly if user dot nil question mark, if that's the thing that I'm checking for, or if user dot empty question mark because I want my reader to know what condition I'm checking.

+ +

STEPHANIE: Yeah, that is interesting, this idea of, like, which mode do you find yourself needing to use more and if that is accommodated for you because that's just the more common, like, use case or problem.

+ +

I think that's something that I will be thinking about the next time I write a conditional [laughs] because, like I was saying earlier, I think I end up just leaning on what someone else has decided for me in terms of truthiness and not so much how I would like it to work for me.

+ +

JOËL: And sometimes we don't want to fight the language too much, you know if I'm writing Elm, that everything is hard Booleans. And I know I'm never going to get a nil in a place where I'd expect true or false because the compiler would prevent that from happening. I know that I'm not going to get an empty value, potentially.

+ +

There's ways you can do things with a type system where you can explicitly say no empty values are even allowed at this point. And if you do allow them, then the type system will say, "Hey, you forgot to check for the empty case. Bad program. I'm rejecting that." And then you have to write that explicit branch for, oh, if empty versus if present. So I really appreciate that style of programming.

+ +

But then, when you're in a language like Ruby where you're not dealing with explicit types on purpose, how do you shift that mindset so that you don't need to know the type of the value that you're dealing with? You only want to say, hey, in this context, here's the minimal interface that I want it to conform to. And maybe it's just the truthy or falsiness interface, and everything beyond that is not relevant.

+ +

STEPHANIE: I think it's kind of wild to me that this idea of a binary that theoretically seems very clear turns out is actually quite confusing, ambiguous, philosophical, even. [chuckles]

+ +

JOËL: Yeah. It's definitely...you can get into some deep, philosophical questions there, language design as well.

+ +

One aspect, though, that I'm really curious about your thoughts is bringing new people in who are learning a language. It's really common for people who are learning a language for the first time, learning to code for the first time to write code that you and I would immediately know, like, that's not going to work. You can't add a Boolean and a number. You're just learning to code. You've never done that before. You don't know. And then how the language reacts to that kind of thing can help guide that experience.

+ +

So, do you think that truthiness maybe makes things more confusing for newcomers? Or, maybe on the other side, it helps to smooth that learning curve because you don't have to be like, oh, wait, I have a user here. I can't put that in a condition because that's not a strict true or false. I'm going to coerce it, or I've got to find a predicate method or something. You can just be like, no, put it in. The interpreter will figure it out for you.

+ +

STEPHANIE: Wow. That's a great question. I'm trying to put myself in the beginner's mindset a little bit and think about what it's like to just try something and the magic of it working. Because, like you said, the interpreter does it for you, or whatever, and something happens, and you're like, wow, like, that was really cool. And I didn't have to know all of the ins and outs of the types of things I was working with.

+ +

That can be really helpful in just getting them, like, started and getting them just, like, on the ground writing code. And having that feeling of satisfaction that, like, that they didn't have to, you know, have to learn all these things that can be really scary to make their program work.

+ +

But I do think it also kind of bites them later once they really realize [laughs] what is going on and the minute that they get that, like, unexpected behavior, right? Like, that becomes a time when you do have to figure out what might be going on under the hood. So two sides of the same coin.

+ +

JOËL: What you're saying there about, like, maybe smoothing that initial curve but then it biting them later got me thinking. You know how we have the concept of technical debt where we write code in a way that's maybe not quite as clean today so we can move faster but that then later on we have to pay it back? And I almost wonder if what we have here is almost like a pedagogical debt where it's going to cost us a month from now, but today it helps us move faster and actually kind of get that momentum going.

+ +

STEPHANIE: Pedagogical debt. I like that. I think you've coined a new term. Because I really relate to that where you learn just enough to do the thing now. But, you know, it's probably not, like, the right way or, like, the most informed—I think most informed is probably how I would best describe it—way of doing it. And later, you, yeah, just have to invest a little more into it. And I think that's okay.

+ +

I think sometimes I do tend to, like, beat myself up over something down the line when I have to deal with some piece of less-than-ideal code that I'd written earlier. Like, I think that, oh, I could have avoided this if only I knew. But the whole point is that I didn't know. [laughs] And, like, that's okay, like, maybe I didn't need to know at the time.

+ +

JOËL: Yeah, and code that's never shipped is of zero value. So having something that you could ship is better than having something perfect that you didn't ship.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NPavQzEt + + ]]> + + Joël Quenneville + Stephanie Minn + + + 389: Review Season + https://bikeshed.thoughtbot.com/389 + 509aac3a-4430-4d66-b9dc-70a3ad3e0986 + Tue, 20 Jun 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie just got back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. Joël started a new project at work. + +Review season is upon us. Stephanie and Joël think about growth and goals and talk about reviews: how to do them, how to write them for yourself, and how to write them for others. + 33:45 + no + + + Stephanie just got back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. Joël started a new project at work. +Review season is upon us. Stephanie and Joël think about growth and goals and talk about reviews: how to do them, how to write them for yourself, and how to write them for others. +Blue Ridge Ruby (https://blueridgeruby.com/) +Impactful Articles of 2022 (https://www.bikeshed.fm/369) +Constructive vs Predicative Data by Hillel Wayne (https://www.hillelwayne.com/post/constructive/) +Parse, don’t validate by Alexis King (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) +Working Iteratively (https://thoughtbot.com/blog/working-iteratively) +thoughtbot’s 20th Anniversary Live AMA (https://thoughtbot.com/events/ama-developers-20th-anniversary) +20th Anniversary e-book (https://thoughtbot.com/resources/20-for-20) +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: I just came back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. And I had a really great time. +JOËL: Oooh, I'll bet this is a great time of year to be in Asheville. It's The Blue Ridge Mountains, right? +STEPHANIE: Yeah, exactly. It was perfect weather. It was in the 70s. And yeah, it was just so beautiful there, being surrounded by mountains. And I got to meet a lot of new and old Ruby friends. That was really fun, seeing some just conference folks that I don't normally get to see otherwise. And, yeah, this was my second regional conference, and I think I am really enjoying them. I'm considering prioritizing going to more regional conferences over the ones in some of the bigger cities that Ruby Central puts on moving forward. Just because I really like visiting smaller cities in the U.S., places that I otherwise wouldn't have as strong of a reason to go to. +JOËL: And you weren't just attending this conference; you were speaking. +STEPHANIE: I was, yeah. I gave a talk that I had given before about pair programming and nonviolent communication. And this was my first time giving a talk a second time, which was interesting. Is that something that you've done before? +JOËL: I have not, no. I've created, like, a new bespoke talk for every conference that I've been at, and that's a lot of work. So I love the idea of giving a talk you've given before somewhere else. It seems like, you know, anybody can watch it on the first time on YouTube, generally. But it's not the same as being in the room and getting a chance for someone to see you live and to give a talk, especially at something like a regional conference. It sounds like a great opportunity. What was your experience giving a talk for the second time? +STEPHANIE: Well, I was very excited not to do any more work [chuckles] and thinking that I could just show up [chuckles] and be totally prepared because I'd already done this thing before. And that was not necessarily the case. I still kind of came back to my talk after a few months of not looking at it for a while and had some fresh eyes, rewrote some of the things. I was able to apply a few things that I had learned since giving it the first time around, which was good, just having more perspective and insight into the things that I was talking about. Otherwise, the content didn't really change, just polished it further. +I think in the editing process, you could edit forever, really. So I imagine if I revisit it again, I'll find other things that I want to change. But this time around, I also memorized my slides because, last time, I was a little more dependent on my speaker notes. And part of what I wanted to do this time around, because I had a little more time in preparing, was trying to go from memory. And that went pretty well, I think. +JOËL: How did you feel about the delivery of it? Because now you had a chance to have a practice run in front of a real audience. And, as much as you practice at home in front of the mirror, it's not the same as actually giving a talk in front of an audience. +STEPHANIE: Yeah. I was surprised by how the audience is also different, and the things that they'll react to is slightly different. There were some jokes that landed similarly and others that didn't land a little bit with this crowd, but maybe other parts, there was more of a reaction. So that was surprising. And I think I had to kind of adjust those expectations on the fly as I delivered whatever, you know, line I was kind of expecting some kind of reaction to. +And I also, other than memorizing my slides, you know, I think had the mental capacity to focus a little more on the delivery component that you're talking about because I wasn't, you know, up until the last minute still working on the content itself, and just being able to direct my mental energy to, I guess, the next level of performance when giving a presentation. +And, yeah, I would definitely give this talk again. I really liked that it was something that feels pretty evergreen, something I care a lot about. I don't think it will be a topic that I get kind of bored of anytime soon. So those were all some of the things I was thinking about in giving a talk a second time. +JOËL: When you write your speaker notes, do you give yourself directions for expected audience reactions, so something like a pause for laughter after a joke or something like that? +STEPHANIE: No. I think I am too nervous about presuming [laughs] how the audience will react to put something in and then have to be, like, super surprised and figure out what to do if they don't react the way that I think they will. So it ends up being that I just kind of go forth. And if I do get a reaction out of them, that's great. But not expecting it works for me because then, at least, I can control how I am presenting and how I'm showing [chuckles] up a little bit more. +JOËL: So you're really working with the energy in the room then. +STEPHANIE: Yeah, I think so. +JOËL: Was this talk recorded? So if people in the audience want to go and watch this talk. +STEPHANIE: Yeah. The first version that I gave of it is online if you search for the title "Empathetic Pair Programming with Nonviolent Communication." And this version was recorded as well. So, eventually, it'll also be up. And, I don't know, maybe I'll watch it back and [chuckles] see the difference in presentation. I would be very curious. I've never watched any one of my conference talks fully through the recording from start to end before. But I know that that's something that I could continue to improve on. So maybe one day I'll find the confidence. +My other highlight that I wanted to share about this regional conference is how well-organized it was. So it was mainly organized by Jeremy Smith, and I thought he did such an awesome job. He organized a bunch of activities in Asheville for the Saturday after the conference if folks wanted to stay a little longer and just check out the city. There was a group that went hiking, a group that did a brewery tour. And the activity I chose to do was to go tubing. +JOËL: Fun. +STEPHANIE: Yeah, it was my first time. So you're basically in an inner tube floating down a very calm river, just hanging out. You...we were on the group, and you could clip yourself to the rest of the group so you're all, you know, kind of floating down together. But some people would unclip themselves and just go free for a little while. And, yeah, when you get too hot, you can dip into the water to cool off. And I just had such a great time. [laughs] It was almost like being on a Disney ride but out in nature, which I just, like, is totally my jam. +JOËL: I tried tubing once in Texas. And the inner tubes are black, and in the Texas sun, they get really hot. So every, I don't know, 20 minutes or so, I had to get off the inner tube. It was too hot to sit on. And I had to flip it just because it absorbed so much heat. +STEPHANIE: Wow. Yeah, that does sound like it would get very hot. I think the funny thing that I wasn't expecting was how hard it would be to get back into the inner tube after you had gotten in the water, at least for me, because the inner tubes were quite large. And so I couldn't get enough leverage to pull myself [laughs] back up onto it, and ended up several times just, like, flopping belly first into the inner tube and then having to, like, flop over so that I could be on my back and be sitting in it again. +And other times that I had to wait a little while until the river got shallower so I could actually stand and just sit in it. So there were times that it was kind of a struggle, but 90% of it was very chill and fun. +So, Joël, what's new in your world? +JOËL: I started a new project at work. I'm working with a data warehouse, pulling data in from a variety of sources, getting it all into one kind of unified schema, doing some transformations on it. And then also setting up some sort of outgoing plugins to allow different sources to access that unified data. So this is not in a Rails app, but we do have a Rails app connecting to this data warehouse. +Data engineering is, at least in this style, is newer to me. So I think it's a really interesting world to get into. I don't know if, technically, this counts as big data. I don't think the term is cool anymore. But five or so years ago, everybody was all about the big data, and that was the hip term to toss around. +STEPHANIE: So, is this something pretty new to you? You haven't had too much experience doing this kind of data engineering work before? +JOËL: Yeah, at least not with, like, a data warehouse. I think a lot of the work around data transformations, or creating unified schemas, thinking in terms of data in different stages that are at different levels of correctness...I've done a fair amount of ETL, Extract, Transform, Load, or sometimes people shift it around and say, ELT, Extract, Load, Transform. I've done a fair amount of those because I've done a lot of integrations with third-party systems. +STEPHANIE: So I've always thought of data engineering as, in some ways, a separate role or a track. And I'm really curious about you having, you know, mostly been doing software development if that gives you an interesting lens to look at these problems. +JOËL: So, to get the full answer, you should probably ask me again in six months. +STEPHANIE: That's fair. +JOËL: Initial thoughts is that there's a shocking amount of overlap between some of these ideas, again, because I've done ETL-style projects a lot. You know, if you've got any kind of Rails app and you're integrating with a third-party API, you're often doing ETL at a very small level. To a certain extent, even if you're doing, let's say, some front-end code, and you're interacting with a back end, depending on how you want to deal with that transformation of getting data from your API, you might be doing something kind of like an ETL. +Designing types in something like a TypeScript or an Elm and thinking in terms of the data that you have, the transforms that you're doing has a lot of similarities to what you would do in a data warehouse. I think a lot of the general ideas apply. +I know I talked at the beginning of this year articles that were impactful for me. And one of those articles that was really impactful was Hillel Wayne's "Constructive Versus Predicative Data," which is all about structuring data and when you can enforce constraints via the data structure versus when you need to enforce it via code. +Similarly, a lot of the ideas from the article "Parse, Don't Validate" by Alexis King. The articles focused on designing types. But it also, I think, applies to when you're thinking of schemas because schemas and types are, in a sense, isomorphic to each other. +STEPHANIE: I like what you said there about as a software developer; you've probably done this at a much smaller scale. And, yeah, like you were saying, things that you had already learned about before or thought about before you're able to apply to this different set of problems or, like, different approach to programming. Is there anything that has been challenging for you? +JOËL: Yes, and it's a weird one. Because we're working with enterprise systems, navigating the websites for these enterprise systems and the documentation for them is not a pleasant experience, trying to get a feel for how the system is made to work. It's just so different when you're used to tools and documentation written by the open-source community. +Even third-party tutorials and things it's never, like, oh, here's a great article where you can scan and find the thing that you want. It's, hey, I'm a consultant guru on this thing. Sign up for my webinar, and you can have a 15-hour course on how to use this tool. And that's not what I want to do. I just want give me the five-paragraph blog post on how to do data imports, or how to set up a staging area for data, or something like that. +STEPHANIE: Right. You're basically being asked to develop skills in using the enterprise software rather than more general skills for the problem or task; it sounds like. Because apparently, there are people making a business out of teaching other people how to use or navigate the software. +JOËL: And I think that's fine. I love that people are making businesses of teaching these. But just the way things are structured, information is not generally as available for this large enterprise software as it is in the open-source world, and even when it is, it's just different patterns of access. So even you go to a particular technology's website, and it's all marketing copy. It's all sales funnel and not a lot of actually telling you really what the technology does. It's all, like, really vague, you know, business speak on, you know, empowering your team, and gathering insights, and all this stuff. +So you really do a lot of drilling down. And what you need to find is the developer site. That's where you get the actual tech documentation. Depending on the tech, it's more or less good. But yeah, the official website of the technologies is just...it's not aimed at me as a developer. It's speaking to a different audience. +STEPHANIE: That is interesting. I didn't realize that once you are, you know, working on a data warehouse, it is because you are consuming so many different external sources of data, and having to figure out how to work with each one is part of the process to get what you need. +JOËL: So there's the external services but the data warehouse itself that we're using is an enterprise product. +STEPHANIE: Got it. +JOËL: So, just figuring out how this data warehouse works, it feels like it's a different culture, a different developer culture. +STEPHANIE: That's cool. I'll definitely ask you again in a few months, and I look forward to hearing what you report back. +So the other topic that I wanted to get into today is reviews, specifically self-reviews. To be honest, our review cycle is happening right now. And I have very much procrastinated [chuckles] on writing them until, you know, one or two days before. So I came into our conversation today, like, in that mind space of thinking about my growth, and my goals, and that kind of stuff. +And it got me thinking that I don't hear a lot of people talk about reviews, and how to do them, how to write them for yourself, how to write them for others, how people approach them. Though I would guess that the procrastination part is pretty common, [chuckles] just based on what I'm hearing from other folks on our team too, and what they're up to for the next couple of days before they do. Joël, have you written your review yet? +JOËL: So it's interesting because this review cycle has a few different components. You write a self-review. You write a review of your manager, and then you write a review of several of your peers who have nominated you to write a review. So I've done my own review. I've done my manager's review. I've not completed all of my peer reviews yet. +STEPHANIE: That's pretty good. That's better than me. I've only done my own. [laughs] So, yeah, the deadline is coming up. And I'll probably get back to it right after this. +I'm curious about your process, though, for writing a self-review. Do you come into it having thought about how you've been doing so far in the last six months or so? Or, when you sit down to write it, are you thinking about these things for the first time in a while? +JOËL: Combination. So I think I do come in without necessarily having, like, planned for the review cycle. That being said, throughout the year, I try to build a fair amount of, like, personal self-reflection, professional self-reflection at various points throughout the year. So I'm not coming into the review cycle being like, oh, I have not thought about professional growth at all. What have I done this year? +I think one thing I haven't done quite as well is when I'm doing these moments of self-reflection on my own throughout the year, writing down notes that I could then use to apply when the review cycle comes up. So I am having to rely on memory on, like, oh yeah, last month, when I kind of sat down and thought about areas that I want to improve in or areas that, like, what are my goals that I want to have? And I just commit that to memory. So, yeah, I think live in the moment; now that you've asked me this question, you've made me think that maybe I should be taking more regular notes about this. +STEPHANIE: One thing I've been really liking about the software that we're using for reviews and other professional growth things is...it's called 15Five. And you can give your co-workers shout-outs using this tool. And as I was writing my review, I could actually open all of the kudos and shout-outs that I received from my peers and just remember some of the things that I worked on or a lot of the things that other people noticed. +I tend to sometimes have a hard time remembering some of the smaller things that I've done that made an impact, but other people are usually better about pointing that out than I am. [chuckles] And that has been really helpful because it's, yeah, nice to see like, oh, like, you know, so and so really appreciated when I paired with them on, you know, debugging this thing. And maybe I can pull that into something that I'm writing about the kind of mentorship I've been doing in the last few months. +JOËL: How do you feel about the aspect where you have to then give feedback on colleagues? +STEPHANIE: I really value and enjoy this aspect because most of the time, I am just gassing my colleagues up [chuckles] and writing, you know, really encouraging things about all of the awesome work that they're doing. So, for me, it actually feels really good. +And I was thinking a little bit about my approach to reviewing my peers and review culture in general. I have worked at companies where we have had a very, like, healthy and positive review culture. So it happens often enough that it's become normalized. It's not a really scary thing. And I also like to think about feedback in two types, where you have feedback that you want to give someone so that they can change behavior in a way that helps you work with them better, and then feedback you have for someone for their growth. +And once I separated those two things, I realized that really, the former, if you're, you know, giving someone constructive feedback because you maybe would like them to be doing something different. That's not necessarily what you want to be writing in their annual review. Those things are usually better communicated in a more timely manner, like, right when you are noticing what you might want to be changed. +And so then when you are doing reviews, like, you've hopefully already kind of gotten all of that stuff out of the way. And you can just focus on areas of growth for them, which is the fun part, I think, in reviewing peers because, yeah, you can give some suggestions to further support them in, like, where they want to go. +JOËL: I like that distinction between just general growth, suggestions, and then interaction suggestions. And just to give an example, it sounds like interaction suggestions would be like, "Oh, when we pair, I would like it if you used this style of communication from, let's say, nonviolent communication. Here's a talk; go watch it." +STEPHANIE: [laughs] Yeah, I did talk on this; go watch it. There used to be a framework for reviews that I've done before that I actually don't quite like. It's the Stop, Start, Continue framework where you answer questions about, okay, what should this person stopped doing? What should they continue doing? And what should they start doing? And the things that you would put in stop, I think, are probably what you would want to have communicated in a more timely manner, like, not necessarily it happening, you know, really divorced from whatever behavior you might be asking. +And, in general, I think focusing on what you would like others to be doing instead is usually a better approach to handling that kind of feedback just because it avoids making someone feel bad about having done something wrong and, instead, kind of redirecting them into what you would like them to be doing. +JOËL: So you're saying if you have something in the stop category, let's say stop interrupting me all the time when we're in meetings, you're saying this is something you prefer not to bring up at all or something that you prefer to bring up one on one and not in the context of review? +STEPHANIE: Something to bring up one on one. Ideally, pretty soon after, that might have happened. It's a little more top of mind. And then you don't end up in that position of maybe misremembering or having the other person misremember and having to figure out, like, who was in the right or in the wrong in understanding how that interaction went. Especially if you're able to do it a little sooner after it happened, you can point out, like, hey, this happened. And instead of framing it as please stop interrupting me, you could say, "Could you please make some space for some folks who've been a little more quiet in the meetings to make sure that they've been able to share?" +Still, I think once you've made more space to give that kind of constructive feedback when you are writing reviews, you can then, like, focus on the growth aspect and not the redirection of how others are doing their work. +JOËL: That makes sense. So, what would be an example of the kind of feedback that you like to give to other people in the context of a review? +STEPHANIE: Yeah, I think especially if I know what someone is wanting to focus on, right? If I'm working with someone, hopefully, we've kind of gotten to talk about what they like to work on, what they don't like to work on, what they are hoping to spend more time doing, or yeah, just their hopes and dreams for their professional [chuckles] development, being able to point out some things that they maybe haven't thought about trying it I really like to do. +I was thinking about a time when I gave a co-worker some feedback as a mentee of theirs where they had been really awesome at providing information to me about things that I was unfamiliar with. But one thing that I was really hoping for was more tools to figure things out on my own. So instead of sending me a link to some documentation, maybe helping me figure out how to search for the documentation that I'm looking for. And that was something that I could share with them because I knew that they wanted to work on their mentorship skills and an opportunity, I think, for them to take it to a level where it's closer to coaching and not just providing information. +JOËL: That makes a lot of sense. Maybe flipping it around, is there a point in time where you've received a review feedback that has been really valuable to you or really helped you hit the next level in your career? +STEPHANIE: I really appreciate feedback that encourages me when I'm maybe a little bit too timid to go seek the things out myself. So there were times when I received some feedback about how great of a leader I could be before I thought I was ready to be a leader. And they pointed out the qualities of leadership that I had demonstrated that led them to believe that I would be ready for a role like that. And that was really helpful because I don't think that was even necessarily a short-term goal of mine. And it took someone else saying, "I think you're ready," that made me feel a lot more confident about opening that door. +I guess this is all to say that I really love review season because of, you know, all of the support I get from my co-workers. And, yeah, just remembering that it's not just a journey I have to take all by myself, that the point of working with other people is for all of us to help each other grow. +JOËL: I think something that you mentioned earlier really connected with me, the idea of trying to give feedback in the...even, like, feedback that's about changing or improving, phrasing it in a more positive way, or at least framing it in a more positive way. So here's an opportunity for growth rather than here's the thing you're doing wrong. Because that reminds me of two pieces of review that I got when I was a fairly junior developer that have stuck with me ever since. And one of them was really a catalyst for growth, and the other one kind of haunted me. +So this first one I got, someone in a review just mentioned that they thought that I was just generally a slow developer, just not fast at writing code. Not a whole lot of context; just that's who I was. And, in a sense, it was almost like I'd been given this identity, like, oh, I am now Joël, the slow developer. And I didn't want that identity. So I'm kind of like, I want to refuse to accept it. But at the same time, there's always that self-doubt in the back. And now, anytime I'm on a project with someone else, I'm comparing, oh, am I shipping stories quite as fast as someone else? And if not, why? Is it because I'm a slow developer? +Or if I'm having a rough day and I'm not getting the ticket done that I was hoping to get done by the end of the day, you know, you just get that voice in the back of your head that's like, oh, it's because you're a slow developer. Someone called that out last year, and they were right. So, in a sense, it kind of haunted me. +On the flip side, I once got some feedback talking about an opportunity for growth. If I focused on working in more iterative, incremental chunks, it would help have a smoother workflow and probably help me work faster as well. And that was really kind of an exciting opportunity. It's also stuck with me for years but not in the sort of haunting sort of way or this, like, bring in self-doubt but more in terms of opportunity. +Because now I'm always like, oh, can I break this down into even smaller chunks? Would that help me move faster? Would that help me be less blocked on other people? Would that be easier for our QA team? Would this be easier for review for my colleagues? Just a lot of different opportunities for benefits with working in smaller iterative chunks. +And, for years, I've just been kind of honing that skill. And now, looking back over, you know, a decade of doing this, I think it's one of the best skills that I have. And so, in a sense, I feel like both of these people that left me that review, in a sense, they're trying to get me to maybe have a slightly higher velocity. But they're different approaches, radically different in terms of how it impacted me as a person. +STEPHANIE: Yeah, I am really glad you brought that up. Because I definitely have also received, quote, unquote, "constructive feedback," but maybe wasn't phrased in the right way, that also haunted me. And it doesn't feel good. I think that that sucks. That person wasn't really able to frame it in a way that pushed you to progress in the positive way that you mentioned with learning to work incrementally. +And in fact, I almost think that the difference in those two phrasings is encapsulated by a framework for giving feedback that's actionable, specific, and kind. So suggesting you to work incrementally is all of those things, especially if they know that you do want to increase your velocity. But you're being supported in doing it in a way that is positive and growth-oriented as opposed to, like, out of fear that other people think that you are a slow developer. And, you know, that's certainly a way that people are motivated. But I would say that that's not the way that we want to be motivated. [laughs] +JOËL: I'm glad we're having this conversation because I think it just reinforces to me just the value of good communication skills for developers. And, you know, you can see that when developers have to write documentation, or even things like comments or commit messages. You see it when developers write blog posts. So it's really valuable to work on your communication skills in a lot of these technical areas. +But reviews are a very particular area where it's easy to maybe have not the impact that you wanted because you communicated a core idea that's probably right, but just the way it was communicated was not going to have the impact that you're hoping for. And so getting good at communicating specifically in the area of reviews, which I assume most of us in the software industry are doing on a semi-regular basis, is probably a good tool to have in your professional tool belt. +STEPHANIE: Absolutely. +JOËL: We recently hit a big milestone at thoughtbot, where thoughtbot turned 20 years old in early June. And so, throughout June, we've been doing a lot of fun internal things and some external things to celebrate turning 20. And one of those is we're hosting a live AMA with a variety of thoughtbot devs. That's going to be on Friday, June 23rd, so a couple of days after this podcast goes live. +So, to our listeners, if you're listening to this, in the first few days after it goes live, you get a chance to join in on the live AMA and ask your questions of our team as we celebrate 20 years. There's a blog post with all the details, and we'll link to that in the show notes. +STEPHANIE: One other thing that I think we're doing that's really cool for our 20th anniversary is we published a short ebook with a curated collection of 20 hits from our blog, the thoughtbot blog, over the course of its history, some of the more popular and impactful blog posts that we've ever published. So I highly recommend checking that out. You know, the thoughtbot blog is such an awesome resource. And I discovered a few things that I hadn't read before on the blog from this ebook. So that will also be linked in the show notes. +JOËL: I mentioned earlier how one of my opportunities for growth through review was getting better at working iteratively. And, a couple of years ago, I took a lot of the lessons that I'd learned over the years of getting better at working iteratively, and I put them in a blog post, and that blog post made it into that 20th Anniversary ebook. So we can probably link the blog post itself in the show notes. But also, if you're picking up that ebook, you'll get a chance to see that article on my lessons learned on how to work iteratively. +STEPHANIE: Awesome. On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie just got back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. Joël started a new project at work.

+ +

Review season is upon us. Stephanie and Joël think about growth and goals and talk about reviews: how to do them, how to write them for yourself, and how to write them for others.

+ +
+ + + +

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: I just came back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. And I had a really great time.

+ +

JOËL: Oooh, I'll bet this is a great time of year to be in Asheville. It's The Blue Ridge Mountains, right?

+ +

STEPHANIE: Yeah, exactly. It was perfect weather. It was in the 70s. And yeah, it was just so beautiful there, being surrounded by mountains. And I got to meet a lot of new and old Ruby friends. That was really fun, seeing some just conference folks that I don't normally get to see otherwise. And, yeah, this was my second regional conference, and I think I am really enjoying them. I'm considering prioritizing going to more regional conferences over the ones in some of the bigger cities that Ruby Central puts on moving forward. Just because I really like visiting smaller cities in the U.S., places that I otherwise wouldn't have as strong of a reason to go to.

+ +

JOËL: And you weren't just attending this conference; you were speaking.

+ +

STEPHANIE: I was, yeah. I gave a talk that I had given before about pair programming and nonviolent communication. And this was my first time giving a talk a second time, which was interesting. Is that something that you've done before?

+ +

JOËL: I have not, no. I've created, like, a new bespoke talk for every conference that I've been at, and that's a lot of work. So I love the idea of giving a talk you've given before somewhere else. It seems like, you know, anybody can watch it on the first time on YouTube, generally. But it's not the same as being in the room and getting a chance for someone to see you live and to give a talk, especially at something like a regional conference. It sounds like a great opportunity. What was your experience giving a talk for the second time?

+ +

STEPHANIE: Well, I was very excited not to do any more work [chuckles] and thinking that I could just show up [chuckles] and be totally prepared because I'd already done this thing before. And that was not necessarily the case. I still kind of came back to my talk after a few months of not looking at it for a while and had some fresh eyes, rewrote some of the things. I was able to apply a few things that I had learned since giving it the first time around, which was good, just having more perspective and insight into the things that I was talking about. Otherwise, the content didn't really change, just polished it further.

+ +

I think in the editing process, you could edit forever, really. So I imagine if I revisit it again, I'll find other things that I want to change. But this time around, I also memorized my slides because, last time, I was a little more dependent on my speaker notes. And part of what I wanted to do this time around, because I had a little more time in preparing, was trying to go from memory. And that went pretty well, I think.

+ +

JOËL: How did you feel about the delivery of it? Because now you had a chance to have a practice run in front of a real audience. And, as much as you practice at home in front of the mirror, it's not the same as actually giving a talk in front of an audience.

+ +

STEPHANIE: Yeah. I was surprised by how the audience is also different, and the things that they'll react to is slightly different. There were some jokes that landed similarly and others that didn't land a little bit with this crowd, but maybe other parts, there was more of a reaction. So that was surprising. And I think I had to kind of adjust those expectations on the fly as I delivered whatever, you know, line I was kind of expecting some kind of reaction to.

+ +

And I also, other than memorizing my slides, you know, I think had the mental capacity to focus a little more on the delivery component that you're talking about because I wasn't, you know, up until the last minute still working on the content itself, and just being able to direct my mental energy to, I guess, the next level of performance when giving a presentation.

+ +

And, yeah, I would definitely give this talk again. I really liked that it was something that feels pretty evergreen, something I care a lot about. I don't think it will be a topic that I get kind of bored of anytime soon. So those were all some of the things I was thinking about in giving a talk a second time.

+ +

JOËL: When you write your speaker notes, do you give yourself directions for expected audience reactions, so something like a pause for laughter after a joke or something like that?

+ +

STEPHANIE: No. I think I am too nervous about presuming [laughs] how the audience will react to put something in and then have to be, like, super surprised and figure out what to do if they don't react the way that I think they will. So it ends up being that I just kind of go forth. And if I do get a reaction out of them, that's great. But not expecting it works for me because then, at least, I can control how I am presenting and how I'm showing [chuckles] up a little bit more.

+ +

JOËL: So you're really working with the energy in the room then.

+ +

STEPHANIE: Yeah, I think so.

+ +

JOËL: Was this talk recorded? So if people in the audience want to go and watch this talk.

+ +

STEPHANIE: Yeah. The first version that I gave of it is online if you search for the title "Empathetic Pair Programming with Nonviolent Communication." And this version was recorded as well. So, eventually, it'll also be up. And, I don't know, maybe I'll watch it back and [chuckles] see the difference in presentation. I would be very curious. I've never watched any one of my conference talks fully through the recording from start to end before. But I know that that's something that I could continue to improve on. So maybe one day I'll find the confidence.

+ +

My other highlight that I wanted to share about this regional conference is how well-organized it was. So it was mainly organized by Jeremy Smith, and I thought he did such an awesome job. He organized a bunch of activities in Asheville for the Saturday after the conference if folks wanted to stay a little longer and just check out the city. There was a group that went hiking, a group that did a brewery tour. And the activity I chose to do was to go tubing.

+ +

JOËL: Fun.

+ +

STEPHANIE: Yeah, it was my first time. So you're basically in an inner tube floating down a very calm river, just hanging out. You...we were on the group, and you could clip yourself to the rest of the group so you're all, you know, kind of floating down together. But some people would unclip themselves and just go free for a little while. And, yeah, when you get too hot, you can dip into the water to cool off. And I just had such a great time. [laughs] It was almost like being on a Disney ride but out in nature, which I just, like, is totally my jam.

+ +

JOËL: I tried tubing once in Texas. And the inner tubes are black, and in the Texas sun, they get really hot. So every, I don't know, 20 minutes or so, I had to get off the inner tube. It was too hot to sit on. And I had to flip it just because it absorbed so much heat.

+ +

STEPHANIE: Wow. Yeah, that does sound like it would get very hot. I think the funny thing that I wasn't expecting was how hard it would be to get back into the inner tube after you had gotten in the water, at least for me, because the inner tubes were quite large. And so I couldn't get enough leverage to pull myself [laughs] back up onto it, and ended up several times just, like, flopping belly first into the inner tube and then having to, like, flop over so that I could be on my back and be sitting in it again.

+ +

And other times that I had to wait a little while until the river got shallower so I could actually stand and just sit in it. So there were times that it was kind of a struggle, but 90% of it was very chill and fun.

+ +

So, Joël, what's new in your world?

+ +

JOËL: I started a new project at work. I'm working with a data warehouse, pulling data in from a variety of sources, getting it all into one kind of unified schema, doing some transformations on it. And then also setting up some sort of outgoing plugins to allow different sources to access that unified data. So this is not in a Rails app, but we do have a Rails app connecting to this data warehouse.

+ +

Data engineering is, at least in this style, is newer to me. So I think it's a really interesting world to get into. I don't know if, technically, this counts as big data. I don't think the term is cool anymore. But five or so years ago, everybody was all about the big data, and that was the hip term to toss around.

+ +

STEPHANIE: So, is this something pretty new to you? You haven't had too much experience doing this kind of data engineering work before?

+ +

JOËL: Yeah, at least not with, like, a data warehouse. I think a lot of the work around data transformations, or creating unified schemas, thinking in terms of data in different stages that are at different levels of correctness...I've done a fair amount of ETL, Extract, Transform, Load, or sometimes people shift it around and say, ELT, Extract, Load, Transform. I've done a fair amount of those because I've done a lot of integrations with third-party systems.

+ +

STEPHANIE: So I've always thought of data engineering as, in some ways, a separate role or a track. And I'm really curious about you having, you know, mostly been doing software development if that gives you an interesting lens to look at these problems.

+ +

JOËL: So, to get the full answer, you should probably ask me again in six months.

+ +

STEPHANIE: That's fair.

+ +

JOËL: Initial thoughts is that there's a shocking amount of overlap between some of these ideas, again, because I've done ETL-style projects a lot. You know, if you've got any kind of Rails app and you're integrating with a third-party API, you're often doing ETL at a very small level. To a certain extent, even if you're doing, let's say, some front-end code, and you're interacting with a back end, depending on how you want to deal with that transformation of getting data from your API, you might be doing something kind of like an ETL.

+ +

Designing types in something like a TypeScript or an Elm and thinking in terms of the data that you have, the transforms that you're doing has a lot of similarities to what you would do in a data warehouse. I think a lot of the general ideas apply.

+ +

I know I talked at the beginning of this year articles that were impactful for me. And one of those articles that was really impactful was Hillel Wayne's "Constructive Versus Predicative Data," which is all about structuring data and when you can enforce constraints via the data structure versus when you need to enforce it via code.

+ +

Similarly, a lot of the ideas from the article "Parse, Don't Validate" by Alexis King. The articles focused on designing types. But it also, I think, applies to when you're thinking of schemas because schemas and types are, in a sense, isomorphic to each other.

+ +

STEPHANIE: I like what you said there about as a software developer; you've probably done this at a much smaller scale. And, yeah, like you were saying, things that you had already learned about before or thought about before you're able to apply to this different set of problems or, like, different approach to programming. Is there anything that has been challenging for you?

+ +

JOËL: Yes, and it's a weird one. Because we're working with enterprise systems, navigating the websites for these enterprise systems and the documentation for them is not a pleasant experience, trying to get a feel for how the system is made to work. It's just so different when you're used to tools and documentation written by the open-source community.

+ +

Even third-party tutorials and things it's never, like, oh, here's a great article where you can scan and find the thing that you want. It's, hey, I'm a consultant guru on this thing. Sign up for my webinar, and you can have a 15-hour course on how to use this tool. And that's not what I want to do. I just want give me the five-paragraph blog post on how to do data imports, or how to set up a staging area for data, or something like that.

+ +

STEPHANIE: Right. You're basically being asked to develop skills in using the enterprise software rather than more general skills for the problem or task; it sounds like. Because apparently, there are people making a business out of teaching other people how to use or navigate the software.

+ +

JOËL: And I think that's fine. I love that people are making businesses of teaching these. But just the way things are structured, information is not generally as available for this large enterprise software as it is in the open-source world, and even when it is, it's just different patterns of access. So even you go to a particular technology's website, and it's all marketing copy. It's all sales funnel and not a lot of actually telling you really what the technology does. It's all, like, really vague, you know, business speak on, you know, empowering your team, and gathering insights, and all this stuff.

+ +

So you really do a lot of drilling down. And what you need to find is the developer site. That's where you get the actual tech documentation. Depending on the tech, it's more or less good. But yeah, the official website of the technologies is just...it's not aimed at me as a developer. It's speaking to a different audience.

+ +

STEPHANIE: That is interesting. I didn't realize that once you are, you know, working on a data warehouse, it is because you are consuming so many different external sources of data, and having to figure out how to work with each one is part of the process to get what you need.

+ +

JOËL: So there's the external services but the data warehouse itself that we're using is an enterprise product.

+ +

STEPHANIE: Got it.

+ +

JOËL: So, just figuring out how this data warehouse works, it feels like it's a different culture, a different developer culture.

+ +

STEPHANIE: That's cool. I'll definitely ask you again in a few months, and I look forward to hearing what you report back.

+ +

So the other topic that I wanted to get into today is reviews, specifically self-reviews. To be honest, our review cycle is happening right now. And I have very much procrastinated [chuckles] on writing them until, you know, one or two days before. So I came into our conversation today, like, in that mind space of thinking about my growth, and my goals, and that kind of stuff.

+ +

And it got me thinking that I don't hear a lot of people talk about reviews, and how to do them, how to write them for yourself, how to write them for others, how people approach them. Though I would guess that the procrastination part is pretty common, [chuckles] just based on what I'm hearing from other folks on our team too, and what they're up to for the next couple of days before they do. Joël, have you written your review yet?

+ +

JOËL: So it's interesting because this review cycle has a few different components. You write a self-review. You write a review of your manager, and then you write a review of several of your peers who have nominated you to write a review. So I've done my own review. I've done my manager's review. I've not completed all of my peer reviews yet.

+ +

STEPHANIE: That's pretty good. That's better than me. I've only done my own. [laughs] So, yeah, the deadline is coming up. And I'll probably get back to it right after this.

+ +

I'm curious about your process, though, for writing a self-review. Do you come into it having thought about how you've been doing so far in the last six months or so? Or, when you sit down to write it, are you thinking about these things for the first time in a while?

+ +

JOËL: Combination. So I think I do come in without necessarily having, like, planned for the review cycle. That being said, throughout the year, I try to build a fair amount of, like, personal self-reflection, professional self-reflection at various points throughout the year. So I'm not coming into the review cycle being like, oh, I have not thought about professional growth at all. What have I done this year?

+ +

I think one thing I haven't done quite as well is when I'm doing these moments of self-reflection on my own throughout the year, writing down notes that I could then use to apply when the review cycle comes up. So I am having to rely on memory on, like, oh yeah, last month, when I kind of sat down and thought about areas that I want to improve in or areas that, like, what are my goals that I want to have? And I just commit that to memory. So, yeah, I think live in the moment; now that you've asked me this question, you've made me think that maybe I should be taking more regular notes about this.

+ +

STEPHANIE: One thing I've been really liking about the software that we're using for reviews and other professional growth things is...it's called 15Five. And you can give your co-workers shout-outs using this tool. And as I was writing my review, I could actually open all of the kudos and shout-outs that I received from my peers and just remember some of the things that I worked on or a lot of the things that other people noticed.

+ +

I tend to sometimes have a hard time remembering some of the smaller things that I've done that made an impact, but other people are usually better about pointing that out than I am. [chuckles] And that has been really helpful because it's, yeah, nice to see like, oh, like, you know, so and so really appreciated when I paired with them on, you know, debugging this thing. And maybe I can pull that into something that I'm writing about the kind of mentorship I've been doing in the last few months.

+ +

JOËL: How do you feel about the aspect where you have to then give feedback on colleagues?

+ +

STEPHANIE: I really value and enjoy this aspect because most of the time, I am just gassing my colleagues up [chuckles] and writing, you know, really encouraging things about all of the awesome work that they're doing. So, for me, it actually feels really good.

+ +

And I was thinking a little bit about my approach to reviewing my peers and review culture in general. I have worked at companies where we have had a very, like, healthy and positive review culture. So it happens often enough that it's become normalized. It's not a really scary thing. And I also like to think about feedback in two types, where you have feedback that you want to give someone so that they can change behavior in a way that helps you work with them better, and then feedback you have for someone for their growth.

+ +

And once I separated those two things, I realized that really, the former, if you're, you know, giving someone constructive feedback because you maybe would like them to be doing something different. That's not necessarily what you want to be writing in their annual review. Those things are usually better communicated in a more timely manner, like, right when you are noticing what you might want to be changed.

+ +

And so then when you are doing reviews, like, you've hopefully already kind of gotten all of that stuff out of the way. And you can just focus on areas of growth for them, which is the fun part, I think, in reviewing peers because, yeah, you can give some suggestions to further support them in, like, where they want to go.

+ +

JOËL: I like that distinction between just general growth, suggestions, and then interaction suggestions. And just to give an example, it sounds like interaction suggestions would be like, "Oh, when we pair, I would like it if you used this style of communication from, let's say, nonviolent communication. Here's a talk; go watch it."

+ +

STEPHANIE: [laughs] Yeah, I did talk on this; go watch it. There used to be a framework for reviews that I've done before that I actually don't quite like. It's the Stop, Start, Continue framework where you answer questions about, okay, what should this person stopped doing? What should they continue doing? And what should they start doing? And the things that you would put in stop, I think, are probably what you would want to have communicated in a more timely manner, like, not necessarily it happening, you know, really divorced from whatever behavior you might be asking.

+ +

And, in general, I think focusing on what you would like others to be doing instead is usually a better approach to handling that kind of feedback just because it avoids making someone feel bad about having done something wrong and, instead, kind of redirecting them into what you would like them to be doing.

+ +

JOËL: So you're saying if you have something in the stop category, let's say stop interrupting me all the time when we're in meetings, you're saying this is something you prefer not to bring up at all or something that you prefer to bring up one on one and not in the context of review?

+ +

STEPHANIE: Something to bring up one on one. Ideally, pretty soon after, that might have happened. It's a little more top of mind. And then you don't end up in that position of maybe misremembering or having the other person misremember and having to figure out, like, who was in the right or in the wrong in understanding how that interaction went. Especially if you're able to do it a little sooner after it happened, you can point out, like, hey, this happened. And instead of framing it as please stop interrupting me, you could say, "Could you please make some space for some folks who've been a little more quiet in the meetings to make sure that they've been able to share?"

+ +

Still, I think once you've made more space to give that kind of constructive feedback when you are writing reviews, you can then, like, focus on the growth aspect and not the redirection of how others are doing their work.

+ +

JOËL: That makes sense. So, what would be an example of the kind of feedback that you like to give to other people in the context of a review?

+ +

STEPHANIE: Yeah, I think especially if I know what someone is wanting to focus on, right? If I'm working with someone, hopefully, we've kind of gotten to talk about what they like to work on, what they don't like to work on, what they are hoping to spend more time doing, or yeah, just their hopes and dreams for their professional [chuckles] development, being able to point out some things that they maybe haven't thought about trying it I really like to do.

+ +

I was thinking about a time when I gave a co-worker some feedback as a mentee of theirs where they had been really awesome at providing information to me about things that I was unfamiliar with. But one thing that I was really hoping for was more tools to figure things out on my own. So instead of sending me a link to some documentation, maybe helping me figure out how to search for the documentation that I'm looking for. And that was something that I could share with them because I knew that they wanted to work on their mentorship skills and an opportunity, I think, for them to take it to a level where it's closer to coaching and not just providing information.

+ +

JOËL: That makes a lot of sense. Maybe flipping it around, is there a point in time where you've received a review feedback that has been really valuable to you or really helped you hit the next level in your career?

+ +

STEPHANIE: I really appreciate feedback that encourages me when I'm maybe a little bit too timid to go seek the things out myself. So there were times when I received some feedback about how great of a leader I could be before I thought I was ready to be a leader. And they pointed out the qualities of leadership that I had demonstrated that led them to believe that I would be ready for a role like that. And that was really helpful because I don't think that was even necessarily a short-term goal of mine. And it took someone else saying, "I think you're ready," that made me feel a lot more confident about opening that door.

+ +

I guess this is all to say that I really love review season because of, you know, all of the support I get from my co-workers. And, yeah, just remembering that it's not just a journey I have to take all by myself, that the point of working with other people is for all of us to help each other grow.

+ +

JOËL: I think something that you mentioned earlier really connected with me, the idea of trying to give feedback in the...even, like, feedback that's about changing or improving, phrasing it in a more positive way, or at least framing it in a more positive way. So here's an opportunity for growth rather than here's the thing you're doing wrong. Because that reminds me of two pieces of review that I got when I was a fairly junior developer that have stuck with me ever since. And one of them was really a catalyst for growth, and the other one kind of haunted me.

+ +

So this first one I got, someone in a review just mentioned that they thought that I was just generally a slow developer, just not fast at writing code. Not a whole lot of context; just that's who I was. And, in a sense, it was almost like I'd been given this identity, like, oh, I am now Joël, the slow developer. And I didn't want that identity. So I'm kind of like, I want to refuse to accept it. But at the same time, there's always that self-doubt in the back. And now, anytime I'm on a project with someone else, I'm comparing, oh, am I shipping stories quite as fast as someone else? And if not, why? Is it because I'm a slow developer?

+ +

Or if I'm having a rough day and I'm not getting the ticket done that I was hoping to get done by the end of the day, you know, you just get that voice in the back of your head that's like, oh, it's because you're a slow developer. Someone called that out last year, and they were right. So, in a sense, it kind of haunted me.

+ +

On the flip side, I once got some feedback talking about an opportunity for growth. If I focused on working in more iterative, incremental chunks, it would help have a smoother workflow and probably help me work faster as well. And that was really kind of an exciting opportunity. It's also stuck with me for years but not in the sort of haunting sort of way or this, like, bring in self-doubt but more in terms of opportunity.

+ +

Because now I'm always like, oh, can I break this down into even smaller chunks? Would that help me move faster? Would that help me be less blocked on other people? Would that be easier for our QA team? Would this be easier for review for my colleagues? Just a lot of different opportunities for benefits with working in smaller iterative chunks.

+ +

And, for years, I've just been kind of honing that skill. And now, looking back over, you know, a decade of doing this, I think it's one of the best skills that I have. And so, in a sense, I feel like both of these people that left me that review, in a sense, they're trying to get me to maybe have a slightly higher velocity. But they're different approaches, radically different in terms of how it impacted me as a person.

+ +

STEPHANIE: Yeah, I am really glad you brought that up. Because I definitely have also received, quote, unquote, "constructive feedback," but maybe wasn't phrased in the right way, that also haunted me. And it doesn't feel good. I think that that sucks. That person wasn't really able to frame it in a way that pushed you to progress in the positive way that you mentioned with learning to work incrementally.

+ +

And in fact, I almost think that the difference in those two phrasings is encapsulated by a framework for giving feedback that's actionable, specific, and kind. So suggesting you to work incrementally is all of those things, especially if they know that you do want to increase your velocity. But you're being supported in doing it in a way that is positive and growth-oriented as opposed to, like, out of fear that other people think that you are a slow developer. And, you know, that's certainly a way that people are motivated. But I would say that that's not the way that we want to be motivated. [laughs]

+ +

JOËL: I'm glad we're having this conversation because I think it just reinforces to me just the value of good communication skills for developers. And, you know, you can see that when developers have to write documentation, or even things like comments or commit messages. You see it when developers write blog posts. So it's really valuable to work on your communication skills in a lot of these technical areas.

+ +

But reviews are a very particular area where it's easy to maybe have not the impact that you wanted because you communicated a core idea that's probably right, but just the way it was communicated was not going to have the impact that you're hoping for. And so getting good at communicating specifically in the area of reviews, which I assume most of us in the software industry are doing on a semi-regular basis, is probably a good tool to have in your professional tool belt.

+ +

STEPHANIE: Absolutely.

+ +

JOËL: We recently hit a big milestone at thoughtbot, where thoughtbot turned 20 years old in early June. And so, throughout June, we've been doing a lot of fun internal things and some external things to celebrate turning 20. And one of those is we're hosting a live AMA with a variety of thoughtbot devs. That's going to be on Friday, June 23rd, so a couple of days after this podcast goes live.

+ +

So, to our listeners, if you're listening to this, in the first few days after it goes live, you get a chance to join in on the live AMA and ask your questions of our team as we celebrate 20 years. There's a blog post with all the details, and we'll link to that in the show notes.

+ +

STEPHANIE: One other thing that I think we're doing that's really cool for our 20th anniversary is we published a short ebook with a curated collection of 20 hits from our blog, the thoughtbot blog, over the course of its history, some of the more popular and impactful blog posts that we've ever published. So I highly recommend checking that out. You know, the thoughtbot blog is such an awesome resource. And I discovered a few things that I hadn't read before on the blog from this ebook. So that will also be linked in the show notes.

+ +

JOËL: I mentioned earlier how one of my opportunities for growth through review was getting better at working iteratively. And, a couple of years ago, I took a lot of the lessons that I'd learned over the years of getting better at working iteratively, and I put them in a blog post, and that blog post made it into that 20th Anniversary ebook. So we can probably link the blog post itself in the show notes. But also, if you're picking up that ebook, you'll get a chance to see that article on my lessons learned on how to work iteratively.

+ +

STEPHANIE: Awesome. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie just got back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. Joël started a new project at work.

+ +

Review season is upon us. Stephanie and Joël think about growth and goals and talk about reviews: how to do them, how to write them for yourself, and how to write them for others.

+ +
+ + + +

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: I just came back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. And I had a really great time.

+ +

JOËL: Oooh, I'll bet this is a great time of year to be in Asheville. It's The Blue Ridge Mountains, right?

+ +

STEPHANIE: Yeah, exactly. It was perfect weather. It was in the 70s. And yeah, it was just so beautiful there, being surrounded by mountains. And I got to meet a lot of new and old Ruby friends. That was really fun, seeing some just conference folks that I don't normally get to see otherwise. And, yeah, this was my second regional conference, and I think I am really enjoying them. I'm considering prioritizing going to more regional conferences over the ones in some of the bigger cities that Ruby Central puts on moving forward. Just because I really like visiting smaller cities in the U.S., places that I otherwise wouldn't have as strong of a reason to go to.

+ +

JOËL: And you weren't just attending this conference; you were speaking.

+ +

STEPHANIE: I was, yeah. I gave a talk that I had given before about pair programming and nonviolent communication. And this was my first time giving a talk a second time, which was interesting. Is that something that you've done before?

+ +

JOËL: I have not, no. I've created, like, a new bespoke talk for every conference that I've been at, and that's a lot of work. So I love the idea of giving a talk you've given before somewhere else. It seems like, you know, anybody can watch it on the first time on YouTube, generally. But it's not the same as being in the room and getting a chance for someone to see you live and to give a talk, especially at something like a regional conference. It sounds like a great opportunity. What was your experience giving a talk for the second time?

+ +

STEPHANIE: Well, I was very excited not to do any more work [chuckles] and thinking that I could just show up [chuckles] and be totally prepared because I'd already done this thing before. And that was not necessarily the case. I still kind of came back to my talk after a few months of not looking at it for a while and had some fresh eyes, rewrote some of the things. I was able to apply a few things that I had learned since giving it the first time around, which was good, just having more perspective and insight into the things that I was talking about. Otherwise, the content didn't really change, just polished it further.

+ +

I think in the editing process, you could edit forever, really. So I imagine if I revisit it again, I'll find other things that I want to change. But this time around, I also memorized my slides because, last time, I was a little more dependent on my speaker notes. And part of what I wanted to do this time around, because I had a little more time in preparing, was trying to go from memory. And that went pretty well, I think.

+ +

JOËL: How did you feel about the delivery of it? Because now you had a chance to have a practice run in front of a real audience. And, as much as you practice at home in front of the mirror, it's not the same as actually giving a talk in front of an audience.

+ +

STEPHANIE: Yeah. I was surprised by how the audience is also different, and the things that they'll react to is slightly different. There were some jokes that landed similarly and others that didn't land a little bit with this crowd, but maybe other parts, there was more of a reaction. So that was surprising. And I think I had to kind of adjust those expectations on the fly as I delivered whatever, you know, line I was kind of expecting some kind of reaction to.

+ +

And I also, other than memorizing my slides, you know, I think had the mental capacity to focus a little more on the delivery component that you're talking about because I wasn't, you know, up until the last minute still working on the content itself, and just being able to direct my mental energy to, I guess, the next level of performance when giving a presentation.

+ +

And, yeah, I would definitely give this talk again. I really liked that it was something that feels pretty evergreen, something I care a lot about. I don't think it will be a topic that I get kind of bored of anytime soon. So those were all some of the things I was thinking about in giving a talk a second time.

+ +

JOËL: When you write your speaker notes, do you give yourself directions for expected audience reactions, so something like a pause for laughter after a joke or something like that?

+ +

STEPHANIE: No. I think I am too nervous about presuming [laughs] how the audience will react to put something in and then have to be, like, super surprised and figure out what to do if they don't react the way that I think they will. So it ends up being that I just kind of go forth. And if I do get a reaction out of them, that's great. But not expecting it works for me because then, at least, I can control how I am presenting and how I'm showing [chuckles] up a little bit more.

+ +

JOËL: So you're really working with the energy in the room then.

+ +

STEPHANIE: Yeah, I think so.

+ +

JOËL: Was this talk recorded? So if people in the audience want to go and watch this talk.

+ +

STEPHANIE: Yeah. The first version that I gave of it is online if you search for the title "Empathetic Pair Programming with Nonviolent Communication." And this version was recorded as well. So, eventually, it'll also be up. And, I don't know, maybe I'll watch it back and [chuckles] see the difference in presentation. I would be very curious. I've never watched any one of my conference talks fully through the recording from start to end before. But I know that that's something that I could continue to improve on. So maybe one day I'll find the confidence.

+ +

My other highlight that I wanted to share about this regional conference is how well-organized it was. So it was mainly organized by Jeremy Smith, and I thought he did such an awesome job. He organized a bunch of activities in Asheville for the Saturday after the conference if folks wanted to stay a little longer and just check out the city. There was a group that went hiking, a group that did a brewery tour. And the activity I chose to do was to go tubing.

+ +

JOËL: Fun.

+ +

STEPHANIE: Yeah, it was my first time. So you're basically in an inner tube floating down a very calm river, just hanging out. You...we were on the group, and you could clip yourself to the rest of the group so you're all, you know, kind of floating down together. But some people would unclip themselves and just go free for a little while. And, yeah, when you get too hot, you can dip into the water to cool off. And I just had such a great time. [laughs] It was almost like being on a Disney ride but out in nature, which I just, like, is totally my jam.

+ +

JOËL: I tried tubing once in Texas. And the inner tubes are black, and in the Texas sun, they get really hot. So every, I don't know, 20 minutes or so, I had to get off the inner tube. It was too hot to sit on. And I had to flip it just because it absorbed so much heat.

+ +

STEPHANIE: Wow. Yeah, that does sound like it would get very hot. I think the funny thing that I wasn't expecting was how hard it would be to get back into the inner tube after you had gotten in the water, at least for me, because the inner tubes were quite large. And so I couldn't get enough leverage to pull myself [laughs] back up onto it, and ended up several times just, like, flopping belly first into the inner tube and then having to, like, flop over so that I could be on my back and be sitting in it again.

+ +

And other times that I had to wait a little while until the river got shallower so I could actually stand and just sit in it. So there were times that it was kind of a struggle, but 90% of it was very chill and fun.

+ +

So, Joël, what's new in your world?

+ +

JOËL: I started a new project at work. I'm working with a data warehouse, pulling data in from a variety of sources, getting it all into one kind of unified schema, doing some transformations on it. And then also setting up some sort of outgoing plugins to allow different sources to access that unified data. So this is not in a Rails app, but we do have a Rails app connecting to this data warehouse.

+ +

Data engineering is, at least in this style, is newer to me. So I think it's a really interesting world to get into. I don't know if, technically, this counts as big data. I don't think the term is cool anymore. But five or so years ago, everybody was all about the big data, and that was the hip term to toss around.

+ +

STEPHANIE: So, is this something pretty new to you? You haven't had too much experience doing this kind of data engineering work before?

+ +

JOËL: Yeah, at least not with, like, a data warehouse. I think a lot of the work around data transformations, or creating unified schemas, thinking in terms of data in different stages that are at different levels of correctness...I've done a fair amount of ETL, Extract, Transform, Load, or sometimes people shift it around and say, ELT, Extract, Load, Transform. I've done a fair amount of those because I've done a lot of integrations with third-party systems.

+ +

STEPHANIE: So I've always thought of data engineering as, in some ways, a separate role or a track. And I'm really curious about you having, you know, mostly been doing software development if that gives you an interesting lens to look at these problems.

+ +

JOËL: So, to get the full answer, you should probably ask me again in six months.

+ +

STEPHANIE: That's fair.

+ +

JOËL: Initial thoughts is that there's a shocking amount of overlap between some of these ideas, again, because I've done ETL-style projects a lot. You know, if you've got any kind of Rails app and you're integrating with a third-party API, you're often doing ETL at a very small level. To a certain extent, even if you're doing, let's say, some front-end code, and you're interacting with a back end, depending on how you want to deal with that transformation of getting data from your API, you might be doing something kind of like an ETL.

+ +

Designing types in something like a TypeScript or an Elm and thinking in terms of the data that you have, the transforms that you're doing has a lot of similarities to what you would do in a data warehouse. I think a lot of the general ideas apply.

+ +

I know I talked at the beginning of this year articles that were impactful for me. And one of those articles that was really impactful was Hillel Wayne's "Constructive Versus Predicative Data," which is all about structuring data and when you can enforce constraints via the data structure versus when you need to enforce it via code.

+ +

Similarly, a lot of the ideas from the article "Parse, Don't Validate" by Alexis King. The articles focused on designing types. But it also, I think, applies to when you're thinking of schemas because schemas and types are, in a sense, isomorphic to each other.

+ +

STEPHANIE: I like what you said there about as a software developer; you've probably done this at a much smaller scale. And, yeah, like you were saying, things that you had already learned about before or thought about before you're able to apply to this different set of problems or, like, different approach to programming. Is there anything that has been challenging for you?

+ +

JOËL: Yes, and it's a weird one. Because we're working with enterprise systems, navigating the websites for these enterprise systems and the documentation for them is not a pleasant experience, trying to get a feel for how the system is made to work. It's just so different when you're used to tools and documentation written by the open-source community.

+ +

Even third-party tutorials and things it's never, like, oh, here's a great article where you can scan and find the thing that you want. It's, hey, I'm a consultant guru on this thing. Sign up for my webinar, and you can have a 15-hour course on how to use this tool. And that's not what I want to do. I just want give me the five-paragraph blog post on how to do data imports, or how to set up a staging area for data, or something like that.

+ +

STEPHANIE: Right. You're basically being asked to develop skills in using the enterprise software rather than more general skills for the problem or task; it sounds like. Because apparently, there are people making a business out of teaching other people how to use or navigate the software.

+ +

JOËL: And I think that's fine. I love that people are making businesses of teaching these. But just the way things are structured, information is not generally as available for this large enterprise software as it is in the open-source world, and even when it is, it's just different patterns of access. So even you go to a particular technology's website, and it's all marketing copy. It's all sales funnel and not a lot of actually telling you really what the technology does. It's all, like, really vague, you know, business speak on, you know, empowering your team, and gathering insights, and all this stuff.

+ +

So you really do a lot of drilling down. And what you need to find is the developer site. That's where you get the actual tech documentation. Depending on the tech, it's more or less good. But yeah, the official website of the technologies is just...it's not aimed at me as a developer. It's speaking to a different audience.

+ +

STEPHANIE: That is interesting. I didn't realize that once you are, you know, working on a data warehouse, it is because you are consuming so many different external sources of data, and having to figure out how to work with each one is part of the process to get what you need.

+ +

JOËL: So there's the external services but the data warehouse itself that we're using is an enterprise product.

+ +

STEPHANIE: Got it.

+ +

JOËL: So, just figuring out how this data warehouse works, it feels like it's a different culture, a different developer culture.

+ +

STEPHANIE: That's cool. I'll definitely ask you again in a few months, and I look forward to hearing what you report back.

+ +

So the other topic that I wanted to get into today is reviews, specifically self-reviews. To be honest, our review cycle is happening right now. And I have very much procrastinated [chuckles] on writing them until, you know, one or two days before. So I came into our conversation today, like, in that mind space of thinking about my growth, and my goals, and that kind of stuff.

+ +

And it got me thinking that I don't hear a lot of people talk about reviews, and how to do them, how to write them for yourself, how to write them for others, how people approach them. Though I would guess that the procrastination part is pretty common, [chuckles] just based on what I'm hearing from other folks on our team too, and what they're up to for the next couple of days before they do. Joël, have you written your review yet?

+ +

JOËL: So it's interesting because this review cycle has a few different components. You write a self-review. You write a review of your manager, and then you write a review of several of your peers who have nominated you to write a review. So I've done my own review. I've done my manager's review. I've not completed all of my peer reviews yet.

+ +

STEPHANIE: That's pretty good. That's better than me. I've only done my own. [laughs] So, yeah, the deadline is coming up. And I'll probably get back to it right after this.

+ +

I'm curious about your process, though, for writing a self-review. Do you come into it having thought about how you've been doing so far in the last six months or so? Or, when you sit down to write it, are you thinking about these things for the first time in a while?

+ +

JOËL: Combination. So I think I do come in without necessarily having, like, planned for the review cycle. That being said, throughout the year, I try to build a fair amount of, like, personal self-reflection, professional self-reflection at various points throughout the year. So I'm not coming into the review cycle being like, oh, I have not thought about professional growth at all. What have I done this year?

+ +

I think one thing I haven't done quite as well is when I'm doing these moments of self-reflection on my own throughout the year, writing down notes that I could then use to apply when the review cycle comes up. So I am having to rely on memory on, like, oh yeah, last month, when I kind of sat down and thought about areas that I want to improve in or areas that, like, what are my goals that I want to have? And I just commit that to memory. So, yeah, I think live in the moment; now that you've asked me this question, you've made me think that maybe I should be taking more regular notes about this.

+ +

STEPHANIE: One thing I've been really liking about the software that we're using for reviews and other professional growth things is...it's called 15Five. And you can give your co-workers shout-outs using this tool. And as I was writing my review, I could actually open all of the kudos and shout-outs that I received from my peers and just remember some of the things that I worked on or a lot of the things that other people noticed.

+ +

I tend to sometimes have a hard time remembering some of the smaller things that I've done that made an impact, but other people are usually better about pointing that out than I am. [chuckles] And that has been really helpful because it's, yeah, nice to see like, oh, like, you know, so and so really appreciated when I paired with them on, you know, debugging this thing. And maybe I can pull that into something that I'm writing about the kind of mentorship I've been doing in the last few months.

+ +

JOËL: How do you feel about the aspect where you have to then give feedback on colleagues?

+ +

STEPHANIE: I really value and enjoy this aspect because most of the time, I am just gassing my colleagues up [chuckles] and writing, you know, really encouraging things about all of the awesome work that they're doing. So, for me, it actually feels really good.

+ +

And I was thinking a little bit about my approach to reviewing my peers and review culture in general. I have worked at companies where we have had a very, like, healthy and positive review culture. So it happens often enough that it's become normalized. It's not a really scary thing. And I also like to think about feedback in two types, where you have feedback that you want to give someone so that they can change behavior in a way that helps you work with them better, and then feedback you have for someone for their growth.

+ +

And once I separated those two things, I realized that really, the former, if you're, you know, giving someone constructive feedback because you maybe would like them to be doing something different. That's not necessarily what you want to be writing in their annual review. Those things are usually better communicated in a more timely manner, like, right when you are noticing what you might want to be changed.

+ +

And so then when you are doing reviews, like, you've hopefully already kind of gotten all of that stuff out of the way. And you can just focus on areas of growth for them, which is the fun part, I think, in reviewing peers because, yeah, you can give some suggestions to further support them in, like, where they want to go.

+ +

JOËL: I like that distinction between just general growth, suggestions, and then interaction suggestions. And just to give an example, it sounds like interaction suggestions would be like, "Oh, when we pair, I would like it if you used this style of communication from, let's say, nonviolent communication. Here's a talk; go watch it."

+ +

STEPHANIE: [laughs] Yeah, I did talk on this; go watch it. There used to be a framework for reviews that I've done before that I actually don't quite like. It's the Stop, Start, Continue framework where you answer questions about, okay, what should this person stopped doing? What should they continue doing? And what should they start doing? And the things that you would put in stop, I think, are probably what you would want to have communicated in a more timely manner, like, not necessarily it happening, you know, really divorced from whatever behavior you might be asking.

+ +

And, in general, I think focusing on what you would like others to be doing instead is usually a better approach to handling that kind of feedback just because it avoids making someone feel bad about having done something wrong and, instead, kind of redirecting them into what you would like them to be doing.

+ +

JOËL: So you're saying if you have something in the stop category, let's say stop interrupting me all the time when we're in meetings, you're saying this is something you prefer not to bring up at all or something that you prefer to bring up one on one and not in the context of review?

+ +

STEPHANIE: Something to bring up one on one. Ideally, pretty soon after, that might have happened. It's a little more top of mind. And then you don't end up in that position of maybe misremembering or having the other person misremember and having to figure out, like, who was in the right or in the wrong in understanding how that interaction went. Especially if you're able to do it a little sooner after it happened, you can point out, like, hey, this happened. And instead of framing it as please stop interrupting me, you could say, "Could you please make some space for some folks who've been a little more quiet in the meetings to make sure that they've been able to share?"

+ +

Still, I think once you've made more space to give that kind of constructive feedback when you are writing reviews, you can then, like, focus on the growth aspect and not the redirection of how others are doing their work.

+ +

JOËL: That makes sense. So, what would be an example of the kind of feedback that you like to give to other people in the context of a review?

+ +

STEPHANIE: Yeah, I think especially if I know what someone is wanting to focus on, right? If I'm working with someone, hopefully, we've kind of gotten to talk about what they like to work on, what they don't like to work on, what they are hoping to spend more time doing, or yeah, just their hopes and dreams for their professional [chuckles] development, being able to point out some things that they maybe haven't thought about trying it I really like to do.

+ +

I was thinking about a time when I gave a co-worker some feedback as a mentee of theirs where they had been really awesome at providing information to me about things that I was unfamiliar with. But one thing that I was really hoping for was more tools to figure things out on my own. So instead of sending me a link to some documentation, maybe helping me figure out how to search for the documentation that I'm looking for. And that was something that I could share with them because I knew that they wanted to work on their mentorship skills and an opportunity, I think, for them to take it to a level where it's closer to coaching and not just providing information.

+ +

JOËL: That makes a lot of sense. Maybe flipping it around, is there a point in time where you've received a review feedback that has been really valuable to you or really helped you hit the next level in your career?

+ +

STEPHANIE: I really appreciate feedback that encourages me when I'm maybe a little bit too timid to go seek the things out myself. So there were times when I received some feedback about how great of a leader I could be before I thought I was ready to be a leader. And they pointed out the qualities of leadership that I had demonstrated that led them to believe that I would be ready for a role like that. And that was really helpful because I don't think that was even necessarily a short-term goal of mine. And it took someone else saying, "I think you're ready," that made me feel a lot more confident about opening that door.

+ +

I guess this is all to say that I really love review season because of, you know, all of the support I get from my co-workers. And, yeah, just remembering that it's not just a journey I have to take all by myself, that the point of working with other people is for all of us to help each other grow.

+ +

JOËL: I think something that you mentioned earlier really connected with me, the idea of trying to give feedback in the...even, like, feedback that's about changing or improving, phrasing it in a more positive way, or at least framing it in a more positive way. So here's an opportunity for growth rather than here's the thing you're doing wrong. Because that reminds me of two pieces of review that I got when I was a fairly junior developer that have stuck with me ever since. And one of them was really a catalyst for growth, and the other one kind of haunted me.

+ +

So this first one I got, someone in a review just mentioned that they thought that I was just generally a slow developer, just not fast at writing code. Not a whole lot of context; just that's who I was. And, in a sense, it was almost like I'd been given this identity, like, oh, I am now Joël, the slow developer. And I didn't want that identity. So I'm kind of like, I want to refuse to accept it. But at the same time, there's always that self-doubt in the back. And now, anytime I'm on a project with someone else, I'm comparing, oh, am I shipping stories quite as fast as someone else? And if not, why? Is it because I'm a slow developer?

+ +

Or if I'm having a rough day and I'm not getting the ticket done that I was hoping to get done by the end of the day, you know, you just get that voice in the back of your head that's like, oh, it's because you're a slow developer. Someone called that out last year, and they were right. So, in a sense, it kind of haunted me.

+ +

On the flip side, I once got some feedback talking about an opportunity for growth. If I focused on working in more iterative, incremental chunks, it would help have a smoother workflow and probably help me work faster as well. And that was really kind of an exciting opportunity. It's also stuck with me for years but not in the sort of haunting sort of way or this, like, bring in self-doubt but more in terms of opportunity.

+ +

Because now I'm always like, oh, can I break this down into even smaller chunks? Would that help me move faster? Would that help me be less blocked on other people? Would that be easier for our QA team? Would this be easier for review for my colleagues? Just a lot of different opportunities for benefits with working in smaller iterative chunks.

+ +

And, for years, I've just been kind of honing that skill. And now, looking back over, you know, a decade of doing this, I think it's one of the best skills that I have. And so, in a sense, I feel like both of these people that left me that review, in a sense, they're trying to get me to maybe have a slightly higher velocity. But they're different approaches, radically different in terms of how it impacted me as a person.

+ +

STEPHANIE: Yeah, I am really glad you brought that up. Because I definitely have also received, quote, unquote, "constructive feedback," but maybe wasn't phrased in the right way, that also haunted me. And it doesn't feel good. I think that that sucks. That person wasn't really able to frame it in a way that pushed you to progress in the positive way that you mentioned with learning to work incrementally.

+ +

And in fact, I almost think that the difference in those two phrasings is encapsulated by a framework for giving feedback that's actionable, specific, and kind. So suggesting you to work incrementally is all of those things, especially if they know that you do want to increase your velocity. But you're being supported in doing it in a way that is positive and growth-oriented as opposed to, like, out of fear that other people think that you are a slow developer. And, you know, that's certainly a way that people are motivated. But I would say that that's not the way that we want to be motivated. [laughs]

+ +

JOËL: I'm glad we're having this conversation because I think it just reinforces to me just the value of good communication skills for developers. And, you know, you can see that when developers have to write documentation, or even things like comments or commit messages. You see it when developers write blog posts. So it's really valuable to work on your communication skills in a lot of these technical areas.

+ +

But reviews are a very particular area where it's easy to maybe have not the impact that you wanted because you communicated a core idea that's probably right, but just the way it was communicated was not going to have the impact that you're hoping for. And so getting good at communicating specifically in the area of reviews, which I assume most of us in the software industry are doing on a semi-regular basis, is probably a good tool to have in your professional tool belt.

+ +

STEPHANIE: Absolutely.

+ +

JOËL: We recently hit a big milestone at thoughtbot, where thoughtbot turned 20 years old in early June. And so, throughout June, we've been doing a lot of fun internal things and some external things to celebrate turning 20. And one of those is we're hosting a live AMA with a variety of thoughtbot devs. That's going to be on Friday, June 23rd, so a couple of days after this podcast goes live.

+ +

So, to our listeners, if you're listening to this, in the first few days after it goes live, you get a chance to join in on the live AMA and ask your questions of our team as we celebrate 20 years. There's a blog post with all the details, and we'll link to that in the show notes.

+ +

STEPHANIE: One other thing that I think we're doing that's really cool for our 20th anniversary is we published a short ebook with a curated collection of 20 hits from our blog, the thoughtbot blog, over the course of its history, some of the more popular and impactful blog posts that we've ever published. So I highly recommend checking that out. You know, the thoughtbot blog is such an awesome resource. And I discovered a few things that I hadn't read before on the blog from this ebook. So that will also be linked in the show notes.

+ +

JOËL: I mentioned earlier how one of my opportunities for growth through review was getting better at working iteratively. And, a couple of years ago, I took a lot of the lessons that I'd learned over the years of getting better at working iteratively, and I put them in a blog post, and that blog post made it into that 20th Anniversary ebook. So we can probably link the blog post itself in the show notes. But also, if you're picking up that ebook, you'll get a chance to see that article on my lessons learned on how to work iteratively.

+ +

STEPHANIE: Awesome. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+EZ2e6fxI + + ]]> + + Joël Quenneville + Stephanie Minn + + + 388: Empowering Other Departments Within a Company + https://bikeshed.thoughtbot.com/388 + 54428082-959f-4a5a-9141-7db774b5302f + Tue, 13 Jun 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël has a bike shorts update; Stephanie has a garden one. + +Often, power is centralized within the dev team. This is usually because they are the only ones able to execute. Sometimes this ends up interfering with team processes and workload. Joël is a fan of empowering other teams to do things themselves. + 34:11 + no + + + Joël has a bike shorts update; Stephanie has a garden one. +Often, power is centralized within the dev team. This is usually because they are the only ones able to execute. Sometimes this ends up interfering with team processes and workload. Joël is a fan of empowering other teams to do things themselves. +Strangler Fig Pattern (https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) +What Being a Staff Developer Means at Shopify by Rose Wiegley (https://shopify.engineering/what-being-a-staff-developer-means-at-shopify) +End-User Programming (https://www.inkandswitch.com/end-user-programming/) +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, in a recent episode, I had mentioned that I was going to go on vacation on a bike trip and that I had purchased a pair of bike shorts to try out on that trip to see if that would help. And, wow, that was a great purchase. It literally saved my butt. +STEPHANIE: That's awesome. I'm really glad that they worked out for you. +JOËL: Still sore. This was a five-day biking trip. And I think day two was the worst, but after that, things got better. But the shorts definitely helped. +STEPHANIE: I think my favorite part about us talking about biking and bike shorts is that we're finally living up to the name of our podcast. [laughs] Turns out that bikeshedding is actually even more, bikeshedding when it's about actual bike stuff. And a listener named James even wrote in with some pro tips about, you know, how to care for your bike shorts and, you know, have a comfortable biking experience. And gave some good tips for me on some longer rides to check out near me in Chicago. +JOËL: So it sounds like there's some crossover between the software developer community and bike enthusiasts community who also tune into this podcast. +STEPHANIE: I do think that we have gotten tweets before from, I think, like, the motorcycle Twitter tagging us @_bikeshed, perhaps maybe trying to tag a different account but, yeah, ended up in our Twitter inbox instead. +JOËL: Now we just need some sweet, sweet bicycle sponsorships. So, Stephanie, what's been new in your world? +STEPHANIE: I have a garden update. Last year, we purchased a small fig tree from the internet. It turns out that you can get little fruit trees delivered to your door. And this was, I think, around the fall, so it was getting a little cooler. And here in Chicago, we have to bring some of our plants inside to overwinter. And so we brought the fig indoors, and it's maybe, like, two or three feet tall. And, you know, over the few months, we were just, like, caring for it. And I was really excited to see that it had started fruiting several months ago. And I got to show it to all of my co-workers in a call. +I, like, picked up this kind of large pot with our little fig tree, and I, like, held it really close to my camera and tried to point out the fruit to the other people on the call, which I realized was perhaps not a very effective way to show off my plants. Like, you could just take a picture and send it in Slack. And I was like, yes, I could have done that. +But yesterday (Now our fig tree has been outside for a little while since it's warmer.) I noticed that they were ripe, and I got to harvest our figs and eat them, and they were delicious. And I got to update the team on my little fig adventure. And this time I did take pictures of the fruits and sent them in Slack instead of trying to bring this tree in from the outdoors. +JOËL: That's exciting. Because I'm a fan of the design pattern, I have to ask, is this a strangler fig? +STEPHANIE: It's not a strangler fig, though I have seen one in the wild on a trip to Florida. I saw a really big strangler fig, you know, completely, like, enveloping another tree, and that was really cool. If you ever get to see one in person, I think it's just, I don't know, just really amazing how nature works. +JOËL: I did not realize they were wild in Florida, something to keep an eye out for next time I'm there. +STEPHANIE: Definitely. So, in a recent retro on my client team, we were discussing the one-off requests our team has been getting from the folks over on the sales and client support side. Oftentimes, this involved running a script in our production console to fix some issue that a customer was experiencing. And we were talking about what we could do to make this process a little more automated, make it a little less time-consuming on our end. Even though it would just take a few minutes to run this script, we were seeing that we were getting this request repeatedly. +I'm curious if you've kind of been in this situation before where dev work is required and kind of eating into time that we are trying to be delivering on other feature work for similar one-off requests or to support other folks at the company. +JOËL: Yeah. I think it's a pretty common pattern that I've seen. And I think sometimes it can actually start from a healthy place. If you're taking very much of an MVP philosophy and you're building a small version of your product to start with, you're not going to have a whole suite of admin tools available. You might not even have any admin people. It might just be a founder and a technical co-founder. And so, for the first few hundred customers you have, maybe the way you make changes is by loading up the Rails production console and making a change. And that's good enough, but that doesn't scale. +STEPHANIE: Yeah. You bring up a good point that I think one thing that we get to experience as consultants is seeing many different companies at different stages in their business. And I think I've seen this issue in many different iterations based on the size of the company, right? So you were saying for an MVP product, there's no admin support at all. Maybe you have a project that is now thinking of how to introduce a little bit of admin tooling and might reach for something lightweight like a gem. I've also seen custom admin dashboards, and that being its own namespace and having all of that feature set hand-rolled, and then maybe some other company might opt for a Software as a Service solution. +JOËL: Yeah, there's a lot of different implementations that happen at various stages of companies. I think one thing that does seem to stay pretty constant, though, is oftentimes; other teams don't have the tools they need to make the changes they need to. So, if you have a customer service person and they're receiving a complaint or they're having to make a change, they're not always empowered to make the changes they need to. They need to talk to the dev team, who then need to make changes. +And the dev team don't really want to spend their day doing admin work. They are incentivized to ship features. And so both sides are unhappy. And it kind of comes from a sort of fundamental, I think, over-empowering of the dev team and kind of a disempowering of some of the other departments within the company, if that makes sense. +STEPHANIE: Yeah, that's interesting because I don't think it necessarily is intentional, the way that that happens, right? It's not like you start building a product, and you are saying, "Okay, we only want to give devs the power to change all of this stuff at the production level." It's just something inherent, I suppose, to the work that we do. And there's a lot of active effort that needs to be taken to spread some of that empowerment around. +JOËL: Yeah, generally, it is not some sort of, like, nefarious corporate politics that's happening where the CTO is, like, hoarding all the power, or it's a turf war or anything like that. Like you said, it's kind of an emergent property. As developers, we're often used to being sort of ultra-empowered to do what needs to be done. In general, development teams are highly respected within companies, and so people listen to them. But also, in order to do their job, they need to have access to a lot of things. +So you often have production access to all the things and the admin credentials. And if there's something that doesn't work, you write code, and you can change the sort of fundamental underlying platform that you're working with. And so you're generally empowered to make the changes you need to make your life better or if you're blocked on something. And that's not necessarily true for other departments who are working in the system that we're building. +STEPHANIE: Yeah, it's kind of interesting the duality that you have identified where we do have all of this power or capability to change the system. But you had mentioned earlier that sometimes it actually gets in the way of our work, that it can be a drag to do if we have other competing priorities, and that those mundane tasks end up being something that we also don't enjoy doing. And so, like you're saying, like, no one is quite happy. I wonder at what point you, as a developer, having repeatedly been asked to do these kinds of tasks for other departments when you, would start advocating for building tooling. +JOËL: I don't think there's a kind of a clear dividing line, like, oh, after three requests, you must build a dashboard. It's probably more about just general communication with the other teams. I like to think of it from kind of two perspectives. From the perspective of the developers, how can we keep them efficiently working on what they need to prioritize, which is typically new feature development? +And then, from the perspective of other teams, how can they be empowered to do the work that you need to do without getting blocked? Because just like the dev team doesn't like to get blocked on all sorts of things, other teams don't like it either. And so, how can we make sure that other team members within the company are empowered to do their work as efficiently as possible? +STEPHANIE: Yeah, that's interesting. I think as an IC, I've been in different positions, depending on the context of my work. There have been times when I've been happy to help with that kind of request, right? Because I know that I'm unblocking someone else. I'm facilitating their work. And they usually appreciate it too. And so maybe if that's still the case and that there's not necessarily any pain that comes with that being just the process that it is from both sides, like, that's perfectly fine. +But then it's totally fair for, you know, either party, once they do feel like it's blocking other work, to start looking into maybe how much time you're spending on these one-off requests, especially if it's being spread around to other team members. You know how much effort you're making, but, like, a manager might actually be more aware of how it's affecting multiple folks on the team and wanting to figure out, like, how that sits in with the other priorities that the team is working on. +JOËL: Yeah, I'm glad you mentioned talking to other people because I might be quite happy to say, "Oh, I'm going to go and, you know, go into the database and make a small change." But just because it's easy for me to do and I can take, you know, 10 minutes out of my day to do it, doesn't mean that that experience is good for, let's say, a customer service person who had to get blocked or had to ask someone else to help to move this ticket forward. When if it was something they could do themselves, that would have been a much better experience. +So, even though it's a very fairly, you know, cheap request and because I don't get them a lot, I'm happy to do them, it's maybe not a good experience for my customer service colleague. So, like you said, it is important to get people's experiences on all sides. +STEPHANIE: One thing that I have seen a lot is for these things to start as configuration in a YAML file that requires developers to change and then commit to the codebase whenever, you know, maybe it's, like, a list of products or a list of prices, something that is, you know, really the business domain. And yet we are hard coding it and, like, codifying it into our source control. +JOËL: Oof, yes. I have been in those projects, yeah. Now, every time you want to make a change, a business person has to reach out to the dev team, and then you have to make a code change, and then you have to deploy it. And that just becomes a whole thing. And then they come back to you the next day and say, "Oh, actually, we talked about it, and we want it a little bit differently." And you have to go through that process again. +STEPHANIE: I think we reach for that just because we think it's faster maybe to set up, you know, some kind of, like, lightweight configuration file, rather than if you're working in Rails, you know, setting up a whole MVC for whatever thing you're trying to configure. And I'm curious if you think that's true or not. +JOËL: I think it depends. Sometimes it can be because this data feels very static, kind of hard-coded. And so it's not a thing you would necessarily want to have. In a database, it's more like a constant that you would have in your source control, except that then you find out that your constant is not quite as constant as you thought it was. And I think maybe that's okay. +Writing software is all about kind of discovering the problem in the domain as it evolves and trying to not over-engineer things ahead of time. So, if we have a small set of values, maybe they're U.S. states that you deliver to or a small list of products or something that you feel is relatively hard coded, maybe it starts as a constant array hard coded into Ruby, maybe it is a YAML file that you load. Then, over time, there comes a point where you decide this should be a database table, and if it needs to be sort of pre-seeded, then there's a mechanism for that with database seeds in Rails. +STEPHANIE: Yeah, that's fair. I find it so interesting because most of the time, I've not seen that transition happen, right? It almost feels like some form of the bystander effect where everyone is just, well, I'm adding just one more thing. So I don't want to make this really big change now. +JOËL: And that's true for everything in code, right? You say, "Oh, this deeply nested condition, yeah, it should probably be restructured. But I'm just going to add, you know, an eighth nested level in there. And, like, eight is probably the limit, but mine is going to be the eighth, so it's going to be good." And then somebody comes in and says, "Well, you know, nine is not that bad, but the next person probably should refactor it." And then it's a mess. +STEPHANIE: Yeah, it's kind of like the entropy of code, I suppose, [laughs] where, you know, we had said it requires a lot of active energy and effort to make those changes to support other folks in different departments of the company. And I think that's, like, one very common area that we see things starting as configuration but then end up being something that you are needing to support in changing. +And I wonder if maybe that is a signal in itself, right? If you are getting this information from another team, like, someone external to the development team, I wonder if that's kind of a clue that this is something that should be reconsidered about whether you start with it being hard-coded. +JOËL: That's an interesting thought. There's a sense in which I think these always come from places external to the development team because it's a form of kind of product research when you're trying to understand what the features need to be, what this needs to happen. Unless this hard-coded data is purely structural or internal values, but it rarely is. There probably is a broader discussion to be had about the use of any sort of hard-coded data in a configuration file in a Rails app versus just always starting with a database table. +One thing that's nice about always having a database table is that if you ever need to connect it to other data in your system, now you can do things like table joins, where you can't join your users on some kind of YAML array, or you have to do some sort of Ruby Enumerable logic. You can't just do it in SQL. +STEPHANIE: Yeah. This is a bit of a tangent, I think. But that reminds me of when I worked at a product company where we had a very robust data warehouse, and all of that information was available to teams on the marketing side and on the data science side. And I actually really liked that because they were able to, you know, construct their own dashboards and queries to get the things that they need. And I've certainly seen what you're saying, this pretty important business information being hard-coded, and that ends up being less accessible, right? And less insightful, really. +One other area of this topic that I think I've also bumped into before is specifically a QA engineer or, like, a QA team and empowering them to be able to do their jobs. Oftentimes, I've noticed that QA environments are not as well-maintained as maybe they should be, where the data that's seeded or, you know, kind of overtime in this environment is a little wonky. +I've also experienced, while working on a feature, kind of having to go back and forth between whoever is helping QA my work telling them, like, "Oh, this isn't finished yet. So, like, don't worry about this that you're testing," or, you know, "Actually, that does look wrong. But let me look into it over on this end." And I found it sometimes difficult to navigate because I want them to be more empowered to test their feature without that uncertainty over whether something is intentional or actually broken. +JOËL: In this case, do you think it's more about communication between development and QA, clear acceptance criteria, or clear descriptions of what changes have been pushed up for review and what's not in scope? Is that where you're headed? +STEPHANIE: I think that's a part of it. But I actually think there are more technical considerations, especially in terms of whether our environments all align in terms of the data we're expecting, right? Does our dev environment kind of look like our QA environment, which looks like our production environment? Because I've certainly been in projects where that's, like, all over the place, and that really messes up the different expectations we have. +We all know the "Oh, it worked in my local" [laughs] response to when things come up in other environments that are unexpected. And I wonder if there is more attention that we should be having towards making sure that just because this environment is not the main one that we're working in as developers, that people who are having to use it have an equally good user experience. +JOËL: I like that you brought up the term user experience because oftentimes, as developers, and just, I think, product teams in general, we're trying to make something good for the customers of the application. But there are a lot of other people that have to interact with it in sort of more ancillary roles; like you mentioned, it might be QA. It might be customer support. It might be business development. And they're not the customer. And so because of that, they're often kind of a second thought or even sort of no thought at all. +And so they do their jobs as best they can with what they've got, and sometimes get really creative getting around some of the hurdles that are in place. But we can often, with very little effort because the bar is so low, make these people's lives a lot better by applying just a little bit of the same approach that we would use to make software great for a customer to use for teammates in these other roles. +STEPHANIE: Yeah, absolutely. Especially because we have that line of communication open with them, and, like you said, they are also our users of our applications. And especially for QA folks, too, in some ways, they're the first line of defense of our users, right? They are a resource for us to know if the customers will eventually have a poor experience or not. +And I was thinking about that back-and-forth communication I mentioned with QA, you know, trying to explain, like, oh, this isn't finished yet, so maybe, like, you should not expect this to happen. But, oftentimes, that perhaps is a signal that we haven't thought about the way that we're developing our feature to be able to be released to customers in a more incremental way. Or we might be hand-waving over something that ends up being a bug later on. +JOËL: Definitely. For myself, I see that as a... code smell is maybe not the right term here, but maybe acceptance criteria smell. If I'm trying to write out some acceptance criteria, and I'm having to say, like, "Oh, but, like, ignore this, and, like, pretend this doesn't exist. All of these, like, weird edge cases and exceptions we're trying to put in, are oftentimes a sign that maybe the work was not scoped correctly. +STEPHANIE: I'm curious, in your workflow, will you just make those improvements if you have the opportunity to? Or do you end up bringing that to the team or creating a ticket for it? How does that fit in when you identify areas that could be improved? +JOËL: I think it depends on the team's current workload. Oftentimes, if it's just something small, it's something I can just slip into my day, and it makes somebody else's life easier, that's great. Otherwise, it can be a thing that needs to be brought up with the team in general. And then it's the thing that we prioritize, and we put it in the backlog because, like you said, the main users of our app are customers. But all of these other teammates are also users of our app in other ways, and so they need certain features to get their job done. +And so it's worthwhile to, I think, at a product planning level, take those into account and prioritize them with the customer-facing things. And sometimes, because those other teams don't have as much of a voice at the table, it's up to us as developers because we sometimes have that direct communication where we're talking to them and sort of going back and forth about, "Oh, can you change this in the database for me?" or "Can you do this?" And it can be up to us to champion these other teammates' needs with the team and with the product organization in general. +STEPHANIE: Yeah, I really like the way you put that. I think you used the word champion. And I've seen this also go the other direction, where we add more processes in place, where the direct communication that needs to be gatekept a little bit through a manager because the manager is trying to protect the time of the team. And that is one way to handle the issue of these requests taking too much of the team's time. +But I think at some point, as an IC, you also have the agency to champion or advocate for how you use your own development time. And that reminds me of something I heard from Rose Wiegley over at Shopify about what it means to be, like, a staff or a senior developer, and that is sharing that I'm going to do this, and this is why. And that means that I won't have time to do this other thing that I may be committed to earlier. But you know, these are my reasons. And if anyone sees any problems with that, let me know. +And I've been thinking about that a lot in terms of figuring out how to do the kind of work that I value. And for you and me, that does sometimes mean building those tools to empower people who aren't developers. But that is, yeah, just a way that we can assert a little bit of that agency rather than having to get the buy-in to even consider setting time aside for that work. +JOËL: Yeah, I think some of the really fulfilling work that I've done has been just sometimes taking a morning and, quote, unquote, "pairing" with, like, a business development or a customer service person and just saying, "Hey, can I just sit with you while you process this kind of request or problem that you're trying to do?" And then just really seeing what they do and all the steps and being able to ask a lot of questions and kind of putting my product developer hat on. And because then I know, internally, all the things that are happening, I can quickly see, oh, okay, you're- having to do these, like, five steps to get around this really annoying thing that's just, like, a rough corner that we have that I can, like, just easily smooth the way, you know, with a 10-minute one-line fix. I'm going to go and do that, and, you know, by the afternoon, that's already done, and that's saved them so much time or so much annoyance because it's not always time. Sometimes it's just annoyance. And their life is better. And I put very little effort into it. Most of it is just taking the time just to talk to each other and to try to understand each other. +So I think we brought up the idea in the beginning of trying to empower other teams to not sort of centralize all the ability to execute on change within the development team. And sometimes, you can go to fairly extreme lengths to that. One that I've seen is the idea of end-user programming or end-user development, where the using the software rather than the team developing it has some sort of way where they can sort of customize or build on, or sometimes even script or -code -their experience. Is that something you've ever had to deal with or interact with on a project? +STEPHANIE: Yeah, it's really interesting that you brought that up because I had mentioned going with a SaaS solution earlier as something that I've seen before. And that reminds me of when I worked on a client project where we were using Freshsales to integrate with the business domain of the client. And this would eventually be the main software that the sales team would use. And the reason that we went with Freshsales was because it allowed for a lot of that custom configuration and workflows that they could create for themselves for their needs. +Though ironically, as we were kind of butting up into the limitations of Freshsales and how it didn't necessarily work for the way we were representing our data, we kind of joked that we almost wished we had to build the tool from scratch ourselves. So I think there are trade-offs there, you know, folks had done a lot of research to figure out the right SaaS solution for this project that we were doing. And yet, you know, inevitably, like, there were some cons with the third-party and how we were able to integrate with it. And it was actually also replacing something that had been built in-house and had become difficult to maintain or something that the company decided that they didn't want to maintain anymore. So I hate to say it, but I really think it [laughs] depends. +JOËL: And now you're getting into the classic build versus buy dilemma for chunks of your software. +STEPHANIE: Yeah, absolutely. +JOËL: I think a way that I've seen, and this happens in a kind of a smaller sense, is providing escape hatches for data. And so maybe you've got a couple of small dashboards, or you've got just a lot of things that happen in your system. And you don't have the development time, or you don't want to prioritize that time right now to build something custom for maybe your business development team. But you provide certain reports that can be exported as CSV or Excel, which then the business development team will load into Excel and do the work that they need. +And now they're empowered to do what they want instead of having to ask for more information or just being limited to what was on that web UI. Similarly, sometimes, when you're able to Import a CSV, I've seen this happen a lot, where in software that's not built just right for a customer service team, they'll often export a CSV of data, put it into Excel, manipulate it the way they really want it to be, and then re-import it into the system. And so that can be a great way to temporarily empower people. I think it's also a product smell. Oftentimes, there's a fundamental flaw of the way that your product works because your team is trying to go around it. It's so bad. But as a shorter-term solution, that can be great. +STEPHANIE: That makes me think that Excel is the real end-user programming software. +JOËL: It really is. It really is. I do really like the idea of end-user Programming, though. And rather than developers or even product people having to decide how our software should work for our users, shifting that to the masses and letting them have all of that empowerment and agency that we're talking about. +There's a technology research lab called Ink & Switch, and they build a lot of really cool end-user programming tools. I think I've seen some, like, note-taking software, that they've done, and just other research into why it's important and how it can impact users. And I have read a little bit of their work, and I think it's really cool. So I'll be sure to add that to our show notes. +JOËL: I think even as developers, we like some of these ideas of end-user development. We have that a lot in our tooling. But then, even when we interact with other people's software that we don't own...because we're used to interacting with our own software, we own it. We can change anything we want. We've got complete freedom. But the moment we interact with somebody else's software and, of course, it doesn't work 100% the way we need it to, it is sometimes nice to have sort of ways to hook into it so that we can get the things we want and then maybe do some extra manipulation on our own. And APIs are often how we do that. And so the equivalent of providing an API for another developer, well, what is that for our other teams? +STEPHANIE: Yeah, great questions to consider. +JOËL: You know, it could be a CSV export. It could be maybe there's some easy way to connect to a Zapier plugin. And now, you know, they don't need to ask the dev team, "Oh, we want to receive this notification email internally when this event happens. They can just connect to a Zapier plugin and have it send an email or do something in Salesforce or all these other things that are helpful in their workflows but that we've not taken the time to build into the core software. And now they're empowered to do their work and not blocked on us. +STEPHANIE: That's interesting because as you were talking about that, it made me think of development tooling that we get to integrate with and how those APIs are usually very flexible. And let us decide what we need and ask the API for that as opposed to it dictating it for us. And, you know, if that's something that we get to enjoy, then, yeah, we should certainly think about how you can spread that to others. +JOËL: I love that. On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël has a bike shorts update; Stephanie has a garden one.

+ +

Often, power is centralized within the dev team. This is usually because they are the only ones able to execute. Sometimes this ends up interfering with team processes and workload. Joël is a fan of empowering other teams to do things themselves.

+ +
+ + + +

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, in a recent episode, I had mentioned that I was going to go on vacation on a bike trip and that I had purchased a pair of bike shorts to try out on that trip to see if that would help. And, wow, that was a great purchase. It literally saved my butt.

+ +

STEPHANIE: That's awesome. I'm really glad that they worked out for you.

+ +

JOËL: Still sore. This was a five-day biking trip. And I think day two was the worst, but after that, things got better. But the shorts definitely helped.

+ +

STEPHANIE: I think my favorite part about us talking about biking and bike shorts is that we're finally living up to the name of our podcast. [laughs] Turns out that bikeshedding is actually even more, bikeshedding when it's about actual bike stuff. And a listener named James even wrote in with some pro tips about, you know, how to care for your bike shorts and, you know, have a comfortable biking experience. And gave some good tips for me on some longer rides to check out near me in Chicago.

+ +

JOËL: So it sounds like there's some crossover between the software developer community and bike enthusiasts community who also tune into this podcast.

+ +

STEPHANIE: I do think that we have gotten tweets before from, I think, like, the motorcycle Twitter tagging us @_bikeshed, perhaps maybe trying to tag a different account but, yeah, ended up in our Twitter inbox instead.

+ +

JOËL: Now we just need some sweet, sweet bicycle sponsorships. So, Stephanie, what's been new in your world?

+ +

STEPHANIE: I have a garden update. Last year, we purchased a small fig tree from the internet. It turns out that you can get little fruit trees delivered to your door. And this was, I think, around the fall, so it was getting a little cooler. And here in Chicago, we have to bring some of our plants inside to overwinter. And so we brought the fig indoors, and it's maybe, like, two or three feet tall. And, you know, over the few months, we were just, like, caring for it. And I was really excited to see that it had started fruiting several months ago. And I got to show it to all of my co-workers in a call.

+ +

I, like, picked up this kind of large pot with our little fig tree, and I, like, held it really close to my camera and tried to point out the fruit to the other people on the call, which I realized was perhaps not a very effective way to show off my plants. Like, you could just take a picture and send it in Slack. And I was like, yes, I could have done that.

+ +

But yesterday (Now our fig tree has been outside for a little while since it's warmer.) I noticed that they were ripe, and I got to harvest our figs and eat them, and they were delicious. And I got to update the team on my little fig adventure. And this time I did take pictures of the fruits and sent them in Slack instead of trying to bring this tree in from the outdoors.

+ +

JOËL: That's exciting. Because I'm a fan of the design pattern, I have to ask, is this a strangler fig?

+ +

STEPHANIE: It's not a strangler fig, though I have seen one in the wild on a trip to Florida. I saw a really big strangler fig, you know, completely, like, enveloping another tree, and that was really cool. If you ever get to see one in person, I think it's just, I don't know, just really amazing how nature works.

+ +

JOËL: I did not realize they were wild in Florida, something to keep an eye out for next time I'm there.

+ +

STEPHANIE: Definitely. So, in a recent retro on my client team, we were discussing the one-off requests our team has been getting from the folks over on the sales and client support side. Oftentimes, this involved running a script in our production console to fix some issue that a customer was experiencing. And we were talking about what we could do to make this process a little more automated, make it a little less time-consuming on our end. Even though it would just take a few minutes to run this script, we were seeing that we were getting this request repeatedly.

+ +

I'm curious if you've kind of been in this situation before where dev work is required and kind of eating into time that we are trying to be delivering on other feature work for similar one-off requests or to support other folks at the company.

+ +

JOËL: Yeah. I think it's a pretty common pattern that I've seen. And I think sometimes it can actually start from a healthy place. If you're taking very much of an MVP philosophy and you're building a small version of your product to start with, you're not going to have a whole suite of admin tools available. You might not even have any admin people. It might just be a founder and a technical co-founder. And so, for the first few hundred customers you have, maybe the way you make changes is by loading up the Rails production console and making a change. And that's good enough, but that doesn't scale.

+ +

STEPHANIE: Yeah. You bring up a good point that I think one thing that we get to experience as consultants is seeing many different companies at different stages in their business. And I think I've seen this issue in many different iterations based on the size of the company, right? So you were saying for an MVP product, there's no admin support at all. Maybe you have a project that is now thinking of how to introduce a little bit of admin tooling and might reach for something lightweight like a gem. I've also seen custom admin dashboards, and that being its own namespace and having all of that feature set hand-rolled, and then maybe some other company might opt for a Software as a Service solution.

+ +

JOËL: Yeah, there's a lot of different implementations that happen at various stages of companies. I think one thing that does seem to stay pretty constant, though, is oftentimes; other teams don't have the tools they need to make the changes they need to. So, if you have a customer service person and they're receiving a complaint or they're having to make a change, they're not always empowered to make the changes they need to. They need to talk to the dev team, who then need to make changes.

+ +

And the dev team don't really want to spend their day doing admin work. They are incentivized to ship features. And so both sides are unhappy. And it kind of comes from a sort of fundamental, I think, over-empowering of the dev team and kind of a disempowering of some of the other departments within the company, if that makes sense.

+ +

STEPHANIE: Yeah, that's interesting because I don't think it necessarily is intentional, the way that that happens, right? It's not like you start building a product, and you are saying, "Okay, we only want to give devs the power to change all of this stuff at the production level." It's just something inherent, I suppose, to the work that we do. And there's a lot of active effort that needs to be taken to spread some of that empowerment around.

+ +

JOËL: Yeah, generally, it is not some sort of, like, nefarious corporate politics that's happening where the CTO is, like, hoarding all the power, or it's a turf war or anything like that. Like you said, it's kind of an emergent property. As developers, we're often used to being sort of ultra-empowered to do what needs to be done. In general, development teams are highly respected within companies, and so people listen to them. But also, in order to do their job, they need to have access to a lot of things.

+ +

So you often have production access to all the things and the admin credentials. And if there's something that doesn't work, you write code, and you can change the sort of fundamental underlying platform that you're working with. And so you're generally empowered to make the changes you need to make your life better or if you're blocked on something. And that's not necessarily true for other departments who are working in the system that we're building.

+ +

STEPHANIE: Yeah, it's kind of interesting the duality that you have identified where we do have all of this power or capability to change the system. But you had mentioned earlier that sometimes it actually gets in the way of our work, that it can be a drag to do if we have other competing priorities, and that those mundane tasks end up being something that we also don't enjoy doing. And so, like you're saying, like, no one is quite happy. I wonder at what point you, as a developer, having repeatedly been asked to do these kinds of tasks for other departments when you, would start advocating for building tooling.

+ +

JOËL: I don't think there's a kind of a clear dividing line, like, oh, after three requests, you must build a dashboard. It's probably more about just general communication with the other teams. I like to think of it from kind of two perspectives. From the perspective of the developers, how can we keep them efficiently working on what they need to prioritize, which is typically new feature development?

+ +

And then, from the perspective of other teams, how can they be empowered to do the work that you need to do without getting blocked? Because just like the dev team doesn't like to get blocked on all sorts of things, other teams don't like it either. And so, how can we make sure that other team members within the company are empowered to do their work as efficiently as possible?

+ +

STEPHANIE: Yeah, that's interesting. I think as an IC, I've been in different positions, depending on the context of my work. There have been times when I've been happy to help with that kind of request, right? Because I know that I'm unblocking someone else. I'm facilitating their work. And they usually appreciate it too. And so maybe if that's still the case and that there's not necessarily any pain that comes with that being just the process that it is from both sides, like, that's perfectly fine.

+ +

But then it's totally fair for, you know, either party, once they do feel like it's blocking other work, to start looking into maybe how much time you're spending on these one-off requests, especially if it's being spread around to other team members. You know how much effort you're making, but, like, a manager might actually be more aware of how it's affecting multiple folks on the team and wanting to figure out, like, how that sits in with the other priorities that the team is working on.

+ +

JOËL: Yeah, I'm glad you mentioned talking to other people because I might be quite happy to say, "Oh, I'm going to go and, you know, go into the database and make a small change." But just because it's easy for me to do and I can take, you know, 10 minutes out of my day to do it, doesn't mean that that experience is good for, let's say, a customer service person who had to get blocked or had to ask someone else to help to move this ticket forward. When if it was something they could do themselves, that would have been a much better experience.

+ +

So, even though it's a very fairly, you know, cheap request and because I don't get them a lot, I'm happy to do them, it's maybe not a good experience for my customer service colleague. So, like you said, it is important to get people's experiences on all sides.

+ +

STEPHANIE: One thing that I have seen a lot is for these things to start as configuration in a YAML file that requires developers to change and then commit to the codebase whenever, you know, maybe it's, like, a list of products or a list of prices, something that is, you know, really the business domain. And yet we are hard coding it and, like, codifying it into our source control.

+ +

JOËL: Oof, yes. I have been in those projects, yeah. Now, every time you want to make a change, a business person has to reach out to the dev team, and then you have to make a code change, and then you have to deploy it. And that just becomes a whole thing. And then they come back to you the next day and say, "Oh, actually, we talked about it, and we want it a little bit differently." And you have to go through that process again.

+ +

STEPHANIE: I think we reach for that just because we think it's faster maybe to set up, you know, some kind of, like, lightweight configuration file, rather than if you're working in Rails, you know, setting up a whole MVC for whatever thing you're trying to configure. And I'm curious if you think that's true or not.

+ +

JOËL: I think it depends. Sometimes it can be because this data feels very static, kind of hard-coded. And so it's not a thing you would necessarily want to have. In a database, it's more like a constant that you would have in your source control, except that then you find out that your constant is not quite as constant as you thought it was. And I think maybe that's okay.

+ +

Writing software is all about kind of discovering the problem in the domain as it evolves and trying to not over-engineer things ahead of time. So, if we have a small set of values, maybe they're U.S. states that you deliver to or a small list of products or something that you feel is relatively hard coded, maybe it starts as a constant array hard coded into Ruby, maybe it is a YAML file that you load. Then, over time, there comes a point where you decide this should be a database table, and if it needs to be sort of pre-seeded, then there's a mechanism for that with database seeds in Rails.

+ +

STEPHANIE: Yeah, that's fair. I find it so interesting because most of the time, I've not seen that transition happen, right? It almost feels like some form of the bystander effect where everyone is just, well, I'm adding just one more thing. So I don't want to make this really big change now.

+ +

JOËL: And that's true for everything in code, right? You say, "Oh, this deeply nested condition, yeah, it should probably be restructured. But I'm just going to add, you know, an eighth nested level in there. And, like, eight is probably the limit, but mine is going to be the eighth, so it's going to be good." And then somebody comes in and says, "Well, you know, nine is not that bad, but the next person probably should refactor it." And then it's a mess.

+ +

STEPHANIE: Yeah, it's kind of like the entropy of code, I suppose, [laughs] where, you know, we had said it requires a lot of active energy and effort to make those changes to support other folks in different departments of the company. And I think that's, like, one very common area that we see things starting as configuration but then end up being something that you are needing to support in changing.

+ +

And I wonder if maybe that is a signal in itself, right? If you are getting this information from another team, like, someone external to the development team, I wonder if that's kind of a clue that this is something that should be reconsidered about whether you start with it being hard-coded.

+ +

JOËL: That's an interesting thought. There's a sense in which I think these always come from places external to the development team because it's a form of kind of product research when you're trying to understand what the features need to be, what this needs to happen. Unless this hard-coded data is purely structural or internal values, but it rarely is. There probably is a broader discussion to be had about the use of any sort of hard-coded data in a configuration file in a Rails app versus just always starting with a database table.

+ +

One thing that's nice about always having a database table is that if you ever need to connect it to other data in your system, now you can do things like table joins, where you can't join your users on some kind of YAML array, or you have to do some sort of Ruby Enumerable logic. You can't just do it in SQL.

+ +

STEPHANIE: Yeah. This is a bit of a tangent, I think. But that reminds me of when I worked at a product company where we had a very robust data warehouse, and all of that information was available to teams on the marketing side and on the data science side. And I actually really liked that because they were able to, you know, construct their own dashboards and queries to get the things that they need. And I've certainly seen what you're saying, this pretty important business information being hard-coded, and that ends up being less accessible, right? And less insightful, really.

+ +

One other area of this topic that I think I've also bumped into before is specifically a QA engineer or, like, a QA team and empowering them to be able to do their jobs. Oftentimes, I've noticed that QA environments are not as well-maintained as maybe they should be, where the data that's seeded or, you know, kind of overtime in this environment is a little wonky.

+ +

I've also experienced, while working on a feature, kind of having to go back and forth between whoever is helping QA my work telling them, like, "Oh, this isn't finished yet. So, like, don't worry about this that you're testing," or, you know, "Actually, that does look wrong. But let me look into it over on this end." And I found it sometimes difficult to navigate because I want them to be more empowered to test their feature without that uncertainty over whether something is intentional or actually broken.

+ +

JOËL: In this case, do you think it's more about communication between development and QA, clear acceptance criteria, or clear descriptions of what changes have been pushed up for review and what's not in scope? Is that where you're headed?

+ +

STEPHANIE: I think that's a part of it. But I actually think there are more technical considerations, especially in terms of whether our environments all align in terms of the data we're expecting, right? Does our dev environment kind of look like our QA environment, which looks like our production environment? Because I've certainly been in projects where that's, like, all over the place, and that really messes up the different expectations we have.

+ +

We all know the "Oh, it worked in my local" [laughs] response to when things come up in other environments that are unexpected. And I wonder if there is more attention that we should be having towards making sure that just because this environment is not the main one that we're working in as developers, that people who are having to use it have an equally good user experience.

+ +

JOËL: I like that you brought up the term user experience because oftentimes, as developers, and just, I think, product teams in general, we're trying to make something good for the customers of the application. But there are a lot of other people that have to interact with it in sort of more ancillary roles; like you mentioned, it might be QA. It might be customer support. It might be business development. And they're not the customer. And so because of that, they're often kind of a second thought or even sort of no thought at all.

+ +

And so they do their jobs as best they can with what they've got, and sometimes get really creative getting around some of the hurdles that are in place. But we can often, with very little effort because the bar is so low, make these people's lives a lot better by applying just a little bit of the same approach that we would use to make software great for a customer to use for teammates in these other roles.

+ +

STEPHANIE: Yeah, absolutely. Especially because we have that line of communication open with them, and, like you said, they are also our users of our applications. And especially for QA folks, too, in some ways, they're the first line of defense of our users, right? They are a resource for us to know if the customers will eventually have a poor experience or not.

+ +

And I was thinking about that back-and-forth communication I mentioned with QA, you know, trying to explain, like, oh, this isn't finished yet, so maybe, like, you should not expect this to happen. But, oftentimes, that perhaps is a signal that we haven't thought about the way that we're developing our feature to be able to be released to customers in a more incremental way. Or we might be hand-waving over something that ends up being a bug later on.

+ +

JOËL: Definitely. For myself, I see that as a... code smell is maybe not the right term here, but maybe acceptance criteria smell. If I'm trying to write out some acceptance criteria, and I'm having to say, like, "Oh, but, like, ignore this, and, like, pretend this doesn't exist. All of these, like, weird edge cases and exceptions we're trying to put in, are oftentimes a sign that maybe the work was not scoped correctly.

+ +

STEPHANIE: I'm curious, in your workflow, will you just make those improvements if you have the opportunity to? Or do you end up bringing that to the team or creating a ticket for it? How does that fit in when you identify areas that could be improved?

+ +

JOËL: I think it depends on the team's current workload. Oftentimes, if it's just something small, it's something I can just slip into my day, and it makes somebody else's life easier, that's great. Otherwise, it can be a thing that needs to be brought up with the team in general. And then it's the thing that we prioritize, and we put it in the backlog because, like you said, the main users of our app are customers. But all of these other teammates are also users of our app in other ways, and so they need certain features to get their job done.

+ +

And so it's worthwhile to, I think, at a product planning level, take those into account and prioritize them with the customer-facing things. And sometimes, because those other teams don't have as much of a voice at the table, it's up to us as developers because we sometimes have that direct communication where we're talking to them and sort of going back and forth about, "Oh, can you change this in the database for me?" or "Can you do this?" And it can be up to us to champion these other teammates' needs with the team and with the product organization in general.

+ +

STEPHANIE: Yeah, I really like the way you put that. I think you used the word champion. And I've seen this also go the other direction, where we add more processes in place, where the direct communication that needs to be gatekept a little bit through a manager because the manager is trying to protect the time of the team. And that is one way to handle the issue of these requests taking too much of the team's time.

+ +

But I think at some point, as an IC, you also have the agency to champion or advocate for how you use your own development time. And that reminds me of something I heard from Rose Wiegley over at Shopify about what it means to be, like, a staff or a senior developer, and that is sharing that I'm going to do this, and this is why. And that means that I won't have time to do this other thing that I may be committed to earlier. But you know, these are my reasons. And if anyone sees any problems with that, let me know.

+ +

And I've been thinking about that a lot in terms of figuring out how to do the kind of work that I value. And for you and me, that does sometimes mean building those tools to empower people who aren't developers. But that is, yeah, just a way that we can assert a little bit of that agency rather than having to get the buy-in to even consider setting time aside for that work.

+ +

JOËL: Yeah, I think some of the really fulfilling work that I've done has been just sometimes taking a morning and, quote, unquote, "pairing" with, like, a business development or a customer service person and just saying, "Hey, can I just sit with you while you process this kind of request or problem that you're trying to do?" And then just really seeing what they do and all the steps and being able to ask a lot of questions and kind of putting my product developer hat on. And because then I know, internally, all the things that are happening, I can quickly see, oh, okay, you're- having to do these, like, five steps to get around this really annoying thing that's just, like, a rough corner that we have that I can, like, just easily smooth the way, you know, with a 10-minute one-line fix. I'm going to go and do that, and, you know, by the afternoon, that's already done, and that's saved them so much time or so much annoyance because it's not always time. Sometimes it's just annoyance. And their life is better. And I put very little effort into it. Most of it is just taking the time just to talk to each other and to try to understand each other.

+ +

So I think we brought up the idea in the beginning of trying to empower other teams to not sort of centralize all the ability to execute on change within the development team. And sometimes, you can go to fairly extreme lengths to that. One that I've seen is the idea of end-user programming or end-user development, where the using the software rather than the team developing it has some sort of way where they can sort of customize or build on, or sometimes even script or -code -their experience. Is that something you've ever had to deal with or interact with on a project?

+ +

STEPHANIE: Yeah, it's really interesting that you brought that up because I had mentioned going with a SaaS solution earlier as something that I've seen before. And that reminds me of when I worked on a client project where we were using Freshsales to integrate with the business domain of the client. And this would eventually be the main software that the sales team would use. And the reason that we went with Freshsales was because it allowed for a lot of that custom configuration and workflows that they could create for themselves for their needs.

+ +

Though ironically, as we were kind of butting up into the limitations of Freshsales and how it didn't necessarily work for the way we were representing our data, we kind of joked that we almost wished we had to build the tool from scratch ourselves. So I think there are trade-offs there, you know, folks had done a lot of research to figure out the right SaaS solution for this project that we were doing. And yet, you know, inevitably, like, there were some cons with the third-party and how we were able to integrate with it. And it was actually also replacing something that had been built in-house and had become difficult to maintain or something that the company decided that they didn't want to maintain anymore. So I hate to say it, but I really think it [laughs] depends.

+ +

JOËL: And now you're getting into the classic build versus buy dilemma for chunks of your software.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I think a way that I've seen, and this happens in a kind of a smaller sense, is providing escape hatches for data. And so maybe you've got a couple of small dashboards, or you've got just a lot of things that happen in your system. And you don't have the development time, or you don't want to prioritize that time right now to build something custom for maybe your business development team. But you provide certain reports that can be exported as CSV or Excel, which then the business development team will load into Excel and do the work that they need.

+ +

And now they're empowered to do what they want instead of having to ask for more information or just being limited to what was on that web UI. Similarly, sometimes, when you're able to Import a CSV, I've seen this happen a lot, where in software that's not built just right for a customer service team, they'll often export a CSV of data, put it into Excel, manipulate it the way they really want it to be, and then re-import it into the system. And so that can be a great way to temporarily empower people. I think it's also a product smell. Oftentimes, there's a fundamental flaw of the way that your product works because your team is trying to go around it. It's so bad. But as a shorter-term solution, that can be great.

+ +

STEPHANIE: That makes me think that Excel is the real end-user programming software.

+ +

JOËL: It really is. It really is. I do really like the idea of end-user Programming, though. And rather than developers or even product people having to decide how our software should work for our users, shifting that to the masses and letting them have all of that empowerment and agency that we're talking about.

+ +

There's a technology research lab called Ink & Switch, and they build a lot of really cool end-user programming tools. I think I've seen some, like, note-taking software, that they've done, and just other research into why it's important and how it can impact users. And I have read a little bit of their work, and I think it's really cool. So I'll be sure to add that to our show notes.

+ +

JOËL: I think even as developers, we like some of these ideas of end-user development. We have that a lot in our tooling. But then, even when we interact with other people's software that we don't own...because we're used to interacting with our own software, we own it. We can change anything we want. We've got complete freedom. But the moment we interact with somebody else's software and, of course, it doesn't work 100% the way we need it to, it is sometimes nice to have sort of ways to hook into it so that we can get the things we want and then maybe do some extra manipulation on our own. And APIs are often how we do that. And so the equivalent of providing an API for another developer, well, what is that for our other teams?

+ +

STEPHANIE: Yeah, great questions to consider.

+ +

JOËL: You know, it could be a CSV export. It could be maybe there's some easy way to connect to a Zapier plugin. And now, you know, they don't need to ask the dev team, "Oh, we want to receive this notification email internally when this event happens. They can just connect to a Zapier plugin and have it send an email or do something in Salesforce or all these other things that are helpful in their workflows but that we've not taken the time to build into the core software. And now they're empowered to do their work and not blocked on us.

+ +

STEPHANIE: That's interesting because as you were talking about that, it made me think of development tooling that we get to integrate with and how those APIs are usually very flexible. And let us decide what we need and ask the API for that as opposed to it dictating it for us. And, you know, if that's something that we get to enjoy, then, yeah, we should certainly think about how you can spread that to others.

+ +

JOËL: I love that. On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Joël has a bike shorts update; Stephanie has a garden one.

+ +

Often, power is centralized within the dev team. This is usually because they are the only ones able to execute. Sometimes this ends up interfering with team processes and workload. Joël is a fan of empowering other teams to do things themselves.

+ +
+ + + +

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, in a recent episode, I had mentioned that I was going to go on vacation on a bike trip and that I had purchased a pair of bike shorts to try out on that trip to see if that would help. And, wow, that was a great purchase. It literally saved my butt.

+ +

STEPHANIE: That's awesome. I'm really glad that they worked out for you.

+ +

JOËL: Still sore. This was a five-day biking trip. And I think day two was the worst, but after that, things got better. But the shorts definitely helped.

+ +

STEPHANIE: I think my favorite part about us talking about biking and bike shorts is that we're finally living up to the name of our podcast. [laughs] Turns out that bikeshedding is actually even more, bikeshedding when it's about actual bike stuff. And a listener named James even wrote in with some pro tips about, you know, how to care for your bike shorts and, you know, have a comfortable biking experience. And gave some good tips for me on some longer rides to check out near me in Chicago.

+ +

JOËL: So it sounds like there's some crossover between the software developer community and bike enthusiasts community who also tune into this podcast.

+ +

STEPHANIE: I do think that we have gotten tweets before from, I think, like, the motorcycle Twitter tagging us @_bikeshed, perhaps maybe trying to tag a different account but, yeah, ended up in our Twitter inbox instead.

+ +

JOËL: Now we just need some sweet, sweet bicycle sponsorships. So, Stephanie, what's been new in your world?

+ +

STEPHANIE: I have a garden update. Last year, we purchased a small fig tree from the internet. It turns out that you can get little fruit trees delivered to your door. And this was, I think, around the fall, so it was getting a little cooler. And here in Chicago, we have to bring some of our plants inside to overwinter. And so we brought the fig indoors, and it's maybe, like, two or three feet tall. And, you know, over the few months, we were just, like, caring for it. And I was really excited to see that it had started fruiting several months ago. And I got to show it to all of my co-workers in a call.

+ +

I, like, picked up this kind of large pot with our little fig tree, and I, like, held it really close to my camera and tried to point out the fruit to the other people on the call, which I realized was perhaps not a very effective way to show off my plants. Like, you could just take a picture and send it in Slack. And I was like, yes, I could have done that.

+ +

But yesterday (Now our fig tree has been outside for a little while since it's warmer.) I noticed that they were ripe, and I got to harvest our figs and eat them, and they were delicious. And I got to update the team on my little fig adventure. And this time I did take pictures of the fruits and sent them in Slack instead of trying to bring this tree in from the outdoors.

+ +

JOËL: That's exciting. Because I'm a fan of the design pattern, I have to ask, is this a strangler fig?

+ +

STEPHANIE: It's not a strangler fig, though I have seen one in the wild on a trip to Florida. I saw a really big strangler fig, you know, completely, like, enveloping another tree, and that was really cool. If you ever get to see one in person, I think it's just, I don't know, just really amazing how nature works.

+ +

JOËL: I did not realize they were wild in Florida, something to keep an eye out for next time I'm there.

+ +

STEPHANIE: Definitely. So, in a recent retro on my client team, we were discussing the one-off requests our team has been getting from the folks over on the sales and client support side. Oftentimes, this involved running a script in our production console to fix some issue that a customer was experiencing. And we were talking about what we could do to make this process a little more automated, make it a little less time-consuming on our end. Even though it would just take a few minutes to run this script, we were seeing that we were getting this request repeatedly.

+ +

I'm curious if you've kind of been in this situation before where dev work is required and kind of eating into time that we are trying to be delivering on other feature work for similar one-off requests or to support other folks at the company.

+ +

JOËL: Yeah. I think it's a pretty common pattern that I've seen. And I think sometimes it can actually start from a healthy place. If you're taking very much of an MVP philosophy and you're building a small version of your product to start with, you're not going to have a whole suite of admin tools available. You might not even have any admin people. It might just be a founder and a technical co-founder. And so, for the first few hundred customers you have, maybe the way you make changes is by loading up the Rails production console and making a change. And that's good enough, but that doesn't scale.

+ +

STEPHANIE: Yeah. You bring up a good point that I think one thing that we get to experience as consultants is seeing many different companies at different stages in their business. And I think I've seen this issue in many different iterations based on the size of the company, right? So you were saying for an MVP product, there's no admin support at all. Maybe you have a project that is now thinking of how to introduce a little bit of admin tooling and might reach for something lightweight like a gem. I've also seen custom admin dashboards, and that being its own namespace and having all of that feature set hand-rolled, and then maybe some other company might opt for a Software as a Service solution.

+ +

JOËL: Yeah, there's a lot of different implementations that happen at various stages of companies. I think one thing that does seem to stay pretty constant, though, is oftentimes; other teams don't have the tools they need to make the changes they need to. So, if you have a customer service person and they're receiving a complaint or they're having to make a change, they're not always empowered to make the changes they need to. They need to talk to the dev team, who then need to make changes.

+ +

And the dev team don't really want to spend their day doing admin work. They are incentivized to ship features. And so both sides are unhappy. And it kind of comes from a sort of fundamental, I think, over-empowering of the dev team and kind of a disempowering of some of the other departments within the company, if that makes sense.

+ +

STEPHANIE: Yeah, that's interesting because I don't think it necessarily is intentional, the way that that happens, right? It's not like you start building a product, and you are saying, "Okay, we only want to give devs the power to change all of this stuff at the production level." It's just something inherent, I suppose, to the work that we do. And there's a lot of active effort that needs to be taken to spread some of that empowerment around.

+ +

JOËL: Yeah, generally, it is not some sort of, like, nefarious corporate politics that's happening where the CTO is, like, hoarding all the power, or it's a turf war or anything like that. Like you said, it's kind of an emergent property. As developers, we're often used to being sort of ultra-empowered to do what needs to be done. In general, development teams are highly respected within companies, and so people listen to them. But also, in order to do their job, they need to have access to a lot of things.

+ +

So you often have production access to all the things and the admin credentials. And if there's something that doesn't work, you write code, and you can change the sort of fundamental underlying platform that you're working with. And so you're generally empowered to make the changes you need to make your life better or if you're blocked on something. And that's not necessarily true for other departments who are working in the system that we're building.

+ +

STEPHANIE: Yeah, it's kind of interesting the duality that you have identified where we do have all of this power or capability to change the system. But you had mentioned earlier that sometimes it actually gets in the way of our work, that it can be a drag to do if we have other competing priorities, and that those mundane tasks end up being something that we also don't enjoy doing. And so, like you're saying, like, no one is quite happy. I wonder at what point you, as a developer, having repeatedly been asked to do these kinds of tasks for other departments when you, would start advocating for building tooling.

+ +

JOËL: I don't think there's a kind of a clear dividing line, like, oh, after three requests, you must build a dashboard. It's probably more about just general communication with the other teams. I like to think of it from kind of two perspectives. From the perspective of the developers, how can we keep them efficiently working on what they need to prioritize, which is typically new feature development?

+ +

And then, from the perspective of other teams, how can they be empowered to do the work that you need to do without getting blocked? Because just like the dev team doesn't like to get blocked on all sorts of things, other teams don't like it either. And so, how can we make sure that other team members within the company are empowered to do their work as efficiently as possible?

+ +

STEPHANIE: Yeah, that's interesting. I think as an IC, I've been in different positions, depending on the context of my work. There have been times when I've been happy to help with that kind of request, right? Because I know that I'm unblocking someone else. I'm facilitating their work. And they usually appreciate it too. And so maybe if that's still the case and that there's not necessarily any pain that comes with that being just the process that it is from both sides, like, that's perfectly fine.

+ +

But then it's totally fair for, you know, either party, once they do feel like it's blocking other work, to start looking into maybe how much time you're spending on these one-off requests, especially if it's being spread around to other team members. You know how much effort you're making, but, like, a manager might actually be more aware of how it's affecting multiple folks on the team and wanting to figure out, like, how that sits in with the other priorities that the team is working on.

+ +

JOËL: Yeah, I'm glad you mentioned talking to other people because I might be quite happy to say, "Oh, I'm going to go and, you know, go into the database and make a small change." But just because it's easy for me to do and I can take, you know, 10 minutes out of my day to do it, doesn't mean that that experience is good for, let's say, a customer service person who had to get blocked or had to ask someone else to help to move this ticket forward. When if it was something they could do themselves, that would have been a much better experience.

+ +

So, even though it's a very fairly, you know, cheap request and because I don't get them a lot, I'm happy to do them, it's maybe not a good experience for my customer service colleague. So, like you said, it is important to get people's experiences on all sides.

+ +

STEPHANIE: One thing that I have seen a lot is for these things to start as configuration in a YAML file that requires developers to change and then commit to the codebase whenever, you know, maybe it's, like, a list of products or a list of prices, something that is, you know, really the business domain. And yet we are hard coding it and, like, codifying it into our source control.

+ +

JOËL: Oof, yes. I have been in those projects, yeah. Now, every time you want to make a change, a business person has to reach out to the dev team, and then you have to make a code change, and then you have to deploy it. And that just becomes a whole thing. And then they come back to you the next day and say, "Oh, actually, we talked about it, and we want it a little bit differently." And you have to go through that process again.

+ +

STEPHANIE: I think we reach for that just because we think it's faster maybe to set up, you know, some kind of, like, lightweight configuration file, rather than if you're working in Rails, you know, setting up a whole MVC for whatever thing you're trying to configure. And I'm curious if you think that's true or not.

+ +

JOËL: I think it depends. Sometimes it can be because this data feels very static, kind of hard-coded. And so it's not a thing you would necessarily want to have. In a database, it's more like a constant that you would have in your source control, except that then you find out that your constant is not quite as constant as you thought it was. And I think maybe that's okay.

+ +

Writing software is all about kind of discovering the problem in the domain as it evolves and trying to not over-engineer things ahead of time. So, if we have a small set of values, maybe they're U.S. states that you deliver to or a small list of products or something that you feel is relatively hard coded, maybe it starts as a constant array hard coded into Ruby, maybe it is a YAML file that you load. Then, over time, there comes a point where you decide this should be a database table, and if it needs to be sort of pre-seeded, then there's a mechanism for that with database seeds in Rails.

+ +

STEPHANIE: Yeah, that's fair. I find it so interesting because most of the time, I've not seen that transition happen, right? It almost feels like some form of the bystander effect where everyone is just, well, I'm adding just one more thing. So I don't want to make this really big change now.

+ +

JOËL: And that's true for everything in code, right? You say, "Oh, this deeply nested condition, yeah, it should probably be restructured. But I'm just going to add, you know, an eighth nested level in there. And, like, eight is probably the limit, but mine is going to be the eighth, so it's going to be good." And then somebody comes in and says, "Well, you know, nine is not that bad, but the next person probably should refactor it." And then it's a mess.

+ +

STEPHANIE: Yeah, it's kind of like the entropy of code, I suppose, [laughs] where, you know, we had said it requires a lot of active energy and effort to make those changes to support other folks in different departments of the company. And I think that's, like, one very common area that we see things starting as configuration but then end up being something that you are needing to support in changing.

+ +

And I wonder if maybe that is a signal in itself, right? If you are getting this information from another team, like, someone external to the development team, I wonder if that's kind of a clue that this is something that should be reconsidered about whether you start with it being hard-coded.

+ +

JOËL: That's an interesting thought. There's a sense in which I think these always come from places external to the development team because it's a form of kind of product research when you're trying to understand what the features need to be, what this needs to happen. Unless this hard-coded data is purely structural or internal values, but it rarely is. There probably is a broader discussion to be had about the use of any sort of hard-coded data in a configuration file in a Rails app versus just always starting with a database table.

+ +

One thing that's nice about always having a database table is that if you ever need to connect it to other data in your system, now you can do things like table joins, where you can't join your users on some kind of YAML array, or you have to do some sort of Ruby Enumerable logic. You can't just do it in SQL.

+ +

STEPHANIE: Yeah. This is a bit of a tangent, I think. But that reminds me of when I worked at a product company where we had a very robust data warehouse, and all of that information was available to teams on the marketing side and on the data science side. And I actually really liked that because they were able to, you know, construct their own dashboards and queries to get the things that they need. And I've certainly seen what you're saying, this pretty important business information being hard-coded, and that ends up being less accessible, right? And less insightful, really.

+ +

One other area of this topic that I think I've also bumped into before is specifically a QA engineer or, like, a QA team and empowering them to be able to do their jobs. Oftentimes, I've noticed that QA environments are not as well-maintained as maybe they should be, where the data that's seeded or, you know, kind of overtime in this environment is a little wonky.

+ +

I've also experienced, while working on a feature, kind of having to go back and forth between whoever is helping QA my work telling them, like, "Oh, this isn't finished yet. So, like, don't worry about this that you're testing," or, you know, "Actually, that does look wrong. But let me look into it over on this end." And I found it sometimes difficult to navigate because I want them to be more empowered to test their feature without that uncertainty over whether something is intentional or actually broken.

+ +

JOËL: In this case, do you think it's more about communication between development and QA, clear acceptance criteria, or clear descriptions of what changes have been pushed up for review and what's not in scope? Is that where you're headed?

+ +

STEPHANIE: I think that's a part of it. But I actually think there are more technical considerations, especially in terms of whether our environments all align in terms of the data we're expecting, right? Does our dev environment kind of look like our QA environment, which looks like our production environment? Because I've certainly been in projects where that's, like, all over the place, and that really messes up the different expectations we have.

+ +

We all know the "Oh, it worked in my local" [laughs] response to when things come up in other environments that are unexpected. And I wonder if there is more attention that we should be having towards making sure that just because this environment is not the main one that we're working in as developers, that people who are having to use it have an equally good user experience.

+ +

JOËL: I like that you brought up the term user experience because oftentimes, as developers, and just, I think, product teams in general, we're trying to make something good for the customers of the application. But there are a lot of other people that have to interact with it in sort of more ancillary roles; like you mentioned, it might be QA. It might be customer support. It might be business development. And they're not the customer. And so because of that, they're often kind of a second thought or even sort of no thought at all.

+ +

And so they do their jobs as best they can with what they've got, and sometimes get really creative getting around some of the hurdles that are in place. But we can often, with very little effort because the bar is so low, make these people's lives a lot better by applying just a little bit of the same approach that we would use to make software great for a customer to use for teammates in these other roles.

+ +

STEPHANIE: Yeah, absolutely. Especially because we have that line of communication open with them, and, like you said, they are also our users of our applications. And especially for QA folks, too, in some ways, they're the first line of defense of our users, right? They are a resource for us to know if the customers will eventually have a poor experience or not.

+ +

And I was thinking about that back-and-forth communication I mentioned with QA, you know, trying to explain, like, oh, this isn't finished yet, so maybe, like, you should not expect this to happen. But, oftentimes, that perhaps is a signal that we haven't thought about the way that we're developing our feature to be able to be released to customers in a more incremental way. Or we might be hand-waving over something that ends up being a bug later on.

+ +

JOËL: Definitely. For myself, I see that as a... code smell is maybe not the right term here, but maybe acceptance criteria smell. If I'm trying to write out some acceptance criteria, and I'm having to say, like, "Oh, but, like, ignore this, and, like, pretend this doesn't exist. All of these, like, weird edge cases and exceptions we're trying to put in, are oftentimes a sign that maybe the work was not scoped correctly.

+ +

STEPHANIE: I'm curious, in your workflow, will you just make those improvements if you have the opportunity to? Or do you end up bringing that to the team or creating a ticket for it? How does that fit in when you identify areas that could be improved?

+ +

JOËL: I think it depends on the team's current workload. Oftentimes, if it's just something small, it's something I can just slip into my day, and it makes somebody else's life easier, that's great. Otherwise, it can be a thing that needs to be brought up with the team in general. And then it's the thing that we prioritize, and we put it in the backlog because, like you said, the main users of our app are customers. But all of these other teammates are also users of our app in other ways, and so they need certain features to get their job done.

+ +

And so it's worthwhile to, I think, at a product planning level, take those into account and prioritize them with the customer-facing things. And sometimes, because those other teams don't have as much of a voice at the table, it's up to us as developers because we sometimes have that direct communication where we're talking to them and sort of going back and forth about, "Oh, can you change this in the database for me?" or "Can you do this?" And it can be up to us to champion these other teammates' needs with the team and with the product organization in general.

+ +

STEPHANIE: Yeah, I really like the way you put that. I think you used the word champion. And I've seen this also go the other direction, where we add more processes in place, where the direct communication that needs to be gatekept a little bit through a manager because the manager is trying to protect the time of the team. And that is one way to handle the issue of these requests taking too much of the team's time.

+ +

But I think at some point, as an IC, you also have the agency to champion or advocate for how you use your own development time. And that reminds me of something I heard from Rose Wiegley over at Shopify about what it means to be, like, a staff or a senior developer, and that is sharing that I'm going to do this, and this is why. And that means that I won't have time to do this other thing that I may be committed to earlier. But you know, these are my reasons. And if anyone sees any problems with that, let me know.

+ +

And I've been thinking about that a lot in terms of figuring out how to do the kind of work that I value. And for you and me, that does sometimes mean building those tools to empower people who aren't developers. But that is, yeah, just a way that we can assert a little bit of that agency rather than having to get the buy-in to even consider setting time aside for that work.

+ +

JOËL: Yeah, I think some of the really fulfilling work that I've done has been just sometimes taking a morning and, quote, unquote, "pairing" with, like, a business development or a customer service person and just saying, "Hey, can I just sit with you while you process this kind of request or problem that you're trying to do?" And then just really seeing what they do and all the steps and being able to ask a lot of questions and kind of putting my product developer hat on. And because then I know, internally, all the things that are happening, I can quickly see, oh, okay, you're- having to do these, like, five steps to get around this really annoying thing that's just, like, a rough corner that we have that I can, like, just easily smooth the way, you know, with a 10-minute one-line fix. I'm going to go and do that, and, you know, by the afternoon, that's already done, and that's saved them so much time or so much annoyance because it's not always time. Sometimes it's just annoyance. And their life is better. And I put very little effort into it. Most of it is just taking the time just to talk to each other and to try to understand each other.

+ +

So I think we brought up the idea in the beginning of trying to empower other teams to not sort of centralize all the ability to execute on change within the development team. And sometimes, you can go to fairly extreme lengths to that. One that I've seen is the idea of end-user programming or end-user development, where the using the software rather than the team developing it has some sort of way where they can sort of customize or build on, or sometimes even script or -code -their experience. Is that something you've ever had to deal with or interact with on a project?

+ +

STEPHANIE: Yeah, it's really interesting that you brought that up because I had mentioned going with a SaaS solution earlier as something that I've seen before. And that reminds me of when I worked on a client project where we were using Freshsales to integrate with the business domain of the client. And this would eventually be the main software that the sales team would use. And the reason that we went with Freshsales was because it allowed for a lot of that custom configuration and workflows that they could create for themselves for their needs.

+ +

Though ironically, as we were kind of butting up into the limitations of Freshsales and how it didn't necessarily work for the way we were representing our data, we kind of joked that we almost wished we had to build the tool from scratch ourselves. So I think there are trade-offs there, you know, folks had done a lot of research to figure out the right SaaS solution for this project that we were doing. And yet, you know, inevitably, like, there were some cons with the third-party and how we were able to integrate with it. And it was actually also replacing something that had been built in-house and had become difficult to maintain or something that the company decided that they didn't want to maintain anymore. So I hate to say it, but I really think it [laughs] depends.

+ +

JOËL: And now you're getting into the classic build versus buy dilemma for chunks of your software.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I think a way that I've seen, and this happens in a kind of a smaller sense, is providing escape hatches for data. And so maybe you've got a couple of small dashboards, or you've got just a lot of things that happen in your system. And you don't have the development time, or you don't want to prioritize that time right now to build something custom for maybe your business development team. But you provide certain reports that can be exported as CSV or Excel, which then the business development team will load into Excel and do the work that they need.

+ +

And now they're empowered to do what they want instead of having to ask for more information or just being limited to what was on that web UI. Similarly, sometimes, when you're able to Import a CSV, I've seen this happen a lot, where in software that's not built just right for a customer service team, they'll often export a CSV of data, put it into Excel, manipulate it the way they really want it to be, and then re-import it into the system. And so that can be a great way to temporarily empower people. I think it's also a product smell. Oftentimes, there's a fundamental flaw of the way that your product works because your team is trying to go around it. It's so bad. But as a shorter-term solution, that can be great.

+ +

STEPHANIE: That makes me think that Excel is the real end-user programming software.

+ +

JOËL: It really is. It really is. I do really like the idea of end-user Programming, though. And rather than developers or even product people having to decide how our software should work for our users, shifting that to the masses and letting them have all of that empowerment and agency that we're talking about.

+ +

There's a technology research lab called Ink & Switch, and they build a lot of really cool end-user programming tools. I think I've seen some, like, note-taking software, that they've done, and just other research into why it's important and how it can impact users. And I have read a little bit of their work, and I think it's really cool. So I'll be sure to add that to our show notes.

+ +

JOËL: I think even as developers, we like some of these ideas of end-user development. We have that a lot in our tooling. But then, even when we interact with other people's software that we don't own...because we're used to interacting with our own software, we own it. We can change anything we want. We've got complete freedom. But the moment we interact with somebody else's software and, of course, it doesn't work 100% the way we need it to, it is sometimes nice to have sort of ways to hook into it so that we can get the things we want and then maybe do some extra manipulation on our own. And APIs are often how we do that. And so the equivalent of providing an API for another developer, well, what is that for our other teams?

+ +

STEPHANIE: Yeah, great questions to consider.

+ +

JOËL: You know, it could be a CSV export. It could be maybe there's some easy way to connect to a Zapier plugin. And now, you know, they don't need to ask the dev team, "Oh, we want to receive this notification email internally when this event happens. They can just connect to a Zapier plugin and have it send an email or do something in Salesforce or all these other things that are helpful in their workflows but that we've not taken the time to build into the core software. And now they're empowered to do their work and not blocked on us.

+ +

STEPHANIE: That's interesting because as you were talking about that, it made me think of development tooling that we get to integrate with and how those APIs are usually very flexible. And let us decide what we need and ask the API for that as opposed to it dictating it for us. And, you know, if that's something that we get to enjoy, then, yeah, we should certainly think about how you can spread that to others.

+ +

JOËL: I love that. On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+62pU-FtV + + ]]> + + Joël Quenneville + Stephanie Minn + + + 387: RubyKaigi 2023 with Mina Slater + https://bikeshed.thoughtbot.com/387 + 8c2aa49c-6840-4fcc-8e65-ff4e526fd396 + Tue, 06 Jun 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie is joined by a special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater. + +Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure! + 31:22 + no + + + Stephanie is joined by very special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater. +Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure! +RubyKaigi (https://rubykaigi.org/2023/) +WNB.rb (https://www.wnb-rb.dev/) +Understanding the Ruby Global VM Lock by observing it by Ivo Anjo (https://rubykaigi.org/2023/presentations/KnuX.html#day1) +gvl-tracing (https://github.com/ivoanjo/gvl-tracing) +Justin Searls' RubyKaigi 2023 live coverage (https://blog.testdouble.com/field-reports/ruby-kaigi/) +Prioritizing Learning episode (https://www.bikeshed.fm/362) +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 and today. I'm joined by a very special guest, fellow thoughtboter Mina Slater. Mina, would you like to introduce yourself to our audience? +MINA: Yeah. Hi, everyone. I am Mina. I am a Senior Developer on Mission Control, which is thoughtbot's DevOps and SRE team. +STEPHANIE: So, Mina, what's new in your world? +MINA: Well, I start marathon training this week. So I hope that this conversation goes well and lasts you for three months because you're probably not going to see or hear from me all summer. +STEPHANIE: Yes. That sounds...it sounds hard, to be honest, marathon training in the summer. When I was doing a bit more running, I always thought I would wake up earlier than I did and, you know, beat the heat, and then I never would, and that really, like, was kind of rough. +MINA: Yeah, actually, I was thinking about my plans for today. I didn't wake up early enough to run in the morning. And so I was calculating, like, okay, by midday, it's going to be too hot. So I'm going to have to wait until, like, 6:00 p.m. [laughs] +STEPHANIE: Yeah, yeah. Or, if you're like me, there's a very real chance that you just skip it altogether. +[laughter] +MINA: Well, I have a deadline, so... [laughs] +STEPHANIE: That's true. When is your marathon race? +MINA: This is actually the first year I'm doing two in a calendar year. So I'm doing Berlin in September. And then, three weeks after that, I'm going to run one in Detroit. +STEPHANIE: Nice. At least you'll be ready. You'll, like, have done it. I don't know; it kind of sounds maybe a bit more efficient that way. [laughs] +MINA: Theoretically. But, you know, ask me in October. I'll let you know how it goes. +STEPHANIE: That's true. You might have to come back on as a guest. [laughs] +MINA: Just to talk about how it went. [laughs] +STEPHANIE: Yeah, exactly. +MINA: So that's what's new with me. What's new in your world, Steph? +STEPHANIE: So, a while back on a previous Bike Shed episode, I talked about joining this client team and, in their daily team syncs, in addition to just sharing what we were up to and what we were working on, we would also answer the question what's something new to us. And that was a space for people to share things that they learned or even just, like, new things that they tried, like food, or activities, or whatnot. And I really enjoyed it as a way to get to know the team, especially when I was new to that client project. +And recently, someone on the team ended up creating a random question generator. So now the question for the daily sync rotates. And I've been having a lot of fun with that. Some of the ones that I like are, what made you laugh recently? What's currently playing on your Spotify or YouTube? No cheating. +MINA: [laughs] +STEPHANIE: And then, yesterday, we had what's for dinner? As the question. And I really liked that one because it actually prompted me to [chuckles] think about what I was going to do for dinner as opposed to waiting till 5:00 p.m. and then stressing because I'm already hungry but don't have a plan [chuckles] for how I'm going to feed myself yet. So it ended up being nice because I, you know, kind of was inspired by what other people mentioned about their dinner plans and got my stuff together. +MINA: That's shocking to me because we had just come off of two weeks of traveling together. And the one thing I learned about you is that you plan two meals ahead, but maybe that is travel stuff. +STEPHANIE: I think that is extremely correct. Because when you're traveling, you're really excited about all the different things that you want to eat wherever you are. And so, yeah, we were definitely...at least I was planning for us, like, two or three meals [laughs] in advance. +MINA: [laughs] +STEPHANIE: But, when I'm at home, it is much harder to, I don't know, like, be motivated. And it just becomes, like, a daily chore. [laughs] So it's not as exciting. +MINA: I think I'm the same way. I just had a whole bunch of family in town. And I was definitely planning dinner before we had breakfast because I'm like, oh, now I have to be responsible for all of these people. +STEPHANIE: Yeah. I just mentioned the questions because I've been really having fun with them, and I feel a lot more connected to the team. Like, I just get to know them more as people and the things they're interested in, and what they do in their free time. So, yeah, highly recommend adding a fun question to your daily syncs. +MINA: Yeah, we started doing that on Mission Control at our team sync meetings recently, too, where the first person...we actually have an order generator that somebody on the team wrote where it takes everyone's first and last name and scramble them and then randomizes the order. So you kind of have to figure out where in the queue you are and who's coming up next after you. But the first person that goes in the queue every day has to think of an icebreaker question. +STEPHANIE: That's kind of a lot of pressure [laughs] for a daily meeting, especially if you're having to unscramble names and then also come up with the icebreaker question. I personally would be very stressed [laughs] by that. But I also can see that it's...I also think it's very fun, especially for a small team like yours. +MINA: Yeah, yeah, just seven of us; we get to know really well what letters are in everyone's names. But I was first today, and I didn't have an icebreaker question ready. So I ended up just passing. So that's also an option. +STEPHANIE: That's fair. Maybe I'll link you to our random question generator, so you can find some inspiration. [laughs] +MINA: Yeah, it's a ChatGPT situation. +STEPHANIE: So you mentioned that you and I had just been traveling together for two weeks. And that's because Mina and I were at RubyKaigi in Matsumoto, Japan, earlier this May. And that's the topic of today's episode: Our Experience at RubyKaigi. And the really cool thing that I wanted to mention was that this was all possible because Mina and I were sponsored by WNB.rb, which is a global community of women and non-binary people working in Ruby. And I've mentioned this group on the show before, but I wanted to plug it again because I think that this was something really special that we got to do. +WNB runs a lot of initiatives, like, meetups and panels supporting people to speak at conferences and book clubs. And, you know, just many different programming events for supporting women and non-binary Rubyists in their career growth. And they are recently beginning a new initiative to sponsor folks to attend conferences. And Mina, you and I were the first people to get to try this out and go to an international conference. So that was really awesome. It was something that I don't think I would have done without the support from WNB. +MINA: And you almost didn't do. I think there was a lot of convincing [chuckles] that went on at the beginning to kind of get you to, like, actually consider coming with me. +STEPHANIE: It's true. It's true. I think you had DMed me, and you were, like, so, like, RubyKaigi, like, eyeball emoji. [laughs] I was, I think, hesitant because this was my first international conference. And so there was just a lot of, like, unknowns and uncertainty for me. And I think that's going to be part of what we talk about today. But is there anything that you want to say about WNB and how you felt about being offered this opportunity? +MINA: Yeah. When Emily and Jemma, the founders of WNB, approached us with this opportunity and this offer, I think I was...taken aback is not really quite the right words but, like, surprised and honored, really, I think it's a better word. Like, I was very honored that they thought of us and kind of took the initiative to come to us with this offer. +So I'm really grateful for this opportunity because going to RubyKaigi, I think it's always something that was on my radar. But I never thought that...well, not never. I thought that I had to go as a speaker, which would have been, like, a three to five-year goal. [laughs] But to be able to go as an attendee with the support of the group and also of thoughtbot was really nice. +STEPHANIE: Yeah, absolutely. That investment in our professional development was really meaningful to me. So, like you, I'm very grateful. And if any of our listeners are interested in donating to WNB.rb and contributing to the community's ability to send folks to conferences, you can do so at wnb-rb.dev/donate. Or, if you work for a company that might be interested in sponsoring, you can reach out to them at organizers@wnb-rb.dev. +MINA: I highly recommend doing that. +STEPHANIE: So, one of the questions I wanted to ask you about in terms of your RubyKaigi experience was, like, how it lined up with your expectations and if it was different or similar to what you were expecting. +MINA: Yeah, I have always heard that when people talk about RubyKaigi as a conference and about its contents, the word that everyone uses to describe it is technical. I have already had sort of a little bit of that expectation going in. But I think my interpretation of the word technical didn't really line up with how actually technical it was. And so that was one thing that was different than what I had expected. +STEPHANIE: Could you elaborate on what was surprising about the way that it was technical? +MINA: Yeah. I think that when I hear technical talks and having been to some Ruby and Rails confs here in the States, when I hear about technical talks, it's a lot more content about people using the technology, how they use Ruby to do certain things, or how they use Rails to achieve certain goals in their day-to-day work or side projects. But it seems at RubyKaigi; it is a lot more about the language itself, how Ruby does certain things, or how interpreters implement Ruby, the language itself. So I think it's much more lower-level than what I was expecting. +STEPHANIE: Yeah, I agree. I think you and I have gone to many of Ruby Central conferences in the U.S., like RubyConf and RailsConf. So that was kind of my comparison as well is that was, you know, the experience that I was more familiar with. And then, going into this conference, I was very surprised that the themes of the talks were, like you said, very focused on the language itself, especially performance, tooling, the history and future of Ruby, which I thought was pretty neat. +Ruby turns 30, I think, this year. And one thing that I noticed a lot was folks talking about using Ruby to reflect on itself and the possibilities of utilizing those capabilities to improve our experience as developers using the language. +MINA: Yeah. I think one of the things I was really fascinated by is...you had mentioned the performance. There were several talks about collecting how Ruby performs at certain levels. And I thought that that was quite interesting and things I had never thought about before, and I'm hoping to think about in the future. [laughs] +STEPHANIE: Yeah. One talk that I went to was Understanding the Ruby Global VM Lock by Ivo Anjo. And that was something that, you know, I had an awareness of that Ruby has this GVL and certain...I had, like, a very hand-wavy understanding about how, like, concurrency worked with Ruby because it hasn't been something that I've really needed to know too deeply in my day-to-day work. Like, I feel a little bit grateful not to have run into an issue where I had to, you know, dive deep into it because it was causing problems. [laughs] +But attending that talk was really cool because I liked that the speaker did give, like, an overview for folks who might be less familiar but then was able to get really deep in terms of, like, what he was doing workwise with improving his performance by being able to observe how the lock was being used in different threads and, like, where it might be able to be improved. And he shared some of his open-source projects that I'll link in the show notes. +But, yeah, that was just something that I was vaguely aware of and haven't yet, like, needed to know a lot about, but, you know, got to understand more by going to this conference. And I don't think I would have gotten that content otherwise. +MINA: Yeah, I agree. The talk that you are referencing is one of my favorite as well. I think, like you, kind of this vague idea of there's things going on under the hood in Ruby is always there, but to get a peek behind the curtain a little bit was very enlightening. I wrote down one of the things that he said about how highly optimized Ruby code can still be impacted and be slow if you don't optimize GVL. And he also shared, I think, some strategies for profiling that layer in your product, if that is something you need, which I thought was really cool. +STEPHANIE: Yeah. I think I had mentioned performance was a really big theme. But I didn't realize how many levers there were to pull in terms of the way Ruby is implemented or the way that we are able to use Ruby that can improve performance. And it's really cool to see so many people being experts at all of those different components or aspects of making Ruby fast. [laughs] +MINA: Yeah. I think that part of the work that we do on Mission Control is monitoring performance and latency for our clients. And while I don't expect having to utilize some of the tools that I learned at RubyKaigi, I expect being aware of these things helping, I think, in the long run. +STEPHANIE: Yeah, absolutely. Joël and I have talked on the show about this idea of, like, push versus pull learning. So push, being you consume content that may not be relevant to you right now but maybe will be in the future. And you can remember, like, oh, I watched a talk on this, or I read something about this, and then you can go refer back to it. +As opposed to pull being, like, I have this thing that I don't understand, but I need to know right now, so I'm going to seek out resources about it. And I think we kind of landed on that both are important. But at Kaigi, especially, this was very much more push for me where there's a lot of things that I now have an awareness of. +But it's a little different, I think, from my experience at Ruby Central conferences where I will look at the schedule, and I will see talks that I'm like, oh, like, that sounds like it will be really relevant to something I'm working through on my client project or, like, some kind of challenging consulting situation. +And so the other thing that I noticed that was different was that a lot of the U.S. conferences are more, I think like business and team challenges-focused. So the talks kind of incorporate both a technical and socio-cultural aspect of the problems that they were solving. And I usually really like that because I find them very relatable to my day-to-day work. And that was something that was less common at Kaigi. +MINA: Also, that I've never been to a conference that is more on the academic side of things. So I don't know if maybe that is more aligned with what Kaigi feels like. +STEPHANIE: Yeah, that's true. I think there were a lot of talks from Ruby Committers who were just sharing, like, what they've been working on, like, what they've been thinking about in terms of future features for Ruby. And it was very much at the end of those talks, like, I'm open to feedback. Like, look out for this coming soon, or, like, help contribute to this effort. +And so it was interesting because it was less, like, here are some lessons learned or, like, here are some takeaways, or, like, here's how we did this. And more like, hey, I'm, you know, in the middle of figuring this out, and I'm sharing with you where I'm at right now. But I guess that's kind of the beauty of the open-source community is that you can put out a call for help and contributions. +MINA: Yeah, I think they call that peer review in the academic circles. +STEPHANIE: [laughs] That's fair. +MINA: [laughs] +STEPHANIE: Was there anything else that you really enjoyed about the conference? +MINA: I think that one of my favorite parts, and we've talked about this a little bit before, is after hours on the second day, we were able to connect with Emori House and have dinner with their members. Emori House is a group that supports female Kaigi attendees specifically. I think it's that they, as a group, rent out an establishment or a house or something, and they all stay together kind of to look out for each other as they attend this very, I think, male-dominated conference. +STEPHANIE: Yeah. I loved that dinner with folks from Emori House too. I think the really cool thing to me is that it's just community and action, you know, like, someone wanted to go to this conference and make it easier for other women to go to this conference and decided to get lodging together and do that work of community building. And that social aspect of conferences we hadn't really talked about yet, but it's something that I really enjoy. And it's, like, one of the main reasons that I go to conferences besides learning. +MINA: Yeah, I agree. At the Ruby Central conferences, one of my favorite parts is always the hallway track, where you randomly meet other attendees or connect with attendees that you already knew. And like I mentioned, this dinner with Emori House happened on the second night. And I think by midday second day; I was missing that a little bit. The setup for RubyKaigi, I noticed, does not make meeting people and organizing social events as easy as I had been used to, and part of that, I'm sure, is the language barrier. +But some places where I had met a lot of the people that I call conference friends for Ruby Central conferences had been at the lunch table. And Kaigi sets up in a way where they send you out with food vouchers for local restaurants, which I thought was really cool. But it doesn't make meeting people and organizing groups to go out together with people you don't already know a little more difficult. So meeting Emori House on the second night was kind of exactly what I had been missing at the moment. +STEPHANIE: Yeah, agreed. I also really thrive off of more smaller group interactions like organically, you know, bumping into people on the hallway track, ideally. +I also noticed that, at Kaigi, a lot of the sponsors end up hosting parties and meetups after the conference in the evenings. And so that was a very interesting social difference, I think, where the sponsors had a lot more engagement in that sense. You and I didn't end up going to any of those drink-ups, are what they're called. +But I think, similarly, if I were alone, I would be a little intimidated to go by myself. And it's kind of one of those things where it's like, oh, if I know someone, then we can go together. But, yeah, I certainly was also missing a bit of a more organic interaction with others. Though, I did meet a few Rubyists from just other places in East Asia, like Taiwan and China. And it was really cool to be in a place where people are thinking about Ruby differently than in the U.S. +I noticed in Japan; there's a lot more energy and enthusiasm about it. And, yeah, just folks who are really passionate about making Ruby a long-lasting language, something that, you know, people will continue to want to work with. And I thought that was very uplifting because it's kind of different from what the current industry in the U.S. is looking like in terms of programming languages for the jobs available. +MINA: It's really energizing, I think, to hear people be so enthusiastic about Ruby, especially, like you said, when people ask me what I do here, I say, "Developer," and they say, "Oh, what language do you work in?" I always have to be kind of like, "Have you heard of Ruby?" [laughs] And I think it helps that Ruby originated in Japan. They probably feel a little bit, like, not necessarily protective of it, but, like, this is our own, and we have to embrace it and make sure that it is future-facing, and going places, and it doesn't get stale. +STEPHANIE: Right. And I think that's really cool, especially to, you know, be around and, like, have conversations about, like you said, it's very energizing. +MINA: Yeah, like you mentioned, we did meet several other Rubyists from, like, East Asian countries, which doesn't necessarily always happen when you attend U.S.-based or even European-based conferences. I think that it is just not as...they have to travel from way farther away. So I think it's really cool to hear about RubyConf Taiwan coming up from one of the Rubyists from Taiwan, which is awesome. And it makes me kind of want to go. [laughs] +STEPHANIE: Yeah, I didn't know that that existed either. And just realizing that there are Rubyists all over the world who want to share the love of the language is really cool. And I am definitely going to keep a lookout for other opportunities. Now that I've checked off my first international conference, you know, I have a lot more confidence about [laughs] doing it again in the future, which actually kind of leads me to my next question is, do you have any advice for someone who wants to go to Kaigi or wants to go to an international conference? +MINA: Yeah, I think I have both. For international conferences in general, I thought that getting a buddy to go with you is really nice. Steph and I were able to...like, you and I were able to kind of support each other in different ways because I think we're both stressed [laughs] about international travel in different ways. So where you are stressed, I'm able to support, and where I'm stressed, you're able to support. So it was really nice and well-rounded experience because of that. +And for RubyKaigi specifically, I would recommend checking out some of the previous year's talks before you actually get there and take a look at the schedule when it comes out. Because, like we said, the idea of, I think, technical when people use that word to describe the content at RubyKaigi is different than what most people would expect. And kind of having an idea of what you're getting into by looking at previous videos, I think, will be really helpful and get you in the right mindset to absorb some of the information and knowledge. +STEPHANIE: Yeah, absolutely. I was just thinking about...I saw in Ruby Weekly this week Justin Searls had posted a very thorough live blogging of his experience at Kaigi that was much more in the weeds of, like, all of the content of the talks. And also had tips for how to brew coffee at a convenience store in Japan too. So I recommend checking that out if folks are curious about...especially this year before the videos of the talks are out. +I think one thing that I would do differently next time if I were to attend Kaigi or attend a conference that supports multiple languages...so there were talks in Japanese and English, and the ones in Japanese were live interpreted. And you and I had attended, like, one or two, but it ended up being a little tough to follow because the slides were a little bit out of sync with the interpretation. +I definitely would want to try again and invest a little more into attending talks in Japanese because I do think the content is still even different from what we might be seeing in English. And now that I know that it takes a lot of mental energy, just kind of perhaps loading up on those talks in the morning while I'm still, you know -- +MINA: [laughs] +STEPHANIE: Fresh-faced and coffee-driven. [laughs] Rather than saving it for the afternoon when it might be a little harder to really focus. +MINA: I think my mental energy has a very specific sweet spot because definitely, like, late in the afternoon would not be good for that. But also, like, very early in the morning would also not be very good for that because my coffee hasn't kicked in yet. +STEPHANIE: That's very real as well. +MINA: Do you think that there is anything that the conference could have done to have made your experience a little tiny bit better? Is there any support that you could have gotten from someone else, be it the conference, or WNB, or thoughtbot, or other people that you had gone with that could have enhanced this experience? +STEPHANIE: Hmm, that's an interesting question. I'm not really sure because I was experiencing so many new things -- +MINA: [laughs] +STEPHANIE: That that was kind of, like, what was top of mind for me was just getting around even just, like, looking at all the little sponsor booths because that was, like, novel for me to see, like, different companies that I've never heard of before that I think when I asked you about expectations earlier, like, I actually came in with not a lot of expectations because I really was just open to whatever it was going to be. +And now that I've experienced it once, I think that I have a little more of an idea of what works for me, what I like, what I don't like. And so I think it really comes down to it being quite a personal experience and how you like to attend conferences and so -- +MINA: For sure. +STEPHANIE: At the end of the day, yeah, like, definitely recommend just going if that opportunity is available to you and determining for yourself how you want that experience to be. +MINA: Certainly. I think just by being there you learn a lot about what you like in conferences and how we like to attend conferences. On a personal level, I'm also an organizer with Ruby Central with their scholarship committee. And that's somewhere where we take new Rubyists or first-time conference attendees and kind of lower the barrier for them to attend these conferences. And the important part I wanted to get to is setting them up with a mentor, somebody who has attended one of these conferences before that can kind of help them set goals and navigate. And I thought that someone like that would...at RubyKaigi, being both our first times, might be useful. +STEPHANIE: Yeah, absolutely. I think that's totally fair. One thing I do really like about the Ruby Central conferences is the social support. And I think you had mentioned that maybe that was the piece that was a little bit missing for you at this conference. +MINA: Yeah. I know that someone had asked early on, I think, like, the night before the conference officially kicked off, whether there is a Slack or Discord space for all conference attendees so that people can organize outings or meals. And that is definitely something that at least the Ruby Central conferences have, and I imagine other conferences do too, that was missing at Kaigi as well. +STEPHANIE: I'm wondering if you would go to Kaigi again and maybe be that mentor for someone else. +MINA: I think so. I think I had different feelings about it when we were just leaving the conference, kind of feeling like some of these things that I'm learning here or that I'm being made aware of rather at RubyKaigi will come up important in the future, but maybe not right away. So then I was kind of walking away with a sense of, like, oh, maybe this is a conference that is important, but I might deprioritize if other opportunities come up. +But then I started to kind of, like, jot down some reflections and retroing with myself on this experience. And I thought what you mentioned about this being the sort of, like, the push learning opportunity is really nice because I went in there not knowing what I don't know. And I think I came out of it at least being a little bit aware of lots of things that I don't know. +STEPHANIE: Yeah, yeah. Maybe, like, what I've come away with this conversation is that there is value in conferences being different from each other, like having more options. And, you know, one conference can't really be everything for everyone. And so, for you and I to have had such a very different experience at this particular conference than we normally do, that has value. It also can be something that you end up deciding, like, you're not into, and then you know. So, yeah, I guess that is kind of what I wanted to say about this very new experience. +MINA: Yeah, having new experiences, I think, is the important part. It's the same idea as you want to get a diverse group of people in the room together, and you come out with better ideas or better products or whatever because you have other points of view. And I think that attending conferences, even if not around the world, that are different from each other either in academia or just kind of, like, branching out of Ruby Central conferences, too, is a really valuable experience. Maybe conferences in other languages or language-agnostic conferences. +STEPHANIE: Yeah, well said. On that note, shall we wrap up? +MINA: Let's do it. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie is joined by very special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater.

+ +

Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure!

+ +
+ + + +

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 and today. I'm joined by a very special guest, fellow thoughtboter Mina Slater. Mina, would you like to introduce yourself to our audience?

+ +

MINA: Yeah. Hi, everyone. I am Mina. I am a Senior Developer on Mission Control, which is thoughtbot's DevOps and SRE team.

+ +

STEPHANIE: So, Mina, what's new in your world?

+ +

MINA: Well, I start marathon training this week. So I hope that this conversation goes well and lasts you for three months because you're probably not going to see or hear from me all summer.

+ +

STEPHANIE: Yes. That sounds...it sounds hard, to be honest, marathon training in the summer. When I was doing a bit more running, I always thought I would wake up earlier than I did and, you know, beat the heat, and then I never would, and that really, like, was kind of rough.

+ +

MINA: Yeah, actually, I was thinking about my plans for today. I didn't wake up early enough to run in the morning. And so I was calculating, like, okay, by midday, it's going to be too hot. So I'm going to have to wait until, like, 6:00 p.m. [laughs]

+ +

STEPHANIE: Yeah, yeah. Or, if you're like me, there's a very real chance that you just skip it altogether.

+ +

[laughter]

+ +

MINA: Well, I have a deadline, so... [laughs]

+ +

STEPHANIE: That's true. When is your marathon race?

+ +

MINA: This is actually the first year I'm doing two in a calendar year. So I'm doing Berlin in September. And then, three weeks after that, I'm going to run one in Detroit.

+ +

STEPHANIE: Nice. At least you'll be ready. You'll, like, have done it. I don't know; it kind of sounds maybe a bit more efficient that way. [laughs]

+ +

MINA: Theoretically. But, you know, ask me in October. I'll let you know how it goes.

+ +

STEPHANIE: That's true. You might have to come back on as a guest. [laughs]

+ +

MINA: Just to talk about how it went. [laughs]

+ +

STEPHANIE: Yeah, exactly.

+ +

MINA: So that's what's new with me. What's new in your world, Steph?

+ +

STEPHANIE: So, a while back on a previous Bike Shed episode, I talked about joining this client team and, in their daily team syncs, in addition to just sharing what we were up to and what we were working on, we would also answer the question what's something new to us. And that was a space for people to share things that they learned or even just, like, new things that they tried, like food, or activities, or whatnot. And I really enjoyed it as a way to get to know the team, especially when I was new to that client project.

+ +

And recently, someone on the team ended up creating a random question generator. So now the question for the daily sync rotates. And I've been having a lot of fun with that. Some of the ones that I like are, what made you laugh recently? What's currently playing on your Spotify or YouTube? No cheating.

+ +

MINA: [laughs]

+ +

STEPHANIE: And then, yesterday, we had what's for dinner? As the question. And I really liked that one because it actually prompted me to [chuckles] think about what I was going to do for dinner as opposed to waiting till 5:00 p.m. and then stressing because I'm already hungry but don't have a plan [chuckles] for how I'm going to feed myself yet. So it ended up being nice because I, you know, kind of was inspired by what other people mentioned about their dinner plans and got my stuff together.

+ +

MINA: That's shocking to me because we had just come off of two weeks of traveling together. And the one thing I learned about you is that you plan two meals ahead, but maybe that is travel stuff.

+ +

STEPHANIE: I think that is extremely correct. Because when you're traveling, you're really excited about all the different things that you want to eat wherever you are. And so, yeah, we were definitely...at least I was planning for us, like, two or three meals [laughs] in advance.

+ +

MINA: [laughs]

+ +

STEPHANIE: But, when I'm at home, it is much harder to, I don't know, like, be motivated. And it just becomes, like, a daily chore. [laughs] So it's not as exciting.

+ +

MINA: I think I'm the same way. I just had a whole bunch of family in town. And I was definitely planning dinner before we had breakfast because I'm like, oh, now I have to be responsible for all of these people.

+ +

STEPHANIE: Yeah. I just mentioned the questions because I've been really having fun with them, and I feel a lot more connected to the team. Like, I just get to know them more as people and the things they're interested in, and what they do in their free time. So, yeah, highly recommend adding a fun question to your daily syncs.

+ +

MINA: Yeah, we started doing that on Mission Control at our team sync meetings recently, too, where the first person...we actually have an order generator that somebody on the team wrote where it takes everyone's first and last name and scramble them and then randomizes the order. So you kind of have to figure out where in the queue you are and who's coming up next after you. But the first person that goes in the queue every day has to think of an icebreaker question.

+ +

STEPHANIE: That's kind of a lot of pressure [laughs] for a daily meeting, especially if you're having to unscramble names and then also come up with the icebreaker question. I personally would be very stressed [laughs] by that. But I also can see that it's...I also think it's very fun, especially for a small team like yours.

+ +

MINA: Yeah, yeah, just seven of us; we get to know really well what letters are in everyone's names. But I was first today, and I didn't have an icebreaker question ready. So I ended up just passing. So that's also an option.

+ +

STEPHANIE: That's fair. Maybe I'll link you to our random question generator, so you can find some inspiration. [laughs]

+ +

MINA: Yeah, it's a ChatGPT situation.

+ +

STEPHANIE: So you mentioned that you and I had just been traveling together for two weeks. And that's because Mina and I were at RubyKaigi in Matsumoto, Japan, earlier this May. And that's the topic of today's episode: Our Experience at RubyKaigi. And the really cool thing that I wanted to mention was that this was all possible because Mina and I were sponsored by WNB.rb, which is a global community of women and non-binary people working in Ruby. And I've mentioned this group on the show before, but I wanted to plug it again because I think that this was something really special that we got to do.

+ +

WNB runs a lot of initiatives, like, meetups and panels supporting people to speak at conferences and book clubs. And, you know, just many different programming events for supporting women and non-binary Rubyists in their career growth. And they are recently beginning a new initiative to sponsor folks to attend conferences. And Mina, you and I were the first people to get to try this out and go to an international conference. So that was really awesome. It was something that I don't think I would have done without the support from WNB.

+ +

MINA: And you almost didn't do. I think there was a lot of convincing [chuckles] that went on at the beginning to kind of get you to, like, actually consider coming with me.

+ +

STEPHANIE: It's true. It's true. I think you had DMed me, and you were, like, so, like, RubyKaigi, like, eyeball emoji. [laughs] I was, I think, hesitant because this was my first international conference. And so there was just a lot of, like, unknowns and uncertainty for me. And I think that's going to be part of what we talk about today. But is there anything that you want to say about WNB and how you felt about being offered this opportunity?

+ +

MINA: Yeah. When Emily and Jemma, the founders of WNB, approached us with this opportunity and this offer, I think I was...taken aback is not really quite the right words but, like, surprised and honored, really, I think it's a better word. Like, I was very honored that they thought of us and kind of took the initiative to come to us with this offer.

+ +

So I'm really grateful for this opportunity because going to RubyKaigi, I think it's always something that was on my radar. But I never thought that...well, not never. I thought that I had to go as a speaker, which would have been, like, a three to five-year goal. [laughs] But to be able to go as an attendee with the support of the group and also of thoughtbot was really nice.

+ +

STEPHANIE: Yeah, absolutely. That investment in our professional development was really meaningful to me. So, like you, I'm very grateful. And if any of our listeners are interested in donating to WNB.rb and contributing to the community's ability to send folks to conferences, you can do so at wnb-rb.dev/donate. Or, if you work for a company that might be interested in sponsoring, you can reach out to them at organizers@wnb-rb.dev.

+ +

MINA: I highly recommend doing that.

+ +

STEPHANIE: So, one of the questions I wanted to ask you about in terms of your RubyKaigi experience was, like, how it lined up with your expectations and if it was different or similar to what you were expecting.

+ +

MINA: Yeah, I have always heard that when people talk about RubyKaigi as a conference and about its contents, the word that everyone uses to describe it is technical. I have already had sort of a little bit of that expectation going in. But I think my interpretation of the word technical didn't really line up with how actually technical it was. And so that was one thing that was different than what I had expected.

+ +

STEPHANIE: Could you elaborate on what was surprising about the way that it was technical?

+ +

MINA: Yeah. I think that when I hear technical talks and having been to some Ruby and Rails confs here in the States, when I hear about technical talks, it's a lot more content about people using the technology, how they use Ruby to do certain things, or how they use Rails to achieve certain goals in their day-to-day work or side projects. But it seems at RubyKaigi; it is a lot more about the language itself, how Ruby does certain things, or how interpreters implement Ruby, the language itself. So I think it's much more lower-level than what I was expecting.

+ +

STEPHANIE: Yeah, I agree. I think you and I have gone to many of Ruby Central conferences in the U.S., like RubyConf and RailsConf. So that was kind of my comparison as well is that was, you know, the experience that I was more familiar with. And then, going into this conference, I was very surprised that the themes of the talks were, like you said, very focused on the language itself, especially performance, tooling, the history and future of Ruby, which I thought was pretty neat.

+ +

Ruby turns 30, I think, this year. And one thing that I noticed a lot was folks talking about using Ruby to reflect on itself and the possibilities of utilizing those capabilities to improve our experience as developers using the language.

+ +

MINA: Yeah. I think one of the things I was really fascinated by is...you had mentioned the performance. There were several talks about collecting how Ruby performs at certain levels. And I thought that that was quite interesting and things I had never thought about before, and I'm hoping to think about in the future. [laughs]

+ +

STEPHANIE: Yeah. One talk that I went to was Understanding the Ruby Global VM Lock by Ivo Anjo. And that was something that, you know, I had an awareness of that Ruby has this GVL and certain...I had, like, a very hand-wavy understanding about how, like, concurrency worked with Ruby because it hasn't been something that I've really needed to know too deeply in my day-to-day work. Like, I feel a little bit grateful not to have run into an issue where I had to, you know, dive deep into it because it was causing problems. [laughs]

+ +

But attending that talk was really cool because I liked that the speaker did give, like, an overview for folks who might be less familiar but then was able to get really deep in terms of, like, what he was doing workwise with improving his performance by being able to observe how the lock was being used in different threads and, like, where it might be able to be improved. And he shared some of his open-source projects that I'll link in the show notes.

+ +

But, yeah, that was just something that I was vaguely aware of and haven't yet, like, needed to know a lot about, but, you know, got to understand more by going to this conference. And I don't think I would have gotten that content otherwise.

+ +

MINA: Yeah, I agree. The talk that you are referencing is one of my favorite as well. I think, like you, kind of this vague idea of there's things going on under the hood in Ruby is always there, but to get a peek behind the curtain a little bit was very enlightening. I wrote down one of the things that he said about how highly optimized Ruby code can still be impacted and be slow if you don't optimize GVL. And he also shared, I think, some strategies for profiling that layer in your product, if that is something you need, which I thought was really cool.

+ +

STEPHANIE: Yeah. I think I had mentioned performance was a really big theme. But I didn't realize how many levers there were to pull in terms of the way Ruby is implemented or the way that we are able to use Ruby that can improve performance. And it's really cool to see so many people being experts at all of those different components or aspects of making Ruby fast. [laughs]

+ +

MINA: Yeah. I think that part of the work that we do on Mission Control is monitoring performance and latency for our clients. And while I don't expect having to utilize some of the tools that I learned at RubyKaigi, I expect being aware of these things helping, I think, in the long run.

+ +

STEPHANIE: Yeah, absolutely. Joël and I have talked on the show about this idea of, like, push versus pull learning. So push, being you consume content that may not be relevant to you right now but maybe will be in the future. And you can remember, like, oh, I watched a talk on this, or I read something about this, and then you can go refer back to it.

+ +

As opposed to pull being, like, I have this thing that I don't understand, but I need to know right now, so I'm going to seek out resources about it. And I think we kind of landed on that both are important. But at Kaigi, especially, this was very much more push for me where there's a lot of things that I now have an awareness of.

+ +

But it's a little different, I think, from my experience at Ruby Central conferences where I will look at the schedule, and I will see talks that I'm like, oh, like, that sounds like it will be really relevant to something I'm working through on my client project or, like, some kind of challenging consulting situation.

+ +

And so the other thing that I noticed that was different was that a lot of the U.S. conferences are more, I think like business and team challenges-focused. So the talks kind of incorporate both a technical and socio-cultural aspect of the problems that they were solving. And I usually really like that because I find them very relatable to my day-to-day work. And that was something that was less common at Kaigi.

+ +

MINA: Also, that I've never been to a conference that is more on the academic side of things. So I don't know if maybe that is more aligned with what Kaigi feels like.

+ +

STEPHANIE: Yeah, that's true. I think there were a lot of talks from Ruby Committers who were just sharing, like, what they've been working on, like, what they've been thinking about in terms of future features for Ruby. And it was very much at the end of those talks, like, I'm open to feedback. Like, look out for this coming soon, or, like, help contribute to this effort.

+ +

And so it was interesting because it was less, like, here are some lessons learned or, like, here are some takeaways, or, like, here's how we did this. And more like, hey, I'm, you know, in the middle of figuring this out, and I'm sharing with you where I'm at right now. But I guess that's kind of the beauty of the open-source community is that you can put out a call for help and contributions.

+ +

MINA: Yeah, I think they call that peer review in the academic circles.

+ +

STEPHANIE: [laughs] That's fair.

+ +

MINA: [laughs]

+ +

STEPHANIE: Was there anything else that you really enjoyed about the conference?

+ +

MINA: I think that one of my favorite parts, and we've talked about this a little bit before, is after hours on the second day, we were able to connect with Emori House and have dinner with their members. Emori House is a group that supports female Kaigi attendees specifically. I think it's that they, as a group, rent out an establishment or a house or something, and they all stay together kind of to look out for each other as they attend this very, I think, male-dominated conference.

+ +

STEPHANIE: Yeah. I loved that dinner with folks from Emori House too. I think the really cool thing to me is that it's just community and action, you know, like, someone wanted to go to this conference and make it easier for other women to go to this conference and decided to get lodging together and do that work of community building. And that social aspect of conferences we hadn't really talked about yet, but it's something that I really enjoy. And it's, like, one of the main reasons that I go to conferences besides learning.

+ +

MINA: Yeah, I agree. At the Ruby Central conferences, one of my favorite parts is always the hallway track, where you randomly meet other attendees or connect with attendees that you already knew. And like I mentioned, this dinner with Emori House happened on the second night. And I think by midday second day; I was missing that a little bit. The setup for RubyKaigi, I noticed, does not make meeting people and organizing social events as easy as I had been used to, and part of that, I'm sure, is the language barrier.

+ +

But some places where I had met a lot of the people that I call conference friends for Ruby Central conferences had been at the lunch table. And Kaigi sets up in a way where they send you out with food vouchers for local restaurants, which I thought was really cool. But it doesn't make meeting people and organizing groups to go out together with people you don't already know a little more difficult. So meeting Emori House on the second night was kind of exactly what I had been missing at the moment.

+ +

STEPHANIE: Yeah, agreed. I also really thrive off of more smaller group interactions like organically, you know, bumping into people on the hallway track, ideally.

+ +

I also noticed that, at Kaigi, a lot of the sponsors end up hosting parties and meetups after the conference in the evenings. And so that was a very interesting social difference, I think, where the sponsors had a lot more engagement in that sense. You and I didn't end up going to any of those drink-ups, are what they're called.

+ +

But I think, similarly, if I were alone, I would be a little intimidated to go by myself. And it's kind of one of those things where it's like, oh, if I know someone, then we can go together. But, yeah, I certainly was also missing a bit of a more organic interaction with others. Though, I did meet a few Rubyists from just other places in East Asia, like Taiwan and China. And it was really cool to be in a place where people are thinking about Ruby differently than in the U.S.

+ +

I noticed in Japan; there's a lot more energy and enthusiasm about it. And, yeah, just folks who are really passionate about making Ruby a long-lasting language, something that, you know, people will continue to want to work with. And I thought that was very uplifting because it's kind of different from what the current industry in the U.S. is looking like in terms of programming languages for the jobs available.

+ +

MINA: It's really energizing, I think, to hear people be so enthusiastic about Ruby, especially, like you said, when people ask me what I do here, I say, "Developer," and they say, "Oh, what language do you work in?" I always have to be kind of like, "Have you heard of Ruby?" [laughs] And I think it helps that Ruby originated in Japan. They probably feel a little bit, like, not necessarily protective of it, but, like, this is our own, and we have to embrace it and make sure that it is future-facing, and going places, and it doesn't get stale.

+ +

STEPHANIE: Right. And I think that's really cool, especially to, you know, be around and, like, have conversations about, like you said, it's very energizing.

+ +

MINA: Yeah, like you mentioned, we did meet several other Rubyists from, like, East Asian countries, which doesn't necessarily always happen when you attend U.S.-based or even European-based conferences. I think that it is just not as...they have to travel from way farther away. So I think it's really cool to hear about RubyConf Taiwan coming up from one of the Rubyists from Taiwan, which is awesome. And it makes me kind of want to go. [laughs]

+ +

STEPHANIE: Yeah, I didn't know that that existed either. And just realizing that there are Rubyists all over the world who want to share the love of the language is really cool. And I am definitely going to keep a lookout for other opportunities. Now that I've checked off my first international conference, you know, I have a lot more confidence about [laughs] doing it again in the future, which actually kind of leads me to my next question is, do you have any advice for someone who wants to go to Kaigi or wants to go to an international conference?

+ +

MINA: Yeah, I think I have both. For international conferences in general, I thought that getting a buddy to go with you is really nice. Steph and I were able to...like, you and I were able to kind of support each other in different ways because I think we're both stressed [laughs] about international travel in different ways. So where you are stressed, I'm able to support, and where I'm stressed, you're able to support. So it was really nice and well-rounded experience because of that.

+ +

And for RubyKaigi specifically, I would recommend checking out some of the previous year's talks before you actually get there and take a look at the schedule when it comes out. Because, like we said, the idea of, I think, technical when people use that word to describe the content at RubyKaigi is different than what most people would expect. And kind of having an idea of what you're getting into by looking at previous videos, I think, will be really helpful and get you in the right mindset to absorb some of the information and knowledge.

+ +

STEPHANIE: Yeah, absolutely. I was just thinking about...I saw in Ruby Weekly this week Justin Searls had posted a very thorough live blogging of his experience at Kaigi that was much more in the weeds of, like, all of the content of the talks. And also had tips for how to brew coffee at a convenience store in Japan too. So I recommend checking that out if folks are curious about...especially this year before the videos of the talks are out.

+ +

I think one thing that I would do differently next time if I were to attend Kaigi or attend a conference that supports multiple languages...so there were talks in Japanese and English, and the ones in Japanese were live interpreted. And you and I had attended, like, one or two, but it ended up being a little tough to follow because the slides were a little bit out of sync with the interpretation.

+ +

I definitely would want to try again and invest a little more into attending talks in Japanese because I do think the content is still even different from what we might be seeing in English. And now that I know that it takes a lot of mental energy, just kind of perhaps loading up on those talks in the morning while I'm still, you know --

+ +

MINA: [laughs]

+ +

STEPHANIE: Fresh-faced and coffee-driven. [laughs] Rather than saving it for the afternoon when it might be a little harder to really focus.

+ +

MINA: I think my mental energy has a very specific sweet spot because definitely, like, late in the afternoon would not be good for that. But also, like, very early in the morning would also not be very good for that because my coffee hasn't kicked in yet.

+ +

STEPHANIE: That's very real as well.

+ +

MINA: Do you think that there is anything that the conference could have done to have made your experience a little tiny bit better? Is there any support that you could have gotten from someone else, be it the conference, or WNB, or thoughtbot, or other people that you had gone with that could have enhanced this experience?

+ +

STEPHANIE: Hmm, that's an interesting question. I'm not really sure because I was experiencing so many new things --

+ +

MINA: [laughs]

+ +

STEPHANIE: That that was kind of, like, what was top of mind for me was just getting around even just, like, looking at all the little sponsor booths because that was, like, novel for me to see, like, different companies that I've never heard of before that I think when I asked you about expectations earlier, like, I actually came in with not a lot of expectations because I really was just open to whatever it was going to be.

+ +

And now that I've experienced it once, I think that I have a little more of an idea of what works for me, what I like, what I don't like. And so I think it really comes down to it being quite a personal experience and how you like to attend conferences and so --

+ +

MINA: For sure.

+ +

STEPHANIE: At the end of the day, yeah, like, definitely recommend just going if that opportunity is available to you and determining for yourself how you want that experience to be.

+ +

MINA: Certainly. I think just by being there you learn a lot about what you like in conferences and how we like to attend conferences. On a personal level, I'm also an organizer with Ruby Central with their scholarship committee. And that's somewhere where we take new Rubyists or first-time conference attendees and kind of lower the barrier for them to attend these conferences. And the important part I wanted to get to is setting them up with a mentor, somebody who has attended one of these conferences before that can kind of help them set goals and navigate. And I thought that someone like that would...at RubyKaigi, being both our first times, might be useful.

+ +

STEPHANIE: Yeah, absolutely. I think that's totally fair. One thing I do really like about the Ruby Central conferences is the social support. And I think you had mentioned that maybe that was the piece that was a little bit missing for you at this conference.

+ +

MINA: Yeah. I know that someone had asked early on, I think, like, the night before the conference officially kicked off, whether there is a Slack or Discord space for all conference attendees so that people can organize outings or meals. And that is definitely something that at least the Ruby Central conferences have, and I imagine other conferences do too, that was missing at Kaigi as well.

+ +

STEPHANIE: I'm wondering if you would go to Kaigi again and maybe be that mentor for someone else.

+ +

MINA: I think so. I think I had different feelings about it when we were just leaving the conference, kind of feeling like some of these things that I'm learning here or that I'm being made aware of rather at RubyKaigi will come up important in the future, but maybe not right away. So then I was kind of walking away with a sense of, like, oh, maybe this is a conference that is important, but I might deprioritize if other opportunities come up.

+ +

But then I started to kind of, like, jot down some reflections and retroing with myself on this experience. And I thought what you mentioned about this being the sort of, like, the push learning opportunity is really nice because I went in there not knowing what I don't know. And I think I came out of it at least being a little bit aware of lots of things that I don't know.

+ +

STEPHANIE: Yeah, yeah. Maybe, like, what I've come away with this conversation is that there is value in conferences being different from each other, like having more options. And, you know, one conference can't really be everything for everyone. And so, for you and I to have had such a very different experience at this particular conference than we normally do, that has value. It also can be something that you end up deciding, like, you're not into, and then you know. So, yeah, I guess that is kind of what I wanted to say about this very new experience.

+ +

MINA: Yeah, having new experiences, I think, is the important part. It's the same idea as you want to get a diverse group of people in the room together, and you come out with better ideas or better products or whatever because you have other points of view. And I think that attending conferences, even if not around the world, that are different from each other either in academia or just kind of, like, branching out of Ruby Central conferences, too, is a really valuable experience. Maybe conferences in other languages or language-agnostic conferences.

+ +

STEPHANIE: Yeah, well said. On that note, shall we wrap up?

+ +

MINA: Let's do it.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + + Stephanie is joined by very special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater.

+ +

Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure!

+ +
+ + + +

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 and today. I'm joined by a very special guest, fellow thoughtboter Mina Slater. Mina, would you like to introduce yourself to our audience?

+ +

MINA: Yeah. Hi, everyone. I am Mina. I am a Senior Developer on Mission Control, which is thoughtbot's DevOps and SRE team.

+ +

STEPHANIE: So, Mina, what's new in your world?

+ +

MINA: Well, I start marathon training this week. So I hope that this conversation goes well and lasts you for three months because you're probably not going to see or hear from me all summer.

+ +

STEPHANIE: Yes. That sounds...it sounds hard, to be honest, marathon training in the summer. When I was doing a bit more running, I always thought I would wake up earlier than I did and, you know, beat the heat, and then I never would, and that really, like, was kind of rough.

+ +

MINA: Yeah, actually, I was thinking about my plans for today. I didn't wake up early enough to run in the morning. And so I was calculating, like, okay, by midday, it's going to be too hot. So I'm going to have to wait until, like, 6:00 p.m. [laughs]

+ +

STEPHANIE: Yeah, yeah. Or, if you're like me, there's a very real chance that you just skip it altogether.

+ +

[laughter]

+ +

MINA: Well, I have a deadline, so... [laughs]

+ +

STEPHANIE: That's true. When is your marathon race?

+ +

MINA: This is actually the first year I'm doing two in a calendar year. So I'm doing Berlin in September. And then, three weeks after that, I'm going to run one in Detroit.

+ +

STEPHANIE: Nice. At least you'll be ready. You'll, like, have done it. I don't know; it kind of sounds maybe a bit more efficient that way. [laughs]

+ +

MINA: Theoretically. But, you know, ask me in October. I'll let you know how it goes.

+ +

STEPHANIE: That's true. You might have to come back on as a guest. [laughs]

+ +

MINA: Just to talk about how it went. [laughs]

+ +

STEPHANIE: Yeah, exactly.

+ +

MINA: So that's what's new with me. What's new in your world, Steph?

+ +

STEPHANIE: So, a while back on a previous Bike Shed episode, I talked about joining this client team and, in their daily team syncs, in addition to just sharing what we were up to and what we were working on, we would also answer the question what's something new to us. And that was a space for people to share things that they learned or even just, like, new things that they tried, like food, or activities, or whatnot. And I really enjoyed it as a way to get to know the team, especially when I was new to that client project.

+ +

And recently, someone on the team ended up creating a random question generator. So now the question for the daily sync rotates. And I've been having a lot of fun with that. Some of the ones that I like are, what made you laugh recently? What's currently playing on your Spotify or YouTube? No cheating.

+ +

MINA: [laughs]

+ +

STEPHANIE: And then, yesterday, we had what's for dinner? As the question. And I really liked that one because it actually prompted me to [chuckles] think about what I was going to do for dinner as opposed to waiting till 5:00 p.m. and then stressing because I'm already hungry but don't have a plan [chuckles] for how I'm going to feed myself yet. So it ended up being nice because I, you know, kind of was inspired by what other people mentioned about their dinner plans and got my stuff together.

+ +

MINA: That's shocking to me because we had just come off of two weeks of traveling together. And the one thing I learned about you is that you plan two meals ahead, but maybe that is travel stuff.

+ +

STEPHANIE: I think that is extremely correct. Because when you're traveling, you're really excited about all the different things that you want to eat wherever you are. And so, yeah, we were definitely...at least I was planning for us, like, two or three meals [laughs] in advance.

+ +

MINA: [laughs]

+ +

STEPHANIE: But, when I'm at home, it is much harder to, I don't know, like, be motivated. And it just becomes, like, a daily chore. [laughs] So it's not as exciting.

+ +

MINA: I think I'm the same way. I just had a whole bunch of family in town. And I was definitely planning dinner before we had breakfast because I'm like, oh, now I have to be responsible for all of these people.

+ +

STEPHANIE: Yeah. I just mentioned the questions because I've been really having fun with them, and I feel a lot more connected to the team. Like, I just get to know them more as people and the things they're interested in, and what they do in their free time. So, yeah, highly recommend adding a fun question to your daily syncs.

+ +

MINA: Yeah, we started doing that on Mission Control at our team sync meetings recently, too, where the first person...we actually have an order generator that somebody on the team wrote where it takes everyone's first and last name and scramble them and then randomizes the order. So you kind of have to figure out where in the queue you are and who's coming up next after you. But the first person that goes in the queue every day has to think of an icebreaker question.

+ +

STEPHANIE: That's kind of a lot of pressure [laughs] for a daily meeting, especially if you're having to unscramble names and then also come up with the icebreaker question. I personally would be very stressed [laughs] by that. But I also can see that it's...I also think it's very fun, especially for a small team like yours.

+ +

MINA: Yeah, yeah, just seven of us; we get to know really well what letters are in everyone's names. But I was first today, and I didn't have an icebreaker question ready. So I ended up just passing. So that's also an option.

+ +

STEPHANIE: That's fair. Maybe I'll link you to our random question generator, so you can find some inspiration. [laughs]

+ +

MINA: Yeah, it's a ChatGPT situation.

+ +

STEPHANIE: So you mentioned that you and I had just been traveling together for two weeks. And that's because Mina and I were at RubyKaigi in Matsumoto, Japan, earlier this May. And that's the topic of today's episode: Our Experience at RubyKaigi. And the really cool thing that I wanted to mention was that this was all possible because Mina and I were sponsored by WNB.rb, which is a global community of women and non-binary people working in Ruby. And I've mentioned this group on the show before, but I wanted to plug it again because I think that this was something really special that we got to do.

+ +

WNB runs a lot of initiatives, like, meetups and panels supporting people to speak at conferences and book clubs. And, you know, just many different programming events for supporting women and non-binary Rubyists in their career growth. And they are recently beginning a new initiative to sponsor folks to attend conferences. And Mina, you and I were the first people to get to try this out and go to an international conference. So that was really awesome. It was something that I don't think I would have done without the support from WNB.

+ +

MINA: And you almost didn't do. I think there was a lot of convincing [chuckles] that went on at the beginning to kind of get you to, like, actually consider coming with me.

+ +

STEPHANIE: It's true. It's true. I think you had DMed me, and you were, like, so, like, RubyKaigi, like, eyeball emoji. [laughs] I was, I think, hesitant because this was my first international conference. And so there was just a lot of, like, unknowns and uncertainty for me. And I think that's going to be part of what we talk about today. But is there anything that you want to say about WNB and how you felt about being offered this opportunity?

+ +

MINA: Yeah. When Emily and Jemma, the founders of WNB, approached us with this opportunity and this offer, I think I was...taken aback is not really quite the right words but, like, surprised and honored, really, I think it's a better word. Like, I was very honored that they thought of us and kind of took the initiative to come to us with this offer.

+ +

So I'm really grateful for this opportunity because going to RubyKaigi, I think it's always something that was on my radar. But I never thought that...well, not never. I thought that I had to go as a speaker, which would have been, like, a three to five-year goal. [laughs] But to be able to go as an attendee with the support of the group and also of thoughtbot was really nice.

+ +

STEPHANIE: Yeah, absolutely. That investment in our professional development was really meaningful to me. So, like you, I'm very grateful. And if any of our listeners are interested in donating to WNB.rb and contributing to the community's ability to send folks to conferences, you can do so at wnb-rb.dev/donate. Or, if you work for a company that might be interested in sponsoring, you can reach out to them at organizers@wnb-rb.dev.

+ +

MINA: I highly recommend doing that.

+ +

STEPHANIE: So, one of the questions I wanted to ask you about in terms of your RubyKaigi experience was, like, how it lined up with your expectations and if it was different or similar to what you were expecting.

+ +

MINA: Yeah, I have always heard that when people talk about RubyKaigi as a conference and about its contents, the word that everyone uses to describe it is technical. I have already had sort of a little bit of that expectation going in. But I think my interpretation of the word technical didn't really line up with how actually technical it was. And so that was one thing that was different than what I had expected.

+ +

STEPHANIE: Could you elaborate on what was surprising about the way that it was technical?

+ +

MINA: Yeah. I think that when I hear technical talks and having been to some Ruby and Rails confs here in the States, when I hear about technical talks, it's a lot more content about people using the technology, how they use Ruby to do certain things, or how they use Rails to achieve certain goals in their day-to-day work or side projects. But it seems at RubyKaigi; it is a lot more about the language itself, how Ruby does certain things, or how interpreters implement Ruby, the language itself. So I think it's much more lower-level than what I was expecting.

+ +

STEPHANIE: Yeah, I agree. I think you and I have gone to many of Ruby Central conferences in the U.S., like RubyConf and RailsConf. So that was kind of my comparison as well is that was, you know, the experience that I was more familiar with. And then, going into this conference, I was very surprised that the themes of the talks were, like you said, very focused on the language itself, especially performance, tooling, the history and future of Ruby, which I thought was pretty neat.

+ +

Ruby turns 30, I think, this year. And one thing that I noticed a lot was folks talking about using Ruby to reflect on itself and the possibilities of utilizing those capabilities to improve our experience as developers using the language.

+ +

MINA: Yeah. I think one of the things I was really fascinated by is...you had mentioned the performance. There were several talks about collecting how Ruby performs at certain levels. And I thought that that was quite interesting and things I had never thought about before, and I'm hoping to think about in the future. [laughs]

+ +

STEPHANIE: Yeah. One talk that I went to was Understanding the Ruby Global VM Lock by Ivo Anjo. And that was something that, you know, I had an awareness of that Ruby has this GVL and certain...I had, like, a very hand-wavy understanding about how, like, concurrency worked with Ruby because it hasn't been something that I've really needed to know too deeply in my day-to-day work. Like, I feel a little bit grateful not to have run into an issue where I had to, you know, dive deep into it because it was causing problems. [laughs]

+ +

But attending that talk was really cool because I liked that the speaker did give, like, an overview for folks who might be less familiar but then was able to get really deep in terms of, like, what he was doing workwise with improving his performance by being able to observe how the lock was being used in different threads and, like, where it might be able to be improved. And he shared some of his open-source projects that I'll link in the show notes.

+ +

But, yeah, that was just something that I was vaguely aware of and haven't yet, like, needed to know a lot about, but, you know, got to understand more by going to this conference. And I don't think I would have gotten that content otherwise.

+ +

MINA: Yeah, I agree. The talk that you are referencing is one of my favorite as well. I think, like you, kind of this vague idea of there's things going on under the hood in Ruby is always there, but to get a peek behind the curtain a little bit was very enlightening. I wrote down one of the things that he said about how highly optimized Ruby code can still be impacted and be slow if you don't optimize GVL. And he also shared, I think, some strategies for profiling that layer in your product, if that is something you need, which I thought was really cool.

+ +

STEPHANIE: Yeah. I think I had mentioned performance was a really big theme. But I didn't realize how many levers there were to pull in terms of the way Ruby is implemented or the way that we are able to use Ruby that can improve performance. And it's really cool to see so many people being experts at all of those different components or aspects of making Ruby fast. [laughs]

+ +

MINA: Yeah. I think that part of the work that we do on Mission Control is monitoring performance and latency for our clients. And while I don't expect having to utilize some of the tools that I learned at RubyKaigi, I expect being aware of these things helping, I think, in the long run.

+ +

STEPHANIE: Yeah, absolutely. Joël and I have talked on the show about this idea of, like, push versus pull learning. So push, being you consume content that may not be relevant to you right now but maybe will be in the future. And you can remember, like, oh, I watched a talk on this, or I read something about this, and then you can go refer back to it.

+ +

As opposed to pull being, like, I have this thing that I don't understand, but I need to know right now, so I'm going to seek out resources about it. And I think we kind of landed on that both are important. But at Kaigi, especially, this was very much more push for me where there's a lot of things that I now have an awareness of.

+ +

But it's a little different, I think, from my experience at Ruby Central conferences where I will look at the schedule, and I will see talks that I'm like, oh, like, that sounds like it will be really relevant to something I'm working through on my client project or, like, some kind of challenging consulting situation.

+ +

And so the other thing that I noticed that was different was that a lot of the U.S. conferences are more, I think like business and team challenges-focused. So the talks kind of incorporate both a technical and socio-cultural aspect of the problems that they were solving. And I usually really like that because I find them very relatable to my day-to-day work. And that was something that was less common at Kaigi.

+ +

MINA: Also, that I've never been to a conference that is more on the academic side of things. So I don't know if maybe that is more aligned with what Kaigi feels like.

+ +

STEPHANIE: Yeah, that's true. I think there were a lot of talks from Ruby Committers who were just sharing, like, what they've been working on, like, what they've been thinking about in terms of future features for Ruby. And it was very much at the end of those talks, like, I'm open to feedback. Like, look out for this coming soon, or, like, help contribute to this effort.

+ +

And so it was interesting because it was less, like, here are some lessons learned or, like, here are some takeaways, or, like, here's how we did this. And more like, hey, I'm, you know, in the middle of figuring this out, and I'm sharing with you where I'm at right now. But I guess that's kind of the beauty of the open-source community is that you can put out a call for help and contributions.

+ +

MINA: Yeah, I think they call that peer review in the academic circles.

+ +

STEPHANIE: [laughs] That's fair.

+ +

MINA: [laughs]

+ +

STEPHANIE: Was there anything else that you really enjoyed about the conference?

+ +

MINA: I think that one of my favorite parts, and we've talked about this a little bit before, is after hours on the second day, we were able to connect with Emori House and have dinner with their members. Emori House is a group that supports female Kaigi attendees specifically. I think it's that they, as a group, rent out an establishment or a house or something, and they all stay together kind of to look out for each other as they attend this very, I think, male-dominated conference.

+ +

STEPHANIE: Yeah. I loved that dinner with folks from Emori House too. I think the really cool thing to me is that it's just community and action, you know, like, someone wanted to go to this conference and make it easier for other women to go to this conference and decided to get lodging together and do that work of community building. And that social aspect of conferences we hadn't really talked about yet, but it's something that I really enjoy. And it's, like, one of the main reasons that I go to conferences besides learning.

+ +

MINA: Yeah, I agree. At the Ruby Central conferences, one of my favorite parts is always the hallway track, where you randomly meet other attendees or connect with attendees that you already knew. And like I mentioned, this dinner with Emori House happened on the second night. And I think by midday second day; I was missing that a little bit. The setup for RubyKaigi, I noticed, does not make meeting people and organizing social events as easy as I had been used to, and part of that, I'm sure, is the language barrier.

+ +

But some places where I had met a lot of the people that I call conference friends for Ruby Central conferences had been at the lunch table. And Kaigi sets up in a way where they send you out with food vouchers for local restaurants, which I thought was really cool. But it doesn't make meeting people and organizing groups to go out together with people you don't already know a little more difficult. So meeting Emori House on the second night was kind of exactly what I had been missing at the moment.

+ +

STEPHANIE: Yeah, agreed. I also really thrive off of more smaller group interactions like organically, you know, bumping into people on the hallway track, ideally.

+ +

I also noticed that, at Kaigi, a lot of the sponsors end up hosting parties and meetups after the conference in the evenings. And so that was a very interesting social difference, I think, where the sponsors had a lot more engagement in that sense. You and I didn't end up going to any of those drink-ups, are what they're called.

+ +

But I think, similarly, if I were alone, I would be a little intimidated to go by myself. And it's kind of one of those things where it's like, oh, if I know someone, then we can go together. But, yeah, I certainly was also missing a bit of a more organic interaction with others. Though, I did meet a few Rubyists from just other places in East Asia, like Taiwan and China. And it was really cool to be in a place where people are thinking about Ruby differently than in the U.S.

+ +

I noticed in Japan; there's a lot more energy and enthusiasm about it. And, yeah, just folks who are really passionate about making Ruby a long-lasting language, something that, you know, people will continue to want to work with. And I thought that was very uplifting because it's kind of different from what the current industry in the U.S. is looking like in terms of programming languages for the jobs available.

+ +

MINA: It's really energizing, I think, to hear people be so enthusiastic about Ruby, especially, like you said, when people ask me what I do here, I say, "Developer," and they say, "Oh, what language do you work in?" I always have to be kind of like, "Have you heard of Ruby?" [laughs] And I think it helps that Ruby originated in Japan. They probably feel a little bit, like, not necessarily protective of it, but, like, this is our own, and we have to embrace it and make sure that it is future-facing, and going places, and it doesn't get stale.

+ +

STEPHANIE: Right. And I think that's really cool, especially to, you know, be around and, like, have conversations about, like you said, it's very energizing.

+ +

MINA: Yeah, like you mentioned, we did meet several other Rubyists from, like, East Asian countries, which doesn't necessarily always happen when you attend U.S.-based or even European-based conferences. I think that it is just not as...they have to travel from way farther away. So I think it's really cool to hear about RubyConf Taiwan coming up from one of the Rubyists from Taiwan, which is awesome. And it makes me kind of want to go. [laughs]

+ +

STEPHANIE: Yeah, I didn't know that that existed either. And just realizing that there are Rubyists all over the world who want to share the love of the language is really cool. And I am definitely going to keep a lookout for other opportunities. Now that I've checked off my first international conference, you know, I have a lot more confidence about [laughs] doing it again in the future, which actually kind of leads me to my next question is, do you have any advice for someone who wants to go to Kaigi or wants to go to an international conference?

+ +

MINA: Yeah, I think I have both. For international conferences in general, I thought that getting a buddy to go with you is really nice. Steph and I were able to...like, you and I were able to kind of support each other in different ways because I think we're both stressed [laughs] about international travel in different ways. So where you are stressed, I'm able to support, and where I'm stressed, you're able to support. So it was really nice and well-rounded experience because of that.

+ +

And for RubyKaigi specifically, I would recommend checking out some of the previous year's talks before you actually get there and take a look at the schedule when it comes out. Because, like we said, the idea of, I think, technical when people use that word to describe the content at RubyKaigi is different than what most people would expect. And kind of having an idea of what you're getting into by looking at previous videos, I think, will be really helpful and get you in the right mindset to absorb some of the information and knowledge.

+ +

STEPHANIE: Yeah, absolutely. I was just thinking about...I saw in Ruby Weekly this week Justin Searls had posted a very thorough live blogging of his experience at Kaigi that was much more in the weeds of, like, all of the content of the talks. And also had tips for how to brew coffee at a convenience store in Japan too. So I recommend checking that out if folks are curious about...especially this year before the videos of the talks are out.

+ +

I think one thing that I would do differently next time if I were to attend Kaigi or attend a conference that supports multiple languages...so there were talks in Japanese and English, and the ones in Japanese were live interpreted. And you and I had attended, like, one or two, but it ended up being a little tough to follow because the slides were a little bit out of sync with the interpretation.

+ +

I definitely would want to try again and invest a little more into attending talks in Japanese because I do think the content is still even different from what we might be seeing in English. And now that I know that it takes a lot of mental energy, just kind of perhaps loading up on those talks in the morning while I'm still, you know --

+ +

MINA: [laughs]

+ +

STEPHANIE: Fresh-faced and coffee-driven. [laughs] Rather than saving it for the afternoon when it might be a little harder to really focus.

+ +

MINA: I think my mental energy has a very specific sweet spot because definitely, like, late in the afternoon would not be good for that. But also, like, very early in the morning would also not be very good for that because my coffee hasn't kicked in yet.

+ +

STEPHANIE: That's very real as well.

+ +

MINA: Do you think that there is anything that the conference could have done to have made your experience a little tiny bit better? Is there any support that you could have gotten from someone else, be it the conference, or WNB, or thoughtbot, or other people that you had gone with that could have enhanced this experience?

+ +

STEPHANIE: Hmm, that's an interesting question. I'm not really sure because I was experiencing so many new things --

+ +

MINA: [laughs]

+ +

STEPHANIE: That that was kind of, like, what was top of mind for me was just getting around even just, like, looking at all the little sponsor booths because that was, like, novel for me to see, like, different companies that I've never heard of before that I think when I asked you about expectations earlier, like, I actually came in with not a lot of expectations because I really was just open to whatever it was going to be.

+ +

And now that I've experienced it once, I think that I have a little more of an idea of what works for me, what I like, what I don't like. And so I think it really comes down to it being quite a personal experience and how you like to attend conferences and so --

+ +

MINA: For sure.

+ +

STEPHANIE: At the end of the day, yeah, like, definitely recommend just going if that opportunity is available to you and determining for yourself how you want that experience to be.

+ +

MINA: Certainly. I think just by being there you learn a lot about what you like in conferences and how we like to attend conferences. On a personal level, I'm also an organizer with Ruby Central with their scholarship committee. And that's somewhere where we take new Rubyists or first-time conference attendees and kind of lower the barrier for them to attend these conferences. And the important part I wanted to get to is setting them up with a mentor, somebody who has attended one of these conferences before that can kind of help them set goals and navigate. And I thought that someone like that would...at RubyKaigi, being both our first times, might be useful.

+ +

STEPHANIE: Yeah, absolutely. I think that's totally fair. One thing I do really like about the Ruby Central conferences is the social support. And I think you had mentioned that maybe that was the piece that was a little bit missing for you at this conference.

+ +

MINA: Yeah. I know that someone had asked early on, I think, like, the night before the conference officially kicked off, whether there is a Slack or Discord space for all conference attendees so that people can organize outings or meals. And that is definitely something that at least the Ruby Central conferences have, and I imagine other conferences do too, that was missing at Kaigi as well.

+ +

STEPHANIE: I'm wondering if you would go to Kaigi again and maybe be that mentor for someone else.

+ +

MINA: I think so. I think I had different feelings about it when we were just leaving the conference, kind of feeling like some of these things that I'm learning here or that I'm being made aware of rather at RubyKaigi will come up important in the future, but maybe not right away. So then I was kind of walking away with a sense of, like, oh, maybe this is a conference that is important, but I might deprioritize if other opportunities come up.

+ +

But then I started to kind of, like, jot down some reflections and retroing with myself on this experience. And I thought what you mentioned about this being the sort of, like, the push learning opportunity is really nice because I went in there not knowing what I don't know. And I think I came out of it at least being a little bit aware of lots of things that I don't know.

+ +

STEPHANIE: Yeah, yeah. Maybe, like, what I've come away with this conversation is that there is value in conferences being different from each other, like having more options. And, you know, one conference can't really be everything for everyone. And so, for you and I to have had such a very different experience at this particular conference than we normally do, that has value. It also can be something that you end up deciding, like, you're not into, and then you know. So, yeah, I guess that is kind of what I wanted to say about this very new experience.

+ +

MINA: Yeah, having new experiences, I think, is the important part. It's the same idea as you want to get a diverse group of people in the room together, and you come out with better ideas or better products or whatever because you have other points of view. And I think that attending conferences, even if not around the world, that are different from each other either in academia or just kind of, like, branching out of Ruby Central conferences, too, is a really valuable experience. Maybe conferences in other languages or language-agnostic conferences.

+ +

STEPHANIE: Yeah, well said. On that note, shall we wrap up?

+ +

MINA: Let's do it.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GaKSE4Mw + + ]]> + + Stephanie Minn + + + 386: Value Objects Revisited: The `Tally` Edition + https://bikeshed.thoughtbot.com/386 + 77a39a18-d0e2-45b0-a344-e60aef0deabb + Wed, 31 May 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + If you're in the market for bicycle shorts, Joël's got you. Stephanie just returned from RubyKaigi in Japan and shares details of her trip. + +Recently at thoughtbot, there have been conversations around an interesting data modeling exercise. Joël and Stephanie discuss the following: + +* Value Objects vs. Hashes +* Doing Math on Compound Numbers +* Monoids and Folding +* Naming Concepts in Code + 41:08 + no + + + If you're in the market for bicycle shorts, Joël's got you. Stephanie just returned from RubyKaigi in Japan and shares details of her trip. +Recently at thoughtbot, there have been conversations around an interesting data modeling exercise. Joël and Stephanie discuss the following: +Value Objects vs. Hashes +Doing Math on Compound Numbers +Monoids and Folding +Naming Concepts in Code +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Ruby Kaigi (https://rubykaigi.org/2023/) +Google Translate Lens (https://lens.google/) +Video on city parks (https://www.youtube.com/watch?v=qnyikrFlGdU) +Enumerable#tally (https://ruby-doc.org/3.2.2/Enumerable.html#method-i-tally) +Hash#merge (https://ruby-doc.org/3.2.2/Hash.html#method-i-merge) +Monoids (https://blog.ploeh.dk/2017/10/06/monoids/) +Enumerable#all? (https://ruby-doc.org/3.2.2/Enumerable.html#method-i-all-3F) +Value of specialized vocabulary (https://www.bikeshed.fm/356) +Gist with Joël’s code solution (https://gist.github.com/JoelQ/3056a0a6e8b5488faa5caeef630cd702) +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 little bit of what we've learned along the way. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I've made an unusual purchase this week. I went out and bought a pair of bicycle shorts. And, for those who are not aware, these are special shorts that have padding built into them. Typically, they're, like, skin-tight, but I got, I guess, what are called mountain biking shorts. So, they kind of look more like the cut of a normal short. But they've got this, like, built-in padding for biking. +STEPHANIE: So. Just to confirm, you did get these shorts for biking purposes, right? +JOËL: Yes. I purchased these shorts for biking purposes. +STEPHANIE: Okay. [laughs] +JOËL: And I got these because I was talking to a friend about this and mentioning that this was, like, probably the most ambitious cycling thing I've ever done in my life. And they recommended if you have not done bike shorts, you really should get them. They make a big difference. +STEPHANIE: Wow. Okay, I have two thoughts here. First of all, you prefaced this saying that this was an unusual purchase. So I thought maybe that you bought these bike shorts for some other purpose. [laughs] But I am excited to talk about this because I've also been curious about trying bike shorts. +I bike a lot in Chicago in the summer, and I've been doing, like, longer rides on the Lakefront trail. And one of my goals, actually, this summer is to do a bikepacking trip. But I have not been super comfortable on longer rides. And I was just thinking that this might be something really helpful to make them a little more enjoyable. +JOËL: So, is the kind of biking that you're doing closer to what might be considered commuting? +STEPHANIE: Yeah, mostly commuting. But also, just, like, going on long rides on the weekends, in addition to this, hopefully, forthcoming bikepacking trip up to a state park. So not too long, maybe, like, 60 miles, but definitely long enough to start getting a little uncomfy on your seat. +JOËL: Yeah, is 60 miles, like, in one day? +STEPHANIE: Yeah, exactly. +JOËL: That's a lot. Yeah, the friend who recommended biking shorts to me told me that pretty much anything over maybe 10 miles is worth getting shorts. +STEPHANIE: Wow, okay. I clearly have been suffering [laughs] for way too long, then. Tell me more about your cycling trip. +JOËL: So this is a bikes plus beer trip. Basically, I plotted a bunch of breweries in Belgium on a map and constructed an itinerary that could hit a bunch of them while keeping fairly short rides between towns. And the goal is to do maybe 30-35 miles in a day. And so I'll be going probably, like, cycling in the morning, and then exploring and drinking in the afternoon and evening. +STEPHANIE: That sounds amazing. That's really cool to do a little bit of a tour of the area and then also traveling by bike. +JOËL: Yeah, I'm excited because other modes of transport really just give you the origin and the destination, whereas cycling, you kind of get all of the in-between places. You get a much better feel for the area that you're in. And you can make all these unexpected stops if you want. You can make detours. So I feel like you get the sort of being in the moment, being in the place effect that you would have as a pedestrian but with a much longer reign. +STEPHANIE: Yeah, absolutely. That's exactly what I was going to say. I love cycling. And there's something really special about being able to be present in your surroundings and seeing people on the street or a cool building as you're going. But also going at a speed where it feels very fun and very freeing to just be cycling through a town and making stops when you want to, and traveling greater distances than you could be able to on foot. +JOËL: So I just received these bike shorts yesterday in the mail. So today, at the end of the day, I'm going out for a bike ride, and I'm going to see if they perform as advertised. +STEPHANIE: That's exciting. Keep us posted [laughs] on if you end up liking them or not. +JOËL: Yeah, yeah. The next episode or two, I'll have to report bike shorts; yay or nay? +STEPHANIE: Yeah, The Bike Shed will now become bike gear reviews. +JOËL: The name will actually line up, then with what the people googling, it might think it actually is. Stephanie, what's new in your world? +STEPHANIE: Speaking of vacation, I just got back from a two-and-a-half-week trip myself. I mentioned on the podcast a couple of episodes ago, I think, that I was traveling to Japan for RubyKaigi, an international Ruby Conference over in Japan. And then I spent another week in Taiwan, just on my own time. So, yeah, I had a really big, long trip, and it was really great. It was my first time going abroad in a really long time. It was my first time being somewhere where I didn't speak the language. +So, in Japan...I don't speak any Japanese. And it was both challenging and also, like, not too bad. I found my way around through a lot of gesturing and smiling, and nodding. [laughs] And, hopefully, people were able to understand what I was trying to communicate. Also, pointing at menus, I highly recommend going to places that have pictures of the food, and then you can just point when you want to order. [laughs] +JOËL: So, did you find that English was not particularly useful then in Japan as a tourist? +STEPHANIE: Yeah, I would say so. The next thing was that most signs were translated. So we ended up taking public transportation a lot. And that was quite easy to navigate, especially since I have kind of navigated subways in other cities before, and reading the signs is no problem. But when you're trying to communicate with locals, that was a little harder. +JOËL: Did you use any, like, apps on your phone or anything like that to help navigate kind of the different language? +STEPHANIE: Yeah, the Google Translate Lens app. I can't remember exactly what it is. But this was my first time really using it. And I was really impressed by how it was able to translate things that you're using your camera to take pictures of, or just, like, having your camera view. I did feel a little silly, like, holding my phone up to everything and trying [laughs]...so I could understand what I was reading. But for menus that did not have pictures, that was my backup strategy. [laughs] +JOËL: Did you ever have to have your phone translate something and then just show your phone to someone else? +STEPHANIE: No, I didn't have to go that far. Though I do think that it has a feature where you can have someone speak into the phone, and it will translate that into your native language. And then you respond by speaking into it and then playing the sound for them, which, you know, I bet really works in a pinch. But I think that required a little more investment into the interaction [laughs] with the other person than I was ready for. Like I said, the gesturing served me quite well. +JOËL: I got the experience of being on the other side of that a while back. So, here in Boston, I was just walking down the street, and someone stopped me and just holds up their phone. And they've typed something in Chinese on there. And they hit a button, and it comes in English. +STEPHANIE: [laughs] +JOËL: And they're asking for directions. And I think I typed a sentence back on their phone in English, and then they hit the translate button and got it back in Chinese. We went back and forth a few times. And eventually, I think he got what he wanted, and we went our separate ways. And I was kind of amazed that this whole interaction happened. +STEPHANIE: Yeah, that's really cool. +JOËL: Yeah, kudos to that person for having the courage to stop someone on the street when you don't speak their language. +STEPHANIE: Yeah, absolutely. I think even when I was struggling to communicate with someone because of the language barrier, I could tell from their gesturing in return that we were, like, willing to help each other out. And that, like, there was still an ability to find some kind of connection, even though, you know, we didn't completely understand each other. And that was definitely one thing that I really enjoyed was being in a place with, you know, people different from me and having that exposure. It's been a really long time since I've got to experience that, and that was really valuable. +JOËL: So, other than the conference, what would you say are some highlights of the trip for you, maybe one from Japan and one from Taiwan? +STEPHANIE: So one of my favorite things about being in Tokyo was all the green space that was around. I ended up walking a lot just to explore the neighborhoods. And I always just stumbled across a local park or even a shrine that had really great nature around it, a lot of big trees. You know, some, like, water features, maybe like a pond, and a lot of really fun plants that I got to learn about. +And, yeah, that was really nice, especially in such a dense urban area, like, coming across green space to just sit for a little while. And it was such a nice relief from the density and busyness of a big city. That was just one thing that I was really impressed by being in Japan. +JOËL: That's really cool. I think that really speaks to the quality of their urban planning. I know that the stereotype of Tokyo that I have in my mind is that it's, like, you know, ultra-modern, ultra-urban, you know, it's the largest city in the world. So the idea that they've taken the time to set up all these little parks everywhere is really endearing. +Particularly, I think the idea of smaller parks at the neighborhood level where you don't need, you know, something massive like, let's say, New York's Central Park, which is, you know, really cool. But having just a little green space in your neighborhood where you can, like, stop by, I think it's a wonderful upgrade to local people's quality of life. +I was recently listening to a video on YouTube from a city planning channel talking about just all the thinking that goes behind city parks, and having them at different scales, and how that impacts the residents of different areas. So it's really cool to hear that Tokyo has done a great job with that. +STEPHANIE: Yeah, absolutely. I think part of the joy of just stumbling upon it was that you know, even when I wasn't seeking it out, it would just come along during my walks. And, yeah, it really was very refreshing. +JOËL: What about Taiwan? +STEPHANIE: So, in Taiwan, what I really enjoyed about it it's a bit of a smaller island. And so you can actually get to a lot of places within a few days. And a lot of folks take day trips out to the coast from Taipei. And I was able to do a two-day trip to another county that had some hot springs, and I got to enjoy an outdoor hot springs in the rain. And that was really nice because it was, like, surrounded by trees. +And it happened to be raining that morning, but, you know, we were all kind of already getting wet, so it didn't really matter. And it was just, like, this really serene and gorgeous experience being able to enjoy that. And I think that was another place where I was in a very urban area, and then being able to escape a little bit was really nice. +JOËL: That sounds like a magical moment. Have you visited hot springs before, or was this your first time going to a hot spring? +STEPHANIE: I have been to a few in the U.S. before. I like to take road trips to national parks. And there are some really great hot springs in the U.S. as well. And so this was kind of something that I really wanted to do somewhere else just to experience it elsewhere. And, yeah, I'm really glad to have checked that off my bucket list. +JOËL: That's really cool. I've never been to a hot spring, and it sounds like a fun thing to do. So it's on my kind of greater bucket list. It's maybe not a top-five thing to do, but definitely, something I want to do one day. +STEPHANIE: Cool. Love it. That was vacation talk from Joël and Stephanie. [laughs] +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So recently at thoughtbot, we've been having conversations around this really interesting data modeling exercise, where let's say this is a company, and you want to purchase T-shirts for everyone at the company. You have already some T-shirts on hand because you've done this kind of thing before in a couple of different warehouses. And you need to know how many new T-shirts you need to order in order to have enough for everyone. +So as long as you keep things simple, the math is pretty easy because you sum the number of people at your company, and then you sum the number of shirts across all of your warehouses, and that gives you the T-shirts that you need, the T-shirts that you have. You get the difference between those two numbers, and that tells you how many new T-shirts you need to order. Where things get more complicated is once you start introducing T-shirt sizes, and that's where the fun data modeling comes in. +If everyone at your company has a T-shirt size that they want and then at your warehouses, you store...the object that represents a warehouse stores a hash of sizes and how many of each size you have. Now, how do you do all this, like, summing across things? And it's not really just a single number that you want. Now you need to know how many small, mediums, and larges. +And, sometimes, you've got a hash. Sometimes you've got just symbols on a user, and you've got a sum across hashes. Maybe do some differences across hashes. And it gets kind of tricky to work with. So that's sort of the problem as it's initially presented. And we've been having a really interesting conversation around different ways to try to solve it in a way that's really kind of clean and nice. +STEPHANIE: Yeah, that's interesting because what you described sounds like the first iteration of solving the problem is, oh, the warehouse stores this information as a hash. So maybe I will create a new hash for the counts of T-shirt sizes that I need and then do the comparison on those two hashes. It sounds like maybe there was some unwieldiness or maybe even some duplicated code there. Is that what you think you all were trying to solve by modeling this differently? +JOËL: I think we kind of quickly hit some limitations with hashes. One thing that is fun before we start trying to combine a bunch of hashes is that some of the data exists as a hash on the warehouses. But to get the T-shirts that we need, all we have are an array of users and a size on all of them. +And we can use this fun method from Enumerable called Tally to give us a kind of Tally hash that is just a mapping of size, two counts of that size in the array. And so that's a really fun method. You don't get to bring it out that often in Ruby. And it's nice because that hash format happens to match the same format as the hashes stored on the warehouse objects. +STEPHANIE: Right. So now you're comparing apples to apples. But it sounds like maybe this hash representation does hold some kind of significance. +JOËL: Yeah. I guess, for me, I tend to see anytime you're doing fancier operations on a hash more than just reading in and out; it probably wants to be some kind of value object. And, in this case, we kind of want to do math on hashes. I think the equation is kind of still the same thing. We're trying to get the difference between the two, between the want versus have, but you can't just subtract one hash from another directly. +There's some things that you can do with the hash merge method that allows you to pass a custom block and do some things there. But we're going to have to do this sort of repeatedly. And now we're kind of leaking some of that knowledge a little bit. So it feels like something where you might want to actually name this concept and make it an object of its own that can then have its own kinds of domain operations as methods on it. +STEPHANIE: Yeah, I like that a lot. Because even just as I was thinking about it when you are storing data like that in just a hash, what do you call it? Like, what do you name it? I think I've seen things like that named, like, T-shirt data, or, like, warehouse data, or warehouse T-shirt counts, or T-shirt counts. You know, that is when it starts to diverge, and you end up maybe seeing the same, like, data represented, but it being named different things in different parts of the code. And I, in experience, have found that very painful. +JOËL: Yeah, because I guess you could have, like, T-shirts on hand from your warehouse; that's one hash. But the hash generated from the users might get called something like user preferences. And if you're reading through that code and you see a hash, and you're like, okay, do these two hashes that I'm looking at, maybe in a test, just kind of coincidentally have the same keys? Or are these kind of fundamentally the same thing? Or is the idea of, like, T-shirts on hand like a stock different from, like, a preference? And do they represent different things that just happen to be similar in this particular scenario? +STEPHANIE: Right. And especially if then there are methods where you're passing that data structure that really represents the same thing. But you're passing it as arguments, and then, suddenly, one variable name, user preferences, or user T-shirt preferences becomes, you know, T-shirt count. That has been really confusing for me before. +JOËL: One thing that does get, I think, clunky very quickly is that you have all of these warehouse objects that have that hash of, like, stock on hand on them. And what you really want is a kind of aggregate object that tells you not what's the stock on hand for one warehouse but across all warehouses. So you've got to go through, I guess, that array of warehouses and somehow kind of aggregate all of those hashes together. And because they're already tallies, you can't just do Enumerable Tally on it anymore. You've got to find some way to combine them together, and that gets tricky really quickly. +STEPHANIE: Right. I can see they're starting to be, like, nested loops, especially if you're just working with primitives. +JOËL: I think some initial implementations that we saw ended up doing either, like, some kind of reduce block or eachwithobject, or something like that, which are, I think, fine solutions here. But what lives inside of those blocks is what gets complicated. And I don't know about you, but I feel like if I'm reading through some code and then all of a sudden I see a reduce block, and it's, like, ten lines of logic with maybe some, like, nested things, like, maybe some nested loops or some conditions inside of it, that's kind of intimidating. Reduce is not a super easy method to wrap your head around, especially when the block has got a lot of logic. +STEPHANIE: Yeah, that's a really good point. It definitely gives me pause. And I have to, like, you know, commit to reading the method in its entirety to fully understand [laughs] what's going on. +JOËL: Sometimes, like, really pause and, like, annotate with comments and all this stuff. +STEPHANIE: So, what did you end up thinking about in terms of solving that problem of aggregating the sums of all the different T-shirt sizes for each warehouse? +JOËL: So I think, for me, oftentimes, it's easier to make the problem a little bit smaller, solve that smaller problem, and then try to kind of scale up back up again and particularly when you're dealing with something like reducing or aggregating a large collection. Like, forget about dealing with a collection. Just how could I combine two items of this type? So if I had two of these hashes. And forget about fitting it for an array. But if I have two of these hashes, how could I combine them together? +And you could do this with hash merge. I wanted to do things a little bit more encapsulated. And because I also knew that we're building some more logic around these, I actually wrote a custom object. I called it a tally, maybe inspired by that Enumerable method, and implemented an operator plus on this tally object. So a tally object can plus another tally object. And the response from that is you get a third tally object that's gone through all of the keys and summed them together. So it's kind of an aggregate sum. +STEPHANIE: This is a cool example of a method that's a verb also representing a noun to name the return value, right? So the Tally method on Enumerable returns a hash, which we have been talking about for a while as, like, a data structure that's, you know, perfectly fine, but maybe we can leverage turning it into like you said, a value object to give it more meaning or to make it easier to work with. And it seems like the naming part just kind of fell into your lap. +JOËL: Yeah, tally is interesting in that it is both a noun and a verb in English. I'm not sure what the grammatical term for that kind of word is. +STEPHANIE: So, once you extracted this new class out, what insights or observations did you have about this problem? +JOËL: What becomes really cool about this is that once you have a way of combining two objects together, reduce is a way to just kind of scale that up to an arbitrary number. And so, just like you can sum an array of numbers by reducing plus over the array. Because I have plus on my tally object, I can reduce plus operator over an array of tally objects. And they all just kind of sum together in a single tally that's the combination of all of them. So this is really cool. +What used to be an intimidating reduce block, the intimidating logic gets moved into a plus method, which I think is much more approachable. Because I can go in the context of an object and say, okay, I've got this tally object, and I'm trying to add it to another tally object. And we're just going one key at a time, adding them together. Simple enough. +And then in the place where we're reducing, all we're saying is list of tallies reduce plus. And I know that pattern already because I do it with integers to sum them together. And so now I've just got this really simple one-line in the scary part. And the actual complex logic is much more approachable. +STEPHANIE: That is very cool. I found it really interesting that this came about because we were trying to do math on these two hashes. So it seems like, you know, a tally because it represents a score or, like, a number. Like, we were able to implement those plus operators and get to a simple solution because we're working with numbers. +JOËL: Yeah, I think it might be fair to describe it as maybe a compound number is the term that I use. I don't know if that's mathematically correct. Oftentimes, when you're dealing with things that represent a number or something that's represented numerically but that might have more than one number involved in it. But you still want to do math with this kind of compound, multi-number value anyway. +And one example that you might have is, let's say, a point in 2D space. You have an X coordinate and a Y coordinate. And you can do math on points. In fact, there's a whole field of math to deal with that kind of thing. That's an important thing that you have to do. You might want to be able to add or subtract points. You might want to do certain types of multiplication on them. And so just because something has more than one number associated to it doesn't mean that it can't be used for math. In fact, oftentimes, that's where the fancier math does come into play. +But when we treat them as primitives, and we just have, let's say, our XY pair was a hash, or, like, a two-element array, then we lose the ability to do math nicely. If we create, let's say, a point class that has an X and Y, and then we define plus, we define minus, we define scalar and vector multiplication, things like that, now we can do all those operations. And we can treat it like math, even though it's not just a simple integer anymore. +STEPHANIE: Yeah, I like that a lot because we do end up working with data, you know, maybe even from our database. But then, inevitably, we want to, like, learn something about it. And so I was thinking about how frequently I use GROUP BY in MySQL queries and how, oftentimes, I care about counts, or, like, number of records. +And perhaps this is why we see, like, the hash primitive used so frequently in codebases that then become pretty complicated once we're trying to, like I mentioned, like, learn something about it or, like, compare things or whatever logic that we need to do. And transforming them into objects that then know how to do math on themselves [laughs] is very cool. +JOËL: Hashes are interesting because they're pretty much just basic data structures. And I think, very often, they're sort of pre-objects. They're things that want to eventually become objects. And, oftentimes, what I find is that hashes get passed around a system. And various other classes or subsystems all have bits of logic that act on the hash because the hash can't own that. +And so you end up with the logic around the concept of whatever the hash represents kind of scattered and maybe duplicated across three or four places in the application. And then, all of a sudden, if you give that a name, if you create a class for it, you can pull all of that logic into one place. And, all of a sudden, it probably cleans up all of the surrounding places because now they don't have to care about the implementation of exactly what operating on the hash is. +But, also, it means that these operations generally have, like, nice domain names. And, in the case of a complex number, you might even have that represented through math operations, like, plus or minus. And that allows your code to read really nicely. +STEPHANIE: Right. Which gets me thinking about how I mentioned, like, tally as a noun, and, you know, you implemented your custom class. But do you think there's any value in the idea of a tally being specifically like a hash-like thing with a number as the value for each key, like, that existing as a more general class for people to use? +JOËL: Oh, that's interesting. So, in my personal implementation, I hard-coded values for small, medium, and large because those were the T-shirt sizes from the example. But you're talking about some sort of generic tally object that maybe would be a gem or something like that that people could use that represents counts of arbitrary things or multiple counts of arbitrary things that might then implement some common math operators so that you could add or subtract them. +STEPHANIE: Yeah, exactly. Because I was just thinking, you know, like I mentioned, I often represent that when I count number of records in my database. Or even I can recall a problem that I encountered previously where I had to figure out the number of orders for an e-commerce store based on the location. And I held that in a hash data structure, but really, it's a tally. [laughs] And so, yeah, I think that maybe we've kind of stumbled across a very useful representation of very common problems. +JOËL: Yeah, I can see there being use for a generic version of this. Maybe that's your chance to go out and create some open source, or maybe this already exists. We should maybe research that first. +STEPHANIE: Yeah, if any one of our listeners know, [laughs] send us an email. +JOËL: So something that was really interesting to me about all of these changes, introducing the value object, cleaning up the reduce, all that stuff, is that, in the end, once the...there was this object that represented the sort of aggregate compound value, the tally, then the equation stayed the same. And I can just slot in those variables as before. +Whereas previously, when we switch from just a single count to this, like, we need to take into account sizes that, like, broke the initial implementation of the code. So it's funny how you sort of go from a simple implementation and then a new requirement, which breaks it. But then just changing the hash to be an object all of a sudden made the original code, which didn't really need to change; it just worked again. +STEPHANIE: Hmm. That's really interesting because it makes me think about how maybe the primitives were perfectly fine, you know, in the first set of requirements, and not until, like, an additional complexity or something new emerged that we needed to reach for an object that could support the change. +JOËL: Yeah. And I think I'd argue that if you're doing just raw T-shirt count, an integer is probably the right value to use there. But if you're doing counts broken out by T-shirt size, then having an object that's a single thing that responds to plus and minus so that you can use it in the same equation where you're saying sum up all of these things from the warehouse, and then do a difference with the T-shirts that we need that becomes really nice. +STEPHANIE: Do you think there was some value in going through the hash implementation first, though, and then arriving at using a more custom object? I'm curious, kind of, like, what that journey was like. +JOËL: It's hard to say. I would say maybe yes. But I could also see someone who's done this a lot, who's built the sort of heuristics, the instincts around this could immediately be like, oh, wait, we're trying to sum hashes here. Clearly, these need to be objects. Clearly, what we need is something that implements a plus operator that we can reduce. +STEPHANIE: Yeah, I like that a lot. Because part of, you know, knowing what to reach for is having seen it enough times and seeing patterns, right? +JOËL: This reminds me of a particular pattern that comes from the world of functional programming. It has a kind of scary-sounding name. It's monoid, not monad, monoid. And the idea in the context of Ruby is it's some kind of object that implements a plus method. So two of these objects can combine each other. And typically, you also have some sort of empty version of this object or some sort of, like, zero value. +And there's a few rules that go around, like, kind of how this object has to behave. Like, you can't just put any implementation you want in that plus method. Certain requirements that have to be met for it to be considered, like, a valid plus method in this pattern. But if you do meet those requirements, then arrays of this type of object are just inherently reducible because you can just reduce plus over them. +And so I think anytime you're trying to aggregate some sort of unwieldy data structure, that's probably a useful pattern to have because, you know, wait, as long as I have a way to combine two items together and potentially some way to generate an empty state, I can aggregate this whole list. +STEPHANIE: I'm curious, does that also apply to non-numerical values? +JOËL: Yes, any kind of aggregation combination, whatever. So maybe what you're doing is you're combining strings together. +STEPHANIE: Got it. +JOËL: String concatenation is a form of combination. And so you could be reducing some kind of concatenation over an array of strings, and you end up with one aggregate string that's the combination of all of them. Sometimes, though, you're not just taking values and putting them next to each other so that what you have is kind of all of them at the same time. You might instead do some kind of comparison. +An example here might be Boolean values. You might say the way that I'm sort of, quote, unquote, "aggregating" two values, two Boolean values is with the operator AND. And so you have two Boolean values, and you get a new sort of combo value out of them, that is, are both of these values true? +STEPHANIE: Whoa, that's blowing my mind right now. Because I had never thought of the, like, AND operator on Booleans, essentially aggregating them into a single true or false value. [laughs] +JOËL: It's kind of weird, right? But I guess we do the same thing with numbers. One plus one doesn't give us 11 unless you're writing JavaScript. +STEPHANIE: [laughs] +JOËL: You know, we get a new number too, that is some sort of, like, combination of the two. So, similarly, it kind of makes sense that two Booleans might combine to create a new sort of third Boolean value. Where it gets really interesting, though, is that once you have this sort of combination, if you try to reduce AND over an array of Booleans, what you effectively have created is Ruby's Enumerable all method that checks to say, are all values in this array true? +STEPHANIE: Interesting. But really, the way that's implemented is just, like, a definition of what aggregate means for Booleans, right? +JOËL: Right. But it's taking that idea of aggregating two values and scaling it up to an array of many values. So we know Boolean AND. Another way to think about it is, are both of these values true? Is the question it's trying to answer. And then we're scaling that out to say, is both of these values true for everything? So are all of these values true? Because we're going from two to many. +STEPHANIE: Cool. So maybe the takeaway for some of our listeners could be, like, next time they find themselves having to deal with a collection or an Enumerable and, you know, using a reduce or, like, trying to break it down to compare two of those elements first, and figuring out how they want that interaction to work. Does that sound right? +JOËL: Yeah, absolutely. Once you have a way to combine two elements together, if you want to scale it up to n elements, you just plug it into reduce, and it does the rest of the work for you. +My big takeaways from this exercise were one: the value of creating custom objects. Wrapping primitives like hashes in an object and adding a few domain methods on them made such a difference in my final implementation. +Secondly, I think it's what you're saying, this whole thing about breaking down complex reduce problems by figuring out how to combine two items and then just using reduce to scale it to an array. +And then, finally, I think this is a point that we've mentioned on this podcast before, the value of specific vocabulary - being able to name things and patterns. And so knowing some of the details of this monoid pattern and having a name for it means that now I start seeing it in places. And so the moment I see, oh, wait, we're aggregating values; we're combining two values together and then doing this in a reduce, immediately, my mind goes, wait, that feels like monoid. And then, I can explore that with my custom object to try to make the code better. +STEPHANIE: Yeah. And even if you don't remember the monoid part specifically, the idea of Tally, like, that is something that I think is really cool and really applicable to a lot of codebases. +JOËL: So, for those who are interested in more practically what this code looks like, I've put this all in a Gist, and I'll link to it in the show notes. This was a really fun exercise for me because I used sort of two development techniques to help sort of build this out. +One, I went with a kind of literate programming approach, where I had just a Ruby file and would have put in some big comment blocks talking about what the setup was, what I was trying to do, and then describing how I'd like to use the code, and then try to write code that made that happen. And then, for the actual objects that I was using under the hood, I used TDD to test drive and build them out. +So you've got all of that in the Gist. We've got the tests and that sort of literate programming script that almost reads like a mini blog post, except it's executable Ruby. So, if you're curious to see about that, the link is in the show notes. +STEPHANIE: That's a very cool format. I'm excited to take a look. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + If you're in the market for bicycle shorts, Joël's got you. Stephanie just returned from RubyKaigi in Japan and shares details of her trip.

+ +

Recently at thoughtbot, there have been conversations around an interesting data modeling exercise. Joël and Stephanie discuss the following:

+ +
    +
  • Value Objects vs. Hashes
    • +
  • Doing Math on Compound Numbers
    • +
  • Monoids and Folding
    • +
  • Naming Concepts in Code
    • +
+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've made an unusual purchase this week. I went out and bought a pair of bicycle shorts. And, for those who are not aware, these are special shorts that have padding built into them. Typically, they're, like, skin-tight, but I got, I guess, what are called mountain biking shorts. So, they kind of look more like the cut of a normal short. But they've got this, like, built-in padding for biking.

+ +

STEPHANIE: So. Just to confirm, you did get these shorts for biking purposes, right?

+ +

JOËL: Yes. I purchased these shorts for biking purposes.

+ +

STEPHANIE: Okay. [laughs]

+ +

JOËL: And I got these because I was talking to a friend about this and mentioning that this was, like, probably the most ambitious cycling thing I've ever done in my life. And they recommended if you have not done bike shorts, you really should get them. They make a big difference.

+ +

STEPHANIE: Wow. Okay, I have two thoughts here. First of all, you prefaced this saying that this was an unusual purchase. So I thought maybe that you bought these bike shorts for some other purpose. [laughs] But I am excited to talk about this because I've also been curious about trying bike shorts.

+ +

I bike a lot in Chicago in the summer, and I've been doing, like, longer rides on the Lakefront trail. And one of my goals, actually, this summer is to do a bikepacking trip. But I have not been super comfortable on longer rides. And I was just thinking that this might be something really helpful to make them a little more enjoyable.

+ +

JOËL: So, is the kind of biking that you're doing closer to what might be considered commuting?

+ +

STEPHANIE: Yeah, mostly commuting. But also, just, like, going on long rides on the weekends, in addition to this, hopefully, forthcoming bikepacking trip up to a state park. So not too long, maybe, like, 60 miles, but definitely long enough to start getting a little uncomfy on your seat.

+ +

JOËL: Yeah, is 60 miles, like, in one day?

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: That's a lot. Yeah, the friend who recommended biking shorts to me told me that pretty much anything over maybe 10 miles is worth getting shorts.

+ +

STEPHANIE: Wow, okay. I clearly have been suffering [laughs] for way too long, then. Tell me more about your cycling trip.

+ +

JOËL: So this is a bikes plus beer trip. Basically, I plotted a bunch of breweries in Belgium on a map and constructed an itinerary that could hit a bunch of them while keeping fairly short rides between towns. And the goal is to do maybe 30-35 miles in a day. And so I'll be going probably, like, cycling in the morning, and then exploring and drinking in the afternoon and evening.

+ +

STEPHANIE: That sounds amazing. That's really cool to do a little bit of a tour of the area and then also traveling by bike.

+ +

JOËL: Yeah, I'm excited because other modes of transport really just give you the origin and the destination, whereas cycling, you kind of get all of the in-between places. You get a much better feel for the area that you're in. And you can make all these unexpected stops if you want. You can make detours. So I feel like you get the sort of being in the moment, being in the place effect that you would have as a pedestrian but with a much longer reign.

+ +

STEPHANIE: Yeah, absolutely. That's exactly what I was going to say. I love cycling. And there's something really special about being able to be present in your surroundings and seeing people on the street or a cool building as you're going. But also going at a speed where it feels very fun and very freeing to just be cycling through a town and making stops when you want to, and traveling greater distances than you could be able to on foot.

+ +

JOËL: So I just received these bike shorts yesterday in the mail. So today, at the end of the day, I'm going out for a bike ride, and I'm going to see if they perform as advertised.

+ +

STEPHANIE: That's exciting. Keep us posted [laughs] on if you end up liking them or not.

+ +

JOËL: Yeah, yeah. The next episode or two, I'll have to report bike shorts; yay or nay?

+ +

STEPHANIE: Yeah, The Bike Shed will now become bike gear reviews.

+ +

JOËL: The name will actually line up, then with what the people googling, it might think it actually is. Stephanie, what's new in your world?

+ +

STEPHANIE: Speaking of vacation, I just got back from a two-and-a-half-week trip myself. I mentioned on the podcast a couple of episodes ago, I think, that I was traveling to Japan for RubyKaigi, an international Ruby Conference over in Japan. And then I spent another week in Taiwan, just on my own time. So, yeah, I had a really big, long trip, and it was really great. It was my first time going abroad in a really long time. It was my first time being somewhere where I didn't speak the language.

+ +

So, in Japan...I don't speak any Japanese. And it was both challenging and also, like, not too bad. I found my way around through a lot of gesturing and smiling, and nodding. [laughs] And, hopefully, people were able to understand what I was trying to communicate. Also, pointing at menus, I highly recommend going to places that have pictures of the food, and then you can just point when you want to order. [laughs]

+ +

JOËL: So, did you find that English was not particularly useful then in Japan as a tourist?

+ +

STEPHANIE: Yeah, I would say so. The next thing was that most signs were translated. So we ended up taking public transportation a lot. And that was quite easy to navigate, especially since I have kind of navigated subways in other cities before, and reading the signs is no problem. But when you're trying to communicate with locals, that was a little harder.

+ +

JOËL: Did you use any, like, apps on your phone or anything like that to help navigate kind of the different language?

+ +

STEPHANIE: Yeah, the Google Translate Lens app. I can't remember exactly what it is. But this was my first time really using it. And I was really impressed by how it was able to translate things that you're using your camera to take pictures of, or just, like, having your camera view. I did feel a little silly, like, holding my phone up to everything and trying [laughs]...so I could understand what I was reading. But for menus that did not have pictures, that was my backup strategy. [laughs]

+ +

JOËL: Did you ever have to have your phone translate something and then just show your phone to someone else?

+ +

STEPHANIE: No, I didn't have to go that far. Though I do think that it has a feature where you can have someone speak into the phone, and it will translate that into your native language. And then you respond by speaking into it and then playing the sound for them, which, you know, I bet really works in a pinch. But I think that required a little more investment into the interaction [laughs] with the other person than I was ready for. Like I said, the gesturing served me quite well.

+ +

JOËL: I got the experience of being on the other side of that a while back. So, here in Boston, I was just walking down the street, and someone stopped me and just holds up their phone. And they've typed something in Chinese on there. And they hit a button, and it comes in English.

+ +

STEPHANIE: [laughs]

+ +

JOËL: And they're asking for directions. And I think I typed a sentence back on their phone in English, and then they hit the translate button and got it back in Chinese. We went back and forth a few times. And eventually, I think he got what he wanted, and we went our separate ways. And I was kind of amazed that this whole interaction happened.

+ +

STEPHANIE: Yeah, that's really cool.

+ +

JOËL: Yeah, kudos to that person for having the courage to stop someone on the street when you don't speak their language.

+ +

STEPHANIE: Yeah, absolutely. I think even when I was struggling to communicate with someone because of the language barrier, I could tell from their gesturing in return that we were, like, willing to help each other out. And that, like, there was still an ability to find some kind of connection, even though, you know, we didn't completely understand each other. And that was definitely one thing that I really enjoyed was being in a place with, you know, people different from me and having that exposure. It's been a really long time since I've got to experience that, and that was really valuable.

+ +

JOËL: So, other than the conference, what would you say are some highlights of the trip for you, maybe one from Japan and one from Taiwan?

+ +

STEPHANIE: So one of my favorite things about being in Tokyo was all the green space that was around. I ended up walking a lot just to explore the neighborhoods. And I always just stumbled across a local park or even a shrine that had really great nature around it, a lot of big trees. You know, some, like, water features, maybe like a pond, and a lot of really fun plants that I got to learn about.

+ +

And, yeah, that was really nice, especially in such a dense urban area, like, coming across green space to just sit for a little while. And it was such a nice relief from the density and busyness of a big city. That was just one thing that I was really impressed by being in Japan.

+ +

JOËL: That's really cool. I think that really speaks to the quality of their urban planning. I know that the stereotype of Tokyo that I have in my mind is that it's, like, you know, ultra-modern, ultra-urban, you know, it's the largest city in the world. So the idea that they've taken the time to set up all these little parks everywhere is really endearing.

+ +

Particularly, I think the idea of smaller parks at the neighborhood level where you don't need, you know, something massive like, let's say, New York's Central Park, which is, you know, really cool. But having just a little green space in your neighborhood where you can, like, stop by, I think it's a wonderful upgrade to local people's quality of life.

+ +

I was recently listening to a video on YouTube from a city planning channel talking about just all the thinking that goes behind city parks, and having them at different scales, and how that impacts the residents of different areas. So it's really cool to hear that Tokyo has done a great job with that.

+ +

STEPHANIE: Yeah, absolutely. I think part of the joy of just stumbling upon it was that you know, even when I wasn't seeking it out, it would just come along during my walks. And, yeah, it really was very refreshing.

+ +

JOËL: What about Taiwan?

+ +

STEPHANIE: So, in Taiwan, what I really enjoyed about it it's a bit of a smaller island. And so you can actually get to a lot of places within a few days. And a lot of folks take day trips out to the coast from Taipei. And I was able to do a two-day trip to another county that had some hot springs, and I got to enjoy an outdoor hot springs in the rain. And that was really nice because it was, like, surrounded by trees.

+ +

And it happened to be raining that morning, but, you know, we were all kind of already getting wet, so it didn't really matter. And it was just, like, this really serene and gorgeous experience being able to enjoy that. And I think that was another place where I was in a very urban area, and then being able to escape a little bit was really nice.

+ +

JOËL: That sounds like a magical moment. Have you visited hot springs before, or was this your first time going to a hot spring?

+ +

STEPHANIE: I have been to a few in the U.S. before. I like to take road trips to national parks. And there are some really great hot springs in the U.S. as well. And so this was kind of something that I really wanted to do somewhere else just to experience it elsewhere. And, yeah, I'm really glad to have checked that off my bucket list.

+ +

JOËL: That's really cool. I've never been to a hot spring, and it sounds like a fun thing to do. So it's on my kind of greater bucket list. It's maybe not a top-five thing to do, but definitely, something I want to do one day.

+ +

STEPHANIE: Cool. Love it. That was vacation talk from Joël and Stephanie. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So recently at thoughtbot, we've been having conversations around this really interesting data modeling exercise, where let's say this is a company, and you want to purchase T-shirts for everyone at the company. You have already some T-shirts on hand because you've done this kind of thing before in a couple of different warehouses. And you need to know how many new T-shirts you need to order in order to have enough for everyone.

+ +

So as long as you keep things simple, the math is pretty easy because you sum the number of people at your company, and then you sum the number of shirts across all of your warehouses, and that gives you the T-shirts that you need, the T-shirts that you have. You get the difference between those two numbers, and that tells you how many new T-shirts you need to order. Where things get more complicated is once you start introducing T-shirt sizes, and that's where the fun data modeling comes in.

+ +

If everyone at your company has a T-shirt size that they want and then at your warehouses, you store...the object that represents a warehouse stores a hash of sizes and how many of each size you have. Now, how do you do all this, like, summing across things? And it's not really just a single number that you want. Now you need to know how many small, mediums, and larges.

+ +

And, sometimes, you've got a hash. Sometimes you've got just symbols on a user, and you've got a sum across hashes. Maybe do some differences across hashes. And it gets kind of tricky to work with. So that's sort of the problem as it's initially presented. And we've been having a really interesting conversation around different ways to try to solve it in a way that's really kind of clean and nice.

+ +

STEPHANIE: Yeah, that's interesting because what you described sounds like the first iteration of solving the problem is, oh, the warehouse stores this information as a hash. So maybe I will create a new hash for the counts of T-shirt sizes that I need and then do the comparison on those two hashes. It sounds like maybe there was some unwieldiness or maybe even some duplicated code there. Is that what you think you all were trying to solve by modeling this differently?

+ +

JOËL: I think we kind of quickly hit some limitations with hashes. One thing that is fun before we start trying to combine a bunch of hashes is that some of the data exists as a hash on the warehouses. But to get the T-shirts that we need, all we have are an array of users and a size on all of them.

+ +

And we can use this fun method from Enumerable called Tally to give us a kind of Tally hash that is just a mapping of size, two counts of that size in the array. And so that's a really fun method. You don't get to bring it out that often in Ruby. And it's nice because that hash format happens to match the same format as the hashes stored on the warehouse objects.

+ +

STEPHANIE: Right. So now you're comparing apples to apples. But it sounds like maybe this hash representation does hold some kind of significance.

+ +

JOËL: Yeah. I guess, for me, I tend to see anytime you're doing fancier operations on a hash more than just reading in and out; it probably wants to be some kind of value object. And, in this case, we kind of want to do math on hashes. I think the equation is kind of still the same thing. We're trying to get the difference between the two, between the want versus have, but you can't just subtract one hash from another directly.

+ +

There's some things that you can do with the hash merge method that allows you to pass a custom block and do some things there. But we're going to have to do this sort of repeatedly. And now we're kind of leaking some of that knowledge a little bit. So it feels like something where you might want to actually name this concept and make it an object of its own that can then have its own kinds of domain operations as methods on it.

+ +

STEPHANIE: Yeah, I like that a lot. Because even just as I was thinking about it when you are storing data like that in just a hash, what do you call it? Like, what do you name it? I think I've seen things like that named, like, T-shirt data, or, like, warehouse data, or warehouse T-shirt counts, or T-shirt counts. You know, that is when it starts to diverge, and you end up maybe seeing the same, like, data represented, but it being named different things in different parts of the code. And I, in experience, have found that very painful.

+ +

JOËL: Yeah, because I guess you could have, like, T-shirts on hand from your warehouse; that's one hash. But the hash generated from the users might get called something like user preferences. And if you're reading through that code and you see a hash, and you're like, okay, do these two hashes that I'm looking at, maybe in a test, just kind of coincidentally have the same keys? Or are these kind of fundamentally the same thing? Or is the idea of, like, T-shirts on hand like a stock different from, like, a preference? And do they represent different things that just happen to be similar in this particular scenario?

+ +

STEPHANIE: Right. And especially if then there are methods where you're passing that data structure that really represents the same thing. But you're passing it as arguments, and then, suddenly, one variable name, user preferences, or user T-shirt preferences becomes, you know, T-shirt count. That has been really confusing for me before.

+ +

JOËL: One thing that does get, I think, clunky very quickly is that you have all of these warehouse objects that have that hash of, like, stock on hand on them. And what you really want is a kind of aggregate object that tells you not what's the stock on hand for one warehouse but across all warehouses. So you've got to go through, I guess, that array of warehouses and somehow kind of aggregate all of those hashes together. And because they're already tallies, you can't just do Enumerable Tally on it anymore. You've got to find some way to combine them together, and that gets tricky really quickly.

+ +

STEPHANIE: Right. I can see they're starting to be, like, nested loops, especially if you're just working with primitives.

+ +

JOËL: I think some initial implementations that we saw ended up doing either, like, some kind of reduce block or each_with_object, or something like that, which are, I think, fine solutions here. But what lives inside of those blocks is what gets complicated. And I don't know about you, but I feel like if I'm reading through some code and then all of a sudden I see a reduce block, and it's, like, ten lines of logic with maybe some, like, nested things, like, maybe some nested loops or some conditions inside of it, that's kind of intimidating. Reduce is not a super easy method to wrap your head around, especially when the block has got a lot of logic.

+ +

STEPHANIE: Yeah, that's a really good point. It definitely gives me pause. And I have to, like, you know, commit to reading the method in its entirety to fully understand [laughs] what's going on.

+ +

JOËL: Sometimes, like, really pause and, like, annotate with comments and all this stuff.

+ +

STEPHANIE: So, what did you end up thinking about in terms of solving that problem of aggregating the sums of all the different T-shirt sizes for each warehouse?

+ +

JOËL: So I think, for me, oftentimes, it's easier to make the problem a little bit smaller, solve that smaller problem, and then try to kind of scale up back up again and particularly when you're dealing with something like reducing or aggregating a large collection. Like, forget about dealing with a collection. Just how could I combine two items of this type? So if I had two of these hashes. And forget about fitting it for an array. But if I have two of these hashes, how could I combine them together?

+ +

And you could do this with hash merge. I wanted to do things a little bit more encapsulated. And because I also knew that we're building some more logic around these, I actually wrote a custom object. I called it a tally, maybe inspired by that Enumerable method, and implemented an operator plus on this tally object. So a tally object can plus another tally object. And the response from that is you get a third tally object that's gone through all of the keys and summed them together. So it's kind of an aggregate sum.

+ +

STEPHANIE: This is a cool example of a method that's a verb also representing a noun to name the return value, right? So the Tally method on Enumerable returns a hash, which we have been talking about for a while as, like, a data structure that's, you know, perfectly fine, but maybe we can leverage turning it into like you said, a value object to give it more meaning or to make it easier to work with. And it seems like the naming part just kind of fell into your lap.

+ +

JOËL: Yeah, tally is interesting in that it is both a noun and a verb in English. I'm not sure what the grammatical term for that kind of word is.

+ +

STEPHANIE: So, once you extracted this new class out, what insights or observations did you have about this problem?

+ +

JOËL: What becomes really cool about this is that once you have a way of combining two objects together, reduce is a way to just kind of scale that up to an arbitrary number. And so, just like you can sum an array of numbers by reducing plus over the array. Because I have plus on my tally object, I can reduce plus operator over an array of tally objects. And they all just kind of sum together in a single tally that's the combination of all of them. So this is really cool.

+ +

What used to be an intimidating reduce block, the intimidating logic gets moved into a plus method, which I think is much more approachable. Because I can go in the context of an object and say, okay, I've got this tally object, and I'm trying to add it to another tally object. And we're just going one key at a time, adding them together. Simple enough.

+ +

And then in the place where we're reducing, all we're saying is list of tallies reduce plus. And I know that pattern already because I do it with integers to sum them together. And so now I've just got this really simple one-line in the scary part. And the actual complex logic is much more approachable.

+ +

STEPHANIE: That is very cool. I found it really interesting that this came about because we were trying to do math on these two hashes. So it seems like, you know, a tally because it represents a score or, like, a number. Like, we were able to implement those plus operators and get to a simple solution because we're working with numbers.

+ +

JOËL: Yeah, I think it might be fair to describe it as maybe a compound number is the term that I use. I don't know if that's mathematically correct. Oftentimes, when you're dealing with things that represent a number or something that's represented numerically but that might have more than one number involved in it. But you still want to do math with this kind of compound, multi-number value anyway.

+ +

And one example that you might have is, let's say, a point in 2D space. You have an X coordinate and a Y coordinate. And you can do math on points. In fact, there's a whole field of math to deal with that kind of thing. That's an important thing that you have to do. You might want to be able to add or subtract points. You might want to do certain types of multiplication on them. And so just because something has more than one number associated to it doesn't mean that it can't be used for math. In fact, oftentimes, that's where the fancier math does come into play.

+ +

But when we treat them as primitives, and we just have, let's say, our XY pair was a hash, or, like, a two-element array, then we lose the ability to do math nicely. If we create, let's say, a point class that has an X and Y, and then we define plus, we define minus, we define scalar and vector multiplication, things like that, now we can do all those operations. And we can treat it like math, even though it's not just a simple integer anymore.

+ +

STEPHANIE: Yeah, I like that a lot because we do end up working with data, you know, maybe even from our database. But then, inevitably, we want to, like, learn something about it. And so I was thinking about how frequently I use GROUP BY in MySQL queries and how, oftentimes, I care about counts, or, like, number of records.

+ +

And perhaps this is why we see, like, the hash primitive used so frequently in codebases that then become pretty complicated once we're trying to, like I mentioned, like, learn something about it or, like, compare things or whatever logic that we need to do. And transforming them into objects that then know how to do math on themselves [laughs] is very cool.

+ +

JOËL: Hashes are interesting because they're pretty much just basic data structures. And I think, very often, they're sort of pre-objects. They're things that want to eventually become objects. And, oftentimes, what I find is that hashes get passed around a system. And various other classes or subsystems all have bits of logic that act on the hash because the hash can't own that.

+ +

And so you end up with the logic around the concept of whatever the hash represents kind of scattered and maybe duplicated across three or four places in the application. And then, all of a sudden, if you give that a name, if you create a class for it, you can pull all of that logic into one place. And, all of a sudden, it probably cleans up all of the surrounding places because now they don't have to care about the implementation of exactly what operating on the hash is.

+ +

But, also, it means that these operations generally have, like, nice domain names. And, in the case of a complex number, you might even have that represented through math operations, like, plus or minus. And that allows your code to read really nicely.

+ +

STEPHANIE: Right. Which gets me thinking about how I mentioned, like, tally as a noun, and, you know, you implemented your custom class. But do you think there's any value in the idea of a tally being specifically like a hash-like thing with a number as the value for each key, like, that existing as a more general class for people to use?

+ +

JOËL: Oh, that's interesting. So, in my personal implementation, I hard-coded values for small, medium, and large because those were the T-shirt sizes from the example. But you're talking about some sort of generic tally object that maybe would be a gem or something like that that people could use that represents counts of arbitrary things or multiple counts of arbitrary things that might then implement some common math operators so that you could add or subtract them.

+ +

STEPHANIE: Yeah, exactly. Because I was just thinking, you know, like I mentioned, I often represent that when I count number of records in my database. Or even I can recall a problem that I encountered previously where I had to figure out the number of orders for an e-commerce store based on the location. And I held that in a hash data structure, but really, it's a tally. [laughs] And so, yeah, I think that maybe we've kind of stumbled across a very useful representation of very common problems.

+ +

JOËL: Yeah, I can see there being use for a generic version of this. Maybe that's your chance to go out and create some open source, or maybe this already exists. We should maybe research that first.

+ +

STEPHANIE: Yeah, if any one of our listeners know, [laughs] send us an email.

+ +

JOËL: So something that was really interesting to me about all of these changes, introducing the value object, cleaning up the reduce, all that stuff, is that, in the end, once the...there was this object that represented the sort of aggregate compound value, the tally, then the equation stayed the same. And I can just slot in those variables as before.

+ +

Whereas previously, when we switch from just a single count to this, like, we need to take into account sizes that, like, broke the initial implementation of the code. So it's funny how you sort of go from a simple implementation and then a new requirement, which breaks it. But then just changing the hash to be an object all of a sudden made the original code, which didn't really need to change; it just worked again.

+ +

STEPHANIE: Hmm. That's really interesting because it makes me think about how maybe the primitives were perfectly fine, you know, in the first set of requirements, and not until, like, an additional complexity or something new emerged that we needed to reach for an object that could support the change.

+ +

JOËL: Yeah. And I think I'd argue that if you're doing just raw T-shirt count, an integer is probably the right value to use there. But if you're doing counts broken out by T-shirt size, then having an object that's a single thing that responds to plus and minus so that you can use it in the same equation where you're saying sum up all of these things from the warehouse, and then do a difference with the T-shirts that we need that becomes really nice.

+ +

STEPHANIE: Do you think there was some value in going through the hash implementation first, though, and then arriving at using a more custom object? I'm curious, kind of, like, what that journey was like.

+ +

JOËL: It's hard to say. I would say maybe yes. But I could also see someone who's done this a lot, who's built the sort of heuristics, the instincts around this could immediately be like, oh, wait, we're trying to sum hashes here. Clearly, these need to be objects. Clearly, what we need is something that implements a plus operator that we can reduce.

+ +

STEPHANIE: Yeah, I like that a lot. Because part of, you know, knowing what to reach for is having seen it enough times and seeing patterns, right?

+ +

JOËL: This reminds me of a particular pattern that comes from the world of functional programming. It has a kind of scary-sounding name. It's monoid, not monad, monoid. And the idea in the context of Ruby is it's some kind of object that implements a plus method. So two of these objects can combine each other. And typically, you also have some sort of empty version of this object or some sort of, like, zero value.

+ +

And there's a few rules that go around, like, kind of how this object has to behave. Like, you can't just put any implementation you want in that plus method. Certain requirements that have to be met for it to be considered, like, a valid plus method in this pattern. But if you do meet those requirements, then arrays of this type of object are just inherently reducible because you can just reduce plus over them.

+ +

And so I think anytime you're trying to aggregate some sort of unwieldy data structure, that's probably a useful pattern to have because, you know, wait, as long as I have a way to combine two items together and potentially some way to generate an empty state, I can aggregate this whole list.

+ +

STEPHANIE: I'm curious, does that also apply to non-numerical values?

+ +

JOËL: Yes, any kind of aggregation combination, whatever. So maybe what you're doing is you're combining strings together.

+ +

STEPHANIE: Got it.

+ +

JOËL: String concatenation is a form of combination. And so you could be reducing some kind of concatenation over an array of strings, and you end up with one aggregate string that's the combination of all of them. Sometimes, though, you're not just taking values and putting them next to each other so that what you have is kind of all of them at the same time. You might instead do some kind of comparison.

+ +

An example here might be Boolean values. You might say the way that I'm sort of, quote, unquote, "aggregating" two values, two Boolean values is with the operator AND. And so you have two Boolean values, and you get a new sort of combo value out of them, that is, are both of these values true?

+ +

STEPHANIE: Whoa, that's blowing my mind right now. Because I had never thought of the, like, AND operator on Booleans, essentially aggregating them into a single true or false value. [laughs]

+ +

JOËL: It's kind of weird, right? But I guess we do the same thing with numbers. One plus one doesn't give us 11 unless you're writing JavaScript.

+ +

STEPHANIE: [laughs]

+ +

JOËL: You know, we get a new number too, that is some sort of, like, combination of the two. So, similarly, it kind of makes sense that two Booleans might combine to create a new sort of third Boolean value. Where it gets really interesting, though, is that once you have this sort of combination, if you try to reduce AND over an array of Booleans, what you effectively have created is Ruby's Enumerable all method that checks to say, are all values in this array true?

+ +

STEPHANIE: Interesting. But really, the way that's implemented is just, like, a definition of what aggregate means for Booleans, right?

+ +

JOËL: Right. But it's taking that idea of aggregating two values and scaling it up to an array of many values. So we know Boolean AND. Another way to think about it is, are both of these values true? Is the question it's trying to answer. And then we're scaling that out to say, is both of these values true for everything? So are all of these values true? Because we're going from two to many.

+ +

STEPHANIE: Cool. So maybe the takeaway for some of our listeners could be, like, next time they find themselves having to deal with a collection or an Enumerable and, you know, using a reduce or, like, trying to break it down to compare two of those elements first, and figuring out how they want that interaction to work. Does that sound right?

+ +

JOËL: Yeah, absolutely. Once you have a way to combine two elements together, if you want to scale it up to n elements, you just plug it into reduce, and it does the rest of the work for you.

+ +

My big takeaways from this exercise were one: the value of creating custom objects. Wrapping primitives like hashes in an object and adding a few domain methods on them made such a difference in my final implementation.

+ +

Secondly, I think it's what you're saying, this whole thing about breaking down complex reduce problems by figuring out how to combine two items and then just using reduce to scale it to an array.

+ +

And then, finally, I think this is a point that we've mentioned on this podcast before, the value of specific vocabulary - being able to name things and patterns. And so knowing some of the details of this monoid pattern and having a name for it means that now I start seeing it in places. And so the moment I see, oh, wait, we're aggregating values; we're combining two values together and then doing this in a reduce, immediately, my mind goes, wait, that feels like monoid. And then, I can explore that with my custom object to try to make the code better.

+ +

STEPHANIE: Yeah. And even if you don't remember the monoid part specifically, the idea of Tally, like, that is something that I think is really cool and really applicable to a lot of codebases.

+ +

JOËL: So, for those who are interested in more practically what this code looks like, I've put this all in a Gist, and I'll link to it in the show notes. This was a really fun exercise for me because I used sort of two development techniques to help sort of build this out.

+ +

One, I went with a kind of literate programming approach, where I had just a Ruby file and would have put in some big comment blocks talking about what the setup was, what I was trying to do, and then describing how I'd like to use the code, and then try to write code that made that happen. And then, for the actual objects that I was using under the hood, I used TDD to test drive and build them out.

+ +

So you've got all of that in the Gist. We've got the tests and that sort of literate programming script that almost reads like a mini blog post, except it's executable Ruby. So, if you're curious to see about that, the link is in the show notes.

+ +

STEPHANIE: That's a very cool format. I'm excited to take a look.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + If you're in the market for bicycle shorts, Joël's got you. Stephanie just returned from RubyKaigi in Japan and shares details of her trip.

+ +

Recently at thoughtbot, there have been conversations around an interesting data modeling exercise. Joël and Stephanie discuss the following:

+ +
    +
  • Value Objects vs. Hashes
    • +
  • Doing Math on Compound Numbers
    • +
  • Monoids and Folding
    • +
  • Naming Concepts in Code
    • +
+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've made an unusual purchase this week. I went out and bought a pair of bicycle shorts. And, for those who are not aware, these are special shorts that have padding built into them. Typically, they're, like, skin-tight, but I got, I guess, what are called mountain biking shorts. So, they kind of look more like the cut of a normal short. But they've got this, like, built-in padding for biking.

+ +

STEPHANIE: So. Just to confirm, you did get these shorts for biking purposes, right?

+ +

JOËL: Yes. I purchased these shorts for biking purposes.

+ +

STEPHANIE: Okay. [laughs]

+ +

JOËL: And I got these because I was talking to a friend about this and mentioning that this was, like, probably the most ambitious cycling thing I've ever done in my life. And they recommended if you have not done bike shorts, you really should get them. They make a big difference.

+ +

STEPHANIE: Wow. Okay, I have two thoughts here. First of all, you prefaced this saying that this was an unusual purchase. So I thought maybe that you bought these bike shorts for some other purpose. [laughs] But I am excited to talk about this because I've also been curious about trying bike shorts.

+ +

I bike a lot in Chicago in the summer, and I've been doing, like, longer rides on the Lakefront trail. And one of my goals, actually, this summer is to do a bikepacking trip. But I have not been super comfortable on longer rides. And I was just thinking that this might be something really helpful to make them a little more enjoyable.

+ +

JOËL: So, is the kind of biking that you're doing closer to what might be considered commuting?

+ +

STEPHANIE: Yeah, mostly commuting. But also, just, like, going on long rides on the weekends, in addition to this, hopefully, forthcoming bikepacking trip up to a state park. So not too long, maybe, like, 60 miles, but definitely long enough to start getting a little uncomfy on your seat.

+ +

JOËL: Yeah, is 60 miles, like, in one day?

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: That's a lot. Yeah, the friend who recommended biking shorts to me told me that pretty much anything over maybe 10 miles is worth getting shorts.

+ +

STEPHANIE: Wow, okay. I clearly have been suffering [laughs] for way too long, then. Tell me more about your cycling trip.

+ +

JOËL: So this is a bikes plus beer trip. Basically, I plotted a bunch of breweries in Belgium on a map and constructed an itinerary that could hit a bunch of them while keeping fairly short rides between towns. And the goal is to do maybe 30-35 miles in a day. And so I'll be going probably, like, cycling in the morning, and then exploring and drinking in the afternoon and evening.

+ +

STEPHANIE: That sounds amazing. That's really cool to do a little bit of a tour of the area and then also traveling by bike.

+ +

JOËL: Yeah, I'm excited because other modes of transport really just give you the origin and the destination, whereas cycling, you kind of get all of the in-between places. You get a much better feel for the area that you're in. And you can make all these unexpected stops if you want. You can make detours. So I feel like you get the sort of being in the moment, being in the place effect that you would have as a pedestrian but with a much longer reign.

+ +

STEPHANIE: Yeah, absolutely. That's exactly what I was going to say. I love cycling. And there's something really special about being able to be present in your surroundings and seeing people on the street or a cool building as you're going. But also going at a speed where it feels very fun and very freeing to just be cycling through a town and making stops when you want to, and traveling greater distances than you could be able to on foot.

+ +

JOËL: So I just received these bike shorts yesterday in the mail. So today, at the end of the day, I'm going out for a bike ride, and I'm going to see if they perform as advertised.

+ +

STEPHANIE: That's exciting. Keep us posted [laughs] on if you end up liking them or not.

+ +

JOËL: Yeah, yeah. The next episode or two, I'll have to report bike shorts; yay or nay?

+ +

STEPHANIE: Yeah, The Bike Shed will now become bike gear reviews.

+ +

JOËL: The name will actually line up, then with what the people googling, it might think it actually is. Stephanie, what's new in your world?

+ +

STEPHANIE: Speaking of vacation, I just got back from a two-and-a-half-week trip myself. I mentioned on the podcast a couple of episodes ago, I think, that I was traveling to Japan for RubyKaigi, an international Ruby Conference over in Japan. And then I spent another week in Taiwan, just on my own time. So, yeah, I had a really big, long trip, and it was really great. It was my first time going abroad in a really long time. It was my first time being somewhere where I didn't speak the language.

+ +

So, in Japan...I don't speak any Japanese. And it was both challenging and also, like, not too bad. I found my way around through a lot of gesturing and smiling, and nodding. [laughs] And, hopefully, people were able to understand what I was trying to communicate. Also, pointing at menus, I highly recommend going to places that have pictures of the food, and then you can just point when you want to order. [laughs]

+ +

JOËL: So, did you find that English was not particularly useful then in Japan as a tourist?

+ +

STEPHANIE: Yeah, I would say so. The next thing was that most signs were translated. So we ended up taking public transportation a lot. And that was quite easy to navigate, especially since I have kind of navigated subways in other cities before, and reading the signs is no problem. But when you're trying to communicate with locals, that was a little harder.

+ +

JOËL: Did you use any, like, apps on your phone or anything like that to help navigate kind of the different language?

+ +

STEPHANIE: Yeah, the Google Translate Lens app. I can't remember exactly what it is. But this was my first time really using it. And I was really impressed by how it was able to translate things that you're using your camera to take pictures of, or just, like, having your camera view. I did feel a little silly, like, holding my phone up to everything and trying [laughs]...so I could understand what I was reading. But for menus that did not have pictures, that was my backup strategy. [laughs]

+ +

JOËL: Did you ever have to have your phone translate something and then just show your phone to someone else?

+ +

STEPHANIE: No, I didn't have to go that far. Though I do think that it has a feature where you can have someone speak into the phone, and it will translate that into your native language. And then you respond by speaking into it and then playing the sound for them, which, you know, I bet really works in a pinch. But I think that required a little more investment into the interaction [laughs] with the other person than I was ready for. Like I said, the gesturing served me quite well.

+ +

JOËL: I got the experience of being on the other side of that a while back. So, here in Boston, I was just walking down the street, and someone stopped me and just holds up their phone. And they've typed something in Chinese on there. And they hit a button, and it comes in English.

+ +

STEPHANIE: [laughs]

+ +

JOËL: And they're asking for directions. And I think I typed a sentence back on their phone in English, and then they hit the translate button and got it back in Chinese. We went back and forth a few times. And eventually, I think he got what he wanted, and we went our separate ways. And I was kind of amazed that this whole interaction happened.

+ +

STEPHANIE: Yeah, that's really cool.

+ +

JOËL: Yeah, kudos to that person for having the courage to stop someone on the street when you don't speak their language.

+ +

STEPHANIE: Yeah, absolutely. I think even when I was struggling to communicate with someone because of the language barrier, I could tell from their gesturing in return that we were, like, willing to help each other out. And that, like, there was still an ability to find some kind of connection, even though, you know, we didn't completely understand each other. And that was definitely one thing that I really enjoyed was being in a place with, you know, people different from me and having that exposure. It's been a really long time since I've got to experience that, and that was really valuable.

+ +

JOËL: So, other than the conference, what would you say are some highlights of the trip for you, maybe one from Japan and one from Taiwan?

+ +

STEPHANIE: So one of my favorite things about being in Tokyo was all the green space that was around. I ended up walking a lot just to explore the neighborhoods. And I always just stumbled across a local park or even a shrine that had really great nature around it, a lot of big trees. You know, some, like, water features, maybe like a pond, and a lot of really fun plants that I got to learn about.

+ +

And, yeah, that was really nice, especially in such a dense urban area, like, coming across green space to just sit for a little while. And it was such a nice relief from the density and busyness of a big city. That was just one thing that I was really impressed by being in Japan.

+ +

JOËL: That's really cool. I think that really speaks to the quality of their urban planning. I know that the stereotype of Tokyo that I have in my mind is that it's, like, you know, ultra-modern, ultra-urban, you know, it's the largest city in the world. So the idea that they've taken the time to set up all these little parks everywhere is really endearing.

+ +

Particularly, I think the idea of smaller parks at the neighborhood level where you don't need, you know, something massive like, let's say, New York's Central Park, which is, you know, really cool. But having just a little green space in your neighborhood where you can, like, stop by, I think it's a wonderful upgrade to local people's quality of life.

+ +

I was recently listening to a video on YouTube from a city planning channel talking about just all the thinking that goes behind city parks, and having them at different scales, and how that impacts the residents of different areas. So it's really cool to hear that Tokyo has done a great job with that.

+ +

STEPHANIE: Yeah, absolutely. I think part of the joy of just stumbling upon it was that you know, even when I wasn't seeking it out, it would just come along during my walks. And, yeah, it really was very refreshing.

+ +

JOËL: What about Taiwan?

+ +

STEPHANIE: So, in Taiwan, what I really enjoyed about it it's a bit of a smaller island. And so you can actually get to a lot of places within a few days. And a lot of folks take day trips out to the coast from Taipei. And I was able to do a two-day trip to another county that had some hot springs, and I got to enjoy an outdoor hot springs in the rain. And that was really nice because it was, like, surrounded by trees.

+ +

And it happened to be raining that morning, but, you know, we were all kind of already getting wet, so it didn't really matter. And it was just, like, this really serene and gorgeous experience being able to enjoy that. And I think that was another place where I was in a very urban area, and then being able to escape a little bit was really nice.

+ +

JOËL: That sounds like a magical moment. Have you visited hot springs before, or was this your first time going to a hot spring?

+ +

STEPHANIE: I have been to a few in the U.S. before. I like to take road trips to national parks. And there are some really great hot springs in the U.S. as well. And so this was kind of something that I really wanted to do somewhere else just to experience it elsewhere. And, yeah, I'm really glad to have checked that off my bucket list.

+ +

JOËL: That's really cool. I've never been to a hot spring, and it sounds like a fun thing to do. So it's on my kind of greater bucket list. It's maybe not a top-five thing to do, but definitely, something I want to do one day.

+ +

STEPHANIE: Cool. Love it. That was vacation talk from Joël and Stephanie. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So recently at thoughtbot, we've been having conversations around this really interesting data modeling exercise, where let's say this is a company, and you want to purchase T-shirts for everyone at the company. You have already some T-shirts on hand because you've done this kind of thing before in a couple of different warehouses. And you need to know how many new T-shirts you need to order in order to have enough for everyone.

+ +

So as long as you keep things simple, the math is pretty easy because you sum the number of people at your company, and then you sum the number of shirts across all of your warehouses, and that gives you the T-shirts that you need, the T-shirts that you have. You get the difference between those two numbers, and that tells you how many new T-shirts you need to order. Where things get more complicated is once you start introducing T-shirt sizes, and that's where the fun data modeling comes in.

+ +

If everyone at your company has a T-shirt size that they want and then at your warehouses, you store...the object that represents a warehouse stores a hash of sizes and how many of each size you have. Now, how do you do all this, like, summing across things? And it's not really just a single number that you want. Now you need to know how many small, mediums, and larges.

+ +

And, sometimes, you've got a hash. Sometimes you've got just symbols on a user, and you've got a sum across hashes. Maybe do some differences across hashes. And it gets kind of tricky to work with. So that's sort of the problem as it's initially presented. And we've been having a really interesting conversation around different ways to try to solve it in a way that's really kind of clean and nice.

+ +

STEPHANIE: Yeah, that's interesting because what you described sounds like the first iteration of solving the problem is, oh, the warehouse stores this information as a hash. So maybe I will create a new hash for the counts of T-shirt sizes that I need and then do the comparison on those two hashes. It sounds like maybe there was some unwieldiness or maybe even some duplicated code there. Is that what you think you all were trying to solve by modeling this differently?

+ +

JOËL: I think we kind of quickly hit some limitations with hashes. One thing that is fun before we start trying to combine a bunch of hashes is that some of the data exists as a hash on the warehouses. But to get the T-shirts that we need, all we have are an array of users and a size on all of them.

+ +

And we can use this fun method from Enumerable called Tally to give us a kind of Tally hash that is just a mapping of size, two counts of that size in the array. And so that's a really fun method. You don't get to bring it out that often in Ruby. And it's nice because that hash format happens to match the same format as the hashes stored on the warehouse objects.

+ +

STEPHANIE: Right. So now you're comparing apples to apples. But it sounds like maybe this hash representation does hold some kind of significance.

+ +

JOËL: Yeah. I guess, for me, I tend to see anytime you're doing fancier operations on a hash more than just reading in and out; it probably wants to be some kind of value object. And, in this case, we kind of want to do math on hashes. I think the equation is kind of still the same thing. We're trying to get the difference between the two, between the want versus have, but you can't just subtract one hash from another directly.

+ +

There's some things that you can do with the hash merge method that allows you to pass a custom block and do some things there. But we're going to have to do this sort of repeatedly. And now we're kind of leaking some of that knowledge a little bit. So it feels like something where you might want to actually name this concept and make it an object of its own that can then have its own kinds of domain operations as methods on it.

+ +

STEPHANIE: Yeah, I like that a lot. Because even just as I was thinking about it when you are storing data like that in just a hash, what do you call it? Like, what do you name it? I think I've seen things like that named, like, T-shirt data, or, like, warehouse data, or warehouse T-shirt counts, or T-shirt counts. You know, that is when it starts to diverge, and you end up maybe seeing the same, like, data represented, but it being named different things in different parts of the code. And I, in experience, have found that very painful.

+ +

JOËL: Yeah, because I guess you could have, like, T-shirts on hand from your warehouse; that's one hash. But the hash generated from the users might get called something like user preferences. And if you're reading through that code and you see a hash, and you're like, okay, do these two hashes that I'm looking at, maybe in a test, just kind of coincidentally have the same keys? Or are these kind of fundamentally the same thing? Or is the idea of, like, T-shirts on hand like a stock different from, like, a preference? And do they represent different things that just happen to be similar in this particular scenario?

+ +

STEPHANIE: Right. And especially if then there are methods where you're passing that data structure that really represents the same thing. But you're passing it as arguments, and then, suddenly, one variable name, user preferences, or user T-shirt preferences becomes, you know, T-shirt count. That has been really confusing for me before.

+ +

JOËL: One thing that does get, I think, clunky very quickly is that you have all of these warehouse objects that have that hash of, like, stock on hand on them. And what you really want is a kind of aggregate object that tells you not what's the stock on hand for one warehouse but across all warehouses. So you've got to go through, I guess, that array of warehouses and somehow kind of aggregate all of those hashes together. And because they're already tallies, you can't just do Enumerable Tally on it anymore. You've got to find some way to combine them together, and that gets tricky really quickly.

+ +

STEPHANIE: Right. I can see they're starting to be, like, nested loops, especially if you're just working with primitives.

+ +

JOËL: I think some initial implementations that we saw ended up doing either, like, some kind of reduce block or each_with_object, or something like that, which are, I think, fine solutions here. But what lives inside of those blocks is what gets complicated. And I don't know about you, but I feel like if I'm reading through some code and then all of a sudden I see a reduce block, and it's, like, ten lines of logic with maybe some, like, nested things, like, maybe some nested loops or some conditions inside of it, that's kind of intimidating. Reduce is not a super easy method to wrap your head around, especially when the block has got a lot of logic.

+ +

STEPHANIE: Yeah, that's a really good point. It definitely gives me pause. And I have to, like, you know, commit to reading the method in its entirety to fully understand [laughs] what's going on.

+ +

JOËL: Sometimes, like, really pause and, like, annotate with comments and all this stuff.

+ +

STEPHANIE: So, what did you end up thinking about in terms of solving that problem of aggregating the sums of all the different T-shirt sizes for each warehouse?

+ +

JOËL: So I think, for me, oftentimes, it's easier to make the problem a little bit smaller, solve that smaller problem, and then try to kind of scale up back up again and particularly when you're dealing with something like reducing or aggregating a large collection. Like, forget about dealing with a collection. Just how could I combine two items of this type? So if I had two of these hashes. And forget about fitting it for an array. But if I have two of these hashes, how could I combine them together?

+ +

And you could do this with hash merge. I wanted to do things a little bit more encapsulated. And because I also knew that we're building some more logic around these, I actually wrote a custom object. I called it a tally, maybe inspired by that Enumerable method, and implemented an operator plus on this tally object. So a tally object can plus another tally object. And the response from that is you get a third tally object that's gone through all of the keys and summed them together. So it's kind of an aggregate sum.

+ +

STEPHANIE: This is a cool example of a method that's a verb also representing a noun to name the return value, right? So the Tally method on Enumerable returns a hash, which we have been talking about for a while as, like, a data structure that's, you know, perfectly fine, but maybe we can leverage turning it into like you said, a value object to give it more meaning or to make it easier to work with. And it seems like the naming part just kind of fell into your lap.

+ +

JOËL: Yeah, tally is interesting in that it is both a noun and a verb in English. I'm not sure what the grammatical term for that kind of word is.

+ +

STEPHANIE: So, once you extracted this new class out, what insights or observations did you have about this problem?

+ +

JOËL: What becomes really cool about this is that once you have a way of combining two objects together, reduce is a way to just kind of scale that up to an arbitrary number. And so, just like you can sum an array of numbers by reducing plus over the array. Because I have plus on my tally object, I can reduce plus operator over an array of tally objects. And they all just kind of sum together in a single tally that's the combination of all of them. So this is really cool.

+ +

What used to be an intimidating reduce block, the intimidating logic gets moved into a plus method, which I think is much more approachable. Because I can go in the context of an object and say, okay, I've got this tally object, and I'm trying to add it to another tally object. And we're just going one key at a time, adding them together. Simple enough.

+ +

And then in the place where we're reducing, all we're saying is list of tallies reduce plus. And I know that pattern already because I do it with integers to sum them together. And so now I've just got this really simple one-line in the scary part. And the actual complex logic is much more approachable.

+ +

STEPHANIE: That is very cool. I found it really interesting that this came about because we were trying to do math on these two hashes. So it seems like, you know, a tally because it represents a score or, like, a number. Like, we were able to implement those plus operators and get to a simple solution because we're working with numbers.

+ +

JOËL: Yeah, I think it might be fair to describe it as maybe a compound number is the term that I use. I don't know if that's mathematically correct. Oftentimes, when you're dealing with things that represent a number or something that's represented numerically but that might have more than one number involved in it. But you still want to do math with this kind of compound, multi-number value anyway.

+ +

And one example that you might have is, let's say, a point in 2D space. You have an X coordinate and a Y coordinate. And you can do math on points. In fact, there's a whole field of math to deal with that kind of thing. That's an important thing that you have to do. You might want to be able to add or subtract points. You might want to do certain types of multiplication on them. And so just because something has more than one number associated to it doesn't mean that it can't be used for math. In fact, oftentimes, that's where the fancier math does come into play.

+ +

But when we treat them as primitives, and we just have, let's say, our XY pair was a hash, or, like, a two-element array, then we lose the ability to do math nicely. If we create, let's say, a point class that has an X and Y, and then we define plus, we define minus, we define scalar and vector multiplication, things like that, now we can do all those operations. And we can treat it like math, even though it's not just a simple integer anymore.

+ +

STEPHANIE: Yeah, I like that a lot because we do end up working with data, you know, maybe even from our database. But then, inevitably, we want to, like, learn something about it. And so I was thinking about how frequently I use GROUP BY in MySQL queries and how, oftentimes, I care about counts, or, like, number of records.

+ +

And perhaps this is why we see, like, the hash primitive used so frequently in codebases that then become pretty complicated once we're trying to, like I mentioned, like, learn something about it or, like, compare things or whatever logic that we need to do. And transforming them into objects that then know how to do math on themselves [laughs] is very cool.

+ +

JOËL: Hashes are interesting because they're pretty much just basic data structures. And I think, very often, they're sort of pre-objects. They're things that want to eventually become objects. And, oftentimes, what I find is that hashes get passed around a system. And various other classes or subsystems all have bits of logic that act on the hash because the hash can't own that.

+ +

And so you end up with the logic around the concept of whatever the hash represents kind of scattered and maybe duplicated across three or four places in the application. And then, all of a sudden, if you give that a name, if you create a class for it, you can pull all of that logic into one place. And, all of a sudden, it probably cleans up all of the surrounding places because now they don't have to care about the implementation of exactly what operating on the hash is.

+ +

But, also, it means that these operations generally have, like, nice domain names. And, in the case of a complex number, you might even have that represented through math operations, like, plus or minus. And that allows your code to read really nicely.

+ +

STEPHANIE: Right. Which gets me thinking about how I mentioned, like, tally as a noun, and, you know, you implemented your custom class. But do you think there's any value in the idea of a tally being specifically like a hash-like thing with a number as the value for each key, like, that existing as a more general class for people to use?

+ +

JOËL: Oh, that's interesting. So, in my personal implementation, I hard-coded values for small, medium, and large because those were the T-shirt sizes from the example. But you're talking about some sort of generic tally object that maybe would be a gem or something like that that people could use that represents counts of arbitrary things or multiple counts of arbitrary things that might then implement some common math operators so that you could add or subtract them.

+ +

STEPHANIE: Yeah, exactly. Because I was just thinking, you know, like I mentioned, I often represent that when I count number of records in my database. Or even I can recall a problem that I encountered previously where I had to figure out the number of orders for an e-commerce store based on the location. And I held that in a hash data structure, but really, it's a tally. [laughs] And so, yeah, I think that maybe we've kind of stumbled across a very useful representation of very common problems.

+ +

JOËL: Yeah, I can see there being use for a generic version of this. Maybe that's your chance to go out and create some open source, or maybe this already exists. We should maybe research that first.

+ +

STEPHANIE: Yeah, if any one of our listeners know, [laughs] send us an email.

+ +

JOËL: So something that was really interesting to me about all of these changes, introducing the value object, cleaning up the reduce, all that stuff, is that, in the end, once the...there was this object that represented the sort of aggregate compound value, the tally, then the equation stayed the same. And I can just slot in those variables as before.

+ +

Whereas previously, when we switch from just a single count to this, like, we need to take into account sizes that, like, broke the initial implementation of the code. So it's funny how you sort of go from a simple implementation and then a new requirement, which breaks it. But then just changing the hash to be an object all of a sudden made the original code, which didn't really need to change; it just worked again.

+ +

STEPHANIE: Hmm. That's really interesting because it makes me think about how maybe the primitives were perfectly fine, you know, in the first set of requirements, and not until, like, an additional complexity or something new emerged that we needed to reach for an object that could support the change.

+ +

JOËL: Yeah. And I think I'd argue that if you're doing just raw T-shirt count, an integer is probably the right value to use there. But if you're doing counts broken out by T-shirt size, then having an object that's a single thing that responds to plus and minus so that you can use it in the same equation where you're saying sum up all of these things from the warehouse, and then do a difference with the T-shirts that we need that becomes really nice.

+ +

STEPHANIE: Do you think there was some value in going through the hash implementation first, though, and then arriving at using a more custom object? I'm curious, kind of, like, what that journey was like.

+ +

JOËL: It's hard to say. I would say maybe yes. But I could also see someone who's done this a lot, who's built the sort of heuristics, the instincts around this could immediately be like, oh, wait, we're trying to sum hashes here. Clearly, these need to be objects. Clearly, what we need is something that implements a plus operator that we can reduce.

+ +

STEPHANIE: Yeah, I like that a lot. Because part of, you know, knowing what to reach for is having seen it enough times and seeing patterns, right?

+ +

JOËL: This reminds me of a particular pattern that comes from the world of functional programming. It has a kind of scary-sounding name. It's monoid, not monad, monoid. And the idea in the context of Ruby is it's some kind of object that implements a plus method. So two of these objects can combine each other. And typically, you also have some sort of empty version of this object or some sort of, like, zero value.

+ +

And there's a few rules that go around, like, kind of how this object has to behave. Like, you can't just put any implementation you want in that plus method. Certain requirements that have to be met for it to be considered, like, a valid plus method in this pattern. But if you do meet those requirements, then arrays of this type of object are just inherently reducible because you can just reduce plus over them.

+ +

And so I think anytime you're trying to aggregate some sort of unwieldy data structure, that's probably a useful pattern to have because, you know, wait, as long as I have a way to combine two items together and potentially some way to generate an empty state, I can aggregate this whole list.

+ +

STEPHANIE: I'm curious, does that also apply to non-numerical values?

+ +

JOËL: Yes, any kind of aggregation combination, whatever. So maybe what you're doing is you're combining strings together.

+ +

STEPHANIE: Got it.

+ +

JOËL: String concatenation is a form of combination. And so you could be reducing some kind of concatenation over an array of strings, and you end up with one aggregate string that's the combination of all of them. Sometimes, though, you're not just taking values and putting them next to each other so that what you have is kind of all of them at the same time. You might instead do some kind of comparison.

+ +

An example here might be Boolean values. You might say the way that I'm sort of, quote, unquote, "aggregating" two values, two Boolean values is with the operator AND. And so you have two Boolean values, and you get a new sort of combo value out of them, that is, are both of these values true?

+ +

STEPHANIE: Whoa, that's blowing my mind right now. Because I had never thought of the, like, AND operator on Booleans, essentially aggregating them into a single true or false value. [laughs]

+ +

JOËL: It's kind of weird, right? But I guess we do the same thing with numbers. One plus one doesn't give us 11 unless you're writing JavaScript.

+ +

STEPHANIE: [laughs]

+ +

JOËL: You know, we get a new number too, that is some sort of, like, combination of the two. So, similarly, it kind of makes sense that two Booleans might combine to create a new sort of third Boolean value. Where it gets really interesting, though, is that once you have this sort of combination, if you try to reduce AND over an array of Booleans, what you effectively have created is Ruby's Enumerable all method that checks to say, are all values in this array true?

+ +

STEPHANIE: Interesting. But really, the way that's implemented is just, like, a definition of what aggregate means for Booleans, right?

+ +

JOËL: Right. But it's taking that idea of aggregating two values and scaling it up to an array of many values. So we know Boolean AND. Another way to think about it is, are both of these values true? Is the question it's trying to answer. And then we're scaling that out to say, is both of these values true for everything? So are all of these values true? Because we're going from two to many.

+ +

STEPHANIE: Cool. So maybe the takeaway for some of our listeners could be, like, next time they find themselves having to deal with a collection or an Enumerable and, you know, using a reduce or, like, trying to break it down to compare two of those elements first, and figuring out how they want that interaction to work. Does that sound right?

+ +

JOËL: Yeah, absolutely. Once you have a way to combine two elements together, if you want to scale it up to n elements, you just plug it into reduce, and it does the rest of the work for you.

+ +

My big takeaways from this exercise were one: the value of creating custom objects. Wrapping primitives like hashes in an object and adding a few domain methods on them made such a difference in my final implementation.

+ +

Secondly, I think it's what you're saying, this whole thing about breaking down complex reduce problems by figuring out how to combine two items and then just using reduce to scale it to an array.

+ +

And then, finally, I think this is a point that we've mentioned on this podcast before, the value of specific vocabulary - being able to name things and patterns. And so knowing some of the details of this monoid pattern and having a name for it means that now I start seeing it in places. And so the moment I see, oh, wait, we're aggregating values; we're combining two values together and then doing this in a reduce, immediately, my mind goes, wait, that feels like monoid. And then, I can explore that with my custom object to try to make the code better.

+ +

STEPHANIE: Yeah. And even if you don't remember the monoid part specifically, the idea of Tally, like, that is something that I think is really cool and really applicable to a lot of codebases.

+ +

JOËL: So, for those who are interested in more practically what this code looks like, I've put this all in a Gist, and I'll link to it in the show notes. This was a really fun exercise for me because I used sort of two development techniques to help sort of build this out.

+ +

One, I went with a kind of literate programming approach, where I had just a Ruby file and would have put in some big comment blocks talking about what the setup was, what I was trying to do, and then describing how I'd like to use the code, and then try to write code that made that happen. And then, for the actual objects that I was using under the hood, I used TDD to test drive and build them out.

+ +

So you've got all of that in the Gist. We've got the tests and that sort of literate programming script that almost reads like a mini blog post, except it's executable Ruby. So, if you're curious to see about that, the link is in the show notes.

+ +

STEPHANIE: That's a very cool format. I'm excited to take a look.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+B5BZNIRu + + ]]> + + Joël Quenneville + Stephanie Minn + + + 385: The Boring Parts of Tech + https://bikeshed.thoughtbot.com/385 + 0b61f64a-4abe-4704-ad85-b1c8d63913d4 + Tue, 23 May 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël is joined by thoughtbot Software Developer and Dirt Jumper Daniel Nolan. Dirt jumping is BMX-style riding 🏍️ with really enormous dirt jumps. + +But for a person who loves excitement in his spare time, for Daniel at work, it's not the new and shiny that interests him. When he dives into something, the "boring" parts of tech are what he finds most fulfilling. He wants to know the "why," and in this conversation, he explains how it sustains his career. + 24:41 + no + + + Joël is joined by thoughtbot Software Developer and Dirt Jumper Daniel Nolan. Dirt jumping is BMX-style riding 🏍️ with really enormous dirt jumps. +But for a person who loves excitement in his spare time, for Daniel at work, it's not the new and shiny that interests him. When he dives into something, the "boring" parts of tech are what he finds most fulfilling. He wants to know the "why," and in this conversation, he explains how it sustains his career. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Debugging series (https://thoughtbot.com/blog/debugging-series-2021-welcome-to-the-jungle) +Dependabot (https://github.com/dependabot) +Coverband (https://github.com/danmayer/coverband) +thoughtbot maintenance service (https://thoughtbot.com/services/rails-maintenance) +Sentry (https://sentry.io/welcome/) +New Relic (https://newrelic.com/) +Custom Rubocop rules (https://thoughtbot.com/blog/rubocop-custom-cops-for-custom-needs) +Daniel Nolan Twitter (https://twitter.com/danielnolan) +Daniel Nolan GitHub (https://github.com/danielnolan) +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. And today, I'm joined with a guest, Daniel Nolan. +DANIEL: Hey. +JOËL: And, together, we're here to share a bit of what we've learned along the way. So, Daniel, what's new in your world? +DANIEL: So, recently, I just picked up a dirt jumper bicycle, and I've been learning to get better at dirt jumping. I ride mountain bikes quite a bit. But jumping is something that I haven't been super comfortable with. +JOËL: What is dirt jumping? +DANIEL: So, Dirt Jumping is kind of more like BMX-style riding with really huge dirt jumps. If you do it right, you don't pedal. So you should be jumping and pumping and making your way around the track or the course without the need to pedal. So it's actually pretty interesting. And it's supposed to level up your mountain bike skills if you get good at this. +JOËL: So the idea is you start up high somewhere, and you just kind of let the gravity bring you down? +DANIEL: Yep, that's the idea. So you start up on a platform; usually, you drop in. And then, from there, you start the series of jumps or rollers, pick up speed, and then kind of go into some bigger jumps, and berms, and stuff and make your way around the course. It's pretty fun. +JOËL: So you're coming down from a high, and then you hit a dirt ramp somewhere. You go up in the air. You fly off, and you're doing, like, a flip or something like that? +DANIEL: Yeah, not quite there yet. Some of the people I ride with can do flips, and no handers, and stuff; definitely not there, but just getting comfortable on big dirt jumps. I think the scariest thing is not being able to see the landing. So it's, like, if it's just a little jump, like, you know where you're going. But if it's like one of those big jumps with a huge lift, you just have no idea what's on the other side. And no matter how, you know, even if you've hit it ten times, it's still scary because you can't see it. +JOËL: How do you land safely when you can't see your landing place? +DANIEL: There's a technique where you kind of push the bike down. So, like, once you're in the air and you've kind of leveled the bike out, and you spot the landing, you force the bike down to kind of accentuate that movement and make the bike go down. +JOËL: Just so I get a better mental picture here, how high up are we talking about when you're flying off this ramp? +DANIEL: So some of these dirt jumps are probably...on the ones that I'm riding, they lift to probably, like, you know, eight, nine-feet high, and you're probably getting, like, three to four feet in the air over that to clear it. +JOËL: Wow. That's a little bit of elevation right there. +DANIEL: Yeah. +JOËL: I would probably be scared. +DANIEL: The safe jumps have what they call a table on top, so there's no risk. Like, if you land on top of the jump, you're not going to die. But, yeah, typically, they're flat on top. So you have to have enough air and enough momentum to clear that flat part and land on the downside. +JOËL: I like to do a lot of bouldering. In this case, I do it in a gym, so you're climbing up a wall that's maybe 15 feet high. Even at that height, I feel a little scared; not very good with heights. How do you feel when you're up 15-20 feet on a bicycle, and you don't know where you're going to land? +DANIEL: It's scary. I mean, just, there's no way to get around it. But that's the whole reason I started getting into the dirt jumping is just try to get it to where it's more second nature, and you're not so terrified. +JOËL: Kind of pushing some of your personal limits, then. +DANIEL: Yeah, for sure. +JOËL: So it sounds like you're introducing a lot of excitement and novelty in your personal life. And that contrasts to a recent conversation that we had where you'd mentioned that, at work, it's not the kind of shiny, new tech that excites you, or even kind of the scary parts. But you find that the boring parts of tech are what are most fulfilling to you. +DANIEL: Yeah, I actually really do like diving into the more boring parts. And I think to give just a little history about myself and maybe why that might be, I'm a second career programmer. My original career, or what I thought was going to be my lifelong career, was I was an auto mechanic. So I was a certified VW tech in my early 20s. And I've always kind of had this passion for, like, why things are. I want to know why something is. So, when I dive into something, it's like, I want to know the why. I don't want to just know what the fix is. I want to know why that thing fixes it or whatever. +So I find that getting into the more boring parts of programming, and especially in the Rails stack, allowed me to do this. So, for example, like, a gem that Dependabot can't upgrade, and it just sits there. The PR just sits there, and nobody wants to touch it. So then I come along, and I'm like, well, why won't it upgrade? Why can't we upgrade this thing? And I start diving into sort of breaking changes. Is there stuff like that? +So fixing things, for me, has been something...since I was just a little kid, my mom said I always used to take things apart and put them back together. I always want to know the why. Doing some of the more boring stuff, you get to do a lot more of that. +JOËL: So it sounds like really you're motivated by curiosity pretty strongly. +DANIEL: Yeah, for sure. I don't want to just know what a quick fix is or something like that. I want to actually get in. I want to read this, you know, like, an example, like, a gem that won't upgrade, like, I want to go dive into that source code. I want to see what the source code is doing. I want to figure out the why, you know. I don't want to just Google for, like, hey, I can't upgrade this gem. What do you think I should do? So I've always been super curious. That's how I've been able to sustain in software development and not really get burn out. It's what makes me tick. +JOËL: How do you feel about bug fixing or, like, chasing down bugs in general? Is that something that really scratches that itch? +DANIEL: It definitely does. I feel it's, you know, very similar to somebody comes to you, and they've got a broken car. And they're like, "Hey, this thing's making this noise when I'm going down the highway at 50 miles an hour, you know, what is it?" You know, it's very much the same thing. Like, you get an end user, and they're like, "Hey, when I click this button in the browser, and, you know, this thing doesn't load," or, you know, I'm getting a 500 error." It's very relatable. I love diving into those type of things. Like, I love fixing bugs. +JOËL: It's interesting that you related that back to your work with cars because it sounds like you were doing sort of the mechanical version of debugging. +DANIEL: Definitely the mechanical version of debugging. But it's still...it's a lot of the same stuff. It's a lot of process of elimination and stuff like that, right? Like, you got a noise coming from the front left. It could be anything, you know, it could be the wheel. It could be brakes. It could be, I mean, there's a number of things it could be. So you kind of got to start going down the path of like, you know, well, it's not this, and it's not this, and it's not this. +And it's very similar when you have a bug, you know, and you start down the path of, like, oh, well, I can click the button. The post is getting sent to the server. But, for some reason, you know, the parameters aren't going past the controller or something like that. So, you know, you maybe go look for some primitive params or something, I don't know. But it's very similar as, you know, just going through the process of, like, checking things off and trying to get to the root cause. +JOËL: Yeah. So, when you joined software, you already had this skill kind of really built up pretty well. +DANIEL: Yeah, I definitely did. Being a mechanic, a lot of times, I would get, like, the problems that nobody else wanted to deal with. Because people were like, oh, he likes troubleshooting electrical issues and stuff like that, so give it to him, you know. Whereas the other mechanics are just, you know, like, were more, like, oh, I want to rebuild the engine, or I want to put a new trans...like, it visibly needs an engine. +Like, oh, there's a rod through the side of the block. It's leaking oil everywhere. Okay, yeah, like...versus, oh, it's got some electrical bug where, you know, one injector doesn't fire every 50th time, or something like that. And something that you just really have to, like, trace down and figure out why it's not happening. So I feel like I had a pretty good, no pun intended, toolbox coming into... +JOËL: Nice. +DANIEL: Software development as far as just problem-solving skills, I guess. +JOËL: It's interesting. A few years ago, I interviewed a bunch of people about debugging and the parts they liked, the parts they didn't like, hopes, and fears. And most people I talked to actually enjoyed debugging, except that, oftentimes, when bugs come up, it's because they're blocking something else. And there are time pressures. +And so all that extra context is what makes debugging stressful for most people that I talk to. But the actual act of debugging, that kind of process of elimination or trying to hunt down the source of a bug, many people I interviewed actually found that highly fulfilling. So it sounds like it taps into a lot of the same interests that you have. +DANIEL: That's super interesting, yeah. And it is fulfilling, too, right? Like, you're going this hunting, and you kind of, like, put on your detective hat and go try to, like, figure out what the breaking thing is. And then you get the payoff also of like, okay, well, you know, if you actually fix it, you resolved it, and you get that little bit of payoff. +And I think for any job for me to be fulfilling, I have to have that kind of that payoff where you start with something broken, and you fix it. You know, you start with an empty editor, and then you build out a web application or something like that. So it's just, like, having that payoff is definitely huge. You know, I just find that part of software development super fulfilling. +JOËL: So you've mentioned debugging. You've talked a little bit about gnarly gem upgrades. What other types of work fit under that boring part of software heading for you? +DANIEL: Putting in some tools for best practices maybe, you know, like setting up linters and stuff like that, automated code review kind of things. It's stuff that you tend to see, like, teams and stuff want, but they just never have the time. They're always building, you know, new features and stuff. So I think a lot of that stuff, like, gets pushed by the wayside. Refactoring code that's good enough. It's good enough, and it's working, but it could be a little cleaner, a little easier to read; kind of enjoy that, too. I don't know, do you have any things that you would consider boring programming work? +JOËL: I think some types of features sometimes can feel boring, maybe a little bit beyond boring. It's scary or unpleasant to work on. Sometimes there are just parts of the code that are really gnarly to work with. I'm like, oh no, I've got the ticket that requires touching some of that gnarly code in a particular part of the app. There's one app, in particular, I'm thinking of that this was the wizard code, or the multi-step form processing code that had gotten really gnarly, and so nobody wanted to touch it. And if you had a ticket that required touching that code, it's like, oh no, you drew the short straw. +DANIEL: Yeah. I've definitely had experiences like that. I had a feature I worked on at a previous job where it was...the feature was referred to as the black box because nobody knew how it worked. Nobody knew what it actually did. But they knew that it didn't produce the results they wanted. And they knew it needed to be refactored, so that was definitely one. I don't even know if I would say that was boring, but definitely, a scary part that nobody wants to touch. +There's just all kinds of stuff that's boring. Like, if you're just constantly adding new features and doing new things, and adding to the app, there's code that's probably not used anymore. So using something like Coverband and going in and finding unused code and cleaning out that kind of stuff. Optimizing queries, again, you know, you build something, and it works. It's there. It's doing its thing. And nobody's complained that the endpoint's slow. But when you run it, you notice that there's like, you know, 70 N+1 queries. So you go, you know, you go touch that up a little bit. +I feel like a lot of people and a lot of programmers just don't want to do that work, or it may not even be that they don't want to do that work. It's just a lot of times; there's maybe no time for it. So that's no fault of anyone in particular. But I think we need to, you know, figure out a way to make some more of these things fun. Maybe more teams need to build in, like, gem upgrade day or something. And, you know, like, go upgrade the ones that are hard to upgrade. Upgrade the ones that Dependabot can't, that have breaking changes. Or, I don't know, there's got to be some way where we can make some more of this, like, the tasks that keep the car running more enjoyable, right? +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: Would it be fair to describe the types of work that you've been talking about here, you've been describing as the boring parts of development, would it be fair to put those under the heading of maintenance? +DANIEL: I think it would be fair to put it under maintenance, maybe even relating that back to cars. It's the same thing, right? Like, you can put a new paint job on the car, and you can get some new, shiny wheels. And you can, you know, put a turbocharger on it or something but, eventually, you know, you got to change your oil. You got to change your tires. You need to change your air filter, new windshield wipers, you know, so you can see when it's raining. +These things are all just things that need to be done. Otherwise, no matter how shiny your car is, it's just not going to go anymore, right? So I feel like maybe most of these tasks are maintenance. It's not the shiny, new thing. It's just keeping the thing running. +JOËL: And, I guess, traditionally, at thoughtbot, we've done engagements where we're either building new software or new features on existing software. Or we might be coming in and fixing some larger problems, maybe doing something like helping with a Rails upgrade or helping to backfill a test suite, some larger kind of chronic problems. +But we recently introduced a maintenance service that is, instead of having people full-time there to do a particular task, it's more of so many hours a month to just do a lot of those boring things where we're doing like you said, potentially gem upgrades, or fixing bugs, or things like that. Is that a team that you would be interested in joining? +DANIEL: So I actually got to work with Jeanine and [inaudible 16:05] on support and maintenance for about a month, month and a half maybe. I worked on an upgrade. And that's exactly what I did. It was upgrading a Rails 5.2 app to Rails 7. And yeah, it was not only super fun, but the other fun side of that, for me, is that a lot of times when I'm doing these things, and you find breaking changes, the gem is either, like, ten years old, and it can't be upgraded because there's nobody maintaining it anymore. So you maybe have to create a fork, or you maybe submit a patch or something. +So this is a way that I've been able to get, you know, my feet wet in open source without really contributing to a specific open-source project. So I have tons of little commits on different gems here and there fixing stuff up or something I found along the way that couldn't be upgraded or something like that. So yeah, the support and maintenance team is definitely something that I'm interested in, and I had a good time working with them for that rotation. +JOËL: And I think it's really interesting you're talking about the pattern of open-source contributions that you were having. And I think that's something that's really valuable to the community, just those little patches in various places because it's broken or is no longer compatible with other things. What you're doing not only helps unblock you and your client but also is probably unblocking a lot of other people in the community, so might have a larger impact towards other people than if you were putting all of your time into contributing to one more well-known gem. +DANIEL: Yeah, for sure. You know, I know for sure, like, some of them I have a commit on Honeybadger, something that broke recently, a Sidekiq upgrade that broke, and there was just a small change to the way the error handling worked. And it was, like, causing just this flood of errors. And it was just a simple change. But I'm sure not only did it fix it for us and the app I was working on, but, yeah, I'm sure quite a few people benefited from that one. +JOËL: So, for those listeners out there who are hearing you talk about some of this maintenance or boring work and maybe are feeling inspired to go and do that on their team, how would you recommend getting into that? +DANIEL: Well, I mentioned Dependabot. If your team's already using something like Dependabot for, like, minor gem upgrades, maybe there's a PR that's stuck that Dependabot can't upgrade because there's some breaking changes in one of the gems it's trying to upgrade. That's a great place to start. You could run, I believe; it's bundle-outdated. And that will tell you what gems are in your gem file that are outdated and need to be updated. +So any of them that are going to be major version bumps, you know, going from, like, two to three, typically, you'll usually have breaking changes somewhere you can kind of jump in and go fix those breaking changes. Maybe there's even breaking changes in another gem that may be related or something that you're trying to upgrade. And, you know, you can't upgrade past version two because the new gem you're trying to upgrade depends on that gem-specific version or something like that. So I feel like that's a great way you could jump in. +Maybe some other ways would be if, you know, maybe you want to optimize queries or something like that. Maybe you have Sentry or some other type of software that reports on these things, New Relic, you know, so something like that you could go dive into and pick up an endpoint that's responding slow or something that has some N+1s being reported and go dive in, see if you can maybe touch those up. +JOËL: Those are all great suggestions. I know I once worked with a developer who would dedicate...I think it was the first hour of his day. So he'd come into work in the morning, and before jumping in on feature work, the first hour of his day, he would just do small improvements on things and not just, like, refactoring for the sake of refactoring. But they're things like you're describing, like, oh, do we have a gem that needs to handle an update? +Did one of our monitoring services highlight maybe some slow queries that I could tweak a little bit this morning? Or are there areas where we're feeling pain that we can make things better? And just by doing a little bit every day, he became known as the person on the team who is, like, having an impact, and making everybody's lives better, and making the codebase better, making the product better. And I really appreciated this person. +DANIEL: Yeah, sounds like an angel. Like I was saying, you know, I kind of hinted out a little bit before...I think these things...and it could be because they're boring, or it could just be because you have stakeholders that are, like, hey, we need to get this new feature out. And I just feel like a lot of this stuff definitely gets pushed to the back burner often, so figuring out a way to incorporate some stuff into your day like that, or automating some of it, you know, using things like Dependabot and stuff like that. I think they're all just great ways to keep the app or the project in good shape. +Another thing that I've done adding custom RuboCop rules to enforce things the way that you want them. So, like, it comes with a standard set of rules, but you find some pattern that's being, you know, repeated, and we don't want that pattern repeated. You know, spend the time to write a RuboCop rule so that that pattern doesn't get repeated. And you don't have to constantly police this in PRs, you know, you let the automated tool do it for you. But I've never really heard anybody get super excited about writing a Rubocop rule. +JOËL: And they're valuable. +DANIEL: Yeah, they're definitely valuable. +JOËL: I think the most excited I've seen people get about RuboCop rules is typically as part of an incident report. So something went terribly wrong, and maybe production went down. And then you're doing a post-mortem, and then you realize, oh, in this way, some bad code made it through. And you decide how can we prevent this from happening again? And the consensus is, oh, maybe a Rubocop rule would have prevented this. So I think that's generally where people actually start caring about a Rubocop rule is after there's been some larger incident. +DANIEL: Sure. We had something where I think, like, we first started using system specs on an app I was working on, and some people were using Path Helper, and some people were using URL Helper. And, for some reason, the ones that were using Path Helper would fail randomly. I don't really recall right off the top of my head why, but we wrote a RuboCop rule to just enforce using the URL for or the URL Helper instead of the Path Helper just to enforce that rule. So we didn't have to constantly police it, and it just made everybody's lives easier. +Figuring out a way to set some time aside for this stuff or automating this stuff is definitely beneficial because you may not always have somebody on the team that's interested or that wants to champion this stuff. +JOËL: Hey, you mentioned the word champion, and I like that word because it's the kind of thing that often doesn't get prioritized. And so you need somebody to advocate for that work getting done. And, generally, I've found this work is often cheaper to do sooner rather than later. If you postpone it too long, and now it's been ten years, and you've not done a Rails upgrade, and your app is still running on Rails 3. It's going to be very expensive to do that work. +DANIEL: Yeah, the biggest cost of software is maintenance is definitely true. +JOËL: Maintenance is valuable work, and we should celebrate it more. +DANIEL: For sure. +JOËL: On that note, shall we wrap up? +DANIEL: I think so. +JOËL: Thanks for joining us, Daniel. Where can people find you online? +DANIEL: You can find me on Twitter or on GitHub. Both are danielnolan. +JOËL: All right, thank you very much for joining us. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël is joined by thoughtbot Software Developer and Dirt Jumper Daniel Nolan. Dirt jumping is BMX-style riding 🏍️ with really enormous dirt jumps.

+ +

But for a person who loves excitement in his spare time, for Daniel at work, it's not the new and shiny that interests him. When he dives into something, the "boring" parts of tech are what he finds most fulfilling. He wants to know the "why," and in this conversation, he explains how it sustains his career.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined with a guest, Daniel Nolan.

+ +

DANIEL: Hey.

+ +

JOËL: And, together, we're here to share a bit of what we've learned along the way. So, Daniel, what's new in your world?

+ +

DANIEL: So, recently, I just picked up a dirt jumper bicycle, and I've been learning to get better at dirt jumping. I ride mountain bikes quite a bit. But jumping is something that I haven't been super comfortable with.

+ +

JOËL: What is dirt jumping?

+ +

DANIEL: So, Dirt Jumping is kind of more like BMX-style riding with really huge dirt jumps. If you do it right, you don't pedal. So you should be jumping and pumping and making your way around the track or the course without the need to pedal. So it's actually pretty interesting. And it's supposed to level up your mountain bike skills if you get good at this.

+ +

JOËL: So the idea is you start up high somewhere, and you just kind of let the gravity bring you down?

+ +

DANIEL: Yep, that's the idea. So you start up on a platform; usually, you drop in. And then, from there, you start the series of jumps or rollers, pick up speed, and then kind of go into some bigger jumps, and berms, and stuff and make your way around the course. It's pretty fun.

+ +

JOËL: So you're coming down from a high, and then you hit a dirt ramp somewhere. You go up in the air. You fly off, and you're doing, like, a flip or something like that?

+ +

DANIEL: Yeah, not quite there yet. Some of the people I ride with can do flips, and no handers, and stuff; definitely not there, but just getting comfortable on big dirt jumps. I think the scariest thing is not being able to see the landing. So it's, like, if it's just a little jump, like, you know where you're going. But if it's like one of those big jumps with a huge lift, you just have no idea what's on the other side. And no matter how, you know, even if you've hit it ten times, it's still scary because you can't see it.

+ +

JOËL: How do you land safely when you can't see your landing place?

+ +

DANIEL: There's a technique where you kind of push the bike down. So, like, once you're in the air and you've kind of leveled the bike out, and you spot the landing, you force the bike down to kind of accentuate that movement and make the bike go down.

+ +

JOËL: Just so I get a better mental picture here, how high up are we talking about when you're flying off this ramp?

+ +

DANIEL: So some of these dirt jumps are probably...on the ones that I'm riding, they lift to probably, like, you know, eight, nine-feet high, and you're probably getting, like, three to four feet in the air over that to clear it.

+ +

JOËL: Wow. That's a little bit of elevation right there.

+ +

DANIEL: Yeah.

+ +

JOËL: I would probably be scared.

+ +

DANIEL: The safe jumps have what they call a table on top, so there's no risk. Like, if you land on top of the jump, you're not going to die. But, yeah, typically, they're flat on top. So you have to have enough air and enough momentum to clear that flat part and land on the downside.

+ +

JOËL: I like to do a lot of bouldering. In this case, I do it in a gym, so you're climbing up a wall that's maybe 15 feet high. Even at that height, I feel a little scared; not very good with heights. How do you feel when you're up 15-20 feet on a bicycle, and you don't know where you're going to land?

+ +

DANIEL: It's scary. I mean, just, there's no way to get around it. But that's the whole reason I started getting into the dirt jumping is just try to get it to where it's more second nature, and you're not so terrified.

+ +

JOËL: Kind of pushing some of your personal limits, then.

+ +

DANIEL: Yeah, for sure.

+ +

JOËL: So it sounds like you're introducing a lot of excitement and novelty in your personal life. And that contrasts to a recent conversation that we had where you'd mentioned that, at work, it's not the kind of shiny, new tech that excites you, or even kind of the scary parts. But you find that the boring parts of tech are what are most fulfilling to you.

+ +

DANIEL: Yeah, I actually really do like diving into the more boring parts. And I think to give just a little history about myself and maybe why that might be, I'm a second career programmer. My original career, or what I thought was going to be my lifelong career, was I was an auto mechanic. So I was a certified VW tech in my early 20s. And I've always kind of had this passion for, like, why things are. I want to know why something is. So, when I dive into something, it's like, I want to know the why. I don't want to just know what the fix is. I want to know why that thing fixes it or whatever.

+ +

So I find that getting into the more boring parts of programming, and especially in the Rails stack, allowed me to do this. So, for example, like, a gem that Dependabot can't upgrade, and it just sits there. The PR just sits there, and nobody wants to touch it. So then I come along, and I'm like, well, why won't it upgrade? Why can't we upgrade this thing? And I start diving into sort of breaking changes. Is there stuff like that?

+ +

So fixing things, for me, has been something...since I was just a little kid, my mom said I always used to take things apart and put them back together. I always want to know the why. Doing some of the more boring stuff, you get to do a lot more of that.

+ +

JOËL: So it sounds like really you're motivated by curiosity pretty strongly.

+ +

DANIEL: Yeah, for sure. I don't want to just know what a quick fix is or something like that. I want to actually get in. I want to read this, you know, like, an example, like, a gem that won't upgrade, like, I want to go dive into that source code. I want to see what the source code is doing. I want to figure out the why, you know. I don't want to just Google for, like, hey, I can't upgrade this gem. What do you think I should do? So I've always been super curious. That's how I've been able to sustain in software development and not really get burn out. It's what makes me tick.

+ +

JOËL: How do you feel about bug fixing or, like, chasing down bugs in general? Is that something that really scratches that itch?

+ +

DANIEL: It definitely does. I feel it's, you know, very similar to somebody comes to you, and they've got a broken car. And they're like, "Hey, this thing's making this noise when I'm going down the highway at 50 miles an hour, you know, what is it?" You know, it's very much the same thing. Like, you get an end user, and they're like, "Hey, when I click this button in the browser, and, you know, this thing doesn't load," or, you know, I'm getting a 500 error." It's very relatable. I love diving into those type of things. Like, I love fixing bugs.

+ +

JOËL: It's interesting that you related that back to your work with cars because it sounds like you were doing sort of the mechanical version of debugging.

+ +

DANIEL: Definitely the mechanical version of debugging. But it's still...it's a lot of the same stuff. It's a lot of process of elimination and stuff like that, right? Like, you got a noise coming from the front left. It could be anything, you know, it could be the wheel. It could be brakes. It could be, I mean, there's a number of things it could be. So you kind of got to start going down the path of like, you know, well, it's not this, and it's not this, and it's not this.

+ +

And it's very similar when you have a bug, you know, and you start down the path of, like, oh, well, I can click the button. The post is getting sent to the server. But, for some reason, you know, the parameters aren't going past the controller or something like that. So, you know, you maybe go look for some primitive params or something, I don't know. But it's very similar as, you know, just going through the process of, like, checking things off and trying to get to the root cause.

+ +

JOËL: Yeah. So, when you joined software, you already had this skill kind of really built up pretty well.

+ +

DANIEL: Yeah, I definitely did. Being a mechanic, a lot of times, I would get, like, the problems that nobody else wanted to deal with. Because people were like, oh, he likes troubleshooting electrical issues and stuff like that, so give it to him, you know. Whereas the other mechanics are just, you know, like, were more, like, oh, I want to rebuild the engine, or I want to put a new trans...like, it visibly needs an engine.

+ +

Like, oh, there's a rod through the side of the block. It's leaking oil everywhere. Okay, yeah, like...versus, oh, it's got some electrical bug where, you know, one injector doesn't fire every 50th time, or something like that. And something that you just really have to, like, trace down and figure out why it's not happening. So I feel like I had a pretty good, no pun intended, toolbox coming into...

+ +

JOËL: Nice.

+ +

DANIEL: Software development as far as just problem-solving skills, I guess.

+ +

JOËL: It's interesting. A few years ago, I interviewed a bunch of people about debugging and the parts they liked, the parts they didn't like, hopes, and fears. And most people I talked to actually enjoyed debugging, except that, oftentimes, when bugs come up, it's because they're blocking something else. And there are time pressures.

+ +

And so all that extra context is what makes debugging stressful for most people that I talk to. But the actual act of debugging, that kind of process of elimination or trying to hunt down the source of a bug, many people I interviewed actually found that highly fulfilling. So it sounds like it taps into a lot of the same interests that you have.

+ +

DANIEL: That's super interesting, yeah. And it is fulfilling, too, right? Like, you're going this hunting, and you kind of, like, put on your detective hat and go try to, like, figure out what the breaking thing is. And then you get the payoff also of like, okay, well, you know, if you actually fix it, you resolved it, and you get that little bit of payoff.

+ +

And I think for any job for me to be fulfilling, I have to have that kind of that payoff where you start with something broken, and you fix it. You know, you start with an empty editor, and then you build out a web application or something like that. So it's just, like, having that payoff is definitely huge. You know, I just find that part of software development super fulfilling.

+ +

JOËL: So you've mentioned debugging. You've talked a little bit about gnarly gem upgrades. What other types of work fit under that boring part of software heading for you?

+ +

DANIEL: Putting in some tools for best practices maybe, you know, like setting up linters and stuff like that, automated code review kind of things. It's stuff that you tend to see, like, teams and stuff want, but they just never have the time. They're always building, you know, new features and stuff. So I think a lot of that stuff, like, gets pushed by the wayside. Refactoring code that's good enough. It's good enough, and it's working, but it could be a little cleaner, a little easier to read; kind of enjoy that, too. I don't know, do you have any things that you would consider boring programming work?

+ +

JOËL: I think some types of features sometimes can feel boring, maybe a little bit beyond boring. It's scary or unpleasant to work on. Sometimes there are just parts of the code that are really gnarly to work with. I'm like, oh no, I've got the ticket that requires touching some of that gnarly code in a particular part of the app. There's one app, in particular, I'm thinking of that this was the wizard code, or the multi-step form processing code that had gotten really gnarly, and so nobody wanted to touch it. And if you had a ticket that required touching that code, it's like, oh no, you drew the short straw.

+ +

DANIEL: Yeah. I've definitely had experiences like that. I had a feature I worked on at a previous job where it was...the feature was referred to as the black box because nobody knew how it worked. Nobody knew what it actually did. But they knew that it didn't produce the results they wanted. And they knew it needed to be refactored, so that was definitely one. I don't even know if I would say that was boring, but definitely, a scary part that nobody wants to touch.

+ +

There's just all kinds of stuff that's boring. Like, if you're just constantly adding new features and doing new things, and adding to the app, there's code that's probably not used anymore. So using something like Coverband and going in and finding unused code and cleaning out that kind of stuff. Optimizing queries, again, you know, you build something, and it works. It's there. It's doing its thing. And nobody's complained that the endpoint's slow. But when you run it, you notice that there's like, you know, 70 N+1 queries. So you go, you know, you go touch that up a little bit.

+ +

I feel like a lot of people and a lot of programmers just don't want to do that work, or it may not even be that they don't want to do that work. It's just a lot of times; there's maybe no time for it. So that's no fault of anyone in particular. But I think we need to, you know, figure out a way to make some more of these things fun. Maybe more teams need to build in, like, gem upgrade day or something. And, you know, like, go upgrade the ones that are hard to upgrade. Upgrade the ones that Dependabot can't, that have breaking changes. Or, I don't know, there's got to be some way where we can make some more of this, like, the tasks that keep the car running more enjoyable, right?

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: Would it be fair to describe the types of work that you've been talking about here, you've been describing as the boring parts of development, would it be fair to put those under the heading of maintenance?

+ +

DANIEL: I think it would be fair to put it under maintenance, maybe even relating that back to cars. It's the same thing, right? Like, you can put a new paint job on the car, and you can get some new, shiny wheels. And you can, you know, put a turbocharger on it or something but, eventually, you know, you got to change your oil. You got to change your tires. You need to change your air filter, new windshield wipers, you know, so you can see when it's raining.

+ +

These things are all just things that need to be done. Otherwise, no matter how shiny your car is, it's just not going to go anymore, right? So I feel like maybe most of these tasks are maintenance. It's not the shiny, new thing. It's just keeping the thing running.

+ +

JOËL: And, I guess, traditionally, at thoughtbot, we've done engagements where we're either building new software or new features on existing software. Or we might be coming in and fixing some larger problems, maybe doing something like helping with a Rails upgrade or helping to backfill a test suite, some larger kind of chronic problems.

+ +

But we recently introduced a maintenance service that is, instead of having people full-time there to do a particular task, it's more of so many hours a month to just do a lot of those boring things where we're doing like you said, potentially gem upgrades, or fixing bugs, or things like that. Is that a team that you would be interested in joining?

+ +

DANIEL: So I actually got to work with Jeanine and [inaudible 16:05] on support and maintenance for about a month, month and a half maybe. I worked on an upgrade. And that's exactly what I did. It was upgrading a Rails 5.2 app to Rails 7. And yeah, it was not only super fun, but the other fun side of that, for me, is that a lot of times when I'm doing these things, and you find breaking changes, the gem is either, like, ten years old, and it can't be upgraded because there's nobody maintaining it anymore. So you maybe have to create a fork, or you maybe submit a patch or something.

+ +

So this is a way that I've been able to get, you know, my feet wet in open source without really contributing to a specific open-source project. So I have tons of little commits on different gems here and there fixing stuff up or something I found along the way that couldn't be upgraded or something like that. So yeah, the support and maintenance team is definitely something that I'm interested in, and I had a good time working with them for that rotation.

+ +

JOËL: And I think it's really interesting you're talking about the pattern of open-source contributions that you were having. And I think that's something that's really valuable to the community, just those little patches in various places because it's broken or is no longer compatible with other things. What you're doing not only helps unblock you and your client but also is probably unblocking a lot of other people in the community, so might have a larger impact towards other people than if you were putting all of your time into contributing to one more well-known gem.

+ +

DANIEL: Yeah, for sure. You know, I know for sure, like, some of them I have a commit on Honeybadger, something that broke recently, a Sidekiq upgrade that broke, and there was just a small change to the way the error handling worked. And it was, like, causing just this flood of errors. And it was just a simple change. But I'm sure not only did it fix it for us and the app I was working on, but, yeah, I'm sure quite a few people benefited from that one.

+ +

JOËL: So, for those listeners out there who are hearing you talk about some of this maintenance or boring work and maybe are feeling inspired to go and do that on their team, how would you recommend getting into that?

+ +

DANIEL: Well, I mentioned Dependabot. If your team's already using something like Dependabot for, like, minor gem upgrades, maybe there's a PR that's stuck that Dependabot can't upgrade because there's some breaking changes in one of the gems it's trying to upgrade. That's a great place to start. You could run, I believe; it's bundle-outdated. And that will tell you what gems are in your gem file that are outdated and need to be updated.

+ +

So any of them that are going to be major version bumps, you know, going from, like, two to three, typically, you'll usually have breaking changes somewhere you can kind of jump in and go fix those breaking changes. Maybe there's even breaking changes in another gem that may be related or something that you're trying to upgrade. And, you know, you can't upgrade past version two because the new gem you're trying to upgrade depends on that gem-specific version or something like that. So I feel like that's a great way you could jump in.

+ +

Maybe some other ways would be if, you know, maybe you want to optimize queries or something like that. Maybe you have Sentry or some other type of software that reports on these things, New Relic, you know, so something like that you could go dive into and pick up an endpoint that's responding slow or something that has some N+1s being reported and go dive in, see if you can maybe touch those up.

+ +

JOËL: Those are all great suggestions. I know I once worked with a developer who would dedicate...I think it was the first hour of his day. So he'd come into work in the morning, and before jumping in on feature work, the first hour of his day, he would just do small improvements on things and not just, like, refactoring for the sake of refactoring. But they're things like you're describing, like, oh, do we have a gem that needs to handle an update?

+ +

Did one of our monitoring services highlight maybe some slow queries that I could tweak a little bit this morning? Or are there areas where we're feeling pain that we can make things better? And just by doing a little bit every day, he became known as the person on the team who is, like, having an impact, and making everybody's lives better, and making the codebase better, making the product better. And I really appreciated this person.

+ +

DANIEL: Yeah, sounds like an angel. Like I was saying, you know, I kind of hinted out a little bit before...I think these things...and it could be because they're boring, or it could just be because you have stakeholders that are, like, hey, we need to get this new feature out. And I just feel like a lot of this stuff definitely gets pushed to the back burner often, so figuring out a way to incorporate some stuff into your day like that, or automating some of it, you know, using things like Dependabot and stuff like that. I think they're all just great ways to keep the app or the project in good shape.

+ +

Another thing that I've done adding custom RuboCop rules to enforce things the way that you want them. So, like, it comes with a standard set of rules, but you find some pattern that's being, you know, repeated, and we don't want that pattern repeated. You know, spend the time to write a RuboCop rule so that that pattern doesn't get repeated. And you don't have to constantly police this in PRs, you know, you let the automated tool do it for you. But I've never really heard anybody get super excited about writing a Rubocop rule.

+ +

JOËL: And they're valuable.

+ +

DANIEL: Yeah, they're definitely valuable.

+ +

JOËL: I think the most excited I've seen people get about RuboCop rules is typically as part of an incident report. So something went terribly wrong, and maybe production went down. And then you're doing a post-mortem, and then you realize, oh, in this way, some bad code made it through. And you decide how can we prevent this from happening again? And the consensus is, oh, maybe a Rubocop rule would have prevented this. So I think that's generally where people actually start caring about a Rubocop rule is after there's been some larger incident.

+ +

DANIEL: Sure. We had something where I think, like, we first started using system specs on an app I was working on, and some people were using Path Helper, and some people were using URL Helper. And, for some reason, the ones that were using Path Helper would fail randomly. I don't really recall right off the top of my head why, but we wrote a RuboCop rule to just enforce using the URL for or the URL Helper instead of the Path Helper just to enforce that rule. So we didn't have to constantly police it, and it just made everybody's lives easier.

+ +

Figuring out a way to set some time aside for this stuff or automating this stuff is definitely beneficial because you may not always have somebody on the team that's interested or that wants to champion this stuff.

+ +

JOËL: Hey, you mentioned the word champion, and I like that word because it's the kind of thing that often doesn't get prioritized. And so you need somebody to advocate for that work getting done. And, generally, I've found this work is often cheaper to do sooner rather than later. If you postpone it too long, and now it's been ten years, and you've not done a Rails upgrade, and your app is still running on Rails 3. It's going to be very expensive to do that work.

+ +

DANIEL: Yeah, the biggest cost of software is maintenance is definitely true.

+ +

JOËL: Maintenance is valuable work, and we should celebrate it more.

+ +

DANIEL: For sure.

+ +

JOËL: On that note, shall we wrap up?

+ +

DANIEL: I think so.

+ +

JOËL: Thanks for joining us, Daniel. Where can people find you online?

+ +

DANIEL: You can find me on Twitter or on GitHub. Both are danielnolan.

+ +

JOËL: All right, thank you very much for joining us.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël is joined by thoughtbot Software Developer and Dirt Jumper Daniel Nolan. Dirt jumping is BMX-style riding 🏍️ with really enormous dirt jumps.

+ +

But for a person who loves excitement in his spare time, for Daniel at work, it's not the new and shiny that interests him. When he dives into something, the "boring" parts of tech are what he finds most fulfilling. He wants to know the "why," and in this conversation, he explains how it sustains his career.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined with a guest, Daniel Nolan.

+ +

DANIEL: Hey.

+ +

JOËL: And, together, we're here to share a bit of what we've learned along the way. So, Daniel, what's new in your world?

+ +

DANIEL: So, recently, I just picked up a dirt jumper bicycle, and I've been learning to get better at dirt jumping. I ride mountain bikes quite a bit. But jumping is something that I haven't been super comfortable with.

+ +

JOËL: What is dirt jumping?

+ +

DANIEL: So, Dirt Jumping is kind of more like BMX-style riding with really huge dirt jumps. If you do it right, you don't pedal. So you should be jumping and pumping and making your way around the track or the course without the need to pedal. So it's actually pretty interesting. And it's supposed to level up your mountain bike skills if you get good at this.

+ +

JOËL: So the idea is you start up high somewhere, and you just kind of let the gravity bring you down?

+ +

DANIEL: Yep, that's the idea. So you start up on a platform; usually, you drop in. And then, from there, you start the series of jumps or rollers, pick up speed, and then kind of go into some bigger jumps, and berms, and stuff and make your way around the course. It's pretty fun.

+ +

JOËL: So you're coming down from a high, and then you hit a dirt ramp somewhere. You go up in the air. You fly off, and you're doing, like, a flip or something like that?

+ +

DANIEL: Yeah, not quite there yet. Some of the people I ride with can do flips, and no handers, and stuff; definitely not there, but just getting comfortable on big dirt jumps. I think the scariest thing is not being able to see the landing. So it's, like, if it's just a little jump, like, you know where you're going. But if it's like one of those big jumps with a huge lift, you just have no idea what's on the other side. And no matter how, you know, even if you've hit it ten times, it's still scary because you can't see it.

+ +

JOËL: How do you land safely when you can't see your landing place?

+ +

DANIEL: There's a technique where you kind of push the bike down. So, like, once you're in the air and you've kind of leveled the bike out, and you spot the landing, you force the bike down to kind of accentuate that movement and make the bike go down.

+ +

JOËL: Just so I get a better mental picture here, how high up are we talking about when you're flying off this ramp?

+ +

DANIEL: So some of these dirt jumps are probably...on the ones that I'm riding, they lift to probably, like, you know, eight, nine-feet high, and you're probably getting, like, three to four feet in the air over that to clear it.

+ +

JOËL: Wow. That's a little bit of elevation right there.

+ +

DANIEL: Yeah.

+ +

JOËL: I would probably be scared.

+ +

DANIEL: The safe jumps have what they call a table on top, so there's no risk. Like, if you land on top of the jump, you're not going to die. But, yeah, typically, they're flat on top. So you have to have enough air and enough momentum to clear that flat part and land on the downside.

+ +

JOËL: I like to do a lot of bouldering. In this case, I do it in a gym, so you're climbing up a wall that's maybe 15 feet high. Even at that height, I feel a little scared; not very good with heights. How do you feel when you're up 15-20 feet on a bicycle, and you don't know where you're going to land?

+ +

DANIEL: It's scary. I mean, just, there's no way to get around it. But that's the whole reason I started getting into the dirt jumping is just try to get it to where it's more second nature, and you're not so terrified.

+ +

JOËL: Kind of pushing some of your personal limits, then.

+ +

DANIEL: Yeah, for sure.

+ +

JOËL: So it sounds like you're introducing a lot of excitement and novelty in your personal life. And that contrasts to a recent conversation that we had where you'd mentioned that, at work, it's not the kind of shiny, new tech that excites you, or even kind of the scary parts. But you find that the boring parts of tech are what are most fulfilling to you.

+ +

DANIEL: Yeah, I actually really do like diving into the more boring parts. And I think to give just a little history about myself and maybe why that might be, I'm a second career programmer. My original career, or what I thought was going to be my lifelong career, was I was an auto mechanic. So I was a certified VW tech in my early 20s. And I've always kind of had this passion for, like, why things are. I want to know why something is. So, when I dive into something, it's like, I want to know the why. I don't want to just know what the fix is. I want to know why that thing fixes it or whatever.

+ +

So I find that getting into the more boring parts of programming, and especially in the Rails stack, allowed me to do this. So, for example, like, a gem that Dependabot can't upgrade, and it just sits there. The PR just sits there, and nobody wants to touch it. So then I come along, and I'm like, well, why won't it upgrade? Why can't we upgrade this thing? And I start diving into sort of breaking changes. Is there stuff like that?

+ +

So fixing things, for me, has been something...since I was just a little kid, my mom said I always used to take things apart and put them back together. I always want to know the why. Doing some of the more boring stuff, you get to do a lot more of that.

+ +

JOËL: So it sounds like really you're motivated by curiosity pretty strongly.

+ +

DANIEL: Yeah, for sure. I don't want to just know what a quick fix is or something like that. I want to actually get in. I want to read this, you know, like, an example, like, a gem that won't upgrade, like, I want to go dive into that source code. I want to see what the source code is doing. I want to figure out the why, you know. I don't want to just Google for, like, hey, I can't upgrade this gem. What do you think I should do? So I've always been super curious. That's how I've been able to sustain in software development and not really get burn out. It's what makes me tick.

+ +

JOËL: How do you feel about bug fixing or, like, chasing down bugs in general? Is that something that really scratches that itch?

+ +

DANIEL: It definitely does. I feel it's, you know, very similar to somebody comes to you, and they've got a broken car. And they're like, "Hey, this thing's making this noise when I'm going down the highway at 50 miles an hour, you know, what is it?" You know, it's very much the same thing. Like, you get an end user, and they're like, "Hey, when I click this button in the browser, and, you know, this thing doesn't load," or, you know, I'm getting a 500 error." It's very relatable. I love diving into those type of things. Like, I love fixing bugs.

+ +

JOËL: It's interesting that you related that back to your work with cars because it sounds like you were doing sort of the mechanical version of debugging.

+ +

DANIEL: Definitely the mechanical version of debugging. But it's still...it's a lot of the same stuff. It's a lot of process of elimination and stuff like that, right? Like, you got a noise coming from the front left. It could be anything, you know, it could be the wheel. It could be brakes. It could be, I mean, there's a number of things it could be. So you kind of got to start going down the path of like, you know, well, it's not this, and it's not this, and it's not this.

+ +

And it's very similar when you have a bug, you know, and you start down the path of, like, oh, well, I can click the button. The post is getting sent to the server. But, for some reason, you know, the parameters aren't going past the controller or something like that. So, you know, you maybe go look for some primitive params or something, I don't know. But it's very similar as, you know, just going through the process of, like, checking things off and trying to get to the root cause.

+ +

JOËL: Yeah. So, when you joined software, you already had this skill kind of really built up pretty well.

+ +

DANIEL: Yeah, I definitely did. Being a mechanic, a lot of times, I would get, like, the problems that nobody else wanted to deal with. Because people were like, oh, he likes troubleshooting electrical issues and stuff like that, so give it to him, you know. Whereas the other mechanics are just, you know, like, were more, like, oh, I want to rebuild the engine, or I want to put a new trans...like, it visibly needs an engine.

+ +

Like, oh, there's a rod through the side of the block. It's leaking oil everywhere. Okay, yeah, like...versus, oh, it's got some electrical bug where, you know, one injector doesn't fire every 50th time, or something like that. And something that you just really have to, like, trace down and figure out why it's not happening. So I feel like I had a pretty good, no pun intended, toolbox coming into...

+ +

JOËL: Nice.

+ +

DANIEL: Software development as far as just problem-solving skills, I guess.

+ +

JOËL: It's interesting. A few years ago, I interviewed a bunch of people about debugging and the parts they liked, the parts they didn't like, hopes, and fears. And most people I talked to actually enjoyed debugging, except that, oftentimes, when bugs come up, it's because they're blocking something else. And there are time pressures.

+ +

And so all that extra context is what makes debugging stressful for most people that I talk to. But the actual act of debugging, that kind of process of elimination or trying to hunt down the source of a bug, many people I interviewed actually found that highly fulfilling. So it sounds like it taps into a lot of the same interests that you have.

+ +

DANIEL: That's super interesting, yeah. And it is fulfilling, too, right? Like, you're going this hunting, and you kind of, like, put on your detective hat and go try to, like, figure out what the breaking thing is. And then you get the payoff also of like, okay, well, you know, if you actually fix it, you resolved it, and you get that little bit of payoff.

+ +

And I think for any job for me to be fulfilling, I have to have that kind of that payoff where you start with something broken, and you fix it. You know, you start with an empty editor, and then you build out a web application or something like that. So it's just, like, having that payoff is definitely huge. You know, I just find that part of software development super fulfilling.

+ +

JOËL: So you've mentioned debugging. You've talked a little bit about gnarly gem upgrades. What other types of work fit under that boring part of software heading for you?

+ +

DANIEL: Putting in some tools for best practices maybe, you know, like setting up linters and stuff like that, automated code review kind of things. It's stuff that you tend to see, like, teams and stuff want, but they just never have the time. They're always building, you know, new features and stuff. So I think a lot of that stuff, like, gets pushed by the wayside. Refactoring code that's good enough. It's good enough, and it's working, but it could be a little cleaner, a little easier to read; kind of enjoy that, too. I don't know, do you have any things that you would consider boring programming work?

+ +

JOËL: I think some types of features sometimes can feel boring, maybe a little bit beyond boring. It's scary or unpleasant to work on. Sometimes there are just parts of the code that are really gnarly to work with. I'm like, oh no, I've got the ticket that requires touching some of that gnarly code in a particular part of the app. There's one app, in particular, I'm thinking of that this was the wizard code, or the multi-step form processing code that had gotten really gnarly, and so nobody wanted to touch it. And if you had a ticket that required touching that code, it's like, oh no, you drew the short straw.

+ +

DANIEL: Yeah. I've definitely had experiences like that. I had a feature I worked on at a previous job where it was...the feature was referred to as the black box because nobody knew how it worked. Nobody knew what it actually did. But they knew that it didn't produce the results they wanted. And they knew it needed to be refactored, so that was definitely one. I don't even know if I would say that was boring, but definitely, a scary part that nobody wants to touch.

+ +

There's just all kinds of stuff that's boring. Like, if you're just constantly adding new features and doing new things, and adding to the app, there's code that's probably not used anymore. So using something like Coverband and going in and finding unused code and cleaning out that kind of stuff. Optimizing queries, again, you know, you build something, and it works. It's there. It's doing its thing. And nobody's complained that the endpoint's slow. But when you run it, you notice that there's like, you know, 70 N+1 queries. So you go, you know, you go touch that up a little bit.

+ +

I feel like a lot of people and a lot of programmers just don't want to do that work, or it may not even be that they don't want to do that work. It's just a lot of times; there's maybe no time for it. So that's no fault of anyone in particular. But I think we need to, you know, figure out a way to make some more of these things fun. Maybe more teams need to build in, like, gem upgrade day or something. And, you know, like, go upgrade the ones that are hard to upgrade. Upgrade the ones that Dependabot can't, that have breaking changes. Or, I don't know, there's got to be some way where we can make some more of this, like, the tasks that keep the car running more enjoyable, right?

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: Would it be fair to describe the types of work that you've been talking about here, you've been describing as the boring parts of development, would it be fair to put those under the heading of maintenance?

+ +

DANIEL: I think it would be fair to put it under maintenance, maybe even relating that back to cars. It's the same thing, right? Like, you can put a new paint job on the car, and you can get some new, shiny wheels. And you can, you know, put a turbocharger on it or something but, eventually, you know, you got to change your oil. You got to change your tires. You need to change your air filter, new windshield wipers, you know, so you can see when it's raining.

+ +

These things are all just things that need to be done. Otherwise, no matter how shiny your car is, it's just not going to go anymore, right? So I feel like maybe most of these tasks are maintenance. It's not the shiny, new thing. It's just keeping the thing running.

+ +

JOËL: And, I guess, traditionally, at thoughtbot, we've done engagements where we're either building new software or new features on existing software. Or we might be coming in and fixing some larger problems, maybe doing something like helping with a Rails upgrade or helping to backfill a test suite, some larger kind of chronic problems.

+ +

But we recently introduced a maintenance service that is, instead of having people full-time there to do a particular task, it's more of so many hours a month to just do a lot of those boring things where we're doing like you said, potentially gem upgrades, or fixing bugs, or things like that. Is that a team that you would be interested in joining?

+ +

DANIEL: So I actually got to work with Jeanine and [inaudible 16:05] on support and maintenance for about a month, month and a half maybe. I worked on an upgrade. And that's exactly what I did. It was upgrading a Rails 5.2 app to Rails 7. And yeah, it was not only super fun, but the other fun side of that, for me, is that a lot of times when I'm doing these things, and you find breaking changes, the gem is either, like, ten years old, and it can't be upgraded because there's nobody maintaining it anymore. So you maybe have to create a fork, or you maybe submit a patch or something.

+ +

So this is a way that I've been able to get, you know, my feet wet in open source without really contributing to a specific open-source project. So I have tons of little commits on different gems here and there fixing stuff up or something I found along the way that couldn't be upgraded or something like that. So yeah, the support and maintenance team is definitely something that I'm interested in, and I had a good time working with them for that rotation.

+ +

JOËL: And I think it's really interesting you're talking about the pattern of open-source contributions that you were having. And I think that's something that's really valuable to the community, just those little patches in various places because it's broken or is no longer compatible with other things. What you're doing not only helps unblock you and your client but also is probably unblocking a lot of other people in the community, so might have a larger impact towards other people than if you were putting all of your time into contributing to one more well-known gem.

+ +

DANIEL: Yeah, for sure. You know, I know for sure, like, some of them I have a commit on Honeybadger, something that broke recently, a Sidekiq upgrade that broke, and there was just a small change to the way the error handling worked. And it was, like, causing just this flood of errors. And it was just a simple change. But I'm sure not only did it fix it for us and the app I was working on, but, yeah, I'm sure quite a few people benefited from that one.

+ +

JOËL: So, for those listeners out there who are hearing you talk about some of this maintenance or boring work and maybe are feeling inspired to go and do that on their team, how would you recommend getting into that?

+ +

DANIEL: Well, I mentioned Dependabot. If your team's already using something like Dependabot for, like, minor gem upgrades, maybe there's a PR that's stuck that Dependabot can't upgrade because there's some breaking changes in one of the gems it's trying to upgrade. That's a great place to start. You could run, I believe; it's bundle-outdated. And that will tell you what gems are in your gem file that are outdated and need to be updated.

+ +

So any of them that are going to be major version bumps, you know, going from, like, two to three, typically, you'll usually have breaking changes somewhere you can kind of jump in and go fix those breaking changes. Maybe there's even breaking changes in another gem that may be related or something that you're trying to upgrade. And, you know, you can't upgrade past version two because the new gem you're trying to upgrade depends on that gem-specific version or something like that. So I feel like that's a great way you could jump in.

+ +

Maybe some other ways would be if, you know, maybe you want to optimize queries or something like that. Maybe you have Sentry or some other type of software that reports on these things, New Relic, you know, so something like that you could go dive into and pick up an endpoint that's responding slow or something that has some N+1s being reported and go dive in, see if you can maybe touch those up.

+ +

JOËL: Those are all great suggestions. I know I once worked with a developer who would dedicate...I think it was the first hour of his day. So he'd come into work in the morning, and before jumping in on feature work, the first hour of his day, he would just do small improvements on things and not just, like, refactoring for the sake of refactoring. But they're things like you're describing, like, oh, do we have a gem that needs to handle an update?

+ +

Did one of our monitoring services highlight maybe some slow queries that I could tweak a little bit this morning? Or are there areas where we're feeling pain that we can make things better? And just by doing a little bit every day, he became known as the person on the team who is, like, having an impact, and making everybody's lives better, and making the codebase better, making the product better. And I really appreciated this person.

+ +

DANIEL: Yeah, sounds like an angel. Like I was saying, you know, I kind of hinted out a little bit before...I think these things...and it could be because they're boring, or it could just be because you have stakeholders that are, like, hey, we need to get this new feature out. And I just feel like a lot of this stuff definitely gets pushed to the back burner often, so figuring out a way to incorporate some stuff into your day like that, or automating some of it, you know, using things like Dependabot and stuff like that. I think they're all just great ways to keep the app or the project in good shape.

+ +

Another thing that I've done adding custom RuboCop rules to enforce things the way that you want them. So, like, it comes with a standard set of rules, but you find some pattern that's being, you know, repeated, and we don't want that pattern repeated. You know, spend the time to write a RuboCop rule so that that pattern doesn't get repeated. And you don't have to constantly police this in PRs, you know, you let the automated tool do it for you. But I've never really heard anybody get super excited about writing a Rubocop rule.

+ +

JOËL: And they're valuable.

+ +

DANIEL: Yeah, they're definitely valuable.

+ +

JOËL: I think the most excited I've seen people get about RuboCop rules is typically as part of an incident report. So something went terribly wrong, and maybe production went down. And then you're doing a post-mortem, and then you realize, oh, in this way, some bad code made it through. And you decide how can we prevent this from happening again? And the consensus is, oh, maybe a Rubocop rule would have prevented this. So I think that's generally where people actually start caring about a Rubocop rule is after there's been some larger incident.

+ +

DANIEL: Sure. We had something where I think, like, we first started using system specs on an app I was working on, and some people were using Path Helper, and some people were using URL Helper. And, for some reason, the ones that were using Path Helper would fail randomly. I don't really recall right off the top of my head why, but we wrote a RuboCop rule to just enforce using the URL for or the URL Helper instead of the Path Helper just to enforce that rule. So we didn't have to constantly police it, and it just made everybody's lives easier.

+ +

Figuring out a way to set some time aside for this stuff or automating this stuff is definitely beneficial because you may not always have somebody on the team that's interested or that wants to champion this stuff.

+ +

JOËL: Hey, you mentioned the word champion, and I like that word because it's the kind of thing that often doesn't get prioritized. And so you need somebody to advocate for that work getting done. And, generally, I've found this work is often cheaper to do sooner rather than later. If you postpone it too long, and now it's been ten years, and you've not done a Rails upgrade, and your app is still running on Rails 3. It's going to be very expensive to do that work.

+ +

DANIEL: Yeah, the biggest cost of software is maintenance is definitely true.

+ +

JOËL: Maintenance is valuable work, and we should celebrate it more.

+ +

DANIEL: For sure.

+ +

JOËL: On that note, shall we wrap up?

+ +

DANIEL: I think so.

+ +

JOËL: Thanks for joining us, Daniel. Where can people find you online?

+ +

DANIEL: You can find me on Twitter or on GitHub. Both are danielnolan.

+ +

JOËL: All right, thank you very much for joining us.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7B9qmuP1 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 384: Not All Numbers Are Numbers + https://bikeshed.thoughtbot.com/384 + f32ac724-4567-4fe7-beb1-431d1387bbec + Tue, 16 May 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël gives a recap after attending RailsConf 2023 in Atlanta, Georgia (and yes, there was karaoke! 🎤 🎶). Stephanie plugs the The Tightly Coupled Book Club Podcast from friends and fellow thoughtboters Aji and Mina Slater where they're reading The Rails Guides from cover to cover and treating it like a book club and having a discussions about the documentation as they read it together. + +Stemming from [a Twitter thread by Joël](https://twitter.com/joelquen/status/1598705157168136193), their main topic focuses on not all numbers being numbers. So: if someone is submitting a phone number through a form: + +* How would you store that in the database? +* Would you store it as a string? Because sometimes it comes with some extra formatting. +* Would you normalize it and try to store it as an integer because it's a number? + +Thoughts, Dear Listener? + 37:56 + no + + + Joël gives a recap after attending RailsConf 2023 in Atlanta, Georgia (and yes, there was karaoke! 🎤 🎶). Stephanie plugs the The Tightly Coupled Book Club Podcast from friends and fellow thoughtboters Aji and Mina Slater where they're reading The Rails Guides from cover to cover and treating it like a book club and having a discussions about the documentation as they read it together. +Stemming from a Twitter thread by Joël (https://twitter.com/joelquen/status/1598705157168136193), their main topic focuses on not all numbers being numbers. So: if someone is submitting a phone number through a form: +How would you store that in the database? +Would you store it as a string? Because sometimes it comes with some extra formatting. +Would you normalize it and try to store it as an integer because it's a number? +Thoughts, Dear Listener? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +How to Decline by Anne Helen Petersen (https://annehelen.substack.com/p/how-to-decline) +The Tightly Coupled Book Club podcast (https://podcasts.apple.com/us/podcast/the-tightly-coupled-book-club/id1679202519) +Rails Guides (https://guides.rubyonrails.org/) +Michael Hartl Rails Tutorial (https://www.railstutorial.org/) +Why the GOV.UK Design System team changed the input type for numbers (https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/) +Google’s libphonenumber (https://github.com/google/libphonenumber) +GOV.UK design system’s open GitHub issue on phone numbers (https://github.com/alphagov/govuk-design-system-backlog/issues/101) +HTML numeric input mode (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) +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: I've just returned from attending RailsConf 2023 in Atlanta, Georgia, and it was so much fun. I got a chance to attend some really good talks. I got a chance to connect with other people in the community. I always love the hallway track or any of the events that happen in the evenings after the conferences. It's a lot of fun. +STEPHANIE: Nice. I found it funny that you emphasized just returned because you literally walked through the door of your home and then got online to record this podcast with me. [laughs] +JOËL: Productivity. +STEPHANIE: What were some of your highlights from the conference? +JOËL: I really appreciated a talk by Elle Meredith about how to say no. And she gave...I think it was nine sort of different ways that you might want to have a conversation about saying no to a request. They're almost like design patterns but for interpersonal conversations. And so she covered situations where you might want to say no to maybe someone who's higher up in a hierarchy than you, so a manager. +But also, what it's like sometimes when it's the other way around if you're a manager and you have to say no to someone who reports to you, and how to handle some of those conversations. So I really appreciated the nuance that she had to share. And I think the strategies were just really practical. +STEPHANIE: That's awesome. Yeah, I know we, as developers, love some good patterns and frameworks. That actually reminds me of something else that I'd read recently, a newsletter called Culture Study by this journalist Anne Helen Petersen. She recently sent out a dispatch about how to say no or decline requests through email. And I was just thinking that it's such a challenging thing to do. But having a script or seeing examples of how other people do it is really helpful to just make it easier the next time that you want to say no, but then you're not sure how. +JOËL: It's not easy to say no. I think most people want to please, and it's much easier to say yes. And maybe even you want to believe that you can say yes, that you can do everything with limited resources and not have to prioritize. And then, of course, reality hits you, and you're in a worse situation than if you'd said no upfront or had at least an honest conversation about the limitations that we have and the prioritization that needs to happen. +STEPHANIE: Yeah, absolutely. So, over in the thoughtbot Slack, I saw a lot of really awesome praise and even photos from the conference, including stuff about a thoughtbot-sponsored event that we hosted over at RailsConf. What was that like? +JOËL: That was so much fun. So we hosted an event out in Centennial Park after day one and just had some lawn games, some snacks, some drinks. And people just came to hang out in the park and had a good time. And I got to chat with a lot of people. I think it somehow just felt really relaxed yet really social. +Sometimes when you're in the hallway in the convention center, you'll see groups of people talking, but also kind of people awkwardly walking around and struggling to connect. And there are just so many people around. And if you don't know anyone, it can be really hard to kind of break in. And I felt that this setting...I'm not sure exactly why; maybe it was a smaller amount of people. Maybe it's because it's a more relaxed atmosphere. You're outside. Everyone was kind of mingling and talking and seemed to be having a good time. +STEPHANIE: That's really cool. I'm so bummed to have missed it. Yeah, I hear you about the hallway track. It's like you're still kind of, you know, either in a convention center or a hotel, so there is just that vibe of formality. And taking it out of that venue and making it super casual, you know, I think that also almost allows people to not talk about tech, or the conference, or anything work-related and just have fun. +JOËL: Definitely. Although there's definitely fun that happens in all sorts of ways after the conference as well. One of the evenings, I went out with a few other thoughtboters and some other attendees at the conference; we went to a karaoke bar. +STEPHANIE: That sounds like a lot of fun. I think that's become almost a tradition for the thoughtbot crew whenever we do things out in the world, karaoke. And I'm trying to get escape rooms to be a conference tradition among my group of friends. So you and I, we participated in escape room the last conference that we were at together, and that was a lot of fun. So this is a thing that I hope to keep doing [laughs] next time I see you in person. +JOËL: We didn't just participate. We broke the record. +STEPHANIE: It's true. Yeah, I didn't want to brag on the podcast. But we did break the record. And we got to, like, write our names on a little poster to put in the office. And I hope it's still there, at that escape room company in Providence, Rhode Island. +JOËL: I'd be curious to hear from some of our listeners what some of their traditions are when they go to a conference. Do you have something that you like to do with your conference friends when you meet up? Let us know at hosts@bikeshed.fm. And we'll give you a shout-out on one of the upcoming episodes. So, Stephanie, what's new in your world? +STEPHANIE: Speaking of friends and community, I have a podcast to plug today. So our friends and fellow thoughtboters and married couple Aji and Mina Slater, they just launched a podcast called The Tightly Coupled Book Club Podcast. And what they're doing is reading The Rails Guides from cover to cover and kind of treating it like a book club and having a discussion about the documentation as they read it together. +And I listened to the first two episodes this morning, and I really enjoyed it. I thought it was such a cool idea and a really great format as a person who enjoys talking about books and things I've read with you. I mean, sometimes we've joked that this is kind of like our two-person book club. But it's really cool to listen in on other people who are, you know, are really knowledgeable, or have a lot of experience about a thing, and then also share their experience reading something as they come across it. I thought that was really interesting too. There's a real-time aspect of it that I liked. +JOËL: I love the idea of taking the book club concept and then reading the Rails Guides. What a really original idea. +STEPHANIE: It's funny because the Rails Guides do kind of read like a book. I went on to the documentation today just to kind of give myself a refresher as I was listening. And you can download the guides on your Kindle. So, in some ways, they've kind of leaned into that format. And since a lot of it is also just, like, prose, it is more like paragraphs rather than quick bits or API reference. +JOËL: Right, right. It's something that's meant to be read in larger chunks rather than just found through a search and then referencing one entry in a list of methods or something like that. +STEPHANIE: Yeah. I think my other favorite part about doing an idea like this is I think we all kind of have our own different experiences with the Rails official docs and guides. And I really liked that they're just like, yeah, like, you know, the way that an individual developer approaches the documentation can be totally different. And they kind of talk about how they do it or how they don't do it. Kind of all with the intention of wanting to better understand Rails and also wanting to better support people who want to get into Rails and are kind of entering the universe from the documentation for the first time. +JOËL: Yeah, and I think the Rails Guides, in particular, are often that first point of contact for a lot of newer Rails developers. I know that, for myself, when I was first getting into Rails, I was on those guides all the time. Between that and cherry-picking examples from the Michael Hartl Rails tutorial, that's kind of how I learned Rails. +STEPHANIE: Yeah, I like that a lot. For other folks who want to hear more about just Mina and Aji's experience with the Rails Guides, you should all check out that podcast. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So this is a conversation we had the other day, and I'm curious what your take is on this. If someone is submitting a phone number through a form, how would you store that in the database? Would you store it as a string? Because sometimes it comes with some extra formatting. Would you normalize it and try to store it as an integer because it's a number? What's your take? +STEPHANIE: Okay, to answer that question, I think I'm going to gripe a little bit first because the thing with phone numbers is that there are so many ways to format them. So, when you were saying, like, oh, you know, how would you input a number? I'm like; I don't know. Even if I were to write down a phone number on any given day, would I add the parentheses? Would I include the dashes? Do I add the country code? It honestly really depends. +And it's just totally different just based on what the form is asking of me or what channel I'm doing it in. So I think phone numbers is an interesting example because there are so many ways of representing it. But I think that actually also answers the way that I would do it is saving it as a string. Because while a phone number is made up of numbers, it's not exactly a numerical value. +JOËL: You're hitting on something pretty deep here about the fundamental nature of what a phone number is. What do you mean by saying it's not numeric? +STEPHANIE: I guess it doesn't mean anything in mathematical terms, I suppose, is what I was trying to get at. Like, it happens to be in the U.S., at least, you know. +JOËL: Always gotta qualify that, right? +STEPHANIE: Right. It happens to be a 10-digit identifier, I suppose. I almost said number there, but I think I'm trying to avoid it for the sake of my argument. But it's not necessarily something we would try to do arithmetic on. It's not something that... +JOËL: I'm kind of laughing at the idea of trying to do math on a phone number, adding two phone numbers together, doing some sort of, I don't know, add 20% to your phone number. Like, what does that even mean? +STEPHANIE: Yeah, absolutely. It's something that mostly remains static, right? It's like when it changes, that means something different. It means that the way that you would reach someone via a phone call or just that kind of communication is more of an event that has changed rather than the value transforming doesn't mean anything on its own. +JOËL: So you mentioned that this is not the kind of number that you can do arithmetic on. That kind of reminded me of an article from the UK's I want to say government design guidelines and how to design web forms that are going to be used by any service that's part of the UK Government. And they have this category of numbers that they call non-incrementable. +And their suggestion is that even though these things are represented as numbers, they should not use the HTML number input for them because you're never going to hit that little plus or minus arrow to go up and down and change the number. And that, instead, it should just be a regular text input. +STEPHANIE: Yeah, that's interesting because the idea of incrementing, for me, is definitely more attributed to the idea of a numerical value where it's a number and then what that number represents. So it could be weight. It could be money. It could be some other measurement. Another one could be quantity, right? If you have a shopping cart or something, and you're incrementing that value because you want to buy more of whatever item. That, to me, is where I see that type of input more frequently. +And so it would make sense that, you know, a phone number where the person is usually inputting a fixed thing that, you know, because that is not something that they can change, or they are wanting to change in that form, would be represented with a different HTML input. +JOËL: I don't know about you, but I feel like when I'm having a conversation with someone, occasionally, they'll just sort of mention something that my ears will kind of prick up because it feels like a keyword. And you mentioned earlier the keyword identifier, that a phone number to you feels more like an identifier than a number. And I want to dig into that because that feels really key to this conversation. +STEPHANIE: Yeah. I think there are a lot of things that happen to have numbers in them because that's the characters we use to denote some kind of unique or mostly unique value [laughs] of something. So, like, most people have a phone number, some people don't, some people may have multiple. But, usually, that phone number is tied to a person or a business or some kind of...it's like a record of how to reach someone. +JOËL: Yeah. I guess to a certain extent, a phone number is like a...it's not an ID for a person, but it's an ID for a phone, or for a SIM card, or a line, an account, something like that that's publicly shared out. But even though it's publicly shared out, it's effectively...I guess you might call it a third-party ID by the phone companies. If they're supposed to be globally unique, you might say the global telecoms consortium that have come up with this set of rules. +STEPHANIE: [laughs] Yes, we're clearly not telecommunications experts over here [laughs] or just have a, you know, regular human-level understanding of how telephones work. [laughs] +JOËL: But I think that's a really interesting idea because I think my instinct with phone numbers is I want to normalize them when I get them through a form. And yet I have very strong instincts that anytime I get an ID from a third-party service, let's say I'm interacting with an API, and I get a new user through there. The ID from the third-party service is there. When I save it into my database, I will create a new primary key for that row because I want to own my own primary keys. +But I will have a row for that third-party ID, and I will make sure to not modify it. I will store it in its raw form. So why do I feel the need to normalize phone numbers? If they are third-party IDs, then maybe I should just be storing them in raw format as entered by the user. At the very least, maybe I should store them as strings rather than trying to turn them into numbers. +STEPHANIE: Yeah, that's interesting. I mean, I do think phone numbers are a bit of an exception here in that you could think of it as a third-party ID. But it's also so ubiquitous in how our society functions. And the way people use it, it's like it's not a single service that this is owned by where you want to make sure that you're capturing it the way that that third party would. It's something that is so commonplace that it can end up having different forms because of the way that users interact with it. +JOËL: I think one thing that's really interesting with third-party IDs is that even though they might come back as numbers like you said earlier, we don't do math on them. The main thing you ever do with a third-party ID is use it to make requests back to that third-party service. So, if I have a user I've pulled from some other service and I ever want to talk to that service again, I would need to use that third-party ID that I have stored in order to make sure that everything stays in sync. +That's kind of what we do with a phone number, right? We store it. And then the reason we might want to store a phone number is because we might want to programmatically make a phone call or send a text message that's interacting back with that telecom's world. We might want a human to do that. But the effect is still kind of the same. +We're not doing any transformations or work on it internally within the software. It's always when we want to make some kind of phone call, either manually by a person or automatically with a computer. And the only way we can do that and reach the right person is by using the ID that was given to us. +STEPHANIE: Yeah, that's a really good point. I mean, I have seen many applications that do hand-roll their own validation or normalization on phone numbers. But I do think that there is a library for this published by Google I think. It's called Libphonenumber. And so it's an open-source library for parsing, validating, and formatting phone numbers for, I think, most countries. It's very comprehensive. +JOËL: I think the difference maybe with a phone number and a form where you might want to do a little bit of polishing on it is that it is manually entered by a user. It definitely needs validation because a user manually typing in an ID into a form absolutely could have an error in it. Normalizing it for storage purposes, maybe, but at the very least, yeah, it needs to be validated because someone hand-typing in an ID is not something you want to rely on too heavily. +STEPHANIE: Yeah. I mean, I'm curious if we can extrapolate this conversation further beyond phone numbers. It sounds like we're talking about this idea that values with numbers in them should not always be treated as integers. +JOËL: Yes. And I have a great example of that that has actually burned me before. +STEPHANIE: Ooh, what is it? +JOËL: Zip codes. So, again, prefixing this, in the U.S., zip codes are typically a five-digit number. There's a variant that has more digits in it. And you'd think that you can store that...it's a five-digit number; you can store that in an integer column. And that does not work because you can start with a zero. And so if you store that as an integer, then what you really have is a four-digit integer. And then, when you try to put that back into an address, things get messed up. +So it's really important to store U.S. zip codes as strings so that you can keep that leading zero if you need it. And, of course, the moment you introduce international zip codes, or I think postal codes is what most countries call it, now, all of a sudden, you've got letters in addition to numbers. I wanted to share one of the most delightful postcode bits of knowledge that I have. +STEPHANIE: Please. +JOËL: Which is that in Canada, postal codes alternate letters and numbers. And Canada decided that Santa Claus needed his own Canadian zip code. And his zip code is H0H 0H0. +STEPHANIE: [laughs] +JOËL: H0H 0H0 +STEPHANIE: Of course it is. I like that a lot. Makes sense that he would reside in Canada, up in the frigid, chilly north. So you've mentioned that you were burned by this. Does that mean you were working with an application that did store postal codes as integers? And what was the impact or consequence of that? +JOËL: So I was building a feature that required interacting with a zip code. And, as one does, I tested it out in development. And, as one also often does, I put in my own address. Now, I happen to live in Boston, and my zip code starts with a zero. So I happen to live in the one place that has that weird edge case. And immediately when I saw in dev how things happen, I was like, wait a minute, that's broken. That's not going to work. +STEPHANIE: Yeah. Wow. I wonder if that has just been impacting users for a long time before that discovery. +JOËL: It probably depends on the application, right? I guess you could...if you introduce that as a problem, you could try to add hacks on hacks to make it better. So you store it as an integer, but then when you get the integer out of the database, and you need to use it as an address, you then reformat it back. So you left-pad the number with zeros. +STEPHANIE: Yeah, I can see some really interesting ways of trying to work around that. +JOËL: But yeah, I think the best practice is definitely store your zip/postal codes as a string, not as an integer. +STEPHANIE: I wonder what it is about these types of values that make us think that they are numbers or want to store them as integers. I think that the Rails default is to store primary keys in integers. And if you wanted to use UUIDs, for example, instead, you do have to have done that initial setup. +I'm curious about the origin of using ints. And I know that that's like a whole story [laughs] in terms of the bite-size of that value. But yeah, it's just one of those origin stories that I'm wondering if that has kind of impacted our understanding of what primary keys look like. +JOËL: At its core, I think this goes back to what we were talking about earlier. Primary keys the default in Rails is an auto-incrementing integer. And we store it as an integer so that the database can do a plus-one on it every time we insert another record. We don't want to do that with zip codes or with phone numbers. Now, quite possibly, within the U.S. Postal Service or whatever the standard is for establishing phone numbers, they might, because these are numbers, they might be doing some kind of incrementing somewhere. +But there are patterns, definitely, that have been established. But they're not always necessarily incrementing. And they're not transparent to us in a way that we would care about them normally in an app. And we might care that, oh, we know that if it has a leading zero in the zip code, you're in this broad region or something like that. But, again, this is not really doing math so much as it's knowing the pattern in the ID. +I know some ID-like numbers have checksum logic built into them; credit card numbers are something like this. So I don't know if you've ever tried to type in your credit card number in a form. Like, the outline goes red. It'll tell you there's an error and you've not submitted it. Nobody's making a background request to your bank. And the bank is like, wait a minute; this is a bad card number. +The validation logic on the front end just immediately was able to tell the number is wrong. And that's because there are some checks and logic built in such that your number can be almost like self-verifying. We don't know that it's Stephanie's number, but we do know that it is a valid Mastercard. +STEPHANIE: Yeah, that's really interesting because, you know, I know that there are just various combinations of digits in a credit card number that are straight up and valid. And I think that's another example of something that is more like an identifier as well. +JOËL: You're right. I think so. It identifies a particular card, a piece of plastic that you have, and maybe line of credit or something like that. I'm not sure what the underlying modeling is exactly. But as a user of that credit card, [laughs] it represents a piece of plastic in my pocket. And that is a number that other services can use to talk to the card issuer. So it's an ID that you can use to make requests to Visa, or MasterCard, or whoever. +So I think you're right; that does fall under the umbrella of a third-party ID. I think I probably would tend to try to store that as a string based on this conversation rather than as an integer, even though it is all numbers. I say that, though, and, of course, now I'm going to get people tweeting at me saying, "Did you know that American Express sometimes put a letter in their credit card numbers?" +STEPHANIE: Oh, man. That would really throw a wrench in my understanding of how credit cards work. +JOËL: [laughs] But, again, if you store it as a string, it doesn't matter. +STEPHANIE: I'm really interested in the idea that a lot of these things we're talking about, you know, are often collected in forms and saved in our applications. Because we need to save information about our users in the context of whatever domain our application is working in. And I can kind of see it going a couple of ways where it's either, like, don't give that too much thought. +Or we try to introduce a library that does a lot to make sure that it's kind of covered all of the different cases. Or, like, it's really covered kind of how we've been talking about credit card numbers and phone numbers, like, a really wide breadth of logic that exists because of the way that they are very prevalent in the human world, at least. +And I'm curious, at what point do you think, you know, like, writing that first migration, how much energy would you put into making sure that those values are normalized correctly or that you're doing the right thing with those pieces of data? +JOËL: I think, based on this conversation, I would probably lean into doing minimal normalization. And I think the thing that's special about this type of number that we're talking about is that we don't need to do any logic on it internally. We typically only use it when calling out to some third-party system. And assuming that third-party system will accept that identifier in its raw form, non-normalized, then why do I need to care or put that effort in? +STEPHANIE: Yeah, that's a really interesting point. I think it definitely depends on what you're doing with it, right? Like, if you're a payment platform, obviously, you want to make sure that you get those credit card [laughs] values right and the way that you operate on them is as robust as possible. But for most applications, you might just be displaying the phone number, and that's about it. And minimal normalization and just formatting based on the way that your application handles it seems reasonable enough. +JOËL: I think the main thing you need to be able to do with that number is to make a call to that third-party service system and have it work. So a phone number you need to be able to call it and connect to the right person on the other end. With a credit card number, you need to be able to charge it, and we need to be able to charge it successfully. That's really the main thing that you're concerned with it. If you can do that without normalizing, then you're fine. +Now, you might need validating, which I think is a separate thing from normalizing. And that's really interesting because you can get all this fancy validation logic to check that there's the correct number of digits in the phone number or in the credit card and all that. And that's great. But you can also sometimes just try it. So I think we see this really commonly with things like email validation where we don't really trust that we can validate emails. Instead, we send you an email with a confirmation link. And the validation is that you were able to receive that and click that confirmation link. +STEPHANIE: Oh yeah, that's an interesting way. I've never thought about that. But a way that we've solved that problem without having to accommodate every single way a person might try to input their email. +JOËL: Similarly, you could do for a phone number, send a text with a confirmation number. And if you can receive that, then your phone number is good. And if you can't, then try to input your phone number again, assuming I'm dealing with a provider that can send to most numbers. I don't have to deal with all of the region-specific variations on how phone numbers work. +Payments are really interesting because, typically, that is the main mode that you're trying to use them. It's not even like a validation thing. It's that we're going to make a call to your bank right now. And if this card gets declined, you're going to have to put your number in again. +STEPHANIE: Yeah, I've certainly seen some differing trends over time around how those inputs are validated, though, right? Like, there are some websites that give you that real-time feedback. And, as a user, I think for me, it depends on whether or not I like it, right? It's, like, I've certainly encountered forms where I am like, oh, I'm appreciative that they're doing some input masking so that I don't accidentally type in a value that they are not willing to accept, and other times where the validation ends up getting in the way. When do you think that real-time feedback is important? +JOËL: So I think it's all about shortening the cycle of making a mistake and fixing it. So, you know, it's annoying if you typo your credit card number, and then you submit it. And it takes a few seconds to go back to the provider. And then, oh, it comes back up and says, "Sorry, that was wrong." And then you've got to figure out what went wrong. +If they had some logic that did that checksum math or something like that and said, "Wait a minute, this number is wrong," then you could fix it immediately without having to do a full-page submit and potentially lose or have to reload data that you filled in and if it's a larger form. So to get functional, you don't need that. But it's a nice layer on top of things to be able to have a shorter feedback loop where you immediately get feedback that tells you, wait a minute, that card number is not quite right. Maybe consider don't hitting that submit button. +STEPHANIE: Yeah, I think it also definitely depends on the goals of your system. I'm remembering now that article you mentioned from the UK government's design system. I was perusing that. And I found that they have some very explicit guidelines around form inputs because part of their goal is to make this portal as accessible as possible for all of their citizens. +And one thing that I remember was really interesting about how they considered their users was how if you enter a phone number, you can use the phone keypad-style of input. And the justification was that a lot of people are using this on mobile, so we want to make sure that we make this as accessible as possible for them since not everyone has access to a computer. And I thought it was really cool that they justified their reasoning. +And I think they even have all of this stuff open to feedback. So I had found a GitHub issue, I think, called, like, telephone numbers. And they're like, hey, like, we want to hear your thoughts about how telephone numbers should be received as inputs and whether this is working for you. And I thought that was a really committed way to make sure that the way that the system is implemented really reflects the user's needs. +JOËL: Yeah. And what's really cool about HTML is that we now have the ability to kind of decouple some of these things. And so, you might be typing in a text input, but you want to limit certain characters. You only want to be able to type in number characters. Does that mean that you have to use a number input? Well, not necessarily. With HTML5, you can put a regular expression pattern to limit what can be typed in this input. +You can also have an input mode, which, for mobile, will control which keyboard shows up. Or it won't control; it tells the mobile operating system or the browser what you would like them to show, and it's up to them to implement that. And so, like you were saying, for a phone number, even if you're typing it into a, let's say, text input because you want to be able to...maybe the user wants to put in whitespace, or dashes, or whatever. But you still want that number pad to show up by putting an input mode numeric on it. You can get that keyboard, even though you're not in a numeric input. +STEPHANIE: Yeah, I think that's a blessing and a curse that we do have these separate layers of abstraction, right? Because, on one hand, it gives us more flexibility. And then I've also seen it just run amok [laughs] and cause a lot of confusion about what being the source of truth, but I think that's a conversation for another day. +JOËL: Yep. Form design accessibility, keyboard inputs. So yeah, I think coming back to the core question of today, when is a number maybe not a number? +STEPHANIE: That's a big question that I think only the developer with the task at hand can answer. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël gives a recap after attending RailsConf 2023 in Atlanta, Georgia (and yes, there was karaoke! 🎤 🎶). Stephanie plugs the The Tightly Coupled Book Club Podcast from friends and fellow thoughtboters Aji and Mina Slater where they're reading The Rails Guides from cover to cover and treating it like a book club and having a discussions about the documentation as they read it together.

+ +

Stemming from a Twitter thread by Joël, their main topic focuses on not all numbers being numbers. So: if someone is submitting a phone number through a form:

+ +
    +
  • How would you store that in the database?
    • +
  • Would you store it as a string? Because sometimes it comes with some extra formatting.
    • +
  • Would you normalize it and try to store it as an integer because it's a number?
    • +
+ +

Thoughts, Dear Listener?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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: I've just returned from attending RailsConf 2023 in Atlanta, Georgia, and it was so much fun. I got a chance to attend some really good talks. I got a chance to connect with other people in the community. I always love the hallway track or any of the events that happen in the evenings after the conferences. It's a lot of fun.

+ +

STEPHANIE: Nice. I found it funny that you emphasized just returned because you literally walked through the door of your home and then got online to record this podcast with me. [laughs]

+ +

JOËL: Productivity.

+ +

STEPHANIE: What were some of your highlights from the conference?

+ +

JOËL: I really appreciated a talk by Elle Meredith about how to say no. And she gave...I think it was nine sort of different ways that you might want to have a conversation about saying no to a request. They're almost like design patterns but for interpersonal conversations. And so she covered situations where you might want to say no to maybe someone who's higher up in a hierarchy than you, so a manager.

+ +

But also, what it's like sometimes when it's the other way around if you're a manager and you have to say no to someone who reports to you, and how to handle some of those conversations. So I really appreciated the nuance that she had to share. And I think the strategies were just really practical.

+ +

STEPHANIE: That's awesome. Yeah, I know we, as developers, love some good patterns and frameworks. That actually reminds me of something else that I'd read recently, a newsletter called Culture Study by this journalist Anne Helen Petersen. She recently sent out a dispatch about how to say no or decline requests through email. And I was just thinking that it's such a challenging thing to do. But having a script or seeing examples of how other people do it is really helpful to just make it easier the next time that you want to say no, but then you're not sure how.

+ +

JOËL: It's not easy to say no. I think most people want to please, and it's much easier to say yes. And maybe even you want to believe that you can say yes, that you can do everything with limited resources and not have to prioritize. And then, of course, reality hits you, and you're in a worse situation than if you'd said no upfront or had at least an honest conversation about the limitations that we have and the prioritization that needs to happen.

+ +

STEPHANIE: Yeah, absolutely. So, over in the thoughtbot Slack, I saw a lot of really awesome praise and even photos from the conference, including stuff about a thoughtbot-sponsored event that we hosted over at RailsConf. What was that like?

+ +

JOËL: That was so much fun. So we hosted an event out in Centennial Park after day one and just had some lawn games, some snacks, some drinks. And people just came to hang out in the park and had a good time. And I got to chat with a lot of people. I think it somehow just felt really relaxed yet really social.

+ +

Sometimes when you're in the hallway in the convention center, you'll see groups of people talking, but also kind of people awkwardly walking around and struggling to connect. And there are just so many people around. And if you don't know anyone, it can be really hard to kind of break in. And I felt that this setting...I'm not sure exactly why; maybe it was a smaller amount of people. Maybe it's because it's a more relaxed atmosphere. You're outside. Everyone was kind of mingling and talking and seemed to be having a good time.

+ +

STEPHANIE: That's really cool. I'm so bummed to have missed it. Yeah, I hear you about the hallway track. It's like you're still kind of, you know, either in a convention center or a hotel, so there is just that vibe of formality. And taking it out of that venue and making it super casual, you know, I think that also almost allows people to not talk about tech, or the conference, or anything work-related and just have fun.

+ +

JOËL: Definitely. Although there's definitely fun that happens in all sorts of ways after the conference as well. One of the evenings, I went out with a few other thoughtboters and some other attendees at the conference; we went to a karaoke bar.

+ +

STEPHANIE: That sounds like a lot of fun. I think that's become almost a tradition for the thoughtbot crew whenever we do things out in the world, karaoke. And I'm trying to get escape rooms to be a conference tradition among my group of friends. So you and I, we participated in escape room the last conference that we were at together, and that was a lot of fun. So this is a thing that I hope to keep doing [laughs] next time I see you in person.

+ +

JOËL: We didn't just participate. We broke the record.

+ +

STEPHANIE: It's true. Yeah, I didn't want to brag on the podcast. But we did break the record. And we got to, like, write our names on a little poster to put in the office. And I hope it's still there, at that escape room company in Providence, Rhode Island.

+ +

JOËL: I'd be curious to hear from some of our listeners what some of their traditions are when they go to a conference. Do you have something that you like to do with your conference friends when you meet up? Let us know at hosts@bikeshed.fm. And we'll give you a shout-out on one of the upcoming episodes. So, Stephanie, what's new in your world?

+ +

STEPHANIE: Speaking of friends and community, I have a podcast to plug today. So our friends and fellow thoughtboters and married couple Aji and Mina Slater, they just launched a podcast called The Tightly Coupled Book Club Podcast. And what they're doing is reading The Rails Guides from cover to cover and kind of treating it like a book club and having a discussion about the documentation as they read it together.

+ +

And I listened to the first two episodes this morning, and I really enjoyed it. I thought it was such a cool idea and a really great format as a person who enjoys talking about books and things I've read with you. I mean, sometimes we've joked that this is kind of like our two-person book club. But it's really cool to listen in on other people who are, you know, are really knowledgeable, or have a lot of experience about a thing, and then also share their experience reading something as they come across it. I thought that was really interesting too. There's a real-time aspect of it that I liked.

+ +

JOËL: I love the idea of taking the book club concept and then reading the Rails Guides. What a really original idea.

+ +

STEPHANIE: It's funny because the Rails Guides do kind of read like a book. I went on to the documentation today just to kind of give myself a refresher as I was listening. And you can download the guides on your Kindle. So, in some ways, they've kind of leaned into that format. And since a lot of it is also just, like, prose, it is more like paragraphs rather than quick bits or API reference.

+ +

JOËL: Right, right. It's something that's meant to be read in larger chunks rather than just found through a search and then referencing one entry in a list of methods or something like that.

+ +

STEPHANIE: Yeah. I think my other favorite part about doing an idea like this is I think we all kind of have our own different experiences with the Rails official docs and guides. And I really liked that they're just like, yeah, like, you know, the way that an individual developer approaches the documentation can be totally different. And they kind of talk about how they do it or how they don't do it. Kind of all with the intention of wanting to better understand Rails and also wanting to better support people who want to get into Rails and are kind of entering the universe from the documentation for the first time.

+ +

JOËL: Yeah, and I think the Rails Guides, in particular, are often that first point of contact for a lot of newer Rails developers. I know that, for myself, when I was first getting into Rails, I was on those guides all the time. Between that and cherry-picking examples from the Michael Hartl Rails tutorial, that's kind of how I learned Rails.

+ +

STEPHANIE: Yeah, I like that a lot. For other folks who want to hear more about just Mina and Aji's experience with the Rails Guides, you should all check out that podcast.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So this is a conversation we had the other day, and I'm curious what your take is on this. If someone is submitting a phone number through a form, how would you store that in the database? Would you store it as a string? Because sometimes it comes with some extra formatting. Would you normalize it and try to store it as an integer because it's a number? What's your take?

+ +

STEPHANIE: Okay, to answer that question, I think I'm going to gripe a little bit first because the thing with phone numbers is that there are so many ways to format them. So, when you were saying, like, oh, you know, how would you input a number? I'm like; I don't know. Even if I were to write down a phone number on any given day, would I add the parentheses? Would I include the dashes? Do I add the country code? It honestly really depends.

+ +

And it's just totally different just based on what the form is asking of me or what channel I'm doing it in. So I think phone numbers is an interesting example because there are so many ways of representing it. But I think that actually also answers the way that I would do it is saving it as a string. Because while a phone number is made up of numbers, it's not exactly a numerical value.

+ +

JOËL: You're hitting on something pretty deep here about the fundamental nature of what a phone number is. What do you mean by saying it's not numeric?

+ +

STEPHANIE: I guess it doesn't mean anything in mathematical terms, I suppose, is what I was trying to get at. Like, it happens to be in the U.S., at least, you know.

+ +

JOËL: Always gotta qualify that, right?

+ +

STEPHANIE: Right. It happens to be a 10-digit identifier, I suppose. I almost said number there, but I think I'm trying to avoid it for the sake of my argument. But it's not necessarily something we would try to do arithmetic on. It's not something that...

+ +

JOËL: I'm kind of laughing at the idea of trying to do math on a phone number, adding two phone numbers together, doing some sort of, I don't know, add 20% to your phone number. Like, what does that even mean?

+ +

STEPHANIE: Yeah, absolutely. It's something that mostly remains static, right? It's like when it changes, that means something different. It means that the way that you would reach someone via a phone call or just that kind of communication is more of an event that has changed rather than the value transforming doesn't mean anything on its own.

+ +

JOËL: So you mentioned that this is not the kind of number that you can do arithmetic on. That kind of reminded me of an article from the UK's I want to say government design guidelines and how to design web forms that are going to be used by any service that's part of the UK Government. And they have this category of numbers that they call non-incrementable.

+ +

And their suggestion is that even though these things are represented as numbers, they should not use the HTML number input for them because you're never going to hit that little plus or minus arrow to go up and down and change the number. And that, instead, it should just be a regular text input.

+ +

STEPHANIE: Yeah, that's interesting because the idea of incrementing, for me, is definitely more attributed to the idea of a numerical value where it's a number and then what that number represents. So it could be weight. It could be money. It could be some other measurement. Another one could be quantity, right? If you have a shopping cart or something, and you're incrementing that value because you want to buy more of whatever item. That, to me, is where I see that type of input more frequently.

+ +

And so it would make sense that, you know, a phone number where the person is usually inputting a fixed thing that, you know, because that is not something that they can change, or they are wanting to change in that form, would be represented with a different HTML input.

+ +

JOËL: I don't know about you, but I feel like when I'm having a conversation with someone, occasionally, they'll just sort of mention something that my ears will kind of prick up because it feels like a keyword. And you mentioned earlier the keyword identifier, that a phone number to you feels more like an identifier than a number. And I want to dig into that because that feels really key to this conversation.

+ +

STEPHANIE: Yeah. I think there are a lot of things that happen to have numbers in them because that's the characters we use to denote some kind of unique or mostly unique value [laughs] of something. So, like, most people have a phone number, some people don't, some people may have multiple. But, usually, that phone number is tied to a person or a business or some kind of...it's like a record of how to reach someone.

+ +

JOËL: Yeah. I guess to a certain extent, a phone number is like a...it's not an ID for a person, but it's an ID for a phone, or for a SIM card, or a line, an account, something like that that's publicly shared out. But even though it's publicly shared out, it's effectively...I guess you might call it a third-party ID by the phone companies. If they're supposed to be globally unique, you might say the global telecoms consortium that have come up with this set of rules.

+ +

STEPHANIE: [laughs] Yes, we're clearly not telecommunications experts over here [laughs] or just have a, you know, regular human-level understanding of how telephones work. [laughs]

+ +

JOËL: But I think that's a really interesting idea because I think my instinct with phone numbers is I want to normalize them when I get them through a form. And yet I have very strong instincts that anytime I get an ID from a third-party service, let's say I'm interacting with an API, and I get a new user through there. The ID from the third-party service is there. When I save it into my database, I will create a new primary key for that row because I want to own my own primary keys.

+ +

But I will have a row for that third-party ID, and I will make sure to not modify it. I will store it in its raw form. So why do I feel the need to normalize phone numbers? If they are third-party IDs, then maybe I should just be storing them in raw format as entered by the user. At the very least, maybe I should store them as strings rather than trying to turn them into numbers.

+ +

STEPHANIE: Yeah, that's interesting. I mean, I do think phone numbers are a bit of an exception here in that you could think of it as a third-party ID. But it's also so ubiquitous in how our society functions. And the way people use it, it's like it's not a single service that this is owned by where you want to make sure that you're capturing it the way that that third party would. It's something that is so commonplace that it can end up having different forms because of the way that users interact with it.
+JOËL: I think one thing that's really interesting with third-party IDs is that even though they might come back as numbers like you said earlier, we don't do math on them. The main thing you ever do with a third-party ID is use it to make requests back to that third-party service. So, if I have a user I've pulled from some other service and I ever want to talk to that service again, I would need to use that third-party ID that I have stored in order to make sure that everything stays in sync.

+ +

That's kind of what we do with a phone number, right? We store it. And then the reason we might want to store a phone number is because we might want to programmatically make a phone call or send a text message that's interacting back with that telecom's world. We might want a human to do that. But the effect is still kind of the same.

+ +

We're not doing any transformations or work on it internally within the software. It's always when we want to make some kind of phone call, either manually by a person or automatically with a computer. And the only way we can do that and reach the right person is by using the ID that was given to us.

+ +

STEPHANIE: Yeah, that's a really good point. I mean, I have seen many applications that do hand-roll their own validation or normalization on phone numbers. But I do think that there is a library for this published by Google I think. It's called Libphonenumber. And so it's an open-source library for parsing, validating, and formatting phone numbers for, I think, most countries. It's very comprehensive.

+ +

JOËL: I think the difference maybe with a phone number and a form where you might want to do a little bit of polishing on it is that it is manually entered by a user. It definitely needs validation because a user manually typing in an ID into a form absolutely could have an error in it. Normalizing it for storage purposes, maybe, but at the very least, yeah, it needs to be validated because someone hand-typing in an ID is not something you want to rely on too heavily.

+ +

STEPHANIE: Yeah. I mean, I'm curious if we can extrapolate this conversation further beyond phone numbers. It sounds like we're talking about this idea that values with numbers in them should not always be treated as integers.

+ +

JOËL: Yes. And I have a great example of that that has actually burned me before.

+ +

STEPHANIE: Ooh, what is it?

+ +

JOËL: Zip codes. So, again, prefixing this, in the U.S., zip codes are typically a five-digit number. There's a variant that has more digits in it. And you'd think that you can store that...it's a five-digit number; you can store that in an integer column. And that does not work because you can start with a zero. And so if you store that as an integer, then what you really have is a four-digit integer. And then, when you try to put that back into an address, things get messed up.

+ +

So it's really important to store U.S. zip codes as strings so that you can keep that leading zero if you need it. And, of course, the moment you introduce international zip codes, or I think postal codes is what most countries call it, now, all of a sudden, you've got letters in addition to numbers. I wanted to share one of the most delightful postcode bits of knowledge that I have.

+ +

STEPHANIE: Please.

+ +

JOËL: Which is that in Canada, postal codes alternate letters and numbers. And Canada decided that Santa Claus needed his own Canadian zip code. And his zip code is H0H 0H0.

+ +

STEPHANIE: [laughs]

+ +

JOËL: H0H 0H0

+ +

STEPHANIE: Of course it is. I like that a lot. Makes sense that he would reside in Canada, up in the frigid, chilly north. So you've mentioned that you were burned by this. Does that mean you were working with an application that did store postal codes as integers? And what was the impact or consequence of that?

+ +

JOËL: So I was building a feature that required interacting with a zip code. And, as one does, I tested it out in development. And, as one also often does, I put in my own address. Now, I happen to live in Boston, and my zip code starts with a zero. So I happen to live in the one place that has that weird edge case. And immediately when I saw in dev how things happen, I was like, wait a minute, that's broken. That's not going to work.

+ +

STEPHANIE: Yeah. Wow. I wonder if that has just been impacting users for a long time before that discovery.

+ +

JOËL: It probably depends on the application, right? I guess you could...if you introduce that as a problem, you could try to add hacks on hacks to make it better. So you store it as an integer, but then when you get the integer out of the database, and you need to use it as an address, you then reformat it back. So you left-pad the number with zeros.

+ +

STEPHANIE: Yeah, I can see some really interesting ways of trying to work around that.

+ +

JOËL: But yeah, I think the best practice is definitely store your zip/postal codes as a string, not as an integer.

+ +

STEPHANIE: I wonder what it is about these types of values that make us think that they are numbers or want to store them as integers. I think that the Rails default is to store primary keys in integers. And if you wanted to use UUIDs, for example, instead, you do have to have done that initial setup.

+ +

I'm curious about the origin of using ints. And I know that that's like a whole story [laughs] in terms of the bite-size of that value. But yeah, it's just one of those origin stories that I'm wondering if that has kind of impacted our understanding of what primary keys look like.

+ +

JOËL: At its core, I think this goes back to what we were talking about earlier. Primary keys the default in Rails is an auto-incrementing integer. And we store it as an integer so that the database can do a plus-one on it every time we insert another record. We don't want to do that with zip codes or with phone numbers. Now, quite possibly, within the U.S. Postal Service or whatever the standard is for establishing phone numbers, they might, because these are numbers, they might be doing some kind of incrementing somewhere.

+ +

But there are patterns, definitely, that have been established. But they're not always necessarily incrementing. And they're not transparent to us in a way that we would care about them normally in an app. And we might care that, oh, we know that if it has a leading zero in the zip code, you're in this broad region or something like that. But, again, this is not really doing math so much as it's knowing the pattern in the ID.

+ +

I know some ID-like numbers have checksum logic built into them; credit card numbers are something like this. So I don't know if you've ever tried to type in your credit card number in a form. Like, the outline goes red. It'll tell you there's an error and you've not submitted it. Nobody's making a background request to your bank. And the bank is like, wait a minute; this is a bad card number.

+ +

The validation logic on the front end just immediately was able to tell the number is wrong. And that's because there are some checks and logic built in such that your number can be almost like self-verifying. We don't know that it's Stephanie's number, but we do know that it is a valid Mastercard.

+ +

STEPHANIE: Yeah, that's really interesting because, you know, I know that there are just various combinations of digits in a credit card number that are straight up and valid. And I think that's another example of something that is more like an identifier as well.

+ +

JOËL: You're right. I think so. It identifies a particular card, a piece of plastic that you have, and maybe line of credit or something like that. I'm not sure what the underlying modeling is exactly. But as a user of that credit card, [laughs] it represents a piece of plastic in my pocket. And that is a number that other services can use to talk to the card issuer. So it's an ID that you can use to make requests to Visa, or MasterCard, or whoever.

+ +

So I think you're right; that does fall under the umbrella of a third-party ID. I think I probably would tend to try to store that as a string based on this conversation rather than as an integer, even though it is all numbers. I say that, though, and, of course, now I'm going to get people tweeting at me saying, "Did you know that American Express sometimes put a letter in their credit card numbers?"

+ +

STEPHANIE: Oh, man. That would really throw a wrench in my understanding of how credit cards work.

+ +

JOËL: [laughs] But, again, if you store it as a string, it doesn't matter.

+ +

STEPHANIE: I'm really interested in the idea that a lot of these things we're talking about, you know, are often collected in forms and saved in our applications. Because we need to save information about our users in the context of whatever domain our application is working in. And I can kind of see it going a couple of ways where it's either, like, don't give that too much thought.

+ +

Or we try to introduce a library that does a lot to make sure that it's kind of covered all of the different cases. Or, like, it's really covered kind of how we've been talking about credit card numbers and phone numbers, like, a really wide breadth of logic that exists because of the way that they are very prevalent in the human world, at least.

+ +

And I'm curious, at what point do you think, you know, like, writing that first migration, how much energy would you put into making sure that those values are normalized correctly or that you're doing the right thing with those pieces of data?

+ +

JOËL: I think, based on this conversation, I would probably lean into doing minimal normalization. And I think the thing that's special about this type of number that we're talking about is that we don't need to do any logic on it internally. We typically only use it when calling out to some third-party system. And assuming that third-party system will accept that identifier in its raw form, non-normalized, then why do I need to care or put that effort in?

+ +

STEPHANIE: Yeah, that's a really interesting point. I think it definitely depends on what you're doing with it, right? Like, if you're a payment platform, obviously, you want to make sure that you get those credit card [laughs] values right and the way that you operate on them is as robust as possible. But for most applications, you might just be displaying the phone number, and that's about it. And minimal normalization and just formatting based on the way that your application handles it seems reasonable enough.

+ +

JOËL: I think the main thing you need to be able to do with that number is to make a call to that third-party service system and have it work. So a phone number you need to be able to call it and connect to the right person on the other end. With a credit card number, you need to be able to charge it, and we need to be able to charge it successfully. That's really the main thing that you're concerned with it. If you can do that without normalizing, then you're fine.

+ +

Now, you might need validating, which I think is a separate thing from normalizing. And that's really interesting because you can get all this fancy validation logic to check that there's the correct number of digits in the phone number or in the credit card and all that. And that's great. But you can also sometimes just try it. So I think we see this really commonly with things like email validation where we don't really trust that we can validate emails. Instead, we send you an email with a confirmation link. And the validation is that you were able to receive that and click that confirmation link.

+ +

STEPHANIE: Oh yeah, that's an interesting way. I've never thought about that. But a way that we've solved that problem without having to accommodate every single way a person might try to input their email.

+ +

JOËL: Similarly, you could do for a phone number, send a text with a confirmation number. And if you can receive that, then your phone number is good. And if you can't, then try to input your phone number again, assuming I'm dealing with a provider that can send to most numbers. I don't have to deal with all of the region-specific variations on how phone numbers work.

+ +

Payments are really interesting because, typically, that is the main mode that you're trying to use them. It's not even like a validation thing. It's that we're going to make a call to your bank right now. And if this card gets declined, you're going to have to put your number in again.

+ +

STEPHANIE: Yeah, I've certainly seen some differing trends over time around how those inputs are validated, though, right? Like, there are some websites that give you that real-time feedback. And, as a user, I think for me, it depends on whether or not I like it, right? It's, like, I've certainly encountered forms where I am like, oh, I'm appreciative that they're doing some input masking so that I don't accidentally type in a value that they are not willing to accept, and other times where the validation ends up getting in the way. When do you think that real-time feedback is important?

+ +

JOËL: So I think it's all about shortening the cycle of making a mistake and fixing it. So, you know, it's annoying if you typo your credit card number, and then you submit it. And it takes a few seconds to go back to the provider. And then, oh, it comes back up and says, "Sorry, that was wrong." And then you've got to figure out what went wrong.

+ +

If they had some logic that did that checksum math or something like that and said, "Wait a minute, this number is wrong," then you could fix it immediately without having to do a full-page submit and potentially lose or have to reload data that you filled in and if it's a larger form. So to get functional, you don't need that. But it's a nice layer on top of things to be able to have a shorter feedback loop where you immediately get feedback that tells you, wait a minute, that card number is not quite right. Maybe consider don't hitting that submit button.

+ +

STEPHANIE: Yeah, I think it also definitely depends on the goals of your system. I'm remembering now that article you mentioned from the UK government's design system. I was perusing that. And I found that they have some very explicit guidelines around form inputs because part of their goal is to make this portal as accessible as possible for all of their citizens.

+ +

And one thing that I remember was really interesting about how they considered their users was how if you enter a phone number, you can use the phone keypad-style of input. And the justification was that a lot of people are using this on mobile, so we want to make sure that we make this as accessible as possible for them since not everyone has access to a computer. And I thought it was really cool that they justified their reasoning.

+ +

And I think they even have all of this stuff open to feedback. So I had found a GitHub issue, I think, called, like, telephone numbers. And they're like, hey, like, we want to hear your thoughts about how telephone numbers should be received as inputs and whether this is working for you. And I thought that was a really committed way to make sure that the way that the system is implemented really reflects the user's needs.

+ +

JOËL: Yeah. And what's really cool about HTML is that we now have the ability to kind of decouple some of these things. And so, you might be typing in a text input, but you want to limit certain characters. You only want to be able to type in number characters. Does that mean that you have to use a number input? Well, not necessarily. With HTML5, you can put a regular expression pattern to limit what can be typed in this input.

+ +

You can also have an input mode, which, for mobile, will control which keyboard shows up. Or it won't control; it tells the mobile operating system or the browser what you would like them to show, and it's up to them to implement that. And so, like you were saying, for a phone number, even if you're typing it into a, let's say, text input because you want to be able to...maybe the user wants to put in whitespace, or dashes, or whatever. But you still want that number pad to show up by putting an input mode numeric on it. You can get that keyboard, even though you're not in a numeric input.

+ +

STEPHANIE: Yeah, I think that's a blessing and a curse that we do have these separate layers of abstraction, right? Because, on one hand, it gives us more flexibility. And then I've also seen it just run amok [laughs] and cause a lot of confusion about what being the source of truth, but I think that's a conversation for another day.

+ +

JOËL: Yep. Form design accessibility, keyboard inputs. So yeah, I think coming back to the core question of today, when is a number maybe not a number?

+ +

STEPHANIE: That's a big question that I think only the developer with the task at hand can answer.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël gives a recap after attending RailsConf 2023 in Atlanta, Georgia (and yes, there was karaoke! 🎤 🎶). Stephanie plugs the The Tightly Coupled Book Club Podcast from friends and fellow thoughtboters Aji and Mina Slater where they're reading The Rails Guides from cover to cover and treating it like a book club and having a discussions about the documentation as they read it together.

+ +

Stemming from a Twitter thread by Joël, their main topic focuses on not all numbers being numbers. So: if someone is submitting a phone number through a form:

+ +
    +
  • How would you store that in the database?
    • +
  • Would you store it as a string? Because sometimes it comes with some extra formatting.
    • +
  • Would you normalize it and try to store it as an integer because it's a number?
    • +
+ +

Thoughts, Dear Listener?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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: I've just returned from attending RailsConf 2023 in Atlanta, Georgia, and it was so much fun. I got a chance to attend some really good talks. I got a chance to connect with other people in the community. I always love the hallway track or any of the events that happen in the evenings after the conferences. It's a lot of fun.

+ +

STEPHANIE: Nice. I found it funny that you emphasized just returned because you literally walked through the door of your home and then got online to record this podcast with me. [laughs]

+ +

JOËL: Productivity.

+ +

STEPHANIE: What were some of your highlights from the conference?

+ +

JOËL: I really appreciated a talk by Elle Meredith about how to say no. And she gave...I think it was nine sort of different ways that you might want to have a conversation about saying no to a request. They're almost like design patterns but for interpersonal conversations. And so she covered situations where you might want to say no to maybe someone who's higher up in a hierarchy than you, so a manager.

+ +

But also, what it's like sometimes when it's the other way around if you're a manager and you have to say no to someone who reports to you, and how to handle some of those conversations. So I really appreciated the nuance that she had to share. And I think the strategies were just really practical.

+ +

STEPHANIE: That's awesome. Yeah, I know we, as developers, love some good patterns and frameworks. That actually reminds me of something else that I'd read recently, a newsletter called Culture Study by this journalist Anne Helen Petersen. She recently sent out a dispatch about how to say no or decline requests through email. And I was just thinking that it's such a challenging thing to do. But having a script or seeing examples of how other people do it is really helpful to just make it easier the next time that you want to say no, but then you're not sure how.

+ +

JOËL: It's not easy to say no. I think most people want to please, and it's much easier to say yes. And maybe even you want to believe that you can say yes, that you can do everything with limited resources and not have to prioritize. And then, of course, reality hits you, and you're in a worse situation than if you'd said no upfront or had at least an honest conversation about the limitations that we have and the prioritization that needs to happen.

+ +

STEPHANIE: Yeah, absolutely. So, over in the thoughtbot Slack, I saw a lot of really awesome praise and even photos from the conference, including stuff about a thoughtbot-sponsored event that we hosted over at RailsConf. What was that like?

+ +

JOËL: That was so much fun. So we hosted an event out in Centennial Park after day one and just had some lawn games, some snacks, some drinks. And people just came to hang out in the park and had a good time. And I got to chat with a lot of people. I think it somehow just felt really relaxed yet really social.

+ +

Sometimes when you're in the hallway in the convention center, you'll see groups of people talking, but also kind of people awkwardly walking around and struggling to connect. And there are just so many people around. And if you don't know anyone, it can be really hard to kind of break in. And I felt that this setting...I'm not sure exactly why; maybe it was a smaller amount of people. Maybe it's because it's a more relaxed atmosphere. You're outside. Everyone was kind of mingling and talking and seemed to be having a good time.

+ +

STEPHANIE: That's really cool. I'm so bummed to have missed it. Yeah, I hear you about the hallway track. It's like you're still kind of, you know, either in a convention center or a hotel, so there is just that vibe of formality. And taking it out of that venue and making it super casual, you know, I think that also almost allows people to not talk about tech, or the conference, or anything work-related and just have fun.

+ +

JOËL: Definitely. Although there's definitely fun that happens in all sorts of ways after the conference as well. One of the evenings, I went out with a few other thoughtboters and some other attendees at the conference; we went to a karaoke bar.

+ +

STEPHANIE: That sounds like a lot of fun. I think that's become almost a tradition for the thoughtbot crew whenever we do things out in the world, karaoke. And I'm trying to get escape rooms to be a conference tradition among my group of friends. So you and I, we participated in escape room the last conference that we were at together, and that was a lot of fun. So this is a thing that I hope to keep doing [laughs] next time I see you in person.

+ +

JOËL: We didn't just participate. We broke the record.

+ +

STEPHANIE: It's true. Yeah, I didn't want to brag on the podcast. But we did break the record. And we got to, like, write our names on a little poster to put in the office. And I hope it's still there, at that escape room company in Providence, Rhode Island.

+ +

JOËL: I'd be curious to hear from some of our listeners what some of their traditions are when they go to a conference. Do you have something that you like to do with your conference friends when you meet up? Let us know at hosts@bikeshed.fm. And we'll give you a shout-out on one of the upcoming episodes. So, Stephanie, what's new in your world?

+ +

STEPHANIE: Speaking of friends and community, I have a podcast to plug today. So our friends and fellow thoughtboters and married couple Aji and Mina Slater, they just launched a podcast called The Tightly Coupled Book Club Podcast. And what they're doing is reading The Rails Guides from cover to cover and kind of treating it like a book club and having a discussion about the documentation as they read it together.

+ +

And I listened to the first two episodes this morning, and I really enjoyed it. I thought it was such a cool idea and a really great format as a person who enjoys talking about books and things I've read with you. I mean, sometimes we've joked that this is kind of like our two-person book club. But it's really cool to listen in on other people who are, you know, are really knowledgeable, or have a lot of experience about a thing, and then also share their experience reading something as they come across it. I thought that was really interesting too. There's a real-time aspect of it that I liked.

+ +

JOËL: I love the idea of taking the book club concept and then reading the Rails Guides. What a really original idea.

+ +

STEPHANIE: It's funny because the Rails Guides do kind of read like a book. I went on to the documentation today just to kind of give myself a refresher as I was listening. And you can download the guides on your Kindle. So, in some ways, they've kind of leaned into that format. And since a lot of it is also just, like, prose, it is more like paragraphs rather than quick bits or API reference.

+ +

JOËL: Right, right. It's something that's meant to be read in larger chunks rather than just found through a search and then referencing one entry in a list of methods or something like that.

+ +

STEPHANIE: Yeah. I think my other favorite part about doing an idea like this is I think we all kind of have our own different experiences with the Rails official docs and guides. And I really liked that they're just like, yeah, like, you know, the way that an individual developer approaches the documentation can be totally different. And they kind of talk about how they do it or how they don't do it. Kind of all with the intention of wanting to better understand Rails and also wanting to better support people who want to get into Rails and are kind of entering the universe from the documentation for the first time.

+ +

JOËL: Yeah, and I think the Rails Guides, in particular, are often that first point of contact for a lot of newer Rails developers. I know that, for myself, when I was first getting into Rails, I was on those guides all the time. Between that and cherry-picking examples from the Michael Hartl Rails tutorial, that's kind of how I learned Rails.

+ +

STEPHANIE: Yeah, I like that a lot. For other folks who want to hear more about just Mina and Aji's experience with the Rails Guides, you should all check out that podcast.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So this is a conversation we had the other day, and I'm curious what your take is on this. If someone is submitting a phone number through a form, how would you store that in the database? Would you store it as a string? Because sometimes it comes with some extra formatting. Would you normalize it and try to store it as an integer because it's a number? What's your take?

+ +

STEPHANIE: Okay, to answer that question, I think I'm going to gripe a little bit first because the thing with phone numbers is that there are so many ways to format them. So, when you were saying, like, oh, you know, how would you input a number? I'm like; I don't know. Even if I were to write down a phone number on any given day, would I add the parentheses? Would I include the dashes? Do I add the country code? It honestly really depends.

+ +

And it's just totally different just based on what the form is asking of me or what channel I'm doing it in. So I think phone numbers is an interesting example because there are so many ways of representing it. But I think that actually also answers the way that I would do it is saving it as a string. Because while a phone number is made up of numbers, it's not exactly a numerical value.

+ +

JOËL: You're hitting on something pretty deep here about the fundamental nature of what a phone number is. What do you mean by saying it's not numeric?

+ +

STEPHANIE: I guess it doesn't mean anything in mathematical terms, I suppose, is what I was trying to get at. Like, it happens to be in the U.S., at least, you know.

+ +

JOËL: Always gotta qualify that, right?

+ +

STEPHANIE: Right. It happens to be a 10-digit identifier, I suppose. I almost said number there, but I think I'm trying to avoid it for the sake of my argument. But it's not necessarily something we would try to do arithmetic on. It's not something that...

+ +

JOËL: I'm kind of laughing at the idea of trying to do math on a phone number, adding two phone numbers together, doing some sort of, I don't know, add 20% to your phone number. Like, what does that even mean?

+ +

STEPHANIE: Yeah, absolutely. It's something that mostly remains static, right? It's like when it changes, that means something different. It means that the way that you would reach someone via a phone call or just that kind of communication is more of an event that has changed rather than the value transforming doesn't mean anything on its own.

+ +

JOËL: So you mentioned that this is not the kind of number that you can do arithmetic on. That kind of reminded me of an article from the UK's I want to say government design guidelines and how to design web forms that are going to be used by any service that's part of the UK Government. And they have this category of numbers that they call non-incrementable.

+ +

And their suggestion is that even though these things are represented as numbers, they should not use the HTML number input for them because you're never going to hit that little plus or minus arrow to go up and down and change the number. And that, instead, it should just be a regular text input.

+ +

STEPHANIE: Yeah, that's interesting because the idea of incrementing, for me, is definitely more attributed to the idea of a numerical value where it's a number and then what that number represents. So it could be weight. It could be money. It could be some other measurement. Another one could be quantity, right? If you have a shopping cart or something, and you're incrementing that value because you want to buy more of whatever item. That, to me, is where I see that type of input more frequently.

+ +

And so it would make sense that, you know, a phone number where the person is usually inputting a fixed thing that, you know, because that is not something that they can change, or they are wanting to change in that form, would be represented with a different HTML input.

+ +

JOËL: I don't know about you, but I feel like when I'm having a conversation with someone, occasionally, they'll just sort of mention something that my ears will kind of prick up because it feels like a keyword. And you mentioned earlier the keyword identifier, that a phone number to you feels more like an identifier than a number. And I want to dig into that because that feels really key to this conversation.

+ +

STEPHANIE: Yeah. I think there are a lot of things that happen to have numbers in them because that's the characters we use to denote some kind of unique or mostly unique value [laughs] of something. So, like, most people have a phone number, some people don't, some people may have multiple. But, usually, that phone number is tied to a person or a business or some kind of...it's like a record of how to reach someone.

+ +

JOËL: Yeah. I guess to a certain extent, a phone number is like a...it's not an ID for a person, but it's an ID for a phone, or for a SIM card, or a line, an account, something like that that's publicly shared out. But even though it's publicly shared out, it's effectively...I guess you might call it a third-party ID by the phone companies. If they're supposed to be globally unique, you might say the global telecoms consortium that have come up with this set of rules.

+ +

STEPHANIE: [laughs] Yes, we're clearly not telecommunications experts over here [laughs] or just have a, you know, regular human-level understanding of how telephones work. [laughs]

+ +

JOËL: But I think that's a really interesting idea because I think my instinct with phone numbers is I want to normalize them when I get them through a form. And yet I have very strong instincts that anytime I get an ID from a third-party service, let's say I'm interacting with an API, and I get a new user through there. The ID from the third-party service is there. When I save it into my database, I will create a new primary key for that row because I want to own my own primary keys.

+ +

But I will have a row for that third-party ID, and I will make sure to not modify it. I will store it in its raw form. So why do I feel the need to normalize phone numbers? If they are third-party IDs, then maybe I should just be storing them in raw format as entered by the user. At the very least, maybe I should store them as strings rather than trying to turn them into numbers.

+ +

STEPHANIE: Yeah, that's interesting. I mean, I do think phone numbers are a bit of an exception here in that you could think of it as a third-party ID. But it's also so ubiquitous in how our society functions. And the way people use it, it's like it's not a single service that this is owned by where you want to make sure that you're capturing it the way that that third party would. It's something that is so commonplace that it can end up having different forms because of the way that users interact with it.
+JOËL: I think one thing that's really interesting with third-party IDs is that even though they might come back as numbers like you said earlier, we don't do math on them. The main thing you ever do with a third-party ID is use it to make requests back to that third-party service. So, if I have a user I've pulled from some other service and I ever want to talk to that service again, I would need to use that third-party ID that I have stored in order to make sure that everything stays in sync.

+ +

That's kind of what we do with a phone number, right? We store it. And then the reason we might want to store a phone number is because we might want to programmatically make a phone call or send a text message that's interacting back with that telecom's world. We might want a human to do that. But the effect is still kind of the same.

+ +

We're not doing any transformations or work on it internally within the software. It's always when we want to make some kind of phone call, either manually by a person or automatically with a computer. And the only way we can do that and reach the right person is by using the ID that was given to us.

+ +

STEPHANIE: Yeah, that's a really good point. I mean, I have seen many applications that do hand-roll their own validation or normalization on phone numbers. But I do think that there is a library for this published by Google I think. It's called Libphonenumber. And so it's an open-source library for parsing, validating, and formatting phone numbers for, I think, most countries. It's very comprehensive.

+ +

JOËL: I think the difference maybe with a phone number and a form where you might want to do a little bit of polishing on it is that it is manually entered by a user. It definitely needs validation because a user manually typing in an ID into a form absolutely could have an error in it. Normalizing it for storage purposes, maybe, but at the very least, yeah, it needs to be validated because someone hand-typing in an ID is not something you want to rely on too heavily.

+ +

STEPHANIE: Yeah. I mean, I'm curious if we can extrapolate this conversation further beyond phone numbers. It sounds like we're talking about this idea that values with numbers in them should not always be treated as integers.

+ +

JOËL: Yes. And I have a great example of that that has actually burned me before.

+ +

STEPHANIE: Ooh, what is it?

+ +

JOËL: Zip codes. So, again, prefixing this, in the U.S., zip codes are typically a five-digit number. There's a variant that has more digits in it. And you'd think that you can store that...it's a five-digit number; you can store that in an integer column. And that does not work because you can start with a zero. And so if you store that as an integer, then what you really have is a four-digit integer. And then, when you try to put that back into an address, things get messed up.

+ +

So it's really important to store U.S. zip codes as strings so that you can keep that leading zero if you need it. And, of course, the moment you introduce international zip codes, or I think postal codes is what most countries call it, now, all of a sudden, you've got letters in addition to numbers. I wanted to share one of the most delightful postcode bits of knowledge that I have.

+ +

STEPHANIE: Please.

+ +

JOËL: Which is that in Canada, postal codes alternate letters and numbers. And Canada decided that Santa Claus needed his own Canadian zip code. And his zip code is H0H 0H0.

+ +

STEPHANIE: [laughs]

+ +

JOËL: H0H 0H0

+ +

STEPHANIE: Of course it is. I like that a lot. Makes sense that he would reside in Canada, up in the frigid, chilly north. So you've mentioned that you were burned by this. Does that mean you were working with an application that did store postal codes as integers? And what was the impact or consequence of that?

+ +

JOËL: So I was building a feature that required interacting with a zip code. And, as one does, I tested it out in development. And, as one also often does, I put in my own address. Now, I happen to live in Boston, and my zip code starts with a zero. So I happen to live in the one place that has that weird edge case. And immediately when I saw in dev how things happen, I was like, wait a minute, that's broken. That's not going to work.

+ +

STEPHANIE: Yeah. Wow. I wonder if that has just been impacting users for a long time before that discovery.

+ +

JOËL: It probably depends on the application, right? I guess you could...if you introduce that as a problem, you could try to add hacks on hacks to make it better. So you store it as an integer, but then when you get the integer out of the database, and you need to use it as an address, you then reformat it back. So you left-pad the number with zeros.

+ +

STEPHANIE: Yeah, I can see some really interesting ways of trying to work around that.

+ +

JOËL: But yeah, I think the best practice is definitely store your zip/postal codes as a string, not as an integer.

+ +

STEPHANIE: I wonder what it is about these types of values that make us think that they are numbers or want to store them as integers. I think that the Rails default is to store primary keys in integers. And if you wanted to use UUIDs, for example, instead, you do have to have done that initial setup.

+ +

I'm curious about the origin of using ints. And I know that that's like a whole story [laughs] in terms of the bite-size of that value. But yeah, it's just one of those origin stories that I'm wondering if that has kind of impacted our understanding of what primary keys look like.

+ +

JOËL: At its core, I think this goes back to what we were talking about earlier. Primary keys the default in Rails is an auto-incrementing integer. And we store it as an integer so that the database can do a plus-one on it every time we insert another record. We don't want to do that with zip codes or with phone numbers. Now, quite possibly, within the U.S. Postal Service or whatever the standard is for establishing phone numbers, they might, because these are numbers, they might be doing some kind of incrementing somewhere.

+ +

But there are patterns, definitely, that have been established. But they're not always necessarily incrementing. And they're not transparent to us in a way that we would care about them normally in an app. And we might care that, oh, we know that if it has a leading zero in the zip code, you're in this broad region or something like that. But, again, this is not really doing math so much as it's knowing the pattern in the ID.

+ +

I know some ID-like numbers have checksum logic built into them; credit card numbers are something like this. So I don't know if you've ever tried to type in your credit card number in a form. Like, the outline goes red. It'll tell you there's an error and you've not submitted it. Nobody's making a background request to your bank. And the bank is like, wait a minute; this is a bad card number.

+ +

The validation logic on the front end just immediately was able to tell the number is wrong. And that's because there are some checks and logic built in such that your number can be almost like self-verifying. We don't know that it's Stephanie's number, but we do know that it is a valid Mastercard.

+ +

STEPHANIE: Yeah, that's really interesting because, you know, I know that there are just various combinations of digits in a credit card number that are straight up and valid. And I think that's another example of something that is more like an identifier as well.

+ +

JOËL: You're right. I think so. It identifies a particular card, a piece of plastic that you have, and maybe line of credit or something like that. I'm not sure what the underlying modeling is exactly. But as a user of that credit card, [laughs] it represents a piece of plastic in my pocket. And that is a number that other services can use to talk to the card issuer. So it's an ID that you can use to make requests to Visa, or MasterCard, or whoever.

+ +

So I think you're right; that does fall under the umbrella of a third-party ID. I think I probably would tend to try to store that as a string based on this conversation rather than as an integer, even though it is all numbers. I say that, though, and, of course, now I'm going to get people tweeting at me saying, "Did you know that American Express sometimes put a letter in their credit card numbers?"

+ +

STEPHANIE: Oh, man. That would really throw a wrench in my understanding of how credit cards work.

+ +

JOËL: [laughs] But, again, if you store it as a string, it doesn't matter.

+ +

STEPHANIE: I'm really interested in the idea that a lot of these things we're talking about, you know, are often collected in forms and saved in our applications. Because we need to save information about our users in the context of whatever domain our application is working in. And I can kind of see it going a couple of ways where it's either, like, don't give that too much thought.

+ +

Or we try to introduce a library that does a lot to make sure that it's kind of covered all of the different cases. Or, like, it's really covered kind of how we've been talking about credit card numbers and phone numbers, like, a really wide breadth of logic that exists because of the way that they are very prevalent in the human world, at least.

+ +

And I'm curious, at what point do you think, you know, like, writing that first migration, how much energy would you put into making sure that those values are normalized correctly or that you're doing the right thing with those pieces of data?

+ +

JOËL: I think, based on this conversation, I would probably lean into doing minimal normalization. And I think the thing that's special about this type of number that we're talking about is that we don't need to do any logic on it internally. We typically only use it when calling out to some third-party system. And assuming that third-party system will accept that identifier in its raw form, non-normalized, then why do I need to care or put that effort in?

+ +

STEPHANIE: Yeah, that's a really interesting point. I think it definitely depends on what you're doing with it, right? Like, if you're a payment platform, obviously, you want to make sure that you get those credit card [laughs] values right and the way that you operate on them is as robust as possible. But for most applications, you might just be displaying the phone number, and that's about it. And minimal normalization and just formatting based on the way that your application handles it seems reasonable enough.

+ +

JOËL: I think the main thing you need to be able to do with that number is to make a call to that third-party service system and have it work. So a phone number you need to be able to call it and connect to the right person on the other end. With a credit card number, you need to be able to charge it, and we need to be able to charge it successfully. That's really the main thing that you're concerned with it. If you can do that without normalizing, then you're fine.

+ +

Now, you might need validating, which I think is a separate thing from normalizing. And that's really interesting because you can get all this fancy validation logic to check that there's the correct number of digits in the phone number or in the credit card and all that. And that's great. But you can also sometimes just try it. So I think we see this really commonly with things like email validation where we don't really trust that we can validate emails. Instead, we send you an email with a confirmation link. And the validation is that you were able to receive that and click that confirmation link.

+ +

STEPHANIE: Oh yeah, that's an interesting way. I've never thought about that. But a way that we've solved that problem without having to accommodate every single way a person might try to input their email.

+ +

JOËL: Similarly, you could do for a phone number, send a text with a confirmation number. And if you can receive that, then your phone number is good. And if you can't, then try to input your phone number again, assuming I'm dealing with a provider that can send to most numbers. I don't have to deal with all of the region-specific variations on how phone numbers work.

+ +

Payments are really interesting because, typically, that is the main mode that you're trying to use them. It's not even like a validation thing. It's that we're going to make a call to your bank right now. And if this card gets declined, you're going to have to put your number in again.

+ +

STEPHANIE: Yeah, I've certainly seen some differing trends over time around how those inputs are validated, though, right? Like, there are some websites that give you that real-time feedback. And, as a user, I think for me, it depends on whether or not I like it, right? It's, like, I've certainly encountered forms where I am like, oh, I'm appreciative that they're doing some input masking so that I don't accidentally type in a value that they are not willing to accept, and other times where the validation ends up getting in the way. When do you think that real-time feedback is important?

+ +

JOËL: So I think it's all about shortening the cycle of making a mistake and fixing it. So, you know, it's annoying if you typo your credit card number, and then you submit it. And it takes a few seconds to go back to the provider. And then, oh, it comes back up and says, "Sorry, that was wrong." And then you've got to figure out what went wrong.

+ +

If they had some logic that did that checksum math or something like that and said, "Wait a minute, this number is wrong," then you could fix it immediately without having to do a full-page submit and potentially lose or have to reload data that you filled in and if it's a larger form. So to get functional, you don't need that. But it's a nice layer on top of things to be able to have a shorter feedback loop where you immediately get feedback that tells you, wait a minute, that card number is not quite right. Maybe consider don't hitting that submit button.

+ +

STEPHANIE: Yeah, I think it also definitely depends on the goals of your system. I'm remembering now that article you mentioned from the UK government's design system. I was perusing that. And I found that they have some very explicit guidelines around form inputs because part of their goal is to make this portal as accessible as possible for all of their citizens.

+ +

And one thing that I remember was really interesting about how they considered their users was how if you enter a phone number, you can use the phone keypad-style of input. And the justification was that a lot of people are using this on mobile, so we want to make sure that we make this as accessible as possible for them since not everyone has access to a computer. And I thought it was really cool that they justified their reasoning.

+ +

And I think they even have all of this stuff open to feedback. So I had found a GitHub issue, I think, called, like, telephone numbers. And they're like, hey, like, we want to hear your thoughts about how telephone numbers should be received as inputs and whether this is working for you. And I thought that was a really committed way to make sure that the way that the system is implemented really reflects the user's needs.

+ +

JOËL: Yeah. And what's really cool about HTML is that we now have the ability to kind of decouple some of these things. And so, you might be typing in a text input, but you want to limit certain characters. You only want to be able to type in number characters. Does that mean that you have to use a number input? Well, not necessarily. With HTML5, you can put a regular expression pattern to limit what can be typed in this input.

+ +

You can also have an input mode, which, for mobile, will control which keyboard shows up. Or it won't control; it tells the mobile operating system or the browser what you would like them to show, and it's up to them to implement that. And so, like you were saying, for a phone number, even if you're typing it into a, let's say, text input because you want to be able to...maybe the user wants to put in whitespace, or dashes, or whatever. But you still want that number pad to show up by putting an input mode numeric on it. You can get that keyboard, even though you're not in a numeric input.

+ +

STEPHANIE: Yeah, I think that's a blessing and a curse that we do have these separate layers of abstraction, right? Because, on one hand, it gives us more flexibility. And then I've also seen it just run amok [laughs] and cause a lot of confusion about what being the source of truth, but I think that's a conversation for another day.

+ +

JOËL: Yep. Form design accessibility, keyboard inputs. So yeah, I think coming back to the core question of today, when is a number maybe not a number?

+ +

STEPHANIE: That's a big question that I think only the developer with the task at hand can answer.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+AxcrW-jN + + ]]> + + Joël Quenneville + Stephanie Minn + + + 383: Code as Storytelling with Nicole Zhu + https://bikeshed.thoughtbot.com/383 + 0a94927b-2cad-444f-8c9b-5fad288f16b0 + Tue, 09 May 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Engineering manager at Vox Media and author Nicole Zhu joins Stephanie on today's episode to discuss her writing practice. + +nicoledonut is a biweekly newsletter about the writing process and sustaining a creative life that features creative resources, occasional interviews with creative folks, short essays on writing and creativity, farm-to-table memes and TikToks, and features on what Nicole is currently writing, reading, and watching. + 43:02 + no + + + Engineering manager at Vox Media and author Nicole Zhu joins Stephanie on today's episode to discuss her writing practice. +nicoledonut is a biweekly newsletter about the writing process and sustaining a creative life that features creative resources, occasional interviews with creative folks, short essays on writing and creativity, farm-to-table memes and TikToks, and features on what Nicole is currently writing, reading, and watching. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Kieran Culkin on learning about billionaires filming Succession (https://www.tiktok.com/@esquire/video/7215641441597410603?_r=1&_t=8bPK4Ingkf5) +The Home Depot skeleton (https://twitter.com/jenni_tabler/status/1566266554240888832) +Nicole Zhu's newsletter (https://nicoledonut.com/) +The Making of a Manager by Julie Zhuo (https://www.juliezhuo.com/book/manager.html) +Saving Time by Jenny Odell (https://www.penguinrandomhouse.com/books/672377/saving-time-by-jenny-odell/) +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. And today, I'm joined by my friend and special guest, Nicole Zhu. +NICOLE: Hi, I'm so excited to be here. My name is Nicole, and I am an Engineering manager at Vox Media and a writer. +STEPHANIE: Amazing, I'm so thrilled to have you here. So, Nicole, we usually kick off the show by sharing a little bit about what's new in our world. And I can take us away and let you know about my very exciting weekend activities of taking down our Halloween skeleton. And yes, I know that it's April, but I feel like I've been seeing the 12-foot Home Depot skeletons everywhere. And it's becoming a thing for people to leave up just their Halloween decorations and, just as the other holidays keep rolling on, changing it up so that their skeleton is wearing like bunny ears for Easter or a leprechaun hat for St. Patrick's Day. +And we've been definitely on the weird skeleton in front of the house long past the Halloween train for a few years now. Our skeleton's name is Gary. And it's funny because he's like a science classroom skeleton, so not just plastic. He's actually quite heavy. +NICOLE: He's got some meat to the bones. [laughs] +STEPHANIE: Yeah, yeah, and physiologically correct. But we like to keep him out till spring because we got to put him away at some point so that people are excited again when he comes back out in October. And the kids on our block really love him. And yeah, that's what I did this weekend. [laughs] +NICOLE: I love it. I would love to meet Gary one day. Sounds very exciting. [laughs] I do get why you'd want to dress up the skeleton, especially if it's 12 feet tall because it's a lot of work to put up and take down for just one month, but that's fascinating. For me, something new in my world is the return of "Succession," the TV show. +STEPHANIE: Oh yes. +NICOLE: I did not watch yesterday's episode, so I'm already spoiled, but that's okay. But I've been getting a lot of Succession TikToks, and I've been learning a lot about the making of the show and the lives of the uber-rich. And in this one interview with Kieran Culkin, the interviewer asked him, "What's something that you learned in shooting the show about the uber-rich about billionaires that's maybe weird or unexpected?" And Kieran Culkin says that the uber-rich don't have coats because they're just shuttled everywhere in private jets and cars. They're not running to the grocery store, taking the subway, so they don't really wear coats, which I thought was fascinating. It makes a lot of sense. +And then there was this really interesting clip too that was talking about the cinematography of the show. And what is really interesting about it is that it resists the wealth porn kind of lens because it's filmed in this mockumentary style that doesn't linger or have sweeping gestures of how majestic these beautiful cities and buildings and apartments they're in. +Everything just seems very matter of fact because that is just the backdrop to their lives, which I think is so interesting how, yeah, I don't know, where I was like, I didn't ever really notice it. And now I can't stop seeing it when I watch the show where it's about miserable, rich people. And so I like that the visual language of the show reflects it too. +STEPHANIE: Wow, yeah, that makes a lot of sense. The coat thing really gets me because I'm just imagining if I could be perfectly climate controlled all the time. [laughs] +NICOLE: Right? Oh my gosh, especially you're based in Chicago [laughs], that is when you can retire the winter coat. That is always an important phase. +STEPHANIE: Yeah, seriously. I also am thinking now about just like the montages of showing a place, just movies or shows filmed in New York City or whatever, and it's such...so you know it's like the big city, right? +NICOLE: Mmm-hmm, mm-hmm. +STEPHANIE: And all of that setup. And it's really interesting to hear that stylistically, that is also different for a show like this where they're trying to convey a certain message. +NICOLE: Yeah, yeah, definitely. +STEPHANIE: So I'm really excited to have you on The Bike Shed because I have known you for a few years. And you write this really amazing newsletter called "nicoledonut" about your writing practice. And it's a newsletter that I open every other week when you send out a dispatch. And last year at RubyConf, they had a conference track called Bringing Your Backgrounds With You. +And there were talks that people gave about how the hobbies that they did outside of work or an identity that they held made them a better developer, like, affected how they showed up at work in a positive way. And as someone who has always been really impressed by the thoughtfulness that you apply to your writing practice, I was really curious about how that shows up for you as an engineering manager. +NICOLE: Definitely a great question. And to provide a bit of context for listeners, I feel like I have to explain the newsletter title because it's odd. But there's a writer who I really love named Jenny Zhang, and her handle across the Internet is jennybagel. And so I was like, oh, that would be so funny. I should be nicoledonut. I do love donuts. My Neopets username was donutfiend, so it was -- +STEPHANIE: Hell yeah. +NICOLE: But anyway, so that was kind of...I was like, I need to come up with some fun title for this newsletter, and that is what I settled on. But yes, I've written personal essays and creative nonfiction. And my primary focus more recently these past few years has been fiction. And this newsletter was really kind of born out of a desire to learn in the open, provide resources, act as kind of a journal, and just process ideas about writing and what it means to kind of sustain a creative life. +So it has definitely made me more reflective and proactively, like you said, kind of think about what that means in terms of how that transfers into my day job in engineering. I recently moved into management a little over a year ago, and before that, I was a senior full-stack engineer working on a lot of our audience experiences and websites and, previously, more of our editorial tools. +So I think when it comes to obviously writing code and being more of an individual contributor, I think you had previously kind of touched on what does it mean to treat code as a craft? And I do think that there are a lot of similarities between those two things because I think there's creativity in engineering, of course. You have to think about going from something abstract to something concrete. In engineering, you're given generally, or you're defining kind of requirements and features and functionality. You may be make an engineering plan or something like that, an EDD, given those constraints. +And then I think writing is very similar. You outline, and then you have to actually write the thing and then revise. I do think writing is not necessarily as collaborative as coding is, perhaps, but still similar overall in terms of an author having a vision, dealing with different constraints, if that's word count, if it's form or structure, if it's point of view, things like that. And that all determines what the outcome will be. +You always learn something in the execution, the idea that planning can only take you so far. And at a certain point, you gather as much background knowledge and information and talk to as many people. Depending on the kinds of writing I do, I have or haven't done as much research. But at a certain point, the research becomes procrastination, and I know I need to actually just start writing. +And similarly, with engineering, I think that's the piece is that once you actually start implementation, you start to uncover roadblocks. You uncover questions or complications or things like that. And so I think that's always the exciting part is you can't really always know the road ahead of you until you start the journey. And I also think that in order to benefit from mentorship and feedback...we can talk more about this. I know that that's something that is kind of a larger topic. +And then another thing I think where the two are really similar is there's this endless learning that goes with each of them. I guess that's true of, I think, most crafts. Good practitioners of the craft, I think, take on that mindset. But I do think that obviously, in engineering, you have industry changes, new technologies emerging really frequently. But I do think that good writers think about that, too, in terms of what new novels are coming out. But also, how do you build a solid foundation? +And I do think it's that contrast that applies in any craft is, you know, you want to have a good solid foundation and learn the basics but then keep up to date with new things as well. So I think there was this...there's this meme I actually did include in the newsletter that was...it's the meme of these two guys looking at different windows of a bus, and one looks really sad, and one looks really happy. But the two of them have the same caption, which is there's always more to learn. +And so I think that is the two sides of the coin [laughs]. I think that is relevant in engineering and writing that I've kind of brought to both of those practices is trying to be optimistic [laughs] about the idea that there's always more to learn that that's kind of the thought of it. +And then certainly, when it comes to management, I do think that writing has proven really valuable in that very obvious sense of kind of practical communication where I just write a lot more. I write a lot more things that are not code, I should say, as a manager. And communication is really at the forefront of my job, and so is demonstrating curiosity and building empathy, fostering relationships with people. +And I do think that particularly writing fiction you have to be curious about people I think to be a writer. And I think that is true of managers as well. So I do think that has been a really interesting way that I didn't anticipate writing showing up in my day job but has been a really helpful thing and has made my work stronger and think about the people, the process, and kind of what we do and why a little differently. +STEPHANIE: Yeah, absolutely. Wow, you got into a lot of different things I'm excited to keep discussing further. But one thing that I was thinking about as you were talking was, have you heard of the adage, I guess, that code is read many more times than it's written? +NICOLE: Hmm, I think I have, yeah. +STEPHANIE: I was thinking about that as you were talking because, in some ways, in most ways, actually, if you ascribe to that adage, I suppose, we write code for others to read. And I think there's an aspect of code telling a story that is really interesting. I've heard a lot of people advocate for writing, thoughtbot included, writing your tests like they're telling a story. +And so when a future developer is trying to understand what's going on, they can read the tests, understand the setup, read what is being tested, and then read what the expected outcome is and have a complete picture of what's going on. The same goes for commit messages. You are writing little bits of documentation for people in the future. +And I've also been thinking about how legacy code is just this artifact as well of all of the changes that an organization might have gone through. And so when you see something that you see a bit of code that is really weird or gets your spidey senses tingling, it's almost like, oh, I wonder what happened here that led to this piece left behind? +NICOLE: Yeah, definitely. Now that you're talking about it, I also think of pull requests as a great way to employ storytelling. I remember there definitely have been times where myself or other engineers are working on a really thorny problem, and we always joke that the PR description is longer than the change. And it's like, but you got to read the PR description in order to understand what change you're making and why. And here's the backstory, the context to kind of center people in that. +As a manager, I think about storytelling a lot in terms of defining purpose and providing clarity for teams. I was reading Julie Zhuo's "The Making of a Manager," and it was a really kind of foundational text for me when I first was exploring management. And she kind of boils it down to people, purpose, and process. +And so I do think the purpose part of that is really tied to clear communication. And can you tell a story of what we're doing from really high-level vision and then more tactically strategy? And then making sure that people have bought into that, they understand, can kind of repeat that without you being there to remind them necessarily. Because you really want that message to carry through in the work and that they have that understanding. +Vision is something I only recently have really started to realize how difficult it is to articulate. It's like you don't really understand the purpose of vision until you maybe don't have one, or you've been kind of just trying to keep your head afloat, and you don't have a Northstar to work towards. But I do think that is what plays into motivation, and team health, and, obviously, quality of the product. So yeah, that's kind of another dimension I've been thinking of. +And also our foes actually. Sorry, another one. Our foes, I think, like outages and incidents. I think that's always a fun opportunity to talk about stories. There was a period of time where every time we had an incident, you had to present that incident and a recap of it in an engineering all-hands every month. And they ended up being really fun. We turned something that is ostensibly very stressful into something that was very entertaining that people could really get on board with and would learn something from. +And we had the funniest one; I think was...we called it the Thanks Obama Outage because there was an outage that was caused by a photo of Barack Obama that had been uploaded in our content management system, as required no less, that had some malformed metadata or something that just broke everything. And so, again, it was a really difficult issue [laughs] and a long outage. And that was the result that I remember that presentation being really fun. +And again, kind of like mythmaking in a way where that is something that we remember. We pay attention to that part of the codebase a lot now. It's taught us a lot. So yeah, I do think storytelling isn't always necessarily the super serious thing, but it can also just be team building, and morale, and culture as well. +STEPHANIE: Yeah, absolutely. I think what you said about vision really resonates with me because if you don't have the vision, then you're also not making the best decisions you can be making even something as low-level as how you write the code. Because if you don't know are we going to be changing this feature a month from now, that might dictate how you go forth with implementation as opposed to if you know that it's not in the company's vision to really be doing anything else with this particular feature. And you then might feel a little more comfortable with a more rudimentary approach, right? +NICOLE: Yeah, totally. Whether or not it's, we've over-optimized or not or kind of optimized for speed. Like, it's all about trade-offs. And I do think, again, like you said, having a vision that always you can check your decision-making against and inform the path ahead I think is very, very helpful. +STEPHANIE: When you write, do you also keep that in mind? Like, do you write with that North Star? And is that really important to your process? +NICOLE: I think it depends. I think that writing can be a little more at a slant, I suppose, is how I think of it because I don't always...just similar to work, I don't always come in with a fully-fledged fleshed-out vision of what I want a piece to be. The most recent piece I've been working on actually I did have kind of a pretty, I think, solid foundation. +I've been working on this story about loneliness. And I knew that I wanted to base the structure on the UCLA...a UCLA clinic has this questionnaire that's 20 items long that is about measuring loneliness on a scale. And so I was like, okay, I knew that I wanted to examine dimensions of loneliness, and that would be the structure. It would be 20 questions, and it would be in that format. So that gave me a lot more to start with of, you know, here's where I want the piece to go. Here's what I want it to do. +And then there have definitely been other cases where it's more that the conceit seems interesting; a character comes to mind. I overhear a conversation on the subway, and I think it's funny, and that becomes the first thing that is put on the page. So I definitely have different entry points, I think, into a draft. But I will definitely say that revision is the phase where that always gets clarified. And it has to, I think, because as much as I'm sometimes just writing for vibes, it's not always like that. +And I do think that the purpose of revision is to clarify your goals so you can then really look at the piece and be like, is it doing what I want it to? Where is it lacking? Where's it really strong? Where's the pacing falling flat? And things like that. So I do think that sooner or later, that clarity comes, and that vision comes into focus. But it isn't always the first thing that happens, I think, because I do think the creative process is a little bit more mysterious, shall we say, than working on an engineering team. [laughs] +STEPHANIE: Yeah. Well, you started off responding to my question with it depends, which is a very engineering answer, but I suppose -- +NICOLE: That is true. That is true. You got me. [laughs] +STEPHANIE: It applies to both. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: You mentioned revision. And so, I do want to talk about feedback because I think that is an important part of the revision process. And I have really loved what you've had to say about writing feedback and your experience with writing feedback, especially in writing workshops. And I have always been really curious about what we might be able to learn about receiving feedback in code review. +NICOLE: When it comes to receiving feedback, I think I wrote a two-part series of my newsletter, one that was about providing feedback, one that was about receiving it. I think on the side of receiving feedback, first and foremost, I think it's important to know when you're ready to share your work and know that you can share multiple times. In writing, that can be I show a very early draft to my partner who is the person who kind of reads everything and anything at any stage. It's something less polished, and I'm really just testing ideas. +But then obviously, if there's something that is more polished, that is something I would want to bring to a writing group, bring into a workshop, things like that. Similarly, as engineers, I think...thank God for GitHub drafts actually adopting literally the way in which I think of that, right? +STEPHANIE: Yeah. +NICOLE: You can share a branch or a GitHub PR in progress and just check the approach. I've done that so many times, and really that helped so much with my own learning and learning from mentors in my own organization was checking in early and trying to gut-check my work earlier as opposed to later. Because then you feel, I think, again, a bit more naturally receptive because you're already in that questioning phase. You're not like, oh, this is polished, and I've written all the tests, and the PR description is done. And now you want me to go back and change the whole approach from the ground up. That can feel tough. I get that. +And so I think, hand in hand, what goes with that is whose feedback are you interested in? Is that a peer? Is it a mentor? I think obviously leaning on your own team, on senior engineers, I do think that is one of the primary, I think, expectations of a senior engineer is kind of multiplying the effectiveness of their peers and helping them learn and grow. So I do think that that's a really valuable skill to develop on that end, but also, again, just approaching people. +And obviously, different teams have different processes for that, if it's daily stand-ups, if it's GitHub reminders, automated messages that get pulled up in your channel, things like that. But there are ways to build that into your day-to-day, which I think is really beneficial too. +And then there's also the phase of priming yourself to receive the feedback. And I think there's actually a lot of emotional work that I don't think we talk about when it comes to that. Because receiving feedback can always be vulnerable, and it can bring up unexpected emotions. And I think learning how to regulate the emotional response to that is really valuable for us as people but obviously within the workplace too. +So I've found it really helpful to reflect if I'm getting feedback that...well, first of all, it depends on the format. So I think some people prefer verbal feedback, some people will prefer written. I think getting it in the form of written feedback can be helpful because it provides you some distance. You don't have to respond in the moment. And so I've definitely had cases where I then kind of want to reflect on why certain suggestions might elicit certain reactions if I have a fight or flight response, if I'm feeling ashamed or frustrated, or indignant, all the range of emotions. +Emotions are, to put the engineering hat on, are information. And so I think listening to that, not letting it rule you per se but letting it inform and help you figure out what is this telling me and how do I then respond, or what should I do next? Is really valuable. Because sometimes it's not, again, actually the feedback; maybe it's more about that, oh, it's a really radical idea. Maybe it's a really...it's an approach I didn't even consider, and it would take a lot of work. +But again, maybe if I sit and think about it, it is the scalable approach. It's the cleaner approach, things like that. Or are they just touching on something that I maybe haven't thought as deeply about? And so I think there is that piece too. Is it the delivery? Is it something about your context or history with the person giving the feedback too? I think all of those, the relationship building, the trust on a team, all plays into feedback. +And obviously, we can create better conditions for exchanging and receiving feedback. But I do think there's still that companion piece that is also just about, again, fostering team trust and culture overall because that is the thing that makes these conversations all the easier and less, I think, potentially fraught or high pressure. +STEPHANIE: 100%. Listeners can't see, but I was nodding very aggressively [laughs] this entire time. +NICOLE: Loved it. +STEPHANIE: And I love that you bring up interpersonal relationships, team culture, and feelings. Listeners of the show will know that I love talking about feelings. But I wanted to ask you this exact question because I think code review can be so fraught. And I've seen it be a source of conflict and tension. And I personally have always wanted more tools for giving better feedback. Because when I do give feedback, it's for the person to feel supported to help push their work to be better and for us to do good work as a team. +And I am really sensitive to the way that I give feedback because I know what it's like to receive feedback that doesn't land well. And when you were talking about investigating what kinds of feelings come up when you do receive a certain kind of comment on a code review or something, that was really interesting to me. Because I definitely know what it's like to have worked really, really hard on a pull request and for it to feel very precious to me and then to receive a lot of change requests or whatever. It can be really disappointing or really frustrating or whatever. And yeah, I wish that we, as an industry, could talk about this stuff more frequently. +NICOLE: Yeah, for sure. And I do think that you know, I think the longer you work with someone, ideally, again, the stronger relationship you form. You find your own ways of communicating that work for you. I think actually what I've learned in management is, yes, I have a communication style, but I also am flexible with how I work with each of my reports, who, again, have very different working styles, communication styles, learning styles. +I don't believe that the manager sets the standards. I think there is a balance there of meeting people where they are and giving them what they need while obviously maintaining your own values and practices. But yeah, certainly, again, I think that's why for perhaps more junior engineers, they might need more examples. They might not respond well to as terse a comment. +But certainly, with engineers, senior engineers that I've worked with, when I was starting out, the more we developed a relationship, they could just get a little bit more terse. For example, they could be like, "Fix this, fix that," and I would not take it personally because we had already gone through the phase where they were providing maybe some more detailed feedback, links to other examples or gists, or things like that, and our communication styles evolved. +And so I do think that's another thing to think about as well is that it doesn't have to be static. I think that's the value of a team, and having good team process, too, is ideally having arenas in which you can talk about how these kinds of things are going. Are we happy with the cadence? Are we happy with how people are treating each other and things like that? Are we getting timely feedback and things like that? That's a good opportunity for a retrospective and to talk about that in a kind of blameless context and approach that more holistically. +So I do think that, yeah, feedback can be very fraught. And I think what can be difficult in the world of engineering is that it can be very easy to then just be like, well, this is just the best way for the work. And feelings are, like you said, not really kind of considered. And, again, software development and engineering is a team sport. And so I do think fostering the environment in which everyone can be doing great work is really the imperative. +STEPHANIE: Yeah, I really like how you talked about the dynamic nature of relationships on a team and that the communication style can change there when you have built that trust and you understand where another person is coming from. I was also thinking about the question of whose feedback are you interested in? +And I certainly can remember times where I requested a review from someone in particular because maybe they had more context about this particular thing I was working on, and I wanted to make sure that I didn't miss anything, or someone else who maybe I had something to learn from them. And that is one way of making feedback work for me and being set up to receive it well. +Because as much as...like you said, it's really easy to fall back into the argument of like, oh, what's the best way for the work, or what is the cleanest code or whatever? I am still a person who wrote it. I produced a piece of work and have feelings about it. And so I have really enjoyed just learning more about how I react to feedback and trying to mitigate the stress that I feel in what is kind of inherently like a conflict-generating process. +NICOLE: Yeah, yeah, definitely. Another thing that kind of popped into my head to one of the earlier questions we were talking about is in terms of similarities between writing and engineering, style and structure are both really, really important. And even though in engineering, like you said, sometimes it can be, I mean, there is a point with engineering where you're like, this line of code works, or it doesn't. +There is a degree of correctness [laughs] that you do have to meet, obviously. But again, after that, it can be personal preference. It's why we have linters that have certain styles or things like that to try to eliminate some of these more divisive, shall we say, potentially discussions around, [laughs] God forbid, tabs or spaces, naming conventions, all this stuff. +But certainly, yeah, when it comes to structuring code, the style, or whatever else, like you said, there's a human lens to that. And so I think making sure that we are accounting for that in the process is really important, and not just whether or not the work gets done but also how the work gets done is really important. Because it predicts what do future projects...what does future collaboration look like? And again, you're not just ever optimizing for one thing in one point of time. You're always...you're building teams. You're building products. So there's a long kind of lifecycle to think about. +STEPHANIE: For sure. So after you get feedback and after you go through the revision process, I'm curious what you think about the idea of what is good enough in the context of your writing. And then also, if that has influenced when you think a feature is done or the code is as good as you want it to be. +NICOLE: Yeah, definitely. I think when it comes to my writing, how I think about what is good enough I think there is the kind of sentiment common in the writer community that you can edit yourself to death. You can revise forever if you wanted to. It's also kind of why I don't like to go back and read things I've already published because I'm always going to find something, you know, an errant comma or like, oh, man, I wish I had rephrased this here. +But I do think that, for me, I think about a couple of questions that help me get a sense of is this in a good place to, you know, for me generally, it's just to start submitting to places for publication. So one of those is, has someone else read it? That is always a really big question, whether it's a trusted reader, if I brought it to a workshop, or just my writing group, making sure I have a set of outside eyes, fresh eyes on the piece to give their reaction. And again, truly as a reader, sometimes just as a reader, not even as a fellow writer, because I do think different audiences will take different things and provide different types of feedback. +Another one is what kinds of changes am I making at this point in time? Am I still making really big structural edits? Or am I just kind of pushing words and commas around, and it feels like rearranging deck chairs on the Titanic? They're not massive changes to the piece. +And then the final question is always, if this were published in its current state right now, would I be happy with it? Would I be proud of it? And that's a very gut feeling that I think only an individual can kind of feel for themselves. And sometimes it's like, no, I don't like the way, like, I know it's 95% there, but I don't like the way this ends or something else. Again, those are all useful signals for me about whether a piece is complete or ready for submission or anything like that. +I think when it comes to engineering, I think there's a little bit less of the gut feeling, to be honest, because we have standards. We have processes in place generally on teams where it's like, is the feature working? Have you written tests? Have you written a QA plan if it needs one? If it's something that needs more extensive documentation or code comments or something like that, is that something you've done? Has a bit more of a clear runway for me in terms of figuring out when something is ready to be shown to others. +But certainly, as a manager, I've written a lot more types of documents I suppose, or types of communication where it's like organizational changes. I've written team announcements. I've written celebration posts. I've had to deliver bad news. Like, those are all things that you don't think about necessarily. But I've definitely had literally, you know, I have Google Docs of drafts of like, I need to draft the Slack message. +And even though it's just a Slack message, I will spend time trying to make sure I've credited all the right people, or provided all the context, got all the right answers. I run it by my director, my peers, and things like that if it's relevant. And again, I think there is still that piece that comes in of drafting, getting feedback, revising, and then feeling like, okay, have I done my due diligence here, and is it ready? That cycle is applicable in many, many situations. But yeah, I certainly think for direct IC work, it's probably a little bit more well-defined than some of the other processes. +STEPHANIE: Yeah, that makes sense. I really liked what you said about noticing the difference between making big structural changes and little word adjustments. I think you called it pushing commas around or something like that. +NICOLE: [laughs] Yeah. +STEPHANIE: I love that. Because I do think that with programming, there is definitely a big part of it that's just going on the journey and exploring different avenues. And so if you do suddenly think of, oh, I just thought of a completely different way to write this code, that is worth exploring even if you just end up going back to the original implementation. But at least you saw that thought through, and you're like, okay, this doesn't work because of X, Y, and Z, and I'm choosing to go this other route instead. And I think that, yeah, that is just a good practice to explore. +NICOLE: Another example of storytelling, too, where it's like, you can tell the story in the PR description or whatever, in stand-up, to be like, I also did go down this path, XYZ reason. Here's why it didn't work out, and here's what we're optimizing for. And there you go. So I do think we talk...I guess product managers think more about buy-in, but I think that's true of engineers too. It's like, how do you build consensus and provide context? +And so yeah, I think what you were saying, too, even if the path is circuitous or you're exploring other avenues, talking to other people, and just exploring what's out there, it all adds up to kind of the final decision and might provide, again, some useful information for other people to understand how you arrived there and get on board with it. +STEPHANIE: 100%. I remember when I worked with someone who we were writing a PR description together because we had paired on some code. And we had tried three different things. And he wrote paragraphs for each thing that we tried. And I was like, wow, I don't know if I would have done that on my own. But I just learned the value of doing that to, like you said, prime yourself for feedback as well, being like, I did try this, and this is what I thought. And other people can disagree with you, but then at least they have the information, right? +NICOLE: Definitely. +STEPHANIE: So before we wrap up, the last thing that I wanted to talk about, because I think it's super cool, is just how you have a totally separate hobby and skill and practice that you invest time and energy into that's not programming. And it's so refreshing for me to see you do that because I think, obviously, there's this false idea that programmers just code all the time in their free time, in their spare time, whatever. And I'm really curious about how writing fits into your life as something separate from your day job. +NICOLE: Yes, I've been thinking about this a ton. I think a lot of people, the last couple of years has forced a really big reckoning about work and life and how much we're giving to work, the boundaries that can be blurred, how capitalism butts its head into hobbies, and how we monetize them, or everything is a side hustle. And, oh, you should have a page running...oh, you should charge for a newsletter. And I think there's obviously the side of we should value our labor, but also, I don't want everything in my life to be labor. [laughs] +So I do think that is interesting. Writing to me, I actually do not see it as a hobby. I see it as another career of mine. I feel like I have two careers, but I have one job, [laughs] if that makes sense. I certainly have hobbies. But for me, what distinguishes that from my writing is that with hobbies, there's no expectation that you want to get better. You approach it with just...it's just pure enjoyment. And certainly, writing has part of that for me, but I have aspirations to publish. I love it when my work can reach readers and things like that. +But I do think that regardless having other interests, like you said, outside engineering, outside technology, it's a great break. And I do think also in technology, in particular, I notice...I think we're getting away from it, but certainly, there's an expectation, like you said, that you will have side projects that you code in your free time, that you're on Hacker News. +I think there is a little bit of that vibe in the tech industry that I don't see in other industries. You don't expect a teacher to want to teach in their free time, [laughs] you know what I mean? But we have almost that kind of implicit expectation of engineers to always be staying up to date on those things. +I think with writing and engineering; the two complement each other in some interesting ways. And they make me appreciate things about the other craft or practice that I may not previously have. And I think that with engineering, it is a team effort. It's really collaborative, and I really love working in that space. But on the flip side, too, with writing, I do love, you know, there's the ego part of it. You don't have individual authorship over code necessarily unless it's git blame level. But there's a reason why it's called git blame, [laughter] even the word is like git blame. +I've literally had cases where I'm like, oh, this thing is broken. Who wrote this? And then I was like, oh, surprise, it was you six years ago. But I do think with writing; it's an opportunity for me to really just explore and ask questions, and things don't have to be solved. It can just be play. And it is a place where I feel like everything that I accomplish is...obviously, I have people in my life who really support me, but it is a much more individual activity. So it is kind of the right-left brain piece. +But I've been reading this book called "Saving Time." It is what my microphone is currently propped on. But it's by Jenny Odell, who wrote: "How to Do Nothing." It's breaking my brain in a really, really, really good way. It talks a lot about the origin of productivity, how we think about time, and how it is so tied to colonialism, and racism, and capitalism, and neoliberalism, all these things. I think it has been really interesting. +And so thinking about boundaries between work and writing has been really, really helpful because I really love my job; I'm not only my job. And so I think having that clarity and then being like, well, what does that mean in terms of how I divide my time, how I set examples for others at work in terms of taking time off or leaving the office on time? And trying to make sure that I have a good emotional headspace so that I can transition to writing after work; all those things. I think it is really interesting. +And that also, ultimately, it's we're not just our productivity either. And I think writing can be very, again, inherently kind of unproductive. People joke that cleaning is writing, doing the dishes is writing, taking a walk is writing, showering is writing, but it is true. I think that the art doesn't talk about efficiency. You can't, I think, make art always more efficient in the same way you can do with engineering. We don't have those same kinds of conversations. And I really like having that kind of distinction. +Not that I don't like problem-solving with constraints and trade-offs and things like that, but I also really like that meandering quality of art and writing. So yeah, I've been thinking a lot more about collective time management, I guess, and what that means in terms of work, writing, and then yeah, hobbies and personal life. There are never enough hours in the day. But as this book is teaching me, again, maybe it's more about paradigm shifting and also collective policies we can be putting in place to help make that feeling go away. +STEPHANIE: For sure. Thank you for that distinction between hobby and career. I really liked that because it's a very generative mindset. It's like a both...and... rather than an either...or... And yeah, I completely agree with you wanting to make your life expansive, like, have all of the things. I'm also a big fan of Jenny Odell. I plugged "How to Do Nothing" on another episode. I am excited to read her second book as well. +NICOLE: I think you'll like it a lot. It's really excellent. She does such interesting things talking about ecology and geology and geographic time skills, which is really interesting that I don't know; it's nice to be reminded that we are small. [laughter] It's a book that kind of reminds you of your mortality in a good way, if that makes sense. But much like Gary on your porch reminds you of mortality too [laughs] and that you have to put Gary away for a little bit so that his time can come in October. [laughs] +STEPHANIE: Exactly, exactly. Cool. On that note, let's wrap up. Thank you so much for being on the show, Nicole. +NICOLE: Thank you so much for having me. This was a blast. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Engineering manager at Vox Media and author Nicole Zhu joins Stephanie on today's episode to discuss her writing practice.

+ +

nicoledonut is a biweekly newsletter about the writing process and sustaining a creative life that features creative resources, occasional interviews with creative folks, short essays on writing and creativity, farm-to-table memes and TikToks, and features on what Nicole is currently writing, reading, and watching.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by my friend and special guest, Nicole Zhu.

+ +

NICOLE: Hi, I'm so excited to be here. My name is Nicole, and I am an Engineering manager at Vox Media and a writer.

+ +

STEPHANIE: Amazing, I'm so thrilled to have you here. So, Nicole, we usually kick off the show by sharing a little bit about what's new in our world. And I can take us away and let you know about my very exciting weekend activities of taking down our Halloween skeleton. And yes, I know that it's April, but I feel like I've been seeing the 12-foot Home Depot skeletons everywhere. And it's becoming a thing for people to leave up just their Halloween decorations and, just as the other holidays keep rolling on, changing it up so that their skeleton is wearing like bunny ears for Easter or a leprechaun hat for St. Patrick's Day.

+ +

And we've been definitely on the weird skeleton in front of the house long past the Halloween train for a few years now. Our skeleton's name is Gary. And it's funny because he's like a science classroom skeleton, so not just plastic. He's actually quite heavy.

+ +

NICOLE: He's got some meat to the bones. [laughs]

+ +

STEPHANIE: Yeah, yeah, and physiologically correct. But we like to keep him out till spring because we got to put him away at some point so that people are excited again when he comes back out in October. And the kids on our block really love him. And yeah, that's what I did this weekend. [laughs]

+ +

NICOLE: I love it. I would love to meet Gary one day. Sounds very exciting. [laughs] I do get why you'd want to dress up the skeleton, especially if it's 12 feet tall because it's a lot of work to put up and take down for just one month, but that's fascinating. For me, something new in my world is the return of "Succession," the TV show.

+ +

STEPHANIE: Oh yes.

+ +

NICOLE: I did not watch yesterday's episode, so I'm already spoiled, but that's okay. But I've been getting a lot of Succession TikToks, and I've been learning a lot about the making of the show and the lives of the uber-rich. And in this one interview with Kieran Culkin, the interviewer asked him, "What's something that you learned in shooting the show about the uber-rich about billionaires that's maybe weird or unexpected?" And Kieran Culkin says that the uber-rich don't have coats because they're just shuttled everywhere in private jets and cars. They're not running to the grocery store, taking the subway, so they don't really wear coats, which I thought was fascinating. It makes a lot of sense.

+ +

And then there was this really interesting clip too that was talking about the cinematography of the show. And what is really interesting about it is that it resists the wealth porn kind of lens because it's filmed in this mockumentary style that doesn't linger or have sweeping gestures of how majestic these beautiful cities and buildings and apartments they're in.

+ +

Everything just seems very matter of fact because that is just the backdrop to their lives, which I think is so interesting how, yeah, I don't know, where I was like, I didn't ever really notice it. And now I can't stop seeing it when I watch the show where it's about miserable, rich people. And so I like that the visual language of the show reflects it too.

+ +

STEPHANIE: Wow, yeah, that makes a lot of sense. The coat thing really gets me because I'm just imagining if I could be perfectly climate controlled all the time. [laughs]

+ +

NICOLE: Right? Oh my gosh, especially you're based in Chicago [laughs], that is when you can retire the winter coat. That is always an important phase.

+ +

STEPHANIE: Yeah, seriously. I also am thinking now about just like the montages of showing a place, just movies or shows filmed in New York City or whatever, and it's such...so you know it's like the big city, right?

+ +

NICOLE: Mmm-hmm, mm-hmm.

+ +

STEPHANIE: And all of that setup. And it's really interesting to hear that stylistically, that is also different for a show like this where they're trying to convey a certain message.

+ +

NICOLE: Yeah, yeah, definitely.

+ +

STEPHANIE: So I'm really excited to have you on The Bike Shed because I have known you for a few years. And you write this really amazing newsletter called "nicoledonut" about your writing practice. And it's a newsletter that I open every other week when you send out a dispatch. And last year at RubyConf, they had a conference track called Bringing Your Backgrounds With You.

+ +

And there were talks that people gave about how the hobbies that they did outside of work or an identity that they held made them a better developer, like, affected how they showed up at work in a positive way. And as someone who has always been really impressed by the thoughtfulness that you apply to your writing practice, I was really curious about how that shows up for you as an engineering manager.

+ +

NICOLE: Definitely a great question. And to provide a bit of context for listeners, I feel like I have to explain the newsletter title because it's odd. But there's a writer who I really love named Jenny Zhang, and her handle across the Internet is jennybagel. And so I was like, oh, that would be so funny. I should be nicoledonut. I do love donuts. My Neopets username was donutfiend, so it was --

+ +

STEPHANIE: Hell yeah.

+ +

NICOLE: But anyway, so that was kind of...I was like, I need to come up with some fun title for this newsletter, and that is what I settled on. But yes, I've written personal essays and creative nonfiction. And my primary focus more recently these past few years has been fiction. And this newsletter was really kind of born out of a desire to learn in the open, provide resources, act as kind of a journal, and just process ideas about writing and what it means to kind of sustain a creative life.

+ +

So it has definitely made me more reflective and proactively, like you said, kind of think about what that means in terms of how that transfers into my day job in engineering. I recently moved into management a little over a year ago, and before that, I was a senior full-stack engineer working on a lot of our audience experiences and websites and, previously, more of our editorial tools.

+ +

So I think when it comes to obviously writing code and being more of an individual contributor, I think you had previously kind of touched on what does it mean to treat code as a craft? And I do think that there are a lot of similarities between those two things because I think there's creativity in engineering, of course. You have to think about going from something abstract to something concrete. In engineering, you're given generally, or you're defining kind of requirements and features and functionality. You may be make an engineering plan or something like that, an EDD, given those constraints.

+ +

And then I think writing is very similar. You outline, and then you have to actually write the thing and then revise. I do think writing is not necessarily as collaborative as coding is, perhaps, but still similar overall in terms of an author having a vision, dealing with different constraints, if that's word count, if it's form or structure, if it's point of view, things like that. And that all determines what the outcome will be.

+ +

You always learn something in the execution, the idea that planning can only take you so far. And at a certain point, you gather as much background knowledge and information and talk to as many people. Depending on the kinds of writing I do, I have or haven't done as much research. But at a certain point, the research becomes procrastination, and I know I need to actually just start writing.

+ +

And similarly, with engineering, I think that's the piece is that once you actually start implementation, you start to uncover roadblocks. You uncover questions or complications or things like that. And so I think that's always the exciting part is you can't really always know the road ahead of you until you start the journey. And I also think that in order to benefit from mentorship and feedback...we can talk more about this. I know that that's something that is kind of a larger topic.

+ +

And then another thing I think where the two are really similar is there's this endless learning that goes with each of them. I guess that's true of, I think, most crafts. Good practitioners of the craft, I think, take on that mindset. But I do think that obviously, in engineering, you have industry changes, new technologies emerging really frequently. But I do think that good writers think about that, too, in terms of what new novels are coming out. But also, how do you build a solid foundation?

+ +

And I do think it's that contrast that applies in any craft is, you know, you want to have a good solid foundation and learn the basics but then keep up to date with new things as well. So I think there was this...there's this meme I actually did include in the newsletter that was...it's the meme of these two guys looking at different windows of a bus, and one looks really sad, and one looks really happy. But the two of them have the same caption, which is there's always more to learn.

+ +

And so I think that is the two sides of the coin [laughs]. I think that is relevant in engineering and writing that I've kind of brought to both of those practices is trying to be optimistic [laughs] about the idea that there's always more to learn that that's kind of the thought of it.

+ +

And then certainly, when it comes to management, I do think that writing has proven really valuable in that very obvious sense of kind of practical communication where I just write a lot more. I write a lot more things that are not code, I should say, as a manager. And communication is really at the forefront of my job, and so is demonstrating curiosity and building empathy, fostering relationships with people.

+ +

And I do think that particularly writing fiction you have to be curious about people I think to be a writer. And I think that is true of managers as well. So I do think that has been a really interesting way that I didn't anticipate writing showing up in my day job but has been a really helpful thing and has made my work stronger and think about the people, the process, and kind of what we do and why a little differently.

+ +

STEPHANIE: Yeah, absolutely. Wow, you got into a lot of different things I'm excited to keep discussing further. But one thing that I was thinking about as you were talking was, have you heard of the adage, I guess, that code is read many more times than it's written?

+ +

NICOLE: Hmm, I think I have, yeah.

+ +

STEPHANIE: I was thinking about that as you were talking because, in some ways, in most ways, actually, if you ascribe to that adage, I suppose, we write code for others to read. And I think there's an aspect of code telling a story that is really interesting. I've heard a lot of people advocate for writing, thoughtbot included, writing your tests like they're telling a story.

+ +

And so when a future developer is trying to understand what's going on, they can read the tests, understand the setup, read what is being tested, and then read what the expected outcome is and have a complete picture of what's going on. The same goes for commit messages. You are writing little bits of documentation for people in the future.

+ +

And I've also been thinking about how legacy code is just this artifact as well of all of the changes that an organization might have gone through. And so when you see something that you see a bit of code that is really weird or gets your spidey senses tingling, it's almost like, oh, I wonder what happened here that led to this piece left behind?

+ +

NICOLE: Yeah, definitely. Now that you're talking about it, I also think of pull requests as a great way to employ storytelling. I remember there definitely have been times where myself or other engineers are working on a really thorny problem, and we always joke that the PR description is longer than the change. And it's like, but you got to read the PR description in order to understand what change you're making and why. And here's the backstory, the context to kind of center people in that.

+ +

As a manager, I think about storytelling a lot in terms of defining purpose and providing clarity for teams. I was reading Julie Zhuo's "The Making of a Manager," and it was a really kind of foundational text for me when I first was exploring management. And she kind of boils it down to people, purpose, and process.

+ +

And so I do think the purpose part of that is really tied to clear communication. And can you tell a story of what we're doing from really high-level vision and then more tactically strategy? And then making sure that people have bought into that, they understand, can kind of repeat that without you being there to remind them necessarily. Because you really want that message to carry through in the work and that they have that understanding.

+ +

Vision is something I only recently have really started to realize how difficult it is to articulate. It's like you don't really understand the purpose of vision until you maybe don't have one, or you've been kind of just trying to keep your head afloat, and you don't have a Northstar to work towards. But I do think that is what plays into motivation, and team health, and, obviously, quality of the product. So yeah, that's kind of another dimension I've been thinking of.

+ +

And also our foes actually. Sorry, another one. Our foes, I think, like outages and incidents. I think that's always a fun opportunity to talk about stories. There was a period of time where every time we had an incident, you had to present that incident and a recap of it in an engineering all-hands every month. And they ended up being really fun. We turned something that is ostensibly very stressful into something that was very entertaining that people could really get on board with and would learn something from.

+ +

And we had the funniest one; I think was...we called it the Thanks Obama Outage because there was an outage that was caused by a photo of Barack Obama that had been uploaded in our content management system, as required no less, that had some malformed metadata or something that just broke everything. And so, again, it was a really difficult issue [laughs] and a long outage. And that was the result that I remember that presentation being really fun.

+ +

And again, kind of like mythmaking in a way where that is something that we remember. We pay attention to that part of the codebase a lot now. It's taught us a lot. So yeah, I do think storytelling isn't always necessarily the super serious thing, but it can also just be team building, and morale, and culture as well.

+ +

STEPHANIE: Yeah, absolutely. I think what you said about vision really resonates with me because if you don't have the vision, then you're also not making the best decisions you can be making even something as low-level as how you write the code. Because if you don't know are we going to be changing this feature a month from now, that might dictate how you go forth with implementation as opposed to if you know that it's not in the company's vision to really be doing anything else with this particular feature. And you then might feel a little more comfortable with a more rudimentary approach, right?

+ +

NICOLE: Yeah, totally. Whether or not it's, we've over-optimized or not or kind of optimized for speed. Like, it's all about trade-offs. And I do think, again, like you said, having a vision that always you can check your decision-making against and inform the path ahead I think is very, very helpful.

+ +

STEPHANIE: When you write, do you also keep that in mind? Like, do you write with that North Star? And is that really important to your process?

+ +

NICOLE: I think it depends. I think that writing can be a little more at a slant, I suppose, is how I think of it because I don't always...just similar to work, I don't always come in with a fully-fledged fleshed-out vision of what I want a piece to be. The most recent piece I've been working on actually I did have kind of a pretty, I think, solid foundation.

+ +

I've been working on this story about loneliness. And I knew that I wanted to base the structure on the UCLA...a UCLA clinic has this questionnaire that's 20 items long that is about measuring loneliness on a scale. And so I was like, okay, I knew that I wanted to examine dimensions of loneliness, and that would be the structure. It would be 20 questions, and it would be in that format. So that gave me a lot more to start with of, you know, here's where I want the piece to go. Here's what I want it to do.

+ +

And then there have definitely been other cases where it's more that the conceit seems interesting; a character comes to mind. I overhear a conversation on the subway, and I think it's funny, and that becomes the first thing that is put on the page. So I definitely have different entry points, I think, into a draft. But I will definitely say that revision is the phase where that always gets clarified. And it has to, I think, because as much as I'm sometimes just writing for vibes, it's not always like that.

+ +

And I do think that the purpose of revision is to clarify your goals so you can then really look at the piece and be like, is it doing what I want it to? Where is it lacking? Where's it really strong? Where's the pacing falling flat? And things like that. So I do think that sooner or later, that clarity comes, and that vision comes into focus. But it isn't always the first thing that happens, I think, because I do think the creative process is a little bit more mysterious, shall we say, than working on an engineering team. [laughs]

+ +

STEPHANIE: Yeah. Well, you started off responding to my question with it depends, which is a very engineering answer, but I suppose --

+ +

NICOLE: That is true. That is true. You got me. [laughs]

+ +

STEPHANIE: It applies to both.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: You mentioned revision. And so, I do want to talk about feedback because I think that is an important part of the revision process. And I have really loved what you've had to say about writing feedback and your experience with writing feedback, especially in writing workshops. And I have always been really curious about what we might be able to learn about receiving feedback in code review.

+ +

NICOLE: When it comes to receiving feedback, I think I wrote a two-part series of my newsletter, one that was about providing feedback, one that was about receiving it. I think on the side of receiving feedback, first and foremost, I think it's important to know when you're ready to share your work and know that you can share multiple times. In writing, that can be I show a very early draft to my partner who is the person who kind of reads everything and anything at any stage. It's something less polished, and I'm really just testing ideas.

+ +

But then obviously, if there's something that is more polished, that is something I would want to bring to a writing group, bring into a workshop, things like that. Similarly, as engineers, I think...thank God for GitHub drafts actually adopting literally the way in which I think of that, right?

+ +

STEPHANIE: Yeah.

+ +

NICOLE: You can share a branch or a GitHub PR in progress and just check the approach. I've done that so many times, and really that helped so much with my own learning and learning from mentors in my own organization was checking in early and trying to gut-check my work earlier as opposed to later. Because then you feel, I think, again, a bit more naturally receptive because you're already in that questioning phase. You're not like, oh, this is polished, and I've written all the tests, and the PR description is done. And now you want me to go back and change the whole approach from the ground up. That can feel tough. I get that.

+ +

And so I think, hand in hand, what goes with that is whose feedback are you interested in? Is that a peer? Is it a mentor? I think obviously leaning on your own team, on senior engineers, I do think that is one of the primary, I think, expectations of a senior engineer is kind of multiplying the effectiveness of their peers and helping them learn and grow. So I do think that that's a really valuable skill to develop on that end, but also, again, just approaching people.

+ +

And obviously, different teams have different processes for that, if it's daily stand-ups, if it's GitHub reminders, automated messages that get pulled up in your channel, things like that. But there are ways to build that into your day-to-day, which I think is really beneficial too.

+ +

And then there's also the phase of priming yourself to receive the feedback. And I think there's actually a lot of emotional work that I don't think we talk about when it comes to that. Because receiving feedback can always be vulnerable, and it can bring up unexpected emotions. And I think learning how to regulate the emotional response to that is really valuable for us as people but obviously within the workplace too.

+ +

So I've found it really helpful to reflect if I'm getting feedback that...well, first of all, it depends on the format. So I think some people prefer verbal feedback, some people will prefer written. I think getting it in the form of written feedback can be helpful because it provides you some distance. You don't have to respond in the moment. And so I've definitely had cases where I then kind of want to reflect on why certain suggestions might elicit certain reactions if I have a fight or flight response, if I'm feeling ashamed or frustrated, or indignant, all the range of emotions.

+ +

Emotions are, to put the engineering hat on, are information. And so I think listening to that, not letting it rule you per se but letting it inform and help you figure out what is this telling me and how do I then respond, or what should I do next? Is really valuable. Because sometimes it's not, again, actually the feedback; maybe it's more about that, oh, it's a really radical idea. Maybe it's a really...it's an approach I didn't even consider, and it would take a lot of work.

+ +

But again, maybe if I sit and think about it, it is the scalable approach. It's the cleaner approach, things like that. Or are they just touching on something that I maybe haven't thought as deeply about? And so I think there is that piece too. Is it the delivery? Is it something about your context or history with the person giving the feedback too? I think all of those, the relationship building, the trust on a team, all plays into feedback.

+ +

And obviously, we can create better conditions for exchanging and receiving feedback. But I do think there's still that companion piece that is also just about, again, fostering team trust and culture overall because that is the thing that makes these conversations all the easier and less, I think, potentially fraught or high pressure.

+ +

STEPHANIE: 100%. Listeners can't see, but I was nodding very aggressively [laughs] this entire time.

+ +

NICOLE: Loved it.

+ +

STEPHANIE: And I love that you bring up interpersonal relationships, team culture, and feelings. Listeners of the show will know that I love talking about feelings. But I wanted to ask you this exact question because I think code review can be so fraught. And I've seen it be a source of conflict and tension. And I personally have always wanted more tools for giving better feedback. Because when I do give feedback, it's for the person to feel supported to help push their work to be better and for us to do good work as a team.

+ +

And I am really sensitive to the way that I give feedback because I know what it's like to receive feedback that doesn't land well. And when you were talking about investigating what kinds of feelings come up when you do receive a certain kind of comment on a code review or something, that was really interesting to me. Because I definitely know what it's like to have worked really, really hard on a pull request and for it to feel very precious to me and then to receive a lot of change requests or whatever. It can be really disappointing or really frustrating or whatever. And yeah, I wish that we, as an industry, could talk about this stuff more frequently.

+ +

NICOLE: Yeah, for sure. And I do think that you know, I think the longer you work with someone, ideally, again, the stronger relationship you form. You find your own ways of communicating that work for you. I think actually what I've learned in management is, yes, I have a communication style, but I also am flexible with how I work with each of my reports, who, again, have very different working styles, communication styles, learning styles.

+ +

I don't believe that the manager sets the standards. I think there is a balance there of meeting people where they are and giving them what they need while obviously maintaining your own values and practices. But yeah, certainly, again, I think that's why for perhaps more junior engineers, they might need more examples. They might not respond well to as terse a comment.

+ +

But certainly, with engineers, senior engineers that I've worked with, when I was starting out, the more we developed a relationship, they could just get a little bit more terse. For example, they could be like, "Fix this, fix that," and I would not take it personally because we had already gone through the phase where they were providing maybe some more detailed feedback, links to other examples or gists, or things like that, and our communication styles evolved.

+ +

And so I do think that's another thing to think about as well is that it doesn't have to be static. I think that's the value of a team, and having good team process, too, is ideally having arenas in which you can talk about how these kinds of things are going. Are we happy with the cadence? Are we happy with how people are treating each other and things like that? Are we getting timely feedback and things like that? That's a good opportunity for a retrospective and to talk about that in a kind of blameless context and approach that more holistically.

+ +

So I do think that, yeah, feedback can be very fraught. And I think what can be difficult in the world of engineering is that it can be very easy to then just be like, well, this is just the best way for the work. And feelings are, like you said, not really kind of considered. And, again, software development and engineering is a team sport. And so I do think fostering the environment in which everyone can be doing great work is really the imperative.

+ +

STEPHANIE: Yeah, I really like how you talked about the dynamic nature of relationships on a team and that the communication style can change there when you have built that trust and you understand where another person is coming from. I was also thinking about the question of whose feedback are you interested in?

+ +

And I certainly can remember times where I requested a review from someone in particular because maybe they had more context about this particular thing I was working on, and I wanted to make sure that I didn't miss anything, or someone else who maybe I had something to learn from them. And that is one way of making feedback work for me and being set up to receive it well.

+ +

Because as much as...like you said, it's really easy to fall back into the argument of like, oh, what's the best way for the work, or what is the cleanest code or whatever? I am still a person who wrote it. I produced a piece of work and have feelings about it. And so I have really enjoyed just learning more about how I react to feedback and trying to mitigate the stress that I feel in what is kind of inherently like a conflict-generating process.

+ +

NICOLE: Yeah, yeah, definitely. Another thing that kind of popped into my head to one of the earlier questions we were talking about is in terms of similarities between writing and engineering, style and structure are both really, really important. And even though in engineering, like you said, sometimes it can be, I mean, there is a point with engineering where you're like, this line of code works, or it doesn't.

+ +

There is a degree of correctness [laughs] that you do have to meet, obviously. But again, after that, it can be personal preference. It's why we have linters that have certain styles or things like that to try to eliminate some of these more divisive, shall we say, potentially discussions around, [laughs] God forbid, tabs or spaces, naming conventions, all this stuff.

+ +

But certainly, yeah, when it comes to structuring code, the style, or whatever else, like you said, there's a human lens to that. And so I think making sure that we are accounting for that in the process is really important, and not just whether or not the work gets done but also how the work gets done is really important. Because it predicts what do future projects...what does future collaboration look like? And again, you're not just ever optimizing for one thing in one point of time. You're always...you're building teams. You're building products. So there's a long kind of lifecycle to think about.

+ +

STEPHANIE: For sure. So after you get feedback and after you go through the revision process, I'm curious what you think about the idea of what is good enough in the context of your writing. And then also, if that has influenced when you think a feature is done or the code is as good as you want it to be.

+ +

NICOLE: Yeah, definitely. I think when it comes to my writing, how I think about what is good enough I think there is the kind of sentiment common in the writer community that you can edit yourself to death. You can revise forever if you wanted to. It's also kind of why I don't like to go back and read things I've already published because I'm always going to find something, you know, an errant comma or like, oh, man, I wish I had rephrased this here.

+ +

But I do think that, for me, I think about a couple of questions that help me get a sense of is this in a good place to, you know, for me generally, it's just to start submitting to places for publication. So one of those is, has someone else read it? That is always a really big question, whether it's a trusted reader, if I brought it to a workshop, or just my writing group, making sure I have a set of outside eyes, fresh eyes on the piece to give their reaction. And again, truly as a reader, sometimes just as a reader, not even as a fellow writer, because I do think different audiences will take different things and provide different types of feedback.

+ +

Another one is what kinds of changes am I making at this point in time? Am I still making really big structural edits? Or am I just kind of pushing words and commas around, and it feels like rearranging deck chairs on the Titanic? They're not massive changes to the piece.

+ +

And then the final question is always, if this were published in its current state right now, would I be happy with it? Would I be proud of it? And that's a very gut feeling that I think only an individual can kind of feel for themselves. And sometimes it's like, no, I don't like the way, like, I know it's 95% there, but I don't like the way this ends or something else. Again, those are all useful signals for me about whether a piece is complete or ready for submission or anything like that.

+ +

I think when it comes to engineering, I think there's a little bit less of the gut feeling, to be honest, because we have standards. We have processes in place generally on teams where it's like, is the feature working? Have you written tests? Have you written a QA plan if it needs one? If it's something that needs more extensive documentation or code comments or something like that, is that something you've done? Has a bit more of a clear runway for me in terms of figuring out when something is ready to be shown to others.

+ +

But certainly, as a manager, I've written a lot more types of documents I suppose, or types of communication where it's like organizational changes. I've written team announcements. I've written celebration posts. I've had to deliver bad news. Like, those are all things that you don't think about necessarily. But I've definitely had literally, you know, I have Google Docs of drafts of like, I need to draft the Slack message.

+ +

And even though it's just a Slack message, I will spend time trying to make sure I've credited all the right people, or provided all the context, got all the right answers. I run it by my director, my peers, and things like that if it's relevant. And again, I think there is still that piece that comes in of drafting, getting feedback, revising, and then feeling like, okay, have I done my due diligence here, and is it ready? That cycle is applicable in many, many situations. But yeah, I certainly think for direct IC work, it's probably a little bit more well-defined than some of the other processes.

+ +

STEPHANIE: Yeah, that makes sense. I really liked what you said about noticing the difference between making big structural changes and little word adjustments. I think you called it pushing commas around or something like that.

+ +

NICOLE: [laughs] Yeah.

+ +

STEPHANIE: I love that. Because I do think that with programming, there is definitely a big part of it that's just going on the journey and exploring different avenues. And so if you do suddenly think of, oh, I just thought of a completely different way to write this code, that is worth exploring even if you just end up going back to the original implementation. But at least you saw that thought through, and you're like, okay, this doesn't work because of X, Y, and Z, and I'm choosing to go this other route instead. And I think that, yeah, that is just a good practice to explore.

+ +

NICOLE: Another example of storytelling, too, where it's like, you can tell the story in the PR description or whatever, in stand-up, to be like, I also did go down this path, XYZ reason. Here's why it didn't work out, and here's what we're optimizing for. And there you go. So I do think we talk...I guess product managers think more about buy-in, but I think that's true of engineers too. It's like, how do you build consensus and provide context?

+ +

And so yeah, I think what you were saying, too, even if the path is circuitous or you're exploring other avenues, talking to other people, and just exploring what's out there, it all adds up to kind of the final decision and might provide, again, some useful information for other people to understand how you arrived there and get on board with it.

+ +

STEPHANIE: 100%. I remember when I worked with someone who we were writing a PR description together because we had paired on some code. And we had tried three different things. And he wrote paragraphs for each thing that we tried. And I was like, wow, I don't know if I would have done that on my own. But I just learned the value of doing that to, like you said, prime yourself for feedback as well, being like, I did try this, and this is what I thought. And other people can disagree with you, but then at least they have the information, right?

+ +

NICOLE: Definitely.

+ +

STEPHANIE: So before we wrap up, the last thing that I wanted to talk about, because I think it's super cool, is just how you have a totally separate hobby and skill and practice that you invest time and energy into that's not programming. And it's so refreshing for me to see you do that because I think, obviously, there's this false idea that programmers just code all the time in their free time, in their spare time, whatever. And I'm really curious about how writing fits into your life as something separate from your day job.

+ +

NICOLE: Yes, I've been thinking about this a ton. I think a lot of people, the last couple of years has forced a really big reckoning about work and life and how much we're giving to work, the boundaries that can be blurred, how capitalism butts its head into hobbies, and how we monetize them, or everything is a side hustle. And, oh, you should have a page running...oh, you should charge for a newsletter. And I think there's obviously the side of we should value our labor, but also, I don't want everything in my life to be labor. [laughs]

+ +

So I do think that is interesting. Writing to me, I actually do not see it as a hobby. I see it as another career of mine. I feel like I have two careers, but I have one job, [laughs] if that makes sense. I certainly have hobbies. But for me, what distinguishes that from my writing is that with hobbies, there's no expectation that you want to get better. You approach it with just...it's just pure enjoyment. And certainly, writing has part of that for me, but I have aspirations to publish. I love it when my work can reach readers and things like that.

+ +

But I do think that regardless having other interests, like you said, outside engineering, outside technology, it's a great break. And I do think also in technology, in particular, I notice...I think we're getting away from it, but certainly, there's an expectation, like you said, that you will have side projects that you code in your free time, that you're on Hacker News.

+ +

I think there is a little bit of that vibe in the tech industry that I don't see in other industries. You don't expect a teacher to want to teach in their free time, [laughs] you know what I mean? But we have almost that kind of implicit expectation of engineers to always be staying up to date on those things.

+ +

I think with writing and engineering; the two complement each other in some interesting ways. And they make me appreciate things about the other craft or practice that I may not previously have. And I think that with engineering, it is a team effort. It's really collaborative, and I really love working in that space. But on the flip side, too, with writing, I do love, you know, there's the ego part of it. You don't have individual authorship over code necessarily unless it's git blame level. But there's a reason why it's called git blame, [laughter] even the word is like git blame.

+ +

I've literally had cases where I'm like, oh, this thing is broken. Who wrote this? And then I was like, oh, surprise, it was you six years ago. But I do think with writing; it's an opportunity for me to really just explore and ask questions, and things don't have to be solved. It can just be play. And it is a place where I feel like everything that I accomplish is...obviously, I have people in my life who really support me, but it is a much more individual activity. So it is kind of the right-left brain piece.

+ +

But I've been reading this book called "Saving Time." It is what my microphone is currently propped on. But it's by Jenny Odell, who wrote: "How to Do Nothing." It's breaking my brain in a really, really, really good way. It talks a lot about the origin of productivity, how we think about time, and how it is so tied to colonialism, and racism, and capitalism, and neoliberalism, all these things. I think it has been really interesting.

+ +

And so thinking about boundaries between work and writing has been really, really helpful because I really love my job; I'm not only my job. And so I think having that clarity and then being like, well, what does that mean in terms of how I divide my time, how I set examples for others at work in terms of taking time off or leaving the office on time? And trying to make sure that I have a good emotional headspace so that I can transition to writing after work; all those things. I think it is really interesting.

+ +

And that also, ultimately, it's we're not just our productivity either. And I think writing can be very, again, inherently kind of unproductive. People joke that cleaning is writing, doing the dishes is writing, taking a walk is writing, showering is writing, but it is true. I think that the art doesn't talk about efficiency. You can't, I think, make art always more efficient in the same way you can do with engineering. We don't have those same kinds of conversations. And I really like having that kind of distinction.

+ +

Not that I don't like problem-solving with constraints and trade-offs and things like that, but I also really like that meandering quality of art and writing. So yeah, I've been thinking a lot more about collective time management, I guess, and what that means in terms of work, writing, and then yeah, hobbies and personal life. There are never enough hours in the day. But as this book is teaching me, again, maybe it's more about paradigm shifting and also collective policies we can be putting in place to help make that feeling go away.

+ +

STEPHANIE: For sure. Thank you for that distinction between hobby and career. I really liked that because it's a very generative mindset. It's like a both...and... rather than an either...or... And yeah, I completely agree with you wanting to make your life expansive, like, have all of the things. I'm also a big fan of Jenny Odell. I plugged "How to Do Nothing" on another episode. I am excited to read her second book as well.

+ +

NICOLE: I think you'll like it a lot. It's really excellent. She does such interesting things talking about ecology and geology and geographic time skills, which is really interesting that I don't know; it's nice to be reminded that we are small. [laughter] It's a book that kind of reminds you of your mortality in a good way, if that makes sense. But much like Gary on your porch reminds you of mortality too [laughs] and that you have to put Gary away for a little bit so that his time can come in October. [laughs]

+ +

STEPHANIE: Exactly, exactly. Cool. On that note, let's wrap up. Thank you so much for being on the show, Nicole.

+ +

NICOLE: Thank you so much for having me. This was a blast.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Engineering manager at Vox Media and author Nicole Zhu joins Stephanie on today's episode to discuss her writing practice.

+ +

nicoledonut is a biweekly newsletter about the writing process and sustaining a creative life that features creative resources, occasional interviews with creative folks, short essays on writing and creativity, farm-to-table memes and TikToks, and features on what Nicole is currently writing, reading, and watching.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by my friend and special guest, Nicole Zhu.

+ +

NICOLE: Hi, I'm so excited to be here. My name is Nicole, and I am an Engineering manager at Vox Media and a writer.

+ +

STEPHANIE: Amazing, I'm so thrilled to have you here. So, Nicole, we usually kick off the show by sharing a little bit about what's new in our world. And I can take us away and let you know about my very exciting weekend activities of taking down our Halloween skeleton. And yes, I know that it's April, but I feel like I've been seeing the 12-foot Home Depot skeletons everywhere. And it's becoming a thing for people to leave up just their Halloween decorations and, just as the other holidays keep rolling on, changing it up so that their skeleton is wearing like bunny ears for Easter or a leprechaun hat for St. Patrick's Day.

+ +

And we've been definitely on the weird skeleton in front of the house long past the Halloween train for a few years now. Our skeleton's name is Gary. And it's funny because he's like a science classroom skeleton, so not just plastic. He's actually quite heavy.

+ +

NICOLE: He's got some meat to the bones. [laughs]

+ +

STEPHANIE: Yeah, yeah, and physiologically correct. But we like to keep him out till spring because we got to put him away at some point so that people are excited again when he comes back out in October. And the kids on our block really love him. And yeah, that's what I did this weekend. [laughs]

+ +

NICOLE: I love it. I would love to meet Gary one day. Sounds very exciting. [laughs] I do get why you'd want to dress up the skeleton, especially if it's 12 feet tall because it's a lot of work to put up and take down for just one month, but that's fascinating. For me, something new in my world is the return of "Succession," the TV show.

+ +

STEPHANIE: Oh yes.

+ +

NICOLE: I did not watch yesterday's episode, so I'm already spoiled, but that's okay. But I've been getting a lot of Succession TikToks, and I've been learning a lot about the making of the show and the lives of the uber-rich. And in this one interview with Kieran Culkin, the interviewer asked him, "What's something that you learned in shooting the show about the uber-rich about billionaires that's maybe weird or unexpected?" And Kieran Culkin says that the uber-rich don't have coats because they're just shuttled everywhere in private jets and cars. They're not running to the grocery store, taking the subway, so they don't really wear coats, which I thought was fascinating. It makes a lot of sense.

+ +

And then there was this really interesting clip too that was talking about the cinematography of the show. And what is really interesting about it is that it resists the wealth porn kind of lens because it's filmed in this mockumentary style that doesn't linger or have sweeping gestures of how majestic these beautiful cities and buildings and apartments they're in.

+ +

Everything just seems very matter of fact because that is just the backdrop to their lives, which I think is so interesting how, yeah, I don't know, where I was like, I didn't ever really notice it. And now I can't stop seeing it when I watch the show where it's about miserable, rich people. And so I like that the visual language of the show reflects it too.

+ +

STEPHANIE: Wow, yeah, that makes a lot of sense. The coat thing really gets me because I'm just imagining if I could be perfectly climate controlled all the time. [laughs]

+ +

NICOLE: Right? Oh my gosh, especially you're based in Chicago [laughs], that is when you can retire the winter coat. That is always an important phase.

+ +

STEPHANIE: Yeah, seriously. I also am thinking now about just like the montages of showing a place, just movies or shows filmed in New York City or whatever, and it's such...so you know it's like the big city, right?

+ +

NICOLE: Mmm-hmm, mm-hmm.

+ +

STEPHANIE: And all of that setup. And it's really interesting to hear that stylistically, that is also different for a show like this where they're trying to convey a certain message.

+ +

NICOLE: Yeah, yeah, definitely.

+ +

STEPHANIE: So I'm really excited to have you on The Bike Shed because I have known you for a few years. And you write this really amazing newsletter called "nicoledonut" about your writing practice. And it's a newsletter that I open every other week when you send out a dispatch. And last year at RubyConf, they had a conference track called Bringing Your Backgrounds With You.

+ +

And there were talks that people gave about how the hobbies that they did outside of work or an identity that they held made them a better developer, like, affected how they showed up at work in a positive way. And as someone who has always been really impressed by the thoughtfulness that you apply to your writing practice, I was really curious about how that shows up for you as an engineering manager.

+ +

NICOLE: Definitely a great question. And to provide a bit of context for listeners, I feel like I have to explain the newsletter title because it's odd. But there's a writer who I really love named Jenny Zhang, and her handle across the Internet is jennybagel. And so I was like, oh, that would be so funny. I should be nicoledonut. I do love donuts. My Neopets username was donutfiend, so it was --

+ +

STEPHANIE: Hell yeah.

+ +

NICOLE: But anyway, so that was kind of...I was like, I need to come up with some fun title for this newsletter, and that is what I settled on. But yes, I've written personal essays and creative nonfiction. And my primary focus more recently these past few years has been fiction. And this newsletter was really kind of born out of a desire to learn in the open, provide resources, act as kind of a journal, and just process ideas about writing and what it means to kind of sustain a creative life.

+ +

So it has definitely made me more reflective and proactively, like you said, kind of think about what that means in terms of how that transfers into my day job in engineering. I recently moved into management a little over a year ago, and before that, I was a senior full-stack engineer working on a lot of our audience experiences and websites and, previously, more of our editorial tools.

+ +

So I think when it comes to obviously writing code and being more of an individual contributor, I think you had previously kind of touched on what does it mean to treat code as a craft? And I do think that there are a lot of similarities between those two things because I think there's creativity in engineering, of course. You have to think about going from something abstract to something concrete. In engineering, you're given generally, or you're defining kind of requirements and features and functionality. You may be make an engineering plan or something like that, an EDD, given those constraints.

+ +

And then I think writing is very similar. You outline, and then you have to actually write the thing and then revise. I do think writing is not necessarily as collaborative as coding is, perhaps, but still similar overall in terms of an author having a vision, dealing with different constraints, if that's word count, if it's form or structure, if it's point of view, things like that. And that all determines what the outcome will be.

+ +

You always learn something in the execution, the idea that planning can only take you so far. And at a certain point, you gather as much background knowledge and information and talk to as many people. Depending on the kinds of writing I do, I have or haven't done as much research. But at a certain point, the research becomes procrastination, and I know I need to actually just start writing.

+ +

And similarly, with engineering, I think that's the piece is that once you actually start implementation, you start to uncover roadblocks. You uncover questions or complications or things like that. And so I think that's always the exciting part is you can't really always know the road ahead of you until you start the journey. And I also think that in order to benefit from mentorship and feedback...we can talk more about this. I know that that's something that is kind of a larger topic.

+ +

And then another thing I think where the two are really similar is there's this endless learning that goes with each of them. I guess that's true of, I think, most crafts. Good practitioners of the craft, I think, take on that mindset. But I do think that obviously, in engineering, you have industry changes, new technologies emerging really frequently. But I do think that good writers think about that, too, in terms of what new novels are coming out. But also, how do you build a solid foundation?

+ +

And I do think it's that contrast that applies in any craft is, you know, you want to have a good solid foundation and learn the basics but then keep up to date with new things as well. So I think there was this...there's this meme I actually did include in the newsletter that was...it's the meme of these two guys looking at different windows of a bus, and one looks really sad, and one looks really happy. But the two of them have the same caption, which is there's always more to learn.

+ +

And so I think that is the two sides of the coin [laughs]. I think that is relevant in engineering and writing that I've kind of brought to both of those practices is trying to be optimistic [laughs] about the idea that there's always more to learn that that's kind of the thought of it.

+ +

And then certainly, when it comes to management, I do think that writing has proven really valuable in that very obvious sense of kind of practical communication where I just write a lot more. I write a lot more things that are not code, I should say, as a manager. And communication is really at the forefront of my job, and so is demonstrating curiosity and building empathy, fostering relationships with people.

+ +

And I do think that particularly writing fiction you have to be curious about people I think to be a writer. And I think that is true of managers as well. So I do think that has been a really interesting way that I didn't anticipate writing showing up in my day job but has been a really helpful thing and has made my work stronger and think about the people, the process, and kind of what we do and why a little differently.

+ +

STEPHANIE: Yeah, absolutely. Wow, you got into a lot of different things I'm excited to keep discussing further. But one thing that I was thinking about as you were talking was, have you heard of the adage, I guess, that code is read many more times than it's written?

+ +

NICOLE: Hmm, I think I have, yeah.

+ +

STEPHANIE: I was thinking about that as you were talking because, in some ways, in most ways, actually, if you ascribe to that adage, I suppose, we write code for others to read. And I think there's an aspect of code telling a story that is really interesting. I've heard a lot of people advocate for writing, thoughtbot included, writing your tests like they're telling a story.

+ +

And so when a future developer is trying to understand what's going on, they can read the tests, understand the setup, read what is being tested, and then read what the expected outcome is and have a complete picture of what's going on. The same goes for commit messages. You are writing little bits of documentation for people in the future.

+ +

And I've also been thinking about how legacy code is just this artifact as well of all of the changes that an organization might have gone through. And so when you see something that you see a bit of code that is really weird or gets your spidey senses tingling, it's almost like, oh, I wonder what happened here that led to this piece left behind?

+ +

NICOLE: Yeah, definitely. Now that you're talking about it, I also think of pull requests as a great way to employ storytelling. I remember there definitely have been times where myself or other engineers are working on a really thorny problem, and we always joke that the PR description is longer than the change. And it's like, but you got to read the PR description in order to understand what change you're making and why. And here's the backstory, the context to kind of center people in that.

+ +

As a manager, I think about storytelling a lot in terms of defining purpose and providing clarity for teams. I was reading Julie Zhuo's "The Making of a Manager," and it was a really kind of foundational text for me when I first was exploring management. And she kind of boils it down to people, purpose, and process.

+ +

And so I do think the purpose part of that is really tied to clear communication. And can you tell a story of what we're doing from really high-level vision and then more tactically strategy? And then making sure that people have bought into that, they understand, can kind of repeat that without you being there to remind them necessarily. Because you really want that message to carry through in the work and that they have that understanding.

+ +

Vision is something I only recently have really started to realize how difficult it is to articulate. It's like you don't really understand the purpose of vision until you maybe don't have one, or you've been kind of just trying to keep your head afloat, and you don't have a Northstar to work towards. But I do think that is what plays into motivation, and team health, and, obviously, quality of the product. So yeah, that's kind of another dimension I've been thinking of.

+ +

And also our foes actually. Sorry, another one. Our foes, I think, like outages and incidents. I think that's always a fun opportunity to talk about stories. There was a period of time where every time we had an incident, you had to present that incident and a recap of it in an engineering all-hands every month. And they ended up being really fun. We turned something that is ostensibly very stressful into something that was very entertaining that people could really get on board with and would learn something from.

+ +

And we had the funniest one; I think was...we called it the Thanks Obama Outage because there was an outage that was caused by a photo of Barack Obama that had been uploaded in our content management system, as required no less, that had some malformed metadata or something that just broke everything. And so, again, it was a really difficult issue [laughs] and a long outage. And that was the result that I remember that presentation being really fun.

+ +

And again, kind of like mythmaking in a way where that is something that we remember. We pay attention to that part of the codebase a lot now. It's taught us a lot. So yeah, I do think storytelling isn't always necessarily the super serious thing, but it can also just be team building, and morale, and culture as well.

+ +

STEPHANIE: Yeah, absolutely. I think what you said about vision really resonates with me because if you don't have the vision, then you're also not making the best decisions you can be making even something as low-level as how you write the code. Because if you don't know are we going to be changing this feature a month from now, that might dictate how you go forth with implementation as opposed to if you know that it's not in the company's vision to really be doing anything else with this particular feature. And you then might feel a little more comfortable with a more rudimentary approach, right?

+ +

NICOLE: Yeah, totally. Whether or not it's, we've over-optimized or not or kind of optimized for speed. Like, it's all about trade-offs. And I do think, again, like you said, having a vision that always you can check your decision-making against and inform the path ahead I think is very, very helpful.

+ +

STEPHANIE: When you write, do you also keep that in mind? Like, do you write with that North Star? And is that really important to your process?

+ +

NICOLE: I think it depends. I think that writing can be a little more at a slant, I suppose, is how I think of it because I don't always...just similar to work, I don't always come in with a fully-fledged fleshed-out vision of what I want a piece to be. The most recent piece I've been working on actually I did have kind of a pretty, I think, solid foundation.

+ +

I've been working on this story about loneliness. And I knew that I wanted to base the structure on the UCLA...a UCLA clinic has this questionnaire that's 20 items long that is about measuring loneliness on a scale. And so I was like, okay, I knew that I wanted to examine dimensions of loneliness, and that would be the structure. It would be 20 questions, and it would be in that format. So that gave me a lot more to start with of, you know, here's where I want the piece to go. Here's what I want it to do.

+ +

And then there have definitely been other cases where it's more that the conceit seems interesting; a character comes to mind. I overhear a conversation on the subway, and I think it's funny, and that becomes the first thing that is put on the page. So I definitely have different entry points, I think, into a draft. But I will definitely say that revision is the phase where that always gets clarified. And it has to, I think, because as much as I'm sometimes just writing for vibes, it's not always like that.

+ +

And I do think that the purpose of revision is to clarify your goals so you can then really look at the piece and be like, is it doing what I want it to? Where is it lacking? Where's it really strong? Where's the pacing falling flat? And things like that. So I do think that sooner or later, that clarity comes, and that vision comes into focus. But it isn't always the first thing that happens, I think, because I do think the creative process is a little bit more mysterious, shall we say, than working on an engineering team. [laughs]

+ +

STEPHANIE: Yeah. Well, you started off responding to my question with it depends, which is a very engineering answer, but I suppose --

+ +

NICOLE: That is true. That is true. You got me. [laughs]

+ +

STEPHANIE: It applies to both.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: You mentioned revision. And so, I do want to talk about feedback because I think that is an important part of the revision process. And I have really loved what you've had to say about writing feedback and your experience with writing feedback, especially in writing workshops. And I have always been really curious about what we might be able to learn about receiving feedback in code review.

+ +

NICOLE: When it comes to receiving feedback, I think I wrote a two-part series of my newsletter, one that was about providing feedback, one that was about receiving it. I think on the side of receiving feedback, first and foremost, I think it's important to know when you're ready to share your work and know that you can share multiple times. In writing, that can be I show a very early draft to my partner who is the person who kind of reads everything and anything at any stage. It's something less polished, and I'm really just testing ideas.

+ +

But then obviously, if there's something that is more polished, that is something I would want to bring to a writing group, bring into a workshop, things like that. Similarly, as engineers, I think...thank God for GitHub drafts actually adopting literally the way in which I think of that, right?

+ +

STEPHANIE: Yeah.

+ +

NICOLE: You can share a branch or a GitHub PR in progress and just check the approach. I've done that so many times, and really that helped so much with my own learning and learning from mentors in my own organization was checking in early and trying to gut-check my work earlier as opposed to later. Because then you feel, I think, again, a bit more naturally receptive because you're already in that questioning phase. You're not like, oh, this is polished, and I've written all the tests, and the PR description is done. And now you want me to go back and change the whole approach from the ground up. That can feel tough. I get that.

+ +

And so I think, hand in hand, what goes with that is whose feedback are you interested in? Is that a peer? Is it a mentor? I think obviously leaning on your own team, on senior engineers, I do think that is one of the primary, I think, expectations of a senior engineer is kind of multiplying the effectiveness of their peers and helping them learn and grow. So I do think that that's a really valuable skill to develop on that end, but also, again, just approaching people.

+ +

And obviously, different teams have different processes for that, if it's daily stand-ups, if it's GitHub reminders, automated messages that get pulled up in your channel, things like that. But there are ways to build that into your day-to-day, which I think is really beneficial too.

+ +

And then there's also the phase of priming yourself to receive the feedback. And I think there's actually a lot of emotional work that I don't think we talk about when it comes to that. Because receiving feedback can always be vulnerable, and it can bring up unexpected emotions. And I think learning how to regulate the emotional response to that is really valuable for us as people but obviously within the workplace too.

+ +

So I've found it really helpful to reflect if I'm getting feedback that...well, first of all, it depends on the format. So I think some people prefer verbal feedback, some people will prefer written. I think getting it in the form of written feedback can be helpful because it provides you some distance. You don't have to respond in the moment. And so I've definitely had cases where I then kind of want to reflect on why certain suggestions might elicit certain reactions if I have a fight or flight response, if I'm feeling ashamed or frustrated, or indignant, all the range of emotions.

+ +

Emotions are, to put the engineering hat on, are information. And so I think listening to that, not letting it rule you per se but letting it inform and help you figure out what is this telling me and how do I then respond, or what should I do next? Is really valuable. Because sometimes it's not, again, actually the feedback; maybe it's more about that, oh, it's a really radical idea. Maybe it's a really...it's an approach I didn't even consider, and it would take a lot of work.

+ +

But again, maybe if I sit and think about it, it is the scalable approach. It's the cleaner approach, things like that. Or are they just touching on something that I maybe haven't thought as deeply about? And so I think there is that piece too. Is it the delivery? Is it something about your context or history with the person giving the feedback too? I think all of those, the relationship building, the trust on a team, all plays into feedback.

+ +

And obviously, we can create better conditions for exchanging and receiving feedback. But I do think there's still that companion piece that is also just about, again, fostering team trust and culture overall because that is the thing that makes these conversations all the easier and less, I think, potentially fraught or high pressure.

+ +

STEPHANIE: 100%. Listeners can't see, but I was nodding very aggressively [laughs] this entire time.

+ +

NICOLE: Loved it.

+ +

STEPHANIE: And I love that you bring up interpersonal relationships, team culture, and feelings. Listeners of the show will know that I love talking about feelings. But I wanted to ask you this exact question because I think code review can be so fraught. And I've seen it be a source of conflict and tension. And I personally have always wanted more tools for giving better feedback. Because when I do give feedback, it's for the person to feel supported to help push their work to be better and for us to do good work as a team.

+ +

And I am really sensitive to the way that I give feedback because I know what it's like to receive feedback that doesn't land well. And when you were talking about investigating what kinds of feelings come up when you do receive a certain kind of comment on a code review or something, that was really interesting to me. Because I definitely know what it's like to have worked really, really hard on a pull request and for it to feel very precious to me and then to receive a lot of change requests or whatever. It can be really disappointing or really frustrating or whatever. And yeah, I wish that we, as an industry, could talk about this stuff more frequently.

+ +

NICOLE: Yeah, for sure. And I do think that you know, I think the longer you work with someone, ideally, again, the stronger relationship you form. You find your own ways of communicating that work for you. I think actually what I've learned in management is, yes, I have a communication style, but I also am flexible with how I work with each of my reports, who, again, have very different working styles, communication styles, learning styles.

+ +

I don't believe that the manager sets the standards. I think there is a balance there of meeting people where they are and giving them what they need while obviously maintaining your own values and practices. But yeah, certainly, again, I think that's why for perhaps more junior engineers, they might need more examples. They might not respond well to as terse a comment.

+ +

But certainly, with engineers, senior engineers that I've worked with, when I was starting out, the more we developed a relationship, they could just get a little bit more terse. For example, they could be like, "Fix this, fix that," and I would not take it personally because we had already gone through the phase where they were providing maybe some more detailed feedback, links to other examples or gists, or things like that, and our communication styles evolved.

+ +

And so I do think that's another thing to think about as well is that it doesn't have to be static. I think that's the value of a team, and having good team process, too, is ideally having arenas in which you can talk about how these kinds of things are going. Are we happy with the cadence? Are we happy with how people are treating each other and things like that? Are we getting timely feedback and things like that? That's a good opportunity for a retrospective and to talk about that in a kind of blameless context and approach that more holistically.

+ +

So I do think that, yeah, feedback can be very fraught. And I think what can be difficult in the world of engineering is that it can be very easy to then just be like, well, this is just the best way for the work. And feelings are, like you said, not really kind of considered. And, again, software development and engineering is a team sport. And so I do think fostering the environment in which everyone can be doing great work is really the imperative.

+ +

STEPHANIE: Yeah, I really like how you talked about the dynamic nature of relationships on a team and that the communication style can change there when you have built that trust and you understand where another person is coming from. I was also thinking about the question of whose feedback are you interested in?

+ +

And I certainly can remember times where I requested a review from someone in particular because maybe they had more context about this particular thing I was working on, and I wanted to make sure that I didn't miss anything, or someone else who maybe I had something to learn from them. And that is one way of making feedback work for me and being set up to receive it well.

+ +

Because as much as...like you said, it's really easy to fall back into the argument of like, oh, what's the best way for the work, or what is the cleanest code or whatever? I am still a person who wrote it. I produced a piece of work and have feelings about it. And so I have really enjoyed just learning more about how I react to feedback and trying to mitigate the stress that I feel in what is kind of inherently like a conflict-generating process.

+ +

NICOLE: Yeah, yeah, definitely. Another thing that kind of popped into my head to one of the earlier questions we were talking about is in terms of similarities between writing and engineering, style and structure are both really, really important. And even though in engineering, like you said, sometimes it can be, I mean, there is a point with engineering where you're like, this line of code works, or it doesn't.

+ +

There is a degree of correctness [laughs] that you do have to meet, obviously. But again, after that, it can be personal preference. It's why we have linters that have certain styles or things like that to try to eliminate some of these more divisive, shall we say, potentially discussions around, [laughs] God forbid, tabs or spaces, naming conventions, all this stuff.

+ +

But certainly, yeah, when it comes to structuring code, the style, or whatever else, like you said, there's a human lens to that. And so I think making sure that we are accounting for that in the process is really important, and not just whether or not the work gets done but also how the work gets done is really important. Because it predicts what do future projects...what does future collaboration look like? And again, you're not just ever optimizing for one thing in one point of time. You're always...you're building teams. You're building products. So there's a long kind of lifecycle to think about.

+ +

STEPHANIE: For sure. So after you get feedback and after you go through the revision process, I'm curious what you think about the idea of what is good enough in the context of your writing. And then also, if that has influenced when you think a feature is done or the code is as good as you want it to be.

+ +

NICOLE: Yeah, definitely. I think when it comes to my writing, how I think about what is good enough I think there is the kind of sentiment common in the writer community that you can edit yourself to death. You can revise forever if you wanted to. It's also kind of why I don't like to go back and read things I've already published because I'm always going to find something, you know, an errant comma or like, oh, man, I wish I had rephrased this here.

+ +

But I do think that, for me, I think about a couple of questions that help me get a sense of is this in a good place to, you know, for me generally, it's just to start submitting to places for publication. So one of those is, has someone else read it? That is always a really big question, whether it's a trusted reader, if I brought it to a workshop, or just my writing group, making sure I have a set of outside eyes, fresh eyes on the piece to give their reaction. And again, truly as a reader, sometimes just as a reader, not even as a fellow writer, because I do think different audiences will take different things and provide different types of feedback.

+ +

Another one is what kinds of changes am I making at this point in time? Am I still making really big structural edits? Or am I just kind of pushing words and commas around, and it feels like rearranging deck chairs on the Titanic? They're not massive changes to the piece.

+ +

And then the final question is always, if this were published in its current state right now, would I be happy with it? Would I be proud of it? And that's a very gut feeling that I think only an individual can kind of feel for themselves. And sometimes it's like, no, I don't like the way, like, I know it's 95% there, but I don't like the way this ends or something else. Again, those are all useful signals for me about whether a piece is complete or ready for submission or anything like that.

+ +

I think when it comes to engineering, I think there's a little bit less of the gut feeling, to be honest, because we have standards. We have processes in place generally on teams where it's like, is the feature working? Have you written tests? Have you written a QA plan if it needs one? If it's something that needs more extensive documentation or code comments or something like that, is that something you've done? Has a bit more of a clear runway for me in terms of figuring out when something is ready to be shown to others.

+ +

But certainly, as a manager, I've written a lot more types of documents I suppose, or types of communication where it's like organizational changes. I've written team announcements. I've written celebration posts. I've had to deliver bad news. Like, those are all things that you don't think about necessarily. But I've definitely had literally, you know, I have Google Docs of drafts of like, I need to draft the Slack message.

+ +

And even though it's just a Slack message, I will spend time trying to make sure I've credited all the right people, or provided all the context, got all the right answers. I run it by my director, my peers, and things like that if it's relevant. And again, I think there is still that piece that comes in of drafting, getting feedback, revising, and then feeling like, okay, have I done my due diligence here, and is it ready? That cycle is applicable in many, many situations. But yeah, I certainly think for direct IC work, it's probably a little bit more well-defined than some of the other processes.

+ +

STEPHANIE: Yeah, that makes sense. I really liked what you said about noticing the difference between making big structural changes and little word adjustments. I think you called it pushing commas around or something like that.

+ +

NICOLE: [laughs] Yeah.

+ +

STEPHANIE: I love that. Because I do think that with programming, there is definitely a big part of it that's just going on the journey and exploring different avenues. And so if you do suddenly think of, oh, I just thought of a completely different way to write this code, that is worth exploring even if you just end up going back to the original implementation. But at least you saw that thought through, and you're like, okay, this doesn't work because of X, Y, and Z, and I'm choosing to go this other route instead. And I think that, yeah, that is just a good practice to explore.

+ +

NICOLE: Another example of storytelling, too, where it's like, you can tell the story in the PR description or whatever, in stand-up, to be like, I also did go down this path, XYZ reason. Here's why it didn't work out, and here's what we're optimizing for. And there you go. So I do think we talk...I guess product managers think more about buy-in, but I think that's true of engineers too. It's like, how do you build consensus and provide context?

+ +

And so yeah, I think what you were saying, too, even if the path is circuitous or you're exploring other avenues, talking to other people, and just exploring what's out there, it all adds up to kind of the final decision and might provide, again, some useful information for other people to understand how you arrived there and get on board with it.

+ +

STEPHANIE: 100%. I remember when I worked with someone who we were writing a PR description together because we had paired on some code. And we had tried three different things. And he wrote paragraphs for each thing that we tried. And I was like, wow, I don't know if I would have done that on my own. But I just learned the value of doing that to, like you said, prime yourself for feedback as well, being like, I did try this, and this is what I thought. And other people can disagree with you, but then at least they have the information, right?

+ +

NICOLE: Definitely.

+ +

STEPHANIE: So before we wrap up, the last thing that I wanted to talk about, because I think it's super cool, is just how you have a totally separate hobby and skill and practice that you invest time and energy into that's not programming. And it's so refreshing for me to see you do that because I think, obviously, there's this false idea that programmers just code all the time in their free time, in their spare time, whatever. And I'm really curious about how writing fits into your life as something separate from your day job.

+ +

NICOLE: Yes, I've been thinking about this a ton. I think a lot of people, the last couple of years has forced a really big reckoning about work and life and how much we're giving to work, the boundaries that can be blurred, how capitalism butts its head into hobbies, and how we monetize them, or everything is a side hustle. And, oh, you should have a page running...oh, you should charge for a newsletter. And I think there's obviously the side of we should value our labor, but also, I don't want everything in my life to be labor. [laughs]

+ +

So I do think that is interesting. Writing to me, I actually do not see it as a hobby. I see it as another career of mine. I feel like I have two careers, but I have one job, [laughs] if that makes sense. I certainly have hobbies. But for me, what distinguishes that from my writing is that with hobbies, there's no expectation that you want to get better. You approach it with just...it's just pure enjoyment. And certainly, writing has part of that for me, but I have aspirations to publish. I love it when my work can reach readers and things like that.

+ +

But I do think that regardless having other interests, like you said, outside engineering, outside technology, it's a great break. And I do think also in technology, in particular, I notice...I think we're getting away from it, but certainly, there's an expectation, like you said, that you will have side projects that you code in your free time, that you're on Hacker News.

+ +

I think there is a little bit of that vibe in the tech industry that I don't see in other industries. You don't expect a teacher to want to teach in their free time, [laughs] you know what I mean? But we have almost that kind of implicit expectation of engineers to always be staying up to date on those things.

+ +

I think with writing and engineering; the two complement each other in some interesting ways. And they make me appreciate things about the other craft or practice that I may not previously have. And I think that with engineering, it is a team effort. It's really collaborative, and I really love working in that space. But on the flip side, too, with writing, I do love, you know, there's the ego part of it. You don't have individual authorship over code necessarily unless it's git blame level. But there's a reason why it's called git blame, [laughter] even the word is like git blame.

+ +

I've literally had cases where I'm like, oh, this thing is broken. Who wrote this? And then I was like, oh, surprise, it was you six years ago. But I do think with writing; it's an opportunity for me to really just explore and ask questions, and things don't have to be solved. It can just be play. And it is a place where I feel like everything that I accomplish is...obviously, I have people in my life who really support me, but it is a much more individual activity. So it is kind of the right-left brain piece.

+ +

But I've been reading this book called "Saving Time." It is what my microphone is currently propped on. But it's by Jenny Odell, who wrote: "How to Do Nothing." It's breaking my brain in a really, really, really good way. It talks a lot about the origin of productivity, how we think about time, and how it is so tied to colonialism, and racism, and capitalism, and neoliberalism, all these things. I think it has been really interesting.

+ +

And so thinking about boundaries between work and writing has been really, really helpful because I really love my job; I'm not only my job. And so I think having that clarity and then being like, well, what does that mean in terms of how I divide my time, how I set examples for others at work in terms of taking time off or leaving the office on time? And trying to make sure that I have a good emotional headspace so that I can transition to writing after work; all those things. I think it is really interesting.

+ +

And that also, ultimately, it's we're not just our productivity either. And I think writing can be very, again, inherently kind of unproductive. People joke that cleaning is writing, doing the dishes is writing, taking a walk is writing, showering is writing, but it is true. I think that the art doesn't talk about efficiency. You can't, I think, make art always more efficient in the same way you can do with engineering. We don't have those same kinds of conversations. And I really like having that kind of distinction.

+ +

Not that I don't like problem-solving with constraints and trade-offs and things like that, but I also really like that meandering quality of art and writing. So yeah, I've been thinking a lot more about collective time management, I guess, and what that means in terms of work, writing, and then yeah, hobbies and personal life. There are never enough hours in the day. But as this book is teaching me, again, maybe it's more about paradigm shifting and also collective policies we can be putting in place to help make that feeling go away.

+ +

STEPHANIE: For sure. Thank you for that distinction between hobby and career. I really liked that because it's a very generative mindset. It's like a both...and... rather than an either...or... And yeah, I completely agree with you wanting to make your life expansive, like, have all of the things. I'm also a big fan of Jenny Odell. I plugged "How to Do Nothing" on another episode. I am excited to read her second book as well.

+ +

NICOLE: I think you'll like it a lot. It's really excellent. She does such interesting things talking about ecology and geology and geographic time skills, which is really interesting that I don't know; it's nice to be reminded that we are small. [laughter] It's a book that kind of reminds you of your mortality in a good way, if that makes sense. But much like Gary on your porch reminds you of mortality too [laughs] and that you have to put Gary away for a little bit so that his time can come in October. [laughs]

+ +

STEPHANIE: Exactly, exactly. Cool. On that note, let's wrap up. Thank you so much for being on the show, Nicole.

+ +

NICOLE: Thank you so much for having me. This was a blast.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+J_64qHCG + + ]]> + + Stephanie Minn + + + 382: Domain-Specific Languages + https://bikeshed.thoughtbot.com/382 + 6107e121-a808-4a50-bdcc-e4717e130fd3 + Tue, 02 May 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël has been integrating a third-party platform into a testing pipeline...and it has not been going well. Because it's not something she usually keeps up-to-date with, Stephanie is excited to learn about more of the open-source side of things in Ruby, what's new in the Ruby tooling world, and what folks are thinking about regarding the future of the language. + +Today's topic is inspired by an internal thoughtbot Slack thread about writing a custom matcher for Rspec. Stephanie and Joël contrast DSLs vs. Object APIs and also talk about: + +* CanCanCan vs Pundit +* RSpec DSL +* When is a DSL helpful? +* Why not use both DSLs & Object APIs? +* Extensibility +* When does a DSL become a framework? + 36:09 + no + + + Joël has been integrating a third-party platform into a testing pipeline...and it has not been going well. Because it's not something she usually keeps up-to-date with, Stephanie is excited to learn about more of the open-source side of things in Ruby, what's new in the Ruby tooling world, and what folks are thinking about regarding the future of the language. +Today's topic is inspired by an internal thoughtbot Slack thread about writing a custom matcher for Rspec. Stephanie and Joël contrast DSLs vs. Object APIs and also talk about: +CanCanCan vs Pundit +RSpec DSL +When is a DSL helpful? +Why not use both DSLs & Object APIs? +Extensibility +When does a DSL become a framework? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +RubyKaigi 2023 (https://rubykaigi.org/2023/) +Mystified by RSpec’s DSL? by Jason Swett (https://www.codewithjason.com/mystified-rspecs-dsl-parentheses-can-add-clarity/) +Building Custom RSpec Matchers with Regular Objects (https://thoughtbot.com/blog/building-custom-rspec-matchers-with-regular-objects) +FactoryBot (https://github.com/thoughtbot/factory_bot) +Writing a Domain-Specific Language in Ruby by Gabe Berke-Williams (https://thoughtbot.com/blog/writing-a-domain-specific-language-in-ruby) +Capybara (https://teamcapybara.github.io/capybara/) +Acceptance Tests at a Single Level of Abstraction (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) +CanCanCan (https://github.com/CanCanCommunity/cancancan) +Pundit (https://www.capvidia.com/products/pundit) +Discrete Math and Functional Programming (https://www.amazon.com/Discrete-Mathematics-Functional-Programming-VanDrunen/dp/1590282604) +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 little bit of what we've learned along the way. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I've been integrating a third-party platform into our testing pipeline for my client. It has not been going well. We've been struggling a little bit, mostly just because tests just kind of crash. Our testing pipeline is pretty complex. It's a lot of one script, some environment variables, does a few things, shells out to another script, which is in a different language. Does a few more things, shells out to another script, maybe calls out to rake, calls out to a shell script. There are four or five of these in a chain, and it's a bit of a mess. +Somewhere along in there, something is not compatible with this third-party service that we're trying to integrate with. I was pairing this week with a colleague. And we were able to reproduce a situation where we were able to get a failure under some conditions and a success under other conditions. So these are basically, if we run the whole chain of scripts that call each other from the beginning, we know we get a failure. And if we skipped entirely the chain of scripts that set up things and then just manually try to invoke a third-party service, that works. +And so now we know that there's something in between that's incompatible, and now it's just about narrowing things down. There are a few different approaches we could take. We could try to sort of work our way forward. We know a known point where it breaks and then just try to start the chain one step further and see where it fails. We could try to get fancy and do a binary search, like split it in half and then half and half again. +We ended up doing it the other way, where we started at the end. We had our known good point and then just stepping one step back and saying, okay, now we introduce the last script in the chain. Does that work? Okay, that pass is great. Let's go one step further; two scripts up in the chain. And at some point, we find, okay, here's the one script that fails. Now, what is it within this script? And it was a really fun debugging session where we were just narrowing things down until we found the source of the bug. +STEPHANIE: Wow, that sounds pretty complicated. It just seems like there are so many layers going on. And it was really challenging to pinpoint where the source of the issue was. +JOËL: Definitely. I think all the layers made it really complicated. But having a process that we could follow and then kind of narrowing it down made it almost mechanical to figure out where the bug was once we got to a point where we had a known good point and a known bad point. +STEPHANIE: Yeah, that makes sense. Kind of sounds like if you are using git bisect or something like that to narrow down the scope of where the issue could be. I'm curious because this is like a bunch of shell scripts and rake tasks or commands or whatever. What would have made this debugging process easier? +JOËL: I think having fewer scripts in this chain. +STEPHANIE: [laughs] That's fair. +JOËL: We don't need so many scripts that call out to each other in different languages trying to share data via environment variables. So we've got a bit of a Rube Goldberg machine, and we're trying to patch in yet another piece in there. +STEPHANIE: Yeah, that's really tough. I was curious if there was, I don't know, any logging or any other clues that you were getting along the way because I know from experience how painful it is to debug that kind of code. +JOËL: It's interesting because I feel like normally logging is something that's really useful. In this particular case, we run into an exception at some point. So it's more of under what conditions does the exception happen? The important thing was to find that there is a point where it breaks, and there's a point where it doesn't, and realizing that if we ran some of these commands just directly without going through the whole pipeline, that things did work and that we were not triggering that exception. +So all of a sudden, now that tells us, okay, something in our pipeline is wrong. And then we can just start narrowing things down. So yeah, adventures in debugging. Sometimes it's really frustrating, but then when you have a good process, and you find the bug, it's incredibly satisfying. +STEPHANIE: I like that you used a process that can be applied to many different problems, in this particular case, debugging a testing pipeline. Maybe not something that we do every day, but certainly, it comes up, and now we have tools to address those kinds of issues as well. +JOËL: So my week has been up and down with all of this debugging. What's been new in your world? +STEPHANIE: I've been doing some travel planning because I'm going to RubyKaigi in Japan. +JOËL: Whoa. +STEPHANIE: This is actually going to be my first international conference, so I'm really looking forward to that. I just have never been compelled to travel abroad to go to a tech conference. But I'm really looking forward to going to RubyKaigi because now I've been to the U.S.-based conferences a few times. And I'm excited to see how things are different at an international conference and specifically a RubyKaigi because, obviously, there's a lot of really cool Ruby work happening over there in Japan. +So I'm excited to learn about more of the open-source side of things of Ruby, what's new in the Ruby tooling world, and just what folks are thinking about in terms of the future of the language. That's not something I normally keep super up-to-date on. But I'm excited to be around people who do think and talk about these things a lot and maybe get some new insights into my own work. +JOËL: Do you find that you tend to keep up more with some of the frameworks like Rails rather than the underlying language itself? +STEPHANIE: Yeah, that's a good question. I do think because the framework changes a little more frequently, new releases are kind of more applicable to the work that I'm doing. Whereas language updates or upgrades are a little bit less top of mind for me because the point is that it doesn't have to change [laughs] all that much, and we can continue to work with things as expected and not be disrupted. +So it is definitely like a whole new world for me, but I'm really looking forward to it. I think it will be really interesting and just kind of a whole other space to explore that I haven't really because I've usually been focused on more of the web development and industry work side of things. +JOËL: What's a Ruby feature that either is coming out in the future or that came out in the last couple of releases that got you really excited? +STEPHANIE: I think the conversation about typing in Ruby is something that has been on my radar but has also been ebbing and flowing over time. And I did see a few talks at RubyKaigi this year that are going to talk about how to introduce gradual typing in Ruby. And now that it has been out for a little bit and people have been using it, how people are feeling about it, pros and cons, and kind of where they're going to take it or not take it from there. +JOËL: Have you done much TypeScript? +STEPHANIE: I have been working more in TypeScript recently but did spend most of my front-end work coding days in JavaScript. And so that transition itself was pretty challenging for me where I suddenly felt a language that I did know pretty well. I was having to be in that...in somewhat of a beginner's mindset again. Even just reading the code itself, there were just so many new things to be looking at in terms of the syntax. And it was a difficult but ultimately pretty rewarding experience because the way I thought about JavaScript afterwards was much more refined, I think. +JOËL: Types definitely, I think, change the way you think about code; at least, that's been my experience. +STEPHANIE: Yeah, absolutely. I haven't gotten the pleasure to work with types in Ruby just yet, but I've just heard different experiences. And I'm excited to see what experts have to say about it. +JOËL: That's the fun of going to a conference. +STEPHANIE: Absolutely. So yeah, if any listeners are also headed to RubyKaigi, yeah, look out for me. +JOËL: I was recently having a conversation with someone about the fact that a lot of languages provide ways to sort of embed many languages within them. So the Lisp family of languages are really big into macros and metaprogramming. Some other languages are big into giving you the ability to build your own ASTs or have really strong parsing capabilities so that you can produce your own, again, mini-language. +And Ruby does this as well. It's pretty popular among the Ruby community to build DSLs, Domain-Specific Languages using some of Ruby's built-in abilities. But it seems to be a sort of universal need or at the very least a universal desire among programmers. Have you ever found yourself as a code author wanting to embed a sort of smaller language within your application? +STEPHANIE: I don't think I have, to be honest. It's a very interesting question. Because I think the motivation to build your own mini-language using Ruby would have to be you'd have to have a really good reason for it, and in my experience, I haven't quite encountered that yet. Because, yeah, it seems like a lot of upfront work, a lot of overhead to introduce something like that, especially if it's not necessarily either a really, really particular domain that others might find a use for, or it just doesn't end up seeming worthwhile if I can just write regular, old Ruby code. +JOËL: I think you're not alone. I think the Ruby community has been kind of a bit of a pendulum here where several years ago, everything that could be made into a DSL was. Now the pendulum kind of has been swinging the other way. And we see DSLs, but they're not quite as frequent. For those who maybe have not experienced a DSL or aren't quite familiar with the concept, how would you describe the idea? +STEPHANIE: I think I would describe domain-specific languages as a bit of a mini-language that is created for a very particular problem space in mind to make development for that domain easier. Oftentimes, I've also kind of seen people describe the benefit of DSLs as being able to read that language as if it were plain English. +And so, in my head, I have kind of, at least in the Ruby world, right? We see that a lot in different gems. RSpec, for example, has its own internal DSL, and many people really enjoy it because it took the domain of testing. And the way you write it kind of is how you might read or understand it in English. And so it's a bit easier to talk about what you're expecting in your tests. +JOËL: Yeah, it's so high-level and minimal and domain-specific that it almost stops feeling like it's a programming language and can almost feel like it's a high-level configuration for this very particular domain, sometimes even to the point where the idea is that a non-programmer could read it and understand what's going on. +STEPHANIE: I think RSpec is actually one of the first Ruby DSLs that you might encounter when you're learning Ruby for the first time. And I've definitely seen developers who are new to Ruby, you know, they're writing code, and they're like, okay, I'm ready to write a test now. And the project uses RSpec because that's what most of us use in our Rails applications. And then they see, like you said, almost a configuration language, and they are really confused. They're not really sure what they're reading. They struggle with the syntax a lot. And it ends up being a point of frustration when they're first starting out if they're not just copying and pasting other existing RSpec tests. I'm curious if you've seen that before. +JOËL: I've definitely seen that. And it's a little bit ironic because oftentimes, an argument for DSL is that it makes things simpler that you don't even have to know Ruby; you can just write it. It's simpler. It's easier to write. It's easier to understand. And to a certain extent, maybe that's true. But for someone who does know Ruby and doesn't know your particular little domain language, now they're encountering something that they don't know. And they're having to learn it, and they're having to struggle with it. And it might behave a little bit weirdly compared to how Ruby normally works. And so sometimes it doesn't make it easier for adoption. But it does look really good in a README. +STEPHANIE: That's totally fair. I think the other thing that's interesting about RSpec is that a lot of it is really just stylistic. I actually read a blog post by Jason Swett and the headline of it was "Mystified by RSpec's DSL? Some parentheses can add clarity." And he basically goes on to tell us that really RSpec is just leaning on some of Ruby's syntactic sugar of omitting parentheses for method calls. And if you just add the parentheses back in your it blocks or your describes, it can read a lot more like regular Ruby. And you might have a better time understanding what's going on when you realize that we're just passing our descriptors as arguments along with some blocks. +JOËL: That's ironic given that oftentimes, the goal of these is to make it look like not Ruby. +STEPHANIE: I agree; it is ironic. [laughs] +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: I think another drawback that I've seen with DSLs is that they oftentimes are more limited in their capabilities. So if the designer of the gem didn't explicitly think of your use case, then oftentimes, it can be really hard to extend or to support edge cases that are not specifically designed for that language in the way that plain Ruby is often much more flexible. +STEPHANIE: Yeah, that's really interesting because when a gem does have some kind of DSL, a lot of effort probably went into making that the main interface that you would work with or you would use. And when that isn't working for your use case, the design of the underlying objects may or may not be helpful for the changes that you want to make. +JOËL: I think it's interesting that you mentioned the underlying objects because those are often sort of not meant for public consumption when you're building a gem that's DSL forward. I think, in many cases, my ideal gem would make those underlying objects the primary interface and then maybe offer DSL as a kind of nice-to-have layer on top for those situations that maybe aren't as complex where writing things in the domain language might actually be quite nice. But keeping those underlying objects as the interface, it's nice to use and well-documented for the majority of people. +STEPHANIE: Yeah, I like that too because then you can get the best of both worlds. So speaking of trying to make a DSL work for you, have you ever experienced having to kind of work around the DSL to get the functionality you were hoping to achieve? +JOËL: So I think we're talking about the idea of having both a DSL and the underlying objects. And RSpec is a great example of this with their custom matchers. RSpec itself is a DSL, but then they also offer a DSL to allow you to create custom matchers. And it's not super well documented. I always forget how to define them, and so I oftentimes don't bother. It's just kind of too much of a pain for something that doesn't always provide that much value. But if it were easy, I would probably do it more. Eventually, I realized that you could use just regular Ruby objects as custom matchers. And they just seemed to respond to certain methods, just regular old objects and polymorphism. +And all of a sudden, now I'm back into all of the tools and mechanisms that I am familiar with, like the back of my hand. I can write objects all day. I can TDD them. I can apply any patterns that I want to if I'm doing something really complicated. I can extract helpers. All of that works really well with the knowledge that I already have without having to sink a lot of time into trying to learn the built-in DSL. +So, for the most part, now, when I define custom matchers, I'll often jump directly to creating a regular object and making it conform to the matcher interface rather than relying on the DSL for that. So once we go back to the test, now we're back in DSL land. Now we're no longer talking in terms of objects so much. We'll have some nice methods and they will all kind of read like English. So to pull a recent example that I worked on, I might say something like expect this policy object method to conform to this truth table. +STEPHANIE: That's a really interesting example. It actually kind of sounds like it hits the sweet spot of what you were describing earlier in the sense that it has a really nice DSL, but also, you can create your own objects, and that has an interface that you can implement. And yes, have your cake and eat it too. [laughs] But the idea that then you're kind of converting it back to the DSL because that is just what we know, and it has become so normalized. +I was talking earlier about okay; when is a DSL worthwhile? When is the use case a good reason to implement it? And especially for gems that I think that are really popular that we as a Ruby community have collectively used most of the time on our projects because we have oftentimes a lot of the same problems that we're solving. It seems like this has become its own shared language, right? +JOËL: Yeah, there are definitely some DSLs that we all end up learning because they're just so prominent in the Ruby community, even Rails itself ships with several built-in DSLs. +STEPHANIE: Yeah, absolutely. FactoryBot is another one, too. It is a gem by thoughtbot. And actually, in preparation to talk about DSLs with you today, I scoured our blog and found a really great blog post, "Writing a Domain-Specific Language in Ruby" by Gabe Berke-Williams. And it is basically like, here's how to write something like FactoryBot and creating your own little mini Ruby DSL for something that would be very similar to what FactoryBot does for fixtures. +JOËL: That's a great resource, and we'll make sure to link that in the show notes. We've been talking about some of the limitations of DSLs or some aspects of them maybe that we personally don't like. What are maybe examples of DSLs that you do enjoy working with? +STEPHANIE: Yeah, I have an example for this one. I really enjoy using Capybara's DSL for acceptance testing. I did have to go down the route of writing some custom selectors for...I just had some HTML elements within kind of a complicated table and was trying to figure out how to write some selectors so that I could write the test as if it were in, you know, quote, unquote, "plain English" like, within this table, expect some value. +And that was an interesting journey. But I think that it really helped me have a better understanding of accessibility of just the underlying building blocks of the page that I was working with. And, yeah, I really appreciate being able to read those tests from a user perspective and kind of know exactly what they're doing when they're interacting with this virtual browser without having to run it in headful mode and see it for myself. +JOËL: It's always great when a DSL can give you that experience of abstracting enough to where it makes the code delightful to work with while also not having too high a cost to learn or being too restrictive in what it allows you to do. Would you make a difference between something that's a DSL versus maybe just code that's written at a higher level of abstraction? +So maybe to get back to your example with Capybara, it's really nice to have these nice custom matchers and all of these things to work with HTML pages. If I'm writing, let's say, a helper method at the bottom of a test, I don't think that feels quite like it's a DSL yet. But it's definitely a higher level than specifying CSS selectors. So would you make a difference between those two things? +STEPHANIE: That's a good question. I think it's one of those you know it when you see it kind of questions because it just depends on the amount of abstraction, like you mentioned, and maybe even metaprogramming. That takes something from the core language to morph into what you could qualify as a separate language. What do you think about this? +JOËL: Yeah, part of me almost wonders if this exists kind of on a continuum, and the boundary might be a little bit fuzzy. I think there might be some other qualifications that come with it as well. Even though DSLs are typically higher-level helpers, it's usually more than just that. There are also sort of slightly different semantics in the way that you would tend to use them to the point where while they may be just Ruby methods, we don't use them like Ruby methods, and even to the point that we don't think of them as Ruby methods. +To go back to that article you mentioned from Jason, where just reminding people, hey, if you put params on this, all of a sudden, it helps you remember, oh, it's just a Ruby method instead of being like, oh, this is a language keyword or something. +STEPHANIE: Yeah, I wonder if there's also something to the idea of domain specificity where it should be self-service within the domain that you're working. And then it has limitations once you are trying to do something separate from the domain. +JOËL: Right, it's an element of focus to this. And I think it's probably also a language is not just one helper; it's a collection typically. So it's probably a series of high-level helpers, potentially. They might not be methods, even though that is ultimately one of the primary interfaces we use to run code in Ruby. So it's a collection of methods that are high-level, but the collection itself is focused. And oftentimes, they're meant to be used in a way where it's not just a traditional method call. +STEPHANIE: Right. There's some amount of you bringing to the table your own use case in how you use those methods. +JOËL: Yeah, so it might be mimicking a language keyword. It might be mimicking the idea of a configuration. We see that a little bit with ActiveRecord and some of the, let's say, the association and validation APIs. Those kind of feel like, yes, they're embedded in a class, but they feel like either keywords or even just straight-up configuration where you set key-value pairs of things to configure how a particular class is going to work. +STEPHANIE: Yeah, that's true for a lot of things in Rails, too, if we're talking about routes and initializers as well. +JOËL: So I've complained about some things I don't like about DSLs. I really like the routing DSL in Rails. +STEPHANIE: Why is that? +JOËL: I think it's very compact and readable. And that's an element that's really nice about DSLs is that it can make things feel very readable and, oftentimes, we read code more often than we write it. And routes have...I was going to say fewer edge cases, but I have seen some really gnarly route files that are pretty awful to work with, especially if you're mostly writing RESTful controllers, and I would recommend that people do. It's really nice to just be able to skim through a route file and be like, oh, these are the resources in my app and the actions I can do on each resource. And here are the ones that are nested. +STEPHANIE: Yeah, it almost sounds like a DSL can provide guardrails towards the recommended way of tackling that particular domain. The routes DSL really discourages you from doing anything too complicated because they are encouraging you to follow the Rails convention. And so I think that goes back to the specificity piece of if you've written a DSL, it's because you've thought very deeply about this particular domain and how common problems show up and how you would want people to be empowered by the language rather than inhibited by it. +JOËL: I think, thinking more about that, the word that comes to mind is declarative. When you read code that's written with DSLs, typically, it's very declarative. It's more just describing a thing as opposed to either procedural, a series of commands to do, or even OO, where you're composing objects and sending messages to each other. And so problems that lend themselves to being implemented through more descriptive and declarative approaches probably are really good candidates for a DSL. +STEPHANIE: Yeah, I like that a lot because when we talk about domains, we're not necessarily talking about a business domain, which is kind of the other way that some folks think about that word. We're talking about a problem space. And the idea of the language being declarative to describe the problem space makes a lot of sense to me because you want it to be flexible enough for different use cases but all within the idea of testing or browser navigation or whatever. +JOËL: Yeah. I feel like there's a lot of... there are probably more problems that can be converted to declarative solutions than might initially kind of strike you. Sometimes the problem isn't quite as bounded. And so when you want customizations that are not supported by your DSL, then it kind of falls apart. So I think a classic situation that might feel like something declarative is authorization. +Authorization are a series of rules for who can access what, and it would seem like this is a great case for a DSL. Wouldn't it be great to have just one file you can just kind of skim, and we can just see all of the access rules? Access rules that are basically asking to be done declaratively. And we have gems like that. The original CanCan gem and then the successor CanCanCan are trying to follow that approach. Have you used either of those gems? +STEPHANIE: I did use the CanCanCan gem a while ago. +JOËL: What was your experience with that style of authorization? +STEPHANIE: It has been a while but I do remember having to check that original file of like all the different authorizations kind of repeatedly coming back to it to remember, okay, for this rule, what should be allowed to happen here? +JOËL: So I think that's definitely one of the benefits is that you have all of your rules stored in one place, and you can kind of scan through the list. My experience, though, is that in practice, it often kind of balloons up and has all of these edge cases in it. And in some earlier versions, I don't know if that's still a problem today, it could even be difficult to accomplish certain things. +If you're going to say that access to this particular object depends not on properties of that object itself but on some custom join or association or something like that, that could be really clunky to do or sometimes impossible depending on how esoteric it is or if there's some really complex custom logic to do. And once you're doing something like that, you don't really want to have that logic in your...in this case, it would be the abilities file but inside because that's not really something you express via the DSL anymore. Now you're dropping into OO or procedural world. +STEPHANIE: Right. It seems a bit far removed from where we do actually care about the different abilities, especially for one-off cases. +JOËL: That is interesting because I feel like there's a bit of a read-versus write-situation happening there as well. It's particularly nice to have, I think, everything in one abilities file for reading and for auditing. I've definitely been in code where there's like three or four ways to authorize, and they're all being used inconsistently, and that's not nice at all. +On the other hand, it can be hard with DSL sometimes to customize or to go beyond the rules that are built in. In the case of authorization, you've effectively built a little mini-rules engine. And if you don't have a good way for people to add custom rules without just embedding procedural code into your abilities file, it's going to quickly get out of hand. +STEPHANIE: Yeah, that makes sense. On the topic of authorization, you did mention an example earlier when you were writing a policy object. +JOËL: I've generally found that that's been my go-to pattern for authorization. I enjoy the Pundit gem that provides some kind of light scaffolding around working with policy objects, but it's a general pattern, and you can absolutely write your own. You don't need a gem for that. Now we're definitely not in the DSL world. We're not doing this declaratively. We're leaning very heavily on OO and saying we're just going to create objects. They talk to each other. They can do anything that any Ruby object can do and as simple or as complex as they need to be. +So you have the full power of Ruby and all the patterns that you're used to using. The downside is it is a little bit harder to read and to kind of just audit what's happening in terms of permission because there's no high-level overview anymore. Now you've just got to look through a bunch of classes. So maybe that's the trade-off, flexibility, extensibility versus more declarative style and easy overview. +STEPHANIE: That makes a lot of sense because we were talking earlier about guardrails. And because those boundaries do exist, that might not give us the flexibility we want compared to just writing regular Ruby objects. But yeah, we do get the benefit of, like you said, auditing, and at least if we don't try to do some really gnarly, custom stuff, [laughs] something that's easier to read and comprehend. +JOËL: And, again, maybe that's where in the best of both worlds situation, you say, hey, I'm creating some form of rules engine, whether it's for describing routes, or authorization, permissions, or users can build custom business rules for a product or something like that. And it's all object-based under the hood. And then, we provide a DSL to make it nice to work with these rules. +If a programmer using our gem wants to write a custom rule that just really extends what the ones we shipped can do, allow them to do that via the object API. We have all the objects available to you that underlie the DSL. Add more rules yourself. And then maybe those can be plugged back into the DSL like we saw with the RSpec and custom matchers. Or maybe you have to say, okay, if I have a custom rule object, now I have to just stay in the object space. And I think both of those solutions are okay. But now you've sort of kept those two worlds separate and still allowed people to extend. +STEPHANIE: I like that as contributing to the language because language is never static. It changes over time. And that's a way that people can continue to evolve a language that may have been originally written at a certain time and place. +JOËL: Moving on from DSLs, we got some listener feedback recently from James, who was listening to our episode on discrete math. And James really appreciated the episode and wanted to share a resource with us. This is the book "Discrete Math and Functional Programming" by Thomas VanDrunen. It's an introduction to discrete math as a theoretical concept taught side by side with the very practical aspect of learning to use the language standard ML, and both of those factor into each other. +So you're kind of learning a little bit of theory and some practice, at the same time, getting to implement some discrete math concepts in standard ML to get a feel for them. Yeah, I've not read this book, but I love the concept of pairing a theoretical piece and a practical piece. So I'll drop a link to it in the show notes as well. Thank you, James. +STEPHANIE: Yeah, thanks, James. And I guess this is just a little reminder that if our listeners have any feedback or questions they want to write in about, you can reach us at hosts@bikeshed.fm. +JOËL: On that note. Shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël has been integrating a third-party platform into a testing pipeline...and it has not been going well. Because it's not something she usually keeps up-to-date with, Stephanie is excited to learn about more of the open-source side of things in Ruby, what's new in the Ruby tooling world, and what folks are thinking about regarding the future of the language.

+ +

Today's topic is inspired by an internal thoughtbot Slack thread about writing a custom matcher for Rspec. Stephanie and Joël contrast DSLs vs. Object APIs and also talk about:

+ +
    +
  • CanCanCan vs Pundit
    • +
  • RSpec DSL
    • +
  • When is a DSL helpful?
    • +
  • Why not use both DSLs & Object APIs?
    • +
  • Extensibility
    • +
  • When does a DSL become a framework?
    • +
+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been integrating a third-party platform into our testing pipeline for my client. It has not been going well. We've been struggling a little bit, mostly just because tests just kind of crash. Our testing pipeline is pretty complex. It's a lot of one script, some environment variables, does a few things, shells out to another script, which is in a different language. Does a few more things, shells out to another script, maybe calls out to rake, calls out to a shell script. There are four or five of these in a chain, and it's a bit of a mess.

+ +

Somewhere along in there, something is not compatible with this third-party service that we're trying to integrate with. I was pairing this week with a colleague. And we were able to reproduce a situation where we were able to get a failure under some conditions and a success under other conditions. So these are basically, if we run the whole chain of scripts that call each other from the beginning, we know we get a failure. And if we skipped entirely the chain of scripts that set up things and then just manually try to invoke a third-party service, that works.

+ +

And so now we know that there's something in between that's incompatible, and now it's just about narrowing things down. There are a few different approaches we could take. We could try to sort of work our way forward. We know a known point where it breaks and then just try to start the chain one step further and see where it fails. We could try to get fancy and do a binary search, like split it in half and then half and half again.

+ +

We ended up doing it the other way, where we started at the end. We had our known good point and then just stepping one step back and saying, okay, now we introduce the last script in the chain. Does that work? Okay, that pass is great. Let's go one step further; two scripts up in the chain. And at some point, we find, okay, here's the one script that fails. Now, what is it within this script? And it was a really fun debugging session where we were just narrowing things down until we found the source of the bug.

+ +

STEPHANIE: Wow, that sounds pretty complicated. It just seems like there are so many layers going on. And it was really challenging to pinpoint where the source of the issue was.

+ +

JOËL: Definitely. I think all the layers made it really complicated. But having a process that we could follow and then kind of narrowing it down made it almost mechanical to figure out where the bug was once we got to a point where we had a known good point and a known bad point.

+ +

STEPHANIE: Yeah, that makes sense. Kind of sounds like if you are using git bisect or something like that to narrow down the scope of where the issue could be. I'm curious because this is like a bunch of shell scripts and rake tasks or commands or whatever. What would have made this debugging process easier?

+ +

JOËL: I think having fewer scripts in this chain.

+ +

STEPHANIE: [laughs] That's fair.

+ +

JOËL: We don't need so many scripts that call out to each other in different languages trying to share data via environment variables. So we've got a bit of a Rube Goldberg machine, and we're trying to patch in yet another piece in there.

+ +

STEPHANIE: Yeah, that's really tough. I was curious if there was, I don't know, any logging or any other clues that you were getting along the way because I know from experience how painful it is to debug that kind of code.

+ +

JOËL: It's interesting because I feel like normally logging is something that's really useful. In this particular case, we run into an exception at some point. So it's more of under what conditions does the exception happen? The important thing was to find that there is a point where it breaks, and there's a point where it doesn't, and realizing that if we ran some of these commands just directly without going through the whole pipeline, that things did work and that we were not triggering that exception.

+ +

So all of a sudden, now that tells us, okay, something in our pipeline is wrong. And then we can just start narrowing things down. So yeah, adventures in debugging. Sometimes it's really frustrating, but then when you have a good process, and you find the bug, it's incredibly satisfying.

+ +

STEPHANIE: I like that you used a process that can be applied to many different problems, in this particular case, debugging a testing pipeline. Maybe not something that we do every day, but certainly, it comes up, and now we have tools to address those kinds of issues as well.

+ +

JOËL: So my week has been up and down with all of this debugging. What's been new in your world?

+ +

STEPHANIE: I've been doing some travel planning because I'm going to RubyKaigi in Japan.

+ +

JOËL: Whoa.

+ +

STEPHANIE: This is actually going to be my first international conference, so I'm really looking forward to that. I just have never been compelled to travel abroad to go to a tech conference. But I'm really looking forward to going to RubyKaigi because now I've been to the U.S.-based conferences a few times. And I'm excited to see how things are different at an international conference and specifically a RubyKaigi because, obviously, there's a lot of really cool Ruby work happening over there in Japan.

+ +

So I'm excited to learn about more of the open-source side of things of Ruby, what's new in the Ruby tooling world, and just what folks are thinking about in terms of the future of the language. That's not something I normally keep super up-to-date on. But I'm excited to be around people who do think and talk about these things a lot and maybe get some new insights into my own work.

+ +

JOËL: Do you find that you tend to keep up more with some of the frameworks like Rails rather than the underlying language itself?

+ +

STEPHANIE: Yeah, that's a good question. I do think because the framework changes a little more frequently, new releases are kind of more applicable to the work that I'm doing. Whereas language updates or upgrades are a little bit less top of mind for me because the point is that it doesn't have to change [laughs] all that much, and we can continue to work with things as expected and not be disrupted.

+ +

So it is definitely like a whole new world for me, but I'm really looking forward to it. I think it will be really interesting and just kind of a whole other space to explore that I haven't really because I've usually been focused on more of the web development and industry work side of things.

+ +

JOËL: What's a Ruby feature that either is coming out in the future or that came out in the last couple of releases that got you really excited?

+ +

STEPHANIE: I think the conversation about typing in Ruby is something that has been on my radar but has also been ebbing and flowing over time. And I did see a few talks at RubyKaigi this year that are going to talk about how to introduce gradual typing in Ruby. And now that it has been out for a little bit and people have been using it, how people are feeling about it, pros and cons, and kind of where they're going to take it or not take it from there.

+ +

JOËL: Have you done much TypeScript?

+ +

STEPHANIE: I have been working more in TypeScript recently but did spend most of my front-end work coding days in JavaScript. And so that transition itself was pretty challenging for me where I suddenly felt a language that I did know pretty well. I was having to be in that...in somewhat of a beginner's mindset again. Even just reading the code itself, there were just so many new things to be looking at in terms of the syntax. And it was a difficult but ultimately pretty rewarding experience because the way I thought about JavaScript afterwards was much more refined, I think.

+ +

JOËL: Types definitely, I think, change the way you think about code; at least, that's been my experience.

+ +

STEPHANIE: Yeah, absolutely. I haven't gotten the pleasure to work with types in Ruby just yet, but I've just heard different experiences. And I'm excited to see what experts have to say about it.

+ +

JOËL: That's the fun of going to a conference.

+ +

STEPHANIE: Absolutely. So yeah, if any listeners are also headed to RubyKaigi, yeah, look out for me.

+ +

JOËL: I was recently having a conversation with someone about the fact that a lot of languages provide ways to sort of embed many languages within them. So the Lisp family of languages are really big into macros and metaprogramming. Some other languages are big into giving you the ability to build your own ASTs or have really strong parsing capabilities so that you can produce your own, again, mini-language.

+ +

And Ruby does this as well. It's pretty popular among the Ruby community to build DSLs, Domain-Specific Languages using some of Ruby's built-in abilities. But it seems to be a sort of universal need or at the very least a universal desire among programmers. Have you ever found yourself as a code author wanting to embed a sort of smaller language within your application?

+ +

STEPHANIE: I don't think I have, to be honest. It's a very interesting question. Because I think the motivation to build your own mini-language using Ruby would have to be you'd have to have a really good reason for it, and in my experience, I haven't quite encountered that yet. Because, yeah, it seems like a lot of upfront work, a lot of overhead to introduce something like that, especially if it's not necessarily either a really, really particular domain that others might find a use for, or it just doesn't end up seeming worthwhile if I can just write regular, old Ruby code.

+ +

JOËL: I think you're not alone. I think the Ruby community has been kind of a bit of a pendulum here where several years ago, everything that could be made into a DSL was. Now the pendulum kind of has been swinging the other way. And we see DSLs, but they're not quite as frequent. For those who maybe have not experienced a DSL or aren't quite familiar with the concept, how would you describe the idea?

+ +

STEPHANIE: I think I would describe domain-specific languages as a bit of a mini-language that is created for a very particular problem space in mind to make development for that domain easier. Oftentimes, I've also kind of seen people describe the benefit of DSLs as being able to read that language as if it were plain English.

+ +

And so, in my head, I have kind of, at least in the Ruby world, right? We see that a lot in different gems. RSpec, for example, has its own internal DSL, and many people really enjoy it because it took the domain of testing. And the way you write it kind of is how you might read or understand it in English. And so it's a bit easier to talk about what you're expecting in your tests.

+ +

JOËL: Yeah, it's so high-level and minimal and domain-specific that it almost stops feeling like it's a programming language and can almost feel like it's a high-level configuration for this very particular domain, sometimes even to the point where the idea is that a non-programmer could read it and understand what's going on.

+ +

STEPHANIE: I think RSpec is actually one of the first Ruby DSLs that you might encounter when you're learning Ruby for the first time. And I've definitely seen developers who are new to Ruby, you know, they're writing code, and they're like, okay, I'm ready to write a test now. And the project uses RSpec because that's what most of us use in our Rails applications. And then they see, like you said, almost a configuration language, and they are really confused. They're not really sure what they're reading. They struggle with the syntax a lot. And it ends up being a point of frustration when they're first starting out if they're not just copying and pasting other existing RSpec tests. I'm curious if you've seen that before.

+ +

JOËL: I've definitely seen that. And it's a little bit ironic because oftentimes, an argument for DSL is that it makes things simpler that you don't even have to know Ruby; you can just write it. It's simpler. It's easier to write. It's easier to understand. And to a certain extent, maybe that's true. But for someone who does know Ruby and doesn't know your particular little domain language, now they're encountering something that they don't know. And they're having to learn it, and they're having to struggle with it. And it might behave a little bit weirdly compared to how Ruby normally works. And so sometimes it doesn't make it easier for adoption. But it does look really good in a README.

+ +

STEPHANIE: That's totally fair. I think the other thing that's interesting about RSpec is that a lot of it is really just stylistic. I actually read a blog post by Jason Swett and the headline of it was "Mystified by RSpec's DSL? Some parentheses can add clarity." And he basically goes on to tell us that really RSpec is just leaning on some of Ruby's syntactic sugar of omitting parentheses for method calls. And if you just add the parentheses back in your it blocks or your describes, it can read a lot more like regular Ruby. And you might have a better time understanding what's going on when you realize that we're just passing our descriptors as arguments along with some blocks.

+ +

JOËL: That's ironic given that oftentimes, the goal of these is to make it look like not Ruby.

+ +

STEPHANIE: I agree; it is ironic. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: I think another drawback that I've seen with DSLs is that they oftentimes are more limited in their capabilities. So if the designer of the gem didn't explicitly think of your use case, then oftentimes, it can be really hard to extend or to support edge cases that are not specifically designed for that language in the way that plain Ruby is often much more flexible.

+ +

STEPHANIE: Yeah, that's really interesting because when a gem does have some kind of DSL, a lot of effort probably went into making that the main interface that you would work with or you would use. And when that isn't working for your use case, the design of the underlying objects may or may not be helpful for the changes that you want to make.

+ +

JOËL: I think it's interesting that you mentioned the underlying objects because those are often sort of not meant for public consumption when you're building a gem that's DSL forward. I think, in many cases, my ideal gem would make those underlying objects the primary interface and then maybe offer DSL as a kind of nice-to-have layer on top for those situations that maybe aren't as complex where writing things in the domain language might actually be quite nice. But keeping those underlying objects as the interface, it's nice to use and well-documented for the majority of people.

+ +

STEPHANIE: Yeah, I like that too because then you can get the best of both worlds. So speaking of trying to make a DSL work for you, have you ever experienced having to kind of work around the DSL to get the functionality you were hoping to achieve?

+ +

JOËL: So I think we're talking about the idea of having both a DSL and the underlying objects. And RSpec is a great example of this with their custom matchers. RSpec itself is a DSL, but then they also offer a DSL to allow you to create custom matchers. And it's not super well documented. I always forget how to define them, and so I oftentimes don't bother. It's just kind of too much of a pain for something that doesn't always provide that much value. But if it were easy, I would probably do it more. Eventually, I realized that you could use just regular Ruby objects as custom matchers. And they just seemed to respond to certain methods, just regular old objects and polymorphism.

+ +

And all of a sudden, now I'm back into all of the tools and mechanisms that I am familiar with, like the back of my hand. I can write objects all day. I can TDD them. I can apply any patterns that I want to if I'm doing something really complicated. I can extract helpers. All of that works really well with the knowledge that I already have without having to sink a lot of time into trying to learn the built-in DSL.

+ +

So, for the most part, now, when I define custom matchers, I'll often jump directly to creating a regular object and making it conform to the matcher interface rather than relying on the DSL for that. So once we go back to the test, now we're back in DSL land. Now we're no longer talking in terms of objects so much. We'll have some nice methods and they will all kind of read like English. So to pull a recent example that I worked on, I might say something like expect this policy object method to conform to this truth table.

+ +

STEPHANIE: That's a really interesting example. It actually kind of sounds like it hits the sweet spot of what you were describing earlier in the sense that it has a really nice DSL, but also, you can create your own objects, and that has an interface that you can implement. And yes, have your cake and eat it too. [laughs] But the idea that then you're kind of converting it back to the DSL because that is just what we know, and it has become so normalized.

+ +

I was talking earlier about okay; when is a DSL worthwhile? When is the use case a good reason to implement it? And especially for gems that I think that are really popular that we as a Ruby community have collectively used most of the time on our projects because we have oftentimes a lot of the same problems that we're solving. It seems like this has become its own shared language, right?

+ +

JOËL: Yeah, there are definitely some DSLs that we all end up learning because they're just so prominent in the Ruby community, even Rails itself ships with several built-in DSLs.

+ +

STEPHANIE: Yeah, absolutely. FactoryBot is another one, too. It is a gem by thoughtbot. And actually, in preparation to talk about DSLs with you today, I scoured our blog and found a really great blog post, "Writing a Domain-Specific Language in Ruby" by Gabe Berke-Williams. And it is basically like, here's how to write something like FactoryBot and creating your own little mini Ruby DSL for something that would be very similar to what FactoryBot does for fixtures.

+ +

JOËL: That's a great resource, and we'll make sure to link that in the show notes. We've been talking about some of the limitations of DSLs or some aspects of them maybe that we personally don't like. What are maybe examples of DSLs that you do enjoy working with?

+ +

STEPHANIE: Yeah, I have an example for this one. I really enjoy using Capybara's DSL for acceptance testing. I did have to go down the route of writing some custom selectors for...I just had some HTML elements within kind of a complicated table and was trying to figure out how to write some selectors so that I could write the test as if it were in, you know, quote, unquote, "plain English" like, within this table, expect some value.

+ +

And that was an interesting journey. But I think that it really helped me have a better understanding of accessibility of just the underlying building blocks of the page that I was working with. And, yeah, I really appreciate being able to read those tests from a user perspective and kind of know exactly what they're doing when they're interacting with this virtual browser without having to run it in headful mode and see it for myself.

+ +

JOËL: It's always great when a DSL can give you that experience of abstracting enough to where it makes the code delightful to work with while also not having too high a cost to learn or being too restrictive in what it allows you to do. Would you make a difference between something that's a DSL versus maybe just code that's written at a higher level of abstraction?

+ +

So maybe to get back to your example with Capybara, it's really nice to have these nice custom matchers and all of these things to work with HTML pages. If I'm writing, let's say, a helper method at the bottom of a test, I don't think that feels quite like it's a DSL yet. But it's definitely a higher level than specifying CSS selectors. So would you make a difference between those two things?

+ +

STEPHANIE: That's a good question. I think it's one of those you know it when you see it kind of questions because it just depends on the amount of abstraction, like you mentioned, and maybe even metaprogramming. That takes something from the core language to morph into what you could qualify as a separate language. What do you think about this?

+ +

JOËL: Yeah, part of me almost wonders if this exists kind of on a continuum, and the boundary might be a little bit fuzzy. I think there might be some other qualifications that come with it as well. Even though DSLs are typically higher-level helpers, it's usually more than just that. There are also sort of slightly different semantics in the way that you would tend to use them to the point where while they may be just Ruby methods, we don't use them like Ruby methods, and even to the point that we don't think of them as Ruby methods.

+ +

To go back to that article you mentioned from Jason, where just reminding people, hey, if you put params on this, all of a sudden, it helps you remember, oh, it's just a Ruby method instead of being like, oh, this is a language keyword or something.

+ +

STEPHANIE: Yeah, I wonder if there's also something to the idea of domain specificity where it should be self-service within the domain that you're working. And then it has limitations once you are trying to do something separate from the domain.

+ +

JOËL: Right, it's an element of focus to this. And I think it's probably also a language is not just one helper; it's a collection typically. So it's probably a series of high-level helpers, potentially. They might not be methods, even though that is ultimately one of the primary interfaces we use to run code in Ruby. So it's a collection of methods that are high-level, but the collection itself is focused. And oftentimes, they're meant to be used in a way where it's not just a traditional method call.

+ +

STEPHANIE: Right. There's some amount of you bringing to the table your own use case in how you use those methods.

+ +

JOËL: Yeah, so it might be mimicking a language keyword. It might be mimicking the idea of a configuration. We see that a little bit with ActiveRecord and some of the, let's say, the association and validation APIs. Those kind of feel like, yes, they're embedded in a class, but they feel like either keywords or even just straight-up configuration where you set key-value pairs of things to configure how a particular class is going to work.

+ +

STEPHANIE: Yeah, that's true for a lot of things in Rails, too, if we're talking about routes and initializers as well.

+ +

JOËL: So I've complained about some things I don't like about DSLs. I really like the routing DSL in Rails.

+ +

STEPHANIE: Why is that?

+ +

JOËL: I think it's very compact and readable. And that's an element that's really nice about DSLs is that it can make things feel very readable and, oftentimes, we read code more often than we write it. And routes have...I was going to say fewer edge cases, but I have seen some really gnarly route files that are pretty awful to work with, especially if you're mostly writing RESTful controllers, and I would recommend that people do. It's really nice to just be able to skim through a route file and be like, oh, these are the resources in my app and the actions I can do on each resource. And here are the ones that are nested.

+ +

STEPHANIE: Yeah, it almost sounds like a DSL can provide guardrails towards the recommended way of tackling that particular domain. The routes DSL really discourages you from doing anything too complicated because they are encouraging you to follow the Rails convention. And so I think that goes back to the specificity piece of if you've written a DSL, it's because you've thought very deeply about this particular domain and how common problems show up and how you would want people to be empowered by the language rather than inhibited by it.

+ +

JOËL: I think, thinking more about that, the word that comes to mind is declarative. When you read code that's written with DSLs, typically, it's very declarative. It's more just describing a thing as opposed to either procedural, a series of commands to do, or even OO, where you're composing objects and sending messages to each other. And so problems that lend themselves to being implemented through more descriptive and declarative approaches probably are really good candidates for a DSL.

+ +

STEPHANIE: Yeah, I like that a lot because when we talk about domains, we're not necessarily talking about a business domain, which is kind of the other way that some folks think about that word. We're talking about a problem space. And the idea of the language being declarative to describe the problem space makes a lot of sense to me because you want it to be flexible enough for different use cases but all within the idea of testing or browser navigation or whatever.

+ +

JOËL: Yeah. I feel like there's a lot of... there are probably more problems that can be converted to declarative solutions than might initially kind of strike you. Sometimes the problem isn't quite as bounded. And so when you want customizations that are not supported by your DSL, then it kind of falls apart. So I think a classic situation that might feel like something declarative is authorization.

+ +

Authorization are a series of rules for who can access what, and it would seem like this is a great case for a DSL. Wouldn't it be great to have just one file you can just kind of skim, and we can just see all of the access rules? Access rules that are basically asking to be done declaratively. And we have gems like that. The original CanCan gem and then the successor CanCanCan are trying to follow that approach. Have you used either of those gems?

+ +

STEPHANIE: I did use the CanCanCan gem a while ago.

+ +

JOËL: What was your experience with that style of authorization?

+ +

STEPHANIE: It has been a while but I do remember having to check that original file of like all the different authorizations kind of repeatedly coming back to it to remember, okay, for this rule, what should be allowed to happen here?

+ +

JOËL: So I think that's definitely one of the benefits is that you have all of your rules stored in one place, and you can kind of scan through the list. My experience, though, is that in practice, it often kind of balloons up and has all of these edge cases in it. And in some earlier versions, I don't know if that's still a problem today, it could even be difficult to accomplish certain things.

+ +

If you're going to say that access to this particular object depends not on properties of that object itself but on some custom join or association or something like that, that could be really clunky to do or sometimes impossible depending on how esoteric it is or if there's some really complex custom logic to do. And once you're doing something like that, you don't really want to have that logic in your...in this case, it would be the abilities file but inside because that's not really something you express via the DSL anymore. Now you're dropping into OO or procedural world.

+ +

STEPHANIE: Right. It seems a bit far removed from where we do actually care about the different abilities, especially for one-off cases.

+ +

JOËL: That is interesting because I feel like there's a bit of a read-versus write-situation happening there as well. It's particularly nice to have, I think, everything in one abilities file for reading and for auditing. I've definitely been in code where there's like three or four ways to authorize, and they're all being used inconsistently, and that's not nice at all.

+ +

On the other hand, it can be hard with DSL sometimes to customize or to go beyond the rules that are built in. In the case of authorization, you've effectively built a little mini-rules engine. And if you don't have a good way for people to add custom rules without just embedding procedural code into your abilities file, it's going to quickly get out of hand.

+ +

STEPHANIE: Yeah, that makes sense. On the topic of authorization, you did mention an example earlier when you were writing a policy object.

+ +

JOËL: I've generally found that that's been my go-to pattern for authorization. I enjoy the Pundit gem that provides some kind of light scaffolding around working with policy objects, but it's a general pattern, and you can absolutely write your own. You don't need a gem for that. Now we're definitely not in the DSL world. We're not doing this declaratively. We're leaning very heavily on OO and saying we're just going to create objects. They talk to each other. They can do anything that any Ruby object can do and as simple or as complex as they need to be.

+ +

So you have the full power of Ruby and all the patterns that you're used to using. The downside is it is a little bit harder to read and to kind of just audit what's happening in terms of permission because there's no high-level overview anymore. Now you've just got to look through a bunch of classes. So maybe that's the trade-off, flexibility, extensibility versus more declarative style and easy overview.

+ +

STEPHANIE: That makes a lot of sense because we were talking earlier about guardrails. And because those boundaries do exist, that might not give us the flexibility we want compared to just writing regular Ruby objects. But yeah, we do get the benefit of, like you said, auditing, and at least if we don't try to do some really gnarly, custom stuff, [laughs] something that's easier to read and comprehend.

+ +

JOËL: And, again, maybe that's where in the best of both worlds situation, you say, hey, I'm creating some form of rules engine, whether it's for describing routes, or authorization, permissions, or users can build custom business rules for a product or something like that. And it's all object-based under the hood. And then, we provide a DSL to make it nice to work with these rules.

+ +

If a programmer using our gem wants to write a custom rule that just really extends what the ones we shipped can do, allow them to do that via the object API. We have all the objects available to you that underlie the DSL. Add more rules yourself. And then maybe those can be plugged back into the DSL like we saw with the RSpec and custom matchers. Or maybe you have to say, okay, if I have a custom rule object, now I have to just stay in the object space. And I think both of those solutions are okay. But now you've sort of kept those two worlds separate and still allowed people to extend.

+ +

STEPHANIE: I like that as contributing to the language because language is never static. It changes over time. And that's a way that people can continue to evolve a language that may have been originally written at a certain time and place.

+ +

JOËL: Moving on from DSLs, we got some listener feedback recently from James, who was listening to our episode on discrete math. And James really appreciated the episode and wanted to share a resource with us. This is the book "Discrete Math and Functional Programming" by Thomas VanDrunen. It's an introduction to discrete math as a theoretical concept taught side by side with the very practical aspect of learning to use the language standard ML, and both of those factor into each other.

+ +

So you're kind of learning a little bit of theory and some practice, at the same time, getting to implement some discrete math concepts in standard ML to get a feel for them. Yeah, I've not read this book, but I love the concept of pairing a theoretical piece and a practical piece. So I'll drop a link to it in the show notes as well. Thank you, James.

+ +

STEPHANIE: Yeah, thanks, James. And I guess this is just a little reminder that if our listeners have any feedback or questions they want to write in about, you can reach us at hosts@bikeshed.fm.

+ +

JOËL: On that note. Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël has been integrating a third-party platform into a testing pipeline...and it has not been going well. Because it's not something she usually keeps up-to-date with, Stephanie is excited to learn about more of the open-source side of things in Ruby, what's new in the Ruby tooling world, and what folks are thinking about regarding the future of the language.

+ +

Today's topic is inspired by an internal thoughtbot Slack thread about writing a custom matcher for Rspec. Stephanie and Joël contrast DSLs vs. Object APIs and also talk about:

+ +
    +
  • CanCanCan vs Pundit
    • +
  • RSpec DSL
    • +
  • When is a DSL helpful?
    • +
  • Why not use both DSLs & Object APIs?
    • +
  • Extensibility
    • +
  • When does a DSL become a framework?
    • +
+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been integrating a third-party platform into our testing pipeline for my client. It has not been going well. We've been struggling a little bit, mostly just because tests just kind of crash. Our testing pipeline is pretty complex. It's a lot of one script, some environment variables, does a few things, shells out to another script, which is in a different language. Does a few more things, shells out to another script, maybe calls out to rake, calls out to a shell script. There are four or five of these in a chain, and it's a bit of a mess.

+ +

Somewhere along in there, something is not compatible with this third-party service that we're trying to integrate with. I was pairing this week with a colleague. And we were able to reproduce a situation where we were able to get a failure under some conditions and a success under other conditions. So these are basically, if we run the whole chain of scripts that call each other from the beginning, we know we get a failure. And if we skipped entirely the chain of scripts that set up things and then just manually try to invoke a third-party service, that works.

+ +

And so now we know that there's something in between that's incompatible, and now it's just about narrowing things down. There are a few different approaches we could take. We could try to sort of work our way forward. We know a known point where it breaks and then just try to start the chain one step further and see where it fails. We could try to get fancy and do a binary search, like split it in half and then half and half again.

+ +

We ended up doing it the other way, where we started at the end. We had our known good point and then just stepping one step back and saying, okay, now we introduce the last script in the chain. Does that work? Okay, that pass is great. Let's go one step further; two scripts up in the chain. And at some point, we find, okay, here's the one script that fails. Now, what is it within this script? And it was a really fun debugging session where we were just narrowing things down until we found the source of the bug.

+ +

STEPHANIE: Wow, that sounds pretty complicated. It just seems like there are so many layers going on. And it was really challenging to pinpoint where the source of the issue was.

+ +

JOËL: Definitely. I think all the layers made it really complicated. But having a process that we could follow and then kind of narrowing it down made it almost mechanical to figure out where the bug was once we got to a point where we had a known good point and a known bad point.

+ +

STEPHANIE: Yeah, that makes sense. Kind of sounds like if you are using git bisect or something like that to narrow down the scope of where the issue could be. I'm curious because this is like a bunch of shell scripts and rake tasks or commands or whatever. What would have made this debugging process easier?

+ +

JOËL: I think having fewer scripts in this chain.

+ +

STEPHANIE: [laughs] That's fair.

+ +

JOËL: We don't need so many scripts that call out to each other in different languages trying to share data via environment variables. So we've got a bit of a Rube Goldberg machine, and we're trying to patch in yet another piece in there.

+ +

STEPHANIE: Yeah, that's really tough. I was curious if there was, I don't know, any logging or any other clues that you were getting along the way because I know from experience how painful it is to debug that kind of code.

+ +

JOËL: It's interesting because I feel like normally logging is something that's really useful. In this particular case, we run into an exception at some point. So it's more of under what conditions does the exception happen? The important thing was to find that there is a point where it breaks, and there's a point where it doesn't, and realizing that if we ran some of these commands just directly without going through the whole pipeline, that things did work and that we were not triggering that exception.

+ +

So all of a sudden, now that tells us, okay, something in our pipeline is wrong. And then we can just start narrowing things down. So yeah, adventures in debugging. Sometimes it's really frustrating, but then when you have a good process, and you find the bug, it's incredibly satisfying.

+ +

STEPHANIE: I like that you used a process that can be applied to many different problems, in this particular case, debugging a testing pipeline. Maybe not something that we do every day, but certainly, it comes up, and now we have tools to address those kinds of issues as well.

+ +

JOËL: So my week has been up and down with all of this debugging. What's been new in your world?

+ +

STEPHANIE: I've been doing some travel planning because I'm going to RubyKaigi in Japan.

+ +

JOËL: Whoa.

+ +

STEPHANIE: This is actually going to be my first international conference, so I'm really looking forward to that. I just have never been compelled to travel abroad to go to a tech conference. But I'm really looking forward to going to RubyKaigi because now I've been to the U.S.-based conferences a few times. And I'm excited to see how things are different at an international conference and specifically a RubyKaigi because, obviously, there's a lot of really cool Ruby work happening over there in Japan.

+ +

So I'm excited to learn about more of the open-source side of things of Ruby, what's new in the Ruby tooling world, and just what folks are thinking about in terms of the future of the language. That's not something I normally keep super up-to-date on. But I'm excited to be around people who do think and talk about these things a lot and maybe get some new insights into my own work.

+ +

JOËL: Do you find that you tend to keep up more with some of the frameworks like Rails rather than the underlying language itself?

+ +

STEPHANIE: Yeah, that's a good question. I do think because the framework changes a little more frequently, new releases are kind of more applicable to the work that I'm doing. Whereas language updates or upgrades are a little bit less top of mind for me because the point is that it doesn't have to change [laughs] all that much, and we can continue to work with things as expected and not be disrupted.

+ +

So it is definitely like a whole new world for me, but I'm really looking forward to it. I think it will be really interesting and just kind of a whole other space to explore that I haven't really because I've usually been focused on more of the web development and industry work side of things.

+ +

JOËL: What's a Ruby feature that either is coming out in the future or that came out in the last couple of releases that got you really excited?

+ +

STEPHANIE: I think the conversation about typing in Ruby is something that has been on my radar but has also been ebbing and flowing over time. And I did see a few talks at RubyKaigi this year that are going to talk about how to introduce gradual typing in Ruby. And now that it has been out for a little bit and people have been using it, how people are feeling about it, pros and cons, and kind of where they're going to take it or not take it from there.

+ +

JOËL: Have you done much TypeScript?

+ +

STEPHANIE: I have been working more in TypeScript recently but did spend most of my front-end work coding days in JavaScript. And so that transition itself was pretty challenging for me where I suddenly felt a language that I did know pretty well. I was having to be in that...in somewhat of a beginner's mindset again. Even just reading the code itself, there were just so many new things to be looking at in terms of the syntax. And it was a difficult but ultimately pretty rewarding experience because the way I thought about JavaScript afterwards was much more refined, I think.

+ +

JOËL: Types definitely, I think, change the way you think about code; at least, that's been my experience.

+ +

STEPHANIE: Yeah, absolutely. I haven't gotten the pleasure to work with types in Ruby just yet, but I've just heard different experiences. And I'm excited to see what experts have to say about it.

+ +

JOËL: That's the fun of going to a conference.

+ +

STEPHANIE: Absolutely. So yeah, if any listeners are also headed to RubyKaigi, yeah, look out for me.

+ +

JOËL: I was recently having a conversation with someone about the fact that a lot of languages provide ways to sort of embed many languages within them. So the Lisp family of languages are really big into macros and metaprogramming. Some other languages are big into giving you the ability to build your own ASTs or have really strong parsing capabilities so that you can produce your own, again, mini-language.

+ +

And Ruby does this as well. It's pretty popular among the Ruby community to build DSLs, Domain-Specific Languages using some of Ruby's built-in abilities. But it seems to be a sort of universal need or at the very least a universal desire among programmers. Have you ever found yourself as a code author wanting to embed a sort of smaller language within your application?

+ +

STEPHANIE: I don't think I have, to be honest. It's a very interesting question. Because I think the motivation to build your own mini-language using Ruby would have to be you'd have to have a really good reason for it, and in my experience, I haven't quite encountered that yet. Because, yeah, it seems like a lot of upfront work, a lot of overhead to introduce something like that, especially if it's not necessarily either a really, really particular domain that others might find a use for, or it just doesn't end up seeming worthwhile if I can just write regular, old Ruby code.

+ +

JOËL: I think you're not alone. I think the Ruby community has been kind of a bit of a pendulum here where several years ago, everything that could be made into a DSL was. Now the pendulum kind of has been swinging the other way. And we see DSLs, but they're not quite as frequent. For those who maybe have not experienced a DSL or aren't quite familiar with the concept, how would you describe the idea?

+ +

STEPHANIE: I think I would describe domain-specific languages as a bit of a mini-language that is created for a very particular problem space in mind to make development for that domain easier. Oftentimes, I've also kind of seen people describe the benefit of DSLs as being able to read that language as if it were plain English.

+ +

And so, in my head, I have kind of, at least in the Ruby world, right? We see that a lot in different gems. RSpec, for example, has its own internal DSL, and many people really enjoy it because it took the domain of testing. And the way you write it kind of is how you might read or understand it in English. And so it's a bit easier to talk about what you're expecting in your tests.

+ +

JOËL: Yeah, it's so high-level and minimal and domain-specific that it almost stops feeling like it's a programming language and can almost feel like it's a high-level configuration for this very particular domain, sometimes even to the point where the idea is that a non-programmer could read it and understand what's going on.

+ +

STEPHANIE: I think RSpec is actually one of the first Ruby DSLs that you might encounter when you're learning Ruby for the first time. And I've definitely seen developers who are new to Ruby, you know, they're writing code, and they're like, okay, I'm ready to write a test now. And the project uses RSpec because that's what most of us use in our Rails applications. And then they see, like you said, almost a configuration language, and they are really confused. They're not really sure what they're reading. They struggle with the syntax a lot. And it ends up being a point of frustration when they're first starting out if they're not just copying and pasting other existing RSpec tests. I'm curious if you've seen that before.

+ +

JOËL: I've definitely seen that. And it's a little bit ironic because oftentimes, an argument for DSL is that it makes things simpler that you don't even have to know Ruby; you can just write it. It's simpler. It's easier to write. It's easier to understand. And to a certain extent, maybe that's true. But for someone who does know Ruby and doesn't know your particular little domain language, now they're encountering something that they don't know. And they're having to learn it, and they're having to struggle with it. And it might behave a little bit weirdly compared to how Ruby normally works. And so sometimes it doesn't make it easier for adoption. But it does look really good in a README.

+ +

STEPHANIE: That's totally fair. I think the other thing that's interesting about RSpec is that a lot of it is really just stylistic. I actually read a blog post by Jason Swett and the headline of it was "Mystified by RSpec's DSL? Some parentheses can add clarity." And he basically goes on to tell us that really RSpec is just leaning on some of Ruby's syntactic sugar of omitting parentheses for method calls. And if you just add the parentheses back in your it blocks or your describes, it can read a lot more like regular Ruby. And you might have a better time understanding what's going on when you realize that we're just passing our descriptors as arguments along with some blocks.

+ +

JOËL: That's ironic given that oftentimes, the goal of these is to make it look like not Ruby.

+ +

STEPHANIE: I agree; it is ironic. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: I think another drawback that I've seen with DSLs is that they oftentimes are more limited in their capabilities. So if the designer of the gem didn't explicitly think of your use case, then oftentimes, it can be really hard to extend or to support edge cases that are not specifically designed for that language in the way that plain Ruby is often much more flexible.

+ +

STEPHANIE: Yeah, that's really interesting because when a gem does have some kind of DSL, a lot of effort probably went into making that the main interface that you would work with or you would use. And when that isn't working for your use case, the design of the underlying objects may or may not be helpful for the changes that you want to make.

+ +

JOËL: I think it's interesting that you mentioned the underlying objects because those are often sort of not meant for public consumption when you're building a gem that's DSL forward. I think, in many cases, my ideal gem would make those underlying objects the primary interface and then maybe offer DSL as a kind of nice-to-have layer on top for those situations that maybe aren't as complex where writing things in the domain language might actually be quite nice. But keeping those underlying objects as the interface, it's nice to use and well-documented for the majority of people.

+ +

STEPHANIE: Yeah, I like that too because then you can get the best of both worlds. So speaking of trying to make a DSL work for you, have you ever experienced having to kind of work around the DSL to get the functionality you were hoping to achieve?

+ +

JOËL: So I think we're talking about the idea of having both a DSL and the underlying objects. And RSpec is a great example of this with their custom matchers. RSpec itself is a DSL, but then they also offer a DSL to allow you to create custom matchers. And it's not super well documented. I always forget how to define them, and so I oftentimes don't bother. It's just kind of too much of a pain for something that doesn't always provide that much value. But if it were easy, I would probably do it more. Eventually, I realized that you could use just regular Ruby objects as custom matchers. And they just seemed to respond to certain methods, just regular old objects and polymorphism.

+ +

And all of a sudden, now I'm back into all of the tools and mechanisms that I am familiar with, like the back of my hand. I can write objects all day. I can TDD them. I can apply any patterns that I want to if I'm doing something really complicated. I can extract helpers. All of that works really well with the knowledge that I already have without having to sink a lot of time into trying to learn the built-in DSL.

+ +

So, for the most part, now, when I define custom matchers, I'll often jump directly to creating a regular object and making it conform to the matcher interface rather than relying on the DSL for that. So once we go back to the test, now we're back in DSL land. Now we're no longer talking in terms of objects so much. We'll have some nice methods and they will all kind of read like English. So to pull a recent example that I worked on, I might say something like expect this policy object method to conform to this truth table.

+ +

STEPHANIE: That's a really interesting example. It actually kind of sounds like it hits the sweet spot of what you were describing earlier in the sense that it has a really nice DSL, but also, you can create your own objects, and that has an interface that you can implement. And yes, have your cake and eat it too. [laughs] But the idea that then you're kind of converting it back to the DSL because that is just what we know, and it has become so normalized.

+ +

I was talking earlier about okay; when is a DSL worthwhile? When is the use case a good reason to implement it? And especially for gems that I think that are really popular that we as a Ruby community have collectively used most of the time on our projects because we have oftentimes a lot of the same problems that we're solving. It seems like this has become its own shared language, right?

+ +

JOËL: Yeah, there are definitely some DSLs that we all end up learning because they're just so prominent in the Ruby community, even Rails itself ships with several built-in DSLs.

+ +

STEPHANIE: Yeah, absolutely. FactoryBot is another one, too. It is a gem by thoughtbot. And actually, in preparation to talk about DSLs with you today, I scoured our blog and found a really great blog post, "Writing a Domain-Specific Language in Ruby" by Gabe Berke-Williams. And it is basically like, here's how to write something like FactoryBot and creating your own little mini Ruby DSL for something that would be very similar to what FactoryBot does for fixtures.

+ +

JOËL: That's a great resource, and we'll make sure to link that in the show notes. We've been talking about some of the limitations of DSLs or some aspects of them maybe that we personally don't like. What are maybe examples of DSLs that you do enjoy working with?

+ +

STEPHANIE: Yeah, I have an example for this one. I really enjoy using Capybara's DSL for acceptance testing. I did have to go down the route of writing some custom selectors for...I just had some HTML elements within kind of a complicated table and was trying to figure out how to write some selectors so that I could write the test as if it were in, you know, quote, unquote, "plain English" like, within this table, expect some value.

+ +

And that was an interesting journey. But I think that it really helped me have a better understanding of accessibility of just the underlying building blocks of the page that I was working with. And, yeah, I really appreciate being able to read those tests from a user perspective and kind of know exactly what they're doing when they're interacting with this virtual browser without having to run it in headful mode and see it for myself.

+ +

JOËL: It's always great when a DSL can give you that experience of abstracting enough to where it makes the code delightful to work with while also not having too high a cost to learn or being too restrictive in what it allows you to do. Would you make a difference between something that's a DSL versus maybe just code that's written at a higher level of abstraction?

+ +

So maybe to get back to your example with Capybara, it's really nice to have these nice custom matchers and all of these things to work with HTML pages. If I'm writing, let's say, a helper method at the bottom of a test, I don't think that feels quite like it's a DSL yet. But it's definitely a higher level than specifying CSS selectors. So would you make a difference between those two things?

+ +

STEPHANIE: That's a good question. I think it's one of those you know it when you see it kind of questions because it just depends on the amount of abstraction, like you mentioned, and maybe even metaprogramming. That takes something from the core language to morph into what you could qualify as a separate language. What do you think about this?

+ +

JOËL: Yeah, part of me almost wonders if this exists kind of on a continuum, and the boundary might be a little bit fuzzy. I think there might be some other qualifications that come with it as well. Even though DSLs are typically higher-level helpers, it's usually more than just that. There are also sort of slightly different semantics in the way that you would tend to use them to the point where while they may be just Ruby methods, we don't use them like Ruby methods, and even to the point that we don't think of them as Ruby methods.

+ +

To go back to that article you mentioned from Jason, where just reminding people, hey, if you put params on this, all of a sudden, it helps you remember, oh, it's just a Ruby method instead of being like, oh, this is a language keyword or something.

+ +

STEPHANIE: Yeah, I wonder if there's also something to the idea of domain specificity where it should be self-service within the domain that you're working. And then it has limitations once you are trying to do something separate from the domain.

+ +

JOËL: Right, it's an element of focus to this. And I think it's probably also a language is not just one helper; it's a collection typically. So it's probably a series of high-level helpers, potentially. They might not be methods, even though that is ultimately one of the primary interfaces we use to run code in Ruby. So it's a collection of methods that are high-level, but the collection itself is focused. And oftentimes, they're meant to be used in a way where it's not just a traditional method call.

+ +

STEPHANIE: Right. There's some amount of you bringing to the table your own use case in how you use those methods.

+ +

JOËL: Yeah, so it might be mimicking a language keyword. It might be mimicking the idea of a configuration. We see that a little bit with ActiveRecord and some of the, let's say, the association and validation APIs. Those kind of feel like, yes, they're embedded in a class, but they feel like either keywords or even just straight-up configuration where you set key-value pairs of things to configure how a particular class is going to work.

+ +

STEPHANIE: Yeah, that's true for a lot of things in Rails, too, if we're talking about routes and initializers as well.

+ +

JOËL: So I've complained about some things I don't like about DSLs. I really like the routing DSL in Rails.

+ +

STEPHANIE: Why is that?

+ +

JOËL: I think it's very compact and readable. And that's an element that's really nice about DSLs is that it can make things feel very readable and, oftentimes, we read code more often than we write it. And routes have...I was going to say fewer edge cases, but I have seen some really gnarly route files that are pretty awful to work with, especially if you're mostly writing RESTful controllers, and I would recommend that people do. It's really nice to just be able to skim through a route file and be like, oh, these are the resources in my app and the actions I can do on each resource. And here are the ones that are nested.

+ +

STEPHANIE: Yeah, it almost sounds like a DSL can provide guardrails towards the recommended way of tackling that particular domain. The routes DSL really discourages you from doing anything too complicated because they are encouraging you to follow the Rails convention. And so I think that goes back to the specificity piece of if you've written a DSL, it's because you've thought very deeply about this particular domain and how common problems show up and how you would want people to be empowered by the language rather than inhibited by it.

+ +

JOËL: I think, thinking more about that, the word that comes to mind is declarative. When you read code that's written with DSLs, typically, it's very declarative. It's more just describing a thing as opposed to either procedural, a series of commands to do, or even OO, where you're composing objects and sending messages to each other. And so problems that lend themselves to being implemented through more descriptive and declarative approaches probably are really good candidates for a DSL.

+ +

STEPHANIE: Yeah, I like that a lot because when we talk about domains, we're not necessarily talking about a business domain, which is kind of the other way that some folks think about that word. We're talking about a problem space. And the idea of the language being declarative to describe the problem space makes a lot of sense to me because you want it to be flexible enough for different use cases but all within the idea of testing or browser navigation or whatever.

+ +

JOËL: Yeah. I feel like there's a lot of... there are probably more problems that can be converted to declarative solutions than might initially kind of strike you. Sometimes the problem isn't quite as bounded. And so when you want customizations that are not supported by your DSL, then it kind of falls apart. So I think a classic situation that might feel like something declarative is authorization.

+ +

Authorization are a series of rules for who can access what, and it would seem like this is a great case for a DSL. Wouldn't it be great to have just one file you can just kind of skim, and we can just see all of the access rules? Access rules that are basically asking to be done declaratively. And we have gems like that. The original CanCan gem and then the successor CanCanCan are trying to follow that approach. Have you used either of those gems?

+ +

STEPHANIE: I did use the CanCanCan gem a while ago.

+ +

JOËL: What was your experience with that style of authorization?

+ +

STEPHANIE: It has been a while but I do remember having to check that original file of like all the different authorizations kind of repeatedly coming back to it to remember, okay, for this rule, what should be allowed to happen here?

+ +

JOËL: So I think that's definitely one of the benefits is that you have all of your rules stored in one place, and you can kind of scan through the list. My experience, though, is that in practice, it often kind of balloons up and has all of these edge cases in it. And in some earlier versions, I don't know if that's still a problem today, it could even be difficult to accomplish certain things.

+ +

If you're going to say that access to this particular object depends not on properties of that object itself but on some custom join or association or something like that, that could be really clunky to do or sometimes impossible depending on how esoteric it is or if there's some really complex custom logic to do. And once you're doing something like that, you don't really want to have that logic in your...in this case, it would be the abilities file but inside because that's not really something you express via the DSL anymore. Now you're dropping into OO or procedural world.

+ +

STEPHANIE: Right. It seems a bit far removed from where we do actually care about the different abilities, especially for one-off cases.

+ +

JOËL: That is interesting because I feel like there's a bit of a read-versus write-situation happening there as well. It's particularly nice to have, I think, everything in one abilities file for reading and for auditing. I've definitely been in code where there's like three or four ways to authorize, and they're all being used inconsistently, and that's not nice at all.

+ +

On the other hand, it can be hard with DSL sometimes to customize or to go beyond the rules that are built in. In the case of authorization, you've effectively built a little mini-rules engine. And if you don't have a good way for people to add custom rules without just embedding procedural code into your abilities file, it's going to quickly get out of hand.

+ +

STEPHANIE: Yeah, that makes sense. On the topic of authorization, you did mention an example earlier when you were writing a policy object.

+ +

JOËL: I've generally found that that's been my go-to pattern for authorization. I enjoy the Pundit gem that provides some kind of light scaffolding around working with policy objects, but it's a general pattern, and you can absolutely write your own. You don't need a gem for that. Now we're definitely not in the DSL world. We're not doing this declaratively. We're leaning very heavily on OO and saying we're just going to create objects. They talk to each other. They can do anything that any Ruby object can do and as simple or as complex as they need to be.

+ +

So you have the full power of Ruby and all the patterns that you're used to using. The downside is it is a little bit harder to read and to kind of just audit what's happening in terms of permission because there's no high-level overview anymore. Now you've just got to look through a bunch of classes. So maybe that's the trade-off, flexibility, extensibility versus more declarative style and easy overview.

+ +

STEPHANIE: That makes a lot of sense because we were talking earlier about guardrails. And because those boundaries do exist, that might not give us the flexibility we want compared to just writing regular Ruby objects. But yeah, we do get the benefit of, like you said, auditing, and at least if we don't try to do some really gnarly, custom stuff, [laughs] something that's easier to read and comprehend.

+ +

JOËL: And, again, maybe that's where in the best of both worlds situation, you say, hey, I'm creating some form of rules engine, whether it's for describing routes, or authorization, permissions, or users can build custom business rules for a product or something like that. And it's all object-based under the hood. And then, we provide a DSL to make it nice to work with these rules.

+ +

If a programmer using our gem wants to write a custom rule that just really extends what the ones we shipped can do, allow them to do that via the object API. We have all the objects available to you that underlie the DSL. Add more rules yourself. And then maybe those can be plugged back into the DSL like we saw with the RSpec and custom matchers. Or maybe you have to say, okay, if I have a custom rule object, now I have to just stay in the object space. And I think both of those solutions are okay. But now you've sort of kept those two worlds separate and still allowed people to extend.

+ +

STEPHANIE: I like that as contributing to the language because language is never static. It changes over time. And that's a way that people can continue to evolve a language that may have been originally written at a certain time and place.

+ +

JOËL: Moving on from DSLs, we got some listener feedback recently from James, who was listening to our episode on discrete math. And James really appreciated the episode and wanted to share a resource with us. This is the book "Discrete Math and Functional Programming" by Thomas VanDrunen. It's an introduction to discrete math as a theoretical concept taught side by side with the very practical aspect of learning to use the language standard ML, and both of those factor into each other.

+ +

So you're kind of learning a little bit of theory and some practice, at the same time, getting to implement some discrete math concepts in standard ML to get a feel for them. Yeah, I've not read this book, but I love the concept of pairing a theoretical piece and a practical piece. So I'll drop a link to it in the show notes as well. Thank you, James.

+ +

STEPHANIE: Yeah, thanks, James. And I guess this is just a little reminder that if our listeners have any feedback or questions they want to write in about, you can reach us at hosts@bikeshed.fm.

+ +

JOËL: On that note. Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NqZ7sSnI + + ]]> + + Joël Quenneville + Stephanie Minn + + + 381: To TDD or Not to TDD? + https://bikeshed.thoughtbot.com/381 + 77a68031-000d-4e47-8376-4e8196f3ac3b + Tue, 25 Apr 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + It's gardening season! Stephanie swaps seeds with friends and talks about her Chicago garden. Joël recently started experimenting with a dedicated bookmark manager. + +They discuss the aspirational (and sometimes dogmatic) sides of TDD and explore when to test: first or after. + +How does that affect the tests? +How does that affect the code? +How does that affect workflow? +Are you a "better" programmer because you 100% TDD? + 40:58 + no + + + It's gardening season! Stephanie swaps seeds with friends and talks about her Chicago garden. Joël recently started experimenting with a dedicated bookmark manager. +They discuss the aspirational (and sometimes dogmatic) sides of TDD and explore when to test: first or after. +How does that affect the tests? +How does that affect the code? +How does that affect workflow? +Are you a "better" programmer because you 100% TDD? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Cassidy William's Productivity tools (https://dev.to/cassidoo/the-productivity-apps-i-use-in-2023-3m8l) +raindrop.io Bookmark Manager (https://raindrop.io/) +Simplifying Tests by Extracting Side-Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) +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 is new in your world? +STEPHANIE: It's gardening season here in Chicago. So right now, it is like mid-April as we're recording this, and we are just starting to get some warm weather. And this is usually the time that I do my garden planning for the season. And the other week, I went over to a friend's place, and we did a bit of a seed share. So we just each have collected fruit and vegetable seeds and herbs and all that. +And a really fun way to collect more things to grow is to share with your friends. Seeds are super cheap, but I feel like you could just have like an infinite amount for all of the things that you might want to grow. And so it's really nice to be able to, yes, spread that gardening love around and share with your friends. +JOËL: I'm imagining something like people trading collectible trading cards but the plant version. +STEPHANIE: Yeah, exactly. The fun thing that we did, my friend and I, because, you know, you usually get a little envelope with between 10 and 50 or more seeds, and they're super tiny. Some of them are really teeny tiny, like with broccoli, for example, it's like I can't even explain. It's less than a millimeter, I swear. It's very easy to just lose them, so you want to keep them contained. +But because we are sharing, we don't have a second envelope for the other person to take home with them. And so we actually made our own little envelopes with some origami paper that she had. And we folded it and stapled it and made it very cute. And so I came home with a bunch of these very adorable handmade envelopes with all of my new seeds. +JOËL: Are you mostly doing vegetables, or are these flowers? +STEPHANIE: Yeah, so we mostly focus on vegetables for our garden. And we do like to sprinkle some flower seeds in our yard. But that is more just like throw some seeds out there, and whatever happens to them happens. But with the vegetables, we put a little bit more effort because we usually try to have a good yield. +So in past years, that has meant starting seeds indoors because, in Chicago, we have a shorter growing season than some warmer climate places. And the late summer vegetables like tomatoes, peppers those usually take a little bit longer. So if you want to get a good yield, you might want to start them inside a little early before it's warm enough for them to go outside. +JOËL: So, do you have a garden plot out in your yard, or do you have a community garden plot? How does that work? +STEPHANIE: I am really grateful to have a bit of backyard space. And we have three raised beds that we built that cover...I think each one is 3 feet by 10 feet, so quite a good amount of space. Yeah, we're able to grow a lot of food. Our highlights include shishito peppers. That's one that I really like to grow myself a lot because I usually don't see them in stores as frequently. We grow really great eggplants. Tomatoes, obviously, is a pretty popular beginner-friendly vegetable plant. And we like to grow a lot because then we can process it all and can some of it so we can have nice tomato sauce that's homegrown year round. +JOËL: Hmm, sounds delicious. Do you experiment with the different varieties? +STEPHANIE: We do. That's also a way that the seed sharing is really helpful because maybe I'll get some varieties of certain vegetables like cucumbers or whatever, but maybe my friend has a different kind. And I think we try to do a mix of growing the varieties that we know we like and then experimenting with some ones that are new to us. +JOËL: It's hard to beat fresh vegetables in the summer. +STEPHANIE: Yeah. I'm very excited, especially because during the fall and winter seasons here in Chicago, our local food is a little less exciting. It still can be good, but it's been a lot of root vegetables and the like when we try to eat seasonally in the other season. So I'm really looking forward to stuff that's just juicy and fresh, and it's just one of my biggest joys during the summer. What about you, Joël, what's new in your world? +JOËL: I've recently started experimenting with a dedicated bookmark manager. This is not because I have been to too many bookstores and have all the free bookmarks they give you. These are the digital bookmarks to websites, and I've been really bad at managing those. I mostly just memorize the keywords I need to Google to get access to that website, which is a terrible way of doing things. +And then I've got a mix of a few different browsers, which I don't sync, and have a couple of bookmarks. I use a little bit of Pocket, which is a tool by Mozilla. It's all right, but the search capabilities are not very good. So sometimes I'll know it's in there, but I can't find it. +STEPHANIE: I'm so glad you brought up this topic because I am in a similar boat where I read a lot of things on the internet and have just thrown them all into my top-level bookmarks hierarchy. And that has not really been working for me, either. So I'm really curious to find out how you've been solving this problem. +JOËL: So recently, I volunteered to be a mentor for first-time speakers at the upcoming RailsConf in Atlanta. And someone was asking me about designing slides, and we were talking a little bit about when should you use maybe a bulleted list on a slide versus when there are other options available. I knew that I had read years ago a fantastic resource on slide design. But try as I could, I could not Google this and get the page that I was looking for. +This was shared to me by somebody else as part of a conference preparation group years ago, and so I reached out to this person. I was like, "Hey, so do you happen to remember that link you shared with me five years ago?" And this person says, "I do remember it. I don't have the link either." +STEPHANIE: I've literally been in this exact same situation where I remembered that there was an article that I read, and I remembered exactly who shared it with me or who I talked about it with, and when I couldn't find it, trying to reach out to them and also not being able to find it through them. +JOËL: So the story ends well because I was able to log into an old Slack group... +STEPHANIE: Wow. +JOËL: That had been created for the speakers at this conference and dig through the history. And luckily, I still had access to the group. I was still in that private channel for the speakers. And I found the link, and I was able to share it with others. So that was great. But then I started thinking; I can't keep living this way. I need something better. +STEPHANIE: It's true. Even though we are expert Googlers as developers, sometimes the search just doesn't get you the thing you're looking for. +JOËL: So, about this time, I'm scrolling Twitter as one does. And I saw a tweet from Cassidy Williams talking about some of the productivity tools that she's been using this year did a longer article about it. And I started reading it, and a tool that she mentioned there is Raindrop.io, which is an all-in-one bookmark manager. And I'm like, oh, that is exactly, I think, the missing piece of technology in my life right now. So I went up and signed up for it, and so far, it's been pretty good. I'm experimenting with it. +But I've consolidated a lot of the links that were in my head or in some of these other places, put it in there, categorized them a little bit, tagged them. And hopefully, this becomes a better way so that when I want to reference a link for someone else either in a conversation or as a resource or even for myself, maybe when I'm writing an article, I'm like, oh, I know I read something that would act as a good resource here. I can go to Raindrop and get that article without any of these other shenanigans I had to do this time. +STEPHANIE: Amazing. What is special about Raindrop as opposed to just your native browser bookmark capabilities? +JOËL: It has some deeper structuring capabilities in terms of not everything has to be hierarchical. It has tags as well as categories. And I think most importantly, for me, it has search, which seems to be pretty good at surfacing things. It also has some somewhat smart capabilities where it will automatically figure out if the thing that you've linked is an article, or a document, or a video, something like that. So you can filter by these inferred types as well. It has the ability to sync across devices, which browsers can do if you're signed up for them. +STEPHANIE: Nice. I like that it has that search functionality that you mentioned because I think I'm definitely in the boat of just scrolling through all of my untagged, unorganized bookmarks. And it's really tough to find what I'm looking for, especially if the meta title also doesn't quite tell me exactly the keywords that I'm needing to be scanning for in that moment. So I will definitely have to give it a try. +JOËL: I believe you can get full-text search if you pay for the premium version (I'm currently trying the free version.), which in theory, could mean that it searches the contents of the article. It's not clear with that. But I do know they save a snapshot of the text of the article. +STEPHANIE: That's really interesting because then it's almost like a search engine but scoped to the things that you have saved. +JOËL: Yes. +STEPHANIE: Nice. +JOËL: I'll see how that goes, and maybe six months from now, I can talk a little bit about what the experience has been using that. +STEPHANIE: Yeah, six months from now, you can tell us all about how you have no issues or qualms with how you've been managing bookmarks because everything is working perfectly well for you. [laughs] +JOËL: JK, I've dropped this whole bookmark thing. +STEPHANIE: That's true. That's also the flip side of trying out a new tool, [laughs], isn't it? +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: So our topic for today is something that we've had in our topic backlog for a while, and I'm excited to talk about it. It's TDD, which I think is a very well-known, potentially controversial topic of discussion in the world of software development. And specifically, we wanted to talk about when TDD is useful and when you actually might also have some value in writing tests afterwards. And in preparation for this topic today, I actually have been TDDing most of my client work this week. +JOËL: What? You're telling me you don't TDD 100% of the time? Are you even a real developer? +STEPHANIE: I am a real developer, and I do not TDD 100% of the time. I'm just going to say it. It's on record. +JOËL: You know what? Me too. +STEPHANIE: Wow, I'm glad we could clear the air on that one. [laughs] +JOËL: What percent of the time would you say that you do TDD? In this case, test first as opposed to maybe testing after you've written the code or maybe not testing at all. +STEPHANIE: Hmm, that's an interesting question. A part of me wants to answer it in my ideal workflow terms. But I think that is less interesting than reality, which is I will usually at least try to test first if I'm feeling like I am up for it. So maybe the percentage is, I don't know, I really couldn't tell you, but I'm just going to throw out 40% of the time [laughs] because that seems pretty, I don't know, reasonable. Sometimes you wake up, and you're just like, I'm not going to do it today. [laughs] And other days, you wake up, and you're like, you know? It sounds like a fun exercise to do for this particular feature. +So yeah, if I TDD 40% of the time, then I think maybe I write tests after another 40% or 50%. And then [laughs] I'm hesitant to say this on the air, but sometimes you code, and you don't write tests for it and would not recommend it for the majority of your work. But I'm just going to be real here that sometimes it happens. +JOËL: It's always a trade-off in terms of the work you put in versus the value you're getting out of it. And sometimes, you get very little value out of a test. +STEPHANIE: Yeah, that's real. It totally depends on what you're doing. +JOËL: I think one thing that's interesting for us, because we're consultants, so we move from one project to another, is that some projects are set up in a way that they're very test friendly. It's easy to have a testing workflow with them. And then others are just incredibly painful to test because of the way the system has been architected. +And I think a TDD purist would then tell us that this is a symptom of high coupling or other architectural problems; that's probably true. But also, you don't have time to re-architect the entire system, and so then it becomes a question of trade-offs. Can I test some things easily today? Can I refactor a few things that will make this local change somewhat easier to test? And then, where is it not worth the effort to make something testable? +STEPHANIE: Yeah, I've definitely struggled with that, where a part of me wanted to test something very thoroughly or even do test-driven development and then ran into some obstacles along the way and having to be realistic about that effort. +The other thing I was referring to around it depending is also the actual code you're working on. So maybe if you're just writing a script or something to automate some dev workflow, it's okay for that not to be tested. And I also do think that the decision to TDD is very dependent on whether you are writing net new code, or refactoring, or having to deal with legacy code. +JOËL: That definitely makes a difference. For me, when I'm refactoring in the purest sense, changing structure without changing behavior, in theory, I should not be writing tests for that because there should already be existing tests, and I'm not changing behaviors. So the test suite should prove that my changes did not change behavior. In practice, oftentimes, there is not the coverage that needs to be there. I don't know about you; I feel like I often don't trust the code enough, where I'm a little bit scared to do a refactor if there isn't test coverage. How about you? +STEPHANIE: I've been running into that issue a lot on my current client project where I've been making an intentional effort to add test coverage before I make any changes because that forces me to really understand how things work because either I read a piece of code and I just can't tell at all. Or I learn later on that I thought I understood something based on the class or the method names, but it turns out that there was actually some nuance in there or side effects or what have you that belied my understanding [laughs] of what it was doing. +And after a few times of that lack of trust that you talked about popping up, I was like, okay, I think, at least for me, the way that I can feel good about the work that I'm doing is to set myself up for success in that way. +JOËL: Do you ever find that the code that you write in a test-driven approach tends to end up different than code that you might write with a test-after approach? +STEPHANIE: Yeah, I think this can actually be answered at a few different levels but let me start with talking about how I like to practice TDD. If I'm given a user story, I usually try to work outside in. So I will write a feature or acceptance test and that involves testing how the user would interact with our application. +At that point, I will usually go with the most naive implementation to get the test passing, and so it probably won't look pretty. In a recent case, I was adding a new parameter to a controller, and I just put everything in the controller to get the test green. [laughs] And then, at that point, is when I gave that code a second pass and looked for areas to extract where I could. +JOËL: That refactor step and the red, green refactor cycle is really important. +STEPHANIE: Yeah, absolutely. I think that is where I find TDD to be the most valuable from that higher-level perspective. And I know that there are different schools of thought on this. But that helps ensure that at least I have written the code to make the feature work the way that I was hoping. And I use TDD less for driving design decisions just because I like to have something to react to that is helpful for me rather than having a blank slate of, okay, let me write a test with an idea about how an object's interface will look. And so that's what works for me. +So I do think it's kind of a mix of like from an acceptance test level; I am at least writing code that I know works, but the shape of the code for me is less determined by how I test. +JOËL: So when you're looking at code that you've written six months down the line, you generally can't tell the difference whether it was test-driven or written first and tested after. +STEPHANIE: That sounds right. That's just how my process works. In fact, I think recently we, to go on a quick tangent, we talked about writing conference talks, and I think I even mentioned for me the process is looking at the thing and then revising. And I think that the design driving element of TDD that a lot of people like is a bit less effective for me personally. +JOËL: Hmm. Would you say that TDD does not impact the shape of the code that you end up creating in response to the tests? Or when you're talking about design, are you mostly thinking in terms of the interface that you would have in the test itself, like, what arguments the constructor takes or things like that? +STEPHANIE: I think I was talking more about the latter, the interface, the construction arguments. When I do test afterwards, I also will notice the way the setup of my test how that is feeling. And if it is feeling a bit unwieldy or is a bit complicated, that will cue me to maybe take another pass at the code itself. So that's actually one way that testing after can signal to me a way that I might want to change my code. +JOËL: Okay, so you're getting some of those pressures that you get from testing, but you respond to them in a like second path? +STEPHANIE: Yeah, I think so. I'm curious how you TDD and whether you notice changes in how your code looks. +JOËL: I think there are a couple of things that TDD does in my workflow that are really nice. One is it keeps me focused in terms of getting the work done because you're just following from one failure to another. It also keeps me focused in terms of scope. It's really easy for my engineering brain to be like, oh, we could totally do this thing and all that, and it's like, no, that's not needed to solve the problem at hand. +Because in TDD, you try the smallest solution that will solve your problem, and then you will refactor it to make it maybe nicer to work with. But you try not to add new behavior that's not required in order to pass the test, and that can be a really helpful forcing function for me. +STEPHANIE: That's interesting because I was just thinking about how sometimes, at least with the outside-in approach that I was talking about, I will find that the scope of the ticket is too big as I make changes to get the desired quality of the code that I want. +Like I mentioned, the naive implementation, like, sure, maybe everything is in a controller, but as soon as I'm starting to do that second pass, and I want to maybe change another class and to make it work for my needs, I will notice it start to sprawl a little bit. And that is usually a signal to me that, like, oh, maybe what I need first is just refactoring the objects that I'm hoping to use to get the desired implementation. And that ends up being a separate PR that I do first to then set myself up for making the change. +JOËL: The classic make the change easy before you then go and make the easy change. +STEPHANIE: Right. But that does mean that that initial feature test that I wrote won't ever be green. So I do have to kind of like back out of making that change and just be like, okay, today is not the day [laughs] that I'm going to get this feature working. +JOËL: There are some times where I'm in a situation like that, and I will kind of recognize, oh, there's a refactor step that's happening right now as a sort of subtask. And so, I will make that refactor change that I need to and then commit only those files that were a part of that refactor and may be included as part of the PR with the feature change or maybe push it up and make it its own PR. +But depending on what the refactor is, oftentimes, I can kind of do it sort of all more or less continuously but decide once I've done that refactor step, okay, commit time but only those files for the smaller set of changes, and then keep moving with that outside-in approach. +One thing I have noticed about the style of code that I tend to produce when I TDD versus when I don't is how I will tend to decouple things. And so because coupled code is really annoying to test in isolation, TDD sort of forces me to do more dependency injection, passing objects to others. It will often force me or maybe not force me, but it gives me that wholesome pressure to maybe separate HTTP requests from more of the business logic in my code, which otherwise I might completely intermix because it's just so convenient. Even certain things like class methods, I might tend to overuse them or use them more if I'm not test driving than if I were. +STEPHANIE: When you talk about coupling, I'm curious, do you end up mocking a lot in the tests that you are writing to drive your development? +JOËL: No, but if I'm testing after, I probably will. Mocking, I think, is a sign of coupling generally. In tests where you're just passing objects to each other, generally, you can get away with passing in a test double or something, whereas if you're hard-coding dependencies, you often have to mock. +STEPHANIE: Got it. That makes a lot more sense now. I think that does require a bit of thought upfront about what kinds of objects you might need and what they would provide for you in the thing that you're testing. +JOËL: Yes. There's definitely a phase where let's say; I'm testing some kind of third-party integration; I'm just kind of trying to do it all in one object that has a mix of business logic and some HTTP request stuff. It gets really annoying as we're adding...maybe the first feature is okay. I use WebMock, and I stub out a request, and it's good. And then the second one, I feel like I'm kind of duplicating that. And then the third one, I've got to deal with retries. +So now I've got to go back to the first one and add some two or three WebMocks because now we've got exponential backoff code that's happening here. And this new feature broke the old tests. And it just becomes this really annoying thing to do. And then I might start thinking, okay, how do I separate these two things? I have one place where I test the HTTP logic, the exponential backoff, the what to do if I get a 404 from the API. And then, separately, I can just have the business logic and test all of those branches there without having to touch any of the HTTP stuff. +I think you could get there from a few different paths. So you could get there by sort of following a lot of classic design principles, things like SOLID, because they kind of converge on that general idea as well. You could even get there if you took more of a functional programming approach where you are really good at separating side-effectful code from, I'm going to use the term loosely here, pure functions. +I've heard some people make the distinction between IO versus non-IO in code and how that affects the types of tests that you write for them. And separating those two is a thing that you might do, even if you weren't writing tests at all, if that's a design principle that you know to follow. +STEPHANIE: Yeah, that's a great point. I was thinking, as you were talking about your approach for handling that potential feature with talking to a third party, that I've heard that particular task or problem in software development used as an example for a lot of those different techniques or strategies that you mentioned. And I suppose TDD really is just a tool, and it doesn't replace your experience or intuition. +And earlier, when we were talking about times that you don't do TDD, I will have to say that if I am doing something that I've done many times before, I feel confident enough that I don't need to lean on that red, green refactor cycle. At that point, it's more muscle memory. And maybe I do forget a step along the way, but I have the experience to know how to debug that or to see the error and know exactly what it was that I did wrong. And in that case, I am tapping into something different than using TDD. +JOËL: I think definitely, for a lot of things now, there are patterns that I have learned where even if I weren't TDDing, I might do a third-party integration using this pattern because I've done it via TDD enough to know that this is a structure that I find works very well in terms of the coupling of things. And then maybe if I want to fill in some tests afterwards, then I'll thank my past self that I'm using a pattern that plays nicely with that. One thing that I do notice happens sometimes is that when people add tests after the fact, they will add tests that are green but that don't necessarily fail if the code breaks. Have you ever seen that? +STEPHANIE: I have seen that before. In fact, I just saw it recently where we had a false positive test. And I made a change expecting the test to fail, and it didn't, which is not great because the value that tests have are when they fail, you want to be alerted when something goes wrong. Just because they're green doesn't mean that everything works. It just means that they didn't detect a problem. And in this particular case, I don't know if the developer who wrote this test had TDDed or not. But I did notice that in the test, we were mocking a method, and that ended up being the cause of the false positive. +JOËL: I'm always a little bit skeptical of mocks because I feel like I've seen so many either brittle tests or tests that will succeed all the time come out of mocks. I don't know if you've ever heard the term tautological test or a test that is a tautology. +STEPHANIE: No, I haven't. What does that mean? +JOËL: In its sort of most basic sense, it's a test that is always green no matter what the output is. Some people think of it more in terms of self-referential tests, like, oh, a thing equals itself, which, yes, it does, and those tend to be always green. But it's not always self-referential. It can be some other subtle ways. Typically this happens when mocking or specifically if you mock the system under test. It's very easy to write a test that is now going to always be green, no matter how the code changes. +A fun fact about the word tautology is it comes from discrete math, which is the topic of my RailsConf talk. If you write out a truth table that shows all the possible inputs and whether or not something will be true or false, depending on what the inputs are, the output column is all true in a tautology, which tells you that no matter what the inputs are, you're going to get true out of that method or function or equation. And so, if this was a Boolean expression in Ruby, you could replace that by hardcoding true and get the same result. +STEPHANIE: Yeah, that's what I was imagining, a function that just returns true. [laughs] +JOËL: And that's effectively what you can accidentally write when you're creating a test that is a tautological test is one where you could have just replaced the entire thing with expect true to be true, and it would have the same effect. And, like you said, tests only have value when they fail. And a test that never fails has no value. So TDD has this red, green refactor cycle. I feel like you could probably come up with a cute slogan like that for a testing-after style. So maybe I guess you'd start off you write some code, then you write a test that theoretically passes for it. +So you start green, but then you want to make sure you see that test fail, so you got to go red and then comment out the code or something. Then comment it back in to see that it goes back to green to make sure that not only does this test fail when the code is broken but also that bringing this test back is what makes it pass, which is an important distinction. So maybe it's a green, red, green, and then maybe refactor. Because one thing that I admired in the style that you were talking about earlier is that even when you test after, you include a refactor step. The test at the end is not the final step in your workflow. +STEPHANIE: Yeah, that's a really good point. When you said green, red, green, I was thinking of a Christmas garland [laughs] or something like that. But yeah, I do think that stuff gets skipped sometimes. If you are testing after, you're backfilling tests for code you wrote, and at that point, you think you know how it will work, and so you're writing your tests kind of colored with that in mind. +I like the injecting commenting something out or changing an input or something that you know should make the test fail, just so that you can confirm that you didn't just write a test that expects true to equal true or give you a false positive like that, then go back to green. And as you were saying that, it did make me think like, oh, well, that's like a whole extra step as opposed to TDD where we do just have red, green refactor. We don't have that extra step. But I think the effort is just like put in at a different point in time. +JOËL: Agreed. It's important that you see the code fail and that you see it pass after the change. The order has changed a little bit, but those two kinds of core elements are present. Kind of by default, you have no choice when you're doing TDD. You have the ability to skip that if you're testing after, but ideally, you incorporate those in a robust test after workflow as well. +STEPHANIE: Yeah. And I know I mentioned times when I've done something enough or used a pattern enough that maybe I'll just go ahead and implement it and then backfill with tests. And I also recognize that in those moments, I could have done something wrong, that there is some amount of wanting to check that the test failed. And I imagine there is some kind of balance to achieve there between the speed that you get by having that experience and knowing the direction you want to take things and applying a pattern that you've done a lot with being like, oh, we're all human, and sometimes we make mistakes. +JOËL: In a situation where you feel like you're coding something that you've coded up 100 times before, you're very familiar with this. Do you find that a test after workflow is faster for you? +STEPHANIE: Hmm, that's an interesting question. +JOËL: Because I think that's often a motivation. It's like, I don't want to bother, like, I just have the idea. I know what to do. Let me just write that code and get it done. +STEPHANIE: I think if I were introducing a new route or controller action or whatever, I don't need to go through the cycle of writing a test and it failing because I haven't added the action to the controller yet. It's like I know that that is the next logical step, and so maybe I might skip it there. But if I'm at the point where I'm working with business or domain logic, I think that's where is the value of test writing first because it's like, I passed the framework and passed my tools. And now, I'm working at working through the logic of the business problem itself. +JOËL: So you're working in maybe slightly larger iterations of that red, green refactor cycle. +STEPHANIE: Yeah, that's a good way to describe it. +JOËL: I was recently working on a gem and tried to TDD it from scratch and went with micro iterations. And it was actually really fun, and there was a flow to it. And this is a greenfield side project. And it helped me stay focused. I think it did give me a decent design. I really enjoyed it. +STEPHANIE: Nice. Was there something satisfying about seeing that green each time and kind of doing that bit of mechanical labor? And I can see how that can feel almost meditative. +JOËL: Yes. And I think also because this was a problem that I didn't fully know how I was going to solve, TDD helped really focus me on solving sub-parts of that problem, things that I can hold in my head and solve in a minimalistic way and then iterate on. +STEPHANIE: I like that a lot. You were using that technique, and that really helped for the task at hand, which was, in this case, a bit smaller in scope. I think the way you and I have been talking about TDD has been very realistic and very reasonable. And I'm curious what you think about people who kind of use it as the pinnacle of how you should write code. +JOËL: I think that's really interesting because TDD is a really wonderful technique, and I wish more people used it. But it's kind of taken on a mystique of its own where if you do TDD or claim to do TDD 100% of the time, now, all of a sudden, you've put yourself on another level. And I think people even who choose for pragmatic reasons not to TDD all the time maybe feel a little bit of guilt or at least feel the need to explain themselves to other people to say, "Hey, I didn't TDD this here. Well, let me explain to you why that's okay, and I'm not a bad programmer." +STEPHANIE: Yeah, I think we even alluded a little bit to that earlier in the show, and I could hear my hesitancy to be like, oh, I guess I'm going to say this and have all these people hear it. But I think that's a good point that it's okay for you not to do it 100% of the time. That doesn't make you any less of a programmer. Also, the way we've been talking about it also makes it sound like one of those things where it's like you do have to learn the rules before you can break them. And so there is value in learning it and doing it. +And then you also, after having done it enough, know when you want to use it or when you don't. My advice for folks who haven't really done it before or don't quite see the value of it is just to try it and then decide for yourself. I think at the end of the day, we should all feel empowered to be able to decide how we work best. +JOËL: It's also really valuable, I think, to maybe pair with someone who is really good at that and to get to see what their workflow is like. Oftentimes, there's almost a hump of getting into it where you are more productive without TDDing because you're not comfortable with the flow or with the techniques. And it takes a lot of expertise to get over that hump where maybe at the expert end of things, you are more productive with it. And on the less expert end, it just becomes a chore that takes up all of your time or ends up giving you results that aren't that great anyway. And so, how do you cross that chasm? +STEPHANIE: Yeah, that's a really, really great point because, in some ways, when you first get started, it will feel slow. You are unlearning the ways that you have known to code before and trying to do it in a different way. And I really like your advice about trying to pair with someone who has expertise or has been practicing it for a long time. That was my first real introduction to it too. At this point, I had been a few years into my career and hadn't really tried it because it seemed very daunting, and seeing someone else verbalize their process and seeing their workflow was really helpful for me to get on board. +JOËL: I think what I would like is for TDD to be a tool that is aspirational for a lot of people. If you're new to the technique and you've paired with somebody who's really good at it, and you see the flow that they have and be like, wow, that's really good. I would love to get that incorporated in the way that I work. Rather than a sort of measuring stick for how elite of a programmer you are. There's no sense in shaming people over the tools they use. +STEPHANIE: Right. Because it should also be accessible, and if you make people feel bad about it, and then it's not accessible to folks. +JOËL: On that note. Shall we wrap up? +STEPHANIE: Yeah, let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + It's gardening season! Stephanie swaps seeds with friends and talks about her Chicago garden. Joël recently started experimenting with a dedicated bookmark manager.

+ +

They discuss the aspirational (and sometimes dogmatic) sides of TDD and explore when to test: first or after.

+ +

How does that affect the tests?
+How does that affect the code?
+How does that affect workflow?
+Are you a "better" programmer because you 100% TDD?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 is new in your world?

+ +

STEPHANIE: It's gardening season here in Chicago. So right now, it is like mid-April as we're recording this, and we are just starting to get some warm weather. And this is usually the time that I do my garden planning for the season. And the other week, I went over to a friend's place, and we did a bit of a seed share. So we just each have collected fruit and vegetable seeds and herbs and all that.

+ +

And a really fun way to collect more things to grow is to share with your friends. Seeds are super cheap, but I feel like you could just have like an infinite amount for all of the things that you might want to grow. And so it's really nice to be able to, yes, spread that gardening love around and share with your friends.

+ +

JOËL: I'm imagining something like people trading collectible trading cards but the plant version.

+ +

STEPHANIE: Yeah, exactly. The fun thing that we did, my friend and I, because, you know, you usually get a little envelope with between 10 and 50 or more seeds, and they're super tiny. Some of them are really teeny tiny, like with broccoli, for example, it's like I can't even explain. It's less than a millimeter, I swear. It's very easy to just lose them, so you want to keep them contained.

+ +

But because we are sharing, we don't have a second envelope for the other person to take home with them. And so we actually made our own little envelopes with some origami paper that she had. And we folded it and stapled it and made it very cute. And so I came home with a bunch of these very adorable handmade envelopes with all of my new seeds.

+ +

JOËL: Are you mostly doing vegetables, or are these flowers?

+ +

STEPHANIE: Yeah, so we mostly focus on vegetables for our garden. And we do like to sprinkle some flower seeds in our yard. But that is more just like throw some seeds out there, and whatever happens to them happens. But with the vegetables, we put a little bit more effort because we usually try to have a good yield.

+ +

So in past years, that has meant starting seeds indoors because, in Chicago, we have a shorter growing season than some warmer climate places. And the late summer vegetables like tomatoes, peppers those usually take a little bit longer. So if you want to get a good yield, you might want to start them inside a little early before it's warm enough for them to go outside.

+ +

JOËL: So, do you have a garden plot out in your yard, or do you have a community garden plot? How does that work?

+ +

STEPHANIE: I am really grateful to have a bit of backyard space. And we have three raised beds that we built that cover...I think each one is 3 feet by 10 feet, so quite a good amount of space. Yeah, we're able to grow a lot of food. Our highlights include shishito peppers. That's one that I really like to grow myself a lot because I usually don't see them in stores as frequently. We grow really great eggplants. Tomatoes, obviously, is a pretty popular beginner-friendly vegetable plant. And we like to grow a lot because then we can process it all and can some of it so we can have nice tomato sauce that's homegrown year round.

+ +

JOËL: Hmm, sounds delicious. Do you experiment with the different varieties?

+ +

STEPHANIE: We do. That's also a way that the seed sharing is really helpful because maybe I'll get some varieties of certain vegetables like cucumbers or whatever, but maybe my friend has a different kind. And I think we try to do a mix of growing the varieties that we know we like and then experimenting with some ones that are new to us.

+ +

JOËL: It's hard to beat fresh vegetables in the summer.

+ +

STEPHANIE: Yeah. I'm very excited, especially because during the fall and winter seasons here in Chicago, our local food is a little less exciting. It still can be good, but it's been a lot of root vegetables and the like when we try to eat seasonally in the other season. So I'm really looking forward to stuff that's just juicy and fresh, and it's just one of my biggest joys during the summer. What about you, Joël, what's new in your world?

+ +

JOËL: I've recently started experimenting with a dedicated bookmark manager. This is not because I have been to too many bookstores and have all the free bookmarks they give you. These are the digital bookmarks to websites, and I've been really bad at managing those. I mostly just memorize the keywords I need to Google to get access to that website, which is a terrible way of doing things.

+ +

And then I've got a mix of a few different browsers, which I don't sync, and have a couple of bookmarks. I use a little bit of Pocket, which is a tool by Mozilla. It's all right, but the search capabilities are not very good. So sometimes I'll know it's in there, but I can't find it.

+ +

STEPHANIE: I'm so glad you brought up this topic because I am in a similar boat where I read a lot of things on the internet and have just thrown them all into my top-level bookmarks hierarchy. And that has not really been working for me, either. So I'm really curious to find out how you've been solving this problem.

+ +

JOËL: So recently, I volunteered to be a mentor for first-time speakers at the upcoming RailsConf in Atlanta. And someone was asking me about designing slides, and we were talking a little bit about when should you use maybe a bulleted list on a slide versus when there are other options available. I knew that I had read years ago a fantastic resource on slide design. But try as I could, I could not Google this and get the page that I was looking for.

+ +

This was shared to me by somebody else as part of a conference preparation group years ago, and so I reached out to this person. I was like, "Hey, so do you happen to remember that link you shared with me five years ago?" And this person says, "I do remember it. I don't have the link either."

+ +

STEPHANIE: I've literally been in this exact same situation where I remembered that there was an article that I read, and I remembered exactly who shared it with me or who I talked about it with, and when I couldn't find it, trying to reach out to them and also not being able to find it through them.

+ +

JOËL: So the story ends well because I was able to log into an old Slack group...

+ +

STEPHANIE: Wow.

+ +

JOËL: That had been created for the speakers at this conference and dig through the history. And luckily, I still had access to the group. I was still in that private channel for the speakers. And I found the link, and I was able to share it with others. So that was great. But then I started thinking; I can't keep living this way. I need something better.

+ +

STEPHANIE: It's true. Even though we are expert Googlers as developers, sometimes the search just doesn't get you the thing you're looking for.

+ +

JOËL: So, about this time, I'm scrolling Twitter as one does. And I saw a tweet from Cassidy Williams talking about some of the productivity tools that she's been using this year did a longer article about it. And I started reading it, and a tool that she mentioned there is Raindrop.io, which is an all-in-one bookmark manager. And I'm like, oh, that is exactly, I think, the missing piece of technology in my life right now. So I went up and signed up for it, and so far, it's been pretty good. I'm experimenting with it.

+ +

But I've consolidated a lot of the links that were in my head or in some of these other places, put it in there, categorized them a little bit, tagged them. And hopefully, this becomes a better way so that when I want to reference a link for someone else either in a conversation or as a resource or even for myself, maybe when I'm writing an article, I'm like, oh, I know I read something that would act as a good resource here. I can go to Raindrop and get that article without any of these other shenanigans I had to do this time.

+ +

STEPHANIE: Amazing. What is special about Raindrop as opposed to just your native browser bookmark capabilities?

+ +

JOËL: It has some deeper structuring capabilities in terms of not everything has to be hierarchical. It has tags as well as categories. And I think most importantly, for me, it has search, which seems to be pretty good at surfacing things. It also has some somewhat smart capabilities where it will automatically figure out if the thing that you've linked is an article, or a document, or a video, something like that. So you can filter by these inferred types as well. It has the ability to sync across devices, which browsers can do if you're signed up for them.

+ +

STEPHANIE: Nice. I like that it has that search functionality that you mentioned because I think I'm definitely in the boat of just scrolling through all of my untagged, unorganized bookmarks. And it's really tough to find what I'm looking for, especially if the meta title also doesn't quite tell me exactly the keywords that I'm needing to be scanning for in that moment. So I will definitely have to give it a try.

+ +

JOËL: I believe you can get full-text search if you pay for the premium version (I'm currently trying the free version.), which in theory, could mean that it searches the contents of the article. It's not clear with that. But I do know they save a snapshot of the text of the article.

+ +

STEPHANIE: That's really interesting because then it's almost like a search engine but scoped to the things that you have saved.

+ +

JOËL: Yes.

+ +

STEPHANIE: Nice.

+ +

JOËL: I'll see how that goes, and maybe six months from now, I can talk a little bit about what the experience has been using that.

+ +

STEPHANIE: Yeah, six months from now, you can tell us all about how you have no issues or qualms with how you've been managing bookmarks because everything is working perfectly well for you. [laughs]

+ +

JOËL: JK, I've dropped this whole bookmark thing.

+ +

STEPHANIE: That's true. That's also the flip side of trying out a new tool, [laughs], isn't it?

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So our topic for today is something that we've had in our topic backlog for a while, and I'm excited to talk about it. It's TDD, which I think is a very well-known, potentially controversial topic of discussion in the world of software development. And specifically, we wanted to talk about when TDD is useful and when you actually might also have some value in writing tests afterwards. And in preparation for this topic today, I actually have been TDDing most of my client work this week.

+ +

JOËL: What? You're telling me you don't TDD 100% of the time? Are you even a real developer?

+ +

STEPHANIE: I am a real developer, and I do not TDD 100% of the time. I'm just going to say it. It's on record.

+ +

JOËL: You know what? Me too.

+ +

STEPHANIE: Wow, I'm glad we could clear the air on that one. [laughs]

+ +

JOËL: What percent of the time would you say that you do TDD? In this case, test first as opposed to maybe testing after you've written the code or maybe not testing at all.

+ +

STEPHANIE: Hmm, that's an interesting question. A part of me wants to answer it in my ideal workflow terms. But I think that is less interesting than reality, which is I will usually at least try to test first if I'm feeling like I am up for it. So maybe the percentage is, I don't know, I really couldn't tell you, but I'm just going to throw out 40% of the time [laughs] because that seems pretty, I don't know, reasonable. Sometimes you wake up, and you're just like, I'm not going to do it today. [laughs] And other days, you wake up, and you're like, you know? It sounds like a fun exercise to do for this particular feature.

+ +

So yeah, if I TDD 40% of the time, then I think maybe I write tests after another 40% or 50%. And then [laughs] I'm hesitant to say this on the air, but sometimes you code, and you don't write tests for it and would not recommend it for the majority of your work. But I'm just going to be real here that sometimes it happens.

+ +

JOËL: It's always a trade-off in terms of the work you put in versus the value you're getting out of it. And sometimes, you get very little value out of a test.

+ +

STEPHANIE: Yeah, that's real. It totally depends on what you're doing.

+ +

JOËL: I think one thing that's interesting for us, because we're consultants, so we move from one project to another, is that some projects are set up in a way that they're very test friendly. It's easy to have a testing workflow with them. And then others are just incredibly painful to test because of the way the system has been architected.

+ +

And I think a TDD purist would then tell us that this is a symptom of high coupling or other architectural problems; that's probably true. But also, you don't have time to re-architect the entire system, and so then it becomes a question of trade-offs. Can I test some things easily today? Can I refactor a few things that will make this local change somewhat easier to test? And then, where is it not worth the effort to make something testable?

+ +

STEPHANIE: Yeah, I've definitely struggled with that, where a part of me wanted to test something very thoroughly or even do test-driven development and then ran into some obstacles along the way and having to be realistic about that effort.

+ +

The other thing I was referring to around it depending is also the actual code you're working on. So maybe if you're just writing a script or something to automate some dev workflow, it's okay for that not to be tested. And I also do think that the decision to TDD is very dependent on whether you are writing net new code, or refactoring, or having to deal with legacy code.

+ +

JOËL: That definitely makes a difference. For me, when I'm refactoring in the purest sense, changing structure without changing behavior, in theory, I should not be writing tests for that because there should already be existing tests, and I'm not changing behaviors. So the test suite should prove that my changes did not change behavior. In practice, oftentimes, there is not the coverage that needs to be there. I don't know about you; I feel like I often don't trust the code enough, where I'm a little bit scared to do a refactor if there isn't test coverage. How about you?

+ +

STEPHANIE: I've been running into that issue a lot on my current client project where I've been making an intentional effort to add test coverage before I make any changes because that forces me to really understand how things work because either I read a piece of code and I just can't tell at all. Or I learn later on that I thought I understood something based on the class or the method names, but it turns out that there was actually some nuance in there or side effects or what have you that belied my understanding [laughs] of what it was doing.

+ +

And after a few times of that lack of trust that you talked about popping up, I was like, okay, I think, at least for me, the way that I can feel good about the work that I'm doing is to set myself up for success in that way.

+ +

JOËL: Do you ever find that the code that you write in a test-driven approach tends to end up different than code that you might write with a test-after approach?

+ +

STEPHANIE: Yeah, I think this can actually be answered at a few different levels but let me start with talking about how I like to practice TDD. If I'm given a user story, I usually try to work outside in. So I will write a feature or acceptance test and that involves testing how the user would interact with our application.

+ +

At that point, I will usually go with the most naive implementation to get the test passing, and so it probably won't look pretty. In a recent case, I was adding a new parameter to a controller, and I just put everything in the controller to get the test green. [laughs] And then, at that point, is when I gave that code a second pass and looked for areas to extract where I could.

+ +

JOËL: That refactor step and the red, green refactor cycle is really important.

+ +

STEPHANIE: Yeah, absolutely. I think that is where I find TDD to be the most valuable from that higher-level perspective. And I know that there are different schools of thought on this. But that helps ensure that at least I have written the code to make the feature work the way that I was hoping. And I use TDD less for driving design decisions just because I like to have something to react to that is helpful for me rather than having a blank slate of, okay, let me write a test with an idea about how an object's interface will look. And so that's what works for me.

+ +

So I do think it's kind of a mix of like from an acceptance test level; I am at least writing code that I know works, but the shape of the code for me is less determined by how I test.

+ +

JOËL: So when you're looking at code that you've written six months down the line, you generally can't tell the difference whether it was test-driven or written first and tested after.

+ +

STEPHANIE: That sounds right. That's just how my process works. In fact, I think recently we, to go on a quick tangent, we talked about writing conference talks, and I think I even mentioned for me the process is looking at the thing and then revising. And I think that the design driving element of TDD that a lot of people like is a bit less effective for me personally.

+ +

JOËL: Hmm. Would you say that TDD does not impact the shape of the code that you end up creating in response to the tests? Or when you're talking about design, are you mostly thinking in terms of the interface that you would have in the test itself, like, what arguments the constructor takes or things like that?

+ +

STEPHANIE: I think I was talking more about the latter, the interface, the construction arguments. When I do test afterwards, I also will notice the way the setup of my test how that is feeling. And if it is feeling a bit unwieldy or is a bit complicated, that will cue me to maybe take another pass at the code itself. So that's actually one way that testing after can signal to me a way that I might want to change my code.

+ +

JOËL: Okay, so you're getting some of those pressures that you get from testing, but you respond to them in a like second path?

+ +

STEPHANIE: Yeah, I think so. I'm curious how you TDD and whether you notice changes in how your code looks.

+ +

JOËL: I think there are a couple of things that TDD does in my workflow that are really nice. One is it keeps me focused in terms of getting the work done because you're just following from one failure to another. It also keeps me focused in terms of scope. It's really easy for my engineering brain to be like, oh, we could totally do this thing and all that, and it's like, no, that's not needed to solve the problem at hand.

+ +

Because in TDD, you try the smallest solution that will solve your problem, and then you will refactor it to make it maybe nicer to work with. But you try not to add new behavior that's not required in order to pass the test, and that can be a really helpful forcing function for me.

+ +

STEPHANIE: That's interesting because I was just thinking about how sometimes, at least with the outside-in approach that I was talking about, I will find that the scope of the ticket is too big as I make changes to get the desired quality of the code that I want.

+ +

Like I mentioned, the naive implementation, like, sure, maybe everything is in a controller, but as soon as I'm starting to do that second pass, and I want to maybe change another class and to make it work for my needs, I will notice it start to sprawl a little bit. And that is usually a signal to me that, like, oh, maybe what I need first is just refactoring the objects that I'm hoping to use to get the desired implementation. And that ends up being a separate PR that I do first to then set myself up for making the change.

+ +

JOËL: The classic make the change easy before you then go and make the easy change.

+ +

STEPHANIE: Right. But that does mean that that initial feature test that I wrote won't ever be green. So I do have to kind of like back out of making that change and just be like, okay, today is not the day [laughs] that I'm going to get this feature working.

+ +

JOËL: There are some times where I'm in a situation like that, and I will kind of recognize, oh, there's a refactor step that's happening right now as a sort of subtask. And so, I will make that refactor change that I need to and then commit only those files that were a part of that refactor and may be included as part of the PR with the feature change or maybe push it up and make it its own PR.

+ +

But depending on what the refactor is, oftentimes, I can kind of do it sort of all more or less continuously but decide once I've done that refactor step, okay, commit time but only those files for the smaller set of changes, and then keep moving with that outside-in approach.

+ +

One thing I have noticed about the style of code that I tend to produce when I TDD versus when I don't is how I will tend to decouple things. And so because coupled code is really annoying to test in isolation, TDD sort of forces me to do more dependency injection, passing objects to others. It will often force me or maybe not force me, but it gives me that wholesome pressure to maybe separate HTTP requests from more of the business logic in my code, which otherwise I might completely intermix because it's just so convenient. Even certain things like class methods, I might tend to overuse them or use them more if I'm not test driving than if I were.

+ +

STEPHANIE: When you talk about coupling, I'm curious, do you end up mocking a lot in the tests that you are writing to drive your development?

+ +

JOËL: No, but if I'm testing after, I probably will. Mocking, I think, is a sign of coupling generally. In tests where you're just passing objects to each other, generally, you can get away with passing in a test double or something, whereas if you're hard-coding dependencies, you often have to mock.

+ +

STEPHANIE: Got it. That makes a lot more sense now. I think that does require a bit of thought upfront about what kinds of objects you might need and what they would provide for you in the thing that you're testing.

+ +

JOËL: Yes. There's definitely a phase where let's say; I'm testing some kind of third-party integration; I'm just kind of trying to do it all in one object that has a mix of business logic and some HTTP request stuff. It gets really annoying as we're adding...maybe the first feature is okay. I use WebMock, and I stub out a request, and it's good. And then the second one, I feel like I'm kind of duplicating that. And then the third one, I've got to deal with retries.

+ +

So now I've got to go back to the first one and add some two or three WebMocks because now we've got exponential backoff code that's happening here. And this new feature broke the old tests. And it just becomes this really annoying thing to do. And then I might start thinking, okay, how do I separate these two things? I have one place where I test the HTTP logic, the exponential backoff, the what to do if I get a 404 from the API. And then, separately, I can just have the business logic and test all of those branches there without having to touch any of the HTTP stuff.

+ +

I think you could get there from a few different paths. So you could get there by sort of following a lot of classic design principles, things like SOLID, because they kind of converge on that general idea as well. You could even get there if you took more of a functional programming approach where you are really good at separating side-effectful code from, I'm going to use the term loosely here, pure functions.

+ +

I've heard some people make the distinction between IO versus non-IO in code and how that affects the types of tests that you write for them. And separating those two is a thing that you might do, even if you weren't writing tests at all, if that's a design principle that you know to follow.

+ +

STEPHANIE: Yeah, that's a great point. I was thinking, as you were talking about your approach for handling that potential feature with talking to a third party, that I've heard that particular task or problem in software development used as an example for a lot of those different techniques or strategies that you mentioned. And I suppose TDD really is just a tool, and it doesn't replace your experience or intuition.

+ +

And earlier, when we were talking about times that you don't do TDD, I will have to say that if I am doing something that I've done many times before, I feel confident enough that I don't need to lean on that red, green refactor cycle. At that point, it's more muscle memory. And maybe I do forget a step along the way, but I have the experience to know how to debug that or to see the error and know exactly what it was that I did wrong. And in that case, I am tapping into something different than using TDD.

+ +

JOËL: I think definitely, for a lot of things now, there are patterns that I have learned where even if I weren't TDDing, I might do a third-party integration using this pattern because I've done it via TDD enough to know that this is a structure that I find works very well in terms of the coupling of things. And then maybe if I want to fill in some tests afterwards, then I'll thank my past self that I'm using a pattern that plays nicely with that. One thing that I do notice happens sometimes is that when people add tests after the fact, they will add tests that are green but that don't necessarily fail if the code breaks. Have you ever seen that?

+ +

STEPHANIE: I have seen that before. In fact, I just saw it recently where we had a false positive test. And I made a change expecting the test to fail, and it didn't, which is not great because the value that tests have are when they fail, you want to be alerted when something goes wrong. Just because they're green doesn't mean that everything works. It just means that they didn't detect a problem. And in this particular case, I don't know if the developer who wrote this test had TDDed or not. But I did notice that in the test, we were mocking a method, and that ended up being the cause of the false positive.

+ +

JOËL: I'm always a little bit skeptical of mocks because I feel like I've seen so many either brittle tests or tests that will succeed all the time come out of mocks. I don't know if you've ever heard the term tautological test or a test that is a tautology.

+ +

STEPHANIE: No, I haven't. What does that mean?

+ +

JOËL: In its sort of most basic sense, it's a test that is always green no matter what the output is. Some people think of it more in terms of self-referential tests, like, oh, a thing equals itself, which, yes, it does, and those tend to be always green. But it's not always self-referential. It can be some other subtle ways. Typically this happens when mocking or specifically if you mock the system under test. It's very easy to write a test that is now going to always be green, no matter how the code changes.

+ +

A fun fact about the word tautology is it comes from discrete math, which is the topic of my RailsConf talk. If you write out a truth table that shows all the possible inputs and whether or not something will be true or false, depending on what the inputs are, the output column is all true in a tautology, which tells you that no matter what the inputs are, you're going to get true out of that method or function or equation. And so, if this was a Boolean expression in Ruby, you could replace that by hardcoding true and get the same result.

+ +

STEPHANIE: Yeah, that's what I was imagining, a function that just returns true. [laughs]

+ +

JOËL: And that's effectively what you can accidentally write when you're creating a test that is a tautological test is one where you could have just replaced the entire thing with expect true to be true, and it would have the same effect. And, like you said, tests only have value when they fail. And a test that never fails has no value. So TDD has this red, green refactor cycle. I feel like you could probably come up with a cute slogan like that for a testing-after style. So maybe I guess you'd start off you write some code, then you write a test that theoretically passes for it.

+ +

So you start green, but then you want to make sure you see that test fail, so you got to go red and then comment out the code or something. Then comment it back in to see that it goes back to green to make sure that not only does this test fail when the code is broken but also that bringing this test back is what makes it pass, which is an important distinction. So maybe it's a green, red, green, and then maybe refactor. Because one thing that I admired in the style that you were talking about earlier is that even when you test after, you include a refactor step. The test at the end is not the final step in your workflow.

+ +

STEPHANIE: Yeah, that's a really good point. When you said green, red, green, I was thinking of a Christmas garland [laughs] or something like that. But yeah, I do think that stuff gets skipped sometimes. If you are testing after, you're backfilling tests for code you wrote, and at that point, you think you know how it will work, and so you're writing your tests kind of colored with that in mind.

+ +

I like the injecting commenting something out or changing an input or something that you know should make the test fail, just so that you can confirm that you didn't just write a test that expects true to equal true or give you a false positive like that, then go back to green. And as you were saying that, it did make me think like, oh, well, that's like a whole extra step as opposed to TDD where we do just have red, green refactor. We don't have that extra step. But I think the effort is just like put in at a different point in time.

+ +

JOËL: Agreed. It's important that you see the code fail and that you see it pass after the change. The order has changed a little bit, but those two kinds of core elements are present. Kind of by default, you have no choice when you're doing TDD. You have the ability to skip that if you're testing after, but ideally, you incorporate those in a robust test after workflow as well.

+ +

STEPHANIE: Yeah. And I know I mentioned times when I've done something enough or used a pattern enough that maybe I'll just go ahead and implement it and then backfill with tests. And I also recognize that in those moments, I could have done something wrong, that there is some amount of wanting to check that the test failed. And I imagine there is some kind of balance to achieve there between the speed that you get by having that experience and knowing the direction you want to take things and applying a pattern that you've done a lot with being like, oh, we're all human, and sometimes we make mistakes.

+ +

JOËL: In a situation where you feel like you're coding something that you've coded up 100 times before, you're very familiar with this. Do you find that a test after workflow is faster for you?

+ +

STEPHANIE: Hmm, that's an interesting question.

+ +

JOËL: Because I think that's often a motivation. It's like, I don't want to bother, like, I just have the idea. I know what to do. Let me just write that code and get it done.

+ +

STEPHANIE: I think if I were introducing a new route or controller action or whatever, I don't need to go through the cycle of writing a test and it failing because I haven't added the action to the controller yet. It's like I know that that is the next logical step, and so maybe I might skip it there. But if I'm at the point where I'm working with business or domain logic, I think that's where is the value of test writing first because it's like, I passed the framework and passed my tools. And now, I'm working at working through the logic of the business problem itself.

+ +

JOËL: So you're working in maybe slightly larger iterations of that red, green refactor cycle.

+ +

STEPHANIE: Yeah, that's a good way to describe it.

+ +

JOËL: I was recently working on a gem and tried to TDD it from scratch and went with micro iterations. And it was actually really fun, and there was a flow to it. And this is a greenfield side project. And it helped me stay focused. I think it did give me a decent design. I really enjoyed it.

+ +

STEPHANIE: Nice. Was there something satisfying about seeing that green each time and kind of doing that bit of mechanical labor? And I can see how that can feel almost meditative.

+ +

JOËL: Yes. And I think also because this was a problem that I didn't fully know how I was going to solve, TDD helped really focus me on solving sub-parts of that problem, things that I can hold in my head and solve in a minimalistic way and then iterate on.

+ +

STEPHANIE: I like that a lot. You were using that technique, and that really helped for the task at hand, which was, in this case, a bit smaller in scope. I think the way you and I have been talking about TDD has been very realistic and very reasonable. And I'm curious what you think about people who kind of use it as the pinnacle of how you should write code.

+ +

JOËL: I think that's really interesting because TDD is a really wonderful technique, and I wish more people used it. But it's kind of taken on a mystique of its own where if you do TDD or claim to do TDD 100% of the time, now, all of a sudden, you've put yourself on another level. And I think people even who choose for pragmatic reasons not to TDD all the time maybe feel a little bit of guilt or at least feel the need to explain themselves to other people to say, "Hey, I didn't TDD this here. Well, let me explain to you why that's okay, and I'm not a bad programmer."

+ +

STEPHANIE: Yeah, I think we even alluded a little bit to that earlier in the show, and I could hear my hesitancy to be like, oh, I guess I'm going to say this and have all these people hear it. But I think that's a good point that it's okay for you not to do it 100% of the time. That doesn't make you any less of a programmer. Also, the way we've been talking about it also makes it sound like one of those things where it's like you do have to learn the rules before you can break them. And so there is value in learning it and doing it.

+ +

And then you also, after having done it enough, know when you want to use it or when you don't. My advice for folks who haven't really done it before or don't quite see the value of it is just to try it and then decide for yourself. I think at the end of the day, we should all feel empowered to be able to decide how we work best.

+ +

JOËL: It's also really valuable, I think, to maybe pair with someone who is really good at that and to get to see what their workflow is like. Oftentimes, there's almost a hump of getting into it where you are more productive without TDDing because you're not comfortable with the flow or with the techniques. And it takes a lot of expertise to get over that hump where maybe at the expert end of things, you are more productive with it. And on the less expert end, it just becomes a chore that takes up all of your time or ends up giving you results that aren't that great anyway. And so, how do you cross that chasm?

+ +

STEPHANIE: Yeah, that's a really, really great point because, in some ways, when you first get started, it will feel slow. You are unlearning the ways that you have known to code before and trying to do it in a different way. And I really like your advice about trying to pair with someone who has expertise or has been practicing it for a long time. That was my first real introduction to it too. At this point, I had been a few years into my career and hadn't really tried it because it seemed very daunting, and seeing someone else verbalize their process and seeing their workflow was really helpful for me to get on board.

+ +

JOËL: I think what I would like is for TDD to be a tool that is aspirational for a lot of people. If you're new to the technique and you've paired with somebody who's really good at it, and you see the flow that they have and be like, wow, that's really good. I would love to get that incorporated in the way that I work. Rather than a sort of measuring stick for how elite of a programmer you are. There's no sense in shaming people over the tools they use.

+ +

STEPHANIE: Right. Because it should also be accessible, and if you make people feel bad about it, and then it's not accessible to folks.

+ +

JOËL: On that note. Shall we wrap up?

+ +

STEPHANIE: Yeah, let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + It's gardening season! Stephanie swaps seeds with friends and talks about her Chicago garden. Joël recently started experimenting with a dedicated bookmark manager.

+ +

They discuss the aspirational (and sometimes dogmatic) sides of TDD and explore when to test: first or after.

+ +

How does that affect the tests?
+How does that affect the code?
+How does that affect workflow?
+Are you a "better" programmer because you 100% TDD?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 is new in your world?

+ +

STEPHANIE: It's gardening season here in Chicago. So right now, it is like mid-April as we're recording this, and we are just starting to get some warm weather. And this is usually the time that I do my garden planning for the season. And the other week, I went over to a friend's place, and we did a bit of a seed share. So we just each have collected fruit and vegetable seeds and herbs and all that.

+ +

And a really fun way to collect more things to grow is to share with your friends. Seeds are super cheap, but I feel like you could just have like an infinite amount for all of the things that you might want to grow. And so it's really nice to be able to, yes, spread that gardening love around and share with your friends.

+ +

JOËL: I'm imagining something like people trading collectible trading cards but the plant version.

+ +

STEPHANIE: Yeah, exactly. The fun thing that we did, my friend and I, because, you know, you usually get a little envelope with between 10 and 50 or more seeds, and they're super tiny. Some of them are really teeny tiny, like with broccoli, for example, it's like I can't even explain. It's less than a millimeter, I swear. It's very easy to just lose them, so you want to keep them contained.

+ +

But because we are sharing, we don't have a second envelope for the other person to take home with them. And so we actually made our own little envelopes with some origami paper that she had. And we folded it and stapled it and made it very cute. And so I came home with a bunch of these very adorable handmade envelopes with all of my new seeds.

+ +

JOËL: Are you mostly doing vegetables, or are these flowers?

+ +

STEPHANIE: Yeah, so we mostly focus on vegetables for our garden. And we do like to sprinkle some flower seeds in our yard. But that is more just like throw some seeds out there, and whatever happens to them happens. But with the vegetables, we put a little bit more effort because we usually try to have a good yield.

+ +

So in past years, that has meant starting seeds indoors because, in Chicago, we have a shorter growing season than some warmer climate places. And the late summer vegetables like tomatoes, peppers those usually take a little bit longer. So if you want to get a good yield, you might want to start them inside a little early before it's warm enough for them to go outside.

+ +

JOËL: So, do you have a garden plot out in your yard, or do you have a community garden plot? How does that work?

+ +

STEPHANIE: I am really grateful to have a bit of backyard space. And we have three raised beds that we built that cover...I think each one is 3 feet by 10 feet, so quite a good amount of space. Yeah, we're able to grow a lot of food. Our highlights include shishito peppers. That's one that I really like to grow myself a lot because I usually don't see them in stores as frequently. We grow really great eggplants. Tomatoes, obviously, is a pretty popular beginner-friendly vegetable plant. And we like to grow a lot because then we can process it all and can some of it so we can have nice tomato sauce that's homegrown year round.

+ +

JOËL: Hmm, sounds delicious. Do you experiment with the different varieties?

+ +

STEPHANIE: We do. That's also a way that the seed sharing is really helpful because maybe I'll get some varieties of certain vegetables like cucumbers or whatever, but maybe my friend has a different kind. And I think we try to do a mix of growing the varieties that we know we like and then experimenting with some ones that are new to us.

+ +

JOËL: It's hard to beat fresh vegetables in the summer.

+ +

STEPHANIE: Yeah. I'm very excited, especially because during the fall and winter seasons here in Chicago, our local food is a little less exciting. It still can be good, but it's been a lot of root vegetables and the like when we try to eat seasonally in the other season. So I'm really looking forward to stuff that's just juicy and fresh, and it's just one of my biggest joys during the summer. What about you, Joël, what's new in your world?

+ +

JOËL: I've recently started experimenting with a dedicated bookmark manager. This is not because I have been to too many bookstores and have all the free bookmarks they give you. These are the digital bookmarks to websites, and I've been really bad at managing those. I mostly just memorize the keywords I need to Google to get access to that website, which is a terrible way of doing things.

+ +

And then I've got a mix of a few different browsers, which I don't sync, and have a couple of bookmarks. I use a little bit of Pocket, which is a tool by Mozilla. It's all right, but the search capabilities are not very good. So sometimes I'll know it's in there, but I can't find it.

+ +

STEPHANIE: I'm so glad you brought up this topic because I am in a similar boat where I read a lot of things on the internet and have just thrown them all into my top-level bookmarks hierarchy. And that has not really been working for me, either. So I'm really curious to find out how you've been solving this problem.

+ +

JOËL: So recently, I volunteered to be a mentor for first-time speakers at the upcoming RailsConf in Atlanta. And someone was asking me about designing slides, and we were talking a little bit about when should you use maybe a bulleted list on a slide versus when there are other options available. I knew that I had read years ago a fantastic resource on slide design. But try as I could, I could not Google this and get the page that I was looking for.

+ +

This was shared to me by somebody else as part of a conference preparation group years ago, and so I reached out to this person. I was like, "Hey, so do you happen to remember that link you shared with me five years ago?" And this person says, "I do remember it. I don't have the link either."

+ +

STEPHANIE: I've literally been in this exact same situation where I remembered that there was an article that I read, and I remembered exactly who shared it with me or who I talked about it with, and when I couldn't find it, trying to reach out to them and also not being able to find it through them.

+ +

JOËL: So the story ends well because I was able to log into an old Slack group...

+ +

STEPHANIE: Wow.

+ +

JOËL: That had been created for the speakers at this conference and dig through the history. And luckily, I still had access to the group. I was still in that private channel for the speakers. And I found the link, and I was able to share it with others. So that was great. But then I started thinking; I can't keep living this way. I need something better.

+ +

STEPHANIE: It's true. Even though we are expert Googlers as developers, sometimes the search just doesn't get you the thing you're looking for.

+ +

JOËL: So, about this time, I'm scrolling Twitter as one does. And I saw a tweet from Cassidy Williams talking about some of the productivity tools that she's been using this year did a longer article about it. And I started reading it, and a tool that she mentioned there is Raindrop.io, which is an all-in-one bookmark manager. And I'm like, oh, that is exactly, I think, the missing piece of technology in my life right now. So I went up and signed up for it, and so far, it's been pretty good. I'm experimenting with it.

+ +

But I've consolidated a lot of the links that were in my head or in some of these other places, put it in there, categorized them a little bit, tagged them. And hopefully, this becomes a better way so that when I want to reference a link for someone else either in a conversation or as a resource or even for myself, maybe when I'm writing an article, I'm like, oh, I know I read something that would act as a good resource here. I can go to Raindrop and get that article without any of these other shenanigans I had to do this time.

+ +

STEPHANIE: Amazing. What is special about Raindrop as opposed to just your native browser bookmark capabilities?

+ +

JOËL: It has some deeper structuring capabilities in terms of not everything has to be hierarchical. It has tags as well as categories. And I think most importantly, for me, it has search, which seems to be pretty good at surfacing things. It also has some somewhat smart capabilities where it will automatically figure out if the thing that you've linked is an article, or a document, or a video, something like that. So you can filter by these inferred types as well. It has the ability to sync across devices, which browsers can do if you're signed up for them.

+ +

STEPHANIE: Nice. I like that it has that search functionality that you mentioned because I think I'm definitely in the boat of just scrolling through all of my untagged, unorganized bookmarks. And it's really tough to find what I'm looking for, especially if the meta title also doesn't quite tell me exactly the keywords that I'm needing to be scanning for in that moment. So I will definitely have to give it a try.

+ +

JOËL: I believe you can get full-text search if you pay for the premium version (I'm currently trying the free version.), which in theory, could mean that it searches the contents of the article. It's not clear with that. But I do know they save a snapshot of the text of the article.

+ +

STEPHANIE: That's really interesting because then it's almost like a search engine but scoped to the things that you have saved.

+ +

JOËL: Yes.

+ +

STEPHANIE: Nice.

+ +

JOËL: I'll see how that goes, and maybe six months from now, I can talk a little bit about what the experience has been using that.

+ +

STEPHANIE: Yeah, six months from now, you can tell us all about how you have no issues or qualms with how you've been managing bookmarks because everything is working perfectly well for you. [laughs]

+ +

JOËL: JK, I've dropped this whole bookmark thing.

+ +

STEPHANIE: That's true. That's also the flip side of trying out a new tool, [laughs], isn't it?

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So our topic for today is something that we've had in our topic backlog for a while, and I'm excited to talk about it. It's TDD, which I think is a very well-known, potentially controversial topic of discussion in the world of software development. And specifically, we wanted to talk about when TDD is useful and when you actually might also have some value in writing tests afterwards. And in preparation for this topic today, I actually have been TDDing most of my client work this week.

+ +

JOËL: What? You're telling me you don't TDD 100% of the time? Are you even a real developer?

+ +

STEPHANIE: I am a real developer, and I do not TDD 100% of the time. I'm just going to say it. It's on record.

+ +

JOËL: You know what? Me too.

+ +

STEPHANIE: Wow, I'm glad we could clear the air on that one. [laughs]

+ +

JOËL: What percent of the time would you say that you do TDD? In this case, test first as opposed to maybe testing after you've written the code or maybe not testing at all.

+ +

STEPHANIE: Hmm, that's an interesting question. A part of me wants to answer it in my ideal workflow terms. But I think that is less interesting than reality, which is I will usually at least try to test first if I'm feeling like I am up for it. So maybe the percentage is, I don't know, I really couldn't tell you, but I'm just going to throw out 40% of the time [laughs] because that seems pretty, I don't know, reasonable. Sometimes you wake up, and you're just like, I'm not going to do it today. [laughs] And other days, you wake up, and you're like, you know? It sounds like a fun exercise to do for this particular feature.

+ +

So yeah, if I TDD 40% of the time, then I think maybe I write tests after another 40% or 50%. And then [laughs] I'm hesitant to say this on the air, but sometimes you code, and you don't write tests for it and would not recommend it for the majority of your work. But I'm just going to be real here that sometimes it happens.

+ +

JOËL: It's always a trade-off in terms of the work you put in versus the value you're getting out of it. And sometimes, you get very little value out of a test.

+ +

STEPHANIE: Yeah, that's real. It totally depends on what you're doing.

+ +

JOËL: I think one thing that's interesting for us, because we're consultants, so we move from one project to another, is that some projects are set up in a way that they're very test friendly. It's easy to have a testing workflow with them. And then others are just incredibly painful to test because of the way the system has been architected.

+ +

And I think a TDD purist would then tell us that this is a symptom of high coupling or other architectural problems; that's probably true. But also, you don't have time to re-architect the entire system, and so then it becomes a question of trade-offs. Can I test some things easily today? Can I refactor a few things that will make this local change somewhat easier to test? And then, where is it not worth the effort to make something testable?

+ +

STEPHANIE: Yeah, I've definitely struggled with that, where a part of me wanted to test something very thoroughly or even do test-driven development and then ran into some obstacles along the way and having to be realistic about that effort.

+ +

The other thing I was referring to around it depending is also the actual code you're working on. So maybe if you're just writing a script or something to automate some dev workflow, it's okay for that not to be tested. And I also do think that the decision to TDD is very dependent on whether you are writing net new code, or refactoring, or having to deal with legacy code.

+ +

JOËL: That definitely makes a difference. For me, when I'm refactoring in the purest sense, changing structure without changing behavior, in theory, I should not be writing tests for that because there should already be existing tests, and I'm not changing behaviors. So the test suite should prove that my changes did not change behavior. In practice, oftentimes, there is not the coverage that needs to be there. I don't know about you; I feel like I often don't trust the code enough, where I'm a little bit scared to do a refactor if there isn't test coverage. How about you?

+ +

STEPHANIE: I've been running into that issue a lot on my current client project where I've been making an intentional effort to add test coverage before I make any changes because that forces me to really understand how things work because either I read a piece of code and I just can't tell at all. Or I learn later on that I thought I understood something based on the class or the method names, but it turns out that there was actually some nuance in there or side effects or what have you that belied my understanding [laughs] of what it was doing.

+ +

And after a few times of that lack of trust that you talked about popping up, I was like, okay, I think, at least for me, the way that I can feel good about the work that I'm doing is to set myself up for success in that way.

+ +

JOËL: Do you ever find that the code that you write in a test-driven approach tends to end up different than code that you might write with a test-after approach?

+ +

STEPHANIE: Yeah, I think this can actually be answered at a few different levels but let me start with talking about how I like to practice TDD. If I'm given a user story, I usually try to work outside in. So I will write a feature or acceptance test and that involves testing how the user would interact with our application.

+ +

At that point, I will usually go with the most naive implementation to get the test passing, and so it probably won't look pretty. In a recent case, I was adding a new parameter to a controller, and I just put everything in the controller to get the test green. [laughs] And then, at that point, is when I gave that code a second pass and looked for areas to extract where I could.

+ +

JOËL: That refactor step and the red, green refactor cycle is really important.

+ +

STEPHANIE: Yeah, absolutely. I think that is where I find TDD to be the most valuable from that higher-level perspective. And I know that there are different schools of thought on this. But that helps ensure that at least I have written the code to make the feature work the way that I was hoping. And I use TDD less for driving design decisions just because I like to have something to react to that is helpful for me rather than having a blank slate of, okay, let me write a test with an idea about how an object's interface will look. And so that's what works for me.

+ +

So I do think it's kind of a mix of like from an acceptance test level; I am at least writing code that I know works, but the shape of the code for me is less determined by how I test.

+ +

JOËL: So when you're looking at code that you've written six months down the line, you generally can't tell the difference whether it was test-driven or written first and tested after.

+ +

STEPHANIE: That sounds right. That's just how my process works. In fact, I think recently we, to go on a quick tangent, we talked about writing conference talks, and I think I even mentioned for me the process is looking at the thing and then revising. And I think that the design driving element of TDD that a lot of people like is a bit less effective for me personally.

+ +

JOËL: Hmm. Would you say that TDD does not impact the shape of the code that you end up creating in response to the tests? Or when you're talking about design, are you mostly thinking in terms of the interface that you would have in the test itself, like, what arguments the constructor takes or things like that?

+ +

STEPHANIE: I think I was talking more about the latter, the interface, the construction arguments. When I do test afterwards, I also will notice the way the setup of my test how that is feeling. And if it is feeling a bit unwieldy or is a bit complicated, that will cue me to maybe take another pass at the code itself. So that's actually one way that testing after can signal to me a way that I might want to change my code.

+ +

JOËL: Okay, so you're getting some of those pressures that you get from testing, but you respond to them in a like second path?

+ +

STEPHANIE: Yeah, I think so. I'm curious how you TDD and whether you notice changes in how your code looks.

+ +

JOËL: I think there are a couple of things that TDD does in my workflow that are really nice. One is it keeps me focused in terms of getting the work done because you're just following from one failure to another. It also keeps me focused in terms of scope. It's really easy for my engineering brain to be like, oh, we could totally do this thing and all that, and it's like, no, that's not needed to solve the problem at hand.

+ +

Because in TDD, you try the smallest solution that will solve your problem, and then you will refactor it to make it maybe nicer to work with. But you try not to add new behavior that's not required in order to pass the test, and that can be a really helpful forcing function for me.

+ +

STEPHANIE: That's interesting because I was just thinking about how sometimes, at least with the outside-in approach that I was talking about, I will find that the scope of the ticket is too big as I make changes to get the desired quality of the code that I want.

+ +

Like I mentioned, the naive implementation, like, sure, maybe everything is in a controller, but as soon as I'm starting to do that second pass, and I want to maybe change another class and to make it work for my needs, I will notice it start to sprawl a little bit. And that is usually a signal to me that, like, oh, maybe what I need first is just refactoring the objects that I'm hoping to use to get the desired implementation. And that ends up being a separate PR that I do first to then set myself up for making the change.

+ +

JOËL: The classic make the change easy before you then go and make the easy change.

+ +

STEPHANIE: Right. But that does mean that that initial feature test that I wrote won't ever be green. So I do have to kind of like back out of making that change and just be like, okay, today is not the day [laughs] that I'm going to get this feature working.

+ +

JOËL: There are some times where I'm in a situation like that, and I will kind of recognize, oh, there's a refactor step that's happening right now as a sort of subtask. And so, I will make that refactor change that I need to and then commit only those files that were a part of that refactor and may be included as part of the PR with the feature change or maybe push it up and make it its own PR.

+ +

But depending on what the refactor is, oftentimes, I can kind of do it sort of all more or less continuously but decide once I've done that refactor step, okay, commit time but only those files for the smaller set of changes, and then keep moving with that outside-in approach.

+ +

One thing I have noticed about the style of code that I tend to produce when I TDD versus when I don't is how I will tend to decouple things. And so because coupled code is really annoying to test in isolation, TDD sort of forces me to do more dependency injection, passing objects to others. It will often force me or maybe not force me, but it gives me that wholesome pressure to maybe separate HTTP requests from more of the business logic in my code, which otherwise I might completely intermix because it's just so convenient. Even certain things like class methods, I might tend to overuse them or use them more if I'm not test driving than if I were.

+ +

STEPHANIE: When you talk about coupling, I'm curious, do you end up mocking a lot in the tests that you are writing to drive your development?

+ +

JOËL: No, but if I'm testing after, I probably will. Mocking, I think, is a sign of coupling generally. In tests where you're just passing objects to each other, generally, you can get away with passing in a test double or something, whereas if you're hard-coding dependencies, you often have to mock.

+ +

STEPHANIE: Got it. That makes a lot more sense now. I think that does require a bit of thought upfront about what kinds of objects you might need and what they would provide for you in the thing that you're testing.

+ +

JOËL: Yes. There's definitely a phase where let's say; I'm testing some kind of third-party integration; I'm just kind of trying to do it all in one object that has a mix of business logic and some HTTP request stuff. It gets really annoying as we're adding...maybe the first feature is okay. I use WebMock, and I stub out a request, and it's good. And then the second one, I feel like I'm kind of duplicating that. And then the third one, I've got to deal with retries.

+ +

So now I've got to go back to the first one and add some two or three WebMocks because now we've got exponential backoff code that's happening here. And this new feature broke the old tests. And it just becomes this really annoying thing to do. And then I might start thinking, okay, how do I separate these two things? I have one place where I test the HTTP logic, the exponential backoff, the what to do if I get a 404 from the API. And then, separately, I can just have the business logic and test all of those branches there without having to touch any of the HTTP stuff.

+ +

I think you could get there from a few different paths. So you could get there by sort of following a lot of classic design principles, things like SOLID, because they kind of converge on that general idea as well. You could even get there if you took more of a functional programming approach where you are really good at separating side-effectful code from, I'm going to use the term loosely here, pure functions.

+ +

I've heard some people make the distinction between IO versus non-IO in code and how that affects the types of tests that you write for them. And separating those two is a thing that you might do, even if you weren't writing tests at all, if that's a design principle that you know to follow.

+ +

STEPHANIE: Yeah, that's a great point. I was thinking, as you were talking about your approach for handling that potential feature with talking to a third party, that I've heard that particular task or problem in software development used as an example for a lot of those different techniques or strategies that you mentioned. And I suppose TDD really is just a tool, and it doesn't replace your experience or intuition.

+ +

And earlier, when we were talking about times that you don't do TDD, I will have to say that if I am doing something that I've done many times before, I feel confident enough that I don't need to lean on that red, green refactor cycle. At that point, it's more muscle memory. And maybe I do forget a step along the way, but I have the experience to know how to debug that or to see the error and know exactly what it was that I did wrong. And in that case, I am tapping into something different than using TDD.

+ +

JOËL: I think definitely, for a lot of things now, there are patterns that I have learned where even if I weren't TDDing, I might do a third-party integration using this pattern because I've done it via TDD enough to know that this is a structure that I find works very well in terms of the coupling of things. And then maybe if I want to fill in some tests afterwards, then I'll thank my past self that I'm using a pattern that plays nicely with that. One thing that I do notice happens sometimes is that when people add tests after the fact, they will add tests that are green but that don't necessarily fail if the code breaks. Have you ever seen that?

+ +

STEPHANIE: I have seen that before. In fact, I just saw it recently where we had a false positive test. And I made a change expecting the test to fail, and it didn't, which is not great because the value that tests have are when they fail, you want to be alerted when something goes wrong. Just because they're green doesn't mean that everything works. It just means that they didn't detect a problem. And in this particular case, I don't know if the developer who wrote this test had TDDed or not. But I did notice that in the test, we were mocking a method, and that ended up being the cause of the false positive.

+ +

JOËL: I'm always a little bit skeptical of mocks because I feel like I've seen so many either brittle tests or tests that will succeed all the time come out of mocks. I don't know if you've ever heard the term tautological test or a test that is a tautology.

+ +

STEPHANIE: No, I haven't. What does that mean?

+ +

JOËL: In its sort of most basic sense, it's a test that is always green no matter what the output is. Some people think of it more in terms of self-referential tests, like, oh, a thing equals itself, which, yes, it does, and those tend to be always green. But it's not always self-referential. It can be some other subtle ways. Typically this happens when mocking or specifically if you mock the system under test. It's very easy to write a test that is now going to always be green, no matter how the code changes.

+ +

A fun fact about the word tautology is it comes from discrete math, which is the topic of my RailsConf talk. If you write out a truth table that shows all the possible inputs and whether or not something will be true or false, depending on what the inputs are, the output column is all true in a tautology, which tells you that no matter what the inputs are, you're going to get true out of that method or function or equation. And so, if this was a Boolean expression in Ruby, you could replace that by hardcoding true and get the same result.

+ +

STEPHANIE: Yeah, that's what I was imagining, a function that just returns true. [laughs]

+ +

JOËL: And that's effectively what you can accidentally write when you're creating a test that is a tautological test is one where you could have just replaced the entire thing with expect true to be true, and it would have the same effect. And, like you said, tests only have value when they fail. And a test that never fails has no value. So TDD has this red, green refactor cycle. I feel like you could probably come up with a cute slogan like that for a testing-after style. So maybe I guess you'd start off you write some code, then you write a test that theoretically passes for it.

+ +

So you start green, but then you want to make sure you see that test fail, so you got to go red and then comment out the code or something. Then comment it back in to see that it goes back to green to make sure that not only does this test fail when the code is broken but also that bringing this test back is what makes it pass, which is an important distinction. So maybe it's a green, red, green, and then maybe refactor. Because one thing that I admired in the style that you were talking about earlier is that even when you test after, you include a refactor step. The test at the end is not the final step in your workflow.

+ +

STEPHANIE: Yeah, that's a really good point. When you said green, red, green, I was thinking of a Christmas garland [laughs] or something like that. But yeah, I do think that stuff gets skipped sometimes. If you are testing after, you're backfilling tests for code you wrote, and at that point, you think you know how it will work, and so you're writing your tests kind of colored with that in mind.

+ +

I like the injecting commenting something out or changing an input or something that you know should make the test fail, just so that you can confirm that you didn't just write a test that expects true to equal true or give you a false positive like that, then go back to green. And as you were saying that, it did make me think like, oh, well, that's like a whole extra step as opposed to TDD where we do just have red, green refactor. We don't have that extra step. But I think the effort is just like put in at a different point in time.

+ +

JOËL: Agreed. It's important that you see the code fail and that you see it pass after the change. The order has changed a little bit, but those two kinds of core elements are present. Kind of by default, you have no choice when you're doing TDD. You have the ability to skip that if you're testing after, but ideally, you incorporate those in a robust test after workflow as well.

+ +

STEPHANIE: Yeah. And I know I mentioned times when I've done something enough or used a pattern enough that maybe I'll just go ahead and implement it and then backfill with tests. And I also recognize that in those moments, I could have done something wrong, that there is some amount of wanting to check that the test failed. And I imagine there is some kind of balance to achieve there between the speed that you get by having that experience and knowing the direction you want to take things and applying a pattern that you've done a lot with being like, oh, we're all human, and sometimes we make mistakes.

+ +

JOËL: In a situation where you feel like you're coding something that you've coded up 100 times before, you're very familiar with this. Do you find that a test after workflow is faster for you?

+ +

STEPHANIE: Hmm, that's an interesting question.

+ +

JOËL: Because I think that's often a motivation. It's like, I don't want to bother, like, I just have the idea. I know what to do. Let me just write that code and get it done.

+ +

STEPHANIE: I think if I were introducing a new route or controller action or whatever, I don't need to go through the cycle of writing a test and it failing because I haven't added the action to the controller yet. It's like I know that that is the next logical step, and so maybe I might skip it there. But if I'm at the point where I'm working with business or domain logic, I think that's where is the value of test writing first because it's like, I passed the framework and passed my tools. And now, I'm working at working through the logic of the business problem itself.

+ +

JOËL: So you're working in maybe slightly larger iterations of that red, green refactor cycle.

+ +

STEPHANIE: Yeah, that's a good way to describe it.

+ +

JOËL: I was recently working on a gem and tried to TDD it from scratch and went with micro iterations. And it was actually really fun, and there was a flow to it. And this is a greenfield side project. And it helped me stay focused. I think it did give me a decent design. I really enjoyed it.

+ +

STEPHANIE: Nice. Was there something satisfying about seeing that green each time and kind of doing that bit of mechanical labor? And I can see how that can feel almost meditative.

+ +

JOËL: Yes. And I think also because this was a problem that I didn't fully know how I was going to solve, TDD helped really focus me on solving sub-parts of that problem, things that I can hold in my head and solve in a minimalistic way and then iterate on.

+ +

STEPHANIE: I like that a lot. You were using that technique, and that really helped for the task at hand, which was, in this case, a bit smaller in scope. I think the way you and I have been talking about TDD has been very realistic and very reasonable. And I'm curious what you think about people who kind of use it as the pinnacle of how you should write code.

+ +

JOËL: I think that's really interesting because TDD is a really wonderful technique, and I wish more people used it. But it's kind of taken on a mystique of its own where if you do TDD or claim to do TDD 100% of the time, now, all of a sudden, you've put yourself on another level. And I think people even who choose for pragmatic reasons not to TDD all the time maybe feel a little bit of guilt or at least feel the need to explain themselves to other people to say, "Hey, I didn't TDD this here. Well, let me explain to you why that's okay, and I'm not a bad programmer."

+ +

STEPHANIE: Yeah, I think we even alluded a little bit to that earlier in the show, and I could hear my hesitancy to be like, oh, I guess I'm going to say this and have all these people hear it. But I think that's a good point that it's okay for you not to do it 100% of the time. That doesn't make you any less of a programmer. Also, the way we've been talking about it also makes it sound like one of those things where it's like you do have to learn the rules before you can break them. And so there is value in learning it and doing it.

+ +

And then you also, after having done it enough, know when you want to use it or when you don't. My advice for folks who haven't really done it before or don't quite see the value of it is just to try it and then decide for yourself. I think at the end of the day, we should all feel empowered to be able to decide how we work best.

+ +

JOËL: It's also really valuable, I think, to maybe pair with someone who is really good at that and to get to see what their workflow is like. Oftentimes, there's almost a hump of getting into it where you are more productive without TDDing because you're not comfortable with the flow or with the techniques. And it takes a lot of expertise to get over that hump where maybe at the expert end of things, you are more productive with it. And on the less expert end, it just becomes a chore that takes up all of your time or ends up giving you results that aren't that great anyway. And so, how do you cross that chasm?

+ +

STEPHANIE: Yeah, that's a really, really great point because, in some ways, when you first get started, it will feel slow. You are unlearning the ways that you have known to code before and trying to do it in a different way. And I really like your advice about trying to pair with someone who has expertise or has been practicing it for a long time. That was my first real introduction to it too. At this point, I had been a few years into my career and hadn't really tried it because it seemed very daunting, and seeing someone else verbalize their process and seeing their workflow was really helpful for me to get on board.

+ +

JOËL: I think what I would like is for TDD to be a tool that is aspirational for a lot of people. If you're new to the technique and you've paired with somebody who's really good at it, and you see the flow that they have and be like, wow, that's really good. I would love to get that incorporated in the way that I work. Rather than a sort of measuring stick for how elite of a programmer you are. There's no sense in shaming people over the tools they use.

+ +

STEPHANIE: Right. Because it should also be accessible, and if you make people feel bad about it, and then it's not accessible to folks.

+ +

JOËL: On that note. Shall we wrap up?

+ +

STEPHANIE: Yeah, let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7W7Ii84G + + ]]> + + Joël Quenneville + Stephanie Minn + + + 380: Remote Work Life + https://bikeshed.thoughtbot.com/380 + a7d5ce05-151b-48bd-9920-5c7391d4c73f + Tue, 18 Apr 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël has been working on his RailsConf talk about various aspects of discrete math useful in day-to-day work as a developer and going deep on some concepts from propositional logic and Boolean algebra, particularly DeMorgan's Laws, which explain how to negate a compound condition. Stephanie attended a meeting with a fun "Spicy Takes" topic. She gave a short talk on how frictionless technology may not be the best path forward and tried to argue in favor of more friction in our software. + +Together, they talk about ways they've made remote work work for them and things they'd like to try/do differently. + 32:19 + no + + + Joël has been working on his RailsConf talk about various aspects of discrete math useful in day-to-day work as a developer and going deep on some concepts from propositional logic and Boolean algebra, particularly DeMorgan's Laws, which explain how to negate a compound condition. Stephanie attended a meeting with a fun "Spicy Takes" topic. She gave a short talk on how frictionless technology may not be the best path forward and tried to argue in favor of more friction in our software. +Together, they talk about ways they've made remote work work for them and things they'd like to try/do differently. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Taskmaster - Do Not Avoid Not Making the Bell Not Ring (https://www.youtube.com/watch?v=8iEnaOKGOFw) +The Dark Side of Frictionless Technology (https://newsletters.theatlantic.com/galaxy-brain/6328fa97bcbd490021b314da/personal-tech-obsolete-user-experience/) +Is Tech Too Easy to Use? (https://www.nytimes.com/2018/12/12/technology/tech-friction-frictionless.html) +How to Do Nothing by Jenny Odell (https://www.penguinrandomhouse.com/books/600671/how-to-do-nothing-by-jenny-odell/) +Rubber duck Debugging (https://rubberduckdebugging.com/) +Schedule Shutdown, Complete Bike Shed episode (https://www.bikeshed.fm/310) +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: I've recently got accepted to speak at RailsConf. And I've been working on my talk about various aspects of discrete math that are useful in day-to-day work as a developer and going really deep on some concepts from propositional logic and Boolean algebra, particularly the DeMorgan's Laws, which explain how to negate a compound condition. +So if condition one or condition two, if you want to negate that thing as a whole, you can't just negate both of the conditions individually. You will get a totally different result, and that's a really easy mistake to make. I don't always memorize exactly what to do. But I know enough in the back of my head when it comes up on a pull request to check it out and be like, oh, there's a negating of a compound condition here. Pay closer attention. There might be a bug. +STEPHANIE: So are you saying that when you negate each condition individually, you get the opposite result that you want? +JOËL: It's not opposite, just different. +STEPHANIE: Just different, okay. +JOËL: So De Morgan's Laws tell us that if you want to negate the compound condition as a whole, you negate the individual clauses but then also have to flip the sign in the middle. So if you're trying to negate condition one and condition two, it becomes not condition one or not condition two. +STEPHANIE: I see. Wow, that's confusing because you'd think that there are just two outcomes, but really there are a lot more. +JOËL: Yes. +STEPHANIE: And that reminds me of when we've talked about on the show combinatorial explosions, which I know is a favorite topic of yours. +JOËL: Combinatorics will definitely come up in the talk as well. It's sometimes hard to hold all the possibilities in your mind. And so I'm a big fan of truth tables to visualize what's happening and to be like, oh, when I make this thing negative, now all these things flipped into false when I want them to be true and vice versa. Okay, I've got a weird inverse going on here or something like that. +STEPHANIE: I have a funny thing to share with you. Joël, have you ever heard of the show "Taskmaster"? +JOËL: No, I'm not familiar with this. +STEPHANIE: Okay, it's a British reality competition comedy show where the contestants are usually famous British actors or comedians. And they have to do just really insane, silly tasks. And usually, one of the more iconic ones is to eat as much watermelon as you can in a minute. But they're just presented with a whole watermelon without any tools or anything [chuckles] for cutting it up. And it's just very funny and very delightful. +And one of the tasks that I watched recently was a situation where they had to follow these instructions, and the instructions were to do the opposite of the following statement: "You must under no circumstances not avoid not making the bell not ring." And they had a bell right in front of them. And so they had to figure out if they were supposed to ring the bell or not ring the bell based on those instructions and within a certain time limit. If they had the math skills that you were talking about, [chuckles] perhaps they would have been able to figure it out. +JOËL: I would absolutely want to write that out as a more formal logic thing. Otherwise, it becomes...you just mess with your head. You get in almost a recursive space where like, wait, not not, does that cancel? Does it stay? And yeah, it gets really messy. +STEPHANIE: Yeah, it was very funny to watch them try to figure that out on the spot. And I think there's a clip of it on YouTube that we can link [laughs] for our listeners. +JOËL: That's amazing. What's new in your world? +STEPHANIE: So last Friday...you and I are on the same team at thoughtbot called Boost, and every two weeks, we get together as a team, and we have a meeting where anyone can propose a topic. It's just a nice space for people to see each other and hang out. And one of our co-workers hosted that meeting and he chose the topic of spicy takes and asked for volunteers to sign up and give a quick couple of minutes lightning talk on the spicy take that they had. And it was so fun. +We got some takes on how REST is not the best. We got some opposing opinions about Tailwind. And I ended up giving a short, little talk on how frictionless technology may not be the best path forward and was trying to argue in favor of a little more friction in our software. +JOËL: What would friction look like in this scenario? +STEPHANIE: I was really interested in exploring how by making our software so easy for users we eliminate some amount of attention and mindfulness into using technology. So I think for me friction would be presenting the user with more autonomy and choice rather than making decisions on their behalf. +I don't totally know what that looks like, but I do know that things like one-click ordering or autoplay those things have made me bristle a little bit in certain contexts and wondering what other options do we have available to us to provide the features we want to provide to our users but maybe not in a way that is so convenient and easy to use that we lose that aspect of knowing what we're doing with our technology. +JOËL: I feel like knowing you, you've probably read a couple of articles and some books on this topic. And if I wanted to dig more into this idea of a little bit more mindfulness or introducing a little bit of friction into my software world, where would you recommend I go to read? +STEPHANIE: Yeah, that's a great question. When I was preparing the talk, I referenced a few articles that I'll link in the show notes, one from The Atlantic and one from The New York Times. And I liked them because one of them presented what I was getting at, the more philosophical approach of like, what does it mean for our attention to be? And what does it mean for our technology to be too easy? And the other one had more practical use cases for security and technology misinformation and abuse. So I liked that those two things complemented each other equally. +And then I also would plug a book called "How to Do Nothing: Resisting the Attention Economy" by Jenny Odell. I read that book last year and really enjoyed it. And she talks a lot about just the current technology landscape and what we, as consumers and users, can do to reframe our relationship with it. And I think that book is for people who use technology in general. But as developers, I think we are in a unique position to extend that train of thought right into the things that we develop. +JOËL: You know, a place where I do appreciate friction is in the physical world. If there weren't any friction, my chair would not stay put on the ground. My fingers would not press on the keyboard. So we need friction to be able to do our jobs. So you work from home; I work from home because thoughtbot is now fully remote. How has that been for you setting up a work environment in your home? +STEPHANIE: So I've actually been working from home since 2019. So about a year before the pandemic, I had moved to Chicago and was still working for a company in New York. And so that was when I started working from home, and then have just been doing that ever since. So I think I have now really figured out a setup that works for me. I've been doing it for four years now, which is pretty wild to me when I think about it. It's interesting because I actually really enjoyed going into an office. And there are parts of that that I really miss. But I think I have just gotten used to it and have a setup that works well for me. +JOËL: Are there any things that you like to do for your environment to help get yourself into maybe the zone a little bit more easily? +STEPHANIE: Yeah. So my workspace is a separate room from the rest of my apartment, which is also really just one big room. [laughs] It's kind of like a loft-style situation, so I don't really have doors. But I am in what we call the sunroom, and it's actually kind of like an enclosed porch with a big window and lots of plants. And it's in the back of the apartment. +And so whenever I'm in this space, it's because I'm working. And I think having that separation of home and work is really helpful. Because when I step into this space, I'm like, okay, now I'm at work, and I don't have as many distractions as I would if I were working in a different space like a bedroom or the living room. +JOËL: I have to say whenever you're on a video call, the plants around you are iconic. +STEPHANIE: Oh, thank you. Yeah, it's been a nice conversation starter. When I'm meeting a new person, they usually comment on the plants, and I can give them a little show and tell. And that's been really nice. +JOËL: I feel like a lot of people who work from home have put a lot of work into creating fun backgrounds for their video calls. Maybe they're setting up a cool bookcase behind them or plants. People like to put something behind them that will make things interesting on a video call in a way that maybe we didn't need to when it was just a conference room and in an office. +STEPHANIE: Yeah, absolutely. I was just on a meeting with someone who had a big pile of tiny rubber ducks. So he was also a developer and, I guess, had just amassed this very delightful rubber duck collection, and it was just in the background. And we got to joke about it for a little bit, and that was really fun. +JOËL: Are these rubber ducks meant to be used during debugging sessions? +STEPHANIE: Yeah, exactly. +JOËL: So I'm in a somewhat different situation from you in that I don't have a separate room to set up a home office. I've resisted doing anything in my bedroom. Like you said, it's good to have that separation. So I work more in my kind of living room-dining room space. And something that I found is really valuable for me has been movement. So say I work an hour in one part of the room, and then I switch to a different place. And it's going to be maybe a different posture. +So I'm working in a solid chair table for a while, and then maybe I switch to more of an easy chair situation. That I think has been really helpful for me ergonomically during the day is just making sure that I'm not always in the same position constantly all the time but actually incorporating change in movement throughout my day. +STEPHANIE: I like that a lot. I actually do also end up sitting at my dining room table sometimes for a change of scenery. It's funny because there was a while when...when I'm at my office desk, I have a standing desk. And so usually if I'm in a meeting, I would be at my desk and people would see me standing. And I think someone at some point mentioned like, "Wow, you seem to stand all day." And I was like, "Oh, well, when I'm not in a meeting, that's when I'm sitting on the couch or a lounge chair or something." [laughs] I'm curious, though, because you are working in your dining living space if it's been harder to separate work and home life. +JOËL: I think it was definitely an adjustment, but it's a thing that I learned to do. And I still try to keep some amount of separation, which is why I don't set up an office space in my room. But I've also gotten to the point where now that I work from home, I find myself leaving home much more frequently after the workday ends. I was surprised just how much social interaction you get just by default being in an office around people all the time. When you're at home all day, even if you're on calls, it's not the same. +And so I've found myself more and more to stay in a healthy emotional, mental space, leaving the home in the evening to go do things with friends or with other people. And so even though I am an introvert who prior to working from home preferred to stay at home more evenings than not, I've started living almost more of what people would assume is an extrovert lifestyle where I'm out every evening. +STEPHANIE: Wow, that's so interesting because I'm the opposite; where when I was commuting and going to an office, I found it much easier to stay out. I would just go to a bar or a restaurant after work. Whereas now it's a bit harder because I'm not already out and about in the world, and also I am in my comfy pants, and I'm just like, oh, I have to go out? I don't know if I'm up for that. [laughs] +Though I also really...I think the downside is that I have been really missing some of that human contact. And there are weeks where I'm like, dang, I really didn't talk to people in the world very much. So it's actually been a bit of a bigger obstacle for me to find the energy to see people in the evenings after work. +JOËL: It helps to make plans. +STEPHANIE: Yeah, that's a good idea. +JOËL: Or you can have people come to you. You mentioned you were doing that soup club. +STEPHANIE: I did, yeah, back when the winter was first starting. I mentioned on the show that I was having people over for soup on Friday nights, and that was really great. That was nice because then I was like, okay, I have to sign off by 5:00 p.m. so I can start making the soup. [laughs] +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So you mentioned that sometimes it's hard to leave the home because you're kind of in your comfy clothes, and you don't want to kind of get dressed to go out. Has working from home kind of changed the way you tend to dress? Do you ever do the thing where it's like, oh, I've got the formal top and then just sweats? +STEPHANIE: Yeah. Like business on top and party in the bottom [laughter] or something like that is the phrase. My habits around getting ready in the morning have definitely changed; where I don't put as much energy or effort, or time into it as I did when I was working in an office. And that has been nice because I get that time back, and that is really valuable to me. +Yeah, I'm also usually just in soft pants. [laughs] That has definitely been a very positive impact on my life. And I do try to make an effort to go out for coffee. And when I do that, I'm just like, yeah, how I go out is how I go out. I don't really mind. I'm very comfortable going out however I'm feeling that day. But I think getting the time back actually has been really important to me. +JOËL: Hmm, I think for me, interestingly, that's become an interesting way to build a little bit of separation from personal life and work life. So I'm making a point to put on...I don't know how you describe it. I was going to say real pants, but it's not like sweats are not real pants. But yeah, I will put on the kind of thing that I would put on to go in the office. And for me, that's kind of a...it's a start to the day. It's a start to being more serious and transitioning to more of a work mindset. +STEPHANIE: Yeah, absolutely. +JOËL: As opposed to on the weekend, if I'm just hanging around in the same space, but I'm dressed differently, I don't feel like I'm in work mode. +STEPHANIE: Yeah, yeah, that's fair. I've definitely noticed your fun sweaters that you wear in video calls and stuff. So I really appreciate that; yeah, you are just putting on clothes that make you feel like you're ready to dive into the work week. I'm really curious, do you find yourself being more productive working from home than you were working in an office? +JOËL: I would say it's about even on average. There are probably days where more or less on one side or the other, but I would say it's similar. +STEPHANIE: I think I'm actually much more focused at home. And I know that this is not true for everyone because I was chatting with a friend, and she was asking, like, "How do you stay focused at home?" She was telling me that she gets so distracted by all the things that she could be doing in her home life. And for me, because I really enjoyed the social aspect of being in an office, I found myself wandering into the kitchen not infrequently to go get some snacks, and oh, running into this person and having a little chat. +And I think my presence also, I was available for other people to come to me and start a conversation or ask to go on a walk. And I think I actually really needed that external push to take breaks. Because now that I'm working from home by myself, I definitely just get into some rabbit holes, and it's tough for me to resurface. +JOËL: Let me fix one more error, and then maybe the test will be green. Oh, that didn't fix it, but I'll bet one more would fix it. And keep doing that until it's like, oh, well, I'm going to push off my break for another 30 minutes, oh, another hour. And it's like, you know what? I'm just going to finish my day. +STEPHANIE: That literally happens to me all the time. The lunchtime break is tough because I definitely will delay that by 15 minutes and then 30 minutes, and then oh no, it's like 2:00 p.m. Okay, let me just eat a snack, then. And then keep going until I finish whatever task, and then end up wishing that I had made a little more of an effort to take a real break. +JOËL: Yeah, I was having a conversation recently with someone about how it's often easier to make space for other people than for yourself. So if somebody is like, "Hey, I want to take a break. Do you want to go take a walk?" You might be like, "Sure." Maybe I wasn't quite in a place where I wanted to take a break, but I'll make the time for you. +Whereas when it's like, you know what? My body or my mind is telling me I need to take a break, but this test isn't green yet. So I'm going to almost deny myself here for the, I don't know, the good of the mission, whatever. It's not really a noble sacrifice. It ends up hurting you and the project in the longer run, but it's so much easier to do that. +STEPHANIE: Wow. Okay, yeah, that really resonated with me because I find myself in situations where I don't think that I can take a break because I'm like, oh, I have all these red tests, and I need to get them in a place where I feel comfortable stepping away. But if someone asked me like, "Hey, I'm at your door. Let's go for a walk," I could just put it away and go for a walk and have a great time. And I would like to be able to do that for myself when I don't have someone prompting me. +JOËL: There's something I really appreciated that someone who used to be at thoughtbot would do is this person would go for a walk every afternoon without fail and would drop a line in the Slack channel being like, "Hey, I'm stepping away for a walk." And, I mean, yeah, it's nice to know that, okay, this person's not reachable for the next 15 minutes or whatever. But that's not really, I think, the value that I got from it. It was more of seeing somebody else taking a break and it being a reminder for me too to be like, you know what? Maybe I should take a walk as well, like, it might be time for a break. +STEPHANIE: Yeah, I like that a lot. I think it's kind of ironic that I have quote, unquote, "optimized" my setup so much that I don't get distracted that I miss out on the friction laughs (A little call back to earlier.) that I would like to, yeah, call more mindfulness to how I'm physically feeling, not even physically but also emotionally and intellectually and being prompted, like I said, externally because I am realizing now that I really need that. +JOËL: And at least for us here in North America, it's now starting to be spring. And so I think sometimes winter can be its own barrier to be like, you know what? I should go and take a walk. I don't know if I want to put on all the layers and my boots and all of that and deal with the snow. Whereas now it's like, just walk out and there will be flowers and trees covered in blooms. And it's going to be amazing. +STEPHANIE: Yeah, I'm really looking forward to that. I agree; I think when the weather is nice, that is definitely a bigger motivator for me because there's more to enjoy and more to look at. And I love being outside. When you do step away to take a break, what do you do in your home or outside your home? +JOËL: So I'm a big fan of taking a walk. I live in a dense, walkable neighborhood, Downtown Boston. And so just walking around a few blocks is a great way to get a little bit of fresh air, just get some motion going because I've been sitting around for a long time. It's a lot of natural beauty as well. A lot of people have gardens, and there are a lot of trees planted along the roads. So it's just a really pleasant way to, in some ways, connect with a little bit of nature and be outside and reset. Do you find yourself when you're looking for a break gravitating outwards or inwards in your space? +STEPHANIE: I like to make myself a snack, a cup of tea. Sometimes if I'm reading a good book, I'll get into the book for 20 minutes. And sometimes, if there's nothing to pick up, maybe I'll find myself on YouTube and watch a short little thing just to reset and have some fun. Sometimes I'll try to tackle some dishes. I think the other thing with working from home is that I now create more mess in my home. [laughs] I don't know if it's the same with you. But I, yeah, try to keep on top of that so that I don't have to do it later in the evening. +JOËL: I think one of the things that's really nice about working from home is the ability to cook more because you're in that space. So I've found myself oftentimes more on my lunch break, maybe prepping some things for a stew or something that's going to braise, and then just having it sit on the stove all afternoon. And like I said, maybe a really quick break is just you get up, go check the pot on the stove, and you turn the heat down or stir it a little bit and then get back to work. +STEPHANIE: Yeah, I like that a lot. I do that, too, with a pot of rice or beans or something like that. I also am definitely making my own food for lunch a lot more just because, being at home, you have your whole kitchen and fridge available to you, and I feel less pressure to get all that done the night before. +JOËL: Right. I think I've been trying to incorporate a little bit more physicality to my breaks recently. And one thing that I've done for shorter breaks...if it is a longer break, it is nice to go out and take a walk. But for shorter breaks, I set up a pull-up bar, and I just try to go and do a set of pull-ups there. And I'm not great at it, so it's not like I'm there for 10 minutes doing 100 pull-ups. But it's a nice way to go from a very static mental mode to a quick break that just totally resets you into this active physical space. +STEPHANIE: Yeah, I like that a lot because something like that requires your full attention and physical effort in that moment. So it's not like you can still really be thinking about work while you're in the middle of doing a pull-up, at least [laughs] that's my interpretation of [laughs] how you take those breaks. +JOËL: I'm curious, are there any other kinds of lifestyle elements that you've changed or customized to help you have a better working-from-home experience? +STEPHANIE: There was a past Bike Shed episode hosted by Steph Viccari and Chris Toomey, and I can't remember exactly what it was that they were talking about. It must have been working from home-related because Chris had mentioned a ritual that he had when he was finishing his workday where he would close his laptop and say, "Schedule shutdown complete." And I've been thinking about that a lot and trying to do a similar thing of just verbalizing, "I'm done with work now," to make it true. [chuckles] +Otherwise, if I don't, I can find myself gravitating towards my laptop when I have a thought. Like, I have an idea like, oh, I just thought of a way to try to debug that test or whatever. And then I'll want to go back just really quickly to write it down on my work computer so it's there for me when I come back. But if I've said, "I am done with work today," that means I'm trying not to reopen the work laptop, and then I'll try to jot it down somewhere else. And that has been really helpful. +JOËL: So, setting like an emotional boundary. +STEPHANIE: Yeah, an emotional boundary that almost becomes physical in a way because when I was working in an office, I would never take my work stuff home with me, so I physically could not access it. And since I can't do that now, by verbalizing it, it's almost as if I've created a boundary in my head. +JOËL: That's really powerful, the impact that you can have just by sort of verbalizing something. +STEPHANIE: I will say that I also don't keep any work stuff on my personal devices and that was true even when I worked in an office, but I think it has actually been more helpful and important working remotely. It sounds like you've experimented with a lot of different ways to make remote working work for you. And I'm curious if there's anything else that you really want to change or anything that you would like to try or do differently. +JOËL: I think an element that I've been experimenting with recently is actually working outside of the home, so something like going to the library or going to a coffee shop. Interestingly, I've tended to use those mostly for when I want to work on personal projects that are not work. So strangely enough, now I work in my home, and when I do things for myself that I previously would have maybe done in my home, now it's always at a coffee shop, at the library, something like that. So I still keep that separation, but it's inverted. +STEPHANIE: Wow, that's really interesting. I also like to be in a more public space as well with my work. And just being surrounded by other people and busyness is very comforting for me. And it actually also helps with the rabbit hole because I think I am more present in my environment when I do have cues of people getting up around me or whatever. Though ironically, my wanting to be around other people does not really work well with meetings and collaborating and pairing with other people. [chuckles] And so when I have to do those things, even though I'm also socializing just in a different way, I usually have to be in a more quiet, private space. +JOËL: Have you ever tried to maybe group your meetings on a particular day so that you have, let's say, an afternoon of uninterrupted time that you know you can just go to a coffee shop and be heads down and not have to take a call there? +STEPHANIE: I haven't tried that. But I think that would be helpful because then it's kind of like the best of both worlds, right? Where I can say, "Hey, I can meet once I'm moved back into my private space," and also have that physical environment of being around other people. And I think I had previously thought just those things were mutually exclusive, but there are certainly ways that I'd love to try injecting that into my home-work setup. +I'm really glad that we ended up talking about this because I think this will just be our future for a while. And it's always worth revisiting it and thinking about it and thinking if it's working for us or not. I'm really excited to try some of the new things that you mentioned. Like, we've been doing this for several years now, but there's always room for improvement and room to inject more fun and joy, and creativity in how we choose to do our work. +JOËL: On that note. Shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël has been working on his RailsConf talk about various aspects of discrete math useful in day-to-day work as a developer and going deep on some concepts from propositional logic and Boolean algebra, particularly DeMorgan's Laws, which explain how to negate a compound condition. Stephanie attended a meeting with a fun "Spicy Takes" topic. She gave a short talk on how frictionless technology may not be the best path forward and tried to argue in favor of more friction in our software.

+ +

Together, they talk about ways they've made remote work work for them and things they'd like to try/do differently.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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: I've recently got accepted to speak at RailsConf. And I've been working on my talk about various aspects of discrete math that are useful in day-to-day work as a developer and going really deep on some concepts from propositional logic and Boolean algebra, particularly the DeMorgan's Laws, which explain how to negate a compound condition.

+ +

So if condition one or condition two, if you want to negate that thing as a whole, you can't just negate both of the conditions individually. You will get a totally different result, and that's a really easy mistake to make. I don't always memorize exactly what to do. But I know enough in the back of my head when it comes up on a pull request to check it out and be like, oh, there's a negating of a compound condition here. Pay closer attention. There might be a bug.

+ +

STEPHANIE: So are you saying that when you negate each condition individually, you get the opposite result that you want?

+ +

JOËL: It's not opposite, just different.

+ +

STEPHANIE: Just different, okay.

+ +

JOËL: So De Morgan's Laws tell us that if you want to negate the compound condition as a whole, you negate the individual clauses but then also have to flip the sign in the middle. So if you're trying to negate condition one and condition two, it becomes not condition one or not condition two.

+ +

STEPHANIE: I see. Wow, that's confusing because you'd think that there are just two outcomes, but really there are a lot more.

+ +

JOËL: Yes.

+ +

STEPHANIE: And that reminds me of when we've talked about on the show combinatorial explosions, which I know is a favorite topic of yours.

+ +

JOËL: Combinatorics will definitely come up in the talk as well. It's sometimes hard to hold all the possibilities in your mind. And so I'm a big fan of truth tables to visualize what's happening and to be like, oh, when I make this thing negative, now all these things flipped into false when I want them to be true and vice versa. Okay, I've got a weird inverse going on here or something like that.

+ +

STEPHANIE: I have a funny thing to share with you. Joël, have you ever heard of the show "Taskmaster"?

+ +

JOËL: No, I'm not familiar with this.

+ +

STEPHANIE: Okay, it's a British reality competition comedy show where the contestants are usually famous British actors or comedians. And they have to do just really insane, silly tasks. And usually, one of the more iconic ones is to eat as much watermelon as you can in a minute. But they're just presented with a whole watermelon without any tools or anything [chuckles] for cutting it up. And it's just very funny and very delightful.

+ +

And one of the tasks that I watched recently was a situation where they had to follow these instructions, and the instructions were to do the opposite of the following statement: "You must under no circumstances not avoid not making the bell not ring." And they had a bell right in front of them. And so they had to figure out if they were supposed to ring the bell or not ring the bell based on those instructions and within a certain time limit. If they had the math skills that you were talking about, [chuckles] perhaps they would have been able to figure it out.

+ +

JOËL: I would absolutely want to write that out as a more formal logic thing. Otherwise, it becomes...you just mess with your head. You get in almost a recursive space where like, wait, not not, does that cancel? Does it stay? And yeah, it gets really messy.

+ +

STEPHANIE: Yeah, it was very funny to watch them try to figure that out on the spot. And I think there's a clip of it on YouTube that we can link [laughs] for our listeners.

+ +

JOËL: That's amazing. What's new in your world?

+ +

STEPHANIE: So last Friday...you and I are on the same team at thoughtbot called Boost, and every two weeks, we get together as a team, and we have a meeting where anyone can propose a topic. It's just a nice space for people to see each other and hang out. And one of our co-workers hosted that meeting and he chose the topic of spicy takes and asked for volunteers to sign up and give a quick couple of minutes lightning talk on the spicy take that they had. And it was so fun.

+ +

We got some takes on how REST is not the best. We got some opposing opinions about Tailwind. And I ended up giving a short, little talk on how frictionless technology may not be the best path forward and was trying to argue in favor of a little more friction in our software.

+ +

JOËL: What would friction look like in this scenario?

+ +

STEPHANIE: I was really interested in exploring how by making our software so easy for users we eliminate some amount of attention and mindfulness into using technology. So I think for me friction would be presenting the user with more autonomy and choice rather than making decisions on their behalf.

+ +

I don't totally know what that looks like, but I do know that things like one-click ordering or autoplay those things have made me bristle a little bit in certain contexts and wondering what other options do we have available to us to provide the features we want to provide to our users but maybe not in a way that is so convenient and easy to use that we lose that aspect of knowing what we're doing with our technology.

+ +

JOËL: I feel like knowing you, you've probably read a couple of articles and some books on this topic. And if I wanted to dig more into this idea of a little bit more mindfulness or introducing a little bit of friction into my software world, where would you recommend I go to read?

+ +

STEPHANIE: Yeah, that's a great question. When I was preparing the talk, I referenced a few articles that I'll link in the show notes, one from The Atlantic and one from The New York Times. And I liked them because one of them presented what I was getting at, the more philosophical approach of like, what does it mean for our attention to be? And what does it mean for our technology to be too easy? And the other one had more practical use cases for security and technology misinformation and abuse. So I liked that those two things complemented each other equally.

+ +

And then I also would plug a book called "How to Do Nothing: Resisting the Attention Economy" by Jenny Odell. I read that book last year and really enjoyed it. And she talks a lot about just the current technology landscape and what we, as consumers and users, can do to reframe our relationship with it. And I think that book is for people who use technology in general. But as developers, I think we are in a unique position to extend that train of thought right into the things that we develop.

+ +

JOËL: You know, a place where I do appreciate friction is in the physical world. If there weren't any friction, my chair would not stay put on the ground. My fingers would not press on the keyboard. So we need friction to be able to do our jobs. So you work from home; I work from home because thoughtbot is now fully remote. How has that been for you setting up a work environment in your home?

+ +

STEPHANIE: So I've actually been working from home since 2019. So about a year before the pandemic, I had moved to Chicago and was still working for a company in New York. And so that was when I started working from home, and then have just been doing that ever since. So I think I have now really figured out a setup that works for me. I've been doing it for four years now, which is pretty wild to me when I think about it. It's interesting because I actually really enjoyed going into an office. And there are parts of that that I really miss. But I think I have just gotten used to it and have a setup that works well for me.

+ +

JOËL: Are there any things that you like to do for your environment to help get yourself into maybe the zone a little bit more easily?

+ +

STEPHANIE: Yeah. So my workspace is a separate room from the rest of my apartment, which is also really just one big room. [laughs] It's kind of like a loft-style situation, so I don't really have doors. But I am in what we call the sunroom, and it's actually kind of like an enclosed porch with a big window and lots of plants. And it's in the back of the apartment.

+ +

And so whenever I'm in this space, it's because I'm working. And I think having that separation of home and work is really helpful. Because when I step into this space, I'm like, okay, now I'm at work, and I don't have as many distractions as I would if I were working in a different space like a bedroom or the living room.

+ +

JOËL: I have to say whenever you're on a video call, the plants around you are iconic.

+ +

STEPHANIE: Oh, thank you. Yeah, it's been a nice conversation starter. When I'm meeting a new person, they usually comment on the plants, and I can give them a little show and tell. And that's been really nice.

+ +

JOËL: I feel like a lot of people who work from home have put a lot of work into creating fun backgrounds for their video calls. Maybe they're setting up a cool bookcase behind them or plants. People like to put something behind them that will make things interesting on a video call in a way that maybe we didn't need to when it was just a conference room and in an office.

+ +

STEPHANIE: Yeah, absolutely. I was just on a meeting with someone who had a big pile of tiny rubber ducks. So he was also a developer and, I guess, had just amassed this very delightful rubber duck collection, and it was just in the background. And we got to joke about it for a little bit, and that was really fun.

+ +

JOËL: Are these rubber ducks meant to be used during debugging sessions?

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: So I'm in a somewhat different situation from you in that I don't have a separate room to set up a home office. I've resisted doing anything in my bedroom. Like you said, it's good to have that separation. So I work more in my kind of living room-dining room space. And something that I found is really valuable for me has been movement. So say I work an hour in one part of the room, and then I switch to a different place. And it's going to be maybe a different posture.

+ +

So I'm working in a solid chair table for a while, and then maybe I switch to more of an easy chair situation. That I think has been really helpful for me ergonomically during the day is just making sure that I'm not always in the same position constantly all the time but actually incorporating change in movement throughout my day.

+ +

STEPHANIE: I like that a lot. I actually do also end up sitting at my dining room table sometimes for a change of scenery. It's funny because there was a while when...when I'm at my office desk, I have a standing desk. And so usually if I'm in a meeting, I would be at my desk and people would see me standing. And I think someone at some point mentioned like, "Wow, you seem to stand all day." And I was like, "Oh, well, when I'm not in a meeting, that's when I'm sitting on the couch or a lounge chair or something." [laughs] I'm curious, though, because you are working in your dining living space if it's been harder to separate work and home life.

+ +

JOËL: I think it was definitely an adjustment, but it's a thing that I learned to do. And I still try to keep some amount of separation, which is why I don't set up an office space in my room. But I've also gotten to the point where now that I work from home, I find myself leaving home much more frequently after the workday ends. I was surprised just how much social interaction you get just by default being in an office around people all the time. When you're at home all day, even if you're on calls, it's not the same.

+ +

And so I've found myself more and more to stay in a healthy emotional, mental space, leaving the home in the evening to go do things with friends or with other people. And so even though I am an introvert who prior to working from home preferred to stay at home more evenings than not, I've started living almost more of what people would assume is an extrovert lifestyle where I'm out every evening.

+ +

STEPHANIE: Wow, that's so interesting because I'm the opposite; where when I was commuting and going to an office, I found it much easier to stay out. I would just go to a bar or a restaurant after work. Whereas now it's a bit harder because I'm not already out and about in the world, and also I am in my comfy pants, and I'm just like, oh, I have to go out? I don't know if I'm up for that. [laughs]

+ +

Though I also really...I think the downside is that I have been really missing some of that human contact. And there are weeks where I'm like, dang, I really didn't talk to people in the world very much. So it's actually been a bit of a bigger obstacle for me to find the energy to see people in the evenings after work.

+ +

JOËL: It helps to make plans.

+ +

STEPHANIE: Yeah, that's a good idea.

+ +

JOËL: Or you can have people come to you. You mentioned you were doing that soup club.

+ +

STEPHANIE: I did, yeah, back when the winter was first starting. I mentioned on the show that I was having people over for soup on Friday nights, and that was really great. That was nice because then I was like, okay, I have to sign off by 5:00 p.m. so I can start making the soup. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you mentioned that sometimes it's hard to leave the home because you're kind of in your comfy clothes, and you don't want to kind of get dressed to go out. Has working from home kind of changed the way you tend to dress? Do you ever do the thing where it's like, oh, I've got the formal top and then just sweats?

+ +

STEPHANIE: Yeah. Like business on top and party in the bottom [laughter] or something like that is the phrase. My habits around getting ready in the morning have definitely changed; where I don't put as much energy or effort, or time into it as I did when I was working in an office. And that has been nice because I get that time back, and that is really valuable to me.

+ +

Yeah, I'm also usually just in soft pants. [laughs] That has definitely been a very positive impact on my life. And I do try to make an effort to go out for coffee. And when I do that, I'm just like, yeah, how I go out is how I go out. I don't really mind. I'm very comfortable going out however I'm feeling that day. But I think getting the time back actually has been really important to me.

+ +

JOËL: Hmm, I think for me, interestingly, that's become an interesting way to build a little bit of separation from personal life and work life. So I'm making a point to put on...I don't know how you describe it. I was going to say real pants, but it's not like sweats are not real pants. But yeah, I will put on the kind of thing that I would put on to go in the office. And for me, that's kind of a...it's a start to the day. It's a start to being more serious and transitioning to more of a work mindset.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: As opposed to on the weekend, if I'm just hanging around in the same space, but I'm dressed differently, I don't feel like I'm in work mode.

+ +

STEPHANIE: Yeah, yeah, that's fair. I've definitely noticed your fun sweaters that you wear in video calls and stuff. So I really appreciate that; yeah, you are just putting on clothes that make you feel like you're ready to dive into the work week. I'm really curious, do you find yourself being more productive working from home than you were working in an office?

+ +

JOËL: I would say it's about even on average. There are probably days where more or less on one side or the other, but I would say it's similar.

+ +

STEPHANIE: I think I'm actually much more focused at home. And I know that this is not true for everyone because I was chatting with a friend, and she was asking, like, "How do you stay focused at home?" She was telling me that she gets so distracted by all the things that she could be doing in her home life. And for me, because I really enjoyed the social aspect of being in an office, I found myself wandering into the kitchen not infrequently to go get some snacks, and oh, running into this person and having a little chat.

+ +

And I think my presence also, I was available for other people to come to me and start a conversation or ask to go on a walk. And I think I actually really needed that external push to take breaks. Because now that I'm working from home by myself, I definitely just get into some rabbit holes, and it's tough for me to resurface.

+ +

JOËL: Let me fix one more error, and then maybe the test will be green. Oh, that didn't fix it, but I'll bet one more would fix it. And keep doing that until it's like, oh, well, I'm going to push off my break for another 30 minutes, oh, another hour. And it's like, you know what? I'm just going to finish my day.

+ +

STEPHANIE: That literally happens to me all the time. The lunchtime break is tough because I definitely will delay that by 15 minutes and then 30 minutes, and then oh no, it's like 2:00 p.m. Okay, let me just eat a snack, then. And then keep going until I finish whatever task, and then end up wishing that I had made a little more of an effort to take a real break.

+ +

JOËL: Yeah, I was having a conversation recently with someone about how it's often easier to make space for other people than for yourself. So if somebody is like, "Hey, I want to take a break. Do you want to go take a walk?" You might be like, "Sure." Maybe I wasn't quite in a place where I wanted to take a break, but I'll make the time for you.

+ +

Whereas when it's like, you know what? My body or my mind is telling me I need to take a break, but this test isn't green yet. So I'm going to almost deny myself here for the, I don't know, the good of the mission, whatever. It's not really a noble sacrifice. It ends up hurting you and the project in the longer run, but it's so much easier to do that.

+ +

STEPHANIE: Wow. Okay, yeah, that really resonated with me because I find myself in situations where I don't think that I can take a break because I'm like, oh, I have all these red tests, and I need to get them in a place where I feel comfortable stepping away. But if someone asked me like, "Hey, I'm at your door. Let's go for a walk," I could just put it away and go for a walk and have a great time. And I would like to be able to do that for myself when I don't have someone prompting me.

+ +

JOËL: There's something I really appreciated that someone who used to be at thoughtbot would do is this person would go for a walk every afternoon without fail and would drop a line in the Slack channel being like, "Hey, I'm stepping away for a walk." And, I mean, yeah, it's nice to know that, okay, this person's not reachable for the next 15 minutes or whatever. But that's not really, I think, the value that I got from it. It was more of seeing somebody else taking a break and it being a reminder for me too to be like, you know what? Maybe I should take a walk as well, like, it might be time for a break.

+ +

STEPHANIE: Yeah, I like that a lot. I think it's kind of ironic that I have quote, unquote, "optimized" my setup so much that I don't get distracted that I miss out on the friction [laughs] (A little call back to earlier.) that I would like to, yeah, call more mindfulness to how I'm physically feeling, not even physically but also emotionally and intellectually and being prompted, like I said, externally because I am realizing now that I really need that.

+ +

JOËL: And at least for us here in North America, it's now starting to be spring. And so I think sometimes winter can be its own barrier to be like, you know what? I should go and take a walk. I don't know if I want to put on all the layers and my boots and all of that and deal with the snow. Whereas now it's like, just walk out and there will be flowers and trees covered in blooms. And it's going to be amazing.

+ +

STEPHANIE: Yeah, I'm really looking forward to that. I agree; I think when the weather is nice, that is definitely a bigger motivator for me because there's more to enjoy and more to look at. And I love being outside. When you do step away to take a break, what do you do in your home or outside your home?

+ +

JOËL: So I'm a big fan of taking a walk. I live in a dense, walkable neighborhood, Downtown Boston. And so just walking around a few blocks is a great way to get a little bit of fresh air, just get some motion going because I've been sitting around for a long time. It's a lot of natural beauty as well. A lot of people have gardens, and there are a lot of trees planted along the roads. So it's just a really pleasant way to, in some ways, connect with a little bit of nature and be outside and reset. Do you find yourself when you're looking for a break gravitating outwards or inwards in your space?

+ +

STEPHANIE: I like to make myself a snack, a cup of tea. Sometimes if I'm reading a good book, I'll get into the book for 20 minutes. And sometimes, if there's nothing to pick up, maybe I'll find myself on YouTube and watch a short little thing just to reset and have some fun. Sometimes I'll try to tackle some dishes. I think the other thing with working from home is that I now create more mess in my home. [laughs] I don't know if it's the same with you. But I, yeah, try to keep on top of that so that I don't have to do it later in the evening.

+ +

JOËL: I think one of the things that's really nice about working from home is the ability to cook more because you're in that space. So I've found myself oftentimes more on my lunch break, maybe prepping some things for a stew or something that's going to braise, and then just having it sit on the stove all afternoon. And like I said, maybe a really quick break is just you get up, go check the pot on the stove, and you turn the heat down or stir it a little bit and then get back to work.

+ +

STEPHANIE: Yeah, I like that a lot. I do that, too, with a pot of rice or beans or something like that. I also am definitely making my own food for lunch a lot more just because, being at home, you have your whole kitchen and fridge available to you, and I feel less pressure to get all that done the night before.

+ +

JOËL: Right. I think I've been trying to incorporate a little bit more physicality to my breaks recently. And one thing that I've done for shorter breaks...if it is a longer break, it is nice to go out and take a walk. But for shorter breaks, I set up a pull-up bar, and I just try to go and do a set of pull-ups there. And I'm not great at it, so it's not like I'm there for 10 minutes doing 100 pull-ups. But it's a nice way to go from a very static mental mode to a quick break that just totally resets you into this active physical space.

+ +

STEPHANIE: Yeah, I like that a lot because something like that requires your full attention and physical effort in that moment. So it's not like you can still really be thinking about work while you're in the middle of doing a pull-up, at least [laughs] that's my interpretation of [laughs] how you take those breaks.

+ +

JOËL: I'm curious, are there any other kinds of lifestyle elements that you've changed or customized to help you have a better working-from-home experience?

+ +

STEPHANIE: There was a past Bike Shed episode hosted by Steph Viccari and Chris Toomey, and I can't remember exactly what it was that they were talking about. It must have been working from home-related because Chris had mentioned a ritual that he had when he was finishing his workday where he would close his laptop and say, "Schedule shutdown complete." And I've been thinking about that a lot and trying to do a similar thing of just verbalizing, "I'm done with work now," to make it true. [chuckles]

+ +

Otherwise, if I don't, I can find myself gravitating towards my laptop when I have a thought. Like, I have an idea like, oh, I just thought of a way to try to debug that test or whatever. And then I'll want to go back just really quickly to write it down on my work computer so it's there for me when I come back. But if I've said, "I am done with work today," that means I'm trying not to reopen the work laptop, and then I'll try to jot it down somewhere else. And that has been really helpful.

+ +

JOËL: So, setting like an emotional boundary.

+ +

STEPHANIE: Yeah, an emotional boundary that almost becomes physical in a way because when I was working in an office, I would never take my work stuff home with me, so I physically could not access it. And since I can't do that now, by verbalizing it, it's almost as if I've created a boundary in my head.

+ +

JOËL: That's really powerful, the impact that you can have just by sort of verbalizing something.

+ +

STEPHANIE: I will say that I also don't keep any work stuff on my personal devices and that was true even when I worked in an office, but I think it has actually been more helpful and important working remotely. It sounds like you've experimented with a lot of different ways to make remote working work for you. And I'm curious if there's anything else that you really want to change or anything that you would like to try or do differently.

+ +

JOËL: I think an element that I've been experimenting with recently is actually working outside of the home, so something like going to the library or going to a coffee shop. Interestingly, I've tended to use those mostly for when I want to work on personal projects that are not work. So strangely enough, now I work in my home, and when I do things for myself that I previously would have maybe done in my home, now it's always at a coffee shop, at the library, something like that. So I still keep that separation, but it's inverted.

+ +

STEPHANIE: Wow, that's really interesting. I also like to be in a more public space as well with my work. And just being surrounded by other people and busyness is very comforting for me. And it actually also helps with the rabbit hole because I think I am more present in my environment when I do have cues of people getting up around me or whatever. Though ironically, my wanting to be around other people does not really work well with meetings and collaborating and pairing with other people. [chuckles] And so when I have to do those things, even though I'm also socializing just in a different way, I usually have to be in a more quiet, private space.

+ +

JOËL: Have you ever tried to maybe group your meetings on a particular day so that you have, let's say, an afternoon of uninterrupted time that you know you can just go to a coffee shop and be heads down and not have to take a call there?

+ +

STEPHANIE: I haven't tried that. But I think that would be helpful because then it's kind of like the best of both worlds, right? Where I can say, "Hey, I can meet once I'm moved back into my private space," and also have that physical environment of being around other people. And I think I had previously thought just those things were mutually exclusive, but there are certainly ways that I'd love to try injecting that into my home-work setup.

+ +

I'm really glad that we ended up talking about this because I think this will just be our future for a while. And it's always worth revisiting it and thinking about it and thinking if it's working for us or not. I'm really excited to try some of the new things that you mentioned. Like, we've been doing this for several years now, but there's always room for improvement and room to inject more fun and joy, and creativity in how we choose to do our work.

+ +

JOËL: On that note. Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël has been working on his RailsConf talk about various aspects of discrete math useful in day-to-day work as a developer and going deep on some concepts from propositional logic and Boolean algebra, particularly DeMorgan's Laws, which explain how to negate a compound condition. Stephanie attended a meeting with a fun "Spicy Takes" topic. She gave a short talk on how frictionless technology may not be the best path forward and tried to argue in favor of more friction in our software.

+ +

Together, they talk about ways they've made remote work work for them and things they'd like to try/do differently.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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: I've recently got accepted to speak at RailsConf. And I've been working on my talk about various aspects of discrete math that are useful in day-to-day work as a developer and going really deep on some concepts from propositional logic and Boolean algebra, particularly the DeMorgan's Laws, which explain how to negate a compound condition.

+ +

So if condition one or condition two, if you want to negate that thing as a whole, you can't just negate both of the conditions individually. You will get a totally different result, and that's a really easy mistake to make. I don't always memorize exactly what to do. But I know enough in the back of my head when it comes up on a pull request to check it out and be like, oh, there's a negating of a compound condition here. Pay closer attention. There might be a bug.

+ +

STEPHANIE: So are you saying that when you negate each condition individually, you get the opposite result that you want?

+ +

JOËL: It's not opposite, just different.

+ +

STEPHANIE: Just different, okay.

+ +

JOËL: So De Morgan's Laws tell us that if you want to negate the compound condition as a whole, you negate the individual clauses but then also have to flip the sign in the middle. So if you're trying to negate condition one and condition two, it becomes not condition one or not condition two.

+ +

STEPHANIE: I see. Wow, that's confusing because you'd think that there are just two outcomes, but really there are a lot more.

+ +

JOËL: Yes.

+ +

STEPHANIE: And that reminds me of when we've talked about on the show combinatorial explosions, which I know is a favorite topic of yours.

+ +

JOËL: Combinatorics will definitely come up in the talk as well. It's sometimes hard to hold all the possibilities in your mind. And so I'm a big fan of truth tables to visualize what's happening and to be like, oh, when I make this thing negative, now all these things flipped into false when I want them to be true and vice versa. Okay, I've got a weird inverse going on here or something like that.

+ +

STEPHANIE: I have a funny thing to share with you. Joël, have you ever heard of the show "Taskmaster"?

+ +

JOËL: No, I'm not familiar with this.

+ +

STEPHANIE: Okay, it's a British reality competition comedy show where the contestants are usually famous British actors or comedians. And they have to do just really insane, silly tasks. And usually, one of the more iconic ones is to eat as much watermelon as you can in a minute. But they're just presented with a whole watermelon without any tools or anything [chuckles] for cutting it up. And it's just very funny and very delightful.

+ +

And one of the tasks that I watched recently was a situation where they had to follow these instructions, and the instructions were to do the opposite of the following statement: "You must under no circumstances not avoid not making the bell not ring." And they had a bell right in front of them. And so they had to figure out if they were supposed to ring the bell or not ring the bell based on those instructions and within a certain time limit. If they had the math skills that you were talking about, [chuckles] perhaps they would have been able to figure it out.

+ +

JOËL: I would absolutely want to write that out as a more formal logic thing. Otherwise, it becomes...you just mess with your head. You get in almost a recursive space where like, wait, not not, does that cancel? Does it stay? And yeah, it gets really messy.

+ +

STEPHANIE: Yeah, it was very funny to watch them try to figure that out on the spot. And I think there's a clip of it on YouTube that we can link [laughs] for our listeners.

+ +

JOËL: That's amazing. What's new in your world?

+ +

STEPHANIE: So last Friday...you and I are on the same team at thoughtbot called Boost, and every two weeks, we get together as a team, and we have a meeting where anyone can propose a topic. It's just a nice space for people to see each other and hang out. And one of our co-workers hosted that meeting and he chose the topic of spicy takes and asked for volunteers to sign up and give a quick couple of minutes lightning talk on the spicy take that they had. And it was so fun.

+ +

We got some takes on how REST is not the best. We got some opposing opinions about Tailwind. And I ended up giving a short, little talk on how frictionless technology may not be the best path forward and was trying to argue in favor of a little more friction in our software.

+ +

JOËL: What would friction look like in this scenario?

+ +

STEPHANIE: I was really interested in exploring how by making our software so easy for users we eliminate some amount of attention and mindfulness into using technology. So I think for me friction would be presenting the user with more autonomy and choice rather than making decisions on their behalf.

+ +

I don't totally know what that looks like, but I do know that things like one-click ordering or autoplay those things have made me bristle a little bit in certain contexts and wondering what other options do we have available to us to provide the features we want to provide to our users but maybe not in a way that is so convenient and easy to use that we lose that aspect of knowing what we're doing with our technology.

+ +

JOËL: I feel like knowing you, you've probably read a couple of articles and some books on this topic. And if I wanted to dig more into this idea of a little bit more mindfulness or introducing a little bit of friction into my software world, where would you recommend I go to read?

+ +

STEPHANIE: Yeah, that's a great question. When I was preparing the talk, I referenced a few articles that I'll link in the show notes, one from The Atlantic and one from The New York Times. And I liked them because one of them presented what I was getting at, the more philosophical approach of like, what does it mean for our attention to be? And what does it mean for our technology to be too easy? And the other one had more practical use cases for security and technology misinformation and abuse. So I liked that those two things complemented each other equally.

+ +

And then I also would plug a book called "How to Do Nothing: Resisting the Attention Economy" by Jenny Odell. I read that book last year and really enjoyed it. And she talks a lot about just the current technology landscape and what we, as consumers and users, can do to reframe our relationship with it. And I think that book is for people who use technology in general. But as developers, I think we are in a unique position to extend that train of thought right into the things that we develop.

+ +

JOËL: You know, a place where I do appreciate friction is in the physical world. If there weren't any friction, my chair would not stay put on the ground. My fingers would not press on the keyboard. So we need friction to be able to do our jobs. So you work from home; I work from home because thoughtbot is now fully remote. How has that been for you setting up a work environment in your home?

+ +

STEPHANIE: So I've actually been working from home since 2019. So about a year before the pandemic, I had moved to Chicago and was still working for a company in New York. And so that was when I started working from home, and then have just been doing that ever since. So I think I have now really figured out a setup that works for me. I've been doing it for four years now, which is pretty wild to me when I think about it. It's interesting because I actually really enjoyed going into an office. And there are parts of that that I really miss. But I think I have just gotten used to it and have a setup that works well for me.

+ +

JOËL: Are there any things that you like to do for your environment to help get yourself into maybe the zone a little bit more easily?

+ +

STEPHANIE: Yeah. So my workspace is a separate room from the rest of my apartment, which is also really just one big room. [laughs] It's kind of like a loft-style situation, so I don't really have doors. But I am in what we call the sunroom, and it's actually kind of like an enclosed porch with a big window and lots of plants. And it's in the back of the apartment.

+ +

And so whenever I'm in this space, it's because I'm working. And I think having that separation of home and work is really helpful. Because when I step into this space, I'm like, okay, now I'm at work, and I don't have as many distractions as I would if I were working in a different space like a bedroom or the living room.

+ +

JOËL: I have to say whenever you're on a video call, the plants around you are iconic.

+ +

STEPHANIE: Oh, thank you. Yeah, it's been a nice conversation starter. When I'm meeting a new person, they usually comment on the plants, and I can give them a little show and tell. And that's been really nice.

+ +

JOËL: I feel like a lot of people who work from home have put a lot of work into creating fun backgrounds for their video calls. Maybe they're setting up a cool bookcase behind them or plants. People like to put something behind them that will make things interesting on a video call in a way that maybe we didn't need to when it was just a conference room and in an office.

+ +

STEPHANIE: Yeah, absolutely. I was just on a meeting with someone who had a big pile of tiny rubber ducks. So he was also a developer and, I guess, had just amassed this very delightful rubber duck collection, and it was just in the background. And we got to joke about it for a little bit, and that was really fun.

+ +

JOËL: Are these rubber ducks meant to be used during debugging sessions?

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: So I'm in a somewhat different situation from you in that I don't have a separate room to set up a home office. I've resisted doing anything in my bedroom. Like you said, it's good to have that separation. So I work more in my kind of living room-dining room space. And something that I found is really valuable for me has been movement. So say I work an hour in one part of the room, and then I switch to a different place. And it's going to be maybe a different posture.

+ +

So I'm working in a solid chair table for a while, and then maybe I switch to more of an easy chair situation. That I think has been really helpful for me ergonomically during the day is just making sure that I'm not always in the same position constantly all the time but actually incorporating change in movement throughout my day.

+ +

STEPHANIE: I like that a lot. I actually do also end up sitting at my dining room table sometimes for a change of scenery. It's funny because there was a while when...when I'm at my office desk, I have a standing desk. And so usually if I'm in a meeting, I would be at my desk and people would see me standing. And I think someone at some point mentioned like, "Wow, you seem to stand all day." And I was like, "Oh, well, when I'm not in a meeting, that's when I'm sitting on the couch or a lounge chair or something." [laughs] I'm curious, though, because you are working in your dining living space if it's been harder to separate work and home life.

+ +

JOËL: I think it was definitely an adjustment, but it's a thing that I learned to do. And I still try to keep some amount of separation, which is why I don't set up an office space in my room. But I've also gotten to the point where now that I work from home, I find myself leaving home much more frequently after the workday ends. I was surprised just how much social interaction you get just by default being in an office around people all the time. When you're at home all day, even if you're on calls, it's not the same.

+ +

And so I've found myself more and more to stay in a healthy emotional, mental space, leaving the home in the evening to go do things with friends or with other people. And so even though I am an introvert who prior to working from home preferred to stay at home more evenings than not, I've started living almost more of what people would assume is an extrovert lifestyle where I'm out every evening.

+ +

STEPHANIE: Wow, that's so interesting because I'm the opposite; where when I was commuting and going to an office, I found it much easier to stay out. I would just go to a bar or a restaurant after work. Whereas now it's a bit harder because I'm not already out and about in the world, and also I am in my comfy pants, and I'm just like, oh, I have to go out? I don't know if I'm up for that. [laughs]

+ +

Though I also really...I think the downside is that I have been really missing some of that human contact. And there are weeks where I'm like, dang, I really didn't talk to people in the world very much. So it's actually been a bit of a bigger obstacle for me to find the energy to see people in the evenings after work.

+ +

JOËL: It helps to make plans.

+ +

STEPHANIE: Yeah, that's a good idea.

+ +

JOËL: Or you can have people come to you. You mentioned you were doing that soup club.

+ +

STEPHANIE: I did, yeah, back when the winter was first starting. I mentioned on the show that I was having people over for soup on Friday nights, and that was really great. That was nice because then I was like, okay, I have to sign off by 5:00 p.m. so I can start making the soup. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you mentioned that sometimes it's hard to leave the home because you're kind of in your comfy clothes, and you don't want to kind of get dressed to go out. Has working from home kind of changed the way you tend to dress? Do you ever do the thing where it's like, oh, I've got the formal top and then just sweats?

+ +

STEPHANIE: Yeah. Like business on top and party in the bottom [laughter] or something like that is the phrase. My habits around getting ready in the morning have definitely changed; where I don't put as much energy or effort, or time into it as I did when I was working in an office. And that has been nice because I get that time back, and that is really valuable to me.

+ +

Yeah, I'm also usually just in soft pants. [laughs] That has definitely been a very positive impact on my life. And I do try to make an effort to go out for coffee. And when I do that, I'm just like, yeah, how I go out is how I go out. I don't really mind. I'm very comfortable going out however I'm feeling that day. But I think getting the time back actually has been really important to me.

+ +

JOËL: Hmm, I think for me, interestingly, that's become an interesting way to build a little bit of separation from personal life and work life. So I'm making a point to put on...I don't know how you describe it. I was going to say real pants, but it's not like sweats are not real pants. But yeah, I will put on the kind of thing that I would put on to go in the office. And for me, that's kind of a...it's a start to the day. It's a start to being more serious and transitioning to more of a work mindset.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: As opposed to on the weekend, if I'm just hanging around in the same space, but I'm dressed differently, I don't feel like I'm in work mode.

+ +

STEPHANIE: Yeah, yeah, that's fair. I've definitely noticed your fun sweaters that you wear in video calls and stuff. So I really appreciate that; yeah, you are just putting on clothes that make you feel like you're ready to dive into the work week. I'm really curious, do you find yourself being more productive working from home than you were working in an office?

+ +

JOËL: I would say it's about even on average. There are probably days where more or less on one side or the other, but I would say it's similar.

+ +

STEPHANIE: I think I'm actually much more focused at home. And I know that this is not true for everyone because I was chatting with a friend, and she was asking, like, "How do you stay focused at home?" She was telling me that she gets so distracted by all the things that she could be doing in her home life. And for me, because I really enjoyed the social aspect of being in an office, I found myself wandering into the kitchen not infrequently to go get some snacks, and oh, running into this person and having a little chat.

+ +

And I think my presence also, I was available for other people to come to me and start a conversation or ask to go on a walk. And I think I actually really needed that external push to take breaks. Because now that I'm working from home by myself, I definitely just get into some rabbit holes, and it's tough for me to resurface.

+ +

JOËL: Let me fix one more error, and then maybe the test will be green. Oh, that didn't fix it, but I'll bet one more would fix it. And keep doing that until it's like, oh, well, I'm going to push off my break for another 30 minutes, oh, another hour. And it's like, you know what? I'm just going to finish my day.

+ +

STEPHANIE: That literally happens to me all the time. The lunchtime break is tough because I definitely will delay that by 15 minutes and then 30 minutes, and then oh no, it's like 2:00 p.m. Okay, let me just eat a snack, then. And then keep going until I finish whatever task, and then end up wishing that I had made a little more of an effort to take a real break.

+ +

JOËL: Yeah, I was having a conversation recently with someone about how it's often easier to make space for other people than for yourself. So if somebody is like, "Hey, I want to take a break. Do you want to go take a walk?" You might be like, "Sure." Maybe I wasn't quite in a place where I wanted to take a break, but I'll make the time for you.

+ +

Whereas when it's like, you know what? My body or my mind is telling me I need to take a break, but this test isn't green yet. So I'm going to almost deny myself here for the, I don't know, the good of the mission, whatever. It's not really a noble sacrifice. It ends up hurting you and the project in the longer run, but it's so much easier to do that.

+ +

STEPHANIE: Wow. Okay, yeah, that really resonated with me because I find myself in situations where I don't think that I can take a break because I'm like, oh, I have all these red tests, and I need to get them in a place where I feel comfortable stepping away. But if someone asked me like, "Hey, I'm at your door. Let's go for a walk," I could just put it away and go for a walk and have a great time. And I would like to be able to do that for myself when I don't have someone prompting me.

+ +

JOËL: There's something I really appreciated that someone who used to be at thoughtbot would do is this person would go for a walk every afternoon without fail and would drop a line in the Slack channel being like, "Hey, I'm stepping away for a walk." And, I mean, yeah, it's nice to know that, okay, this person's not reachable for the next 15 minutes or whatever. But that's not really, I think, the value that I got from it. It was more of seeing somebody else taking a break and it being a reminder for me too to be like, you know what? Maybe I should take a walk as well, like, it might be time for a break.

+ +

STEPHANIE: Yeah, I like that a lot. I think it's kind of ironic that I have quote, unquote, "optimized" my setup so much that I don't get distracted that I miss out on the friction [laughs] (A little call back to earlier.) that I would like to, yeah, call more mindfulness to how I'm physically feeling, not even physically but also emotionally and intellectually and being prompted, like I said, externally because I am realizing now that I really need that.

+ +

JOËL: And at least for us here in North America, it's now starting to be spring. And so I think sometimes winter can be its own barrier to be like, you know what? I should go and take a walk. I don't know if I want to put on all the layers and my boots and all of that and deal with the snow. Whereas now it's like, just walk out and there will be flowers and trees covered in blooms. And it's going to be amazing.

+ +

STEPHANIE: Yeah, I'm really looking forward to that. I agree; I think when the weather is nice, that is definitely a bigger motivator for me because there's more to enjoy and more to look at. And I love being outside. When you do step away to take a break, what do you do in your home or outside your home?

+ +

JOËL: So I'm a big fan of taking a walk. I live in a dense, walkable neighborhood, Downtown Boston. And so just walking around a few blocks is a great way to get a little bit of fresh air, just get some motion going because I've been sitting around for a long time. It's a lot of natural beauty as well. A lot of people have gardens, and there are a lot of trees planted along the roads. So it's just a really pleasant way to, in some ways, connect with a little bit of nature and be outside and reset. Do you find yourself when you're looking for a break gravitating outwards or inwards in your space?

+ +

STEPHANIE: I like to make myself a snack, a cup of tea. Sometimes if I'm reading a good book, I'll get into the book for 20 minutes. And sometimes, if there's nothing to pick up, maybe I'll find myself on YouTube and watch a short little thing just to reset and have some fun. Sometimes I'll try to tackle some dishes. I think the other thing with working from home is that I now create more mess in my home. [laughs] I don't know if it's the same with you. But I, yeah, try to keep on top of that so that I don't have to do it later in the evening.

+ +

JOËL: I think one of the things that's really nice about working from home is the ability to cook more because you're in that space. So I've found myself oftentimes more on my lunch break, maybe prepping some things for a stew or something that's going to braise, and then just having it sit on the stove all afternoon. And like I said, maybe a really quick break is just you get up, go check the pot on the stove, and you turn the heat down or stir it a little bit and then get back to work.

+ +

STEPHANIE: Yeah, I like that a lot. I do that, too, with a pot of rice or beans or something like that. I also am definitely making my own food for lunch a lot more just because, being at home, you have your whole kitchen and fridge available to you, and I feel less pressure to get all that done the night before.

+ +

JOËL: Right. I think I've been trying to incorporate a little bit more physicality to my breaks recently. And one thing that I've done for shorter breaks...if it is a longer break, it is nice to go out and take a walk. But for shorter breaks, I set up a pull-up bar, and I just try to go and do a set of pull-ups there. And I'm not great at it, so it's not like I'm there for 10 minutes doing 100 pull-ups. But it's a nice way to go from a very static mental mode to a quick break that just totally resets you into this active physical space.

+ +

STEPHANIE: Yeah, I like that a lot because something like that requires your full attention and physical effort in that moment. So it's not like you can still really be thinking about work while you're in the middle of doing a pull-up, at least [laughs] that's my interpretation of [laughs] how you take those breaks.

+ +

JOËL: I'm curious, are there any other kinds of lifestyle elements that you've changed or customized to help you have a better working-from-home experience?

+ +

STEPHANIE: There was a past Bike Shed episode hosted by Steph Viccari and Chris Toomey, and I can't remember exactly what it was that they were talking about. It must have been working from home-related because Chris had mentioned a ritual that he had when he was finishing his workday where he would close his laptop and say, "Schedule shutdown complete." And I've been thinking about that a lot and trying to do a similar thing of just verbalizing, "I'm done with work now," to make it true. [chuckles]

+ +

Otherwise, if I don't, I can find myself gravitating towards my laptop when I have a thought. Like, I have an idea like, oh, I just thought of a way to try to debug that test or whatever. And then I'll want to go back just really quickly to write it down on my work computer so it's there for me when I come back. But if I've said, "I am done with work today," that means I'm trying not to reopen the work laptop, and then I'll try to jot it down somewhere else. And that has been really helpful.

+ +

JOËL: So, setting like an emotional boundary.

+ +

STEPHANIE: Yeah, an emotional boundary that almost becomes physical in a way because when I was working in an office, I would never take my work stuff home with me, so I physically could not access it. And since I can't do that now, by verbalizing it, it's almost as if I've created a boundary in my head.

+ +

JOËL: That's really powerful, the impact that you can have just by sort of verbalizing something.

+ +

STEPHANIE: I will say that I also don't keep any work stuff on my personal devices and that was true even when I worked in an office, but I think it has actually been more helpful and important working remotely. It sounds like you've experimented with a lot of different ways to make remote working work for you. And I'm curious if there's anything else that you really want to change or anything that you would like to try or do differently.

+ +

JOËL: I think an element that I've been experimenting with recently is actually working outside of the home, so something like going to the library or going to a coffee shop. Interestingly, I've tended to use those mostly for when I want to work on personal projects that are not work. So strangely enough, now I work in my home, and when I do things for myself that I previously would have maybe done in my home, now it's always at a coffee shop, at the library, something like that. So I still keep that separation, but it's inverted.

+ +

STEPHANIE: Wow, that's really interesting. I also like to be in a more public space as well with my work. And just being surrounded by other people and busyness is very comforting for me. And it actually also helps with the rabbit hole because I think I am more present in my environment when I do have cues of people getting up around me or whatever. Though ironically, my wanting to be around other people does not really work well with meetings and collaborating and pairing with other people. [chuckles] And so when I have to do those things, even though I'm also socializing just in a different way, I usually have to be in a more quiet, private space.

+ +

JOËL: Have you ever tried to maybe group your meetings on a particular day so that you have, let's say, an afternoon of uninterrupted time that you know you can just go to a coffee shop and be heads down and not have to take a call there?

+ +

STEPHANIE: I haven't tried that. But I think that would be helpful because then it's kind of like the best of both worlds, right? Where I can say, "Hey, I can meet once I'm moved back into my private space," and also have that physical environment of being around other people. And I think I had previously thought just those things were mutually exclusive, but there are certainly ways that I'd love to try injecting that into my home-work setup.

+ +

I'm really glad that we ended up talking about this because I think this will just be our future for a while. And it's always worth revisiting it and thinking about it and thinking if it's working for us or not. I'm really excited to try some of the new things that you mentioned. Like, we've been doing this for several years now, but there's always room for improvement and room to inject more fun and joy, and creativity in how we choose to do our work.

+ +

JOËL: On that note. Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+eVTmJI2S + + ]]> + + Joël Quenneville + Stephanie Minn + + + 379: Feature Flags + https://bikeshed.thoughtbot.com/379 + 6989e2ea-3085-412f-9707-7a4caba45fc5 + Tue, 11 Apr 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël submitted a last-minute submission to RailsConf discreet math, which got picked up! 🎉 He'll be speaking at RailsConf 2023 in Atlanta at the end of April about why it's relevant to developers and all the different practical ways he uses it daily. + +Stephanie recommends headlamps for in-bed reading sessions and sets up the feature flags topic for today based on a project that must be released to the public in one go. + 41:56 + no + + + Joël submitted a last-minute submission to RailsConf discreet math, which got picked up! 🎉 He'll be speaking at RailsConf 2023 in Atlanta at the end of April about why it's relevant to developers and all the different practical ways he uses it daily. +Stephanie recommends headlamps for in-bed reading sessions and sets up the feature flags topic for today based on a project that must be released to the public in one go. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Joël's Railsconf talk (https://railsconf2023.sessionize.com/session/453592) +Episode on Discrete Math (https://www.bikeshed.fm/374) +Episode on the Fundamentals (https://www.bikeshed.fm/371) +Strangler fig pattern (https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) +Flipper gem (https://github.com/jnunemaker/flipper) +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 a few episodes ago, we had a guest, Sara Jackson, on and she was talking about some cool elements of discrete math and how those can be really practically useful to us as developers in our day-to-day work. I was really inspired by that conversation. And the day we recorded that, I think, was the last day that the RailsConf CFP was open. +So I went and submitted a last-minute submission to RailsConf for this idea, and it got picked up. So I'm going to be speaking at RailsConf 2023 in Atlanta at the end of April about discrete math and why it's relevant to us as developers, and all the different practical ways that I use it on a daily basis. +STEPHANIE: That's awesome. Congrats, Joël. I'm so excited for this talk. +JOËL: Thanks. +STEPHANIE: Was this an 11:59 p.m. submission? +JOËL: Aaah, very close to that, yes. I don't recommend people to do this. But if inspiration hits you on the last day of the CFP, do it; go for it. I'd actually submitted two talk proposals. And I think maybe a little bit of the excitement in the energy for this last-minute one came through because that's the one that the committee picked. +STEPHANIE: How did you know that you would want to turn this topic into a talk? +JOËL: I think because I was excited to share about this to other people, and we'd kind of already done that on the show. But this is the sort of thing that's like, you know what? I'm kind of feeling a little bit of fire of this idea. I think more people should know about this. I think there's value in sharing this idea more broadly. What are some areas that I could do? I could maybe write a blog post. Oh, RailsConf, that's open until tonight. Let me put together a proposal because I'm excited about sharing this idea. +STEPHANIE: Yeah, I think we chatted a little bit about discrete math as potentially a fundamental pillar of information or a skill set for developers back in our episode on just the fundamentals of what developers need to know. And I was just thinking as you were talking about it that that was an audio medium, but it's obviously kind of an academic topic. And so to have slides for it and almost make it kind of like a little mini-lecture but more fun [laughs] than sitting in a classroom, I think, could be a really cool application of this topic. +JOËL: Yeah, I'm excited to take a very practical look at this. I've got 30 minutes to talk about it. I'm not going to give you the deep mathematical fundamentals. But if there are little bits of discrete math that I can show that are actually practically useful in a day-to-day situation, I think that would be incredibly valuable. So currently working on the talk, but the way I have it structured right now is very scenario-based. So we're going to look at some problems, look at just a tiny little bit of discrete math theory, and then see how that allows us to solve the underlying problem. +STEPHANIE: Nice. I won't be attending RailsConf this year, but I really look forward to watching the video when it comes out. +JOËL: Thank you. So, Stephanie, what's new in your world? +STEPHANIE: So last night I was reading in bed, and I usually stay up a little bit later than my partner. And so he was going to bed, and at that point, I usually turn off the bedside table lamp and either move to the couch to keep reading or just go to bed as well. But I was really engrossed in my book, and I wanted to keep going. But I was so cozy in bed. I really didn't want to move to the couch because then you risk falling asleep on the couch, and nobody likes that. +And so I was like, oh man, you know what I would really love? One of those book lights. And I got this really vivid memory of the clip-on ones I used to have as a kid that would clip onto the pages of my book and shine a light onto the page. And I was like, I feel like that technology must have gotten better [laughs] since I was a child. And I was like, okay, now I need to look up some doodad and buy a thing to help me solve this problem of reading in bed after hours. +And I was scrolling through my phone for a little bit, but then I was like, well, I want to read right now, not after [chuckles] I've purchased this gadget. And it hit me that we have headlamps that we use for our camping trips and also just if we ever are stuck without electricity. And I grabbed one of those from the junk drawer, and I wore it to bed and was reading my book. And it was a pretty good experience. So I'm actually pretty happy that I didn't need to buy a new thing to solve this problem of mine. And yeah, it turns out that you can just use something that you have at home. +JOËL: That's really cool. I feel like when I've used the headlamps before; normally, they're incredibly bright. Did you find that to be a problem for you? +STEPHANIE: I was able to adjust the brightness on mine, so it was definitely on the lower end of the setting and, overall, just better than having the nightstand lamp on, which I think just totally brightens the room. And at least this was a more targeted area of light, and it's working so far. He didn't wake up or anything, so I would call that a success. And now I have it in my bedside drawer. And I think I look really silly, but that's okay. No one can see me anyway. [laughs] +JOËL: That's kind of the whole point of it, right? +STEPHANIE: Exactly. [laughs] So, aside from my bedtime routine, another thing that's new in my world is something project-related. So I wanted to bring this up to you and get your thoughts on the situation. So I want to talk about feature flags because I'm currently working on a pretty big project that has to be released to the public in one go. And so naturally, we reached for using feature flags to be able to release our work to production but not to make it accessible to users so that we could be working on this thing incrementally and not have a huge release where all of this code goes out. +But as we've been building the feature, I am realizing that we are having to plug conditional code to check for this feature flag in a lot of different places. So, so far, we've been putting it in controllers. We've been putting it in a menu builder to show the user where they can navigate to. And then we've even been putting it inside of methods to change behavior based on whether the flag is on. And so that was kind of, I think, getting my spider senses a little bit tingling. +And then recently, one of the bigger issues that our team had a discussion about was whether to include this conditional check for the flag in queries. So we are building on top of an existing model. But once the feature flag is on and customers are using it, the application will be able to create new records for that model. But they're of a different category with a different value for one of the attributes. And we end up clearing for this model in a lot of one-off places. +And so once this thing is on, all of the records that are specific to this new feature will be included whenever we query for this model. And as we've been developing, it's been less of an issue because customers can't access the flow to create these new records. But someone brought up what if we release this, and it turns out that we have an issue and we want to turn it off; we want to roll it back? And at that point, those records will still have been created in the database and will then be included in those queries and what do we do then? +And so we started getting into the weeds a little bit of, like, do we want to have some conditional query situation going on? We haven't quite landed on an answer, but things are getting a little hairy. And I am curious if this works. Any thoughts for you? +JOËL: That's a really interesting problem to have. You mentioned having all of these conditionals kind of sprinkled everywhere for the feature flag kind of triggered your spidey senses a little bit. Do you have a sense a little bit of maybe why that feels wrong or maybe why you're feeling uncomfortable about this code? +STEPHANIE: Yeah, I was thinking about it, and, in my opinion, the ideal world for feature flags would be you have the checks at the boundaries of your code or where a customer could interact with the application. And then you are able to, I guess, branch a little earlier so that they don't go down the flow at all where the changes are being made. And this seems to be a little bit of the opposite, where we end up having to check in a million different places because we aren't keeping that separation as explicit as I think it should be. +JOËL: Hmm, so almost like it's not the feature flag that's the problem. The feature flag is just a symptom of tight coupling in the wider system. +STEPHANIE: Yeah, that's definitely a smell that has emerged. But I also don't think that we have the luxury necessarily to decouple all of the places in the code as we are trying to add this new feature. Have you been in a situation like this before? +JOËL: I think tight coupling, in general, is a thing I've seen in a lot of projects. I can't immediately think of a moment where it was highlighted by introducing a feature flag. Sometimes I think what can be tricky is if you have a feature that has a lot of cross-cutting concerns, then it's easy for that to kind of bleed into other things. There are a variety of techniques to try to, like you said, isolate the new code such that you don't need to conditionally branch on it everywhere. +I wonder if there might be maybe a few important inflection points that you could introduce some sort of wrapper or push a conditional higher up the decision tree or something like that that might get 50%-80% of the way there and at least eliminate a lot of the pain. +STEPHANIE: Yeah. I like the use of inflection points because I think that right now, our strategy has been everywhere as we are making changes, just putting it in as a guard when there's probably some degree of higher level thinking about, okay, we're now changing a bunch of internals of this class, but maybe the change that we're making is its own concept. And it could be a separate class, and that is when we choose to use that class like that as an inflection point. +JOËL: I have this vague mental model in my mind of building a mechanical system and wanting to know where do I want it to be rigid and where do I want some sort of joints so that it can flex? And I don't want the entire system to be made out of joints because now it's a pile of spaghetti. It's important to be rigid in a lot of places. But in some places, I do need it to flex. +And it's identifying what are those right places where it needs to bend to flex to different scenarios? And to me, that's a metaphor for when do we need abstractions, the ability to choose between different paths, the ability to maybe have some polymorphism? And when do we want to force everything to say, "No, all the code is going to behave in this one way?" +STEPHANIE: Yeah, that's a great point. I am also kind of stuck on what you said earlier, where the feature is very cross-cutting, and I think that is true for this project at hand. And so that has been very challenging too. There's also a lack of trust that it will just work with the other parts that it's touching because we're actually extending something that was already a bit of a unique flow or a kind of a one-off situation. And it was built very particularly to support that one thing. +And now here we are introducing something else for it to support and having to go in and change all of those individual places where we were making those one-off exceptions to now also be able to handle this new thing we're introducing. +JOËL: I think, in many cases, I appreciate when people write code in that way and that they didn't try to abstract everything on that first difference. But now that I'm the one coming in doing the second one now, it's time to think, okay, clearly, we're trying to flex here. We probably need some sort of abstraction. Unfortunately, that means it does have to come into the time budget for this feature and say, look, we already have a special case here. Now we're going to add a second special case. We need to take the time to do a little bit of refactoring or a little bit of abstracting in order to make that work properly. +STEPHANIE: Yeah, absolutely. I think the logic there originally was that, oh, we already have a special case for this thing. So it should be easy [laughs] to now add this other special case that's kind of based off of the original exception. And I actually think that worked against us a little bit because I'm mentioning we're introducing this new feature flag, and I'm also seeing remnants of that old feature flag that didn't get quite cleaned up as well, so just a lot more complexity in the different ways that the flow is going. +JOËL: In some ways, you kind of see earlier failures with this exact same approach that you're trying to take. So it's a bit of a warning. +STEPHANIE: Yeah. I want to avoid leaving those traces for future developers. There's definitely some degree of regret that I feel for all the times that I've introduced a feature flag and never cleaned [laughs] it up. So seeing just remnants of this same approach, like you mentioned, and wanting to do something differently to make sure that we aren't creating as much trouble for the next time around. +JOËL: So you'd brought up cross-cutting concerns earlier. And I think some common situations for that is like, oh, we've got some code that changed in the model where we have to put conditions. But then we also have a parallel condition in the controller and a parallel condition in the view, and maybe even in the routing file, and it quickly becomes a mess. Sometimes you're able to sort of take all of those, and kind of put them in a different part of the app. +So you might have a view file that is really complex and has all these conditionals. And maybe you kind of give up trying to make it all work in one file and say, you know what? For this special case, we're going to do it all in a separate view file. And maybe there's one top-level condition that says, if this thing is true, render the second view file; otherwise, render the first one. And now you've only got one condition instead of having it kind of sprinkled all over some other piece. +STEPHANIE: Yeah, that actually is the approach we ended up taking for this project. And in this case, we have React on the front end. So we're rendering a completely different React component based on the flag. And that did solve a lot of the front-end-specific complexity. And still, I think we are seeing a lot of the coupling be an issue on the back end, which is interesting. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So you'd mentioned queries and how...it sounds like there's maybe an enum in the database that you're adding a new state to, but you want to exclude that new state from any existing queries. I almost wonder if this is a situation where you want to create a sort of no-op commit that could go out without the feature flag, and that would basically prevent all the existing queries from using this new enum. And maybe it introduces the new enum but behind something that blocks them from being used in the existing queries. +Depending on how your queries are structured, maybe it's just in your main query; you have a where not extra line that excludes the values in that enum. If it's not nicely scoped, maybe you need some sort of default scope on the model to say, exclude anything that has this enum value. And now you can introduce that enum, and you can have all those records. And even if it's not behind a feature flag, everything will continue to work exactly as it does today, and that's your goal. +And that is a fairly small scoped change. It's almost like a refactor in the classic sense of it, the make the change easy before you make the easy change. Although, in your case, it's maybe not that easy of a change. But then, after that, you can build on top of this with your work that might be behind a feature flag. +STEPHANIE: Yeah, I like that approach a lot because that ensures that the existing behavior will continue to work as expected. And then that also is a good way to audit, I guess, all the places that we will need to consider when we are making the change. So we already have in mind all the places that things are touching, and it's not a surprise when we find out, oh, we missed this query, or whatever. +I was also thinking about...I mentioned that we are querying one-off quite a bit with different filters. I was also thinking that maybe a query object could be a good use case here and wrapping existing business logic in a meaningful query. And then perhaps the new enum that we're introducing would have its own conceptual meaning. +JOËL: When you talk about one-off queries, are these like custom queries built out directly in the view or in the controller? Or where are you seeing these one-off queries? +STEPHANIE: Unfortunately, it's both the controller and in-service classes. [chuckles] +JOËL: Okay. I was afraid you were going to say the view, which brings me back to my old PHP days because I definitely wrote queries in...I guess my entire app was basically the view at that time. I had just one PHP file, and HTML, SQL all went in there. The page submitted to itself. So there's a giant conditional that split the files like if POST versus if GET. +STEPHANIE: Oof, that sounds pretty gnarly. And I feel like; in that case, you don't have the tools for the flexibility that you would have liked. +JOËL: It turns out the frameworks are nice. It's a good thing to have. +STEPHANIE: Good take. +JOËL: I think going back to something we were talking earlier, we were talking about how to maybe incrementally ship parts of this, and the sort of no-op approach that I was talking about, I'm a huge fan of. I think it's similar to what's sometimes called the strangler fig pattern that allows you to sort of incrementally sometimes change over from one system to another. But I think a lot of the ideas from that pattern can apply to adding new behavior where you might want to start by introducing some sort of no-op system and then maybe conditionally branching within that and keeping things separate to then evolving to your final piece. +And there was an article that I am a huge fan of by Adrianna Chang on the Shopify Engineering blog about this pattern. We'll link it in the show notes. But for those who are interested in digging into this pattern more, kind of wondering how it applies, I recommend reading this article. +STEPHANIE: I'm really glad you mentioned that because the other thing I was thinking about that feels like such a trap with feature flags is that it kind of conflates two different things, at least in the way that I've seen it used on different teams where we are using it to hide work that we are incrementally shipping. +And then it's also used as a deployment strategy. So maybe you might turn it on for X percent of customers, or you might just turn it on to 100% for everyone. But if something goes wrong, you can quickly turn it off. And for some reason, I'm thinking that those two things...maybe I'm not sure that one tool is the best thing for both of those concerns. +JOËL: Yes. Sometimes feature flags are used to actually gate a feature. I tend to bucket the turning it on and turning it off as the same thing as turning it on for 50% of people. But sometimes, it's really used more for a kind of CI/CD process where you want everything that gets merged from a PR to immediately go out to the production server. But you might not be ready to have that particular feature get turned on just yet. But a lot of those things might get turned on pretty quickly, and then the feature flag might get removed fairly quickly as well. +So they're not really features in the sense of product people are going to want to be like, okay, now we're ready to turn on this new feature for the big release day. They're very logistical. And they're really almost like another way to do version control but at the release level rather than via Git. Does that sound like a reasonable distinction to you, or is that different than what you're talking about? +STEPHANIE: That's really interesting. I think you may have found a third [laughs] way that people use them because I have definitely seen that as well. I think for me, what you said about if you turn it on to 50% of people, that is essentially turning it on to 100% in the sense that if you are trying to mitigate risk and things go wrong, things are still wrong, and you have to figure out what to do then. +And I'm glad you mentioned the strangler fig pattern because I think people on teams that I've been on at least have been using feature flags as a crutch for managing risk when they deploy and thinking that, oh, if something goes wrong, then at least we have this mechanism to stop the bleeding. Whereas if you were making sure that the code you are writing is in production but doesn't change the existing behavior because of the way you wrote it, that is a lot more resilient, I think, than just opening the gates and hoping for the best and having a safety net of turning it off. +JOËL: I see what you're saying now. And I think you've hit on a really important thing. So when you're trying to build software incrementally, there's a bit of an anti-pattern where you go off on a long-running branch, and you build, and you build, and you build. And hopefully, you're keeping it in sync with the main branch, but maybe you're not. And at some point, there's a big merge, and it's scary and potentially dangerous. And then there's a release, and hopefully, everything goes well. And we generally agree that that style of development generally does not lead to the best outcomes. So we try to work incrementally. We try to merge back into the main branch as much as possible. +But I think that many developers are kind of wired to think in that long-running branch approach. And so they kind of try to recreate it with feature flags. So it's like, oh yeah, technically, we're merging, like, we're on small branches, and we're merging back into main, but it's all gated behind this one feature flag, and then it's going to be a big bang release. And it may or may not break, and it's going to be scary. And it's going to be a lot of risk that we're trying to mitigate. But the more we're piling on behind this feature flag, the higher the risk becomes. So it ends up being kind of a long-running branch. +STEPHANIE: Yeah, that's a really great connection. I think that is where some of the fear is coming from too. And we are thinking that, oh, we're relatively safe because we have this mechanism that at least we can react with very quickly rather than having to revert a change or something like that. But the way that we're using it on this project...and in general, I've seen other people do it this way. And that could be why this technique has proliferated a little bit. It is a bit concerning; I think, because it still is just okay; we're just going to release it and then hope for the best. +JOËL: I think there are valid use cases for that kind of strategy, but I would like to see those come from a product perspective rather than a development perspective. So maybe as a business strategy, we decide that this series of features, we want them all to kind of show up at the same time. They're part of a larger package of changes that we want to release all at once. Now you're getting into product strategy. Oftentimes, it's better to release small things incrementally. But there are some times where you want to release a big thing that has multiple kind of sub-features all at once, and I think that's totally valid. +Where I'm less comfortable with it is when it's coming from the developer side because it's more about, oh, we just want to protect all of these things and kind of release a massive change all at once. And that, I think, ideally is better managed by truly working incrementally with something like a strangler fig pattern. I think that manages to mitigate the risks while also avoiding some of the messiness that comes with the feature flag here. +STEPHANIE: Yeah, I think the other way of working that I've noticed with feature flags gating larger features is having a QA team member manually going through all of the features behind the feature flag to make sure things are working as expected. But that is still different from real users using it. I think that is another form of reassurance that folks think we're getting with this strategy. But I think it's still limited in covering a production use case which is ultimately giving you the truest [laughs] reassurance that your application is working as expected for the people that are using it. +JOËL: I think I'm fine with having a QA person turn a feature flag on on a staging server, try something out as part of the workflow as long as these features are generally kept small. And then we ship it, and we turn the feature flag on, and then maybe we remove it as part of the process later on. Where I get less comfortable is where you've got a team of people working for weeks behind a feature flag. And, again, I do understand that for product reasons, there are times where that's a valid thing, where there's a big set of changes that you don't want your customers to see. +But if it's for developer reasons because we're concerned about coupling or we're concerned that something could break, then I get really uncomfortable with saying, okay, we're going to have a team of people working for several weeks behind a feature flag, and then we're going to need multiple QA people to test a ton of work that's all behind a feature flag. Now you're just kind of creating new risk while also trying to mitigate it and it kind of turns into a sort of weird zero-sum game. +STEPHANIE: Yeah, I know what you mean. I think in those cases, too, you're only testing what you know. So you're only testing the edge cases and the different flows that you know about. And inevitably, customers are probably using the app [chuckles] in ways that are completely unexpected, and no amount of testing all the different cases that you think are comprehensive will account for the way that it's used by customers. +JOËL: To be fair, I think a good QA person will catch a lot of weird edge cases. They know a lot of the ways that customers will try weird things. They often are really good at not being boxed into product or development's ideas of how the product should be used rather than how it can be used. That being said, real customers are a surprising and creative bunch, and they will absolutely do the unexpected. +STEPHANIE: Yeah, that's a great point. I'm glad you mentioned that. +JOËL: We've talked about a few different ways where maybe you're uncertain or uncomfortable about feature flags. Are there ways of using feature flags that you are 100% in favor of or that you're excited about, like, yes, feature flags are a great use in this scenario? +STEPHANIE: First of all, I think one of the most delightful times that I've had with a feature flag is when we use the Flipper gem. At a previous company, I remember really enjoying that one over...I've seen more hand-rolled implementations of feature flags, but I do want to give that gem a little shout-out. I think they are most effective when you do have a new page or something that has a very clear boundary, and you want to make sure that no one can go to the URL and see the new features that way, at least that's like the most clear cut use case for them. +And then, ideally, you have implemented everything. You have tested behind the feature flag. And then, the day of the release, we can just turn that thing on, and all is well. I hate to be that person to say simpler is better, but sometimes I think that is true. What about you? Do you have any instances where you felt a feature flag was really effective? +JOËL: I appreciate feature flags in more traditional CD, continuous deployment-style systems, particularly once the team grows a little bit and you've got a lot of PRs going out. And you want to be able to maybe undo things without necessarily having to revert and redeploy code, or if you've got things where you don't want to have Git be the thing that's gating when customers get to see features. +So maybe a person implements it on a particular day, but you don't want customers to see it until next week because that's when your marketing has said, if we're going to turn it on, do you really want that to sit in a PR for a week and then hit the merge button and that's going to be what ships it out to people? Like, that gets kind of clunky. I think you can get away with it when you're a small, fast-moving team. It doesn't work once you start scaling a little bit. And so I find that at that point, starting to introduce feature flags has been really helpful on teams I've worked on. +And I've been part of that transition where we're feeling a lot of pain, and then we introduce feature flags and can move to more of a continuous deployment where you get your code reviewed; you merge it; it's good. And then it goes out, and at some point, we turn the feature on, and then maybe at some point, we come back and clean up the feature flag and say this is now permanently in. I've seen good success with that style of approach. +STEPHANIE: Yeah, you bring up a good point about incorporating it into the CI/CD process. And that also makes me think, ideally, we would have some information as developers about how long we want this thing to be in that feature flag state because if you know, then you can claim ownership over it and make sure that it gets cleaned up. I think right now, what I've seen is we are using it in the development process, but then we're not necessarily communicating with product about how long it's supposed to stay this way and what are we supposed to do with it afterwards. A lot of that gets lost. +JOËL: It is interesting that I think some feature flags are mainly product-focused, and then others are entirely developer-focused. In fact, maybe the product team doesn't even need to know that this is internally gated by a feature flag because it's more about internally how you manage the release process and continuous deployment. +The fact that maybe physically pushing the code onto the server and having a feature be available to users is not exactly the same action might be a distinction that doesn't really matter to your product team. And if that's not a thing that they care about toggling for users, then that can be something that just stays internal to the dev team. And you say, okay, we're using that to manage risk or to allow us to merge code earlier, whatever the thing is, but then we clean them up ourselves, and nobody needs to know. +Whereas some things are very much product-focused, and we say, okay, the product team wants this to be a thing they can turn on and off, or they want to run an experiment, and then they very much need to be in the know. And I think you were alluding to some feature flags that might be kind of halfway in between that. They're not clear-cut product ones, but they're not entirely just mechanical deployment flags. They kind of sit in that weird zone between the two. +STEPHANIE: Yeah, absolutely. I think maybe there is a case to be made about this distinction, and people can then better use this tool and apply it to the actual problem that they're having. +JOËL: I think it's helped me get a better feel for them by having a bit of that distinction in my mind, thinking of flags as these are either sort of mechanical developer flags, or these are products flags. And maybe there's a richer nomenclature that can be developed. But I think at least having that distinction has helped me think about these in a more structured fashion. +STEPHANIE: Yeah, and even communicating that in the name of the flag, too, I think could be really valuable for other developers who come across it in the codebase. As for cleaning them up, I was just thinking about how it can be such a pain to then unwind the logic of the feature flag [chuckles] when you're removing them to figure out, okay, now that this thing is done, how do we actually want it to work? I think sometimes that ends up being a bit of a pain point and is what leaves them hanging around. +JOËL: And then it's not obvious which of the two branches in a conditional should be kept. +STEPHANIE: Right. And maybe that also depends on that distinction where you're talking about between a product release flag and a more internal development tool. +JOËL: Yeah, I could definitely see a more product-focused one where it's possible that you might want to keep both and say, no, this is a thing that we want to be able to toggle on. In general, for the foreseeable future, don't remove this flag. I want to control it from a dashboard. Maybe we want this to become maybe not gated by a feature flag in the traditional sense, but we want to tie it to a subscription level on a user's profile. So keep all the conditionals in place, but now just branch off the user's subscription status rather than a global flag. +STEPHANIE: Yeah, it turns out that feature flags can be really complicated. It's not just kind of a binary is it on or off [laughs] situation. It almost makes me wonder if some metadata would be helpful with flags to signal more information about them in the codebase. Like, are they a part of your application domain or not? It kind of gets a little fuzzy. +JOËL: Definitely. Something could be experimental; something could be like we said, mechanical; something could be deeply integrated into the vision of the product where you know that you're going to want to branch in the future here for different types of customers. I've even been on projects that were multi-tenant, where we had just standard feature flagging setup, but different tenants would have different sets of flags turned on. So they were global configuration for their instance of the app, but each instance had their own unique config of flags turned on and off. +STEPHANIE: That's really interesting because, in some ways, flags are a bit of a configuration. But then, when you are combining a lot of different flags to configure something, then maybe that is better done with a different approach. +JOËL: I like doing that kind of thing with flags rather than configuration because then it can be done via an admin dashboard rather than having to make changes to a YAML or JSON and having to commit it. And in this particular projects case, it was really nice because it meant that we could sort of, again, find those flex points and say, okay, we know that some clients want things to behave in two or three different ways in this one particular place. We'll gate that behind a flag, and then you can enable the variant that you want for each client. And now the customer service reps can manage that, and not the dev team. +STEPHANIE: Got it. Yeah, that is pretty cool. +JOËL: So, in a way, feature flags can be a great way to empower other departments within the business instead of kind of centralizing control within the dev team. +STEPHANIE: Yeah. I suppose you just provided another use case for them. [laughs] +JOËL: I feel like there are probably some really interesting elements to dig into around the interaction between product design and the actual development of things and teams that are doing either business development or customer support. Or maybe just some kind of rep for a big client is sort of where a lot of the power to actually execute things is. That is not this episode today, but I think that could be a great follow-up episode to do sometime. +STEPHANIE: Yeah, that's very interesting. I would love to talk about that in the future. +JOËL: The short version is I'm a fan of empowering other people. +STEPHANIE: There you have it, folks. [laughs] You heard it here first. Joël is a fan of empowering other people. On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël submitted a last-minute submission to RailsConf discreet math, which got picked up! 🎉 He'll be speaking at RailsConf 2023 in Atlanta at the end of April about why it's relevant to developers and all the different practical ways he uses it daily.

+ +

Stephanie recommends headlamps for in-bed reading sessions and sets up the feature flags topic for today based on a project that must be released to the public in one go.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 a few episodes ago, we had a guest, Sara Jackson, on and she was talking about some cool elements of discrete math and how those can be really practically useful to us as developers in our day-to-day work. I was really inspired by that conversation. And the day we recorded that, I think, was the last day that the RailsConf CFP was open.

+ +

So I went and submitted a last-minute submission to RailsConf for this idea, and it got picked up. So I'm going to be speaking at RailsConf 2023 in Atlanta at the end of April about discrete math and why it's relevant to us as developers, and all the different practical ways that I use it on a daily basis.

+ +

STEPHANIE: That's awesome. Congrats, Joël. I'm so excited for this talk.

+ +

JOËL: Thanks.

+ +

STEPHANIE: Was this an 11:59 p.m. submission?

+ +

JOËL: Aaah, very close to that, yes. I don't recommend people to do this. But if inspiration hits you on the last day of the CFP, do it; go for it. I'd actually submitted two talk proposals. And I think maybe a little bit of the excitement in the energy for this last-minute one came through because that's the one that the committee picked.

+ +

STEPHANIE: How did you know that you would want to turn this topic into a talk?

+ +

JOËL: I think because I was excited to share about this to other people, and we'd kind of already done that on the show. But this is the sort of thing that's like, you know what? I'm kind of feeling a little bit of fire of this idea. I think more people should know about this. I think there's value in sharing this idea more broadly. What are some areas that I could do? I could maybe write a blog post. Oh, RailsConf, that's open until tonight. Let me put together a proposal because I'm excited about sharing this idea.

+ +

STEPHANIE: Yeah, I think we chatted a little bit about discrete math as potentially a fundamental pillar of information or a skill set for developers back in our episode on just the fundamentals of what developers need to know. And I was just thinking as you were talking about it that that was an audio medium, but it's obviously kind of an academic topic. And so to have slides for it and almost make it kind of like a little mini-lecture but more fun [laughs] than sitting in a classroom, I think, could be a really cool application of this topic.

+ +

JOËL: Yeah, I'm excited to take a very practical look at this. I've got 30 minutes to talk about it. I'm not going to give you the deep mathematical fundamentals. But if there are little bits of discrete math that I can show that are actually practically useful in a day-to-day situation, I think that would be incredibly valuable. So currently working on the talk, but the way I have it structured right now is very scenario-based. So we're going to look at some problems, look at just a tiny little bit of discrete math theory, and then see how that allows us to solve the underlying problem.

+ +

STEPHANIE: Nice. I won't be attending RailsConf this year, but I really look forward to watching the video when it comes out.

+ +

JOËL: Thank you. So, Stephanie, what's new in your world?

+ +

STEPHANIE: So last night I was reading in bed, and I usually stay up a little bit later than my partner. And so he was going to bed, and at that point, I usually turn off the bedside table lamp and either move to the couch to keep reading or just go to bed as well. But I was really engrossed in my book, and I wanted to keep going. But I was so cozy in bed. I really didn't want to move to the couch because then you risk falling asleep on the couch, and nobody likes that.

+ +

And so I was like, oh man, you know what I would really love? One of those book lights. And I got this really vivid memory of the clip-on ones I used to have as a kid that would clip onto the pages of my book and shine a light onto the page. And I was like, I feel like that technology must have gotten better [laughs] since I was a child. And I was like, okay, now I need to look up some doodad and buy a thing to help me solve this problem of reading in bed after hours.

+ +

And I was scrolling through my phone for a little bit, but then I was like, well, I want to read right now, not after [chuckles] I've purchased this gadget. And it hit me that we have headlamps that we use for our camping trips and also just if we ever are stuck without electricity. And I grabbed one of those from the junk drawer, and I wore it to bed and was reading my book. And it was a pretty good experience. So I'm actually pretty happy that I didn't need to buy a new thing to solve this problem of mine. And yeah, it turns out that you can just use something that you have at home.

+ +

JOËL: That's really cool. I feel like when I've used the headlamps before; normally, they're incredibly bright. Did you find that to be a problem for you?

+ +

STEPHANIE: I was able to adjust the brightness on mine, so it was definitely on the lower end of the setting and, overall, just better than having the nightstand lamp on, which I think just totally brightens the room. And at least this was a more targeted area of light, and it's working so far. He didn't wake up or anything, so I would call that a success. And now I have it in my bedside drawer. And I think I look really silly, but that's okay. No one can see me anyway. [laughs]

+ +

JOËL: That's kind of the whole point of it, right?

+ +

STEPHANIE: Exactly. [laughs] So, aside from my bedtime routine, another thing that's new in my world is something project-related. So I wanted to bring this up to you and get your thoughts on the situation. So I want to talk about feature flags because I'm currently working on a pretty big project that has to be released to the public in one go. And so naturally, we reached for using feature flags to be able to release our work to production but not to make it accessible to users so that we could be working on this thing incrementally and not have a huge release where all of this code goes out.

+ +

But as we've been building the feature, I am realizing that we are having to plug conditional code to check for this feature flag in a lot of different places. So, so far, we've been putting it in controllers. We've been putting it in a menu builder to show the user where they can navigate to. And then we've even been putting it inside of methods to change behavior based on whether the flag is on. And so that was kind of, I think, getting my spider senses a little bit tingling.

+ +

And then recently, one of the bigger issues that our team had a discussion about was whether to include this conditional check for the flag in queries. So we are building on top of an existing model. But once the feature flag is on and customers are using it, the application will be able to create new records for that model. But they're of a different category with a different value for one of the attributes. And we end up clearing for this model in a lot of one-off places.

+ +

And so once this thing is on, all of the records that are specific to this new feature will be included whenever we query for this model. And as we've been developing, it's been less of an issue because customers can't access the flow to create these new records. But someone brought up what if we release this, and it turns out that we have an issue and we want to turn it off; we want to roll it back? And at that point, those records will still have been created in the database and will then be included in those queries and what do we do then?

+ +

And so we started getting into the weeds a little bit of, like, do we want to have some conditional query situation going on? We haven't quite landed on an answer, but things are getting a little hairy. And I am curious if this works. Any thoughts for you?

+ +

JOËL: That's a really interesting problem to have. You mentioned having all of these conditionals kind of sprinkled everywhere for the feature flag kind of triggered your spidey senses a little bit. Do you have a sense a little bit of maybe why that feels wrong or maybe why you're feeling uncomfortable about this code?

+ +

STEPHANIE: Yeah, I was thinking about it, and, in my opinion, the ideal world for feature flags would be you have the checks at the boundaries of your code or where a customer could interact with the application. And then you are able to, I guess, branch a little earlier so that they don't go down the flow at all where the changes are being made. And this seems to be a little bit of the opposite, where we end up having to check in a million different places because we aren't keeping that separation as explicit as I think it should be.

+ +

JOËL: Hmm, so almost like it's not the feature flag that's the problem. The feature flag is just a symptom of tight coupling in the wider system.

+ +

STEPHANIE: Yeah, that's definitely a smell that has emerged. But I also don't think that we have the luxury necessarily to decouple all of the places in the code as we are trying to add this new feature. Have you been in a situation like this before?

+ +

JOËL: I think tight coupling, in general, is a thing I've seen in a lot of projects. I can't immediately think of a moment where it was highlighted by introducing a feature flag. Sometimes I think what can be tricky is if you have a feature that has a lot of cross-cutting concerns, then it's easy for that to kind of bleed into other things. There are a variety of techniques to try to, like you said, isolate the new code such that you don't need to conditionally branch on it everywhere.

+ +

I wonder if there might be maybe a few important inflection points that you could introduce some sort of wrapper or push a conditional higher up the decision tree or something like that that might get 50%-80% of the way there and at least eliminate a lot of the pain.

+ +

STEPHANIE: Yeah. I like the use of inflection points because I think that right now, our strategy has been everywhere as we are making changes, just putting it in as a guard when there's probably some degree of higher level thinking about, okay, we're now changing a bunch of internals of this class, but maybe the change that we're making is its own concept. And it could be a separate class, and that is when we choose to use that class like that as an inflection point.

+ +

JOËL: I have this vague mental model in my mind of building a mechanical system and wanting to know where do I want it to be rigid and where do I want some sort of joints so that it can flex? And I don't want the entire system to be made out of joints because now it's a pile of spaghetti. It's important to be rigid in a lot of places. But in some places, I do need it to flex.

+ +

And it's identifying what are those right places where it needs to bend to flex to different scenarios? And to me, that's a metaphor for when do we need abstractions, the ability to choose between different paths, the ability to maybe have some polymorphism? And when do we want to force everything to say, "No, all the code is going to behave in this one way?"

+ +

STEPHANIE: Yeah, that's a great point. I am also kind of stuck on what you said earlier, where the feature is very cross-cutting, and I think that is true for this project at hand. And so that has been very challenging too. There's also a lack of trust that it will just work with the other parts that it's touching because we're actually extending something that was already a bit of a unique flow or a kind of a one-off situation. And it was built very particularly to support that one thing.

+ +

And now here we are introducing something else for it to support and having to go in and change all of those individual places where we were making those one-off exceptions to now also be able to handle this new thing we're introducing.

+ +

JOËL: I think, in many cases, I appreciate when people write code in that way and that they didn't try to abstract everything on that first difference. But now that I'm the one coming in doing the second one now, it's time to think, okay, clearly, we're trying to flex here. We probably need some sort of abstraction. Unfortunately, that means it does have to come into the time budget for this feature and say, look, we already have a special case here. Now we're going to add a second special case. We need to take the time to do a little bit of refactoring or a little bit of abstracting in order to make that work properly.

+ +

STEPHANIE: Yeah, absolutely. I think the logic there originally was that, oh, we already have a special case for this thing. So it should be easy [laughs] to now add this other special case that's kind of based off of the original exception. And I actually think that worked against us a little bit because I'm mentioning we're introducing this new feature flag, and I'm also seeing remnants of that old feature flag that didn't get quite cleaned up as well, so just a lot more complexity in the different ways that the flow is going.

+ +

JOËL: In some ways, you kind of see earlier failures with this exact same approach that you're trying to take. So it's a bit of a warning.

+ +

STEPHANIE: Yeah. I want to avoid leaving those traces for future developers. There's definitely some degree of regret that I feel for all the times that I've introduced a feature flag and never cleaned [laughs] it up. So seeing just remnants of this same approach, like you mentioned, and wanting to do something differently to make sure that we aren't creating as much trouble for the next time around.

+ +

JOËL: So you'd brought up cross-cutting concerns earlier. And I think some common situations for that is like, oh, we've got some code that changed in the model where we have to put conditions. But then we also have a parallel condition in the controller and a parallel condition in the view, and maybe even in the routing file, and it quickly becomes a mess. Sometimes you're able to sort of take all of those, and kind of put them in a different part of the app.

+ +

So you might have a view file that is really complex and has all these conditionals. And maybe you kind of give up trying to make it all work in one file and say, you know what? For this special case, we're going to do it all in a separate view file. And maybe there's one top-level condition that says, if this thing is true, render the second view file; otherwise, render the first one. And now you've only got one condition instead of having it kind of sprinkled all over some other piece.

+ +

STEPHANIE: Yeah, that actually is the approach we ended up taking for this project. And in this case, we have React on the front end. So we're rendering a completely different React component based on the flag. And that did solve a lot of the front-end-specific complexity. And still, I think we are seeing a lot of the coupling be an issue on the back end, which is interesting.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you'd mentioned queries and how...it sounds like there's maybe an enum in the database that you're adding a new state to, but you want to exclude that new state from any existing queries. I almost wonder if this is a situation where you want to create a sort of no-op commit that could go out without the feature flag, and that would basically prevent all the existing queries from using this new enum. And maybe it introduces the new enum but behind something that blocks them from being used in the existing queries.

+ +

Depending on how your queries are structured, maybe it's just in your main query; you have a where not extra line that excludes the values in that enum. If it's not nicely scoped, maybe you need some sort of default scope on the model to say, exclude anything that has this enum value. And now you can introduce that enum, and you can have all those records. And even if it's not behind a feature flag, everything will continue to work exactly as it does today, and that's your goal.

+ +

And that is a fairly small scoped change. It's almost like a refactor in the classic sense of it, the make the change easy before you make the easy change. Although, in your case, it's maybe not that easy of a change. But then, after that, you can build on top of this with your work that might be behind a feature flag.

+ +

STEPHANIE: Yeah, I like that approach a lot because that ensures that the existing behavior will continue to work as expected. And then that also is a good way to audit, I guess, all the places that we will need to consider when we are making the change. So we already have in mind all the places that things are touching, and it's not a surprise when we find out, oh, we missed this query, or whatever.

+ +

I was also thinking about...I mentioned that we are querying one-off quite a bit with different filters. I was also thinking that maybe a query object could be a good use case here and wrapping existing business logic in a meaningful query. And then perhaps the new enum that we're introducing would have its own conceptual meaning.

+ +

JOËL: When you talk about one-off queries, are these like custom queries built out directly in the view or in the controller? Or where are you seeing these one-off queries?

+ +

STEPHANIE: Unfortunately, it's both the controller and in-service classes. [chuckles]

+ +

JOËL: Okay. I was afraid you were going to say the view, which brings me back to my old PHP days because I definitely wrote queries in...I guess my entire app was basically the view at that time. I had just one PHP file, and HTML, SQL all went in there. The page submitted to itself. So there's a giant conditional that split the files like if POST versus if GET.

+ +

STEPHANIE: Oof, that sounds pretty gnarly. And I feel like; in that case, you don't have the tools for the flexibility that you would have liked.

+ +

JOËL: It turns out the frameworks are nice. It's a good thing to have.

+ +

STEPHANIE: Good take.

+ +

JOËL: I think going back to something we were talking earlier, we were talking about how to maybe incrementally ship parts of this, and the sort of no-op approach that I was talking about, I'm a huge fan of. I think it's similar to what's sometimes called the strangler fig pattern that allows you to sort of incrementally sometimes change over from one system to another. But I think a lot of the ideas from that pattern can apply to adding new behavior where you might want to start by introducing some sort of no-op system and then maybe conditionally branching within that and keeping things separate to then evolving to your final piece.

+ +

And there was an article that I am a huge fan of by Adrianna Chang on the Shopify Engineering blog about this pattern. We'll link it in the show notes. But for those who are interested in digging into this pattern more, kind of wondering how it applies, I recommend reading this article.

+ +

STEPHANIE: I'm really glad you mentioned that because the other thing I was thinking about that feels like such a trap with feature flags is that it kind of conflates two different things, at least in the way that I've seen it used on different teams where we are using it to hide work that we are incrementally shipping.

+ +

And then it's also used as a deployment strategy. So maybe you might turn it on for X percent of customers, or you might just turn it on to 100% for everyone. But if something goes wrong, you can quickly turn it off. And for some reason, I'm thinking that those two things...maybe I'm not sure that one tool is the best thing for both of those concerns.

+ +

JOËL: Yes. Sometimes feature flags are used to actually gate a feature. I tend to bucket the turning it on and turning it off as the same thing as turning it on for 50% of people. But sometimes, it's really used more for a kind of CI/CD process where you want everything that gets merged from a PR to immediately go out to the production server. But you might not be ready to have that particular feature get turned on just yet. But a lot of those things might get turned on pretty quickly, and then the feature flag might get removed fairly quickly as well.

+ +

So they're not really features in the sense of product people are going to want to be like, okay, now we're ready to turn on this new feature for the big release day. They're very logistical. And they're really almost like another way to do version control but at the release level rather than via Git. Does that sound like a reasonable distinction to you, or is that different than what you're talking about?

+ +

STEPHANIE: That's really interesting. I think you may have found a third [laughs] way that people use them because I have definitely seen that as well. I think for me, what you said about if you turn it on to 50% of people, that is essentially turning it on to 100% in the sense that if you are trying to mitigate risk and things go wrong, things are still wrong, and you have to figure out what to do then.

+ +

And I'm glad you mentioned the strangler fig pattern because I think people on teams that I've been on at least have been using feature flags as a crutch for managing risk when they deploy and thinking that, oh, if something goes wrong, then at least we have this mechanism to stop the bleeding. Whereas if you were making sure that the code you are writing is in production but doesn't change the existing behavior because of the way you wrote it, that is a lot more resilient, I think, than just opening the gates and hoping for the best and having a safety net of turning it off.

+ +

JOËL: I see what you're saying now. And I think you've hit on a really important thing. So when you're trying to build software incrementally, there's a bit of an anti-pattern where you go off on a long-running branch, and you build, and you build, and you build. And hopefully, you're keeping it in sync with the main branch, but maybe you're not. And at some point, there's a big merge, and it's scary and potentially dangerous. And then there's a release, and hopefully, everything goes well. And we generally agree that that style of development generally does not lead to the best outcomes. So we try to work incrementally. We try to merge back into the main branch as much as possible.

+ +

But I think that many developers are kind of wired to think in that long-running branch approach. And so they kind of try to recreate it with feature flags. So it's like, oh yeah, technically, we're merging, like, we're on small branches, and we're merging back into main, but it's all gated behind this one feature flag, and then it's going to be a big bang release. And it may or may not break, and it's going to be scary. And it's going to be a lot of risk that we're trying to mitigate. But the more we're piling on behind this feature flag, the higher the risk becomes. So it ends up being kind of a long-running branch.

+ +

STEPHANIE: Yeah, that's a really great connection. I think that is where some of the fear is coming from too. And we are thinking that, oh, we're relatively safe because we have this mechanism that at least we can react with very quickly rather than having to revert a change or something like that. But the way that we're using it on this project...and in general, I've seen other people do it this way. And that could be why this technique has proliferated a little bit. It is a bit concerning; I think, because it still is just okay; we're just going to release it and then hope for the best.

+ +

JOËL: I think there are valid use cases for that kind of strategy, but I would like to see those come from a product perspective rather than a development perspective. So maybe as a business strategy, we decide that this series of features, we want them all to kind of show up at the same time. They're part of a larger package of changes that we want to release all at once. Now you're getting into product strategy. Oftentimes, it's better to release small things incrementally. But there are some times where you want to release a big thing that has multiple kind of sub-features all at once, and I think that's totally valid.

+ +

Where I'm less comfortable with it is when it's coming from the developer side because it's more about, oh, we just want to protect all of these things and kind of release a massive change all at once. And that, I think, ideally is better managed by truly working incrementally with something like a strangler fig pattern. I think that manages to mitigate the risks while also avoiding some of the messiness that comes with the feature flag here.

+ +

STEPHANIE: Yeah, I think the other way of working that I've noticed with feature flags gating larger features is having a QA team member manually going through all of the features behind the feature flag to make sure things are working as expected. But that is still different from real users using it. I think that is another form of reassurance that folks think we're getting with this strategy. But I think it's still limited in covering a production use case which is ultimately giving you the truest [laughs] reassurance that your application is working as expected for the people that are using it.

+ +

JOËL: I think I'm fine with having a QA person turn a feature flag on on a staging server, try something out as part of the workflow as long as these features are generally kept small. And then we ship it, and we turn the feature flag on, and then maybe we remove it as part of the process later on. Where I get less comfortable is where you've got a team of people working for weeks behind a feature flag. And, again, I do understand that for product reasons, there are times where that's a valid thing, where there's a big set of changes that you don't want your customers to see.

+ +

But if it's for developer reasons because we're concerned about coupling or we're concerned that something could break, then I get really uncomfortable with saying, okay, we're going to have a team of people working for several weeks behind a feature flag, and then we're going to need multiple QA people to test a ton of work that's all behind a feature flag. Now you're just kind of creating new risk while also trying to mitigate it and it kind of turns into a sort of weird zero-sum game.

+ +

STEPHANIE: Yeah, I know what you mean. I think in those cases, too, you're only testing what you know. So you're only testing the edge cases and the different flows that you know about. And inevitably, customers are probably using the app [chuckles] in ways that are completely unexpected, and no amount of testing all the different cases that you think are comprehensive will account for the way that it's used by customers.

+ +

JOËL: To be fair, I think a good QA person will catch a lot of weird edge cases. They know a lot of the ways that customers will try weird things. They often are really good at not being boxed into product or development's ideas of how the product should be used rather than how it can be used. That being said, real customers are a surprising and creative bunch, and they will absolutely do the unexpected.

+ +

STEPHANIE: Yeah, that's a great point. I'm glad you mentioned that.

+ +

JOËL: We've talked about a few different ways where maybe you're uncertain or uncomfortable about feature flags. Are there ways of using feature flags that you are 100% in favor of or that you're excited about, like, yes, feature flags are a great use in this scenario?

+ +

STEPHANIE: First of all, I think one of the most delightful times that I've had with a feature flag is when we use the Flipper gem. At a previous company, I remember really enjoying that one over...I've seen more hand-rolled implementations of feature flags, but I do want to give that gem a little shout-out. I think they are most effective when you do have a new page or something that has a very clear boundary, and you want to make sure that no one can go to the URL and see the new features that way, at least that's like the most clear cut use case for them.

+ +

And then, ideally, you have implemented everything. You have tested behind the feature flag. And then, the day of the release, we can just turn that thing on, and all is well. I hate to be that person to say simpler is better, but sometimes I think that is true. What about you? Do you have any instances where you felt a feature flag was really effective?

+ +

JOËL: I appreciate feature flags in more traditional CD, continuous deployment-style systems, particularly once the team grows a little bit and you've got a lot of PRs going out. And you want to be able to maybe undo things without necessarily having to revert and redeploy code, or if you've got things where you don't want to have Git be the thing that's gating when customers get to see features.

+ +

So maybe a person implements it on a particular day, but you don't want customers to see it until next week because that's when your marketing has said, if we're going to turn it on, do you really want that to sit in a PR for a week and then hit the merge button and that's going to be what ships it out to people? Like, that gets kind of clunky. I think you can get away with it when you're a small, fast-moving team. It doesn't work once you start scaling a little bit. And so I find that at that point, starting to introduce feature flags has been really helpful on teams I've worked on.

+ +

And I've been part of that transition where we're feeling a lot of pain, and then we introduce feature flags and can move to more of a continuous deployment where you get your code reviewed; you merge it; it's good. And then it goes out, and at some point, we turn the feature on, and then maybe at some point, we come back and clean up the feature flag and say this is now permanently in. I've seen good success with that style of approach.

+ +

STEPHANIE: Yeah, you bring up a good point about incorporating it into the CI/CD process. And that also makes me think, ideally, we would have some information as developers about how long we want this thing to be in that feature flag state because if you know, then you can claim ownership over it and make sure that it gets cleaned up. I think right now, what I've seen is we are using it in the development process, but then we're not necessarily communicating with product about how long it's supposed to stay this way and what are we supposed to do with it afterwards. A lot of that gets lost.

+ +

JOËL: It is interesting that I think some feature flags are mainly product-focused, and then others are entirely developer-focused. In fact, maybe the product team doesn't even need to know that this is internally gated by a feature flag because it's more about internally how you manage the release process and continuous deployment.

+ +

The fact that maybe physically pushing the code onto the server and having a feature be available to users is not exactly the same action might be a distinction that doesn't really matter to your product team. And if that's not a thing that they care about toggling for users, then that can be something that just stays internal to the dev team. And you say, okay, we're using that to manage risk or to allow us to merge code earlier, whatever the thing is, but then we clean them up ourselves, and nobody needs to know.

+ +

Whereas some things are very much product-focused, and we say, okay, the product team wants this to be a thing they can turn on and off, or they want to run an experiment, and then they very much need to be in the know. And I think you were alluding to some feature flags that might be kind of halfway in between that. They're not clear-cut product ones, but they're not entirely just mechanical deployment flags. They kind of sit in that weird zone between the two.

+ +

STEPHANIE: Yeah, absolutely. I think maybe there is a case to be made about this distinction, and people can then better use this tool and apply it to the actual problem that they're having.

+ +

JOËL: I think it's helped me get a better feel for them by having a bit of that distinction in my mind, thinking of flags as these are either sort of mechanical developer flags, or these are products flags. And maybe there's a richer nomenclature that can be developed. But I think at least having that distinction has helped me think about these in a more structured fashion.

+ +

STEPHANIE: Yeah, and even communicating that in the name of the flag, too, I think could be really valuable for other developers who come across it in the codebase. As for cleaning them up, I was just thinking about how it can be such a pain to then unwind the logic of the feature flag [chuckles] when you're removing them to figure out, okay, now that this thing is done, how do we actually want it to work? I think sometimes that ends up being a bit of a pain point and is what leaves them hanging around.

+ +

JOËL: And then it's not obvious which of the two branches in a conditional should be kept.

+ +

STEPHANIE: Right. And maybe that also depends on that distinction where you're talking about between a product release flag and a more internal development tool.

+ +

JOËL: Yeah, I could definitely see a more product-focused one where it's possible that you might want to keep both and say, no, this is a thing that we want to be able to toggle on. In general, for the foreseeable future, don't remove this flag. I want to control it from a dashboard. Maybe we want this to become maybe not gated by a feature flag in the traditional sense, but we want to tie it to a subscription level on a user's profile. So keep all the conditionals in place, but now just branch off the user's subscription status rather than a global flag.

+ +

STEPHANIE: Yeah, it turns out that feature flags can be really complicated. It's not just kind of a binary is it on or off [laughs] situation. It almost makes me wonder if some metadata would be helpful with flags to signal more information about them in the codebase. Like, are they a part of your application domain or not? It kind of gets a little fuzzy.

+ +

JOËL: Definitely. Something could be experimental; something could be like we said, mechanical; something could be deeply integrated into the vision of the product where you know that you're going to want to branch in the future here for different types of customers. I've even been on projects that were multi-tenant, where we had just standard feature flagging setup, but different tenants would have different sets of flags turned on. So they were global configuration for their instance of the app, but each instance had their own unique config of flags turned on and off.

+ +

STEPHANIE: That's really interesting because, in some ways, flags are a bit of a configuration. But then, when you are combining a lot of different flags to configure something, then maybe that is better done with a different approach.

+ +

JOËL: I like doing that kind of thing with flags rather than configuration because then it can be done via an admin dashboard rather than having to make changes to a YAML or JSON and having to commit it. And in this particular projects case, it was really nice because it meant that we could sort of, again, find those flex points and say, okay, we know that some clients want things to behave in two or three different ways in this one particular place. We'll gate that behind a flag, and then you can enable the variant that you want for each client. And now the customer service reps can manage that, and not the dev team.

+ +

STEPHANIE: Got it. Yeah, that is pretty cool.

+ +

JOËL: So, in a way, feature flags can be a great way to empower other departments within the business instead of kind of centralizing control within the dev team.

+ +

STEPHANIE: Yeah. I suppose you just provided another use case for them. [laughs]

+ +

JOËL: I feel like there are probably some really interesting elements to dig into around the interaction between product design and the actual development of things and teams that are doing either business development or customer support. Or maybe just some kind of rep for a big client is sort of where a lot of the power to actually execute things is. That is not this episode today, but I think that could be a great follow-up episode to do sometime.

+ +

STEPHANIE: Yeah, that's very interesting. I would love to talk about that in the future.

+ +

JOËL: The short version is I'm a fan of empowering other people.

+ +

STEPHANIE: There you have it, folks. [laughs] You heard it here first. Joël is a fan of empowering other people. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël submitted a last-minute submission to RailsConf discreet math, which got picked up! 🎉 He'll be speaking at RailsConf 2023 in Atlanta at the end of April about why it's relevant to developers and all the different practical ways he uses it daily.

+ +

Stephanie recommends headlamps for in-bed reading sessions and sets up the feature flags topic for today based on a project that must be released to the public in one go.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 a few episodes ago, we had a guest, Sara Jackson, on and she was talking about some cool elements of discrete math and how those can be really practically useful to us as developers in our day-to-day work. I was really inspired by that conversation. And the day we recorded that, I think, was the last day that the RailsConf CFP was open.

+ +

So I went and submitted a last-minute submission to RailsConf for this idea, and it got picked up. So I'm going to be speaking at RailsConf 2023 in Atlanta at the end of April about discrete math and why it's relevant to us as developers, and all the different practical ways that I use it on a daily basis.

+ +

STEPHANIE: That's awesome. Congrats, Joël. I'm so excited for this talk.

+ +

JOËL: Thanks.

+ +

STEPHANIE: Was this an 11:59 p.m. submission?

+ +

JOËL: Aaah, very close to that, yes. I don't recommend people to do this. But if inspiration hits you on the last day of the CFP, do it; go for it. I'd actually submitted two talk proposals. And I think maybe a little bit of the excitement in the energy for this last-minute one came through because that's the one that the committee picked.

+ +

STEPHANIE: How did you know that you would want to turn this topic into a talk?

+ +

JOËL: I think because I was excited to share about this to other people, and we'd kind of already done that on the show. But this is the sort of thing that's like, you know what? I'm kind of feeling a little bit of fire of this idea. I think more people should know about this. I think there's value in sharing this idea more broadly. What are some areas that I could do? I could maybe write a blog post. Oh, RailsConf, that's open until tonight. Let me put together a proposal because I'm excited about sharing this idea.

+ +

STEPHANIE: Yeah, I think we chatted a little bit about discrete math as potentially a fundamental pillar of information or a skill set for developers back in our episode on just the fundamentals of what developers need to know. And I was just thinking as you were talking about it that that was an audio medium, but it's obviously kind of an academic topic. And so to have slides for it and almost make it kind of like a little mini-lecture but more fun [laughs] than sitting in a classroom, I think, could be a really cool application of this topic.

+ +

JOËL: Yeah, I'm excited to take a very practical look at this. I've got 30 minutes to talk about it. I'm not going to give you the deep mathematical fundamentals. But if there are little bits of discrete math that I can show that are actually practically useful in a day-to-day situation, I think that would be incredibly valuable. So currently working on the talk, but the way I have it structured right now is very scenario-based. So we're going to look at some problems, look at just a tiny little bit of discrete math theory, and then see how that allows us to solve the underlying problem.

+ +

STEPHANIE: Nice. I won't be attending RailsConf this year, but I really look forward to watching the video when it comes out.

+ +

JOËL: Thank you. So, Stephanie, what's new in your world?

+ +

STEPHANIE: So last night I was reading in bed, and I usually stay up a little bit later than my partner. And so he was going to bed, and at that point, I usually turn off the bedside table lamp and either move to the couch to keep reading or just go to bed as well. But I was really engrossed in my book, and I wanted to keep going. But I was so cozy in bed. I really didn't want to move to the couch because then you risk falling asleep on the couch, and nobody likes that.

+ +

And so I was like, oh man, you know what I would really love? One of those book lights. And I got this really vivid memory of the clip-on ones I used to have as a kid that would clip onto the pages of my book and shine a light onto the page. And I was like, I feel like that technology must have gotten better [laughs] since I was a child. And I was like, okay, now I need to look up some doodad and buy a thing to help me solve this problem of reading in bed after hours.

+ +

And I was scrolling through my phone for a little bit, but then I was like, well, I want to read right now, not after [chuckles] I've purchased this gadget. And it hit me that we have headlamps that we use for our camping trips and also just if we ever are stuck without electricity. And I grabbed one of those from the junk drawer, and I wore it to bed and was reading my book. And it was a pretty good experience. So I'm actually pretty happy that I didn't need to buy a new thing to solve this problem of mine. And yeah, it turns out that you can just use something that you have at home.

+ +

JOËL: That's really cool. I feel like when I've used the headlamps before; normally, they're incredibly bright. Did you find that to be a problem for you?

+ +

STEPHANIE: I was able to adjust the brightness on mine, so it was definitely on the lower end of the setting and, overall, just better than having the nightstand lamp on, which I think just totally brightens the room. And at least this was a more targeted area of light, and it's working so far. He didn't wake up or anything, so I would call that a success. And now I have it in my bedside drawer. And I think I look really silly, but that's okay. No one can see me anyway. [laughs]

+ +

JOËL: That's kind of the whole point of it, right?

+ +

STEPHANIE: Exactly. [laughs] So, aside from my bedtime routine, another thing that's new in my world is something project-related. So I wanted to bring this up to you and get your thoughts on the situation. So I want to talk about feature flags because I'm currently working on a pretty big project that has to be released to the public in one go. And so naturally, we reached for using feature flags to be able to release our work to production but not to make it accessible to users so that we could be working on this thing incrementally and not have a huge release where all of this code goes out.

+ +

But as we've been building the feature, I am realizing that we are having to plug conditional code to check for this feature flag in a lot of different places. So, so far, we've been putting it in controllers. We've been putting it in a menu builder to show the user where they can navigate to. And then we've even been putting it inside of methods to change behavior based on whether the flag is on. And so that was kind of, I think, getting my spider senses a little bit tingling.

+ +

And then recently, one of the bigger issues that our team had a discussion about was whether to include this conditional check for the flag in queries. So we are building on top of an existing model. But once the feature flag is on and customers are using it, the application will be able to create new records for that model. But they're of a different category with a different value for one of the attributes. And we end up clearing for this model in a lot of one-off places.

+ +

And so once this thing is on, all of the records that are specific to this new feature will be included whenever we query for this model. And as we've been developing, it's been less of an issue because customers can't access the flow to create these new records. But someone brought up what if we release this, and it turns out that we have an issue and we want to turn it off; we want to roll it back? And at that point, those records will still have been created in the database and will then be included in those queries and what do we do then?

+ +

And so we started getting into the weeds a little bit of, like, do we want to have some conditional query situation going on? We haven't quite landed on an answer, but things are getting a little hairy. And I am curious if this works. Any thoughts for you?

+ +

JOËL: That's a really interesting problem to have. You mentioned having all of these conditionals kind of sprinkled everywhere for the feature flag kind of triggered your spidey senses a little bit. Do you have a sense a little bit of maybe why that feels wrong or maybe why you're feeling uncomfortable about this code?

+ +

STEPHANIE: Yeah, I was thinking about it, and, in my opinion, the ideal world for feature flags would be you have the checks at the boundaries of your code or where a customer could interact with the application. And then you are able to, I guess, branch a little earlier so that they don't go down the flow at all where the changes are being made. And this seems to be a little bit of the opposite, where we end up having to check in a million different places because we aren't keeping that separation as explicit as I think it should be.

+ +

JOËL: Hmm, so almost like it's not the feature flag that's the problem. The feature flag is just a symptom of tight coupling in the wider system.

+ +

STEPHANIE: Yeah, that's definitely a smell that has emerged. But I also don't think that we have the luxury necessarily to decouple all of the places in the code as we are trying to add this new feature. Have you been in a situation like this before?

+ +

JOËL: I think tight coupling, in general, is a thing I've seen in a lot of projects. I can't immediately think of a moment where it was highlighted by introducing a feature flag. Sometimes I think what can be tricky is if you have a feature that has a lot of cross-cutting concerns, then it's easy for that to kind of bleed into other things. There are a variety of techniques to try to, like you said, isolate the new code such that you don't need to conditionally branch on it everywhere.

+ +

I wonder if there might be maybe a few important inflection points that you could introduce some sort of wrapper or push a conditional higher up the decision tree or something like that that might get 50%-80% of the way there and at least eliminate a lot of the pain.

+ +

STEPHANIE: Yeah. I like the use of inflection points because I think that right now, our strategy has been everywhere as we are making changes, just putting it in as a guard when there's probably some degree of higher level thinking about, okay, we're now changing a bunch of internals of this class, but maybe the change that we're making is its own concept. And it could be a separate class, and that is when we choose to use that class like that as an inflection point.

+ +

JOËL: I have this vague mental model in my mind of building a mechanical system and wanting to know where do I want it to be rigid and where do I want some sort of joints so that it can flex? And I don't want the entire system to be made out of joints because now it's a pile of spaghetti. It's important to be rigid in a lot of places. But in some places, I do need it to flex.

+ +

And it's identifying what are those right places where it needs to bend to flex to different scenarios? And to me, that's a metaphor for when do we need abstractions, the ability to choose between different paths, the ability to maybe have some polymorphism? And when do we want to force everything to say, "No, all the code is going to behave in this one way?"

+ +

STEPHANIE: Yeah, that's a great point. I am also kind of stuck on what you said earlier, where the feature is very cross-cutting, and I think that is true for this project at hand. And so that has been very challenging too. There's also a lack of trust that it will just work with the other parts that it's touching because we're actually extending something that was already a bit of a unique flow or a kind of a one-off situation. And it was built very particularly to support that one thing.

+ +

And now here we are introducing something else for it to support and having to go in and change all of those individual places where we were making those one-off exceptions to now also be able to handle this new thing we're introducing.

+ +

JOËL: I think, in many cases, I appreciate when people write code in that way and that they didn't try to abstract everything on that first difference. But now that I'm the one coming in doing the second one now, it's time to think, okay, clearly, we're trying to flex here. We probably need some sort of abstraction. Unfortunately, that means it does have to come into the time budget for this feature and say, look, we already have a special case here. Now we're going to add a second special case. We need to take the time to do a little bit of refactoring or a little bit of abstracting in order to make that work properly.

+ +

STEPHANIE: Yeah, absolutely. I think the logic there originally was that, oh, we already have a special case for this thing. So it should be easy [laughs] to now add this other special case that's kind of based off of the original exception. And I actually think that worked against us a little bit because I'm mentioning we're introducing this new feature flag, and I'm also seeing remnants of that old feature flag that didn't get quite cleaned up as well, so just a lot more complexity in the different ways that the flow is going.

+ +

JOËL: In some ways, you kind of see earlier failures with this exact same approach that you're trying to take. So it's a bit of a warning.

+ +

STEPHANIE: Yeah. I want to avoid leaving those traces for future developers. There's definitely some degree of regret that I feel for all the times that I've introduced a feature flag and never cleaned [laughs] it up. So seeing just remnants of this same approach, like you mentioned, and wanting to do something differently to make sure that we aren't creating as much trouble for the next time around.

+ +

JOËL: So you'd brought up cross-cutting concerns earlier. And I think some common situations for that is like, oh, we've got some code that changed in the model where we have to put conditions. But then we also have a parallel condition in the controller and a parallel condition in the view, and maybe even in the routing file, and it quickly becomes a mess. Sometimes you're able to sort of take all of those, and kind of put them in a different part of the app.

+ +

So you might have a view file that is really complex and has all these conditionals. And maybe you kind of give up trying to make it all work in one file and say, you know what? For this special case, we're going to do it all in a separate view file. And maybe there's one top-level condition that says, if this thing is true, render the second view file; otherwise, render the first one. And now you've only got one condition instead of having it kind of sprinkled all over some other piece.

+ +

STEPHANIE: Yeah, that actually is the approach we ended up taking for this project. And in this case, we have React on the front end. So we're rendering a completely different React component based on the flag. And that did solve a lot of the front-end-specific complexity. And still, I think we are seeing a lot of the coupling be an issue on the back end, which is interesting.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you'd mentioned queries and how...it sounds like there's maybe an enum in the database that you're adding a new state to, but you want to exclude that new state from any existing queries. I almost wonder if this is a situation where you want to create a sort of no-op commit that could go out without the feature flag, and that would basically prevent all the existing queries from using this new enum. And maybe it introduces the new enum but behind something that blocks them from being used in the existing queries.

+ +

Depending on how your queries are structured, maybe it's just in your main query; you have a where not extra line that excludes the values in that enum. If it's not nicely scoped, maybe you need some sort of default scope on the model to say, exclude anything that has this enum value. And now you can introduce that enum, and you can have all those records. And even if it's not behind a feature flag, everything will continue to work exactly as it does today, and that's your goal.

+ +

And that is a fairly small scoped change. It's almost like a refactor in the classic sense of it, the make the change easy before you make the easy change. Although, in your case, it's maybe not that easy of a change. But then, after that, you can build on top of this with your work that might be behind a feature flag.

+ +

STEPHANIE: Yeah, I like that approach a lot because that ensures that the existing behavior will continue to work as expected. And then that also is a good way to audit, I guess, all the places that we will need to consider when we are making the change. So we already have in mind all the places that things are touching, and it's not a surprise when we find out, oh, we missed this query, or whatever.

+ +

I was also thinking about...I mentioned that we are querying one-off quite a bit with different filters. I was also thinking that maybe a query object could be a good use case here and wrapping existing business logic in a meaningful query. And then perhaps the new enum that we're introducing would have its own conceptual meaning.

+ +

JOËL: When you talk about one-off queries, are these like custom queries built out directly in the view or in the controller? Or where are you seeing these one-off queries?

+ +

STEPHANIE: Unfortunately, it's both the controller and in-service classes. [chuckles]

+ +

JOËL: Okay. I was afraid you were going to say the view, which brings me back to my old PHP days because I definitely wrote queries in...I guess my entire app was basically the view at that time. I had just one PHP file, and HTML, SQL all went in there. The page submitted to itself. So there's a giant conditional that split the files like if POST versus if GET.

+ +

STEPHANIE: Oof, that sounds pretty gnarly. And I feel like; in that case, you don't have the tools for the flexibility that you would have liked.

+ +

JOËL: It turns out the frameworks are nice. It's a good thing to have.

+ +

STEPHANIE: Good take.

+ +

JOËL: I think going back to something we were talking earlier, we were talking about how to maybe incrementally ship parts of this, and the sort of no-op approach that I was talking about, I'm a huge fan of. I think it's similar to what's sometimes called the strangler fig pattern that allows you to sort of incrementally sometimes change over from one system to another. But I think a lot of the ideas from that pattern can apply to adding new behavior where you might want to start by introducing some sort of no-op system and then maybe conditionally branching within that and keeping things separate to then evolving to your final piece.

+ +

And there was an article that I am a huge fan of by Adrianna Chang on the Shopify Engineering blog about this pattern. We'll link it in the show notes. But for those who are interested in digging into this pattern more, kind of wondering how it applies, I recommend reading this article.

+ +

STEPHANIE: I'm really glad you mentioned that because the other thing I was thinking about that feels like such a trap with feature flags is that it kind of conflates two different things, at least in the way that I've seen it used on different teams where we are using it to hide work that we are incrementally shipping.

+ +

And then it's also used as a deployment strategy. So maybe you might turn it on for X percent of customers, or you might just turn it on to 100% for everyone. But if something goes wrong, you can quickly turn it off. And for some reason, I'm thinking that those two things...maybe I'm not sure that one tool is the best thing for both of those concerns.

+ +

JOËL: Yes. Sometimes feature flags are used to actually gate a feature. I tend to bucket the turning it on and turning it off as the same thing as turning it on for 50% of people. But sometimes, it's really used more for a kind of CI/CD process where you want everything that gets merged from a PR to immediately go out to the production server. But you might not be ready to have that particular feature get turned on just yet. But a lot of those things might get turned on pretty quickly, and then the feature flag might get removed fairly quickly as well.

+ +

So they're not really features in the sense of product people are going to want to be like, okay, now we're ready to turn on this new feature for the big release day. They're very logistical. And they're really almost like another way to do version control but at the release level rather than via Git. Does that sound like a reasonable distinction to you, or is that different than what you're talking about?

+ +

STEPHANIE: That's really interesting. I think you may have found a third [laughs] way that people use them because I have definitely seen that as well. I think for me, what you said about if you turn it on to 50% of people, that is essentially turning it on to 100% in the sense that if you are trying to mitigate risk and things go wrong, things are still wrong, and you have to figure out what to do then.

+ +

And I'm glad you mentioned the strangler fig pattern because I think people on teams that I've been on at least have been using feature flags as a crutch for managing risk when they deploy and thinking that, oh, if something goes wrong, then at least we have this mechanism to stop the bleeding. Whereas if you were making sure that the code you are writing is in production but doesn't change the existing behavior because of the way you wrote it, that is a lot more resilient, I think, than just opening the gates and hoping for the best and having a safety net of turning it off.

+ +

JOËL: I see what you're saying now. And I think you've hit on a really important thing. So when you're trying to build software incrementally, there's a bit of an anti-pattern where you go off on a long-running branch, and you build, and you build, and you build. And hopefully, you're keeping it in sync with the main branch, but maybe you're not. And at some point, there's a big merge, and it's scary and potentially dangerous. And then there's a release, and hopefully, everything goes well. And we generally agree that that style of development generally does not lead to the best outcomes. So we try to work incrementally. We try to merge back into the main branch as much as possible.

+ +

But I think that many developers are kind of wired to think in that long-running branch approach. And so they kind of try to recreate it with feature flags. So it's like, oh yeah, technically, we're merging, like, we're on small branches, and we're merging back into main, but it's all gated behind this one feature flag, and then it's going to be a big bang release. And it may or may not break, and it's going to be scary. And it's going to be a lot of risk that we're trying to mitigate. But the more we're piling on behind this feature flag, the higher the risk becomes. So it ends up being kind of a long-running branch.

+ +

STEPHANIE: Yeah, that's a really great connection. I think that is where some of the fear is coming from too. And we are thinking that, oh, we're relatively safe because we have this mechanism that at least we can react with very quickly rather than having to revert a change or something like that. But the way that we're using it on this project...and in general, I've seen other people do it this way. And that could be why this technique has proliferated a little bit. It is a bit concerning; I think, because it still is just okay; we're just going to release it and then hope for the best.

+ +

JOËL: I think there are valid use cases for that kind of strategy, but I would like to see those come from a product perspective rather than a development perspective. So maybe as a business strategy, we decide that this series of features, we want them all to kind of show up at the same time. They're part of a larger package of changes that we want to release all at once. Now you're getting into product strategy. Oftentimes, it's better to release small things incrementally. But there are some times where you want to release a big thing that has multiple kind of sub-features all at once, and I think that's totally valid.

+ +

Where I'm less comfortable with it is when it's coming from the developer side because it's more about, oh, we just want to protect all of these things and kind of release a massive change all at once. And that, I think, ideally is better managed by truly working incrementally with something like a strangler fig pattern. I think that manages to mitigate the risks while also avoiding some of the messiness that comes with the feature flag here.

+ +

STEPHANIE: Yeah, I think the other way of working that I've noticed with feature flags gating larger features is having a QA team member manually going through all of the features behind the feature flag to make sure things are working as expected. But that is still different from real users using it. I think that is another form of reassurance that folks think we're getting with this strategy. But I think it's still limited in covering a production use case which is ultimately giving you the truest [laughs] reassurance that your application is working as expected for the people that are using it.

+ +

JOËL: I think I'm fine with having a QA person turn a feature flag on on a staging server, try something out as part of the workflow as long as these features are generally kept small. And then we ship it, and we turn the feature flag on, and then maybe we remove it as part of the process later on. Where I get less comfortable is where you've got a team of people working for weeks behind a feature flag. And, again, I do understand that for product reasons, there are times where that's a valid thing, where there's a big set of changes that you don't want your customers to see.

+ +

But if it's for developer reasons because we're concerned about coupling or we're concerned that something could break, then I get really uncomfortable with saying, okay, we're going to have a team of people working for several weeks behind a feature flag, and then we're going to need multiple QA people to test a ton of work that's all behind a feature flag. Now you're just kind of creating new risk while also trying to mitigate it and it kind of turns into a sort of weird zero-sum game.

+ +

STEPHANIE: Yeah, I know what you mean. I think in those cases, too, you're only testing what you know. So you're only testing the edge cases and the different flows that you know about. And inevitably, customers are probably using the app [chuckles] in ways that are completely unexpected, and no amount of testing all the different cases that you think are comprehensive will account for the way that it's used by customers.

+ +

JOËL: To be fair, I think a good QA person will catch a lot of weird edge cases. They know a lot of the ways that customers will try weird things. They often are really good at not being boxed into product or development's ideas of how the product should be used rather than how it can be used. That being said, real customers are a surprising and creative bunch, and they will absolutely do the unexpected.

+ +

STEPHANIE: Yeah, that's a great point. I'm glad you mentioned that.

+ +

JOËL: We've talked about a few different ways where maybe you're uncertain or uncomfortable about feature flags. Are there ways of using feature flags that you are 100% in favor of or that you're excited about, like, yes, feature flags are a great use in this scenario?

+ +

STEPHANIE: First of all, I think one of the most delightful times that I've had with a feature flag is when we use the Flipper gem. At a previous company, I remember really enjoying that one over...I've seen more hand-rolled implementations of feature flags, but I do want to give that gem a little shout-out. I think they are most effective when you do have a new page or something that has a very clear boundary, and you want to make sure that no one can go to the URL and see the new features that way, at least that's like the most clear cut use case for them.

+ +

And then, ideally, you have implemented everything. You have tested behind the feature flag. And then, the day of the release, we can just turn that thing on, and all is well. I hate to be that person to say simpler is better, but sometimes I think that is true. What about you? Do you have any instances where you felt a feature flag was really effective?

+ +

JOËL: I appreciate feature flags in more traditional CD, continuous deployment-style systems, particularly once the team grows a little bit and you've got a lot of PRs going out. And you want to be able to maybe undo things without necessarily having to revert and redeploy code, or if you've got things where you don't want to have Git be the thing that's gating when customers get to see features.

+ +

So maybe a person implements it on a particular day, but you don't want customers to see it until next week because that's when your marketing has said, if we're going to turn it on, do you really want that to sit in a PR for a week and then hit the merge button and that's going to be what ships it out to people? Like, that gets kind of clunky. I think you can get away with it when you're a small, fast-moving team. It doesn't work once you start scaling a little bit. And so I find that at that point, starting to introduce feature flags has been really helpful on teams I've worked on.

+ +

And I've been part of that transition where we're feeling a lot of pain, and then we introduce feature flags and can move to more of a continuous deployment where you get your code reviewed; you merge it; it's good. And then it goes out, and at some point, we turn the feature on, and then maybe at some point, we come back and clean up the feature flag and say this is now permanently in. I've seen good success with that style of approach.

+ +

STEPHANIE: Yeah, you bring up a good point about incorporating it into the CI/CD process. And that also makes me think, ideally, we would have some information as developers about how long we want this thing to be in that feature flag state because if you know, then you can claim ownership over it and make sure that it gets cleaned up. I think right now, what I've seen is we are using it in the development process, but then we're not necessarily communicating with product about how long it's supposed to stay this way and what are we supposed to do with it afterwards. A lot of that gets lost.

+ +

JOËL: It is interesting that I think some feature flags are mainly product-focused, and then others are entirely developer-focused. In fact, maybe the product team doesn't even need to know that this is internally gated by a feature flag because it's more about internally how you manage the release process and continuous deployment.

+ +

The fact that maybe physically pushing the code onto the server and having a feature be available to users is not exactly the same action might be a distinction that doesn't really matter to your product team. And if that's not a thing that they care about toggling for users, then that can be something that just stays internal to the dev team. And you say, okay, we're using that to manage risk or to allow us to merge code earlier, whatever the thing is, but then we clean them up ourselves, and nobody needs to know.

+ +

Whereas some things are very much product-focused, and we say, okay, the product team wants this to be a thing they can turn on and off, or they want to run an experiment, and then they very much need to be in the know. And I think you were alluding to some feature flags that might be kind of halfway in between that. They're not clear-cut product ones, but they're not entirely just mechanical deployment flags. They kind of sit in that weird zone between the two.

+ +

STEPHANIE: Yeah, absolutely. I think maybe there is a case to be made about this distinction, and people can then better use this tool and apply it to the actual problem that they're having.

+ +

JOËL: I think it's helped me get a better feel for them by having a bit of that distinction in my mind, thinking of flags as these are either sort of mechanical developer flags, or these are products flags. And maybe there's a richer nomenclature that can be developed. But I think at least having that distinction has helped me think about these in a more structured fashion.

+ +

STEPHANIE: Yeah, and even communicating that in the name of the flag, too, I think could be really valuable for other developers who come across it in the codebase. As for cleaning them up, I was just thinking about how it can be such a pain to then unwind the logic of the feature flag [chuckles] when you're removing them to figure out, okay, now that this thing is done, how do we actually want it to work? I think sometimes that ends up being a bit of a pain point and is what leaves them hanging around.

+ +

JOËL: And then it's not obvious which of the two branches in a conditional should be kept.

+ +

STEPHANIE: Right. And maybe that also depends on that distinction where you're talking about between a product release flag and a more internal development tool.

+ +

JOËL: Yeah, I could definitely see a more product-focused one where it's possible that you might want to keep both and say, no, this is a thing that we want to be able to toggle on. In general, for the foreseeable future, don't remove this flag. I want to control it from a dashboard. Maybe we want this to become maybe not gated by a feature flag in the traditional sense, but we want to tie it to a subscription level on a user's profile. So keep all the conditionals in place, but now just branch off the user's subscription status rather than a global flag.

+ +

STEPHANIE: Yeah, it turns out that feature flags can be really complicated. It's not just kind of a binary is it on or off [laughs] situation. It almost makes me wonder if some metadata would be helpful with flags to signal more information about them in the codebase. Like, are they a part of your application domain or not? It kind of gets a little fuzzy.

+ +

JOËL: Definitely. Something could be experimental; something could be like we said, mechanical; something could be deeply integrated into the vision of the product where you know that you're going to want to branch in the future here for different types of customers. I've even been on projects that were multi-tenant, where we had just standard feature flagging setup, but different tenants would have different sets of flags turned on. So they were global configuration for their instance of the app, but each instance had their own unique config of flags turned on and off.

+ +

STEPHANIE: That's really interesting because, in some ways, flags are a bit of a configuration. But then, when you are combining a lot of different flags to configure something, then maybe that is better done with a different approach.

+ +

JOËL: I like doing that kind of thing with flags rather than configuration because then it can be done via an admin dashboard rather than having to make changes to a YAML or JSON and having to commit it. And in this particular projects case, it was really nice because it meant that we could sort of, again, find those flex points and say, okay, we know that some clients want things to behave in two or three different ways in this one particular place. We'll gate that behind a flag, and then you can enable the variant that you want for each client. And now the customer service reps can manage that, and not the dev team.

+ +

STEPHANIE: Got it. Yeah, that is pretty cool.

+ +

JOËL: So, in a way, feature flags can be a great way to empower other departments within the business instead of kind of centralizing control within the dev team.

+ +

STEPHANIE: Yeah. I suppose you just provided another use case for them. [laughs]

+ +

JOËL: I feel like there are probably some really interesting elements to dig into around the interaction between product design and the actual development of things and teams that are doing either business development or customer support. Or maybe just some kind of rep for a big client is sort of where a lot of the power to actually execute things is. That is not this episode today, but I think that could be a great follow-up episode to do sometime.

+ +

STEPHANIE: Yeah, that's very interesting. I would love to talk about that in the future.

+ +

JOËL: The short version is I'm a fan of empowering other people.

+ +

STEPHANIE: There you have it, folks. [laughs] You heard it here first. Joël is a fan of empowering other people. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+13bCsgiH + + ]]> + + Joël Quenneville + Stephanie Minn + + + 378: Leadership and Impact as an Individual Contributor + https://bikeshed.thoughtbot.com/378 + 27bf1c6d-7c0b-4dd5-966b-8e687e8235d2 + Tue, 04 Apr 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Today's episode is "Old News"! Stephanie shares her ergonomic desk setup. Joël talks about the pyramids. + +Another old thing is the Bike Shed episode two weeks ago about success and fulfillment. Stephanie and Joël realized off-mic that one area they didn't really talk about so much is impact, and that is something that is very fulfilling for both of them. Today, they talk about impact and leadership as individual contributors because leadership is typically associated with management. But they believe that as ICs, at any level, you can be displaying attributes of leadership and show up in that way on teams. + 38:16 + no + + + Today's episode is "Old News"! Stephanie shares her ergonomic desk setup. Joël talks about the pyramids. +Another old thing is the Bike Shed episode two weeks ago about success and fulfillment. Stephanie and Joël realized off-mic that one area they didn't really talk about so much is impact, and that is something that is very fulfilling for both of them. Today, they talk about impact and leadership as individual contributors because leadership is typically associated with management. But they believe that as ICs, at any level, you can be displaying attributes of leadership and show up in that way on teams. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Success and Fulfillment episode (https://www.bikeshed.fm/376) +Logitech MX Vertical (https://www.bestbuy.com/site/logitech-mx-vertical-advanced-wireless-optical-mouse-with-ergonomic-design-graphite/6282602.p?skuId=6282602&ref=212&loc=1&extStoreId=319&ref=212&loc=1&&&gclid=EAIaIQobChMItMP27PT8_QIVfMiUCR0_dwVqEAQYASABEgIWJ_D_BwE&gclsrc=aw.ds) +Rose Wiegley's Lead From Where You Are (https://www.youtube.com/watch?v=1GorXHiB7nw) +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 old in your world? +STEPHANIE: I'm glad you asked that question because I don't think we get a chance to talk about things that are exactly the same as they've always been. And so today, I'd like to share my ergonomic desk setup, [laughs] which has been old for about a year or so. And back then, I was having some issues with some back pain and some wrist pain, and I made a few upgrades and since then have not had any issues. +And I feel like it's one of those things that I just forgot about because when it stops being a problem, you don't really notice it. And today, I am able to reflect on my old problem of bodily pain while working. And I'm happy to say that things have been much better for a while now. +JOËL: Oh, that's amazing. What's one thing you think had the most impact in your setup? +STEPHANIE: Oh, I picked up one of those vertical mice for my wrist. I was having some wrist pain, like I mentioned. And I actually solicited some input from other thoughtboters for the best mouse to replace the Apple Magic Mouse that I was using, which I really wanted it to work for me because I liked the way it looked, but nevertheless, that was causing me issues. So I ended up with the Logitech MX vertical, and that has really solved my wrist pain. It is very not cute. [laughs] It kind of looks like a weird big, gray snail. But you know what? You got to do what you got to do. +JOËL: That sounds like an art project waiting to happen. +STEPHANIE: Yeah. I would love to see; I don't know, a way to make these vertical mice look a little more cute. Maybe I will stick some googly eyes or something on it and then just be like, this is my pet snail [laughs] that works with me every day. +JOËL: Do you have a name? +STEPHANIE: Not yet. Maybe I'll save it for what's new next week. +[laughter] +JOËL: Homework assignment. Years ago, I was also having some wrist pain. And I think one of the most impactful things I did was remapping some keys on my keyboard. So I'm a pretty heavy Vim user. And I think just reaching with that pinky for the Escape key all the time was putting a lot of strain on my wrist. So I remapped Caps Lock to control. That's what I did. Yes, because it was reaching down with the pinky for the Control key and remapped escape to hitting J twice. +So now I can do those two very common things, Control for some kind of common chord and then Escape because you're always dropping in and out of modes, all from the Home row. And now, both my hands feel great, and I can be happy writing Vim. +STEPHANIE: That's really nice. I think when I had asked in Slack about mouse recommendations, someone had trolled me a little bit and said that if I just use my keyboard for everything, then I won't need to use [laughs] a mouse at all. [laughs] So there's also that option too for listeners out there. +JOËL: It's true. You go to tmux and Vim, and on a Mac, maybe something like Alfred and a few OS shortcuts, and you can get 90% of the way to keyboard only. +STEPHANIE: What about you, Joël? What's old in your world? +JOËL: So you know what, something that's really old? Pyramids. +STEPHANIE: Wow. [laughter] I should have known that this is where we were headed. +JOËL: Long-term listeners of the show will know I'm a huge history nerd. And we think of the pyramids as being old, but they are ridiculously old. A fun fact that I have not learned recently because this is something that is old in my world, but that I learned a while back is that if we look back to Cleopatra, the last Pharaoh, she is closer to us in time than she was to the building of the Great Pyramid. +STEPHANIE: No. What? Wow. Okay, yeah, that definitely just messed with my brain a little bit. And now, I have to rethink my understanding of time. +JOËL: I think the way the timeline sort of works in my mind is it tends to get compressed the further back you go. So it's like, yeah, I think of modern-ish times, like, yeah, there's like a lot of stuff, and I'm thinking in terms of decades until maybe like the 1900s. And now I start to think in terms of centuries. And they're kind of more or less equivalent, you know, the Victorian Age. It fills about the same amount of space in my mind as like the '60s. And then you get to the point where it's just like millennia. +STEPHANIE: Mm-hmm. When you think of Ancient Egypt, do you think Cleopatra and also pyramids, so you kind of conflate? At least I do. I conflate the two a little bit. But yeah, I guess a lot of time passed in between that. [laughs] +JOËL: The pyramids are also really cool because they were one of The Seven Wonders of the ancient world, which is sort of, I want to say, like a tourist circuit created by the ancient Greeks, sort of like monuments that they thought were particularly impressive. But they're also the only ones that are still standing; all of the others have been lost to time. +STEPHANIE: Wow, it's the real wonder then [laughs] for being able to stand the test of time. +JOËL: It's also the oldest of the seven and has managed to survive until today, so very impressive. +STEPHANIE: I love that. Just now, when you were talking about thinking about time periods kind of compressed, I definitely fall victim to thinking that the '70s or whatever was just 30 years ago, even though we are solidly in the 2020s and, in reality, it's obviously like 50. But yeah, I think that always freaks me out a little bit. +JOËL: Yes, it's no longer the year 2000. +STEPHANIE: Turns out. [laughs] So, in case our listeners didn't know. [laughs] +JOËL: I think when we were close-ish to the turn of the millennium, it just made mental math so easy because you're at that nice zero point. And then you get to the early 2010s, and it's close enough within a rounding error. And now we just can't pretend about that anymore. +STEPHANIE: No, we really can't. +JOËL: We need a new anchor point to do that mental math. +STEPHANIE: I love that we're talking about what's old in our world because I love a chance to just repeat something that I've said before that I still think is really cool, but I feel like that doesn't get invited as frequently. It's just like, oh, how are you doing? What's new? So yeah, highly recommend asking people what's old in their world? +JOËL: Yeah. And beyond that, not just like, what are some new things you're trying? But kind of like what you were talking about earlier, what's something that's stayed stable in your life, something that you've been doing for a while that works for you? +STEPHANIE: Yeah, I love it. So another thing that's old is our episode from a couple of weeks ago about success and fulfillment. And you and I realized off-mic that one area we didn't really talk about so much is impact, and that being something that is very fulfilling for both of us. And that kind of got me thinking about impact and leadership. And I especially am interested in this topic as individual contributors because I think that leadership is typically associated with management. But I really believe that as ICs, at any level, really, you can be displaying attributes of leadership and showing up in that way on teams. +JOËL: Definitely. I think you can have an impact at every level of the career ladder, not just an impact on a project but an impact on other people. I remember the first internship I did. I was maybe two weeks in, and I had a brand new intern join. It's day two, and I'm already pairing with him and being like, "Hey, I barely know anything about Rails. But if you want help with understanding instance variables, that's the one thing I know, and I can help you." +STEPHANIE: Yeah, that's awesome. I mean, everyone knows something that another person doesn't. And just having that mindset of injecting leadership into things that you do at work, no matter how big or how small, I think is really important. +JOËL: I think there's maybe a lie that we tell ourselves, which is that we need to wait to be an expert before we can help other people. +STEPHANIE: Yeah, I've certainly fallen into that trap a little bit where I think it's held me back from sharing something because I assumed that the other person would know already or the thing I'm thinking is something I learned but not necessarily something that someone else would find interesting or new. +JOËL: Right. Or even somebody's looking for help, and you feel like maybe you're not qualified to help on that problem, even though you probably are. +STEPHANIE: One thing that I was really curious about is, can you remember a time when an IC on your team demonstrated leadership, and you were really impressed by it? Like, you thought, like, wow, that was really great leadership on their part, and I'm really glad that they did that. +JOËL: Yeah. So I think one way that I really appreciate seeing leadership demonstrated is in client communication. Typically, the teams we have at thoughtbot are structured on a particular project where there's like a team lead who is in charge of the project. It's usually a couple of consultants working together as peers. Depending on the situation, one or the other might take leadership where it's necessary. +But I've really appreciated situations where a colleague will just really knock it out of the park with some communication with the client or when they are maybe helping talk through a difficult situation. Or maybe even we realize that there's a risk coming down the pipeline for the project and raising it early and making sure that we de-risk that properly. Those are all things that I really appreciate seeing. +STEPHANIE: Yeah. I think the way folks engage in channels of communication can have a really big impact. A few things that come to mind for me that I think is really great leadership is when more experienced or senior folks ask questions in public spaces because that kind of cultivates a space where asking questions is okay, and even people who have whatever title or whatever years of experience they still have questions and can signal to other folks in the team that this is okay to do. +And the same thing goes for sharing mistakes as well. Also, just signaling that, like, yeah, we mess up, and that's totally normal and okay. And the consequences aren't so scary that people feel a lot of pressure not to make mistakes or share when they happen. +JOËL: Yeah. The concept you're describing is very similar to the idea of vulnerability. +STEPHANIE: Yeah, that sounds right. +JOËL: So kind of modeling that from more senior people helps create a safer environment for the more junior people. +STEPHANIE: I think another thing that I really love that others do for me, and something that I want to get better at doing for others, is speaking up when something is a little off because, again, with power dynamics, for people who are newer or less experienced, they might be noticing things, but they don't feel encouraged to speak up about it in a public space or even with their manager. But they might confide in another IC who is maybe a little more senior. +And one thing that I really liked that happened on my client project recently is a senior engineer said in Slack, "Hey, I noticed some sentiment from our daily sync meeting that we're cutting it close to our deadline." And he asked like, "Should we shift some priorities around? Or what is more important to make sure that we focus on in the next few weeks before the end of the quarter?" And I was just really glad he said that because I certainly had been feeling it. But I don't know if I necessarily kept a pulse that other people were also feeling it. +And so having someone keeping an eye on those things and being receptive to hearing that from folks and then being like, okay, I want to make sure that I bring it up to the manager because it's important. I thought that was really cool. +JOËL: Yeah. Now we're almost dialing into sort of emotional awareness of what other people on the team might be feeling and also the ability to think in terms of risks and being proactive about managing those. +STEPHANIE: I like your use of the word risks because that definitely feels like something that, in general, people are scared to bring up. But ultimately, it is the signal of someone who is experienced enough to know that it's important to make transparent and then adjust accordingly. +Even beyond noticing what folks are feeling, there are also more concrete things that can be noticed as well, like if team members are complaining about CI build time being really long and that being a repeating issue in getting their work done. Or any other development or tooling thing that is causing people issues, having someone notice how frequently that happens and then being like, hey, this is a problem. And here's what I think we should do about it. +JOËL: So not only the awareness but also the initiative to try to enact change. +STEPHANIE: Yeah, absolutely. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: So you and I are actually working on the same client but on different project teams. And you've been involved with making improvements to CI to reduce kind of the problem that I was just talking about where it takes a while for us to develop. And you are working on reducing the number of days between the master branch and when you are allowed to hit the merge button to make sure that feature branches had incorporated the latest changes for master. +And one thing that I really like that you did was you solicited folks' input for what that time range should be. So I think you were playing around with the idea of giving people three days to merge, or else they'd have to rebase. +JOËL: I thought it was being really comprehensive here with three days because, you know what? You solicited feedback, you got review, but maybe it's the end of the day, or maybe someone's in different time zones. So we definitely want to cover at least a 24-hour period. So three days gives you an extra day. It should be safe. Is there any common situation where you might want a PR to be open for more than three days, but you wouldn't have rebased the latest master changes? +STEPHANIE: Yeah. I can see how you thought about it from a few different angles too. Like, you're thinking about time zones and folks working in other regions. And I ended up responding to you, and I was like, oh, what about the weekend? [laughs] +JOËL: Oops. +STEPHANIE: Because three days seems a little short if two of those days are eaten up by Saturday and Sunday. But what I liked was that you said, "Hey, I'm thinking about doing this. What do other people think?" Because you didn't claim to know what works best for everyone. And I think that's a really important skill to be honest, soliciting others for feedback, and knowing who to ask for and who to make sure you are not negatively affecting their work by making a change or making a decision. +JOËL: And in this case, it helped me realize that I had skipped over the most obvious edge case while thinking I'd covered all the really niche ones +STEPHANIE: We got there in the end, [laughs] and I think made the most informed decision. +JOËL: I guess that's just good product design in general. Talk to your users, get early feedback, put a prototype out where necessary. You don't always want your users to dictate what you will do, but it's good to get their feedback. And similarly, I think that applies when working with dev-facing things; you want feedback from developers. If I asked everybody at the company, I would have gotten a lot of different answers. And I might not have gotten one that satisfied everybody. But having some of that feedback helps me make a more informed decision. +STEPHANIE: Yeah, and to take it to the next step, I think there's also accountability for those decisions that you have to have. So if the decision that you made ends up being like a huge pain for some unforeseen reasons, I imagine you'd be on top of that as well and would want to figure out how to adjust if the experiment doesn't work as well as you would have liked. +JOËL: Right. I think we often talk about failing early. In fact, we have a recent episode about dealing with failure. And we mostly talked about it from a technical perspective, catching errors or making code more resilient to failure. But there is also a human component of it, which is if you catch errors or design problems, and I'm using design here as a product design, not in visual design, at a prototype phase or maybe a user interview phase, you've saved yourself a lot of maybe unnecessary work that you would have had if you went out to the product phase and shipped it to your entire customer base. +I guess, in a sense, it's worth thinking about other developers, the engineering team as customers sometimes. And a lot of the internal facing parts of your project are effectively a product geared towards them. They are the users. And so, throwing in a little bit of product development and design skills into building internally-facing software can have a huge impact. +So beyond just thinking of developers as a sort of internal customer base, occasionally, we work on projects where you are building internal tooling for other teams; maybe it's business development, maybe it's the marketing team, maybe it's some form of customer support. And that can often have a really large level of impact. Have you ever been on a project like that? +STEPHANIE: I have. One of my first jobs was for an e-commerce company. And I built tools for the customer support team for dealing with customers and getting their orders correct and fixed and whatnot. So I did work on an admin dashboard to make their jobs easier as well as the company also had its own internal software for dealing with warehouse logistics. And so, I also built a little bit of tooling for our logistics and fulfillment team. +And I really liked that work a lot because I could just go over and talk to the folks internally and be like, "Hey, what did you mean by this?" Or like, "What do you want here, and what would make your life easier?" And I felt a much more tangible impact than I did sometimes working on customer-facing features because I would deliver, and that goes out in the world. And I don't get to see how it's being used, and the feedback loop is much longer. So I really liked working on the internal tooling. +JOËL: In my experience, those teams are often really underserved when it comes to software. And so it's possible to make a huge impact on their quality of life with relatively little work. Sometimes you can just take an afternoon and eliminate a thing that's causing them to pull out their hair. +STEPHANIE: Yeah, absolutely. And you get the satisfaction of knowing that you built something exactly as they wanted it. Whereas sometimes, with user or customer-facing features, we are guessing or experimenting a little bit. And yeah, I think having someone who then is very grateful for, I don't know, the button that you added that makes them have to click less buttons [laughs] when they do their work in an internal dashboard can feel really good. +JOËL: Having that direct access can be really nice where you get to just go over and talk to them or shadow them for a day, see how their work happens, get to hear their frustrations real-time. It's often a smaller group as well than you would have for our customers, which might be thousands of people, and so you sample a few for user testing. But for an internal team, you can get them all in a Zoom call. I don't necessarily recommend doing a giant Zoom call for this kind of thing, but it's a small enough group that you could. +STEPHANIE: I'd like to flip that around to you. Have you ever been on the receiving end of an improvement or someone else making your life a little easier, and if you could share what that was and how it made you feel? +JOËL: I think pretty early on in my career, one of my first projects for thoughtbot, we were building a small kind of greenfield app for a startup. And another member on the team took a couple of hours one afternoon to just write a few small abstractions for the test suite that; just made it so much nicer to write tests. And we're pretty scrappy. We've got a tight deadline, and we're trying to iterate very quickly. But that quality of life difference was significant to the point I still remember this ten years later. I think we were rotating this developer off, and this was kind of a farewell present, so... +STEPHANIE: That's really sweet. +JOËL: You know what? I love that idea of saying when you rotate off a project, do a little something extra for the people you're leaving behind. +STEPHANIE: Yeah, I love that too. It's your kind of like last chance to make a small impact in that world. +JOËL: Especially because on your last couple days, you're probably not expected to pick up a ticket and get it halfway done. So as you're kind of ramping down, you might have a little bit of time to do some sort of refactoring task or something that needs to get done but hasn't been prioritized that will have a positive impact on the team. +STEPHANIE: Yeah, or even writing a script to automate something that you have kind of developed the muscle memory for, like, oh, I run these three commands in succession. And if you could just wrap it up in a little script and hand it off to someone else, it is a very sweet parting gift as well. +JOËL: Absolutely. So I'm curious, we opened the topic talking about impact, and you immediately connected that to leadership, and I want to explore that idea a little bit. Do you think impact has to be connected to leadership? Or are there ways to have impact, maybe outside of a leadership role? +STEPHANIE: I think they kind of go hand in hand, don't you? Because if you are wanting to make an impact, then in some ways, you are demonstrating that you care about other people. And at least for me, that is kind of my definition of leadership is enabling other folks to do better work. And you and I talk about attending and speaking at conferences pretty frequently on the podcast. And that is a very clear way that you are making an impact on the community. +But I also think that it is also a demonstration of leadership that you care enough about something that you want to share it with others and leave them with something that you've learned or something that you would like to see be done differently. +JOËL: And just to be clear here, the way you're talking about leadership is not a title; it's an action that you do. You're demonstrating leadership, even if you don't have any form of leadership title. +STEPHANIE: Yeah, absolutely. I think that because software development is a collaborative job, in some ways, in most things we do, there is some form of leadership component, even if you're not managing people or you don't have a particular title. +JOËL: Like you said, it's about the things that you're doing to enable other people or to act as a sort of force multiplier on your team rather than how many people report to you in the org chart. +STEPHANIE: Yeah, absolutely. +JOËL: So if everybody aspires to enable each other and to be impactful, is it possible to have a team where every person on the team is a leader? +STEPHANIE: Whoa, [laughs] asking the big questions, Joël. I mean, logically, the answer seems to be no based on our traditional understandings of leadership and being a leader or follower. But I also kind of disagree because, as developers, we have to make choices all of the time, and that can be at the level of the code that we write, the commit messages we write, what we communicate in our daily sync. +And those are all opportunities, I think, to inject those skills that we're talking about. And so, yeah, everyone on the team is making decisions about their work. And inherently, to me, at least, the way you make those decisions and the impact of those decisions imply some form of leadership. What about you? What do you think about this? +JOËL: It's tough because you can get into bikeshedding the definition. +STEPHANIE: [laughs] +JOËL: Which, hey, it's all about that, right? You know, is leadership about authority or decision-making capacity? Is it about impact? Is it about maybe even responsibility if things go wrong? Who's responsible for the consequences? It could be about position in the org tree and relative depth on that tree, to use some data structure terminology. But I liked your emphasis on the idea of impact and enabling others. So now it's a thing that you do. +And so any member at any moment can be demonstrating leadership or acting in some leadership capacity, and they're contributing to the team in that way. And in the next moment, somebody else stands up and does the same thing. And it doesn't necessarily have to be in conflict. You can actually be in a beautiful harmony. +STEPHANIE: Yeah, I really like the way you said that. I love a good beautiful harmony. [laughs] I think part of what has shaped my view on this is a keynote talk from RubyConf Mini back in November by Rose Wiegley. And her talk was called "Lead From Where You Are." And I think perhaps I've kind of internalized that a little bit to be like, oh yeah, everything we do, we can make a decision that can have a positive impact on others. +So that has helped me at least feel like I have a lot more agency in what I do as a developer, even if I don't have the concrete responsibility of being a mentor to a particular person or having a direct report. It injects meaning into my work, and that goes back to the fulfillment piece that we were talking in, knowing that, like, okay, like, here's how I can make an impact. And that's all just wrapped up together. +JOËL: So you kind of defined earlier the idea of leadership as work that has impact on others or that enables the work of others. And I think that there are some forms of that work which are kind of highly respected and will get you noticed and will be kind of called out as like, oh, you're performing leadership here. You stood up in that meeting, and you said the hard thing that needed to be said. +And there are other forms of supporting or enabling the team that almost get viewed as the opposite of leadership that don't get recognized and are almost like you're seen as less of a leader if you're spending a lot of your time doing that. That can be sometimes more administrative work. How does that sort of fit into this model where we're talking about leadership as something that has an impact on others? +STEPHANIE: Yeah, I'm glad you mentioned that because I have a lot of gripes [laughs] and thoughts, I suppose, about what work is visible and not visible and valued more or less. And I do think some more traditional signals of leadership, like talking the most in a meeting, like, that I don't necessarily think is my definition of leadership; in fact, the opposite. A true leader, in my opinion, is someone who makes space for others and makes sure that all voices are heard. +And yeah, I guess it just speaks to like what I was saying about soliciting other people for feedback as well. It's like someone to me who demonstrates leadership is not someone who thinks that they have all the right answers but actively seeks out more information to invalidate what they think is right and find the right solution for the folks on their team. +Similarly, in Rose's talk, she also mentions the idea of being a problem finder, so not just being tasked with solving a problem but looking around and being like, okay, like, what aren't we talking about and that we should be? And obviously, also contributing to making that better and not just being like, "Here's a bunch of problems, [laughs] and you have to deal with it," but that proactive work. Ideally, we are addressing those things before they become a huge problem. And I really liked that aspect of what leadership looks like as well. +JOËL: Yeah, I think something that I've noticed that I do more as I've built more experience over time is that when I started off earlier in my career, it was a lot of here's a problem that needs to be solved, go and solve it. And then over time, it's what are the problems that need to be solved? You have to sort of figure out those problems before you go and solve them. And then sometimes it's even one level above that; what questions should we be asking so that we can find the problem so that we can solve them? +And that will happen...it could be internally, so some of the things that I'm doing currently around improving the experience of a test suite is like, okay, we know sort of that it's slow in certain ways. How can we make that faster? We know that the experience is not great. But what are the actual problems that are happening here, the root causes? Or we're getting some complaints, but we don't really know what the underlying problem is. Let's go and search that out. +STEPHANIE: Yeah, that brings to mind an issue that I think I see a lot on client projects where perhaps stakeholders or an engineering manager is seeing that we are slow to merge our PRs, and they kind of start reaching for solutions like, okay, well, people should spend more time doing code reviews or whatever, thinking that that's what the issue is. +But in reality, maybe it's, I don't know, it can even be something as lower level as having to re-request reviews every single time you push a new commit because the GitHub settings are such that it requires additional approvals for every new change. And that is something that they would not know about unless someone spoke up and said, "Actually, this is what's causing us friction," and having to go back and do these manual tasks that maybe we should explore a different alternative to solve. +JOËL: Yeah, instead of just jumping in with a solution of we need to throw more dev hours at this problem, it can be useful to step back and ask, okay, well, why do we have this problem in the first place? Is it a process issue that we have? Is there some sort of social element that we need to address and organizational problems? And if it's not that, then what are the questions that we're missing? What questions should we be asking here to understand this problem? +STEPHANIE: Right. And even speaking up about it too and going against someone's assumption and saying, "Here's what I've been seeing, and this is what I think about it," that takes a lot of courage. And I do think it is something that is especially important for folks who are more experienced and have more responsibility or a higher-level title, but ideally is something that anyone could do. I would love to know for you, Joël, what is the most important way that you want to make an impact as a developer? +JOËL: I think the human element is the most important. I want to have an impact on my colleagues, on the dev teams with my clients. I want to ship good work. But I think the most valuable thing to invest in is other people. +STEPHANIE: Yeah, I agree. I think for me; it's like making a good work experience for the people that I work with. And it's also a little bit selfish because then that means I am having a good work experience, and I'm in a good culture and environment. But that is definitely an area that I spend a lot of time thinking about and wanting to start conversations about. +JOËL: It's a win-win, right? You make it better for everybody else and better for you in the process. +STEPHANIE: Exactly. +JOËL: And it's okay for it to be somewhat selfishly motivated. Like, it doesn't have to always be every day super altruistic like; I just want to make the world a better place. +STEPHANIE: [laughs] +JOËL: Like, you know what? I want my corner of the world to be better, and in doing so, I'm going to make it better for everyone else. +STEPHANIE: What's that phrase? The tide rising all the ships. [laughs] That is extremely not correct, but I think you know what I'm trying to say. +JOËL: I think a rising tide lifts all boats. +STEPHANIE: Yeah, something like that. I love a good rising tide. [laughs] On that note, shall we wrap up? +JOËL: Let's wrap up. Or let's rise up. +STEPHANIE: [laughs] +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Today's episode is "Old News"! Stephanie shares her ergonomic desk setup. Joël talks about the pyramids.

+ +

Another old thing is the Bike Shed episode two weeks ago about success and fulfillment. Stephanie and Joël realized off-mic that one area they didn't really talk about so much is impact, and that is something that is very fulfilling for both of them. Today, they talk about impact and leadership as individual contributors because leadership is typically associated with management. But they believe that as ICs, at any level, you can be displaying attributes of leadership and show up in that way on teams.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 old in your world?

+ +

STEPHANIE: I'm glad you asked that question because I don't think we get a chance to talk about things that are exactly the same as they've always been. And so today, I'd like to share my ergonomic desk setup, [laughs] which has been old for about a year or so. And back then, I was having some issues with some back pain and some wrist pain, and I made a few upgrades and since then have not had any issues.

+ +

And I feel like it's one of those things that I just forgot about because when it stops being a problem, you don't really notice it. And today, I am able to reflect on my old problem of bodily pain while working. And I'm happy to say that things have been much better for a while now.

+ +

JOËL: Oh, that's amazing. What's one thing you think had the most impact in your setup?

+ +

STEPHANIE: Oh, I picked up one of those vertical mice for my wrist. I was having some wrist pain, like I mentioned. And I actually solicited some input from other thoughtboters for the best mouse to replace the Apple Magic Mouse that I was using, which I really wanted it to work for me because I liked the way it looked, but nevertheless, that was causing me issues. So I ended up with the Logitech MX vertical, and that has really solved my wrist pain. It is very not cute. [laughs] It kind of looks like a weird big, gray snail. But you know what? You got to do what you got to do.

+ +

JOËL: That sounds like an art project waiting to happen.

+ +

STEPHANIE: Yeah. I would love to see; I don't know, a way to make these vertical mice look a little more cute. Maybe I will stick some googly eyes or something on it and then just be like, this is my pet snail [laughs] that works with me every day.

+ +

JOËL: Do you have a name?

+ +

STEPHANIE: Not yet. Maybe I'll save it for what's new next week.

+ +

[laughter]

+ +

JOËL: Homework assignment. Years ago, I was also having some wrist pain. And I think one of the most impactful things I did was remapping some keys on my keyboard. So I'm a pretty heavy Vim user. And I think just reaching with that pinky for the Escape key all the time was putting a lot of strain on my wrist. So I remapped Caps Lock to control. That's what I did. Yes, because it was reaching down with the pinky for the Control key and remapped escape to hitting J twice.

+ +

So now I can do those two very common things, Control for some kind of common chord and then Escape because you're always dropping in and out of modes, all from the Home row. And now, both my hands feel great, and I can be happy writing Vim.

+ +

STEPHANIE: That's really nice. I think when I had asked in Slack about mouse recommendations, someone had trolled me a little bit and said that if I just use my keyboard for everything, then I won't need to use [laughs] a mouse at all. [laughs] So there's also that option too for listeners out there.

+ +

JOËL: It's true. You go to tmux and Vim, and on a Mac, maybe something like Alfred and a few OS shortcuts, and you can get 90% of the way to keyboard only.

+ +

STEPHANIE: What about you, Joël? What's old in your world?

+ +

JOËL: So you know what, something that's really old? Pyramids.

+ +

STEPHANIE: Wow. [laughter] I should have known that this is where we were headed.

+ +

JOËL: Long-term listeners of the show will know I'm a huge history nerd. And we think of the pyramids as being old, but they are ridiculously old. A fun fact that I have not learned recently because this is something that is old in my world, but that I learned a while back is that if we look back to Cleopatra, the last Pharaoh, she is closer to us in time than she was to the building of the Great Pyramid.

+ +

STEPHANIE: No. What? Wow. Okay, yeah, that definitely just messed with my brain a little bit. And now, I have to rethink my understanding of time.

+ +

JOËL: I think the way the timeline sort of works in my mind is it tends to get compressed the further back you go. So it's like, yeah, I think of modern-ish times, like, yeah, there's like a lot of stuff, and I'm thinking in terms of decades until maybe like the 1900s. And now I start to think in terms of centuries. And they're kind of more or less equivalent, you know, the Victorian Age. It fills about the same amount of space in my mind as like the '60s. And then you get to the point where it's just like millennia.

+ +

STEPHANIE: Mm-hmm. When you think of Ancient Egypt, do you think Cleopatra and also pyramids, so you kind of conflate? At least I do. I conflate the two a little bit. But yeah, I guess a lot of time passed in between that. [laughs]

+ +

JOËL: The pyramids are also really cool because they were one of The Seven Wonders of the ancient world, which is sort of, I want to say, like a tourist circuit created by the ancient Greeks, sort of like monuments that they thought were particularly impressive. But they're also the only ones that are still standing; all of the others have been lost to time.

+ +

STEPHANIE: Wow, it's the real wonder then [laughs] for being able to stand the test of time.

+ +

JOËL: It's also the oldest of the seven and has managed to survive until today, so very impressive.

+ +

STEPHANIE: I love that. Just now, when you were talking about thinking about time periods kind of compressed, I definitely fall victim to thinking that the '70s or whatever was just 30 years ago, even though we are solidly in the 2020s and, in reality, it's obviously like 50. But yeah, I think that always freaks me out a little bit.

+ +

JOËL: Yes, it's no longer the year 2000.

+ +

STEPHANIE: Turns out. [laughs] So, in case our listeners didn't know. [laughs]

+ +

JOËL: I think when we were close-ish to the turn of the millennium, it just made mental math so easy because you're at that nice zero point. And then you get to the early 2010s, and it's close enough within a rounding error. And now we just can't pretend about that anymore.

+ +

STEPHANIE: No, we really can't.

+ +

JOËL: We need a new anchor point to do that mental math.

+ +

STEPHANIE: I love that we're talking about what's old in our world because I love a chance to just repeat something that I've said before that I still think is really cool, but I feel like that doesn't get invited as frequently. It's just like, oh, how are you doing? What's new? So yeah, highly recommend asking people what's old in their world?

+ +

JOËL: Yeah. And beyond that, not just like, what are some new things you're trying? But kind of like what you were talking about earlier, what's something that's stayed stable in your life, something that you've been doing for a while that works for you?

+ +

STEPHANIE: Yeah, I love it. So another thing that's old is our episode from a couple of weeks ago about success and fulfillment. And you and I realized off-mic that one area we didn't really talk about so much is impact, and that being something that is very fulfilling for both of us. And that kind of got me thinking about impact and leadership. And I especially am interested in this topic as individual contributors because I think that leadership is typically associated with management. But I really believe that as ICs, at any level, really, you can be displaying attributes of leadership and showing up in that way on teams.

+ +

JOËL: Definitely. I think you can have an impact at every level of the career ladder, not just an impact on a project but an impact on other people. I remember the first internship I did. I was maybe two weeks in, and I had a brand new intern join. It's day two, and I'm already pairing with him and being like, "Hey, I barely know anything about Rails. But if you want help with understanding instance variables, that's the one thing I know, and I can help you."

+ +

STEPHANIE: Yeah, that's awesome. I mean, everyone knows something that another person doesn't. And just having that mindset of injecting leadership into things that you do at work, no matter how big or how small, I think is really important.

+ +

JOËL: I think there's maybe a lie that we tell ourselves, which is that we need to wait to be an expert before we can help other people.

+ +

STEPHANIE: Yeah, I've certainly fallen into that trap a little bit where I think it's held me back from sharing something because I assumed that the other person would know already or the thing I'm thinking is something I learned but not necessarily something that someone else would find interesting or new.

+ +

JOËL: Right. Or even somebody's looking for help, and you feel like maybe you're not qualified to help on that problem, even though you probably are.

+ +

STEPHANIE: One thing that I was really curious about is, can you remember a time when an IC on your team demonstrated leadership, and you were really impressed by it? Like, you thought, like, wow, that was really great leadership on their part, and I'm really glad that they did that.

+ +

JOËL: Yeah. So I think one way that I really appreciate seeing leadership demonstrated is in client communication. Typically, the teams we have at thoughtbot are structured on a particular project where there's like a team lead who is in charge of the project. It's usually a couple of consultants working together as peers. Depending on the situation, one or the other might take leadership where it's necessary.

+ +

But I've really appreciated situations where a colleague will just really knock it out of the park with some communication with the client or when they are maybe helping talk through a difficult situation. Or maybe even we realize that there's a risk coming down the pipeline for the project and raising it early and making sure that we de-risk that properly. Those are all things that I really appreciate seeing.

+ +

STEPHANIE: Yeah. I think the way folks engage in channels of communication can have a really big impact. A few things that come to mind for me that I think is really great leadership is when more experienced or senior folks ask questions in public spaces because that kind of cultivates a space where asking questions is okay, and even people who have whatever title or whatever years of experience they still have questions and can signal to other folks in the team that this is okay to do.

+ +

And the same thing goes for sharing mistakes as well. Also, just signaling that, like, yeah, we mess up, and that's totally normal and okay. And the consequences aren't so scary that people feel a lot of pressure not to make mistakes or share when they happen.

+ +

JOËL: Yeah. The concept you're describing is very similar to the idea of vulnerability.

+ +

STEPHANIE: Yeah, that sounds right.

+ +

JOËL: So kind of modeling that from more senior people helps create a safer environment for the more junior people.

+ +

STEPHANIE: I think another thing that I really love that others do for me, and something that I want to get better at doing for others, is speaking up when something is a little off because, again, with power dynamics, for people who are newer or less experienced, they might be noticing things, but they don't feel encouraged to speak up about it in a public space or even with their manager. But they might confide in another IC who is maybe a little more senior.

+ +

And one thing that I really liked that happened on my client project recently is a senior engineer said in Slack, "Hey, I noticed some sentiment from our daily sync meeting that we're cutting it close to our deadline." And he asked like, "Should we shift some priorities around? Or what is more important to make sure that we focus on in the next few weeks before the end of the quarter?" And I was just really glad he said that because I certainly had been feeling it. But I don't know if I necessarily kept a pulse that other people were also feeling it.

+ +

And so having someone keeping an eye on those things and being receptive to hearing that from folks and then being like, okay, I want to make sure that I bring it up to the manager because it's important. I thought that was really cool.

+ +

JOËL: Yeah. Now we're almost dialing into sort of emotional awareness of what other people on the team might be feeling and also the ability to think in terms of risks and being proactive about managing those.

+ +

STEPHANIE: I like your use of the word risks because that definitely feels like something that, in general, people are scared to bring up. But ultimately, it is the signal of someone who is experienced enough to know that it's important to make transparent and then adjust accordingly.

+ +

Even beyond noticing what folks are feeling, there are also more concrete things that can be noticed as well, like if team members are complaining about CI build time being really long and that being a repeating issue in getting their work done. Or any other development or tooling thing that is causing people issues, having someone notice how frequently that happens and then being like, hey, this is a problem. And here's what I think we should do about it.

+ +

JOËL: So not only the awareness but also the initiative to try to enact change.

+ +

STEPHANIE: Yeah, absolutely.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So you and I are actually working on the same client but on different project teams. And you've been involved with making improvements to CI to reduce kind of the problem that I was just talking about where it takes a while for us to develop. And you are working on reducing the number of days between the master branch and when you are allowed to hit the merge button to make sure that feature branches had incorporated the latest changes for master.

+ +

And one thing that I really like that you did was you solicited folks' input for what that time range should be. So I think you were playing around with the idea of giving people three days to merge, or else they'd have to rebase.

+ +

JOËL: I thought it was being really comprehensive here with three days because, you know what? You solicited feedback, you got review, but maybe it's the end of the day, or maybe someone's in different time zones. So we definitely want to cover at least a 24-hour period. So three days gives you an extra day. It should be safe. Is there any common situation where you might want a PR to be open for more than three days, but you wouldn't have rebased the latest master changes?

+ +

STEPHANIE: Yeah. I can see how you thought about it from a few different angles too. Like, you're thinking about time zones and folks working in other regions. And I ended up responding to you, and I was like, oh, what about the weekend? [laughs]

+ +

JOËL: Oops.

+ +

STEPHANIE: Because three days seems a little short if two of those days are eaten up by Saturday and Sunday. But what I liked was that you said, "Hey, I'm thinking about doing this. What do other people think?" Because you didn't claim to know what works best for everyone. And I think that's a really important skill to be honest, soliciting others for feedback, and knowing who to ask for and who to make sure you are not negatively affecting their work by making a change or making a decision.

+ +

JOËL: And in this case, it helped me realize that I had skipped over the most obvious edge case while thinking I'd covered all the really niche ones

+ +

STEPHANIE: We got there in the end, [laughs] and I think made the most informed decision.

+ +

JOËL: I guess that's just good product design in general. Talk to your users, get early feedback, put a prototype out where necessary. You don't always want your users to dictate what you will do, but it's good to get their feedback. And similarly, I think that applies when working with dev-facing things; you want feedback from developers. If I asked everybody at the company, I would have gotten a lot of different answers. And I might not have gotten one that satisfied everybody. But having some of that feedback helps me make a more informed decision.

+ +

STEPHANIE: Yeah, and to take it to the next step, I think there's also accountability for those decisions that you have to have. So if the decision that you made ends up being like a huge pain for some unforeseen reasons, I imagine you'd be on top of that as well and would want to figure out how to adjust if the experiment doesn't work as well as you would have liked.

+ +

JOËL: Right. I think we often talk about failing early. In fact, we have a recent episode about dealing with failure. And we mostly talked about it from a technical perspective, catching errors or making code more resilient to failure. But there is also a human component of it, which is if you catch errors or design problems, and I'm using design here as a product design, not in visual design, at a prototype phase or maybe a user interview phase, you've saved yourself a lot of maybe unnecessary work that you would have had if you went out to the product phase and shipped it to your entire customer base.

+ +

I guess, in a sense, it's worth thinking about other developers, the engineering team as customers sometimes. And a lot of the internal facing parts of your project are effectively a product geared towards them. They are the users. And so, throwing in a little bit of product development and design skills into building internally-facing software can have a huge impact.

+ +

So beyond just thinking of developers as a sort of internal customer base, occasionally, we work on projects where you are building internal tooling for other teams; maybe it's business development, maybe it's the marketing team, maybe it's some form of customer support. And that can often have a really large level of impact. Have you ever been on a project like that?

+ +

STEPHANIE: I have. One of my first jobs was for an e-commerce company. And I built tools for the customer support team for dealing with customers and getting their orders correct and fixed and whatnot. So I did work on an admin dashboard to make their jobs easier as well as the company also had its own internal software for dealing with warehouse logistics. And so, I also built a little bit of tooling for our logistics and fulfillment team.

+ +

And I really liked that work a lot because I could just go over and talk to the folks internally and be like, "Hey, what did you mean by this?" Or like, "What do you want here, and what would make your life easier?" And I felt a much more tangible impact than I did sometimes working on customer-facing features because I would deliver, and that goes out in the world. And I don't get to see how it's being used, and the feedback loop is much longer. So I really liked working on the internal tooling.

+ +

JOËL: In my experience, those teams are often really underserved when it comes to software. And so it's possible to make a huge impact on their quality of life with relatively little work. Sometimes you can just take an afternoon and eliminate a thing that's causing them to pull out their hair.

+ +

STEPHANIE: Yeah, absolutely. And you get the satisfaction of knowing that you built something exactly as they wanted it. Whereas sometimes, with user or customer-facing features, we are guessing or experimenting a little bit. And yeah, I think having someone who then is very grateful for, I don't know, the button that you added that makes them have to click less buttons [laughs] when they do their work in an internal dashboard can feel really good.

+ +

JOËL: Having that direct access can be really nice where you get to just go over and talk to them or shadow them for a day, see how their work happens, get to hear their frustrations real-time. It's often a smaller group as well than you would have for our customers, which might be thousands of people, and so you sample a few for user testing. But for an internal team, you can get them all in a Zoom call. I don't necessarily recommend doing a giant Zoom call for this kind of thing, but it's a small enough group that you could.

+ +

STEPHANIE: I'd like to flip that around to you. Have you ever been on the receiving end of an improvement or someone else making your life a little easier, and if you could share what that was and how it made you feel?

+ +

JOËL: I think pretty early on in my career, one of my first projects for thoughtbot, we were building a small kind of greenfield app for a startup. And another member on the team took a couple of hours one afternoon to just write a few small abstractions for the test suite that; just made it so much nicer to write tests. And we're pretty scrappy. We've got a tight deadline, and we're trying to iterate very quickly. But that quality of life difference was significant to the point I still remember this ten years later. I think we were rotating this developer off, and this was kind of a farewell present, so...

+ +

STEPHANIE: That's really sweet.

+ +

JOËL: You know what? I love that idea of saying when you rotate off a project, do a little something extra for the people you're leaving behind.

+ +

STEPHANIE: Yeah, I love that too. It's your kind of like last chance to make a small impact in that world.

+ +

JOËL: Especially because on your last couple days, you're probably not expected to pick up a ticket and get it halfway done. So as you're kind of ramping down, you might have a little bit of time to do some sort of refactoring task or something that needs to get done but hasn't been prioritized that will have a positive impact on the team.

+ +

STEPHANIE: Yeah, or even writing a script to automate something that you have kind of developed the muscle memory for, like, oh, I run these three commands in succession. And if you could just wrap it up in a little script and hand it off to someone else, it is a very sweet parting gift as well.

+ +

JOËL: Absolutely. So I'm curious, we opened the topic talking about impact, and you immediately connected that to leadership, and I want to explore that idea a little bit. Do you think impact has to be connected to leadership? Or are there ways to have impact, maybe outside of a leadership role?

+ +

STEPHANIE: I think they kind of go hand in hand, don't you? Because if you are wanting to make an impact, then in some ways, you are demonstrating that you care about other people. And at least for me, that is kind of my definition of leadership is enabling other folks to do better work. And you and I talk about attending and speaking at conferences pretty frequently on the podcast. And that is a very clear way that you are making an impact on the community.

+ +

But I also think that it is also a demonstration of leadership that you care enough about something that you want to share it with others and leave them with something that you've learned or something that you would like to see be done differently.

+ +

JOËL: And just to be clear here, the way you're talking about leadership is not a title; it's an action that you do. You're demonstrating leadership, even if you don't have any form of leadership title.

+ +

STEPHANIE: Yeah, absolutely. I think that because software development is a collaborative job, in some ways, in most things we do, there is some form of leadership component, even if you're not managing people or you don't have a particular title.

+ +

JOËL: Like you said, it's about the things that you're doing to enable other people or to act as a sort of force multiplier on your team rather than how many people report to you in the org chart.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: So if everybody aspires to enable each other and to be impactful, is it possible to have a team where every person on the team is a leader?

+ +

STEPHANIE: Whoa, [laughs] asking the big questions, Joël. I mean, logically, the answer seems to be no based on our traditional understandings of leadership and being a leader or follower. But I also kind of disagree because, as developers, we have to make choices all of the time, and that can be at the level of the code that we write, the commit messages we write, what we communicate in our daily sync.

+ +

And those are all opportunities, I think, to inject those skills that we're talking about. And so, yeah, everyone on the team is making decisions about their work. And inherently, to me, at least, the way you make those decisions and the impact of those decisions imply some form of leadership. What about you? What do you think about this?

+ +

JOËL: It's tough because you can get into bikeshedding the definition.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Which, hey, it's all about that, right? You know, is leadership about authority or decision-making capacity? Is it about impact? Is it about maybe even responsibility if things go wrong? Who's responsible for the consequences? It could be about position in the org tree and relative depth on that tree, to use some data structure terminology. But I liked your emphasis on the idea of impact and enabling others. So now it's a thing that you do.

+ +

And so any member at any moment can be demonstrating leadership or acting in some leadership capacity, and they're contributing to the team in that way. And in the next moment, somebody else stands up and does the same thing. And it doesn't necessarily have to be in conflict. You can actually be in a beautiful harmony.

+ +

STEPHANIE: Yeah, I really like the way you said that. I love a good beautiful harmony. [laughs] I think part of what has shaped my view on this is a keynote talk from RubyConf Mini back in November by Rose Wiegley. And her talk was called "Lead From Where You Are." And I think perhaps I've kind of internalized that a little bit to be like, oh yeah, everything we do, we can make a decision that can have a positive impact on others.

+ +

So that has helped me at least feel like I have a lot more agency in what I do as a developer, even if I don't have the concrete responsibility of being a mentor to a particular person or having a direct report. It injects meaning into my work, and that goes back to the fulfillment piece that we were talking in, knowing that, like, okay, like, here's how I can make an impact. And that's all just wrapped up together.

+ +

JOËL: So you kind of defined earlier the idea of leadership as work that has impact on others or that enables the work of others. And I think that there are some forms of that work which are kind of highly respected and will get you noticed and will be kind of called out as like, oh, you're performing leadership here. You stood up in that meeting, and you said the hard thing that needed to be said.

+ +

And there are other forms of supporting or enabling the team that almost get viewed as the opposite of leadership that don't get recognized and are almost like you're seen as less of a leader if you're spending a lot of your time doing that. That can be sometimes more administrative work. How does that sort of fit into this model where we're talking about leadership as something that has an impact on others?

+ +

STEPHANIE: Yeah, I'm glad you mentioned that because I have a lot of gripes [laughs] and thoughts, I suppose, about what work is visible and not visible and valued more or less. And I do think some more traditional signals of leadership, like talking the most in a meeting, like, that I don't necessarily think is my definition of leadership; in fact, the opposite. A true leader, in my opinion, is someone who makes space for others and makes sure that all voices are heard.

+ +

And yeah, I guess it just speaks to like what I was saying about soliciting other people for feedback as well. It's like someone to me who demonstrates leadership is not someone who thinks that they have all the right answers but actively seeks out more information to invalidate what they think is right and find the right solution for the folks on their team.

+ +

Similarly, in Rose's talk, she also mentions the idea of being a problem finder, so not just being tasked with solving a problem but looking around and being like, okay, like, what aren't we talking about and that we should be? And obviously, also contributing to making that better and not just being like, "Here's a bunch of problems, [laughs] and you have to deal with it," but that proactive work. Ideally, we are addressing those things before they become a huge problem. And I really liked that aspect of what leadership looks like as well.

+ +

JOËL: Yeah, I think something that I've noticed that I do more as I've built more experience over time is that when I started off earlier in my career, it was a lot of here's a problem that needs to be solved, go and solve it. And then over time, it's what are the problems that need to be solved? You have to sort of figure out those problems before you go and solve them. And then sometimes it's even one level above that; what questions should we be asking so that we can find the problem so that we can solve them?

+ +

And that will happen...it could be internally, so some of the things that I'm doing currently around improving the experience of a test suite is like, okay, we know sort of that it's slow in certain ways. How can we make that faster? We know that the experience is not great. But what are the actual problems that are happening here, the root causes? Or we're getting some complaints, but we don't really know what the underlying problem is. Let's go and search that out.

+ +

STEPHANIE: Yeah, that brings to mind an issue that I think I see a lot on client projects where perhaps stakeholders or an engineering manager is seeing that we are slow to merge our PRs, and they kind of start reaching for solutions like, okay, well, people should spend more time doing code reviews or whatever, thinking that that's what the issue is.

+ +

But in reality, maybe it's, I don't know, it can even be something as lower level as having to re-request reviews every single time you push a new commit because the GitHub settings are such that it requires additional approvals for every new change. And that is something that they would not know about unless someone spoke up and said, "Actually, this is what's causing us friction," and having to go back and do these manual tasks that maybe we should explore a different alternative to solve.

+ +

JOËL: Yeah, instead of just jumping in with a solution of we need to throw more dev hours at this problem, it can be useful to step back and ask, okay, well, why do we have this problem in the first place? Is it a process issue that we have? Is there some sort of social element that we need to address and organizational problems? And if it's not that, then what are the questions that we're missing? What questions should we be asking here to understand this problem?

+ +

STEPHANIE: Right. And even speaking up about it too and going against someone's assumption and saying, "Here's what I've been seeing, and this is what I think about it," that takes a lot of courage. And I do think it is something that is especially important for folks who are more experienced and have more responsibility or a higher-level title, but ideally is something that anyone could do. I would love to know for you, Joël, what is the most important way that you want to make an impact as a developer?

+ +

JOËL: I think the human element is the most important. I want to have an impact on my colleagues, on the dev teams with my clients. I want to ship good work. But I think the most valuable thing to invest in is other people.

+ +

STEPHANIE: Yeah, I agree. I think for me; it's like making a good work experience for the people that I work with. And it's also a little bit selfish because then that means I am having a good work experience, and I'm in a good culture and environment. But that is definitely an area that I spend a lot of time thinking about and wanting to start conversations about.

+ +

JOËL: It's a win-win, right? You make it better for everybody else and better for you in the process.

+ +

STEPHANIE: Exactly.

+ +

JOËL: And it's okay for it to be somewhat selfishly motivated. Like, it doesn't have to always be every day super altruistic like; I just want to make the world a better place.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Like, you know what? I want my corner of the world to be better, and in doing so, I'm going to make it better for everyone else.

+ +

STEPHANIE: What's that phrase? The tide rising all the ships. [laughs] That is extremely not correct, but I think you know what I'm trying to say.

+ +

JOËL: I think a rising tide lifts all boats.

+ +

STEPHANIE: Yeah, something like that. I love a good rising tide. [laughs] On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. Or let's rise up.

+ +

STEPHANIE: [laughs]

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Today's episode is "Old News"! Stephanie shares her ergonomic desk setup. Joël talks about the pyramids.

+ +

Another old thing is the Bike Shed episode two weeks ago about success and fulfillment. Stephanie and Joël realized off-mic that one area they didn't really talk about so much is impact, and that is something that is very fulfilling for both of them. Today, they talk about impact and leadership as individual contributors because leadership is typically associated with management. But they believe that as ICs, at any level, you can be displaying attributes of leadership and show up in that way on teams.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 old in your world?

+ +

STEPHANIE: I'm glad you asked that question because I don't think we get a chance to talk about things that are exactly the same as they've always been. And so today, I'd like to share my ergonomic desk setup, [laughs] which has been old for about a year or so. And back then, I was having some issues with some back pain and some wrist pain, and I made a few upgrades and since then have not had any issues.

+ +

And I feel like it's one of those things that I just forgot about because when it stops being a problem, you don't really notice it. And today, I am able to reflect on my old problem of bodily pain while working. And I'm happy to say that things have been much better for a while now.

+ +

JOËL: Oh, that's amazing. What's one thing you think had the most impact in your setup?

+ +

STEPHANIE: Oh, I picked up one of those vertical mice for my wrist. I was having some wrist pain, like I mentioned. And I actually solicited some input from other thoughtboters for the best mouse to replace the Apple Magic Mouse that I was using, which I really wanted it to work for me because I liked the way it looked, but nevertheless, that was causing me issues. So I ended up with the Logitech MX vertical, and that has really solved my wrist pain. It is very not cute. [laughs] It kind of looks like a weird big, gray snail. But you know what? You got to do what you got to do.

+ +

JOËL: That sounds like an art project waiting to happen.

+ +

STEPHANIE: Yeah. I would love to see; I don't know, a way to make these vertical mice look a little more cute. Maybe I will stick some googly eyes or something on it and then just be like, this is my pet snail [laughs] that works with me every day.

+ +

JOËL: Do you have a name?

+ +

STEPHANIE: Not yet. Maybe I'll save it for what's new next week.

+ +

[laughter]

+ +

JOËL: Homework assignment. Years ago, I was also having some wrist pain. And I think one of the most impactful things I did was remapping some keys on my keyboard. So I'm a pretty heavy Vim user. And I think just reaching with that pinky for the Escape key all the time was putting a lot of strain on my wrist. So I remapped Caps Lock to control. That's what I did. Yes, because it was reaching down with the pinky for the Control key and remapped escape to hitting J twice.

+ +

So now I can do those two very common things, Control for some kind of common chord and then Escape because you're always dropping in and out of modes, all from the Home row. And now, both my hands feel great, and I can be happy writing Vim.

+ +

STEPHANIE: That's really nice. I think when I had asked in Slack about mouse recommendations, someone had trolled me a little bit and said that if I just use my keyboard for everything, then I won't need to use [laughs] a mouse at all. [laughs] So there's also that option too for listeners out there.

+ +

JOËL: It's true. You go to tmux and Vim, and on a Mac, maybe something like Alfred and a few OS shortcuts, and you can get 90% of the way to keyboard only.

+ +

STEPHANIE: What about you, Joël? What's old in your world?

+ +

JOËL: So you know what, something that's really old? Pyramids.

+ +

STEPHANIE: Wow. [laughter] I should have known that this is where we were headed.

+ +

JOËL: Long-term listeners of the show will know I'm a huge history nerd. And we think of the pyramids as being old, but they are ridiculously old. A fun fact that I have not learned recently because this is something that is old in my world, but that I learned a while back is that if we look back to Cleopatra, the last Pharaoh, she is closer to us in time than she was to the building of the Great Pyramid.

+ +

STEPHANIE: No. What? Wow. Okay, yeah, that definitely just messed with my brain a little bit. And now, I have to rethink my understanding of time.

+ +

JOËL: I think the way the timeline sort of works in my mind is it tends to get compressed the further back you go. So it's like, yeah, I think of modern-ish times, like, yeah, there's like a lot of stuff, and I'm thinking in terms of decades until maybe like the 1900s. And now I start to think in terms of centuries. And they're kind of more or less equivalent, you know, the Victorian Age. It fills about the same amount of space in my mind as like the '60s. And then you get to the point where it's just like millennia.

+ +

STEPHANIE: Mm-hmm. When you think of Ancient Egypt, do you think Cleopatra and also pyramids, so you kind of conflate? At least I do. I conflate the two a little bit. But yeah, I guess a lot of time passed in between that. [laughs]

+ +

JOËL: The pyramids are also really cool because they were one of The Seven Wonders of the ancient world, which is sort of, I want to say, like a tourist circuit created by the ancient Greeks, sort of like monuments that they thought were particularly impressive. But they're also the only ones that are still standing; all of the others have been lost to time.

+ +

STEPHANIE: Wow, it's the real wonder then [laughs] for being able to stand the test of time.

+ +

JOËL: It's also the oldest of the seven and has managed to survive until today, so very impressive.

+ +

STEPHANIE: I love that. Just now, when you were talking about thinking about time periods kind of compressed, I definitely fall victim to thinking that the '70s or whatever was just 30 years ago, even though we are solidly in the 2020s and, in reality, it's obviously like 50. But yeah, I think that always freaks me out a little bit.

+ +

JOËL: Yes, it's no longer the year 2000.

+ +

STEPHANIE: Turns out. [laughs] So, in case our listeners didn't know. [laughs]

+ +

JOËL: I think when we were close-ish to the turn of the millennium, it just made mental math so easy because you're at that nice zero point. And then you get to the early 2010s, and it's close enough within a rounding error. And now we just can't pretend about that anymore.

+ +

STEPHANIE: No, we really can't.

+ +

JOËL: We need a new anchor point to do that mental math.

+ +

STEPHANIE: I love that we're talking about what's old in our world because I love a chance to just repeat something that I've said before that I still think is really cool, but I feel like that doesn't get invited as frequently. It's just like, oh, how are you doing? What's new? So yeah, highly recommend asking people what's old in their world?

+ +

JOËL: Yeah. And beyond that, not just like, what are some new things you're trying? But kind of like what you were talking about earlier, what's something that's stayed stable in your life, something that you've been doing for a while that works for you?

+ +

STEPHANIE: Yeah, I love it. So another thing that's old is our episode from a couple of weeks ago about success and fulfillment. And you and I realized off-mic that one area we didn't really talk about so much is impact, and that being something that is very fulfilling for both of us. And that kind of got me thinking about impact and leadership. And I especially am interested in this topic as individual contributors because I think that leadership is typically associated with management. But I really believe that as ICs, at any level, really, you can be displaying attributes of leadership and showing up in that way on teams.

+ +

JOËL: Definitely. I think you can have an impact at every level of the career ladder, not just an impact on a project but an impact on other people. I remember the first internship I did. I was maybe two weeks in, and I had a brand new intern join. It's day two, and I'm already pairing with him and being like, "Hey, I barely know anything about Rails. But if you want help with understanding instance variables, that's the one thing I know, and I can help you."

+ +

STEPHANIE: Yeah, that's awesome. I mean, everyone knows something that another person doesn't. And just having that mindset of injecting leadership into things that you do at work, no matter how big or how small, I think is really important.

+ +

JOËL: I think there's maybe a lie that we tell ourselves, which is that we need to wait to be an expert before we can help other people.

+ +

STEPHANIE: Yeah, I've certainly fallen into that trap a little bit where I think it's held me back from sharing something because I assumed that the other person would know already or the thing I'm thinking is something I learned but not necessarily something that someone else would find interesting or new.

+ +

JOËL: Right. Or even somebody's looking for help, and you feel like maybe you're not qualified to help on that problem, even though you probably are.

+ +

STEPHANIE: One thing that I was really curious about is, can you remember a time when an IC on your team demonstrated leadership, and you were really impressed by it? Like, you thought, like, wow, that was really great leadership on their part, and I'm really glad that they did that.

+ +

JOËL: Yeah. So I think one way that I really appreciate seeing leadership demonstrated is in client communication. Typically, the teams we have at thoughtbot are structured on a particular project where there's like a team lead who is in charge of the project. It's usually a couple of consultants working together as peers. Depending on the situation, one or the other might take leadership where it's necessary.

+ +

But I've really appreciated situations where a colleague will just really knock it out of the park with some communication with the client or when they are maybe helping talk through a difficult situation. Or maybe even we realize that there's a risk coming down the pipeline for the project and raising it early and making sure that we de-risk that properly. Those are all things that I really appreciate seeing.

+ +

STEPHANIE: Yeah. I think the way folks engage in channels of communication can have a really big impact. A few things that come to mind for me that I think is really great leadership is when more experienced or senior folks ask questions in public spaces because that kind of cultivates a space where asking questions is okay, and even people who have whatever title or whatever years of experience they still have questions and can signal to other folks in the team that this is okay to do.

+ +

And the same thing goes for sharing mistakes as well. Also, just signaling that, like, yeah, we mess up, and that's totally normal and okay. And the consequences aren't so scary that people feel a lot of pressure not to make mistakes or share when they happen.

+ +

JOËL: Yeah. The concept you're describing is very similar to the idea of vulnerability.

+ +

STEPHANIE: Yeah, that sounds right.

+ +

JOËL: So kind of modeling that from more senior people helps create a safer environment for the more junior people.

+ +

STEPHANIE: I think another thing that I really love that others do for me, and something that I want to get better at doing for others, is speaking up when something is a little off because, again, with power dynamics, for people who are newer or less experienced, they might be noticing things, but they don't feel encouraged to speak up about it in a public space or even with their manager. But they might confide in another IC who is maybe a little more senior.

+ +

And one thing that I really liked that happened on my client project recently is a senior engineer said in Slack, "Hey, I noticed some sentiment from our daily sync meeting that we're cutting it close to our deadline." And he asked like, "Should we shift some priorities around? Or what is more important to make sure that we focus on in the next few weeks before the end of the quarter?" And I was just really glad he said that because I certainly had been feeling it. But I don't know if I necessarily kept a pulse that other people were also feeling it.

+ +

And so having someone keeping an eye on those things and being receptive to hearing that from folks and then being like, okay, I want to make sure that I bring it up to the manager because it's important. I thought that was really cool.

+ +

JOËL: Yeah. Now we're almost dialing into sort of emotional awareness of what other people on the team might be feeling and also the ability to think in terms of risks and being proactive about managing those.

+ +

STEPHANIE: I like your use of the word risks because that definitely feels like something that, in general, people are scared to bring up. But ultimately, it is the signal of someone who is experienced enough to know that it's important to make transparent and then adjust accordingly.

+ +

Even beyond noticing what folks are feeling, there are also more concrete things that can be noticed as well, like if team members are complaining about CI build time being really long and that being a repeating issue in getting their work done. Or any other development or tooling thing that is causing people issues, having someone notice how frequently that happens and then being like, hey, this is a problem. And here's what I think we should do about it.

+ +

JOËL: So not only the awareness but also the initiative to try to enact change.

+ +

STEPHANIE: Yeah, absolutely.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So you and I are actually working on the same client but on different project teams. And you've been involved with making improvements to CI to reduce kind of the problem that I was just talking about where it takes a while for us to develop. And you are working on reducing the number of days between the master branch and when you are allowed to hit the merge button to make sure that feature branches had incorporated the latest changes for master.

+ +

And one thing that I really like that you did was you solicited folks' input for what that time range should be. So I think you were playing around with the idea of giving people three days to merge, or else they'd have to rebase.

+ +

JOËL: I thought it was being really comprehensive here with three days because, you know what? You solicited feedback, you got review, but maybe it's the end of the day, or maybe someone's in different time zones. So we definitely want to cover at least a 24-hour period. So three days gives you an extra day. It should be safe. Is there any common situation where you might want a PR to be open for more than three days, but you wouldn't have rebased the latest master changes?

+ +

STEPHANIE: Yeah. I can see how you thought about it from a few different angles too. Like, you're thinking about time zones and folks working in other regions. And I ended up responding to you, and I was like, oh, what about the weekend? [laughs]

+ +

JOËL: Oops.

+ +

STEPHANIE: Because three days seems a little short if two of those days are eaten up by Saturday and Sunday. But what I liked was that you said, "Hey, I'm thinking about doing this. What do other people think?" Because you didn't claim to know what works best for everyone. And I think that's a really important skill to be honest, soliciting others for feedback, and knowing who to ask for and who to make sure you are not negatively affecting their work by making a change or making a decision.

+ +

JOËL: And in this case, it helped me realize that I had skipped over the most obvious edge case while thinking I'd covered all the really niche ones

+ +

STEPHANIE: We got there in the end, [laughs] and I think made the most informed decision.

+ +

JOËL: I guess that's just good product design in general. Talk to your users, get early feedback, put a prototype out where necessary. You don't always want your users to dictate what you will do, but it's good to get their feedback. And similarly, I think that applies when working with dev-facing things; you want feedback from developers. If I asked everybody at the company, I would have gotten a lot of different answers. And I might not have gotten one that satisfied everybody. But having some of that feedback helps me make a more informed decision.

+ +

STEPHANIE: Yeah, and to take it to the next step, I think there's also accountability for those decisions that you have to have. So if the decision that you made ends up being like a huge pain for some unforeseen reasons, I imagine you'd be on top of that as well and would want to figure out how to adjust if the experiment doesn't work as well as you would have liked.

+ +

JOËL: Right. I think we often talk about failing early. In fact, we have a recent episode about dealing with failure. And we mostly talked about it from a technical perspective, catching errors or making code more resilient to failure. But there is also a human component of it, which is if you catch errors or design problems, and I'm using design here as a product design, not in visual design, at a prototype phase or maybe a user interview phase, you've saved yourself a lot of maybe unnecessary work that you would have had if you went out to the product phase and shipped it to your entire customer base.

+ +

I guess, in a sense, it's worth thinking about other developers, the engineering team as customers sometimes. And a lot of the internal facing parts of your project are effectively a product geared towards them. They are the users. And so, throwing in a little bit of product development and design skills into building internally-facing software can have a huge impact.

+ +

So beyond just thinking of developers as a sort of internal customer base, occasionally, we work on projects where you are building internal tooling for other teams; maybe it's business development, maybe it's the marketing team, maybe it's some form of customer support. And that can often have a really large level of impact. Have you ever been on a project like that?

+ +

STEPHANIE: I have. One of my first jobs was for an e-commerce company. And I built tools for the customer support team for dealing with customers and getting their orders correct and fixed and whatnot. So I did work on an admin dashboard to make their jobs easier as well as the company also had its own internal software for dealing with warehouse logistics. And so, I also built a little bit of tooling for our logistics and fulfillment team.

+ +

And I really liked that work a lot because I could just go over and talk to the folks internally and be like, "Hey, what did you mean by this?" Or like, "What do you want here, and what would make your life easier?" And I felt a much more tangible impact than I did sometimes working on customer-facing features because I would deliver, and that goes out in the world. And I don't get to see how it's being used, and the feedback loop is much longer. So I really liked working on the internal tooling.

+ +

JOËL: In my experience, those teams are often really underserved when it comes to software. And so it's possible to make a huge impact on their quality of life with relatively little work. Sometimes you can just take an afternoon and eliminate a thing that's causing them to pull out their hair.

+ +

STEPHANIE: Yeah, absolutely. And you get the satisfaction of knowing that you built something exactly as they wanted it. Whereas sometimes, with user or customer-facing features, we are guessing or experimenting a little bit. And yeah, I think having someone who then is very grateful for, I don't know, the button that you added that makes them have to click less buttons [laughs] when they do their work in an internal dashboard can feel really good.

+ +

JOËL: Having that direct access can be really nice where you get to just go over and talk to them or shadow them for a day, see how their work happens, get to hear their frustrations real-time. It's often a smaller group as well than you would have for our customers, which might be thousands of people, and so you sample a few for user testing. But for an internal team, you can get them all in a Zoom call. I don't necessarily recommend doing a giant Zoom call for this kind of thing, but it's a small enough group that you could.

+ +

STEPHANIE: I'd like to flip that around to you. Have you ever been on the receiving end of an improvement or someone else making your life a little easier, and if you could share what that was and how it made you feel?

+ +

JOËL: I think pretty early on in my career, one of my first projects for thoughtbot, we were building a small kind of greenfield app for a startup. And another member on the team took a couple of hours one afternoon to just write a few small abstractions for the test suite that; just made it so much nicer to write tests. And we're pretty scrappy. We've got a tight deadline, and we're trying to iterate very quickly. But that quality of life difference was significant to the point I still remember this ten years later. I think we were rotating this developer off, and this was kind of a farewell present, so...

+ +

STEPHANIE: That's really sweet.

+ +

JOËL: You know what? I love that idea of saying when you rotate off a project, do a little something extra for the people you're leaving behind.

+ +

STEPHANIE: Yeah, I love that too. It's your kind of like last chance to make a small impact in that world.

+ +

JOËL: Especially because on your last couple days, you're probably not expected to pick up a ticket and get it halfway done. So as you're kind of ramping down, you might have a little bit of time to do some sort of refactoring task or something that needs to get done but hasn't been prioritized that will have a positive impact on the team.

+ +

STEPHANIE: Yeah, or even writing a script to automate something that you have kind of developed the muscle memory for, like, oh, I run these three commands in succession. And if you could just wrap it up in a little script and hand it off to someone else, it is a very sweet parting gift as well.

+ +

JOËL: Absolutely. So I'm curious, we opened the topic talking about impact, and you immediately connected that to leadership, and I want to explore that idea a little bit. Do you think impact has to be connected to leadership? Or are there ways to have impact, maybe outside of a leadership role?

+ +

STEPHANIE: I think they kind of go hand in hand, don't you? Because if you are wanting to make an impact, then in some ways, you are demonstrating that you care about other people. And at least for me, that is kind of my definition of leadership is enabling other folks to do better work. And you and I talk about attending and speaking at conferences pretty frequently on the podcast. And that is a very clear way that you are making an impact on the community.

+ +

But I also think that it is also a demonstration of leadership that you care enough about something that you want to share it with others and leave them with something that you've learned or something that you would like to see be done differently.

+ +

JOËL: And just to be clear here, the way you're talking about leadership is not a title; it's an action that you do. You're demonstrating leadership, even if you don't have any form of leadership title.

+ +

STEPHANIE: Yeah, absolutely. I think that because software development is a collaborative job, in some ways, in most things we do, there is some form of leadership component, even if you're not managing people or you don't have a particular title.

+ +

JOËL: Like you said, it's about the things that you're doing to enable other people or to act as a sort of force multiplier on your team rather than how many people report to you in the org chart.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: So if everybody aspires to enable each other and to be impactful, is it possible to have a team where every person on the team is a leader?

+ +

STEPHANIE: Whoa, [laughs] asking the big questions, Joël. I mean, logically, the answer seems to be no based on our traditional understandings of leadership and being a leader or follower. But I also kind of disagree because, as developers, we have to make choices all of the time, and that can be at the level of the code that we write, the commit messages we write, what we communicate in our daily sync.

+ +

And those are all opportunities, I think, to inject those skills that we're talking about. And so, yeah, everyone on the team is making decisions about their work. And inherently, to me, at least, the way you make those decisions and the impact of those decisions imply some form of leadership. What about you? What do you think about this?

+ +

JOËL: It's tough because you can get into bikeshedding the definition.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Which, hey, it's all about that, right? You know, is leadership about authority or decision-making capacity? Is it about impact? Is it about maybe even responsibility if things go wrong? Who's responsible for the consequences? It could be about position in the org tree and relative depth on that tree, to use some data structure terminology. But I liked your emphasis on the idea of impact and enabling others. So now it's a thing that you do.

+ +

And so any member at any moment can be demonstrating leadership or acting in some leadership capacity, and they're contributing to the team in that way. And in the next moment, somebody else stands up and does the same thing. And it doesn't necessarily have to be in conflict. You can actually be in a beautiful harmony.

+ +

STEPHANIE: Yeah, I really like the way you said that. I love a good beautiful harmony. [laughs] I think part of what has shaped my view on this is a keynote talk from RubyConf Mini back in November by Rose Wiegley. And her talk was called "Lead From Where You Are." And I think perhaps I've kind of internalized that a little bit to be like, oh yeah, everything we do, we can make a decision that can have a positive impact on others.

+ +

So that has helped me at least feel like I have a lot more agency in what I do as a developer, even if I don't have the concrete responsibility of being a mentor to a particular person or having a direct report. It injects meaning into my work, and that goes back to the fulfillment piece that we were talking in, knowing that, like, okay, like, here's how I can make an impact. And that's all just wrapped up together.

+ +

JOËL: So you kind of defined earlier the idea of leadership as work that has impact on others or that enables the work of others. And I think that there are some forms of that work which are kind of highly respected and will get you noticed and will be kind of called out as like, oh, you're performing leadership here. You stood up in that meeting, and you said the hard thing that needed to be said.

+ +

And there are other forms of supporting or enabling the team that almost get viewed as the opposite of leadership that don't get recognized and are almost like you're seen as less of a leader if you're spending a lot of your time doing that. That can be sometimes more administrative work. How does that sort of fit into this model where we're talking about leadership as something that has an impact on others?

+ +

STEPHANIE: Yeah, I'm glad you mentioned that because I have a lot of gripes [laughs] and thoughts, I suppose, about what work is visible and not visible and valued more or less. And I do think some more traditional signals of leadership, like talking the most in a meeting, like, that I don't necessarily think is my definition of leadership; in fact, the opposite. A true leader, in my opinion, is someone who makes space for others and makes sure that all voices are heard.

+ +

And yeah, I guess it just speaks to like what I was saying about soliciting other people for feedback as well. It's like someone to me who demonstrates leadership is not someone who thinks that they have all the right answers but actively seeks out more information to invalidate what they think is right and find the right solution for the folks on their team.

+ +

Similarly, in Rose's talk, she also mentions the idea of being a problem finder, so not just being tasked with solving a problem but looking around and being like, okay, like, what aren't we talking about and that we should be? And obviously, also contributing to making that better and not just being like, "Here's a bunch of problems, [laughs] and you have to deal with it," but that proactive work. Ideally, we are addressing those things before they become a huge problem. And I really liked that aspect of what leadership looks like as well.

+ +

JOËL: Yeah, I think something that I've noticed that I do more as I've built more experience over time is that when I started off earlier in my career, it was a lot of here's a problem that needs to be solved, go and solve it. And then over time, it's what are the problems that need to be solved? You have to sort of figure out those problems before you go and solve them. And then sometimes it's even one level above that; what questions should we be asking so that we can find the problem so that we can solve them?

+ +

And that will happen...it could be internally, so some of the things that I'm doing currently around improving the experience of a test suite is like, okay, we know sort of that it's slow in certain ways. How can we make that faster? We know that the experience is not great. But what are the actual problems that are happening here, the root causes? Or we're getting some complaints, but we don't really know what the underlying problem is. Let's go and search that out.

+ +

STEPHANIE: Yeah, that brings to mind an issue that I think I see a lot on client projects where perhaps stakeholders or an engineering manager is seeing that we are slow to merge our PRs, and they kind of start reaching for solutions like, okay, well, people should spend more time doing code reviews or whatever, thinking that that's what the issue is.

+ +

But in reality, maybe it's, I don't know, it can even be something as lower level as having to re-request reviews every single time you push a new commit because the GitHub settings are such that it requires additional approvals for every new change. And that is something that they would not know about unless someone spoke up and said, "Actually, this is what's causing us friction," and having to go back and do these manual tasks that maybe we should explore a different alternative to solve.

+ +

JOËL: Yeah, instead of just jumping in with a solution of we need to throw more dev hours at this problem, it can be useful to step back and ask, okay, well, why do we have this problem in the first place? Is it a process issue that we have? Is there some sort of social element that we need to address and organizational problems? And if it's not that, then what are the questions that we're missing? What questions should we be asking here to understand this problem?

+ +

STEPHANIE: Right. And even speaking up about it too and going against someone's assumption and saying, "Here's what I've been seeing, and this is what I think about it," that takes a lot of courage. And I do think it is something that is especially important for folks who are more experienced and have more responsibility or a higher-level title, but ideally is something that anyone could do. I would love to know for you, Joël, what is the most important way that you want to make an impact as a developer?

+ +

JOËL: I think the human element is the most important. I want to have an impact on my colleagues, on the dev teams with my clients. I want to ship good work. But I think the most valuable thing to invest in is other people.

+ +

STEPHANIE: Yeah, I agree. I think for me; it's like making a good work experience for the people that I work with. And it's also a little bit selfish because then that means I am having a good work experience, and I'm in a good culture and environment. But that is definitely an area that I spend a lot of time thinking about and wanting to start conversations about.

+ +

JOËL: It's a win-win, right? You make it better for everybody else and better for you in the process.

+ +

STEPHANIE: Exactly.

+ +

JOËL: And it's okay for it to be somewhat selfishly motivated. Like, it doesn't have to always be every day super altruistic like; I just want to make the world a better place.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Like, you know what? I want my corner of the world to be better, and in doing so, I'm going to make it better for everyone else.

+ +

STEPHANIE: What's that phrase? The tide rising all the ships. [laughs] That is extremely not correct, but I think you know what I'm trying to say.

+ +

JOËL: I think a rising tide lifts all boats.

+ +

STEPHANIE: Yeah, something like that. I love a good rising tide. [laughs] On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. Or let's rise up.

+ +

STEPHANIE: [laughs]

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+5wB64jKN + + ]]> + + Joël Quenneville + Stephanie Minn + + + 377: Error Handling + https://bikeshed.thoughtbot.com/377 + 762bb2d3-b798-4f4a-8825-e3b40fe0151e + Tue, 28 Mar 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël is a mentor for RailsConf and got matched with a speaker. Stephanie has been having trouble stepping away from her work. It's frustrating when chasing down a bug because something's gone wrong, and you spend a whole afternoon figuring out where it is. Joël and Stephanie discuss error handling as a possible solution. + 45:06 + no + + + Joël is a mentor for RailsConf and got matched with a speaker. Stephanie has been having trouble stepping away from her work. It's frustrating when chasing down a bug because something's gone wrong, and you spend a whole afternoon figuring out where it is. Joël and Stephanie discuss error handling as a possible solution. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Mis en Place Writing (https://www.swyx.io/writing-mise-en-place) +Errors accumulate at boundaries (https://thoughtbot.com/blog/testing-your-edge-cases) +Retryable errors (https://thoughtbot.com/blog/handling-errors-when-working-with-external-apis) +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 recently, RailsConf has closed out their CFP, and they've started sending out acceptances and rejections for proposals. And one thing that they do that I think is really nice is that they offer first-time speakers the ability to get matched with a speaker-mentor, somebody else who has given talks before that can help them prep their talk, listen to them rehearse, that kind of thing. And so they had put out a call for mentors last week. I responded to that, and I got matched with a speaker today. +STEPHANIE: Cool. Is this your first time being a speaker-mentor? +JOËL: First time for RailsConf. I've done it for another conference before. +STEPHANIE: That's really exciting. What do you like about playing that role? +JOËL: So I very much like prepping and giving talks myself. And I really value if there's something that I'm excited about sharing it, helping others build up that skill as well. So I think it's a great opportunity. I also remember what it was like when I was a first-time speaker and just how very nervous I was and not sure. +So I think having someone who can play that role is an opportunity to have a really powerful impact in what's oftentimes, I want to say, a monumental moment. But it's kind of like a milestone marker moment in someone's career, the first time I gave a talk at a conference. So you get to help them to make that moment the best it can be. +STEPHANIE: I love that, yeah. You make a really great point that after you've been speaking for a while, you maybe might forget what it felt like to give your first talk and how big of a deal it is. And in general, I think one thing I really love about Ruby Central conferences is how supportive they are of first-time speakers. So even in the CFP, they mentioned that they welcome first-time speakers and want to make sure to accept talks from those folks and then provide them support through this mentor program. And yeah, it just makes me feel really happy. +JOËL: Do you remember your first talk? +STEPHANIE: I do. So my very first talk I gave virtually at RubyConf in 2021. And then last year was actually my first in-person talk. And I remember even though it was technically my second talk; it was really my first talk in front of an audience. And I saw speakers in the Slack workspace asking questions about the AV setup, and I didn't even think to consider that in my preparation. So it was nice. Even though I didn't get set up with a mentor, to share a space with other experienced speakers and see what kinds of things they were asking about or what kinds of things they were sharing in that Slack space was helpful for me. +JOËL: So when you do a proposal, do you typically have an outline already built out, or is it mostly a concept that you're pitching, and then you maybe start with an outline? Or where do you go next after a proposal has been accepted? +STEPHANIE: That's a great question. I think first, I procrastinate for several months, [laughs], but I do try to write an outline in the proposal when I submit it so I do have a starting point. And I think that actually helps the CFP committee, too, when they are evaluating proposals to kind of get a better idea of what the talk will be about. And so, in my ideal world, I already have some structure, so by the time I've procrastinated to the point where it's a month or so before the conference itself, [laughs] I have an outline. +And I end up writing words, like, I will just write my talk as if it were an essay with this bullet point outline already. And I find that helpful for me because I definitely have a bit of a stream-of-consciousness productivity energy. And so if I just put it all out there, I will then go back and be very ruthless, I suppose, in my editing, and I think that's where the magic happens. +So I kind of let myself just word vomit all over the page. And then the real work comes in the editing process and organizing and making sure it sounds the way I would want it to sound when I'm speaking. And yeah, that's how it has worked for me so far. +JOËL: So you have a sort of a separate phase for sort of just stream of consciousness dumping and then separately editing. And having those two separate is an important part of your process. +STEPHANIE: Yeah, I think so. I don't do as well trying to imagine the structure and everything perfectly the first time around and then filling things in. I find that just putting everything out there and, you know, a lot of things get cut. But that works well for me. What about you? What is your typical conference talk writing process? +JOËL: I think mine is a little bit more iterative. I tend to put in some pieces that I like and then try to connect them together, try to make sure it's telling a story. I think a lot about the pedagogical side of things, where people are going to be confused, where they're going to have questions, where they might check out. +And then very early, start doing kind of draft rehearsals where I'm starting to work on the talk. And I will stop halfway through because, in my mind, I'm trying to seat myself in the audience and be a person who's listening. And there might be a moment where I'm like, wait a minute, you just jump from one thing to another, and I don't get the logical connection here. And I might pause right there in the rehearsal and add in, say, okay, we need a transitional point, or we need to explain a concept between these two. +And I keep doing that until I can get through the whole thing and then realize it's way too long and start cutting. And I cut aggressively, and now it's too short. And now I go through it again. And again, people have questions in the audience, hypothetical audience; I am the audience. And so I really kind of inflate it and then cut it down and re-inflate it and cut it down a bunch of times until I'm happy. +STEPHANIE: I like that a lot. That sounds right. That sounds very you to work even on a conference talk iteratively. +JOËL: It's very time-consuming. So I don't know it's the most efficient way to build a talk, but it's a process that works for me. +STEPHANIE: Yeah, that's true. And then there's value in the journey, even if the talk ends up changing from the very beginning to the end product. +JOËL: So the approach that you described for yourself, I think, where you have a rough draft, and you're separating the editing from almost like a creative process, reminds me a lot of an article that I read called "Mise en Place Writing" by...I'm not sure what their full name is. They go by the handle Swyx. This is an article about their process for writing, but I think it applies to conference talks as well. Have you seen this article? +STEPHANIE: I haven't. But that, I think, is similar to how I've thought about it or I've seen or heard other authors talk about their writing process and it being kind of similar where the creative work...they give themselves a lot of grace and just letting it be. And then the, like I mentioned, real work is in the editing process. It's kind of two different mindsets, I think. +JOËL: We'll link the article in the show notes. +STEPHANIE: I'm curious then how you incorporate visuals into your process because I think that's where my workflow is a little less successful because I'm not really thinking about visuals along with the words, and they do feel more like an afterthought. And I've always been really impressed when people who give talks can have a really visual and dynamic slide presentation. How does that work for you? +JOËL: So I think I try to avoid slides that are three bullet points in the slide, and then I'm going to talk about it for three or four minutes for each bullet point. People read those quickly and then check out. I'll oftentimes try to have, like, turn each of those bullet points into a full-on slide. And maybe it's just a title and a fun picture or something like that. What this ends up doing is I kind of really inflate my slide deck. I'm going through maybe 80 or 100 slides in a 30-minute presentation. +So it's multiple slides a minute. They move by really quickly. So I usually have either just an image or a header. I will usually start by just sketching it out with headers and then, where it makes sense, using an image. An image can be just for fun, or it can be something like a diagram where it is trying to illustrate a point. +STEPHANIE: Yeah, I like that. I think talks with a lot of slides that are mostly just images or something that you can grasp in a few seconds are really engaging because you're keeping it moving, and you don't really let people get bored. And so you show a new slide, and they look at it, but then they are able to direct their attention back to what you're saying. +JOËL: It's fun too with images because you can reuse them, and then they become a way to connect people back to a theme or let them know that you're making the same point again. A lot of talks, I will have a central theme that gets repeated. I'll often have a slide with some fun image with my key point on it. And then that slide will show up three or four times in my presentation oftentimes because each of the main points I'm trying to make kind of culminates at that same takeaway. +And so for example, in the talk I gave at RubyConf Mini last fall, I had a slide about writing Ruby code being delightful. I think having some children being happy with just a big title being like, "Oh, delightful," or something like that. And after each of my examples where we went from code that was less good to something that was more idiomatic, Ruby that was really fun to work with, I would finish on that slide and be like, hey, our code is now delightful. +And hopefully, that helped people with the takeaway of, like, we want to write delightful code. Ruby has tools to do that. And then, hopefully, they either remember the things they can do to get to that point or can look it up and find a talk online. +STEPHANIE: Yeah, I watched that talk, and I really vividly remember that slide and the theme that you were trying to hone in on. So I thought it was pretty effective. I think this makes me realize speaking, I mean; speaking is obviously a skill but even the process of creating a talk in that particular medium is also a vast skill and can go...there are so many different styles and flavors. But I really think that what you said will get me thinking next time I'm writing my talk and how I can better incorporate that kind of engagement with the audience and making sure that the way I deliver the talk is just as thoughtful as the content itself. +JOËL: Yeah, I've been putting a lot of thought into what makes a good talk and what elements are unique to my process, what elements can be useful to others because now I have to coach someone else on their process and say, "Hey, here's the thing that worked for me. Maybe this will be helpful for you." Or maybe it's just, "Have you tried this?" Or "I think audiences will be asking this question at this moment, what do you think of this?" So that's definitely been top of mind in a whole other dimension for me recently. How about you? What's new in your world? +STEPHANIE: So before we started recording, I was heads down deep in the muck of trying to write some tests, some RSpec tests on my client project. And the domain for this client project is really big. There are a lot of models. And I was starting to go deep into the factory setups for our test fixtures. And it was hairy. And I was just going further and further down the rabbit hole to the point where I was skipping lunch. +JOËL: Ooooh. +STEPHANIE: Yeah, I was like, I couldn't pull myself away from it, and I kind of regret it a little bit. [laughs] And so I was just thinking about, like, how can I incorporate taking breaks a little bit more and feeling better about stepping away from the work when I'm really deep in it? You and I had this standing appointment to record [laughs] a podcast, so that was kind of the signal to me that it was time to try to set it aside. +And I did end up taking the dog for a walk around the block beforehand to get some fresh air, but yeah, it was a little rough, I don't know. How do you deal with just being so deep in the code that you don't really want to resurface? +JOËL: That's hard because sometimes I'm feeling productive, and I don't want to stop because I feel like I might not get back into the flow quite as easily. Sometimes it's just out of frustration. It's like, oh, I'm just so close to getting this bug done. If I get this one more test to pass, then I'll be good. And I keep doing one more thing. And the next thing I know, I have skipped lunch, and it's late in the afternoon. And it's just like; it's been a frustrating day. +STEPHANIE: And you're cranky, yeah, yep. I know that feeling. +JOËL: I've stopped being productive for the past hour. But I'll be like, one more thing, one more thing. +STEPHANIE: I think I was in that place because I was starting to get deep into the internals of models completely unrelated to the test that I was writing, but that was just where the rabbit hole led me. And I think after this, I will go and ask in Slack for a pair because I think that would be really helpful right now. I've just reached the limits of what I know. And I'm almost positive that someone knows how to do this more efficiently than I do. So that was a bit of a signal to me, but it was very challenging untangling myself out of that headspace. +JOËL: Have you ever played the video game Civilization? +STEPHANIE: No, I haven't. +JOËL: It's a turn-based historical strategy game. The running joke about it is that people get really pulled into it. And they're always just saying, "I'm going to play one more turn, and then I'm going to be done for the evening." And the next thing you know, it's 4:00 a.m. And I think that sometimes applies to fixing one more failure, just getting one more file in that chain of figuring out what the bug is in code. It's a very similar feeling. +STEPHANIE: Yeah, I know exactly what you're talking about. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So it can be really frustrating when you're kind of chasing down a bug because something's gone wrong, and now you're spending a whole afternoon figuring out where it is. Do you ever find yourself maybe acting preemptively to try to prevent those sorts of things from happening in the first place? So maybe putting in some sort of guards or error handling or something like that so that your future self won't have to spend that afternoon. +STEPHANIE: That's a great point because the bug that I was facing just now was definitely something I think could have been avoided. It was a classic no method [laughs] on nil class error. And I am still unsure how that happened, and I hope to come back to it after this. But yeah, that certainly is a great topic to get into, error handling. I think it's been on my mind a little bit lately because I'm working on a full-stack feature that has user-facing errors and things we want to make sure that we communicate to the user so that they could hopefully do something about it or just contact customer support on this app. +But there are also some API calls that are kicked off in the process of the user submitting the form, and those can lead to a bunch of different failures. And we may or may not have already discovered what those failures could be, and there may or may not have been designs created for those different failure states. And I feel like I haven't quite gotten a handle on how to deal with all of the possible errors that can happen when implementing a full-stack feature or a vertical slice. Yeah, that has tripped me up a lot lately. +JOËL: I think my time working in Elm has really made me much more aware of the different ways that things can fail just because Elm's type system is very robust. It's very complete. And so it will point out to you every potential place that could have a failure and ask you to handle it because it doesn't want to get to a point where it doesn't know what to do and there's a runtime error for something like no method or something like that. +So if you've got a potential nullable value and you're trying to say, okay, take this and render it, the compiler will say, wait a minute, you did not handle the null case. Give me something to do with the null case, or I refuse to compile. And now you've got to handle that. If there's something that might feel like an HTTP request, again, the compiler would be like, well, but what about the failure case? You didn't tell me what to do on the failure case. This is an incomplete piece of code. I refuse to compile that. +So I think I've built now a little bit of anticipation because I know the compiler is going to tell me to do this. Now even when I write code that's not compiled like Ruby, my brain compiler is still like, oh, there's a nullable value here. You didn't check the null case. What are you going to do about that? +STEPHANIE: Yeah, that's a great point. I think the more experience I gain, the more possible errors I see in the world or out in the wild. When I think about developing on the web, you know, you mentioned HTTP requests, but also, if we fail to connect to the database or a job fails to enqueue, there are just so many places where things can go wrong. And it's almost like the more I learn about all those possible failures, the more anxious I am [laughs] to make sure that I've covered everything though I think there is some amount of just that being impossible. +And I'm particularly interested in figuring out what is enough because one thing that really I find quite painful is when you don't think through things enough and you just cross your fingers and hope it works and you ship it, and then your team is dealing with a lot of bugs or a lot of noisy error monitoring notifications afterwards. And so that's kind of what I'm trying to adjust for, I think. +JOËL: I think there's like two general classes of approach you can use to deal with that; one is to try to prevent errors altogether, and there's a variety of tools you could use for that. I'm thinking of either something like a type system or maybe test-driven development or even some sort of analysis tool. That could be diagramming, that could be decision tables, something like that. All those, I think, fall under better understanding of the edges of your system. Whereas sometimes you want to do the opposite and sort of really lean into, okay, errors will happen. How do we recover from them? How do we make them easy to diagnose in the future? +STEPHANIE: Yeah, that second bit is really interesting to me because I've started to try to think about the errors and who we want to notify about the errors. And so I feel like there are a few different categories of errors where if it's a validation error and it's something that the user can fix, you know, that we want to make sure to surface and tell them how they can fix it. If it's like a programming error, there's no value in showing that to the user. +And I'm sure that we've all seen a website that responded with a 500, but then we actually saw the error message itself, and we're like, ooh, this is kind of weird [laughs] to be seeing this. And so realizing, okay, that's not valuable to the user. But what should I be doing with it instead? And maybe that is hooking it up to whatever error monitoring service you use to make sure someone is alerted. Or, I don't know, even in the third case, like, what should a customer support team be notified about? And that kind of sits in between not quite a user-facing error but also not a bug, and that's a different category. +JOËL: So, something that is not necessarily a problem in the code, but you might want somebody in the company to know about and be notified about. +STEPHANIE: Yeah, exactly. Maybe not something that is so urgent that it needs to be flagged in real-time but goes somewhere, and someone will check on it at some point. [laughs] So you were mentioning that you now have a better sense of what could go wrong. How much time do you spend writing code to cover all of those different possibilities? +JOËL: Hmm, I don't know that I've ever put the time to quantify it. I would say a decent amount because you've got to think about...sometimes they're not even things that can go wrong per se. But they're off that very simple, linear happy path that you're thinking of. So you might think even for rendering some kind of view, and you've got some search results you're trying to display. +Have you considered an empty state? Is there a difference between initially loading the page or have not performed a search yet, and search but did not find any results? Those are things that are not necessarily errors, but they're not things you're thinking in mind when you're just writing that first happy path of, like, oh, load page, show results. I assume there's always a result set. And so those are things that are important for the user experience that you need to have, but that are kind of edge cases that you have to add in afterwards, or you have to think about. +And so I think that, for me, tends to fall under a similar category as okay; what if an error happened? Especially when you're dealing with kind of a full-stack situation where on the front end maybe you're making a result to a back end to pull down...let's say you're making a search and the back end is doing the actual search. You send up a query. Now you get back a failure. +Is that the same thing as getting no results back? Like, a success with no results, versus an error code, versus not making a query yet. So you've got like four or five states you've got to think about on the front end to display and how you're going to handle those. So I think thinking about those upfront is often really helpful. +STEPHANIE: As you were talking about that, I suppose I asked the question because I have experienced when those things are not thought about upfront, and then you discover them as you're implementing. And how much time do you use to kind of go into a little detouring trying to make sure that you have all of the edge cases covered, and at what point do you stop? Because you're like, I've covered what I can. And this ticket was supposed to only be three points [laughs] or whatever, you know. +JOËL: Yeah. And how do you keep a feature from ballooning when there are all these edge cases? +STEPHANIE: Yeah, exactly. It's a balance. +JOËL: Are there any techniques that you like to do when you...so you pick up a ticket that looks easy, but that might have a lot of these hidden edge cases in it. Are there techniques you like to use that might help you figure out those edge cases and maybe give you some follow-up questions that you might reach out to the product person to clarify? Or maybe it's mostly intuition and experience as a developer that you kind of figure out that, oh, these are the things we need to ask about. It's like, have you thought about an error state? +STEPHANIE: Yeah, that's a good question. In general, I'm a little suspicious of any ticket that doesn't include some kind of acceptance criteria about the unhappy path. And I certainly think it's a lot easier once you are embedded into this domain, and you have that expertise, and you are able to see the possible issues you'll run into. I do think that I like to do a little bit of coding just to kind of explore the space, and then that does give me more insight into how I might be able to follow up on the ticket. +So you mentioned techniques. Especially if they're written as user stories, I don't think they necessarily incorporate the flow or the procedure of how things are kicked off. And so when you're thinking about implementing it, you're like, oh, this actually needs to happen in the background, or this should be synchronous or not. And those are a lot of error states that I find are missing when I pick up a ticket. +And I think it also depends on which way you want to implement it what implementation is viable. And then maybe you bring it to a product person, and they are actually like, "No, we don't want it to work like that." And then you have to kind of rethink things a little bit. But yeah, certainly, the process of taking a user story and then doing an initial think-through of what approach you want to take definitely surfaces some potential unhappy paths. +JOËL: It's almost like prototyping it in your mind. +STEPHANIE: Yeah, I think so. I think it also depends a little bit on the team because if the engineer wrote the ticket, then there likely has been some thought about unhappy paths. But on other teams that I've been on when implementation is up to the person who picked it up rather than kind of spelled out for you by someone else who did that thinking, that's definitely an opportunity to pause, I think, and document which way you might want to go so that you can make sure that you account for the possible things that could go wrong that likely the user story didn't cover. +JOËL: Sometimes there are some edge cases or failure states that are just sort of built into the problem that you're solving. If you're having to make a background request, there's always a chance that that might fail because the network is not trustworthy. Sometimes though, those things just kind of come out of our implementation, the fact that we implemented it in a particular way. +And that's not something that you'd expect a product person to have to think about. That's more on us as developers to be like, oh yeah, well, I'm indexing into a hash and didn't think to check is a nested hash even present? Maybe that key isn't there. And now I've got a weird nil error, an undefined method. That's kind of on us rather than on, like, oh, a specific kind of thing that we can think about upfront. +STEPHANIE: Yeah, that's fair. And I think that is just an important part of the development process. Though you make a good point because I think that just kind of speaks to all of the different layers of things that can go wrong [laughs] and figuring out which ones are specific to your role as developer to account for, and then which are ones that you need to bring in or pull in a designer to chat about. It can be a little overwhelming. I'm overwhelmed just thinking about it. +[laughter] +JOËL: Yeah, errors are not a sort of monolithic class of things. They can't be an afterthought. But they're also not just a thing where it's like, oh yeah, do the error handling, and then you're good. We kind of lump a lot of things under the concept of errors, even if they might all eventually manifest as some kind of exception. I guess a true solution is just one giant top-level rescue nil. +STEPHANIE: [laughs] Very funny. +JOËL: So we've talked about a few different dimensions of errors where they might be sort of user-visible or not, or something that's more implementation-based versus inherent to the problem. One thing that we haven't looked at is the dimension of errors that might be recoverable versus not. Have you ever built a system where you had errors that could be recovered from and didn't crash the program? +STEPHANIE: Ooh, yes. That makes me think about retrying and especially what you're saying if things are happening in the background. Maybe there is an ephemeral error where the network timed out or something. But if it is given another shot, it might succeed on the second go. And I think there's a whole process of thinking about what happens when a process has to be retried and if there were any side effects that you didn't want to have committed the first time around, you know, but then something else that was supposed to happen and when the process happens again, things are very broken. So making sure that you are keeping things idempotent so that by undoing it again, there are not any unforeseen issues. +JOËL: I heard you say that word commit here, and that's kind of a keyword to my mind. I immediately think database transactions. Is that the sense that you're thinking about this term here? Or does it have another meaning for you in this context? +STEPHANIE: Yeah. I do think I used that word specifically because when I've run into this in the past, it has been around making database changes. I'm trying to think if there is another way that this might show up. I think even in something like sending an email, too, though it is a bit lower stakes. I've certainly, as a user, experienced when that goes wrong and just been [laughs] flooded with emails and being like, wow, this is annoying. And that's, I think, something valid to consider as well. +JOËL: Yeah. You don't want that email job to be a thing that gets retried and just keeps failing because there's a nil error after the email gets sent. And so we just re-enqueue it, re-enqueue it, re-enqueue it, and the person ends up receiving 500 emails. +STEPHANIE: What about you? Any thoughts about recoverable errors? +JOËL: Yeah. I think really common for me is thinking about that in the context of a background job because those are things that I think are specifically designed to be retried if they fail; at least, a lot of job enqueuing systems assume that. When we write them, we don't always take that into account, but that's the system that we're working in. So that can be something as simple as marking somewhere that you have sent that email so that you don't resend it if that job ever re-executes. +I think that goes to your point about idempotency earlier that you often want to write code that can get executed multiple times but doesn't necessarily do the action multiple times. It will do it at most once. And that's probably an interesting distinction to have is knowing what elements of your code need to execute at most once, versus as many times as the code is called, versus things that might get tried and then rolled back like a database transaction. And so then that will...I guess you could say it's at most once because you're writing it but unwriting it. But that plays out a little bit differently than something like an email where you can't undo sending an email outside of Gmail. +STEPHANIE: Yeah, I love that undo button. [laughs] +JOËL: You need some other mechanisms for that. +STEPHANIE: Yeah. As you were talking about that, I was also thinking about the idea of failing gracefully, which I think also ties into the idea of recoverable. So this is not a development-specific example. But the idea of an escalator no longer working well; at least you can use it as stairs. So that doesn't mean that everything is totally broken and people are unable to get from one floor to another. So maybe if there is a network request that's touching data and that fails, you can at least fall back on something that's cached. That mindset, I think, really is important to think about at all the different levels we are talking about. +JOËL: Yeah, or hopefully, even maybe some amount of graceful degradation. On a front-end app, you might not want to just crash the whole thing if one background request failed. So you can try again. You can be told, okay, try again in so much time. Maybe we automatically retry to make that same request with some sort of exponential backoff strategy. Or maybe we say, "Look, search is down for now. Here's a link if you want to go check a status page. Until then, other parts of the site are still working." +I feel like we're getting back into what makes great product design and how great product designers have to make failure conditions. It has to be at the forefront of the thinking that comes to designing that product. +STEPHANIE: Yeah, that's a good point. I think my initial feelings of being overwhelmed and stressed about dealing with errors may be because a lot of it falls on the developer if those things aren't accounted for. And we spoke a little bit earlier about, okay, what is within our realm or domain of actually being responsible for, and what can we loop in others for help with? +JOËL: So we've been talking a lot about different ways of preventing errors, different ways of recovering, generally trying to make the whole experience really smooth. A slightly different philosophy around errors is rather than preventing them early is to fail early, like, fail early and loudly. And maybe you recover, maybe you don't. That depends on the context. But instead of putting so much effort into preventing errors upfront, it's better to just crash a lot or to fail loudly and deal with the consequences, or have a strategy for dealing with failure because failure is inevitable. How do you feel about that philosophy? +STEPHANIE: Oh, I think it has a time and a place. One example I'm thinking of is if you don't want your application to be deployed if some configuration is not exactly how it needs to be for the app to run effectively. And so there is a matter of, like, okay, I really want to make sure that the DevOps team or the development team knows that something is very wrong because if this were to be deployed, the app would be unusable. And so that's an example to me of failing loudly but, ideally, not letting it affect end users because they're still using [laughs] the site on a different version. [laughs] +JOËL: Right. I guess the classic example of that is for a Rails app, doing a Hash#fetch() on the environment to load up your environment variables instead of using the square bracket syntax so that as the app is booting and executing those initializers, it will crash if it encounters one of those and then fail to deploy if you're doing a deploy via something like Heroku. I've even sometimes when I'm adding environment variables, purposefully had them loaded in an initializer rather than maybe like in a class later on, specifically so that it would crash the app and prevent deployment if that environment variable was not set. +STEPHANIE: Yeah, that's what I was thinking too, environment variables. Though I think even with that kind of mindset, you're either just delegating that responsibility to someone else down the line to either figure out how to accommodate or account for in a graceful manner. Or you are creating an environment where everyone is very stressed out [laughs] and having to fight fires. So I think it also requires a little bit of thought and isn't necessarily a strategy to just completely embody. [laughs] +JOËL: I've noticed that bugs and errors often accumulate at the boundaries of systems or even subsystems or modules within a program. Maybe the place to apply the strategy of failing early and loudly is particularly valuable at those boundaries. But internally, within a subsystem or a module, maybe it's nicer to use other strategies for error handling. Does that sound like maybe a useful distinction to you? +STEPHANIE: Yeah, I think subsystems was the keyword to me there because you don't want it to be such a catastrophe that it affects the usability of the app entirely. But that does still require some systems in place, I think, to respond to when that thing is failing loudly. +JOËL: I think an example that came to mind for me is like you were mentioning earlier, a full-stack application. And if you've got the back end that's providing an API and something is wrong, I don't want that API to give me back garbage data and try to pretend that everything's okay. Let that API give me back some kind of error code. And I in the front end, I already know that the network is inherently unreliable. I'm planning to handle errors at that point. So it's fine for the API back end to fail loudly in this case. In fact, I think that's the optimal solution. +STEPHANIE: Yeah, I think that's true because ideally, that error clues you into what kind of thing failed, and then maybe you can use that information more meaningfully than trying to guess at what happened with this bad data and then having to define some kind of error message in your app when ideally someone else who had more knowledge about it could have told you what went wrong. +JOËL: And I guess the problem with not failing loudly or with an explicit failure is that if you try to just pass on some sort of value that will pretend to be like what you initially asked for, whoever's consuming that doesn't know that something went wrong. So then you use this garbage data, and you do some things and pass it along to the next person. And eventually, it may cause a failure three or four steps down the line. +And now, trying to trace that, like, why did this fail? And it's not because something was wrong in Module D, or C, or B. It all comes back to oh, A had a problem but didn't crash or give us an error. It tried to pass its sort of best guess, like, this is probably okay. And then it just kind of moved all the way down the line. +STEPHANIE: I'm imagining external API developers everywhere just nodding their heads in agreement. [laughs] +JOËL: I've fought this on a local level as well. I was working on some kind of code for a JavaScript date picker plugin, and this was back in the jQuery days. It was some kind of...it was not a date picker. I think it was a typeahead drop-down thing. In some situations, I forget exactly how it would happen, but the input from there might be empty, but then that would get converted into an undefined value, which then JavaScript would convert to the string undefined, which would then get passed to something else that if it saw a string, it thought that was the thing that the user typed, and they would pass it through. +And I think maybe in the end, I was looking at a crash ten functions away in the front-end code that had to deal with the input from this typeahead and being like, why am I getting these undefined? Or maybe it was a string NaN or something like that. Like, why am I dealing with these weird strings that should never have come out of this? And it turned out it was just kind of an edge case. It wasn't addressed in this component further on, and then it was kind of leaking strings that everybody else thought was sensible up until three or four jumps further down the stack. +STEPHANIE: Yeah, that's a great point. I think it does go back to the idea of there being preventable errors. And then there are things that are truly not preventable because we live in a physical world [laughs] where computers talk to each other over the wire. And that distinction is, you know, perhaps the first being avoidable errors by writing resilient code. And the second being like, okay, in reality, there will be things that go wrong, and this is what we really have to watch out for. +On that note, shall we wrap up? +JOËL: Let's wrap up. [laughs] +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël is a mentor for RailsConf and got matched with a speaker. Stephanie has been having trouble stepping away from her work. It's frustrating when chasing down a bug because something's gone wrong, and you spend a whole afternoon figuring out where it is. Joël and Stephanie discuss error handling as a possible solution.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 recently, RailsConf has closed out their CFP, and they've started sending out acceptances and rejections for proposals. And one thing that they do that I think is really nice is that they offer first-time speakers the ability to get matched with a speaker-mentor, somebody else who has given talks before that can help them prep their talk, listen to them rehearse, that kind of thing. And so they had put out a call for mentors last week. I responded to that, and I got matched with a speaker today.

+ +

STEPHANIE: Cool. Is this your first time being a speaker-mentor?

+ +

JOËL: First time for RailsConf. I've done it for another conference before.

+ +

STEPHANIE: That's really exciting. What do you like about playing that role?

+ +

JOËL: So I very much like prepping and giving talks myself. And I really value if there's something that I'm excited about sharing it, helping others build up that skill as well. So I think it's a great opportunity. I also remember what it was like when I was a first-time speaker and just how very nervous I was and not sure.

+ +

So I think having someone who can play that role is an opportunity to have a really powerful impact in what's oftentimes, I want to say, a monumental moment. But it's kind of like a milestone marker moment in someone's career, the first time I gave a talk at a conference. So you get to help them to make that moment the best it can be.

+ +

STEPHANIE: I love that, yeah. You make a really great point that after you've been speaking for a while, you maybe might forget what it felt like to give your first talk and how big of a deal it is. And in general, I think one thing I really love about Ruby Central conferences is how supportive they are of first-time speakers. So even in the CFP, they mentioned that they welcome first-time speakers and want to make sure to accept talks from those folks and then provide them support through this mentor program. And yeah, it just makes me feel really happy.

+ +

JOËL: Do you remember your first talk?

+ +

STEPHANIE: I do. So my very first talk I gave virtually at RubyConf in 2021. And then last year was actually my first in-person talk. And I remember even though it was technically my second talk; it was really my first talk in front of an audience. And I saw speakers in the Slack workspace asking questions about the AV setup, and I didn't even think to consider that in my preparation. So it was nice. Even though I didn't get set up with a mentor, to share a space with other experienced speakers and see what kinds of things they were asking about or what kinds of things they were sharing in that Slack space was helpful for me.

+ +

JOËL: So when you do a proposal, do you typically have an outline already built out, or is it mostly a concept that you're pitching, and then you maybe start with an outline? Or where do you go next after a proposal has been accepted?

+ +

STEPHANIE: That's a great question. I think first, I procrastinate for several months, [laughs], but I do try to write an outline in the proposal when I submit it so I do have a starting point. And I think that actually helps the CFP committee, too, when they are evaluating proposals to kind of get a better idea of what the talk will be about. And so, in my ideal world, I already have some structure, so by the time I've procrastinated to the point where it's a month or so before the conference itself, [laughs] I have an outline.

+ +

And I end up writing words, like, I will just write my talk as if it were an essay with this bullet point outline already. And I find that helpful for me because I definitely have a bit of a stream-of-consciousness productivity energy. And so if I just put it all out there, I will then go back and be very ruthless, I suppose, in my editing, and I think that's where the magic happens.

+ +

So I kind of let myself just word vomit all over the page. And then the real work comes in the editing process and organizing and making sure it sounds the way I would want it to sound when I'm speaking. And yeah, that's how it has worked for me so far.

+ +

JOËL: So you have a sort of a separate phase for sort of just stream of consciousness dumping and then separately editing. And having those two separate is an important part of your process.

+ +

STEPHANIE: Yeah, I think so. I don't do as well trying to imagine the structure and everything perfectly the first time around and then filling things in. I find that just putting everything out there and, you know, a lot of things get cut. But that works well for me. What about you? What is your typical conference talk writing process?

+ +

JOËL: I think mine is a little bit more iterative. I tend to put in some pieces that I like and then try to connect them together, try to make sure it's telling a story. I think a lot about the pedagogical side of things, where people are going to be confused, where they're going to have questions, where they might check out.

+ +

And then very early, start doing kind of draft rehearsals where I'm starting to work on the talk. And I will stop halfway through because, in my mind, I'm trying to seat myself in the audience and be a person who's listening. And there might be a moment where I'm like, wait a minute, you just jump from one thing to another, and I don't get the logical connection here. And I might pause right there in the rehearsal and add in, say, okay, we need a transitional point, or we need to explain a concept between these two.

+ +

And I keep doing that until I can get through the whole thing and then realize it's way too long and start cutting. And I cut aggressively, and now it's too short. And now I go through it again. And again, people have questions in the audience, hypothetical audience; I am the audience. And so I really kind of inflate it and then cut it down and re-inflate it and cut it down a bunch of times until I'm happy.

+ +

STEPHANIE: I like that a lot. That sounds right. That sounds very you to work even on a conference talk iteratively.

+ +

JOËL: It's very time-consuming. So I don't know it's the most efficient way to build a talk, but it's a process that works for me.

+ +

STEPHANIE: Yeah, that's true. And then there's value in the journey, even if the talk ends up changing from the very beginning to the end product.

+ +

JOËL: So the approach that you described for yourself, I think, where you have a rough draft, and you're separating the editing from almost like a creative process, reminds me a lot of an article that I read called "Mise en Place Writing" by...I'm not sure what their full name is. They go by the handle Swyx. This is an article about their process for writing, but I think it applies to conference talks as well. Have you seen this article?

+ +

STEPHANIE: I haven't. But that, I think, is similar to how I've thought about it or I've seen or heard other authors talk about their writing process and it being kind of similar where the creative work...they give themselves a lot of grace and just letting it be. And then the, like I mentioned, real work is in the editing process. It's kind of two different mindsets, I think.

+ +

JOËL: We'll link the article in the show notes.

+ +

STEPHANIE: I'm curious then how you incorporate visuals into your process because I think that's where my workflow is a little less successful because I'm not really thinking about visuals along with the words, and they do feel more like an afterthought. And I've always been really impressed when people who give talks can have a really visual and dynamic slide presentation. How does that work for you?

+ +

JOËL: So I think I try to avoid slides that are three bullet points in the slide, and then I'm going to talk about it for three or four minutes for each bullet point. People read those quickly and then check out. I'll oftentimes try to have, like, turn each of those bullet points into a full-on slide. And maybe it's just a title and a fun picture or something like that. What this ends up doing is I kind of really inflate my slide deck. I'm going through maybe 80 or 100 slides in a 30-minute presentation.

+ +

So it's multiple slides a minute. They move by really quickly. So I usually have either just an image or a header. I will usually start by just sketching it out with headers and then, where it makes sense, using an image. An image can be just for fun, or it can be something like a diagram where it is trying to illustrate a point.

+ +

STEPHANIE: Yeah, I like that. I think talks with a lot of slides that are mostly just images or something that you can grasp in a few seconds are really engaging because you're keeping it moving, and you don't really let people get bored. And so you show a new slide, and they look at it, but then they are able to direct their attention back to what you're saying.

+ +

JOËL: It's fun too with images because you can reuse them, and then they become a way to connect people back to a theme or let them know that you're making the same point again. A lot of talks, I will have a central theme that gets repeated. I'll often have a slide with some fun image with my key point on it. And then that slide will show up three or four times in my presentation oftentimes because each of the main points I'm trying to make kind of culminates at that same takeaway.

+ +

And so for example, in the talk I gave at RubyConf Mini last fall, I had a slide about writing Ruby code being delightful. I think having some children being happy with just a big title being like, "Oh, delightful," or something like that. And after each of my examples where we went from code that was less good to something that was more idiomatic, Ruby that was really fun to work with, I would finish on that slide and be like, hey, our code is now delightful.

+ +

And hopefully, that helped people with the takeaway of, like, we want to write delightful code. Ruby has tools to do that. And then, hopefully, they either remember the things they can do to get to that point or can look it up and find a talk online.

+ +

STEPHANIE: Yeah, I watched that talk, and I really vividly remember that slide and the theme that you were trying to hone in on. So I thought it was pretty effective. I think this makes me realize speaking, I mean; speaking is obviously a skill but even the process of creating a talk in that particular medium is also a vast skill and can go...there are so many different styles and flavors. But I really think that what you said will get me thinking next time I'm writing my talk and how I can better incorporate that kind of engagement with the audience and making sure that the way I deliver the talk is just as thoughtful as the content itself.

+ +

JOËL: Yeah, I've been putting a lot of thought into what makes a good talk and what elements are unique to my process, what elements can be useful to others because now I have to coach someone else on their process and say, "Hey, here's the thing that worked for me. Maybe this will be helpful for you." Or maybe it's just, "Have you tried this?" Or "I think audiences will be asking this question at this moment, what do you think of this?" So that's definitely been top of mind in a whole other dimension for me recently. How about you? What's new in your world?

+ +

STEPHANIE: So before we started recording, I was heads down deep in the muck of trying to write some tests, some RSpec tests on my client project. And the domain for this client project is really big. There are a lot of models. And I was starting to go deep into the factory setups for our test fixtures. And it was hairy. And I was just going further and further down the rabbit hole to the point where I was skipping lunch.

+ +

JOËL: Ooooh.

+ +

STEPHANIE: Yeah, I was like, I couldn't pull myself away from it, and I kind of regret it a little bit. [laughs] And so I was just thinking about, like, how can I incorporate taking breaks a little bit more and feeling better about stepping away from the work when I'm really deep in it? You and I had this standing appointment to record [laughs] a podcast, so that was kind of the signal to me that it was time to try to set it aside.

+ +

And I did end up taking the dog for a walk around the block beforehand to get some fresh air, but yeah, it was a little rough, I don't know. How do you deal with just being so deep in the code that you don't really want to resurface?

+ +

JOËL: That's hard because sometimes I'm feeling productive, and I don't want to stop because I feel like I might not get back into the flow quite as easily. Sometimes it's just out of frustration. It's like, oh, I'm just so close to getting this bug done. If I get this one more test to pass, then I'll be good. And I keep doing one more thing. And the next thing I know, I have skipped lunch, and it's late in the afternoon. And it's just like; it's been a frustrating day.

+ +

STEPHANIE: And you're cranky, yeah, yep. I know that feeling.

+ +

JOËL: I've stopped being productive for the past hour. But I'll be like, one more thing, one more thing.

+ +

STEPHANIE: I think I was in that place because I was starting to get deep into the internals of models completely unrelated to the test that I was writing, but that was just where the rabbit hole led me. And I think after this, I will go and ask in Slack for a pair because I think that would be really helpful right now. I've just reached the limits of what I know. And I'm almost positive that someone knows how to do this more efficiently than I do. So that was a bit of a signal to me, but it was very challenging untangling myself out of that headspace.

+ +

JOËL: Have you ever played the video game Civilization?

+ +

STEPHANIE: No, I haven't.

+ +

JOËL: It's a turn-based historical strategy game. The running joke about it is that people get really pulled into it. And they're always just saying, "I'm going to play one more turn, and then I'm going to be done for the evening." And the next thing you know, it's 4:00 a.m. And I think that sometimes applies to fixing one more failure, just getting one more file in that chain of figuring out what the bug is in code. It's a very similar feeling.

+ +

STEPHANIE: Yeah, I know exactly what you're talking about.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So it can be really frustrating when you're kind of chasing down a bug because something's gone wrong, and now you're spending a whole afternoon figuring out where it is. Do you ever find yourself maybe acting preemptively to try to prevent those sorts of things from happening in the first place? So maybe putting in some sort of guards or error handling or something like that so that your future self won't have to spend that afternoon.

+ +

STEPHANIE: That's a great point because the bug that I was facing just now was definitely something I think could have been avoided. It was a classic no method [laughs] on nil class error. And I am still unsure how that happened, and I hope to come back to it after this. But yeah, that certainly is a great topic to get into, error handling. I think it's been on my mind a little bit lately because I'm working on a full-stack feature that has user-facing errors and things we want to make sure that we communicate to the user so that they could hopefully do something about it or just contact customer support on this app.

+ +

But there are also some API calls that are kicked off in the process of the user submitting the form, and those can lead to a bunch of different failures. And we may or may not have already discovered what those failures could be, and there may or may not have been designs created for those different failure states. And I feel like I haven't quite gotten a handle on how to deal with all of the possible errors that can happen when implementing a full-stack feature or a vertical slice. Yeah, that has tripped me up a lot lately.

+ +

JOËL: I think my time working in Elm has really made me much more aware of the different ways that things can fail just because Elm's type system is very robust. It's very complete. And so it will point out to you every potential place that could have a failure and ask you to handle it because it doesn't want to get to a point where it doesn't know what to do and there's a runtime error for something like no method or something like that.

+ +

So if you've got a potential nullable value and you're trying to say, okay, take this and render it, the compiler will say, wait a minute, you did not handle the null case. Give me something to do with the null case, or I refuse to compile. And now you've got to handle that. If there's something that might feel like an HTTP request, again, the compiler would be like, well, but what about the failure case? You didn't tell me what to do on the failure case. This is an incomplete piece of code. I refuse to compile that.

+ +

So I think I've built now a little bit of anticipation because I know the compiler is going to tell me to do this. Now even when I write code that's not compiled like Ruby, my brain compiler is still like, oh, there's a nullable value here. You didn't check the null case. What are you going to do about that?

+ +

STEPHANIE: Yeah, that's a great point. I think the more experience I gain, the more possible errors I see in the world or out in the wild. When I think about developing on the web, you know, you mentioned HTTP requests, but also, if we fail to connect to the database or a job fails to enqueue, there are just so many places where things can go wrong. And it's almost like the more I learn about all those possible failures, the more anxious I am [laughs] to make sure that I've covered everything though I think there is some amount of just that being impossible.

+ +

And I'm particularly interested in figuring out what is enough because one thing that really I find quite painful is when you don't think through things enough and you just cross your fingers and hope it works and you ship it, and then your team is dealing with a lot of bugs or a lot of noisy error monitoring notifications afterwards. And so that's kind of what I'm trying to adjust for, I think.

+ +

JOËL: I think there's like two general classes of approach you can use to deal with that; one is to try to prevent errors altogether, and there's a variety of tools you could use for that. I'm thinking of either something like a type system or maybe test-driven development or even some sort of analysis tool. That could be diagramming, that could be decision tables, something like that. All those, I think, fall under better understanding of the edges of your system. Whereas sometimes you want to do the opposite and sort of really lean into, okay, errors will happen. How do we recover from them? How do we make them easy to diagnose in the future?

+ +

STEPHANIE: Yeah, that second bit is really interesting to me because I've started to try to think about the errors and who we want to notify about the errors. And so I feel like there are a few different categories of errors where if it's a validation error and it's something that the user can fix, you know, that we want to make sure to surface and tell them how they can fix it. If it's like a programming error, there's no value in showing that to the user.

+ +

And I'm sure that we've all seen a website that responded with a 500, but then we actually saw the error message itself, and we're like, ooh, this is kind of weird [laughs] to be seeing this. And so realizing, okay, that's not valuable to the user. But what should I be doing with it instead? And maybe that is hooking it up to whatever error monitoring service you use to make sure someone is alerted. Or, I don't know, even in the third case, like, what should a customer support team be notified about? And that kind of sits in between not quite a user-facing error but also not a bug, and that's a different category.

+ +

JOËL: So, something that is not necessarily a problem in the code, but you might want somebody in the company to know about and be notified about.

+ +

STEPHANIE: Yeah, exactly. Maybe not something that is so urgent that it needs to be flagged in real-time but goes somewhere, and someone will check on it at some point. [laughs] So you were mentioning that you now have a better sense of what could go wrong. How much time do you spend writing code to cover all of those different possibilities?

+ +

JOËL: Hmm, I don't know that I've ever put the time to quantify it. I would say a decent amount because you've got to think about...sometimes they're not even things that can go wrong per se. But they're off that very simple, linear happy path that you're thinking of. So you might think even for rendering some kind of view, and you've got some search results you're trying to display.

+ +

Have you considered an empty state? Is there a difference between initially loading the page or have not performed a search yet, and search but did not find any results? Those are things that are not necessarily errors, but they're not things you're thinking in mind when you're just writing that first happy path of, like, oh, load page, show results. I assume there's always a result set. And so those are things that are important for the user experience that you need to have, but that are kind of edge cases that you have to add in afterwards, or you have to think about.

+ +

And so I think that, for me, tends to fall under a similar category as okay; what if an error happened? Especially when you're dealing with kind of a full-stack situation where on the front end maybe you're making a result to a back end to pull down...let's say you're making a search and the back end is doing the actual search. You send up a query. Now you get back a failure.

+ +

Is that the same thing as getting no results back? Like, a success with no results, versus an error code, versus not making a query yet. So you've got like four or five states you've got to think about on the front end to display and how you're going to handle those. So I think thinking about those upfront is often really helpful.

+ +

STEPHANIE: As you were talking about that, I suppose I asked the question because I have experienced when those things are not thought about upfront, and then you discover them as you're implementing. And how much time do you use to kind of go into a little detouring trying to make sure that you have all of the edge cases covered, and at what point do you stop? Because you're like, I've covered what I can. And this ticket was supposed to only be three points [laughs] or whatever, you know.

+ +

JOËL: Yeah. And how do you keep a feature from ballooning when there are all these edge cases?

+ +

STEPHANIE: Yeah, exactly. It's a balance.

+ +

JOËL: Are there any techniques that you like to do when you...so you pick up a ticket that looks easy, but that might have a lot of these hidden edge cases in it. Are there techniques you like to use that might help you figure out those edge cases and maybe give you some follow-up questions that you might reach out to the product person to clarify? Or maybe it's mostly intuition and experience as a developer that you kind of figure out that, oh, these are the things we need to ask about. It's like, have you thought about an error state?

+ +

STEPHANIE: Yeah, that's a good question. In general, I'm a little suspicious of any ticket that doesn't include some kind of acceptance criteria about the unhappy path. And I certainly think it's a lot easier once you are embedded into this domain, and you have that expertise, and you are able to see the possible issues you'll run into. I do think that I like to do a little bit of coding just to kind of explore the space, and then that does give me more insight into how I might be able to follow up on the ticket.

+ +

So you mentioned techniques. Especially if they're written as user stories, I don't think they necessarily incorporate the flow or the procedure of how things are kicked off. And so when you're thinking about implementing it, you're like, oh, this actually needs to happen in the background, or this should be synchronous or not. And those are a lot of error states that I find are missing when I pick up a ticket.

+ +

And I think it also depends on which way you want to implement it what implementation is viable. And then maybe you bring it to a product person, and they are actually like, "No, we don't want it to work like that." And then you have to kind of rethink things a little bit. But yeah, certainly, the process of taking a user story and then doing an initial think-through of what approach you want to take definitely surfaces some potential unhappy paths.

+ +

JOËL: It's almost like prototyping it in your mind.

+ +

STEPHANIE: Yeah, I think so. I think it also depends a little bit on the team because if the engineer wrote the ticket, then there likely has been some thought about unhappy paths. But on other teams that I've been on when implementation is up to the person who picked it up rather than kind of spelled out for you by someone else who did that thinking, that's definitely an opportunity to pause, I think, and document which way you might want to go so that you can make sure that you account for the possible things that could go wrong that likely the user story didn't cover.

+ +

JOËL: Sometimes there are some edge cases or failure states that are just sort of built into the problem that you're solving. If you're having to make a background request, there's always a chance that that might fail because the network is not trustworthy. Sometimes though, those things just kind of come out of our implementation, the fact that we implemented it in a particular way.

+ +

And that's not something that you'd expect a product person to have to think about. That's more on us as developers to be like, oh yeah, well, I'm indexing into a hash and didn't think to check is a nested hash even present? Maybe that key isn't there. And now I've got a weird nil error, an undefined method. That's kind of on us rather than on, like, oh, a specific kind of thing that we can think about upfront.

+ +

STEPHANIE: Yeah, that's fair. And I think that is just an important part of the development process. Though you make a good point because I think that just kind of speaks to all of the different layers of things that can go wrong [laughs] and figuring out which ones are specific to your role as developer to account for, and then which are ones that you need to bring in or pull in a designer to chat about. It can be a little overwhelming. I'm overwhelmed just thinking about it.

+ +

[laughter]

+ +

JOËL: Yeah, errors are not a sort of monolithic class of things. They can't be an afterthought. But they're also not just a thing where it's like, oh yeah, do the error handling, and then you're good. We kind of lump a lot of things under the concept of errors, even if they might all eventually manifest as some kind of exception. I guess a true solution is just one giant top-level rescue nil.

+ +

STEPHANIE: [laughs] Very funny.

+ +

JOËL: So we've talked about a few different dimensions of errors where they might be sort of user-visible or not, or something that's more implementation-based versus inherent to the problem. One thing that we haven't looked at is the dimension of errors that might be recoverable versus not. Have you ever built a system where you had errors that could be recovered from and didn't crash the program?

+ +

STEPHANIE: Ooh, yes. That makes me think about retrying and especially what you're saying if things are happening in the background. Maybe there is an ephemeral error where the network timed out or something. But if it is given another shot, it might succeed on the second go. And I think there's a whole process of thinking about what happens when a process has to be retried and if there were any side effects that you didn't want to have committed the first time around, you know, but then something else that was supposed to happen and when the process happens again, things are very broken. So making sure that you are keeping things idempotent so that by undoing it again, there are not any unforeseen issues.

+ +

JOËL: I heard you say that word commit here, and that's kind of a keyword to my mind. I immediately think database transactions. Is that the sense that you're thinking about this term here? Or does it have another meaning for you in this context?

+ +

STEPHANIE: Yeah. I do think I used that word specifically because when I've run into this in the past, it has been around making database changes. I'm trying to think if there is another way that this might show up. I think even in something like sending an email, too, though it is a bit lower stakes. I've certainly, as a user, experienced when that goes wrong and just been [laughs] flooded with emails and being like, wow, this is annoying. And that's, I think, something valid to consider as well.

+ +

JOËL: Yeah. You don't want that email job to be a thing that gets retried and just keeps failing because there's a nil error after the email gets sent. And so we just re-enqueue it, re-enqueue it, re-enqueue it, and the person ends up receiving 500 emails.

+ +

STEPHANIE: What about you? Any thoughts about recoverable errors?

+ +

JOËL: Yeah. I think really common for me is thinking about that in the context of a background job because those are things that I think are specifically designed to be retried if they fail; at least, a lot of job enqueuing systems assume that. When we write them, we don't always take that into account, but that's the system that we're working in. So that can be something as simple as marking somewhere that you have sent that email so that you don't resend it if that job ever re-executes.

+ +

I think that goes to your point about idempotency earlier that you often want to write code that can get executed multiple times but doesn't necessarily do the action multiple times. It will do it at most once. And that's probably an interesting distinction to have is knowing what elements of your code need to execute at most once, versus as many times as the code is called, versus things that might get tried and then rolled back like a database transaction. And so then that will...I guess you could say it's at most once because you're writing it but unwriting it. But that plays out a little bit differently than something like an email where you can't undo sending an email outside of Gmail.

+ +

STEPHANIE: Yeah, I love that undo button. [laughs]

+ +

JOËL: You need some other mechanisms for that.

+ +

STEPHANIE: Yeah. As you were talking about that, I was also thinking about the idea of failing gracefully, which I think also ties into the idea of recoverable. So this is not a development-specific example. But the idea of an escalator no longer working well; at least you can use it as stairs. So that doesn't mean that everything is totally broken and people are unable to get from one floor to another. So maybe if there is a network request that's touching data and that fails, you can at least fall back on something that's cached. That mindset, I think, really is important to think about at all the different levels we are talking about.

+ +

JOËL: Yeah, or hopefully, even maybe some amount of graceful degradation. On a front-end app, you might not want to just crash the whole thing if one background request failed. So you can try again. You can be told, okay, try again in so much time. Maybe we automatically retry to make that same request with some sort of exponential backoff strategy. Or maybe we say, "Look, search is down for now. Here's a link if you want to go check a status page. Until then, other parts of the site are still working."

+ +

I feel like we're getting back into what makes great product design and how great product designers have to make failure conditions. It has to be at the forefront of the thinking that comes to designing that product.

+ +

STEPHANIE: Yeah, that's a good point. I think my initial feelings of being overwhelmed and stressed about dealing with errors may be because a lot of it falls on the developer if those things aren't accounted for. And we spoke a little bit earlier about, okay, what is within our realm or domain of actually being responsible for, and what can we loop in others for help with?

+ +

JOËL: So we've been talking a lot about different ways of preventing errors, different ways of recovering, generally trying to make the whole experience really smooth. A slightly different philosophy around errors is rather than preventing them early is to fail early, like, fail early and loudly. And maybe you recover, maybe you don't. That depends on the context. But instead of putting so much effort into preventing errors upfront, it's better to just crash a lot or to fail loudly and deal with the consequences, or have a strategy for dealing with failure because failure is inevitable. How do you feel about that philosophy?

+ +

STEPHANIE: Oh, I think it has a time and a place. One example I'm thinking of is if you don't want your application to be deployed if some configuration is not exactly how it needs to be for the app to run effectively. And so there is a matter of, like, okay, I really want to make sure that the DevOps team or the development team knows that something is very wrong because if this were to be deployed, the app would be unusable. And so that's an example to me of failing loudly but, ideally, not letting it affect end users because they're still using [laughs] the site on a different version. [laughs]

+ +

JOËL: Right. I guess the classic example of that is for a Rails app, doing a Hash#fetch() on the environment to load up your environment variables instead of using the square bracket syntax so that as the app is booting and executing those initializers, it will crash if it encounters one of those and then fail to deploy if you're doing a deploy via something like Heroku. I've even sometimes when I'm adding environment variables, purposefully had them loaded in an initializer rather than maybe like in a class later on, specifically so that it would crash the app and prevent deployment if that environment variable was not set.

+ +

STEPHANIE: Yeah, that's what I was thinking too, environment variables. Though I think even with that kind of mindset, you're either just delegating that responsibility to someone else down the line to either figure out how to accommodate or account for in a graceful manner. Or you are creating an environment where everyone is very stressed out [laughs] and having to fight fires. So I think it also requires a little bit of thought and isn't necessarily a strategy to just completely embody. [laughs]

+ +

JOËL: I've noticed that bugs and errors often accumulate at the boundaries of systems or even subsystems or modules within a program. Maybe the place to apply the strategy of failing early and loudly is particularly valuable at those boundaries. But internally, within a subsystem or a module, maybe it's nicer to use other strategies for error handling. Does that sound like maybe a useful distinction to you?

+ +

STEPHANIE: Yeah, I think subsystems was the keyword to me there because you don't want it to be such a catastrophe that it affects the usability of the app entirely. But that does still require some systems in place, I think, to respond to when that thing is failing loudly.

+ +

JOËL: I think an example that came to mind for me is like you were mentioning earlier, a full-stack application. And if you've got the back end that's providing an API and something is wrong, I don't want that API to give me back garbage data and try to pretend that everything's okay. Let that API give me back some kind of error code. And I in the front end, I already know that the network is inherently unreliable. I'm planning to handle errors at that point. So it's fine for the API back end to fail loudly in this case. In fact, I think that's the optimal solution.

+ +

STEPHANIE: Yeah, I think that's true because ideally, that error clues you into what kind of thing failed, and then maybe you can use that information more meaningfully than trying to guess at what happened with this bad data and then having to define some kind of error message in your app when ideally someone else who had more knowledge about it could have told you what went wrong.

+ +

JOËL: And I guess the problem with not failing loudly or with an explicit failure is that if you try to just pass on some sort of value that will pretend to be like what you initially asked for, whoever's consuming that doesn't know that something went wrong. So then you use this garbage data, and you do some things and pass it along to the next person. And eventually, it may cause a failure three or four steps down the line.

+ +

And now, trying to trace that, like, why did this fail? And it's not because something was wrong in Module D, or C, or B. It all comes back to oh, A had a problem but didn't crash or give us an error. It tried to pass its sort of best guess, like, this is probably okay. And then it just kind of moved all the way down the line.

+ +

STEPHANIE: I'm imagining external API developers everywhere just nodding their heads in agreement. [laughs]

+ +

JOËL: I've fought this on a local level as well. I was working on some kind of code for a JavaScript date picker plugin, and this was back in the jQuery days. It was some kind of...it was not a date picker. I think it was a typeahead drop-down thing. In some situations, I forget exactly how it would happen, but the input from there might be empty, but then that would get converted into an undefined value, which then JavaScript would convert to the string undefined, which would then get passed to something else that if it saw a string, it thought that was the thing that the user typed, and they would pass it through.

+ +

And I think maybe in the end, I was looking at a crash ten functions away in the front-end code that had to deal with the input from this typeahead and being like, why am I getting these undefined? Or maybe it was a string NaN or something like that. Like, why am I dealing with these weird strings that should never have come out of this? And it turned out it was just kind of an edge case. It wasn't addressed in this component further on, and then it was kind of leaking strings that everybody else thought was sensible up until three or four jumps further down the stack.

+ +

STEPHANIE: Yeah, that's a great point. I think it does go back to the idea of there being preventable errors. And then there are things that are truly not preventable because we live in a physical world [laughs] where computers talk to each other over the wire. And that distinction is, you know, perhaps the first being avoidable errors by writing resilient code. And the second being like, okay, in reality, there will be things that go wrong, and this is what we really have to watch out for.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. [laughs]

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël is a mentor for RailsConf and got matched with a speaker. Stephanie has been having trouble stepping away from her work. It's frustrating when chasing down a bug because something's gone wrong, and you spend a whole afternoon figuring out where it is. Joël and Stephanie discuss error handling as a possible solution.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 recently, RailsConf has closed out their CFP, and they've started sending out acceptances and rejections for proposals. And one thing that they do that I think is really nice is that they offer first-time speakers the ability to get matched with a speaker-mentor, somebody else who has given talks before that can help them prep their talk, listen to them rehearse, that kind of thing. And so they had put out a call for mentors last week. I responded to that, and I got matched with a speaker today.

+ +

STEPHANIE: Cool. Is this your first time being a speaker-mentor?

+ +

JOËL: First time for RailsConf. I've done it for another conference before.

+ +

STEPHANIE: That's really exciting. What do you like about playing that role?

+ +

JOËL: So I very much like prepping and giving talks myself. And I really value if there's something that I'm excited about sharing it, helping others build up that skill as well. So I think it's a great opportunity. I also remember what it was like when I was a first-time speaker and just how very nervous I was and not sure.

+ +

So I think having someone who can play that role is an opportunity to have a really powerful impact in what's oftentimes, I want to say, a monumental moment. But it's kind of like a milestone marker moment in someone's career, the first time I gave a talk at a conference. So you get to help them to make that moment the best it can be.

+ +

STEPHANIE: I love that, yeah. You make a really great point that after you've been speaking for a while, you maybe might forget what it felt like to give your first talk and how big of a deal it is. And in general, I think one thing I really love about Ruby Central conferences is how supportive they are of first-time speakers. So even in the CFP, they mentioned that they welcome first-time speakers and want to make sure to accept talks from those folks and then provide them support through this mentor program. And yeah, it just makes me feel really happy.

+ +

JOËL: Do you remember your first talk?

+ +

STEPHANIE: I do. So my very first talk I gave virtually at RubyConf in 2021. And then last year was actually my first in-person talk. And I remember even though it was technically my second talk; it was really my first talk in front of an audience. And I saw speakers in the Slack workspace asking questions about the AV setup, and I didn't even think to consider that in my preparation. So it was nice. Even though I didn't get set up with a mentor, to share a space with other experienced speakers and see what kinds of things they were asking about or what kinds of things they were sharing in that Slack space was helpful for me.

+ +

JOËL: So when you do a proposal, do you typically have an outline already built out, or is it mostly a concept that you're pitching, and then you maybe start with an outline? Or where do you go next after a proposal has been accepted?

+ +

STEPHANIE: That's a great question. I think first, I procrastinate for several months, [laughs], but I do try to write an outline in the proposal when I submit it so I do have a starting point. And I think that actually helps the CFP committee, too, when they are evaluating proposals to kind of get a better idea of what the talk will be about. And so, in my ideal world, I already have some structure, so by the time I've procrastinated to the point where it's a month or so before the conference itself, [laughs] I have an outline.

+ +

And I end up writing words, like, I will just write my talk as if it were an essay with this bullet point outline already. And I find that helpful for me because I definitely have a bit of a stream-of-consciousness productivity energy. And so if I just put it all out there, I will then go back and be very ruthless, I suppose, in my editing, and I think that's where the magic happens.

+ +

So I kind of let myself just word vomit all over the page. And then the real work comes in the editing process and organizing and making sure it sounds the way I would want it to sound when I'm speaking. And yeah, that's how it has worked for me so far.

+ +

JOËL: So you have a sort of a separate phase for sort of just stream of consciousness dumping and then separately editing. And having those two separate is an important part of your process.

+ +

STEPHANIE: Yeah, I think so. I don't do as well trying to imagine the structure and everything perfectly the first time around and then filling things in. I find that just putting everything out there and, you know, a lot of things get cut. But that works well for me. What about you? What is your typical conference talk writing process?

+ +

JOËL: I think mine is a little bit more iterative. I tend to put in some pieces that I like and then try to connect them together, try to make sure it's telling a story. I think a lot about the pedagogical side of things, where people are going to be confused, where they're going to have questions, where they might check out.

+ +

And then very early, start doing kind of draft rehearsals where I'm starting to work on the talk. And I will stop halfway through because, in my mind, I'm trying to seat myself in the audience and be a person who's listening. And there might be a moment where I'm like, wait a minute, you just jump from one thing to another, and I don't get the logical connection here. And I might pause right there in the rehearsal and add in, say, okay, we need a transitional point, or we need to explain a concept between these two.

+ +

And I keep doing that until I can get through the whole thing and then realize it's way too long and start cutting. And I cut aggressively, and now it's too short. And now I go through it again. And again, people have questions in the audience, hypothetical audience; I am the audience. And so I really kind of inflate it and then cut it down and re-inflate it and cut it down a bunch of times until I'm happy.

+ +

STEPHANIE: I like that a lot. That sounds right. That sounds very you to work even on a conference talk iteratively.

+ +

JOËL: It's very time-consuming. So I don't know it's the most efficient way to build a talk, but it's a process that works for me.

+ +

STEPHANIE: Yeah, that's true. And then there's value in the journey, even if the talk ends up changing from the very beginning to the end product.

+ +

JOËL: So the approach that you described for yourself, I think, where you have a rough draft, and you're separating the editing from almost like a creative process, reminds me a lot of an article that I read called "Mise en Place Writing" by...I'm not sure what their full name is. They go by the handle Swyx. This is an article about their process for writing, but I think it applies to conference talks as well. Have you seen this article?

+ +

STEPHANIE: I haven't. But that, I think, is similar to how I've thought about it or I've seen or heard other authors talk about their writing process and it being kind of similar where the creative work...they give themselves a lot of grace and just letting it be. And then the, like I mentioned, real work is in the editing process. It's kind of two different mindsets, I think.

+ +

JOËL: We'll link the article in the show notes.

+ +

STEPHANIE: I'm curious then how you incorporate visuals into your process because I think that's where my workflow is a little less successful because I'm not really thinking about visuals along with the words, and they do feel more like an afterthought. And I've always been really impressed when people who give talks can have a really visual and dynamic slide presentation. How does that work for you?

+ +

JOËL: So I think I try to avoid slides that are three bullet points in the slide, and then I'm going to talk about it for three or four minutes for each bullet point. People read those quickly and then check out. I'll oftentimes try to have, like, turn each of those bullet points into a full-on slide. And maybe it's just a title and a fun picture or something like that. What this ends up doing is I kind of really inflate my slide deck. I'm going through maybe 80 or 100 slides in a 30-minute presentation.

+ +

So it's multiple slides a minute. They move by really quickly. So I usually have either just an image or a header. I will usually start by just sketching it out with headers and then, where it makes sense, using an image. An image can be just for fun, or it can be something like a diagram where it is trying to illustrate a point.

+ +

STEPHANIE: Yeah, I like that. I think talks with a lot of slides that are mostly just images or something that you can grasp in a few seconds are really engaging because you're keeping it moving, and you don't really let people get bored. And so you show a new slide, and they look at it, but then they are able to direct their attention back to what you're saying.

+ +

JOËL: It's fun too with images because you can reuse them, and then they become a way to connect people back to a theme or let them know that you're making the same point again. A lot of talks, I will have a central theme that gets repeated. I'll often have a slide with some fun image with my key point on it. And then that slide will show up three or four times in my presentation oftentimes because each of the main points I'm trying to make kind of culminates at that same takeaway.

+ +

And so for example, in the talk I gave at RubyConf Mini last fall, I had a slide about writing Ruby code being delightful. I think having some children being happy with just a big title being like, "Oh, delightful," or something like that. And after each of my examples where we went from code that was less good to something that was more idiomatic, Ruby that was really fun to work with, I would finish on that slide and be like, hey, our code is now delightful.

+ +

And hopefully, that helped people with the takeaway of, like, we want to write delightful code. Ruby has tools to do that. And then, hopefully, they either remember the things they can do to get to that point or can look it up and find a talk online.

+ +

STEPHANIE: Yeah, I watched that talk, and I really vividly remember that slide and the theme that you were trying to hone in on. So I thought it was pretty effective. I think this makes me realize speaking, I mean; speaking is obviously a skill but even the process of creating a talk in that particular medium is also a vast skill and can go...there are so many different styles and flavors. But I really think that what you said will get me thinking next time I'm writing my talk and how I can better incorporate that kind of engagement with the audience and making sure that the way I deliver the talk is just as thoughtful as the content itself.

+ +

JOËL: Yeah, I've been putting a lot of thought into what makes a good talk and what elements are unique to my process, what elements can be useful to others because now I have to coach someone else on their process and say, "Hey, here's the thing that worked for me. Maybe this will be helpful for you." Or maybe it's just, "Have you tried this?" Or "I think audiences will be asking this question at this moment, what do you think of this?" So that's definitely been top of mind in a whole other dimension for me recently. How about you? What's new in your world?

+ +

STEPHANIE: So before we started recording, I was heads down deep in the muck of trying to write some tests, some RSpec tests on my client project. And the domain for this client project is really big. There are a lot of models. And I was starting to go deep into the factory setups for our test fixtures. And it was hairy. And I was just going further and further down the rabbit hole to the point where I was skipping lunch.

+ +

JOËL: Ooooh.

+ +

STEPHANIE: Yeah, I was like, I couldn't pull myself away from it, and I kind of regret it a little bit. [laughs] And so I was just thinking about, like, how can I incorporate taking breaks a little bit more and feeling better about stepping away from the work when I'm really deep in it? You and I had this standing appointment to record [laughs] a podcast, so that was kind of the signal to me that it was time to try to set it aside.

+ +

And I did end up taking the dog for a walk around the block beforehand to get some fresh air, but yeah, it was a little rough, I don't know. How do you deal with just being so deep in the code that you don't really want to resurface?

+ +

JOËL: That's hard because sometimes I'm feeling productive, and I don't want to stop because I feel like I might not get back into the flow quite as easily. Sometimes it's just out of frustration. It's like, oh, I'm just so close to getting this bug done. If I get this one more test to pass, then I'll be good. And I keep doing one more thing. And the next thing I know, I have skipped lunch, and it's late in the afternoon. And it's just like; it's been a frustrating day.

+ +

STEPHANIE: And you're cranky, yeah, yep. I know that feeling.

+ +

JOËL: I've stopped being productive for the past hour. But I'll be like, one more thing, one more thing.

+ +

STEPHANIE: I think I was in that place because I was starting to get deep into the internals of models completely unrelated to the test that I was writing, but that was just where the rabbit hole led me. And I think after this, I will go and ask in Slack for a pair because I think that would be really helpful right now. I've just reached the limits of what I know. And I'm almost positive that someone knows how to do this more efficiently than I do. So that was a bit of a signal to me, but it was very challenging untangling myself out of that headspace.

+ +

JOËL: Have you ever played the video game Civilization?

+ +

STEPHANIE: No, I haven't.

+ +

JOËL: It's a turn-based historical strategy game. The running joke about it is that people get really pulled into it. And they're always just saying, "I'm going to play one more turn, and then I'm going to be done for the evening." And the next thing you know, it's 4:00 a.m. And I think that sometimes applies to fixing one more failure, just getting one more file in that chain of figuring out what the bug is in code. It's a very similar feeling.

+ +

STEPHANIE: Yeah, I know exactly what you're talking about.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So it can be really frustrating when you're kind of chasing down a bug because something's gone wrong, and now you're spending a whole afternoon figuring out where it is. Do you ever find yourself maybe acting preemptively to try to prevent those sorts of things from happening in the first place? So maybe putting in some sort of guards or error handling or something like that so that your future self won't have to spend that afternoon.

+ +

STEPHANIE: That's a great point because the bug that I was facing just now was definitely something I think could have been avoided. It was a classic no method [laughs] on nil class error. And I am still unsure how that happened, and I hope to come back to it after this. But yeah, that certainly is a great topic to get into, error handling. I think it's been on my mind a little bit lately because I'm working on a full-stack feature that has user-facing errors and things we want to make sure that we communicate to the user so that they could hopefully do something about it or just contact customer support on this app.

+ +

But there are also some API calls that are kicked off in the process of the user submitting the form, and those can lead to a bunch of different failures. And we may or may not have already discovered what those failures could be, and there may or may not have been designs created for those different failure states. And I feel like I haven't quite gotten a handle on how to deal with all of the possible errors that can happen when implementing a full-stack feature or a vertical slice. Yeah, that has tripped me up a lot lately.

+ +

JOËL: I think my time working in Elm has really made me much more aware of the different ways that things can fail just because Elm's type system is very robust. It's very complete. And so it will point out to you every potential place that could have a failure and ask you to handle it because it doesn't want to get to a point where it doesn't know what to do and there's a runtime error for something like no method or something like that.

+ +

So if you've got a potential nullable value and you're trying to say, okay, take this and render it, the compiler will say, wait a minute, you did not handle the null case. Give me something to do with the null case, or I refuse to compile. And now you've got to handle that. If there's something that might feel like an HTTP request, again, the compiler would be like, well, but what about the failure case? You didn't tell me what to do on the failure case. This is an incomplete piece of code. I refuse to compile that.

+ +

So I think I've built now a little bit of anticipation because I know the compiler is going to tell me to do this. Now even when I write code that's not compiled like Ruby, my brain compiler is still like, oh, there's a nullable value here. You didn't check the null case. What are you going to do about that?

+ +

STEPHANIE: Yeah, that's a great point. I think the more experience I gain, the more possible errors I see in the world or out in the wild. When I think about developing on the web, you know, you mentioned HTTP requests, but also, if we fail to connect to the database or a job fails to enqueue, there are just so many places where things can go wrong. And it's almost like the more I learn about all those possible failures, the more anxious I am [laughs] to make sure that I've covered everything though I think there is some amount of just that being impossible.

+ +

And I'm particularly interested in figuring out what is enough because one thing that really I find quite painful is when you don't think through things enough and you just cross your fingers and hope it works and you ship it, and then your team is dealing with a lot of bugs or a lot of noisy error monitoring notifications afterwards. And so that's kind of what I'm trying to adjust for, I think.

+ +

JOËL: I think there's like two general classes of approach you can use to deal with that; one is to try to prevent errors altogether, and there's a variety of tools you could use for that. I'm thinking of either something like a type system or maybe test-driven development or even some sort of analysis tool. That could be diagramming, that could be decision tables, something like that. All those, I think, fall under better understanding of the edges of your system. Whereas sometimes you want to do the opposite and sort of really lean into, okay, errors will happen. How do we recover from them? How do we make them easy to diagnose in the future?

+ +

STEPHANIE: Yeah, that second bit is really interesting to me because I've started to try to think about the errors and who we want to notify about the errors. And so I feel like there are a few different categories of errors where if it's a validation error and it's something that the user can fix, you know, that we want to make sure to surface and tell them how they can fix it. If it's like a programming error, there's no value in showing that to the user.

+ +

And I'm sure that we've all seen a website that responded with a 500, but then we actually saw the error message itself, and we're like, ooh, this is kind of weird [laughs] to be seeing this. And so realizing, okay, that's not valuable to the user. But what should I be doing with it instead? And maybe that is hooking it up to whatever error monitoring service you use to make sure someone is alerted. Or, I don't know, even in the third case, like, what should a customer support team be notified about? And that kind of sits in between not quite a user-facing error but also not a bug, and that's a different category.

+ +

JOËL: So, something that is not necessarily a problem in the code, but you might want somebody in the company to know about and be notified about.

+ +

STEPHANIE: Yeah, exactly. Maybe not something that is so urgent that it needs to be flagged in real-time but goes somewhere, and someone will check on it at some point. [laughs] So you were mentioning that you now have a better sense of what could go wrong. How much time do you spend writing code to cover all of those different possibilities?

+ +

JOËL: Hmm, I don't know that I've ever put the time to quantify it. I would say a decent amount because you've got to think about...sometimes they're not even things that can go wrong per se. But they're off that very simple, linear happy path that you're thinking of. So you might think even for rendering some kind of view, and you've got some search results you're trying to display.

+ +

Have you considered an empty state? Is there a difference between initially loading the page or have not performed a search yet, and search but did not find any results? Those are things that are not necessarily errors, but they're not things you're thinking in mind when you're just writing that first happy path of, like, oh, load page, show results. I assume there's always a result set. And so those are things that are important for the user experience that you need to have, but that are kind of edge cases that you have to add in afterwards, or you have to think about.

+ +

And so I think that, for me, tends to fall under a similar category as okay; what if an error happened? Especially when you're dealing with kind of a full-stack situation where on the front end maybe you're making a result to a back end to pull down...let's say you're making a search and the back end is doing the actual search. You send up a query. Now you get back a failure.

+ +

Is that the same thing as getting no results back? Like, a success with no results, versus an error code, versus not making a query yet. So you've got like four or five states you've got to think about on the front end to display and how you're going to handle those. So I think thinking about those upfront is often really helpful.

+ +

STEPHANIE: As you were talking about that, I suppose I asked the question because I have experienced when those things are not thought about upfront, and then you discover them as you're implementing. And how much time do you use to kind of go into a little detouring trying to make sure that you have all of the edge cases covered, and at what point do you stop? Because you're like, I've covered what I can. And this ticket was supposed to only be three points [laughs] or whatever, you know.

+ +

JOËL: Yeah. And how do you keep a feature from ballooning when there are all these edge cases?

+ +

STEPHANIE: Yeah, exactly. It's a balance.

+ +

JOËL: Are there any techniques that you like to do when you...so you pick up a ticket that looks easy, but that might have a lot of these hidden edge cases in it. Are there techniques you like to use that might help you figure out those edge cases and maybe give you some follow-up questions that you might reach out to the product person to clarify? Or maybe it's mostly intuition and experience as a developer that you kind of figure out that, oh, these are the things we need to ask about. It's like, have you thought about an error state?

+ +

STEPHANIE: Yeah, that's a good question. In general, I'm a little suspicious of any ticket that doesn't include some kind of acceptance criteria about the unhappy path. And I certainly think it's a lot easier once you are embedded into this domain, and you have that expertise, and you are able to see the possible issues you'll run into. I do think that I like to do a little bit of coding just to kind of explore the space, and then that does give me more insight into how I might be able to follow up on the ticket.

+ +

So you mentioned techniques. Especially if they're written as user stories, I don't think they necessarily incorporate the flow or the procedure of how things are kicked off. And so when you're thinking about implementing it, you're like, oh, this actually needs to happen in the background, or this should be synchronous or not. And those are a lot of error states that I find are missing when I pick up a ticket.

+ +

And I think it also depends on which way you want to implement it what implementation is viable. And then maybe you bring it to a product person, and they are actually like, "No, we don't want it to work like that." And then you have to kind of rethink things a little bit. But yeah, certainly, the process of taking a user story and then doing an initial think-through of what approach you want to take definitely surfaces some potential unhappy paths.

+ +

JOËL: It's almost like prototyping it in your mind.

+ +

STEPHANIE: Yeah, I think so. I think it also depends a little bit on the team because if the engineer wrote the ticket, then there likely has been some thought about unhappy paths. But on other teams that I've been on when implementation is up to the person who picked it up rather than kind of spelled out for you by someone else who did that thinking, that's definitely an opportunity to pause, I think, and document which way you might want to go so that you can make sure that you account for the possible things that could go wrong that likely the user story didn't cover.

+ +

JOËL: Sometimes there are some edge cases or failure states that are just sort of built into the problem that you're solving. If you're having to make a background request, there's always a chance that that might fail because the network is not trustworthy. Sometimes though, those things just kind of come out of our implementation, the fact that we implemented it in a particular way.

+ +

And that's not something that you'd expect a product person to have to think about. That's more on us as developers to be like, oh yeah, well, I'm indexing into a hash and didn't think to check is a nested hash even present? Maybe that key isn't there. And now I've got a weird nil error, an undefined method. That's kind of on us rather than on, like, oh, a specific kind of thing that we can think about upfront.

+ +

STEPHANIE: Yeah, that's fair. And I think that is just an important part of the development process. Though you make a good point because I think that just kind of speaks to all of the different layers of things that can go wrong [laughs] and figuring out which ones are specific to your role as developer to account for, and then which are ones that you need to bring in or pull in a designer to chat about. It can be a little overwhelming. I'm overwhelmed just thinking about it.

+ +

[laughter]

+ +

JOËL: Yeah, errors are not a sort of monolithic class of things. They can't be an afterthought. But they're also not just a thing where it's like, oh yeah, do the error handling, and then you're good. We kind of lump a lot of things under the concept of errors, even if they might all eventually manifest as some kind of exception. I guess a true solution is just one giant top-level rescue nil.

+ +

STEPHANIE: [laughs] Very funny.

+ +

JOËL: So we've talked about a few different dimensions of errors where they might be sort of user-visible or not, or something that's more implementation-based versus inherent to the problem. One thing that we haven't looked at is the dimension of errors that might be recoverable versus not. Have you ever built a system where you had errors that could be recovered from and didn't crash the program?

+ +

STEPHANIE: Ooh, yes. That makes me think about retrying and especially what you're saying if things are happening in the background. Maybe there is an ephemeral error where the network timed out or something. But if it is given another shot, it might succeed on the second go. And I think there's a whole process of thinking about what happens when a process has to be retried and if there were any side effects that you didn't want to have committed the first time around, you know, but then something else that was supposed to happen and when the process happens again, things are very broken. So making sure that you are keeping things idempotent so that by undoing it again, there are not any unforeseen issues.

+ +

JOËL: I heard you say that word commit here, and that's kind of a keyword to my mind. I immediately think database transactions. Is that the sense that you're thinking about this term here? Or does it have another meaning for you in this context?

+ +

STEPHANIE: Yeah. I do think I used that word specifically because when I've run into this in the past, it has been around making database changes. I'm trying to think if there is another way that this might show up. I think even in something like sending an email, too, though it is a bit lower stakes. I've certainly, as a user, experienced when that goes wrong and just been [laughs] flooded with emails and being like, wow, this is annoying. And that's, I think, something valid to consider as well.

+ +

JOËL: Yeah. You don't want that email job to be a thing that gets retried and just keeps failing because there's a nil error after the email gets sent. And so we just re-enqueue it, re-enqueue it, re-enqueue it, and the person ends up receiving 500 emails.

+ +

STEPHANIE: What about you? Any thoughts about recoverable errors?

+ +

JOËL: Yeah. I think really common for me is thinking about that in the context of a background job because those are things that I think are specifically designed to be retried if they fail; at least, a lot of job enqueuing systems assume that. When we write them, we don't always take that into account, but that's the system that we're working in. So that can be something as simple as marking somewhere that you have sent that email so that you don't resend it if that job ever re-executes.

+ +

I think that goes to your point about idempotency earlier that you often want to write code that can get executed multiple times but doesn't necessarily do the action multiple times. It will do it at most once. And that's probably an interesting distinction to have is knowing what elements of your code need to execute at most once, versus as many times as the code is called, versus things that might get tried and then rolled back like a database transaction. And so then that will...I guess you could say it's at most once because you're writing it but unwriting it. But that plays out a little bit differently than something like an email where you can't undo sending an email outside of Gmail.

+ +

STEPHANIE: Yeah, I love that undo button. [laughs]

+ +

JOËL: You need some other mechanisms for that.

+ +

STEPHANIE: Yeah. As you were talking about that, I was also thinking about the idea of failing gracefully, which I think also ties into the idea of recoverable. So this is not a development-specific example. But the idea of an escalator no longer working well; at least you can use it as stairs. So that doesn't mean that everything is totally broken and people are unable to get from one floor to another. So maybe if there is a network request that's touching data and that fails, you can at least fall back on something that's cached. That mindset, I think, really is important to think about at all the different levels we are talking about.

+ +

JOËL: Yeah, or hopefully, even maybe some amount of graceful degradation. On a front-end app, you might not want to just crash the whole thing if one background request failed. So you can try again. You can be told, okay, try again in so much time. Maybe we automatically retry to make that same request with some sort of exponential backoff strategy. Or maybe we say, "Look, search is down for now. Here's a link if you want to go check a status page. Until then, other parts of the site are still working."

+ +

I feel like we're getting back into what makes great product design and how great product designers have to make failure conditions. It has to be at the forefront of the thinking that comes to designing that product.

+ +

STEPHANIE: Yeah, that's a good point. I think my initial feelings of being overwhelmed and stressed about dealing with errors may be because a lot of it falls on the developer if those things aren't accounted for. And we spoke a little bit earlier about, okay, what is within our realm or domain of actually being responsible for, and what can we loop in others for help with?

+ +

JOËL: So we've been talking a lot about different ways of preventing errors, different ways of recovering, generally trying to make the whole experience really smooth. A slightly different philosophy around errors is rather than preventing them early is to fail early, like, fail early and loudly. And maybe you recover, maybe you don't. That depends on the context. But instead of putting so much effort into preventing errors upfront, it's better to just crash a lot or to fail loudly and deal with the consequences, or have a strategy for dealing with failure because failure is inevitable. How do you feel about that philosophy?

+ +

STEPHANIE: Oh, I think it has a time and a place. One example I'm thinking of is if you don't want your application to be deployed if some configuration is not exactly how it needs to be for the app to run effectively. And so there is a matter of, like, okay, I really want to make sure that the DevOps team or the development team knows that something is very wrong because if this were to be deployed, the app would be unusable. And so that's an example to me of failing loudly but, ideally, not letting it affect end users because they're still using [laughs] the site on a different version. [laughs]

+ +

JOËL: Right. I guess the classic example of that is for a Rails app, doing a Hash#fetch() on the environment to load up your environment variables instead of using the square bracket syntax so that as the app is booting and executing those initializers, it will crash if it encounters one of those and then fail to deploy if you're doing a deploy via something like Heroku. I've even sometimes when I'm adding environment variables, purposefully had them loaded in an initializer rather than maybe like in a class later on, specifically so that it would crash the app and prevent deployment if that environment variable was not set.

+ +

STEPHANIE: Yeah, that's what I was thinking too, environment variables. Though I think even with that kind of mindset, you're either just delegating that responsibility to someone else down the line to either figure out how to accommodate or account for in a graceful manner. Or you are creating an environment where everyone is very stressed out [laughs] and having to fight fires. So I think it also requires a little bit of thought and isn't necessarily a strategy to just completely embody. [laughs]

+ +

JOËL: I've noticed that bugs and errors often accumulate at the boundaries of systems or even subsystems or modules within a program. Maybe the place to apply the strategy of failing early and loudly is particularly valuable at those boundaries. But internally, within a subsystem or a module, maybe it's nicer to use other strategies for error handling. Does that sound like maybe a useful distinction to you?

+ +

STEPHANIE: Yeah, I think subsystems was the keyword to me there because you don't want it to be such a catastrophe that it affects the usability of the app entirely. But that does still require some systems in place, I think, to respond to when that thing is failing loudly.

+ +

JOËL: I think an example that came to mind for me is like you were mentioning earlier, a full-stack application. And if you've got the back end that's providing an API and something is wrong, I don't want that API to give me back garbage data and try to pretend that everything's okay. Let that API give me back some kind of error code. And I in the front end, I already know that the network is inherently unreliable. I'm planning to handle errors at that point. So it's fine for the API back end to fail loudly in this case. In fact, I think that's the optimal solution.

+ +

STEPHANIE: Yeah, I think that's true because ideally, that error clues you into what kind of thing failed, and then maybe you can use that information more meaningfully than trying to guess at what happened with this bad data and then having to define some kind of error message in your app when ideally someone else who had more knowledge about it could have told you what went wrong.

+ +

JOËL: And I guess the problem with not failing loudly or with an explicit failure is that if you try to just pass on some sort of value that will pretend to be like what you initially asked for, whoever's consuming that doesn't know that something went wrong. So then you use this garbage data, and you do some things and pass it along to the next person. And eventually, it may cause a failure three or four steps down the line.

+ +

And now, trying to trace that, like, why did this fail? And it's not because something was wrong in Module D, or C, or B. It all comes back to oh, A had a problem but didn't crash or give us an error. It tried to pass its sort of best guess, like, this is probably okay. And then it just kind of moved all the way down the line.

+ +

STEPHANIE: I'm imagining external API developers everywhere just nodding their heads in agreement. [laughs]

+ +

JOËL: I've fought this on a local level as well. I was working on some kind of code for a JavaScript date picker plugin, and this was back in the jQuery days. It was some kind of...it was not a date picker. I think it was a typeahead drop-down thing. In some situations, I forget exactly how it would happen, but the input from there might be empty, but then that would get converted into an undefined value, which then JavaScript would convert to the string undefined, which would then get passed to something else that if it saw a string, it thought that was the thing that the user typed, and they would pass it through.

+ +

And I think maybe in the end, I was looking at a crash ten functions away in the front-end code that had to deal with the input from this typeahead and being like, why am I getting these undefined? Or maybe it was a string NaN or something like that. Like, why am I dealing with these weird strings that should never have come out of this? And it turned out it was just kind of an edge case. It wasn't addressed in this component further on, and then it was kind of leaking strings that everybody else thought was sensible up until three or four jumps further down the stack.

+ +

STEPHANIE: Yeah, that's a great point. I think it does go back to the idea of there being preventable errors. And then there are things that are truly not preventable because we live in a physical world [laughs] where computers talk to each other over the wire. And that distinction is, you know, perhaps the first being avoidable errors by writing resilient code. And the second being like, okay, in reality, there will be things that go wrong, and this is what we really have to watch out for.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. [laughs]

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+yCN7M7Kz + + ]]> + + Joël Quenneville + Stephanie Minn + + + 376: Success and Fulfillment + https://bikeshed.thoughtbot.com/376 + 760b8f3c-fbd4-4819-ae5a-fd20bf2a68c5 + Tue, 21 Mar 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Stephanie has a win and a gripe from her client project this week. In a previous episode, Joël talked about his work exploring how to model dependent side effects, particularly D&D dice rolls. He went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs. Then it will roll all the dice necessary and tell you did you successfully hit your target and, if so, how much damage you did. + +Together, they discuss how they think about fulfillment at work and what brings them fulfillment as developers. + 41:03 + no + + Stephanie has a win and a gripe from her client project this week. In a previous episode, Joël talked about his work exploring how to model dependent side effects, particularly D&D dice rolls. He went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs. Then it will roll all the dice necessary and tell you did you successfully hit your target and, if so, how much damage you did. +Together, they discuss how they think about fulfillment at work and what brings them fulfillment as developers. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Obsidian (https://obsidian.md/) +Joël's DnD dice roll app production (https://dnd-damage-roller.netlify.app/) site and repo (https://github.com/JoelQ/dungeons-and-dragons-damage-calculator) +Engineering Management for the Rest of Us (https://www.engmanagement.dev/) +The Five Love Languages (https://www.psychologytoday.com/intl/blog/click-here-happiness/202009/what-are-the-5-love-languages-definition-and-examples) +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 I have a win, I suppose, and a gripe from my client project this week that I would love to share. So my win is that I've been working in React lately. And I might have mentioned this on a previous episode, but it's been a few years for me. So I'm kind of catching up on the new, hot tooling, you know, whatever is popular in that world these days, and having to read a lot of documentation to figure out how to use it and just in general, I think being a little bit outside my comfort zone. +And I was working on an existing React component that was untested, and I had to change and extend some functionality in it. And we're also a little bit on a deadline. So there's like a little bit of pressure on the team to be delivering. And so when I got this ticket, I was like, okay, I am seeing this existing component that looks also a few years outdated. It's using some of the older technology that we've kind of moved on from. +And I was just like, oh, I really should write tests for this before I go in and change some things just to feel confident that my changes don't break anything because it was pretty gnarly. But I was not in the mood for it. [laughs] And this was like two or three days ago. I was just very grumpy. And I was like, oh man, why do I have to do it? [laughs] I kind of wanted to just get into making the changes so I could deliver on this work. +So, spoiler, I did not write the tests that day and just kind of went ahead with the changes. But then, the next morning, I woke up, and I was feeling inspired. I was like, I made those changes, but I'm actually not feeling that confident about it. So let me go back and try to write some tests. And I got to use the new tools I had been looking into, and that was part of my hesitation too. I was like, oh man, this is like a really old component. +And I don't want to use the older ones that we're using for testing. But how is it going to play with the newer testing tools that we're using? And so there was just like a lot of, I think, barriers to me feeling excited about writing those tests. But with my renewed energy, I did it. And I feel very happy about it and proud of myself. Yeah, that's my little win. +JOËL: That's a roller coaster of a journey there. That sort of deception when you find out that there are no tests for this and somebody else's problem has kind of become your problem. But then you decide you don't want it to be your problem, you know, kick it down the road for somebody else. And then you feel good about yourself, and you decide to backfill the test anyway. And you get that confidence, and now everything's better for everybody. That is quite the journey. +STEPHANIE: Exactly. I listened to another podcast recently where they coined this term called tantrum logic, which is basically the idea that when you're kind of grumpy or something happens, and you're like, man, I don't want to do any of this, like, if I can't do it my way, then I don't want to do it at all. [laughs] +And just the idea that the way you're thinking about the issue at hand may not be totally grounded in reality. And I think I needed that reset and just a good night's sleep and going to do something else to come back and be like, actually, I do want to write those tests, even if it will be challenging. I'm in a better mind space for it. Mind space? Headspace? [laughs] Headspace for it. And I overcame the tantrum logic. +JOËL: A good night's sleep is just such a powerful tool for resetting. +STEPHANIE: Yeah, I agree. Shout out to sleep. [laughs] It turns out that it can really have a positive effect on how you feel. +JOËL: By the way, this is not an advertisement. We are not sponsored by sleep. We just both love it and recommend it. +STEPHANIE: [laughs] To get into my gripe a little bit, so you and I are on the same client project we've mentioned before on the show. And I think I even talked a little bit about receiving a new computer from our client to do our client work on. So now I have many devices at home. And we had also chatted previously about a note-taking app that we both use called Obsidian. +And one of the reasons that I really like it is because it's all local storage. So your notes are not being uploaded to the cloud or whatever. But that does make it hard to use on multiple, I mean, not just hard, impossible to use [laughs] on multiple devices unless you pay for it. They have a sync offering where you can use it on multiple devices. And I think it's also encrypted in a certain way. +Anyway, sometimes I'll be working on my client laptop and have some idea or thought that I really want to note down, but I don't have Obsidian installed on this machine, and it's not synced to my other Obsidian. And I have just been kind of annoyed about having to go open another computer to write a thought down if I want to document it. And I'm curious how you deal with this problem. +JOËL: So the downside of Obsidian not being a cloud product is that you don't just get that sync for free. The upside of it just being markdown files on your hard drive is that you can use any other product or tool that you want to manipulate these files. So I have my Obsidian vault, which is just the term for the directory where it keeps all of these files in a Dropbox directory. And so I have it sync across multiple machines just by being signed into my Dropbox account. +STEPHANIE: That's smart. And that sync is pretty smooth for you? You don't have any issues with updating it in one spot and seeing those changes in another? +JOËL: I have not had issues with that. Of course, I'm not jumping between machines within 30 seconds of each other. Generally, I'm also connected to the internet. So I haven't had a situation where I make a change to a machine not connected to the internet, and then later on, I edit an old version on a different machine that is connected to the internet, and now we have conflict. I've not run into that problem. +STEPHANIE: Okay, cool. That sounds good. It's funny you mentioned that because it's just the other day, off-mic; you and I were on a call doing a little bit of pairing. And you were on both machines at the same time [laughs] because we had to use one for our call. And then you were looking something up on your client computer as well. And the thought of you just using two computers at once was very amusing to me. +JOËL: It's the ultimate hacker move in...I was going to say bad, but that's maybe a little bit too judgmental, but yeah, in classic, I feel like police shows, things like that. +STEPHANIE: I do have one more thought about note-taking that we haven't talked about before. But I'm really curious, how do you deal with thoughts you have on the road during a time you don't have a device on you? Do you go and write that down somewhere, or what do you do with those? +JOËL: I have an absolutely awful solution, which is I add it to my mental stack and hope it doesn't overflow before I get to a computer. +STEPHANIE: That's really funny because I used to do something similar where if I had a to-do list or something like that in my head, I would remember the number of items on my list to try to cue me into remembering what those items were. The worst thing that would happen is I would remember that I had three things on my to-do list but could only remember two. And so I had to just [laughs] deal with my existential anxiety about knowing that there was something else that I had forgotten about but could not remember [laughs] for the life of me what it was. +JOËL: So I do that trick sometimes for my grocery list if I don't want to write it down. I'll just be like, oh yeah, go to the grocery store, make sure there are five items in my basket when I check out. And similar to you, sometimes I have that problem. I had a light-bulb moment the other day, which is that this trick is actually an example of hashing content. +STEPHANIE: [laughs] +JOËL: So if you're ever hashing the contents of a file and then wanting to compare if another file is the same and you check the hashes are the same. In a sense, you're kind of hashing your grocery list and your shopping cart and trying to see do they both hash to the same value? Now, a good hashing algorithm has an infinitesimally low chance of a collision. Counting the number of items in your list or cart has a fairly high chance of a collision. You could have a cart and a list that both have five items, but they're not the same items. Yet this comparison would still make you think that they're the same. +STEPHANIE: This is a very funny metaphor to me. I think the other issue is that as a human and not a computer, I do not have the mental storage space to then also remember what algorithm [laughs] I'm using to hash my to-do list. +JOËL: The algorithm is the count function. +STEPHANIE: [laughs] True, true, a more sophisticated algorithm then. [laughs] +JOËL: Yes, which is why I keep using this not very safe, but it's good enough. +STEPHANIE: Sometimes, we just need to be good enough. So, Joël, what's new in your world? +JOËL: So, in a previous episode, I think we talked about some work I was doing exploring how to model dependent side effects, particularly D&D dice rolls. So this week, I went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs, and then it will roll all the dice necessary and tell you did you successfully hit your target, and if so, how much damage did you do? And it takes into account all these edge cases. +STEPHANIE: Cool. That's so exciting because I think we mentioned last time how that would be a really interesting exercise to write up that code. Did you get any insight from doing that? +JOËL: I think a lot of the insight that I got came from the initial diagramming phase. And I think coding it out really solidified the things that I had learned from the diagramming. Of interest here is that there are effectively or potentially four separate dice-rolling phases that can happen. First, you're rolling to see can you hit your target? And depending on the situation, you're rolling one or two dice. +And then after that, you're rolling to see if you do hit, how much damage you do. And you're either rolling one set of dice, or you might be rolling two sets of dice if you happen to do a critical hit. So I think that the diagram that I had clearly showed these are four sets of randomness that have to happen and then how they relate to each other. These two are dependent on each other; these two are independent. +I think one thing that was really interesting that I learned from the code is that for something like a dice roller, you usually don't want to see just the result. Because if I just have a button that says how much damage did I do, and then I get a number back that says, "You did zero damage," or "You did three damage," as a person, that's not very satisfying. And I don't know that I fully trust it. I want to see all the intermediate results. So I want to see, oh, did I roll two different dice for that initial two-hit? What were the numbers? +And then I can say, okay, well, I need to roll above a five or roll above a 10. And I rolled these two dice, and they were both under 10. That makes sense why I didn't hit. Or I rolled one of them above and one of them below, but I was rolling with disadvantage, which means I have to take the lower of the two numbers. So I could have hit, but I didn't. So I think that is really fun as a user to see the intermediate steps. But also, as a developer, it helps me to be confident that the code I wrote works the way I expect it to. +STEPHANIE: Yeah, that's really neat. I think what I love about this is that you took something that, in some ways, could be really simple, right? And the implementation could have been just the first thing that you thought of, but you thought very deeply about it and made the dice roller that you wanted in the world. [laughs] I'm curious. Can anyone go check out this repo on the internet? +JOËL: Yes. So we can link to the repo in the show notes. And also, the dice roller itself is up online at dnd-damage-roller.netlify.app. And we can link that as well for anybody who wants to go and check it out. +STEPHANIE: Awesome. +JOËL: I think my goal in this is it's more of a learning exercise. I don't think the world needs another D&D dice roller. There are better ones built into more comprehensive tools. But it was fun for me to work on this, to explore some ideas, and to dig into randomness. I've always had a fascination with random rolls. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: So it sounds like the Dice Roller app really scratched an itch for you and was a fulfilling exercise for you and just exploring randomness, like you mentioned, and just a theory that you had about writing good code. I'm curious about how you think about fulfillment at work in general and what brings you fulfillment as a developer. +JOËL: Fulfillment is really interesting because I think it's a really kind of personal question. It probably varies a little bit from person to person. But there are probably also some aspects that are global to everyone. I know we've talked about things like psychological safety in the past. And if you don't have things like that, that baseline, it's going to be hard to feel fulfilled. +STEPHANIE: Yeah, I agree. I am thinking of Maslow's hierarchy of needs, and in some ways, fulfillment is kind of the tip of the pyramid. If you are feeling safe and like you belong and get enough sleep, like we mentioned earlier, you can reach towards getting into what really feels fulfilling and gives you purpose in life. +JOËL: I love that you brought up Maslow's pyramid because like you said, that top part is self-actualization. So you need all those lower layers before you can actually reach the point of true fulfillment on the job. One thing I recently realized about myself is how I tend to approach projects that are in a difficult place. I find a lot of fulfillment in sort of relative change. It doesn't matter if a project is in a bad place as long as the project on a week-by-week basis is moving in the right direction. It might still be in a bad place, but is it better than last week? And was I a part of making that better? That makes me feel good. +STEPHANIE: Yes. I have always really admired your optimism around that and how you share even small wins. You're really good about that, actually, and celebrating that. And it's interesting to learn that it's like that process itself that has a lot of meaning for you. Because I think I'm a little bit different in the sense that I have an ideal version of working in my head, and if we're not there, even if we are making some incremental progress week to week, I think I struggle. +Sometimes I feel frustrated or stressed because I think that we're just not where I want to be. And I've definitely been thinking about harnessing some of that optimism and celebration that you have around, just making things better a little bit at a time. +JOËL: And I think we should be clear that this is not the way one has to be; this is just how I tend to feel on projects. +STEPHANIE: Yeah, absolutely. +JOËL: I know there are plenty of people who feel most fulfilled when they're on projects where things are mostly good. And then it's not about incremental improvement in the product, but maybe it's shipping a lot of features and feeling like they're moving very quickly. Maybe it's that feeling of speed that gives them fulfillment rather than the feeling of incremental progress. +STEPHANIE: Yeah, absolutely. I think what is helpful for me in hearing about this from you and just from others (I love talking to other people and learning about what motivates them.) is seeing what else is possible outside of my own little universe inside my head and doing the self-reflection to be like, okay cool, this works for Joël, but maybe this doesn't work for me. But having the input from other people lets me discover more about myself in that way. +JOËL: That is incredibly powerful. I love that. I think in a variety of aspects of my life, but especially when it comes to fulfillment in software and at work, talking to other people, seeing how they relate to a project or to a particular task, and, like you said, getting to see their perspectives that are sometimes totally different than mine. +STEPHANIE: Yeah, absolutely. So you just mentioned one aspect of how you find fulfillment when a project is maybe in a tougher spot than usual. I'm curious if you can recall a time that you've been the most fulfilled at work. +JOËL: Most fulfilled. I think one of the most fulfilling projects I did was several years ago. We built a dashboard for just exploring a lot of data from medical studies. And so the researchers would upload some time series data for things like heart rate, or skin electro-sensitivity, a bunch of other things, along with a video. It was a kind of an interview-style situation. They were doing a session with a patient. +And we would then sync all of these data streams up. We would sync it up to the video, and then you could kind of explore the data. There were scrubbers, so you could kind of scrub through the video, and it would scrub through the time series data all at the same time in sync. You could scrub through the time series data. It would sync the video kind of like bidirectional. You could zoom in on the data. +The idea is this is a high-level kind of exploratory tool. And you could then find the interesting bits of data that you could then do more quantitative analysis on. So you could then find a part of the stream and say, this is the interesting part. Clip from 10:55 to 11:10 in the stream, on all streams, and then export just that data in a zip file. And then I'm going to put that through a bunch of math and figure out, oh, is there a correlation between these moments? +STEPHANIE: So what about that project was really exciting or fun for you? +JOËL: I think the client was incredibly fun to work with. There was like an energy and excitement. This was part of their, I think, Ph.D. thesis. And they were really excited. They were incredibly knowledgeable, just delightful to work with. I think this was a fun...so we built this from scratch. It was a greenfield app. I think it had a lot of interactivity. It had a lot of visuals. It was one of the first projects I got to work on that used Elm. I think all those things combined to just make it a really fun project to work on. +It was also a fairly short project. So we had a very kind of tight deadline. We were very pragmatic with absolutely everything on there. Like, what can we do to get this done quickly? Is this feature worth the time? It was kind of a classic MVP product. And I think it was one of the most fun things I've built. +STEPHANIE: Cool. I'm also hearing there was probably some creative aspect of it that was really fulfilling for you, like exploring a lot of new things. Like, you said, you were working with Elm for the first time. And the project itself sounds very different from some of our other more typical consulting engagements and also the collaboration aspect. Like, you mentioned the tight deadline, which compelled you all to work really closely together to make this really cool thing in that short amount of time. +JOËL: Exactly. Yeah, it was like a three or four-week project that I look back on really fondly. Like, oh, that was a good time with those two colleagues and that client, and we did a thing. It was really cool. +STEPHANIE: That's awesome. +JOËL: I think it's really interesting that just hearing that story, you're immediately picking up on, like, oh, I see elements of creativity and exploration. Do you have kind of an internal system that you use to analyze projects that you're on to be like, oh, this is a project I'm enjoying because of this element or that? Because you seem very self-aware around these types of things. +STEPHANIE: I'm glad you asked that because I think I was trying to reflect back to you some of the things that I picked up about what you were sharing. I have been reading a book, surprise, surprise. +JOËL: What? You read? +STEPHANIE: I read. [laughs] It's called "Engineering Management for the Rest of Us" by Sarah Drasner. And I am not an engineering manager, and I don't necessarily know if I even want to be. But I really enjoy reading management books to better understand how to manage myself or how to be a person who is managed. +And one of the things she talks about is understanding an individual's values and how those things end up being what motivates them and also likely what brings fulfillment. And so after I learned about the value of values, I started thinking, okay, what is it that I am motivated by? And really reflecting on when I have felt really good about work and also when I felt challenged or unhappy at work and what things were missing during that time. +So the things that I have realized that I am very motivated by are human connection. I love spending quality time with people, and that is probably why I enjoy pairing so much. But also, in my one on ones with my manager, I really enjoy that time just being time for us to share space and get to know each other and talk. It doesn't necessarily need to be going through agenda items or a status report or even necessarily talking about my project. +JOËL: So you mentioned that you value quality time with others. Is that a reference to "The Five Love Languages" concept? +STEPHANIE: It is. It is. I think I also made a bit of a connection there too because what I like in my personal relationships also obviously applies to work. +JOËL: Yeah, it's how you feel appreciated, how you feel fulfilled. And just for our listeners who may not have read this book, I think the concept is that there are five ways that people like to receive appreciation. +STEPHANIE: Yeah, I think receive and both express appreciation and love. And quality time is one of them. +JOËL: Yeah, yeah. And the other four, if I remember correctly, are acts of service, words of affirmation, physical touch. +STEPHANIE: Gift-giving is the last one. Yeah, so that was a fun reflection on my part in being able to just know what makes me feel good. And then it also helps me communicate with other people how to work with me. I think that is super important. I love when people share with me what, I mean, I mentioned this earlier, just what drives them and how they like to be appreciated so that I can do my best to try to offer them that. +And I guess this actually is a good transition into the next value of mine that really drives me. I was thinking about this because I mentioned just now that I was learning some new React tools, new to me, anyway. And I'm like, yeah, I like learning. But then I was like; I don't know if I like learning the way other people like learning in the sense that it's not the knowledge itself or the process of learning itself that drives me but learning as a tool to better understand myself. So I think personal development is very important to me. And that feels different from how other people might value learning. +JOËL: Interesting. So you might be excited to learn a new React testing tool but not because you're chasing the latest, shiny tech but more because you feel like the process of learning this testing tool helps you learn something new about yourself. +STEPHANIE: Yeah, I think that sounds right. One of the tools specifically...we're using MSW Mock Service Worker for mocking network requests in Jest. And I was able to use information about testing in Rails and Ruby and apply that to this new tool. And I got to kind of revel in the fact that I could use previous learnings to apply in this new context, and that was really cool to me. So it wasn't necessarily the tool itself or even the process of learning but kind of realizing that I was capable of applying one thing to this less familiar thing. +JOËL: So kind of that realization that, hey, you're now far enough in your career, and you have enough experience. You have a broad base of knowledge that all of a sudden, you realize, wait a minute, I'm not starting from scratch anymore. I can apply lessons learned in the past to learn this new thing and make that easier. And that's a really validating feeling. +STEPHANIE: Exactly. That was really cool to me, and I felt really good afterwards. I think this week at work has been very uplifting because I've been having all these little mini-revelations if you will. +JOËL: I love that. I love that so much. +STEPHANIE: So, one thing that I think is very easily conflated with fulfillment is the idea of success. And I kind of want to talk about the distinction between success and fulfillment. Does that bring up any thoughts for you? +JOËL: Yes. I think the two are often entangled, but they're definitely not the same thing. It is possible to be fulfilled on a project that is not successful. And it's also possible to be on a successful project and yet not feel fulfilled. But oftentimes, the two go together because when things are going well on a project, they're probably also going well in a lot of other ways, and you might be feeling fulfilled as long as general parameters fit in, right? If values line up, things like that. +I know for me I value quality and excellence and doing work that I'm proud of. So I think if I were working at a place that was doing kind of low-quality, low-cost work where it's just like, you know what? You want cheap and low-quality? Come to us. We'll just get it done quick and cheap. And yeah, it's not going to be great, but you get what you pay for. +There's a reason this part of the market exists, and it's a totally valid way to build software. But I would not feel fulfilled there, even though maybe the clients are absolutely happy with the work that's being done. So I think that would be a situation where there is success, but I might not feel personally fulfilled. +STEPHANIE: Yeah, I'm glad you brought that up because I think I really struggled in the beginning of my consulting career with equating client happiness with success. And I'm now just starting to kind of unlearn that a little bit and realizing that success means different things to different people. So even if we talk about thoughtbot for just a second, one of thoughtbot's values as a company is seeking fulfillment in everything that we do. +And so even though, like you said, the client might be totally happy, for thoughtbot, that may not be a successful client engagement if you, Joël, as the developer staffed on that project, didn't find fulfillment. Because what's success for us here is that we are fulfilled in the project itself. And that was really helpful because, in some ways, I'm like, well, who cares? Who else cares besides me that I'm fulfilled? And to be like, oh, yeah, actually, what our collective success means is that I'm fulfilled, and you're fulfilled. That was really important to me and one thing that I really appreciate about working here. +JOËL: Fulfillment comes partly from our environment, from maybe the project that we're working on, our colleagues, but also comes to a certain extent from ourselves. And to a certain extent, we can drive that ourselves as well. And I think that first step is a certain amount of self-awareness and self-understanding. You are clearly a master at this. What are some things that you do to drive that self-understanding, to build maybe a sense of how you become fulfilled, and identifying those values that make you feel fulfilled on a project? +STEPHANIE: Listen, [laughs] I don't know if I would call myself a master at this, only that I'm very actively working on it in my life right now, in therapy, but also in talking to other people about this because, yeah, sometimes it has caused me a lot of turmoil. I'll be really stuck in a rut or feeling a lot of burnout, and that, ironically, actually motivates me to be like, how can this be different? And oftentimes, that means I have to look inward. +But you and I had a conversation last week off-mic that was really helpful for me because I was feeling really bummed about my client work and it not going the way that I thought it would. And your insight helped me think about the project a little differently and think about metrics of success differently. For that project, I could not expect that project to look exactly like all of my past experiences. And success for those projects were not the same for this project. So yeah, talking to others, I highly recommend that. +JOËL: I guess you mentioned that you read a lot of management books and a lot of books geared towards managers for discussing things like how to set up a one-on-one. Those are almost like...they're not really therapy, but they kind of lean a little bit towards that sometimes and trying to create fulfillment for your direct reports. So maybe seeing it from the other side helps you build understanding. +STEPHANIE: Yeah, actually, that's totally a great call out because I highly recommend reading books about [laughs] management, even if you're not interested in management. Only because there's no guarantee that you'll have a good manager who can do all those things for you, so if you can equip yourself for doing those things, then you are likely to have a better workplace experience, in my opinion. +JOËL: And I guess the obvious one that we have not talked about is if you do have a good manager, have these conversations with them. +STEPHANIE: Yeah, absolutely. +JOËL: Part of their job is to help you be more fulfilled. And they should be having conversations to maybe help you discover those ways that you are feeling fulfilled at work and how to get there. Here's one aspect that we have not talked about that I'm curious to explore a little bit: recognition. +STEPHANIE: Ooh. Yeah, that's a good one. +JOËL: How important is it for you to feel recognized, either by your colleagues or by the more official org structure? +STEPHANIE: This is a great question. I do value recognition from people I trust. So I think we were talking about sometimes client projects are not successful, but you tried your best, and you did do valuable work. And you might not hear that from the client. They might think differently. But if a trusted co-worker can provide that validation for you, oftentimes, I find that more helpful. +JOËL: That's an interesting distinction. And I think recognition has a very different weight depending on the source it's coming from. If it's somebody you look up to, and they just give you a shout-out or something, I'm riding that high all day long. +STEPHANIE: Yeah, yeah, that's a great point. How do you like to receive recognition? +JOËL: Hmm. So at thoughtbot, we have an internal system where we can give shout-outs to each other. They're called high fives. And they get shared directly to the team Slack channel. And it's a small thing, but I really appreciate it when somebody calls out like, "Hey, I appreciated this thing that you did," or "This is the thing that had an impact on me," or "I appreciated the thing that you shared." +Those things make me feel really great. It's a small thing. It takes 30 seconds to do. But I really appreciate that. And it's something that I am looking to more intentionally do more of because it's fun to receive recognition, but it's also really valuable to give recognition. +STEPHANIE: Yeah, I'm with you. I am also trying to be intentional about being even more generous with my positive feedback for others. And I think there's also some degree of recognition and validation to give to yourself. +JOËL: Self-validation. +STEPHANIE: Yeah, yeah. I mean, I'm definitely trying to do more of that. Because if I'm doing work that lines up with my values, I want to be able to pat myself on the back for it, even if no one else will do it for me. [laughs] +JOËL: What does that look like? You're like standing in the mirror and saying, "Good job?" +STEPHANIE: [laughs] +JOËL: Do you have maybe a document where you kind of list the things that you feel proud of, even if nobody else has noticed? What does that look like for you? +STEPHANIE: Ooh, yeah, a brag document. I think some folks at thoughtbot have recommended doing that. For me, it's going and getting myself a treat. +JOËL: Oh, I like that. +STEPHANIE: So maybe like a latte the next morning or going to get just a sweet thing. Yeah, that's my way of doing it. +JOËL: So we've talked about self-recognition, recognition from colleagues. I think another element is recognition from management or the company that you're working at. That can be just praise. But oftentimes, I think when you're looking at recognition from something a little more corporate, it has a more kind of concrete aspect to it. And maybe that is come yearly evaluation time; there's a raise that recognizes the fact that you've done good work. +I know for me, last year, I got a big promotion. And I felt like I had been performing at a level that was kind of pretty far above and beyond the title that I had. And getting that promotion, in some ways, was very much kind of validation and recognition of the fact that I had been performing at that high level. +STEPHANIE: Yeah, it sounds like the acknowledgment for the expanded work that you've been doing was really motivating for you. +JOËL: Yeah. It's interesting you mentioned that acknowledgment is really motivating because it really is, and sometimes the reverse is also true. You feel discouraged or unmotivated because the good work that you're doing is not recognized. Are you familiar with the idea of intrinsic versus extrinsic motivation? +STEPHANIE: Yeah, I am. Being motivated by something externally, like someone offering a promotion, or a raise, or whatever, versus it coming from yourself. +JOËL: Yeah. And I think for many people, you're probably not purely motivated by one or the other. There are some things where you're motivated by your own internal values, as we mentioned earlier, and some things where you're motivated by incentives offered at work. And that balance will probably shift over time and in different moments. But having a little bit of both can be really, really powerful. If you can be living up to your values and then get rewarded for it, that's kind of peak fulfillment right there. +STEPHANIE: Yeah, that's the sweet spot. Yeah, I wish that for everyone in the world. [laughs] On that note, shall we wrap up? +JOËL: Let's wrap up. [laughs] +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie has a win and a gripe from her client project this week. In a previous episode, Joël talked about his work exploring how to model dependent side effects, particularly D&D dice rolls. He went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs. Then it will roll all the dice necessary and tell you did you successfully hit your target and, if so, how much damage you did.

+ +

Together, they discuss how they think about fulfillment at work and what brings them fulfillment as developers.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 I have a win, I suppose, and a gripe from my client project this week that I would love to share. So my win is that I've been working in React lately. And I might have mentioned this on a previous episode, but it's been a few years for me. So I'm kind of catching up on the new, hot tooling, you know, whatever is popular in that world these days, and having to read a lot of documentation to figure out how to use it and just in general, I think being a little bit outside my comfort zone.

+ +

And I was working on an existing React component that was untested, and I had to change and extend some functionality in it. And we're also a little bit on a deadline. So there's like a little bit of pressure on the team to be delivering. And so when I got this ticket, I was like, okay, I am seeing this existing component that looks also a few years outdated. It's using some of the older technology that we've kind of moved on from.

+ +

And I was just like, oh, I really should write tests for this before I go in and change some things just to feel confident that my changes don't break anything because it was pretty gnarly. But I was not in the mood for it. [laughs] And this was like two or three days ago. I was just very grumpy. And I was like, oh man, why do I have to do it? [laughs] I kind of wanted to just get into making the changes so I could deliver on this work.

+ +

So, spoiler, I did not write the tests that day and just kind of went ahead with the changes. But then, the next morning, I woke up, and I was feeling inspired. I was like, I made those changes, but I'm actually not feeling that confident about it. So let me go back and try to write some tests. And I got to use the new tools I had been looking into, and that was part of my hesitation too. I was like, oh man, this is like a really old component.

+ +

And I don't want to use the older ones that we're using for testing. But how is it going to play with the newer testing tools that we're using? And so there was just like a lot of, I think, barriers to me feeling excited about writing those tests. But with my renewed energy, I did it. And I feel very happy about it and proud of myself. Yeah, that's my little win.

+ +

JOËL: That's a roller coaster of a journey there. That sort of deception when you find out that there are no tests for this and somebody else's problem has kind of become your problem. But then you decide you don't want it to be your problem, you know, kick it down the road for somebody else. And then you feel good about yourself, and you decide to backfill the test anyway. And you get that confidence, and now everything's better for everybody. That is quite the journey.

+ +

STEPHANIE: Exactly. I listened to another podcast recently where they coined this term called tantrum logic, which is basically the idea that when you're kind of grumpy or something happens, and you're like, man, I don't want to do any of this, like, if I can't do it my way, then I don't want to do it at all. [laughs]

+ +

And just the idea that the way you're thinking about the issue at hand may not be totally grounded in reality. And I think I needed that reset and just a good night's sleep and going to do something else to come back and be like, actually, I do want to write those tests, even if it will be challenging. I'm in a better mind space for it. Mind space? Headspace? [laughs] Headspace for it. And I overcame the tantrum logic.

+ +

JOËL: A good night's sleep is just such a powerful tool for resetting.

+ +

STEPHANIE: Yeah, I agree. Shout out to sleep. [laughs] It turns out that it can really have a positive effect on how you feel.

+ +

JOËL: By the way, this is not an advertisement. We are not sponsored by sleep. We just both love it and recommend it.

+ +

STEPHANIE: [laughs] To get into my gripe a little bit, so you and I are on the same client project we've mentioned before on the show. And I think I even talked a little bit about receiving a new computer from our client to do our client work on. So now I have many devices at home. And we had also chatted previously about a note-taking app that we both use called Obsidian.

+ +

And one of the reasons that I really like it is because it's all local storage. So your notes are not being uploaded to the cloud or whatever. But that does make it hard to use on multiple, I mean, not just hard, impossible to use [laughs] on multiple devices unless you pay for it. They have a sync offering where you can use it on multiple devices. And I think it's also encrypted in a certain way.

+ +

Anyway, sometimes I'll be working on my client laptop and have some idea or thought that I really want to note down, but I don't have Obsidian installed on this machine, and it's not synced to my other Obsidian. And I have just been kind of annoyed about having to go open another computer to write a thought down if I want to document it. And I'm curious how you deal with this problem.

+ +

JOËL: So the downside of Obsidian not being a cloud product is that you don't just get that sync for free. The upside of it just being markdown files on your hard drive is that you can use any other product or tool that you want to manipulate these files. So I have my Obsidian vault, which is just the term for the directory where it keeps all of these files in a Dropbox directory. And so I have it sync across multiple machines just by being signed into my Dropbox account.

+ +

STEPHANIE: That's smart. And that sync is pretty smooth for you? You don't have any issues with updating it in one spot and seeing those changes in another?

+ +

JOËL: I have not had issues with that. Of course, I'm not jumping between machines within 30 seconds of each other. Generally, I'm also connected to the internet. So I haven't had a situation where I make a change to a machine not connected to the internet, and then later on, I edit an old version on a different machine that is connected to the internet, and now we have conflict. I've not run into that problem.

+ +

STEPHANIE: Okay, cool. That sounds good. It's funny you mentioned that because it's just the other day, off-mic; you and I were on a call doing a little bit of pairing. And you were on both machines at the same time [laughs] because we had to use one for our call. And then you were looking something up on your client computer as well. And the thought of you just using two computers at once was very amusing to me.

+ +

JOËL: It's the ultimate hacker move in...I was going to say bad, but that's maybe a little bit too judgmental, but yeah, in classic, I feel like police shows, things like that.

+ +

STEPHANIE: I do have one more thought about note-taking that we haven't talked about before. But I'm really curious, how do you deal with thoughts you have on the road during a time you don't have a device on you? Do you go and write that down somewhere, or what do you do with those?

+ +

JOËL: I have an absolutely awful solution, which is I add it to my mental stack and hope it doesn't overflow before I get to a computer.

+ +

STEPHANIE: That's really funny because I used to do something similar where if I had a to-do list or something like that in my head, I would remember the number of items on my list to try to cue me into remembering what those items were. The worst thing that would happen is I would remember that I had three things on my to-do list but could only remember two. And so I had to just [laughs] deal with my existential anxiety about knowing that there was something else that I had forgotten about but could not remember [laughs] for the life of me what it was.

+ +

JOËL: So I do that trick sometimes for my grocery list if I don't want to write it down. I'll just be like, oh yeah, go to the grocery store, make sure there are five items in my basket when I check out. And similar to you, sometimes I have that problem. I had a light-bulb moment the other day, which is that this trick is actually an example of hashing content.

+ +

STEPHANIE: [laughs]

+ +

JOËL: So if you're ever hashing the contents of a file and then wanting to compare if another file is the same and you check the hashes are the same. In a sense, you're kind of hashing your grocery list and your shopping cart and trying to see do they both hash to the same value? Now, a good hashing algorithm has an infinitesimally low chance of a collision. Counting the number of items in your list or cart has a fairly high chance of a collision. You could have a cart and a list that both have five items, but they're not the same items. Yet this comparison would still make you think that they're the same.

+ +

STEPHANIE: This is a very funny metaphor to me. I think the other issue is that as a human and not a computer, I do not have the mental storage space to then also remember what algorithm [laughs] I'm using to hash my to-do list.

+ +

JOËL: The algorithm is the count function.

+ +

STEPHANIE: [laughs] True, true, a more sophisticated algorithm then. [laughs]

+ +

JOËL: Yes, which is why I keep using this not very safe, but it's good enough.

+ +

STEPHANIE: Sometimes, we just need to be good enough. So, Joël, what's new in your world?

+ +

JOËL: So, in a previous episode, I think we talked about some work I was doing exploring how to model dependent side effects, particularly D&D dice rolls. So this week, I went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs, and then it will roll all the dice necessary and tell you did you successfully hit your target, and if so, how much damage did you do? And it takes into account all these edge cases.

+ +

STEPHANIE: Cool. That's so exciting because I think we mentioned last time how that would be a really interesting exercise to write up that code. Did you get any insight from doing that?

+ +

JOËL: I think a lot of the insight that I got came from the initial diagramming phase. And I think coding it out really solidified the things that I had learned from the diagramming. Of interest here is that there are effectively or potentially four separate dice-rolling phases that can happen. First, you're rolling to see can you hit your target? And depending on the situation, you're rolling one or two dice.

+ +

And then after that, you're rolling to see if you do hit, how much damage you do. And you're either rolling one set of dice, or you might be rolling two sets of dice if you happen to do a critical hit. So I think that the diagram that I had clearly showed these are four sets of randomness that have to happen and then how they relate to each other. These two are dependent on each other; these two are independent.

+ +

I think one thing that was really interesting that I learned from the code is that for something like a dice roller, you usually don't want to see just the result. Because if I just have a button that says how much damage did I do, and then I get a number back that says, "You did zero damage," or "You did three damage," as a person, that's not very satisfying. And I don't know that I fully trust it. I want to see all the intermediate results. So I want to see, oh, did I roll two different dice for that initial two-hit? What were the numbers?

+ +

And then I can say, okay, well, I need to roll above a five or roll above a 10. And I rolled these two dice, and they were both under 10. That makes sense why I didn't hit. Or I rolled one of them above and one of them below, but I was rolling with disadvantage, which means I have to take the lower of the two numbers. So I could have hit, but I didn't. So I think that is really fun as a user to see the intermediate steps. But also, as a developer, it helps me to be confident that the code I wrote works the way I expect it to.

+ +

STEPHANIE: Yeah, that's really neat. I think what I love about this is that you took something that, in some ways, could be really simple, right? And the implementation could have been just the first thing that you thought of, but you thought very deeply about it and made the dice roller that you wanted in the world. [laughs] I'm curious. Can anyone go check out this repo on the internet?

+ +

JOËL: Yes. So we can link to the repo in the show notes. And also, the dice roller itself is up online at dnd-damage-roller.netlify.app. And we can link that as well for anybody who wants to go and check it out.

+ +

STEPHANIE: Awesome.

+ +

JOËL: I think my goal in this is it's more of a learning exercise. I don't think the world needs another D&D dice roller. There are better ones built into more comprehensive tools. But it was fun for me to work on this, to explore some ideas, and to dig into randomness. I've always had a fascination with random rolls.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So it sounds like the Dice Roller app really scratched an itch for you and was a fulfilling exercise for you and just exploring randomness, like you mentioned, and just a theory that you had about writing good code. I'm curious about how you think about fulfillment at work in general and what brings you fulfillment as a developer.

+ +

JOËL: Fulfillment is really interesting because I think it's a really kind of personal question. It probably varies a little bit from person to person. But there are probably also some aspects that are global to everyone. I know we've talked about things like psychological safety in the past. And if you don't have things like that, that baseline, it's going to be hard to feel fulfilled.

+ +

STEPHANIE: Yeah, I agree. I am thinking of Maslow's hierarchy of needs, and in some ways, fulfillment is kind of the tip of the pyramid. If you are feeling safe and like you belong and get enough sleep, like we mentioned earlier, you can reach towards getting into what really feels fulfilling and gives you purpose in life.

+ +

JOËL: I love that you brought up Maslow's pyramid because like you said, that top part is self-actualization. So you need all those lower layers before you can actually reach the point of true fulfillment on the job. One thing I recently realized about myself is how I tend to approach projects that are in a difficult place. I find a lot of fulfillment in sort of relative change. It doesn't matter if a project is in a bad place as long as the project on a week-by-week basis is moving in the right direction. It might still be in a bad place, but is it better than last week? And was I a part of making that better? That makes me feel good.

+ +

STEPHANIE: Yes. I have always really admired your optimism around that and how you share even small wins. You're really good about that, actually, and celebrating that. And it's interesting to learn that it's like that process itself that has a lot of meaning for you. Because I think I'm a little bit different in the sense that I have an ideal version of working in my head, and if we're not there, even if we are making some incremental progress week to week, I think I struggle.

+ +

Sometimes I feel frustrated or stressed because I think that we're just not where I want to be. And I've definitely been thinking about harnessing some of that optimism and celebration that you have around, just making things better a little bit at a time.
+JOËL: And I think we should be clear that this is not the way one has to be; this is just how I tend to feel on projects.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I know there are plenty of people who feel most fulfilled when they're on projects where things are mostly good. And then it's not about incremental improvement in the product, but maybe it's shipping a lot of features and feeling like they're moving very quickly. Maybe it's that feeling of speed that gives them fulfillment rather than the feeling of incremental progress.

+ +

STEPHANIE: Yeah, absolutely. I think what is helpful for me in hearing about this from you and just from others (I love talking to other people and learning about what motivates them.) is seeing what else is possible outside of my own little universe inside my head and doing the self-reflection to be like, okay cool, this works for Joël, but maybe this doesn't work for me. But having the input from other people lets me discover more about myself in that way.

+ +

JOËL: That is incredibly powerful. I love that. I think in a variety of aspects of my life, but especially when it comes to fulfillment in software and at work, talking to other people, seeing how they relate to a project or to a particular task, and, like you said, getting to see their perspectives that are sometimes totally different than mine.

+ +

STEPHANIE: Yeah, absolutely. So you just mentioned one aspect of how you find fulfillment when a project is maybe in a tougher spot than usual. I'm curious if you can recall a time that you've been the most fulfilled at work.

+ +

JOËL: Most fulfilled. I think one of the most fulfilling projects I did was several years ago. We built a dashboard for just exploring a lot of data from medical studies. And so the researchers would upload some time series data for things like heart rate, or skin electro-sensitivity, a bunch of other things, along with a video. It was a kind of an interview-style situation. They were doing a session with a patient.

+ +

And we would then sync all of these data streams up. We would sync it up to the video, and then you could kind of explore the data. There were scrubbers, so you could kind of scrub through the video, and it would scrub through the time series data all at the same time in sync. You could scrub through the time series data. It would sync the video kind of like bidirectional. You could zoom in on the data.

+ +

The idea is this is a high-level kind of exploratory tool. And you could then find the interesting bits of data that you could then do more quantitative analysis on. So you could then find a part of the stream and say, this is the interesting part. Clip from 10:55 to 11:10 in the stream, on all streams, and then export just that data in a zip file. And then I'm going to put that through a bunch of math and figure out, oh, is there a correlation between these moments?

+ +

STEPHANIE: So what about that project was really exciting or fun for you?

+ +

JOËL: I think the client was incredibly fun to work with. There was like an energy and excitement. This was part of their, I think, Ph.D. thesis. And they were really excited. They were incredibly knowledgeable, just delightful to work with. I think this was a fun...so we built this from scratch. It was a greenfield app. I think it had a lot of interactivity. It had a lot of visuals. It was one of the first projects I got to work on that used Elm. I think all those things combined to just make it a really fun project to work on.

+ +

It was also a fairly short project. So we had a very kind of tight deadline. We were very pragmatic with absolutely everything on there. Like, what can we do to get this done quickly? Is this feature worth the time? It was kind of a classic MVP product. And I think it was one of the most fun things I've built.

+ +

STEPHANIE: Cool. I'm also hearing there was probably some creative aspect of it that was really fulfilling for you, like exploring a lot of new things. Like, you said, you were working with Elm for the first time. And the project itself sounds very different from some of our other more typical consulting engagements and also the collaboration aspect. Like, you mentioned the tight deadline, which compelled you all to work really closely together to make this really cool thing in that short amount of time.

+ +

JOËL: Exactly. Yeah, it was like a three or four-week project that I look back on really fondly. Like, oh, that was a good time with those two colleagues and that client, and we did a thing. It was really cool.

+ +

STEPHANIE: That's awesome.

+ +

JOËL: I think it's really interesting that just hearing that story, you're immediately picking up on, like, oh, I see elements of creativity and exploration. Do you have kind of an internal system that you use to analyze projects that you're on to be like, oh, this is a project I'm enjoying because of this element or that? Because you seem very self-aware around these types of things.

+ +

STEPHANIE: I'm glad you asked that because I think I was trying to reflect back to you some of the things that I picked up about what you were sharing. I have been reading a book, surprise, surprise.

+ +

JOËL: What? You read?

+ +

STEPHANIE: I read. [laughs] It's called "Engineering Management for the Rest of Us" by Sarah Drasner. And I am not an engineering manager, and I don't necessarily know if I even want to be. But I really enjoy reading management books to better understand how to manage myself or how to be a person who is managed.

+ +

And one of the things she talks about is understanding an individual's values and how those things end up being what motivates them and also likely what brings fulfillment. And so after I learned about the value of values, I started thinking, okay, what is it that I am motivated by? And really reflecting on when I have felt really good about work and also when I felt challenged or unhappy at work and what things were missing during that time.

+ +

So the things that I have realized that I am very motivated by are human connection. I love spending quality time with people, and that is probably why I enjoy pairing so much. But also, in my one on ones with my manager, I really enjoy that time just being time for us to share space and get to know each other and talk. It doesn't necessarily need to be going through agenda items or a status report or even necessarily talking about my project.

+ +

JOËL: So you mentioned that you value quality time with others. Is that a reference to "The Five Love Languages" concept?

+ +

STEPHANIE: It is. It is. I think I also made a bit of a connection there too because what I like in my personal relationships also obviously applies to work.

+ +

JOËL: Yeah, it's how you feel appreciated, how you feel fulfilled. And just for our listeners who may not have read this book, I think the concept is that there are five ways that people like to receive appreciation.

+ +

STEPHANIE: Yeah, I think receive and both express appreciation and love. And quality time is one of them.

+ +

JOËL: Yeah, yeah. And the other four, if I remember correctly, are acts of service, words of affirmation, physical touch.

+ +

STEPHANIE: Gift-giving is the last one. Yeah, so that was a fun reflection on my part in being able to just know what makes me feel good. And then it also helps me communicate with other people how to work with me. I think that is super important. I love when people share with me what, I mean, I mentioned this earlier, just what drives them and how they like to be appreciated so that I can do my best to try to offer them that.

+ +

And I guess this actually is a good transition into the next value of mine that really drives me. I was thinking about this because I mentioned just now that I was learning some new React tools, new to me, anyway. And I'm like, yeah, I like learning. But then I was like; I don't know if I like learning the way other people like learning in the sense that it's not the knowledge itself or the process of learning itself that drives me but learning as a tool to better understand myself. So I think personal development is very important to me. And that feels different from how other people might value learning.

+ +

JOËL: Interesting. So you might be excited to learn a new React testing tool but not because you're chasing the latest, shiny tech but more because you feel like the process of learning this testing tool helps you learn something new about yourself.

+ +

STEPHANIE: Yeah, I think that sounds right. One of the tools specifically...we're using MSW Mock Service Worker for mocking network requests in Jest. And I was able to use information about testing in Rails and Ruby and apply that to this new tool. And I got to kind of revel in the fact that I could use previous learnings to apply in this new context, and that was really cool to me. So it wasn't necessarily the tool itself or even the process of learning but kind of realizing that I was capable of applying one thing to this less familiar thing.

+ +

JOËL: So kind of that realization that, hey, you're now far enough in your career, and you have enough experience. You have a broad base of knowledge that all of a sudden, you realize, wait a minute, I'm not starting from scratch anymore. I can apply lessons learned in the past to learn this new thing and make that easier. And that's a really validating feeling.

+ +

STEPHANIE: Exactly. That was really cool to me, and I felt really good afterwards. I think this week at work has been very uplifting because I've been having all these little mini-revelations if you will.

+ +

JOËL: I love that. I love that so much.

+ +

STEPHANIE: So, one thing that I think is very easily conflated with fulfillment is the idea of success. And I kind of want to talk about the distinction between success and fulfillment. Does that bring up any thoughts for you?

+ +

JOËL: Yes. I think the two are often entangled, but they're definitely not the same thing. It is possible to be fulfilled on a project that is not successful. And it's also possible to be on a successful project and yet not feel fulfilled. But oftentimes, the two go together because when things are going well on a project, they're probably also going well in a lot of other ways, and you might be feeling fulfilled as long as general parameters fit in, right? If values line up, things like that.

+ +

I know for me I value quality and excellence and doing work that I'm proud of. So I think if I were working at a place that was doing kind of low-quality, low-cost work where it's just like, you know what? You want cheap and low-quality? Come to us. We'll just get it done quick and cheap. And yeah, it's not going to be great, but you get what you pay for.

+ +

There's a reason this part of the market exists, and it's a totally valid way to build software. But I would not feel fulfilled there, even though maybe the clients are absolutely happy with the work that's being done. So I think that would be a situation where there is success, but I might not feel personally fulfilled.

+ +

STEPHANIE: Yeah, I'm glad you brought that up because I think I really struggled in the beginning of my consulting career with equating client happiness with success. And I'm now just starting to kind of unlearn that a little bit and realizing that success means different things to different people. So even if we talk about thoughtbot for just a second, one of thoughtbot's values as a company is seeking fulfillment in everything that we do.

+ +

And so even though, like you said, the client might be totally happy, for thoughtbot, that may not be a successful client engagement if you, Joël, as the developer staffed on that project, didn't find fulfillment. Because what's success for us here is that we are fulfilled in the project itself. And that was really helpful because, in some ways, I'm like, well, who cares? Who else cares besides me that I'm fulfilled? And to be like, oh, yeah, actually, what our collective success means is that I'm fulfilled, and you're fulfilled. That was really important to me and one thing that I really appreciate about working here.

+ +

JOËL: Fulfillment comes partly from our environment, from maybe the project that we're working on, our colleagues, but also comes to a certain extent from ourselves. And to a certain extent, we can drive that ourselves as well. And I think that first step is a certain amount of self-awareness and self-understanding. You are clearly a master at this. What are some things that you do to drive that self-understanding, to build maybe a sense of how you become fulfilled, and identifying those values that make you feel fulfilled on a project?

+ +

STEPHANIE: Listen, [laughs] I don't know if I would call myself a master at this, only that I'm very actively working on it in my life right now, in therapy, but also in talking to other people about this because, yeah, sometimes it has caused me a lot of turmoil. I'll be really stuck in a rut or feeling a lot of burnout, and that, ironically, actually motivates me to be like, how can this be different? And oftentimes, that means I have to look inward.

+ +

But you and I had a conversation last week off-mic that was really helpful for me because I was feeling really bummed about my client work and it not going the way that I thought it would. And your insight helped me think about the project a little differently and think about metrics of success differently. For that project, I could not expect that project to look exactly like all of my past experiences. And success for those projects were not the same for this project. So yeah, talking to others, I highly recommend that.

+ +

JOËL: I guess you mentioned that you read a lot of management books and a lot of books geared towards managers for discussing things like how to set up a one-on-one. Those are almost like...they're not really therapy, but they kind of lean a little bit towards that sometimes and trying to create fulfillment for your direct reports. So maybe seeing it from the other side helps you build understanding.

+ +

STEPHANIE: Yeah, actually, that's totally a great call out because I highly recommend reading books about [laughs] management, even if you're not interested in management. Only because there's no guarantee that you'll have a good manager who can do all those things for you, so if you can equip yourself for doing those things, then you are likely to have a better workplace experience, in my opinion.

+ +

JOËL: And I guess the obvious one that we have not talked about is if you do have a good manager, have these conversations with them.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: Part of their job is to help you be more fulfilled. And they should be having conversations to maybe help you discover those ways that you are feeling fulfilled at work and how to get there. Here's one aspect that we have not talked about that I'm curious to explore a little bit: recognition.

+ +

STEPHANIE: Ooh. Yeah, that's a good one.

+ +

JOËL: How important is it for you to feel recognized, either by your colleagues or by the more official org structure?

+ +

STEPHANIE: This is a great question. I do value recognition from people I trust. So I think we were talking about sometimes client projects are not successful, but you tried your best, and you did do valuable work. And you might not hear that from the client. They might think differently. But if a trusted co-worker can provide that validation for you, oftentimes, I find that more helpful.

+ +

JOËL: That's an interesting distinction. And I think recognition has a very different weight depending on the source it's coming from. If it's somebody you look up to, and they just give you a shout-out or something, I'm riding that high all day long.

+ +

STEPHANIE: Yeah, yeah, that's a great point. How do you like to receive recognition?

+ +

JOËL: Hmm. So at thoughtbot, we have an internal system where we can give shout-outs to each other. They're called high fives. And they get shared directly to the team Slack channel. And it's a small thing, but I really appreciate it when somebody calls out like, "Hey, I appreciated this thing that you did," or "This is the thing that had an impact on me," or "I appreciated the thing that you shared."

+ +

Those things make me feel really great. It's a small thing. It takes 30 seconds to do. But I really appreciate that. And it's something that I am looking to more intentionally do more of because it's fun to receive recognition, but it's also really valuable to give recognition.

+ +

STEPHANIE: Yeah, I'm with you. I am also trying to be intentional about being even more generous with my positive feedback for others. And I think there's also some degree of recognition and validation to give to yourself.

+ +

JOËL: Self-validation.

+ +

STEPHANIE: Yeah, yeah. I mean, I'm definitely trying to do more of that. Because if I'm doing work that lines up with my values, I want to be able to pat myself on the back for it, even if no one else will do it for me. [laughs]

+ +

JOËL: What does that look like? You're like standing in the mirror and saying, "Good job?"

+ +

STEPHANIE: [laughs]

+ +

JOËL: Do you have maybe a document where you kind of list the things that you feel proud of, even if nobody else has noticed? What does that look like for you?

+ +

STEPHANIE: Ooh, yeah, a brag document. I think some folks at thoughtbot have recommended doing that. For me, it's going and getting myself a treat.

+ +

JOËL: Oh, I like that.

+ +

STEPHANIE: So maybe like a latte the next morning or going to get just a sweet thing. Yeah, that's my way of doing it.

+ +

JOËL: So we've talked about self-recognition, recognition from colleagues. I think another element is recognition from management or the company that you're working at. That can be just praise. But oftentimes, I think when you're looking at recognition from something a little more corporate, it has a more kind of concrete aspect to it. And maybe that is come yearly evaluation time; there's a raise that recognizes the fact that you've done good work.

+ +

I know for me, last year, I got a big promotion. And I felt like I had been performing at a level that was kind of pretty far above and beyond the title that I had. And getting that promotion, in some ways, was very much kind of validation and recognition of the fact that I had been performing at that high level.

+ +

STEPHANIE: Yeah, it sounds like the acknowledgment for the expanded work that you've been doing was really motivating for you.

+ +

JOËL: Yeah. It's interesting you mentioned that acknowledgment is really motivating because it really is, and sometimes the reverse is also true. You feel discouraged or unmotivated because the good work that you're doing is not recognized. Are you familiar with the idea of intrinsic versus extrinsic motivation?

+ +

STEPHANIE: Yeah, I am. Being motivated by something externally, like someone offering a promotion, or a raise, or whatever, versus it coming from yourself.

+ +

JOËL: Yeah. And I think for many people, you're probably not purely motivated by one or the other. There are some things where you're motivated by your own internal values, as we mentioned earlier, and some things where you're motivated by incentives offered at work. And that balance will probably shift over time and in different moments. But having a little bit of both can be really, really powerful. If you can be living up to your values and then get rewarded for it, that's kind of peak fulfillment right there.

+ +

STEPHANIE: Yeah, that's the sweet spot. Yeah, I wish that for everyone in the world. [laughs] On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. [laughs]

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Stephanie has a win and a gripe from her client project this week. In a previous episode, Joël talked about his work exploring how to model dependent side effects, particularly D&D dice rolls. He went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs. Then it will roll all the dice necessary and tell you did you successfully hit your target and, if so, how much damage you did.

+ +

Together, they discuss how they think about fulfillment at work and what brings them fulfillment as developers.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 I have a win, I suppose, and a gripe from my client project this week that I would love to share. So my win is that I've been working in React lately. And I might have mentioned this on a previous episode, but it's been a few years for me. So I'm kind of catching up on the new, hot tooling, you know, whatever is popular in that world these days, and having to read a lot of documentation to figure out how to use it and just in general, I think being a little bit outside my comfort zone.

+ +

And I was working on an existing React component that was untested, and I had to change and extend some functionality in it. And we're also a little bit on a deadline. So there's like a little bit of pressure on the team to be delivering. And so when I got this ticket, I was like, okay, I am seeing this existing component that looks also a few years outdated. It's using some of the older technology that we've kind of moved on from.

+ +

And I was just like, oh, I really should write tests for this before I go in and change some things just to feel confident that my changes don't break anything because it was pretty gnarly. But I was not in the mood for it. [laughs] And this was like two or three days ago. I was just very grumpy. And I was like, oh man, why do I have to do it? [laughs] I kind of wanted to just get into making the changes so I could deliver on this work.

+ +

So, spoiler, I did not write the tests that day and just kind of went ahead with the changes. But then, the next morning, I woke up, and I was feeling inspired. I was like, I made those changes, but I'm actually not feeling that confident about it. So let me go back and try to write some tests. And I got to use the new tools I had been looking into, and that was part of my hesitation too. I was like, oh man, this is like a really old component.

+ +

And I don't want to use the older ones that we're using for testing. But how is it going to play with the newer testing tools that we're using? And so there was just like a lot of, I think, barriers to me feeling excited about writing those tests. But with my renewed energy, I did it. And I feel very happy about it and proud of myself. Yeah, that's my little win.

+ +

JOËL: That's a roller coaster of a journey there. That sort of deception when you find out that there are no tests for this and somebody else's problem has kind of become your problem. But then you decide you don't want it to be your problem, you know, kick it down the road for somebody else. And then you feel good about yourself, and you decide to backfill the test anyway. And you get that confidence, and now everything's better for everybody. That is quite the journey.

+ +

STEPHANIE: Exactly. I listened to another podcast recently where they coined this term called tantrum logic, which is basically the idea that when you're kind of grumpy or something happens, and you're like, man, I don't want to do any of this, like, if I can't do it my way, then I don't want to do it at all. [laughs]

+ +

And just the idea that the way you're thinking about the issue at hand may not be totally grounded in reality. And I think I needed that reset and just a good night's sleep and going to do something else to come back and be like, actually, I do want to write those tests, even if it will be challenging. I'm in a better mind space for it. Mind space? Headspace? [laughs] Headspace for it. And I overcame the tantrum logic.

+ +

JOËL: A good night's sleep is just such a powerful tool for resetting.

+ +

STEPHANIE: Yeah, I agree. Shout out to sleep. [laughs] It turns out that it can really have a positive effect on how you feel.

+ +

JOËL: By the way, this is not an advertisement. We are not sponsored by sleep. We just both love it and recommend it.

+ +

STEPHANIE: [laughs] To get into my gripe a little bit, so you and I are on the same client project we've mentioned before on the show. And I think I even talked a little bit about receiving a new computer from our client to do our client work on. So now I have many devices at home. And we had also chatted previously about a note-taking app that we both use called Obsidian.

+ +

And one of the reasons that I really like it is because it's all local storage. So your notes are not being uploaded to the cloud or whatever. But that does make it hard to use on multiple, I mean, not just hard, impossible to use [laughs] on multiple devices unless you pay for it. They have a sync offering where you can use it on multiple devices. And I think it's also encrypted in a certain way.

+ +

Anyway, sometimes I'll be working on my client laptop and have some idea or thought that I really want to note down, but I don't have Obsidian installed on this machine, and it's not synced to my other Obsidian. And I have just been kind of annoyed about having to go open another computer to write a thought down if I want to document it. And I'm curious how you deal with this problem.

+ +

JOËL: So the downside of Obsidian not being a cloud product is that you don't just get that sync for free. The upside of it just being markdown files on your hard drive is that you can use any other product or tool that you want to manipulate these files. So I have my Obsidian vault, which is just the term for the directory where it keeps all of these files in a Dropbox directory. And so I have it sync across multiple machines just by being signed into my Dropbox account.

+ +

STEPHANIE: That's smart. And that sync is pretty smooth for you? You don't have any issues with updating it in one spot and seeing those changes in another?

+ +

JOËL: I have not had issues with that. Of course, I'm not jumping between machines within 30 seconds of each other. Generally, I'm also connected to the internet. So I haven't had a situation where I make a change to a machine not connected to the internet, and then later on, I edit an old version on a different machine that is connected to the internet, and now we have conflict. I've not run into that problem.

+ +

STEPHANIE: Okay, cool. That sounds good. It's funny you mentioned that because it's just the other day, off-mic; you and I were on a call doing a little bit of pairing. And you were on both machines at the same time [laughs] because we had to use one for our call. And then you were looking something up on your client computer as well. And the thought of you just using two computers at once was very amusing to me.

+ +

JOËL: It's the ultimate hacker move in...I was going to say bad, but that's maybe a little bit too judgmental, but yeah, in classic, I feel like police shows, things like that.

+ +

STEPHANIE: I do have one more thought about note-taking that we haven't talked about before. But I'm really curious, how do you deal with thoughts you have on the road during a time you don't have a device on you? Do you go and write that down somewhere, or what do you do with those?

+ +

JOËL: I have an absolutely awful solution, which is I add it to my mental stack and hope it doesn't overflow before I get to a computer.

+ +

STEPHANIE: That's really funny because I used to do something similar where if I had a to-do list or something like that in my head, I would remember the number of items on my list to try to cue me into remembering what those items were. The worst thing that would happen is I would remember that I had three things on my to-do list but could only remember two. And so I had to just [laughs] deal with my existential anxiety about knowing that there was something else that I had forgotten about but could not remember [laughs] for the life of me what it was.

+ +

JOËL: So I do that trick sometimes for my grocery list if I don't want to write it down. I'll just be like, oh yeah, go to the grocery store, make sure there are five items in my basket when I check out. And similar to you, sometimes I have that problem. I had a light-bulb moment the other day, which is that this trick is actually an example of hashing content.

+ +

STEPHANIE: [laughs]

+ +

JOËL: So if you're ever hashing the contents of a file and then wanting to compare if another file is the same and you check the hashes are the same. In a sense, you're kind of hashing your grocery list and your shopping cart and trying to see do they both hash to the same value? Now, a good hashing algorithm has an infinitesimally low chance of a collision. Counting the number of items in your list or cart has a fairly high chance of a collision. You could have a cart and a list that both have five items, but they're not the same items. Yet this comparison would still make you think that they're the same.

+ +

STEPHANIE: This is a very funny metaphor to me. I think the other issue is that as a human and not a computer, I do not have the mental storage space to then also remember what algorithm [laughs] I'm using to hash my to-do list.

+ +

JOËL: The algorithm is the count function.

+ +

STEPHANIE: [laughs] True, true, a more sophisticated algorithm then. [laughs]

+ +

JOËL: Yes, which is why I keep using this not very safe, but it's good enough.

+ +

STEPHANIE: Sometimes, we just need to be good enough. So, Joël, what's new in your world?

+ +

JOËL: So, in a previous episode, I think we talked about some work I was doing exploring how to model dependent side effects, particularly D&D dice rolls. So this week, I went from the theoretical to the practical and wrote up a miniature D&D damage dice roll app that you put in a few inputs, and then it will roll all the dice necessary and tell you did you successfully hit your target, and if so, how much damage did you do? And it takes into account all these edge cases.

+ +

STEPHANIE: Cool. That's so exciting because I think we mentioned last time how that would be a really interesting exercise to write up that code. Did you get any insight from doing that?

+ +

JOËL: I think a lot of the insight that I got came from the initial diagramming phase. And I think coding it out really solidified the things that I had learned from the diagramming. Of interest here is that there are effectively or potentially four separate dice-rolling phases that can happen. First, you're rolling to see can you hit your target? And depending on the situation, you're rolling one or two dice.

+ +

And then after that, you're rolling to see if you do hit, how much damage you do. And you're either rolling one set of dice, or you might be rolling two sets of dice if you happen to do a critical hit. So I think that the diagram that I had clearly showed these are four sets of randomness that have to happen and then how they relate to each other. These two are dependent on each other; these two are independent.

+ +

I think one thing that was really interesting that I learned from the code is that for something like a dice roller, you usually don't want to see just the result. Because if I just have a button that says how much damage did I do, and then I get a number back that says, "You did zero damage," or "You did three damage," as a person, that's not very satisfying. And I don't know that I fully trust it. I want to see all the intermediate results. So I want to see, oh, did I roll two different dice for that initial two-hit? What were the numbers?

+ +

And then I can say, okay, well, I need to roll above a five or roll above a 10. And I rolled these two dice, and they were both under 10. That makes sense why I didn't hit. Or I rolled one of them above and one of them below, but I was rolling with disadvantage, which means I have to take the lower of the two numbers. So I could have hit, but I didn't. So I think that is really fun as a user to see the intermediate steps. But also, as a developer, it helps me to be confident that the code I wrote works the way I expect it to.

+ +

STEPHANIE: Yeah, that's really neat. I think what I love about this is that you took something that, in some ways, could be really simple, right? And the implementation could have been just the first thing that you thought of, but you thought very deeply about it and made the dice roller that you wanted in the world. [laughs] I'm curious. Can anyone go check out this repo on the internet?

+ +

JOËL: Yes. So we can link to the repo in the show notes. And also, the dice roller itself is up online at dnd-damage-roller.netlify.app. And we can link that as well for anybody who wants to go and check it out.

+ +

STEPHANIE: Awesome.

+ +

JOËL: I think my goal in this is it's more of a learning exercise. I don't think the world needs another D&D dice roller. There are better ones built into more comprehensive tools. But it was fun for me to work on this, to explore some ideas, and to dig into randomness. I've always had a fascination with random rolls.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So it sounds like the Dice Roller app really scratched an itch for you and was a fulfilling exercise for you and just exploring randomness, like you mentioned, and just a theory that you had about writing good code. I'm curious about how you think about fulfillment at work in general and what brings you fulfillment as a developer.

+ +

JOËL: Fulfillment is really interesting because I think it's a really kind of personal question. It probably varies a little bit from person to person. But there are probably also some aspects that are global to everyone. I know we've talked about things like psychological safety in the past. And if you don't have things like that, that baseline, it's going to be hard to feel fulfilled.

+ +

STEPHANIE: Yeah, I agree. I am thinking of Maslow's hierarchy of needs, and in some ways, fulfillment is kind of the tip of the pyramid. If you are feeling safe and like you belong and get enough sleep, like we mentioned earlier, you can reach towards getting into what really feels fulfilling and gives you purpose in life.

+ +

JOËL: I love that you brought up Maslow's pyramid because like you said, that top part is self-actualization. So you need all those lower layers before you can actually reach the point of true fulfillment on the job. One thing I recently realized about myself is how I tend to approach projects that are in a difficult place. I find a lot of fulfillment in sort of relative change. It doesn't matter if a project is in a bad place as long as the project on a week-by-week basis is moving in the right direction. It might still be in a bad place, but is it better than last week? And was I a part of making that better? That makes me feel good.

+ +

STEPHANIE: Yes. I have always really admired your optimism around that and how you share even small wins. You're really good about that, actually, and celebrating that. And it's interesting to learn that it's like that process itself that has a lot of meaning for you. Because I think I'm a little bit different in the sense that I have an ideal version of working in my head, and if we're not there, even if we are making some incremental progress week to week, I think I struggle.

+ +

Sometimes I feel frustrated or stressed because I think that we're just not where I want to be. And I've definitely been thinking about harnessing some of that optimism and celebration that you have around, just making things better a little bit at a time.
+JOËL: And I think we should be clear that this is not the way one has to be; this is just how I tend to feel on projects.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I know there are plenty of people who feel most fulfilled when they're on projects where things are mostly good. And then it's not about incremental improvement in the product, but maybe it's shipping a lot of features and feeling like they're moving very quickly. Maybe it's that feeling of speed that gives them fulfillment rather than the feeling of incremental progress.

+ +

STEPHANIE: Yeah, absolutely. I think what is helpful for me in hearing about this from you and just from others (I love talking to other people and learning about what motivates them.) is seeing what else is possible outside of my own little universe inside my head and doing the self-reflection to be like, okay cool, this works for Joël, but maybe this doesn't work for me. But having the input from other people lets me discover more about myself in that way.

+ +

JOËL: That is incredibly powerful. I love that. I think in a variety of aspects of my life, but especially when it comes to fulfillment in software and at work, talking to other people, seeing how they relate to a project or to a particular task, and, like you said, getting to see their perspectives that are sometimes totally different than mine.

+ +

STEPHANIE: Yeah, absolutely. So you just mentioned one aspect of how you find fulfillment when a project is maybe in a tougher spot than usual. I'm curious if you can recall a time that you've been the most fulfilled at work.

+ +

JOËL: Most fulfilled. I think one of the most fulfilling projects I did was several years ago. We built a dashboard for just exploring a lot of data from medical studies. And so the researchers would upload some time series data for things like heart rate, or skin electro-sensitivity, a bunch of other things, along with a video. It was a kind of an interview-style situation. They were doing a session with a patient.

+ +

And we would then sync all of these data streams up. We would sync it up to the video, and then you could kind of explore the data. There were scrubbers, so you could kind of scrub through the video, and it would scrub through the time series data all at the same time in sync. You could scrub through the time series data. It would sync the video kind of like bidirectional. You could zoom in on the data.

+ +

The idea is this is a high-level kind of exploratory tool. And you could then find the interesting bits of data that you could then do more quantitative analysis on. So you could then find a part of the stream and say, this is the interesting part. Clip from 10:55 to 11:10 in the stream, on all streams, and then export just that data in a zip file. And then I'm going to put that through a bunch of math and figure out, oh, is there a correlation between these moments?

+ +

STEPHANIE: So what about that project was really exciting or fun for you?

+ +

JOËL: I think the client was incredibly fun to work with. There was like an energy and excitement. This was part of their, I think, Ph.D. thesis. And they were really excited. They were incredibly knowledgeable, just delightful to work with. I think this was a fun...so we built this from scratch. It was a greenfield app. I think it had a lot of interactivity. It had a lot of visuals. It was one of the first projects I got to work on that used Elm. I think all those things combined to just make it a really fun project to work on.

+ +

It was also a fairly short project. So we had a very kind of tight deadline. We were very pragmatic with absolutely everything on there. Like, what can we do to get this done quickly? Is this feature worth the time? It was kind of a classic MVP product. And I think it was one of the most fun things I've built.

+ +

STEPHANIE: Cool. I'm also hearing there was probably some creative aspect of it that was really fulfilling for you, like exploring a lot of new things. Like, you said, you were working with Elm for the first time. And the project itself sounds very different from some of our other more typical consulting engagements and also the collaboration aspect. Like, you mentioned the tight deadline, which compelled you all to work really closely together to make this really cool thing in that short amount of time.

+ +

JOËL: Exactly. Yeah, it was like a three or four-week project that I look back on really fondly. Like, oh, that was a good time with those two colleagues and that client, and we did a thing. It was really cool.

+ +

STEPHANIE: That's awesome.

+ +

JOËL: I think it's really interesting that just hearing that story, you're immediately picking up on, like, oh, I see elements of creativity and exploration. Do you have kind of an internal system that you use to analyze projects that you're on to be like, oh, this is a project I'm enjoying because of this element or that? Because you seem very self-aware around these types of things.

+ +

STEPHANIE: I'm glad you asked that because I think I was trying to reflect back to you some of the things that I picked up about what you were sharing. I have been reading a book, surprise, surprise.

+ +

JOËL: What? You read?

+ +

STEPHANIE: I read. [laughs] It's called "Engineering Management for the Rest of Us" by Sarah Drasner. And I am not an engineering manager, and I don't necessarily know if I even want to be. But I really enjoy reading management books to better understand how to manage myself or how to be a person who is managed.

+ +

And one of the things she talks about is understanding an individual's values and how those things end up being what motivates them and also likely what brings fulfillment. And so after I learned about the value of values, I started thinking, okay, what is it that I am motivated by? And really reflecting on when I have felt really good about work and also when I felt challenged or unhappy at work and what things were missing during that time.

+ +

So the things that I have realized that I am very motivated by are human connection. I love spending quality time with people, and that is probably why I enjoy pairing so much. But also, in my one on ones with my manager, I really enjoy that time just being time for us to share space and get to know each other and talk. It doesn't necessarily need to be going through agenda items or a status report or even necessarily talking about my project.

+ +

JOËL: So you mentioned that you value quality time with others. Is that a reference to "The Five Love Languages" concept?

+ +

STEPHANIE: It is. It is. I think I also made a bit of a connection there too because what I like in my personal relationships also obviously applies to work.

+ +

JOËL: Yeah, it's how you feel appreciated, how you feel fulfilled. And just for our listeners who may not have read this book, I think the concept is that there are five ways that people like to receive appreciation.

+ +

STEPHANIE: Yeah, I think receive and both express appreciation and love. And quality time is one of them.

+ +

JOËL: Yeah, yeah. And the other four, if I remember correctly, are acts of service, words of affirmation, physical touch.

+ +

STEPHANIE: Gift-giving is the last one. Yeah, so that was a fun reflection on my part in being able to just know what makes me feel good. And then it also helps me communicate with other people how to work with me. I think that is super important. I love when people share with me what, I mean, I mentioned this earlier, just what drives them and how they like to be appreciated so that I can do my best to try to offer them that.

+ +

And I guess this actually is a good transition into the next value of mine that really drives me. I was thinking about this because I mentioned just now that I was learning some new React tools, new to me, anyway. And I'm like, yeah, I like learning. But then I was like; I don't know if I like learning the way other people like learning in the sense that it's not the knowledge itself or the process of learning itself that drives me but learning as a tool to better understand myself. So I think personal development is very important to me. And that feels different from how other people might value learning.

+ +

JOËL: Interesting. So you might be excited to learn a new React testing tool but not because you're chasing the latest, shiny tech but more because you feel like the process of learning this testing tool helps you learn something new about yourself.

+ +

STEPHANIE: Yeah, I think that sounds right. One of the tools specifically...we're using MSW Mock Service Worker for mocking network requests in Jest. And I was able to use information about testing in Rails and Ruby and apply that to this new tool. And I got to kind of revel in the fact that I could use previous learnings to apply in this new context, and that was really cool to me. So it wasn't necessarily the tool itself or even the process of learning but kind of realizing that I was capable of applying one thing to this less familiar thing.

+ +

JOËL: So kind of that realization that, hey, you're now far enough in your career, and you have enough experience. You have a broad base of knowledge that all of a sudden, you realize, wait a minute, I'm not starting from scratch anymore. I can apply lessons learned in the past to learn this new thing and make that easier. And that's a really validating feeling.

+ +

STEPHANIE: Exactly. That was really cool to me, and I felt really good afterwards. I think this week at work has been very uplifting because I've been having all these little mini-revelations if you will.

+ +

JOËL: I love that. I love that so much.

+ +

STEPHANIE: So, one thing that I think is very easily conflated with fulfillment is the idea of success. And I kind of want to talk about the distinction between success and fulfillment. Does that bring up any thoughts for you?

+ +

JOËL: Yes. I think the two are often entangled, but they're definitely not the same thing. It is possible to be fulfilled on a project that is not successful. And it's also possible to be on a successful project and yet not feel fulfilled. But oftentimes, the two go together because when things are going well on a project, they're probably also going well in a lot of other ways, and you might be feeling fulfilled as long as general parameters fit in, right? If values line up, things like that.

+ +

I know for me I value quality and excellence and doing work that I'm proud of. So I think if I were working at a place that was doing kind of low-quality, low-cost work where it's just like, you know what? You want cheap and low-quality? Come to us. We'll just get it done quick and cheap. And yeah, it's not going to be great, but you get what you pay for.

+ +

There's a reason this part of the market exists, and it's a totally valid way to build software. But I would not feel fulfilled there, even though maybe the clients are absolutely happy with the work that's being done. So I think that would be a situation where there is success, but I might not feel personally fulfilled.

+ +

STEPHANIE: Yeah, I'm glad you brought that up because I think I really struggled in the beginning of my consulting career with equating client happiness with success. And I'm now just starting to kind of unlearn that a little bit and realizing that success means different things to different people. So even if we talk about thoughtbot for just a second, one of thoughtbot's values as a company is seeking fulfillment in everything that we do.

+ +

And so even though, like you said, the client might be totally happy, for thoughtbot, that may not be a successful client engagement if you, Joël, as the developer staffed on that project, didn't find fulfillment. Because what's success for us here is that we are fulfilled in the project itself. And that was really helpful because, in some ways, I'm like, well, who cares? Who else cares besides me that I'm fulfilled? And to be like, oh, yeah, actually, what our collective success means is that I'm fulfilled, and you're fulfilled. That was really important to me and one thing that I really appreciate about working here.

+ +

JOËL: Fulfillment comes partly from our environment, from maybe the project that we're working on, our colleagues, but also comes to a certain extent from ourselves. And to a certain extent, we can drive that ourselves as well. And I think that first step is a certain amount of self-awareness and self-understanding. You are clearly a master at this. What are some things that you do to drive that self-understanding, to build maybe a sense of how you become fulfilled, and identifying those values that make you feel fulfilled on a project?

+ +

STEPHANIE: Listen, [laughs] I don't know if I would call myself a master at this, only that I'm very actively working on it in my life right now, in therapy, but also in talking to other people about this because, yeah, sometimes it has caused me a lot of turmoil. I'll be really stuck in a rut or feeling a lot of burnout, and that, ironically, actually motivates me to be like, how can this be different? And oftentimes, that means I have to look inward.

+ +

But you and I had a conversation last week off-mic that was really helpful for me because I was feeling really bummed about my client work and it not going the way that I thought it would. And your insight helped me think about the project a little differently and think about metrics of success differently. For that project, I could not expect that project to look exactly like all of my past experiences. And success for those projects were not the same for this project. So yeah, talking to others, I highly recommend that.

+ +

JOËL: I guess you mentioned that you read a lot of management books and a lot of books geared towards managers for discussing things like how to set up a one-on-one. Those are almost like...they're not really therapy, but they kind of lean a little bit towards that sometimes and trying to create fulfillment for your direct reports. So maybe seeing it from the other side helps you build understanding.

+ +

STEPHANIE: Yeah, actually, that's totally a great call out because I highly recommend reading books about [laughs] management, even if you're not interested in management. Only because there's no guarantee that you'll have a good manager who can do all those things for you, so if you can equip yourself for doing those things, then you are likely to have a better workplace experience, in my opinion.

+ +

JOËL: And I guess the obvious one that we have not talked about is if you do have a good manager, have these conversations with them.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: Part of their job is to help you be more fulfilled. And they should be having conversations to maybe help you discover those ways that you are feeling fulfilled at work and how to get there. Here's one aspect that we have not talked about that I'm curious to explore a little bit: recognition.

+ +

STEPHANIE: Ooh. Yeah, that's a good one.

+ +

JOËL: How important is it for you to feel recognized, either by your colleagues or by the more official org structure?

+ +

STEPHANIE: This is a great question. I do value recognition from people I trust. So I think we were talking about sometimes client projects are not successful, but you tried your best, and you did do valuable work. And you might not hear that from the client. They might think differently. But if a trusted co-worker can provide that validation for you, oftentimes, I find that more helpful.

+ +

JOËL: That's an interesting distinction. And I think recognition has a very different weight depending on the source it's coming from. If it's somebody you look up to, and they just give you a shout-out or something, I'm riding that high all day long.

+ +

STEPHANIE: Yeah, yeah, that's a great point. How do you like to receive recognition?

+ +

JOËL: Hmm. So at thoughtbot, we have an internal system where we can give shout-outs to each other. They're called high fives. And they get shared directly to the team Slack channel. And it's a small thing, but I really appreciate it when somebody calls out like, "Hey, I appreciated this thing that you did," or "This is the thing that had an impact on me," or "I appreciated the thing that you shared."

+ +

Those things make me feel really great. It's a small thing. It takes 30 seconds to do. But I really appreciate that. And it's something that I am looking to more intentionally do more of because it's fun to receive recognition, but it's also really valuable to give recognition.

+ +

STEPHANIE: Yeah, I'm with you. I am also trying to be intentional about being even more generous with my positive feedback for others. And I think there's also some degree of recognition and validation to give to yourself.

+ +

JOËL: Self-validation.

+ +

STEPHANIE: Yeah, yeah. I mean, I'm definitely trying to do more of that. Because if I'm doing work that lines up with my values, I want to be able to pat myself on the back for it, even if no one else will do it for me. [laughs]

+ +

JOËL: What does that look like? You're like standing in the mirror and saying, "Good job?"

+ +

STEPHANIE: [laughs]

+ +

JOËL: Do you have maybe a document where you kind of list the things that you feel proud of, even if nobody else has noticed? What does that look like for you?

+ +

STEPHANIE: Ooh, yeah, a brag document. I think some folks at thoughtbot have recommended doing that. For me, it's going and getting myself a treat.

+ +

JOËL: Oh, I like that.

+ +

STEPHANIE: So maybe like a latte the next morning or going to get just a sweet thing. Yeah, that's my way of doing it.

+ +

JOËL: So we've talked about self-recognition, recognition from colleagues. I think another element is recognition from management or the company that you're working at. That can be just praise. But oftentimes, I think when you're looking at recognition from something a little more corporate, it has a more kind of concrete aspect to it. And maybe that is come yearly evaluation time; there's a raise that recognizes the fact that you've done good work.

+ +

I know for me, last year, I got a big promotion. And I felt like I had been performing at a level that was kind of pretty far above and beyond the title that I had. And getting that promotion, in some ways, was very much kind of validation and recognition of the fact that I had been performing at that high level.

+ +

STEPHANIE: Yeah, it sounds like the acknowledgment for the expanded work that you've been doing was really motivating for you.

+ +

JOËL: Yeah. It's interesting you mentioned that acknowledgment is really motivating because it really is, and sometimes the reverse is also true. You feel discouraged or unmotivated because the good work that you're doing is not recognized. Are you familiar with the idea of intrinsic versus extrinsic motivation?

+ +

STEPHANIE: Yeah, I am. Being motivated by something externally, like someone offering a promotion, or a raise, or whatever, versus it coming from yourself.

+ +

JOËL: Yeah. And I think for many people, you're probably not purely motivated by one or the other. There are some things where you're motivated by your own internal values, as we mentioned earlier, and some things where you're motivated by incentives offered at work. And that balance will probably shift over time and in different moments. But having a little bit of both can be really, really powerful. If you can be living up to your values and then get rewarded for it, that's kind of peak fulfillment right there.

+ +

STEPHANIE: Yeah, that's the sweet spot. Yeah, I wish that for everyone in the world. [laughs] On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. [laughs]

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+biHRcRGs + + ]]> + + Joël Quenneville + Stephanie Minn + + + 375: Deleting Code + https://bikeshed.thoughtbot.com/375 + d42d7dfc-f93a-46b6-b058-0d383646b51e + Tue, 14 Mar 2023 00:15:00 -0400 + thoughtbot + + full + thoughtbot + The idea of deleting code has been swimming around in Stephanie's brain recently because she's been feeling nervous about it. Together, Joël and Stephanie explore ways of gaining confidence to delete code while feeling good about it. + 31:19 + no + + + thoughtbot had an in-person Summit in the UK! Joël recalls highlights. Stephanie is loving daily sync meetings on a new project. +The idea of deleting code has been swimming around in Stephanie's brain recently because she's been feeling nervous about it. Together, Joël and Stephanie explore ways of gaining confidence to delete code while feeling good about it. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Thoughtbot summit video (https://www.youtube.com/watch?v=6d7gUq5J-ck) +Gather Town (https://www.gather.town/) +Sustainable Rails episode (https://www.bikeshed.fm/368) +Chelsea Troy on deleting features (https://chelseatroy.com/2021/01/21/reducing-technical-debt/) +Unused (https://unused.codes/) +elm-review-unused (https://package.elm-lang.org/packages/jfmengels/elm-review-unused/latest/) +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 today, 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: I just got back from a few days in the UK, where thoughtbot has been having an in-person Summit, where we've brought people from all over the company together to spend a few days just spending time with each other, getting to know each other, getting to connect in person. +STEPHANIE: That sounds like it was a lot of fun. I've been hearing really great things about it from folks who've come back. Unfortunately, I couldn't make it this year. I got sick a little bit beforehand and then ended up not being able to go. But it sounds like it was a lot of fun just to get together, especially since we're now a remote company. +JOËL: Yeah, I'm really sorry you weren't able to make it there. It would have been amazing to do a Bike Shed co-hosts get-together. +STEPHANIE: I know. In the same room, maybe even record. What a concept. [laughs] +JOËL: So thoughtbot is a fully remote company, and so that means that getting a chance to have people to come together and build those in-person connections that you don't get, I think, is incredibly valuable. I was really excited to meet both the people that I work with and that I see on my screen every day and people who I don't talk to as often because they're working on different teams or different departments even. +STEPHANIE: What was one highlight of the time you spent together? +JOËL: I'll give a couple of highlights, one I think is more on the activity side. We went bouldering as a group. This was a really popular activity. We were trying to sign up people for it, and it was so popular we had to make two groups because there were too many people who were interested. And it was really fun. There are people with a whole variety of skill levels. Some people, it was their first time, some people had been doing it for a while. And just getting together and solving problems was a lot of fun. +STEPHANIE: Yes, I saw that. That was one of the things I was really looking forward to doing when I was still thinking that I was going to go. And it's cool that it had opportunities for both beginners and people who have been doing it before, which I think, if I recall correctly, Joël, you are a boulderer yourself back home. So that's pretty neat that you were able to, yeah, I don't know, maybe share some of that experience IRL too. +JOËL: Yeah, yeah, I think it's great because people were able to help each other. Sometimes you have a different perspective down on the ground than you do up on the wall. And then, in my case, because I've done it a lot, I know a little bit of actual climbing technique. And so I can give some tips on, like, oh, if you're stuck and you don't know how to get past a particular point, or you don't know how to start a particular climb, or your arms are getting tired halfway up, here's maybe a small change you can make that would make things easier for you. +STEPHANIE: Honestly, that also sounds like a really good metaphor for pair programming, [laughs] like, looking at things from different perspectives, you know, someone who's on the wall? I don't know what the lingo is. But it's the equivalent of someone driving in coding, the navigator having a little more perspective and being able to point out things that they might not see that's right in front of them. +JOËL: I love that metaphor. Now I'm going to think of that both when I pair and the next time I climb. +STEPHANIE: I love it. +JOËL: I think climbing, when I do it, it's always more fun with a friend, specifically for what you were saying. I climb alone sometimes, but as much as possible, I'll reach out to another friend who climbs and say, "Hey, let's climb together." And then we can alternate on the same route even. +STEPHANIE: That's cool. I didn't realize that it could be such a social activity. +JOËL: It is very much a social activity, and I think that's part of the fun of it. It's challenging physically but also mentally because it's a puzzle that you solve. But then also, it's a thing that you do with friends. +I think another aspect that was a highlight for me was getting a chance to connect with people from other teams, other departments within thoughtbot. I think one thing that was really nice when we were located in an office is that over lunch, or just at the water cooler, or whatever, you would connect with people who were in other teams and who were in different departments. +So I might talk to people in People Ops, or in marketing, in operations just sort of in the natural course of the day in a way that I think I don't do quite as much of now that we're more remote. And I tend to talk more with other developers and designers on my team. So I think that was really great to connect with people from other teams and other departments within the company. +STEPHANIE: Yeah, I know what you mean. I think I really miss the spontaneous, organic social interaction that you get from working in an office. And I think we've maybe talked about remote work on the podcast before, or previous co-hosts Steph and Chris have also talked about remote work. But it definitely requires a lot more intention to manifest those connections that otherwise would have been a little more organic in person. +And so, while you all were at an in-person summit in the UK, there was also a virtual summit hosted for folks who weren't able to travel this time around, and I really appreciated that. I got to spend a day just connecting with other people in Gather Town, which is a web app that's like a virtual space where you have little avatars, and you can run around and meet up with people into virtual meeting rooms on this map. [laughs] I'm not really sure I'm describing it well, but it's very cute. It is almost like a little video game. +It's like a cross between a video game and video conferencing [chuckles] software. But yeah, I think I just really appreciated how inclusive thoughtbot has been doing remote work where, like, yes, we really value these in-person gatherings, and we understand that there is a bit of magic that comes from that, but also making sure that no one's left out. And at the end of the day, not everyone can make it, but we were still able to hang out and socialize amongst ourselves in a different way. +JOËL: Agreed. I think that inclusivity is part of what makes thoughtbot such a great place to work at. +STEPHANIE: Speaking of inclusivity, I mentioned a few weeks ago that I joined a new project recently and had been going through the onboarding and hopping into all these new meetings. One thing that I've really enjoyed about this new client team that I'm on is that in their daily sync meetings, we all share what we're working on. But we also all share something that's new to us, which is a little bit meta because we do that on this podcast. [laughs] +But each person just shares maybe something they learned at work but also usually something just totally not work related like a new show that they're watching. There's another person on my team who learns a lot of things from YouTube videos. And so he's always telling us about the new thing he learned about, I don't know, like mushrooms or whatever, or AI [laughs] through YouTube. And yeah, someone else might show a sweater that they just knit themselves. And it's been a very easy way to get to know people, especially when you're meeting a whole new team. And yeah, I've been enjoying it a lot. It's made me feel very welcome and like I know them as people outside of work. +JOËL: I love that. Yeah, they're more than just people you're shipping code with. You're able to build that connection. And it sounds like that helps smooth the...maybe we can say the social aspect of onboarding. Because when you onboard onto a project, you're not just onboarding onto a series of codebases and tools; you're also onboarding onto a team, and you need to get to know people and build relationships. +STEPHANIE: Yeah, absolutely. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So you've been...is it two weeks in a new codebase? Have you gone and deleted any code yet? +STEPHANIE: I wish. I am glad you asked this question because this has been a topic that has been swimming around in my head a little bit lately because this new client codebase it's very big and it's quite old. Like, I've been seeing code from 10 years ago. And it's been a really challenging codebase to get onboarded into, actually, because there's so much stuff. +In fact, I recently learned that some of their model specs are so big that they have been split out into up to seven different files to cover specs for one model. [laughs] So that has been a lot to grapple with. And I think in my journeys working on a starter ticket, I've just stumbled upon stuff that is very confusing. And then I might follow that thread only to realize that, like, oh, this method that I spent 20 minutes trying to grok turns out it's not actually used anywhere. +JOËL: That's a lot of dead code. +STEPHANIE: It is a lot of dead code, but I am also not quite feeling confident enough to delete it because I'm new, because I have no idea what consequences that might have. So, yeah, the idea of deleting code has just kind of been swimming around in here because ideally, we would be able to, but, for some reason, I don't know, at least for me, I feel very nervous about it. So it hasn't been something that I've reached for. +JOËL: That's a great question because I think in maybe Ruby, in particular, it's not always obvious if code is being used or not. When you do find yourself deleting code, how do you gain the confidence that it was safe to delete that? +STEPHANIE: Yeah, that's a good question. In the past, when I've done it successfully, I'll probably post a Slack message or something and being like, hey, I noticed this code is not being used anywhere, or I'd like to delete it because why, like, I don't know, because it's been misleading me because it's just not providing any value. And then kind of give it like a day or two, and if no one speaks up about it, then I will usually go ahead. +And obviously, get some code review, hopefully, get some other eyes on it just to make sure that whatever assumptions I made were valid, and then go for it. And then just watch [laughs] the deployment afterwards and make sure that there are no new errors, you know, no new complaints or anything like that. And, yeah, I think that has been my process, and I've definitely found success doing that. +But I have also experienced a bad result [laughs] from doing that where one time, on my last client project, we were refactoring the signup flow. And we realized that after you signed up, you were redirected to this blank page for like 10 seconds or something. It was completely empty. There was nothing on it except a spinner, I think. [laughs] And then it would then redirect you to the dashboard of the app. And we were like, oh, we can definitely delete this. We have no idea what this is doing. We don't want to try to refactor this as part of the effort that we were doing. +And so we deleted it, only to find out later from the marketing team that they had been using that page for something Google Analytics related, and we had to revert that change. And it was a real bummer because I think when we removed it, we felt good about that. We were like, oh yes, deleting code, awesome. And then having to bring it back without a clear plan of how to actually fix the problem that we were trying to solve was a bit of a bummer. +JOËL: So, as programmers, we're hired to write code. Why does it feel so good to do the opposite of that, to delete code? +STEPHANIE: That's a great question. I actually want to know what you think about this, but before that, I wanted to plug this Slack channel that we have at thoughtbot called Dead Code Society, where people can post their PR diffs showing more red than green, so more lines removed than lines added. And I have been really enjoying that Slack channel. It's very delightful. [laughs] But, Joël, do you have any thoughts about why it feels so good to delete code? +JOËL: There are probably a few different reasons. Especially when it's not your own code, you're often not attached to it. There's often, I think, the sense when you go into an existing codebase you're just like, oh, everything's just bad, and I don't understand it. And those other coders who wrote this didn't know how to do their job and kind of be the curmudgeon character. So it just kind of feels good to remove that and maybe rewrite it yourself. I would say that's not a good mindset to go in for deleting code. I think there are positive ways where it is actually a good thing. +STEPHANIE: That's fair. Just removing code because you would write it differently is not necessarily a net positive. [laughs] +JOËL: But I think...so when I initially asked the question, I said, "We're hired to write code." And I think that's a bit of a false assumption built into the question. We're not hired to write code. We're hired to solve problems, to build solutions. And as much as code can be an asset in solving problems, it's also a liability. And code has varying maintenance costs that are typically not low. They vary from expensive to very expensive. And so any chance we get to remove some of that, we're removing some of the carrying costs, to use a term that we discussed a few episodes back when we talked about sustainable Rails. +STEPHANIE: Yeah, absolutely. One thing that I remember you sharing about the client project that we're both on in the past is they have a very cumbersome test suite. And in some situations, you have wanted to advocate for deleting some of those tests. +JOËL: Deleting tests is a really, I think, spicy take because you're trying to get better test coverage. And if your test coverage isn't great, you don't want to lose any of that. So there's definitely a loss aversion there, and we might need it later. At the same time, tests have a cost, cost to run, cost to maintain. And if they're not providing a lot of value, then the cost of keeping them around might be higher than any kind of benefit they're giving you. +And I think a classic case of this is tests that have either been marked pending in the codebase with an exit or something like that or that have been marked in your CI server as muted; just ignore failures from this test. Because now you're still having to maintain, still having to execute these tests. They're costing you time, but they're giving you zero benefit. And they're just taking up space in your codebase, making it harder to read. So if you can't get these tests back into the point where they're actually executing, and you're caring about the output, then you probably don't need those tests, and they can be removed. +STEPHANIE: Yeah, that's fair. I'm thinking about the perspective of someone who does not want to delete those tests. I think in the past, I've seen it and even felt it myself as someone who probably wrote the tests, kind of hoping for some ideal world where I will finally have time to go back to that test. And I already put a lot of effort into trying to make it work, and I want to make it work. I want to have the value of that test. +And it's kind of like a sunk cost fallacy a little bit where it's like, I already spent however much time on it that it must have some kind of value. Because just hearing that someone else wants to delete the test can kind of hurt a little bit. [laughs] And it's tough. I do think that it's easier for someone with an outside perspective to be like, "Hey, this test is costing more than the value that it's providing." But yeah, I can see why people might have a little bit of pushback +JOËL: Sometimes, the value of a test is also in the journey rather than the destination. +STEPHANIE: Yeah, that's a good point. +JOËL: So if you're practicing TDD, maybe you use some tests to help you drive out some functionality, help you come up with a design that you want to do. But maybe once you've actually created the design, the test that helped you get there is not actually that useful. I've heard some people will do this by writing a lot of more system tests-like tests that are very integration-heavy, that have a lot of edge cases that you might not care to test at that level, at that granularity. And so they use those to help drive a little bit of the implementation and then remove them because they're not providing that much value relative to their cost anymore. +STEPHANIE: I think that's a really good point. The tests that you write for implementation can have value to you as a developer, but that's different from those tests having value to the business when you commit them to a codebase and incorporate them as part of CI and a CI that everyone else has to run as well. So yeah, I think in that case, the context definitely matters. And hopefully, you can feel good about the value that it provided but then also have that eye towards, okay, what about the business, and what values does the business have? +JOËL: Yeah, and accept that the test did the job that it was supposed to do. It got you to where you needed to be, and it completed its purpose. And now it's ready to move on. +STEPHANIE: Another thing that I recently read about deleting code...and this was from Chelsea Troy. She advocates for regularly evaluating features in an app and deciding whether they're providing enough value to justify keeping around and maintaining for developers as well. And I thought that was really interesting because I don't know if that's something that I'd really considered before that sometimes an app might outgrow some features, or they might not be worth keeping around because of the problems or the maintenance costs that they carry into the future. +JOËL: That's fascinating because I think you're taking the same analysis we were talking about tests and then kind of like bringing it up now to the product level. Because now, we're not just talking about deleting code; we're talking about deleting functionality that a product might have. +STEPHANIE: I think the challenge there is that the effects of the carrying cost of a feature is not necessarily felt by the business stakeholders, or product folks, or people operating at a higher level, but it is felt by developers. If there's a bug that's come up from this old feature, and oh, I have never seen this feature before, and now I have to spend a day learning about what this thing is before I can fix the bug. It did feel like a radical idea that maybe developers can play a part in advocating for some features to be retired, that is, you know, maybe separate from how products thinks about those things. +JOËL: I think in order to be able to make those decisions or really just to be part of those conversations, the dev side needs to be really integrated with the product team and with larger business objectives. And so then you can say, look, if we take a week of one developer's time to provide the support this feature needs and we have one customer paying $20 a month for it, that's not a good business prospect. +Now, is this strategically an area that we're trying to grow? And so yeah, we're doing it for one customer, but we're hoping to get 100 by the end of the year, and then it will be worth it. Then yes, maybe we keep that feature around. If this is the thing, like, we experimented for a few weeks five years ago, and then it's just kind of hang around as a legacy thing that this one person knows about and uses, then maybe it's worth saying, look, this has a high business cost. It might be worth sunsetting that feature. But it's a conversation that everybody needs to be involved in. +STEPHANIE: Yeah, yeah. I like the idea of it being something more proactive versus, I don't know, something that I think I've seen at other orgs and just in general as a person who uses digital products, like, a feature or a product, just kind of dying. And probably the organization just wasn't able to find a team to continue to support it, and it just kind of kept being this burden. And then, eventually, it just was something that they had to let go. But then, at that point, you had already spent all of that time, and effort, and energy into figuring out what to do with this thing. +Whereas the approach that Chelsea is advocating for is more realistic, I think, about the fate of [laughs] software products and features. And as a developer, I would get that feeling of deleting [laughs] code that is so satisfying. And I'm just not burdened by having to deal with something that is not providing value, like cumbersome tests. [laughs] +JOËL: I think it's always the fundamental thing that you have to go back to when you're talking about deleting code, or features, or anything is that sort of cost-benefit analysis. Does this thing provide us any value? And if so, does that value outweigh the cost of the work we need to do to maintain it? And in the case of dead code, well, it's probably providing zero value, but it's imposing a cost, and so we want to remove it. +In the case of a test that is not muted or pending, then maybe it does provide some value. But if it's really brittle and constantly breaking, and it's costing us many hours of fixing time, then maybe it's not. If we can't find a way to fix it and make it more valuable because sometimes it's the other option, then it might be worth considering deleting it. Have you ever, on a codebase, taken some time to actually seek out code that could be deleted as opposed to just sort of stumbling onto it yourself? +STEPHANIE: That's a good question. I think I have not just explored a codebase just looking for stuff to delete, but I have...maybe if you had something under a feature flag and you no longer needed the flag because it was released to everyone, you know, going back to delete it because you specifically made a ticket to make sure that you went back and cleaned that up. I do really appreciate the tracking of that work in that way and just making sure you're like, hey, I want to avoid a situation where this becomes dead code. And even just making a card for it is putting that intention out there. And hopefully, someone, if not yourself, we'll take that on because it's important. +JOËL: Yeah, kind of proactively trying to make sure that the work that you've done doesn't become dead code, that it gets pruned at the appropriate moment. +STEPHANIE: What about you? I'm curious from your perspective as an individual contributor when you are just moving through a codebase, and you see something suspiciously [laughs] looking like dead code what you do with it. +JOËL: I often like to split out a small PR just to remove that if it's not too much work and it's semi-related to what I'm doing. I'd like to give a shout-out to two tools that can help detect or confirm that something is dead code. One is Unused, written by former thoughtboter Josh Clayton. +It uses, I think, Ctags under the hood to track all the tokens in an app and then tries to determine are there tokens that are orphaned, that are isolated, and are not used? And it can then build you a report. And that can be good if you're doing a code audit of a codebase or if you're looking to confirm that a piece of code that you're working on might not be, like, is it actually used or not? +Another one is elm-review-unused, which is a plugin for elm-review which is Elm's linter, kind of like RuboCop. And what's really nice there is because it reads the AST, and Elm functions don't have side effects. You know that if something is not reachable from the main function that, it is completely safe to remove. You've run the script, and it will delete a bunch of functions for you that are unused, and it's 100% safe. +And it is very thorough. It finds all of the dead code and just removes it. It's practically just a...it's not a button because it's a script that you run but that you can automate to run on commit or whatever on the CI. But yeah, that's an amazing experience to just have it auto clean-up for you all the time. +STEPHANIE: That's really cool. I like that a lot. I think that would be really nice to incorporate into your development workflow, like you said, that it's part of the linting system and just keeping things tidy. +JOËL: Yeah, I think it's a little bit harder to have something that's quite as thorough for a Ruby or Rails app just because it's so dynamic, and we've got all this metaprogramming. But yeah, maybe this would be a thing where you would want to run something like Unused or some other linting tool every now and then to just check; hey, do we have any dead code that can be removed? +STEPHANIE: Yeah, absolutely. And I think this is totally a little bit different because we're just talking about tools, but I'm also thinking of red flags on a team level where I have definitely asked in a Slack channel, "Hey, I've never seen this feature before. What does it do?" and just crickets. [laughs] And even the product folks that I'm working with, they're like, "I don't know. It predates me," that being a bit of a smell, [laughs] if you will, to reevaluate some of those things. And those flags can exist on many different levels. +JOËL: That's always terrifying because you're like 80% sure that this is dead code, but there's like a 20% chance that this powers the core of the app, but nobody's touched it in 10 years. +STEPHANIE: Yeah, it is very scary. [laughs] +JOËL: Hopefully, your test suite is good enough that if you comment out that function and then you run your test suite, that it just all goes red, and you know that that's actually needed for something. +STEPHANIE: Yeah, though I think sometimes you might remove a piece of dead code, and there are some issues afterwards, and you find out, and you just revert it, and it's fine. At the end of the day, there are a lot of safeguards in place, and we've all done it. And so I think normalizing it is also very important in that it's okay if sometimes you make a mistake there. +JOËL: Stephanie is giving you permission to go and delete that code today. Ship it to production, and if something breaks, it's okay. +STEPHANIE: [laughs] +JOËL: You can revert it. Hopefully, your company is set up where reverting commits from production is a cheap and easy thing to do, and life goes on. So I'm curious, Stephanie, have you ever gone into GitHub and checked your stats on a project to see if you're more red than green or what that ratio is for you on a given project? +STEPHANIE: I have. Actually, someone else did on my behalf because I was posting a lot in that Dead Code Society Slack channel. And they then shared a screenshot of my overall contributions to a repo, and it was more red than green. I felt pretty good about myself. [laughs] +JOËL: All right. Net negative but in a positive kind of way. +STEPHANIE: In a positive way. [laughter] +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. [laughs] Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + thoughtbot had an in-person Summit in the UK! Joël recalls highlights. Stephanie is loving daily sync meetings on a new project.

+ +

The idea of deleting code has been swimming around in Stephanie's brain recently because she's been feeling nervous about it. Together, Joël and Stephanie explore ways of gaining confidence to delete code while feeling good about it.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 today, 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: I just got back from a few days in the UK, where thoughtbot has been having an in-person Summit, where we've brought people from all over the company together to spend a few days just spending time with each other, getting to know each other, getting to connect in person.

+ +

STEPHANIE: That sounds like it was a lot of fun. I've been hearing really great things about it from folks who've come back. Unfortunately, I couldn't make it this year. I got sick a little bit beforehand and then ended up not being able to go. But it sounds like it was a lot of fun just to get together, especially since we're now a remote company.

+ +

JOËL: Yeah, I'm really sorry you weren't able to make it there. It would have been amazing to do a Bike Shed co-hosts get-together.

+ +

STEPHANIE: I know. In the same room, maybe even record. What a concept. [laughs]

+ +

JOËL: So thoughtbot is a fully remote company, and so that means that getting a chance to have people to come together and build those in-person connections that you don't get, I think, is incredibly valuable. I was really excited to meet both the people that I work with and that I see on my screen every day and people who I don't talk to as often because they're working on different teams or different departments even.

+ +

STEPHANIE: What was one highlight of the time you spent together?

+ +

JOËL: I'll give a couple of highlights, one I think is more on the activity side. We went bouldering as a group. This was a really popular activity. We were trying to sign up people for it, and it was so popular we had to make two groups because there were too many people who were interested. And it was really fun. There are people with a whole variety of skill levels. Some people, it was their first time, some people had been doing it for a while. And just getting together and solving problems was a lot of fun.

+ +

STEPHANIE: Yes, I saw that. That was one of the things I was really looking forward to doing when I was still thinking that I was going to go. And it's cool that it had opportunities for both beginners and people who have been doing it before, which I think, if I recall correctly, Joël, you are a boulderer yourself back home. So that's pretty neat that you were able to, yeah, I don't know, maybe share some of that experience IRL too.

+ +

JOËL: Yeah, yeah, I think it's great because people were able to help each other. Sometimes you have a different perspective down on the ground than you do up on the wall. And then, in my case, because I've done it a lot, I know a little bit of actual climbing technique. And so I can give some tips on, like, oh, if you're stuck and you don't know how to get past a particular point, or you don't know how to start a particular climb, or your arms are getting tired halfway up, here's maybe a small change you can make that would make things easier for you.

+ +

STEPHANIE: Honestly, that also sounds like a really good metaphor for pair programming, [laughs] like, looking at things from different perspectives, you know, someone who's on the wall? I don't know what the lingo is. But it's the equivalent of someone driving in coding, the navigator having a little more perspective and being able to point out things that they might not see that's right in front of them.

+ +

JOËL: I love that metaphor. Now I'm going to think of that both when I pair and the next time I climb.

+ +

STEPHANIE: I love it.

+ +

JOËL: I think climbing, when I do it, it's always more fun with a friend, specifically for what you were saying. I climb alone sometimes, but as much as possible, I'll reach out to another friend who climbs and say, "Hey, let's climb together." And then we can alternate on the same route even.

+ +

STEPHANIE: That's cool. I didn't realize that it could be such a social activity.

+ +

JOËL: It is very much a social activity, and I think that's part of the fun of it. It's challenging physically but also mentally because it's a puzzle that you solve. But then also, it's a thing that you do with friends.

+ +

I think another aspect that was a highlight for me was getting a chance to connect with people from other teams, other departments within thoughtbot. I think one thing that was really nice when we were located in an office is that over lunch, or just at the water cooler, or whatever, you would connect with people who were in other teams and who were in different departments.

+ +

So I might talk to people in People Ops, or in marketing, in operations just sort of in the natural course of the day in a way that I think I don't do quite as much of now that we're more remote. And I tend to talk more with other developers and designers on my team. So I think that was really great to connect with people from other teams and other departments within the company.

+ +

STEPHANIE: Yeah, I know what you mean. I think I really miss the spontaneous, organic social interaction that you get from working in an office. And I think we've maybe talked about remote work on the podcast before, or previous co-hosts Steph and Chris have also talked about remote work. But it definitely requires a lot more intention to manifest those connections that otherwise would have been a little more organic in person.

+ +

And so, while you all were at an in-person summit in the UK, there was also a virtual summit hosted for folks who weren't able to travel this time around, and I really appreciated that. I got to spend a day just connecting with other people in Gather Town, which is a web app that's like a virtual space where you have little avatars, and you can run around and meet up with people into virtual meeting rooms on this map. [laughs] I'm not really sure I'm describing it well, but it's very cute. It is almost like a little video game.

+ +

It's like a cross between a video game and video conferencing [chuckles] software. But yeah, I think I just really appreciated how inclusive thoughtbot has been doing remote work where, like, yes, we really value these in-person gatherings, and we understand that there is a bit of magic that comes from that, but also making sure that no one's left out. And at the end of the day, not everyone can make it, but we were still able to hang out and socialize amongst ourselves in a different way.

+ +

JOËL: Agreed. I think that inclusivity is part of what makes thoughtbot such a great place to work at.

+ +

STEPHANIE: Speaking of inclusivity, I mentioned a few weeks ago that I joined a new project recently and had been going through the onboarding and hopping into all these new meetings. One thing that I've really enjoyed about this new client team that I'm on is that in their daily sync meetings, we all share what we're working on. But we also all share something that's new to us, which is a little bit meta because we do that on this podcast. [laughs]

+ +

But each person just shares maybe something they learned at work but also usually something just totally not work related like a new show that they're watching. There's another person on my team who learns a lot of things from YouTube videos. And so he's always telling us about the new thing he learned about, I don't know, like mushrooms or whatever, or AI [laughs] through YouTube. And yeah, someone else might show a sweater that they just knit themselves. And it's been a very easy way to get to know people, especially when you're meeting a whole new team. And yeah, I've been enjoying it a lot. It's made me feel very welcome and like I know them as people outside of work.

+ +

JOËL: I love that. Yeah, they're more than just people you're shipping code with. You're able to build that connection. And it sounds like that helps smooth the...maybe we can say the social aspect of onboarding. Because when you onboard onto a project, you're not just onboarding onto a series of codebases and tools; you're also onboarding onto a team, and you need to get to know people and build relationships.

+ +

STEPHANIE: Yeah, absolutely.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you've been...is it two weeks in a new codebase? Have you gone and deleted any code yet?

+ +

STEPHANIE: I wish. I am glad you asked this question because this has been a topic that has been swimming around in my head a little bit lately because this new client codebase it's very big and it's quite old. Like, I've been seeing code from 10 years ago. And it's been a really challenging codebase to get onboarded into, actually, because there's so much stuff.

+ +

In fact, I recently learned that some of their model specs are so big that they have been split out into up to seven different files to cover specs for one model. [laughs] So that has been a lot to grapple with. And I think in my journeys working on a starter ticket, I've just stumbled upon stuff that is very confusing. And then I might follow that thread only to realize that, like, oh, this method that I spent 20 minutes trying to grok turns out it's not actually used anywhere.

+ +

JOËL: That's a lot of dead code.

+ +

STEPHANIE: It is a lot of dead code, but I am also not quite feeling confident enough to delete it because I'm new, because I have no idea what consequences that might have. So, yeah, the idea of deleting code has just kind of been swimming around in here because ideally, we would be able to, but, for some reason, I don't know, at least for me, I feel very nervous about it. So it hasn't been something that I've reached for.

+ +

JOËL: That's a great question because I think in maybe Ruby, in particular, it's not always obvious if code is being used or not. When you do find yourself deleting code, how do you gain the confidence that it was safe to delete that?

+ +

STEPHANIE: Yeah, that's a good question. In the past, when I've done it successfully, I'll probably post a Slack message or something and being like, hey, I noticed this code is not being used anywhere, or I'd like to delete it because why, like, I don't know, because it's been misleading me because it's just not providing any value. And then kind of give it like a day or two, and if no one speaks up about it, then I will usually go ahead.

+ +

And obviously, get some code review, hopefully, get some other eyes on it just to make sure that whatever assumptions I made were valid, and then go for it. And then just watch [laughs] the deployment afterwards and make sure that there are no new errors, you know, no new complaints or anything like that. And, yeah, I think that has been my process, and I've definitely found success doing that.

+ +

But I have also experienced a bad result [laughs] from doing that where one time, on my last client project, we were refactoring the signup flow. And we realized that after you signed up, you were redirected to this blank page for like 10 seconds or something. It was completely empty. There was nothing on it except a spinner, I think. [laughs] And then it would then redirect you to the dashboard of the app. And we were like, oh, we can definitely delete this. We have no idea what this is doing. We don't want to try to refactor this as part of the effort that we were doing.

+ +

And so we deleted it, only to find out later from the marketing team that they had been using that page for something Google Analytics related, and we had to revert that change. And it was a real bummer because I think when we removed it, we felt good about that. We were like, oh yes, deleting code, awesome. And then having to bring it back without a clear plan of how to actually fix the problem that we were trying to solve was a bit of a bummer.

+ +

JOËL: So, as programmers, we're hired to write code. Why does it feel so good to do the opposite of that, to delete code?

+ +

STEPHANIE: That's a great question. I actually want to know what you think about this, but before that, I wanted to plug this Slack channel that we have at thoughtbot called Dead Code Society, where people can post their PR diffs showing more red than green, so more lines removed than lines added. And I have been really enjoying that Slack channel. It's very delightful. [laughs] But, Joël, do you have any thoughts about why it feels so good to delete code?

+ +

JOËL: There are probably a few different reasons. Especially when it's not your own code, you're often not attached to it. There's often, I think, the sense when you go into an existing codebase you're just like, oh, everything's just bad, and I don't understand it. And those other coders who wrote this didn't know how to do their job and kind of be the curmudgeon character. So it just kind of feels good to remove that and maybe rewrite it yourself. I would say that's not a good mindset to go in for deleting code. I think there are positive ways where it is actually a good thing.

+ +

STEPHANIE: That's fair. Just removing code because you would write it differently is not necessarily a net positive. [laughs]

+ +

JOËL: But I think...so when I initially asked the question, I said, "We're hired to write code." And I think that's a bit of a false assumption built into the question. We're not hired to write code. We're hired to solve problems, to build solutions. And as much as code can be an asset in solving problems, it's also a liability. And code has varying maintenance costs that are typically not low. They vary from expensive to very expensive. And so any chance we get to remove some of that, we're removing some of the carrying costs, to use a term that we discussed a few episodes back when we talked about sustainable Rails.

+ +

STEPHANIE: Yeah, absolutely. One thing that I remember you sharing about the client project that we're both on in the past is they have a very cumbersome test suite. And in some situations, you have wanted to advocate for deleting some of those tests.

+ +

JOËL: Deleting tests is a really, I think, spicy take because you're trying to get better test coverage. And if your test coverage isn't great, you don't want to lose any of that. So there's definitely a loss aversion there, and we might need it later. At the same time, tests have a cost, cost to run, cost to maintain. And if they're not providing a lot of value, then the cost of keeping them around might be higher than any kind of benefit they're giving you.

+ +

And I think a classic case of this is tests that have either been marked pending in the codebase with an exit or something like that or that have been marked in your CI server as muted; just ignore failures from this test. Because now you're still having to maintain, still having to execute these tests. They're costing you time, but they're giving you zero benefit. And they're just taking up space in your codebase, making it harder to read. So if you can't get these tests back into the point where they're actually executing, and you're caring about the output, then you probably don't need those tests, and they can be removed.

+ +

STEPHANIE: Yeah, that's fair. I'm thinking about the perspective of someone who does not want to delete those tests. I think in the past, I've seen it and even felt it myself as someone who probably wrote the tests, kind of hoping for some ideal world where I will finally have time to go back to that test. And I already put a lot of effort into trying to make it work, and I want to make it work. I want to have the value of that test.

+ +

And it's kind of like a sunk cost fallacy a little bit where it's like, I already spent however much time on it that it must have some kind of value. Because just hearing that someone else wants to delete the test can kind of hurt a little bit. [laughs] And it's tough. I do think that it's easier for someone with an outside perspective to be like, "Hey, this test is costing more than the value that it's providing." But yeah, I can see why people might have a little bit of pushback

+ +

JOËL: Sometimes, the value of a test is also in the journey rather than the destination.

+ +

STEPHANIE: Yeah, that's a good point.

+ +

JOËL: So if you're practicing TDD, maybe you use some tests to help you drive out some functionality, help you come up with a design that you want to do. But maybe once you've actually created the design, the test that helped you get there is not actually that useful. I've heard some people will do this by writing a lot of more system tests-like tests that are very integration-heavy, that have a lot of edge cases that you might not care to test at that level, at that granularity. And so they use those to help drive a little bit of the implementation and then remove them because they're not providing that much value relative to their cost anymore.

+ +

STEPHANIE: I think that's a really good point. The tests that you write for implementation can have value to you as a developer, but that's different from those tests having value to the business when you commit them to a codebase and incorporate them as part of CI and a CI that everyone else has to run as well. So yeah, I think in that case, the context definitely matters. And hopefully, you can feel good about the value that it provided but then also have that eye towards, okay, what about the business, and what values does the business have?

+ +

JOËL: Yeah, and accept that the test did the job that it was supposed to do. It got you to where you needed to be, and it completed its purpose. And now it's ready to move on.

+ +

STEPHANIE: Another thing that I recently read about deleting code...and this was from Chelsea Troy. She advocates for regularly evaluating features in an app and deciding whether they're providing enough value to justify keeping around and maintaining for developers as well. And I thought that was really interesting because I don't know if that's something that I'd really considered before that sometimes an app might outgrow some features, or they might not be worth keeping around because of the problems or the maintenance costs that they carry into the future.

+ +

JOËL: That's fascinating because I think you're taking the same analysis we were talking about tests and then kind of like bringing it up now to the product level. Because now, we're not just talking about deleting code; we're talking about deleting functionality that a product might have.

+ +

STEPHANIE: I think the challenge there is that the effects of the carrying cost of a feature is not necessarily felt by the business stakeholders, or product folks, or people operating at a higher level, but it is felt by developers. If there's a bug that's come up from this old feature, and oh, I have never seen this feature before, and now I have to spend a day learning about what this thing is before I can fix the bug. It did feel like a radical idea that maybe developers can play a part in advocating for some features to be retired, that is, you know, maybe separate from how products thinks about those things.

+ +

JOËL: I think in order to be able to make those decisions or really just to be part of those conversations, the dev side needs to be really integrated with the product team and with larger business objectives. And so then you can say, look, if we take a week of one developer's time to provide the support this feature needs and we have one customer paying $20 a month for it, that's not a good business prospect.

+ +

Now, is this strategically an area that we're trying to grow? And so yeah, we're doing it for one customer, but we're hoping to get 100 by the end of the year, and then it will be worth it. Then yes, maybe we keep that feature around. If this is the thing, like, we experimented for a few weeks five years ago, and then it's just kind of hang around as a legacy thing that this one person knows about and uses, then maybe it's worth saying, look, this has a high business cost. It might be worth sunsetting that feature. But it's a conversation that everybody needs to be involved in.

+ +

STEPHANIE: Yeah, yeah. I like the idea of it being something more proactive versus, I don't know, something that I think I've seen at other orgs and just in general as a person who uses digital products, like, a feature or a product, just kind of dying. And probably the organization just wasn't able to find a team to continue to support it, and it just kind of kept being this burden. And then, eventually, it just was something that they had to let go. But then, at that point, you had already spent all of that time, and effort, and energy into figuring out what to do with this thing.

+ +

Whereas the approach that Chelsea is advocating for is more realistic, I think, about the fate of [laughs] software products and features. And as a developer, I would get that feeling of deleting [laughs] code that is so satisfying. And I'm just not burdened by having to deal with something that is not providing value, like cumbersome tests. [laughs]

+ +

JOËL: I think it's always the fundamental thing that you have to go back to when you're talking about deleting code, or features, or anything is that sort of cost-benefit analysis. Does this thing provide us any value? And if so, does that value outweigh the cost of the work we need to do to maintain it? And in the case of dead code, well, it's probably providing zero value, but it's imposing a cost, and so we want to remove it.

+ +

In the case of a test that is not muted or pending, then maybe it does provide some value. But if it's really brittle and constantly breaking, and it's costing us many hours of fixing time, then maybe it's not. If we can't find a way to fix it and make it more valuable because sometimes it's the other option, then it might be worth considering deleting it. Have you ever, on a codebase, taken some time to actually seek out code that could be deleted as opposed to just sort of stumbling onto it yourself?

+ +

STEPHANIE: That's a good question. I think I have not just explored a codebase just looking for stuff to delete, but I have...maybe if you had something under a feature flag and you no longer needed the flag because it was released to everyone, you know, going back to delete it because you specifically made a ticket to make sure that you went back and cleaned that up. I do really appreciate the tracking of that work in that way and just making sure you're like, hey, I want to avoid a situation where this becomes dead code. And even just making a card for it is putting that intention out there. And hopefully, someone, if not yourself, we'll take that on because it's important.

+ +

JOËL: Yeah, kind of proactively trying to make sure that the work that you've done doesn't become dead code, that it gets pruned at the appropriate moment.

+ +

STEPHANIE: What about you? I'm curious from your perspective as an individual contributor when you are just moving through a codebase, and you see something suspiciously [laughs] looking like dead code what you do with it.

+ +

JOËL: I often like to split out a small PR just to remove that if it's not too much work and it's semi-related to what I'm doing. I'd like to give a shout-out to two tools that can help detect or confirm that something is dead code. One is Unused, written by former thoughtboter Josh Clayton.

+ +

It uses, I think, Ctags under the hood to track all the tokens in an app and then tries to determine are there tokens that are orphaned, that are isolated, and are not used? And it can then build you a report. And that can be good if you're doing a code audit of a codebase or if you're looking to confirm that a piece of code that you're working on might not be, like, is it actually used or not?

+ +

Another one is elm-review-unused, which is a plugin for elm-review which is Elm's linter, kind of like RuboCop. And what's really nice there is because it reads the AST, and Elm functions don't have side effects. You know that if something is not reachable from the main function that, it is completely safe to remove. You've run the script, and it will delete a bunch of functions for you that are unused, and it's 100% safe.

+ +

And it is very thorough. It finds all of the dead code and just removes it. It's practically just a...it's not a button because it's a script that you run but that you can automate to run on commit or whatever on the CI. But yeah, that's an amazing experience to just have it auto clean-up for you all the time.

+ +

STEPHANIE: That's really cool. I like that a lot. I think that would be really nice to incorporate into your development workflow, like you said, that it's part of the linting system and just keeping things tidy.

+ +

JOËL: Yeah, I think it's a little bit harder to have something that's quite as thorough for a Ruby or Rails app just because it's so dynamic, and we've got all this metaprogramming. But yeah, maybe this would be a thing where you would want to run something like Unused or some other linting tool every now and then to just check; hey, do we have any dead code that can be removed?

+ +

STEPHANIE: Yeah, absolutely. And I think this is totally a little bit different because we're just talking about tools, but I'm also thinking of red flags on a team level where I have definitely asked in a Slack channel, "Hey, I've never seen this feature before. What does it do?" and just crickets. [laughs] And even the product folks that I'm working with, they're like, "I don't know. It predates me," that being a bit of a smell, [laughs] if you will, to reevaluate some of those things. And those flags can exist on many different levels.

+ +

JOËL: That's always terrifying because you're like 80% sure that this is dead code, but there's like a 20% chance that this powers the core of the app, but nobody's touched it in 10 years.

+ +

STEPHANIE: Yeah, it is very scary. [laughs]

+ +

JOËL: Hopefully, your test suite is good enough that if you comment out that function and then you run your test suite, that it just all goes red, and you know that that's actually needed for something.

+ +

STEPHANIE: Yeah, though I think sometimes you might remove a piece of dead code, and there are some issues afterwards, and you find out, and you just revert it, and it's fine. At the end of the day, there are a lot of safeguards in place, and we've all done it. And so I think normalizing it is also very important in that it's okay if sometimes you make a mistake there.

+ +

JOËL: Stephanie is giving you permission to go and delete that code today. Ship it to production, and if something breaks, it's okay.

+ +

STEPHANIE: [laughs]

+ +

JOËL: You can revert it. Hopefully, your company is set up where reverting commits from production is a cheap and easy thing to do, and life goes on. So I'm curious, Stephanie, have you ever gone into GitHub and checked your stats on a project to see if you're more red than green or what that ratio is for you on a given project?

+ +

STEPHANIE: I have. Actually, someone else did on my behalf because I was posting a lot in that Dead Code Society Slack channel. And they then shared a screenshot of my overall contributions to a repo, and it was more red than green. I felt pretty good about myself. [laughs]

+ +

JOËL: All right. Net negative but in a positive kind of way.

+ +

STEPHANIE: In a positive way. [laughter]

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. [laughs] Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + thoughtbot had an in-person Summit in the UK! Joël recalls highlights. Stephanie is loving daily sync meetings on a new project.

+ +

The idea of deleting code has been swimming around in Stephanie's brain recently because she's been feeling nervous about it. Together, Joël and Stephanie explore ways of gaining confidence to delete code while feeling good about it.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 today, 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: I just got back from a few days in the UK, where thoughtbot has been having an in-person Summit, where we've brought people from all over the company together to spend a few days just spending time with each other, getting to know each other, getting to connect in person.

+ +

STEPHANIE: That sounds like it was a lot of fun. I've been hearing really great things about it from folks who've come back. Unfortunately, I couldn't make it this year. I got sick a little bit beforehand and then ended up not being able to go. But it sounds like it was a lot of fun just to get together, especially since we're now a remote company.

+ +

JOËL: Yeah, I'm really sorry you weren't able to make it there. It would have been amazing to do a Bike Shed co-hosts get-together.

+ +

STEPHANIE: I know. In the same room, maybe even record. What a concept. [laughs]

+ +

JOËL: So thoughtbot is a fully remote company, and so that means that getting a chance to have people to come together and build those in-person connections that you don't get, I think, is incredibly valuable. I was really excited to meet both the people that I work with and that I see on my screen every day and people who I don't talk to as often because they're working on different teams or different departments even.

+ +

STEPHANIE: What was one highlight of the time you spent together?

+ +

JOËL: I'll give a couple of highlights, one I think is more on the activity side. We went bouldering as a group. This was a really popular activity. We were trying to sign up people for it, and it was so popular we had to make two groups because there were too many people who were interested. And it was really fun. There are people with a whole variety of skill levels. Some people, it was their first time, some people had been doing it for a while. And just getting together and solving problems was a lot of fun.

+ +

STEPHANIE: Yes, I saw that. That was one of the things I was really looking forward to doing when I was still thinking that I was going to go. And it's cool that it had opportunities for both beginners and people who have been doing it before, which I think, if I recall correctly, Joël, you are a boulderer yourself back home. So that's pretty neat that you were able to, yeah, I don't know, maybe share some of that experience IRL too.

+ +

JOËL: Yeah, yeah, I think it's great because people were able to help each other. Sometimes you have a different perspective down on the ground than you do up on the wall. And then, in my case, because I've done it a lot, I know a little bit of actual climbing technique. And so I can give some tips on, like, oh, if you're stuck and you don't know how to get past a particular point, or you don't know how to start a particular climb, or your arms are getting tired halfway up, here's maybe a small change you can make that would make things easier for you.

+ +

STEPHANIE: Honestly, that also sounds like a really good metaphor for pair programming, [laughs] like, looking at things from different perspectives, you know, someone who's on the wall? I don't know what the lingo is. But it's the equivalent of someone driving in coding, the navigator having a little more perspective and being able to point out things that they might not see that's right in front of them.

+ +

JOËL: I love that metaphor. Now I'm going to think of that both when I pair and the next time I climb.

+ +

STEPHANIE: I love it.

+ +

JOËL: I think climbing, when I do it, it's always more fun with a friend, specifically for what you were saying. I climb alone sometimes, but as much as possible, I'll reach out to another friend who climbs and say, "Hey, let's climb together." And then we can alternate on the same route even.

+ +

STEPHANIE: That's cool. I didn't realize that it could be such a social activity.

+ +

JOËL: It is very much a social activity, and I think that's part of the fun of it. It's challenging physically but also mentally because it's a puzzle that you solve. But then also, it's a thing that you do with friends.

+ +

I think another aspect that was a highlight for me was getting a chance to connect with people from other teams, other departments within thoughtbot. I think one thing that was really nice when we were located in an office is that over lunch, or just at the water cooler, or whatever, you would connect with people who were in other teams and who were in different departments.

+ +

So I might talk to people in People Ops, or in marketing, in operations just sort of in the natural course of the day in a way that I think I don't do quite as much of now that we're more remote. And I tend to talk more with other developers and designers on my team. So I think that was really great to connect with people from other teams and other departments within the company.

+ +

STEPHANIE: Yeah, I know what you mean. I think I really miss the spontaneous, organic social interaction that you get from working in an office. And I think we've maybe talked about remote work on the podcast before, or previous co-hosts Steph and Chris have also talked about remote work. But it definitely requires a lot more intention to manifest those connections that otherwise would have been a little more organic in person.

+ +

And so, while you all were at an in-person summit in the UK, there was also a virtual summit hosted for folks who weren't able to travel this time around, and I really appreciated that. I got to spend a day just connecting with other people in Gather Town, which is a web app that's like a virtual space where you have little avatars, and you can run around and meet up with people into virtual meeting rooms on this map. [laughs] I'm not really sure I'm describing it well, but it's very cute. It is almost like a little video game.

+ +

It's like a cross between a video game and video conferencing [chuckles] software. But yeah, I think I just really appreciated how inclusive thoughtbot has been doing remote work where, like, yes, we really value these in-person gatherings, and we understand that there is a bit of magic that comes from that, but also making sure that no one's left out. And at the end of the day, not everyone can make it, but we were still able to hang out and socialize amongst ourselves in a different way.

+ +

JOËL: Agreed. I think that inclusivity is part of what makes thoughtbot such a great place to work at.

+ +

STEPHANIE: Speaking of inclusivity, I mentioned a few weeks ago that I joined a new project recently and had been going through the onboarding and hopping into all these new meetings. One thing that I've really enjoyed about this new client team that I'm on is that in their daily sync meetings, we all share what we're working on. But we also all share something that's new to us, which is a little bit meta because we do that on this podcast. [laughs]

+ +

But each person just shares maybe something they learned at work but also usually something just totally not work related like a new show that they're watching. There's another person on my team who learns a lot of things from YouTube videos. And so he's always telling us about the new thing he learned about, I don't know, like mushrooms or whatever, or AI [laughs] through YouTube. And yeah, someone else might show a sweater that they just knit themselves. And it's been a very easy way to get to know people, especially when you're meeting a whole new team. And yeah, I've been enjoying it a lot. It's made me feel very welcome and like I know them as people outside of work.

+ +

JOËL: I love that. Yeah, they're more than just people you're shipping code with. You're able to build that connection. And it sounds like that helps smooth the...maybe we can say the social aspect of onboarding. Because when you onboard onto a project, you're not just onboarding onto a series of codebases and tools; you're also onboarding onto a team, and you need to get to know people and build relationships.

+ +

STEPHANIE: Yeah, absolutely.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you've been...is it two weeks in a new codebase? Have you gone and deleted any code yet?

+ +

STEPHANIE: I wish. I am glad you asked this question because this has been a topic that has been swimming around in my head a little bit lately because this new client codebase it's very big and it's quite old. Like, I've been seeing code from 10 years ago. And it's been a really challenging codebase to get onboarded into, actually, because there's so much stuff.

+ +

In fact, I recently learned that some of their model specs are so big that they have been split out into up to seven different files to cover specs for one model. [laughs] So that has been a lot to grapple with. And I think in my journeys working on a starter ticket, I've just stumbled upon stuff that is very confusing. And then I might follow that thread only to realize that, like, oh, this method that I spent 20 minutes trying to grok turns out it's not actually used anywhere.

+ +

JOËL: That's a lot of dead code.

+ +

STEPHANIE: It is a lot of dead code, but I am also not quite feeling confident enough to delete it because I'm new, because I have no idea what consequences that might have. So, yeah, the idea of deleting code has just kind of been swimming around in here because ideally, we would be able to, but, for some reason, I don't know, at least for me, I feel very nervous about it. So it hasn't been something that I've reached for.

+ +

JOËL: That's a great question because I think in maybe Ruby, in particular, it's not always obvious if code is being used or not. When you do find yourself deleting code, how do you gain the confidence that it was safe to delete that?

+ +

STEPHANIE: Yeah, that's a good question. In the past, when I've done it successfully, I'll probably post a Slack message or something and being like, hey, I noticed this code is not being used anywhere, or I'd like to delete it because why, like, I don't know, because it's been misleading me because it's just not providing any value. And then kind of give it like a day or two, and if no one speaks up about it, then I will usually go ahead.

+ +

And obviously, get some code review, hopefully, get some other eyes on it just to make sure that whatever assumptions I made were valid, and then go for it. And then just watch [laughs] the deployment afterwards and make sure that there are no new errors, you know, no new complaints or anything like that. And, yeah, I think that has been my process, and I've definitely found success doing that.

+ +

But I have also experienced a bad result [laughs] from doing that where one time, on my last client project, we were refactoring the signup flow. And we realized that after you signed up, you were redirected to this blank page for like 10 seconds or something. It was completely empty. There was nothing on it except a spinner, I think. [laughs] And then it would then redirect you to the dashboard of the app. And we were like, oh, we can definitely delete this. We have no idea what this is doing. We don't want to try to refactor this as part of the effort that we were doing.

+ +

And so we deleted it, only to find out later from the marketing team that they had been using that page for something Google Analytics related, and we had to revert that change. And it was a real bummer because I think when we removed it, we felt good about that. We were like, oh yes, deleting code, awesome. And then having to bring it back without a clear plan of how to actually fix the problem that we were trying to solve was a bit of a bummer.

+ +

JOËL: So, as programmers, we're hired to write code. Why does it feel so good to do the opposite of that, to delete code?

+ +

STEPHANIE: That's a great question. I actually want to know what you think about this, but before that, I wanted to plug this Slack channel that we have at thoughtbot called Dead Code Society, where people can post their PR diffs showing more red than green, so more lines removed than lines added. And I have been really enjoying that Slack channel. It's very delightful. [laughs] But, Joël, do you have any thoughts about why it feels so good to delete code?

+ +

JOËL: There are probably a few different reasons. Especially when it's not your own code, you're often not attached to it. There's often, I think, the sense when you go into an existing codebase you're just like, oh, everything's just bad, and I don't understand it. And those other coders who wrote this didn't know how to do their job and kind of be the curmudgeon character. So it just kind of feels good to remove that and maybe rewrite it yourself. I would say that's not a good mindset to go in for deleting code. I think there are positive ways where it is actually a good thing.

+ +

STEPHANIE: That's fair. Just removing code because you would write it differently is not necessarily a net positive. [laughs]

+ +

JOËL: But I think...so when I initially asked the question, I said, "We're hired to write code." And I think that's a bit of a false assumption built into the question. We're not hired to write code. We're hired to solve problems, to build solutions. And as much as code can be an asset in solving problems, it's also a liability. And code has varying maintenance costs that are typically not low. They vary from expensive to very expensive. And so any chance we get to remove some of that, we're removing some of the carrying costs, to use a term that we discussed a few episodes back when we talked about sustainable Rails.

+ +

STEPHANIE: Yeah, absolutely. One thing that I remember you sharing about the client project that we're both on in the past is they have a very cumbersome test suite. And in some situations, you have wanted to advocate for deleting some of those tests.

+ +

JOËL: Deleting tests is a really, I think, spicy take because you're trying to get better test coverage. And if your test coverage isn't great, you don't want to lose any of that. So there's definitely a loss aversion there, and we might need it later. At the same time, tests have a cost, cost to run, cost to maintain. And if they're not providing a lot of value, then the cost of keeping them around might be higher than any kind of benefit they're giving you.

+ +

And I think a classic case of this is tests that have either been marked pending in the codebase with an exit or something like that or that have been marked in your CI server as muted; just ignore failures from this test. Because now you're still having to maintain, still having to execute these tests. They're costing you time, but they're giving you zero benefit. And they're just taking up space in your codebase, making it harder to read. So if you can't get these tests back into the point where they're actually executing, and you're caring about the output, then you probably don't need those tests, and they can be removed.

+ +

STEPHANIE: Yeah, that's fair. I'm thinking about the perspective of someone who does not want to delete those tests. I think in the past, I've seen it and even felt it myself as someone who probably wrote the tests, kind of hoping for some ideal world where I will finally have time to go back to that test. And I already put a lot of effort into trying to make it work, and I want to make it work. I want to have the value of that test.

+ +

And it's kind of like a sunk cost fallacy a little bit where it's like, I already spent however much time on it that it must have some kind of value. Because just hearing that someone else wants to delete the test can kind of hurt a little bit. [laughs] And it's tough. I do think that it's easier for someone with an outside perspective to be like, "Hey, this test is costing more than the value that it's providing." But yeah, I can see why people might have a little bit of pushback

+ +

JOËL: Sometimes, the value of a test is also in the journey rather than the destination.

+ +

STEPHANIE: Yeah, that's a good point.

+ +

JOËL: So if you're practicing TDD, maybe you use some tests to help you drive out some functionality, help you come up with a design that you want to do. But maybe once you've actually created the design, the test that helped you get there is not actually that useful. I've heard some people will do this by writing a lot of more system tests-like tests that are very integration-heavy, that have a lot of edge cases that you might not care to test at that level, at that granularity. And so they use those to help drive a little bit of the implementation and then remove them because they're not providing that much value relative to their cost anymore.

+ +

STEPHANIE: I think that's a really good point. The tests that you write for implementation can have value to you as a developer, but that's different from those tests having value to the business when you commit them to a codebase and incorporate them as part of CI and a CI that everyone else has to run as well. So yeah, I think in that case, the context definitely matters. And hopefully, you can feel good about the value that it provided but then also have that eye towards, okay, what about the business, and what values does the business have?

+ +

JOËL: Yeah, and accept that the test did the job that it was supposed to do. It got you to where you needed to be, and it completed its purpose. And now it's ready to move on.

+ +

STEPHANIE: Another thing that I recently read about deleting code...and this was from Chelsea Troy. She advocates for regularly evaluating features in an app and deciding whether they're providing enough value to justify keeping around and maintaining for developers as well. And I thought that was really interesting because I don't know if that's something that I'd really considered before that sometimes an app might outgrow some features, or they might not be worth keeping around because of the problems or the maintenance costs that they carry into the future.

+ +

JOËL: That's fascinating because I think you're taking the same analysis we were talking about tests and then kind of like bringing it up now to the product level. Because now, we're not just talking about deleting code; we're talking about deleting functionality that a product might have.

+ +

STEPHANIE: I think the challenge there is that the effects of the carrying cost of a feature is not necessarily felt by the business stakeholders, or product folks, or people operating at a higher level, but it is felt by developers. If there's a bug that's come up from this old feature, and oh, I have never seen this feature before, and now I have to spend a day learning about what this thing is before I can fix the bug. It did feel like a radical idea that maybe developers can play a part in advocating for some features to be retired, that is, you know, maybe separate from how products thinks about those things.

+ +

JOËL: I think in order to be able to make those decisions or really just to be part of those conversations, the dev side needs to be really integrated with the product team and with larger business objectives. And so then you can say, look, if we take a week of one developer's time to provide the support this feature needs and we have one customer paying $20 a month for it, that's not a good business prospect.

+ +

Now, is this strategically an area that we're trying to grow? And so yeah, we're doing it for one customer, but we're hoping to get 100 by the end of the year, and then it will be worth it. Then yes, maybe we keep that feature around. If this is the thing, like, we experimented for a few weeks five years ago, and then it's just kind of hang around as a legacy thing that this one person knows about and uses, then maybe it's worth saying, look, this has a high business cost. It might be worth sunsetting that feature. But it's a conversation that everybody needs to be involved in.

+ +

STEPHANIE: Yeah, yeah. I like the idea of it being something more proactive versus, I don't know, something that I think I've seen at other orgs and just in general as a person who uses digital products, like, a feature or a product, just kind of dying. And probably the organization just wasn't able to find a team to continue to support it, and it just kind of kept being this burden. And then, eventually, it just was something that they had to let go. But then, at that point, you had already spent all of that time, and effort, and energy into figuring out what to do with this thing.

+ +

Whereas the approach that Chelsea is advocating for is more realistic, I think, about the fate of [laughs] software products and features. And as a developer, I would get that feeling of deleting [laughs] code that is so satisfying. And I'm just not burdened by having to deal with something that is not providing value, like cumbersome tests. [laughs]

+ +

JOËL: I think it's always the fundamental thing that you have to go back to when you're talking about deleting code, or features, or anything is that sort of cost-benefit analysis. Does this thing provide us any value? And if so, does that value outweigh the cost of the work we need to do to maintain it? And in the case of dead code, well, it's probably providing zero value, but it's imposing a cost, and so we want to remove it.

+ +

In the case of a test that is not muted or pending, then maybe it does provide some value. But if it's really brittle and constantly breaking, and it's costing us many hours of fixing time, then maybe it's not. If we can't find a way to fix it and make it more valuable because sometimes it's the other option, then it might be worth considering deleting it. Have you ever, on a codebase, taken some time to actually seek out code that could be deleted as opposed to just sort of stumbling onto it yourself?

+ +

STEPHANIE: That's a good question. I think I have not just explored a codebase just looking for stuff to delete, but I have...maybe if you had something under a feature flag and you no longer needed the flag because it was released to everyone, you know, going back to delete it because you specifically made a ticket to make sure that you went back and cleaned that up. I do really appreciate the tracking of that work in that way and just making sure you're like, hey, I want to avoid a situation where this becomes dead code. And even just making a card for it is putting that intention out there. And hopefully, someone, if not yourself, we'll take that on because it's important.

+ +

JOËL: Yeah, kind of proactively trying to make sure that the work that you've done doesn't become dead code, that it gets pruned at the appropriate moment.

+ +

STEPHANIE: What about you? I'm curious from your perspective as an individual contributor when you are just moving through a codebase, and you see something suspiciously [laughs] looking like dead code what you do with it.

+ +

JOËL: I often like to split out a small PR just to remove that if it's not too much work and it's semi-related to what I'm doing. I'd like to give a shout-out to two tools that can help detect or confirm that something is dead code. One is Unused, written by former thoughtboter Josh Clayton.

+ +

It uses, I think, Ctags under the hood to track all the tokens in an app and then tries to determine are there tokens that are orphaned, that are isolated, and are not used? And it can then build you a report. And that can be good if you're doing a code audit of a codebase or if you're looking to confirm that a piece of code that you're working on might not be, like, is it actually used or not?

+ +

Another one is elm-review-unused, which is a plugin for elm-review which is Elm's linter, kind of like RuboCop. And what's really nice there is because it reads the AST, and Elm functions don't have side effects. You know that if something is not reachable from the main function that, it is completely safe to remove. You've run the script, and it will delete a bunch of functions for you that are unused, and it's 100% safe.

+ +

And it is very thorough. It finds all of the dead code and just removes it. It's practically just a...it's not a button because it's a script that you run but that you can automate to run on commit or whatever on the CI. But yeah, that's an amazing experience to just have it auto clean-up for you all the time.

+ +

STEPHANIE: That's really cool. I like that a lot. I think that would be really nice to incorporate into your development workflow, like you said, that it's part of the linting system and just keeping things tidy.

+ +

JOËL: Yeah, I think it's a little bit harder to have something that's quite as thorough for a Ruby or Rails app just because it's so dynamic, and we've got all this metaprogramming. But yeah, maybe this would be a thing where you would want to run something like Unused or some other linting tool every now and then to just check; hey, do we have any dead code that can be removed?

+ +

STEPHANIE: Yeah, absolutely. And I think this is totally a little bit different because we're just talking about tools, but I'm also thinking of red flags on a team level where I have definitely asked in a Slack channel, "Hey, I've never seen this feature before. What does it do?" and just crickets. [laughs] And even the product folks that I'm working with, they're like, "I don't know. It predates me," that being a bit of a smell, [laughs] if you will, to reevaluate some of those things. And those flags can exist on many different levels.

+ +

JOËL: That's always terrifying because you're like 80% sure that this is dead code, but there's like a 20% chance that this powers the core of the app, but nobody's touched it in 10 years.

+ +

STEPHANIE: Yeah, it is very scary. [laughs]

+ +

JOËL: Hopefully, your test suite is good enough that if you comment out that function and then you run your test suite, that it just all goes red, and you know that that's actually needed for something.

+ +

STEPHANIE: Yeah, though I think sometimes you might remove a piece of dead code, and there are some issues afterwards, and you find out, and you just revert it, and it's fine. At the end of the day, there are a lot of safeguards in place, and we've all done it. And so I think normalizing it is also very important in that it's okay if sometimes you make a mistake there.

+ +

JOËL: Stephanie is giving you permission to go and delete that code today. Ship it to production, and if something breaks, it's okay.

+ +

STEPHANIE: [laughs]

+ +

JOËL: You can revert it. Hopefully, your company is set up where reverting commits from production is a cheap and easy thing to do, and life goes on. So I'm curious, Stephanie, have you ever gone into GitHub and checked your stats on a project to see if you're more red than green or what that ratio is for you on a given project?

+ +

STEPHANIE: I have. Actually, someone else did on my behalf because I was posting a lot in that Dead Code Society Slack channel. And they then shared a screenshot of my overall contributions to a repo, and it was more red than green. I felt pretty good about myself. [laughs]

+ +

JOËL: All right. Net negative but in a positive kind of way.

+ +

STEPHANIE: In a positive way. [laughter]

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. [laughs] Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+k5pxTqH- + + ]]> + + Joël Quenneville + Stephanie Minn + + + 374: Discrete Math + https://bikeshed.thoughtbot.com/374 + 8720c447-071f-4584-9c3a-0aa1502df52b + Tue, 07 Mar 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël is joined by a very special guest, Sara Jackson, a fellow Software Developer at thoughtbot. + +A few episodes ago, Stephanie and Joël talked about ["The Fundamentals"](https://www.bikeshed.fm/371) and how many of the fundamentals of web development line up with a Computer Science degree. Joël made a comment during that episode that his pick for the most underrated CS class that he thinks would benefit most devs is a class called +"Discrete Math." Sara weighs in! + 30:54 + no + + + Joël is joined by a very special guest, Sara Jackson, a fellow Software Developer at thoughtbot. +A few episodes ago, Stephanie and Joël talked about "The Fundamentals" (https://www.bikeshed.fm/371) and how many of the fundamentals of web development line up with a Computer Science degree. Joël made a comment during that episode that his pick for the most underrated CS class that he thinks would benefit most devs is a class called +"Discrete Math." Sara weighs in! +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Earlier Bike Shed Episode with Sara (https://www.bikeshed.fm/354) +The Linux man-pages project (https://www.kernel.org/doc/man-pages/) +Gravity Falls (https://www.imdb.com/title/tt1865718/) +Elm types as sets (https://guide.elm-lang.org/appendix/types_as_sets.html) +Folgers ad (https://www.youtube.com/watch?v=S7LXSQ85jpw) +Brilliant.org's discrete math course (https://brilliant.org/wiki/discrete-mathematics/) +mayuko (https://www.youtube.com/@hellomayuko) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +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. And today, I'm joined by a special guest, Sara Jackson, who is a fellow developer here at thoughtbot. +SARA: Hello. +JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world? +SARA: Actually, I recently picked up crocheting. +JOËL: That's exciting. What is the first project that you've started working on? +SARA: I don't know if you happen to be a fan of animation or cartoons, but I love "Gravity Falls." And there's a character, Mabel, who wears many sweaters. I'm working on a sweater. +JOËL: Inspired by this character. +SARA: Yes. It is a Herculean endeavor for my first crochet project, but we're in it now. +JOËL: That does sound like jumping into it and picking a pretty hard project. Is that the way you typically approach new hobbies or new things, you just kind of jump in and pick up something challenging? +SARA: Yeah. I definitely think that's a good description of how I approach hobbies. How about you? +JOËL: I think I like to ease into things. I'm the kind of person who, if I pick up a video game, I will play the tutorial. +SARA: It's so funny you say that because I'm definitely the type of person who also reads manuals. [chuckles] +JOËL: [laughs] I'm sure you've probably, at this point, read many sections of the Unix manual. Longtime listeners might recognize you from a previous episode we did on the history of operating systems. +SARA: Yes, I am an avid reader of the man pages. In fact, I wish every command-line tool had man pages or at least more detailed man pages. Reading man pages, reading technical documentation, really, I feel like goes right in line with things like needlework, knitting, crocheting. You're following a very technical pattern description of what you should be doing, how many stitches. It's almost algorithmic. +JOËL: Do you feel like the fact that you've read a lot of man pages and now that you're getting into reading crochet patterns, do you feel like that's helped you maybe become a better technical writer when you write documentation? +SARA: Definitely. Yes. [laughs] There's a common meme going around on the internet of how to make a peanut butter and jelly sandwich: open jar, put knife in jar. And you see somebody putting the knife in handle first because it wasn't specific enough. When you're looking at a crochet pattern, it needs to be written very explicitly, and in the same way, technical documentation needs to be like that too. It needs to be accessible for every audience, well, most audiences. +JOËL: That's a big challenge because you want to give enough detail that, like you said, you don't accidentally use the wrong end of the knife to spread your peanut butter. But at the same time, if you give all the little details, you lose the forest for the trees. And people who know how to use a knife are going to struggle to use your documentation. +SARA: That is true. That's why I think it is very valuable to do something that you recommend very often, especially when writing blog posts or call for papers is, defining the audience. Who's this for? +JOËL: Yeah, knowing your audience is so important when it comes to any kind of media, even if it's a talk or an article, or I guess, a crochet pattern. +SARA: Precisely. +JOËL: Does the crochet world have sort of the concept of patterns aimed at beginners versus patterns aimed at a more advanced audience? +SARA: I would definitely say that is the case. There are more advanced stitches and techniques that you would generally not see in a more beginner pattern. And in more advanced patterns, at least speaking from a knitting perspective...I'm pretty new to crocheting, but I've been knitting for a while. In knitting patterns, simpler techniques might not be described in such detail in a more advanced pattern. +JOËL: So a couple of weeks ago, Stephanie and I were discussing the fundamentals, how much of the fundamentals of web development line up with a computer science degree. I had made this comment on that episode that my pick for most underrated CS class that I think would benefit most developers is a class called discrete math. +SARA: I remember this class. It was a love-hate relationship. I am a big fan. +JOËL: Would you describe yourself as a math person? +SARA: I don't think so. No. +JOËL: Because I know I hated math for the longest time. And I don't really find that math, in general, has been that helpful for software. There's kind of the stereotype that I'll sometimes hear from people when they find out that I write code for a living. They'll say things like, "Oh, you must be so good at math." And it's like, no, calculus was really hard for me, and I struggled and did not like it. +SARA: I feel like that's a big reason why folks go into programming; the computer can do the math for you. +JOËL: Right? It is a computer. It is a math machine. +SARA: I mean, how many folks in computer-related fields got their start on a TI-83, programming in that thing? +JOËL: A lot of people. Someday it might be fun to do an episode on the sort of common origin stories that you hear from people in the software industry, a lot of people programming a calculator, a lot of people I hear coming from Neopets. +SARA: Yeah, Neopets and MySpace, editing the profile pages with CSS, HTML. +JOËL: But that's an episode for another time. I think, in my experience, discrete math was not like all the other math that I did. It felt so practical, like, this is math for programmers is how I felt it was even though that's not how it's sold in university. What was your experience? +SARA: My concept was very much like, this is logic. This is very hard. By hard, I mean firm way of looking at the world and defining the logic behind things when you think about proofs and set theory. +JOËL: So we've been throwing around the term discrete math, and many of our listeners might not be familiar with what it is. If you had to describe discrete math to someone who is not familiar with it, what would you say? +SARA: Math that's discrete. [laughter] Sorry, sorry. +JOËL: What does discrete mean? +SARA: When I think of discrete math, I think of logic, definitions, how data relates to each other, that sort of thing, as opposed to ones and zeros. +JOËL: Yeah, discrete math; it felt like it was very much like a grab-bag class. It just involved so many different branches of math, and you kind of get a little bit of an intro of like ten different topics, all of which apply and are helpful when you're writing software. So I got a little intro to a couple of different forms of logic, propositional logic, and predicate logic. I got an intro to Boolean algebra. +I got an intro to set theory, an intro to combinatorics, talked about recursive functions from a mathematical perspective, an intro to graph theory. Probably like a few more. There are like ten different things. You just got a little intro to them, spent a couple of weeks on each topic. But I felt like that was enough to give me a lot of value that I still reference on a daily basis in my work. +SARA: Absolutely. One of the parts of discrete math that really stuck with me are computational models like Turing machines, pushdown automaton, finite-state machines. Learning about those, analyzing them really helped me break down algorithms and break down my code and look at, okay, for this specific input that I have for each of these variables, what are we doing? +JOËL: So what does that look like in your daily work? You've got a complex card, and you see that it's a difficult feature to implement. And in your mind, you say, okay, let me try to describe this as a finite-state machine, and maybe you draw a diagram or something like that. +SARA: Yeah, I will, actually. I'll draw a diagram, or I'll draw like a pseudocode out on paper. I'll think about all the different kinds of inputs that I would expect or not expect, which itself is not finite, but we try. And then what is the output that I would expect? What is the outcome that I would expect from, say, a user enters one, a user enters Sara, a user enters purple? What would the outcome be? Do I have those vectors captured in my code? And that also goes into TDD. +JOËL: Do you feel like knowing about Turing machines or finite-state machines has made it easier for you to PDD? That's a connection I haven't heard before. +SARA: Yeah, I think so because a Turing complete computational model is deterministic. That means that every possible path that could be got into from where you're at any path exists between the two. Sometimes it might mean rejection or an error, but the path has been defined. And thinking about that when it comes to tests, I feel like has been so helpful for me of like, I can't just think about the happy path. I can't just think about it's exactly what it needs to be. It's also what if it's not there? What if it doesn't exist? What if it's 0? What if it's empty? What if it's a different data structure? +JOËL: That's really fascinating to me because I feel like I encountered some of these practical applications of it much later when I was learning about types and learning about Elm and sort of that community's approach to designing data structures. And one thing that they say a lot is that you should make impossible states impossible when you design a type, and the way that they tend to approach that is thinking of types as if they were sets. +And so you think of a set of...the Boolean type is a set that has two elements because there are true and false. An enum might have, you know, if it's a three-element enum, that is, three elements. But then you start having things like records which are kind of like a hash in Ruby, which might have, let's say, two elements in them. And if it has a Boolean and an enum value, now those two multiply times each other. And so now you have two times three, six possible states. And maybe the problem you're trying to model only has five, and so you've sort of inadvertently added an extra state. +They tend to talk about it a little bit more through the lens of sets and the lens of combinatorics, which are other elements of discrete math that give you mental models to deal with this. And so talking about all the different possibilities, that's combinatorics. Thinking of a type as a set and talking about its cardinality, that's set theory. So those were things that I would do when I was writing Elm programs on a daily basis, but I never made the connection back to finite-state machines. +SARA: I feel like those marry so well together, those concepts. You can see combinatorics and set theory of objects and of where they can go. And that goes right into graph theory. +JOËL: Oooh, I love me some graphs. +SARA: [laughs] +JOËL: Listeners of the show will know that I am a huge fan of dependency graphs and as a tool and as a model that can be applied to a lot of things, so thinking in terms of maybe the dependencies of your program like packages. But it can also be in terms of tasks to be done and so thinking in terms of a larger feature, breaking it down into smaller features, all of which depend on each other. And depending on how that dependency graph is structured, what order do you need to complete them in order to ship them independently? +SARA: I love that. And it reminds me of graphs that represent state, like, finite-state machines sort of things where you can actually infer where you're going to end up based on where you are for certain types of graphs. And I feel like you can use that in programming. You can use that in proofs where you have the, okay, you've solved for the zero case. You've solved for the one case. Now let's solve for N+1 anytime in the future. This all feels very full circle in my mind. [chuckles] +JOËL: I think that's very apt. And a really powerful thing that I've noticed is having different mental models to approach the same problem or different logical or analysis techniques to interact with the same problem. And so when you look at something through the lens of a finite-state machine, or through the lens of a graph, or through the lens of a set, or through the lens of combinatorics, you might be looking at the same problem. But by having different perspectives to look at it, you gain different insight and hopefully helps you come to a better solution. +SARA: Absolutely. And I love that discrete math gives us those different tools to be better programmers. It's something that I enjoy. And I enjoyed the classes as much as they were extremely difficult. And I love the idea of being able to share those tools with other people that might not have learned about them. +JOËL: You were talking about seeing things from different perspectives and how they kind of line up. There are some equivalences that I found were really fun between, let's say, sets and Boolean algebra, the operations that you can do. So things like ANDing two values is similar to doing an intersection on two sets, and ORing two values is similar to doing a union. Interestingly, we have preserved that in Ruby. Array has operators where you can combine arrays using set operations, and it has the single pipe, which we typically read as OR to union two arrays. I want to say it has a single AND that you can use. It's used to intersect two arrays. +SARA: I actually used that sometime within the last year, I remember. +JOËL: So, if you've ever wondered why those two particular operators to do set operations instead of a union method, now you know. +SARA: I love set operations. I recently made an update to thoughtbot's internal tool hub, and I used set unions there. [laughs] +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: If you had to sell a colleague on the value of discrete math, what would be the example that you would use? +SARA: What if I told you that you would never have to wonder what the results might be in a given situation of true and false? +JOËL: That's deep. Do you want to know all the secrets of the universe? +SARA: Let me introduce to you truth tables. +JOËL: Oh, I love a good truth table. Yes, such a simple tool, but it pays so much. +SARA: Absolutely, especially in a world where we have unless as an operator. +JOËL: Unless gets me so much in Ruby, especially when there are compound expressions. So you say do something unless condition one or condition two, and then I have to think, wait, when does this happen? +SARA: I have to read it to myself in English, not this and not that. [chuckles] +JOËL: So that's interesting because when you translated that in English, you changed the operator that's being used. +SARA: I totally did. +JOËL: Unless a condition or other condition. And your brain was smart enough to flip that; mine is not. +SARA: [laughs] +JOËL: But what's happening here is, and you would learn this in a discrete math class, De Morgan's Laws that say what happens when you negate compound conditions. And you have to negate each of the individual conditions and also flip all the operators, so all the ANDs turn into ORs and the ORs turn into ANDs. And so I always have to remember to do that in my mind when I see an unless or when I see someone negating a compound condition. +So now, in my mind, every time I'm reviewing code on a pull request, and I see negating a compound condition, it's just a sort of red flag for there's quite possibly a bug here. And maybe leave a comment asking the author, "Did you really mean to do this?" And like you said, maybe even write out a truth table just so that myself I know that the correct behavior is happening. +SARA: It is a good example of a code smell because if it's hard for you to understand or me to understand, sure, it made sense when it was written, but code is read more than it's written. It should be easy to read and understand. So it's definitely easy to introduce a bug at that point like you were saying, worth commenting on. +JOËL: You log on to your machine at the beginning of the day, open up a PR, and you're just like, oh yes, I love the smell of De Morgan in the morning. +SARA: [laughs] Nothing like De Morgan in your cup in the morning. +JOËL: [laughs] Yes. Oh, now I really want to -- +SARA: A DeMorgan in the morgen. +[laughter] +JOËL: Now I really want to see a spoof of that Folgers ad. +SARA: [laughs] For some reason, the jingle is escaping me, but it's there. +JOËL: It's an ad for a brand of American coffee. +SARA: Yes, for those that were not in America during the '90s to see the commercial, [singing] the best part of waking up is De Morgan in your cup. +JOËL: [chuckles] That was amazing. +SARA: [laughs] Hopefully, we don't get a copyright strike for that. +[laughter] +JOËL: You know what? That is the sell for why you should learn discrete math. +SARA: Yes. What are some other ways you find discrete math around in your day-to-day life? +JOËL: I think the most practical part is working with Booleans because writing conditional code writing Boolean expressions is something that I do multiple times every day. And I think anybody who's done programming for any length of time gets some amount of intuition around working with Boolean expressions. Having spent a little bit of time studying them, you learn some patterns. You learn ways of working with them. +And a common thing that I will often see in Ruby code is people will overuse the if expression when you could have used a Boolean expression instead. So I've seen things like if condition return true, else return false, which is just identity. I've also seen more complex things which will say, "If value one is true and value two is true, return true; otherwise, return false," or some fancy things with early returns that, in the end, are just reimplementing Boolean AND. +So knowing about a little bit of basic Boolean algebra, being comfortable with combining things using AND and OR rather than just writing early returns, I think, gives a much richer toolkit and something that is much more scalable. And, of course, for those situations where there are complex conditional code, having truth tables as a tool in your back pocket is just absolutely invaluable. +SARA: 100%. When those get so complex, definitely realizing it's worth maybe breaking up a chain of Boolean logic into separate mini-methods if you need to. There's nothing like seeing a whole bunch of stuff ANDed together that are only kind of related. [laughs] +JOËL: There's a form of logic that you dig into as well called predicate logic, and there's a whole set of things you can do with it. But two things that stood out to me were these two operators that apply a condition to a whole set of values. And they either claim that a certain thing is true for at least one of the elements in a set or for every value in a set. +And the interesting thing is that if you claim that something is true for all elements, in order to falsify that claim, you only need to find one counterexample. You don't need to check every item. If I can find one, and maybe it's the first item in this set that is wrong or that contradicts the logical statement that I'm trying to make, then I've immediately disproved your entire statement because you claimed that this was true for every element. +SARA: And it's hard learning these sorts of fundamentals from computer science; it's hard to not apply that to real life and hear somebody using a statement, "Every this, all of that." I immediately come back with, "Well, some of them." [laughs] I'm that guy, yep. +JOËL: The person at the end of a conference talk who puts up their hand and says, "So this is not really a question. It's more of a statement." +SARA: [laughs] I found this one example. Yeah, I'm a stickler for specificity, for sure. Thanks, discrete math. +JOËL: It definitely helped me be much more nuanced in the way that I speak. I tend to not speak in absolutes or superlatives because of that class. +SARA: Yeah, I very frequently use the term a non-zero amount of times to describe, for example, there exists one in a set. +JOËL: There's also another interesting aspect of this, which is when you see a chain of ANDs, so condition, and condition, and condition, and condition, and condition, you're effectively making the assertion that something is true for all elements or that all these conditions are true. Therefore, it only takes one for the whole thing to evaluate to false. And I want to say the fancy name for this is annihilation, where you can have a giant chain of conditions that are ANDed together, and they're all true, but if any single one of them is false, then the whole chain evaluates to false. +SARA: And this is where you can get a little clever with the order in which you put those in your AND where you have the least heavy lifting checks first so that they fail first. Or if you have things that need to check for nil, check them after. Check the basic stuff first. Let it almost short circuit; let it fail fast, as they say. +JOËL: Yeah, these are all performance tricks that I think, even if you don't have a discrete math background, you might have picked up. You know about short-circuiting. You know about trying the cheap checks first. And now you know a little bit of the theoretical background of why. +SARA: [singing] Where do we go from here? [laughs] +JOËL: So we have these sort of logical operators that will claim that something is true for all elements of a set or at least one element of a set, and those are kind of theoretical. They're useful if we're trying to set up a logical proposition. But these exist in code, in Ruby, as part of the enumerable module. Enumerable has two methods; they are any and all. And you can use those methods to claim that all items in an array will evaluate to true when the given block runs or that at least one evaluates to true for items in that array. +SARA: What's the word where you're taking out some of a set? Slice but not slice. There's intersection [crosstalk 26:46] union, so not a set theory one, no. +JOËL: Like getting the inverse? +SARA: Maybe. I don't know. +JOËL: I feel like there's a term for getting the inverse of a set. +SARA: Not the inverse. +JOËL: Because you can get the inverse of the intersection or something. +SARA: Yeah. I think I'm just going to go along the lines of being able to slice out what you want with select and how you can then chain an enumerable on that. +JOËL: Okay. Okay, I see. So you're making a connection from enumerable to set theory. +SARA: Mm-hmm. +JOËL: Excellent. +SARA: Even if you don't necessarily want every item in your enumerable, your array, your hash, you can use things like select and reject to get a subset for a certain condition, and you can slice out based on a condition. And then you can then apply any or all to that. And so I want all of the even numbers, and now for all of these even numbers, such and such should be true for the set. +JOËL: So now we've made a connection between enumerable and predicate logic. And we've also made a connection to set theory. +SARA: It's coming full circle again. [laughs] Discrete math is everywhere. +JOËL: So if you use the enumerable module in Ruby, which you should be (It's one of the best parts of the language.), you're doing discrete math every day, and you didn't know it. +SARA: You're welcome. +JOËL: So we've seen that a lot of us are interacting with elements of discrete math every day and that learning a little bit about it more formally can help us be a bit more mindful in how we code every day. It can give us the mental models to solve and analyze problems that we encounter daily. For those listeners who might want to dig a little bit more deeply into discrete math, do you have any resources there that you recommend? +SARA: Well, not sponsored, but brilliant.org is a pretty good resource for things like math, computer science, for the very least. I'm sure it has other courses, but those are the ones that I've kind of looked at on some YouTubers' free trial. [chuckles] And I liked their approach to teaching, and I think it has got a low barrier to entry for learning these topics. I would definitely recommend that, so brilliant.org +JOËL: It's funny you mentioned that they sponsor a lot of technology, science, and math YouTubers. So for those listeners who are interested in checking it out, maybe look up some YouTubers and see if they have a free sign-up code. +SARA: Mayuko is a good YouTuber for that. I believe she gets sponsored by Brilliant occasionally. She's a software engineer out in California. +JOËL: Clearly, we're not sponsored because we don't have a code to give out. +SARA: [laughs] Sponsor us, Brilliant. +JOËL: [laughs] Host at bikeshed.fm +SARA: [laughs] +JOËL: All right. Well, with that, shall we wrap up? +SARA: Yeah, let's do. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël is joined by a very special guest, Sara Jackson, a fellow Software Developer at thoughtbot.

+ +

A few episodes ago, Stephanie and Joël talked about "The Fundamentals" and how many of the fundamentals of web development line up with a Computer Science degree. Joël made a comment during that episode that his pick for the most underrated CS class that he thinks would benefit most devs is a class called
+"Discrete Math." Sara weighs in!

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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. And today, I'm joined by a special guest, Sara Jackson, who is a fellow developer here at thoughtbot.

+ +

SARA: Hello.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world?

+ +

SARA: Actually, I recently picked up crocheting.

+ +

JOËL: That's exciting. What is the first project that you've started working on?

+ +

SARA: I don't know if you happen to be a fan of animation or cartoons, but I love "Gravity Falls." And there's a character, Mabel, who wears many sweaters. I'm working on a sweater.

+ +

JOËL: Inspired by this character.

+ +

SARA: Yes. It is a Herculean endeavor for my first crochet project, but we're in it now.

+ +

JOËL: That does sound like jumping into it and picking a pretty hard project. Is that the way you typically approach new hobbies or new things, you just kind of jump in and pick up something challenging?

+ +

SARA: Yeah. I definitely think that's a good description of how I approach hobbies. How about you?

+ +

JOËL: I think I like to ease into things. I'm the kind of person who, if I pick up a video game, I will play the tutorial.

+ +

SARA: It's so funny you say that because I'm definitely the type of person who also reads manuals. [chuckles]

+ +

JOËL: [laughs] I'm sure you've probably, at this point, read many sections of the Unix manual. Longtime listeners might recognize you from a previous episode we did on the history of operating systems.

+ +

SARA: Yes, I am an avid reader of the man pages. In fact, I wish every command-line tool had man pages or at least more detailed man pages. Reading man pages, reading technical documentation, really, I feel like goes right in line with things like needlework, knitting, crocheting. You're following a very technical pattern description of what you should be doing, how many stitches. It's almost algorithmic.

+ +

JOËL: Do you feel like the fact that you've read a lot of man pages and now that you're getting into reading crochet patterns, do you feel like that's helped you maybe become a better technical writer when you write documentation?

+ +

SARA: Definitely. Yes. [laughs] There's a common meme going around on the internet of how to make a peanut butter and jelly sandwich: open jar, put knife in jar. And you see somebody putting the knife in handle first because it wasn't specific enough. When you're looking at a crochet pattern, it needs to be written very explicitly, and in the same way, technical documentation needs to be like that too. It needs to be accessible for every audience, well, most audiences.

+ +

JOËL: That's a big challenge because you want to give enough detail that, like you said, you don't accidentally use the wrong end of the knife to spread your peanut butter. But at the same time, if you give all the little details, you lose the forest for the trees. And people who know how to use a knife are going to struggle to use your documentation.

+ +

SARA: That is true. That's why I think it is very valuable to do something that you recommend very often, especially when writing blog posts or call for papers is, defining the audience. Who's this for?

+ +

JOËL: Yeah, knowing your audience is so important when it comes to any kind of media, even if it's a talk or an article, or I guess, a crochet pattern.

+ +

SARA: Precisely.

+ +

JOËL: Does the crochet world have sort of the concept of patterns aimed at beginners versus patterns aimed at a more advanced audience?

+ +

SARA: I would definitely say that is the case. There are more advanced stitches and techniques that you would generally not see in a more beginner pattern. And in more advanced patterns, at least speaking from a knitting perspective...I'm pretty new to crocheting, but I've been knitting for a while. In knitting patterns, simpler techniques might not be described in such detail in a more advanced pattern.

+ +

JOËL: So a couple of weeks ago, Stephanie and I were discussing the fundamentals, how much of the fundamentals of web development line up with a computer science degree. I had made this comment on that episode that my pick for most underrated CS class that I think would benefit most developers is a class called discrete math.

+ +

SARA: I remember this class. It was a love-hate relationship. I am a big fan.

+ +

JOËL: Would you describe yourself as a math person?

+ +

SARA: I don't think so. No.

+ +

JOËL: Because I know I hated math for the longest time. And I don't really find that math, in general, has been that helpful for software. There's kind of the stereotype that I'll sometimes hear from people when they find out that I write code for a living. They'll say things like, "Oh, you must be so good at math." And it's like, no, calculus was really hard for me, and I struggled and did not like it.

+ +

SARA: I feel like that's a big reason why folks go into programming; the computer can do the math for you.

+ +

JOËL: Right? It is a computer. It is a math machine.

+ +

SARA: I mean, how many folks in computer-related fields got their start on a TI-83, programming in that thing?

+ +

JOËL: A lot of people. Someday it might be fun to do an episode on the sort of common origin stories that you hear from people in the software industry, a lot of people programming a calculator, a lot of people I hear coming from Neopets.

+ +

SARA: Yeah, Neopets and MySpace, editing the profile pages with CSS, HTML.

+ +

JOËL: But that's an episode for another time. I think, in my experience, discrete math was not like all the other math that I did. It felt so practical, like, this is math for programmers is how I felt it was even though that's not how it's sold in university. What was your experience?

+ +

SARA: My concept was very much like, this is logic. This is very hard. By hard, I mean firm way of looking at the world and defining the logic behind things when you think about proofs and set theory.

+ +

JOËL: So we've been throwing around the term discrete math, and many of our listeners might not be familiar with what it is. If you had to describe discrete math to someone who is not familiar with it, what would you say?

+ +

SARA: Math that's discrete. [laughter] Sorry, sorry.

+ +

JOËL: What does discrete mean?

+ +

SARA: When I think of discrete math, I think of logic, definitions, how data relates to each other, that sort of thing, as opposed to ones and zeros.

+ +

JOËL: Yeah, discrete math; it felt like it was very much like a grab-bag class. It just involved so many different branches of math, and you kind of get a little bit of an intro of like ten different topics, all of which apply and are helpful when you're writing software. So I got a little intro to a couple of different forms of logic, propositional logic, and predicate logic. I got an intro to Boolean algebra.

+ +

I got an intro to set theory, an intro to combinatorics, talked about recursive functions from a mathematical perspective, an intro to graph theory. Probably like a few more. There are like ten different things. You just got a little intro to them, spent a couple of weeks on each topic. But I felt like that was enough to give me a lot of value that I still reference on a daily basis in my work.

+ +

SARA: Absolutely. One of the parts of discrete math that really stuck with me are computational models like Turing machines, pushdown automaton, finite-state machines. Learning about those, analyzing them really helped me break down algorithms and break down my code and look at, okay, for this specific input that I have for each of these variables, what are we doing?

+ +

JOËL: So what does that look like in your daily work? You've got a complex card, and you see that it's a difficult feature to implement. And in your mind, you say, okay, let me try to describe this as a finite-state machine, and maybe you draw a diagram or something like that.

+ +

SARA: Yeah, I will, actually. I'll draw a diagram, or I'll draw like a pseudocode out on paper. I'll think about all the different kinds of inputs that I would expect or not expect, which itself is not finite, but we try. And then what is the output that I would expect? What is the outcome that I would expect from, say, a user enters one, a user enters Sara, a user enters purple? What would the outcome be? Do I have those vectors captured in my code? And that also goes into TDD.

+ +

JOËL: Do you feel like knowing about Turing machines or finite-state machines has made it easier for you to PDD? That's a connection I haven't heard before.

+ +

SARA: Yeah, I think so because a Turing complete computational model is deterministic. That means that every possible path that could be got into from where you're at any path exists between the two. Sometimes it might mean rejection or an error, but the path has been defined. And thinking about that when it comes to tests, I feel like has been so helpful for me of like, I can't just think about the happy path. I can't just think about it's exactly what it needs to be. It's also what if it's not there? What if it doesn't exist? What if it's 0? What if it's empty? What if it's a different data structure?

+ +

JOËL: That's really fascinating to me because I feel like I encountered some of these practical applications of it much later when I was learning about types and learning about Elm and sort of that community's approach to designing data structures. And one thing that they say a lot is that you should make impossible states impossible when you design a type, and the way that they tend to approach that is thinking of types as if they were sets.

+ +

And so you think of a set of...the Boolean type is a set that has two elements because there are true and false. An enum might have, you know, if it's a three-element enum, that is, three elements. But then you start having things like records which are kind of like a hash in Ruby, which might have, let's say, two elements in them. And if it has a Boolean and an enum value, now those two multiply times each other. And so now you have two times three, six possible states. And maybe the problem you're trying to model only has five, and so you've sort of inadvertently added an extra state.

+ +

They tend to talk about it a little bit more through the lens of sets and the lens of combinatorics, which are other elements of discrete math that give you mental models to deal with this. And so talking about all the different possibilities, that's combinatorics. Thinking of a type as a set and talking about its cardinality, that's set theory. So those were things that I would do when I was writing Elm programs on a daily basis, but I never made the connection back to finite-state machines.

+ +

SARA: I feel like those marry so well together, those concepts. You can see combinatorics and set theory of objects and of where they can go. And that goes right into graph theory.

+ +

JOËL: Oooh, I love me some graphs.

+ +

SARA: [laughs]

+ +

JOËL: Listeners of the show will know that I am a huge fan of dependency graphs and as a tool and as a model that can be applied to a lot of things, so thinking in terms of maybe the dependencies of your program like packages. But it can also be in terms of tasks to be done and so thinking in terms of a larger feature, breaking it down into smaller features, all of which depend on each other. And depending on how that dependency graph is structured, what order do you need to complete them in order to ship them independently?

+ +

SARA: I love that. And it reminds me of graphs that represent state, like, finite-state machines sort of things where you can actually infer where you're going to end up based on where you are for certain types of graphs. And I feel like you can use that in programming. You can use that in proofs where you have the, okay, you've solved for the zero case. You've solved for the one case. Now let's solve for N+1 anytime in the future. This all feels very full circle in my mind. [chuckles]

+ +

JOËL: I think that's very apt. And a really powerful thing that I've noticed is having different mental models to approach the same problem or different logical or analysis techniques to interact with the same problem. And so when you look at something through the lens of a finite-state machine, or through the lens of a graph, or through the lens of a set, or through the lens of combinatorics, you might be looking at the same problem. But by having different perspectives to look at it, you gain different insight and hopefully helps you come to a better solution.

+ +

SARA: Absolutely. And I love that discrete math gives us those different tools to be better programmers. It's something that I enjoy. And I enjoyed the classes as much as they were extremely difficult. And I love the idea of being able to share those tools with other people that might not have learned about them.

+ +

JOËL: You were talking about seeing things from different perspectives and how they kind of line up. There are some equivalences that I found were really fun between, let's say, sets and Boolean algebra, the operations that you can do. So things like ANDing two values is similar to doing an intersection on two sets, and ORing two values is similar to doing a union. Interestingly, we have preserved that in Ruby. Array has operators where you can combine arrays using set operations, and it has the single pipe, which we typically read as OR to union two arrays. I want to say it has a single AND that you can use. It's used to intersect two arrays.

+ +

SARA: I actually used that sometime within the last year, I remember.

+ +

JOËL: So, if you've ever wondered why those two particular operators to do set operations instead of a union method, now you know.

+ +

SARA: I love set operations. I recently made an update to thoughtbot's internal tool hub, and I used set unions there. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: If you had to sell a colleague on the value of discrete math, what would be the example that you would use?

+ +

SARA: What if I told you that you would never have to wonder what the results might be in a given situation of true and false?

+ +

JOËL: That's deep. Do you want to know all the secrets of the universe?

+ +

SARA: Let me introduce to you truth tables.

+ +

JOËL: Oh, I love a good truth table. Yes, such a simple tool, but it pays so much.

+ +

SARA: Absolutely, especially in a world where we have unless as an operator.

+ +

JOËL: Unless gets me so much in Ruby, especially when there are compound expressions. So you say do something unless condition one or condition two, and then I have to think, wait, when does this happen?

+ +

SARA: I have to read it to myself in English, not this and not that. [chuckles]

+ +

JOËL: So that's interesting because when you translated that in English, you changed the operator that's being used.

+ +

SARA: I totally did.

+ +

JOËL: Unless a condition or other condition. And your brain was smart enough to flip that; mine is not.

+ +

SARA: [laughs]

+ +

JOËL: But what's happening here is, and you would learn this in a discrete math class, De Morgan's Laws that say what happens when you negate compound conditions. And you have to negate each of the individual conditions and also flip all the operators, so all the ANDs turn into ORs and the ORs turn into ANDs. And so I always have to remember to do that in my mind when I see an unless or when I see someone negating a compound condition.

+ +

So now, in my mind, every time I'm reviewing code on a pull request, and I see negating a compound condition, it's just a sort of red flag for there's quite possibly a bug here. And maybe leave a comment asking the author, "Did you really mean to do this?" And like you said, maybe even write out a truth table just so that myself I know that the correct behavior is happening.

+ +

SARA: It is a good example of a code smell because if it's hard for you to understand or me to understand, sure, it made sense when it was written, but code is read more than it's written. It should be easy to read and understand. So it's definitely easy to introduce a bug at that point like you were saying, worth commenting on.

+ +

JOËL: You log on to your machine at the beginning of the day, open up a PR, and you're just like, oh yes, I love the smell of De Morgan in the morning.

+ +

SARA: [laughs] Nothing like De Morgan in your cup in the morning.

+ +

JOËL: [laughs] Yes. Oh, now I really want to --

+ +

SARA: A DeMorgan in the morgen.

+ +

[laughter]

+ +

JOËL: Now I really want to see a spoof of that Folgers ad.

+ +

SARA: [laughs] For some reason, the jingle is escaping me, but it's there.

+ +

JOËL: It's an ad for a brand of American coffee.

+ +

SARA: Yes, for those that were not in America during the '90s to see the commercial, [singing] the best part of waking up is De Morgan in your cup.

+ +

JOËL: [chuckles] That was amazing.

+ +

SARA: [laughs] Hopefully, we don't get a copyright strike for that.

+ +

[laughter]

+ +

JOËL: You know what? That is the sell for why you should learn discrete math.

+ +

SARA: Yes. What are some other ways you find discrete math around in your day-to-day life?

+ +

JOËL: I think the most practical part is working with Booleans because writing conditional code writing Boolean expressions is something that I do multiple times every day. And I think anybody who's done programming for any length of time gets some amount of intuition around working with Boolean expressions. Having spent a little bit of time studying them, you learn some patterns. You learn ways of working with them.

+ +

And a common thing that I will often see in Ruby code is people will overuse the if expression when you could have used a Boolean expression instead. So I've seen things like if condition return true, else return false, which is just identity. I've also seen more complex things which will say, "If value one is true and value two is true, return true; otherwise, return false," or some fancy things with early returns that, in the end, are just reimplementing Boolean AND.

+ +

So knowing about a little bit of basic Boolean algebra, being comfortable with combining things using AND and OR rather than just writing early returns, I think, gives a much richer toolkit and something that is much more scalable. And, of course, for those situations where there are complex conditional code, having truth tables as a tool in your back pocket is just absolutely invaluable.

+ +

SARA: 100%. When those get so complex, definitely realizing it's worth maybe breaking up a chain of Boolean logic into separate mini-methods if you need to. There's nothing like seeing a whole bunch of stuff ANDed together that are only kind of related. [laughs]

+ +

JOËL: There's a form of logic that you dig into as well called predicate logic, and there's a whole set of things you can do with it. But two things that stood out to me were these two operators that apply a condition to a whole set of values. And they either claim that a certain thing is true for at least one of the elements in a set or for every value in a set.

+ +

And the interesting thing is that if you claim that something is true for all elements, in order to falsify that claim, you only need to find one counterexample. You don't need to check every item. If I can find one, and maybe it's the first item in this set that is wrong or that contradicts the logical statement that I'm trying to make, then I've immediately disproved your entire statement because you claimed that this was true for every element.

+ +

SARA: And it's hard learning these sorts of fundamentals from computer science; it's hard to not apply that to real life and hear somebody using a statement, "Every this, all of that." I immediately come back with, "Well, some of them." [laughs] I'm that guy, yep.

+ +

JOËL: The person at the end of a conference talk who puts up their hand and says, "So this is not really a question. It's more of a statement."

+ +

SARA: [laughs] I found this one example. Yeah, I'm a stickler for specificity, for sure. Thanks, discrete math.

+ +

JOËL: It definitely helped me be much more nuanced in the way that I speak. I tend to not speak in absolutes or superlatives because of that class.

+ +

SARA: Yeah, I very frequently use the term a non-zero amount of times to describe, for example, there exists one in a set.

+ +

JOËL: There's also another interesting aspect of this, which is when you see a chain of ANDs, so condition, and condition, and condition, and condition, and condition, you're effectively making the assertion that something is true for all elements or that all these conditions are true. Therefore, it only takes one for the whole thing to evaluate to false. And I want to say the fancy name for this is annihilation, where you can have a giant chain of conditions that are ANDed together, and they're all true, but if any single one of them is false, then the whole chain evaluates to false.

+ +

SARA: And this is where you can get a little clever with the order in which you put those in your AND where you have the least heavy lifting checks first so that they fail first. Or if you have things that need to check for nil, check them after. Check the basic stuff first. Let it almost short circuit; let it fail fast, as they say.

+ +

JOËL: Yeah, these are all performance tricks that I think, even if you don't have a discrete math background, you might have picked up. You know about short-circuiting. You know about trying the cheap checks first. And now you know a little bit of the theoretical background of why.

+ +

SARA: [singing] Where do we go from here? [laughs]

+ +

JOËL: So we have these sort of logical operators that will claim that something is true for all elements of a set or at least one element of a set, and those are kind of theoretical. They're useful if we're trying to set up a logical proposition. But these exist in code, in Ruby, as part of the enumerable module. Enumerable has two methods; they are any and all. And you can use those methods to claim that all items in an array will evaluate to true when the given block runs or that at least one evaluates to true for items in that array.

+ +

SARA: What's the word where you're taking out some of a set? Slice but not slice. There's intersection [crosstalk 26:46] union, so not a set theory one, no.

+ +

JOËL: Like getting the inverse?

+ +

SARA: Maybe. I don't know.

+ +

JOËL: I feel like there's a term for getting the inverse of a set.

+ +

SARA: Not the inverse.

+ +

JOËL: Because you can get the inverse of the intersection or something.

+ +

SARA: Yeah. I think I'm just going to go along the lines of being able to slice out what you want with select and how you can then chain an enumerable on that.

+ +

JOËL: Okay. Okay, I see. So you're making a connection from enumerable to set theory.

+ +

SARA: Mm-hmm.

+ +

JOËL: Excellent.

+ +

SARA: Even if you don't necessarily want every item in your enumerable, your array, your hash, you can use things like select and reject to get a subset for a certain condition, and you can slice out based on a condition. And then you can then apply any or all to that. And so I want all of the even numbers, and now for all of these even numbers, such and such should be true for the set.

+ +

JOËL: So now we've made a connection between enumerable and predicate logic. And we've also made a connection to set theory.

+ +

SARA: It's coming full circle again. [laughs] Discrete math is everywhere.

+ +

JOËL: So if you use the enumerable module in Ruby, which you should be (It's one of the best parts of the language.), you're doing discrete math every day, and you didn't know it.

+ +

SARA: You're welcome.

+ +

JOËL: So we've seen that a lot of us are interacting with elements of discrete math every day and that learning a little bit about it more formally can help us be a bit more mindful in how we code every day. It can give us the mental models to solve and analyze problems that we encounter daily. For those listeners who might want to dig a little bit more deeply into discrete math, do you have any resources there that you recommend?

+ +

SARA: Well, not sponsored, but brilliant.org is a pretty good resource for things like math, computer science, for the very least. I'm sure it has other courses, but those are the ones that I've kind of looked at on some YouTubers' free trial. [chuckles] And I liked their approach to teaching, and I think it has got a low barrier to entry for learning these topics. I would definitely recommend that, so brilliant.org

+ +

JOËL: It's funny you mentioned that they sponsor a lot of technology, science, and math YouTubers. So for those listeners who are interested in checking it out, maybe look up some YouTubers and see if they have a free sign-up code.

+ +

SARA: Mayuko is a good YouTuber for that. I believe she gets sponsored by Brilliant occasionally. She's a software engineer out in California.

+ +

JOËL: Clearly, we're not sponsored because we don't have a code to give out.

+ +

SARA: [laughs] Sponsor us, Brilliant.

+ +

JOËL: [laughs] Host at bikeshed.fm

+ +

SARA: [laughs]

+ +

JOËL: All right. Well, with that, shall we wrap up?

+ +

SARA: Yeah, let's do.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël is joined by a very special guest, Sara Jackson, a fellow Software Developer at thoughtbot.

+ +

A few episodes ago, Stephanie and Joël talked about "The Fundamentals" and how many of the fundamentals of web development line up with a Computer Science degree. Joël made a comment during that episode that his pick for the most underrated CS class that he thinks would benefit most devs is a class called
+"Discrete Math." Sara weighs in!

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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. And today, I'm joined by a special guest, Sara Jackson, who is a fellow developer here at thoughtbot.

+ +

SARA: Hello.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world?

+ +

SARA: Actually, I recently picked up crocheting.

+ +

JOËL: That's exciting. What is the first project that you've started working on?

+ +

SARA: I don't know if you happen to be a fan of animation or cartoons, but I love "Gravity Falls." And there's a character, Mabel, who wears many sweaters. I'm working on a sweater.

+ +

JOËL: Inspired by this character.

+ +

SARA: Yes. It is a Herculean endeavor for my first crochet project, but we're in it now.

+ +

JOËL: That does sound like jumping into it and picking a pretty hard project. Is that the way you typically approach new hobbies or new things, you just kind of jump in and pick up something challenging?

+ +

SARA: Yeah. I definitely think that's a good description of how I approach hobbies. How about you?

+ +

JOËL: I think I like to ease into things. I'm the kind of person who, if I pick up a video game, I will play the tutorial.

+ +

SARA: It's so funny you say that because I'm definitely the type of person who also reads manuals. [chuckles]

+ +

JOËL: [laughs] I'm sure you've probably, at this point, read many sections of the Unix manual. Longtime listeners might recognize you from a previous episode we did on the history of operating systems.

+ +

SARA: Yes, I am an avid reader of the man pages. In fact, I wish every command-line tool had man pages or at least more detailed man pages. Reading man pages, reading technical documentation, really, I feel like goes right in line with things like needlework, knitting, crocheting. You're following a very technical pattern description of what you should be doing, how many stitches. It's almost algorithmic.

+ +

JOËL: Do you feel like the fact that you've read a lot of man pages and now that you're getting into reading crochet patterns, do you feel like that's helped you maybe become a better technical writer when you write documentation?

+ +

SARA: Definitely. Yes. [laughs] There's a common meme going around on the internet of how to make a peanut butter and jelly sandwich: open jar, put knife in jar. And you see somebody putting the knife in handle first because it wasn't specific enough. When you're looking at a crochet pattern, it needs to be written very explicitly, and in the same way, technical documentation needs to be like that too. It needs to be accessible for every audience, well, most audiences.

+ +

JOËL: That's a big challenge because you want to give enough detail that, like you said, you don't accidentally use the wrong end of the knife to spread your peanut butter. But at the same time, if you give all the little details, you lose the forest for the trees. And people who know how to use a knife are going to struggle to use your documentation.

+ +

SARA: That is true. That's why I think it is very valuable to do something that you recommend very often, especially when writing blog posts or call for papers is, defining the audience. Who's this for?

+ +

JOËL: Yeah, knowing your audience is so important when it comes to any kind of media, even if it's a talk or an article, or I guess, a crochet pattern.

+ +

SARA: Precisely.

+ +

JOËL: Does the crochet world have sort of the concept of patterns aimed at beginners versus patterns aimed at a more advanced audience?

+ +

SARA: I would definitely say that is the case. There are more advanced stitches and techniques that you would generally not see in a more beginner pattern. And in more advanced patterns, at least speaking from a knitting perspective...I'm pretty new to crocheting, but I've been knitting for a while. In knitting patterns, simpler techniques might not be described in such detail in a more advanced pattern.

+ +

JOËL: So a couple of weeks ago, Stephanie and I were discussing the fundamentals, how much of the fundamentals of web development line up with a computer science degree. I had made this comment on that episode that my pick for most underrated CS class that I think would benefit most developers is a class called discrete math.

+ +

SARA: I remember this class. It was a love-hate relationship. I am a big fan.

+ +

JOËL: Would you describe yourself as a math person?

+ +

SARA: I don't think so. No.

+ +

JOËL: Because I know I hated math for the longest time. And I don't really find that math, in general, has been that helpful for software. There's kind of the stereotype that I'll sometimes hear from people when they find out that I write code for a living. They'll say things like, "Oh, you must be so good at math." And it's like, no, calculus was really hard for me, and I struggled and did not like it.

+ +

SARA: I feel like that's a big reason why folks go into programming; the computer can do the math for you.

+ +

JOËL: Right? It is a computer. It is a math machine.

+ +

SARA: I mean, how many folks in computer-related fields got their start on a TI-83, programming in that thing?

+ +

JOËL: A lot of people. Someday it might be fun to do an episode on the sort of common origin stories that you hear from people in the software industry, a lot of people programming a calculator, a lot of people I hear coming from Neopets.

+ +

SARA: Yeah, Neopets and MySpace, editing the profile pages with CSS, HTML.

+ +

JOËL: But that's an episode for another time. I think, in my experience, discrete math was not like all the other math that I did. It felt so practical, like, this is math for programmers is how I felt it was even though that's not how it's sold in university. What was your experience?

+ +

SARA: My concept was very much like, this is logic. This is very hard. By hard, I mean firm way of looking at the world and defining the logic behind things when you think about proofs and set theory.

+ +

JOËL: So we've been throwing around the term discrete math, and many of our listeners might not be familiar with what it is. If you had to describe discrete math to someone who is not familiar with it, what would you say?

+ +

SARA: Math that's discrete. [laughter] Sorry, sorry.

+ +

JOËL: What does discrete mean?

+ +

SARA: When I think of discrete math, I think of logic, definitions, how data relates to each other, that sort of thing, as opposed to ones and zeros.

+ +

JOËL: Yeah, discrete math; it felt like it was very much like a grab-bag class. It just involved so many different branches of math, and you kind of get a little bit of an intro of like ten different topics, all of which apply and are helpful when you're writing software. So I got a little intro to a couple of different forms of logic, propositional logic, and predicate logic. I got an intro to Boolean algebra.

+ +

I got an intro to set theory, an intro to combinatorics, talked about recursive functions from a mathematical perspective, an intro to graph theory. Probably like a few more. There are like ten different things. You just got a little intro to them, spent a couple of weeks on each topic. But I felt like that was enough to give me a lot of value that I still reference on a daily basis in my work.

+ +

SARA: Absolutely. One of the parts of discrete math that really stuck with me are computational models like Turing machines, pushdown automaton, finite-state machines. Learning about those, analyzing them really helped me break down algorithms and break down my code and look at, okay, for this specific input that I have for each of these variables, what are we doing?

+ +

JOËL: So what does that look like in your daily work? You've got a complex card, and you see that it's a difficult feature to implement. And in your mind, you say, okay, let me try to describe this as a finite-state machine, and maybe you draw a diagram or something like that.

+ +

SARA: Yeah, I will, actually. I'll draw a diagram, or I'll draw like a pseudocode out on paper. I'll think about all the different kinds of inputs that I would expect or not expect, which itself is not finite, but we try. And then what is the output that I would expect? What is the outcome that I would expect from, say, a user enters one, a user enters Sara, a user enters purple? What would the outcome be? Do I have those vectors captured in my code? And that also goes into TDD.

+ +

JOËL: Do you feel like knowing about Turing machines or finite-state machines has made it easier for you to PDD? That's a connection I haven't heard before.

+ +

SARA: Yeah, I think so because a Turing complete computational model is deterministic. That means that every possible path that could be got into from where you're at any path exists between the two. Sometimes it might mean rejection or an error, but the path has been defined. And thinking about that when it comes to tests, I feel like has been so helpful for me of like, I can't just think about the happy path. I can't just think about it's exactly what it needs to be. It's also what if it's not there? What if it doesn't exist? What if it's 0? What if it's empty? What if it's a different data structure?

+ +

JOËL: That's really fascinating to me because I feel like I encountered some of these practical applications of it much later when I was learning about types and learning about Elm and sort of that community's approach to designing data structures. And one thing that they say a lot is that you should make impossible states impossible when you design a type, and the way that they tend to approach that is thinking of types as if they were sets.

+ +

And so you think of a set of...the Boolean type is a set that has two elements because there are true and false. An enum might have, you know, if it's a three-element enum, that is, three elements. But then you start having things like records which are kind of like a hash in Ruby, which might have, let's say, two elements in them. And if it has a Boolean and an enum value, now those two multiply times each other. And so now you have two times three, six possible states. And maybe the problem you're trying to model only has five, and so you've sort of inadvertently added an extra state.

+ +

They tend to talk about it a little bit more through the lens of sets and the lens of combinatorics, which are other elements of discrete math that give you mental models to deal with this. And so talking about all the different possibilities, that's combinatorics. Thinking of a type as a set and talking about its cardinality, that's set theory. So those were things that I would do when I was writing Elm programs on a daily basis, but I never made the connection back to finite-state machines.

+ +

SARA: I feel like those marry so well together, those concepts. You can see combinatorics and set theory of objects and of where they can go. And that goes right into graph theory.

+ +

JOËL: Oooh, I love me some graphs.

+ +

SARA: [laughs]

+ +

JOËL: Listeners of the show will know that I am a huge fan of dependency graphs and as a tool and as a model that can be applied to a lot of things, so thinking in terms of maybe the dependencies of your program like packages. But it can also be in terms of tasks to be done and so thinking in terms of a larger feature, breaking it down into smaller features, all of which depend on each other. And depending on how that dependency graph is structured, what order do you need to complete them in order to ship them independently?

+ +

SARA: I love that. And it reminds me of graphs that represent state, like, finite-state machines sort of things where you can actually infer where you're going to end up based on where you are for certain types of graphs. And I feel like you can use that in programming. You can use that in proofs where you have the, okay, you've solved for the zero case. You've solved for the one case. Now let's solve for N+1 anytime in the future. This all feels very full circle in my mind. [chuckles]

+ +

JOËL: I think that's very apt. And a really powerful thing that I've noticed is having different mental models to approach the same problem or different logical or analysis techniques to interact with the same problem. And so when you look at something through the lens of a finite-state machine, or through the lens of a graph, or through the lens of a set, or through the lens of combinatorics, you might be looking at the same problem. But by having different perspectives to look at it, you gain different insight and hopefully helps you come to a better solution.

+ +

SARA: Absolutely. And I love that discrete math gives us those different tools to be better programmers. It's something that I enjoy. And I enjoyed the classes as much as they were extremely difficult. And I love the idea of being able to share those tools with other people that might not have learned about them.

+ +

JOËL: You were talking about seeing things from different perspectives and how they kind of line up. There are some equivalences that I found were really fun between, let's say, sets and Boolean algebra, the operations that you can do. So things like ANDing two values is similar to doing an intersection on two sets, and ORing two values is similar to doing a union. Interestingly, we have preserved that in Ruby. Array has operators where you can combine arrays using set operations, and it has the single pipe, which we typically read as OR to union two arrays. I want to say it has a single AND that you can use. It's used to intersect two arrays.

+ +

SARA: I actually used that sometime within the last year, I remember.

+ +

JOËL: So, if you've ever wondered why those two particular operators to do set operations instead of a union method, now you know.

+ +

SARA: I love set operations. I recently made an update to thoughtbot's internal tool hub, and I used set unions there. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: If you had to sell a colleague on the value of discrete math, what would be the example that you would use?

+ +

SARA: What if I told you that you would never have to wonder what the results might be in a given situation of true and false?

+ +

JOËL: That's deep. Do you want to know all the secrets of the universe?

+ +

SARA: Let me introduce to you truth tables.

+ +

JOËL: Oh, I love a good truth table. Yes, such a simple tool, but it pays so much.

+ +

SARA: Absolutely, especially in a world where we have unless as an operator.

+ +

JOËL: Unless gets me so much in Ruby, especially when there are compound expressions. So you say do something unless condition one or condition two, and then I have to think, wait, when does this happen?

+ +

SARA: I have to read it to myself in English, not this and not that. [chuckles]

+ +

JOËL: So that's interesting because when you translated that in English, you changed the operator that's being used.

+ +

SARA: I totally did.

+ +

JOËL: Unless a condition or other condition. And your brain was smart enough to flip that; mine is not.

+ +

SARA: [laughs]

+ +

JOËL: But what's happening here is, and you would learn this in a discrete math class, De Morgan's Laws that say what happens when you negate compound conditions. And you have to negate each of the individual conditions and also flip all the operators, so all the ANDs turn into ORs and the ORs turn into ANDs. And so I always have to remember to do that in my mind when I see an unless or when I see someone negating a compound condition.

+ +

So now, in my mind, every time I'm reviewing code on a pull request, and I see negating a compound condition, it's just a sort of red flag for there's quite possibly a bug here. And maybe leave a comment asking the author, "Did you really mean to do this?" And like you said, maybe even write out a truth table just so that myself I know that the correct behavior is happening.

+ +

SARA: It is a good example of a code smell because if it's hard for you to understand or me to understand, sure, it made sense when it was written, but code is read more than it's written. It should be easy to read and understand. So it's definitely easy to introduce a bug at that point like you were saying, worth commenting on.

+ +

JOËL: You log on to your machine at the beginning of the day, open up a PR, and you're just like, oh yes, I love the smell of De Morgan in the morning.

+ +

SARA: [laughs] Nothing like De Morgan in your cup in the morning.

+ +

JOËL: [laughs] Yes. Oh, now I really want to --

+ +

SARA: A DeMorgan in the morgen.

+ +

[laughter]

+ +

JOËL: Now I really want to see a spoof of that Folgers ad.

+ +

SARA: [laughs] For some reason, the jingle is escaping me, but it's there.

+ +

JOËL: It's an ad for a brand of American coffee.

+ +

SARA: Yes, for those that were not in America during the '90s to see the commercial, [singing] the best part of waking up is De Morgan in your cup.

+ +

JOËL: [chuckles] That was amazing.

+ +

SARA: [laughs] Hopefully, we don't get a copyright strike for that.

+ +

[laughter]

+ +

JOËL: You know what? That is the sell for why you should learn discrete math.

+ +

SARA: Yes. What are some other ways you find discrete math around in your day-to-day life?

+ +

JOËL: I think the most practical part is working with Booleans because writing conditional code writing Boolean expressions is something that I do multiple times every day. And I think anybody who's done programming for any length of time gets some amount of intuition around working with Boolean expressions. Having spent a little bit of time studying them, you learn some patterns. You learn ways of working with them.

+ +

And a common thing that I will often see in Ruby code is people will overuse the if expression when you could have used a Boolean expression instead. So I've seen things like if condition return true, else return false, which is just identity. I've also seen more complex things which will say, "If value one is true and value two is true, return true; otherwise, return false," or some fancy things with early returns that, in the end, are just reimplementing Boolean AND.

+ +

So knowing about a little bit of basic Boolean algebra, being comfortable with combining things using AND and OR rather than just writing early returns, I think, gives a much richer toolkit and something that is much more scalable. And, of course, for those situations where there are complex conditional code, having truth tables as a tool in your back pocket is just absolutely invaluable.

+ +

SARA: 100%. When those get so complex, definitely realizing it's worth maybe breaking up a chain of Boolean logic into separate mini-methods if you need to. There's nothing like seeing a whole bunch of stuff ANDed together that are only kind of related. [laughs]

+ +

JOËL: There's a form of logic that you dig into as well called predicate logic, and there's a whole set of things you can do with it. But two things that stood out to me were these two operators that apply a condition to a whole set of values. And they either claim that a certain thing is true for at least one of the elements in a set or for every value in a set.

+ +

And the interesting thing is that if you claim that something is true for all elements, in order to falsify that claim, you only need to find one counterexample. You don't need to check every item. If I can find one, and maybe it's the first item in this set that is wrong or that contradicts the logical statement that I'm trying to make, then I've immediately disproved your entire statement because you claimed that this was true for every element.

+ +

SARA: And it's hard learning these sorts of fundamentals from computer science; it's hard to not apply that to real life and hear somebody using a statement, "Every this, all of that." I immediately come back with, "Well, some of them." [laughs] I'm that guy, yep.

+ +

JOËL: The person at the end of a conference talk who puts up their hand and says, "So this is not really a question. It's more of a statement."

+ +

SARA: [laughs] I found this one example. Yeah, I'm a stickler for specificity, for sure. Thanks, discrete math.

+ +

JOËL: It definitely helped me be much more nuanced in the way that I speak. I tend to not speak in absolutes or superlatives because of that class.

+ +

SARA: Yeah, I very frequently use the term a non-zero amount of times to describe, for example, there exists one in a set.

+ +

JOËL: There's also another interesting aspect of this, which is when you see a chain of ANDs, so condition, and condition, and condition, and condition, and condition, you're effectively making the assertion that something is true for all elements or that all these conditions are true. Therefore, it only takes one for the whole thing to evaluate to false. And I want to say the fancy name for this is annihilation, where you can have a giant chain of conditions that are ANDed together, and they're all true, but if any single one of them is false, then the whole chain evaluates to false.

+ +

SARA: And this is where you can get a little clever with the order in which you put those in your AND where you have the least heavy lifting checks first so that they fail first. Or if you have things that need to check for nil, check them after. Check the basic stuff first. Let it almost short circuit; let it fail fast, as they say.

+ +

JOËL: Yeah, these are all performance tricks that I think, even if you don't have a discrete math background, you might have picked up. You know about short-circuiting. You know about trying the cheap checks first. And now you know a little bit of the theoretical background of why.

+ +

SARA: [singing] Where do we go from here? [laughs]

+ +

JOËL: So we have these sort of logical operators that will claim that something is true for all elements of a set or at least one element of a set, and those are kind of theoretical. They're useful if we're trying to set up a logical proposition. But these exist in code, in Ruby, as part of the enumerable module. Enumerable has two methods; they are any and all. And you can use those methods to claim that all items in an array will evaluate to true when the given block runs or that at least one evaluates to true for items in that array.

+ +

SARA: What's the word where you're taking out some of a set? Slice but not slice. There's intersection [crosstalk 26:46] union, so not a set theory one, no.

+ +

JOËL: Like getting the inverse?

+ +

SARA: Maybe. I don't know.

+ +

JOËL: I feel like there's a term for getting the inverse of a set.

+ +

SARA: Not the inverse.

+ +

JOËL: Because you can get the inverse of the intersection or something.

+ +

SARA: Yeah. I think I'm just going to go along the lines of being able to slice out what you want with select and how you can then chain an enumerable on that.

+ +

JOËL: Okay. Okay, I see. So you're making a connection from enumerable to set theory.

+ +

SARA: Mm-hmm.

+ +

JOËL: Excellent.

+ +

SARA: Even if you don't necessarily want every item in your enumerable, your array, your hash, you can use things like select and reject to get a subset for a certain condition, and you can slice out based on a condition. And then you can then apply any or all to that. And so I want all of the even numbers, and now for all of these even numbers, such and such should be true for the set.

+ +

JOËL: So now we've made a connection between enumerable and predicate logic. And we've also made a connection to set theory.

+ +

SARA: It's coming full circle again. [laughs] Discrete math is everywhere.

+ +

JOËL: So if you use the enumerable module in Ruby, which you should be (It's one of the best parts of the language.), you're doing discrete math every day, and you didn't know it.

+ +

SARA: You're welcome.

+ +

JOËL: So we've seen that a lot of us are interacting with elements of discrete math every day and that learning a little bit about it more formally can help us be a bit more mindful in how we code every day. It can give us the mental models to solve and analyze problems that we encounter daily. For those listeners who might want to dig a little bit more deeply into discrete math, do you have any resources there that you recommend?

+ +

SARA: Well, not sponsored, but brilliant.org is a pretty good resource for things like math, computer science, for the very least. I'm sure it has other courses, but those are the ones that I've kind of looked at on some YouTubers' free trial. [chuckles] And I liked their approach to teaching, and I think it has got a low barrier to entry for learning these topics. I would definitely recommend that, so brilliant.org

+ +

JOËL: It's funny you mentioned that they sponsor a lot of technology, science, and math YouTubers. So for those listeners who are interested in checking it out, maybe look up some YouTubers and see if they have a free sign-up code.

+ +

SARA: Mayuko is a good YouTuber for that. I believe she gets sponsored by Brilliant occasionally. She's a software engineer out in California.

+ +

JOËL: Clearly, we're not sponsored because we don't have a code to give out.

+ +

SARA: [laughs] Sponsor us, Brilliant.

+ +

JOËL: [laughs] Host at bikeshed.fm

+ +

SARA: [laughs]

+ +

JOËL: All right. Well, with that, shall we wrap up?

+ +

SARA: Yeah, let's do.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+j783d5kO + + ]]> + + Joël Quenneville + + + 373: Empathy, Community and Gender Bias in Tech with Andrea Goulet + https://bikeshed.thoughtbot.com/373 + db3a2520-70b0-4591-8f31-a1ab5e47d168 + Tue, 28 Feb 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie is joined today by a very special guest, Andrea Goulet. Andrea founded Empathy In Tech as part of writing her book [Empathy-Driven Software Development](https://empathyintech.com/). She's also the founder of the community [Legacy Code Rocks](https://www.legacycode.rocks/) and the Chief Vision Officer of two companies: [Corgibytes](https://corgibytes.com/) and [Heartware](https://www.heartware.dev/) (which provides financial support to keep Empathy In Tech running). + +Stephanie has strong opinions about the concept of "Makers and Menders" that the Corgibytes folks have written/spoken about, especially around those personas and gender stereotypes. Andrea joins Steph to evolve the conversation and add nuance to the discussion about legacy code/maintenance in our community. + 42:21 + no + + + Stephanie is joined today by a very special guest, Andrea Goulet. Andrea founded Empathy In Tech as part of writing her book Empathy-Driven Software Development (https://empathyintech.com/). She's also the founder of the community Legacy Code Rocks (https://www.legacycode.rocks/) and the Chief Vision Officer of two companies: Corgibytes (https://corgibytes.com/) and Heartware (https://www.heartware.dev/) (which provides financial support to keep Empathy In Tech running). +Stephanie has strong opinions about the concept of "Makers and Menders" that the Corgibytes folks have written/spoken about, especially around those personas and gender stereotypes. Andrea joins Steph to evolve the conversation and add nuance to the discussion about legacy code/maintenance in our community. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Makers and Menders from Corgibytes (https://corgibytes.com/blog/2015/08/14/makers-vs-menders/) +Empathy in Tech (https://empathyintech.com/) +Legacy Code Rocks (https://www.legacycode.rocks/) +Forget Technical Debt — Here's How to Build Technical Wealth (https://review.firstround.com/forget-technical-debt-heres-how-to-build-technical-wealth) +Equal Partners by Kate Mangino (https://bookshop.org/p/books/equal-partners-improving-gender-equality-at-home-kate-mangino/18336353) +Sustainable Web Development Episode (https://www.bikeshed.fm/368) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +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., And today I'm joined by a very special guest, Andrea Goulet. Hi, Andrea. +ANDREA: Hello, thanks for having me. +STEPHANIE: So here on The Bike Shed, we like to start by sharing something new in our world. Could you tell us a bit about yourself and anything new going on for you? +ANDREA: Yeah, so I have a background in strategic communications, and then kind of made a windy journey over to software. And so, for the past 13 years, I've been focused on modernizing legacy systems. And legacy is kind of a loose term; something you write today can be legacy. But essentially, we kind of help modernize any kind of software, any language, any platform, any framework. +And so, over the course of doing that, in the work that I did before I came to software, I had a very technical understanding of empathy and communications and had just done a lot of that. And I just noticed how much that mattered in creating healthy and sustainable codebases. So now I'm kind of taking that experience, and I've got a book contract called "Empathy-Driven Software Development." So I've been working on just diving into a lot of the really deep research. So that's been kind of my focus for the past two years. +And it's been really surprising because there were things that were positioned as truths, and then it's like, wait a second, neuroscience is completely upending everything. So it's been a fun learning journey. And I'm excited to share some of the things that I've learned over the years, especially [laughs] in the past two years with this book. So that is the new thing with me. And it's...I was telling you before it just feels like a constant new thing. Anybody who's written a book...it's the hardest thing I've ever done, so... [laughs] +STEPHANIE: Yeah, that sounds tough but also kind of exciting because you're learning so many new things that then kind of shape how you view the world, it sounds like. +ANDREA: Yeah. Yeah, it really does. And I think I really like diving into the details. And I think what started this was...my business partner, Scott, at the time, really embodied the stereotypical 2010 software developer down to the scruffy beard and dark-rimmed glasses. And what I found incredibly interesting was he had this belief of I'm good with machines, but I'm bad with people. And he just had this really deeply ingrained. On the flip side, I had this belief of, oh, I'm good with people, but I'm bad with machines. I'll never learn how to code. +And I found that really interesting. And personally, I had to go through a journey because we went on...it was the first time either of us had ever been on a podcast. So this was about ten years ago. And at the end of the podcast, Scott was the only one on there. And he said, you know, the person asked about his origin story and about our company Corgibytes. And he was like, "Yeah, you know, Andrea is amazing. She's our non-technical founder." +And by that time, I had been coding next to him for like three years. And I was like, why the heck would you call me non-technical? And I just felt this...what is it that I have to do to prove it to you? Do I have to actually go get a CS degree? I know I'm self-taught, but does that mean that I'm not good enough? What certificates do I need? Do I need to sit down next to you? Do I need to change my lifestyle? Do I need to look like you? So I was really upset [laughing] and just thinking through, how dare you? How dare you label me as non-technical? +And Scott is very quiet and patient, great with people, I think. [laughs] And he listened and said, "I use the words that you use to describe yourself. When we were in a sales meeting right before that phone call, I paid attention to how you introduced yourself, and I pretty much used the same words. So when you call yourself technical, I will too." That shattered my world. It shattered my identity because then it put the responsibility of belonging on me. I couldn't blame other people for my not feeling like I didn't belong. +That journey has just been so profound. This is what I see a lot of times with empathy is that we have these kinds of self-identities, but then we're afraid to open up and share. And we make these assumptions of other people, but, at the same time, there's real-world evidence. And so, how do we interpret that? In addition to this, Scott...like, part of the reason I called myself non-technical was because all of the people I saw who were like me or had my background, that's the word that was used to describe someone like me. +And when I would go to a conference, you know, I have a feminine presentation. And this was ten years ago. My very first conference was 300 software developers, and there were probably about 295 men. And I was one of five women in the room. And because I looked so different and because I stood out, the first question that anybody would ask me, and this was about 30% to 40% of introductions, was, "Are you technical or non-technical?" And I had to choose between this binary. +And I was like; I don't know. Am I technical? Like, is it a CEO that can code? I don't know. But then I have this background. And so I would just default to, "No, I guess I'm non-technical," because that's what felt safe because that's what they assumed. And I just didn't know, and I didn't realize that I was then building in this identity. +And so then, as part of trying to create a warm and inclusive organization, we did one of the unconscious bias surveys from Harvard. And what astonished me when I did that myself was that I didn't have a whole lot of bias, like, there was some. But the most profound bias was against women in the workplace, and it stood out a big one. I was like, how is it that I can be someone who's a fierce advocate, but then that's my own bias against people like me? What the heck is going on? So really exploring all of this. +And I think Scott and I have had so many different conversations over the years. We actually ended up getting married. And so we have a personal reason to figure a lot of this stuff out too. And when we start to have those conversations about who am I and what's important to me, then all of a sudden, we can start creating better code. We can start working together better as a team. We can start advocating for our needs. Other people know what we need ahead of time. And we're not operating out of defensiveness; we're operating out of collaboration and creativity. +So the book and kind of everything is inspired by my background and my lived experience but then also seeing Scott and his struggles, too, because he had been told like, "You're a geek. Stay in the computers. Stay in the code. You're not allowed to talk to customers because you're bad at it," and flat out was told that. +So how do we overcome these labels that people have put on us, and then we've made part of our own identity? And which ones are useful, and then which ones are not? Because sometimes labels can create a sense of community and affinity and so how do we know? And it's complicated, but the same thing, software is complicated. We can take skills like empathy and communication. We can look at them schematically and operationalize them when we look at them in kind of detail. So that's what I enjoy doing is looking under the hood and figuring out how does all this stuff work? So... [laughs] +STEPHANIE: I did want to respond to a few things that I heard you say when you're talking about going to a conference and feeling very much in the minority. I went to my first RailsConf in 2022, my first RailsConf in person, and I was shocked at the gender imbalance. And I feel like every time I used the women's restroom; I was looking around and trying to make a connection with someone and have a bit of a kinship and be like, oh yes, you are here with me in this space. And then we would have a conversation and walk out together, and that felt very meaningful because the rest of the space, you know, I wasn't finding my people. And so I feel that very hard. +I think this is also a good time to transition into the idea of makers and menders, especially because we have been talking about labels. So you all talked about this distinction between the different types of work in software development. So we have greenfield work, and that is writing code from scratch, making all the decisions about how to set up an application, exploring a whole new domain that hasn't been codified yet. And that is one type of work. +But there's also mender-type work, which is working in existing applications, legacy code, refactoring, and dealing with the complexity of something that has stood the test of time but may or may not have gotten a lot of investment or care and bringing that codebase back to life if you will. And when I first heard about that distinction, I was like, yes, I'm a mender. This is what I like to do. But the more I thought about it, I started to also feel conflicted because I felt pain doing that work as well. +ANDREA: Oh, interesting, yeah. +STEPHANIE: Especially in the context of teams that I've been on when that work was not valued. And I was doing maintenance work and fixing bugs and either specifically being assigned to do that work or just doing it because I knew it needed to be done and no one else was doing it. And that had caused me a lot of frustration before because I would look around and be on a team with mostly White men and be like, why aren't they picking up any of this work as well? +And so I was thinking about how I both felt very seen by the acknowledgment that this is work, and this is valid work, and it's important work, but also a little bit confused because I'm like, how did I get here? Did I pigeonhole myself into doing this work? Because the more I did it, the better I got at it, the more comfortable and, to whatever degree, enjoyed it. But at the same time, I'm not totally sure I was given the opportunity to do greenfield work earlier in my career. That could have changed where my interests lie. +ANDREA: Yeah, it is. And it's funny that you mentioned this because I actually I'm a maker. But yeah, I created this community, and I'm known for this thing. And I had a very similar experience to how do I exist as someone who's different in this kind of community? And I think part of it is, you know, there's a great quote by George Box, who is a statistician, and he says, "All models are wrong; some are useful." +And I think that's kind of the whole idea with the maker-mender is that it is a signal to be like, hey, if you like fixing stuff...because there is so much shame, like, that's what we were responding to. And Scott had the opposite problem of what you have experienced, where he was only allowed to work on greenfield work. They were like, "No, you're a good developer. So we want you working on features. We won't let you fix the bugs. We won't let you do the work that you like doing." And so that's why he wanted to create Corgibytes because he's like, "This work needs to be done." I am so personally passionate about this. +And when we were having these conversations 13 years ago, I was talking to him about product/market fit and stuff like that. And I was like, "You like fixing software, and there's a lot of software out there to be fixed." I just was very, very confused as to why this kind of existed. And we had been told flat out, "You're never going to find anybody else like Scott. You're never going to be able to build a company around people who find a lot of joy in doing this work." +And I think that this comes down to identity and kind of the way that Legacy Code Rocks was built too. A lot of the signaling that we put out there and the messaging and stuff really came from Scott's feeling of, like, I want to find more people like me. So being in the women's bathroom and like, how do I find more menders? Or how do I find people...because we were walking through a Barnes & Noble, and it was like a maker fest, maker everything. And he's like, "I don't have a community. There's nowhere for me to go to create these meaningful connections," exactly like you were saying. "I have maybe two people in my network." +And then we were at a conference in 2015. We were at the large agile conference. And it was one of the first ones that I've been to that had a software craft track. And we met like 20 people who were really, like, I just saw Scott light up in a way that I hadn't seen him light up because he could geek out on this level that I hadn't seen him do before. And so when I asked, like, "How do you guys stay in touch afterwards?" And they're like, "Oh no, we don't. We don't know how to build a community." And it's like, well, okay, well, we can get that started. +To your response of like, how do you operate when it is presented as a binary? And it's like, am I this, or am I this? This kind of gets down to the idea of identity-wise, is it a binary, or is it a spectrum? I tend to think of it kind of like an introvert-extrovert spectrum where it's like there is no wrong or right, and you can move in different places. +And I think being able to explain the nuances of the modeling around how we came up with this messaging can get lost a lot of times. But I'm with you, like, how...and that's kind of something now where it's like, okay, maybe my role was to just start this conversation, but then everybody's having these ideas. But there are people who genuinely feel seen, you know. +STEPHANIE: Yeah, that's really interesting because what I'm hearing is that when there's this dominant narrative of what a developer should be, and should be good at, and what they should do, it's kind of like what you were saying earlier about how hard it was for you to claim that identity yourself. People who feel differently aren't seen, and that's, I think, the problem. +And I'm very, very interested in the gender aspect of it because one thing that I've noticed is that a lot of my female developer friends do do more of that mending work. So when you talk about feeling like there was no community out there, it just wasn't represented at the time, you know, a decade ago for sure. And still, even now, I think we're just starting to elevate those voices and that work. +I wanted to share that at thoughtbot; we have different teams for different business verticals. And so we do have a rapid validation prototyping team. We do have a greenfield like MVP, V1 product team. And then we also have a team, Boost, the team that I'm on. That is more team augmentation, working with legacy code and existing systems. And it was not lost on me that Boost has the most women. [laughs] +ANDREA: Yeah, because you have the concept of cognitive load and mental load. +STEPHANIE: Yes. +ANDREA: Women at home end up taking a lot more of this invisible labor that's behind the scenes. Like, you're picking the kids up from school, or you're doing the laundry, or all these things that are just behind the scenes. And this was actually something...so when Scott and I also got married, that's when I first became aware of this, and it was very similar. And it was, okay, how do I...because Scott and I, both in our business and in our personal partnership, we wanted it to be based on equity. And then also, like, how do I show up? +And for me, the hardest thing with that was letting go of control where it's like, it has to be a certain way. It's hard for me to comment on the broader enterprise level because what I see at Corgibytes is we have gender parity. That's been pretty balanced over the course of our..., and we're a small boutique company, so it's different. But then, in the larger community of Legacy Code Rocks, it tends to be more male. There are actually fewer women in there. +And I think, too, like there's this idea of testers and QA, like, I think that falls in there as well, and that's heavily dominant. And I think sometimes it's like, oh...and I think this kind of comes to the problem of it, like, it's the way that we think about the work in general. And this might be useful just to think about kind of the way that it came about was, you know, makers and menders was we were putting together [laughs] actually this talk for this conference that we went to. +And my background in marketing, I was trying to wrap my brain around when is it appropriate for mending? And I had my marketing degree. It's like, oh, the product lifecycle. And Scott's retort was, "It needs to be a circle. We're agile, so it needs to be a circle." And I was like, this doesn't make any sense. Because look, if you have maturity and then you have it...oh my gosh, it'll link back to innovation, and then you can do new stuff. +And so yeah, I think when we describe makers and menders, and this is true with any label, the idea in the broader model is that makers and menders aren't necessarily distinct, and your team should 1,000%...everyone should be contributing. And if you only have one person who's doing this work, you're at a detriment. That's not healthy for your codebase like; this should be baked in. And the mender is more of like, this is where I get my joy. It's more of an opt-in. But I think that your observation about the invisible labor and how that gets translated to maintenance work is accurate. +A lot of times, like when Scott was describing his thing, it's like, there's the movie "Office Space." I might be dating myself. But there's this guy, Milton, and it's like, "Just go to the basement." He was told maintenance is where good software careers go to die. [laughs] And so over the years, it's like, how do we celebrate this and make it more part of the maker work? +And it's similar to how introverts and extroverts...it's like, we all work together, and you need all of it. But there is an extrovert bias. And extroverts are seen more as, oh, they have leadership traits and stuff. But increasingly, we're starting to see, no, actually, that's not the only way that you can be effective. So I think it's hard. And I think it does come down to belonging. And I think that there are also different cultural impacts there. And it comes down to just a lot of different lived experiences. +And I so appreciate you sharing your point of view. And I'm curious, what would help you feel more like you belong? Is it the work and the environment that you're in that's kind of contributing to this feeling? Or is it other things in general or? +STEPHANIE: Okay, so I did want to address real quick what you were saying about mental load and household labor because I think I really only started thinking about this after I read a book called "Equal Partners" by Kate Mangino, where she talks about how to improve gender equality at home, and I loved that book so much. And I suddenly started to see it everywhere in life and obviously at work too. And that's kind of what really drove my thinking around this conversation, maintenance work being considered less skilled labor or things that get offloaded to someone else. I think that really frustrates me because I just don't believe that's true. +And to get back to what you were asking about what would make me feel more seen or valued, I think it's systemic. But I also think that organizations can make change within their cultures around incentives especially. When you are only promoted if you do greenfield work and write thousands of lines of code, [laughs] that's what people will want to do. [laughs] And not even just promotions, but who gets a kudos in Slack? Or when do you get positive encouragement? +As a consultant, I've worked on different client teams that had different values, and that was when I really struggled to be in those environments. I have a really strong memory of working on a greenfield project, but there was another male developer who was just cranking out features and doing all of this work and then demoing it to stakeholders. But then there was one feature that he had implemented but had faked the data. So he hadn't finished the backend part of it but just used fake data to demo the user interface to stakeholders. And then he moved on to something else. +And I was like, wait; this isn't done. [laughs] But at that point, stakeholders thought it was done. They thought that it was complete. They gave him positive feedback for finishing it. And then I had to come in and be like, "This isn't done. Someone needs to work on this." And that person ended up being me. And that was really frustrating because I was doing that behind-the-scenes work, the under-the-hood work for something that had already been attributed to someone else. And yeah, I think about that a lot and what systems or what the environment was that led to that particular dynamic. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: Do you have any advice for leaders who want to make sure there's more equity for people who like to do mending and legacy code work? +ANDREA: Yeah, absolutely. I am so grateful for your questions and your perspective because this is not something that's talked about a lot, and it is so important. I wrote an article for First Round Review. This was in 2016 or 2017. And it was called "Forget Technical Debt — Here's How to Build Technical Wealth," and so if you want to link to it in the show notes. It's a really long article and that goes into some of the specifics around it, but it's meant for CEOs. It really is meant for CEOs. +And I do think that you're right; some of it is that we have lionized this culture of making and the work that is more visible. And it's like, oh, okay, great, here's all the visual design stuff. That's fantastic, but then recognizing there's a lot of stuff that's behind the scenes too. So in terms of leaders, I think some of it is you have to think about long-term thinking instead of just the short-term. Don't just chase the new shiny. +Also, you need to be really aware of what your return on investment is. Because the developers that are working on maintaining and making sure that your mission-critical systems don't fail those are the ones that have the highest value in your organization because if that system goes down, your company makes money. Greenfield work, yes, it's very...and I'm not downplaying greenfield work for sure. I'm definitely, [laughs] like, I love doing that stuff. I love doing the generating phase. +And at the same time, if we only look towards kind of more the future bias...there's a great book that we were featured in called "The Innovation Delusion" that talks about this more in general. But if we only look at the visible work that's coming, then we forget what's important now. And so for leaders, if you're running a software company, know where your mission-critical systems are and recognize the importance of maintaining them. That's the very first step. +The second step is to recognize the complexities of a situation, like, to think about things in terms of complex systems instead of complicated systems. And I'll describe the difference. So when I came to software, I had been working in the creative field, like in advertising, and branding, and copywriting, and all that. And we got inputs. We kind of ran it through this process, and then we delivered. And we did a demo and all of that stuff. +It was when is the timeline? When is it done? Big air quotes. And we were pretty predictably able to deliver on our delivery day. Sometimes things would go wrong, but we kind of had a sense because we had done the same pattern over and over again. You don't get that in legacy code because the variables are so immense that you cannot predict in the same way. You have to adopt a new strategy for how do you measure effectiveness. +And the idea of measuring software productivity in terms of new features or lines of code, like, that's something that goes all the way back to Dykstra [laughs] in the 1970s around, is that the right way? Well, a lot of people who code are like, "No, that's not." This is a debate that goes back to the earliest days of computing. But I think that the companies that are able to build resilient systems have a competitive advantage. +If a leader wants to look at their systems, whether that is a social system and the people in their organization or whether or not it's their software if you look at it from a systems thinking, like, there are interactions that I need to pay attention to not just process, that is super key as well. And then the last one is to recognize, like, one of our core values is communication is just as important as code. +I would be remiss to neglect empathy and communication in part of this, but that really is so important. Because when we position things in terms of...and I don't know as much about thoughtbot and kind of the overall strategy, but kind of an anti-pattern I have seen just in general in organizational behavior is that when you structure teams functionally and silo them, you're not getting that diversity of thought. +So the way that we approach it is, like, put a mender on a maker team because they're going to have a different perspective. And then, you can work together to get things out the door faster and value each other's perspectives and recognize strengths and shadows. So, for me, as a maker, I'm like, I've got a huge optimism bias, and we can go through all this stuff. And for Scott, it's like he struggles to know when he's done. Like, for me, I'm like, cool, we're 80% done. I got it. We're good to go. And for Scott, he'll work on something, and then it's like, I have to stop him. +So recognizing that we help each other, that kind of thought diversity and experience diversity goes across so many different vectors, not just makers and menders. But I think, to me, it's about reframing value so that you're not just thinking about what it is right now in this moment. And I think a lot of this comes down to investor strategy too. Because if you've got an investor that you're trying to appease and they're just trying to make short-term monetary gains, it's much harder to think in terms of long term. +And I think it's developers understanding business, business understanding the struggles of developers and how they need lots of focus time, and how estimating is really freaking hard, and why if you demand something, it's going to be probably not right. And then coming up with frameworks together where...how can I describe this in a way? So to me, it really is about empathy and communication at the end of the day when we're talking about interactions and how do we operationalize it. +STEPHANIE: I like what you said about reframing value because I do believe that it starts from the top. When you value sustainability...my co-host, Joël, had an episode about sustainability as a value in software development. But then that changes, like I mentioned before, the incentive structures and who gets rewarded for what type of work. And I also think that it's not only diverse types of people who like doing different types of work, but there is value in doing both. +And I know we talked about it being a spectrum earlier, but I strongly believe that doing the legacy code work and experiencing what it's like to try to change a system that you are like, I have no idea why this decision was made or like, why is the code like this? That will help inform you. If you do do greenfield work, those are really important skills, I think, to bring to that other type of work as well. Because then you're thinking about, okay, how can I make decisions that will help the developers down the line when I'm no longer on this project? +ANDREA: Exactly, which is a form of empathy. [laughs] +STEPHANIE: Yeah, it is a form of empathy, exactly. And the reverse is also true too. I was thinking about, okay, how can working in greenfield code help inform working with legacy code? And I was like, oh, you have so much energy when the world is completely open to you, and you can make whatever decisions to deliver value. And I've really struggled working in legacy code, feeling like I don't have any options and that I have to repeat a pattern that's already been set or that I'm just kind of stuck with what I've been given. But I think that there is some value in injecting more of that agency into working with legacy code as well. +ANDREA: Well, and I think, too, I think you hit it on the head because, like I said, with the mental load at home, it was like, I had to be okay with things failing where it's like, it wasn't exactly the way I would do it, and I had to be okay with that. Like, oh, the dishes aren't put in the dishwasher exactly the same way I would do it. I'm not going behind it. And like, okay, it's not perfect. That's...whoo, it's going to be okay. +And I think that's kind of what we experience, too, is this idea of we have to figure out how we work together in a way that is sustainable. And I think that, similar to my experience with the technical, non-technical piece, there is an onus. Now, granted, I want to be very careful here to not...there is trauma, and there is absolutely horrific discrimination and abuse. And that is not what I'm talking about here in terms of power dynamics. +I am talking more about self-identity and self-expression. And I think that if you are in a community like makers and menders, yeah, we're less represented. There is a little bit of an onus, the technical, non-technical, like the onus of understanding what non-technical means and where I can push back is really important work for me to do. Because what I was surprised with was everyone there, like, when I started asking...so my response ended up being, "Help me understand, why did you ask that question?" And I took ownership of the narrative. +And it was like, oh, well, what I found was that most of the people were like, if you're a recruiter, I don't want to waste your time with a bunch of stuff that you don't want to talk about. And then being able to say, "Oh, okay, I can see that, and you assumed that I was a recruiter because of the way I looked. And I understand the intention here. Next time, if I'm at a software conference, assume that I know how to code and assume that I'm here for a reason." +And a great opening question is, "What brought you here?" I'm like, oh, okay, when we ask a close-ended question, we position things as a binary, like, are you technical or non-technical? That creates a lot of cognitive dissonance, and it's hard. But if I open it up and say, "What brought you here?" Then I can create my own narrative. There is an aspect of setting boundaries and pushing back a little bit like you said, agency. And that can be really hard because it gets at the core of who you are, and then you have to really explore it. +And what I found, at least, is in the majority, there have been exceptions, but in the majority of the male-dominated groups that I've been in in my career in software, the majority are very welcoming and want me to be there. But I feel inadequate, and it's more impostor syndrome than I think it is people being discriminatory. Learning about the differences between that and where is my responsibility and where's your responsibility in this that's a tough tension to play. +STEPHANIE: Absolutely. And I think that's why it's really important that we're having a conversation like this. I think what you're getting at is just the harm of the default assumption that is chronic, [laughs] at least for me sometimes. And you mentioned earlier the history of computing a little bit. And I was really excited about that because I did a little bit of digging and learned about women's history in computing and how after World War II, programming, you know, there were so many women. +In fact, I think by 1960, more than one in four programmers were women, and they were working on mission-critical work like for NASA for, you know, during World War II for code-breaking. And I read that at the time, that work was deemed boring and tedious, and that's why men didn't want to do it. They wanted to work on hardware, which was what was the cool, creative, interesting work. And the computing work was just second class. That's changed, but in some ways, I'm thinking about, okay, where are we now? And to what degree are we kind of continuing this legacy? And how can we evolve or move beyond it? +ANDREA: Yeah, you're absolutely right. And in some of the research for the book, one of the things I learned is a lot of people know the name, John von Neumann. He created the von Neumann architecture, that is the foundation of all the hardware that most of us use today. And the very first kind of general purpose digital computer, ENIAC, all...I think it was eight of the people who were programmers for that were women. That team was led by John von Neumann's wife, Klára, and you never hear about Klára. You have to go digging for that. +And The Smithsonian actually just about 8, 10 years ago did a big anniversary and then realized none of those women were invited to the press conferences. They were not invited. And so there is kind of this...similar to generational wealth, it's the thing that gets passed down. Like, if you're in the rooms in the early days...there was a quote by John Backus, who created FORTRAN and the Backus–Naur principle, where he talked about programming in the 1950s. +He has an essay, and he was like, yeah, I mean, an idea was anybody who claims it, and we never cited our sources. And so it was whoever had the biggest ego was the one who got credit. And everyone's like, great; you're a hero. And so I think that's kind of the beginning of it. And so if you weren't invited into the room, because in the 1950s, in addition to gender, there was legislation that prevented...we weren't even allowed to use the same bathrooms. You had White bathrooms and Black bathrooms. +So you had very serious barriers for many different people getting into that room, and I think that gets to the idea of intersectionality as well. So the more barriers that you had, the harder it was going to be. And so then you get the stereotypes, and then you get the media who promotes the stereotypes. And so that is what happened to me. So I grew up in the '80s and '90s, and just every movie I watched, every TV show portrayed somebody who was, quote, "good" with computers in a very specific way. I didn't see myself in it. So I was like, oh, I'm not there. +But then, when I talk to Scott, he's like, "Oh, I never saw that. I never saw the discrimination. I just saw this stuff." That's part of it is that if you were in that position where discrimination, or difficulties, or stereotypes had been invisible to you, the onus is on you to learn and to listen. If you are in a situation where you feel like you have been in the minority, the onus is on you to find ways to become more empowered. +And a lot of times, that is setting boundaries. It's advocating for yourself. It's recognizing your self-worth. And those are all things that are really hard. And saying, hey, if we want to be sustainable, everyone needs to contribute. I'm happy to train everyone, but this is not going to work. And being able to frame it, too, in terms of value, like, why? Why is it a benefit for everyone building that empathy? +And you're right, I mean, there are absolutely cultures where...who was it? I think it was Edward Deming. And he said, "A single person is powerless in the face of a bad system." And so if you're in a system that isn't going to work, recognizing that and can you move into a different system? Or can you change it from within? And those are all different questions that you've got to ask based on your own fortitude, your own interests, your own resources, your own situation. There is no easy question. But it's always work. And no matter who you are, it's always work. [laughs] +STEPHANIE: Yeah, yeah. I joined as co-host of this podcast just a few months ago. And I had to do a lot of reflecting on what I wanted to get out of it and what my goals were. And that's why I'm really excited to have you on here and to be using this platform to talk about things that are important to me and things that I think more people should know about or think about. So before we wrap up, Andrea, do you have anything else you want to say? +ANDREA: I want to reinforce that if you feel joy from mending, it's awesome. And there are communities like legacycode.rocks. We have MenderCon, and it's a celebration of software maintenance. So it can be really great. We have a virtual meetup every Wednesday. And there's a kind of a core group of people who come, and they're like, it's like therapy because there are a lot of people who are in your situation where it's like, I'm the only person on my team who cares about automated tests, and I have no idea like...and just having people who kind of share in that struggle can be really helpful, so finding your community. +And then I think software maintenance is really, really critical and really important, and I think we see it. Like, we're seeing in the news every day in terms of these larger systems going down. Just recently, Southwest Airlines and all of these flights got canceled. The maintenance work is so, so valuable. If you feel like a mender and you feel like that fits your identity, just know that there is a lot of worth in the work that you are doing, an immense amount of worth in the work that you are doing, and to continue to advocate for that. +If you are a maker, yes, there is absolutely worth in the work you're doing, but learn about menders. Learn how to work together. And if you are a leader of an organization, recognize that all of these different perspectives can work together. And, again, reframe the value. +So I am so grateful that you framed the conversation this way. It's so important. I'm very, very grateful to hear from you and your point of view. And I hope that you continue to push the narrative like this because it's really important. +STEPHANIE: Aww, thanks. And thank you so much for being on the podcast. +ANDREA: Yeah, yeah, absolutely. Thanks for having me. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie is joined today by a very special guest, Andrea Goulet. Andrea founded Empathy In Tech as part of writing her book Empathy-Driven Software Development. She's also the founder of the community Legacy Code Rocks and the Chief Vision Officer of two companies: Corgibytes and Heartware (which provides financial support to keep Empathy In Tech running).

+ +

Stephanie has strong opinions about the concept of "Makers and Menders" that the Corgibytes folks have written/spoken about, especially around those personas and gender stereotypes. Andrea joins Steph to evolve the conversation and add nuance to the discussion about legacy code/maintenance in our community.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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., And today I'm joined by a very special guest, Andrea Goulet. Hi, Andrea.

+ +

ANDREA: Hello, thanks for having me.

+ +

STEPHANIE: So here on The Bike Shed, we like to start by sharing something new in our world. Could you tell us a bit about yourself and anything new going on for you?

+ +

ANDREA: Yeah, so I have a background in strategic communications, and then kind of made a windy journey over to software. And so, for the past 13 years, I've been focused on modernizing legacy systems. And legacy is kind of a loose term; something you write today can be legacy. But essentially, we kind of help modernize any kind of software, any language, any platform, any framework.

+ +

And so, over the course of doing that, in the work that I did before I came to software, I had a very technical understanding of empathy and communications and had just done a lot of that. And I just noticed how much that mattered in creating healthy and sustainable codebases. So now I'm kind of taking that experience, and I've got a book contract called "Empathy-Driven Software Development." So I've been working on just diving into a lot of the really deep research. So that's been kind of my focus for the past two years.

+ +

And it's been really surprising because there were things that were positioned as truths, and then it's like, wait a second, neuroscience is completely upending everything. So it's been a fun learning journey. And I'm excited to share some of the things that I've learned over the years, especially [laughs] in the past two years with this book. So that is the new thing with me. And it's...I was telling you before it just feels like a constant new thing. Anybody who's written a book...it's the hardest thing I've ever done, so... [laughs]

+ +

STEPHANIE: Yeah, that sounds tough but also kind of exciting because you're learning so many new things that then kind of shape how you view the world, it sounds like.

+ +

ANDREA: Yeah. Yeah, it really does. And I think I really like diving into the details. And I think what started this was...my business partner, Scott, at the time, really embodied the stereotypical 2010 software developer down to the scruffy beard and dark-rimmed glasses. And what I found incredibly interesting was he had this belief of I'm good with machines, but I'm bad with people. And he just had this really deeply ingrained. On the flip side, I had this belief of, oh, I'm good with people, but I'm bad with machines. I'll never learn how to code.

+ +

And I found that really interesting. And personally, I had to go through a journey because we went on...it was the first time either of us had ever been on a podcast. So this was about ten years ago. And at the end of the podcast, Scott was the only one on there. And he said, you know, the person asked about his origin story and about our company Corgibytes. And he was like, "Yeah, you know, Andrea is amazing. She's our non-technical founder."

+ +

And by that time, I had been coding next to him for like three years. And I was like, why the heck would you call me non-technical? And I just felt this...what is it that I have to do to prove it to you? Do I have to actually go get a CS degree? I know I'm self-taught, but does that mean that I'm not good enough? What certificates do I need? Do I need to sit down next to you? Do I need to change my lifestyle? Do I need to look like you? So I was really upset [laughing] and just thinking through, how dare you? How dare you label me as non-technical?

+ +

And Scott is very quiet and patient, great with people, I think. [laughs] And he listened and said, "I use the words that you use to describe yourself. When we were in a sales meeting right before that phone call, I paid attention to how you introduced yourself, and I pretty much used the same words. So when you call yourself technical, I will too." That shattered my world. It shattered my identity because then it put the responsibility of belonging on me. I couldn't blame other people for my not feeling like I didn't belong.

+ +

That journey has just been so profound. This is what I see a lot of times with empathy is that we have these kinds of self-identities, but then we're afraid to open up and share. And we make these assumptions of other people, but, at the same time, there's real-world evidence. And so, how do we interpret that? In addition to this, Scott...like, part of the reason I called myself non-technical was because all of the people I saw who were like me or had my background, that's the word that was used to describe someone like me.

+ +

And when I would go to a conference, you know, I have a feminine presentation. And this was ten years ago. My very first conference was 300 software developers, and there were probably about 295 men. And I was one of five women in the room. And because I looked so different and because I stood out, the first question that anybody would ask me, and this was about 30% to 40% of introductions, was, "Are you technical or non-technical?" And I had to choose between this binary.

+ +

And I was like; I don't know. Am I technical? Like, is it a CEO that can code? I don't know. But then I have this background. And so I would just default to, "No, I guess I'm non-technical," because that's what felt safe because that's what they assumed. And I just didn't know, and I didn't realize that I was then building in this identity.

+ +

And so then, as part of trying to create a warm and inclusive organization, we did one of the unconscious bias surveys from Harvard. And what astonished me when I did that myself was that I didn't have a whole lot of bias, like, there was some. But the most profound bias was against women in the workplace, and it stood out a big one. I was like, how is it that I can be someone who's a fierce advocate, but then that's my own bias against people like me? What the heck is going on? So really exploring all of this.

+ +

And I think Scott and I have had so many different conversations over the years. We actually ended up getting married. And so we have a personal reason to figure a lot of this stuff out too. And when we start to have those conversations about who am I and what's important to me, then all of a sudden, we can start creating better code. We can start working together better as a team. We can start advocating for our needs. Other people know what we need ahead of time. And we're not operating out of defensiveness; we're operating out of collaboration and creativity.

+ +

So the book and kind of everything is inspired by my background and my lived experience but then also seeing Scott and his struggles, too, because he had been told like, "You're a geek. Stay in the computers. Stay in the code. You're not allowed to talk to customers because you're bad at it," and flat out was told that.

+ +

So how do we overcome these labels that people have put on us, and then we've made part of our own identity? And which ones are useful, and then which ones are not? Because sometimes labels can create a sense of community and affinity and so how do we know? And it's complicated, but the same thing, software is complicated. We can take skills like empathy and communication. We can look at them schematically and operationalize them when we look at them in kind of detail. So that's what I enjoy doing is looking under the hood and figuring out how does all this stuff work? So... [laughs]

+ +

STEPHANIE: I did want to respond to a few things that I heard you say when you're talking about going to a conference and feeling very much in the minority. I went to my first RailsConf in 2022, my first RailsConf in person, and I was shocked at the gender imbalance. And I feel like every time I used the women's restroom; I was looking around and trying to make a connection with someone and have a bit of a kinship and be like, oh yes, you are here with me in this space. And then we would have a conversation and walk out together, and that felt very meaningful because the rest of the space, you know, I wasn't finding my people. And so I feel that very hard.

+ +

I think this is also a good time to transition into the idea of makers and menders, especially because we have been talking about labels. So you all talked about this distinction between the different types of work in software development. So we have greenfield work, and that is writing code from scratch, making all the decisions about how to set up an application, exploring a whole new domain that hasn't been codified yet. And that is one type of work.

+ +

But there's also mender-type work, which is working in existing applications, legacy code, refactoring, and dealing with the complexity of something that has stood the test of time but may or may not have gotten a lot of investment or care and bringing that codebase back to life if you will. And when I first heard about that distinction, I was like, yes, I'm a mender. This is what I like to do. But the more I thought about it, I started to also feel conflicted because I felt pain doing that work as well.

+ +

ANDREA: Oh, interesting, yeah.

+ +

STEPHANIE: Especially in the context of teams that I've been on when that work was not valued. And I was doing maintenance work and fixing bugs and either specifically being assigned to do that work or just doing it because I knew it needed to be done and no one else was doing it. And that had caused me a lot of frustration before because I would look around and be on a team with mostly White men and be like, why aren't they picking up any of this work as well?

+ +

And so I was thinking about how I both felt very seen by the acknowledgment that this is work, and this is valid work, and it's important work, but also a little bit confused because I'm like, how did I get here? Did I pigeonhole myself into doing this work? Because the more I did it, the better I got at it, the more comfortable and, to whatever degree, enjoyed it. But at the same time, I'm not totally sure I was given the opportunity to do greenfield work earlier in my career. That could have changed where my interests lie.

+ +

ANDREA: Yeah, it is. And it's funny that you mentioned this because I actually I'm a maker. But yeah, I created this community, and I'm known for this thing. And I had a very similar experience to how do I exist as someone who's different in this kind of community? And I think part of it is, you know, there's a great quote by George Box, who is a statistician, and he says, "All models are wrong; some are useful."

+ +

And I think that's kind of the whole idea with the maker-mender is that it is a signal to be like, hey, if you like fixing stuff...because there is so much shame, like, that's what we were responding to. And Scott had the opposite problem of what you have experienced, where he was only allowed to work on greenfield work. They were like, "No, you're a good developer. So we want you working on features. We won't let you fix the bugs. We won't let you do the work that you like doing." And so that's why he wanted to create Corgibytes because he's like, "This work needs to be done." I am so personally passionate about this.

+ +

And when we were having these conversations 13 years ago, I was talking to him about product/market fit and stuff like that. And I was like, "You like fixing software, and there's a lot of software out there to be fixed." I just was very, very confused as to why this kind of existed. And we had been told flat out, "You're never going to find anybody else like Scott. You're never going to be able to build a company around people who find a lot of joy in doing this work."

+ +

And I think that this comes down to identity and kind of the way that Legacy Code Rocks was built too. A lot of the signaling that we put out there and the messaging and stuff really came from Scott's feeling of, like, I want to find more people like me. So being in the women's bathroom and like, how do I find more menders? Or how do I find people...because we were walking through a Barnes & Noble, and it was like a maker fest, maker everything. And he's like, "I don't have a community. There's nowhere for me to go to create these meaningful connections," exactly like you were saying. "I have maybe two people in my network."

+ +

And then we were at a conference in 2015. We were at the large agile conference. And it was one of the first ones that I've been to that had a software craft track. And we met like 20 people who were really, like, I just saw Scott light up in a way that I hadn't seen him light up because he could geek out on this level that I hadn't seen him do before. And so when I asked, like, "How do you guys stay in touch afterwards?" And they're like, "Oh no, we don't. We don't know how to build a community." And it's like, well, okay, well, we can get that started.

+ +

To your response of like, how do you operate when it is presented as a binary? And it's like, am I this, or am I this? This kind of gets down to the idea of identity-wise, is it a binary, or is it a spectrum? I tend to think of it kind of like an introvert-extrovert spectrum where it's like there is no wrong or right, and you can move in different places.

+ +

And I think being able to explain the nuances of the modeling around how we came up with this messaging can get lost a lot of times. But I'm with you, like, how...and that's kind of something now where it's like, okay, maybe my role was to just start this conversation, but then everybody's having these ideas. But there are people who genuinely feel seen, you know.

+ +

STEPHANIE: Yeah, that's really interesting because what I'm hearing is that when there's this dominant narrative of what a developer should be, and should be good at, and what they should do, it's kind of like what you were saying earlier about how hard it was for you to claim that identity yourself. People who feel differently aren't seen, and that's, I think, the problem.

+ +

And I'm very, very interested in the gender aspect of it because one thing that I've noticed is that a lot of my female developer friends do do more of that mending work. So when you talk about feeling like there was no community out there, it just wasn't represented at the time, you know, a decade ago for sure. And still, even now, I think we're just starting to elevate those voices and that work.

+ +

I wanted to share that at thoughtbot; we have different teams for different business verticals. And so we do have a rapid validation prototyping team. We do have a greenfield like MVP, V1 product team. And then we also have a team, Boost, the team that I'm on. That is more team augmentation, working with legacy code and existing systems. And it was not lost on me that Boost has the most women. [laughs]

+ +

ANDREA: Yeah, because you have the concept of cognitive load and mental load.

+ +

STEPHANIE: Yes.

+ +

ANDREA: Women at home end up taking a lot more of this invisible labor that's behind the scenes. Like, you're picking the kids up from school, or you're doing the laundry, or all these things that are just behind the scenes. And this was actually something...so when Scott and I also got married, that's when I first became aware of this, and it was very similar. And it was, okay, how do I...because Scott and I, both in our business and in our personal partnership, we wanted it to be based on equity. And then also, like, how do I show up?

+ +

And for me, the hardest thing with that was letting go of control where it's like, it has to be a certain way. It's hard for me to comment on the broader enterprise level because what I see at Corgibytes is we have gender parity. That's been pretty balanced over the course of our..., and we're a small boutique company, so it's different. But then, in the larger community of Legacy Code Rocks, it tends to be more male. There are actually fewer women in there.

+ +

And I think, too, like there's this idea of testers and QA, like, I think that falls in there as well, and that's heavily dominant. And I think sometimes it's like, oh...and I think this kind of comes to the problem of it, like, it's the way that we think about the work in general. And this might be useful just to think about kind of the way that it came about was, you know, makers and menders was we were putting together [laughs] actually this talk for this conference that we went to.

+ +

And my background in marketing, I was trying to wrap my brain around when is it appropriate for mending? And I had my marketing degree. It's like, oh, the product lifecycle. And Scott's retort was, "It needs to be a circle. We're agile, so it needs to be a circle." And I was like, this doesn't make any sense. Because look, if you have maturity and then you have it...oh my gosh, it'll link back to innovation, and then you can do new stuff.

+ +

And so yeah, I think when we describe makers and menders, and this is true with any label, the idea in the broader model is that makers and menders aren't necessarily distinct, and your team should 1,000%...everyone should be contributing. And if you only have one person who's doing this work, you're at a detriment. That's not healthy for your codebase like; this should be baked in. And the mender is more of like, this is where I get my joy. It's more of an opt-in. But I think that your observation about the invisible labor and how that gets translated to maintenance work is accurate.

+ +

A lot of times, like when Scott was describing his thing, it's like, there's the movie "Office Space." I might be dating myself. But there's this guy, Milton, and it's like, "Just go to the basement." He was told maintenance is where good software careers go to die. [laughs] And so over the years, it's like, how do we celebrate this and make it more part of the maker work?

+ +

And it's similar to how introverts and extroverts...it's like, we all work together, and you need all of it. But there is an extrovert bias. And extroverts are seen more as, oh, they have leadership traits and stuff. But increasingly, we're starting to see, no, actually, that's not the only way that you can be effective. So I think it's hard. And I think it does come down to belonging. And I think that there are also different cultural impacts there. And it comes down to just a lot of different lived experiences.

+ +

And I so appreciate you sharing your point of view. And I'm curious, what would help you feel more like you belong? Is it the work and the environment that you're in that's kind of contributing to this feeling? Or is it other things in general or?

+ +

STEPHANIE: Okay, so I did want to address real quick what you were saying about mental load and household labor because I think I really only started thinking about this after I read a book called "Equal Partners" by Kate Mangino, where she talks about how to improve gender equality at home, and I loved that book so much. And I suddenly started to see it everywhere in life and obviously at work too. And that's kind of what really drove my thinking around this conversation, maintenance work being considered less skilled labor or things that get offloaded to someone else. I think that really frustrates me because I just don't believe that's true.

+ +

And to get back to what you were asking about what would make me feel more seen or valued, I think it's systemic. But I also think that organizations can make change within their cultures around incentives especially. When you are only promoted if you do greenfield work and write thousands of lines of code, [laughs] that's what people will want to do. [laughs] And not even just promotions, but who gets a kudos in Slack? Or when do you get positive encouragement?

+ +

As a consultant, I've worked on different client teams that had different values, and that was when I really struggled to be in those environments. I have a really strong memory of working on a greenfield project, but there was another male developer who was just cranking out features and doing all of this work and then demoing it to stakeholders. But then there was one feature that he had implemented but had faked the data. So he hadn't finished the backend part of it but just used fake data to demo the user interface to stakeholders. And then he moved on to something else.

+ +

And I was like, wait; this isn't done. [laughs] But at that point, stakeholders thought it was done. They thought that it was complete. They gave him positive feedback for finishing it. And then I had to come in and be like, "This isn't done. Someone needs to work on this." And that person ended up being me. And that was really frustrating because I was doing that behind-the-scenes work, the under-the-hood work for something that had already been attributed to someone else. And yeah, I think about that a lot and what systems or what the environment was that led to that particular dynamic.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: Do you have any advice for leaders who want to make sure there's more equity for people who like to do mending and legacy code work?

+ +

ANDREA: Yeah, absolutely. I am so grateful for your questions and your perspective because this is not something that's talked about a lot, and it is so important. I wrote an article for First Round Review. This was in 2016 or 2017. And it was called "Forget Technical Debt — Here's How to Build Technical Wealth," and so if you want to link to it in the show notes. It's a really long article and that goes into some of the specifics around it, but it's meant for CEOs. It really is meant for CEOs.

+ +

And I do think that you're right; some of it is that we have lionized this culture of making and the work that is more visible. And it's like, oh, okay, great, here's all the visual design stuff. That's fantastic, but then recognizing there's a lot of stuff that's behind the scenes too. So in terms of leaders, I think some of it is you have to think about long-term thinking instead of just the short-term. Don't just chase the new shiny.

+ +

Also, you need to be really aware of what your return on investment is. Because the developers that are working on maintaining and making sure that your mission-critical systems don't fail those are the ones that have the highest value in your organization because if that system goes down, your company makes money. Greenfield work, yes, it's very...and I'm not downplaying greenfield work for sure. I'm definitely, [laughs] like, I love doing that stuff. I love doing the generating phase.

+ +

And at the same time, if we only look towards kind of more the future bias...there's a great book that we were featured in called "The Innovation Delusion" that talks about this more in general. But if we only look at the visible work that's coming, then we forget what's important now. And so for leaders, if you're running a software company, know where your mission-critical systems are and recognize the importance of maintaining them. That's the very first step.

+ +

The second step is to recognize the complexities of a situation, like, to think about things in terms of complex systems instead of complicated systems. And I'll describe the difference. So when I came to software, I had been working in the creative field, like in advertising, and branding, and copywriting, and all that. And we got inputs. We kind of ran it through this process, and then we delivered. And we did a demo and all of that stuff.

+ +

It was when is the timeline? When is it done? Big air quotes. And we were pretty predictably able to deliver on our delivery day. Sometimes things would go wrong, but we kind of had a sense because we had done the same pattern over and over again. You don't get that in legacy code because the variables are so immense that you cannot predict in the same way. You have to adopt a new strategy for how do you measure effectiveness.

+ +

And the idea of measuring software productivity in terms of new features or lines of code, like, that's something that goes all the way back to Dykstra [laughs] in the 1970s around, is that the right way? Well, a lot of people who code are like, "No, that's not." This is a debate that goes back to the earliest days of computing. But I think that the companies that are able to build resilient systems have a competitive advantage.

+ +

If a leader wants to look at their systems, whether that is a social system and the people in their organization or whether or not it's their software if you look at it from a systems thinking, like, there are interactions that I need to pay attention to not just process, that is super key as well. And then the last one is to recognize, like, one of our core values is communication is just as important as code.

+ +

I would be remiss to neglect empathy and communication in part of this, but that really is so important. Because when we position things in terms of...and I don't know as much about thoughtbot and kind of the overall strategy, but kind of an anti-pattern I have seen just in general in organizational behavior is that when you structure teams functionally and silo them, you're not getting that diversity of thought.

+ +

So the way that we approach it is, like, put a mender on a maker team because they're going to have a different perspective. And then, you can work together to get things out the door faster and value each other's perspectives and recognize strengths and shadows. So, for me, as a maker, I'm like, I've got a huge optimism bias, and we can go through all this stuff. And for Scott, it's like he struggles to know when he's done. Like, for me, I'm like, cool, we're 80% done. I got it. We're good to go. And for Scott, he'll work on something, and then it's like, I have to stop him.

+ +

So recognizing that we help each other, that kind of thought diversity and experience diversity goes across so many different vectors, not just makers and menders. But I think, to me, it's about reframing value so that you're not just thinking about what it is right now in this moment. And I think a lot of this comes down to investor strategy too. Because if you've got an investor that you're trying to appease and they're just trying to make short-term monetary gains, it's much harder to think in terms of long term.

+ +

And I think it's developers understanding business, business understanding the struggles of developers and how they need lots of focus time, and how estimating is really freaking hard, and why if you demand something, it's going to be probably not right. And then coming up with frameworks together where...how can I describe this in a way? So to me, it really is about empathy and communication at the end of the day when we're talking about interactions and how do we operationalize it.

+ +

STEPHANIE: I like what you said about reframing value because I do believe that it starts from the top. When you value sustainability...my co-host, Joël, had an episode about sustainability as a value in software development. But then that changes, like I mentioned before, the incentive structures and who gets rewarded for what type of work. And I also think that it's not only diverse types of people who like doing different types of work, but there is value in doing both.

+ +

And I know we talked about it being a spectrum earlier, but I strongly believe that doing the legacy code work and experiencing what it's like to try to change a system that you are like, I have no idea why this decision was made or like, why is the code like this? That will help inform you. If you do do greenfield work, those are really important skills, I think, to bring to that other type of work as well. Because then you're thinking about, okay, how can I make decisions that will help the developers down the line when I'm no longer on this project?

+ +

ANDREA: Exactly, which is a form of empathy. [laughs]

+ +

STEPHANIE: Yeah, it is a form of empathy, exactly. And the reverse is also true too. I was thinking about, okay, how can working in greenfield code help inform working with legacy code? And I was like, oh, you have so much energy when the world is completely open to you, and you can make whatever decisions to deliver value. And I've really struggled working in legacy code, feeling like I don't have any options and that I have to repeat a pattern that's already been set or that I'm just kind of stuck with what I've been given. But I think that there is some value in injecting more of that agency into working with legacy code as well.

+ +

ANDREA: Well, and I think, too, I think you hit it on the head because, like I said, with the mental load at home, it was like, I had to be okay with things failing where it's like, it wasn't exactly the way I would do it, and I had to be okay with that. Like, oh, the dishes aren't put in the dishwasher exactly the same way I would do it. I'm not going behind it. And like, okay, it's not perfect. That's...whoo, it's going to be okay.

+ +

And I think that's kind of what we experience, too, is this idea of we have to figure out how we work together in a way that is sustainable. And I think that, similar to my experience with the technical, non-technical piece, there is an onus. Now, granted, I want to be very careful here to not...there is trauma, and there is absolutely horrific discrimination and abuse. And that is not what I'm talking about here in terms of power dynamics.

+ +

I am talking more about self-identity and self-expression. And I think that if you are in a community like makers and menders, yeah, we're less represented. There is a little bit of an onus, the technical, non-technical, like the onus of understanding what non-technical means and where I can push back is really important work for me to do. Because what I was surprised with was everyone there, like, when I started asking...so my response ended up being, "Help me understand, why did you ask that question?" And I took ownership of the narrative.

+ +

And it was like, oh, well, what I found was that most of the people were like, if you're a recruiter, I don't want to waste your time with a bunch of stuff that you don't want to talk about. And then being able to say, "Oh, okay, I can see that, and you assumed that I was a recruiter because of the way I looked. And I understand the intention here. Next time, if I'm at a software conference, assume that I know how to code and assume that I'm here for a reason."

+ +

And a great opening question is, "What brought you here?" I'm like, oh, okay, when we ask a close-ended question, we position things as a binary, like, are you technical or non-technical? That creates a lot of cognitive dissonance, and it's hard. But if I open it up and say, "What brought you here?" Then I can create my own narrative. There is an aspect of setting boundaries and pushing back a little bit like you said, agency. And that can be really hard because it gets at the core of who you are, and then you have to really explore it.

+ +

And what I found, at least, is in the majority, there have been exceptions, but in the majority of the male-dominated groups that I've been in in my career in software, the majority are very welcoming and want me to be there. But I feel inadequate, and it's more impostor syndrome than I think it is people being discriminatory. Learning about the differences between that and where is my responsibility and where's your responsibility in this that's a tough tension to play.

+ +

STEPHANIE: Absolutely. And I think that's why it's really important that we're having a conversation like this. I think what you're getting at is just the harm of the default assumption that is chronic, [laughs] at least for me sometimes. And you mentioned earlier the history of computing a little bit. And I was really excited about that because I did a little bit of digging and learned about women's history in computing and how after World War II, programming, you know, there were so many women.

+ +

In fact, I think by 1960, more than one in four programmers were women, and they were working on mission-critical work like for NASA for, you know, during World War II for code-breaking. And I read that at the time, that work was deemed boring and tedious, and that's why men didn't want to do it. They wanted to work on hardware, which was what was the cool, creative, interesting work. And the computing work was just second class. That's changed, but in some ways, I'm thinking about, okay, where are we now? And to what degree are we kind of continuing this legacy? And how can we evolve or move beyond it?

+ +

ANDREA: Yeah, you're absolutely right. And in some of the research for the book, one of the things I learned is a lot of people know the name, John von Neumann. He created the von Neumann architecture, that is the foundation of all the hardware that most of us use today. And the very first kind of general purpose digital computer, ENIAC, all...I think it was eight of the people who were programmers for that were women. That team was led by John von Neumann's wife, Klára, and you never hear about Klára. You have to go digging for that.

+ +

And The Smithsonian actually just about 8, 10 years ago did a big anniversary and then realized none of those women were invited to the press conferences. They were not invited. And so there is kind of this...similar to generational wealth, it's the thing that gets passed down. Like, if you're in the rooms in the early days...there was a quote by John Backus, who created FORTRAN and the Backus–Naur principle, where he talked about programming in the 1950s.

+ +

He has an essay, and he was like, yeah, I mean, an idea was anybody who claims it, and we never cited our sources. And so it was whoever had the biggest ego was the one who got credit. And everyone's like, great; you're a hero. And so I think that's kind of the beginning of it. And so if you weren't invited into the room, because in the 1950s, in addition to gender, there was legislation that prevented...we weren't even allowed to use the same bathrooms. You had White bathrooms and Black bathrooms.

+ +

So you had very serious barriers for many different people getting into that room, and I think that gets to the idea of intersectionality as well. So the more barriers that you had, the harder it was going to be. And so then you get the stereotypes, and then you get the media who promotes the stereotypes. And so that is what happened to me. So I grew up in the '80s and '90s, and just every movie I watched, every TV show portrayed somebody who was, quote, "good" with computers in a very specific way. I didn't see myself in it. So I was like, oh, I'm not there.

+ +

But then, when I talk to Scott, he's like, "Oh, I never saw that. I never saw the discrimination. I just saw this stuff." That's part of it is that if you were in that position where discrimination, or difficulties, or stereotypes had been invisible to you, the onus is on you to learn and to listen. If you are in a situation where you feel like you have been in the minority, the onus is on you to find ways to become more empowered.

+ +

And a lot of times, that is setting boundaries. It's advocating for yourself. It's recognizing your self-worth. And those are all things that are really hard. And saying, hey, if we want to be sustainable, everyone needs to contribute. I'm happy to train everyone, but this is not going to work. And being able to frame it, too, in terms of value, like, why? Why is it a benefit for everyone building that empathy?

+ +

And you're right, I mean, there are absolutely cultures where...who was it? I think it was Edward Deming. And he said, "A single person is powerless in the face of a bad system." And so if you're in a system that isn't going to work, recognizing that and can you move into a different system? Or can you change it from within? And those are all different questions that you've got to ask based on your own fortitude, your own interests, your own resources, your own situation. There is no easy question. But it's always work. And no matter who you are, it's always work. [laughs]

+ +

STEPHANIE: Yeah, yeah. I joined as co-host of this podcast just a few months ago. And I had to do a lot of reflecting on what I wanted to get out of it and what my goals were. And that's why I'm really excited to have you on here and to be using this platform to talk about things that are important to me and things that I think more people should know about or think about. So before we wrap up, Andrea, do you have anything else you want to say?

+ +

ANDREA: I want to reinforce that if you feel joy from mending, it's awesome. And there are communities like legacycode.rocks. We have MenderCon, and it's a celebration of software maintenance. So it can be really great. We have a virtual meetup every Wednesday. And there's a kind of a core group of people who come, and they're like, it's like therapy because there are a lot of people who are in your situation where it's like, I'm the only person on my team who cares about automated tests, and I have no idea like...and just having people who kind of share in that struggle can be really helpful, so finding your community.

+ +

And then I think software maintenance is really, really critical and really important, and I think we see it. Like, we're seeing in the news every day in terms of these larger systems going down. Just recently, Southwest Airlines and all of these flights got canceled. The maintenance work is so, so valuable. If you feel like a mender and you feel like that fits your identity, just know that there is a lot of worth in the work that you are doing, an immense amount of worth in the work that you are doing, and to continue to advocate for that.

+ +

If you are a maker, yes, there is absolutely worth in the work you're doing, but learn about menders. Learn how to work together. And if you are a leader of an organization, recognize that all of these different perspectives can work together. And, again, reframe the value.

+ +

So I am so grateful that you framed the conversation this way. It's so important. I'm very, very grateful to hear from you and your point of view. And I hope that you continue to push the narrative like this because it's really important.

+ +

STEPHANIE: Aww, thanks. And thank you so much for being on the podcast.

+ +

ANDREA: Yeah, yeah, absolutely. Thanks for having me.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Stephanie is joined today by a very special guest, Andrea Goulet. Andrea founded Empathy In Tech as part of writing her book Empathy-Driven Software Development. She's also the founder of the community Legacy Code Rocks and the Chief Vision Officer of two companies: Corgibytes and Heartware (which provides financial support to keep Empathy In Tech running).

+ +

Stephanie has strong opinions about the concept of "Makers and Menders" that the Corgibytes folks have written/spoken about, especially around those personas and gender stereotypes. Andrea joins Steph to evolve the conversation and add nuance to the discussion about legacy code/maintenance in our community.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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., And today I'm joined by a very special guest, Andrea Goulet. Hi, Andrea.

+ +

ANDREA: Hello, thanks for having me.

+ +

STEPHANIE: So here on The Bike Shed, we like to start by sharing something new in our world. Could you tell us a bit about yourself and anything new going on for you?

+ +

ANDREA: Yeah, so I have a background in strategic communications, and then kind of made a windy journey over to software. And so, for the past 13 years, I've been focused on modernizing legacy systems. And legacy is kind of a loose term; something you write today can be legacy. But essentially, we kind of help modernize any kind of software, any language, any platform, any framework.

+ +

And so, over the course of doing that, in the work that I did before I came to software, I had a very technical understanding of empathy and communications and had just done a lot of that. And I just noticed how much that mattered in creating healthy and sustainable codebases. So now I'm kind of taking that experience, and I've got a book contract called "Empathy-Driven Software Development." So I've been working on just diving into a lot of the really deep research. So that's been kind of my focus for the past two years.

+ +

And it's been really surprising because there were things that were positioned as truths, and then it's like, wait a second, neuroscience is completely upending everything. So it's been a fun learning journey. And I'm excited to share some of the things that I've learned over the years, especially [laughs] in the past two years with this book. So that is the new thing with me. And it's...I was telling you before it just feels like a constant new thing. Anybody who's written a book...it's the hardest thing I've ever done, so... [laughs]

+ +

STEPHANIE: Yeah, that sounds tough but also kind of exciting because you're learning so many new things that then kind of shape how you view the world, it sounds like.

+ +

ANDREA: Yeah. Yeah, it really does. And I think I really like diving into the details. And I think what started this was...my business partner, Scott, at the time, really embodied the stereotypical 2010 software developer down to the scruffy beard and dark-rimmed glasses. And what I found incredibly interesting was he had this belief of I'm good with machines, but I'm bad with people. And he just had this really deeply ingrained. On the flip side, I had this belief of, oh, I'm good with people, but I'm bad with machines. I'll never learn how to code.

+ +

And I found that really interesting. And personally, I had to go through a journey because we went on...it was the first time either of us had ever been on a podcast. So this was about ten years ago. And at the end of the podcast, Scott was the only one on there. And he said, you know, the person asked about his origin story and about our company Corgibytes. And he was like, "Yeah, you know, Andrea is amazing. She's our non-technical founder."

+ +

And by that time, I had been coding next to him for like three years. And I was like, why the heck would you call me non-technical? And I just felt this...what is it that I have to do to prove it to you? Do I have to actually go get a CS degree? I know I'm self-taught, but does that mean that I'm not good enough? What certificates do I need? Do I need to sit down next to you? Do I need to change my lifestyle? Do I need to look like you? So I was really upset [laughing] and just thinking through, how dare you? How dare you label me as non-technical?

+ +

And Scott is very quiet and patient, great with people, I think. [laughs] And he listened and said, "I use the words that you use to describe yourself. When we were in a sales meeting right before that phone call, I paid attention to how you introduced yourself, and I pretty much used the same words. So when you call yourself technical, I will too." That shattered my world. It shattered my identity because then it put the responsibility of belonging on me. I couldn't blame other people for my not feeling like I didn't belong.

+ +

That journey has just been so profound. This is what I see a lot of times with empathy is that we have these kinds of self-identities, but then we're afraid to open up and share. And we make these assumptions of other people, but, at the same time, there's real-world evidence. And so, how do we interpret that? In addition to this, Scott...like, part of the reason I called myself non-technical was because all of the people I saw who were like me or had my background, that's the word that was used to describe someone like me.

+ +

And when I would go to a conference, you know, I have a feminine presentation. And this was ten years ago. My very first conference was 300 software developers, and there were probably about 295 men. And I was one of five women in the room. And because I looked so different and because I stood out, the first question that anybody would ask me, and this was about 30% to 40% of introductions, was, "Are you technical or non-technical?" And I had to choose between this binary.

+ +

And I was like; I don't know. Am I technical? Like, is it a CEO that can code? I don't know. But then I have this background. And so I would just default to, "No, I guess I'm non-technical," because that's what felt safe because that's what they assumed. And I just didn't know, and I didn't realize that I was then building in this identity.

+ +

And so then, as part of trying to create a warm and inclusive organization, we did one of the unconscious bias surveys from Harvard. And what astonished me when I did that myself was that I didn't have a whole lot of bias, like, there was some. But the most profound bias was against women in the workplace, and it stood out a big one. I was like, how is it that I can be someone who's a fierce advocate, but then that's my own bias against people like me? What the heck is going on? So really exploring all of this.

+ +

And I think Scott and I have had so many different conversations over the years. We actually ended up getting married. And so we have a personal reason to figure a lot of this stuff out too. And when we start to have those conversations about who am I and what's important to me, then all of a sudden, we can start creating better code. We can start working together better as a team. We can start advocating for our needs. Other people know what we need ahead of time. And we're not operating out of defensiveness; we're operating out of collaboration and creativity.

+ +

So the book and kind of everything is inspired by my background and my lived experience but then also seeing Scott and his struggles, too, because he had been told like, "You're a geek. Stay in the computers. Stay in the code. You're not allowed to talk to customers because you're bad at it," and flat out was told that.

+ +

So how do we overcome these labels that people have put on us, and then we've made part of our own identity? And which ones are useful, and then which ones are not? Because sometimes labels can create a sense of community and affinity and so how do we know? And it's complicated, but the same thing, software is complicated. We can take skills like empathy and communication. We can look at them schematically and operationalize them when we look at them in kind of detail. So that's what I enjoy doing is looking under the hood and figuring out how does all this stuff work? So... [laughs]

+ +

STEPHANIE: I did want to respond to a few things that I heard you say when you're talking about going to a conference and feeling very much in the minority. I went to my first RailsConf in 2022, my first RailsConf in person, and I was shocked at the gender imbalance. And I feel like every time I used the women's restroom; I was looking around and trying to make a connection with someone and have a bit of a kinship and be like, oh yes, you are here with me in this space. And then we would have a conversation and walk out together, and that felt very meaningful because the rest of the space, you know, I wasn't finding my people. And so I feel that very hard.

+ +

I think this is also a good time to transition into the idea of makers and menders, especially because we have been talking about labels. So you all talked about this distinction between the different types of work in software development. So we have greenfield work, and that is writing code from scratch, making all the decisions about how to set up an application, exploring a whole new domain that hasn't been codified yet. And that is one type of work.

+ +

But there's also mender-type work, which is working in existing applications, legacy code, refactoring, and dealing with the complexity of something that has stood the test of time but may or may not have gotten a lot of investment or care and bringing that codebase back to life if you will. And when I first heard about that distinction, I was like, yes, I'm a mender. This is what I like to do. But the more I thought about it, I started to also feel conflicted because I felt pain doing that work as well.

+ +

ANDREA: Oh, interesting, yeah.

+ +

STEPHANIE: Especially in the context of teams that I've been on when that work was not valued. And I was doing maintenance work and fixing bugs and either specifically being assigned to do that work or just doing it because I knew it needed to be done and no one else was doing it. And that had caused me a lot of frustration before because I would look around and be on a team with mostly White men and be like, why aren't they picking up any of this work as well?

+ +

And so I was thinking about how I both felt very seen by the acknowledgment that this is work, and this is valid work, and it's important work, but also a little bit confused because I'm like, how did I get here? Did I pigeonhole myself into doing this work? Because the more I did it, the better I got at it, the more comfortable and, to whatever degree, enjoyed it. But at the same time, I'm not totally sure I was given the opportunity to do greenfield work earlier in my career. That could have changed where my interests lie.

+ +

ANDREA: Yeah, it is. And it's funny that you mentioned this because I actually I'm a maker. But yeah, I created this community, and I'm known for this thing. And I had a very similar experience to how do I exist as someone who's different in this kind of community? And I think part of it is, you know, there's a great quote by George Box, who is a statistician, and he says, "All models are wrong; some are useful."

+ +

And I think that's kind of the whole idea with the maker-mender is that it is a signal to be like, hey, if you like fixing stuff...because there is so much shame, like, that's what we were responding to. And Scott had the opposite problem of what you have experienced, where he was only allowed to work on greenfield work. They were like, "No, you're a good developer. So we want you working on features. We won't let you fix the bugs. We won't let you do the work that you like doing." And so that's why he wanted to create Corgibytes because he's like, "This work needs to be done." I am so personally passionate about this.

+ +

And when we were having these conversations 13 years ago, I was talking to him about product/market fit and stuff like that. And I was like, "You like fixing software, and there's a lot of software out there to be fixed." I just was very, very confused as to why this kind of existed. And we had been told flat out, "You're never going to find anybody else like Scott. You're never going to be able to build a company around people who find a lot of joy in doing this work."

+ +

And I think that this comes down to identity and kind of the way that Legacy Code Rocks was built too. A lot of the signaling that we put out there and the messaging and stuff really came from Scott's feeling of, like, I want to find more people like me. So being in the women's bathroom and like, how do I find more menders? Or how do I find people...because we were walking through a Barnes & Noble, and it was like a maker fest, maker everything. And he's like, "I don't have a community. There's nowhere for me to go to create these meaningful connections," exactly like you were saying. "I have maybe two people in my network."

+ +

And then we were at a conference in 2015. We were at the large agile conference. And it was one of the first ones that I've been to that had a software craft track. And we met like 20 people who were really, like, I just saw Scott light up in a way that I hadn't seen him light up because he could geek out on this level that I hadn't seen him do before. And so when I asked, like, "How do you guys stay in touch afterwards?" And they're like, "Oh no, we don't. We don't know how to build a community." And it's like, well, okay, well, we can get that started.

+ +

To your response of like, how do you operate when it is presented as a binary? And it's like, am I this, or am I this? This kind of gets down to the idea of identity-wise, is it a binary, or is it a spectrum? I tend to think of it kind of like an introvert-extrovert spectrum where it's like there is no wrong or right, and you can move in different places.

+ +

And I think being able to explain the nuances of the modeling around how we came up with this messaging can get lost a lot of times. But I'm with you, like, how...and that's kind of something now where it's like, okay, maybe my role was to just start this conversation, but then everybody's having these ideas. But there are people who genuinely feel seen, you know.

+ +

STEPHANIE: Yeah, that's really interesting because what I'm hearing is that when there's this dominant narrative of what a developer should be, and should be good at, and what they should do, it's kind of like what you were saying earlier about how hard it was for you to claim that identity yourself. People who feel differently aren't seen, and that's, I think, the problem.

+ +

And I'm very, very interested in the gender aspect of it because one thing that I've noticed is that a lot of my female developer friends do do more of that mending work. So when you talk about feeling like there was no community out there, it just wasn't represented at the time, you know, a decade ago for sure. And still, even now, I think we're just starting to elevate those voices and that work.

+ +

I wanted to share that at thoughtbot; we have different teams for different business verticals. And so we do have a rapid validation prototyping team. We do have a greenfield like MVP, V1 product team. And then we also have a team, Boost, the team that I'm on. That is more team augmentation, working with legacy code and existing systems. And it was not lost on me that Boost has the most women. [laughs]

+ +

ANDREA: Yeah, because you have the concept of cognitive load and mental load.

+ +

STEPHANIE: Yes.

+ +

ANDREA: Women at home end up taking a lot more of this invisible labor that's behind the scenes. Like, you're picking the kids up from school, or you're doing the laundry, or all these things that are just behind the scenes. And this was actually something...so when Scott and I also got married, that's when I first became aware of this, and it was very similar. And it was, okay, how do I...because Scott and I, both in our business and in our personal partnership, we wanted it to be based on equity. And then also, like, how do I show up?

+ +

And for me, the hardest thing with that was letting go of control where it's like, it has to be a certain way. It's hard for me to comment on the broader enterprise level because what I see at Corgibytes is we have gender parity. That's been pretty balanced over the course of our..., and we're a small boutique company, so it's different. But then, in the larger community of Legacy Code Rocks, it tends to be more male. There are actually fewer women in there.

+ +

And I think, too, like there's this idea of testers and QA, like, I think that falls in there as well, and that's heavily dominant. And I think sometimes it's like, oh...and I think this kind of comes to the problem of it, like, it's the way that we think about the work in general. And this might be useful just to think about kind of the way that it came about was, you know, makers and menders was we were putting together [laughs] actually this talk for this conference that we went to.

+ +

And my background in marketing, I was trying to wrap my brain around when is it appropriate for mending? And I had my marketing degree. It's like, oh, the product lifecycle. And Scott's retort was, "It needs to be a circle. We're agile, so it needs to be a circle." And I was like, this doesn't make any sense. Because look, if you have maturity and then you have it...oh my gosh, it'll link back to innovation, and then you can do new stuff.

+ +

And so yeah, I think when we describe makers and menders, and this is true with any label, the idea in the broader model is that makers and menders aren't necessarily distinct, and your team should 1,000%...everyone should be contributing. And if you only have one person who's doing this work, you're at a detriment. That's not healthy for your codebase like; this should be baked in. And the mender is more of like, this is where I get my joy. It's more of an opt-in. But I think that your observation about the invisible labor and how that gets translated to maintenance work is accurate.

+ +

A lot of times, like when Scott was describing his thing, it's like, there's the movie "Office Space." I might be dating myself. But there's this guy, Milton, and it's like, "Just go to the basement." He was told maintenance is where good software careers go to die. [laughs] And so over the years, it's like, how do we celebrate this and make it more part of the maker work?

+ +

And it's similar to how introverts and extroverts...it's like, we all work together, and you need all of it. But there is an extrovert bias. And extroverts are seen more as, oh, they have leadership traits and stuff. But increasingly, we're starting to see, no, actually, that's not the only way that you can be effective. So I think it's hard. And I think it does come down to belonging. And I think that there are also different cultural impacts there. And it comes down to just a lot of different lived experiences.

+ +

And I so appreciate you sharing your point of view. And I'm curious, what would help you feel more like you belong? Is it the work and the environment that you're in that's kind of contributing to this feeling? Or is it other things in general or?

+ +

STEPHANIE: Okay, so I did want to address real quick what you were saying about mental load and household labor because I think I really only started thinking about this after I read a book called "Equal Partners" by Kate Mangino, where she talks about how to improve gender equality at home, and I loved that book so much. And I suddenly started to see it everywhere in life and obviously at work too. And that's kind of what really drove my thinking around this conversation, maintenance work being considered less skilled labor or things that get offloaded to someone else. I think that really frustrates me because I just don't believe that's true.

+ +

And to get back to what you were asking about what would make me feel more seen or valued, I think it's systemic. But I also think that organizations can make change within their cultures around incentives especially. When you are only promoted if you do greenfield work and write thousands of lines of code, [laughs] that's what people will want to do. [laughs] And not even just promotions, but who gets a kudos in Slack? Or when do you get positive encouragement?

+ +

As a consultant, I've worked on different client teams that had different values, and that was when I really struggled to be in those environments. I have a really strong memory of working on a greenfield project, but there was another male developer who was just cranking out features and doing all of this work and then demoing it to stakeholders. But then there was one feature that he had implemented but had faked the data. So he hadn't finished the backend part of it but just used fake data to demo the user interface to stakeholders. And then he moved on to something else.

+ +

And I was like, wait; this isn't done. [laughs] But at that point, stakeholders thought it was done. They thought that it was complete. They gave him positive feedback for finishing it. And then I had to come in and be like, "This isn't done. Someone needs to work on this." And that person ended up being me. And that was really frustrating because I was doing that behind-the-scenes work, the under-the-hood work for something that had already been attributed to someone else. And yeah, I think about that a lot and what systems or what the environment was that led to that particular dynamic.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: Do you have any advice for leaders who want to make sure there's more equity for people who like to do mending and legacy code work?

+ +

ANDREA: Yeah, absolutely. I am so grateful for your questions and your perspective because this is not something that's talked about a lot, and it is so important. I wrote an article for First Round Review. This was in 2016 or 2017. And it was called "Forget Technical Debt — Here's How to Build Technical Wealth," and so if you want to link to it in the show notes. It's a really long article and that goes into some of the specifics around it, but it's meant for CEOs. It really is meant for CEOs.

+ +

And I do think that you're right; some of it is that we have lionized this culture of making and the work that is more visible. And it's like, oh, okay, great, here's all the visual design stuff. That's fantastic, but then recognizing there's a lot of stuff that's behind the scenes too. So in terms of leaders, I think some of it is you have to think about long-term thinking instead of just the short-term. Don't just chase the new shiny.

+ +

Also, you need to be really aware of what your return on investment is. Because the developers that are working on maintaining and making sure that your mission-critical systems don't fail those are the ones that have the highest value in your organization because if that system goes down, your company makes money. Greenfield work, yes, it's very...and I'm not downplaying greenfield work for sure. I'm definitely, [laughs] like, I love doing that stuff. I love doing the generating phase.

+ +

And at the same time, if we only look towards kind of more the future bias...there's a great book that we were featured in called "The Innovation Delusion" that talks about this more in general. But if we only look at the visible work that's coming, then we forget what's important now. And so for leaders, if you're running a software company, know where your mission-critical systems are and recognize the importance of maintaining them. That's the very first step.

+ +

The second step is to recognize the complexities of a situation, like, to think about things in terms of complex systems instead of complicated systems. And I'll describe the difference. So when I came to software, I had been working in the creative field, like in advertising, and branding, and copywriting, and all that. And we got inputs. We kind of ran it through this process, and then we delivered. And we did a demo and all of that stuff.

+ +

It was when is the timeline? When is it done? Big air quotes. And we were pretty predictably able to deliver on our delivery day. Sometimes things would go wrong, but we kind of had a sense because we had done the same pattern over and over again. You don't get that in legacy code because the variables are so immense that you cannot predict in the same way. You have to adopt a new strategy for how do you measure effectiveness.

+ +

And the idea of measuring software productivity in terms of new features or lines of code, like, that's something that goes all the way back to Dykstra [laughs] in the 1970s around, is that the right way? Well, a lot of people who code are like, "No, that's not." This is a debate that goes back to the earliest days of computing. But I think that the companies that are able to build resilient systems have a competitive advantage.

+ +

If a leader wants to look at their systems, whether that is a social system and the people in their organization or whether or not it's their software if you look at it from a systems thinking, like, there are interactions that I need to pay attention to not just process, that is super key as well. And then the last one is to recognize, like, one of our core values is communication is just as important as code.

+ +

I would be remiss to neglect empathy and communication in part of this, but that really is so important. Because when we position things in terms of...and I don't know as much about thoughtbot and kind of the overall strategy, but kind of an anti-pattern I have seen just in general in organizational behavior is that when you structure teams functionally and silo them, you're not getting that diversity of thought.

+ +

So the way that we approach it is, like, put a mender on a maker team because they're going to have a different perspective. And then, you can work together to get things out the door faster and value each other's perspectives and recognize strengths and shadows. So, for me, as a maker, I'm like, I've got a huge optimism bias, and we can go through all this stuff. And for Scott, it's like he struggles to know when he's done. Like, for me, I'm like, cool, we're 80% done. I got it. We're good to go. And for Scott, he'll work on something, and then it's like, I have to stop him.

+ +

So recognizing that we help each other, that kind of thought diversity and experience diversity goes across so many different vectors, not just makers and menders. But I think, to me, it's about reframing value so that you're not just thinking about what it is right now in this moment. And I think a lot of this comes down to investor strategy too. Because if you've got an investor that you're trying to appease and they're just trying to make short-term monetary gains, it's much harder to think in terms of long term.

+ +

And I think it's developers understanding business, business understanding the struggles of developers and how they need lots of focus time, and how estimating is really freaking hard, and why if you demand something, it's going to be probably not right. And then coming up with frameworks together where...how can I describe this in a way? So to me, it really is about empathy and communication at the end of the day when we're talking about interactions and how do we operationalize it.

+ +

STEPHANIE: I like what you said about reframing value because I do believe that it starts from the top. When you value sustainability...my co-host, Joël, had an episode about sustainability as a value in software development. But then that changes, like I mentioned before, the incentive structures and who gets rewarded for what type of work. And I also think that it's not only diverse types of people who like doing different types of work, but there is value in doing both.

+ +

And I know we talked about it being a spectrum earlier, but I strongly believe that doing the legacy code work and experiencing what it's like to try to change a system that you are like, I have no idea why this decision was made or like, why is the code like this? That will help inform you. If you do do greenfield work, those are really important skills, I think, to bring to that other type of work as well. Because then you're thinking about, okay, how can I make decisions that will help the developers down the line when I'm no longer on this project?

+ +

ANDREA: Exactly, which is a form of empathy. [laughs]

+ +

STEPHANIE: Yeah, it is a form of empathy, exactly. And the reverse is also true too. I was thinking about, okay, how can working in greenfield code help inform working with legacy code? And I was like, oh, you have so much energy when the world is completely open to you, and you can make whatever decisions to deliver value. And I've really struggled working in legacy code, feeling like I don't have any options and that I have to repeat a pattern that's already been set or that I'm just kind of stuck with what I've been given. But I think that there is some value in injecting more of that agency into working with legacy code as well.

+ +

ANDREA: Well, and I think, too, I think you hit it on the head because, like I said, with the mental load at home, it was like, I had to be okay with things failing where it's like, it wasn't exactly the way I would do it, and I had to be okay with that. Like, oh, the dishes aren't put in the dishwasher exactly the same way I would do it. I'm not going behind it. And like, okay, it's not perfect. That's...whoo, it's going to be okay.

+ +

And I think that's kind of what we experience, too, is this idea of we have to figure out how we work together in a way that is sustainable. And I think that, similar to my experience with the technical, non-technical piece, there is an onus. Now, granted, I want to be very careful here to not...there is trauma, and there is absolutely horrific discrimination and abuse. And that is not what I'm talking about here in terms of power dynamics.

+ +

I am talking more about self-identity and self-expression. And I think that if you are in a community like makers and menders, yeah, we're less represented. There is a little bit of an onus, the technical, non-technical, like the onus of understanding what non-technical means and where I can push back is really important work for me to do. Because what I was surprised with was everyone there, like, when I started asking...so my response ended up being, "Help me understand, why did you ask that question?" And I took ownership of the narrative.

+ +

And it was like, oh, well, what I found was that most of the people were like, if you're a recruiter, I don't want to waste your time with a bunch of stuff that you don't want to talk about. And then being able to say, "Oh, okay, I can see that, and you assumed that I was a recruiter because of the way I looked. And I understand the intention here. Next time, if I'm at a software conference, assume that I know how to code and assume that I'm here for a reason."

+ +

And a great opening question is, "What brought you here?" I'm like, oh, okay, when we ask a close-ended question, we position things as a binary, like, are you technical or non-technical? That creates a lot of cognitive dissonance, and it's hard. But if I open it up and say, "What brought you here?" Then I can create my own narrative. There is an aspect of setting boundaries and pushing back a little bit like you said, agency. And that can be really hard because it gets at the core of who you are, and then you have to really explore it.

+ +

And what I found, at least, is in the majority, there have been exceptions, but in the majority of the male-dominated groups that I've been in in my career in software, the majority are very welcoming and want me to be there. But I feel inadequate, and it's more impostor syndrome than I think it is people being discriminatory. Learning about the differences between that and where is my responsibility and where's your responsibility in this that's a tough tension to play.

+ +

STEPHANIE: Absolutely. And I think that's why it's really important that we're having a conversation like this. I think what you're getting at is just the harm of the default assumption that is chronic, [laughs] at least for me sometimes. And you mentioned earlier the history of computing a little bit. And I was really excited about that because I did a little bit of digging and learned about women's history in computing and how after World War II, programming, you know, there were so many women.

+ +

In fact, I think by 1960, more than one in four programmers were women, and they were working on mission-critical work like for NASA for, you know, during World War II for code-breaking. And I read that at the time, that work was deemed boring and tedious, and that's why men didn't want to do it. They wanted to work on hardware, which was what was the cool, creative, interesting work. And the computing work was just second class. That's changed, but in some ways, I'm thinking about, okay, where are we now? And to what degree are we kind of continuing this legacy? And how can we evolve or move beyond it?

+ +

ANDREA: Yeah, you're absolutely right. And in some of the research for the book, one of the things I learned is a lot of people know the name, John von Neumann. He created the von Neumann architecture, that is the foundation of all the hardware that most of us use today. And the very first kind of general purpose digital computer, ENIAC, all...I think it was eight of the people who were programmers for that were women. That team was led by John von Neumann's wife, Klára, and you never hear about Klára. You have to go digging for that.

+ +

And The Smithsonian actually just about 8, 10 years ago did a big anniversary and then realized none of those women were invited to the press conferences. They were not invited. And so there is kind of this...similar to generational wealth, it's the thing that gets passed down. Like, if you're in the rooms in the early days...there was a quote by John Backus, who created FORTRAN and the Backus–Naur principle, where he talked about programming in the 1950s.

+ +

He has an essay, and he was like, yeah, I mean, an idea was anybody who claims it, and we never cited our sources. And so it was whoever had the biggest ego was the one who got credit. And everyone's like, great; you're a hero. And so I think that's kind of the beginning of it. And so if you weren't invited into the room, because in the 1950s, in addition to gender, there was legislation that prevented...we weren't even allowed to use the same bathrooms. You had White bathrooms and Black bathrooms.

+ +

So you had very serious barriers for many different people getting into that room, and I think that gets to the idea of intersectionality as well. So the more barriers that you had, the harder it was going to be. And so then you get the stereotypes, and then you get the media who promotes the stereotypes. And so that is what happened to me. So I grew up in the '80s and '90s, and just every movie I watched, every TV show portrayed somebody who was, quote, "good" with computers in a very specific way. I didn't see myself in it. So I was like, oh, I'm not there.

+ +

But then, when I talk to Scott, he's like, "Oh, I never saw that. I never saw the discrimination. I just saw this stuff." That's part of it is that if you were in that position where discrimination, or difficulties, or stereotypes had been invisible to you, the onus is on you to learn and to listen. If you are in a situation where you feel like you have been in the minority, the onus is on you to find ways to become more empowered.

+ +

And a lot of times, that is setting boundaries. It's advocating for yourself. It's recognizing your self-worth. And those are all things that are really hard. And saying, hey, if we want to be sustainable, everyone needs to contribute. I'm happy to train everyone, but this is not going to work. And being able to frame it, too, in terms of value, like, why? Why is it a benefit for everyone building that empathy?

+ +

And you're right, I mean, there are absolutely cultures where...who was it? I think it was Edward Deming. And he said, "A single person is powerless in the face of a bad system." And so if you're in a system that isn't going to work, recognizing that and can you move into a different system? Or can you change it from within? And those are all different questions that you've got to ask based on your own fortitude, your own interests, your own resources, your own situation. There is no easy question. But it's always work. And no matter who you are, it's always work. [laughs]

+ +

STEPHANIE: Yeah, yeah. I joined as co-host of this podcast just a few months ago. And I had to do a lot of reflecting on what I wanted to get out of it and what my goals were. And that's why I'm really excited to have you on here and to be using this platform to talk about things that are important to me and things that I think more people should know about or think about. So before we wrap up, Andrea, do you have anything else you want to say?

+ +

ANDREA: I want to reinforce that if you feel joy from mending, it's awesome. And there are communities like legacycode.rocks. We have MenderCon, and it's a celebration of software maintenance. So it can be really great. We have a virtual meetup every Wednesday. And there's a kind of a core group of people who come, and they're like, it's like therapy because there are a lot of people who are in your situation where it's like, I'm the only person on my team who cares about automated tests, and I have no idea like...and just having people who kind of share in that struggle can be really helpful, so finding your community.

+ +

And then I think software maintenance is really, really critical and really important, and I think we see it. Like, we're seeing in the news every day in terms of these larger systems going down. Just recently, Southwest Airlines and all of these flights got canceled. The maintenance work is so, so valuable. If you feel like a mender and you feel like that fits your identity, just know that there is a lot of worth in the work that you are doing, an immense amount of worth in the work that you are doing, and to continue to advocate for that.

+ +

If you are a maker, yes, there is absolutely worth in the work you're doing, but learn about menders. Learn how to work together. And if you are a leader of an organization, recognize that all of these different perspectives can work together. And, again, reframe the value.

+ +

So I am so grateful that you framed the conversation this way. It's so important. I'm very, very grateful to hear from you and your point of view. And I hope that you continue to push the narrative like this because it's really important.

+ +

STEPHANIE: Aww, thanks. And thank you so much for being on the podcast.

+ +

ANDREA: Yeah, yeah, absolutely. Thanks for having me.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Ak60hId4 + + ]]> + + Stephanie Minn + + + 372: Onboarding (Well!) Onto a Project + https://bikeshed.thoughtbot.com/372 + 0a5cb076-4da2-4d34-883a-0346fef90827 + Tue, 21 Feb 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie raves about more software development-related zines by Julia Evans. Joël has been thinking about the mechanics of rolling dice. + +Stephanie also started on a new client project that Joël has already been working on for many months. They talk about onboarding. + 37:37 + no + + + Stephanie raves about more software development-related zines by Julia Evans. Joël has been thinking about the mechanics of rolling dice. +Stephanie also started on a new client project that Joël has already been working on for many months. They talk about onboarding. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Julia Evan's Wizard Zines (https://wizardzines.com/) +Why's Poignant Guide To Ruby (http://poignant.guide/) +Learn You A Haskell For Great Good (http://www.learnyouahaskell.com/) +Mazes for Programmers (http://mazesforprogrammers.com/) +thoughtbot dotfiles (https://github.com/thoughtbot/dotfiles) +rcm (https://github.com/thoughtbot/rcm) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +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 I got a very exciting package in the mail the other day that I wanted to share with you. So I think I've mentioned her on the pod before, but I got a package of software development-related zines by Julia Evans, and I'm going to share a few of the titles that I got. +So I picked up, "Oh shit, git!" [laughs] Can I swear on this podcast? I don't know. I guess we're going to find out. Or maybe we can just make the executive decision that it's fine. [laughs] I also got "Hell Yes! CSS!", "The Pocket Guide to Debugging," which I think I mentioned previously. I had seen the PDF version before, but now I have this cute, little, I don't know, six-inch book that I can carry around for all of my debugging needs. Who knows? Maybe I'll be out in the world and just need to pull it out [laughs] and debug something while I'm on the train; who's to say? And then I also picked up "HTTP: Learn Your Browser's Language!" +So I'm really excited to have these little illustrated digest-sized resources. I think they'll look really cute on my shelf next to my more intense hardcore technical books like "Design Patterns" and "Practical Object-Oriented Design in Ruby" or whatever. I'm really excited about the more creative endeavors people have done with creating educational resources about software development. In fact, I think last time when we talked about creativity and creative expression, we totally missed the world of side projects. And I've really just enjoyed when people illustrate things and make stuff a lot more accessible to a wider audience than a traditional textbook or more text-based heavy resources. +JOËL: I love when people go for a bit more of the playful or quirky when dealing with technical topics. And this is a great example. I love Julia Evans' work. But I'm also reminded of things like "Why's (poignant) Guide to Ruby," "Learn You a Haskell for Great Good!" or even...I forget the title of it. But there's a book by...I think it's Jamis Buck on mazes. And it's told in this sort of quirky style in a narrative. But it's all about maze-solving algorithms but told through the eyes of characters who are wandering through a maze, and it's just delightful. +STEPHANIE: Aww, that's so cute. I love that. I also just had the thought that these things would make great gifts for a fledgling developer or a developer in your life who, if you don't want to get them something super specialized or technical or whatever. There are so many, like you said, quirky and fun things out there that I'm sure they'll appreciate. So, Joël, what's new in your world? +JOËL: I play D&D regularly with some colleagues at thoughtbot. And recently, I got to thinking about the mechanics of rolling dice. Specifically, what dice can be rolled together? Like, can I roll multiple dice at the same time? And which one do you have to wait for the outcome of a previous roll before it makes sense to roll it? +That was really interesting to me because I think that connects to a lot of other things that we do in software, where sometimes some things are independent. You can do them at the same time. And then, other times, you have to wait for the outcome of the first thing before you can even start doing the second thing. So I think, in many ways, it's a great metaphor for the difference between parallel versus series operations. +STEPHANIE: I think it's very funny that you found a way to connect D&D to software development. I'm just imagining you rolling your die and then while you're doing that, having some revelation like the math lady meme or whatever, just thinking about, whoa, if this outcome happens, then [laughs] what happens? +I have not joined in on our company's D&D campaign, but I do like that y'all post little updates about the story in a public space for the whole company to check out. So sometimes I've been searching for some message in our company's knowledge base, and I have stumbled upon a post about the campaign so far and what happened in last night's session, you know, how all the adventurers fought the big bird, [laughs] and it is very delightful to me. +JOËL: It's a really fun way, I think to be creative. I think I enjoy the role-playing side of it a little bit more than just the mechanics of rolling dice, even though the thing I was excited to share today is rolling dice is fun. It is kind of like doing improv, where you're trying to figure out what would your character do and how do they respond to what other people say? It's fun, but it's hard. +STEPHANIE: One burning question I have is, does anyone do voices for their characters? +JOËL: Absolutely. Aji Slater, who was on a previous episode of this podcast, is part of this campaign, and their character has some really fun voices. +STEPHANIE: That's awesome. I'm really interested in joining as a guest or something. But yeah, the improv aspect of it kind of freaks me out. I bet it's a really welcoming group. And if other people are getting into it, then I can get into it too. +JOËL: Yeah, this group is very, very low-key. Most people playing, I think, are fairly new to the game. So it's very friendly, very kind of tolerant of, oh, you didn't know this rule existed, that's totally fine. We'll make it work, things like that. +STEPHANIE: Nice. So another recent development in my world is that I started a new client project, actually the same client that you've been working on for many months, Joël. +JOËL: Yes, the same client but different teams within the client. So we don't get to necessarily interact with each other day to day. But it is interesting that now we get to share knowledge about how this application works with each other. +STEPHANIE: Yeah, yeah. And I don't think we've gotten a chance to work together even in the same world like this before. So that's kind of exciting. +JOËL: How has the onboarding been for you? +STEPHANIE: So, one onboarding development that was surprisingly easy and felt good was setting up a new laptop. So the client company shipped a laptop to me to use for all of their work. And I had to set up just the laptop from scratch, so I could develop on it. And I was able to do that pretty painlessly with the help of the dotfiles that I had previously put together and all of the configurations that I had exported and uploaded to like a cloud drive. +And so I was able to have that up and running within a day with all of my favorite keyboard shortcuts, applications, all my little preferences, and that felt really good. So I'm going to pat myself on the back [laughs] for past Stephanie's efforts in making current Stephanie's life easier. +JOËL: I'm curious, do you use thoughtbot's dotfiles as the base for your development environment, or do you use something custom? +STEPHANIE: I have my own personal dotfiles that I have in a GitHub repo. But I think I did, at one point, go through thoughtbot's dotfiles for inspiration. I found that it has just a lot of extra stuff that I don't really need, but I do like that it's out there. So if any folks want a place to start with having a laptop setup configuration, you should definitely check that out. And we can link that in the show notes. +JOËL: I really like the tool rcm, which is also by thoughtbot that allows you to have a modular system of dotfiles that you can pull from a few different sources and combine together. +STEPHANIE: Oh, that's neat. I hadn't known about that one. That's cool. +JOËL: It's a suite of command-line tools that allows you to pull probably from a git repo. And it might be several, and then trying to pull them all to the right place on your machine to be executable. So, in my case, I have the thoughtbot dotfiles and then also some personal ones. And it just kind of merges them together based on some rules and creates all the dotfiles in my home directory for that. +STEPHANIE: Nice. I think the one thing that I do need to keep up on is pushing updates to the dotfiles when I make changes locally because I did have to pull in a few things that I had adjusted or made tweaks to that didn't make it to the source that I was pulling from on this new machine. This is actually my fifth MacBook that I own [laughs] just from remnants of jobs and clients' past. And one day...I keep telling myself that I'll have to return one of the older ones that I'm not using anymore, but as of now, I am an owner of five computers. [laughs] +JOËL: Just start mining Bitcoin on the idle ones. +STEPHANIE: Oh. [laughs] That's genius. I guess that's definitely a better use than them just sitting in my drawers. +JOËL: I guess you're paying for power, and that's kind of the whole point, so... +STEPHANIE: That's fair. +JOËL: What are some things that you like to do when you onboard onto a new project? +STEPHANIE: So, aside from my laptop adventures, when I joined this new project, I had a few things in mind that I wanted to achieve during this onboarding process. One of the things I think I want to get better at is understanding the business when I'm onboarding onto a new client. I think this is an area that previously I hadn't really focused on, but I'm now understanding is actually really important to being set up for success on a team. +And so, as consultants, we're dropped into a client project oftentimes when things are already moving. And they kind of clearly have some things that they were hoping we could help with. But I am hoping to also use this time to just take a bit of a step back and ask questions about, like, what is the product? And what are its core features? And who are its users? And also, what's the direction of the business? Can I get some more context on how things are right now? +We're so frequently brought in and being like, okay, like, you're going to work on this project but without the context of is the business scaling right now, or what are its struggles? We aren't quite able to make as informed decisions as we could if we had been at the company for longer and had just seen things change and had more of a feel of why we're doing what we're doing. +JOËL: I love that you're asking all those questions upfront. I feel like coming in onto a new project, and that can be as a consultant, or it could be just starting a new job, is the perfect time to just be asking all of those questions. And people, I think, appreciate when we ask those questions. Sometimes I think as consultants; we can sometimes be afraid that, oh, if we're asking these sorts of basic questions, people might think less of us. +But I think the opposite happens where because we're asking those foundational questions about the business model, about the future of the product, about how the technical architecture works, people really appreciate that we're asking those foundational questions where other people might not. So it actually helps build credibility rather than hurting credibility. +STEPHANIE: Yeah, and I think they are really important in making the right technical decision, too, because it can help inform where you spend your time refactoring or evaluating whether this shortcut is worth it to meet this deadline or if it's not because of the bigger picture and where things are headed. If anything, I've learned that being a developer really isn't just about being in the code but having as much information as possible so that there is less ambiguity and you have more clarity to make the right choices when you do have to write the code. +Another key aspect that I have become a lot more observational about, I think, is understanding the team that I'm joining, especially what their process is, how they communicate. One thing that's kind of funny about seeing a lot of different companies and how they work as consultants is they might claim to use agile, but in reality, it is a little bit different than that. And you can have that perspective as an outsider. Things like pointing an estimation is kind of all over the place in the industry. So I really like to make sure I fully understand how the team does that and what points means to them. +I think another thing that I want to do during my onboarding time this week and as I'm getting to know developers on the client side is learning about the pain points that they're feeling. And, yeah, just getting more of a feel about what's top of mind for them and where is a good space to invest my time and my energy. +Lastly, some more basic stuff is communication. Another thing about being a contractor that's challenging is that we don't normally get the full onboarding experience that full-time hires do. And so we may or may not have an onboarding mentor or a buddy and finding out, okay, who is the right person that I should be asking questions to? Or where's the right space for that? When you join new teams, are there any other things that you like to take into consideration? +JOËL: I like that you talked about understanding the team's process. One thing that I often like to do pretty early on is make some kind of small code change but then have it go through the full process of coding on my machine to deploy it in production. And so just find some small change in the code that needs to be done, and maybe it's an easy bug fix or something. But just so I can walk through all the steps and find out what the team's process is. +What are some sort of weird things that this team does that other people might not that I need to know about? Where does review happen? Is there a staging environment, unexpected ways which my change might get rejected? Things like that. So walking through the entire, I guess you could say software development lifecycle, kind of speedrunning is, I think, a really valuable exercise to do really early on a new project. +STEPHANIE: Yeah, that's a great point. Like I mentioned, I think that looks so different for every team. And I'm now learning about new tools and SaaS products that I have never seen before. And even though I have an understanding of the software development lifecycle in general, just learning those quirks is very valuable so that you can be a contributor as soon as possible. +JOËL: I like to contribute on day one, if possible, so kind of in order of...I don't want to say order of priority. But the order of things that I often do on a new project is one, clone the repo, try to run the setup script, or manually step through instructions in the README. Depending on the repo, that might be 10 minutes. That might be all of my first day. +Number two, try to run the test suite. +STEPHANIE: Yes. +JOËL: Number three is figure out what went wrong for me in step one or two, make a fix for it, commit it, and open up a PR for it, and that's my contribution. If I can do those three things on day one, I feel like that is a solid first day. +STEPHANIE: That's great. I love that. What can you do to help improve this process and make it just a little bit better for someone else? I think another good first-day task might be automating a part of that process that is currently manual and kind of annoying. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: So once you've cloned the repo and you're poking around the codebase, what are some things that you notice when you're looking at the code? +JOËL: Ooh, that's always fun. In a Rails application, there are a few files I almost always open first in a new project just to get a feel for it. Number one is the routes file. What does that look like? Is it huge? Is it small? Are there a lot of non-standard routes in there, not just standard RESTful resources? That's going to tell me a lot about how things are structured. I can probably even get a sense of what controllers are large, what controllers have 20 non-RESTful actions in them just by looking at the routing file. +The other place I like to look at is the user model. Generally, that just collects so many methods. And so I can also often get a feel about the app just by looking at that. And then from there, it's pulling on connections and trying to say, okay, well, what seems to be the core model of this app that everything coalesces around? And maybe for an e-commerce app, it's some kind of product, or maybe for an insurance product, it might be some kind of policy object. And so you find that, and then you find all of the core business logic around there. And that can often give you a really good picture of what the app is like. +STEPHANIE: Yeah, a few other things I would add to that list of things to check out is the Gemfile. I like to look at that to see what gems are familiar to me. Do they have authentication, common authentication gems that I've used before? Or is there a lot of stuff that's new to me? And it also kind of tells you, are they more likely to reach for a library or try to build something themselves? +I liked that you mentioned that you try to run the test suite early on. I think test coverage is a good place to investigate as well if they have any metrics, you know, that also tells you that it is or isn't something they value. And then seeing like, okay, what parts are well-tested and what parts are a little less tested? +I'm really glad that you pointed out how much information you can glean about controllers because then, once you're poking around in there, that can tell you a lot about where are the scary parts of the app? I've found that to be really interesting. You know, sometimes you can just open up a file and be like, whoa, [laughs] and have kind of a gut reaction. Other times, you might pick it up from other developers, and you might start hearing about areas of the app that they are a little nervous to touch. +JOËL: I definitely connect with that. I feel like many products have a particular file that is kind of scary and that people don't want to touch. And sometimes, people will tell you upfront, sometimes, you just discover it yourself. And I've been on projects where it's like, oh no, we have a ticket that's come up. It's fairly straightforward, except we know whoever picks it up is going to have to touch the scary file, and I'm not it. +STEPHANIE: Yeah, absolutely. +JOËL: I'm curious if you run any kind of automated tooling to try to understand a little bit more about the code. So I'm thinking things like maybe Flog or Flay or some of those tools to get a feel for maybe what are the hotspots in the application, anything like that that you like to look for? +STEPHANIE: That's a great point. I think the only times I have invested energy into doing that has been more when I'm doing a code audit for a client, which, in some cases, is a separate service that clients can pay consultants for. But I can see the value of doing it when you're joining a team for the first time. +JOËL: In a sense, I almost feel like we do a kind of abbreviated code audit for ourselves as part of onboarding. +STEPHANIE: That's fair. I wonder if you can use those tools and scope it in a way to the particular team or areas in the codebase that you know that you'll be working on. +JOËL: You mentioned the Gemfile earlier. And one thing that maybe seems super obvious is checking version numbers for things like Rails and Ruby because that will significantly impact how development is going to work. Is this a Rails 3 app, or is this a Rails 7 application? +STEPHANIE: Yeah, yeah, that's a great point. I am glad you mentioned that because I think that's probably the very first thing [laughs] that I would do just to set my expectations around what I'm working with. +JOËL: I feel like it's one of those things that's often just told to you when somebody helps you onboard. It's like, "Okay, you can clone the repo. It's over here. By the way, this is a Rails 3 app. We're kind of behind the times. Here are some weird things we've had to do to keep it alive. We have this other team. They're in this back room over there, slowly working on a Rails 4 upgrade. It's been in progress for four months, but we think we're pretty close. Can't wait for Rails 4." +STEPHANIE: Oh God. [laughs] I think the alternative is a developer being like, "Oh yeah, we just upgraded to Rails 7," and they're all really excited and feeling really good about it, [laughs] as they should be, because I think that Rails upgrades are an important thing to stay on top of. And it is really great when you are working on a project that gets to be up to date there. +JOËL: Yeah, Rails upgrades are interesting because I feel like when you're proactive about them, they're not that bad, especially more modern versions. I think Rails has gotten a lot better about making those upgrades smoother today than they were ten years ago. But when you're not up to date about them, when you've just kind of procrastinated on doing the updates, every month or year that you wait to do the update makes it so much harder to do that update when the time comes. +Because now more gems have fallen out of date, more things have now been abandoned that you just can't use. A lot of community knowledge is just not around as much anymore. Because Rails 3...I forget when Rails 4 came out, probably about ten years ago. So people who remember how things were done idiomatically ten years ago, some of that knowledge has kind of passed on. It's not as prevalent as knowledge around Rails 6 or Rails 7 is. +STEPHANIE: 100%. I think I heard someone at thoughtbot identify themselves as a post-Rails 5 generation developer. And I loved that because it really tells you a lot about just their experience. And it's kind of fun. I can imagine some kind of BuzzFeed quiz or something that's like, what Rails generation are you? But yeah, I've certainly seen pro-con lists about joining different projects, and a con might be the app is still on Rails 3. And then, if the app is on a very new version of Rails, that's usually in the pro column because folks are excited about getting to have all that good, new stuff. +What do you look out for in terms of design patterns in a codebase? Is that something that kind of sets off your radar at all? +JOËL: One thing that will definitely make me raise an eyebrow is heavy use of metaprogramming. I've been bitten by that a lot on projects. Some things are way too clever by half. So a lot of metaprogramming typically means it's going to be difficult to read and follow the flow of logic in the code. And also, there might be some unexpected bugs. Or I found once a memory leak that happened because of some weird metaprogramming. So that definitely makes me a little bit skeptical of part of the code. +STEPHANIE: Yeah, that's fair. And it also just makes it hard to understand the domain when you have no idea where things go. And you have to just find out later when you are debugging and are in the middle of desperately trying to figure out how this app works. So I can see how that is a little suspicious. I think one thing that I am reevaluating for myself when I notice design patterns is trying to figure out, do I want to perpetuate them? Do I want to follow them? And in the past, I have been more likely to just follow an existing pattern in the codebase. +But one thing that I'm hoping to do moving forward is to simply ask, how do decisions get made around patterns? Who gets to introduce them? Are they documented? What does that process look like? Do you have a conversation with the team about it? Just so that I have more tools in my toolbox, I think if I ever do find something that I feel really strongly about, that should be different than what I'm seeing in the codebase. So kind of expanding my skill set there. +JOËL: I think that's a fantastic question to ask, and I've done this on previous projects. And sometimes, the answers are just absolutely illuminating. So you see a weird pattern, and you ask, like, "Oh, where does that come from? Why do we do that?" And some will say," Oh yeah, that was Bob back in, you know, 2017. He read an article and was really a fan of this thing, and he put it everywhere. Nobody else really understood the pattern, but we haven't really been able to change it. And he's no longer with the company, and now we just kind of...it's there." +Or sometimes it's like, "Oh, great question because you see, we have this subtle business problem. And we've got to reconcile these two pieces of technology with also this expectation that our customers have. And so we came across this pattern, and we decided to use it." And it's these things where just looking at the code with no context, you're like, that's weird. Why would you want to do that? And then, when you understand the underlying problem, it makes so much sense. +It's like, okay, I don't love this pattern, but it's the correct solution here, and I fully support having that here. It's a tricky problem at the intersection of technological problems and business problems, and this was the best way we could solve it. I'm not always super happy, but it is the right choice. +STEPHANIE: Yeah, I've heard someone describe that as code archaeology in a way that all codebases have a story to tell about how they got to the current state that they're in. And I have certainly struggled with this but trying to approach joining a new team and working on a new codebase, especially if it's legacy code, from a place of curiosity rather than being combative about it. And just going through the git commits or just simply asking members of the team, like, "Hey, what's going on here?" and getting to hear some of those fun stories. +JOËL: Yeah, most code exists for a reason. It's not just people writing things just because, particularly code that, you walk in as an outsider and think, oh, that's bad code or looks weird. It's usually for a reason. People aren't just purposefully writing this to trigger you two years down the road. +It's also important...as a new person onboarding onto a project, people care about your perspective. As an outsider, oftentimes, it's really rich to bring in an outside perspective. But it's also not a great look to come in and just immediately be like, "Oh, we need to tear this thing down," or "This is so bad." It's important to build trust with the team. And as with so many things in life, seek to understand before running your mouth. +STEPHANIE: Wow, how insightful, Joël. [laughs] Speaking of building trust, can we talk a little bit about different strategies we have for doing that? +JOËL: Yeah. As a new person on the team, you really want to build a strong connection with the client and to build that trust because then you can be more effective in doing your job. You can bring more value to the client. What are some ways that you like to get that moving in a positive direction early on a new project? +STEPHANIE: I think setting up channels of communication is really important, so, ideally, having a one-on-one with a manager or a team lead because that is a great place to make sure that the work you're doing is aligned with what they think you should be doing. So figuring out what their expectations are, like, what do you expect me to get done in my first week? And then what do you want me to be doing by the first month? +That is important because we might think about all the things we would love to improve about this codebase or like influence on the team. But if that is not lined up with their views of what success looks like, then we're not quite delivering on the value that we [laughs] had hoped that we would. +Another thing that I'm starting to notice a lot more, and we talked a little bit about this previously when we talked about the value of sustainability in web development, but learning what the team's values are and also what the organization's values are because that will really inform the behavior of folks on the team and the decisions that they make. +So some values that come to mind are transparency, or collaboration, or growth, or speed. Like, if you find out those underlying foundational pillars, that can really help you orient yourself in your work and being like, okay, I know that this organization really focuses on these kinds of things, so I would like to try to make decisions that uphold or are in line with the things that are important to them. +JOËL: I want to really second your comment about good communication. That is one of the most powerful things you can do to build credibility to build trust with another human being, and that can happen in a lot of ways. Like you're saying, some of it is setting up actual communication channels with a manager. Some of that can be the things we mentioned earlier, like asking questions about the architecture, trying to learn all about the product and the business. +That can also be being active in that particular team's Slack channel. Sometimes new people come on to a team, and they're a little bit more timid, and they're just kind of not present. And so kind of coming in and...like, you don't want to take over the channel but being active in the channel, asking your questions in that channel, even just talking about your onboarding experience being like, "Hey, I'm running through...I got stuck on this thing. Here's the thing I did to get unstuck." People love seeing that. And it helps them to feel like you're actively participating from day one. +STEPHANIE: Yes, that is a great transition to what I wanted to make sure to say at the end of this is that your onboarding experience matters. I know that when you're joining a new team, you might feel a lot of pressure to start contributing and make sure that you are providing value. But your onboarding experience should be inclusive, and you should advocate for your needs. +Like, if you don't have access to credentials or there are just various blockers to your onboarding, that's a big deal, and it should not be a gatekeep-y process. Everyone wants you to be able to do your job, and so if you're running into those issues, it's definitely important to raise those concerns for yourself and also for anyone else who comes along the way. +Also, everything is new, and will probably feel uncomfortable. If you're anything like me, I feel a lot of pressure to prove myself when I join a new team and start contributing left and right. But it's just important to remember that when all this stuff is new, feeling uncertain or feeling confused and just being in that beginner's mindset again can be uncomfortable, but that is totally normal. +JOËL: I feel like something I sometimes do that ties all of these ideas together is when I'm encountering some new code or a new problem, to help myself understand it, I will diagram it. But oftentimes, it can be nice to share that diagram in the team's Slack channel and to say, "Hey, I'm new to the project, and I was exploring this area, and I kind of diagrammed it." Just talk a little bit about the thing that you're doing and maybe what you learned about it. People love that. +Visuals are a really powerful tool. And you might be surprised that there might be some team members that have been on the project for a while who never really understood that part of the code. And so they will latch on to what you've shared and be like, "Oh, thank you, because now I finally have a feel for that part." Or maybe you didn't get it quite right, and somebody will follow up and say, "Hey, I love your diagram, but you have a misconception here. There's actually a different piece that connects here." And then you can have a conversation, and you just revealed a blind spot. And so I've found that that can be a really positive way to get started. +STEPHANIE: Yeah, absolutely. Joël Quenneville, professional diagrammer. But even if you don't draw a diagram, putting your assumptions out into the world and how you understand things I think is really valuable because, yeah, it's like you are showing your learning path and also being open to receiving feedback if it's not quite right and, hopefully, spreading knowledge all around. So I love that. +JOËL: This reminds me a little bit of the episode we had with Steve Polito about learning in public. And he was focused more on learning about Rails, and open source, and things like that. But there's a sense in which you can sort of learn the product or learn the codebase. And public means your team channel. So you can say, "Hey, I'm digging into this model, and here's how I understand the way things work. It's a bulleted list of three things." You might get some good comments on that. You might get other people who appreciate it. So kind of learning the internals of a product within the public confines of a team, I think, is a really good framework as well. +STEPHANIE: Absolutely. +JOËL: On that note, Shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie raves about more software development-related zines by Julia Evans. Joël has been thinking about the mechanics of rolling dice.

+ +

Stephanie also started on a new client project that Joël has already been working on for many months. They talk about onboarding.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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 I got a very exciting package in the mail the other day that I wanted to share with you. So I think I've mentioned her on the pod before, but I got a package of software development-related zines by Julia Evans, and I'm going to share a few of the titles that I got.

+ +

So I picked up, "Oh shit, git!" [laughs] Can I swear on this podcast? I don't know. I guess we're going to find out. Or maybe we can just make the executive decision that it's fine. [laughs] I also got "Hell Yes! CSS!", "The Pocket Guide to Debugging," which I think I mentioned previously. I had seen the PDF version before, but now I have this cute, little, I don't know, six-inch book that I can carry around for all of my debugging needs. Who knows? Maybe I'll be out in the world and just need to pull it out [laughs] and debug something while I'm on the train; who's to say? And then I also picked up "HTTP: Learn Your Browser's Language!"

+ +

So I'm really excited to have these little illustrated digest-sized resources. I think they'll look really cute on my shelf next to my more intense hardcore technical books like "Design Patterns" and "Practical Object-Oriented Design in Ruby" or whatever. I'm really excited about the more creative endeavors people have done with creating educational resources about software development. In fact, I think last time when we talked about creativity and creative expression, we totally missed the world of side projects. And I've really just enjoyed when people illustrate things and make stuff a lot more accessible to a wider audience than a traditional textbook or more text-based heavy resources.

+ +

JOËL: I love when people go for a bit more of the playful or quirky when dealing with technical topics. And this is a great example. I love Julia Evans' work. But I'm also reminded of things like "Why's (poignant) Guide to Ruby," "Learn You a Haskell for Great Good!" or even...I forget the title of it. But there's a book by...I think it's Jamis Buck on mazes. And it's told in this sort of quirky style in a narrative. But it's all about maze-solving algorithms but told through the eyes of characters who are wandering through a maze, and it's just delightful.

+ +

STEPHANIE: Aww, that's so cute. I love that. I also just had the thought that these things would make great gifts for a fledgling developer or a developer in your life who, if you don't want to get them something super specialized or technical or whatever. There are so many, like you said, quirky and fun things out there that I'm sure they'll appreciate. So, Joël, what's new in your world?

+ +

JOËL: I play D&D regularly with some colleagues at thoughtbot. And recently, I got to thinking about the mechanics of rolling dice. Specifically, what dice can be rolled together? Like, can I roll multiple dice at the same time? And which one do you have to wait for the outcome of a previous roll before it makes sense to roll it?

+ +

That was really interesting to me because I think that connects to a lot of other things that we do in software, where sometimes some things are independent. You can do them at the same time. And then, other times, you have to wait for the outcome of the first thing before you can even start doing the second thing. So I think, in many ways, it's a great metaphor for the difference between parallel versus series operations.

+ +

STEPHANIE: I think it's very funny that you found a way to connect D&D to software development. I'm just imagining you rolling your die and then while you're doing that, having some revelation like the math lady meme or whatever, just thinking about, whoa, if this outcome happens, then [laughs] what happens?

+ +

I have not joined in on our company's D&D campaign, but I do like that y'all post little updates about the story in a public space for the whole company to check out. So sometimes I've been searching for some message in our company's knowledge base, and I have stumbled upon a post about the campaign so far and what happened in last night's session, you know, how all the adventurers fought the big bird, [laughs] and it is very delightful to me.

+ +

JOËL: It's a really fun way, I think to be creative. I think I enjoy the role-playing side of it a little bit more than just the mechanics of rolling dice, even though the thing I was excited to share today is rolling dice is fun. It is kind of like doing improv, where you're trying to figure out what would your character do and how do they respond to what other people say? It's fun, but it's hard.

+ +

STEPHANIE: One burning question I have is, does anyone do voices for their characters?

+ +

JOËL: Absolutely. Aji Slater, who was on a previous episode of this podcast, is part of this campaign, and their character has some really fun voices.

+ +

STEPHANIE: That's awesome. I'm really interested in joining as a guest or something. But yeah, the improv aspect of it kind of freaks me out. I bet it's a really welcoming group. And if other people are getting into it, then I can get into it too.

+ +

JOËL: Yeah, this group is very, very low-key. Most people playing, I think, are fairly new to the game. So it's very friendly, very kind of tolerant of, oh, you didn't know this rule existed, that's totally fine. We'll make it work, things like that.

+ +

STEPHANIE: Nice. So another recent development in my world is that I started a new client project, actually the same client that you've been working on for many months, Joël.

+ +

JOËL: Yes, the same client but different teams within the client. So we don't get to necessarily interact with each other day to day. But it is interesting that now we get to share knowledge about how this application works with each other.

+ +

STEPHANIE: Yeah, yeah. And I don't think we've gotten a chance to work together even in the same world like this before. So that's kind of exciting.

+ +

JOËL: How has the onboarding been for you?

+ +

STEPHANIE: So, one onboarding development that was surprisingly easy and felt good was setting up a new laptop. So the client company shipped a laptop to me to use for all of their work. And I had to set up just the laptop from scratch, so I could develop on it. And I was able to do that pretty painlessly with the help of the dotfiles that I had previously put together and all of the configurations that I had exported and uploaded to like a cloud drive.

+ +

And so I was able to have that up and running within a day with all of my favorite keyboard shortcuts, applications, all my little preferences, and that felt really good. So I'm going to pat myself on the back [laughs] for past Stephanie's efforts in making current Stephanie's life easier.

+ +

JOËL: I'm curious, do you use thoughtbot's dotfiles as the base for your development environment, or do you use something custom?

+ +

STEPHANIE: I have my own personal dotfiles that I have in a GitHub repo. But I think I did, at one point, go through thoughtbot's dotfiles for inspiration. I found that it has just a lot of extra stuff that I don't really need, but I do like that it's out there. So if any folks want a place to start with having a laptop setup configuration, you should definitely check that out. And we can link that in the show notes.

+ +

JOËL: I really like the tool rcm, which is also by thoughtbot that allows you to have a modular system of dotfiles that you can pull from a few different sources and combine together.

+ +

STEPHANIE: Oh, that's neat. I hadn't known about that one. That's cool.

+ +

JOËL: It's a suite of command-line tools that allows you to pull probably from a git repo. And it might be several, and then trying to pull them all to the right place on your machine to be executable. So, in my case, I have the thoughtbot dotfiles and then also some personal ones. And it just kind of merges them together based on some rules and creates all the dotfiles in my home directory for that.

+ +

STEPHANIE: Nice. I think the one thing that I do need to keep up on is pushing updates to the dotfiles when I make changes locally because I did have to pull in a few things that I had adjusted or made tweaks to that didn't make it to the source that I was pulling from on this new machine. This is actually my fifth MacBook that I own [laughs] just from remnants of jobs and clients' past. And one day...I keep telling myself that I'll have to return one of the older ones that I'm not using anymore, but as of now, I am an owner of five computers. [laughs]

+ +

JOËL: Just start mining Bitcoin on the idle ones.

+ +

STEPHANIE: Oh. [laughs] That's genius. I guess that's definitely a better use than them just sitting in my drawers.

+ +

JOËL: I guess you're paying for power, and that's kind of the whole point, so...

+ +

STEPHANIE: That's fair.

+ +

JOËL: What are some things that you like to do when you onboard onto a new project?

+ +

STEPHANIE: So, aside from my laptop adventures, when I joined this new project, I had a few things in mind that I wanted to achieve during this onboarding process. One of the things I think I want to get better at is understanding the business when I'm onboarding onto a new client. I think this is an area that previously I hadn't really focused on, but I'm now understanding is actually really important to being set up for success on a team.

+ +

And so, as consultants, we're dropped into a client project oftentimes when things are already moving. And they kind of clearly have some things that they were hoping we could help with. But I am hoping to also use this time to just take a bit of a step back and ask questions about, like, what is the product? And what are its core features? And who are its users? And also, what's the direction of the business? Can I get some more context on how things are right now?

+ +

We're so frequently brought in and being like, okay, like, you're going to work on this project but without the context of is the business scaling right now, or what are its struggles? We aren't quite able to make as informed decisions as we could if we had been at the company for longer and had just seen things change and had more of a feel of why we're doing what we're doing.

+ +

JOËL: I love that you're asking all those questions upfront. I feel like coming in onto a new project, and that can be as a consultant, or it could be just starting a new job, is the perfect time to just be asking all of those questions. And people, I think, appreciate when we ask those questions. Sometimes I think as consultants; we can sometimes be afraid that, oh, if we're asking these sorts of basic questions, people might think less of us.

+ +

But I think the opposite happens where because we're asking those foundational questions about the business model, about the future of the product, about how the technical architecture works, people really appreciate that we're asking those foundational questions where other people might not. So it actually helps build credibility rather than hurting credibility.

+ +

STEPHANIE: Yeah, and I think they are really important in making the right technical decision, too, because it can help inform where you spend your time refactoring or evaluating whether this shortcut is worth it to meet this deadline or if it's not because of the bigger picture and where things are headed. If anything, I've learned that being a developer really isn't just about being in the code but having as much information as possible so that there is less ambiguity and you have more clarity to make the right choices when you do have to write the code.

+ +

Another key aspect that I have become a lot more observational about, I think, is understanding the team that I'm joining, especially what their process is, how they communicate. One thing that's kind of funny about seeing a lot of different companies and how they work as consultants is they might claim to use agile, but in reality, it is a little bit different than that. And you can have that perspective as an outsider. Things like pointing an estimation is kind of all over the place in the industry. So I really like to make sure I fully understand how the team does that and what points means to them.

+ +

I think another thing that I want to do during my onboarding time this week and as I'm getting to know developers on the client side is learning about the pain points that they're feeling. And, yeah, just getting more of a feel about what's top of mind for them and where is a good space to invest my time and my energy.

+ +

Lastly, some more basic stuff is communication. Another thing about being a contractor that's challenging is that we don't normally get the full onboarding experience that full-time hires do. And so we may or may not have an onboarding mentor or a buddy and finding out, okay, who is the right person that I should be asking questions to? Or where's the right space for that? When you join new teams, are there any other things that you like to take into consideration?

+ +

JOËL: I like that you talked about understanding the team's process. One thing that I often like to do pretty early on is make some kind of small code change but then have it go through the full process of coding on my machine to deploy it in production. And so just find some small change in the code that needs to be done, and maybe it's an easy bug fix or something. But just so I can walk through all the steps and find out what the team's process is.

+ +

What are some sort of weird things that this team does that other people might not that I need to know about? Where does review happen? Is there a staging environment, unexpected ways which my change might get rejected? Things like that. So walking through the entire, I guess you could say software development lifecycle, kind of speedrunning is, I think, a really valuable exercise to do really early on a new project.

+ +

STEPHANIE: Yeah, that's a great point. Like I mentioned, I think that looks so different for every team. And I'm now learning about new tools and SaaS products that I have never seen before. And even though I have an understanding of the software development lifecycle in general, just learning those quirks is very valuable so that you can be a contributor as soon as possible.

+ +

JOËL: I like to contribute on day one, if possible, so kind of in order of...I don't want to say order of priority. But the order of things that I often do on a new project is one, clone the repo, try to run the setup script, or manually step through instructions in the README. Depending on the repo, that might be 10 minutes. That might be all of my first day.

+ +

Number two, try to run the test suite.

+ +

STEPHANIE: Yes.

+ +

JOËL: Number three is figure out what went wrong for me in step one or two, make a fix for it, commit it, and open up a PR for it, and that's my contribution. If I can do those three things on day one, I feel like that is a solid first day.

+ +

STEPHANIE: That's great. I love that. What can you do to help improve this process and make it just a little bit better for someone else? I think another good first-day task might be automating a part of that process that is currently manual and kind of annoying.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So once you've cloned the repo and you're poking around the codebase, what are some things that you notice when you're looking at the code?

+ +

JOËL: Ooh, that's always fun. In a Rails application, there are a few files I almost always open first in a new project just to get a feel for it. Number one is the routes file. What does that look like? Is it huge? Is it small? Are there a lot of non-standard routes in there, not just standard RESTful resources? That's going to tell me a lot about how things are structured. I can probably even get a sense of what controllers are large, what controllers have 20 non-RESTful actions in them just by looking at the routing file.

+ +

The other place I like to look at is the user model. Generally, that just collects so many methods. And so I can also often get a feel about the app just by looking at that. And then from there, it's pulling on connections and trying to say, okay, well, what seems to be the core model of this app that everything coalesces around? And maybe for an e-commerce app, it's some kind of product, or maybe for an insurance product, it might be some kind of policy object. And so you find that, and then you find all of the core business logic around there. And that can often give you a really good picture of what the app is like.

+ +

STEPHANIE: Yeah, a few other things I would add to that list of things to check out is the Gemfile. I like to look at that to see what gems are familiar to me. Do they have authentication, common authentication gems that I've used before? Or is there a lot of stuff that's new to me? And it also kind of tells you, are they more likely to reach for a library or try to build something themselves?

+ +

I liked that you mentioned that you try to run the test suite early on. I think test coverage is a good place to investigate as well if they have any metrics, you know, that also tells you that it is or isn't something they value. And then seeing like, okay, what parts are well-tested and what parts are a little less tested?

+ +

I'm really glad that you pointed out how much information you can glean about controllers because then, once you're poking around in there, that can tell you a lot about where are the scary parts of the app? I've found that to be really interesting. You know, sometimes you can just open up a file and be like, whoa, [laughs] and have kind of a gut reaction. Other times, you might pick it up from other developers, and you might start hearing about areas of the app that they are a little nervous to touch.

+ +

JOËL: I definitely connect with that. I feel like many products have a particular file that is kind of scary and that people don't want to touch. And sometimes, people will tell you upfront, sometimes, you just discover it yourself. And I've been on projects where it's like, oh no, we have a ticket that's come up. It's fairly straightforward, except we know whoever picks it up is going to have to touch the scary file, and I'm not it.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I'm curious if you run any kind of automated tooling to try to understand a little bit more about the code. So I'm thinking things like maybe Flog or Flay or some of those tools to get a feel for maybe what are the hotspots in the application, anything like that that you like to look for?

+ +

STEPHANIE: That's a great point. I think the only times I have invested energy into doing that has been more when I'm doing a code audit for a client, which, in some cases, is a separate service that clients can pay consultants for. But I can see the value of doing it when you're joining a team for the first time.

+ +

JOËL: In a sense, I almost feel like we do a kind of abbreviated code audit for ourselves as part of onboarding.

+ +

STEPHANIE: That's fair. I wonder if you can use those tools and scope it in a way to the particular team or areas in the codebase that you know that you'll be working on.

+ +

JOËL: You mentioned the Gemfile earlier. And one thing that maybe seems super obvious is checking version numbers for things like Rails and Ruby because that will significantly impact how development is going to work. Is this a Rails 3 app, or is this a Rails 7 application?

+ +

STEPHANIE: Yeah, yeah, that's a great point. I am glad you mentioned that because I think that's probably the very first thing [laughs] that I would do just to set my expectations around what I'm working with.

+ +

JOËL: I feel like it's one of those things that's often just told to you when somebody helps you onboard. It's like, "Okay, you can clone the repo. It's over here. By the way, this is a Rails 3 app. We're kind of behind the times. Here are some weird things we've had to do to keep it alive. We have this other team. They're in this back room over there, slowly working on a Rails 4 upgrade. It's been in progress for four months, but we think we're pretty close. Can't wait for Rails 4."

+ +

STEPHANIE: Oh God. [laughs] I think the alternative is a developer being like, "Oh yeah, we just upgraded to Rails 7," and they're all really excited and feeling really good about it, [laughs] as they should be, because I think that Rails upgrades are an important thing to stay on top of. And it is really great when you are working on a project that gets to be up to date there.

+ +

JOËL: Yeah, Rails upgrades are interesting because I feel like when you're proactive about them, they're not that bad, especially more modern versions. I think Rails has gotten a lot better about making those upgrades smoother today than they were ten years ago. But when you're not up to date about them, when you've just kind of procrastinated on doing the updates, every month or year that you wait to do the update makes it so much harder to do that update when the time comes.

+ +

Because now more gems have fallen out of date, more things have now been abandoned that you just can't use. A lot of community knowledge is just not around as much anymore. Because Rails 3...I forget when Rails 4 came out, probably about ten years ago. So people who remember how things were done idiomatically ten years ago, some of that knowledge has kind of passed on. It's not as prevalent as knowledge around Rails 6 or Rails 7 is.

+ +

STEPHANIE: 100%. I think I heard someone at thoughtbot identify themselves as a post-Rails 5 generation developer. And I loved that because it really tells you a lot about just their experience. And it's kind of fun. I can imagine some kind of BuzzFeed quiz or something that's like, what Rails generation are you? But yeah, I've certainly seen pro-con lists about joining different projects, and a con might be the app is still on Rails 3. And then, if the app is on a very new version of Rails, that's usually in the pro column because folks are excited about getting to have all that good, new stuff.

+ +

What do you look out for in terms of design patterns in a codebase? Is that something that kind of sets off your radar at all?

+ +

JOËL: One thing that will definitely make me raise an eyebrow is heavy use of metaprogramming. I've been bitten by that a lot on projects. Some things are way too clever by half. So a lot of metaprogramming typically means it's going to be difficult to read and follow the flow of logic in the code. And also, there might be some unexpected bugs. Or I found once a memory leak that happened because of some weird metaprogramming. So that definitely makes me a little bit skeptical of part of the code.

+ +

STEPHANIE: Yeah, that's fair. And it also just makes it hard to understand the domain when you have no idea where things go. And you have to just find out later when you are debugging and are in the middle of desperately trying to figure out how this app works. So I can see how that is a little suspicious. I think one thing that I am reevaluating for myself when I notice design patterns is trying to figure out, do I want to perpetuate them? Do I want to follow them? And in the past, I have been more likely to just follow an existing pattern in the codebase.

+ +

But one thing that I'm hoping to do moving forward is to simply ask, how do decisions get made around patterns? Who gets to introduce them? Are they documented? What does that process look like? Do you have a conversation with the team about it? Just so that I have more tools in my toolbox, I think if I ever do find something that I feel really strongly about, that should be different than what I'm seeing in the codebase. So kind of expanding my skill set there.

+ +

JOËL: I think that's a fantastic question to ask, and I've done this on previous projects. And sometimes, the answers are just absolutely illuminating. So you see a weird pattern, and you ask, like, "Oh, where does that come from? Why do we do that?" And some will say," Oh yeah, that was Bob back in, you know, 2017. He read an article and was really a fan of this thing, and he put it everywhere. Nobody else really understood the pattern, but we haven't really been able to change it. And he's no longer with the company, and now we just kind of...it's there."

+ +

Or sometimes it's like, "Oh, great question because you see, we have this subtle business problem. And we've got to reconcile these two pieces of technology with also this expectation that our customers have. And so we came across this pattern, and we decided to use it." And it's these things where just looking at the code with no context, you're like, that's weird. Why would you want to do that? And then, when you understand the underlying problem, it makes so much sense.

+ +

It's like, okay, I don't love this pattern, but it's the correct solution here, and I fully support having that here. It's a tricky problem at the intersection of technological problems and business problems, and this was the best way we could solve it. I'm not always super happy, but it is the right choice.

+ +

STEPHANIE: Yeah, I've heard someone describe that as code archaeology in a way that all codebases have a story to tell about how they got to the current state that they're in. And I have certainly struggled with this but trying to approach joining a new team and working on a new codebase, especially if it's legacy code, from a place of curiosity rather than being combative about it. And just going through the git commits or just simply asking members of the team, like, "Hey, what's going on here?" and getting to hear some of those fun stories.

+ +

JOËL: Yeah, most code exists for a reason. It's not just people writing things just because, particularly code that, you walk in as an outsider and think, oh, that's bad code or looks weird. It's usually for a reason. People aren't just purposefully writing this to trigger you two years down the road.

+ +

It's also important...as a new person onboarding onto a project, people care about your perspective. As an outsider, oftentimes, it's really rich to bring in an outside perspective. But it's also not a great look to come in and just immediately be like, "Oh, we need to tear this thing down," or "This is so bad." It's important to build trust with the team. And as with so many things in life, seek to understand before running your mouth.

+ +

STEPHANIE: Wow, how insightful, Joël. [laughs] Speaking of building trust, can we talk a little bit about different strategies we have for doing that?

+ +

JOËL: Yeah. As a new person on the team, you really want to build a strong connection with the client and to build that trust because then you can be more effective in doing your job. You can bring more value to the client. What are some ways that you like to get that moving in a positive direction early on a new project?

+ +

STEPHANIE: I think setting up channels of communication is really important, so, ideally, having a one-on-one with a manager or a team lead because that is a great place to make sure that the work you're doing is aligned with what they think you should be doing. So figuring out what their expectations are, like, what do you expect me to get done in my first week? And then what do you want me to be doing by the first month?

+ +

That is important because we might think about all the things we would love to improve about this codebase or like influence on the team. But if that is not lined up with their views of what success looks like, then we're not quite delivering on the value that we [laughs] had hoped that we would.

+ +

Another thing that I'm starting to notice a lot more, and we talked a little bit about this previously when we talked about the value of sustainability in web development, but learning what the team's values are and also what the organization's values are because that will really inform the behavior of folks on the team and the decisions that they make.

+ +

So some values that come to mind are transparency, or collaboration, or growth, or speed. Like, if you find out those underlying foundational pillars, that can really help you orient yourself in your work and being like, okay, I know that this organization really focuses on these kinds of things, so I would like to try to make decisions that uphold or are in line with the things that are important to them.

+ +

JOËL: I want to really second your comment about good communication. That is one of the most powerful things you can do to build credibility to build trust with another human being, and that can happen in a lot of ways. Like you're saying, some of it is setting up actual communication channels with a manager. Some of that can be the things we mentioned earlier, like asking questions about the architecture, trying to learn all about the product and the business.

+ +

That can also be being active in that particular team's Slack channel. Sometimes new people come on to a team, and they're a little bit more timid, and they're just kind of not present. And so kind of coming in and...like, you don't want to take over the channel but being active in the channel, asking your questions in that channel, even just talking about your onboarding experience being like, "Hey, I'm running through...I got stuck on this thing. Here's the thing I did to get unstuck." People love seeing that. And it helps them to feel like you're actively participating from day one.

+ +

STEPHANIE: Yes, that is a great transition to what I wanted to make sure to say at the end of this is that your onboarding experience matters. I know that when you're joining a new team, you might feel a lot of pressure to start contributing and make sure that you are providing value. But your onboarding experience should be inclusive, and you should advocate for your needs.

+ +

Like, if you don't have access to credentials or there are just various blockers to your onboarding, that's a big deal, and it should not be a gatekeep-y process. Everyone wants you to be able to do your job, and so if you're running into those issues, it's definitely important to raise those concerns for yourself and also for anyone else who comes along the way.

+ +

Also, everything is new, and will probably feel uncomfortable. If you're anything like me, I feel a lot of pressure to prove myself when I join a new team and start contributing left and right. But it's just important to remember that when all this stuff is new, feeling uncertain or feeling confused and just being in that beginner's mindset again can be uncomfortable, but that is totally normal.

+ +

JOËL: I feel like something I sometimes do that ties all of these ideas together is when I'm encountering some new code or a new problem, to help myself understand it, I will diagram it. But oftentimes, it can be nice to share that diagram in the team's Slack channel and to say, "Hey, I'm new to the project, and I was exploring this area, and I kind of diagrammed it." Just talk a little bit about the thing that you're doing and maybe what you learned about it. People love that.

+ +

Visuals are a really powerful tool. And you might be surprised that there might be some team members that have been on the project for a while who never really understood that part of the code. And so they will latch on to what you've shared and be like, "Oh, thank you, because now I finally have a feel for that part." Or maybe you didn't get it quite right, and somebody will follow up and say, "Hey, I love your diagram, but you have a misconception here. There's actually a different piece that connects here." And then you can have a conversation, and you just revealed a blind spot. And so I've found that that can be a really positive way to get started.

+ +

STEPHANIE: Yeah, absolutely. Joël Quenneville, professional diagrammer. But even if you don't draw a diagram, putting your assumptions out into the world and how you understand things I think is really valuable because, yeah, it's like you are showing your learning path and also being open to receiving feedback if it's not quite right and, hopefully, spreading knowledge all around. So I love that.

+ +

JOËL: This reminds me a little bit of the episode we had with Steve Polito about learning in public. And he was focused more on learning about Rails, and open source, and things like that. But there's a sense in which you can sort of learn the product or learn the codebase. And public means your team channel. So you can say, "Hey, I'm digging into this model, and here's how I understand the way things work. It's a bulleted list of three things." You might get some good comments on that. You might get other people who appreciate it. So kind of learning the internals of a product within the public confines of a team, I think, is a really good framework as well.

+ +

STEPHANIE: Absolutely.

+ +

JOËL: On that note, Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Stephanie raves about more software development-related zines by Julia Evans. Joël has been thinking about the mechanics of rolling dice.

+ +

Stephanie also started on a new client project that Joël has already been working on for many months. They talk about onboarding.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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 I got a very exciting package in the mail the other day that I wanted to share with you. So I think I've mentioned her on the pod before, but I got a package of software development-related zines by Julia Evans, and I'm going to share a few of the titles that I got.

+ +

So I picked up, "Oh shit, git!" [laughs] Can I swear on this podcast? I don't know. I guess we're going to find out. Or maybe we can just make the executive decision that it's fine. [laughs] I also got "Hell Yes! CSS!", "The Pocket Guide to Debugging," which I think I mentioned previously. I had seen the PDF version before, but now I have this cute, little, I don't know, six-inch book that I can carry around for all of my debugging needs. Who knows? Maybe I'll be out in the world and just need to pull it out [laughs] and debug something while I'm on the train; who's to say? And then I also picked up "HTTP: Learn Your Browser's Language!"

+ +

So I'm really excited to have these little illustrated digest-sized resources. I think they'll look really cute on my shelf next to my more intense hardcore technical books like "Design Patterns" and "Practical Object-Oriented Design in Ruby" or whatever. I'm really excited about the more creative endeavors people have done with creating educational resources about software development. In fact, I think last time when we talked about creativity and creative expression, we totally missed the world of side projects. And I've really just enjoyed when people illustrate things and make stuff a lot more accessible to a wider audience than a traditional textbook or more text-based heavy resources.

+ +

JOËL: I love when people go for a bit more of the playful or quirky when dealing with technical topics. And this is a great example. I love Julia Evans' work. But I'm also reminded of things like "Why's (poignant) Guide to Ruby," "Learn You a Haskell for Great Good!" or even...I forget the title of it. But there's a book by...I think it's Jamis Buck on mazes. And it's told in this sort of quirky style in a narrative. But it's all about maze-solving algorithms but told through the eyes of characters who are wandering through a maze, and it's just delightful.

+ +

STEPHANIE: Aww, that's so cute. I love that. I also just had the thought that these things would make great gifts for a fledgling developer or a developer in your life who, if you don't want to get them something super specialized or technical or whatever. There are so many, like you said, quirky and fun things out there that I'm sure they'll appreciate. So, Joël, what's new in your world?

+ +

JOËL: I play D&D regularly with some colleagues at thoughtbot. And recently, I got to thinking about the mechanics of rolling dice. Specifically, what dice can be rolled together? Like, can I roll multiple dice at the same time? And which one do you have to wait for the outcome of a previous roll before it makes sense to roll it?

+ +

That was really interesting to me because I think that connects to a lot of other things that we do in software, where sometimes some things are independent. You can do them at the same time. And then, other times, you have to wait for the outcome of the first thing before you can even start doing the second thing. So I think, in many ways, it's a great metaphor for the difference between parallel versus series operations.

+ +

STEPHANIE: I think it's very funny that you found a way to connect D&D to software development. I'm just imagining you rolling your die and then while you're doing that, having some revelation like the math lady meme or whatever, just thinking about, whoa, if this outcome happens, then [laughs] what happens?

+ +

I have not joined in on our company's D&D campaign, but I do like that y'all post little updates about the story in a public space for the whole company to check out. So sometimes I've been searching for some message in our company's knowledge base, and I have stumbled upon a post about the campaign so far and what happened in last night's session, you know, how all the adventurers fought the big bird, [laughs] and it is very delightful to me.

+ +

JOËL: It's a really fun way, I think to be creative. I think I enjoy the role-playing side of it a little bit more than just the mechanics of rolling dice, even though the thing I was excited to share today is rolling dice is fun. It is kind of like doing improv, where you're trying to figure out what would your character do and how do they respond to what other people say? It's fun, but it's hard.

+ +

STEPHANIE: One burning question I have is, does anyone do voices for their characters?

+ +

JOËL: Absolutely. Aji Slater, who was on a previous episode of this podcast, is part of this campaign, and their character has some really fun voices.

+ +

STEPHANIE: That's awesome. I'm really interested in joining as a guest or something. But yeah, the improv aspect of it kind of freaks me out. I bet it's a really welcoming group. And if other people are getting into it, then I can get into it too.

+ +

JOËL: Yeah, this group is very, very low-key. Most people playing, I think, are fairly new to the game. So it's very friendly, very kind of tolerant of, oh, you didn't know this rule existed, that's totally fine. We'll make it work, things like that.

+ +

STEPHANIE: Nice. So another recent development in my world is that I started a new client project, actually the same client that you've been working on for many months, Joël.

+ +

JOËL: Yes, the same client but different teams within the client. So we don't get to necessarily interact with each other day to day. But it is interesting that now we get to share knowledge about how this application works with each other.

+ +

STEPHANIE: Yeah, yeah. And I don't think we've gotten a chance to work together even in the same world like this before. So that's kind of exciting.

+ +

JOËL: How has the onboarding been for you?

+ +

STEPHANIE: So, one onboarding development that was surprisingly easy and felt good was setting up a new laptop. So the client company shipped a laptop to me to use for all of their work. And I had to set up just the laptop from scratch, so I could develop on it. And I was able to do that pretty painlessly with the help of the dotfiles that I had previously put together and all of the configurations that I had exported and uploaded to like a cloud drive.

+ +

And so I was able to have that up and running within a day with all of my favorite keyboard shortcuts, applications, all my little preferences, and that felt really good. So I'm going to pat myself on the back [laughs] for past Stephanie's efforts in making current Stephanie's life easier.

+ +

JOËL: I'm curious, do you use thoughtbot's dotfiles as the base for your development environment, or do you use something custom?

+ +

STEPHANIE: I have my own personal dotfiles that I have in a GitHub repo. But I think I did, at one point, go through thoughtbot's dotfiles for inspiration. I found that it has just a lot of extra stuff that I don't really need, but I do like that it's out there. So if any folks want a place to start with having a laptop setup configuration, you should definitely check that out. And we can link that in the show notes.

+ +

JOËL: I really like the tool rcm, which is also by thoughtbot that allows you to have a modular system of dotfiles that you can pull from a few different sources and combine together.

+ +

STEPHANIE: Oh, that's neat. I hadn't known about that one. That's cool.

+ +

JOËL: It's a suite of command-line tools that allows you to pull probably from a git repo. And it might be several, and then trying to pull them all to the right place on your machine to be executable. So, in my case, I have the thoughtbot dotfiles and then also some personal ones. And it just kind of merges them together based on some rules and creates all the dotfiles in my home directory for that.

+ +

STEPHANIE: Nice. I think the one thing that I do need to keep up on is pushing updates to the dotfiles when I make changes locally because I did have to pull in a few things that I had adjusted or made tweaks to that didn't make it to the source that I was pulling from on this new machine. This is actually my fifth MacBook that I own [laughs] just from remnants of jobs and clients' past. And one day...I keep telling myself that I'll have to return one of the older ones that I'm not using anymore, but as of now, I am an owner of five computers. [laughs]

+ +

JOËL: Just start mining Bitcoin on the idle ones.

+ +

STEPHANIE: Oh. [laughs] That's genius. I guess that's definitely a better use than them just sitting in my drawers.

+ +

JOËL: I guess you're paying for power, and that's kind of the whole point, so...

+ +

STEPHANIE: That's fair.

+ +

JOËL: What are some things that you like to do when you onboard onto a new project?

+ +

STEPHANIE: So, aside from my laptop adventures, when I joined this new project, I had a few things in mind that I wanted to achieve during this onboarding process. One of the things I think I want to get better at is understanding the business when I'm onboarding onto a new client. I think this is an area that previously I hadn't really focused on, but I'm now understanding is actually really important to being set up for success on a team.

+ +

And so, as consultants, we're dropped into a client project oftentimes when things are already moving. And they kind of clearly have some things that they were hoping we could help with. But I am hoping to also use this time to just take a bit of a step back and ask questions about, like, what is the product? And what are its core features? And who are its users? And also, what's the direction of the business? Can I get some more context on how things are right now?

+ +

We're so frequently brought in and being like, okay, like, you're going to work on this project but without the context of is the business scaling right now, or what are its struggles? We aren't quite able to make as informed decisions as we could if we had been at the company for longer and had just seen things change and had more of a feel of why we're doing what we're doing.

+ +

JOËL: I love that you're asking all those questions upfront. I feel like coming in onto a new project, and that can be as a consultant, or it could be just starting a new job, is the perfect time to just be asking all of those questions. And people, I think, appreciate when we ask those questions. Sometimes I think as consultants; we can sometimes be afraid that, oh, if we're asking these sorts of basic questions, people might think less of us.

+ +

But I think the opposite happens where because we're asking those foundational questions about the business model, about the future of the product, about how the technical architecture works, people really appreciate that we're asking those foundational questions where other people might not. So it actually helps build credibility rather than hurting credibility.

+ +

STEPHANIE: Yeah, and I think they are really important in making the right technical decision, too, because it can help inform where you spend your time refactoring or evaluating whether this shortcut is worth it to meet this deadline or if it's not because of the bigger picture and where things are headed. If anything, I've learned that being a developer really isn't just about being in the code but having as much information as possible so that there is less ambiguity and you have more clarity to make the right choices when you do have to write the code.

+ +

Another key aspect that I have become a lot more observational about, I think, is understanding the team that I'm joining, especially what their process is, how they communicate. One thing that's kind of funny about seeing a lot of different companies and how they work as consultants is they might claim to use agile, but in reality, it is a little bit different than that. And you can have that perspective as an outsider. Things like pointing an estimation is kind of all over the place in the industry. So I really like to make sure I fully understand how the team does that and what points means to them.

+ +

I think another thing that I want to do during my onboarding time this week and as I'm getting to know developers on the client side is learning about the pain points that they're feeling. And, yeah, just getting more of a feel about what's top of mind for them and where is a good space to invest my time and my energy.

+ +

Lastly, some more basic stuff is communication. Another thing about being a contractor that's challenging is that we don't normally get the full onboarding experience that full-time hires do. And so we may or may not have an onboarding mentor or a buddy and finding out, okay, who is the right person that I should be asking questions to? Or where's the right space for that? When you join new teams, are there any other things that you like to take into consideration?

+ +

JOËL: I like that you talked about understanding the team's process. One thing that I often like to do pretty early on is make some kind of small code change but then have it go through the full process of coding on my machine to deploy it in production. And so just find some small change in the code that needs to be done, and maybe it's an easy bug fix or something. But just so I can walk through all the steps and find out what the team's process is.

+ +

What are some sort of weird things that this team does that other people might not that I need to know about? Where does review happen? Is there a staging environment, unexpected ways which my change might get rejected? Things like that. So walking through the entire, I guess you could say software development lifecycle, kind of speedrunning is, I think, a really valuable exercise to do really early on a new project.

+ +

STEPHANIE: Yeah, that's a great point. Like I mentioned, I think that looks so different for every team. And I'm now learning about new tools and SaaS products that I have never seen before. And even though I have an understanding of the software development lifecycle in general, just learning those quirks is very valuable so that you can be a contributor as soon as possible.

+ +

JOËL: I like to contribute on day one, if possible, so kind of in order of...I don't want to say order of priority. But the order of things that I often do on a new project is one, clone the repo, try to run the setup script, or manually step through instructions in the README. Depending on the repo, that might be 10 minutes. That might be all of my first day.

+ +

Number two, try to run the test suite.

+ +

STEPHANIE: Yes.

+ +

JOËL: Number three is figure out what went wrong for me in step one or two, make a fix for it, commit it, and open up a PR for it, and that's my contribution. If I can do those three things on day one, I feel like that is a solid first day.

+ +

STEPHANIE: That's great. I love that. What can you do to help improve this process and make it just a little bit better for someone else? I think another good first-day task might be automating a part of that process that is currently manual and kind of annoying.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So once you've cloned the repo and you're poking around the codebase, what are some things that you notice when you're looking at the code?

+ +

JOËL: Ooh, that's always fun. In a Rails application, there are a few files I almost always open first in a new project just to get a feel for it. Number one is the routes file. What does that look like? Is it huge? Is it small? Are there a lot of non-standard routes in there, not just standard RESTful resources? That's going to tell me a lot about how things are structured. I can probably even get a sense of what controllers are large, what controllers have 20 non-RESTful actions in them just by looking at the routing file.

+ +

The other place I like to look at is the user model. Generally, that just collects so many methods. And so I can also often get a feel about the app just by looking at that. And then from there, it's pulling on connections and trying to say, okay, well, what seems to be the core model of this app that everything coalesces around? And maybe for an e-commerce app, it's some kind of product, or maybe for an insurance product, it might be some kind of policy object. And so you find that, and then you find all of the core business logic around there. And that can often give you a really good picture of what the app is like.

+ +

STEPHANIE: Yeah, a few other things I would add to that list of things to check out is the Gemfile. I like to look at that to see what gems are familiar to me. Do they have authentication, common authentication gems that I've used before? Or is there a lot of stuff that's new to me? And it also kind of tells you, are they more likely to reach for a library or try to build something themselves?

+ +

I liked that you mentioned that you try to run the test suite early on. I think test coverage is a good place to investigate as well if they have any metrics, you know, that also tells you that it is or isn't something they value. And then seeing like, okay, what parts are well-tested and what parts are a little less tested?

+ +

I'm really glad that you pointed out how much information you can glean about controllers because then, once you're poking around in there, that can tell you a lot about where are the scary parts of the app? I've found that to be really interesting. You know, sometimes you can just open up a file and be like, whoa, [laughs] and have kind of a gut reaction. Other times, you might pick it up from other developers, and you might start hearing about areas of the app that they are a little nervous to touch.

+ +

JOËL: I definitely connect with that. I feel like many products have a particular file that is kind of scary and that people don't want to touch. And sometimes, people will tell you upfront, sometimes, you just discover it yourself. And I've been on projects where it's like, oh no, we have a ticket that's come up. It's fairly straightforward, except we know whoever picks it up is going to have to touch the scary file, and I'm not it.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: I'm curious if you run any kind of automated tooling to try to understand a little bit more about the code. So I'm thinking things like maybe Flog or Flay or some of those tools to get a feel for maybe what are the hotspots in the application, anything like that that you like to look for?

+ +

STEPHANIE: That's a great point. I think the only times I have invested energy into doing that has been more when I'm doing a code audit for a client, which, in some cases, is a separate service that clients can pay consultants for. But I can see the value of doing it when you're joining a team for the first time.

+ +

JOËL: In a sense, I almost feel like we do a kind of abbreviated code audit for ourselves as part of onboarding.

+ +

STEPHANIE: That's fair. I wonder if you can use those tools and scope it in a way to the particular team or areas in the codebase that you know that you'll be working on.

+ +

JOËL: You mentioned the Gemfile earlier. And one thing that maybe seems super obvious is checking version numbers for things like Rails and Ruby because that will significantly impact how development is going to work. Is this a Rails 3 app, or is this a Rails 7 application?

+ +

STEPHANIE: Yeah, yeah, that's a great point. I am glad you mentioned that because I think that's probably the very first thing [laughs] that I would do just to set my expectations around what I'm working with.

+ +

JOËL: I feel like it's one of those things that's often just told to you when somebody helps you onboard. It's like, "Okay, you can clone the repo. It's over here. By the way, this is a Rails 3 app. We're kind of behind the times. Here are some weird things we've had to do to keep it alive. We have this other team. They're in this back room over there, slowly working on a Rails 4 upgrade. It's been in progress for four months, but we think we're pretty close. Can't wait for Rails 4."

+ +

STEPHANIE: Oh God. [laughs] I think the alternative is a developer being like, "Oh yeah, we just upgraded to Rails 7," and they're all really excited and feeling really good about it, [laughs] as they should be, because I think that Rails upgrades are an important thing to stay on top of. And it is really great when you are working on a project that gets to be up to date there.

+ +

JOËL: Yeah, Rails upgrades are interesting because I feel like when you're proactive about them, they're not that bad, especially more modern versions. I think Rails has gotten a lot better about making those upgrades smoother today than they were ten years ago. But when you're not up to date about them, when you've just kind of procrastinated on doing the updates, every month or year that you wait to do the update makes it so much harder to do that update when the time comes.

+ +

Because now more gems have fallen out of date, more things have now been abandoned that you just can't use. A lot of community knowledge is just not around as much anymore. Because Rails 3...I forget when Rails 4 came out, probably about ten years ago. So people who remember how things were done idiomatically ten years ago, some of that knowledge has kind of passed on. It's not as prevalent as knowledge around Rails 6 or Rails 7 is.

+ +

STEPHANIE: 100%. I think I heard someone at thoughtbot identify themselves as a post-Rails 5 generation developer. And I loved that because it really tells you a lot about just their experience. And it's kind of fun. I can imagine some kind of BuzzFeed quiz or something that's like, what Rails generation are you? But yeah, I've certainly seen pro-con lists about joining different projects, and a con might be the app is still on Rails 3. And then, if the app is on a very new version of Rails, that's usually in the pro column because folks are excited about getting to have all that good, new stuff.

+ +

What do you look out for in terms of design patterns in a codebase? Is that something that kind of sets off your radar at all?

+ +

JOËL: One thing that will definitely make me raise an eyebrow is heavy use of metaprogramming. I've been bitten by that a lot on projects. Some things are way too clever by half. So a lot of metaprogramming typically means it's going to be difficult to read and follow the flow of logic in the code. And also, there might be some unexpected bugs. Or I found once a memory leak that happened because of some weird metaprogramming. So that definitely makes me a little bit skeptical of part of the code.

+ +

STEPHANIE: Yeah, that's fair. And it also just makes it hard to understand the domain when you have no idea where things go. And you have to just find out later when you are debugging and are in the middle of desperately trying to figure out how this app works. So I can see how that is a little suspicious. I think one thing that I am reevaluating for myself when I notice design patterns is trying to figure out, do I want to perpetuate them? Do I want to follow them? And in the past, I have been more likely to just follow an existing pattern in the codebase.

+ +

But one thing that I'm hoping to do moving forward is to simply ask, how do decisions get made around patterns? Who gets to introduce them? Are they documented? What does that process look like? Do you have a conversation with the team about it? Just so that I have more tools in my toolbox, I think if I ever do find something that I feel really strongly about, that should be different than what I'm seeing in the codebase. So kind of expanding my skill set there.

+ +

JOËL: I think that's a fantastic question to ask, and I've done this on previous projects. And sometimes, the answers are just absolutely illuminating. So you see a weird pattern, and you ask, like, "Oh, where does that come from? Why do we do that?" And some will say," Oh yeah, that was Bob back in, you know, 2017. He read an article and was really a fan of this thing, and he put it everywhere. Nobody else really understood the pattern, but we haven't really been able to change it. And he's no longer with the company, and now we just kind of...it's there."

+ +

Or sometimes it's like, "Oh, great question because you see, we have this subtle business problem. And we've got to reconcile these two pieces of technology with also this expectation that our customers have. And so we came across this pattern, and we decided to use it." And it's these things where just looking at the code with no context, you're like, that's weird. Why would you want to do that? And then, when you understand the underlying problem, it makes so much sense.

+ +

It's like, okay, I don't love this pattern, but it's the correct solution here, and I fully support having that here. It's a tricky problem at the intersection of technological problems and business problems, and this was the best way we could solve it. I'm not always super happy, but it is the right choice.

+ +

STEPHANIE: Yeah, I've heard someone describe that as code archaeology in a way that all codebases have a story to tell about how they got to the current state that they're in. And I have certainly struggled with this but trying to approach joining a new team and working on a new codebase, especially if it's legacy code, from a place of curiosity rather than being combative about it. And just going through the git commits or just simply asking members of the team, like, "Hey, what's going on here?" and getting to hear some of those fun stories.

+ +

JOËL: Yeah, most code exists for a reason. It's not just people writing things just because, particularly code that, you walk in as an outsider and think, oh, that's bad code or looks weird. It's usually for a reason. People aren't just purposefully writing this to trigger you two years down the road.

+ +

It's also important...as a new person onboarding onto a project, people care about your perspective. As an outsider, oftentimes, it's really rich to bring in an outside perspective. But it's also not a great look to come in and just immediately be like, "Oh, we need to tear this thing down," or "This is so bad." It's important to build trust with the team. And as with so many things in life, seek to understand before running your mouth.

+ +

STEPHANIE: Wow, how insightful, Joël. [laughs] Speaking of building trust, can we talk a little bit about different strategies we have for doing that?

+ +

JOËL: Yeah. As a new person on the team, you really want to build a strong connection with the client and to build that trust because then you can be more effective in doing your job. You can bring more value to the client. What are some ways that you like to get that moving in a positive direction early on a new project?

+ +

STEPHANIE: I think setting up channels of communication is really important, so, ideally, having a one-on-one with a manager or a team lead because that is a great place to make sure that the work you're doing is aligned with what they think you should be doing. So figuring out what their expectations are, like, what do you expect me to get done in my first week? And then what do you want me to be doing by the first month?

+ +

That is important because we might think about all the things we would love to improve about this codebase or like influence on the team. But if that is not lined up with their views of what success looks like, then we're not quite delivering on the value that we [laughs] had hoped that we would.

+ +

Another thing that I'm starting to notice a lot more, and we talked a little bit about this previously when we talked about the value of sustainability in web development, but learning what the team's values are and also what the organization's values are because that will really inform the behavior of folks on the team and the decisions that they make.

+ +

So some values that come to mind are transparency, or collaboration, or growth, or speed. Like, if you find out those underlying foundational pillars, that can really help you orient yourself in your work and being like, okay, I know that this organization really focuses on these kinds of things, so I would like to try to make decisions that uphold or are in line with the things that are important to them.

+ +

JOËL: I want to really second your comment about good communication. That is one of the most powerful things you can do to build credibility to build trust with another human being, and that can happen in a lot of ways. Like you're saying, some of it is setting up actual communication channels with a manager. Some of that can be the things we mentioned earlier, like asking questions about the architecture, trying to learn all about the product and the business.

+ +

That can also be being active in that particular team's Slack channel. Sometimes new people come on to a team, and they're a little bit more timid, and they're just kind of not present. And so kind of coming in and...like, you don't want to take over the channel but being active in the channel, asking your questions in that channel, even just talking about your onboarding experience being like, "Hey, I'm running through...I got stuck on this thing. Here's the thing I did to get unstuck." People love seeing that. And it helps them to feel like you're actively participating from day one.

+ +

STEPHANIE: Yes, that is a great transition to what I wanted to make sure to say at the end of this is that your onboarding experience matters. I know that when you're joining a new team, you might feel a lot of pressure to start contributing and make sure that you are providing value. But your onboarding experience should be inclusive, and you should advocate for your needs.

+ +

Like, if you don't have access to credentials or there are just various blockers to your onboarding, that's a big deal, and it should not be a gatekeep-y process. Everyone wants you to be able to do your job, and so if you're running into those issues, it's definitely important to raise those concerns for yourself and also for anyone else who comes along the way.

+ +

Also, everything is new, and will probably feel uncomfortable. If you're anything like me, I feel a lot of pressure to prove myself when I join a new team and start contributing left and right. But it's just important to remember that when all this stuff is new, feeling uncertain or feeling confused and just being in that beginner's mindset again can be uncomfortable, but that is totally normal.

+ +

JOËL: I feel like something I sometimes do that ties all of these ideas together is when I'm encountering some new code or a new problem, to help myself understand it, I will diagram it. But oftentimes, it can be nice to share that diagram in the team's Slack channel and to say, "Hey, I'm new to the project, and I was exploring this area, and I kind of diagrammed it." Just talk a little bit about the thing that you're doing and maybe what you learned about it. People love that.

+ +

Visuals are a really powerful tool. And you might be surprised that there might be some team members that have been on the project for a while who never really understood that part of the code. And so they will latch on to what you've shared and be like, "Oh, thank you, because now I finally have a feel for that part." Or maybe you didn't get it quite right, and somebody will follow up and say, "Hey, I love your diagram, but you have a misconception here. There's actually a different piece that connects here." And then you can have a conversation, and you just revealed a blind spot. And so I've found that that can be a really positive way to get started.

+ +

STEPHANIE: Yeah, absolutely. Joël Quenneville, professional diagrammer. But even if you don't draw a diagram, putting your assumptions out into the world and how you understand things I think is really valuable because, yeah, it's like you are showing your learning path and also being open to receiving feedback if it's not quite right and, hopefully, spreading knowledge all around. So I love that.

+ +

JOËL: This reminds me a little bit of the episode we had with Steve Polito about learning in public. And he was focused more on learning about Rails, and open source, and things like that. But there's a sense in which you can sort of learn the product or learn the codebase. And public means your team channel. So you can say, "Hey, I'm digging into this model, and here's how I understand the way things work. It's a bulleted list of three things." You might get some good comments on that. You might get other people who appreciate it. So kind of learning the internals of a product within the public confines of a team, I think, is a really good framework as well.

+ +

STEPHANIE: Absolutely.

+ +

JOËL: On that note, Shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+mB9ONu5h + + ]]> + + Joël Quenneville + Stephanie Minn + + + 371: The "Fundamentals" + https://bikeshed.thoughtbot.com/371 + 3c477f6e-a21b-4d4a-af98-3a2c5d255b26 + Tue, 14 Feb 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël has been fighting autoloading in a Rails app recently, and it's been really unpleasant. Stephanie has been experimenting with how she interacts with Slack. + +What are "the fundamentals"? People often argue for the value of Computer Science classes for the jobbing programmer because we need "the fundamentals." But what are they? And does CS really provide that for us? + 36:32 + no + + + Joël has been fighting autoloading in a Rails app recently, and it's been really unpleasant. Stephanie has been experimenting with how she interacts with Slack. +What are "the fundamentals"? People often argue for the value of Computer Science classes for the jobbing programmer because we need "the fundamentals." But what are they? And does CS really provide that for us? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +RailsConf talk on autoloading (https://www.youtube.com/watch?v=57AsQrxjLEs) +Joël's RubyConf Mini talk (https://www.youtube.com/watch?v=PHMOsTK1jSE) +Stephanie's RubyConf Mini talk (https://www.youtube.com/watch?v=S-ukCrsrTNw) +Fun, Friendly Computer Science by Mercedes Bernard (https://mercedesbernard.com/speaking/fun-friendly-cs) +Achieving Fast Method Metaprogramming: Lessons from MemoWise by Jemma Issroff and Jacob Evelyn (https://www.youtube.com/watch?v=c2Pa6W_O8oo) +Episode on specialized vocabulary (https://www.bikeshed.fm/356) +Episode on what to learn (https://www.bikeshed.fm/362) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +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: I have been fighting autoloading in a Rails app recently, and it's been really unpleasant. This is an older Rails 4 application, so we don't have Zeitwerk, any of the fancy modern things. But the problem I'm encountering is that people write code that references a constant somewhere. And if that constant is not named in the conventional way so that it would load from the proper file, it will raise a NameError at runtime when you try to execute the code. +And then you want to reference that constant with a big asterisk there because if anybody else has happened to have loaded that constant correctly either by a manual require or some other method, then that constant will already be in scope, and so you don't get a NameError. So it causes a situation where you have a lot of non-deterministic failures in the code that are not easy to always reproduce either locally or even in the test suite. +STEPHANIE: That sounds really frustrating because you must be getting errors left and right that you weren't expecting and then have to deal with. I'm curious, though, because you use the word non-deterministic. But in some ways, I'm thinking that you could perhaps grep or search the codebase for places where we're requiring constants like that and perhaps even audit that. Has that been something you've thought about, or do you think that's possible at all? +JOËL: I don't think just grepping is going to be good enough because it's anytime you use a constant, and that's a class name, a module name. Things like that are probably the most common cases. If you're just referencing a constant like an array or a string, it's probably defined in the same file, so you're probably good. But if you're trying to include a module, or inherit from another class, or you want to instantiate another class somewhere, then you can run into issues if the class name or the namespacing for it doesn't line up with the file name so that when Rails tries to autoload it, it doesn't find it where it expects. +STEPHANIE: Got it. Okay, that makes more sense to me now. +JOËL: When I interviewed at thoughtbot, one of the questions that I was asked, and I don't know if that's still in our interview anymore, was, "Tell us about one of your favorite features in Ruby." And then, "If you could remove one or change one thing about the language, what would you change?" And I think the goal of that was to see if people had enough expertise in the language to both have something they really liked about it but also know the warts; what are the places that are hard to work with? +And I definitely know that I said enumerable is my favorite part of Ruby because enumerable is amazing. I feel like, at the time, I didn't have a great answer for what I would change, but I don't remember what I said. I think today, if I had to answer that question, I might say the global namespace for all constants where just because you load another file, it might change what constants are available in a way that can really lead to some surprising behavior sometimes. +STEPHANIE: It's really funny that you mentioned enumerable because I think, at this point, you've been at thoughtbot for almost a decade, and you recently gave a talk about the enumerable module. [laughs] And so it sounds like that's something that's still one of your favorite and beloved features of Ruby. So that's really fun. +I also agree that autoloading is very opaque to me, especially, like you mentioned earlier; things can be totally different depending on what Rails version you're running. And it sounds like, ideally, when it works, it works. And hopefully, someone has done the legwork of making it effective for you. But when something goes wrong, then something that you had kind of taken for granted prior becomes really hairy. +JOËL: I think for those who are interested in digging into really deep how autoloading works in Rails and how it's sort of changed over time, there was a keynote at RailsConf last year that dug into that. That is an excellent talk to listen to. +STEPHANIE: Yes, that keynote from RailsConf 2022 about how Zeitwerk was developed by Xavier Noria, Xavier with an X. I was there too. That was a really awesome keynote. And I found it really interesting because, again, it was about this whole aspect that I just took for granted and had never really thought about. And I'm glad that someone else [laughs] figured it out for me. So that was a great reference. +Speaking of conference talks, in prior episodes, we had mentioned the talks that you and I gave at RubConf Mini back in November, and the videos for those talks are out. So if you want to check out Joël's talk about enumerable or my talks about pair programming and non-violent communication, we'll link the videos of those talks in the show notes. +JOËL: Excellent. So, what's new in your world, Stephanie? +STEPHANIE: I've been experimenting with how I interact with Slack. So I used to be very distracted by Slack as someone who needs to mark everything as read in order for the little red badge to go away or for the bold channel name to become unbold. I was constantly clicking around in Slack whenever I had it open for the sake of completing that task of reading messages, even if I wasn't necessarily in a space to fully read or even had time to be spending distracted on Slack. +But naturally, I would like, oh, click on this channel because it's bold, so I've unread messages. And then I'd get sucked in and be like, oh, I totally lost like five minutes of my time [laughs] and have forgotten what I was doing prior. So I started experimenting with using Slack as an inbox instead, so more of a pull than push in terms of receiving notifications. And I think it's been working well for me. +I've also been leaning on Slack's native keyboard shortcuts instead of using a mouse to interact with the Slack client because that helps me avoid that distracted clicking or going into this channel just to see what's up, and that has also been just okay. I think their keyboard navigation is not my favorite. There are no customization options. +So at one point, the shortcut to close the thread window pane was conflicting with my 1Password keyboard shortcuts, so I had to change my 1Password situation. And whenever you have to learn keyboard shortcuts for something different and in ways that might clash with your regular muscle memory for other applications, it's kind of annoying. But that's my journey with using Slack mostly on the keyboard so far. +JOËL: What kind of impact have you seen on your focus since you've been using this workflow? +STEPHANIE: I think it's been helpful for me to tune out things that I just can't prioritize my time and energy to at the moment. So I'm also pretty decisive when it comes to muting and leaving channels. I'm not in a ton of fun, casual channels because, again, I find them a little bit distracting. If I do want to go see cute dog content, I will go into the pets channel. But it's easier for me to have that be an intentional decision that I'm making as opposed to, oh, look, there are more messages in the dog channel. [laughs] Let me go check them out now. +I think it has helped me focus my time and energy on the things that are most important to me. And the trade-off there is that I missed out on some content, but I think that I've become okay with that. And the channels that I am more subscribed to, like our dev channel that we've mentioned on the podcast before any project or team-related communications those, are top of mind for me. And when I do need a little bit of a break and do need some fun banter, I will hop into other channels for that. +JOËL: So you brought up a little bit of this idea of FOMO around Slack channels. I think there's an area where our industry at large has a lot of FOMO, and this is around the computer science degree. A lot of people that are in the industry do not have one. There are a lot of different paths that can come into becoming a developer. Some people are entirely self-taught. Some people have gone through a bootcamp. Some people have kind of transferred from other similar or not at all similar industries. So there are a lot of different journeys that people have. +But for many people, if you don't have that, there is some FOMO around, “Did I miss out on something?” And there's a word that people always kind of toss around when talking about computer science and specifically the things you might be missing out on if you don't have it, and that is the fundamentals. You might be missing out on the fundamentals or, oh, well, what if I don't know the fundamentals, then I'm faced with a problem? And I won't know what to do, or it might make me learn more slowly. Is that something that you've heard thrown around? +STEPHANIE: I agree that the word fundamentals is extremely vague. In fact, I'm just going to say it: I have no idea what most people mean when they say the fundamentals, or at least I think they could mean a lot of different things. And so when that term is used, maybe I should just be asking for clarification [laughs] because I think that we could be talking about a lot of different things. Before we get into what fundamentals of programming or computer science or whatever means to each of us, Joël, do you want to share a little bit about where you're coming from in terms of any education prior to becoming a developer? +JOËL: Sure. So I do have a CS degree. I actually learned to code before college. I read some books, did some tutorials on the internet, played around with some code on my own, had a lot of side projects, and even at some point was, freelancing a few small projects as well. But I always struggled trying to build projects larger than a certain size. I felt like they would sort of implode under the weight of their own complexity. +I definitely felt like there's got to be some underlying fundamentals that I'm missing, some theory of writing code that would explain how to structure things in a way that scales. And this is not scaling to millions of users; this is scaling beyond 100, 200 lines of code, maintainability. And so, I had really high hopes for a computer science degree. And honestly, I think I was a little bit disappointed. I learned a lot of other interesting theoretical things, but not a lot that was actually answering that underlying problem. +And I didn't really get the answers I was looking for until I started working more in the industry, doing various internships and then later on full-time jobs as well. And just over the years, that has sort of built up a lot of answers to those questions that I had. But I didn't necessarily find them in my computer science degree, so I have mixed feelings. +STEPHANIE: I had no idea that you were doing that level of coding prior to studying in college. That's really cool. Now that I'm thinking about it, I think that's the case for a lot of people. They might get a taste of coding when they're young. It was true for me. I was a young girl on the internet in the early days writing HTML and CSS on neopets.com. And that is also how I got my first taste, and kind of wanted to explore further. +So, in college, I studied journalism actually. That was where my interests were at the time. But I did take some computer science courses on the side and ended up completing it as a minor. But I'm with you that the education I got didn't quite match up with what I was expecting. In fact, I kind of struggled, I think, because there weren't a lot of more relatable applications to what I was learning, and so I was very bored and disengaged, I think. +And so when I came out of college, I didn't think I wanted to do software development, or programming, or anything like that because I didn't love taking those classes. And, I don't know, I'm going to get into my whole career history today. But I basically fell into the role of development. It was kind of like, oh, you have these coding skills; we need these coding skills. I was like, okay, I guess this is my job now. [laughs] And I think you and I are actually kind of similar in the sense that once you started doing the work, you started to see a lot of the things that you had learned previously that you could then apply. Does that sound right? +JOËL: Yes. And I think maybe more so over the years, there are some things where it's like, oh, with a five-year mark, it's like, oh, finally now I feel like I've got enough practical experience where I can start to appreciate some of these underlying things, or I'm getting into things beyond just the basics of writing a simple Rails app where I start to need some of those other concepts. And some of those it's five years, some of those are ten years. And so it's sometimes nice to have something to go back to. Although after ten years, there's only so much I remember, so sometimes it's just having a keyword that I can Google and dig into further. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So earlier, you mentioned that fundamentals is a bit of a weasel word; it means different things to different people. So I'm curious for you, what do you think of when you think of fundamentals And, maybe more specifically, from the perspective of a web developer? +STEPHANIE: Yeah, I want to caveat this by saying that I think you can learn these different skills in many different ways; that could be formal education, that could be a bootcamp, that could be self-taught. But these three categories are what I think are useful education for a web developer. +So firstly, understanding how computer systems work at the abstraction you're using and maybe even one level lower. So this is likely the programming language or framework and the tools that you're using, and I think a lot of bootcamps teach this. They want to teach you the skills you need to get a job and do that job. +The second category, I would say, is more theoretical. So the theories of computer science and math that you and I alluded to earlier as not having been super practical at the time that we learned them. I guess that's probably why they're called theories. [laughs] But I'm thinking like algorithms, data structures, and other concepts like O notation or whatever. +And then thirdly, this one, I think, doesn't get talked about enough. But there's this whole world of practical skills that we do in the industry that I don't quite think are taught in either environment, so that looks like reading code and reviewing code, especially as it relates to working in an existing application as well as writing tests and documentation, and, in general, working with other people. I think a lot of programming education focuses on the act of writing code when I think there's a lot to learn from reading code and analyzing it. And that's something that I have been thinking a lot about the more I spend doing it in my job. +JOËL: I like the way you've sort of broken these down into more relatable categories rather than just this generic idea of the fundamentals. I think when people think of the fundamentals, they're probably thinking mostly of your category two, the more theoretical underpinnings. Some of those are actually quite relevant, I think, to the day-to-day work that we do. And then some of them are very kind of abstract and maybe even to the point of mostly being relevant if you're doing research but not that interesting if you're writing code on a day to day. Does that sound about right to you? +STEPHANIE: That's fair. I revisited a series of blog posts and conference talks that my friend Mercedes Bernard gave called "Fun, Friendly Computer Science," that was aimed towards people who didn't have a formal CS background to give them a vocabulary or some exposure to computer science concepts that would be helpful in day to day programming work. And one thing that stood out to me was the idea of set theory and how working with relational databases is pretty much working with set theory, even if you don't use that vocabulary or reference those underlying concepts. +I think another aspect of these theoretical fundamentals that companies might interview people on, like algorithms or data structures, there's also a lot of talk about how those aren't part of your day-to-day jobs. And yes, knowing about them is useful, but the benefits of working in an existing programming language is that those have all been figured out for you. And you are just using those data structures and have to worry a bit less about how they are working under the hood. +That's not to say you should know nothing about them, but I think I had mentioned earlier maybe it's helpful to understand things at a lower level than what you're working with. And that can come up when you run into problems that those data structures aren't quite able to help you solve, and you need something different, or you need to be a little more creative. But I would say that almost all of the time, you have the luxury of not having to think about that. +JOËL: It's interesting you mentioned set theory because I was thinking of a set theory metaphor here, which is we have a set of things, which is what a traditional computer science degree will teach you. We have a set of things that are the quote, unquote, "fundamentals." And there's definitely an intersection between those two sets, but they don't totally overlap over each other. +And so there are some things in a computer science degree that are absolutely going to be fundamentals that you need to use and that you're going to use in your day-to-day job. You don't have to learn them through CS. You can learn them from all sorts of other sources. And then there are also some things in CS that are maybe not part of the fundamentals. +All knowledge has value. And so these things can be mental models, or they can connect to other things. But they're not necessarily fundamental to you being able to do a good job as a working developer out in the world. And again, this will vary a lot depending on the type of development that you're doing. I'm mostly thinking of web development because that's what you and I do, both front end and back end. +I want to come back to something that you mentioned earlier because I feel like when everybody thinks of the fundamentals of computer science, the first thing that comes to mind are data structures and algorithms. Those are the things that you're working on when you're doing leet code. They are the kind of things you get asked on interviews. It's the kind of thing that's kind of fun to show off to other people. And it sounds like you're saying that data structures and algorithms are actually kind of overrated; that's a hot take. +STEPHANIE: I think it's overrated if you are working in web development. Like we were talking about earlier, at that level of abstraction, you're using the tools of the language to build software that works for your users. Like, I am really not thinking all that much about how to implement a linked list or something like that. [laughs] I have my trusty hash in Ruby. I can use an array if I need to and just put my data in there, and that is perfectly fine and acceptable. And I have not really needed to do anything too fancy beyond that. +In fact, I think you and I have talked a lot on this podcast about paradigms and design patterns. And those are the things that I find really interesting and want to learn more about at this point in my career and because they're more relevant to my day-to-day work. And I think we should be interviewed on the work that we will be doing. +JOËL: I think that lines up a lot with my experience as well. I have had to implement some trees, some linked lists, and things occasionally throughout time. I think especially working in Elm, sometimes is a little bit more lower-level data structures to work with or to construct. And sometimes you might need that to know some basics around things like trees if you're operating over the DOM, which is a tree, things like that. But, again, a lot of those things are already pre-built for you. So having the 10-minute version might be good enough to get what you need to do. +I think one thing that's probably the most useful thing that I would pull out of an algorithms class is the concept of a binary search, not just literally how do I implement a binary search on an array or a linked list but the idea of it and then taking that and applying it to a very broad set of problems. And a classic one is when you're debugging, and there are all sorts of ways that your program might fail. And if you are looking at it just process of elimination, just one little thing at a time, it's going to take you forever to check every possible cause. +But if you can find a way to eliminate half of the possibilities, and that might be by putting a conditional high in your decision tree, or there are a lot of different ways you can do that, all of a sudden, it makes it much easier to narrow down your search and to find a bug. And so that is a technique that I think is just hugely valuable that you learn in an algorithms class, but that can be generalized to all sorts of problems. I'm curious, in writing in Ruby, or JavaScript, or any of the web languages that we tend to write in, have you ever had to calculate the big O of a method or function you've written? +STEPHANIE: Only in the context of performance and Rails performance. The only times I think I've ever really pulled it out is when I am seeing a database query that is O of n or worse, and then I rewrite the function to avoid that inefficiency. Otherwise, I think most functions are perfectly fine, and there's no need to really optimize for that the first time around. +Though, I am going to plug another conference talk that I watched recently from Jemma Issroff and Jacob Evelyn about their developing of a gem called MemoWise which involves memoization and caching. But they did a really cool job of deep diving into the source code of their gem to make things as efficient as possible. And that did involve investigating different O notations and stuff like that. +111 +JOËL: Yeah, I found that in practice, most performance bottlenecks on the web tend to be I/O bound rather than CPU bound. I just realized I threw out some fancy technical terms that you probably would learn in a CS degree, and that might feel confusing for those who don't have that background. So that means that your problem is slow. It's waiting on, usually, some sort of network or file system, or database, or something like that rather than waiting for processing speed. +As an aside, we've talked about the value of having specialized vocabulary and names to add to problems. So that is a value that you get out of a more formal education path is that you do learn some of those technical terms. And that can sometimes help you to build a mental model of the solutions you can apply to a problem. +STEPHANIE: I might have mentioned it in that episode, but I do think I learned best, having had to wrestle with something in my personal life and experience and then going out and seeking more information about it and learning about it. And at that point, it's much more interesting to me because I can relate it to something that is in front of me as opposed to reading a textbook and trying to imagine ways that this information would be useful. +A lot of these concepts, it's totally okay to go explore them once you need them. You're right that it is tough if you have no idea where to even begin or what to search for, or what to look for. But I don't know; I think maybe I'm just being efficient with my time this way. [laughs] +JOËL: I'd like to throw a metaphor at you that you kind of introduced earlier when you were talking about Slack and how you're trying to change from a push to a pull mode, and I think this can apply to learning as well. Any sort of push approach to learning, you're kind of pre-learning some things because you think they're going to be useful or they might power some more learning. And it's going to be good to have that sort of already there in the situation where you need it. +Then that might be going to do a four-year degree, or maybe that's just saying, this year, I want to learn a little bit of this theoretical idea to build some better understanding of the quote, unquote, "fundamentals." And that could just be sort of general continuing education that you do. But sometimes, like you said, it's just in time. You say until I encounter a problem, it's like, okay, this problem is slow. I don't know a whole lot about performance. Let me go read up about performance. +And then you get to be like, oh, the first question you ask is, is your problem I/O bound or CPU bound? What does that mean? Okay, now there are different strategies for how you deal with things and different analysis tools. And then you go and learn that at that moment rather than having learned it the summer before because you just were trying to fill out a sort of broader foundation for your knowledge. +STEPHANIE: Wow. Excellent callback. Again, only you can find multiple ways to reference something [laughs] I said earlier. I also really enjoy listening to someone who's an expert at something or particularly knowledgeable talk about something that they're excited about. And so I was thinking that I don't have as robust of a computer science education as some of my peers or coworkers, but I know that I have people to go to with my problems. +Like you, for example, you might pull out, oh, this reminds me of graph theory. [laughs] I know we've talked about dependency graphs a lot on this podcast. And, in some ways, I am absorbing that education through you. And maybe in the future, I will encounter something that reminds me of a conversation we had, and I have a starting place. So I think having people with diverse backgrounds in this field can be really valuable as well. +JOËL: I love that because that means that even in your day-to-day, there's kind of a sort of mix of push and pull that's happening. You might just be having a conversation with somebody, and they're really excited about dependency graphs, and they tell you why they're excited about it. And that's maybe a little bit more of a push because you don't immediately need it, but you're gathering some knowledge. +But then you might also be encountering a problem on a client, and then you ask in our dev channel, "Hey, I'm encountering this sort of problem. What should I do?" And somebody says, "Oh, you might want to look into calculating the big O of this function because that looks suspicious. Tell me about that." +STEPHANIE: Exactly. And now it's my turn to call back to my Slack anecdote earlier because I do think in this field, there's just an infinite amount of things to learn. And I do have to accept that I'm not going to learn everything. And I have found a way that works for me, you know, that combination of, oh, here's a problem I'm facing. +And I really need to find out what is going on in this C code so I can better understand this Ruby code I'm writing or something like that. Or people sharing different insights that they have, and I'm getting that information that way. And you said it earlier that however you receive this information or get this education, there's no one way to do it. There's no one correct way. +JOËL: And I think everybody does a mix of both, right? You've mentioned several times that you had attended a conference talk, or read a book, or read an article on a topic related to more theoretical underpinnings. And I'm pretty sure you weren't going to that talk because you had a problem that needed to be solved, and you're like, oh, if only I could get the answer, this is where I'll get it. It's probably a little bit more in preparation, saying, oh, I'm at a conference. The whole point of a conference is to get some information ahead of time. And this particular topic sounds like it would be helpful. Does that sound right? +STEPHANIE: Yeah, that is a really great way of putting it. I hadn't thought of it that way. But that also kind of checks off the box of listening to someone else explain things to me [laughs] that they've already done a lot of research on and feel excited enough to share with the world. And that is inherently more interesting to me than reading a textbook. +JOËL: Oh yeah. Textbooks are boring. We'd done a whole episode recently about where to focus our learning. So I think if listeners are interested in digging deeper into that and maybe the push versus the pull, there are a lot of great thoughts there as well. +STEPHANIE: So before we wrap up, are there any underrated quote, unquote, "fundamental" computer science topics or concepts that you think are particularly valuable to you and your work as a developer? +JOËL: I would like to plug discrete math as a topic. And I know we've talked about, oh, there are some theoretical ideas that are maybe very firmly in the theoretical realm and aren't that useful in day-to-day work, and math sounds like it would be in that branch. But discrete math is basically all the practical math that is useful to you as a developer. It's kind of a mishmash of 10 different subjects. +So it's a bit of an overview of here's an intro to Boolean algebra. Here's an intro to propositional logic. Here's an intro to predicate logic. Let's talk about set theory. Let's talk about combinatorics. Let's talk about recursive functions from a mathematical perspective. Let's talk about a little bit of graph theory. So it just touches on a bunch of these topics, and they're all generally quite useful. +I find things like Boolean algebra I use absolutely every day because writing Boolean expressions is a thing that we do all the time in our code. And you might think there's not that much to doing Boolean expressions. And you might even have picked up on some of the patterns by yourself just by doing the work long enough. But there are some really interesting laws and rules that can be applied and analysis techniques that, even in just the small portion of a course dedicated to that topic, you get a lot of value out of it. +So I would recommend either digging into some of these topics a little bit on your own, so digging a little bit into Boolean algebra, digging a little bit into set theory, or digging into discrete math as a whole, sort of looking at all the different little sections together. I think that really gives you a lot of tools to improve your day-to-day work. +STEPHANIE: That was a great sell on discrete math. And who knows? Maybe you've influenced some of our listeners to go check that out. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël has been fighting autoloading in a Rails app recently, and it's been really unpleasant. Stephanie has been experimenting with how she interacts with Slack.

+ +

What are "the fundamentals"? People often argue for the value of Computer Science classes for the jobbing programmer because we need "the fundamentals." But what are they? And does CS really provide that for us?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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: I have been fighting autoloading in a Rails app recently, and it's been really unpleasant. This is an older Rails 4 application, so we don't have Zeitwerk, any of the fancy modern things. But the problem I'm encountering is that people write code that references a constant somewhere. And if that constant is not named in the conventional way so that it would load from the proper file, it will raise a NameError at runtime when you try to execute the code.

+ +

And then you want to reference that constant with a big asterisk there because if anybody else has happened to have loaded that constant correctly either by a manual require or some other method, then that constant will already be in scope, and so you don't get a NameError. So it causes a situation where you have a lot of non-deterministic failures in the code that are not easy to always reproduce either locally or even in the test suite.

+ +

STEPHANIE: That sounds really frustrating because you must be getting errors left and right that you weren't expecting and then have to deal with. I'm curious, though, because you use the word non-deterministic. But in some ways, I'm thinking that you could perhaps grep or search the codebase for places where we're requiring constants like that and perhaps even audit that. Has that been something you've thought about, or do you think that's possible at all?

+ +

JOËL: I don't think just grepping is going to be good enough because it's anytime you use a constant, and that's a class name, a module name. Things like that are probably the most common cases. If you're just referencing a constant like an array or a string, it's probably defined in the same file, so you're probably good. But if you're trying to include a module, or inherit from another class, or you want to instantiate another class somewhere, then you can run into issues if the class name or the namespacing for it doesn't line up with the file name so that when Rails tries to autoload it, it doesn't find it where it expects.

+ +

STEPHANIE: Got it. Okay, that makes more sense to me now.

+ +

JOËL: When I interviewed at thoughtbot, one of the questions that I was asked, and I don't know if that's still in our interview anymore, was, "Tell us about one of your favorite features in Ruby." And then, "If you could remove one or change one thing about the language, what would you change?" And I think the goal of that was to see if people had enough expertise in the language to both have something they really liked about it but also know the warts; what are the places that are hard to work with?

+ +

And I definitely know that I said enumerable is my favorite part of Ruby because enumerable is amazing. I feel like, at the time, I didn't have a great answer for what I would change, but I don't remember what I said. I think today, if I had to answer that question, I might say the global namespace for all constants where just because you load another file, it might change what constants are available in a way that can really lead to some surprising behavior sometimes.

+ +

STEPHANIE: It's really funny that you mentioned enumerable because I think, at this point, you've been at thoughtbot for almost a decade, and you recently gave a talk about the enumerable module. [laughs] And so it sounds like that's something that's still one of your favorite and beloved features of Ruby. So that's really fun.

+ +

I also agree that autoloading is very opaque to me, especially, like you mentioned earlier; things can be totally different depending on what Rails version you're running. And it sounds like, ideally, when it works, it works. And hopefully, someone has done the legwork of making it effective for you. But when something goes wrong, then something that you had kind of taken for granted prior becomes really hairy.

+ +

JOËL: I think for those who are interested in digging into really deep how autoloading works in Rails and how it's sort of changed over time, there was a keynote at RailsConf last year that dug into that. That is an excellent talk to listen to.

+ +

STEPHANIE: Yes, that keynote from RailsConf 2022 about how Zeitwerk was developed by Xavier Noria, Xavier with an X. I was there too. That was a really awesome keynote. And I found it really interesting because, again, it was about this whole aspect that I just took for granted and had never really thought about. And I'm glad that someone else [laughs] figured it out for me. So that was a great reference.

+ +

Speaking of conference talks, in prior episodes, we had mentioned the talks that you and I gave at RubConf Mini back in November, and the videos for those talks are out. So if you want to check out Joël's talk about enumerable or my talks about pair programming and non-violent communication, we'll link the videos of those talks in the show notes.

+ +

JOËL: Excellent. So, what's new in your world, Stephanie?

+ +

STEPHANIE: I've been experimenting with how I interact with Slack. So I used to be very distracted by Slack as someone who needs to mark everything as read in order for the little red badge to go away or for the bold channel name to become unbold. I was constantly clicking around in Slack whenever I had it open for the sake of completing that task of reading messages, even if I wasn't necessarily in a space to fully read or even had time to be spending distracted on Slack.

+ +

But naturally, I would like, oh, click on this channel because it's bold, so I've unread messages. And then I'd get sucked in and be like, oh, I totally lost like five minutes of my time [laughs] and have forgotten what I was doing prior. So I started experimenting with using Slack as an inbox instead, so more of a pull than push in terms of receiving notifications. And I think it's been working well for me.

+ +

I've also been leaning on Slack's native keyboard shortcuts instead of using a mouse to interact with the Slack client because that helps me avoid that distracted clicking or going into this channel just to see what's up, and that has also been just okay. I think their keyboard navigation is not my favorite. There are no customization options.

+ +

So at one point, the shortcut to close the thread window pane was conflicting with my 1Password keyboard shortcuts, so I had to change my 1Password situation. And whenever you have to learn keyboard shortcuts for something different and in ways that might clash with your regular muscle memory for other applications, it's kind of annoying. But that's my journey with using Slack mostly on the keyboard so far.

+ +

JOËL: What kind of impact have you seen on your focus since you've been using this workflow?

+ +

STEPHANIE: I think it's been helpful for me to tune out things that I just can't prioritize my time and energy to at the moment. So I'm also pretty decisive when it comes to muting and leaving channels. I'm not in a ton of fun, casual channels because, again, I find them a little bit distracting. If I do want to go see cute dog content, I will go into the pets channel. But it's easier for me to have that be an intentional decision that I'm making as opposed to, oh, look, there are more messages in the dog channel. [laughs] Let me go check them out now.

+ +

I think it has helped me focus my time and energy on the things that are most important to me. And the trade-off there is that I missed out on some content, but I think that I've become okay with that. And the channels that I am more subscribed to, like our dev channel that we've mentioned on the podcast before any project or team-related communications those, are top of mind for me. And when I do need a little bit of a break and do need some fun banter, I will hop into other channels for that.

+ +

JOËL: So you brought up a little bit of this idea of FOMO around Slack channels. I think there's an area where our industry at large has a lot of FOMO, and this is around the computer science degree. A lot of people that are in the industry do not have one. There are a lot of different paths that can come into becoming a developer. Some people are entirely self-taught. Some people have gone through a bootcamp. Some people have kind of transferred from other similar or not at all similar industries. So there are a lot of different journeys that people have.

+ +

But for many people, if you don't have that, there is some FOMO around, “Did I miss out on something?” And there's a word that people always kind of toss around when talking about computer science and specifically the things you might be missing out on if you don't have it, and that is the fundamentals. You might be missing out on the fundamentals or, oh, well, what if I don't know the fundamentals, then I'm faced with a problem? And I won't know what to do, or it might make me learn more slowly. Is that something that you've heard thrown around?

+ +

STEPHANIE: I agree that the word fundamentals is extremely vague. In fact, I'm just going to say it: I have no idea what most people mean when they say the fundamentals, or at least I think they could mean a lot of different things. And so when that term is used, maybe I should just be asking for clarification [laughs] because I think that we could be talking about a lot of different things. Before we get into what fundamentals of programming or computer science or whatever means to each of us, Joël, do you want to share a little bit about where you're coming from in terms of any education prior to becoming a developer?

+ +

JOËL: Sure. So I do have a CS degree. I actually learned to code before college. I read some books, did some tutorials on the internet, played around with some code on my own, had a lot of side projects, and even at some point was, freelancing a few small projects as well. But I always struggled trying to build projects larger than a certain size. I felt like they would sort of implode under the weight of their own complexity.

+ +

I definitely felt like there's got to be some underlying fundamentals that I'm missing, some theory of writing code that would explain how to structure things in a way that scales. And this is not scaling to millions of users; this is scaling beyond 100, 200 lines of code, maintainability. And so, I had really high hopes for a computer science degree. And honestly, I think I was a little bit disappointed. I learned a lot of other interesting theoretical things, but not a lot that was actually answering that underlying problem.

+ +

And I didn't really get the answers I was looking for until I started working more in the industry, doing various internships and then later on full-time jobs as well. And just over the years, that has sort of built up a lot of answers to those questions that I had. But I didn't necessarily find them in my computer science degree, so I have mixed feelings.

+ +

STEPHANIE: I had no idea that you were doing that level of coding prior to studying in college. That's really cool. Now that I'm thinking about it, I think that's the case for a lot of people. They might get a taste of coding when they're young. It was true for me. I was a young girl on the internet in the early days writing HTML and CSS on neopets.com. And that is also how I got my first taste, and kind of wanted to explore further.

+ +

So, in college, I studied journalism actually. That was where my interests were at the time. But I did take some computer science courses on the side and ended up completing it as a minor. But I'm with you that the education I got didn't quite match up with what I was expecting. In fact, I kind of struggled, I think, because there weren't a lot of more relatable applications to what I was learning, and so I was very bored and disengaged, I think.

+ +

And so when I came out of college, I didn't think I wanted to do software development, or programming, or anything like that because I didn't love taking those classes. And, I don't know, I'm going to get into my whole career history today. But I basically fell into the role of development. It was kind of like, oh, you have these coding skills; we need these coding skills. I was like, okay, I guess this is my job now. [laughs] And I think you and I are actually kind of similar in the sense that once you started doing the work, you started to see a lot of the things that you had learned previously that you could then apply. Does that sound right?

+ +

JOËL: Yes. And I think maybe more so over the years, there are some things where it's like, oh, with a five-year mark, it's like, oh, finally now I feel like I've got enough practical experience where I can start to appreciate some of these underlying things, or I'm getting into things beyond just the basics of writing a simple Rails app where I start to need some of those other concepts. And some of those it's five years, some of those are ten years. And so it's sometimes nice to have something to go back to. Although after ten years, there's only so much I remember, so sometimes it's just having a keyword that I can Google and dig into further.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So earlier, you mentioned that fundamentals is a bit of a weasel word; it means different things to different people. So I'm curious for you, what do you think of when you think of fundamentals And, maybe more specifically, from the perspective of a web developer?

+ +

STEPHANIE: Yeah, I want to caveat this by saying that I think you can learn these different skills in many different ways; that could be formal education, that could be a bootcamp, that could be self-taught. But these three categories are what I think are useful education for a web developer.

+ +

So firstly, understanding how computer systems work at the abstraction you're using and maybe even one level lower. So this is likely the programming language or framework and the tools that you're using, and I think a lot of bootcamps teach this. They want to teach you the skills you need to get a job and do that job.

+ +

The second category, I would say, is more theoretical. So the theories of computer science and math that you and I alluded to earlier as not having been super practical at the time that we learned them. I guess that's probably why they're called theories. [laughs] But I'm thinking like algorithms, data structures, and other concepts like O notation or whatever.

+ +

And then thirdly, this one, I think, doesn't get talked about enough. But there's this whole world of practical skills that we do in the industry that I don't quite think are taught in either environment, so that looks like reading code and reviewing code, especially as it relates to working in an existing application as well as writing tests and documentation, and, in general, working with other people. I think a lot of programming education focuses on the act of writing code when I think there's a lot to learn from reading code and analyzing it. And that's something that I have been thinking a lot about the more I spend doing it in my job.

+ +

JOËL: I like the way you've sort of broken these down into more relatable categories rather than just this generic idea of the fundamentals. I think when people think of the fundamentals, they're probably thinking mostly of your category two, the more theoretical underpinnings. Some of those are actually quite relevant, I think, to the day-to-day work that we do. And then some of them are very kind of abstract and maybe even to the point of mostly being relevant if you're doing research but not that interesting if you're writing code on a day to day. Does that sound about right to you?

+ +

STEPHANIE: That's fair. I revisited a series of blog posts and conference talks that my friend Mercedes Bernard gave called "Fun, Friendly Computer Science," that was aimed towards people who didn't have a formal CS background to give them a vocabulary or some exposure to computer science concepts that would be helpful in day to day programming work. And one thing that stood out to me was the idea of set theory and how working with relational databases is pretty much working with set theory, even if you don't use that vocabulary or reference those underlying concepts.

+ +

I think another aspect of these theoretical fundamentals that companies might interview people on, like algorithms or data structures, there's also a lot of talk about how those aren't part of your day-to-day jobs. And yes, knowing about them is useful, but the benefits of working in an existing programming language is that those have all been figured out for you. And you are just using those data structures and have to worry a bit less about how they are working under the hood.

+ +

That's not to say you should know nothing about them, but I think I had mentioned earlier maybe it's helpful to understand things at a lower level than what you're working with. And that can come up when you run into problems that those data structures aren't quite able to help you solve, and you need something different, or you need to be a little more creative. But I would say that almost all of the time, you have the luxury of not having to think about that.

+ +

JOËL: It's interesting you mentioned set theory because I was thinking of a set theory metaphor here, which is we have a set of things, which is what a traditional computer science degree will teach you. We have a set of things that are the quote, unquote, "fundamentals." And there's definitely an intersection between those two sets, but they don't totally overlap over each other.

+ +

And so there are some things in a computer science degree that are absolutely going to be fundamentals that you need to use and that you're going to use in your day-to-day job. You don't have to learn them through CS. You can learn them from all sorts of other sources. And then there are also some things in CS that are maybe not part of the fundamentals.

+ +

All knowledge has value. And so these things can be mental models, or they can connect to other things. But they're not necessarily fundamental to you being able to do a good job as a working developer out in the world. And again, this will vary a lot depending on the type of development that you're doing. I'm mostly thinking of web development because that's what you and I do, both front end and back end.

+ +

I want to come back to something that you mentioned earlier because I feel like when everybody thinks of the fundamentals of computer science, the first thing that comes to mind are data structures and algorithms. Those are the things that you're working on when you're doing leet code. They are the kind of things you get asked on interviews. It's the kind of thing that's kind of fun to show off to other people. And it sounds like you're saying that data structures and algorithms are actually kind of overrated; that's a hot take.

+ +

STEPHANIE: I think it's overrated if you are working in web development. Like we were talking about earlier, at that level of abstraction, you're using the tools of the language to build software that works for your users. Like, I am really not thinking all that much about how to implement a linked list or something like that. [laughs] I have my trusty hash in Ruby. I can use an array if I need to and just put my data in there, and that is perfectly fine and acceptable. And I have not really needed to do anything too fancy beyond that.

+ +

In fact, I think you and I have talked a lot on this podcast about paradigms and design patterns. And those are the things that I find really interesting and want to learn more about at this point in my career and because they're more relevant to my day-to-day work. And I think we should be interviewed on the work that we will be doing.

+ +

JOËL: I think that lines up a lot with my experience as well. I have had to implement some trees, some linked lists, and things occasionally throughout time. I think especially working in Elm, sometimes is a little bit more lower-level data structures to work with or to construct. And sometimes you might need that to know some basics around things like trees if you're operating over the DOM, which is a tree, things like that. But, again, a lot of those things are already pre-built for you. So having the 10-minute version might be good enough to get what you need to do.

+ +

I think one thing that's probably the most useful thing that I would pull out of an algorithms class is the concept of a binary search, not just literally how do I implement a binary search on an array or a linked list but the idea of it and then taking that and applying it to a very broad set of problems. And a classic one is when you're debugging, and there are all sorts of ways that your program might fail. And if you are looking at it just process of elimination, just one little thing at a time, it's going to take you forever to check every possible cause.

+ +

But if you can find a way to eliminate half of the possibilities, and that might be by putting a conditional high in your decision tree, or there are a lot of different ways you can do that, all of a sudden, it makes it much easier to narrow down your search and to find a bug. And so that is a technique that I think is just hugely valuable that you learn in an algorithms class, but that can be generalized to all sorts of problems. I'm curious, in writing in Ruby, or JavaScript, or any of the web languages that we tend to write in, have you ever had to calculate the big O of a method or function you've written?

+ +

STEPHANIE: Only in the context of performance and Rails performance. The only times I think I've ever really pulled it out is when I am seeing a database query that is O of n or worse, and then I rewrite the function to avoid that inefficiency. Otherwise, I think most functions are perfectly fine, and there's no need to really optimize for that the first time around.

+ +

Though, I am going to plug another conference talk that I watched recently from Jemma Issroff and Jacob Evelyn about their developing of a gem called MemoWise which involves memoization and caching. But they did a really cool job of deep diving into the source code of their gem to make things as efficient as possible. And that did involve investigating different O notations and stuff like that.
+111
+JOËL: Yeah, I found that in practice, most performance bottlenecks on the web tend to be I/O bound rather than CPU bound. I just realized I threw out some fancy technical terms that you probably would learn in a CS degree, and that might feel confusing for those who don't have that background. So that means that your problem is slow. It's waiting on, usually, some sort of network or file system, or database, or something like that rather than waiting for processing speed.

+ +

As an aside, we've talked about the value of having specialized vocabulary and names to add to problems. So that is a value that you get out of a more formal education path is that you do learn some of those technical terms. And that can sometimes help you to build a mental model of the solutions you can apply to a problem.

+ +

STEPHANIE: I might have mentioned it in that episode, but I do think I learned best, having had to wrestle with something in my personal life and experience and then going out and seeking more information about it and learning about it. And at that point, it's much more interesting to me because I can relate it to something that is in front of me as opposed to reading a textbook and trying to imagine ways that this information would be useful.

+ +

A lot of these concepts, it's totally okay to go explore them once you need them. You're right that it is tough if you have no idea where to even begin or what to search for, or what to look for. But I don't know; I think maybe I'm just being efficient with my time this way. [laughs]

+ +

JOËL: I'd like to throw a metaphor at you that you kind of introduced earlier when you were talking about Slack and how you're trying to change from a push to a pull mode, and I think this can apply to learning as well. Any sort of push approach to learning, you're kind of pre-learning some things because you think they're going to be useful or they might power some more learning. And it's going to be good to have that sort of already there in the situation where you need it.

+ +

Then that might be going to do a four-year degree, or maybe that's just saying, this year, I want to learn a little bit of this theoretical idea to build some better understanding of the quote, unquote, "fundamentals." And that could just be sort of general continuing education that you do. But sometimes, like you said, it's just in time. You say until I encounter a problem, it's like, okay, this problem is slow. I don't know a whole lot about performance. Let me go read up about performance.

+ +

And then you get to be like, oh, the first question you ask is, is your problem I/O bound or CPU bound? What does that mean? Okay, now there are different strategies for how you deal with things and different analysis tools. And then you go and learn that at that moment rather than having learned it the summer before because you just were trying to fill out a sort of broader foundation for your knowledge.

+ +

STEPHANIE: Wow. Excellent callback. Again, only you can find multiple ways to reference something [laughs] I said earlier. I also really enjoy listening to someone who's an expert at something or particularly knowledgeable talk about something that they're excited about. And so I was thinking that I don't have as robust of a computer science education as some of my peers or coworkers, but I know that I have people to go to with my problems.

+ +

Like you, for example, you might pull out, oh, this reminds me of graph theory. [laughs] I know we've talked about dependency graphs a lot on this podcast. And, in some ways, I am absorbing that education through you. And maybe in the future, I will encounter something that reminds me of a conversation we had, and I have a starting place. So I think having people with diverse backgrounds in this field can be really valuable as well.

+ +

JOËL: I love that because that means that even in your day-to-day, there's kind of a sort of mix of push and pull that's happening. You might just be having a conversation with somebody, and they're really excited about dependency graphs, and they tell you why they're excited about it. And that's maybe a little bit more of a push because you don't immediately need it, but you're gathering some knowledge.

+ +

But then you might also be encountering a problem on a client, and then you ask in our dev channel, "Hey, I'm encountering this sort of problem. What should I do?" And somebody says, "Oh, you might want to look into calculating the big O of this function because that looks suspicious. Tell me about that."

+ +

STEPHANIE: Exactly. And now it's my turn to call back to my Slack anecdote earlier because I do think in this field, there's just an infinite amount of things to learn. And I do have to accept that I'm not going to learn everything. And I have found a way that works for me, you know, that combination of, oh, here's a problem I'm facing.

+ +

And I really need to find out what is going on in this C code so I can better understand this Ruby code I'm writing or something like that. Or people sharing different insights that they have, and I'm getting that information that way. And you said it earlier that however you receive this information or get this education, there's no one way to do it. There's no one correct way.

+ +

JOËL: And I think everybody does a mix of both, right? You've mentioned several times that you had attended a conference talk, or read a book, or read an article on a topic related to more theoretical underpinnings. And I'm pretty sure you weren't going to that talk because you had a problem that needed to be solved, and you're like, oh, if only I could get the answer, this is where I'll get it. It's probably a little bit more in preparation, saying, oh, I'm at a conference. The whole point of a conference is to get some information ahead of time. And this particular topic sounds like it would be helpful. Does that sound right?

+ +

STEPHANIE: Yeah, that is a really great way of putting it. I hadn't thought of it that way. But that also kind of checks off the box of listening to someone else explain things to me [laughs] that they've already done a lot of research on and feel excited enough to share with the world. And that is inherently more interesting to me than reading a textbook.

+ +

JOËL: Oh yeah. Textbooks are boring. We'd done a whole episode recently about where to focus our learning. So I think if listeners are interested in digging deeper into that and maybe the push versus the pull, there are a lot of great thoughts there as well.

+ +

STEPHANIE: So before we wrap up, are there any underrated quote, unquote, "fundamental" computer science topics or concepts that you think are particularly valuable to you and your work as a developer?

+ +

JOËL: I would like to plug discrete math as a topic. And I know we've talked about, oh, there are some theoretical ideas that are maybe very firmly in the theoretical realm and aren't that useful in day-to-day work, and math sounds like it would be in that branch. But discrete math is basically all the practical math that is useful to you as a developer. It's kind of a mishmash of 10 different subjects.

+ +

So it's a bit of an overview of here's an intro to Boolean algebra. Here's an intro to propositional logic. Here's an intro to predicate logic. Let's talk about set theory. Let's talk about combinatorics. Let's talk about recursive functions from a mathematical perspective. Let's talk about a little bit of graph theory. So it just touches on a bunch of these topics, and they're all generally quite useful.

+ +

I find things like Boolean algebra I use absolutely every day because writing Boolean expressions is a thing that we do all the time in our code. And you might think there's not that much to doing Boolean expressions. And you might even have picked up on some of the patterns by yourself just by doing the work long enough. But there are some really interesting laws and rules that can be applied and analysis techniques that, even in just the small portion of a course dedicated to that topic, you get a lot of value out of it.

+ +

So I would recommend either digging into some of these topics a little bit on your own, so digging a little bit into Boolean algebra, digging a little bit into set theory, or digging into discrete math as a whole, sort of looking at all the different little sections together. I think that really gives you a lot of tools to improve your day-to-day work.

+ +

STEPHANIE: That was a great sell on discrete math. And who knows? Maybe you've influenced some of our listeners to go check that out.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël has been fighting autoloading in a Rails app recently, and it's been really unpleasant. Stephanie has been experimenting with how she interacts with Slack.

+ +

What are "the fundamentals"? People often argue for the value of Computer Science classes for the jobbing programmer because we need "the fundamentals." But what are they? And does CS really provide that for us?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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: I have been fighting autoloading in a Rails app recently, and it's been really unpleasant. This is an older Rails 4 application, so we don't have Zeitwerk, any of the fancy modern things. But the problem I'm encountering is that people write code that references a constant somewhere. And if that constant is not named in the conventional way so that it would load from the proper file, it will raise a NameError at runtime when you try to execute the code.

+ +

And then you want to reference that constant with a big asterisk there because if anybody else has happened to have loaded that constant correctly either by a manual require or some other method, then that constant will already be in scope, and so you don't get a NameError. So it causes a situation where you have a lot of non-deterministic failures in the code that are not easy to always reproduce either locally or even in the test suite.

+ +

STEPHANIE: That sounds really frustrating because you must be getting errors left and right that you weren't expecting and then have to deal with. I'm curious, though, because you use the word non-deterministic. But in some ways, I'm thinking that you could perhaps grep or search the codebase for places where we're requiring constants like that and perhaps even audit that. Has that been something you've thought about, or do you think that's possible at all?

+ +

JOËL: I don't think just grepping is going to be good enough because it's anytime you use a constant, and that's a class name, a module name. Things like that are probably the most common cases. If you're just referencing a constant like an array or a string, it's probably defined in the same file, so you're probably good. But if you're trying to include a module, or inherit from another class, or you want to instantiate another class somewhere, then you can run into issues if the class name or the namespacing for it doesn't line up with the file name so that when Rails tries to autoload it, it doesn't find it where it expects.

+ +

STEPHANIE: Got it. Okay, that makes more sense to me now.

+ +

JOËL: When I interviewed at thoughtbot, one of the questions that I was asked, and I don't know if that's still in our interview anymore, was, "Tell us about one of your favorite features in Ruby." And then, "If you could remove one or change one thing about the language, what would you change?" And I think the goal of that was to see if people had enough expertise in the language to both have something they really liked about it but also know the warts; what are the places that are hard to work with?

+ +

And I definitely know that I said enumerable is my favorite part of Ruby because enumerable is amazing. I feel like, at the time, I didn't have a great answer for what I would change, but I don't remember what I said. I think today, if I had to answer that question, I might say the global namespace for all constants where just because you load another file, it might change what constants are available in a way that can really lead to some surprising behavior sometimes.

+ +

STEPHANIE: It's really funny that you mentioned enumerable because I think, at this point, you've been at thoughtbot for almost a decade, and you recently gave a talk about the enumerable module. [laughs] And so it sounds like that's something that's still one of your favorite and beloved features of Ruby. So that's really fun.

+ +

I also agree that autoloading is very opaque to me, especially, like you mentioned earlier; things can be totally different depending on what Rails version you're running. And it sounds like, ideally, when it works, it works. And hopefully, someone has done the legwork of making it effective for you. But when something goes wrong, then something that you had kind of taken for granted prior becomes really hairy.

+ +

JOËL: I think for those who are interested in digging into really deep how autoloading works in Rails and how it's sort of changed over time, there was a keynote at RailsConf last year that dug into that. That is an excellent talk to listen to.

+ +

STEPHANIE: Yes, that keynote from RailsConf 2022 about how Zeitwerk was developed by Xavier Noria, Xavier with an X. I was there too. That was a really awesome keynote. And I found it really interesting because, again, it was about this whole aspect that I just took for granted and had never really thought about. And I'm glad that someone else [laughs] figured it out for me. So that was a great reference.

+ +

Speaking of conference talks, in prior episodes, we had mentioned the talks that you and I gave at RubConf Mini back in November, and the videos for those talks are out. So if you want to check out Joël's talk about enumerable or my talks about pair programming and non-violent communication, we'll link the videos of those talks in the show notes.

+ +

JOËL: Excellent. So, what's new in your world, Stephanie?

+ +

STEPHANIE: I've been experimenting with how I interact with Slack. So I used to be very distracted by Slack as someone who needs to mark everything as read in order for the little red badge to go away or for the bold channel name to become unbold. I was constantly clicking around in Slack whenever I had it open for the sake of completing that task of reading messages, even if I wasn't necessarily in a space to fully read or even had time to be spending distracted on Slack.

+ +

But naturally, I would like, oh, click on this channel because it's bold, so I've unread messages. And then I'd get sucked in and be like, oh, I totally lost like five minutes of my time [laughs] and have forgotten what I was doing prior. So I started experimenting with using Slack as an inbox instead, so more of a pull than push in terms of receiving notifications. And I think it's been working well for me.

+ +

I've also been leaning on Slack's native keyboard shortcuts instead of using a mouse to interact with the Slack client because that helps me avoid that distracted clicking or going into this channel just to see what's up, and that has also been just okay. I think their keyboard navigation is not my favorite. There are no customization options.

+ +

So at one point, the shortcut to close the thread window pane was conflicting with my 1Password keyboard shortcuts, so I had to change my 1Password situation. And whenever you have to learn keyboard shortcuts for something different and in ways that might clash with your regular muscle memory for other applications, it's kind of annoying. But that's my journey with using Slack mostly on the keyboard so far.

+ +

JOËL: What kind of impact have you seen on your focus since you've been using this workflow?

+ +

STEPHANIE: I think it's been helpful for me to tune out things that I just can't prioritize my time and energy to at the moment. So I'm also pretty decisive when it comes to muting and leaving channels. I'm not in a ton of fun, casual channels because, again, I find them a little bit distracting. If I do want to go see cute dog content, I will go into the pets channel. But it's easier for me to have that be an intentional decision that I'm making as opposed to, oh, look, there are more messages in the dog channel. [laughs] Let me go check them out now.

+ +

I think it has helped me focus my time and energy on the things that are most important to me. And the trade-off there is that I missed out on some content, but I think that I've become okay with that. And the channels that I am more subscribed to, like our dev channel that we've mentioned on the podcast before any project or team-related communications those, are top of mind for me. And when I do need a little bit of a break and do need some fun banter, I will hop into other channels for that.

+ +

JOËL: So you brought up a little bit of this idea of FOMO around Slack channels. I think there's an area where our industry at large has a lot of FOMO, and this is around the computer science degree. A lot of people that are in the industry do not have one. There are a lot of different paths that can come into becoming a developer. Some people are entirely self-taught. Some people have gone through a bootcamp. Some people have kind of transferred from other similar or not at all similar industries. So there are a lot of different journeys that people have.

+ +

But for many people, if you don't have that, there is some FOMO around, “Did I miss out on something?” And there's a word that people always kind of toss around when talking about computer science and specifically the things you might be missing out on if you don't have it, and that is the fundamentals. You might be missing out on the fundamentals or, oh, well, what if I don't know the fundamentals, then I'm faced with a problem? And I won't know what to do, or it might make me learn more slowly. Is that something that you've heard thrown around?

+ +

STEPHANIE: I agree that the word fundamentals is extremely vague. In fact, I'm just going to say it: I have no idea what most people mean when they say the fundamentals, or at least I think they could mean a lot of different things. And so when that term is used, maybe I should just be asking for clarification [laughs] because I think that we could be talking about a lot of different things. Before we get into what fundamentals of programming or computer science or whatever means to each of us, Joël, do you want to share a little bit about where you're coming from in terms of any education prior to becoming a developer?

+ +

JOËL: Sure. So I do have a CS degree. I actually learned to code before college. I read some books, did some tutorials on the internet, played around with some code on my own, had a lot of side projects, and even at some point was, freelancing a few small projects as well. But I always struggled trying to build projects larger than a certain size. I felt like they would sort of implode under the weight of their own complexity.

+ +

I definitely felt like there's got to be some underlying fundamentals that I'm missing, some theory of writing code that would explain how to structure things in a way that scales. And this is not scaling to millions of users; this is scaling beyond 100, 200 lines of code, maintainability. And so, I had really high hopes for a computer science degree. And honestly, I think I was a little bit disappointed. I learned a lot of other interesting theoretical things, but not a lot that was actually answering that underlying problem.

+ +

And I didn't really get the answers I was looking for until I started working more in the industry, doing various internships and then later on full-time jobs as well. And just over the years, that has sort of built up a lot of answers to those questions that I had. But I didn't necessarily find them in my computer science degree, so I have mixed feelings.

+ +

STEPHANIE: I had no idea that you were doing that level of coding prior to studying in college. That's really cool. Now that I'm thinking about it, I think that's the case for a lot of people. They might get a taste of coding when they're young. It was true for me. I was a young girl on the internet in the early days writing HTML and CSS on neopets.com. And that is also how I got my first taste, and kind of wanted to explore further.

+ +

So, in college, I studied journalism actually. That was where my interests were at the time. But I did take some computer science courses on the side and ended up completing it as a minor. But I'm with you that the education I got didn't quite match up with what I was expecting. In fact, I kind of struggled, I think, because there weren't a lot of more relatable applications to what I was learning, and so I was very bored and disengaged, I think.

+ +

And so when I came out of college, I didn't think I wanted to do software development, or programming, or anything like that because I didn't love taking those classes. And, I don't know, I'm going to get into my whole career history today. But I basically fell into the role of development. It was kind of like, oh, you have these coding skills; we need these coding skills. I was like, okay, I guess this is my job now. [laughs] And I think you and I are actually kind of similar in the sense that once you started doing the work, you started to see a lot of the things that you had learned previously that you could then apply. Does that sound right?

+ +

JOËL: Yes. And I think maybe more so over the years, there are some things where it's like, oh, with a five-year mark, it's like, oh, finally now I feel like I've got enough practical experience where I can start to appreciate some of these underlying things, or I'm getting into things beyond just the basics of writing a simple Rails app where I start to need some of those other concepts. And some of those it's five years, some of those are ten years. And so it's sometimes nice to have something to go back to. Although after ten years, there's only so much I remember, so sometimes it's just having a keyword that I can Google and dig into further.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So earlier, you mentioned that fundamentals is a bit of a weasel word; it means different things to different people. So I'm curious for you, what do you think of when you think of fundamentals And, maybe more specifically, from the perspective of a web developer?

+ +

STEPHANIE: Yeah, I want to caveat this by saying that I think you can learn these different skills in many different ways; that could be formal education, that could be a bootcamp, that could be self-taught. But these three categories are what I think are useful education for a web developer.

+ +

So firstly, understanding how computer systems work at the abstraction you're using and maybe even one level lower. So this is likely the programming language or framework and the tools that you're using, and I think a lot of bootcamps teach this. They want to teach you the skills you need to get a job and do that job.

+ +

The second category, I would say, is more theoretical. So the theories of computer science and math that you and I alluded to earlier as not having been super practical at the time that we learned them. I guess that's probably why they're called theories. [laughs] But I'm thinking like algorithms, data structures, and other concepts like O notation or whatever.

+ +

And then thirdly, this one, I think, doesn't get talked about enough. But there's this whole world of practical skills that we do in the industry that I don't quite think are taught in either environment, so that looks like reading code and reviewing code, especially as it relates to working in an existing application as well as writing tests and documentation, and, in general, working with other people. I think a lot of programming education focuses on the act of writing code when I think there's a lot to learn from reading code and analyzing it. And that's something that I have been thinking a lot about the more I spend doing it in my job.

+ +

JOËL: I like the way you've sort of broken these down into more relatable categories rather than just this generic idea of the fundamentals. I think when people think of the fundamentals, they're probably thinking mostly of your category two, the more theoretical underpinnings. Some of those are actually quite relevant, I think, to the day-to-day work that we do. And then some of them are very kind of abstract and maybe even to the point of mostly being relevant if you're doing research but not that interesting if you're writing code on a day to day. Does that sound about right to you?

+ +

STEPHANIE: That's fair. I revisited a series of blog posts and conference talks that my friend Mercedes Bernard gave called "Fun, Friendly Computer Science," that was aimed towards people who didn't have a formal CS background to give them a vocabulary or some exposure to computer science concepts that would be helpful in day to day programming work. And one thing that stood out to me was the idea of set theory and how working with relational databases is pretty much working with set theory, even if you don't use that vocabulary or reference those underlying concepts.

+ +

I think another aspect of these theoretical fundamentals that companies might interview people on, like algorithms or data structures, there's also a lot of talk about how those aren't part of your day-to-day jobs. And yes, knowing about them is useful, but the benefits of working in an existing programming language is that those have all been figured out for you. And you are just using those data structures and have to worry a bit less about how they are working under the hood.

+ +

That's not to say you should know nothing about them, but I think I had mentioned earlier maybe it's helpful to understand things at a lower level than what you're working with. And that can come up when you run into problems that those data structures aren't quite able to help you solve, and you need something different, or you need to be a little more creative. But I would say that almost all of the time, you have the luxury of not having to think about that.

+ +

JOËL: It's interesting you mentioned set theory because I was thinking of a set theory metaphor here, which is we have a set of things, which is what a traditional computer science degree will teach you. We have a set of things that are the quote, unquote, "fundamentals." And there's definitely an intersection between those two sets, but they don't totally overlap over each other.

+ +

And so there are some things in a computer science degree that are absolutely going to be fundamentals that you need to use and that you're going to use in your day-to-day job. You don't have to learn them through CS. You can learn them from all sorts of other sources. And then there are also some things in CS that are maybe not part of the fundamentals.

+ +

All knowledge has value. And so these things can be mental models, or they can connect to other things. But they're not necessarily fundamental to you being able to do a good job as a working developer out in the world. And again, this will vary a lot depending on the type of development that you're doing. I'm mostly thinking of web development because that's what you and I do, both front end and back end.

+ +

I want to come back to something that you mentioned earlier because I feel like when everybody thinks of the fundamentals of computer science, the first thing that comes to mind are data structures and algorithms. Those are the things that you're working on when you're doing leet code. They are the kind of things you get asked on interviews. It's the kind of thing that's kind of fun to show off to other people. And it sounds like you're saying that data structures and algorithms are actually kind of overrated; that's a hot take.

+ +

STEPHANIE: I think it's overrated if you are working in web development. Like we were talking about earlier, at that level of abstraction, you're using the tools of the language to build software that works for your users. Like, I am really not thinking all that much about how to implement a linked list or something like that. [laughs] I have my trusty hash in Ruby. I can use an array if I need to and just put my data in there, and that is perfectly fine and acceptable. And I have not really needed to do anything too fancy beyond that.

+ +

In fact, I think you and I have talked a lot on this podcast about paradigms and design patterns. And those are the things that I find really interesting and want to learn more about at this point in my career and because they're more relevant to my day-to-day work. And I think we should be interviewed on the work that we will be doing.

+ +

JOËL: I think that lines up a lot with my experience as well. I have had to implement some trees, some linked lists, and things occasionally throughout time. I think especially working in Elm, sometimes is a little bit more lower-level data structures to work with or to construct. And sometimes you might need that to know some basics around things like trees if you're operating over the DOM, which is a tree, things like that. But, again, a lot of those things are already pre-built for you. So having the 10-minute version might be good enough to get what you need to do.

+ +

I think one thing that's probably the most useful thing that I would pull out of an algorithms class is the concept of a binary search, not just literally how do I implement a binary search on an array or a linked list but the idea of it and then taking that and applying it to a very broad set of problems. And a classic one is when you're debugging, and there are all sorts of ways that your program might fail. And if you are looking at it just process of elimination, just one little thing at a time, it's going to take you forever to check every possible cause.

+ +

But if you can find a way to eliminate half of the possibilities, and that might be by putting a conditional high in your decision tree, or there are a lot of different ways you can do that, all of a sudden, it makes it much easier to narrow down your search and to find a bug. And so that is a technique that I think is just hugely valuable that you learn in an algorithms class, but that can be generalized to all sorts of problems. I'm curious, in writing in Ruby, or JavaScript, or any of the web languages that we tend to write in, have you ever had to calculate the big O of a method or function you've written?

+ +

STEPHANIE: Only in the context of performance and Rails performance. The only times I think I've ever really pulled it out is when I am seeing a database query that is O of n or worse, and then I rewrite the function to avoid that inefficiency. Otherwise, I think most functions are perfectly fine, and there's no need to really optimize for that the first time around.

+ +

Though, I am going to plug another conference talk that I watched recently from Jemma Issroff and Jacob Evelyn about their developing of a gem called MemoWise which involves memoization and caching. But they did a really cool job of deep diving into the source code of their gem to make things as efficient as possible. And that did involve investigating different O notations and stuff like that.
+111
+JOËL: Yeah, I found that in practice, most performance bottlenecks on the web tend to be I/O bound rather than CPU bound. I just realized I threw out some fancy technical terms that you probably would learn in a CS degree, and that might feel confusing for those who don't have that background. So that means that your problem is slow. It's waiting on, usually, some sort of network or file system, or database, or something like that rather than waiting for processing speed.

+ +

As an aside, we've talked about the value of having specialized vocabulary and names to add to problems. So that is a value that you get out of a more formal education path is that you do learn some of those technical terms. And that can sometimes help you to build a mental model of the solutions you can apply to a problem.

+ +

STEPHANIE: I might have mentioned it in that episode, but I do think I learned best, having had to wrestle with something in my personal life and experience and then going out and seeking more information about it and learning about it. And at that point, it's much more interesting to me because I can relate it to something that is in front of me as opposed to reading a textbook and trying to imagine ways that this information would be useful.

+ +

A lot of these concepts, it's totally okay to go explore them once you need them. You're right that it is tough if you have no idea where to even begin or what to search for, or what to look for. But I don't know; I think maybe I'm just being efficient with my time this way. [laughs]

+ +

JOËL: I'd like to throw a metaphor at you that you kind of introduced earlier when you were talking about Slack and how you're trying to change from a push to a pull mode, and I think this can apply to learning as well. Any sort of push approach to learning, you're kind of pre-learning some things because you think they're going to be useful or they might power some more learning. And it's going to be good to have that sort of already there in the situation where you need it.

+ +

Then that might be going to do a four-year degree, or maybe that's just saying, this year, I want to learn a little bit of this theoretical idea to build some better understanding of the quote, unquote, "fundamentals." And that could just be sort of general continuing education that you do. But sometimes, like you said, it's just in time. You say until I encounter a problem, it's like, okay, this problem is slow. I don't know a whole lot about performance. Let me go read up about performance.

+ +

And then you get to be like, oh, the first question you ask is, is your problem I/O bound or CPU bound? What does that mean? Okay, now there are different strategies for how you deal with things and different analysis tools. And then you go and learn that at that moment rather than having learned it the summer before because you just were trying to fill out a sort of broader foundation for your knowledge.

+ +

STEPHANIE: Wow. Excellent callback. Again, only you can find multiple ways to reference something [laughs] I said earlier. I also really enjoy listening to someone who's an expert at something or particularly knowledgeable talk about something that they're excited about. And so I was thinking that I don't have as robust of a computer science education as some of my peers or coworkers, but I know that I have people to go to with my problems.

+ +

Like you, for example, you might pull out, oh, this reminds me of graph theory. [laughs] I know we've talked about dependency graphs a lot on this podcast. And, in some ways, I am absorbing that education through you. And maybe in the future, I will encounter something that reminds me of a conversation we had, and I have a starting place. So I think having people with diverse backgrounds in this field can be really valuable as well.

+ +

JOËL: I love that because that means that even in your day-to-day, there's kind of a sort of mix of push and pull that's happening. You might just be having a conversation with somebody, and they're really excited about dependency graphs, and they tell you why they're excited about it. And that's maybe a little bit more of a push because you don't immediately need it, but you're gathering some knowledge.

+ +

But then you might also be encountering a problem on a client, and then you ask in our dev channel, "Hey, I'm encountering this sort of problem. What should I do?" And somebody says, "Oh, you might want to look into calculating the big O of this function because that looks suspicious. Tell me about that."

+ +

STEPHANIE: Exactly. And now it's my turn to call back to my Slack anecdote earlier because I do think in this field, there's just an infinite amount of things to learn. And I do have to accept that I'm not going to learn everything. And I have found a way that works for me, you know, that combination of, oh, here's a problem I'm facing.

+ +

And I really need to find out what is going on in this C code so I can better understand this Ruby code I'm writing or something like that. Or people sharing different insights that they have, and I'm getting that information that way. And you said it earlier that however you receive this information or get this education, there's no one way to do it. There's no one correct way.

+ +

JOËL: And I think everybody does a mix of both, right? You've mentioned several times that you had attended a conference talk, or read a book, or read an article on a topic related to more theoretical underpinnings. And I'm pretty sure you weren't going to that talk because you had a problem that needed to be solved, and you're like, oh, if only I could get the answer, this is where I'll get it. It's probably a little bit more in preparation, saying, oh, I'm at a conference. The whole point of a conference is to get some information ahead of time. And this particular topic sounds like it would be helpful. Does that sound right?

+ +

STEPHANIE: Yeah, that is a really great way of putting it. I hadn't thought of it that way. But that also kind of checks off the box of listening to someone else explain things to me [laughs] that they've already done a lot of research on and feel excited enough to share with the world. And that is inherently more interesting to me than reading a textbook.

+ +

JOËL: Oh yeah. Textbooks are boring. We'd done a whole episode recently about where to focus our learning. So I think if listeners are interested in digging deeper into that and maybe the push versus the pull, there are a lot of great thoughts there as well.

+ +

STEPHANIE: So before we wrap up, are there any underrated quote, unquote, "fundamental" computer science topics or concepts that you think are particularly valuable to you and your work as a developer?

+ +

JOËL: I would like to plug discrete math as a topic. And I know we've talked about, oh, there are some theoretical ideas that are maybe very firmly in the theoretical realm and aren't that useful in day-to-day work, and math sounds like it would be in that branch. But discrete math is basically all the practical math that is useful to you as a developer. It's kind of a mishmash of 10 different subjects.

+ +

So it's a bit of an overview of here's an intro to Boolean algebra. Here's an intro to propositional logic. Here's an intro to predicate logic. Let's talk about set theory. Let's talk about combinatorics. Let's talk about recursive functions from a mathematical perspective. Let's talk about a little bit of graph theory. So it just touches on a bunch of these topics, and they're all generally quite useful.

+ +

I find things like Boolean algebra I use absolutely every day because writing Boolean expressions is a thing that we do all the time in our code. And you might think there's not that much to doing Boolean expressions. And you might even have picked up on some of the patterns by yourself just by doing the work long enough. But there are some really interesting laws and rules that can be applied and analysis techniques that, even in just the small portion of a course dedicated to that topic, you get a lot of value out of it.

+ +

So I would recommend either digging into some of these topics a little bit on your own, so digging a little bit into Boolean algebra, digging a little bit into set theory, or digging into discrete math as a whole, sort of looking at all the different little sections together. I think that really gives you a lot of tools to improve your day-to-day work.

+ +

STEPHANIE: That was a great sell on discrete math. And who knows? Maybe you've influenced some of our listeners to go check that out.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+aVespr8L + + ]]> + + Joël Quenneville + Stephanie Minn + + + 370: Creative Expression in Software Development + https://bikeshed.thoughtbot.com/370 + ab967964-d298-4ddf-8cfb-43f4ad492de7 + Tue, 07 Feb 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie shares that she's been taking an intro to basket weaving class at a local art studio, and it's an interesting connection to computer science. Joël eats honeycomb live on air and shares a video that former Bike Shed host Steph Viccari found from Ian Anderson. It's a parody to the tune of "All I Want For Christmas Is You," but it's all about the Ruby 3.2 release. + +In this episode, Stephanie and Joël shift away from literature and lean into art. Writing code is technical work, but in many ways, it's also aesthetic work. It's a work of art. How do you feel about expressing yourself creatively through your code? + 38:52 + no + + + Stephanie shares that she's been taking an intro to basket weaving class at a local art studio, and it's an interesting connection to computer science. Joël eats honeycomb live on air and shares a video that former Bike Shed host Steph Viccari found from Ian Anderson. It's a parody to the tune of "All I Want For Christmas Is You," but it's all about the Ruby 3.2 release. +In this episode, Stephanie and Joël shift away from literature and lean into art. Writing code is technical work, but in many ways, it's also aesthetic work. It's a work of art. How do you feel about expressing yourself creatively through your code? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Weaving, Computing, and the Jacquard Loom (https://www.scienceandindustrymuseum.org.uk/objects-and-stories/jacquard-loom) +Ian Anderson's Ruby Christmas song (https://www.instagram.com/reel/CmAxL_ZNMOa/?igshid=YmMyMTA2M2Y%3D) +Dan McKinley's Boring Technology Club slides (https://boringtechnology.club/) +Simple English Wikipedia (https://simple.wikipedia.org/wiki/Main_Page) +Geepaw Hill's Twitter thread about levels of thinking (https://twitter.com/GeePawHill/status/1565389543628480518) +Julia Evans's debugging puzzles (https://mysteries.wizardzines.com/) +Tomorrow, and Tomorrow, and Tomorrow by Gabrielle Zevin (https://bookshop.org/p/books/tomorrow-and-tomorrow-and-tomorrow-gabrielle-zevin/17502475) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +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: I'm really excited to share that I've been taking this intro to weaving class at a local art studio. I'm actually a few weeks in, and it's wrapping up soon. But one thing that I found really cool at the very first class was that the instructor mentioned that weaving was, in some ways, a predecessor or inspiration to modern computing. And he said that, and I got really excited because surely that meant that I would be good at this thing [laughs] and this craft, and then I promptly kind of forgot about it. +But I was inspired the other night to look up this history to just learn more about weaving and its connection to computer science. And I learned that, in particular, the invention of something called the Jacquard loom really led to early computing machines because, basically, weaving involves threading horizontal and vertical fibers. And the way you do it if you thread the horizontal fiber, also called the weft, over or under the vertical fibers, called the warp, you get different patterns. +And so with the Jacquard loom, this invention utilized punch cards as instructions for basically binary code, and that would tell the loom how to raise and lower those vertical threads, which would then lead to a beautiful pattern. And after that invention, this previously very laborious process became automated. And that also had a really big impact on the textile industry. And fabric became a lot more available at a much lower cost. So that was a really cool little history lesson for me. +JOËL: That is really cool. So are you saying that punch cards, as we know them from early computing, were borrowed as a concept from the weaving industry? +STEPHANIE: Yeah, that's at least what I've read. I can see now how complex weaving tapestries and patterns set the stage for more complex computations. And I don't know if I'm going to keep going down this weaving journey. I liked the intro class because it was very chill, and I got to use my hands. And I had a little bit of fun making, I don't know, like ten by 12-inch little tapestry. But yeah, I've definitely seen other more advanced weavers make really beautiful textiles and fiber arts. And it's really cool to see the application of that detail-oriented skill in different formats. +JOËL: Are you going to try to make your own punch cards? +STEPHANIE: That's an interesting evolution of this skill [laughs] for sure. I think what I really did like was the hands-on approach. And so the punch cards did make this process automated. But I personally enjoyed the switching of the threads and pulling them through and doing it with my hands instead of something that's kind of turned into automated machine work. Does that inspire you in some way? +JOËL: I think sometimes it's interesting, right? As software people, we sort of have the two urges. We work in so much automation. When we see a process, we would love to try to automate it ourselves, even if it's been done before. So, oh, could I build a small, automatic mechanical loom using punch cards? That sounds like a fun automation challenge. At the same time, so much of my daily job is automation that sometimes it's nice to kind of remove automation entirely from the picture and, like you said, just work with your hands. +STEPHANIE: That's a really interesting way to think about it. I do believe that people have different reactions to it, like you said, where they're like, "Wow, I can use my skills to do this really cool thing." On the other hand, you might also respond with, "Wow, I've done this automation code-writing work for eight hours. So now I really want to do something completely different." And I think that's the camp that I was in, at least when I first signed up for this class, just having space, like three hours a week, to sit and not look at a computer and deal with the physical realm. +JOËL: So here's the other route that I think a lot of software people take, and that is, here's a fun mechanical process that can be automated. What if we simulated it virtually? So what if I create a program where you can sort of create your own punch card, like, decide where you want to punch the holes? +And maybe these are just radio buttons or something or checkboxes in a grid on a webpage. And then, the program will output an SVG that is the thing that would have been woven if you'd used it in that pattern. And so now you can kind of play around with, like, huh, what if I punch here? What if I unpunch here? And you get all these patterns out, and you could just get to try it around. +STEPHANIE: That's fascinating. I can't believe your brain went there. [laughter] But yeah, the idea that it's not actually about the pattern itself but the holes that you make, that part being the creative process and then what comes out of it then being a bit of a surprise or just something organic that's a really interesting take too. +JOËL: Something that I find is really fun about software and things created from software is this sort of really short feedback loop in terms of trial and error. So if you were actually having a weaving machine and you made a physical punch card, and then you try something, and you realize it's not quite right, the machine weaved something you didn't quite like, now you've got to set it up again. +You probably have to start from scratch with a new punch card because you can't really unpunch holes unless maybe you can put tape over it or something. That trial-and-error feedback loop is much shorter. Whereas with a program, you just pause the simulation, punch-unpunch some holes, restart, and then you just kind of keep trying. And there's something fun about that creative exploration when you've got that really tight feedback loop. +STEPHANIE: That's fair. I think perhaps that actually might be why doing it manually, and by it, I mean weaving, gives you a little bit more room to [laughs] debug if you will, because you can see when something goes wrong. And this actually happened to me in class earlier this week where I didn't thread the fiber over instead of under. And I was like, oh, this doesn't look right. Like, that's not the look I'm going for. +And then I could kind of quickly see, oh, I missed a thread over here and unravel and do it again. Whereas what you just described, if the punch card is wrong and then you create this big piece of fabric, at that point, I'm not really sure what happens then. If someone out there is a weaving expert and knows the answer; I would be very curious to know. +JOËL: Now I kind of wish we'd had this conversation last month because, in early January, there was a game jam event that happened. It's a yearly or biyearly Historically Accurate Game Jam, and they select a theme, and then everybody has to submit a game, or a simulation, or something, an interactive program that fits with the theme. And this year's theme was the Industrial Revolution. And I feel like simulating an old automated loom with punch cards would be the perfect fit for something that's small enough that I could build it in a week without spending 10 hours a day working on it. It fits within the theme, and it's still kind of fun. +STEPHANIE: Wow, that would have been a really great idea. If there was an award for best fitting the theme, I think that would have won because then you're also tackling the history of computing. I was talking about earlier the loom obviously being...or the automated loom also really playing a big role in the Industrial Revolution. And, I don't know, maybe this is our future club, Joël, and we're going to get into video game development. [laughs] What's new in your world, Joël? +JOËL: There are two things. One is that today former Bike Shed host, Stephanie Viccari, shared a video with me from Ian Anderson. This was made last December to the tune of All I Want For Christmas Is You. But it's all about the, at that time, upcoming Ruby 3.2 release. It is amazing. The lyrics talk about the different features that are upcoming. It rhymes. It's set to meter. I am just blown away by this. And I'm just really hyped [laughs] about this video. +STEPHANIE: You sent it to me and I gave it a watch before we sat down to record, and I also loved this video. It was so fun. And I think Ruby has a bit of a tradition of releasing new versions around Christmas time. So if this became a tradition, that would be very fun, and maybe instead of singing Christmas carols, we'll be singing new Ruby version carols around the holidays. +JOËL: I feel like if Ian wants to do another one next Christmas, now that you have the precedent, it'd be a great space to try something to the tune of Last Christmas because now you can reference back last year's song. +STEPHANIE: Yeah. I might as well just go all in and create a whole Christmas album of Ruby anticipation carols. +[laughter] +JOËL: Yeah, really excited about that. Kudos to Ian. And for all of our listeners, we'll link the video on the show notes of the podcast. Go and check it out; it is worth the two and a half-minutes of your life. +STEPHANIE: Agreed. +JOËL: The other cool thing, for the past few episodes, we've been talking a lot about hexagons and how they show up in nature, and bees, and how they build their honeycombs and whether that is sort of by design or sort of just happens by nature through sort of external forces. And so this week, I went out to the store, and I bought some real honeycomb. And I'm going to try it on air. +STEPHANIE: [laughs] Oh my gosh, I didn't realize that's what was happening. [laughter] Okay, I'm ready. +JOËL: All right, I'm going to take a slice. +STEPHANIE: Wow. For research. +JOËL: For science. +STEPHANIE: Wow, that is a big bite. [laughs] +JOËL: Hmmm, it's basically crunchy honey. +STEPHANIE: So I've enjoyed honeycomb in that raw form on ice cream. I really like it on there and oatmeal and stuff like that. I think it's a little bit waxy. Like, once you get to chewing the bits at the end, that part is a bit of a less pleasant mouth-feel [laughs] in my opinion. What are you experiencing right now? +JOËL: Yeah, so like you're saying, the honey kind of dissolves away in your mouth. You had this really fun mix of textures. But then, in the end, you do end up with a ball of [laughter] beeswax in your mouth. +STEPHANIE: Oh no. +JOËL: Which I understand is completely safe to eat, so... +STEPHANIE: Yeah, that's true. +JOËL: I'm just going to eat the whole thing. +STEPHANIE: I think it's kind of like swallowing gum. [laughs] +JOËL: Which apparently does not last for seven years in your digestive system; that's a myth. +STEPHANIE: Wow, debunking myths, trying honeycomb. You're welcome, to all The Bike Shed listeners out there. Investigating the important things. +JOËL: What is interesting is that we're talking about the structural power of hexagons. I can cut a pretty thin slice of the comb, and it doesn't fall apart. It still has a lot of strength to it, which is nice because it means that the honey doesn't just go splashing everywhere. I can cut up a fairly thin slice, pick it up, it still holds the honey, put it in my mouth, and it doesn't make a mess. +STEPHANIE: The bees know what they're doing. [laughs] Cool. Would you eat raw honeycomb again? +JOËL: Well, I got a whole block, and I had one tiny slice. So, yes, I will be eating the rest of this. +STEPHANIE: [laughs] +JOËL: I don't think this will be a regular thing in my weekly groceries. But I would bring this out again for a special occasion. Or I can see this fitting nicely, like you said, on maybe certain breakfasts, even on a charcuterie board or something. +STEPHANIE: Oh yeah, that's a really good use for it. +JOËL: In some ways, it's nice because it's a way to have honey without having to have it on something else or having to eat it with a spoon. It's honey that comes with its own carrying vessel. +STEPHANIE: That's great. Yeah, like a bread bowl for soup. [laughs] +JOËL: Exactly. Bees make their own bread bowls for honey. +STEPHANIE: [laughs] +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So, for the last couple of weeks, we've been joking that this is turning into the Stephanie and Joël book club because we've been talking about a lot of articles and books. Today, I'd like to shift a little bit away from literature and lean into art. Writing code is a technical work, but in many ways, it's also an aesthetic work. It's a work of art. How do you feel about the idea of expressing yourself creatively through your code? +STEPHANIE: So this is interesting to me because it's actually quite different from what we've been talking about in recent episodes around the idea of writing sustainable code, code for other people to read. Because if you are writing code purely for creative expression and just for yourself, that will look very different than what I think folks have kind of called boring technology, which is choosing the patterns, the tools, the frameworks that are tried and true, and just kind of sticking to the things that people have solved before. +And so, in some ways, I don't know if I really get to express myself creatively in the code that I write, which I think is okay for me because I don't really consider myself someone who needs a creative outlet in my work. What about you? What thoughts do you have about this? +JOËL: I think it's interesting the way you described it. I'm almost wondering if I'm making maybe a comparison to physical architecture; maybe you almost have a sort of brutalist perspective on the things you construct. +STEPHANIE: [laughs] +JOËL: So they're functional. They're minimal. They are not always the prettiest to look at, but they're solid. Does that metaphor sound about right to you? +STEPHANIE: I feel like I have to make a pun about SOLID, the design patterns, and code. +JOËL: Ooh. +STEPHANIE: [laughs] But I think I like brutalist, I mean, the term itself. I don't know if I necessarily identify with it in terms of my work and output. But the idea that the code that I do is functional is, I think, particularly important to me as a developer. And I don't just mean, like, oh, the code works, so it's done, but functional for whatever need I'm solving and also for the people who are working with this code again in the future. +I mentioned boring technology. There's a talk that I'm kind of referencing by Dan McKinley, and you can check out his slides at boringtechnology.club. And he talks about this idea of decision-making and how that relates to writing boring or creative code. And he also references Maslow's hierarchy of needs. And so, ideally, if you're working in an existing codebase, all the low-level decisions have been made for you. And then you can kind of traverse the hierarchy and focus your creativity on the high-level problems that you're trying to solve. +So maybe you're not necessarily expressing your creativity in the syntax or whatever pattern you're using, again, because a lot of those things have been solved. But where the creativity comes from is the particular domain or business problem you have and the real-world constraints that you're faced with. And how do you figure out what to do given those constraints? +JOËL: I think that lines up a lot with my own experience as well. I think as a newer developer, syntax is sort of the thing that's top of mind. And so, maybe trying to get clever with syntax is something that I would focus on more. Sometimes that's trying to get code really short and terse. Sometimes it's because I want to try. Can I do this thing with a particular piece of syntax, or even just does it look pretty? +I think now, in my code, I am actually kind of boring with my syntax. I, probably when I write Ruby, mostly use a kind of slimmed-down set of syntax and don't use the full expressive power of the language for most of my day-to-day needs. So basic things with objects, and methods, and blocks, sort of the basic building blocks that we get from Ruby regular conditionals, if...else, and a few other nice things that the language gives us. But, in many ways, it almost feels like...I don't know if you've ever seen the simplified English Wikipedia. +STEPHANIE: No, I haven't. What is that? +JOËL: They're treating it, I think, like a separate language, but it is a version of Wikipedia in English with a more restricted vocabulary to try to make the content more accessible to those that might struggle with more standard English. So it's a sort of smaller subset of English. And, in many ways, I feel like a lot of the day-to-day Ruby code that I write is simplified, Ruby. +STEPHANIE: Wow, that's really interesting. I think this also goes back to the specialized vocabulary episode we talked about. And is there value in keeping things accessible, and straightforward, and boring but at the cost of being able to express yourself with everything you have available to you? This is a bit of a tangent, I guess, but I grew up speaking Chinese with my parents, but since then, I have really lost a lot of that vocabulary. +And, in some ways, I really struggle with communicating in Chinese because I feel like I'm not able to express myself exactly the way I want to in the way that I can in English. And when I'm talking to my parents, yeah, that's been a bit of a challenge for me because I do really value being able to say things the way that I mean, and I'm not able to have that with my limited vocabulary. So I can also see how people might not enjoy working within these confines of boring syntax and boring frameworks. +JOËL: Sometimes it's nice to give yourself a sort of syntactical restriction, but they're very low-level when it comes to most of what we do for programming. And I think that's sort of what I've learned as my career has evolved is that programming is so much more than just learning syntax. So kind of like with art, maybe it's nice to restrict yourself to say, oh, can I do something with only a particular brushstroke technique, or restricting myself to a particular palette or a particular medium? And that can foster a lot of creativity. So, similarly, I think you could do some things like playing Code Golf, not on production code; please don't. +STEPHANIE: [laughs] +JOËL: But as an experiment in a side project or just almost as a piece of art, that can be a really interesting problem to solve and give you a deeper understanding of the language. And I'm sure there are plenty of other syntactical limitations you could put on yourself or maybe fancy things you would like to explore and say, "Well, this is over the top. We don't need to structure it in this way or use this syntax. But I want to sort of push the boundaries of what can be done with it. Let's see where I can take it." +STEPHANIE: That's really fair. And I think it relates back to what I was saying earlier about perhaps creativity when writing software products comes from the constraints of the business of, in some ways, physical aspects of development. In the Dan McKinley talk, I mentioned about choosing boring technology. He generally recommends against bringing in a new language or framework because of the costs, the carrying cost of doing that, and the long-term maintenance to consider. +But he instead suggests turning the question on its head and being like, how can we solve this problem with the current technology that we do have? And I think that relates to what you were saying about being able to push the boundaries of a particular medium or tool and in a way that you might not have considered before. +JOËL: Exactly. And I think going back to the analogy with art; sometimes it is nice to restrict yourself to a particular brushstroke or something like that to try to foster creativity. But oftentimes, you want to explore creativity in much higher-level ways. So maybe you're not restricting things like brushstrokes and color, and, instead, you want to explore lighting. You want to explore maybe certain ways of mixing colors. +There are all sorts of, I think, higher-level ways that you can be creative in art that's not just the mechanics of how you apply pigment to canvas. And we see the same thing like you were saying, in code where there's a lot of higher level business problems. Generally, how do we want to structure large chunks of the code? How do we want to build abstractions? Although that can also be a dangerous place to get too creative in. +STEPHANIE: Yeah, absolutely. Do you consider yourself a creative person or need a creative outlet? And how does writing code or software development play a role in that for you? +JOËL: I would say, yes, I consider myself a creative person. And I would consider coding, in general, to be a creative endeavor. I sometimes describe to people that writing code is like building something out of infinite legos. You're constrained only by the power of your imagination and the amount of time you're willing to put into constructing the thing that you're building. +Of course, then you have all sorts of business constraints. And there are things you want to do on a work project that are probably not the same as what you would want to do on a client project or on a personal project. But there's still creativity, I think, at every level and sometimes even outside of the code itself. Just understanding and breaking down the business problem can require a ton of creativity before you even write a single line of code in your editor. +I was reading a Twitter thread the other day by @GeePawHill that sort of proposes that there are sort of four steps in evolution of kind of the mindset that programmers go through over their career. And I'd be curious to hear your thoughts on this evolution if you kind of agree with it or disagree with it if that maybe lines up with some of your experience. +So this Twitter thread proposes four levels of thinking that we go through. I think we can kind of jump between these levels at various points in our work. So we might do all of these in a day, but to a certain extent, they also follow a little bit of a progression in our career. So the first level is thinking in terms of syntax; that's just knowing the characters to type in the editor. +The second level is thinking in terms of code, that's, thinking a little bit more semantically. So now, instead of thinking, oh, do I need if then curly brace, then closed curly brace? Now we're thinking more in terms of, okay, I need a branch in the flow of control for my logic here. And at that level, maybe you don't even need to think about the syntax quite so much because you're so comfortable with. It kind of just fades away. +Building beyond that, now you're thinking in terms of your paradigm. So Ruby is an object-oriented language, so you might be thinking in terms of what objects do I need to represent this problem and how do they need to talk to each other? And the sort of underlying semantics of, oh, do I need a conditional here or not? Those might start fading away because now you're thinking at a slightly higher level. +And then, finally, thinking in terms of change sets. Now you're thinking less in terms of the language itself and more in terms of the business problems and how the current behavior of the software is different and needs to change to get to where we want the behavior to be. +STEPHANIE: I think I disagree a little bit with the idea that it's a progression. And I'm thinking about how when you have a beginner's mind, anything is possible. And in some ways, if you are new to coding, before you have that understanding of what is and isn't possible, anything is possible. And so, in some ways, I've worked with people who are super new to coding, and the ideas that they come up with for how to make a change at that highest level that you were just describing, in some ways, make sense. +You can be like, oh yeah, that actually is something we can do and an idea that you might eventually get to from someone more experienced, having followed those different levels of progression and reaching a place where you're like, I know exactly what tools or the details about how to do this. But when you have that beginner's mind, and you don't have the details of the how, I think you can still think about those problems at a higher level, and that is valuable, and maybe they'll need help implementing along the way. +And I think that that could be a really interesting area of collaboration that perhaps we don't do enough in this industry because it's very mentorship-focused where it's like, okay, I have more experience, and so I'm going to teach you what I know. Whereas if you bring someone with a totally fresh perspective along, what ideas can you generate from there? +JOËL: I think we definitely exist in all of these layers every day as developers. I think, looking back at myself as a newer developer, I tended to maybe work bottom-up when I tried to solve a problem. And I think that now I probably tend to work sort of in the reverse order, start by thinking in terms of changes and then work my way down. And so syntax, at that point, is the last thing that I'm thinking about. It's really an implementation detail. Whereas I think as a new coder, syntax was super important. Was your experience similar to that, or did you have a very different journey? +STEPHANIE: It's funny that you mentioned it because I think when I was new to development, there were so many syntactic things that I didn't understand that I just kind of like blurted out of my brain when I was reading code and was then trying to latch on to the important pieces of information that I needed to know, which often meant class names or method names. Pieces that I could grab onto and be like, okay, I'm seeing that this method then calls this other method or whatever. +And, yeah, what you were saying about implementation details falling away, I kind of did that at the beginning of my career a little bit, at least at that syntactic level. So, yeah, I think I'm with you where we all exist at different parts of this framework, I suppose. And that journey could look different for everyone. +JOËL: So we're talking about ways to be creative at higher levels. And one way that I find has been really fun for me but also really useful has been bringing in dependency graphs as a tool for design. You knew I had to mention dependency graphs. +STEPHANIE: We got there in the end. [laughter] Cool, go on. +JOËL: I think it's been really good sometimes in terms of modeling change sets because dependency graphs can be a great tool for that, but also sometimes in terms of trying to understand what the underlying business problem is and how it might translate into code structures where things might be tightly coupled versus not. And so, drawing it out visually is a really powerful design tool. +And because now I can look at it in two-dimensional space, I can realize, oh, I see something that feels like it's maybe an anti-pattern or might be a problem here. There's a cycle in my graph; maybe we should find a way to break that. Maybe we need to introduce some dependency inversion and break that cycle, and now our graph is acyclic. +And so I think that's where there can be a lot of creativity that happens, even when you're not writing code at that point. You're just sort of talking about how different pieces of the project or even different subproblems...you're not even talking about if they're implemented in code, but just saying this subproblem is related to this subproblem, and maybe I would like to find a way for them to not have a connection to each other. +STEPHANIE: I'm glad we got back to this dependency graph topic because I stumbled upon something that I'm curious to hear your opinion on. I have been following Julia Evans' work for a little bit now. And she recently released a new zine about debugging. And at the end of the zine, she includes a link to these choose-your-own adventure puzzles that she has created, specifically to teach you about debugging and how to do it. +And so it's basically a little detective game, and you kind of follow along with this bug. And she gives you some different options about how would you like to find a little bit more information about this bug? And what approach would you take? And you make some different selections, and then as you go, you get more information about the bug. And that helps inform what next steps you might take. +And, one, I think this is a great example of a creative project about software development, even though it's not necessarily your day-to-day work. But then she also uses a tool called Twine, which is for creating non-linear stories, or puzzles, or games. And it got me really thinking about the multi-step wizard we've been talking about and this idea of looking at a problem in different mediums. +It also reminds me of if you have a designer on your team and they're doing prototyping, they usually have some kind of user interactivity that they have to codify. And they are making those decisions about okay, like, if you are at this step, then where do you go next? And those are all things that you've talked about doing as a developer, I think, at a later point in the future lifecycle. And I'm now just kind of thinking about how to integrate some of that into our workflow. Do you have any thoughts about that? +JOËL: I had one of the coolest experiences in my career when I was doing a front-end project where we were building a typeahead component that was pulling data from a remote server and then populating a drop-down. And the designer and I sat down and just started to look through all the different states that you could be and how you could move from one to another. +So it looked like maybe you start the typeahead is empty; it's just a text box. And then as you start typing, maybe there's a spinner that shows up. And then maybe you have some results, or maybe you don't have results. And those are two different entirely states that you could be in. And then, if you backspace, what happens? And what if something goes wrong on the server? Like, we just kept finding all these edge cases. +And we built out a diagram of all the possible journeys that someone could take, starting from that empty text box, all the way to either some sort of error state or a final state where you've selected an item. But, of course, these are not necessarily terminal because in an error state, maybe you can just start typing again, and you sort of jump back into the beginning of the flow. +So we did this whole diagram that ended up looking very much like a finite-state machine. We didn't use the term, but that's kind of what it ended up being. And I think we both learned a lot about the problem we were trying to solve and the user experience we were trying to create through that. +There was just a lot of back and forth of, like, oh, did you think about what would happen if we get no results here? Have we thought about that state? Or it's like, okay, so now we're in an error state. What do we do? Is there a way to get out of it, or are we just kind of stuck? Oh, you can backspace. Okay, what happens then? +STEPHANIE: Yeah, I mean, we've been talking about creativity as a solitary process. But I think that that goes to show that when collaborating with other people, too, that process can also be very fun and creative and fulfill that need outside of the way the code is written. +JOËL: In many ways, I think working with somebody else, and that gets made at the intersection of two or more people's work, is probably the most creative way to build software. +STEPHANIE: That actually reminds me of a book I read last year called "Tomorrow, and Tomorrow, and Tomorrow." And it's about these two friends and their journey creating video games together. And it kind of follows several decades of their life and their relationship, and their creative and collaborative process. And I really loved that book. It was very good, especially if you like video games. There are a lot of great references to that too. +But I think what you were saying about that fulfillment that you can get with working with other people, and that book does a really good job examining that and getting into our need as humans for that type of collaboration. So that's my little book rec. It goes back to our conversation about designing a game. Again, maybe this is [laughs] what we'll do next. Who knows? The world's our oyster. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie shares that she's been taking an intro to basket weaving class at a local art studio, and it's an interesting connection to computer science. Joël eats honeycomb live on air and shares a video that former Bike Shed host Steph Viccari found from Ian Anderson. It's a parody to the tune of "All I Want For Christmas Is You," but it's all about the Ruby 3.2 release.

+ +

In this episode, Stephanie and Joël shift away from literature and lean into art. Writing code is technical work, but in many ways, it's also aesthetic work. It's a work of art. How do you feel about expressing yourself creatively through your code?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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: I'm really excited to share that I've been taking this intro to weaving class at a local art studio. I'm actually a few weeks in, and it's wrapping up soon. But one thing that I found really cool at the very first class was that the instructor mentioned that weaving was, in some ways, a predecessor or inspiration to modern computing. And he said that, and I got really excited because surely that meant that I would be good at this thing [laughs] and this craft, and then I promptly kind of forgot about it.

+ +

But I was inspired the other night to look up this history to just learn more about weaving and its connection to computer science. And I learned that, in particular, the invention of something called the Jacquard loom really led to early computing machines because, basically, weaving involves threading horizontal and vertical fibers. And the way you do it if you thread the horizontal fiber, also called the weft, over or under the vertical fibers, called the warp, you get different patterns.

+ +

And so with the Jacquard loom, this invention utilized punch cards as instructions for basically binary code, and that would tell the loom how to raise and lower those vertical threads, which would then lead to a beautiful pattern. And after that invention, this previously very laborious process became automated. And that also had a really big impact on the textile industry. And fabric became a lot more available at a much lower cost. So that was a really cool little history lesson for me.

+ +

JOËL: That is really cool. So are you saying that punch cards, as we know them from early computing, were borrowed as a concept from the weaving industry?

+ +

STEPHANIE: Yeah, that's at least what I've read. I can see now how complex weaving tapestries and patterns set the stage for more complex computations. And I don't know if I'm going to keep going down this weaving journey. I liked the intro class because it was very chill, and I got to use my hands. And I had a little bit of fun making, I don't know, like ten by 12-inch little tapestry. But yeah, I've definitely seen other more advanced weavers make really beautiful textiles and fiber arts. And it's really cool to see the application of that detail-oriented skill in different formats.

+ +

JOËL: Are you going to try to make your own punch cards?

+ +

STEPHANIE: That's an interesting evolution of this skill [laughs] for sure. I think what I really did like was the hands-on approach. And so the punch cards did make this process automated. But I personally enjoyed the switching of the threads and pulling them through and doing it with my hands instead of something that's kind of turned into automated machine work. Does that inspire you in some way?

+ +

JOËL: I think sometimes it's interesting, right? As software people, we sort of have the two urges. We work in so much automation. When we see a process, we would love to try to automate it ourselves, even if it's been done before. So, oh, could I build a small, automatic mechanical loom using punch cards? That sounds like a fun automation challenge. At the same time, so much of my daily job is automation that sometimes it's nice to kind of remove automation entirely from the picture and, like you said, just work with your hands.

+ +

STEPHANIE: That's a really interesting way to think about it. I do believe that people have different reactions to it, like you said, where they're like, "Wow, I can use my skills to do this really cool thing." On the other hand, you might also respond with, "Wow, I've done this automation code-writing work for eight hours. So now I really want to do something completely different." And I think that's the camp that I was in, at least when I first signed up for this class, just having space, like three hours a week, to sit and not look at a computer and deal with the physical realm.

+ +

JOËL: So here's the other route that I think a lot of software people take, and that is, here's a fun mechanical process that can be automated. What if we simulated it virtually? So what if I create a program where you can sort of create your own punch card, like, decide where you want to punch the holes?

+ +

And maybe these are just radio buttons or something or checkboxes in a grid on a webpage. And then, the program will output an SVG that is the thing that would have been woven if you'd used it in that pattern. And so now you can kind of play around with, like, huh, what if I punch here? What if I unpunch here? And you get all these patterns out, and you could just get to try it around.

+ +

STEPHANIE: That's fascinating. I can't believe your brain went there. [laughter] But yeah, the idea that it's not actually about the pattern itself but the holes that you make, that part being the creative process and then what comes out of it then being a bit of a surprise or just something organic that's a really interesting take too.

+ +

JOËL: Something that I find is really fun about software and things created from software is this sort of really short feedback loop in terms of trial and error. So if you were actually having a weaving machine and you made a physical punch card, and then you try something, and you realize it's not quite right, the machine weaved something you didn't quite like, now you've got to set it up again.

+ +

You probably have to start from scratch with a new punch card because you can't really unpunch holes unless maybe you can put tape over it or something. That trial-and-error feedback loop is much shorter. Whereas with a program, you just pause the simulation, punch-unpunch some holes, restart, and then you just kind of keep trying. And there's something fun about that creative exploration when you've got that really tight feedback loop.

+ +

STEPHANIE: That's fair. I think perhaps that actually might be why doing it manually, and by it, I mean weaving, gives you a little bit more room to [laughs] debug if you will, because you can see when something goes wrong. And this actually happened to me in class earlier this week where I didn't thread the fiber over instead of under. And I was like, oh, this doesn't look right. Like, that's not the look I'm going for.

+ +

And then I could kind of quickly see, oh, I missed a thread over here and unravel and do it again. Whereas what you just described, if the punch card is wrong and then you create this big piece of fabric, at that point, I'm not really sure what happens then. If someone out there is a weaving expert and knows the answer; I would be very curious to know.

+ +

JOËL: Now I kind of wish we'd had this conversation last month because, in early January, there was a game jam event that happened. It's a yearly or biyearly Historically Accurate Game Jam, and they select a theme, and then everybody has to submit a game, or a simulation, or something, an interactive program that fits with the theme. And this year's theme was the Industrial Revolution. And I feel like simulating an old automated loom with punch cards would be the perfect fit for something that's small enough that I could build it in a week without spending 10 hours a day working on it. It fits within the theme, and it's still kind of fun.

+ +

STEPHANIE: Wow, that would have been a really great idea. If there was an award for best fitting the theme, I think that would have won because then you're also tackling the history of computing. I was talking about earlier the loom obviously being...or the automated loom also really playing a big role in the Industrial Revolution. And, I don't know, maybe this is our future club, Joël, and we're going to get into video game development. [laughs] What's new in your world, Joël?

+ +

JOËL: There are two things. One is that today former Bike Shed host, Stephanie Viccari, shared a video with me from Ian Anderson. This was made last December to the tune of All I Want For Christmas Is You. But it's all about the, at that time, upcoming Ruby 3.2 release. It is amazing. The lyrics talk about the different features that are upcoming. It rhymes. It's set to meter. I am just blown away by this. And I'm just really hyped [laughs] about this video.

+ +

STEPHANIE: You sent it to me and I gave it a watch before we sat down to record, and I also loved this video. It was so fun. And I think Ruby has a bit of a tradition of releasing new versions around Christmas time. So if this became a tradition, that would be very fun, and maybe instead of singing Christmas carols, we'll be singing new Ruby version carols around the holidays.

+ +

JOËL: I feel like if Ian wants to do another one next Christmas, now that you have the precedent, it'd be a great space to try something to the tune of Last Christmas because now you can reference back last year's song.

+ +

STEPHANIE: Yeah. I might as well just go all in and create a whole Christmas album of Ruby anticipation carols.

+ +

[laughter]

+ +

JOËL: Yeah, really excited about that. Kudos to Ian. And for all of our listeners, we'll link the video on the show notes of the podcast. Go and check it out; it is worth the two and a half-minutes of your life.

+ +

STEPHANIE: Agreed.

+ +

JOËL: The other cool thing, for the past few episodes, we've been talking a lot about hexagons and how they show up in nature, and bees, and how they build their honeycombs and whether that is sort of by design or sort of just happens by nature through sort of external forces. And so this week, I went out to the store, and I bought some real honeycomb. And I'm going to try it on air.

+ +

STEPHANIE: [laughs] Oh my gosh, I didn't realize that's what was happening. [laughter] Okay, I'm ready.

+ +

JOËL: All right, I'm going to take a slice.

+ +

STEPHANIE: Wow. For research.

+ +

JOËL: For science.

+ +

STEPHANIE: Wow, that is a big bite. [laughs]

+ +

JOËL: Hmmm, it's basically crunchy honey.

+ +

STEPHANIE: So I've enjoyed honeycomb in that raw form on ice cream. I really like it on there and oatmeal and stuff like that. I think it's a little bit waxy. Like, once you get to chewing the bits at the end, that part is a bit of a less pleasant mouth-feel [laughs] in my opinion. What are you experiencing right now?

+ +

JOËL: Yeah, so like you're saying, the honey kind of dissolves away in your mouth. You had this really fun mix of textures. But then, in the end, you do end up with a ball of [laughter] beeswax in your mouth.

+ +

STEPHANIE: Oh no.

+ +

JOËL: Which I understand is completely safe to eat, so...

+ +

STEPHANIE: Yeah, that's true.

+ +

JOËL: I'm just going to eat the whole thing.

+ +

STEPHANIE: I think it's kind of like swallowing gum. [laughs]

+ +

JOËL: Which apparently does not last for seven years in your digestive system; that's a myth.

+ +

STEPHANIE: Wow, debunking myths, trying honeycomb. You're welcome, to all The Bike Shed listeners out there. Investigating the important things.

+ +

JOËL: What is interesting is that we're talking about the structural power of hexagons. I can cut a pretty thin slice of the comb, and it doesn't fall apart. It still has a lot of strength to it, which is nice because it means that the honey doesn't just go splashing everywhere. I can cut up a fairly thin slice, pick it up, it still holds the honey, put it in my mouth, and it doesn't make a mess.

+ +

STEPHANIE: The bees know what they're doing. [laughs] Cool. Would you eat raw honeycomb again?

+ +

JOËL: Well, I got a whole block, and I had one tiny slice. So, yes, I will be eating the rest of this.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I don't think this will be a regular thing in my weekly groceries. But I would bring this out again for a special occasion. Or I can see this fitting nicely, like you said, on maybe certain breakfasts, even on a charcuterie board or something.

+ +

STEPHANIE: Oh yeah, that's a really good use for it.

+ +

JOËL: In some ways, it's nice because it's a way to have honey without having to have it on something else or having to eat it with a spoon. It's honey that comes with its own carrying vessel.

+ +

STEPHANIE: That's great. Yeah, like a bread bowl for soup. [laughs]

+ +

JOËL: Exactly. Bees make their own bread bowls for honey.

+ +

STEPHANIE: [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So, for the last couple of weeks, we've been joking that this is turning into the Stephanie and Joël book club because we've been talking about a lot of articles and books. Today, I'd like to shift a little bit away from literature and lean into art. Writing code is a technical work, but in many ways, it's also an aesthetic work. It's a work of art. How do you feel about the idea of expressing yourself creatively through your code?

+ +

STEPHANIE: So this is interesting to me because it's actually quite different from what we've been talking about in recent episodes around the idea of writing sustainable code, code for other people to read. Because if you are writing code purely for creative expression and just for yourself, that will look very different than what I think folks have kind of called boring technology, which is choosing the patterns, the tools, the frameworks that are tried and true, and just kind of sticking to the things that people have solved before.

+ +

And so, in some ways, I don't know if I really get to express myself creatively in the code that I write, which I think is okay for me because I don't really consider myself someone who needs a creative outlet in my work. What about you? What thoughts do you have about this?

+ +

JOËL: I think it's interesting the way you described it. I'm almost wondering if I'm making maybe a comparison to physical architecture; maybe you almost have a sort of brutalist perspective on the things you construct.

+ +

STEPHANIE: [laughs]

+ +

JOËL: So they're functional. They're minimal. They are not always the prettiest to look at, but they're solid. Does that metaphor sound about right to you?

+ +

STEPHANIE: I feel like I have to make a pun about SOLID, the design patterns, and code.

+ +

JOËL: Ooh.

+ +

STEPHANIE: [laughs] But I think I like brutalist, I mean, the term itself. I don't know if I necessarily identify with it in terms of my work and output. But the idea that the code that I do is functional is, I think, particularly important to me as a developer. And I don't just mean, like, oh, the code works, so it's done, but functional for whatever need I'm solving and also for the people who are working with this code again in the future.

+ +

I mentioned boring technology. There's a talk that I'm kind of referencing by Dan McKinley, and you can check out his slides at boringtechnology.club. And he talks about this idea of decision-making and how that relates to writing boring or creative code. And he also references Maslow's hierarchy of needs. And so, ideally, if you're working in an existing codebase, all the low-level decisions have been made for you. And then you can kind of traverse the hierarchy and focus your creativity on the high-level problems that you're trying to solve.

+ +

So maybe you're not necessarily expressing your creativity in the syntax or whatever pattern you're using, again, because a lot of those things have been solved. But where the creativity comes from is the particular domain or business problem you have and the real-world constraints that you're faced with. And how do you figure out what to do given those constraints?

+ +

JOËL: I think that lines up a lot with my own experience as well. I think as a newer developer, syntax is sort of the thing that's top of mind. And so, maybe trying to get clever with syntax is something that I would focus on more. Sometimes that's trying to get code really short and terse. Sometimes it's because I want to try. Can I do this thing with a particular piece of syntax, or even just does it look pretty?

+ +

I think now, in my code, I am actually kind of boring with my syntax. I, probably when I write Ruby, mostly use a kind of slimmed-down set of syntax and don't use the full expressive power of the language for most of my day-to-day needs. So basic things with objects, and methods, and blocks, sort of the basic building blocks that we get from Ruby regular conditionals, if...else, and a few other nice things that the language gives us. But, in many ways, it almost feels like...I don't know if you've ever seen the simplified English Wikipedia.

+ +

STEPHANIE: No, I haven't. What is that?

+ +

JOËL: They're treating it, I think, like a separate language, but it is a version of Wikipedia in English with a more restricted vocabulary to try to make the content more accessible to those that might struggle with more standard English. So it's a sort of smaller subset of English. And, in many ways, I feel like a lot of the day-to-day Ruby code that I write is simplified, Ruby.

+ +

STEPHANIE: Wow, that's really interesting. I think this also goes back to the specialized vocabulary episode we talked about. And is there value in keeping things accessible, and straightforward, and boring but at the cost of being able to express yourself with everything you have available to you? This is a bit of a tangent, I guess, but I grew up speaking Chinese with my parents, but since then, I have really lost a lot of that vocabulary.

+ +

And, in some ways, I really struggle with communicating in Chinese because I feel like I'm not able to express myself exactly the way I want to in the way that I can in English. And when I'm talking to my parents, yeah, that's been a bit of a challenge for me because I do really value being able to say things the way that I mean, and I'm not able to have that with my limited vocabulary. So I can also see how people might not enjoy working within these confines of boring syntax and boring frameworks.

+ +

JOËL: Sometimes it's nice to give yourself a sort of syntactical restriction, but they're very low-level when it comes to most of what we do for programming. And I think that's sort of what I've learned as my career has evolved is that programming is so much more than just learning syntax. So kind of like with art, maybe it's nice to restrict yourself to say, oh, can I do something with only a particular brushstroke technique, or restricting myself to a particular palette or a particular medium? And that can foster a lot of creativity. So, similarly, I think you could do some things like playing Code Golf, not on production code; please don't.

+ +

STEPHANIE: [laughs]

+ +

JOËL: But as an experiment in a side project or just almost as a piece of art, that can be a really interesting problem to solve and give you a deeper understanding of the language. And I'm sure there are plenty of other syntactical limitations you could put on yourself or maybe fancy things you would like to explore and say, "Well, this is over the top. We don't need to structure it in this way or use this syntax. But I want to sort of push the boundaries of what can be done with it. Let's see where I can take it."

+ +

STEPHANIE: That's really fair. And I think it relates back to what I was saying earlier about perhaps creativity when writing software products comes from the constraints of the business of, in some ways, physical aspects of development. In the Dan McKinley talk, I mentioned about choosing boring technology. He generally recommends against bringing in a new language or framework because of the costs, the carrying cost of doing that, and the long-term maintenance to consider.

+ +

But he instead suggests turning the question on its head and being like, how can we solve this problem with the current technology that we do have? And I think that relates to what you were saying about being able to push the boundaries of a particular medium or tool and in a way that you might not have considered before.

+ +

JOËL: Exactly. And I think going back to the analogy with art; sometimes it is nice to restrict yourself to a particular brushstroke or something like that to try to foster creativity. But oftentimes, you want to explore creativity in much higher-level ways. So maybe you're not restricting things like brushstrokes and color, and, instead, you want to explore lighting. You want to explore maybe certain ways of mixing colors.

+ +

There are all sorts of, I think, higher-level ways that you can be creative in art that's not just the mechanics of how you apply pigment to canvas. And we see the same thing like you were saying, in code where there's a lot of higher level business problems. Generally, how do we want to structure large chunks of the code? How do we want to build abstractions? Although that can also be a dangerous place to get too creative in.

+ +

STEPHANIE: Yeah, absolutely. Do you consider yourself a creative person or need a creative outlet? And how does writing code or software development play a role in that for you?

+ +

JOËL: I would say, yes, I consider myself a creative person. And I would consider coding, in general, to be a creative endeavor. I sometimes describe to people that writing code is like building something out of infinite legos. You're constrained only by the power of your imagination and the amount of time you're willing to put into constructing the thing that you're building.

+ +

Of course, then you have all sorts of business constraints. And there are things you want to do on a work project that are probably not the same as what you would want to do on a client project or on a personal project. But there's still creativity, I think, at every level and sometimes even outside of the code itself. Just understanding and breaking down the business problem can require a ton of creativity before you even write a single line of code in your editor.

+ +

I was reading a Twitter thread the other day by @GeePawHill that sort of proposes that there are sort of four steps in evolution of kind of the mindset that programmers go through over their career. And I'd be curious to hear your thoughts on this evolution if you kind of agree with it or disagree with it if that maybe lines up with some of your experience.

+ +

So this Twitter thread proposes four levels of thinking that we go through. I think we can kind of jump between these levels at various points in our work. So we might do all of these in a day, but to a certain extent, they also follow a little bit of a progression in our career. So the first level is thinking in terms of syntax; that's just knowing the characters to type in the editor.

+ +

The second level is thinking in terms of code, that's, thinking a little bit more semantically. So now, instead of thinking, oh, do I need if then curly brace, then closed curly brace? Now we're thinking more in terms of, okay, I need a branch in the flow of control for my logic here. And at that level, maybe you don't even need to think about the syntax quite so much because you're so comfortable with. It kind of just fades away.

+ +

Building beyond that, now you're thinking in terms of your paradigm. So Ruby is an object-oriented language, so you might be thinking in terms of what objects do I need to represent this problem and how do they need to talk to each other? And the sort of underlying semantics of, oh, do I need a conditional here or not? Those might start fading away because now you're thinking at a slightly higher level.

+ +

And then, finally, thinking in terms of change sets. Now you're thinking less in terms of the language itself and more in terms of the business problems and how the current behavior of the software is different and needs to change to get to where we want the behavior to be.

+ +

STEPHANIE: I think I disagree a little bit with the idea that it's a progression. And I'm thinking about how when you have a beginner's mind, anything is possible. And in some ways, if you are new to coding, before you have that understanding of what is and isn't possible, anything is possible. And so, in some ways, I've worked with people who are super new to coding, and the ideas that they come up with for how to make a change at that highest level that you were just describing, in some ways, make sense.

+ +

You can be like, oh yeah, that actually is something we can do and an idea that you might eventually get to from someone more experienced, having followed those different levels of progression and reaching a place where you're like, I know exactly what tools or the details about how to do this. But when you have that beginner's mind, and you don't have the details of the how, I think you can still think about those problems at a higher level, and that is valuable, and maybe they'll need help implementing along the way.

+ +

And I think that that could be a really interesting area of collaboration that perhaps we don't do enough in this industry because it's very mentorship-focused where it's like, okay, I have more experience, and so I'm going to teach you what I know. Whereas if you bring someone with a totally fresh perspective along, what ideas can you generate from there?

+ +

JOËL: I think we definitely exist in all of these layers every day as developers. I think, looking back at myself as a newer developer, I tended to maybe work bottom-up when I tried to solve a problem. And I think that now I probably tend to work sort of in the reverse order, start by thinking in terms of changes and then work my way down. And so syntax, at that point, is the last thing that I'm thinking about. It's really an implementation detail. Whereas I think as a new coder, syntax was super important. Was your experience similar to that, or did you have a very different journey?

+ +

STEPHANIE: It's funny that you mentioned it because I think when I was new to development, there were so many syntactic things that I didn't understand that I just kind of like blurted out of my brain when I was reading code and was then trying to latch on to the important pieces of information that I needed to know, which often meant class names or method names. Pieces that I could grab onto and be like, okay, I'm seeing that this method then calls this other method or whatever.

+ +

And, yeah, what you were saying about implementation details falling away, I kind of did that at the beginning of my career a little bit, at least at that syntactic level. So, yeah, I think I'm with you where we all exist at different parts of this framework, I suppose. And that journey could look different for everyone.

+ +

JOËL: So we're talking about ways to be creative at higher levels. And one way that I find has been really fun for me but also really useful has been bringing in dependency graphs as a tool for design. You knew I had to mention dependency graphs.

+ +

STEPHANIE: We got there in the end. [laughter] Cool, go on.

+ +

JOËL: I think it's been really good sometimes in terms of modeling change sets because dependency graphs can be a great tool for that, but also sometimes in terms of trying to understand what the underlying business problem is and how it might translate into code structures where things might be tightly coupled versus not. And so, drawing it out visually is a really powerful design tool.

+ +

And because now I can look at it in two-dimensional space, I can realize, oh, I see something that feels like it's maybe an anti-pattern or might be a problem here. There's a cycle in my graph; maybe we should find a way to break that. Maybe we need to introduce some dependency inversion and break that cycle, and now our graph is acyclic.

+ +

And so I think that's where there can be a lot of creativity that happens, even when you're not writing code at that point. You're just sort of talking about how different pieces of the project or even different subproblems...you're not even talking about if they're implemented in code, but just saying this subproblem is related to this subproblem, and maybe I would like to find a way for them to not have a connection to each other.

+ +

STEPHANIE: I'm glad we got back to this dependency graph topic because I stumbled upon something that I'm curious to hear your opinion on. I have been following Julia Evans' work for a little bit now. And she recently released a new zine about debugging. And at the end of the zine, she includes a link to these choose-your-own adventure puzzles that she has created, specifically to teach you about debugging and how to do it.

+ +

And so it's basically a little detective game, and you kind of follow along with this bug. And she gives you some different options about how would you like to find a little bit more information about this bug? And what approach would you take? And you make some different selections, and then as you go, you get more information about the bug. And that helps inform what next steps you might take.

+ +

And, one, I think this is a great example of a creative project about software development, even though it's not necessarily your day-to-day work. But then she also uses a tool called Twine, which is for creating non-linear stories, or puzzles, or games. And it got me really thinking about the multi-step wizard we've been talking about and this idea of looking at a problem in different mediums.

+ +

It also reminds me of if you have a designer on your team and they're doing prototyping, they usually have some kind of user interactivity that they have to codify. And they are making those decisions about okay, like, if you are at this step, then where do you go next? And those are all things that you've talked about doing as a developer, I think, at a later point in the future lifecycle. And I'm now just kind of thinking about how to integrate some of that into our workflow. Do you have any thoughts about that?

+ +

JOËL: I had one of the coolest experiences in my career when I was doing a front-end project where we were building a typeahead component that was pulling data from a remote server and then populating a drop-down. And the designer and I sat down and just started to look through all the different states that you could be and how you could move from one to another.

+ +

So it looked like maybe you start the typeahead is empty; it's just a text box. And then as you start typing, maybe there's a spinner that shows up. And then maybe you have some results, or maybe you don't have results. And those are two different entirely states that you could be in. And then, if you backspace, what happens? And what if something goes wrong on the server? Like, we just kept finding all these edge cases.

+ +

And we built out a diagram of all the possible journeys that someone could take, starting from that empty text box, all the way to either some sort of error state or a final state where you've selected an item. But, of course, these are not necessarily terminal because in an error state, maybe you can just start typing again, and you sort of jump back into the beginning of the flow.

+ +

So we did this whole diagram that ended up looking very much like a finite-state machine. We didn't use the term, but that's kind of what it ended up being. And I think we both learned a lot about the problem we were trying to solve and the user experience we were trying to create through that.

+ +

There was just a lot of back and forth of, like, oh, did you think about what would happen if we get no results here? Have we thought about that state? Or it's like, okay, so now we're in an error state. What do we do? Is there a way to get out of it, or are we just kind of stuck? Oh, you can backspace. Okay, what happens then?

+ +

STEPHANIE: Yeah, I mean, we've been talking about creativity as a solitary process. But I think that that goes to show that when collaborating with other people, too, that process can also be very fun and creative and fulfill that need outside of the way the code is written.

+ +

JOËL: In many ways, I think working with somebody else, and that gets made at the intersection of two or more people's work, is probably the most creative way to build software.

+ +

STEPHANIE: That actually reminds me of a book I read last year called "Tomorrow, and Tomorrow, and Tomorrow." And it's about these two friends and their journey creating video games together. And it kind of follows several decades of their life and their relationship, and their creative and collaborative process. And I really loved that book. It was very good, especially if you like video games. There are a lot of great references to that too.

+ +

But I think what you were saying about that fulfillment that you can get with working with other people, and that book does a really good job examining that and getting into our need as humans for that type of collaboration. So that's my little book rec. It goes back to our conversation about designing a game. Again, maybe this is [laughs] what we'll do next. Who knows? The world's our oyster.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Stephanie shares that she's been taking an intro to basket weaving class at a local art studio, and it's an interesting connection to computer science. Joël eats honeycomb live on air and shares a video that former Bike Shed host Steph Viccari found from Ian Anderson. It's a parody to the tune of "All I Want For Christmas Is You," but it's all about the Ruby 3.2 release.

+ +

In this episode, Stephanie and Joël shift away from literature and lean into art. Writing code is technical work, but in many ways, it's also aesthetic work. It's a work of art. How do you feel about expressing yourself creatively through your code?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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: I'm really excited to share that I've been taking this intro to weaving class at a local art studio. I'm actually a few weeks in, and it's wrapping up soon. But one thing that I found really cool at the very first class was that the instructor mentioned that weaving was, in some ways, a predecessor or inspiration to modern computing. And he said that, and I got really excited because surely that meant that I would be good at this thing [laughs] and this craft, and then I promptly kind of forgot about it.

+ +

But I was inspired the other night to look up this history to just learn more about weaving and its connection to computer science. And I learned that, in particular, the invention of something called the Jacquard loom really led to early computing machines because, basically, weaving involves threading horizontal and vertical fibers. And the way you do it if you thread the horizontal fiber, also called the weft, over or under the vertical fibers, called the warp, you get different patterns.

+ +

And so with the Jacquard loom, this invention utilized punch cards as instructions for basically binary code, and that would tell the loom how to raise and lower those vertical threads, which would then lead to a beautiful pattern. And after that invention, this previously very laborious process became automated. And that also had a really big impact on the textile industry. And fabric became a lot more available at a much lower cost. So that was a really cool little history lesson for me.

+ +

JOËL: That is really cool. So are you saying that punch cards, as we know them from early computing, were borrowed as a concept from the weaving industry?

+ +

STEPHANIE: Yeah, that's at least what I've read. I can see now how complex weaving tapestries and patterns set the stage for more complex computations. And I don't know if I'm going to keep going down this weaving journey. I liked the intro class because it was very chill, and I got to use my hands. And I had a little bit of fun making, I don't know, like ten by 12-inch little tapestry. But yeah, I've definitely seen other more advanced weavers make really beautiful textiles and fiber arts. And it's really cool to see the application of that detail-oriented skill in different formats.

+ +

JOËL: Are you going to try to make your own punch cards?

+ +

STEPHANIE: That's an interesting evolution of this skill [laughs] for sure. I think what I really did like was the hands-on approach. And so the punch cards did make this process automated. But I personally enjoyed the switching of the threads and pulling them through and doing it with my hands instead of something that's kind of turned into automated machine work. Does that inspire you in some way?

+ +

JOËL: I think sometimes it's interesting, right? As software people, we sort of have the two urges. We work in so much automation. When we see a process, we would love to try to automate it ourselves, even if it's been done before. So, oh, could I build a small, automatic mechanical loom using punch cards? That sounds like a fun automation challenge. At the same time, so much of my daily job is automation that sometimes it's nice to kind of remove automation entirely from the picture and, like you said, just work with your hands.

+ +

STEPHANIE: That's a really interesting way to think about it. I do believe that people have different reactions to it, like you said, where they're like, "Wow, I can use my skills to do this really cool thing." On the other hand, you might also respond with, "Wow, I've done this automation code-writing work for eight hours. So now I really want to do something completely different." And I think that's the camp that I was in, at least when I first signed up for this class, just having space, like three hours a week, to sit and not look at a computer and deal with the physical realm.

+ +

JOËL: So here's the other route that I think a lot of software people take, and that is, here's a fun mechanical process that can be automated. What if we simulated it virtually? So what if I create a program where you can sort of create your own punch card, like, decide where you want to punch the holes?

+ +

And maybe these are just radio buttons or something or checkboxes in a grid on a webpage. And then, the program will output an SVG that is the thing that would have been woven if you'd used it in that pattern. And so now you can kind of play around with, like, huh, what if I punch here? What if I unpunch here? And you get all these patterns out, and you could just get to try it around.

+ +

STEPHANIE: That's fascinating. I can't believe your brain went there. [laughter] But yeah, the idea that it's not actually about the pattern itself but the holes that you make, that part being the creative process and then what comes out of it then being a bit of a surprise or just something organic that's a really interesting take too.

+ +

JOËL: Something that I find is really fun about software and things created from software is this sort of really short feedback loop in terms of trial and error. So if you were actually having a weaving machine and you made a physical punch card, and then you try something, and you realize it's not quite right, the machine weaved something you didn't quite like, now you've got to set it up again.

+ +

You probably have to start from scratch with a new punch card because you can't really unpunch holes unless maybe you can put tape over it or something. That trial-and-error feedback loop is much shorter. Whereas with a program, you just pause the simulation, punch-unpunch some holes, restart, and then you just kind of keep trying. And there's something fun about that creative exploration when you've got that really tight feedback loop.

+ +

STEPHANIE: That's fair. I think perhaps that actually might be why doing it manually, and by it, I mean weaving, gives you a little bit more room to [laughs] debug if you will, because you can see when something goes wrong. And this actually happened to me in class earlier this week where I didn't thread the fiber over instead of under. And I was like, oh, this doesn't look right. Like, that's not the look I'm going for.

+ +

And then I could kind of quickly see, oh, I missed a thread over here and unravel and do it again. Whereas what you just described, if the punch card is wrong and then you create this big piece of fabric, at that point, I'm not really sure what happens then. If someone out there is a weaving expert and knows the answer; I would be very curious to know.

+ +

JOËL: Now I kind of wish we'd had this conversation last month because, in early January, there was a game jam event that happened. It's a yearly or biyearly Historically Accurate Game Jam, and they select a theme, and then everybody has to submit a game, or a simulation, or something, an interactive program that fits with the theme. And this year's theme was the Industrial Revolution. And I feel like simulating an old automated loom with punch cards would be the perfect fit for something that's small enough that I could build it in a week without spending 10 hours a day working on it. It fits within the theme, and it's still kind of fun.

+ +

STEPHANIE: Wow, that would have been a really great idea. If there was an award for best fitting the theme, I think that would have won because then you're also tackling the history of computing. I was talking about earlier the loom obviously being...or the automated loom also really playing a big role in the Industrial Revolution. And, I don't know, maybe this is our future club, Joël, and we're going to get into video game development. [laughs] What's new in your world, Joël?

+ +

JOËL: There are two things. One is that today former Bike Shed host, Stephanie Viccari, shared a video with me from Ian Anderson. This was made last December to the tune of All I Want For Christmas Is You. But it's all about the, at that time, upcoming Ruby 3.2 release. It is amazing. The lyrics talk about the different features that are upcoming. It rhymes. It's set to meter. I am just blown away by this. And I'm just really hyped [laughs] about this video.

+ +

STEPHANIE: You sent it to me and I gave it a watch before we sat down to record, and I also loved this video. It was so fun. And I think Ruby has a bit of a tradition of releasing new versions around Christmas time. So if this became a tradition, that would be very fun, and maybe instead of singing Christmas carols, we'll be singing new Ruby version carols around the holidays.

+ +

JOËL: I feel like if Ian wants to do another one next Christmas, now that you have the precedent, it'd be a great space to try something to the tune of Last Christmas because now you can reference back last year's song.

+ +

STEPHANIE: Yeah. I might as well just go all in and create a whole Christmas album of Ruby anticipation carols.

+ +

[laughter]

+ +

JOËL: Yeah, really excited about that. Kudos to Ian. And for all of our listeners, we'll link the video on the show notes of the podcast. Go and check it out; it is worth the two and a half-minutes of your life.

+ +

STEPHANIE: Agreed.

+ +

JOËL: The other cool thing, for the past few episodes, we've been talking a lot about hexagons and how they show up in nature, and bees, and how they build their honeycombs and whether that is sort of by design or sort of just happens by nature through sort of external forces. And so this week, I went out to the store, and I bought some real honeycomb. And I'm going to try it on air.

+ +

STEPHANIE: [laughs] Oh my gosh, I didn't realize that's what was happening. [laughter] Okay, I'm ready.

+ +

JOËL: All right, I'm going to take a slice.

+ +

STEPHANIE: Wow. For research.

+ +

JOËL: For science.

+ +

STEPHANIE: Wow, that is a big bite. [laughs]

+ +

JOËL: Hmmm, it's basically crunchy honey.

+ +

STEPHANIE: So I've enjoyed honeycomb in that raw form on ice cream. I really like it on there and oatmeal and stuff like that. I think it's a little bit waxy. Like, once you get to chewing the bits at the end, that part is a bit of a less pleasant mouth-feel [laughs] in my opinion. What are you experiencing right now?

+ +

JOËL: Yeah, so like you're saying, the honey kind of dissolves away in your mouth. You had this really fun mix of textures. But then, in the end, you do end up with a ball of [laughter] beeswax in your mouth.

+ +

STEPHANIE: Oh no.

+ +

JOËL: Which I understand is completely safe to eat, so...

+ +

STEPHANIE: Yeah, that's true.

+ +

JOËL: I'm just going to eat the whole thing.

+ +

STEPHANIE: I think it's kind of like swallowing gum. [laughs]

+ +

JOËL: Which apparently does not last for seven years in your digestive system; that's a myth.

+ +

STEPHANIE: Wow, debunking myths, trying honeycomb. You're welcome, to all The Bike Shed listeners out there. Investigating the important things.

+ +

JOËL: What is interesting is that we're talking about the structural power of hexagons. I can cut a pretty thin slice of the comb, and it doesn't fall apart. It still has a lot of strength to it, which is nice because it means that the honey doesn't just go splashing everywhere. I can cut up a fairly thin slice, pick it up, it still holds the honey, put it in my mouth, and it doesn't make a mess.

+ +

STEPHANIE: The bees know what they're doing. [laughs] Cool. Would you eat raw honeycomb again?

+ +

JOËL: Well, I got a whole block, and I had one tiny slice. So, yes, I will be eating the rest of this.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I don't think this will be a regular thing in my weekly groceries. But I would bring this out again for a special occasion. Or I can see this fitting nicely, like you said, on maybe certain breakfasts, even on a charcuterie board or something.

+ +

STEPHANIE: Oh yeah, that's a really good use for it.

+ +

JOËL: In some ways, it's nice because it's a way to have honey without having to have it on something else or having to eat it with a spoon. It's honey that comes with its own carrying vessel.

+ +

STEPHANIE: That's great. Yeah, like a bread bowl for soup. [laughs]

+ +

JOËL: Exactly. Bees make their own bread bowls for honey.

+ +

STEPHANIE: [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So, for the last couple of weeks, we've been joking that this is turning into the Stephanie and Joël book club because we've been talking about a lot of articles and books. Today, I'd like to shift a little bit away from literature and lean into art. Writing code is a technical work, but in many ways, it's also an aesthetic work. It's a work of art. How do you feel about the idea of expressing yourself creatively through your code?

+ +

STEPHANIE: So this is interesting to me because it's actually quite different from what we've been talking about in recent episodes around the idea of writing sustainable code, code for other people to read. Because if you are writing code purely for creative expression and just for yourself, that will look very different than what I think folks have kind of called boring technology, which is choosing the patterns, the tools, the frameworks that are tried and true, and just kind of sticking to the things that people have solved before.

+ +

And so, in some ways, I don't know if I really get to express myself creatively in the code that I write, which I think is okay for me because I don't really consider myself someone who needs a creative outlet in my work. What about you? What thoughts do you have about this?

+ +

JOËL: I think it's interesting the way you described it. I'm almost wondering if I'm making maybe a comparison to physical architecture; maybe you almost have a sort of brutalist perspective on the things you construct.

+ +

STEPHANIE: [laughs]

+ +

JOËL: So they're functional. They're minimal. They are not always the prettiest to look at, but they're solid. Does that metaphor sound about right to you?

+ +

STEPHANIE: I feel like I have to make a pun about SOLID, the design patterns, and code.

+ +

JOËL: Ooh.

+ +

STEPHANIE: [laughs] But I think I like brutalist, I mean, the term itself. I don't know if I necessarily identify with it in terms of my work and output. But the idea that the code that I do is functional is, I think, particularly important to me as a developer. And I don't just mean, like, oh, the code works, so it's done, but functional for whatever need I'm solving and also for the people who are working with this code again in the future.

+ +

I mentioned boring technology. There's a talk that I'm kind of referencing by Dan McKinley, and you can check out his slides at boringtechnology.club. And he talks about this idea of decision-making and how that relates to writing boring or creative code. And he also references Maslow's hierarchy of needs. And so, ideally, if you're working in an existing codebase, all the low-level decisions have been made for you. And then you can kind of traverse the hierarchy and focus your creativity on the high-level problems that you're trying to solve.

+ +

So maybe you're not necessarily expressing your creativity in the syntax or whatever pattern you're using, again, because a lot of those things have been solved. But where the creativity comes from is the particular domain or business problem you have and the real-world constraints that you're faced with. And how do you figure out what to do given those constraints?

+ +

JOËL: I think that lines up a lot with my own experience as well. I think as a newer developer, syntax is sort of the thing that's top of mind. And so, maybe trying to get clever with syntax is something that I would focus on more. Sometimes that's trying to get code really short and terse. Sometimes it's because I want to try. Can I do this thing with a particular piece of syntax, or even just does it look pretty?

+ +

I think now, in my code, I am actually kind of boring with my syntax. I, probably when I write Ruby, mostly use a kind of slimmed-down set of syntax and don't use the full expressive power of the language for most of my day-to-day needs. So basic things with objects, and methods, and blocks, sort of the basic building blocks that we get from Ruby regular conditionals, if...else, and a few other nice things that the language gives us. But, in many ways, it almost feels like...I don't know if you've ever seen the simplified English Wikipedia.

+ +

STEPHANIE: No, I haven't. What is that?

+ +

JOËL: They're treating it, I think, like a separate language, but it is a version of Wikipedia in English with a more restricted vocabulary to try to make the content more accessible to those that might struggle with more standard English. So it's a sort of smaller subset of English. And, in many ways, I feel like a lot of the day-to-day Ruby code that I write is simplified, Ruby.

+ +

STEPHANIE: Wow, that's really interesting. I think this also goes back to the specialized vocabulary episode we talked about. And is there value in keeping things accessible, and straightforward, and boring but at the cost of being able to express yourself with everything you have available to you? This is a bit of a tangent, I guess, but I grew up speaking Chinese with my parents, but since then, I have really lost a lot of that vocabulary.

+ +

And, in some ways, I really struggle with communicating in Chinese because I feel like I'm not able to express myself exactly the way I want to in the way that I can in English. And when I'm talking to my parents, yeah, that's been a bit of a challenge for me because I do really value being able to say things the way that I mean, and I'm not able to have that with my limited vocabulary. So I can also see how people might not enjoy working within these confines of boring syntax and boring frameworks.

+ +

JOËL: Sometimes it's nice to give yourself a sort of syntactical restriction, but they're very low-level when it comes to most of what we do for programming. And I think that's sort of what I've learned as my career has evolved is that programming is so much more than just learning syntax. So kind of like with art, maybe it's nice to restrict yourself to say, oh, can I do something with only a particular brushstroke technique, or restricting myself to a particular palette or a particular medium? And that can foster a lot of creativity. So, similarly, I think you could do some things like playing Code Golf, not on production code; please don't.

+ +

STEPHANIE: [laughs]

+ +

JOËL: But as an experiment in a side project or just almost as a piece of art, that can be a really interesting problem to solve and give you a deeper understanding of the language. And I'm sure there are plenty of other syntactical limitations you could put on yourself or maybe fancy things you would like to explore and say, "Well, this is over the top. We don't need to structure it in this way or use this syntax. But I want to sort of push the boundaries of what can be done with it. Let's see where I can take it."

+ +

STEPHANIE: That's really fair. And I think it relates back to what I was saying earlier about perhaps creativity when writing software products comes from the constraints of the business of, in some ways, physical aspects of development. In the Dan McKinley talk, I mentioned about choosing boring technology. He generally recommends against bringing in a new language or framework because of the costs, the carrying cost of doing that, and the long-term maintenance to consider.

+ +

But he instead suggests turning the question on its head and being like, how can we solve this problem with the current technology that we do have? And I think that relates to what you were saying about being able to push the boundaries of a particular medium or tool and in a way that you might not have considered before.

+ +

JOËL: Exactly. And I think going back to the analogy with art; sometimes it is nice to restrict yourself to a particular brushstroke or something like that to try to foster creativity. But oftentimes, you want to explore creativity in much higher-level ways. So maybe you're not restricting things like brushstrokes and color, and, instead, you want to explore lighting. You want to explore maybe certain ways of mixing colors.

+ +

There are all sorts of, I think, higher-level ways that you can be creative in art that's not just the mechanics of how you apply pigment to canvas. And we see the same thing like you were saying, in code where there's a lot of higher level business problems. Generally, how do we want to structure large chunks of the code? How do we want to build abstractions? Although that can also be a dangerous place to get too creative in.

+ +

STEPHANIE: Yeah, absolutely. Do you consider yourself a creative person or need a creative outlet? And how does writing code or software development play a role in that for you?

+ +

JOËL: I would say, yes, I consider myself a creative person. And I would consider coding, in general, to be a creative endeavor. I sometimes describe to people that writing code is like building something out of infinite legos. You're constrained only by the power of your imagination and the amount of time you're willing to put into constructing the thing that you're building.

+ +

Of course, then you have all sorts of business constraints. And there are things you want to do on a work project that are probably not the same as what you would want to do on a client project or on a personal project. But there's still creativity, I think, at every level and sometimes even outside of the code itself. Just understanding and breaking down the business problem can require a ton of creativity before you even write a single line of code in your editor.

+ +

I was reading a Twitter thread the other day by @GeePawHill that sort of proposes that there are sort of four steps in evolution of kind of the mindset that programmers go through over their career. And I'd be curious to hear your thoughts on this evolution if you kind of agree with it or disagree with it if that maybe lines up with some of your experience.

+ +

So this Twitter thread proposes four levels of thinking that we go through. I think we can kind of jump between these levels at various points in our work. So we might do all of these in a day, but to a certain extent, they also follow a little bit of a progression in our career. So the first level is thinking in terms of syntax; that's just knowing the characters to type in the editor.

+ +

The second level is thinking in terms of code, that's, thinking a little bit more semantically. So now, instead of thinking, oh, do I need if then curly brace, then closed curly brace? Now we're thinking more in terms of, okay, I need a branch in the flow of control for my logic here. And at that level, maybe you don't even need to think about the syntax quite so much because you're so comfortable with. It kind of just fades away.

+ +

Building beyond that, now you're thinking in terms of your paradigm. So Ruby is an object-oriented language, so you might be thinking in terms of what objects do I need to represent this problem and how do they need to talk to each other? And the sort of underlying semantics of, oh, do I need a conditional here or not? Those might start fading away because now you're thinking at a slightly higher level.

+ +

And then, finally, thinking in terms of change sets. Now you're thinking less in terms of the language itself and more in terms of the business problems and how the current behavior of the software is different and needs to change to get to where we want the behavior to be.

+ +

STEPHANIE: I think I disagree a little bit with the idea that it's a progression. And I'm thinking about how when you have a beginner's mind, anything is possible. And in some ways, if you are new to coding, before you have that understanding of what is and isn't possible, anything is possible. And so, in some ways, I've worked with people who are super new to coding, and the ideas that they come up with for how to make a change at that highest level that you were just describing, in some ways, make sense.

+ +

You can be like, oh yeah, that actually is something we can do and an idea that you might eventually get to from someone more experienced, having followed those different levels of progression and reaching a place where you're like, I know exactly what tools or the details about how to do this. But when you have that beginner's mind, and you don't have the details of the how, I think you can still think about those problems at a higher level, and that is valuable, and maybe they'll need help implementing along the way.

+ +

And I think that that could be a really interesting area of collaboration that perhaps we don't do enough in this industry because it's very mentorship-focused where it's like, okay, I have more experience, and so I'm going to teach you what I know. Whereas if you bring someone with a totally fresh perspective along, what ideas can you generate from there?

+ +

JOËL: I think we definitely exist in all of these layers every day as developers. I think, looking back at myself as a newer developer, I tended to maybe work bottom-up when I tried to solve a problem. And I think that now I probably tend to work sort of in the reverse order, start by thinking in terms of changes and then work my way down. And so syntax, at that point, is the last thing that I'm thinking about. It's really an implementation detail. Whereas I think as a new coder, syntax was super important. Was your experience similar to that, or did you have a very different journey?

+ +

STEPHANIE: It's funny that you mentioned it because I think when I was new to development, there were so many syntactic things that I didn't understand that I just kind of like blurted out of my brain when I was reading code and was then trying to latch on to the important pieces of information that I needed to know, which often meant class names or method names. Pieces that I could grab onto and be like, okay, I'm seeing that this method then calls this other method or whatever.

+ +

And, yeah, what you were saying about implementation details falling away, I kind of did that at the beginning of my career a little bit, at least at that syntactic level. So, yeah, I think I'm with you where we all exist at different parts of this framework, I suppose. And that journey could look different for everyone.

+ +

JOËL: So we're talking about ways to be creative at higher levels. And one way that I find has been really fun for me but also really useful has been bringing in dependency graphs as a tool for design. You knew I had to mention dependency graphs.

+ +

STEPHANIE: We got there in the end. [laughter] Cool, go on.

+ +

JOËL: I think it's been really good sometimes in terms of modeling change sets because dependency graphs can be a great tool for that, but also sometimes in terms of trying to understand what the underlying business problem is and how it might translate into code structures where things might be tightly coupled versus not. And so, drawing it out visually is a really powerful design tool.

+ +

And because now I can look at it in two-dimensional space, I can realize, oh, I see something that feels like it's maybe an anti-pattern or might be a problem here. There's a cycle in my graph; maybe we should find a way to break that. Maybe we need to introduce some dependency inversion and break that cycle, and now our graph is acyclic.

+ +

And so I think that's where there can be a lot of creativity that happens, even when you're not writing code at that point. You're just sort of talking about how different pieces of the project or even different subproblems...you're not even talking about if they're implemented in code, but just saying this subproblem is related to this subproblem, and maybe I would like to find a way for them to not have a connection to each other.

+ +

STEPHANIE: I'm glad we got back to this dependency graph topic because I stumbled upon something that I'm curious to hear your opinion on. I have been following Julia Evans' work for a little bit now. And she recently released a new zine about debugging. And at the end of the zine, she includes a link to these choose-your-own adventure puzzles that she has created, specifically to teach you about debugging and how to do it.

+ +

And so it's basically a little detective game, and you kind of follow along with this bug. And she gives you some different options about how would you like to find a little bit more information about this bug? And what approach would you take? And you make some different selections, and then as you go, you get more information about the bug. And that helps inform what next steps you might take.

+ +

And, one, I think this is a great example of a creative project about software development, even though it's not necessarily your day-to-day work. But then she also uses a tool called Twine, which is for creating non-linear stories, or puzzles, or games. And it got me really thinking about the multi-step wizard we've been talking about and this idea of looking at a problem in different mediums.

+ +

It also reminds me of if you have a designer on your team and they're doing prototyping, they usually have some kind of user interactivity that they have to codify. And they are making those decisions about okay, like, if you are at this step, then where do you go next? And those are all things that you've talked about doing as a developer, I think, at a later point in the future lifecycle. And I'm now just kind of thinking about how to integrate some of that into our workflow. Do you have any thoughts about that?

+ +

JOËL: I had one of the coolest experiences in my career when I was doing a front-end project where we were building a typeahead component that was pulling data from a remote server and then populating a drop-down. And the designer and I sat down and just started to look through all the different states that you could be and how you could move from one to another.

+ +

So it looked like maybe you start the typeahead is empty; it's just a text box. And then as you start typing, maybe there's a spinner that shows up. And then maybe you have some results, or maybe you don't have results. And those are two different entirely states that you could be in. And then, if you backspace, what happens? And what if something goes wrong on the server? Like, we just kept finding all these edge cases.

+ +

And we built out a diagram of all the possible journeys that someone could take, starting from that empty text box, all the way to either some sort of error state or a final state where you've selected an item. But, of course, these are not necessarily terminal because in an error state, maybe you can just start typing again, and you sort of jump back into the beginning of the flow.

+ +

So we did this whole diagram that ended up looking very much like a finite-state machine. We didn't use the term, but that's kind of what it ended up being. And I think we both learned a lot about the problem we were trying to solve and the user experience we were trying to create through that.

+ +

There was just a lot of back and forth of, like, oh, did you think about what would happen if we get no results here? Have we thought about that state? Or it's like, okay, so now we're in an error state. What do we do? Is there a way to get out of it, or are we just kind of stuck? Oh, you can backspace. Okay, what happens then?

+ +

STEPHANIE: Yeah, I mean, we've been talking about creativity as a solitary process. But I think that that goes to show that when collaborating with other people, too, that process can also be very fun and creative and fulfill that need outside of the way the code is written.

+ +

JOËL: In many ways, I think working with somebody else, and that gets made at the intersection of two or more people's work, is probably the most creative way to build software.

+ +

STEPHANIE: That actually reminds me of a book I read last year called "Tomorrow, and Tomorrow, and Tomorrow." And it's about these two friends and their journey creating video games together. And it kind of follows several decades of their life and their relationship, and their creative and collaborative process. And I really loved that book. It was very good, especially if you like video games. There are a lot of great references to that too.

+ +

But I think what you were saying about that fulfillment that you can get with working with other people, and that book does a really good job examining that and getting into our need as humans for that type of collaboration. So that's my little book rec. It goes back to our conversation about designing a game. Again, maybe this is [laughs] what we'll do next. Who knows? The world's our oyster.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+zMctcAsQ + + ]]> + + Joël Quenneville + Stephanie Minn + + + 369: Most Impactful Articles of 2022 + https://bikeshed.thoughtbot.com/369 + 03bd3015-9caf-4f26-813c-5a9233b8c318 + Tue, 31 Jan 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël has been pondering another tool for thought from Maggie Appleton: diagramming. What does drawing complex things reveal? Stephanie has updates on how Soup Group went, plus a clarification from last week's episode re: hexagons and tessellation. + +They also share the top most impactful articles they read in 2022. + 50:23 + no + + + Joël has been pondering another tool for thought from Maggie Appleton: diagramming. What does drawing complex things reveal? Stephanie has updates on how Soup Group went, plus a clarification from last week's episode re: hexagons and tessellation. +They also share the top most impactful articles they read in 2022. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Maggie Appleton tools for thought (https://maggieappleton.com/tools-for-thought) +Squint test (https://www.youtube.com/watch?v=8bZh5LMaSmE&themeRefresh=1) +Cardinality of types (https://guide.elm-lang.org/appendix/types_as_sets.html) +Honeycomb hexagon construction (https://www.nature.com/articles/srep28341) +Coachability (https://cate.blog/2021/02/22/coachability/) +Strangler Fig Pattern (https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) +Finding time to refactor (https://thoughtbot.com/blog/finding-the-time-to-refactor) +Parse don't validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) +Errors cluster around boundaries (https://thoughtbot.com/blog/debugging-at-the-boundaries) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot that has basically become a two-person book club between me and Joël. [laughter] +JOËL: I love that. +STEPHANIE: I'm so sorry, I had to. I think we've been sharing so many things we've been reading in the past couple of episodes, and I've been loving it. I think it's a lot of the conversations we have off-air too, and now we're just bringing it on on-air. And I am going to lean into it. [laughs] +JOËL: I like it. +STEPHANIE: So, Joël, what's new in your world? +JOËL: So, in a recent episode, I think it was two episodes ago, you shared an article by Maggie Appleton about tools for thought. And I've kind of been going back to that article a few times in the past few weeks. And I feel like I always see something new. +And one tool for thought that Maggie explicitly mentions in the article is diagramming, and that's something that we've used as an industry for a long time to deal with conditional logic is just writing a flow diagram. And I feel like that's such a useful tool sometimes to move away from code and text into visuals and draw your problem rather than write your problem. +It's often useful either when I'm trying to figure out how to structure some of my own code or when I'm reviewing a PR for somebody else, and something just feels not quite right, but I'm not quite sure what I want to say. And so drawing the problem all of a sudden might give me some insights, might help me identify why does something feel off about this code that I can't quite put into words? +STEPHANIE: What does drawing complex things reveal for you? Is there a time where you were able to see something that you hadn't seen before? +JOËL: One thing I think it can make more obvious is the shape of the problem. When we describe a problem in words, sometimes there's a sense of like, okay, there are two main paths through this problem or something. And then when we do our code, we try to make it DRY, and we try all these things. And it's really hard to see the flow of logic. And we might actually have way more paths through our code than are actually needed by the initial problem definition. +I think we talked about this in a past episode as well, structuring a multi-step form or a wizard. And oftentimes, that is structured way more complex than it needs to be. And you can really see that difference when you draw out a flow diagram, the difference between forcing everything down a single linear flow with a bunch of little independent conditions versus branching up front three or four or five ways, however many steps you have. And then, from there, it's just executing code. +STEPHANIE: I have two thoughts here. Firstly, it's very tragic that this is an audio medium only [laughs] and not also a visual one. Because I think we've joked in the past about when we've, you know, talked about complex problems and branching conditionals and stuff like that, like, oh, like, if only we could show a visual representation to our listeners. [laughs] And secondly, now that makes a lot more sense why there are so many whiteboards just hanging out in offices everywhere. [laughs] +JOËL: We should use them more. It's interesting you mentioned the limitations of an audio format that we have. But even just describing the problem in an audio format is different than implementing it in code. So if I were to describe a problem to you that says, oh, we have a multi-step form that has three different steps to it, in that description, you might initially think, oh, that means I want to branch three ways up front, and then each step will need to do some processing. But if you look at the implementation in the code, maybe whoever coded it, and maybe that's yourself, will have done it totally differently with a lot more branching than just three up front because it's a different medium. +STEPHANIE: That's a really good point. I also remember reading something about how you can reason about how many branches a piece of code might have if you just look at the structure of the lines of code in your editor if you either step away from it and are just looking at the code not really able to see the text itself but just the shape that it makes. If you have some shorter lines and then a handful of longer lines, you might be able to see like, oh, like these are multiple conditionals happening, which I think is kind of related to what you're saying about taking a piece of code and then diagramming it out to really see the different paths. +And I know that that can also be obscured a little bit if you are stylistically using different syntax. Like, if you are using a guard clause to return early, that's a conditional, but it gets a bit hidden from the visual representation than if you had written out the full if statement, for example. +JOËL: I think that's a really interesting distinction that you bring up because a lot of languages provide syntactic sugar for common conditional tasks that we do. And sometimes, that syntactic sugar will almost obfuscate the fact that there is a conditional happening at all, which can be great in a lot of cases. +But when it comes to analyzing and particularly comparing different implementations, a second conversion that I like to do is converting all of the conditional code to some standardized form, and, for me, that's typically just your basic if...elsif...else expressions. And so any fancy Boolean operators we're doing, any safe navigation that we're doing around nil, maybe some inline conditionals, early returns, things like that, all of the implicit elses that are involved as well, putting them all into some normalized form then allows me to compare two implementations with each other. +And sometimes, two approaches that we initially thought were identical, just with different syntax, turned out to have slightly different behavior because maybe one has this sort of implicit branch that the other one doesn't. And by converting to a normalized syntax, all of a sudden, this difference becomes super obvious. +To be clear, this is not something I do necessarily in the actual code that I commit, not necessarily writing everything long-form. But definitely, when I'm trying to think about conditional code or analyzing somebody else's code, I will often convert it to long-form, some normalized shape so that I can then see some things about it that were not obvious in the final form. Or to make a comparison with something else, and then you can compare apples to apples and say, okay, both these approaches that we're considering in normalized form, here's what they look like. There's some difference here that we do care about or don't care about. +STEPHANIE: That's really interesting. I find it very curious that there is a value in having the long-form approach of writing the code out and being able to identify things. But then the end result that we commit might not look like that and be shortened and be kind of, quote, unquote, "polished," or at least condensed with syntactic sugar. And I'm kind of wondering why that might be the case. +JOËL: I think a lot of that will come down to your personal or your company's style guide. Personally, I think I do lean a little bit more towards a slightly more explicit form. But there are plenty of times that I will use syntactic sugar as well, as long as everybody knows what it does. But sometimes, it will come at the cost of other analysis techniques. You had mentioned the squint test earlier, which I believe is a term coined by Sandi Metz. +STEPHANIE: I think it might be. That rings a bell. +JOËL: And that is a benefit that you get by writing explicit conditionals all the time. But sometimes, it is much nicer to write code that is a little bit more terse. And so you have to do the trade-offs there. +STEPHANIE: Yeah, that's a really good point. +JOËL: So that's two of the sort of three formats that I was thinking about for converting conditional code to gain more insight. The other format is honestly a little bit weird. It's almost a stretch. But from my time spent working with the Elm language, I learned how to use its type system, which uses a concept called algebraic data types, or some languages will call these tagged unions, some languages will call these sum types. This concept goes by a lot of different names. +But they're used to define types into model data. But there's a really fun property, which is that you can model conditional code using this as well. And so you can convert executable code into these algebraic data types. And now, you can apply a lot of tools and heuristics that you have from the data modeling world to this conditional code. +STEPHANIE: Do you have a practical example? +JOËL: So a classic thing that data modelers will say is you should make impossible states impossible. So in practice, this means that when you define a type using these algebraic data types, you should not be able to create more distinct values than are actually valid in this particular system. So, for example, if a value is required to always be present for something and there's no way in the system for a value to become not present, then don't allow it to be nullable. +We do something similar when we design a database schema when we put a null false on a column because we know that this will never be null. And so, why allow nulls when you know they should never be there? So it's a similar thing with the types. This sort of analysis that you can do looking at...the fancy term is the types cardinality. I'll link to an article that digs into that for people who are curious. +But that can show you whether a type can represent, let's say, ten possible values, but the domain you're trying to model only has 5. And so when there's that discrepancy, there are five valid values that can be modeled by your type and an additional extra five that are not valid that just kind of shake out from the way you implemented things. So you can take that technique and apply it to a conditional that you've converted to algebraic data type form. And that can help find things like paths through your conditional code that don't line up with the problem that you're trying to solve. +So going back to the example I talked about earlier of a multi-step form with three different steps, that's a problem that should have three paths through your conditional. But depending on your implementation, if it's a bunch of independent if clauses, you might have a bit of a combinatorial explosion. And there might be 25 different paths through that chunk of code. And that means three of them are the ones that your problem wants, and then the extra 22 are things that should quote, unquote, "never happen," but we all know that they eventually will. So that kind of analysis can help maybe give you pointers to the fact that your current structure is not well-suited to the problem that you're trying to solve. +STEPHANIE: I think another database schema example that came to mind for me was using an enum to declare acceptable values for a field. And, yeah, I know exactly what you mean when working with code where you might know, because of the way the business works, that this thing is impossible, and yet, you still have to either end up coding defensively for it or just kind of hold that complexity in your head. And that can lead to some gnarly situations, and it makes debugging down the line a lot more difficult too. +JOËL: It definitely makes it really hard for somebody else to know the original intention of the code when a conditional has more paths through it than there actually are actual paths in the problem you're trying to solve. Because you have to load all of that in your head, and our programmer brains are trained to think about all the edge cases, and what if this condition fires but this other one doesn't? Could that lead to a bug? Is that just a thing that's like, well, but the inputs will never trigger that, so you can ignore it? And if there are no comments to tell you, and if there are comments, then do you trust them? Because it -- +STEPHANIE: Yes. [laughter] I'll just jump in here and say, yeah, I have seen the comments then conflict with the code as well. And so you have these two sources of information that are conflicting with each other, and you have no idea what is true and what's not. +JOËL: So I'm a big fan of structuring conditional code such that the number of unique paths through a set of conditions is the same as the sort of, you might say, logical paths through the problem domain that we haven't added extra paths, just sort of accidentally due to the way we implemented things. +STEPHANIE: Yeah. And now you have three different ways to visualize that information in your head [laughs] with these mental models. +JOËL: Right. So from taking code that is conditional code and then transforming it into one of these other representations, I don't always do all three, but there are tools that I have. And I can gain all sorts of new insights into that code by looking at it through a completely different lens. +STEPHANIE: That's super cool. +JOËL: So the last episode, you had mentioned that you were going to try a soup club. How did that turn out? +STEPHANIE: It turned out great. It was awesome, the inaugural soup group. I had, I think, around eight people total. And I spent...right after work, I went straight to chopping celery [laughs] and onions and just soup prepping. And it was such a good time. I invited a different group of friends than normally come together, and that turned out really well. I think we all kind of had at least one thing in common, which was my goal was just to, you know, have my friends come together and meet new people too. +And we had soup, and we had bread. Someone brought a spiced crispy chickpea appetizer that went really well inside of our ribollita vegetable bean soup. And then I had the perfect amount of leftovers. So after making a really big batch of food and spending quite a long time cooking, I wanted to make sure that everyone had their fill. But it was also pretty nice to have two servings left over that I could toss in the freezer just for me and as a reward for my hard work. +And then it ended up working out really well because I went on vacation last week. And the night we got back home, we were like, "Oh, it's kind of late. What are we going to do for dinner?" And then I got to pull out the leftover soup from my freezer. And it was the perfect coming home from a big trip, and you have nothing in your fridge kind of deal. So it worked out well. +JOËL: I guess that's the advantage of hosting is that you get to keep the leftovers. +STEPHANIE: It's true. +JOËL: You also have to, you know, make the soup. [laughs] +STEPHANIE: Also true. [laughs] But like I said, it wasn't like I had so much soup that I was going to have to eat it every single day for the next week and a half. It was just the amount that I wanted. So I'm excited to keep doing this. I'm hoping to do the next soup group in the next week or two. And then some other folks even offered to host it for next time. So maybe we might experiment with doing a rotating thing. But yeah, it has definitely brought me joy through this winter. +JOËL: That's so lovely. What else has been new in your world? +STEPHANIE: I have a clarification to make from last week's episode. So last week, we were talking about hexagons and tessellation. And we had mentioned that hexagons and triangles were really strong shapes. And we mentioned that, oh yeah, you can see it in the natural world through honeycomb. And I've since learned that bees don't actually build the hexagon shape themselves. +That was something that scientists did think to be true for a little bit, that bees were just geometrically inclined, but it turns out that the accepted theory for how honeycomb gets its shape is that bees build cylindrical cells that later transform into hexagons, which does have a lot of surface area for holding the honey, though the process itself is actually still debated by scientists. +So there's some research that has supported the idea that it's formed through physical forces like the changing temperature of the wax that transforms it from a cylinder shape into a hexagon, though, yeah, apparently, the studies are still a bit inconclusive. And the last scientific paper I read about this, just to really get my facts straight [laughs], they were kind of exploring aspects of bee behavior that led to the hexagons eventually forming because that does require that the cylinders are perfectly the same size and are at least built in a hexagonal pattern, even though the cells themselves are not hexagons. +JOËL: Fascinating. So it sounds like it's either a social thing where the bees do it based off of some behavior. Or if it's a physical thing, it's some sort of like hexagons are a natural equilibrium point that everything kind of trends to, and so as temperature changes, the beehive will naturally trend towards that. +STEPHANIE: Yeah, exactly. I have a good friend who is a beekeeper, so I got to pick her brain a little bit about honeycomb. [laughs] +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So in the past few episodes, we've talked about books we're reading, articles that we're reading. This is kind of turning into the Stephanie and Joël book club. +STEPHANIE: I love it. +JOËL: That got me thinking about things that I've read that were impactful in the past year. So I'm curious for both of us what might be, let's say, the top two or three most impactful articles that you read in 2022. Or maybe to put it another way, what are the top two or three articles that you reference the most in conversations with other people? +STEPHANIE: So listeners might not know this, but I actually joined thoughtbot early last year in February. So I was coming into this new job, and I was so excited to be joining an organization with so many talented developers. And I was really excited to learn from everyone. So I kind of came in with really big goals around my technical growth. And the end of the year just passed, and I got to do a little bit of reflection. And I was quite proud of myself actually for all the things that I had learned and all the ways that I had grown. +And I was reminded of this blog post that I think I had in the back of my mind around "Coachability" by Cate, and she talks about how coaching is different from mentorship. And she provides some really cool mental models for different ways of providing support to your teammates. Let's say mentorship is teaching someone how to swim, and maybe helping someone out with a task might be throwing them a life raft. +Coaching is more like seeing someone in the water, but you are up on a bridge, and you are kind of seeing all of their surroundings. And you are identifying ways that they can help themselves. So maybe there's a branch, a tree branch, a few feet away from them. And can they go grab that tree branch? How can they help themselves? +So I came to this new job at thoughtbot, and I had these really big goals. But I also knew that I wanted to lean on my new co-workers and just be able to not only learn the things that I was really excited to learn but also trust that they had my best interests in mind as well and for them to be able to point out things that could help my career growth. +So the idea of coachability was really interesting to me because I had been coming from a workplace that had a really great feedback culture. But I think this article touches on what to do with feedback in a way that I hadn't seen before. So she also describes being coachable as having two axes, one of them being receptiveness to feedback and the other being actionability in response to feedback. +So receptiveness is when you hear feedback; do you listen to it? Do you work through it? How does that feedback fit into your mental model of your goals and your skills? And then actionability is like, okay, what do you do with that? How do you change your behavior? How do you change the way you approach problems? And those two things in mind were really helpful in terms of understanding how I respond to feedback and how to really make the most of it when I receive it. +Because there are times when I get feedback, and I don't know what to do with it, you know, maybe it just wasn't specific enough. And so, in that sense, I want to work on my actionability and figuring out, okay, someone said that testing would be a really great opportunity for me to learn. But what can I do to learn how to write better tests? And that might involve figuring that out on my own, like, what strategies work for me. Or that might involve asking them, being like, "What do you recommend?" +So yeah, I had this really big year of growth. And I'm excited to keep this mental model in mind when I feel like I might be stuck and I'm not getting the growth that I want and using those axes to kind of determine how to move forward. +JOËL: I think the first thing that comes to mind for me is the episode that you and I did a while back about the value of precise language. For example, you talked about the distinction between coaching and mentorship, which I think in sort of colloquial speech, we kind of use interchangeably. But having them both mean different things, and then being able to talk about those or at least analyze yourself through the lens of those two words, I think, is really valuable and may be helping to drive either insights or actions that you can take. And similarly, this idea of having two different axes for receptiveness versus...was it changeability you said was the other one? +STEPHANIE: Actionability. +JOËL: Actionability, I think, is really helpful when you're feeling stuck because now you can realize, oh, is it because I'm not accepting feedback or not getting good feedback? Or is it that I'm getting feedback, but it's hard to take action on it? So just all of a sudden, having those terms and having that mental model, that framework, I feel like equips me to engage with feedback in a way that is much more powerful than when we kind of used all those terms interchangeably. +STEPHANIE: Yeah, exactly. I think that it's very well understood that feedback is important and having a good feedback culture is really healthy. But I think we don't always talk about the next step, which is what do you do with feedback? And with the help of this article, I've kind of come to realize that all feedback is valuable, but not all of it is good. And she makes a really excellent point of saying that the way you respond to feedback also depends on the relationship you have with the person giving it. +So, ideally, you have a high trust high respect relationship with that person. And so when they give you feedback, you are like, yeah, I'm receptive to this, and I want to do something about it. But sometimes you get feedback from someone, and you might not have that trust in that relationship or that respect. And it just straight up might not be good feedback for you. +And the way you engage with it could be figuring out what part of it is helpful for me and what part of it is not? And if it's not helpful in terms of helping your growth, it might at least be informative. And that might help you learn something about the other person or about the circumstances or environment that you're in. +JOËL: Again, I love the distinction you're making between helpful and informative. +STEPHANIE: Yeah. I think I had to learn that the hard way this year. [laughs] So, yeah, I really hope that folks find this vocabulary or this idea...or consider it when they are thinking about feedback in terms of giving it or receiving it and using it in a way that works for them to grow the way they want to. +JOËL: I'm curious, in your interactions, and learning, and growth over the past year, do you feel like you've leaned a little bit more into the mentorship or the coaching side of things? What would you say is the rough percentage breakdown? Are we talking 50-50, 80-20? +STEPHANIE: That's such a good question. I think I received both this year. But I think I'm at a point in my career where coaching is more valuable to me. And I'm reminded of a time a few months into joining thoughtbot where I was working and pairing with a principal developer. And he was really turning the workaround on me and asking, like, what do I want to do? What do I see in the code? What areas do I want to explore? +And I found it really uncomfortable because I was like, oh, I just want you to tell me what to do because I don't know, or at least at the time, I was really...I found it kind of stressful. But now, looking back on it and with this vocabulary, I'm like, oh, that's what true coaching was because I gained a lot of experience towards my foundational skill set of figuring out how to solve problems or identifying areas of refactoring through that process. +And so sometimes coaching can feel really uncomfortable because you are stretching outside of your comfort zone and that your coach is hopefully supporting you but not just giving you the help but teaching you how to help yourself. +JOËL: That's a really interesting thing to notice. And I think what I'm hearing is that coaching can feel less comfortable than mentoring because you're being asked to do more of the work yourself. And you're maybe being stretched in some ways that aren't exactly the same as you would get in a more mentoring-focused scenario. Does that sound right? +STEPHANIE: Yeah, I think that sounds right because, like I said, I was also receiving mentorship, and I learned about new things. But those didn't always solidify in terms of empowering me next time to be able to do it without the help of someone else. Joël, what was an article that really spoke to you this last year? +JOËL: So I really appreciated an article by Adrianna Chang, who's a developer at Shopify, about "Refactoring Legacy Code with the Strangler Fig Pattern." And it talks about this approach to moving refactoring code from one implementation to another. And it's a longer-ranged process, and how to do so incrementally. And a big theme for me this year has been refactoring and incremental change. +I've had a lot of conversations with people about how to spot smaller steps. I've written an article on working incrementally. And so I think this was really nice because it gave a very particular technique on how to do so with an example. And so, because these sorts of conversations kept coming up this year, I found myself referencing this article all the time. +STEPHANIE: I really loved this article too. And this last year, I also saw a strangler fig tree for the first time in real life in Florida. And I think that was after I had read this article. And it was really cool to make the connection between something I was seeing in nature with a pattern in software development or technique. +JOËL: We have this metaphor, and now you get to see the real thing. I was excited because, at RubyConf Mini this year, I actually got to meet Adrianna. So it was really cool. It's like, "Hey, I've been referencing your article all year. It's super cool to meet you in person." +STEPHANIE: That's awesome. I love that, just being able to support members of the community. What I really liked about the approach this article advocated for is that it allowed developers to continue working. You don't have to halt everything and dedicate time to refactor and not get any new feature work done. And that's the beauty of the incremental approach that you were talking about earlier, where you can continue development. Sometimes that refactoring might be paused for some reason or another, but then you can pick back up where you left off. +And that is really intriguing to me because I think this past year, I was working on a client where refactoring seemed like something we had to dedicate special time for. And it constantly became tough to prioritize and sell to stakeholders. Whereas if you incorporate it into the work and do it in a way that doesn't stop the show [laughs] from going on, it can work really well and work towards sustainability and maintenance, which is another thing that we've talked a lot about on the show. +JOËL: Something that's really powerful, I think, with that technique is that it allows you to have all of the intermediate steps get merged into your main branch and get shipped. So you don't have to have this long-running branch with a big change that's constantly going stale, and you're having to keep in sync with the main branch. And, unfortunately, I've often seen even this sort of thing where you create a long-running branch for a big change, a big refactor, and eventually, it just gets abandoned, and you have not locked in any wins. +STEPHANIE: Yeah, that's the worst of both worlds where you've dedicated time and resources and don't get the benefits of that work. I also liked that the strangler fig pattern kind of forces you to really understand the existing code. I think working with legacy code can be really challenging. And a lot of people don't like to do it because it involves a lot of spelunking and figuring out, okay, what's really going on. +But in order to isolate the pieces to, you know, slowly start to stop making calls to the old code, it requires that you take a hard look at your legacy code and really figure it out. And I honestly think that that then informs the new code that you write to better support both the old feature and also any new features to come. +JOËL: Definitely. The really nice thing about this pattern is that it also scales up and down. You can do this really small...even as part of a feature branch; maybe it's just part of your development process, even if you don't necessarily ship all of the intermediate steps. But it helps you work more incrementally and in a tighter scope. And then you can scale it up as big as changing out entire sections of a framework or...I think Adrianna's example is like switching out a data source. And so you can do some really large refactors. But then you could do it as well on just a small feature. +I really like using this pattern anytime you're doing things like Rails upgrades, and you've got old gems that might not convert over where it's like, oh, the community abandoned this gem between Rails 4 and Rails 5. But now you need sort of a bridge to get over. And so I think that pattern is particularly powerful when doing something like a Rails upgrade. +STEPHANIE: Very Cool. +JOËL: So what would be a second article that was really impactful for you in the past year? +STEPHANIE: So, speaking of refactoring, I really enjoyed a blog post called Finding Time to Refactor by a former thoughtboter, German Velasco. He makes a really great point that we should think of completeness in our work, not just when the code works as expected or meets the product requirements, but also when it is clear and maintainable. And so he really advocates for baking refactoring into just your normal development process. +And like I said, that goes back to this idea that it can be incremental. It doesn't have to be separate or something that we do later, which is kind of what I had learned before coming to thoughtbot. So when I was also speaking about just my technical growth, this shift in philosophy, for me, was a really big part of that. And I just started kind of thinking and seeing ways to just do it in my regular process. And I think that has really helped me to feel better about my work and also see a noticeable improvement in the quality of my code. +So he mentioned the three times that he makes sure to refactor, and that is one when he is practicing TDD and going through the red-green-refactor cycle. +JOËL: It's in the name. +STEPHANIE: [laughs] It really is. Two, when code is difficult to understand, so if he's coming in and fixing a bug and he pays the tax of trying to figure out confusing code, that's a really great opportunity to then reduce that caring cost for others by making it clear while you're in there, so leaving things better than you found it. +And then three, when the existing design doesn't work. We, I think, have mentioned the adage, "Make the change easy, and then make the easy change." So if he's coming in to add a new feature and it's just not quite working, then that's a really good opportunity to refactor the existing design to support this new information or new concept. +JOËL: I like those three scenarios. And I think that second one, in particular, resonated with me, the making things easier to understand. And in the sort of narrower sense of the word refactoring, traditionally, this means changing the structure of the code without changing its behavior. And I once had a situation where I was dealing with a series of early return expressions in a method that were all returning Booleans. And it was really hard because there were some unlesses, some ifs, some weird negation happening. And I just couldn't figure out what this code was doing. +STEPHANIE: Did you draw a diagram? [laughs] +JOËL: I did not. But it turns out this code was untested. And so I pretty much just tried, like, it took two Booleans as inputs and gave back a Boolean. So I just tried all the combinations, put it in, saw what it gave me out, and then wrote tests for them. And then realized that the test cases were telling me that this code was always returning false unless both inputs were true. +And that's when it kind of hits me, it's like, wait a minute, this is Boolean AND. We've reimplemented Boolean AND with this convoluted set of conditional code. And so, at the end there, once I had that test coverage to feel confident, I went in and did a refactor where I changed the implementation. Instead of being...I think it was like three or four inline conditionals, just rewrote it as argument one and argument two, and that was much easier to read. +STEPHANIE: That's a great point. Because the next time someone comes in here, and let's say they have to maybe add another condition or whatever, they're not just tacking on to this really confusing thing. You've hopefully made it easier for them to work with that code. And I also really appreciated, you know, I was mentioning how this article affected my thought process and how I approach development, but it's a really great one to share to then foster a culture of just continuous refactoring, I guess, is what I'm going to call it [laughs] and hopefully, avoiding having to do a massive rewrite or a massive effort to refactor. +The phrase that comes to mind is many hands make light work. And if we all incorporated this into our process, perhaps we would just be working all around with more delightful code. Joël, do you have one more article that really stood out to you this year? +JOËL: One that I think I really connected with this year is "Parse, Don't Validate" by Alexis King. Long-time listeners of the show will have heard me talk about this a little bit with Chris Toomey when he was a guest on the show this past fall. But the gist of the article is that the process of parsing is converting a broader type into a narrower type with the potential for errors. +So traditionally, we think of this as turning a string which a string is very broad. All sorts of things are strings, and then you turn it into something else. So maybe you're parsing JSON. So you take a string of characters and try to turn it into a Ruby hash, but not all strings are valid hashes. So there's also the possibility for errors. And so, JSON.parse() could raise an error in Ruby. +This idea, though, can be then expanded because, ideally, you don't want to just check that a value is valid for your stricter rules. You don't want to just check that a string is valid JSON and then pass the string along to the next person. You actually want to transform it. And then everybody else down the line can interact with that hash and not have to do a check again is this valid JSON? You've already validated that you've already converted it into a hash. You don't need to check that it's valid JSON again because, by the nature of being a hash, it's impossible for it to be invalid. +Now, you might have some extra requirements on that hash. So maybe you require certain keys to be present and things like that. And I think that's where this idea gets even more powerful because then you can kind of layer this on top and have a second parsing step where you say, I'm going to parse this hash into, let's say, a shopping cart object. And so, not all Ruby hashes are valid shopping carts. +And so you try to take a broader value and coerce it into a narrower value or transform it into a narrower value and potentially raise an error for those hashes that are not valid shopping carts. And then, whoever down the line gets a shopping cart object, you can just call items on it. You can call price on it. You don't need to check is this key present? Because now you have that certainty. +STEPHANIE: This reminds me of when I was working with TypeScript in the summer of last year. And having come from a dynamically-typed language background, it was really challenging but also really interesting to me because we were also parsing JSON. But once we had transformed or parsed that data into this domain object, we had a lot more confidence about what we were working in. And all the functions we wrote down the line or used on the line, we could know for sure that, okay, it has these properties about it. And that really shaped the code we wrote. +JOËL: So use the word confident here, which, for me, it's a keyword. And so you can now assume that certain properties are true because it's been checked once. That can be tricky if you don't actually do a transformation. If you're just sort of passing a raw value down, you'll often end up with code that is defensive that keeps rechecking the same conditions over and over. +And you see this lot around nil in Ruby where somebody checks for a value for nil, and then inside that conditional, three or four other conditions deep, we recheck the same value for nil again, even though, in theory, it should not be nil at that point. And so by doing transformations like that, by parsing instead of just validating, we can ensure that we don't have to repeat those conditions. +STEPHANIE: Yeah, I mean, that refers back to the analyzing conditional code that we spent a bit of time talking about at the beginning of this episode. Because I remember in that application, we render different components based on the status of this domain object. And there was a condition for when the status was something that was not expected. +And then someone had left a comment that was like, technically, this should never happen. But I think that he had to add it to appease the compiler. And I think had we been able to better enforce those boundaries, had we been more thoughtful around our domain modeling, we could have figured out how to make sure that we weren't then introducing that ambiguity down the line. +JOËL: I think it's interesting that you immediately went to talking about TypeScript here because TypeScript has a type system. And the "f, Don't Validate" article is written in Haskell, which is another typed language. And types are great for showing you exactly like, here's the boundary. On this side of it, it's a string, and on this side here, it's a richly-typed value that has been parsed. +In Ruby, we don't have that, everything is duck-typed, but I think the principle still applies. It's a little bit more implicit, but there are zones of high or low assumptions about the data. So when I'm interacting directly with raw input from a third-party endpoint, I'm really only expecting some kind of raw string from the body of the response. It may or may not be valid. There are all sorts of checks I need to do to make sure I can do anything with it. So that is a very low assumption zone. +Later on, in the business logic part of the code, I might expect that I can call a method on the object to get the price of a shopping cart or a list of items or something like that. Now I'm in a much higher assumption zone. And being self-aware about where we transition from low assumptions to high assumptions is, I think, a really key takeaway for how we interact with code in Ruby. Because, oftentimes, where that boundary is a little bit fuzzy or where we think it's in one place but it's actually in a different place is where bugs tend to cluster. +STEPHANIE: Do you have any thoughts about how to adhere to those rules that we're making so we're not having to assume in a dynamically-typed language? +JOËL: One way that I think is often helpful is trying to use richer objects and to not just rely on primitives all the time. So don't pass a business process a hash and be just like, trust me, I checked it; it's got the right keys because the day will come when you pass it a malformed hash and now we're going to have an error in the business process. +And now we have a dilemma because do we want to start adding defensive checks in the business process to be like, oh, are all our keys that we expect present, things like that? Do we need to elsewhere in the code make sure we process the hash correctly? It becomes a little bit messy. And so, oftentimes, it might be better to say, don't pass a raw hash around. Create a domain object that has the actual method that you want, and pass that instead. +STEPHANIE: Oh, sounds like a great opportunity to use the new data class in Ruby 3.2 that we talked about in an episode prior. +JOËL: That's a great suggestion. I would definitely reach for something like that, I think, in a situation where I'm trying to model something a little bit richer than just a hash. +STEPHANIE: I also think that there have been more trends around borrowing concepts from functional programming, and especially with the introduction of classes that represent nil or empty states, so instead of just using the default nil, having at least a bit of context around a nil what or an empty what. That then might have methods that either raise an error or just signal that something is wrong with the assumptions that we're making around the flexibility that we get from duck typing. +I'm really glad that you proposed this topic idea for today's episode because it really represented a lot of themes that we have been discussing on the show in the past couple of months. And I am excited to maybe do this again in the future to just capture what's been interesting or inspiring for us throughout the year. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël has been pondering another tool for thought from Maggie Appleton: diagramming. What does drawing complex things reveal? Stephanie has updates on how Soup Group went, plus a clarification from last week's episode re: hexagons and tessellation.

+ +

They also share the top most impactful articles they read in 2022.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot that has basically become a two-person book club between me and Joël. [laughter]

+ +

JOËL: I love that.

+ +

STEPHANIE: I'm so sorry, I had to. I think we've been sharing so many things we've been reading in the past couple of episodes, and I've been loving it. I think it's a lot of the conversations we have off-air too, and now we're just bringing it on on-air. And I am going to lean into it. [laughs]

+ +

JOËL: I like it.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So, in a recent episode, I think it was two episodes ago, you shared an article by Maggie Appleton about tools for thought. And I've kind of been going back to that article a few times in the past few weeks. And I feel like I always see something new.

+ +

And one tool for thought that Maggie explicitly mentions in the article is diagramming, and that's something that we've used as an industry for a long time to deal with conditional logic is just writing a flow diagram. And I feel like that's such a useful tool sometimes to move away from code and text into visuals and draw your problem rather than write your problem.

+ +

It's often useful either when I'm trying to figure out how to structure some of my own code or when I'm reviewing a PR for somebody else, and something just feels not quite right, but I'm not quite sure what I want to say. And so drawing the problem all of a sudden might give me some insights, might help me identify why does something feel off about this code that I can't quite put into words?

+ +

STEPHANIE: What does drawing complex things reveal for you? Is there a time where you were able to see something that you hadn't seen before?

+ +

JOËL: One thing I think it can make more obvious is the shape of the problem. When we describe a problem in words, sometimes there's a sense of like, okay, there are two main paths through this problem or something. And then when we do our code, we try to make it DRY, and we try all these things. And it's really hard to see the flow of logic. And we might actually have way more paths through our code than are actually needed by the initial problem definition.

+ +

I think we talked about this in a past episode as well, structuring a multi-step form or a wizard. And oftentimes, that is structured way more complex than it needs to be. And you can really see that difference when you draw out a flow diagram, the difference between forcing everything down a single linear flow with a bunch of little independent conditions versus branching up front three or four or five ways, however many steps you have. And then, from there, it's just executing code.

+ +

STEPHANIE: I have two thoughts here. Firstly, it's very tragic that this is an audio medium only [laughs] and not also a visual one. Because I think we've joked in the past about when we've, you know, talked about complex problems and branching conditionals and stuff like that, like, oh, like, if only we could show a visual representation to our listeners. [laughs] And secondly, now that makes a lot more sense why there are so many whiteboards just hanging out in offices everywhere. [laughs]

+ +

JOËL: We should use them more. It's interesting you mentioned the limitations of an audio format that we have. But even just describing the problem in an audio format is different than implementing it in code. So if I were to describe a problem to you that says, oh, we have a multi-step form that has three different steps to it, in that description, you might initially think, oh, that means I want to branch three ways up front, and then each step will need to do some processing. But if you look at the implementation in the code, maybe whoever coded it, and maybe that's yourself, will have done it totally differently with a lot more branching than just three up front because it's a different medium.

+ +

STEPHANIE: That's a really good point. I also remember reading something about how you can reason about how many branches a piece of code might have if you just look at the structure of the lines of code in your editor if you either step away from it and are just looking at the code not really able to see the text itself but just the shape that it makes. If you have some shorter lines and then a handful of longer lines, you might be able to see like, oh, like these are multiple conditionals happening, which I think is kind of related to what you're saying about taking a piece of code and then diagramming it out to really see the different paths.

+ +

And I know that that can also be obscured a little bit if you are stylistically using different syntax. Like, if you are using a guard clause to return early, that's a conditional, but it gets a bit hidden from the visual representation than if you had written out the full if statement, for example.

+ +

JOËL: I think that's a really interesting distinction that you bring up because a lot of languages provide syntactic sugar for common conditional tasks that we do. And sometimes, that syntactic sugar will almost obfuscate the fact that there is a conditional happening at all, which can be great in a lot of cases.

+ +

But when it comes to analyzing and particularly comparing different implementations, a second conversion that I like to do is converting all of the conditional code to some standardized form, and, for me, that's typically just your basic if...elsif...else expressions. And so any fancy Boolean operators we're doing, any safe navigation that we're doing around nil, maybe some inline conditionals, early returns, things like that, all of the implicit elses that are involved as well, putting them all into some normalized form then allows me to compare two implementations with each other.

+ +

And sometimes, two approaches that we initially thought were identical, just with different syntax, turned out to have slightly different behavior because maybe one has this sort of implicit branch that the other one doesn't. And by converting to a normalized syntax, all of a sudden, this difference becomes super obvious.

+ +

To be clear, this is not something I do necessarily in the actual code that I commit, not necessarily writing everything long-form. But definitely, when I'm trying to think about conditional code or analyzing somebody else's code, I will often convert it to long-form, some normalized shape so that I can then see some things about it that were not obvious in the final form. Or to make a comparison with something else, and then you can compare apples to apples and say, okay, both these approaches that we're considering in normalized form, here's what they look like. There's some difference here that we do care about or don't care about.

+ +

STEPHANIE: That's really interesting. I find it very curious that there is a value in having the long-form approach of writing the code out and being able to identify things. But then the end result that we commit might not look like that and be shortened and be kind of, quote, unquote, "polished," or at least condensed with syntactic sugar. And I'm kind of wondering why that might be the case.

+ +

JOËL: I think a lot of that will come down to your personal or your company's style guide. Personally, I think I do lean a little bit more towards a slightly more explicit form. But there are plenty of times that I will use syntactic sugar as well, as long as everybody knows what it does. But sometimes, it will come at the cost of other analysis techniques. You had mentioned the squint test earlier, which I believe is a term coined by Sandi Metz.

+ +

STEPHANIE: I think it might be. That rings a bell.

+ +

JOËL: And that is a benefit that you get by writing explicit conditionals all the time. But sometimes, it is much nicer to write code that is a little bit more terse. And so you have to do the trade-offs there.

+ +

STEPHANIE: Yeah, that's a really good point.

+ +

JOËL: So that's two of the sort of three formats that I was thinking about for converting conditional code to gain more insight. The other format is honestly a little bit weird. It's almost a stretch. But from my time spent working with the Elm language, I learned how to use its type system, which uses a concept called algebraic data types, or some languages will call these tagged unions, some languages will call these sum types. This concept goes by a lot of different names.

+ +

But they're used to define types into model data. But there's a really fun property, which is that you can model conditional code using this as well. And so you can convert executable code into these algebraic data types. And now, you can apply a lot of tools and heuristics that you have from the data modeling world to this conditional code.

+ +

STEPHANIE: Do you have a practical example?

+ +

JOËL: So a classic thing that data modelers will say is you should make impossible states impossible. So in practice, this means that when you define a type using these algebraic data types, you should not be able to create more distinct values than are actually valid in this particular system. So, for example, if a value is required to always be present for something and there's no way in the system for a value to become not present, then don't allow it to be nullable.

+ +

We do something similar when we design a database schema when we put a null false on a column because we know that this will never be null. And so, why allow nulls when you know they should never be there? So it's a similar thing with the types. This sort of analysis that you can do looking at...the fancy term is the types cardinality. I'll link to an article that digs into that for people who are curious.

+ +

But that can show you whether a type can represent, let's say, ten possible values, but the domain you're trying to model only has 5. And so when there's that discrepancy, there are five valid values that can be modeled by your type and an additional extra five that are not valid that just kind of shake out from the way you implemented things. So you can take that technique and apply it to a conditional that you've converted to algebraic data type form. And that can help find things like paths through your conditional code that don't line up with the problem that you're trying to solve.

+ +

So going back to the example I talked about earlier of a multi-step form with three different steps, that's a problem that should have three paths through your conditional. But depending on your implementation, if it's a bunch of independent if clauses, you might have a bit of a combinatorial explosion. And there might be 25 different paths through that chunk of code. And that means three of them are the ones that your problem wants, and then the extra 22 are things that should quote, unquote, "never happen," but we all know that they eventually will. So that kind of analysis can help maybe give you pointers to the fact that your current structure is not well-suited to the problem that you're trying to solve.

+ +

STEPHANIE: I think another database schema example that came to mind for me was using an enum to declare acceptable values for a field. And, yeah, I know exactly what you mean when working with code where you might know, because of the way the business works, that this thing is impossible, and yet, you still have to either end up coding defensively for it or just kind of hold that complexity in your head. And that can lead to some gnarly situations, and it makes debugging down the line a lot more difficult too.

+ +

JOËL: It definitely makes it really hard for somebody else to know the original intention of the code when a conditional has more paths through it than there actually are actual paths in the problem you're trying to solve. Because you have to load all of that in your head, and our programmer brains are trained to think about all the edge cases, and what if this condition fires but this other one doesn't? Could that lead to a bug? Is that just a thing that's like, well, but the inputs will never trigger that, so you can ignore it? And if there are no comments to tell you, and if there are comments, then do you trust them? Because it --

+ +

STEPHANIE: Yes. [laughter] I'll just jump in here and say, yeah, I have seen the comments then conflict with the code as well. And so you have these two sources of information that are conflicting with each other, and you have no idea what is true and what's not.

+ +

JOËL: So I'm a big fan of structuring conditional code such that the number of unique paths through a set of conditions is the same as the sort of, you might say, logical paths through the problem domain that we haven't added extra paths, just sort of accidentally due to the way we implemented things.

+ +

STEPHANIE: Yeah. And now you have three different ways to visualize that information in your head [laughs] with these mental models.

+ +

JOËL: Right. So from taking code that is conditional code and then transforming it into one of these other representations, I don't always do all three, but there are tools that I have. And I can gain all sorts of new insights into that code by looking at it through a completely different lens.

+ +

STEPHANIE: That's super cool.

+ +

JOËL: So the last episode, you had mentioned that you were going to try a soup club. How did that turn out?

+ +

STEPHANIE: It turned out great. It was awesome, the inaugural soup group. I had, I think, around eight people total. And I spent...right after work, I went straight to chopping celery [laughs] and onions and just soup prepping. And it was such a good time. I invited a different group of friends than normally come together, and that turned out really well. I think we all kind of had at least one thing in common, which was my goal was just to, you know, have my friends come together and meet new people too.

+ +

And we had soup, and we had bread. Someone brought a spiced crispy chickpea appetizer that went really well inside of our ribollita vegetable bean soup. And then I had the perfect amount of leftovers. So after making a really big batch of food and spending quite a long time cooking, I wanted to make sure that everyone had their fill. But it was also pretty nice to have two servings left over that I could toss in the freezer just for me and as a reward for my hard work.

+ +

And then it ended up working out really well because I went on vacation last week. And the night we got back home, we were like, "Oh, it's kind of late. What are we going to do for dinner?" And then I got to pull out the leftover soup from my freezer. And it was the perfect coming home from a big trip, and you have nothing in your fridge kind of deal. So it worked out well.

+ +

JOËL: I guess that's the advantage of hosting is that you get to keep the leftovers.

+ +

STEPHANIE: It's true.

+ +

JOËL: You also have to, you know, make the soup. [laughs]

+ +

STEPHANIE: Also true. [laughs] But like I said, it wasn't like I had so much soup that I was going to have to eat it every single day for the next week and a half. It was just the amount that I wanted. So I'm excited to keep doing this. I'm hoping to do the next soup group in the next week or two. And then some other folks even offered to host it for next time. So maybe we might experiment with doing a rotating thing. But yeah, it has definitely brought me joy through this winter.

+ +

JOËL: That's so lovely. What else has been new in your world?

+ +

STEPHANIE: I have a clarification to make from last week's episode. So last week, we were talking about hexagons and tessellation. And we had mentioned that hexagons and triangles were really strong shapes. And we mentioned that, oh yeah, you can see it in the natural world through honeycomb. And I've since learned that bees don't actually build the hexagon shape themselves.

+ +

That was something that scientists did think to be true for a little bit, that bees were just geometrically inclined, but it turns out that the accepted theory for how honeycomb gets its shape is that bees build cylindrical cells that later transform into hexagons, which does have a lot of surface area for holding the honey, though the process itself is actually still debated by scientists.

+ +

So there's some research that has supported the idea that it's formed through physical forces like the changing temperature of the wax that transforms it from a cylinder shape into a hexagon, though, yeah, apparently, the studies are still a bit inconclusive. And the last scientific paper I read about this, just to really get my facts straight [laughs], they were kind of exploring aspects of bee behavior that led to the hexagons eventually forming because that does require that the cylinders are perfectly the same size and are at least built in a hexagonal pattern, even though the cells themselves are not hexagons.

+ +

JOËL: Fascinating. So it sounds like it's either a social thing where the bees do it based off of some behavior. Or if it's a physical thing, it's some sort of like hexagons are a natural equilibrium point that everything kind of trends to, and so as temperature changes, the beehive will naturally trend towards that.

+ +

STEPHANIE: Yeah, exactly. I have a good friend who is a beekeeper, so I got to pick her brain a little bit about honeycomb. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So in the past few episodes, we've talked about books we're reading, articles that we're reading. This is kind of turning into the Stephanie and Joël book club.

+ +

STEPHANIE: I love it.

+ +

JOËL: That got me thinking about things that I've read that were impactful in the past year. So I'm curious for both of us what might be, let's say, the top two or three most impactful articles that you read in 2022. Or maybe to put it another way, what are the top two or three articles that you reference the most in conversations with other people?

+ +

STEPHANIE: So listeners might not know this, but I actually joined thoughtbot early last year in February. So I was coming into this new job, and I was so excited to be joining an organization with so many talented developers. And I was really excited to learn from everyone. So I kind of came in with really big goals around my technical growth. And the end of the year just passed, and I got to do a little bit of reflection. And I was quite proud of myself actually for all the things that I had learned and all the ways that I had grown.

+ +

And I was reminded of this blog post that I think I had in the back of my mind around "Coachability" by Cate, and she talks about how coaching is different from mentorship. And she provides some really cool mental models for different ways of providing support to your teammates. Let's say mentorship is teaching someone how to swim, and maybe helping someone out with a task might be throwing them a life raft.

+ +

Coaching is more like seeing someone in the water, but you are up on a bridge, and you are kind of seeing all of their surroundings. And you are identifying ways that they can help themselves. So maybe there's a branch, a tree branch, a few feet away from them. And can they go grab that tree branch? How can they help themselves?

+ +

So I came to this new job at thoughtbot, and I had these really big goals. But I also knew that I wanted to lean on my new co-workers and just be able to not only learn the things that I was really excited to learn but also trust that they had my best interests in mind as well and for them to be able to point out things that could help my career growth.

+ +

So the idea of coachability was really interesting to me because I had been coming from a workplace that had a really great feedback culture. But I think this article touches on what to do with feedback in a way that I hadn't seen before. So she also describes being coachable as having two axes, one of them being receptiveness to feedback and the other being actionability in response to feedback.

+ +

So receptiveness is when you hear feedback; do you listen to it? Do you work through it? How does that feedback fit into your mental model of your goals and your skills? And then actionability is like, okay, what do you do with that? How do you change your behavior? How do you change the way you approach problems? And those two things in mind were really helpful in terms of understanding how I respond to feedback and how to really make the most of it when I receive it.

+ +

Because there are times when I get feedback, and I don't know what to do with it, you know, maybe it just wasn't specific enough. And so, in that sense, I want to work on my actionability and figuring out, okay, someone said that testing would be a really great opportunity for me to learn. But what can I do to learn how to write better tests? And that might involve figuring that out on my own, like, what strategies work for me. Or that might involve asking them, being like, "What do you recommend?"

+ +

So yeah, I had this really big year of growth. And I'm excited to keep this mental model in mind when I feel like I might be stuck and I'm not getting the growth that I want and using those axes to kind of determine how to move forward.

+ +

JOËL: I think the first thing that comes to mind for me is the episode that you and I did a while back about the value of precise language. For example, you talked about the distinction between coaching and mentorship, which I think in sort of colloquial speech, we kind of use interchangeably. But having them both mean different things, and then being able to talk about those or at least analyze yourself through the lens of those two words, I think, is really valuable and may be helping to drive either insights or actions that you can take. And similarly, this idea of having two different axes for receptiveness versus...was it changeability you said was the other one?

+ +

STEPHANIE: Actionability.

+ +

JOËL: Actionability, I think, is really helpful when you're feeling stuck because now you can realize, oh, is it because I'm not accepting feedback or not getting good feedback? Or is it that I'm getting feedback, but it's hard to take action on it? So just all of a sudden, having those terms and having that mental model, that framework, I feel like equips me to engage with feedback in a way that is much more powerful than when we kind of used all those terms interchangeably.

+ +

STEPHANIE: Yeah, exactly. I think that it's very well understood that feedback is important and having a good feedback culture is really healthy. But I think we don't always talk about the next step, which is what do you do with feedback? And with the help of this article, I've kind of come to realize that all feedback is valuable, but not all of it is good. And she makes a really excellent point of saying that the way you respond to feedback also depends on the relationship you have with the person giving it.

+ +

So, ideally, you have a high trust high respect relationship with that person. And so when they give you feedback, you are like, yeah, I'm receptive to this, and I want to do something about it. But sometimes you get feedback from someone, and you might not have that trust in that relationship or that respect. And it just straight up might not be good feedback for you.

+ +

And the way you engage with it could be figuring out what part of it is helpful for me and what part of it is not? And if it's not helpful in terms of helping your growth, it might at least be informative. And that might help you learn something about the other person or about the circumstances or environment that you're in.

+ +

JOËL: Again, I love the distinction you're making between helpful and informative.

+ +

STEPHANIE: Yeah. I think I had to learn that the hard way this year. [laughs] So, yeah, I really hope that folks find this vocabulary or this idea...or consider it when they are thinking about feedback in terms of giving it or receiving it and using it in a way that works for them to grow the way they want to.

+ +

JOËL: I'm curious, in your interactions, and learning, and growth over the past year, do you feel like you've leaned a little bit more into the mentorship or the coaching side of things? What would you say is the rough percentage breakdown? Are we talking 50-50, 80-20?

+ +

STEPHANIE: That's such a good question. I think I received both this year. But I think I'm at a point in my career where coaching is more valuable to me. And I'm reminded of a time a few months into joining thoughtbot where I was working and pairing with a principal developer. And he was really turning the workaround on me and asking, like, what do I want to do? What do I see in the code? What areas do I want to explore?

+ +

And I found it really uncomfortable because I was like, oh, I just want you to tell me what to do because I don't know, or at least at the time, I was really...I found it kind of stressful. But now, looking back on it and with this vocabulary, I'm like, oh, that's what true coaching was because I gained a lot of experience towards my foundational skill set of figuring out how to solve problems or identifying areas of refactoring through that process.

+ +

And so sometimes coaching can feel really uncomfortable because you are stretching outside of your comfort zone and that your coach is hopefully supporting you but not just giving you the help but teaching you how to help yourself.

+ +

JOËL: That's a really interesting thing to notice. And I think what I'm hearing is that coaching can feel less comfortable than mentoring because you're being asked to do more of the work yourself. And you're maybe being stretched in some ways that aren't exactly the same as you would get in a more mentoring-focused scenario. Does that sound right?

+ +

STEPHANIE: Yeah, I think that sounds right because, like I said, I was also receiving mentorship, and I learned about new things. But those didn't always solidify in terms of empowering me next time to be able to do it without the help of someone else. Joël, what was an article that really spoke to you this last year?

+ +

JOËL: So I really appreciated an article by Adrianna Chang, who's a developer at Shopify, about "Refactoring Legacy Code with the Strangler Fig Pattern." And it talks about this approach to moving refactoring code from one implementation to another. And it's a longer-ranged process, and how to do so incrementally. And a big theme for me this year has been refactoring and incremental change.

+ +

I've had a lot of conversations with people about how to spot smaller steps. I've written an article on working incrementally. And so I think this was really nice because it gave a very particular technique on how to do so with an example. And so, because these sorts of conversations kept coming up this year, I found myself referencing this article all the time.

+ +

STEPHANIE: I really loved this article too. And this last year, I also saw a strangler fig tree for the first time in real life in Florida. And I think that was after I had read this article. And it was really cool to make the connection between something I was seeing in nature with a pattern in software development or technique.

+ +

JOËL: We have this metaphor, and now you get to see the real thing. I was excited because, at RubyConf Mini this year, I actually got to meet Adrianna. So it was really cool. It's like, "Hey, I've been referencing your article all year. It's super cool to meet you in person."

+ +

STEPHANIE: That's awesome. I love that, just being able to support members of the community. What I really liked about the approach this article advocated for is that it allowed developers to continue working. You don't have to halt everything and dedicate time to refactor and not get any new feature work done. And that's the beauty of the incremental approach that you were talking about earlier, where you can continue development. Sometimes that refactoring might be paused for some reason or another, but then you can pick back up where you left off.

+ +

And that is really intriguing to me because I think this past year, I was working on a client where refactoring seemed like something we had to dedicate special time for. And it constantly became tough to prioritize and sell to stakeholders. Whereas if you incorporate it into the work and do it in a way that doesn't stop the show [laughs] from going on, it can work really well and work towards sustainability and maintenance, which is another thing that we've talked a lot about on the show.

+ +

JOËL: Something that's really powerful, I think, with that technique is that it allows you to have all of the intermediate steps get merged into your main branch and get shipped. So you don't have to have this long-running branch with a big change that's constantly going stale, and you're having to keep in sync with the main branch. And, unfortunately, I've often seen even this sort of thing where you create a long-running branch for a big change, a big refactor, and eventually, it just gets abandoned, and you have not locked in any wins.

+ +

STEPHANIE: Yeah, that's the worst of both worlds where you've dedicated time and resources and don't get the benefits of that work. I also liked that the strangler fig pattern kind of forces you to really understand the existing code. I think working with legacy code can be really challenging. And a lot of people don't like to do it because it involves a lot of spelunking and figuring out, okay, what's really going on.

+ +

But in order to isolate the pieces to, you know, slowly start to stop making calls to the old code, it requires that you take a hard look at your legacy code and really figure it out. And I honestly think that that then informs the new code that you write to better support both the old feature and also any new features to come.

+ +

JOËL: Definitely. The really nice thing about this pattern is that it also scales up and down. You can do this really small...even as part of a feature branch; maybe it's just part of your development process, even if you don't necessarily ship all of the intermediate steps. But it helps you work more incrementally and in a tighter scope. And then you can scale it up as big as changing out entire sections of a framework or...I think Adrianna's example is like switching out a data source. And so you can do some really large refactors. But then you could do it as well on just a small feature.

+ +

I really like using this pattern anytime you're doing things like Rails upgrades, and you've got old gems that might not convert over where it's like, oh, the community abandoned this gem between Rails 4 and Rails 5. But now you need sort of a bridge to get over. And so I think that pattern is particularly powerful when doing something like a Rails upgrade.

+ +

STEPHANIE: Very Cool.

+ +

JOËL: So what would be a second article that was really impactful for you in the past year?

+ +

STEPHANIE: So, speaking of refactoring, I really enjoyed a blog post called Finding Time to Refactor by a former thoughtboter, German Velasco. He makes a really great point that we should think of completeness in our work, not just when the code works as expected or meets the product requirements, but also when it is clear and maintainable. And so he really advocates for baking refactoring into just your normal development process.

+ +

And like I said, that goes back to this idea that it can be incremental. It doesn't have to be separate or something that we do later, which is kind of what I had learned before coming to thoughtbot. So when I was also speaking about just my technical growth, this shift in philosophy, for me, was a really big part of that. And I just started kind of thinking and seeing ways to just do it in my regular process. And I think that has really helped me to feel better about my work and also see a noticeable improvement in the quality of my code.

+ +

So he mentioned the three times that he makes sure to refactor, and that is one when he is practicing TDD and going through the red-green-refactor cycle.

+ +

JOËL: It's in the name.

+ +

STEPHANIE: [laughs] It really is. Two, when code is difficult to understand, so if he's coming in and fixing a bug and he pays the tax of trying to figure out confusing code, that's a really great opportunity to then reduce that caring cost for others by making it clear while you're in there, so leaving things better than you found it.

+ +

And then three, when the existing design doesn't work. We, I think, have mentioned the adage, "Make the change easy, and then make the easy change." So if he's coming in to add a new feature and it's just not quite working, then that's a really good opportunity to refactor the existing design to support this new information or new concept.

+ +

JOËL: I like those three scenarios. And I think that second one, in particular, resonated with me, the making things easier to understand. And in the sort of narrower sense of the word refactoring, traditionally, this means changing the structure of the code without changing its behavior. And I once had a situation where I was dealing with a series of early return expressions in a method that were all returning Booleans. And it was really hard because there were some unlesses, some ifs, some weird negation happening. And I just couldn't figure out what this code was doing.

+ +

STEPHANIE: Did you draw a diagram? [laughs]

+ +

JOËL: I did not. But it turns out this code was untested. And so I pretty much just tried, like, it took two Booleans as inputs and gave back a Boolean. So I just tried all the combinations, put it in, saw what it gave me out, and then wrote tests for them. And then realized that the test cases were telling me that this code was always returning false unless both inputs were true.

+ +

And that's when it kind of hits me, it's like, wait a minute, this is Boolean AND. We've reimplemented Boolean AND with this convoluted set of conditional code. And so, at the end there, once I had that test coverage to feel confident, I went in and did a refactor where I changed the implementation. Instead of being...I think it was like three or four inline conditionals, just rewrote it as argument one and argument two, and that was much easier to read.

+ +

STEPHANIE: That's a great point. Because the next time someone comes in here, and let's say they have to maybe add another condition or whatever, they're not just tacking on to this really confusing thing. You've hopefully made it easier for them to work with that code. And I also really appreciated, you know, I was mentioning how this article affected my thought process and how I approach development, but it's a really great one to share to then foster a culture of just continuous refactoring, I guess, is what I'm going to call it [laughs] and hopefully, avoiding having to do a massive rewrite or a massive effort to refactor.

+ +

The phrase that comes to mind is many hands make light work. And if we all incorporated this into our process, perhaps we would just be working all around with more delightful code. Joël, do you have one more article that really stood out to you this year?

+ +

JOËL: One that I think I really connected with this year is "Parse, Don't Validate" by Alexis King. Long-time listeners of the show will have heard me talk about this a little bit with Chris Toomey when he was a guest on the show this past fall. But the gist of the article is that the process of parsing is converting a broader type into a narrower type with the potential for errors.

+ +

So traditionally, we think of this as turning a string which a string is very broad. All sorts of things are strings, and then you turn it into something else. So maybe you're parsing JSON. So you take a string of characters and try to turn it into a Ruby hash, but not all strings are valid hashes. So there's also the possibility for errors. And so, JSON.parse() could raise an error in Ruby.

+ +

This idea, though, can be then expanded because, ideally, you don't want to just check that a value is valid for your stricter rules. You don't want to just check that a string is valid JSON and then pass the string along to the next person. You actually want to transform it. And then everybody else down the line can interact with that hash and not have to do a check again is this valid JSON? You've already validated that you've already converted it into a hash. You don't need to check that it's valid JSON again because, by the nature of being a hash, it's impossible for it to be invalid.

+ +

Now, you might have some extra requirements on that hash. So maybe you require certain keys to be present and things like that. And I think that's where this idea gets even more powerful because then you can kind of layer this on top and have a second parsing step where you say, I'm going to parse this hash into, let's say, a shopping cart object. And so, not all Ruby hashes are valid shopping carts.

+ +

And so you try to take a broader value and coerce it into a narrower value or transform it into a narrower value and potentially raise an error for those hashes that are not valid shopping carts. And then, whoever down the line gets a shopping cart object, you can just call items on it. You can call price on it. You don't need to check is this key present? Because now you have that certainty.

+ +

STEPHANIE: This reminds me of when I was working with TypeScript in the summer of last year. And having come from a dynamically-typed language background, it was really challenging but also really interesting to me because we were also parsing JSON. But once we had transformed or parsed that data into this domain object, we had a lot more confidence about what we were working in. And all the functions we wrote down the line or used on the line, we could know for sure that, okay, it has these properties about it. And that really shaped the code we wrote.

+ +

JOËL: So use the word confident here, which, for me, it's a keyword. And so you can now assume that certain properties are true because it's been checked once. That can be tricky if you don't actually do a transformation. If you're just sort of passing a raw value down, you'll often end up with code that is defensive that keeps rechecking the same conditions over and over.

+ +

And you see this lot around nil in Ruby where somebody checks for a value for nil, and then inside that conditional, three or four other conditions deep, we recheck the same value for nil again, even though, in theory, it should not be nil at that point. And so by doing transformations like that, by parsing instead of just validating, we can ensure that we don't have to repeat those conditions.

+ +

STEPHANIE: Yeah, I mean, that refers back to the analyzing conditional code that we spent a bit of time talking about at the beginning of this episode. Because I remember in that application, we render different components based on the status of this domain object. And there was a condition for when the status was something that was not expected.

+ +

And then someone had left a comment that was like, technically, this should never happen. But I think that he had to add it to appease the compiler. And I think had we been able to better enforce those boundaries, had we been more thoughtful around our domain modeling, we could have figured out how to make sure that we weren't then introducing that ambiguity down the line.

+ +

JOËL: I think it's interesting that you immediately went to talking about TypeScript here because TypeScript has a type system. And the "f, Don't Validate" article is written in Haskell, which is another typed language. And types are great for showing you exactly like, here's the boundary. On this side of it, it's a string, and on this side here, it's a richly-typed value that has been parsed.

+ +

In Ruby, we don't have that, everything is duck-typed, but I think the principle still applies. It's a little bit more implicit, but there are zones of high or low assumptions about the data. So when I'm interacting directly with raw input from a third-party endpoint, I'm really only expecting some kind of raw string from the body of the response. It may or may not be valid. There are all sorts of checks I need to do to make sure I can do anything with it. So that is a very low assumption zone.

+ +

Later on, in the business logic part of the code, I might expect that I can call a method on the object to get the price of a shopping cart or a list of items or something like that. Now I'm in a much higher assumption zone. And being self-aware about where we transition from low assumptions to high assumptions is, I think, a really key takeaway for how we interact with code in Ruby. Because, oftentimes, where that boundary is a little bit fuzzy or where we think it's in one place but it's actually in a different place is where bugs tend to cluster.

+ +

STEPHANIE: Do you have any thoughts about how to adhere to those rules that we're making so we're not having to assume in a dynamically-typed language?

+ +

JOËL: One way that I think is often helpful is trying to use richer objects and to not just rely on primitives all the time. So don't pass a business process a hash and be just like, trust me, I checked it; it's got the right keys because the day will come when you pass it a malformed hash and now we're going to have an error in the business process.

+ +

And now we have a dilemma because do we want to start adding defensive checks in the business process to be like, oh, are all our keys that we expect present, things like that? Do we need to elsewhere in the code make sure we process the hash correctly? It becomes a little bit messy. And so, oftentimes, it might be better to say, don't pass a raw hash around. Create a domain object that has the actual method that you want, and pass that instead.

+ +

STEPHANIE: Oh, sounds like a great opportunity to use the new data class in Ruby 3.2 that we talked about in an episode prior.

+ +

JOËL: That's a great suggestion. I would definitely reach for something like that, I think, in a situation where I'm trying to model something a little bit richer than just a hash.

+ +

STEPHANIE: I also think that there have been more trends around borrowing concepts from functional programming, and especially with the introduction of classes that represent nil or empty states, so instead of just using the default nil, having at least a bit of context around a nil what or an empty what. That then might have methods that either raise an error or just signal that something is wrong with the assumptions that we're making around the flexibility that we get from duck typing.

+ +

I'm really glad that you proposed this topic idea for today's episode because it really represented a lot of themes that we have been discussing on the show in the past couple of months. And I am excited to maybe do this again in the future to just capture what's been interesting or inspiring for us throughout the year.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël has been pondering another tool for thought from Maggie Appleton: diagramming. What does drawing complex things reveal? Stephanie has updates on how Soup Group went, plus a clarification from last week's episode re: hexagons and tessellation.

+ +

They also share the top most impactful articles they read in 2022.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot that has basically become a two-person book club between me and Joël. [laughter]

+ +

JOËL: I love that.

+ +

STEPHANIE: I'm so sorry, I had to. I think we've been sharing so many things we've been reading in the past couple of episodes, and I've been loving it. I think it's a lot of the conversations we have off-air too, and now we're just bringing it on on-air. And I am going to lean into it. [laughs]

+ +

JOËL: I like it.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So, in a recent episode, I think it was two episodes ago, you shared an article by Maggie Appleton about tools for thought. And I've kind of been going back to that article a few times in the past few weeks. And I feel like I always see something new.

+ +

And one tool for thought that Maggie explicitly mentions in the article is diagramming, and that's something that we've used as an industry for a long time to deal with conditional logic is just writing a flow diagram. And I feel like that's such a useful tool sometimes to move away from code and text into visuals and draw your problem rather than write your problem.

+ +

It's often useful either when I'm trying to figure out how to structure some of my own code or when I'm reviewing a PR for somebody else, and something just feels not quite right, but I'm not quite sure what I want to say. And so drawing the problem all of a sudden might give me some insights, might help me identify why does something feel off about this code that I can't quite put into words?

+ +

STEPHANIE: What does drawing complex things reveal for you? Is there a time where you were able to see something that you hadn't seen before?

+ +

JOËL: One thing I think it can make more obvious is the shape of the problem. When we describe a problem in words, sometimes there's a sense of like, okay, there are two main paths through this problem or something. And then when we do our code, we try to make it DRY, and we try all these things. And it's really hard to see the flow of logic. And we might actually have way more paths through our code than are actually needed by the initial problem definition.

+ +

I think we talked about this in a past episode as well, structuring a multi-step form or a wizard. And oftentimes, that is structured way more complex than it needs to be. And you can really see that difference when you draw out a flow diagram, the difference between forcing everything down a single linear flow with a bunch of little independent conditions versus branching up front three or four or five ways, however many steps you have. And then, from there, it's just executing code.

+ +

STEPHANIE: I have two thoughts here. Firstly, it's very tragic that this is an audio medium only [laughs] and not also a visual one. Because I think we've joked in the past about when we've, you know, talked about complex problems and branching conditionals and stuff like that, like, oh, like, if only we could show a visual representation to our listeners. [laughs] And secondly, now that makes a lot more sense why there are so many whiteboards just hanging out in offices everywhere. [laughs]

+ +

JOËL: We should use them more. It's interesting you mentioned the limitations of an audio format that we have. But even just describing the problem in an audio format is different than implementing it in code. So if I were to describe a problem to you that says, oh, we have a multi-step form that has three different steps to it, in that description, you might initially think, oh, that means I want to branch three ways up front, and then each step will need to do some processing. But if you look at the implementation in the code, maybe whoever coded it, and maybe that's yourself, will have done it totally differently with a lot more branching than just three up front because it's a different medium.

+ +

STEPHANIE: That's a really good point. I also remember reading something about how you can reason about how many branches a piece of code might have if you just look at the structure of the lines of code in your editor if you either step away from it and are just looking at the code not really able to see the text itself but just the shape that it makes. If you have some shorter lines and then a handful of longer lines, you might be able to see like, oh, like these are multiple conditionals happening, which I think is kind of related to what you're saying about taking a piece of code and then diagramming it out to really see the different paths.

+ +

And I know that that can also be obscured a little bit if you are stylistically using different syntax. Like, if you are using a guard clause to return early, that's a conditional, but it gets a bit hidden from the visual representation than if you had written out the full if statement, for example.

+ +

JOËL: I think that's a really interesting distinction that you bring up because a lot of languages provide syntactic sugar for common conditional tasks that we do. And sometimes, that syntactic sugar will almost obfuscate the fact that there is a conditional happening at all, which can be great in a lot of cases.

+ +

But when it comes to analyzing and particularly comparing different implementations, a second conversion that I like to do is converting all of the conditional code to some standardized form, and, for me, that's typically just your basic if...elsif...else expressions. And so any fancy Boolean operators we're doing, any safe navigation that we're doing around nil, maybe some inline conditionals, early returns, things like that, all of the implicit elses that are involved as well, putting them all into some normalized form then allows me to compare two implementations with each other.

+ +

And sometimes, two approaches that we initially thought were identical, just with different syntax, turned out to have slightly different behavior because maybe one has this sort of implicit branch that the other one doesn't. And by converting to a normalized syntax, all of a sudden, this difference becomes super obvious.

+ +

To be clear, this is not something I do necessarily in the actual code that I commit, not necessarily writing everything long-form. But definitely, when I'm trying to think about conditional code or analyzing somebody else's code, I will often convert it to long-form, some normalized shape so that I can then see some things about it that were not obvious in the final form. Or to make a comparison with something else, and then you can compare apples to apples and say, okay, both these approaches that we're considering in normalized form, here's what they look like. There's some difference here that we do care about or don't care about.

+ +

STEPHANIE: That's really interesting. I find it very curious that there is a value in having the long-form approach of writing the code out and being able to identify things. But then the end result that we commit might not look like that and be shortened and be kind of, quote, unquote, "polished," or at least condensed with syntactic sugar. And I'm kind of wondering why that might be the case.

+ +

JOËL: I think a lot of that will come down to your personal or your company's style guide. Personally, I think I do lean a little bit more towards a slightly more explicit form. But there are plenty of times that I will use syntactic sugar as well, as long as everybody knows what it does. But sometimes, it will come at the cost of other analysis techniques. You had mentioned the squint test earlier, which I believe is a term coined by Sandi Metz.

+ +

STEPHANIE: I think it might be. That rings a bell.

+ +

JOËL: And that is a benefit that you get by writing explicit conditionals all the time. But sometimes, it is much nicer to write code that is a little bit more terse. And so you have to do the trade-offs there.

+ +

STEPHANIE: Yeah, that's a really good point.

+ +

JOËL: So that's two of the sort of three formats that I was thinking about for converting conditional code to gain more insight. The other format is honestly a little bit weird. It's almost a stretch. But from my time spent working with the Elm language, I learned how to use its type system, which uses a concept called algebraic data types, or some languages will call these tagged unions, some languages will call these sum types. This concept goes by a lot of different names.

+ +

But they're used to define types into model data. But there's a really fun property, which is that you can model conditional code using this as well. And so you can convert executable code into these algebraic data types. And now, you can apply a lot of tools and heuristics that you have from the data modeling world to this conditional code.

+ +

STEPHANIE: Do you have a practical example?

+ +

JOËL: So a classic thing that data modelers will say is you should make impossible states impossible. So in practice, this means that when you define a type using these algebraic data types, you should not be able to create more distinct values than are actually valid in this particular system. So, for example, if a value is required to always be present for something and there's no way in the system for a value to become not present, then don't allow it to be nullable.

+ +

We do something similar when we design a database schema when we put a null false on a column because we know that this will never be null. And so, why allow nulls when you know they should never be there? So it's a similar thing with the types. This sort of analysis that you can do looking at...the fancy term is the types cardinality. I'll link to an article that digs into that for people who are curious.

+ +

But that can show you whether a type can represent, let's say, ten possible values, but the domain you're trying to model only has 5. And so when there's that discrepancy, there are five valid values that can be modeled by your type and an additional extra five that are not valid that just kind of shake out from the way you implemented things. So you can take that technique and apply it to a conditional that you've converted to algebraic data type form. And that can help find things like paths through your conditional code that don't line up with the problem that you're trying to solve.

+ +

So going back to the example I talked about earlier of a multi-step form with three different steps, that's a problem that should have three paths through your conditional. But depending on your implementation, if it's a bunch of independent if clauses, you might have a bit of a combinatorial explosion. And there might be 25 different paths through that chunk of code. And that means three of them are the ones that your problem wants, and then the extra 22 are things that should quote, unquote, "never happen," but we all know that they eventually will. So that kind of analysis can help maybe give you pointers to the fact that your current structure is not well-suited to the problem that you're trying to solve.

+ +

STEPHANIE: I think another database schema example that came to mind for me was using an enum to declare acceptable values for a field. And, yeah, I know exactly what you mean when working with code where you might know, because of the way the business works, that this thing is impossible, and yet, you still have to either end up coding defensively for it or just kind of hold that complexity in your head. And that can lead to some gnarly situations, and it makes debugging down the line a lot more difficult too.

+ +

JOËL: It definitely makes it really hard for somebody else to know the original intention of the code when a conditional has more paths through it than there actually are actual paths in the problem you're trying to solve. Because you have to load all of that in your head, and our programmer brains are trained to think about all the edge cases, and what if this condition fires but this other one doesn't? Could that lead to a bug? Is that just a thing that's like, well, but the inputs will never trigger that, so you can ignore it? And if there are no comments to tell you, and if there are comments, then do you trust them? Because it --

+ +

STEPHANIE: Yes. [laughter] I'll just jump in here and say, yeah, I have seen the comments then conflict with the code as well. And so you have these two sources of information that are conflicting with each other, and you have no idea what is true and what's not.

+ +

JOËL: So I'm a big fan of structuring conditional code such that the number of unique paths through a set of conditions is the same as the sort of, you might say, logical paths through the problem domain that we haven't added extra paths, just sort of accidentally due to the way we implemented things.

+ +

STEPHANIE: Yeah. And now you have three different ways to visualize that information in your head [laughs] with these mental models.

+ +

JOËL: Right. So from taking code that is conditional code and then transforming it into one of these other representations, I don't always do all three, but there are tools that I have. And I can gain all sorts of new insights into that code by looking at it through a completely different lens.

+ +

STEPHANIE: That's super cool.

+ +

JOËL: So the last episode, you had mentioned that you were going to try a soup club. How did that turn out?

+ +

STEPHANIE: It turned out great. It was awesome, the inaugural soup group. I had, I think, around eight people total. And I spent...right after work, I went straight to chopping celery [laughs] and onions and just soup prepping. And it was such a good time. I invited a different group of friends than normally come together, and that turned out really well. I think we all kind of had at least one thing in common, which was my goal was just to, you know, have my friends come together and meet new people too.

+ +

And we had soup, and we had bread. Someone brought a spiced crispy chickpea appetizer that went really well inside of our ribollita vegetable bean soup. And then I had the perfect amount of leftovers. So after making a really big batch of food and spending quite a long time cooking, I wanted to make sure that everyone had their fill. But it was also pretty nice to have two servings left over that I could toss in the freezer just for me and as a reward for my hard work.

+ +

And then it ended up working out really well because I went on vacation last week. And the night we got back home, we were like, "Oh, it's kind of late. What are we going to do for dinner?" And then I got to pull out the leftover soup from my freezer. And it was the perfect coming home from a big trip, and you have nothing in your fridge kind of deal. So it worked out well.

+ +

JOËL: I guess that's the advantage of hosting is that you get to keep the leftovers.

+ +

STEPHANIE: It's true.

+ +

JOËL: You also have to, you know, make the soup. [laughs]

+ +

STEPHANIE: Also true. [laughs] But like I said, it wasn't like I had so much soup that I was going to have to eat it every single day for the next week and a half. It was just the amount that I wanted. So I'm excited to keep doing this. I'm hoping to do the next soup group in the next week or two. And then some other folks even offered to host it for next time. So maybe we might experiment with doing a rotating thing. But yeah, it has definitely brought me joy through this winter.

+ +

JOËL: That's so lovely. What else has been new in your world?

+ +

STEPHANIE: I have a clarification to make from last week's episode. So last week, we were talking about hexagons and tessellation. And we had mentioned that hexagons and triangles were really strong shapes. And we mentioned that, oh yeah, you can see it in the natural world through honeycomb. And I've since learned that bees don't actually build the hexagon shape themselves.

+ +

That was something that scientists did think to be true for a little bit, that bees were just geometrically inclined, but it turns out that the accepted theory for how honeycomb gets its shape is that bees build cylindrical cells that later transform into hexagons, which does have a lot of surface area for holding the honey, though the process itself is actually still debated by scientists.

+ +

So there's some research that has supported the idea that it's formed through physical forces like the changing temperature of the wax that transforms it from a cylinder shape into a hexagon, though, yeah, apparently, the studies are still a bit inconclusive. And the last scientific paper I read about this, just to really get my facts straight [laughs], they were kind of exploring aspects of bee behavior that led to the hexagons eventually forming because that does require that the cylinders are perfectly the same size and are at least built in a hexagonal pattern, even though the cells themselves are not hexagons.

+ +

JOËL: Fascinating. So it sounds like it's either a social thing where the bees do it based off of some behavior. Or if it's a physical thing, it's some sort of like hexagons are a natural equilibrium point that everything kind of trends to, and so as temperature changes, the beehive will naturally trend towards that.

+ +

STEPHANIE: Yeah, exactly. I have a good friend who is a beekeeper, so I got to pick her brain a little bit about honeycomb. [laughs]

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So in the past few episodes, we've talked about books we're reading, articles that we're reading. This is kind of turning into the Stephanie and Joël book club.

+ +

STEPHANIE: I love it.

+ +

JOËL: That got me thinking about things that I've read that were impactful in the past year. So I'm curious for both of us what might be, let's say, the top two or three most impactful articles that you read in 2022. Or maybe to put it another way, what are the top two or three articles that you reference the most in conversations with other people?

+ +

STEPHANIE: So listeners might not know this, but I actually joined thoughtbot early last year in February. So I was coming into this new job, and I was so excited to be joining an organization with so many talented developers. And I was really excited to learn from everyone. So I kind of came in with really big goals around my technical growth. And the end of the year just passed, and I got to do a little bit of reflection. And I was quite proud of myself actually for all the things that I had learned and all the ways that I had grown.

+ +

And I was reminded of this blog post that I think I had in the back of my mind around "Coachability" by Cate, and she talks about how coaching is different from mentorship. And she provides some really cool mental models for different ways of providing support to your teammates. Let's say mentorship is teaching someone how to swim, and maybe helping someone out with a task might be throwing them a life raft.

+ +

Coaching is more like seeing someone in the water, but you are up on a bridge, and you are kind of seeing all of their surroundings. And you are identifying ways that they can help themselves. So maybe there's a branch, a tree branch, a few feet away from them. And can they go grab that tree branch? How can they help themselves?

+ +

So I came to this new job at thoughtbot, and I had these really big goals. But I also knew that I wanted to lean on my new co-workers and just be able to not only learn the things that I was really excited to learn but also trust that they had my best interests in mind as well and for them to be able to point out things that could help my career growth.

+ +

So the idea of coachability was really interesting to me because I had been coming from a workplace that had a really great feedback culture. But I think this article touches on what to do with feedback in a way that I hadn't seen before. So she also describes being coachable as having two axes, one of them being receptiveness to feedback and the other being actionability in response to feedback.

+ +

So receptiveness is when you hear feedback; do you listen to it? Do you work through it? How does that feedback fit into your mental model of your goals and your skills? And then actionability is like, okay, what do you do with that? How do you change your behavior? How do you change the way you approach problems? And those two things in mind were really helpful in terms of understanding how I respond to feedback and how to really make the most of it when I receive it.

+ +

Because there are times when I get feedback, and I don't know what to do with it, you know, maybe it just wasn't specific enough. And so, in that sense, I want to work on my actionability and figuring out, okay, someone said that testing would be a really great opportunity for me to learn. But what can I do to learn how to write better tests? And that might involve figuring that out on my own, like, what strategies work for me. Or that might involve asking them, being like, "What do you recommend?"

+ +

So yeah, I had this really big year of growth. And I'm excited to keep this mental model in mind when I feel like I might be stuck and I'm not getting the growth that I want and using those axes to kind of determine how to move forward.

+ +

JOËL: I think the first thing that comes to mind for me is the episode that you and I did a while back about the value of precise language. For example, you talked about the distinction between coaching and mentorship, which I think in sort of colloquial speech, we kind of use interchangeably. But having them both mean different things, and then being able to talk about those or at least analyze yourself through the lens of those two words, I think, is really valuable and may be helping to drive either insights or actions that you can take. And similarly, this idea of having two different axes for receptiveness versus...was it changeability you said was the other one?

+ +

STEPHANIE: Actionability.

+ +

JOËL: Actionability, I think, is really helpful when you're feeling stuck because now you can realize, oh, is it because I'm not accepting feedback or not getting good feedback? Or is it that I'm getting feedback, but it's hard to take action on it? So just all of a sudden, having those terms and having that mental model, that framework, I feel like equips me to engage with feedback in a way that is much more powerful than when we kind of used all those terms interchangeably.

+ +

STEPHANIE: Yeah, exactly. I think that it's very well understood that feedback is important and having a good feedback culture is really healthy. But I think we don't always talk about the next step, which is what do you do with feedback? And with the help of this article, I've kind of come to realize that all feedback is valuable, but not all of it is good. And she makes a really excellent point of saying that the way you respond to feedback also depends on the relationship you have with the person giving it.

+ +

So, ideally, you have a high trust high respect relationship with that person. And so when they give you feedback, you are like, yeah, I'm receptive to this, and I want to do something about it. But sometimes you get feedback from someone, and you might not have that trust in that relationship or that respect. And it just straight up might not be good feedback for you.

+ +

And the way you engage with it could be figuring out what part of it is helpful for me and what part of it is not? And if it's not helpful in terms of helping your growth, it might at least be informative. And that might help you learn something about the other person or about the circumstances or environment that you're in.

+ +

JOËL: Again, I love the distinction you're making between helpful and informative.

+ +

STEPHANIE: Yeah. I think I had to learn that the hard way this year. [laughs] So, yeah, I really hope that folks find this vocabulary or this idea...or consider it when they are thinking about feedback in terms of giving it or receiving it and using it in a way that works for them to grow the way they want to.

+ +

JOËL: I'm curious, in your interactions, and learning, and growth over the past year, do you feel like you've leaned a little bit more into the mentorship or the coaching side of things? What would you say is the rough percentage breakdown? Are we talking 50-50, 80-20?

+ +

STEPHANIE: That's such a good question. I think I received both this year. But I think I'm at a point in my career where coaching is more valuable to me. And I'm reminded of a time a few months into joining thoughtbot where I was working and pairing with a principal developer. And he was really turning the workaround on me and asking, like, what do I want to do? What do I see in the code? What areas do I want to explore?

+ +

And I found it really uncomfortable because I was like, oh, I just want you to tell me what to do because I don't know, or at least at the time, I was really...I found it kind of stressful. But now, looking back on it and with this vocabulary, I'm like, oh, that's what true coaching was because I gained a lot of experience towards my foundational skill set of figuring out how to solve problems or identifying areas of refactoring through that process.

+ +

And so sometimes coaching can feel really uncomfortable because you are stretching outside of your comfort zone and that your coach is hopefully supporting you but not just giving you the help but teaching you how to help yourself.

+ +

JOËL: That's a really interesting thing to notice. And I think what I'm hearing is that coaching can feel less comfortable than mentoring because you're being asked to do more of the work yourself. And you're maybe being stretched in some ways that aren't exactly the same as you would get in a more mentoring-focused scenario. Does that sound right?

+ +

STEPHANIE: Yeah, I think that sounds right because, like I said, I was also receiving mentorship, and I learned about new things. But those didn't always solidify in terms of empowering me next time to be able to do it without the help of someone else. Joël, what was an article that really spoke to you this last year?

+ +

JOËL: So I really appreciated an article by Adrianna Chang, who's a developer at Shopify, about "Refactoring Legacy Code with the Strangler Fig Pattern." And it talks about this approach to moving refactoring code from one implementation to another. And it's a longer-ranged process, and how to do so incrementally. And a big theme for me this year has been refactoring and incremental change.

+ +

I've had a lot of conversations with people about how to spot smaller steps. I've written an article on working incrementally. And so I think this was really nice because it gave a very particular technique on how to do so with an example. And so, because these sorts of conversations kept coming up this year, I found myself referencing this article all the time.

+ +

STEPHANIE: I really loved this article too. And this last year, I also saw a strangler fig tree for the first time in real life in Florida. And I think that was after I had read this article. And it was really cool to make the connection between something I was seeing in nature with a pattern in software development or technique.

+ +

JOËL: We have this metaphor, and now you get to see the real thing. I was excited because, at RubyConf Mini this year, I actually got to meet Adrianna. So it was really cool. It's like, "Hey, I've been referencing your article all year. It's super cool to meet you in person."

+ +

STEPHANIE: That's awesome. I love that, just being able to support members of the community. What I really liked about the approach this article advocated for is that it allowed developers to continue working. You don't have to halt everything and dedicate time to refactor and not get any new feature work done. And that's the beauty of the incremental approach that you were talking about earlier, where you can continue development. Sometimes that refactoring might be paused for some reason or another, but then you can pick back up where you left off.

+ +

And that is really intriguing to me because I think this past year, I was working on a client where refactoring seemed like something we had to dedicate special time for. And it constantly became tough to prioritize and sell to stakeholders. Whereas if you incorporate it into the work and do it in a way that doesn't stop the show [laughs] from going on, it can work really well and work towards sustainability and maintenance, which is another thing that we've talked a lot about on the show.

+ +

JOËL: Something that's really powerful, I think, with that technique is that it allows you to have all of the intermediate steps get merged into your main branch and get shipped. So you don't have to have this long-running branch with a big change that's constantly going stale, and you're having to keep in sync with the main branch. And, unfortunately, I've often seen even this sort of thing where you create a long-running branch for a big change, a big refactor, and eventually, it just gets abandoned, and you have not locked in any wins.

+ +

STEPHANIE: Yeah, that's the worst of both worlds where you've dedicated time and resources and don't get the benefits of that work. I also liked that the strangler fig pattern kind of forces you to really understand the existing code. I think working with legacy code can be really challenging. And a lot of people don't like to do it because it involves a lot of spelunking and figuring out, okay, what's really going on.

+ +

But in order to isolate the pieces to, you know, slowly start to stop making calls to the old code, it requires that you take a hard look at your legacy code and really figure it out. And I honestly think that that then informs the new code that you write to better support both the old feature and also any new features to come.

+ +

JOËL: Definitely. The really nice thing about this pattern is that it also scales up and down. You can do this really small...even as part of a feature branch; maybe it's just part of your development process, even if you don't necessarily ship all of the intermediate steps. But it helps you work more incrementally and in a tighter scope. And then you can scale it up as big as changing out entire sections of a framework or...I think Adrianna's example is like switching out a data source. And so you can do some really large refactors. But then you could do it as well on just a small feature.

+ +

I really like using this pattern anytime you're doing things like Rails upgrades, and you've got old gems that might not convert over where it's like, oh, the community abandoned this gem between Rails 4 and Rails 5. But now you need sort of a bridge to get over. And so I think that pattern is particularly powerful when doing something like a Rails upgrade.

+ +

STEPHANIE: Very Cool.

+ +

JOËL: So what would be a second article that was really impactful for you in the past year?

+ +

STEPHANIE: So, speaking of refactoring, I really enjoyed a blog post called Finding Time to Refactor by a former thoughtboter, German Velasco. He makes a really great point that we should think of completeness in our work, not just when the code works as expected or meets the product requirements, but also when it is clear and maintainable. And so he really advocates for baking refactoring into just your normal development process.

+ +

And like I said, that goes back to this idea that it can be incremental. It doesn't have to be separate or something that we do later, which is kind of what I had learned before coming to thoughtbot. So when I was also speaking about just my technical growth, this shift in philosophy, for me, was a really big part of that. And I just started kind of thinking and seeing ways to just do it in my regular process. And I think that has really helped me to feel better about my work and also see a noticeable improvement in the quality of my code.

+ +

So he mentioned the three times that he makes sure to refactor, and that is one when he is practicing TDD and going through the red-green-refactor cycle.

+ +

JOËL: It's in the name.

+ +

STEPHANIE: [laughs] It really is. Two, when code is difficult to understand, so if he's coming in and fixing a bug and he pays the tax of trying to figure out confusing code, that's a really great opportunity to then reduce that caring cost for others by making it clear while you're in there, so leaving things better than you found it.

+ +

And then three, when the existing design doesn't work. We, I think, have mentioned the adage, "Make the change easy, and then make the easy change." So if he's coming in to add a new feature and it's just not quite working, then that's a really good opportunity to refactor the existing design to support this new information or new concept.

+ +

JOËL: I like those three scenarios. And I think that second one, in particular, resonated with me, the making things easier to understand. And in the sort of narrower sense of the word refactoring, traditionally, this means changing the structure of the code without changing its behavior. And I once had a situation where I was dealing with a series of early return expressions in a method that were all returning Booleans. And it was really hard because there were some unlesses, some ifs, some weird negation happening. And I just couldn't figure out what this code was doing.

+ +

STEPHANIE: Did you draw a diagram? [laughs]

+ +

JOËL: I did not. But it turns out this code was untested. And so I pretty much just tried, like, it took two Booleans as inputs and gave back a Boolean. So I just tried all the combinations, put it in, saw what it gave me out, and then wrote tests for them. And then realized that the test cases were telling me that this code was always returning false unless both inputs were true.

+ +

And that's when it kind of hits me, it's like, wait a minute, this is Boolean AND. We've reimplemented Boolean AND with this convoluted set of conditional code. And so, at the end there, once I had that test coverage to feel confident, I went in and did a refactor where I changed the implementation. Instead of being...I think it was like three or four inline conditionals, just rewrote it as argument one and argument two, and that was much easier to read.

+ +

STEPHANIE: That's a great point. Because the next time someone comes in here, and let's say they have to maybe add another condition or whatever, they're not just tacking on to this really confusing thing. You've hopefully made it easier for them to work with that code. And I also really appreciated, you know, I was mentioning how this article affected my thought process and how I approach development, but it's a really great one to share to then foster a culture of just continuous refactoring, I guess, is what I'm going to call it [laughs] and hopefully, avoiding having to do a massive rewrite or a massive effort to refactor.

+ +

The phrase that comes to mind is many hands make light work. And if we all incorporated this into our process, perhaps we would just be working all around with more delightful code. Joël, do you have one more article that really stood out to you this year?

+ +

JOËL: One that I think I really connected with this year is "Parse, Don't Validate" by Alexis King. Long-time listeners of the show will have heard me talk about this a little bit with Chris Toomey when he was a guest on the show this past fall. But the gist of the article is that the process of parsing is converting a broader type into a narrower type with the potential for errors.

+ +

So traditionally, we think of this as turning a string which a string is very broad. All sorts of things are strings, and then you turn it into something else. So maybe you're parsing JSON. So you take a string of characters and try to turn it into a Ruby hash, but not all strings are valid hashes. So there's also the possibility for errors. And so, JSON.parse() could raise an error in Ruby.

+ +

This idea, though, can be then expanded because, ideally, you don't want to just check that a value is valid for your stricter rules. You don't want to just check that a string is valid JSON and then pass the string along to the next person. You actually want to transform it. And then everybody else down the line can interact with that hash and not have to do a check again is this valid JSON? You've already validated that you've already converted it into a hash. You don't need to check that it's valid JSON again because, by the nature of being a hash, it's impossible for it to be invalid.

+ +

Now, you might have some extra requirements on that hash. So maybe you require certain keys to be present and things like that. And I think that's where this idea gets even more powerful because then you can kind of layer this on top and have a second parsing step where you say, I'm going to parse this hash into, let's say, a shopping cart object. And so, not all Ruby hashes are valid shopping carts.

+ +

And so you try to take a broader value and coerce it into a narrower value or transform it into a narrower value and potentially raise an error for those hashes that are not valid shopping carts. And then, whoever down the line gets a shopping cart object, you can just call items on it. You can call price on it. You don't need to check is this key present? Because now you have that certainty.

+ +

STEPHANIE: This reminds me of when I was working with TypeScript in the summer of last year. And having come from a dynamically-typed language background, it was really challenging but also really interesting to me because we were also parsing JSON. But once we had transformed or parsed that data into this domain object, we had a lot more confidence about what we were working in. And all the functions we wrote down the line or used on the line, we could know for sure that, okay, it has these properties about it. And that really shaped the code we wrote.

+ +

JOËL: So use the word confident here, which, for me, it's a keyword. And so you can now assume that certain properties are true because it's been checked once. That can be tricky if you don't actually do a transformation. If you're just sort of passing a raw value down, you'll often end up with code that is defensive that keeps rechecking the same conditions over and over.

+ +

And you see this lot around nil in Ruby where somebody checks for a value for nil, and then inside that conditional, three or four other conditions deep, we recheck the same value for nil again, even though, in theory, it should not be nil at that point. And so by doing transformations like that, by parsing instead of just validating, we can ensure that we don't have to repeat those conditions.

+ +

STEPHANIE: Yeah, I mean, that refers back to the analyzing conditional code that we spent a bit of time talking about at the beginning of this episode. Because I remember in that application, we render different components based on the status of this domain object. And there was a condition for when the status was something that was not expected.

+ +

And then someone had left a comment that was like, technically, this should never happen. But I think that he had to add it to appease the compiler. And I think had we been able to better enforce those boundaries, had we been more thoughtful around our domain modeling, we could have figured out how to make sure that we weren't then introducing that ambiguity down the line.

+ +

JOËL: I think it's interesting that you immediately went to talking about TypeScript here because TypeScript has a type system. And the "f, Don't Validate" article is written in Haskell, which is another typed language. And types are great for showing you exactly like, here's the boundary. On this side of it, it's a string, and on this side here, it's a richly-typed value that has been parsed.

+ +

In Ruby, we don't have that, everything is duck-typed, but I think the principle still applies. It's a little bit more implicit, but there are zones of high or low assumptions about the data. So when I'm interacting directly with raw input from a third-party endpoint, I'm really only expecting some kind of raw string from the body of the response. It may or may not be valid. There are all sorts of checks I need to do to make sure I can do anything with it. So that is a very low assumption zone.

+ +

Later on, in the business logic part of the code, I might expect that I can call a method on the object to get the price of a shopping cart or a list of items or something like that. Now I'm in a much higher assumption zone. And being self-aware about where we transition from low assumptions to high assumptions is, I think, a really key takeaway for how we interact with code in Ruby. Because, oftentimes, where that boundary is a little bit fuzzy or where we think it's in one place but it's actually in a different place is where bugs tend to cluster.

+ +

STEPHANIE: Do you have any thoughts about how to adhere to those rules that we're making so we're not having to assume in a dynamically-typed language?

+ +

JOËL: One way that I think is often helpful is trying to use richer objects and to not just rely on primitives all the time. So don't pass a business process a hash and be just like, trust me, I checked it; it's got the right keys because the day will come when you pass it a malformed hash and now we're going to have an error in the business process.

+ +

And now we have a dilemma because do we want to start adding defensive checks in the business process to be like, oh, are all our keys that we expect present, things like that? Do we need to elsewhere in the code make sure we process the hash correctly? It becomes a little bit messy. And so, oftentimes, it might be better to say, don't pass a raw hash around. Create a domain object that has the actual method that you want, and pass that instead.

+ +

STEPHANIE: Oh, sounds like a great opportunity to use the new data class in Ruby 3.2 that we talked about in an episode prior.

+ +

JOËL: That's a great suggestion. I would definitely reach for something like that, I think, in a situation where I'm trying to model something a little bit richer than just a hash.

+ +

STEPHANIE: I also think that there have been more trends around borrowing concepts from functional programming, and especially with the introduction of classes that represent nil or empty states, so instead of just using the default nil, having at least a bit of context around a nil what or an empty what. That then might have methods that either raise an error or just signal that something is wrong with the assumptions that we're making around the flexibility that we get from duck typing.

+ +

I'm really glad that you proposed this topic idea for today's episode because it really represented a lot of themes that we have been discussing on the show in the past couple of months. And I am excited to maybe do this again in the future to just capture what's been interesting or inspiring for us throughout the year.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thank you so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+LguNWtjo + + ]]> + + Joël Quenneville + Stephanie Minn + + + 368: Sustainable Web Development + https://bikeshed.thoughtbot.com/368 + 7d552f85-2113-4eb1-875d-163e1807b6cd + Tue, 24 Jan 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie talks about hosting a "Soup Group"! Joël got nerd-sniped during the last episode and dove deeper into Maggie Appleton's "Tools for Thought." + +Stephanie has been thinking a lot about Sustainable Web Development. What is sustainability? How does it relate to tech and what we do? + 36:03 + no + + + Stephanie talks about hosting a Soup Group! Joël got nerd-sniped during the last episode and dove deeper into Maggie Appleton's "Tools for Thought." +Stephanie has been thinking a lot about Sustainable Web Development. What is sustainability? How does it relate to tech and what we do? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Maggie Appleton's Tools for Thought (https://maggieappleton.com/tools-for-thought) +Tangrams (https://en.wikipedia.org/wiki/Tangram) +Tessellation (https://en.wikipedia.org/wiki/Tessellation) +Hexagons are the Bestagons (https://www.youtube.com/watch?v=thOifuHs6eY) +Sustainable Web Development with Ruby on Rails (https://sustainable-rails.com/) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +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: I'm excited to share a winter survival idea for folks out there who are, like me, in a very cold place where all your friends don't want to hang out [laughs] and bear the cold temperatures of deep winter in January. Because tonight, I'm hosting my first soup group where I'm basically just going to make a really big batch of soup and have my friends come over with bread, and we're going to eat soup and bread and be cozy. +And I'm really excited because I was trying to figure out a way to combat the winter blues a little bit. And, yeah, I think this time of year can be really tough after the holidays to get people together again. At least for me, I was feeling like I haven't seen my friends in so long. And I was like, well, I could just be the person to take the initiative [laughs] and be like, "Come over to our place." +And the goal is to eventually do this regularly and just have this low-stakes open invitation for anyone to come and show up however they want to. It doesn't have to be, like, big pressure or anything. And if they can't make it at any one time, then there will hopefully be one in the future where they can make it, so I'm excited. After this, I am going to make soup for ten people, and it's going to be great. [laughs] +JOËL: I love this idea. Soup on a cold day is just the coziest thing. +STEPHANIE: Yeah, exactly. I definitely wanted to just make people feel warm and cozy. And that's what I want, so I'm really doing this for myself. [laughs] +JOËL: And you know the advantage of hosting is you don't have to go outside. +STEPHANIE: Yeah, that's the real thing is I'm probably going to kick everyone out at like 11:00 p.m. and then go straight to bed, and it's going to be great. [laughs] +JOËL: Have you been experimenting with a particular kind of soup recently? Are you going to bring out an old favorite? +STEPHANIE: Yeah, I'm excited to make ribollita today, so kind of like a Tuscan style of veggie hearty soup. And I've just been bookmarking soup recipes left and right. [laughs] And I've outsourced the bread situation. So I'm excited to see what kind of bread people bring. And yeah, it'll be very fun and kind of surprising in a comforting way. +JOËL: I'm not familiar with this soup. It's ribollita you said? +STEPHANIE: Yeah, that's it. +JOËL: You said it's a vegetable soup. +STEPHANIE: Yeah, mostly veggies and beans. So I have this giant cabbage, a lot of kale, multiple cans of Great Northern white beans, and they're all going to get mixed together. And we'll see how it turns out. I'll update the podcast on how the soup group goes. It is the inaugural one. So I can't think of a time that I made that much soup before. So, hopefully, it goes well. We'll find out. So, Joël, what about you? What's new in your world? +JOËL: So, in the previous episode, we talked a little bit about some of the things you had learned about note-taking. And you'd mentioned an article by, I think, Maggie Applebon -- +STEPHANIE: Maggie Appleton. +JOËL: Appleton...on tools for thought. It was linked in the show notes of that episode. And I went back and read that article, and it was so good, particularly the section, I think, on historical tools for thought and how they, over time, were sort of groundbreaking in helping us to either remember things or to think about problems or ideas in a different way, or to sort of interrogate those ideas and see if we think they're true or helpful. And these were things like writing or the number system but even some more fancy things like the scientific method for the Cartesian coordinate system. +STEPHANIE: Yeah, I was really excited to share this with you because I think it was the intersection of a lot of your different interests, including note-taking, diagrams, history, and human cognition, so I'm glad that you found it interesting. +JOËL: I definitely got nerd-sniped there. +STEPHANIE: [laughs] +JOËL: I think one thing that really struck me was the power of having multiple different representations for ideas. And one that jumped out at me was the Cartesian coordinate system, which, among other things, a really powerful tool that gave people...when this was invented, it allowed you to convert algebra problems into geometry problems. +And so now, something that used to be an equation you can draw as a triangle or something. And we know how to find the area of a triangle. That's been known since the ancient Greeks and even earlier. And so now a problem that sounded hard is now easy, or at least we have a different way to think about that problem. Because if this equation is equivalent to a triangle, what does that mean? +And vice versa, you can use this to convert geometry problems into algebra problems. And so sometimes the power of a new tool for thought might be in that it allows you to sort of convert between two other existing ways of representing things. And making those connections, all of a sudden gives you a whole new way of thinking about things. That blew my mind. +STEPHANIE: Yeah, I agree. I think the other really cool thing is that a lot of these ideas that humans are discovering also already existed in the natural world. So when you are talking about math, you can see representations of math in plants and nature, and I was reminded of how honeycomb from bees is one of the strongest shapes. And yeah, it's really neat to draw inspiration from a lot of places and learn from things that, like, figured it out before we did. +JOËL: Have you seen the video on YouTube called "Hexagons are the Bestagons?" +STEPHANIE: No, I have not. Tell me more. +JOËL: It's a video on YouTube. We can link it in the show notes. Basically, the hexagon shows up everywhere in nature in part because it has a lot of really fun mathematical properties. It's one of the few shapes that you can use to completely cover a surface. So if you want to subdivide a two-dimensional surface into smaller shapes without leaving any empty spaces between them, you really don't have that many options. +I want to say it's like squares and triangles and hexagons are the only shapes that can do that. And hexagons have these really fun properties around strength. They also are one of the best balances between volume versus the amount of material that it takes to give you that volume and for strength and things like that. So it's good for honeycombs because you can store a lot of honey for very little amount of wax. But it's also good for all sorts of structural engineering because you can build things that are very strong yet light because they require very little metal or other material to create them. +STEPHANIE: When you're saying hexagons filling a lot of space, I also thought about how they've become kind of popular in tiles or interior design in kitchens, and bathrooms, and stuff. [laughs] I've definitely seen that trend a bit. [laughs] So that's really cool just to see, like, yeah, this thing in the natural world that we have adopted for other uses. It's really fun. +JOËL: I want to say this idea of taking a 2D space and being able to completely cover it without spaces with a shape is called tessellating a plane. It's a fancy term for it. And if you want to do it with just a single shape, I think there are only like three or four shapes that can do it. +STEPHANIE: That's really interesting because it reminds me of those tessellation puzzles that I used to play with as a kid. Do you know what I'm talking about? +JOËL: You're thinking like a tangram or something different. +STEPHANIE: Yeah, yeah, tangram, that was...oh my gosh, those were fun. Wow, I was learning math as a young child, [laughs] just didn't even know it. +JOËL: Another random fun fact: the logo for the Elm programming language is a tangram. +STEPHANIE: [Gasps] +JOËL: And the community is sort of encouraged to then remix it because the tangram is just a square tessellated out of a bunch of these shapes. But then, if you're building a library or you've got an event or something, the community will take those shapes and remix them into some other shapes that might fit your event. +STEPHANIE: That's really cool. Is it a metaphor for how Elm can be used in different ways? [laughs] +JOËL: I'm not sure about the story behind the logo. We'd have to look that up. +STEPHANIE: That'll be a good adventure for later. [laughs] +JOËL: In...I want to say Moroccan art, but I think it might be broader than just Moroccan. It might be more broadly North African or Moorish or whatever you want to call that. There's a long history of building these tessellations, I think, out of tiles, but maybe other things as well where you're doing it with a variety of shapes. +So you might start...a classic one, I think is an eight-pointed...is it eight, or? I think it's an eight-pointed star, and then you sort of add other shapes around it. And those can create patterns that take a long time to repeat. And there are these beautiful geometric patterns that just keep on going and expanding without necessarily repeating over a lot of space. +STEPHANIE: Whoa. That kind of blows my mind a little bit. It seems so counterintuitive, but then I feel like there are a lot of things in math that are like that as well. +JOËL: So, yeah, I think a classic pattern you might start with something like an eight-pointed star. And then maybe to fill in the spaces around that central star, you might put some squares, and then maybe you put some triangles around that, and you sort of keep trying to fill in. And maybe eventually you get to another eight-pointed star, but it's not always perfectly symmetric. +STEPHANIE: Someone should make a board game or something out of this idea. [laughs] +JOËL: Oooh. +STEPHANIE: I bet there's one that exists. But I'm just thinking about people who like jigsaw puzzles and that being the next level challenge of, like, can you figure out how things fit together without the confines of a little jigsaw shape? [laughs] +JOËL: Right, right. You have a rectangle shape that you have to perfectly fill in with all of these other smaller shapes, and there is a single solution that will work. You have to figure it out. +STEPHANIE: I personally would be very overwhelmed, [laughs] but it sounds fun at the same time. +JOËL: So those are a lot of thoughts that I've been having inspiration reading that article that you shared on a previous episode. Have you been reading anything interesting recently? +STEPHANIE: I have. I'm really excited to talk about this topic because during my investment time this past week, I've been thinking a lot about it, taking a lot of notes in Obsidian, which is a callback to the last episode, and yeah, I'm excited to kind of get into it. So what I've been reading is Sustainable Web Development with Ruby on Rails by ‎David Bryant Copeland. +And I think a lot of fellow thoughtboters have referenced this book or talked a little bit about ideas from this book; at least, I've seen discussion about it in Slack, so that's kind of why I wanted to pick it up. But what really blew my mind was honestly the first chapter where he talks about why he wrote this book and basically what sustainable web development is because it is a little bit, maybe, like a buzzy word. It's like, what is sustainability? How does it relate to tech and what we do? +And he basically gets down to it by saying that the software that we write is sustainable if it continues to meet our needs years into the future or has longevity and continues to be something we can iterate and work on and not feel that pain or friction, and we feel like we want to, and we feel joyful working on this codebase. So that was kind of my interpretation of his definition about sustainability. +JOËL: I love that definition of sustainability about code that can grow and live for a long time. And I feel like that's not a universal value in the tech industry. And on the extreme end of that, you'll have teams that promote the idea that maybe every few years, you should throw out your old codebase and rewrite. I want to say some teams at Google may have done that as a practice for a while, and, of course, then people quote that as a best practice. +To a certain extent, I want to say that's kind of what happens with Basecamp in that there are multiple versions of Basecamp. And I want to say each of those is a fresh Rails app. So there's a sense in which those or that style of development is not sustainable in the definition that you were just giving there. How do you feel about that? +STEPHANIE: I definitely think the industry has a bias towards newness and change. And a lot of people want to pick up the hot, new technology and, like you said, rewrite code, especially when it's become hard to work with. And honestly, I think that could be its whole own episode, rewrites because I think you and I have pretty strong opinions about it. +But I genuinely think that most of our work is, at least, you and I on the Boost team, in particular here at thoughtbot, where we embed on existing client teams, and usually, that means legacy code as well, but I think that the work of development is mostly extending existing code and trying to sustain applications that have users and are working for users. +And I think that that's certainly a value that I wish were highlighted more or were invested in more because sometimes that change or wanting to hop on to do something different or do something new has a lot of consequences that I'm not sure we talk about enough as an industry. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: It's interesting you mentioned the types of projects that we tend to be on. I feel like there are a lot of projects that I've been brought on where my goal, specifically coming onto this project, was to make the software more sustainable for the team. It's very easy to sort of start moving very fast in the beginning with a greenfield app, and then eventually, a lot of your choices catch up to you. +And then, as your team grows and your product grows, it becomes less and less sustainable. And that's often the point in the lifecycle of the product where I might join the team and try to help make things better for them. I love the keyword sustainable. I don't think that's one that I've used a lot, but it's a great label to put on that kind of work. +STEPHANIE: Yeah, I agree. I think what you mentioned earlier, too, about values that, really stuck out to me in this book because it basically says, "This book is for you if you value these three things: sustainability, consistency, and quality." And all of the recommendations and techniques that he then presents in the rest of the book, using Rails, those decisions are recommended with those three values in mind. +And I think, one, those values are personally important to me as a developer. But it also helped me develop some guiding principles around decision-making and provided a lot of clarity around times that I've been on teams where we were doing things that didn't quite align with my values, and I didn't enjoy it. And I couldn't really figure out why. +But now I'm able to see that, oh, perhaps this team or organization was valuing something like speed, or profit, or change, or something like that that I just fundamentally value differently. And that was kind of where my internal friction or contentment or discontentment was coming from when working on these teams. So, yeah, that was really clarifying for me. +JOËL: Would you say, for you, when you talk about these values, that these are fundamental or ultimate values for you when you write code? Or are they values that are a good way to sort of be a means to some other end? You know, for example, sustainability, do you care about sustainability just for its own sake? Or do you care about it because you want a product to be able to live for a long time? You're building for ten years or 20 years or however long you want this project to last. +STEPHANIE: I think the thing with values is that they are really fundamental to a person's identity or belief system. In fact, the definition that I'm kind of working off of here is that values are those fundamental beliefs that drive our actions. And so when you say, like, are values driving how you write code? I think they drive everything. [laughs] +But the point that he makes in this book is like, here's how they drive code and technical decisions. So the book is actually quite specific about technical recommendations that he has in the context of Rails. And it's funny because we're talking pretty abstractly and big picture about values and things like that. But then I think it's because he sets the stage to be like, everything I recommend here is what I believe to be sustainable, and good quality, and consistent. +And just for an example, one of the recommendations he makes is to, when you're kind of setting up a greenfield application, is to use a SQL schema instead of the default ActiveRecord DSL, so using a structure .SQL file. Because, in his eyes, having the flexibility to write SQL and use the most you can with those tools when it comes to database work is more sustainable in the long term than using the DSL that might not have all the tools available to you that SQL does. +And so he kind of gives his reasoning about, like, this is what I recommend, and here's why it contributes to sustainability, in my opinion. And so I have found myself, while I'm reading along, either agreeing, like, oh yeah, I can see his reasoning here, or maybe even disagreeing because I might think about things differently or have other considerations in mind that are more important to me and what sustainability means to me. But what I hopefully want to take away from the framework or understanding of values is evaluating technical decisions that I make based on my values as an individual but, more importantly, the values of the team or organization. +JOËL: I love mental frameworks like that that give you clarity into your own thought processes or how you make decisions moving forward. Sometimes you can look at something that's very concrete. Somebody gives you some advice on maybe structuring your database schema, and that might be helpful in and of itself. But if you came away with a larger thought process, I think that's doubly valuable. +As an aside here, I love this approach to writing where he sort of lays down almost like preconditions for this book. If you don't agree on these values, this book is not going to be very helpful for you. And then also, here are situations where this advice is not going to apply. Now that I've put down all these edge cases for the rest of this book, I'm going to be speaking very decisively; these are the things I recommend and not have to caveat myself all the time. +It's like, yes, I know there are some edge cases where you might not want to do this if it's a one-off script or whatever it is. We've already dealt with all of those upfront. And now, I can be very confident and very direct for the whole rest of the book. And I feel like that's something I struggle with in some of my work sometimes is. I care a lot about nuance, and my audience probably cares about edge cases even more than I do. They probably care too much. +Because I say something that's generally true most of the time, and I know somebody's already thinking about the one edge case where that's not true. And that doesn't matter for the main point I'm trying to make. So it's always a struggle to know when to caveat a statement that I'm making. But if you caveat too much, then you undermine your whole point. And so I like this idea of putting some caveats up front and then just saying, like, now we're in the 80% case. Within the 80% case, these are things I think are true. +STEPHANIE: Yeah, that's a really good point. I agree he is very clear about the intended audience. And so when you read this book, you are either on board because you value the same things he does, or you're not because you are focused and your goals are things that are different from him. So I think it was really helpful to get on the same page, even in a piece of content or in a piece of writing. Because I want to use my time well as a reader, so I want to make sure that what I am consuming makes sense for me, and I will find it worthwhile. +David takes a really strong stance on what quality means. And even though that is a pretty subjective value, he describes it as doing things right the first time and acknowledging the reality that we likely won't have the time to go back and clean things up after they've been shipped. So, on this client project, I found myself wanting to refactor things as part of my process, suggesting different implementations to do things the quote, unquote, "right way," or the best way we could, and not everyone shared that sentiment. +I sometimes got pushback, and that was challenging for me to figure out how I wanted to navigate that situation and what I was willing to let go and what I wasn't. And so I'm curious if you've ever been in a consulting position like that where maybe the team and organization's values were a little bit different from your understanding, or if they just weren't clear at all, and you were driving towards something that seemed very nebulous. +JOËL: I think I've been on both sides of that, both sometimes saying, "Look, we need to maybe slow down," or "Here's a thing that we need to do otherwise that's going to cost us on the longer term. Here's an area where we need to invest in quality today." And sort of on the other side where I'll feel like someone is really pushing an overengineered solution claiming it's going to make life a whole lot better, "If we invest three months upfront today, and maybe in three or four years, it'll pay off if certain things happen," that don't really necessarily line up with the immediate goals. +A lot of this, I think, comes down to understanding the client, and their business, and their goals. Sometimes there is a really important deadline for something that has to happen based on an event in the real world. If you were building software for something that had to do with, let's say, the World Cup, you don't want it shipping in January 2023. That's just pointless. And so you've got to prioritize shipping things. +And sometimes you say, "Okay, well, do we ship a few broken things? Or do we prefer to ship something that's a little bit smaller, more tightly scoped, but that holds well together?" That again, you have to really understand the client, their business, their needs. So I think for me those values of sustainability, quality...I forget what the third one was that you'd mentioned. +STEPHANIE: Consistency. +JOËL: Consistency, yes. They all sort of inform how it's going to mesh with the product I'm working on, the goals of that product. Where's it going in the next three months, six months, 12 months? Where's it coming from? Who's the team that I'm working with? Am I with a team of 300 people that are just committing to the main branch all the time with no tests, and we're constantly fighting regressions? Then sustainability looks very different there than a one other-person team, and we're trying to ship something for the World Cup. +STEPHANIE: Oh yeah, I have a lot of thoughts there too. Because I do agree that it can look different and sometimes shift a little bit depending on the situation. What you were just describing about team makeup that is really interesting to me because, yeah, sustainability can look different for different teams. +If you have, let's say, a lot of earlier career developers on your team, maybe you really want to focus on readability and making sure that they're able to navigate the codebase and figure things out over something like more advanced patterns and skills that will just cause them friction. But maybe you have a team where you all agree that that's what sustainability means to you is choosing those more advanced technical patterns and committing to them and figuring out how to maintain that because it's important to you. +And the other thing that you brought up that is also mentioned in this book is that the more information developers have about the future and direction of the business, the better code we can write. For some reason, I've found myself in situations where I don't know all too much about what we are working towards or what the goals of the business are both in the short term and the long term. And I try to make the best guess I can. +But I think in those scenarios, at least moving forward, I would really like to be better about pushing product folks or leadership to explain to me why we're doing what we're doing, kind of share the information that they have so that we can build the best product that we can. +I think sometimes that information doesn't get shared for some reason. They kind of think that engineers are going to go do their engineer thing, and we'll focus on long-term strategy over here. But yeah, I truly believe that the more information we have, the better quality work we can produce. +JOËL: I 100% agree. And I think that's what we see in a lot of classic agile literature talking about things like cross-functional teams or even the client or the product team should be integrated with the development team. You're all one team working together rather than someone has an idea, and then the technical team executes on it. +We see that also in some of the domain-driven design literature as well, where oftentimes projects start, and you sit down with a subject matter expert, and they just walk you through all of the business aspects. And particularly for the purpose of domain-driven design, you talk about a lot of the terms that make sense for the business. You build up a glossary of terms. I think they call it a ubiquitous language of things that are specific to your business and how does that work on a day-to-day basis. +STEPHANIE: Do you have any strategies for getting more clarity around the work and why you're building it if it's not yet available to you? +JOËL: I think there are sort of two scenarios where you have to do that; one of them that comes up maybe more often for us as consultants is onboarding onto a new client. There's a whole new business that we may know nothing about, and we have to learn a lot of that. And so, as part of the onboarding process, I think it's really valuable to have conversations with people who are not part of the dev team to learn about the business side of things. +On a per-feature basis, if you've already been onboarded on a project, you've been there for a while, it's often good to go back to the person who maybe created a ticket, a product person who's asking for a feature, and ask, "Why? Why do you want this?" Ideally, maybe that's even part of the ticket-creating process because the two teams are more integrated, and product team is like, here's a problem we're trying to solve. Here's what we think would be a solution. Or maybe even just "Here's a business problem. We need a technical solution. Can you do that for us?" +But I've often followed up with people outside of the engineering team to ask follow-up questions. And why are we doing this? And sometimes it's even you have to do like five Whys where it's like, "Oh, we're doing this because we need to do this thing for this customer. They asked for it." And it's like, "Okay, well, why are they asking for that?" "Oh, it's because they have this problem." And why are they having this problem?" And eventually, like, "Oh, I see. Okay." +The real solution has nothing to do with what was asked, and you come up with something that's maybe much tighter scoped or will better solve, and everybody's a winner in that case. But it does require following up. So I guess the short and boring answer is talk to people outside the engineering team. +STEPHANIE: That's a great point. I think the questions that we as engineers ask can drive more clarity to product people as well if we continue to ask those five levels of why in ways that they maybe didn't think about either. We have the opportunity to do that if we want to do our work well, too. That's kind of exciting to me that it isn't just okay, we're handed some work to do, and they've done all of that strategic thinking separately. And having to implement those details, we can kind of start to chip away at what are we really doing here? +And you mentioned talking to people outside of the engineering team. I just was thinking that pairing with non-developers would also be a really great task to do, especially when you get a ticket that's a bit ambiguous and you have questions. And you can always comment on the ticket or whatever and ask your questions. But perhaps there's also a good opportunity to work things through synchronously. In some ways, I think that is a more natural opportunity for that conversation to evolve rather than it being like, okay, I answered these questions, and now I'm going to move on to whatever else I have to do. +JOËL: So you mentioned pairing. It's often good to have someone maybe outside the development team pair with you on a technical thing, but sometimes it's good to flip the script. If you're building especially software for an internal team, it can be really valuable to just shadow one of them for a couple of hours or a day. +I did a project where we were building a tool for an internal sales team. And I had the privilege to shadow a couple of the sales members for a few hours as they're just doing their job. And I'm just asking all the questions like, "Oh, why do you do it that way? And what is the purpose behind this?" And I learned so much about the business by doing that. +STEPHANIE: I love that we took this idea of sustainable development and went beyond just technical design decisions or aspects of how we do our jobs. Because there is so much more that we can do to foster the value of sustainability or whatever other values that you might have, and yeah, I feel really excited to try both these technical strategies from the book and also the collaborative aspects as well. +JOËL: I'm really excited about some of these ideas that are coming up from the book. I think today we basically just talked about the introduction, the idea of sustainability. But I think as maybe you read more in the book, maybe we can do another episode later on talking about some of the more specific technical recommendations, how they relate to sustainability and maybe share some of our thoughts on that. +STEPHANIE: Yeah, I definitely am excited to keep y'all updated on this journey. [laughs] +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. +JOËL: Show notes for this episode can be found at bikeshed.fm. This show has been produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter. Or at hosts@bikeshed.fm via email. +Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Stephanie talks about hosting a Soup Group! Joël got nerd-sniped during the last episode and dove deeper into Maggie Appleton's "Tools for Thought."

+ +

Stephanie has been thinking a lot about Sustainable Web Development. What is sustainability? How does it relate to tech and what we do?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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: I'm excited to share a winter survival idea for folks out there who are, like me, in a very cold place where all your friends don't want to hang out [laughs] and bear the cold temperatures of deep winter in January. Because tonight, I'm hosting my first soup group where I'm basically just going to make a really big batch of soup and have my friends come over with bread, and we're going to eat soup and bread and be cozy.

+ +

And I'm really excited because I was trying to figure out a way to combat the winter blues a little bit. And, yeah, I think this time of year can be really tough after the holidays to get people together again. At least for me, I was feeling like I haven't seen my friends in so long. And I was like, well, I could just be the person to take the initiative [laughs] and be like, "Come over to our place."

+ +

And the goal is to eventually do this regularly and just have this low-stakes open invitation for anyone to come and show up however they want to. It doesn't have to be, like, big pressure or anything. And if they can't make it at any one time, then there will hopefully be one in the future where they can make it, so I'm excited. After this, I am going to make soup for ten people, and it's going to be great. [laughs]

+ +

JOËL: I love this idea. Soup on a cold day is just the coziest thing.

+ +

STEPHANIE: Yeah, exactly. I definitely wanted to just make people feel warm and cozy. And that's what I want, so I'm really doing this for myself. [laughs]

+ +

JOËL: And you know the advantage of hosting is you don't have to go outside.

+ +

STEPHANIE: Yeah, that's the real thing is I'm probably going to kick everyone out at like 11:00 p.m. and then go straight to bed, and it's going to be great. [laughs]

+ +

JOËL: Have you been experimenting with a particular kind of soup recently? Are you going to bring out an old favorite?

+ +

STEPHANIE: Yeah, I'm excited to make ribollita today, so kind of like a Tuscan style of veggie hearty soup. And I've just been bookmarking soup recipes left and right. [laughs] And I've outsourced the bread situation. So I'm excited to see what kind of bread people bring. And yeah, it'll be very fun and kind of surprising in a comforting way.

+ +

JOËL: I'm not familiar with this soup. It's ribollita you said?

+ +

STEPHANIE: Yeah, that's it.

+ +

JOËL: You said it's a vegetable soup.

+ +

STEPHANIE: Yeah, mostly veggies and beans. So I have this giant cabbage, a lot of kale, multiple cans of Great Northern white beans, and they're all going to get mixed together. And we'll see how it turns out. I'll update the podcast on how the soup group goes. It is the inaugural one. So I can't think of a time that I made that much soup before. So, hopefully, it goes well. We'll find out. So, Joël, what about you? What's new in your world?

+ +

JOËL: So, in the previous episode, we talked a little bit about some of the things you had learned about note-taking. And you'd mentioned an article by, I think, Maggie Applebon --

+ +

STEPHANIE: Maggie Appleton.

+ +

JOËL: Appleton...on tools for thought. It was linked in the show notes of that episode. And I went back and read that article, and it was so good, particularly the section, I think, on historical tools for thought and how they, over time, were sort of groundbreaking in helping us to either remember things or to think about problems or ideas in a different way, or to sort of interrogate those ideas and see if we think they're true or helpful. And these were things like writing or the number system but even some more fancy things like the scientific method for the Cartesian coordinate system.

+ +

STEPHANIE: Yeah, I was really excited to share this with you because I think it was the intersection of a lot of your different interests, including note-taking, diagrams, history, and human cognition, so I'm glad that you found it interesting.

+ +

JOËL: I definitely got nerd-sniped there.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I think one thing that really struck me was the power of having multiple different representations for ideas. And one that jumped out at me was the Cartesian coordinate system, which, among other things, a really powerful tool that gave people...when this was invented, it allowed you to convert algebra problems into geometry problems.

+ +

And so now, something that used to be an equation you can draw as a triangle or something. And we know how to find the area of a triangle. That's been known since the ancient Greeks and even earlier. And so now a problem that sounded hard is now easy, or at least we have a different way to think about that problem. Because if this equation is equivalent to a triangle, what does that mean?

+ +

And vice versa, you can use this to convert geometry problems into algebra problems. And so sometimes the power of a new tool for thought might be in that it allows you to sort of convert between two other existing ways of representing things. And making those connections, all of a sudden gives you a whole new way of thinking about things. That blew my mind.

+ +

STEPHANIE: Yeah, I agree. I think the other really cool thing is that a lot of these ideas that humans are discovering also already existed in the natural world. So when you are talking about math, you can see representations of math in plants and nature, and I was reminded of how honeycomb from bees is one of the strongest shapes. And yeah, it's really neat to draw inspiration from a lot of places and learn from things that, like, figured it out before we did.

+ +

JOËL: Have you seen the video on YouTube called "Hexagons are the Bestagons?"

+ +

STEPHANIE: No, I have not. Tell me more.

+ +

JOËL: It's a video on YouTube. We can link it in the show notes. Basically, the hexagon shows up everywhere in nature in part because it has a lot of really fun mathematical properties. It's one of the few shapes that you can use to completely cover a surface. So if you want to subdivide a two-dimensional surface into smaller shapes without leaving any empty spaces between them, you really don't have that many options.

+ +

I want to say it's like squares and triangles and hexagons are the only shapes that can do that. And hexagons have these really fun properties around strength. They also are one of the best balances between volume versus the amount of material that it takes to give you that volume and for strength and things like that. So it's good for honeycombs because you can store a lot of honey for very little amount of wax. But it's also good for all sorts of structural engineering because you can build things that are very strong yet light because they require very little metal or other material to create them.

+ +

STEPHANIE: When you're saying hexagons filling a lot of space, I also thought about how they've become kind of popular in tiles or interior design in kitchens, and bathrooms, and stuff. [laughs] I've definitely seen that trend a bit. [laughs] So that's really cool just to see, like, yeah, this thing in the natural world that we have adopted for other uses. It's really fun.

+ +

JOËL: I want to say this idea of taking a 2D space and being able to completely cover it without spaces with a shape is called tessellating a plane. It's a fancy term for it. And if you want to do it with just a single shape, I think there are only like three or four shapes that can do it.

+ +

STEPHANIE: That's really interesting because it reminds me of those tessellation puzzles that I used to play with as a kid. Do you know what I'm talking about?

+ +

JOËL: You're thinking like a tangram or something different.

+ +

STEPHANIE: Yeah, yeah, tangram, that was...oh my gosh, those were fun. Wow, I was learning math as a young child, [laughs] just didn't even know it.

+ +

JOËL: Another random fun fact: the logo for the Elm programming language is a tangram.

+ +

STEPHANIE: [Gasps]

+ +

JOËL: And the community is sort of encouraged to then remix it because the tangram is just a square tessellated out of a bunch of these shapes. But then, if you're building a library or you've got an event or something, the community will take those shapes and remix them into some other shapes that might fit your event.

+ +

STEPHANIE: That's really cool. Is it a metaphor for how Elm can be used in different ways? [laughs]

+ +

JOËL: I'm not sure about the story behind the logo. We'd have to look that up.

+ +

STEPHANIE: That'll be a good adventure for later. [laughs]

+ +

JOËL: In...I want to say Moroccan art, but I think it might be broader than just Moroccan. It might be more broadly North African or Moorish or whatever you want to call that. There's a long history of building these tessellations, I think, out of tiles, but maybe other things as well where you're doing it with a variety of shapes.

+ +

So you might start...a classic one, I think is an eight-pointed...is it eight, or? I think it's an eight-pointed star, and then you sort of add other shapes around it. And those can create patterns that take a long time to repeat. And there are these beautiful geometric patterns that just keep on going and expanding without necessarily repeating over a lot of space.

+ +

STEPHANIE: Whoa. That kind of blows my mind a little bit. It seems so counterintuitive, but then I feel like there are a lot of things in math that are like that as well.

+ +

JOËL: So, yeah, I think a classic pattern you might start with something like an eight-pointed star. And then maybe to fill in the spaces around that central star, you might put some squares, and then maybe you put some triangles around that, and you sort of keep trying to fill in. And maybe eventually you get to another eight-pointed star, but it's not always perfectly symmetric.

+ +

STEPHANIE: Someone should make a board game or something out of this idea. [laughs]

+ +

JOËL: Oooh.

+ +

STEPHANIE: I bet there's one that exists. But I'm just thinking about people who like jigsaw puzzles and that being the next level challenge of, like, can you figure out how things fit together without the confines of a little jigsaw shape? [laughs]

+ +

JOËL: Right, right. You have a rectangle shape that you have to perfectly fill in with all of these other smaller shapes, and there is a single solution that will work. You have to figure it out.

+ +

STEPHANIE: I personally would be very overwhelmed, [laughs] but it sounds fun at the same time.

+ +

JOËL: So those are a lot of thoughts that I've been having inspiration reading that article that you shared on a previous episode. Have you been reading anything interesting recently?

+ +

STEPHANIE: I have. I'm really excited to talk about this topic because during my investment time this past week, I've been thinking a lot about it, taking a lot of notes in Obsidian, which is a callback to the last episode, and yeah, I'm excited to kind of get into it. So what I've been reading is Sustainable Web Development with Ruby on Rails by ‎David Bryant Copeland.

+ +

And I think a lot of fellow thoughtboters have referenced this book or talked a little bit about ideas from this book; at least, I've seen discussion about it in Slack, so that's kind of why I wanted to pick it up. But what really blew my mind was honestly the first chapter where he talks about why he wrote this book and basically what sustainable web development is because it is a little bit, maybe, like a buzzy word. It's like, what is sustainability? How does it relate to tech and what we do?

+ +

And he basically gets down to it by saying that the software that we write is sustainable if it continues to meet our needs years into the future or has longevity and continues to be something we can iterate and work on and not feel that pain or friction, and we feel like we want to, and we feel joyful working on this codebase. So that was kind of my interpretation of his definition about sustainability.

+ +

JOËL: I love that definition of sustainability about code that can grow and live for a long time. And I feel like that's not a universal value in the tech industry. And on the extreme end of that, you'll have teams that promote the idea that maybe every few years, you should throw out your old codebase and rewrite. I want to say some teams at Google may have done that as a practice for a while, and, of course, then people quote that as a best practice.

+ +

To a certain extent, I want to say that's kind of what happens with Basecamp in that there are multiple versions of Basecamp. And I want to say each of those is a fresh Rails app. So there's a sense in which those or that style of development is not sustainable in the definition that you were just giving there. How do you feel about that?

+ +

STEPHANIE: I definitely think the industry has a bias towards newness and change. And a lot of people want to pick up the hot, new technology and, like you said, rewrite code, especially when it's become hard to work with. And honestly, I think that could be its whole own episode, rewrites because I think you and I have pretty strong opinions about it.

+ +

But I genuinely think that most of our work is, at least, you and I on the Boost team, in particular here at thoughtbot, where we embed on existing client teams, and usually, that means legacy code as well, but I think that the work of development is mostly extending existing code and trying to sustain applications that have users and are working for users.

+ +

And I think that that's certainly a value that I wish were highlighted more or were invested in more because sometimes that change or wanting to hop on to do something different or do something new has a lot of consequences that I'm not sure we talk about enough as an industry.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: It's interesting you mentioned the types of projects that we tend to be on. I feel like there are a lot of projects that I've been brought on where my goal, specifically coming onto this project, was to make the software more sustainable for the team. It's very easy to sort of start moving very fast in the beginning with a greenfield app, and then eventually, a lot of your choices catch up to you.

+ +

And then, as your team grows and your product grows, it becomes less and less sustainable. And that's often the point in the lifecycle of the product where I might join the team and try to help make things better for them. I love the keyword sustainable. I don't think that's one that I've used a lot, but it's a great label to put on that kind of work.

+ +

STEPHANIE: Yeah, I agree. I think what you mentioned earlier, too, about values that, really stuck out to me in this book because it basically says, "This book is for you if you value these three things: sustainability, consistency, and quality." And all of the recommendations and techniques that he then presents in the rest of the book, using Rails, those decisions are recommended with those three values in mind.

+ +

And I think, one, those values are personally important to me as a developer. But it also helped me develop some guiding principles around decision-making and provided a lot of clarity around times that I've been on teams where we were doing things that didn't quite align with my values, and I didn't enjoy it. And I couldn't really figure out why.

+ +

But now I'm able to see that, oh, perhaps this team or organization was valuing something like speed, or profit, or change, or something like that that I just fundamentally value differently. And that was kind of where my internal friction or contentment or discontentment was coming from when working on these teams. So, yeah, that was really clarifying for me.

+ +

JOËL: Would you say, for you, when you talk about these values, that these are fundamental or ultimate values for you when you write code? Or are they values that are a good way to sort of be a means to some other end? You know, for example, sustainability, do you care about sustainability just for its own sake? Or do you care about it because you want a product to be able to live for a long time? You're building for ten years or 20 years or however long you want this project to last.

+ +

STEPHANIE: I think the thing with values is that they are really fundamental to a person's identity or belief system. In fact, the definition that I'm kind of working off of here is that values are those fundamental beliefs that drive our actions. And so when you say, like, are values driving how you write code? I think they drive everything. [laughs]

+ +

But the point that he makes in this book is like, here's how they drive code and technical decisions. So the book is actually quite specific about technical recommendations that he has in the context of Rails. And it's funny because we're talking pretty abstractly and big picture about values and things like that. But then I think it's because he sets the stage to be like, everything I recommend here is what I believe to be sustainable, and good quality, and consistent.

+ +

And just for an example, one of the recommendations he makes is to, when you're kind of setting up a greenfield application, is to use a SQL schema instead of the default ActiveRecord DSL, so using a structure .SQL file. Because, in his eyes, having the flexibility to write SQL and use the most you can with those tools when it comes to database work is more sustainable in the long term than using the DSL that might not have all the tools available to you that SQL does.

+ +

And so he kind of gives his reasoning about, like, this is what I recommend, and here's why it contributes to sustainability, in my opinion. And so I have found myself, while I'm reading along, either agreeing, like, oh yeah, I can see his reasoning here, or maybe even disagreeing because I might think about things differently or have other considerations in mind that are more important to me and what sustainability means to me. But what I hopefully want to take away from the framework or understanding of values is evaluating technical decisions that I make based on my values as an individual but, more importantly, the values of the team or organization.

+ +

JOËL: I love mental frameworks like that that give you clarity into your own thought processes or how you make decisions moving forward. Sometimes you can look at something that's very concrete. Somebody gives you some advice on maybe structuring your database schema, and that might be helpful in and of itself. But if you came away with a larger thought process, I think that's doubly valuable.

+ +

As an aside here, I love this approach to writing where he sort of lays down almost like preconditions for this book. If you don't agree on these values, this book is not going to be very helpful for you. And then also, here are situations where this advice is not going to apply. Now that I've put down all these edge cases for the rest of this book, I'm going to be speaking very decisively; these are the things I recommend and not have to caveat myself all the time.

+ +

It's like, yes, I know there are some edge cases where you might not want to do this if it's a one-off script or whatever it is. We've already dealt with all of those upfront. And now, I can be very confident and very direct for the whole rest of the book. And I feel like that's something I struggle with in some of my work sometimes is. I care a lot about nuance, and my audience probably cares about edge cases even more than I do. They probably care too much.

+ +

Because I say something that's generally true most of the time, and I know somebody's already thinking about the one edge case where that's not true. And that doesn't matter for the main point I'm trying to make. So it's always a struggle to know when to caveat a statement that I'm making. But if you caveat too much, then you undermine your whole point. And so I like this idea of putting some caveats up front and then just saying, like, now we're in the 80% case. Within the 80% case, these are things I think are true.

+ +

STEPHANIE: Yeah, that's a really good point. I agree he is very clear about the intended audience. And so when you read this book, you are either on board because you value the same things he does, or you're not because you are focused and your goals are things that are different from him. So I think it was really helpful to get on the same page, even in a piece of content or in a piece of writing. Because I want to use my time well as a reader, so I want to make sure that what I am consuming makes sense for me, and I will find it worthwhile.

+ +

David takes a really strong stance on what quality means. And even though that is a pretty subjective value, he describes it as doing things right the first time and acknowledging the reality that we likely won't have the time to go back and clean things up after they've been shipped. So, on this client project, I found myself wanting to refactor things as part of my process, suggesting different implementations to do things the quote, unquote, "right way," or the best way we could, and not everyone shared that sentiment.

+ +

I sometimes got pushback, and that was challenging for me to figure out how I wanted to navigate that situation and what I was willing to let go and what I wasn't. And so I'm curious if you've ever been in a consulting position like that where maybe the team and organization's values were a little bit different from your understanding, or if they just weren't clear at all, and you were driving towards something that seemed very nebulous.

+ +

JOËL: I think I've been on both sides of that, both sometimes saying, "Look, we need to maybe slow down," or "Here's a thing that we need to do otherwise that's going to cost us on the longer term. Here's an area where we need to invest in quality today." And sort of on the other side where I'll feel like someone is really pushing an overengineered solution claiming it's going to make life a whole lot better, "If we invest three months upfront today, and maybe in three or four years, it'll pay off if certain things happen," that don't really necessarily line up with the immediate goals.

+ +

A lot of this, I think, comes down to understanding the client, and their business, and their goals. Sometimes there is a really important deadline for something that has to happen based on an event in the real world. If you were building software for something that had to do with, let's say, the World Cup, you don't want it shipping in January 2023. That's just pointless. And so you've got to prioritize shipping things.

+ +

And sometimes you say, "Okay, well, do we ship a few broken things? Or do we prefer to ship something that's a little bit smaller, more tightly scoped, but that holds well together?" That again, you have to really understand the client, their business, their needs. So I think for me those values of sustainability, quality...I forget what the third one was that you'd mentioned.

+ +

STEPHANIE: Consistency.

+ +

JOËL: Consistency, yes. They all sort of inform how it's going to mesh with the product I'm working on, the goals of that product. Where's it going in the next three months, six months, 12 months? Where's it coming from? Who's the team that I'm working with? Am I with a team of 300 people that are just committing to the main branch all the time with no tests, and we're constantly fighting regressions? Then sustainability looks very different there than a one other-person team, and we're trying to ship something for the World Cup.

+ +

STEPHANIE: Oh yeah, I have a lot of thoughts there too. Because I do agree that it can look different and sometimes shift a little bit depending on the situation. What you were just describing about team makeup that is really interesting to me because, yeah, sustainability can look different for different teams.

+ +

If you have, let's say, a lot of earlier career developers on your team, maybe you really want to focus on readability and making sure that they're able to navigate the codebase and figure things out over something like more advanced patterns and skills that will just cause them friction. But maybe you have a team where you all agree that that's what sustainability means to you is choosing those more advanced technical patterns and committing to them and figuring out how to maintain that because it's important to you.

+ +

And the other thing that you brought up that is also mentioned in this book is that the more information developers have about the future and direction of the business, the better code we can write. For some reason, I've found myself in situations where I don't know all too much about what we are working towards or what the goals of the business are both in the short term and the long term. And I try to make the best guess I can.

+ +

But I think in those scenarios, at least moving forward, I would really like to be better about pushing product folks or leadership to explain to me why we're doing what we're doing, kind of share the information that they have so that we can build the best product that we can.

+ +

I think sometimes that information doesn't get shared for some reason. They kind of think that engineers are going to go do their engineer thing, and we'll focus on long-term strategy over here. But yeah, I truly believe that the more information we have, the better quality work we can produce.

+ +

JOËL: I 100% agree. And I think that's what we see in a lot of classic agile literature talking about things like cross-functional teams or even the client or the product team should be integrated with the development team. You're all one team working together rather than someone has an idea, and then the technical team executes on it.

+ +

We see that also in some of the domain-driven design literature as well, where oftentimes projects start, and you sit down with a subject matter expert, and they just walk you through all of the business aspects. And particularly for the purpose of domain-driven design, you talk about a lot of the terms that make sense for the business. You build up a glossary of terms. I think they call it a ubiquitous language of things that are specific to your business and how does that work on a day-to-day basis.

+ +

STEPHANIE: Do you have any strategies for getting more clarity around the work and why you're building it if it's not yet available to you?

+ +

JOËL: I think there are sort of two scenarios where you have to do that; one of them that comes up maybe more often for us as consultants is onboarding onto a new client. There's a whole new business that we may know nothing about, and we have to learn a lot of that. And so, as part of the onboarding process, I think it's really valuable to have conversations with people who are not part of the dev team to learn about the business side of things.

+ +

On a per-feature basis, if you've already been onboarded on a project, you've been there for a while, it's often good to go back to the person who maybe created a ticket, a product person who's asking for a feature, and ask, "Why? Why do you want this?" Ideally, maybe that's even part of the ticket-creating process because the two teams are more integrated, and product team is like, here's a problem we're trying to solve. Here's what we think would be a solution. Or maybe even just "Here's a business problem. We need a technical solution. Can you do that for us?"

+ +

But I've often followed up with people outside of the engineering team to ask follow-up questions. And why are we doing this? And sometimes it's even you have to do like five Whys where it's like, "Oh, we're doing this because we need to do this thing for this customer. They asked for it." And it's like, "Okay, well, why are they asking for that?" "Oh, it's because they have this problem." And why are they having this problem?" And eventually, like, "Oh, I see. Okay."

+ +

The real solution has nothing to do with what was asked, and you come up with something that's maybe much tighter scoped or will better solve, and everybody's a winner in that case. But it does require following up. So I guess the short and boring answer is talk to people outside the engineering team.

+ +

STEPHANIE: That's a great point. I think the questions that we as engineers ask can drive more clarity to product people as well if we continue to ask those five levels of why in ways that they maybe didn't think about either. We have the opportunity to do that if we want to do our work well, too. That's kind of exciting to me that it isn't just okay, we're handed some work to do, and they've done all of that strategic thinking separately. And having to implement those details, we can kind of start to chip away at what are we really doing here?

+ +

And you mentioned talking to people outside of the engineering team. I just was thinking that pairing with non-developers would also be a really great task to do, especially when you get a ticket that's a bit ambiguous and you have questions. And you can always comment on the ticket or whatever and ask your questions. But perhaps there's also a good opportunity to work things through synchronously. In some ways, I think that is a more natural opportunity for that conversation to evolve rather than it being like, okay, I answered these questions, and now I'm going to move on to whatever else I have to do.

+ +

JOËL: So you mentioned pairing. It's often good to have someone maybe outside the development team pair with you on a technical thing, but sometimes it's good to flip the script. If you're building especially software for an internal team, it can be really valuable to just shadow one of them for a couple of hours or a day.

+ +

I did a project where we were building a tool for an internal sales team. And I had the privilege to shadow a couple of the sales members for a few hours as they're just doing their job. And I'm just asking all the questions like, "Oh, why do you do it that way? And what is the purpose behind this?" And I learned so much about the business by doing that.

+ +

STEPHANIE: I love that we took this idea of sustainable development and went beyond just technical design decisions or aspects of how we do our jobs. Because there is so much more that we can do to foster the value of sustainability or whatever other values that you might have, and yeah, I feel really excited to try both these technical strategies from the book and also the collaborative aspects as well.

+ +

JOËL: I'm really excited about some of these ideas that are coming up from the book. I think today we basically just talked about the introduction, the idea of sustainability. But I think as maybe you read more in the book, maybe we can do another episode later on talking about some of the more specific technical recommendations, how they relate to sustainability and maybe share some of our thoughts on that.

+ +

STEPHANIE: Yeah, I definitely am excited to keep y'all updated on this journey. [laughs]

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

JOËL: Show notes for this episode can be found at bikeshed.fm. This show has been produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter. Or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Stephanie talks about hosting a Soup Group! Joël got nerd-sniped during the last episode and dove deeper into Maggie Appleton's "Tools for Thought."

+ +

Stephanie has been thinking a lot about Sustainable Web Development. What is sustainability? How does it relate to tech and what we do?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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: I'm excited to share a winter survival idea for folks out there who are, like me, in a very cold place where all your friends don't want to hang out [laughs] and bear the cold temperatures of deep winter in January. Because tonight, I'm hosting my first soup group where I'm basically just going to make a really big batch of soup and have my friends come over with bread, and we're going to eat soup and bread and be cozy.

+ +

And I'm really excited because I was trying to figure out a way to combat the winter blues a little bit. And, yeah, I think this time of year can be really tough after the holidays to get people together again. At least for me, I was feeling like I haven't seen my friends in so long. And I was like, well, I could just be the person to take the initiative [laughs] and be like, "Come over to our place."

+ +

And the goal is to eventually do this regularly and just have this low-stakes open invitation for anyone to come and show up however they want to. It doesn't have to be, like, big pressure or anything. And if they can't make it at any one time, then there will hopefully be one in the future where they can make it, so I'm excited. After this, I am going to make soup for ten people, and it's going to be great. [laughs]

+ +

JOËL: I love this idea. Soup on a cold day is just the coziest thing.

+ +

STEPHANIE: Yeah, exactly. I definitely wanted to just make people feel warm and cozy. And that's what I want, so I'm really doing this for myself. [laughs]

+ +

JOËL: And you know the advantage of hosting is you don't have to go outside.

+ +

STEPHANIE: Yeah, that's the real thing is I'm probably going to kick everyone out at like 11:00 p.m. and then go straight to bed, and it's going to be great. [laughs]

+ +

JOËL: Have you been experimenting with a particular kind of soup recently? Are you going to bring out an old favorite?

+ +

STEPHANIE: Yeah, I'm excited to make ribollita today, so kind of like a Tuscan style of veggie hearty soup. And I've just been bookmarking soup recipes left and right. [laughs] And I've outsourced the bread situation. So I'm excited to see what kind of bread people bring. And yeah, it'll be very fun and kind of surprising in a comforting way.

+ +

JOËL: I'm not familiar with this soup. It's ribollita you said?

+ +

STEPHANIE: Yeah, that's it.

+ +

JOËL: You said it's a vegetable soup.

+ +

STEPHANIE: Yeah, mostly veggies and beans. So I have this giant cabbage, a lot of kale, multiple cans of Great Northern white beans, and they're all going to get mixed together. And we'll see how it turns out. I'll update the podcast on how the soup group goes. It is the inaugural one. So I can't think of a time that I made that much soup before. So, hopefully, it goes well. We'll find out. So, Joël, what about you? What's new in your world?

+ +

JOËL: So, in the previous episode, we talked a little bit about some of the things you had learned about note-taking. And you'd mentioned an article by, I think, Maggie Applebon --

+ +

STEPHANIE: Maggie Appleton.

+ +

JOËL: Appleton...on tools for thought. It was linked in the show notes of that episode. And I went back and read that article, and it was so good, particularly the section, I think, on historical tools for thought and how they, over time, were sort of groundbreaking in helping us to either remember things or to think about problems or ideas in a different way, or to sort of interrogate those ideas and see if we think they're true or helpful. And these were things like writing or the number system but even some more fancy things like the scientific method for the Cartesian coordinate system.

+ +

STEPHANIE: Yeah, I was really excited to share this with you because I think it was the intersection of a lot of your different interests, including note-taking, diagrams, history, and human cognition, so I'm glad that you found it interesting.

+ +

JOËL: I definitely got nerd-sniped there.

+ +

STEPHANIE: [laughs]

+ +

JOËL: I think one thing that really struck me was the power of having multiple different representations for ideas. And one that jumped out at me was the Cartesian coordinate system, which, among other things, a really powerful tool that gave people...when this was invented, it allowed you to convert algebra problems into geometry problems.

+ +

And so now, something that used to be an equation you can draw as a triangle or something. And we know how to find the area of a triangle. That's been known since the ancient Greeks and even earlier. And so now a problem that sounded hard is now easy, or at least we have a different way to think about that problem. Because if this equation is equivalent to a triangle, what does that mean?

+ +

And vice versa, you can use this to convert geometry problems into algebra problems. And so sometimes the power of a new tool for thought might be in that it allows you to sort of convert between two other existing ways of representing things. And making those connections, all of a sudden gives you a whole new way of thinking about things. That blew my mind.

+ +

STEPHANIE: Yeah, I agree. I think the other really cool thing is that a lot of these ideas that humans are discovering also already existed in the natural world. So when you are talking about math, you can see representations of math in plants and nature, and I was reminded of how honeycomb from bees is one of the strongest shapes. And yeah, it's really neat to draw inspiration from a lot of places and learn from things that, like, figured it out before we did.

+ +

JOËL: Have you seen the video on YouTube called "Hexagons are the Bestagons?"

+ +

STEPHANIE: No, I have not. Tell me more.

+ +

JOËL: It's a video on YouTube. We can link it in the show notes. Basically, the hexagon shows up everywhere in nature in part because it has a lot of really fun mathematical properties. It's one of the few shapes that you can use to completely cover a surface. So if you want to subdivide a two-dimensional surface into smaller shapes without leaving any empty spaces between them, you really don't have that many options.

+ +

I want to say it's like squares and triangles and hexagons are the only shapes that can do that. And hexagons have these really fun properties around strength. They also are one of the best balances between volume versus the amount of material that it takes to give you that volume and for strength and things like that. So it's good for honeycombs because you can store a lot of honey for very little amount of wax. But it's also good for all sorts of structural engineering because you can build things that are very strong yet light because they require very little metal or other material to create them.

+ +

STEPHANIE: When you're saying hexagons filling a lot of space, I also thought about how they've become kind of popular in tiles or interior design in kitchens, and bathrooms, and stuff. [laughs] I've definitely seen that trend a bit. [laughs] So that's really cool just to see, like, yeah, this thing in the natural world that we have adopted for other uses. It's really fun.

+ +

JOËL: I want to say this idea of taking a 2D space and being able to completely cover it without spaces with a shape is called tessellating a plane. It's a fancy term for it. And if you want to do it with just a single shape, I think there are only like three or four shapes that can do it.

+ +

STEPHANIE: That's really interesting because it reminds me of those tessellation puzzles that I used to play with as a kid. Do you know what I'm talking about?

+ +

JOËL: You're thinking like a tangram or something different.

+ +

STEPHANIE: Yeah, yeah, tangram, that was...oh my gosh, those were fun. Wow, I was learning math as a young child, [laughs] just didn't even know it.

+ +

JOËL: Another random fun fact: the logo for the Elm programming language is a tangram.

+ +

STEPHANIE: [Gasps]

+ +

JOËL: And the community is sort of encouraged to then remix it because the tangram is just a square tessellated out of a bunch of these shapes. But then, if you're building a library or you've got an event or something, the community will take those shapes and remix them into some other shapes that might fit your event.

+ +

STEPHANIE: That's really cool. Is it a metaphor for how Elm can be used in different ways? [laughs]

+ +

JOËL: I'm not sure about the story behind the logo. We'd have to look that up.

+ +

STEPHANIE: That'll be a good adventure for later. [laughs]

+ +

JOËL: In...I want to say Moroccan art, but I think it might be broader than just Moroccan. It might be more broadly North African or Moorish or whatever you want to call that. There's a long history of building these tessellations, I think, out of tiles, but maybe other things as well where you're doing it with a variety of shapes.

+ +

So you might start...a classic one, I think is an eight-pointed...is it eight, or? I think it's an eight-pointed star, and then you sort of add other shapes around it. And those can create patterns that take a long time to repeat. And there are these beautiful geometric patterns that just keep on going and expanding without necessarily repeating over a lot of space.

+ +

STEPHANIE: Whoa. That kind of blows my mind a little bit. It seems so counterintuitive, but then I feel like there are a lot of things in math that are like that as well.

+ +

JOËL: So, yeah, I think a classic pattern you might start with something like an eight-pointed star. And then maybe to fill in the spaces around that central star, you might put some squares, and then maybe you put some triangles around that, and you sort of keep trying to fill in. And maybe eventually you get to another eight-pointed star, but it's not always perfectly symmetric.

+ +

STEPHANIE: Someone should make a board game or something out of this idea. [laughs]

+ +

JOËL: Oooh.

+ +

STEPHANIE: I bet there's one that exists. But I'm just thinking about people who like jigsaw puzzles and that being the next level challenge of, like, can you figure out how things fit together without the confines of a little jigsaw shape? [laughs]

+ +

JOËL: Right, right. You have a rectangle shape that you have to perfectly fill in with all of these other smaller shapes, and there is a single solution that will work. You have to figure it out.

+ +

STEPHANIE: I personally would be very overwhelmed, [laughs] but it sounds fun at the same time.

+ +

JOËL: So those are a lot of thoughts that I've been having inspiration reading that article that you shared on a previous episode. Have you been reading anything interesting recently?

+ +

STEPHANIE: I have. I'm really excited to talk about this topic because during my investment time this past week, I've been thinking a lot about it, taking a lot of notes in Obsidian, which is a callback to the last episode, and yeah, I'm excited to kind of get into it. So what I've been reading is Sustainable Web Development with Ruby on Rails by ‎David Bryant Copeland.

+ +

And I think a lot of fellow thoughtboters have referenced this book or talked a little bit about ideas from this book; at least, I've seen discussion about it in Slack, so that's kind of why I wanted to pick it up. But what really blew my mind was honestly the first chapter where he talks about why he wrote this book and basically what sustainable web development is because it is a little bit, maybe, like a buzzy word. It's like, what is sustainability? How does it relate to tech and what we do?

+ +

And he basically gets down to it by saying that the software that we write is sustainable if it continues to meet our needs years into the future or has longevity and continues to be something we can iterate and work on and not feel that pain or friction, and we feel like we want to, and we feel joyful working on this codebase. So that was kind of my interpretation of his definition about sustainability.

+ +

JOËL: I love that definition of sustainability about code that can grow and live for a long time. And I feel like that's not a universal value in the tech industry. And on the extreme end of that, you'll have teams that promote the idea that maybe every few years, you should throw out your old codebase and rewrite. I want to say some teams at Google may have done that as a practice for a while, and, of course, then people quote that as a best practice.

+ +

To a certain extent, I want to say that's kind of what happens with Basecamp in that there are multiple versions of Basecamp. And I want to say each of those is a fresh Rails app. So there's a sense in which those or that style of development is not sustainable in the definition that you were just giving there. How do you feel about that?

+ +

STEPHANIE: I definitely think the industry has a bias towards newness and change. And a lot of people want to pick up the hot, new technology and, like you said, rewrite code, especially when it's become hard to work with. And honestly, I think that could be its whole own episode, rewrites because I think you and I have pretty strong opinions about it.

+ +

But I genuinely think that most of our work is, at least, you and I on the Boost team, in particular here at thoughtbot, where we embed on existing client teams, and usually, that means legacy code as well, but I think that the work of development is mostly extending existing code and trying to sustain applications that have users and are working for users.

+ +

And I think that that's certainly a value that I wish were highlighted more or were invested in more because sometimes that change or wanting to hop on to do something different or do something new has a lot of consequences that I'm not sure we talk about enough as an industry.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: It's interesting you mentioned the types of projects that we tend to be on. I feel like there are a lot of projects that I've been brought on where my goal, specifically coming onto this project, was to make the software more sustainable for the team. It's very easy to sort of start moving very fast in the beginning with a greenfield app, and then eventually, a lot of your choices catch up to you.

+ +

And then, as your team grows and your product grows, it becomes less and less sustainable. And that's often the point in the lifecycle of the product where I might join the team and try to help make things better for them. I love the keyword sustainable. I don't think that's one that I've used a lot, but it's a great label to put on that kind of work.

+ +

STEPHANIE: Yeah, I agree. I think what you mentioned earlier, too, about values that, really stuck out to me in this book because it basically says, "This book is for you if you value these three things: sustainability, consistency, and quality." And all of the recommendations and techniques that he then presents in the rest of the book, using Rails, those decisions are recommended with those three values in mind.

+ +

And I think, one, those values are personally important to me as a developer. But it also helped me develop some guiding principles around decision-making and provided a lot of clarity around times that I've been on teams where we were doing things that didn't quite align with my values, and I didn't enjoy it. And I couldn't really figure out why.

+ +

But now I'm able to see that, oh, perhaps this team or organization was valuing something like speed, or profit, or change, or something like that that I just fundamentally value differently. And that was kind of where my internal friction or contentment or discontentment was coming from when working on these teams. So, yeah, that was really clarifying for me.

+ +

JOËL: Would you say, for you, when you talk about these values, that these are fundamental or ultimate values for you when you write code? Or are they values that are a good way to sort of be a means to some other end? You know, for example, sustainability, do you care about sustainability just for its own sake? Or do you care about it because you want a product to be able to live for a long time? You're building for ten years or 20 years or however long you want this project to last.

+ +

STEPHANIE: I think the thing with values is that they are really fundamental to a person's identity or belief system. In fact, the definition that I'm kind of working off of here is that values are those fundamental beliefs that drive our actions. And so when you say, like, are values driving how you write code? I think they drive everything. [laughs]

+ +

But the point that he makes in this book is like, here's how they drive code and technical decisions. So the book is actually quite specific about technical recommendations that he has in the context of Rails. And it's funny because we're talking pretty abstractly and big picture about values and things like that. But then I think it's because he sets the stage to be like, everything I recommend here is what I believe to be sustainable, and good quality, and consistent.

+ +

And just for an example, one of the recommendations he makes is to, when you're kind of setting up a greenfield application, is to use a SQL schema instead of the default ActiveRecord DSL, so using a structure .SQL file. Because, in his eyes, having the flexibility to write SQL and use the most you can with those tools when it comes to database work is more sustainable in the long term than using the DSL that might not have all the tools available to you that SQL does.

+ +

And so he kind of gives his reasoning about, like, this is what I recommend, and here's why it contributes to sustainability, in my opinion. And so I have found myself, while I'm reading along, either agreeing, like, oh yeah, I can see his reasoning here, or maybe even disagreeing because I might think about things differently or have other considerations in mind that are more important to me and what sustainability means to me. But what I hopefully want to take away from the framework or understanding of values is evaluating technical decisions that I make based on my values as an individual but, more importantly, the values of the team or organization.

+ +

JOËL: I love mental frameworks like that that give you clarity into your own thought processes or how you make decisions moving forward. Sometimes you can look at something that's very concrete. Somebody gives you some advice on maybe structuring your database schema, and that might be helpful in and of itself. But if you came away with a larger thought process, I think that's doubly valuable.

+ +

As an aside here, I love this approach to writing where he sort of lays down almost like preconditions for this book. If you don't agree on these values, this book is not going to be very helpful for you. And then also, here are situations where this advice is not going to apply. Now that I've put down all these edge cases for the rest of this book, I'm going to be speaking very decisively; these are the things I recommend and not have to caveat myself all the time.

+ +

It's like, yes, I know there are some edge cases where you might not want to do this if it's a one-off script or whatever it is. We've already dealt with all of those upfront. And now, I can be very confident and very direct for the whole rest of the book. And I feel like that's something I struggle with in some of my work sometimes is. I care a lot about nuance, and my audience probably cares about edge cases even more than I do. They probably care too much.

+ +

Because I say something that's generally true most of the time, and I know somebody's already thinking about the one edge case where that's not true. And that doesn't matter for the main point I'm trying to make. So it's always a struggle to know when to caveat a statement that I'm making. But if you caveat too much, then you undermine your whole point. And so I like this idea of putting some caveats up front and then just saying, like, now we're in the 80% case. Within the 80% case, these are things I think are true.

+ +

STEPHANIE: Yeah, that's a really good point. I agree he is very clear about the intended audience. And so when you read this book, you are either on board because you value the same things he does, or you're not because you are focused and your goals are things that are different from him. So I think it was really helpful to get on the same page, even in a piece of content or in a piece of writing. Because I want to use my time well as a reader, so I want to make sure that what I am consuming makes sense for me, and I will find it worthwhile.

+ +

David takes a really strong stance on what quality means. And even though that is a pretty subjective value, he describes it as doing things right the first time and acknowledging the reality that we likely won't have the time to go back and clean things up after they've been shipped. So, on this client project, I found myself wanting to refactor things as part of my process, suggesting different implementations to do things the quote, unquote, "right way," or the best way we could, and not everyone shared that sentiment.

+ +

I sometimes got pushback, and that was challenging for me to figure out how I wanted to navigate that situation and what I was willing to let go and what I wasn't. And so I'm curious if you've ever been in a consulting position like that where maybe the team and organization's values were a little bit different from your understanding, or if they just weren't clear at all, and you were driving towards something that seemed very nebulous.

+ +

JOËL: I think I've been on both sides of that, both sometimes saying, "Look, we need to maybe slow down," or "Here's a thing that we need to do otherwise that's going to cost us on the longer term. Here's an area where we need to invest in quality today." And sort of on the other side where I'll feel like someone is really pushing an overengineered solution claiming it's going to make life a whole lot better, "If we invest three months upfront today, and maybe in three or four years, it'll pay off if certain things happen," that don't really necessarily line up with the immediate goals.

+ +

A lot of this, I think, comes down to understanding the client, and their business, and their goals. Sometimes there is a really important deadline for something that has to happen based on an event in the real world. If you were building software for something that had to do with, let's say, the World Cup, you don't want it shipping in January 2023. That's just pointless. And so you've got to prioritize shipping things.

+ +

And sometimes you say, "Okay, well, do we ship a few broken things? Or do we prefer to ship something that's a little bit smaller, more tightly scoped, but that holds well together?" That again, you have to really understand the client, their business, their needs. So I think for me those values of sustainability, quality...I forget what the third one was that you'd mentioned.

+ +

STEPHANIE: Consistency.

+ +

JOËL: Consistency, yes. They all sort of inform how it's going to mesh with the product I'm working on, the goals of that product. Where's it going in the next three months, six months, 12 months? Where's it coming from? Who's the team that I'm working with? Am I with a team of 300 people that are just committing to the main branch all the time with no tests, and we're constantly fighting regressions? Then sustainability looks very different there than a one other-person team, and we're trying to ship something for the World Cup.

+ +

STEPHANIE: Oh yeah, I have a lot of thoughts there too. Because I do agree that it can look different and sometimes shift a little bit depending on the situation. What you were just describing about team makeup that is really interesting to me because, yeah, sustainability can look different for different teams.

+ +

If you have, let's say, a lot of earlier career developers on your team, maybe you really want to focus on readability and making sure that they're able to navigate the codebase and figure things out over something like more advanced patterns and skills that will just cause them friction. But maybe you have a team where you all agree that that's what sustainability means to you is choosing those more advanced technical patterns and committing to them and figuring out how to maintain that because it's important to you.

+ +

And the other thing that you brought up that is also mentioned in this book is that the more information developers have about the future and direction of the business, the better code we can write. For some reason, I've found myself in situations where I don't know all too much about what we are working towards or what the goals of the business are both in the short term and the long term. And I try to make the best guess I can.

+ +

But I think in those scenarios, at least moving forward, I would really like to be better about pushing product folks or leadership to explain to me why we're doing what we're doing, kind of share the information that they have so that we can build the best product that we can.

+ +

I think sometimes that information doesn't get shared for some reason. They kind of think that engineers are going to go do their engineer thing, and we'll focus on long-term strategy over here. But yeah, I truly believe that the more information we have, the better quality work we can produce.

+ +

JOËL: I 100% agree. And I think that's what we see in a lot of classic agile literature talking about things like cross-functional teams or even the client or the product team should be integrated with the development team. You're all one team working together rather than someone has an idea, and then the technical team executes on it.

+ +

We see that also in some of the domain-driven design literature as well, where oftentimes projects start, and you sit down with a subject matter expert, and they just walk you through all of the business aspects. And particularly for the purpose of domain-driven design, you talk about a lot of the terms that make sense for the business. You build up a glossary of terms. I think they call it a ubiquitous language of things that are specific to your business and how does that work on a day-to-day basis.

+ +

STEPHANIE: Do you have any strategies for getting more clarity around the work and why you're building it if it's not yet available to you?

+ +

JOËL: I think there are sort of two scenarios where you have to do that; one of them that comes up maybe more often for us as consultants is onboarding onto a new client. There's a whole new business that we may know nothing about, and we have to learn a lot of that. And so, as part of the onboarding process, I think it's really valuable to have conversations with people who are not part of the dev team to learn about the business side of things.

+ +

On a per-feature basis, if you've already been onboarded on a project, you've been there for a while, it's often good to go back to the person who maybe created a ticket, a product person who's asking for a feature, and ask, "Why? Why do you want this?" Ideally, maybe that's even part of the ticket-creating process because the two teams are more integrated, and product team is like, here's a problem we're trying to solve. Here's what we think would be a solution. Or maybe even just "Here's a business problem. We need a technical solution. Can you do that for us?"

+ +

But I've often followed up with people outside of the engineering team to ask follow-up questions. And why are we doing this? And sometimes it's even you have to do like five Whys where it's like, "Oh, we're doing this because we need to do this thing for this customer. They asked for it." And it's like, "Okay, well, why are they asking for that?" "Oh, it's because they have this problem." And why are they having this problem?" And eventually, like, "Oh, I see. Okay."

+ +

The real solution has nothing to do with what was asked, and you come up with something that's maybe much tighter scoped or will better solve, and everybody's a winner in that case. But it does require following up. So I guess the short and boring answer is talk to people outside the engineering team.

+ +

STEPHANIE: That's a great point. I think the questions that we as engineers ask can drive more clarity to product people as well if we continue to ask those five levels of why in ways that they maybe didn't think about either. We have the opportunity to do that if we want to do our work well, too. That's kind of exciting to me that it isn't just okay, we're handed some work to do, and they've done all of that strategic thinking separately. And having to implement those details, we can kind of start to chip away at what are we really doing here?

+ +

And you mentioned talking to people outside of the engineering team. I just was thinking that pairing with non-developers would also be a really great task to do, especially when you get a ticket that's a bit ambiguous and you have questions. And you can always comment on the ticket or whatever and ask your questions. But perhaps there's also a good opportunity to work things through synchronously. In some ways, I think that is a more natural opportunity for that conversation to evolve rather than it being like, okay, I answered these questions, and now I'm going to move on to whatever else I have to do.

+ +

JOËL: So you mentioned pairing. It's often good to have someone maybe outside the development team pair with you on a technical thing, but sometimes it's good to flip the script. If you're building especially software for an internal team, it can be really valuable to just shadow one of them for a couple of hours or a day.

+ +

I did a project where we were building a tool for an internal sales team. And I had the privilege to shadow a couple of the sales members for a few hours as they're just doing their job. And I'm just asking all the questions like, "Oh, why do you do it that way? And what is the purpose behind this?" And I learned so much about the business by doing that.

+ +

STEPHANIE: I love that we took this idea of sustainable development and went beyond just technical design decisions or aspects of how we do our jobs. Because there is so much more that we can do to foster the value of sustainability or whatever other values that you might have, and yeah, I feel really excited to try both these technical strategies from the book and also the collaborative aspects as well.

+ +

JOËL: I'm really excited about some of these ideas that are coming up from the book. I think today we basically just talked about the introduction, the idea of sustainability. But I think as maybe you read more in the book, maybe we can do another episode later on talking about some of the more specific technical recommendations, how they relate to sustainability and maybe share some of our thoughts on that.

+ +

STEPHANIE: Yeah, I definitely am excited to keep y'all updated on this journey. [laughs]

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

JOËL: Show notes for this episode can be found at bikeshed.fm. This show has been produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter. Or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+D2iIDj8l + + ]]> + + Joël Quenneville + Stephanie Minn + + + 367: Value Objects + https://bikeshed.thoughtbot.com/367 + 621373db-9174-42af-97a3-bb39067be26e + Tue, 17 Jan 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël's been traveling. Stephanie's working on professional development. She's also keeping up a little bit more with Ruby news and community news in general and saw that Ruby 3.2 introduced a new class called data to its core library for the use case of creating simple value objects. + 34:00 + no + + + Joël's been traveling. Stephanie's working on professional development. She's also keeping up a little bit more with Ruby news and community news in general and saw that Ruby 3.2 introduced a new class called data to its core library for the use case of creating simple value objects. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Maggie Appleton's Tools for Thought (https://maggieappleton.com/tools-for-thought) +Episode on note-taking with Amanda Beiner (https://www.bikeshed.fm/357) +Obsidian (https://obsidian.md/) +Zettelkasten (https://zettelkasten.de/posts/overview/) +Evergreen notes (https://notes.andymatuschak.org/Evergreen_notes) +New Data class (https://ruby-doc.org/3.2.0/Data.html) +Joël's article on value objects (https://thoughtbot.com/blog/value-object-semantics-in-ruby) +Episode on specialized vocabulary (https://www.bikeshed.fm/356) +Primitive Obsession (https://wiki.c2.com/?PrimitiveObsession) +Transcript: +AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +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 little bit of what we've learned along the way. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I've been traveling for the past few weeks in Europe. I just recently got back to the U.S. and have just gotten used to drinking American-style drip coffee again after having espresso every day for a few weeks. And it's been an adjustment. +STEPHANIE: I bet. I think that it's such a downgrade compared to European espresso. I remember when I was in Italy, I also would really enjoy espresso every day at a local cafe and just be like sitting outside drinking it. And it was very delightful. +JOËL: They're very different experiences. I have to say I do enjoy just holding a hot mug and sort of sipping on it for a long time. It's also a lot weaker. You wouldn't want to do a full hot mug of espresso. That would just be way too intense. But yeah, I think both experiences are enjoyable. They're just different. +STEPHANIE: Yeah. So, that first day with your measly drip coffee and your jet lag, how are you doing on your first day back at work? +JOËL: I did pretty good. I think part of the fun of coming back to the U.S. from Europe is that the jet lag makes me a very productive morning person for a week. Normally, I'm a little bit more of an evening person. So I get to get a bit of an alter ego for a week, and that helps me to transition back into work. +STEPHANIE: Nice. +JOËL: So you've also been on break and have started work again. How are you feeling productivity-wise, kicking off the New Year? +STEPHANIE: I'm actually unbooked this week and the last week too. So I'm not working on client projects, but I am having a lot of time to work on just professional development. And usually, during this downtime, I also like to reassess just how I'm working, and lately, what that has meant for me is changing my note-taking process. And I'm really excited to share this with you because I know that you have talked about this on the show before, I think in a previous episode with a guest, Amanda Beiner. +And I listened to that episode, and I was really inspired because I was feeling like I didn't have a note-taking system that worked super well for me. But you all talked about some tools you used and some, I guess, philosophies around note-taking that like I said, I was really inspired by. And so I hopped on board the Obsidian train. And I'm really excited to share with you my experience with it. +So I really like it because I previously was taking notes in my editor under the impression that, oh, like, everything is in one place. It'll be like a seamless transition from code to note-taking. And I was already writing in Markdown. But I actually didn't like it that much because I found it kind of distracting to have code things kind of around. And if I was navigating files or something, something work or code-related might come up, and that ended up being a bit distracting for me. But I know that that works really well for some people; a coworker of ours, Aji, I know that he takes his notes in Vim and has a really fancy setup for that. +And so I thought maybe that's what I wanted, but it turns out that what I wanted was actually more of a boundary between code and notes. And so, I was assessing different note-taking and knowledge management software. And I have been really enjoying Obsidian because it also has quite a bit of community support. So I've installed a few plugins for just quality-of-life features like snippets which I had in my editor, and now I get to have in Obsidian. +I also installed things like Natural Language Dates. So for my running to-do list, I can just do a shortcut for today, and it'll autofill today's date, which, I don't know, because for me, [laughs] that is just a little bit less mental work that I have to do to remember the date. And yeah, I've been really liking it. I haven't even fully explored backlinking, and that connectivity aspect, which I know is a core feature, but it's been working well for me so far. +JOËL: That's really exciting. I love notes and note-taking and the ways that we can use those to make our lives better as developers and as human beings. Do you have a particular system or way you've approached that? Because I know for me, I probably looked at Obsidian for six months before I kind of had the courage to download it because I didn't want to go into it and not have a way to organize things. +I was like; I don't want to just throw random notes in here. I want to have a system. That might just be me. But did you just kind of jump into it and see, like, oh, a system will emerge? Did you have a particular philosophy going in? How are you approaching taking notes there? +STEPHANIE: That's definitely a you thing because I've definitely had the opposite experience [laughs] where I'm just like, oh, I've downloaded this thing. I'm going to start typing notes and see what happens. I have never really had a good organizational system, which I think is fine for me. I was really leaning on pen and paper notes for a while, and I still have a certain use case for them. +Because I find that when I'm in meetings or one-on-ones and taking notes, I don't actually like to have my hands on the keyboard because of distractions. Like I mentioned earlier, it's really easy for me to, like, oh, accidentally Command-Tab and open Slack and be like, oh, someone posted something new in Slack; let me go read this. And I'm not giving the meeting or the person I'm talking to my full attention, and I really didn't like that. +So I still do pen and paper for things where I want to make sure that I'm not getting distracted. And then, I will transfer any gems from those notes to Obsidian if I find that they are worth putting in a place where I do have a little bit more discoverability and eventually maybe kind of adding on to my process of using those backlinks and connecting thoughts like that. So, so far, it's truly just a list of separate little pages of notes, and yeah, we'll see how it goes. I'm curious what your system for organizing is or if you have kind of figured out something that works well for you. +JOËL: So my approach focuses very heavily on the backlinks. It's loosely inspired by two similar systems of organization called Zettelkasten and evergreen notes. The idea is that you create notes that are ideas. Typically, the title is like a thesis statement, and you keep them very short, focused on a single thing. And if you have a more complex idea, it probably breaks down into two or three, and then you link them to each other as makes sense. +So you create a web of these atomic ideas that are highly interconnected with each other. And then later on, because I use this a lot for either creating content in the future or to help refine my thinking on various software topics, so later on, I can go through and maybe connect three or four things I didn't realize connected together. Or if I'm writing an article or a talk, maybe find three or four of these ideas that I generated at very different moments, but now they're connected. And I can make an article or a talk out of them. So that's sort of the purpose that I use them for and how I've organized things for myself. +STEPHANIE: I think that's a really interesting topic because while I was assessing different software for note-taking and, like I said, knowledge management, I discovered this blog post by Maggie Appleton that was super interesting because she is talking about the term tools of thought which a lot of these different software kind of leveraged in their marketing copy as like, oh, this software will be like the key to evolving your thinking and help you expand making connections, like you mentioned, in ways that you weren't able to before. And was very obviously trying to upsell you on this product, and she -- +JOËL: It's over the top. +STEPHANIE: A little bit, a little bit. So in this article, I liked that she took a critical lens to that idea and rooted her article in history and gave examples of a bunch of different things in human history that also evolved the ways humans were able to express their thoughts and solve problems. And so some of the ones that she listed were like storytelling and oral tradition. Literally, the written language obviously [laughs] empowered humans to be able to communicate and think in ways that we never were before but also drawings, and maps, and spreadsheets. +So I thought that was really cool because she was basically saying that tools of thought don't need to be digital, and people claiming that these software, you know, are the new way to think or whatever, it's like, the way we're thinking now, but we also have this long history of using and developing different things that helped us communicate with each other and think about stuff. +JOËL: I think that's something that appealed to me when I was looking at some of these note-taking systems. Zettelkasten, in particular, predates digital technology. The original system was built on note cards, and the digital stuff just made it a little bit easier. But I think also when I was reading about these ideas of keeping ideas small and linking them together, I realized that's already kind of how I tend to organize information when I just hold it in my brain or even when I try to do something like a tweet thread on Twitter where I'll try to break it up. +It might be a larger, more complex idea, but each tweet, I try to get it to kind of stand on its own to make it easier to retweet and all that. And so it becomes a chain of related ideas that maybe build up to something, but each idea stands on its own. And that's kind of how in these systems notes end up working. And they're in a way that you can kind of remix them with each other. So it's not just a linear chain like you would have on Twitter. +STEPHANIE: Yeah, I remember you all in that episode about note-taking with Amanda talked about the value of having an atomic piece of information in every note that you write. And since then, I've been trying to do that more because, especially when I was doing pen and paper, I would just write very loose, messy thoughts down. And I would just think that maybe I would come back to them one day and try to figure out, like, oh, what did I say here, and can I apply it to something? +But it's kind of like doing any kind of refactoring or whatever. It's like, in that moment, you have the most context about what you just wrote down or created. And so I've been a little more intentional about trying to take that thought to its logical end, and then hopefully, it will provide value later. +What you were saying about the connectivity I also wanted to kind of touch on a little bit further because I've realized that for me, a lot of the connection-making happens during times where I'm not very actively trying to think, or reflect, or do a lot of deep work, if you will. Because lately, I've been having a lot of revelations in the shower, or while I'm trying to fall asleep, or just other kinds of meditative activity. And I'm just coming to terms with that's just how my brain works. And doing those kinds of activities has value for me because it's like something is clearly going on in my brain. And I definitely want to just honor that's how it works for me. +JOËL: I had a great conversation recently with another colleague about the gift of boredom and how that can impact our work and what we think about, and our creativity. That was really great. Sometimes it's important to give ourselves a little bit more blank space in our lives. And counter-intuitively, it can make us more productive, even though we're not scheduling ourselves to be productive. +STEPHANIE: Yes, I wholeheartedly agree with that. I think a lot about the feeling of boredom, and for me, that is like the middle of summer break when you're still in school and you just had no obligations whatsoever. And you could just do whatever you wanted and could just laze around and be bored. But letting your mind wander during those times is something I really miss. +And sometimes, when I do experience that feeling, I get a little bit anxious. I'm like, oh, I could be doing something else. There's whatever endless list of chores or things that are, quote, unquote, "productive." But yeah, I really like how you mentioned that there is value in that experience, and it can feel really indulgent, but that can be good too. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So you mentioned recently that you've had a lot of revelations or new ideas that have come upon you or that you've been able to dig into a little bit more. Is there one you'd like to share with the audience? +STEPHANIE: Yeah. So during this downtime that I've had not working on client work, I have been able to keep up a little bit more with Ruby news or just community news in general. And in, I think, an edition of Ruby Weekly, I saw that Ruby 3.2 introduced this new class called data to its core library for the use case of creating simple value objects. +And I was really excited about this new feature because I remembered that you had written a thoughtbot blog post about value objects back in the summer that I had reviewed. That was an opportunity that I could make a connection between something happening in recent news with some thoughts that I had about this topic a few months ago. But basically, this new class can be used over something like a struct to create objects that are immutable in their values, which is a big improvement if you are trying to follow value objects semantics. +JOËL: So, I have not played around with the new data class. How is it different from the existing struct that we have in Ruby? +STEPHANIE: So I think I might actually answer that first by saying how they're similar, which is that they are both vehicles for holding pieces of data. So we've, in the past, been able to use a struct to very cheaply and easily create a new class that has attributes. But one pitfall of using a struct when you're trying to implement something like a value object is that structs also came with writer methods for all of its members. +And so you could change the value of a member, and that it kind of inherently goes against the semantics of a value object because, ideally, they're immutable. And so, with the data class, it doesn't offer writer methods essentially. And I think that it freezes the instance as well in the constructor. And so even if you tried to add writer methods, you would eventually get an error. +JOËL: That's really convenient. I think that may be an area where I've been a little bit frustrated with structs in the past, which is that they can be modified. They basically get treated as if they're hashes with a slightly nicer syntax to interact with them. And I want slightly harder boundaries around the data. +Particularly when I'm using them as value objects, I generally don't want people to modify them because that might lead to some weird bugs in the code where you've got a, I don't know, something represents a time value or a date value or something, and you're trying to do math on it. And instead of giving you a new time or date, value just modifies the first one. And so now your start date is in the past or something because you happen to subtract a time from it to do a calculation. And you can't assign it to a variable anywhere. +STEPHANIE: Yeah, for sure. Another kind of pitfall I remember noticing about structs were that the struct class includes the enumerable module, which makes a struct kind of like a collection. Whereas if you are using it for a value object, that's maybe not what you want. So there was a bit of discourse about whether or not the data class should inherit from struct. And I think they landed on it not inheriting because then you can draw a line in the sand and have that stricter enforcement of saying like, this is what a data as value object should be, and this is what it should not be. So I found that pretty valuable too. +JOËL: I think I've heard people talk about sort of two classes of problems that are typically solved with a struct; one is something like a value object where you probably don't want it to be writable. You probably don't want it to be enumerable. And it sounds like data now takes on that role very nicely. +The other category of problem is that you have just a hash, and you're trying to incrementally migrate it over to some nicer objects in some kind of domain. And struct actually gives you this really nice intermediate phase where it still mostly behaves like a hash if you needed to, but it also behaves like an object. And it can help you incrementally transition away from just a giant hash into something that's a little bit more programmatic. +STEPHANIE: Yeah, that's a really good point. I think struct will still be a very viable option for that second category that you described. But having this new data class could be a good middle ground before you extract something into its own class because it better encapsulates the idea of a value object. +And one thing that I remember was really interesting about the article that you wrote was that sometimes people forget to implement certain methods when they're writing their own custom value objects. And these come a bit more out of the box with data and just provide a bit more like...what's the word I'm looking for? I'm looking for...you know when you're bowling, and you have those bumpers, I guess? [laughs] +JOËL: Uh-huh. +STEPHANIE: They provide just like safeguards, I guess, for following semantics around value objects that I thought was really important because it's creating an artifact for this concept that didn't exist. +JOËL: And to recap for the audience here, the difference is in how objects are compared for equality. So value objects, if they have the same internal value, even if they're separate objects in memory, should be considered equal. That's how numbers work. That's how hashes work. Generally, primitives in Ruby behave this way. And structs behave that way, and the new data class, it sounds, also behaves that way. Whereas regular objects that you would make they compare based off of the identity of the object, not its value. +So if you create two user instances, not ActiveRecord, but you could create a user class, you create two instances in memory. They both have the same attributes. They will be considered not equal to each other because they're not the same instance in memory, and that's fine for something more complex. But when you're dealing with value objects, it's important that two objects that represent the same thing, like a particular time for a unit of measure or something like that, if they have the same internal value, they must be the same. +STEPHANIE: Right. So prior to the introduction of this class, that wasn't really enforced or codified anywhere. It was something that if you knew what a value object was, you could apply that concept to your code and make sure that the code you wrote was semantically aligned with this concept. And what was kind of exciting to me about the addition of this to the core class library in Ruby is that someone could discover this without having to know what a value object is like more formally. +They might be able to see the use of a data class and be like, oh, let me look this up in the official Ruby docs. And then they could learn like, okay, here's what that means, and here's some rules for this concept in a way that, like I mentioned earlier, felt very implicit to me prior. So that, I don't know, was a really exciting new development in my eyes. +JOËL: One of the first episodes that you and I recorded together was about the value of specific vocabulary. And I think part of what the Ruby team has done here is they've taken an implicit concept and given it a name. It's extracted, and it has a name now. And if you use it now, it's because you're doing this data thing, this value object thing. And now there's a documentation page. You can Google it. You can find it rather than just be wondering like, oh, why did someone use a struct in this way and not realize there are some implicit semantics that are different? Or wondering why did the override double equals on this custom class? +STEPHANIE: Yeah, exactly. I think that the introduction of this class also provides a solution for something that you mentioned in that blog post, which was the idea of testing value objects. Because previously, when you did have to make sure that you implemented methods, those comparison methods to align with the concept of a value object, it was very easy to forget or just not know. And so you provided a potential solution of testing value objects via an RSpec shared example. +And I remember thinking like, ooh, that was a really hot topic because we had also been debating about shared examples in general. But yeah, I was just thinking that now that it's part of the core library, I think, in some ways, that eliminates the need to test something that is using a data class anyway because we can rely a little bit more on that dependency. +JOËL: Right? It's the built-in behavior now. Do you have any fun uses for value objects recently? +STEPHANIE: I have not necessarily had to implement my own recently. But I do think that the next time I work with one or the next time I think that I might want to have something like a value object it will be a lot easier. And I'm just excited to play around with this and see how it will help solve any problem that might come up. So, Joël, do you have any ideas about when you might reach for a data object? +JOËL: A lot of situations, I think, when you see the primitive obsession smell are a great use case for value objects, or maybe we should call them data objects now, now that this is part of Ruby's vocabulary. I think I often tend to; preemptively sounds bad, but a lot of times, I will try to be careful. Anytime I'm doing anything with raw numbers, magic strings, things like that, I'll try to encapsulate them into some sort of struct. Or even if it's like a pair of numbers, it always goes together, maybe a latitude and longitude. +Now, those are a pair. Do I want to just be passing around a two-element array all the time or a hash that would probably make a very nice data object? If I have a unit of measure, some number that represents not just the abstract concept of three but specifically three miles or three minutes, then I might reach for something like a data class. +STEPHANIE: Yeah, I think that's also true if you're doing any kind of arithmetic or, in general, trying to compare anything about two of the same things. That might be a good indicator as well that you could use something richer, like a value object, to make some of that code more readable, and you get some of those convenient methods for doing those comparisons. +JOËL: Have you ever written code where you just have like some number in the code, and there's a comment afterwards that's like minutes or miles or something like that, just giving you the unit as a comment afterwards? +STEPHANIE: Oh yeah. I've definitely seen some of that code. And yeah, I mean, now that you mentioned it, that's a great use case for what we're talking about, and it's definitely a code smell. +JOËL: It can often be nice as you make these more domain concepts; maybe they start as a data object, but then they might grow with their own custom methods. And maybe you extend data the same way you could extend a struct, or maybe you create a custom class to the point where the user...whoever calls that object, doesn't really need to know or care about the particular unit, just like when you have duration value. +If you have a duration object, you can do the math you want. You can do all the operations and don't have to know whether it is in milliseconds, or seconds, or minutes because it knows that internally and keeps all of the math straight as opposed to just holding on to what I've done before, which is you have some really big number somewhere. You have start is, or length is equal to some big number and then comment milliseconds. And then, hopefully, whoever does math on that number later remembers to do the division by 1,000 or whatever they need. +STEPHANIE: I've certainly worked on code where we've tolerated those magic numbers for probably longer than we should have because maybe we did have the shared understanding that that value represents minutes or milliseconds or whatever, and that was just part of the domain knowledge. But you're right, like when you see them, and without a very clear label, all of that stuff is implied and is really not very friendly for someone coming along in the future. +As well as, like you mentioned earlier, if you have to do math on it later to convert it to something else, that is also a red flag that you could use some kind of abstraction or something to represent this concept at a higher level but also be extensible to different forms, so a duration to represent different amounts of time or money to represent different values and different currencies, stuff like that. +JOËL: Do you have a guideline that you follow as to when something starts being worth extracting into some kind of data object? +STEPHANIE: I don't know if I have particularly clear guidelines, but I do remember feeling frustrated when I've had to test really complicated hashes or just primitives that are holding a lot of different pieces of information in a way that just is very unwieldy when you do have to write a test for it. And if those things were encapsulated in methods, that would have been a lot easier. And so I think that is a bit of a signal for me. Do you have any other guidelines or gut instincts around that? +JOËL: We mentioned the comment that is the unit. That's probably a...I wasn't sure if I would have to call it a code smell, but I'm going to call it a code smell that tells you maybe you should...that value wants to be something a little bit more than just a number. I've gotten suspicious of just raw integers in general, not enough to say that I'm going to make all integers data objects now, but enough to make me pause and think a lot of times. What does this number represent? Should it be a data object? +I think I also tend to default to try to do something like a data object when I'm dealing with API responses. You were talking about hashes and how they can be annoying to test. But also, when you're dealing with data coming back from a third-party API, a giant nested hash is not the most convenient thing to work with, both for the implementation but then also just for the readability of your code. I often try to have almost like a translation layer where very quickly I take the payload from a third-party service and turn it into some kind of object. +STEPHANIE: Yeah, I think the data class docs itself has an example of using it for HTTP responses because I think the particular implementation doesn't even require it to have attributes. And so you can use it to just label something rather than requiring a value for it. +JOËL: And that is one thing that is nice about something like a data object versus a hash is that a hash could have literally anything in it. And to a certain extent, a data object is self-documenting. So if I want to know I've gotten to a shopping cart object from a third-party API, what can I get out of the shopping cart? +I can look at the data object. I can open the class and see here are the methods I can call. If it's just a hash, well, I guess I can try to either find the documentation for the API or try to make a real request and then inspect the hash at runtime. But there's not really any way to find out without actually executing the code. +STEPHANIE: Yeah, that's totally fair. And what you said about self-documenting makes a lot of sense. And it's always preferable than that stray comment in the code. [laughs] +JOËL: I'm really excited to use the data class in future Ruby 3.2 projects. So I'm really glad that you brought it up. I've not tried it myself, but I'm excited to use it in future projects. +STEPHANIE: On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeeeeeee!!!!!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Joël's been traveling. Stephanie's working on professional development. She's also keeping up a little bit more with Ruby news and community news in general and saw that Ruby 3.2 introduced a new class called data to its core library for the use case of creating simple value objects.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been traveling for the past few weeks in Europe. I just recently got back to the U.S. and have just gotten used to drinking American-style drip coffee again after having espresso every day for a few weeks. And it's been an adjustment.

+ +

STEPHANIE: I bet. I think that it's such a downgrade compared to European espresso. I remember when I was in Italy, I also would really enjoy espresso every day at a local cafe and just be like sitting outside drinking it. And it was very delightful.

+ +

JOËL: They're very different experiences. I have to say I do enjoy just holding a hot mug and sort of sipping on it for a long time. It's also a lot weaker. You wouldn't want to do a full hot mug of espresso. That would just be way too intense. But yeah, I think both experiences are enjoyable. They're just different.

+ +

STEPHANIE: Yeah. So, that first day with your measly drip coffee and your jet lag, how are you doing on your first day back at work?

+ +

JOËL: I did pretty good. I think part of the fun of coming back to the U.S. from Europe is that the jet lag makes me a very productive morning person for a week. Normally, I'm a little bit more of an evening person. So I get to get a bit of an alter ego for a week, and that helps me to transition back into work.

+ +

STEPHANIE: Nice.

+ +

JOËL: So you've also been on break and have started work again. How are you feeling productivity-wise, kicking off the New Year?

+ +

STEPHANIE: I'm actually unbooked this week and the last week too. So I'm not working on client projects, but I am having a lot of time to work on just professional development. And usually, during this downtime, I also like to reassess just how I'm working, and lately, what that has meant for me is changing my note-taking process. And I'm really excited to share this with you because I know that you have talked about this on the show before, I think in a previous episode with a guest, Amanda Beiner.

+ +

And I listened to that episode, and I was really inspired because I was feeling like I didn't have a note-taking system that worked super well for me. But you all talked about some tools you used and some, I guess, philosophies around note-taking that like I said, I was really inspired by. And so I hopped on board the Obsidian train. And I'm really excited to share with you my experience with it.

+ +

So I really like it because I previously was taking notes in my editor under the impression that, oh, like, everything is in one place. It'll be like a seamless transition from code to note-taking. And I was already writing in Markdown. But I actually didn't like it that much because I found it kind of distracting to have code things kind of around. And if I was navigating files or something, something work or code-related might come up, and that ended up being a bit distracting for me. But I know that that works really well for some people; a coworker of ours, Aji, I know that he takes his notes in Vim and has a really fancy setup for that.

+ +

And so I thought maybe that's what I wanted, but it turns out that what I wanted was actually more of a boundary between code and notes. And so, I was assessing different note-taking and knowledge management software. And I have been really enjoying Obsidian because it also has quite a bit of community support. So I've installed a few plugins for just quality-of-life features like snippets which I had in my editor, and now I get to have in Obsidian.

+ +

I also installed things like Natural Language Dates. So for my running to-do list, I can just do a shortcut for today, and it'll autofill today's date, which, I don't know, because for me, [laughs] that is just a little bit less mental work that I have to do to remember the date. And yeah, I've been really liking it. I haven't even fully explored backlinking, and that connectivity aspect, which I know is a core feature, but it's been working well for me so far.

+ +

JOËL: That's really exciting. I love notes and note-taking and the ways that we can use those to make our lives better as developers and as human beings. Do you have a particular system or way you've approached that? Because I know for me, I probably looked at Obsidian for six months before I kind of had the courage to download it because I didn't want to go into it and not have a way to organize things.

+ +

I was like; I don't want to just throw random notes in here. I want to have a system. That might just be me. But did you just kind of jump into it and see, like, oh, a system will emerge? Did you have a particular philosophy going in? How are you approaching taking notes there?

+ +

STEPHANIE: That's definitely a you thing because I've definitely had the opposite experience [laughs] where I'm just like, oh, I've downloaded this thing. I'm going to start typing notes and see what happens. I have never really had a good organizational system, which I think is fine for me. I was really leaning on pen and paper notes for a while, and I still have a certain use case for them.

+ +

Because I find that when I'm in meetings or one-on-ones and taking notes, I don't actually like to have my hands on the keyboard because of distractions. Like I mentioned earlier, it's really easy for me to, like, oh, accidentally Command-Tab and open Slack and be like, oh, someone posted something new in Slack; let me go read this. And I'm not giving the meeting or the person I'm talking to my full attention, and I really didn't like that.

+ +

So I still do pen and paper for things where I want to make sure that I'm not getting distracted. And then, I will transfer any gems from those notes to Obsidian if I find that they are worth putting in a place where I do have a little bit more discoverability and eventually maybe kind of adding on to my process of using those backlinks and connecting thoughts like that. So, so far, it's truly just a list of separate little pages of notes, and yeah, we'll see how it goes. I'm curious what your system for organizing is or if you have kind of figured out something that works well for you.

+ +

JOËL: So my approach focuses very heavily on the backlinks. It's loosely inspired by two similar systems of organization called Zettelkasten and evergreen notes. The idea is that you create notes that are ideas. Typically, the title is like a thesis statement, and you keep them very short, focused on a single thing. And if you have a more complex idea, it probably breaks down into two or three, and then you link them to each other as makes sense.

+ +

So you create a web of these atomic ideas that are highly interconnected with each other. And then later on, because I use this a lot for either creating content in the future or to help refine my thinking on various software topics, so later on, I can go through and maybe connect three or four things I didn't realize connected together. Or if I'm writing an article or a talk, maybe find three or four of these ideas that I generated at very different moments, but now they're connected. And I can make an article or a talk out of them. So that's sort of the purpose that I use them for and how I've organized things for myself.

+ +

STEPHANIE: I think that's a really interesting topic because while I was assessing different software for note-taking and, like I said, knowledge management, I discovered this blog post by Maggie Appleton that was super interesting because she is talking about the term tools of thought which a lot of these different software kind of leveraged in their marketing copy as like, oh, this software will be like the key to evolving your thinking and help you expand making connections, like you mentioned, in ways that you weren't able to before. And was very obviously trying to upsell you on this product, and she --

+ +

JOËL: It's over the top.

+ +

STEPHANIE: A little bit, a little bit. So in this article, I liked that she took a critical lens to that idea and rooted her article in history and gave examples of a bunch of different things in human history that also evolved the ways humans were able to express their thoughts and solve problems. And so some of the ones that she listed were like storytelling and oral tradition. Literally, the written language obviously [laughs] empowered humans to be able to communicate and think in ways that we never were before but also drawings, and maps, and spreadsheets.

+ +

So I thought that was really cool because she was basically saying that tools of thought don't need to be digital, and people claiming that these software, you know, are the new way to think or whatever, it's like, the way we're thinking now, but we also have this long history of using and developing different things that helped us communicate with each other and think about stuff.

+ +

JOËL: I think that's something that appealed to me when I was looking at some of these note-taking systems. Zettelkasten, in particular, predates digital technology. The original system was built on note cards, and the digital stuff just made it a little bit easier. But I think also when I was reading about these ideas of keeping ideas small and linking them together, I realized that's already kind of how I tend to organize information when I just hold it in my brain or even when I try to do something like a tweet thread on Twitter where I'll try to break it up.

+ +

It might be a larger, more complex idea, but each tweet, I try to get it to kind of stand on its own to make it easier to retweet and all that. And so it becomes a chain of related ideas that maybe build up to something, but each idea stands on its own. And that's kind of how in these systems notes end up working. And they're in a way that you can kind of remix them with each other. So it's not just a linear chain like you would have on Twitter.

+ +

STEPHANIE: Yeah, I remember you all in that episode about note-taking with Amanda talked about the value of having an atomic piece of information in every note that you write. And since then, I've been trying to do that more because, especially when I was doing pen and paper, I would just write very loose, messy thoughts down. And I would just think that maybe I would come back to them one day and try to figure out, like, oh, what did I say here, and can I apply it to something?

+ +

But it's kind of like doing any kind of refactoring or whatever. It's like, in that moment, you have the most context about what you just wrote down or created. And so I've been a little more intentional about trying to take that thought to its logical end, and then hopefully, it will provide value later.

+ +

What you were saying about the connectivity I also wanted to kind of touch on a little bit further because I've realized that for me, a lot of the connection-making happens during times where I'm not very actively trying to think, or reflect, or do a lot of deep work, if you will. Because lately, I've been having a lot of revelations in the shower, or while I'm trying to fall asleep, or just other kinds of meditative activity. And I'm just coming to terms with that's just how my brain works. And doing those kinds of activities has value for me because it's like something is clearly going on in my brain. And I definitely want to just honor that's how it works for me.

+ +

JOËL: I had a great conversation recently with another colleague about the gift of boredom and how that can impact our work and what we think about, and our creativity. That was really great. Sometimes it's important to give ourselves a little bit more blank space in our lives. And counter-intuitively, it can make us more productive, even though we're not scheduling ourselves to be productive.

+ +

STEPHANIE: Yes, I wholeheartedly agree with that. I think a lot about the feeling of boredom, and for me, that is like the middle of summer break when you're still in school and you just had no obligations whatsoever. And you could just do whatever you wanted and could just laze around and be bored. But letting your mind wander during those times is something I really miss.

+ +

And sometimes, when I do experience that feeling, I get a little bit anxious. I'm like, oh, I could be doing something else. There's whatever endless list of chores or things that are, quote, unquote, "productive." But yeah, I really like how you mentioned that there is value in that experience, and it can feel really indulgent, but that can be good too.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you mentioned recently that you've had a lot of revelations or new ideas that have come upon you or that you've been able to dig into a little bit more. Is there one you'd like to share with the audience?

+ +

STEPHANIE: Yeah. So during this downtime that I've had not working on client work, I have been able to keep up a little bit more with Ruby news or just community news in general. And in, I think, an edition of Ruby Weekly, I saw that Ruby 3.2 introduced this new class called data to its core library for the use case of creating simple value objects.

+ +

And I was really excited about this new feature because I remembered that you had written a thoughtbot blog post about value objects back in the summer that I had reviewed. That was an opportunity that I could make a connection between something happening in recent news with some thoughts that I had about this topic a few months ago. But basically, this new class can be used over something like a struct to create objects that are immutable in their values, which is a big improvement if you are trying to follow value objects semantics.

+ +

JOËL: So, I have not played around with the new data class. How is it different from the existing struct that we have in Ruby?

+ +

STEPHANIE: So I think I might actually answer that first by saying how they're similar, which is that they are both vehicles for holding pieces of data. So we've, in the past, been able to use a struct to very cheaply and easily create a new class that has attributes. But one pitfall of using a struct when you're trying to implement something like a value object is that structs also came with writer methods for all of its members.

+ +

And so you could change the value of a member, and that it kind of inherently goes against the semantics of a value object because, ideally, they're immutable. And so, with the data class, it doesn't offer writer methods essentially. And I think that it freezes the instance as well in the constructor. And so even if you tried to add writer methods, you would eventually get an error.

+ +

JOËL: That's really convenient. I think that may be an area where I've been a little bit frustrated with structs in the past, which is that they can be modified. They basically get treated as if they're hashes with a slightly nicer syntax to interact with them. And I want slightly harder boundaries around the data.

+ +

Particularly when I'm using them as value objects, I generally don't want people to modify them because that might lead to some weird bugs in the code where you've got a, I don't know, something represents a time value or a date value or something, and you're trying to do math on it. And instead of giving you a new time or date, value just modifies the first one. And so now your start date is in the past or something because you happen to subtract a time from it to do a calculation. And you can't assign it to a variable anywhere.

+ +

STEPHANIE: Yeah, for sure. Another kind of pitfall I remember noticing about structs were that the struct class includes the enumerable module, which makes a struct kind of like a collection. Whereas if you are using it for a value object, that's maybe not what you want. So there was a bit of discourse about whether or not the data class should inherit from struct. And I think they landed on it not inheriting because then you can draw a line in the sand and have that stricter enforcement of saying like, this is what a data as value object should be, and this is what it should not be. So I found that pretty valuable too.

+ +

JOËL: I think I've heard people talk about sort of two classes of problems that are typically solved with a struct; one is something like a value object where you probably don't want it to be writable. You probably don't want it to be enumerable. And it sounds like data now takes on that role very nicely.

+ +

The other category of problem is that you have just a hash, and you're trying to incrementally migrate it over to some nicer objects in some kind of domain. And struct actually gives you this really nice intermediate phase where it still mostly behaves like a hash if you needed to, but it also behaves like an object. And it can help you incrementally transition away from just a giant hash into something that's a little bit more programmatic.

+ +

STEPHANIE: Yeah, that's a really good point. I think struct will still be a very viable option for that second category that you described. But having this new data class could be a good middle ground before you extract something into its own class because it better encapsulates the idea of a value object.

+ +

And one thing that I remember was really interesting about the article that you wrote was that sometimes people forget to implement certain methods when they're writing their own custom value objects. And these come a bit more out of the box with data and just provide a bit more like...what's the word I'm looking for? I'm looking for...you know when you're bowling, and you have those bumpers, I guess? [laughs]

+ +

JOËL: Uh-huh.

+ +

STEPHANIE: They provide just like safeguards, I guess, for following semantics around value objects that I thought was really important because it's creating an artifact for this concept that didn't exist.

+ +

JOËL: And to recap for the audience here, the difference is in how objects are compared for equality. So value objects, if they have the same internal value, even if they're separate objects in memory, should be considered equal. That's how numbers work. That's how hashes work. Generally, primitives in Ruby behave this way. And structs behave that way, and the new data class, it sounds, also behaves that way. Whereas regular objects that you would make they compare based off of the identity of the object, not its value.

+ +

So if you create two user instances, not ActiveRecord, but you could create a user class, you create two instances in memory. They both have the same attributes. They will be considered not equal to each other because they're not the same instance in memory, and that's fine for something more complex. But when you're dealing with value objects, it's important that two objects that represent the same thing, like a particular time for a unit of measure or something like that, if they have the same internal value, they must be the same.

+ +

STEPHANIE: Right. So prior to the introduction of this class, that wasn't really enforced or codified anywhere. It was something that if you knew what a value object was, you could apply that concept to your code and make sure that the code you wrote was semantically aligned with this concept. And what was kind of exciting to me about the addition of this to the core class library in Ruby is that someone could discover this without having to know what a value object is like more formally.

+ +

They might be able to see the use of a data class and be like, oh, let me look this up in the official Ruby docs. And then they could learn like, okay, here's what that means, and here's some rules for this concept in a way that, like I mentioned earlier, felt very implicit to me prior. So that, I don't know, was a really exciting new development in my eyes.

+ +

JOËL: One of the first episodes that you and I recorded together was about the value of specific vocabulary. And I think part of what the Ruby team has done here is they've taken an implicit concept and given it a name. It's extracted, and it has a name now. And if you use it now, it's because you're doing this data thing, this value object thing. And now there's a documentation page. You can Google it. You can find it rather than just be wondering like, oh, why did someone use a struct in this way and not realize there are some implicit semantics that are different? Or wondering why did the override double equals on this custom class?

+ +

STEPHANIE: Yeah, exactly. I think that the introduction of this class also provides a solution for something that you mentioned in that blog post, which was the idea of testing value objects. Because previously, when you did have to make sure that you implemented methods, those comparison methods to align with the concept of a value object, it was very easy to forget or just not know. And so you provided a potential solution of testing value objects via an RSpec shared example.

+ +

And I remember thinking like, ooh, that was a really hot topic because we had also been debating about shared examples in general. But yeah, I was just thinking that now that it's part of the core library, I think, in some ways, that eliminates the need to test something that is using a data class anyway because we can rely a little bit more on that dependency.

+ +

JOËL: Right? It's the built-in behavior now. Do you have any fun uses for value objects recently?

+ +

STEPHANIE: I have not necessarily had to implement my own recently. But I do think that the next time I work with one or the next time I think that I might want to have something like a value object it will be a lot easier. And I'm just excited to play around with this and see how it will help solve any problem that might come up. So, Joël, do you have any ideas about when you might reach for a data object?

+ +

JOËL: A lot of situations, I think, when you see the primitive obsession smell are a great use case for value objects, or maybe we should call them data objects now, now that this is part of Ruby's vocabulary. I think I often tend to; preemptively sounds bad, but a lot of times, I will try to be careful. Anytime I'm doing anything with raw numbers, magic strings, things like that, I'll try to encapsulate them into some sort of struct. Or even if it's like a pair of numbers, it always goes together, maybe a latitude and longitude.

+ +

Now, those are a pair. Do I want to just be passing around a two-element array all the time or a hash that would probably make a very nice data object? If I have a unit of measure, some number that represents not just the abstract concept of three but specifically three miles or three minutes, then I might reach for something like a data class.

+ +

STEPHANIE: Yeah, I think that's also true if you're doing any kind of arithmetic or, in general, trying to compare anything about two of the same things. That might be a good indicator as well that you could use something richer, like a value object, to make some of that code more readable, and you get some of those convenient methods for doing those comparisons.

+ +

JOËL: Have you ever written code where you just have like some number in the code, and there's a comment afterwards that's like minutes or miles or something like that, just giving you the unit as a comment afterwards?

+ +

STEPHANIE: Oh yeah. I've definitely seen some of that code. And yeah, I mean, now that you mentioned it, that's a great use case for what we're talking about, and it's definitely a code smell.

+ +

JOËL: It can often be nice as you make these more domain concepts; maybe they start as a data object, but then they might grow with their own custom methods. And maybe you extend data the same way you could extend a struct, or maybe you create a custom class to the point where the user...whoever calls that object, doesn't really need to know or care about the particular unit, just like when you have duration value.

+ +

If you have a duration object, you can do the math you want. You can do all the operations and don't have to know whether it is in milliseconds, or seconds, or minutes because it knows that internally and keeps all of the math straight as opposed to just holding on to what I've done before, which is you have some really big number somewhere. You have start is, or length is equal to some big number and then comment milliseconds. And then, hopefully, whoever does math on that number later remembers to do the division by 1,000 or whatever they need.

+ +

STEPHANIE: I've certainly worked on code where we've tolerated those magic numbers for probably longer than we should have because maybe we did have the shared understanding that that value represents minutes or milliseconds or whatever, and that was just part of the domain knowledge. But you're right, like when you see them, and without a very clear label, all of that stuff is implied and is really not very friendly for someone coming along in the future.

+ +

As well as, like you mentioned earlier, if you have to do math on it later to convert it to something else, that is also a red flag that you could use some kind of abstraction or something to represent this concept at a higher level but also be extensible to different forms, so a duration to represent different amounts of time or money to represent different values and different currencies, stuff like that.

+ +

JOËL: Do you have a guideline that you follow as to when something starts being worth extracting into some kind of data object?

+ +

STEPHANIE: I don't know if I have particularly clear guidelines, but I do remember feeling frustrated when I've had to test really complicated hashes or just primitives that are holding a lot of different pieces of information in a way that just is very unwieldy when you do have to write a test for it. And if those things were encapsulated in methods, that would have been a lot easier. And so I think that is a bit of a signal for me. Do you have any other guidelines or gut instincts around that?

+ +

JOËL: We mentioned the comment that is the unit. That's probably a...I wasn't sure if I would have to call it a code smell, but I'm going to call it a code smell that tells you maybe you should...that value wants to be something a little bit more than just a number. I've gotten suspicious of just raw integers in general, not enough to say that I'm going to make all integers data objects now, but enough to make me pause and think a lot of times. What does this number represent? Should it be a data object?

+ +

I think I also tend to default to try to do something like a data object when I'm dealing with API responses. You were talking about hashes and how they can be annoying to test. But also, when you're dealing with data coming back from a third-party API, a giant nested hash is not the most convenient thing to work with, both for the implementation but then also just for the readability of your code. I often try to have almost like a translation layer where very quickly I take the payload from a third-party service and turn it into some kind of object.

+ +

STEPHANIE: Yeah, I think the data class docs itself has an example of using it for HTTP responses because I think the particular implementation doesn't even require it to have attributes. And so you can use it to just label something rather than requiring a value for it.

+ +

JOËL: And that is one thing that is nice about something like a data object versus a hash is that a hash could have literally anything in it. And to a certain extent, a data object is self-documenting. So if I want to know I've gotten to a shopping cart object from a third-party API, what can I get out of the shopping cart?

+ +

I can look at the data object. I can open the class and see here are the methods I can call. If it's just a hash, well, I guess I can try to either find the documentation for the API or try to make a real request and then inspect the hash at runtime. But there's not really any way to find out without actually executing the code.

+ +

STEPHANIE: Yeah, that's totally fair. And what you said about self-documenting makes a lot of sense. And it's always preferable than that stray comment in the code. [laughs]

+ +

JOËL: I'm really excited to use the data class in future Ruby 3.2 projects. So I'm really glad that you brought it up. I've not tried it myself, but I'm excited to use it in future projects.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeeeee!!!!!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Joël's been traveling. Stephanie's working on professional development. She's also keeping up a little bit more with Ruby news and community news in general and saw that Ruby 3.2 introduced a new class called data to its core library for the use case of creating simple value objects.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

Transcript:

+ +

AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been traveling for the past few weeks in Europe. I just recently got back to the U.S. and have just gotten used to drinking American-style drip coffee again after having espresso every day for a few weeks. And it's been an adjustment.

+ +

STEPHANIE: I bet. I think that it's such a downgrade compared to European espresso. I remember when I was in Italy, I also would really enjoy espresso every day at a local cafe and just be like sitting outside drinking it. And it was very delightful.

+ +

JOËL: They're very different experiences. I have to say I do enjoy just holding a hot mug and sort of sipping on it for a long time. It's also a lot weaker. You wouldn't want to do a full hot mug of espresso. That would just be way too intense. But yeah, I think both experiences are enjoyable. They're just different.

+ +

STEPHANIE: Yeah. So, that first day with your measly drip coffee and your jet lag, how are you doing on your first day back at work?

+ +

JOËL: I did pretty good. I think part of the fun of coming back to the U.S. from Europe is that the jet lag makes me a very productive morning person for a week. Normally, I'm a little bit more of an evening person. So I get to get a bit of an alter ego for a week, and that helps me to transition back into work.

+ +

STEPHANIE: Nice.

+ +

JOËL: So you've also been on break and have started work again. How are you feeling productivity-wise, kicking off the New Year?

+ +

STEPHANIE: I'm actually unbooked this week and the last week too. So I'm not working on client projects, but I am having a lot of time to work on just professional development. And usually, during this downtime, I also like to reassess just how I'm working, and lately, what that has meant for me is changing my note-taking process. And I'm really excited to share this with you because I know that you have talked about this on the show before, I think in a previous episode with a guest, Amanda Beiner.

+ +

And I listened to that episode, and I was really inspired because I was feeling like I didn't have a note-taking system that worked super well for me. But you all talked about some tools you used and some, I guess, philosophies around note-taking that like I said, I was really inspired by. And so I hopped on board the Obsidian train. And I'm really excited to share with you my experience with it.

+ +

So I really like it because I previously was taking notes in my editor under the impression that, oh, like, everything is in one place. It'll be like a seamless transition from code to note-taking. And I was already writing in Markdown. But I actually didn't like it that much because I found it kind of distracting to have code things kind of around. And if I was navigating files or something, something work or code-related might come up, and that ended up being a bit distracting for me. But I know that that works really well for some people; a coworker of ours, Aji, I know that he takes his notes in Vim and has a really fancy setup for that.

+ +

And so I thought maybe that's what I wanted, but it turns out that what I wanted was actually more of a boundary between code and notes. And so, I was assessing different note-taking and knowledge management software. And I have been really enjoying Obsidian because it also has quite a bit of community support. So I've installed a few plugins for just quality-of-life features like snippets which I had in my editor, and now I get to have in Obsidian.

+ +

I also installed things like Natural Language Dates. So for my running to-do list, I can just do a shortcut for today, and it'll autofill today's date, which, I don't know, because for me, [laughs] that is just a little bit less mental work that I have to do to remember the date. And yeah, I've been really liking it. I haven't even fully explored backlinking, and that connectivity aspect, which I know is a core feature, but it's been working well for me so far.

+ +

JOËL: That's really exciting. I love notes and note-taking and the ways that we can use those to make our lives better as developers and as human beings. Do you have a particular system or way you've approached that? Because I know for me, I probably looked at Obsidian for six months before I kind of had the courage to download it because I didn't want to go into it and not have a way to organize things.

+ +

I was like; I don't want to just throw random notes in here. I want to have a system. That might just be me. But did you just kind of jump into it and see, like, oh, a system will emerge? Did you have a particular philosophy going in? How are you approaching taking notes there?

+ +

STEPHANIE: That's definitely a you thing because I've definitely had the opposite experience [laughs] where I'm just like, oh, I've downloaded this thing. I'm going to start typing notes and see what happens. I have never really had a good organizational system, which I think is fine for me. I was really leaning on pen and paper notes for a while, and I still have a certain use case for them.

+ +

Because I find that when I'm in meetings or one-on-ones and taking notes, I don't actually like to have my hands on the keyboard because of distractions. Like I mentioned earlier, it's really easy for me to, like, oh, accidentally Command-Tab and open Slack and be like, oh, someone posted something new in Slack; let me go read this. And I'm not giving the meeting or the person I'm talking to my full attention, and I really didn't like that.

+ +

So I still do pen and paper for things where I want to make sure that I'm not getting distracted. And then, I will transfer any gems from those notes to Obsidian if I find that they are worth putting in a place where I do have a little bit more discoverability and eventually maybe kind of adding on to my process of using those backlinks and connecting thoughts like that. So, so far, it's truly just a list of separate little pages of notes, and yeah, we'll see how it goes. I'm curious what your system for organizing is or if you have kind of figured out something that works well for you.

+ +

JOËL: So my approach focuses very heavily on the backlinks. It's loosely inspired by two similar systems of organization called Zettelkasten and evergreen notes. The idea is that you create notes that are ideas. Typically, the title is like a thesis statement, and you keep them very short, focused on a single thing. And if you have a more complex idea, it probably breaks down into two or three, and then you link them to each other as makes sense.

+ +

So you create a web of these atomic ideas that are highly interconnected with each other. And then later on, because I use this a lot for either creating content in the future or to help refine my thinking on various software topics, so later on, I can go through and maybe connect three or four things I didn't realize connected together. Or if I'm writing an article or a talk, maybe find three or four of these ideas that I generated at very different moments, but now they're connected. And I can make an article or a talk out of them. So that's sort of the purpose that I use them for and how I've organized things for myself.

+ +

STEPHANIE: I think that's a really interesting topic because while I was assessing different software for note-taking and, like I said, knowledge management, I discovered this blog post by Maggie Appleton that was super interesting because she is talking about the term tools of thought which a lot of these different software kind of leveraged in their marketing copy as like, oh, this software will be like the key to evolving your thinking and help you expand making connections, like you mentioned, in ways that you weren't able to before. And was very obviously trying to upsell you on this product, and she --

+ +

JOËL: It's over the top.

+ +

STEPHANIE: A little bit, a little bit. So in this article, I liked that she took a critical lens to that idea and rooted her article in history and gave examples of a bunch of different things in human history that also evolved the ways humans were able to express their thoughts and solve problems. And so some of the ones that she listed were like storytelling and oral tradition. Literally, the written language obviously [laughs] empowered humans to be able to communicate and think in ways that we never were before but also drawings, and maps, and spreadsheets.

+ +

So I thought that was really cool because she was basically saying that tools of thought don't need to be digital, and people claiming that these software, you know, are the new way to think or whatever, it's like, the way we're thinking now, but we also have this long history of using and developing different things that helped us communicate with each other and think about stuff.

+ +

JOËL: I think that's something that appealed to me when I was looking at some of these note-taking systems. Zettelkasten, in particular, predates digital technology. The original system was built on note cards, and the digital stuff just made it a little bit easier. But I think also when I was reading about these ideas of keeping ideas small and linking them together, I realized that's already kind of how I tend to organize information when I just hold it in my brain or even when I try to do something like a tweet thread on Twitter where I'll try to break it up.

+ +

It might be a larger, more complex idea, but each tweet, I try to get it to kind of stand on its own to make it easier to retweet and all that. And so it becomes a chain of related ideas that maybe build up to something, but each idea stands on its own. And that's kind of how in these systems notes end up working. And they're in a way that you can kind of remix them with each other. So it's not just a linear chain like you would have on Twitter.

+ +

STEPHANIE: Yeah, I remember you all in that episode about note-taking with Amanda talked about the value of having an atomic piece of information in every note that you write. And since then, I've been trying to do that more because, especially when I was doing pen and paper, I would just write very loose, messy thoughts down. And I would just think that maybe I would come back to them one day and try to figure out, like, oh, what did I say here, and can I apply it to something?

+ +

But it's kind of like doing any kind of refactoring or whatever. It's like, in that moment, you have the most context about what you just wrote down or created. And so I've been a little more intentional about trying to take that thought to its logical end, and then hopefully, it will provide value later.

+ +

What you were saying about the connectivity I also wanted to kind of touch on a little bit further because I've realized that for me, a lot of the connection-making happens during times where I'm not very actively trying to think, or reflect, or do a lot of deep work, if you will. Because lately, I've been having a lot of revelations in the shower, or while I'm trying to fall asleep, or just other kinds of meditative activity. And I'm just coming to terms with that's just how my brain works. And doing those kinds of activities has value for me because it's like something is clearly going on in my brain. And I definitely want to just honor that's how it works for me.

+ +

JOËL: I had a great conversation recently with another colleague about the gift of boredom and how that can impact our work and what we think about, and our creativity. That was really great. Sometimes it's important to give ourselves a little bit more blank space in our lives. And counter-intuitively, it can make us more productive, even though we're not scheduling ourselves to be productive.

+ +

STEPHANIE: Yes, I wholeheartedly agree with that. I think a lot about the feeling of boredom, and for me, that is like the middle of summer break when you're still in school and you just had no obligations whatsoever. And you could just do whatever you wanted and could just laze around and be bored. But letting your mind wander during those times is something I really miss.

+ +

And sometimes, when I do experience that feeling, I get a little bit anxious. I'm like, oh, I could be doing something else. There's whatever endless list of chores or things that are, quote, unquote, "productive." But yeah, I really like how you mentioned that there is value in that experience, and it can feel really indulgent, but that can be good too.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So you mentioned recently that you've had a lot of revelations or new ideas that have come upon you or that you've been able to dig into a little bit more. Is there one you'd like to share with the audience?

+ +

STEPHANIE: Yeah. So during this downtime that I've had not working on client work, I have been able to keep up a little bit more with Ruby news or just community news in general. And in, I think, an edition of Ruby Weekly, I saw that Ruby 3.2 introduced this new class called data to its core library for the use case of creating simple value objects.

+ +

And I was really excited about this new feature because I remembered that you had written a thoughtbot blog post about value objects back in the summer that I had reviewed. That was an opportunity that I could make a connection between something happening in recent news with some thoughts that I had about this topic a few months ago. But basically, this new class can be used over something like a struct to create objects that are immutable in their values, which is a big improvement if you are trying to follow value objects semantics.

+ +

JOËL: So, I have not played around with the new data class. How is it different from the existing struct that we have in Ruby?

+ +

STEPHANIE: So I think I might actually answer that first by saying how they're similar, which is that they are both vehicles for holding pieces of data. So we've, in the past, been able to use a struct to very cheaply and easily create a new class that has attributes. But one pitfall of using a struct when you're trying to implement something like a value object is that structs also came with writer methods for all of its members.

+ +

And so you could change the value of a member, and that it kind of inherently goes against the semantics of a value object because, ideally, they're immutable. And so, with the data class, it doesn't offer writer methods essentially. And I think that it freezes the instance as well in the constructor. And so even if you tried to add writer methods, you would eventually get an error.

+ +

JOËL: That's really convenient. I think that may be an area where I've been a little bit frustrated with structs in the past, which is that they can be modified. They basically get treated as if they're hashes with a slightly nicer syntax to interact with them. And I want slightly harder boundaries around the data.

+ +

Particularly when I'm using them as value objects, I generally don't want people to modify them because that might lead to some weird bugs in the code where you've got a, I don't know, something represents a time value or a date value or something, and you're trying to do math on it. And instead of giving you a new time or date, value just modifies the first one. And so now your start date is in the past or something because you happen to subtract a time from it to do a calculation. And you can't assign it to a variable anywhere.

+ +

STEPHANIE: Yeah, for sure. Another kind of pitfall I remember noticing about structs were that the struct class includes the enumerable module, which makes a struct kind of like a collection. Whereas if you are using it for a value object, that's maybe not what you want. So there was a bit of discourse about whether or not the data class should inherit from struct. And I think they landed on it not inheriting because then you can draw a line in the sand and have that stricter enforcement of saying like, this is what a data as value object should be, and this is what it should not be. So I found that pretty valuable too.

+ +

JOËL: I think I've heard people talk about sort of two classes of problems that are typically solved with a struct; one is something like a value object where you probably don't want it to be writable. You probably don't want it to be enumerable. And it sounds like data now takes on that role very nicely.

+ +

The other category of problem is that you have just a hash, and you're trying to incrementally migrate it over to some nicer objects in some kind of domain. And struct actually gives you this really nice intermediate phase where it still mostly behaves like a hash if you needed to, but it also behaves like an object. And it can help you incrementally transition away from just a giant hash into something that's a little bit more programmatic.

+ +

STEPHANIE: Yeah, that's a really good point. I think struct will still be a very viable option for that second category that you described. But having this new data class could be a good middle ground before you extract something into its own class because it better encapsulates the idea of a value object.

+ +

And one thing that I remember was really interesting about the article that you wrote was that sometimes people forget to implement certain methods when they're writing their own custom value objects. And these come a bit more out of the box with data and just provide a bit more like...what's the word I'm looking for? I'm looking for...you know when you're bowling, and you have those bumpers, I guess? [laughs]

+ +

JOËL: Uh-huh.

+ +

STEPHANIE: They provide just like safeguards, I guess, for following semantics around value objects that I thought was really important because it's creating an artifact for this concept that didn't exist.

+ +

JOËL: And to recap for the audience here, the difference is in how objects are compared for equality. So value objects, if they have the same internal value, even if they're separate objects in memory, should be considered equal. That's how numbers work. That's how hashes work. Generally, primitives in Ruby behave this way. And structs behave that way, and the new data class, it sounds, also behaves that way. Whereas regular objects that you would make they compare based off of the identity of the object, not its value.

+ +

So if you create two user instances, not ActiveRecord, but you could create a user class, you create two instances in memory. They both have the same attributes. They will be considered not equal to each other because they're not the same instance in memory, and that's fine for something more complex. But when you're dealing with value objects, it's important that two objects that represent the same thing, like a particular time for a unit of measure or something like that, if they have the same internal value, they must be the same.

+ +

STEPHANIE: Right. So prior to the introduction of this class, that wasn't really enforced or codified anywhere. It was something that if you knew what a value object was, you could apply that concept to your code and make sure that the code you wrote was semantically aligned with this concept. And what was kind of exciting to me about the addition of this to the core class library in Ruby is that someone could discover this without having to know what a value object is like more formally.

+ +

They might be able to see the use of a data class and be like, oh, let me look this up in the official Ruby docs. And then they could learn like, okay, here's what that means, and here's some rules for this concept in a way that, like I mentioned earlier, felt very implicit to me prior. So that, I don't know, was a really exciting new development in my eyes.

+ +

JOËL: One of the first episodes that you and I recorded together was about the value of specific vocabulary. And I think part of what the Ruby team has done here is they've taken an implicit concept and given it a name. It's extracted, and it has a name now. And if you use it now, it's because you're doing this data thing, this value object thing. And now there's a documentation page. You can Google it. You can find it rather than just be wondering like, oh, why did someone use a struct in this way and not realize there are some implicit semantics that are different? Or wondering why did the override double equals on this custom class?

+ +

STEPHANIE: Yeah, exactly. I think that the introduction of this class also provides a solution for something that you mentioned in that blog post, which was the idea of testing value objects. Because previously, when you did have to make sure that you implemented methods, those comparison methods to align with the concept of a value object, it was very easy to forget or just not know. And so you provided a potential solution of testing value objects via an RSpec shared example.

+ +

And I remember thinking like, ooh, that was a really hot topic because we had also been debating about shared examples in general. But yeah, I was just thinking that now that it's part of the core library, I think, in some ways, that eliminates the need to test something that is using a data class anyway because we can rely a little bit more on that dependency.

+ +

JOËL: Right? It's the built-in behavior now. Do you have any fun uses for value objects recently?

+ +

STEPHANIE: I have not necessarily had to implement my own recently. But I do think that the next time I work with one or the next time I think that I might want to have something like a value object it will be a lot easier. And I'm just excited to play around with this and see how it will help solve any problem that might come up. So, Joël, do you have any ideas about when you might reach for a data object?

+ +

JOËL: A lot of situations, I think, when you see the primitive obsession smell are a great use case for value objects, or maybe we should call them data objects now, now that this is part of Ruby's vocabulary. I think I often tend to; preemptively sounds bad, but a lot of times, I will try to be careful. Anytime I'm doing anything with raw numbers, magic strings, things like that, I'll try to encapsulate them into some sort of struct. Or even if it's like a pair of numbers, it always goes together, maybe a latitude and longitude.

+ +

Now, those are a pair. Do I want to just be passing around a two-element array all the time or a hash that would probably make a very nice data object? If I have a unit of measure, some number that represents not just the abstract concept of three but specifically three miles or three minutes, then I might reach for something like a data class.

+ +

STEPHANIE: Yeah, I think that's also true if you're doing any kind of arithmetic or, in general, trying to compare anything about two of the same things. That might be a good indicator as well that you could use something richer, like a value object, to make some of that code more readable, and you get some of those convenient methods for doing those comparisons.

+ +

JOËL: Have you ever written code where you just have like some number in the code, and there's a comment afterwards that's like minutes or miles or something like that, just giving you the unit as a comment afterwards?

+ +

STEPHANIE: Oh yeah. I've definitely seen some of that code. And yeah, I mean, now that you mentioned it, that's a great use case for what we're talking about, and it's definitely a code smell.

+ +

JOËL: It can often be nice as you make these more domain concepts; maybe they start as a data object, but then they might grow with their own custom methods. And maybe you extend data the same way you could extend a struct, or maybe you create a custom class to the point where the user...whoever calls that object, doesn't really need to know or care about the particular unit, just like when you have duration value.

+ +

If you have a duration object, you can do the math you want. You can do all the operations and don't have to know whether it is in milliseconds, or seconds, or minutes because it knows that internally and keeps all of the math straight as opposed to just holding on to what I've done before, which is you have some really big number somewhere. You have start is, or length is equal to some big number and then comment milliseconds. And then, hopefully, whoever does math on that number later remembers to do the division by 1,000 or whatever they need.

+ +

STEPHANIE: I've certainly worked on code where we've tolerated those magic numbers for probably longer than we should have because maybe we did have the shared understanding that that value represents minutes or milliseconds or whatever, and that was just part of the domain knowledge. But you're right, like when you see them, and without a very clear label, all of that stuff is implied and is really not very friendly for someone coming along in the future.

+ +

As well as, like you mentioned earlier, if you have to do math on it later to convert it to something else, that is also a red flag that you could use some kind of abstraction or something to represent this concept at a higher level but also be extensible to different forms, so a duration to represent different amounts of time or money to represent different values and different currencies, stuff like that.

+ +

JOËL: Do you have a guideline that you follow as to when something starts being worth extracting into some kind of data object?

+ +

STEPHANIE: I don't know if I have particularly clear guidelines, but I do remember feeling frustrated when I've had to test really complicated hashes or just primitives that are holding a lot of different pieces of information in a way that just is very unwieldy when you do have to write a test for it. And if those things were encapsulated in methods, that would have been a lot easier. And so I think that is a bit of a signal for me. Do you have any other guidelines or gut instincts around that?

+ +

JOËL: We mentioned the comment that is the unit. That's probably a...I wasn't sure if I would have to call it a code smell, but I'm going to call it a code smell that tells you maybe you should...that value wants to be something a little bit more than just a number. I've gotten suspicious of just raw integers in general, not enough to say that I'm going to make all integers data objects now, but enough to make me pause and think a lot of times. What does this number represent? Should it be a data object?

+ +

I think I also tend to default to try to do something like a data object when I'm dealing with API responses. You were talking about hashes and how they can be annoying to test. But also, when you're dealing with data coming back from a third-party API, a giant nested hash is not the most convenient thing to work with, both for the implementation but then also just for the readability of your code. I often try to have almost like a translation layer where very quickly I take the payload from a third-party service and turn it into some kind of object.

+ +

STEPHANIE: Yeah, I think the data class docs itself has an example of using it for HTTP responses because I think the particular implementation doesn't even require it to have attributes. And so you can use it to just label something rather than requiring a value for it.

+ +

JOËL: And that is one thing that is nice about something like a data object versus a hash is that a hash could have literally anything in it. And to a certain extent, a data object is self-documenting. So if I want to know I've gotten to a shopping cart object from a third-party API, what can I get out of the shopping cart?

+ +

I can look at the data object. I can open the class and see here are the methods I can call. If it's just a hash, well, I guess I can try to either find the documentation for the API or try to make a real request and then inspect the hash at runtime. But there's not really any way to find out without actually executing the code.

+ +

STEPHANIE: Yeah, that's totally fair. And what you said about self-documenting makes a lot of sense. And it's always preferable than that stray comment in the code. [laughs]

+ +

JOËL: I'm really excited to use the data class in future Ruby 3.2 projects. So I'm really glad that you brought it up. I've not tried it myself, but I'm excited to use it in future projects.

+ +

STEPHANIE: On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeeeeee!!!!!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ml9bCATW + + ]]> + + Joël Quenneville + Stephanie Minn + + + 366: Componentization and Branching Strategies + https://bikeshed.thoughtbot.com/366 + c6d59624-8417-4a0b-a62a-401309151e40 + Tue, 10 Jan 2023 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Happy New Year! It's 2023 🎉 Joël and Stephanie chat about developer resolutions or things they'd like to do this year and then discuss componentization and branching strategies. + 38:31 + no + + + Happy New Year! It's 2023 🎉 Joël and Stephanie chat about developer resolutions or things they'd like to do this year and then discuss componentization and branching strategies. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Joël's Elm Meetup talk wasn't recorded but the slides are here (https://speakerdeck.com/joelq/structuring-views-in-elm) +Joël hasn't published an article on the 3 principles of branching, but he does discuss them in this twitter thread (https://twitter.com/joelquen/status/1091039877918048256) +Making Impossible States Impossible (https://www.youtube.com/watch?v=IcgmSRJHu_8) +Cardinalities (https://guide.elm-lang.org/appendix/types_as_sets.html) +Component-Driven Development (https://www.componentdriven.org/) +Storybook (https://storybook.js.org/) +BEM (https://getbem.com/) +View Components at GitHub (https://viewcomponent.org/viewcomponents-at-github.html) +Confident Ruby (https://store.avdi.codes/l/rrWapR?layout=profile) +Case Expressions Episode (https://www.bikeshed.fm/352) +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, as of the time that this episode goes live, it's the new year; it's 2023. Happy New Year. +STEPHANIE: Happy New Year, Joël, and Happy New Year to our listeners. +JOËL: So, new year is oftentimes where people like to take maybe resolutions or plan a little bit out of their year. I'm curious, Stephanie, do you have any developer resolutions or things that you'd like to do this year? +STEPHANIE: So, I think last episode, we were talking a little bit about reflection, especially in terms of career progression. And I may have mentioned that I don't really believe in New Year's resolutions. [laughs] But I do think that one intention that I have for myself is to chill a little bit. I think the fall of 2022, for me, was really hectic, exciting but a little busy in terms of speaking and content creation; you know, we started doing this podcast together. And so I do think that winter is my time of hibernation. +Development-wise, one goal that was really inspiring for me that you shared is writing ten blog posts a year. And I think I might keep that in the back of my head as we get into the new year and maybe start to at least just have it in my mind. So if I see anything that comes up, I can be like, oh yes, I had this intention to write more blog posts, which I think might be helpful to just marinate on even during my chill time. +Because when I do finally feel productive and energized again, I can at least have been thinking about it. And I think doing that reflection and marinating is also work, even if it doesn't end up turning into an artifact or anything like that. And so yeah, that's my plan for the beginning of the year, at least. +And then, on a personal note, I'm on a journey to be warm this winter and not be miserable and cold. So as a recovering Californian in Chicago these days, I have just always wanted to stay in and be a little bit of a hermit in the winter because I just have a hard time with the cold. But then I learned that you can just buy things that will help keep you warm. +And so, a recent purchase of mine was a heated, portable blanket. So I will definitely be repping that in my Zoom calls and on the couch. And I've just gotten really stocked up on the warm weather accessories, so fingerless gloves and the like. So I'm excited to just not be miserable this winter. That's my plan for the new year. +JOËL: You'll have to report back on how well that goes, how you feel about that blanket. +STEPHANIE: Oh yeah, I definitely will. Maybe I'll even wear it when we're recording. +JOËL: Maybe next year we can make a gift guide. +STEPHANIE: That would be so fun. I would like that: a gift guide for developers or the developer in your life. +JOËL: Right. Fingerless gloves just because it looks cool. [laughs] +STEPHANIE: I'm wearing them right now. Yeah, I can type, and my hands stay warm, highly recommend. +JOËL: So it's not just a hacker thing to look cool. It actually works. +STEPHANIE: I would say so. As someone who has very cold extremities, it's been a good solution for me. +JOËL: You'd mentioned in a previous episode talking about conference talk ideas that you like to marinate in sort of build up a file of ideas over the course of a year. And it sounds like you're taking that approach but then also applying it to smaller form content like blog posts over the course of this winter. +STEPHANIE: I think so. I realized something about myself is that I am a bit of a slow cooker in terms of coming up with ideas, especially if they're rooted in experience. I think it takes me the process of going through something like going through a client project and then honestly, three months later being like, oh, now I can have some distance from it and be like, oh, this is what I was thinking, or this is what I noticed or observed, which I think that's just how I am, and that's okay. I recognize that I don't necessarily churn out content all the time, and, for me, it kind of does feel more like seasons or cycles. +JOËL: So it's funny you mentioned the ten blog posts goal, and that's what I was going to share for my developer goal for the year. I've had that for the past several years. It's a really fun goal to have, I think, because it's aggressive enough that it requires me to put out a fair amount of content, but it's also achievable. +That being said, as of the time of this recording, which is at some undisclosed time prior to the New Year, I only have eight articles that are live on the thoughtbot blog. So for all you listeners in the future in 2023, if you're curious if I achieved my 2022 goals, go check the thoughtbot blog and see did I successfully publish the last two before the end of the month. +STEPHANIE: One thing you had mentioned to me off-air was that you do also tend to backload blog posts towards the end of the year once you realize that that deadline is coming up. Do you think you will do something differently in 2023? +JOËL: I would like to write a little bit more early in the year. I think I'll have to figure out exactly how I want some of my goals to play out. I think I mentioned this in the previous episode; two large themes that I've wanted to focus on are ways to invest in our team and our teammates and then creating content, so things like blog posts, like this podcast, like conference talks. Those were two broad themes that I had given my year in 2022. And I really enjoy those. I think I would want to repeat those themes for 2023 as well, so figuring out exactly how I'm going to interweave them, something I'm going to iterate on. +STEPHANIE: Have you considered breaking down that yearly goal into smaller time intervals, so maybe two or three blog posts a quarter? +JOËL: That might be a better way to do it to make sure that I'm on track. I give myself this as a goal. I'm not super hard on myself if I don't hit it, although I have hit it for multiple years. If I only have eight blog posts this year, that's still an accomplishment I'm proud of. And I think there's some good content that I put out. So I will not be distraught if I don't hit the 10, but it's good to be aiming for something. +STEPHANIE: Yeah, that's a good mindset to have. I also have a personal goal of reading 52 books a year. And this will be my third year attempting to do so. Or, I guess I have been successful in 2021 and 2022 now. But I remember when I first wanted to do it; I didn't tell anyone because I was terrified of not meeting that goal and just feeling a bit disappointed in myself. +And so, I just kept it to myself and didn't mention it to anyone until I got to around 40 or 45 bookmark, and then I could confidently tell people about my goal because, at that point, I was on track and feeling pretty confident that I was going to finish it. So that's my strategy [chuckles] is to not tell anyone until I am pretty much there and then share, and people can be impressed. +JOËL: I feel like there's always a bit of a tension there where when you've got a goal, sometimes you don't want to tell people about it because you don't want to say a thing and then disappoint other people and not get it done. But in some ways, for me, when I can get a goal out of my head and out into almost the real world by telling someone, it makes that goal more real and maybe inspires me to work harder towards it but also maybe helps me believe in myself a little bit more because I've said it out loud. +And, I don't know, maybe saying it in front of a mirror would have the same effect. But getting it out of just my thinking pattern and saying it, "This is what I think I'm going to achieve. This is what I'm trying to do," somehow makes the goal more real for me, makes it more achievable. +STEPHANIE: That makes sense. It's like the difference between saying, "I think I'm going to do this," and "Okay, I'm going to do this." +JOËL: Right. And maybe there's a little bit of social pressure too, if I tell someone, now I don't want to disappoint them. That can be bad because it causes me to doubt myself, but in small amounts, it can maybe help me to push through moments of doubt or moments of feeling like I want to give up. +STEPHANIE: Yeah, I mean, either way, even if you only ended up with eight blog posts in a year, people are just really excited that you're putting content out there. And they're not counting how many posts you put out. +JOËL: In a sense, it's purely a vanity metric for me to know my progress. +STEPHANIE: So I have one thing that happened this week that I would be curious to get your input on. On my client project, I was tasked with making a small UI change to a navigation menu that existed as a separate React project within our Rails repo. And so the task was for...we had this little caret icon that was used in the mobile nav, and the designer wanted it to be reused somewhere else on the desktop nav menu. +And I was digging through the codebase looking to see where the caret was already. And I realized that it was done with CSS on the menu label. So it was really coupled to this menu label and wasn't reusable in that current state. So it took me a little while to figure out how to pull out the seams and extract it into its own component so I could reuse it where I needed it to. +And so I was trying to figure out how we got here because we are using the styled-components library, which should encourage componentization. And I was just thinking about different approaches to building UI features from scratch. And I did a little bit of digging and learned about component-driven development, which suggests the idea of building each component in isolation and thinking through all the relevant states that it might exist in for at least your first couple of use cases and then combining them to create larger components, and then ultimately pages. +And that was interesting to me because it's a little bit different from a strategy that I'm used to, especially if you're implementing a new page or template where you just kind of scaffold out all of your HTML elements that you need. But then when you add on styling, those primitive components, you might end up having a lot of duplication if you are creating very generic things like buttons that end up being coupled to the page that you're working on, especially if you are putting them on the page in a very specific way. +And you might add CSS rules like margins or padding that, again, is coupled to that particular UI that you're building. So I'm curious if you've really thought about building UI from a component level and starting small and then building out or if you also take it from a top-down approach. +JOËL: It's interesting that you mentioned that the component approach really deals with figuring out state. And I think that's probably an area where it shines a lot when you have situations where components can have multiple states. And it's very easy when you're looking at much more of a scenario-driven approach where you just want to say, oh, I want this form input to look like this, like this one mock. But that was only showing the happy path. And you didn't think about all those other states. And so, for situations where you might have a lot of states, the component approach, I think, is really interesting. +I had a really fantastic experience a few years ago pairing with a thoughtbot designer on fairly...well, what we thought was going to be a simple form input. And it turned out that it had a lot of edge cases and funny state things that could happen. And we ended up drawing what essentially was a...you might call that a finite-state machine in a more formal sense. But it's basically a diagram where we show the state of the input. And then we would say, what are the different things that can happen that might transition it into another state? +So maybe it starts empty, but then you start typing, and then something happens, or you have an invalid value, and then something happens. But then, from the invalid state, can you come back to the empty state? Can you come back into the typing state? At what point do we show a read error? Do we clear it out while you're typing? Even after you have an error, this particular input was also backed by some remote data. So it was like a typeahead kind of thing pulling data from a server. +And there were a lot of extra edge cases for things like, oh, we're waiting for results, or no results matched, or we got exactly one result. And so that was really interesting. We ended up building up this whole diagram where we showed all the transitions that could happen, the ways you can loop back to a previous state, and it forced us to think about a lot of edge cases that we wouldn't have thought of otherwise. +STEPHANIE: That's really interesting. I think the transitions between different states definitely can get really complicated. While you were saying that, I was reminded of Storybook, the tool for building out components in isolation. And one thing that I really like is that they encourage you to think about different states and edge cases as almost like user stories. I think they're called stories. And you can use their DSL to extract those pieces of information and basically think through kind of what you were saying, but it's built into the tool. And so it really encourages that thought process. +Because I definitely have run into just trying to build out a basic button or something but then having all of these questions that I have to ask designers while I'm implementing it to be like, what should happen here? Or, like, what should it look like when it's disabled, or what happens when it, like you mentioned, gets back data that it wasn't expecting or something like that? +JOËL: Sometimes you have situations where your page doesn't have a lot of state, or your components don't really have a lot of state. And it really is just a static page. In those situations, now you're looking at questions more of reusability rather than state management. And you may or may not want some kind of componentized approach for that. That might be a little bit different depending on, like; you may not be using React if it's a completely static page. +So maybe this is server-rendered, and you're trying to componentize using Rails helpers. Or you're using something like BEM the CSS...I don't know if you'd call it a framework or a structural approach of defining classes that are in a more componentized approach so that you can reuse styles. So there are a lot of ways to reuse and componentize. Even though I think oftentimes when we talk about visual components, we're often thinking about React. +STEPHANIE: Yeah, I also did a little digging into ViewComponents because I was, again, just kind of trying to think of a mental model for how to approach building out UIs. And in their docs, they have a really good example about their process for using ViewComponents at GitHub. And basically, the progression is that they implement a single use case component that might live as it is for a while until there is some other use case for that component, and then maybe it's adapted for general use in multiple locations. +And then, if it turns out to be like a really good generic building block, they actually extract it into their open-source component library called Primer, I think is what it is. So that was an interesting process for me as someone who just kind of like did that first step of pulling out this little piece into its own component. And then, right now, it isn't necessarily quite ready for being reused in a bunch of different ways. But I think that was a good first step in setting it up to be able to. +JOËL: Definitely. I think it's easy to overDRY or, in this case, it's almost like over abstract in preparation for reuse that might never happen. But oftentimes, it's an incremental thing where you do as much as it makes sense for your current scenario while also leaving yourself the option to easily keep going down that path for future scenarios where there is more duplication. And then, if those scenarios never come, then great, you've saved yourself some work. And if the scenarios do come, then hopefully, it's easy to take the next step. +I gave a talk several years ago at an Elm meetup. Elm is a front-end language that compiles down to JavaScript. And in Elm they don't have components in the same way that React might have. Everything is just functions because of its very functional DNA. And I was talking about how to structure the view layer in terms of functions and how to do so cleanly in a way that is reusable. And one guideline that I had for myself for structuring this kind of code is that a function can either do something or it can branch, but it can't do both. +So if a function (But you can think component here.) is splitting in two different situations, then it doesn't get to have any logic inside it. It just calls out to some other component. And the only thing that it does is say, "I'm a branching component. If this happens, pull this other subcomponent; otherwise, bring in this subcomponent and maybe set up some arguments or something like that." And then the other child components that are rendering various pieces of UI, they don't get to branch. They are just given this data, render it in this way. +STEPHANIE: That makes a lot of sense. I think that also reminds me of the philosophy of separating your components to be container components or presentational components, where there are some that are just focused on what is being rendered and others that have more of that logic in determining what should or should not be displayed. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: It's interesting that we're talking about branching, how to structure it, how to model components that deal with branching or that have to be called from a branch because branching is something that I've been thinking about a lot for the past couple of years. One thing I noticed that we tend to do as developers is that we really, really want to force everything down a single path as much as possible. +Like, there is a main path, and then if you have to branch off of it, you go off on the side path. As short as possible, find a way to merge back onto the main path. But there is one single main path in your program, and everything tries to merge back into it. Have you encountered that in your own coding journey? +STEPHANIE: Do you mean having a lot of conditionals along this single path that might take you elsewhere but then, in the end, are just little tangents, and you're trying to get back to that main execution of code? +JOËL: Yes. An example of that might be dealing with a value that is potentially nil in Ruby or null in JavaScript. And so you check if that value is present, and then you do some things. And then you want to do something else, so you have to, again, check if the value is present and then potentially do the next step. And then, again, check if the value is present. And you end up repeating this conditional multiple times. +We have some constructs that make this a little bit nicer. Ruby has the lonely operator that will just sort of keep passing that nil down in a safe way. But it is still doing a nil check at every step of your long chain of actions you're trying to take because that value is potentially null at every step. +STEPHANIE: The lonely operator being the safe navigation operator. Is that right? +JOËL: Yes, that's right. That is another name for it. +STEPHANIE: Okay, cool. Glad we're on the same page. +JOËL: The &. We have some quirky names for operators in Ruby. +STEPHANIE: Yeah, we sure do. I hadn't heard of lonely before, so that was a really cool tidbit for me. +JOËL: There's also the spaceship operator, which is the less than equal greater than for comparing objects with comparable. +STEPHANIE: Ooh, I like that. I've also heard squid operator for interpolating Ruby in ERB. +JOËL: Nice. +STEPHANIE: I think, in my experience, I have seen that chaining of the safe navigation operator and the chaining of checking for nil in code that doesn't quite utilize the Tell, Don't Ask principle where you have to check for nil and all the objects down the line rather than having that functionality extracted in a method that is then, in my opinion, more correctly co-located with the relevant domain model. So I'm curious if you think that the conditionals themselves are an issue or if it's just the way that they were implemented or where they exist. +JOËL: In this particular case, I would say the conditionals are a code smell, and they're probably extraneous. You're checking the theme value for null again, or maybe you're checking a derived value for null that you don't need to because you've already checked it earlier. It's code that is not confident because the uncertainty from that initial nil has sort of bled through all of your code. +A classic solution to this problem is to try to push the uncertainty to the edges of your system. And a great resource for that is the book Confident Ruby by Avdi Grimm, which talks about all sorts of techniques for dealing with a lot of those uncertainties that you deal with in code and how to push those to the edges of your system. +STEPHANIE: Thanks. That does actually remind me of what you were saying about componentization and having that outer component make the decision, and then everything else inside of it doesn't need to worry about it anymore. +JOËL: I think it's all kind of connected. I've come up with sort of three, let's call them principles, that I try to use when structuring code that I think are kind of the same idea viewed from three different points of view, or maybe all kind of converge towards the same ideas. The first one being what I showed earlier, the idea of separating branching code and doing code into two separate places. The second one being to try to branch early, push conditionals higher up your decision tree. And the final one being to keep the code within a single method or component or whatever your structuring element is at the same level of abstraction. +So if you're writing at a higher level calling a lot of lower-level methods, that's great. But then don't mix in some lower-level concerns there. Extract those out to a private method or another object or a component and bring those in, and keep everything at a high level in your high-level components, and then everything at a low level in your low-level components. +STEPHANIE: Yeah, that makes sense. I think that is perhaps closer to what I was trying to say earlier, where I think conditionals can be okay if they are in the right place. So if you have a controller and you see a bunch of conditionals, I think if that conditional-checking is related to something like rendering, that feels a bit more okay to me as opposed to seeing conditionals that then execute a procedure or a bunch of different things that might be better extracted somewhere else. +JOËL: I think there are two classes of conditional that you have to think about. Some conditionals are just unnecessary. You're doing extra work that is not required by the code because the code is poorly factored, and so you're having to do this extra work. This commonly happens, I think, in large code bases where they're modified over time, and you get this big, scary large method, maybe with deeply nested code, and you want to just make one modification in it. But you're afraid to break other things, so you wrap it in a conditional. But then everybody else is doing the same. +And then you've got this giant tangle of conditionals, some of which are duplicating each other, some of which will never be called just because it's poorly factored, and it just grew that way over time. And so those, if you're sitting down and looking at cleaning up that code, many of them can be entirely eliminated just by structuring things in a cleaner fashion. +STEPHANIE: Yeah, I've definitely experienced what you're talking about. And I think it does provide a lot of value once someone figures out what the heck is going on with all of these conditionals and wraps their head around it if they're able to refactor it to eliminate some of that complexity that has just downstream effects for everyone working in that code. Like, they don't have to do the work of trying to figure out what is going on, especially for unnecessary logic in the first place. +JOËL: I think a classic case I've seen of this is dealing with wizards where you have a bunch of different steps, and they might be all handled in one place. And a classic way that I've often seen people attempt to do this is say, well, there are a lot of things that might be shared between different steps. Or, again, we want to do this one single linear path. And so you might have, say, one giant Rails controller that accepts inputs from all the possible steps in the wizard. And then it will just say, if this parameter is present, do this action; else, if there is other parameters present, do this action. +It's not even like do this step one action or do the step two action. It might be if the user's name and email are present, then save some data to this table, else if a phone number is present, trigger this background job elseif all these things. But what gets tricky is then you don't know which combinations can happen together. +And then later on, when this gets really big, and you're trying to modify it, and it's like, oh, the customer wants another field on the screen that shows the phone number. But maybe you don't want a background job to be triggered in that case, or maybe it shows up on a different page that you also want to show the phone number on, but now you want the behavior to be slightly different for both of them. And so it gets into this really big tangled mess. +It's also impossible to read that code and know what is going to be executed for each step. So my general preferred approach for that kind of situation...and actually, we have an older episode of The Bike Shed where Steph and Chris discuss this in detail, and their recommendation was similar. So the trick is to branch early, and instead of having a single logical path, it's just check condition, do a thing, keep going. Check condition, do a thing, keep going. +You have branching at the top level that says, if step one, do the step one things; if step two, do the step two things; if step three, do the step three things. And you can have shared logic between them. You might have some private methods that call each other. And all that is fine. You can have levels of abstraction, all the goodies that you're used to. +But now you have a much simpler branching structure because you branch once at the top level. And that might be a four, or five, six, seven-way branch, which is complex. But there is no more branching down below it. After that, it's five or six linear paths going down instead of one giant path with a bunch of branches on it that merge back onto the main path. +STEPHANIE: Speaking of condition with multiple branches, I think we also talked a little bit about this in a previous episode you and I did on case expressions where you talked about how you handled that wizard with a flat case statement. So if folks want to hear more about our opinions on case expressions, I definitely recommend you check out that episode. +JOËL: One thing that I think is really interesting is that when you have extra if...else expressions that you don't need, and maybe they're nested in a certain way, or they're just like really long, you create more paths through your decision tree if you were to model this as a decision tree, then you actually want...so going back to the case of the wizard, the way that you structure it with a case expression is there's one, let's say a five-way branch, and then after that, it's just linear paths. So there are five unique ways to traverse that decision tree, which is exactly the number of ways that you want. +In the original implementation that I talked about where everything is an independent condition that says if this param is present, do a thing, keep going. If this other param is present, do a thing, keep going. And any combination of those might stack up together. Well, now we've got a combinatorial explosion because what if the phone number is present but also the first name and email? Do we do all of those things together? And so it's hard for the reader to understand because there literally are a lot of paths that can happen. And many of them are invalid paths. They shouldn't happen. +STEPHANIE: Yeah, I don't want to be anywhere near a combinatorial explosion based on that term. But, yeah, I think it's also very descriptive of what it feels like to have to parse through a bunch of nested conditionals like that to figure out where you are or what is going to happen next. +JOËL: I mentioned earlier on this podcast that I've done a lot of work with the Elm language. And when they're designing types in their community, they often use the expression make impossible states impossible. And so they'll look at the data structures that they're using and ask, "Are there ways that this data structure can be used to represent values that don't make sense in my domain? And can I change that representation, the definition of these data structures such that it now becomes impossible?" There are some heuristics that you can use to try to make that happen. +There's also a bit of a more mathematical way to think about it, which is thinking in terms of cardinalities, which is how many different types of values can be expressed by a given type. So you think a Boolean can only be one of two values, true or false. That is a type with a cardinality of two. You can do this exercise with different primitive types. But also, once you start combining types together, for example, you've got a pair of Booleans. You've got two values, each of which could be in two different states, and so now those two cardinalities multiply. You've got four possibilities for a type that is a pair of Booleans. +This becomes a really interesting analysis when you start thinking about using this to model a state of your application. So let's say you're trying to model something that has three possible states, and you say, oh, I'm going to use two Booleans to model this. It's problematic because two Booleans have four states, but the thing you're trying to model has only three. And so now you're absolutely going to get in some weird invalid state for that one extra combination that you didn't account for. Maybe that's false and false. +I see that happen a lot, even in database design, where you have two Boolean flag columns that interact with each other. And it's like, oh, but they should never both be false because that's some error state that should never happen, and, of course, inevitably, it does. What was really exciting to me was thinking about this mantra of making impossible states impossible. Can we apply that to branching? +In the way that I've structured my code, there should be the same number of possible branches through my decision tree as there are actual paths through the domain that I'm trying to model. So if it is a wizard with five steps, I want my decision tree to have five paths. If my decision tree has more than five paths, then maybe that's a sign that I need to refactor the implementation because I now have some extra invalid paths that I need to trim. +STEPHANIE: I think the phrase making impossible states impossible is really interesting because that mindset would be really helpful to avoid that defensive coding. I think that shows up as all of those unnecessary conditionals and checking for nil values because you just don't know, even though logically, you might know that it's not possible based on the domain or the business logic. +But we all have seen that no method on nil error come up in our error monitoring service. And you're like, oh shoot, I have to fix that. And you reach for it using that safe navigation operator. And so yeah, the idea of writing confident code, not defensive code (They're opposites to me.), is definitely something that I want to keep in mind. +JOËL: I think something that I'm getting out of this episode is also the value of interacting with other language communities and pulling in ideas from there and how that can enrich the way you think about code in a different language. This episode has talked about components in React in JavaScript. We've talked about architectures and CSS. We've pulled in some typing techniques from Elm and how that might maybe help us think about conditionals in Ruby. So it's a very polyglot episode. And I think that enriches our vocabulary and enriches our toolset, even when we're not coding in those languages. +STEPHANIE: Yeah, absolutely. I think it also shows that a lot of these things are universal. Even though there might be different paradigms, a lot of them kind of, like you said, are enriched by knowledge from other philosophies or frameworks, or it all kind of converges. +JOËL: There's a famous quote, and I've seen it attributed to many people, so I'm not even going to try. And it goes something like this: "History may not repeat itself, but it certainly does rhyme." And I feel like maybe we've got a little bit of that going on here in that the problems and solutions might not exactly replicate across languages and paradigms, but they certainly do rhyme. +STEPHANIE: That's a very, Joël thing to bring up, I think. +JOËL: [laughs] +STEPHANIE: Classic pulling from history to explain the present. +JOËL: On that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!! +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Happy New Year! It's 2023 🎉 Joël and Stephanie chat about developer resolutions or things they'd like to do this year and then discuss componentization and branching strategies.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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, as of the time that this episode goes live, it's the new year; it's 2023. Happy New Year.

+ +

STEPHANIE: Happy New Year, Joël, and Happy New Year to our listeners.

+ +

JOËL: So, new year is oftentimes where people like to take maybe resolutions or plan a little bit out of their year. I'm curious, Stephanie, do you have any developer resolutions or things that you'd like to do this year?

+ +

STEPHANIE: So, I think last episode, we were talking a little bit about reflection, especially in terms of career progression. And I may have mentioned that I don't really believe in New Year's resolutions. [laughs] But I do think that one intention that I have for myself is to chill a little bit. I think the fall of 2022, for me, was really hectic, exciting but a little busy in terms of speaking and content creation; you know, we started doing this podcast together. And so I do think that winter is my time of hibernation.

+ +

Development-wise, one goal that was really inspiring for me that you shared is writing ten blog posts a year. And I think I might keep that in the back of my head as we get into the new year and maybe start to at least just have it in my mind. So if I see anything that comes up, I can be like, oh yes, I had this intention to write more blog posts, which I think might be helpful to just marinate on even during my chill time.

+ +

Because when I do finally feel productive and energized again, I can at least have been thinking about it. And I think doing that reflection and marinating is also work, even if it doesn't end up turning into an artifact or anything like that. And so yeah, that's my plan for the beginning of the year, at least.

+ +

And then, on a personal note, I'm on a journey to be warm this winter and not be miserable and cold. So as a recovering Californian in Chicago these days, I have just always wanted to stay in and be a little bit of a hermit in the winter because I just have a hard time with the cold. But then I learned that you can just buy things that will help keep you warm.

+ +

And so, a recent purchase of mine was a heated, portable blanket. So I will definitely be repping that in my Zoom calls and on the couch. And I've just gotten really stocked up on the warm weather accessories, so fingerless gloves and the like. So I'm excited to just not be miserable this winter. That's my plan for the new year.

+ +

JOËL: You'll have to report back on how well that goes, how you feel about that blanket.

+ +

STEPHANIE: Oh yeah, I definitely will. Maybe I'll even wear it when we're recording.

+ +

JOËL: Maybe next year we can make a gift guide.

+ +

STEPHANIE: That would be so fun. I would like that: a gift guide for developers or the developer in your life.

+ +

JOËL: Right. Fingerless gloves just because it looks cool. [laughs]

+ +

STEPHANIE: I'm wearing them right now. Yeah, I can type, and my hands stay warm, highly recommend.

+ +

JOËL: So it's not just a hacker thing to look cool. It actually works.

+ +

STEPHANIE: I would say so. As someone who has very cold extremities, it's been a good solution for me.

+ +

JOËL: You'd mentioned in a previous episode talking about conference talk ideas that you like to marinate in sort of build up a file of ideas over the course of a year. And it sounds like you're taking that approach but then also applying it to smaller form content like blog posts over the course of this winter.

+ +

STEPHANIE: I think so. I realized something about myself is that I am a bit of a slow cooker in terms of coming up with ideas, especially if they're rooted in experience. I think it takes me the process of going through something like going through a client project and then honestly, three months later being like, oh, now I can have some distance from it and be like, oh, this is what I was thinking, or this is what I noticed or observed, which I think that's just how I am, and that's okay. I recognize that I don't necessarily churn out content all the time, and, for me, it kind of does feel more like seasons or cycles.

+ +

JOËL: So it's funny you mentioned the ten blog posts goal, and that's what I was going to share for my developer goal for the year. I've had that for the past several years. It's a really fun goal to have, I think, because it's aggressive enough that it requires me to put out a fair amount of content, but it's also achievable.

+ +

That being said, as of the time of this recording, which is at some undisclosed time prior to the New Year, I only have eight articles that are live on the thoughtbot blog. So for all you listeners in the future in 2023, if you're curious if I achieved my 2022 goals, go check the thoughtbot blog and see did I successfully publish the last two before the end of the month.

+ +

STEPHANIE: One thing you had mentioned to me off-air was that you do also tend to backload blog posts towards the end of the year once you realize that that deadline is coming up. Do you think you will do something differently in 2023?

+ +

JOËL: I would like to write a little bit more early in the year. I think I'll have to figure out exactly how I want some of my goals to play out. I think I mentioned this in the previous episode; two large themes that I've wanted to focus on are ways to invest in our team and our teammates and then creating content, so things like blog posts, like this podcast, like conference talks. Those were two broad themes that I had given my year in 2022. And I really enjoy those. I think I would want to repeat those themes for 2023 as well, so figuring out exactly how I'm going to interweave them, something I'm going to iterate on.

+ +

STEPHANIE: Have you considered breaking down that yearly goal into smaller time intervals, so maybe two or three blog posts a quarter?

+ +

JOËL: That might be a better way to do it to make sure that I'm on track. I give myself this as a goal. I'm not super hard on myself if I don't hit it, although I have hit it for multiple years. If I only have eight blog posts this year, that's still an accomplishment I'm proud of. And I think there's some good content that I put out. So I will not be distraught if I don't hit the 10, but it's good to be aiming for something.

+ +

STEPHANIE: Yeah, that's a good mindset to have. I also have a personal goal of reading 52 books a year. And this will be my third year attempting to do so. Or, I guess I have been successful in 2021 and 2022 now. But I remember when I first wanted to do it; I didn't tell anyone because I was terrified of not meeting that goal and just feeling a bit disappointed in myself.

+ +

And so, I just kept it to myself and didn't mention it to anyone until I got to around 40 or 45 bookmark, and then I could confidently tell people about my goal because, at that point, I was on track and feeling pretty confident that I was going to finish it. So that's my strategy [chuckles] is to not tell anyone until I am pretty much there and then share, and people can be impressed.

+ +

JOËL: I feel like there's always a bit of a tension there where when you've got a goal, sometimes you don't want to tell people about it because you don't want to say a thing and then disappoint other people and not get it done. But in some ways, for me, when I can get a goal out of my head and out into almost the real world by telling someone, it makes that goal more real and maybe inspires me to work harder towards it but also maybe helps me believe in myself a little bit more because I've said it out loud.

+ +

And, I don't know, maybe saying it in front of a mirror would have the same effect. But getting it out of just my thinking pattern and saying it, "This is what I think I'm going to achieve. This is what I'm trying to do," somehow makes the goal more real for me, makes it more achievable.

+ +

STEPHANIE: That makes sense. It's like the difference between saying, "I think I'm going to do this," and "Okay, I'm going to do this."

+ +

JOËL: Right. And maybe there's a little bit of social pressure too, if I tell someone, now I don't want to disappoint them. That can be bad because it causes me to doubt myself, but in small amounts, it can maybe help me to push through moments of doubt or moments of feeling like I want to give up.

+ +

STEPHANIE: Yeah, I mean, either way, even if you only ended up with eight blog posts in a year, people are just really excited that you're putting content out there. And they're not counting how many posts you put out.

+ +

JOËL: In a sense, it's purely a vanity metric for me to know my progress.

+ +

STEPHANIE: So I have one thing that happened this week that I would be curious to get your input on. On my client project, I was tasked with making a small UI change to a navigation menu that existed as a separate React project within our Rails repo. And so the task was for...we had this little caret icon that was used in the mobile nav, and the designer wanted it to be reused somewhere else on the desktop nav menu.

+ +

And I was digging through the codebase looking to see where the caret was already. And I realized that it was done with CSS on the menu label. So it was really coupled to this menu label and wasn't reusable in that current state. So it took me a little while to figure out how to pull out the seams and extract it into its own component so I could reuse it where I needed it to.

+ +

And so I was trying to figure out how we got here because we are using the styled-components library, which should encourage componentization. And I was just thinking about different approaches to building UI features from scratch. And I did a little bit of digging and learned about component-driven development, which suggests the idea of building each component in isolation and thinking through all the relevant states that it might exist in for at least your first couple of use cases and then combining them to create larger components, and then ultimately pages.

+ +

And that was interesting to me because it's a little bit different from a strategy that I'm used to, especially if you're implementing a new page or template where you just kind of scaffold out all of your HTML elements that you need. But then when you add on styling, those primitive components, you might end up having a lot of duplication if you are creating very generic things like buttons that end up being coupled to the page that you're working on, especially if you are putting them on the page in a very specific way.

+ +

And you might add CSS rules like margins or padding that, again, is coupled to that particular UI that you're building. So I'm curious if you've really thought about building UI from a component level and starting small and then building out or if you also take it from a top-down approach.

+ +

JOËL: It's interesting that you mentioned that the component approach really deals with figuring out state. And I think that's probably an area where it shines a lot when you have situations where components can have multiple states. And it's very easy when you're looking at much more of a scenario-driven approach where you just want to say, oh, I want this form input to look like this, like this one mock. But that was only showing the happy path. And you didn't think about all those other states. And so, for situations where you might have a lot of states, the component approach, I think, is really interesting.

+ +

I had a really fantastic experience a few years ago pairing with a thoughtbot designer on fairly...well, what we thought was going to be a simple form input. And it turned out that it had a lot of edge cases and funny state things that could happen. And we ended up drawing what essentially was a...you might call that a finite-state machine in a more formal sense. But it's basically a diagram where we show the state of the input. And then we would say, what are the different things that can happen that might transition it into another state?

+ +

So maybe it starts empty, but then you start typing, and then something happens, or you have an invalid value, and then something happens. But then, from the invalid state, can you come back to the empty state? Can you come back into the typing state? At what point do we show a read error? Do we clear it out while you're typing? Even after you have an error, this particular input was also backed by some remote data. So it was like a typeahead kind of thing pulling data from a server.

+ +

And there were a lot of extra edge cases for things like, oh, we're waiting for results, or no results matched, or we got exactly one result. And so that was really interesting. We ended up building up this whole diagram where we showed all the transitions that could happen, the ways you can loop back to a previous state, and it forced us to think about a lot of edge cases that we wouldn't have thought of otherwise.

+ +

STEPHANIE: That's really interesting. I think the transitions between different states definitely can get really complicated. While you were saying that, I was reminded of Storybook, the tool for building out components in isolation. And one thing that I really like is that they encourage you to think about different states and edge cases as almost like user stories. I think they're called stories. And you can use their DSL to extract those pieces of information and basically think through kind of what you were saying, but it's built into the tool. And so it really encourages that thought process.

+ +

Because I definitely have run into just trying to build out a basic button or something but then having all of these questions that I have to ask designers while I'm implementing it to be like, what should happen here? Or, like, what should it look like when it's disabled, or what happens when it, like you mentioned, gets back data that it wasn't expecting or something like that?

+ +

JOËL: Sometimes you have situations where your page doesn't have a lot of state, or your components don't really have a lot of state. And it really is just a static page. In those situations, now you're looking at questions more of reusability rather than state management. And you may or may not want some kind of componentized approach for that. That might be a little bit different depending on, like; you may not be using React if it's a completely static page.

+ +

So maybe this is server-rendered, and you're trying to componentize using Rails helpers. Or you're using something like BEM the CSS...I don't know if you'd call it a framework or a structural approach of defining classes that are in a more componentized approach so that you can reuse styles. So there are a lot of ways to reuse and componentize. Even though I think oftentimes when we talk about visual components, we're often thinking about React.

+ +

STEPHANIE: Yeah, I also did a little digging into ViewComponents because I was, again, just kind of trying to think of a mental model for how to approach building out UIs. And in their docs, they have a really good example about their process for using ViewComponents at GitHub. And basically, the progression is that they implement a single use case component that might live as it is for a while until there is some other use case for that component, and then maybe it's adapted for general use in multiple locations.

+ +

And then, if it turns out to be like a really good generic building block, they actually extract it into their open-source component library called Primer, I think is what it is. So that was an interesting process for me as someone who just kind of like did that first step of pulling out this little piece into its own component. And then, right now, it isn't necessarily quite ready for being reused in a bunch of different ways. But I think that was a good first step in setting it up to be able to.

+ +

JOËL: Definitely. I think it's easy to overDRY or, in this case, it's almost like over abstract in preparation for reuse that might never happen. But oftentimes, it's an incremental thing where you do as much as it makes sense for your current scenario while also leaving yourself the option to easily keep going down that path for future scenarios where there is more duplication. And then, if those scenarios never come, then great, you've saved yourself some work. And if the scenarios do come, then hopefully, it's easy to take the next step.

+ +

I gave a talk several years ago at an Elm meetup. Elm is a front-end language that compiles down to JavaScript. And in Elm they don't have components in the same way that React might have. Everything is just functions because of its very functional DNA. And I was talking about how to structure the view layer in terms of functions and how to do so cleanly in a way that is reusable. And one guideline that I had for myself for structuring this kind of code is that a function can either do something or it can branch, but it can't do both.

+ +

So if a function (But you can think component here.) is splitting in two different situations, then it doesn't get to have any logic inside it. It just calls out to some other component. And the only thing that it does is say, "I'm a branching component. If this happens, pull this other subcomponent; otherwise, bring in this subcomponent and maybe set up some arguments or something like that." And then the other child components that are rendering various pieces of UI, they don't get to branch. They are just given this data, render it in this way.

+ +

STEPHANIE: That makes a lot of sense. I think that also reminds me of the philosophy of separating your components to be container components or presentational components, where there are some that are just focused on what is being rendered and others that have more of that logic in determining what should or should not be displayed.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: It's interesting that we're talking about branching, how to structure it, how to model components that deal with branching or that have to be called from a branch because branching is something that I've been thinking about a lot for the past couple of years. One thing I noticed that we tend to do as developers is that we really, really want to force everything down a single path as much as possible.

+ +

Like, there is a main path, and then if you have to branch off of it, you go off on the side path. As short as possible, find a way to merge back onto the main path. But there is one single main path in your program, and everything tries to merge back into it. Have you encountered that in your own coding journey?

+ +

STEPHANIE: Do you mean having a lot of conditionals along this single path that might take you elsewhere but then, in the end, are just little tangents, and you're trying to get back to that main execution of code?

+ +

JOËL: Yes. An example of that might be dealing with a value that is potentially nil in Ruby or null in JavaScript. And so you check if that value is present, and then you do some things. And then you want to do something else, so you have to, again, check if the value is present and then potentially do the next step. And then, again, check if the value is present. And you end up repeating this conditional multiple times.

+ +

We have some constructs that make this a little bit nicer. Ruby has the lonely operator that will just sort of keep passing that nil down in a safe way. But it is still doing a nil check at every step of your long chain of actions you're trying to take because that value is potentially null at every step.

+ +

STEPHANIE: The lonely operator being the safe navigation operator. Is that right?

+ +

JOËL: Yes, that's right. That is another name for it.

+ +

STEPHANIE: Okay, cool. Glad we're on the same page.

+ +

JOËL: The &. We have some quirky names for operators in Ruby.

+ +

STEPHANIE: Yeah, we sure do. I hadn't heard of lonely before, so that was a really cool tidbit for me.

+ +

JOËL: There's also the spaceship operator, which is the less than equal greater than for comparing objects with comparable.

+ +

STEPHANIE: Ooh, I like that. I've also heard squid operator for interpolating Ruby in ERB.

+ +

JOËL: Nice.

+ +

STEPHANIE: I think, in my experience, I have seen that chaining of the safe navigation operator and the chaining of checking for nil in code that doesn't quite utilize the Tell, Don't Ask principle where you have to check for nil and all the objects down the line rather than having that functionality extracted in a method that is then, in my opinion, more correctly co-located with the relevant domain model. So I'm curious if you think that the conditionals themselves are an issue or if it's just the way that they were implemented or where they exist.

+ +

JOËL: In this particular case, I would say the conditionals are a code smell, and they're probably extraneous. You're checking the theme value for null again, or maybe you're checking a derived value for null that you don't need to because you've already checked it earlier. It's code that is not confident because the uncertainty from that initial nil has sort of bled through all of your code.

+ +

A classic solution to this problem is to try to push the uncertainty to the edges of your system. And a great resource for that is the book Confident Ruby by Avdi Grimm, which talks about all sorts of techniques for dealing with a lot of those uncertainties that you deal with in code and how to push those to the edges of your system.

+ +

STEPHANIE: Thanks. That does actually remind me of what you were saying about componentization and having that outer component make the decision, and then everything else inside of it doesn't need to worry about it anymore.

+ +

JOËL: I think it's all kind of connected. I've come up with sort of three, let's call them principles, that I try to use when structuring code that I think are kind of the same idea viewed from three different points of view, or maybe all kind of converge towards the same ideas. The first one being what I showed earlier, the idea of separating branching code and doing code into two separate places. The second one being to try to branch early, push conditionals higher up your decision tree. And the final one being to keep the code within a single method or component or whatever your structuring element is at the same level of abstraction.

+ +

So if you're writing at a higher level calling a lot of lower-level methods, that's great. But then don't mix in some lower-level concerns there. Extract those out to a private method or another object or a component and bring those in, and keep everything at a high level in your high-level components, and then everything at a low level in your low-level components.

+ +

STEPHANIE: Yeah, that makes sense. I think that is perhaps closer to what I was trying to say earlier, where I think conditionals can be okay if they are in the right place. So if you have a controller and you see a bunch of conditionals, I think if that conditional-checking is related to something like rendering, that feels a bit more okay to me as opposed to seeing conditionals that then execute a procedure or a bunch of different things that might be better extracted somewhere else.

+ +

JOËL: I think there are two classes of conditional that you have to think about. Some conditionals are just unnecessary. You're doing extra work that is not required by the code because the code is poorly factored, and so you're having to do this extra work. This commonly happens, I think, in large code bases where they're modified over time, and you get this big, scary large method, maybe with deeply nested code, and you want to just make one modification in it. But you're afraid to break other things, so you wrap it in a conditional. But then everybody else is doing the same.

+ +

And then you've got this giant tangle of conditionals, some of which are duplicating each other, some of which will never be called just because it's poorly factored, and it just grew that way over time. And so those, if you're sitting down and looking at cleaning up that code, many of them can be entirely eliminated just by structuring things in a cleaner fashion.

+ +

STEPHANIE: Yeah, I've definitely experienced what you're talking about. And I think it does provide a lot of value once someone figures out what the heck is going on with all of these conditionals and wraps their head around it if they're able to refactor it to eliminate some of that complexity that has just downstream effects for everyone working in that code. Like, they don't have to do the work of trying to figure out what is going on, especially for unnecessary logic in the first place.

+ +

JOËL: I think a classic case I've seen of this is dealing with wizards where you have a bunch of different steps, and they might be all handled in one place. And a classic way that I've often seen people attempt to do this is say, well, there are a lot of things that might be shared between different steps. Or, again, we want to do this one single linear path. And so you might have, say, one giant Rails controller that accepts inputs from all the possible steps in the wizard. And then it will just say, if this parameter is present, do this action; else, if there is other parameters present, do this action.

+ +

It's not even like do this step one action or do the step two action. It might be if the user's name and email are present, then save some data to this table, else if a phone number is present, trigger this background job elseif all these things. But what gets tricky is then you don't know which combinations can happen together.

+ +

And then later on, when this gets really big, and you're trying to modify it, and it's like, oh, the customer wants another field on the screen that shows the phone number. But maybe you don't want a background job to be triggered in that case, or maybe it shows up on a different page that you also want to show the phone number on, but now you want the behavior to be slightly different for both of them. And so it gets into this really big tangled mess.

+ +

It's also impossible to read that code and know what is going to be executed for each step. So my general preferred approach for that kind of situation...and actually, we have an older episode of The Bike Shed where Steph and Chris discuss this in detail, and their recommendation was similar. So the trick is to branch early, and instead of having a single logical path, it's just check condition, do a thing, keep going. Check condition, do a thing, keep going.

+ +

You have branching at the top level that says, if step one, do the step one things; if step two, do the step two things; if step three, do the step three things. And you can have shared logic between them. You might have some private methods that call each other. And all that is fine. You can have levels of abstraction, all the goodies that you're used to.

+ +

But now you have a much simpler branching structure because you branch once at the top level. And that might be a four, or five, six, seven-way branch, which is complex. But there is no more branching down below it. After that, it's five or six linear paths going down instead of one giant path with a bunch of branches on it that merge back onto the main path.

+ +

STEPHANIE: Speaking of condition with multiple branches, I think we also talked a little bit about this in a previous episode you and I did on case expressions where you talked about how you handled that wizard with a flat case statement. So if folks want to hear more about our opinions on case expressions, I definitely recommend you check out that episode.

+ +

JOËL: One thing that I think is really interesting is that when you have extra if...else expressions that you don't need, and maybe they're nested in a certain way, or they're just like really long, you create more paths through your decision tree if you were to model this as a decision tree, then you actually want...so going back to the case of the wizard, the way that you structure it with a case expression is there's one, let's say a five-way branch, and then after that, it's just linear paths. So there are five unique ways to traverse that decision tree, which is exactly the number of ways that you want.

+ +

In the original implementation that I talked about where everything is an independent condition that says if this param is present, do a thing, keep going. If this other param is present, do a thing, keep going. And any combination of those might stack up together. Well, now we've got a combinatorial explosion because what if the phone number is present but also the first name and email? Do we do all of those things together? And so it's hard for the reader to understand because there literally are a lot of paths that can happen. And many of them are invalid paths. They shouldn't happen.

+ +

STEPHANIE: Yeah, I don't want to be anywhere near a combinatorial explosion based on that term. But, yeah, I think it's also very descriptive of what it feels like to have to parse through a bunch of nested conditionals like that to figure out where you are or what is going to happen next.

+ +

JOËL: I mentioned earlier on this podcast that I've done a lot of work with the Elm language. And when they're designing types in their community, they often use the expression make impossible states impossible. And so they'll look at the data structures that they're using and ask, "Are there ways that this data structure can be used to represent values that don't make sense in my domain? And can I change that representation, the definition of these data structures such that it now becomes impossible?" There are some heuristics that you can use to try to make that happen.

+ +

There's also a bit of a more mathematical way to think about it, which is thinking in terms of cardinalities, which is how many different types of values can be expressed by a given type. So you think a Boolean can only be one of two values, true or false. That is a type with a cardinality of two. You can do this exercise with different primitive types. But also, once you start combining types together, for example, you've got a pair of Booleans. You've got two values, each of which could be in two different states, and so now those two cardinalities multiply. You've got four possibilities for a type that is a pair of Booleans.

+ +

This becomes a really interesting analysis when you start thinking about using this to model a state of your application. So let's say you're trying to model something that has three possible states, and you say, oh, I'm going to use two Booleans to model this. It's problematic because two Booleans have four states, but the thing you're trying to model has only three. And so now you're absolutely going to get in some weird invalid state for that one extra combination that you didn't account for. Maybe that's false and false.

+ +

I see that happen a lot, even in database design, where you have two Boolean flag columns that interact with each other. And it's like, oh, but they should never both be false because that's some error state that should never happen, and, of course, inevitably, it does. What was really exciting to me was thinking about this mantra of making impossible states impossible. Can we apply that to branching?

+ +

In the way that I've structured my code, there should be the same number of possible branches through my decision tree as there are actual paths through the domain that I'm trying to model. So if it is a wizard with five steps, I want my decision tree to have five paths. If my decision tree has more than five paths, then maybe that's a sign that I need to refactor the implementation because I now have some extra invalid paths that I need to trim.

+ +

STEPHANIE: I think the phrase making impossible states impossible is really interesting because that mindset would be really helpful to avoid that defensive coding. I think that shows up as all of those unnecessary conditionals and checking for nil values because you just don't know, even though logically, you might know that it's not possible based on the domain or the business logic.

+ +

But we all have seen that no method on nil error come up in our error monitoring service. And you're like, oh shoot, I have to fix that. And you reach for it using that safe navigation operator. And so yeah, the idea of writing confident code, not defensive code (They're opposites to me.), is definitely something that I want to keep in mind.

+ +

JOËL: I think something that I'm getting out of this episode is also the value of interacting with other language communities and pulling in ideas from there and how that can enrich the way you think about code in a different language. This episode has talked about components in React in JavaScript. We've talked about architectures and CSS. We've pulled in some typing techniques from Elm and how that might maybe help us think about conditionals in Ruby. So it's a very polyglot episode. And I think that enriches our vocabulary and enriches our toolset, even when we're not coding in those languages.

+ +

STEPHANIE: Yeah, absolutely. I think it also shows that a lot of these things are universal. Even though there might be different paradigms, a lot of them kind of, like you said, are enriched by knowledge from other philosophies or frameworks, or it all kind of converges.

+ +

JOËL: There's a famous quote, and I've seen it attributed to many people, so I'm not even going to try. And it goes something like this: "History may not repeat itself, but it certainly does rhyme." And I feel like maybe we've got a little bit of that going on here in that the problems and solutions might not exactly replicate across languages and paradigms, but they certainly do rhyme.

+ +

STEPHANIE: That's a very, Joël thing to bring up, I think.

+ +

JOËL: [laughs]

+ +

STEPHANIE: Classic pulling from history to explain the present.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + + Happy New Year! It's 2023 🎉 Joël and Stephanie chat about developer resolutions or things they'd like to do this year and then discuss componentization and branching strategies.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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, as of the time that this episode goes live, it's the new year; it's 2023. Happy New Year.

+ +

STEPHANIE: Happy New Year, Joël, and Happy New Year to our listeners.

+ +

JOËL: So, new year is oftentimes where people like to take maybe resolutions or plan a little bit out of their year. I'm curious, Stephanie, do you have any developer resolutions or things that you'd like to do this year?

+ +

STEPHANIE: So, I think last episode, we were talking a little bit about reflection, especially in terms of career progression. And I may have mentioned that I don't really believe in New Year's resolutions. [laughs] But I do think that one intention that I have for myself is to chill a little bit. I think the fall of 2022, for me, was really hectic, exciting but a little busy in terms of speaking and content creation; you know, we started doing this podcast together. And so I do think that winter is my time of hibernation.

+ +

Development-wise, one goal that was really inspiring for me that you shared is writing ten blog posts a year. And I think I might keep that in the back of my head as we get into the new year and maybe start to at least just have it in my mind. So if I see anything that comes up, I can be like, oh yes, I had this intention to write more blog posts, which I think might be helpful to just marinate on even during my chill time.

+ +

Because when I do finally feel productive and energized again, I can at least have been thinking about it. And I think doing that reflection and marinating is also work, even if it doesn't end up turning into an artifact or anything like that. And so yeah, that's my plan for the beginning of the year, at least.

+ +

And then, on a personal note, I'm on a journey to be warm this winter and not be miserable and cold. So as a recovering Californian in Chicago these days, I have just always wanted to stay in and be a little bit of a hermit in the winter because I just have a hard time with the cold. But then I learned that you can just buy things that will help keep you warm.

+ +

And so, a recent purchase of mine was a heated, portable blanket. So I will definitely be repping that in my Zoom calls and on the couch. And I've just gotten really stocked up on the warm weather accessories, so fingerless gloves and the like. So I'm excited to just not be miserable this winter. That's my plan for the new year.

+ +

JOËL: You'll have to report back on how well that goes, how you feel about that blanket.

+ +

STEPHANIE: Oh yeah, I definitely will. Maybe I'll even wear it when we're recording.

+ +

JOËL: Maybe next year we can make a gift guide.

+ +

STEPHANIE: That would be so fun. I would like that: a gift guide for developers or the developer in your life.

+ +

JOËL: Right. Fingerless gloves just because it looks cool. [laughs]

+ +

STEPHANIE: I'm wearing them right now. Yeah, I can type, and my hands stay warm, highly recommend.

+ +

JOËL: So it's not just a hacker thing to look cool. It actually works.

+ +

STEPHANIE: I would say so. As someone who has very cold extremities, it's been a good solution for me.

+ +

JOËL: You'd mentioned in a previous episode talking about conference talk ideas that you like to marinate in sort of build up a file of ideas over the course of a year. And it sounds like you're taking that approach but then also applying it to smaller form content like blog posts over the course of this winter.

+ +

STEPHANIE: I think so. I realized something about myself is that I am a bit of a slow cooker in terms of coming up with ideas, especially if they're rooted in experience. I think it takes me the process of going through something like going through a client project and then honestly, three months later being like, oh, now I can have some distance from it and be like, oh, this is what I was thinking, or this is what I noticed or observed, which I think that's just how I am, and that's okay. I recognize that I don't necessarily churn out content all the time, and, for me, it kind of does feel more like seasons or cycles.

+ +

JOËL: So it's funny you mentioned the ten blog posts goal, and that's what I was going to share for my developer goal for the year. I've had that for the past several years. It's a really fun goal to have, I think, because it's aggressive enough that it requires me to put out a fair amount of content, but it's also achievable.

+ +

That being said, as of the time of this recording, which is at some undisclosed time prior to the New Year, I only have eight articles that are live on the thoughtbot blog. So for all you listeners in the future in 2023, if you're curious if I achieved my 2022 goals, go check the thoughtbot blog and see did I successfully publish the last two before the end of the month.

+ +

STEPHANIE: One thing you had mentioned to me off-air was that you do also tend to backload blog posts towards the end of the year once you realize that that deadline is coming up. Do you think you will do something differently in 2023?

+ +

JOËL: I would like to write a little bit more early in the year. I think I'll have to figure out exactly how I want some of my goals to play out. I think I mentioned this in the previous episode; two large themes that I've wanted to focus on are ways to invest in our team and our teammates and then creating content, so things like blog posts, like this podcast, like conference talks. Those were two broad themes that I had given my year in 2022. And I really enjoy those. I think I would want to repeat those themes for 2023 as well, so figuring out exactly how I'm going to interweave them, something I'm going to iterate on.

+ +

STEPHANIE: Have you considered breaking down that yearly goal into smaller time intervals, so maybe two or three blog posts a quarter?

+ +

JOËL: That might be a better way to do it to make sure that I'm on track. I give myself this as a goal. I'm not super hard on myself if I don't hit it, although I have hit it for multiple years. If I only have eight blog posts this year, that's still an accomplishment I'm proud of. And I think there's some good content that I put out. So I will not be distraught if I don't hit the 10, but it's good to be aiming for something.

+ +

STEPHANIE: Yeah, that's a good mindset to have. I also have a personal goal of reading 52 books a year. And this will be my third year attempting to do so. Or, I guess I have been successful in 2021 and 2022 now. But I remember when I first wanted to do it; I didn't tell anyone because I was terrified of not meeting that goal and just feeling a bit disappointed in myself.

+ +

And so, I just kept it to myself and didn't mention it to anyone until I got to around 40 or 45 bookmark, and then I could confidently tell people about my goal because, at that point, I was on track and feeling pretty confident that I was going to finish it. So that's my strategy [chuckles] is to not tell anyone until I am pretty much there and then share, and people can be impressed.

+ +

JOËL: I feel like there's always a bit of a tension there where when you've got a goal, sometimes you don't want to tell people about it because you don't want to say a thing and then disappoint other people and not get it done. But in some ways, for me, when I can get a goal out of my head and out into almost the real world by telling someone, it makes that goal more real and maybe inspires me to work harder towards it but also maybe helps me believe in myself a little bit more because I've said it out loud.

+ +

And, I don't know, maybe saying it in front of a mirror would have the same effect. But getting it out of just my thinking pattern and saying it, "This is what I think I'm going to achieve. This is what I'm trying to do," somehow makes the goal more real for me, makes it more achievable.

+ +

STEPHANIE: That makes sense. It's like the difference between saying, "I think I'm going to do this," and "Okay, I'm going to do this."

+ +

JOËL: Right. And maybe there's a little bit of social pressure too, if I tell someone, now I don't want to disappoint them. That can be bad because it causes me to doubt myself, but in small amounts, it can maybe help me to push through moments of doubt or moments of feeling like I want to give up.

+ +

STEPHANIE: Yeah, I mean, either way, even if you only ended up with eight blog posts in a year, people are just really excited that you're putting content out there. And they're not counting how many posts you put out.

+ +

JOËL: In a sense, it's purely a vanity metric for me to know my progress.

+ +

STEPHANIE: So I have one thing that happened this week that I would be curious to get your input on. On my client project, I was tasked with making a small UI change to a navigation menu that existed as a separate React project within our Rails repo. And so the task was for...we had this little caret icon that was used in the mobile nav, and the designer wanted it to be reused somewhere else on the desktop nav menu.

+ +

And I was digging through the codebase looking to see where the caret was already. And I realized that it was done with CSS on the menu label. So it was really coupled to this menu label and wasn't reusable in that current state. So it took me a little while to figure out how to pull out the seams and extract it into its own component so I could reuse it where I needed it to.

+ +

And so I was trying to figure out how we got here because we are using the styled-components library, which should encourage componentization. And I was just thinking about different approaches to building UI features from scratch. And I did a little bit of digging and learned about component-driven development, which suggests the idea of building each component in isolation and thinking through all the relevant states that it might exist in for at least your first couple of use cases and then combining them to create larger components, and then ultimately pages.

+ +

And that was interesting to me because it's a little bit different from a strategy that I'm used to, especially if you're implementing a new page or template where you just kind of scaffold out all of your HTML elements that you need. But then when you add on styling, those primitive components, you might end up having a lot of duplication if you are creating very generic things like buttons that end up being coupled to the page that you're working on, especially if you are putting them on the page in a very specific way.

+ +

And you might add CSS rules like margins or padding that, again, is coupled to that particular UI that you're building. So I'm curious if you've really thought about building UI from a component level and starting small and then building out or if you also take it from a top-down approach.

+ +

JOËL: It's interesting that you mentioned that the component approach really deals with figuring out state. And I think that's probably an area where it shines a lot when you have situations where components can have multiple states. And it's very easy when you're looking at much more of a scenario-driven approach where you just want to say, oh, I want this form input to look like this, like this one mock. But that was only showing the happy path. And you didn't think about all those other states. And so, for situations where you might have a lot of states, the component approach, I think, is really interesting.

+ +

I had a really fantastic experience a few years ago pairing with a thoughtbot designer on fairly...well, what we thought was going to be a simple form input. And it turned out that it had a lot of edge cases and funny state things that could happen. And we ended up drawing what essentially was a...you might call that a finite-state machine in a more formal sense. But it's basically a diagram where we show the state of the input. And then we would say, what are the different things that can happen that might transition it into another state?

+ +

So maybe it starts empty, but then you start typing, and then something happens, or you have an invalid value, and then something happens. But then, from the invalid state, can you come back to the empty state? Can you come back into the typing state? At what point do we show a read error? Do we clear it out while you're typing? Even after you have an error, this particular input was also backed by some remote data. So it was like a typeahead kind of thing pulling data from a server.

+ +

And there were a lot of extra edge cases for things like, oh, we're waiting for results, or no results matched, or we got exactly one result. And so that was really interesting. We ended up building up this whole diagram where we showed all the transitions that could happen, the ways you can loop back to a previous state, and it forced us to think about a lot of edge cases that we wouldn't have thought of otherwise.

+ +

STEPHANIE: That's really interesting. I think the transitions between different states definitely can get really complicated. While you were saying that, I was reminded of Storybook, the tool for building out components in isolation. And one thing that I really like is that they encourage you to think about different states and edge cases as almost like user stories. I think they're called stories. And you can use their DSL to extract those pieces of information and basically think through kind of what you were saying, but it's built into the tool. And so it really encourages that thought process.

+ +

Because I definitely have run into just trying to build out a basic button or something but then having all of these questions that I have to ask designers while I'm implementing it to be like, what should happen here? Or, like, what should it look like when it's disabled, or what happens when it, like you mentioned, gets back data that it wasn't expecting or something like that?

+ +

JOËL: Sometimes you have situations where your page doesn't have a lot of state, or your components don't really have a lot of state. And it really is just a static page. In those situations, now you're looking at questions more of reusability rather than state management. And you may or may not want some kind of componentized approach for that. That might be a little bit different depending on, like; you may not be using React if it's a completely static page.

+ +

So maybe this is server-rendered, and you're trying to componentize using Rails helpers. Or you're using something like BEM the CSS...I don't know if you'd call it a framework or a structural approach of defining classes that are in a more componentized approach so that you can reuse styles. So there are a lot of ways to reuse and componentize. Even though I think oftentimes when we talk about visual components, we're often thinking about React.

+ +

STEPHANIE: Yeah, I also did a little digging into ViewComponents because I was, again, just kind of trying to think of a mental model for how to approach building out UIs. And in their docs, they have a really good example about their process for using ViewComponents at GitHub. And basically, the progression is that they implement a single use case component that might live as it is for a while until there is some other use case for that component, and then maybe it's adapted for general use in multiple locations.

+ +

And then, if it turns out to be like a really good generic building block, they actually extract it into their open-source component library called Primer, I think is what it is. So that was an interesting process for me as someone who just kind of like did that first step of pulling out this little piece into its own component. And then, right now, it isn't necessarily quite ready for being reused in a bunch of different ways. But I think that was a good first step in setting it up to be able to.

+ +

JOËL: Definitely. I think it's easy to overDRY or, in this case, it's almost like over abstract in preparation for reuse that might never happen. But oftentimes, it's an incremental thing where you do as much as it makes sense for your current scenario while also leaving yourself the option to easily keep going down that path for future scenarios where there is more duplication. And then, if those scenarios never come, then great, you've saved yourself some work. And if the scenarios do come, then hopefully, it's easy to take the next step.

+ +

I gave a talk several years ago at an Elm meetup. Elm is a front-end language that compiles down to JavaScript. And in Elm they don't have components in the same way that React might have. Everything is just functions because of its very functional DNA. And I was talking about how to structure the view layer in terms of functions and how to do so cleanly in a way that is reusable. And one guideline that I had for myself for structuring this kind of code is that a function can either do something or it can branch, but it can't do both.

+ +

So if a function (But you can think component here.) is splitting in two different situations, then it doesn't get to have any logic inside it. It just calls out to some other component. And the only thing that it does is say, "I'm a branching component. If this happens, pull this other subcomponent; otherwise, bring in this subcomponent and maybe set up some arguments or something like that." And then the other child components that are rendering various pieces of UI, they don't get to branch. They are just given this data, render it in this way.

+ +

STEPHANIE: That makes a lot of sense. I think that also reminds me of the philosophy of separating your components to be container components or presentational components, where there are some that are just focused on what is being rendered and others that have more of that logic in determining what should or should not be displayed.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: It's interesting that we're talking about branching, how to structure it, how to model components that deal with branching or that have to be called from a branch because branching is something that I've been thinking about a lot for the past couple of years. One thing I noticed that we tend to do as developers is that we really, really want to force everything down a single path as much as possible.

+ +

Like, there is a main path, and then if you have to branch off of it, you go off on the side path. As short as possible, find a way to merge back onto the main path. But there is one single main path in your program, and everything tries to merge back into it. Have you encountered that in your own coding journey?

+ +

STEPHANIE: Do you mean having a lot of conditionals along this single path that might take you elsewhere but then, in the end, are just little tangents, and you're trying to get back to that main execution of code?

+ +

JOËL: Yes. An example of that might be dealing with a value that is potentially nil in Ruby or null in JavaScript. And so you check if that value is present, and then you do some things. And then you want to do something else, so you have to, again, check if the value is present and then potentially do the next step. And then, again, check if the value is present. And you end up repeating this conditional multiple times.

+ +

We have some constructs that make this a little bit nicer. Ruby has the lonely operator that will just sort of keep passing that nil down in a safe way. But it is still doing a nil check at every step of your long chain of actions you're trying to take because that value is potentially null at every step.

+ +

STEPHANIE: The lonely operator being the safe navigation operator. Is that right?

+ +

JOËL: Yes, that's right. That is another name for it.

+ +

STEPHANIE: Okay, cool. Glad we're on the same page.

+ +

JOËL: The &. We have some quirky names for operators in Ruby.

+ +

STEPHANIE: Yeah, we sure do. I hadn't heard of lonely before, so that was a really cool tidbit for me.

+ +

JOËL: There's also the spaceship operator, which is the less than equal greater than for comparing objects with comparable.

+ +

STEPHANIE: Ooh, I like that. I've also heard squid operator for interpolating Ruby in ERB.

+ +

JOËL: Nice.

+ +

STEPHANIE: I think, in my experience, I have seen that chaining of the safe navigation operator and the chaining of checking for nil in code that doesn't quite utilize the Tell, Don't Ask principle where you have to check for nil and all the objects down the line rather than having that functionality extracted in a method that is then, in my opinion, more correctly co-located with the relevant domain model. So I'm curious if you think that the conditionals themselves are an issue or if it's just the way that they were implemented or where they exist.

+ +

JOËL: In this particular case, I would say the conditionals are a code smell, and they're probably extraneous. You're checking the theme value for null again, or maybe you're checking a derived value for null that you don't need to because you've already checked it earlier. It's code that is not confident because the uncertainty from that initial nil has sort of bled through all of your code.

+ +

A classic solution to this problem is to try to push the uncertainty to the edges of your system. And a great resource for that is the book Confident Ruby by Avdi Grimm, which talks about all sorts of techniques for dealing with a lot of those uncertainties that you deal with in code and how to push those to the edges of your system.

+ +

STEPHANIE: Thanks. That does actually remind me of what you were saying about componentization and having that outer component make the decision, and then everything else inside of it doesn't need to worry about it anymore.

+ +

JOËL: I think it's all kind of connected. I've come up with sort of three, let's call them principles, that I try to use when structuring code that I think are kind of the same idea viewed from three different points of view, or maybe all kind of converge towards the same ideas. The first one being what I showed earlier, the idea of separating branching code and doing code into two separate places. The second one being to try to branch early, push conditionals higher up your decision tree. And the final one being to keep the code within a single method or component or whatever your structuring element is at the same level of abstraction.

+ +

So if you're writing at a higher level calling a lot of lower-level methods, that's great. But then don't mix in some lower-level concerns there. Extract those out to a private method or another object or a component and bring those in, and keep everything at a high level in your high-level components, and then everything at a low level in your low-level components.

+ +

STEPHANIE: Yeah, that makes sense. I think that is perhaps closer to what I was trying to say earlier, where I think conditionals can be okay if they are in the right place. So if you have a controller and you see a bunch of conditionals, I think if that conditional-checking is related to something like rendering, that feels a bit more okay to me as opposed to seeing conditionals that then execute a procedure or a bunch of different things that might be better extracted somewhere else.

+ +

JOËL: I think there are two classes of conditional that you have to think about. Some conditionals are just unnecessary. You're doing extra work that is not required by the code because the code is poorly factored, and so you're having to do this extra work. This commonly happens, I think, in large code bases where they're modified over time, and you get this big, scary large method, maybe with deeply nested code, and you want to just make one modification in it. But you're afraid to break other things, so you wrap it in a conditional. But then everybody else is doing the same.

+ +

And then you've got this giant tangle of conditionals, some of which are duplicating each other, some of which will never be called just because it's poorly factored, and it just grew that way over time. And so those, if you're sitting down and looking at cleaning up that code, many of them can be entirely eliminated just by structuring things in a cleaner fashion.

+ +

STEPHANIE: Yeah, I've definitely experienced what you're talking about. And I think it does provide a lot of value once someone figures out what the heck is going on with all of these conditionals and wraps their head around it if they're able to refactor it to eliminate some of that complexity that has just downstream effects for everyone working in that code. Like, they don't have to do the work of trying to figure out what is going on, especially for unnecessary logic in the first place.

+ +

JOËL: I think a classic case I've seen of this is dealing with wizards where you have a bunch of different steps, and they might be all handled in one place. And a classic way that I've often seen people attempt to do this is say, well, there are a lot of things that might be shared between different steps. Or, again, we want to do this one single linear path. And so you might have, say, one giant Rails controller that accepts inputs from all the possible steps in the wizard. And then it will just say, if this parameter is present, do this action; else, if there is other parameters present, do this action.

+ +

It's not even like do this step one action or do the step two action. It might be if the user's name and email are present, then save some data to this table, else if a phone number is present, trigger this background job elseif all these things. But what gets tricky is then you don't know which combinations can happen together.

+ +

And then later on, when this gets really big, and you're trying to modify it, and it's like, oh, the customer wants another field on the screen that shows the phone number. But maybe you don't want a background job to be triggered in that case, or maybe it shows up on a different page that you also want to show the phone number on, but now you want the behavior to be slightly different for both of them. And so it gets into this really big tangled mess.

+ +

It's also impossible to read that code and know what is going to be executed for each step. So my general preferred approach for that kind of situation...and actually, we have an older episode of The Bike Shed where Steph and Chris discuss this in detail, and their recommendation was similar. So the trick is to branch early, and instead of having a single logical path, it's just check condition, do a thing, keep going. Check condition, do a thing, keep going.

+ +

You have branching at the top level that says, if step one, do the step one things; if step two, do the step two things; if step three, do the step three things. And you can have shared logic between them. You might have some private methods that call each other. And all that is fine. You can have levels of abstraction, all the goodies that you're used to.

+ +

But now you have a much simpler branching structure because you branch once at the top level. And that might be a four, or five, six, seven-way branch, which is complex. But there is no more branching down below it. After that, it's five or six linear paths going down instead of one giant path with a bunch of branches on it that merge back onto the main path.

+ +

STEPHANIE: Speaking of condition with multiple branches, I think we also talked a little bit about this in a previous episode you and I did on case expressions where you talked about how you handled that wizard with a flat case statement. So if folks want to hear more about our opinions on case expressions, I definitely recommend you check out that episode.

+ +

JOËL: One thing that I think is really interesting is that when you have extra if...else expressions that you don't need, and maybe they're nested in a certain way, or they're just like really long, you create more paths through your decision tree if you were to model this as a decision tree, then you actually want...so going back to the case of the wizard, the way that you structure it with a case expression is there's one, let's say a five-way branch, and then after that, it's just linear paths. So there are five unique ways to traverse that decision tree, which is exactly the number of ways that you want.

+ +

In the original implementation that I talked about where everything is an independent condition that says if this param is present, do a thing, keep going. If this other param is present, do a thing, keep going. And any combination of those might stack up together. Well, now we've got a combinatorial explosion because what if the phone number is present but also the first name and email? Do we do all of those things together? And so it's hard for the reader to understand because there literally are a lot of paths that can happen. And many of them are invalid paths. They shouldn't happen.

+ +

STEPHANIE: Yeah, I don't want to be anywhere near a combinatorial explosion based on that term. But, yeah, I think it's also very descriptive of what it feels like to have to parse through a bunch of nested conditionals like that to figure out where you are or what is going to happen next.

+ +

JOËL: I mentioned earlier on this podcast that I've done a lot of work with the Elm language. And when they're designing types in their community, they often use the expression make impossible states impossible. And so they'll look at the data structures that they're using and ask, "Are there ways that this data structure can be used to represent values that don't make sense in my domain? And can I change that representation, the definition of these data structures such that it now becomes impossible?" There are some heuristics that you can use to try to make that happen.

+ +

There's also a bit of a more mathematical way to think about it, which is thinking in terms of cardinalities, which is how many different types of values can be expressed by a given type. So you think a Boolean can only be one of two values, true or false. That is a type with a cardinality of two. You can do this exercise with different primitive types. But also, once you start combining types together, for example, you've got a pair of Booleans. You've got two values, each of which could be in two different states, and so now those two cardinalities multiply. You've got four possibilities for a type that is a pair of Booleans.

+ +

This becomes a really interesting analysis when you start thinking about using this to model a state of your application. So let's say you're trying to model something that has three possible states, and you say, oh, I'm going to use two Booleans to model this. It's problematic because two Booleans have four states, but the thing you're trying to model has only three. And so now you're absolutely going to get in some weird invalid state for that one extra combination that you didn't account for. Maybe that's false and false.

+ +

I see that happen a lot, even in database design, where you have two Boolean flag columns that interact with each other. And it's like, oh, but they should never both be false because that's some error state that should never happen, and, of course, inevitably, it does. What was really exciting to me was thinking about this mantra of making impossible states impossible. Can we apply that to branching?

+ +

In the way that I've structured my code, there should be the same number of possible branches through my decision tree as there are actual paths through the domain that I'm trying to model. So if it is a wizard with five steps, I want my decision tree to have five paths. If my decision tree has more than five paths, then maybe that's a sign that I need to refactor the implementation because I now have some extra invalid paths that I need to trim.

+ +

STEPHANIE: I think the phrase making impossible states impossible is really interesting because that mindset would be really helpful to avoid that defensive coding. I think that shows up as all of those unnecessary conditionals and checking for nil values because you just don't know, even though logically, you might know that it's not possible based on the domain or the business logic.

+ +

But we all have seen that no method on nil error come up in our error monitoring service. And you're like, oh shoot, I have to fix that. And you reach for it using that safe navigation operator. And so yeah, the idea of writing confident code, not defensive code (They're opposites to me.), is definitely something that I want to keep in mind.

+ +

JOËL: I think something that I'm getting out of this episode is also the value of interacting with other language communities and pulling in ideas from there and how that can enrich the way you think about code in a different language. This episode has talked about components in React in JavaScript. We've talked about architectures and CSS. We've pulled in some typing techniques from Elm and how that might maybe help us think about conditionals in Ruby. So it's a very polyglot episode. And I think that enriches our vocabulary and enriches our toolset, even when we're not coding in those languages.

+ +

STEPHANIE: Yeah, absolutely. I think it also shows that a lot of these things are universal. Even though there might be different paradigms, a lot of them kind of, like you said, are enriched by knowledge from other philosophies or frameworks, or it all kind of converges.

+ +

JOËL: There's a famous quote, and I've seen it attributed to many people, so I'm not even going to try. And it goes something like this: "History may not repeat itself, but it certainly does rhyme." And I feel like maybe we've got a little bit of that going on here in that the problems and solutions might not exactly replicate across languages and paradigms, but they certainly do rhyme.

+ +

STEPHANIE: That's a very, Joël thing to bring up, I think.

+ +

JOËL: [laughs]

+ +

STEPHANIE: Classic pulling from history to explain the present.

+ +

JOËL: On that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3nmYMxhB + + ]]> + + Joël Quenneville + Stephanie Minn + + + 365: Career Progression + https://bikeshed.thoughtbot.com/365 + 5eed19b0-b3ac-4967-9e9d-267fde108bb9 + Tue, 13 Dec 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël has been thinking a lot recently about array indexing. Stephanie started volunteering at the Chicago Tool Library, a non-profit community lending library for Chicagoans to borrow tools and equipment for DIY home projects! + +It's the end of the year and often a time of reflection: looking back on the year and thinking about the next. Stephanie and Joël ponder if open source is a critical way to advance careers as software developers. + 37:55 + no + + + Joël has been thinking a lot recently about array indexing. Stephanie started volunteering at the Chicago Tooele Library, a non-profit community lending library for Chicagoans to borrow tools and equipment for DIY home projects! +It's the end of the year and often a time of reflection: looking back on the year and thinking about the next. Stephanie and Joël ponder if open source is a critical way to advance careers as software developers. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Chicago Tool Library (https://www.chicagotoollibrary.org/our-organization) +Circulate and Ruby For Good (https://github.com/rubyforgood/circulate) +Glue Work (https://noidea.dog/glue) +Being the DRI of your career (https://cate.blog/2021/09/20/being-the-dri-of-your-career/) +The Manager's Path (https://www.oreilly.com/library/view/the-managers-path/9781491973882/) +Kingship (https://acoup.blog/2022/10/07/collections-teaching-paradox-crusader-kings-iii-part-iii-constructivisting-a-kingdom/) +What technologies should I learn? (https://thoughtbot.com/blog/what-technologies-should-i-learn) +Learning by Helping (https://thoughtbot.com/blog/learning-by-helping) +"Comb-shaped" Careers (https://killalldefects.com/2020/02/22/specializing-vs-generalizing-careers/) +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 are here to share a little bit of what we've learned along the way. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I've been thinking a lot recently about array indexing. I feel like this is one of the areas where you commonly get confused as a new programmer because most languages start array indexing at zero. And what we really have here are two counting systems, either an offset so how many spaces from the beginning of the array, or a counting system where you count 1,2,3,4. At first, it feels like why would computers ever go with the offset approach? It's so illogical. Counting 1,2,3,4 would feel natural. +But then, the more I think about it, the more I've started seeing the zero-based pattern show up in everyday life. One example, because I enjoy reading history, is how we talk about centuries. You might talk about the 19th century is the Victorian age, roughly. But you might also refer to the 19th century as the 1800s. So we've kind of got these two names that are a little bit off by one. And that's because when you're counting the centuries, you count first century, second century, third century, fourth century, and so on. +But when we actually go by the first two digits, you start with the zeros, then the 100s, then the 200s, 300s, and so on. And so we have a zero-based counting system and a one-based counting system, and we sort of have learned to navigate both simultaneously. So that was really interesting to me to make a connection between history and programming and the fact that sometimes we count from zero, and sometimes we count from one. +STEPHANIE: Yeah, I will have to admit that I always get confused when we're talking about centuries and making the mental connection that 19th century is the 1800s. It always takes me a bit of an extra second to make sure I know what I'm hearing, and I'm attributing it to the right year. +I think another example where I get a bit tripped up is the numbering of floors because, in the U.S., we are counting floors using the one-based counting system, whereas I think in Europe and places outside of North America, to my knowledge, the first floor will be considered the ground floor, and then the second floor will be the first floor and onward. So that is a zero-based counting system that I can recall. +JOËL: I never noticed there was a pattern. I just thought every building was arbitrary in where it counted from. +STEPHANIE: Yeah, I do think it's a cultural thing. I would be really curious to know more about the history of how those counting systems get adopted. +JOËL: So that's a fun thing that I've been exploring recently. What's new in your world, Stephanie? +STEPHANIE: I am really excited to talk about a new real-life update. I started volunteering at the Chicago Tooele Library, which is a non-profit community lending library in my city for Chicagoans to borrow tools and equipment for DIY home projects. What I really like about it is they use a pay-what-you-can model so everyone can have access to these resources. It reduces the need for people to buy new things all the time, especially for little one-off projects. And they also provide education to empower folks to learn how to do things themselves, which I thought was really cool. +And another thing that I think might be a little relevant to this audience is that I actually first encountered the Tooele library through its open-source software, which is a Ruby for Good project called Circulate. So the Tooele Library had previously been using this software that was built by community members to do all of their lending. And I got to see it in action when I saw a librarian use it to rent out tools to community members. And then I also interfaced with it myself as a member of the Tooele Library. +I've borrowed things like saws, cooking appliances like air fryers that they also had. And when I was first a guest on this show, I borrowed a microphone from them to do this podcast because I was just a guest at the time and didn't want to commit to buying a whole new microphone, so that was a really awesome way that I got to benefit from it. +JOËL: It's a fantastic resource for the community. +STEPHANIE: Yeah, I love it so much. If anyone is in Chicago and wants to check it out, I highly recommend it. And even if you're not in Chicago, if the idea of a lending library interests you, you can check out the software on Ruby for Good. And it's no longer being used by the Chicago Tooele Library, but it would be really cool to see it be picked up by other people who might want to start something similar in their own hometowns. +JOËL: So you mentioned you're volunteering here. So this means you're going in person and helping people check out items from the library. +STEPHANIE: Yeah, I did my first volunteer librarian shift about a month ago, and right now, they're in the middle of moving from one location to another, so they've had a lot of in-person workdays to get some of that done. But even before that, I had contributed a little bit to the open-source repo, which is just a pretty standard Rails project, so I felt super comfortable with getting my feet wet in it. And it was, I think, my first open-source contribution. +I find that some of the other open-source software, especially developer tooling, is a little scary to get into. So this was a really accessible way for me to contribute to that community, just leveraging the skills that I have for my day-to-day work. +JOËL: Would you recommend this project for our listeners who are looking to maybe get their own first contribution in open source? +STEPHANIE: The Circulate project is actually on a bit of a hiatus right now. But I would definitely suggest people fork it and play around with it if they want to. I also know that Ruby for Good has a bunch of other projects that are Rails apps and have real users and are having an impact that way. So if anyone wants to get into open source in a way that feels accessible and they're building a product that people are using, I definitely recommend checking that out. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So, as we're recording this, it's the end of the year. It's often a time of reflection and looking back on the year and maybe even thinking about the next year and progression. I'm curious since you said this was your introduction to the world of open source, do you think that working on open source is a critical way to advance our careers as software developers? +STEPHANIE: That's a good question. Honestly, I think my answer would be, no, it's not critical. I think it's one avenue for people to explore and increase their impact on the community and increase their technical knowledge, especially if it's in an area that they are not quite working in in their day-to-day, but they're really interested in diving deeper in. +But I do think there's sometimes a lot of pressure to feel like open source is this shining beacon of opportunity for you to dive into and that it'll bring a lot of meaning to the work that you do. And people, obviously, and for a good reason, talk about how special it is that open source is part of the industry that we work in, but I don't necessarily think it's critical. +I do certainly feel inspired by people who create open-source tools or contribute to Ruby or Rails. But I don't necessarily think that it's something that should be a rule and that everyone needs to get into it or contribute to it. Because there are many ways that people can have an impact having influence on the community, and that way is one. But there's also a lot of value, even just focusing on the team that you're on and your company internally. +JOËL: I appreciate the nuance there because I think like you said, we often view open source as the main thing that everyone should be doing to get ahead. And there are a lot of different ways to improve your skill and then to get ahead in your career, which are not always correlated. One kind of really basic way that I was shocked at how much it helped me was I was learning a new language, Elm. I joined their online Slack community and just hung out in the chat room and answered the most beginner questions because I barely knew the language at the time. +And most of these could be found just by looking up the documentation or by opening up a REPL and experimenting with a thing and giving an answer, which are skills that, as a programmer who's got some experience, I take for granted but that not everyone has that as a reflex. Because Googling, searching documentation, crafting experiments in the REPL those are all skills that you have to learn to build over time. But answering those very basic questions over and over over the course of a few months actually taught me so much about the language, and I'm not doing anything fancy. +STEPHANIE: That's awesome. I have a friend who, during a time when I think she was struggling with her confidence in her technical skill and was feeling a bit stuck at work, spent an afternoon answering Stack Overflow questions on basic Ruby and Rails, and that gave her a lot of joy. Because she recognized that she was the person Googling those questions and needing to find answers many years ago, and that was one way that she could pay it forward. And I think she had a lot of empathy, like I said, for those people who are needing a little help, and it felt really good for her to be able to provide it. +JOËL: It's a way to have an impact on other people while also solidifying your own knowledge. +STEPHANIE: Yeah, exactly. +JOËL: So we've mentioned a couple of different ways where you can level up your skills, that might be through helping out other people online, that could be through open source. But I'd like to zoom out a little bit and look at not just improving your technical skills but thinking about career in general when you're looking out over the next 10, 20, 30 years. Do you have an approach that you like to take when you're thinking that broadly? +STEPHANIE: For me, I have had trouble thinking about a five or 10-year plan because things often don't turn out the way that I envisioned them. And so I think I've come to realize that leaning into how I feel about things in any given moment is more valuable and oftentimes more accurate to what I really want. Because I can have an idea of what I want my career to look like, but the things that ring most true are what I'm feeling in the moment. +And so you mentioned we're releasing this episode at the end of the year. I do tend to do a little bit of recap about how my year went if I spent it doing things that fulfilled me and made me feel good, if I grew in the ways that I wanted, even separate from any performance review. I know that this is a time of reflection for a lot of people. And I don't personally ascribe to New Year's resolutions, but I do like to think about themes or intentions. And those are things that ground me rather than setting particular goals that I may or may not achieve; I may realize I want to change. +So yeah, I really recommend just sitting with yourself and spending time thinking about what you want, and that could mean a promotion, but that could also mean a more interesting project using new technology. It could mean more responsibility and decision-making power. It could mean a move into management. I think it's different for everyone. And so when people have asked me about advice or what they should do in terms of coming to a crossroads between jobs or between projects, I think that you really can't tell anyone else what is the right move for them; only they can decide. +JOËL: And tech, it's such a broad field. There are so many different roles and paths you can take through it. Well, there's junior engineer, engineer one, engineer two, engineer three, that's just the same everywhere. And there's only one way forward; it's up or stagnation, and that's it. Like you really get to choose your own adventure in this industry, and that's exciting and maybe a little bit terrifying. +STEPHANIE: Oh yeah, for sure. I like that you brought up the different levels and roles that you could have because I have found companies that provide a career ladder or engineering ladder that has been useful for me in the past in figuring out if the next step at the company that I'm at is what I want. And it's helpful. It's very clear to me, okay, these are the skills that I need to get promoted into this next level. But other times, that description describes something that I'm not interested in, and that is also really helpful information. +JOËL: Was there ever a moment in your own career where you had to navigate some of these decisions to decide what path you wanted to take as opposed to just following a ladder up? +STEPHANIE: Oh yeah. I was presented opportunities to start getting a feel for management or overseeing a team as a lead. And people had really great feedback for me that that was something that I had shown leadership in, and they thought I would do a great job in that role. But I actually decided to kind of hit the brakes a little bit on that particular route because what I realized I wanted at the time was to focus more on being an IC and deepening my technical knowledge. And that was really tough. +I do also think that a lot of women are pushed into management because they end up doing a lot of the glue work that comes with unblocking people, supporting people, and project management and those are all skills that, like, quote, unquote, "lend themselves towards management." But just because we do that work doesn't necessarily mean that that's the direction that we want our careers to go in. And so that was a really tough thing that I had to do was to make it really clear that I wasn't quite ready for that yet. And I might be in the future, but in that moment, just standing my ground and being like, actually, I want to focus elsewhere instead. +JOËL: That's really valuable, knowing yourself and knowing where you want to go, what the next step is. Are there any exercises you like to do to try to figure that out for yourself? Because I know something that I've struggled with sometimes is not being quite sure what I want. +STEPHANIE: I journal a lot in my personal life and also about work. I think I tend to revisit that in my notes, especially about things I've learned or things that I felt excited about in terms of projects and what I've been unlearning, and just going through all of the things that I've collected over the year and synthesizing that information. +I also really like to lean on my friends and peers. So I really enjoy a good one-on-one when we just talk about those types of things, you know, dreams, hopes, goals. I like to lean on my manager a lot, too, because oftentimes, they're able to see things about my work over the past year that maybe I was just too in the weeds to be able to have that higher level perspective about. +As a third-party observer, they see a lot of things that you might not be able to, either on your current project or even opportunities for you to step into at a higher level in the company. So yeah, I think that, in some ways, it's a solitary activity, but it doesn't always have to be. +JOËL: I remember having a really good conversation with my manager as well, at some point, talking about that decision of am I interested in maybe moving into the management track? Do I want to stay on the IC side of things? And that was a really good conversation to have. +STEPHANIE: So after having those conversations and kind of figuring out what direction you wanted to go, were there times when you had to actively make that choice or advocate for yourself? +JOËL: Yes. One of the things that I realized that I care about is investing in other people, and sort of the mentoring, supporting side of things which you might think is kind of a management activity. But management is a little bit different than that. I prefer the coaching aspect than the management aspect. And so what I wanted to do at some point once, I realized that that's what I wanted and that a management position would not fulfill that desire, I started looking to see is there a way to craft that role within the company? +A common thing that happens, I think, in workplaces is that you are given roles or titles for things that you already do. Clearly, if there's something that I care about, I needed to be doing it already in my day-to-day work, and I needed to be doing it at a fairly high level. And so I focused efforts there, trying to say I want to get better at this. I want to do this in the opportunities that I do have in my current role. +And then eventually, I did go to my manager and said, "Look, this is what I am looking for in the next step." Had a discussion about whether or not management could be a fit or if we could customize a management role for this, and eventually decided that an IC role would be a better fit for that. And among other things, we introduce at thoughtbot the role of principal developer, which is kind of the next step on our career ladder. It can be a little bit different emphasis for different people on the team who have that role, but, for me, a big part of that was putting more impact on the broader team as its focus. +STEPHANIE: That's really cool. I really appreciate that you were able to come to the table with what you wanted and able to have a discussion about, okay, so management might not be the right fit. But how can we create this new role that not only benefited you but also benefited the rest of the company because that hadn't been an area that they had quite figured out yet. But by doing that, you essentially did exactly the kind of coaching and making an impact [chuckles] that you had also shared you had been wanting because you just opened this new door for others to also eventually work towards. And I think that's really awesome. +That reminds me a lot of the idea of being directly responsible for yourself and your career. There's a really good blog post by a woman named Cate, who is an engineering director at DuckDuckGo. I'll link it to the show notes. But she writes a lot about how you have to own your own career and find opportunities to have that agency. And you can always ask. Like, you might not get everything that you want, but by asking and by bringing it up, you at least can start the conversation rather than expecting or just hoping that things will turn out the way that you want without having said anything. +A couple of things that she says in the article that I also really like is the idea of expecting less from your job and more from your career. +JOËL: Hmmm. +STEPHANIE: At any given point, your job might not check all of the boxes, but maybe they check some, and that is worthwhile. And once you get to a point where maybe the job is not really doing anything towards the direction you want your overall career to go, that might be time to reevaluate. And then she also mentions learning from feedback and asking for feedback, and making sure that beyond the things that you're able to identify, learning from others areas that you can work on to have a better impact on your team is also really important in progressing your career quickly. +JOËL: So how is this mindset of owning your career path maybe different than the default that a lot of people might assume in our industry? It sounds like it's a much more proactive approach. We talked already about doing the work to figure out what you want out of a career, what you care about, as opposed to just being told what you should care about by others. Are there other aspects that you have to sort of own as part of owning that career? +STEPHANIE: I mean, I think it's just vital to having a work experience that is fulfilling and brings you joy and doesn't bog you down. I know we all have to work, but we also all have the capacity to exercise our agency there. +I know we did talk a little about management earlier, and I wanted to also plug a book, "The Manager's Path" by Camille Fournier, which is about management. But she has a really excellent first chapter about how to be managed and what you can expect from having to be an employee with a manager but also what power you have in that dynamic. She says that while you can be given opportunities and have areas of growth pointed out to you, your manager can't read your mind, and they can't tell you what will make you happy. +And so I have seen a lot of people spend time worrying about if they're doing the right things to get to the next level. But oftentimes, we just haven't really talked enough about how that next level is really totally different. And there are so many routes that that could take, whether that is becoming an open-source maintainer, or producing content like blog posts or podcasts even, or speaking at conferences, or management. +Once I realized that there were so many different opportunities available to me, I did feel a bit liberated because it does seem like, oh, you're just supposed to level up your technical skills until you've become this superstar coder. But that's not what everyone wants, and I think that's okay. +JOËL: And, like you said, there are so many different areas where you might choose to focus or invest time into, and you don't have to do them all. You don't have to be the super prolific open-source person, and also keynoting at conferences, and also publishing the book, and also, you know, whatever you want to add in there. +So once you know your goals, how do you make those goals a reality? We've been talking a lot about know yourself and have some goals. But at some point, you have to translate those goals into actions that will take you one step at a time towards those goals, and sometimes that translation step is hard. +STEPHANIE: It is hard. I think this is another place where I would work with my manager on, especially if I'm on a project where I'm not quite seeing those opportunities. Like I said, usually having another perspective or another set of eyes on what you're working on can make it clear, like, specific and concrete aspects that you can spend your energy on. +So if it's wanting to get better at testing, it's like, okay, what does the current test suite look like, and what are some opportunities that you can provide new value to the test suite to make an impact on the team? Or what are some refactoring opportunities you can make if you are wanting to have more of that experience outside of the regular ticketed feature work that you have to do? +JOËL: I think it's interesting that you mentioned impact on the team because not only do you want to level up some skills, but if nobody knows about it, your odds of getting that promotion or getting recognized for it are very low. So not only do you have to get good at technical systems, you have to get good at social systems as well. +I was recently reading an article about the role of kingship in medieval Europe and how it's very much a role that needs to play out in public in order to build legitimacy so that people will do what you say. You need to be seen to do the things that everybody has in their mental kind of checklist are things that a good king does. +And some of those are somewhat divorced from the reality of what actually is effective governance. It could be various public rituals that you do that people see and are like, oh yes, you're doing this parade every year. You're looking the part of a good king; therefore, I think of you as a good king. It could be military campaigns because there are a lot of those in the Middle Ages. +And there's this interesting cycle where kings that have long and effective reigns then get to influence what the next generation of kings are going to have to do in order to look legitimate because people will point back at you and be like, well, Stephanie was an effective ruler, and she did X,Y,Z. And so, in order to look the part of an effective ruler, you should be doing those same things. +STEPHANIE: That's fascinating. In some ways, I struggle with the idea that you have to prove that you're, you know, doing the kingly things and worthy of that title. But I do think that there is some degree of truth to that in your career as well, where you want to make sure that the work you're doing is visible. +And you also just, in general, bring up a really good idea about the importance of leadership in career progression. And I think that in my experience, and from what I've observed, that is a vital way to progress your career is to just start demonstrating leadership qualities, and that could look like reaching out to new team members and helping them with onboarding. That could mean updating the documentation, just taking the initiative, and doing that. +That could also mean starting to voice more of your opinions about risks or red flags about a certain technical implementation or a project because you have amassed the experience to be able to make those decisions and put in your two cents and then making sure that the choices that are made are the right ones. +JOËL: Additionally, I think even when you're doing things that are a little bit more inward-focused, like learning something new, you can generally find some kind of artifact that you can take and share more broadly with a team. So maybe you experimented with something, and you wrote up a small code example to showcase the thing that you're trying out; make a Gist on GitHub and share it with your team. If you learn something new, maybe write a blog post about it. Maybe even just start a thread in Slack and start a conversation on something that you learned recently. +These can be really low effort, but I always look for opportunities to take things that I have learned, things where I'm sort of working a little bit more inwardly on myself and see how can I share that with the rest of the team? Both because it benefits the team, they get to benefit from the impact of some of what you've done but also, it helps a little bit with making sure that your work is visible. +STEPHANIE: Yeah, absolutely. +JOËL: So we've been talking a lot about improving ourselves technically, but there's one question that we've danced around that we haven't actually addressed, and I'm curious about your thoughts here. For someone who's early career, do you think it's more valuable to be a specialist, someone who goes all in deep on one technology and becomes great at it? Or is it better to go more broad, become a generalist, and know a little bit about a lot of things? From the point of view of what will help move my career forward. +STEPHANIE: I personally do think there is an aspect of being a generalist for a little while, a few years maybe, to get a taste of what is available to you. I think that is valuable before really committing to decide, okay, like, this is what I want to specialize in. Honestly, as a generalist myself, I still do feel a bit like I don't know what I want to dive deep into and commit myself a little bit to being like, okay, I'm going to have to sacrifice learning all of these other things to really focus on this one aspect. +So I have found that being a generalist also kind of gives me the flexibility to work on different projects that might require learning a new language, or at least one that I am less familiar with. And I know that that's a skill in and of itself, being able to move on to different things and gather information and the skills you need to start contributing and working effectively quickly. So, honestly, I think I can really only speak to that experience, but it has served me well and is, for the most part, enjoyable to me at this present moment. What about you? Do you have any thoughts about generalist versus specialist? +JOËL: I think, in a certain sense, there's no right answer. Like we said earlier, there are multiple paths to a career in tech, and you can go through both. I think something that I've seen be less effective, especially very early career folks, is trying to go too broad, jumping on every new language or framework every couple of weeks, every month, and just dipping your toe in it and then moving on to something else and never really learning deeply, or synthesizing, or building a mental model of things. And so you're kind of stuck in the shallow end forever, and it's hard to break through into that initial level of expertise. +So I think, especially very early career people, I tend to recommend pick one language or technology and focus on getting good at that and then branch out. And, of course, you're never doing everything in a vacuum because there are a bajillion dev skills you need to learn beyond a language or framework. +So I often categorize three areas to focus on that I like to recommend for people; one is pick a primary language or framework and get good at it. Two, learn some evergreen skills, these are things like version control, so Git, SQL, using the command line. And these are not things that you need to master on day one because you're going to use these your entire career. So learn a few things, move on, come back to them next month, learn a few more things, and just keep coming back there every now and then over the course of your entire career to deepen those skills, and that will serve you very well. +And then, finally, some random thing you're interested in. I find that I learn so much faster and so much more deeply on topics that I'm interested in or passionate about. And that interest can be very random sometimes, and it can also be fleeting. It can be, oh, I was interested in a thing for a little bit, and I dug into it, and then I moved on to something else. +If I have a career or learning plan, I like to leave that room for spontaneity to say there will be things that are maybe not strategically important as my next step, but I can learn them because I'm interested in them because they bring me joy. And then later on, maybe that will actually be the foundation of something important two years down the line where I can draw on that knowledge. +STEPHANIE: You bring up a really interesting point. I do think my interpretation of generalist did line up more with the idea of those evergreen skills. So I think also about debugging and testing, and those are just part of the things that you're doing every day. And that might look different from project to project depending on what language or framework you're using and what testing philosophy people on your team abide by. +But yeah, those are areas that I do think investing in will serve you well across projects and help put you in a position where you can jump into anything and be like, okay, I have these core foundational beliefs and skills about this work and now, okay, let me figure out how to apply them to the task at hand. +JOËL: Are you familiar with the metaphor of the T-shaped developer? +STEPHANIE: I don't think so. +JOËL: So the idea is that you want to balance out a broad set of skills that you're a generalist at, that you know a little bit about them with a few things that you are a deep expert in. So you have that horizontal bar, but you also have a deep area of expertise which creates a kind of a T shape. In a sense, maybe that's just trying to say, like, do both. +But I was recently reading an article that was advocating for not only a T-shaped developer as a sort of starting point but then also beyond that, over the course of a long career, you have plenty of opportunities to develop more than one specialization. And so now you start having a very broad base of general knowledge as well as multiple areas that you have spent significant time becoming an expert in. And this article referred to this idea as a comb-shaped developer, and that's something you work up to over the course of years or decades in tech. +STEPHANIE: That's very cool. I love the idea that you might start out as a T-shaped but what you're doing is kind of like adding to your harness of skills and it being an additive process. You'd have more teeth in your comb [laughs] rather than it replacing something or a set of skills. +On that note, shall we wrap up? +JOËL: Let's wrap up. +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Joël has been thinking a lot recently about array indexing. Stephanie started volunteering at the Chicago Tooele Library, a non-profit community lending library for Chicagoans to borrow tools and equipment for DIY home projects!

+ +

It's the end of the year and often a time of reflection: looking back on the year and thinking about the next. Stephanie and Joël ponder if open source is a critical way to advance careers as software developers.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 are here to share a little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been thinking a lot recently about array indexing. I feel like this is one of the areas where you commonly get confused as a new programmer because most languages start array indexing at zero. And what we really have here are two counting systems, either an offset so how many spaces from the beginning of the array, or a counting system where you count 1,2,3,4. At first, it feels like why would computers ever go with the offset approach? It's so illogical. Counting 1,2,3,4 would feel natural.

+ +

But then, the more I think about it, the more I've started seeing the zero-based pattern show up in everyday life. One example, because I enjoy reading history, is how we talk about centuries. You might talk about the 19th century is the Victorian age, roughly. But you might also refer to the 19th century as the 1800s. So we've kind of got these two names that are a little bit off by one. And that's because when you're counting the centuries, you count first century, second century, third century, fourth century, and so on.

+ +

But when we actually go by the first two digits, you start with the zeros, then the 100s, then the 200s, 300s, and so on. And so we have a zero-based counting system and a one-based counting system, and we sort of have learned to navigate both simultaneously. So that was really interesting to me to make a connection between history and programming and the fact that sometimes we count from zero, and sometimes we count from one.

+ +

STEPHANIE: Yeah, I will have to admit that I always get confused when we're talking about centuries and making the mental connection that 19th century is the 1800s. It always takes me a bit of an extra second to make sure I know what I'm hearing, and I'm attributing it to the right year.

+ +

I think another example where I get a bit tripped up is the numbering of floors because, in the U.S., we are counting floors using the one-based counting system, whereas I think in Europe and places outside of North America, to my knowledge, the first floor will be considered the ground floor, and then the second floor will be the first floor and onward. So that is a zero-based counting system that I can recall.

+ +

JOËL: I never noticed there was a pattern. I just thought every building was arbitrary in where it counted from.

+ +

STEPHANIE: Yeah, I do think it's a cultural thing. I would be really curious to know more about the history of how those counting systems get adopted.

+ +

JOËL: So that's a fun thing that I've been exploring recently. What's new in your world, Stephanie?

+ +

STEPHANIE: I am really excited to talk about a new real-life update. I started volunteering at the Chicago Tooele Library, which is a non-profit community lending library in my city for Chicagoans to borrow tools and equipment for DIY home projects. What I really like about it is they use a pay-what-you-can model so everyone can have access to these resources. It reduces the need for people to buy new things all the time, especially for little one-off projects. And they also provide education to empower folks to learn how to do things themselves, which I thought was really cool.

+ +

And another thing that I think might be a little relevant to this audience is that I actually first encountered the Tooele library through its open-source software, which is a Ruby for Good project called Circulate. So the Tooele Library had previously been using this software that was built by community members to do all of their lending. And I got to see it in action when I saw a librarian use it to rent out tools to community members. And then I also interfaced with it myself as a member of the Tooele Library.

+ +

I've borrowed things like saws, cooking appliances like air fryers that they also had. And when I was first a guest on this show, I borrowed a microphone from them to do this podcast because I was just a guest at the time and didn't want to commit to buying a whole new microphone, so that was a really awesome way that I got to benefit from it.

+ +

JOËL: It's a fantastic resource for the community.

+ +

STEPHANIE: Yeah, I love it so much. If anyone is in Chicago and wants to check it out, I highly recommend it. And even if you're not in Chicago, if the idea of a lending library interests you, you can check out the software on Ruby for Good. And it's no longer being used by the Chicago Tooele Library, but it would be really cool to see it be picked up by other people who might want to start something similar in their own hometowns.

+ +

JOËL: So you mentioned you're volunteering here. So this means you're going in person and helping people check out items from the library.

+ +

STEPHANIE: Yeah, I did my first volunteer librarian shift about a month ago, and right now, they're in the middle of moving from one location to another, so they've had a lot of in-person workdays to get some of that done. But even before that, I had contributed a little bit to the open-source repo, which is just a pretty standard Rails project, so I felt super comfortable with getting my feet wet in it. And it was, I think, my first open-source contribution.

+ +

I find that some of the other open-source software, especially developer tooling, is a little scary to get into. So this was a really accessible way for me to contribute to that community, just leveraging the skills that I have for my day-to-day work.

+ +

JOËL: Would you recommend this project for our listeners who are looking to maybe get their own first contribution in open source?

+ +

STEPHANIE: The Circulate project is actually on a bit of a hiatus right now. But I would definitely suggest people fork it and play around with it if they want to. I also know that Ruby for Good has a bunch of other projects that are Rails apps and have real users and are having an impact that way. So if anyone wants to get into open source in a way that feels accessible and they're building a product that people are using, I definitely recommend checking that out.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So, as we're recording this, it's the end of the year. It's often a time of reflection and looking back on the year and maybe even thinking about the next year and progression. I'm curious since you said this was your introduction to the world of open source, do you think that working on open source is a critical way to advance our careers as software developers?

+ +

STEPHANIE: That's a good question. Honestly, I think my answer would be, no, it's not critical. I think it's one avenue for people to explore and increase their impact on the community and increase their technical knowledge, especially if it's in an area that they are not quite working in in their day-to-day, but they're really interested in diving deeper in.

+ +

But I do think there's sometimes a lot of pressure to feel like open source is this shining beacon of opportunity for you to dive into and that it'll bring a lot of meaning to the work that you do. And people, obviously, and for a good reason, talk about how special it is that open source is part of the industry that we work in, but I don't necessarily think it's critical.

+ +

I do certainly feel inspired by people who create open-source tools or contribute to Ruby or Rails. But I don't necessarily think that it's something that should be a rule and that everyone needs to get into it or contribute to it. Because there are many ways that people can have an impact having influence on the community, and that way is one. But there's also a lot of value, even just focusing on the team that you're on and your company internally.

+ +

JOËL: I appreciate the nuance there because I think like you said, we often view open source as the main thing that everyone should be doing to get ahead. And there are a lot of different ways to improve your skill and then to get ahead in your career, which are not always correlated. One kind of really basic way that I was shocked at how much it helped me was I was learning a new language, Elm. I joined their online Slack community and just hung out in the chat room and answered the most beginner questions because I barely knew the language at the time.

+ +

And most of these could be found just by looking up the documentation or by opening up a REPL and experimenting with a thing and giving an answer, which are skills that, as a programmer who's got some experience, I take for granted but that not everyone has that as a reflex. Because Googling, searching documentation, crafting experiments in the REPL those are all skills that you have to learn to build over time. But answering those very basic questions over and over over the course of a few months actually taught me so much about the language, and I'm not doing anything fancy.

+ +

STEPHANIE: That's awesome. I have a friend who, during a time when I think she was struggling with her confidence in her technical skill and was feeling a bit stuck at work, spent an afternoon answering Stack Overflow questions on basic Ruby and Rails, and that gave her a lot of joy. Because she recognized that she was the person Googling those questions and needing to find answers many years ago, and that was one way that she could pay it forward. And I think she had a lot of empathy, like I said, for those people who are needing a little help, and it felt really good for her to be able to provide it.

+ +

JOËL: It's a way to have an impact on other people while also solidifying your own knowledge.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: So we've mentioned a couple of different ways where you can level up your skills, that might be through helping out other people online, that could be through open source. But I'd like to zoom out a little bit and look at not just improving your technical skills but thinking about career in general when you're looking out over the next 10, 20, 30 years. Do you have an approach that you like to take when you're thinking that broadly?

+ +

STEPHANIE: For me, I have had trouble thinking about a five or 10-year plan because things often don't turn out the way that I envisioned them. And so I think I've come to realize that leaning into how I feel about things in any given moment is more valuable and oftentimes more accurate to what I really want. Because I can have an idea of what I want my career to look like, but the things that ring most true are what I'm feeling in the moment.

+ +

And so you mentioned we're releasing this episode at the end of the year. I do tend to do a little bit of recap about how my year went if I spent it doing things that fulfilled me and made me feel good, if I grew in the ways that I wanted, even separate from any performance review. I know that this is a time of reflection for a lot of people. And I don't personally ascribe to New Year's resolutions, but I do like to think about themes or intentions. And those are things that ground me rather than setting particular goals that I may or may not achieve; I may realize I want to change.

+ +

So yeah, I really recommend just sitting with yourself and spending time thinking about what you want, and that could mean a promotion, but that could also mean a more interesting project using new technology. It could mean more responsibility and decision-making power. It could mean a move into management. I think it's different for everyone. And so when people have asked me about advice or what they should do in terms of coming to a crossroads between jobs or between projects, I think that you really can't tell anyone else what is the right move for them; only they can decide.

+ +

JOËL: And tech, it's such a broad field. There are so many different roles and paths you can take through it. Well, there's junior engineer, engineer one, engineer two, engineer three, that's just the same everywhere. And there's only one way forward; it's up or stagnation, and that's it. Like you really get to choose your own adventure in this industry, and that's exciting and maybe a little bit terrifying.

+ +

STEPHANIE: Oh yeah, for sure. I like that you brought up the different levels and roles that you could have because I have found companies that provide a career ladder or engineering ladder that has been useful for me in the past in figuring out if the next step at the company that I'm at is what I want. And it's helpful. It's very clear to me, okay, these are the skills that I need to get promoted into this next level. But other times, that description describes something that I'm not interested in, and that is also really helpful information.

+ +

JOËL: Was there ever a moment in your own career where you had to navigate some of these decisions to decide what path you wanted to take as opposed to just following a ladder up?

+ +

STEPHANIE: Oh yeah. I was presented opportunities to start getting a feel for management or overseeing a team as a lead. And people had really great feedback for me that that was something that I had shown leadership in, and they thought I would do a great job in that role. But I actually decided to kind of hit the brakes a little bit on that particular route because what I realized I wanted at the time was to focus more on being an IC and deepening my technical knowledge. And that was really tough.

+ +

I do also think that a lot of women are pushed into management because they end up doing a lot of the glue work that comes with unblocking people, supporting people, and project management and those are all skills that, like, quote, unquote, "lend themselves towards management." But just because we do that work doesn't necessarily mean that that's the direction that we want our careers to go in. And so that was a really tough thing that I had to do was to make it really clear that I wasn't quite ready for that yet. And I might be in the future, but in that moment, just standing my ground and being like, actually, I want to focus elsewhere instead.

+ +

JOËL: That's really valuable, knowing yourself and knowing where you want to go, what the next step is. Are there any exercises you like to do to try to figure that out for yourself? Because I know something that I've struggled with sometimes is not being quite sure what I want.

+ +

STEPHANIE: I journal a lot in my personal life and also about work. I think I tend to revisit that in my notes, especially about things I've learned or things that I felt excited about in terms of projects and what I've been unlearning, and just going through all of the things that I've collected over the year and synthesizing that information.

+ +

I also really like to lean on my friends and peers. So I really enjoy a good one-on-one when we just talk about those types of things, you know, dreams, hopes, goals. I like to lean on my manager a lot, too, because oftentimes, they're able to see things about my work over the past year that maybe I was just too in the weeds to be able to have that higher level perspective about.

+ +

As a third-party observer, they see a lot of things that you might not be able to, either on your current project or even opportunities for you to step into at a higher level in the company. So yeah, I think that, in some ways, it's a solitary activity, but it doesn't always have to be.

+ +

JOËL: I remember having a really good conversation with my manager as well, at some point, talking about that decision of am I interested in maybe moving into the management track? Do I want to stay on the IC side of things? And that was a really good conversation to have.

+ +

STEPHANIE: So after having those conversations and kind of figuring out what direction you wanted to go, were there times when you had to actively make that choice or advocate for yourself?

+ +

JOËL: Yes. One of the things that I realized that I care about is investing in other people, and sort of the mentoring, supporting side of things which you might think is kind of a management activity. But management is a little bit different than that. I prefer the coaching aspect than the management aspect. And so what I wanted to do at some point once, I realized that that's what I wanted and that a management position would not fulfill that desire, I started looking to see is there a way to craft that role within the company?

+ +

A common thing that happens, I think, in workplaces is that you are given roles or titles for things that you already do. Clearly, if there's something that I care about, I needed to be doing it already in my day-to-day work, and I needed to be doing it at a fairly high level. And so I focused efforts there, trying to say I want to get better at this. I want to do this in the opportunities that I do have in my current role.

+ +

And then eventually, I did go to my manager and said, "Look, this is what I am looking for in the next step." Had a discussion about whether or not management could be a fit or if we could customize a management role for this, and eventually decided that an IC role would be a better fit for that. And among other things, we introduce at thoughtbot the role of principal developer, which is kind of the next step on our career ladder. It can be a little bit different emphasis for different people on the team who have that role, but, for me, a big part of that was putting more impact on the broader team as its focus.

+ +

STEPHANIE: That's really cool. I really appreciate that you were able to come to the table with what you wanted and able to have a discussion about, okay, so management might not be the right fit. But how can we create this new role that not only benefited you but also benefited the rest of the company because that hadn't been an area that they had quite figured out yet. But by doing that, you essentially did exactly the kind of coaching and making an impact [chuckles] that you had also shared you had been wanting because you just opened this new door for others to also eventually work towards. And I think that's really awesome.

+ +

That reminds me a lot of the idea of being directly responsible for yourself and your career. There's a really good blog post by a woman named Cate, who is an engineering director at DuckDuckGo. I'll link it to the show notes. But she writes a lot about how you have to own your own career and find opportunities to have that agency. And you can always ask. Like, you might not get everything that you want, but by asking and by bringing it up, you at least can start the conversation rather than expecting or just hoping that things will turn out the way that you want without having said anything.

+ +

A couple of things that she says in the article that I also really like is the idea of expecting less from your job and more from your career.

+ +

JOËL: Hmmm.

+ +

STEPHANIE: At any given point, your job might not check all of the boxes, but maybe they check some, and that is worthwhile. And once you get to a point where maybe the job is not really doing anything towards the direction you want your overall career to go, that might be time to reevaluate. And then she also mentions learning from feedback and asking for feedback, and making sure that beyond the things that you're able to identify, learning from others areas that you can work on to have a better impact on your team is also really important in progressing your career quickly.

+ +

JOËL: So how is this mindset of owning your career path maybe different than the default that a lot of people might assume in our industry? It sounds like it's a much more proactive approach. We talked already about doing the work to figure out what you want out of a career, what you care about, as opposed to just being told what you should care about by others. Are there other aspects that you have to sort of own as part of owning that career?

+ +

STEPHANIE: I mean, I think it's just vital to having a work experience that is fulfilling and brings you joy and doesn't bog you down. I know we all have to work, but we also all have the capacity to exercise our agency there.

+ +

I know we did talk a little about management earlier, and I wanted to also plug a book, "The Manager's Path" by Camille Fournier, which is about management. But she has a really excellent first chapter about how to be managed and what you can expect from having to be an employee with a manager but also what power you have in that dynamic. She says that while you can be given opportunities and have areas of growth pointed out to you, your manager can't read your mind, and they can't tell you what will make you happy.

+ +

And so I have seen a lot of people spend time worrying about if they're doing the right things to get to the next level. But oftentimes, we just haven't really talked enough about how that next level is really totally different. And there are so many routes that that could take, whether that is becoming an open-source maintainer, or producing content like blog posts or podcasts even, or speaking at conferences, or management.

+ +

Once I realized that there were so many different opportunities available to me, I did feel a bit liberated because it does seem like, oh, you're just supposed to level up your technical skills until you've become this superstar coder. But that's not what everyone wants, and I think that's okay.

+ +

JOËL: And, like you said, there are so many different areas where you might choose to focus or invest time into, and you don't have to do them all. You don't have to be the super prolific open-source person, and also keynoting at conferences, and also publishing the book, and also, you know, whatever you want to add in there.

+ +

So once you know your goals, how do you make those goals a reality? We've been talking a lot about know yourself and have some goals. But at some point, you have to translate those goals into actions that will take you one step at a time towards those goals, and sometimes that translation step is hard.

+ +

STEPHANIE: It is hard. I think this is another place where I would work with my manager on, especially if I'm on a project where I'm not quite seeing those opportunities. Like I said, usually having another perspective or another set of eyes on what you're working on can make it clear, like, specific and concrete aspects that you can spend your energy on.

+ +

So if it's wanting to get better at testing, it's like, okay, what does the current test suite look like, and what are some opportunities that you can provide new value to the test suite to make an impact on the team? Or what are some refactoring opportunities you can make if you are wanting to have more of that experience outside of the regular ticketed feature work that you have to do?

+ +

JOËL: I think it's interesting that you mentioned impact on the team because not only do you want to level up some skills, but if nobody knows about it, your odds of getting that promotion or getting recognized for it are very low. So not only do you have to get good at technical systems, you have to get good at social systems as well.

+ +

I was recently reading an article about the role of kingship in medieval Europe and how it's very much a role that needs to play out in public in order to build legitimacy so that people will do what you say. You need to be seen to do the things that everybody has in their mental kind of checklist are things that a good king does.

+ +

And some of those are somewhat divorced from the reality of what actually is effective governance. It could be various public rituals that you do that people see and are like, oh yes, you're doing this parade every year. You're looking the part of a good king; therefore, I think of you as a good king. It could be military campaigns because there are a lot of those in the Middle Ages.

+ +

And there's this interesting cycle where kings that have long and effective reigns then get to influence what the next generation of kings are going to have to do in order to look legitimate because people will point back at you and be like, well, Stephanie was an effective ruler, and she did X,Y,Z. And so, in order to look the part of an effective ruler, you should be doing those same things.

+ +

STEPHANIE: That's fascinating. In some ways, I struggle with the idea that you have to prove that you're, you know, doing the kingly things and worthy of that title. But I do think that there is some degree of truth to that in your career as well, where you want to make sure that the work you're doing is visible.

+ +

And you also just, in general, bring up a really good idea about the importance of leadership in career progression. And I think that in my experience, and from what I've observed, that is a vital way to progress your career is to just start demonstrating leadership qualities, and that could look like reaching out to new team members and helping them with onboarding. That could mean updating the documentation, just taking the initiative, and doing that.

+ +

That could also mean starting to voice more of your opinions about risks or red flags about a certain technical implementation or a project because you have amassed the experience to be able to make those decisions and put in your two cents and then making sure that the choices that are made are the right ones.

+ +

JOËL: Additionally, I think even when you're doing things that are a little bit more inward-focused, like learning something new, you can generally find some kind of artifact that you can take and share more broadly with a team. So maybe you experimented with something, and you wrote up a small code example to showcase the thing that you're trying out; make a Gist on GitHub and share it with your team. If you learn something new, maybe write a blog post about it. Maybe even just start a thread in Slack and start a conversation on something that you learned recently.

+ +

These can be really low effort, but I always look for opportunities to take things that I have learned, things where I'm sort of working a little bit more inwardly on myself and see how can I share that with the rest of the team? Both because it benefits the team, they get to benefit from the impact of some of what you've done but also, it helps a little bit with making sure that your work is visible.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: So we've been talking a lot about improving ourselves technically, but there's one question that we've danced around that we haven't actually addressed, and I'm curious about your thoughts here. For someone who's early career, do you think it's more valuable to be a specialist, someone who goes all in deep on one technology and becomes great at it? Or is it better to go more broad, become a generalist, and know a little bit about a lot of things? From the point of view of what will help move my career forward.

+ +

STEPHANIE: I personally do think there is an aspect of being a generalist for a little while, a few years maybe, to get a taste of what is available to you. I think that is valuable before really committing to decide, okay, like, this is what I want to specialize in. Honestly, as a generalist myself, I still do feel a bit like I don't know what I want to dive deep into and commit myself a little bit to being like, okay, I'm going to have to sacrifice learning all of these other things to really focus on this one aspect.

+ +

So I have found that being a generalist also kind of gives me the flexibility to work on different projects that might require learning a new language, or at least one that I am less familiar with. And I know that that's a skill in and of itself, being able to move on to different things and gather information and the skills you need to start contributing and working effectively quickly. So, honestly, I think I can really only speak to that experience, but it has served me well and is, for the most part, enjoyable to me at this present moment. What about you? Do you have any thoughts about generalist versus specialist?

+ +

JOËL: I think, in a certain sense, there's no right answer. Like we said earlier, there are multiple paths to a career in tech, and you can go through both. I think something that I've seen be less effective, especially very early career folks, is trying to go too broad, jumping on every new language or framework every couple of weeks, every month, and just dipping your toe in it and then moving on to something else and never really learning deeply, or synthesizing, or building a mental model of things. And so you're kind of stuck in the shallow end forever, and it's hard to break through into that initial level of expertise.

+ +

So I think, especially very early career people, I tend to recommend pick one language or technology and focus on getting good at that and then branch out. And, of course, you're never doing everything in a vacuum because there are a bajillion dev skills you need to learn beyond a language or framework.

+ +

So I often categorize three areas to focus on that I like to recommend for people; one is pick a primary language or framework and get good at it. Two, learn some evergreen skills, these are things like version control, so Git, SQL, using the command line. And these are not things that you need to master on day one because you're going to use these your entire career. So learn a few things, move on, come back to them next month, learn a few more things, and just keep coming back there every now and then over the course of your entire career to deepen those skills, and that will serve you very well.

+ +

And then, finally, some random thing you're interested in. I find that I learn so much faster and so much more deeply on topics that I'm interested in or passionate about. And that interest can be very random sometimes, and it can also be fleeting. It can be, oh, I was interested in a thing for a little bit, and I dug into it, and then I moved on to something else.

+ +

If I have a career or learning plan, I like to leave that room for spontaneity to say there will be things that are maybe not strategically important as my next step, but I can learn them because I'm interested in them because they bring me joy. And then later on, maybe that will actually be the foundation of something important two years down the line where I can draw on that knowledge.

+ +

STEPHANIE: You bring up a really interesting point. I do think my interpretation of generalist did line up more with the idea of those evergreen skills. So I think also about debugging and testing, and those are just part of the things that you're doing every day. And that might look different from project to project depending on what language or framework you're using and what testing philosophy people on your team abide by.

+ +

But yeah, those are areas that I do think investing in will serve you well across projects and help put you in a position where you can jump into anything and be like, okay, I have these core foundational beliefs and skills about this work and now, okay, let me figure out how to apply them to the task at hand.

+ +

JOËL: Are you familiar with the metaphor of the T-shaped developer?

+ +

STEPHANIE: I don't think so.

+ +

JOËL: So the idea is that you want to balance out a broad set of skills that you're a generalist at, that you know a little bit about them with a few things that you are a deep expert in. So you have that horizontal bar, but you also have a deep area of expertise which creates a kind of a T shape. In a sense, maybe that's just trying to say, like, do both.

+ +

But I was recently reading an article that was advocating for not only a T-shaped developer as a sort of starting point but then also beyond that, over the course of a long career, you have plenty of opportunities to develop more than one specialization. And so now you start having a very broad base of general knowledge as well as multiple areas that you have spent significant time becoming an expert in. And this article referred to this idea as a comb-shaped developer, and that's something you work up to over the course of years or decades in tech.

+ +

STEPHANIE: That's very cool. I love the idea that you might start out as a T-shaped but what you're doing is kind of like adding to your harness of skills and it being an additive process. You'd have more teeth in your comb [laughs] rather than it replacing something or a set of skills.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Joël has been thinking a lot recently about array indexing. Stephanie started volunteering at the Chicago Tooele Library, a non-profit community lending library for Chicagoans to borrow tools and equipment for DIY home projects!

+ +

It's the end of the year and often a time of reflection: looking back on the year and thinking about the next. Stephanie and Joël ponder if open source is a critical way to advance careers as software developers.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 are here to share a little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I've been thinking a lot recently about array indexing. I feel like this is one of the areas where you commonly get confused as a new programmer because most languages start array indexing at zero. And what we really have here are two counting systems, either an offset so how many spaces from the beginning of the array, or a counting system where you count 1,2,3,4. At first, it feels like why would computers ever go with the offset approach? It's so illogical. Counting 1,2,3,4 would feel natural.

+ +

But then, the more I think about it, the more I've started seeing the zero-based pattern show up in everyday life. One example, because I enjoy reading history, is how we talk about centuries. You might talk about the 19th century is the Victorian age, roughly. But you might also refer to the 19th century as the 1800s. So we've kind of got these two names that are a little bit off by one. And that's because when you're counting the centuries, you count first century, second century, third century, fourth century, and so on.

+ +

But when we actually go by the first two digits, you start with the zeros, then the 100s, then the 200s, 300s, and so on. And so we have a zero-based counting system and a one-based counting system, and we sort of have learned to navigate both simultaneously. So that was really interesting to me to make a connection between history and programming and the fact that sometimes we count from zero, and sometimes we count from one.

+ +

STEPHANIE: Yeah, I will have to admit that I always get confused when we're talking about centuries and making the mental connection that 19th century is the 1800s. It always takes me a bit of an extra second to make sure I know what I'm hearing, and I'm attributing it to the right year.

+ +

I think another example where I get a bit tripped up is the numbering of floors because, in the U.S., we are counting floors using the one-based counting system, whereas I think in Europe and places outside of North America, to my knowledge, the first floor will be considered the ground floor, and then the second floor will be the first floor and onward. So that is a zero-based counting system that I can recall.

+ +

JOËL: I never noticed there was a pattern. I just thought every building was arbitrary in where it counted from.

+ +

STEPHANIE: Yeah, I do think it's a cultural thing. I would be really curious to know more about the history of how those counting systems get adopted.

+ +

JOËL: So that's a fun thing that I've been exploring recently. What's new in your world, Stephanie?

+ +

STEPHANIE: I am really excited to talk about a new real-life update. I started volunteering at the Chicago Tooele Library, which is a non-profit community lending library in my city for Chicagoans to borrow tools and equipment for DIY home projects. What I really like about it is they use a pay-what-you-can model so everyone can have access to these resources. It reduces the need for people to buy new things all the time, especially for little one-off projects. And they also provide education to empower folks to learn how to do things themselves, which I thought was really cool.

+ +

And another thing that I think might be a little relevant to this audience is that I actually first encountered the Tooele library through its open-source software, which is a Ruby for Good project called Circulate. So the Tooele Library had previously been using this software that was built by community members to do all of their lending. And I got to see it in action when I saw a librarian use it to rent out tools to community members. And then I also interfaced with it myself as a member of the Tooele Library.

+ +

I've borrowed things like saws, cooking appliances like air fryers that they also had. And when I was first a guest on this show, I borrowed a microphone from them to do this podcast because I was just a guest at the time and didn't want to commit to buying a whole new microphone, so that was a really awesome way that I got to benefit from it.

+ +

JOËL: It's a fantastic resource for the community.

+ +

STEPHANIE: Yeah, I love it so much. If anyone is in Chicago and wants to check it out, I highly recommend it. And even if you're not in Chicago, if the idea of a lending library interests you, you can check out the software on Ruby for Good. And it's no longer being used by the Chicago Tooele Library, but it would be really cool to see it be picked up by other people who might want to start something similar in their own hometowns.

+ +

JOËL: So you mentioned you're volunteering here. So this means you're going in person and helping people check out items from the library.

+ +

STEPHANIE: Yeah, I did my first volunteer librarian shift about a month ago, and right now, they're in the middle of moving from one location to another, so they've had a lot of in-person workdays to get some of that done. But even before that, I had contributed a little bit to the open-source repo, which is just a pretty standard Rails project, so I felt super comfortable with getting my feet wet in it. And it was, I think, my first open-source contribution.

+ +

I find that some of the other open-source software, especially developer tooling, is a little scary to get into. So this was a really accessible way for me to contribute to that community, just leveraging the skills that I have for my day-to-day work.

+ +

JOËL: Would you recommend this project for our listeners who are looking to maybe get their own first contribution in open source?

+ +

STEPHANIE: The Circulate project is actually on a bit of a hiatus right now. But I would definitely suggest people fork it and play around with it if they want to. I also know that Ruby for Good has a bunch of other projects that are Rails apps and have real users and are having an impact that way. So if anyone wants to get into open source in a way that feels accessible and they're building a product that people are using, I definitely recommend checking that out.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So, as we're recording this, it's the end of the year. It's often a time of reflection and looking back on the year and maybe even thinking about the next year and progression. I'm curious since you said this was your introduction to the world of open source, do you think that working on open source is a critical way to advance our careers as software developers?

+ +

STEPHANIE: That's a good question. Honestly, I think my answer would be, no, it's not critical. I think it's one avenue for people to explore and increase their impact on the community and increase their technical knowledge, especially if it's in an area that they are not quite working in in their day-to-day, but they're really interested in diving deeper in.

+ +

But I do think there's sometimes a lot of pressure to feel like open source is this shining beacon of opportunity for you to dive into and that it'll bring a lot of meaning to the work that you do. And people, obviously, and for a good reason, talk about how special it is that open source is part of the industry that we work in, but I don't necessarily think it's critical.

+ +

I do certainly feel inspired by people who create open-source tools or contribute to Ruby or Rails. But I don't necessarily think that it's something that should be a rule and that everyone needs to get into it or contribute to it. Because there are many ways that people can have an impact having influence on the community, and that way is one. But there's also a lot of value, even just focusing on the team that you're on and your company internally.

+ +

JOËL: I appreciate the nuance there because I think like you said, we often view open source as the main thing that everyone should be doing to get ahead. And there are a lot of different ways to improve your skill and then to get ahead in your career, which are not always correlated. One kind of really basic way that I was shocked at how much it helped me was I was learning a new language, Elm. I joined their online Slack community and just hung out in the chat room and answered the most beginner questions because I barely knew the language at the time.

+ +

And most of these could be found just by looking up the documentation or by opening up a REPL and experimenting with a thing and giving an answer, which are skills that, as a programmer who's got some experience, I take for granted but that not everyone has that as a reflex. Because Googling, searching documentation, crafting experiments in the REPL those are all skills that you have to learn to build over time. But answering those very basic questions over and over over the course of a few months actually taught me so much about the language, and I'm not doing anything fancy.

+ +

STEPHANIE: That's awesome. I have a friend who, during a time when I think she was struggling with her confidence in her technical skill and was feeling a bit stuck at work, spent an afternoon answering Stack Overflow questions on basic Ruby and Rails, and that gave her a lot of joy. Because she recognized that she was the person Googling those questions and needing to find answers many years ago, and that was one way that she could pay it forward. And I think she had a lot of empathy, like I said, for those people who are needing a little help, and it felt really good for her to be able to provide it.

+ +

JOËL: It's a way to have an impact on other people while also solidifying your own knowledge.

+ +

STEPHANIE: Yeah, exactly.

+ +

JOËL: So we've mentioned a couple of different ways where you can level up your skills, that might be through helping out other people online, that could be through open source. But I'd like to zoom out a little bit and look at not just improving your technical skills but thinking about career in general when you're looking out over the next 10, 20, 30 years. Do you have an approach that you like to take when you're thinking that broadly?

+ +

STEPHANIE: For me, I have had trouble thinking about a five or 10-year plan because things often don't turn out the way that I envisioned them. And so I think I've come to realize that leaning into how I feel about things in any given moment is more valuable and oftentimes more accurate to what I really want. Because I can have an idea of what I want my career to look like, but the things that ring most true are what I'm feeling in the moment.

+ +

And so you mentioned we're releasing this episode at the end of the year. I do tend to do a little bit of recap about how my year went if I spent it doing things that fulfilled me and made me feel good, if I grew in the ways that I wanted, even separate from any performance review. I know that this is a time of reflection for a lot of people. And I don't personally ascribe to New Year's resolutions, but I do like to think about themes or intentions. And those are things that ground me rather than setting particular goals that I may or may not achieve; I may realize I want to change.

+ +

So yeah, I really recommend just sitting with yourself and spending time thinking about what you want, and that could mean a promotion, but that could also mean a more interesting project using new technology. It could mean more responsibility and decision-making power. It could mean a move into management. I think it's different for everyone. And so when people have asked me about advice or what they should do in terms of coming to a crossroads between jobs or between projects, I think that you really can't tell anyone else what is the right move for them; only they can decide.

+ +

JOËL: And tech, it's such a broad field. There are so many different roles and paths you can take through it. Well, there's junior engineer, engineer one, engineer two, engineer three, that's just the same everywhere. And there's only one way forward; it's up or stagnation, and that's it. Like you really get to choose your own adventure in this industry, and that's exciting and maybe a little bit terrifying.

+ +

STEPHANIE: Oh yeah, for sure. I like that you brought up the different levels and roles that you could have because I have found companies that provide a career ladder or engineering ladder that has been useful for me in the past in figuring out if the next step at the company that I'm at is what I want. And it's helpful. It's very clear to me, okay, these are the skills that I need to get promoted into this next level. But other times, that description describes something that I'm not interested in, and that is also really helpful information.

+ +

JOËL: Was there ever a moment in your own career where you had to navigate some of these decisions to decide what path you wanted to take as opposed to just following a ladder up?

+ +

STEPHANIE: Oh yeah. I was presented opportunities to start getting a feel for management or overseeing a team as a lead. And people had really great feedback for me that that was something that I had shown leadership in, and they thought I would do a great job in that role. But I actually decided to kind of hit the brakes a little bit on that particular route because what I realized I wanted at the time was to focus more on being an IC and deepening my technical knowledge. And that was really tough.

+ +

I do also think that a lot of women are pushed into management because they end up doing a lot of the glue work that comes with unblocking people, supporting people, and project management and those are all skills that, like, quote, unquote, "lend themselves towards management." But just because we do that work doesn't necessarily mean that that's the direction that we want our careers to go in. And so that was a really tough thing that I had to do was to make it really clear that I wasn't quite ready for that yet. And I might be in the future, but in that moment, just standing my ground and being like, actually, I want to focus elsewhere instead.

+ +

JOËL: That's really valuable, knowing yourself and knowing where you want to go, what the next step is. Are there any exercises you like to do to try to figure that out for yourself? Because I know something that I've struggled with sometimes is not being quite sure what I want.

+ +

STEPHANIE: I journal a lot in my personal life and also about work. I think I tend to revisit that in my notes, especially about things I've learned or things that I felt excited about in terms of projects and what I've been unlearning, and just going through all of the things that I've collected over the year and synthesizing that information.

+ +

I also really like to lean on my friends and peers. So I really enjoy a good one-on-one when we just talk about those types of things, you know, dreams, hopes, goals. I like to lean on my manager a lot, too, because oftentimes, they're able to see things about my work over the past year that maybe I was just too in the weeds to be able to have that higher level perspective about.

+ +

As a third-party observer, they see a lot of things that you might not be able to, either on your current project or even opportunities for you to step into at a higher level in the company. So yeah, I think that, in some ways, it's a solitary activity, but it doesn't always have to be.

+ +

JOËL: I remember having a really good conversation with my manager as well, at some point, talking about that decision of am I interested in maybe moving into the management track? Do I want to stay on the IC side of things? And that was a really good conversation to have.

+ +

STEPHANIE: So after having those conversations and kind of figuring out what direction you wanted to go, were there times when you had to actively make that choice or advocate for yourself?

+ +

JOËL: Yes. One of the things that I realized that I care about is investing in other people, and sort of the mentoring, supporting side of things which you might think is kind of a management activity. But management is a little bit different than that. I prefer the coaching aspect than the management aspect. And so what I wanted to do at some point once, I realized that that's what I wanted and that a management position would not fulfill that desire, I started looking to see is there a way to craft that role within the company?

+ +

A common thing that happens, I think, in workplaces is that you are given roles or titles for things that you already do. Clearly, if there's something that I care about, I needed to be doing it already in my day-to-day work, and I needed to be doing it at a fairly high level. And so I focused efforts there, trying to say I want to get better at this. I want to do this in the opportunities that I do have in my current role.

+ +

And then eventually, I did go to my manager and said, "Look, this is what I am looking for in the next step." Had a discussion about whether or not management could be a fit or if we could customize a management role for this, and eventually decided that an IC role would be a better fit for that. And among other things, we introduce at thoughtbot the role of principal developer, which is kind of the next step on our career ladder. It can be a little bit different emphasis for different people on the team who have that role, but, for me, a big part of that was putting more impact on the broader team as its focus.

+ +

STEPHANIE: That's really cool. I really appreciate that you were able to come to the table with what you wanted and able to have a discussion about, okay, so management might not be the right fit. But how can we create this new role that not only benefited you but also benefited the rest of the company because that hadn't been an area that they had quite figured out yet. But by doing that, you essentially did exactly the kind of coaching and making an impact [chuckles] that you had also shared you had been wanting because you just opened this new door for others to also eventually work towards. And I think that's really awesome.

+ +

That reminds me a lot of the idea of being directly responsible for yourself and your career. There's a really good blog post by a woman named Cate, who is an engineering director at DuckDuckGo. I'll link it to the show notes. But she writes a lot about how you have to own your own career and find opportunities to have that agency. And you can always ask. Like, you might not get everything that you want, but by asking and by bringing it up, you at least can start the conversation rather than expecting or just hoping that things will turn out the way that you want without having said anything.

+ +

A couple of things that she says in the article that I also really like is the idea of expecting less from your job and more from your career.

+ +

JOËL: Hmmm.

+ +

STEPHANIE: At any given point, your job might not check all of the boxes, but maybe they check some, and that is worthwhile. And once you get to a point where maybe the job is not really doing anything towards the direction you want your overall career to go, that might be time to reevaluate. And then she also mentions learning from feedback and asking for feedback, and making sure that beyond the things that you're able to identify, learning from others areas that you can work on to have a better impact on your team is also really important in progressing your career quickly.

+ +

JOËL: So how is this mindset of owning your career path maybe different than the default that a lot of people might assume in our industry? It sounds like it's a much more proactive approach. We talked already about doing the work to figure out what you want out of a career, what you care about, as opposed to just being told what you should care about by others. Are there other aspects that you have to sort of own as part of owning that career?

+ +

STEPHANIE: I mean, I think it's just vital to having a work experience that is fulfilling and brings you joy and doesn't bog you down. I know we all have to work, but we also all have the capacity to exercise our agency there.

+ +

I know we did talk a little about management earlier, and I wanted to also plug a book, "The Manager's Path" by Camille Fournier, which is about management. But she has a really excellent first chapter about how to be managed and what you can expect from having to be an employee with a manager but also what power you have in that dynamic. She says that while you can be given opportunities and have areas of growth pointed out to you, your manager can't read your mind, and they can't tell you what will make you happy.

+ +

And so I have seen a lot of people spend time worrying about if they're doing the right things to get to the next level. But oftentimes, we just haven't really talked enough about how that next level is really totally different. And there are so many routes that that could take, whether that is becoming an open-source maintainer, or producing content like blog posts or podcasts even, or speaking at conferences, or management.

+ +

Once I realized that there were so many different opportunities available to me, I did feel a bit liberated because it does seem like, oh, you're just supposed to level up your technical skills until you've become this superstar coder. But that's not what everyone wants, and I think that's okay.

+ +

JOËL: And, like you said, there are so many different areas where you might choose to focus or invest time into, and you don't have to do them all. You don't have to be the super prolific open-source person, and also keynoting at conferences, and also publishing the book, and also, you know, whatever you want to add in there.

+ +

So once you know your goals, how do you make those goals a reality? We've been talking a lot about know yourself and have some goals. But at some point, you have to translate those goals into actions that will take you one step at a time towards those goals, and sometimes that translation step is hard.

+ +

STEPHANIE: It is hard. I think this is another place where I would work with my manager on, especially if I'm on a project where I'm not quite seeing those opportunities. Like I said, usually having another perspective or another set of eyes on what you're working on can make it clear, like, specific and concrete aspects that you can spend your energy on.

+ +

So if it's wanting to get better at testing, it's like, okay, what does the current test suite look like, and what are some opportunities that you can provide new value to the test suite to make an impact on the team? Or what are some refactoring opportunities you can make if you are wanting to have more of that experience outside of the regular ticketed feature work that you have to do?

+ +

JOËL: I think it's interesting that you mentioned impact on the team because not only do you want to level up some skills, but if nobody knows about it, your odds of getting that promotion or getting recognized for it are very low. So not only do you have to get good at technical systems, you have to get good at social systems as well.

+ +

I was recently reading an article about the role of kingship in medieval Europe and how it's very much a role that needs to play out in public in order to build legitimacy so that people will do what you say. You need to be seen to do the things that everybody has in their mental kind of checklist are things that a good king does.

+ +

And some of those are somewhat divorced from the reality of what actually is effective governance. It could be various public rituals that you do that people see and are like, oh yes, you're doing this parade every year. You're looking the part of a good king; therefore, I think of you as a good king. It could be military campaigns because there are a lot of those in the Middle Ages.

+ +

And there's this interesting cycle where kings that have long and effective reigns then get to influence what the next generation of kings are going to have to do in order to look legitimate because people will point back at you and be like, well, Stephanie was an effective ruler, and she did X,Y,Z. And so, in order to look the part of an effective ruler, you should be doing those same things.

+ +

STEPHANIE: That's fascinating. In some ways, I struggle with the idea that you have to prove that you're, you know, doing the kingly things and worthy of that title. But I do think that there is some degree of truth to that in your career as well, where you want to make sure that the work you're doing is visible.

+ +

And you also just, in general, bring up a really good idea about the importance of leadership in career progression. And I think that in my experience, and from what I've observed, that is a vital way to progress your career is to just start demonstrating leadership qualities, and that could look like reaching out to new team members and helping them with onboarding. That could mean updating the documentation, just taking the initiative, and doing that.

+ +

That could also mean starting to voice more of your opinions about risks or red flags about a certain technical implementation or a project because you have amassed the experience to be able to make those decisions and put in your two cents and then making sure that the choices that are made are the right ones.

+ +

JOËL: Additionally, I think even when you're doing things that are a little bit more inward-focused, like learning something new, you can generally find some kind of artifact that you can take and share more broadly with a team. So maybe you experimented with something, and you wrote up a small code example to showcase the thing that you're trying out; make a Gist on GitHub and share it with your team. If you learn something new, maybe write a blog post about it. Maybe even just start a thread in Slack and start a conversation on something that you learned recently.

+ +

These can be really low effort, but I always look for opportunities to take things that I have learned, things where I'm sort of working a little bit more inwardly on myself and see how can I share that with the rest of the team? Both because it benefits the team, they get to benefit from the impact of some of what you've done but also, it helps a little bit with making sure that your work is visible.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: So we've been talking a lot about improving ourselves technically, but there's one question that we've danced around that we haven't actually addressed, and I'm curious about your thoughts here. For someone who's early career, do you think it's more valuable to be a specialist, someone who goes all in deep on one technology and becomes great at it? Or is it better to go more broad, become a generalist, and know a little bit about a lot of things? From the point of view of what will help move my career forward.

+ +

STEPHANIE: I personally do think there is an aspect of being a generalist for a little while, a few years maybe, to get a taste of what is available to you. I think that is valuable before really committing to decide, okay, like, this is what I want to specialize in. Honestly, as a generalist myself, I still do feel a bit like I don't know what I want to dive deep into and commit myself a little bit to being like, okay, I'm going to have to sacrifice learning all of these other things to really focus on this one aspect.

+ +

So I have found that being a generalist also kind of gives me the flexibility to work on different projects that might require learning a new language, or at least one that I am less familiar with. And I know that that's a skill in and of itself, being able to move on to different things and gather information and the skills you need to start contributing and working effectively quickly. So, honestly, I think I can really only speak to that experience, but it has served me well and is, for the most part, enjoyable to me at this present moment. What about you? Do you have any thoughts about generalist versus specialist?

+ +

JOËL: I think, in a certain sense, there's no right answer. Like we said earlier, there are multiple paths to a career in tech, and you can go through both. I think something that I've seen be less effective, especially very early career folks, is trying to go too broad, jumping on every new language or framework every couple of weeks, every month, and just dipping your toe in it and then moving on to something else and never really learning deeply, or synthesizing, or building a mental model of things. And so you're kind of stuck in the shallow end forever, and it's hard to break through into that initial level of expertise.

+ +

So I think, especially very early career people, I tend to recommend pick one language or technology and focus on getting good at that and then branch out. And, of course, you're never doing everything in a vacuum because there are a bajillion dev skills you need to learn beyond a language or framework.

+ +

So I often categorize three areas to focus on that I like to recommend for people; one is pick a primary language or framework and get good at it. Two, learn some evergreen skills, these are things like version control, so Git, SQL, using the command line. And these are not things that you need to master on day one because you're going to use these your entire career. So learn a few things, move on, come back to them next month, learn a few more things, and just keep coming back there every now and then over the course of your entire career to deepen those skills, and that will serve you very well.

+ +

And then, finally, some random thing you're interested in. I find that I learn so much faster and so much more deeply on topics that I'm interested in or passionate about. And that interest can be very random sometimes, and it can also be fleeting. It can be, oh, I was interested in a thing for a little bit, and I dug into it, and then I moved on to something else.

+ +

If I have a career or learning plan, I like to leave that room for spontaneity to say there will be things that are maybe not strategically important as my next step, but I can learn them because I'm interested in them because they bring me joy. And then later on, maybe that will actually be the foundation of something important two years down the line where I can draw on that knowledge.

+ +

STEPHANIE: You bring up a really interesting point. I do think my interpretation of generalist did line up more with the idea of those evergreen skills. So I think also about debugging and testing, and those are just part of the things that you're doing every day. And that might look different from project to project depending on what language or framework you're using and what testing philosophy people on your team abide by.

+ +

But yeah, those are areas that I do think investing in will serve you well across projects and help put you in a position where you can jump into anything and be like, okay, I have these core foundational beliefs and skills about this work and now, okay, let me figure out how to apply them to the task at hand.

+ +

JOËL: Are you familiar with the metaphor of the T-shaped developer?

+ +

STEPHANIE: I don't think so.

+ +

JOËL: So the idea is that you want to balance out a broad set of skills that you're a generalist at, that you know a little bit about them with a few things that you are a deep expert in. So you have that horizontal bar, but you also have a deep area of expertise which creates a kind of a T shape. In a sense, maybe that's just trying to say, like, do both.

+ +

But I was recently reading an article that was advocating for not only a T-shaped developer as a sort of starting point but then also beyond that, over the course of a long career, you have plenty of opportunities to develop more than one specialization. And so now you start having a very broad base of general knowledge as well as multiple areas that you have spent significant time becoming an expert in. And this article referred to this idea as a comb-shaped developer, and that's something you work up to over the course of years or decades in tech.

+ +

STEPHANIE: That's very cool. I love the idea that you might start out as a T-shaped but what you're doing is kind of like adding to your harness of skills and it being an additive process. You'd have more teeth in your comb [laughs] rather than it replacing something or a set of skills.

+ +

On that note, shall we wrap up?

+ +

JOËL: Let's wrap up.

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+2l3wQLEB + + ]]> + + Joël Quenneville + Stephanie Minn + + + 364: Constructive vs Predicative Data + https://bikeshed.thoughtbot.com/364 + 98bb213f-8e15-45f5-b68c-51d4fb3fe70d + Tue, 06 Dec 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Stephanie and Joël attended RubyConf Mini, and both spoke there. They discuss takeaways and highlights from the conference. + +The core idea for this episode is explained in this article: [Constructive vs. Predicative Data](https://www.hillelwayne.com/post/constructive/). This came up recently in a conversation at thoughtbot about designing a database schema and what constraints could be encoded in the schema directly versus needing some kind of trigger or Rails validation to cover it. + 34:07 + no + + + Stephanie and Joël attended RubyConf Mini, and both spoke there. They discuss takeaways and highlights from the conference. +The core idea for this episode is explained in this article: Constructive vs. Predicative Data (https://www.hillelwayne.com/post/constructive/). This came up recently in a conversation at thoughtbot about designing a database schema and what constraints could be encoded in the schema directly versus needing some kind of trigger or Rails validation to cover it. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +RubyConf Mini (https://www.rubyconfmini.com/) +Episode on CFP - The Bike Shed 352: Case Expressions (https://www.bikeshed.fm/352) +Podcast panel: The Ruby on Rails Podcast Episode 446: I'm Giving A Talk on Thursday (https://www.therubyonrailspodcast.com/446) +Slides for FP talk: Functional Programming for Fun and Profit!! (https://speakerdeck.com/jennyshih/functional-programming-for-fun-and-profit?slide=107) +Episode on language: The Bike Shed - 356: The Value of Specialized Vocabulary (https://www.bikeshed.fm/356) +Constructive vs. Predicative data (https://www.hillelwayne.com/post/constructive/) +Avoid the Three-state Boolean Problem (https://thoughtbot.com/blog/avoid-the-threestate-boolean-problem) +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 something that's very recent in both of our worlds has been that both you and I, Stephanie, attended RubyConf Mini, and we both spoke there. What are some of your takeaways or highlights from the conference? +STEPHANIE: Seeing you in person was definitely a highlight. I really enjoyed that. Because we're working remotely, I don't, you know, get to be in an office with you day to day. And it was really awesome to hang out with you, I think, for the first time as co-hosts of the podcast. And we both, I think, met some people at the conference too that were listeners. And it was really awesome to share that experience with you. +JOËL: I had the interesting experience of several people who told me they recognized me by my voice, which I think is a common thing for podcasters, but as a new host, I was surprised by that. +STEPHANIE: Yeah, that's weird. As a podcast listener, too, I definitely know exactly what you're talking about where it's like, oh yeah, I can identify someone by their voice. But to then be that person that people can recognize is pretty weird. +I also really enjoyed being an audience member of the podcast panel that you are on at the conference with other podcast folks. It was moderated by Brittany Martin. And yeah, I just thought you represented The Bike Shed really well and spoke for both of us about podcasting in a way that I really appreciated. +JOËL: And for any of our listeners who were not able to be there in person, Brittany has published that episode as a podcast, and we will link to it in the show notes. +STEPHANIE: Another thing I really liked about RubyConf Mini was the smaller scale. I think it was about 150 or so attendees, which felt very different from traditional Ruby Central conferences with several hundreds of people. I heard a lot from other folks there that they really liked the regional aspect of it, the intimacy of the smaller conference. +I think I got more of an opportunity to run into people that I'd met at the conference over the next few days. And there was, yeah, definitely a sense of tighter knit community there, you know, when you meet someone, and then you bump into them on the way into a talk, and then you can ask how their day was going and any highlights that they had. And yeah, I guess I haven't really attended a conference that size before, and so that felt like a very special experience for me. +JOËL: I 100% agree. I think the smaller format definitely makes it a little bit more intimate, makes it much easier, I think, to build some of those social connections, to meet with people, and to have some good conversations. I think the format of the conference as well favored that. There were, I think, larger breaks between talks that encouraged people to hang out and talk. And, as you said, because it's smaller, you also get to see the same people over the course of a few different breaks instead of being like, oh, I met a stranger on the morning of day one, and then in the afternoon, I met another stranger. And it's just constantly introducing yourself. +One thing that was really interesting to me is the experience of being a speaker is very different than just attending. As a speaker, you get to go to the speaker dinner and connect with a lot of the other speakers there. Some of them might be quote, unquote "famous people" that you're not quite comfortable just walking up to and introducing yourself. But in the smaller dinner, you just find yourself sitting next to them and enjoying some food or a drink and getting conversations. +It's also much easier to have people come up to you during the conference. Because you're a speaker, people will come and talk to you. So if you tend to be a little bit more introverted, as long as you can get over your fear of being on stage and public speaking, it actually makes social connection interaction much easier to be a speaker. I would recommend to any of our listeners who were wondering how can I get more out of a conference? How can I get better connections, better conversations? Consider being a speaker. +STEPHANIE: Yeah, absolutely. We've talked about this before; I think when we chatted about writing our CFPs for this conference that speaking doesn't have to be a really big, scary thing, but everyone has something to say. I think we had mentioned in previous episodes that your talk topic came out of just a discussion that you had internally, and you were like, wow, enumerables are so cool, like, let me dig deeper into them and just share what I learned. So I totally recommend it. +And this conference was my first in real-life speaking opportunity as well, and that felt super different from my experience last time doing it virtually, you know, talking about how much I love that sense of community all the time. But it really felt true for me this time around, where I could see the audience react to the things I was saying, like, maybe go off the cuff a little bit. +And then yeah, at the end, having people come up to me was really awesome to just talk about pairing, which is what I spoke about, and just share our experiences. And they asked what I thought about some things, and it was really cool to just be able to spread that knowledge around. And one thing I noticed you did a lot was come up to speakers after they wrapped up their talks. You were almost always the first person to get up and congratulate them and just get the ball rolling on following up on the things they talked about. Is that something that you really enjoy doing or find particularly valuable as an audience member or speaker? +JOËL: Yes, both. I think, as a speaker, it's really validating to have people come up to you after the talk and either just tell you they liked the talk or ask a question. I generally don't like to do just open questions after a talk from the audience because then you get the classic; this is more of a comment than a question or people who will tell you that you had a typo on one of your code slides. Like, none of that is useful to anyone. +So, if you're really interested, come talk to me afterwards. And then that actually makes me feel like my talk connected with people, and people were paying attention, people enjoyed it, people were learning. So I try to pay that forward as well for talks that I listened to, go up to the speaker, and tell them one thing that I appreciated about the talk or a thing that I learned, or something that got me excited in their content. +STEPHANIE: Yeah, I'm sure that it's very appreciated. And it also breaks the awkward silence at the end when the speaker finishes and people aren't sure if it's okay for them to get up and start moving around. Yeah, I thought that was a really good way to kind of just encourage people to start chatting with each other and moving into those break times that we mentioned earlier, those opportunities to socialize. +JOËL: Another thing that I think is really fun that you can do at in-person conferences, and I know you were doing it a lot, is going to see the talks of friends and colleagues and sitting in the front row and just being there to cheer them on and encourage them. Again, I think that makes a big difference when you are on stage, and you see these people who are your friends and colleagues there to support you. It gives you that boost of confidence. And when you're there in the audience, it's fun to cheer on somebody else. +STEPHANIE: Oh yeah. You gave me a lot of thumbs-ups during my talk, and I really appreciated that. [laughs] So I'm curious if there were any talks that stood out to you that you got to see. +JOËL: And I was really inspired by your talk, pair programming. I think there are a lot of things that I can take from that to improve the way I pair. I was also inspired by Aji's talk, Aji Slater, on automating manual tasks that you have to do in an iterative way. That one really hit home because, on my current project, I have been doing a lot of manual things. And I just have random snippets of code, like, some shell script lines or Ruby console lines, that I copy-paste out of Slack conversations because I've shared them with other people who are doing similar work. +And I realized that a lot of his advice would apply to the work that I'm doing and how that could really make things better. So that was one of those talks I was listening to, and I was like, oh, you know what? Monday morning, when I go back to my project, this is something that I'm going to start doing. This is something I'm going to change in the way I do my day-to-day work. +STEPHANIE: Yeah, absolutely. I have so many tasks that I would like to get automated, and think that one day I will magically have more time in my schedule to get to it. But I liked that his talk gave pretty concrete strategies for baking it into your regular, like you said, day-to-day workflow, and that lowers the activation energy to getting them done. And then those things can be iterated on and could eventually become, in an ideal world, a fully-fledged feature that you put together from doing those repetitive tasks. And yeah, they provide a lot of value not just to you but can eventually provide value to your co-workers and then even your users in the future. +JOËL: Were there any talks that stood out for you? +STEPHANIE: One talk that I really enjoyed was Jenny Shih's about Functional Programming for Fun and Profit. I have attended a lot of functional programming talks within the Ruby realm, at least to try to get a better sense of how it can apply to my work and the languages and paradigms that I use. And honestly, what I liked about it was that it didn't get too in the weeds about functional programming. What she did was provide mental models for understanding the paradigm that I think was a good vehicle for understanding things very generally. +And, for me, like,¬¬ a talk, it's really hard to pay attention to lines of code and to read code on the fly while people are presenting. For me, that is just not how I like to consume that information. And so she provided themes and, like I said, those mental models, which I know you really like to use a lot too in teaching people new concepts. For me, I didn't fully learn what a monad was, once again, but at least having that repeated exposure to those foundational aspects, I think, will eventually lead me to be able to grok those things a little more comprehensively the next time I see it or whenever I decide to dig deeper. +JOËL: What was a mental model that was shared that connected with you particularly? +STEPHANIE: So one of the main mental models that she shared was thinking about a program in terms of these three dimensions: value, behavior, and time. She had a nice slide that showed the difference between the object-oriented paradigm, where value and behavior are contained by objects, where time is kind of inherently wrapped up in those objects that hold information about the state through values and behavior. Whereas in her functional programming example, those three dimensions were a bit separate. And I found that distinction to be really helpful in separating things that felt very implicit before, but it was nice to see them broken out into very clear concepts in terms of building blocks of a program. +JOËL: So it's helpful then when thinking...when you look at code, if you can think about it in those three different dimensions to help think about, am I taking a functional or other approach in this particular dimension when working with this code? +STEPHANIE: Yeah, exactly. I think it also gave me more of a vocabulary to describe the pros and cons of each and a lens of thinking about which I might want to choose for the particular problem at hand. +JOËL: So you mentioned there's a visual for these three dimensions from the slides. Are those slides publicly available? +STEPHANIE: They are. I will link to them in the show notes. +JOËL: So all of these talks were recorded. They're not yet available to the public, but I think the plan is to publish them on YouTube sometime in the new year, so that means probably January 2023. And a big shout out to the AV team and everyone who is involved in recording these. +STEPHANIE: Yeah, I am definitely looking out for a link to my talk so I can send it to my mom. I also wanted to give a little shout-out to the organizers of RubyConf Mini: Jemma Issroff, Emily Samp, and Andy Croll. +JOËL: Woo! +STEPHANIE: They put on just a really awesome conference, and I feel very grateful that I got a chance to attend with you, Joël. +JOËL: It was definitely a delightful experience. +STEPHANIE: Delightful. That's a reference to Joël's talk for those of you who are listening. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: Coming back from the conference, I recently had a really interesting conversation with some other colleagues at thoughtbot. We were looking at a database schema for a new application and talking about some of the trade-offs involved in how that schema is structured, so what tables we want to have. Do we want to have indexes? Things like that. And particularly around some of the assumptions are business rules that would come into play. +So we're looking at...we'd drawn out this Entity Relationship Diagram (ERD). In it, we're looking at all the tables, and something that comes up immediately is like, oh, it's possible to have some bad data that could show up in these columns. Or it's possible that this relationship could exist where this table has a foreign key on this table, but really, that should never happen in this particular way of working. +And so then the question became, how do we try to prevent these things that currently the schema allows but that are not valid in this particular business domain? Do we want to change the schema somehow and make that stricter or find some way to prevent it? Do we want to add some kind of validation that will check some business rules first before inserting or updating a record? I'm curious, have you ever been in a situation like that where you had to balance those two approaches to enforcing business rules on your database? +A classic small example of this is a situation where let's say, you have a users' table and you have a name column on there. And you want to ensure that that name must always be present; all users must have names. Do you try to enforce that via the schema with a NOT NULL constraint? Or maybe you try to enforce that with a validation, maybe a presence validation at the Rails level. +Or if you're really into SQL, maybe some fancy trigger, but do it in a validation style rather than trying to force this using the schema. And our particular scenario was a little bit more complex than just one column; it was more to do with associations. But I think this sort of problem shows up even in constraints as small as a required field. +STEPHANIE: That's really interesting. I think that, in my experience, when we are spinning up new tables, at that point, we do try to put some intentional thought into what the schema should look like and what requirements we might need to encode at the database level. But things that are more complex might need a little more code, like Ruby code. I have then pushed to an ActiveRecord validation. +One thing that I think is important to know is that when you do set those things on the schema, it's harder to change. And so you usually have to feel pretty confident that that's what you want. Otherwise, you'll run into issues later if that does have to change and making changes to whatever existing data you might have. But it's also pretty common to just do your best when you are deciding on a database schema and then having to make adjustments down the line as you know more about your domain. +JOËL: This conversation reminds me a little bit of the idea of database normalization. I think that might almost fit as a subset of general tactics of using the schema to ensure your data is more correct. When you are generating new tables, let's say you're creating a greenfield app and you need to create four or five tables; how much emphasis do you put on database normalization when you're initially designing those? +STEPHANIE: I think for a greenfield project when you are setting everything up and creating tables for your main domain models, there is an aspect of it that should be considered because you're in this unique position where nothing really is in existence yet. And you do want to try to set yourself up to be successful and hopefully have information about your main use case for this app and can kind of make decisions about the schema then. +At least in my experience, that has been part of the conversation, though, to be fair, because it's so early, you do have the opportunity to change things without as much effort or pain. But I think it's worth considering when you're just sitting down and working through what those models are going to look like. +JOËL: And for our listeners who may not have heard the term normalization before, it's a series of...you can think of them as rules that you apply to your database design to try to avoid data redundancies in your tables. There are different levels of this; they're typically referred to as normal forms. So you'll see things like first normal form, second normal form, third normal form; those are kind of the fancy terms for them. +But they generally involve breaking out other tables so that you don't have data redundancies. And in many ways, this is similar to principles such as the single-responsibility principle that we apply to objects when we're designing our objects in an OO system. But this is more at the table level for databases. +STEPHANIE: I do think that it is so hard, maybe even impossible, to plan something out, to not have any of those redundancies, to begin with. And I do think sometimes they are a bit inevitable. But I also have had the experience of having to figure out what the heck I'm looking at when I am querying data and see all these things that are duplicated or maybe slightly different. +And yeah, I think when you are in that position of starting a greenfield application, it is really interesting to see how you make those decisions about what needs to be enforced and where. Where did you end up landing, or what did you discuss in this conversation with the co-worker? +JOËL: I think we went with a bit of a hybrid approach. Some things, we can use the schema to prevent bad data, and then some things either cannot be represented with a schema, or it's possible, but it's really cumbersome and painful. And so, we chose to try to enforce it with a validation. To me, this feels very similar to a problem in typed languages. +So some communities that use a lot of types try to use those types to only allow data to come through that's in a valid shape. And so you'll hear things like make impossible states impossible or make illegal states unrepresentable. And that works for many things, but it's not always possible to enforce all of your business constraints through a schema. Or sometimes it's possible but just not practical. And so, I think there is a balance of finding when you can use the schema or when it's better to use the validation.¬ +STEPHANIE: Yeah, I think my general rule of thumb is, like I mentioned earlier, things I feel really confident about that we want to make sure that we have in our database or in our data for sure. I do lean towards requiring those in a schema, and it also communicates that confidence or communicates that intent that it's something that at one point was decided is important. And so, if a future developer comes in, it would take a lot of work for them to write a migration, to remove some database constraint. Whereas I think sometimes validations at the Rails level are potentially a little more open to change and then even more so if you get to validating on the client side. +JOËL: That can get to be a really, like, it's a useful tool, but one that you can really hurt yourself with. If you modify your validations at the Rails level or at the front-end level, but then you don't backfill those changes on your data in the database, then you might have records in your database that if you were to load them into memory and hit save on them again, would refuse to save because they no longer match the validations. And on longer-lived applications, I've seen that happen sometimes where not all rows in the database pass the Rails validations. +STEPHANIE: Yeah, I think I've seen that be a problem either for developers who then have to backfill that data or write some migration to change some of the data to meet the new requirements, or just unexpected bugs on the users who discover something new but like you said, have been there long enough before those things were implemented. +JOËL: The more I think of this, I think maybe constraints that are enforced at a validation level might still require changing the data in your database. So if you had a constraint enforced via a schema, you don't have a choice. You have to write some way to migrate that data so that it fits the new schema. You can kind of lie to yourself with validation and not change the historic data, and sometimes that is the case; you want to keep the old data and only prevent new data from being written in the old format. But if you need consistency, then you probably need a data migration regardless of which approach you take. +STEPHANIE: Yeah, that definitely sounds like the more robust way to go about it for sure. +JOËL: I have an article that I like to reference a lot by Hillel Wayne on Constructive Versus Predicative Data, which is basically looking at these two general approaches to enforcing data correctness and formalizing them a little bit. So do you try to enforce them based on the construction or the shape of the entity that you're creating, be that a database table, an object, a type, something like that? Or do you enforce it via some kind of predicate? So that could be a validation or other similar logic that runs kind of at runtime to enforce your constraints. +STEPHANIE: That's interesting. I hadn't heard of those terms before, but I think they provide a lens through which you can look at the problem. Did the article end up suggesting different strategies for solving that problem, or was it more theoretical in different ways to look at it? +JOËL: I think the article does two things. First, like you said, it gives us the words to talk about those approaches. And having those labels now, I start seeing them everywhere. I see them in databases, I see them in objects, I see them when doing types across a variety of languages. So that's already a huge win for me. I think you and I had done an episode a couple of months back where we talked about the value of having labels to put to ideas. And I think for me reading that article gave me those two labels. And all of a sudden, it really helped to make connections that I wasn't seeing before. +The second thing that the article does is, I think, explore some of the limitations that each approach has and when you might want to use one versus another. The constructive approach, so using a schema, is more consistent because you know it is impossible for the program to create data that's in the wrong shape. That being said, not all constraints can be represented in a constructive manner, or it might be possible but really cumbersome. +Also, sometimes it's not really invalid data; it's just sort of undesirable data. So you might want a looser schema. And let's say that you're storing some kind of intermediate state or some kind of raw input from another system that you might want to layer validations on top of, but you don't want to reject that data out of your database. You want that sort of incomplete or imperfect data in your system. +Something that I find myself doing more and more these days when I create new tables is to really lock down the schema as much as possible. I think that might be contrary to maybe the way a lot of people in the community like to work. Some people might prefer to start with a very loose schema with no constraints and then work towards making things stricter as they explore the domain, and that's kind of the default that Rails has. If you're creating a new table, all columns, for example, are nullable by default. +Personally, I will put a null false on every column and every migration that I make unless somebody can make a convincing case otherwise, and even then, I might try to think of is there any possible way that we could avoid that scenario and put that null false. Part of the reason for that is that it is much easier to loosen constraints on existing data than to tighten them afterwards. So if I have a column where no value is allowed to be null, and then later on we decide, you know what? It is okay for some of them to be null, I can change the requirement on that column, and I don't need to make any changes to the existing data. It just works. +If the reverse happens, if I have a column that allows a bunch of nulls and then I want to make that column required, now I have to go and find a way to backfill all the empty spots in that column. And that could be a very challenging process. It might even be impossible. There might be some values there that it's just like, the user did not supply them at the time because we didn't ask for them. And now there's nothing we can put in there. So do you put in, like, unknown or not available? Then you have to ask yourself some really difficult questions about your data. +STEPHANIE: Yeah, absolutely. I think I agree with you there. Another thing I like to do is provide default values for columns, especially ones where they can't be null, because, like you were saying, that helps me have a better understanding of just what is going on in the database. +An issue I have seen come up involves a Boolean column where if a default value of false, for example, if that's what we're going with, is not encoded in the schema, you end up with potentially three values for a Boolean, which would be true, false, and null, and that I think has been -- +JOËL: The infamous three-state Boolean. +STEPHANIE: Yeah, exactly, the three-state problem, which is just inherently contradictory to what a Boolean is, to begin with. And I've definitely run into issues with that where you have to decide, or figure out, or write code to determine is null false? Is that what we mean here? It's not clear. But if you, like you said, locked it down at the beginning, provided those default values, that puts in those guardrails to prevent things from getting out of hand. +JOËL: It also makes it easier for users of your database, application, whatever to interact with your code. I've run into this a lot when working with GraphQL APIs. And the default in many GraphQL server implementations is to make all fields nullable by default. When you build your schema, you have to add some extra things there to say, "This field is non-nullable," which means that a client that's now consuming it, anytime they deal with the data they need to check, is it present or not? You can't have the confidence that that data is there. And so it can force a lot of extra checks on the client. Or I guess you could just take it on faith and hope nothing breaks. +STEPHANIE: Yeah, it's funny you mention that because I definitely think there's like spheres of impact. So as a developer, you maybe start having to write code that checks those kinds of things, like if it's null or not in your code. Then that can even extend to, like you said, your users or consumers of the API, who then have to contend with data that they have no control over. And I've been there too, and that can be frustrating as well. +JOËL: We've talked a lot about data correctness and different ways to achieve it, different strategies. Why is this something that we care so much about? +STEPHANIE: I think data correctness is really important from a developer experience perspective. And it's way easier to fix a bug in your code than it is to wrangle a lot of accumulated bad data. +JOËL: Yeah, sometimes bad data is not fixable at all, and those are situations where you have a really bad day as a developer. +STEPHANIE: Agreed. +JOËL: Well, on that note, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Stephanie and Joël attended RubyConf Mini, and both spoke there. They discuss takeaways and highlights from the conference.

+ +

The core idea for this episode is explained in this article: Constructive vs. Predicative Data. This came up recently in a conversation at thoughtbot about designing a database schema and what constraints could be encoded in the schema directly versus needing some kind of trigger or Rails validation to cover it.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

RubyConf Mini
+Episode on CFP - The Bike Shed 352: Case Expressions
+Podcast panel: The Ruby on Rails Podcast Episode 446: I'm Giving A Talk on Thursday
+Slides for FP talk: Functional Programming for Fun and Profit!!
+Episode on language: The Bike Shed - 356: The Value of Specialized Vocabulary
+Constructive vs. Predicative data
+Avoid the Three-state Boolean Problem

+ +

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 something that's very recent in both of our worlds has been that both you and I, Stephanie, attended RubyConf Mini, and we both spoke there. What are some of your takeaways or highlights from the conference?

+ +

STEPHANIE: Seeing you in person was definitely a highlight. I really enjoyed that. Because we're working remotely, I don't, you know, get to be in an office with you day to day. And it was really awesome to hang out with you, I think, for the first time as co-hosts of the podcast. And we both, I think, met some people at the conference too that were listeners. And it was really awesome to share that experience with you.

+ +

JOËL: I had the interesting experience of several people who told me they recognized me by my voice, which I think is a common thing for podcasters, but as a new host, I was surprised by that.

+ +

STEPHANIE: Yeah, that's weird. As a podcast listener, too, I definitely know exactly what you're talking about where it's like, oh yeah, I can identify someone by their voice. But to then be that person that people can recognize is pretty weird.

+ +

I also really enjoyed being an audience member of the podcast panel that you are on at the conference with other podcast folks. It was moderated by Brittany Martin. And yeah, I just thought you represented The Bike Shed really well and spoke for both of us about podcasting in a way that I really appreciated.

+ +

JOËL: And for any of our listeners who were not able to be there in person, Brittany has published that episode as a podcast, and we will link to it in the show notes.

+ +

STEPHANIE: Another thing I really liked about RubyConf Mini was the smaller scale. I think it was about 150 or so attendees, which felt very different from traditional Ruby Central conferences with several hundreds of people. I heard a lot from other folks there that they really liked the regional aspect of it, the intimacy of the smaller conference.

+ +

I think I got more of an opportunity to run into people that I'd met at the conference over the next few days. And there was, yeah, definitely a sense of tighter knit community there, you know, when you meet someone, and then you bump into them on the way into a talk, and then you can ask how their day was going and any highlights that they had. And yeah, I guess I haven't really attended a conference that size before, and so that felt like a very special experience for me.

+ +

JOËL: I 100% agree. I think the smaller format definitely makes it a little bit more intimate, makes it much easier, I think, to build some of those social connections, to meet with people, and to have some good conversations. I think the format of the conference as well favored that. There were, I think, larger breaks between talks that encouraged people to hang out and talk. And, as you said, because it's smaller, you also get to see the same people over the course of a few different breaks instead of being like, oh, I met a stranger on the morning of day one, and then in the afternoon, I met another stranger. And it's just constantly introducing yourself.

+ +

One thing that was really interesting to me is the experience of being a speaker is very different than just attending. As a speaker, you get to go to the speaker dinner and connect with a lot of the other speakers there. Some of them might be quote, unquote "famous people" that you're not quite comfortable just walking up to and introducing yourself. But in the smaller dinner, you just find yourself sitting next to them and enjoying some food or a drink and getting conversations.

+ +

It's also much easier to have people come up to you during the conference. Because you're a speaker, people will come and talk to you. So if you tend to be a little bit more introverted, as long as you can get over your fear of being on stage and public speaking, it actually makes social connection interaction much easier to be a speaker. I would recommend to any of our listeners who were wondering how can I get more out of a conference? How can I get better connections, better conversations? Consider being a speaker.

+ +

STEPHANIE: Yeah, absolutely. We've talked about this before; I think when we chatted about writing our CFPs for this conference that speaking doesn't have to be a really big, scary thing, but everyone has something to say. I think we had mentioned in previous episodes that your talk topic came out of just a discussion that you had internally, and you were like, wow, enumerables are so cool, like, let me dig deeper into them and just share what I learned. So I totally recommend it.

+ +

And this conference was my first in real-life speaking opportunity as well, and that felt super different from my experience last time doing it virtually, you know, talking about how much I love that sense of community all the time. But it really felt true for me this time around, where I could see the audience react to the things I was saying, like, maybe go off the cuff a little bit.

+ +

And then yeah, at the end, having people come up to me was really awesome to just talk about pairing, which is what I spoke about, and just share our experiences. And they asked what I thought about some things, and it was really cool to just be able to spread that knowledge around. And one thing I noticed you did a lot was come up to speakers after they wrapped up their talks. You were almost always the first person to get up and congratulate them and just get the ball rolling on following up on the things they talked about. Is that something that you really enjoy doing or find particularly valuable as an audience member or speaker?

+ +

JOËL: Yes, both. I think, as a speaker, it's really validating to have people come up to you after the talk and either just tell you they liked the talk or ask a question. I generally don't like to do just open questions after a talk from the audience because then you get the classic; this is more of a comment than a question or people who will tell you that you had a typo on one of your code slides. Like, none of that is useful to anyone.

+ +

So, if you're really interested, come talk to me afterwards. And then that actually makes me feel like my talk connected with people, and people were paying attention, people enjoyed it, people were learning. So I try to pay that forward as well for talks that I listened to, go up to the speaker, and tell them one thing that I appreciated about the talk or a thing that I learned, or something that got me excited in their content.

+ +

STEPHANIE: Yeah, I'm sure that it's very appreciated. And it also breaks the awkward silence at the end when the speaker finishes and people aren't sure if it's okay for them to get up and start moving around. Yeah, I thought that was a really good way to kind of just encourage people to start chatting with each other and moving into those break times that we mentioned earlier, those opportunities to socialize.

+ +

JOËL: Another thing that I think is really fun that you can do at in-person conferences, and I know you were doing it a lot, is going to see the talks of friends and colleagues and sitting in the front row and just being there to cheer them on and encourage them. Again, I think that makes a big difference when you are on stage, and you see these people who are your friends and colleagues there to support you. It gives you that boost of confidence. And when you're there in the audience, it's fun to cheer on somebody else.

+ +

STEPHANIE: Oh yeah. You gave me a lot of thumbs-ups during my talk, and I really appreciated that. [laughs] So I'm curious if there were any talks that stood out to you that you got to see.

+ +

JOËL: And I was really inspired by your talk, pair programming. I think there are a lot of things that I can take from that to improve the way I pair. I was also inspired by Aji's talk, Aji Slater, on automating manual tasks that you have to do in an iterative way. That one really hit home because, on my current project, I have been doing a lot of manual things. And I just have random snippets of code, like, some shell script lines or Ruby console lines, that I copy-paste out of Slack conversations because I've shared them with other people who are doing similar work.

+ +

And I realized that a lot of his advice would apply to the work that I'm doing and how that could really make things better. So that was one of those talks I was listening to, and I was like, oh, you know what? Monday morning, when I go back to my project, this is something that I'm going to start doing. This is something I'm going to change in the way I do my day-to-day work.

+ +

STEPHANIE: Yeah, absolutely. I have so many tasks that I would like to get automated, and think that one day I will magically have more time in my schedule to get to it. But I liked that his talk gave pretty concrete strategies for baking it into your regular, like you said, day-to-day workflow, and that lowers the activation energy to getting them done. And then those things can be iterated on and could eventually become, in an ideal world, a fully-fledged feature that you put together from doing those repetitive tasks. And yeah, they provide a lot of value not just to you but can eventually provide value to your co-workers and then even your users in the future.

+ +

JOËL: Were there any talks that stood out for you?

+ +

STEPHANIE: One talk that I really enjoyed was Jenny Shih's about Functional Programming for Fun and Profit. I have attended a lot of functional programming talks within the Ruby realm, at least to try to get a better sense of how it can apply to my work and the languages and paradigms that I use. And honestly, what I liked about it was that it didn't get too in the weeds about functional programming. What she did was provide mental models for understanding the paradigm that I think was a good vehicle for understanding things very generally.

+ +

And, for me, like,¬¬ a talk, it's really hard to pay attention to lines of code and to read code on the fly while people are presenting. For me, that is just not how I like to consume that information. And so she provided themes and, like I said, those mental models, which I know you really like to use a lot too in teaching people new concepts. For me, I didn't fully learn what a monad was, once again, but at least having that repeated exposure to those foundational aspects, I think, will eventually lead me to be able to grok those things a little more comprehensively the next time I see it or whenever I decide to dig deeper.

+ +

JOËL: What was a mental model that was shared that connected with you particularly?

+ +

STEPHANIE: So one of the main mental models that she shared was thinking about a program in terms of these three dimensions: value, behavior, and time. She had a nice slide that showed the difference between the object-oriented paradigm, where value and behavior are contained by objects, where time is kind of inherently wrapped up in those objects that hold information about the state through values and behavior. Whereas in her functional programming example, those three dimensions were a bit separate. And I found that distinction to be really helpful in separating things that felt very implicit before, but it was nice to see them broken out into very clear concepts in terms of building blocks of a program.

+ +

JOËL: So it's helpful then when thinking...when you look at code, if you can think about it in those three different dimensions to help think about, am I taking a functional or other approach in this particular dimension when working with this code?

+ +

STEPHANIE: Yeah, exactly. I think it also gave me more of a vocabulary to describe the pros and cons of each and a lens of thinking about which I might want to choose for the particular problem at hand.

+ +

JOËL: So you mentioned there's a visual for these three dimensions from the slides. Are those slides publicly available?

+ +

STEPHANIE: They are. I will link to them in the show notes.

+ +

JOËL: So all of these talks were recorded. They're not yet available to the public, but I think the plan is to publish them on YouTube sometime in the new year, so that means probably January 2023. And a big shout out to the AV team and everyone who is involved in recording these.

+ +

STEPHANIE: Yeah, I am definitely looking out for a link to my talk so I can send it to my mom. I also wanted to give a little shout-out to the organizers of RubyConf Mini: Jemma Issroff, Emily Samp, and Andy Croll.

+ +

JOËL: Woo!

+ +

STEPHANIE: They put on just a really awesome conference, and I feel very grateful that I got a chance to attend with you, Joël.

+ +

JOËL: It was definitely a delightful experience.

+ +

STEPHANIE: Delightful. That's a reference to Joël's talk for those of you who are listening.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: Coming back from the conference, I recently had a really interesting conversation with some other colleagues at thoughtbot. We were looking at a database schema for a new application and talking about some of the trade-offs involved in how that schema is structured, so what tables we want to have. Do we want to have indexes? Things like that. And particularly around some of the assumptions are business rules that would come into play.

+ +

So we're looking at...we'd drawn out this Entity Relationship Diagram (ERD). In it, we're looking at all the tables, and something that comes up immediately is like, oh, it's possible to have some bad data that could show up in these columns. Or it's possible that this relationship could exist where this table has a foreign key on this table, but really, that should never happen in this particular way of working.

+ +

And so then the question became, how do we try to prevent these things that currently the schema allows but that are not valid in this particular business domain? Do we want to change the schema somehow and make that stricter or find some way to prevent it? Do we want to add some kind of validation that will check some business rules first before inserting or updating a record? I'm curious, have you ever been in a situation like that where you had to balance those two approaches to enforcing business rules on your database?

+ +

A classic small example of this is a situation where let's say, you have a users' table and you have a name column on there. And you want to ensure that that name must always be present; all users must have names. Do you try to enforce that via the schema with a NOT NULL constraint? Or maybe you try to enforce that with a validation, maybe a presence validation at the Rails level.

+ +

Or if you're really into SQL, maybe some fancy trigger, but do it in a validation style rather than trying to force this using the schema. And our particular scenario was a little bit more complex than just one column; it was more to do with associations. But I think this sort of problem shows up even in constraints as small as a required field.

+ +

STEPHANIE: That's really interesting. I think that, in my experience, when we are spinning up new tables, at that point, we do try to put some intentional thought into what the schema should look like and what requirements we might need to encode at the database level. But things that are more complex might need a little more code, like Ruby code. I have then pushed to an ActiveRecord validation.

+ +

One thing that I think is important to know is that when you do set those things on the schema, it's harder to change. And so you usually have to feel pretty confident that that's what you want. Otherwise, you'll run into issues later if that does have to change and making changes to whatever existing data you might have. But it's also pretty common to just do your best when you are deciding on a database schema and then having to make adjustments down the line as you know more about your domain.

+ +

JOËL: This conversation reminds me a little bit of the idea of database normalization. I think that might almost fit as a subset of general tactics of using the schema to ensure your data is more correct. When you are generating new tables, let's say you're creating a greenfield app and you need to create four or five tables; how much emphasis do you put on database normalization when you're initially designing those?

+ +

STEPHANIE: I think for a greenfield project when you are setting everything up and creating tables for your main domain models, there is an aspect of it that should be considered because you're in this unique position where nothing really is in existence yet. And you do want to try to set yourself up to be successful and hopefully have information about your main use case for this app and can kind of make decisions about the schema then.

+ +

At least in my experience, that has been part of the conversation, though, to be fair, because it's so early, you do have the opportunity to change things without as much effort or pain. But I think it's worth considering when you're just sitting down and working through what those models are going to look like.

+ +

JOËL: And for our listeners who may not have heard the term normalization before, it's a series of...you can think of them as rules that you apply to your database design to try to avoid data redundancies in your tables. There are different levels of this; they're typically referred to as normal forms. So you'll see things like first normal form, second normal form, third normal form; those are kind of the fancy terms for them.

+ +

But they generally involve breaking out other tables so that you don't have data redundancies. And in many ways, this is similar to principles such as the single-responsibility principle that we apply to objects when we're designing our objects in an OO system. But this is more at the table level for databases.

+ +

STEPHANIE: I do think that it is so hard, maybe even impossible, to plan something out, to not have any of those redundancies, to begin with. And I do think sometimes they are a bit inevitable. But I also have had the experience of having to figure out what the heck I'm looking at when I am querying data and see all these things that are duplicated or maybe slightly different.

+ +

And yeah, I think when you are in that position of starting a greenfield application, it is really interesting to see how you make those decisions about what needs to be enforced and where. Where did you end up landing, or what did you discuss in this conversation with the co-worker?

+ +

JOËL: I think we went with a bit of a hybrid approach. Some things, we can use the schema to prevent bad data, and then some things either cannot be represented with a schema, or it's possible, but it's really cumbersome and painful. And so, we chose to try to enforce it with a validation. To me, this feels very similar to a problem in typed languages.

+ +

So some communities that use a lot of types try to use those types to only allow data to come through that's in a valid shape. And so you'll hear things like make impossible states impossible or make illegal states unrepresentable. And that works for many things, but it's not always possible to enforce all of your business constraints through a schema. Or sometimes it's possible but just not practical. And so, I think there is a balance of finding when you can use the schema or when it's better to use the validation.¬

+ +

STEPHANIE: Yeah, I think my general rule of thumb is, like I mentioned earlier, things I feel really confident about that we want to make sure that we have in our database or in our data for sure. I do lean towards requiring those in a schema, and it also communicates that confidence or communicates that intent that it's something that at one point was decided is important. And so, if a future developer comes in, it would take a lot of work for them to write a migration, to remove some database constraint. Whereas I think sometimes validations at the Rails level are potentially a little more open to change and then even more so if you get to validating on the client side.

+ +

JOËL: That can get to be a really, like, it's a useful tool, but one that you can really hurt yourself with. If you modify your validations at the Rails level or at the front-end level, but then you don't backfill those changes on your data in the database, then you might have records in your database that if you were to load them into memory and hit save on them again, would refuse to save because they no longer match the validations. And on longer-lived applications, I've seen that happen sometimes where not all rows in the database pass the Rails validations.

+ +

STEPHANIE: Yeah, I think I've seen that be a problem either for developers who then have to backfill that data or write some migration to change some of the data to meet the new requirements, or just unexpected bugs on the users who discover something new but like you said, have been there long enough before those things were implemented.

+ +

JOËL: The more I think of this, I think maybe constraints that are enforced at a validation level might still require changing the data in your database. So if you had a constraint enforced via a schema, you don't have a choice. You have to write some way to migrate that data so that it fits the new schema. You can kind of lie to yourself with validation and not change the historic data, and sometimes that is the case; you want to keep the old data and only prevent new data from being written in the old format. But if you need consistency, then you probably need a data migration regardless of which approach you take.

+ +

STEPHANIE: Yeah, that definitely sounds like the more robust way to go about it for sure.

+ +

JOËL: I have an article that I like to reference a lot by Hillel Wayne on Constructive Versus Predicative Data, which is basically looking at these two general approaches to enforcing data correctness and formalizing them a little bit. So do you try to enforce them based on the construction or the shape of the entity that you're creating, be that a database table, an object, a type, something like that? Or do you enforce it via some kind of predicate? So that could be a validation or other similar logic that runs kind of at runtime to enforce your constraints.

+ +

STEPHANIE: That's interesting. I hadn't heard of those terms before, but I think they provide a lens through which you can look at the problem. Did the article end up suggesting different strategies for solving that problem, or was it more theoretical in different ways to look at it?

+ +

JOËL: I think the article does two things. First, like you said, it gives us the words to talk about those approaches. And having those labels now, I start seeing them everywhere. I see them in databases, I see them in objects, I see them when doing types across a variety of languages. So that's already a huge win for me. I think you and I had done an episode a couple of months back where we talked about the value of having labels to put to ideas. And I think for me reading that article gave me those two labels. And all of a sudden, it really helped to make connections that I wasn't seeing before.

+ +

The second thing that the article does is, I think, explore some of the limitations that each approach has and when you might want to use one versus another. The constructive approach, so using a schema, is more consistent because you know it is impossible for the program to create data that's in the wrong shape. That being said, not all constraints can be represented in a constructive manner, or it might be possible but really cumbersome.

+ +

Also, sometimes it's not really invalid data; it's just sort of undesirable data. So you might want a looser schema. And let's say that you're storing some kind of intermediate state or some kind of raw input from another system that you might want to layer validations on top of, but you don't want to reject that data out of your database. You want that sort of incomplete or imperfect data in your system.

+ +

Something that I find myself doing more and more these days when I create new tables is to really lock down the schema as much as possible. I think that might be contrary to maybe the way a lot of people in the community like to work. Some people might prefer to start with a very loose schema with no constraints and then work towards making things stricter as they explore the domain, and that's kind of the default that Rails has. If you're creating a new table, all columns, for example, are nullable by default.

+ +

Personally, I will put a null false on every column and every migration that I make unless somebody can make a convincing case otherwise, and even then, I might try to think of is there any possible way that we could avoid that scenario and put that null false. Part of the reason for that is that it is much easier to loosen constraints on existing data than to tighten them afterwards. So if I have a column where no value is allowed to be null, and then later on we decide, you know what? It is okay for some of them to be null, I can change the requirement on that column, and I don't need to make any changes to the existing data. It just works.

+ +

If the reverse happens, if I have a column that allows a bunch of nulls and then I want to make that column required, now I have to go and find a way to backfill all the empty spots in that column. And that could be a very challenging process. It might even be impossible. There might be some values there that it's just like, the user did not supply them at the time because we didn't ask for them. And now there's nothing we can put in there. So do you put in, like, unknown or not available? Then you have to ask yourself some really difficult questions about your data.

+ +

STEPHANIE: Yeah, absolutely. I think I agree with you there. Another thing I like to do is provide default values for columns, especially ones where they can't be null, because, like you were saying, that helps me have a better understanding of just what is going on in the database.

+ +

An issue I have seen come up involves a Boolean column where if a default value of false, for example, if that's what we're going with, is not encoded in the schema, you end up with potentially three values for a Boolean, which would be true, false, and null, and that I think has been --

+ +

JOËL: The infamous three-state Boolean.

+ +

STEPHANIE: Yeah, exactly, the three-state problem, which is just inherently contradictory to what a Boolean is, to begin with. And I've definitely run into issues with that where you have to decide, or figure out, or write code to determine is null false? Is that what we mean here? It's not clear. But if you, like you said, locked it down at the beginning, provided those default values, that puts in those guardrails to prevent things from getting out of hand.

+ +

JOËL: It also makes it easier for users of your database, application, whatever to interact with your code. I've run into this a lot when working with GraphQL APIs. And the default in many GraphQL server implementations is to make all fields nullable by default. When you build your schema, you have to add some extra things there to say, "This field is non-nullable," which means that a client that's now consuming it, anytime they deal with the data they need to check, is it present or not? You can't have the confidence that that data is there. And so it can force a lot of extra checks on the client. Or I guess you could just take it on faith and hope nothing breaks.

+ +

STEPHANIE: Yeah, it's funny you mention that because I definitely think there's like spheres of impact. So as a developer, you maybe start having to write code that checks those kinds of things, like if it's null or not in your code. Then that can even extend to, like you said, your users or consumers of the API, who then have to contend with data that they have no control over. And I've been there too, and that can be frustrating as well.

+ +

JOËL: We've talked a lot about data correctness and different ways to achieve it, different strategies. Why is this something that we care so much about?

+ +

STEPHANIE: I think data correctness is really important from a developer experience perspective. And it's way easier to fix a bug in your code than it is to wrangle a lot of accumulated bad data.

+ +

JOËL: Yeah, sometimes bad data is not fixable at all, and those are situations where you have a really bad day as a developer.

+ +

STEPHANIE: Agreed.

+ +

JOËL: Well, on that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Stephanie and Joël attended RubyConf Mini, and both spoke there. They discuss takeaways and highlights from the conference.

+ +

The core idea for this episode is explained in this article: Constructive vs. Predicative Data. This came up recently in a conversation at thoughtbot about designing a database schema and what constraints could be encoded in the schema directly versus needing some kind of trigger or Rails validation to cover it.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

RubyConf Mini
+Episode on CFP - The Bike Shed 352: Case Expressions
+Podcast panel: The Ruby on Rails Podcast Episode 446: I'm Giving A Talk on Thursday
+Slides for FP talk: Functional Programming for Fun and Profit!!
+Episode on language: The Bike Shed - 356: The Value of Specialized Vocabulary
+Constructive vs. Predicative data
+Avoid the Three-state Boolean Problem

+ +

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 something that's very recent in both of our worlds has been that both you and I, Stephanie, attended RubyConf Mini, and we both spoke there. What are some of your takeaways or highlights from the conference?

+ +

STEPHANIE: Seeing you in person was definitely a highlight. I really enjoyed that. Because we're working remotely, I don't, you know, get to be in an office with you day to day. And it was really awesome to hang out with you, I think, for the first time as co-hosts of the podcast. And we both, I think, met some people at the conference too that were listeners. And it was really awesome to share that experience with you.

+ +

JOËL: I had the interesting experience of several people who told me they recognized me by my voice, which I think is a common thing for podcasters, but as a new host, I was surprised by that.

+ +

STEPHANIE: Yeah, that's weird. As a podcast listener, too, I definitely know exactly what you're talking about where it's like, oh yeah, I can identify someone by their voice. But to then be that person that people can recognize is pretty weird.

+ +

I also really enjoyed being an audience member of the podcast panel that you are on at the conference with other podcast folks. It was moderated by Brittany Martin. And yeah, I just thought you represented The Bike Shed really well and spoke for both of us about podcasting in a way that I really appreciated.

+ +

JOËL: And for any of our listeners who were not able to be there in person, Brittany has published that episode as a podcast, and we will link to it in the show notes.

+ +

STEPHANIE: Another thing I really liked about RubyConf Mini was the smaller scale. I think it was about 150 or so attendees, which felt very different from traditional Ruby Central conferences with several hundreds of people. I heard a lot from other folks there that they really liked the regional aspect of it, the intimacy of the smaller conference.

+ +

I think I got more of an opportunity to run into people that I'd met at the conference over the next few days. And there was, yeah, definitely a sense of tighter knit community there, you know, when you meet someone, and then you bump into them on the way into a talk, and then you can ask how their day was going and any highlights that they had. And yeah, I guess I haven't really attended a conference that size before, and so that felt like a very special experience for me.

+ +

JOËL: I 100% agree. I think the smaller format definitely makes it a little bit more intimate, makes it much easier, I think, to build some of those social connections, to meet with people, and to have some good conversations. I think the format of the conference as well favored that. There were, I think, larger breaks between talks that encouraged people to hang out and talk. And, as you said, because it's smaller, you also get to see the same people over the course of a few different breaks instead of being like, oh, I met a stranger on the morning of day one, and then in the afternoon, I met another stranger. And it's just constantly introducing yourself.

+ +

One thing that was really interesting to me is the experience of being a speaker is very different than just attending. As a speaker, you get to go to the speaker dinner and connect with a lot of the other speakers there. Some of them might be quote, unquote "famous people" that you're not quite comfortable just walking up to and introducing yourself. But in the smaller dinner, you just find yourself sitting next to them and enjoying some food or a drink and getting conversations.

+ +

It's also much easier to have people come up to you during the conference. Because you're a speaker, people will come and talk to you. So if you tend to be a little bit more introverted, as long as you can get over your fear of being on stage and public speaking, it actually makes social connection interaction much easier to be a speaker. I would recommend to any of our listeners who were wondering how can I get more out of a conference? How can I get better connections, better conversations? Consider being a speaker.

+ +

STEPHANIE: Yeah, absolutely. We've talked about this before; I think when we chatted about writing our CFPs for this conference that speaking doesn't have to be a really big, scary thing, but everyone has something to say. I think we had mentioned in previous episodes that your talk topic came out of just a discussion that you had internally, and you were like, wow, enumerables are so cool, like, let me dig deeper into them and just share what I learned. So I totally recommend it.

+ +

And this conference was my first in real-life speaking opportunity as well, and that felt super different from my experience last time doing it virtually, you know, talking about how much I love that sense of community all the time. But it really felt true for me this time around, where I could see the audience react to the things I was saying, like, maybe go off the cuff a little bit.

+ +

And then yeah, at the end, having people come up to me was really awesome to just talk about pairing, which is what I spoke about, and just share our experiences. And they asked what I thought about some things, and it was really cool to just be able to spread that knowledge around. And one thing I noticed you did a lot was come up to speakers after they wrapped up their talks. You were almost always the first person to get up and congratulate them and just get the ball rolling on following up on the things they talked about. Is that something that you really enjoy doing or find particularly valuable as an audience member or speaker?

+ +

JOËL: Yes, both. I think, as a speaker, it's really validating to have people come up to you after the talk and either just tell you they liked the talk or ask a question. I generally don't like to do just open questions after a talk from the audience because then you get the classic; this is more of a comment than a question or people who will tell you that you had a typo on one of your code slides. Like, none of that is useful to anyone.

+ +

So, if you're really interested, come talk to me afterwards. And then that actually makes me feel like my talk connected with people, and people were paying attention, people enjoyed it, people were learning. So I try to pay that forward as well for talks that I listened to, go up to the speaker, and tell them one thing that I appreciated about the talk or a thing that I learned, or something that got me excited in their content.

+ +

STEPHANIE: Yeah, I'm sure that it's very appreciated. And it also breaks the awkward silence at the end when the speaker finishes and people aren't sure if it's okay for them to get up and start moving around. Yeah, I thought that was a really good way to kind of just encourage people to start chatting with each other and moving into those break times that we mentioned earlier, those opportunities to socialize.

+ +

JOËL: Another thing that I think is really fun that you can do at in-person conferences, and I know you were doing it a lot, is going to see the talks of friends and colleagues and sitting in the front row and just being there to cheer them on and encourage them. Again, I think that makes a big difference when you are on stage, and you see these people who are your friends and colleagues there to support you. It gives you that boost of confidence. And when you're there in the audience, it's fun to cheer on somebody else.

+ +

STEPHANIE: Oh yeah. You gave me a lot of thumbs-ups during my talk, and I really appreciated that. [laughs] So I'm curious if there were any talks that stood out to you that you got to see.

+ +

JOËL: And I was really inspired by your talk, pair programming. I think there are a lot of things that I can take from that to improve the way I pair. I was also inspired by Aji's talk, Aji Slater, on automating manual tasks that you have to do in an iterative way. That one really hit home because, on my current project, I have been doing a lot of manual things. And I just have random snippets of code, like, some shell script lines or Ruby console lines, that I copy-paste out of Slack conversations because I've shared them with other people who are doing similar work.

+ +

And I realized that a lot of his advice would apply to the work that I'm doing and how that could really make things better. So that was one of those talks I was listening to, and I was like, oh, you know what? Monday morning, when I go back to my project, this is something that I'm going to start doing. This is something I'm going to change in the way I do my day-to-day work.

+ +

STEPHANIE: Yeah, absolutely. I have so many tasks that I would like to get automated, and think that one day I will magically have more time in my schedule to get to it. But I liked that his talk gave pretty concrete strategies for baking it into your regular, like you said, day-to-day workflow, and that lowers the activation energy to getting them done. And then those things can be iterated on and could eventually become, in an ideal world, a fully-fledged feature that you put together from doing those repetitive tasks. And yeah, they provide a lot of value not just to you but can eventually provide value to your co-workers and then even your users in the future.

+ +

JOËL: Were there any talks that stood out for you?

+ +

STEPHANIE: One talk that I really enjoyed was Jenny Shih's about Functional Programming for Fun and Profit. I have attended a lot of functional programming talks within the Ruby realm, at least to try to get a better sense of how it can apply to my work and the languages and paradigms that I use. And honestly, what I liked about it was that it didn't get too in the weeds about functional programming. What she did was provide mental models for understanding the paradigm that I think was a good vehicle for understanding things very generally.

+ +

And, for me, like,¬¬ a talk, it's really hard to pay attention to lines of code and to read code on the fly while people are presenting. For me, that is just not how I like to consume that information. And so she provided themes and, like I said, those mental models, which I know you really like to use a lot too in teaching people new concepts. For me, I didn't fully learn what a monad was, once again, but at least having that repeated exposure to those foundational aspects, I think, will eventually lead me to be able to grok those things a little more comprehensively the next time I see it or whenever I decide to dig deeper.

+ +

JOËL: What was a mental model that was shared that connected with you particularly?

+ +

STEPHANIE: So one of the main mental models that she shared was thinking about a program in terms of these three dimensions: value, behavior, and time. She had a nice slide that showed the difference between the object-oriented paradigm, where value and behavior are contained by objects, where time is kind of inherently wrapped up in those objects that hold information about the state through values and behavior. Whereas in her functional programming example, those three dimensions were a bit separate. And I found that distinction to be really helpful in separating things that felt very implicit before, but it was nice to see them broken out into very clear concepts in terms of building blocks of a program.

+ +

JOËL: So it's helpful then when thinking...when you look at code, if you can think about it in those three different dimensions to help think about, am I taking a functional or other approach in this particular dimension when working with this code?

+ +

STEPHANIE: Yeah, exactly. I think it also gave me more of a vocabulary to describe the pros and cons of each and a lens of thinking about which I might want to choose for the particular problem at hand.

+ +

JOËL: So you mentioned there's a visual for these three dimensions from the slides. Are those slides publicly available?

+ +

STEPHANIE: They are. I will link to them in the show notes.

+ +

JOËL: So all of these talks were recorded. They're not yet available to the public, but I think the plan is to publish them on YouTube sometime in the new year, so that means probably January 2023. And a big shout out to the AV team and everyone who is involved in recording these.

+ +

STEPHANIE: Yeah, I am definitely looking out for a link to my talk so I can send it to my mom. I also wanted to give a little shout-out to the organizers of RubyConf Mini: Jemma Issroff, Emily Samp, and Andy Croll.

+ +

JOËL: Woo!

+ +

STEPHANIE: They put on just a really awesome conference, and I feel very grateful that I got a chance to attend with you, Joël.

+ +

JOËL: It was definitely a delightful experience.

+ +

STEPHANIE: Delightful. That's a reference to Joël's talk for those of you who are listening.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: Coming back from the conference, I recently had a really interesting conversation with some other colleagues at thoughtbot. We were looking at a database schema for a new application and talking about some of the trade-offs involved in how that schema is structured, so what tables we want to have. Do we want to have indexes? Things like that. And particularly around some of the assumptions are business rules that would come into play.

+ +

So we're looking at...we'd drawn out this Entity Relationship Diagram (ERD). In it, we're looking at all the tables, and something that comes up immediately is like, oh, it's possible to have some bad data that could show up in these columns. Or it's possible that this relationship could exist where this table has a foreign key on this table, but really, that should never happen in this particular way of working.

+ +

And so then the question became, how do we try to prevent these things that currently the schema allows but that are not valid in this particular business domain? Do we want to change the schema somehow and make that stricter or find some way to prevent it? Do we want to add some kind of validation that will check some business rules first before inserting or updating a record? I'm curious, have you ever been in a situation like that where you had to balance those two approaches to enforcing business rules on your database?

+ +

A classic small example of this is a situation where let's say, you have a users' table and you have a name column on there. And you want to ensure that that name must always be present; all users must have names. Do you try to enforce that via the schema with a NOT NULL constraint? Or maybe you try to enforce that with a validation, maybe a presence validation at the Rails level.

+ +

Or if you're really into SQL, maybe some fancy trigger, but do it in a validation style rather than trying to force this using the schema. And our particular scenario was a little bit more complex than just one column; it was more to do with associations. But I think this sort of problem shows up even in constraints as small as a required field.

+ +

STEPHANIE: That's really interesting. I think that, in my experience, when we are spinning up new tables, at that point, we do try to put some intentional thought into what the schema should look like and what requirements we might need to encode at the database level. But things that are more complex might need a little more code, like Ruby code. I have then pushed to an ActiveRecord validation.

+ +

One thing that I think is important to know is that when you do set those things on the schema, it's harder to change. And so you usually have to feel pretty confident that that's what you want. Otherwise, you'll run into issues later if that does have to change and making changes to whatever existing data you might have. But it's also pretty common to just do your best when you are deciding on a database schema and then having to make adjustments down the line as you know more about your domain.

+ +

JOËL: This conversation reminds me a little bit of the idea of database normalization. I think that might almost fit as a subset of general tactics of using the schema to ensure your data is more correct. When you are generating new tables, let's say you're creating a greenfield app and you need to create four or five tables; how much emphasis do you put on database normalization when you're initially designing those?

+ +

STEPHANIE: I think for a greenfield project when you are setting everything up and creating tables for your main domain models, there is an aspect of it that should be considered because you're in this unique position where nothing really is in existence yet. And you do want to try to set yourself up to be successful and hopefully have information about your main use case for this app and can kind of make decisions about the schema then.

+ +

At least in my experience, that has been part of the conversation, though, to be fair, because it's so early, you do have the opportunity to change things without as much effort or pain. But I think it's worth considering when you're just sitting down and working through what those models are going to look like.

+ +

JOËL: And for our listeners who may not have heard the term normalization before, it's a series of...you can think of them as rules that you apply to your database design to try to avoid data redundancies in your tables. There are different levels of this; they're typically referred to as normal forms. So you'll see things like first normal form, second normal form, third normal form; those are kind of the fancy terms for them.

+ +

But they generally involve breaking out other tables so that you don't have data redundancies. And in many ways, this is similar to principles such as the single-responsibility principle that we apply to objects when we're designing our objects in an OO system. But this is more at the table level for databases.

+ +

STEPHANIE: I do think that it is so hard, maybe even impossible, to plan something out, to not have any of those redundancies, to begin with. And I do think sometimes they are a bit inevitable. But I also have had the experience of having to figure out what the heck I'm looking at when I am querying data and see all these things that are duplicated or maybe slightly different.

+ +

And yeah, I think when you are in that position of starting a greenfield application, it is really interesting to see how you make those decisions about what needs to be enforced and where. Where did you end up landing, or what did you discuss in this conversation with the co-worker?

+ +

JOËL: I think we went with a bit of a hybrid approach. Some things, we can use the schema to prevent bad data, and then some things either cannot be represented with a schema, or it's possible, but it's really cumbersome and painful. And so, we chose to try to enforce it with a validation. To me, this feels very similar to a problem in typed languages.

+ +

So some communities that use a lot of types try to use those types to only allow data to come through that's in a valid shape. And so you'll hear things like make impossible states impossible or make illegal states unrepresentable. And that works for many things, but it's not always possible to enforce all of your business constraints through a schema. Or sometimes it's possible but just not practical. And so, I think there is a balance of finding when you can use the schema or when it's better to use the validation.¬

+ +

STEPHANIE: Yeah, I think my general rule of thumb is, like I mentioned earlier, things I feel really confident about that we want to make sure that we have in our database or in our data for sure. I do lean towards requiring those in a schema, and it also communicates that confidence or communicates that intent that it's something that at one point was decided is important. And so, if a future developer comes in, it would take a lot of work for them to write a migration, to remove some database constraint. Whereas I think sometimes validations at the Rails level are potentially a little more open to change and then even more so if you get to validating on the client side.

+ +

JOËL: That can get to be a really, like, it's a useful tool, but one that you can really hurt yourself with. If you modify your validations at the Rails level or at the front-end level, but then you don't backfill those changes on your data in the database, then you might have records in your database that if you were to load them into memory and hit save on them again, would refuse to save because they no longer match the validations. And on longer-lived applications, I've seen that happen sometimes where not all rows in the database pass the Rails validations.

+ +

STEPHANIE: Yeah, I think I've seen that be a problem either for developers who then have to backfill that data or write some migration to change some of the data to meet the new requirements, or just unexpected bugs on the users who discover something new but like you said, have been there long enough before those things were implemented.

+ +

JOËL: The more I think of this, I think maybe constraints that are enforced at a validation level might still require changing the data in your database. So if you had a constraint enforced via a schema, you don't have a choice. You have to write some way to migrate that data so that it fits the new schema. You can kind of lie to yourself with validation and not change the historic data, and sometimes that is the case; you want to keep the old data and only prevent new data from being written in the old format. But if you need consistency, then you probably need a data migration regardless of which approach you take.

+ +

STEPHANIE: Yeah, that definitely sounds like the more robust way to go about it for sure.

+ +

JOËL: I have an article that I like to reference a lot by Hillel Wayne on Constructive Versus Predicative Data, which is basically looking at these two general approaches to enforcing data correctness and formalizing them a little bit. So do you try to enforce them based on the construction or the shape of the entity that you're creating, be that a database table, an object, a type, something like that? Or do you enforce it via some kind of predicate? So that could be a validation or other similar logic that runs kind of at runtime to enforce your constraints.

+ +

STEPHANIE: That's interesting. I hadn't heard of those terms before, but I think they provide a lens through which you can look at the problem. Did the article end up suggesting different strategies for solving that problem, or was it more theoretical in different ways to look at it?

+ +

JOËL: I think the article does two things. First, like you said, it gives us the words to talk about those approaches. And having those labels now, I start seeing them everywhere. I see them in databases, I see them in objects, I see them when doing types across a variety of languages. So that's already a huge win for me. I think you and I had done an episode a couple of months back where we talked about the value of having labels to put to ideas. And I think for me reading that article gave me those two labels. And all of a sudden, it really helped to make connections that I wasn't seeing before.

+ +

The second thing that the article does is, I think, explore some of the limitations that each approach has and when you might want to use one versus another. The constructive approach, so using a schema, is more consistent because you know it is impossible for the program to create data that's in the wrong shape. That being said, not all constraints can be represented in a constructive manner, or it might be possible but really cumbersome.

+ +

Also, sometimes it's not really invalid data; it's just sort of undesirable data. So you might want a looser schema. And let's say that you're storing some kind of intermediate state or some kind of raw input from another system that you might want to layer validations on top of, but you don't want to reject that data out of your database. You want that sort of incomplete or imperfect data in your system.

+ +

Something that I find myself doing more and more these days when I create new tables is to really lock down the schema as much as possible. I think that might be contrary to maybe the way a lot of people in the community like to work. Some people might prefer to start with a very loose schema with no constraints and then work towards making things stricter as they explore the domain, and that's kind of the default that Rails has. If you're creating a new table, all columns, for example, are nullable by default.

+ +

Personally, I will put a null false on every column and every migration that I make unless somebody can make a convincing case otherwise, and even then, I might try to think of is there any possible way that we could avoid that scenario and put that null false. Part of the reason for that is that it is much easier to loosen constraints on existing data than to tighten them afterwards. So if I have a column where no value is allowed to be null, and then later on we decide, you know what? It is okay for some of them to be null, I can change the requirement on that column, and I don't need to make any changes to the existing data. It just works.

+ +

If the reverse happens, if I have a column that allows a bunch of nulls and then I want to make that column required, now I have to go and find a way to backfill all the empty spots in that column. And that could be a very challenging process. It might even be impossible. There might be some values there that it's just like, the user did not supply them at the time because we didn't ask for them. And now there's nothing we can put in there. So do you put in, like, unknown or not available? Then you have to ask yourself some really difficult questions about your data.

+ +

STEPHANIE: Yeah, absolutely. I think I agree with you there. Another thing I like to do is provide default values for columns, especially ones where they can't be null, because, like you were saying, that helps me have a better understanding of just what is going on in the database.

+ +

An issue I have seen come up involves a Boolean column where if a default value of false, for example, if that's what we're going with, is not encoded in the schema, you end up with potentially three values for a Boolean, which would be true, false, and null, and that I think has been --

+ +

JOËL: The infamous three-state Boolean.

+ +

STEPHANIE: Yeah, exactly, the three-state problem, which is just inherently contradictory to what a Boolean is, to begin with. And I've definitely run into issues with that where you have to decide, or figure out, or write code to determine is null false? Is that what we mean here? It's not clear. But if you, like you said, locked it down at the beginning, provided those default values, that puts in those guardrails to prevent things from getting out of hand.

+ +

JOËL: It also makes it easier for users of your database, application, whatever to interact with your code. I've run into this a lot when working with GraphQL APIs. And the default in many GraphQL server implementations is to make all fields nullable by default. When you build your schema, you have to add some extra things there to say, "This field is non-nullable," which means that a client that's now consuming it, anytime they deal with the data they need to check, is it present or not? You can't have the confidence that that data is there. And so it can force a lot of extra checks on the client. Or I guess you could just take it on faith and hope nothing breaks.

+ +

STEPHANIE: Yeah, it's funny you mention that because I definitely think there's like spheres of impact. So as a developer, you maybe start having to write code that checks those kinds of things, like if it's null or not in your code. Then that can even extend to, like you said, your users or consumers of the API, who then have to contend with data that they have no control over. And I've been there too, and that can be frustrating as well.

+ +

JOËL: We've talked a lot about data correctness and different ways to achieve it, different strategies. Why is this something that we care so much about?

+ +

STEPHANIE: I think data correctness is really important from a developer experience perspective. And it's way easier to fix a bug in your code than it is to wrangle a lot of accumulated bad data.

+ +

JOËL: Yeah, sometimes bad data is not fixable at all, and those are situations where you have a really bad day as a developer.

+ +

STEPHANIE: Agreed.

+ +

JOËL: Well, on that note, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+bR02MUu6 + + ]]> + + Joël Quenneville + Stephanie Minn + + + 363: Deployments + https://bikeshed.thoughtbot.com/363 + e743a388-0081-4106-b42a-cbbf759edee6 + Tue, 22 Nov 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Joël discovered Bardcore. Stephanie planned and executed an IRL meetup for folks in the WNB.rb virtual community group in Chicago and had a consulting win. + +Together, they discuss what deployment processes look like for clients in their current workloads. + 34:26 + no + + + Joël discovered Bardcore. Stephanie planned and executed an IRL meetup for folks in the WNB.rb virtual community group in Chicago and had a consulting win. +Together, they discuss what deployment processes look like for clients in their current workloads. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Hildegard von Blingen YouTube Channel (https://www.youtube.com/c/Hildegardvonblingin/videos) +Hildegard von Bingen - Historical Character (https://en.wikipedia.org/wiki/Hildegard_of_Bingen) +WNB.rb (https://www.wnb-rb.dev/) +git flow (https://nvie.com/posts/a-successful-git-branching-model/) +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: I've been getting into something that's kind of fun and quirky. It's a new musical genre called Bardcore. +STEPHANIE: Bardcore. +JOËL: Yes, it's basically re-mixing pop songs to make them vaguely more medieval, oftentimes using acoustic instruments, something that sounds a little bit more like maybe a lute in some flutes, oftentimes also kind of changing the lyrics a little bit to use more old-timey language. When the lyrics use words from modern life, sometimes changing them to something that would fit more in a more medieval setting. It's a lot of fun. +STEPHANIE: That sounds so fun. When are you normally in the mood to listen to Bardcore? +JOËL: It can be fun while coding because it's fairly chill as a genre. Honestly, I feel like it can also be good when I'm just sort of feeling a little bit nostalgic or daydreamy. I think it's good for that mood as well. +STEPHANIE: I love that. I can't wait to go and listen to some Bardcore after this. +JOËL: Let me recommend the YouTube channel Hildegard von Blingin' as a great entry point into the genre. +STEPHANIE: Incredible. I can't wait. In fact, I'm going to end up sharing it with all of my D&D friends too. +[laughter] +JOËL: The channel is a play on words of an actual historical character, Hildegard von Bingen, who is, I want to say, a 12th-century nun but also a polymath. So she wrote on all sorts of topics, from biology and the natural world to theology. She was a musician, just one of these like really talented people that made a mark on the medieval world. So it's kind of fun that they used her name as the inspiration for the channel. +STEPHANIE: Yeah, that sounds right up your alley. I knew that you were going to come with a historical tidbit about Bardcore. [laughs] +JOËL: Another really cool thing that I appreciate about the channel is it's not just audio. It's also beautifully illustrated. So the creator has created visuals inspired by medieval manuscripts illustrating the contents of the song. So it's kind of funny to see something that...modern pop songs aren't always the most deep lyrics, and to see them given this medieval manuscript treatment is amusing, for me at least. +STEPHANIE: That sounds really funny and also kind of calming. I was just thinking about what you said earlier about how they sometimes rewrite the lyrics to be more about medieval life. And I love the idea of taking the things that pop songs are about these days and applying them to historic life back in the day. +JOËL: A lot of pop songs also are about love, and romance, and breakups. I think that kind of fits with some of that 12th-century troubadour-style romantic songs because that was definitely the kind of thing that they were singing about back then as well. +STEPHANIE: Absolutely. +JOËL: So I've been jamming out to Bardcore this week. What is new in your world, Stephanie? +STEPHANIE: I'm really excited to share that I had an awesome weekend. One of the things that I had been doing the past couple of weeks was planning an IRL meetup for some folks in Chicago, people in the WNB.rb virtual community group. I've mentioned it on the podcast before when I was a guest. But WNB is a Ruby community group for women and non-binary folks. And we just started creating regional Slack channels. +And so I started a little Chicago channel and planned a brunch. So on Sunday, a few of us, I think it was six, some old friends and some new met up for brunch in Logan Square in Chicago. And it was really awesome to do a local meetup. I haven't done something like that since pre-COVID times, and so it felt really special. +JOËL: That's exciting. Were you big into the meetup scene pre-COVID? +STEPHANIE: So I was working remotely for a previous company when I moved back to Chicago, and so was still trying to meet people here, find a community, find some friends. And I did go to a few community groups, but that was not too soon before COVID started, and so I didn't get to really invest in them the way that I had hoped. So it's really exciting to me to potentially be able to start doing that again. +JOËL: This new meetup that you were at, was it focused more on the social aspect of things, or was it a more technical meetup? +STEPHANIE: It was definitely more of a social aspect. I would be really curious to know if that group would want to focus on some more technical things. But we had a nice diversity and experience levels and the types of work we were doing. So there were a few of us who were consultants, a few of us at product companies. And I think we shared a lot about our different experiences. We talked a bit about the pros and cons of product versus consulting. +And so it was really nice to just learn more about what other people are up to, what tech and framework people are using, and chat casually in that sense. But I also definitely see some more opportunity to focus on technical stuff if that moves us. +JOËL: I think that was probably my favorite part of Ruby meetups back when I was attending those a lot here in Boston, where I'm based, getting to chat with other developers in the city, hearing about their experiences on different topics. And oftentimes, it will sort of revolve around tech to a certain extent, but it's not always like a formal have a presentation. Sometimes just socializing is almost more fun or brings more value to me. +STEPHANIE: Yeah, I totally agree. I also wanted to share another thing that happened to me this week. It was a bit of a consulting win. So on my client project, we have been having retros every two weeks at the end of the sprint. But I was noticing with a fellow thoughtboter that we weren't really getting a lot of engagement in retros. It was kind of the same folks speaking and bringing up issues because we were doing it in a style that was like a retro board, and then folks could write in cards or raise their hand in the meeting to add something to one of the columns. +And so, we ended up proposing to do a round-robin style format for retro. And we just had our first one yesterday using that new format, and it was received really well. Everyone went around and shared things that went well. And then, we went around again and shared things to improve or risks or concerns that we had about the sprint. And it was really nice to have everyone participate, to hear folks piggybacking off of what other people said. And I think we were able to get a better sense of what the group was feeling. +And yeah, there was a new hire who was just observing our retro, and she is going to be facilitating these kinds of meetings for other teams. And she seemed really into it and wanted to bring it over to other teams as well and try it there. And so that felt really good to know that we were able to make a change that was an improvement for our team but might even have an impact on other teams at the company as well. +JOËL: I love that. I think a lot of what we often bring to the table, because we've seen things at a lot of different companies, is not just code improvements but also process improvements. Every company is different, so you can't always just copy-paste things from one place to another. But being willing to try new things, experiment, and then follow this iterative, continuous improvement approach, not just with the code but with the process as well, I think, is something that is really valuable in the work that we do for our clients. +STEPHANIE: Yeah, absolutely. +JOËL: And it sounds like here you iterated on their retro process. And everybody seems to really like this new iteration, so that sounds like a big win. Congratulations. +STEPHANIE: Thanks. I really appreciated that they were open to trying. That made me feel really good and makes me feel empowered as a consultant to be able to like you're saying, leverage that experience and suggest things that can just improve the quality of life for our clients. +JOËL: Another area that I think we've seen a lot of different ways of doing things, and we've actually been able to iterate a lot as far as process goes, is deployments. How do we get our code from, let's say, passes code review, and then, at some point, we want it to go live in production? So what does deployment look like on your current client, Stephanie? +STEPHANIE: I'm glad you asked because I'm experiencing a deployment process on this client that's actually a bit different than what I have seen before. So this client is not a super big team, but maybe, I don't know, between 30 or 50 engineers would be my guess. I am working on a smaller team with just four developers. And so I'm seeing a lot of code get merged into our big Rails app pretty frequently by other teams. And we are also merging to the same app. +So my client has release managers who rotate each day and go through all of the different teams' pull requests that are ready to be merged. They will merge those pull requests on the developers' behalf. And then once everything is merged into an integration branch, they will then merge all of that stuff into their production branch and kick off a deploy. +JOËL: Wow. So does that mean that developers on your team don't merge their code? You just when you get an approval, you ping the release manager and ask them to merge it for you? +STEPHANIE: Yeah, so developers don't merge their own code. We might move the card into ready for deployment, and that's how release managers know that that PR is ready to be merged. +JOËL: And are you then following something that's roughly like Git flow where you've got this sort of development branch, and then at some point, commits get maybe cherry-picked over to the main branch, which then gets released? Or maybe it's even a special dedicated release branch. What does that look like in terms of the Git workflow? +STEPHANIE: Yeah, we have that release branch that you mentioned that eventually gets merged, either through the GitHub GUI or a CLI by the release manager, into the main branch, essentially. And that's what then gets deployed. +JOËL: How do you handle situations where a feature goes out to production, and then you realize that there's a bug or there's something that you don't like about it, and you would like to revert that feature? +STEPHANIE: Yeah, that's a great question. This has happened to me once now, where I merged some code that ended up introducing a regression. And unfortunately, I wasn't tagged or pinged, so I didn't really know about this until the next business day and caught up with Slack and saw that someone else had to resolve my issue, which was kind of a bummer, I think, because with this process, once that code is, quote, unquote, "done," since I'm not the one merging it, and I'm not the one deploying it, I don't get a chance to follow up on the changes in production and then check to see if they look good. +When things go wrong, it seems like it kind of takes a bit of time to figure out how to get it resolved like; who would have the context? And then, if they're not available, someone else might have to jump in and fix it. So it's been interesting because, on one hand, I totally understand that they want to be releasing just once a day. Like, it's nice to have a dedicated person do all of this stuff that is work and would take away time from normal development. +But I do sometimes feel like I don't have as much ownership over my feature with this process because, like I said, it just kind of is out of my hands. And oftentimes, I might be done with my work, but that doesn't get deployed for a few days depending on other things going on with the team. +JOËL: That's interesting that you mentioned that it might not be deployed for a few days even though it's done and maybe merged. I think, generally, we assume that merging a commit into the main branch and deploying it are going to be more or less the same thing. +But oftentimes, you might end up in a situation where there's a feature that's done in development, but we don't want it to actually go live for our customers for a while yet. And that might be for technical reasons because we're waiting for other pieces to be in place, or it might be for business reasons because we did the work, but this feature has to come out on a particular date, and so that's when it's going to go live. +So then you end up in that awkward situation, maybe where you want to deploy something else. But you've got a commit already on the master branch that can't go out with the others. And you've got to do an awkward cherry-pick. Have you ever been in that situation? +STEPHANIE: I have. I remember being on a project where we had features in our main branch, but that hadn't been deployed to users yet. We actually didn't want that to be live yet but then had an issue with an existing feature that was already live that we had to make a hotfix for. And that was definitely one of those cherry-picking situations that did become a bit hairy and wasn't too fun. It sounds like you have had experience with that type of deployment process as well. +JOËL: Yes, I think of a project where that was a very common problem because there were a lot of features on that project that were gated to a particular time. So a lot of the features going live for customers were decoupled to the actual development lifecycle. And on that particular project, we used a lot of feature flags on the commits. So we'd control whether or not a feature was live for the customer. It wasn't, is this commit in the main branch, but it was, is this feature flag on or off? +STEPHANIE: Yeah, we're using feature flags on this client project as well. And so, in some ways, I think that if we did have a more continuous deployment process, it would be okay because this big feature that I'm working on on my team we're not trying to go live until a month from now, but we have been slowly, incrementally pushing features underneath the flag. But even then, we do still have a bit of an async process because of this daily release flow. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: How do you feel about continuous deployment in general? +STEPHANIE: So the reason why I found the way I've been describing so surprising is because I am more used to a continuous deployment flow. When I used to work for a product company, and we were a team of, I don't know, like 30 engineers, we'd merge our own work. And then our main branch would automatically be deployed. And so we could make sure our changes looked good in production and then feel a sense of we finished this feature. But we did also run into problems there because our CI build time which had to run for every single time that code was merged into main, took maybe 20-25 minutes. +So whenever we merged to main, we would have to wait for CI to build, wait for the deploy to go through, and that might be a few extra minutes depending, and then confirm our changes. And that became more of an issue when there was a backup in the queue of a lot of people trying to merge code. And it's funny because we kind of want to be constantly merging. That's kind of a sign that things are moving along. +And it ended up being that deployment was the bottleneck in some instances, especially if there was a CI build that broke, and then it was kind of like a car crash a little bit where there was this huge backup. That wasn't great either because when you have to babysit your deploy like that, I didn't find that I had a ton of focus time to go and pivot to something else. I was just keeping an eye on things the whole time. +JOËL: Would you have preferred a workflow that maybe didn't run on every commit but maybe ran once every 30 minutes and just bundled any commits that happened within that? So maybe it's one commit, maybe it's four. Or would you have maybe preferred one where you didn't run the tests before deploying? You're just like, you know what? We trust that we ran them on the branch. It's good. We can just go straight to production. +STEPHANIE: Well, that idea, the second one of not running tests before deploying, I've never even thought about that. I think that it does provide some value because when you integrate changes into main, sometimes that might cause unexpected issues. So I think, in my experience, the times when CI failed, it usually was for a valid reason, and it wasn't just a blocker that we then had to retry the build for. +But what you were saying about bundling commits or a set of changes and then deploying on a scheduler maybe a few times a day automatically, that sounds really interesting to me. I have never worked on a team that has done it that way. But that sounds like it could be a good, happy medium between the two processes. +JOËL: I think that's effectively what the release manager is probably doing manually. But if there was a way to just do that automatically where you just say you merge to the main branch anytime you want, but on a timer every 30 minutes, the latest main will be run on CI, and if it's green, it will get promoted to production. +STEPHANIE: I think there's still a sense of whose job is it to follow up if something goes wrong in that sense. +JOËL: That's a good point. I think part of that is also it's a coping mechanism because of the slow test suite. We have a big process smell here, and we're trying to find some ways to get around it. And one way where I don't think any amount of process is going to help is when you have to do a hotfix. +So let's say there's a really bad bug in production. We need to get that fix out now, and so I make that fix. I live ping you to review it. We get it done in like 10 minutes, and we merge. And now we've got to wait 20 minutes for CI to pass before we can make that patch go live. And we're really hoping this test suite is not flaky because if not, we might be waiting another 20 minutes. +And so, in a sense, a slow test suite becomes a huge bottleneck to fixing emergency things. And now we're going to be tempted to say, "This is an emergency. We're going to bypass CI and just ship directly to production because this is on fire. We are corrupting customer data or something. This needs to be fixed now." And hopefully, we did not make the problem worse in our hotfix because we were rushing, which I have definitely done. +Luckily, in these situations, it has gotten caught by CI. But there have been situations where I've tried to do a quick hotfix that I thought was going to fix things, and then CI caught it, and I was like, I'm glad I didn't just put that directly in production. +STEPHANIE: Yeah, I think what I've come to realize is that the current process that I am experiencing on my client project, you know, I'm sure there's some history there about how it came to be and why they decided to do it that way. And that might be an artifact of something going wrong and them trying to put guardrails to prevent problems from showing up in production. So I do have some understanding there. +So if anyone out there has a deployment process that they love, I would love to hear about it. You can tweet us @_bikeshed or send us an email to let us know if you have a deployment process that works well for your team. +JOËL: Maybe we'll even feature it on a future episode. +STEPHANIE: Yeah, definitely. +JOËL: I'd like to get into some of the trade-offs that come with different processes, and one that jumps out at me from what you were talking about earlier is the impact of team size. With a smaller team, when you're, you know, 2,3,4,5 developers, you can have a really simple Git-based approach where merging a PR goes directly onto your main branch and maybe even have it set up to automatically deploy, and that's kind of it. If a commit is on main, it is live in production. And if you want to undo something, you just Git revert, and that goes live. And that's a really simple, effective workflow. +But then, as the team starts growing, you start needing something a little bit fancier because there are a lot of commits coming out at once. They might have dependencies on each other. Reverting becomes a little bit more complicated. As the product gets more complicated, too, then you start having to want to have work that's done, but you don't want to just have a PR sitting around waiting until go-live day. So I think that's definitely an axis to think of when you're thinking of trade-offs is some workflows work very well for smaller teams and others are a better fit for larger teams. +STEPHANIE: Absolutely. I think when you were talking about smaller teams, almost everyone has knowledge about what is currently being worked on. And so when problems do happen, that work of reverting or figuring out what went wrong isn't as hairy because most folks on a small team would know what changes are being merged and can pitch in to help there. +But yeah, I am really interested in the transition between a small team where you feel comfortable just merging the code and having the automatic deployment and when you do need to have a heavier-handed solution, I suppose. Do you think that there's an inflection point that pushes that decision to be made? +JOËL: I'm not sure exactly where that inflection point is. I might say as low as maybe 5 or 10 developers on your team, but there are probably some other variables that go along with that. Part of it might even be how good your team is at keeping commits small and focused, and independently deployable. If your team is committing really large commits that potentially break the build or that are tightly coupled to other commits, that might make it really difficult to say that your branch is always deployable. And so, you might want to bring in a heavier process earlier. +Whereas if your team is doing a lot of small, atomic commits, which I think we discussed this on last week's episode, I think that could probably allow you to get a lot more mileage out of a very simple workflow where even with a slightly larger team, you're still able to just merge and deploy and also potentially revert very easily because these are atomic commits. +STEPHANIE: Yeah. I like what you said about how you can get away with a lighter solution if you are really investing in things like making sure that each commit is green on CI. Because, you know, kind of what we were saying earlier, sometimes adding additional process without really figuring out what we're trying to solve here can lead to some of those trade-offs that we're talking about. +JOËL: Agreed. I'm a big fan of using the simplest process that your team can get away with. Maybe we could even extend that more generally to just use the simplest thing that your team can get away with. I think that goes for code complexity, that goes for maybe code optimization. Don't make it more complex just because you're hoping to have this massive scale one day because you don't need it today. So use a process that works for your team at your current team size, and then you can iterate on that and start adding more complex elements as the team starts growing. +So, Stephanie, I'm curious; we've talked about a lot of different types of deploy processes. What would be your ultimate favorite way to handle deploys if you had the choice? +STEPHANIE: I think I do prefer a more automated process. When I was on a medium-sized team, that was working pretty well for us. We were having deploys be kicked off when we merged to main, but then we had a Slack integration that would tell us, "Hey, your thing is being deployed." It would tell us the results of the CI build, and it would tag us if something went wrong. And so I think that was nice in solving that issue of ownership that I had mentioned where I knew that, oh, there was an issue. I have the most context, and I can solve it the most quickly on this team. +And then it was also good to just see what was going out, see what other people were working on. I liked that it made that very transparent. And that sense of feeling like you saw your feature from start to finish and seeing it live on production felt really good and gave me meaning in my development work. +JOËL: Yeah, that sounds like it hits a lot of really positive values, like you said, that ownership that you have from beginning to end, even with maybe the revert if something has to happen, the transparency where you get to see if any issues came through. And then the automation and the simplicity because it's just merge your PR and the work goes out. +Earlier in the episode, we were talking about trade-offs that come with a workflow. So a workflow like what you're describing, what size team do you think would be best suited for a workflow like that? +STEPHANIE: Yeah, I don't know if I have an exact number. I did mention that medium-sized team seemed to feel pretty good where we did have some investment in the infrastructure in place, so, like you were saying, we had guardrails when things went wrong. But it wasn't so much for a really large team where it would have been too noisy in the Slack channel. +And also, merge conflicts would come up if we were merging a lot of work during the day. And that did interrupt that queue and that flow and became something that we had to manually work through sometimes with other developers if that was their code that we had conflicts with. And so I can see it also start to not work past...I think I mentioned that the team was 20 to 30. I would be really curious to know how far that can take a team as it grows. +JOËL: So, 20 to 30 people, this workflow works pretty well. What about sort of maybe experience level? Do you think this is a workflow that requires a certain level of seniority? You're talking about merge conflicts a lot, so maybe a team that is very disciplined with keeping their commits small. Do you think that's required to make this workflow work well for the team? +STEPHANIE: That's a great question. When I was on this team, we did have people with all experience levels. And what I really liked was that it was okay if there were merge conflicts. It was okay if CI was red. People were super helpful in jumping on to work with you to figure it out, also, because they probably had things in the queue that they were waiting to try to go out. +But it felt like a team culture where we were all committed to releasing our code smoothly. And so sometimes merge conflicts would happen, but, like I said, you usually could see it and could jump in to help out if someone was maybe stressed out about it or needed an extra hand. +JOËL: I love the process you described. And the culture that your team had didn't require everyone to get it right all the time. There's room for mistakes or not even mistakes, but just less experience where you don't always know to scope everything super tightly, or your Git process isn't quite perfect every time. And that's great for a team because there's room to grow, room to bring in people of different levels of experience. +STEPHANIE: Yeah, I also think it's more realistic. +JOËL: Oh, 100%. I'd like to look at one more axis of trade-offs, and that is product type. What kind of product do you think that this workflow you described would fit well as opposed to maybe a different type of product that wouldn't be as good of a fit? I think what comes to mind for me immediately is maybe situations where you do a lot of work upfront, but then you only want it to go live for clients later, but you do want it merged. And so you decouple the Git history from actually releasing to customers. +So that's a product lifecycle that might be a little bit different. It could be a product where you even just do big releases at set intervals. So people don't want continuous change, but you're like, once every season, we release the new version or something like that. +STEPHANIE: Yeah, I was thinking that the continuous deployment process worked well for that team who was building a product that was very customer-facing in the sense that people were visiting the site every day. And they were running a lot of A/B tests on those customers as well. And so that was helpful because we could be releasing those tests iteratively and getting continuous feedback that way. +JOËL: So, as we discussed in this episode, no process is perfect. There are always trade-offs. So I think it was really fun to look at a concrete example of a process that you liked, Stephanie, and then look at maybe some of the trade-offs for when does it work and when does it not work so well? And with that, shall we wrap up? +STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +JOËL: This show has been produced and edited by Mandy Moore. +STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. +STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. +JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Joël discovered Bardcore. Stephanie planned and executed an IRL meetup for folks in the WNB.rb virtual community group in Chicago and had a consulting win.

+ +

Together, they discuss what deployment processes look like for clients in their current workloads.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Hildegard von Blingen YouTube Channel
+Hildegard von Bingen - Historical Character
+WNB.rb
+git flow

+ +

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: I've been getting into something that's kind of fun and quirky. It's a new musical genre called Bardcore.

+ +

STEPHANIE: Bardcore.

+ +

JOËL: Yes, it's basically re-mixing pop songs to make them vaguely more medieval, oftentimes using acoustic instruments, something that sounds a little bit more like maybe a lute in some flutes, oftentimes also kind of changing the lyrics a little bit to use more old-timey language. When the lyrics use words from modern life, sometimes changing them to something that would fit more in a more medieval setting. It's a lot of fun.

+ +

STEPHANIE: That sounds so fun. When are you normally in the mood to listen to Bardcore?

+ +

JOËL: It can be fun while coding because it's fairly chill as a genre. Honestly, I feel like it can also be good when I'm just sort of feeling a little bit nostalgic or daydreamy. I think it's good for that mood as well.

+ +

STEPHANIE: I love that. I can't wait to go and listen to some Bardcore after this.

+ +

JOËL: Let me recommend the YouTube channel Hildegard von Blingin' as a great entry point into the genre.

+ +

STEPHANIE: Incredible. I can't wait. In fact, I'm going to end up sharing it with all of my D&D friends too.

+ +

[laughter]

+ +

JOËL: The channel is a play on words of an actual historical character, Hildegard von Bingen, who is, I want to say, a 12th-century nun but also a polymath. So she wrote on all sorts of topics, from biology and the natural world to theology. She was a musician, just one of these like really talented people that made a mark on the medieval world. So it's kind of fun that they used her name as the inspiration for the channel.

+ +

STEPHANIE: Yeah, that sounds right up your alley. I knew that you were going to come with a historical tidbit about Bardcore. [laughs]

+ +

JOËL: Another really cool thing that I appreciate about the channel is it's not just audio. It's also beautifully illustrated. So the creator has created visuals inspired by medieval manuscripts illustrating the contents of the song. So it's kind of funny to see something that...modern pop songs aren't always the most deep lyrics, and to see them given this medieval manuscript treatment is amusing, for me at least.

+ +

STEPHANIE: That sounds really funny and also kind of calming. I was just thinking about what you said earlier about how they sometimes rewrite the lyrics to be more about medieval life. And I love the idea of taking the things that pop songs are about these days and applying them to historic life back in the day.

+ +

JOËL: A lot of pop songs also are about love, and romance, and breakups. I think that kind of fits with some of that 12th-century troubadour-style romantic songs because that was definitely the kind of thing that they were singing about back then as well.

+ +

STEPHANIE: Absolutely.

+ +

JOËL: So I've been jamming out to Bardcore this week. What is new in your world, Stephanie?

+ +

STEPHANIE: I'm really excited to share that I had an awesome weekend. One of the things that I had been doing the past couple of weeks was planning an IRL meetup for some folks in Chicago, people in the WNB.rb virtual community group. I've mentioned it on the podcast before when I was a guest. But WNB is a Ruby community group for women and non-binary folks. And we just started creating regional Slack channels.

+ +

And so I started a little Chicago channel and planned a brunch. So on Sunday, a few of us, I think it was six, some old friends and some new met up for brunch in Logan Square in Chicago. And it was really awesome to do a local meetup. I haven't done something like that since pre-COVID times, and so it felt really special.

+ +

JOËL: That's exciting. Were you big into the meetup scene pre-COVID?

+ +

STEPHANIE: So I was working remotely for a previous company when I moved back to Chicago, and so was still trying to meet people here, find a community, find some friends. And I did go to a few community groups, but that was not too soon before COVID started, and so I didn't get to really invest in them the way that I had hoped. So it's really exciting to me to potentially be able to start doing that again.

+ +

JOËL: This new meetup that you were at, was it focused more on the social aspect of things, or was it a more technical meetup?

+ +

STEPHANIE: It was definitely more of a social aspect. I would be really curious to know if that group would want to focus on some more technical things. But we had a nice diversity and experience levels and the types of work we were doing. So there were a few of us who were consultants, a few of us at product companies. And I think we shared a lot about our different experiences. We talked a bit about the pros and cons of product versus consulting.

+ +

And so it was really nice to just learn more about what other people are up to, what tech and framework people are using, and chat casually in that sense. But I also definitely see some more opportunity to focus on technical stuff if that moves us.

+ +

JOËL: I think that was probably my favorite part of Ruby meetups back when I was attending those a lot here in Boston, where I'm based, getting to chat with other developers in the city, hearing about their experiences on different topics. And oftentimes, it will sort of revolve around tech to a certain extent, but it's not always like a formal have a presentation. Sometimes just socializing is almost more fun or brings more value to me.

+ +

STEPHANIE: Yeah, I totally agree. I also wanted to share another thing that happened to me this week. It was a bit of a consulting win. So on my client project, we have been having retros every two weeks at the end of the sprint. But I was noticing with a fellow thoughtboter that we weren't really getting a lot of engagement in retros. It was kind of the same folks speaking and bringing up issues because we were doing it in a style that was like a retro board, and then folks could write in cards or raise their hand in the meeting to add something to one of the columns.

+ +

And so, we ended up proposing to do a round-robin style format for retro. And we just had our first one yesterday using that new format, and it was received really well. Everyone went around and shared things that went well. And then, we went around again and shared things to improve or risks or concerns that we had about the sprint. And it was really nice to have everyone participate, to hear folks piggybacking off of what other people said. And I think we were able to get a better sense of what the group was feeling.

+ +

And yeah, there was a new hire who was just observing our retro, and she is going to be facilitating these kinds of meetings for other teams. And she seemed really into it and wanted to bring it over to other teams as well and try it there. And so that felt really good to know that we were able to make a change that was an improvement for our team but might even have an impact on other teams at the company as well.

+ +

JOËL: I love that. I think a lot of what we often bring to the table, because we've seen things at a lot of different companies, is not just code improvements but also process improvements. Every company is different, so you can't always just copy-paste things from one place to another. But being willing to try new things, experiment, and then follow this iterative, continuous improvement approach, not just with the code but with the process as well, I think, is something that is really valuable in the work that we do for our clients.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: And it sounds like here you iterated on their retro process. And everybody seems to really like this new iteration, so that sounds like a big win. Congratulations.

+ +

STEPHANIE: Thanks. I really appreciated that they were open to trying. That made me feel really good and makes me feel empowered as a consultant to be able to like you're saying, leverage that experience and suggest things that can just improve the quality of life for our clients.

+ +

JOËL: Another area that I think we've seen a lot of different ways of doing things, and we've actually been able to iterate a lot as far as process goes, is deployments. How do we get our code from, let's say, passes code review, and then, at some point, we want it to go live in production? So what does deployment look like on your current client, Stephanie?

+ +

STEPHANIE: I'm glad you asked because I'm experiencing a deployment process on this client that's actually a bit different than what I have seen before. So this client is not a super big team, but maybe, I don't know, between 30 or 50 engineers would be my guess. I am working on a smaller team with just four developers. And so I'm seeing a lot of code get merged into our big Rails app pretty frequently by other teams. And we are also merging to the same app.

+ +

So my client has release managers who rotate each day and go through all of the different teams' pull requests that are ready to be merged. They will merge those pull requests on the developers' behalf. And then once everything is merged into an integration branch, they will then merge all of that stuff into their production branch and kick off a deploy.

+ +

JOËL: Wow. So does that mean that developers on your team don't merge their code? You just when you get an approval, you ping the release manager and ask them to merge it for you?

+ +

STEPHANIE: Yeah, so developers don't merge their own code. We might move the card into ready for deployment, and that's how release managers know that that PR is ready to be merged.

+ +

JOËL: And are you then following something that's roughly like Git flow where you've got this sort of development branch, and then at some point, commits get maybe cherry-picked over to the main branch, which then gets released? Or maybe it's even a special dedicated release branch. What does that look like in terms of the Git workflow?

+ +

STEPHANIE: Yeah, we have that release branch that you mentioned that eventually gets merged, either through the GitHub GUI or a CLI by the release manager, into the main branch, essentially. And that's what then gets deployed.

+ +

JOËL: How do you handle situations where a feature goes out to production, and then you realize that there's a bug or there's something that you don't like about it, and you would like to revert that feature?

+ +

STEPHANIE: Yeah, that's a great question. This has happened to me once now, where I merged some code that ended up introducing a regression. And unfortunately, I wasn't tagged or pinged, so I didn't really know about this until the next business day and caught up with Slack and saw that someone else had to resolve my issue, which was kind of a bummer, I think, because with this process, once that code is, quote, unquote, "done," since I'm not the one merging it, and I'm not the one deploying it, I don't get a chance to follow up on the changes in production and then check to see if they look good.

+ +

When things go wrong, it seems like it kind of takes a bit of time to figure out how to get it resolved like; who would have the context? And then, if they're not available, someone else might have to jump in and fix it. So it's been interesting because, on one hand, I totally understand that they want to be releasing just once a day. Like, it's nice to have a dedicated person do all of this stuff that is work and would take away time from normal development.

+ +

But I do sometimes feel like I don't have as much ownership over my feature with this process because, like I said, it just kind of is out of my hands. And oftentimes, I might be done with my work, but that doesn't get deployed for a few days depending on other things going on with the team.

+ +

JOËL: That's interesting that you mentioned that it might not be deployed for a few days even though it's done and maybe merged. I think, generally, we assume that merging a commit into the main branch and deploying it are going to be more or less the same thing.

+ +

But oftentimes, you might end up in a situation where there's a feature that's done in development, but we don't want it to actually go live for our customers for a while yet. And that might be for technical reasons because we're waiting for other pieces to be in place, or it might be for business reasons because we did the work, but this feature has to come out on a particular date, and so that's when it's going to go live.

+ +

So then you end up in that awkward situation, maybe where you want to deploy something else. But you've got a commit already on the master branch that can't go out with the others. And you've got to do an awkward cherry-pick. Have you ever been in that situation?

+ +

STEPHANIE: I have. I remember being on a project where we had features in our main branch, but that hadn't been deployed to users yet. We actually didn't want that to be live yet but then had an issue with an existing feature that was already live that we had to make a hotfix for. And that was definitely one of those cherry-picking situations that did become a bit hairy and wasn't too fun. It sounds like you have had experience with that type of deployment process as well.

+ +

JOËL: Yes, I think of a project where that was a very common problem because there were a lot of features on that project that were gated to a particular time. So a lot of the features going live for customers were decoupled to the actual development lifecycle. And on that particular project, we used a lot of feature flags on the commits. So we'd control whether or not a feature was live for the customer. It wasn't, is this commit in the main branch, but it was, is this feature flag on or off?

+ +

STEPHANIE: Yeah, we're using feature flags on this client project as well. And so, in some ways, I think that if we did have a more continuous deployment process, it would be okay because this big feature that I'm working on on my team we're not trying to go live until a month from now, but we have been slowly, incrementally pushing features underneath the flag. But even then, we do still have a bit of an async process because of this daily release flow.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: How do you feel about continuous deployment in general?

+ +

STEPHANIE: So the reason why I found the way I've been describing so surprising is because I am more used to a continuous deployment flow. When I used to work for a product company, and we were a team of, I don't know, like 30 engineers, we'd merge our own work. And then our main branch would automatically be deployed. And so we could make sure our changes looked good in production and then feel a sense of we finished this feature. But we did also run into problems there because our CI build time which had to run for every single time that code was merged into main, took maybe 20-25 minutes.

+ +

So whenever we merged to main, we would have to wait for CI to build, wait for the deploy to go through, and that might be a few extra minutes depending, and then confirm our changes. And that became more of an issue when there was a backup in the queue of a lot of people trying to merge code. And it's funny because we kind of want to be constantly merging. That's kind of a sign that things are moving along.

+ +

And it ended up being that deployment was the bottleneck in some instances, especially if there was a CI build that broke, and then it was kind of like a car crash a little bit where there was this huge backup. That wasn't great either because when you have to babysit your deploy like that, I didn't find that I had a ton of focus time to go and pivot to something else. I was just keeping an eye on things the whole time.

+ +

JOËL: Would you have preferred a workflow that maybe didn't run on every commit but maybe ran once every 30 minutes and just bundled any commits that happened within that? So maybe it's one commit, maybe it's four. Or would you have maybe preferred one where you didn't run the tests before deploying? You're just like, you know what? We trust that we ran them on the branch. It's good. We can just go straight to production.

+ +

STEPHANIE: Well, that idea, the second one of not running tests before deploying, I've never even thought about that. I think that it does provide some value because when you integrate changes into main, sometimes that might cause unexpected issues. So I think, in my experience, the times when CI failed, it usually was for a valid reason, and it wasn't just a blocker that we then had to retry the build for.

+ +

But what you were saying about bundling commits or a set of changes and then deploying on a scheduler maybe a few times a day automatically, that sounds really interesting to me. I have never worked on a team that has done it that way. But that sounds like it could be a good, happy medium between the two processes.

+ +

JOËL: I think that's effectively what the release manager is probably doing manually. But if there was a way to just do that automatically where you just say you merge to the main branch anytime you want, but on a timer every 30 minutes, the latest main will be run on CI, and if it's green, it will get promoted to production.

+ +

STEPHANIE: I think there's still a sense of whose job is it to follow up if something goes wrong in that sense.

+ +

JOËL: That's a good point. I think part of that is also it's a coping mechanism because of the slow test suite. We have a big process smell here, and we're trying to find some ways to get around it. And one way where I don't think any amount of process is going to help is when you have to do a hotfix.

+ +

So let's say there's a really bad bug in production. We need to get that fix out now, and so I make that fix. I live ping you to review it. We get it done in like 10 minutes, and we merge. And now we've got to wait 20 minutes for CI to pass before we can make that patch go live. And we're really hoping this test suite is not flaky because if not, we might be waiting another 20 minutes.

+ +

And so, in a sense, a slow test suite becomes a huge bottleneck to fixing emergency things. And now we're going to be tempted to say, "This is an emergency. We're going to bypass CI and just ship directly to production because this is on fire. We are corrupting customer data or something. This needs to be fixed now." And hopefully, we did not make the problem worse in our hotfix because we were rushing, which I have definitely done.

+ +

Luckily, in these situations, it has gotten caught by CI. But there have been situations where I've tried to do a quick hotfix that I thought was going to fix things, and then CI caught it, and I was like, I'm glad I didn't just put that directly in production.

+ +

STEPHANIE: Yeah, I think what I've come to realize is that the current process that I am experiencing on my client project, you know, I'm sure there's some history there about how it came to be and why they decided to do it that way. And that might be an artifact of something going wrong and them trying to put guardrails to prevent problems from showing up in production. So I do have some understanding there.

+ +

So if anyone out there has a deployment process that they love, I would love to hear about it. You can tweet us @_bikeshed or send us an email to let us know if you have a deployment process that works well for your team.

+ +

JOËL: Maybe we'll even feature it on a future episode.

+ +

STEPHANIE: Yeah, definitely.

+ +

JOËL: I'd like to get into some of the trade-offs that come with different processes, and one that jumps out at me from what you were talking about earlier is the impact of team size. With a smaller team, when you're, you know, 2,3,4,5 developers, you can have a really simple Git-based approach where merging a PR goes directly onto your main branch and maybe even have it set up to automatically deploy, and that's kind of it. If a commit is on main, it is live in production. And if you want to undo something, you just Git revert, and that goes live. And that's a really simple, effective workflow.

+ +

But then, as the team starts growing, you start needing something a little bit fancier because there are a lot of commits coming out at once. They might have dependencies on each other. Reverting becomes a little bit more complicated. As the product gets more complicated, too, then you start having to want to have work that's done, but you don't want to just have a PR sitting around waiting until go-live day. So I think that's definitely an axis to think of when you're thinking of trade-offs is some workflows work very well for smaller teams and others are a better fit for larger teams.

+ +

STEPHANIE: Absolutely. I think when you were talking about smaller teams, almost everyone has knowledge about what is currently being worked on. And so when problems do happen, that work of reverting or figuring out what went wrong isn't as hairy because most folks on a small team would know what changes are being merged and can pitch in to help there.

+ +

But yeah, I am really interested in the transition between a small team where you feel comfortable just merging the code and having the automatic deployment and when you do need to have a heavier-handed solution, I suppose. Do you think that there's an inflection point that pushes that decision to be made?

+ +

JOËL: I'm not sure exactly where that inflection point is. I might say as low as maybe 5 or 10 developers on your team, but there are probably some other variables that go along with that. Part of it might even be how good your team is at keeping commits small and focused, and independently deployable. If your team is committing really large commits that potentially break the build or that are tightly coupled to other commits, that might make it really difficult to say that your branch is always deployable. And so, you might want to bring in a heavier process earlier.

+ +

Whereas if your team is doing a lot of small, atomic commits, which I think we discussed this on last week's episode, I think that could probably allow you to get a lot more mileage out of a very simple workflow where even with a slightly larger team, you're still able to just merge and deploy and also potentially revert very easily because these are atomic commits.

+ +

STEPHANIE: Yeah. I like what you said about how you can get away with a lighter solution if you are really investing in things like making sure that each commit is green on CI. Because, you know, kind of what we were saying earlier, sometimes adding additional process without really figuring out what we're trying to solve here can lead to some of those trade-offs that we're talking about.

+ +

JOËL: Agreed. I'm a big fan of using the simplest process that your team can get away with. Maybe we could even extend that more generally to just use the simplest thing that your team can get away with. I think that goes for code complexity, that goes for maybe code optimization. Don't make it more complex just because you're hoping to have this massive scale one day because you don't need it today. So use a process that works for your team at your current team size, and then you can iterate on that and start adding more complex elements as the team starts growing.

+ +

So, Stephanie, I'm curious; we've talked about a lot of different types of deploy processes. What would be your ultimate favorite way to handle deploys if you had the choice?

+ +

STEPHANIE: I think I do prefer a more automated process. When I was on a medium-sized team, that was working pretty well for us. We were having deploys be kicked off when we merged to main, but then we had a Slack integration that would tell us, "Hey, your thing is being deployed." It would tell us the results of the CI build, and it would tag us if something went wrong. And so I think that was nice in solving that issue of ownership that I had mentioned where I knew that, oh, there was an issue. I have the most context, and I can solve it the most quickly on this team.

+ +

And then it was also good to just see what was going out, see what other people were working on. I liked that it made that very transparent. And that sense of feeling like you saw your feature from start to finish and seeing it live on production felt really good and gave me meaning in my development work.

+ +

JOËL: Yeah, that sounds like it hits a lot of really positive values, like you said, that ownership that you have from beginning to end, even with maybe the revert if something has to happen, the transparency where you get to see if any issues came through. And then the automation and the simplicity because it's just merge your PR and the work goes out.

+ +

Earlier in the episode, we were talking about trade-offs that come with a workflow. So a workflow like what you're describing, what size team do you think would be best suited for a workflow like that?

+ +

STEPHANIE: Yeah, I don't know if I have an exact number. I did mention that medium-sized team seemed to feel pretty good where we did have some investment in the infrastructure in place, so, like you were saying, we had guardrails when things went wrong. But it wasn't so much for a really large team where it would have been too noisy in the Slack channel.

+ +

And also, merge conflicts would come up if we were merging a lot of work during the day. And that did interrupt that queue and that flow and became something that we had to manually work through sometimes with other developers if that was their code that we had conflicts with. And so I can see it also start to not work past...I think I mentioned that the team was 20 to 30. I would be really curious to know how far that can take a team as it grows.

+ +

JOËL: So, 20 to 30 people, this workflow works pretty well. What about sort of maybe experience level? Do you think this is a workflow that requires a certain level of seniority? You're talking about merge conflicts a lot, so maybe a team that is very disciplined with keeping their commits small. Do you think that's required to make this workflow work well for the team?

+ +

STEPHANIE: That's a great question. When I was on this team, we did have people with all experience levels. And what I really liked was that it was okay if there were merge conflicts. It was okay if CI was red. People were super helpful in jumping on to work with you to figure it out, also, because they probably had things in the queue that they were waiting to try to go out.

+ +

But it felt like a team culture where we were all committed to releasing our code smoothly. And so sometimes merge conflicts would happen, but, like I said, you usually could see it and could jump in to help out if someone was maybe stressed out about it or needed an extra hand.

+ +

JOËL: I love the process you described. And the culture that your team had didn't require everyone to get it right all the time. There's room for mistakes or not even mistakes, but just less experience where you don't always know to scope everything super tightly, or your Git process isn't quite perfect every time. And that's great for a team because there's room to grow, room to bring in people of different levels of experience.

+ +

STEPHANIE: Yeah, I also think it's more realistic.

+ +

JOËL: Oh, 100%. I'd like to look at one more axis of trade-offs, and that is product type. What kind of product do you think that this workflow you described would fit well as opposed to maybe a different type of product that wouldn't be as good of a fit? I think what comes to mind for me immediately is maybe situations where you do a lot of work upfront, but then you only want it to go live for clients later, but you do want it merged. And so you decouple the Git history from actually releasing to customers.

+ +

So that's a product lifecycle that might be a little bit different. It could be a product where you even just do big releases at set intervals. So people don't want continuous change, but you're like, once every season, we release the new version or something like that.

+ +

STEPHANIE: Yeah, I was thinking that the continuous deployment process worked well for that team who was building a product that was very customer-facing in the sense that people were visiting the site every day. And they were running a lot of A/B tests on those customers as well. And so that was helpful because we could be releasing those tests iteratively and getting continuous feedback that way.

+ +

JOËL: So, as we discussed in this episode, no process is perfect. There are always trade-offs. So I think it was really fun to look at a concrete example of a process that you liked, Stephanie, and then look at maybe some of the trade-offs for when does it work and when does it not work so well? And with that, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Joël discovered Bardcore. Stephanie planned and executed an IRL meetup for folks in the WNB.rb virtual community group in Chicago and had a consulting win.

+ +

Together, they discuss what deployment processes look like for clients in their current workloads.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Hildegard von Blingen YouTube Channel
+Hildegard von Bingen - Historical Character
+WNB.rb
+git flow

+ +

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: I've been getting into something that's kind of fun and quirky. It's a new musical genre called Bardcore.

+ +

STEPHANIE: Bardcore.

+ +

JOËL: Yes, it's basically re-mixing pop songs to make them vaguely more medieval, oftentimes using acoustic instruments, something that sounds a little bit more like maybe a lute in some flutes, oftentimes also kind of changing the lyrics a little bit to use more old-timey language. When the lyrics use words from modern life, sometimes changing them to something that would fit more in a more medieval setting. It's a lot of fun.

+ +

STEPHANIE: That sounds so fun. When are you normally in the mood to listen to Bardcore?

+ +

JOËL: It can be fun while coding because it's fairly chill as a genre. Honestly, I feel like it can also be good when I'm just sort of feeling a little bit nostalgic or daydreamy. I think it's good for that mood as well.

+ +

STEPHANIE: I love that. I can't wait to go and listen to some Bardcore after this.

+ +

JOËL: Let me recommend the YouTube channel Hildegard von Blingin' as a great entry point into the genre.

+ +

STEPHANIE: Incredible. I can't wait. In fact, I'm going to end up sharing it with all of my D&D friends too.

+ +

[laughter]

+ +

JOËL: The channel is a play on words of an actual historical character, Hildegard von Bingen, who is, I want to say, a 12th-century nun but also a polymath. So she wrote on all sorts of topics, from biology and the natural world to theology. She was a musician, just one of these like really talented people that made a mark on the medieval world. So it's kind of fun that they used her name as the inspiration for the channel.

+ +

STEPHANIE: Yeah, that sounds right up your alley. I knew that you were going to come with a historical tidbit about Bardcore. [laughs]

+ +

JOËL: Another really cool thing that I appreciate about the channel is it's not just audio. It's also beautifully illustrated. So the creator has created visuals inspired by medieval manuscripts illustrating the contents of the song. So it's kind of funny to see something that...modern pop songs aren't always the most deep lyrics, and to see them given this medieval manuscript treatment is amusing, for me at least.

+ +

STEPHANIE: That sounds really funny and also kind of calming. I was just thinking about what you said earlier about how they sometimes rewrite the lyrics to be more about medieval life. And I love the idea of taking the things that pop songs are about these days and applying them to historic life back in the day.

+ +

JOËL: A lot of pop songs also are about love, and romance, and breakups. I think that kind of fits with some of that 12th-century troubadour-style romantic songs because that was definitely the kind of thing that they were singing about back then as well.

+ +

STEPHANIE: Absolutely.

+ +

JOËL: So I've been jamming out to Bardcore this week. What is new in your world, Stephanie?

+ +

STEPHANIE: I'm really excited to share that I had an awesome weekend. One of the things that I had been doing the past couple of weeks was planning an IRL meetup for some folks in Chicago, people in the WNB.rb virtual community group. I've mentioned it on the podcast before when I was a guest. But WNB is a Ruby community group for women and non-binary folks. And we just started creating regional Slack channels.

+ +

And so I started a little Chicago channel and planned a brunch. So on Sunday, a few of us, I think it was six, some old friends and some new met up for brunch in Logan Square in Chicago. And it was really awesome to do a local meetup. I haven't done something like that since pre-COVID times, and so it felt really special.

+ +

JOËL: That's exciting. Were you big into the meetup scene pre-COVID?

+ +

STEPHANIE: So I was working remotely for a previous company when I moved back to Chicago, and so was still trying to meet people here, find a community, find some friends. And I did go to a few community groups, but that was not too soon before COVID started, and so I didn't get to really invest in them the way that I had hoped. So it's really exciting to me to potentially be able to start doing that again.

+ +

JOËL: This new meetup that you were at, was it focused more on the social aspect of things, or was it a more technical meetup?

+ +

STEPHANIE: It was definitely more of a social aspect. I would be really curious to know if that group would want to focus on some more technical things. But we had a nice diversity and experience levels and the types of work we were doing. So there were a few of us who were consultants, a few of us at product companies. And I think we shared a lot about our different experiences. We talked a bit about the pros and cons of product versus consulting.

+ +

And so it was really nice to just learn more about what other people are up to, what tech and framework people are using, and chat casually in that sense. But I also definitely see some more opportunity to focus on technical stuff if that moves us.

+ +

JOËL: I think that was probably my favorite part of Ruby meetups back when I was attending those a lot here in Boston, where I'm based, getting to chat with other developers in the city, hearing about their experiences on different topics. And oftentimes, it will sort of revolve around tech to a certain extent, but it's not always like a formal have a presentation. Sometimes just socializing is almost more fun or brings more value to me.

+ +

STEPHANIE: Yeah, I totally agree. I also wanted to share another thing that happened to me this week. It was a bit of a consulting win. So on my client project, we have been having retros every two weeks at the end of the sprint. But I was noticing with a fellow thoughtboter that we weren't really getting a lot of engagement in retros. It was kind of the same folks speaking and bringing up issues because we were doing it in a style that was like a retro board, and then folks could write in cards or raise their hand in the meeting to add something to one of the columns.

+ +

And so, we ended up proposing to do a round-robin style format for retro. And we just had our first one yesterday using that new format, and it was received really well. Everyone went around and shared things that went well. And then, we went around again and shared things to improve or risks or concerns that we had about the sprint. And it was really nice to have everyone participate, to hear folks piggybacking off of what other people said. And I think we were able to get a better sense of what the group was feeling.

+ +

And yeah, there was a new hire who was just observing our retro, and she is going to be facilitating these kinds of meetings for other teams. And she seemed really into it and wanted to bring it over to other teams as well and try it there. And so that felt really good to know that we were able to make a change that was an improvement for our team but might even have an impact on other teams at the company as well.

+ +

JOËL: I love that. I think a lot of what we often bring to the table, because we've seen things at a lot of different companies, is not just code improvements but also process improvements. Every company is different, so you can't always just copy-paste things from one place to another. But being willing to try new things, experiment, and then follow this iterative, continuous improvement approach, not just with the code but with the process as well, I think, is something that is really valuable in the work that we do for our clients.

+ +

STEPHANIE: Yeah, absolutely.

+ +

JOËL: And it sounds like here you iterated on their retro process. And everybody seems to really like this new iteration, so that sounds like a big win. Congratulations.

+ +

STEPHANIE: Thanks. I really appreciated that they were open to trying. That made me feel really good and makes me feel empowered as a consultant to be able to like you're saying, leverage that experience and suggest things that can just improve the quality of life for our clients.

+ +

JOËL: Another area that I think we've seen a lot of different ways of doing things, and we've actually been able to iterate a lot as far as process goes, is deployments. How do we get our code from, let's say, passes code review, and then, at some point, we want it to go live in production? So what does deployment look like on your current client, Stephanie?

+ +

STEPHANIE: I'm glad you asked because I'm experiencing a deployment process on this client that's actually a bit different than what I have seen before. So this client is not a super big team, but maybe, I don't know, between 30 or 50 engineers would be my guess. I am working on a smaller team with just four developers. And so I'm seeing a lot of code get merged into our big Rails app pretty frequently by other teams. And we are also merging to the same app.

+ +

So my client has release managers who rotate each day and go through all of the different teams' pull requests that are ready to be merged. They will merge those pull requests on the developers' behalf. And then once everything is merged into an integration branch, they will then merge all of that stuff into their production branch and kick off a deploy.

+ +

JOËL: Wow. So does that mean that developers on your team don't merge their code? You just when you get an approval, you ping the release manager and ask them to merge it for you?

+ +

STEPHANIE: Yeah, so developers don't merge their own code. We might move the card into ready for deployment, and that's how release managers know that that PR is ready to be merged.

+ +

JOËL: And are you then following something that's roughly like Git flow where you've got this sort of development branch, and then at some point, commits get maybe cherry-picked over to the main branch, which then gets released? Or maybe it's even a special dedicated release branch. What does that look like in terms of the Git workflow?

+ +

STEPHANIE: Yeah, we have that release branch that you mentioned that eventually gets merged, either through the GitHub GUI or a CLI by the release manager, into the main branch, essentially. And that's what then gets deployed.

+ +

JOËL: How do you handle situations where a feature goes out to production, and then you realize that there's a bug or there's something that you don't like about it, and you would like to revert that feature?

+ +

STEPHANIE: Yeah, that's a great question. This has happened to me once now, where I merged some code that ended up introducing a regression. And unfortunately, I wasn't tagged or pinged, so I didn't really know about this until the next business day and caught up with Slack and saw that someone else had to resolve my issue, which was kind of a bummer, I think, because with this process, once that code is, quote, unquote, "done," since I'm not the one merging it, and I'm not the one deploying it, I don't get a chance to follow up on the changes in production and then check to see if they look good.

+ +

When things go wrong, it seems like it kind of takes a bit of time to figure out how to get it resolved like; who would have the context? And then, if they're not available, someone else might have to jump in and fix it. So it's been interesting because, on one hand, I totally understand that they want to be releasing just once a day. Like, it's nice to have a dedicated person do all of this stuff that is work and would take away time from normal development.

+ +

But I do sometimes feel like I don't have as much ownership over my feature with this process because, like I said, it just kind of is out of my hands. And oftentimes, I might be done with my work, but that doesn't get deployed for a few days depending on other things going on with the team.

+ +

JOËL: That's interesting that you mentioned that it might not be deployed for a few days even though it's done and maybe merged. I think, generally, we assume that merging a commit into the main branch and deploying it are going to be more or less the same thing.

+ +

But oftentimes, you might end up in a situation where there's a feature that's done in development, but we don't want it to actually go live for our customers for a while yet. And that might be for technical reasons because we're waiting for other pieces to be in place, or it might be for business reasons because we did the work, but this feature has to come out on a particular date, and so that's when it's going to go live.

+ +

So then you end up in that awkward situation, maybe where you want to deploy something else. But you've got a commit already on the master branch that can't go out with the others. And you've got to do an awkward cherry-pick. Have you ever been in that situation?

+ +

STEPHANIE: I have. I remember being on a project where we had features in our main branch, but that hadn't been deployed to users yet. We actually didn't want that to be live yet but then had an issue with an existing feature that was already live that we had to make a hotfix for. And that was definitely one of those cherry-picking situations that did become a bit hairy and wasn't too fun. It sounds like you have had experience with that type of deployment process as well.

+ +

JOËL: Yes, I think of a project where that was a very common problem because there were a lot of features on that project that were gated to a particular time. So a lot of the features going live for customers were decoupled to the actual development lifecycle. And on that particular project, we used a lot of feature flags on the commits. So we'd control whether or not a feature was live for the customer. It wasn't, is this commit in the main branch, but it was, is this feature flag on or off?

+ +

STEPHANIE: Yeah, we're using feature flags on this client project as well. And so, in some ways, I think that if we did have a more continuous deployment process, it would be okay because this big feature that I'm working on on my team we're not trying to go live until a month from now, but we have been slowly, incrementally pushing features underneath the flag. But even then, we do still have a bit of an async process because of this daily release flow.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: How do you feel about continuous deployment in general?

+ +

STEPHANIE: So the reason why I found the way I've been describing so surprising is because I am more used to a continuous deployment flow. When I used to work for a product company, and we were a team of, I don't know, like 30 engineers, we'd merge our own work. And then our main branch would automatically be deployed. And so we could make sure our changes looked good in production and then feel a sense of we finished this feature. But we did also run into problems there because our CI build time which had to run for every single time that code was merged into main, took maybe 20-25 minutes.

+ +

So whenever we merged to main, we would have to wait for CI to build, wait for the deploy to go through, and that might be a few extra minutes depending, and then confirm our changes. And that became more of an issue when there was a backup in the queue of a lot of people trying to merge code. And it's funny because we kind of want to be constantly merging. That's kind of a sign that things are moving along.

+ +

And it ended up being that deployment was the bottleneck in some instances, especially if there was a CI build that broke, and then it was kind of like a car crash a little bit where there was this huge backup. That wasn't great either because when you have to babysit your deploy like that, I didn't find that I had a ton of focus time to go and pivot to something else. I was just keeping an eye on things the whole time.

+ +

JOËL: Would you have preferred a workflow that maybe didn't run on every commit but maybe ran once every 30 minutes and just bundled any commits that happened within that? So maybe it's one commit, maybe it's four. Or would you have maybe preferred one where you didn't run the tests before deploying? You're just like, you know what? We trust that we ran them on the branch. It's good. We can just go straight to production.

+ +

STEPHANIE: Well, that idea, the second one of not running tests before deploying, I've never even thought about that. I think that it does provide some value because when you integrate changes into main, sometimes that might cause unexpected issues. So I think, in my experience, the times when CI failed, it usually was for a valid reason, and it wasn't just a blocker that we then had to retry the build for.

+ +

But what you were saying about bundling commits or a set of changes and then deploying on a scheduler maybe a few times a day automatically, that sounds really interesting to me. I have never worked on a team that has done it that way. But that sounds like it could be a good, happy medium between the two processes.

+ +

JOËL: I think that's effectively what the release manager is probably doing manually. But if there was a way to just do that automatically where you just say you merge to the main branch anytime you want, but on a timer every 30 minutes, the latest main will be run on CI, and if it's green, it will get promoted to production.

+ +

STEPHANIE: I think there's still a sense of whose job is it to follow up if something goes wrong in that sense.

+ +

JOËL: That's a good point. I think part of that is also it's a coping mechanism because of the slow test suite. We have a big process smell here, and we're trying to find some ways to get around it. And one way where I don't think any amount of process is going to help is when you have to do a hotfix.

+ +

So let's say there's a really bad bug in production. We need to get that fix out now, and so I make that fix. I live ping you to review it. We get it done in like 10 minutes, and we merge. And now we've got to wait 20 minutes for CI to pass before we can make that patch go live. And we're really hoping this test suite is not flaky because if not, we might be waiting another 20 minutes.

+ +

And so, in a sense, a slow test suite becomes a huge bottleneck to fixing emergency things. And now we're going to be tempted to say, "This is an emergency. We're going to bypass CI and just ship directly to production because this is on fire. We are corrupting customer data or something. This needs to be fixed now." And hopefully, we did not make the problem worse in our hotfix because we were rushing, which I have definitely done.

+ +

Luckily, in these situations, it has gotten caught by CI. But there have been situations where I've tried to do a quick hotfix that I thought was going to fix things, and then CI caught it, and I was like, I'm glad I didn't just put that directly in production.

+ +

STEPHANIE: Yeah, I think what I've come to realize is that the current process that I am experiencing on my client project, you know, I'm sure there's some history there about how it came to be and why they decided to do it that way. And that might be an artifact of something going wrong and them trying to put guardrails to prevent problems from showing up in production. So I do have some understanding there.

+ +

So if anyone out there has a deployment process that they love, I would love to hear about it. You can tweet us @_bikeshed or send us an email to let us know if you have a deployment process that works well for your team.

+ +

JOËL: Maybe we'll even feature it on a future episode.

+ +

STEPHANIE: Yeah, definitely.

+ +

JOËL: I'd like to get into some of the trade-offs that come with different processes, and one that jumps out at me from what you were talking about earlier is the impact of team size. With a smaller team, when you're, you know, 2,3,4,5 developers, you can have a really simple Git-based approach where merging a PR goes directly onto your main branch and maybe even have it set up to automatically deploy, and that's kind of it. If a commit is on main, it is live in production. And if you want to undo something, you just Git revert, and that goes live. And that's a really simple, effective workflow.

+ +

But then, as the team starts growing, you start needing something a little bit fancier because there are a lot of commits coming out at once. They might have dependencies on each other. Reverting becomes a little bit more complicated. As the product gets more complicated, too, then you start having to want to have work that's done, but you don't want to just have a PR sitting around waiting until go-live day. So I think that's definitely an axis to think of when you're thinking of trade-offs is some workflows work very well for smaller teams and others are a better fit for larger teams.

+ +

STEPHANIE: Absolutely. I think when you were talking about smaller teams, almost everyone has knowledge about what is currently being worked on. And so when problems do happen, that work of reverting or figuring out what went wrong isn't as hairy because most folks on a small team would know what changes are being merged and can pitch in to help there.

+ +

But yeah, I am really interested in the transition between a small team where you feel comfortable just merging the code and having the automatic deployment and when you do need to have a heavier-handed solution, I suppose. Do you think that there's an inflection point that pushes that decision to be made?

+ +

JOËL: I'm not sure exactly where that inflection point is. I might say as low as maybe 5 or 10 developers on your team, but there are probably some other variables that go along with that. Part of it might even be how good your team is at keeping commits small and focused, and independently deployable. If your team is committing really large commits that potentially break the build or that are tightly coupled to other commits, that might make it really difficult to say that your branch is always deployable. And so, you might want to bring in a heavier process earlier.

+ +

Whereas if your team is doing a lot of small, atomic commits, which I think we discussed this on last week's episode, I think that could probably allow you to get a lot more mileage out of a very simple workflow where even with a slightly larger team, you're still able to just merge and deploy and also potentially revert very easily because these are atomic commits.

+ +

STEPHANIE: Yeah. I like what you said about how you can get away with a lighter solution if you are really investing in things like making sure that each commit is green on CI. Because, you know, kind of what we were saying earlier, sometimes adding additional process without really figuring out what we're trying to solve here can lead to some of those trade-offs that we're talking about.

+ +

JOËL: Agreed. I'm a big fan of using the simplest process that your team can get away with. Maybe we could even extend that more generally to just use the simplest thing that your team can get away with. I think that goes for code complexity, that goes for maybe code optimization. Don't make it more complex just because you're hoping to have this massive scale one day because you don't need it today. So use a process that works for your team at your current team size, and then you can iterate on that and start adding more complex elements as the team starts growing.

+ +

So, Stephanie, I'm curious; we've talked about a lot of different types of deploy processes. What would be your ultimate favorite way to handle deploys if you had the choice?

+ +

STEPHANIE: I think I do prefer a more automated process. When I was on a medium-sized team, that was working pretty well for us. We were having deploys be kicked off when we merged to main, but then we had a Slack integration that would tell us, "Hey, your thing is being deployed." It would tell us the results of the CI build, and it would tag us if something went wrong. And so I think that was nice in solving that issue of ownership that I had mentioned where I knew that, oh, there was an issue. I have the most context, and I can solve it the most quickly on this team.

+ +

And then it was also good to just see what was going out, see what other people were working on. I liked that it made that very transparent. And that sense of feeling like you saw your feature from start to finish and seeing it live on production felt really good and gave me meaning in my development work.

+ +

JOËL: Yeah, that sounds like it hits a lot of really positive values, like you said, that ownership that you have from beginning to end, even with maybe the revert if something has to happen, the transparency where you get to see if any issues came through. And then the automation and the simplicity because it's just merge your PR and the work goes out.

+ +

Earlier in the episode, we were talking about trade-offs that come with a workflow. So a workflow like what you're describing, what size team do you think would be best suited for a workflow like that?

+ +

STEPHANIE: Yeah, I don't know if I have an exact number. I did mention that medium-sized team seemed to feel pretty good where we did have some investment in the infrastructure in place, so, like you were saying, we had guardrails when things went wrong. But it wasn't so much for a really large team where it would have been too noisy in the Slack channel.

+ +

And also, merge conflicts would come up if we were merging a lot of work during the day. And that did interrupt that queue and that flow and became something that we had to manually work through sometimes with other developers if that was their code that we had conflicts with. And so I can see it also start to not work past...I think I mentioned that the team was 20 to 30. I would be really curious to know how far that can take a team as it grows.

+ +

JOËL: So, 20 to 30 people, this workflow works pretty well. What about sort of maybe experience level? Do you think this is a workflow that requires a certain level of seniority? You're talking about merge conflicts a lot, so maybe a team that is very disciplined with keeping their commits small. Do you think that's required to make this workflow work well for the team?

+ +

STEPHANIE: That's a great question. When I was on this team, we did have people with all experience levels. And what I really liked was that it was okay if there were merge conflicts. It was okay if CI was red. People were super helpful in jumping on to work with you to figure it out, also, because they probably had things in the queue that they were waiting to try to go out.

+ +

But it felt like a team culture where we were all committed to releasing our code smoothly. And so sometimes merge conflicts would happen, but, like I said, you usually could see it and could jump in to help out if someone was maybe stressed out about it or needed an extra hand.

+ +

JOËL: I love the process you described. And the culture that your team had didn't require everyone to get it right all the time. There's room for mistakes or not even mistakes, but just less experience where you don't always know to scope everything super tightly, or your Git process isn't quite perfect every time. And that's great for a team because there's room to grow, room to bring in people of different levels of experience.

+ +

STEPHANIE: Yeah, I also think it's more realistic.

+ +

JOËL: Oh, 100%. I'd like to look at one more axis of trade-offs, and that is product type. What kind of product do you think that this workflow you described would fit well as opposed to maybe a different type of product that wouldn't be as good of a fit? I think what comes to mind for me immediately is maybe situations where you do a lot of work upfront, but then you only want it to go live for clients later, but you do want it merged. And so you decouple the Git history from actually releasing to customers.

+ +

So that's a product lifecycle that might be a little bit different. It could be a product where you even just do big releases at set intervals. So people don't want continuous change, but you're like, once every season, we release the new version or something like that.

+ +

STEPHANIE: Yeah, I was thinking that the continuous deployment process worked well for that team who was building a product that was very customer-facing in the sense that people were visiting the site every day. And they were running a lot of A/B tests on those customers as well. And so that was helpful because we could be releasing those tests iteratively and getting continuous feedback that way.

+ +

JOËL: So, as we discussed in this episode, no process is perfect. There are always trade-offs. So I think it was really fun to look at a concrete example of a process that you liked, Stephanie, and then look at maybe some of the trade-offs for when does it work and when does it not work so well? And with that, shall we wrap up?

+ +

STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

JOËL: This show has been produced and edited by Mandy Moore.

+ +

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

+ +

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

+ +

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+vS712UEZ + + ]]> + + Joël Quenneville + Stephanie Minn + + + 362: Prioritizing Learning + https://bikeshed.thoughtbot.com/362 + 49582cc3-8f43-41cd-8ac5-17c69454995a + Tue, 15 Nov 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + This week, Steph and Joël discuss investment time and keeping track of things they want to learn. + +How do you, dear listener, keep track of things you want to learn? When investment time rolls around, what do you reach for, or how do you prioritize that list? Are there things you actively decide not to focus on when choosing where to develop deep expertise? Are there things you wish you could spend time on if you could? + 29:40 + no + + + This week, Steph and Joël discuss investment time and keeping track of things they want to learn. +How do you, dear listener, keep track of things you want to learn? When investment time rolls around, what do you reach for, or how do you prioritize that list? Are there things you actively decide not to focus on when choosing where to develop deep expertise? Are there things you wish you could spend time on if you could? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Bloom's Taxonomy (https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/) +thoughtbot's interview (https://thoughtbot.com/playbook/our-company/hiring#interviewing) +3 categories of learning (https://thoughtbot.com/blog/what-technologies-should-i-learn) +Four Thousand Weeks: Time Management for Mortals (https://www.amazon.com/Four-Thousand-Weeks-Management-Mortals/dp/B08XZY5ZF7/ref=sr_1_1?gclid=CjwKCAiA9qKbBhAzEiwAS4yeDZvBGi9yS1YkifUNcf0j8jx3s-NKc1pw5itLKSjI1vOfzlYJCuRNFRoC7ioQAvD_BwE&hvadid=599682518804&hvdev=c&hvlocphy=9006718&hvnetw=g&hvqmt=e&hvrand=3741098155096216457&hvtargid=kwd-1661352592925&hydadcr=28547_10703911&keywords=the+four+thousand+weeks&qid=1667835268&sr=8-1) +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 little bit of what we've learned along the way. +STEPHANIE: So, Joël, what's new in your world? +JOËL: I was recently having a conversation with another colleague at thoughtbot, and they brought up Bloom's Taxonomy, which is a taxonomy of different phases of learning. It's often visualized as a pyramid with a broad base that starts with remembering facts and then expands up to understanding and then up to applying, and then analyzing, evaluating, and then finally creating. So it's a way to kind of quantify progression of someone who is trying to master a topic. +And what really struck me when I saw this diagram was I immediately thought about how the tech industry interviews and a lot of our interviews are focused on the base of that pyramid. It's all about did you memorize certain facts, or APIs, or things like that? But a lot of the value that we create as developers...but to be good at our jobs, we have to actually be active much higher up in that pyramid in the analyze, evaluate, and create layers. +But unfortunately, I feel like interviews often don't go that far; they're really just focused on the base. So that was a really interesting realization. We were not talking about interviewing, but this colleague shared the diagram. I looked at it, and the first thing I thought was like, oh, this is the problem with a lot of tech interviews these days. +STEPHANIE: Yeah, I think a lot about how in interviews, we want to be showing off our best selves in a sense. Like, we want our interviewers to see the version of ourselves that we bring to work, which is usually like you were saying, at that top layer and isn't recalling particular facts about how our framework works or things we might have learned in computer science class in college. +And one thing I actually really like about thoughtbot's interview...even in the job application, I think it says, "We want to see your strengths and see you at your best self." And it asks what can we, as thoughtbot, interview you on in a way that gives you the opportunity to display those skills? And so I really like that. +I think I remember when I submitted that application, I might have said something along the lines of debugging a problem because I think that's where I personally shine. I don't know if it ended up being a conscious thing. But I do remember when I was doing the pairing interview, there was an aspect of debugging, and I was like, yes, this is where I can show off what I would normally do in a real-life work situation. So that really resonates with me. +JOËL: Debugging is such a core developer skill, and yet I feel it's not often something that we dig into in a process like an interview. Sometimes you have almost like a code review style where you've got, oh, there is one bug hidden in here, find it, and it's almost like a gotcha sort of thing. I don't like those. But a real situation where you could show off your problem-solving and debugging skills sounds like a really good way to play to your strengths. +STEPHANIE: Yeah. Where else do you think that higher level of critical analysis and creative output shows up in your day-to-day work? +JOËL: I think it has to pervade the day-to-day work. The majority of my job is not remembering what method from enumerable is used to sort an array; it's trying to find a way to translate a problem that the business has into code or a code solution that will satisfy quite a lot of different constraints. This might be something that is doable in one or two days because that's all we have to allocate to this problem. +So a lot of that work could be scoping down a problem. There might be some performance-related constraints where it needs to be faster than X. There are certainly some correctness constraints as well that you're trying to work within. So all of that, I think, is much more at that analysis, evaluation, and creation layers of the pyramid. +STEPHANIE: Yeah, that's a really good point. I think sometimes I've seen interviews try to replicate that or recreate it in an interview question, even though they may be genuinely based off of real-life experiences that companies might have had. But most often, it's really hard to be evaluated on that situation until you're really just doing that work. +JOËL: It is really hard to translate that into an interview format. I think one aspect that I do appreciate, and maybe that's just the consultant in me but having a conversation about trade-offs in a situation where there isn't a single correct answer. And so, maybe the interviewer and the candidate have different conclusions. But as long as they can show their reasoning down that path of why they came to the conclusion that they did, I think that's the important part of that. +The hard thing is if the interviewer has their preferred solution, and they're just like, "No, you didn't come to my conclusion," then that's not a good interview. But a situation where a candidate gets to demonstrate their critical thinking skills, their analysis skills, their ability to make difficult decisions to balance trade-offs, I think that's a great way to show off some of those high-level skills that honestly we use on a daily basis. +STEPHANIE: Yeah, I agree 100%. +JOËL: So that's what I've been kind of excited about recently, just seeing this diagram and having that moment of clarity about interviewing. What's something new in your world, Stephanie? +STEPHANIE: That's really interesting that you brought that up because it's kind of related to what I was going to say about what I've been working on on my client project, which is the ambiguity of the rewrite. So I mentioned last week that I've been rewriting some Rails views. And we're working on a pretty old legacy application, so there are a lot of things that, as we're rewriting, we need to figure out whether or not we want to include it in the new version. +So it's been a little more challenging than just copying over the functionality that you want because there are a lot of things in this legacy app that were written 10-12 years ago that we don't have any context on, especially as consultants and even the people we're working with on this team, the code might even predate them. +So we do our best to ask them questions about, hey, is this still necessary? Do you think we want it in this rewrite? And they don't always know the answers. And so we have to make our best judgment and make a lot of micro-level decisions about what we think is important to bring into this rewrite without a ton of that historical context. So when you were talking about those analytical, critical thinking skills, that seemed like a very relevant experience that I would say has been utilizing those aspects of learning. +JOËL: Definitely, especially for a codebase that is that old. I feel like ten years is almost like a generation in software developer terms. Ten years ago would be what? 2012. That's Rails 3 still. I forget when Rails 4 came out. But yeah, that's a long time ago when you talk about technology. And at a company, even the odds of someone sticking around for that long are very low. +STEPHANIE: Absolutely. And so sometimes we just choose to leave the code as it is, and we will just copy and paste it. But other times, we might try to rewrite it in a more modern way. One thing that we did recently was migrate a hand-rolled form builder to use Simple Form. And we did our best to retain most of the original functionality. But there were aspects of it, things like browser validation and stuff like that, that had to change because we made the conscious decision to use a more modern form builder. +But then there were always going to be some differences, and so we had to reconcile those with the product team, have a lot of communication around what was important to keep and what wasn't. And yeah, really, just try to get the code in a better spot if we can while also acknowledging that some things have been working for ten years, and that's okay too. +JOËL: So you're talking about a lot of old code that you're working with and seeing how much things have changed over ten years. And I feel like, as software developers, we're constantly having to learn and hone our skills, but it can really be overwhelming because there's so much to learn. How do you prioritize what you want to learn next? +STEPHANIE: At thoughtbot, we're lucky enough to have investment times. So typically, on Fridays, most of us will not be working on client work, but we'll be working on things to improve thoughtbot internally or improve ourselves professionally. So I'm really grateful that I have dedicated learning time, and figuring out how to spend it has been both fun and also fraught in a way because like you were saying, there are so many things I want to learn about, and we internally have so much lively discussion about really cool technical things. +But I've kind of accepted that I'm not going to be able to learn it all. And so when Friday does roll around, I do have to figure out, okay, how do I want to spend my precious investment time today? For me, it honestly feels really dependent on how I'm doing that Friday. So I do have a bit of a backlog of talks and articles that I've collected along the way or bookmarked that I might come back to if that is the mode I'm in. I also have bigger themes, I think, around frameworks and technologies that I want to dig a little more deeply into. +I've been trying to work through a TypeScript tutorial for a while now, especially because it's not something that I've gotten a chance to spend a ton of time on in client work. And so in some ways, it's like, well, if I want to work on a client project using TypeScript, then I feel like I should brush up on TypeScript first. So that's kind of in the back of my head is just a more nebulous goal. But I also think that it really changes depending on how I'm feeling throughout the year. It could be very well that the TypeScript thing never comes to fruition and maybe something else will grab my attention. +JOËL: I'm sure there are lessons, though, that you would learn from TypeScript that you could then use to improve your day-to day-work on a Rails project, for example. +STEPHANIE: Yeah, absolutely. I think that's the really cool thing is that everything I learn in some way can connect to other things that I do know, or experience, or come across during my everyday work. So none of it ever feels like a waste of time. I think the best feeling is when you can make that connection as you are experiencing something in the codebase that reminds you of something you read about in a blog post or something like that. +JOËL: Connections are one of the most crucial parts of, I think, knowledge creation. And in a past episode on note-taking, we had a whole deep conversation about how sometimes making connections between some of your notes is almost more valuable than taking a note by itself. +STEPHANIE: Joël, how do you prioritize your learning? +JOËL: I have three broad categories of technical learning that I like to do. The first is anything related to my core language and framework, and as of right now, that is Ruby, Rails. And maybe a little bit more broadly, anything related to the paradigms related to that, so object-oriented design, patterns related to that, all things that will help me to write better Ruby and Rails code. +Then there are evergreen skills that are always great to invest in, things like getting better at Git, learning a little bit of SQL, getting better at doing things on the command line. Those are all things that I look to level up every now and then. And then, finally, just whatever interests me right now. I find that the return on investment for the amount of time you put in versus the amount of knowledge you get out is much higher when I'm personally interested. +So it might be something completely unrelated to maybe more strategic elements of tech that I'm trying to get, but if I'm interested, it's worth putting a little bit of time into that. And so, for me, several years ago, that was functional programming types. Elm, I went really deep into that. And I think that really unlocked a whole other way of thinking about software for me and helped me...like we were saying earlier, I was able to bring that back to the way I think about Rails applications, the way I think about test-driven development. And that really rounded out my thinking, I think. +STEPHANIE: Yeah, I think focusing your energy into where you're interested in makes it easier, for sure. It makes it more fun. I think like you're saying, your learning gets accelerated. And I think it's also really cool that people have different interests that they do like to go deep on. So maybe you might be thinking that you should focus your energy on this other aspect of development that you think would be really cool or useful in your work but doesn't necessarily interest you that much. Chances are that there's someone else who loves learning and talking about it, and you can use them as a resource when you want to know more. +JOËL: That is a really important aspect because learning is not necessarily a solo activity. So sometimes, maybe I'm not even just prioritizing things that I think are strategically good for me or even things I'm just interested in. It might be things that my colleagues are interested in. So we have a book club that we run at thoughtbot. We've been going through the book Ruby Science, and there have been some great discussions around that. Recently, we've also been doing watch parties for episodes of I know it is RubyTapas by Avdi Grimm, but I think it rebranded recently, and I forget the new name of it, Graceful...I think Graceful.Dev. +STEPHANIE: Graceful Devs, I think, yeah. +JOËL: So we've been watching some of these together as a team and then having a conversation afterwards, so that's also been great. +STEPHANIE: That's really cool. Yeah, I think getting other people involved makes it a lot more fun. And you have an accountability buddy. And you can have those deep, thoughtful conversations about the things you've learned. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: I'm curious, have you ever made a conscious effort to not focus on something super deeply? +JOËL: I don't know that I've made a decision to be like, I will not spend time here. But I've definitely made a decision to I will invest here and maybe not care quite as much there. So I've done quite a bit of different front-end technologies, starting with jQuery and Backbone.js and moving through a lot of the frameworks. Somehow I have not yet done much React. It's sort of a big hole in that list of frameworks that I have worked with. It's just not something that I've prioritized. I've done other things. I've learned concepts that I think mirror a lot of what React does, but that's not been something that I've dug into. +STEPHANIE: That's really interesting because I think a lot of people think that they need to learn React because it's the popular front-end framework of the time. And so they think that it's something that they should know, or if they do ever have to work on a project with React, that kind of contributes to that feeling. But I like what you were saying earlier about how you have experience with other front-end frameworks. And that can help inform you if you ever do have to work in it. And also, there are so many great expert React devs out there. Like, we don't have to all be that dev. +JOËL: Yeah. I think there can definitely be a pressure to feel like you have to know it all. And a lot of these tech stacks are changing so quickly that it becomes overwhelming to try to just keep up with everything. +STEPHANIE: For sure. I remember having to write some tests for a React app, and the things that I had learned several years ago using Enzyme or something were no longer as relevant today, and having to pick up on the new best practices for writing Jest tests and React Testing Library. It was a lot, even though I was able to identify aspects of it that lined up with what I knew. It can be overwhelming, for sure. And people spend a lot of time digging deep into this framework and like I said, becoming those experts and accepting that I probably won't be that person [laughs] was also a little bit liberating, I think. +JOËL: It's also important, I think, to accept that these sorts of labels of I'm that person, or I'm not that person are not permanent. It's I'm not that person now because that's not where I want to prioritize my time. Maybe in two or three years, it will make sense for me to become that person. And I can become that person if I put in the time, but today is not the day for me to be that person. +STEPHANIE: That's a really good way of putting that. I like that a lot. +JOËL: One struggle that I have, and I've seen a lot of people too is that it's easy to get very scattered in your learning that you'll have a lot of different things you're trying to learn at the same time or you feel like you want to do a little bit of this and a little bit of that. And then maybe you don't go very deep in any of them and feel like you're not being very effective with your time. Do you ever feel that, and do you have any strategies you like to use to make the most out of your learning time? +STEPHANIE: I really relate to that. And I think one resource that helped me reframe that conundrum if you will, was this book called Four Thousand Weeks: Time Management for Mortals by Oliver Burkeman. It was really interesting because it kind of turned productivity culture around a bit on its head because his whole thesis is that you won't achieve at all and that by trying to hack your own productivity, what you're really preventing yourself from doing is accepting the fact that time is finite. And that you have to make hard decisions about where to focus your time in a way that will enrich your life the most. +And sacrifice the idea that you will get to do everything on your to-do list, that you will learn every framework that you want to learn. And it's still hard for me to totally accept that. But I think I'm inching towards the idea that if I do drop a ball on something that I have had bookmarked for at this point, you know, a year, I'm probably never going to get around to reading that. And that's okay because I'm still getting by with the things that I am learning and applying them in the aspects of my work that are relevant to me today. +JOËL: That sounds like a really refreshing take on productivity culture, maybe with some hard truths in there as well. Is 4,000 weeks the human lifespan? +STEPHANIE: [laughs] Yeah, it is. It's really funny because I think he even starts off in the book quizzing one of his friends, like, how many weeks do you think we have to live? And his friend very naively answered, "Oh, must be, you know, 500,000 or so," or something like that. But he used that as an illustration of how we inflate how much time we think that we might have in a day, a week, our lifespan. [laughs] +JOËL: I'm a big history nerd in my personal time. You see this theme that comes up a lot in medieval European art and the 1400s after a lot of these big plagues have happened where they feature a lot of death or skeletons or those sorts of motifs that are much more prevalent than maybe an earlier art, and this idea that comes with a Latin phrase Memento Mori (remember death). And I think there's maybe an element of that that comes back into this book at least the way you were describing it, the idea that you only have 4,000 weeks, roughly, in your life, so make the best use of it. +STEPHANIE: Yeah, absolutely. It's nothing new, for sure. I think it's just one of those things that we've been grappling with as a species for as long as we've existed. [laughs] So I don't know if anyone out there feels slightly relieved that it's okay for them not to get through their list of bookmarked articles about technical things. I hope that feels slightly better for you. +JOËL: We give you permission for you, the audience, to go to your bookmarks and those articles that you've been meaning to read for two years and you haven't got to; it's okay to remove them. You will be okay. +STEPHANIE: Agreed. So we've talked about how we spend our investment time. But I'm curious, do you have any strategies for people who do most of their learning in their everyday work? +JOËL: You know, I think that applies to me as well. We've been heavily emphasizing investment time, but that's only one day a week. And four days a week, I am doing regular application development for clients. And so the majority of my hours in a week are going to be dedicated to that. I find that being very self-aware for the things that you do and trying to notice when I learn something new or when I interact with something new has really helped me get more out of my day-to-day work. +And a way to level that, I think, is to be on the lookout for opportunities to share with others. And that can be as small as just put a today I learned message in a group chat, maybe in thoughtbot's Slack developer channel, and just say, "Hey, today I learned this interesting thing about a particular method." Or "Today I learned this weird thing about time zones." Or "Today I learned this interesting fact about testing." And then that might start a discussion, or it might not. But the fact that I took the time to take it out of my head and write it out, I think, makes that more concrete, and it helps me hold on to it. +STEPHANIE: I've noticed you are really good about doing that, about sharing things that you encounter in your everyday work in a very low-stakes kind of way. I am not so good at doing that. I tend to be so steeped in client work, and I have to really intentionally, after a project is over, think about what I learned along the way. And oftentimes, they're not as small, incremental atomic bits of information but bigger picture things about, oh, I learned how to navigate this aspect of ambiguity. +And maybe the next time, I can point to a past experience or lean on a little bit more on my gut instinct to guide me towards making the right decision. And I think that's an important aspect of learning too, even if it wasn't necessarily a technical tidbit. It is part of becoming a better developer, just as equally as gaining that more concrete technical knowledge. +JOËL: Intuition, I think, is really important as developers, and honing that intuition is something that is really valuable. One way that I found helpful is dialogue, just a conversation with one other person, maybe it's asynchronous over Slack, maybe it's a call in person, and just talking through an idea that I have. +A recent one and I think I mentioned this on the previous episode of The Bike Shed, was talking about RSpec matchers. And does your choice of matcher impact the sorts of design that will come out of the code that you write? Does EQ tend to push you in a direction maybe where you're less strongly encapsulating data? And so that's just a thought, and then you have a conversation about it. And then that can help sharpen your intuition so that the next time you're writing a test you're not just thoughtlessly bringing in a matcher because whatever; it's the thing to do. +And initially, maybe it's not intuition; it's much more explicit. You're thinking, ooh, do I want EQ, or do I want not? But I imagine that after six months of me being hyperaware of that, I will have built up some intuitions to be like, oh, this is the place where we want a custom matcher, or here's the place where I want EQ. +And my hope is that that will eventually come to the point where it's so natural. Someone would almost have to stop me and say, hey, wait, why are you choosing that? And then I have to think a little bit and be like, oh, it's because of these things. But I'll have started with a conversation, which then turned into just hyperawareness thinking about it every time I do that action which then turns into intuition. +STEPHANIE: Yeah. I think you can also call that experience. I remember having a conversation with someone, and I told them that I could inject their brain with all of the knowledge and information that I had. But that isn't quite the same as having really experienced the process of gaining that knowledge through more conventional learning methods but also that day-to-day client work that you're doing. So I totally agree with you there. +JOËL: You took this whole long thing I had to say and were able to condense it down to one word: experience. +STEPHANIE: [laughs] +JOËL: Which I think, yeah, exactly describes what I'm trying to say. And with that, shall we wrap up? +STEPHANIE: Let's wrap up. +JOËL: The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. +Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + This week, Steph and Joël discuss investment time and keeping track of things they want to learn.

+ +

How do you, dear listener, keep track of things you want to learn? When investment time rolls around, what do you reach for, or how do you prioritize that list? Are there things you actively decide not to focus on when choosing where to develop deep expertise? Are there things you wish you could spend time on if you could?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I was recently having a conversation with another colleague at thoughtbot, and they brought up Bloom's Taxonomy, which is a taxonomy of different phases of learning. It's often visualized as a pyramid with a broad base that starts with remembering facts and then expands up to understanding and then up to applying, and then analyzing, evaluating, and then finally creating. So it's a way to kind of quantify progression of someone who is trying to master a topic.

+ +

And what really struck me when I saw this diagram was I immediately thought about how the tech industry interviews and a lot of our interviews are focused on the base of that pyramid. It's all about did you memorize certain facts, or APIs, or things like that? But a lot of the value that we create as developers...but to be good at our jobs, we have to actually be active much higher up in that pyramid in the analyze, evaluate, and create layers.

+ +

But unfortunately, I feel like interviews often don't go that far; they're really just focused on the base. So that was a really interesting realization. We were not talking about interviewing, but this colleague shared the diagram. I looked at it, and the first thing I thought was like, oh, this is the problem with a lot of tech interviews these days.

+ +

STEPHANIE: Yeah, I think a lot about how in interviews, we want to be showing off our best selves in a sense. Like, we want our interviewers to see the version of ourselves that we bring to work, which is usually like you were saying, at that top layer and isn't recalling particular facts about how our framework works or things we might have learned in computer science class in college.

+ +

And one thing I actually really like about thoughtbot's interview...even in the job application, I think it says, "We want to see your strengths and see you at your best self." And it asks what can we, as thoughtbot, interview you on in a way that gives you the opportunity to display those skills? And so I really like that.

+ +

I think I remember when I submitted that application, I might have said something along the lines of debugging a problem because I think that's where I personally shine. I don't know if it ended up being a conscious thing. But I do remember when I was doing the pairing interview, there was an aspect of debugging, and I was like, yes, this is where I can show off what I would normally do in a real-life work situation. So that really resonates with me.

+ +

JOËL: Debugging is such a core developer skill, and yet I feel it's not often something that we dig into in a process like an interview. Sometimes you have almost like a code review style where you've got, oh, there is one bug hidden in here, find it, and it's almost like a gotcha sort of thing. I don't like those. But a real situation where you could show off your problem-solving and debugging skills sounds like a really good way to play to your strengths.

+ +

STEPHANIE: Yeah. Where else do you think that higher level of critical analysis and creative output shows up in your day-to-day work?

+ +

JOËL: I think it has to pervade the day-to-day work. The majority of my job is not remembering what method from enumerable is used to sort an array; it's trying to find a way to translate a problem that the business has into code or a code solution that will satisfy quite a lot of different constraints. This might be something that is doable in one or two days because that's all we have to allocate to this problem.

+ +

So a lot of that work could be scoping down a problem. There might be some performance-related constraints where it needs to be faster than X. There are certainly some correctness constraints as well that you're trying to work within. So all of that, I think, is much more at that analysis, evaluation, and creation layers of the pyramid.

+ +

STEPHANIE: Yeah, that's a really good point. I think sometimes I've seen interviews try to replicate that or recreate it in an interview question, even though they may be genuinely based off of real-life experiences that companies might have had. But most often, it's really hard to be evaluated on that situation until you're really just doing that work.

+ +

JOËL: It is really hard to translate that into an interview format. I think one aspect that I do appreciate, and maybe that's just the consultant in me but having a conversation about trade-offs in a situation where there isn't a single correct answer. And so, maybe the interviewer and the candidate have different conclusions. But as long as they can show their reasoning down that path of why they came to the conclusion that they did, I think that's the important part of that.

+ +

The hard thing is if the interviewer has their preferred solution, and they're just like, "No, you didn't come to my conclusion," then that's not a good interview. But a situation where a candidate gets to demonstrate their critical thinking skills, their analysis skills, their ability to make difficult decisions to balance trade-offs, I think that's a great way to show off some of those high-level skills that honestly we use on a daily basis.

+ +

STEPHANIE: Yeah, I agree 100%.

+ +

JOËL: So that's what I've been kind of excited about recently, just seeing this diagram and having that moment of clarity about interviewing. What's something new in your world, Stephanie?

+ +

STEPHANIE: That's really interesting that you brought that up because it's kind of related to what I was going to say about what I've been working on on my client project, which is the ambiguity of the rewrite. So I mentioned last week that I've been rewriting some Rails views. And we're working on a pretty old legacy application, so there are a lot of things that, as we're rewriting, we need to figure out whether or not we want to include it in the new version.

+ +

So it's been a little more challenging than just copying over the functionality that you want because there are a lot of things in this legacy app that were written 10-12 years ago that we don't have any context on, especially as consultants and even the people we're working with on this team, the code might even predate them.

+ +

So we do our best to ask them questions about, hey, is this still necessary? Do you think we want it in this rewrite? And they don't always know the answers. And so we have to make our best judgment and make a lot of micro-level decisions about what we think is important to bring into this rewrite without a ton of that historical context. So when you were talking about those analytical, critical thinking skills, that seemed like a very relevant experience that I would say has been utilizing those aspects of learning.

+ +

JOËL: Definitely, especially for a codebase that is that old. I feel like ten years is almost like a generation in software developer terms. Ten years ago would be what? 2012. That's Rails 3 still. I forget when Rails 4 came out. But yeah, that's a long time ago when you talk about technology. And at a company, even the odds of someone sticking around for that long are very low.

+ +

STEPHANIE: Absolutely. And so sometimes we just choose to leave the code as it is, and we will just copy and paste it. But other times, we might try to rewrite it in a more modern way. One thing that we did recently was migrate a hand-rolled form builder to use Simple Form. And we did our best to retain most of the original functionality. But there were aspects of it, things like browser validation and stuff like that, that had to change because we made the conscious decision to use a more modern form builder.

+ +

But then there were always going to be some differences, and so we had to reconcile those with the product team, have a lot of communication around what was important to keep and what wasn't. And yeah, really, just try to get the code in a better spot if we can while also acknowledging that some things have been working for ten years, and that's okay too.

+ +

JOËL: So you're talking about a lot of old code that you're working with and seeing how much things have changed over ten years. And I feel like, as software developers, we're constantly having to learn and hone our skills, but it can really be overwhelming because there's so much to learn. How do you prioritize what you want to learn next?

+ +

STEPHANIE: At thoughtbot, we're lucky enough to have investment times. So typically, on Fridays, most of us will not be working on client work, but we'll be working on things to improve thoughtbot internally or improve ourselves professionally. So I'm really grateful that I have dedicated learning time, and figuring out how to spend it has been both fun and also fraught in a way because like you were saying, there are so many things I want to learn about, and we internally have so much lively discussion about really cool technical things.

+ +

But I've kind of accepted that I'm not going to be able to learn it all. And so when Friday does roll around, I do have to figure out, okay, how do I want to spend my precious investment time today? For me, it honestly feels really dependent on how I'm doing that Friday. So I do have a bit of a backlog of talks and articles that I've collected along the way or bookmarked that I might come back to if that is the mode I'm in. I also have bigger themes, I think, around frameworks and technologies that I want to dig a little more deeply into.

+ +

I've been trying to work through a TypeScript tutorial for a while now, especially because it's not something that I've gotten a chance to spend a ton of time on in client work. And so in some ways, it's like, well, if I want to work on a client project using TypeScript, then I feel like I should brush up on TypeScript first. So that's kind of in the back of my head is just a more nebulous goal. But I also think that it really changes depending on how I'm feeling throughout the year. It could be very well that the TypeScript thing never comes to fruition and maybe something else will grab my attention.

+ +

JOËL: I'm sure there are lessons, though, that you would learn from TypeScript that you could then use to improve your day-to day-work on a Rails project, for example.

+ +

STEPHANIE: Yeah, absolutely. I think that's the really cool thing is that everything I learn in some way can connect to other things that I do know, or experience, or come across during my everyday work. So none of it ever feels like a waste of time. I think the best feeling is when you can make that connection as you are experiencing something in the codebase that reminds you of something you read about in a blog post or something like that.

+ +

JOËL: Connections are one of the most crucial parts of, I think, knowledge creation. And in a past episode on note-taking, we had a whole deep conversation about how sometimes making connections between some of your notes is almost more valuable than taking a note by itself.

+ +

STEPHANIE: Joël, how do you prioritize your learning?

+ +

JOËL: I have three broad categories of technical learning that I like to do. The first is anything related to my core language and framework, and as of right now, that is Ruby, Rails. And maybe a little bit more broadly, anything related to the paradigms related to that, so object-oriented design, patterns related to that, all things that will help me to write better Ruby and Rails code.

+ +

Then there are evergreen skills that are always great to invest in, things like getting better at Git, learning a little bit of SQL, getting better at doing things on the command line. Those are all things that I look to level up every now and then. And then, finally, just whatever interests me right now. I find that the return on investment for the amount of time you put in versus the amount of knowledge you get out is much higher when I'm personally interested.

+ +

So it might be something completely unrelated to maybe more strategic elements of tech that I'm trying to get, but if I'm interested, it's worth putting a little bit of time into that. And so, for me, several years ago, that was functional programming types. Elm, I went really deep into that. And I think that really unlocked a whole other way of thinking about software for me and helped me...like we were saying earlier, I was able to bring that back to the way I think about Rails applications, the way I think about test-driven development. And that really rounded out my thinking, I think.

+ +

STEPHANIE: Yeah, I think focusing your energy into where you're interested in makes it easier, for sure. It makes it more fun. I think like you're saying, your learning gets accelerated. And I think it's also really cool that people have different interests that they do like to go deep on. So maybe you might be thinking that you should focus your energy on this other aspect of development that you think would be really cool or useful in your work but doesn't necessarily interest you that much. Chances are that there's someone else who loves learning and talking about it, and you can use them as a resource when you want to know more.

+ +

JOËL: That is a really important aspect because learning is not necessarily a solo activity. So sometimes, maybe I'm not even just prioritizing things that I think are strategically good for me or even things I'm just interested in. It might be things that my colleagues are interested in. So we have a book club that we run at thoughtbot. We've been going through the book Ruby Science, and there have been some great discussions around that. Recently, we've also been doing watch parties for episodes of I know it is RubyTapas by Avdi Grimm, but I think it rebranded recently, and I forget the new name of it, Graceful...I think Graceful.Dev.

+ +

STEPHANIE: Graceful Devs, I think, yeah.

+ +

JOËL: So we've been watching some of these together as a team and then having a conversation afterwards, so that's also been great.

+ +

STEPHANIE: That's really cool. Yeah, I think getting other people involved makes it a lot more fun. And you have an accountability buddy. And you can have those deep, thoughtful conversations about the things you've learned.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: I'm curious, have you ever made a conscious effort to not focus on something super deeply?

+ +

JOËL: I don't know that I've made a decision to be like, I will not spend time here. But I've definitely made a decision to I will invest here and maybe not care quite as much there. So I've done quite a bit of different front-end technologies, starting with jQuery and Backbone.js and moving through a lot of the frameworks. Somehow I have not yet done much React. It's sort of a big hole in that list of frameworks that I have worked with. It's just not something that I've prioritized. I've done other things. I've learned concepts that I think mirror a lot of what React does, but that's not been something that I've dug into.

+ +

STEPHANIE: That's really interesting because I think a lot of people think that they need to learn React because it's the popular front-end framework of the time. And so they think that it's something that they should know, or if they do ever have to work on a project with React, that kind of contributes to that feeling. But I like what you were saying earlier about how you have experience with other front-end frameworks. And that can help inform you if you ever do have to work in it. And also, there are so many great expert React devs out there. Like, we don't have to all be that dev.

+ +

JOËL: Yeah. I think there can definitely be a pressure to feel like you have to know it all. And a lot of these tech stacks are changing so quickly that it becomes overwhelming to try to just keep up with everything.

+ +

STEPHANIE: For sure. I remember having to write some tests for a React app, and the things that I had learned several years ago using Enzyme or something were no longer as relevant today, and having to pick up on the new best practices for writing Jest tests and React Testing Library. It was a lot, even though I was able to identify aspects of it that lined up with what I knew. It can be overwhelming, for sure. And people spend a lot of time digging deep into this framework and like I said, becoming those experts and accepting that I probably won't be that person [laughs] was also a little bit liberating, I think.

+ +

JOËL: It's also important, I think, to accept that these sorts of labels of I'm that person, or I'm not that person are not permanent. It's I'm not that person now because that's not where I want to prioritize my time. Maybe in two or three years, it will make sense for me to become that person. And I can become that person if I put in the time, but today is not the day for me to be that person.

+ +

STEPHANIE: That's a really good way of putting that. I like that a lot.

+ +

JOËL: One struggle that I have, and I've seen a lot of people too is that it's easy to get very scattered in your learning that you'll have a lot of different things you're trying to learn at the same time or you feel like you want to do a little bit of this and a little bit of that. And then maybe you don't go very deep in any of them and feel like you're not being very effective with your time. Do you ever feel that, and do you have any strategies you like to use to make the most out of your learning time?

+ +

STEPHANIE: I really relate to that. And I think one resource that helped me reframe that conundrum if you will, was this book called Four Thousand Weeks: Time Management for Mortals by Oliver Burkeman. It was really interesting because it kind of turned productivity culture around a bit on its head because his whole thesis is that you won't achieve at all and that by trying to hack your own productivity, what you're really preventing yourself from doing is accepting the fact that time is finite. And that you have to make hard decisions about where to focus your time in a way that will enrich your life the most.

+ +

And sacrifice the idea that you will get to do everything on your to-do list, that you will learn every framework that you want to learn. And it's still hard for me to totally accept that. But I think I'm inching towards the idea that if I do drop a ball on something that I have had bookmarked for at this point, you know, a year, I'm probably never going to get around to reading that. And that's okay because I'm still getting by with the things that I am learning and applying them in the aspects of my work that are relevant to me today.

+ +

JOËL: That sounds like a really refreshing take on productivity culture, maybe with some hard truths in there as well. Is 4,000 weeks the human lifespan?

+ +

STEPHANIE: [laughs] Yeah, it is. It's really funny because I think he even starts off in the book quizzing one of his friends, like, how many weeks do you think we have to live? And his friend very naively answered, "Oh, must be, you know, 500,000 or so," or something like that. But he used that as an illustration of how we inflate how much time we think that we might have in a day, a week, our lifespan. [laughs]

+ +

JOËL: I'm a big history nerd in my personal time. You see this theme that comes up a lot in medieval European art and the 1400s after a lot of these big plagues have happened where they feature a lot of death or skeletons or those sorts of motifs that are much more prevalent than maybe an earlier art, and this idea that comes with a Latin phrase Memento Mori (remember death). And I think there's maybe an element of that that comes back into this book at least the way you were describing it, the idea that you only have 4,000 weeks, roughly, in your life, so make the best use of it.

+ +

STEPHANIE: Yeah, absolutely. It's nothing new, for sure. I think it's just one of those things that we've been grappling with as a species for as long as we've existed. [laughs] So I don't know if anyone out there feels slightly relieved that it's okay for them not to get through their list of bookmarked articles about technical things. I hope that feels slightly better for you.

+ +

JOËL: We give you permission for you, the audience, to go to your bookmarks and those articles that you've been meaning to read for two years and you haven't got to; it's okay to remove them. You will be okay.

+ +

STEPHANIE: Agreed. So we've talked about how we spend our investment time. But I'm curious, do you have any strategies for people who do most of their learning in their everyday work?

+ +

JOËL: You know, I think that applies to me as well. We've been heavily emphasizing investment time, but that's only one day a week. And four days a week, I am doing regular application development for clients. And so the majority of my hours in a week are going to be dedicated to that. I find that being very self-aware for the things that you do and trying to notice when I learn something new or when I interact with something new has really helped me get more out of my day-to-day work.

+ +

And a way to level that, I think, is to be on the lookout for opportunities to share with others. And that can be as small as just put a today I learned message in a group chat, maybe in thoughtbot's Slack developer channel, and just say, "Hey, today I learned this interesting thing about a particular method." Or "Today I learned this weird thing about time zones." Or "Today I learned this interesting fact about testing." And then that might start a discussion, or it might not. But the fact that I took the time to take it out of my head and write it out, I think, makes that more concrete, and it helps me hold on to it.

+ +

STEPHANIE: I've noticed you are really good about doing that, about sharing things that you encounter in your everyday work in a very low-stakes kind of way. I am not so good at doing that. I tend to be so steeped in client work, and I have to really intentionally, after a project is over, think about what I learned along the way. And oftentimes, they're not as small, incremental atomic bits of information but bigger picture things about, oh, I learned how to navigate this aspect of ambiguity.

+ +

And maybe the next time, I can point to a past experience or lean on a little bit more on my gut instinct to guide me towards making the right decision. And I think that's an important aspect of learning too, even if it wasn't necessarily a technical tidbit. It is part of becoming a better developer, just as equally as gaining that more concrete technical knowledge.

+ +

JOËL: Intuition, I think, is really important as developers, and honing that intuition is something that is really valuable. One way that I found helpful is dialogue, just a conversation with one other person, maybe it's asynchronous over Slack, maybe it's a call in person, and just talking through an idea that I have.

+ +

A recent one and I think I mentioned this on the previous episode of The Bike Shed, was talking about RSpec matchers. And does your choice of matcher impact the sorts of design that will come out of the code that you write? Does EQ tend to push you in a direction maybe where you're less strongly encapsulating data? And so that's just a thought, and then you have a conversation about it. And then that can help sharpen your intuition so that the next time you're writing a test you're not just thoughtlessly bringing in a matcher because whatever; it's the thing to do.

+ +

And initially, maybe it's not intuition; it's much more explicit. You're thinking, ooh, do I want EQ, or do I want not? But I imagine that after six months of me being hyperaware of that, I will have built up some intuitions to be like, oh, this is the place where we want a custom matcher, or here's the place where I want EQ.

+ +

And my hope is that that will eventually come to the point where it's so natural. Someone would almost have to stop me and say, hey, wait, why are you choosing that? And then I have to think a little bit and be like, oh, it's because of these things. But I'll have started with a conversation, which then turned into just hyperawareness thinking about it every time I do that action which then turns into intuition.

+ +

STEPHANIE: Yeah. I think you can also call that experience. I remember having a conversation with someone, and I told them that I could inject their brain with all of the knowledge and information that I had. But that isn't quite the same as having really experienced the process of gaining that knowledge through more conventional learning methods but also that day-to-day client work that you're doing. So I totally agree with you there.

+ +

JOËL: You took this whole long thing I had to say and were able to condense it down to one word: experience.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Which I think, yeah, exactly describes what I'm trying to say. And with that, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

JOËL: The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + This week, Steph and Joël discuss investment time and keeping track of things they want to learn.

+ +

How do you, dear listener, keep track of things you want to learn? When investment time rolls around, what do you reach for, or how do you prioritize that list? Are there things you actively decide not to focus on when choosing where to develop deep expertise? Are there things you wish you could spend time on if you could?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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 little bit of what we've learned along the way.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: I was recently having a conversation with another colleague at thoughtbot, and they brought up Bloom's Taxonomy, which is a taxonomy of different phases of learning. It's often visualized as a pyramid with a broad base that starts with remembering facts and then expands up to understanding and then up to applying, and then analyzing, evaluating, and then finally creating. So it's a way to kind of quantify progression of someone who is trying to master a topic.

+ +

And what really struck me when I saw this diagram was I immediately thought about how the tech industry interviews and a lot of our interviews are focused on the base of that pyramid. It's all about did you memorize certain facts, or APIs, or things like that? But a lot of the value that we create as developers...but to be good at our jobs, we have to actually be active much higher up in that pyramid in the analyze, evaluate, and create layers.

+ +

But unfortunately, I feel like interviews often don't go that far; they're really just focused on the base. So that was a really interesting realization. We were not talking about interviewing, but this colleague shared the diagram. I looked at it, and the first thing I thought was like, oh, this is the problem with a lot of tech interviews these days.

+ +

STEPHANIE: Yeah, I think a lot about how in interviews, we want to be showing off our best selves in a sense. Like, we want our interviewers to see the version of ourselves that we bring to work, which is usually like you were saying, at that top layer and isn't recalling particular facts about how our framework works or things we might have learned in computer science class in college.

+ +

And one thing I actually really like about thoughtbot's interview...even in the job application, I think it says, "We want to see your strengths and see you at your best self." And it asks what can we, as thoughtbot, interview you on in a way that gives you the opportunity to display those skills? And so I really like that.

+ +

I think I remember when I submitted that application, I might have said something along the lines of debugging a problem because I think that's where I personally shine. I don't know if it ended up being a conscious thing. But I do remember when I was doing the pairing interview, there was an aspect of debugging, and I was like, yes, this is where I can show off what I would normally do in a real-life work situation. So that really resonates with me.

+ +

JOËL: Debugging is such a core developer skill, and yet I feel it's not often something that we dig into in a process like an interview. Sometimes you have almost like a code review style where you've got, oh, there is one bug hidden in here, find it, and it's almost like a gotcha sort of thing. I don't like those. But a real situation where you could show off your problem-solving and debugging skills sounds like a really good way to play to your strengths.

+ +

STEPHANIE: Yeah. Where else do you think that higher level of critical analysis and creative output shows up in your day-to-day work?

+ +

JOËL: I think it has to pervade the day-to-day work. The majority of my job is not remembering what method from enumerable is used to sort an array; it's trying to find a way to translate a problem that the business has into code or a code solution that will satisfy quite a lot of different constraints. This might be something that is doable in one or two days because that's all we have to allocate to this problem.

+ +

So a lot of that work could be scoping down a problem. There might be some performance-related constraints where it needs to be faster than X. There are certainly some correctness constraints as well that you're trying to work within. So all of that, I think, is much more at that analysis, evaluation, and creation layers of the pyramid.

+ +

STEPHANIE: Yeah, that's a really good point. I think sometimes I've seen interviews try to replicate that or recreate it in an interview question, even though they may be genuinely based off of real-life experiences that companies might have had. But most often, it's really hard to be evaluated on that situation until you're really just doing that work.

+ +

JOËL: It is really hard to translate that into an interview format. I think one aspect that I do appreciate, and maybe that's just the consultant in me but having a conversation about trade-offs in a situation where there isn't a single correct answer. And so, maybe the interviewer and the candidate have different conclusions. But as long as they can show their reasoning down that path of why they came to the conclusion that they did, I think that's the important part of that.

+ +

The hard thing is if the interviewer has their preferred solution, and they're just like, "No, you didn't come to my conclusion," then that's not a good interview. But a situation where a candidate gets to demonstrate their critical thinking skills, their analysis skills, their ability to make difficult decisions to balance trade-offs, I think that's a great way to show off some of those high-level skills that honestly we use on a daily basis.

+ +

STEPHANIE: Yeah, I agree 100%.

+ +

JOËL: So that's what I've been kind of excited about recently, just seeing this diagram and having that moment of clarity about interviewing. What's something new in your world, Stephanie?

+ +

STEPHANIE: That's really interesting that you brought that up because it's kind of related to what I was going to say about what I've been working on on my client project, which is the ambiguity of the rewrite. So I mentioned last week that I've been rewriting some Rails views. And we're working on a pretty old legacy application, so there are a lot of things that, as we're rewriting, we need to figure out whether or not we want to include it in the new version.

+ +

So it's been a little more challenging than just copying over the functionality that you want because there are a lot of things in this legacy app that were written 10-12 years ago that we don't have any context on, especially as consultants and even the people we're working with on this team, the code might even predate them.

+ +

So we do our best to ask them questions about, hey, is this still necessary? Do you think we want it in this rewrite? And they don't always know the answers. And so we have to make our best judgment and make a lot of micro-level decisions about what we think is important to bring into this rewrite without a ton of that historical context. So when you were talking about those analytical, critical thinking skills, that seemed like a very relevant experience that I would say has been utilizing those aspects of learning.

+ +

JOËL: Definitely, especially for a codebase that is that old. I feel like ten years is almost like a generation in software developer terms. Ten years ago would be what? 2012. That's Rails 3 still. I forget when Rails 4 came out. But yeah, that's a long time ago when you talk about technology. And at a company, even the odds of someone sticking around for that long are very low.

+ +

STEPHANIE: Absolutely. And so sometimes we just choose to leave the code as it is, and we will just copy and paste it. But other times, we might try to rewrite it in a more modern way. One thing that we did recently was migrate a hand-rolled form builder to use Simple Form. And we did our best to retain most of the original functionality. But there were aspects of it, things like browser validation and stuff like that, that had to change because we made the conscious decision to use a more modern form builder.

+ +

But then there were always going to be some differences, and so we had to reconcile those with the product team, have a lot of communication around what was important to keep and what wasn't. And yeah, really, just try to get the code in a better spot if we can while also acknowledging that some things have been working for ten years, and that's okay too.

+ +

JOËL: So you're talking about a lot of old code that you're working with and seeing how much things have changed over ten years. And I feel like, as software developers, we're constantly having to learn and hone our skills, but it can really be overwhelming because there's so much to learn. How do you prioritize what you want to learn next?

+ +

STEPHANIE: At thoughtbot, we're lucky enough to have investment times. So typically, on Fridays, most of us will not be working on client work, but we'll be working on things to improve thoughtbot internally or improve ourselves professionally. So I'm really grateful that I have dedicated learning time, and figuring out how to spend it has been both fun and also fraught in a way because like you were saying, there are so many things I want to learn about, and we internally have so much lively discussion about really cool technical things.

+ +

But I've kind of accepted that I'm not going to be able to learn it all. And so when Friday does roll around, I do have to figure out, okay, how do I want to spend my precious investment time today? For me, it honestly feels really dependent on how I'm doing that Friday. So I do have a bit of a backlog of talks and articles that I've collected along the way or bookmarked that I might come back to if that is the mode I'm in. I also have bigger themes, I think, around frameworks and technologies that I want to dig a little more deeply into.

+ +

I've been trying to work through a TypeScript tutorial for a while now, especially because it's not something that I've gotten a chance to spend a ton of time on in client work. And so in some ways, it's like, well, if I want to work on a client project using TypeScript, then I feel like I should brush up on TypeScript first. So that's kind of in the back of my head is just a more nebulous goal. But I also think that it really changes depending on how I'm feeling throughout the year. It could be very well that the TypeScript thing never comes to fruition and maybe something else will grab my attention.

+ +

JOËL: I'm sure there are lessons, though, that you would learn from TypeScript that you could then use to improve your day-to day-work on a Rails project, for example.

+ +

STEPHANIE: Yeah, absolutely. I think that's the really cool thing is that everything I learn in some way can connect to other things that I do know, or experience, or come across during my everyday work. So none of it ever feels like a waste of time. I think the best feeling is when you can make that connection as you are experiencing something in the codebase that reminds you of something you read about in a blog post or something like that.

+ +

JOËL: Connections are one of the most crucial parts of, I think, knowledge creation. And in a past episode on note-taking, we had a whole deep conversation about how sometimes making connections between some of your notes is almost more valuable than taking a note by itself.

+ +

STEPHANIE: Joël, how do you prioritize your learning?

+ +

JOËL: I have three broad categories of technical learning that I like to do. The first is anything related to my core language and framework, and as of right now, that is Ruby, Rails. And maybe a little bit more broadly, anything related to the paradigms related to that, so object-oriented design, patterns related to that, all things that will help me to write better Ruby and Rails code.

+ +

Then there are evergreen skills that are always great to invest in, things like getting better at Git, learning a little bit of SQL, getting better at doing things on the command line. Those are all things that I look to level up every now and then. And then, finally, just whatever interests me right now. I find that the return on investment for the amount of time you put in versus the amount of knowledge you get out is much higher when I'm personally interested.

+ +

So it might be something completely unrelated to maybe more strategic elements of tech that I'm trying to get, but if I'm interested, it's worth putting a little bit of time into that. And so, for me, several years ago, that was functional programming types. Elm, I went really deep into that. And I think that really unlocked a whole other way of thinking about software for me and helped me...like we were saying earlier, I was able to bring that back to the way I think about Rails applications, the way I think about test-driven development. And that really rounded out my thinking, I think.

+ +

STEPHANIE: Yeah, I think focusing your energy into where you're interested in makes it easier, for sure. It makes it more fun. I think like you're saying, your learning gets accelerated. And I think it's also really cool that people have different interests that they do like to go deep on. So maybe you might be thinking that you should focus your energy on this other aspect of development that you think would be really cool or useful in your work but doesn't necessarily interest you that much. Chances are that there's someone else who loves learning and talking about it, and you can use them as a resource when you want to know more.

+ +

JOËL: That is a really important aspect because learning is not necessarily a solo activity. So sometimes, maybe I'm not even just prioritizing things that I think are strategically good for me or even things I'm just interested in. It might be things that my colleagues are interested in. So we have a book club that we run at thoughtbot. We've been going through the book Ruby Science, and there have been some great discussions around that. Recently, we've also been doing watch parties for episodes of I know it is RubyTapas by Avdi Grimm, but I think it rebranded recently, and I forget the new name of it, Graceful...I think Graceful.Dev.

+ +

STEPHANIE: Graceful Devs, I think, yeah.

+ +

JOËL: So we've been watching some of these together as a team and then having a conversation afterwards, so that's also been great.

+ +

STEPHANIE: That's really cool. Yeah, I think getting other people involved makes it a lot more fun. And you have an accountability buddy. And you can have those deep, thoughtful conversations about the things you've learned.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: I'm curious, have you ever made a conscious effort to not focus on something super deeply?

+ +

JOËL: I don't know that I've made a decision to be like, I will not spend time here. But I've definitely made a decision to I will invest here and maybe not care quite as much there. So I've done quite a bit of different front-end technologies, starting with jQuery and Backbone.js and moving through a lot of the frameworks. Somehow I have not yet done much React. It's sort of a big hole in that list of frameworks that I have worked with. It's just not something that I've prioritized. I've done other things. I've learned concepts that I think mirror a lot of what React does, but that's not been something that I've dug into.

+ +

STEPHANIE: That's really interesting because I think a lot of people think that they need to learn React because it's the popular front-end framework of the time. And so they think that it's something that they should know, or if they do ever have to work on a project with React, that kind of contributes to that feeling. But I like what you were saying earlier about how you have experience with other front-end frameworks. And that can help inform you if you ever do have to work in it. And also, there are so many great expert React devs out there. Like, we don't have to all be that dev.

+ +

JOËL: Yeah. I think there can definitely be a pressure to feel like you have to know it all. And a lot of these tech stacks are changing so quickly that it becomes overwhelming to try to just keep up with everything.

+ +

STEPHANIE: For sure. I remember having to write some tests for a React app, and the things that I had learned several years ago using Enzyme or something were no longer as relevant today, and having to pick up on the new best practices for writing Jest tests and React Testing Library. It was a lot, even though I was able to identify aspects of it that lined up with what I knew. It can be overwhelming, for sure. And people spend a lot of time digging deep into this framework and like I said, becoming those experts and accepting that I probably won't be that person [laughs] was also a little bit liberating, I think.

+ +

JOËL: It's also important, I think, to accept that these sorts of labels of I'm that person, or I'm not that person are not permanent. It's I'm not that person now because that's not where I want to prioritize my time. Maybe in two or three years, it will make sense for me to become that person. And I can become that person if I put in the time, but today is not the day for me to be that person.

+ +

STEPHANIE: That's a really good way of putting that. I like that a lot.

+ +

JOËL: One struggle that I have, and I've seen a lot of people too is that it's easy to get very scattered in your learning that you'll have a lot of different things you're trying to learn at the same time or you feel like you want to do a little bit of this and a little bit of that. And then maybe you don't go very deep in any of them and feel like you're not being very effective with your time. Do you ever feel that, and do you have any strategies you like to use to make the most out of your learning time?

+ +

STEPHANIE: I really relate to that. And I think one resource that helped me reframe that conundrum if you will, was this book called Four Thousand Weeks: Time Management for Mortals by Oliver Burkeman. It was really interesting because it kind of turned productivity culture around a bit on its head because his whole thesis is that you won't achieve at all and that by trying to hack your own productivity, what you're really preventing yourself from doing is accepting the fact that time is finite. And that you have to make hard decisions about where to focus your time in a way that will enrich your life the most.

+ +

And sacrifice the idea that you will get to do everything on your to-do list, that you will learn every framework that you want to learn. And it's still hard for me to totally accept that. But I think I'm inching towards the idea that if I do drop a ball on something that I have had bookmarked for at this point, you know, a year, I'm probably never going to get around to reading that. And that's okay because I'm still getting by with the things that I am learning and applying them in the aspects of my work that are relevant to me today.

+ +

JOËL: That sounds like a really refreshing take on productivity culture, maybe with some hard truths in there as well. Is 4,000 weeks the human lifespan?

+ +

STEPHANIE: [laughs] Yeah, it is. It's really funny because I think he even starts off in the book quizzing one of his friends, like, how many weeks do you think we have to live? And his friend very naively answered, "Oh, must be, you know, 500,000 or so," or something like that. But he used that as an illustration of how we inflate how much time we think that we might have in a day, a week, our lifespan. [laughs]

+ +

JOËL: I'm a big history nerd in my personal time. You see this theme that comes up a lot in medieval European art and the 1400s after a lot of these big plagues have happened where they feature a lot of death or skeletons or those sorts of motifs that are much more prevalent than maybe an earlier art, and this idea that comes with a Latin phrase Memento Mori (remember death). And I think there's maybe an element of that that comes back into this book at least the way you were describing it, the idea that you only have 4,000 weeks, roughly, in your life, so make the best use of it.

+ +

STEPHANIE: Yeah, absolutely. It's nothing new, for sure. I think it's just one of those things that we've been grappling with as a species for as long as we've existed. [laughs] So I don't know if anyone out there feels slightly relieved that it's okay for them not to get through their list of bookmarked articles about technical things. I hope that feels slightly better for you.

+ +

JOËL: We give you permission for you, the audience, to go to your bookmarks and those articles that you've been meaning to read for two years and you haven't got to; it's okay to remove them. You will be okay.

+ +

STEPHANIE: Agreed. So we've talked about how we spend our investment time. But I'm curious, do you have any strategies for people who do most of their learning in their everyday work?

+ +

JOËL: You know, I think that applies to me as well. We've been heavily emphasizing investment time, but that's only one day a week. And four days a week, I am doing regular application development for clients. And so the majority of my hours in a week are going to be dedicated to that. I find that being very self-aware for the things that you do and trying to notice when I learn something new or when I interact with something new has really helped me get more out of my day-to-day work.

+ +

And a way to level that, I think, is to be on the lookout for opportunities to share with others. And that can be as small as just put a today I learned message in a group chat, maybe in thoughtbot's Slack developer channel, and just say, "Hey, today I learned this interesting thing about a particular method." Or "Today I learned this weird thing about time zones." Or "Today I learned this interesting fact about testing." And then that might start a discussion, or it might not. But the fact that I took the time to take it out of my head and write it out, I think, makes that more concrete, and it helps me hold on to it.

+ +

STEPHANIE: I've noticed you are really good about doing that, about sharing things that you encounter in your everyday work in a very low-stakes kind of way. I am not so good at doing that. I tend to be so steeped in client work, and I have to really intentionally, after a project is over, think about what I learned along the way. And oftentimes, they're not as small, incremental atomic bits of information but bigger picture things about, oh, I learned how to navigate this aspect of ambiguity.

+ +

And maybe the next time, I can point to a past experience or lean on a little bit more on my gut instinct to guide me towards making the right decision. And I think that's an important aspect of learning too, even if it wasn't necessarily a technical tidbit. It is part of becoming a better developer, just as equally as gaining that more concrete technical knowledge.

+ +

JOËL: Intuition, I think, is really important as developers, and honing that intuition is something that is really valuable. One way that I found helpful is dialogue, just a conversation with one other person, maybe it's asynchronous over Slack, maybe it's a call in person, and just talking through an idea that I have.

+ +

A recent one and I think I mentioned this on the previous episode of The Bike Shed, was talking about RSpec matchers. And does your choice of matcher impact the sorts of design that will come out of the code that you write? Does EQ tend to push you in a direction maybe where you're less strongly encapsulating data? And so that's just a thought, and then you have a conversation about it. And then that can help sharpen your intuition so that the next time you're writing a test you're not just thoughtlessly bringing in a matcher because whatever; it's the thing to do.

+ +

And initially, maybe it's not intuition; it's much more explicit. You're thinking, ooh, do I want EQ, or do I want not? But I imagine that after six months of me being hyperaware of that, I will have built up some intuitions to be like, oh, this is the place where we want a custom matcher, or here's the place where I want EQ.

+ +

And my hope is that that will eventually come to the point where it's so natural. Someone would almost have to stop me and say, hey, wait, why are you choosing that? And then I have to think a little bit and be like, oh, it's because of these things. But I'll have started with a conversation, which then turned into just hyperawareness thinking about it every time I do that action which then turns into intuition.

+ +

STEPHANIE: Yeah. I think you can also call that experience. I remember having a conversation with someone, and I told them that I could inject their brain with all of the knowledge and information that I had. But that isn't quite the same as having really experienced the process of gaining that knowledge through more conventional learning methods but also that day-to-day client work that you're doing. So I totally agree with you there.

+ +

JOËL: You took this whole long thing I had to say and were able to condense it down to one word: experience.

+ +

STEPHANIE: [laughs]

+ +

JOËL: Which I think, yeah, exactly describes what I'm trying to say. And with that, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

JOËL: The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1EXNSu9h + + ]]> + + Joël Quenneville + Stephanie Minn + + + 361: Working Incrementally + https://bikeshed.thoughtbot.com/361 + b4b7f98d-80d7-46c1-8ee1-cbb5584df63c + Tue, 08 Nov 2022 00:00:00 -0500 + thoughtbot + + full + thoughtbot + thoughtbotter Stephanie Minn joins The Bike Shed as co-host! 🎉 + +Joël and Stephanie talk about continuing on a rewrite and redesign of a legacy Rails app and working incrementally. + 30:28 + no + + + thoughtbotter Stephanie Minn joins The Bike Shed as co-host! 🎉 +Joël and Stephanie talk about continuing on a rewrite and redesign of a legacy Rails app and working incrementally. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Stephanie's listener question (https://www.bikeshed.fm/327) +Stephanie's older episodes +Case Expressions (https://www.bikeshed.fm/352) +Specialized Vocabulary (https://www.bikeshed.fm/356) +Mike Burns' smelly list (https://thoughtbot.com/blog/a-smelly-list) +Previous episode about note taking systems (https://www.bikeshed.fm/357) +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. And today, I'm joined by someone very special, Stephanie Minn, who will be joining the podcast as a co-host. +STEPHANIE: Hi, Joël. It's me, Stephanie Minn. [laughs] +JOËL: Welcome to The Bike Shed. +STEPHANIE: Thanks. I am really excited to be here for the third time, I guess, but now in a more official capacity. +JOËL: And together, I think both of us are now excited to share a little bit of what we've learned along the way. So for the first time as a co-host, I'm happy to ask you the question, what's new in your world? +STEPHANIE: Well, I think I would have to say co-hosting this podcast. It's pretty big news for me, personally. I'm really pumped and also really nervous. I never thought I would co-host a podcast. But I have been a long-time listener of the show, and it feels very surreal to be here. I have big shoes to fill, even if I do have the same name as former co-host Steph Viccari. +It's funny; I listened to a previous episode of The Bike Shed this morning, where I had submitted a listener question about project estimation. It came out earlier this year. It was really funny because Steph and Chris had a whole bit about speaking to this other Stephanie out in the world. That was me. And now it's kind of come full circle that I am in this position now. So I thought that was kind of fun. Now I could just say hello to all the Stephs out there. +JOËL: Regular listeners will have recognized you because you've been a recent guest on a couple of different episodes, one where you talked about case expressions and how they fit into our style of programming. And then another one where we talked about the use of domain-specific or industry-specific vocabulary and jargon as a form of communication and how that plays out in the workplace. And for those who have not listened to those, we'll link them in the show notes if you want to catch up on the backlog. +STEPHANIE: I really enjoyed being a guest on the last few episodes. It was cool to see things that we talk about internally come up in a way that we want to share with a broader audience because I think some of the things that we get into in book club or in the dev channel on Slack end up being really interesting and sometimes not things that we always see out in the content world, and we can dig really deep into that with this format. So that is really exciting to me. +I think, in general, being on this podcast, I'm hoping in some ways will also be a growth opportunity for me because I am wanting to get more comfortable sharing my thoughts and ideas in a public space more frequently and informally. I'm very comfortable hoarding my thoughts until they're perfectly refined. And I'm like, okay, now I finally feel ready to share them in the form of a blog post or a talk. +But I kind of want to open myself up to hearing from others, different perspectives, being more comfortable being wrong in public, and changing my mind, and evolving how I work and what I think in this way because I think it's important to normalize that. Yeah, I don't know how I can be any more vulnerable than being on a podcast on the internet. +JOËL: Podcasting is really interesting because it's much more raw and unfiltered as opposed to something like a blog post or a conference talk where you've gone through a whole editing phase; you've rehearsed it. And you've spoken at conferences before, and you're speaking again. You'll be at RubyConf Mini in a few weeks. +STEPHANIE: Yeah, I was thinking about my background because I actually come from a journalism background; that's what my degree is. And so I'm very comfortable in the role of editor, and I am a very obsessive and tedious editor when it comes to my own personal work in words and in code, I would say. The idea of putting stuff out there in a more unfiltered and less polished way is uncomfortable for me, but I want to get better at it, which is why I'm here because, like you were saying, in some ways, it's more realistic in just how we talk about some of these things at work. +I kind of want to remove the Instagram filter of talking about software and technical topics. And sometimes, we are just learning about things along the way. And I think that's one of the things that I've really appreciated about The Bike Shed in the past. +JOËL: Have you ever tried improv? +STEPHANIE: Oh my God. Once I took an improv class as a team bonding activity at an old job, and that was really something. I think we all collectively were not into the idea, but that's what we were doing. So we went to I a think comedy club or something in New York with my team at my first job. And it was actually a lot more fun than I thought it was going to be. I think the instructors knew that most people would not be super comfortable with improv, and so they did provide a lot of structure in terms of the types of exercises and games we played. +And we weren't doing improv comedy; we were just doing the exercises that would make us feel a little more comfortable and just having fun with it. Given some prompts, we would maybe walk across the room in a silly walk. And then the other person that we would walk to would imitate it, but it would be slightly different, and it would kind of evolve that way. So that's funny that you mentioned that. I had to really dig that memory from the archives [laughs] because I probably repressed it at some point. +JOËL: I've also done improv a couple of times in a similar setting to you, like a team-building activity. I really enjoyed it. And in many ways, I feel like podcasting can feel like the improv version of the content world. +STEPHANIE: Yes, and I agree. +[laughter] +JOËL: Yes, and very true. +STEPHANIE: So, Joël, what's new in your world? +JOËL: So you'd mentioned earlier how our developer channel on Slack is just a fantastic resource. There are some great conversations that happen there, and a lot of them eventually I like them so much I want to pull them into The Bike Shed and make an episode inspired by them. And I had a conversation today about the impact of what matchers you choose when you write tests and how that might impact the code that you write. So, for example, an equality matcher is almost like the primitive obsession version of testing matchers in RSpec and how which one you pick might impact the implementation of your code. +An example of that might be if you have... let's say you're testing behavior on an order, and you might say you do some things, and you expect the order status to be the string or to equal the string pending. You've now exposed this internal of this order status string where instead you might using some of RSpec's automatic matchers for predicate methods, expect the order to be _pending because you now have a predicate method pending defined on your order. +So by choosing to use a more rich matcher, you may have actually improved the encapsulation of your object. I had never thought about matters in that way before. It kind of blew my mind, and so I'm still kind of chewing on that, and maybe some of the implications of it. +STEPHANIE: That's really interesting because, in my experience, I think I would reach for the more general matchers, the ones that seem to be more top of mind for me. And it takes an extra intentional thought to be like, oh, actually, I want this particular specific matcher to better reflect the behavior that I'm desiring. +JOËL: This just came out of a conversation because fellow thoughtboter, Mike Burns, has a blog post that just lists a bunch of almost code smells or things that make him raise an eyebrow during code review that might lead to a follow-up comment and asking for clarification about why that choice was used. And on that list is the RSpec eq matcher that checks for just regular equality. And so we went a little bit deep into why that might be the case, and that brought up a lot of really interesting ideas that I had not thought about before. +STEPHANIE: I'm curious if you are doing test-driven development if using a more specific selector. This is kind of the opposite of what I said earlier, but I guess I'm wondering if there's a possibility that it pigeonholes you into a particular implementation. +JOËL: It might pigeonhole you into a particular interface, and I'm still exploring the idea. I think that the richer matchers move you away from implementation. So, in this case, or in the case of the example I talked about earlier, all you know is that there's a predicate method pending on an order. You don't know whether it's implemented as a Boolean internally or if it's a string that is being checked or some other thing. Maybe it's a status code. +STEPHANIE: That's cool. Do you think you might explore this in your own work moving forward? +JOËL: In a recent episode with Amanda Beiner, we had a whole conversation about note-taking systems, and I talked about having a sort of personal knowledge base where I keep deeper thoughts about code. And I definitely added a couple of entries to that today based off of that conversation. +STEPHANIE: That's awesome. I totally know what you're talking about when you learn things or pick up little bits and pieces of information that you want to hold on to. But you might not have a particularly applicable project or codebase you're working in at the moment to apply that, but you want to hold on to it when you encounter that situation in the future. So I really like what you're saying about just adding it to your knowledge base and coming back to it. +JOËL: I think the next time I'm writing a test and I feel the need to reach for eq I will immediately think of this and ask myself, is there something else that might be better? And if other matches feel awkward, why? So it's going to definitely cause me to be a lot more thoughtful about the way I write assertions. I'm curious to see if that will have an impact on the types of designs that my tests drive. +STEPHANIE: Yeah, so maybe not a code smell but a code whiff. +JOËL: Definitely. +MID-ROLL AD: +Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: So one thing I've been thinking a lot about in my client project currently is working on features more incrementally. Right now, we are working on a rewrite of the front end of a legacy Rails app. So they did a big, modern refresh on the look of the app. And we are rewriting a bunch of the views to those specs. And all of this is happening behind a feature flag. So we are able to ship work incrementally and not have as much of an issue where all of this work is happening on one big branch. +But because a lot of this work builds on top of each other, I have been experiencing folks cutting branches off of feature branches, off of feature branches. And I've been thinking a lot about the intentional steps that we made to be able to deploy this in pieces and more safely but the friction that people still might have to work incrementally. +One thing that I've noticed is that there are different levels to how this shows up in our work. You can work incrementally on an individual level where you are in your own work writing small commits that capture individual pieces, and you can feel good about that. But then you also have it at a team level where we have to collectively decide how we want to ship features. And I am trying to figure out how to encourage other people to agree on an approach and encourage the benefits of shipping features in small chunks. Have you ever noticed a discrepancy between individual work and how a team works in that way? +JOËL: It sounds like what you're describing is that by encouraging the team to work in smaller chunks, it has made the Git and branching and merging process more complicated for the team as a whole. Maybe there's a bit of that tension whereby increasing the individual granularity; you're making the merging for the team more complex. +STEPHANIE: Yeah, we've had a lot of rebasing issues where we do spend a lot of time in that mode because one branch went through code review and had some changes and then went through UAT and had some changes. And then we had to reconcile those changes with another feature that had been started and cut off of that feature branch. +JOËL: That's really interesting because I feel like I've almost had the opposite experience. When I was a new developer, I would constantly get Git conflicts, and you have to figure out the merge, and it's a mess. And then eventually, I got decently good at resolving conflicts. Nowadays, I very rarely encounter conflicts, and the ones I get tend to be really minimal. And I think that's because I've started to really work incrementally and to keep my change sets small. +And so Git conflicts are not really something I run into very much anymore. And I tend to think of them now as more of a symptom of large patches and code changes that might be bigger than they need to be. Does that line up maybe with your experience as well? +STEPHANIE: Yeah, I think it does. But one area of friction that we are experiencing right now is that we may be working incrementally, but those changes don't make it all the way to our integration or production branches, and so they are still just hanging around. And we have had to fix merge conflicts, not necessarily with other people's work but with our own work where changes happened upstream, and then they kind of cascade down. So we are working in pieces. But because there is a little bit of process challenges that we're facing, we haven't quite closed the loop on that feedback cycle in a way that allows us to move as quickly as I think what you're describing. +JOËL: It sounds like maybe your team is bundling multiple incremental changes and then trying to merge a bundle of them together. So while it's composed of small, incremental changes, the effect is similar to merging a branch that's got a large change set together. +STEPHANIE: Yeah, that's exactly it. +JOËL: In my own work, I tend to really view commits as the atomic chunks of the work that I'm doing, so each of them is going to be very tightly scoped and do a single thing. Ideally, also pass all the tests and be independently mergeable. I tend to view PRs not so much as like a unit of work but just a unit of review, a way to get feedback on one or more commits. I don't want to put too many commits in a PR because then it's painful for the reviewer. But also, another reason that you got me thinking about is that trying to shove fewer commits in a PR will also make it easier to do that final merge. +STEPHANIE: Yeah, I know that I really appreciate when PRs are just one, maybe a few commits, but the overall diff is small. And in my opinion, I think we are able to move faster that way because reviews are quicker, conflicts are fewer. And it better captures the idea of working incrementally, even if it does involve more than a single, small atomic commit. And I would love to figure out how to move in that direction. +Right now, in my client project, one of the barriers is the processes we've built into the agile methodology we're following, where our PRs have to get a couple of approvals and then be tested by folks from product. And so it's sometimes easier to just add a little bit of things to an open PR already. But what we were talking about with incorporating more of that intentionality really pays the cost up front rather than just pushing it until later when we do run into problems with conflicts or having to go back to debug something that went in into a big bundled PR and then having to spend time and energy at that point in the lifecycle of our work. +JOËL: It's really interesting that you highlight the organizational impact and the process impacts. Definitely, when you increase the cost of merging when you make it like to merge a single PR, you're going to need to wait at least 24 hours because of all the other checks that need to go through, then people will tend to make larger PRs. And so sometimes it's not about programmer discipline or good habits even; it's about the process pressures that just really incentivize making larger PRs because of how expensive it is to open a new one. +I'm curious, though, in a perfect world, when you are reviewing a PR for some code written in Ruby on Rails, what is the max amount of lines that you'd want to see in a diff before you start thinking this is too big; I wish we could split it up? +STEPHANIE: I don't know if I have a number in my head. I want to say somewhere in the couple hundreds, maybe. I will love a PR where the diff is less than 100. That feels great to review and just feels right. I don't know; it's I don't open it and be like, ah, I have to now read through tens of files, some of which I have no context about. I like a tidy PR where everything that's changed is related to what the PR title is. What about you? Do you have a heuristic? +JOËL: I think I'm probably similar to you, 100 lines is probably about the cut-off for where it starts to become more of a chore to review a PR. I've definitely had moments where somebody sends me a link and says, "Hey, can you review?" And I click the link and I open it up, and I'm like, oh okay, well, I should set aside a half hour here to really get into this because this is not going to be quick. +STEPHANIE: For sure. And it also makes addressing that review feedback more difficult because you have to likely make more changes because there's just more to review and more to improve if it wasn't quite right the first time. The only time I do a big diff is if it's all in red. [laughter] +JOËL: Yes. +STEPHANIE: We have a Slack channel at thoughtbot called Dead Code Society where people post screenshots of their negative diffs, and it's so fun. +JOËL: I'm all for that. When I look at code that has been broken down into nice, small commits, it just looks so clean. It looks so natural. But when I try to write code like that, it's anything but; it doesn't feel natural. Have you had a similar experience? +STEPHANIE: I completely agree. I think it's really hard, and it's something that I am still practicing. Because when you are first learning to code, no one teaches you to write it incrementally; at least, that was my experience. It requires a lot of discipline to think about code in little, tiny chunks when you are just so excited to get your feature working and seeing it in a browser and playing around with it. +When I first started doing it, I thought it was impossible. I thought it was wild to have a single commit be passing CI all the time because when I was writing code, there were so many work in progresses. And then I would run the test suite and be like, ah, 20 test failures. Now I have to go through and fix all of them. I guess what I learned from that was the pain of not working incrementally, and that is what motivates me to be disciplined. And it doesn't always happen. +Sometimes I'm lazy and just decide that it's fine for now, and then will usually have to come back through when I am in that kind of headspace where I'm like, okay, let me really get down to business. And I'm able to see the seams of the code that I wrote to be able to extract them out into encapsulated pieces because that doesn't always come supernaturally. So yeah, I would say that it's an upward journey for sure. Do you find that to be true for your work? +JOËL: It has definitely been a journey. I think as I have gained experience, as I have discovered new techniques, even picked up different perspectives and mindsets, all of these have helped hone that skill. And I feel like it's one of those skills that feels very mundane, but it's actually one of the more valuable skills I have as a developer is able to take something complex and decompose it into atomic pieces. +STEPHANIE: Do you ever find yourselves in a position where there are obstacles that keep you from doing that, or would you say it's just an internal state of mind? +JOËL: Maybe a little bit of both. You'd mentioned earlier that there can be process or organizational obstacles that make it much harder to try to scope down the work that you have. It can be internal in that you don't know the tools that you need for this particular scenario. But it's something where you're constantly on the lookout for ways to learn to be better. +Over the course of your career, it is a skill that I think you're going to keep improving probably forever. I don't think you'll ever get to the point which is like, yep, I've mastered this. I'm as good as I will ever be, and that's the end. I'm curious, are there some tools or techniques that you like to use when trying to keep your work focused? +STEPHANIE: From a commit level, I really love the git add --patch command. I think that it is really helpful because I like to litter my code with random debuggers and little changes that I don't end up wanting to bring into my commit later on. And so that is a great place for me to discard things that I know are distractions or were part of little rabbit holes I went down along the way. And so I highly recommend folks to check that out if that's not something that's already familiar to them. +At a higher level, TDD has helped with staying focused because you have that built-in feedback loop. And once you are green, you can commit essentially and know that you did the least amount of work possible to get the behavior that you wanted without starting to sprawl into other territory. Joël, do you have any other tips or tools you want to share with our listeners? +JOËL: A sort of mental tool that I've gotten into recently is drawing things out as a directed graph to understand what are the changes that I need to accomplish my goal and then what changes rely on other changes being there first? And a directed graph, you just draw a bunch of circles with arrows pointing towards things that they depend on. Anytime there is a cycle, that chunk of changes all has to go out together. They're all sort of interdependent on each other. +And if you can find a way to restructure the graph or introduce a new step in there that will break the cycle, now individual pieces of that can be shipped independently. I've started using that visual approach sometimes to look at changes that feel like they're one sort of big blob of changes that can't be broken down and to say, oh, well, in order to ship this change, I need to introduce this new gem. I'm going to need to change behavior in this part of the system, but that will also need a change in another part of the system. +And now that I can see how things are connected to each other, it gives me a clue to where I can rearrange the changes. Maybe there's a refactor that I can ship out first completely separate that makes the follow-up work much easier. Or maybe there's a way that I can introduce some of the changes without needing to do all of them at once. +STEPHANIE: That's a really cool way to identify those pieces because it can be nearly impossible to figure it out from files in a repo or to keep in your head. And I think what's even cooler is that you can share those graphs too so someone else can come along and pick up that work, as well as just have the same level of understanding of what things depend on each other just through our clients. +JOËL: I've really fallen in love with directed graphs and dependency graphs, in particular over the past year, and I feel like now I see them everywhere. And regular listeners of the show will have noticed that I have mentioned them multiple times. And I almost feel now like I'm that Parks and Recs meme where he's got [laughter] all his conspiracy board with all the threads connecting to each other and just like, let me tell you about graphs and how everything is all connected. They're behind everything. +STEPHANIE: I'm with you. I think everything is connected, even just in our informal conversations on the pod and off the pod. We're constantly being like, oh, that's a great idea. Like, we can do a completely different episode if we go down this rabbit hole, but it also still maps back to things we talked about in another episode. And yeah, that feels very true to me in terms of software and also in terms of life, not to make that sound too deep. [laughs] But it's cool that you have found a way to manage that complexity for yourself at work and a way to share it with others. +JOËL: I think one of these days, we're going to have to do a dedicated episode all about dependency graphs. +STEPHANIE: Yeah, I would love to hear more. Too bad the podcast is just an auditory platform and not a visual one. [laughs] +JOËL: That's the challenge, right? Because it's such a visual topic. +STEPHANIE: That's cool. I'm really looking forward to hearing more about them. On that note, shall we wrap up? +JOËL: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeee!!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + thoughtbotter Stephanie Minn joins The Bike Shed as co-host! 🎉

+ +

Joël and Stephanie talk about continuing on a rewrite and redesign of a legacy Rails app and working incrementally.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by someone very special, Stephanie Minn, who will be joining the podcast as a co-host.

+ +

STEPHANIE: Hi, Joël. It's me, Stephanie Minn. [laughs]

+ +

JOËL: Welcome to The Bike Shed.

+ +

STEPHANIE: Thanks. I am really excited to be here for the third time, I guess, but now in a more official capacity.

+ +

JOËL: And together, I think both of us are now excited to share a little bit of what we've learned along the way. So for the first time as a co-host, I'm happy to ask you the question, what's new in your world?

+ +

STEPHANIE: Well, I think I would have to say co-hosting this podcast. It's pretty big news for me, personally. I'm really pumped and also really nervous. I never thought I would co-host a podcast. But I have been a long-time listener of the show, and it feels very surreal to be here. I have big shoes to fill, even if I do have the same name as former co-host Steph Viccari.

+ +

It's funny; I listened to a previous episode of The Bike Shed this morning, where I had submitted a listener question about project estimation. It came out earlier this year. It was really funny because Steph and Chris had a whole bit about speaking to this other Stephanie out in the world. That was me. And now it's kind of come full circle that I am in this position now. So I thought that was kind of fun. Now I could just say hello to all the Stephs out there.

+ +

JOËL: Regular listeners will have recognized you because you've been a recent guest on a couple of different episodes, one where you talked about case expressions and how they fit into our style of programming. And then another one where we talked about the use of domain-specific or industry-specific vocabulary and jargon as a form of communication and how that plays out in the workplace. And for those who have not listened to those, we'll link them in the show notes if you want to catch up on the backlog.

+ +

STEPHANIE: I really enjoyed being a guest on the last few episodes. It was cool to see things that we talk about internally come up in a way that we want to share with a broader audience because I think some of the things that we get into in book club or in the dev channel on Slack end up being really interesting and sometimes not things that we always see out in the content world, and we can dig really deep into that with this format. So that is really exciting to me.

+ +

I think, in general, being on this podcast, I'm hoping in some ways will also be a growth opportunity for me because I am wanting to get more comfortable sharing my thoughts and ideas in a public space more frequently and informally. I'm very comfortable hoarding my thoughts until they're perfectly refined. And I'm like, okay, now I finally feel ready to share them in the form of a blog post or a talk.

+ +

But I kind of want to open myself up to hearing from others, different perspectives, being more comfortable being wrong in public, and changing my mind, and evolving how I work and what I think in this way because I think it's important to normalize that. Yeah, I don't know how I can be any more vulnerable than being on a podcast on the internet.

+ +

JOËL: Podcasting is really interesting because it's much more raw and unfiltered as opposed to something like a blog post or a conference talk where you've gone through a whole editing phase; you've rehearsed it. And you've spoken at conferences before, and you're speaking again. You'll be at RubyConf Mini in a few weeks.

+ +

STEPHANIE: Yeah, I was thinking about my background because I actually come from a journalism background; that's what my degree is. And so I'm very comfortable in the role of editor, and I am a very obsessive and tedious editor when it comes to my own personal work in words and in code, I would say. The idea of putting stuff out there in a more unfiltered and less polished way is uncomfortable for me, but I want to get better at it, which is why I'm here because, like you were saying, in some ways, it's more realistic in just how we talk about some of these things at work.

+ +

I kind of want to remove the Instagram filter of talking about software and technical topics. And sometimes, we are just learning about things along the way. And I think that's one of the things that I've really appreciated about The Bike Shed in the past.

+ +

JOËL: Have you ever tried improv?

+ +

STEPHANIE: Oh my God. Once I took an improv class as a team bonding activity at an old job, and that was really something. I think we all collectively were not into the idea, but that's what we were doing. So we went to I a think comedy club or something in New York with my team at my first job. And it was actually a lot more fun than I thought it was going to be. I think the instructors knew that most people would not be super comfortable with improv, and so they did provide a lot of structure in terms of the types of exercises and games we played.

+ +

And we weren't doing improv comedy; we were just doing the exercises that would make us feel a little more comfortable and just having fun with it. Given some prompts, we would maybe walk across the room in a silly walk. And then the other person that we would walk to would imitate it, but it would be slightly different, and it would kind of evolve that way. So that's funny that you mentioned that. I had to really dig that memory from the archives [laughs] because I probably repressed it at some point.

+ +

JOËL: I've also done improv a couple of times in a similar setting to you, like a team-building activity. I really enjoyed it. And in many ways, I feel like podcasting can feel like the improv version of the content world.

+ +

STEPHANIE: Yes, and I agree.

+ +

[laughter]

+ +

JOËL: Yes, and very true.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So you'd mentioned earlier how our developer channel on Slack is just a fantastic resource. There are some great conversations that happen there, and a lot of them eventually I like them so much I want to pull them into The Bike Shed and make an episode inspired by them. And I had a conversation today about the impact of what matchers you choose when you write tests and how that might impact the code that you write. So, for example, an equality matcher is almost like the primitive obsession version of testing matchers in RSpec and how which one you pick might impact the implementation of your code.

+ +

An example of that might be if you have... let's say you're testing behavior on an order, and you might say you do some things, and you expect the order status to be the string or to equal the string pending. You've now exposed this internal of this order status string where instead you might using some of RSpec's automatic matchers for predicate methods, expect the order to be _pending because you now have a predicate method pending defined on your order.

+ +

So by choosing to use a more rich matcher, you may have actually improved the encapsulation of your object. I had never thought about matters in that way before. It kind of blew my mind, and so I'm still kind of chewing on that, and maybe some of the implications of it.

+ +

STEPHANIE: That's really interesting because, in my experience, I think I would reach for the more general matchers, the ones that seem to be more top of mind for me. And it takes an extra intentional thought to be like, oh, actually, I want this particular specific matcher to better reflect the behavior that I'm desiring.

+ +

JOËL: This just came out of a conversation because fellow thoughtboter, Mike Burns, has a blog post that just lists a bunch of almost code smells or things that make him raise an eyebrow during code review that might lead to a follow-up comment and asking for clarification about why that choice was used. And on that list is the RSpec eq matcher that checks for just regular equality. And so we went a little bit deep into why that might be the case, and that brought up a lot of really interesting ideas that I had not thought about before.

+ +

STEPHANIE: I'm curious if you are doing test-driven development if using a more specific selector. This is kind of the opposite of what I said earlier, but I guess I'm wondering if there's a possibility that it pigeonholes you into a particular implementation.

+ +

JOËL: It might pigeonhole you into a particular interface, and I'm still exploring the idea. I think that the richer matchers move you away from implementation. So, in this case, or in the case of the example I talked about earlier, all you know is that there's a predicate method pending on an order. You don't know whether it's implemented as a Boolean internally or if it's a string that is being checked or some other thing. Maybe it's a status code.

+ +

STEPHANIE: That's cool. Do you think you might explore this in your own work moving forward?

+ +

JOËL: In a recent episode with Amanda Beiner, we had a whole conversation about note-taking systems, and I talked about having a sort of personal knowledge base where I keep deeper thoughts about code. And I definitely added a couple of entries to that today based off of that conversation.

+ +

STEPHANIE: That's awesome. I totally know what you're talking about when you learn things or pick up little bits and pieces of information that you want to hold on to. But you might not have a particularly applicable project or codebase you're working in at the moment to apply that, but you want to hold on to it when you encounter that situation in the future. So I really like what you're saying about just adding it to your knowledge base and coming back to it.

+ +

JOËL: I think the next time I'm writing a test and I feel the need to reach for eq I will immediately think of this and ask myself, is there something else that might be better? And if other matches feel awkward, why? So it's going to definitely cause me to be a lot more thoughtful about the way I write assertions. I'm curious to see if that will have an impact on the types of designs that my tests drive.

+ +

STEPHANIE: Yeah, so maybe not a code smell but a code whiff.

+ +

JOËL: Definitely.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So one thing I've been thinking a lot about in my client project currently is working on features more incrementally. Right now, we are working on a rewrite of the front end of a legacy Rails app. So they did a big, modern refresh on the look of the app. And we are rewriting a bunch of the views to those specs. And all of this is happening behind a feature flag. So we are able to ship work incrementally and not have as much of an issue where all of this work is happening on one big branch.

+ +

But because a lot of this work builds on top of each other, I have been experiencing folks cutting branches off of feature branches, off of feature branches. And I've been thinking a lot about the intentional steps that we made to be able to deploy this in pieces and more safely but the friction that people still might have to work incrementally.

+ +

One thing that I've noticed is that there are different levels to how this shows up in our work. You can work incrementally on an individual level where you are in your own work writing small commits that capture individual pieces, and you can feel good about that. But then you also have it at a team level where we have to collectively decide how we want to ship features. And I am trying to figure out how to encourage other people to agree on an approach and encourage the benefits of shipping features in small chunks. Have you ever noticed a discrepancy between individual work and how a team works in that way?

+ +

JOËL: It sounds like what you're describing is that by encouraging the team to work in smaller chunks, it has made the Git and branching and merging process more complicated for the team as a whole. Maybe there's a bit of that tension whereby increasing the individual granularity; you're making the merging for the team more complex.

+ +

STEPHANIE: Yeah, we've had a lot of rebasing issues where we do spend a lot of time in that mode because one branch went through code review and had some changes and then went through UAT and had some changes. And then we had to reconcile those changes with another feature that had been started and cut off of that feature branch.

+ +

JOËL: That's really interesting because I feel like I've almost had the opposite experience. When I was a new developer, I would constantly get Git conflicts, and you have to figure out the merge, and it's a mess. And then eventually, I got decently good at resolving conflicts. Nowadays, I very rarely encounter conflicts, and the ones I get tend to be really minimal. And I think that's because I've started to really work incrementally and to keep my change sets small.

+ +

And so Git conflicts are not really something I run into very much anymore. And I tend to think of them now as more of a symptom of large patches and code changes that might be bigger than they need to be. Does that line up maybe with your experience as well?

+ +

STEPHANIE: Yeah, I think it does. But one area of friction that we are experiencing right now is that we may be working incrementally, but those changes don't make it all the way to our integration or production branches, and so they are still just hanging around. And we have had to fix merge conflicts, not necessarily with other people's work but with our own work where changes happened upstream, and then they kind of cascade down. So we are working in pieces. But because there is a little bit of process challenges that we're facing, we haven't quite closed the loop on that feedback cycle in a way that allows us to move as quickly as I think what you're describing.

+ +

JOËL: It sounds like maybe your team is bundling multiple incremental changes and then trying to merge a bundle of them together. So while it's composed of small, incremental changes, the effect is similar to merging a branch that's got a large change set together.

+ +

STEPHANIE: Yeah, that's exactly it.

+ +

JOËL: In my own work, I tend to really view commits as the atomic chunks of the work that I'm doing, so each of them is going to be very tightly scoped and do a single thing. Ideally, also pass all the tests and be independently mergeable. I tend to view PRs not so much as like a unit of work but just a unit of review, a way to get feedback on one or more commits. I don't want to put too many commits in a PR because then it's painful for the reviewer. But also, another reason that you got me thinking about is that trying to shove fewer commits in a PR will also make it easier to do that final merge.

+ +

STEPHANIE: Yeah, I know that I really appreciate when PRs are just one, maybe a few commits, but the overall diff is small. And in my opinion, I think we are able to move faster that way because reviews are quicker, conflicts are fewer. And it better captures the idea of working incrementally, even if it does involve more than a single, small atomic commit. And I would love to figure out how to move in that direction.

+ +

Right now, in my client project, one of the barriers is the processes we've built into the agile methodology we're following, where our PRs have to get a couple of approvals and then be tested by folks from product. And so it's sometimes easier to just add a little bit of things to an open PR already. But what we were talking about with incorporating more of that intentionality really pays the cost up front rather than just pushing it until later when we do run into problems with conflicts or having to go back to debug something that went in into a big bundled PR and then having to spend time and energy at that point in the lifecycle of our work.

+ +

JOËL: It's really interesting that you highlight the organizational impact and the process impacts. Definitely, when you increase the cost of merging when you make it like to merge a single PR, you're going to need to wait at least 24 hours because of all the other checks that need to go through, then people will tend to make larger PRs. And so sometimes it's not about programmer discipline or good habits even; it's about the process pressures that just really incentivize making larger PRs because of how expensive it is to open a new one.

+ +

I'm curious, though, in a perfect world, when you are reviewing a PR for some code written in Ruby on Rails, what is the max amount of lines that you'd want to see in a diff before you start thinking this is too big; I wish we could split it up?

+ +

STEPHANIE: I don't know if I have a number in my head. I want to say somewhere in the couple hundreds, maybe. I will love a PR where the diff is less than 100. That feels great to review and just feels right. I don't know; it's I don't open it and be like, ah, I have to now read through tens of files, some of which I have no context about. I like a tidy PR where everything that's changed is related to what the PR title is. What about you? Do you have a heuristic?

+ +

JOËL: I think I'm probably similar to you, 100 lines is probably about the cut-off for where it starts to become more of a chore to review a PR. I've definitely had moments where somebody sends me a link and says, "Hey, can you review?" And I click the link and I open it up, and I'm like, oh okay, well, I should set aside a half hour here to really get into this because this is not going to be quick.

+ +

STEPHANIE: For sure. And it also makes addressing that review feedback more difficult because you have to likely make more changes because there's just more to review and more to improve if it wasn't quite right the first time. The only time I do a big diff is if it's all in red. [laughter]

+ +

JOËL: Yes.

+ +

STEPHANIE: We have a Slack channel at thoughtbot called Dead Code Society where people post screenshots of their negative diffs, and it's so fun.

+ +

JOËL: I'm all for that. When I look at code that has been broken down into nice, small commits, it just looks so clean. It looks so natural. But when I try to write code like that, it's anything but; it doesn't feel natural. Have you had a similar experience?

+ +

STEPHANIE: I completely agree. I think it's really hard, and it's something that I am still practicing. Because when you are first learning to code, no one teaches you to write it incrementally; at least, that was my experience. It requires a lot of discipline to think about code in little, tiny chunks when you are just so excited to get your feature working and seeing it in a browser and playing around with it.

+ +

When I first started doing it, I thought it was impossible. I thought it was wild to have a single commit be passing CI all the time because when I was writing code, there were so many work in progresses. And then I would run the test suite and be like, ah, 20 test failures. Now I have to go through and fix all of them. I guess what I learned from that was the pain of not working incrementally, and that is what motivates me to be disciplined. And it doesn't always happen.

+ +

Sometimes I'm lazy and just decide that it's fine for now, and then will usually have to come back through when I am in that kind of headspace where I'm like, okay, let me really get down to business. And I'm able to see the seams of the code that I wrote to be able to extract them out into encapsulated pieces because that doesn't always come supernaturally. So yeah, I would say that it's an upward journey for sure. Do you find that to be true for your work?

+ +

JOËL: It has definitely been a journey. I think as I have gained experience, as I have discovered new techniques, even picked up different perspectives and mindsets, all of these have helped hone that skill. And I feel like it's one of those skills that feels very mundane, but it's actually one of the more valuable skills I have as a developer is able to take something complex and decompose it into atomic pieces.

+ +

STEPHANIE: Do you ever find yourselves in a position where there are obstacles that keep you from doing that, or would you say it's just an internal state of mind?

+ +

JOËL: Maybe a little bit of both. You'd mentioned earlier that there can be process or organizational obstacles that make it much harder to try to scope down the work that you have. It can be internal in that you don't know the tools that you need for this particular scenario. But it's something where you're constantly on the lookout for ways to learn to be better.

+ +

Over the course of your career, it is a skill that I think you're going to keep improving probably forever. I don't think you'll ever get to the point which is like, yep, I've mastered this. I'm as good as I will ever be, and that's the end. I'm curious, are there some tools or techniques that you like to use when trying to keep your work focused?

+ +

STEPHANIE: From a commit level, I really love the git add --patch command. I think that it is really helpful because I like to litter my code with random debuggers and little changes that I don't end up wanting to bring into my commit later on. And so that is a great place for me to discard things that I know are distractions or were part of little rabbit holes I went down along the way. And so I highly recommend folks to check that out if that's not something that's already familiar to them.

+ +

At a higher level, TDD has helped with staying focused because you have that built-in feedback loop. And once you are green, you can commit essentially and know that you did the least amount of work possible to get the behavior that you wanted without starting to sprawl into other territory. Joël, do you have any other tips or tools you want to share with our listeners?

+ +

JOËL: A sort of mental tool that I've gotten into recently is drawing things out as a directed graph to understand what are the changes that I need to accomplish my goal and then what changes rely on other changes being there first? And a directed graph, you just draw a bunch of circles with arrows pointing towards things that they depend on. Anytime there is a cycle, that chunk of changes all has to go out together. They're all sort of interdependent on each other.

+ +

And if you can find a way to restructure the graph or introduce a new step in there that will break the cycle, now individual pieces of that can be shipped independently. I've started using that visual approach sometimes to look at changes that feel like they're one sort of big blob of changes that can't be broken down and to say, oh, well, in order to ship this change, I need to introduce this new gem. I'm going to need to change behavior in this part of the system, but that will also need a change in another part of the system.

+ +

And now that I can see how things are connected to each other, it gives me a clue to where I can rearrange the changes. Maybe there's a refactor that I can ship out first completely separate that makes the follow-up work much easier. Or maybe there's a way that I can introduce some of the changes without needing to do all of them at once.

+ +

STEPHANIE: That's a really cool way to identify those pieces because it can be nearly impossible to figure it out from files in a repo or to keep in your head. And I think what's even cooler is that you can share those graphs too so someone else can come along and pick up that work, as well as just have the same level of understanding of what things depend on each other just through our clients.

+ +

JOËL: I've really fallen in love with directed graphs and dependency graphs, in particular over the past year, and I feel like now I see them everywhere. And regular listeners of the show will have noticed that I have mentioned them multiple times. And I almost feel now like I'm that Parks and Recs meme where he's got [laughter] all his conspiracy board with all the threads connecting to each other and just like, let me tell you about graphs and how everything is all connected. They're behind everything.

+ +

STEPHANIE: I'm with you. I think everything is connected, even just in our informal conversations on the pod and off the pod. We're constantly being like, oh, that's a great idea. Like, we can do a completely different episode if we go down this rabbit hole, but it also still maps back to things we talked about in another episode. And yeah, that feels very true to me in terms of software and also in terms of life, not to make that sound too deep. [laughs] But it's cool that you have found a way to manage that complexity for yourself at work and a way to share it with others.

+ +

JOËL: I think one of these days, we're going to have to do a dedicated episode all about dependency graphs.

+ +

STEPHANIE: Yeah, I would love to hear more. Too bad the podcast is just an auditory platform and not a visual one. [laughs]

+ +

JOËL: That's the challenge, right? Because it's such a visual topic.

+ +

STEPHANIE: That's cool. I'm really looking forward to hearing more about them. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + thoughtbotter Stephanie Minn joins The Bike Shed as co-host! 🎉

+ +

Joël and Stephanie talk about continuing on a rewrite and redesign of a legacy Rails app and working incrementally.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by someone very special, Stephanie Minn, who will be joining the podcast as a co-host.

+ +

STEPHANIE: Hi, Joël. It's me, Stephanie Minn. [laughs]

+ +

JOËL: Welcome to The Bike Shed.

+ +

STEPHANIE: Thanks. I am really excited to be here for the third time, I guess, but now in a more official capacity.

+ +

JOËL: And together, I think both of us are now excited to share a little bit of what we've learned along the way. So for the first time as a co-host, I'm happy to ask you the question, what's new in your world?

+ +

STEPHANIE: Well, I think I would have to say co-hosting this podcast. It's pretty big news for me, personally. I'm really pumped and also really nervous. I never thought I would co-host a podcast. But I have been a long-time listener of the show, and it feels very surreal to be here. I have big shoes to fill, even if I do have the same name as former co-host Steph Viccari.

+ +

It's funny; I listened to a previous episode of The Bike Shed this morning, where I had submitted a listener question about project estimation. It came out earlier this year. It was really funny because Steph and Chris had a whole bit about speaking to this other Stephanie out in the world. That was me. And now it's kind of come full circle that I am in this position now. So I thought that was kind of fun. Now I could just say hello to all the Stephs out there.

+ +

JOËL: Regular listeners will have recognized you because you've been a recent guest on a couple of different episodes, one where you talked about case expressions and how they fit into our style of programming. And then another one where we talked about the use of domain-specific or industry-specific vocabulary and jargon as a form of communication and how that plays out in the workplace. And for those who have not listened to those, we'll link them in the show notes if you want to catch up on the backlog.

+ +

STEPHANIE: I really enjoyed being a guest on the last few episodes. It was cool to see things that we talk about internally come up in a way that we want to share with a broader audience because I think some of the things that we get into in book club or in the dev channel on Slack end up being really interesting and sometimes not things that we always see out in the content world, and we can dig really deep into that with this format. So that is really exciting to me.

+ +

I think, in general, being on this podcast, I'm hoping in some ways will also be a growth opportunity for me because I am wanting to get more comfortable sharing my thoughts and ideas in a public space more frequently and informally. I'm very comfortable hoarding my thoughts until they're perfectly refined. And I'm like, okay, now I finally feel ready to share them in the form of a blog post or a talk.

+ +

But I kind of want to open myself up to hearing from others, different perspectives, being more comfortable being wrong in public, and changing my mind, and evolving how I work and what I think in this way because I think it's important to normalize that. Yeah, I don't know how I can be any more vulnerable than being on a podcast on the internet.

+ +

JOËL: Podcasting is really interesting because it's much more raw and unfiltered as opposed to something like a blog post or a conference talk where you've gone through a whole editing phase; you've rehearsed it. And you've spoken at conferences before, and you're speaking again. You'll be at RubyConf Mini in a few weeks.

+ +

STEPHANIE: Yeah, I was thinking about my background because I actually come from a journalism background; that's what my degree is. And so I'm very comfortable in the role of editor, and I am a very obsessive and tedious editor when it comes to my own personal work in words and in code, I would say. The idea of putting stuff out there in a more unfiltered and less polished way is uncomfortable for me, but I want to get better at it, which is why I'm here because, like you were saying, in some ways, it's more realistic in just how we talk about some of these things at work.

+ +

I kind of want to remove the Instagram filter of talking about software and technical topics. And sometimes, we are just learning about things along the way. And I think that's one of the things that I've really appreciated about The Bike Shed in the past.

+ +

JOËL: Have you ever tried improv?

+ +

STEPHANIE: Oh my God. Once I took an improv class as a team bonding activity at an old job, and that was really something. I think we all collectively were not into the idea, but that's what we were doing. So we went to I a think comedy club or something in New York with my team at my first job. And it was actually a lot more fun than I thought it was going to be. I think the instructors knew that most people would not be super comfortable with improv, and so they did provide a lot of structure in terms of the types of exercises and games we played.

+ +

And we weren't doing improv comedy; we were just doing the exercises that would make us feel a little more comfortable and just having fun with it. Given some prompts, we would maybe walk across the room in a silly walk. And then the other person that we would walk to would imitate it, but it would be slightly different, and it would kind of evolve that way. So that's funny that you mentioned that. I had to really dig that memory from the archives [laughs] because I probably repressed it at some point.

+ +

JOËL: I've also done improv a couple of times in a similar setting to you, like a team-building activity. I really enjoyed it. And in many ways, I feel like podcasting can feel like the improv version of the content world.

+ +

STEPHANIE: Yes, and I agree.

+ +

[laughter]

+ +

JOËL: Yes, and very true.

+ +

STEPHANIE: So, Joël, what's new in your world?

+ +

JOËL: So you'd mentioned earlier how our developer channel on Slack is just a fantastic resource. There are some great conversations that happen there, and a lot of them eventually I like them so much I want to pull them into The Bike Shed and make an episode inspired by them. And I had a conversation today about the impact of what matchers you choose when you write tests and how that might impact the code that you write. So, for example, an equality matcher is almost like the primitive obsession version of testing matchers in RSpec and how which one you pick might impact the implementation of your code.

+ +

An example of that might be if you have... let's say you're testing behavior on an order, and you might say you do some things, and you expect the order status to be the string or to equal the string pending. You've now exposed this internal of this order status string where instead you might using some of RSpec's automatic matchers for predicate methods, expect the order to be _pending because you now have a predicate method pending defined on your order.

+ +

So by choosing to use a more rich matcher, you may have actually improved the encapsulation of your object. I had never thought about matters in that way before. It kind of blew my mind, and so I'm still kind of chewing on that, and maybe some of the implications of it.

+ +

STEPHANIE: That's really interesting because, in my experience, I think I would reach for the more general matchers, the ones that seem to be more top of mind for me. And it takes an extra intentional thought to be like, oh, actually, I want this particular specific matcher to better reflect the behavior that I'm desiring.

+ +

JOËL: This just came out of a conversation because fellow thoughtboter, Mike Burns, has a blog post that just lists a bunch of almost code smells or things that make him raise an eyebrow during code review that might lead to a follow-up comment and asking for clarification about why that choice was used. And on that list is the RSpec eq matcher that checks for just regular equality. And so we went a little bit deep into why that might be the case, and that brought up a lot of really interesting ideas that I had not thought about before.

+ +

STEPHANIE: I'm curious if you are doing test-driven development if using a more specific selector. This is kind of the opposite of what I said earlier, but I guess I'm wondering if there's a possibility that it pigeonholes you into a particular implementation.

+ +

JOËL: It might pigeonhole you into a particular interface, and I'm still exploring the idea. I think that the richer matchers move you away from implementation. So, in this case, or in the case of the example I talked about earlier, all you know is that there's a predicate method pending on an order. You don't know whether it's implemented as a Boolean internally or if it's a string that is being checked or some other thing. Maybe it's a status code.

+ +

STEPHANIE: That's cool. Do you think you might explore this in your own work moving forward?

+ +

JOËL: In a recent episode with Amanda Beiner, we had a whole conversation about note-taking systems, and I talked about having a sort of personal knowledge base where I keep deeper thoughts about code. And I definitely added a couple of entries to that today based off of that conversation.

+ +

STEPHANIE: That's awesome. I totally know what you're talking about when you learn things or pick up little bits and pieces of information that you want to hold on to. But you might not have a particularly applicable project or codebase you're working in at the moment to apply that, but you want to hold on to it when you encounter that situation in the future. So I really like what you're saying about just adding it to your knowledge base and coming back to it.

+ +

JOËL: I think the next time I'm writing a test and I feel the need to reach for eq I will immediately think of this and ask myself, is there something else that might be better? And if other matches feel awkward, why? So it's going to definitely cause me to be a lot more thoughtful about the way I write assertions. I'm curious to see if that will have an impact on the types of designs that my tests drive.

+ +

STEPHANIE: Yeah, so maybe not a code smell but a code whiff.

+ +

JOËL: Definitely.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: So one thing I've been thinking a lot about in my client project currently is working on features more incrementally. Right now, we are working on a rewrite of the front end of a legacy Rails app. So they did a big, modern refresh on the look of the app. And we are rewriting a bunch of the views to those specs. And all of this is happening behind a feature flag. So we are able to ship work incrementally and not have as much of an issue where all of this work is happening on one big branch.

+ +

But because a lot of this work builds on top of each other, I have been experiencing folks cutting branches off of feature branches, off of feature branches. And I've been thinking a lot about the intentional steps that we made to be able to deploy this in pieces and more safely but the friction that people still might have to work incrementally.

+ +

One thing that I've noticed is that there are different levels to how this shows up in our work. You can work incrementally on an individual level where you are in your own work writing small commits that capture individual pieces, and you can feel good about that. But then you also have it at a team level where we have to collectively decide how we want to ship features. And I am trying to figure out how to encourage other people to agree on an approach and encourage the benefits of shipping features in small chunks. Have you ever noticed a discrepancy between individual work and how a team works in that way?

+ +

JOËL: It sounds like what you're describing is that by encouraging the team to work in smaller chunks, it has made the Git and branching and merging process more complicated for the team as a whole. Maybe there's a bit of that tension whereby increasing the individual granularity; you're making the merging for the team more complex.

+ +

STEPHANIE: Yeah, we've had a lot of rebasing issues where we do spend a lot of time in that mode because one branch went through code review and had some changes and then went through UAT and had some changes. And then we had to reconcile those changes with another feature that had been started and cut off of that feature branch.

+ +

JOËL: That's really interesting because I feel like I've almost had the opposite experience. When I was a new developer, I would constantly get Git conflicts, and you have to figure out the merge, and it's a mess. And then eventually, I got decently good at resolving conflicts. Nowadays, I very rarely encounter conflicts, and the ones I get tend to be really minimal. And I think that's because I've started to really work incrementally and to keep my change sets small.

+ +

And so Git conflicts are not really something I run into very much anymore. And I tend to think of them now as more of a symptom of large patches and code changes that might be bigger than they need to be. Does that line up maybe with your experience as well?

+ +

STEPHANIE: Yeah, I think it does. But one area of friction that we are experiencing right now is that we may be working incrementally, but those changes don't make it all the way to our integration or production branches, and so they are still just hanging around. And we have had to fix merge conflicts, not necessarily with other people's work but with our own work where changes happened upstream, and then they kind of cascade down. So we are working in pieces. But because there is a little bit of process challenges that we're facing, we haven't quite closed the loop on that feedback cycle in a way that allows us to move as quickly as I think what you're describing.

+ +

JOËL: It sounds like maybe your team is bundling multiple incremental changes and then trying to merge a bundle of them together. So while it's composed of small, incremental changes, the effect is similar to merging a branch that's got a large change set together.

+ +

STEPHANIE: Yeah, that's exactly it.

+ +

JOËL: In my own work, I tend to really view commits as the atomic chunks of the work that I'm doing, so each of them is going to be very tightly scoped and do a single thing. Ideally, also pass all the tests and be independently mergeable. I tend to view PRs not so much as like a unit of work but just a unit of review, a way to get feedback on one or more commits. I don't want to put too many commits in a PR because then it's painful for the reviewer. But also, another reason that you got me thinking about is that trying to shove fewer commits in a PR will also make it easier to do that final merge.

+ +

STEPHANIE: Yeah, I know that I really appreciate when PRs are just one, maybe a few commits, but the overall diff is small. And in my opinion, I think we are able to move faster that way because reviews are quicker, conflicts are fewer. And it better captures the idea of working incrementally, even if it does involve more than a single, small atomic commit. And I would love to figure out how to move in that direction.

+ +

Right now, in my client project, one of the barriers is the processes we've built into the agile methodology we're following, where our PRs have to get a couple of approvals and then be tested by folks from product. And so it's sometimes easier to just add a little bit of things to an open PR already. But what we were talking about with incorporating more of that intentionality really pays the cost up front rather than just pushing it until later when we do run into problems with conflicts or having to go back to debug something that went in into a big bundled PR and then having to spend time and energy at that point in the lifecycle of our work.

+ +

JOËL: It's really interesting that you highlight the organizational impact and the process impacts. Definitely, when you increase the cost of merging when you make it like to merge a single PR, you're going to need to wait at least 24 hours because of all the other checks that need to go through, then people will tend to make larger PRs. And so sometimes it's not about programmer discipline or good habits even; it's about the process pressures that just really incentivize making larger PRs because of how expensive it is to open a new one.

+ +

I'm curious, though, in a perfect world, when you are reviewing a PR for some code written in Ruby on Rails, what is the max amount of lines that you'd want to see in a diff before you start thinking this is too big; I wish we could split it up?

+ +

STEPHANIE: I don't know if I have a number in my head. I want to say somewhere in the couple hundreds, maybe. I will love a PR where the diff is less than 100. That feels great to review and just feels right. I don't know; it's I don't open it and be like, ah, I have to now read through tens of files, some of which I have no context about. I like a tidy PR where everything that's changed is related to what the PR title is. What about you? Do you have a heuristic?

+ +

JOËL: I think I'm probably similar to you, 100 lines is probably about the cut-off for where it starts to become more of a chore to review a PR. I've definitely had moments where somebody sends me a link and says, "Hey, can you review?" And I click the link and I open it up, and I'm like, oh okay, well, I should set aside a half hour here to really get into this because this is not going to be quick.

+ +

STEPHANIE: For sure. And it also makes addressing that review feedback more difficult because you have to likely make more changes because there's just more to review and more to improve if it wasn't quite right the first time. The only time I do a big diff is if it's all in red. [laughter]

+ +

JOËL: Yes.

+ +

STEPHANIE: We have a Slack channel at thoughtbot called Dead Code Society where people post screenshots of their negative diffs, and it's so fun.

+ +

JOËL: I'm all for that. When I look at code that has been broken down into nice, small commits, it just looks so clean. It looks so natural. But when I try to write code like that, it's anything but; it doesn't feel natural. Have you had a similar experience?

+ +

STEPHANIE: I completely agree. I think it's really hard, and it's something that I am still practicing. Because when you are first learning to code, no one teaches you to write it incrementally; at least, that was my experience. It requires a lot of discipline to think about code in little, tiny chunks when you are just so excited to get your feature working and seeing it in a browser and playing around with it.

+ +

When I first started doing it, I thought it was impossible. I thought it was wild to have a single commit be passing CI all the time because when I was writing code, there were so many work in progresses. And then I would run the test suite and be like, ah, 20 test failures. Now I have to go through and fix all of them. I guess what I learned from that was the pain of not working incrementally, and that is what motivates me to be disciplined. And it doesn't always happen.

+ +

Sometimes I'm lazy and just decide that it's fine for now, and then will usually have to come back through when I am in that kind of headspace where I'm like, okay, let me really get down to business. And I'm able to see the seams of the code that I wrote to be able to extract them out into encapsulated pieces because that doesn't always come supernaturally. So yeah, I would say that it's an upward journey for sure. Do you find that to be true for your work?

+ +

JOËL: It has definitely been a journey. I think as I have gained experience, as I have discovered new techniques, even picked up different perspectives and mindsets, all of these have helped hone that skill. And I feel like it's one of those skills that feels very mundane, but it's actually one of the more valuable skills I have as a developer is able to take something complex and decompose it into atomic pieces.

+ +

STEPHANIE: Do you ever find yourselves in a position where there are obstacles that keep you from doing that, or would you say it's just an internal state of mind?

+ +

JOËL: Maybe a little bit of both. You'd mentioned earlier that there can be process or organizational obstacles that make it much harder to try to scope down the work that you have. It can be internal in that you don't know the tools that you need for this particular scenario. But it's something where you're constantly on the lookout for ways to learn to be better.

+ +

Over the course of your career, it is a skill that I think you're going to keep improving probably forever. I don't think you'll ever get to the point which is like, yep, I've mastered this. I'm as good as I will ever be, and that's the end. I'm curious, are there some tools or techniques that you like to use when trying to keep your work focused?

+ +

STEPHANIE: From a commit level, I really love the git add --patch command. I think that it is really helpful because I like to litter my code with random debuggers and little changes that I don't end up wanting to bring into my commit later on. And so that is a great place for me to discard things that I know are distractions or were part of little rabbit holes I went down along the way. And so I highly recommend folks to check that out if that's not something that's already familiar to them.

+ +

At a higher level, TDD has helped with staying focused because you have that built-in feedback loop. And once you are green, you can commit essentially and know that you did the least amount of work possible to get the behavior that you wanted without starting to sprawl into other territory. Joël, do you have any other tips or tools you want to share with our listeners?

+ +

JOËL: A sort of mental tool that I've gotten into recently is drawing things out as a directed graph to understand what are the changes that I need to accomplish my goal and then what changes rely on other changes being there first? And a directed graph, you just draw a bunch of circles with arrows pointing towards things that they depend on. Anytime there is a cycle, that chunk of changes all has to go out together. They're all sort of interdependent on each other.

+ +

And if you can find a way to restructure the graph or introduce a new step in there that will break the cycle, now individual pieces of that can be shipped independently. I've started using that visual approach sometimes to look at changes that feel like they're one sort of big blob of changes that can't be broken down and to say, oh, well, in order to ship this change, I need to introduce this new gem. I'm going to need to change behavior in this part of the system, but that will also need a change in another part of the system.

+ +

And now that I can see how things are connected to each other, it gives me a clue to where I can rearrange the changes. Maybe there's a refactor that I can ship out first completely separate that makes the follow-up work much easier. Or maybe there's a way that I can introduce some of the changes without needing to do all of them at once.

+ +

STEPHANIE: That's a really cool way to identify those pieces because it can be nearly impossible to figure it out from files in a repo or to keep in your head. And I think what's even cooler is that you can share those graphs too so someone else can come along and pick up that work, as well as just have the same level of understanding of what things depend on each other just through our clients.

+ +

JOËL: I've really fallen in love with directed graphs and dependency graphs, in particular over the past year, and I feel like now I see them everywhere. And regular listeners of the show will have noticed that I have mentioned them multiple times. And I almost feel now like I'm that Parks and Recs meme where he's got [laughter] all his conspiracy board with all the threads connecting to each other and just like, let me tell you about graphs and how everything is all connected. They're behind everything.

+ +

STEPHANIE: I'm with you. I think everything is connected, even just in our informal conversations on the pod and off the pod. We're constantly being like, oh, that's a great idea. Like, we can do a completely different episode if we go down this rabbit hole, but it also still maps back to things we talked about in another episode. And yeah, that feels very true to me in terms of software and also in terms of life, not to make that sound too deep. [laughs] But it's cool that you have found a way to manage that complexity for yourself at work and a way to share it with others.

+ +

JOËL: I think one of these days, we're going to have to do a dedicated episode all about dependency graphs.

+ +

STEPHANIE: Yeah, I would love to hear more. Too bad the podcast is just an auditory platform and not a visual one. [laughs]

+ +

JOËL: That's the challenge, right? Because it's such a visual topic.

+ +

STEPHANIE: That's cool. I'm really looking forward to hearing more about them. On that note, shall we wrap up?

+ +

JOËL: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+e2P4WmMW + + ]]> + + Joël Quenneville + Stephanie Minn + + + 360: ActiveRecord Models + https://bikeshed.thoughtbot.com/360 + 33841350-be6a-473d-84e4-7c99fb703150 + Tue, 01 Nov 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Fellow thoughtboter Sarah Lima joins Joël to discuss an issue Sarah had when she was doing a code review recently: making HTTP requests in an ActiveRecord model. Her concern with that approach was that a class was having too many responsibilities that would break the single-responsibility principle, and that it would make the class hard to maintain. Because the ActiveRecord layer is a layer that's meant to encapsulate business roles and data, her issue was that adding another responsibility on top of it would be too much. Her solution was to extract a class that would handle the whole HTTP request process. + 28:37 + no + + + Fellow thoughtboter Sarah Lima joins Joël to discuss an issue Sarah had when she was doing a code review recently: making HTTP requests in an ActiveRecord model. Her concern with that approach was that a class was having too many responsibilities that would break the single-responsibility principle, and that it would make the class hard to maintain. Because the ActiveRecord layer is a layer that's meant to encapsulate business roles and data, her issue was that adding another responsibility on top of it would be too much. Her solution was to extract a class that would handle the whole HTTP request process. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +SQL TRIM() (https://popsql.com/learn-sql/postgresql/how-to-trim-strings-in-postgresql) +Iteration as an anti-pattern (https://thoughtbot.com/blog/iteration-as-an-anti-pattern) +WET tests (https://thoughtbot.com/blog/the-case-for-wet-tests) +thoughtbot code review guidelines (https://github.com/thoughtbot/guides/tree/main/code-review) +Side effects in tests (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) +Active Resource (https://github.com/rails/activeresource) +Different strategies for 3rd party requests (https://thoughtbot.com/blog/testing-third-party-interactions) +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. And today, I'm joined by fellow thoughtboter Sarah Lima. +SARAH: Happy to be here. +JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Sarah, what's new in your world? +SARAH: Well, after a year and a half working on the same thoughtbot client, I have rolled off, and I have joined a new team. And I am learning a lot about not only a new codebase but learning to work with a new team. So that's always challenging, and this time it's not different. +JOËL: What is something that you like to do when joining a new team to help smooth the onboarding process? +SARAH: Well, I think especially getting to know people with one on ones. This time, I didn't do that right away because I had a bunch of time off scheduled right at the beginning of the project. But I did it right after I came back. And I'm learning a lot about my new colleagues, how they like to work, how they learn best. So, for instance, there are some people that like to learn and grow by reading blog posts, reading books, and there are other people that don't like that as much. +JOËL: So when you joined the new project, you just reached out to all of these people and set up a few meetings just to get to know them. +SARAH: Yeah, exactly. +JOËL: That's really good. I've never done that on a project. And now that you've said it, it kind of seems obvious. Maybe I should do that moving forward to get to know new teammates. +SARAH: Yeah. And I think it's easier on my project because it's a very small team. There are four of us thoughtboters, and there are just two client developers. So it was easier. +JOËL: What about on the code side of things? Are there any tricks you like to do when you're first getting started in a new codebase? +SARAH: Well, I think I really enjoy diving in right away, working on something small, and asking questions. I have also found it helpful in the past, especially on larger codebases, that someone that's experienced on a project gives me an overview showing me the quirks. And, of course, a good README is always a good thing to have, and during the process, always be updating the README. In this recent project, it was not different. I opened a lot of PRs to update the README. So that was good to have a PR right on your first day. +JOËL: I love that. I think that's usually my goal when I start on a new project is to have a PR the first day that fixes anything in the setup script that has been broken since the last person onboarded or documentation that was wrong. +SARAH: Yeah, absolutely. +JOËL: It's always a strong first contribution. +SARAH: Yeah. What about you, Joël? What's going on? What's new in your world? +JOËL: I've been investigating flaky tests, and I ran across a wild bug this week. I had a test that would fail every now and then. And it was pulling some data from Postgres and then doing some transformations on it. And I couldn't figure out why it was failing. It was a complex query. So it was just pulling out not ActiveRecord objects but a raw array of values. At some point, I was putting a PUT statement in the code with the array of values I expected to get and the array I would actually get. +And I was surprised to see that there is a field in there that is a float that was rounded to a different number of decimal places. I was like, that doesn't seem right. And so I was digging into it more, and I found out that this decimal value is from a timestamp that is in a file name for an mp4 video file name. And what is happening is that when we're querying the database, we're trying to extract the timestamp out of the file name by dropping the .mp4 file extension. And we're using the SQL TRIM function. +Unfortunately, TRIM does not do whatever the original authors thought it does. It doesn't just remove that substring from the end, but instead, it will remove any of those characters, so in my case, any of dot, M, P, or 4 in any combination from the end of the string. So anytime that my timestamp ended in a four, any fours were just getting chopped off. So if it ended in 44.mp4, the 44 would also get removed, not just the .mp4, which meant that randomly whenever a timestamp happened to end in 4, my test would flake. +SARAH: Wow. Do you have any idea how much time you spent debugging that? +JOËL: Oh, probably took, I'd say, a day, two days. This is spread over a couple of debugging sessions. But eventually, finding that particular location for the bug probably took us a couple of days. In the end, the bug fix for this is just a couple of lines, a couple of days work, and the diff is only a few lines. But I'm sure that the discussion on the PR is going to be really interesting. There's probably going to be a description that is a lot longer than the actual diff. +SARAH: Yeah, 100%. [laughs] +JOËL: Have you run across any interesting PRs on your new project? +SARAH: Yeah, I did. In fact, I recently reviewed a PR that had three interesting main issues that I wanted to address. And I wanted to lead the person that was working on it to a slightly better solution. So the three issues I saw were that the tests that were added were very DRY, so that was making everything a bit difficult to understand. The second one was that I saw one of the ActiveRecord classes was making HTTP requests, and that didn't sound like a good idea to me. +JOËL: That is unusual. +SARAH: Yes. The third one was that there were a lot of collections being built iteratively where another innumerable method would be a better fit, such as map instead of an each call. +JOËL: Oh, this is a classic situation where you're just using each to go through and transform something, and you've got some sort of external array that you're mutating as part of the each. +SARAH: Yes. +JOËL: There's a great thought article, I believe, by Joe Ferris on Iteration as an Anti-pattern. +SARAH: I think it's by Mike Burns. And I have referred to that article. In fact, I had very good articles for two of these three problems. I referred to a bunch of articles about WET tests as opposed to DRY tests, like how striving for tests that are DRY is not a good idea as opposed to telling a whole story in your tests. And I referred to that other article how iteratively building a collection can be an anti-pattern by Mike Burns. But the second issue about HTTP requests I didn't have anything to refer to. Maybe we should write one. +JOËL: This reminds me that in the thoughtbot Slack, we have a custom emoji for you should write a blog post about that. And this would probably be a good time to use it. +SARAH: Yes. So, Joël, how do you typically handle a PR that is maybe too long, and you have a lot of concerns about it? And how do you handle delivering that feedback? +JOËL: Oh, that is a challenge. I've definitely done it poorly in the past. And I think the wrong way to go about that situation is to go thoroughly through the PR and leave 50, 60 comments. That is overwhelming for the other person. And they're going to have a really bad day when they see 50 comments come through. And there's so much that they can't really address the main things you were talking about anyway. +So what I generally try to do, and it's kind of nice now that GitHub doesn't immediately publish your comments, is if I realize...like I start putting some more detailed comments, and then I realize, oh, there's going to be a lot, zoom out a little bit, and try to find are there some higher level trends that I can talk about? And maybe even just summarize in a larger comment at the bottom and say, "Hey, I see some larger structural issues," or "This PR is leaning very heavily on a technique that I think is maybe not the best use here. Maybe we should discuss that," instead of digging into maybe the actual implementation details of the code. +SARAH: Yeah, funny, you should mention that. I have recently also started doing that, using the summary version of GitHub reviews. And I used to just go file by file and leaving comments right away. And I'm thinking that this is not a good idea, especially when the PR is long. So I think another thing I would do is also call the person to pair and ask questions and understand where the person is coming from and also explain what are your concerns and how you both can get to a better place with that PR. +JOËL: That's really important. You have to remember there's another person on the other end of this. I love the idea of reaching out to them directly. Especially if there's a larger conversation to be had around approach or implementation, it's often easier to resolve those directly rather than back and forth in GitHub comments. So you mentioned situations where the PR is really long. Have you ever had to push back on that in some way? +SARAH: Yes. Especially when I saw, whoa, that's going to be difficult to understand, that's going to be difficult to review. And I have reached out to the person to say, "Hey, what about we split that PR in two?" Of course thinking about splitting the PR in a way that makes sense, in a way that still delivers our users’ value as soon as possible. +JOËL: I've been in situations like that where it's a really long PR, and the person has already invested a lot of work into it. And maybe it's even gone through a round of reviews. It feels almost too late to ask them to split up the work. But then I've actually regretted not doing that because there's so much complexity going on that then it doesn't work, or there are some bugs in it. We struggle to ship this, or it might just have to go through so many rounds of review and re-review and re-review. And because the PR is so long, it's a huge commitment for me to re-review it every time. +So there are situations I've been in where I wish that before even looking at the code at all, I was like, this is too long. We need to either slim down the story of what's being done. Because sometimes that's what happens is that the ticket is not well-defined, and someone goes in and just sort of keeps adding more code. And it becomes a bit of a big ball of mud. So, either helping to refine the ticket first or splitting the PR rather than actually looking at the code. +SARAH: Yeah, and pairing often can also help with that. So especially as consultants, our clients may ask us to work on different projects, and you work alone. And you may have tight deadlines, but I think it's always helpful to find time anyway to help your colleagues as well. +JOËL: I like that. I think there's a lot of value in the work that we do, where we collaborate with others in addition to whatever we do solo. So, oftentimes, it's great to pair with people at a client where possible to become involved in the code review process to even get involved in maybe some of the more broader system design conversations, sprint planning. All of those things are really good to jump into more than just getting siloed into working on just a solo feature. +SARAH: Yes, 100%. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So one of the things you mentioned that stood out for you when you were doing some code review recently was making HTTP requests in an ActiveRecord model. Why is that something that sort of caught your eyes, maybe an area to push back on in a particular design? +SARAH: That's a good question. My concern with that approach was that our class was having too many responsibilities that would break the SRP principle, the single-responsibility principle, and that would make our class hard to maintain. So the ActiveRecord layer is a layer that's meant to encapsulate business roles and data. So I was worried that adding another responsibility on top of it would be too much. So my idea was that we would extract a class that would handle the whole HTTP request process. +JOËL: Yeah, I feel like my instincts typically when I've done third-party integrations is that the ActiveRecord class should not know about the external internet world. It knows about the database. It knows about some of its core model functionality but that knowing about the internet world is somebody else's responsibility and that, ideally, the direction of dependency should flow the other way. So maybe the class that makes an external request knows about the ActiveRecord object if it needs to let's say, instantiate an instance of that model using data from an external request. +Or maybe it's even some third-party thing; maybe it's their controller that knows how to make or that will ask another object to make a request to some API and might also make a request to the model and ask it for some database data and then combine those two together. But that the ActiveRecord object only knows about that database area of responsibility and doesn't know that other things are also happening in the system. +SARAH: Absolutely. And I was also thinking that that class would have a difficult test to write. So a good idea is to separate our code that is side-effectful into their own classes, and that makes our tests so much easier. +JOËL: I actually wrote an article on the topic where one of my realizations at some point was that a lot of the pain points in code are what functional programmers would call side effects, so things like HTTP requests. And these are often things where we need to stub or do other things. And so isolating them as much as possible often simplifies our tests. +SARAH: Yeah, certainly. And I refer to that article every time I have the chance. +JOËL: Have you encountered the general concept of layered architectures, or hexagonal architectures, or things like that in the world of Rails or maybe elsewhere? +SARAH: Not hexagonal architecture. I have heard about it, but I haven't dived into it yet. Can you give us an overview? +JOËL: So I've also not worked with an actual hexagonal architecture. But the general idea, I guess, of layered architectures is that you build your code in a variety of layers, and different layers don't have access to or don't know about the ones...and I forget in this model if it's above or below, let's say it's below. So the inner layers don't know about the outer layers, but the outer layers can know about anything below them. +And so if the core of your app is the database, your database is most definitely not knowing about anything outside of just its data. And your ActiveRecord models that sit on top of that know about the database, but they don't know if they're being fronted by a web application, or a command line, or anything else. And then, above that, you might have more of a business process layer that knows about the database. It might know about how to make some external requests, but it doesn't know about anything above that. +And then, maybe at the final layer, you've got an application layer that handles things like controllers and interactions with users of the site. The core idea is that you split it into layers, and the higher-up layers know about everything below them, but no layer knows about what's above it. I feel like we're loosely applying that to the situation here with ActiveRecord in that it feels like the ActiveRecord layer if you will, shouldn't really know about third-party API requests. +SARAH: So, one exception to that is the ActiveResource approach that connects our business objects to REST services. So if you have an external website and you want to connect it via HTTP, you can do it using Rails ActiveResource. +JOËL: That is interesting because it functions like an ActiveRecord object, but instead of being backed by the database, it's backed by some kind of API. I almost wonder if...let's refactor our mental model here. And instead of saying that HTTP belongs in a separate layer that's higher up, maybe, in this case, it's almost like a sibling layer. +So your ActiveRecord models know about the database, and they make database requests in ActiveResource, or I think there are some gems that provide similar behavior. It might be backed by a particular API, but neither of them should know about the other. So maybe an ActiveResource model should not be making database requests. +SARAH: Yes, I like that line of thought. +JOËL: I guess the question then becomes, what about interactions between the two where you want to, I don't know, have some kind of association? You know, I don't think I've ever used ActiveResource on a project. +SARAH: I did once when trying to work with something close to microservice architecture. So we had a monolith, and we built a small service that was also in Rails, and we needed to consume the data that was stored in the monolith. +JOËL: And did you like that approach? +SARAH: Yeah. I think in that specific scenario, it was very productive. And I enjoyed a lot the API that Rails provided me via ActiveResources. +JOËL: Did you ever have to mix ActiveResource models and ActiveRecord models? +SARAH: No, I didn't; thankfully, not. I have never thought about that. +JOËL: So maybe in most applications, those two will just sort of naturally fall into maybe separate parts of the app, and they don't need to interact that much. +SARAH: Yeah, I think that will be the case. So mixing two of those subjects we're talking about here, that's testing and HTTP requests; we've been having a discussion in our project about the usage of VCR. That's a gem that records your HTTP requests interactions and replays them during tests. We've been discussing if using it is a good idea or not because we've been having issues with cassettes, that's one of VCR's concepts when these cassettes are not valid anymore. So do you have any thoughts on the subject? Maybe that will make a whole episode. +JOËL: We could definitely do a whole episode, I think, on testing third-party APIs. VCR is one of multiple different strategies that can be used to not make actual real network requests in your tests which brings some stability. There are also some downsides to it. I have found, in general, that over time, cassettes become brittle. So the idea of VCR is really cool. In practice, I think I've found that a few hand-rolled Webmock stubs usually do the job better for my needs. +SARAH: Yeah, I'll be interested in hearing that episode because, at least in my project, we have a lot of HTTP requests to external services, and they return a lot of information. I'm wondering if just dealing with that with Webmock would be too much work. +JOËL: One of the really useful things about VCR is that you can just make your request from anywhere, and it will just completely handle it. In some ways, though, I think it maybe hides some of that test pain that we were talking about earlier and allows you to sort of put HTTP in a lot of places that maybe you don't want it to. And by allowing yourself to feel a little bit of that test pain, you can more easily notice the places where maybe an object should not be making a request. +Or the actual HTTP logic can be moved to a concentrated place where all the HTTP is done together. And then only that object will need unit tests that actually need to mock the network, and most of your objects are fine. Where it gets interesting is more for things like integration tests, where now you're doing a lot of interactions, and you might have quite a few background requests that need to be made. +SARAH: I'm looking forward to the whole episode on this subject because I feel there's so much to talk about. +JOËL: There really is. I have a blog post that sort of summarizes a few different common categories of approaches to testing third-party requests, which might be different depending on whether you're doing a unit test or an integration test. But I grouped common solutions into four different categories. We'll make sure to link that in the show notes. So we've been talking a lot about testing. I'm curious when you review PR, do you start with the tests, maybe read through the tests first, and then the implementation? +SARAH: That's a good question. I have never thought about starting with tests. I think I'm going to give that a try anytime. But I just start reviewing them like by the first file that comes up. [laughs] +JOËL: I'm the same. I normally just do them in order. I have occasionally tried to do a test first, and that is sometimes interesting. Sometimes you read the test and, especially when you don't know what the implementation is going to be, you're like, why is this in the test? And then you jump to the implementation like, oh, that's what's going on. +Well, thank you so much, Sarah, for joining us on this whirlwind tour of code review, design of objects, and interacting with HTTP and testing. +SARAH: My pleasure. +JOËL: Where can people find you online if they would like to follow your work? +SARAH: I'm on Twitter @sarahlima_rb. +JOËL: We'll make sure to link that in the show notes. And with that, let's wrap up. +The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Fellow thoughtboter Sarah Lima joins Joël to discuss an issue Sarah had when she was doing a code review recently: making HTTP requests in an ActiveRecord model. Her concern with that approach was that a class was having too many responsibilities that would break the single-responsibility principle, and that it would make the class hard to maintain. Because the ActiveRecord layer is a layer that's meant to encapsulate business roles and data, her issue was that adding another responsibility on top of it would be too much. Her solution was to extract a class that would handle the whole HTTP request process.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by fellow thoughtboter Sarah Lima.

+ +

SARAH: Happy to be here.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Sarah, what's new in your world?

+ +

SARAH: Well, after a year and a half working on the same thoughtbot client, I have rolled off, and I have joined a new team. And I am learning a lot about not only a new codebase but learning to work with a new team. So that's always challenging, and this time it's not different.

+ +

JOËL: What is something that you like to do when joining a new team to help smooth the onboarding process?

+ +

SARAH: Well, I think especially getting to know people with one on ones. This time, I didn't do that right away because I had a bunch of time off scheduled right at the beginning of the project. But I did it right after I came back. And I'm learning a lot about my new colleagues, how they like to work, how they learn best. So, for instance, there are some people that like to learn and grow by reading blog posts, reading books, and there are other people that don't like that as much.

+ +

JOËL: So when you joined the new project, you just reached out to all of these people and set up a few meetings just to get to know them.

+ +

SARAH: Yeah, exactly.

+ +

JOËL: That's really good. I've never done that on a project. And now that you've said it, it kind of seems obvious. Maybe I should do that moving forward to get to know new teammates.

+ +

SARAH: Yeah. And I think it's easier on my project because it's a very small team. There are four of us thoughtboters, and there are just two client developers. So it was easier.

+ +

JOËL: What about on the code side of things? Are there any tricks you like to do when you're first getting started in a new codebase?

+ +

SARAH: Well, I think I really enjoy diving in right away, working on something small, and asking questions. I have also found it helpful in the past, especially on larger codebases, that someone that's experienced on a project gives me an overview showing me the quirks. And, of course, a good README is always a good thing to have, and during the process, always be updating the README. In this recent project, it was not different. I opened a lot of PRs to update the README. So that was good to have a PR right on your first day.

+ +

JOËL: I love that. I think that's usually my goal when I start on a new project is to have a PR the first day that fixes anything in the setup script that has been broken since the last person onboarded or documentation that was wrong.

+ +

SARAH: Yeah, absolutely.

+ +

JOËL: It's always a strong first contribution.

+ +

SARAH: Yeah. What about you, Joël? What's going on? What's new in your world?

+ +

JOËL: I've been investigating flaky tests, and I ran across a wild bug this week. I had a test that would fail every now and then. And it was pulling some data from Postgres and then doing some transformations on it. And I couldn't figure out why it was failing. It was a complex query. So it was just pulling out not ActiveRecord objects but a raw array of values. At some point, I was putting a PUT statement in the code with the array of values I expected to get and the array I would actually get.

+ +

And I was surprised to see that there is a field in there that is a float that was rounded to a different number of decimal places. I was like, that doesn't seem right. And so I was digging into it more, and I found out that this decimal value is from a timestamp that is in a file name for an mp4 video file name. And what is happening is that when we're querying the database, we're trying to extract the timestamp out of the file name by dropping the .mp4 file extension. And we're using the SQL TRIM function.

+ +

Unfortunately, TRIM does not do whatever the original authors thought it does. It doesn't just remove that substring from the end, but instead, it will remove any of those characters, so in my case, any of dot, M, P, or 4 in any combination from the end of the string. So anytime that my timestamp ended in a four, any fours were just getting chopped off. So if it ended in 44.mp4, the 44 would also get removed, not just the .mp4, which meant that randomly whenever a timestamp happened to end in 4, my test would flake.

+ +

SARAH: Wow. Do you have any idea how much time you spent debugging that?

+ +

JOËL: Oh, probably took, I'd say, a day, two days. This is spread over a couple of debugging sessions. But eventually, finding that particular location for the bug probably took us a couple of days. In the end, the bug fix for this is just a couple of lines, a couple of days work, and the diff is only a few lines. But I'm sure that the discussion on the PR is going to be really interesting. There's probably going to be a description that is a lot longer than the actual diff.

+ +

SARAH: Yeah, 100%. [laughs]

+ +

JOËL: Have you run across any interesting PRs on your new project?

+ +

SARAH: Yeah, I did. In fact, I recently reviewed a PR that had three interesting main issues that I wanted to address. And I wanted to lead the person that was working on it to a slightly better solution. So the three issues I saw were that the tests that were added were very DRY, so that was making everything a bit difficult to understand. The second one was that I saw one of the ActiveRecord classes was making HTTP requests, and that didn't sound like a good idea to me.

+ +

JOËL: That is unusual.

+ +

SARAH: Yes. The third one was that there were a lot of collections being built iteratively where another innumerable method would be a better fit, such as map instead of an each call.

+ +

JOËL: Oh, this is a classic situation where you're just using each to go through and transform something, and you've got some sort of external array that you're mutating as part of the each.

+ +

SARAH: Yes.

+ +

JOËL: There's a great thought article, I believe, by Joe Ferris on Iteration as an Anti-pattern.

+ +

SARAH: I think it's by Mike Burns. And I have referred to that article. In fact, I had very good articles for two of these three problems. I referred to a bunch of articles about WET tests as opposed to DRY tests, like how striving for tests that are DRY is not a good idea as opposed to telling a whole story in your tests. And I referred to that other article how iteratively building a collection can be an anti-pattern by Mike Burns. But the second issue about HTTP requests I didn't have anything to refer to. Maybe we should write one.

+ +

JOËL: This reminds me that in the thoughtbot Slack, we have a custom emoji for you should write a blog post about that. And this would probably be a good time to use it.

+ +

SARAH: Yes. So, Joël, how do you typically handle a PR that is maybe too long, and you have a lot of concerns about it? And how do you handle delivering that feedback?

+ +

JOËL: Oh, that is a challenge. I've definitely done it poorly in the past. And I think the wrong way to go about that situation is to go thoroughly through the PR and leave 50, 60 comments. That is overwhelming for the other person. And they're going to have a really bad day when they see 50 comments come through. And there's so much that they can't really address the main things you were talking about anyway.

+ +

So what I generally try to do, and it's kind of nice now that GitHub doesn't immediately publish your comments, is if I realize...like I start putting some more detailed comments, and then I realize, oh, there's going to be a lot, zoom out a little bit, and try to find are there some higher level trends that I can talk about? And maybe even just summarize in a larger comment at the bottom and say, "Hey, I see some larger structural issues," or "This PR is leaning very heavily on a technique that I think is maybe not the best use here. Maybe we should discuss that," instead of digging into maybe the actual implementation details of the code.

+ +

SARAH: Yeah, funny, you should mention that. I have recently also started doing that, using the summary version of GitHub reviews. And I used to just go file by file and leaving comments right away. And I'm thinking that this is not a good idea, especially when the PR is long. So I think another thing I would do is also call the person to pair and ask questions and understand where the person is coming from and also explain what are your concerns and how you both can get to a better place with that PR.

+ +

JOËL: That's really important. You have to remember there's another person on the other end of this. I love the idea of reaching out to them directly. Especially if there's a larger conversation to be had around approach or implementation, it's often easier to resolve those directly rather than back and forth in GitHub comments. So you mentioned situations where the PR is really long. Have you ever had to push back on that in some way?

+ +

SARAH: Yes. Especially when I saw, whoa, that's going to be difficult to understand, that's going to be difficult to review. And I have reached out to the person to say, "Hey, what about we split that PR in two?" Of course thinking about splitting the PR in a way that makes sense, in a way that still delivers our users’ value as soon as possible.

+ +

JOËL: I've been in situations like that where it's a really long PR, and the person has already invested a lot of work into it. And maybe it's even gone through a round of reviews. It feels almost too late to ask them to split up the work. But then I've actually regretted not doing that because there's so much complexity going on that then it doesn't work, or there are some bugs in it. We struggle to ship this, or it might just have to go through so many rounds of review and re-review and re-review. And because the PR is so long, it's a huge commitment for me to re-review it every time.

+ +

So there are situations I've been in where I wish that before even looking at the code at all, I was like, this is too long. We need to either slim down the story of what's being done. Because sometimes that's what happens is that the ticket is not well-defined, and someone goes in and just sort of keeps adding more code. And it becomes a bit of a big ball of mud. So, either helping to refine the ticket first or splitting the PR rather than actually looking at the code.

+ +

SARAH: Yeah, and pairing often can also help with that. So especially as consultants, our clients may ask us to work on different projects, and you work alone. And you may have tight deadlines, but I think it's always helpful to find time anyway to help your colleagues as well.

+ +

JOËL: I like that. I think there's a lot of value in the work that we do, where we collaborate with others in addition to whatever we do solo. So, oftentimes, it's great to pair with people at a client where possible to become involved in the code review process to even get involved in maybe some of the more broader system design conversations, sprint planning. All of those things are really good to jump into more than just getting siloed into working on just a solo feature.

+ +

SARAH: Yes, 100%.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So one of the things you mentioned that stood out for you when you were doing some code review recently was making HTTP requests in an ActiveRecord model. Why is that something that sort of caught your eyes, maybe an area to push back on in a particular design?

+ +

SARAH: That's a good question. My concern with that approach was that our class was having too many responsibilities that would break the SRP principle, the single-responsibility principle, and that would make our class hard to maintain. So the ActiveRecord layer is a layer that's meant to encapsulate business roles and data. So I was worried that adding another responsibility on top of it would be too much. So my idea was that we would extract a class that would handle the whole HTTP request process.

+ +

JOËL: Yeah, I feel like my instincts typically when I've done third-party integrations is that the ActiveRecord class should not know about the external internet world. It knows about the database. It knows about some of its core model functionality but that knowing about the internet world is somebody else's responsibility and that, ideally, the direction of dependency should flow the other way. So maybe the class that makes an external request knows about the ActiveRecord object if it needs to let's say, instantiate an instance of that model using data from an external request.

+ +

Or maybe it's even some third-party thing; maybe it's their controller that knows how to make or that will ask another object to make a request to some API and might also make a request to the model and ask it for some database data and then combine those two together. But that the ActiveRecord object only knows about that database area of responsibility and doesn't know that other things are also happening in the system.

+ +

SARAH: Absolutely. And I was also thinking that that class would have a difficult test to write. So a good idea is to separate our code that is side-effectful into their own classes, and that makes our tests so much easier.

+ +

JOËL: I actually wrote an article on the topic where one of my realizations at some point was that a lot of the pain points in code are what functional programmers would call side effects, so things like HTTP requests. And these are often things where we need to stub or do other things. And so isolating them as much as possible often simplifies our tests.

+ +

SARAH: Yeah, certainly. And I refer to that article every time I have the chance.

+ +

JOËL: Have you encountered the general concept of layered architectures, or hexagonal architectures, or things like that in the world of Rails or maybe elsewhere?

+ +

SARAH: Not hexagonal architecture. I have heard about it, but I haven't dived into it yet. Can you give us an overview?

+ +

JOËL: So I've also not worked with an actual hexagonal architecture. But the general idea, I guess, of layered architectures is that you build your code in a variety of layers, and different layers don't have access to or don't know about the ones...and I forget in this model if it's above or below, let's say it's below. So the inner layers don't know about the outer layers, but the outer layers can know about anything below them.

+ +

And so if the core of your app is the database, your database is most definitely not knowing about anything outside of just its data. And your ActiveRecord models that sit on top of that know about the database, but they don't know if they're being fronted by a web application, or a command line, or anything else. And then, above that, you might have more of a business process layer that knows about the database. It might know about how to make some external requests, but it doesn't know about anything above that.

+ +

And then, maybe at the final layer, you've got an application layer that handles things like controllers and interactions with users of the site. The core idea is that you split it into layers, and the higher-up layers know about everything below them, but no layer knows about what's above it. I feel like we're loosely applying that to the situation here with ActiveRecord in that it feels like the ActiveRecord layer if you will, shouldn't really know about third-party API requests.

+ +

SARAH: So, one exception to that is the ActiveResource approach that connects our business objects to REST services. So if you have an external website and you want to connect it via HTTP, you can do it using Rails ActiveResource.

+ +

JOËL: That is interesting because it functions like an ActiveRecord object, but instead of being backed by the database, it's backed by some kind of API. I almost wonder if...let's refactor our mental model here. And instead of saying that HTTP belongs in a separate layer that's higher up, maybe, in this case, it's almost like a sibling layer.

+ +

So your ActiveRecord models know about the database, and they make database requests in ActiveResource, or I think there are some gems that provide similar behavior. It might be backed by a particular API, but neither of them should know about the other. So maybe an ActiveResource model should not be making database requests.

+ +

SARAH: Yes, I like that line of thought.

+ +

JOËL: I guess the question then becomes, what about interactions between the two where you want to, I don't know, have some kind of association? You know, I don't think I've ever used ActiveResource on a project.

+ +

SARAH: I did once when trying to work with something close to microservice architecture. So we had a monolith, and we built a small service that was also in Rails, and we needed to consume the data that was stored in the monolith.

+ +

JOËL: And did you like that approach?

+ +

SARAH: Yeah. I think in that specific scenario, it was very productive. And I enjoyed a lot the API that Rails provided me via ActiveResources.

+ +

JOËL: Did you ever have to mix ActiveResource models and ActiveRecord models?

+ +

SARAH: No, I didn't; thankfully, not. I have never thought about that.

+ +

JOËL: So maybe in most applications, those two will just sort of naturally fall into maybe separate parts of the app, and they don't need to interact that much.

+ +

SARAH: Yeah, I think that will be the case. So mixing two of those subjects we're talking about here, that's testing and HTTP requests; we've been having a discussion in our project about the usage of VCR. That's a gem that records your HTTP requests interactions and replays them during tests. We've been discussing if using it is a good idea or not because we've been having issues with cassettes, that's one of VCR's concepts when these cassettes are not valid anymore. So do you have any thoughts on the subject? Maybe that will make a whole episode.

+ +

JOËL: We could definitely do a whole episode, I think, on testing third-party APIs. VCR is one of multiple different strategies that can be used to not make actual real network requests in your tests which brings some stability. There are also some downsides to it. I have found, in general, that over time, cassettes become brittle. So the idea of VCR is really cool. In practice, I think I've found that a few hand-rolled Webmock stubs usually do the job better for my needs.

+ +

SARAH: Yeah, I'll be interested in hearing that episode because, at least in my project, we have a lot of HTTP requests to external services, and they return a lot of information. I'm wondering if just dealing with that with Webmock would be too much work.

+ +

JOËL: One of the really useful things about VCR is that you can just make your request from anywhere, and it will just completely handle it. In some ways, though, I think it maybe hides some of that test pain that we were talking about earlier and allows you to sort of put HTTP in a lot of places that maybe you don't want it to. And by allowing yourself to feel a little bit of that test pain, you can more easily notice the places where maybe an object should not be making a request.

+ +

Or the actual HTTP logic can be moved to a concentrated place where all the HTTP is done together. And then only that object will need unit tests that actually need to mock the network, and most of your objects are fine. Where it gets interesting is more for things like integration tests, where now you're doing a lot of interactions, and you might have quite a few background requests that need to be made.

+ +

SARAH: I'm looking forward to the whole episode on this subject because I feel there's so much to talk about.

+ +

JOËL: There really is. I have a blog post that sort of summarizes a few different common categories of approaches to testing third-party requests, which might be different depending on whether you're doing a unit test or an integration test. But I grouped common solutions into four different categories. We'll make sure to link that in the show notes. So we've been talking a lot about testing. I'm curious when you review PR, do you start with the tests, maybe read through the tests first, and then the implementation?

+ +

SARAH: That's a good question. I have never thought about starting with tests. I think I'm going to give that a try anytime. But I just start reviewing them like by the first file that comes up. [laughs]

+ +

JOËL: I'm the same. I normally just do them in order. I have occasionally tried to do a test first, and that is sometimes interesting. Sometimes you read the test and, especially when you don't know what the implementation is going to be, you're like, why is this in the test? And then you jump to the implementation like, oh, that's what's going on.

+ +

Well, thank you so much, Sarah, for joining us on this whirlwind tour of code review, design of objects, and interacting with HTTP and testing.

+ +

SARAH: My pleasure.

+ +

JOËL: Where can people find you online if they would like to follow your work?

+ +

SARAH: I'm on Twitter @sarahlima_rb.

+ +

JOËL: We'll make sure to link that in the show notes. And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Fellow thoughtboter Sarah Lima joins Joël to discuss an issue Sarah had when she was doing a code review recently: making HTTP requests in an ActiveRecord model. Her concern with that approach was that a class was having too many responsibilities that would break the single-responsibility principle, and that it would make the class hard to maintain. Because the ActiveRecord layer is a layer that's meant to encapsulate business roles and data, her issue was that adding another responsibility on top of it would be too much. Her solution was to extract a class that would handle the whole HTTP request process.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by fellow thoughtboter Sarah Lima.

+ +

SARAH: Happy to be here.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Sarah, what's new in your world?

+ +

SARAH: Well, after a year and a half working on the same thoughtbot client, I have rolled off, and I have joined a new team. And I am learning a lot about not only a new codebase but learning to work with a new team. So that's always challenging, and this time it's not different.

+ +

JOËL: What is something that you like to do when joining a new team to help smooth the onboarding process?

+ +

SARAH: Well, I think especially getting to know people with one on ones. This time, I didn't do that right away because I had a bunch of time off scheduled right at the beginning of the project. But I did it right after I came back. And I'm learning a lot about my new colleagues, how they like to work, how they learn best. So, for instance, there are some people that like to learn and grow by reading blog posts, reading books, and there are other people that don't like that as much.

+ +

JOËL: So when you joined the new project, you just reached out to all of these people and set up a few meetings just to get to know them.

+ +

SARAH: Yeah, exactly.

+ +

JOËL: That's really good. I've never done that on a project. And now that you've said it, it kind of seems obvious. Maybe I should do that moving forward to get to know new teammates.

+ +

SARAH: Yeah. And I think it's easier on my project because it's a very small team. There are four of us thoughtboters, and there are just two client developers. So it was easier.

+ +

JOËL: What about on the code side of things? Are there any tricks you like to do when you're first getting started in a new codebase?

+ +

SARAH: Well, I think I really enjoy diving in right away, working on something small, and asking questions. I have also found it helpful in the past, especially on larger codebases, that someone that's experienced on a project gives me an overview showing me the quirks. And, of course, a good README is always a good thing to have, and during the process, always be updating the README. In this recent project, it was not different. I opened a lot of PRs to update the README. So that was good to have a PR right on your first day.

+ +

JOËL: I love that. I think that's usually my goal when I start on a new project is to have a PR the first day that fixes anything in the setup script that has been broken since the last person onboarded or documentation that was wrong.

+ +

SARAH: Yeah, absolutely.

+ +

JOËL: It's always a strong first contribution.

+ +

SARAH: Yeah. What about you, Joël? What's going on? What's new in your world?

+ +

JOËL: I've been investigating flaky tests, and I ran across a wild bug this week. I had a test that would fail every now and then. And it was pulling some data from Postgres and then doing some transformations on it. And I couldn't figure out why it was failing. It was a complex query. So it was just pulling out not ActiveRecord objects but a raw array of values. At some point, I was putting a PUT statement in the code with the array of values I expected to get and the array I would actually get.

+ +

And I was surprised to see that there is a field in there that is a float that was rounded to a different number of decimal places. I was like, that doesn't seem right. And so I was digging into it more, and I found out that this decimal value is from a timestamp that is in a file name for an mp4 video file name. And what is happening is that when we're querying the database, we're trying to extract the timestamp out of the file name by dropping the .mp4 file extension. And we're using the SQL TRIM function.

+ +

Unfortunately, TRIM does not do whatever the original authors thought it does. It doesn't just remove that substring from the end, but instead, it will remove any of those characters, so in my case, any of dot, M, P, or 4 in any combination from the end of the string. So anytime that my timestamp ended in a four, any fours were just getting chopped off. So if it ended in 44.mp4, the 44 would also get removed, not just the .mp4, which meant that randomly whenever a timestamp happened to end in 4, my test would flake.

+ +

SARAH: Wow. Do you have any idea how much time you spent debugging that?

+ +

JOËL: Oh, probably took, I'd say, a day, two days. This is spread over a couple of debugging sessions. But eventually, finding that particular location for the bug probably took us a couple of days. In the end, the bug fix for this is just a couple of lines, a couple of days work, and the diff is only a few lines. But I'm sure that the discussion on the PR is going to be really interesting. There's probably going to be a description that is a lot longer than the actual diff.

+ +

SARAH: Yeah, 100%. [laughs]

+ +

JOËL: Have you run across any interesting PRs on your new project?

+ +

SARAH: Yeah, I did. In fact, I recently reviewed a PR that had three interesting main issues that I wanted to address. And I wanted to lead the person that was working on it to a slightly better solution. So the three issues I saw were that the tests that were added were very DRY, so that was making everything a bit difficult to understand. The second one was that I saw one of the ActiveRecord classes was making HTTP requests, and that didn't sound like a good idea to me.

+ +

JOËL: That is unusual.

+ +

SARAH: Yes. The third one was that there were a lot of collections being built iteratively where another innumerable method would be a better fit, such as map instead of an each call.

+ +

JOËL: Oh, this is a classic situation where you're just using each to go through and transform something, and you've got some sort of external array that you're mutating as part of the each.

+ +

SARAH: Yes.

+ +

JOËL: There's a great thought article, I believe, by Joe Ferris on Iteration as an Anti-pattern.

+ +

SARAH: I think it's by Mike Burns. And I have referred to that article. In fact, I had very good articles for two of these three problems. I referred to a bunch of articles about WET tests as opposed to DRY tests, like how striving for tests that are DRY is not a good idea as opposed to telling a whole story in your tests. And I referred to that other article how iteratively building a collection can be an anti-pattern by Mike Burns. But the second issue about HTTP requests I didn't have anything to refer to. Maybe we should write one.

+ +

JOËL: This reminds me that in the thoughtbot Slack, we have a custom emoji for you should write a blog post about that. And this would probably be a good time to use it.

+ +

SARAH: Yes. So, Joël, how do you typically handle a PR that is maybe too long, and you have a lot of concerns about it? And how do you handle delivering that feedback?

+ +

JOËL: Oh, that is a challenge. I've definitely done it poorly in the past. And I think the wrong way to go about that situation is to go thoroughly through the PR and leave 50, 60 comments. That is overwhelming for the other person. And they're going to have a really bad day when they see 50 comments come through. And there's so much that they can't really address the main things you were talking about anyway.

+ +

So what I generally try to do, and it's kind of nice now that GitHub doesn't immediately publish your comments, is if I realize...like I start putting some more detailed comments, and then I realize, oh, there's going to be a lot, zoom out a little bit, and try to find are there some higher level trends that I can talk about? And maybe even just summarize in a larger comment at the bottom and say, "Hey, I see some larger structural issues," or "This PR is leaning very heavily on a technique that I think is maybe not the best use here. Maybe we should discuss that," instead of digging into maybe the actual implementation details of the code.

+ +

SARAH: Yeah, funny, you should mention that. I have recently also started doing that, using the summary version of GitHub reviews. And I used to just go file by file and leaving comments right away. And I'm thinking that this is not a good idea, especially when the PR is long. So I think another thing I would do is also call the person to pair and ask questions and understand where the person is coming from and also explain what are your concerns and how you both can get to a better place with that PR.

+ +

JOËL: That's really important. You have to remember there's another person on the other end of this. I love the idea of reaching out to them directly. Especially if there's a larger conversation to be had around approach or implementation, it's often easier to resolve those directly rather than back and forth in GitHub comments. So you mentioned situations where the PR is really long. Have you ever had to push back on that in some way?

+ +

SARAH: Yes. Especially when I saw, whoa, that's going to be difficult to understand, that's going to be difficult to review. And I have reached out to the person to say, "Hey, what about we split that PR in two?" Of course thinking about splitting the PR in a way that makes sense, in a way that still delivers our users’ value as soon as possible.

+ +

JOËL: I've been in situations like that where it's a really long PR, and the person has already invested a lot of work into it. And maybe it's even gone through a round of reviews. It feels almost too late to ask them to split up the work. But then I've actually regretted not doing that because there's so much complexity going on that then it doesn't work, or there are some bugs in it. We struggle to ship this, or it might just have to go through so many rounds of review and re-review and re-review. And because the PR is so long, it's a huge commitment for me to re-review it every time.

+ +

So there are situations I've been in where I wish that before even looking at the code at all, I was like, this is too long. We need to either slim down the story of what's being done. Because sometimes that's what happens is that the ticket is not well-defined, and someone goes in and just sort of keeps adding more code. And it becomes a bit of a big ball of mud. So, either helping to refine the ticket first or splitting the PR rather than actually looking at the code.

+ +

SARAH: Yeah, and pairing often can also help with that. So especially as consultants, our clients may ask us to work on different projects, and you work alone. And you may have tight deadlines, but I think it's always helpful to find time anyway to help your colleagues as well.

+ +

JOËL: I like that. I think there's a lot of value in the work that we do, where we collaborate with others in addition to whatever we do solo. So, oftentimes, it's great to pair with people at a client where possible to become involved in the code review process to even get involved in maybe some of the more broader system design conversations, sprint planning. All of those things are really good to jump into more than just getting siloed into working on just a solo feature.

+ +

SARAH: Yes, 100%.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So one of the things you mentioned that stood out for you when you were doing some code review recently was making HTTP requests in an ActiveRecord model. Why is that something that sort of caught your eyes, maybe an area to push back on in a particular design?

+ +

SARAH: That's a good question. My concern with that approach was that our class was having too many responsibilities that would break the SRP principle, the single-responsibility principle, and that would make our class hard to maintain. So the ActiveRecord layer is a layer that's meant to encapsulate business roles and data. So I was worried that adding another responsibility on top of it would be too much. So my idea was that we would extract a class that would handle the whole HTTP request process.

+ +

JOËL: Yeah, I feel like my instincts typically when I've done third-party integrations is that the ActiveRecord class should not know about the external internet world. It knows about the database. It knows about some of its core model functionality but that knowing about the internet world is somebody else's responsibility and that, ideally, the direction of dependency should flow the other way. So maybe the class that makes an external request knows about the ActiveRecord object if it needs to let's say, instantiate an instance of that model using data from an external request.

+ +

Or maybe it's even some third-party thing; maybe it's their controller that knows how to make or that will ask another object to make a request to some API and might also make a request to the model and ask it for some database data and then combine those two together. But that the ActiveRecord object only knows about that database area of responsibility and doesn't know that other things are also happening in the system.

+ +

SARAH: Absolutely. And I was also thinking that that class would have a difficult test to write. So a good idea is to separate our code that is side-effectful into their own classes, and that makes our tests so much easier.

+ +

JOËL: I actually wrote an article on the topic where one of my realizations at some point was that a lot of the pain points in code are what functional programmers would call side effects, so things like HTTP requests. And these are often things where we need to stub or do other things. And so isolating them as much as possible often simplifies our tests.

+ +

SARAH: Yeah, certainly. And I refer to that article every time I have the chance.

+ +

JOËL: Have you encountered the general concept of layered architectures, or hexagonal architectures, or things like that in the world of Rails or maybe elsewhere?

+ +

SARAH: Not hexagonal architecture. I have heard about it, but I haven't dived into it yet. Can you give us an overview?

+ +

JOËL: So I've also not worked with an actual hexagonal architecture. But the general idea, I guess, of layered architectures is that you build your code in a variety of layers, and different layers don't have access to or don't know about the ones...and I forget in this model if it's above or below, let's say it's below. So the inner layers don't know about the outer layers, but the outer layers can know about anything below them.

+ +

And so if the core of your app is the database, your database is most definitely not knowing about anything outside of just its data. And your ActiveRecord models that sit on top of that know about the database, but they don't know if they're being fronted by a web application, or a command line, or anything else. And then, above that, you might have more of a business process layer that knows about the database. It might know about how to make some external requests, but it doesn't know about anything above that.

+ +

And then, maybe at the final layer, you've got an application layer that handles things like controllers and interactions with users of the site. The core idea is that you split it into layers, and the higher-up layers know about everything below them, but no layer knows about what's above it. I feel like we're loosely applying that to the situation here with ActiveRecord in that it feels like the ActiveRecord layer if you will, shouldn't really know about third-party API requests.

+ +

SARAH: So, one exception to that is the ActiveResource approach that connects our business objects to REST services. So if you have an external website and you want to connect it via HTTP, you can do it using Rails ActiveResource.

+ +

JOËL: That is interesting because it functions like an ActiveRecord object, but instead of being backed by the database, it's backed by some kind of API. I almost wonder if...let's refactor our mental model here. And instead of saying that HTTP belongs in a separate layer that's higher up, maybe, in this case, it's almost like a sibling layer.

+ +

So your ActiveRecord models know about the database, and they make database requests in ActiveResource, or I think there are some gems that provide similar behavior. It might be backed by a particular API, but neither of them should know about the other. So maybe an ActiveResource model should not be making database requests.

+ +

SARAH: Yes, I like that line of thought.

+ +

JOËL: I guess the question then becomes, what about interactions between the two where you want to, I don't know, have some kind of association? You know, I don't think I've ever used ActiveResource on a project.

+ +

SARAH: I did once when trying to work with something close to microservice architecture. So we had a monolith, and we built a small service that was also in Rails, and we needed to consume the data that was stored in the monolith.

+ +

JOËL: And did you like that approach?

+ +

SARAH: Yeah. I think in that specific scenario, it was very productive. And I enjoyed a lot the API that Rails provided me via ActiveResources.

+ +

JOËL: Did you ever have to mix ActiveResource models and ActiveRecord models?

+ +

SARAH: No, I didn't; thankfully, not. I have never thought about that.

+ +

JOËL: So maybe in most applications, those two will just sort of naturally fall into maybe separate parts of the app, and they don't need to interact that much.

+ +

SARAH: Yeah, I think that will be the case. So mixing two of those subjects we're talking about here, that's testing and HTTP requests; we've been having a discussion in our project about the usage of VCR. That's a gem that records your HTTP requests interactions and replays them during tests. We've been discussing if using it is a good idea or not because we've been having issues with cassettes, that's one of VCR's concepts when these cassettes are not valid anymore. So do you have any thoughts on the subject? Maybe that will make a whole episode.

+ +

JOËL: We could definitely do a whole episode, I think, on testing third-party APIs. VCR is one of multiple different strategies that can be used to not make actual real network requests in your tests which brings some stability. There are also some downsides to it. I have found, in general, that over time, cassettes become brittle. So the idea of VCR is really cool. In practice, I think I've found that a few hand-rolled Webmock stubs usually do the job better for my needs.

+ +

SARAH: Yeah, I'll be interested in hearing that episode because, at least in my project, we have a lot of HTTP requests to external services, and they return a lot of information. I'm wondering if just dealing with that with Webmock would be too much work.

+ +

JOËL: One of the really useful things about VCR is that you can just make your request from anywhere, and it will just completely handle it. In some ways, though, I think it maybe hides some of that test pain that we were talking about earlier and allows you to sort of put HTTP in a lot of places that maybe you don't want it to. And by allowing yourself to feel a little bit of that test pain, you can more easily notice the places where maybe an object should not be making a request.

+ +

Or the actual HTTP logic can be moved to a concentrated place where all the HTTP is done together. And then only that object will need unit tests that actually need to mock the network, and most of your objects are fine. Where it gets interesting is more for things like integration tests, where now you're doing a lot of interactions, and you might have quite a few background requests that need to be made.

+ +

SARAH: I'm looking forward to the whole episode on this subject because I feel there's so much to talk about.

+ +

JOËL: There really is. I have a blog post that sort of summarizes a few different common categories of approaches to testing third-party requests, which might be different depending on whether you're doing a unit test or an integration test. But I grouped common solutions into four different categories. We'll make sure to link that in the show notes. So we've been talking a lot about testing. I'm curious when you review PR, do you start with the tests, maybe read through the tests first, and then the implementation?

+ +

SARAH: That's a good question. I have never thought about starting with tests. I think I'm going to give that a try anytime. But I just start reviewing them like by the first file that comes up. [laughs]

+ +

JOËL: I'm the same. I normally just do them in order. I have occasionally tried to do a test first, and that is sometimes interesting. Sometimes you read the test and, especially when you don't know what the implementation is going to be, you're like, why is this in the test? And then you jump to the implementation like, oh, that's what's going on.

+ +

Well, thank you so much, Sarah, for joining us on this whirlwind tour of code review, design of objects, and interacting with HTTP and testing.

+ +

SARAH: My pleasure.

+ +

JOËL: Where can people find you online if they would like to follow your work?

+ +

SARAH: I'm on Twitter @sarahlima_rb.

+ +

JOËL: We'll make sure to link that in the show notes. And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+sgj-I64d + + ]]> + + Joël Quenneville + + + 359: Serializers + https://bikeshed.thoughtbot.com/359 + 26053e8b-9b6c-49d4-8ebc-6309d1c7f45e + Tue, 25 Oct 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris Toomey is back! (For an episode.) He talks about what he's been up to since handing off the reins to Joël. He's been playing around with something at Sagewell that he enjoys. At the core of it? Serializers. + 44:10 + no + + + Chris Toomey is back! (For an episode.) He talks about what he's been up to since handing off the reins to Joël. He's been playing around with something at Sagewell that he enjoys. At the core of it? Serializers. +Primalize gem (https://github.com/jgaskins/primalize) +Derek's talk on code review (https://www.youtube.com/watch?v=PJjmw9TRB7s) +Inertia.js (https://inertiajs.com/) +Phantom types (https://thoughtbot.com/blog/modeling-currency-in-elm-using-phantom-types) +io-ts (https://gcanti.github.io/io-ts/) +dry-rb (https://dry-rb.org/) +parse don't validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) +value objects (http://wiki.c2.com/?ValueObject) +broader perspective on parsing (https://thoughtbot.com/blog/a-broader-take-on-parsing) +Enumerable#tally (https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a5fb11ea) +RubyConf mini (https://www.rubyconfmini.com/) +where.missing (https://boringrails.com/tips/activerecord-where-missing-associations) +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. And today, I'm joined by a very special guest, former host Chris Toomey. +CHRIS: Hi, Joël. Thanks for having me. +JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Chris, what's new in your world? +CHRIS: Being on this podcast is new in my world, or everything old is new again, or something along those lines. But, yeah, thank you so much for having me back. It's a pleasure. Although it's very odd, it feels somehow so different and yet very familiar. +But yeah, more generally, what's new in my world? I think this was probably in development as I was winding down my time as a host here on The Bike Shed, but I don't know that I ever got a chance to talk about it. There has been a fun sort of deep-in-the-weeds technical thing that we've been playing around with at Sagewell that I've really enjoyed. +So at the core of it, we have serializers. So we take some data structures in our Ruby on Rails code base, and we need to serialize them to JSON to send them to the front end. In our case, we're using Inertia, so it's not quite a JSON API, but it's fine to think about it in that way for the context of this discussion. +And what we were finding is our front end has TypeScript. So we're writing Svelte, which is using TypeScript. And so we're stating or asserting that the types like, hey, we're going to get this data in from the back end, and it's going to have this shape to it. And we found that it was really hard to keep those in sync to keep, like, what does the user mean on the front end? What's the data that we're going to get? It's going to have a full name, which is a string, except sometimes that might be null. So how do we make sure that those are keeping up to date? +And then we had a growing number of serializers on the back end and determining which serializer we were actually using, and it was just...it was a mess, to put it lightly. And so we had explored a couple of different options around it, and eventually, we found a library called Primalize. So Primalize is a Ruby library. It is for writing JSON serializers. But what's really interesting about it is it has a typing layer. It's like a type system sort of thing at play. +So when you define a serializer in Primalize, instead of just saying, here are the fields; there is an ID, a name, et cetera, you say, there is an ID, and it is a string. There is a name, and it is a string, or an optional string, which is the even more interesting bit. You can say array. You can say object. You can say an enum of a couple of different values. And so we looked at that, and we said, ooh, this is very interesting. Astute listeners will know that this is probably useless in a Ruby system, which doesn't have types or a compilation step or anything like that. +But what's really cool about this is when you use a Primalize serializer, as you're serializing an object, if there is ever a type mismatch, so the observed type at runtime and the authored type if those ever mismatch, then you can have some sort of notification happen. So in our case, we configured it to send a warning to Sentry to say, "Hey, you said the types were this, but we're actually seeing this other thing." Most often, it will be like an Optional, a null sneaking through, a nil sneaking through on the Ruby side. +But what was really interesting is as we were squinting at this, we're like, huh, so now we're going to write all this type information. What if we could somehow get that type information down to the front end? So I had a long weekend, one weekend, and I went away, and I wrote a bunch of code that took all of those serializers, ran through them, and generated the associated TypeScript interfaces. And so now we have a build step that will essentially run that and assert that we're getting the same thing in CI as we have committed to the codebase. +But now we have the generated serializer types on the front end that match to the used serializer on the back end, as well as the observed run-time types. So it's a combination of a true compilation step type system on the front end and a run-time type system on the back end, which has been very, very interesting. +JOËL: I have a lot of thoughts here. +CHRIS: I figured you would. [laughs] +JOËL: But the first thing that came to mind is, as a consultant, there's a scenario with especially smaller startups that generally concerns me, and that is the CTO goes away for a weekend and writes a lot of code... +CHRIS: [laughs] +JOËL: And brings in a new system on Monday, which is exactly what you're describing here. How do you feel about the fact that you've done that? +CHRIS: I wasn't ready to go this deep this early on in this episode. +JOËL: [laughs] +CHRIS: But honestly, that is a fantastic question. It's a thing that I have been truly not struggling with but really thinking about. We're going to go on a slight aside here, but I am finding it really difficult to engage with the actual day-to-day coding work that we're doing and to still stay close to the codebase and not be in the way. +There's a pattern that I've seen happen a number of times now where I pick up a piece of work that is, you know, one of the tickets at the top of the backlog. I start to work on it. I get pulled into a meeting, then another meeting, then three more meetings. And suddenly, it's three days later. I haven't completed this piece of work that was defined to be the next most important piece of work. And suddenly, I'm blocking the team. +JOËL: Hmmm. +CHRIS: So I actually made a rule that I'm not allowed to own critical path work, which feels weird because it's like, I want to be engaged with that work. So the counterpoint to that is I'm now trying to schedule pairing sessions with each of the developers on the team once a week. And in that time, I can work on that sort of stuff with them, and they'll then own it and run with it. So it makes sure that I'm not blocking on those sorts of things, but I'm still connected to the core work that we're doing. +But the other thing that you're describing of the CTO goes away for the weekend and then comes back with a new harebrained scheme; I'm very sensitive to that, having worked on; frankly, I think the same project. I can think of a project that you and I worked on where we experienced this. +JOËL: I think we're thinking of the same project. +CHRIS: So yes. Like, I'm scarred by that and, frankly, a handful of experiences of that nature. So we actually, I think, have a really healthy system in place at Sagewell for capturing, documenting, prioritizing this sort of other work, this developer-centric work. So this is the feature and bug work that gets prioritized and one list over here that is owned by our product manager. Separately, the dev team gets to say, here are the pain points. Here's the stuff that keeps breaking. Here are the things that I wish was better. Here is the observability hard-to-understand bits. +And so we have a couple of different systems at play and recurring meetings and sort of unique ceremonies around that, and so this work was very much a fallout of that. It was actually a recurring topic that we kept trying a couple of different stabs at, and we never quite landed it. And then I showed up this one Monday morning, and I was like, "I found a thing; what do we think?" And then, critically, from there, I made sure I paired with other folks on the team as we pushed on the implementation. +And then, actually, I mentioned Primalize, the library that we're using. We have now since deprecated Primalize within the app because we kept just adding to it so much that eventually, we're like, at this point, should we own this stuff? So we ended up rewriting the core bits of Primalize to better fit our use cases. And now we've actually removed Primalize, wonderful library. I highly recommend it to anyone who has that particular use case but then the additional type generation for the front end. +Plus, we have some custom types within our app, Money being the most interesting one. We decided to model Money as our first-class consideration rather than just letting JavaScript have the sole idea of a number. But yes, in a very long-winded way, yes, I'm very sensitive to the thing you described. And I hope, in this case, I did not fall prey to the CTO goes away for the weekend and made a thing. +JOËL: I think what I'm hearing is the key difference here is that you got buy-in from the team around this idea before you went out and implemented it. So you're not off doing your own things disconnected from the team and then imposing it from on high. The team already agreed this is the thing we want to do, and then you just did it for them. +CHRIS: Largely, yes. Although I will say there are times that each developer on the team, myself included, have sort of gone away, come back with something, and said, "Hey, here's a WIP PR exploring an area." And there was actually...I'm forgetting what the context was, but there was one that happened recently that I introduced. I was like; I had to do this. And the team talked me out of it, and I ended up closing that PR. Someone else actually made a different PR that was an alternative implementation. I was like, no, that's better; we should absolutely do that. +And I think that's really healthy. That's a hard thing to maintain but making sure that everyone feels like they've got a strong voice and that we're considering all of the different ways in which we might consider the work. Most critically, you know, how does this impact users at the end of the day? That's always the primary consideration. How do we make sure we build a robust, maintainable, observable system, all those sorts of things? +And primarily, this work should go in that other direction, but I also don't want to stifle that creative spark of I got this thing in my head, and I had to explore it. Like, we shouldn't then need to never mind, throw away the work, put it into a ticket. Like, for as long as we can, that more organic, intuitive process if we can retain that, I like that. Critically, with the ability for everyone to tell me, "No, this is a bad idea. Stop it. What are you doing?" And that has happened recently. I mean, they were kinder about it, but they did talk me out of a bad idea. So here we are. +JOËL: So you showed up on Monday morning, not with telling everyone, "Hey, I merged this thing over the weekend." You're showing up with a work-in-progress PR. +CHRIS: Yes, definitely. I mean, everything goes through a PR, and everything has discussion and conversation around it. That's a strong, strong like Derek Prior's wonderful talk Building a Culture of Code Review. I forget the exact name of it. But it's one of my favorite talks in talking about the utility of code review as a way to share ideas and all of those wonderful things. So everything goes through code review, and particularly anything that is of that more exploratory architectural space. +Often we'll say any one review from anyone on the team is sufficient to merge most things but something like that, I would want to say, "Hey, can everybody take a look at this? And if anyone has any reservations, then let's talk about it more." But if I or anyone else on the team for this sort of work gets everybody approving it, then cool, we're good to go. But yeah, code review critical, critical part of the process. +JOËL: I'm curious about Primalize, the gem that you mentioned. It sounds like it's some kind of validation layer between some Ruby data structure and your serializers. +CHRIS: It is the serializer, but in the process of serializing, it does run-time type validation, essentially. So as it's accessing, you know, you say first name. You have a user object. You pass it in, and you say, "Serializer, there's a first name, and it's a string." It will call the first name method on that user object. And then, it will check that it has the expected type, and if it doesn't, then, in our case, it sends to Sentry. +We have configured it...it's actually interesting. In development and test mode, it will raise for a type mismatch, and in production mode, it will alert Sentry so you can configure that differently. But that ends up being really nice because these type mismatches end up being very loud early on. And it's surprisingly easy to maintain and ends up telling us a lot of truths about our system because, really, what we're doing is connecting data from many different systems and flowing it in and out. And all of the inputs and outputs from our system feel very meaningful to lock down in this way. But yeah, it's been an adventure. +JOËL: It seems to me there could almost be two sets of types here, the inputs coming into Primalize from your Ruby data structures and then the outputs that are the actual serialized values. And so you might expect, let's say, an integer on the Ruby side, but maybe at the serialization level, you're serializing it to a string. Do you have that sort of conversion step as part of your serializers sometimes, or is the idea that everything's already the right type on the Ruby side, and then we just, like, to JSON it at the end? +CHRIS: Yep. Primalize, I think, probably works a little closer to what you're describing. They have the idea of coercions. So within Primalize, there is the concept of a timestamp; that is one of the types that is available. But a timestamp is sort of the union of a date, a time, or I think they might let through a string; I'm not sure if there is as well. But frankly, for us, that was more ambiguity than we wanted or more blurring across the lines. And in the implementation that we've now built, date and time are distinct. And critically, a string is not a valid date or time; it is a string, that's another thing. +And so there's a bunch of plumbing within the way you define the serializers. There are override methods so that you can locally within the serializer say, like, oh, we need to coerce from the shape of data into this other shape of data, even little like in-line proc, so we can do it quickly. But the idea is that the data, once it has been passed to the serializer, should be up the right shape. And so when we get to the type assertion part of the library, we expect that things are in the asserted type and will warn if not. We get surprisingly few warnings, which is interesting now. +This whole process has made us pay a little more intention, and it's been less arduous simultaneously than I would have expected because like this is kind of a lot of work that I'm describing. And yet it ends up being very natural when you're the developer in context, like, oh, I've been reading these docs for days. I know the shape of this JSON that I'm working with inside and out, and now I'll just write it down in the serializer. It's very easy to do in that moment, and then it captures it and enforces it in such a useful way. +As an aside, as I've been looking at this, I'm like, this is just GraphQL, but inside out, I'm pretty sure. But that is a choice that we have made. We didn't want to adopt the whole GraphQL thing. But just for anyone out there who is listening and is thinking, isn't this just GraphQL but inside out? Kind of. Yes. +JOËL: I think my favorite part of GraphQL is the schema, which is not really the selling point for GraphQL, you know, like the idea that you can traverse the graph and get any subset of data that you want and all that. I think I would be more than happy with a REST API that has some kind of schema built around it. And someone told me that maybe what I really just want is SOAP, and I don't know how to feel about that comment. +CHRIS: You just got to have some XML, and some WSDLs, and other fun things. I've heard people say good things about SOAP. SOAP seems like a fine idea. If anything, I think a critical part of this is we don't have a JSON API. We have a very tightly coupled front end and back end, and a singular front end, frankly. And so that I think naturally...that makes the thing that I'm describing here a much more comfortable fit. +If we had multiple different downstream clients that we're trying to consume from the same back end, then I think a GraphQL API or some other structured JSON schema, whatever it is type of API, and associated documentation and typing layer would be probably a better fit. But as I've said many a time on this here, Bike Shed, Inertia is one of my favorite libraries or frameworks (They're probably more of a framework.) one of my favorite technological approaches that I have ever found. +And particularly in buildings Sagewell, it has allowed us to move so rapidly the idea that changes are, you know, one fell swoop changes everything within the codebase. We don't have to think about syncing deploys for the back end and the front end and how to coordinate across them. Our app is so much easier to understand by virtue of that architecture that Inertia implies. +JOËL: So, if I understand correctly, you don't serialize to JSON as part of the serializers. You're serializing directly to JavaScript. +CHRIS: We do serialize to JSON. At the end of the day, Inertia takes care of this on both the Rails side and the client side. There is a JSON API. Like, if you look at the network inspector, you will see XHR requests happening. But critically, we're not doing that. We're not the ones in charge of it. We're not hitting a specific endpoint. +It feels as an application coder much closer to a traditional Rails app. It just happens to be that we're writing our view layer. Instead of an ERB, we're writing them in Svelte files. But otherwise, it feels almost identical to a normal traditional Rails app with controllers and the normal routing and all that kind of stuff. +JOËL: One thing that's really interesting about JSON as an interchange format is that it is very restrictive. The primitives it has are even narrower than, say, the primitives that Ruby has. So you'd mentioned sending a date through. There is no JSON date. You have to serialize it to some other type, potentially an integer, potentially a string that has a format that the other side knows how it's going to interpret. And I feel like it's those sorts of richer types when we need to pass them through JSON that serialization and deserialization or parsing on the other end become really interesting. +CHRIS: Yeah, I definitely agree with that. It was a struggling point for a while until we found this new approach that we're doing with the serializers in the type system. But so far, the only thing that we've done this with is Money. But on the front end, a while ago, we introduced a specific TypeScript type. So it's a phantom type, and I believe I'm getting this correct. It's a phantom type called Cents, C-E-N-T-S. So it represents...I'm going to say an integer. I know that JavaScript doesn't have integers, but logically, it represents an integer amount of cents. And critically, it is not a number, like, the lowercase number in the type system. We cannot add them together. We can't -- +JOËL: I thought you were going to say, NaN. +CHRIS: [laughs] It is not a number. I saw a n/a for not applicable somewhere in the application the other day. I was like, oh my God, we have a NaN? It happened? But it wasn't, it was just n/a, and I was fine. But yeah, so we have this idea of Cents within the application. We have a money input, which is a special input designed exactly for this. So to a user, it is formatted to look like you're entering dollars and cents. But under the hood, we are bidirectionally converting that to the integer amount of cents that we need. And we strictly, within the type system, those are cents. +And you can't do math on Cents unless you use a special set of helper functions. You cannot generate Cents on the fly unless you use a special set of helper functions, the constructor functions. So we've been really restrictive about that, which was kind of annoying because a lot of the data coming from the server is just, you know, numbers. +But now, with this type system that we've introduced on the Ruby side, we can assert and enforce that these are money.new on the Ruby side, so using the Money gem. And they come down to the front end as capital C Cents in the type system on the TypeScript side. So we're able to actually bind that together and then enforce proper usage sort of on both sides. +The next step that we plan to do after that is dates and times. And those are actually almost weirder because they end up...we just have to sort of say what they are, and they will be ISO 8601 date and time strings, respectively. But we'll have functions that know this is a date string; that's a thing. It is, again, a phantom type implemented within our TypeScript type system. +But we will have custom functions that deal with that and really constrain...lock ourselves down to only working with them correctly. And critically, saying that is the only date and time format that we work with; there is no other. We don't have arbitrary dates. Is this a JSON date or something else? I don't know; there are too many date syntaxes. +JOËL: I like the idea of what you're doing in that it sounds like you're very much narrowing that sort of window of where in the stack the data exists in the sort of unstructured, free-floating primitives that could be misinterpreted. And so, at this point, it's almost narrowed to the point where it can't be touched by any user or developer-written code because you've pushed the boundaries on the Rails side down and then on the JavaScript side up to the point where the translation here you define translations on one side or, I guess, a parser on one side and a serializer on the other. And they guarantee that everything is good up until that point. +CHRIS: Yep, with the added fun of the runtime reflection on the Ruby side. So it's an interesting thing. Like, TypeScript actually has similar things. You can say what the type is all day long, and your code will consistently conform to that asserted type. But at the end of the day, if your JSON API gets in some different data...unless you're using a library like io-ts, is one that I've looked at, which actually does parsing and returns a result object of did we parse to the thing that you wanted or did we get an error in that data structure? +So we could get to that level on the client side as well. We haven't done that yet largely because we've essentially pushed that concern up to the Ruby layer. So where we're authoring the data, because we own that, we're going to do it at that level. There are a bunch of benefits of defining it there and then sort of reflecting it down. +But yeah, TypeScript, you can absolutely lie to yourself, whereas Elm, a language that I know you love dearly, you cannot lie to yourself in Elm. You've got to tell the truth. It's the only option. You've got to prove it. Whereas in TypeScript, you can just kind of suggest, and TypeScript will be like, all right, cool, I'll make sure you stay honest on that, but I'm not going to make you prove it, which is an interesting sort of set of related trade-offs there. +But I think we found a very comfortable resting spot for right now. Although now, we're starting to look at the edges of the Ruby system where data is coming in. So we have lots of webhooks and other external partners that we're integrating with, and they're sending us data. And that data is of varying shapes. Some will send us a payload with the word amount, and it refers to an integer amount of cents because, of course, it does. Some will send us the word amount in their payload, and it will be a floating amount of dollars. And I get a little sad on those days. +But critically, our job is to make sure all of those are the same and that we never pass dollars as cents or cents as dollars because that's where things go sad. That is job number one at Sagewell in the engineering team is never get the decimal place wrong in money. +JOËL: That would be a pretty terrible mistake to make. +CHRIS: It would. I mean, it happens. In fintech, that problem comes up a lot. And again, the fact that...I'm honestly surprised to see situations out there where we're getting in floating point dollars. That is a surprise to me because I thought we had all agreed sort of as a community that it was integer cents but especially in a language that has integers. JavaScript, it's kind of making it up the whole time. But Ruby has integers. JSON, I guess, doesn't have integers, so I'm sort of mixing concerns here, but you get the idea. +JOËL: Despite Ruby not having a static type system, I've found that generally, when I'm integrating with a third-party API, I get to the point where I want something that approximates like Elm's JSON decoders or io-ts or something like that. Because JSON is just a big blob of data that could be of any shape, and I don't really trust it because it's third-party data, and you should not trust third parties. And I find that I end up maybe cobbling something together commonly with like a bunch of usage of hash.fetch, things like that. But I feel like Ruby doesn't have a great approach to parsing and composing these validators for external data. +CHRIS: Ruby as a language certainly doesn't, and the ecosystem, I would say, is rather limited in terms of the options here. We have looked a bit at the dry-rb stack of gems, so dry-validation and dry-schema, in particular, both offer potentially useful aspects. We've actually done a little bit of spiking internally around that sort of thing of, like, let's parse this incoming data instead of just coercing to hash and saying that it's got probably the shape that we want. And then similarly, I will fetch all day instead of digging because I want to be quite loud when we get it wrong. +But we're already using dry-monads. So we have the idea of result types within the system. We can either succeed or fail at certain operations. And I think it's just a little further down the stack. But probably something that we will implement soon is at those external boundaries where data is coming in doing some form of parsing and validation to make sure that it conforms to unknown data structure. And then, within the app, we can do things more cleanly. +That also would allow us to, like, let's push the idea that this is floating point dollars all the way out to the edge. And the minute it hits our system, we convert it into a money.new, which means that cents are properly handled. It's the same type of money or dollar, same type of currency handling as everywhere else in the app. And so pushing that to the very edges of our application is a very interesting idea. And so that could happen in the library or sort of a parsing client, I guess, is probably the best way to think about it. So I'm excited to do that at some point. +JOËL: Have you read the article, Parse, Don't Validate? +CHRIS: I actually posted that in some code review the other day to one of the developers on the team, and they replied, "You're just going to quietly drop one of my favorite articles of all time in code review?" [laughs] So yes, I've read it; I love it. It's a wonderful idea, definitely something that I'm intrigued by. And sort of bringing dry-monads into Ruby, on the one hand, feels like a forced fit and yet has also been one of the other, I think strongest sort of architectural decisions that we've made within the application. +There's so much imperative work that we ended up having to do. Send this off to this external API, then tell this other one, then tell this other one. Put the whole thing in a transaction so that our local data properly handles it. And having dry-monads do notation, in particular, to allow us to make that manageable but fail in all the ways it needs to fail, very expressive in its failure modes, that's been great. And then parse, don't validate we don't quite do it yet. But that's one of the dreams of, like, our codebase really should do that thing. We believe in that. So let's get there soon. +JOËL: And the core idea behind parse, don't validate is that instead of just having some data that you don't trust, running a check on it and passing that blob of now checked but still untrusted data down to the next person who might also want to check it. Generally, you want to pass it through some sort of filter that will, one, validate that it's correct but then actually typically convert it into some other trusted shape. +In Ruby, that might be something like taking an amorphous blob of JSON and turning it into some kind of value object or something like that. And then anybody downstream that receives, let's say, money object can trust that they're dealing with a well-formed money value as opposed to an arbitrary blob of JSON, which hopefully somebody else has validated, but who knows? So I'm going to validate it again. +CHRIS: You can tell that I've been out of the podcasting game for a while because I just started responding to yes; I love that blog post without describing the core premise of it. So kudos to you, Joël; you are a fantastic podcast host over there. +I will say one of the things you just described is an interesting...it's been a bit of a struggle for us. We keep sort of talking through what's the architecture. How do we want to build this application? What do we care about? What are the things that really matter within this codebase, and then what is all the other stuff? And we've been good at determining the things that really matter, thinking collectively as a group, and I think coming up with some novel, useful, elegant...I'm saying too many positive adjectives for what we're doing. +But I've been very happy with sort of the thing that we decide. And then there's the long-tail work of actually propagating that change throughout the rest of the application. We're, like, okay, here's how it works. Every incoming webhook, we now parse and yield a value object. That sentence that you just said a minute ago is exactly what I want. That's like a bunch of work. It's particularly a bunch of work to convert an existing codebase. It's easy to say, okay, from here forward, any new webhooks, payloads that are coming in, we're going to do in this way. But we have a lot of things in our app now that exist in this half-converted way. +There was a brief period where we had three different serializer technologies at play. Just this week, I did the work of killing off the middle ground one, the Primalized-based thing, and we now have only our new hotness and then the very old. We were using Blueprinter as the serializer as the initial sort of stub. And so that still exists within the codebase in some places. But trying to figure out how to prioritize that work, the finishing out those maintenance-type conversions is a tricky one. It's never the priority. But it is really nice to have consistency in a codebase. So it's...yeah, do you have any thoughts on that? +JOËL: I think going back to the article and what the meaning of parsing is, I used to always think of parsing as taking strings and turning them into something else, and I think this really broadened my perspective on the idea of parsing. And now, I think of it more as converting from a broader type to a narrower type with failures. +So, for example, you could go from a string to an integer, and not all strings are valid integers. So you're narrowing the type. And if you have the string hello world, it will fail, and it will give you an error of some type. But you can have multiple layers of that. So maybe you have a string that you parse into an integer, but then, later on, you might want to parse that integer into something else that requires an integer in a range. Let's say it's a percentage. So you have a value object that is a percentage, but it's encoded in the JSON as a string. +So that first pass, you parse it from a string into an integer, and then you parse that integer into a percentage object. But if it's outside the range of valid percentage numbers, then maybe you get an error there as well. So it's a thing that can happen at multiple layers. And I've now really connected it with the primitive obsession smell in code. So oftentimes, when you decide, wait, I don't want a primitive here; I want a richer type, commonly, there's going to be a parsing step that should exist to go from that primitive into the richer type. +CHRIS: I like that. That was a classic Joël wildly concise summary of a deeply complex technical topic right there. +JOËL: It's like I'm going to connect some ideas from functional programming and a classic object-oriented code smell and, yeah, just kind of mash it all together with a popular article. +CHRIS: If only you had a diagram. Podcast is not the best medium for diagrams, but I think you could do it. You could speak one out loud, and everyone would be able to see it in their mind's eye. +JOËL: So I will tell you what my diagram is for this because I've actually created it already. I imagine this as a sort of like pyramid with different layers that keep getting smaller and smaller. So the size of type is sort of the width of a layer. And so your strings are a very wide layer. Then on top of that, you have a narrower layer that might be, you know, it could be an integer, or you could even if you're parsing JSON, you first start with a string, then you parse that into a Ruby hash, not all strings are valid hashes. So that's going to be narrower. +Then you might extract some values out of that hash. But if the keys aren't right, that might also fail. You're trying to pull the user out of it. And so each layer it gets a richer type, but that richer type, by virtue of being richer, is narrower. And as you're trying to move up that pyramid at every step, there is a possibility for a failure. +CHRIS: Have you written a blog post about this with said diagram in it? And is that why you have that so readily at hand? [laughs] +JOËL: Yes, that is the case. +CHRIS: Okay. Yeah, that made sense to me. [laughs] +JOËL: We'll make sure to link to it in the show notes. +CHRIS: Now you have to link to Joël blog posts, whereas I used to have to link to them [chuckles] in almost every episode of The Bike Shed that I recorded. +JOËL: Another thing I've been thinking about in terms of this parsing is that parsing and serializing are, in a sense, almost opposites of each other. Typically, when you're parsing, you're going from a broad type to a narrow one. And when you're serializing, you're going from a narrow type to a broader one. So you might go from a user into a hash into a string. So you're sort of going down that pyramid rather than going up. +CHRIS: It is an interesting observation and one that immediately my brain is like, okay, cool. So can we reuse our serializers but just run them in reverse or? And then I try and talk myself out of that because that's a classic don't repeat yourself sort of failure mode of, like, actually, it's fine. You can repeat a little bit. So long as you can repeat and constrain, that's a fine version. But yeah, feels true, though, at the core. +JOËL: I think, in some ways, if you want a single source of truth, what you want is a schema, and then you can derive serializers and parsers from that schema. +CHRIS: It's interesting because you used the word derive. That has been an interesting evolution at Sagewell. The engineering team seems to be very collected around the idea of explicitness, almost the Zen of Python; explicit is better than implicit. And we are willing to write a lot of words down a lot of times and be happy with that. I think we actually made the explicit choice at one point that we will not implement an automatic camel case conversion in our serializer, even though we could; this is a knowable piece of code. +But what we want is the grepability from the front end to the back end to say, like, where's this data coming from? And being able to say, like, it is this data, which is from this serializer, which comes from this object method, and being able to trace that very literally and very explicitly in the code, even though that is definitely the sort of thing that we could derive or automatically infer or have Ruby do that translation for us. +And our codebase is more verbose and a little noisier. But I think overall, I've been very happy with it, and I think the team has been very happy. But it is an interesting one because I've seen plenty of teams where it is the exact opposite. Any repeated characters must be destroyed. We must write code to write the code for us. And so it's fun to be working with a team where we seem to be aligned around an approach on that front. +JOËL: That example that you gave is really interesting because I feel like a common thing that happens in a serialization layer is also a form of normalization. And so, for example, you might downcase all strings as part of the serialization, definitely, like dates always get written in ISO 8601 format whenever that happens. And so, regardless of how you might have it stored on the Ruby side, by the time it gets to the JSON, it's always in a standard format. And it sounds like you're not necessarily doing that with capitalization. +CHRIS: I think the distinction would be the keys and the values, so we are definitely doing normalization on the values side. So ISO 8601 date and time strings, respectively that, is the direction that we plan to go for the value. But then for the key that's associated with that, what is the name for this data, those we're choosing to be explicit and somewhat repetitive, or not even necessarily repetitive, but the idea of, like, it's first_name on the Ruby side, and it's first capital N name camel case, or it's...I forget the name. It's not quite camel case; it's a different one but lower camel, maybe. +But whatever JavaScript uses, we try to bias towards that when we're going to the front end. It does get a little tricky coming back into the Ruby side. So our controllers have a bunch of places where they need to know about what I think is called lower camel case, and so we're not perfect there. But that critical distinction between sort of the names for things, and the values for things, transformations, and normalizations on the values, I'm good with that. But we've chosen to go with a much more explicit version for the names of things or the keys in JSON objects specifically. +JOËL: One thing that can be interesting if you have a normalization phase in your serializer is that that can mean that your serializer and parsers are not necessarily symmetric. So you might accept malformed data into your parser and parse it correctly. But then you can't guarantee that the data that gets serialized out is going to identically match the data that got parsed in. +CHRIS: Yeah, that is interesting. I'm not quite sure of the ramifications, although I feel like there are some. It almost feels like formatting Prettier and things like that where they need to hold on to whitespace in some cases and throw out in others. I'm thinking about how ASTs work. And, I don't know, there's interesting stuff, but, again, not sure of the ramifications. +But actually, to flip the tables just a little bit, and that's an aggressive terminology, but we're going to roll with it. To flip the script, let's go with that, Joël; what's been up in your world? You've been hosting this wonderful show. I've listened in to a number of episodes. You're doing a fantastic job. I want to hear a little bit more of what's new in your world, Joël. +JOËL: So I've been working on a project that has a lot of flaky tests, and we're trying to figure out the source of that flakiness. It's easy to just dive into, oh, I saw a flaky Test. Let me try to fix it. But we have so much flakiness that I want to go about it a little bit more systematically. And so my first step has actually been gathering data. So I've actually been able to make API requests to our CI server. And the way we figure out flakiness is looking at the commit hash that a particular test suite run has executed on. +And if there's more than one CI build for a given commit hash, we know that's probably some kind of flakiness. It could be a legitimate failure that somebody assumed was flakiness, and so they just re-run CI. But the symptom that we are trying to address is the fact that we have a very high level of people re-verifying their code. And so to do that or to figure out some stats, I made a request to the API grouped by commit hash and then was able to get the stats of how many re-verifications there are and even the distribution. +The classic way that you would do that is in Ruby; you would use the GroupBy function from enumerable. And then, you would transform values instead of having, like, say; each commit hash then points to all the builds, an array of builds that match that commit hash. You would then thumb those. So now you have commit hashes that point to counts of how many builds there were for that commit hash. Newer versions of Ruby introduced the tally method, which I love, which allows you to basically do all of that in one step. +One thing that I found really interesting, though, is that that will then give me a hash of commit hashes that point to the number of builds that are there. If I want to get the distribution for the whole project over the course of, say, the last week, and I want to say, "How many times do people run only one CI run versus running twice in the same commit versus running three times, or four times, or five or six times?" I want to see that distribution of how many times people are rerunning their build. You're effectively doing that tally process twice. +So once you have a list of all the builds, you group by hash. You count, and so you end up with that. You have the Ruby hash of commit SHAs pointing to number of times the build was run on that. And then, you again group by the number of builds for each commit SHA. And so now what you have is you'll have something like one, and then that points to an array of SHA one, SHA two, SHA three, SHA four like all the builds. +And then you tally that again, or you transform values, or however, you end up doing it. And what you end up with is saying for running only once, I now have 200 builds that ran only once. For running twice in the same commit SHA, there are 15. For running three times, there are two. For running four times, there is one. And now I've got my distribution broken down by how many times it was run. It took me a while to work through all of that. But now the shortcut in my head is going to be you double tally to get distribution. +CHRIS: As an aside, the whole everything you're talking about is interesting and getting to that distribution. I feel like I've tried to solve that problem on data recently and struggled with it. But particularly tally, I just want to spend a minute because tally is such a fantastic addition to the Ruby standard library. I used to have in sort of like loose muscle memory transform value is grouped by ampersand itself, transform values count, sort, reverse to H. That whole string of nonsense gets replaced by tally, and, oof, what a beautiful example of Ruby, and enumerable, and all of the wonder that you can encapsulate there. +JOËL: Enumerable is one of the best parts of Ruby. I love it so much. It was one of the first things that just blew my mind about Ruby when I started. I came from a PHP, C++ background and was used to writing for loops for everything and not the nice for each loops that a lot of languages have these days. You're writing like a legit for or while loop, and you're managing the indexes yourself. And there's so much room for things to go wrong. +And being introduced to each blew my mind. And I was like, this is so beautiful. I'm not dealing with indexes. I'm not dealing with the raw implementation of the array. I can just say do a thing for each element. This is amazing. And that is when I truly fell in love with Ruby. +CHRIS: I want to say I came from Python, most recently before Ruby. And Python has pretty nice list comprehensions and, in fact, in some ways, features that enumerable doesn't have. But, still, coming to Ruby, I was like, oh, this enumerable; this is cool. This is something. And it's only gotten better. It still keeps growing, and the idea of custom enumerables. And yeah, there's some real neat stuff in there. +JOËL: I'm going to be speaking at RubyConf Mini this fall in November, and my talk is all about Enumerators and ranges in enumerable and ways you can use those to make the APIs of the objects that you create delightful for other people to use. +CHRIS: That sounds like a classic Joël talk right there that I will be happy to listen to when it comes out. A very quick related, a semi-related aside, so, tally, beautiful addition to the Ruby language. On the Rails side, there was one that I used recently, which is where.missing. Have you seen where.missing? +JOËL: I have not heard of this. +CHRIS: So where.missing is fantastic. Let's assume you've got two related objects, so you've got like a has many blah, so like a user has many posts. I think you can...if I'm remembering it correctly, it's User.where.missing(:posts). So it's where dot missing and then parentheses the symbol posts. And under the hood, Rails will do the whole LEFT OUTER JOIN where the count is null, et cetera. It turns into this wildly complex SQL query or understandably complex, but there's a lot going on there. And yet it compresses down so elegantly into this nice, little ActiveRecord bit. +So where.missing is my new favorite addition into the Rails landscape to complement tally on the Ruby side, which I think tally is Ruby 2.7, I want to say. So it's been around for a while. And where.missing might be a Ruby 7 feature. It might be a six-something, but still, wonderful features, ever-evolving these tool sets that we use. +JOËL: One of the really nice things about enumerable and family is the fact that they build on a very small amount of primitives, and so as long as you basically understand blocks, you can use enumerable and anything in there. It's not special syntax that you have to memorize. It's just regular functions and blocks. +Well, Chris, thank you so much for coming back for a visit. It's been a pleasure. And it's always good to have you share the cool things that you're doing at Sagewell. +CHRIS: Well, thank you so much, Joël. It's been an absolute pleasure getting to come back to this whole Bike Shed. And, again, just to add a note here, you're doing a really fantastic job with the show. It's been interesting transitioning back into listener mode for the show. Weirdly, I wasn't listening when I was a host. But now I've regained the ability to listen to The Bike Shed and really enjoy the episodes that you've been doing and the wonderful spectrum of guests that you've had on and variety of topics. So, yeah, thank you for hosting this whole Bike Shed. It's been great. +JOËL: And with that, let's wrap up. +The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris Toomey is back! (For an episode.) He talks about what he's been up to since handing off the reins to Joël. He's been playing around with something at Sagewell that he enjoys. At the core of it? Serializers.

+ +
+ +

Primalize gem
+Derek's talk on code review
+Inertia.js
+Phantom types
+io-ts
+dry-rb
+parse don't validate
+value objects
+broader perspective on parsing
+Enumerable#tally
+RubyConf mini
+where.missing

+ +

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. And today, I'm joined by a very special guest, former host Chris Toomey.

+ +

CHRIS: Hi, Joël. Thanks for having me.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Chris, what's new in your world?

+ +

CHRIS: Being on this podcast is new in my world, or everything old is new again, or something along those lines. But, yeah, thank you so much for having me back. It's a pleasure. Although it's very odd, it feels somehow so different and yet very familiar.

+ +

But yeah, more generally, what's new in my world? I think this was probably in development as I was winding down my time as a host here on The Bike Shed, but I don't know that I ever got a chance to talk about it. There has been a fun sort of deep-in-the-weeds technical thing that we've been playing around with at Sagewell that I've really enjoyed.

+ +

So at the core of it, we have serializers. So we take some data structures in our Ruby on Rails code base, and we need to serialize them to JSON to send them to the front end. In our case, we're using Inertia, so it's not quite a JSON API, but it's fine to think about it in that way for the context of this discussion.

+ +

And what we were finding is our front end has TypeScript. So we're writing Svelte, which is using TypeScript. And so we're stating or asserting that the types like, hey, we're going to get this data in from the back end, and it's going to have this shape to it. And we found that it was really hard to keep those in sync to keep, like, what does the user mean on the front end? What's the data that we're going to get? It's going to have a full name, which is a string, except sometimes that might be null. So how do we make sure that those are keeping up to date?

+ +

And then we had a growing number of serializers on the back end and determining which serializer we were actually using, and it was just...it was a mess, to put it lightly. And so we had explored a couple of different options around it, and eventually, we found a library called Primalize. So Primalize is a Ruby library. It is for writing JSON serializers. But what's really interesting about it is it has a typing layer. It's like a type system sort of thing at play.

+ +

So when you define a serializer in Primalize, instead of just saying, here are the fields; there is an ID, a name, et cetera, you say, there is an ID, and it is a string. There is a name, and it is a string, or an optional string, which is the even more interesting bit. You can say array. You can say object. You can say an enum of a couple of different values. And so we looked at that, and we said, ooh, this is very interesting. Astute listeners will know that this is probably useless in a Ruby system, which doesn't have types or a compilation step or anything like that.

+ +

But what's really cool about this is when you use a Primalize serializer, as you're serializing an object, if there is ever a type mismatch, so the observed type at runtime and the authored type if those ever mismatch, then you can have some sort of notification happen. So in our case, we configured it to send a warning to Sentry to say, "Hey, you said the types were this, but we're actually seeing this other thing." Most often, it will be like an Optional, a null sneaking through, a nil sneaking through on the Ruby side.

+ +

But what was really interesting is as we were squinting at this, we're like, huh, so now we're going to write all this type information. What if we could somehow get that type information down to the front end? So I had a long weekend, one weekend, and I went away, and I wrote a bunch of code that took all of those serializers, ran through them, and generated the associated TypeScript interfaces. And so now we have a build step that will essentially run that and assert that we're getting the same thing in CI as we have committed to the codebase.

+ +

But now we have the generated serializer types on the front end that match to the used serializer on the back end, as well as the observed run-time types. So it's a combination of a true compilation step type system on the front end and a run-time type system on the back end, which has been very, very interesting.

+ +

JOËL: I have a lot of thoughts here.

+ +

CHRIS: I figured you would. [laughs]

+ +

JOËL: But the first thing that came to mind is, as a consultant, there's a scenario with especially smaller startups that generally concerns me, and that is the CTO goes away for a weekend and writes a lot of code...

+ +

CHRIS: [laughs]

+ +

JOËL: And brings in a new system on Monday, which is exactly what you're describing here. How do you feel about the fact that you've done that?

+ +

CHRIS: I wasn't ready to go this deep this early on in this episode.

+ +

JOËL: [laughs]

+ +

CHRIS: But honestly, that is a fantastic question. It's a thing that I have been truly not struggling with but really thinking about. We're going to go on a slight aside here, but I am finding it really difficult to engage with the actual day-to-day coding work that we're doing and to still stay close to the codebase and not be in the way.

+ +

There's a pattern that I've seen happen a number of times now where I pick up a piece of work that is, you know, one of the tickets at the top of the backlog. I start to work on it. I get pulled into a meeting, then another meeting, then three more meetings. And suddenly, it's three days later. I haven't completed this piece of work that was defined to be the next most important piece of work. And suddenly, I'm blocking the team.

+ +

JOËL: Hmmm.

+ +

CHRIS: So I actually made a rule that I'm not allowed to own critical path work, which feels weird because it's like, I want to be engaged with that work. So the counterpoint to that is I'm now trying to schedule pairing sessions with each of the developers on the team once a week. And in that time, I can work on that sort of stuff with them, and they'll then own it and run with it. So it makes sure that I'm not blocking on those sorts of things, but I'm still connected to the core work that we're doing.

+ +

But the other thing that you're describing of the CTO goes away for the weekend and then comes back with a new harebrained scheme; I'm very sensitive to that, having worked on; frankly, I think the same project. I can think of a project that you and I worked on where we experienced this.

+ +

JOËL: I think we're thinking of the same project.

+ +

CHRIS: So yes. Like, I'm scarred by that and, frankly, a handful of experiences of that nature. So we actually, I think, have a really healthy system in place at Sagewell for capturing, documenting, prioritizing this sort of other work, this developer-centric work. So this is the feature and bug work that gets prioritized and one list over here that is owned by our product manager. Separately, the dev team gets to say, here are the pain points. Here's the stuff that keeps breaking. Here are the things that I wish was better. Here is the observability hard-to-understand bits.

+ +

And so we have a couple of different systems at play and recurring meetings and sort of unique ceremonies around that, and so this work was very much a fallout of that. It was actually a recurring topic that we kept trying a couple of different stabs at, and we never quite landed it. And then I showed up this one Monday morning, and I was like, "I found a thing; what do we think?" And then, critically, from there, I made sure I paired with other folks on the team as we pushed on the implementation.

+ +

And then, actually, I mentioned Primalize, the library that we're using. We have now since deprecated Primalize within the app because we kept just adding to it so much that eventually, we're like, at this point, should we own this stuff? So we ended up rewriting the core bits of Primalize to better fit our use cases. And now we've actually removed Primalize, wonderful library. I highly recommend it to anyone who has that particular use case but then the additional type generation for the front end.

+ +

Plus, we have some custom types within our app, Money being the most interesting one. We decided to model Money as our first-class consideration rather than just letting JavaScript have the sole idea of a number. But yes, in a very long-winded way, yes, I'm very sensitive to the thing you described. And I hope, in this case, I did not fall prey to the CTO goes away for the weekend and made a thing.

+ +

JOËL: I think what I'm hearing is the key difference here is that you got buy-in from the team around this idea before you went out and implemented it. So you're not off doing your own things disconnected from the team and then imposing it from on high. The team already agreed this is the thing we want to do, and then you just did it for them.

+ +

CHRIS: Largely, yes. Although I will say there are times that each developer on the team, myself included, have sort of gone away, come back with something, and said, "Hey, here's a WIP PR exploring an area." And there was actually...I'm forgetting what the context was, but there was one that happened recently that I introduced. I was like; I had to do this. And the team talked me out of it, and I ended up closing that PR. Someone else actually made a different PR that was an alternative implementation. I was like, no, that's better; we should absolutely do that.

+ +

And I think that's really healthy. That's a hard thing to maintain but making sure that everyone feels like they've got a strong voice and that we're considering all of the different ways in which we might consider the work. Most critically, you know, how does this impact users at the end of the day? That's always the primary consideration. How do we make sure we build a robust, maintainable, observable system, all those sorts of things?

+ +

And primarily, this work should go in that other direction, but I also don't want to stifle that creative spark of I got this thing in my head, and I had to explore it. Like, we shouldn't then need to never mind, throw away the work, put it into a ticket. Like, for as long as we can, that more organic, intuitive process if we can retain that, I like that. Critically, with the ability for everyone to tell me, "No, this is a bad idea. Stop it. What are you doing?" And that has happened recently. I mean, they were kinder about it, but they did talk me out of a bad idea. So here we are.

+ +

JOËL: So you showed up on Monday morning, not with telling everyone, "Hey, I merged this thing over the weekend." You're showing up with a work-in-progress PR.

+ +

CHRIS: Yes, definitely. I mean, everything goes through a PR, and everything has discussion and conversation around it. That's a strong, strong like Derek Prior's wonderful talk Building a Culture of Code Review. I forget the exact name of it. But it's one of my favorite talks in talking about the utility of code review as a way to share ideas and all of those wonderful things. So everything goes through code review, and particularly anything that is of that more exploratory architectural space.

+ +

Often we'll say any one review from anyone on the team is sufficient to merge most things but something like that, I would want to say, "Hey, can everybody take a look at this? And if anyone has any reservations, then let's talk about it more." But if I or anyone else on the team for this sort of work gets everybody approving it, then cool, we're good to go. But yeah, code review critical, critical part of the process.

+ +

JOËL: I'm curious about Primalize, the gem that you mentioned. It sounds like it's some kind of validation layer between some Ruby data structure and your serializers.

+ +

CHRIS: It is the serializer, but in the process of serializing, it does run-time type validation, essentially. So as it's accessing, you know, you say first name. You have a user object. You pass it in, and you say, "Serializer, there's a first name, and it's a string." It will call the first name method on that user object. And then, it will check that it has the expected type, and if it doesn't, then, in our case, it sends to Sentry.

+ +

We have configured it...it's actually interesting. In development and test mode, it will raise for a type mismatch, and in production mode, it will alert Sentry so you can configure that differently. But that ends up being really nice because these type mismatches end up being very loud early on. And it's surprisingly easy to maintain and ends up telling us a lot of truths about our system because, really, what we're doing is connecting data from many different systems and flowing it in and out. And all of the inputs and outputs from our system feel very meaningful to lock down in this way. But yeah, it's been an adventure.

+ +

JOËL: It seems to me there could almost be two sets of types here, the inputs coming into Primalize from your Ruby data structures and then the outputs that are the actual serialized values. And so you might expect, let's say, an integer on the Ruby side, but maybe at the serialization level, you're serializing it to a string. Do you have that sort of conversion step as part of your serializers sometimes, or is the idea that everything's already the right type on the Ruby side, and then we just, like, to JSON it at the end?

+ +

CHRIS: Yep. Primalize, I think, probably works a little closer to what you're describing. They have the idea of coercions. So within Primalize, there is the concept of a timestamp; that is one of the types that is available. But a timestamp is sort of the union of a date, a time, or I think they might let through a string; I'm not sure if there is as well. But frankly, for us, that was more ambiguity than we wanted or more blurring across the lines. And in the implementation that we've now built, date and time are distinct. And critically, a string is not a valid date or time; it is a string, that's another thing.

+ +

And so there's a bunch of plumbing within the way you define the serializers. There are override methods so that you can locally within the serializer say, like, oh, we need to coerce from the shape of data into this other shape of data, even little like in-line proc, so we can do it quickly. But the idea is that the data, once it has been passed to the serializer, should be up the right shape. And so when we get to the type assertion part of the library, we expect that things are in the asserted type and will warn if not. We get surprisingly few warnings, which is interesting now.

+ +

This whole process has made us pay a little more intention, and it's been less arduous simultaneously than I would have expected because like this is kind of a lot of work that I'm describing. And yet it ends up being very natural when you're the developer in context, like, oh, I've been reading these docs for days. I know the shape of this JSON that I'm working with inside and out, and now I'll just write it down in the serializer. It's very easy to do in that moment, and then it captures it and enforces it in such a useful way.

+ +

As an aside, as I've been looking at this, I'm like, this is just GraphQL, but inside out, I'm pretty sure. But that is a choice that we have made. We didn't want to adopt the whole GraphQL thing. But just for anyone out there who is listening and is thinking, isn't this just GraphQL but inside out? Kind of. Yes.

+ +

JOËL: I think my favorite part of GraphQL is the schema, which is not really the selling point for GraphQL, you know, like the idea that you can traverse the graph and get any subset of data that you want and all that. I think I would be more than happy with a REST API that has some kind of schema built around it. And someone told me that maybe what I really just want is SOAP, and I don't know how to feel about that comment.

+ +

CHRIS: You just got to have some XML, and some WSDLs, and other fun things. I've heard people say good things about SOAP. SOAP seems like a fine idea. If anything, I think a critical part of this is we don't have a JSON API. We have a very tightly coupled front end and back end, and a singular front end, frankly. And so that I think naturally...that makes the thing that I'm describing here a much more comfortable fit.

+ +

If we had multiple different downstream clients that we're trying to consume from the same back end, then I think a GraphQL API or some other structured JSON schema, whatever it is type of API, and associated documentation and typing layer would be probably a better fit. But as I've said many a time on this here, Bike Shed, Inertia is one of my favorite libraries or frameworks (They're probably more of a framework.) one of my favorite technological approaches that I have ever found.

+ +

And particularly in buildings Sagewell, it has allowed us to move so rapidly the idea that changes are, you know, one fell swoop changes everything within the codebase. We don't have to think about syncing deploys for the back end and the front end and how to coordinate across them. Our app is so much easier to understand by virtue of that architecture that Inertia implies.

+ +

JOËL: So, if I understand correctly, you don't serialize to JSON as part of the serializers. You're serializing directly to JavaScript.

+ +

CHRIS: We do serialize to JSON. At the end of the day, Inertia takes care of this on both the Rails side and the client side. There is a JSON API. Like, if you look at the network inspector, you will see XHR requests happening. But critically, we're not doing that. We're not the ones in charge of it. We're not hitting a specific endpoint.

+ +

It feels as an application coder much closer to a traditional Rails app. It just happens to be that we're writing our view layer. Instead of an ERB, we're writing them in Svelte files. But otherwise, it feels almost identical to a normal traditional Rails app with controllers and the normal routing and all that kind of stuff.

+ +

JOËL: One thing that's really interesting about JSON as an interchange format is that it is very restrictive. The primitives it has are even narrower than, say, the primitives that Ruby has. So you'd mentioned sending a date through. There is no JSON date. You have to serialize it to some other type, potentially an integer, potentially a string that has a format that the other side knows how it's going to interpret. And I feel like it's those sorts of richer types when we need to pass them through JSON that serialization and deserialization or parsing on the other end become really interesting.

+ +

CHRIS: Yeah, I definitely agree with that. It was a struggling point for a while until we found this new approach that we're doing with the serializers in the type system. But so far, the only thing that we've done this with is Money. But on the front end, a while ago, we introduced a specific TypeScript type. So it's a phantom type, and I believe I'm getting this correct. It's a phantom type called Cents, C-E-N-T-S. So it represents...I'm going to say an integer. I know that JavaScript doesn't have integers, but logically, it represents an integer amount of cents. And critically, it is not a number, like, the lowercase number in the type system. We cannot add them together. We can't --

+ +

JOËL: I thought you were going to say, NaN.

+ +

CHRIS: [laughs] It is not a number. I saw a n/a for not applicable somewhere in the application the other day. I was like, oh my God, we have a NaN? It happened? But it wasn't, it was just n/a, and I was fine. But yeah, so we have this idea of Cents within the application. We have a money input, which is a special input designed exactly for this. So to a user, it is formatted to look like you're entering dollars and cents. But under the hood, we are bidirectionally converting that to the integer amount of cents that we need. And we strictly, within the type system, those are cents.

+ +

And you can't do math on Cents unless you use a special set of helper functions. You cannot generate Cents on the fly unless you use a special set of helper functions, the constructor functions. So we've been really restrictive about that, which was kind of annoying because a lot of the data coming from the server is just, you know, numbers.

+ +

But now, with this type system that we've introduced on the Ruby side, we can assert and enforce that these are money.new on the Ruby side, so using the Money gem. And they come down to the front end as capital C Cents in the type system on the TypeScript side. So we're able to actually bind that together and then enforce proper usage sort of on both sides.

+ +

The next step that we plan to do after that is dates and times. And those are actually almost weirder because they end up...we just have to sort of say what they are, and they will be ISO 8601 date and time strings, respectively. But we'll have functions that know this is a date string; that's a thing. It is, again, a phantom type implemented within our TypeScript type system.

+ +

But we will have custom functions that deal with that and really constrain...lock ourselves down to only working with them correctly. And critically, saying that is the only date and time format that we work with; there is no other. We don't have arbitrary dates. Is this a JSON date or something else? I don't know; there are too many date syntaxes.

+ +

JOËL: I like the idea of what you're doing in that it sounds like you're very much narrowing that sort of window of where in the stack the data exists in the sort of unstructured, free-floating primitives that could be misinterpreted. And so, at this point, it's almost narrowed to the point where it can't be touched by any user or developer-written code because you've pushed the boundaries on the Rails side down and then on the JavaScript side up to the point where the translation here you define translations on one side or, I guess, a parser on one side and a serializer on the other. And they guarantee that everything is good up until that point.

+ +

CHRIS: Yep, with the added fun of the runtime reflection on the Ruby side. So it's an interesting thing. Like, TypeScript actually has similar things. You can say what the type is all day long, and your code will consistently conform to that asserted type. But at the end of the day, if your JSON API gets in some different data...unless you're using a library like io-ts, is one that I've looked at, which actually does parsing and returns a result object of did we parse to the thing that you wanted or did we get an error in that data structure?

+ +

So we could get to that level on the client side as well. We haven't done that yet largely because we've essentially pushed that concern up to the Ruby layer. So where we're authoring the data, because we own that, we're going to do it at that level. There are a bunch of benefits of defining it there and then sort of reflecting it down.

+ +

But yeah, TypeScript, you can absolutely lie to yourself, whereas Elm, a language that I know you love dearly, you cannot lie to yourself in Elm. You've got to tell the truth. It's the only option. You've got to prove it. Whereas in TypeScript, you can just kind of suggest, and TypeScript will be like, all right, cool, I'll make sure you stay honest on that, but I'm not going to make you prove it, which is an interesting sort of set of related trade-offs there.

+ +

But I think we found a very comfortable resting spot for right now. Although now, we're starting to look at the edges of the Ruby system where data is coming in. So we have lots of webhooks and other external partners that we're integrating with, and they're sending us data. And that data is of varying shapes. Some will send us a payload with the word amount, and it refers to an integer amount of cents because, of course, it does. Some will send us the word amount in their payload, and it will be a floating amount of dollars. And I get a little sad on those days.

+ +

But critically, our job is to make sure all of those are the same and that we never pass dollars as cents or cents as dollars because that's where things go sad. That is job number one at Sagewell in the engineering team is never get the decimal place wrong in money.

+ +

JOËL: That would be a pretty terrible mistake to make.

+ +

CHRIS: It would. I mean, it happens. In fintech, that problem comes up a lot. And again, the fact that...I'm honestly surprised to see situations out there where we're getting in floating point dollars. That is a surprise to me because I thought we had all agreed sort of as a community that it was integer cents but especially in a language that has integers. JavaScript, it's kind of making it up the whole time. But Ruby has integers. JSON, I guess, doesn't have integers, so I'm sort of mixing concerns here, but you get the idea.

+ +

JOËL: Despite Ruby not having a static type system, I've found that generally, when I'm integrating with a third-party API, I get to the point where I want something that approximates like Elm's JSON decoders or io-ts or something like that. Because JSON is just a big blob of data that could be of any shape, and I don't really trust it because it's third-party data, and you should not trust third parties. And I find that I end up maybe cobbling something together commonly with like a bunch of usage of hash.fetch, things like that. But I feel like Ruby doesn't have a great approach to parsing and composing these validators for external data.

+ +

CHRIS: Ruby as a language certainly doesn't, and the ecosystem, I would say, is rather limited in terms of the options here. We have looked a bit at the dry-rb stack of gems, so dry-validation and dry-schema, in particular, both offer potentially useful aspects. We've actually done a little bit of spiking internally around that sort of thing of, like, let's parse this incoming data instead of just coercing to hash and saying that it's got probably the shape that we want. And then similarly, I will fetch all day instead of digging because I want to be quite loud when we get it wrong.

+ +

But we're already using dry-monads. So we have the idea of result types within the system. We can either succeed or fail at certain operations. And I think it's just a little further down the stack. But probably something that we will implement soon is at those external boundaries where data is coming in doing some form of parsing and validation to make sure that it conforms to unknown data structure. And then, within the app, we can do things more cleanly.

+ +

That also would allow us to, like, let's push the idea that this is floating point dollars all the way out to the edge. And the minute it hits our system, we convert it into a money.new, which means that cents are properly handled. It's the same type of money or dollar, same type of currency handling as everywhere else in the app. And so pushing that to the very edges of our application is a very interesting idea. And so that could happen in the library or sort of a parsing client, I guess, is probably the best way to think about it. So I'm excited to do that at some point.

+ +

JOËL: Have you read the article, Parse, Don't Validate?

+ +

CHRIS: I actually posted that in some code review the other day to one of the developers on the team, and they replied, "You're just going to quietly drop one of my favorite articles of all time in code review?" [laughs] So yes, I've read it; I love it. It's a wonderful idea, definitely something that I'm intrigued by. And sort of bringing dry-monads into Ruby, on the one hand, feels like a forced fit and yet has also been one of the other, I think strongest sort of architectural decisions that we've made within the application.

+ +

There's so much imperative work that we ended up having to do. Send this off to this external API, then tell this other one, then tell this other one. Put the whole thing in a transaction so that our local data properly handles it. And having dry-monads do notation, in particular, to allow us to make that manageable but fail in all the ways it needs to fail, very expressive in its failure modes, that's been great. And then parse, don't validate we don't quite do it yet. But that's one of the dreams of, like, our codebase really should do that thing. We believe in that. So let's get there soon.

+ +

JOËL: And the core idea behind parse, don't validate is that instead of just having some data that you don't trust, running a check on it and passing that blob of now checked but still untrusted data down to the next person who might also want to check it. Generally, you want to pass it through some sort of filter that will, one, validate that it's correct but then actually typically convert it into some other trusted shape.

+ +

In Ruby, that might be something like taking an amorphous blob of JSON and turning it into some kind of value object or something like that. And then anybody downstream that receives, let's say, money object can trust that they're dealing with a well-formed money value as opposed to an arbitrary blob of JSON, which hopefully somebody else has validated, but who knows? So I'm going to validate it again.

+ +

CHRIS: You can tell that I've been out of the podcasting game for a while because I just started responding to yes; I love that blog post without describing the core premise of it. So kudos to you, Joël; you are a fantastic podcast host over there.

+ +

I will say one of the things you just described is an interesting...it's been a bit of a struggle for us. We keep sort of talking through what's the architecture. How do we want to build this application? What do we care about? What are the things that really matter within this codebase, and then what is all the other stuff? And we've been good at determining the things that really matter, thinking collectively as a group, and I think coming up with some novel, useful, elegant...I'm saying too many positive adjectives for what we're doing.

+ +

But I've been very happy with sort of the thing that we decide. And then there's the long-tail work of actually propagating that change throughout the rest of the application. We're, like, okay, here's how it works. Every incoming webhook, we now parse and yield a value object. That sentence that you just said a minute ago is exactly what I want. That's like a bunch of work. It's particularly a bunch of work to convert an existing codebase. It's easy to say, okay, from here forward, any new webhooks, payloads that are coming in, we're going to do in this way. But we have a lot of things in our app now that exist in this half-converted way.

+ +

There was a brief period where we had three different serializer technologies at play. Just this week, I did the work of killing off the middle ground one, the Primalized-based thing, and we now have only our new hotness and then the very old. We were using Blueprinter as the serializer as the initial sort of stub. And so that still exists within the codebase in some places. But trying to figure out how to prioritize that work, the finishing out those maintenance-type conversions is a tricky one. It's never the priority. But it is really nice to have consistency in a codebase. So it's...yeah, do you have any thoughts on that?
+JOËL: I think going back to the article and what the meaning of parsing is, I used to always think of parsing as taking strings and turning them into something else, and I think this really broadened my perspective on the idea of parsing. And now, I think of it more as converting from a broader type to a narrower type with failures.

+ +

So, for example, you could go from a string to an integer, and not all strings are valid integers. So you're narrowing the type. And if you have the string hello world, it will fail, and it will give you an error of some type. But you can have multiple layers of that. So maybe you have a string that you parse into an integer, but then, later on, you might want to parse that integer into something else that requires an integer in a range. Let's say it's a percentage. So you have a value object that is a percentage, but it's encoded in the JSON as a string.

+ +

So that first pass, you parse it from a string into an integer, and then you parse that integer into a percentage object. But if it's outside the range of valid percentage numbers, then maybe you get an error there as well. So it's a thing that can happen at multiple layers. And I've now really connected it with the primitive obsession smell in code. So oftentimes, when you decide, wait, I don't want a primitive here; I want a richer type, commonly, there's going to be a parsing step that should exist to go from that primitive into the richer type.

+ +

CHRIS: I like that. That was a classic Joël wildly concise summary of a deeply complex technical topic right there.

+ +

JOËL: It's like I'm going to connect some ideas from functional programming and a classic object-oriented code smell and, yeah, just kind of mash it all together with a popular article.

+ +

CHRIS: If only you had a diagram. Podcast is not the best medium for diagrams, but I think you could do it. You could speak one out loud, and everyone would be able to see it in their mind's eye.

+ +

JOËL: So I will tell you what my diagram is for this because I've actually created it already. I imagine this as a sort of like pyramid with different layers that keep getting smaller and smaller. So the size of type is sort of the width of a layer. And so your strings are a very wide layer. Then on top of that, you have a narrower layer that might be, you know, it could be an integer, or you could even if you're parsing JSON, you first start with a string, then you parse that into a Ruby hash, not all strings are valid hashes. So that's going to be narrower.

+ +

Then you might extract some values out of that hash. But if the keys aren't right, that might also fail. You're trying to pull the user out of it. And so each layer it gets a richer type, but that richer type, by virtue of being richer, is narrower. And as you're trying to move up that pyramid at every step, there is a possibility for a failure.

+ +

CHRIS: Have you written a blog post about this with said diagram in it? And is that why you have that so readily at hand? [laughs]

+ +

JOËL: Yes, that is the case.

+ +

CHRIS: Okay. Yeah, that made sense to me. [laughs]

+ +

JOËL: We'll make sure to link to it in the show notes.

+ +

CHRIS: Now you have to link to Joël blog posts, whereas I used to have to link to them [chuckles] in almost every episode of The Bike Shed that I recorded.

+ +

JOËL: Another thing I've been thinking about in terms of this parsing is that parsing and serializing are, in a sense, almost opposites of each other. Typically, when you're parsing, you're going from a broad type to a narrow one. And when you're serializing, you're going from a narrow type to a broader one. So you might go from a user into a hash into a string. So you're sort of going down that pyramid rather than going up.

+ +

CHRIS: It is an interesting observation and one that immediately my brain is like, okay, cool. So can we reuse our serializers but just run them in reverse or? And then I try and talk myself out of that because that's a classic don't repeat yourself sort of failure mode of, like, actually, it's fine. You can repeat a little bit. So long as you can repeat and constrain, that's a fine version. But yeah, feels true, though, at the core.

+ +

JOËL: I think, in some ways, if you want a single source of truth, what you want is a schema, and then you can derive serializers and parsers from that schema.

+ +

CHRIS: It's interesting because you used the word derive. That has been an interesting evolution at Sagewell. The engineering team seems to be very collected around the idea of explicitness, almost the Zen of Python; explicit is better than implicit. And we are willing to write a lot of words down a lot of times and be happy with that. I think we actually made the explicit choice at one point that we will not implement an automatic camel case conversion in our serializer, even though we could; this is a knowable piece of code.

+ +

But what we want is the grepability from the front end to the back end to say, like, where's this data coming from? And being able to say, like, it is this data, which is from this serializer, which comes from this object method, and being able to trace that very literally and very explicitly in the code, even though that is definitely the sort of thing that we could derive or automatically infer or have Ruby do that translation for us.

+ +

And our codebase is more verbose and a little noisier. But I think overall, I've been very happy with it, and I think the team has been very happy. But it is an interesting one because I've seen plenty of teams where it is the exact opposite. Any repeated characters must be destroyed. We must write code to write the code for us. And so it's fun to be working with a team where we seem to be aligned around an approach on that front.

+ +

JOËL: That example that you gave is really interesting because I feel like a common thing that happens in a serialization layer is also a form of normalization. And so, for example, you might downcase all strings as part of the serialization, definitely, like dates always get written in ISO 8601 format whenever that happens. And so, regardless of how you might have it stored on the Ruby side, by the time it gets to the JSON, it's always in a standard format. And it sounds like you're not necessarily doing that with capitalization.

+ +

CHRIS: I think the distinction would be the keys and the values, so we are definitely doing normalization on the values side. So ISO 8601 date and time strings, respectively that, is the direction that we plan to go for the value. But then for the key that's associated with that, what is the name for this data, those we're choosing to be explicit and somewhat repetitive, or not even necessarily repetitive, but the idea of, like, it's first_name on the Ruby side, and it's first capital N name camel case, or it's...I forget the name. It's not quite camel case; it's a different one but lower camel, maybe.

+ +

But whatever JavaScript uses, we try to bias towards that when we're going to the front end. It does get a little tricky coming back into the Ruby side. So our controllers have a bunch of places where they need to know about what I think is called lower camel case, and so we're not perfect there. But that critical distinction between sort of the names for things, and the values for things, transformations, and normalizations on the values, I'm good with that. But we've chosen to go with a much more explicit version for the names of things or the keys in JSON objects specifically.

+ +

JOËL: One thing that can be interesting if you have a normalization phase in your serializer is that that can mean that your serializer and parsers are not necessarily symmetric. So you might accept malformed data into your parser and parse it correctly. But then you can't guarantee that the data that gets serialized out is going to identically match the data that got parsed in.

+ +

CHRIS: Yeah, that is interesting. I'm not quite sure of the ramifications, although I feel like there are some. It almost feels like formatting Prettier and things like that where they need to hold on to whitespace in some cases and throw out in others. I'm thinking about how ASTs work. And, I don't know, there's interesting stuff, but, again, not sure of the ramifications.

+ +

But actually, to flip the tables just a little bit, and that's an aggressive terminology, but we're going to roll with it. To flip the script, let's go with that, Joël; what's been up in your world? You've been hosting this wonderful show. I've listened in to a number of episodes. You're doing a fantastic job. I want to hear a little bit more of what's new in your world, Joël.

+ +

JOËL: So I've been working on a project that has a lot of flaky tests, and we're trying to figure out the source of that flakiness. It's easy to just dive into, oh, I saw a flaky Test. Let me try to fix it. But we have so much flakiness that I want to go about it a little bit more systematically. And so my first step has actually been gathering data. So I've actually been able to make API requests to our CI server. And the way we figure out flakiness is looking at the commit hash that a particular test suite run has executed on.

+ +

And if there's more than one CI build for a given commit hash, we know that's probably some kind of flakiness. It could be a legitimate failure that somebody assumed was flakiness, and so they just re-run CI. But the symptom that we are trying to address is the fact that we have a very high level of people re-verifying their code. And so to do that or to figure out some stats, I made a request to the API grouped by commit hash and then was able to get the stats of how many re-verifications there are and even the distribution.

+ +

The classic way that you would do that is in Ruby; you would use the GroupBy function from enumerable. And then, you would transform values instead of having, like, say; each commit hash then points to all the builds, an array of builds that match that commit hash. You would then thumb those. So now you have commit hashes that point to counts of how many builds there were for that commit hash. Newer versions of Ruby introduced the tally method, which I love, which allows you to basically do all of that in one step.

+ +

One thing that I found really interesting, though, is that that will then give me a hash of commit hashes that point to the number of builds that are there. If I want to get the distribution for the whole project over the course of, say, the last week, and I want to say, "How many times do people run only one CI run versus running twice in the same commit versus running three times, or four times, or five or six times?" I want to see that distribution of how many times people are rerunning their build. You're effectively doing that tally process twice.

+ +

So once you have a list of all the builds, you group by hash. You count, and so you end up with that. You have the Ruby hash of commit SHAs pointing to number of times the build was run on that. And then, you again group by the number of builds for each commit SHA. And so now what you have is you'll have something like one, and then that points to an array of SHA one, SHA two, SHA three, SHA four like all the builds.

+ +

And then you tally that again, or you transform values, or however, you end up doing it. And what you end up with is saying for running only once, I now have 200 builds that ran only once. For running twice in the same commit SHA, there are 15. For running three times, there are two. For running four times, there is one. And now I've got my distribution broken down by how many times it was run. It took me a while to work through all of that. But now the shortcut in my head is going to be you double tally to get distribution.

+ +

CHRIS: As an aside, the whole everything you're talking about is interesting and getting to that distribution. I feel like I've tried to solve that problem on data recently and struggled with it. But particularly tally, I just want to spend a minute because tally is such a fantastic addition to the Ruby standard library. I used to have in sort of like loose muscle memory transform value is grouped by ampersand itself, transform values count, sort, reverse to H. That whole string of nonsense gets replaced by tally, and, oof, what a beautiful example of Ruby, and enumerable, and all of the wonder that you can encapsulate there.

+ +

JOËL: Enumerable is one of the best parts of Ruby. I love it so much. It was one of the first things that just blew my mind about Ruby when I started. I came from a PHP, C++ background and was used to writing for loops for everything and not the nice for each loops that a lot of languages have these days. You're writing like a legit for or while loop, and you're managing the indexes yourself. And there's so much room for things to go wrong.

+ +

And being introduced to each blew my mind. And I was like, this is so beautiful. I'm not dealing with indexes. I'm not dealing with the raw implementation of the array. I can just say do a thing for each element. This is amazing. And that is when I truly fell in love with Ruby.

+ +

CHRIS: I want to say I came from Python, most recently before Ruby. And Python has pretty nice list comprehensions and, in fact, in some ways, features that enumerable doesn't have. But, still, coming to Ruby, I was like, oh, this enumerable; this is cool. This is something. And it's only gotten better. It still keeps growing, and the idea of custom enumerables. And yeah, there's some real neat stuff in there.

+ +

JOËL: I'm going to be speaking at RubyConf Mini this fall in November, and my talk is all about Enumerators and ranges in enumerable and ways you can use those to make the APIs of the objects that you create delightful for other people to use.

+ +

CHRIS: That sounds like a classic Joël talk right there that I will be happy to listen to when it comes out. A very quick related, a semi-related aside, so, tally, beautiful addition to the Ruby language. On the Rails side, there was one that I used recently, which is where.missing. Have you seen where.missing?

+ +

JOËL: I have not heard of this.

+ +

CHRIS: So where.missing is fantastic. Let's assume you've got two related objects, so you've got like a has many blah, so like a user has many posts. I think you can...if I'm remembering it correctly, it's User.where.missing(:posts). So it's where dot missing and then parentheses the symbol posts. And under the hood, Rails will do the whole LEFT OUTER JOIN where the count is null, et cetera. It turns into this wildly complex SQL query or understandably complex, but there's a lot going on there. And yet it compresses down so elegantly into this nice, little ActiveRecord bit.

+ +

So where.missing is my new favorite addition into the Rails landscape to complement tally on the Ruby side, which I think tally is Ruby 2.7, I want to say. So it's been around for a while. And where.missing might be a Ruby 7 feature. It might be a six-something, but still, wonderful features, ever-evolving these tool sets that we use.

+ +

JOËL: One of the really nice things about enumerable and family is the fact that they build on a very small amount of primitives, and so as long as you basically understand blocks, you can use enumerable and anything in there. It's not special syntax that you have to memorize. It's just regular functions and blocks.

+ +

Well, Chris, thank you so much for coming back for a visit. It's been a pleasure. And it's always good to have you share the cool things that you're doing at Sagewell.

+ +

CHRIS: Well, thank you so much, Joël. It's been an absolute pleasure getting to come back to this whole Bike Shed. And, again, just to add a note here, you're doing a really fantastic job with the show. It's been interesting transitioning back into listener mode for the show. Weirdly, I wasn't listening when I was a host. But now I've regained the ability to listen to The Bike Shed and really enjoy the episodes that you've been doing and the wonderful spectrum of guests that you've had on and variety of topics. So, yeah, thank you for hosting this whole Bike Shed. It's been great.

+ +

JOËL: And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Chris Toomey is back! (For an episode.) He talks about what he's been up to since handing off the reins to Joël. He's been playing around with something at Sagewell that he enjoys. At the core of it? Serializers.

+ +
+ +

Primalize gem
+Derek's talk on code review
+Inertia.js
+Phantom types
+io-ts
+dry-rb
+parse don't validate
+value objects
+broader perspective on parsing
+Enumerable#tally
+RubyConf mini
+where.missing

+ +

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. And today, I'm joined by a very special guest, former host Chris Toomey.

+ +

CHRIS: Hi, Joël. Thanks for having me.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Chris, what's new in your world?

+ +

CHRIS: Being on this podcast is new in my world, or everything old is new again, or something along those lines. But, yeah, thank you so much for having me back. It's a pleasure. Although it's very odd, it feels somehow so different and yet very familiar.

+ +

But yeah, more generally, what's new in my world? I think this was probably in development as I was winding down my time as a host here on The Bike Shed, but I don't know that I ever got a chance to talk about it. There has been a fun sort of deep-in-the-weeds technical thing that we've been playing around with at Sagewell that I've really enjoyed.

+ +

So at the core of it, we have serializers. So we take some data structures in our Ruby on Rails code base, and we need to serialize them to JSON to send them to the front end. In our case, we're using Inertia, so it's not quite a JSON API, but it's fine to think about it in that way for the context of this discussion.

+ +

And what we were finding is our front end has TypeScript. So we're writing Svelte, which is using TypeScript. And so we're stating or asserting that the types like, hey, we're going to get this data in from the back end, and it's going to have this shape to it. And we found that it was really hard to keep those in sync to keep, like, what does the user mean on the front end? What's the data that we're going to get? It's going to have a full name, which is a string, except sometimes that might be null. So how do we make sure that those are keeping up to date?

+ +

And then we had a growing number of serializers on the back end and determining which serializer we were actually using, and it was just...it was a mess, to put it lightly. And so we had explored a couple of different options around it, and eventually, we found a library called Primalize. So Primalize is a Ruby library. It is for writing JSON serializers. But what's really interesting about it is it has a typing layer. It's like a type system sort of thing at play.

+ +

So when you define a serializer in Primalize, instead of just saying, here are the fields; there is an ID, a name, et cetera, you say, there is an ID, and it is a string. There is a name, and it is a string, or an optional string, which is the even more interesting bit. You can say array. You can say object. You can say an enum of a couple of different values. And so we looked at that, and we said, ooh, this is very interesting. Astute listeners will know that this is probably useless in a Ruby system, which doesn't have types or a compilation step or anything like that.

+ +

But what's really cool about this is when you use a Primalize serializer, as you're serializing an object, if there is ever a type mismatch, so the observed type at runtime and the authored type if those ever mismatch, then you can have some sort of notification happen. So in our case, we configured it to send a warning to Sentry to say, "Hey, you said the types were this, but we're actually seeing this other thing." Most often, it will be like an Optional, a null sneaking through, a nil sneaking through on the Ruby side.

+ +

But what was really interesting is as we were squinting at this, we're like, huh, so now we're going to write all this type information. What if we could somehow get that type information down to the front end? So I had a long weekend, one weekend, and I went away, and I wrote a bunch of code that took all of those serializers, ran through them, and generated the associated TypeScript interfaces. And so now we have a build step that will essentially run that and assert that we're getting the same thing in CI as we have committed to the codebase.

+ +

But now we have the generated serializer types on the front end that match to the used serializer on the back end, as well as the observed run-time types. So it's a combination of a true compilation step type system on the front end and a run-time type system on the back end, which has been very, very interesting.

+ +

JOËL: I have a lot of thoughts here.

+ +

CHRIS: I figured you would. [laughs]

+ +

JOËL: But the first thing that came to mind is, as a consultant, there's a scenario with especially smaller startups that generally concerns me, and that is the CTO goes away for a weekend and writes a lot of code...

+ +

CHRIS: [laughs]

+ +

JOËL: And brings in a new system on Monday, which is exactly what you're describing here. How do you feel about the fact that you've done that?

+ +

CHRIS: I wasn't ready to go this deep this early on in this episode.

+ +

JOËL: [laughs]

+ +

CHRIS: But honestly, that is a fantastic question. It's a thing that I have been truly not struggling with but really thinking about. We're going to go on a slight aside here, but I am finding it really difficult to engage with the actual day-to-day coding work that we're doing and to still stay close to the codebase and not be in the way.

+ +

There's a pattern that I've seen happen a number of times now where I pick up a piece of work that is, you know, one of the tickets at the top of the backlog. I start to work on it. I get pulled into a meeting, then another meeting, then three more meetings. And suddenly, it's three days later. I haven't completed this piece of work that was defined to be the next most important piece of work. And suddenly, I'm blocking the team.

+ +

JOËL: Hmmm.

+ +

CHRIS: So I actually made a rule that I'm not allowed to own critical path work, which feels weird because it's like, I want to be engaged with that work. So the counterpoint to that is I'm now trying to schedule pairing sessions with each of the developers on the team once a week. And in that time, I can work on that sort of stuff with them, and they'll then own it and run with it. So it makes sure that I'm not blocking on those sorts of things, but I'm still connected to the core work that we're doing.

+ +

But the other thing that you're describing of the CTO goes away for the weekend and then comes back with a new harebrained scheme; I'm very sensitive to that, having worked on; frankly, I think the same project. I can think of a project that you and I worked on where we experienced this.

+ +

JOËL: I think we're thinking of the same project.

+ +

CHRIS: So yes. Like, I'm scarred by that and, frankly, a handful of experiences of that nature. So we actually, I think, have a really healthy system in place at Sagewell for capturing, documenting, prioritizing this sort of other work, this developer-centric work. So this is the feature and bug work that gets prioritized and one list over here that is owned by our product manager. Separately, the dev team gets to say, here are the pain points. Here's the stuff that keeps breaking. Here are the things that I wish was better. Here is the observability hard-to-understand bits.

+ +

And so we have a couple of different systems at play and recurring meetings and sort of unique ceremonies around that, and so this work was very much a fallout of that. It was actually a recurring topic that we kept trying a couple of different stabs at, and we never quite landed it. And then I showed up this one Monday morning, and I was like, "I found a thing; what do we think?" And then, critically, from there, I made sure I paired with other folks on the team as we pushed on the implementation.

+ +

And then, actually, I mentioned Primalize, the library that we're using. We have now since deprecated Primalize within the app because we kept just adding to it so much that eventually, we're like, at this point, should we own this stuff? So we ended up rewriting the core bits of Primalize to better fit our use cases. And now we've actually removed Primalize, wonderful library. I highly recommend it to anyone who has that particular use case but then the additional type generation for the front end.

+ +

Plus, we have some custom types within our app, Money being the most interesting one. We decided to model Money as our first-class consideration rather than just letting JavaScript have the sole idea of a number. But yes, in a very long-winded way, yes, I'm very sensitive to the thing you described. And I hope, in this case, I did not fall prey to the CTO goes away for the weekend and made a thing.

+ +

JOËL: I think what I'm hearing is the key difference here is that you got buy-in from the team around this idea before you went out and implemented it. So you're not off doing your own things disconnected from the team and then imposing it from on high. The team already agreed this is the thing we want to do, and then you just did it for them.

+ +

CHRIS: Largely, yes. Although I will say there are times that each developer on the team, myself included, have sort of gone away, come back with something, and said, "Hey, here's a WIP PR exploring an area." And there was actually...I'm forgetting what the context was, but there was one that happened recently that I introduced. I was like; I had to do this. And the team talked me out of it, and I ended up closing that PR. Someone else actually made a different PR that was an alternative implementation. I was like, no, that's better; we should absolutely do that.

+ +

And I think that's really healthy. That's a hard thing to maintain but making sure that everyone feels like they've got a strong voice and that we're considering all of the different ways in which we might consider the work. Most critically, you know, how does this impact users at the end of the day? That's always the primary consideration. How do we make sure we build a robust, maintainable, observable system, all those sorts of things?

+ +

And primarily, this work should go in that other direction, but I also don't want to stifle that creative spark of I got this thing in my head, and I had to explore it. Like, we shouldn't then need to never mind, throw away the work, put it into a ticket. Like, for as long as we can, that more organic, intuitive process if we can retain that, I like that. Critically, with the ability for everyone to tell me, "No, this is a bad idea. Stop it. What are you doing?" And that has happened recently. I mean, they were kinder about it, but they did talk me out of a bad idea. So here we are.

+ +

JOËL: So you showed up on Monday morning, not with telling everyone, "Hey, I merged this thing over the weekend." You're showing up with a work-in-progress PR.

+ +

CHRIS: Yes, definitely. I mean, everything goes through a PR, and everything has discussion and conversation around it. That's a strong, strong like Derek Prior's wonderful talk Building a Culture of Code Review. I forget the exact name of it. But it's one of my favorite talks in talking about the utility of code review as a way to share ideas and all of those wonderful things. So everything goes through code review, and particularly anything that is of that more exploratory architectural space.

+ +

Often we'll say any one review from anyone on the team is sufficient to merge most things but something like that, I would want to say, "Hey, can everybody take a look at this? And if anyone has any reservations, then let's talk about it more." But if I or anyone else on the team for this sort of work gets everybody approving it, then cool, we're good to go. But yeah, code review critical, critical part of the process.

+ +

JOËL: I'm curious about Primalize, the gem that you mentioned. It sounds like it's some kind of validation layer between some Ruby data structure and your serializers.

+ +

CHRIS: It is the serializer, but in the process of serializing, it does run-time type validation, essentially. So as it's accessing, you know, you say first name. You have a user object. You pass it in, and you say, "Serializer, there's a first name, and it's a string." It will call the first name method on that user object. And then, it will check that it has the expected type, and if it doesn't, then, in our case, it sends to Sentry.

+ +

We have configured it...it's actually interesting. In development and test mode, it will raise for a type mismatch, and in production mode, it will alert Sentry so you can configure that differently. But that ends up being really nice because these type mismatches end up being very loud early on. And it's surprisingly easy to maintain and ends up telling us a lot of truths about our system because, really, what we're doing is connecting data from many different systems and flowing it in and out. And all of the inputs and outputs from our system feel very meaningful to lock down in this way. But yeah, it's been an adventure.

+ +

JOËL: It seems to me there could almost be two sets of types here, the inputs coming into Primalize from your Ruby data structures and then the outputs that are the actual serialized values. And so you might expect, let's say, an integer on the Ruby side, but maybe at the serialization level, you're serializing it to a string. Do you have that sort of conversion step as part of your serializers sometimes, or is the idea that everything's already the right type on the Ruby side, and then we just, like, to JSON it at the end?

+ +

CHRIS: Yep. Primalize, I think, probably works a little closer to what you're describing. They have the idea of coercions. So within Primalize, there is the concept of a timestamp; that is one of the types that is available. But a timestamp is sort of the union of a date, a time, or I think they might let through a string; I'm not sure if there is as well. But frankly, for us, that was more ambiguity than we wanted or more blurring across the lines. And in the implementation that we've now built, date and time are distinct. And critically, a string is not a valid date or time; it is a string, that's another thing.

+ +

And so there's a bunch of plumbing within the way you define the serializers. There are override methods so that you can locally within the serializer say, like, oh, we need to coerce from the shape of data into this other shape of data, even little like in-line proc, so we can do it quickly. But the idea is that the data, once it has been passed to the serializer, should be up the right shape. And so when we get to the type assertion part of the library, we expect that things are in the asserted type and will warn if not. We get surprisingly few warnings, which is interesting now.

+ +

This whole process has made us pay a little more intention, and it's been less arduous simultaneously than I would have expected because like this is kind of a lot of work that I'm describing. And yet it ends up being very natural when you're the developer in context, like, oh, I've been reading these docs for days. I know the shape of this JSON that I'm working with inside and out, and now I'll just write it down in the serializer. It's very easy to do in that moment, and then it captures it and enforces it in such a useful way.

+ +

As an aside, as I've been looking at this, I'm like, this is just GraphQL, but inside out, I'm pretty sure. But that is a choice that we have made. We didn't want to adopt the whole GraphQL thing. But just for anyone out there who is listening and is thinking, isn't this just GraphQL but inside out? Kind of. Yes.

+ +

JOËL: I think my favorite part of GraphQL is the schema, which is not really the selling point for GraphQL, you know, like the idea that you can traverse the graph and get any subset of data that you want and all that. I think I would be more than happy with a REST API that has some kind of schema built around it. And someone told me that maybe what I really just want is SOAP, and I don't know how to feel about that comment.

+ +

CHRIS: You just got to have some XML, and some WSDLs, and other fun things. I've heard people say good things about SOAP. SOAP seems like a fine idea. If anything, I think a critical part of this is we don't have a JSON API. We have a very tightly coupled front end and back end, and a singular front end, frankly. And so that I think naturally...that makes the thing that I'm describing here a much more comfortable fit.

+ +

If we had multiple different downstream clients that we're trying to consume from the same back end, then I think a GraphQL API or some other structured JSON schema, whatever it is type of API, and associated documentation and typing layer would be probably a better fit. But as I've said many a time on this here, Bike Shed, Inertia is one of my favorite libraries or frameworks (They're probably more of a framework.) one of my favorite technological approaches that I have ever found.

+ +

And particularly in buildings Sagewell, it has allowed us to move so rapidly the idea that changes are, you know, one fell swoop changes everything within the codebase. We don't have to think about syncing deploys for the back end and the front end and how to coordinate across them. Our app is so much easier to understand by virtue of that architecture that Inertia implies.

+ +

JOËL: So, if I understand correctly, you don't serialize to JSON as part of the serializers. You're serializing directly to JavaScript.

+ +

CHRIS: We do serialize to JSON. At the end of the day, Inertia takes care of this on both the Rails side and the client side. There is a JSON API. Like, if you look at the network inspector, you will see XHR requests happening. But critically, we're not doing that. We're not the ones in charge of it. We're not hitting a specific endpoint.

+ +

It feels as an application coder much closer to a traditional Rails app. It just happens to be that we're writing our view layer. Instead of an ERB, we're writing them in Svelte files. But otherwise, it feels almost identical to a normal traditional Rails app with controllers and the normal routing and all that kind of stuff.

+ +

JOËL: One thing that's really interesting about JSON as an interchange format is that it is very restrictive. The primitives it has are even narrower than, say, the primitives that Ruby has. So you'd mentioned sending a date through. There is no JSON date. You have to serialize it to some other type, potentially an integer, potentially a string that has a format that the other side knows how it's going to interpret. And I feel like it's those sorts of richer types when we need to pass them through JSON that serialization and deserialization or parsing on the other end become really interesting.

+ +

CHRIS: Yeah, I definitely agree with that. It was a struggling point for a while until we found this new approach that we're doing with the serializers in the type system. But so far, the only thing that we've done this with is Money. But on the front end, a while ago, we introduced a specific TypeScript type. So it's a phantom type, and I believe I'm getting this correct. It's a phantom type called Cents, C-E-N-T-S. So it represents...I'm going to say an integer. I know that JavaScript doesn't have integers, but logically, it represents an integer amount of cents. And critically, it is not a number, like, the lowercase number in the type system. We cannot add them together. We can't --

+ +

JOËL: I thought you were going to say, NaN.

+ +

CHRIS: [laughs] It is not a number. I saw a n/a for not applicable somewhere in the application the other day. I was like, oh my God, we have a NaN? It happened? But it wasn't, it was just n/a, and I was fine. But yeah, so we have this idea of Cents within the application. We have a money input, which is a special input designed exactly for this. So to a user, it is formatted to look like you're entering dollars and cents. But under the hood, we are bidirectionally converting that to the integer amount of cents that we need. And we strictly, within the type system, those are cents.

+ +

And you can't do math on Cents unless you use a special set of helper functions. You cannot generate Cents on the fly unless you use a special set of helper functions, the constructor functions. So we've been really restrictive about that, which was kind of annoying because a lot of the data coming from the server is just, you know, numbers.

+ +

But now, with this type system that we've introduced on the Ruby side, we can assert and enforce that these are money.new on the Ruby side, so using the Money gem. And they come down to the front end as capital C Cents in the type system on the TypeScript side. So we're able to actually bind that together and then enforce proper usage sort of on both sides.

+ +

The next step that we plan to do after that is dates and times. And those are actually almost weirder because they end up...we just have to sort of say what they are, and they will be ISO 8601 date and time strings, respectively. But we'll have functions that know this is a date string; that's a thing. It is, again, a phantom type implemented within our TypeScript type system.

+ +

But we will have custom functions that deal with that and really constrain...lock ourselves down to only working with them correctly. And critically, saying that is the only date and time format that we work with; there is no other. We don't have arbitrary dates. Is this a JSON date or something else? I don't know; there are too many date syntaxes.

+ +

JOËL: I like the idea of what you're doing in that it sounds like you're very much narrowing that sort of window of where in the stack the data exists in the sort of unstructured, free-floating primitives that could be misinterpreted. And so, at this point, it's almost narrowed to the point where it can't be touched by any user or developer-written code because you've pushed the boundaries on the Rails side down and then on the JavaScript side up to the point where the translation here you define translations on one side or, I guess, a parser on one side and a serializer on the other. And they guarantee that everything is good up until that point.

+ +

CHRIS: Yep, with the added fun of the runtime reflection on the Ruby side. So it's an interesting thing. Like, TypeScript actually has similar things. You can say what the type is all day long, and your code will consistently conform to that asserted type. But at the end of the day, if your JSON API gets in some different data...unless you're using a library like io-ts, is one that I've looked at, which actually does parsing and returns a result object of did we parse to the thing that you wanted or did we get an error in that data structure?

+ +

So we could get to that level on the client side as well. We haven't done that yet largely because we've essentially pushed that concern up to the Ruby layer. So where we're authoring the data, because we own that, we're going to do it at that level. There are a bunch of benefits of defining it there and then sort of reflecting it down.

+ +

But yeah, TypeScript, you can absolutely lie to yourself, whereas Elm, a language that I know you love dearly, you cannot lie to yourself in Elm. You've got to tell the truth. It's the only option. You've got to prove it. Whereas in TypeScript, you can just kind of suggest, and TypeScript will be like, all right, cool, I'll make sure you stay honest on that, but I'm not going to make you prove it, which is an interesting sort of set of related trade-offs there.

+ +

But I think we found a very comfortable resting spot for right now. Although now, we're starting to look at the edges of the Ruby system where data is coming in. So we have lots of webhooks and other external partners that we're integrating with, and they're sending us data. And that data is of varying shapes. Some will send us a payload with the word amount, and it refers to an integer amount of cents because, of course, it does. Some will send us the word amount in their payload, and it will be a floating amount of dollars. And I get a little sad on those days.

+ +

But critically, our job is to make sure all of those are the same and that we never pass dollars as cents or cents as dollars because that's where things go sad. That is job number one at Sagewell in the engineering team is never get the decimal place wrong in money.

+ +

JOËL: That would be a pretty terrible mistake to make.

+ +

CHRIS: It would. I mean, it happens. In fintech, that problem comes up a lot. And again, the fact that...I'm honestly surprised to see situations out there where we're getting in floating point dollars. That is a surprise to me because I thought we had all agreed sort of as a community that it was integer cents but especially in a language that has integers. JavaScript, it's kind of making it up the whole time. But Ruby has integers. JSON, I guess, doesn't have integers, so I'm sort of mixing concerns here, but you get the idea.

+ +

JOËL: Despite Ruby not having a static type system, I've found that generally, when I'm integrating with a third-party API, I get to the point where I want something that approximates like Elm's JSON decoders or io-ts or something like that. Because JSON is just a big blob of data that could be of any shape, and I don't really trust it because it's third-party data, and you should not trust third parties. And I find that I end up maybe cobbling something together commonly with like a bunch of usage of hash.fetch, things like that. But I feel like Ruby doesn't have a great approach to parsing and composing these validators for external data.

+ +

CHRIS: Ruby as a language certainly doesn't, and the ecosystem, I would say, is rather limited in terms of the options here. We have looked a bit at the dry-rb stack of gems, so dry-validation and dry-schema, in particular, both offer potentially useful aspects. We've actually done a little bit of spiking internally around that sort of thing of, like, let's parse this incoming data instead of just coercing to hash and saying that it's got probably the shape that we want. And then similarly, I will fetch all day instead of digging because I want to be quite loud when we get it wrong.

+ +

But we're already using dry-monads. So we have the idea of result types within the system. We can either succeed or fail at certain operations. And I think it's just a little further down the stack. But probably something that we will implement soon is at those external boundaries where data is coming in doing some form of parsing and validation to make sure that it conforms to unknown data structure. And then, within the app, we can do things more cleanly.

+ +

That also would allow us to, like, let's push the idea that this is floating point dollars all the way out to the edge. And the minute it hits our system, we convert it into a money.new, which means that cents are properly handled. It's the same type of money or dollar, same type of currency handling as everywhere else in the app. And so pushing that to the very edges of our application is a very interesting idea. And so that could happen in the library or sort of a parsing client, I guess, is probably the best way to think about it. So I'm excited to do that at some point.

+ +

JOËL: Have you read the article, Parse, Don't Validate?

+ +

CHRIS: I actually posted that in some code review the other day to one of the developers on the team, and they replied, "You're just going to quietly drop one of my favorite articles of all time in code review?" [laughs] So yes, I've read it; I love it. It's a wonderful idea, definitely something that I'm intrigued by. And sort of bringing dry-monads into Ruby, on the one hand, feels like a forced fit and yet has also been one of the other, I think strongest sort of architectural decisions that we've made within the application.

+ +

There's so much imperative work that we ended up having to do. Send this off to this external API, then tell this other one, then tell this other one. Put the whole thing in a transaction so that our local data properly handles it. And having dry-monads do notation, in particular, to allow us to make that manageable but fail in all the ways it needs to fail, very expressive in its failure modes, that's been great. And then parse, don't validate we don't quite do it yet. But that's one of the dreams of, like, our codebase really should do that thing. We believe in that. So let's get there soon.

+ +

JOËL: And the core idea behind parse, don't validate is that instead of just having some data that you don't trust, running a check on it and passing that blob of now checked but still untrusted data down to the next person who might also want to check it. Generally, you want to pass it through some sort of filter that will, one, validate that it's correct but then actually typically convert it into some other trusted shape.

+ +

In Ruby, that might be something like taking an amorphous blob of JSON and turning it into some kind of value object or something like that. And then anybody downstream that receives, let's say, money object can trust that they're dealing with a well-formed money value as opposed to an arbitrary blob of JSON, which hopefully somebody else has validated, but who knows? So I'm going to validate it again.

+ +

CHRIS: You can tell that I've been out of the podcasting game for a while because I just started responding to yes; I love that blog post without describing the core premise of it. So kudos to you, Joël; you are a fantastic podcast host over there.

+ +

I will say one of the things you just described is an interesting...it's been a bit of a struggle for us. We keep sort of talking through what's the architecture. How do we want to build this application? What do we care about? What are the things that really matter within this codebase, and then what is all the other stuff? And we've been good at determining the things that really matter, thinking collectively as a group, and I think coming up with some novel, useful, elegant...I'm saying too many positive adjectives for what we're doing.

+ +

But I've been very happy with sort of the thing that we decide. And then there's the long-tail work of actually propagating that change throughout the rest of the application. We're, like, okay, here's how it works. Every incoming webhook, we now parse and yield a value object. That sentence that you just said a minute ago is exactly what I want. That's like a bunch of work. It's particularly a bunch of work to convert an existing codebase. It's easy to say, okay, from here forward, any new webhooks, payloads that are coming in, we're going to do in this way. But we have a lot of things in our app now that exist in this half-converted way.

+ +

There was a brief period where we had three different serializer technologies at play. Just this week, I did the work of killing off the middle ground one, the Primalized-based thing, and we now have only our new hotness and then the very old. We were using Blueprinter as the serializer as the initial sort of stub. And so that still exists within the codebase in some places. But trying to figure out how to prioritize that work, the finishing out those maintenance-type conversions is a tricky one. It's never the priority. But it is really nice to have consistency in a codebase. So it's...yeah, do you have any thoughts on that?
+JOËL: I think going back to the article and what the meaning of parsing is, I used to always think of parsing as taking strings and turning them into something else, and I think this really broadened my perspective on the idea of parsing. And now, I think of it more as converting from a broader type to a narrower type with failures.

+ +

So, for example, you could go from a string to an integer, and not all strings are valid integers. So you're narrowing the type. And if you have the string hello world, it will fail, and it will give you an error of some type. But you can have multiple layers of that. So maybe you have a string that you parse into an integer, but then, later on, you might want to parse that integer into something else that requires an integer in a range. Let's say it's a percentage. So you have a value object that is a percentage, but it's encoded in the JSON as a string.

+ +

So that first pass, you parse it from a string into an integer, and then you parse that integer into a percentage object. But if it's outside the range of valid percentage numbers, then maybe you get an error there as well. So it's a thing that can happen at multiple layers. And I've now really connected it with the primitive obsession smell in code. So oftentimes, when you decide, wait, I don't want a primitive here; I want a richer type, commonly, there's going to be a parsing step that should exist to go from that primitive into the richer type.

+ +

CHRIS: I like that. That was a classic Joël wildly concise summary of a deeply complex technical topic right there.

+ +

JOËL: It's like I'm going to connect some ideas from functional programming and a classic object-oriented code smell and, yeah, just kind of mash it all together with a popular article.

+ +

CHRIS: If only you had a diagram. Podcast is not the best medium for diagrams, but I think you could do it. You could speak one out loud, and everyone would be able to see it in their mind's eye.

+ +

JOËL: So I will tell you what my diagram is for this because I've actually created it already. I imagine this as a sort of like pyramid with different layers that keep getting smaller and smaller. So the size of type is sort of the width of a layer. And so your strings are a very wide layer. Then on top of that, you have a narrower layer that might be, you know, it could be an integer, or you could even if you're parsing JSON, you first start with a string, then you parse that into a Ruby hash, not all strings are valid hashes. So that's going to be narrower.

+ +

Then you might extract some values out of that hash. But if the keys aren't right, that might also fail. You're trying to pull the user out of it. And so each layer it gets a richer type, but that richer type, by virtue of being richer, is narrower. And as you're trying to move up that pyramid at every step, there is a possibility for a failure.

+ +

CHRIS: Have you written a blog post about this with said diagram in it? And is that why you have that so readily at hand? [laughs]

+ +

JOËL: Yes, that is the case.

+ +

CHRIS: Okay. Yeah, that made sense to me. [laughs]

+ +

JOËL: We'll make sure to link to it in the show notes.

+ +

CHRIS: Now you have to link to Joël blog posts, whereas I used to have to link to them [chuckles] in almost every episode of The Bike Shed that I recorded.

+ +

JOËL: Another thing I've been thinking about in terms of this parsing is that parsing and serializing are, in a sense, almost opposites of each other. Typically, when you're parsing, you're going from a broad type to a narrow one. And when you're serializing, you're going from a narrow type to a broader one. So you might go from a user into a hash into a string. So you're sort of going down that pyramid rather than going up.

+ +

CHRIS: It is an interesting observation and one that immediately my brain is like, okay, cool. So can we reuse our serializers but just run them in reverse or? And then I try and talk myself out of that because that's a classic don't repeat yourself sort of failure mode of, like, actually, it's fine. You can repeat a little bit. So long as you can repeat and constrain, that's a fine version. But yeah, feels true, though, at the core.

+ +

JOËL: I think, in some ways, if you want a single source of truth, what you want is a schema, and then you can derive serializers and parsers from that schema.

+ +

CHRIS: It's interesting because you used the word derive. That has been an interesting evolution at Sagewell. The engineering team seems to be very collected around the idea of explicitness, almost the Zen of Python; explicit is better than implicit. And we are willing to write a lot of words down a lot of times and be happy with that. I think we actually made the explicit choice at one point that we will not implement an automatic camel case conversion in our serializer, even though we could; this is a knowable piece of code.

+ +

But what we want is the grepability from the front end to the back end to say, like, where's this data coming from? And being able to say, like, it is this data, which is from this serializer, which comes from this object method, and being able to trace that very literally and very explicitly in the code, even though that is definitely the sort of thing that we could derive or automatically infer or have Ruby do that translation for us.

+ +

And our codebase is more verbose and a little noisier. But I think overall, I've been very happy with it, and I think the team has been very happy. But it is an interesting one because I've seen plenty of teams where it is the exact opposite. Any repeated characters must be destroyed. We must write code to write the code for us. And so it's fun to be working with a team where we seem to be aligned around an approach on that front.

+ +

JOËL: That example that you gave is really interesting because I feel like a common thing that happens in a serialization layer is also a form of normalization. And so, for example, you might downcase all strings as part of the serialization, definitely, like dates always get written in ISO 8601 format whenever that happens. And so, regardless of how you might have it stored on the Ruby side, by the time it gets to the JSON, it's always in a standard format. And it sounds like you're not necessarily doing that with capitalization.

+ +

CHRIS: I think the distinction would be the keys and the values, so we are definitely doing normalization on the values side. So ISO 8601 date and time strings, respectively that, is the direction that we plan to go for the value. But then for the key that's associated with that, what is the name for this data, those we're choosing to be explicit and somewhat repetitive, or not even necessarily repetitive, but the idea of, like, it's first_name on the Ruby side, and it's first capital N name camel case, or it's...I forget the name. It's not quite camel case; it's a different one but lower camel, maybe.

+ +

But whatever JavaScript uses, we try to bias towards that when we're going to the front end. It does get a little tricky coming back into the Ruby side. So our controllers have a bunch of places where they need to know about what I think is called lower camel case, and so we're not perfect there. But that critical distinction between sort of the names for things, and the values for things, transformations, and normalizations on the values, I'm good with that. But we've chosen to go with a much more explicit version for the names of things or the keys in JSON objects specifically.

+ +

JOËL: One thing that can be interesting if you have a normalization phase in your serializer is that that can mean that your serializer and parsers are not necessarily symmetric. So you might accept malformed data into your parser and parse it correctly. But then you can't guarantee that the data that gets serialized out is going to identically match the data that got parsed in.

+ +

CHRIS: Yeah, that is interesting. I'm not quite sure of the ramifications, although I feel like there are some. It almost feels like formatting Prettier and things like that where they need to hold on to whitespace in some cases and throw out in others. I'm thinking about how ASTs work. And, I don't know, there's interesting stuff, but, again, not sure of the ramifications.

+ +

But actually, to flip the tables just a little bit, and that's an aggressive terminology, but we're going to roll with it. To flip the script, let's go with that, Joël; what's been up in your world? You've been hosting this wonderful show. I've listened in to a number of episodes. You're doing a fantastic job. I want to hear a little bit more of what's new in your world, Joël.

+ +

JOËL: So I've been working on a project that has a lot of flaky tests, and we're trying to figure out the source of that flakiness. It's easy to just dive into, oh, I saw a flaky Test. Let me try to fix it. But we have so much flakiness that I want to go about it a little bit more systematically. And so my first step has actually been gathering data. So I've actually been able to make API requests to our CI server. And the way we figure out flakiness is looking at the commit hash that a particular test suite run has executed on.

+ +

And if there's more than one CI build for a given commit hash, we know that's probably some kind of flakiness. It could be a legitimate failure that somebody assumed was flakiness, and so they just re-run CI. But the symptom that we are trying to address is the fact that we have a very high level of people re-verifying their code. And so to do that or to figure out some stats, I made a request to the API grouped by commit hash and then was able to get the stats of how many re-verifications there are and even the distribution.

+ +

The classic way that you would do that is in Ruby; you would use the GroupBy function from enumerable. And then, you would transform values instead of having, like, say; each commit hash then points to all the builds, an array of builds that match that commit hash. You would then thumb those. So now you have commit hashes that point to counts of how many builds there were for that commit hash. Newer versions of Ruby introduced the tally method, which I love, which allows you to basically do all of that in one step.

+ +

One thing that I found really interesting, though, is that that will then give me a hash of commit hashes that point to the number of builds that are there. If I want to get the distribution for the whole project over the course of, say, the last week, and I want to say, "How many times do people run only one CI run versus running twice in the same commit versus running three times, or four times, or five or six times?" I want to see that distribution of how many times people are rerunning their build. You're effectively doing that tally process twice.

+ +

So once you have a list of all the builds, you group by hash. You count, and so you end up with that. You have the Ruby hash of commit SHAs pointing to number of times the build was run on that. And then, you again group by the number of builds for each commit SHA. And so now what you have is you'll have something like one, and then that points to an array of SHA one, SHA two, SHA three, SHA four like all the builds.

+ +

And then you tally that again, or you transform values, or however, you end up doing it. And what you end up with is saying for running only once, I now have 200 builds that ran only once. For running twice in the same commit SHA, there are 15. For running three times, there are two. For running four times, there is one. And now I've got my distribution broken down by how many times it was run. It took me a while to work through all of that. But now the shortcut in my head is going to be you double tally to get distribution.

+ +

CHRIS: As an aside, the whole everything you're talking about is interesting and getting to that distribution. I feel like I've tried to solve that problem on data recently and struggled with it. But particularly tally, I just want to spend a minute because tally is such a fantastic addition to the Ruby standard library. I used to have in sort of like loose muscle memory transform value is grouped by ampersand itself, transform values count, sort, reverse to H. That whole string of nonsense gets replaced by tally, and, oof, what a beautiful example of Ruby, and enumerable, and all of the wonder that you can encapsulate there.

+ +

JOËL: Enumerable is one of the best parts of Ruby. I love it so much. It was one of the first things that just blew my mind about Ruby when I started. I came from a PHP, C++ background and was used to writing for loops for everything and not the nice for each loops that a lot of languages have these days. You're writing like a legit for or while loop, and you're managing the indexes yourself. And there's so much room for things to go wrong.

+ +

And being introduced to each blew my mind. And I was like, this is so beautiful. I'm not dealing with indexes. I'm not dealing with the raw implementation of the array. I can just say do a thing for each element. This is amazing. And that is when I truly fell in love with Ruby.

+ +

CHRIS: I want to say I came from Python, most recently before Ruby. And Python has pretty nice list comprehensions and, in fact, in some ways, features that enumerable doesn't have. But, still, coming to Ruby, I was like, oh, this enumerable; this is cool. This is something. And it's only gotten better. It still keeps growing, and the idea of custom enumerables. And yeah, there's some real neat stuff in there.

+ +

JOËL: I'm going to be speaking at RubyConf Mini this fall in November, and my talk is all about Enumerators and ranges in enumerable and ways you can use those to make the APIs of the objects that you create delightful for other people to use.

+ +

CHRIS: That sounds like a classic Joël talk right there that I will be happy to listen to when it comes out. A very quick related, a semi-related aside, so, tally, beautiful addition to the Ruby language. On the Rails side, there was one that I used recently, which is where.missing. Have you seen where.missing?

+ +

JOËL: I have not heard of this.

+ +

CHRIS: So where.missing is fantastic. Let's assume you've got two related objects, so you've got like a has many blah, so like a user has many posts. I think you can...if I'm remembering it correctly, it's User.where.missing(:posts). So it's where dot missing and then parentheses the symbol posts. And under the hood, Rails will do the whole LEFT OUTER JOIN where the count is null, et cetera. It turns into this wildly complex SQL query or understandably complex, but there's a lot going on there. And yet it compresses down so elegantly into this nice, little ActiveRecord bit.

+ +

So where.missing is my new favorite addition into the Rails landscape to complement tally on the Ruby side, which I think tally is Ruby 2.7, I want to say. So it's been around for a while. And where.missing might be a Ruby 7 feature. It might be a six-something, but still, wonderful features, ever-evolving these tool sets that we use.

+ +

JOËL: One of the really nice things about enumerable and family is the fact that they build on a very small amount of primitives, and so as long as you basically understand blocks, you can use enumerable and anything in there. It's not special syntax that you have to memorize. It's just regular functions and blocks.

+ +

Well, Chris, thank you so much for coming back for a visit. It's been a pleasure. And it's always good to have you share the cool things that you're doing at Sagewell.

+ +

CHRIS: Well, thank you so much, Joël. It's been an absolute pleasure getting to come back to this whole Bike Shed. And, again, just to add a note here, you're doing a really fantastic job with the show. It's been interesting transitioning back into listener mode for the show. Weirdly, I wasn't listening when I was a host. But now I've regained the ability to listen to The Bike Shed and really enjoy the episodes that you've been doing and the wonderful spectrum of guests that you've had on and variety of topics. So, yeah, thank you for hosting this whole Bike Shed. It's been great.

+ +

JOËL: And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1nk3LZje + + ]]> + + Joël Quenneville + + + 358: Class Methods + https://bikeshed.thoughtbot.com/358 + 7bbe73cb-34b8-4f0b-8f41-180c5dae5546 + Tue, 18 Oct 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Inspired by a Slack thread, Joël invites fellow thoughtbotter Aji Slater on the show to talk about when you should use class methods and when you should avoid them. Are there particular anti-patterns to look out for? How does this fit in with good object-oriented programming? What about Rails? What is an "alternate constructor"? What about service objects? So many questions, and friends: Aji and Joël deliver answers! + 40:40 + no + + + Inspired by a Slack thread, Joël invites fellow thoughtbotter Aji Slater on the show to talk about when you should use class methods and when you should avoid them. Are there particular anti-patterns to look out for? How does this fit in with good object-oriented programming? What about Rails? What is an "alternate constructor"? What about service objects? So many questions, and friends: Aji and Joël deliver answers! +Backbone.js collections (https://backbonejs.org/#Model-Collections) +Query object (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) +Rails is a dialect (https://solnic.codes/2022/02/02/rails-and-its-ruby-dialect/) +Meditations on a Class Method (https://thoughtbot.com/blog/meditations-on-a-class-method) +Why Ruby Class Methods Resist Refactoring (https://codeclimate.com/blog/why-ruby-class-methods-resist-refactoring/) +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. And today, I'm joined by fellow thoughtboter Aji Slater. +AJI: Howdy. +JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Aji, what's new in your world? +AJI: Yeah, well, I just joined a new project, so that's kind of the newest thing in my day-to-day work world. I say just joined, but I guess it was about a month ago now. I'm on the Liftoff team at thoughtbot, which is different than the team that you're on. We do more closer to greenfield ideas and things like that. So there's actually not much to speak about there in that project just yet. Rails new is still just over the horizon for us. +So I've been putting a lot of unused brain cycles toward a side project that is sort of a personal knowledge base concept, and that's a whole thing that I could probably host an entire podcast about. So we don't have to go too deep into my theories about that. But suffice it to say I've talked to some other ADHDers like myself who find that that space is not really conducive to the way that we think and have to organize ourselves and our personal knowledge stores. So sort of writing an app that can lend itself to our fast brains a little bit better. +JOËL: Nice. I just recently recorded an episode of this podcast talking a little bit about note-taking approaches and knowledge-base systems. So, yeah, it's a topic that's very much top of mind for me right now. +AJI: Yeah, what else is going on in your world? +JOËL: I'm based in New England in the U.S. East Coast, and it is fall here. I feel like it happened kind of all of a sudden. And the traditional fall thing to do here is to go to an orchard and pick apples. It's a fun activity to do, and so I'm in the middle of planning that. Yeah, it's fun to go out into nature, very artificial space. +AJI: [laughs] +JOËL: But it's a fun thing to do every fall. +AJI: Yeah, we do that here too. There's an orchard up north of us where my wife and I live in Chicago that we try to visit. And Apple Fest in Lincoln Square is this weekend, and we've been really looking forward to that. Try another time at making homemade hard cider this season, I think, and see how that goes. +JOËL: Fun. When you say another time, does that mean there was a previous unsuccessful attempt? +AJI: Yes. Did the sort of naive approach to it, and there is apparently a lot more subtlety to cidermaking than there is home-brew beer. And we got some real strong funk in that cider that did not make it necessarily an enjoyable experience. Like, it worked but wasn't the tastiest. +JOËL: So it got alcoholic. It was just terrible to drink. +AJI: Yeah, I would back that up. +JOËL: So recently, at thoughtbot, we had a conversation among different team members about the use of Ruby class methods, when they make sense, when they are to be avoided. What is their use case? And different people had different opinions. So I'm curious what your take on class methods are. When do you like to use them? +AJI: Yeah, I remember those conversations coming up. I think I might have even started one of those threads because this is something that comes up to me a lot. I'm a long-time listener, first-time caller to The Bike Shed. [laughs] I can remember awaiting new episodes from Sage and Derek to listen to on my way to and from my first dev job. And at one point, Sage had said, "Never put your business logic in something that you can't call .new on." +And being a young, impressionable developer at the time, I took that to heart, and that seems something that just has been baked in and stayed very truthful to me. And I think one of the times that I asked that and got some conversation started was I was trying to figure out why did I feel that, and like, why did they say that? And I think, yeah, I try to avoid them. I like making instances of things. What is your stance on the Class Method, capital C, capital M? +JOËL: I also generally avoid them. I have sort of two main scenarios that I like to use class methods, first is as an alternate constructor. So new is effectively a class method that's built into Ruby's object model. But sometimes, you want variations on your constructor that maybe sets values by default or that construct things with some slightly different inputs, things like that. And so those almost always make sense as class methods. The other thing that I sometimes use a class method for is as an alias for newing up an instance and then immediately calling an instance method on it. So it's just a slightly shorthand way to call some code. +AJI: That's usually been my first line defense of when there's someone who might feel more comfortable doing class methods that sees me making an instance and says, "Well, you don't need an instance, just make a class method here because it'll get too long if you have to .new and then dot this other thing." And so I'll throw in that magic little trick and be like, here you go. You can call it a class method, and you still get all the benefits of your instance. I love that one. +JOËL: Do you feel like that maybe defeats the purpose? In terms of the interface that people are using, if you're calling it a class method, do you lose the benefits of trying to do things at the instance level instead? Or is it more in the implementation that the benefits are not at the caller level? +AJI: I think that's more true that the benefits are at the instance level, and you're getting all of that that goes along with it. And you're not carrying along a lot of what I see as baggage of the class method version, but you're picking up a little bit of that syntactic sugar. And sometimes it's even easier just to conceptualize, especially in the Rails space because we have all of these different class methods like, you know, Find is one I'm sure that we use all the time to call it on a class, and we get back an instance. And so that feels very natural in the Rails world. +JOËL: I think you could make an argument that that is a form of alternate constructor. It's a class method you call to get an instance back. +AJI: Yeah, absolutely. +JOËL: The fact that it makes a background request to the database is an implementation detail. +AJI: For sure. I agree with that. I had a similar need in a recent project where the data was kept on a third-party API. So I treated it the same way as, instead of going out to the database like ActiveRecord does, made a class method that went off to the API and then came back and made the object that was the representation of that idea in our application. So, yeah, I wholeheartedly agree with that. +JOËL: So in Rails, we have the scope keyword, which will run some query to get a collection of records. But another way that they're often implemented is as class methods, and they're more or less interchangeable. How do you feel about that kind of use of class methods on an ActiveRecord object? Does that violate some of the ideas that we've been talking about? Does it sort of fit in? +AJI: I think when reaching for that sort of need, I sort of fall into the camp of making a class method rather than using a scope. It feels a little less like extending some basic Rails functionality or implying that it's part of the inherent framework and makes it a little more like behavior that's been added that's specific to this domain. And I think that distinction comes into my thinking there. I'm sure there are other reasons. What are your thoughts there? Maybe it'll spark an idea for me. +JOËL: For me, I think I also generally prefer to write them as class methods rather than using the scope keyword, even though they're more or less the same thing. What is interesting is that, in a way, they kind of feel like alternate constructors in that they don't give you an instance; they give you back a collection of instances back. So if we bend the rules a little bit...these are not hard and fast rules but the guidelines. If we bend the guidelines a little bit, they kind of fit under the general categories for best uses of class method that we discussed earlier. +AJI: Yeah, I can definitely see that. I tend to think, or at least I think when you had first brought up the term of alternate constructors, my first thought was of one instance; you ask for a thing, and it gives you this thing back. But it's the same sort of idea with that collection because you're not getting just one instance; you're getting many instances. But it's the same kind of idea. You've asked the larger concept of the thing, the class, to give you back individuals of that class. So that totally falls in line with how I think about acceptable uses of these class methods the way that we've been talking about them. +JOËL: Rails is something really interesting where a lot of the logic that pertains to a single item will live at the instance level. And then logic that pertains to a group of items will live at the class level. So you almost have like two categories of operations that you can run that semantically live either at the class or the instance level. Have you ever noticed that separation before? +AJI: I think that separation feels natural to me because I came into programming through Rails. And I might have been colored in my thinking about this by the framework. The way that I conceptualize what a class is being sort of this blueprint or platonic ideal of what an individual might be and sort of describing the potential behaviors of such an individual. Having that kind of larger concept be able to work across multiple instances feels, yeah, it feels sort of natural. +Like, if you were to think about this idea of a chair, then if you went in and modified what a chair is to mean, then any chair that you asked for later on would kind of come with that behavior along with it. Or if you ask for several chairs, they would all sort of have that idea. +JOËL: I think similar to you; I had that outlook on that's almost like a natural structuring of things. And then, years ago, I got into the hot, new JavaScript framework that was Backbone.js. And it actually separates...it has like a model for individual instances, and then a separate kind of model thing for collections. And that kind of blew my mind. +But what was interesting, then, is that you effectively have instance methods that can deal with all things collection-related, any sort of filtering, any sort of transformations. All of those are done, which you have an instance of a collection, basically, that you act on. And I guess if we were trying to translate that into Rails, that's almost like the concept of a query object. +AJI: Hmm, it's sort of an interesting way to think about that. And Backbone, I feel like I did a day of that in bootcamp. But it has been some time, so I'm not sure that I've worked with that pattern specifically. But it does sort of bring up the idea of how much do you want to be in one model class? And do you want it to contain both of these concepts? +If you have a lot of complex logic that is going to be dealing with a collection, rather than putting that in your model, I think I would probably reach for something like a service object that is going to be specifically doing that and sort of more along that Backboney approach maybe like a query object or something like that. +JOËL: Interesting. When you use the term service object, do you mean something that's not a Rails model, just in general? Or are you talking specifically about one of these objects that can respond to call and is... I've heard them sometimes called Command objects or method objects. +AJI: Yeah, that's an overloaded term certainly in the real space, isn't it? Service object, and what does that mean? I think generally, when I say it, I'm meaning just a plain, old Ruby object like something that is doing its one thing. You're going to use it to do its implementation details. They're all kind of hidden behind in private methods and return you something useful that you can then plug into what you were doing or what you need going on in some other place in your app. +So it, to me, doesn't imply any specific implementation of, like, do you have call? Do you use it this way? Do you use it that way? But it's something that's kind of outside of it is either a model, a view, a controller, and it encapsulates some kind of behavior. So whether that, like we're saying, is a filtering or, you know, it's going to wrap that up. +JOËL: I see. So, for you, a query object would be a service object. +AJI: Yeah, I think so. You know, maybe this is one of the reasons why I generally don't like the overuse of the term service object in our space. I don't know if that's a hot take, and I'm going to get emails for this. But -- +JOËL: Everybody send your angry tweets @Aji. +AJI: Yeah, do it to @Aji on Twitter because I've been trying to get that three-letter handle for years. No, but if you want to talk to me, I'm @DoodlingDev. But, yeah, certainly, it does feel sometimes like an overloaded term, and I just want to go back to talking about plain, old Ruby objects. +JOËL: So, service object is definitely an overloaded term. It's used for a lot of things. One thing that I've often seen it referring to are objects that respond to call. And just to keep away the confusion, maybe let's call them Command objects for the purposes of this conversation. +AJI: Sounds good. +JOËL: I commonly see them done where the implementation is done with a class method named call. Sometimes it delegates to an instance that also has call. Sometimes it's all implemented as a class method. How do you feel about that pattern? +AJI: I don't mind the idea of a thing that responds to call. It, in a way, sort of implies that the class is sort of named as an action, which I don't like. It has an er name, and that kind of has a class named as a pattern. And that always sort of bugs me a little bit. But what I hope for when I open up one of those sorts of classes or objects is that it's going to delegate to an instance because then you're, again, picking up all of those wonderful benefits of the instance-level programming. +JOËL: You keep mentioning the wonderful benefits of instance-level programming. What are some of those benefits? +AJI: One of the ones that sort of strikes me most visibly or kind of viscerally when I see it is that they're very easy to understand. You can extract methods pretty easily that don't turn into kind of clumsy code of a bunch of different class methods that all have four arguments passed in because they're all operating on the same context. And when you're all operating on the same context, you have really a shared state. +And if you're just passing that shared state around, it just gets super confusing. And you get into the order of your arguments, making a big impact on how you are interacting with these different things. And so I think that's sort of the first thing that comes to mind is just visually noisy, which for me is super hard to get my head around, like, well, how am I supposed to use this thing? Can I extend it? +JOËL: Yeah, I would definitely say that if you have a group of class methods that all take, commonly, it's the first argument, the same piece of data and tries to operate on it, that's probably a code smell that points to the fact that these things want to be an instance that lives around it. This could be a form of primitive obsession if you're passing around, let's say, a hash, all of these, and maybe what you really want is to sort of reify that hash into an object. And then all these class methods that used to operate on the hash can now become instance methods on your richer domain object. +AJI: Yeah. What do you say to the folks that come from maybe a more functional mindset or are kind of picking up on the wave of functional programming that's out there in the ethos that say that you've got a bunch of side effects when you don't have everything that your method is operating on, being passed on or passed in? +JOËL: I think side effect is a broad term. You could refer to it as modifying the internal state of an object. Technically, mutation is a side effect. And then you have things like doing effects out in the outside world, like making an HTTP query, printing to the screen, things like that. I think those are probably two separate concepts. Functional programming is great. I love writing functional code. +When you're writing Ruby, Ruby is primarily an object-oriented language with some functional aspects brought in. In my opinion, it's very, you know, a great combination of the two. I think they've gotten the balance well so that the two paradigms play nicely together rather than competing. But I think it's an object-oriented language first with some functional added in. And so you're not going to be, I mean, I guess you could; there is a way to write Ruby where everything is a lambda or where everything is a class method that is pure and takes in inputs. But that's not the idiomatic way to write Ruby. Generally, you're creating objects that have some state. +That being said, if an object is mutating a lot of global state, that's going to become problematic. With regards to its internal state, though, because it is very much localized and it's private, nobody else gets to see it; in many ways, an object can mutate itself, and that chain stays pretty local. +AJI: Yeah, absolutely. You've tripped onto another one of my favorite rabbit holes of idiomatic code, and, like, what does that mean, and why should we strive for that? But I absolutely agree that when Ruby is written to conform to other paradigms that aren't mostly object-oriented is when it starts to get hard to use. It starts to feel a little off. Maybe it has code smells around it. It's going to give me the heebie-jeebies, whatever that might mean for you or for different developers. +I think we all have our things that are sort of this doesn't feel right. And you kind of dig into it, and you can sort of back that up. And whenever Ruby starts to look like something that isn't lots of little objects sending messages, is when I start to get a little on edge, maybe. +JOËL: It is worth, I think, calling out the fact that Ruby is a very expressive language. And there are effectively many...you could call them dialects of it. You have sort of your pure sort of OO approach. You have what's typically written in Rails, which has some OO things. But Rails is also, in many ways, it's very DSL-heavy and, in some ways, very class method-heavy. So writing Rails is sort of its own twist on Ruby. +And then, some people will try to completely retrofit a functional approach onto Ruby, and that's also a way that some people like to write their code. And some of these, you can't necessarily say they're not valid, but they're not what you'll mostly see in the wild. And they're not necessarily the approach that I would recommend. +AJI: Yeah, that's the blessing, and the curse of both programming in general and such an expressive language like Ruby is that there are many different valid ways to do it. And what are your trade-offs going to be when you make those choices? I think that falls kind of smack dab into that idiomatic conversation. +And it comes up for me, too, as a consultant because I try to tend towards that idiomatic, those common patterns and practices because I'm not going to live with this code forever. I need to hand this off. And the closer it is to what you might see out there in the wild more commonly, the easier it will be for the next Ruby developer to come pick it up and extend it. +JOËL: So you'd mentioned earlier some of the benefits of instance programming. One of the things that I find is maybe a little bit weird when you go heavily into the class method approach is that there is only one instance of the class, and it is globally available. +AJI: Are you talking about a singleton there? +JOËL: Yes. And, in fact, your class is effectively a singleton, potentially with globally mutable state. I hope not, but potentially with all of the gotchas and warnings that that entails. And so, if you think of your user instance, you need a reference to it, and there can be multiple of them, and you can call methods on them. If everything is happening at the class level, there is a single user class in memory shared by anyone who wants to use it. It's globally accessible. You can all call methods on it. Yeah, in many ways, it does act like a singleton. +AJI: And let's not even get into the Ruby chestnut of everything's an object. So it is an instance of a class in and of itself. +JOËL: Yes. +AJI: But, absolutely, it can start to act that way. But the singleton it's enshrined in the Gang of Four book of patterns. Like, so what's wrong about a singleton? I hope you can understand over the airwaves the devil's advocate that I'm playing here. [laughs] +JOËL: Yes. There are little horns that have sprouted on your head right now. I think part of the problem with singletons is that, generally, they are globally accessible. There's the problem of global mutable state again. There was a time, I think, when the OO community went pretty wild with singletons, and people realized that this was not great. And so, over time, a consensus evolved that singletons are a pattern that, while useful, should be used rarely and in moderation. +And a lot of warnings have been shared in the community, like, be careful not to overuse the singleton pattern or don't build your system out of singletons. And maybe that's what feels so weird about a system that's built primarily in terms of class methods for me is that it feels like it's built out of singletons. +AJI: Yeah. When I think of object-oriented programming, I kind of fall back to maybe one of the ideals of it is that it represents the world more accurately or maybe more understandably. And that sort of idea doesn't fit that paradigm, does it? If you're a factory that is making widgets, there's not the one canonical widget that all of your customers are going to be talking to and using. They are going to each have their own individual widgets. And those customers can be thought of like the consumers of your methods, your objects. +JOËL: The idea being the real-world thing you're simulating normally, there are multiple actors of every type rather than a single sort of generic one that stands in for everybody. +AJI: If this singleton is going to be your interface or the way that you interact with each of these things that are conceptually different, like a user or something like that, then differentiating between which user becomes a lot harder to do. It takes a lot more setup and involved process in referring to this user when and that kind of thing and creating the little instances. Then you've got more kind of direct reference to a single concept, a single individual. +JOËL: So what you've described is a very sort of classic OO mindset. You find the data and the behaviors that go together. You try to oftentimes simulate the world, model it in terms of actors that give and receive messages. In many ways, though, I think when you're building a system out of class methods, you're thinking about the world in an almost different paradigm. In many ways, it feels almost procedural. What are the behaviors that need to happen in my app? What are the things that need to be done? +You'd mentioned earlier that oftentimes these classes or the methods on them will end up with E-R; they're all verbs. You have a thing-doer, a thing executor, thing manager. They all do things rather than having domain concepts extracted and pulled out. Would you say that that feels somewhat procedural to you as well? +AJI: Yeah. I think a great way to divide it is the way that you have right there; it's these sorts of mindsets. Do you have collections of things that have behaviors, or do you have collections of behaviors that might refer to things? And where you're approaching the design of a system, either from that behavior side or from that object side, is going to be a different mindset. Procedural being more focused on that kind of behavior and telling it what to do rather than putting... I think this is probably a butchered Sandi Metz example, but putting your roommate who hates cats and a cat that doesn't want its tail stepped on in one room, and eventually, things will happen accordingly. +And those two mindsets are going to end up with very different architectures, very different designs, very different ways of building these applications that we make. And, again, does that come back to...Ruby, potentially to a lesser extent but still in the same camp, is object-oriented language, and it sort of functions best when considered and then constructed in that mindset. +And I often wonder sometimes if language developers and language designers make anti-patterns sort of purposefully awkward to use. Like, if you want to hide a lot of class methods, you can do the class shovels self version of things or have privateclassmethod littered all the way through your file. And it seems to me like that might be a little bit of a flag that, like, hey, you're working against the system here. You're trying to make it do a thing that it doesn't naturally want to do. +JOËL: Yeah, because you'd mentioned this private_class method thing because, by default, it's hard to get class methods to be private. You have to use a special keyword. You can't just write private in the class and then assume that the methods below it are going to be private because that does not apply to class methods. +AJI: Exactly. And that friction to making an object that has a smaller interface, that kind of hides its implementation, seems as though it's a purposeful way that Ruby itself was designed to maybe nudge us, developers, into a certain way of working or suggesting a certain mindset. +JOËL: There's a classic Code Climate article titled Class Methods Resist Refactoring. And it mentions different ways that when you're relying heavily on class methods, it's harder to do some of the traditional refactors things like just extract method because it is clunkier because you can't have private methods as easily. You can't share state, so you have to thread variables through. I guess, technically, you can share state with things like class variables and class instance variables, but if you do that, you will probably be very sad. +AJI: [laughs] Yeah, you're opening yourself up to a whole world of hurt there, aren't you? And, yeah, you're opening yourself up to a whole world of hurt there with that, aren't you? Sort of sharing data so dangerously around your app. +JOËL: So I'm a big fan of test-driven development. And one of the things that TDD believes in is that test pain should help guide the design of your system and that, generally, things that are easier to test are better designed. +AJI: Yeah. +JOËL: It's often easier to test class methods because they are globally available singletons. I can easily stub a class. Whereas if I need to stub an instance, I need to do some uglier things like stub any instance of or stub the constructor to return a double, or do some other kind of dirty tricks like that. Does that mean that TDD would prefer a class method-based approach to writing code? +AJI: I think that a surface-level reading of that might say that it does. And I think that maybe the first pass on things, if you're thinking about I want to get this thing done that's right in front of me right now and just move forward, might kind of imply that. But if you start to think about or have come back to something that was implemented in that way, anytime that sort of behavior is going to grow or change, then it's going to start to...the number of backflips that you have to do become a lot more complicated and a lot higher when you've got class methods. +Because I find that, yes, you might have to stub out or pass in a created object or something like that. But if you've got a class method, especially if it is calling other class methods inside it, then all of a sudden, you have in your test this setup that looks completely unrelated to anything that you're running and testing, that you have to have all of this insight or knowledge of what those classes are doing just to set up your test framework before you can even run that. +Another thing that is looked to as an axiom when writing tests that can imply this class approach is that you shouldn't change your code just for the test. If you're doing dependency injection or something like that, passing around little objects, then you're making your code more complicated to make your tests look a certain way. +JOËL: That's interesting. So maybe I'm reacting to some test pain by trying to change my tests first. So I'm trying to deal with some collaborators, and it is tricky to do. And so I decide, well, the thing I want to do is I want to reach for stubbing. But then that's hard to do because it's instances. So in order to make already that compromise in my test work better, now I change the code to be nicer for the test to use mostly classes because those are global. +Whereas maybe the correct path to take initially is, say, oh, there isn't test pain here because I'm trying to isolate an object from its collaborators. Maybe we need to pass an object in as an argument rather than hard coding it inside the class. +AJI: Yeah, absolutely. +JOËL: So I guess you follow the test pain, but maybe the problem is that you've already kind of gone down a path that might not be the best before you got to the point where you decided that you needed a class method. +AJI: And I think that idea of following the test pain can be, again, there are only shades of gray; there is no black and white. It can be sort of taken in a lot of different ways. And the way that I think about it is that test pain is also sort of an early warning sign that there's going to be pain if you want to reuse this class or these behaviors somewhere else. And if it was useful somewhere, it's likely it's going to be useful in another place. +And there are many different kinds of tests pain. The testing is a little easier with a class method because you're not stubbing out any instance of. You're just stubbing; really, what's the difference between stubbing out any instance of or stubbing out the class? Is that just a semantic difference? Is that -- +JOËL: Because someone on the internet said that stubbing any instance of is bad. +AJI: Ooh, right, the internet. I should have read that one. The thing that you can do with passing around instances or sending messages to instances as you do when you're calling a method is that you can easily swap in a different object if you need to stub it. It's similar to how you can change the implementation under the hood of an object and pass in an object that responds to the same messages and kind of keep moving forward with your duck typing. +If you can go into your tests and pass it sort of an object that's always going to return a thing...because we're not testing what that does; we just need a certain response so that we can move forward with the pathway that is under test. You can do that in so many different ways. You could have FactoryBot, for instance, give you a certain shape of a thing. You can create a tiny, little class right there in your tests that does something specific, that can be easily understood what's going on under the hood here. +And instead of having to potentially stub out or create all of these pathways that need to be followed that are overwriting logic that's happening in different class methods or different places otherwhere in the application, you can just pass in this one simplified thing to keep your tests sort of smaller and easier to wrap your head around all in just one go. +JOËL: I think what I'm getting here is that when you design your code around instances, you're more likely to build it in a modular way where you pass objects to other objects. And when you build your code using class methods, you're more likely to write it in a hard-coded way. Because you have that globally available class, you just hard-code it and then call it directly rather than passing things in. And so things end up more coupled and, therefore, high coupling leads to more test pain. +AJI: Yeah, I think you've really kind of hit on something here that the approach of using class methods is locking that class into kind of a single context or use case. Usually, it is this global thing that is this one way, and that's even kind of backed up by the fact that class methods are load-time logic instead of run-time logic. And it really kind of not only couples but it makes it more brittle and less amenable to kind of reuse. +JOËL: That's a really interesting distinction. I often tend to think of runtime versus load time in terms of composition versus inheritance. Composition, you can combine objects together at runtime and get behaviors built on the fly as the code is executing, whereas inheritance sort of inherently freezes you into a particular combination of behaviors at the time of loading the code. It's something that the programmers set up, and so it is much less flexible. +And that is one of the arguments why the Gang of Four patterns book recommends composition over inheritance in many situations is because of that runtime versus load time dichotomy. And I hadn't made that connection for class methods versus instance methods, but I think there's a parallel there. +AJI: Yeah, absolutely. The composition versus inheritance thing, I think, goes very hand in hand with the conversation that we're having about putting your behavior on a class versus an instance because...and I don't know if this is again yielding my thoughts to 'the internet said' in that composition is preferable to inheritance. But without unpacking that right there, that is certainly something that I strive for as well. And while it might have, much like TDD, some kind of superficial, short-term complexity, it has long-term payoff in that flexibility and that reuse, and that extensibility, and all of those other buzzwords that we developers like to throw around. +JOËL: So you've shared a lot of thoughts on the use of class methods. I think this could branch into so many other aspects of object-oriented design that we haven't looked at or that we could go deeper, things like TDD. We could look into how it works with the solid principles, all sorts of things. But I think the big takeaway for me is that class methods are very useful, but it's easy to use them as our single hammer to every problem being a nail. +And it's good to diversify your toolset. And some tools are specialized; they're good to be used in very specific situations that don't come across very often, and others are used every day. And maybe class methods are the former. +AJI: Absolutely. That hammer-and-nail metaphor was right where I was headed for too. Love it. +JOËL: Well, thank you so much, Aji, for joining the conversation today. Where can people find you online? +AJI: Yeah, anywhere you want to look for me: Instagram, GitHub, Twitter. I'm @DoodlingDev, so just send all your angry emails that way. +JOËL: And with that, let's wrap up. +The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Inspired by a Slack thread, Joël invites fellow thoughtbotter Aji Slater on the show to talk about when you should use class methods and when you should avoid them. Are there particular anti-patterns to look out for? How does this fit in with good object-oriented programming? What about Rails? What is an "alternate constructor"? What about service objects? So many questions, and friends: Aji and Joël deliver answers!

+ +
+ +

Backbone.js collections
+Query object
+Rails is a dialect
+Meditations on a Class Method
+Why Ruby Class Methods Resist Refactoring

+ +

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. And today, I'm joined by fellow thoughtboter Aji Slater.

+ +

AJI: Howdy.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Aji, what's new in your world?

+ +

AJI: Yeah, well, I just joined a new project, so that's kind of the newest thing in my day-to-day work world. I say just joined, but I guess it was about a month ago now. I'm on the Liftoff team at thoughtbot, which is different than the team that you're on. We do more closer to greenfield ideas and things like that. So there's actually not much to speak about there in that project just yet. Rails new is still just over the horizon for us.

+ +

So I've been putting a lot of unused brain cycles toward a side project that is sort of a personal knowledge base concept, and that's a whole thing that I could probably host an entire podcast about. So we don't have to go too deep into my theories about that. But suffice it to say I've talked to some other ADHDers like myself who find that that space is not really conducive to the way that we think and have to organize ourselves and our personal knowledge stores. So sort of writing an app that can lend itself to our fast brains a little bit better.

+ +

JOËL: Nice. I just recently recorded an episode of this podcast talking a little bit about note-taking approaches and knowledge-base systems. So, yeah, it's a topic that's very much top of mind for me right now.

+ +

AJI: Yeah, what else is going on in your world?

+ +

JOËL: I'm based in New England in the U.S. East Coast, and it is fall here. I feel like it happened kind of all of a sudden. And the traditional fall thing to do here is to go to an orchard and pick apples. It's a fun activity to do, and so I'm in the middle of planning that. Yeah, it's fun to go out into nature, very artificial space.

+ +

AJI: [laughs]

+ +

JOËL: But it's a fun thing to do every fall.

+ +

AJI: Yeah, we do that here too. There's an orchard up north of us where my wife and I live in Chicago that we try to visit. And Apple Fest in Lincoln Square is this weekend, and we've been really looking forward to that. Try another time at making homemade hard cider this season, I think, and see how that goes.

+ +

JOËL: Fun. When you say another time, does that mean there was a previous unsuccessful attempt?

+ +

AJI: Yes. Did the sort of naive approach to it, and there is apparently a lot more subtlety to cidermaking than there is home-brew beer. And we got some real strong funk in that cider that did not make it necessarily an enjoyable experience. Like, it worked but wasn't the tastiest.

+ +

JOËL: So it got alcoholic. It was just terrible to drink.

+ +

AJI: Yeah, I would back that up.

+ +

JOËL: So recently, at thoughtbot, we had a conversation among different team members about the use of Ruby class methods, when they make sense, when they are to be avoided. What is their use case? And different people had different opinions. So I'm curious what your take on class methods are. When do you like to use them?

+ +

AJI: Yeah, I remember those conversations coming up. I think I might have even started one of those threads because this is something that comes up to me a lot. I'm a long-time listener, first-time caller to The Bike Shed. [laughs] I can remember awaiting new episodes from Sage and Derek to listen to on my way to and from my first dev job. And at one point, Sage had said, "Never put your business logic in something that you can't call .new on."

+ +

And being a young, impressionable developer at the time, I took that to heart, and that seems something that just has been baked in and stayed very truthful to me. And I think one of the times that I asked that and got some conversation started was I was trying to figure out why did I feel that, and like, why did they say that? And I think, yeah, I try to avoid them. I like making instances of things. What is your stance on the Class Method, capital C, capital M?

+ +

JOËL: I also generally avoid them. I have sort of two main scenarios that I like to use class methods, first is as an alternate constructor. So new is effectively a class method that's built into Ruby's object model. But sometimes, you want variations on your constructor that maybe sets values by default or that construct things with some slightly different inputs, things like that. And so those almost always make sense as class methods. The other thing that I sometimes use a class method for is as an alias for newing up an instance and then immediately calling an instance method on it. So it's just a slightly shorthand way to call some code.

+ +

AJI: That's usually been my first line defense of when there's someone who might feel more comfortable doing class methods that sees me making an instance and says, "Well, you don't need an instance, just make a class method here because it'll get too long if you have to .new and then dot this other thing." And so I'll throw in that magic little trick and be like, here you go. You can call it a class method, and you still get all the benefits of your instance. I love that one.

+ +

JOËL: Do you feel like that maybe defeats the purpose? In terms of the interface that people are using, if you're calling it a class method, do you lose the benefits of trying to do things at the instance level instead? Or is it more in the implementation that the benefits are not at the caller level?

+ +

AJI: I think that's more true that the benefits are at the instance level, and you're getting all of that that goes along with it. And you're not carrying along a lot of what I see as baggage of the class method version, but you're picking up a little bit of that syntactic sugar. And sometimes it's even easier just to conceptualize, especially in the Rails space because we have all of these different class methods like, you know, Find is one I'm sure that we use all the time to call it on a class, and we get back an instance. And so that feels very natural in the Rails world.

+ +

JOËL: I think you could make an argument that that is a form of alternate constructor. It's a class method you call to get an instance back.

+ +

AJI: Yeah, absolutely.

+ +

JOËL: The fact that it makes a background request to the database is an implementation detail.

+ +

AJI: For sure. I agree with that. I had a similar need in a recent project where the data was kept on a third-party API. So I treated it the same way as, instead of going out to the database like ActiveRecord does, made a class method that went off to the API and then came back and made the object that was the representation of that idea in our application. So, yeah, I wholeheartedly agree with that.

+ +

JOËL: So in Rails, we have the scope keyword, which will run some query to get a collection of records. But another way that they're often implemented is as class methods, and they're more or less interchangeable. How do you feel about that kind of use of class methods on an ActiveRecord object? Does that violate some of the ideas that we've been talking about? Does it sort of fit in?

+ +

AJI: I think when reaching for that sort of need, I sort of fall into the camp of making a class method rather than using a scope. It feels a little less like extending some basic Rails functionality or implying that it's part of the inherent framework and makes it a little more like behavior that's been added that's specific to this domain. And I think that distinction comes into my thinking there. I'm sure there are other reasons. What are your thoughts there? Maybe it'll spark an idea for me.

+ +

JOËL: For me, I think I also generally prefer to write them as class methods rather than using the scope keyword, even though they're more or less the same thing. What is interesting is that, in a way, they kind of feel like alternate constructors in that they don't give you an instance; they give you back a collection of instances back. So if we bend the rules a little bit...these are not hard and fast rules but the guidelines. If we bend the guidelines a little bit, they kind of fit under the general categories for best uses of class method that we discussed earlier.

+ +

AJI: Yeah, I can definitely see that. I tend to think, or at least I think when you had first brought up the term of alternate constructors, my first thought was of one instance; you ask for a thing, and it gives you this thing back. But it's the same sort of idea with that collection because you're not getting just one instance; you're getting many instances. But it's the same kind of idea. You've asked the larger concept of the thing, the class, to give you back individuals of that class. So that totally falls in line with how I think about acceptable uses of these class methods the way that we've been talking about them.

+ +

JOËL: Rails is something really interesting where a lot of the logic that pertains to a single item will live at the instance level. And then logic that pertains to a group of items will live at the class level. So you almost have like two categories of operations that you can run that semantically live either at the class or the instance level. Have you ever noticed that separation before?

+ +

AJI: I think that separation feels natural to me because I came into programming through Rails. And I might have been colored in my thinking about this by the framework. The way that I conceptualize what a class is being sort of this blueprint or platonic ideal of what an individual might be and sort of describing the potential behaviors of such an individual. Having that kind of larger concept be able to work across multiple instances feels, yeah, it feels sort of natural.

+ +

Like, if you were to think about this idea of a chair, then if you went in and modified what a chair is to mean, then any chair that you asked for later on would kind of come with that behavior along with it. Or if you ask for several chairs, they would all sort of have that idea.

+ +

JOËL: I think similar to you; I had that outlook on that's almost like a natural structuring of things. And then, years ago, I got into the hot, new JavaScript framework that was Backbone.js. And it actually separates...it has like a model for individual instances, and then a separate kind of model thing for collections. And that kind of blew my mind.

+ +

But what was interesting, then, is that you effectively have instance methods that can deal with all things collection-related, any sort of filtering, any sort of transformations. All of those are done, which you have an instance of a collection, basically, that you act on. And I guess if we were trying to translate that into Rails, that's almost like the concept of a query object.

+ +

AJI: Hmm, it's sort of an interesting way to think about that. And Backbone, I feel like I did a day of that in bootcamp. But it has been some time, so I'm not sure that I've worked with that pattern specifically. But it does sort of bring up the idea of how much do you want to be in one model class? And do you want it to contain both of these concepts?

+ +

If you have a lot of complex logic that is going to be dealing with a collection, rather than putting that in your model, I think I would probably reach for something like a service object that is going to be specifically doing that and sort of more along that Backboney approach maybe like a query object or something like that.

+ +

JOËL: Interesting. When you use the term service object, do you mean something that's not a Rails model, just in general? Or are you talking specifically about one of these objects that can respond to call and is... I've heard them sometimes called Command objects or method objects.

+ +

AJI: Yeah, that's an overloaded term certainly in the real space, isn't it? Service object, and what does that mean? I think generally, when I say it, I'm meaning just a plain, old Ruby object like something that is doing its one thing. You're going to use it to do its implementation details. They're all kind of hidden behind in private methods and return you something useful that you can then plug into what you were doing or what you need going on in some other place in your app.

+ +

So it, to me, doesn't imply any specific implementation of, like, do you have call? Do you use it this way? Do you use it that way? But it's something that's kind of outside of it is either a model, a view, a controller, and it encapsulates some kind of behavior. So whether that, like we're saying, is a filtering or, you know, it's going to wrap that up.

+ +

JOËL: I see. So, for you, a query object would be a service object.

+ +

AJI: Yeah, I think so. You know, maybe this is one of the reasons why I generally don't like the overuse of the term service object in our space. I don't know if that's a hot take, and I'm going to get emails for this. But --

+ +

JOËL: Everybody send your angry tweets @Aji.

+ +

AJI: Yeah, do it to @Aji on Twitter because I've been trying to get that three-letter handle for years. No, but if you want to talk to me, I'm @DoodlingDev. But, yeah, certainly, it does feel sometimes like an overloaded term, and I just want to go back to talking about plain, old Ruby objects.

+ +

JOËL: So, service object is definitely an overloaded term. It's used for a lot of things. One thing that I've often seen it referring to are objects that respond to call. And just to keep away the confusion, maybe let's call them Command objects for the purposes of this conversation.

+ +

AJI: Sounds good.

+ +

JOËL: I commonly see them done where the implementation is done with a class method named call. Sometimes it delegates to an instance that also has call. Sometimes it's all implemented as a class method. How do you feel about that pattern?

+ +

AJI: I don't mind the idea of a thing that responds to call. It, in a way, sort of implies that the class is sort of named as an action, which I don't like. It has an er name, and that kind of has a class named as a pattern. And that always sort of bugs me a little bit. But what I hope for when I open up one of those sorts of classes or objects is that it's going to delegate to an instance because then you're, again, picking up all of those wonderful benefits of the instance-level programming.

+ +

JOËL: You keep mentioning the wonderful benefits of instance-level programming. What are some of those benefits?

+ +

AJI: One of the ones that sort of strikes me most visibly or kind of viscerally when I see it is that they're very easy to understand. You can extract methods pretty easily that don't turn into kind of clumsy code of a bunch of different class methods that all have four arguments passed in because they're all operating on the same context. And when you're all operating on the same context, you have really a shared state.

+ +

And if you're just passing that shared state around, it just gets super confusing. And you get into the order of your arguments, making a big impact on how you are interacting with these different things. And so I think that's sort of the first thing that comes to mind is just visually noisy, which for me is super hard to get my head around, like, well, how am I supposed to use this thing? Can I extend it?

+ +

JOËL: Yeah, I would definitely say that if you have a group of class methods that all take, commonly, it's the first argument, the same piece of data and tries to operate on it, that's probably a code smell that points to the fact that these things want to be an instance that lives around it. This could be a form of primitive obsession if you're passing around, let's say, a hash, all of these, and maybe what you really want is to sort of reify that hash into an object. And then all these class methods that used to operate on the hash can now become instance methods on your richer domain object.

+ +

AJI: Yeah. What do you say to the folks that come from maybe a more functional mindset or are kind of picking up on the wave of functional programming that's out there in the ethos that say that you've got a bunch of side effects when you don't have everything that your method is operating on, being passed on or passed in?

+ +

JOËL: I think side effect is a broad term. You could refer to it as modifying the internal state of an object. Technically, mutation is a side effect. And then you have things like doing effects out in the outside world, like making an HTTP query, printing to the screen, things like that. I think those are probably two separate concepts. Functional programming is great. I love writing functional code.

+ +

When you're writing Ruby, Ruby is primarily an object-oriented language with some functional aspects brought in. In my opinion, it's very, you know, a great combination of the two. I think they've gotten the balance well so that the two paradigms play nicely together rather than competing. But I think it's an object-oriented language first with some functional added in. And so you're not going to be, I mean, I guess you could; there is a way to write Ruby where everything is a lambda or where everything is a class method that is pure and takes in inputs. But that's not the idiomatic way to write Ruby. Generally, you're creating objects that have some state.

+ +

That being said, if an object is mutating a lot of global state, that's going to become problematic. With regards to its internal state, though, because it is very much localized and it's private, nobody else gets to see it; in many ways, an object can mutate itself, and that chain stays pretty local.

+ +

AJI: Yeah, absolutely. You've tripped onto another one of my favorite rabbit holes of idiomatic code, and, like, what does that mean, and why should we strive for that? But I absolutely agree that when Ruby is written to conform to other paradigms that aren't mostly object-oriented is when it starts to get hard to use. It starts to feel a little off. Maybe it has code smells around it. It's going to give me the heebie-jeebies, whatever that might mean for you or for different developers.

+ +

I think we all have our things that are sort of this doesn't feel right. And you kind of dig into it, and you can sort of back that up. And whenever Ruby starts to look like something that isn't lots of little objects sending messages, is when I start to get a little on edge, maybe.

+ +

JOËL: It is worth, I think, calling out the fact that Ruby is a very expressive language. And there are effectively many...you could call them dialects of it. You have sort of your pure sort of OO approach. You have what's typically written in Rails, which has some OO things. But Rails is also, in many ways, it's very DSL-heavy and, in some ways, very class method-heavy. So writing Rails is sort of its own twist on Ruby.

+ +

And then, some people will try to completely retrofit a functional approach onto Ruby, and that's also a way that some people like to write their code. And some of these, you can't necessarily say they're not valid, but they're not what you'll mostly see in the wild. And they're not necessarily the approach that I would recommend.

+ +

AJI: Yeah, that's the blessing, and the curse of both programming in general and such an expressive language like Ruby is that there are many different valid ways to do it. And what are your trade-offs going to be when you make those choices? I think that falls kind of smack dab into that idiomatic conversation.

+ +

And it comes up for me, too, as a consultant because I try to tend towards that idiomatic, those common patterns and practices because I'm not going to live with this code forever. I need to hand this off. And the closer it is to what you might see out there in the wild more commonly, the easier it will be for the next Ruby developer to come pick it up and extend it.

+ +

JOËL: So you'd mentioned earlier some of the benefits of instance programming. One of the things that I find is maybe a little bit weird when you go heavily into the class method approach is that there is only one instance of the class, and it is globally available.

+ +

AJI: Are you talking about a singleton there?

+ +

JOËL: Yes. And, in fact, your class is effectively a singleton, potentially with globally mutable state. I hope not, but potentially with all of the gotchas and warnings that that entails. And so, if you think of your user instance, you need a reference to it, and there can be multiple of them, and you can call methods on them. If everything is happening at the class level, there is a single user class in memory shared by anyone who wants to use it. It's globally accessible. You can all call methods on it. Yeah, in many ways, it does act like a singleton.

+ +

AJI: And let's not even get into the Ruby chestnut of everything's an object. So it is an instance of a class in and of itself.

+ +

JOËL: Yes.

+ +

AJI: But, absolutely, it can start to act that way. But the singleton it's enshrined in the Gang of Four book of patterns. Like, so what's wrong about a singleton? I hope you can understand over the airwaves the devil's advocate that I'm playing here. [laughs]

+ +

JOËL: Yes. There are little horns that have sprouted on your head right now. I think part of the problem with singletons is that, generally, they are globally accessible. There's the problem of global mutable state again. There was a time, I think, when the OO community went pretty wild with singletons, and people realized that this was not great. And so, over time, a consensus evolved that singletons are a pattern that, while useful, should be used rarely and in moderation.

+ +

And a lot of warnings have been shared in the community, like, be careful not to overuse the singleton pattern or don't build your system out of singletons. And maybe that's what feels so weird about a system that's built primarily in terms of class methods for me is that it feels like it's built out of singletons.

+ +

AJI: Yeah. When I think of object-oriented programming, I kind of fall back to maybe one of the ideals of it is that it represents the world more accurately or maybe more understandably. And that sort of idea doesn't fit that paradigm, does it? If you're a factory that is making widgets, there's not the one canonical widget that all of your customers are going to be talking to and using. They are going to each have their own individual widgets. And those customers can be thought of like the consumers of your methods, your objects.

+ +

JOËL: The idea being the real-world thing you're simulating normally, there are multiple actors of every type rather than a single sort of generic one that stands in for everybody.

+ +

AJI: If this singleton is going to be your interface or the way that you interact with each of these things that are conceptually different, like a user or something like that, then differentiating between which user becomes a lot harder to do. It takes a lot more setup and involved process in referring to this user when and that kind of thing and creating the little instances. Then you've got more kind of direct reference to a single concept, a single individual.

+ +

JOËL: So what you've described is a very sort of classic OO mindset. You find the data and the behaviors that go together. You try to oftentimes simulate the world, model it in terms of actors that give and receive messages. In many ways, though, I think when you're building a system out of class methods, you're thinking about the world in an almost different paradigm. In many ways, it feels almost procedural. What are the behaviors that need to happen in my app? What are the things that need to be done?

+ +

You'd mentioned earlier that oftentimes these classes or the methods on them will end up with E-R; they're all verbs. You have a thing-doer, a thing executor, thing manager. They all do things rather than having domain concepts extracted and pulled out. Would you say that that feels somewhat procedural to you as well?

+ +

AJI: Yeah. I think a great way to divide it is the way that you have right there; it's these sorts of mindsets. Do you have collections of things that have behaviors, or do you have collections of behaviors that might refer to things? And where you're approaching the design of a system, either from that behavior side or from that object side, is going to be a different mindset. Procedural being more focused on that kind of behavior and telling it what to do rather than putting... I think this is probably a butchered Sandi Metz example, but putting your roommate who hates cats and a cat that doesn't want its tail stepped on in one room, and eventually, things will happen accordingly.

+ +

And those two mindsets are going to end up with very different architectures, very different designs, very different ways of building these applications that we make. And, again, does that come back to...Ruby, potentially to a lesser extent but still in the same camp, is object-oriented language, and it sort of functions best when considered and then constructed in that mindset.

+ +

And I often wonder sometimes if language developers and language designers make anti-patterns sort of purposefully awkward to use. Like, if you want to hide a lot of class methods, you can do the class shovels self version of things or have private_class_method littered all the way through your file. And it seems to me like that might be a little bit of a flag that, like, hey, you're working against the system here. You're trying to make it do a thing that it doesn't naturally want to do.

+ +

JOËL: Yeah, because you'd mentioned this private_class method thing because, by default, it's hard to get class methods to be private. You have to use a special keyword. You can't just write private in the class and then assume that the methods below it are going to be private because that does not apply to class methods.

+ +

AJI: Exactly. And that friction to making an object that has a smaller interface, that kind of hides its implementation, seems as though it's a purposeful way that Ruby itself was designed to maybe nudge us, developers, into a certain way of working or suggesting a certain mindset.

+ +

JOËL: There's a classic Code Climate article titled Class Methods Resist Refactoring. And it mentions different ways that when you're relying heavily on class methods, it's harder to do some of the traditional refactors things like just extract method because it is clunkier because you can't have private methods as easily. You can't share state, so you have to thread variables through. I guess, technically, you can share state with things like class variables and class instance variables, but if you do that, you will probably be very sad.

+ +

AJI: [laughs] Yeah, you're opening yourself up to a whole world of hurt there, aren't you? And, yeah, you're opening yourself up to a whole world of hurt there with that, aren't you? Sort of sharing data so dangerously around your app.

+ +

JOËL: So I'm a big fan of test-driven development. And one of the things that TDD believes in is that test pain should help guide the design of your system and that, generally, things that are easier to test are better designed.

+ +

AJI: Yeah.

+ +

JOËL: It's often easier to test class methods because they are globally available singletons. I can easily stub a class. Whereas if I need to stub an instance, I need to do some uglier things like stub any instance of or stub the constructor to return a double, or do some other kind of dirty tricks like that. Does that mean that TDD would prefer a class method-based approach to writing code?

+ +

AJI: I think that a surface-level reading of that might say that it does. And I think that maybe the first pass on things, if you're thinking about I want to get this thing done that's right in front of me right now and just move forward, might kind of imply that. But if you start to think about or have come back to something that was implemented in that way, anytime that sort of behavior is going to grow or change, then it's going to start to...the number of backflips that you have to do become a lot more complicated and a lot higher when you've got class methods.

+ +

Because I find that, yes, you might have to stub out or pass in a created object or something like that. But if you've got a class method, especially if it is calling other class methods inside it, then all of a sudden, you have in your test this setup that looks completely unrelated to anything that you're running and testing, that you have to have all of this insight or knowledge of what those classes are doing just to set up your test framework before you can even run that.

+ +

Another thing that is looked to as an axiom when writing tests that can imply this class approach is that you shouldn't change your code just for the test. If you're doing dependency injection or something like that, passing around little objects, then you're making your code more complicated to make your tests look a certain way.

+ +

JOËL: That's interesting. So maybe I'm reacting to some test pain by trying to change my tests first. So I'm trying to deal with some collaborators, and it is tricky to do. And so I decide, well, the thing I want to do is I want to reach for stubbing. But then that's hard to do because it's instances. So in order to make already that compromise in my test work better, now I change the code to be nicer for the test to use mostly classes because those are global.

+ +

Whereas maybe the correct path to take initially is, say, oh, there isn't test pain here because I'm trying to isolate an object from its collaborators. Maybe we need to pass an object in as an argument rather than hard coding it inside the class.

+ +

AJI: Yeah, absolutely.

+ +

JOËL: So I guess you follow the test pain, but maybe the problem is that you've already kind of gone down a path that might not be the best before you got to the point where you decided that you needed a class method.

+ +

AJI: And I think that idea of following the test pain can be, again, there are only shades of gray; there is no black and white. It can be sort of taken in a lot of different ways. And the way that I think about it is that test pain is also sort of an early warning sign that there's going to be pain if you want to reuse this class or these behaviors somewhere else. And if it was useful somewhere, it's likely it's going to be useful in another place.

+ +

And there are many different kinds of tests pain. The testing is a little easier with a class method because you're not stubbing out any instance of. You're just stubbing; really, what's the difference between stubbing out any instance of or stubbing out the class? Is that just a semantic difference? Is that --

+ +

JOËL: Because someone on the internet said that stubbing any instance of is bad.

+ +

AJI: Ooh, right, the internet. I should have read that one. The thing that you can do with passing around instances or sending messages to instances as you do when you're calling a method is that you can easily swap in a different object if you need to stub it. It's similar to how you can change the implementation under the hood of an object and pass in an object that responds to the same messages and kind of keep moving forward with your duck typing.

+ +

If you can go into your tests and pass it sort of an object that's always going to return a thing...because we're not testing what that does; we just need a certain response so that we can move forward with the pathway that is under test. You can do that in so many different ways. You could have FactoryBot, for instance, give you a certain shape of a thing. You can create a tiny, little class right there in your tests that does something specific, that can be easily understood what's going on under the hood here.

+ +

And instead of having to potentially stub out or create all of these pathways that need to be followed that are overwriting logic that's happening in different class methods or different places otherwhere in the application, you can just pass in this one simplified thing to keep your tests sort of smaller and easier to wrap your head around all in just one go.

+ +

JOËL: I think what I'm getting here is that when you design your code around instances, you're more likely to build it in a modular way where you pass objects to other objects. And when you build your code using class methods, you're more likely to write it in a hard-coded way. Because you have that globally available class, you just hard-code it and then call it directly rather than passing things in. And so things end up more coupled and, therefore, high coupling leads to more test pain.

+ +

AJI: Yeah, I think you've really kind of hit on something here that the approach of using class methods is locking that class into kind of a single context or use case. Usually, it is this global thing that is this one way, and that's even kind of backed up by the fact that class methods are load-time logic instead of run-time logic. And it really kind of not only couples but it makes it more brittle and less amenable to kind of reuse.

+ +

JOËL: That's a really interesting distinction. I often tend to think of runtime versus load time in terms of composition versus inheritance. Composition, you can combine objects together at runtime and get behaviors built on the fly as the code is executing, whereas inheritance sort of inherently freezes you into a particular combination of behaviors at the time of loading the code. It's something that the programmers set up, and so it is much less flexible.

+ +

And that is one of the arguments why the Gang of Four patterns book recommends composition over inheritance in many situations is because of that runtime versus load time dichotomy. And I hadn't made that connection for class methods versus instance methods, but I think there's a parallel there.

+ +

AJI: Yeah, absolutely. The composition versus inheritance thing, I think, goes very hand in hand with the conversation that we're having about putting your behavior on a class versus an instance because...and I don't know if this is again yielding my thoughts to 'the internet said' in that composition is preferable to inheritance. But without unpacking that right there, that is certainly something that I strive for as well. And while it might have, much like TDD, some kind of superficial, short-term complexity, it has long-term payoff in that flexibility and that reuse, and that extensibility, and all of those other buzzwords that we developers like to throw around.

+ +

JOËL: So you've shared a lot of thoughts on the use of class methods. I think this could branch into so many other aspects of object-oriented design that we haven't looked at or that we could go deeper, things like TDD. We could look into how it works with the solid principles, all sorts of things. But I think the big takeaway for me is that class methods are very useful, but it's easy to use them as our single hammer to every problem being a nail.

+ +

And it's good to diversify your toolset. And some tools are specialized; they're good to be used in very specific situations that don't come across very often, and others are used every day. And maybe class methods are the former.

+ +

AJI: Absolutely. That hammer-and-nail metaphor was right where I was headed for too. Love it.

+ +

JOËL: Well, thank you so much, Aji, for joining the conversation today. Where can people find you online?

+ +

AJI: Yeah, anywhere you want to look for me: Instagram, GitHub, Twitter. I'm @DoodlingDev, so just send all your angry emails that way.

+ +

JOËL: And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Inspired by a Slack thread, Joël invites fellow thoughtbotter Aji Slater on the show to talk about when you should use class methods and when you should avoid them. Are there particular anti-patterns to look out for? How does this fit in with good object-oriented programming? What about Rails? What is an "alternate constructor"? What about service objects? So many questions, and friends: Aji and Joël deliver answers!

+ +
+ +

Backbone.js collections
+Query object
+Rails is a dialect
+Meditations on a Class Method
+Why Ruby Class Methods Resist Refactoring

+ +

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. And today, I'm joined by fellow thoughtboter Aji Slater.

+ +

AJI: Howdy.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Aji, what's new in your world?

+ +

AJI: Yeah, well, I just joined a new project, so that's kind of the newest thing in my day-to-day work world. I say just joined, but I guess it was about a month ago now. I'm on the Liftoff team at thoughtbot, which is different than the team that you're on. We do more closer to greenfield ideas and things like that. So there's actually not much to speak about there in that project just yet. Rails new is still just over the horizon for us.

+ +

So I've been putting a lot of unused brain cycles toward a side project that is sort of a personal knowledge base concept, and that's a whole thing that I could probably host an entire podcast about. So we don't have to go too deep into my theories about that. But suffice it to say I've talked to some other ADHDers like myself who find that that space is not really conducive to the way that we think and have to organize ourselves and our personal knowledge stores. So sort of writing an app that can lend itself to our fast brains a little bit better.

+ +

JOËL: Nice. I just recently recorded an episode of this podcast talking a little bit about note-taking approaches and knowledge-base systems. So, yeah, it's a topic that's very much top of mind for me right now.

+ +

AJI: Yeah, what else is going on in your world?

+ +

JOËL: I'm based in New England in the U.S. East Coast, and it is fall here. I feel like it happened kind of all of a sudden. And the traditional fall thing to do here is to go to an orchard and pick apples. It's a fun activity to do, and so I'm in the middle of planning that. Yeah, it's fun to go out into nature, very artificial space.

+ +

AJI: [laughs]

+ +

JOËL: But it's a fun thing to do every fall.

+ +

AJI: Yeah, we do that here too. There's an orchard up north of us where my wife and I live in Chicago that we try to visit. And Apple Fest in Lincoln Square is this weekend, and we've been really looking forward to that. Try another time at making homemade hard cider this season, I think, and see how that goes.

+ +

JOËL: Fun. When you say another time, does that mean there was a previous unsuccessful attempt?

+ +

AJI: Yes. Did the sort of naive approach to it, and there is apparently a lot more subtlety to cidermaking than there is home-brew beer. And we got some real strong funk in that cider that did not make it necessarily an enjoyable experience. Like, it worked but wasn't the tastiest.

+ +

JOËL: So it got alcoholic. It was just terrible to drink.

+ +

AJI: Yeah, I would back that up.

+ +

JOËL: So recently, at thoughtbot, we had a conversation among different team members about the use of Ruby class methods, when they make sense, when they are to be avoided. What is their use case? And different people had different opinions. So I'm curious what your take on class methods are. When do you like to use them?

+ +

AJI: Yeah, I remember those conversations coming up. I think I might have even started one of those threads because this is something that comes up to me a lot. I'm a long-time listener, first-time caller to The Bike Shed. [laughs] I can remember awaiting new episodes from Sage and Derek to listen to on my way to and from my first dev job. And at one point, Sage had said, "Never put your business logic in something that you can't call .new on."

+ +

And being a young, impressionable developer at the time, I took that to heart, and that seems something that just has been baked in and stayed very truthful to me. And I think one of the times that I asked that and got some conversation started was I was trying to figure out why did I feel that, and like, why did they say that? And I think, yeah, I try to avoid them. I like making instances of things. What is your stance on the Class Method, capital C, capital M?

+ +

JOËL: I also generally avoid them. I have sort of two main scenarios that I like to use class methods, first is as an alternate constructor. So new is effectively a class method that's built into Ruby's object model. But sometimes, you want variations on your constructor that maybe sets values by default or that construct things with some slightly different inputs, things like that. And so those almost always make sense as class methods. The other thing that I sometimes use a class method for is as an alias for newing up an instance and then immediately calling an instance method on it. So it's just a slightly shorthand way to call some code.

+ +

AJI: That's usually been my first line defense of when there's someone who might feel more comfortable doing class methods that sees me making an instance and says, "Well, you don't need an instance, just make a class method here because it'll get too long if you have to .new and then dot this other thing." And so I'll throw in that magic little trick and be like, here you go. You can call it a class method, and you still get all the benefits of your instance. I love that one.

+ +

JOËL: Do you feel like that maybe defeats the purpose? In terms of the interface that people are using, if you're calling it a class method, do you lose the benefits of trying to do things at the instance level instead? Or is it more in the implementation that the benefits are not at the caller level?

+ +

AJI: I think that's more true that the benefits are at the instance level, and you're getting all of that that goes along with it. And you're not carrying along a lot of what I see as baggage of the class method version, but you're picking up a little bit of that syntactic sugar. And sometimes it's even easier just to conceptualize, especially in the Rails space because we have all of these different class methods like, you know, Find is one I'm sure that we use all the time to call it on a class, and we get back an instance. And so that feels very natural in the Rails world.

+ +

JOËL: I think you could make an argument that that is a form of alternate constructor. It's a class method you call to get an instance back.

+ +

AJI: Yeah, absolutely.

+ +

JOËL: The fact that it makes a background request to the database is an implementation detail.

+ +

AJI: For sure. I agree with that. I had a similar need in a recent project where the data was kept on a third-party API. So I treated it the same way as, instead of going out to the database like ActiveRecord does, made a class method that went off to the API and then came back and made the object that was the representation of that idea in our application. So, yeah, I wholeheartedly agree with that.

+ +

JOËL: So in Rails, we have the scope keyword, which will run some query to get a collection of records. But another way that they're often implemented is as class methods, and they're more or less interchangeable. How do you feel about that kind of use of class methods on an ActiveRecord object? Does that violate some of the ideas that we've been talking about? Does it sort of fit in?

+ +

AJI: I think when reaching for that sort of need, I sort of fall into the camp of making a class method rather than using a scope. It feels a little less like extending some basic Rails functionality or implying that it's part of the inherent framework and makes it a little more like behavior that's been added that's specific to this domain. And I think that distinction comes into my thinking there. I'm sure there are other reasons. What are your thoughts there? Maybe it'll spark an idea for me.

+ +

JOËL: For me, I think I also generally prefer to write them as class methods rather than using the scope keyword, even though they're more or less the same thing. What is interesting is that, in a way, they kind of feel like alternate constructors in that they don't give you an instance; they give you back a collection of instances back. So if we bend the rules a little bit...these are not hard and fast rules but the guidelines. If we bend the guidelines a little bit, they kind of fit under the general categories for best uses of class method that we discussed earlier.

+ +

AJI: Yeah, I can definitely see that. I tend to think, or at least I think when you had first brought up the term of alternate constructors, my first thought was of one instance; you ask for a thing, and it gives you this thing back. But it's the same sort of idea with that collection because you're not getting just one instance; you're getting many instances. But it's the same kind of idea. You've asked the larger concept of the thing, the class, to give you back individuals of that class. So that totally falls in line with how I think about acceptable uses of these class methods the way that we've been talking about them.

+ +

JOËL: Rails is something really interesting where a lot of the logic that pertains to a single item will live at the instance level. And then logic that pertains to a group of items will live at the class level. So you almost have like two categories of operations that you can run that semantically live either at the class or the instance level. Have you ever noticed that separation before?

+ +

AJI: I think that separation feels natural to me because I came into programming through Rails. And I might have been colored in my thinking about this by the framework. The way that I conceptualize what a class is being sort of this blueprint or platonic ideal of what an individual might be and sort of describing the potential behaviors of such an individual. Having that kind of larger concept be able to work across multiple instances feels, yeah, it feels sort of natural.

+ +

Like, if you were to think about this idea of a chair, then if you went in and modified what a chair is to mean, then any chair that you asked for later on would kind of come with that behavior along with it. Or if you ask for several chairs, they would all sort of have that idea.

+ +

JOËL: I think similar to you; I had that outlook on that's almost like a natural structuring of things. And then, years ago, I got into the hot, new JavaScript framework that was Backbone.js. And it actually separates...it has like a model for individual instances, and then a separate kind of model thing for collections. And that kind of blew my mind.

+ +

But what was interesting, then, is that you effectively have instance methods that can deal with all things collection-related, any sort of filtering, any sort of transformations. All of those are done, which you have an instance of a collection, basically, that you act on. And I guess if we were trying to translate that into Rails, that's almost like the concept of a query object.

+ +

AJI: Hmm, it's sort of an interesting way to think about that. And Backbone, I feel like I did a day of that in bootcamp. But it has been some time, so I'm not sure that I've worked with that pattern specifically. But it does sort of bring up the idea of how much do you want to be in one model class? And do you want it to contain both of these concepts?

+ +

If you have a lot of complex logic that is going to be dealing with a collection, rather than putting that in your model, I think I would probably reach for something like a service object that is going to be specifically doing that and sort of more along that Backboney approach maybe like a query object or something like that.

+ +

JOËL: Interesting. When you use the term service object, do you mean something that's not a Rails model, just in general? Or are you talking specifically about one of these objects that can respond to call and is... I've heard them sometimes called Command objects or method objects.

+ +

AJI: Yeah, that's an overloaded term certainly in the real space, isn't it? Service object, and what does that mean? I think generally, when I say it, I'm meaning just a plain, old Ruby object like something that is doing its one thing. You're going to use it to do its implementation details. They're all kind of hidden behind in private methods and return you something useful that you can then plug into what you were doing or what you need going on in some other place in your app.

+ +

So it, to me, doesn't imply any specific implementation of, like, do you have call? Do you use it this way? Do you use it that way? But it's something that's kind of outside of it is either a model, a view, a controller, and it encapsulates some kind of behavior. So whether that, like we're saying, is a filtering or, you know, it's going to wrap that up.

+ +

JOËL: I see. So, for you, a query object would be a service object.

+ +

AJI: Yeah, I think so. You know, maybe this is one of the reasons why I generally don't like the overuse of the term service object in our space. I don't know if that's a hot take, and I'm going to get emails for this. But --

+ +

JOËL: Everybody send your angry tweets @Aji.

+ +

AJI: Yeah, do it to @Aji on Twitter because I've been trying to get that three-letter handle for years. No, but if you want to talk to me, I'm @DoodlingDev. But, yeah, certainly, it does feel sometimes like an overloaded term, and I just want to go back to talking about plain, old Ruby objects.

+ +

JOËL: So, service object is definitely an overloaded term. It's used for a lot of things. One thing that I've often seen it referring to are objects that respond to call. And just to keep away the confusion, maybe let's call them Command objects for the purposes of this conversation.

+ +

AJI: Sounds good.

+ +

JOËL: I commonly see them done where the implementation is done with a class method named call. Sometimes it delegates to an instance that also has call. Sometimes it's all implemented as a class method. How do you feel about that pattern?

+ +

AJI: I don't mind the idea of a thing that responds to call. It, in a way, sort of implies that the class is sort of named as an action, which I don't like. It has an er name, and that kind of has a class named as a pattern. And that always sort of bugs me a little bit. But what I hope for when I open up one of those sorts of classes or objects is that it's going to delegate to an instance because then you're, again, picking up all of those wonderful benefits of the instance-level programming.

+ +

JOËL: You keep mentioning the wonderful benefits of instance-level programming. What are some of those benefits?

+ +

AJI: One of the ones that sort of strikes me most visibly or kind of viscerally when I see it is that they're very easy to understand. You can extract methods pretty easily that don't turn into kind of clumsy code of a bunch of different class methods that all have four arguments passed in because they're all operating on the same context. And when you're all operating on the same context, you have really a shared state.

+ +

And if you're just passing that shared state around, it just gets super confusing. And you get into the order of your arguments, making a big impact on how you are interacting with these different things. And so I think that's sort of the first thing that comes to mind is just visually noisy, which for me is super hard to get my head around, like, well, how am I supposed to use this thing? Can I extend it?

+ +

JOËL: Yeah, I would definitely say that if you have a group of class methods that all take, commonly, it's the first argument, the same piece of data and tries to operate on it, that's probably a code smell that points to the fact that these things want to be an instance that lives around it. This could be a form of primitive obsession if you're passing around, let's say, a hash, all of these, and maybe what you really want is to sort of reify that hash into an object. And then all these class methods that used to operate on the hash can now become instance methods on your richer domain object.

+ +

AJI: Yeah. What do you say to the folks that come from maybe a more functional mindset or are kind of picking up on the wave of functional programming that's out there in the ethos that say that you've got a bunch of side effects when you don't have everything that your method is operating on, being passed on or passed in?

+ +

JOËL: I think side effect is a broad term. You could refer to it as modifying the internal state of an object. Technically, mutation is a side effect. And then you have things like doing effects out in the outside world, like making an HTTP query, printing to the screen, things like that. I think those are probably two separate concepts. Functional programming is great. I love writing functional code.

+ +

When you're writing Ruby, Ruby is primarily an object-oriented language with some functional aspects brought in. In my opinion, it's very, you know, a great combination of the two. I think they've gotten the balance well so that the two paradigms play nicely together rather than competing. But I think it's an object-oriented language first with some functional added in. And so you're not going to be, I mean, I guess you could; there is a way to write Ruby where everything is a lambda or where everything is a class method that is pure and takes in inputs. But that's not the idiomatic way to write Ruby. Generally, you're creating objects that have some state.

+ +

That being said, if an object is mutating a lot of global state, that's going to become problematic. With regards to its internal state, though, because it is very much localized and it's private, nobody else gets to see it; in many ways, an object can mutate itself, and that chain stays pretty local.

+ +

AJI: Yeah, absolutely. You've tripped onto another one of my favorite rabbit holes of idiomatic code, and, like, what does that mean, and why should we strive for that? But I absolutely agree that when Ruby is written to conform to other paradigms that aren't mostly object-oriented is when it starts to get hard to use. It starts to feel a little off. Maybe it has code smells around it. It's going to give me the heebie-jeebies, whatever that might mean for you or for different developers.

+ +

I think we all have our things that are sort of this doesn't feel right. And you kind of dig into it, and you can sort of back that up. And whenever Ruby starts to look like something that isn't lots of little objects sending messages, is when I start to get a little on edge, maybe.

+ +

JOËL: It is worth, I think, calling out the fact that Ruby is a very expressive language. And there are effectively many...you could call them dialects of it. You have sort of your pure sort of OO approach. You have what's typically written in Rails, which has some OO things. But Rails is also, in many ways, it's very DSL-heavy and, in some ways, very class method-heavy. So writing Rails is sort of its own twist on Ruby.

+ +

And then, some people will try to completely retrofit a functional approach onto Ruby, and that's also a way that some people like to write their code. And some of these, you can't necessarily say they're not valid, but they're not what you'll mostly see in the wild. And they're not necessarily the approach that I would recommend.

+ +

AJI: Yeah, that's the blessing, and the curse of both programming in general and such an expressive language like Ruby is that there are many different valid ways to do it. And what are your trade-offs going to be when you make those choices? I think that falls kind of smack dab into that idiomatic conversation.

+ +

And it comes up for me, too, as a consultant because I try to tend towards that idiomatic, those common patterns and practices because I'm not going to live with this code forever. I need to hand this off. And the closer it is to what you might see out there in the wild more commonly, the easier it will be for the next Ruby developer to come pick it up and extend it.

+ +

JOËL: So you'd mentioned earlier some of the benefits of instance programming. One of the things that I find is maybe a little bit weird when you go heavily into the class method approach is that there is only one instance of the class, and it is globally available.

+ +

AJI: Are you talking about a singleton there?

+ +

JOËL: Yes. And, in fact, your class is effectively a singleton, potentially with globally mutable state. I hope not, but potentially with all of the gotchas and warnings that that entails. And so, if you think of your user instance, you need a reference to it, and there can be multiple of them, and you can call methods on them. If everything is happening at the class level, there is a single user class in memory shared by anyone who wants to use it. It's globally accessible. You can all call methods on it. Yeah, in many ways, it does act like a singleton.

+ +

AJI: And let's not even get into the Ruby chestnut of everything's an object. So it is an instance of a class in and of itself.

+ +

JOËL: Yes.

+ +

AJI: But, absolutely, it can start to act that way. But the singleton it's enshrined in the Gang of Four book of patterns. Like, so what's wrong about a singleton? I hope you can understand over the airwaves the devil's advocate that I'm playing here. [laughs]

+ +

JOËL: Yes. There are little horns that have sprouted on your head right now. I think part of the problem with singletons is that, generally, they are globally accessible. There's the problem of global mutable state again. There was a time, I think, when the OO community went pretty wild with singletons, and people realized that this was not great. And so, over time, a consensus evolved that singletons are a pattern that, while useful, should be used rarely and in moderation.

+ +

And a lot of warnings have been shared in the community, like, be careful not to overuse the singleton pattern or don't build your system out of singletons. And maybe that's what feels so weird about a system that's built primarily in terms of class methods for me is that it feels like it's built out of singletons.

+ +

AJI: Yeah. When I think of object-oriented programming, I kind of fall back to maybe one of the ideals of it is that it represents the world more accurately or maybe more understandably. And that sort of idea doesn't fit that paradigm, does it? If you're a factory that is making widgets, there's not the one canonical widget that all of your customers are going to be talking to and using. They are going to each have their own individual widgets. And those customers can be thought of like the consumers of your methods, your objects.

+ +

JOËL: The idea being the real-world thing you're simulating normally, there are multiple actors of every type rather than a single sort of generic one that stands in for everybody.

+ +

AJI: If this singleton is going to be your interface or the way that you interact with each of these things that are conceptually different, like a user or something like that, then differentiating between which user becomes a lot harder to do. It takes a lot more setup and involved process in referring to this user when and that kind of thing and creating the little instances. Then you've got more kind of direct reference to a single concept, a single individual.

+ +

JOËL: So what you've described is a very sort of classic OO mindset. You find the data and the behaviors that go together. You try to oftentimes simulate the world, model it in terms of actors that give and receive messages. In many ways, though, I think when you're building a system out of class methods, you're thinking about the world in an almost different paradigm. In many ways, it feels almost procedural. What are the behaviors that need to happen in my app? What are the things that need to be done?

+ +

You'd mentioned earlier that oftentimes these classes or the methods on them will end up with E-R; they're all verbs. You have a thing-doer, a thing executor, thing manager. They all do things rather than having domain concepts extracted and pulled out. Would you say that that feels somewhat procedural to you as well?

+ +

AJI: Yeah. I think a great way to divide it is the way that you have right there; it's these sorts of mindsets. Do you have collections of things that have behaviors, or do you have collections of behaviors that might refer to things? And where you're approaching the design of a system, either from that behavior side or from that object side, is going to be a different mindset. Procedural being more focused on that kind of behavior and telling it what to do rather than putting... I think this is probably a butchered Sandi Metz example, but putting your roommate who hates cats and a cat that doesn't want its tail stepped on in one room, and eventually, things will happen accordingly.

+ +

And those two mindsets are going to end up with very different architectures, very different designs, very different ways of building these applications that we make. And, again, does that come back to...Ruby, potentially to a lesser extent but still in the same camp, is object-oriented language, and it sort of functions best when considered and then constructed in that mindset.

+ +

And I often wonder sometimes if language developers and language designers make anti-patterns sort of purposefully awkward to use. Like, if you want to hide a lot of class methods, you can do the class shovels self version of things or have private_class_method littered all the way through your file. And it seems to me like that might be a little bit of a flag that, like, hey, you're working against the system here. You're trying to make it do a thing that it doesn't naturally want to do.

+ +

JOËL: Yeah, because you'd mentioned this private_class method thing because, by default, it's hard to get class methods to be private. You have to use a special keyword. You can't just write private in the class and then assume that the methods below it are going to be private because that does not apply to class methods.

+ +

AJI: Exactly. And that friction to making an object that has a smaller interface, that kind of hides its implementation, seems as though it's a purposeful way that Ruby itself was designed to maybe nudge us, developers, into a certain way of working or suggesting a certain mindset.

+ +

JOËL: There's a classic Code Climate article titled Class Methods Resist Refactoring. And it mentions different ways that when you're relying heavily on class methods, it's harder to do some of the traditional refactors things like just extract method because it is clunkier because you can't have private methods as easily. You can't share state, so you have to thread variables through. I guess, technically, you can share state with things like class variables and class instance variables, but if you do that, you will probably be very sad.

+ +

AJI: [laughs] Yeah, you're opening yourself up to a whole world of hurt there, aren't you? And, yeah, you're opening yourself up to a whole world of hurt there with that, aren't you? Sort of sharing data so dangerously around your app.

+ +

JOËL: So I'm a big fan of test-driven development. And one of the things that TDD believes in is that test pain should help guide the design of your system and that, generally, things that are easier to test are better designed.

+ +

AJI: Yeah.

+ +

JOËL: It's often easier to test class methods because they are globally available singletons. I can easily stub a class. Whereas if I need to stub an instance, I need to do some uglier things like stub any instance of or stub the constructor to return a double, or do some other kind of dirty tricks like that. Does that mean that TDD would prefer a class method-based approach to writing code?

+ +

AJI: I think that a surface-level reading of that might say that it does. And I think that maybe the first pass on things, if you're thinking about I want to get this thing done that's right in front of me right now and just move forward, might kind of imply that. But if you start to think about or have come back to something that was implemented in that way, anytime that sort of behavior is going to grow or change, then it's going to start to...the number of backflips that you have to do become a lot more complicated and a lot higher when you've got class methods.

+ +

Because I find that, yes, you might have to stub out or pass in a created object or something like that. But if you've got a class method, especially if it is calling other class methods inside it, then all of a sudden, you have in your test this setup that looks completely unrelated to anything that you're running and testing, that you have to have all of this insight or knowledge of what those classes are doing just to set up your test framework before you can even run that.

+ +

Another thing that is looked to as an axiom when writing tests that can imply this class approach is that you shouldn't change your code just for the test. If you're doing dependency injection or something like that, passing around little objects, then you're making your code more complicated to make your tests look a certain way.

+ +

JOËL: That's interesting. So maybe I'm reacting to some test pain by trying to change my tests first. So I'm trying to deal with some collaborators, and it is tricky to do. And so I decide, well, the thing I want to do is I want to reach for stubbing. But then that's hard to do because it's instances. So in order to make already that compromise in my test work better, now I change the code to be nicer for the test to use mostly classes because those are global.

+ +

Whereas maybe the correct path to take initially is, say, oh, there isn't test pain here because I'm trying to isolate an object from its collaborators. Maybe we need to pass an object in as an argument rather than hard coding it inside the class.

+ +

AJI: Yeah, absolutely.

+ +

JOËL: So I guess you follow the test pain, but maybe the problem is that you've already kind of gone down a path that might not be the best before you got to the point where you decided that you needed a class method.

+ +

AJI: And I think that idea of following the test pain can be, again, there are only shades of gray; there is no black and white. It can be sort of taken in a lot of different ways. And the way that I think about it is that test pain is also sort of an early warning sign that there's going to be pain if you want to reuse this class or these behaviors somewhere else. And if it was useful somewhere, it's likely it's going to be useful in another place.

+ +

And there are many different kinds of tests pain. The testing is a little easier with a class method because you're not stubbing out any instance of. You're just stubbing; really, what's the difference between stubbing out any instance of or stubbing out the class? Is that just a semantic difference? Is that --

+ +

JOËL: Because someone on the internet said that stubbing any instance of is bad.

+ +

AJI: Ooh, right, the internet. I should have read that one. The thing that you can do with passing around instances or sending messages to instances as you do when you're calling a method is that you can easily swap in a different object if you need to stub it. It's similar to how you can change the implementation under the hood of an object and pass in an object that responds to the same messages and kind of keep moving forward with your duck typing.

+ +

If you can go into your tests and pass it sort of an object that's always going to return a thing...because we're not testing what that does; we just need a certain response so that we can move forward with the pathway that is under test. You can do that in so many different ways. You could have FactoryBot, for instance, give you a certain shape of a thing. You can create a tiny, little class right there in your tests that does something specific, that can be easily understood what's going on under the hood here.

+ +

And instead of having to potentially stub out or create all of these pathways that need to be followed that are overwriting logic that's happening in different class methods or different places otherwhere in the application, you can just pass in this one simplified thing to keep your tests sort of smaller and easier to wrap your head around all in just one go.

+ +

JOËL: I think what I'm getting here is that when you design your code around instances, you're more likely to build it in a modular way where you pass objects to other objects. And when you build your code using class methods, you're more likely to write it in a hard-coded way. Because you have that globally available class, you just hard-code it and then call it directly rather than passing things in. And so things end up more coupled and, therefore, high coupling leads to more test pain.

+ +

AJI: Yeah, I think you've really kind of hit on something here that the approach of using class methods is locking that class into kind of a single context or use case. Usually, it is this global thing that is this one way, and that's even kind of backed up by the fact that class methods are load-time logic instead of run-time logic. And it really kind of not only couples but it makes it more brittle and less amenable to kind of reuse.

+ +

JOËL: That's a really interesting distinction. I often tend to think of runtime versus load time in terms of composition versus inheritance. Composition, you can combine objects together at runtime and get behaviors built on the fly as the code is executing, whereas inheritance sort of inherently freezes you into a particular combination of behaviors at the time of loading the code. It's something that the programmers set up, and so it is much less flexible.

+ +

And that is one of the arguments why the Gang of Four patterns book recommends composition over inheritance in many situations is because of that runtime versus load time dichotomy. And I hadn't made that connection for class methods versus instance methods, but I think there's a parallel there.

+ +

AJI: Yeah, absolutely. The composition versus inheritance thing, I think, goes very hand in hand with the conversation that we're having about putting your behavior on a class versus an instance because...and I don't know if this is again yielding my thoughts to 'the internet said' in that composition is preferable to inheritance. But without unpacking that right there, that is certainly something that I strive for as well. And while it might have, much like TDD, some kind of superficial, short-term complexity, it has long-term payoff in that flexibility and that reuse, and that extensibility, and all of those other buzzwords that we developers like to throw around.

+ +

JOËL: So you've shared a lot of thoughts on the use of class methods. I think this could branch into so many other aspects of object-oriented design that we haven't looked at or that we could go deeper, things like TDD. We could look into how it works with the solid principles, all sorts of things. But I think the big takeaway for me is that class methods are very useful, but it's easy to use them as our single hammer to every problem being a nail.

+ +

And it's good to diversify your toolset. And some tools are specialized; they're good to be used in very specific situations that don't come across very often, and others are used every day. And maybe class methods are the former.

+ +

AJI: Absolutely. That hammer-and-nail metaphor was right where I was headed for too. Love it.

+ +

JOËL: Well, thank you so much, Aji, for joining the conversation today. Where can people find you online?

+ +

AJI: Yeah, anywhere you want to look for me: Instagram, GitHub, Twitter. I'm @DoodlingDev, so just send all your angry emails that way.

+ +

JOËL: And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+P-LDA7OR + + ]]> + + Joël Quenneville + + + 357: Notetaking For Developers + https://bikeshed.thoughtbot.com/357 + c84587aa-e899-4b0a-9f0a-b80d2f2e6988 + Tue, 11 Oct 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Joël is joined by Amanda Beiner, a Senior Software Engineer at GitHub, who is known for her legendary well-organized notes. They talk about various types of notes: debugging, todos, mental stack, Zetelkasten/evergreen notes, notetaking apps and systems, and visual note-taking and diagramming too! + 30:55 + no + + + Joël is joined by Amanda Beiner, a Senior Software Engineer at GitHub, who is known for her legendary well-organized notes. They talk about various types of notes: debugging, todos, mental stack, Zetelkasten/evergreen notes, notetaking apps and systems, and visual note-taking and diagramming too! +@amandabeiner (https://twitter.com/amandabeiner) +Mermaid.live (https://mermaid.live) +Monodraw (https://monodraw.helftone.com/) +Zettlekasten (https://zettelkasten.de/introduction/) +Evergreen Notes (https://notes.andymatuschak.org/Evergreen_notes) +Notion (https://www.notion.so/) +Obsidian (https://obsidian.md/) +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. And today, I'm joined by Amanda Beiner, a Senior Software Engineer at GitHub. +AMANDA: Hey, Joël. Great to see you. +JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Amanda, what is new in your world? +AMANDA: Well, one thing I'm really excited about is that my team at GitHub is experimenting with how we're going to incorporate learning and sharing what we've learned with each other in new ways, and I'm really excited to see where people take that. +So, one of the things that we're thinking of is that we all get really busy, and we all have exciting projects that we're working on in the day-to-day, and sometimes it can be really hard to pull yourself away from them to do some learning that would be something that will probably help you in the long run. But every time we do do projects like that, people are really excited about it, and people like to collaborate. So we're just trying to figure out how we can make that a more regular thing because it's great for our whole team. +JOËL: I love that. Do you have a project or something that you've been getting into recently to learn? +AMANDA: Yeah. One of the things that I have been working on is that this is the first backend-focused role that I've had in my entire career. So I feel like I just kind of keep pulling back layers on how different forms of magic work. And I'm just trying to get closer to the metal of what is powering our databases. And that's something that I've been really excited to learn some more about. +JOËL: So it's digging into a lot of, like, Postgres and just general database theory. +AMANDA: Yeah. So for me, I've spent a lot of time at the Active Record layer as I have been settling into my role and figuring out what our domain models are that we care about. And I'm trying to get a little bit more into the questions of why did these tables end up looking the way that they do? Why are they normalized or denormalized where they are? And trying to get a better idea of the theory behind those decisions. +JOËL: And this is a new team that you've joined. +AMANDA: This is an existing team that I've joined a year ago now. +JOËL: So it sounds like you're dealing with a somewhat unfamiliar codebase. You're looking at a bunch of existing models and database tables. That can be a lot to process and understand when you first join a team. Do you have an approach that you like to use when you're looking at unknown code for the first time? +AMANDA: Yeah. I usually like to dive right in as much as I can, even if it's with a very small bug fix or something like that, something that allows me to just get my hands dirty from the beginning and poke around what models I'm dealing with, and maybe some of the adjacent ones that I don't need to know about now but might want to come back to later. +JOËL: One thing that I find is really helpful for me are diagramming and note-taking. So if it's something like a database table or ActiveRecord models that I'm not familiar with, if it's more than maybe two or three, which is probably the most I can keep in my head, I have to start drawing some kind of like an entity-relationship diagram or maybe even just a bulleted list somewhere where it's like here are the things and how they connect to each other. Otherwise, I’m like, I don't know, I don't have enough RAM in my brain for that. +AMANDA: That sounds like a really helpful approach. How do you approach creating these diagrams? +JOËL: Occasionally, I will just draw it out by hand with pen and paper. But more recently, I've been using tools like Mermaid.js and specifically the website mermaid.live that allows you to just put in some names and arrows, and it will build out a diagram for you. And that's been really helpful to explore and understand what is going on with different entities that relate to each other. +AMANDA: I've used Mermaid.js recently, and I really enjoyed it as well. I found that writing something that lets me write words or something somewhat like words and takes care of the drawing for me is probably best for everyone involved. +JOËL: Yeah, that's a good point. It's kind of like Markdown, the ability to just write a little bit of text and move on and not worry about the size of boxes or the shape of the arrows or whatever. It helps you to really stay in that flow and keep moving. +AMANDA: I definitely agree. I feel like I can't have been the only person that somehow ended up very deep into the Figma documentation because I didn't quite know how to do what I was supposed to do, and I forgot what I was trying to draw in the first place. +JOËL: Right. It's really easy to put your designer hat on and want to make something like a beautiful diagram when this is really more of a capturing your state of mind. It's a rough note, not something you're necessarily going to publish. So, in addition to visuals, do you find yourself taking a lot of notes when you're exploring code or debugging code? +AMANDA: Yeah. I feel like I tend to jot a lot of things down, maybe class names, maybe some links to PRs or issues, or anywhere that might have context about what I'm looking at and how it got in that way. At this point in the process, it feels my notes usually feel like a bit of a bullet point list that doesn't quite make sense to me yet but maybe will get some shaping later. +JOËL: What kind of things do you tend to record in those notes? +AMANDA: I think one of the things that I'm usually trying to get out of those notes is just a snapshot of what I'm trying to accomplish at the time that I'm creating them. What's the bug that I'm trying to solve, and how did I get into this rabbit hole? So that if it ends up being the wrong one, I can follow my breadcrumbs back out and start a different way. +JOËL: Oh, that is really powerful. I love the imagery you used there of following breadcrumbs. And I feel like that's sometimes something I wish I had when I'm either exploring a particular code path or trying to find a bug. And at some point, I've gone a pretty long path, and I need to back up. And I don't remember exactly where I was or how I got to this point, especially if I've gone down a path, backtracked a little bit, gone down a different path, backtracked, gone further down a third path. And so having breadcrumbs, I think, is a really valuable thing that I wish I did more when I was debugging. +AMANDA: Yeah. And one of the most helpful breadcrumbs that I found is just a list of questions. What was the question that I was trying to answer when I opened this file or looked at this method, and did it help me solve that question or answer that question? And if the answer is no, then I can refer back to what the question was and try to think about what else might help me solve that question. +JOËL: I also love that. It's really easy to get sidetracked by other questions or other ideas when exploring or debugging. And sometimes I find that half hour later, I haven't answered the original question I came here to answer, and I kind of haven't even tried. And so, maybe writing down my questions before I go down a path would help me stay more focused during a debugging session rather than just trying to keep it all in my head. +AMANDA: I very much relate to getting nerd sniped by something that looks interesting but ultimately doesn't solve the original problem that you were trying to. +JOËL: This even happens to me when I'm pair programming. And so we'll say out loud the question we're trying to answer is this; let's open this file. And then you go into it, and you're like, oh, now that is an unusual line of code right there. +AMANDA: [laughs] +JOËL: I wonder why they're doing that. Let me check the git blame on this line. Oh, it's from 2015? +AMANDA: [laughs] +JOËL: I wonder what was happening there. Was that part of a Rails upgrade? And then, at some point, the other person has to interject and be like, "That's all fascinating, but I think the question we're actually trying to answer is..." and we get back on track. +AMANDA: I feel like that's a really good opportunity, maybe for a different kind of note of just interesting curiosities in a given codebase. I find that one of the skills that I'm trying to get better at is, rather than building a repository of information or answers to questions, just building a mental map of where the information I'm trying to find lives so that when someone asks me a question or when I have to solve something I don't necessarily know the answer, but I just know the resource to find that will point me in the direction of that answer. +And I feel like those kinds of explorations are really helpful for building out that mental model, even if it may be at the time seems like an unrelated rabbit hole. +JOËL: So this kind of note is a bit more permanent than a bread crumb style note would be. +AMANDA: Yeah, maybe. And I guess maybe it's less of a note, and it feels kind of like an index. +JOËL: Hmmm. +AMANDA: Like something that's connecting other pieces of information. +JOËL: That's really interesting. It's got me thinking about the fact that note-taking can be very different in different situations and for different purposes. So we've talked a little bit about debugging. I think we've mixed debugging and exploration. Maybe those two are not the same, and you treat notes differently. Actually, do you treat those two as different, or do you have different approaches to note-taking when you're exploring a new codebase versus debugging a particular problem? +AMANDA: I think that those kinds of notes could probably be a little bit different because I think when I'm onboarding onto a new codebase, I'm trying to cast a pretty wide net and give some overall information about what these things do that by the time I'm very deep in debugging, it might be information that I already know very well. So I feel like maybe debugging notes are a little bit more procedural. They are a little bit more I did X, and I did Y, and I did Z, and these were the questions. +And the introductory notes to a new codebase might be more along the lines of this is what this model does, and stuff that will eventually become second nature and might be useful to pass off to someone else who's onboarding but which I might myself not refer back to after a certain amount of time. +JOËL: I see. That's an interesting point because not only might the type of notes you take be different in different scenarios, but even their lifespan could be different. The value of a debugging note, that sort of breadcrumbs, might really only be that useful for a few hours or a couple of days. I can imagine notes you're taking while you're exploring a codebase those might be helpful for a much longer period and, as you said, maybe in passing them on to someone else when they're joining a team. +AMANDA: So that makes me think of whether the debugging notes should be as short-lived as I'm making them sound because I feel like there are times where you know you've debugged something previously, but you didn't keep the notes. Maybe they were just on a scrap of paper, and now they're gone. And I feel like I'd like to do a better job of digesting those notes a little bit better and eventually turning them into something that can be a little bit longer-lived. +JOËL: That's fair. I find that, especially for debugging, I like to capture a lot of what was in my notes in the eventual commit message for the fix. Of course, my random breadcrumbs probably don't make sense in the commit message, but a lot of what I have learned along the way often is helpful. +AMANDA: That's a really good point. I hadn't thought of commit messages as notes, but you're right; they totally are. +JOËL: One thing I've done is I've sort of taken this idea to the extreme. I was debugging some weird database table ActiveRecord model interactions, and the modeling was just a little bit unusual. There were multiple sources of truth in the relationships. And there were enough models that I struggled to really understand what was going on. +And so I drew an entity-relationship diagram. And I felt that that was important to understand for people reviewing the code but also anybody looking back at the commit later on. So I used a tool called Monodraw, which allows you to draw simple diagrams as ASCII art. And so, I have a little ASCII art ERD in my commit message. +AMANDA: That's incredible. I feel like if I were a developer git logging and I saw that commit message, I would be both thrilled and terrified of what exactly I was diving into in the git blame. [laughs] +JOËL: Definitely both, definitely both. But I have referred back maybe a few months later. Like you said, I had to refer back to that commit because a similar bug had cropped up somewhere else. And I knew that that commit had information that I had gathered that would make the debugging experience easier. +AMANDA: I guess the commit message is a really good example of having a note that's very closely tied to its context. Like, it's in the context of like a commit, which is a set of changes at a point in time, and it's really well situated in there. What do you think about the trade-offs of having that as part of a commit message versus something like some other sort of documentation where something like that could live? +JOËL: I guess it depends on how you think you're going to use it in the future. Again, for debugging things, it feels like you don't often need to refer back to them, so I don't think you would want to just dump that on a wiki somewhere. It probably makes sense to have that either in just a collection of debugging notes that you have or that you could then dig into if you needed or in a commit message, something like that. But maybe some of the things that you learned along the way could be pulled out and turned into something that lives somewhere else that's maybe less of a note at that point and more of a publication. +AMANDA: That sounds like a fine line between note and publication. +JOËL: Perhaps it's an artificial line that I'm making. +AMANDA: [laughs] +JOËL: But yeah, I guess the idea is that sometimes I will look at my own debugging notes and try to turn them into something like either a wiki page for a particular codebase or potentially even a blog post on the thoughtbot blog, something that I've been able to synthesize out of the notes there. But now you've kind of gone a few steps beyond the underlying raw notes. +AMANDA: I'm interested in your thoughts on that synthesis of notes into how does something go from a commit message into a blog? What does that process look like for you? +JOËL: I have a personal note-taking system that's loosely inspired by a system called Zettelkasten and also another similar system called evergreen notes. The idea is that when you learn things, you capture small atomic notes, so they are an idea in your note-taking application, and then you connect them. You create links between notes. And the idea is that there's a lot of value in making connections between notes that's almost as much part of the knowledge-creating experience as capturing single notes on their own. +And as you capture a bunch of these little, tiny notes over time and they become very interconnected, then you can start seeing, oh, this note from this one experience, this note from this conference talk, and this note from this book all connect together. And they maybe even make connections I hadn't seen, or I hadn't thought of individually in those moments. But now I see that they all kind of come together with a theme. And I might then combine those together to make a blog post or to use as the foundation for a conference talk. +AMANDA: That's really interesting. I like the concept of being able to capture bits of information at the time that they felt relevant without having to have an entire thesis in this note. Or that idea doesn't have to be fully fleshed out; it can become fleshed out later when you connect the dots. +JOËL: That's a really powerful concept. One of the big ideas that I picked up through this was that there are always byproducts of knowledge creation. So if I'm writing a blog post, there are always some things that I cut that didn't make it into the blog post because I'm trying to keep it focused. But those are still things that I learned, things that are valuable, that could be used for something else. +And so anytime I'm writing a blog post, preparing for a conference talk, learning some things in a debugging session by reading a book, there are always some things that I don't use necessarily immediately. But I can capture those little chunks, and eventually, I have enough of them that I can combine them together to make some kind of other work. +AMANDA: I'm really curious about your process of creating those notes. If you're reading a blog post, say, to learn a new topic and you're taking notes on that, how do you go from this concept that you're learning in the blog post to these really focused notes that can be combined in other ways? +JOËL: So the Zettelkasten approach suggests that you have two forms of notes, one it calls literature notes which are just sort of ideas you jot down as you are reading some work. You're reading a book or a blog post or watching a talk, and then, later on, you go and turn those into those atomic-separated, linked notes together, what Zettelkasten calls permanent notes. And so I'll often do that is just focus on the work itself and jot down some notes and then convert those later on into these smaller atomic chunks. +AMANDA: That concept of taking a larger theme and then actually spending the energy to distill that into a different kind of artifact that might be helpful later on is really interesting. And I don't do Zettelkasten note-taking, but I've also found that to be useful in other contexts as well. +JOËL: One thing that I sort of hold myself to is when I am writing those atomic notes is, I don't write them as bullet points. They're always written in prose and complete sentences. The title is usually a sort of thesis statement, a thing that I think is true or at least a thing that posits that could be true, and then a short paragraph expanding on that idea which I think helps cement a lot of information in my mind but also helps to give me little chunks of things that I can more or less copy-paste into an article and already have almost a rough draft of something I want to say. +Do you find that when you synthesize ideas into notes that you do something similar, or do you stick mostly to bullet points? +AMANDA: I think I might do a mixture of the two. I think procedurally, I use bullet points a lot, but I think those bullet points tend to be full sentences or several sentences together. I've definitely run up against some of the drawbacks of terseness, where they're less helpful when you refer back to it later. But I do like the visual cues that come with things like bullet points, or numbered lists, or even emoji and note-taking to be a visual cue of what I was thinking of or where I can find this later on. +JOËL: I love emoji; emoji is great. +AMANDA: I guess actually I've started using emoji as bullet points. That's something that I've found even to be helpful just with remembering or with grouping things thematically in my mind. And when I'm going back through my notes, I find it easier to find the information that I was looking for because it had a list, or an emoji, or an image, or something like that. +JOËL: Yeah, that makes it really easy to scan and pick out the things that you're looking for. It's almost like adding metadata to your notes. +AMANDA: Totally. +JOËL: That's a great tip. I should do that. +AMANDA: You can definitely run into the Figma problem of you then spend so much time finding the right emoji to be the bullet point that you forgot what you were doing, [laughs] but that's a problem for a different day. +JOËL: So this sort of Zettelkasten evergreen notes approach is a system that I use specifically to help me capture long-term thoughts about software that could eventually turn into content. So this is very much not a debugging note. It's not an exploratory note. It has a very particular purpose, which is why I write it in this particular way. +I'm curious; I know you have a lot of different systems that you use for your notes, Amanda. Is there one that you'd like to share with the audience? Maybe tell us a little bit about what the system is and why it's a good fit for the type of scenario that you'd like to use it in. +AMANDA: Sure. One situation that I found myself in recently is I have started taking classes on things that I'm interested in, development-related and non-development-related. And that's a formal structure that requires some note-taking that I haven't really done since I was in school. And the tools were very different back then as to what we had available to us for note-taking. It was basically Microsoft Word or bust. +So I have found myself having to develop a new note system for that kind of content delivery method, basically of watching a video and taking notes and having something that then makes sense outside of the context of sitting down and watching a video. So that has been a little bit of a process journey that I've been on the last couple of months. +JOËL: And what does your note-taking system look like? +AMANDA: So it's been a mix of things, actually. I started out just kind of brain-dumping as I went along with the instructor talking trying to type and keep up. And I found that very not scannable to look back on. I was looking for some more visual cues, and I didn't really have time to insert those visual cues as I was trying to keep up with a lecture essentially. +I then transitioned back to old school pen and paper, like, got myself a notebook and started writing in it. And obviously, that has some benefits of the free-formness, like, I'm not constrained by the offerings of any specific tool. But the trade-off for that is always that you have different notebooks for everything. And it's like, where's my X class notebook? +And so I've been trying to bring those two methods together into something that makes a little bit more sense for me and also bring in some of that synthesis process that you were talking about with your note-taking method of doing the full literature notes and then synthesizing them down into something a little bit more well-scoped for the particular piece of information. +JOËL: So you have like a two-step process then. +AMANDA: It did end up being a two-step process because one of the things that I found was the grouping of ideas that make sense when you're first learning a concept and the grouping of ideas that make sense when I'm revisiting that concept, later on, aren't necessarily the same. And so, keeping it in the original context doesn't necessarily help me recall the information when I'm referring back to my notes. +JOËL: That's really interesting. When you're writing it, it's going to be different than when you're reading it. +So we've been talking a lot about the purpose of different notes along the way, and you mentioned the word recall here. Do you use these notes mostly as a way to recall things that you would look back at them and try to remember, or are they more of a way to digest the material as you're going through it? +AMANDA: I think at the time that I'm writing them, they definitely served the purpose of helping me digest the information. But at some point, I probably want to be able to look back at them and remember the things that I learned and see if maybe they have new salience now that I have sat on them for a little bit. +JOËL: Hmmm, that's good. So it's valuable for both in different contexts. +AMANDA: Yeah, definitely. And one of the more surprising things that I've learned through that process has been that when I'm learning something, I really like a chronological kind of step-by-step through that process and building blocks of complexity that basically go one on top of the other. But then, once I've kind of made it to the end when I look back on it, I look back on those notes, and they're usually pretty thorough. They probably have a lot of details that aren't going to be top-level priority at the end. +But I didn't really have that concept of priority when I was first learning it. I was kind of grasping onto each bit of information, saying, "I'm going to scroll this away in case I need it later." And then when you get a better understanding of the full picture, you realize, okay, I'm glad that I know that, but it's not necessarily something that I'd want to look back on. So I really like having systems that then allow me to regroup that information once I have built out a fuller picture of what it is I'm trying to learn. +JOËL: Interesting. So the sort of digesting step that happens afterwards or the synthesis step, a lot of the value that you're adding there is by putting structure on a lot of the information you captured. +AMANDA: Yeah, I think putting structure and changing the structure, and not being afraid to change that structure to fit my new understanding in how I see this concept now instead of just how this concept was explained to me. +JOËL: So you mentioned that you'd initially used notebooks and paper and that that felt a little bit constraining in terms of organization. Is there any kind of software or apps that you like to use to organize your notes, and how do they fit in with your approach to note-taking? +AMANDA: I've been using Notion for the last few years. I found that that application works well with my visual preferences for note-taking. I think there's a lot of opportunity for visual cues that help me recall things, such as emoji and bullet points. And I like that I can do all of that by writing Markdown without then also having to read Markdown. +JOËL: Yeah, I definitely agree that a little visual change there where you can actually see the rendered Markdown is a nice quality-of-life improvement. +AMANDA: Absolutely. And I also think that the way that it turns Markdown into blocks that then you can rearrange has served me really well for that synthesis process of maybe this bullet point makes sense, and I want to keep it as is. But I want to rearrange it into these new themes that I'm seeing as I'm reviewing these things that I've learned. +JOËL: That's fascinating. So it has some really good tools for evolving your notes and reorganizing them, it sounds like. +AMANDA: I like that I can group my notes by concept, and notes can be subsets or sub-notes of other notes. And you can kind of move the individual notes in between those blocks pretty easily, which helps me rearrange things when I see different themes evolving. +JOËL: I've heard really good things about Notion, but I've not tried it myself. My app of choice so far has been Obsidian, which I really appreciate its focus on linking between notes. It doesn't have this concept of blocks where you can embed parts of notes as notes into other notes and things like that. But that has been okay for me because I keep my notes very small and atomic. But the focus on hyperlinking between notes has been really useful for me because, in my approach, it's all about the connections. +AMANDA: So, what does that process look like when you are referring back to all of these notes that are hyperlinked together? +JOËL: That's actually really important because the recall aspect is a big part of how you would use a note-taking system. For me, it's sort of like walking the graph. So I'll use search, or maybe I know a note that's in the general theme of what I care about, and then I'll just follow the links to other related articles or notes that talk about things that are related to it. And I might walk that graph three, four steps out in a few different directions. It's kind of like surfing Wikipedia. You find some entry point, and then you just follow the links until you have the material that you're interested in. +AMANDA: It sounds like creating a Wikipedia wormhole of your own. +JOËL: It kind of is. I guess, in a way, it's kind of like a little mini personal wiki where the articles are very, very condensed because I have that limitation that everything must be atomic. +Wow. So this has been a really fascinating conversation. I feel like one of the big takeaways that I have is that types of notes matter. Note-taking can take very different forms in different contexts. And the way you organize them would be vastly different; how long you care about them is also going to be different. +So going into a particular situation, knowing what sort of situation is this that I'm using notes and what is their purpose is going to be really helpful to think in terms of how I want to do my note-keeping. Whereas I think previously, I probably was just like, yeah, notes. You open a document, and you put in some bullet points. +AMANDA: I am definitely guilty of doing that as well. And I like the idea of having a purpose for your notes. You mentioned your purpose was ultimately to build a map that would produce content. And I really like how you have found a system that works really well for that purpose. And I'm going to keep thinking about how to be more intentional in what is the purpose of the notes that I'm taking in the future. +JOËL: Well, thank you so much for joining the conversation today. Where can people find you on the web? +AMANDA: Thanks so much for having me, Joël. You can find me @amandabeiner on Twitter. +JOËL: And we'll link to that in the show notes. And with that, let's wrap up. +The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Joël is joined by Amanda Beiner, a Senior Software Engineer at GitHub, who is known for her legendary well-organized notes. They talk about various types of notes: debugging, todos, mental stack, Zetelkasten/evergreen notes, notetaking apps and systems, and visual note-taking and diagramming too!

+ +
+ + + +

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. And today, I'm joined by Amanda Beiner, a Senior Software Engineer at GitHub.

+ +

AMANDA: Hey, Joël. Great to see you.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Amanda, what is new in your world?

+ +

AMANDA: Well, one thing I'm really excited about is that my team at GitHub is experimenting with how we're going to incorporate learning and sharing what we've learned with each other in new ways, and I'm really excited to see where people take that.

+ +

So, one of the things that we're thinking of is that we all get really busy, and we all have exciting projects that we're working on in the day-to-day, and sometimes it can be really hard to pull yourself away from them to do some learning that would be something that will probably help you in the long run. But every time we do do projects like that, people are really excited about it, and people like to collaborate. So we're just trying to figure out how we can make that a more regular thing because it's great for our whole team.

+ +

JOËL: I love that. Do you have a project or something that you've been getting into recently to learn?

+ +

AMANDA: Yeah. One of the things that I have been working on is that this is the first backend-focused role that I've had in my entire career. So I feel like I just kind of keep pulling back layers on how different forms of magic work. And I'm just trying to get closer to the metal of what is powering our databases. And that's something that I've been really excited to learn some more about.

+ +

JOËL: So it's digging into a lot of, like, Postgres and just general database theory.

+ +

AMANDA: Yeah. So for me, I've spent a lot of time at the Active Record layer as I have been settling into my role and figuring out what our domain models are that we care about. And I'm trying to get a little bit more into the questions of why did these tables end up looking the way that they do? Why are they normalized or denormalized where they are? And trying to get a better idea of the theory behind those decisions.

+ +

JOËL: And this is a new team that you've joined.

+ +

AMANDA: This is an existing team that I've joined a year ago now.

+ +

JOËL: So it sounds like you're dealing with a somewhat unfamiliar codebase. You're looking at a bunch of existing models and database tables. That can be a lot to process and understand when you first join a team. Do you have an approach that you like to use when you're looking at unknown code for the first time?

+ +

AMANDA: Yeah. I usually like to dive right in as much as I can, even if it's with a very small bug fix or something like that, something that allows me to just get my hands dirty from the beginning and poke around what models I'm dealing with, and maybe some of the adjacent ones that I don't need to know about now but might want to come back to later.

+ +

JOËL: One thing that I find is really helpful for me are diagramming and note-taking. So if it's something like a database table or ActiveRecord models that I'm not familiar with, if it's more than maybe two or three, which is probably the most I can keep in my head, I have to start drawing some kind of like an entity-relationship diagram or maybe even just a bulleted list somewhere where it's like here are the things and how they connect to each other. Otherwise, I’m like, I don't know, I don't have enough RAM in my brain for that.

+ +

AMANDA: That sounds like a really helpful approach. How do you approach creating these diagrams?

+ +

JOËL: Occasionally, I will just draw it out by hand with pen and paper. But more recently, I've been using tools like Mermaid.js and specifically the website mermaid.live that allows you to just put in some names and arrows, and it will build out a diagram for you. And that's been really helpful to explore and understand what is going on with different entities that relate to each other.

+ +

AMANDA: I've used Mermaid.js recently, and I really enjoyed it as well. I found that writing something that lets me write words or something somewhat like words and takes care of the drawing for me is probably best for everyone involved.

+ +

JOËL: Yeah, that's a good point. It's kind of like Markdown, the ability to just write a little bit of text and move on and not worry about the size of boxes or the shape of the arrows or whatever. It helps you to really stay in that flow and keep moving.

+ +

AMANDA: I definitely agree. I feel like I can't have been the only person that somehow ended up very deep into the Figma documentation because I didn't quite know how to do what I was supposed to do, and I forgot what I was trying to draw in the first place.

+ +

JOËL: Right. It's really easy to put your designer hat on and want to make something like a beautiful diagram when this is really more of a capturing your state of mind. It's a rough note, not something you're necessarily going to publish. So, in addition to visuals, do you find yourself taking a lot of notes when you're exploring code or debugging code?

+ +

AMANDA: Yeah. I feel like I tend to jot a lot of things down, maybe class names, maybe some links to PRs or issues, or anywhere that might have context about what I'm looking at and how it got in that way. At this point in the process, it feels my notes usually feel like a bit of a bullet point list that doesn't quite make sense to me yet but maybe will get some shaping later.

+ +

JOËL: What kind of things do you tend to record in those notes?

+ +

AMANDA: I think one of the things that I'm usually trying to get out of those notes is just a snapshot of what I'm trying to accomplish at the time that I'm creating them. What's the bug that I'm trying to solve, and how did I get into this rabbit hole? So that if it ends up being the wrong one, I can follow my breadcrumbs back out and start a different way.

+ +

JOËL: Oh, that is really powerful. I love the imagery you used there of following breadcrumbs. And I feel like that's sometimes something I wish I had when I'm either exploring a particular code path or trying to find a bug. And at some point, I've gone a pretty long path, and I need to back up. And I don't remember exactly where I was or how I got to this point, especially if I've gone down a path, backtracked a little bit, gone down a different path, backtracked, gone further down a third path. And so having breadcrumbs, I think, is a really valuable thing that I wish I did more when I was debugging.

+ +

AMANDA: Yeah. And one of the most helpful breadcrumbs that I found is just a list of questions. What was the question that I was trying to answer when I opened this file or looked at this method, and did it help me solve that question or answer that question? And if the answer is no, then I can refer back to what the question was and try to think about what else might help me solve that question.

+ +

JOËL: I also love that. It's really easy to get sidetracked by other questions or other ideas when exploring or debugging. And sometimes I find that half hour later, I haven't answered the original question I came here to answer, and I kind of haven't even tried. And so, maybe writing down my questions before I go down a path would help me stay more focused during a debugging session rather than just trying to keep it all in my head.

+ +

AMANDA: I very much relate to getting nerd sniped by something that looks interesting but ultimately doesn't solve the original problem that you were trying to.

+ +

JOËL: This even happens to me when I'm pair programming. And so we'll say out loud the question we're trying to answer is this; let's open this file. And then you go into it, and you're like, oh, now that is an unusual line of code right there.

+ +

AMANDA: [laughs]

+ +

JOËL: I wonder why they're doing that. Let me check the git blame on this line. Oh, it's from 2015?

+ +

AMANDA: [laughs]

+ +

JOËL: I wonder what was happening there. Was that part of a Rails upgrade? And then, at some point, the other person has to interject and be like, "That's all fascinating, but I think the question we're actually trying to answer is..." and we get back on track.

+ +

AMANDA: I feel like that's a really good opportunity, maybe for a different kind of note of just interesting curiosities in a given codebase. I find that one of the skills that I'm trying to get better at is, rather than building a repository of information or answers to questions, just building a mental map of where the information I'm trying to find lives so that when someone asks me a question or when I have to solve something I don't necessarily know the answer, but I just know the resource to find that will point me in the direction of that answer.

+ +

And I feel like those kinds of explorations are really helpful for building out that mental model, even if it may be at the time seems like an unrelated rabbit hole.

+ +

JOËL: So this kind of note is a bit more permanent than a bread crumb style note would be.

+ +

AMANDA: Yeah, maybe. And I guess maybe it's less of a note, and it feels kind of like an index.

+ +

JOËL: Hmmm.

+ +

AMANDA: Like something that's connecting other pieces of information.

+ +

JOËL: That's really interesting. It's got me thinking about the fact that note-taking can be very different in different situations and for different purposes. So we've talked a little bit about debugging. I think we've mixed debugging and exploration. Maybe those two are not the same, and you treat notes differently. Actually, do you treat those two as different, or do you have different approaches to note-taking when you're exploring a new codebase versus debugging a particular problem?

+ +

AMANDA: I think that those kinds of notes could probably be a little bit different because I think when I'm onboarding onto a new codebase, I'm trying to cast a pretty wide net and give some overall information about what these things do that by the time I'm very deep in debugging, it might be information that I already know very well. So I feel like maybe debugging notes are a little bit more procedural. They are a little bit more I did X, and I did Y, and I did Z, and these were the questions.

+ +

And the introductory notes to a new codebase might be more along the lines of this is what this model does, and stuff that will eventually become second nature and might be useful to pass off to someone else who's onboarding but which I might myself not refer back to after a certain amount of time.

+ +

JOËL: I see. That's an interesting point because not only might the type of notes you take be different in different scenarios, but even their lifespan could be different. The value of a debugging note, that sort of breadcrumbs, might really only be that useful for a few hours or a couple of days. I can imagine notes you're taking while you're exploring a codebase those might be helpful for a much longer period and, as you said, maybe in passing them on to someone else when they're joining a team.

+ +

AMANDA: So that makes me think of whether the debugging notes should be as short-lived as I'm making them sound because I feel like there are times where you know you've debugged something previously, but you didn't keep the notes. Maybe they were just on a scrap of paper, and now they're gone. And I feel like I'd like to do a better job of digesting those notes a little bit better and eventually turning them into something that can be a little bit longer-lived.

+ +

JOËL: That's fair. I find that, especially for debugging, I like to capture a lot of what was in my notes in the eventual commit message for the fix. Of course, my random breadcrumbs probably don't make sense in the commit message, but a lot of what I have learned along the way often is helpful.

+ +

AMANDA: That's a really good point. I hadn't thought of commit messages as notes, but you're right; they totally are.

+ +

JOËL: One thing I've done is I've sort of taken this idea to the extreme. I was debugging some weird database table ActiveRecord model interactions, and the modeling was just a little bit unusual. There were multiple sources of truth in the relationships. And there were enough models that I struggled to really understand what was going on.

+ +

And so I drew an entity-relationship diagram. And I felt that that was important to understand for people reviewing the code but also anybody looking back at the commit later on. So I used a tool called Monodraw, which allows you to draw simple diagrams as ASCII art. And so, I have a little ASCII art ERD in my commit message.

+ +

AMANDA: That's incredible. I feel like if I were a developer git logging and I saw that commit message, I would be both thrilled and terrified of what exactly I was diving into in the git blame. [laughs]

+ +

JOËL: Definitely both, definitely both. But I have referred back maybe a few months later. Like you said, I had to refer back to that commit because a similar bug had cropped up somewhere else. And I knew that that commit had information that I had gathered that would make the debugging experience easier.

+ +

AMANDA: I guess the commit message is a really good example of having a note that's very closely tied to its context. Like, it's in the context of like a commit, which is a set of changes at a point in time, and it's really well situated in there. What do you think about the trade-offs of having that as part of a commit message versus something like some other sort of documentation where something like that could live?

+ +

JOËL: I guess it depends on how you think you're going to use it in the future. Again, for debugging things, it feels like you don't often need to refer back to them, so I don't think you would want to just dump that on a wiki somewhere. It probably makes sense to have that either in just a collection of debugging notes that you have or that you could then dig into if you needed or in a commit message, something like that. But maybe some of the things that you learned along the way could be pulled out and turned into something that lives somewhere else that's maybe less of a note at that point and more of a publication.

+ +

AMANDA: That sounds like a fine line between note and publication.

+ +

JOËL: Perhaps it's an artificial line that I'm making.

+ +

AMANDA: [laughs]

+ +

JOËL: But yeah, I guess the idea is that sometimes I will look at my own debugging notes and try to turn them into something like either a wiki page for a particular codebase or potentially even a blog post on the thoughtbot blog, something that I've been able to synthesize out of the notes there. But now you've kind of gone a few steps beyond the underlying raw notes.

+ +

AMANDA: I'm interested in your thoughts on that synthesis of notes into how does something go from a commit message into a blog? What does that process look like for you?

+ +

JOËL: I have a personal note-taking system that's loosely inspired by a system called Zettelkasten and also another similar system called evergreen notes. The idea is that when you learn things, you capture small atomic notes, so they are an idea in your note-taking application, and then you connect them. You create links between notes. And the idea is that there's a lot of value in making connections between notes that's almost as much part of the knowledge-creating experience as capturing single notes on their own.

+ +

And as you capture a bunch of these little, tiny notes over time and they become very interconnected, then you can start seeing, oh, this note from this one experience, this note from this conference talk, and this note from this book all connect together. And they maybe even make connections I hadn't seen, or I hadn't thought of individually in those moments. But now I see that they all kind of come together with a theme. And I might then combine those together to make a blog post or to use as the foundation for a conference talk.

+ +

AMANDA: That's really interesting. I like the concept of being able to capture bits of information at the time that they felt relevant without having to have an entire thesis in this note. Or that idea doesn't have to be fully fleshed out; it can become fleshed out later when you connect the dots.

+ +

JOËL: That's a really powerful concept. One of the big ideas that I picked up through this was that there are always byproducts of knowledge creation. So if I'm writing a blog post, there are always some things that I cut that didn't make it into the blog post because I'm trying to keep it focused. But those are still things that I learned, things that are valuable, that could be used for something else.

+ +

And so anytime I'm writing a blog post, preparing for a conference talk, learning some things in a debugging session by reading a book, there are always some things that I don't use necessarily immediately. But I can capture those little chunks, and eventually, I have enough of them that I can combine them together to make some kind of other work.

+ +

AMANDA: I'm really curious about your process of creating those notes. If you're reading a blog post, say, to learn a new topic and you're taking notes on that, how do you go from this concept that you're learning in the blog post to these really focused notes that can be combined in other ways?

+ +

JOËL: So the Zettelkasten approach suggests that you have two forms of notes, one it calls literature notes which are just sort of ideas you jot down as you are reading some work. You're reading a book or a blog post or watching a talk, and then, later on, you go and turn those into those atomic-separated, linked notes together, what Zettelkasten calls permanent notes. And so I'll often do that is just focus on the work itself and jot down some notes and then convert those later on into these smaller atomic chunks.

+ +

AMANDA: That concept of taking a larger theme and then actually spending the energy to distill that into a different kind of artifact that might be helpful later on is really interesting. And I don't do Zettelkasten note-taking, but I've also found that to be useful in other contexts as well.

+ +

JOËL: One thing that I sort of hold myself to is when I am writing those atomic notes is, I don't write them as bullet points. They're always written in prose and complete sentences. The title is usually a sort of thesis statement, a thing that I think is true or at least a thing that posits that could be true, and then a short paragraph expanding on that idea which I think helps cement a lot of information in my mind but also helps to give me little chunks of things that I can more or less copy-paste into an article and already have almost a rough draft of something I want to say.

+ +

Do you find that when you synthesize ideas into notes that you do something similar, or do you stick mostly to bullet points?

+ +

AMANDA: I think I might do a mixture of the two. I think procedurally, I use bullet points a lot, but I think those bullet points tend to be full sentences or several sentences together. I've definitely run up against some of the drawbacks of terseness, where they're less helpful when you refer back to it later. But I do like the visual cues that come with things like bullet points, or numbered lists, or even emoji and note-taking to be a visual cue of what I was thinking of or where I can find this later on.

+ +

JOËL: I love emoji; emoji is great.

+ +

AMANDA: I guess actually I've started using emoji as bullet points. That's something that I've found even to be helpful just with remembering or with grouping things thematically in my mind. And when I'm going back through my notes, I find it easier to find the information that I was looking for because it had a list, or an emoji, or an image, or something like that.

+ +

JOËL: Yeah, that makes it really easy to scan and pick out the things that you're looking for. It's almost like adding metadata to your notes.

+ +

AMANDA: Totally.

+ +

JOËL: That's a great tip. I should do that.

+ +

AMANDA: You can definitely run into the Figma problem of you then spend so much time finding the right emoji to be the bullet point that you forgot what you were doing, [laughs] but that's a problem for a different day.

+ +

JOËL: So this sort of Zettelkasten evergreen notes approach is a system that I use specifically to help me capture long-term thoughts about software that could eventually turn into content. So this is very much not a debugging note. It's not an exploratory note. It has a very particular purpose, which is why I write it in this particular way.

+ +

I'm curious; I know you have a lot of different systems that you use for your notes, Amanda. Is there one that you'd like to share with the audience? Maybe tell us a little bit about what the system is and why it's a good fit for the type of scenario that you'd like to use it in.

+ +

AMANDA: Sure. One situation that I found myself in recently is I have started taking classes on things that I'm interested in, development-related and non-development-related. And that's a formal structure that requires some note-taking that I haven't really done since I was in school. And the tools were very different back then as to what we had available to us for note-taking. It was basically Microsoft Word or bust.

+ +

So I have found myself having to develop a new note system for that kind of content delivery method, basically of watching a video and taking notes and having something that then makes sense outside of the context of sitting down and watching a video. So that has been a little bit of a process journey that I've been on the last couple of months.

+ +

JOËL: And what does your note-taking system look like?

+ +

AMANDA: So it's been a mix of things, actually. I started out just kind of brain-dumping as I went along with the instructor talking trying to type and keep up. And I found that very not scannable to look back on. I was looking for some more visual cues, and I didn't really have time to insert those visual cues as I was trying to keep up with a lecture essentially.

+ +

I then transitioned back to old school pen and paper, like, got myself a notebook and started writing in it. And obviously, that has some benefits of the free-formness, like, I'm not constrained by the offerings of any specific tool. But the trade-off for that is always that you have different notebooks for everything. And it's like, where's my X class notebook?

+ +

And so I've been trying to bring those two methods together into something that makes a little bit more sense for me and also bring in some of that synthesis process that you were talking about with your note-taking method of doing the full literature notes and then synthesizing them down into something a little bit more well-scoped for the particular piece of information.

+ +

JOËL: So you have like a two-step process then.

+ +

AMANDA: It did end up being a two-step process because one of the things that I found was the grouping of ideas that make sense when you're first learning a concept and the grouping of ideas that make sense when I'm revisiting that concept, later on, aren't necessarily the same. And so, keeping it in the original context doesn't necessarily help me recall the information when I'm referring back to my notes.

+ +

JOËL: That's really interesting. When you're writing it, it's going to be different than when you're reading it.

+ +

So we've been talking a lot about the purpose of different notes along the way, and you mentioned the word recall here. Do you use these notes mostly as a way to recall things that you would look back at them and try to remember, or are they more of a way to digest the material as you're going through it?

+ +

AMANDA: I think at the time that I'm writing them, they definitely served the purpose of helping me digest the information. But at some point, I probably want to be able to look back at them and remember the things that I learned and see if maybe they have new salience now that I have sat on them for a little bit.

+ +

JOËL: Hmmm, that's good. So it's valuable for both in different contexts.

+ +

AMANDA: Yeah, definitely. And one of the more surprising things that I've learned through that process has been that when I'm learning something, I really like a chronological kind of step-by-step through that process and building blocks of complexity that basically go one on top of the other. But then, once I've kind of made it to the end when I look back on it, I look back on those notes, and they're usually pretty thorough. They probably have a lot of details that aren't going to be top-level priority at the end.

+ +

But I didn't really have that concept of priority when I was first learning it. I was kind of grasping onto each bit of information, saying, "I'm going to scroll this away in case I need it later." And then when you get a better understanding of the full picture, you realize, okay, I'm glad that I know that, but it's not necessarily something that I'd want to look back on. So I really like having systems that then allow me to regroup that information once I have built out a fuller picture of what it is I'm trying to learn.

+ +

JOËL: Interesting. So the sort of digesting step that happens afterwards or the synthesis step, a lot of the value that you're adding there is by putting structure on a lot of the information you captured.

+ +

AMANDA: Yeah, I think putting structure and changing the structure, and not being afraid to change that structure to fit my new understanding in how I see this concept now instead of just how this concept was explained to me.

+ +

JOËL: So you mentioned that you'd initially used notebooks and paper and that that felt a little bit constraining in terms of organization. Is there any kind of software or apps that you like to use to organize your notes, and how do they fit in with your approach to note-taking?

+ +

AMANDA: I've been using Notion for the last few years. I found that that application works well with my visual preferences for note-taking. I think there's a lot of opportunity for visual cues that help me recall things, such as emoji and bullet points. And I like that I can do all of that by writing Markdown without then also having to read Markdown.

+ +

JOËL: Yeah, I definitely agree that a little visual change there where you can actually see the rendered Markdown is a nice quality-of-life improvement.

+ +

AMANDA: Absolutely. And I also think that the way that it turns Markdown into blocks that then you can rearrange has served me really well for that synthesis process of maybe this bullet point makes sense, and I want to keep it as is. But I want to rearrange it into these new themes that I'm seeing as I'm reviewing these things that I've learned.

+ +

JOËL: That's fascinating. So it has some really good tools for evolving your notes and reorganizing them, it sounds like.

+ +

AMANDA: I like that I can group my notes by concept, and notes can be subsets or sub-notes of other notes. And you can kind of move the individual notes in between those blocks pretty easily, which helps me rearrange things when I see different themes evolving.

+ +

JOËL: I've heard really good things about Notion, but I've not tried it myself. My app of choice so far has been Obsidian, which I really appreciate its focus on linking between notes. It doesn't have this concept of blocks where you can embed parts of notes as notes into other notes and things like that. But that has been okay for me because I keep my notes very small and atomic. But the focus on hyperlinking between notes has been really useful for me because, in my approach, it's all about the connections.

+ +

AMANDA: So, what does that process look like when you are referring back to all of these notes that are hyperlinked together?

+ +

JOËL: That's actually really important because the recall aspect is a big part of how you would use a note-taking system. For me, it's sort of like walking the graph. So I'll use search, or maybe I know a note that's in the general theme of what I care about, and then I'll just follow the links to other related articles or notes that talk about things that are related to it. And I might walk that graph three, four steps out in a few different directions. It's kind of like surfing Wikipedia. You find some entry point, and then you just follow the links until you have the material that you're interested in.

+ +

AMANDA: It sounds like creating a Wikipedia wormhole of your own.

+ +

JOËL: It kind of is. I guess, in a way, it's kind of like a little mini personal wiki where the articles are very, very condensed because I have that limitation that everything must be atomic.

+ +

Wow. So this has been a really fascinating conversation. I feel like one of the big takeaways that I have is that types of notes matter. Note-taking can take very different forms in different contexts. And the way you organize them would be vastly different; how long you care about them is also going to be different.

+ +

So going into a particular situation, knowing what sort of situation is this that I'm using notes and what is their purpose is going to be really helpful to think in terms of how I want to do my note-keeping. Whereas I think previously, I probably was just like, yeah, notes. You open a document, and you put in some bullet points.

+ +

AMANDA: I am definitely guilty of doing that as well. And I like the idea of having a purpose for your notes. You mentioned your purpose was ultimately to build a map that would produce content. And I really like how you have found a system that works really well for that purpose. And I'm going to keep thinking about how to be more intentional in what is the purpose of the notes that I'm taking in the future.

+ +

JOËL: Well, thank you so much for joining the conversation today. Where can people find you on the web?

+ +

AMANDA: Thanks so much for having me, Joël. You can find me @amandabeiner on Twitter.

+ +

JOËL: And we'll link to that in the show notes. And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Joël is joined by Amanda Beiner, a Senior Software Engineer at GitHub, who is known for her legendary well-organized notes. They talk about various types of notes: debugging, todos, mental stack, Zetelkasten/evergreen notes, notetaking apps and systems, and visual note-taking and diagramming too!

+ +
+ + + +

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. And today, I'm joined by Amanda Beiner, a Senior Software Engineer at GitHub.

+ +

AMANDA: Hey, Joël. Great to see you.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. So, Amanda, what is new in your world?

+ +

AMANDA: Well, one thing I'm really excited about is that my team at GitHub is experimenting with how we're going to incorporate learning and sharing what we've learned with each other in new ways, and I'm really excited to see where people take that.

+ +

So, one of the things that we're thinking of is that we all get really busy, and we all have exciting projects that we're working on in the day-to-day, and sometimes it can be really hard to pull yourself away from them to do some learning that would be something that will probably help you in the long run. But every time we do do projects like that, people are really excited about it, and people like to collaborate. So we're just trying to figure out how we can make that a more regular thing because it's great for our whole team.

+ +

JOËL: I love that. Do you have a project or something that you've been getting into recently to learn?

+ +

AMANDA: Yeah. One of the things that I have been working on is that this is the first backend-focused role that I've had in my entire career. So I feel like I just kind of keep pulling back layers on how different forms of magic work. And I'm just trying to get closer to the metal of what is powering our databases. And that's something that I've been really excited to learn some more about.

+ +

JOËL: So it's digging into a lot of, like, Postgres and just general database theory.

+ +

AMANDA: Yeah. So for me, I've spent a lot of time at the Active Record layer as I have been settling into my role and figuring out what our domain models are that we care about. And I'm trying to get a little bit more into the questions of why did these tables end up looking the way that they do? Why are they normalized or denormalized where they are? And trying to get a better idea of the theory behind those decisions.

+ +

JOËL: And this is a new team that you've joined.

+ +

AMANDA: This is an existing team that I've joined a year ago now.

+ +

JOËL: So it sounds like you're dealing with a somewhat unfamiliar codebase. You're looking at a bunch of existing models and database tables. That can be a lot to process and understand when you first join a team. Do you have an approach that you like to use when you're looking at unknown code for the first time?

+ +

AMANDA: Yeah. I usually like to dive right in as much as I can, even if it's with a very small bug fix or something like that, something that allows me to just get my hands dirty from the beginning and poke around what models I'm dealing with, and maybe some of the adjacent ones that I don't need to know about now but might want to come back to later.

+ +

JOËL: One thing that I find is really helpful for me are diagramming and note-taking. So if it's something like a database table or ActiveRecord models that I'm not familiar with, if it's more than maybe two or three, which is probably the most I can keep in my head, I have to start drawing some kind of like an entity-relationship diagram or maybe even just a bulleted list somewhere where it's like here are the things and how they connect to each other. Otherwise, I’m like, I don't know, I don't have enough RAM in my brain for that.

+ +

AMANDA: That sounds like a really helpful approach. How do you approach creating these diagrams?

+ +

JOËL: Occasionally, I will just draw it out by hand with pen and paper. But more recently, I've been using tools like Mermaid.js and specifically the website mermaid.live that allows you to just put in some names and arrows, and it will build out a diagram for you. And that's been really helpful to explore and understand what is going on with different entities that relate to each other.

+ +

AMANDA: I've used Mermaid.js recently, and I really enjoyed it as well. I found that writing something that lets me write words or something somewhat like words and takes care of the drawing for me is probably best for everyone involved.

+ +

JOËL: Yeah, that's a good point. It's kind of like Markdown, the ability to just write a little bit of text and move on and not worry about the size of boxes or the shape of the arrows or whatever. It helps you to really stay in that flow and keep moving.

+ +

AMANDA: I definitely agree. I feel like I can't have been the only person that somehow ended up very deep into the Figma documentation because I didn't quite know how to do what I was supposed to do, and I forgot what I was trying to draw in the first place.

+ +

JOËL: Right. It's really easy to put your designer hat on and want to make something like a beautiful diagram when this is really more of a capturing your state of mind. It's a rough note, not something you're necessarily going to publish. So, in addition to visuals, do you find yourself taking a lot of notes when you're exploring code or debugging code?

+ +

AMANDA: Yeah. I feel like I tend to jot a lot of things down, maybe class names, maybe some links to PRs or issues, or anywhere that might have context about what I'm looking at and how it got in that way. At this point in the process, it feels my notes usually feel like a bit of a bullet point list that doesn't quite make sense to me yet but maybe will get some shaping later.

+ +

JOËL: What kind of things do you tend to record in those notes?

+ +

AMANDA: I think one of the things that I'm usually trying to get out of those notes is just a snapshot of what I'm trying to accomplish at the time that I'm creating them. What's the bug that I'm trying to solve, and how did I get into this rabbit hole? So that if it ends up being the wrong one, I can follow my breadcrumbs back out and start a different way.

+ +

JOËL: Oh, that is really powerful. I love the imagery you used there of following breadcrumbs. And I feel like that's sometimes something I wish I had when I'm either exploring a particular code path or trying to find a bug. And at some point, I've gone a pretty long path, and I need to back up. And I don't remember exactly where I was or how I got to this point, especially if I've gone down a path, backtracked a little bit, gone down a different path, backtracked, gone further down a third path. And so having breadcrumbs, I think, is a really valuable thing that I wish I did more when I was debugging.

+ +

AMANDA: Yeah. And one of the most helpful breadcrumbs that I found is just a list of questions. What was the question that I was trying to answer when I opened this file or looked at this method, and did it help me solve that question or answer that question? And if the answer is no, then I can refer back to what the question was and try to think about what else might help me solve that question.

+ +

JOËL: I also love that. It's really easy to get sidetracked by other questions or other ideas when exploring or debugging. And sometimes I find that half hour later, I haven't answered the original question I came here to answer, and I kind of haven't even tried. And so, maybe writing down my questions before I go down a path would help me stay more focused during a debugging session rather than just trying to keep it all in my head.

+ +

AMANDA: I very much relate to getting nerd sniped by something that looks interesting but ultimately doesn't solve the original problem that you were trying to.

+ +

JOËL: This even happens to me when I'm pair programming. And so we'll say out loud the question we're trying to answer is this; let's open this file. And then you go into it, and you're like, oh, now that is an unusual line of code right there.

+ +

AMANDA: [laughs]

+ +

JOËL: I wonder why they're doing that. Let me check the git blame on this line. Oh, it's from 2015?

+ +

AMANDA: [laughs]

+ +

JOËL: I wonder what was happening there. Was that part of a Rails upgrade? And then, at some point, the other person has to interject and be like, "That's all fascinating, but I think the question we're actually trying to answer is..." and we get back on track.

+ +

AMANDA: I feel like that's a really good opportunity, maybe for a different kind of note of just interesting curiosities in a given codebase. I find that one of the skills that I'm trying to get better at is, rather than building a repository of information or answers to questions, just building a mental map of where the information I'm trying to find lives so that when someone asks me a question or when I have to solve something I don't necessarily know the answer, but I just know the resource to find that will point me in the direction of that answer.

+ +

And I feel like those kinds of explorations are really helpful for building out that mental model, even if it may be at the time seems like an unrelated rabbit hole.

+ +

JOËL: So this kind of note is a bit more permanent than a bread crumb style note would be.

+ +

AMANDA: Yeah, maybe. And I guess maybe it's less of a note, and it feels kind of like an index.

+ +

JOËL: Hmmm.

+ +

AMANDA: Like something that's connecting other pieces of information.

+ +

JOËL: That's really interesting. It's got me thinking about the fact that note-taking can be very different in different situations and for different purposes. So we've talked a little bit about debugging. I think we've mixed debugging and exploration. Maybe those two are not the same, and you treat notes differently. Actually, do you treat those two as different, or do you have different approaches to note-taking when you're exploring a new codebase versus debugging a particular problem?

+ +

AMANDA: I think that those kinds of notes could probably be a little bit different because I think when I'm onboarding onto a new codebase, I'm trying to cast a pretty wide net and give some overall information about what these things do that by the time I'm very deep in debugging, it might be information that I already know very well. So I feel like maybe debugging notes are a little bit more procedural. They are a little bit more I did X, and I did Y, and I did Z, and these were the questions.

+ +

And the introductory notes to a new codebase might be more along the lines of this is what this model does, and stuff that will eventually become second nature and might be useful to pass off to someone else who's onboarding but which I might myself not refer back to after a certain amount of time.

+ +

JOËL: I see. That's an interesting point because not only might the type of notes you take be different in different scenarios, but even their lifespan could be different. The value of a debugging note, that sort of breadcrumbs, might really only be that useful for a few hours or a couple of days. I can imagine notes you're taking while you're exploring a codebase those might be helpful for a much longer period and, as you said, maybe in passing them on to someone else when they're joining a team.

+ +

AMANDA: So that makes me think of whether the debugging notes should be as short-lived as I'm making them sound because I feel like there are times where you know you've debugged something previously, but you didn't keep the notes. Maybe they were just on a scrap of paper, and now they're gone. And I feel like I'd like to do a better job of digesting those notes a little bit better and eventually turning them into something that can be a little bit longer-lived.

+ +

JOËL: That's fair. I find that, especially for debugging, I like to capture a lot of what was in my notes in the eventual commit message for the fix. Of course, my random breadcrumbs probably don't make sense in the commit message, but a lot of what I have learned along the way often is helpful.

+ +

AMANDA: That's a really good point. I hadn't thought of commit messages as notes, but you're right; they totally are.

+ +

JOËL: One thing I've done is I've sort of taken this idea to the extreme. I was debugging some weird database table ActiveRecord model interactions, and the modeling was just a little bit unusual. There were multiple sources of truth in the relationships. And there were enough models that I struggled to really understand what was going on.

+ +

And so I drew an entity-relationship diagram. And I felt that that was important to understand for people reviewing the code but also anybody looking back at the commit later on. So I used a tool called Monodraw, which allows you to draw simple diagrams as ASCII art. And so, I have a little ASCII art ERD in my commit message.

+ +

AMANDA: That's incredible. I feel like if I were a developer git logging and I saw that commit message, I would be both thrilled and terrified of what exactly I was diving into in the git blame. [laughs]

+ +

JOËL: Definitely both, definitely both. But I have referred back maybe a few months later. Like you said, I had to refer back to that commit because a similar bug had cropped up somewhere else. And I knew that that commit had information that I had gathered that would make the debugging experience easier.

+ +

AMANDA: I guess the commit message is a really good example of having a note that's very closely tied to its context. Like, it's in the context of like a commit, which is a set of changes at a point in time, and it's really well situated in there. What do you think about the trade-offs of having that as part of a commit message versus something like some other sort of documentation where something like that could live?

+ +

JOËL: I guess it depends on how you think you're going to use it in the future. Again, for debugging things, it feels like you don't often need to refer back to them, so I don't think you would want to just dump that on a wiki somewhere. It probably makes sense to have that either in just a collection of debugging notes that you have or that you could then dig into if you needed or in a commit message, something like that. But maybe some of the things that you learned along the way could be pulled out and turned into something that lives somewhere else that's maybe less of a note at that point and more of a publication.

+ +

AMANDA: That sounds like a fine line between note and publication.

+ +

JOËL: Perhaps it's an artificial line that I'm making.

+ +

AMANDA: [laughs]

+ +

JOËL: But yeah, I guess the idea is that sometimes I will look at my own debugging notes and try to turn them into something like either a wiki page for a particular codebase or potentially even a blog post on the thoughtbot blog, something that I've been able to synthesize out of the notes there. But now you've kind of gone a few steps beyond the underlying raw notes.

+ +

AMANDA: I'm interested in your thoughts on that synthesis of notes into how does something go from a commit message into a blog? What does that process look like for you?

+ +

JOËL: I have a personal note-taking system that's loosely inspired by a system called Zettelkasten and also another similar system called evergreen notes. The idea is that when you learn things, you capture small atomic notes, so they are an idea in your note-taking application, and then you connect them. You create links between notes. And the idea is that there's a lot of value in making connections between notes that's almost as much part of the knowledge-creating experience as capturing single notes on their own.

+ +

And as you capture a bunch of these little, tiny notes over time and they become very interconnected, then you can start seeing, oh, this note from this one experience, this note from this conference talk, and this note from this book all connect together. And they maybe even make connections I hadn't seen, or I hadn't thought of individually in those moments. But now I see that they all kind of come together with a theme. And I might then combine those together to make a blog post or to use as the foundation for a conference talk.

+ +

AMANDA: That's really interesting. I like the concept of being able to capture bits of information at the time that they felt relevant without having to have an entire thesis in this note. Or that idea doesn't have to be fully fleshed out; it can become fleshed out later when you connect the dots.

+ +

JOËL: That's a really powerful concept. One of the big ideas that I picked up through this was that there are always byproducts of knowledge creation. So if I'm writing a blog post, there are always some things that I cut that didn't make it into the blog post because I'm trying to keep it focused. But those are still things that I learned, things that are valuable, that could be used for something else.

+ +

And so anytime I'm writing a blog post, preparing for a conference talk, learning some things in a debugging session by reading a book, there are always some things that I don't use necessarily immediately. But I can capture those little chunks, and eventually, I have enough of them that I can combine them together to make some kind of other work.

+ +

AMANDA: I'm really curious about your process of creating those notes. If you're reading a blog post, say, to learn a new topic and you're taking notes on that, how do you go from this concept that you're learning in the blog post to these really focused notes that can be combined in other ways?

+ +

JOËL: So the Zettelkasten approach suggests that you have two forms of notes, one it calls literature notes which are just sort of ideas you jot down as you are reading some work. You're reading a book or a blog post or watching a talk, and then, later on, you go and turn those into those atomic-separated, linked notes together, what Zettelkasten calls permanent notes. And so I'll often do that is just focus on the work itself and jot down some notes and then convert those later on into these smaller atomic chunks.

+ +

AMANDA: That concept of taking a larger theme and then actually spending the energy to distill that into a different kind of artifact that might be helpful later on is really interesting. And I don't do Zettelkasten note-taking, but I've also found that to be useful in other contexts as well.

+ +

JOËL: One thing that I sort of hold myself to is when I am writing those atomic notes is, I don't write them as bullet points. They're always written in prose and complete sentences. The title is usually a sort of thesis statement, a thing that I think is true or at least a thing that posits that could be true, and then a short paragraph expanding on that idea which I think helps cement a lot of information in my mind but also helps to give me little chunks of things that I can more or less copy-paste into an article and already have almost a rough draft of something I want to say.

+ +

Do you find that when you synthesize ideas into notes that you do something similar, or do you stick mostly to bullet points?

+ +

AMANDA: I think I might do a mixture of the two. I think procedurally, I use bullet points a lot, but I think those bullet points tend to be full sentences or several sentences together. I've definitely run up against some of the drawbacks of terseness, where they're less helpful when you refer back to it later. But I do like the visual cues that come with things like bullet points, or numbered lists, or even emoji and note-taking to be a visual cue of what I was thinking of or where I can find this later on.

+ +

JOËL: I love emoji; emoji is great.

+ +

AMANDA: I guess actually I've started using emoji as bullet points. That's something that I've found even to be helpful just with remembering or with grouping things thematically in my mind. And when I'm going back through my notes, I find it easier to find the information that I was looking for because it had a list, or an emoji, or an image, or something like that.

+ +

JOËL: Yeah, that makes it really easy to scan and pick out the things that you're looking for. It's almost like adding metadata to your notes.

+ +

AMANDA: Totally.

+ +

JOËL: That's a great tip. I should do that.

+ +

AMANDA: You can definitely run into the Figma problem of you then spend so much time finding the right emoji to be the bullet point that you forgot what you were doing, [laughs] but that's a problem for a different day.

+ +

JOËL: So this sort of Zettelkasten evergreen notes approach is a system that I use specifically to help me capture long-term thoughts about software that could eventually turn into content. So this is very much not a debugging note. It's not an exploratory note. It has a very particular purpose, which is why I write it in this particular way.

+ +

I'm curious; I know you have a lot of different systems that you use for your notes, Amanda. Is there one that you'd like to share with the audience? Maybe tell us a little bit about what the system is and why it's a good fit for the type of scenario that you'd like to use it in.

+ +

AMANDA: Sure. One situation that I found myself in recently is I have started taking classes on things that I'm interested in, development-related and non-development-related. And that's a formal structure that requires some note-taking that I haven't really done since I was in school. And the tools were very different back then as to what we had available to us for note-taking. It was basically Microsoft Word or bust.

+ +

So I have found myself having to develop a new note system for that kind of content delivery method, basically of watching a video and taking notes and having something that then makes sense outside of the context of sitting down and watching a video. So that has been a little bit of a process journey that I've been on the last couple of months.

+ +

JOËL: And what does your note-taking system look like?

+ +

AMANDA: So it's been a mix of things, actually. I started out just kind of brain-dumping as I went along with the instructor talking trying to type and keep up. And I found that very not scannable to look back on. I was looking for some more visual cues, and I didn't really have time to insert those visual cues as I was trying to keep up with a lecture essentially.

+ +

I then transitioned back to old school pen and paper, like, got myself a notebook and started writing in it. And obviously, that has some benefits of the free-formness, like, I'm not constrained by the offerings of any specific tool. But the trade-off for that is always that you have different notebooks for everything. And it's like, where's my X class notebook?

+ +

And so I've been trying to bring those two methods together into something that makes a little bit more sense for me and also bring in some of that synthesis process that you were talking about with your note-taking method of doing the full literature notes and then synthesizing them down into something a little bit more well-scoped for the particular piece of information.

+ +

JOËL: So you have like a two-step process then.

+ +

AMANDA: It did end up being a two-step process because one of the things that I found was the grouping of ideas that make sense when you're first learning a concept and the grouping of ideas that make sense when I'm revisiting that concept, later on, aren't necessarily the same. And so, keeping it in the original context doesn't necessarily help me recall the information when I'm referring back to my notes.

+ +

JOËL: That's really interesting. When you're writing it, it's going to be different than when you're reading it.

+ +

So we've been talking a lot about the purpose of different notes along the way, and you mentioned the word recall here. Do you use these notes mostly as a way to recall things that you would look back at them and try to remember, or are they more of a way to digest the material as you're going through it?

+ +

AMANDA: I think at the time that I'm writing them, they definitely served the purpose of helping me digest the information. But at some point, I probably want to be able to look back at them and remember the things that I learned and see if maybe they have new salience now that I have sat on them for a little bit.

+ +

JOËL: Hmmm, that's good. So it's valuable for both in different contexts.

+ +

AMANDA: Yeah, definitely. And one of the more surprising things that I've learned through that process has been that when I'm learning something, I really like a chronological kind of step-by-step through that process and building blocks of complexity that basically go one on top of the other. But then, once I've kind of made it to the end when I look back on it, I look back on those notes, and they're usually pretty thorough. They probably have a lot of details that aren't going to be top-level priority at the end.

+ +

But I didn't really have that concept of priority when I was first learning it. I was kind of grasping onto each bit of information, saying, "I'm going to scroll this away in case I need it later." And then when you get a better understanding of the full picture, you realize, okay, I'm glad that I know that, but it's not necessarily something that I'd want to look back on. So I really like having systems that then allow me to regroup that information once I have built out a fuller picture of what it is I'm trying to learn.

+ +

JOËL: Interesting. So the sort of digesting step that happens afterwards or the synthesis step, a lot of the value that you're adding there is by putting structure on a lot of the information you captured.

+ +

AMANDA: Yeah, I think putting structure and changing the structure, and not being afraid to change that structure to fit my new understanding in how I see this concept now instead of just how this concept was explained to me.

+ +

JOËL: So you mentioned that you'd initially used notebooks and paper and that that felt a little bit constraining in terms of organization. Is there any kind of software or apps that you like to use to organize your notes, and how do they fit in with your approach to note-taking?

+ +

AMANDA: I've been using Notion for the last few years. I found that that application works well with my visual preferences for note-taking. I think there's a lot of opportunity for visual cues that help me recall things, such as emoji and bullet points. And I like that I can do all of that by writing Markdown without then also having to read Markdown.

+ +

JOËL: Yeah, I definitely agree that a little visual change there where you can actually see the rendered Markdown is a nice quality-of-life improvement.

+ +

AMANDA: Absolutely. And I also think that the way that it turns Markdown into blocks that then you can rearrange has served me really well for that synthesis process of maybe this bullet point makes sense, and I want to keep it as is. But I want to rearrange it into these new themes that I'm seeing as I'm reviewing these things that I've learned.

+ +

JOËL: That's fascinating. So it has some really good tools for evolving your notes and reorganizing them, it sounds like.

+ +

AMANDA: I like that I can group my notes by concept, and notes can be subsets or sub-notes of other notes. And you can kind of move the individual notes in between those blocks pretty easily, which helps me rearrange things when I see different themes evolving.

+ +

JOËL: I've heard really good things about Notion, but I've not tried it myself. My app of choice so far has been Obsidian, which I really appreciate its focus on linking between notes. It doesn't have this concept of blocks where you can embed parts of notes as notes into other notes and things like that. But that has been okay for me because I keep my notes very small and atomic. But the focus on hyperlinking between notes has been really useful for me because, in my approach, it's all about the connections.

+ +

AMANDA: So, what does that process look like when you are referring back to all of these notes that are hyperlinked together?

+ +

JOËL: That's actually really important because the recall aspect is a big part of how you would use a note-taking system. For me, it's sort of like walking the graph. So I'll use search, or maybe I know a note that's in the general theme of what I care about, and then I'll just follow the links to other related articles or notes that talk about things that are related to it. And I might walk that graph three, four steps out in a few different directions. It's kind of like surfing Wikipedia. You find some entry point, and then you just follow the links until you have the material that you're interested in.

+ +

AMANDA: It sounds like creating a Wikipedia wormhole of your own.

+ +

JOËL: It kind of is. I guess, in a way, it's kind of like a little mini personal wiki where the articles are very, very condensed because I have that limitation that everything must be atomic.

+ +

Wow. So this has been a really fascinating conversation. I feel like one of the big takeaways that I have is that types of notes matter. Note-taking can take very different forms in different contexts. And the way you organize them would be vastly different; how long you care about them is also going to be different.

+ +

So going into a particular situation, knowing what sort of situation is this that I'm using notes and what is their purpose is going to be really helpful to think in terms of how I want to do my note-keeping. Whereas I think previously, I probably was just like, yeah, notes. You open a document, and you put in some bullet points.

+ +

AMANDA: I am definitely guilty of doing that as well. And I like the idea of having a purpose for your notes. You mentioned your purpose was ultimately to build a map that would produce content. And I really like how you have found a system that works really well for that purpose. And I'm going to keep thinking about how to be more intentional in what is the purpose of the notes that I'm taking in the future.

+ +

JOËL: Well, thank you so much for joining the conversation today. Where can people find you on the web?

+ +

AMANDA: Thanks so much for having me, Joël. You can find me @amandabeiner on Twitter.

+ +

JOËL: And we'll link to that in the show notes. And with that, let's wrap up.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+yqk8Nmy2 + + ]]> + + Joël Quenneville + + + 356: The Value of Specialized Vocabulary + https://bikeshed.thoughtbot.com/356 + 11b9c89e-7d7d-481a-bb5e-f247421b86b1 + Tue, 27 Sep 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Guest and fellow thoughtbotter Stephanie Minn and Joël chat about how the idea of specialized vocabulary came up during a discussion of the Ruby Science book. We have all these names for code smells and refactors. Before knowing these names, we often have a vague sense of the ideas but having a name makes them more real. They also give us ways to talk precisely about what we mean. However, there is a downside since not everyone is familiar with the jargon. + 39:20 + no + + + Guest and fellow thoughtbotter Stephanie Minn and Joël chat about how the idea of specialized vocabulary came up during a discussion of the Ruby Science book. We have all these names for code smells and refactors. Before knowing these names, we often have a vague sense of the ideas but having a name makes them more real. They also give us ways to talk precisely about what we mean. However, there is a downside since not everyone is familiar with the jargon. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Stephanie's previous talk (https://www.youtube.com/watch?v=m0dC5RmxcFk) +Non Violent Communication (https://www.goodreads.com/book/show/71730.Nonviolent_Communication) +RubyConfMini (http://www.rubyconfmini.com/) +Ruby Science book (https://books.thoughtbot.com/books/ruby-science.html) +Connascence as a vocabulary to discuss coupling (https://thoughtbot.com/blog/connascence-as-a-vocabulary-to-discuss-coupling) +Wired series "5 levels of teaching" (https://www.youtube.com/playlist?list=PLibNZv5Zd0dyCoQ6f4pdXUFnpAIlKgm3N) +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. And today, I'm joined with fellow thoughtboter Stephanie Minn. +STEPHANIE: Hey, Joël. +JOËL: And together, we're here to share a little bit of what we've learned along the way. Stephanie, what is new in your world? +STEPHANIE: Thanks for asking. I am on a new project I just started a few weeks ago, and I'm feeling the new project vibes, I think, kind of scoping out what's going on with the client with the work that they're doing. Trying to make a good impression. I think lately I've been in that mode of where can I find some work to do even when I'm just getting on boarded and learning the domain, trying to make those README updates in the areas that are a bit outdated, and yeah, just kind of along for the ride. +One thing that has been surprising already is that in my second week, the project pivoted into a different direction than what I was expecting. So that has been kind of exciting and also pretty interesting to see sometimes this stuff happens. I was brought on thinking that we were working on rebuilding the front end in React and TypeScript, pulling out pieces of their 15-year-old Rails monolith. So that was kind of one area that they decided to start with. +But recently, they actually decided to pivot to just revamping the look of the existing pages in the Rails app using the same templates and forms. So it's kind of shifted from more greenfield-esque work to figuring out what the heck's going on in this legacy codebase and making it a little bit more modern-looking and cleaning out the cobwebs, I suppose as we find them. +JOËL: As a consultant, how do you deal with that kind of dramatic shift in expectations? +STEPHANIE: I think it's tough because I necessarily wasn't in those conversations, and so I have to come at it with the understanding that they have a deep knowledge of the business and things that are going on behind the scenes that I don't, and I am coming in kind of with a fresh set of eyes. And it definitely raises some questions for me, right? Like, why now? What were the trade-offs that were made in the decisions? +And I hope that as a consultant, I can poke and prod a little bit to help them with the transition and also figuring out its impact on the rest of the team in a way maybe someone who is more familiar with the situation and more tied to the politics of the org might not have that perspective. +JOËL: I have a lot of questions here. But actually, I'm thinking that onboarding as a topic would probably make a good standalone episode. So maybe we'll have to bring you back for a future episode to talk about how to onboard well and how to deal with surprises. +STEPHANIE: Yeah, I think that's a great idea. What about you, Joël? What's going on in your world? +JOËL: I'm doing an integration with a third-party gem, and I am really struggling. And I've gotten to the point where I'm reading through the source of the gem to try to figure out some weird errors, some things that come up that are not documented. I think that's a really valuable skill. Ideally, you're not having to bring it out too often, but when you do, being able to drop into the code can really help unblock you or at least make some amount of progress. +STEPHANIE: Are you having to dig into the gem's code because you weren't able to find what you needed from the documentation? +JOËL: That's correct. I'm getting some cryptic errors where the gem is crashing, and I'm finding some lines in my logs that point back to the gem. And now I'm trying to reconstruct what is happening. Why is it not behaving the way it should be based on the documentation that I read? +STEPHANIE: Oh, that's tough. Getting into gem code is uncharted territory. +JOËL: It's nice when you're working with an open-source gem because the source is there, and you can just follow the stack trace and go through the code. Sometimes it's long and tedious, but it generally gives you results. It definitely is intimidating. +STEPHANIE: Yeah. When you're facing this kind of problem where you have no idea where the light at the end of the tunnel might be, how long do you spend with it? At what point do you take away with what you've learned and try to figure out a different approach? +JOËL: That's a good observation because digging through the source of a gem can definitely be a time sink. I think how much time I want to budget depends on a variety of other factors. How big of a problem is this? If I can't figure it out through reading the source, do I have alternate approaches to debug the problem, such as asking for help, opening an issue, reaching out to somebody else who's used it, complaining about it on The Bike Shed and hoping someone responds with an answer? +There are other options that I can do that might leave me blocked but maybe eventually give me results. The advantage with reading the source is that you're at least feeling like you're making progress. +STEPHANIE: Nice. Well, I wish you luck on that journey. [laughs] It sounds pretty tough. I'm sure that you'll get to one of those solutions and figure out how to get unblocked. +JOËL: I hope so. I'm pursuing a few strategies in tandem. So I've asked for help, but I'm also reading the source code. And between the two of those, I hope I'll get to a good solution. +So, Stephanie, last time you were on the show, you talked about your experience creating talk proposals for RubyConf. Have you heard back from them since then? +STEPHANIE: I have. I will be speaking at RubyConf Mini this year. And I'm really excited because this will be my first IRL conference talk. So last time, I recorded my talk for RubyConf, and this time I will be up on a stage in front of real people. +JOËL: That's really exciting. Congratulations. +STEPHANIE: Thanks. +JOËL: What is the topic of your talk? +STEPHANIE: I will be talking about pair programming and specifically pair programming through the lens of a framework called Nonviolent Communication, which is a framework I learned about through a friend who recommended the canonical book on it. And it's a self-help book, to be totally frank, but I found it so illuminating. It really changed how I communicated in my relationships in my personal life. +And the more time I spent with it, the more I realized that it would be a great application in pair programming because it's so collaborative and intimate. I've experienced the highs and lows of pair programming. You can feel so good when you are super connected with your pair. You make a lot of progress. You meet whatever professional goals that you might be meeting, and you have someone along for the ride the whole time. It can be just so rewarding. +But it can also be really challenging when you are having more of those interpersonal conflicts, and navigating that can be tough. And so I'm really excited to share this style of communication that might help others who want to take their pair programming to the next level and get the most out of that experience no matter who they're pairing with. +JOËL: I'm excited to hear this talk because pair programming has always been an important part of what we do at thoughtbot. And I think now that we're remote, we do a lot of remote pair programming. And the interpersonal interactions are a little bit different there than when you're physically in a room with each other, or you have to maybe pay a little bit more attention to them. I'm really excited to hear that. I think that's going to be really useful, not just for me but for a lot of the audience who are there. +STEPHANIE: Thanks. Joël, you have a talk accepted at RubyConf Mini too. +JOËL: Yes, I also had a talk accepted titled Teaching Ruby to Count. And it's going to be all about series, enumerators, enumerables, and ranges in Ruby and the cool things that you can do with them. So I'm really excited to share about that. I've done some deep dives on these topics, and I'm excited to share that with the broader Ruby community. +STEPHANIE: Nice. I'm really excited to hear more about it. +JOËL: Did you submit more than one proposal this year? +STEPHANIE: This year, I didn't. But I would love to get to a point where I have a lot of content on the backburner and can pull it out when CFP season rolls around to just have some more options. Yeah, I have all these ideas in my head. I think we talked about how we come up with content in our last episode. But yeah, having a content bank sounds really nice for the future, so maybe when that season rolls around, it is a lot easier to get the ball rolling on submitting. What about you? Did you submit more than one? +JOËL: I submitted two, but this is the one I was most excited about. I think the other idea was maybe a little bit more polished, but this one was a newer one I came up with towards the end of the CFP period. And I was like, ooh, I'm excited about this. I've just done a deep dive on enumerators, and I think there are some cool things to share with the community. And so that's what I'm excited to share about, and maybe that came through the proposal because that is what the committee picked. So I'm super happy to be talking about that. +STEPHANIE: Nice. Yeah, I was just thinking the same, that your excitement about it was probably palpable to the committee. +JOËL: For any of our viewers who are interested in coming to watch the talks by Stephanie and myself and plenty of other gifted speakers, this will be at RubyConf Mini in Providence, Rhode Island, from November 15th to 17th. And if you can't make it in person, the videos will be published online early in 2023. And we'll definitely share the links to that when they come out. +So as we mentioned in your last episode, thoughtbot has a book club where we've been discussing the book Ruby Science, which goes through a lot of code smells and talks about some various refactoring patterns that can be used to fix them. Most recently, we looked at a code smell that has a very evocative name; it's called shotgun surgery. +STEPHANIE: Yeah, it's a very visceral name for sure. I think that is what prompted this next topic that we're about to discuss because someone in the book club, another thoughtboter, mentioned that they were learning this term for the first time. But it made a lot of sense to them because they had experienced shotgun surgery and didn't have the term for it previously. Joël, do you mind giving the listeners a recap of what shotgun surgery is? +JOËL: So shotgun surgery is when in order to make a change to a codebase, you have to make a bunch of little changes in a lot of different files, a lot of different locations. And that means that all of these little pieces are weirdly coupled to each other in a way that to make one change, you have to make a bunch of little changes in a lot of places. And that results in a very high churn diff, and that's a common symptom of this problem. +STEPHANIE: Nice. Thanks for explaining. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPHANIE: I think I came away from that conversation thinking about the idea of learning new terms, especially technical ones, and the power that learning those terms can give you as a developer, especially when you're communicating with other people on your team. +JOËL: So you mentioned the value in communication there. Some terms have a very precise meaning, and so that allows you to communicate a very specific idea. How do you balance having some jargon and some terminology that allows you to speak very precisely versus having to learn all the terms? Because the more narrow the term is, the more terms you need to talk about all the different things. +STEPHANIE: That's a great question. I don't know if I have a great answer because I think I'm still on my journey. I have always noticed when developers I work with have that really precise, articulate technical vocabulary, probably because I don't. I am constantly referring to functions or classes as things, like, that thingy over there talks to this thing over here, and then does something. [laughs] +And I think it's because I maybe didn't always have that exposure to very precise technical vocabulary. And so I had an understanding of how things worked in my head, but I couldn't necessarily map that to words. And I'm also from California, so, I don't know, maybe some of that is showing through a little bit. [laughs] +But I've been trying to incorporate more technical terms when I speak and also in written form, too, such as in code review, because I want to be able to communicate more clearly my intentions and leave less room for ambiguity. Sometimes I've noticed when you do speak more casually about code, turns out other people can interpret it in different ways. And if you are using, like you said, that narrower technical term for it, that leaves less room for misunderstanding. +But in the same vein, I think a lot of people are like me, where they might not know the technical terms for things. And when you start using a lot of jargon like that, it can be a bit exclusive to folks earlier in their career, especially since software as an industry we have folks from all different backgrounds. We don't necessarily have the expectation of assured formal training. We want to be inclusive of people who came to this career from different places and make sure that we are speaking the same language. And so it's been top of mind for me thinking about how we can balance those two things. I don't know, what do you think? +JOËL: I want to speak to some of the value of precision first because I think there are a few different points. We have the value of precision, then we have the difficulty of learning vocabulary, and how are we inclusive of everyone. But on the topic of precision, I don't know if you saw not too long ago, another fellow thoughtboter, Matheus Sales, published an article on the thoughtbot blog about the concept of connascence. And he introduces this as a new set of vocabulary, not vocabulary that he's created but a vocabulary that is out there that not that many developers are aware of for different ways to talk about coupling. +So it's easy in a pull request to just say, "Oh, well, that thing looks coupled. How about this other way?" And then I respond, "Well, that's also coupled in a different way." And then we just go back and forth like, "Well, mine is more coupled than yours is," or whatever. And connascence provides a more precise, narrow vocabulary to talk about the different ways that things are coupled and which ones are more coupled than others. And so it allows us to break out of maybe those unproductive discussions because now we can talk about things in a more granular way. +STEPHANIE: Yeah, I loved that blog post. It was really exciting for me to pick up a new term to describe something that I had experienced, or seen in codebases, or felt the pain of, and be able to describe it more accurately. I'm curious, Joël, if you were to use that term next time, how would you make sure that folks also have the same level of familiarity with it? +JOËL: I think on a pull request, I would link to Matheus' article depending on...I might give a little bit of context in a comment. So I might say something like, "This area here is coupled. Here's a suggested refactor. It's also coupled but in a different way. It's because we've moved up this hierarchy of connascence from, you know, connascence of names to some other form" (I don't have them all memorized.) and then link to the article. And hopefully, that becomes the start of a productive discussion. +But yeah, having the resources you can link to people is great. And that's one of the nice things about text communication on a pull request is that you can just link to external resources that people can find helpful. +STEPHANIE: To continue talking about the value of precision and specialized vocabulary, Joël, I think you are a very articulate communicator. And I'm curious from your perspective if you have always been this way, if you've always wanted to collect technical terms to describe exactly what you want to convey, or if this was a bit of a journey for you to get to this level of clear communication in your technical speaking and writing. +JOËL: It's definitely been a journey. I think there are sort of two components to this; one is being able to communicate clearly to others; make sure that they understand what you're talking about. So for that, it's really important to be able to put yourself in somebody else's shoes. +So when I'm building a conference talk or writing up a blog post, I will try to read it or go through my slide deck and try to pretend that I am the audience. And then I ask myself the questions: where do I get confused? Where am I going to have questions? Maybe even where am I going to roll my eyes a little bit and be like, eh, I didn't agree with that leap of logic there; where are you going? And then shift back in author mode and say, how can I address these? How can I make my content speak to you in an area where maybe you disagreed, or you were confused? +So I kind of jump between moving from the audience seat to back to the author and try to make that material as much as possible resonate with those people. +STEPHANIE: Do you do that in more real-time communication, such as in meetings or in pairing? +JOËL: I think that's a little bit harder to do. And then it's maybe a little bit more of asking directly, either pausing to let people interject, or you can ask the question directly and say, "Are you familiar with this term?" That can also sometimes be tricky to manage because you don't want to make it sound like you think they don't know anything. +But you can also make it sound really natural in a conversation where you're like, "Oh, we're going to do this thing with a strategy pattern. Have you seen a strategy pattern before? Are you familiar with this? Great, let's keep moving." And if not, maybe it's like, "Hey, let's take a few minutes to talk about what the strategy pattern means." +STEPHANIE: I think you are really great at asking the audience about their level of familiarity with the content, especially in book club. I have definitely experienced just as a developer pairing, or in meetings, or whatnot times when people don't pause and ask. And usually, I have to muster up the courage to interrupt and ask, "Hey, what is X, Y, and Z?" And that is tough sometimes. +I am certainly comfortable with it in a space where there is trust developed in terms of I don't feel worried that people might question my level of familiarity or experience. And I can very enthusiastically say, "Hey, I don't know what this means. Could you please explain it?" But sometimes it can be a little tough when you might not have that relationship with someone, or you haven't talked about it, talked about assumptions about your knowledge or experience level upfront. +And so I have found that to be a really good way to build that trust to make sure that we aren't excluding folks is to just talk about some of that stuff, even before we start pairing or before a meeting. And that can really help with some of those miscommunications that might come down later in the process. +JOËL: It's interesting that you bring up miscommunication because I think sometimes, even though certain jargon can be very precise, sometimes people will not use it to mean exactly what its dictionary definition is. And so sometimes two people are using the same term, and you're not meaning quite the same thing. +And so sometimes I'll be pairing with someone, and I'll have to sort of pause and say, "Hey, wait a minute, you're using the term adapter in a certain way that seems to be a little bit different than the way I'm using it. Can you maybe tell me what your personal definition is? And I'll tell you mine, and we can reconcile those two together." +Sometimes that can also feel like a situation where maybe I'm hazy on the topic. Like, I have a vague sense of it, and maybe it does or does not align with the way the other person is using it. And so that's an opportunity for me to ask them to define the term for me without completely having to say, "I have no idea what this term is. Please, oh, great sage, explain the meaning." +STEPHANIE: Are there times that you feel more or less comfortable doing that kind of reset? +JOËL: I think sometimes the fear is in breaking flow. And so you're doing a thing, and then somebody is trying to explain something, and you don't want to break out of that. Or you're trying to explain something, and you have to decide, is it worth making sure to explain a term, or do you keep moving? So I think that is a big concern. +And there is just the interpersonal concern of if there is less trust, do I want to put myself out there? Does somebody else maybe not feel comfortable you asked them to explain a term? Maybe they're using it wrong. It's not always good in a pairing situation to just come up and say, "Hey, that's not technically the adapter pattern; you're wrong. Let me pull out The Gang of Four book. You see on page 54..." that's not productive. +STEPHANIE: Yeah, for sure. +JOËL: So a lot of it, I think...and maybe this ties into your topic of communication while pairing. But ideally, you're working constructively with a person. And so debating definitions is not generally productive but asking someone, "What do you mean when you say this?" I find is a very helpful way to lead into that type of conversation. +STEPHANIE: Yeah, that's a great strategy because you're coming from a place of curiosity rather than a place of this is my definition, and it's the right definition, and so, therefore, you are wrong. [laughs] +JOËL: It's interesting the place that jargon occupies in our imagination of expertise. If you've ever seen any movie where they're trying to show that somebody is technically competent, they usually demonstrate that a person is competent by having them just spout out a long chain of jargon, and that makes them sound smart. But I think to a certain extent; maybe we believe it in the industry as well. If somebody can use a lot of terms and talk about a system using this very specific jargon, we tend to think that they're smart or at least look up to them a little bit. +STEPHANIE: Yeah, which I think isn't always the best assumption because I've certainly worked with folks who did throw out a lot of jargon but weren't necessarily, like you were saying, using it the way that I understood it, and that made communicating with them challenging. +I also think what true expertise really is is having the knowledge that when you use a jargony term that not everyone might be familiar with it, having the awareness to pause and ask someone how they're doing with the vocabulary and be able to tailor how you explain that term to that other person. I think that demonstrates a really deep level of understanding that doesn't get enough credit. +JOËL: I 100% agree. Jargon, vocabulary, it's a means to an end, not an end in and of itself. So the goal is to communicate clearly to others and maybe to help yourself in your own learning. And if you're not accomplishing those goals, then what's the point? I guess maybe there is another personal goal which is to sound smart, but that's not really a good goal, [laughs] especially not when the way you do that is by confusing everybody else in the room because they don't understand you, to make you try to feel smarter than them. Like, that's bad communication. +STEPHANIE: Yeah, for sure. I've definitely experienced listening to someone explain something and have to really think very hard about every single word that they're saying because they were using terms that are just less common. And so, in my brain, I had to map them to things that made sense to me, and things that I was familiar with that were the same concepts. +Like, I was experienced enough to have that shared understanding, but just the words that they used required another layer of brain work. Maybe we could have found a happy medium between them communicating the way that they expressed themselves the best with my ability to understand easily and quickly so that we could get on the same page. +JOËL: So you mentioned that there are sometimes situations where you're aware of a particular concept, but maybe you're just not aware that the term that somebody else is using maps to this concept you already understand. And I know that for me, oftentimes, being able to give a name to something that I understand is an incredibly powerful thing. +Even though I already know the idea of passing objects to another object in this particular configuration, or of wrapping things in some way or whatever the thing that I'm trying to do, all of a sudden, instead of it being a more nebulous concept in my head or a list of 10 steps or something like that, now I have one thing I can just point to and say it is this. +So that's been really helpful for me in my learning to be able to take a label and put it on something that I already know. And somehow, it cements the idea in my head and also then allows me to build on it to the next things that I want to learn. +STEPHANIE: Yeah, absolutely. It's really exciting when you're able to have that light-bulb moment when you have that precise term, or you learn that precise term for something that you have been wrestling with or experiencing for a while now. +I was just reminded of reading documentation. I have a very vivid memory of the first time I read; I don't know, even the Rails official docs, all of these terms that I didn't understand at the time. But then once I started digging into it, exploring, and just doing the work, when I revisited those docs, I could understand them a lot more comprehensively because I had experience with the things (There I am using things again.) [laughs] and seeing the terms for them and that helping solidify my understanding. +JOËL: I'm curious, in your personal learning, do you find it easier to encounter a term first and then learn what it means, or do the reverse, learn the concept first and then cap it off by being able to give it a name? +STEPHANIE: That's a good question. I think the latter because I've certainly spent a lot of time Googling terms and then reading whatever first search results came up and being like, okay, I think I got it, and then Googling the same term like two weeks later because I didn't really get it the first time. But whenever I come across a term for a concept I already am familiar with, it is like, oh yes, uh-huh! That really ends up sticking with me. +Matheus Sales' blog post that you mentioned earlier is a really great example of that term really standing out to me because I didn't know it at the time, but I suppose was seeking out something to describe the concept of connascence. So that was really cool and really memorable. What about you? Do you have a preferred way of learning new technical terms? +JOËL: I think there can be value to both approaches. But I'm with you; I think it generally is easier to add a name to a concept you already understand. And I experienced this pretty dramatically when I tried to get into functional programming. +So several years ago, I tried to learn the language Haskell which is notorious for being difficult to learn and very abstract and technical. And the way that the Haskell community typically tries to teach things is learn the fundamentals first, very top-down, learn the theory, and then, later on, you can do things in practice. So it's like before you can write an actual program, let us teach you about applicatives, and monads, and all these things that are really difficult to learn. And they're kind of scary technical terms. +So I choked out partway through, gave up on Haskell. A year later, got back into it, tried it again, choked out again. And then, eventually, I pivoted. I started getting into a similar language called Elm, which is similar syntax but compiles to JavaScript for the front end. And that community has the opposite philosophy when it comes to teaching. They want to get you productive as soon as possible. And you can learn some of the theory as you go along. And so with that, I felt like I was learning something new all the time and being productive as well, like, constantly adding new features to things in an application, and that's really exciting. +And what's really beautiful there is that you eventually learn a lot of the same concepts that you would learn in something like Haskell because the two languages share a lot of similar concepts. But instead of saying first, you need to learn about monads as a general concept, and then you can build a program; Elm says, build a bunch of programs first. We'll show you the basic syntax. And after you've built a bunch of them, you'll start realizing, wait a minute, these things all kind of look alike. There are patterns I'm starting to recognize. +And then you can just point to that and say, hey, that pattern that you started recognizing, and you see a bunch of times that's monad. You've known it all along, and now you can put a label on it. And you've gotten there. And so that's the way that I learned those concepts. And that was much easier for me than the approach of trying to learn the abstract concept first. +STEPHANIE: Monad is literally the word I just Googled earlier this week and still have a very, very hazy understanding of. So maybe I'll have to go learn Elm now. [chuckles] +JOËL: I recommend a lot of people to use that as their entry point into the statically typed functional programming world, just because of how much more shallow the learning curve is compared to alternatives. And I think a lot of it has to do with that approach of saying, let's get you productive quickly. Let's get you doing things. And eventually, patterns will emerge, and you can put names on them later. But we'll not make you learn all of the theory upfront, all the jargon. +STEPHANIE: Now that you do understand all the technical jargon around functional programming, how do you approach communicating about it when you do talk about Elm or those kinds of concepts? +JOËL: A lot of it depends on your audience. If you have an audience that already knows these concepts, then being able to use those names is really valuable because it's a shortcut. You can just say, oh yeah, this thing is a monad, and so, therefore, we can do these actions with it. And everybody in the audience just already knows monads have these properties. That's wonderful. Now I can follow to step two instead of having to have a slow build-up. +So if I'm writing an article or giving a talk, or even just having a conversation with someone, if I knew they didn't know the term, I would have to really build up to it, and maybe I wouldn't introduce the term at all. I would just talk about some of the properties that are interesting for the purpose of this particular demo. +But I would probably have to work up to it and say, "See, we have this simpler thing, and then this more complex thing. But here are the problems that we have with it. Here's a change we can make to our code that will make it work." And you walk through the process without necessarily getting into all of the theory. But with somebody else who did know, I could just say, "Oh, what we need here is monad." And they look at me, and they're like, "Oh, of course," and then we do it. +STEPHANIE: What you just described reminds me a lot of the WIRED Video Series, five levels of teaching where they have an expert come in and teach the same concept to different-aged people starting from young kids to an expert in their field as well. And I really liked how you answered that question just with the awareness that you tailor how you explain something to your audience because we could all benefit from just having that intentionality when we communicate in order to get the most value out of our interactions and knowledge sharing, and collaborative working. +JOËL: I think a theme that underlies a lot of what you and I have talked about today is just that communication, good communication is the fundamental value that we're going for here. And jargon and vocabulary can be something that empowers that but used poorly; it can also defeat that purpose. And most importantly, good communication starts with the audience, not with you. So when you work back from the audience, you can use the appropriate vocabulary and words that serve everybody and your ultimate goal of communicating. +STEPHANIE: I love that. +JOËL: So, Stephanie, thank you so much for joining us on The Bike Shed today. And as we wrap up, I wanted to ask you, what is a really fun piece of vocabulary that you’ve learned that you might want to share with the audience? +STEPHANIE: So lately, I learned the term WYSIWYG, which stands for What You See Is What You Get to describe text editing software that lets you see and edit the content as it would actually be displayed. So that was a fun, little term that someone brought up when we were paring and looking at some text editing code. And I was really excited because it sounds fun, and also, now I had just an opportunity to say it on a podcast. [laughs] +JOËL: It's amazing that an acronym that is that long has enough vowels in the right places that you can just pronounce it. +STEPHANIE: Oh yeah. +JOËL: WYSIWYG. That's a fun word to say. +STEPHANIE: 100%. I also try to pronounce all acronyms, regardless of how pronounceable they actually are. [laughs] Thanks for asking. +JOËL: With that, shall we wrap up? +STEPHANIE: Let's wrap up. +JOËL: The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Guest and fellow thoughtbotter Stephanie Minn and Joël chat about how the idea of specialized vocabulary came up during a discussion of the Ruby Science book. We have all these names for code smells and refactors. Before knowing these names, we often have a vague sense of the ideas but having a name makes them more real. They also give us ways to talk precisely about what we mean. However, there is a downside since not everyone is familiar with the jargon.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined with fellow thoughtboter Stephanie Minn.

+ +

STEPHANIE: Hey, Joël.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. Stephanie, what is new in your world?

+ +

STEPHANIE: Thanks for asking. I am on a new project I just started a few weeks ago, and I'm feeling the new project vibes, I think, kind of scoping out what's going on with the client with the work that they're doing. Trying to make a good impression. I think lately I've been in that mode of where can I find some work to do even when I'm just getting on boarded and learning the domain, trying to make those README updates in the areas that are a bit outdated, and yeah, just kind of along for the ride.

+ +

One thing that has been surprising already is that in my second week, the project pivoted into a different direction than what I was expecting. So that has been kind of exciting and also pretty interesting to see sometimes this stuff happens. I was brought on thinking that we were working on rebuilding the front end in React and TypeScript, pulling out pieces of their 15-year-old Rails monolith. So that was kind of one area that they decided to start with.

+ +

But recently, they actually decided to pivot to just revamping the look of the existing pages in the Rails app using the same templates and forms. So it's kind of shifted from more greenfield-esque work to figuring out what the heck's going on in this legacy codebase and making it a little bit more modern-looking and cleaning out the cobwebs, I suppose as we find them.

+ +

JOËL: As a consultant, how do you deal with that kind of dramatic shift in expectations?

+ +

STEPHANIE: I think it's tough because I necessarily wasn't in those conversations, and so I have to come at it with the understanding that they have a deep knowledge of the business and things that are going on behind the scenes that I don't, and I am coming in kind of with a fresh set of eyes. And it definitely raises some questions for me, right? Like, why now? What were the trade-offs that were made in the decisions?

+ +

And I hope that as a consultant, I can poke and prod a little bit to help them with the transition and also figuring out its impact on the rest of the team in a way maybe someone who is more familiar with the situation and more tied to the politics of the org might not have that perspective.

+ +

JOËL: I have a lot of questions here. But actually, I'm thinking that onboarding as a topic would probably make a good standalone episode. So maybe we'll have to bring you back for a future episode to talk about how to onboard well and how to deal with surprises.

+ +

STEPHANIE: Yeah, I think that's a great idea. What about you, Joël? What's going on in your world?

+ +

JOËL: I'm doing an integration with a third-party gem, and I am really struggling. And I've gotten to the point where I'm reading through the source of the gem to try to figure out some weird errors, some things that come up that are not documented. I think that's a really valuable skill. Ideally, you're not having to bring it out too often, but when you do, being able to drop into the code can really help unblock you or at least make some amount of progress.

+ +

STEPHANIE: Are you having to dig into the gem's code because you weren't able to find what you needed from the documentation?

+ +

JOËL: That's correct. I'm getting some cryptic errors where the gem is crashing, and I'm finding some lines in my logs that point back to the gem. And now I'm trying to reconstruct what is happening. Why is it not behaving the way it should be based on the documentation that I read?

+ +

STEPHANIE: Oh, that's tough. Getting into gem code is uncharted territory.

+ +

JOËL: It's nice when you're working with an open-source gem because the source is there, and you can just follow the stack trace and go through the code. Sometimes it's long and tedious, but it generally gives you results. It definitely is intimidating.

+ +

STEPHANIE: Yeah. When you're facing this kind of problem where you have no idea where the light at the end of the tunnel might be, how long do you spend with it? At what point do you take away with what you've learned and try to figure out a different approach?

+ +

JOËL: That's a good observation because digging through the source of a gem can definitely be a time sink. I think how much time I want to budget depends on a variety of other factors. How big of a problem is this? If I can't figure it out through reading the source, do I have alternate approaches to debug the problem, such as asking for help, opening an issue, reaching out to somebody else who's used it, complaining about it on The Bike Shed and hoping someone responds with an answer?

+ +

There are other options that I can do that might leave me blocked but maybe eventually give me results. The advantage with reading the source is that you're at least feeling like you're making progress.

+ +

STEPHANIE: Nice. Well, I wish you luck on that journey. [laughs] It sounds pretty tough. I'm sure that you'll get to one of those solutions and figure out how to get unblocked.

+ +

JOËL: I hope so. I'm pursuing a few strategies in tandem. So I've asked for help, but I'm also reading the source code. And between the two of those, I hope I'll get to a good solution.

+ +

So, Stephanie, last time you were on the show, you talked about your experience creating talk proposals for RubyConf. Have you heard back from them since then?

+ +

STEPHANIE: I have. I will be speaking at RubyConf Mini this year. And I'm really excited because this will be my first IRL conference talk. So last time, I recorded my talk for RubyConf, and this time I will be up on a stage in front of real people.

+ +

JOËL: That's really exciting. Congratulations.

+ +

STEPHANIE: Thanks.

+ +

JOËL: What is the topic of your talk?

+ +

STEPHANIE: I will be talking about pair programming and specifically pair programming through the lens of a framework called Nonviolent Communication, which is a framework I learned about through a friend who recommended the canonical book on it. And it's a self-help book, to be totally frank, but I found it so illuminating. It really changed how I communicated in my relationships in my personal life.

+ +

And the more time I spent with it, the more I realized that it would be a great application in pair programming because it's so collaborative and intimate. I've experienced the highs and lows of pair programming. You can feel so good when you are super connected with your pair. You make a lot of progress. You meet whatever professional goals that you might be meeting, and you have someone along for the ride the whole time. It can be just so rewarding.

+ +

But it can also be really challenging when you are having more of those interpersonal conflicts, and navigating that can be tough. And so I'm really excited to share this style of communication that might help others who want to take their pair programming to the next level and get the most out of that experience no matter who they're pairing with.

+ +

JOËL: I'm excited to hear this talk because pair programming has always been an important part of what we do at thoughtbot. And I think now that we're remote, we do a lot of remote pair programming. And the interpersonal interactions are a little bit different there than when you're physically in a room with each other, or you have to maybe pay a little bit more attention to them. I'm really excited to hear that. I think that's going to be really useful, not just for me but for a lot of the audience who are there.

+ +

STEPHANIE: Thanks. Joël, you have a talk accepted at RubyConf Mini too.

+ +

JOËL: Yes, I also had a talk accepted titled Teaching Ruby to Count. And it's going to be all about series, enumerators, enumerables, and ranges in Ruby and the cool things that you can do with them. So I'm really excited to share about that. I've done some deep dives on these topics, and I'm excited to share that with the broader Ruby community.

+ +

STEPHANIE: Nice. I'm really excited to hear more about it.

+ +

JOËL: Did you submit more than one proposal this year?

+ +

STEPHANIE: This year, I didn't. But I would love to get to a point where I have a lot of content on the backburner and can pull it out when CFP season rolls around to just have some more options. Yeah, I have all these ideas in my head. I think we talked about how we come up with content in our last episode. But yeah, having a content bank sounds really nice for the future, so maybe when that season rolls around, it is a lot easier to get the ball rolling on submitting. What about you? Did you submit more than one?

+ +

JOËL: I submitted two, but this is the one I was most excited about. I think the other idea was maybe a little bit more polished, but this one was a newer one I came up with towards the end of the CFP period. And I was like, ooh, I'm excited about this. I've just done a deep dive on enumerators, and I think there are some cool things to share with the community. And so that's what I'm excited to share about, and maybe that came through the proposal because that is what the committee picked. So I'm super happy to be talking about that.

+ +

STEPHANIE: Nice. Yeah, I was just thinking the same, that your excitement about it was probably palpable to the committee.

+ +

JOËL: For any of our viewers who are interested in coming to watch the talks by Stephanie and myself and plenty of other gifted speakers, this will be at RubyConf Mini in Providence, Rhode Island, from November 15th to 17th. And if you can't make it in person, the videos will be published online early in 2023. And we'll definitely share the links to that when they come out.

+ +

So as we mentioned in your last episode, thoughtbot has a book club where we've been discussing the book Ruby Science, which goes through a lot of code smells and talks about some various refactoring patterns that can be used to fix them. Most recently, we looked at a code smell that has a very evocative name; it's called shotgun surgery.

+ +

STEPHANIE: Yeah, it's a very visceral name for sure. I think that is what prompted this next topic that we're about to discuss because someone in the book club, another thoughtboter, mentioned that they were learning this term for the first time. But it made a lot of sense to them because they had experienced shotgun surgery and didn't have the term for it previously. Joël, do you mind giving the listeners a recap of what shotgun surgery is?

+ +

JOËL: So shotgun surgery is when in order to make a change to a codebase, you have to make a bunch of little changes in a lot of different files, a lot of different locations. And that means that all of these little pieces are weirdly coupled to each other in a way that to make one change, you have to make a bunch of little changes in a lot of places. And that results in a very high churn diff, and that's a common symptom of this problem.

+ +

STEPHANIE: Nice. Thanks for explaining.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: I think I came away from that conversation thinking about the idea of learning new terms, especially technical ones, and the power that learning those terms can give you as a developer, especially when you're communicating with other people on your team.

+ +

JOËL: So you mentioned the value in communication there. Some terms have a very precise meaning, and so that allows you to communicate a very specific idea. How do you balance having some jargon and some terminology that allows you to speak very precisely versus having to learn all the terms? Because the more narrow the term is, the more terms you need to talk about all the different things.

+ +

STEPHANIE: That's a great question. I don't know if I have a great answer because I think I'm still on my journey. I have always noticed when developers I work with have that really precise, articulate technical vocabulary, probably because I don't. I am constantly referring to functions or classes as things, like, that thingy over there talks to this thing over here, and then does something. [laughs]

+ +

And I think it's because I maybe didn't always have that exposure to very precise technical vocabulary. And so I had an understanding of how things worked in my head, but I couldn't necessarily map that to words. And I'm also from California, so, I don't know, maybe some of that is showing through a little bit. [laughs]

+ +

But I've been trying to incorporate more technical terms when I speak and also in written form, too, such as in code review, because I want to be able to communicate more clearly my intentions and leave less room for ambiguity. Sometimes I've noticed when you do speak more casually about code, turns out other people can interpret it in different ways. And if you are using, like you said, that narrower technical term for it, that leaves less room for misunderstanding.

+ +

But in the same vein, I think a lot of people are like me, where they might not know the technical terms for things. And when you start using a lot of jargon like that, it can be a bit exclusive to folks earlier in their career, especially since software as an industry we have folks from all different backgrounds. We don't necessarily have the expectation of assured formal training. We want to be inclusive of people who came to this career from different places and make sure that we are speaking the same language. And so it's been top of mind for me thinking about how we can balance those two things. I don't know, what do you think?

+ +

JOËL: I want to speak to some of the value of precision first because I think there are a few different points. We have the value of precision, then we have the difficulty of learning vocabulary, and how are we inclusive of everyone. But on the topic of precision, I don't know if you saw not too long ago, another fellow thoughtboter, Matheus Sales, published an article on the thoughtbot blog about the concept of connascence. And he introduces this as a new set of vocabulary, not vocabulary that he's created but a vocabulary that is out there that not that many developers are aware of for different ways to talk about coupling.

+ +

So it's easy in a pull request to just say, "Oh, well, that thing looks coupled. How about this other way?" And then I respond, "Well, that's also coupled in a different way." And then we just go back and forth like, "Well, mine is more coupled than yours is," or whatever. And connascence provides a more precise, narrow vocabulary to talk about the different ways that things are coupled and which ones are more coupled than others. And so it allows us to break out of maybe those unproductive discussions because now we can talk about things in a more granular way.

+ +

STEPHANIE: Yeah, I loved that blog post. It was really exciting for me to pick up a new term to describe something that I had experienced, or seen in codebases, or felt the pain of, and be able to describe it more accurately. I'm curious, Joël, if you were to use that term next time, how would you make sure that folks also have the same level of familiarity with it?

+ +

JOËL: I think on a pull request, I would link to Matheus' article depending on...I might give a little bit of context in a comment. So I might say something like, "This area here is coupled. Here's a suggested refactor. It's also coupled but in a different way. It's because we've moved up this hierarchy of connascence from, you know, connascence of names to some other form" (I don't have them all memorized.) and then link to the article. And hopefully, that becomes the start of a productive discussion.

+ +

But yeah, having the resources you can link to people is great. And that's one of the nice things about text communication on a pull request is that you can just link to external resources that people can find helpful.

+ +

STEPHANIE: To continue talking about the value of precision and specialized vocabulary, Joël, I think you are a very articulate communicator. And I'm curious from your perspective if you have always been this way, if you've always wanted to collect technical terms to describe exactly what you want to convey, or if this was a bit of a journey for you to get to this level of clear communication in your technical speaking and writing.

+ +

JOËL: It's definitely been a journey. I think there are sort of two components to this; one is being able to communicate clearly to others; make sure that they understand what you're talking about. So for that, it's really important to be able to put yourself in somebody else's shoes.

+ +

So when I'm building a conference talk or writing up a blog post, I will try to read it or go through my slide deck and try to pretend that I am the audience. And then I ask myself the questions: where do I get confused? Where am I going to have questions? Maybe even where am I going to roll my eyes a little bit and be like, eh, I didn't agree with that leap of logic there; where are you going? And then shift back in author mode and say, how can I address these? How can I make my content speak to you in an area where maybe you disagreed, or you were confused?

+ +

So I kind of jump between moving from the audience seat to back to the author and try to make that material as much as possible resonate with those people.

+ +

STEPHANIE: Do you do that in more real-time communication, such as in meetings or in pairing?

+ +

JOËL: I think that's a little bit harder to do. And then it's maybe a little bit more of asking directly, either pausing to let people interject, or you can ask the question directly and say, "Are you familiar with this term?" That can also sometimes be tricky to manage because you don't want to make it sound like you think they don't know anything.

+ +

But you can also make it sound really natural in a conversation where you're like, "Oh, we're going to do this thing with a strategy pattern. Have you seen a strategy pattern before? Are you familiar with this? Great, let's keep moving." And if not, maybe it's like, "Hey, let's take a few minutes to talk about what the strategy pattern means."

+ +

STEPHANIE: I think you are really great at asking the audience about their level of familiarity with the content, especially in book club. I have definitely experienced just as a developer pairing, or in meetings, or whatnot times when people don't pause and ask. And usually, I have to muster up the courage to interrupt and ask, "Hey, what is X, Y, and Z?" And that is tough sometimes.

+ +

I am certainly comfortable with it in a space where there is trust developed in terms of I don't feel worried that people might question my level of familiarity or experience. And I can very enthusiastically say, "Hey, I don't know what this means. Could you please explain it?" But sometimes it can be a little tough when you might not have that relationship with someone, or you haven't talked about it, talked about assumptions about your knowledge or experience level upfront.

+ +

And so I have found that to be a really good way to build that trust to make sure that we aren't excluding folks is to just talk about some of that stuff, even before we start pairing or before a meeting. And that can really help with some of those miscommunications that might come down later in the process.

+ +

JOËL: It's interesting that you bring up miscommunication because I think sometimes, even though certain jargon can be very precise, sometimes people will not use it to mean exactly what its dictionary definition is. And so sometimes two people are using the same term, and you're not meaning quite the same thing.

+ +

And so sometimes I'll be pairing with someone, and I'll have to sort of pause and say, "Hey, wait a minute, you're using the term adapter in a certain way that seems to be a little bit different than the way I'm using it. Can you maybe tell me what your personal definition is? And I'll tell you mine, and we can reconcile those two together."

+ +

Sometimes that can also feel like a situation where maybe I'm hazy on the topic. Like, I have a vague sense of it, and maybe it does or does not align with the way the other person is using it. And so that's an opportunity for me to ask them to define the term for me without completely having to say, "I have no idea what this term is. Please, oh, great sage, explain the meaning."

+ +

STEPHANIE: Are there times that you feel more or less comfortable doing that kind of reset?

+ +

JOËL: I think sometimes the fear is in breaking flow. And so you're doing a thing, and then somebody is trying to explain something, and you don't want to break out of that. Or you're trying to explain something, and you have to decide, is it worth making sure to explain a term, or do you keep moving? So I think that is a big concern.

+ +

And there is just the interpersonal concern of if there is less trust, do I want to put myself out there? Does somebody else maybe not feel comfortable you asked them to explain a term? Maybe they're using it wrong. It's not always good in a pairing situation to just come up and say, "Hey, that's not technically the adapter pattern; you're wrong. Let me pull out The Gang of Four book. You see on page 54..." that's not productive.

+ +

STEPHANIE: Yeah, for sure.

+ +

JOËL: So a lot of it, I think...and maybe this ties into your topic of communication while pairing. But ideally, you're working constructively with a person. And so debating definitions is not generally productive but asking someone, "What do you mean when you say this?" I find is a very helpful way to lead into that type of conversation.

+ +

STEPHANIE: Yeah, that's a great strategy because you're coming from a place of curiosity rather than a place of this is my definition, and it's the right definition, and so, therefore, you are wrong. [laughs]

+ +

JOËL: It's interesting the place that jargon occupies in our imagination of expertise. If you've ever seen any movie where they're trying to show that somebody is technically competent, they usually demonstrate that a person is competent by having them just spout out a long chain of jargon, and that makes them sound smart. But I think to a certain extent; maybe we believe it in the industry as well. If somebody can use a lot of terms and talk about a system using this very specific jargon, we tend to think that they're smart or at least look up to them a little bit.

+ +

STEPHANIE: Yeah, which I think isn't always the best assumption because I've certainly worked with folks who did throw out a lot of jargon but weren't necessarily, like you were saying, using it the way that I understood it, and that made communicating with them challenging.

+ +

I also think what true expertise really is is having the knowledge that when you use a jargony term that not everyone might be familiar with it, having the awareness to pause and ask someone how they're doing with the vocabulary and be able to tailor how you explain that term to that other person. I think that demonstrates a really deep level of understanding that doesn't get enough credit.

+ +

JOËL: I 100% agree. Jargon, vocabulary, it's a means to an end, not an end in and of itself. So the goal is to communicate clearly to others and maybe to help yourself in your own learning. And if you're not accomplishing those goals, then what's the point? I guess maybe there is another personal goal which is to sound smart, but that's not really a good goal, [laughs] especially not when the way you do that is by confusing everybody else in the room because they don't understand you, to make you try to feel smarter than them. Like, that's bad communication.

+ +

STEPHANIE: Yeah, for sure. I've definitely experienced listening to someone explain something and have to really think very hard about every single word that they're saying because they were using terms that are just less common. And so, in my brain, I had to map them to things that made sense to me, and things that I was familiar with that were the same concepts.

+ +

Like, I was experienced enough to have that shared understanding, but just the words that they used required another layer of brain work. Maybe we could have found a happy medium between them communicating the way that they expressed themselves the best with my ability to understand easily and quickly so that we could get on the same page.

+ +

JOËL: So you mentioned that there are sometimes situations where you're aware of a particular concept, but maybe you're just not aware that the term that somebody else is using maps to this concept you already understand. And I know that for me, oftentimes, being able to give a name to something that I understand is an incredibly powerful thing.

+ +

Even though I already know the idea of passing objects to another object in this particular configuration, or of wrapping things in some way or whatever the thing that I'm trying to do, all of a sudden, instead of it being a more nebulous concept in my head or a list of 10 steps or something like that, now I have one thing I can just point to and say it is this.

+ +

So that's been really helpful for me in my learning to be able to take a label and put it on something that I already know. And somehow, it cements the idea in my head and also then allows me to build on it to the next things that I want to learn.

+ +

STEPHANIE: Yeah, absolutely. It's really exciting when you're able to have that light-bulb moment when you have that precise term, or you learn that precise term for something that you have been wrestling with or experiencing for a while now.

+ +

I was just reminded of reading documentation. I have a very vivid memory of the first time I read; I don't know, even the Rails official docs, all of these terms that I didn't understand at the time. But then once I started digging into it, exploring, and just doing the work, when I revisited those docs, I could understand them a lot more comprehensively because I had experience with the things (There I am using things again.) [laughs] and seeing the terms for them and that helping solidify my understanding.

+ +

JOËL: I'm curious, in your personal learning, do you find it easier to encounter a term first and then learn what it means, or do the reverse, learn the concept first and then cap it off by being able to give it a name?

+ +

STEPHANIE: That's a good question. I think the latter because I've certainly spent a lot of time Googling terms and then reading whatever first search results came up and being like, okay, I think I got it, and then Googling the same term like two weeks later because I didn't really get it the first time. But whenever I come across a term for a concept I already am familiar with, it is like, oh yes, uh-huh! That really ends up sticking with me.

+ +

Matheus Sales' blog post that you mentioned earlier is a really great example of that term really standing out to me because I didn't know it at the time, but I suppose was seeking out something to describe the concept of connascence. So that was really cool and really memorable. What about you? Do you have a preferred way of learning new technical terms?

+ +

JOËL: I think there can be value to both approaches. But I'm with you; I think it generally is easier to add a name to a concept you already understand. And I experienced this pretty dramatically when I tried to get into functional programming.

+ +

So several years ago, I tried to learn the language Haskell which is notorious for being difficult to learn and very abstract and technical. And the way that the Haskell community typically tries to teach things is learn the fundamentals first, very top-down, learn the theory, and then, later on, you can do things in practice. So it's like before you can write an actual program, let us teach you about applicatives, and monads, and all these things that are really difficult to learn. And they're kind of scary technical terms.

+ +

So I choked out partway through, gave up on Haskell. A year later, got back into it, tried it again, choked out again. And then, eventually, I pivoted. I started getting into a similar language called Elm, which is similar syntax but compiles to JavaScript for the front end. And that community has the opposite philosophy when it comes to teaching. They want to get you productive as soon as possible. And you can learn some of the theory as you go along. And so with that, I felt like I was learning something new all the time and being productive as well, like, constantly adding new features to things in an application, and that's really exciting.

+ +

And what's really beautiful there is that you eventually learn a lot of the same concepts that you would learn in something like Haskell because the two languages share a lot of similar concepts. But instead of saying first, you need to learn about monads as a general concept, and then you can build a program; Elm says, build a bunch of programs first. We'll show you the basic syntax. And after you've built a bunch of them, you'll start realizing, wait a minute, these things all kind of look alike. There are patterns I'm starting to recognize.

+ +

And then you can just point to that and say, hey, that pattern that you started recognizing, and you see a bunch of times that's monad. You've known it all along, and now you can put a label on it. And you've gotten there. And so that's the way that I learned those concepts. And that was much easier for me than the approach of trying to learn the abstract concept first.

+ +

STEPHANIE: Monad is literally the word I just Googled earlier this week and still have a very, very hazy understanding of. So maybe I'll have to go learn Elm now. [chuckles]

+ +

JOËL: I recommend a lot of people to use that as their entry point into the statically typed functional programming world, just because of how much more shallow the learning curve is compared to alternatives. And I think a lot of it has to do with that approach of saying, let's get you productive quickly. Let's get you doing things. And eventually, patterns will emerge, and you can put names on them later. But we'll not make you learn all of the theory upfront, all the jargon.

+ +

STEPHANIE: Now that you do understand all the technical jargon around functional programming, how do you approach communicating about it when you do talk about Elm or those kinds of concepts?

+ +

JOËL: A lot of it depends on your audience. If you have an audience that already knows these concepts, then being able to use those names is really valuable because it's a shortcut. You can just say, oh yeah, this thing is a monad, and so, therefore, we can do these actions with it. And everybody in the audience just already knows monads have these properties. That's wonderful. Now I can follow to step two instead of having to have a slow build-up.

+ +

So if I'm writing an article or giving a talk, or even just having a conversation with someone, if I knew they didn't know the term, I would have to really build up to it, and maybe I wouldn't introduce the term at all. I would just talk about some of the properties that are interesting for the purpose of this particular demo.

+ +

But I would probably have to work up to it and say, "See, we have this simpler thing, and then this more complex thing. But here are the problems that we have with it. Here's a change we can make to our code that will make it work." And you walk through the process without necessarily getting into all of the theory. But with somebody else who did know, I could just say, "Oh, what we need here is monad." And they look at me, and they're like, "Oh, of course," and then we do it.

+ +

STEPHANIE: What you just described reminds me a lot of the WIRED Video Series, five levels of teaching where they have an expert come in and teach the same concept to different-aged people starting from young kids to an expert in their field as well. And I really liked how you answered that question just with the awareness that you tailor how you explain something to your audience because we could all benefit from just having that intentionality when we communicate in order to get the most value out of our interactions and knowledge sharing, and collaborative working.

+ +

JOËL: I think a theme that underlies a lot of what you and I have talked about today is just that communication, good communication is the fundamental value that we're going for here. And jargon and vocabulary can be something that empowers that but used poorly; it can also defeat that purpose. And most importantly, good communication starts with the audience, not with you. So when you work back from the audience, you can use the appropriate vocabulary and words that serve everybody and your ultimate goal of communicating.

+ +

STEPHANIE: I love that.

+ +

JOËL: So, Stephanie, thank you so much for joining us on The Bike Shed today. And as we wrap up, I wanted to ask you, what is a really fun piece of vocabulary that you’ve learned that you might want to share with the audience?

+ +

STEPHANIE: So lately, I learned the term WYSIWYG, which stands for What You See Is What You Get to describe text editing software that lets you see and edit the content as it would actually be displayed. So that was a fun, little term that someone brought up when we were paring and looking at some text editing code. And I was really excited because it sounds fun, and also, now I had just an opportunity to say it on a podcast. [laughs]

+ +

JOËL: It's amazing that an acronym that is that long has enough vowels in the right places that you can just pronounce it.

+ +

STEPHANIE: Oh yeah.

+ +

JOËL: WYSIWYG. That's a fun word to say.

+ +

STEPHANIE: 100%. I also try to pronounce all acronyms, regardless of how pronounceable they actually are. [laughs] Thanks for asking.

+ +

JOËL: With that, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

JOËL: The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Guest and fellow thoughtbotter Stephanie Minn and Joël chat about how the idea of specialized vocabulary came up during a discussion of the Ruby Science book. We have all these names for code smells and refactors. Before knowing these names, we often have a vague sense of the ideas but having a name makes them more real. They also give us ways to talk precisely about what we mean. However, there is a downside since not everyone is familiar with the jargon.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined with fellow thoughtboter Stephanie Minn.

+ +

STEPHANIE: Hey, Joël.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. Stephanie, what is new in your world?

+ +

STEPHANIE: Thanks for asking. I am on a new project I just started a few weeks ago, and I'm feeling the new project vibes, I think, kind of scoping out what's going on with the client with the work that they're doing. Trying to make a good impression. I think lately I've been in that mode of where can I find some work to do even when I'm just getting on boarded and learning the domain, trying to make those README updates in the areas that are a bit outdated, and yeah, just kind of along for the ride.

+ +

One thing that has been surprising already is that in my second week, the project pivoted into a different direction than what I was expecting. So that has been kind of exciting and also pretty interesting to see sometimes this stuff happens. I was brought on thinking that we were working on rebuilding the front end in React and TypeScript, pulling out pieces of their 15-year-old Rails monolith. So that was kind of one area that they decided to start with.

+ +

But recently, they actually decided to pivot to just revamping the look of the existing pages in the Rails app using the same templates and forms. So it's kind of shifted from more greenfield-esque work to figuring out what the heck's going on in this legacy codebase and making it a little bit more modern-looking and cleaning out the cobwebs, I suppose as we find them.

+ +

JOËL: As a consultant, how do you deal with that kind of dramatic shift in expectations?

+ +

STEPHANIE: I think it's tough because I necessarily wasn't in those conversations, and so I have to come at it with the understanding that they have a deep knowledge of the business and things that are going on behind the scenes that I don't, and I am coming in kind of with a fresh set of eyes. And it definitely raises some questions for me, right? Like, why now? What were the trade-offs that were made in the decisions?

+ +

And I hope that as a consultant, I can poke and prod a little bit to help them with the transition and also figuring out its impact on the rest of the team in a way maybe someone who is more familiar with the situation and more tied to the politics of the org might not have that perspective.

+ +

JOËL: I have a lot of questions here. But actually, I'm thinking that onboarding as a topic would probably make a good standalone episode. So maybe we'll have to bring you back for a future episode to talk about how to onboard well and how to deal with surprises.

+ +

STEPHANIE: Yeah, I think that's a great idea. What about you, Joël? What's going on in your world?

+ +

JOËL: I'm doing an integration with a third-party gem, and I am really struggling. And I've gotten to the point where I'm reading through the source of the gem to try to figure out some weird errors, some things that come up that are not documented. I think that's a really valuable skill. Ideally, you're not having to bring it out too often, but when you do, being able to drop into the code can really help unblock you or at least make some amount of progress.

+ +

STEPHANIE: Are you having to dig into the gem's code because you weren't able to find what you needed from the documentation?

+ +

JOËL: That's correct. I'm getting some cryptic errors where the gem is crashing, and I'm finding some lines in my logs that point back to the gem. And now I'm trying to reconstruct what is happening. Why is it not behaving the way it should be based on the documentation that I read?

+ +

STEPHANIE: Oh, that's tough. Getting into gem code is uncharted territory.

+ +

JOËL: It's nice when you're working with an open-source gem because the source is there, and you can just follow the stack trace and go through the code. Sometimes it's long and tedious, but it generally gives you results. It definitely is intimidating.

+ +

STEPHANIE: Yeah. When you're facing this kind of problem where you have no idea where the light at the end of the tunnel might be, how long do you spend with it? At what point do you take away with what you've learned and try to figure out a different approach?

+ +

JOËL: That's a good observation because digging through the source of a gem can definitely be a time sink. I think how much time I want to budget depends on a variety of other factors. How big of a problem is this? If I can't figure it out through reading the source, do I have alternate approaches to debug the problem, such as asking for help, opening an issue, reaching out to somebody else who's used it, complaining about it on The Bike Shed and hoping someone responds with an answer?

+ +

There are other options that I can do that might leave me blocked but maybe eventually give me results. The advantage with reading the source is that you're at least feeling like you're making progress.

+ +

STEPHANIE: Nice. Well, I wish you luck on that journey. [laughs] It sounds pretty tough. I'm sure that you'll get to one of those solutions and figure out how to get unblocked.

+ +

JOËL: I hope so. I'm pursuing a few strategies in tandem. So I've asked for help, but I'm also reading the source code. And between the two of those, I hope I'll get to a good solution.

+ +

So, Stephanie, last time you were on the show, you talked about your experience creating talk proposals for RubyConf. Have you heard back from them since then?

+ +

STEPHANIE: I have. I will be speaking at RubyConf Mini this year. And I'm really excited because this will be my first IRL conference talk. So last time, I recorded my talk for RubyConf, and this time I will be up on a stage in front of real people.

+ +

JOËL: That's really exciting. Congratulations.

+ +

STEPHANIE: Thanks.

+ +

JOËL: What is the topic of your talk?

+ +

STEPHANIE: I will be talking about pair programming and specifically pair programming through the lens of a framework called Nonviolent Communication, which is a framework I learned about through a friend who recommended the canonical book on it. And it's a self-help book, to be totally frank, but I found it so illuminating. It really changed how I communicated in my relationships in my personal life.

+ +

And the more time I spent with it, the more I realized that it would be a great application in pair programming because it's so collaborative and intimate. I've experienced the highs and lows of pair programming. You can feel so good when you are super connected with your pair. You make a lot of progress. You meet whatever professional goals that you might be meeting, and you have someone along for the ride the whole time. It can be just so rewarding.

+ +

But it can also be really challenging when you are having more of those interpersonal conflicts, and navigating that can be tough. And so I'm really excited to share this style of communication that might help others who want to take their pair programming to the next level and get the most out of that experience no matter who they're pairing with.

+ +

JOËL: I'm excited to hear this talk because pair programming has always been an important part of what we do at thoughtbot. And I think now that we're remote, we do a lot of remote pair programming. And the interpersonal interactions are a little bit different there than when you're physically in a room with each other, or you have to maybe pay a little bit more attention to them. I'm really excited to hear that. I think that's going to be really useful, not just for me but for a lot of the audience who are there.

+ +

STEPHANIE: Thanks. Joël, you have a talk accepted at RubyConf Mini too.

+ +

JOËL: Yes, I also had a talk accepted titled Teaching Ruby to Count. And it's going to be all about series, enumerators, enumerables, and ranges in Ruby and the cool things that you can do with them. So I'm really excited to share about that. I've done some deep dives on these topics, and I'm excited to share that with the broader Ruby community.

+ +

STEPHANIE: Nice. I'm really excited to hear more about it.

+ +

JOËL: Did you submit more than one proposal this year?

+ +

STEPHANIE: This year, I didn't. But I would love to get to a point where I have a lot of content on the backburner and can pull it out when CFP season rolls around to just have some more options. Yeah, I have all these ideas in my head. I think we talked about how we come up with content in our last episode. But yeah, having a content bank sounds really nice for the future, so maybe when that season rolls around, it is a lot easier to get the ball rolling on submitting. What about you? Did you submit more than one?

+ +

JOËL: I submitted two, but this is the one I was most excited about. I think the other idea was maybe a little bit more polished, but this one was a newer one I came up with towards the end of the CFP period. And I was like, ooh, I'm excited about this. I've just done a deep dive on enumerators, and I think there are some cool things to share with the community. And so that's what I'm excited to share about, and maybe that came through the proposal because that is what the committee picked. So I'm super happy to be talking about that.

+ +

STEPHANIE: Nice. Yeah, I was just thinking the same, that your excitement about it was probably palpable to the committee.

+ +

JOËL: For any of our viewers who are interested in coming to watch the talks by Stephanie and myself and plenty of other gifted speakers, this will be at RubyConf Mini in Providence, Rhode Island, from November 15th to 17th. And if you can't make it in person, the videos will be published online early in 2023. And we'll definitely share the links to that when they come out.

+ +

So as we mentioned in your last episode, thoughtbot has a book club where we've been discussing the book Ruby Science, which goes through a lot of code smells and talks about some various refactoring patterns that can be used to fix them. Most recently, we looked at a code smell that has a very evocative name; it's called shotgun surgery.

+ +

STEPHANIE: Yeah, it's a very visceral name for sure. I think that is what prompted this next topic that we're about to discuss because someone in the book club, another thoughtboter, mentioned that they were learning this term for the first time. But it made a lot of sense to them because they had experienced shotgun surgery and didn't have the term for it previously. Joël, do you mind giving the listeners a recap of what shotgun surgery is?

+ +

JOËL: So shotgun surgery is when in order to make a change to a codebase, you have to make a bunch of little changes in a lot of different files, a lot of different locations. And that means that all of these little pieces are weirdly coupled to each other in a way that to make one change, you have to make a bunch of little changes in a lot of places. And that results in a very high churn diff, and that's a common symptom of this problem.

+ +

STEPHANIE: Nice. Thanks for explaining.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPHANIE: I think I came away from that conversation thinking about the idea of learning new terms, especially technical ones, and the power that learning those terms can give you as a developer, especially when you're communicating with other people on your team.

+ +

JOËL: So you mentioned the value in communication there. Some terms have a very precise meaning, and so that allows you to communicate a very specific idea. How do you balance having some jargon and some terminology that allows you to speak very precisely versus having to learn all the terms? Because the more narrow the term is, the more terms you need to talk about all the different things.

+ +

STEPHANIE: That's a great question. I don't know if I have a great answer because I think I'm still on my journey. I have always noticed when developers I work with have that really precise, articulate technical vocabulary, probably because I don't. I am constantly referring to functions or classes as things, like, that thingy over there talks to this thing over here, and then does something. [laughs]

+ +

And I think it's because I maybe didn't always have that exposure to very precise technical vocabulary. And so I had an understanding of how things worked in my head, but I couldn't necessarily map that to words. And I'm also from California, so, I don't know, maybe some of that is showing through a little bit. [laughs]

+ +

But I've been trying to incorporate more technical terms when I speak and also in written form, too, such as in code review, because I want to be able to communicate more clearly my intentions and leave less room for ambiguity. Sometimes I've noticed when you do speak more casually about code, turns out other people can interpret it in different ways. And if you are using, like you said, that narrower technical term for it, that leaves less room for misunderstanding.

+ +

But in the same vein, I think a lot of people are like me, where they might not know the technical terms for things. And when you start using a lot of jargon like that, it can be a bit exclusive to folks earlier in their career, especially since software as an industry we have folks from all different backgrounds. We don't necessarily have the expectation of assured formal training. We want to be inclusive of people who came to this career from different places and make sure that we are speaking the same language. And so it's been top of mind for me thinking about how we can balance those two things. I don't know, what do you think?

+ +

JOËL: I want to speak to some of the value of precision first because I think there are a few different points. We have the value of precision, then we have the difficulty of learning vocabulary, and how are we inclusive of everyone. But on the topic of precision, I don't know if you saw not too long ago, another fellow thoughtboter, Matheus Sales, published an article on the thoughtbot blog about the concept of connascence. And he introduces this as a new set of vocabulary, not vocabulary that he's created but a vocabulary that is out there that not that many developers are aware of for different ways to talk about coupling.

+ +

So it's easy in a pull request to just say, "Oh, well, that thing looks coupled. How about this other way?" And then I respond, "Well, that's also coupled in a different way." And then we just go back and forth like, "Well, mine is more coupled than yours is," or whatever. And connascence provides a more precise, narrow vocabulary to talk about the different ways that things are coupled and which ones are more coupled than others. And so it allows us to break out of maybe those unproductive discussions because now we can talk about things in a more granular way.

+ +

STEPHANIE: Yeah, I loved that blog post. It was really exciting for me to pick up a new term to describe something that I had experienced, or seen in codebases, or felt the pain of, and be able to describe it more accurately. I'm curious, Joël, if you were to use that term next time, how would you make sure that folks also have the same level of familiarity with it?

+ +

JOËL: I think on a pull request, I would link to Matheus' article depending on...I might give a little bit of context in a comment. So I might say something like, "This area here is coupled. Here's a suggested refactor. It's also coupled but in a different way. It's because we've moved up this hierarchy of connascence from, you know, connascence of names to some other form" (I don't have them all memorized.) and then link to the article. And hopefully, that becomes the start of a productive discussion.

+ +

But yeah, having the resources you can link to people is great. And that's one of the nice things about text communication on a pull request is that you can just link to external resources that people can find helpful.

+ +

STEPHANIE: To continue talking about the value of precision and specialized vocabulary, Joël, I think you are a very articulate communicator. And I'm curious from your perspective if you have always been this way, if you've always wanted to collect technical terms to describe exactly what you want to convey, or if this was a bit of a journey for you to get to this level of clear communication in your technical speaking and writing.

+ +

JOËL: It's definitely been a journey. I think there are sort of two components to this; one is being able to communicate clearly to others; make sure that they understand what you're talking about. So for that, it's really important to be able to put yourself in somebody else's shoes.

+ +

So when I'm building a conference talk or writing up a blog post, I will try to read it or go through my slide deck and try to pretend that I am the audience. And then I ask myself the questions: where do I get confused? Where am I going to have questions? Maybe even where am I going to roll my eyes a little bit and be like, eh, I didn't agree with that leap of logic there; where are you going? And then shift back in author mode and say, how can I address these? How can I make my content speak to you in an area where maybe you disagreed, or you were confused?

+ +

So I kind of jump between moving from the audience seat to back to the author and try to make that material as much as possible resonate with those people.

+ +

STEPHANIE: Do you do that in more real-time communication, such as in meetings or in pairing?

+ +

JOËL: I think that's a little bit harder to do. And then it's maybe a little bit more of asking directly, either pausing to let people interject, or you can ask the question directly and say, "Are you familiar with this term?" That can also sometimes be tricky to manage because you don't want to make it sound like you think they don't know anything.

+ +

But you can also make it sound really natural in a conversation where you're like, "Oh, we're going to do this thing with a strategy pattern. Have you seen a strategy pattern before? Are you familiar with this? Great, let's keep moving." And if not, maybe it's like, "Hey, let's take a few minutes to talk about what the strategy pattern means."

+ +

STEPHANIE: I think you are really great at asking the audience about their level of familiarity with the content, especially in book club. I have definitely experienced just as a developer pairing, or in meetings, or whatnot times when people don't pause and ask. And usually, I have to muster up the courage to interrupt and ask, "Hey, what is X, Y, and Z?" And that is tough sometimes.

+ +

I am certainly comfortable with it in a space where there is trust developed in terms of I don't feel worried that people might question my level of familiarity or experience. And I can very enthusiastically say, "Hey, I don't know what this means. Could you please explain it?" But sometimes it can be a little tough when you might not have that relationship with someone, or you haven't talked about it, talked about assumptions about your knowledge or experience level upfront.

+ +

And so I have found that to be a really good way to build that trust to make sure that we aren't excluding folks is to just talk about some of that stuff, even before we start pairing or before a meeting. And that can really help with some of those miscommunications that might come down later in the process.

+ +

JOËL: It's interesting that you bring up miscommunication because I think sometimes, even though certain jargon can be very precise, sometimes people will not use it to mean exactly what its dictionary definition is. And so sometimes two people are using the same term, and you're not meaning quite the same thing.

+ +

And so sometimes I'll be pairing with someone, and I'll have to sort of pause and say, "Hey, wait a minute, you're using the term adapter in a certain way that seems to be a little bit different than the way I'm using it. Can you maybe tell me what your personal definition is? And I'll tell you mine, and we can reconcile those two together."

+ +

Sometimes that can also feel like a situation where maybe I'm hazy on the topic. Like, I have a vague sense of it, and maybe it does or does not align with the way the other person is using it. And so that's an opportunity for me to ask them to define the term for me without completely having to say, "I have no idea what this term is. Please, oh, great sage, explain the meaning."

+ +

STEPHANIE: Are there times that you feel more or less comfortable doing that kind of reset?

+ +

JOËL: I think sometimes the fear is in breaking flow. And so you're doing a thing, and then somebody is trying to explain something, and you don't want to break out of that. Or you're trying to explain something, and you have to decide, is it worth making sure to explain a term, or do you keep moving? So I think that is a big concern.

+ +

And there is just the interpersonal concern of if there is less trust, do I want to put myself out there? Does somebody else maybe not feel comfortable you asked them to explain a term? Maybe they're using it wrong. It's not always good in a pairing situation to just come up and say, "Hey, that's not technically the adapter pattern; you're wrong. Let me pull out The Gang of Four book. You see on page 54..." that's not productive.

+ +

STEPHANIE: Yeah, for sure.

+ +

JOËL: So a lot of it, I think...and maybe this ties into your topic of communication while pairing. But ideally, you're working constructively with a person. And so debating definitions is not generally productive but asking someone, "What do you mean when you say this?" I find is a very helpful way to lead into that type of conversation.

+ +

STEPHANIE: Yeah, that's a great strategy because you're coming from a place of curiosity rather than a place of this is my definition, and it's the right definition, and so, therefore, you are wrong. [laughs]

+ +

JOËL: It's interesting the place that jargon occupies in our imagination of expertise. If you've ever seen any movie where they're trying to show that somebody is technically competent, they usually demonstrate that a person is competent by having them just spout out a long chain of jargon, and that makes them sound smart. But I think to a certain extent; maybe we believe it in the industry as well. If somebody can use a lot of terms and talk about a system using this very specific jargon, we tend to think that they're smart or at least look up to them a little bit.

+ +

STEPHANIE: Yeah, which I think isn't always the best assumption because I've certainly worked with folks who did throw out a lot of jargon but weren't necessarily, like you were saying, using it the way that I understood it, and that made communicating with them challenging.

+ +

I also think what true expertise really is is having the knowledge that when you use a jargony term that not everyone might be familiar with it, having the awareness to pause and ask someone how they're doing with the vocabulary and be able to tailor how you explain that term to that other person. I think that demonstrates a really deep level of understanding that doesn't get enough credit.

+ +

JOËL: I 100% agree. Jargon, vocabulary, it's a means to an end, not an end in and of itself. So the goal is to communicate clearly to others and maybe to help yourself in your own learning. And if you're not accomplishing those goals, then what's the point? I guess maybe there is another personal goal which is to sound smart, but that's not really a good goal, [laughs] especially not when the way you do that is by confusing everybody else in the room because they don't understand you, to make you try to feel smarter than them. Like, that's bad communication.

+ +

STEPHANIE: Yeah, for sure. I've definitely experienced listening to someone explain something and have to really think very hard about every single word that they're saying because they were using terms that are just less common. And so, in my brain, I had to map them to things that made sense to me, and things that I was familiar with that were the same concepts.

+ +

Like, I was experienced enough to have that shared understanding, but just the words that they used required another layer of brain work. Maybe we could have found a happy medium between them communicating the way that they expressed themselves the best with my ability to understand easily and quickly so that we could get on the same page.

+ +

JOËL: So you mentioned that there are sometimes situations where you're aware of a particular concept, but maybe you're just not aware that the term that somebody else is using maps to this concept you already understand. And I know that for me, oftentimes, being able to give a name to something that I understand is an incredibly powerful thing.

+ +

Even though I already know the idea of passing objects to another object in this particular configuration, or of wrapping things in some way or whatever the thing that I'm trying to do, all of a sudden, instead of it being a more nebulous concept in my head or a list of 10 steps or something like that, now I have one thing I can just point to and say it is this.

+ +

So that's been really helpful for me in my learning to be able to take a label and put it on something that I already know. And somehow, it cements the idea in my head and also then allows me to build on it to the next things that I want to learn.

+ +

STEPHANIE: Yeah, absolutely. It's really exciting when you're able to have that light-bulb moment when you have that precise term, or you learn that precise term for something that you have been wrestling with or experiencing for a while now.

+ +

I was just reminded of reading documentation. I have a very vivid memory of the first time I read; I don't know, even the Rails official docs, all of these terms that I didn't understand at the time. But then once I started digging into it, exploring, and just doing the work, when I revisited those docs, I could understand them a lot more comprehensively because I had experience with the things (There I am using things again.) [laughs] and seeing the terms for them and that helping solidify my understanding.

+ +

JOËL: I'm curious, in your personal learning, do you find it easier to encounter a term first and then learn what it means, or do the reverse, learn the concept first and then cap it off by being able to give it a name?

+ +

STEPHANIE: That's a good question. I think the latter because I've certainly spent a lot of time Googling terms and then reading whatever first search results came up and being like, okay, I think I got it, and then Googling the same term like two weeks later because I didn't really get it the first time. But whenever I come across a term for a concept I already am familiar with, it is like, oh yes, uh-huh! That really ends up sticking with me.

+ +

Matheus Sales' blog post that you mentioned earlier is a really great example of that term really standing out to me because I didn't know it at the time, but I suppose was seeking out something to describe the concept of connascence. So that was really cool and really memorable. What about you? Do you have a preferred way of learning new technical terms?

+ +

JOËL: I think there can be value to both approaches. But I'm with you; I think it generally is easier to add a name to a concept you already understand. And I experienced this pretty dramatically when I tried to get into functional programming.

+ +

So several years ago, I tried to learn the language Haskell which is notorious for being difficult to learn and very abstract and technical. And the way that the Haskell community typically tries to teach things is learn the fundamentals first, very top-down, learn the theory, and then, later on, you can do things in practice. So it's like before you can write an actual program, let us teach you about applicatives, and monads, and all these things that are really difficult to learn. And they're kind of scary technical terms.

+ +

So I choked out partway through, gave up on Haskell. A year later, got back into it, tried it again, choked out again. And then, eventually, I pivoted. I started getting into a similar language called Elm, which is similar syntax but compiles to JavaScript for the front end. And that community has the opposite philosophy when it comes to teaching. They want to get you productive as soon as possible. And you can learn some of the theory as you go along. And so with that, I felt like I was learning something new all the time and being productive as well, like, constantly adding new features to things in an application, and that's really exciting.

+ +

And what's really beautiful there is that you eventually learn a lot of the same concepts that you would learn in something like Haskell because the two languages share a lot of similar concepts. But instead of saying first, you need to learn about monads as a general concept, and then you can build a program; Elm says, build a bunch of programs first. We'll show you the basic syntax. And after you've built a bunch of them, you'll start realizing, wait a minute, these things all kind of look alike. There are patterns I'm starting to recognize.

+ +

And then you can just point to that and say, hey, that pattern that you started recognizing, and you see a bunch of times that's monad. You've known it all along, and now you can put a label on it. And you've gotten there. And so that's the way that I learned those concepts. And that was much easier for me than the approach of trying to learn the abstract concept first.

+ +

STEPHANIE: Monad is literally the word I just Googled earlier this week and still have a very, very hazy understanding of. So maybe I'll have to go learn Elm now. [chuckles]

+ +

JOËL: I recommend a lot of people to use that as their entry point into the statically typed functional programming world, just because of how much more shallow the learning curve is compared to alternatives. And I think a lot of it has to do with that approach of saying, let's get you productive quickly. Let's get you doing things. And eventually, patterns will emerge, and you can put names on them later. But we'll not make you learn all of the theory upfront, all the jargon.

+ +

STEPHANIE: Now that you do understand all the technical jargon around functional programming, how do you approach communicating about it when you do talk about Elm or those kinds of concepts?

+ +

JOËL: A lot of it depends on your audience. If you have an audience that already knows these concepts, then being able to use those names is really valuable because it's a shortcut. You can just say, oh yeah, this thing is a monad, and so, therefore, we can do these actions with it. And everybody in the audience just already knows monads have these properties. That's wonderful. Now I can follow to step two instead of having to have a slow build-up.

+ +

So if I'm writing an article or giving a talk, or even just having a conversation with someone, if I knew they didn't know the term, I would have to really build up to it, and maybe I wouldn't introduce the term at all. I would just talk about some of the properties that are interesting for the purpose of this particular demo.

+ +

But I would probably have to work up to it and say, "See, we have this simpler thing, and then this more complex thing. But here are the problems that we have with it. Here's a change we can make to our code that will make it work." And you walk through the process without necessarily getting into all of the theory. But with somebody else who did know, I could just say, "Oh, what we need here is monad." And they look at me, and they're like, "Oh, of course," and then we do it.

+ +

STEPHANIE: What you just described reminds me a lot of the WIRED Video Series, five levels of teaching where they have an expert come in and teach the same concept to different-aged people starting from young kids to an expert in their field as well. And I really liked how you answered that question just with the awareness that you tailor how you explain something to your audience because we could all benefit from just having that intentionality when we communicate in order to get the most value out of our interactions and knowledge sharing, and collaborative working.

+ +

JOËL: I think a theme that underlies a lot of what you and I have talked about today is just that communication, good communication is the fundamental value that we're going for here. And jargon and vocabulary can be something that empowers that but used poorly; it can also defeat that purpose. And most importantly, good communication starts with the audience, not with you. So when you work back from the audience, you can use the appropriate vocabulary and words that serve everybody and your ultimate goal of communicating.

+ +

STEPHANIE: I love that.

+ +

JOËL: So, Stephanie, thank you so much for joining us on The Bike Shed today. And as we wrap up, I wanted to ask you, what is a really fun piece of vocabulary that you’ve learned that you might want to share with the audience?

+ +

STEPHANIE: So lately, I learned the term WYSIWYG, which stands for What You See Is What You Get to describe text editing software that lets you see and edit the content as it would actually be displayed. So that was a fun, little term that someone brought up when we were paring and looking at some text editing code. And I was really excited because it sounds fun, and also, now I had just an opportunity to say it on a podcast. [laughs]

+ +

JOËL: It's amazing that an acronym that is that long has enough vowels in the right places that you can just pronounce it.

+ +

STEPHANIE: Oh yeah.

+ +

JOËL: WYSIWYG. That's a fun word to say.

+ +

STEPHANIE: 100%. I also try to pronounce all acronyms, regardless of how pronounceable they actually are. [laughs] Thanks for asking.

+ +

JOËL: With that, shall we wrap up?

+ +

STEPHANIE: Let's wrap up.

+ +

JOËL: The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed, or reach me at @joelquen on Twitter, or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+2XtKh1sP + + ]]> + + Joël Quenneville + + + 355: Test Performance + https://bikeshed.thoughtbot.com/355 + 24166862-6b7d-4382-8014-be74d8248b28 + Tue, 20 Sep 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Guest Geoff Harcourt, CTO of CommonLit, joins Joël to talk about a thing that comes up with a lot with clients: the performance of their test suite. It's often a concern because with test suites, until it becomes a problem, people tend to not treat it very well, and people ask for help on making their test suites faster. Geoff shares how he handles a scenario like this at CommonLit. + 42:44 + no + + + Guest Geoff Harcourt, CTO of CommonLit, joins Joël to talk about a thing that comes up with a lot with clients: the performance of their test suite. It's often a concern because with test suites, until it becomes a problem, people tend to not treat it very well, and people ask for help on making their test suites faster. Geoff shares how he handles a scenario like this at CommonLit. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Geoff Harcourt (https://twitter.com/geoffharcourt) +Common Lit (https://www.commonlit.org/) +Cuprite driver (https://cuprite.rubycdp.com/) +Chrome DevTools Protocol (CDP) (https://chromedevtools.github.io/devtools-protocol/) +Factory Doctor (https://test-prof.evilmartians.io/#/profilers/factory_doctor) +Joël's RailsConf talk (https://www.youtube.com/watch?v=LOlG4kqfwcg) +Formal Methods (https://www.hillelwayne.com/post/formally-modeling-migrations/) +Rails multi-database support (https://guides.rubyonrails.org/active_record_multiple_databases.html) +Knapsack pro (https://knapsackpro.com/) +Prior episode with Eebs (https://www.bikeshed.fm/353) +Shopify article on skipping specs (https://shopify.engineering/spark-joy-by-running-fewer-tests) +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. And today, I'm joined by Geoff Harcourt, who is the CTO of CommonLit. +GEOFF: Hi, Joël. +JOËL: And together, we're here to share a little bit of what we've learned along the way. Geoff, can you briefly tell us what is CommonLit? What do you do? +GEOFF: CommonLit is a 501(c)(3) non-profit that delivers a literacy curriculum in English and Spanish to millions of students around the world. Most of our tools are free. So we take a lot of pride in delivering great tools to teachers and students who need them the most. +JOËL: And what does your role as CTO look like there? +GEOFF: So we have a small engineering team. There are nine of us, and we run a Rails monolith. I'd say a fair amount of the time; I'm hands down in the code. But I also do the things that an engineering head has to do, so working with vendors, and figuring out infrastructure, and hiring, and things like that. +JOËL: So that's quite a variety of things that you have to do. What is new in your world? What's something that you've encountered recently that's been fun or interesting? +GEOFF: It's the start of the school year in America, so traffic has gone from a very tiny amount over the summer to almost the highest load that we'll encounter all year. So we're at a new hosting provider this fall. So we're watching our infrastructure and keeping an eye on it. +The analogy that we've been using to describe this is like when you set up a bunch of plumbing, it looks like it all works, but until you really pump water through it, you don't see if there are any leaks. So things are in good shape right now, but it's a very exciting time of year for us. +JOËL: Have you ever done some actual plumbing yourself? +GEOFF: I am very, very bad at home repair. But I have fixed a toilet or two. I've installed a water filter but nothing else. What about you? +JOËL: I've done a little bit of it when I was younger with my dad. Like, I actually welded copper pipes and that kind of thing. +GEOFF: Oh, that's amazing. That's cool. Nice. +JOËL: So I've definitely felt that thing where you turn the water source back on, and it's like, huh, let's see, is this joint going to leak, or are we good? +GEOFF: Yeah, they don't have CI for plumbing, right? +JOËL: [laughs] You know, test it in production, right? +GEOFF: Yeah. [laughs] So we're really watching right now traffic starting to rise as students and teachers are coming back. And we're also figuring out all kinds of things that we want to do to do better monitoring of our application, so some of this is watching metrics to see if things happen. But some of this is also doing some simulated user activity after we do deploys. So we're using some automated browsers with Cypress to log into our application and do some user flows, and then report back on the results. +JOËL: So is this kind of like a feature test in CI, except that you're running it in production? +GEOFF: Yeah. Smoke test is the word that we've settled on for it, but we run it against our production server every time we deploy. And it's a small suite. It's nowhere as big as our big Capybara suite that we run in CI, but we're trying to get feedback in less than six minutes. That's sort of the goal. +In addition to running tests, we also take screenshots with a tool called Percy, and that's a visual regression testing tool. So we get to see the screenshots, and if they differ by more than one pixel, we get a ping that lets us know that maybe our CSS has moved around or something like that. +JOËL: Has that caught some visual bugs for you? +GEOFF: Definitely. The state of CSS at CommonLit was very messy when I arrived, and it's gotten better, but it still definitely needs some love. There are some false positives, but it's been really, really nice to be able to see visual changes on our production pages and then be able to approve them or know that there's something we have to go back and fix. +JOËL: I'm curious, for this smoke test suite, how long does it take to run? +GEOFF: We run it in parallel. It runs on Buildkite, which is the same tool that we use to orchestrate our CI, and the longest test takes about five minutes. It signs in as a teacher, creates an account. It creates a class; it invites the student to that class. It then logs out, logs in as that student creates the student account, signs in as the student, joins the class. +It then assigns a lesson to the student then the student goes and takes the lesson. And then, when the student submits the lesson, then the test is over. And that confirms all of the most critical flows that we would want someone to drop what they were doing if it's broken, you know, account creation, class creation, lesson creation, and students taking a lesson. +JOËL: So you're compressing the first few weeks of school into five minutes. +GEOFF: Yes. And I pity the school that has thousands of fake teachers, all named Aaron McCarronson at the school. +JOËL: [laughs] +GEOFF: But we go through and delete that data every once in a while. But we have a marketer who just started at CommonLit maybe a few weeks ago, and she thought that someone was spamming our signup form because she said, "I see hundreds of teachers named Aaron McCarronson in our user list." +JOËL: You had to admit that you were the spammer? +GEOFF: Yes, I did. [laughs] We now have some controls to filter those people out of reports. But it's always funny when you look at the list, and you see all these fake people there. +JOËL: Do you have any rate limiting on your site? +GEOFF: Yeah, we do quite a bit of it, actually. Some of it we do through Cloudflare. We have tools that limit a certain flow, like people trying to credential stuffing our password, our user sign-in forms. But we also do some further stuff to prevent people from hitting key endpoints. We use Rack::Attack, which is a really nice framework. Have you had to do that in client work with clients setting that stuff up? +JOËL: I've used Rack:Attack before. +GEOFF: Yeah, it's got a reasonably nice interface that you can work with. And I always worry about accidentally setting those things up to be too sensitive, and then you get lots of stuff back. One issue that we sometimes find is that lots of kids at the same school are sharing an IP address. So that's not the thing that we want to use for rate limiting. We want to use some other criteria for rate limiting. +JOËL: Right, right. Do you ever find that you rate limit your smoke tests? Or have you had to bypass the rate limiting in the smoke tests? +GEOFF: Our smoke tests bypass our rate limiting and our bot detection. So they've got some fingerprints they use to bypass that. +JOËL: That must have been an interesting day at the office. +GEOFF: Yes. [laughter] With all of these things, I think it's a big challenge to figure out, and it's similar when you're making tests for development, how to make tests that are high signal. So if a test is failing really frequently, even if it's testing something that's worthwhile, if people start ignoring it, then it stops having value as a piece of signal. So we've invested a ton of time in making our test suite as reliable as possible, but you sometimes do have these things that just require a change. +I've become a really big fan of...there's a Ruby driver for Capybara called Cuprite, and it doesn't control chrome with Chrome Driver or with Selenium. It controls it with the Chrome DevTools protocol, so it's like a direct connection into the browser. And we find that it's very, very fast and very, very reliable. So we saw that our Capybara specs got significantly more reliable when we started using this as our driver. +JOËL: Is this because it's not actually moving the mouse around and clicking but instead issuing commands in the background? +GEOFF: Yeah. My understanding of this is a little bit hazy. But I think that Selenium and ChromeDriver are communicating over a network pipe, and sometimes that network pipe is a little bit lossy. And so it results in asynchronous commands where maybe you don't get the feedback back after something happens. And CDP is what Chrome's team and I think what Puppeteer uses to control things directly. So it's great. +And you can even do things with it. Like, you can simulate different time zone for a user almost natively. You can speed up or slow down the traveling of time and the direction of time in the browser and all kinds of things like that. You can flip it into mobile mode so that the device reports that it's a touch browser, even though it's not. We have a set of mobile specs where we flip it with CDP into mobile mode, and that's been really good too. +Do you find when you're doing client work that you have a demand to build mobile-specific specs for system tests? +JOËL: Generally not, no. +GEOFF: You've managed to escape it. +JOËL: For something that's specific to mobile, maybe one or two tests that have a weird interaction that we know is different on mobile. But in general, we're not doing the whole suite under mobile and the whole suite under desktop. +GEOFF: When you hand off a project...it's been a while since you and I have worked together. +JOËL: For those who don't know, Geoff used to be with us at thoughtbot. We were colleagues. +GEOFF: Yeah, for a while. I remember my very first thoughtbot Summer Summit; you gave a really cool lightning talk about Eleanor of Aquitaine. +JOËL: [laughs] +GEOFF: That was great. So when you're handing a project off to a client after your ending, do you find that there's a transition period where you're educating them about the norms of the test suite before you leave it in their hands? +JOËL: It depends a lot on the client. With many clients, we're working alongside an existing dev team. And so it's not so much one big handoff at the end as it is just building that in the day-to-day, making sure that we are integrating with the team from the outset of the engagement. +So one thing that does come up a lot with clients is the performance of their test suite. That's often a concern because the test suite until it becomes a problem, people tend to not treat it very well. And by the time that you're bringing on an external consultant to help, generally, that's one of the areas of the code that's been a little bit neglected. And so people ask for help on making their test suite faster. Is that something that you've had to deal with at CommonLit as well? +GEOFF: Yeah, that's a great question. We have struggled a lot with the speed that our test suite...the time it takes for our test suite to run. We've done a few things to improve it. The first is that we have quite a bit of caching that we do in our CI suite around dependencies. So gems get cached separately from NPM packages and browser assets. So all three of those things are independently cached. +And then, we run our suites in parallel. Our Jest specs get split up into eight containers. Our Ruby non-system tests...I'd like to say unit tests, but we all know that some of those are actually integration tests. +JOËL: [laughs] +GEOFF: But those tests run in 15 containers, and they start the moment gems are built. So they don't wait for NPM packages. They don't wait for assets. They immediately start going. And then our system specs as soon as the assets are built kick off and start running. And we actually run that in 40 parallel containers so we can get everything finished. +So our CI suite can finish...if there are no dependency bumps and no asset bumps, our specs suite you can finish in just under five minutes. But if you add up all of that time, cumulatively, it's something like 75 minutes is the total execution as it goes. Have you tried FactoryDoctor before for speeding up test suites? +JOËL: This is the gem from Evil Martians? +GEOFF: Yeah, it's part of TestProf, which is their really, really unbelievable toolkit for improving specs, and they have a whole bunch of things. But one of them will tell you how many invocations of FactoryBot factories each factory got. So you can see a user factory was fired 13,000 times in the test suite. It can even do some tagging where it can go in and add metadata to your specs to show which ones might be candidates for optimization. +JOËL: I gave a talk at RailsConf this year titled Your Tests Are Making Too Many Database Calls. +GEOFF: Nice. +JOËL: And one of the things I talked about was creating a lot more data via factories than you think that you are. And I should give a shout-out to FactoryProf for finding those. +GEOFF: Yeah, it's kind of a silent killer with the test suite, and you really don't think that you're doing a whole lot with it, and then you see how many associations. How do you fight that tension between creating enough data that things are realistic versus the streamlining of not creating extraneous things or having maybe mystery guests via associations and things like that? +JOËL: I try to have my base factories be as minimal as possible. So if there's a line in there that I can remove, and the factory or the model still saves, then it should be removed. Some associations, you can't do that if there's a foreign key constraint, and so then I'll leave it in. But I am a very hardcore minimalist, at least with the base factory. +GEOFF: I think that makes a lot of sense. We use foreign keys all over the place because we're always worried about somehow inserting student data that we can't recover with a bug. So we'd rather blow up than think we recorded it. And as a result, sometimes setting up specs for things like a student answering a multiple choice question on a quiz ends up being this sort of if you give a mouse a cookie thing where it's you need the answer options. You need the question. You need the quiz. You need the activity. You need the roster, the students to be in the roster. There has to be a teacher for the roster. It just balloons out because everything has a foreign key. +JOËL: The database requires it, but the test doesn't really care. It's just like, give me a student and make it valid. +GEOFF: Yes, yeah. And I find that that challenge is really hard. And sometimes, you don't see how hard it is to enforce things like database integrity until you have a lot of concurrency going on in your application. It was a very rude surprise to me to find out that browser requests if you have multiple servers going on might not necessarily be served in the order that they were made. +JOËL: [laughs] So you're talking about a scenario where you're running multiple instances of your app. You make two requests from, say, two browser tabs, and somehow they get served from two different instances? +GEOFF: Or not even two browser tabs. Imagine you have a situation where you're auto-saving. +JOËL: Oooh, background requests. +GEOFF: Yeah. So one of the coolest features we have at CommonLit is that students can annotate and highlight a text. And then, the teachers can see the annotations and highlights they've made, and it's actually part of their assignment often to highlight key evidence in a passage. And those things all fire in the background asynchronously so that it doesn't block the student from doing more stuff. +But it also means that potentially if they make two changes to a highlight really quickly that they might arrive out of order. So we've had to do some things to make sure that we're receiving in the right order and that we're not blowing away data that was supposed to be there. +Just think about in a Heroku environment, for example, which is where we used to be, you'd have four dynos running. If dyno one takes too long to serve the thing for dyno two, request one may finish after request two. That was a very, very rude surprise to learn that the world was not as clean and neat as I thought. +JOËL: I've had to do something similar where I'm making a bunch of background requests to a server. And even with a single dyno, it is possible for your request to come back out of order just because of how TCP works. So if it's waiting for a packet and you have two of these requests that went out not too long before each other, there's no guarantee that all the packets for request one come back before all the packets from request two. +GEOFF: Yeah, what are the strategies for on the client side for dealing with that kind of out-of-order response? +JOËL: Find some way to effectively version the requests that you make. Timestamp is an easy one. Whenever a request comes in, you take the response from the latest timestamp, and that wins out. +GEOFF: Yeah, we've started doing some unique IDs. And part of the unique ID is the browser's timestamp. We figure that no one would try to hack themselves and intentionally screw up their own data by submitting out of order. +JOËL: Right, right. +GEOFF: It's funny how you have to pick something to trust. [laughs] +JOËL: I'd imagine, in this case, if somebody did mess around with it, they would really only just be screwing up their own UI. It's not like that's going to then potentially crash the server because of something, and then you've got a potential vector for a denial of service. +GEOFF: Yeah, yeah, that's always what we're worried about, and we have to figure out how to trust these sorts of requests as what's a valid thing and what is, as you're saying, is just the user hurting themselves as opposed to hurting someone else's stuff? +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +GEOFF: You were talking about test suites. What are some things that you have found are consistently problems in real-world apps, but they're really, really hard to test in a test suite? +JOËL: Difficult to test or difficult to optimize for performance? +GEOFF: Maybe difficult to test. +JOËL: Third-party integrations. Anything that's over the network that's going to be difficult. Complex interactions that involve some heavy frontend but then also need a lot of backend processing potentially with asynchronous workers or something like that, there are a lot of techniques that we can use to make all those play together, but that means there's a lot of complexity in that test. +GEOFF: Yeah, definitely. I've taken a deep interest in what I'm sure there's a better technical term for this, but what I call network hostile environments or bandwidth hostile environments. And we see this a lot with kids. Especially during the pandemic, kids would often be trying to do their assignments from home. And maybe there are five kids in the house, and they're all trying to do their homework at the same time. And they're all sharing a home internet connection. +Maybe they're in the basement because they're trying to get some peace and quiet so they can do their assignment or something like that. And maybe they're not strongly connected. And the challenge of dealing with intermittent connectivity is such an interesting problem, very frustrating but very interesting to deal with. +JOËL: Have you explored at all the concept of Formal Methods to model or verify situations like that? +GEOFF: No, but I'm intrigued. Tell me more. +JOËL: I've not tried it myself. But I've read some articles on the topic. Hillel Wayne is a good person to follow for this. +GEOFF: Oh yeah. +JOËL: But it's really fascinating when you'll see, okay, here are some invariants and things. And then here are some things that you set up some basic properties for a system. And then some of these modeling languages will then poke holes and say, hey, it's possible for this 10-step sequence of events to happen that will then crash your server. Because you didn't think that it's possible for five people to be making concurrent requests, and then one of them fails and retries, whatever the steps are. So it's really good at modeling situations that, as developers, we don't always have great intuition, things like parallelism. +GEOFF: Yeah, that sounds so interesting. I'm going to add that to my list of reading for the fall. Once the school year calms down, I feel like I can dig into some technical topics again. I've got this book sitting right next to my desk, Designing Data-Intensive Applications. I saw it referenced somewhere on Twitter, and I did the thing where I got really excited about the book, bought it, and then didn't have time to read it. So it's just sitting there unopened next to my desk, taunting me. +JOËL: What's the 30-second spiel for what is a data-intensive app, and why should we design for it differently? +GEOFF: You know, that's a great question. I'd probably find out if I'd dug further into the book. +JOËL: [laughs] +GEOFF: I have found at CommonLit that we...I had a couple of clients at thoughtbot that dealt with data at the scale that we deal with here. And I'm sure there are bigger teams doing, quote, "bigger data" than we're doing. But it really does seem like one of our key challenges is making sure that we just move data around fast enough that nothing becomes a bottleneck. +We made a really key optimization in our application last year where we changed the way that we autosave students' answers as they go. And it resulted in a massive increase in throughput for us because we went from trying to store updated versions of the students' final answers to just storing essentially a draft and often storing that draft in local storage in the browser and then updating it on the server when we could. +And then, as a result of this, we're making key updates to the table where we store a student's answers much less frequently. And that has a huge impact because, in addition to being one of the biggest tables at CommonLit...it's got almost a billion recorded answers that we've gotten from students over the years. But because we're not writing to it as often, it also means that reads that are made from the table, like when the teacher is getting a report for how the students are doing in a class or when a principal is looking at how a school is doing, now, those queries are seeing less contention from ongoing writes. And so we've seen a nice improvement. +JOËL: One strategy I've seen for that sort of problem, especially when you have a very write-heavy table but that also has a different set of users that needs to read from it, is to set up a read replica. So you have your main that is being written to, and then the read replica is used for reports and people who need to look at the data without being in contention with the table being written. +GEOFF: Yeah, Rails multi-DB support now that it's native to the framework is excellent. It's so nice to be able to just drop that in and fire it up and have it work. We used to use a solution that Instacart had built. It was great for our needs, but it wasn't native to the framework. +So every single time we upgraded Rails, we had to cross our fingers and hope that it didn't, you know, whatever private APIs of ActiveRecord it was using hadn't broken. So now that that stuff, which I think was open sourced from GitHub's multi-database implementation, so now that that's all native in Rails, it's really, really nice to be able to use that. +JOËL: So these kinds of database tricks can help make the application much more performant. You'd mentioned earlier that when you were trying to make your test performant that you had introduced parallelism, and I feel like that's maybe a bit of an intimidating thing for a lot of people. How would you go about converting a test suite that's just vanilla RSpec, single-threaded, and then moving it in a direction of being more parallel? +GEOFF: There's a really, really nice tool called Knapsack, which has a free version. But the pro version, I feel like if you're spending any money at all on CI, it's immediately worth the cost. I think it's something like $75 a month for each suite that you run on it. And Knapsack does this dynamic allocation of tests across containers. +And it interfaces with several of the popular CI providers so that it looks at environment variables and can tell how many containers you're splitting across. It'll do some things, like if some of your containers start early and some of them start late, it will distribute the work so that they all end at the same time, which is really nice. +We've preferred CI providers that charge by the minute. So rather than just paying for a service that we might not be using, we've used services like Semaphore, and right now, we're on Buildkite, which charge by the minute, which means that you can decide to do as much parallelism as you want. You're just paying for the compute time as you run things. +JOËL: So that would mean that two minutes of sequential build time costs just the same as splitting it up in parallel and doing two simultaneous minutes of build time. +GEOFF: Yeah, that is almost true. There's a little bit of setup time when a container spins up. And that's one of the key things that we optimize. I guess if we ran 200 containers if we were like Shopify or something like that, we could technically make our CI suite finish faster, but it might cost us three times as much. +Because if it takes a container 30 seconds to spin up and to get ready, that's 30 seconds of dead time when you're not testing, but you're paying for the compute. So that's one of the key optimizations that we make is figuring out how many containers do we need to finish fast when we're not just blowing time on starting and finishing? +JOËL: Right, because there is a startup cost for each container. +GEOFF: Yeah, and during the work day when our engineers are working along, we spin up 200 EC2 machines or 150 EC2 machines, and they're there in the fleet, and they're ready to go to run CI jobs for us. But if you don't have enough machines, then you have jobs that sit around waiting to start, that sort of thing. So there's definitely a tension between figuring out how much parallelism you're going to do. But I feel like to start; you could always break your test suite into four pieces or two pieces and just see if you get some benefit to running a smaller number of tests in parallel. +JOËL: So, manually splitting up the test suite. +GEOFF: No, no, using something like Knapsack Pro where you're feeding it the suite, and then it's dividing up the tests for you. I think manually splitting up the suite is probably not a good practice overall because I'm guessing you'll probably spend more engineering time on fiddling with which tests go where such that it wouldn't be cost-effective. +JOËL: So I've spent a lot of time recently working to improve a parallel test suite. And one of the big problems that you have is trying to make sure that all of your parallel surfaces are being used efficiently, so you have to split the work evenly. So if you said you have 70 minutes worth of work, if you give 50 minutes to one worker and 20 minutes to the other, that means that your total test suite is still 50 minutes, and that's not good. +So ideally, you split it as evenly as possible. So I think there are three evolutionary steps on the path here. So you start off, and you're going to manually split things out. So you're going to say our biggest chunk of tests by time are the feature specs. We'll make them almost like a separate suite. Then we'll make the models and controllers and views their own thing, and that's roughly half and half, and run those. And maybe you're off by a little bit, but it's still better than putting them all in one. +It becomes difficult, though, to balance all of these because then one might get significantly longer than the other then, you have to manually rebalance it. It works okay if you're only splitting it among two workers. But if you're having to split it among 4, 8, 16, and more, it's not manageable to do this, at least not by hand. +If you want to get fancy, you can try to automate that process and record a timing file of how long every file takes. And then when you kick off the build process, look at that timing file and say, okay, we have 70 minutes, and then we'll just split the file so that we have roughly 70 divided by number of workers' files or minutes of work in each process. And that's what gems like parallel_tests do. And Knapsack's Classic mode works like this as well. That's decently good. +But the problem is you're working off of past information. And so if the test has changed or just if it's highly variable, you might not get a balanced set of workers. And as you mentioned, there's a startup cost, and so not all of your workers boot up at the same time. And so you might still have a very uneven amount of work done by each worker by statically determining the work to be done via a timing file. +So the third evolution here is a dynamic or a self-balancing approach where you just put all of the tests or the files in a queue and then just have every worker pull one or two tests when it's ready to work. So that way, if something takes a lot longer than expected, well, it's just not pulling more from the queue. And everybody else still pulls, and they end up all balancing each other out. And then ideally, every worker finishes work at exactly the same time. And that's how you know you got the most value you could out of your parallel processes. +GEOFF: Yeah, there's something about watching all the jobs finish in almost exactly, you know, within 10 seconds of each other. It just feels very, very satisfying. I think in addition to getting this dynamic splitting where you're getting either per file or per example split across to get things finishing at the same time, we've really valued getting fast feedback. +So I mentioned before that our Jest specs start the moment NPM packages get built. So as soon as there's JavaScripts that can be executed in test, those kick-off. As soon as our gems are ready, the RSpec non-system tests go off, and they start running specs immediately. So we get that really, really fast feedback. +Unfortunately, the browser tests take the longest because they have to wait for the most setup. They have the most dependencies. And then they also run the slowest because they run in the browser and everything. But I think when things are really well-oiled, you watch all of those containers end at roughly the same time, and it feels very satisfying. +JOËL: So, a few weeks ago, on an episode of The Bike Shed, I talked with Eebs Kobeissi about dependency graphs and how I'm super excited about it. And I think I see a dependency graph in what you're describing here in that some things only depend on the gem file, and so they can start working. But other things also depend on the NPM packages. And so your build pipeline is not one linear process or one linear process that forks into other linear processes; it's actually a dependency graph. +GEOFF: That is very true. And the CI tool we used to use called Semaphore actually does a nice job of drawing the dependency graph between all of your steps. Buildkite does not have that, but we do have a bunch of steps that have to wait for other steps to finish. And we do it in our wiki. On our repo, we do have a diagram of how all of this works. +We found that one of the things that was most wasteful for us in CI was rebuilding gems, reinstalling NPM packages (We use Yarn but same thing.), and then rebuilding browser assets. So at the very start of every CI run, we build hashes of a bunch of files in the repository. And then, we use those hashes to name Docker images that contain the outputs of those files so that we are able to skip huge parts of our CI suite if things have already happened. +So I'll give an example if Ruby gems have not changed, which we would know by the Gemfile.lock not having changed, then we know that we can reuse a previously built gems image that has the gems that just gets melted in, same thing with yarn.lock. If yarn.lock hasn't changed, then we don't have to build NPM packages. We know that that already exists somewhere in our Docker registry. +In addition to skipping steps by not redoing work, we also have started to experiment...actually, in response to a comment that Chris Toomey made in a prior Bike Shed episode, we've started to experiment with skipping irrelevant steps. So I'll give an example of this if no Ruby files have changed in our repository, we don't run our RSpec unit tests. We just know that those are valid. There's nothing that needs to be rerun. +Similarly, if no JavaScript has changed, we don't run our Jest tests because we assume that everything is good. We don't lint our views with erb-lint if our view files haven't changed. We don't lint our factories if the model or the database hasn't changed. So we've got all these things to skip key types of processing. +I always try to err on the side of not having a false pass. So I'm sure we could shave this even tighter and do even less work and sometimes finish the build even faster. But I don't want to ever have a thing where the build passes and we get false confidence. +JOËL: Right. Right. So you're using a heuristic that eliminates the really obvious tests that don't need to be run but the ones that maybe are a little bit more borderline, you keep them in. Shaving two seconds is not worth missing a failure. +GEOFF: Yeah. And I've read things about big enterprises doing very sophisticated versions of this where they're guessing at which CI specs might be most relevant and things like that. We're nowhere near that level of sophistication right now. +But I do think that once you get your test suite parallelized and you're not doing wasted work in the form of rebuilding dependencies or rebuilding assets that don't need to be rebuilt, there is some maybe not low, maybe medium hanging fruit that you can use to get some extra oomph out of your test suite. +JOËL: I really like that you brought up this idea of infrastructure and skipping. I think in my own way of thinking about improving test suites, there are three broad categories of approaches you can take. One variable you get to work with is that total number of time single-threaded, so you mentioned 70 minutes. You can make that 70 minutes shorter by avoiding database writes where you don't need them, all the common tricks that we would do to actually change the test themselves. Then we can change...as another variable; we get to work with parallelism, we talked about that. +And then finally, there's all that other stuff that's not actually executing RSpec like you said, loading the gems, installing NPM packages, Docker images. All of those, if we can skip work running migrations, setting up a database, if there are situations where we can improve the speed there, that also improves the total time. +GEOFF: Yeah, there are so many little things that you can pick at to...like, one of the slowest things for us is Elasticsearch. And so we really try to limit the number of specs that use Elasticsearch if we can. You actually have to opt-in to using Elasticsearch on a spec, or else we silently mock and disable all of the things that happen there. +When you're looking at that first variable that you were talking about, just sort of the overall time, beyond using FactoryDoctor and FactoryProf, is there anything else that you've used to just identify the most egregious offenders in a test suite and then figure out if they're worth it? +JOËL: One thing you can do is hook into Active Support notification to try to find database writes. And so you can find, oh, here's where all of the...this test is making way too many database writes for some reason, or it's making a lot, maybe I should take a look at it; it's a hotspot. +GEOFF: Oh, that's really nice. There's one that I've always found is like a big offender, which is people doing negative expectations in system specs. +JOËL: Oh, for their Capybara wait time. +GEOFF: Yeah. So there's a really cool gem, and the name of it is eluding me right now. But there's a gem that raises a special exception if Capybara waits the full time for something to happen. So it lets you know that those things exist. And so we've done a lot of like hunting for...Knapsack will report the slowest examples in your test suite. So we've done some stuff to look for the slowest files and then look to see if there are examples of these negative expectations that are waiting 10 seconds or waiting 8 seconds before they fail. +JOËL: Right. Some files are slow, but they're slow for a reason. Like, a feature spec is going to be much slower than a model test. But the model tests might be very wasteful and because you have so many of them, if you're doing the same pattern in a bunch of them or if it's a factory that's reused across a lot of them, then a small fix there can have some pretty big ripple effects. +GEOFF: Yeah, I think that's true. Have you ever done any evaluation of test suite to see what files or examples you could throw away? +JOËL: Not holistically. I think it's more on an ad hoc basis. You find a place, and you're like, oh, these tests we probably don't need them. We can throw them out. I have found dead tests, tests that are not executed but still committed to the repo. +GEOFF: [laughs] +JOËL: It's just like, hey, I'm going to get a lot of red in my diff today. +GEOFF: That always feels good to have that diff-y check-in, and it's 250 lines or 1,000 lines of red and 1 line of green. +JOËL: So that's been a pretty good overview of a lot of different areas related to performance and infrastructure around tests. Thank you so much, Geoff, for joining us today on The Bike Shed to talk about your experience at CommonLit doing this. Do you have any final words for our listeners? +GEOFF: Yeah. CommonLit is hiring a senior full-stack engineer, so if you'd like to work on Rails and TypeScript in a place with a great test suite and a great team. I've been here for five years, and it's a really, really excellent place to work. And also, it's been really a pleasure to catch up with you again, Joël. +JOËL: And, Geoff, where can people find you online? +GEOFF: I'm Geoff with a G, G-E-O-F-F Harcourt, @geoffharcourt. And that's my name on Twitter, and it's my name on GitHub, so you can find me there. +JOËL: And we'll make sure to include a link to your Twitter profile in the show notes. +The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Guest Geoff Harcourt, CTO of CommonLit, joins Joël to talk about a thing that comes up with a lot with clients: the performance of their test suite. It's often a concern because with test suites, until it becomes a problem, people tend to not treat it very well, and people ask for help on making their test suites faster. Geoff shares how he handles a scenario like this at CommonLit.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by Geoff Harcourt, who is the CTO of CommonLit.

+ +

GEOFF: Hi, Joël.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. Geoff, can you briefly tell us what is CommonLit? What do you do?

+ +

GEOFF: CommonLit is a 501(c)(3) non-profit that delivers a literacy curriculum in English and Spanish to millions of students around the world. Most of our tools are free. So we take a lot of pride in delivering great tools to teachers and students who need them the most.

+ +

JOËL: And what does your role as CTO look like there?

+ +

GEOFF: So we have a small engineering team. There are nine of us, and we run a Rails monolith. I'd say a fair amount of the time; I'm hands down in the code. But I also do the things that an engineering head has to do, so working with vendors, and figuring out infrastructure, and hiring, and things like that.

+ +

JOËL: So that's quite a variety of things that you have to do. What is new in your world? What's something that you've encountered recently that's been fun or interesting?

+ +

GEOFF: It's the start of the school year in America, so traffic has gone from a very tiny amount over the summer to almost the highest load that we'll encounter all year. So we're at a new hosting provider this fall. So we're watching our infrastructure and keeping an eye on it.

+ +

The analogy that we've been using to describe this is like when you set up a bunch of plumbing, it looks like it all works, but until you really pump water through it, you don't see if there are any leaks. So things are in good shape right now, but it's a very exciting time of year for us.

+ +

JOËL: Have you ever done some actual plumbing yourself?

+ +

GEOFF: I am very, very bad at home repair. But I have fixed a toilet or two. I've installed a water filter but nothing else. What about you?

+ +

JOËL: I've done a little bit of it when I was younger with my dad. Like, I actually welded copper pipes and that kind of thing.

+ +

GEOFF: Oh, that's amazing. That's cool. Nice.

+ +

JOËL: So I've definitely felt that thing where you turn the water source back on, and it's like, huh, let's see, is this joint going to leak, or are we good?

+ +

GEOFF: Yeah, they don't have CI for plumbing, right?

+ +

JOËL: [laughs] You know, test it in production, right?

+ +

GEOFF: Yeah. [laughs] So we're really watching right now traffic starting to rise as students and teachers are coming back. And we're also figuring out all kinds of things that we want to do to do better monitoring of our application, so some of this is watching metrics to see if things happen. But some of this is also doing some simulated user activity after we do deploys. So we're using some automated browsers with Cypress to log into our application and do some user flows, and then report back on the results.

+ +

JOËL: So is this kind of like a feature test in CI, except that you're running it in production?

+ +

GEOFF: Yeah. Smoke test is the word that we've settled on for it, but we run it against our production server every time we deploy. And it's a small suite. It's nowhere as big as our big Capybara suite that we run in CI, but we're trying to get feedback in less than six minutes. That's sort of the goal.

+ +

In addition to running tests, we also take screenshots with a tool called Percy, and that's a visual regression testing tool. So we get to see the screenshots, and if they differ by more than one pixel, we get a ping that lets us know that maybe our CSS has moved around or something like that.

+ +

JOËL: Has that caught some visual bugs for you?

+ +

GEOFF: Definitely. The state of CSS at CommonLit was very messy when I arrived, and it's gotten better, but it still definitely needs some love. There are some false positives, but it's been really, really nice to be able to see visual changes on our production pages and then be able to approve them or know that there's something we have to go back and fix.

+ +

JOËL: I'm curious, for this smoke test suite, how long does it take to run?

+ +

GEOFF: We run it in parallel. It runs on Buildkite, which is the same tool that we use to orchestrate our CI, and the longest test takes about five minutes. It signs in as a teacher, creates an account. It creates a class; it invites the student to that class. It then logs out, logs in as that student creates the student account, signs in as the student, joins the class.

+ +

It then assigns a lesson to the student then the student goes and takes the lesson. And then, when the student submits the lesson, then the test is over. And that confirms all of the most critical flows that we would want someone to drop what they were doing if it's broken, you know, account creation, class creation, lesson creation, and students taking a lesson.

+ +

JOËL: So you're compressing the first few weeks of school into five minutes.

+ +

GEOFF: Yes. And I pity the school that has thousands of fake teachers, all named Aaron McCarronson at the school.

+ +

JOËL: [laughs]

+ +

GEOFF: But we go through and delete that data every once in a while. But we have a marketer who just started at CommonLit maybe a few weeks ago, and she thought that someone was spamming our signup form because she said, "I see hundreds of teachers named Aaron McCarronson in our user list."

+ +

JOËL: You had to admit that you were the spammer?

+ +

GEOFF: Yes, I did. [laughs] We now have some controls to filter those people out of reports. But it's always funny when you look at the list, and you see all these fake people there.

+ +

JOËL: Do you have any rate limiting on your site?

+ +

GEOFF: Yeah, we do quite a bit of it, actually. Some of it we do through Cloudflare. We have tools that limit a certain flow, like people trying to credential stuffing our password, our user sign-in forms. But we also do some further stuff to prevent people from hitting key endpoints. We use Rack::Attack, which is a really nice framework. Have you had to do that in client work with clients setting that stuff up?

+ +

JOËL: I've used Rack:Attack before.

+ +

GEOFF: Yeah, it's got a reasonably nice interface that you can work with. And I always worry about accidentally setting those things up to be too sensitive, and then you get lots of stuff back. One issue that we sometimes find is that lots of kids at the same school are sharing an IP address. So that's not the thing that we want to use for rate limiting. We want to use some other criteria for rate limiting.

+ +

JOËL: Right, right. Do you ever find that you rate limit your smoke tests? Or have you had to bypass the rate limiting in the smoke tests?

+ +

GEOFF: Our smoke tests bypass our rate limiting and our bot detection. So they've got some fingerprints they use to bypass that.

+ +

JOËL: That must have been an interesting day at the office.

+ +

GEOFF: Yes. [laughter] With all of these things, I think it's a big challenge to figure out, and it's similar when you're making tests for development, how to make tests that are high signal. So if a test is failing really frequently, even if it's testing something that's worthwhile, if people start ignoring it, then it stops having value as a piece of signal. So we've invested a ton of time in making our test suite as reliable as possible, but you sometimes do have these things that just require a change.

+ +

I've become a really big fan of...there's a Ruby driver for Capybara called Cuprite, and it doesn't control chrome with Chrome Driver or with Selenium. It controls it with the Chrome DevTools protocol, so it's like a direct connection into the browser. And we find that it's very, very fast and very, very reliable. So we saw that our Capybara specs got significantly more reliable when we started using this as our driver.

+ +

JOËL: Is this because it's not actually moving the mouse around and clicking but instead issuing commands in the background?

+ +

GEOFF: Yeah. My understanding of this is a little bit hazy. But I think that Selenium and ChromeDriver are communicating over a network pipe, and sometimes that network pipe is a little bit lossy. And so it results in asynchronous commands where maybe you don't get the feedback back after something happens. And CDP is what Chrome's team and I think what Puppeteer uses to control things directly. So it's great.

+ +

And you can even do things with it. Like, you can simulate different time zone for a user almost natively. You can speed up or slow down the traveling of time and the direction of time in the browser and all kinds of things like that. You can flip it into mobile mode so that the device reports that it's a touch browser, even though it's not. We have a set of mobile specs where we flip it with CDP into mobile mode, and that's been really good too.

+ +

Do you find when you're doing client work that you have a demand to build mobile-specific specs for system tests?

+ +

JOËL: Generally not, no.

+ +

GEOFF: You've managed to escape it.

+ +

JOËL: For something that's specific to mobile, maybe one or two tests that have a weird interaction that we know is different on mobile. But in general, we're not doing the whole suite under mobile and the whole suite under desktop.

+ +

GEOFF: When you hand off a project...it's been a while since you and I have worked together.

+ +

JOËL: For those who don't know, Geoff used to be with us at thoughtbot. We were colleagues.

+ +

GEOFF: Yeah, for a while. I remember my very first thoughtbot Summer Summit; you gave a really cool lightning talk about Eleanor of Aquitaine.

+ +

JOËL: [laughs]

+ +

GEOFF: That was great. So when you're handing a project off to a client after your ending, do you find that there's a transition period where you're educating them about the norms of the test suite before you leave it in their hands?

+ +

JOËL: It depends a lot on the client. With many clients, we're working alongside an existing dev team. And so it's not so much one big handoff at the end as it is just building that in the day-to-day, making sure that we are integrating with the team from the outset of the engagement.

+ +

So one thing that does come up a lot with clients is the performance of their test suite. That's often a concern because the test suite until it becomes a problem, people tend to not treat it very well. And by the time that you're bringing on an external consultant to help, generally, that's one of the areas of the code that's been a little bit neglected. And so people ask for help on making their test suite faster. Is that something that you've had to deal with at CommonLit as well?

+ +

GEOFF: Yeah, that's a great question. We have struggled a lot with the speed that our test suite...the time it takes for our test suite to run. We've done a few things to improve it. The first is that we have quite a bit of caching that we do in our CI suite around dependencies. So gems get cached separately from NPM packages and browser assets. So all three of those things are independently cached.

+ +

And then, we run our suites in parallel. Our Jest specs get split up into eight containers. Our Ruby non-system tests...I'd like to say unit tests, but we all know that some of those are actually integration tests.

+ +

JOËL: [laughs]

+ +

GEOFF: But those tests run in 15 containers, and they start the moment gems are built. So they don't wait for NPM packages. They don't wait for assets. They immediately start going. And then our system specs as soon as the assets are built kick off and start running. And we actually run that in 40 parallel containers so we can get everything finished.

+ +

So our CI suite can finish...if there are no dependency bumps and no asset bumps, our specs suite you can finish in just under five minutes. But if you add up all of that time, cumulatively, it's something like 75 minutes is the total execution as it goes. Have you tried FactoryDoctor before for speeding up test suites?

+ +

JOËL: This is the gem from Evil Martians?

+ +

GEOFF: Yeah, it's part of TestProf, which is their really, really unbelievable toolkit for improving specs, and they have a whole bunch of things. But one of them will tell you how many invocations of FactoryBot factories each factory got. So you can see a user factory was fired 13,000 times in the test suite. It can even do some tagging where it can go in and add metadata to your specs to show which ones might be candidates for optimization.

+ +

JOËL: I gave a talk at RailsConf this year titled Your Tests Are Making Too Many Database Calls.

+ +

GEOFF: Nice.

+ +

JOËL: And one of the things I talked about was creating a lot more data via factories than you think that you are. And I should give a shout-out to FactoryProf for finding those.

+ +

GEOFF: Yeah, it's kind of a silent killer with the test suite, and you really don't think that you're doing a whole lot with it, and then you see how many associations. How do you fight that tension between creating enough data that things are realistic versus the streamlining of not creating extraneous things or having maybe mystery guests via associations and things like that?

+ +

JOËL: I try to have my base factories be as minimal as possible. So if there's a line in there that I can remove, and the factory or the model still saves, then it should be removed. Some associations, you can't do that if there's a foreign key constraint, and so then I'll leave it in. But I am a very hardcore minimalist, at least with the base factory.

+ +

GEOFF: I think that makes a lot of sense. We use foreign keys all over the place because we're always worried about somehow inserting student data that we can't recover with a bug. So we'd rather blow up than think we recorded it. And as a result, sometimes setting up specs for things like a student answering a multiple choice question on a quiz ends up being this sort of if you give a mouse a cookie thing where it's you need the answer options. You need the question. You need the quiz. You need the activity. You need the roster, the students to be in the roster. There has to be a teacher for the roster. It just balloons out because everything has a foreign key.

+ +

JOËL: The database requires it, but the test doesn't really care. It's just like, give me a student and make it valid.

+ +

GEOFF: Yes, yeah. And I find that that challenge is really hard. And sometimes, you don't see how hard it is to enforce things like database integrity until you have a lot of concurrency going on in your application. It was a very rude surprise to me to find out that browser requests if you have multiple servers going on might not necessarily be served in the order that they were made.

+ +

JOËL: [laughs] So you're talking about a scenario where you're running multiple instances of your app. You make two requests from, say, two browser tabs, and somehow they get served from two different instances?

+ +

GEOFF: Or not even two browser tabs. Imagine you have a situation where you're auto-saving.

+ +

JOËL: Oooh, background requests.

+ +

GEOFF: Yeah. So one of the coolest features we have at CommonLit is that students can annotate and highlight a text. And then, the teachers can see the annotations and highlights they've made, and it's actually part of their assignment often to highlight key evidence in a passage. And those things all fire in the background asynchronously so that it doesn't block the student from doing more stuff.

+ +

But it also means that potentially if they make two changes to a highlight really quickly that they might arrive out of order. So we've had to do some things to make sure that we're receiving in the right order and that we're not blowing away data that was supposed to be there.

+ +

Just think about in a Heroku environment, for example, which is where we used to be, you'd have four dynos running. If dyno one takes too long to serve the thing for dyno two, request one may finish after request two. That was a very, very rude surprise to learn that the world was not as clean and neat as I thought.

+ +

JOËL: I've had to do something similar where I'm making a bunch of background requests to a server. And even with a single dyno, it is possible for your request to come back out of order just because of how TCP works. So if it's waiting for a packet and you have two of these requests that went out not too long before each other, there's no guarantee that all the packets for request one come back before all the packets from request two.

+ +

GEOFF: Yeah, what are the strategies for on the client side for dealing with that kind of out-of-order response?

+ +

JOËL: Find some way to effectively version the requests that you make. Timestamp is an easy one. Whenever a request comes in, you take the response from the latest timestamp, and that wins out.

+ +

GEOFF: Yeah, we've started doing some unique IDs. And part of the unique ID is the browser's timestamp. We figure that no one would try to hack themselves and intentionally screw up their own data by submitting out of order.

+ +

JOËL: Right, right.

+ +

GEOFF: It's funny how you have to pick something to trust. [laughs]

+ +

JOËL: I'd imagine, in this case, if somebody did mess around with it, they would really only just be screwing up their own UI. It's not like that's going to then potentially crash the server because of something, and then you've got a potential vector for a denial of service.

+ +

GEOFF: Yeah, yeah, that's always what we're worried about, and we have to figure out how to trust these sorts of requests as what's a valid thing and what is, as you're saying, is just the user hurting themselves as opposed to hurting someone else's stuff?

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

GEOFF: You were talking about test suites. What are some things that you have found are consistently problems in real-world apps, but they're really, really hard to test in a test suite?

+ +

JOËL: Difficult to test or difficult to optimize for performance?

+ +

GEOFF: Maybe difficult to test.

+ +

JOËL: Third-party integrations. Anything that's over the network that's going to be difficult. Complex interactions that involve some heavy frontend but then also need a lot of backend processing potentially with asynchronous workers or something like that, there are a lot of techniques that we can use to make all those play together, but that means there's a lot of complexity in that test.

+ +

GEOFF: Yeah, definitely. I've taken a deep interest in what I'm sure there's a better technical term for this, but what I call network hostile environments or bandwidth hostile environments. And we see this a lot with kids. Especially during the pandemic, kids would often be trying to do their assignments from home. And maybe there are five kids in the house, and they're all trying to do their homework at the same time. And they're all sharing a home internet connection.

+ +

Maybe they're in the basement because they're trying to get some peace and quiet so they can do their assignment or something like that. And maybe they're not strongly connected. And the challenge of dealing with intermittent connectivity is such an interesting problem, very frustrating but very interesting to deal with.

+ +

JOËL: Have you explored at all the concept of Formal Methods to model or verify situations like that?

+ +

GEOFF: No, but I'm intrigued. Tell me more.

+ +

JOËL: I've not tried it myself. But I've read some articles on the topic. Hillel Wayne is a good person to follow for this.

+ +

GEOFF: Oh yeah.

+ +

JOËL: But it's really fascinating when you'll see, okay, here are some invariants and things. And then here are some things that you set up some basic properties for a system. And then some of these modeling languages will then poke holes and say, hey, it's possible for this 10-step sequence of events to happen that will then crash your server. Because you didn't think that it's possible for five people to be making concurrent requests, and then one of them fails and retries, whatever the steps are. So it's really good at modeling situations that, as developers, we don't always have great intuition, things like parallelism.

+ +

GEOFF: Yeah, that sounds so interesting. I'm going to add that to my list of reading for the fall. Once the school year calms down, I feel like I can dig into some technical topics again. I've got this book sitting right next to my desk, Designing Data-Intensive Applications. I saw it referenced somewhere on Twitter, and I did the thing where I got really excited about the book, bought it, and then didn't have time to read it. So it's just sitting there unopened next to my desk, taunting me.

+ +

JOËL: What's the 30-second spiel for what is a data-intensive app, and why should we design for it differently?

+ +

GEOFF: You know, that's a great question. I'd probably find out if I'd dug further into the book.

+ +

JOËL: [laughs]

+ +

GEOFF: I have found at CommonLit that we...I had a couple of clients at thoughtbot that dealt with data at the scale that we deal with here. And I'm sure there are bigger teams doing, quote, "bigger data" than we're doing. But it really does seem like one of our key challenges is making sure that we just move data around fast enough that nothing becomes a bottleneck.

+ +

We made a really key optimization in our application last year where we changed the way that we autosave students' answers as they go. And it resulted in a massive increase in throughput for us because we went from trying to store updated versions of the students' final answers to just storing essentially a draft and often storing that draft in local storage in the browser and then updating it on the server when we could.

+ +

And then, as a result of this, we're making key updates to the table where we store a student's answers much less frequently. And that has a huge impact because, in addition to being one of the biggest tables at CommonLit...it's got almost a billion recorded answers that we've gotten from students over the years. But because we're not writing to it as often, it also means that reads that are made from the table, like when the teacher is getting a report for how the students are doing in a class or when a principal is looking at how a school is doing, now, those queries are seeing less contention from ongoing writes. And so we've seen a nice improvement.

+ +

JOËL: One strategy I've seen for that sort of problem, especially when you have a very write-heavy table but that also has a different set of users that needs to read from it, is to set up a read replica. So you have your main that is being written to, and then the read replica is used for reports and people who need to look at the data without being in contention with the table being written.

+ +

GEOFF: Yeah, Rails multi-DB support now that it's native to the framework is excellent. It's so nice to be able to just drop that in and fire it up and have it work. We used to use a solution that Instacart had built. It was great for our needs, but it wasn't native to the framework.

+ +

So every single time we upgraded Rails, we had to cross our fingers and hope that it didn't, you know, whatever private APIs of ActiveRecord it was using hadn't broken. So now that that stuff, which I think was open sourced from GitHub's multi-database implementation, so now that that's all native in Rails, it's really, really nice to be able to use that.

+ +

JOËL: So these kinds of database tricks can help make the application much more performant. You'd mentioned earlier that when you were trying to make your test performant that you had introduced parallelism, and I feel like that's maybe a bit of an intimidating thing for a lot of people. How would you go about converting a test suite that's just vanilla RSpec, single-threaded, and then moving it in a direction of being more parallel?

+ +

GEOFF: There's a really, really nice tool called Knapsack, which has a free version. But the pro version, I feel like if you're spending any money at all on CI, it's immediately worth the cost. I think it's something like $75 a month for each suite that you run on it. And Knapsack does this dynamic allocation of tests across containers.

+ +

And it interfaces with several of the popular CI providers so that it looks at environment variables and can tell how many containers you're splitting across. It'll do some things, like if some of your containers start early and some of them start late, it will distribute the work so that they all end at the same time, which is really nice.

+ +

We've preferred CI providers that charge by the minute. So rather than just paying for a service that we might not be using, we've used services like Semaphore, and right now, we're on Buildkite, which charge by the minute, which means that you can decide to do as much parallelism as you want. You're just paying for the compute time as you run things.

+ +

JOËL: So that would mean that two minutes of sequential build time costs just the same as splitting it up in parallel and doing two simultaneous minutes of build time.

+ +

GEOFF: Yeah, that is almost true. There's a little bit of setup time when a container spins up. And that's one of the key things that we optimize. I guess if we ran 200 containers if we were like Shopify or something like that, we could technically make our CI suite finish faster, but it might cost us three times as much.

+ +

Because if it takes a container 30 seconds to spin up and to get ready, that's 30 seconds of dead time when you're not testing, but you're paying for the compute. So that's one of the key optimizations that we make is figuring out how many containers do we need to finish fast when we're not just blowing time on starting and finishing?

+ +

JOËL: Right, because there is a startup cost for each container.

+ +

GEOFF: Yeah, and during the work day when our engineers are working along, we spin up 200 EC2 machines or 150 EC2 machines, and they're there in the fleet, and they're ready to go to run CI jobs for us. But if you don't have enough machines, then you have jobs that sit around waiting to start, that sort of thing. So there's definitely a tension between figuring out how much parallelism you're going to do. But I feel like to start; you could always break your test suite into four pieces or two pieces and just see if you get some benefit to running a smaller number of tests in parallel.

+ +

JOËL: So, manually splitting up the test suite.

+ +

GEOFF: No, no, using something like Knapsack Pro where you're feeding it the suite, and then it's dividing up the tests for you. I think manually splitting up the suite is probably not a good practice overall because I'm guessing you'll probably spend more engineering time on fiddling with which tests go where such that it wouldn't be cost-effective.

+ +

JOËL: So I've spent a lot of time recently working to improve a parallel test suite. And one of the big problems that you have is trying to make sure that all of your parallel surfaces are being used efficiently, so you have to split the work evenly. So if you said you have 70 minutes worth of work, if you give 50 minutes to one worker and 20 minutes to the other, that means that your total test suite is still 50 minutes, and that's not good.

+ +

So ideally, you split it as evenly as possible. So I think there are three evolutionary steps on the path here. So you start off, and you're going to manually split things out. So you're going to say our biggest chunk of tests by time are the feature specs. We'll make them almost like a separate suite. Then we'll make the models and controllers and views their own thing, and that's roughly half and half, and run those. And maybe you're off by a little bit, but it's still better than putting them all in one.

+ +

It becomes difficult, though, to balance all of these because then one might get significantly longer than the other then, you have to manually rebalance it. It works okay if you're only splitting it among two workers. But if you're having to split it among 4, 8, 16, and more, it's not manageable to do this, at least not by hand.

+ +

If you want to get fancy, you can try to automate that process and record a timing file of how long every file takes. And then when you kick off the build process, look at that timing file and say, okay, we have 70 minutes, and then we'll just split the file so that we have roughly 70 divided by number of workers' files or minutes of work in each process. And that's what gems like parallel_tests do. And Knapsack's Classic mode works like this as well. That's decently good.

+ +

But the problem is you're working off of past information. And so if the test has changed or just if it's highly variable, you might not get a balanced set of workers. And as you mentioned, there's a startup cost, and so not all of your workers boot up at the same time. And so you might still have a very uneven amount of work done by each worker by statically determining the work to be done via a timing file.

+ +

So the third evolution here is a dynamic or a self-balancing approach where you just put all of the tests or the files in a queue and then just have every worker pull one or two tests when it's ready to work. So that way, if something takes a lot longer than expected, well, it's just not pulling more from the queue. And everybody else still pulls, and they end up all balancing each other out. And then ideally, every worker finishes work at exactly the same time. And that's how you know you got the most value you could out of your parallel processes.

+ +

GEOFF: Yeah, there's something about watching all the jobs finish in almost exactly, you know, within 10 seconds of each other. It just feels very, very satisfying. I think in addition to getting this dynamic splitting where you're getting either per file or per example split across to get things finishing at the same time, we've really valued getting fast feedback.

+ +

So I mentioned before that our Jest specs start the moment NPM packages get built. So as soon as there's JavaScripts that can be executed in test, those kick-off. As soon as our gems are ready, the RSpec non-system tests go off, and they start running specs immediately. So we get that really, really fast feedback.

+ +

Unfortunately, the browser tests take the longest because they have to wait for the most setup. They have the most dependencies. And then they also run the slowest because they run in the browser and everything. But I think when things are really well-oiled, you watch all of those containers end at roughly the same time, and it feels very satisfying.

+ +

JOËL: So, a few weeks ago, on an episode of The Bike Shed, I talked with Eebs Kobeissi about dependency graphs and how I'm super excited about it. And I think I see a dependency graph in what you're describing here in that some things only depend on the gem file, and so they can start working. But other things also depend on the NPM packages. And so your build pipeline is not one linear process or one linear process that forks into other linear processes; it's actually a dependency graph.

+ +

GEOFF: That is very true. And the CI tool we used to use called Semaphore actually does a nice job of drawing the dependency graph between all of your steps. Buildkite does not have that, but we do have a bunch of steps that have to wait for other steps to finish. And we do it in our wiki. On our repo, we do have a diagram of how all of this works.

+ +

We found that one of the things that was most wasteful for us in CI was rebuilding gems, reinstalling NPM packages (We use Yarn but same thing.), and then rebuilding browser assets. So at the very start of every CI run, we build hashes of a bunch of files in the repository. And then, we use those hashes to name Docker images that contain the outputs of those files so that we are able to skip huge parts of our CI suite if things have already happened.

+ +

So I'll give an example if Ruby gems have not changed, which we would know by the Gemfile.lock not having changed, then we know that we can reuse a previously built gems image that has the gems that just gets melted in, same thing with yarn.lock. If yarn.lock hasn't changed, then we don't have to build NPM packages. We know that that already exists somewhere in our Docker registry.

+ +

In addition to skipping steps by not redoing work, we also have started to experiment...actually, in response to a comment that Chris Toomey made in a prior Bike Shed episode, we've started to experiment with skipping irrelevant steps. So I'll give an example of this if no Ruby files have changed in our repository, we don't run our RSpec unit tests. We just know that those are valid. There's nothing that needs to be rerun.

+ +

Similarly, if no JavaScript has changed, we don't run our Jest tests because we assume that everything is good. We don't lint our views with erb-lint if our view files haven't changed. We don't lint our factories if the model or the database hasn't changed. So we've got all these things to skip key types of processing.

+ +

I always try to err on the side of not having a false pass. So I'm sure we could shave this even tighter and do even less work and sometimes finish the build even faster. But I don't want to ever have a thing where the build passes and we get false confidence.

+ +

JOËL: Right. Right. So you're using a heuristic that eliminates the really obvious tests that don't need to be run but the ones that maybe are a little bit more borderline, you keep them in. Shaving two seconds is not worth missing a failure.

+ +

GEOFF: Yeah. And I've read things about big enterprises doing very sophisticated versions of this where they're guessing at which CI specs might be most relevant and things like that. We're nowhere near that level of sophistication right now.

+ +

But I do think that once you get your test suite parallelized and you're not doing wasted work in the form of rebuilding dependencies or rebuilding assets that don't need to be rebuilt, there is some maybe not low, maybe medium hanging fruit that you can use to get some extra oomph out of your test suite.

+ +

JOËL: I really like that you brought up this idea of infrastructure and skipping. I think in my own way of thinking about improving test suites, there are three broad categories of approaches you can take. One variable you get to work with is that total number of time single-threaded, so you mentioned 70 minutes. You can make that 70 minutes shorter by avoiding database writes where you don't need them, all the common tricks that we would do to actually change the test themselves. Then we can change...as another variable; we get to work with parallelism, we talked about that.

+ +

And then finally, there's all that other stuff that's not actually executing RSpec like you said, loading the gems, installing NPM packages, Docker images. All of those, if we can skip work running migrations, setting up a database, if there are situations where we can improve the speed there, that also improves the total time.

+ +

GEOFF: Yeah, there are so many little things that you can pick at to...like, one of the slowest things for us is Elasticsearch. And so we really try to limit the number of specs that use Elasticsearch if we can. You actually have to opt-in to using Elasticsearch on a spec, or else we silently mock and disable all of the things that happen there.

+ +

When you're looking at that first variable that you were talking about, just sort of the overall time, beyond using FactoryDoctor and FactoryProf, is there anything else that you've used to just identify the most egregious offenders in a test suite and then figure out if they're worth it?

+ +

JOËL: One thing you can do is hook into Active Support notification to try to find database writes. And so you can find, oh, here's where all of the...this test is making way too many database writes for some reason, or it's making a lot, maybe I should take a look at it; it's a hotspot.

+ +

GEOFF: Oh, that's really nice. There's one that I've always found is like a big offender, which is people doing negative expectations in system specs.

+ +

JOËL: Oh, for their Capybara wait time.

+ +

GEOFF: Yeah. So there's a really cool gem, and the name of it is eluding me right now. But there's a gem that raises a special exception if Capybara waits the full time for something to happen. So it lets you know that those things exist. And so we've done a lot of like hunting for...Knapsack will report the slowest examples in your test suite. So we've done some stuff to look for the slowest files and then look to see if there are examples of these negative expectations that are waiting 10 seconds or waiting 8 seconds before they fail.

+ +

JOËL: Right. Some files are slow, but they're slow for a reason. Like, a feature spec is going to be much slower than a model test. But the model tests might be very wasteful and because you have so many of them, if you're doing the same pattern in a bunch of them or if it's a factory that's reused across a lot of them, then a small fix there can have some pretty big ripple effects.

+ +

GEOFF: Yeah, I think that's true. Have you ever done any evaluation of test suite to see what files or examples you could throw away?

+ +

JOËL: Not holistically. I think it's more on an ad hoc basis. You find a place, and you're like, oh, these tests we probably don't need them. We can throw them out. I have found dead tests, tests that are not executed but still committed to the repo.

+ +

GEOFF: [laughs]

+ +

JOËL: It's just like, hey, I'm going to get a lot of red in my diff today.

+ +

GEOFF: That always feels good to have that diff-y check-in, and it's 250 lines or 1,000 lines of red and 1 line of green.

+ +

JOËL: So that's been a pretty good overview of a lot of different areas related to performance and infrastructure around tests. Thank you so much, Geoff, for joining us today on The Bike Shed to talk about your experience at CommonLit doing this. Do you have any final words for our listeners?

+ +

GEOFF: Yeah. CommonLit is hiring a senior full-stack engineer, so if you'd like to work on Rails and TypeScript in a place with a great test suite and a great team. I've been here for five years, and it's a really, really excellent place to work. And also, it's been really a pleasure to catch up with you again, Joël.

+ +

JOËL: And, Geoff, where can people find you online?

+ +

GEOFF: I'm Geoff with a G, G-E-O-F-F Harcourt, @geoffharcourt. And that's my name on Twitter, and it's my name on GitHub, so you can find me there.

+ +

JOËL: And we'll make sure to include a link to your Twitter profile in the show notes.

+ +

The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Guest Geoff Harcourt, CTO of CommonLit, joins Joël to talk about a thing that comes up with a lot with clients: the performance of their test suite. It's often a concern because with test suites, until it becomes a problem, people tend to not treat it very well, and people ask for help on making their test suites faster. Geoff shares how he handles a scenario like this at CommonLit.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by Geoff Harcourt, who is the CTO of CommonLit.

+ +

GEOFF: Hi, Joël.

+ +

JOËL: And together, we're here to share a little bit of what we've learned along the way. Geoff, can you briefly tell us what is CommonLit? What do you do?

+ +

GEOFF: CommonLit is a 501(c)(3) non-profit that delivers a literacy curriculum in English and Spanish to millions of students around the world. Most of our tools are free. So we take a lot of pride in delivering great tools to teachers and students who need them the most.

+ +

JOËL: And what does your role as CTO look like there?

+ +

GEOFF: So we have a small engineering team. There are nine of us, and we run a Rails monolith. I'd say a fair amount of the time; I'm hands down in the code. But I also do the things that an engineering head has to do, so working with vendors, and figuring out infrastructure, and hiring, and things like that.

+ +

JOËL: So that's quite a variety of things that you have to do. What is new in your world? What's something that you've encountered recently that's been fun or interesting?

+ +

GEOFF: It's the start of the school year in America, so traffic has gone from a very tiny amount over the summer to almost the highest load that we'll encounter all year. So we're at a new hosting provider this fall. So we're watching our infrastructure and keeping an eye on it.

+ +

The analogy that we've been using to describe this is like when you set up a bunch of plumbing, it looks like it all works, but until you really pump water through it, you don't see if there are any leaks. So things are in good shape right now, but it's a very exciting time of year for us.

+ +

JOËL: Have you ever done some actual plumbing yourself?

+ +

GEOFF: I am very, very bad at home repair. But I have fixed a toilet or two. I've installed a water filter but nothing else. What about you?

+ +

JOËL: I've done a little bit of it when I was younger with my dad. Like, I actually welded copper pipes and that kind of thing.

+ +

GEOFF: Oh, that's amazing. That's cool. Nice.

+ +

JOËL: So I've definitely felt that thing where you turn the water source back on, and it's like, huh, let's see, is this joint going to leak, or are we good?

+ +

GEOFF: Yeah, they don't have CI for plumbing, right?

+ +

JOËL: [laughs] You know, test it in production, right?

+ +

GEOFF: Yeah. [laughs] So we're really watching right now traffic starting to rise as students and teachers are coming back. And we're also figuring out all kinds of things that we want to do to do better monitoring of our application, so some of this is watching metrics to see if things happen. But some of this is also doing some simulated user activity after we do deploys. So we're using some automated browsers with Cypress to log into our application and do some user flows, and then report back on the results.

+ +

JOËL: So is this kind of like a feature test in CI, except that you're running it in production?

+ +

GEOFF: Yeah. Smoke test is the word that we've settled on for it, but we run it against our production server every time we deploy. And it's a small suite. It's nowhere as big as our big Capybara suite that we run in CI, but we're trying to get feedback in less than six minutes. That's sort of the goal.

+ +

In addition to running tests, we also take screenshots with a tool called Percy, and that's a visual regression testing tool. So we get to see the screenshots, and if they differ by more than one pixel, we get a ping that lets us know that maybe our CSS has moved around or something like that.

+ +

JOËL: Has that caught some visual bugs for you?

+ +

GEOFF: Definitely. The state of CSS at CommonLit was very messy when I arrived, and it's gotten better, but it still definitely needs some love. There are some false positives, but it's been really, really nice to be able to see visual changes on our production pages and then be able to approve them or know that there's something we have to go back and fix.

+ +

JOËL: I'm curious, for this smoke test suite, how long does it take to run?

+ +

GEOFF: We run it in parallel. It runs on Buildkite, which is the same tool that we use to orchestrate our CI, and the longest test takes about five minutes. It signs in as a teacher, creates an account. It creates a class; it invites the student to that class. It then logs out, logs in as that student creates the student account, signs in as the student, joins the class.

+ +

It then assigns a lesson to the student then the student goes and takes the lesson. And then, when the student submits the lesson, then the test is over. And that confirms all of the most critical flows that we would want someone to drop what they were doing if it's broken, you know, account creation, class creation, lesson creation, and students taking a lesson.

+ +

JOËL: So you're compressing the first few weeks of school into five minutes.

+ +

GEOFF: Yes. And I pity the school that has thousands of fake teachers, all named Aaron McCarronson at the school.

+ +

JOËL: [laughs]

+ +

GEOFF: But we go through and delete that data every once in a while. But we have a marketer who just started at CommonLit maybe a few weeks ago, and she thought that someone was spamming our signup form because she said, "I see hundreds of teachers named Aaron McCarronson in our user list."

+ +

JOËL: You had to admit that you were the spammer?

+ +

GEOFF: Yes, I did. [laughs] We now have some controls to filter those people out of reports. But it's always funny when you look at the list, and you see all these fake people there.

+ +

JOËL: Do you have any rate limiting on your site?

+ +

GEOFF: Yeah, we do quite a bit of it, actually. Some of it we do through Cloudflare. We have tools that limit a certain flow, like people trying to credential stuffing our password, our user sign-in forms. But we also do some further stuff to prevent people from hitting key endpoints. We use Rack::Attack, which is a really nice framework. Have you had to do that in client work with clients setting that stuff up?

+ +

JOËL: I've used Rack:Attack before.

+ +

GEOFF: Yeah, it's got a reasonably nice interface that you can work with. And I always worry about accidentally setting those things up to be too sensitive, and then you get lots of stuff back. One issue that we sometimes find is that lots of kids at the same school are sharing an IP address. So that's not the thing that we want to use for rate limiting. We want to use some other criteria for rate limiting.

+ +

JOËL: Right, right. Do you ever find that you rate limit your smoke tests? Or have you had to bypass the rate limiting in the smoke tests?

+ +

GEOFF: Our smoke tests bypass our rate limiting and our bot detection. So they've got some fingerprints they use to bypass that.

+ +

JOËL: That must have been an interesting day at the office.

+ +

GEOFF: Yes. [laughter] With all of these things, I think it's a big challenge to figure out, and it's similar when you're making tests for development, how to make tests that are high signal. So if a test is failing really frequently, even if it's testing something that's worthwhile, if people start ignoring it, then it stops having value as a piece of signal. So we've invested a ton of time in making our test suite as reliable as possible, but you sometimes do have these things that just require a change.

+ +

I've become a really big fan of...there's a Ruby driver for Capybara called Cuprite, and it doesn't control chrome with Chrome Driver or with Selenium. It controls it with the Chrome DevTools protocol, so it's like a direct connection into the browser. And we find that it's very, very fast and very, very reliable. So we saw that our Capybara specs got significantly more reliable when we started using this as our driver.

+ +

JOËL: Is this because it's not actually moving the mouse around and clicking but instead issuing commands in the background?

+ +

GEOFF: Yeah. My understanding of this is a little bit hazy. But I think that Selenium and ChromeDriver are communicating over a network pipe, and sometimes that network pipe is a little bit lossy. And so it results in asynchronous commands where maybe you don't get the feedback back after something happens. And CDP is what Chrome's team and I think what Puppeteer uses to control things directly. So it's great.

+ +

And you can even do things with it. Like, you can simulate different time zone for a user almost natively. You can speed up or slow down the traveling of time and the direction of time in the browser and all kinds of things like that. You can flip it into mobile mode so that the device reports that it's a touch browser, even though it's not. We have a set of mobile specs where we flip it with CDP into mobile mode, and that's been really good too.

+ +

Do you find when you're doing client work that you have a demand to build mobile-specific specs for system tests?

+ +

JOËL: Generally not, no.

+ +

GEOFF: You've managed to escape it.

+ +

JOËL: For something that's specific to mobile, maybe one or two tests that have a weird interaction that we know is different on mobile. But in general, we're not doing the whole suite under mobile and the whole suite under desktop.

+ +

GEOFF: When you hand off a project...it's been a while since you and I have worked together.

+ +

JOËL: For those who don't know, Geoff used to be with us at thoughtbot. We were colleagues.

+ +

GEOFF: Yeah, for a while. I remember my very first thoughtbot Summer Summit; you gave a really cool lightning talk about Eleanor of Aquitaine.

+ +

JOËL: [laughs]

+ +

GEOFF: That was great. So when you're handing a project off to a client after your ending, do you find that there's a transition period where you're educating them about the norms of the test suite before you leave it in their hands?

+ +

JOËL: It depends a lot on the client. With many clients, we're working alongside an existing dev team. And so it's not so much one big handoff at the end as it is just building that in the day-to-day, making sure that we are integrating with the team from the outset of the engagement.

+ +

So one thing that does come up a lot with clients is the performance of their test suite. That's often a concern because the test suite until it becomes a problem, people tend to not treat it very well. And by the time that you're bringing on an external consultant to help, generally, that's one of the areas of the code that's been a little bit neglected. And so people ask for help on making their test suite faster. Is that something that you've had to deal with at CommonLit as well?

+ +

GEOFF: Yeah, that's a great question. We have struggled a lot with the speed that our test suite...the time it takes for our test suite to run. We've done a few things to improve it. The first is that we have quite a bit of caching that we do in our CI suite around dependencies. So gems get cached separately from NPM packages and browser assets. So all three of those things are independently cached.

+ +

And then, we run our suites in parallel. Our Jest specs get split up into eight containers. Our Ruby non-system tests...I'd like to say unit tests, but we all know that some of those are actually integration tests.

+ +

JOËL: [laughs]

+ +

GEOFF: But those tests run in 15 containers, and they start the moment gems are built. So they don't wait for NPM packages. They don't wait for assets. They immediately start going. And then our system specs as soon as the assets are built kick off and start running. And we actually run that in 40 parallel containers so we can get everything finished.

+ +

So our CI suite can finish...if there are no dependency bumps and no asset bumps, our specs suite you can finish in just under five minutes. But if you add up all of that time, cumulatively, it's something like 75 minutes is the total execution as it goes. Have you tried FactoryDoctor before for speeding up test suites?

+ +

JOËL: This is the gem from Evil Martians?

+ +

GEOFF: Yeah, it's part of TestProf, which is their really, really unbelievable toolkit for improving specs, and they have a whole bunch of things. But one of them will tell you how many invocations of FactoryBot factories each factory got. So you can see a user factory was fired 13,000 times in the test suite. It can even do some tagging where it can go in and add metadata to your specs to show which ones might be candidates for optimization.

+ +

JOËL: I gave a talk at RailsConf this year titled Your Tests Are Making Too Many Database Calls.

+ +

GEOFF: Nice.

+ +

JOËL: And one of the things I talked about was creating a lot more data via factories than you think that you are. And I should give a shout-out to FactoryProf for finding those.

+ +

GEOFF: Yeah, it's kind of a silent killer with the test suite, and you really don't think that you're doing a whole lot with it, and then you see how many associations. How do you fight that tension between creating enough data that things are realistic versus the streamlining of not creating extraneous things or having maybe mystery guests via associations and things like that?

+ +

JOËL: I try to have my base factories be as minimal as possible. So if there's a line in there that I can remove, and the factory or the model still saves, then it should be removed. Some associations, you can't do that if there's a foreign key constraint, and so then I'll leave it in. But I am a very hardcore minimalist, at least with the base factory.

+ +

GEOFF: I think that makes a lot of sense. We use foreign keys all over the place because we're always worried about somehow inserting student data that we can't recover with a bug. So we'd rather blow up than think we recorded it. And as a result, sometimes setting up specs for things like a student answering a multiple choice question on a quiz ends up being this sort of if you give a mouse a cookie thing where it's you need the answer options. You need the question. You need the quiz. You need the activity. You need the roster, the students to be in the roster. There has to be a teacher for the roster. It just balloons out because everything has a foreign key.

+ +

JOËL: The database requires it, but the test doesn't really care. It's just like, give me a student and make it valid.

+ +

GEOFF: Yes, yeah. And I find that that challenge is really hard. And sometimes, you don't see how hard it is to enforce things like database integrity until you have a lot of concurrency going on in your application. It was a very rude surprise to me to find out that browser requests if you have multiple servers going on might not necessarily be served in the order that they were made.

+ +

JOËL: [laughs] So you're talking about a scenario where you're running multiple instances of your app. You make two requests from, say, two browser tabs, and somehow they get served from two different instances?

+ +

GEOFF: Or not even two browser tabs. Imagine you have a situation where you're auto-saving.

+ +

JOËL: Oooh, background requests.

+ +

GEOFF: Yeah. So one of the coolest features we have at CommonLit is that students can annotate and highlight a text. And then, the teachers can see the annotations and highlights they've made, and it's actually part of their assignment often to highlight key evidence in a passage. And those things all fire in the background asynchronously so that it doesn't block the student from doing more stuff.

+ +

But it also means that potentially if they make two changes to a highlight really quickly that they might arrive out of order. So we've had to do some things to make sure that we're receiving in the right order and that we're not blowing away data that was supposed to be there.

+ +

Just think about in a Heroku environment, for example, which is where we used to be, you'd have four dynos running. If dyno one takes too long to serve the thing for dyno two, request one may finish after request two. That was a very, very rude surprise to learn that the world was not as clean and neat as I thought.

+ +

JOËL: I've had to do something similar where I'm making a bunch of background requests to a server. And even with a single dyno, it is possible for your request to come back out of order just because of how TCP works. So if it's waiting for a packet and you have two of these requests that went out not too long before each other, there's no guarantee that all the packets for request one come back before all the packets from request two.

+ +

GEOFF: Yeah, what are the strategies for on the client side for dealing with that kind of out-of-order response?

+ +

JOËL: Find some way to effectively version the requests that you make. Timestamp is an easy one. Whenever a request comes in, you take the response from the latest timestamp, and that wins out.

+ +

GEOFF: Yeah, we've started doing some unique IDs. And part of the unique ID is the browser's timestamp. We figure that no one would try to hack themselves and intentionally screw up their own data by submitting out of order.

+ +

JOËL: Right, right.

+ +

GEOFF: It's funny how you have to pick something to trust. [laughs]

+ +

JOËL: I'd imagine, in this case, if somebody did mess around with it, they would really only just be screwing up their own UI. It's not like that's going to then potentially crash the server because of something, and then you've got a potential vector for a denial of service.

+ +

GEOFF: Yeah, yeah, that's always what we're worried about, and we have to figure out how to trust these sorts of requests as what's a valid thing and what is, as you're saying, is just the user hurting themselves as opposed to hurting someone else's stuff?

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

GEOFF: You were talking about test suites. What are some things that you have found are consistently problems in real-world apps, but they're really, really hard to test in a test suite?

+ +

JOËL: Difficult to test or difficult to optimize for performance?

+ +

GEOFF: Maybe difficult to test.

+ +

JOËL: Third-party integrations. Anything that's over the network that's going to be difficult. Complex interactions that involve some heavy frontend but then also need a lot of backend processing potentially with asynchronous workers or something like that, there are a lot of techniques that we can use to make all those play together, but that means there's a lot of complexity in that test.

+ +

GEOFF: Yeah, definitely. I've taken a deep interest in what I'm sure there's a better technical term for this, but what I call network hostile environments or bandwidth hostile environments. And we see this a lot with kids. Especially during the pandemic, kids would often be trying to do their assignments from home. And maybe there are five kids in the house, and they're all trying to do their homework at the same time. And they're all sharing a home internet connection.

+ +

Maybe they're in the basement because they're trying to get some peace and quiet so they can do their assignment or something like that. And maybe they're not strongly connected. And the challenge of dealing with intermittent connectivity is such an interesting problem, very frustrating but very interesting to deal with.

+ +

JOËL: Have you explored at all the concept of Formal Methods to model or verify situations like that?

+ +

GEOFF: No, but I'm intrigued. Tell me more.

+ +

JOËL: I've not tried it myself. But I've read some articles on the topic. Hillel Wayne is a good person to follow for this.

+ +

GEOFF: Oh yeah.

+ +

JOËL: But it's really fascinating when you'll see, okay, here are some invariants and things. And then here are some things that you set up some basic properties for a system. And then some of these modeling languages will then poke holes and say, hey, it's possible for this 10-step sequence of events to happen that will then crash your server. Because you didn't think that it's possible for five people to be making concurrent requests, and then one of them fails and retries, whatever the steps are. So it's really good at modeling situations that, as developers, we don't always have great intuition, things like parallelism.

+ +

GEOFF: Yeah, that sounds so interesting. I'm going to add that to my list of reading for the fall. Once the school year calms down, I feel like I can dig into some technical topics again. I've got this book sitting right next to my desk, Designing Data-Intensive Applications. I saw it referenced somewhere on Twitter, and I did the thing where I got really excited about the book, bought it, and then didn't have time to read it. So it's just sitting there unopened next to my desk, taunting me.

+ +

JOËL: What's the 30-second spiel for what is a data-intensive app, and why should we design for it differently?

+ +

GEOFF: You know, that's a great question. I'd probably find out if I'd dug further into the book.

+ +

JOËL: [laughs]

+ +

GEOFF: I have found at CommonLit that we...I had a couple of clients at thoughtbot that dealt with data at the scale that we deal with here. And I'm sure there are bigger teams doing, quote, "bigger data" than we're doing. But it really does seem like one of our key challenges is making sure that we just move data around fast enough that nothing becomes a bottleneck.

+ +

We made a really key optimization in our application last year where we changed the way that we autosave students' answers as they go. And it resulted in a massive increase in throughput for us because we went from trying to store updated versions of the students' final answers to just storing essentially a draft and often storing that draft in local storage in the browser and then updating it on the server when we could.

+ +

And then, as a result of this, we're making key updates to the table where we store a student's answers much less frequently. And that has a huge impact because, in addition to being one of the biggest tables at CommonLit...it's got almost a billion recorded answers that we've gotten from students over the years. But because we're not writing to it as often, it also means that reads that are made from the table, like when the teacher is getting a report for how the students are doing in a class or when a principal is looking at how a school is doing, now, those queries are seeing less contention from ongoing writes. And so we've seen a nice improvement.

+ +

JOËL: One strategy I've seen for that sort of problem, especially when you have a very write-heavy table but that also has a different set of users that needs to read from it, is to set up a read replica. So you have your main that is being written to, and then the read replica is used for reports and people who need to look at the data without being in contention with the table being written.

+ +

GEOFF: Yeah, Rails multi-DB support now that it's native to the framework is excellent. It's so nice to be able to just drop that in and fire it up and have it work. We used to use a solution that Instacart had built. It was great for our needs, but it wasn't native to the framework.

+ +

So every single time we upgraded Rails, we had to cross our fingers and hope that it didn't, you know, whatever private APIs of ActiveRecord it was using hadn't broken. So now that that stuff, which I think was open sourced from GitHub's multi-database implementation, so now that that's all native in Rails, it's really, really nice to be able to use that.

+ +

JOËL: So these kinds of database tricks can help make the application much more performant. You'd mentioned earlier that when you were trying to make your test performant that you had introduced parallelism, and I feel like that's maybe a bit of an intimidating thing for a lot of people. How would you go about converting a test suite that's just vanilla RSpec, single-threaded, and then moving it in a direction of being more parallel?

+ +

GEOFF: There's a really, really nice tool called Knapsack, which has a free version. But the pro version, I feel like if you're spending any money at all on CI, it's immediately worth the cost. I think it's something like $75 a month for each suite that you run on it. And Knapsack does this dynamic allocation of tests across containers.

+ +

And it interfaces with several of the popular CI providers so that it looks at environment variables and can tell how many containers you're splitting across. It'll do some things, like if some of your containers start early and some of them start late, it will distribute the work so that they all end at the same time, which is really nice.

+ +

We've preferred CI providers that charge by the minute. So rather than just paying for a service that we might not be using, we've used services like Semaphore, and right now, we're on Buildkite, which charge by the minute, which means that you can decide to do as much parallelism as you want. You're just paying for the compute time as you run things.

+ +

JOËL: So that would mean that two minutes of sequential build time costs just the same as splitting it up in parallel and doing two simultaneous minutes of build time.

+ +

GEOFF: Yeah, that is almost true. There's a little bit of setup time when a container spins up. And that's one of the key things that we optimize. I guess if we ran 200 containers if we were like Shopify or something like that, we could technically make our CI suite finish faster, but it might cost us three times as much.

+ +

Because if it takes a container 30 seconds to spin up and to get ready, that's 30 seconds of dead time when you're not testing, but you're paying for the compute. So that's one of the key optimizations that we make is figuring out how many containers do we need to finish fast when we're not just blowing time on starting and finishing?

+ +

JOËL: Right, because there is a startup cost for each container.

+ +

GEOFF: Yeah, and during the work day when our engineers are working along, we spin up 200 EC2 machines or 150 EC2 machines, and they're there in the fleet, and they're ready to go to run CI jobs for us. But if you don't have enough machines, then you have jobs that sit around waiting to start, that sort of thing. So there's definitely a tension between figuring out how much parallelism you're going to do. But I feel like to start; you could always break your test suite into four pieces or two pieces and just see if you get some benefit to running a smaller number of tests in parallel.

+ +

JOËL: So, manually splitting up the test suite.

+ +

GEOFF: No, no, using something like Knapsack Pro where you're feeding it the suite, and then it's dividing up the tests for you. I think manually splitting up the suite is probably not a good practice overall because I'm guessing you'll probably spend more engineering time on fiddling with which tests go where such that it wouldn't be cost-effective.

+ +

JOËL: So I've spent a lot of time recently working to improve a parallel test suite. And one of the big problems that you have is trying to make sure that all of your parallel surfaces are being used efficiently, so you have to split the work evenly. So if you said you have 70 minutes worth of work, if you give 50 minutes to one worker and 20 minutes to the other, that means that your total test suite is still 50 minutes, and that's not good.

+ +

So ideally, you split it as evenly as possible. So I think there are three evolutionary steps on the path here. So you start off, and you're going to manually split things out. So you're going to say our biggest chunk of tests by time are the feature specs. We'll make them almost like a separate suite. Then we'll make the models and controllers and views their own thing, and that's roughly half and half, and run those. And maybe you're off by a little bit, but it's still better than putting them all in one.

+ +

It becomes difficult, though, to balance all of these because then one might get significantly longer than the other then, you have to manually rebalance it. It works okay if you're only splitting it among two workers. But if you're having to split it among 4, 8, 16, and more, it's not manageable to do this, at least not by hand.

+ +

If you want to get fancy, you can try to automate that process and record a timing file of how long every file takes. And then when you kick off the build process, look at that timing file and say, okay, we have 70 minutes, and then we'll just split the file so that we have roughly 70 divided by number of workers' files or minutes of work in each process. And that's what gems like parallel_tests do. And Knapsack's Classic mode works like this as well. That's decently good.

+ +

But the problem is you're working off of past information. And so if the test has changed or just if it's highly variable, you might not get a balanced set of workers. And as you mentioned, there's a startup cost, and so not all of your workers boot up at the same time. And so you might still have a very uneven amount of work done by each worker by statically determining the work to be done via a timing file.

+ +

So the third evolution here is a dynamic or a self-balancing approach where you just put all of the tests or the files in a queue and then just have every worker pull one or two tests when it's ready to work. So that way, if something takes a lot longer than expected, well, it's just not pulling more from the queue. And everybody else still pulls, and they end up all balancing each other out. And then ideally, every worker finishes work at exactly the same time. And that's how you know you got the most value you could out of your parallel processes.

+ +

GEOFF: Yeah, there's something about watching all the jobs finish in almost exactly, you know, within 10 seconds of each other. It just feels very, very satisfying. I think in addition to getting this dynamic splitting where you're getting either per file or per example split across to get things finishing at the same time, we've really valued getting fast feedback.

+ +

So I mentioned before that our Jest specs start the moment NPM packages get built. So as soon as there's JavaScripts that can be executed in test, those kick-off. As soon as our gems are ready, the RSpec non-system tests go off, and they start running specs immediately. So we get that really, really fast feedback.

+ +

Unfortunately, the browser tests take the longest because they have to wait for the most setup. They have the most dependencies. And then they also run the slowest because they run in the browser and everything. But I think when things are really well-oiled, you watch all of those containers end at roughly the same time, and it feels very satisfying.

+ +

JOËL: So, a few weeks ago, on an episode of The Bike Shed, I talked with Eebs Kobeissi about dependency graphs and how I'm super excited about it. And I think I see a dependency graph in what you're describing here in that some things only depend on the gem file, and so they can start working. But other things also depend on the NPM packages. And so your build pipeline is not one linear process or one linear process that forks into other linear processes; it's actually a dependency graph.

+ +

GEOFF: That is very true. And the CI tool we used to use called Semaphore actually does a nice job of drawing the dependency graph between all of your steps. Buildkite does not have that, but we do have a bunch of steps that have to wait for other steps to finish. And we do it in our wiki. On our repo, we do have a diagram of how all of this works.

+ +

We found that one of the things that was most wasteful for us in CI was rebuilding gems, reinstalling NPM packages (We use Yarn but same thing.), and then rebuilding browser assets. So at the very start of every CI run, we build hashes of a bunch of files in the repository. And then, we use those hashes to name Docker images that contain the outputs of those files so that we are able to skip huge parts of our CI suite if things have already happened.

+ +

So I'll give an example if Ruby gems have not changed, which we would know by the Gemfile.lock not having changed, then we know that we can reuse a previously built gems image that has the gems that just gets melted in, same thing with yarn.lock. If yarn.lock hasn't changed, then we don't have to build NPM packages. We know that that already exists somewhere in our Docker registry.

+ +

In addition to skipping steps by not redoing work, we also have started to experiment...actually, in response to a comment that Chris Toomey made in a prior Bike Shed episode, we've started to experiment with skipping irrelevant steps. So I'll give an example of this if no Ruby files have changed in our repository, we don't run our RSpec unit tests. We just know that those are valid. There's nothing that needs to be rerun.

+ +

Similarly, if no JavaScript has changed, we don't run our Jest tests because we assume that everything is good. We don't lint our views with erb-lint if our view files haven't changed. We don't lint our factories if the model or the database hasn't changed. So we've got all these things to skip key types of processing.

+ +

I always try to err on the side of not having a false pass. So I'm sure we could shave this even tighter and do even less work and sometimes finish the build even faster. But I don't want to ever have a thing where the build passes and we get false confidence.

+ +

JOËL: Right. Right. So you're using a heuristic that eliminates the really obvious tests that don't need to be run but the ones that maybe are a little bit more borderline, you keep them in. Shaving two seconds is not worth missing a failure.

+ +

GEOFF: Yeah. And I've read things about big enterprises doing very sophisticated versions of this where they're guessing at which CI specs might be most relevant and things like that. We're nowhere near that level of sophistication right now.

+ +

But I do think that once you get your test suite parallelized and you're not doing wasted work in the form of rebuilding dependencies or rebuilding assets that don't need to be rebuilt, there is some maybe not low, maybe medium hanging fruit that you can use to get some extra oomph out of your test suite.

+ +

JOËL: I really like that you brought up this idea of infrastructure and skipping. I think in my own way of thinking about improving test suites, there are three broad categories of approaches you can take. One variable you get to work with is that total number of time single-threaded, so you mentioned 70 minutes. You can make that 70 minutes shorter by avoiding database writes where you don't need them, all the common tricks that we would do to actually change the test themselves. Then we can change...as another variable; we get to work with parallelism, we talked about that.

+ +

And then finally, there's all that other stuff that's not actually executing RSpec like you said, loading the gems, installing NPM packages, Docker images. All of those, if we can skip work running migrations, setting up a database, if there are situations where we can improve the speed there, that also improves the total time.

+ +

GEOFF: Yeah, there are so many little things that you can pick at to...like, one of the slowest things for us is Elasticsearch. And so we really try to limit the number of specs that use Elasticsearch if we can. You actually have to opt-in to using Elasticsearch on a spec, or else we silently mock and disable all of the things that happen there.

+ +

When you're looking at that first variable that you were talking about, just sort of the overall time, beyond using FactoryDoctor and FactoryProf, is there anything else that you've used to just identify the most egregious offenders in a test suite and then figure out if they're worth it?

+ +

JOËL: One thing you can do is hook into Active Support notification to try to find database writes. And so you can find, oh, here's where all of the...this test is making way too many database writes for some reason, or it's making a lot, maybe I should take a look at it; it's a hotspot.

+ +

GEOFF: Oh, that's really nice. There's one that I've always found is like a big offender, which is people doing negative expectations in system specs.

+ +

JOËL: Oh, for their Capybara wait time.

+ +

GEOFF: Yeah. So there's a really cool gem, and the name of it is eluding me right now. But there's a gem that raises a special exception if Capybara waits the full time for something to happen. So it lets you know that those things exist. And so we've done a lot of like hunting for...Knapsack will report the slowest examples in your test suite. So we've done some stuff to look for the slowest files and then look to see if there are examples of these negative expectations that are waiting 10 seconds or waiting 8 seconds before they fail.

+ +

JOËL: Right. Some files are slow, but they're slow for a reason. Like, a feature spec is going to be much slower than a model test. But the model tests might be very wasteful and because you have so many of them, if you're doing the same pattern in a bunch of them or if it's a factory that's reused across a lot of them, then a small fix there can have some pretty big ripple effects.

+ +

GEOFF: Yeah, I think that's true. Have you ever done any evaluation of test suite to see what files or examples you could throw away?

+ +

JOËL: Not holistically. I think it's more on an ad hoc basis. You find a place, and you're like, oh, these tests we probably don't need them. We can throw them out. I have found dead tests, tests that are not executed but still committed to the repo.

+ +

GEOFF: [laughs]

+ +

JOËL: It's just like, hey, I'm going to get a lot of red in my diff today.

+ +

GEOFF: That always feels good to have that diff-y check-in, and it's 250 lines or 1,000 lines of red and 1 line of green.

+ +

JOËL: So that's been a pretty good overview of a lot of different areas related to performance and infrastructure around tests. Thank you so much, Geoff, for joining us today on The Bike Shed to talk about your experience at CommonLit doing this. Do you have any final words for our listeners?

+ +

GEOFF: Yeah. CommonLit is hiring a senior full-stack engineer, so if you'd like to work on Rails and TypeScript in a place with a great test suite and a great team. I've been here for five years, and it's a really, really excellent place to work. And also, it's been really a pleasure to catch up with you again, Joël.

+ +

JOËL: And, Geoff, where can people find you online?

+ +

GEOFF: I'm Geoff with a G, G-E-O-F-F Harcourt, @geoffharcourt. And that's my name on Twitter, and it's my name on GitHub, so you can find me there.

+ +

JOËL: And we'll make sure to include a link to your Twitter profile in the show notes.

+ +

The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-_B_MS_h + + ]]> + + Joël Quenneville + + + 354: The History of Computing + https://bikeshed.thoughtbot.com/354 + 3b1af22d-a3be-469a-8717-220f75b03eea + Tue, 13 Sep 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Why does the history of computing matter? Joël and Developer at thoughtbot Sara Jackson, ponder this and share some cool stories (and trivia!!) behind the tools we use in the industry. + 31:16 + no + + + Why does the history of computing matter? Joël and Developer at thoughtbot Sara Jackson, ponder this and share some cool stories (and trivia!!) behind the tools we use in the industry. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Sara on Twitter (https://twitter.com/csarajackson) +UNIX philosophy (https://en.wikipedia.org/wiki/Unix_philosophy) +Hillel Wayne on why we ask linked list questions (https://www.hillelwayne.com/post/linked-lists/) +History of Unix, Linux, and Open Source / Free Software (https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/history.html) +Collected Histories of Unix (https://www.tuhs.org/Archive/Documentation/OralHistory/) +Selected pages from the nine research editions of the UNIX® Programmer’s Manual illustrate the development of the system. Accompanying commentary recounts some of the needs, events, and individual contributions that shaped this evolution (https://www.cs.dartmouth.edu/~doug/reader.pdf) +These are dates that every hacker knew were important at the time, or shortly afterwards. (http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/#_key_dates) +Unix at 50: How the OS that powered smartphones started from failure (https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/) +First hand account of history of Unix and Multics by Tom Van Vleck (https://www.multicians.org/unix.html) +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. And today, I'm joined by fellow thoughtboter, Team Lead, and Developer Sara Jackson. +SARA: Hello, happy to be here. +JOËL: Together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world? +SARA: Well, Joël, you might know that recently our team had a small get-together in Toronto. +JOËL: And our team, for those who are not aware, is fully remote distributed across multiple countries. So this was a chance to get together in person. +SARA: Yes, correct. This was a chance for those on the Boost team to get together and work together as if we had a physical office. +JOËL: Was this your first time meeting some members of the team? +SARA: It was my second, for the most part. So I joined thoughtbot, but after thoughtbot had already gotten remote. Fortunately, I was able to meet many other thoughtboters in May at our summit. +JOËL: Had you worked at a remote company before coming to thoughtbot? +SARA: Yes, I actually started working remotely in 2019, but even then, that wasn't my first time working remotely. I actually had a full year of internship in college that was remote. +JOËL: So you were a pro at this long before the pandemic made us all try it out. +SARA: I don't know about that, but I've certainly dealt with the idiosyncrasies that come with remote work for longer. +JOËL: What do you think are some of the challenges of remote work as opposed to working in person in an office? +SARA: I think definitely growing and maintaining a culture. When you're in an office, it's easy to create ad hoc conversations and have events that are small that build on the culture. But when you're remote, it has to be a lot more intentional. +JOËL: That definitely rings true for me. One of the things that I really appreciated about in-person office culture was the serendipity that you have those sort of random meetings at the water cooler, those conversations, waiting for coffee with people who are not necessarily on the same team or the same project as you are. +SARA: I also really miss being able to have lunch in person with folks where I can casually gripe about an issue I might be having, and almost certainly, someone would have the answer. Now, if I'm having an issue, I have to intentionally seek help. [chuckles] +JOËL: One of the funny things that often happened, at least the office where I worked at, was that lunches would often devolve into taxonomy conversations. +SARA: I wish I had been there for that. +[laughter] +JOËL: Well, we do have a taxonomy channel on Slack to somewhat continue that legacy. +SARA: Do you have a favorite taxonomy lunch discussion that you recall? +JOËL: I definitely got to the point where I hated the classifying a sandwich. That one has been way overdone. +SARA: Absolutely. +JOËL: There was an interesting one about motorcycles, and mopeds, and bicycles, and e-bikes, and trying to see how do you distinguish one from the other. Is it an electric motor? Is it the power of the engine that you have? Is it the size? +SARA: My brain is already turning on those thoughts. I feel like I could get lost down that rabbit hole very easily. +[laughter] +JOËL: Maybe that should be like a special anniversary episode for The Bike Shed, just one long taxonomy ramble. +SARA: Where we talk about bikes. +JOËL: Ooh, that's so perfect. I love it. One thing that I really appreciated during our time in Toronto was that we actually got to have lunch in person again. +SARA: Yeah, that was so wonderful. Having folks coming together that had maybe never worked together directly on clients just getting to sit down and talk about our day. +JOËL: Yeah, and talk about maybe it's work-related, maybe it's not. There's a lot of power to having some amount of deeper interpersonal connection with your co-workers beyond just the we work on a project together. +SARA: Yeah, it's like camaraderie beyond the shared mission of the company. It's the shared interpersonal mission, like you say. Did you have any in-person pairing sessions in Toronto? +JOËL: I did. It was actually kind of serendipitous. Someone was stuck with a weird failing test because somehow the order factories were getting created in was not behaving in the expected way, and we herd on it, dug into it, found some weird thing with composite primary keys, and solved the issue. +SARA: That's wonderful. I love that. I wonder if that interaction would have happened or gotten solved as quickly if we hadn't been in person. +JOËL: I don't know about you, but I feel like I sometimes struggle to ask for help or ask for a pair more when I'm online. +SARA: Yeah, I agree. It's easier to feel like you're not as big of an impediment when you're in person. You tap someone on the shoulder, "Hey, can you take a look at this?" +JOËL: Especially when they're on the same team as you, they're sitting at the next desk over. I don't know; it just felt easier. Even though it's literally one button press to get Tuple to make a call, somehow, I feel like I'm interrupting more. +SARA: To combat that, I've been trying to pair more frequently and consistently regardless of if I'm struggling with a problem. +JOËL: Has that worked pretty well? +SARA: It's been wonderful. The only downside has been pairing fatigue. +JOËL: Pairing fatigue is real. +SARA: But other than that, problems have gotten solved quickly. We've all learned something for those that I've paired with. It goes faster. +JOËL: So it was really great that we had this experience of doing our daily work but co-located in person; we have these experiences of working together. What would you say has been one of the highlights for you of that time? +SARA: 100% karaoke. +JOËL: [laughs] +SARA: Only two folks did not attend. Many of the folks that did attend told me they weren't going to sing, but they were just going to watch. By the end of the night, everyone had sung. We were there for nearly three and a half hours. [laughs] +JOËL: It was a good time all around. +SARA: I saw a different side to Chad. +JOËL: [laughs] +SARA: And everyone, honestly. Were there any musical choices that surprised you? +JOËL: Not particularly. Karaoke is always fun when you have a group of people that you trust to be a little bit foolish in front of to put yourself out there. I really appreciated the style that we went for, where we have a private room for just the people who were there as opposed to a stage in a bar somewhere. I think that makes it a little bit more accessible to pick up the mic and try to sing a song. +SARA: I agree. That style of karaoke is a lot more popular in Asia, having your private room. Sometimes you can find it in major cities. But I also prefer it for that reason. +JOËL: One of my highlights of this trip was this very sort of serendipitous moment that happened. Someone was asking a question about the difference between a Mac and Linux operating systems. And then just an impromptu gathering happened. And you pulled up a chair, and you're like, gather around, everyone. In the beginning, there was Multics. It was amazing. +SARA: I felt like some kind of historian or librarian coming out from the deep. Let me tell you about this random operating system knowledge that I have. [laughs] +JOËL: The ancient lore. +SARA: The ancient lore in the year 1969. +JOËL: [laughs] And then yeah, we had a conversation walking the history of operating systems, and why we have macOS and Linux, and why they're different, and why Windows is a totally different kind of family there. +SARA: Yeah, macOS and Linux are sort of like cousins coming from the same tree. +JOËL: Is that because they're both related through Unix? +SARA: Yes. Linux and macOS are both built based off of different versions of Unix. Over the years, there's almost like a family tree of these different Nix operating systems as they're called. +JOËL: I've sometimes seen asterisk N-I-X. This is what you're referring to as Nix. +SARA: Yes, where the asterisk is like the RegEx catch-all. +JOËL: So this might be Unix. It might be Linux. It might be... +SARA: Minix. +JOËL: All of those. +SARA: Do you know the origin of the name Unix? +JOËL: I do not. +SARA: It's kind of a fun trivia piece. So, in the beginning, there was Multics spelled M-U-L-T-I-C-S, standing for the Multiplexed Information and Computing Service. Dennis Ritchie and Ken Thompson of Bell Labs famous for the C programming language... +JOËL: You may have heard of it. +SARA: You may have heard of it maybe on a different podcast. They were employees at Bell Labs when Multics was being created. They felt that Multics was very bulky and heavy. It was trying to do too many things at once. It did have a few good concepts. So they developed their own smaller Unix originally, Unics, the Uniplexed Information and Computing Service, Uniplexed versus Multiplexed. We do one thing really well. +JOËL: And that's the Unix philosophy. +SARA: It absolutely is. The Unix philosophy developed out of the creation of Unix and C. Do you know the four main points? +JOËL: No, is it small sharp tools? It's the main one I hear. +SARA: Yes, that is the kind of quippy version that has come out for sure. +JOËL: But there is a formal four-point manifesto. +SARA: I believe it's evolved over the years. But it's interesting looking at the Unix philosophy and seeing how relevant it is today in web development. The four points being make each program do one thing well. To this end, don't add features; make a new program. I feel like we have this a lot in encapsulation. +JOËL: Hmm, maybe even the open-closed principle. +SARA: Absolutely. +JOËL: Similar idea. +SARA: Another part of the philosophy is expecting output of your program to become input of another program that is yet unknown. The key being don't clutter your output; don't have extraneous text. This feels very similar to how we develop APIs. +JOËL: With a focus on composability. +SARA: Absolutely. Being able to chain commands together like you see in Ruby all the time. +JOËL: I love being able to do this, for example, the enumerable API in Ruby and just being able to chain all these methods together to just very nicely do some pretty big transformations on an array or some other data structure. +SARA: 100% agree there. That ability almost certainly came out of following the tenets of this philosophy, maybe not knowingly so but maybe knowingly so. [chuckles] +JOËL: So is that three or four? +SARA: So that was two. The third being what we know as agile. +JOËL: Really? +SARA: Yeah, right? The '70s brought us agile. Design and build software to be tried early, and don't hesitate to throw away clumsy parts and rebuild. +JOËL: Hmmm. +SARA: Even in those days, despite waterfall style still coming on the horizon. It was known for those writing software that it was important to iterate quickly. +JOËL: Wow, I would never have known. +SARA: It's neat having this history available to us. It's sort of like a lens at where we came from. +Another piece of this history that might seem like a more modern concept but was a very big part of the movement in the '70s and the '80s was using tools rather than unskilled help or trying to struggle through something yourself when you're lightening a programming task. We see this all the time at thoughtbot. Folks do this many times there is an issue on a client code. We are able to generalize the solution, extract into a tool that can then be reused. +JOËL: So that's the same kind of genesis as a lot of thoughtbot's open-source gems, so I'm thinking of FactoryBot, Clearance, Paperclip, the old-timey file upload gem, Suspenders, the Rails app generator, and the list goes on. +SARA: I love that in this last point of the Unix philosophy, they specifically call out that you should create a new tool, even if it means detouring, even if it means throwing the tools out later. +JOËL: What impact do you think that has had on the way that tooling in the Unix, or maybe I should say *Nix, ecosystem has developed? +SARA: It was a major aspect of the Nix environment community because Unix was available, not free, but very inexpensively to educational institutions. And because of how lightweight it was and its focus on single-use programs, programs that were designed to do one thing, and also the way the shell was allowing you to use commands directly and having it be the same language as the shell scripting language, users, students, amateurs, and I say that in a loving way, were able to create their own tools very quickly. It was almost like a renaissance of Homebrew. +JOËL: Not Homebrew as in the macOS package manager. +SARA: [laughs] And also not Homebrew as in the alcoholic beverage. +JOËL: [laughs] So, this kind of history is fun trivia to know. Is it really something valuable for us as a jobbing developer in 2022? +SARA: I would say it's a difficult question. If you are someone that doesn't dive into the why of something, especially when something goes wrong, maybe it wouldn't be important or useful. +But what sparked the conversation in Toronto was trying to determine why we as thoughtbot tend to prefer using Macs to develop on versus Linux or Windows. There is a reason, and the reason is in the history. Knowing that can clarify decisions and can give meaning where it feels like an arbitrary decision. +JOËL: Right. We're not just picking Macs because they're shiny. +SARA: They are certainly shiny. And the first thing I did was to put a matte case on it. +JOËL: [laughs] So no shiny in your office. +SARA: If there were too many shiny things in my office, boy, I would never get work done. The cats would be all over me. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: So we've talked a little bit about Unix or *Nix, this evolution of systems. I've also heard the term POSIX thrown around when talking about things that seem to encompass both macOS and Linux. How does that fit into this history? +SARA: POSIX is sort of an umbrella of standards around operating systems that was based on Unix and the things that were standard in Unix. It stands for the Portable Operating System Interface. This allowed for compatibility between OSs, very similar to USB being the standard for peripherals. +JOËL: So, if I was implementing my own Unix-like operating system in the '80s, I would try to conform to the POSIX standard. +SARA: Absolutely. Now, not every Nix operating system is POSIX-compliant, but most are or at least 90% of the way there. +JOËL: Are any of the big ones that people tend to think about not compliant? +SARA: A major player in the operating system space that is not generally considered POSIX-compliant is Microsoft Windows. +JOËL: [laughs] It doesn't even try to be Unix-like, right? It's just its own thing, +SARA: It is completely its own thing. I don't think it even has a standard necessarily that it conforms to. +JOËL: It is its own standard, its own branch of the family tree. +SARA: And that's what happens when your operating system is very proprietary. This has caused folks pain, I'm sure, in the past that may have tried to develop software on their computers using languages that are more readily compatible with POSIX operating systems. +JOËL: So would you say that a language like Ruby is more compatible with one of the POSIX-compatible operating systems? +SARA: 100% yes. In fact, to even use Ruby as a development tool in Windows, prior to Windows 10, you needed an additional tool. You needed something like Cygwin or MinGW, which were POSIX-compliant programs that it was almost like a shell in your Windows computer that would allow you to run those commands. +JOËL: Really? For some reason, I thought that they had some executables that you could run just on Windows by itself. +SARA: Now they do, fortunately, to the benefit of Ruby developers everywhere. As of Windows 10, we now have WSL, the Windows Subsystem for Linux that's built-in. You don't have to worry about installing or configuring some third-party software. +JOËL: I guess that kind of almost cheats by just having a POSIX system embedded in your non-POSIX system. +SARA: It does feel like a cheat, but I think it was born out of demand. The Windows NT kernel, for example, is mostly POSIX-compliant. +JOËL: Really? +SARA: As a result of it being used primarily for servers. +JOËL: So you mentioned the Ruby tends and the Rails ecosystem tends to run better and much more frequently on the various Nix systems. Did it have to be that way? Or is it just kind of an accident of history that we happen to end up with Ruby and Rails in this ecosystem, but just as easily, it could have evolved in the Windows world? +SARA: I think it is an amalgam of things. For example, Unix and Nix operating systems being developed earlier, being widely spread due to being license-free oftentimes, and being widely used in the education space. Also, because it is so lightweight, it is the operating system of choice. For most servers in the world, they're running some form of Unix, Linux, or macOS. +JOËL: I don't think I've ever seen a server that runs macOS; exclusively seen it on dev machines. +SARA: If you go to an animation company, they have server farms of macOS machines because they're really good at rendering. This might not be the case anymore, but it was at one point. +JOËL: That's a whole other world that I've not interacted with a whole lot. +SARA: [chuckles] +JOËL: It's a fun intersection between software, and design, and storytelling. That is an important part for the software field. +SARA: Yeah, it's definitely an aspect that deserves its own deep dive of sorts. If you have a server that's running a Windows-based operating system like NT and you have a website or a program that's designed to be served under a Unix-based server, it can easily be hosted on the Windows server; it's not an issue. The reverse is not true. +JOËL: Oh. +SARA: And this is why programming on a Nix system is the better choice. +JOËL: It's more broadly compatible. +SARA: Absolutely. Significantly more compatible with more things. +JOËL: So today, when I develop, a lot of the tooling that I use is open source. The open-source movement has created a lot of the languages that we know and love, including Ruby, including Rails. Do you think there's some connection between a lot of that tooling being open source and maybe some of the Unix family of operating systems and movements that came out of that branch of the operating system family tree? +SARA: I think that there is a lot of tie-in with today's open-source culture and the computing history that we've been talking about, for example, people finding something that they dislike about the tools that are available and then rolling their own. That's what Ken Thompson and Dennis Ritchie did. Unix was not an official Bell development. It was a side project for them. +JOËL: I love that. +SARA: You see this happen a lot in the software world where a program gets shared widely, and due to this, it gains traction and gains buy-in from the community. If your software is easily accessible to students, folks that are learning, and breaking things, and rebuilding, and trying, and inventing, it's going to persist. And we saw that with Unix. +JOËL: I feel like this background on where a lot of these operating systems came but then also the ecosystems, the values that evolved with them has given me a deeper appreciation of the tooling, the systems that we work with today. Are there any other advantages, do you think, to trying to learn a little bit of computing history? +SARA: I think the main benefit that I mentioned before of if you're a person that wants to know why, then there is a great benefit in knowing some of these details. That being said, you don't need to deep dive or read multiple books or write papers on it. You can get enough information from reading or skimming some Wikipedia pages. +But it's interesting to know where we came from and how it still affects us today. Ruby was written in C, for example. Unix was written in C as well, originally Assembly Language, but it got rewritten in C. And understanding the underlying tooling that goes into that that when things go wrong, you know where to look. +JOËL: I guess that that is the next question is where do you look if you're kind of interested? Is Wikipedia good enough? You just sort of look up operating system, and it tells you where to go? Or do you have other sources you like to search for or start pulling at those threads to understand history? +SARA: That's a great question. And Wikipedia is a wonderful starting point for sure. It has a lot of the abbreviated history and links to better references. I don't have them off the top of my head. So I will find them for you for the show notes. But there are some old esoteric websites with some of this history more thoroughly documented by the people that lived it. +JOËL: I feel like those websites always end up being in HTML 2; your very basic text, horizontal rules, no CSS. +SARA: Mm-hmm. And those are the sites that have many wonderful kernels of knowledge. +JOËL: Uh-huh! Great pun. +SARA: [chuckles] Thank you. +JOËL: Do you read any content by Hillel Wayne? +SARA: I have not. +JOËL: So Hillel produces a lot of deep dives into computing history, oftentimes trying to answer very particular questions such as when and why did we start using reversing a linked list as the canonical interview question? And there are often urban legends around like, oh, it's because of this. And then Hillel will do some research and go through actual archives of messages on message boards or...what is that protocol? +SARA: BBS. +JOËL: Yes. And then find the real answer, like, do actual historical methodology, and I love that. +SARA: I had not heard of this before. I don't know how. And that is all I'm going to be doing this weekend is reading these. That kind of history speaks to my heart. I have a random fun fact along those lines that I wanted to bring to the show, which was that the echo command that we know and love in the terminal was first introduced by the Multics operating system. +JOËL: Wow. So that's like the most common piece of Multics that as an everyday user of a modern operating system that we would still touch a little bit of that history every day when we work. +SARA: Yeah, it's one of those things that we don't think about too much. Where did it come from? How long has it been around? I'm sure the implementation today is very different. But it's like etymology, and like taxonomy, pulling those threads. +JOËL: Two fantastic topics. On that wonderful little nugget of knowledge, let's wrap up. Sara, where can people find you online? +SARA: You can find me on Twitter at @csarajackson. +JOËL: And we will include a link to that in the show notes. +SARA: Thank you so much for having me on the show and letting me nerd out about operating system history. +JOËL: It's been a pleasure. +The show notes for this episode can be found at bikeshed.fm. +This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email. +Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Why does the history of computing matter? Joël and Developer at thoughtbot Sara Jackson, ponder this and share some cool stories (and trivia!!) behind the tools we use in the industry.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by fellow thoughtboter, Team Lead, and Developer Sara Jackson.

+ +

SARA: Hello, happy to be here.

+ +

JOËL: Together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world?

+ +

SARA: Well, Joël, you might know that recently our team had a small get-together in Toronto.

+ +

JOËL: And our team, for those who are not aware, is fully remote distributed across multiple countries. So this was a chance to get together in person.

+ +

SARA: Yes, correct. This was a chance for those on the Boost team to get together and work together as if we had a physical office.

+ +

JOËL: Was this your first time meeting some members of the team?

+ +

SARA: It was my second, for the most part. So I joined thoughtbot, but after thoughtbot had already gotten remote. Fortunately, I was able to meet many other thoughtboters in May at our summit.

+ +

JOËL: Had you worked at a remote company before coming to thoughtbot?

+ +

SARA: Yes, I actually started working remotely in 2019, but even then, that wasn't my first time working remotely. I actually had a full year of internship in college that was remote.

+ +

JOËL: So you were a pro at this long before the pandemic made us all try it out.

+ +

SARA: I don't know about that, but I've certainly dealt with the idiosyncrasies that come with remote work for longer.

+ +

JOËL: What do you think are some of the challenges of remote work as opposed to working in person in an office?

+ +

SARA: I think definitely growing and maintaining a culture. When you're in an office, it's easy to create ad hoc conversations and have events that are small that build on the culture. But when you're remote, it has to be a lot more intentional.

+ +

JOËL: That definitely rings true for me. One of the things that I really appreciated about in-person office culture was the serendipity that you have those sort of random meetings at the water cooler, those conversations, waiting for coffee with people who are not necessarily on the same team or the same project as you are.

+ +

SARA: I also really miss being able to have lunch in person with folks where I can casually gripe about an issue I might be having, and almost certainly, someone would have the answer. Now, if I'm having an issue, I have to intentionally seek help. [chuckles]

+ +

JOËL: One of the funny things that often happened, at least the office where I worked at, was that lunches would often devolve into taxonomy conversations.

+ +

SARA: I wish I had been there for that.

+ +

[laughter]

+ +

JOËL: Well, we do have a taxonomy channel on Slack to somewhat continue that legacy.

+ +

SARA: Do you have a favorite taxonomy lunch discussion that you recall?

+ +

JOËL: I definitely got to the point where I hated the classifying a sandwich. That one has been way overdone.

+ +

SARA: Absolutely.

+ +

JOËL: There was an interesting one about motorcycles, and mopeds, and bicycles, and e-bikes, and trying to see how do you distinguish one from the other. Is it an electric motor? Is it the power of the engine that you have? Is it the size?

+ +

SARA: My brain is already turning on those thoughts. I feel like I could get lost down that rabbit hole very easily.

+ +

[laughter]

+ +

JOËL: Maybe that should be like a special anniversary episode for The Bike Shed, just one long taxonomy ramble.

+ +

SARA: Where we talk about bikes.

+ +

JOËL: Ooh, that's so perfect. I love it. One thing that I really appreciated during our time in Toronto was that we actually got to have lunch in person again.

+ +

SARA: Yeah, that was so wonderful. Having folks coming together that had maybe never worked together directly on clients just getting to sit down and talk about our day.

+ +

JOËL: Yeah, and talk about maybe it's work-related, maybe it's not. There's a lot of power to having some amount of deeper interpersonal connection with your co-workers beyond just the we work on a project together.

+ +

SARA: Yeah, it's like camaraderie beyond the shared mission of the company. It's the shared interpersonal mission, like you say. Did you have any in-person pairing sessions in Toronto?

+ +

JOËL: I did. It was actually kind of serendipitous. Someone was stuck with a weird failing test because somehow the order factories were getting created in was not behaving in the expected way, and we herd on it, dug into it, found some weird thing with composite primary keys, and solved the issue.

+ +

SARA: That's wonderful. I love that. I wonder if that interaction would have happened or gotten solved as quickly if we hadn't been in person.

+ +

JOËL: I don't know about you, but I feel like I sometimes struggle to ask for help or ask for a pair more when I'm online.

+ +

SARA: Yeah, I agree. It's easier to feel like you're not as big of an impediment when you're in person. You tap someone on the shoulder, "Hey, can you take a look at this?"

+ +

JOËL: Especially when they're on the same team as you, they're sitting at the next desk over. I don't know; it just felt easier. Even though it's literally one button press to get Tuple to make a call, somehow, I feel like I'm interrupting more.

+ +

SARA: To combat that, I've been trying to pair more frequently and consistently regardless of if I'm struggling with a problem.

+ +

JOËL: Has that worked pretty well?

+ +

SARA: It's been wonderful. The only downside has been pairing fatigue.

+ +

JOËL: Pairing fatigue is real.

+ +

SARA: But other than that, problems have gotten solved quickly. We've all learned something for those that I've paired with. It goes faster.

+ +

JOËL: So it was really great that we had this experience of doing our daily work but co-located in person; we have these experiences of working together. What would you say has been one of the highlights for you of that time?

+ +

SARA: 100% karaoke.

+ +

JOËL: [laughs]

+ +

SARA: Only two folks did not attend. Many of the folks that did attend told me they weren't going to sing, but they were just going to watch. By the end of the night, everyone had sung. We were there for nearly three and a half hours. [laughs]

+ +

JOËL: It was a good time all around.

+ +

SARA: I saw a different side to Chad.

+ +

JOËL: [laughs]

+ +

SARA: And everyone, honestly. Were there any musical choices that surprised you?

+ +

JOËL: Not particularly. Karaoke is always fun when you have a group of people that you trust to be a little bit foolish in front of to put yourself out there. I really appreciated the style that we went for, where we have a private room for just the people who were there as opposed to a stage in a bar somewhere. I think that makes it a little bit more accessible to pick up the mic and try to sing a song.

+ +

SARA: I agree. That style of karaoke is a lot more popular in Asia, having your private room. Sometimes you can find it in major cities. But I also prefer it for that reason.

+ +

JOËL: One of my highlights of this trip was this very sort of serendipitous moment that happened. Someone was asking a question about the difference between a Mac and Linux operating systems. And then just an impromptu gathering happened. And you pulled up a chair, and you're like, gather around, everyone. In the beginning, there was Multics. It was amazing.

+ +

SARA: I felt like some kind of historian or librarian coming out from the deep. Let me tell you about this random operating system knowledge that I have. [laughs]

+ +

JOËL: The ancient lore.

+ +

SARA: The ancient lore in the year 1969.

+ +

JOËL: [laughs] And then yeah, we had a conversation walking the history of operating systems, and why we have macOS and Linux, and why they're different, and why Windows is a totally different kind of family there.

+ +

SARA: Yeah, macOS and Linux are sort of like cousins coming from the same tree.

+ +

JOËL: Is that because they're both related through Unix?

+ +

SARA: Yes. Linux and macOS are both built based off of different versions of Unix. Over the years, there's almost like a family tree of these different Nix operating systems as they're called.

+ +

JOËL: I've sometimes seen asterisk N-I-X. This is what you're referring to as Nix.

+ +

SARA: Yes, where the asterisk is like the RegEx catch-all.

+ +

JOËL: So this might be Unix. It might be Linux. It might be...

+ +

SARA: Minix.

+ +

JOËL: All of those.

+ +

SARA: Do you know the origin of the name Unix?

+ +

JOËL: I do not.

+ +

SARA: It's kind of a fun trivia piece. So, in the beginning, there was Multics spelled M-U-L-T-I-C-S, standing for the Multiplexed Information and Computing Service. Dennis Ritchie and Ken Thompson of Bell Labs famous for the C programming language...

+ +

JOËL: You may have heard of it.

+ +

SARA: You may have heard of it maybe on a different podcast. They were employees at Bell Labs when Multics was being created. They felt that Multics was very bulky and heavy. It was trying to do too many things at once. It did have a few good concepts. So they developed their own smaller Unix originally, Unics, the Uniplexed Information and Computing Service, Uniplexed versus Multiplexed. We do one thing really well.

+ +

JOËL: And that's the Unix philosophy.

+ +

SARA: It absolutely is. The Unix philosophy developed out of the creation of Unix and C. Do you know the four main points?

+ +

JOËL: No, is it small sharp tools? It's the main one I hear.

+ +

SARA: Yes, that is the kind of quippy version that has come out for sure.

+ +

JOËL: But there is a formal four-point manifesto.

+ +

SARA: I believe it's evolved over the years. But it's interesting looking at the Unix philosophy and seeing how relevant it is today in web development. The four points being make each program do one thing well. To this end, don't add features; make a new program. I feel like we have this a lot in encapsulation.

+ +

JOËL: Hmm, maybe even the open-closed principle.

+ +

SARA: Absolutely.

+ +

JOËL: Similar idea.

+ +

SARA: Another part of the philosophy is expecting output of your program to become input of another program that is yet unknown. The key being don't clutter your output; don't have extraneous text. This feels very similar to how we develop APIs.

+ +

JOËL: With a focus on composability.

+ +

SARA: Absolutely. Being able to chain commands together like you see in Ruby all the time.

+ +

JOËL: I love being able to do this, for example, the enumerable API in Ruby and just being able to chain all these methods together to just very nicely do some pretty big transformations on an array or some other data structure.

+ +

SARA: 100% agree there. That ability almost certainly came out of following the tenets of this philosophy, maybe not knowingly so but maybe knowingly so. [chuckles]

+ +

JOËL: So is that three or four?

+ +

SARA: So that was two. The third being what we know as agile.

+ +

JOËL: Really?

+ +

SARA: Yeah, right? The '70s brought us agile. Design and build software to be tried early, and don't hesitate to throw away clumsy parts and rebuild.

+ +

JOËL: Hmmm.

+ +

SARA: Even in those days, despite waterfall style still coming on the horizon. It was known for those writing software that it was important to iterate quickly.

+ +

JOËL: Wow, I would never have known.

+ +

SARA: It's neat having this history available to us. It's sort of like a lens at where we came from.

+ +

Another piece of this history that might seem like a more modern concept but was a very big part of the movement in the '70s and the '80s was using tools rather than unskilled help or trying to struggle through something yourself when you're lightening a programming task. We see this all the time at thoughtbot. Folks do this many times there is an issue on a client code. We are able to generalize the solution, extract into a tool that can then be reused.

+ +

JOËL: So that's the same kind of genesis as a lot of thoughtbot's open-source gems, so I'm thinking of FactoryBot, Clearance, Paperclip, the old-timey file upload gem, Suspenders, the Rails app generator, and the list goes on.

+ +

SARA: I love that in this last point of the Unix philosophy, they specifically call out that you should create a new tool, even if it means detouring, even if it means throwing the tools out later.

+ +

JOËL: What impact do you think that has had on the way that tooling in the Unix, or maybe I should say *Nix, ecosystem has developed?

+ +

SARA: It was a major aspect of the Nix environment community because Unix was available, not free, but very inexpensively to educational institutions. And because of how lightweight it was and its focus on single-use programs, programs that were designed to do one thing, and also the way the shell was allowing you to use commands directly and having it be the same language as the shell scripting language, users, students, amateurs, and I say that in a loving way, were able to create their own tools very quickly. It was almost like a renaissance of Homebrew.

+ +

JOËL: Not Homebrew as in the macOS package manager.

+ +

SARA: [laughs] And also not Homebrew as in the alcoholic beverage.

+ +

JOËL: [laughs] So, this kind of history is fun trivia to know. Is it really something valuable for us as a jobbing developer in 2022?

+ +

SARA: I would say it's a difficult question. If you are someone that doesn't dive into the why of something, especially when something goes wrong, maybe it wouldn't be important or useful.

+ +

But what sparked the conversation in Toronto was trying to determine why we as thoughtbot tend to prefer using Macs to develop on versus Linux or Windows. There is a reason, and the reason is in the history. Knowing that can clarify decisions and can give meaning where it feels like an arbitrary decision.

+ +

JOËL: Right. We're not just picking Macs because they're shiny.

+ +

SARA: They are certainly shiny. And the first thing I did was to put a matte case on it.

+ +

JOËL: [laughs] So no shiny in your office.

+ +

SARA: If there were too many shiny things in my office, boy, I would never get work done. The cats would be all over me.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So we've talked a little bit about Unix or *Nix, this evolution of systems. I've also heard the term POSIX thrown around when talking about things that seem to encompass both macOS and Linux. How does that fit into this history?

+ +

SARA: POSIX is sort of an umbrella of standards around operating systems that was based on Unix and the things that were standard in Unix. It stands for the Portable Operating System Interface. This allowed for compatibility between OSs, very similar to USB being the standard for peripherals.

+ +

JOËL: So, if I was implementing my own Unix-like operating system in the '80s, I would try to conform to the POSIX standard.

+ +

SARA: Absolutely. Now, not every Nix operating system is POSIX-compliant, but most are or at least 90% of the way there.

+ +

JOËL: Are any of the big ones that people tend to think about not compliant?

+ +

SARA: A major player in the operating system space that is not generally considered POSIX-compliant is Microsoft Windows.

+ +

JOËL: [laughs] It doesn't even try to be Unix-like, right? It's just its own thing,

+ +

SARA: It is completely its own thing. I don't think it even has a standard necessarily that it conforms to.

+ +

JOËL: It is its own standard, its own branch of the family tree.

+ +

SARA: And that's what happens when your operating system is very proprietary. This has caused folks pain, I'm sure, in the past that may have tried to develop software on their computers using languages that are more readily compatible with POSIX operating systems.

+ +

JOËL: So would you say that a language like Ruby is more compatible with one of the POSIX-compatible operating systems?

+ +

SARA: 100% yes. In fact, to even use Ruby as a development tool in Windows, prior to Windows 10, you needed an additional tool. You needed something like Cygwin or MinGW, which were POSIX-compliant programs that it was almost like a shell in your Windows computer that would allow you to run those commands.

+ +

JOËL: Really? For some reason, I thought that they had some executables that you could run just on Windows by itself.

+ +

SARA: Now they do, fortunately, to the benefit of Ruby developers everywhere. As of Windows 10, we now have WSL, the Windows Subsystem for Linux that's built-in. You don't have to worry about installing or configuring some third-party software.

+ +

JOËL: I guess that kind of almost cheats by just having a POSIX system embedded in your non-POSIX system.

+ +

SARA: It does feel like a cheat, but I think it was born out of demand. The Windows NT kernel, for example, is mostly POSIX-compliant.

+ +

JOËL: Really?

+ +

SARA: As a result of it being used primarily for servers.

+ +

JOËL: So you mentioned the Ruby tends and the Rails ecosystem tends to run better and much more frequently on the various Nix systems. Did it have to be that way? Or is it just kind of an accident of history that we happen to end up with Ruby and Rails in this ecosystem, but just as easily, it could have evolved in the Windows world?

+ +

SARA: I think it is an amalgam of things. For example, Unix and Nix operating systems being developed earlier, being widely spread due to being license-free oftentimes, and being widely used in the education space. Also, because it is so lightweight, it is the operating system of choice. For most servers in the world, they're running some form of Unix, Linux, or macOS.

+ +

JOËL: I don't think I've ever seen a server that runs macOS; exclusively seen it on dev machines.

+ +

SARA: If you go to an animation company, they have server farms of macOS machines because they're really good at rendering. This might not be the case anymore, but it was at one point.

+ +

JOËL: That's a whole other world that I've not interacted with a whole lot.

+ +

SARA: [chuckles]

+ +

JOËL: It's a fun intersection between software, and design, and storytelling. That is an important part for the software field.

+ +

SARA: Yeah, it's definitely an aspect that deserves its own deep dive of sorts. If you have a server that's running a Windows-based operating system like NT and you have a website or a program that's designed to be served under a Unix-based server, it can easily be hosted on the Windows server; it's not an issue. The reverse is not true.

+ +

JOËL: Oh.

+ +

SARA: And this is why programming on a Nix system is the better choice.

+ +

JOËL: It's more broadly compatible.

+ +

SARA: Absolutely. Significantly more compatible with more things.

+ +

JOËL: So today, when I develop, a lot of the tooling that I use is open source. The open-source movement has created a lot of the languages that we know and love, including Ruby, including Rails. Do you think there's some connection between a lot of that tooling being open source and maybe some of the Unix family of operating systems and movements that came out of that branch of the operating system family tree?

+ +

SARA: I think that there is a lot of tie-in with today's open-source culture and the computing history that we've been talking about, for example, people finding something that they dislike about the tools that are available and then rolling their own. That's what Ken Thompson and Dennis Ritchie did. Unix was not an official Bell development. It was a side project for them.

+ +

JOËL: I love that.

+ +

SARA: You see this happen a lot in the software world where a program gets shared widely, and due to this, it gains traction and gains buy-in from the community. If your software is easily accessible to students, folks that are learning, and breaking things, and rebuilding, and trying, and inventing, it's going to persist. And we saw that with Unix.

+ +

JOËL: I feel like this background on where a lot of these operating systems came but then also the ecosystems, the values that evolved with them has given me a deeper appreciation of the tooling, the systems that we work with today. Are there any other advantages, do you think, to trying to learn a little bit of computing history?

+ +

SARA: I think the main benefit that I mentioned before of if you're a person that wants to know why, then there is a great benefit in knowing some of these details. That being said, you don't need to deep dive or read multiple books or write papers on it. You can get enough information from reading or skimming some Wikipedia pages.

+ +

But it's interesting to know where we came from and how it still affects us today. Ruby was written in C, for example. Unix was written in C as well, originally Assembly Language, but it got rewritten in C. And understanding the underlying tooling that goes into that that when things go wrong, you know where to look.

+ +

JOËL: I guess that that is the next question is where do you look if you're kind of interested? Is Wikipedia good enough? You just sort of look up operating system, and it tells you where to go? Or do you have other sources you like to search for or start pulling at those threads to understand history?

+ +

SARA: That's a great question. And Wikipedia is a wonderful starting point for sure. It has a lot of the abbreviated history and links to better references. I don't have them off the top of my head. So I will find them for you for the show notes. But there are some old esoteric websites with some of this history more thoroughly documented by the people that lived it.

+ +

JOËL: I feel like those websites always end up being in HTML 2; your very basic text, horizontal rules, no CSS.

+ +

SARA: Mm-hmm. And those are the sites that have many wonderful kernels of knowledge.

+ +

JOËL: Uh-huh! Great pun.

+ +

SARA: [chuckles] Thank you.

+ +

JOËL: Do you read any content by Hillel Wayne?

+ +

SARA: I have not.

+ +

JOËL: So Hillel produces a lot of deep dives into computing history, oftentimes trying to answer very particular questions such as when and why did we start using reversing a linked list as the canonical interview question? And there are often urban legends around like, oh, it's because of this. And then Hillel will do some research and go through actual archives of messages on message boards or...what is that protocol?

+ +

SARA: BBS.

+ +

JOËL: Yes. And then find the real answer, like, do actual historical methodology, and I love that.

+ +

SARA: I had not heard of this before. I don't know how. And that is all I'm going to be doing this weekend is reading these. That kind of history speaks to my heart. I have a random fun fact along those lines that I wanted to bring to the show, which was that the echo command that we know and love in the terminal was first introduced by the Multics operating system.

+ +

JOËL: Wow. So that's like the most common piece of Multics that as an everyday user of a modern operating system that we would still touch a little bit of that history every day when we work.

+ +

SARA: Yeah, it's one of those things that we don't think about too much. Where did it come from? How long has it been around? I'm sure the implementation today is very different. But it's like etymology, and like taxonomy, pulling those threads.

+ +

JOËL: Two fantastic topics. On that wonderful little nugget of knowledge, let's wrap up. Sara, where can people find you online?

+ +

SARA: You can find me on Twitter at @csarajackson.

+ +

JOËL: And we will include a link to that in the show notes.

+ +

SARA: Thank you so much for having me on the show and letting me nerd out about operating system history.

+ +

JOËL: It's been a pleasure.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Why does the history of computing matter? Joël and Developer at thoughtbot Sara Jackson, ponder this and share some cool stories (and trivia!!) behind the tools we use in the industry.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +

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. And today, I'm joined by fellow thoughtboter, Team Lead, and Developer Sara Jackson.

+ +

SARA: Hello, happy to be here.

+ +

JOËL: Together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world?

+ +

SARA: Well, Joël, you might know that recently our team had a small get-together in Toronto.

+ +

JOËL: And our team, for those who are not aware, is fully remote distributed across multiple countries. So this was a chance to get together in person.

+ +

SARA: Yes, correct. This was a chance for those on the Boost team to get together and work together as if we had a physical office.

+ +

JOËL: Was this your first time meeting some members of the team?

+ +

SARA: It was my second, for the most part. So I joined thoughtbot, but after thoughtbot had already gotten remote. Fortunately, I was able to meet many other thoughtboters in May at our summit.

+ +

JOËL: Had you worked at a remote company before coming to thoughtbot?

+ +

SARA: Yes, I actually started working remotely in 2019, but even then, that wasn't my first time working remotely. I actually had a full year of internship in college that was remote.

+ +

JOËL: So you were a pro at this long before the pandemic made us all try it out.

+ +

SARA: I don't know about that, but I've certainly dealt with the idiosyncrasies that come with remote work for longer.

+ +

JOËL: What do you think are some of the challenges of remote work as opposed to working in person in an office?

+ +

SARA: I think definitely growing and maintaining a culture. When you're in an office, it's easy to create ad hoc conversations and have events that are small that build on the culture. But when you're remote, it has to be a lot more intentional.

+ +

JOËL: That definitely rings true for me. One of the things that I really appreciated about in-person office culture was the serendipity that you have those sort of random meetings at the water cooler, those conversations, waiting for coffee with people who are not necessarily on the same team or the same project as you are.

+ +

SARA: I also really miss being able to have lunch in person with folks where I can casually gripe about an issue I might be having, and almost certainly, someone would have the answer. Now, if I'm having an issue, I have to intentionally seek help. [chuckles]

+ +

JOËL: One of the funny things that often happened, at least the office where I worked at, was that lunches would often devolve into taxonomy conversations.

+ +

SARA: I wish I had been there for that.

+ +

[laughter]

+ +

JOËL: Well, we do have a taxonomy channel on Slack to somewhat continue that legacy.

+ +

SARA: Do you have a favorite taxonomy lunch discussion that you recall?

+ +

JOËL: I definitely got to the point where I hated the classifying a sandwich. That one has been way overdone.

+ +

SARA: Absolutely.

+ +

JOËL: There was an interesting one about motorcycles, and mopeds, and bicycles, and e-bikes, and trying to see how do you distinguish one from the other. Is it an electric motor? Is it the power of the engine that you have? Is it the size?

+ +

SARA: My brain is already turning on those thoughts. I feel like I could get lost down that rabbit hole very easily.

+ +

[laughter]

+ +

JOËL: Maybe that should be like a special anniversary episode for The Bike Shed, just one long taxonomy ramble.

+ +

SARA: Where we talk about bikes.

+ +

JOËL: Ooh, that's so perfect. I love it. One thing that I really appreciated during our time in Toronto was that we actually got to have lunch in person again.

+ +

SARA: Yeah, that was so wonderful. Having folks coming together that had maybe never worked together directly on clients just getting to sit down and talk about our day.

+ +

JOËL: Yeah, and talk about maybe it's work-related, maybe it's not. There's a lot of power to having some amount of deeper interpersonal connection with your co-workers beyond just the we work on a project together.

+ +

SARA: Yeah, it's like camaraderie beyond the shared mission of the company. It's the shared interpersonal mission, like you say. Did you have any in-person pairing sessions in Toronto?

+ +

JOËL: I did. It was actually kind of serendipitous. Someone was stuck with a weird failing test because somehow the order factories were getting created in was not behaving in the expected way, and we herd on it, dug into it, found some weird thing with composite primary keys, and solved the issue.

+ +

SARA: That's wonderful. I love that. I wonder if that interaction would have happened or gotten solved as quickly if we hadn't been in person.

+ +

JOËL: I don't know about you, but I feel like I sometimes struggle to ask for help or ask for a pair more when I'm online.

+ +

SARA: Yeah, I agree. It's easier to feel like you're not as big of an impediment when you're in person. You tap someone on the shoulder, "Hey, can you take a look at this?"

+ +

JOËL: Especially when they're on the same team as you, they're sitting at the next desk over. I don't know; it just felt easier. Even though it's literally one button press to get Tuple to make a call, somehow, I feel like I'm interrupting more.

+ +

SARA: To combat that, I've been trying to pair more frequently and consistently regardless of if I'm struggling with a problem.

+ +

JOËL: Has that worked pretty well?

+ +

SARA: It's been wonderful. The only downside has been pairing fatigue.

+ +

JOËL: Pairing fatigue is real.

+ +

SARA: But other than that, problems have gotten solved quickly. We've all learned something for those that I've paired with. It goes faster.

+ +

JOËL: So it was really great that we had this experience of doing our daily work but co-located in person; we have these experiences of working together. What would you say has been one of the highlights for you of that time?

+ +

SARA: 100% karaoke.

+ +

JOËL: [laughs]

+ +

SARA: Only two folks did not attend. Many of the folks that did attend told me they weren't going to sing, but they were just going to watch. By the end of the night, everyone had sung. We were there for nearly three and a half hours. [laughs]

+ +

JOËL: It was a good time all around.

+ +

SARA: I saw a different side to Chad.

+ +

JOËL: [laughs]

+ +

SARA: And everyone, honestly. Were there any musical choices that surprised you?

+ +

JOËL: Not particularly. Karaoke is always fun when you have a group of people that you trust to be a little bit foolish in front of to put yourself out there. I really appreciated the style that we went for, where we have a private room for just the people who were there as opposed to a stage in a bar somewhere. I think that makes it a little bit more accessible to pick up the mic and try to sing a song.

+ +

SARA: I agree. That style of karaoke is a lot more popular in Asia, having your private room. Sometimes you can find it in major cities. But I also prefer it for that reason.

+ +

JOËL: One of my highlights of this trip was this very sort of serendipitous moment that happened. Someone was asking a question about the difference between a Mac and Linux operating systems. And then just an impromptu gathering happened. And you pulled up a chair, and you're like, gather around, everyone. In the beginning, there was Multics. It was amazing.

+ +

SARA: I felt like some kind of historian or librarian coming out from the deep. Let me tell you about this random operating system knowledge that I have. [laughs]

+ +

JOËL: The ancient lore.

+ +

SARA: The ancient lore in the year 1969.

+ +

JOËL: [laughs] And then yeah, we had a conversation walking the history of operating systems, and why we have macOS and Linux, and why they're different, and why Windows is a totally different kind of family there.

+ +

SARA: Yeah, macOS and Linux are sort of like cousins coming from the same tree.

+ +

JOËL: Is that because they're both related through Unix?

+ +

SARA: Yes. Linux and macOS are both built based off of different versions of Unix. Over the years, there's almost like a family tree of these different Nix operating systems as they're called.

+ +

JOËL: I've sometimes seen asterisk N-I-X. This is what you're referring to as Nix.

+ +

SARA: Yes, where the asterisk is like the RegEx catch-all.

+ +

JOËL: So this might be Unix. It might be Linux. It might be...

+ +

SARA: Minix.

+ +

JOËL: All of those.

+ +

SARA: Do you know the origin of the name Unix?

+ +

JOËL: I do not.

+ +

SARA: It's kind of a fun trivia piece. So, in the beginning, there was Multics spelled M-U-L-T-I-C-S, standing for the Multiplexed Information and Computing Service. Dennis Ritchie and Ken Thompson of Bell Labs famous for the C programming language...

+ +

JOËL: You may have heard of it.

+ +

SARA: You may have heard of it maybe on a different podcast. They were employees at Bell Labs when Multics was being created. They felt that Multics was very bulky and heavy. It was trying to do too many things at once. It did have a few good concepts. So they developed their own smaller Unix originally, Unics, the Uniplexed Information and Computing Service, Uniplexed versus Multiplexed. We do one thing really well.

+ +

JOËL: And that's the Unix philosophy.

+ +

SARA: It absolutely is. The Unix philosophy developed out of the creation of Unix and C. Do you know the four main points?

+ +

JOËL: No, is it small sharp tools? It's the main one I hear.

+ +

SARA: Yes, that is the kind of quippy version that has come out for sure.

+ +

JOËL: But there is a formal four-point manifesto.

+ +

SARA: I believe it's evolved over the years. But it's interesting looking at the Unix philosophy and seeing how relevant it is today in web development. The four points being make each program do one thing well. To this end, don't add features; make a new program. I feel like we have this a lot in encapsulation.

+ +

JOËL: Hmm, maybe even the open-closed principle.

+ +

SARA: Absolutely.

+ +

JOËL: Similar idea.

+ +

SARA: Another part of the philosophy is expecting output of your program to become input of another program that is yet unknown. The key being don't clutter your output; don't have extraneous text. This feels very similar to how we develop APIs.

+ +

JOËL: With a focus on composability.

+ +

SARA: Absolutely. Being able to chain commands together like you see in Ruby all the time.

+ +

JOËL: I love being able to do this, for example, the enumerable API in Ruby and just being able to chain all these methods together to just very nicely do some pretty big transformations on an array or some other data structure.

+ +

SARA: 100% agree there. That ability almost certainly came out of following the tenets of this philosophy, maybe not knowingly so but maybe knowingly so. [chuckles]

+ +

JOËL: So is that three or four?

+ +

SARA: So that was two. The third being what we know as agile.

+ +

JOËL: Really?

+ +

SARA: Yeah, right? The '70s brought us agile. Design and build software to be tried early, and don't hesitate to throw away clumsy parts and rebuild.

+ +

JOËL: Hmmm.

+ +

SARA: Even in those days, despite waterfall style still coming on the horizon. It was known for those writing software that it was important to iterate quickly.

+ +

JOËL: Wow, I would never have known.

+ +

SARA: It's neat having this history available to us. It's sort of like a lens at where we came from.

+ +

Another piece of this history that might seem like a more modern concept but was a very big part of the movement in the '70s and the '80s was using tools rather than unskilled help or trying to struggle through something yourself when you're lightening a programming task. We see this all the time at thoughtbot. Folks do this many times there is an issue on a client code. We are able to generalize the solution, extract into a tool that can then be reused.

+ +

JOËL: So that's the same kind of genesis as a lot of thoughtbot's open-source gems, so I'm thinking of FactoryBot, Clearance, Paperclip, the old-timey file upload gem, Suspenders, the Rails app generator, and the list goes on.

+ +

SARA: I love that in this last point of the Unix philosophy, they specifically call out that you should create a new tool, even if it means detouring, even if it means throwing the tools out later.

+ +

JOËL: What impact do you think that has had on the way that tooling in the Unix, or maybe I should say *Nix, ecosystem has developed?

+ +

SARA: It was a major aspect of the Nix environment community because Unix was available, not free, but very inexpensively to educational institutions. And because of how lightweight it was and its focus on single-use programs, programs that were designed to do one thing, and also the way the shell was allowing you to use commands directly and having it be the same language as the shell scripting language, users, students, amateurs, and I say that in a loving way, were able to create their own tools very quickly. It was almost like a renaissance of Homebrew.

+ +

JOËL: Not Homebrew as in the macOS package manager.

+ +

SARA: [laughs] And also not Homebrew as in the alcoholic beverage.

+ +

JOËL: [laughs] So, this kind of history is fun trivia to know. Is it really something valuable for us as a jobbing developer in 2022?

+ +

SARA: I would say it's a difficult question. If you are someone that doesn't dive into the why of something, especially when something goes wrong, maybe it wouldn't be important or useful.

+ +

But what sparked the conversation in Toronto was trying to determine why we as thoughtbot tend to prefer using Macs to develop on versus Linux or Windows. There is a reason, and the reason is in the history. Knowing that can clarify decisions and can give meaning where it feels like an arbitrary decision.

+ +

JOËL: Right. We're not just picking Macs because they're shiny.

+ +

SARA: They are certainly shiny. And the first thing I did was to put a matte case on it.

+ +

JOËL: [laughs] So no shiny in your office.

+ +

SARA: If there were too many shiny things in my office, boy, I would never get work done. The cats would be all over me.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: So we've talked a little bit about Unix or *Nix, this evolution of systems. I've also heard the term POSIX thrown around when talking about things that seem to encompass both macOS and Linux. How does that fit into this history?

+ +

SARA: POSIX is sort of an umbrella of standards around operating systems that was based on Unix and the things that were standard in Unix. It stands for the Portable Operating System Interface. This allowed for compatibility between OSs, very similar to USB being the standard for peripherals.

+ +

JOËL: So, if I was implementing my own Unix-like operating system in the '80s, I would try to conform to the POSIX standard.

+ +

SARA: Absolutely. Now, not every Nix operating system is POSIX-compliant, but most are or at least 90% of the way there.

+ +

JOËL: Are any of the big ones that people tend to think about not compliant?

+ +

SARA: A major player in the operating system space that is not generally considered POSIX-compliant is Microsoft Windows.

+ +

JOËL: [laughs] It doesn't even try to be Unix-like, right? It's just its own thing,

+ +

SARA: It is completely its own thing. I don't think it even has a standard necessarily that it conforms to.

+ +

JOËL: It is its own standard, its own branch of the family tree.

+ +

SARA: And that's what happens when your operating system is very proprietary. This has caused folks pain, I'm sure, in the past that may have tried to develop software on their computers using languages that are more readily compatible with POSIX operating systems.

+ +

JOËL: So would you say that a language like Ruby is more compatible with one of the POSIX-compatible operating systems?

+ +

SARA: 100% yes. In fact, to even use Ruby as a development tool in Windows, prior to Windows 10, you needed an additional tool. You needed something like Cygwin or MinGW, which were POSIX-compliant programs that it was almost like a shell in your Windows computer that would allow you to run those commands.

+ +

JOËL: Really? For some reason, I thought that they had some executables that you could run just on Windows by itself.

+ +

SARA: Now they do, fortunately, to the benefit of Ruby developers everywhere. As of Windows 10, we now have WSL, the Windows Subsystem for Linux that's built-in. You don't have to worry about installing or configuring some third-party software.

+ +

JOËL: I guess that kind of almost cheats by just having a POSIX system embedded in your non-POSIX system.

+ +

SARA: It does feel like a cheat, but I think it was born out of demand. The Windows NT kernel, for example, is mostly POSIX-compliant.

+ +

JOËL: Really?

+ +

SARA: As a result of it being used primarily for servers.

+ +

JOËL: So you mentioned the Ruby tends and the Rails ecosystem tends to run better and much more frequently on the various Nix systems. Did it have to be that way? Or is it just kind of an accident of history that we happen to end up with Ruby and Rails in this ecosystem, but just as easily, it could have evolved in the Windows world?

+ +

SARA: I think it is an amalgam of things. For example, Unix and Nix operating systems being developed earlier, being widely spread due to being license-free oftentimes, and being widely used in the education space. Also, because it is so lightweight, it is the operating system of choice. For most servers in the world, they're running some form of Unix, Linux, or macOS.

+ +

JOËL: I don't think I've ever seen a server that runs macOS; exclusively seen it on dev machines.

+ +

SARA: If you go to an animation company, they have server farms of macOS machines because they're really good at rendering. This might not be the case anymore, but it was at one point.

+ +

JOËL: That's a whole other world that I've not interacted with a whole lot.

+ +

SARA: [chuckles]

+ +

JOËL: It's a fun intersection between software, and design, and storytelling. That is an important part for the software field.

+ +

SARA: Yeah, it's definitely an aspect that deserves its own deep dive of sorts. If you have a server that's running a Windows-based operating system like NT and you have a website or a program that's designed to be served under a Unix-based server, it can easily be hosted on the Windows server; it's not an issue. The reverse is not true.

+ +

JOËL: Oh.

+ +

SARA: And this is why programming on a Nix system is the better choice.

+ +

JOËL: It's more broadly compatible.

+ +

SARA: Absolutely. Significantly more compatible with more things.

+ +

JOËL: So today, when I develop, a lot of the tooling that I use is open source. The open-source movement has created a lot of the languages that we know and love, including Ruby, including Rails. Do you think there's some connection between a lot of that tooling being open source and maybe some of the Unix family of operating systems and movements that came out of that branch of the operating system family tree?

+ +

SARA: I think that there is a lot of tie-in with today's open-source culture and the computing history that we've been talking about, for example, people finding something that they dislike about the tools that are available and then rolling their own. That's what Ken Thompson and Dennis Ritchie did. Unix was not an official Bell development. It was a side project for them.

+ +

JOËL: I love that.

+ +

SARA: You see this happen a lot in the software world where a program gets shared widely, and due to this, it gains traction and gains buy-in from the community. If your software is easily accessible to students, folks that are learning, and breaking things, and rebuilding, and trying, and inventing, it's going to persist. And we saw that with Unix.

+ +

JOËL: I feel like this background on where a lot of these operating systems came but then also the ecosystems, the values that evolved with them has given me a deeper appreciation of the tooling, the systems that we work with today. Are there any other advantages, do you think, to trying to learn a little bit of computing history?

+ +

SARA: I think the main benefit that I mentioned before of if you're a person that wants to know why, then there is a great benefit in knowing some of these details. That being said, you don't need to deep dive or read multiple books or write papers on it. You can get enough information from reading or skimming some Wikipedia pages.

+ +

But it's interesting to know where we came from and how it still affects us today. Ruby was written in C, for example. Unix was written in C as well, originally Assembly Language, but it got rewritten in C. And understanding the underlying tooling that goes into that that when things go wrong, you know where to look.

+ +

JOËL: I guess that that is the next question is where do you look if you're kind of interested? Is Wikipedia good enough? You just sort of look up operating system, and it tells you where to go? Or do you have other sources you like to search for or start pulling at those threads to understand history?

+ +

SARA: That's a great question. And Wikipedia is a wonderful starting point for sure. It has a lot of the abbreviated history and links to better references. I don't have them off the top of my head. So I will find them for you for the show notes. But there are some old esoteric websites with some of this history more thoroughly documented by the people that lived it.

+ +

JOËL: I feel like those websites always end up being in HTML 2; your very basic text, horizontal rules, no CSS.

+ +

SARA: Mm-hmm. And those are the sites that have many wonderful kernels of knowledge.

+ +

JOËL: Uh-huh! Great pun.

+ +

SARA: [chuckles] Thank you.

+ +

JOËL: Do you read any content by Hillel Wayne?

+ +

SARA: I have not.

+ +

JOËL: So Hillel produces a lot of deep dives into computing history, oftentimes trying to answer very particular questions such as when and why did we start using reversing a linked list as the canonical interview question? And there are often urban legends around like, oh, it's because of this. And then Hillel will do some research and go through actual archives of messages on message boards or...what is that protocol?

+ +

SARA: BBS.

+ +

JOËL: Yes. And then find the real answer, like, do actual historical methodology, and I love that.

+ +

SARA: I had not heard of this before. I don't know how. And that is all I'm going to be doing this weekend is reading these. That kind of history speaks to my heart. I have a random fun fact along those lines that I wanted to bring to the show, which was that the echo command that we know and love in the terminal was first introduced by the Multics operating system.

+ +

JOËL: Wow. So that's like the most common piece of Multics that as an everyday user of a modern operating system that we would still touch a little bit of that history every day when we work.

+ +

SARA: Yeah, it's one of those things that we don't think about too much. Where did it come from? How long has it been around? I'm sure the implementation today is very different. But it's like etymology, and like taxonomy, pulling those threads.

+ +

JOËL: Two fantastic topics. On that wonderful little nugget of knowledge, let's wrap up. Sara, where can people find you online?

+ +

SARA: You can find me on Twitter at @csarajackson.

+ +

JOËL: And we will include a link to that in the show notes.

+ +

SARA: Thank you so much for having me on the show and letting me nerd out about operating system history.

+ +

JOËL: It's been a pleasure.

+ +

The show notes for this episode can be found at bikeshed.fm.

+ +

This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+bEe-iImU + + ]]> + + Joël Quenneville + + + 353: Mental Models + https://bikeshed.thoughtbot.com/353 + b22520ce-444d-4bf6-a175-f351f95e2fae + Tue, 06 Sep 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Mental models are metaphors that help us understand complex problems we work on. They can be a simplified roadmap over an infinite area of complexity. + +How does one come up with mental models? How are they useful? Are they primarily a solo thing, or can they be used to communicate with the team? What happens when your model is inaccurate? Today, Joël is joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget, to discuss. + 38:22 + no + + + Mental models are metaphors that help us understand complex problems we work on. They can be a simplified roadmap over an infinite area of complexity. +How does one come up with mental models? How are they useful? Are they primarily a solo thing, or can they be used to communicate with the team? What happens when your model is inaccurate? Today, Joël is joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget, to discuss. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Eebs on Twitter (https://twitter.com/EebsKobeissi) +You Need a Budget (https://www.youneedabudget.com/) +Skill floors and skill ceilings (https://thoughtbot.com/blog/who-is-empowered-by-your-design) +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. And today, I'm joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget. +EEBS: Hi, Joël. It's really good to be here. +JOËL: And together, we're here to share a little bit about what we've learned along the way. So, Eebs, what's new in your world? +EEBS: Oh, a whole lot. I'm a new dad, so I'm getting to experience all those things. But in the developer world, I've recently picked up programming on an ESP32, which controls LED lights. And so I'm having fun lighting up my office. +JOËL: Is that like one of those little microboards, kind of like a Raspberry Pi? +EEBS: Yeah, exactly. It's a little board that's compatible with the Arduino IDE. And I literally only played with it last weekend, so it's still very new to me. +JOËL: Nice. Have you done any Arduino development or Raspberry Pi or anything like that before? +EEBS: No, I have a Raspberry Pi that I run like a DNS server on, but I haven't done any actual programming. I did make an LED blink, which is pretty cool. +JOËL: What kind of programming is required for a board like that? +EEBS: From my understanding, it's either in Python or C. Those are, I think, the two languages that you can program on it. I definitely do not know C. And so I'm just going through a bunch of tutorials and reading some sample code. But I think if I ever end up trying to implement something more complex, I'll probably switch over to Python because that's a little more familiar. +JOËL: So the coding feels fairly high level even though you're writing controller code for LEDs. +EEBS: I hope so. I'd love to be able to take advantage of whatever abstractions I can. +JOËL: Do you have any fun goals you're trying to do with this? Or is this just for the fun of trying a completely different environment than web development? +EEBS: No, it's actually rooted in something visual. So I have these shelves behind me that are in my webcam when I'm in meetings or whatever. And so I want to be able to put a light strip across these shelves and have some sort of visual thing in the background. +JOËL: Like LED mood ring? +EEBS: Yeah, kind of. My eventual goal would be that as I'm talking, a little equalizer display pops up behind me. I thought that would be pretty neat. +JOËL: That is amazing. That will give you all of the cred in the meetings. +EEBS: Right? I thought that'd be pretty cool. What have you been thinking about recently, Joël? +JOËL: I've been submitting to the RubyConf call for proposals which, as of the recording of this episode, has just closed this week. And like many people, I submitted on the last day. +EEBS: [laughs] +JOËL: And it was really fun trying to take some ideas that I'm excited about and then turn them into a proposal that is accessible to other people. +EEBS: Nice. Do you want to share a little bit about what the talk is, or is it under wraps for now? +JOËL: I don't know if anyone on the committee will listen to this before the review goes out. This might break the anonymity of the proposal. +EEBS: Oh, right, right. +JOËL: One thing I will share that's interesting is that there are topics that I'm excited about. It's like, oh, here are a bunch of cool things about something, some technical topic. But talks that are just ten cool things about X are not that great. And so I needed to find some sort of unifying idea that I could use to share that. And that generally is in the form of trying to find a story that I can tell. What unifies all of these things together? What tells a compelling story? Is there some metaphor I can lean into? +EEBS: Nice. I think that's a really powerful way of communicating something deeper is through telling something that people can relate to. +JOËL: One way that thinking about metaphors has been really impactful for me recently is the idea of mental models and how those can help us in development. I'm curious; we've thrown around the phrase a little bit you and I in past conversations; what does a mental model mean to you? +EEBS: I tend to be a visual thinker. And from talking to others, I've heard similar statements. So for me, a mental model is how I think about a particular domain or how I think about code flow or structure. And for me, it's usually either as two-dimensional objects or occasionally three-dimensional objects that I have floating in my visual space. +So, for example, if we had two classes that are collaborators in some way, I often think of them maybe as two rectangles that are side by side. And when they interact, there's some little amorphous blob from one of those rectangles that reaches out into the other one or passes a message from one to the other. +And I sort of have this idea of how many connections are there between these two physical things. Or, if I'm thinking about code flow and the path of execution that code might take, sometimes I visualize it as maybe a tree or potentially loops if there are such cases. +JOËL: So when you think of these concepts, just in general, you're seeing in your mind's eye squares and rectangles floating in the air. +EEBS: Yeah, pretty often. Sometimes it takes those shapes, and as I build up a mental model of some code, I'm usually adding new shapes into that picture I have in my mind. I tend to view things sort of top-down. So like, the start of code or the start of execution is usually at the top or maybe the far left or far right. +And as execution happens, I usually view that as moving in towards the middle and potentially going back out when a response is returned. If it's a web request, something like that, I view it as this sort of outside in. And there's a bunch of pieces in there that are all talking to each other. +JOËL: That's really cool. So not only is there a geometric aspect to it, but there's a spatial aspect to it as well. +EEBS: Yeah. And it's interesting, like, I haven't actually thought about it [laughs] in this level of detail before. But yeah, there certainly is a spatial aspect to it. And I have this idea in my mind of like things and domain objects kind of belong at the bottom, and they should have well-defined boundaries. But the pieces that are a little bit towards the outer edges may be a little more fuzzy and may have less definition around them. +JOËL: That's really interesting because I also have this sort of in my mind's eye see these things when I'm thinking about concepts like that. But I've talked to other people, and some people don't even have much of a mind's eye at all. They don't tend to visualize things in their mind in that way. +EEBS: Yeah, it's really interesting how different people approach this thinking about code. A lot of people write things down. And I write things down, too, and draw little arrows that don't really make any sense. But it helps me do something physically sometimes as well as just thinking about it. +JOËL: Have you ever tried to convert these pictures you see in your mind and actually draw them on paper? +EEBS: Occasionally. And for the most part, that usually takes the form of some kind of domain modeling, whether it's based on database tables or just domain objects. And sometimes I will try and draw them out and then specify the relationships between them like, oh, you know, this one model talks to this other model in this particular way. And I'll define a relationship between them, which helps me think about them and how they interact. +JOËL: I've found that even though for some things I can see it very vividly in my mind's eye, I struggle to then concretely translate that onto paper or digital paper if you will. It's almost like trying to, say, translate an emotion into words and that even though I feel like I see a visual picture, I can't reproduce it by drawing necessarily. +EEBS: It's interesting you brought up feeling because a lot of the times, I have this gut feeling about a mental model, like whether I think it is correct or not. And sometimes I have this uneasy feeling of, like, that doesn't feel right to me, but it's hard to articulate why. And I think sometimes that's when I have to pull out something physical, start making those relations, start connecting things. +And that's when I might uncover, like, oh, this feels odd because I have a circle here or a cycle or something. Or I've sort of represented the truth of something in two different places. Do you have any techniques for getting it out of your head and into something physical that you could share with someone else, maybe it's text or a picture? +JOËL: I think I do struggle with that conversion sometimes. Practice definitely helps. I think maybe there is a metaphor here between converting these, let's call them, pictures that I see in my mind's eye and then drawing diagrams with trying to take feelings and expressing them in words. In the same way that, maybe I might have some feelings, and then I want to journal how I feel, and I struggle to express that. +But finding a way to express that gives me a certain amount of precision and a more concrete thing. In the same way, these things that flash in front of my mind's eye, if I can take the time to put them on paper, they're now more real. They're more concrete. I think you can probe the edges, the ways that it kind of falls apart more easily. +EEBS: Yeah, that makes a lot of sense. There's a lot of value in writing that down and going through those details in a methodical way because oftentimes, you'll catch inconsistencies, or you'll find better ways to describe it. And being able to share your mental model with someone else is often...well, it can be really tricky. +And I think that's why it's important to go through and maybe find a common medium that you can share because I can't see into your brain. You can't see into mine. But if we can share our mental models, then hopefully, we have a better chance of agreeing on the solution or finding inconsistencies. +JOËL: Exactly. I think, in many ways, there are almost multiple layers of mental models and that you might have an abstraction or a metaphor for a concept that you're working with separate from the diagram. And then the diagram is yet another metaphor, but now we're going geometric to represent a broader idea. +EEBS: Yeah. Are there any other ways that you take that picture from your mind's eye besides written documents or conversations? Do you use any diagramming tools that specifically help with that? Or is it just kind of free-form? +JOËL: I do a mix. I am a big fan of draw.io, which allows you to just free-hand or pull shapes together, things like that. There are some more structured tools that I will use. I'll use Mermaid.js. +EEBS: Yeah, I've been using that a lot too. +JOËL: Yeah, that's great. I've been digging into more structured diagrams recently, particularly the idea of graphs, directed graphs. And those have interesting properties. +EEBS: Can you share a little more detail about what you mean? +JOËL: So a graph in the computer science sense is a bunch of nodes. They are typically represented as circles and then edges which are the connections between them. A directed graph is now there's an arrow pointing in a particular direction. A really interesting property that you can have with directed graphs is whether or not they include cycles. So can you only by following the arrows effectively create a loop? Or will the arrows always lead you to some kind of terminal node? +EEBS: Gotcha. Is that a directed acyclic graph? +JOËL: If there are no cycles, yes, it is a directed acyclic graph or DAG, as you'll often see it abbreviated. +EEBS: [laughs] How do you relate that graph to code? And what benefits do you get from expressing it that way? +JOËL: So this shows up in a lot of places. And I'd even say that thinking of certain aspects of my code as a graph and a potentially directed acyclic graph is itself a mental model or a metaphor that helps bring clarity to the way I think about things. So, for example, code, you know, you invoke some main function at some point to call the code, and then that's going to call out some other functions, which call out some other functions, and so on. You may have heard that referred to as a call graph. But that is a graph of calls. +There might be cycles in there for co-recursive functions and things like that. But that is one way you can then sift through and analyze how control flow or how logic flows through your application is through a function graph. You mentioned earlier the idea of objects and how they're connected to each other. That's an object graph. +EEBS: Right. Recently, I had to work through a state transition problem where a customer has some billing, and they can go through many different states, whether it's active, or canceled, or past due, those sorts of things. And so actually, I reached for Mermaid.js and built a graph of, okay, they start here in this empty state. And then they subscribe, which then they become active. They might cancel their subscription, which moves them to a different state. +And by listing out all the states and the transitions between them, it helped me to understand what methods I might need to define on which objects in order to allow those transitions to happen and what checks I might need to make before allowing those transitions depending on the state of the system. +JOËL: I'm hearing the keywords states and transitions. And that's making me think of finite-state machines. Are you drawing a finite-state machine graph or something a bit more free-handed? +EEBS: It's a bit more of free-handed. I don't think I've actually drawn out a state machine since college but just representing the different states as different boxes and the transitions that are possible from those states. I mean, I guess that kind of is a state machine in some way. So graphs are great visual approaches. Are there any non-visual approaches that you take? +JOËL: That's a great question because not all mental models have to be visual. I think the power of a mental model exists in a metaphor. And one that's kind of broad but that I've applied to a lot of different areas is the general idea of something being parallel or in series. I think I first came across this concept talking about electric circuits. And are we talking about two little light bulbs that are in parallel, and if the electricity to one is cut, the other one still lights up? Or are they chained together in series? +EEBS: Yeah, like my LEDs. +JOËL: Exactly, going back to Arduino, but it can also be applied to a bunch of other things. We can talk about code being in parallel or in series. We can talk about work being in parallel or in series. Interestingly, I took that mental model as a sort of quick shortcut when I was digging into some functional programming ideas. Monads and applicatives are the fancy terms here. +EEBS: Oh boy, I'm ready. +JOËL: In general, and there's a hefty asterisk here, I think of monads as being serial, so you're chaining something; one thing happens, then another. So you can think of, for example, chaining promises in JavaScript, promise one, then promise two, as opposed to applicatives which are parallel. So you might think of maybe zipping two lists or two arrays in Ruby. The two arrays, there are no dependencies between the two of them. They get processed side by side as you're traversing both of them together. +EEBS: Interesting. I've heard the term monad a lot, but I haven't heard the term applicative. Are there any other details you can share about them and what makes them different or how they might be seen in our code? +JOËL: I think that the key difference is that distinction in how they're processed. Applicatives are a way of combining two independent, let's call them data sources, and then you find a way to combine them together. So it could be two independent arrays, and you're zipping through them. It might be two independent HTTP requests, and they can both fire in parallel. But then you want to combine their outputs. So you say wait until both are successful and then combine their output. +EEBS: Oh, okay, gotcha. +JOËL: It could even be nullable values. So you say do this thing if both values are present. But you're not...the value of one or the fact that one is null or not is not dependent on whether the other one is null or not. They're independently null or not as opposed to something...Monads are, again, a different way of combining. You might call them data sources or operations. But in this case, there is a clear dependency one, and then its output influences the next one. +You might say check the value is null or present or not. And then, if it is present, take that value and then put it as the input of my next operation. And then, if it is null or not, do another thing. See, now you have a sort of chain. +EEBS: Where do you see these chains happening in code? Or is it everywhere? +JOËL: Once you know that pattern which, again, could be thought of as another mental model, you start seeing it everywhere. So promises in JavaScript chaining together that's effectively monads. Don't @ me, all the functional programming people. +EEBS: [laughs] +JOËL: I know that's not quite true. Anything dealing with multiple operations that could succeed or fail depending on, again, whether you're treating them as dependent or independent, that's probably going to look very similar to either monad or applicative. +EEBS: So the first thing that actually comes to mind here is things like background jobs. Using Sidekiq or Resque or other job processors, you can have a queue of jobs that need to be executed, and they might need to run in serial, or potentially you have multiple workers pulling from a single queue, and thus the work is happening in parallel. Is that a reasonable analogy? +JOËL: I think it's good for the serial versus parallel, but it's not necessarily a good analogy for understanding monads and applicatives. +EEBS: Gotcha. +JOËL: So with two workers, you can process a queue in parallel, and a bunch of things happen. +EEBS: But there's not necessarily anything that is bringing those two workers together to produce a single output. +JOËL: Yes. And there's no dependency between the tasks in the queue. +EEBS: Right, right, gotcha. +JOËL: So if you have a task that says execute this task and then only if this task succeeds, then do the second task, now you've created a dependency. And you couldn't process that in parallel because if task one, which has to be executed first, is executed by worker one, task two should not get processed unless task one is successful. You can't just say, oh, I've got another worker free. I haven't processed task two because it's waiting to know does task one succeed. +EEBS: Right. So an example in code would be a user creates a new order. And when they create a new order, we send them a confirmation email. That would be an example of that happening in serial or a monad-like thing. [chuckle] +JOËL: Yes, I found that thinking of things as serial or parallel is a good shortcut for thinking about monads and applicatives. I don't know that the reverse is necessarily true. They don't necessarily transfer one-to-one with each other. And maybe that's a danger of mental models, right? You find a mental model that describes a situation, and then you try to reverse it, and then you make false assumptions about the world. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: Another mental model that is not necessarily visual that I like actually comes from the video game community, and that's thinking of skill ceilings and skill floors. So in, I think, particularly the MOBA Community, that's a Multiplayer Online Battle Arena, they'll talk about characters as having a high skill floor or a low skill ceiling. +And generally, what that means, and again, the meaning varies a little bit by community, is that a character with a low-skill floor is an easily accessible character. They might not have a lot of skill shots, like, you press a button, and things happen around your character. You don't need to aim, things like that. A high skill ceiling means that there's a lot of room for you to grow, and as you get more skilled, you can get significantly better with that character. +EEBS: Gotcha. So the opportunity is greater with a higher skill ceiling. +JOËL: Correct. And depending on how the character is set up, you might have a very narrow range that could be in the low range where it has a low skill floor and a low skill ceiling, which means that the character is easy to learn. But once you've learned it, there's not really a lot you can do with it. It's a fairly basic character. So getting better at the game is not necessarily going to make you that much more impactful. +And then you could have one that's the opposite that is high both skill floor and skill ceiling where a character is very hard to learn. But once you learn it, that's kind of all there is to it. And then you might have one that has a large range somewhere; maybe it's easy to learn, but it's hard to master, or there's a lot of room for growth. +And so, taking this framework for analyzing characters and video games, I think we can apply that to technology in general. This could be language design. This could be just API design. And you might say, well, I want this to be very accessible. People can jump in very easily. You might say I want this to be very powerful and have a lot of high-end features that make your power users very happy and very productive. +EEBS: That's interesting. When you first were talking about it, I was actually less thinking about it from a user's perspective of what maybe they could do in the application but potentially from the standpoint of a developer writing the system itself. +One of the pieces I always come back to in software development is that change is inevitable. And so, making something easy to change often pays great benefits down the road. And so I wonder how that fits into this idea of a low skill ceiling or a high skill ceiling in terms of perhaps flexibility or being decoupled such that you can take one idea and easily extend it or easily get more from it than you originally set out to build. +JOËL: There's often a trade-off. So you make something easy to change. It's highly decoupled. But you maybe introduce more indirection to the system. So while it's easier to change one single piece, it's harder to understand the system as a whole. +EEBS: Yeah, that's true. And sometimes, you bake in assumptions that you make about the future, which turn out not to be true. +JOËL: [laughs] Yes, that is definitely something I'm guilty of. +EEBS: I think we all are. +JOËL: One thing that I find interesting is as you evolve the design of an architecture pattern, a system, a whole language, you might want to move one of those if I think of them like two independent sliders on a one-dimensional scale. So maybe you want to move the upper boundary a little bit and say I want a higher skill ceiling for this, but they don't actually move completely independently. +So introducing some advanced features might inadvertently also raise the skill floor. And conversely, making the language super accessible so that it has a low-skill floor, you might have to decide I will not introduce certain features. +EEBS: One thing I wanted to ask you about is, do you view different languages as having different skill floors and ceilings? And, you know, I love Ruby. I know you love Element. I've played with Element. It's been a great learning tool for me. How do you view those two languages in terms of skill ceilings and skill floors in terms of, I guess, what you can do with them? +JOËL: That's a great question. And I think you can definitely apply that to languages. Admittedly, I think you could probably start a lot of flame wars with that. +EEBS: [chuckles] Let's not do that. +JOËL: I wrote an article a while back where I applied that mental model to look at the F# programming language. And there was a debate in that community about certain features to add and whether they would allow advanced programming but potentially at the cost of accessibility to newer members of the community and how to balance those. And so I thought, hey, let's throw this video game metaphor at the problem and talk about it through that lens. +EEBS: That's really cool. Did you draw any conclusions, or was it as a way to start a conversation? +JOËL: It is a way to start a conversation. I don't think there is a single correct or best distribution of your skill, ceiling, and floor. It has to match the goals you set out for your project. Just like in games, people love to rank which characters are best and not. And sometimes you can show that, in general, this character is better. +But oftentimes, in a balanced game, you can talk about this character being easier to get started with or this character working very well if you're a pro. But the fact that you have a higher or lower skill ceiling or floor doesn't necessarily make the character better or worse. +EEBS: So, this conversation about differing mental models, I think I hadn't realized that there can be so many different types of mental models. And some things that I do in my thinking I haven't classified as a mental model. But now that you bring it up, I think one that I think about fairly often is this idea of two objects that are collaborators and reaching into the internals of one of those objects from the other object. +So A and B are two separate things. And if A reaches into B's bucket and messes with the state of B, I view that as sort of a bad practice. You're not really adhering to maybe the public API that that object is exposing. You're kind of reaching in and going around behind its back and changing some stuff that it may not expect. +JOËL: Would you refer to that maybe as tight coupling? +EEBS: Yeah, it's definitely tight coupling. It's not just tightly coupled; it's almost worse than that. It's almost like going behind somebody's back and making a change without them knowing. And so when I see that in code or when I write code that does that, I have this really intense desire to separate that and to say, no, no, you can't go in and update this record directly in the database. You have to send it a message and say, "Hey, I would like you to be aware of something," and then it goes and changes its own internal state as a response to that. +And so I have this very vivid sort of mental feeling of it being wrong, of it being like, I'm being sneaky, or I'm not being gracious to the person I'm interacting with as though I were one of these objects. +JOËL: That's fascinating. You've practically anthropomorphized these objects. +EEBS: I do. I view them as little people. +JOËL: You describe this interaction as going behind someone's back. That is the thing that I, a person, do to someone else. It's not a function making a direct call. And yet, it's such a strong...we use a social mental model to talk about objects and interactions. +EEBS: Yeah, I almost want them to be friends. And I think that applies to real-life relationships, right? If you have a nice dialogue back and forth, there's an understanding. There's commonality that you can find. But if I were to go do something behind your back without chatting with you about it first, you might not be so happy with me. +JOËL: I'd feel betrayed. +EEBS: Right. +JOËL: I feel like there's probably a really fun conference talk to be done about that. We often use that metaphor; I think when talking about objects sort of subconsciously but making it explicit and just being, hey, let's talk about these objects as if they were people. Why don't we want to do this? Because this one here is betraying the other object there. This one here is being impolite. +EEBS: We could have two people get on stage and talk to each other. And I might then go and reach in your pocket and pull out some change without you knowing, and you might be upset with me. +JOËL: That would be great. Get a little skit going up on stage. Or even if you're artistically inclined, you could probably draw some really fun little characters to illustrate this. +EEBS: That would be really cool. I, unfortunately, don't have the artistic talent to do that. +JOËL: Well, free conference talk idea to all listeners of the podcast. I expect to see this for RailsConf 2023, maybe. +EEBS: I'll be looking for it. So I've shared a mental model that I didn't really know was a mental model. Are there other mental models that you want to share that I may not be thinking of? +JOËL: Here's one that I've just come to realize recently that I'm actually quite excited about: when you think about the word refactoring, how would you describe that idea? +EEBS: Well, refactoring to me is changing the implementation without changing the behavior. +JOËL: Yes, I think that is the classical definition. You should be able to change the implementation of a method, and the tests without changing are still green after you've done that. +EEBS: I guess, mentally, I think about that as perhaps drawing a box around some of the objects that are floating in my mind's eye, rearranging how they exist within that box, and then the box dissolves. And the tests still pass, but the structure of the objects or the code has changed in my mind. +JOËL: I love that you immediately went to a visual approach there. And I think I have something similar, but I'm coming at it from a slightly more domain modeling perspective. So thinking maybe less from an individual method approach but looking at maybe a larger system, what you're trying to do is use code to describe some version of reality. So it might be a business process that you have. It might be trying to describe some aspect of your customer's life that you're trying to automate for them. +Oftentimes, this thing you're trying to describe in code terms is going to be a simplification because life has a ton of edge cases, and many of them we don't care about. So if we go with a visual metaphor here, you're trying to draw some kind of shape using only straight lines to approximate some weird curve. +And so, let's say you draw something with only four lines. It's really simple, how you have a diamond. That's the shape you're trying to create. And then you're going to fill it in with little other shapes that approximate a diamond. And those are your different models and functions and all the other components that we use to build software. +At some point, your understanding of the underlying reality might change. Maybe you need more precision, or maybe the actual feature requirements have changed. The thing you're trying to approximate with your code is not a diamond. Maybe you've added a few more sides to it. It's a pentagon. So we've gone from four sides to five. And the little components, and modules, and things that you have there approximate that diamond work. +They still mostly approximate your pentagon, but it's really clunky because the initial design was to approximate something else. They were really good for fitting in really tightly and being very loosely coupled to each other when we were trying to do a diamond, but then they don't work as well in the pentagon. +EEBS: So maybe some of the internal shapes need to change or adjust to fill the space that the pentagon has now created. +JOËL: To fill the space or maybe even just to fill it in a way that's less clunky. And so the idea here in this metaphor is that the reality we're targeting in software is always changing. And so the underlying reality changes, and so we're changing that shape that we're creating all the time. +But also, we're getting more precision as we decide; oh, we care about this edge case now. We didn't in version one, and so as part of that, we're constantly having to take the modules that maybe were very well designed initially but then restructure them to fit the new requirements because now there's a fourth object coming in, and it's kind of clunky with our current configuration. +EEBS: That's interesting. One of the first things that jumps to mind is that maybe there are better ways or worse ways to do that refactoring to fit that new shape. Do you think there's any truth to that in the sense that you might initially design a system that perfectly fits that diamond or very closely fits that diamond but then as it changes to a pentagon, do you need to simply add a new piece to fill in that empty space? Or do you need to restructure everything within the diamond now to fit the shape of the pentagon? +JOËL: Oftentimes, you do need to restructure. And I think there's this wonderful little phrase from; I believe it's Kent Beck that says, "Make the change easy, and then make the easy change." +EEBS: Yep. +JOËL: And so, to me, that makes the change easy is that initial restructuring that you need to do of those first shapes so that you can finally bring in the new one. +EEBS: Oh, that's a cool visual. I immediately can imagine the pieces in the pentagon moving around to make space for a new piece that you need to now bring in. And that movement of all those pieces can be really difficult. +Have you ever played that game where it's a square, and you're trying to get a ship out of a port, but there's a whole bunch of other ships, and you can only move them left and right and up and down? And you can do that. And that's what I'm picturing right now is moving shapes within that pentagon to then make space for either a new shape or to allow a shape to escape that is no longer relevant. +JOËL: I played a version of that that had cars, cars, and trucks. +EEBS: Gotcha. Yeah, I think I played that too. +JOËL: That would also be a fun conference talk, right? Like, start with that game as your initial metaphor. And then you use that as a way to talk about refactoring. +EEBS: That would be really cool. +JOËL: I would watch that talk. To anybody listening who wants to give that talk, I want to see you at RailsConf 2023. +EEBS: [laughs] Are we just a talk factory now? +[laughter] +JOËL: I love talk ideas. Maybe this should become a segment. Just have Eebs come in for five minutes once a month and give us a talk idea. It could even be fun to see a talk idea that multiple people implemented differently. +EEBS: That would be really cool, actually. I always get nervous about giving talks or being on podcasts like this one. I would love to be the person that gets to sit there and throw out random ideas and have other people fulfill my dreams. +JOËL: Well, thank you so much, Eebs, for joining us to talk about mental models. And to all of our listeners, I'd love to hear about what mental models you find are helpful, and so please share them with us. On Twitter, you can reach us at @_bikeshed. +EEBS: Thanks for having me, JOËL. This has been super fun. +JOËL: And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. +Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Mental models are metaphors that help us understand complex problems we work on. They can be a simplified roadmap over an infinite area of complexity.

+ +

How does one come up with mental models? How are they useful? Are they primarily a solo thing, or can they be used to communicate with the team? What happens when your model is inaccurate? Today, Joël is joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget, to discuss.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Eebs on Twitter
+You Need a Budget
+Skill floors and skill ceilings

+ +

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. And today, I'm joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget.

+ +

EEBS: Hi, Joël. It's really good to be here.

+ +

JOËL: And together, we're here to share a little bit about what we've learned along the way. So, Eebs, what's new in your world?

+ +

EEBS: Oh, a whole lot. I'm a new dad, so I'm getting to experience all those things. But in the developer world, I've recently picked up programming on an ESP32, which controls LED lights. And so I'm having fun lighting up my office.

+ +

JOËL: Is that like one of those little microboards, kind of like a Raspberry Pi?

+ +

EEBS: Yeah, exactly. It's a little board that's compatible with the Arduino IDE. And I literally only played with it last weekend, so it's still very new to me.

+ +

JOËL: Nice. Have you done any Arduino development or Raspberry Pi or anything like that before?

+ +

EEBS: No, I have a Raspberry Pi that I run like a DNS server on, but I haven't done any actual programming. I did make an LED blink, which is pretty cool.

+ +

JOËL: What kind of programming is required for a board like that?

+ +

EEBS: From my understanding, it's either in Python or C. Those are, I think, the two languages that you can program on it. I definitely do not know C. And so I'm just going through a bunch of tutorials and reading some sample code. But I think if I ever end up trying to implement something more complex, I'll probably switch over to Python because that's a little more familiar.

+ +

JOËL: So the coding feels fairly high level even though you're writing controller code for LEDs.

+ +

EEBS: I hope so. I'd love to be able to take advantage of whatever abstractions I can.

+ +

JOËL: Do you have any fun goals you're trying to do with this? Or is this just for the fun of trying a completely different environment than web development?

+ +

EEBS: No, it's actually rooted in something visual. So I have these shelves behind me that are in my webcam when I'm in meetings or whatever. And so I want to be able to put a light strip across these shelves and have some sort of visual thing in the background.

+ +

JOËL: Like LED mood ring?

+ +

EEBS: Yeah, kind of. My eventual goal would be that as I'm talking, a little equalizer display pops up behind me. I thought that would be pretty neat.

+ +

JOËL: That is amazing. That will give you all of the cred in the meetings.

+ +

EEBS: Right? I thought that'd be pretty cool. What have you been thinking about recently, Joël?

+ +

JOËL: I've been submitting to the RubyConf call for proposals which, as of the recording of this episode, has just closed this week. And like many people, I submitted on the last day.

+ +

EEBS: [laughs]

+ +

JOËL: And it was really fun trying to take some ideas that I'm excited about and then turn them into a proposal that is accessible to other people.

+ +

EEBS: Nice. Do you want to share a little bit about what the talk is, or is it under wraps for now?

+ +

JOËL: I don't know if anyone on the committee will listen to this before the review goes out. This might break the anonymity of the proposal.

+ +

EEBS: Oh, right, right.

+ +

JOËL: One thing I will share that's interesting is that there are topics that I'm excited about. It's like, oh, here are a bunch of cool things about something, some technical topic. But talks that are just ten cool things about X are not that great. And so I needed to find some sort of unifying idea that I could use to share that. And that generally is in the form of trying to find a story that I can tell. What unifies all of these things together? What tells a compelling story? Is there some metaphor I can lean into?

+ +

EEBS: Nice. I think that's a really powerful way of communicating something deeper is through telling something that people can relate to.

+ +

JOËL: One way that thinking about metaphors has been really impactful for me recently is the idea of mental models and how those can help us in development. I'm curious; we've thrown around the phrase a little bit you and I in past conversations; what does a mental model mean to you?

+ +

EEBS: I tend to be a visual thinker. And from talking to others, I've heard similar statements. So for me, a mental model is how I think about a particular domain or how I think about code flow or structure. And for me, it's usually either as two-dimensional objects or occasionally three-dimensional objects that I have floating in my visual space.

+ +

So, for example, if we had two classes that are collaborators in some way, I often think of them maybe as two rectangles that are side by side. And when they interact, there's some little amorphous blob from one of those rectangles that reaches out into the other one or passes a message from one to the other.

+ +

And I sort of have this idea of how many connections are there between these two physical things. Or, if I'm thinking about code flow and the path of execution that code might take, sometimes I visualize it as maybe a tree or potentially loops if there are such cases.

+ +

JOËL: So when you think of these concepts, just in general, you're seeing in your mind's eye squares and rectangles floating in the air.

+ +

EEBS: Yeah, pretty often. Sometimes it takes those shapes, and as I build up a mental model of some code, I'm usually adding new shapes into that picture I have in my mind. I tend to view things sort of top-down. So like, the start of code or the start of execution is usually at the top or maybe the far left or far right.

+ +

And as execution happens, I usually view that as moving in towards the middle and potentially going back out when a response is returned. If it's a web request, something like that, I view it as this sort of outside in. And there's a bunch of pieces in there that are all talking to each other.

+ +

JOËL: That's really cool. So not only is there a geometric aspect to it, but there's a spatial aspect to it as well.

+ +

EEBS: Yeah. And it's interesting, like, I haven't actually thought about it [laughs] in this level of detail before. But yeah, there certainly is a spatial aspect to it. And I have this idea in my mind of like things and domain objects kind of belong at the bottom, and they should have well-defined boundaries. But the pieces that are a little bit towards the outer edges may be a little more fuzzy and may have less definition around them.

+ +

JOËL: That's really interesting because I also have this sort of in my mind's eye see these things when I'm thinking about concepts like that. But I've talked to other people, and some people don't even have much of a mind's eye at all. They don't tend to visualize things in their mind in that way.

+ +

EEBS: Yeah, it's really interesting how different people approach this thinking about code. A lot of people write things down. And I write things down, too, and draw little arrows that don't really make any sense. But it helps me do something physically sometimes as well as just thinking about it.

+ +

JOËL: Have you ever tried to convert these pictures you see in your mind and actually draw them on paper?

+ +

EEBS: Occasionally. And for the most part, that usually takes the form of some kind of domain modeling, whether it's based on database tables or just domain objects. And sometimes I will try and draw them out and then specify the relationships between them like, oh, you know, this one model talks to this other model in this particular way. And I'll define a relationship between them, which helps me think about them and how they interact.

+ +

JOËL: I've found that even though for some things I can see it very vividly in my mind's eye, I struggle to then concretely translate that onto paper or digital paper if you will. It's almost like trying to, say, translate an emotion into words and that even though I feel like I see a visual picture, I can't reproduce it by drawing necessarily.

+ +

EEBS: It's interesting you brought up feeling because a lot of the times, I have this gut feeling about a mental model, like whether I think it is correct or not. And sometimes I have this uneasy feeling of, like, that doesn't feel right to me, but it's hard to articulate why. And I think sometimes that's when I have to pull out something physical, start making those relations, start connecting things.

+ +

And that's when I might uncover, like, oh, this feels odd because I have a circle here or a cycle or something. Or I've sort of represented the truth of something in two different places. Do you have any techniques for getting it out of your head and into something physical that you could share with someone else, maybe it's text or a picture?

+ +

JOËL: I think I do struggle with that conversion sometimes. Practice definitely helps. I think maybe there is a metaphor here between converting these, let's call them, pictures that I see in my mind's eye and then drawing diagrams with trying to take feelings and expressing them in words. In the same way that, maybe I might have some feelings, and then I want to journal how I feel, and I struggle to express that.

+ +

But finding a way to express that gives me a certain amount of precision and a more concrete thing. In the same way, these things that flash in front of my mind's eye, if I can take the time to put them on paper, they're now more real. They're more concrete. I think you can probe the edges, the ways that it kind of falls apart more easily.

+ +

EEBS: Yeah, that makes a lot of sense. There's a lot of value in writing that down and going through those details in a methodical way because oftentimes, you'll catch inconsistencies, or you'll find better ways to describe it. And being able to share your mental model with someone else is often...well, it can be really tricky.

+ +

And I think that's why it's important to go through and maybe find a common medium that you can share because I can't see into your brain. You can't see into mine. But if we can share our mental models, then hopefully, we have a better chance of agreeing on the solution or finding inconsistencies.

+ +

JOËL: Exactly. I think, in many ways, there are almost multiple layers of mental models and that you might have an abstraction or a metaphor for a concept that you're working with separate from the diagram. And then the diagram is yet another metaphor, but now we're going geometric to represent a broader idea.

+ +

EEBS: Yeah. Are there any other ways that you take that picture from your mind's eye besides written documents or conversations? Do you use any diagramming tools that specifically help with that? Or is it just kind of free-form?

+ +

JOËL: I do a mix. I am a big fan of draw.io, which allows you to just free-hand or pull shapes together, things like that. There are some more structured tools that I will use. I'll use Mermaid.js.

+ +

EEBS: Yeah, I've been using that a lot too.

+ +

JOËL: Yeah, that's great. I've been digging into more structured diagrams recently, particularly the idea of graphs, directed graphs. And those have interesting properties.

+ +

EEBS: Can you share a little more detail about what you mean?

+ +

JOËL: So a graph in the computer science sense is a bunch of nodes. They are typically represented as circles and then edges which are the connections between them. A directed graph is now there's an arrow pointing in a particular direction. A really interesting property that you can have with directed graphs is whether or not they include cycles. So can you only by following the arrows effectively create a loop? Or will the arrows always lead you to some kind of terminal node?

+ +

EEBS: Gotcha. Is that a directed acyclic graph?

+ +

JOËL: If there are no cycles, yes, it is a directed acyclic graph or DAG, as you'll often see it abbreviated.

+ +

EEBS: [laughs] How do you relate that graph to code? And what benefits do you get from expressing it that way?

+ +

JOËL: So this shows up in a lot of places. And I'd even say that thinking of certain aspects of my code as a graph and a potentially directed acyclic graph is itself a mental model or a metaphor that helps bring clarity to the way I think about things. So, for example, code, you know, you invoke some main function at some point to call the code, and then that's going to call out some other functions, which call out some other functions, and so on. You may have heard that referred to as a call graph. But that is a graph of calls.

+ +

There might be cycles in there for co-recursive functions and things like that. But that is one way you can then sift through and analyze how control flow or how logic flows through your application is through a function graph. You mentioned earlier the idea of objects and how they're connected to each other. That's an object graph.

+ +

EEBS: Right. Recently, I had to work through a state transition problem where a customer has some billing, and they can go through many different states, whether it's active, or canceled, or past due, those sorts of things. And so actually, I reached for Mermaid.js and built a graph of, okay, they start here in this empty state. And then they subscribe, which then they become active. They might cancel their subscription, which moves them to a different state.

+ +

And by listing out all the states and the transitions between them, it helped me to understand what methods I might need to define on which objects in order to allow those transitions to happen and what checks I might need to make before allowing those transitions depending on the state of the system.

+ +

JOËL: I'm hearing the keywords states and transitions. And that's making me think of finite-state machines. Are you drawing a finite-state machine graph or something a bit more free-handed?

+ +

EEBS: It's a bit more of free-handed. I don't think I've actually drawn out a state machine since college but just representing the different states as different boxes and the transitions that are possible from those states. I mean, I guess that kind of is a state machine in some way. So graphs are great visual approaches. Are there any non-visual approaches that you take?

+ +

JOËL: That's a great question because not all mental models have to be visual. I think the power of a mental model exists in a metaphor. And one that's kind of broad but that I've applied to a lot of different areas is the general idea of something being parallel or in series. I think I first came across this concept talking about electric circuits. And are we talking about two little light bulbs that are in parallel, and if the electricity to one is cut, the other one still lights up? Or are they chained together in series?

+ +

EEBS: Yeah, like my LEDs.

+ +

JOËL: Exactly, going back to Arduino, but it can also be applied to a bunch of other things. We can talk about code being in parallel or in series. We can talk about work being in parallel or in series. Interestingly, I took that mental model as a sort of quick shortcut when I was digging into some functional programming ideas. Monads and applicatives are the fancy terms here.

+ +

EEBS: Oh boy, I'm ready.

+ +

JOËL: In general, and there's a hefty asterisk here, I think of monads as being serial, so you're chaining something; one thing happens, then another. So you can think of, for example, chaining promises in JavaScript, promise one, then promise two, as opposed to applicatives which are parallel. So you might think of maybe zipping two lists or two arrays in Ruby. The two arrays, there are no dependencies between the two of them. They get processed side by side as you're traversing both of them together.

+ +

EEBS: Interesting. I've heard the term monad a lot, but I haven't heard the term applicative. Are there any other details you can share about them and what makes them different or how they might be seen in our code?

+ +

JOËL: I think that the key difference is that distinction in how they're processed. Applicatives are a way of combining two independent, let's call them data sources, and then you find a way to combine them together. So it could be two independent arrays, and you're zipping through them. It might be two independent HTTP requests, and they can both fire in parallel. But then you want to combine their outputs. So you say wait until both are successful and then combine their output.

+ +

EEBS: Oh, okay, gotcha.

+ +

JOËL: It could even be nullable values. So you say do this thing if both values are present. But you're not...the value of one or the fact that one is null or not is not dependent on whether the other one is null or not. They're independently null or not as opposed to something...Monads are, again, a different way of combining. You might call them data sources or operations. But in this case, there is a clear dependency one, and then its output influences the next one.

+ +

You might say check the value is null or present or not. And then, if it is present, take that value and then put it as the input of my next operation. And then, if it is null or not, do another thing. See, now you have a sort of chain.

+ +

EEBS: Where do you see these chains happening in code? Or is it everywhere?

+ +

JOËL: Once you know that pattern which, again, could be thought of as another mental model, you start seeing it everywhere. So promises in JavaScript chaining together that's effectively monads. Don't @ me, all the functional programming people.

+ +

EEBS: [laughs]

+ +

JOËL: I know that's not quite true. Anything dealing with multiple operations that could succeed or fail depending on, again, whether you're treating them as dependent or independent, that's probably going to look very similar to either monad or applicative.

+ +

EEBS: So the first thing that actually comes to mind here is things like background jobs. Using Sidekiq or Resque or other job processors, you can have a queue of jobs that need to be executed, and they might need to run in serial, or potentially you have multiple workers pulling from a single queue, and thus the work is happening in parallel. Is that a reasonable analogy?

+ +

JOËL: I think it's good for the serial versus parallel, but it's not necessarily a good analogy for understanding monads and applicatives.

+ +

EEBS: Gotcha.

+ +

JOËL: So with two workers, you can process a queue in parallel, and a bunch of things happen.

+ +

EEBS: But there's not necessarily anything that is bringing those two workers together to produce a single output.

+ +

JOËL: Yes. And there's no dependency between the tasks in the queue.

+ +

EEBS: Right, right, gotcha.

+ +

JOËL: So if you have a task that says execute this task and then only if this task succeeds, then do the second task, now you've created a dependency. And you couldn't process that in parallel because if task one, which has to be executed first, is executed by worker one, task two should not get processed unless task one is successful. You can't just say, oh, I've got another worker free. I haven't processed task two because it's waiting to know does task one succeed.

+ +

EEBS: Right. So an example in code would be a user creates a new order. And when they create a new order, we send them a confirmation email. That would be an example of that happening in serial or a monad-like thing. [chuckle]

+ +

JOËL: Yes, I found that thinking of things as serial or parallel is a good shortcut for thinking about monads and applicatives. I don't know that the reverse is necessarily true. They don't necessarily transfer one-to-one with each other. And maybe that's a danger of mental models, right? You find a mental model that describes a situation, and then you try to reverse it, and then you make false assumptions about the world.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: Another mental model that is not necessarily visual that I like actually comes from the video game community, and that's thinking of skill ceilings and skill floors. So in, I think, particularly the MOBA Community, that's a Multiplayer Online Battle Arena, they'll talk about characters as having a high skill floor or a low skill ceiling.

+ +

And generally, what that means, and again, the meaning varies a little bit by community, is that a character with a low-skill floor is an easily accessible character. They might not have a lot of skill shots, like, you press a button, and things happen around your character. You don't need to aim, things like that. A high skill ceiling means that there's a lot of room for you to grow, and as you get more skilled, you can get significantly better with that character.

+ +

EEBS: Gotcha. So the opportunity is greater with a higher skill ceiling.

+ +

JOËL: Correct. And depending on how the character is set up, you might have a very narrow range that could be in the low range where it has a low skill floor and a low skill ceiling, which means that the character is easy to learn. But once you've learned it, there's not really a lot you can do with it. It's a fairly basic character. So getting better at the game is not necessarily going to make you that much more impactful.

+ +

And then you could have one that's the opposite that is high both skill floor and skill ceiling where a character is very hard to learn. But once you learn it, that's kind of all there is to it. And then you might have one that has a large range somewhere; maybe it's easy to learn, but it's hard to master, or there's a lot of room for growth.

+ +

And so, taking this framework for analyzing characters and video games, I think we can apply that to technology in general. This could be language design. This could be just API design. And you might say, well, I want this to be very accessible. People can jump in very easily. You might say I want this to be very powerful and have a lot of high-end features that make your power users very happy and very productive.

+ +

EEBS: That's interesting. When you first were talking about it, I was actually less thinking about it from a user's perspective of what maybe they could do in the application but potentially from the standpoint of a developer writing the system itself.

+ +

One of the pieces I always come back to in software development is that change is inevitable. And so, making something easy to change often pays great benefits down the road. And so I wonder how that fits into this idea of a low skill ceiling or a high skill ceiling in terms of perhaps flexibility or being decoupled such that you can take one idea and easily extend it or easily get more from it than you originally set out to build.

+ +

JOËL: There's often a trade-off. So you make something easy to change. It's highly decoupled. But you maybe introduce more indirection to the system. So while it's easier to change one single piece, it's harder to understand the system as a whole.

+ +

EEBS: Yeah, that's true. And sometimes, you bake in assumptions that you make about the future, which turn out not to be true.

+ +

JOËL: [laughs] Yes, that is definitely something I'm guilty of.

+ +

EEBS: I think we all are.

+ +

JOËL: One thing that I find interesting is as you evolve the design of an architecture pattern, a system, a whole language, you might want to move one of those if I think of them like two independent sliders on a one-dimensional scale. So maybe you want to move the upper boundary a little bit and say I want a higher skill ceiling for this, but they don't actually move completely independently.

+ +

So introducing some advanced features might inadvertently also raise the skill floor. And conversely, making the language super accessible so that it has a low-skill floor, you might have to decide I will not introduce certain features.

+ +

EEBS: One thing I wanted to ask you about is, do you view different languages as having different skill floors and ceilings? And, you know, I love Ruby. I know you love Element. I've played with Element. It's been a great learning tool for me. How do you view those two languages in terms of skill ceilings and skill floors in terms of, I guess, what you can do with them?

+ +

JOËL: That's a great question. And I think you can definitely apply that to languages. Admittedly, I think you could probably start a lot of flame wars with that.

+ +

EEBS: [chuckles] Let's not do that.

+ +

JOËL: I wrote an article a while back where I applied that mental model to look at the F# programming language. And there was a debate in that community about certain features to add and whether they would allow advanced programming but potentially at the cost of accessibility to newer members of the community and how to balance those. And so I thought, hey, let's throw this video game metaphor at the problem and talk about it through that lens.

+ +

EEBS: That's really cool. Did you draw any conclusions, or was it as a way to start a conversation?

+ +

JOËL: It is a way to start a conversation. I don't think there is a single correct or best distribution of your skill, ceiling, and floor. It has to match the goals you set out for your project. Just like in games, people love to rank which characters are best and not. And sometimes you can show that, in general, this character is better.

+ +

But oftentimes, in a balanced game, you can talk about this character being easier to get started with or this character working very well if you're a pro. But the fact that you have a higher or lower skill ceiling or floor doesn't necessarily make the character better or worse.

+ +

EEBS: So, this conversation about differing mental models, I think I hadn't realized that there can be so many different types of mental models. And some things that I do in my thinking I haven't classified as a mental model. But now that you bring it up, I think one that I think about fairly often is this idea of two objects that are collaborators and reaching into the internals of one of those objects from the other object.

+ +

So A and B are two separate things. And if A reaches into B's bucket and messes with the state of B, I view that as sort of a bad practice. You're not really adhering to maybe the public API that that object is exposing. You're kind of reaching in and going around behind its back and changing some stuff that it may not expect.

+ +

JOËL: Would you refer to that maybe as tight coupling?

+ +

EEBS: Yeah, it's definitely tight coupling. It's not just tightly coupled; it's almost worse than that. It's almost like going behind somebody's back and making a change without them knowing. And so when I see that in code or when I write code that does that, I have this really intense desire to separate that and to say, no, no, you can't go in and update this record directly in the database. You have to send it a message and say, "Hey, I would like you to be aware of something," and then it goes and changes its own internal state as a response to that.

+ +

And so I have this very vivid sort of mental feeling of it being wrong, of it being like, I'm being sneaky, or I'm not being gracious to the person I'm interacting with as though I were one of these objects.

+ +

JOËL: That's fascinating. You've practically anthropomorphized these objects.

+ +

EEBS: I do. I view them as little people.

+ +

JOËL: You describe this interaction as going behind someone's back. That is the thing that I, a person, do to someone else. It's not a function making a direct call. And yet, it's such a strong...we use a social mental model to talk about objects and interactions.

+ +

EEBS: Yeah, I almost want them to be friends. And I think that applies to real-life relationships, right? If you have a nice dialogue back and forth, there's an understanding. There's commonality that you can find. But if I were to go do something behind your back without chatting with you about it first, you might not be so happy with me.

+ +

JOËL: I'd feel betrayed.

+ +

EEBS: Right.

+ +

JOËL: I feel like there's probably a really fun conference talk to be done about that. We often use that metaphor; I think when talking about objects sort of subconsciously but making it explicit and just being, hey, let's talk about these objects as if they were people. Why don't we want to do this? Because this one here is betraying the other object there. This one here is being impolite.

+ +

EEBS: We could have two people get on stage and talk to each other. And I might then go and reach in your pocket and pull out some change without you knowing, and you might be upset with me.

+ +

JOËL: That would be great. Get a little skit going up on stage. Or even if you're artistically inclined, you could probably draw some really fun little characters to illustrate this.

+ +

EEBS: That would be really cool. I, unfortunately, don't have the artistic talent to do that.

+ +

JOËL: Well, free conference talk idea to all listeners of the podcast. I expect to see this for RailsConf 2023, maybe.

+ +

EEBS: I'll be looking for it. So I've shared a mental model that I didn't really know was a mental model. Are there other mental models that you want to share that I may not be thinking of?

+ +

JOËL: Here's one that I've just come to realize recently that I'm actually quite excited about: when you think about the word refactoring, how would you describe that idea?

+ +

EEBS: Well, refactoring to me is changing the implementation without changing the behavior.

+ +

JOËL: Yes, I think that is the classical definition. You should be able to change the implementation of a method, and the tests without changing are still green after you've done that.

+ +

EEBS: I guess, mentally, I think about that as perhaps drawing a box around some of the objects that are floating in my mind's eye, rearranging how they exist within that box, and then the box dissolves. And the tests still pass, but the structure of the objects or the code has changed in my mind.

+ +

JOËL: I love that you immediately went to a visual approach there. And I think I have something similar, but I'm coming at it from a slightly more domain modeling perspective. So thinking maybe less from an individual method approach but looking at maybe a larger system, what you're trying to do is use code to describe some version of reality. So it might be a business process that you have. It might be trying to describe some aspect of your customer's life that you're trying to automate for them.

+ +

Oftentimes, this thing you're trying to describe in code terms is going to be a simplification because life has a ton of edge cases, and many of them we don't care about. So if we go with a visual metaphor here, you're trying to draw some kind of shape using only straight lines to approximate some weird curve.

+ +

And so, let's say you draw something with only four lines. It's really simple, how you have a diamond. That's the shape you're trying to create. And then you're going to fill it in with little other shapes that approximate a diamond. And those are your different models and functions and all the other components that we use to build software.

+ +

At some point, your understanding of the underlying reality might change. Maybe you need more precision, or maybe the actual feature requirements have changed. The thing you're trying to approximate with your code is not a diamond. Maybe you've added a few more sides to it. It's a pentagon. So we've gone from four sides to five. And the little components, and modules, and things that you have there approximate that diamond work.

+ +

They still mostly approximate your pentagon, but it's really clunky because the initial design was to approximate something else. They were really good for fitting in really tightly and being very loosely coupled to each other when we were trying to do a diamond, but then they don't work as well in the pentagon.

+ +

EEBS: So maybe some of the internal shapes need to change or adjust to fill the space that the pentagon has now created.

+ +

JOËL: To fill the space or maybe even just to fill it in a way that's less clunky. And so the idea here in this metaphor is that the reality we're targeting in software is always changing. And so the underlying reality changes, and so we're changing that shape that we're creating all the time.

+ +

But also, we're getting more precision as we decide; oh, we care about this edge case now. We didn't in version one, and so as part of that, we're constantly having to take the modules that maybe were very well designed initially but then restructure them to fit the new requirements because now there's a fourth object coming in, and it's kind of clunky with our current configuration.

+ +

EEBS: That's interesting. One of the first things that jumps to mind is that maybe there are better ways or worse ways to do that refactoring to fit that new shape. Do you think there's any truth to that in the sense that you might initially design a system that perfectly fits that diamond or very closely fits that diamond but then as it changes to a pentagon, do you need to simply add a new piece to fill in that empty space? Or do you need to restructure everything within the diamond now to fit the shape of the pentagon?

+ +

JOËL: Oftentimes, you do need to restructure. And I think there's this wonderful little phrase from; I believe it's Kent Beck that says, "Make the change easy, and then make the easy change."

+ +

EEBS: Yep.

+ +

JOËL: And so, to me, that makes the change easy is that initial restructuring that you need to do of those first shapes so that you can finally bring in the new one.

+ +

EEBS: Oh, that's a cool visual. I immediately can imagine the pieces in the pentagon moving around to make space for a new piece that you need to now bring in. And that movement of all those pieces can be really difficult.

+ +

Have you ever played that game where it's a square, and you're trying to get a ship out of a port, but there's a whole bunch of other ships, and you can only move them left and right and up and down? And you can do that. And that's what I'm picturing right now is moving shapes within that pentagon to then make space for either a new shape or to allow a shape to escape that is no longer relevant.

+ +

JOËL: I played a version of that that had cars, cars, and trucks.

+ +

EEBS: Gotcha. Yeah, I think I played that too.

+ +

JOËL: That would also be a fun conference talk, right? Like, start with that game as your initial metaphor. And then you use that as a way to talk about refactoring.

+ +

EEBS: That would be really cool.

+ +

JOËL: I would watch that talk. To anybody listening who wants to give that talk, I want to see you at RailsConf 2023.

+ +

EEBS: [laughs] Are we just a talk factory now?

+ +

[laughter]

+ +

JOËL: I love talk ideas. Maybe this should become a segment. Just have Eebs come in for five minutes once a month and give us a talk idea. It could even be fun to see a talk idea that multiple people implemented differently.

+ +

EEBS: That would be really cool, actually. I always get nervous about giving talks or being on podcasts like this one. I would love to be the person that gets to sit there and throw out random ideas and have other people fulfill my dreams.

+ +

JOËL: Well, thank you so much, Eebs, for joining us to talk about mental models. And to all of our listeners, I'd love to hear about what mental models you find are helpful, and so please share them with us. On Twitter, you can reach us at @_bikeshed.

+ +

EEBS: Thanks for having me, JOËL. This has been super fun.

+ +

JOËL: And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Mental models are metaphors that help us understand complex problems we work on. They can be a simplified roadmap over an infinite area of complexity.

+ +

How does one come up with mental models? How are they useful? Are they primarily a solo thing, or can they be used to communicate with the team? What happens when your model is inaccurate? Today, Joël is joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget, to discuss.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Eebs on Twitter
+You Need a Budget
+Skill floors and skill ceilings

+ +

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. And today, I'm joined by Eebs Kobeissi, a Developer and Dev Manager at You Need a Budget.

+ +

EEBS: Hi, Joël. It's really good to be here.

+ +

JOËL: And together, we're here to share a little bit about what we've learned along the way. So, Eebs, what's new in your world?

+ +

EEBS: Oh, a whole lot. I'm a new dad, so I'm getting to experience all those things. But in the developer world, I've recently picked up programming on an ESP32, which controls LED lights. And so I'm having fun lighting up my office.

+ +

JOËL: Is that like one of those little microboards, kind of like a Raspberry Pi?

+ +

EEBS: Yeah, exactly. It's a little board that's compatible with the Arduino IDE. And I literally only played with it last weekend, so it's still very new to me.

+ +

JOËL: Nice. Have you done any Arduino development or Raspberry Pi or anything like that before?

+ +

EEBS: No, I have a Raspberry Pi that I run like a DNS server on, but I haven't done any actual programming. I did make an LED blink, which is pretty cool.

+ +

JOËL: What kind of programming is required for a board like that?

+ +

EEBS: From my understanding, it's either in Python or C. Those are, I think, the two languages that you can program on it. I definitely do not know C. And so I'm just going through a bunch of tutorials and reading some sample code. But I think if I ever end up trying to implement something more complex, I'll probably switch over to Python because that's a little more familiar.

+ +

JOËL: So the coding feels fairly high level even though you're writing controller code for LEDs.

+ +

EEBS: I hope so. I'd love to be able to take advantage of whatever abstractions I can.

+ +

JOËL: Do you have any fun goals you're trying to do with this? Or is this just for the fun of trying a completely different environment than web development?

+ +

EEBS: No, it's actually rooted in something visual. So I have these shelves behind me that are in my webcam when I'm in meetings or whatever. And so I want to be able to put a light strip across these shelves and have some sort of visual thing in the background.

+ +

JOËL: Like LED mood ring?

+ +

EEBS: Yeah, kind of. My eventual goal would be that as I'm talking, a little equalizer display pops up behind me. I thought that would be pretty neat.

+ +

JOËL: That is amazing. That will give you all of the cred in the meetings.

+ +

EEBS: Right? I thought that'd be pretty cool. What have you been thinking about recently, Joël?

+ +

JOËL: I've been submitting to the RubyConf call for proposals which, as of the recording of this episode, has just closed this week. And like many people, I submitted on the last day.

+ +

EEBS: [laughs]

+ +

JOËL: And it was really fun trying to take some ideas that I'm excited about and then turn them into a proposal that is accessible to other people.

+ +

EEBS: Nice. Do you want to share a little bit about what the talk is, or is it under wraps for now?

+ +

JOËL: I don't know if anyone on the committee will listen to this before the review goes out. This might break the anonymity of the proposal.

+ +

EEBS: Oh, right, right.

+ +

JOËL: One thing I will share that's interesting is that there are topics that I'm excited about. It's like, oh, here are a bunch of cool things about something, some technical topic. But talks that are just ten cool things about X are not that great. And so I needed to find some sort of unifying idea that I could use to share that. And that generally is in the form of trying to find a story that I can tell. What unifies all of these things together? What tells a compelling story? Is there some metaphor I can lean into?

+ +

EEBS: Nice. I think that's a really powerful way of communicating something deeper is through telling something that people can relate to.

+ +

JOËL: One way that thinking about metaphors has been really impactful for me recently is the idea of mental models and how those can help us in development. I'm curious; we've thrown around the phrase a little bit you and I in past conversations; what does a mental model mean to you?

+ +

EEBS: I tend to be a visual thinker. And from talking to others, I've heard similar statements. So for me, a mental model is how I think about a particular domain or how I think about code flow or structure. And for me, it's usually either as two-dimensional objects or occasionally three-dimensional objects that I have floating in my visual space.

+ +

So, for example, if we had two classes that are collaborators in some way, I often think of them maybe as two rectangles that are side by side. And when they interact, there's some little amorphous blob from one of those rectangles that reaches out into the other one or passes a message from one to the other.

+ +

And I sort of have this idea of how many connections are there between these two physical things. Or, if I'm thinking about code flow and the path of execution that code might take, sometimes I visualize it as maybe a tree or potentially loops if there are such cases.

+ +

JOËL: So when you think of these concepts, just in general, you're seeing in your mind's eye squares and rectangles floating in the air.

+ +

EEBS: Yeah, pretty often. Sometimes it takes those shapes, and as I build up a mental model of some code, I'm usually adding new shapes into that picture I have in my mind. I tend to view things sort of top-down. So like, the start of code or the start of execution is usually at the top or maybe the far left or far right.

+ +

And as execution happens, I usually view that as moving in towards the middle and potentially going back out when a response is returned. If it's a web request, something like that, I view it as this sort of outside in. And there's a bunch of pieces in there that are all talking to each other.

+ +

JOËL: That's really cool. So not only is there a geometric aspect to it, but there's a spatial aspect to it as well.

+ +

EEBS: Yeah. And it's interesting, like, I haven't actually thought about it [laughs] in this level of detail before. But yeah, there certainly is a spatial aspect to it. And I have this idea in my mind of like things and domain objects kind of belong at the bottom, and they should have well-defined boundaries. But the pieces that are a little bit towards the outer edges may be a little more fuzzy and may have less definition around them.

+ +

JOËL: That's really interesting because I also have this sort of in my mind's eye see these things when I'm thinking about concepts like that. But I've talked to other people, and some people don't even have much of a mind's eye at all. They don't tend to visualize things in their mind in that way.

+ +

EEBS: Yeah, it's really interesting how different people approach this thinking about code. A lot of people write things down. And I write things down, too, and draw little arrows that don't really make any sense. But it helps me do something physically sometimes as well as just thinking about it.

+ +

JOËL: Have you ever tried to convert these pictures you see in your mind and actually draw them on paper?

+ +

EEBS: Occasionally. And for the most part, that usually takes the form of some kind of domain modeling, whether it's based on database tables or just domain objects. And sometimes I will try and draw them out and then specify the relationships between them like, oh, you know, this one model talks to this other model in this particular way. And I'll define a relationship between them, which helps me think about them and how they interact.

+ +

JOËL: I've found that even though for some things I can see it very vividly in my mind's eye, I struggle to then concretely translate that onto paper or digital paper if you will. It's almost like trying to, say, translate an emotion into words and that even though I feel like I see a visual picture, I can't reproduce it by drawing necessarily.

+ +

EEBS: It's interesting you brought up feeling because a lot of the times, I have this gut feeling about a mental model, like whether I think it is correct or not. And sometimes I have this uneasy feeling of, like, that doesn't feel right to me, but it's hard to articulate why. And I think sometimes that's when I have to pull out something physical, start making those relations, start connecting things.

+ +

And that's when I might uncover, like, oh, this feels odd because I have a circle here or a cycle or something. Or I've sort of represented the truth of something in two different places. Do you have any techniques for getting it out of your head and into something physical that you could share with someone else, maybe it's text or a picture?

+ +

JOËL: I think I do struggle with that conversion sometimes. Practice definitely helps. I think maybe there is a metaphor here between converting these, let's call them, pictures that I see in my mind's eye and then drawing diagrams with trying to take feelings and expressing them in words. In the same way that, maybe I might have some feelings, and then I want to journal how I feel, and I struggle to express that.

+ +

But finding a way to express that gives me a certain amount of precision and a more concrete thing. In the same way, these things that flash in front of my mind's eye, if I can take the time to put them on paper, they're now more real. They're more concrete. I think you can probe the edges, the ways that it kind of falls apart more easily.

+ +

EEBS: Yeah, that makes a lot of sense. There's a lot of value in writing that down and going through those details in a methodical way because oftentimes, you'll catch inconsistencies, or you'll find better ways to describe it. And being able to share your mental model with someone else is often...well, it can be really tricky.

+ +

And I think that's why it's important to go through and maybe find a common medium that you can share because I can't see into your brain. You can't see into mine. But if we can share our mental models, then hopefully, we have a better chance of agreeing on the solution or finding inconsistencies.

+ +

JOËL: Exactly. I think, in many ways, there are almost multiple layers of mental models and that you might have an abstraction or a metaphor for a concept that you're working with separate from the diagram. And then the diagram is yet another metaphor, but now we're going geometric to represent a broader idea.

+ +

EEBS: Yeah. Are there any other ways that you take that picture from your mind's eye besides written documents or conversations? Do you use any diagramming tools that specifically help with that? Or is it just kind of free-form?

+ +

JOËL: I do a mix. I am a big fan of draw.io, which allows you to just free-hand or pull shapes together, things like that. There are some more structured tools that I will use. I'll use Mermaid.js.

+ +

EEBS: Yeah, I've been using that a lot too.

+ +

JOËL: Yeah, that's great. I've been digging into more structured diagrams recently, particularly the idea of graphs, directed graphs. And those have interesting properties.

+ +

EEBS: Can you share a little more detail about what you mean?

+ +

JOËL: So a graph in the computer science sense is a bunch of nodes. They are typically represented as circles and then edges which are the connections between them. A directed graph is now there's an arrow pointing in a particular direction. A really interesting property that you can have with directed graphs is whether or not they include cycles. So can you only by following the arrows effectively create a loop? Or will the arrows always lead you to some kind of terminal node?

+ +

EEBS: Gotcha. Is that a directed acyclic graph?

+ +

JOËL: If there are no cycles, yes, it is a directed acyclic graph or DAG, as you'll often see it abbreviated.

+ +

EEBS: [laughs] How do you relate that graph to code? And what benefits do you get from expressing it that way?

+ +

JOËL: So this shows up in a lot of places. And I'd even say that thinking of certain aspects of my code as a graph and a potentially directed acyclic graph is itself a mental model or a metaphor that helps bring clarity to the way I think about things. So, for example, code, you know, you invoke some main function at some point to call the code, and then that's going to call out some other functions, which call out some other functions, and so on. You may have heard that referred to as a call graph. But that is a graph of calls.

+ +

There might be cycles in there for co-recursive functions and things like that. But that is one way you can then sift through and analyze how control flow or how logic flows through your application is through a function graph. You mentioned earlier the idea of objects and how they're connected to each other. That's an object graph.

+ +

EEBS: Right. Recently, I had to work through a state transition problem where a customer has some billing, and they can go through many different states, whether it's active, or canceled, or past due, those sorts of things. And so actually, I reached for Mermaid.js and built a graph of, okay, they start here in this empty state. And then they subscribe, which then they become active. They might cancel their subscription, which moves them to a different state.

+ +

And by listing out all the states and the transitions between them, it helped me to understand what methods I might need to define on which objects in order to allow those transitions to happen and what checks I might need to make before allowing those transitions depending on the state of the system.

+ +

JOËL: I'm hearing the keywords states and transitions. And that's making me think of finite-state machines. Are you drawing a finite-state machine graph or something a bit more free-handed?

+ +

EEBS: It's a bit more of free-handed. I don't think I've actually drawn out a state machine since college but just representing the different states as different boxes and the transitions that are possible from those states. I mean, I guess that kind of is a state machine in some way. So graphs are great visual approaches. Are there any non-visual approaches that you take?

+ +

JOËL: That's a great question because not all mental models have to be visual. I think the power of a mental model exists in a metaphor. And one that's kind of broad but that I've applied to a lot of different areas is the general idea of something being parallel or in series. I think I first came across this concept talking about electric circuits. And are we talking about two little light bulbs that are in parallel, and if the electricity to one is cut, the other one still lights up? Or are they chained together in series?

+ +

EEBS: Yeah, like my LEDs.

+ +

JOËL: Exactly, going back to Arduino, but it can also be applied to a bunch of other things. We can talk about code being in parallel or in series. We can talk about work being in parallel or in series. Interestingly, I took that mental model as a sort of quick shortcut when I was digging into some functional programming ideas. Monads and applicatives are the fancy terms here.

+ +

EEBS: Oh boy, I'm ready.

+ +

JOËL: In general, and there's a hefty asterisk here, I think of monads as being serial, so you're chaining something; one thing happens, then another. So you can think of, for example, chaining promises in JavaScript, promise one, then promise two, as opposed to applicatives which are parallel. So you might think of maybe zipping two lists or two arrays in Ruby. The two arrays, there are no dependencies between the two of them. They get processed side by side as you're traversing both of them together.

+ +

EEBS: Interesting. I've heard the term monad a lot, but I haven't heard the term applicative. Are there any other details you can share about them and what makes them different or how they might be seen in our code?

+ +

JOËL: I think that the key difference is that distinction in how they're processed. Applicatives are a way of combining two independent, let's call them data sources, and then you find a way to combine them together. So it could be two independent arrays, and you're zipping through them. It might be two independent HTTP requests, and they can both fire in parallel. But then you want to combine their outputs. So you say wait until both are successful and then combine their output.

+ +

EEBS: Oh, okay, gotcha.

+ +

JOËL: It could even be nullable values. So you say do this thing if both values are present. But you're not...the value of one or the fact that one is null or not is not dependent on whether the other one is null or not. They're independently null or not as opposed to something...Monads are, again, a different way of combining. You might call them data sources or operations. But in this case, there is a clear dependency one, and then its output influences the next one.

+ +

You might say check the value is null or present or not. And then, if it is present, take that value and then put it as the input of my next operation. And then, if it is null or not, do another thing. See, now you have a sort of chain.

+ +

EEBS: Where do you see these chains happening in code? Or is it everywhere?

+ +

JOËL: Once you know that pattern which, again, could be thought of as another mental model, you start seeing it everywhere. So promises in JavaScript chaining together that's effectively monads. Don't @ me, all the functional programming people.

+ +

EEBS: [laughs]

+ +

JOËL: I know that's not quite true. Anything dealing with multiple operations that could succeed or fail depending on, again, whether you're treating them as dependent or independent, that's probably going to look very similar to either monad or applicative.

+ +

EEBS: So the first thing that actually comes to mind here is things like background jobs. Using Sidekiq or Resque or other job processors, you can have a queue of jobs that need to be executed, and they might need to run in serial, or potentially you have multiple workers pulling from a single queue, and thus the work is happening in parallel. Is that a reasonable analogy?

+ +

JOËL: I think it's good for the serial versus parallel, but it's not necessarily a good analogy for understanding monads and applicatives.

+ +

EEBS: Gotcha.

+ +

JOËL: So with two workers, you can process a queue in parallel, and a bunch of things happen.

+ +

EEBS: But there's not necessarily anything that is bringing those two workers together to produce a single output.

+ +

JOËL: Yes. And there's no dependency between the tasks in the queue.

+ +

EEBS: Right, right, gotcha.

+ +

JOËL: So if you have a task that says execute this task and then only if this task succeeds, then do the second task, now you've created a dependency. And you couldn't process that in parallel because if task one, which has to be executed first, is executed by worker one, task two should not get processed unless task one is successful. You can't just say, oh, I've got another worker free. I haven't processed task two because it's waiting to know does task one succeed.

+ +

EEBS: Right. So an example in code would be a user creates a new order. And when they create a new order, we send them a confirmation email. That would be an example of that happening in serial or a monad-like thing. [chuckle]

+ +

JOËL: Yes, I found that thinking of things as serial or parallel is a good shortcut for thinking about monads and applicatives. I don't know that the reverse is necessarily true. They don't necessarily transfer one-to-one with each other. And maybe that's a danger of mental models, right? You find a mental model that describes a situation, and then you try to reverse it, and then you make false assumptions about the world.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: Another mental model that is not necessarily visual that I like actually comes from the video game community, and that's thinking of skill ceilings and skill floors. So in, I think, particularly the MOBA Community, that's a Multiplayer Online Battle Arena, they'll talk about characters as having a high skill floor or a low skill ceiling.

+ +

And generally, what that means, and again, the meaning varies a little bit by community, is that a character with a low-skill floor is an easily accessible character. They might not have a lot of skill shots, like, you press a button, and things happen around your character. You don't need to aim, things like that. A high skill ceiling means that there's a lot of room for you to grow, and as you get more skilled, you can get significantly better with that character.

+ +

EEBS: Gotcha. So the opportunity is greater with a higher skill ceiling.

+ +

JOËL: Correct. And depending on how the character is set up, you might have a very narrow range that could be in the low range where it has a low skill floor and a low skill ceiling, which means that the character is easy to learn. But once you've learned it, there's not really a lot you can do with it. It's a fairly basic character. So getting better at the game is not necessarily going to make you that much more impactful.

+ +

And then you could have one that's the opposite that is high both skill floor and skill ceiling where a character is very hard to learn. But once you learn it, that's kind of all there is to it. And then you might have one that has a large range somewhere; maybe it's easy to learn, but it's hard to master, or there's a lot of room for growth.

+ +

And so, taking this framework for analyzing characters and video games, I think we can apply that to technology in general. This could be language design. This could be just API design. And you might say, well, I want this to be very accessible. People can jump in very easily. You might say I want this to be very powerful and have a lot of high-end features that make your power users very happy and very productive.

+ +

EEBS: That's interesting. When you first were talking about it, I was actually less thinking about it from a user's perspective of what maybe they could do in the application but potentially from the standpoint of a developer writing the system itself.

+ +

One of the pieces I always come back to in software development is that change is inevitable. And so, making something easy to change often pays great benefits down the road. And so I wonder how that fits into this idea of a low skill ceiling or a high skill ceiling in terms of perhaps flexibility or being decoupled such that you can take one idea and easily extend it or easily get more from it than you originally set out to build.

+ +

JOËL: There's often a trade-off. So you make something easy to change. It's highly decoupled. But you maybe introduce more indirection to the system. So while it's easier to change one single piece, it's harder to understand the system as a whole.

+ +

EEBS: Yeah, that's true. And sometimes, you bake in assumptions that you make about the future, which turn out not to be true.

+ +

JOËL: [laughs] Yes, that is definitely something I'm guilty of.

+ +

EEBS: I think we all are.

+ +

JOËL: One thing that I find interesting is as you evolve the design of an architecture pattern, a system, a whole language, you might want to move one of those if I think of them like two independent sliders on a one-dimensional scale. So maybe you want to move the upper boundary a little bit and say I want a higher skill ceiling for this, but they don't actually move completely independently.

+ +

So introducing some advanced features might inadvertently also raise the skill floor. And conversely, making the language super accessible so that it has a low-skill floor, you might have to decide I will not introduce certain features.

+ +

EEBS: One thing I wanted to ask you about is, do you view different languages as having different skill floors and ceilings? And, you know, I love Ruby. I know you love Element. I've played with Element. It's been a great learning tool for me. How do you view those two languages in terms of skill ceilings and skill floors in terms of, I guess, what you can do with them?

+ +

JOËL: That's a great question. And I think you can definitely apply that to languages. Admittedly, I think you could probably start a lot of flame wars with that.

+ +

EEBS: [chuckles] Let's not do that.

+ +

JOËL: I wrote an article a while back where I applied that mental model to look at the F# programming language. And there was a debate in that community about certain features to add and whether they would allow advanced programming but potentially at the cost of accessibility to newer members of the community and how to balance those. And so I thought, hey, let's throw this video game metaphor at the problem and talk about it through that lens.

+ +

EEBS: That's really cool. Did you draw any conclusions, or was it as a way to start a conversation?

+ +

JOËL: It is a way to start a conversation. I don't think there is a single correct or best distribution of your skill, ceiling, and floor. It has to match the goals you set out for your project. Just like in games, people love to rank which characters are best and not. And sometimes you can show that, in general, this character is better.

+ +

But oftentimes, in a balanced game, you can talk about this character being easier to get started with or this character working very well if you're a pro. But the fact that you have a higher or lower skill ceiling or floor doesn't necessarily make the character better or worse.

+ +

EEBS: So, this conversation about differing mental models, I think I hadn't realized that there can be so many different types of mental models. And some things that I do in my thinking I haven't classified as a mental model. But now that you bring it up, I think one that I think about fairly often is this idea of two objects that are collaborators and reaching into the internals of one of those objects from the other object.

+ +

So A and B are two separate things. And if A reaches into B's bucket and messes with the state of B, I view that as sort of a bad practice. You're not really adhering to maybe the public API that that object is exposing. You're kind of reaching in and going around behind its back and changing some stuff that it may not expect.

+ +

JOËL: Would you refer to that maybe as tight coupling?

+ +

EEBS: Yeah, it's definitely tight coupling. It's not just tightly coupled; it's almost worse than that. It's almost like going behind somebody's back and making a change without them knowing. And so when I see that in code or when I write code that does that, I have this really intense desire to separate that and to say, no, no, you can't go in and update this record directly in the database. You have to send it a message and say, "Hey, I would like you to be aware of something," and then it goes and changes its own internal state as a response to that.

+ +

And so I have this very vivid sort of mental feeling of it being wrong, of it being like, I'm being sneaky, or I'm not being gracious to the person I'm interacting with as though I were one of these objects.

+ +

JOËL: That's fascinating. You've practically anthropomorphized these objects.

+ +

EEBS: I do. I view them as little people.

+ +

JOËL: You describe this interaction as going behind someone's back. That is the thing that I, a person, do to someone else. It's not a function making a direct call. And yet, it's such a strong...we use a social mental model to talk about objects and interactions.

+ +

EEBS: Yeah, I almost want them to be friends. And I think that applies to real-life relationships, right? If you have a nice dialogue back and forth, there's an understanding. There's commonality that you can find. But if I were to go do something behind your back without chatting with you about it first, you might not be so happy with me.

+ +

JOËL: I'd feel betrayed.

+ +

EEBS: Right.

+ +

JOËL: I feel like there's probably a really fun conference talk to be done about that. We often use that metaphor; I think when talking about objects sort of subconsciously but making it explicit and just being, hey, let's talk about these objects as if they were people. Why don't we want to do this? Because this one here is betraying the other object there. This one here is being impolite.

+ +

EEBS: We could have two people get on stage and talk to each other. And I might then go and reach in your pocket and pull out some change without you knowing, and you might be upset with me.

+ +

JOËL: That would be great. Get a little skit going up on stage. Or even if you're artistically inclined, you could probably draw some really fun little characters to illustrate this.

+ +

EEBS: That would be really cool. I, unfortunately, don't have the artistic talent to do that.

+ +

JOËL: Well, free conference talk idea to all listeners of the podcast. I expect to see this for RailsConf 2023, maybe.

+ +

EEBS: I'll be looking for it. So I've shared a mental model that I didn't really know was a mental model. Are there other mental models that you want to share that I may not be thinking of?

+ +

JOËL: Here's one that I've just come to realize recently that I'm actually quite excited about: when you think about the word refactoring, how would you describe that idea?

+ +

EEBS: Well, refactoring to me is changing the implementation without changing the behavior.

+ +

JOËL: Yes, I think that is the classical definition. You should be able to change the implementation of a method, and the tests without changing are still green after you've done that.

+ +

EEBS: I guess, mentally, I think about that as perhaps drawing a box around some of the objects that are floating in my mind's eye, rearranging how they exist within that box, and then the box dissolves. And the tests still pass, but the structure of the objects or the code has changed in my mind.

+ +

JOËL: I love that you immediately went to a visual approach there. And I think I have something similar, but I'm coming at it from a slightly more domain modeling perspective. So thinking maybe less from an individual method approach but looking at maybe a larger system, what you're trying to do is use code to describe some version of reality. So it might be a business process that you have. It might be trying to describe some aspect of your customer's life that you're trying to automate for them.

+ +

Oftentimes, this thing you're trying to describe in code terms is going to be a simplification because life has a ton of edge cases, and many of them we don't care about. So if we go with a visual metaphor here, you're trying to draw some kind of shape using only straight lines to approximate some weird curve.

+ +

And so, let's say you draw something with only four lines. It's really simple, how you have a diamond. That's the shape you're trying to create. And then you're going to fill it in with little other shapes that approximate a diamond. And those are your different models and functions and all the other components that we use to build software.

+ +

At some point, your understanding of the underlying reality might change. Maybe you need more precision, or maybe the actual feature requirements have changed. The thing you're trying to approximate with your code is not a diamond. Maybe you've added a few more sides to it. It's a pentagon. So we've gone from four sides to five. And the little components, and modules, and things that you have there approximate that diamond work.

+ +

They still mostly approximate your pentagon, but it's really clunky because the initial design was to approximate something else. They were really good for fitting in really tightly and being very loosely coupled to each other when we were trying to do a diamond, but then they don't work as well in the pentagon.

+ +

EEBS: So maybe some of the internal shapes need to change or adjust to fill the space that the pentagon has now created.

+ +

JOËL: To fill the space or maybe even just to fill it in a way that's less clunky. And so the idea here in this metaphor is that the reality we're targeting in software is always changing. And so the underlying reality changes, and so we're changing that shape that we're creating all the time.

+ +

But also, we're getting more precision as we decide; oh, we care about this edge case now. We didn't in version one, and so as part of that, we're constantly having to take the modules that maybe were very well designed initially but then restructure them to fit the new requirements because now there's a fourth object coming in, and it's kind of clunky with our current configuration.

+ +

EEBS: That's interesting. One of the first things that jumps to mind is that maybe there are better ways or worse ways to do that refactoring to fit that new shape. Do you think there's any truth to that in the sense that you might initially design a system that perfectly fits that diamond or very closely fits that diamond but then as it changes to a pentagon, do you need to simply add a new piece to fill in that empty space? Or do you need to restructure everything within the diamond now to fit the shape of the pentagon?

+ +

JOËL: Oftentimes, you do need to restructure. And I think there's this wonderful little phrase from; I believe it's Kent Beck that says, "Make the change easy, and then make the easy change."

+ +

EEBS: Yep.

+ +

JOËL: And so, to me, that makes the change easy is that initial restructuring that you need to do of those first shapes so that you can finally bring in the new one.

+ +

EEBS: Oh, that's a cool visual. I immediately can imagine the pieces in the pentagon moving around to make space for a new piece that you need to now bring in. And that movement of all those pieces can be really difficult.

+ +

Have you ever played that game where it's a square, and you're trying to get a ship out of a port, but there's a whole bunch of other ships, and you can only move them left and right and up and down? And you can do that. And that's what I'm picturing right now is moving shapes within that pentagon to then make space for either a new shape or to allow a shape to escape that is no longer relevant.

+ +

JOËL: I played a version of that that had cars, cars, and trucks.

+ +

EEBS: Gotcha. Yeah, I think I played that too.

+ +

JOËL: That would also be a fun conference talk, right? Like, start with that game as your initial metaphor. And then you use that as a way to talk about refactoring.

+ +

EEBS: That would be really cool.

+ +

JOËL: I would watch that talk. To anybody listening who wants to give that talk, I want to see you at RailsConf 2023.

+ +

EEBS: [laughs] Are we just a talk factory now?

+ +

[laughter]

+ +

JOËL: I love talk ideas. Maybe this should become a segment. Just have Eebs come in for five minutes once a month and give us a talk idea. It could even be fun to see a talk idea that multiple people implemented differently.

+ +

EEBS: That would be really cool, actually. I always get nervous about giving talks or being on podcasts like this one. I would love to be the person that gets to sit there and throw out random ideas and have other people fulfill my dreams.

+ +

JOËL: Well, thank you so much, Eebs, for joining us to talk about mental models. And to all of our listeners, I'd love to hear about what mental models you find are helpful, and so please share them with us. On Twitter, you can reach us at @_bikeshed.

+ +

EEBS: Thanks for having me, JOËL. This has been super fun.

+ +

JOËL: And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email.

+ +

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+nxlnnKEA + + ]]> + + Joël Quenneville + + + 352: Case Expressions + https://bikeshed.thoughtbot.com/352 + 1ca030ee-70ef-4992-b60b-e12d35b9792f + Tue, 30 Aug 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + As developers, we care a lot about code quality. How do we know how good is good enough? When do we stop improving code? Alternatively, when working on code that's really bad, how much do you improve it before calling it a day? thoughtbot's Stephanie Minn joins Joël to chat about this and case expressions: We recently discussed these as part of thoughtbot's RubyScience reading group. Are case expressions bad? Are they equivalent to multi-way conditionals? When do you use polymorphism? + 32:23 + no + + + As developers, we care a lot about code quality. How do we know how good is good enough? When do we stop improving code? Alternatively, when working on code that's really bad, how much do you improve it before calling it a day? thoughtbot's Stephanie Minn joins Joël to chat about this and case expressions: We recently discussed these as part of thoughtbot's RubyScience reading group. Are case expressions bad? Are they equivalent to multi-way conditionals? When do you use polymorphism? +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +RubyConf 2022 (https://rubyconf.org/) +RubyConf Mini (https://www.rubyconfmini.com/) +Stephanie's talk at RubyConf 2021 (https://www.youtube.com/watch?v=m0dC5RmxcFk) +WNB.rb (https://www.wnb-rb.dev/) +Joël's RailsConf 2022 talk (https://www.youtube.com/watch?v=LOlG4kqfwcg) +Ruby Science (https://books.thoughtbot.com/books/ruby-science.html) +older episode on wizards (https://www.bikeshed.fm/295) +TCR (https://www.honeybadger.io/blog/ruby-tcr-test-commit-revert/) +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. And we're here to share a little bit about what we've learned along the way. Today, I'm joined by a fellow thoughtboter, Stephanie Minn. +STEPHANIE: Hi, Joël. +JOËL: Welcome to the show. +STEPHANIE: Thanks. Happy to be here. +JOËL: Stephanie, what's new in your world? +STEPHANIE: Thanks for asking. I've been working on writing a CFP for RubyConf, which you have been plugging internally at thoughtbot. I wasn't really sure if I wanted to do it, and then I found out about RubyConf Mini, which is happening as an alternative to the main conference in Houston. And that got me really excited to have some more options and just got me thinking about what I might have sitting on the back-burner that I might want to give a talk about. +JOËL: That's really exciting. I'm curious, what is your process for coming up with an idea for a talk? +STEPHANIE: I think they come in seasons, ideas, for me, so not even necessarily when it's conference time. But if something has been sticking in my brain for a really long time, especially as it relates to processes on teams that I'm on or my day-to-day workflow, and it's something that I keep coming back to and trying to figure out what it is about it that my brain wants to work through a process, that usually tips me off that this might be something that other people are thinking about or working through. +In this case, I am planning to write a CFP about pair programming. And yeah, it's something that I've been thinking about doing for a while, and it seems kind of an evergreen topic. So I thought I would pull it out for this conference. And if it doesn't end up getting accepted, I can always resubmit again in the future. +JOËL: I love that. So it sounds like you have a note or maybe an actual written notepad somewhere where you just, over the course of the year, build up ideas, and then you take a look at that when conference time comes around. +STEPHANIE: Yeah, that's about it. I have just a very long-running note of half-formed thoughts. And then, when I give myself time to really reflect on how things have been going at work, I usually revisit it, and if any of them still resonate or stand out to me, I will go through and try to see if there's any content to come out of that. What about you? I know you are an extensive note-taker and ideas blogger. +JOËL: I have to say I really like your approach of gathering ideas throughout the year. I've worked with many people who would love to give a talk at a conference as a professional goal but then get stuck in the I don't have any ideas. I don't know what I would talk about. And most people have a thing they could talk about. They just don't know it. +And it sounds like you've done a really great job of gathering this info throughout the year so that when the time does come, you don't just freeze. You're like, no, here are the 10-20 things that I experienced or that I am an expert in or that I would love to share. And maybe there are two or three in there that would be very well-fitted for the conference you're looking at. So I love that idea. I have not done that myself personally, but maybe I should start doing that. +STEPHANIE: What about you, Joël? What's up in your world? +JOËL: So I've also been thinking a lot about RubyConf coming up, working on a few ideas for myself. And then, there are a few people that have reached out to me to help them craft ideas or get a little bit of feedback on their proposal. So I've been doing a lot of proposal reviews as well. +STEPHANIE: What do you enjoy about reviewing other people's proposals? +JOËL: I think for many people speaking at a conference is a really big, ambitious professional goal, and so helping people achieve that is really fulfilling for me. Some people might feel almost inadequate or unprepared. But because I know them, I know they've got good things to share. +And so it's almost seeing the greatness in them that they don't quite see yet or that they don't feel confident about. And so being able to see that in their proposal and say, "Oh, there’s a core of a great idea right here, tweak it a little bit, and that'll give you a slightly better chance with the committee and help you towards that path of being on stage for the first time," is really exciting. +STEPHANIE: I spoke at RubyConf last year, in 2021, virtually. And I remember that was my first time speaking at a conference. And I was worried that my talk was not super hardcore, technical enough. But my goal for my talk was to aim it towards other developers like me who are maybe mid-level and wanting to reach this whole audience of people who are attending these conferences to learn and to level up who aren't necessarily super senior experienced developers. +And it was a really great experience. People seemed to really resonate with that. So I really encourage folks to speak about things that are resonating with them at whatever point in their careers because there are so many people out there who are probably in the same boat and want to hear what you have to say. +JOËL: Absolutely. I'm curious, now that you have experienced the full cycle at least once, from ideas to crafting a submission, to getting accepted, preparing a talk, delivering the talk, and then recovering from that, what are maybe some lessons learned or some things you weren't expecting the first time you went into that that now you do know going into another cycle? +STEPHANIE: Yeah, the power of community; I had a lot of support from WNB.rb, a woman and non-binary Ruby community. We crafted our CFPs together and then practiced our talks together and had a working group that met every couple of weeks to give feedback on our talks as we were working on them. And it was really awesome to have that accountability, to have that support, people to tell you that your talk is good and give you a thumbs-up. +And I really want to continue investing in my community that way. And I really appreciate you asking this question because I guess I do have things I've learned and would want to share that with other people in my community, and yeah, just continue to encourage folks who may not have been traditionally encouraged to speak at conferences. +JOËL: Community is so powerful. Even though I've spoken at multiple conferences, I still get nervous about my talks. I have a lot of self-doubt about whether my topic is good, whether I'm sharing it in a way that's going to be impactful. And I had a magical experience at RailsConf this year where a group of us were at a hotel lobby practicing our talks the night before. And I was just still so unsure about my talk. +And the feedback that I got there gave me a huge boost of confidence that I was able to ride into the next day and give a talk that I think turned out rather well. But honestly, that was my favorite moment of the conference was 11:30 p.m., a group of people in the hotel lobby taking turns practicing their talks. +STEPHANIE: Yeah, I love that. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: One thing we've been doing recently at thoughtbot is every other week book club discussion, and we've been looking through the book Ruby Science published by thoughtbot. Every week, we'll have someone who is a facilitator, who has done the reading and has prepared some questions for the group. And you recently facilitated a session on the topic of CASE expressions and why they might be a code smell. That sounds like a really controversial statement. How did you approach that topic? +STEPHANIE: It's funny because I was looking at the upcoming chapters to pick a topic to facilitate for this book club, and CASE statements stood out to me because I was like, oh, I know what that is; that will be easy. [laughs] But it turned out to be a bit meatier than I thought it was going to be. I'd say that I didn't really consider them a code smell until I read the chapter of Ruby Science talking about them. So I was a bit surprised because they seem so common, which is probably also why I thought it would be an easy topic. +JOËL: Would you say that reading the book or that particular chapter changed your mind? +STEPHANIE: I think it did only because I hadn't necessarily given them a second thought or thought of them more deeply in that way. I think that, at least in my experience, you encounter CASE expressions pretty early in your career, and you think they're a cool tool for making your conditionals look a bit nicer. +And it takes probably a bit more experience, a little bit more pain using them or trying to extend them that you start to have a bit of a more higher level awareness of what might be problematic about a CASE expression. But the book club that I facilitated, we had a really engaging discussion where most folks agreed that it was a code smell but also said that it depends. +JOËL: Classic consultants. +STEPHANIE: Truly. One thing that someone said that was a really nice takeaway for me was that CASE expressions get a bad rap in object-oriented languages because there are typically other tools or options you can reach for that might be preferred. And someone else said that it's probably a sign that you might be doing too much in the method. +JOËL: Hmm. You mentioned that there are some tools and things that might be preferred over CASE expressions. What are the common alternatives that people say you should use instead of a CASE expression? +STEPHANIE: I think one simple solution that we discussed in the book club for more straightforward cases would be a hash lookup to use instead of checking for equality via CASE statement. Another solution we talked about was polymorphism, which I think might refer back to the idea of having a bit of a higher level understanding of abstractions in the codebase and what things might look like in the future, especially when you might not have too many conditionals yet in your CASE expression. +Another thing that really stuck out to me in our book club discussion was another thoughtboter mentioned Sandi Metz’s 99 Bottles of OOP. And in that initial solution, she presents a CASE statement as the perfectly fine solution for now. And I thought that was really interesting because, in some cases, that might be all we know about the problem, and that is perfectly fine. What do you think about that? +JOËL: I love the idea of starting simple. Don't try to start with abstraction, especially if you're doing test-driven development. You have a test, make it go green, use the simplest thing, use duplication, use all the dirty tricks. And then from there, now that you know I have a test that was red and this code makes it go green, now the question isn't how do I solve the problem? It's how do I improve the solution? So we've kind of separated those two steps out, and I really like that. +STEPHANIE: Yeah, I remember you mentioned that you had refactored something into using a CASE statement. And I'm curious if you want to share more about that. +JOËL: Oh boy, this was a "fun" problem. Fun is in air quotes, by the way. It was a multi-step form, AKA a wizard in a Rails app, where every step submitted to the same controller, and the controller was a huge mess. It had to handle submissions from four or five different forms, some of which shared fields. +And it was this huge, deeply nested conditional thing that checked if this field is present in params, that probably means we're on step three, except if this other field is also present, then it probably means we're on step four. But if this Boolean flag in the database is set to false, we might be on a variation of step three. And because there was branching, potentially, it was an absolute mess. By looking at the code, you could never know what step of the processing you were on. +What I did is instead of all of these nested if else conditions, I wrote a flat CASE expression that just said, if step one, do step one logic or process step one form. If step two, process step two form and so on. So it was nice and flat. I was able to reuse some parts of the work across by making private methods or other objects, things like that. +But you could easily tell in any part of the code what step you were processing. Which means if you get a new feature from the client that says, "Can you modify the behavior on step four?" Now you actually know where to go to. You go to this controller; you find the big CASE expression. You find the branch that says, "If step four," and then you drill down from there. +STEPHANIE: So after refactoring that into a flat structure, did you find the code more readable? Did other folks on the project think so too? +JOËL: Yes, it was unanimously loved because this is the part of the code that everybody feared to touch. It was the most awful, gnarliest code. And a few of us had touched it, and so if you did the git blame, our names would show up, which meant that anytime anybody got stuck in that code, they would reach out to us and say, "Hey, you're the last one who touched it. Can you fix this for me?" And it was a big game of not it. Cleaning it up made this code accessible to everybody on the team. +STEPHANIE: And why do you think a CASE statement was the right solution in this particular case? +JOËL: I think if it's a multi-step form that maybe had seven steps in it, you clearly have seven branches that you're working with. And so hiding that behind nested conditions where you try to reuse each other's branches just muddied the waters. We have a seven-way branching path; let's be honest about it upfront and do a seven-way CASE expression. +STEPHANIE: One thing that we didn't really talk about as much in our book club discussion was that CASE statements can be quite readable, especially for newer developers. And even though we all did think it was a bit of a code smell, I recently encountered on my client project in a code review someone saying that they preferred a CASE statement in that situation because it was easier for them to grok. I think that's a benefit worth considering before trying to do something fancier in some cases. And I'm curious what you think about that. +JOËL: I strongly agree that a CASE expression is a great place to start, especially when you have actually more than two branches. Your logic could go one of n ways. I generally like to branch earlier than later in a lot of code. It's better in my mind to have a seven-way branch at the top of your decision tree and then just straight lines down than this constantly looping back and branching again and looping back, trying to force everything down a single path when it really doesn't want to be. +STEPHANIE: So, in this case, did you know that you had those seven branching paths upfront, or did you have to tease that out? +JOËL: I did not know from the code. Honestly, it would be very difficult to infer that from the code. But from the product, I knew this is a multi-step form with seven steps. And so I knew what the branches were from the product description. But no, it was almost impossible to infer that from the code. +Long-time listeners of The Bike Shed may remember an older episode where Steph and Chris discussed multi-step forms and how best to approach them in Rails and also in JavaScript. And one thing that did come up is that an ideal way to work with a multi-step form in Rails is to have every step be its own controller. So you have a view, it submits to a controller, which renders another view or redirects to another view which submits to another controller. And that is the direction that we went with this multi-step form eventually. +Once the single controller had a big CASE expression in it, we slowly started moving each branch out to its own controller. And now we had the step one controller, the step two controller, the step three controller, and so on. And I think that was probably the best solution in the end. But we had to go through the CASE expression just to know what was safe to move out. +Interestingly, this refactor is effectively replacing a conditional with polymorphism because all of our controllers are controller objects. They respond to the same interface. And so this gets classic refactor that Ruby Science suggests, which is what we did and kind of what Steph and Chris recommended if you had the luxury of starting from scratch all those episodes ago. +STEPHANIE: Nice, I'm glad it turned out that way and was a lot more manageable. +JOËL: It's really interesting when you're working with a situation like that where you've got really messy code, and you can make some improvements. And it's like, how far do you go? Especially because there's usually a backlog of new features that the customer wants you to implement. +So I'm curious for you, Stephanie, how do you know when you've gone far enough in improving code, either in a refactor step for your own code for a feature you're writing or maybe you're trying to take a break and say I'm going to take a little bit of time today to improve this area of the code. How do you know how good is good enough? +STEPHANIE: That's an interesting question. I think I encounter that in a couple of ways, either in my own work when I am tasked with a feature, and I start getting into the code, and it stresses me out and leaves me a bit confused and not sure where to go to work on my feature. That is usually a signal that I might need to pay some attention first and make the change easy and then making the easy change. +The other common thing that I have experienced on teams is we collectively feel the pain of an area of the codebase. And maybe we talk about it at a developer meeting, and all agree that, yeah, we really want to give this part of the code some love and add it to the backlog. But it's tough in that case because, like you said, there are a lot of new features that stakeholders want. And we as developers want to be over here taking care of our little codebase [laughs], making sure that it is healthy and it feels good to work with. +JOËL: I feel like I don't just want my codebase healthy; I want it pristine. +STEPHANIE: Ooh, pristine. What does that mean to you? +JOËL: I want it perfect, nice, and shiny. And, of course, it's never that, which is why it's always tempting to toss out the old code and start over and do it right this time. That's not a good thing. You have to be able to live with the messiness of everyday life and the fact that, okay, here's an idea. I think if your codebase is perfect, you've put too much work into it. You've gone too far, and you're beyond that; when is good enough good enough? +STEPHANIE: Whoa, that's a big statement. +JOËL: [laughs] Feel free to disagree with me here. +STEPHANIE: I guess I'm curious what perfect is in this case. +JOËL: I think it's subjective for the developers who are writing it. But oftentimes, the ones who are looking for perfection go way too far in their quest for that. +STEPHANIE: Way too far at the expense of things like business value or other things? +JOËL: I think in two ways; one, you probably ended up overengineering things to try to make it so perfect. Your design needs to have some amount of flex in it for the unknown. It's okay to have some rough corners because it's going to change. And you're going to have to redo that corner next week anyway. So you need to not go all the way in making everything absolutely perfect. +The other thing is that if you are putting in the effort to make everything perfect, at some point, you hit diminishing returns. And that's not worth your time from a business perspective or even on a personal project where you're just trying to ship things. At some point, you need to make actual progress. +STEPHANIE: I'm curious if you mainly hold yourself to those very high standards or if you also think about that when reviewing other people's code. +JOËL: So I mentioned earlier that I want my code to be pristine. I want to be clear, that's a bad thing. I do not actually hold myself to that standard. And I try not to hold other people to that standard, either. It's sort of tempering idealism with pragmatism. So being able to say, look, can we cut scope and focus on just one thing? Or does this fulfill the need that we have? And will it hurt us if we leave it like this and come back to it later? Or that question I asked you at the beginning, is this good enough? And maybe we can come back to it eventually. +STEPHANIE: I really struggle with that question sometimes because, in some ways, people talk about software as a craft. And if we were building it in a vacuum, we could fine-tune and hone it until it's this beautiful, perfect, pristine thing. But because we write software for real things in the real world, we are constrained by the needs of our users, or the business, or just the purpose of building software is for folks to use it. And in that case, part of the job is evaluating trade-offs and deciding when is good enough. +But sometimes, when I'm by myself working or coding for a little while, I do get sucked into wanting to make this the best that it could be just for my own personal fulfillment and joy. And I have to pull myself out of it sometimes and take a step back and be like, is this good enough for now, good enough for other people to be able to understand, work with in the future? And sometimes, it also requires getting other people's input too. +JOËL: That's really valuable. +STEPHANIE: Yeah, the worst thing that could happen is squirreling away with your code, and then you emerge with something that was totally not what was asked for. [laughs] +JOËL: Especially on a work project. On a personal project, it's often good to know why you're doing a thing. And so maybe you want to see how far you can get away with pushing a particular metric, whether it's you want to go extreme on the decoupling or 100% TDD, or maybe you want to try something like test && commit || revert which is a development methodology. And those are all great as learning experiments, and then you go as deep as you want. +I'm going to make another hot take here, and again, feel free to tell me I'm wrong. I'm going to say that on your own personal projects, if you pursue perfection, even when it's not for work, pursuing perfection on personal projects dooms them to join the others on the pile of uncompleted projects on your GitHub. +STEPHANIE: That is an interesting take. I think it depends on the goal of your personal project because I personally like to have my projects be a bit of a sandbox, and I have no expectations that they will end up being anything that other people would necessarily look at, even though I guess they just end up public on my GitHub and are just sitting there in a weird, unfinished state. +But yeah, I like to use them as an opportunity to, like you said, practice those concepts that I am really excited to explore but might not necessarily have the opportunity to on whatever client project I'm currently working on. And sometimes, I end up just scrapping it, but the exercise itself was valuable for me. I'm curious, though, what types of personal projects you have that lead you to have that opinion. +JOËL: I think the way I use personal projects is very similar to you in that they're generally for my own personal growth and entertainment. It's about the journey, not the destination. So I generally have no intention of making this a thing that other people will use. It's typically a way to try out a technique, or a concept, or an idea. And so, for those, going really far on a performance or quality metric can be the goal. And that's completely okay with the knowledge that I probably will not complete or ship this project. +I've done a few others where I've done the opposite. I've joined Game Jam events where you typically have a hard deadline. This could be a longer one, like maybe a month or as short as a day or a weekend, and you have to build and ship something within that deadline. And then you have to really make some pragmatic choices. +STEPHANIE: Yeah, that sounds like a lot of pressure. I don't know if I would necessarily thrive in that kind of environment. I really like to spend a lot of time thinking about my code and looking over it again, sometimes to the point where I might be a little bit too precious about it. +I was reflecting on this recently, and I thought about back when I was earlier in my career and didn't have any idea of what clean or good code was or looked like. And I would just write the code that would make my future work and just put it up for review. And I was very blissfully naive, I think, at that point in my career where I wasn't self-conscious about it in any way. +And I think I'm trying to find a good middle ground between being comfortable with whatever comes out when I do some work or write some code while also having more knowledge and experience being able to revisit it and give it a deeper look after some space and feeling good about it without spending too much precious time on it. +JOËL: Yeah, it's that classic consulting; it depends. Learn to balance code quality idealism versus the pragmatic reality of your goal, which is I want to ship something, both on your personal project and at work. That perfect code is useless if you can't ship it for contexts where you actually care about shipping. +And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + As developers, we care a lot about code quality. How do we know how good is good enough? When do we stop improving code? Alternatively, when working on code that's really bad, how much do you improve it before calling it a day? thoughtbot's Stephanie Minn joins Joël to chat about this and case expressions: We recently discussed these as part of thoughtbot's RubyScience reading group. Are case expressions bad? Are they equivalent to multi-way conditionals? When do you use polymorphism?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

RubyConf 2022
+RubyConf Mini
+Stephanie's talk at RubyConf 2021
+WNB.rb
+Joël's RailsConf 2022 talk
+Ruby Science
+older episode on wizards
+TCR

+ +

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. And we're here to share a little bit about what we've learned along the way. Today, I'm joined by a fellow thoughtboter, Stephanie Minn.

+ +

STEPHANIE: Hi, Joël.

+ +

JOËL: Welcome to the show.

+ +

STEPHANIE: Thanks. Happy to be here.

+ +

JOËL: Stephanie, what's new in your world?

+ +

STEPHANIE: Thanks for asking. I've been working on writing a CFP for RubyConf, which you have been plugging internally at thoughtbot. I wasn't really sure if I wanted to do it, and then I found out about RubyConf Mini, which is happening as an alternative to the main conference in Houston. And that got me really excited to have some more options and just got me thinking about what I might have sitting on the back-burner that I might want to give a talk about.

+ +

JOËL: That's really exciting. I'm curious, what is your process for coming up with an idea for a talk?

+ +

STEPHANIE: I think they come in seasons, ideas, for me, so not even necessarily when it's conference time. But if something has been sticking in my brain for a really long time, especially as it relates to processes on teams that I'm on or my day-to-day workflow, and it's something that I keep coming back to and trying to figure out what it is about it that my brain wants to work through a process, that usually tips me off that this might be something that other people are thinking about or working through.

+ +

In this case, I am planning to write a CFP about pair programming. And yeah, it's something that I've been thinking about doing for a while, and it seems kind of an evergreen topic. So I thought I would pull it out for this conference. And if it doesn't end up getting accepted, I can always resubmit again in the future.

+ +

JOËL: I love that. So it sounds like you have a note or maybe an actual written notepad somewhere where you just, over the course of the year, build up ideas, and then you take a look at that when conference time comes around.

+ +

STEPHANIE: Yeah, that's about it. I have just a very long-running note of half-formed thoughts. And then, when I give myself time to really reflect on how things have been going at work, I usually revisit it, and if any of them still resonate or stand out to me, I will go through and try to see if there's any content to come out of that. What about you? I know you are an extensive note-taker and ideas blogger.

+ +

JOËL: I have to say I really like your approach of gathering ideas throughout the year. I've worked with many people who would love to give a talk at a conference as a professional goal but then get stuck in the I don't have any ideas. I don't know what I would talk about. And most people have a thing they could talk about. They just don't know it.

+ +

And it sounds like you've done a really great job of gathering this info throughout the year so that when the time does come, you don't just freeze. You're like, no, here are the 10-20 things that I experienced or that I am an expert in or that I would love to share. And maybe there are two or three in there that would be very well-fitted for the conference you're looking at. So I love that idea. I have not done that myself personally, but maybe I should start doing that.

+ +

STEPHANIE: What about you, Joël? What's up in your world?

+ +

JOËL: So I've also been thinking a lot about RubyConf coming up, working on a few ideas for myself. And then, there are a few people that have reached out to me to help them craft ideas or get a little bit of feedback on their proposal. So I've been doing a lot of proposal reviews as well.

+ +

STEPHANIE: What do you enjoy about reviewing other people's proposals?

+ +

JOËL: I think for many people speaking at a conference is a really big, ambitious professional goal, and so helping people achieve that is really fulfilling for me. Some people might feel almost inadequate or unprepared. But because I know them, I know they've got good things to share.

+ +

And so it's almost seeing the greatness in them that they don't quite see yet or that they don't feel confident about. And so being able to see that in their proposal and say, "Oh, there’s a core of a great idea right here, tweak it a little bit, and that'll give you a slightly better chance with the committee and help you towards that path of being on stage for the first time," is really exciting.

+ +

STEPHANIE: I spoke at RubyConf last year, in 2021, virtually. And I remember that was my first time speaking at a conference. And I was worried that my talk was not super hardcore, technical enough. But my goal for my talk was to aim it towards other developers like me who are maybe mid-level and wanting to reach this whole audience of people who are attending these conferences to learn and to level up who aren't necessarily super senior experienced developers.

+ +

And it was a really great experience. People seemed to really resonate with that. So I really encourage folks to speak about things that are resonating with them at whatever point in their careers because there are so many people out there who are probably in the same boat and want to hear what you have to say.

+ +

JOËL: Absolutely. I'm curious, now that you have experienced the full cycle at least once, from ideas to crafting a submission, to getting accepted, preparing a talk, delivering the talk, and then recovering from that, what are maybe some lessons learned or some things you weren't expecting the first time you went into that that now you do know going into another cycle?

+ +

STEPHANIE: Yeah, the power of community; I had a lot of support from WNB.rb, a woman and non-binary Ruby community. We crafted our CFPs together and then practiced our talks together and had a working group that met every couple of weeks to give feedback on our talks as we were working on them. And it was really awesome to have that accountability, to have that support, people to tell you that your talk is good and give you a thumbs-up.

+ +

And I really want to continue investing in my community that way. And I really appreciate you asking this question because I guess I do have things I've learned and would want to share that with other people in my community, and yeah, just continue to encourage folks who may not have been traditionally encouraged to speak at conferences.

+ +

JOËL: Community is so powerful. Even though I've spoken at multiple conferences, I still get nervous about my talks. I have a lot of self-doubt about whether my topic is good, whether I'm sharing it in a way that's going to be impactful. And I had a magical experience at RailsConf this year where a group of us were at a hotel lobby practicing our talks the night before. And I was just still so unsure about my talk.

+ +

And the feedback that I got there gave me a huge boost of confidence that I was able to ride into the next day and give a talk that I think turned out rather well. But honestly, that was my favorite moment of the conference was 11:30 p.m., a group of people in the hotel lobby taking turns practicing their talks.

+ +

STEPHANIE: Yeah, I love that.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: One thing we've been doing recently at thoughtbot is every other week book club discussion, and we've been looking through the book Ruby Science published by thoughtbot. Every week, we'll have someone who is a facilitator, who has done the reading and has prepared some questions for the group. And you recently facilitated a session on the topic of CASE expressions and why they might be a code smell. That sounds like a really controversial statement. How did you approach that topic?

+ +

STEPHANIE: It's funny because I was looking at the upcoming chapters to pick a topic to facilitate for this book club, and CASE statements stood out to me because I was like, oh, I know what that is; that will be easy. [laughs] But it turned out to be a bit meatier than I thought it was going to be. I'd say that I didn't really consider them a code smell until I read the chapter of Ruby Science talking about them. So I was a bit surprised because they seem so common, which is probably also why I thought it would be an easy topic.

+ +

JOËL: Would you say that reading the book or that particular chapter changed your mind?

+ +

STEPHANIE: I think it did only because I hadn't necessarily given them a second thought or thought of them more deeply in that way. I think that, at least in my experience, you encounter CASE expressions pretty early in your career, and you think they're a cool tool for making your conditionals look a bit nicer.

+ +

And it takes probably a bit more experience, a little bit more pain using them or trying to extend them that you start to have a bit of a more higher level awareness of what might be problematic about a CASE expression. But the book club that I facilitated, we had a really engaging discussion where most folks agreed that it was a code smell but also said that it depends.

+ +

JOËL: Classic consultants.

+ +

STEPHANIE: Truly. One thing that someone said that was a really nice takeaway for me was that CASE expressions get a bad rap in object-oriented languages because there are typically other tools or options you can reach for that might be preferred. And someone else said that it's probably a sign that you might be doing too much in the method.

+ +

JOËL: Hmm. You mentioned that there are some tools and things that might be preferred over CASE expressions. What are the common alternatives that people say you should use instead of a CASE expression?

+ +

STEPHANIE: I think one simple solution that we discussed in the book club for more straightforward cases would be a hash lookup to use instead of checking for equality via CASE statement. Another solution we talked about was polymorphism, which I think might refer back to the idea of having a bit of a higher level understanding of abstractions in the codebase and what things might look like in the future, especially when you might not have too many conditionals yet in your CASE expression.

+ +

Another thing that really stuck out to me in our book club discussion was another thoughtboter mentioned Sandi Metz’s 99 Bottles of OOP. And in that initial solution, she presents a CASE statement as the perfectly fine solution for now. And I thought that was really interesting because, in some cases, that might be all we know about the problem, and that is perfectly fine. What do you think about that?

+ +

JOËL: I love the idea of starting simple. Don't try to start with abstraction, especially if you're doing test-driven development. You have a test, make it go green, use the simplest thing, use duplication, use all the dirty tricks. And then from there, now that you know I have a test that was red and this code makes it go green, now the question isn't how do I solve the problem? It's how do I improve the solution? So we've kind of separated those two steps out, and I really like that.

+ +

STEPHANIE: Yeah, I remember you mentioned that you had refactored something into using a CASE statement. And I'm curious if you want to share more about that.

+ +

JOËL: Oh boy, this was a "fun" problem. Fun is in air quotes, by the way. It was a multi-step form, AKA a wizard in a Rails app, where every step submitted to the same controller, and the controller was a huge mess. It had to handle submissions from four or five different forms, some of which shared fields.

+ +

And it was this huge, deeply nested conditional thing that checked if this field is present in params, that probably means we're on step three, except if this other field is also present, then it probably means we're on step four. But if this Boolean flag in the database is set to false, we might be on a variation of step three. And because there was branching, potentially, it was an absolute mess. By looking at the code, you could never know what step of the processing you were on.

+ +

What I did is instead of all of these nested if else conditions, I wrote a flat CASE expression that just said, if step one, do step one logic or process step one form. If step two, process step two form and so on. So it was nice and flat. I was able to reuse some parts of the work across by making private methods or other objects, things like that.

+ +

But you could easily tell in any part of the code what step you were processing. Which means if you get a new feature from the client that says, "Can you modify the behavior on step four?" Now you actually know where to go to. You go to this controller; you find the big CASE expression. You find the branch that says, "If step four," and then you drill down from there.

+ +

STEPHANIE: So after refactoring that into a flat structure, did you find the code more readable? Did other folks on the project think so too?

+ +

JOËL: Yes, it was unanimously loved because this is the part of the code that everybody feared to touch. It was the most awful, gnarliest code. And a few of us had touched it, and so if you did the git blame, our names would show up, which meant that anytime anybody got stuck in that code, they would reach out to us and say, "Hey, you're the last one who touched it. Can you fix this for me?" And it was a big game of not it. Cleaning it up made this code accessible to everybody on the team.

+ +

STEPHANIE: And why do you think a CASE statement was the right solution in this particular case?

+ +

JOËL: I think if it's a multi-step form that maybe had seven steps in it, you clearly have seven branches that you're working with. And so hiding that behind nested conditions where you try to reuse each other's branches just muddied the waters. We have a seven-way branching path; let's be honest about it upfront and do a seven-way CASE expression.

+ +

STEPHANIE: One thing that we didn't really talk about as much in our book club discussion was that CASE statements can be quite readable, especially for newer developers. And even though we all did think it was a bit of a code smell, I recently encountered on my client project in a code review someone saying that they preferred a CASE statement in that situation because it was easier for them to grok. I think that's a benefit worth considering before trying to do something fancier in some cases. And I'm curious what you think about that.

+ +

JOËL: I strongly agree that a CASE expression is a great place to start, especially when you have actually more than two branches. Your logic could go one of n ways. I generally like to branch earlier than later in a lot of code. It's better in my mind to have a seven-way branch at the top of your decision tree and then just straight lines down than this constantly looping back and branching again and looping back, trying to force everything down a single path when it really doesn't want to be.

+ +

STEPHANIE: So, in this case, did you know that you had those seven branching paths upfront, or did you have to tease that out?

+ +

JOËL: I did not know from the code. Honestly, it would be very difficult to infer that from the code. But from the product, I knew this is a multi-step form with seven steps. And so I knew what the branches were from the product description. But no, it was almost impossible to infer that from the code.

+ +

Long-time listeners of The Bike Shed may remember an older episode where Steph and Chris discussed multi-step forms and how best to approach them in Rails and also in JavaScript. And one thing that did come up is that an ideal way to work with a multi-step form in Rails is to have every step be its own controller. So you have a view, it submits to a controller, which renders another view or redirects to another view which submits to another controller. And that is the direction that we went with this multi-step form eventually.

+ +

Once the single controller had a big CASE expression in it, we slowly started moving each branch out to its own controller. And now we had the step one controller, the step two controller, the step three controller, and so on. And I think that was probably the best solution in the end. But we had to go through the CASE expression just to know what was safe to move out.

+ +

Interestingly, this refactor is effectively replacing a conditional with polymorphism because all of our controllers are controller objects. They respond to the same interface. And so this gets classic refactor that Ruby Science suggests, which is what we did and kind of what Steph and Chris recommended if you had the luxury of starting from scratch all those episodes ago.

+ +

STEPHANIE: Nice, I'm glad it turned out that way and was a lot more manageable.

+ +

JOËL: It's really interesting when you're working with a situation like that where you've got really messy code, and you can make some improvements. And it's like, how far do you go? Especially because there's usually a backlog of new features that the customer wants you to implement.

+ +

So I'm curious for you, Stephanie, how do you know when you've gone far enough in improving code, either in a refactor step for your own code for a feature you're writing or maybe you're trying to take a break and say I'm going to take a little bit of time today to improve this area of the code. How do you know how good is good enough?

+ +

STEPHANIE: That's an interesting question. I think I encounter that in a couple of ways, either in my own work when I am tasked with a feature, and I start getting into the code, and it stresses me out and leaves me a bit confused and not sure where to go to work on my feature. That is usually a signal that I might need to pay some attention first and make the change easy and then making the easy change.

+ +

The other common thing that I have experienced on teams is we collectively feel the pain of an area of the codebase. And maybe we talk about it at a developer meeting, and all agree that, yeah, we really want to give this part of the code some love and add it to the backlog. But it's tough in that case because, like you said, there are a lot of new features that stakeholders want. And we as developers want to be over here taking care of our little codebase [laughs], making sure that it is healthy and it feels good to work with.

+ +

JOËL: I feel like I don't just want my codebase healthy; I want it pristine.

+ +

STEPHANIE: Ooh, pristine. What does that mean to you?

+ +

JOËL: I want it perfect, nice, and shiny. And, of course, it's never that, which is why it's always tempting to toss out the old code and start over and do it right this time. That's not a good thing. You have to be able to live with the messiness of everyday life and the fact that, okay, here's an idea. I think if your codebase is perfect, you've put too much work into it. You've gone too far, and you're beyond that; when is good enough good enough?

+ +

STEPHANIE: Whoa, that's a big statement.

+ +

JOËL: [laughs] Feel free to disagree with me here.

+ +

STEPHANIE: I guess I'm curious what perfect is in this case.

+ +

JOËL: I think it's subjective for the developers who are writing it. But oftentimes, the ones who are looking for perfection go way too far in their quest for that.

+ +

STEPHANIE: Way too far at the expense of things like business value or other things?

+ +

JOËL: I think in two ways; one, you probably ended up overengineering things to try to make it so perfect. Your design needs to have some amount of flex in it for the unknown. It's okay to have some rough corners because it's going to change. And you're going to have to redo that corner next week anyway. So you need to not go all the way in making everything absolutely perfect.

+ +

The other thing is that if you are putting in the effort to make everything perfect, at some point, you hit diminishing returns. And that's not worth your time from a business perspective or even on a personal project where you're just trying to ship things. At some point, you need to make actual progress.

+ +

STEPHANIE: I'm curious if you mainly hold yourself to those very high standards or if you also think about that when reviewing other people's code.

+ +

JOËL: So I mentioned earlier that I want my code to be pristine. I want to be clear, that's a bad thing. I do not actually hold myself to that standard. And I try not to hold other people to that standard, either. It's sort of tempering idealism with pragmatism. So being able to say, look, can we cut scope and focus on just one thing? Or does this fulfill the need that we have? And will it hurt us if we leave it like this and come back to it later? Or that question I asked you at the beginning, is this good enough? And maybe we can come back to it eventually.

+ +

STEPHANIE: I really struggle with that question sometimes because, in some ways, people talk about software as a craft. And if we were building it in a vacuum, we could fine-tune and hone it until it's this beautiful, perfect, pristine thing. But because we write software for real things in the real world, we are constrained by the needs of our users, or the business, or just the purpose of building software is for folks to use it. And in that case, part of the job is evaluating trade-offs and deciding when is good enough.

+ +

But sometimes, when I'm by myself working or coding for a little while, I do get sucked into wanting to make this the best that it could be just for my own personal fulfillment and joy. And I have to pull myself out of it sometimes and take a step back and be like, is this good enough for now, good enough for other people to be able to understand, work with in the future? And sometimes, it also requires getting other people's input too.

+ +

JOËL: That's really valuable.

+ +

STEPHANIE: Yeah, the worst thing that could happen is squirreling away with your code, and then you emerge with something that was totally not what was asked for. [laughs]

+ +

JOËL: Especially on a work project. On a personal project, it's often good to know why you're doing a thing. And so maybe you want to see how far you can get away with pushing a particular metric, whether it's you want to go extreme on the decoupling or 100% TDD, or maybe you want to try something like test && commit || revert which is a development methodology. And those are all great as learning experiments, and then you go as deep as you want.

+ +

I'm going to make another hot take here, and again, feel free to tell me I'm wrong. I'm going to say that on your own personal projects, if you pursue perfection, even when it's not for work, pursuing perfection on personal projects dooms them to join the others on the pile of uncompleted projects on your GitHub.

+ +

STEPHANIE: That is an interesting take. I think it depends on the goal of your personal project because I personally like to have my projects be a bit of a sandbox, and I have no expectations that they will end up being anything that other people would necessarily look at, even though I guess they just end up public on my GitHub and are just sitting there in a weird, unfinished state.

+ +

But yeah, I like to use them as an opportunity to, like you said, practice those concepts that I am really excited to explore but might not necessarily have the opportunity to on whatever client project I'm currently working on. And sometimes, I end up just scrapping it, but the exercise itself was valuable for me. I'm curious, though, what types of personal projects you have that lead you to have that opinion.

+ +

JOËL: I think the way I use personal projects is very similar to you in that they're generally for my own personal growth and entertainment. It's about the journey, not the destination. So I generally have no intention of making this a thing that other people will use. It's typically a way to try out a technique, or a concept, or an idea. And so, for those, going really far on a performance or quality metric can be the goal. And that's completely okay with the knowledge that I probably will not complete or ship this project.

+ +

I've done a few others where I've done the opposite. I've joined Game Jam events where you typically have a hard deadline. This could be a longer one, like maybe a month or as short as a day or a weekend, and you have to build and ship something within that deadline. And then you have to really make some pragmatic choices.

+ +

STEPHANIE: Yeah, that sounds like a lot of pressure. I don't know if I would necessarily thrive in that kind of environment. I really like to spend a lot of time thinking about my code and looking over it again, sometimes to the point where I might be a little bit too precious about it.

+ +

I was reflecting on this recently, and I thought about back when I was earlier in my career and didn't have any idea of what clean or good code was or looked like. And I would just write the code that would make my future work and just put it up for review. And I was very blissfully naive, I think, at that point in my career where I wasn't self-conscious about it in any way.

+ +

And I think I'm trying to find a good middle ground between being comfortable with whatever comes out when I do some work or write some code while also having more knowledge and experience being able to revisit it and give it a deeper look after some space and feeling good about it without spending too much precious time on it.

+ +

JOËL: Yeah, it's that classic consulting; it depends. Learn to balance code quality idealism versus the pragmatic reality of your goal, which is I want to ship something, both on your personal project and at work. That perfect code is useless if you can't ship it for contexts where you actually care about shipping.

+ +

And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + As developers, we care a lot about code quality. How do we know how good is good enough? When do we stop improving code? Alternatively, when working on code that's really bad, how much do you improve it before calling it a day? thoughtbot's Stephanie Minn joins Joël to chat about this and case expressions: We recently discussed these as part of thoughtbot's RubyScience reading group. Are case expressions bad? Are they equivalent to multi-way conditionals? When do you use polymorphism?

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

RubyConf 2022
+RubyConf Mini
+Stephanie's talk at RubyConf 2021
+WNB.rb
+Joël's RailsConf 2022 talk
+Ruby Science
+older episode on wizards
+TCR

+ +

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. And we're here to share a little bit about what we've learned along the way. Today, I'm joined by a fellow thoughtboter, Stephanie Minn.

+ +

STEPHANIE: Hi, Joël.

+ +

JOËL: Welcome to the show.

+ +

STEPHANIE: Thanks. Happy to be here.

+ +

JOËL: Stephanie, what's new in your world?

+ +

STEPHANIE: Thanks for asking. I've been working on writing a CFP for RubyConf, which you have been plugging internally at thoughtbot. I wasn't really sure if I wanted to do it, and then I found out about RubyConf Mini, which is happening as an alternative to the main conference in Houston. And that got me really excited to have some more options and just got me thinking about what I might have sitting on the back-burner that I might want to give a talk about.

+ +

JOËL: That's really exciting. I'm curious, what is your process for coming up with an idea for a talk?

+ +

STEPHANIE: I think they come in seasons, ideas, for me, so not even necessarily when it's conference time. But if something has been sticking in my brain for a really long time, especially as it relates to processes on teams that I'm on or my day-to-day workflow, and it's something that I keep coming back to and trying to figure out what it is about it that my brain wants to work through a process, that usually tips me off that this might be something that other people are thinking about or working through.

+ +

In this case, I am planning to write a CFP about pair programming. And yeah, it's something that I've been thinking about doing for a while, and it seems kind of an evergreen topic. So I thought I would pull it out for this conference. And if it doesn't end up getting accepted, I can always resubmit again in the future.

+ +

JOËL: I love that. So it sounds like you have a note or maybe an actual written notepad somewhere where you just, over the course of the year, build up ideas, and then you take a look at that when conference time comes around.

+ +

STEPHANIE: Yeah, that's about it. I have just a very long-running note of half-formed thoughts. And then, when I give myself time to really reflect on how things have been going at work, I usually revisit it, and if any of them still resonate or stand out to me, I will go through and try to see if there's any content to come out of that. What about you? I know you are an extensive note-taker and ideas blogger.

+ +

JOËL: I have to say I really like your approach of gathering ideas throughout the year. I've worked with many people who would love to give a talk at a conference as a professional goal but then get stuck in the I don't have any ideas. I don't know what I would talk about. And most people have a thing they could talk about. They just don't know it.

+ +

And it sounds like you've done a really great job of gathering this info throughout the year so that when the time does come, you don't just freeze. You're like, no, here are the 10-20 things that I experienced or that I am an expert in or that I would love to share. And maybe there are two or three in there that would be very well-fitted for the conference you're looking at. So I love that idea. I have not done that myself personally, but maybe I should start doing that.

+ +

STEPHANIE: What about you, Joël? What's up in your world?

+ +

JOËL: So I've also been thinking a lot about RubyConf coming up, working on a few ideas for myself. And then, there are a few people that have reached out to me to help them craft ideas or get a little bit of feedback on their proposal. So I've been doing a lot of proposal reviews as well.

+ +

STEPHANIE: What do you enjoy about reviewing other people's proposals?

+ +

JOËL: I think for many people speaking at a conference is a really big, ambitious professional goal, and so helping people achieve that is really fulfilling for me. Some people might feel almost inadequate or unprepared. But because I know them, I know they've got good things to share.

+ +

And so it's almost seeing the greatness in them that they don't quite see yet or that they don't feel confident about. And so being able to see that in their proposal and say, "Oh, there’s a core of a great idea right here, tweak it a little bit, and that'll give you a slightly better chance with the committee and help you towards that path of being on stage for the first time," is really exciting.

+ +

STEPHANIE: I spoke at RubyConf last year, in 2021, virtually. And I remember that was my first time speaking at a conference. And I was worried that my talk was not super hardcore, technical enough. But my goal for my talk was to aim it towards other developers like me who are maybe mid-level and wanting to reach this whole audience of people who are attending these conferences to learn and to level up who aren't necessarily super senior experienced developers.

+ +

And it was a really great experience. People seemed to really resonate with that. So I really encourage folks to speak about things that are resonating with them at whatever point in their careers because there are so many people out there who are probably in the same boat and want to hear what you have to say.

+ +

JOËL: Absolutely. I'm curious, now that you have experienced the full cycle at least once, from ideas to crafting a submission, to getting accepted, preparing a talk, delivering the talk, and then recovering from that, what are maybe some lessons learned or some things you weren't expecting the first time you went into that that now you do know going into another cycle?

+ +

STEPHANIE: Yeah, the power of community; I had a lot of support from WNB.rb, a woman and non-binary Ruby community. We crafted our CFPs together and then practiced our talks together and had a working group that met every couple of weeks to give feedback on our talks as we were working on them. And it was really awesome to have that accountability, to have that support, people to tell you that your talk is good and give you a thumbs-up.

+ +

And I really want to continue investing in my community that way. And I really appreciate you asking this question because I guess I do have things I've learned and would want to share that with other people in my community, and yeah, just continue to encourage folks who may not have been traditionally encouraged to speak at conferences.

+ +

JOËL: Community is so powerful. Even though I've spoken at multiple conferences, I still get nervous about my talks. I have a lot of self-doubt about whether my topic is good, whether I'm sharing it in a way that's going to be impactful. And I had a magical experience at RailsConf this year where a group of us were at a hotel lobby practicing our talks the night before. And I was just still so unsure about my talk.

+ +

And the feedback that I got there gave me a huge boost of confidence that I was able to ride into the next day and give a talk that I think turned out rather well. But honestly, that was my favorite moment of the conference was 11:30 p.m., a group of people in the hotel lobby taking turns practicing their talks.

+ +

STEPHANIE: Yeah, I love that.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: One thing we've been doing recently at thoughtbot is every other week book club discussion, and we've been looking through the book Ruby Science published by thoughtbot. Every week, we'll have someone who is a facilitator, who has done the reading and has prepared some questions for the group. And you recently facilitated a session on the topic of CASE expressions and why they might be a code smell. That sounds like a really controversial statement. How did you approach that topic?

+ +

STEPHANIE: It's funny because I was looking at the upcoming chapters to pick a topic to facilitate for this book club, and CASE statements stood out to me because I was like, oh, I know what that is; that will be easy. [laughs] But it turned out to be a bit meatier than I thought it was going to be. I'd say that I didn't really consider them a code smell until I read the chapter of Ruby Science talking about them. So I was a bit surprised because they seem so common, which is probably also why I thought it would be an easy topic.

+ +

JOËL: Would you say that reading the book or that particular chapter changed your mind?

+ +

STEPHANIE: I think it did only because I hadn't necessarily given them a second thought or thought of them more deeply in that way. I think that, at least in my experience, you encounter CASE expressions pretty early in your career, and you think they're a cool tool for making your conditionals look a bit nicer.

+ +

And it takes probably a bit more experience, a little bit more pain using them or trying to extend them that you start to have a bit of a more higher level awareness of what might be problematic about a CASE expression. But the book club that I facilitated, we had a really engaging discussion where most folks agreed that it was a code smell but also said that it depends.

+ +

JOËL: Classic consultants.

+ +

STEPHANIE: Truly. One thing that someone said that was a really nice takeaway for me was that CASE expressions get a bad rap in object-oriented languages because there are typically other tools or options you can reach for that might be preferred. And someone else said that it's probably a sign that you might be doing too much in the method.

+ +

JOËL: Hmm. You mentioned that there are some tools and things that might be preferred over CASE expressions. What are the common alternatives that people say you should use instead of a CASE expression?

+ +

STEPHANIE: I think one simple solution that we discussed in the book club for more straightforward cases would be a hash lookup to use instead of checking for equality via CASE statement. Another solution we talked about was polymorphism, which I think might refer back to the idea of having a bit of a higher level understanding of abstractions in the codebase and what things might look like in the future, especially when you might not have too many conditionals yet in your CASE expression.

+ +

Another thing that really stuck out to me in our book club discussion was another thoughtboter mentioned Sandi Metz’s 99 Bottles of OOP. And in that initial solution, she presents a CASE statement as the perfectly fine solution for now. And I thought that was really interesting because, in some cases, that might be all we know about the problem, and that is perfectly fine. What do you think about that?

+ +

JOËL: I love the idea of starting simple. Don't try to start with abstraction, especially if you're doing test-driven development. You have a test, make it go green, use the simplest thing, use duplication, use all the dirty tricks. And then from there, now that you know I have a test that was red and this code makes it go green, now the question isn't how do I solve the problem? It's how do I improve the solution? So we've kind of separated those two steps out, and I really like that.

+ +

STEPHANIE: Yeah, I remember you mentioned that you had refactored something into using a CASE statement. And I'm curious if you want to share more about that.

+ +

JOËL: Oh boy, this was a "fun" problem. Fun is in air quotes, by the way. It was a multi-step form, AKA a wizard in a Rails app, where every step submitted to the same controller, and the controller was a huge mess. It had to handle submissions from four or five different forms, some of which shared fields.

+ +

And it was this huge, deeply nested conditional thing that checked if this field is present in params, that probably means we're on step three, except if this other field is also present, then it probably means we're on step four. But if this Boolean flag in the database is set to false, we might be on a variation of step three. And because there was branching, potentially, it was an absolute mess. By looking at the code, you could never know what step of the processing you were on.

+ +

What I did is instead of all of these nested if else conditions, I wrote a flat CASE expression that just said, if step one, do step one logic or process step one form. If step two, process step two form and so on. So it was nice and flat. I was able to reuse some parts of the work across by making private methods or other objects, things like that.

+ +

But you could easily tell in any part of the code what step you were processing. Which means if you get a new feature from the client that says, "Can you modify the behavior on step four?" Now you actually know where to go to. You go to this controller; you find the big CASE expression. You find the branch that says, "If step four," and then you drill down from there.

+ +

STEPHANIE: So after refactoring that into a flat structure, did you find the code more readable? Did other folks on the project think so too?

+ +

JOËL: Yes, it was unanimously loved because this is the part of the code that everybody feared to touch. It was the most awful, gnarliest code. And a few of us had touched it, and so if you did the git blame, our names would show up, which meant that anytime anybody got stuck in that code, they would reach out to us and say, "Hey, you're the last one who touched it. Can you fix this for me?" And it was a big game of not it. Cleaning it up made this code accessible to everybody on the team.

+ +

STEPHANIE: And why do you think a CASE statement was the right solution in this particular case?

+ +

JOËL: I think if it's a multi-step form that maybe had seven steps in it, you clearly have seven branches that you're working with. And so hiding that behind nested conditions where you try to reuse each other's branches just muddied the waters. We have a seven-way branching path; let's be honest about it upfront and do a seven-way CASE expression.

+ +

STEPHANIE: One thing that we didn't really talk about as much in our book club discussion was that CASE statements can be quite readable, especially for newer developers. And even though we all did think it was a bit of a code smell, I recently encountered on my client project in a code review someone saying that they preferred a CASE statement in that situation because it was easier for them to grok. I think that's a benefit worth considering before trying to do something fancier in some cases. And I'm curious what you think about that.

+ +

JOËL: I strongly agree that a CASE expression is a great place to start, especially when you have actually more than two branches. Your logic could go one of n ways. I generally like to branch earlier than later in a lot of code. It's better in my mind to have a seven-way branch at the top of your decision tree and then just straight lines down than this constantly looping back and branching again and looping back, trying to force everything down a single path when it really doesn't want to be.

+ +

STEPHANIE: So, in this case, did you know that you had those seven branching paths upfront, or did you have to tease that out?

+ +

JOËL: I did not know from the code. Honestly, it would be very difficult to infer that from the code. But from the product, I knew this is a multi-step form with seven steps. And so I knew what the branches were from the product description. But no, it was almost impossible to infer that from the code.

+ +

Long-time listeners of The Bike Shed may remember an older episode where Steph and Chris discussed multi-step forms and how best to approach them in Rails and also in JavaScript. And one thing that did come up is that an ideal way to work with a multi-step form in Rails is to have every step be its own controller. So you have a view, it submits to a controller, which renders another view or redirects to another view which submits to another controller. And that is the direction that we went with this multi-step form eventually.

+ +

Once the single controller had a big CASE expression in it, we slowly started moving each branch out to its own controller. And now we had the step one controller, the step two controller, the step three controller, and so on. And I think that was probably the best solution in the end. But we had to go through the CASE expression just to know what was safe to move out.

+ +

Interestingly, this refactor is effectively replacing a conditional with polymorphism because all of our controllers are controller objects. They respond to the same interface. And so this gets classic refactor that Ruby Science suggests, which is what we did and kind of what Steph and Chris recommended if you had the luxury of starting from scratch all those episodes ago.

+ +

STEPHANIE: Nice, I'm glad it turned out that way and was a lot more manageable.

+ +

JOËL: It's really interesting when you're working with a situation like that where you've got really messy code, and you can make some improvements. And it's like, how far do you go? Especially because there's usually a backlog of new features that the customer wants you to implement.

+ +

So I'm curious for you, Stephanie, how do you know when you've gone far enough in improving code, either in a refactor step for your own code for a feature you're writing or maybe you're trying to take a break and say I'm going to take a little bit of time today to improve this area of the code. How do you know how good is good enough?

+ +

STEPHANIE: That's an interesting question. I think I encounter that in a couple of ways, either in my own work when I am tasked with a feature, and I start getting into the code, and it stresses me out and leaves me a bit confused and not sure where to go to work on my feature. That is usually a signal that I might need to pay some attention first and make the change easy and then making the easy change.

+ +

The other common thing that I have experienced on teams is we collectively feel the pain of an area of the codebase. And maybe we talk about it at a developer meeting, and all agree that, yeah, we really want to give this part of the code some love and add it to the backlog. But it's tough in that case because, like you said, there are a lot of new features that stakeholders want. And we as developers want to be over here taking care of our little codebase [laughs], making sure that it is healthy and it feels good to work with.

+ +

JOËL: I feel like I don't just want my codebase healthy; I want it pristine.

+ +

STEPHANIE: Ooh, pristine. What does that mean to you?

+ +

JOËL: I want it perfect, nice, and shiny. And, of course, it's never that, which is why it's always tempting to toss out the old code and start over and do it right this time. That's not a good thing. You have to be able to live with the messiness of everyday life and the fact that, okay, here's an idea. I think if your codebase is perfect, you've put too much work into it. You've gone too far, and you're beyond that; when is good enough good enough?

+ +

STEPHANIE: Whoa, that's a big statement.

+ +

JOËL: [laughs] Feel free to disagree with me here.

+ +

STEPHANIE: I guess I'm curious what perfect is in this case.

+ +

JOËL: I think it's subjective for the developers who are writing it. But oftentimes, the ones who are looking for perfection go way too far in their quest for that.

+ +

STEPHANIE: Way too far at the expense of things like business value or other things?

+ +

JOËL: I think in two ways; one, you probably ended up overengineering things to try to make it so perfect. Your design needs to have some amount of flex in it for the unknown. It's okay to have some rough corners because it's going to change. And you're going to have to redo that corner next week anyway. So you need to not go all the way in making everything absolutely perfect.

+ +

The other thing is that if you are putting in the effort to make everything perfect, at some point, you hit diminishing returns. And that's not worth your time from a business perspective or even on a personal project where you're just trying to ship things. At some point, you need to make actual progress.

+ +

STEPHANIE: I'm curious if you mainly hold yourself to those very high standards or if you also think about that when reviewing other people's code.

+ +

JOËL: So I mentioned earlier that I want my code to be pristine. I want to be clear, that's a bad thing. I do not actually hold myself to that standard. And I try not to hold other people to that standard, either. It's sort of tempering idealism with pragmatism. So being able to say, look, can we cut scope and focus on just one thing? Or does this fulfill the need that we have? And will it hurt us if we leave it like this and come back to it later? Or that question I asked you at the beginning, is this good enough? And maybe we can come back to it eventually.

+ +

STEPHANIE: I really struggle with that question sometimes because, in some ways, people talk about software as a craft. And if we were building it in a vacuum, we could fine-tune and hone it until it's this beautiful, perfect, pristine thing. But because we write software for real things in the real world, we are constrained by the needs of our users, or the business, or just the purpose of building software is for folks to use it. And in that case, part of the job is evaluating trade-offs and deciding when is good enough.

+ +

But sometimes, when I'm by myself working or coding for a little while, I do get sucked into wanting to make this the best that it could be just for my own personal fulfillment and joy. And I have to pull myself out of it sometimes and take a step back and be like, is this good enough for now, good enough for other people to be able to understand, work with in the future? And sometimes, it also requires getting other people's input too.

+ +

JOËL: That's really valuable.

+ +

STEPHANIE: Yeah, the worst thing that could happen is squirreling away with your code, and then you emerge with something that was totally not what was asked for. [laughs]

+ +

JOËL: Especially on a work project. On a personal project, it's often good to know why you're doing a thing. And so maybe you want to see how far you can get away with pushing a particular metric, whether it's you want to go extreme on the decoupling or 100% TDD, or maybe you want to try something like test && commit || revert which is a development methodology. And those are all great as learning experiments, and then you go as deep as you want.

+ +

I'm going to make another hot take here, and again, feel free to tell me I'm wrong. I'm going to say that on your own personal projects, if you pursue perfection, even when it's not for work, pursuing perfection on personal projects dooms them to join the others on the pile of uncompleted projects on your GitHub.

+ +

STEPHANIE: That is an interesting take. I think it depends on the goal of your personal project because I personally like to have my projects be a bit of a sandbox, and I have no expectations that they will end up being anything that other people would necessarily look at, even though I guess they just end up public on my GitHub and are just sitting there in a weird, unfinished state.

+ +

But yeah, I like to use them as an opportunity to, like you said, practice those concepts that I am really excited to explore but might not necessarily have the opportunity to on whatever client project I'm currently working on. And sometimes, I end up just scrapping it, but the exercise itself was valuable for me. I'm curious, though, what types of personal projects you have that lead you to have that opinion.

+ +

JOËL: I think the way I use personal projects is very similar to you in that they're generally for my own personal growth and entertainment. It's about the journey, not the destination. So I generally have no intention of making this a thing that other people will use. It's typically a way to try out a technique, or a concept, or an idea. And so, for those, going really far on a performance or quality metric can be the goal. And that's completely okay with the knowledge that I probably will not complete or ship this project.

+ +

I've done a few others where I've done the opposite. I've joined Game Jam events where you typically have a hard deadline. This could be a longer one, like maybe a month or as short as a day or a weekend, and you have to build and ship something within that deadline. And then you have to really make some pragmatic choices.

+ +

STEPHANIE: Yeah, that sounds like a lot of pressure. I don't know if I would necessarily thrive in that kind of environment. I really like to spend a lot of time thinking about my code and looking over it again, sometimes to the point where I might be a little bit too precious about it.

+ +

I was reflecting on this recently, and I thought about back when I was earlier in my career and didn't have any idea of what clean or good code was or looked like. And I would just write the code that would make my future work and just put it up for review. And I was very blissfully naive, I think, at that point in my career where I wasn't self-conscious about it in any way.

+ +

And I think I'm trying to find a good middle ground between being comfortable with whatever comes out when I do some work or write some code while also having more knowledge and experience being able to revisit it and give it a deeper look after some space and feeling good about it without spending too much precious time on it.

+ +

JOËL: Yeah, it's that classic consulting; it depends. Learn to balance code quality idealism versus the pragmatic reality of your goal, which is I want to ship something, both on your personal project and at work. That perfect code is useless if you can't ship it for contexts where you actually care about shipping.

+ +

And on that note, let's wrap up. The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me at @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeeee!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+oSMvtA9b + + ]]> + + Joël Quenneville + + + 351: Learning in Public + https://bikeshed.thoughtbot.com/351 + 3749cdac-a2ff-4cc9-af37-7af027cf2ab8 + Tue, 23 Aug 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + It's Joël's first episode as host of The Bike Shed! 👋 + +Joël has fellow thoughtbotter [Steve Polito](https://twitter.com/stevepolitodsgn) join him to talk about the benefits and drawbacks of "learning in public" and how there are many, many different ways to do it. + 37:07 + no + + + It's Joël's first episode as host of The Bike Shed! 👋 +Joël has fellow thoughtbotter Steve Polito (https://twitter.com/stevepolitodsgn) join him to talk about the benefits and drawbacks of "learning in public" and how there are many, many different ways to do it. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Transcript: +JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot. I'm Joël Quenneville. And I'm joined today by fellow thoughtboter, Steve Polito. +STEVE: Hey, Joël. Thanks for having me; excited to be here. And congrats again on the new hosting gig. +JOËL: It's exciting to record with my first guest, and I'm excited that you get to be a part of this. And together, Steve and I are here to share a little bit of what we've learned along the way. So, Steve, what's new in your world? +STEVE: Well, on the professional side of things, I've been working on a Rails backend application that connects to a React frontend. And specifically, it's in the healthcare space. My biggest, I guess, struggle but also [laughs] thing that I've learned the most from this project is working with an inconsistent API can be very challenging. And that's been the consistent theme with this project. +But from that, I'm learning a lot. Because prior to this, I'd done a lot of work with just traditional CRUD apps where it's just all-encompassed in the Rails application. So you're kind of in control of everything. This is my first time where we're very much dependent on a third-party API. I'm learning a lot, but it can be challenging at times. But we've gotten in a space now where it's a lot more predictable, and therefore, working with it is easier. That's on the professional side of things. +Personal side of things, I, for whatever reason, decided to run a marathon in September, which means all of the training has to happen in the heat of the summer. I live in New England, and it's been unbearably hot the past two or three weeks, which means training has been unbearable. [laughs] +JOËL: Ouch. +STEVE: Well, I mean, that's what I get for signing up for a marathon at the end of the summer. So I look forward to just working with the unreliable API versus [laughs] doing this right now. That's what's going on with me. What's going on in your world, Joël? +JOËL: For long-time listeners of the podcast, they'll know that former host, Steph Viccari, has been working on a slow test suite. And part of that work has been converting some old Test::Unit tests over to RSpec. I've been working on the same project with her, and so the saga continues. +One of the really frustrating aspects of this work has been the Test::Unit tests rely a lot on fixtures which are just full of mystery guests. The fixtures that are just loaded at the top of the file refer to a few thousand records in the database, most of which are not relevant to the test that I'm trying to convert over. +The problem is that I don't know which ten records, you know, which two users out of the 100 defined in the fixture file are relevant. They're not referenced directly anywhere in the test. But if the RSpec conversion that I do fails, it will break because some user is not present in the database. And so I need to reverse engineer the code and figure out what is missing, which user record is just assumed to be in the database. +STEVE: Yeah, that sounds frustrating. Honestly, until working at thoughtbot, I didn't quite understand the concept of mystery guest. Because when I learned Rails, I just did the Michael Hartl Rails Tutorial, which, in an effort to make it as easy as possible, he just kind of does vanilla Rails. So there's no Factory Bot or RSpec, for example, and it's all fixtures. And it works very well for teaching you how to build and test an application without getting bogged down with too many of the extra things that come along with that. +So I always thought, okay, fixtures, cool, no big deal. Why does everyone always use Factory Bot?[laughs] Like, what problem is this solving? And I'm realizing now because I've run into this too, the issue that it’s solving is this mystery guest, so that's one of the issues that it's solving. And that's just one of those things that I didn't really appreciate until I would run up against it in a similar situation you're describing now where you're writing a test. It might even be a very simple test, right? Like five lines or something, and you're just expecting something trivial to happen. +And it's failing, and it's failing for the wrong reason. The message is so cryptic. And you're just like, what is this thing talking about? It's like referencing something that has nothing to do with the test. And that pain right there is the pain of a mystery guest. I just didn't have a name for it until listening to these episodes. And now I can appreciate why you want to avoid that type of stuff and also why Factory Bot is helpful for that. +JOËL: I think it's the kind of pain that tends to bite you more when you're modifying the tests later on than when you're writing them upfront. And since now, with the work that I'm currently doing, it's all modifying existing tests, I'm feeling this pain on a daily basis. Does that track with your experience as well? +STEVE: Yeah, pretty much. And then what ends up happening is you're working on a feature, and the test fails for the wrong reason. And then you realize 30 other tests fail for the wrong reason. And then, before you know it, you've spent four hours going down a rabbit hole to clean up the fixtures, or the mystery guests, or the implied setup that might be shared across other tests. It's just such a momentum killer, first of all. +You're in this headspace of like, okay, here's the feature I'm working on. Let's just bang this out real quick; no big deal. I want to go to lunch in a couple of minutes. [laughs] And then you're trying to fix this test because it's failing for the wrong reason. And then you keep pulling the string, and you're like, oh, okay, well, there must be a mystery guest or something, but that took like 20 minutes to figure out. +And then you figure that part out but then maybe fixing that mystery guest involves either updating that particular fixture, which could then fan out and cause other tests to fail because it depended on that fixture to have certain properties. Or you have to create a new fixture. But if you create a new fixture, there's now an extra record in the database. And that could break other tests because they are maybe expecting there to be a certain set of users and other things. +But that's just one of those things that early on, I would listen to episodes like this or hear about mystery guests, and I would be like, I just don't get what they're talking about. If you have a few fixtures, how is that so hard to keep straight in your head? And sure, at first, it's not a big deal if you have maybe two fixtures or something. +But then it quickly just reaches an inflection point where either there's more than one person on your team, or you have to add more fixtures or whatever. And then it just reaches an inflection point where it's just not sustainable anymore. And that sounds like that's obviously the point at which this project is at, and that's where you're trying to rein it back in. +JOËL: Yes. So it's definitely making the conversion from Test::Unit over to RSpec more difficult. I've been trying something a little bit clever to try to figure out what data is actually needed because that's my core problem. I have a Test::Unit test that doesn't define any initial setup data. It just assumes that data has been created by fixtures at some point. But there are thousands of records in the database. So which ones do I need to port over to this setup phase of my RSpec test? +What I've been doing is hooking into Active Support notification and watching the records that get read from the database from the Test::Unit tests. And that can tell me, oh, it's these ten that this particular test is using. Those are the ones you're going to need to convert over to your setup block. +STEVE: That's clever. I like that. So you were just looking at the logs essentially. Or did you have to do any puts statements or anything? Or was it just the default internal logging mechanism that Rails has under the hood? +JOËL: The simple version of this would be to look at the logs, so tail the test log file. I'm trying to be a little bit fancier and hooking into Active Support notification, which is something built into Rails that allows you to just listen to certain events in the system and then do actions based off those events. So I can subscribe to any database read and then say call this block when a database read happens. And in that block, I can then update a stats object that, over the course of the test, will then tell me what objects have been read from the database. +STEVE: Oh, okay. That's clever. I'm glad you shared that too. Based on this discussion of mystery guests, I feel like that's just a good use for that tool. I almost wonder if there's an opportunity not even to abstract that because that'd be too much work and overkill, but just, I don't know, make like a gist or something and just reference that for the future. +Because I feel like this is the type of thing that other people are going to run up against...or maybe even a blog post or something because it's just like, if nothing else, it would be good for future Joël to be like, how did I do that again? Oh, yeah, here it is. Like, it's in this blog post I wrote six months ago. So I could just copy and paste the code snippet and call it a day. +JOËL: It's funny you mention blog posts because we have a lot of these conversations internally at thoughtbot. And without fail, someone will eventually comment, "This is great content. You should turn it into a blog post," to the point where we now have an emoji reaction for you should make this into a blog post. +STEVE: Right. That's what's really maybe special about the software industry is there's just a lot of knowledge share built into it just with open-source software, for example. I mean, that's already a form of knowledge share. It's not a blog post, but it's a form of knowledge share. And I just think getting into a habit of just sharing these little artifacts, big or small, whether it's a blog post or just a code snippet, is really helpful for a variety of reasons. +But one, and in this case, to go back to the issue that you've been facing on the client work is you just explained...We talked about a lot of things; two of them were like, what's the mystery guest? That's helpful for some people to know because until very recently like I said, I didn't even really understand what the pains of mystery guests were. And then, we also talked about a potential solution to that. +So a naive approach is tailing the logs, but then you took it a step further with that clever solution to use that notification object. And if we weren't recording this right now, that might be lost in the ether forever. Maybe the people you're working with on your team would know about it, but that would kind of be it. So I think there's an opportunity for you to maybe abstract that into like a code snippet or blog post or something and just store it away for later so that future Joël or another developer can learn from that. +JOËL: That's a really good point, Steve. Creating public artifacts like that is a form of...I've heard it referred to as learning in public before. And that's actually a topic that I think you've really demonstrated mastery of. You are great at sharing the things you've learned or even the questions you have with your colleagues, and the team at thoughtbot, and the broader developer community. What was your journey into starting to share in public like this? Because I know it can be really intimidating, especially for someone who's early in their career. +STEVE: Yeah, that's a good question. So a very brief background on my career history is I'm not classically trained, so to speak, and I'm doing air quotes for those listening. When I say, I'm not classically trained, what I mean is I went to school for graphic design. And there was some overlap with web design, obviously. +But I ended my collegiate career really just knowing how to use Dreamweaver and knowing a little bit about HTML and CSS and barely anything about JavaScript, and I didn't know anything about server-side languages. That was my base. And I was fortunate enough to get a job at a small WordPress agency. I got really good at understanding WordPress and how to configure a website and then making it look like the Photoshop document. +JOËL: There's a shocking amount of the web that runs on WordPress. +STEVE: It's a huge amount. And what's nice is that it doesn't...as you just heard, I didn't have a lot of experience with making production websites. So WordPress made it easy enough for me to get my feet wet. But I would run into a lot of problems. And I was the only developer at this agency, so I couldn't turn to my co-worker and say, "Hey, can you take a look at this real quick?" It was just me and Stack Overflow. That was it. +The reason I'm saying this is because Stack Overflow and being the only person at the agency forced me to learn in public but from a different mindset. I wasn't necessarily learning in public; I was desperately trying to solve a problem by the end of the day. And it just happened to be in public because I would have to either go on Google or Stack Overflow or forums to find the answer. +JOËL: So were you asking questions on these sites then? Like, you were going into a chat room and asking questions or going to Stack Overflow and asking questions. +STEVE: Yeah. If I couldn't find a solution quickly, I would just go on there and just shamelessly ask questions which they were, in some sense, naive questions. Looking back at them now, it clearly highlighted that I didn't understand the fundamentals, but that's okay because I know I didn't. [laughs] And I'm sharing that with everyone right now, so it's not like it's a secret. Because that was the only way I was going to figure it out, like I said. And I didn't have anyone at that agency to ask for help. +So that got me into the mindset of just ask for help. But it also got me into a mindset of...one thing was, okay, I can't just paste the entire error message, like, the entire 3,000-line error message from the logs onto Stack Overflow. That's not going to help anybody. No one's going to answer that question. I needed to start to get good at distilling down the problem into its smallest part to then be able to share it, so I would at least incentivize someone to answer it versus pushing them away because who wants to read a non-formatted log file dump? +JOËL: That is a skill in and of itself. +STEVE: Yeah. I mean, it took time, don't get me wrong. And at first, I was posting those [laughs] giant log files. I would just say, "Hey, can you help me?" [laughs] And it's like, there's no context, and it's just 3,000 lines of gibberish. So obviously, I quickly learned, well, I got to make these bite-size. But then, from there, I slowly learned over time thanks to the community, and just the advent of the internet, and searching and everything like that. +But then I got to a point where I was confident enough with the skills I was learning that I wanted to start giving back and if nothing else, it was really just to help future Steve. So when I would run into an issue that I couldn't solve, typically at this point, it was like WordPress or Drupal issues. Once I was able to solve it, I would then write up a blog post with that solution, and they were very simple posts. +And just by chance, they happened to be very search-engine friendly because I would just, like, the title of the post would be basically the error message or how to do X in Drupal. Obviously, as a software developer, no shortage of problems, right? Like, every day, you're going to run into something that you actually just do not know the answer to. So I would just amass dozens of these problems. And if I found one interesting enough, I would post about it. And I just got into a habit of that because, like I said, if nothing else, it helps me for the future. +But then it's also nice to know there's certainly going to be someone else out there who has the same issue. And it's kind of exciting to think someone on the other side of the globe is going to possibly search this thing and maybe land on my website or something, just like I have done countless times where I've put in something into a search engine, and I land on someone's website, typically the thoughtbot website, [laughs] and I read the solution there. So it's exciting to be part of that. +JOËL: Were you ever afraid that somebody else would come along and tell you your solution is wrong? +STEVE: I wasn't necessarily afraid because that comes with the territory. Honestly, fortunately, I've never really had a situation where someone was outright mean or disrespectful. For the most part, I find folks are very helpful. But it does help like I said, if you distill those questions down and make it simple for someone to help you with. But yeah, I mean, that is one of the...I don't want to say risks, but that comes with the territory of learning in public, which is you might face criticism. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. +So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +JOËL: One thing that I really appreciate with some of the things that you share on social media is kind of like what we say here on the show, sharing a little bit of what we've learned along the way. So you get to follow Steve's journey. And it's like, I'm trying this problem; here is the solution I have so far. It seems to solve some problems, not everything. Tune in tomorrow to hear how the problem keeps developing. +STEVE: Yeah, exactly. That's kind of why I try to make sure I'm giving back at least half as much as I'm taking, so to speak. So in these transactions, like on social media, I'm stumped on something or maybe not even stumped, but I'm just, like you said, exploring an idea. And I want to have it peer-reviewed, so to speak. I mean, in some ways, some of these things are almost like a Twitter code review, right? It's just like, instead of having the formality of doing it on GitHub or whatever, it's just like, here's a snippet, quick gut check here. +And then what's nice is that people are nice enough to respond with what they think. They'll reference other posts or other projects that might touch upon that. And what's nice and what I hope is happening with these exchanges is maybe someone learned a little something about what I just posted. Because I know that I'm certainly learning something from the feedback I get. +And then again, it's almost like code review. You get this nice history of what this idea is about and then different stances on it. And then it just sort of serves as a little bit of a learning tool right there. And then yeah, I'll try to follow up later on, like, hey, here's where I landed now. But maybe it's a little more fleshed out. +JOËL: What are maybe some drawbacks of this concept of learning in public? Are there some reasons you might not want to or not be able to do this? +STEVE: I do think there are...maybe not drawbacks, maybe just risks. An obvious one I can think of is if you're working on proprietary software; for example, you legally probably can't share anything that you're working on. So that makes it challenging because you can't just straight up take a screenshot of your editor [chuckles] and be like, "Hey, look at this cool thing I'm working on today." +That adds a little bit of a roadblock because then you probably have to simplify it or, I don't know, anonymize it in a way that it's just generic. So it just adds a little bit of extra work. But in some ways, that might actually be a good thing because then you've simplified the problem to its purest form, so to speak. +Another drawback we kind of touched upon is you're opening yourself up to criticism, that can be a challenge. Everyone communicates differently. People may not want to use Twitter, for example, to learn in public. They might just want to have a personal blog and do it that way. +JOËL: Turn off the comments. +STEVE: Exactly. Turn off the comments. If you're someone that is hesitant of criticism or just being on social media in general and all that, learning in public can be whatever you want it to be. So what I mean by that is we talked about Twitter and social media. That's kind of an obvious way to learn in public. But another way is you could just have some GitHub repos or your own personal blog, you know, things like that. +What's being implied here is learning in public means, like, public, anyone could access it. But I want to challenge that because public could mean different things in different contexts. So at thoughtbot, for example, we have our dev channel, and people post there all the time. And that's public in a sense, but it's not public to the world. So it's a little more controlled. You know that you're going to get helpful feedback. It's a safe space to do that. +So I would encourage folks listening now that work in an agency or just work in software development in general see if you can create your own dev channel at work or something like that if you don't already have something like that because that's a good way to, I guess, encourage people to learn in public. +JOËL: I love that you're redefining public a little bit here and the idea that public could just mean your team at work or your company. That's a concept that I really like because now maybe it's a little bit less intense to share with them. And it can be something as simple as today I learned. It could be a question about a particular technical thing, or here's the thing I did; it works. Is there a better way to do it? +STEVE: Exactly. If you think about it, code review is a form of learning in public that's built into our day-to-day job because it encompasses a lot of these things. You have to be...I don't want to say ready to take criticism, but it's very common to open up a PR, and you're going to get feedback on it. +The reason I'm hesitant to say criticism is there's a connotation of just criticize me and the person is being rude or something; I don't mean that. I just mean someone who is being critical of your work in the sense that they're making sure it meets the requirement. And it is quote, unquote "good code" given the constraints. So you have to open yourself up to criticism that way. +You're also creating these little artifacts because, in code review, there's going to be a back and forth. Someone might suggest a change; someone else might praise or just give you a shout-out to be like, "Hey, I've never seen this before. I've never seen this method before or this pattern before. This is really neat. It reminds me of something I learned over here." And they might paste a link to something else. +So yeah, code review is a form of learning in public. It's like a very controlled, simplified version of that. And it can also be a good source for learning in public through social media. Because then from that, you get this distilled concept that you can then share to the world or just at work with other people that may not be on your team. +JOËL: thoughtbot has a few, I think, different cultural things that we like to do that all converge on some of these ideas, one being that we have dedicated investment time to try to improve ourselves. Two being that we try to share anything that we create as publicly as possible. So default to making something publicly available unless there's a good reason to keep it private which is the opposite of a lot of companies. +And then finally, bringing that all together, trying to, in the things that we learn, in the work that we do, pull out shareable artifacts. So if you're reading a book, if you're working on a project, is there something tangible you can pull out of it to share back with the team or even the broader world? And that might just be dropping, "Today I learned this," in our dev channel. It might be putting up a little proof of concept repo and publishing it publicly. It might be, as you mentioned earlier, writing a blog post about a cool technique that you found helpful on a project. +So we're constantly trying to find ways to take anything that we've learned and not just make it a personal thing but also try to sort of multiply that to, at the very least, our team but where it makes sense also the broader dev community. +STEVE: Yeah, exactly. I don't know about you, but I feel like there are a lot of similarities with learning in public in their many forms with open-source software. Because open-source software is basically learning in public, right? For folks listening who might be hesitant to start getting in the habit of this, I would just encourage you to look at any popular repository and look at all the open issues. +And what I mean by that is these popular repositories that are used by millions of people they're not perfect. Like, they didn't get it right on their first try. And you can read the source code and you can see everything about it. And it kind of embodies learning in public in that way. So it opens itself up for criticism but also praise. And then it's also just a resource there where you can learn from it. +There are so many times where I'll open up the Rails, like, I'll just go to the Rails source code, not because I need to but because I'm curious, like, how do they do that particular thing? Like, the other day, we were working on something where we had an object or a class, and we wanted it to have two class methods, one called perform, and one called perform with an exclamation point. The details of that don't matter, but I was just kind of like, well, that reminds me of Rails with destroy and destroy with an exclamation point. +And I just want to see how do they do that under the hood? Like, not every single detail, but just how does the destroy method with the exclamation point, like, does the call destroy under the hood? What does it do? And I was just like, well, let's just see what Rails does. And we can kind of copy that pattern for what we're doing over here, which was great. And, again, that wouldn't have happened if we didn't have open-source software, which, again, I think is a form of collective learning in public. It's like, it's the source. It's a result of many people working on it. +JOËL: Even for projects that have only a single author, I think there can be a lot of value there. Long-time listeners of the show will know that I'm a big fan of the Elm programming language. And I've participated in a few Game Jam events where you have a deadline, typically a few days or maybe a month, to create a game based on a theme. And I've built some games using Elm. Later on, people will ask me about particular patterns that can be used in Elm, maybe related to games, maybe not related to games. +And I've been able to link them to parts of that open-source code for the games that I built, which are built under pressure. They're not always great quality. But I can link to a particular section of the code and say, "Here's the pattern we were talking about." And that can spin off a whole conversation. +STEVE: Yeah, that's just one of the many advantages to doing these things. And I should also say, too, you say that I'm good at learning in public, but the same goes for you too. I mean, you're constantly sharing things in the dev channel, writing posts. I want to recognize that too because I think that's a skill that you've also mastered. So I appreciate that. +JOËL: Thank you. +STEVE: You share as much as you do, especially because you have significantly more experience than me. So again, to circle back to the mystery guests, I would hear you talking about mystery guests. I've heard other experienced devs talk about it. But a year or two ago, I'm like, I trust these people. Like, I really trust them. They're smart. They're credible. They have more experience. But I just don't really get what the problem is because I haven't actually experienced it firsthand, but I at least knew to be aware of it. And it was in my back pocket, and I could take it out when I was ready to do a deep dive on that. +So if it weren't for things like this podcast or blog posts or other things like that, I feel like the dev community wouldn't be nearly as...it just wouldn't be at the level that it is now. And I don't mean necessarily even Rails; I just mean software development in general. Imagine if all programmers just worked in isolation and couldn't use information from other developers or imagine that in any career, right? Physicians...imagine if they couldn't do knowledge share. +So I just think being in the software industry, it's just easier to share what you're doing because we make the internet in a way. So it's like, we're already on the internet all day, so we might as well just sprinkle in what we're learning. +JOËL: I have a personal note in my notes. It says that the best knowledge is created in the connections between people. So if you're imagining a graph where people are nodes, and the connections between them are edges, all the best ideas are on those edges where interactions happen between people and not just solo geniuses. +STEVE: Exactly, exactly. I like that. +JOËL: Power of collaboration. +STEVE: Right. It's like a neural network or something. It's just like, everything coming together, passing knowledge along. +JOËL: So, Steve, we've talked about how learning in public can be really good for your own personal growth and learning. Are there any other advantages to this approach to work where you're learning in public? +STEVE: Yes, absolutely. I think learning in public is very beneficial for junior devs in particular. And there are a few reasons I think that one of which is I think it helps you stand out amongst other candidates that are applying for a job. I think that just because...if you're constantly sharing what you learn and what you know, and again, these can be very small things. I'm not talking about multi-part blog posts or something. I'm just talking about sharing simple code snippets but just being kind of consistent about it. +Doing that really helps hiring managers to get a sense for how you think, and how you communicate, and how you code because those are all very important aspects of software development. Like, it's not just coding. If it was just coding, I don't know, GitHub Copilot, that would be it, right? We could all just [laughs] pack up our bags and head home. But there's so much more. There's so much more communicating that is involved in the job. +And if you're constantly sharing what you learn, that just makes it easier for maybe a hiring manager or someone to get a sense of how you think, how you code, how you problem solve, and again, how you communicate too because maybe you'll face some criticism like in the comment section or something. I'm not saying that's justified, but also, maybe that's an opportunity to practice your communication skills and maybe ask that person, like, hey, how would you solve this problem? Or, what do you recommend? +Because again, to go back to code review, that back and forth, that exchange that happens every single day. And I just think that if you're learning in public, it's just going to make it that much more easy for someone to get a sense of what you're like before they've even met you. +JOËL: And I think it's a really virtuous cycle here because you mentioned how this is a great way to show your work for potential employers, but at the same time, it's a great way to practice that work. You're talking about how this will help you improve your communication. But at the same time, it's also proving to everyone that you are good at communicating or that you have grown a lot in your communication. +STEVE: Exactly. Yep, exactly. If you're consistent about it, too, you could just scroll through your old blog posts and see what was I talking about three years ago? Versus what am I talking about now? And hopefully, there'll be some improvement and more depth to the articles. And again, it's just a great way to let folks know how you think and how you solve problems. +JOËL: I found that it's not just valuable for junior developers. I think it can be really helpful throughout your career to have public artifacts to point to. I've found that for some of my clients, being able to point back to blog posts I've written, or even conference talks I've given helps build trust, helps to build credibility for some of the work that I'm trying to do. +STEVE: Exactly, yep. And what's really exciting about it is in that moment, when you send that link or send an artifact, that transaction took two seconds. But it just embodies so much of that credibility because it took you years to get all that knowledge. But now, it's just foundational. You have this big foundation of artifacts that you can share. I think that's just wonderful. +JOËL: Keep learning in public. You're building an archive of valuable resources that will just keep compounding in value over the course of your career. +STEVE: Exactly. That's a good way to put it. I like that. +JOËL: Well, Steve, thanks so much for joining us on the show to talk about learning in public. If people are curious to see some examples of how you do this, where can they find you online? +STEVE: If you just search Steve Polito Design, you'll find me, which is kind of a callback to when I was studying graphic design back in college. So that's the best way to find me. +JOËL: So this is a handle on multiple different social media sites? +STEVE: Yep, exactly. +JOËL: Excellent. We'll make sure to link a few of those in the show notes as well. Thank you so much, Steve, for joining us this week to talk about learning in public. Do you have any last words you'd like to share with our audience? +STEVE: Yeah, I just want to thank you, again, for having me on the show. Just for context, a lot of what I learned about software development came from The Bike Shed, so, again, plus-one for learning in public. It helps other people. So it's very exciting to actually be on the other side of the show right now as a guest. So thank you very much. And congrats again on the new hosting gig; so you'll be learning in public too now, so this is great. [laughs] +JOËL: The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore. +If you enjoyed listening, one really easy way to support the show is to leave a quick rating or even a review in iTunes. It really helps other folks find the show. +If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeee!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + It's Joël's first episode as host of The Bike Shed! 👋

+ +

Joël has fellow thoughtbotter Steve Polito join him to talk about the benefits and drawbacks of "learning in public" and how there are many, many different ways to do it.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +

Transcript:

+ +

JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot. I'm Joël Quenneville. And I'm joined today by fellow thoughtboter, Steve Polito.

+ +

STEVE: Hey, Joël. Thanks for having me; excited to be here. And congrats again on the new hosting gig.

+ +

JOËL: It's exciting to record with my first guest, and I'm excited that you get to be a part of this. And together, Steve and I are here to share a little bit of what we've learned along the way. So, Steve, what's new in your world?

+ +

STEVE: Well, on the professional side of things, I've been working on a Rails backend application that connects to a React frontend. And specifically, it's in the healthcare space. My biggest, I guess, struggle but also [laughs] thing that I've learned the most from this project is working with an inconsistent API can be very challenging. And that's been the consistent theme with this project.

+ +

But from that, I'm learning a lot. Because prior to this, I'd done a lot of work with just traditional CRUD apps where it's just all-encompassed in the Rails application. So you're kind of in control of everything. This is my first time where we're very much dependent on a third-party API. I'm learning a lot, but it can be challenging at times. But we've gotten in a space now where it's a lot more predictable, and therefore, working with it is easier. That's on the professional side of things.

+ +

Personal side of things, I, for whatever reason, decided to run a marathon in September, which means all of the training has to happen in the heat of the summer. I live in New England, and it's been unbearably hot the past two or three weeks, which means training has been unbearable. [laughs]

+ +

JOËL: Ouch.

+ +

STEVE: Well, I mean, that's what I get for signing up for a marathon at the end of the summer. So I look forward to just working with the unreliable API versus [laughs] doing this right now. That's what's going on with me. What's going on in your world, Joël?

+ +

JOËL: For long-time listeners of the podcast, they'll know that former host, Steph Viccari, has been working on a slow test suite. And part of that work has been converting some old Test::Unit tests over to RSpec. I've been working on the same project with her, and so the saga continues.

+ +

One of the really frustrating aspects of this work has been the Test::Unit tests rely a lot on fixtures which are just full of mystery guests. The fixtures that are just loaded at the top of the file refer to a few thousand records in the database, most of which are not relevant to the test that I'm trying to convert over.

+ +

The problem is that I don't know which ten records, you know, which two users out of the 100 defined in the fixture file are relevant. They're not referenced directly anywhere in the test. But if the RSpec conversion that I do fails, it will break because some user is not present in the database. And so I need to reverse engineer the code and figure out what is missing, which user record is just assumed to be in the database.

+ +

STEVE: Yeah, that sounds frustrating. Honestly, until working at thoughtbot, I didn't quite understand the concept of mystery guest. Because when I learned Rails, I just did the Michael Hartl Rails Tutorial, which, in an effort to make it as easy as possible, he just kind of does vanilla Rails. So there's no Factory Bot or RSpec, for example, and it's all fixtures. And it works very well for teaching you how to build and test an application without getting bogged down with too many of the extra things that come along with that.

+ +

So I always thought, okay, fixtures, cool, no big deal. Why does everyone always use Factory Bot?[laughs] Like, what problem is this solving? And I'm realizing now because I've run into this too, the issue that it’s solving is this mystery guest, so that's one of the issues that it's solving. And that's just one of those things that I didn't really appreciate until I would run up against it in a similar situation you're describing now where you're writing a test. It might even be a very simple test, right? Like five lines or something, and you're just expecting something trivial to happen.

+ +

And it's failing, and it's failing for the wrong reason. The message is so cryptic. And you're just like, what is this thing talking about? It's like referencing something that has nothing to do with the test. And that pain right there is the pain of a mystery guest. I just didn't have a name for it until listening to these episodes. And now I can appreciate why you want to avoid that type of stuff and also why Factory Bot is helpful for that.

+ +

JOËL: I think it's the kind of pain that tends to bite you more when you're modifying the tests later on than when you're writing them upfront. And since now, with the work that I'm currently doing, it's all modifying existing tests, I'm feeling this pain on a daily basis. Does that track with your experience as well?

+ +

STEVE: Yeah, pretty much. And then what ends up happening is you're working on a feature, and the test fails for the wrong reason. And then you realize 30 other tests fail for the wrong reason. And then, before you know it, you've spent four hours going down a rabbit hole to clean up the fixtures, or the mystery guests, or the implied setup that might be shared across other tests. It's just such a momentum killer, first of all.

+ +

You're in this headspace of like, okay, here's the feature I'm working on. Let's just bang this out real quick; no big deal. I want to go to lunch in a couple of minutes. [laughs] And then you're trying to fix this test because it's failing for the wrong reason. And then you keep pulling the string, and you're like, oh, okay, well, there must be a mystery guest or something, but that took like 20 minutes to figure out.

+ +

And then you figure that part out but then maybe fixing that mystery guest involves either updating that particular fixture, which could then fan out and cause other tests to fail because it depended on that fixture to have certain properties. Or you have to create a new fixture. But if you create a new fixture, there's now an extra record in the database. And that could break other tests because they are maybe expecting there to be a certain set of users and other things.

+ +

But that's just one of those things that early on, I would listen to episodes like this or hear about mystery guests, and I would be like, I just don't get what they're talking about. If you have a few fixtures, how is that so hard to keep straight in your head? And sure, at first, it's not a big deal if you have maybe two fixtures or something.

+ +

But then it quickly just reaches an inflection point where either there's more than one person on your team, or you have to add more fixtures or whatever. And then it just reaches an inflection point where it's just not sustainable anymore. And that sounds like that's obviously the point at which this project is at, and that's where you're trying to rein it back in.

+ +

JOËL: Yes. So it's definitely making the conversion from Test::Unit over to RSpec more difficult. I've been trying something a little bit clever to try to figure out what data is actually needed because that's my core problem. I have a Test::Unit test that doesn't define any initial setup data. It just assumes that data has been created by fixtures at some point. But there are thousands of records in the database. So which ones do I need to port over to this setup phase of my RSpec test?

+ +

What I've been doing is hooking into Active Support notification and watching the records that get read from the database from the Test::Unit tests. And that can tell me, oh, it's these ten that this particular test is using. Those are the ones you're going to need to convert over to your setup block.

+ +

STEVE: That's clever. I like that. So you were just looking at the logs essentially. Or did you have to do any puts statements or anything? Or was it just the default internal logging mechanism that Rails has under the hood?

+ +

JOËL: The simple version of this would be to look at the logs, so tail the test log file. I'm trying to be a little bit fancier and hooking into Active Support notification, which is something built into Rails that allows you to just listen to certain events in the system and then do actions based off those events. So I can subscribe to any database read and then say call this block when a database read happens. And in that block, I can then update a stats object that, over the course of the test, will then tell me what objects have been read from the database.

+ +

STEVE: Oh, okay. That's clever. I'm glad you shared that too. Based on this discussion of mystery guests, I feel like that's just a good use for that tool. I almost wonder if there's an opportunity not even to abstract that because that'd be too much work and overkill, but just, I don't know, make like a gist or something and just reference that for the future.

+ +

Because I feel like this is the type of thing that other people are going to run up against...or maybe even a blog post or something because it's just like, if nothing else, it would be good for future Joël to be like, how did I do that again? Oh, yeah, here it is. Like, it's in this blog post I wrote six months ago. So I could just copy and paste the code snippet and call it a day.

+ +

JOËL: It's funny you mention blog posts because we have a lot of these conversations internally at thoughtbot. And without fail, someone will eventually comment, "This is great content. You should turn it into a blog post," to the point where we now have an emoji reaction for you should make this into a blog post.

+ +

STEVE: Right. That's what's really maybe special about the software industry is there's just a lot of knowledge share built into it just with open-source software, for example. I mean, that's already a form of knowledge share. It's not a blog post, but it's a form of knowledge share. And I just think getting into a habit of just sharing these little artifacts, big or small, whether it's a blog post or just a code snippet, is really helpful for a variety of reasons.

+ +

But one, and in this case, to go back to the issue that you've been facing on the client work is you just explained...We talked about a lot of things; two of them were like, what's the mystery guest? That's helpful for some people to know because until very recently like I said, I didn't even really understand what the pains of mystery guests were. And then, we also talked about a potential solution to that.

+ +

So a naive approach is tailing the logs, but then you took it a step further with that clever solution to use that notification object. And if we weren't recording this right now, that might be lost in the ether forever. Maybe the people you're working with on your team would know about it, but that would kind of be it. So I think there's an opportunity for you to maybe abstract that into like a code snippet or blog post or something and just store it away for later so that future Joël or another developer can learn from that.

+ +

JOËL: That's a really good point, Steve. Creating public artifacts like that is a form of...I've heard it referred to as learning in public before. And that's actually a topic that I think you've really demonstrated mastery of. You are great at sharing the things you've learned or even the questions you have with your colleagues, and the team at thoughtbot, and the broader developer community. What was your journey into starting to share in public like this? Because I know it can be really intimidating, especially for someone who's early in their career.

+ +

STEVE: Yeah, that's a good question. So a very brief background on my career history is I'm not classically trained, so to speak, and I'm doing air quotes for those listening. When I say, I'm not classically trained, what I mean is I went to school for graphic design. And there was some overlap with web design, obviously.

+ +

But I ended my collegiate career really just knowing how to use Dreamweaver and knowing a little bit about HTML and CSS and barely anything about JavaScript, and I didn't know anything about server-side languages. That was my base. And I was fortunate enough to get a job at a small WordPress agency. I got really good at understanding WordPress and how to configure a website and then making it look like the Photoshop document.

+ +

JOËL: There's a shocking amount of the web that runs on WordPress.

+ +

STEVE: It's a huge amount. And what's nice is that it doesn't...as you just heard, I didn't have a lot of experience with making production websites. So WordPress made it easy enough for me to get my feet wet. But I would run into a lot of problems. And I was the only developer at this agency, so I couldn't turn to my co-worker and say, "Hey, can you take a look at this real quick?" It was just me and Stack Overflow. That was it.

+ +

The reason I'm saying this is because Stack Overflow and being the only person at the agency forced me to learn in public but from a different mindset. I wasn't necessarily learning in public; I was desperately trying to solve a problem by the end of the day. And it just happened to be in public because I would have to either go on Google or Stack Overflow or forums to find the answer.

+ +

JOËL: So were you asking questions on these sites then? Like, you were going into a chat room and asking questions or going to Stack Overflow and asking questions.

+ +

STEVE: Yeah. If I couldn't find a solution quickly, I would just go on there and just shamelessly ask questions which they were, in some sense, naive questions. Looking back at them now, it clearly highlighted that I didn't understand the fundamentals, but that's okay because I know I didn't. [laughs] And I'm sharing that with everyone right now, so it's not like it's a secret. Because that was the only way I was going to figure it out, like I said. And I didn't have anyone at that agency to ask for help.

+ +

So that got me into the mindset of just ask for help. But it also got me into a mindset of...one thing was, okay, I can't just paste the entire error message, like, the entire 3,000-line error message from the logs onto Stack Overflow. That's not going to help anybody. No one's going to answer that question. I needed to start to get good at distilling down the problem into its smallest part to then be able to share it, so I would at least incentivize someone to answer it versus pushing them away because who wants to read a non-formatted log file dump?

+ +

JOËL: That is a skill in and of itself.

+ +

STEVE: Yeah. I mean, it took time, don't get me wrong. And at first, I was posting those [laughs] giant log files. I would just say, "Hey, can you help me?" [laughs] And it's like, there's no context, and it's just 3,000 lines of gibberish. So obviously, I quickly learned, well, I got to make these bite-size. But then, from there, I slowly learned over time thanks to the community, and just the advent of the internet, and searching and everything like that.

+ +

But then I got to a point where I was confident enough with the skills I was learning that I wanted to start giving back and if nothing else, it was really just to help future Steve. So when I would run into an issue that I couldn't solve, typically at this point, it was like WordPress or Drupal issues. Once I was able to solve it, I would then write up a blog post with that solution, and they were very simple posts.

+ +

And just by chance, they happened to be very search-engine friendly because I would just, like, the title of the post would be basically the error message or how to do X in Drupal. Obviously, as a software developer, no shortage of problems, right? Like, every day, you're going to run into something that you actually just do not know the answer to. So I would just amass dozens of these problems. And if I found one interesting enough, I would post about it. And I just got into a habit of that because, like I said, if nothing else, it helps me for the future.

+ +

But then it's also nice to know there's certainly going to be someone else out there who has the same issue. And it's kind of exciting to think someone on the other side of the globe is going to possibly search this thing and maybe land on my website or something, just like I have done countless times where I've put in something into a search engine, and I land on someone's website, typically the thoughtbot website, [laughs] and I read the solution there. So it's exciting to be part of that.

+ +

JOËL: Were you ever afraid that somebody else would come along and tell you your solution is wrong?

+ +

STEVE: I wasn't necessarily afraid because that comes with the territory. Honestly, fortunately, I've never really had a situation where someone was outright mean or disrespectful. For the most part, I find folks are very helpful. But it does help like I said, if you distill those questions down and make it simple for someone to help you with. But yeah, I mean, that is one of the...I don't want to say risks, but that comes with the territory of learning in public, which is you might face criticism.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: One thing that I really appreciate with some of the things that you share on social media is kind of like what we say here on the show, sharing a little bit of what we've learned along the way. So you get to follow Steve's journey. And it's like, I'm trying this problem; here is the solution I have so far. It seems to solve some problems, not everything. Tune in tomorrow to hear how the problem keeps developing.

+ +

STEVE: Yeah, exactly. That's kind of why I try to make sure I'm giving back at least half as much as I'm taking, so to speak. So in these transactions, like on social media, I'm stumped on something or maybe not even stumped, but I'm just, like you said, exploring an idea. And I want to have it peer-reviewed, so to speak. I mean, in some ways, some of these things are almost like a Twitter code review, right? It's just like, instead of having the formality of doing it on GitHub or whatever, it's just like, here's a snippet, quick gut check here.

+ +

And then what's nice is that people are nice enough to respond with what they think. They'll reference other posts or other projects that might touch upon that. And what's nice and what I hope is happening with these exchanges is maybe someone learned a little something about what I just posted. Because I know that I'm certainly learning something from the feedback I get.

+ +

And then again, it's almost like code review. You get this nice history of what this idea is about and then different stances on it. And then it just sort of serves as a little bit of a learning tool right there. And then yeah, I'll try to follow up later on, like, hey, here's where I landed now. But maybe it's a little more fleshed out.

+ +

JOËL: What are maybe some drawbacks of this concept of learning in public? Are there some reasons you might not want to or not be able to do this?

+ +

STEVE: I do think there are...maybe not drawbacks, maybe just risks. An obvious one I can think of is if you're working on proprietary software; for example, you legally probably can't share anything that you're working on. So that makes it challenging because you can't just straight up take a screenshot of your editor [chuckles] and be like, "Hey, look at this cool thing I'm working on today."

+ +

That adds a little bit of a roadblock because then you probably have to simplify it or, I don't know, anonymize it in a way that it's just generic. So it just adds a little bit of extra work. But in some ways, that might actually be a good thing because then you've simplified the problem to its purest form, so to speak.

+ +

Another drawback we kind of touched upon is you're opening yourself up to criticism, that can be a challenge. Everyone communicates differently. People may not want to use Twitter, for example, to learn in public. They might just want to have a personal blog and do it that way.

+ +

JOËL: Turn off the comments.

+ +

STEVE: Exactly. Turn off the comments. If you're someone that is hesitant of criticism or just being on social media in general and all that, learning in public can be whatever you want it to be. So what I mean by that is we talked about Twitter and social media. That's kind of an obvious way to learn in public. But another way is you could just have some GitHub repos or your own personal blog, you know, things like that.

+ +

What's being implied here is learning in public means, like, public, anyone could access it. But I want to challenge that because public could mean different things in different contexts. So at thoughtbot, for example, we have our dev channel, and people post there all the time. And that's public in a sense, but it's not public to the world. So it's a little more controlled. You know that you're going to get helpful feedback. It's a safe space to do that.

+ +

So I would encourage folks listening now that work in an agency or just work in software development in general see if you can create your own dev channel at work or something like that if you don't already have something like that because that's a good way to, I guess, encourage people to learn in public.

+ +

JOËL: I love that you're redefining public a little bit here and the idea that public could just mean your team at work or your company. That's a concept that I really like because now maybe it's a little bit less intense to share with them. And it can be something as simple as today I learned. It could be a question about a particular technical thing, or here's the thing I did; it works. Is there a better way to do it?

+ +

STEVE: Exactly. If you think about it, code review is a form of learning in public that's built into our day-to-day job because it encompasses a lot of these things. You have to be...I don't want to say ready to take criticism, but it's very common to open up a PR, and you're going to get feedback on it.

+ +

The reason I'm hesitant to say criticism is there's a connotation of just criticize me and the person is being rude or something; I don't mean that. I just mean someone who is being critical of your work in the sense that they're making sure it meets the requirement. And it is quote, unquote "good code" given the constraints. So you have to open yourself up to criticism that way.

+ +

You're also creating these little artifacts because, in code review, there's going to be a back and forth. Someone might suggest a change; someone else might praise or just give you a shout-out to be like, "Hey, I've never seen this before. I've never seen this method before or this pattern before. This is really neat. It reminds me of something I learned over here." And they might paste a link to something else.

+ +

So yeah, code review is a form of learning in public. It's like a very controlled, simplified version of that. And it can also be a good source for learning in public through social media. Because then from that, you get this distilled concept that you can then share to the world or just at work with other people that may not be on your team.

+ +

JOËL: thoughtbot has a few, I think, different cultural things that we like to do that all converge on some of these ideas, one being that we have dedicated investment time to try to improve ourselves. Two being that we try to share anything that we create as publicly as possible. So default to making something publicly available unless there's a good reason to keep it private which is the opposite of a lot of companies.

+ +

And then finally, bringing that all together, trying to, in the things that we learn, in the work that we do, pull out shareable artifacts. So if you're reading a book, if you're working on a project, is there something tangible you can pull out of it to share back with the team or even the broader world? And that might just be dropping, "Today I learned this," in our dev channel. It might be putting up a little proof of concept repo and publishing it publicly. It might be, as you mentioned earlier, writing a blog post about a cool technique that you found helpful on a project.

+ +

So we're constantly trying to find ways to take anything that we've learned and not just make it a personal thing but also try to sort of multiply that to, at the very least, our team but where it makes sense also the broader dev community.

+ +

STEVE: Yeah, exactly. I don't know about you, but I feel like there are a lot of similarities with learning in public in their many forms with open-source software. Because open-source software is basically learning in public, right? For folks listening who might be hesitant to start getting in the habit of this, I would just encourage you to look at any popular repository and look at all the open issues.

+ +

And what I mean by that is these popular repositories that are used by millions of people they're not perfect. Like, they didn't get it right on their first try. And you can read the source code and you can see everything about it. And it kind of embodies learning in public in that way. So it opens itself up for criticism but also praise. And then it's also just a resource there where you can learn from it.

+ +

There are so many times where I'll open up the Rails, like, I'll just go to the Rails source code, not because I need to but because I'm curious, like, how do they do that particular thing? Like, the other day, we were working on something where we had an object or a class, and we wanted it to have two class methods, one called perform, and one called perform with an exclamation point. The details of that don't matter, but I was just kind of like, well, that reminds me of Rails with destroy and destroy with an exclamation point.

+ +

And I just want to see how do they do that under the hood? Like, not every single detail, but just how does the destroy method with the exclamation point, like, does the call destroy under the hood? What does it do? And I was just like, well, let's just see what Rails does. And we can kind of copy that pattern for what we're doing over here, which was great. And, again, that wouldn't have happened if we didn't have open-source software, which, again, I think is a form of collective learning in public. It's like, it's the source. It's a result of many people working on it.

+ +

JOËL: Even for projects that have only a single author, I think there can be a lot of value there. Long-time listeners of the show will know that I'm a big fan of the Elm programming language. And I've participated in a few Game Jam events where you have a deadline, typically a few days or maybe a month, to create a game based on a theme. And I've built some games using Elm. Later on, people will ask me about particular patterns that can be used in Elm, maybe related to games, maybe not related to games.

+ +

And I've been able to link them to parts of that open-source code for the games that I built, which are built under pressure. They're not always great quality. But I can link to a particular section of the code and say, "Here's the pattern we were talking about." And that can spin off a whole conversation.

+ +

STEVE: Yeah, that's just one of the many advantages to doing these things. And I should also say, too, you say that I'm good at learning in public, but the same goes for you too. I mean, you're constantly sharing things in the dev channel, writing posts. I want to recognize that too because I think that's a skill that you've also mastered. So I appreciate that.

+ +

JOËL: Thank you.

+ +

STEVE: You share as much as you do, especially because you have significantly more experience than me. So again, to circle back to the mystery guests, I would hear you talking about mystery guests. I've heard other experienced devs talk about it. But a year or two ago, I'm like, I trust these people. Like, I really trust them. They're smart. They're credible. They have more experience. But I just don't really get what the problem is because I haven't actually experienced it firsthand, but I at least knew to be aware of it. And it was in my back pocket, and I could take it out when I was ready to do a deep dive on that.

+ +

So if it weren't for things like this podcast or blog posts or other things like that, I feel like the dev community wouldn't be nearly as...it just wouldn't be at the level that it is now. And I don't mean necessarily even Rails; I just mean software development in general. Imagine if all programmers just worked in isolation and couldn't use information from other developers or imagine that in any career, right? Physicians...imagine if they couldn't do knowledge share.

+ +

So I just think being in the software industry, it's just easier to share what you're doing because we make the internet in a way. So it's like, we're already on the internet all day, so we might as well just sprinkle in what we're learning.

+ +

JOËL: I have a personal note in my notes. It says that the best knowledge is created in the connections between people. So if you're imagining a graph where people are nodes, and the connections between them are edges, all the best ideas are on those edges where interactions happen between people and not just solo geniuses.

+ +

STEVE: Exactly, exactly. I like that.

+ +

JOËL: Power of collaboration.

+ +

STEVE: Right. It's like a neural network or something. It's just like, everything coming together, passing knowledge along.

+ +

JOËL: So, Steve, we've talked about how learning in public can be really good for your own personal growth and learning. Are there any other advantages to this approach to work where you're learning in public?

+ +

STEVE: Yes, absolutely. I think learning in public is very beneficial for junior devs in particular. And there are a few reasons I think that one of which is I think it helps you stand out amongst other candidates that are applying for a job. I think that just because...if you're constantly sharing what you learn and what you know, and again, these can be very small things. I'm not talking about multi-part blog posts or something. I'm just talking about sharing simple code snippets but just being kind of consistent about it.

+ +

Doing that really helps hiring managers to get a sense for how you think, and how you communicate, and how you code because those are all very important aspects of software development. Like, it's not just coding. If it was just coding, I don't know, GitHub Copilot, that would be it, right? We could all just [laughs] pack up our bags and head home. But there's so much more. There's so much more communicating that is involved in the job.

+ +

And if you're constantly sharing what you learn, that just makes it easier for maybe a hiring manager or someone to get a sense of how you think, how you code, how you problem solve, and again, how you communicate too because maybe you'll face some criticism like in the comment section or something. I'm not saying that's justified, but also, maybe that's an opportunity to practice your communication skills and maybe ask that person, like, hey, how would you solve this problem? Or, what do you recommend?

+ +

Because again, to go back to code review, that back and forth, that exchange that happens every single day. And I just think that if you're learning in public, it's just going to make it that much more easy for someone to get a sense of what you're like before they've even met you.

+ +

JOËL: And I think it's a really virtuous cycle here because you mentioned how this is a great way to show your work for potential employers, but at the same time, it's a great way to practice that work. You're talking about how this will help you improve your communication. But at the same time, it's also proving to everyone that you are good at communicating or that you have grown a lot in your communication.

+ +

STEVE: Exactly. Yep, exactly. If you're consistent about it, too, you could just scroll through your old blog posts and see what was I talking about three years ago? Versus what am I talking about now? And hopefully, there'll be some improvement and more depth to the articles. And again, it's just a great way to let folks know how you think and how you solve problems.

+ +

JOËL: I found that it's not just valuable for junior developers. I think it can be really helpful throughout your career to have public artifacts to point to. I've found that for some of my clients, being able to point back to blog posts I've written, or even conference talks I've given helps build trust, helps to build credibility for some of the work that I'm trying to do.

+ +

STEVE: Exactly, yep. And what's really exciting about it is in that moment, when you send that link or send an artifact, that transaction took two seconds. But it just embodies so much of that credibility because it took you years to get all that knowledge. But now, it's just foundational. You have this big foundation of artifacts that you can share. I think that's just wonderful.

+ +

JOËL: Keep learning in public. You're building an archive of valuable resources that will just keep compounding in value over the course of your career.

+ +

STEVE: Exactly. That's a good way to put it. I like that.

+ +

JOËL: Well, Steve, thanks so much for joining us on the show to talk about learning in public. If people are curious to see some examples of how you do this, where can they find you online?

+ +

STEVE: If you just search Steve Polito Design, you'll find me, which is kind of a callback to when I was studying graphic design back in college. So that's the best way to find me.

+ +

JOËL: So this is a handle on multiple different social media sites?

+ +

STEVE: Yep, exactly.

+ +

JOËL: Excellent. We'll make sure to link a few of those in the show notes as well. Thank you so much, Steve, for joining us this week to talk about learning in public. Do you have any last words you'd like to share with our audience?

+ +

STEVE: Yeah, I just want to thank you, again, for having me on the show. Just for context, a lot of what I learned about software development came from The Bike Shed, so, again, plus-one for learning in public. It helps other people. So it's very exciting to actually be on the other side of the show right now as a guest. So thank you very much. And congrats again on the new hosting gig; so you'll be learning in public too now, so this is great. [laughs]

+ +

JOËL: The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + It's Joël's first episode as host of The Bike Shed! 👋

+ +

Joël has fellow thoughtbotter Steve Polito join him to talk about the benefits and drawbacks of "learning in public" and how there are many, many different ways to do it.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +

Transcript:

+ +

JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot. I'm Joël Quenneville. And I'm joined today by fellow thoughtboter, Steve Polito.

+ +

STEVE: Hey, Joël. Thanks for having me; excited to be here. And congrats again on the new hosting gig.

+ +

JOËL: It's exciting to record with my first guest, and I'm excited that you get to be a part of this. And together, Steve and I are here to share a little bit of what we've learned along the way. So, Steve, what's new in your world?

+ +

STEVE: Well, on the professional side of things, I've been working on a Rails backend application that connects to a React frontend. And specifically, it's in the healthcare space. My biggest, I guess, struggle but also [laughs] thing that I've learned the most from this project is working with an inconsistent API can be very challenging. And that's been the consistent theme with this project.

+ +

But from that, I'm learning a lot. Because prior to this, I'd done a lot of work with just traditional CRUD apps where it's just all-encompassed in the Rails application. So you're kind of in control of everything. This is my first time where we're very much dependent on a third-party API. I'm learning a lot, but it can be challenging at times. But we've gotten in a space now where it's a lot more predictable, and therefore, working with it is easier. That's on the professional side of things.

+ +

Personal side of things, I, for whatever reason, decided to run a marathon in September, which means all of the training has to happen in the heat of the summer. I live in New England, and it's been unbearably hot the past two or three weeks, which means training has been unbearable. [laughs]

+ +

JOËL: Ouch.

+ +

STEVE: Well, I mean, that's what I get for signing up for a marathon at the end of the summer. So I look forward to just working with the unreliable API versus [laughs] doing this right now. That's what's going on with me. What's going on in your world, Joël?

+ +

JOËL: For long-time listeners of the podcast, they'll know that former host, Steph Viccari, has been working on a slow test suite. And part of that work has been converting some old Test::Unit tests over to RSpec. I've been working on the same project with her, and so the saga continues.

+ +

One of the really frustrating aspects of this work has been the Test::Unit tests rely a lot on fixtures which are just full of mystery guests. The fixtures that are just loaded at the top of the file refer to a few thousand records in the database, most of which are not relevant to the test that I'm trying to convert over.

+ +

The problem is that I don't know which ten records, you know, which two users out of the 100 defined in the fixture file are relevant. They're not referenced directly anywhere in the test. But if the RSpec conversion that I do fails, it will break because some user is not present in the database. And so I need to reverse engineer the code and figure out what is missing, which user record is just assumed to be in the database.

+ +

STEVE: Yeah, that sounds frustrating. Honestly, until working at thoughtbot, I didn't quite understand the concept of mystery guest. Because when I learned Rails, I just did the Michael Hartl Rails Tutorial, which, in an effort to make it as easy as possible, he just kind of does vanilla Rails. So there's no Factory Bot or RSpec, for example, and it's all fixtures. And it works very well for teaching you how to build and test an application without getting bogged down with too many of the extra things that come along with that.

+ +

So I always thought, okay, fixtures, cool, no big deal. Why does everyone always use Factory Bot?[laughs] Like, what problem is this solving? And I'm realizing now because I've run into this too, the issue that it’s solving is this mystery guest, so that's one of the issues that it's solving. And that's just one of those things that I didn't really appreciate until I would run up against it in a similar situation you're describing now where you're writing a test. It might even be a very simple test, right? Like five lines or something, and you're just expecting something trivial to happen.

+ +

And it's failing, and it's failing for the wrong reason. The message is so cryptic. And you're just like, what is this thing talking about? It's like referencing something that has nothing to do with the test. And that pain right there is the pain of a mystery guest. I just didn't have a name for it until listening to these episodes. And now I can appreciate why you want to avoid that type of stuff and also why Factory Bot is helpful for that.

+ +

JOËL: I think it's the kind of pain that tends to bite you more when you're modifying the tests later on than when you're writing them upfront. And since now, with the work that I'm currently doing, it's all modifying existing tests, I'm feeling this pain on a daily basis. Does that track with your experience as well?

+ +

STEVE: Yeah, pretty much. And then what ends up happening is you're working on a feature, and the test fails for the wrong reason. And then you realize 30 other tests fail for the wrong reason. And then, before you know it, you've spent four hours going down a rabbit hole to clean up the fixtures, or the mystery guests, or the implied setup that might be shared across other tests. It's just such a momentum killer, first of all.

+ +

You're in this headspace of like, okay, here's the feature I'm working on. Let's just bang this out real quick; no big deal. I want to go to lunch in a couple of minutes. [laughs] And then you're trying to fix this test because it's failing for the wrong reason. And then you keep pulling the string, and you're like, oh, okay, well, there must be a mystery guest or something, but that took like 20 minutes to figure out.

+ +

And then you figure that part out but then maybe fixing that mystery guest involves either updating that particular fixture, which could then fan out and cause other tests to fail because it depended on that fixture to have certain properties. Or you have to create a new fixture. But if you create a new fixture, there's now an extra record in the database. And that could break other tests because they are maybe expecting there to be a certain set of users and other things.

+ +

But that's just one of those things that early on, I would listen to episodes like this or hear about mystery guests, and I would be like, I just don't get what they're talking about. If you have a few fixtures, how is that so hard to keep straight in your head? And sure, at first, it's not a big deal if you have maybe two fixtures or something.

+ +

But then it quickly just reaches an inflection point where either there's more than one person on your team, or you have to add more fixtures or whatever. And then it just reaches an inflection point where it's just not sustainable anymore. And that sounds like that's obviously the point at which this project is at, and that's where you're trying to rein it back in.

+ +

JOËL: Yes. So it's definitely making the conversion from Test::Unit over to RSpec more difficult. I've been trying something a little bit clever to try to figure out what data is actually needed because that's my core problem. I have a Test::Unit test that doesn't define any initial setup data. It just assumes that data has been created by fixtures at some point. But there are thousands of records in the database. So which ones do I need to port over to this setup phase of my RSpec test?

+ +

What I've been doing is hooking into Active Support notification and watching the records that get read from the database from the Test::Unit tests. And that can tell me, oh, it's these ten that this particular test is using. Those are the ones you're going to need to convert over to your setup block.

+ +

STEVE: That's clever. I like that. So you were just looking at the logs essentially. Or did you have to do any puts statements or anything? Or was it just the default internal logging mechanism that Rails has under the hood?

+ +

JOËL: The simple version of this would be to look at the logs, so tail the test log file. I'm trying to be a little bit fancier and hooking into Active Support notification, which is something built into Rails that allows you to just listen to certain events in the system and then do actions based off those events. So I can subscribe to any database read and then say call this block when a database read happens. And in that block, I can then update a stats object that, over the course of the test, will then tell me what objects have been read from the database.

+ +

STEVE: Oh, okay. That's clever. I'm glad you shared that too. Based on this discussion of mystery guests, I feel like that's just a good use for that tool. I almost wonder if there's an opportunity not even to abstract that because that'd be too much work and overkill, but just, I don't know, make like a gist or something and just reference that for the future.

+ +

Because I feel like this is the type of thing that other people are going to run up against...or maybe even a blog post or something because it's just like, if nothing else, it would be good for future Joël to be like, how did I do that again? Oh, yeah, here it is. Like, it's in this blog post I wrote six months ago. So I could just copy and paste the code snippet and call it a day.

+ +

JOËL: It's funny you mention blog posts because we have a lot of these conversations internally at thoughtbot. And without fail, someone will eventually comment, "This is great content. You should turn it into a blog post," to the point where we now have an emoji reaction for you should make this into a blog post.

+ +

STEVE: Right. That's what's really maybe special about the software industry is there's just a lot of knowledge share built into it just with open-source software, for example. I mean, that's already a form of knowledge share. It's not a blog post, but it's a form of knowledge share. And I just think getting into a habit of just sharing these little artifacts, big or small, whether it's a blog post or just a code snippet, is really helpful for a variety of reasons.

+ +

But one, and in this case, to go back to the issue that you've been facing on the client work is you just explained...We talked about a lot of things; two of them were like, what's the mystery guest? That's helpful for some people to know because until very recently like I said, I didn't even really understand what the pains of mystery guests were. And then, we also talked about a potential solution to that.

+ +

So a naive approach is tailing the logs, but then you took it a step further with that clever solution to use that notification object. And if we weren't recording this right now, that might be lost in the ether forever. Maybe the people you're working with on your team would know about it, but that would kind of be it. So I think there's an opportunity for you to maybe abstract that into like a code snippet or blog post or something and just store it away for later so that future Joël or another developer can learn from that.

+ +

JOËL: That's a really good point, Steve. Creating public artifacts like that is a form of...I've heard it referred to as learning in public before. And that's actually a topic that I think you've really demonstrated mastery of. You are great at sharing the things you've learned or even the questions you have with your colleagues, and the team at thoughtbot, and the broader developer community. What was your journey into starting to share in public like this? Because I know it can be really intimidating, especially for someone who's early in their career.

+ +

STEVE: Yeah, that's a good question. So a very brief background on my career history is I'm not classically trained, so to speak, and I'm doing air quotes for those listening. When I say, I'm not classically trained, what I mean is I went to school for graphic design. And there was some overlap with web design, obviously.

+ +

But I ended my collegiate career really just knowing how to use Dreamweaver and knowing a little bit about HTML and CSS and barely anything about JavaScript, and I didn't know anything about server-side languages. That was my base. And I was fortunate enough to get a job at a small WordPress agency. I got really good at understanding WordPress and how to configure a website and then making it look like the Photoshop document.

+ +

JOËL: There's a shocking amount of the web that runs on WordPress.

+ +

STEVE: It's a huge amount. And what's nice is that it doesn't...as you just heard, I didn't have a lot of experience with making production websites. So WordPress made it easy enough for me to get my feet wet. But I would run into a lot of problems. And I was the only developer at this agency, so I couldn't turn to my co-worker and say, "Hey, can you take a look at this real quick?" It was just me and Stack Overflow. That was it.

+ +

The reason I'm saying this is because Stack Overflow and being the only person at the agency forced me to learn in public but from a different mindset. I wasn't necessarily learning in public; I was desperately trying to solve a problem by the end of the day. And it just happened to be in public because I would have to either go on Google or Stack Overflow or forums to find the answer.

+ +

JOËL: So were you asking questions on these sites then? Like, you were going into a chat room and asking questions or going to Stack Overflow and asking questions.

+ +

STEVE: Yeah. If I couldn't find a solution quickly, I would just go on there and just shamelessly ask questions which they were, in some sense, naive questions. Looking back at them now, it clearly highlighted that I didn't understand the fundamentals, but that's okay because I know I didn't. [laughs] And I'm sharing that with everyone right now, so it's not like it's a secret. Because that was the only way I was going to figure it out, like I said. And I didn't have anyone at that agency to ask for help.

+ +

So that got me into the mindset of just ask for help. But it also got me into a mindset of...one thing was, okay, I can't just paste the entire error message, like, the entire 3,000-line error message from the logs onto Stack Overflow. That's not going to help anybody. No one's going to answer that question. I needed to start to get good at distilling down the problem into its smallest part to then be able to share it, so I would at least incentivize someone to answer it versus pushing them away because who wants to read a non-formatted log file dump?

+ +

JOËL: That is a skill in and of itself.

+ +

STEVE: Yeah. I mean, it took time, don't get me wrong. And at first, I was posting those [laughs] giant log files. I would just say, "Hey, can you help me?" [laughs] And it's like, there's no context, and it's just 3,000 lines of gibberish. So obviously, I quickly learned, well, I got to make these bite-size. But then, from there, I slowly learned over time thanks to the community, and just the advent of the internet, and searching and everything like that.

+ +

But then I got to a point where I was confident enough with the skills I was learning that I wanted to start giving back and if nothing else, it was really just to help future Steve. So when I would run into an issue that I couldn't solve, typically at this point, it was like WordPress or Drupal issues. Once I was able to solve it, I would then write up a blog post with that solution, and they were very simple posts.

+ +

And just by chance, they happened to be very search-engine friendly because I would just, like, the title of the post would be basically the error message or how to do X in Drupal. Obviously, as a software developer, no shortage of problems, right? Like, every day, you're going to run into something that you actually just do not know the answer to. So I would just amass dozens of these problems. And if I found one interesting enough, I would post about it. And I just got into a habit of that because, like I said, if nothing else, it helps me for the future.

+ +

But then it's also nice to know there's certainly going to be someone else out there who has the same issue. And it's kind of exciting to think someone on the other side of the globe is going to possibly search this thing and maybe land on my website or something, just like I have done countless times where I've put in something into a search engine, and I land on someone's website, typically the thoughtbot website, [laughs] and I read the solution there. So it's exciting to be part of that.

+ +

JOËL: Were you ever afraid that somebody else would come along and tell you your solution is wrong?

+ +

STEVE: I wasn't necessarily afraid because that comes with the territory. Honestly, fortunately, I've never really had a situation where someone was outright mean or disrespectful. For the most part, I find folks are very helpful. But it does help like I said, if you distill those questions down and make it simple for someone to help you with. But yeah, I mean, that is one of the...I don't want to say risks, but that comes with the territory of learning in public, which is you might face criticism.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

JOËL: One thing that I really appreciate with some of the things that you share on social media is kind of like what we say here on the show, sharing a little bit of what we've learned along the way. So you get to follow Steve's journey. And it's like, I'm trying this problem; here is the solution I have so far. It seems to solve some problems, not everything. Tune in tomorrow to hear how the problem keeps developing.

+ +

STEVE: Yeah, exactly. That's kind of why I try to make sure I'm giving back at least half as much as I'm taking, so to speak. So in these transactions, like on social media, I'm stumped on something or maybe not even stumped, but I'm just, like you said, exploring an idea. And I want to have it peer-reviewed, so to speak. I mean, in some ways, some of these things are almost like a Twitter code review, right? It's just like, instead of having the formality of doing it on GitHub or whatever, it's just like, here's a snippet, quick gut check here.

+ +

And then what's nice is that people are nice enough to respond with what they think. They'll reference other posts or other projects that might touch upon that. And what's nice and what I hope is happening with these exchanges is maybe someone learned a little something about what I just posted. Because I know that I'm certainly learning something from the feedback I get.

+ +

And then again, it's almost like code review. You get this nice history of what this idea is about and then different stances on it. And then it just sort of serves as a little bit of a learning tool right there. And then yeah, I'll try to follow up later on, like, hey, here's where I landed now. But maybe it's a little more fleshed out.

+ +

JOËL: What are maybe some drawbacks of this concept of learning in public? Are there some reasons you might not want to or not be able to do this?

+ +

STEVE: I do think there are...maybe not drawbacks, maybe just risks. An obvious one I can think of is if you're working on proprietary software; for example, you legally probably can't share anything that you're working on. So that makes it challenging because you can't just straight up take a screenshot of your editor [chuckles] and be like, "Hey, look at this cool thing I'm working on today."

+ +

That adds a little bit of a roadblock because then you probably have to simplify it or, I don't know, anonymize it in a way that it's just generic. So it just adds a little bit of extra work. But in some ways, that might actually be a good thing because then you've simplified the problem to its purest form, so to speak.

+ +

Another drawback we kind of touched upon is you're opening yourself up to criticism, that can be a challenge. Everyone communicates differently. People may not want to use Twitter, for example, to learn in public. They might just want to have a personal blog and do it that way.

+ +

JOËL: Turn off the comments.

+ +

STEVE: Exactly. Turn off the comments. If you're someone that is hesitant of criticism or just being on social media in general and all that, learning in public can be whatever you want it to be. So what I mean by that is we talked about Twitter and social media. That's kind of an obvious way to learn in public. But another way is you could just have some GitHub repos or your own personal blog, you know, things like that.

+ +

What's being implied here is learning in public means, like, public, anyone could access it. But I want to challenge that because public could mean different things in different contexts. So at thoughtbot, for example, we have our dev channel, and people post there all the time. And that's public in a sense, but it's not public to the world. So it's a little more controlled. You know that you're going to get helpful feedback. It's a safe space to do that.

+ +

So I would encourage folks listening now that work in an agency or just work in software development in general see if you can create your own dev channel at work or something like that if you don't already have something like that because that's a good way to, I guess, encourage people to learn in public.

+ +

JOËL: I love that you're redefining public a little bit here and the idea that public could just mean your team at work or your company. That's a concept that I really like because now maybe it's a little bit less intense to share with them. And it can be something as simple as today I learned. It could be a question about a particular technical thing, or here's the thing I did; it works. Is there a better way to do it?

+ +

STEVE: Exactly. If you think about it, code review is a form of learning in public that's built into our day-to-day job because it encompasses a lot of these things. You have to be...I don't want to say ready to take criticism, but it's very common to open up a PR, and you're going to get feedback on it.

+ +

The reason I'm hesitant to say criticism is there's a connotation of just criticize me and the person is being rude or something; I don't mean that. I just mean someone who is being critical of your work in the sense that they're making sure it meets the requirement. And it is quote, unquote "good code" given the constraints. So you have to open yourself up to criticism that way.

+ +

You're also creating these little artifacts because, in code review, there's going to be a back and forth. Someone might suggest a change; someone else might praise or just give you a shout-out to be like, "Hey, I've never seen this before. I've never seen this method before or this pattern before. This is really neat. It reminds me of something I learned over here." And they might paste a link to something else.

+ +

So yeah, code review is a form of learning in public. It's like a very controlled, simplified version of that. And it can also be a good source for learning in public through social media. Because then from that, you get this distilled concept that you can then share to the world or just at work with other people that may not be on your team.

+ +

JOËL: thoughtbot has a few, I think, different cultural things that we like to do that all converge on some of these ideas, one being that we have dedicated investment time to try to improve ourselves. Two being that we try to share anything that we create as publicly as possible. So default to making something publicly available unless there's a good reason to keep it private which is the opposite of a lot of companies.

+ +

And then finally, bringing that all together, trying to, in the things that we learn, in the work that we do, pull out shareable artifacts. So if you're reading a book, if you're working on a project, is there something tangible you can pull out of it to share back with the team or even the broader world? And that might just be dropping, "Today I learned this," in our dev channel. It might be putting up a little proof of concept repo and publishing it publicly. It might be, as you mentioned earlier, writing a blog post about a cool technique that you found helpful on a project.

+ +

So we're constantly trying to find ways to take anything that we've learned and not just make it a personal thing but also try to sort of multiply that to, at the very least, our team but where it makes sense also the broader dev community.

+ +

STEVE: Yeah, exactly. I don't know about you, but I feel like there are a lot of similarities with learning in public in their many forms with open-source software. Because open-source software is basically learning in public, right? For folks listening who might be hesitant to start getting in the habit of this, I would just encourage you to look at any popular repository and look at all the open issues.

+ +

And what I mean by that is these popular repositories that are used by millions of people they're not perfect. Like, they didn't get it right on their first try. And you can read the source code and you can see everything about it. And it kind of embodies learning in public in that way. So it opens itself up for criticism but also praise. And then it's also just a resource there where you can learn from it.

+ +

There are so many times where I'll open up the Rails, like, I'll just go to the Rails source code, not because I need to but because I'm curious, like, how do they do that particular thing? Like, the other day, we were working on something where we had an object or a class, and we wanted it to have two class methods, one called perform, and one called perform with an exclamation point. The details of that don't matter, but I was just kind of like, well, that reminds me of Rails with destroy and destroy with an exclamation point.

+ +

And I just want to see how do they do that under the hood? Like, not every single detail, but just how does the destroy method with the exclamation point, like, does the call destroy under the hood? What does it do? And I was just like, well, let's just see what Rails does. And we can kind of copy that pattern for what we're doing over here, which was great. And, again, that wouldn't have happened if we didn't have open-source software, which, again, I think is a form of collective learning in public. It's like, it's the source. It's a result of many people working on it.

+ +

JOËL: Even for projects that have only a single author, I think there can be a lot of value there. Long-time listeners of the show will know that I'm a big fan of the Elm programming language. And I've participated in a few Game Jam events where you have a deadline, typically a few days or maybe a month, to create a game based on a theme. And I've built some games using Elm. Later on, people will ask me about particular patterns that can be used in Elm, maybe related to games, maybe not related to games.

+ +

And I've been able to link them to parts of that open-source code for the games that I built, which are built under pressure. They're not always great quality. But I can link to a particular section of the code and say, "Here's the pattern we were talking about." And that can spin off a whole conversation.

+ +

STEVE: Yeah, that's just one of the many advantages to doing these things. And I should also say, too, you say that I'm good at learning in public, but the same goes for you too. I mean, you're constantly sharing things in the dev channel, writing posts. I want to recognize that too because I think that's a skill that you've also mastered. So I appreciate that.

+ +

JOËL: Thank you.

+ +

STEVE: You share as much as you do, especially because you have significantly more experience than me. So again, to circle back to the mystery guests, I would hear you talking about mystery guests. I've heard other experienced devs talk about it. But a year or two ago, I'm like, I trust these people. Like, I really trust them. They're smart. They're credible. They have more experience. But I just don't really get what the problem is because I haven't actually experienced it firsthand, but I at least knew to be aware of it. And it was in my back pocket, and I could take it out when I was ready to do a deep dive on that.

+ +

So if it weren't for things like this podcast or blog posts or other things like that, I feel like the dev community wouldn't be nearly as...it just wouldn't be at the level that it is now. And I don't mean necessarily even Rails; I just mean software development in general. Imagine if all programmers just worked in isolation and couldn't use information from other developers or imagine that in any career, right? Physicians...imagine if they couldn't do knowledge share.

+ +

So I just think being in the software industry, it's just easier to share what you're doing because we make the internet in a way. So it's like, we're already on the internet all day, so we might as well just sprinkle in what we're learning.

+ +

JOËL: I have a personal note in my notes. It says that the best knowledge is created in the connections between people. So if you're imagining a graph where people are nodes, and the connections between them are edges, all the best ideas are on those edges where interactions happen between people and not just solo geniuses.

+ +

STEVE: Exactly, exactly. I like that.

+ +

JOËL: Power of collaboration.

+ +

STEVE: Right. It's like a neural network or something. It's just like, everything coming together, passing knowledge along.

+ +

JOËL: So, Steve, we've talked about how learning in public can be really good for your own personal growth and learning. Are there any other advantages to this approach to work where you're learning in public?

+ +

STEVE: Yes, absolutely. I think learning in public is very beneficial for junior devs in particular. And there are a few reasons I think that one of which is I think it helps you stand out amongst other candidates that are applying for a job. I think that just because...if you're constantly sharing what you learn and what you know, and again, these can be very small things. I'm not talking about multi-part blog posts or something. I'm just talking about sharing simple code snippets but just being kind of consistent about it.

+ +

Doing that really helps hiring managers to get a sense for how you think, and how you communicate, and how you code because those are all very important aspects of software development. Like, it's not just coding. If it was just coding, I don't know, GitHub Copilot, that would be it, right? We could all just [laughs] pack up our bags and head home. But there's so much more. There's so much more communicating that is involved in the job.

+ +

And if you're constantly sharing what you learn, that just makes it easier for maybe a hiring manager or someone to get a sense of how you think, how you code, how you problem solve, and again, how you communicate too because maybe you'll face some criticism like in the comment section or something. I'm not saying that's justified, but also, maybe that's an opportunity to practice your communication skills and maybe ask that person, like, hey, how would you solve this problem? Or, what do you recommend?

+ +

Because again, to go back to code review, that back and forth, that exchange that happens every single day. And I just think that if you're learning in public, it's just going to make it that much more easy for someone to get a sense of what you're like before they've even met you.

+ +

JOËL: And I think it's a really virtuous cycle here because you mentioned how this is a great way to show your work for potential employers, but at the same time, it's a great way to practice that work. You're talking about how this will help you improve your communication. But at the same time, it's also proving to everyone that you are good at communicating or that you have grown a lot in your communication.

+ +

STEVE: Exactly. Yep, exactly. If you're consistent about it, too, you could just scroll through your old blog posts and see what was I talking about three years ago? Versus what am I talking about now? And hopefully, there'll be some improvement and more depth to the articles. And again, it's just a great way to let folks know how you think and how you solve problems.

+ +

JOËL: I found that it's not just valuable for junior developers. I think it can be really helpful throughout your career to have public artifacts to point to. I've found that for some of my clients, being able to point back to blog posts I've written, or even conference talks I've given helps build trust, helps to build credibility for some of the work that I'm trying to do.

+ +

STEVE: Exactly, yep. And what's really exciting about it is in that moment, when you send that link or send an artifact, that transaction took two seconds. But it just embodies so much of that credibility because it took you years to get all that knowledge. But now, it's just foundational. You have this big foundation of artifacts that you can share. I think that's just wonderful.

+ +

JOËL: Keep learning in public. You're building an archive of valuable resources that will just keep compounding in value over the course of your career.

+ +

STEVE: Exactly. That's a good way to put it. I like that.

+ +

JOËL: Well, Steve, thanks so much for joining us on the show to talk about learning in public. If people are curious to see some examples of how you do this, where can they find you online?

+ +

STEVE: If you just search Steve Polito Design, you'll find me, which is kind of a callback to when I was studying graphic design back in college. So that's the best way to find me.

+ +

JOËL: So this is a handle on multiple different social media sites?

+ +

STEVE: Yep, exactly.

+ +

JOËL: Excellent. We'll make sure to link a few of those in the show notes as well. Thank you so much, Steve, for joining us this week to talk about learning in public. Do you have any last words you'd like to share with our audience?

+ +

STEVE: Yeah, I just want to thank you, again, for having me on the show. Just for context, a lot of what I learned about software development came from The Bike Shed, so, again, plus-one for learning in public. It helps other people. So it's very exciting to actually be on the other side of the show right now as a guest. So thank you very much. And congrats again on the new hosting gig; so you'll be learning in public too now, so this is great. [laughs]

+ +

JOËL: The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

+ +

If you enjoyed listening, one really easy way to support the show is to leave a quick rating or even a review in iTunes. It really helps other folks find the show.

+ +

If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+hvhjhU4l + + ]]> + + Joël Quenneville + + + 350: 21 Bell Salute + https://bikeshed.thoughtbot.com/350 + fd66f87a-a910-444e-82c6-f683b03be351 + Tue, 16 Aug 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + It's Steph and Chris' last show. Steph found a game, and if you've been following the journey, all of the Test::Unit test files are now live in RSpec. JWTs really grind Chris' gears. + +They wrap up with things they've learned, takeaways they've had, and their proudest podcasting moments. They also thank all the folks who've helped make The Bike Shed happen. + 52:09 + no + + + It's Steph and Chris' last show. +Steph found a game, and if you've been following the journey, all of the Test::Unit test files are now live in RSpec. JWTs really grind Chris' gears. +They wrap up with things they've learned, takeaways they've had, and their proudest podcasting moments. They also thank all the folks who've helped make The Bike Shed happen. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Microservices (https://www.youtube.com/watch?v=y8OnoxKotPQ) +Transcript: +CHRIS: One more round of golden roads, our golden. So here we go. +STEPH: Oh, one more round of golden roads. Okay, maybe that's going to get to me today. [laughs] +CHRIS: [singing] Golden roads take me home to the place. +STEPH: [singing] I belong. +CHRIS: Yeah, there you go. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together we're here to share a bit of what we've learned along the way, at least one more time. So with that [chuckles] as an intro, Steph, what would you say is new in your world? +STEPH: Hey, Chris. Well, today is the big day. It is the day that you and I are recording our final Bike Shed episode, which we have all the feels about, and we will definitely dive into. But to ignore some of that for now, I have another small fun update I can provide about a new game that I found. So one of the things that's new in my world is I started playing a new board game with Tim; it's called Ticket to Ride. Have you heard of that? +CHRIS: I have. I don't know if I've played it. I feel like it's a particularly popular one now. But I don't know if I've ever had the pleasure. +STEPH: It's a very cute game, so we have the smaller version of it. For anyone that's not familiar, it's essentially a map. And then there's a bunch of spots where you can build trains and connect them, and then you get tickets. So your goal is that you're going to connect one location to another location. And then you get points and yada yada, but it's so much fun and especially the two-player version. It's like this perfect 20, maybe 30-minute game. +I'll be honest; I'm not really a board game person. I always enjoy it. Once I get into it, then I'm like, this is great. I don't know why I was resistant to this. But every time someone's like, "Do you want to play a board game?" I'm like, "Not really." [laughs] I first have to get into it. But I have really enjoyed Ticket to Ride. That's been a really fun game to play. And it's been a nice way to, like, even during the day, we'll break for lunch and squeeze in a game. +CHRIS: Well, I love good two-player games. They're hard to find. But when you find a good one, and it's got that easy pickup and play...I believe I'm going to now purchase this. And thank you for the tip. +STEPH: Yeah, this is definitely one of those where it's easy to pick up, and then you can get the expanded board. So there's a two-player version, but then yeah, you can get one that's a map of the U.S. or a map of Europe. And I think it accommodates up to five players as the maximum, so not a huge group but definitely more than two. +On a slightly more technical note, I have something that I'm very excited to share. It is a journey that you have been on with me, that everybody listening has been on this journey with me. And I'm very excited. I see you nodding your head, so I'm guessing that you're going to know where I'm headed with this. But I'm very excited to announce that all of the Test::Unit test files now live in RSpec. So that is a big win. +I'm very, very excited for that to be a previous state of life and not an ongoing state of life. Because I have certainly developed too much niche knowledge around migrating these tests, and that became apparent to me when I was pairing with another developer that works with the client because they had offered...they had some time. They're like, "Hey, do you want help migrating a test file?" And I was like, "Sure." I was like, "But this is wonky enough, like, we should pair and work on this together because I just know some ins and outs. And I don't want you to have to learn a lot of the hard lessons that I've learned." +And the test that we happened to pick up was very gnarly. It had a lot of mystery guests. And we spent, I think it was a good two hours. And we only migrated one of the tests, so not even a full file but one of the tests. And at the end of it, I was like, I know way too much about some of the oddities and quirkiness of this. And we got through it, but we decided that wasn't a good use of their time for them to go at this alone. So that's why I'm extra excited and relieved because I didn't want this task to carry on to someone else. So, hooray, we did it. +CHRIS: Hooray. Just in time. You're Indiana Jones grabbing your hat right as you roll out and off to [laughs] be away from the project for a bit. So you stuck the landing. Well done, Steph. +STEPH: Thank you. Thank you. So that's some great news. And then also, everything else in life is pretty much focused around getting ready for maternity leave. That's about to happen soon, and I am so ready. I have thoroughly enjoyed a lot of the things that I'm doing, [laughs] but goodness, being pregnant is hard. And I am very much ready for that leave. +So also, a lot of the things that I'm doing right now are very focused on making sure everything's transitioned and communicated and that I just feel really good about that day of departure. That covers all the newness in my world other than the big thing that we're just not talking about yet. How about you? What's new in your world? +CHRIS: Well, continuing to skirt the bigger topic that we will certainly get to in the episode, what is new in my world? I'm actually quite excited workwise right now. We have a much larger body of work that finally we got the clarity. All the pieces fell into place, and now we're sort of everybody rowing in the same direction. There's interesting, I think, really impactful code that we're writing for Sagewell right now. So that's really fantastic. We've got the whole team back together on the engineering side. And so we're, I think, in the strongest and most interesting point that I have experienced thus far. So that's all really fantastic. +On a slight technical deep dive, you know what really grinds my gears? It's JWTs. JSON Web Tokens and I have never gotten along. It's never been a match made in heaven. And we have a webhook that comes from Plaid. Plaid is a vendor for connecting bank accounts and whatnot. And they have webhooks like many people do. So they can inform us when things change, lovely feature of how we build web apps these days. But often, there's a signature that says, "This is definitively from us, and you can trust us." And usually, it's some calculated signature, HMAC, or something like that. +For some reason, Plaid's uses JWTs, and more than that, they use JWKs. So there's JWT which is the signature. That JWT itself is signed with a JWK. You have to fetch the JWK from their server based on the key ID in the header of the JWT. But how do you know if you can trust the JWT before you've gotten the JWK? All of this broke in a recent upgrade. +We went from Heroku-20 to Heroku-22 to the new platform with Heroku, which bumped us to OpenSSL 3.0, and it turns out JWT doesn't work with it. And so that's sad. It's a no. It's going to be a no. It turns out the way that OpenSSL 3.0 works is incompatible with some of the code paths in JWT. And so I was like, wait, we just can't do this? And it's low-level cryptographic primitive stuff that I'm not comfortable messing around with. I'm not going to hop in there and roll up my sleeves. +And even just getting to the point that I understood what was broken about this took like an hour and a half just to sort of like, wait, which is okay...so the JWT signs and encodes. And this will be a theme that we come back to later, but I think web development should be simpler. I think we should strive for simplicity. And this is a perfect example where I'm guessing Plaid uses JWTs and that approach to communicating security things often, but I've not seen it used much for signing webhooks. And, oof, it led to a complicated day. And it's unfixable now as far as I can tell. +There is a commit on the JWT Ruby repo as of five days ago, but it doesn't build in our system. And it's not released. And it's just a mess. So yeah, engineering is complicated. I'm both wildly excited about what we're doing at Sagewell, and then today was this local minimum of like, oh, JWTs again. Again, we find ourselves battling. And you won today, but hopefully not for too long. +STEPH: Oof, how did this manifest that you first noticed? So is it because a webhook suddenly stopped working, and that was like the error that rose up, and that's what helped you dive into it? +CHRIS: Yeah, we have a little bit of code in the controller for where Plaid events come in. We calculate and verify the signature of the webhook to make sure that it's valid, and we reject it otherwise. And we alert ourselves via Sentry, and then we also have a Datadog scan that can show what's the status code of the response. Because these are incoming HTTP payloads or requests, and so we can see there were 200 up until this magical day when suddenly everything changed. And that was when we switched Heroku stacks. +And then we can see it also in Sentry. So we're able to look at it, and we're like, why are none of the Plaid webhooks able to verify the signature anymore? That seems weird. And so then Datadog confirmed that it consistently was broken from this point in time. And then we were able to track that back. It was also pretty easy to guess because the error was "pkeys are immutable in OpenSSL 3.0," and that was the data. And I was like, oh, cool, that sounds fun. Let me go figure out what that means. +STEPH: [laughs] Well, it's a nice use of Datadog. I remember in the past you were talking about adding it. And I was excited because I've never been at that point where a team has just introduced it; either a team doesn't have it, and they wish they had more insights, or they have it and don't use it. And nobody ever checks the board. So that's a nice anecdote for Datadog helping you out. Yeah, I'm not envious of your situation, friend. +CHRIS: I do love the cup half full take [laughs] that you have on the overall situation, but that's nice how Datadog worked out for you. And you know what? It was. Thank you, Steph, for once again being that voice of positivity. +STEPH: I appreciate that you enjoy it because there are times that when someone points it out to me that I do that, I have to be like, "I'm sorry, I'm not trying to be toxic positivity over here. [chuckles] That's just how my brain works." +CHRIS: Oh, you are definitively not toxic positivity. That's a different thing. Because you ended with but also, I feel bad for you, and I'm glad that I'm not in your shoes. So you are the right level of positivity. I don't think I could have talked to you for three and a half years as co-host on a podcast if I didn't appreciate the level of positivity or the general approach that you bring to thinking about stuff. +STEPH: Okay. Well, to borrow a phrase from Matt Sumner, who has been a guest on the show, cool, cool, cool, cool. I'm glad my positivity has been well calibrated. And I was about to say I'm interested to hear how this turns out for the team. [laughs] But we're in an awkward spot where I mean, you and I, we can still totally chat. But listeners won't get to hear the rest of that particular saga. I mean, you can share. I mean, you do you. I'm setting all sorts of boundaries for you right now. +Okay. And now I'm just rambling, and I'm getting weird with it. Because the truth is that, you know, we won't be back. And this is our final episode together. So I think let's just go ahead and rip off the Band-Aid. Let's dive into it. Let's talk about it. Given that it's our last episode that we are recording, we thought of a couple of things that we'd like to talk about. You brought up a great idea that I'm excited to dive into. Do you want to lead us in? +CHRIS: Sure. Well, if we go back all the way to Episode 172, that is the first episode that you came on as a guest. I actually continue to really love the title of that episode, which is What I Believe About Software. And it both captured that conversation really well, but also, more generally, it's actually become the tagline of the show when we do our little introduction. What do we believe about building great software? Et cetera. +And I think that's been the throughline of the conversations that we've had is what remains true. What are the themes? Not necessarily the specific technologies, although we certainly talk about that. But what do we believe about building great software? And so today, I thought it would be fun for us to talk about what do we still believe about building great software? It's roughly three and a half years or so that we've been doing this. What's still true? +STEPH: Oh, well, I have the first unequivocal one, the thing that I still believe about building great software, and that's you should hire thoughtbot. That's definitely the way to go. We'll help you get it done, not that I'm biased in any way. +CHRIS: No. I'd say collectively between us; there's zero bias with regard to thoughtbot or any other web development shop out there. But thoughtbot is the best. +STEPH: All right, perfect. So we've got the first one, the clutch one of hire thoughtbot. And then I also really like this topic. And I still think back to that first episode that I recorded with you and how much fun that was and how that really got me to start thinking about this. Because it was something that, at the time, I didn't really reflect on a lot in terms of what does it take to build great software? I was often just doing the day-to-day actions but then not really going high-level think about it. So I'm excited this is one of the topics that we're revisiting. +So for the next one, this one is, I don't know, maybe it's a little cutesy, but I was trying to think of an alliteration that I enjoyed. And so this one is be an assumption assassin. So what assumptions are you making? And then how can you validate or disprove them? And that is something that I find myself doing constantly. And it always yields better work, better questions, better software, better code, better code reviews. And that's my first one is be an assumption assassin and identify what assumptions you have. +And I had a really good example come up today while I was having a conversation with Joël about something that I was looking to merge. But I was a little hesitant about it because there are some oddities that I won't dig in too deeply. But essentially, there's a test that I migrated that highlights an existing concern in the code. And I was like, should I go ahead and merge this test that documents it, or should I wait to fix that concern and address it? +And he brought up a good point. And he's like, "Well, we're assuming it's a bug and an issue, but it may not actually be depending on how the software is being used." And so then he was encouraging me to reevaluate that assumption that I had where I'm like, oh, this is definitely a problem to, like, I don't know, is it a problem? Let's ask somebody. +CHRIS: First off, I love that as a theme, as one of the things that you still believe about software. Second, I believe you correctly said that you were looking for an alliteration, but my brain heard acronym. +STEPH: [laughs] +CHRIS: And so then I was like, B-A-A-A. Is it BAAA? What are you going for there? Oh, you just wanted a bunch of As. Okay, I got it now. Secondly or thirdly, I think I'm on my third now. Apparently, within Sagewell team culture, one of the things that I'm most known for is... there are two phrases: one is just to name it, and the other is to be clear. And these are the two things that I do apparently constantly so much that it's become a meme within the team. +It's just like, okay, everybody's been talking. But I just want to make sure we're on the same page here. So just to be clear, or just to name it, here's what I'm seeing. But I agree; I think taking those things...what are the implicit bits? What are the assumptions? And making them more explicit. Our job as developers is just to yell at computers all the time and make them try and do human stuff. And there's so much room for lossy conversions at every point in that conversation chain. And so yeah, being very clear, getting rid of assumptions, love it. It's all great stuff. +Actually, in a very related note, the first on my list is that code is for humans to read. This is one of the things that I believe most deeply and most impacts the way that I write software. Any given piece of functionality that we want to author in our code feels like 10, 20, 50, frankly, almost infinite different versions of the code that would produce nearly identical functionality. So at the end of the day, the actual symbols and strings of text that we bring together to write the code is all about other humans, other people on your team, you five months from now, you a week from now, frankly, or me. I'm going to say me, me a week from now. +I want to do future me and everyone else on the team a solid and spend that extra 10% of okay, I have something that works now, but let me try and push it around and try and massage it into a shape that is a little more representative of how we're actually thinking about the code, how we talk about it as an organization. Is that the word that we use to describe that domain concept? Maybe we could change that just a little bit. Can I push more of this into the private API? What actually needs to be known here? +And I think that's where I'm happiest is in those moments because that's where all of the parts of the job come together, the bit where I trick a computer into doing what I want and simultaneously making it so that that code is revisitable, clear, expressive, all of those things. So yeah, code is for humans. And that's true across every language, and framework, and domain that I have worked in. And I've only believed it more and more so over time. So yeah, that's mine. +STEPH: Yeah, I love that one. That's one of the things that comes to mind when people talk about disliking code reviews. And I can imagine there are a number of reasons that people may have had a poor experience with a code review process. But at the end of the day, if you're not getting that feedback or validation from fellow humans, then how do you know that you've been successful, that you've written something that other people can follow up on? Which goes back to the assumptions in terms of like, you're assuming that you have written something that your future self or that other people are going to be able to read and maintain down the road. So yeah, I love that one. +One of the other things that I still hold really true to building great software is prioritize early and often. So always be checking in to understand with your users, with your tech concerns, with data that you may have, new insights, and then just confirm that yes, you and the team are constantly working on the thing that has been prioritized and that is the most important. +And also, be ready to let go. That can be really hard. I have definitely had those moments in my career where I've spent two weeks working really hard on something. And then we've realized that the thing that we were pursuing isn't that valuable, or it's something that users don't need or actually want. And so it was better to let go of it than to pursue it and ship it anyways. So that's one of my other mantras that I have adopted now is prioritize, prioritize, prioritize. +CHRIS: Unsurprisingly, I agree wholeheartedly with all of that. We're still searching for that thing, that core thing that we disagree on other than Pop-Tarts and IPAs. But I don't know that today is the episode that we're actually going to find that. But yeah, prioritizing is such a critical activity. And it is this interesting collaboration point. It gets different groups together. It's this trade-off. It's this balance. And it's a way to focus on and make explicit the choices that we're making. And we're always making choices. We're always making trade-offs. And so being more explicit, being more connected and collaborative around those I believe in so, so, so much. So love that that was something on your list. +Let's see, next up on my list is reduce complexity, just sort of as an adage, just always be reducing complexity. It is amazing to me in my time, particularly as a consultant, but even now, this is something that I hold very true is just it's so easy to grow a system in anticipation of future complexity or imagine that the performance concerns that we're going to run into will be so large that we must switch from Postgres and a nice, simple atomic database into a sharded, clustered Kafka queue adventure. And there are absolutely cases that make sense for that sort of thing. +But at a minimum, I beg of you, anyone starting a new system, don't start with microservices. Don't start with an event queue-based system. These are wildly complex versions of what often can be done with so much simpler of an application. And this scales through to everything. What's the complexity of an API? Do we need caching in that API layer? Or can we just be a little bit inefficient for a little while and avoid the complexity and the overhead of caching? +Turns out caching is a tricky thing to get right, just as an aside. And so the idea of like, oh, let's just sprinkle in a little bit of caching. It'll be easy, and then we'll get better performance, like, yeah, but did you get it right? Or did you introduce a subtle bug into your program that's going to be really hard to debug later? Because do you cache in development? Well, maybe, I'm not sure, could be. +So over time, this is something that I've sort of always felt, but I've only ratcheted it up. It's only something that I've come to believe in more and to hold more firmly to. I think earlier in my career, it was something that I felt, but I would more easily be swayed by aspirational ideas of the staggering amounts of traffic that we would be getting soon or the nine different ways that the data model will expand. And so, we should code the current version in anticipation of that. And I have become somewhat the old man on his lawn yelling at the clouds like, "Nah, we don't need it yet. We can grow to that." +And there's a certain category of things that are useful to try and get out in front of and don't introduce additional complexity, but they're a tiny, tiny list. And so, for most things, my stance is what's the simplest thing that we can get away with right now, that still provides a meaningful experience to our users, that doesn't compromise on security or robustness or correctness but just solves the problem we have right now? And over and over and over again, that has served me incredibly well. So yeah, keep that complexity at bay. +STEPH: That is one that I've definitely struggled with. And frankly, it works in my favor, that idea of keeping things simple. Because I'm terrible when it comes to predicting the future or trying to build things in a way that I just don't have enough information to really drive the architecture or the application that I'm building. So anytime I'm trying to then stretch and reach for the future in those ways unless I really have a concrete understanding of I am building for these particular scenarios, it's really hard to do. So I very much like keeping it simple and not optimizing before you need to. +And it reminds me of I think it's Mark Twain, who has a quote, "Worrying is like paying a debt that you don't owe." And that's something that comes to mind for me when also writing code and building features and software is that I tend to be someone who will worry about stuff. And I'm like, oh, is this going to be easy to extend? Is it going to be what it needs to be six months from now if we need to add more features to this and build on top of it? And I have to remind myself it's like, well, let's just wait. Let's wait till we get there and we know more. +One of my other ideas that couples nicely with the one that you just shared in regards to keeping things simple and then waiting for those needs to arise is that mistakes are going to happen. They are a part of the process. As we are learning and growing and we're stretching our skills and trying things out, things are going to go wrong. We're going to introduce bugs. And to take those opportunities, that's when we start to use that feedback to then improve things like observability, like capturing logs, and how we handle error reporting or having a plan for emergencies. +So maybe that's the part of worrying that can pay off is thinking through, all right, if something does break, or if something gets shipped that shouldn't, then what is our plan in how we handle that? How do we roll back? Or how do we get things back to a stable build? +CHRIS: It's funny. I was actually visiting with a friend this past weekend, and we were chatting more generally about life things but the idea of worrying and anticipation and trying to prepare for every bad outcome. And there's the adage of an ounce of prevention is worth a pound of cure. But increasingly, both in life, depending on the context, and in code, I've found that I've shifted to the opposite of it's impossible to stop everything. +There are going to be bugs that are going to get out there. There are going to be places where we code things incorrectly. And I would rather...I still want to try as hard as I can to get things right, to be clear. I'm not giving up on trying. But I'm all the more focused on how do we know and how do we recover when those things happen? So it's interesting that you just described exactly that, which, again, is a very human life conversation, and yet it applies to the code. +STEPH: I love that rephrasing of it. Instead of the mistakes are going to happen, it's, like, how do we know, and how do we recover? I think that's perfect. I've also found that by answering the how do we know and how do we recover, that really helps you build trust with clients as well. Because again, things are going to happen, things are going to break. +And the more prepared you are for that and then the better plan that you have, and then they can watch how you execute that plan, and it’s going to establish a lot of deep trust with other engineers and also the team that you're working with, that you have been thoughtful and that you have ideas on how are we going to address this? Instead of waiting for that moment to happen. +That's going to happen too. You're going to make decisions in the heat of the moment. But I have found that to be a really useful way to establish yourself with a team in terms of I care about this team and these processes and this application. So how do we handle the bad times, not just the good times? +I do want to circle back because you alluded to the fact that you and I, we've tried to find things that we disagree on. And so far, Pop-Tarts and beer have been the two things that we disagree on. But I do have a question for you that maybe I will disagree with you on. But I need to know some more about it first. +You have alluded to there's the Brussels snack, (Oh, I'm going to get this wrong.) Brussels sprout snack hour or working lunch, something combination of those words. [laughs] And it's the working lunch that has stuck out to me, and I've wanted to ask you about it. So here I am. I'm asking you about it. What's a working lunch? What's the Brussels snack happy hour, snackariffic working lunch look like? +CHRIS: This is fantastic. I love that you waited until the last episode that this was rolling around in the back of your head. And you're like, are you making the team work through lunch? And now, on this final episode, we get to address the controversy that has been brewing in the back of your head. Spoiler alert, no, this is just ridiculous nomenclature. These are two meetings that we have that are more like, let's get the dev team together and talk about stuff that's in our platform sort of developer experience. Or stuff in observability often is talked about in this context because it doesn't quite impact users, but it's how we think about the work. +And so there are two different meetings that alternate every other week. So every Friday afternoon, we do this, but it's one of two meetings depending on the day. So there's a crispy Brussels snack hour that was the first one that was named, which was named purely for nonsense reasons because we don't have anything else that's named nonsensically in our organization. +And so I was like, oh when we name this meeting, we should make it nonsense because we don't have any other...We don't have, you know, an SOA microservices fleet with Barbie doll and Galactus and all of the other wonderful names. Those are references to the greatest video ever about microservices; if you've not seen it, that will be in the show notes. It's required reading. +But anyway, we don't have that. And so we thought, let's be funny with the name of this. So the crispy Brussels snack hour is one, and the crispy Brussels we wanted something that was...the first one is a planning meeting. The second is like, let's actually sort of ensemble program. Let's get the four of us together, and we'll work on some of the stuff that we're talking about here but as a group. And so I wanted the idea of we're working, and so I was like, oh, this will be the crispy Brussels work lunch. But it's purely a name. It's the same time slot. It's 3:00 o'clock on a Friday afternoon. [laughs] +So it is not at all us working through lunch. I don't think we should work through lunch. I'm concerned that you thought that for a while, and you were just like, I'm a little worried, but I'm not going to bring it up. But I'm glad we got to cover this before we wrapped up this whole Bike Shed co-hosting adventure together. +STEPH: I feel relieved and also a little robbed of an opportunity for us to have something that we disagree on because I thought this might be a thing. [laughs] +CHRIS: We can continue searching for that thing. But maybe it's okay that we agreed on most stuff for the run [laughs] of this fun, little show that we did together. +STEPH: Yeah, that's gone on quite a time. We've got like three years together that we have managed to really only find two, I mean, very important of course, two things. But yeah, it's been pretty limited to those two areas. And each time that you'd mentioned the work lunch, I was like, huh, I need to ask about that because I have feelings about it. But then, you always would dive into very interesting stories of things that came out of it, and I quickly forgot about it. +So this feels good. This feels like very good important closure. I'm glad that this finally surfaced. But circling back, since I took us on a detour for a little bit, what are some other things that you still hold deeply about building great software? +CHRIS: I've really got one last thing on the list. It's interesting, there's not a ton technically in this list, which I think represents broadly how I feel about software, and I think how you feel about software. It’s like, it's actually mostly about how the people interact at the end of the day. And you can program in any language or framework, and you can get the job done. We certainly have our preferences and things that we enjoy. +But the last one really rounds us out, which is think about the users. I always want to be anchoring the conversations that we're having, the approach that we're taking to building the software in what do the users think? Who are our users? What do we know about them? What do they care about? How are they using this technology? How is it impacting their lives? We've talked a number of times about potentially actually watching the sales demo as an engineering team, trying to understand what's the messaging that we're putting out into the world for this piece of software that we're building? +Or write along with customer support and understand what are the pain points that people are hitting? And really, like, real humans, what are they experiencing? Potentially with a name attached. And that just changes the way that you think about the software. There's also even the lower-level version of it. As we're building classes or modules, what are the public facets of that, and what are the private API? What's the stuff that we're hiding away? And what's the shape that we are exposing to the outside world for varying definitions of outside? +And how can we just bring in a little bit of empathy to try and think about, again, in the case of like the API for a class, it's probably you on the other side of it, but it's future you in a slightly different mindset with a little bit less information and context on the current problem that you're working on. And so, how can we make things easier for ourselves in the code, for our users at the end of the day? +How can we deliver real value that is not mired in the minutiae of technical complexity and whatnot but really is trying to help people live better lives? That's a little too fancy as I say it out loud. But it is kind of the core of what I believe, so I'm not going to take it back. +STEPH: I love how you've expanded users where more traditionally, it's people that are then using the software. But then you've expanded it to include developers because that is something that is often on my mind and something that I just agree with wholeheartedly in terms of when you're writing software; as you mentioned before, software is for people. And so we want to include others. +And it does improve people's lives. People show up to work every day, and if you've been thoughtful if your past you has been thoughtful, it's either going to give you your future self a better day, or it's going to give other people a better day. So I think that's a very fair statement, improving lives by being thoughtful in regards to focusing on the users, people consuming software, and working in the codebase. +CHRIS: I know we've talked about this before, but I was having a conversation with one of the developers on the team at Sagewell just last week, and they were mentioning how they really loved working on admin features. And I was like, oh, that's interesting. Let's talk more about that. And it was really it's that same thing that I think you and I have discussed of like there's that immediacy. There's that connection. These are actually colleagues, but you can build software to make their day better. You can understand in detail what the pain points are. +What's the workflow that as you watch it, you're like, oh, I could put a button up in the corner of the screen that would automate almost all of this and your day would be that much faster? Oh, let me do that. That's exciting. And so I love that as another variation of it, like, yeah, there's for other developers. There's also for the admin team or other users in the organization of the software. There are so many different versions of users, but I think I think we build a better thing if we think about them more. +STEPH: I have definitely worked with teams where I can tell that certain people are demoralized, and it comes down to they feel frustrated and often disconnected from the people that they are building for. And so then you really feel isolated. I'm pushing code around, but I don't really see the benefit or the purpose of it. And I think that's very hard for developers who typically want to build something that's going to be useful and not feel like it's just going to be thrown away. So connecting your team to those users, I certainly understand. Getting to build something for your colleagues and then they get to say how much they like it is an incredible, rewarding experience. +You also touched on something that I really appreciate, where you highlighted that a lot of the technical decisions that we make are important, but they're not at the center of the things that we believe when it comes to building great software. And that's something that I will often reflect on. Like, as we were thinking through these particular ideas that we still hold true today, how mine are more people and process-focused and rarely deep in the technical weeds. And there are times that I think, well, shouldn't there be something that's more technical, something that's very concrete? Yes, you should build your code this way or build your application or use a specific technology. +But after all the projects and teams that I've been a part of, that's just usually not the most important part. And so I appreciate that you highlighted that because sometimes I have to remind myself that, yes, those things can be challenging, but it's often with people and process. That's where the heart of great software lies. +CHRIS: That's a fantastic phrase, I think, that really encapsulates all of the conversations that we're having here. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half. +So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +CHRIS: Actually shifting gears a little bit, so we've just talked about what we still believe about building great software. I'm intrigued. We've been chatting for a number of years here on this microphone, these microphones. We have separate ones because we're in different states. But I'm interested; what have we changed our minds about? What have you changed your mind about, Steph? I got a couple of ideas, but I'm intrigued to hear yours. +STEPH: Nothing. I've never been wrong. I've stuck to everything that I've ever thought. +CHRIS: That must be boring. +STEPH: [laughs] Yeah, that's totally not true there. There are definitely things that I've changed my mind about. One of the things that I've changed my mind about is that people who know the most will ask the fewest questions. That's something that I used to consider the trademark of someone who is a more experienced senior developer in terms of you really know what you're doing. And so you typically don't ask for help or need help very often. And so, I'm going way back in terms of things that I have changed my mind about. +But I have definitely changed my mind where people who know the most are actually the ones that do a really great job of constantly asking questions and asking for feedback. And I think that is still a misconception that people still carry forward. The idea that if you're asking a lot of questions or asking for help that you are not as skilled in your work, and I view it as quite the opposite, that you are very good at what you do and that you know precisely the value of your time. +And then also reaching out to others for help, and then also just getting validation on things that you may have concerns around. So that's one I've changed my mind on is that I think the more experienced you are, the more questions you tend to ask. +CHRIS: Oh, I love that one. It's a behavior that I know...I think we've talked about this before. But as consultants, we try and model it just the like; it's totally fine to ask questions. And because we often come in with less context, it makes sense for us to be asking questions, but I will definitely intentionally lean into it in those contexts to be like, everybody keeps throwing around this acronym. I don't actually know what that is. Let me raise my hand. +And my favorite moment is when people disagree on what the acronym or what the particular word or what the particular project is. Like, I ask the question, and people are like, "Oh, it's this," and someone across the room is like, "Wait, that's what it means? I thought it was this totally other thing." I'm like, cool, glad that we sorted that out. Glad that we got that one up in the air. +But I actually remember many, many, many years ago, at this point, there was a video series of...PeepCode was the company, and there was the Play by Play series. And so there were particular prominent developers, particularly in the Ruby community. And they would come and sort of be interviewed and pair program. And it was amazing getting to watch these big names that you had heard of, like Yehuda Katz is the one that stands out in my mind. He was one of the authors of merb, which was a framework that was merged with Rails, I want to say around the 3.0 time. +And just an absolute, very big name in this world and someone that I looked up to and respected. And watching this video, they had to Google for particular API signatures and Rails methods. They were like, "Oh, how does that work? Is it link to and then you pass the name?" I forget what it was specifically. But it was just this very human normalizing moment of this person who has demonstrably done incredible work in our community and produced very complex software still needs to Google for the order of arguments to a particular method within Rails. I was like, oh, okay, that's good to know. +And with complete humility in the moment, I was just like, yeah, this is normal. Like, it's impossible to hold all of that in your head. And seeing that early on shook me off the idea that that's the thing to do is just memorize everything. It's like no, no, get good at asking the questions. Get good at debugging. Get good, yeah, asking questions. It's a core skill rather than a thing that you grow out of. But I definitely shared early on I was like, not allowed to ask questions, that'll be scary. +STEPH: I love that example. Because counterintuitively, to me, it demonstrates confidence when someone can say, "Oh, I don't remember how this works," or "Let me go look it up." And so I just very much appreciate when I see someone demonstrating that level of confidence of let's keep going. Let's keep making progress. I'm going to ask for help because that is totally fine, and we are in a safe space. Or I'm going to create a safe space for us to do that. +One of my favorite versions of this where you shared like if you ask about an acronym and then people disagree, one of my favorite versions is to ask about a particular area of the codebase and be like, what would you say this code is doing here? What do you think users do here? Like, what is the purpose? What's the point of this? [chuckles] And then having people be able to say, "Oh, yeah, this definitively does this thing." Or people are like, "You know, I'm not sure. I don't even know if that code is getting run." That's one of my favorite outcomes of asking questions. How about you? What's something you've changed your mind about? +CHRIS: I made a list of a couple of things like remote is on there. I didn't know if I'd like remote. I wanted to try it for a while. Tried it, turns out I like it a lot. It's complex. You got to manage it, whatever. But that I think everybody's talked about that a bunch. +I think probably the most interesting one is deadlines. Initially, in my career, I didn't really feel anything about them. And then I experienced the badness of deadlines. Deadlines are bad. Deadlines are things that come down from on high and then you fail to hit them, and then you're sad. And maybe along the way, you're very stressed and work long hours to try and get there. But they're perhaps arbitrary. And what do they even mean? And also, we have this fixed scope, and they're just bad. And then there was a period of my time where, like, deadlines are bad. The only thing that we do is we show up, and we make the software as quickly as we can. +But in reality, there are times that we need that constraint. And in fact, I have found a ton of value in deadlines when used intentionally. So we can draw a line in the sand, and we can say, at this point in time, we will have a version of the software. We have a marketing campaign that we need to align with this. So we got to have something at that point. And critically, if you're going to have a deadline, you've now fixed a point in time. You need to flex other things. +And critically, I think the thing to flex is the scope. So we need to have team management. We have user accounts right now, but now we need to organize them into teams. That is like a category of functionality. It's not a singular feature. And so yeah, we can ship teams in the next quarter. What exactly that means is up in the air. +And as long as we're able to have conversations essentially on a day-to-day at least weekly cadence as to what will make it in by that deadline and what won't, and we're able to have sometimes the hardest conversations but the very necessary conversations of the trade-offs that we have to make as we're building that software, then I find deadlines are absolutely fantastic tools for focusing and for actually reducing scope but in a really useful way. +And getting something out there in the hands of users so that you start to get real feedback so that you start to learn, is this useful? What are the ways that people are using this? What should we lean into and do more of? What maybe should we roll back, actually? So yeah, deadlines. First, I didn't know them, then I feared them. Now I love them but only under the right circumstances. It's a double-edged sword, definitely. +STEPH: I, too, have felt the terribleness of deadlines and railed against them pretty hard because I had gone through a negative experience with them but have also shifted my feelings about them where they can be incredibly useful. So I really liked that's one of the things that you've changed your mind about. +It also reminds me of one of the other things...I'm going to circle back for a moment to one of the things that I believe about creating great software is to not wait for perfection, and deadlines are a really good tool that helps you not wait for perfection. Because I have also seen teams really struggle or sometimes fail because they waited until there was something perfect to present, and then you realize that you've built the wrong thing. +So I do want to transition and talk a bit about the show because it's our last episode, and we should talk about it, and the fun adventures that we've had and some of the things that we've learned or things that we're feeling in the moment. So given that it's been a wonderful three years for me, it's been four years for you since you've been a host on the show. How are you feeling? +CHRIS: I'm feeling a bunch of different things sort of all at once. I am definitely going to miss this immensely. Particularly, I loved when I started, and I got to interview a bunch of thoughtboters and other people from the community. But frankly, three-plus years of getting to chat with you has been just such a delight. There's been an ease to it. We kind of just show up and talk about what we're doing. And yet there are these themes that have run through it. And it has definitely helped me hone and shape my thinking and my ability to communicate about what I'm thinking. +I've learned that you have a literal superpower to remember the last thing that you were talking about. Listeners, you may not know this, but we are not quite the put-together folks that we may sound like in these recordings. We have a wonderful editor, Mandy Moore, who makes us sound so much better than we are. But we'll often pause and stop and then discuss what we want to talk about next. And Steph always knows the exact phrase that she or I left off on. And it has been so valuable to the team. +But really, it's been just such a pleasure getting to have these conversations. It's also been something that has just gently been in the back of my mind at all times. And so, I'm observing the work in any given week as I'm doing it. It's almost like meditation in a certain way, whereas I'm working on something, like, oh, this is actually really cool. I want to take a note about this and talk about it on The Bike Shed with Steph. +And having this outlet, having this platform to be able to have those conversations and knowing that there are people out there is fantastic, although it's very weird because really, every one of these recordings is just you and I on a video call. And so there is an audience, I'm pretty sure. I think people listen to the show; I don't know, occasionally they write in, so it seems like they do. But at the end of the day, this really just feels like a conversation with a friend, and that has been so valuable to have. And yeah, I'm definitely going to miss that. +It's been a wonderful run, you know, four years is a long time. It's about as long as I've done most things in my career. And so I'm very happy with what we have done here. And there's a trite saying that isn't...yeah, whatever; I'll just say it, which is, "Don't be sad that it's over. Be glad that it happened." And I guess I'm still going to be sad that it's over. But I am so glad that I got the opportunity to do this, that you joined in this adventure and that we got to chat each week. It's been really delightful. +STEPH: I really liked how you refer to this as being a meditative state. And that is something that I have certainly picked up from you and thoroughly enjoyed that I have this space that I get to show up and bring these ideas and topics and then get to talk them out with you. And that has been such a nice way to either end the week or start a week. I mean, it doesn't matter. Anytime that we record, it's this very nice moment of the week where we get to come together and talk through some of the difficulties and share our stories. +And that's been one of my favorite moments is because you and I get to show up and share everything that's going on. But then when someone writes into the show or if they send a tweet or something and they share their story or their version of something that happened, or if they said that we made them laugh, that was one of my favorite accomplishments is the idea that something that we have done was silly enough or fun enough that it has brought them joy and made them laugh. So I, too, I'm very, very much going to miss this. It has been a wonderful adventure. +And I thank you for encouraging me to come on this adventure because I was quite nervous in the beginning. And this has definitely been an aspect of my life that started out as something that was very challenging and stretching my limits, and now it has become this very fun aspect and something that I get to show up and do and then get to share with everyone. And I do feel very proud of it, very much in part to Thom Obarski, who was our initial producer and helped us have that safe space to chat about things. And now Mandy, who keeps the show running smoothly and helps us sound our best week to week. +So it's been a wonderful adventure. This is going to be hard to let go. And I think it's going to hit me most. Like, this was one of those things as we're talking about it, it's, like, I'll see you next week. This will be fine. But I think it's going to hit me when there's something that I want to talk about where I'm like, oh, this would be great to talk about, and I'll add it to The Bike Shed Trello board. And I'll be like, oh yeah, that's not a thing anymore, at least not quite in the same way that it was. +CHRIS: So what I'm taking away from this is that you're immediately going to delete my phone number the minute we hang up this call and stop recording. [laughs] +STEPH: Oh yeah. I preemptively deleted. So that's already done. Friendship is over at this point. +CHRIS: That's smart. Yeah, because you might forget otherwise in the heat of the moment as we're wrapping this whole thing up. +STEPH: [laughs] +CHRIS: But actually, on that note, in a slightly more serious vein, again, there's this weird aspect where the audience is out there. But we're very sort of disconnected, particularly at the moment in time where we're recording. But it has been so wonderful getting various notes from listeners, listener questions, but also just commentary and the occasional thanks and focusing; oh, you pointed me in the direction, or you helped me think through a complicated piece of work or process a problem that we were having. And so that has been just so, so rewarding. +And one of the facets of this that has been so interesting to me is being able to connect to people and basically put out there what we believe about software, and for the folks that resonate with it and be able to have that connection instantly. And meeting people, and they're like, "Oh, I've listened to The Bike Shed. I like all these things." I'm like, oh, cool, we get to skip way further into the conversation because I've already said a bunch, and you say you like that thing. So, cool, we're halfway through our introductory chat. +And I know that we agree about a bunch of things, and that's really wonderful. And frankly, I'm going to miss that immensely. So for anyone out there who's found something valuable in this, who's enjoyed listening week to week, or perhaps even back to Upcase for things, I would love to hear from you. I'd love to connect to folks. Send me an email, Twitter. I'm on all the places. I'm Chris Toomey in various spots or ctoomey.com on the internet. Chris Toomey on GitHub. I'm findable, I think. Chris Toomey developer will probably get you there. +But I would really love to hear from folks, to connect to folks, you know, someday down the road; I think I'll be hiring again. And that'll be fun. I would love to work with some of the folks that have listened to this show or meet you at a conference, or if I happen to be traveling to a city or you're traveling to Boston. Really for me, so much of what this show is about is connecting with people around how we think about building great software. And so, I would love to continue that forward into the future. So yeah, say hi, if you're interested. +STEPH: I agree. That's been one of the most fun aspects of being co-host of the show. And I'll be honest, you are welcome to contact me, but I am going to be off-grid for probably six months. [laughs] So just know that there will be a bit of a delay before you hear back from me. But I would definitely love to hear from you. +I also want to say a very heartfelt thanks to a couple of people, just folks that have made this journey incredible and have made it so much fun. One, in particular, is everyone at thoughtbot for their continuous stream of knowledge. I mean, frankly, my software opinions wouldn't be half as interesting if it wasn't for everyone at thoughtbot constantly sharing their knowledge and being a source of inspiration. So I deeply appreciate everyone that has contributed to topics and ideas and just constantly churning out blog posts because those are phenomenal. +And I also want to give a shout-out to my husband, Tim, because he has listened to The Bike Shed for many years and even helped out with a number of show notes when that was something that you and I used to do before Mandy made our life so much easier and took that over for us. And has intervened a number of times when Utah mid-recording would decide it's time to play. So I want to give a very special thank you to him because he has been a very big supporter of the show and frankly helped me manage through a lot of the recordings for when I had an 80-pound dog that was demanding my attention. +CHRIS: I think continuing on the note of thanks; similarly, I'm so grateful to thoughtbot as an organization for everything that is represented in my career. It's a decade-plus that I have been following and then listening to the podcasts and then joining the organization, and then getting so many wonderful opportunities to learn about this thing called web development. And then, even after I left the organization, I was able to stay on here on The Bike Shed and hang out and still chat with you, Steph, which has been really wonderful. So thank you, thoughtbot, so much. +Thank you to Joël Quenneville, who will be the continuing host of the show. This show is not going anywhere. And, Steph, you and I aren't really going anywhere, but we won't be around anymore. But we are leaving it in the very, very capable hands of Joël, and I'm super excited to hear the direction that he takes it and Joel's incredibly thoughtful and nuanced approach to thinking about programming and communicating. So I think that will be really wonderful. +And lastly, I definitely want to thank Derek Prior and Sage Griffin, the two original hosts of this show, who really produced something wonderful, and for many years, I think it was about four years that they hosted together. I was an avid listener despite actually working at the company the whole time and really loved the thing that they produced and was so grateful that they entrusted me with continuing it forward. +And hopefully myself and then with the help of you along the way, we've...I think we've done an okay job, but now it is time to pass the torch or the green lantern. That's the adage I've been going with. Gotta pass the lantern, pass the mantle on to the next one. So, Joël, it's going to be in your hands now. +STEPH: Yeah, I'm so looking forward to future episodes with Joël Quenneville. They are going to be fabulous. +So I've been thinking in terms of this being our finale episode and then a fun ending for it, so there's a thing called the 21-gun salute, which is the military honor that's performed by firing cannons or artillery. Not to be confused with the three-volley salute, which I definitely confused earlier that is reserved and used at funerals, which this is not. So using the 21-gun salute, I was like, hmm, it is The Bike Shed, and we have this cute ring ring that goes. So I think for our finale, we should have a 21-bell salute as we exit the shed and right off into the sunset. +CHRIS: I love it. I couldn't imagine a more perfect send-off. So with that, what do you think? Should we wrap up? +STEPH: Yes, but I have one more silly thing to add. I've thought of a new software idiom that I'm excited about. And so, this may be my final send-off into glory that I'd like to share with you. And I think that we should make like a shard and split. +CHRIS: [laughs] I so appreciate that in this moment, this final moment that we have together, you choose to go with a punny joke. It is so on brand for the show. It is absolutely perfect. And I think with that note, shall we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + It's Steph and Chris' last show.

+ +

Steph found a game, and if you've been following the journey, all of the Test::Unit test files are now live in RSpec. JWTs really grind Chris' gears.

+ +

They wrap up with things they've learned, takeaways they've had, and their proudest podcasting moments. They also thank all the folks who've helped make The Bike Shed happen.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Microservices

+ +

Transcript:

+ +

CHRIS: One more round of golden roads, our golden. So here we go.

+ +

STEPH: Oh, one more round of golden roads. Okay, maybe that's going to get to me today. [laughs]

+ +

CHRIS: [singing] Golden roads take me home to the place.

+ +

STEPH: [singing] I belong.

+ +

CHRIS: Yeah, there you go.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together we're here to share a bit of what we've learned along the way, at least one more time. So with that [chuckles] as an intro, Steph, what would you say is new in your world?

+ +

STEPH: Hey, Chris. Well, today is the big day. It is the day that you and I are recording our final Bike Shed episode, which we have all the feels about, and we will definitely dive into. But to ignore some of that for now, I have another small fun update I can provide about a new game that I found. So one of the things that's new in my world is I started playing a new board game with Tim; it's called Ticket to Ride. Have you heard of that?

+ +

CHRIS: I have. I don't know if I've played it. I feel like it's a particularly popular one now. But I don't know if I've ever had the pleasure.

+ +

STEPH: It's a very cute game, so we have the smaller version of it. For anyone that's not familiar, it's essentially a map. And then there's a bunch of spots where you can build trains and connect them, and then you get tickets. So your goal is that you're going to connect one location to another location. And then you get points and yada yada, but it's so much fun and especially the two-player version. It's like this perfect 20, maybe 30-minute game.

+ +

I'll be honest; I'm not really a board game person. I always enjoy it. Once I get into it, then I'm like, this is great. I don't know why I was resistant to this. But every time someone's like, "Do you want to play a board game?" I'm like, "Not really." [laughs] I first have to get into it. But I have really enjoyed Ticket to Ride. That's been a really fun game to play. And it's been a nice way to, like, even during the day, we'll break for lunch and squeeze in a game.

+ +

CHRIS: Well, I love good two-player games. They're hard to find. But when you find a good one, and it's got that easy pickup and play...I believe I'm going to now purchase this. And thank you for the tip.

+ +

STEPH: Yeah, this is definitely one of those where it's easy to pick up, and then you can get the expanded board. So there's a two-player version, but then yeah, you can get one that's a map of the U.S. or a map of Europe. And I think it accommodates up to five players as the maximum, so not a huge group but definitely more than two.

+ +

On a slightly more technical note, I have something that I'm very excited to share. It is a journey that you have been on with me, that everybody listening has been on this journey with me. And I'm very excited. I see you nodding your head, so I'm guessing that you're going to know where I'm headed with this. But I'm very excited to announce that all of the Test::Unit test files now live in RSpec. So that is a big win.

+ +

I'm very, very excited for that to be a previous state of life and not an ongoing state of life. Because I have certainly developed too much niche knowledge around migrating these tests, and that became apparent to me when I was pairing with another developer that works with the client because they had offered...they had some time. They're like, "Hey, do you want help migrating a test file?" And I was like, "Sure." I was like, "But this is wonky enough, like, we should pair and work on this together because I just know some ins and outs. And I don't want you to have to learn a lot of the hard lessons that I've learned."

+ +

And the test that we happened to pick up was very gnarly. It had a lot of mystery guests. And we spent, I think it was a good two hours. And we only migrated one of the tests, so not even a full file but one of the tests. And at the end of it, I was like, I know way too much about some of the oddities and quirkiness of this. And we got through it, but we decided that wasn't a good use of their time for them to go at this alone. So that's why I'm extra excited and relieved because I didn't want this task to carry on to someone else. So, hooray, we did it.

+ +

CHRIS: Hooray. Just in time. You're Indiana Jones grabbing your hat right as you roll out and off to [laughs] be away from the project for a bit. So you stuck the landing. Well done, Steph.

+ +

STEPH: Thank you. Thank you. So that's some great news. And then also, everything else in life is pretty much focused around getting ready for maternity leave. That's about to happen soon, and I am so ready. I have thoroughly enjoyed a lot of the things that I'm doing, [laughs] but goodness, being pregnant is hard. And I am very much ready for that leave.

+ +

So also, a lot of the things that I'm doing right now are very focused on making sure everything's transitioned and communicated and that I just feel really good about that day of departure. That covers all the newness in my world other than the big thing that we're just not talking about yet. How about you? What's new in your world?

+ +

CHRIS: Well, continuing to skirt the bigger topic that we will certainly get to in the episode, what is new in my world? I'm actually quite excited workwise right now. We have a much larger body of work that finally we got the clarity. All the pieces fell into place, and now we're sort of everybody rowing in the same direction. There's interesting, I think, really impactful code that we're writing for Sagewell right now. So that's really fantastic. We've got the whole team back together on the engineering side. And so we're, I think, in the strongest and most interesting point that I have experienced thus far. So that's all really fantastic.

+ +

On a slight technical deep dive, you know what really grinds my gears? It's JWTs. JSON Web Tokens and I have never gotten along. It's never been a match made in heaven. And we have a webhook that comes from Plaid. Plaid is a vendor for connecting bank accounts and whatnot. And they have webhooks like many people do. So they can inform us when things change, lovely feature of how we build web apps these days. But often, there's a signature that says, "This is definitively from us, and you can trust us." And usually, it's some calculated signature, HMAC, or something like that.

+ +

For some reason, Plaid's uses JWTs, and more than that, they use JWKs. So there's JWT which is the signature. That JWT itself is signed with a JWK. You have to fetch the JWK from their server based on the key ID in the header of the JWT. But how do you know if you can trust the JWT before you've gotten the JWK? All of this broke in a recent upgrade.

+ +

We went from Heroku-20 to Heroku-22 to the new platform with Heroku, which bumped us to OpenSSL 3.0, and it turns out JWT doesn't work with it. And so that's sad. It's a no. It's going to be a no. It turns out the way that OpenSSL 3.0 works is incompatible with some of the code paths in JWT. And so I was like, wait, we just can't do this? And it's low-level cryptographic primitive stuff that I'm not comfortable messing around with. I'm not going to hop in there and roll up my sleeves.

+ +

And even just getting to the point that I understood what was broken about this took like an hour and a half just to sort of like, wait, which is okay...so the JWT signs and encodes. And this will be a theme that we come back to later, but I think web development should be simpler. I think we should strive for simplicity. And this is a perfect example where I'm guessing Plaid uses JWTs and that approach to communicating security things often, but I've not seen it used much for signing webhooks. And, oof, it led to a complicated day. And it's unfixable now as far as I can tell.

+ +

There is a commit on the JWT Ruby repo as of five days ago, but it doesn't build in our system. And it's not released. And it's just a mess. So yeah, engineering is complicated. I'm both wildly excited about what we're doing at Sagewell, and then today was this local minimum of like, oh, JWTs again. Again, we find ourselves battling. And you won today, but hopefully not for too long.

+ +

STEPH: Oof, how did this manifest that you first noticed? So is it because a webhook suddenly stopped working, and that was like the error that rose up, and that's what helped you dive into it?

+ +

CHRIS: Yeah, we have a little bit of code in the controller for where Plaid events come in. We calculate and verify the signature of the webhook to make sure that it's valid, and we reject it otherwise. And we alert ourselves via Sentry, and then we also have a Datadog scan that can show what's the status code of the response. Because these are incoming HTTP payloads or requests, and so we can see there were 200 up until this magical day when suddenly everything changed. And that was when we switched Heroku stacks.

+ +

And then we can see it also in Sentry. So we're able to look at it, and we're like, why are none of the Plaid webhooks able to verify the signature anymore? That seems weird. And so then Datadog confirmed that it consistently was broken from this point in time. And then we were able to track that back. It was also pretty easy to guess because the error was "pkeys are immutable in OpenSSL 3.0," and that was the data. And I was like, oh, cool, that sounds fun. Let me go figure out what that means.

+ +

STEPH: [laughs] Well, it's a nice use of Datadog. I remember in the past you were talking about adding it. And I was excited because I've never been at that point where a team has just introduced it; either a team doesn't have it, and they wish they had more insights, or they have it and don't use it. And nobody ever checks the board. So that's a nice anecdote for Datadog helping you out. Yeah, I'm not envious of your situation, friend.

+ +

CHRIS: I do love the cup half full take [laughs] that you have on the overall situation, but that's nice how Datadog worked out for you. And you know what? It was. Thank you, Steph, for once again being that voice of positivity.

+ +

STEPH: I appreciate that you enjoy it because there are times that when someone points it out to me that I do that, I have to be like, "I'm sorry, I'm not trying to be toxic positivity over here. [chuckles] That's just how my brain works."

+ +

CHRIS: Oh, you are definitively not toxic positivity. That's a different thing. Because you ended with but also, I feel bad for you, and I'm glad that I'm not in your shoes. So you are the right level of positivity. I don't think I could have talked to you for three and a half years as co-host on a podcast if I didn't appreciate the level of positivity or the general approach that you bring to thinking about stuff.

+ +

STEPH: Okay. Well, to borrow a phrase from Matt Sumner, who has been a guest on the show, cool, cool, cool, cool. I'm glad my positivity has been well calibrated. And I was about to say I'm interested to hear how this turns out for the team. [laughs] But we're in an awkward spot where I mean, you and I, we can still totally chat. But listeners won't get to hear the rest of that particular saga. I mean, you can share. I mean, you do you. I'm setting all sorts of boundaries for you right now.

+ +

Okay. And now I'm just rambling, and I'm getting weird with it. Because the truth is that, you know, we won't be back. And this is our final episode together. So I think let's just go ahead and rip off the Band-Aid. Let's dive into it. Let's talk about it. Given that it's our last episode that we are recording, we thought of a couple of things that we'd like to talk about. You brought up a great idea that I'm excited to dive into. Do you want to lead us in?

+ +

CHRIS: Sure. Well, if we go back all the way to Episode 172, that is the first episode that you came on as a guest. I actually continue to really love the title of that episode, which is What I Believe About Software. And it both captured that conversation really well, but also, more generally, it's actually become the tagline of the show when we do our little introduction. What do we believe about building great software? Et cetera.

+ +

And I think that's been the throughline of the conversations that we've had is what remains true. What are the themes? Not necessarily the specific technologies, although we certainly talk about that. But what do we believe about building great software? And so today, I thought it would be fun for us to talk about what do we still believe about building great software? It's roughly three and a half years or so that we've been doing this. What's still true?

+ +

STEPH: Oh, well, I have the first unequivocal one, the thing that I still believe about building great software, and that's you should hire thoughtbot. That's definitely the way to go. We'll help you get it done, not that I'm biased in any way.

+ +

CHRIS: No. I'd say collectively between us; there's zero bias with regard to thoughtbot or any other web development shop out there. But thoughtbot is the best.

+ +

STEPH: All right, perfect. So we've got the first one, the clutch one of hire thoughtbot. And then I also really like this topic. And I still think back to that first episode that I recorded with you and how much fun that was and how that really got me to start thinking about this. Because it was something that, at the time, I didn't really reflect on a lot in terms of what does it take to build great software? I was often just doing the day-to-day actions but then not really going high-level think about it. So I'm excited this is one of the topics that we're revisiting.

+ +

So for the next one, this one is, I don't know, maybe it's a little cutesy, but I was trying to think of an alliteration that I enjoyed. And so this one is be an assumption assassin. So what assumptions are you making? And then how can you validate or disprove them? And that is something that I find myself doing constantly. And it always yields better work, better questions, better software, better code, better code reviews. And that's my first one is be an assumption assassin and identify what assumptions you have.

+ +

And I had a really good example come up today while I was having a conversation with Joël about something that I was looking to merge. But I was a little hesitant about it because there are some oddities that I won't dig in too deeply. But essentially, there's a test that I migrated that highlights an existing concern in the code. And I was like, should I go ahead and merge this test that documents it, or should I wait to fix that concern and address it?

+ +

And he brought up a good point. And he's like, "Well, we're assuming it's a bug and an issue, but it may not actually be depending on how the software is being used." And so then he was encouraging me to reevaluate that assumption that I had where I'm like, oh, this is definitely a problem to, like, I don't know, is it a problem? Let's ask somebody.

+ +

CHRIS: First off, I love that as a theme, as one of the things that you still believe about software. Second, I believe you correctly said that you were looking for an alliteration, but my brain heard acronym.

+ +

STEPH: [laughs]

+ +

CHRIS: And so then I was like, B-A-A-A. Is it BAAA? What are you going for there? Oh, you just wanted a bunch of As. Okay, I got it now. Secondly or thirdly, I think I'm on my third now. Apparently, within Sagewell team culture, one of the things that I'm most known for is... there are two phrases: one is just to name it, and the other is to be clear. And these are the two things that I do apparently constantly so much that it's become a meme within the team.

+ +

It's just like, okay, everybody's been talking. But I just want to make sure we're on the same page here. So just to be clear, or just to name it, here's what I'm seeing. But I agree; I think taking those things...what are the implicit bits? What are the assumptions? And making them more explicit. Our job as developers is just to yell at computers all the time and make them try and do human stuff. And there's so much room for lossy conversions at every point in that conversation chain. And so yeah, being very clear, getting rid of assumptions, love it. It's all great stuff.

+ +

Actually, in a very related note, the first on my list is that code is for humans to read. This is one of the things that I believe most deeply and most impacts the way that I write software. Any given piece of functionality that we want to author in our code feels like 10, 20, 50, frankly, almost infinite different versions of the code that would produce nearly identical functionality. So at the end of the day, the actual symbols and strings of text that we bring together to write the code is all about other humans, other people on your team, you five months from now, you a week from now, frankly, or me. I'm going to say me, me a week from now.

+ +

I want to do future me and everyone else on the team a solid and spend that extra 10% of okay, I have something that works now, but let me try and push it around and try and massage it into a shape that is a little more representative of how we're actually thinking about the code, how we talk about it as an organization. Is that the word that we use to describe that domain concept? Maybe we could change that just a little bit. Can I push more of this into the private API? What actually needs to be known here?

+ +

And I think that's where I'm happiest is in those moments because that's where all of the parts of the job come together, the bit where I trick a computer into doing what I want and simultaneously making it so that that code is revisitable, clear, expressive, all of those things. So yeah, code is for humans. And that's true across every language, and framework, and domain that I have worked in. And I've only believed it more and more so over time. So yeah, that's mine.

+ +

STEPH: Yeah, I love that one. That's one of the things that comes to mind when people talk about disliking code reviews. And I can imagine there are a number of reasons that people may have had a poor experience with a code review process. But at the end of the day, if you're not getting that feedback or validation from fellow humans, then how do you know that you've been successful, that you've written something that other people can follow up on? Which goes back to the assumptions in terms of like, you're assuming that you have written something that your future self or that other people are going to be able to read and maintain down the road. So yeah, I love that one.

+ +

One of the other things that I still hold really true to building great software is prioritize early and often. So always be checking in to understand with your users, with your tech concerns, with data that you may have, new insights, and then just confirm that yes, you and the team are constantly working on the thing that has been prioritized and that is the most important.

+ +

And also, be ready to let go. That can be really hard. I have definitely had those moments in my career where I've spent two weeks working really hard on something. And then we've realized that the thing that we were pursuing isn't that valuable, or it's something that users don't need or actually want. And so it was better to let go of it than to pursue it and ship it anyways. So that's one of my other mantras that I have adopted now is prioritize, prioritize, prioritize.

+ +

CHRIS: Unsurprisingly, I agree wholeheartedly with all of that. We're still searching for that thing, that core thing that we disagree on other than Pop-Tarts and IPAs. But I don't know that today is the episode that we're actually going to find that. But yeah, prioritizing is such a critical activity. And it is this interesting collaboration point. It gets different groups together. It's this trade-off. It's this balance. And it's a way to focus on and make explicit the choices that we're making. And we're always making choices. We're always making trade-offs. And so being more explicit, being more connected and collaborative around those I believe in so, so, so much. So love that that was something on your list.

+ +

Let's see, next up on my list is reduce complexity, just sort of as an adage, just always be reducing complexity. It is amazing to me in my time, particularly as a consultant, but even now, this is something that I hold very true is just it's so easy to grow a system in anticipation of future complexity or imagine that the performance concerns that we're going to run into will be so large that we must switch from Postgres and a nice, simple atomic database into a sharded, clustered Kafka queue adventure. And there are absolutely cases that make sense for that sort of thing.

+ +

But at a minimum, I beg of you, anyone starting a new system, don't start with microservices. Don't start with an event queue-based system. These are wildly complex versions of what often can be done with so much simpler of an application. And this scales through to everything. What's the complexity of an API? Do we need caching in that API layer? Or can we just be a little bit inefficient for a little while and avoid the complexity and the overhead of caching?

+ +

Turns out caching is a tricky thing to get right, just as an aside. And so the idea of like, oh, let's just sprinkle in a little bit of caching. It'll be easy, and then we'll get better performance, like, yeah, but did you get it right? Or did you introduce a subtle bug into your program that's going to be really hard to debug later? Because do you cache in development? Well, maybe, I'm not sure, could be.

+ +

So over time, this is something that I've sort of always felt, but I've only ratcheted it up. It's only something that I've come to believe in more and to hold more firmly to. I think earlier in my career, it was something that I felt, but I would more easily be swayed by aspirational ideas of the staggering amounts of traffic that we would be getting soon or the nine different ways that the data model will expand. And so, we should code the current version in anticipation of that. And I have become somewhat the old man on his lawn yelling at the clouds like, "Nah, we don't need it yet. We can grow to that."

+ +

And there's a certain category of things that are useful to try and get out in front of and don't introduce additional complexity, but they're a tiny, tiny list. And so, for most things, my stance is what's the simplest thing that we can get away with right now, that still provides a meaningful experience to our users, that doesn't compromise on security or robustness or correctness but just solves the problem we have right now? And over and over and over again, that has served me incredibly well. So yeah, keep that complexity at bay.

+ +

STEPH: That is one that I've definitely struggled with. And frankly, it works in my favor, that idea of keeping things simple. Because I'm terrible when it comes to predicting the future or trying to build things in a way that I just don't have enough information to really drive the architecture or the application that I'm building. So anytime I'm trying to then stretch and reach for the future in those ways unless I really have a concrete understanding of I am building for these particular scenarios, it's really hard to do. So I very much like keeping it simple and not optimizing before you need to.

+ +

And it reminds me of I think it's Mark Twain, who has a quote, "Worrying is like paying a debt that you don't owe." And that's something that comes to mind for me when also writing code and building features and software is that I tend to be someone who will worry about stuff. And I'm like, oh, is this going to be easy to extend? Is it going to be what it needs to be six months from now if we need to add more features to this and build on top of it? And I have to remind myself it's like, well, let's just wait. Let's wait till we get there and we know more.

+ +

One of my other ideas that couples nicely with the one that you just shared in regards to keeping things simple and then waiting for those needs to arise is that mistakes are going to happen. They are a part of the process. As we are learning and growing and we're stretching our skills and trying things out, things are going to go wrong. We're going to introduce bugs. And to take those opportunities, that's when we start to use that feedback to then improve things like observability, like capturing logs, and how we handle error reporting or having a plan for emergencies.

+ +

So maybe that's the part of worrying that can pay off is thinking through, all right, if something does break, or if something gets shipped that shouldn't, then what is our plan in how we handle that? How do we roll back? Or how do we get things back to a stable build?

+ +

CHRIS: It's funny. I was actually visiting with a friend this past weekend, and we were chatting more generally about life things but the idea of worrying and anticipation and trying to prepare for every bad outcome. And there's the adage of an ounce of prevention is worth a pound of cure. But increasingly, both in life, depending on the context, and in code, I've found that I've shifted to the opposite of it's impossible to stop everything.

+ +

There are going to be bugs that are going to get out there. There are going to be places where we code things incorrectly. And I would rather...I still want to try as hard as I can to get things right, to be clear. I'm not giving up on trying. But I'm all the more focused on how do we know and how do we recover when those things happen? So it's interesting that you just described exactly that, which, again, is a very human life conversation, and yet it applies to the code.

+ +

STEPH: I love that rephrasing of it. Instead of the mistakes are going to happen, it's, like, how do we know, and how do we recover? I think that's perfect. I've also found that by answering the how do we know and how do we recover, that really helps you build trust with clients as well. Because again, things are going to happen, things are going to break.

+ +

And the more prepared you are for that and then the better plan that you have, and then they can watch how you execute that plan, and it’s going to establish a lot of deep trust with other engineers and also the team that you're working with, that you have been thoughtful and that you have ideas on how are we going to address this? Instead of waiting for that moment to happen.

+ +

That's going to happen too. You're going to make decisions in the heat of the moment. But I have found that to be a really useful way to establish yourself with a team in terms of I care about this team and these processes and this application. So how do we handle the bad times, not just the good times?

+ +

I do want to circle back because you alluded to the fact that you and I, we've tried to find things that we disagree on. And so far, Pop-Tarts and beer have been the two things that we disagree on. But I do have a question for you that maybe I will disagree with you on. But I need to know some more about it first.

+ +

You have alluded to there's the Brussels snack, (Oh, I'm going to get this wrong.) Brussels sprout snack hour or working lunch, something combination of those words. [laughs] And it's the working lunch that has stuck out to me, and I've wanted to ask you about it. So here I am. I'm asking you about it. What's a working lunch? What's the Brussels snack happy hour, snackariffic working lunch look like?

+ +

CHRIS: This is fantastic. I love that you waited until the last episode that this was rolling around in the back of your head. And you're like, are you making the team work through lunch? And now, on this final episode, we get to address the controversy that has been brewing in the back of your head. Spoiler alert, no, this is just ridiculous nomenclature. These are two meetings that we have that are more like, let's get the dev team together and talk about stuff that's in our platform sort of developer experience. Or stuff in observability often is talked about in this context because it doesn't quite impact users, but it's how we think about the work.

+ +

And so there are two different meetings that alternate every other week. So every Friday afternoon, we do this, but it's one of two meetings depending on the day. So there's a crispy Brussels snack hour that was the first one that was named, which was named purely for nonsense reasons because we don't have anything else that's named nonsensically in our organization.

+ +

And so I was like, oh when we name this meeting, we should make it nonsense because we don't have any other...We don't have, you know, an SOA microservices fleet with Barbie doll and Galactus and all of the other wonderful names. Those are references to the greatest video ever about microservices; if you've not seen it, that will be in the show notes. It's required reading.

+ +

But anyway, we don't have that. And so we thought, let's be funny with the name of this. So the crispy Brussels snack hour is one, and the crispy Brussels we wanted something that was...the first one is a planning meeting. The second is like, let's actually sort of ensemble program. Let's get the four of us together, and we'll work on some of the stuff that we're talking about here but as a group. And so I wanted the idea of we're working, and so I was like, oh, this will be the crispy Brussels work lunch. But it's purely a name. It's the same time slot. It's 3:00 o'clock on a Friday afternoon. [laughs]

+ +

So it is not at all us working through lunch. I don't think we should work through lunch. I'm concerned that you thought that for a while, and you were just like, I'm a little worried, but I'm not going to bring it up. But I'm glad we got to cover this before we wrapped up this whole Bike Shed co-hosting adventure together.

+ +

STEPH: I feel relieved and also a little robbed of an opportunity for us to have something that we disagree on because I thought this might be a thing. [laughs]

+ +

CHRIS: We can continue searching for that thing. But maybe it's okay that we agreed on most stuff for the run [laughs] of this fun, little show that we did together.

+ +

STEPH: Yeah, that's gone on quite a time. We've got like three years together that we have managed to really only find two, I mean, very important of course, two things. But yeah, it's been pretty limited to those two areas. And each time that you'd mentioned the work lunch, I was like, huh, I need to ask about that because I have feelings about it. But then, you always would dive into very interesting stories of things that came out of it, and I quickly forgot about it.

+ +

So this feels good. This feels like very good important closure. I'm glad that this finally surfaced. But circling back, since I took us on a detour for a little bit, what are some other things that you still hold deeply about building great software?

+ +

CHRIS: I've really got one last thing on the list. It's interesting, there's not a ton technically in this list, which I think represents broadly how I feel about software, and I think how you feel about software. It’s like, it's actually mostly about how the people interact at the end of the day. And you can program in any language or framework, and you can get the job done. We certainly have our preferences and things that we enjoy.

+ +

But the last one really rounds us out, which is think about the users. I always want to be anchoring the conversations that we're having, the approach that we're taking to building the software in what do the users think? Who are our users? What do we know about them? What do they care about? How are they using this technology? How is it impacting their lives? We've talked a number of times about potentially actually watching the sales demo as an engineering team, trying to understand what's the messaging that we're putting out into the world for this piece of software that we're building?

+ +

Or write along with customer support and understand what are the pain points that people are hitting? And really, like, real humans, what are they experiencing? Potentially with a name attached. And that just changes the way that you think about the software. There's also even the lower-level version of it. As we're building classes or modules, what are the public facets of that, and what are the private API? What's the stuff that we're hiding away? And what's the shape that we are exposing to the outside world for varying definitions of outside?

+ +

And how can we just bring in a little bit of empathy to try and think about, again, in the case of like the API for a class, it's probably you on the other side of it, but it's future you in a slightly different mindset with a little bit less information and context on the current problem that you're working on. And so, how can we make things easier for ourselves in the code, for our users at the end of the day?

+ +

How can we deliver real value that is not mired in the minutiae of technical complexity and whatnot but really is trying to help people live better lives? That's a little too fancy as I say it out loud. But it is kind of the core of what I believe, so I'm not going to take it back.

+ +

STEPH: I love how you've expanded users where more traditionally, it's people that are then using the software. But then you've expanded it to include developers because that is something that is often on my mind and something that I just agree with wholeheartedly in terms of when you're writing software; as you mentioned before, software is for people. And so we want to include others.

+ +

And it does improve people's lives. People show up to work every day, and if you've been thoughtful if your past you has been thoughtful, it's either going to give you your future self a better day, or it's going to give other people a better day. So I think that's a very fair statement, improving lives by being thoughtful in regards to focusing on the users, people consuming software, and working in the codebase.

+ +

CHRIS: I know we've talked about this before, but I was having a conversation with one of the developers on the team at Sagewell just last week, and they were mentioning how they really loved working on admin features. And I was like, oh, that's interesting. Let's talk more about that. And it was really it's that same thing that I think you and I have discussed of like there's that immediacy. There's that connection. These are actually colleagues, but you can build software to make their day better. You can understand in detail what the pain points are.

+ +

What's the workflow that as you watch it, you're like, oh, I could put a button up in the corner of the screen that would automate almost all of this and your day would be that much faster? Oh, let me do that. That's exciting. And so I love that as another variation of it, like, yeah, there's for other developers. There's also for the admin team or other users in the organization of the software. There are so many different versions of users, but I think I think we build a better thing if we think about them more.

+ +

STEPH: I have definitely worked with teams where I can tell that certain people are demoralized, and it comes down to they feel frustrated and often disconnected from the people that they are building for. And so then you really feel isolated. I'm pushing code around, but I don't really see the benefit or the purpose of it. And I think that's very hard for developers who typically want to build something that's going to be useful and not feel like it's just going to be thrown away. So connecting your team to those users, I certainly understand. Getting to build something for your colleagues and then they get to say how much they like it is an incredible, rewarding experience.

+ +

You also touched on something that I really appreciate, where you highlighted that a lot of the technical decisions that we make are important, but they're not at the center of the things that we believe when it comes to building great software. And that's something that I will often reflect on. Like, as we were thinking through these particular ideas that we still hold true today, how mine are more people and process-focused and rarely deep in the technical weeds. And there are times that I think, well, shouldn't there be something that's more technical, something that's very concrete? Yes, you should build your code this way or build your application or use a specific technology.

+ +

But after all the projects and teams that I've been a part of, that's just usually not the most important part. And so I appreciate that you highlighted that because sometimes I have to remind myself that, yes, those things can be challenging, but it's often with people and process. That's where the heart of great software lies.

+ +

CHRIS: That's a fantastic phrase, I think, that really encapsulates all of the conversations that we're having here.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

CHRIS: Actually shifting gears a little bit, so we've just talked about what we still believe about building great software. I'm intrigued. We've been chatting for a number of years here on this microphone, these microphones. We have separate ones because we're in different states. But I'm interested; what have we changed our minds about? What have you changed your mind about, Steph? I got a couple of ideas, but I'm intrigued to hear yours.

+ +

STEPH: Nothing. I've never been wrong. I've stuck to everything that I've ever thought.

+ +

CHRIS: That must be boring.

+ +

STEPH: [laughs] Yeah, that's totally not true there. There are definitely things that I've changed my mind about. One of the things that I've changed my mind about is that people who know the most will ask the fewest questions. That's something that I used to consider the trademark of someone who is a more experienced senior developer in terms of you really know what you're doing. And so you typically don't ask for help or need help very often. And so, I'm going way back in terms of things that I have changed my mind about.

+ +

But I have definitely changed my mind where people who know the most are actually the ones that do a really great job of constantly asking questions and asking for feedback. And I think that is still a misconception that people still carry forward. The idea that if you're asking a lot of questions or asking for help that you are not as skilled in your work, and I view it as quite the opposite, that you are very good at what you do and that you know precisely the value of your time.

+ +

And then also reaching out to others for help, and then also just getting validation on things that you may have concerns around. So that's one I've changed my mind on is that I think the more experienced you are, the more questions you tend to ask.

+ +

CHRIS: Oh, I love that one. It's a behavior that I know...I think we've talked about this before. But as consultants, we try and model it just the like; it's totally fine to ask questions. And because we often come in with less context, it makes sense for us to be asking questions, but I will definitely intentionally lean into it in those contexts to be like, everybody keeps throwing around this acronym. I don't actually know what that is. Let me raise my hand.

+ +

And my favorite moment is when people disagree on what the acronym or what the particular word or what the particular project is. Like, I ask the question, and people are like, "Oh, it's this," and someone across the room is like, "Wait, that's what it means? I thought it was this totally other thing." I'm like, cool, glad that we sorted that out. Glad that we got that one up in the air.

+ +

But I actually remember many, many, many years ago, at this point, there was a video series of...PeepCode was the company, and there was the Play by Play series. And so there were particular prominent developers, particularly in the Ruby community. And they would come and sort of be interviewed and pair program. And it was amazing getting to watch these big names that you had heard of, like Yehuda Katz is the one that stands out in my mind. He was one of the authors of merb, which was a framework that was merged with Rails, I want to say around the 3.0 time.

+ +

And just an absolute, very big name in this world and someone that I looked up to and respected. And watching this video, they had to Google for particular API signatures and Rails methods. They were like, "Oh, how does that work? Is it link to and then you pass the name?" I forget what it was specifically. But it was just this very human normalizing moment of this person who has demonstrably done incredible work in our community and produced very complex software still needs to Google for the order of arguments to a particular method within Rails. I was like, oh, okay, that's good to know.

+ +

And with complete humility in the moment, I was just like, yeah, this is normal. Like, it's impossible to hold all of that in your head. And seeing that early on shook me off the idea that that's the thing to do is just memorize everything. It's like no, no, get good at asking the questions. Get good at debugging. Get good, yeah, asking questions. It's a core skill rather than a thing that you grow out of. But I definitely shared early on I was like, not allowed to ask questions, that'll be scary.

+ +

STEPH: I love that example. Because counterintuitively, to me, it demonstrates confidence when someone can say, "Oh, I don't remember how this works," or "Let me go look it up." And so I just very much appreciate when I see someone demonstrating that level of confidence of let's keep going. Let's keep making progress. I'm going to ask for help because that is totally fine, and we are in a safe space. Or I'm going to create a safe space for us to do that.

+ +

One of my favorite versions of this where you shared like if you ask about an acronym and then people disagree, one of my favorite versions is to ask about a particular area of the codebase and be like, what would you say this code is doing here? What do you think users do here? Like, what is the purpose? What's the point of this? [chuckles] And then having people be able to say, "Oh, yeah, this definitively does this thing." Or people are like, "You know, I'm not sure. I don't even know if that code is getting run." That's one of my favorite outcomes of asking questions. How about you? What's something you've changed your mind about?

+ +

CHRIS: I made a list of a couple of things like remote is on there. I didn't know if I'd like remote. I wanted to try it for a while. Tried it, turns out I like it a lot. It's complex. You got to manage it, whatever. But that I think everybody's talked about that a bunch.

+ +

I think probably the most interesting one is deadlines. Initially, in my career, I didn't really feel anything about them. And then I experienced the badness of deadlines. Deadlines are bad. Deadlines are things that come down from on high and then you fail to hit them, and then you're sad. And maybe along the way, you're very stressed and work long hours to try and get there. But they're perhaps arbitrary. And what do they even mean? And also, we have this fixed scope, and they're just bad. And then there was a period of my time where, like, deadlines are bad. The only thing that we do is we show up, and we make the software as quickly as we can.

+ +

But in reality, there are times that we need that constraint. And in fact, I have found a ton of value in deadlines when used intentionally. So we can draw a line in the sand, and we can say, at this point in time, we will have a version of the software. We have a marketing campaign that we need to align with this. So we got to have something at that point. And critically, if you're going to have a deadline, you've now fixed a point in time. You need to flex other things.

+ +

And critically, I think the thing to flex is the scope. So we need to have team management. We have user accounts right now, but now we need to organize them into teams. That is like a category of functionality. It's not a singular feature. And so yeah, we can ship teams in the next quarter. What exactly that means is up in the air.

+ +

And as long as we're able to have conversations essentially on a day-to-day at least weekly cadence as to what will make it in by that deadline and what won't, and we're able to have sometimes the hardest conversations but the very necessary conversations of the trade-offs that we have to make as we're building that software, then I find deadlines are absolutely fantastic tools for focusing and for actually reducing scope but in a really useful way.

+ +

And getting something out there in the hands of users so that you start to get real feedback so that you start to learn, is this useful? What are the ways that people are using this? What should we lean into and do more of? What maybe should we roll back, actually? So yeah, deadlines. First, I didn't know them, then I feared them. Now I love them but only under the right circumstances. It's a double-edged sword, definitely.

+ +

STEPH: I, too, have felt the terribleness of deadlines and railed against them pretty hard because I had gone through a negative experience with them but have also shifted my feelings about them where they can be incredibly useful. So I really liked that's one of the things that you've changed your mind about.

+ +

It also reminds me of one of the other things...I'm going to circle back for a moment to one of the things that I believe about creating great software is to not wait for perfection, and deadlines are a really good tool that helps you not wait for perfection. Because I have also seen teams really struggle or sometimes fail because they waited until there was something perfect to present, and then you realize that you've built the wrong thing.

+ +

So I do want to transition and talk a bit about the show because it's our last episode, and we should talk about it, and the fun adventures that we've had and some of the things that we've learned or things that we're feeling in the moment. So given that it's been a wonderful three years for me, it's been four years for you since you've been a host on the show. How are you feeling?

+ +

CHRIS: I'm feeling a bunch of different things sort of all at once. I am definitely going to miss this immensely. Particularly, I loved when I started, and I got to interview a bunch of thoughtboters and other people from the community. But frankly, three-plus years of getting to chat with you has been just such a delight. There's been an ease to it. We kind of just show up and talk about what we're doing. And yet there are these themes that have run through it. And it has definitely helped me hone and shape my thinking and my ability to communicate about what I'm thinking.

+ +

I've learned that you have a literal superpower to remember the last thing that you were talking about. Listeners, you may not know this, but we are not quite the put-together folks that we may sound like in these recordings. We have a wonderful editor, Mandy Moore, who makes us sound so much better than we are. But we'll often pause and stop and then discuss what we want to talk about next. And Steph always knows the exact phrase that she or I left off on. And it has been so valuable to the team.

+ +

But really, it's been just such a pleasure getting to have these conversations. It's also been something that has just gently been in the back of my mind at all times. And so, I'm observing the work in any given week as I'm doing it. It's almost like meditation in a certain way, whereas I'm working on something, like, oh, this is actually really cool. I want to take a note about this and talk about it on The Bike Shed with Steph.

+ +

And having this outlet, having this platform to be able to have those conversations and knowing that there are people out there is fantastic, although it's very weird because really, every one of these recordings is just you and I on a video call. And so there is an audience, I'm pretty sure. I think people listen to the show; I don't know, occasionally they write in, so it seems like they do. But at the end of the day, this really just feels like a conversation with a friend, and that has been so valuable to have. And yeah, I'm definitely going to miss that.

+ +

It's been a wonderful run, you know, four years is a long time. It's about as long as I've done most things in my career. And so I'm very happy with what we have done here. And there's a trite saying that isn't...yeah, whatever; I'll just say it, which is, "Don't be sad that it's over. Be glad that it happened." And I guess I'm still going to be sad that it's over. But I am so glad that I got the opportunity to do this, that you joined in this adventure and that we got to chat each week. It's been really delightful.

+ +

STEPH: I really liked how you refer to this as being a meditative state. And that is something that I have certainly picked up from you and thoroughly enjoyed that I have this space that I get to show up and bring these ideas and topics and then get to talk them out with you. And that has been such a nice way to either end the week or start a week. I mean, it doesn't matter. Anytime that we record, it's this very nice moment of the week where we get to come together and talk through some of the difficulties and share our stories.

+ +

And that's been one of my favorite moments is because you and I get to show up and share everything that's going on. But then when someone writes into the show or if they send a tweet or something and they share their story or their version of something that happened, or if they said that we made them laugh, that was one of my favorite accomplishments is the idea that something that we have done was silly enough or fun enough that it has brought them joy and made them laugh. So I, too, I'm very, very much going to miss this. It has been a wonderful adventure.

+ +

And I thank you for encouraging me to come on this adventure because I was quite nervous in the beginning. And this has definitely been an aspect of my life that started out as something that was very challenging and stretching my limits, and now it has become this very fun aspect and something that I get to show up and do and then get to share with everyone. And I do feel very proud of it, very much in part to Thom Obarski, who was our initial producer and helped us have that safe space to chat about things. And now Mandy, who keeps the show running smoothly and helps us sound our best week to week.

+ +

So it's been a wonderful adventure. This is going to be hard to let go. And I think it's going to hit me most. Like, this was one of those things as we're talking about it, it's, like, I'll see you next week. This will be fine. But I think it's going to hit me when there's something that I want to talk about where I'm like, oh, this would be great to talk about, and I'll add it to The Bike Shed Trello board. And I'll be like, oh yeah, that's not a thing anymore, at least not quite in the same way that it was.

+ +

CHRIS: So what I'm taking away from this is that you're immediately going to delete my phone number the minute we hang up this call and stop recording. [laughs]

+ +

STEPH: Oh yeah. I preemptively deleted. So that's already done. Friendship is over at this point.

+ +

CHRIS: That's smart. Yeah, because you might forget otherwise in the heat of the moment as we're wrapping this whole thing up.

+ +

STEPH: [laughs]

+ +

CHRIS: But actually, on that note, in a slightly more serious vein, again, there's this weird aspect where the audience is out there. But we're very sort of disconnected, particularly at the moment in time where we're recording. But it has been so wonderful getting various notes from listeners, listener questions, but also just commentary and the occasional thanks and focusing; oh, you pointed me in the direction, or you helped me think through a complicated piece of work or process a problem that we were having. And so that has been just so, so rewarding.

+ +

And one of the facets of this that has been so interesting to me is being able to connect to people and basically put out there what we believe about software, and for the folks that resonate with it and be able to have that connection instantly. And meeting people, and they're like, "Oh, I've listened to The Bike Shed. I like all these things." I'm like, oh, cool, we get to skip way further into the conversation because I've already said a bunch, and you say you like that thing. So, cool, we're halfway through our introductory chat.

+ +

And I know that we agree about a bunch of things, and that's really wonderful. And frankly, I'm going to miss that immensely. So for anyone out there who's found something valuable in this, who's enjoyed listening week to week, or perhaps even back to Upcase for things, I would love to hear from you. I'd love to connect to folks. Send me an email, Twitter. I'm on all the places. I'm Chris Toomey in various spots or ctoomey.com on the internet. Chris Toomey on GitHub. I'm findable, I think. Chris Toomey developer will probably get you there.

+ +

But I would really love to hear from folks, to connect to folks, you know, someday down the road; I think I'll be hiring again. And that'll be fun. I would love to work with some of the folks that have listened to this show or meet you at a conference, or if I happen to be traveling to a city or you're traveling to Boston. Really for me, so much of what this show is about is connecting with people around how we think about building great software. And so, I would love to continue that forward into the future. So yeah, say hi, if you're interested.

+ +

STEPH: I agree. That's been one of the most fun aspects of being co-host of the show. And I'll be honest, you are welcome to contact me, but I am going to be off-grid for probably six months. [laughs] So just know that there will be a bit of a delay before you hear back from me. But I would definitely love to hear from you.

+ +

I also want to say a very heartfelt thanks to a couple of people, just folks that have made this journey incredible and have made it so much fun. One, in particular, is everyone at thoughtbot for their continuous stream of knowledge. I mean, frankly, my software opinions wouldn't be half as interesting if it wasn't for everyone at thoughtbot constantly sharing their knowledge and being a source of inspiration. So I deeply appreciate everyone that has contributed to topics and ideas and just constantly churning out blog posts because those are phenomenal.

+ +

And I also want to give a shout-out to my husband, Tim, because he has listened to The Bike Shed for many years and even helped out with a number of show notes when that was something that you and I used to do before Mandy made our life so much easier and took that over for us. And has intervened a number of times when Utah mid-recording would decide it's time to play. So I want to give a very special thank you to him because he has been a very big supporter of the show and frankly helped me manage through a lot of the recordings for when I had an 80-pound dog that was demanding my attention.

+ +

CHRIS: I think continuing on the note of thanks; similarly, I'm so grateful to thoughtbot as an organization for everything that is represented in my career. It's a decade-plus that I have been following and then listening to the podcasts and then joining the organization, and then getting so many wonderful opportunities to learn about this thing called web development. And then, even after I left the organization, I was able to stay on here on The Bike Shed and hang out and still chat with you, Steph, which has been really wonderful. So thank you, thoughtbot, so much.

+ +

Thank you to Joël Quenneville, who will be the continuing host of the show. This show is not going anywhere. And, Steph, you and I aren't really going anywhere, but we won't be around anymore. But we are leaving it in the very, very capable hands of Joël, and I'm super excited to hear the direction that he takes it and Joel's incredibly thoughtful and nuanced approach to thinking about programming and communicating. So I think that will be really wonderful.

+ +

And lastly, I definitely want to thank Derek Prior and Sage Griffin, the two original hosts of this show, who really produced something wonderful, and for many years, I think it was about four years that they hosted together. I was an avid listener despite actually working at the company the whole time and really loved the thing that they produced and was so grateful that they entrusted me with continuing it forward.

+ +

And hopefully myself and then with the help of you along the way, we've...I think we've done an okay job, but now it is time to pass the torch or the green lantern. That's the adage I've been going with. Gotta pass the lantern, pass the mantle on to the next one. So, Joël, it's going to be in your hands now.

+ +

STEPH: Yeah, I'm so looking forward to future episodes with Joël Quenneville. They are going to be fabulous.

+ +

So I've been thinking in terms of this being our finale episode and then a fun ending for it, so there's a thing called the 21-gun salute, which is the military honor that's performed by firing cannons or artillery. Not to be confused with the three-volley salute, which I definitely confused earlier that is reserved and used at funerals, which this is not. So using the 21-gun salute, I was like, hmm, it is The Bike Shed, and we have this cute ring ring that goes. So I think for our finale, we should have a 21-bell salute as we exit the shed and right off into the sunset.

+ +

CHRIS: I love it. I couldn't imagine a more perfect send-off. So with that, what do you think? Should we wrap up?

+ +

STEPH: Yes, but I have one more silly thing to add. I've thought of a new software idiom that I'm excited about. And so, this may be my final send-off into glory that I'd like to share with you. And I think that we should make like a shard and split.

+ +

CHRIS: [laughs] I so appreciate that in this moment, this final moment that we have together, you choose to go with a punny joke. It is so on brand for the show. It is absolutely perfect. And I think with that note, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + It's Steph and Chris' last show.

+ +

Steph found a game, and if you've been following the journey, all of the Test::Unit test files are now live in RSpec. JWTs really grind Chris' gears.

+ +

They wrap up with things they've learned, takeaways they've had, and their proudest podcasting moments. They also thank all the folks who've helped make The Bike Shed happen.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Microservices

+ +

Transcript:

+ +

CHRIS: One more round of golden roads, our golden. So here we go.

+ +

STEPH: Oh, one more round of golden roads. Okay, maybe that's going to get to me today. [laughs]

+ +

CHRIS: [singing] Golden roads take me home to the place.

+ +

STEPH: [singing] I belong.

+ +

CHRIS: Yeah, there you go.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together we're here to share a bit of what we've learned along the way, at least one more time. So with that [chuckles] as an intro, Steph, what would you say is new in your world?

+ +

STEPH: Hey, Chris. Well, today is the big day. It is the day that you and I are recording our final Bike Shed episode, which we have all the feels about, and we will definitely dive into. But to ignore some of that for now, I have another small fun update I can provide about a new game that I found. So one of the things that's new in my world is I started playing a new board game with Tim; it's called Ticket to Ride. Have you heard of that?

+ +

CHRIS: I have. I don't know if I've played it. I feel like it's a particularly popular one now. But I don't know if I've ever had the pleasure.

+ +

STEPH: It's a very cute game, so we have the smaller version of it. For anyone that's not familiar, it's essentially a map. And then there's a bunch of spots where you can build trains and connect them, and then you get tickets. So your goal is that you're going to connect one location to another location. And then you get points and yada yada, but it's so much fun and especially the two-player version. It's like this perfect 20, maybe 30-minute game.

+ +

I'll be honest; I'm not really a board game person. I always enjoy it. Once I get into it, then I'm like, this is great. I don't know why I was resistant to this. But every time someone's like, "Do you want to play a board game?" I'm like, "Not really." [laughs] I first have to get into it. But I have really enjoyed Ticket to Ride. That's been a really fun game to play. And it's been a nice way to, like, even during the day, we'll break for lunch and squeeze in a game.

+ +

CHRIS: Well, I love good two-player games. They're hard to find. But when you find a good one, and it's got that easy pickup and play...I believe I'm going to now purchase this. And thank you for the tip.

+ +

STEPH: Yeah, this is definitely one of those where it's easy to pick up, and then you can get the expanded board. So there's a two-player version, but then yeah, you can get one that's a map of the U.S. or a map of Europe. And I think it accommodates up to five players as the maximum, so not a huge group but definitely more than two.

+ +

On a slightly more technical note, I have something that I'm very excited to share. It is a journey that you have been on with me, that everybody listening has been on this journey with me. And I'm very excited. I see you nodding your head, so I'm guessing that you're going to know where I'm headed with this. But I'm very excited to announce that all of the Test::Unit test files now live in RSpec. So that is a big win.

+ +

I'm very, very excited for that to be a previous state of life and not an ongoing state of life. Because I have certainly developed too much niche knowledge around migrating these tests, and that became apparent to me when I was pairing with another developer that works with the client because they had offered...they had some time. They're like, "Hey, do you want help migrating a test file?" And I was like, "Sure." I was like, "But this is wonky enough, like, we should pair and work on this together because I just know some ins and outs. And I don't want you to have to learn a lot of the hard lessons that I've learned."

+ +

And the test that we happened to pick up was very gnarly. It had a lot of mystery guests. And we spent, I think it was a good two hours. And we only migrated one of the tests, so not even a full file but one of the tests. And at the end of it, I was like, I know way too much about some of the oddities and quirkiness of this. And we got through it, but we decided that wasn't a good use of their time for them to go at this alone. So that's why I'm extra excited and relieved because I didn't want this task to carry on to someone else. So, hooray, we did it.

+ +

CHRIS: Hooray. Just in time. You're Indiana Jones grabbing your hat right as you roll out and off to [laughs] be away from the project for a bit. So you stuck the landing. Well done, Steph.

+ +

STEPH: Thank you. Thank you. So that's some great news. And then also, everything else in life is pretty much focused around getting ready for maternity leave. That's about to happen soon, and I am so ready. I have thoroughly enjoyed a lot of the things that I'm doing, [laughs] but goodness, being pregnant is hard. And I am very much ready for that leave.

+ +

So also, a lot of the things that I'm doing right now are very focused on making sure everything's transitioned and communicated and that I just feel really good about that day of departure. That covers all the newness in my world other than the big thing that we're just not talking about yet. How about you? What's new in your world?

+ +

CHRIS: Well, continuing to skirt the bigger topic that we will certainly get to in the episode, what is new in my world? I'm actually quite excited workwise right now. We have a much larger body of work that finally we got the clarity. All the pieces fell into place, and now we're sort of everybody rowing in the same direction. There's interesting, I think, really impactful code that we're writing for Sagewell right now. So that's really fantastic. We've got the whole team back together on the engineering side. And so we're, I think, in the strongest and most interesting point that I have experienced thus far. So that's all really fantastic.

+ +

On a slight technical deep dive, you know what really grinds my gears? It's JWTs. JSON Web Tokens and I have never gotten along. It's never been a match made in heaven. And we have a webhook that comes from Plaid. Plaid is a vendor for connecting bank accounts and whatnot. And they have webhooks like many people do. So they can inform us when things change, lovely feature of how we build web apps these days. But often, there's a signature that says, "This is definitively from us, and you can trust us." And usually, it's some calculated signature, HMAC, or something like that.

+ +

For some reason, Plaid's uses JWTs, and more than that, they use JWKs. So there's JWT which is the signature. That JWT itself is signed with a JWK. You have to fetch the JWK from their server based on the key ID in the header of the JWT. But how do you know if you can trust the JWT before you've gotten the JWK? All of this broke in a recent upgrade.

+ +

We went from Heroku-20 to Heroku-22 to the new platform with Heroku, which bumped us to OpenSSL 3.0, and it turns out JWT doesn't work with it. And so that's sad. It's a no. It's going to be a no. It turns out the way that OpenSSL 3.0 works is incompatible with some of the code paths in JWT. And so I was like, wait, we just can't do this? And it's low-level cryptographic primitive stuff that I'm not comfortable messing around with. I'm not going to hop in there and roll up my sleeves.

+ +

And even just getting to the point that I understood what was broken about this took like an hour and a half just to sort of like, wait, which is okay...so the JWT signs and encodes. And this will be a theme that we come back to later, but I think web development should be simpler. I think we should strive for simplicity. And this is a perfect example where I'm guessing Plaid uses JWTs and that approach to communicating security things often, but I've not seen it used much for signing webhooks. And, oof, it led to a complicated day. And it's unfixable now as far as I can tell.

+ +

There is a commit on the JWT Ruby repo as of five days ago, but it doesn't build in our system. And it's not released. And it's just a mess. So yeah, engineering is complicated. I'm both wildly excited about what we're doing at Sagewell, and then today was this local minimum of like, oh, JWTs again. Again, we find ourselves battling. And you won today, but hopefully not for too long.

+ +

STEPH: Oof, how did this manifest that you first noticed? So is it because a webhook suddenly stopped working, and that was like the error that rose up, and that's what helped you dive into it?

+ +

CHRIS: Yeah, we have a little bit of code in the controller for where Plaid events come in. We calculate and verify the signature of the webhook to make sure that it's valid, and we reject it otherwise. And we alert ourselves via Sentry, and then we also have a Datadog scan that can show what's the status code of the response. Because these are incoming HTTP payloads or requests, and so we can see there were 200 up until this magical day when suddenly everything changed. And that was when we switched Heroku stacks.

+ +

And then we can see it also in Sentry. So we're able to look at it, and we're like, why are none of the Plaid webhooks able to verify the signature anymore? That seems weird. And so then Datadog confirmed that it consistently was broken from this point in time. And then we were able to track that back. It was also pretty easy to guess because the error was "pkeys are immutable in OpenSSL 3.0," and that was the data. And I was like, oh, cool, that sounds fun. Let me go figure out what that means.

+ +

STEPH: [laughs] Well, it's a nice use of Datadog. I remember in the past you were talking about adding it. And I was excited because I've never been at that point where a team has just introduced it; either a team doesn't have it, and they wish they had more insights, or they have it and don't use it. And nobody ever checks the board. So that's a nice anecdote for Datadog helping you out. Yeah, I'm not envious of your situation, friend.

+ +

CHRIS: I do love the cup half full take [laughs] that you have on the overall situation, but that's nice how Datadog worked out for you. And you know what? It was. Thank you, Steph, for once again being that voice of positivity.

+ +

STEPH: I appreciate that you enjoy it because there are times that when someone points it out to me that I do that, I have to be like, "I'm sorry, I'm not trying to be toxic positivity over here. [chuckles] That's just how my brain works."

+ +

CHRIS: Oh, you are definitively not toxic positivity. That's a different thing. Because you ended with but also, I feel bad for you, and I'm glad that I'm not in your shoes. So you are the right level of positivity. I don't think I could have talked to you for three and a half years as co-host on a podcast if I didn't appreciate the level of positivity or the general approach that you bring to thinking about stuff.

+ +

STEPH: Okay. Well, to borrow a phrase from Matt Sumner, who has been a guest on the show, cool, cool, cool, cool. I'm glad my positivity has been well calibrated. And I was about to say I'm interested to hear how this turns out for the team. [laughs] But we're in an awkward spot where I mean, you and I, we can still totally chat. But listeners won't get to hear the rest of that particular saga. I mean, you can share. I mean, you do you. I'm setting all sorts of boundaries for you right now.

+ +

Okay. And now I'm just rambling, and I'm getting weird with it. Because the truth is that, you know, we won't be back. And this is our final episode together. So I think let's just go ahead and rip off the Band-Aid. Let's dive into it. Let's talk about it. Given that it's our last episode that we are recording, we thought of a couple of things that we'd like to talk about. You brought up a great idea that I'm excited to dive into. Do you want to lead us in?

+ +

CHRIS: Sure. Well, if we go back all the way to Episode 172, that is the first episode that you came on as a guest. I actually continue to really love the title of that episode, which is What I Believe About Software. And it both captured that conversation really well, but also, more generally, it's actually become the tagline of the show when we do our little introduction. What do we believe about building great software? Et cetera.

+ +

And I think that's been the throughline of the conversations that we've had is what remains true. What are the themes? Not necessarily the specific technologies, although we certainly talk about that. But what do we believe about building great software? And so today, I thought it would be fun for us to talk about what do we still believe about building great software? It's roughly three and a half years or so that we've been doing this. What's still true?

+ +

STEPH: Oh, well, I have the first unequivocal one, the thing that I still believe about building great software, and that's you should hire thoughtbot. That's definitely the way to go. We'll help you get it done, not that I'm biased in any way.

+ +

CHRIS: No. I'd say collectively between us; there's zero bias with regard to thoughtbot or any other web development shop out there. But thoughtbot is the best.

+ +

STEPH: All right, perfect. So we've got the first one, the clutch one of hire thoughtbot. And then I also really like this topic. And I still think back to that first episode that I recorded with you and how much fun that was and how that really got me to start thinking about this. Because it was something that, at the time, I didn't really reflect on a lot in terms of what does it take to build great software? I was often just doing the day-to-day actions but then not really going high-level think about it. So I'm excited this is one of the topics that we're revisiting.

+ +

So for the next one, this one is, I don't know, maybe it's a little cutesy, but I was trying to think of an alliteration that I enjoyed. And so this one is be an assumption assassin. So what assumptions are you making? And then how can you validate or disprove them? And that is something that I find myself doing constantly. And it always yields better work, better questions, better software, better code, better code reviews. And that's my first one is be an assumption assassin and identify what assumptions you have.

+ +

And I had a really good example come up today while I was having a conversation with Joël about something that I was looking to merge. But I was a little hesitant about it because there are some oddities that I won't dig in too deeply. But essentially, there's a test that I migrated that highlights an existing concern in the code. And I was like, should I go ahead and merge this test that documents it, or should I wait to fix that concern and address it?

+ +

And he brought up a good point. And he's like, "Well, we're assuming it's a bug and an issue, but it may not actually be depending on how the software is being used." And so then he was encouraging me to reevaluate that assumption that I had where I'm like, oh, this is definitely a problem to, like, I don't know, is it a problem? Let's ask somebody.

+ +

CHRIS: First off, I love that as a theme, as one of the things that you still believe about software. Second, I believe you correctly said that you were looking for an alliteration, but my brain heard acronym.

+ +

STEPH: [laughs]

+ +

CHRIS: And so then I was like, B-A-A-A. Is it BAAA? What are you going for there? Oh, you just wanted a bunch of As. Okay, I got it now. Secondly or thirdly, I think I'm on my third now. Apparently, within Sagewell team culture, one of the things that I'm most known for is... there are two phrases: one is just to name it, and the other is to be clear. And these are the two things that I do apparently constantly so much that it's become a meme within the team.

+ +

It's just like, okay, everybody's been talking. But I just want to make sure we're on the same page here. So just to be clear, or just to name it, here's what I'm seeing. But I agree; I think taking those things...what are the implicit bits? What are the assumptions? And making them more explicit. Our job as developers is just to yell at computers all the time and make them try and do human stuff. And there's so much room for lossy conversions at every point in that conversation chain. And so yeah, being very clear, getting rid of assumptions, love it. It's all great stuff.

+ +

Actually, in a very related note, the first on my list is that code is for humans to read. This is one of the things that I believe most deeply and most impacts the way that I write software. Any given piece of functionality that we want to author in our code feels like 10, 20, 50, frankly, almost infinite different versions of the code that would produce nearly identical functionality. So at the end of the day, the actual symbols and strings of text that we bring together to write the code is all about other humans, other people on your team, you five months from now, you a week from now, frankly, or me. I'm going to say me, me a week from now.

+ +

I want to do future me and everyone else on the team a solid and spend that extra 10% of okay, I have something that works now, but let me try and push it around and try and massage it into a shape that is a little more representative of how we're actually thinking about the code, how we talk about it as an organization. Is that the word that we use to describe that domain concept? Maybe we could change that just a little bit. Can I push more of this into the private API? What actually needs to be known here?

+ +

And I think that's where I'm happiest is in those moments because that's where all of the parts of the job come together, the bit where I trick a computer into doing what I want and simultaneously making it so that that code is revisitable, clear, expressive, all of those things. So yeah, code is for humans. And that's true across every language, and framework, and domain that I have worked in. And I've only believed it more and more so over time. So yeah, that's mine.

+ +

STEPH: Yeah, I love that one. That's one of the things that comes to mind when people talk about disliking code reviews. And I can imagine there are a number of reasons that people may have had a poor experience with a code review process. But at the end of the day, if you're not getting that feedback or validation from fellow humans, then how do you know that you've been successful, that you've written something that other people can follow up on? Which goes back to the assumptions in terms of like, you're assuming that you have written something that your future self or that other people are going to be able to read and maintain down the road. So yeah, I love that one.

+ +

One of the other things that I still hold really true to building great software is prioritize early and often. So always be checking in to understand with your users, with your tech concerns, with data that you may have, new insights, and then just confirm that yes, you and the team are constantly working on the thing that has been prioritized and that is the most important.

+ +

And also, be ready to let go. That can be really hard. I have definitely had those moments in my career where I've spent two weeks working really hard on something. And then we've realized that the thing that we were pursuing isn't that valuable, or it's something that users don't need or actually want. And so it was better to let go of it than to pursue it and ship it anyways. So that's one of my other mantras that I have adopted now is prioritize, prioritize, prioritize.

+ +

CHRIS: Unsurprisingly, I agree wholeheartedly with all of that. We're still searching for that thing, that core thing that we disagree on other than Pop-Tarts and IPAs. But I don't know that today is the episode that we're actually going to find that. But yeah, prioritizing is such a critical activity. And it is this interesting collaboration point. It gets different groups together. It's this trade-off. It's this balance. And it's a way to focus on and make explicit the choices that we're making. And we're always making choices. We're always making trade-offs. And so being more explicit, being more connected and collaborative around those I believe in so, so, so much. So love that that was something on your list.

+ +

Let's see, next up on my list is reduce complexity, just sort of as an adage, just always be reducing complexity. It is amazing to me in my time, particularly as a consultant, but even now, this is something that I hold very true is just it's so easy to grow a system in anticipation of future complexity or imagine that the performance concerns that we're going to run into will be so large that we must switch from Postgres and a nice, simple atomic database into a sharded, clustered Kafka queue adventure. And there are absolutely cases that make sense for that sort of thing.

+ +

But at a minimum, I beg of you, anyone starting a new system, don't start with microservices. Don't start with an event queue-based system. These are wildly complex versions of what often can be done with so much simpler of an application. And this scales through to everything. What's the complexity of an API? Do we need caching in that API layer? Or can we just be a little bit inefficient for a little while and avoid the complexity and the overhead of caching?

+ +

Turns out caching is a tricky thing to get right, just as an aside. And so the idea of like, oh, let's just sprinkle in a little bit of caching. It'll be easy, and then we'll get better performance, like, yeah, but did you get it right? Or did you introduce a subtle bug into your program that's going to be really hard to debug later? Because do you cache in development? Well, maybe, I'm not sure, could be.

+ +

So over time, this is something that I've sort of always felt, but I've only ratcheted it up. It's only something that I've come to believe in more and to hold more firmly to. I think earlier in my career, it was something that I felt, but I would more easily be swayed by aspirational ideas of the staggering amounts of traffic that we would be getting soon or the nine different ways that the data model will expand. And so, we should code the current version in anticipation of that. And I have become somewhat the old man on his lawn yelling at the clouds like, "Nah, we don't need it yet. We can grow to that."

+ +

And there's a certain category of things that are useful to try and get out in front of and don't introduce additional complexity, but they're a tiny, tiny list. And so, for most things, my stance is what's the simplest thing that we can get away with right now, that still provides a meaningful experience to our users, that doesn't compromise on security or robustness or correctness but just solves the problem we have right now? And over and over and over again, that has served me incredibly well. So yeah, keep that complexity at bay.

+ +

STEPH: That is one that I've definitely struggled with. And frankly, it works in my favor, that idea of keeping things simple. Because I'm terrible when it comes to predicting the future or trying to build things in a way that I just don't have enough information to really drive the architecture or the application that I'm building. So anytime I'm trying to then stretch and reach for the future in those ways unless I really have a concrete understanding of I am building for these particular scenarios, it's really hard to do. So I very much like keeping it simple and not optimizing before you need to.

+ +

And it reminds me of I think it's Mark Twain, who has a quote, "Worrying is like paying a debt that you don't owe." And that's something that comes to mind for me when also writing code and building features and software is that I tend to be someone who will worry about stuff. And I'm like, oh, is this going to be easy to extend? Is it going to be what it needs to be six months from now if we need to add more features to this and build on top of it? And I have to remind myself it's like, well, let's just wait. Let's wait till we get there and we know more.

+ +

One of my other ideas that couples nicely with the one that you just shared in regards to keeping things simple and then waiting for those needs to arise is that mistakes are going to happen. They are a part of the process. As we are learning and growing and we're stretching our skills and trying things out, things are going to go wrong. We're going to introduce bugs. And to take those opportunities, that's when we start to use that feedback to then improve things like observability, like capturing logs, and how we handle error reporting or having a plan for emergencies.

+ +

So maybe that's the part of worrying that can pay off is thinking through, all right, if something does break, or if something gets shipped that shouldn't, then what is our plan in how we handle that? How do we roll back? Or how do we get things back to a stable build?

+ +

CHRIS: It's funny. I was actually visiting with a friend this past weekend, and we were chatting more generally about life things but the idea of worrying and anticipation and trying to prepare for every bad outcome. And there's the adage of an ounce of prevention is worth a pound of cure. But increasingly, both in life, depending on the context, and in code, I've found that I've shifted to the opposite of it's impossible to stop everything.

+ +

There are going to be bugs that are going to get out there. There are going to be places where we code things incorrectly. And I would rather...I still want to try as hard as I can to get things right, to be clear. I'm not giving up on trying. But I'm all the more focused on how do we know and how do we recover when those things happen? So it's interesting that you just described exactly that, which, again, is a very human life conversation, and yet it applies to the code.

+ +

STEPH: I love that rephrasing of it. Instead of the mistakes are going to happen, it's, like, how do we know, and how do we recover? I think that's perfect. I've also found that by answering the how do we know and how do we recover, that really helps you build trust with clients as well. Because again, things are going to happen, things are going to break.

+ +

And the more prepared you are for that and then the better plan that you have, and then they can watch how you execute that plan, and it’s going to establish a lot of deep trust with other engineers and also the team that you're working with, that you have been thoughtful and that you have ideas on how are we going to address this? Instead of waiting for that moment to happen.

+ +

That's going to happen too. You're going to make decisions in the heat of the moment. But I have found that to be a really useful way to establish yourself with a team in terms of I care about this team and these processes and this application. So how do we handle the bad times, not just the good times?

+ +

I do want to circle back because you alluded to the fact that you and I, we've tried to find things that we disagree on. And so far, Pop-Tarts and beer have been the two things that we disagree on. But I do have a question for you that maybe I will disagree with you on. But I need to know some more about it first.

+ +

You have alluded to there's the Brussels snack, (Oh, I'm going to get this wrong.) Brussels sprout snack hour or working lunch, something combination of those words. [laughs] And it's the working lunch that has stuck out to me, and I've wanted to ask you about it. So here I am. I'm asking you about it. What's a working lunch? What's the Brussels snack happy hour, snackariffic working lunch look like?

+ +

CHRIS: This is fantastic. I love that you waited until the last episode that this was rolling around in the back of your head. And you're like, are you making the team work through lunch? And now, on this final episode, we get to address the controversy that has been brewing in the back of your head. Spoiler alert, no, this is just ridiculous nomenclature. These are two meetings that we have that are more like, let's get the dev team together and talk about stuff that's in our platform sort of developer experience. Or stuff in observability often is talked about in this context because it doesn't quite impact users, but it's how we think about the work.

+ +

And so there are two different meetings that alternate every other week. So every Friday afternoon, we do this, but it's one of two meetings depending on the day. So there's a crispy Brussels snack hour that was the first one that was named, which was named purely for nonsense reasons because we don't have anything else that's named nonsensically in our organization.

+ +

And so I was like, oh when we name this meeting, we should make it nonsense because we don't have any other...We don't have, you know, an SOA microservices fleet with Barbie doll and Galactus and all of the other wonderful names. Those are references to the greatest video ever about microservices; if you've not seen it, that will be in the show notes. It's required reading.

+ +

But anyway, we don't have that. And so we thought, let's be funny with the name of this. So the crispy Brussels snack hour is one, and the crispy Brussels we wanted something that was...the first one is a planning meeting. The second is like, let's actually sort of ensemble program. Let's get the four of us together, and we'll work on some of the stuff that we're talking about here but as a group. And so I wanted the idea of we're working, and so I was like, oh, this will be the crispy Brussels work lunch. But it's purely a name. It's the same time slot. It's 3:00 o'clock on a Friday afternoon. [laughs]

+ +

So it is not at all us working through lunch. I don't think we should work through lunch. I'm concerned that you thought that for a while, and you were just like, I'm a little worried, but I'm not going to bring it up. But I'm glad we got to cover this before we wrapped up this whole Bike Shed co-hosting adventure together.

+ +

STEPH: I feel relieved and also a little robbed of an opportunity for us to have something that we disagree on because I thought this might be a thing. [laughs]

+ +

CHRIS: We can continue searching for that thing. But maybe it's okay that we agreed on most stuff for the run [laughs] of this fun, little show that we did together.

+ +

STEPH: Yeah, that's gone on quite a time. We've got like three years together that we have managed to really only find two, I mean, very important of course, two things. But yeah, it's been pretty limited to those two areas. And each time that you'd mentioned the work lunch, I was like, huh, I need to ask about that because I have feelings about it. But then, you always would dive into very interesting stories of things that came out of it, and I quickly forgot about it.

+ +

So this feels good. This feels like very good important closure. I'm glad that this finally surfaced. But circling back, since I took us on a detour for a little bit, what are some other things that you still hold deeply about building great software?

+ +

CHRIS: I've really got one last thing on the list. It's interesting, there's not a ton technically in this list, which I think represents broadly how I feel about software, and I think how you feel about software. It’s like, it's actually mostly about how the people interact at the end of the day. And you can program in any language or framework, and you can get the job done. We certainly have our preferences and things that we enjoy.

+ +

But the last one really rounds us out, which is think about the users. I always want to be anchoring the conversations that we're having, the approach that we're taking to building the software in what do the users think? Who are our users? What do we know about them? What do they care about? How are they using this technology? How is it impacting their lives? We've talked a number of times about potentially actually watching the sales demo as an engineering team, trying to understand what's the messaging that we're putting out into the world for this piece of software that we're building?

+ +

Or write along with customer support and understand what are the pain points that people are hitting? And really, like, real humans, what are they experiencing? Potentially with a name attached. And that just changes the way that you think about the software. There's also even the lower-level version of it. As we're building classes or modules, what are the public facets of that, and what are the private API? What's the stuff that we're hiding away? And what's the shape that we are exposing to the outside world for varying definitions of outside?

+ +

And how can we just bring in a little bit of empathy to try and think about, again, in the case of like the API for a class, it's probably you on the other side of it, but it's future you in a slightly different mindset with a little bit less information and context on the current problem that you're working on. And so, how can we make things easier for ourselves in the code, for our users at the end of the day?

+ +

How can we deliver real value that is not mired in the minutiae of technical complexity and whatnot but really is trying to help people live better lives? That's a little too fancy as I say it out loud. But it is kind of the core of what I believe, so I'm not going to take it back.

+ +

STEPH: I love how you've expanded users where more traditionally, it's people that are then using the software. But then you've expanded it to include developers because that is something that is often on my mind and something that I just agree with wholeheartedly in terms of when you're writing software; as you mentioned before, software is for people. And so we want to include others.

+ +

And it does improve people's lives. People show up to work every day, and if you've been thoughtful if your past you has been thoughtful, it's either going to give you your future self a better day, or it's going to give other people a better day. So I think that's a very fair statement, improving lives by being thoughtful in regards to focusing on the users, people consuming software, and working in the codebase.

+ +

CHRIS: I know we've talked about this before, but I was having a conversation with one of the developers on the team at Sagewell just last week, and they were mentioning how they really loved working on admin features. And I was like, oh, that's interesting. Let's talk more about that. And it was really it's that same thing that I think you and I have discussed of like there's that immediacy. There's that connection. These are actually colleagues, but you can build software to make their day better. You can understand in detail what the pain points are.

+ +

What's the workflow that as you watch it, you're like, oh, I could put a button up in the corner of the screen that would automate almost all of this and your day would be that much faster? Oh, let me do that. That's exciting. And so I love that as another variation of it, like, yeah, there's for other developers. There's also for the admin team or other users in the organization of the software. There are so many different versions of users, but I think I think we build a better thing if we think about them more.

+ +

STEPH: I have definitely worked with teams where I can tell that certain people are demoralized, and it comes down to they feel frustrated and often disconnected from the people that they are building for. And so then you really feel isolated. I'm pushing code around, but I don't really see the benefit or the purpose of it. And I think that's very hard for developers who typically want to build something that's going to be useful and not feel like it's just going to be thrown away. So connecting your team to those users, I certainly understand. Getting to build something for your colleagues and then they get to say how much they like it is an incredible, rewarding experience.

+ +

You also touched on something that I really appreciate, where you highlighted that a lot of the technical decisions that we make are important, but they're not at the center of the things that we believe when it comes to building great software. And that's something that I will often reflect on. Like, as we were thinking through these particular ideas that we still hold true today, how mine are more people and process-focused and rarely deep in the technical weeds. And there are times that I think, well, shouldn't there be something that's more technical, something that's very concrete? Yes, you should build your code this way or build your application or use a specific technology.

+ +

But after all the projects and teams that I've been a part of, that's just usually not the most important part. And so I appreciate that you highlighted that because sometimes I have to remind myself that, yes, those things can be challenging, but it's often with people and process. That's where the heart of great software lies.

+ +

CHRIS: That's a fantastic phrase, I think, that really encapsulates all of the conversations that we're having here.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

CHRIS: Actually shifting gears a little bit, so we've just talked about what we still believe about building great software. I'm intrigued. We've been chatting for a number of years here on this microphone, these microphones. We have separate ones because we're in different states. But I'm interested; what have we changed our minds about? What have you changed your mind about, Steph? I got a couple of ideas, but I'm intrigued to hear yours.

+ +

STEPH: Nothing. I've never been wrong. I've stuck to everything that I've ever thought.

+ +

CHRIS: That must be boring.

+ +

STEPH: [laughs] Yeah, that's totally not true there. There are definitely things that I've changed my mind about. One of the things that I've changed my mind about is that people who know the most will ask the fewest questions. That's something that I used to consider the trademark of someone who is a more experienced senior developer in terms of you really know what you're doing. And so you typically don't ask for help or need help very often. And so, I'm going way back in terms of things that I have changed my mind about.

+ +

But I have definitely changed my mind where people who know the most are actually the ones that do a really great job of constantly asking questions and asking for feedback. And I think that is still a misconception that people still carry forward. The idea that if you're asking a lot of questions or asking for help that you are not as skilled in your work, and I view it as quite the opposite, that you are very good at what you do and that you know precisely the value of your time.

+ +

And then also reaching out to others for help, and then also just getting validation on things that you may have concerns around. So that's one I've changed my mind on is that I think the more experienced you are, the more questions you tend to ask.

+ +

CHRIS: Oh, I love that one. It's a behavior that I know...I think we've talked about this before. But as consultants, we try and model it just the like; it's totally fine to ask questions. And because we often come in with less context, it makes sense for us to be asking questions, but I will definitely intentionally lean into it in those contexts to be like, everybody keeps throwing around this acronym. I don't actually know what that is. Let me raise my hand.

+ +

And my favorite moment is when people disagree on what the acronym or what the particular word or what the particular project is. Like, I ask the question, and people are like, "Oh, it's this," and someone across the room is like, "Wait, that's what it means? I thought it was this totally other thing." I'm like, cool, glad that we sorted that out. Glad that we got that one up in the air.

+ +

But I actually remember many, many, many years ago, at this point, there was a video series of...PeepCode was the company, and there was the Play by Play series. And so there were particular prominent developers, particularly in the Ruby community. And they would come and sort of be interviewed and pair program. And it was amazing getting to watch these big names that you had heard of, like Yehuda Katz is the one that stands out in my mind. He was one of the authors of merb, which was a framework that was merged with Rails, I want to say around the 3.0 time.

+ +

And just an absolute, very big name in this world and someone that I looked up to and respected. And watching this video, they had to Google for particular API signatures and Rails methods. They were like, "Oh, how does that work? Is it link to and then you pass the name?" I forget what it was specifically. But it was just this very human normalizing moment of this person who has demonstrably done incredible work in our community and produced very complex software still needs to Google for the order of arguments to a particular method within Rails. I was like, oh, okay, that's good to know.

+ +

And with complete humility in the moment, I was just like, yeah, this is normal. Like, it's impossible to hold all of that in your head. And seeing that early on shook me off the idea that that's the thing to do is just memorize everything. It's like no, no, get good at asking the questions. Get good at debugging. Get good, yeah, asking questions. It's a core skill rather than a thing that you grow out of. But I definitely shared early on I was like, not allowed to ask questions, that'll be scary.

+ +

STEPH: I love that example. Because counterintuitively, to me, it demonstrates confidence when someone can say, "Oh, I don't remember how this works," or "Let me go look it up." And so I just very much appreciate when I see someone demonstrating that level of confidence of let's keep going. Let's keep making progress. I'm going to ask for help because that is totally fine, and we are in a safe space. Or I'm going to create a safe space for us to do that.

+ +

One of my favorite versions of this where you shared like if you ask about an acronym and then people disagree, one of my favorite versions is to ask about a particular area of the codebase and be like, what would you say this code is doing here? What do you think users do here? Like, what is the purpose? What's the point of this? [chuckles] And then having people be able to say, "Oh, yeah, this definitively does this thing." Or people are like, "You know, I'm not sure. I don't even know if that code is getting run." That's one of my favorite outcomes of asking questions. How about you? What's something you've changed your mind about?

+ +

CHRIS: I made a list of a couple of things like remote is on there. I didn't know if I'd like remote. I wanted to try it for a while. Tried it, turns out I like it a lot. It's complex. You got to manage it, whatever. But that I think everybody's talked about that a bunch.

+ +

I think probably the most interesting one is deadlines. Initially, in my career, I didn't really feel anything about them. And then I experienced the badness of deadlines. Deadlines are bad. Deadlines are things that come down from on high and then you fail to hit them, and then you're sad. And maybe along the way, you're very stressed and work long hours to try and get there. But they're perhaps arbitrary. And what do they even mean? And also, we have this fixed scope, and they're just bad. And then there was a period of my time where, like, deadlines are bad. The only thing that we do is we show up, and we make the software as quickly as we can.

+ +

But in reality, there are times that we need that constraint. And in fact, I have found a ton of value in deadlines when used intentionally. So we can draw a line in the sand, and we can say, at this point in time, we will have a version of the software. We have a marketing campaign that we need to align with this. So we got to have something at that point. And critically, if you're going to have a deadline, you've now fixed a point in time. You need to flex other things.

+ +

And critically, I think the thing to flex is the scope. So we need to have team management. We have user accounts right now, but now we need to organize them into teams. That is like a category of functionality. It's not a singular feature. And so yeah, we can ship teams in the next quarter. What exactly that means is up in the air.

+ +

And as long as we're able to have conversations essentially on a day-to-day at least weekly cadence as to what will make it in by that deadline and what won't, and we're able to have sometimes the hardest conversations but the very necessary conversations of the trade-offs that we have to make as we're building that software, then I find deadlines are absolutely fantastic tools for focusing and for actually reducing scope but in a really useful way.

+ +

And getting something out there in the hands of users so that you start to get real feedback so that you start to learn, is this useful? What are the ways that people are using this? What should we lean into and do more of? What maybe should we roll back, actually? So yeah, deadlines. First, I didn't know them, then I feared them. Now I love them but only under the right circumstances. It's a double-edged sword, definitely.

+ +

STEPH: I, too, have felt the terribleness of deadlines and railed against them pretty hard because I had gone through a negative experience with them but have also shifted my feelings about them where they can be incredibly useful. So I really liked that's one of the things that you've changed your mind about.

+ +

It also reminds me of one of the other things...I'm going to circle back for a moment to one of the things that I believe about creating great software is to not wait for perfection, and deadlines are a really good tool that helps you not wait for perfection. Because I have also seen teams really struggle or sometimes fail because they waited until there was something perfect to present, and then you realize that you've built the wrong thing.

+ +

So I do want to transition and talk a bit about the show because it's our last episode, and we should talk about it, and the fun adventures that we've had and some of the things that we've learned or things that we're feeling in the moment. So given that it's been a wonderful three years for me, it's been four years for you since you've been a host on the show. How are you feeling?

+ +

CHRIS: I'm feeling a bunch of different things sort of all at once. I am definitely going to miss this immensely. Particularly, I loved when I started, and I got to interview a bunch of thoughtboters and other people from the community. But frankly, three-plus years of getting to chat with you has been just such a delight. There's been an ease to it. We kind of just show up and talk about what we're doing. And yet there are these themes that have run through it. And it has definitely helped me hone and shape my thinking and my ability to communicate about what I'm thinking.

+ +

I've learned that you have a literal superpower to remember the last thing that you were talking about. Listeners, you may not know this, but we are not quite the put-together folks that we may sound like in these recordings. We have a wonderful editor, Mandy Moore, who makes us sound so much better than we are. But we'll often pause and stop and then discuss what we want to talk about next. And Steph always knows the exact phrase that she or I left off on. And it has been so valuable to the team.

+ +

But really, it's been just such a pleasure getting to have these conversations. It's also been something that has just gently been in the back of my mind at all times. And so, I'm observing the work in any given week as I'm doing it. It's almost like meditation in a certain way, whereas I'm working on something, like, oh, this is actually really cool. I want to take a note about this and talk about it on The Bike Shed with Steph.

+ +

And having this outlet, having this platform to be able to have those conversations and knowing that there are people out there is fantastic, although it's very weird because really, every one of these recordings is just you and I on a video call. And so there is an audience, I'm pretty sure. I think people listen to the show; I don't know, occasionally they write in, so it seems like they do. But at the end of the day, this really just feels like a conversation with a friend, and that has been so valuable to have. And yeah, I'm definitely going to miss that.

+ +

It's been a wonderful run, you know, four years is a long time. It's about as long as I've done most things in my career. And so I'm very happy with what we have done here. And there's a trite saying that isn't...yeah, whatever; I'll just say it, which is, "Don't be sad that it's over. Be glad that it happened." And I guess I'm still going to be sad that it's over. But I am so glad that I got the opportunity to do this, that you joined in this adventure and that we got to chat each week. It's been really delightful.

+ +

STEPH: I really liked how you refer to this as being a meditative state. And that is something that I have certainly picked up from you and thoroughly enjoyed that I have this space that I get to show up and bring these ideas and topics and then get to talk them out with you. And that has been such a nice way to either end the week or start a week. I mean, it doesn't matter. Anytime that we record, it's this very nice moment of the week where we get to come together and talk through some of the difficulties and share our stories.

+ +

And that's been one of my favorite moments is because you and I get to show up and share everything that's going on. But then when someone writes into the show or if they send a tweet or something and they share their story or their version of something that happened, or if they said that we made them laugh, that was one of my favorite accomplishments is the idea that something that we have done was silly enough or fun enough that it has brought them joy and made them laugh. So I, too, I'm very, very much going to miss this. It has been a wonderful adventure.

+ +

And I thank you for encouraging me to come on this adventure because I was quite nervous in the beginning. And this has definitely been an aspect of my life that started out as something that was very challenging and stretching my limits, and now it has become this very fun aspect and something that I get to show up and do and then get to share with everyone. And I do feel very proud of it, very much in part to Thom Obarski, who was our initial producer and helped us have that safe space to chat about things. And now Mandy, who keeps the show running smoothly and helps us sound our best week to week.

+ +

So it's been a wonderful adventure. This is going to be hard to let go. And I think it's going to hit me most. Like, this was one of those things as we're talking about it, it's, like, I'll see you next week. This will be fine. But I think it's going to hit me when there's something that I want to talk about where I'm like, oh, this would be great to talk about, and I'll add it to The Bike Shed Trello board. And I'll be like, oh yeah, that's not a thing anymore, at least not quite in the same way that it was.

+ +

CHRIS: So what I'm taking away from this is that you're immediately going to delete my phone number the minute we hang up this call and stop recording. [laughs]

+ +

STEPH: Oh yeah. I preemptively deleted. So that's already done. Friendship is over at this point.

+ +

CHRIS: That's smart. Yeah, because you might forget otherwise in the heat of the moment as we're wrapping this whole thing up.

+ +

STEPH: [laughs]

+ +

CHRIS: But actually, on that note, in a slightly more serious vein, again, there's this weird aspect where the audience is out there. But we're very sort of disconnected, particularly at the moment in time where we're recording. But it has been so wonderful getting various notes from listeners, listener questions, but also just commentary and the occasional thanks and focusing; oh, you pointed me in the direction, or you helped me think through a complicated piece of work or process a problem that we were having. And so that has been just so, so rewarding.

+ +

And one of the facets of this that has been so interesting to me is being able to connect to people and basically put out there what we believe about software, and for the folks that resonate with it and be able to have that connection instantly. And meeting people, and they're like, "Oh, I've listened to The Bike Shed. I like all these things." I'm like, oh, cool, we get to skip way further into the conversation because I've already said a bunch, and you say you like that thing. So, cool, we're halfway through our introductory chat.

+ +

And I know that we agree about a bunch of things, and that's really wonderful. And frankly, I'm going to miss that immensely. So for anyone out there who's found something valuable in this, who's enjoyed listening week to week, or perhaps even back to Upcase for things, I would love to hear from you. I'd love to connect to folks. Send me an email, Twitter. I'm on all the places. I'm Chris Toomey in various spots or ctoomey.com on the internet. Chris Toomey on GitHub. I'm findable, I think. Chris Toomey developer will probably get you there.

+ +

But I would really love to hear from folks, to connect to folks, you know, someday down the road; I think I'll be hiring again. And that'll be fun. I would love to work with some of the folks that have listened to this show or meet you at a conference, or if I happen to be traveling to a city or you're traveling to Boston. Really for me, so much of what this show is about is connecting with people around how we think about building great software. And so, I would love to continue that forward into the future. So yeah, say hi, if you're interested.

+ +

STEPH: I agree. That's been one of the most fun aspects of being co-host of the show. And I'll be honest, you are welcome to contact me, but I am going to be off-grid for probably six months. [laughs] So just know that there will be a bit of a delay before you hear back from me. But I would definitely love to hear from you.

+ +

I also want to say a very heartfelt thanks to a couple of people, just folks that have made this journey incredible and have made it so much fun. One, in particular, is everyone at thoughtbot for their continuous stream of knowledge. I mean, frankly, my software opinions wouldn't be half as interesting if it wasn't for everyone at thoughtbot constantly sharing their knowledge and being a source of inspiration. So I deeply appreciate everyone that has contributed to topics and ideas and just constantly churning out blog posts because those are phenomenal.

+ +

And I also want to give a shout-out to my husband, Tim, because he has listened to The Bike Shed for many years and even helped out with a number of show notes when that was something that you and I used to do before Mandy made our life so much easier and took that over for us. And has intervened a number of times when Utah mid-recording would decide it's time to play. So I want to give a very special thank you to him because he has been a very big supporter of the show and frankly helped me manage through a lot of the recordings for when I had an 80-pound dog that was demanding my attention.

+ +

CHRIS: I think continuing on the note of thanks; similarly, I'm so grateful to thoughtbot as an organization for everything that is represented in my career. It's a decade-plus that I have been following and then listening to the podcasts and then joining the organization, and then getting so many wonderful opportunities to learn about this thing called web development. And then, even after I left the organization, I was able to stay on here on The Bike Shed and hang out and still chat with you, Steph, which has been really wonderful. So thank you, thoughtbot, so much.

+ +

Thank you to Joël Quenneville, who will be the continuing host of the show. This show is not going anywhere. And, Steph, you and I aren't really going anywhere, but we won't be around anymore. But we are leaving it in the very, very capable hands of Joël, and I'm super excited to hear the direction that he takes it and Joel's incredibly thoughtful and nuanced approach to thinking about programming and communicating. So I think that will be really wonderful.

+ +

And lastly, I definitely want to thank Derek Prior and Sage Griffin, the two original hosts of this show, who really produced something wonderful, and for many years, I think it was about four years that they hosted together. I was an avid listener despite actually working at the company the whole time and really loved the thing that they produced and was so grateful that they entrusted me with continuing it forward.

+ +

And hopefully myself and then with the help of you along the way, we've...I think we've done an okay job, but now it is time to pass the torch or the green lantern. That's the adage I've been going with. Gotta pass the lantern, pass the mantle on to the next one. So, Joël, it's going to be in your hands now.

+ +

STEPH: Yeah, I'm so looking forward to future episodes with Joël Quenneville. They are going to be fabulous.

+ +

So I've been thinking in terms of this being our finale episode and then a fun ending for it, so there's a thing called the 21-gun salute, which is the military honor that's performed by firing cannons or artillery. Not to be confused with the three-volley salute, which I definitely confused earlier that is reserved and used at funerals, which this is not. So using the 21-gun salute, I was like, hmm, it is The Bike Shed, and we have this cute ring ring that goes. So I think for our finale, we should have a 21-bell salute as we exit the shed and right off into the sunset.

+ +

CHRIS: I love it. I couldn't imagine a more perfect send-off. So with that, what do you think? Should we wrap up?

+ +

STEPH: Yes, but I have one more silly thing to add. I've thought of a new software idiom that I'm excited about. And so, this may be my final send-off into glory that I'd like to share with you. And I think that we should make like a shard and split.

+ +

CHRIS: [laughs] I so appreciate that in this moment, this final moment that we have together, you choose to go with a punny joke. It is so on brand for the show. It is absolutely perfect. And I think with that note, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+fd4zxmPN + + ]]> + + Chris Toomey + Steph Viccari + + + 349: Unpopular Opinions + https://bikeshed.thoughtbot.com/349 + 362b134a-4b09-41e3-afa3-8161e91b5dcf + Tue, 09 Aug 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph and Chris announce Joël Quenneville as the new host of the show! 🎉 Joël talks about his grand plans for where The Bike Shed is going to go from here. (Okay, maybe not *grand* plans...!) + +Together, the group chats about unpopular opinions and hot programming takes. + 40:16 + no + + + Steph and Chris announce Joël Quenneville as the new host of the show! 🎉 Joël talks about his grand plans for where The Bike Shed is going to go from here. (Okay, maybe not grand plans...!) +Together, the group chats about unpopular opinions and hot programming takes. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Follow Joël on Twitter! Welcome him to the show. (https://twitter.com/joelquen) +Joël Quenneville - DRY is harmful for intermediate devs (https://twitter.com/joelquen/status/1415053350886903810) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript +CHRIS: Thank you. No brown M&M'S. No asking me weird questions. I ask very little. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: I'm Chris Toomey. +JOËL: And I'm Joël Quenneville. +STEPH: And together, we're here to share a bit of what we learned along the way. So, hey, Chris, what's new in your world? +CHRIS: What is new in my world? There is a new friend on the show with us today, Joël, developer extraordinaire, principal developer at thoughtbot, former coach of the Chicago Blackhawks (That one's not true, but it's funny to say.) and friend of the show, many time guest. Joël, so great to see you. How are you today? +JOËL: I'm excited to be joining the show. +CHRIS: Fantastic. So Steph and I shared with the audience in the previous episode that we have decided...we've made the heavy decision that it is time for us to hand over the hosting mantle. But we had yet to discuss exactly where that was going to go. And today, we are happy to share with you the specifics of that, which is that Joël will be taking over the hosting detail. So, Joël, do you have grand plans for where The Bike Shed is going to go from here? +JOËL: Maybe not in grand plans, but I'm definitely already planning content, lining up a few guests. I think the next few weeks are going to be a lot of interviews with some guests, a lot of co-workers at thoughtbot will want to share their stories or some exciting things that they're working on, things they are specialized in. +One thing that I really appreciate at thoughtbot is that we're all pretty full-stack developers. Everybody tends to have a specialization or an area they're really good at. And so when you're ever stuck, and you need advanced Git help, you go to, historically, Chris. If you want some help on security, you go to Mike Burns, et cetera. And so yeah, I'd love to bring in some of them and get to talk a little bit about some of the areas where they're either doing something interesting, or this is just an area where they have deep expertise. +STEPH: I have to say that having you take over as host of the show feels like such a nice continuation, given that you've been involved with The Bike Shed since you were a guest on the show back in 2018. And then, since then, you've been a repeat guest. And even when you're not here, Chris and I still frequently bring up your name and mention some of the talks and the blog posts that you have written. +So I'm super excited for everything that you just said, for all the guests that you're going to bring on the show, and the thoughtbot voices. And I'm looking forward to tuning into future episodes and hearing what happens next. +JOËL: Yeah, this is a really exciting transition for me. I am a long-time fan of the show. I've been a guest a few times. And now, coming on as a host is just taking it to the next level. +CHRIS: Yeah, Joël, I'm also super excited to see the new perspective that you bring to the show. And frankly, to Steph's point, you've been on the show a bunch of times. You've been here in spirit. In fact, there was a tweet that someone sent to us which was "Hey, @joelquen," which is your Twitter handle, "I feel as if I know you and your work after listening to @SViccari and @christoomey. They definitely appreciate you," which was true then and is true now. So I couldn't be happier for you to be taking over this hosting slot. +JOËL: Creating content for developers and sharing the things I've learned, or the things that I've experienced with other people has always been something that's been really important to me. And so, getting a chance to bring that to The Bike Shed is a really exciting opportunity. +My past work has intersected with the show several times, either that's been conference talks or blog posts, or even just conversations we've all had. Steph and I pair almost every day. So there are a lot of good conversations. A lot of conversations that end with me saying, "You should talk about that in The Bike Shed. That's a good topic." +STEPH: You have been an excellent source for topics in terms of you've literally added stuff to our Trello board that we use to manage the show and then yes, and all those conversations that we've had. You're like, "Oh, this will be a good Bike Shed topic." And I'm like, "Hold please," while I go and then add it to our board. +JOËL: The fun of being an employee at thoughtbot is that I have access to the Trello board. And I can just add whatever ideas I have there for you all to talk about. [laughs] +CHRIS: That is the most direct way to send in a listener question is just to write it into the Trello board directly. Skip all the forms, and the Twitter, and the whatnot. +JOËL: Yeah, speaking of topics on our Trello board, let's go out on a really spicy one. I see we have a card about unpopular opinions. Chris, you created this. What is your hot programming take? +CHRIS: This was so long ago, I don't even remember. But this one has interestingly sat on the Trello board for a while. I was like, Steph, let's really lean into it. Let's go out there. What are our extreme takes? And I think we say the stuff that's in our heart most of the time anyway. But we're; also, I don't know, pragmatic, kind of boring up the middle. +Someone recently described my tech choices as like a Subaru. Like the architecture, the way I built it, you know, it's stable. It'll get to where you want to go. It's not going to be too fancy or too flashy. And I was like, you know, actually, humorously, my wife and I just bought a Subaru. So I was like, I guess I can't say no to that. +Anyway, though, I think I have one spicy take, which I have shared on The Bike Shed before. But it is the thing that I will die on this hill. I care about this. It feels like I'm just being persnickety, but I think it matters, which is that the phrase single-page application or the idea of an S-P-A or a SPA, which I've heard some people say it, is just a terrible framework. I am so unhappy with it as a concept. +I think, technically, the implementation of them has often led to some really complicated things, which is why I've spent so much time exploring Inertia, or LiveView or Livewire, or all of the other options that are out there. I think there are some really interesting novel ways. Remix.run is the most recent thing that I've been talking about, which takes a pretty traditional SPA type of build and then makes it behave more like a traditional server-rendered application. +But just the idea single-page application really grinds my gears that that is a thing that we talk about. Because it's the web, we have URLs; these should all be different pages. I don't care if there's one bundle of JavaScript that we send down or that it begins as a single HTML file that we send down, and then we repopulate constantly. There still should be URLs. Those are a honkin' good idea, and we should use more of those. And we shouldn't anchor to a technology...like, no, SPAs, I don't like it. I'm not a fan. So that is my unpopular opinion, I'm pretty sure. +STEPH: I think we have a full episode, too, where we focused a lot on that topic where you shake your fist at the SPAs in the world [laughs] and why you don't like them. +JOËL: I feel like the industry pendulum might be swinging back. I think we've hit peak SPA, and now we're slowly moving back, anecdotally anyway. +CHRIS: That is definitely what I'm seeing more and more of, and I'm very happy for it. Because I think there's some interesting stuff that came out of SPAs and the ideas of like, oh, let's animate, and let's have more continuity and page transitions and things that I think can really enhance the end-user experience. But I think the cost has been too high. It's broken us from some of the norm. +Like, how does the web work? That's a thing that we should talk about. Links, they're awesome. You can link between pages. It's so cool. And we just kind of threw that away. And we're like, div onclick. It'll be fun. Don't worry about it. Screen readers, who cares about those? Doesn't even matter. I care. That's who cares. I'm going to calm down now. I'm fine. It's fine. But yes, I agree. I do think the pendulum is swinging back, and I'm very happy to see that. +JOËL: Long-time listeners of the show will know that I'm a big fan of the Elm language. And for the longest time, I wanted to do a client project at thoughtbot with it. But I agree with you, Chris, that a lot of things shouldn't be SPAs. A lot of things should be just boring Rails apps. And so, every time an opportunity came, I just couldn't justify doing a front-end app. So I would be like, yay, I would love to do Elm here, but this should just be a vanilla Rails app. +And then, one day, we had a project that came in that was actually a single-page app. It was one page where you loaded up a bunch of data streams and then could interact with them and get all these cool visualizations and things. There was no clicking away. There were no other pages. It was just load some data, and you've got a playground. And that was the moment I knew, okay, this is the app I want to do in Elm. And that was my introduction to bringing Elm to colleagues at thoughtbot to work on a project together. +STEPH: You put out the signal kind of like the Batman signal, but you put out the Elm signal calling everybody into the project. +JOËL: [laughs] +CHRIS: You put a small tree on your desk, and everyone came together around it. +JOËL: [laughs] +CHRIS: Also, I want to applaud your pragmatic restraint of I want to use this. This would be fun to use, but it is not the right choice for many particular applications or projects that came through the door. But then you found it. Then you found that magic moment. +To be extra clear, I'm not opposed like; my distinction is an SPA or traditional server-rendered HTML generation on the server...I got redundant in there, but that'll be fine. It's more the bundle of JavaScript that goes down and that there's no routing on the server-side, et cetera, that all logic is pushed to the client-side. +I've harped on about Inertia and my love for that framework over many, many an episode on the show. But I feel like that, and many other solutions that are in that similar space, allow us to have the sort of experiences that are traditionally associated with an SPA but don't give up on the idea of auth being simply managed via a cookie on the server sort of thing. Cookie on the server is a phrase that doesn't really make sense. But y'all get what I'm saying, I hope. If not, assume that I said the right thing. It'll be more fun that way. +JOËL: Steph, I'm curious; what's maybe one of your unpopular opinions or hot takes? +STEPH: I have a couple, and since Chris used a phrase that has now helped anchor me in terms of like the hill that I will die on, I'm now looking through that list to pick the one that I feel like the most passionate about. So looking through that list, I might just have to go a couple. It's hard to really choose. +But the first one is I'm going to say you don't need a side project. I can't tell you how much that frustrates me when people just always say you have to do something on the side. You have to stay up late and code. You have to do coding on the weekends. I feel very strongly that software development is a job, and it doesn't have to be your passion; if it is, that is fabulous. +But it is, at the end of the day, still a job, and you don't need to know three additional languages to be good at your job. And you should be able to focus on learning what makes your day-to-day easier and then learn that during your work hours. So that's something I feel very strongly about. +JOËL: Do you think that's something that is a current reality or something that is aspirational? As in, an employer shouldn't require it, or it is currently possible to have a completely fine career and never have a side project. +STEPH: I think it's very possible currently and aspirational for some teams. I think there are some companies and teams that will turn you down because you don't fit that mold. And I think that's what then puts us in that unpopular opinion category. Because there are enough people that still think that that is an important part of being a software developer. +But I do think that there are still plenty of teams and people that are starting to agree with the idea that it shouldn't be that way and that that is not a requirement for an interview, or for joining the team, or for being a good developer, or for progressing in your skills. So a little bit of both, currently possible and also aspirational. +JOËL: I'm going to throw a question out, and I think this may be its own complete topic. So feel free to tell me that this is not the day to talk about this, but I'm going to put a question out. Recently, there was a really good conversation that happened internally at thoughtbot where one of our newer developers was asking, is it possible to progress our whole career ladder without ever doing any side projects? So just 32 hours of client work, eight hours investment time every week. +And maybe a little bit beyond that, maybe it's technically possible. But it takes an excruciatingly long time. Is it possible to progress in a reasonable amount of time through the career ladder without doing any extra work outside of our standard working hours? What are your thoughts on that for thoughtbot? +STEPH: I think the answer has to be yes. Because I mean, who's creating that ladder that you are climbing? It's going to come down to the company and the managers and the people who are deciding on how you advance, and not everybody has time. So what you're telling me is that if someone can't advance during the normal work hours that they have then...because they have families; they have other priorities in their life; they have other responsibilities, that then they're just stuck? And that feels like an unacceptable answer to me. So my answer is absolutely you can progress during the work hours that you have. And if you can't, then that is a problem for managers and leadership to fix. +CHRIS: I definitely agree with the assertion that you're making, Steph. And I like the ire that you're bringing to this. This is good. This is the sort of fire that we should have in this particular segment. I do think there was an aspect of the question that is subtle and really interesting to me, which is in a reasonable amount of time. And then you mentioned, or it might take an excruciatingly long amount of time. +A thing that I observe about our industry is that it is rather young overall, and the expectations of progression are incredibly rapid. This is sort of my second career. I spent three years as a mechanical engineer working in industry. That was the first thing that I did. And that world looks wildly different. +The idea of achieving principal engineer, which is a little bit more formalized of a concept, but I saw that as 30 years down the road kind of thing, or it may be 20, or something, but a significant chunk of my career. That is something I might achieve towards the end of my career after having put in a lot of time. +And development is just such a young industry. Like, the idea of going to a bootcamp and then two years later being a senior engineer and continuing to progress just ever so rapidly is interesting. I don't want to slow anyone down by any means. And I don't want to say that like, well, when I was over there, it was slower, and so it should be slower here. But I don't think it's realistic, frankly. +And I think some of what is at the heart of this question is like, no, this is an industry where you get in there, and in five years, you have achieved the pinnacle of your career. And then you go retire, and you go to a cabin in the woods, and you never talk to humans or touch a computer again. That's the dream. It's like, well, maybe that's not realistic. And what would it actually look like if we were a little more chill about these sorts of things? That is a question that I have. +STEPH: It's funny that you mentioned that one because that was one that I almost put on my list of unpopular opinions where I think the progression in which we change our titles as developers is silly, [chuckles] is probably the best word that I have for it. Because I agree with you, I don't want to slow people down. And we often change our titles to reflect that, yes, we want more responsibilities. We want more pay, and so that feels like the best way to then achieve those goals. +But it's so rapid in how we expect people to progress to different levels of engineering. I do think it loses a bit of its meaning because then we progress people so quickly through those different roles. Because then senior developer means so much. I mean, are you a senior developer with two years of experience or ten years of experience? Like, you could be in both of those groups. And so, it just loses some of its meaning because of that. +JOËL: It's also hard because years of experience aren't really a good way to compare two developers. I mean, two versus 10 is probably something you can compare very roughly. But five versus 7 or 5 versus 10, someone might be much more experienced or be better at solving problems after five years than somebody else in 10. +CHRIS: I will argue that two years in a consultancy is like five or maybe even ten years in a middle-of-the-road product company that's kind of got its stuff figured out. And just the volume of new and novel that will come at you is quite large. And I strongly recommend working with a lovely company called thoughtbot to get that experience because it'll be a fun time while you're there. And, man, will you learn a lot. +MID-ROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half. +So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPH: Joël, I have another potentially unpopular opinion I'd love to share. But I'm curious, what's one of yours? +JOËL: So here's a controversial opinion that I have: DRY, Don't Repeat Yourself, is dangerous, I'd say even a harmful rule of thumb for intermediate developers. It's one of our favorite kind of aphorisms, principles that we try to live by as developers. But I think it often does more harm than good at a certain point in your career. +When you start off as a new developer, one of the most common sorts of bugs you'll do is where you duplicate code, and then you change it in one place and don't change it in the other. And they're out of sync, and then your code breaks. And then you discover DRY, Don't Repeat Yourself. And it's amazing because this simple rule fixes 80% of the bugs you were creating. And of course, now there are other types of bugs you find out about. But it's a whole class that gets eliminated by that, and it's wonderful. +But then you get into the intermediate developer, and you start to get clever, and you try to apply this in a lot of places. And you start trying to abstract things that are similar but not the same, and then they start to diverge. And then you've got a mess on your hands. And this happens in application code happens in test code. +Yeah, you end up doing that, prematurely abstracting, and particularly when it's just based on through a simple substring matching. So you're saying this string of 100 characters is identical in two files. We need an abstraction that shares these two when the fact that the two strings might be similar is just coincidental. And so that's where you cause more harm than good. And then eventually, you kind of transcend that, hopefully, and get back to the point where you can maybe apply DRY more judiciously. +Now, DRY is no longer for you about similar characters. It's about similar or actually same concepts because similar is not good enough. And hopefully, you have the discernment to distinguish between similar and same. And when you're not quite sure, maybe you leave them separate to see will they diverge in the next few months? +STEPH: It's almost like you and I are on the same project, and we have felt similar pains in the world. +JOËL: [laughs] I think this is a thing that a lot of developers eventually get to the point where they can do it decently well in production code. But at least when it comes to RSpec code, the Ruby community has just refused to learn this lesson. We're still stuck in that intermediate developer phase where everything's got to be extracted out as shared setup. And I would argue that shared setup on most tests is similar and not same. And the identical thing is if you're just copying two strings of code that look similar in two files and creating an abstraction that really doesn't need to be there. +CHRIS: Friends, I have to tell a truth in this moment. I wrote a let within an RSpec file this week. It happened. +JOËL: [Gasps] +STEPH: This is actually why you're moving off the show, Chris. This right here. [laughs] +CHRIS: I'm getting kicked off the island. I've broken rule number one [chuckles]; let's not. This was...I think it was a reasonable one; at least I couldn't figure out a different way to do it. I was defining a class within an RSpec file, a representative implementation of a subclass. And I tried to do it by just defining a class in line, but RuboCop came along; we recently added RuboCop to the app as well. And RuboCop said, no, no, no, you are leaking a constant. And I said, oh, that's true, RuboCop. +And then, thankfully, the documentation page for that rule had a pointer to what to do instead. And so it ended up with a let. I don't actually think I need to let now that I think about it. You can dynamically define a class within a spec example. So I then, in the rest of the example, started doing that. So I'll probably remove the one let that I actually added. [laughs] But it happened. +JOËL: That honestly seems reasonable to me. I think there are use cases where let can be done correctly. It's just really hard to have the discipline to not stray off that very narrow path of safety. I recently gave a talk at RailsConf about how your test suite is making too many database calls. And most of them are all related to doing way too much during your setup phase. +And one of the reasons I gave that this happens too often is shared setup and let in particular. And I thought that I might get booed off the stage. But in fact, several people came up to me afterwards and told me that I had actually given them a whole new perspective they had never seen, and that was interesting to them. +STEPH: That's awesome. That's so nice that people came up and shared that with you. Yeah, I think one of the areas that I don't know if we highlight enough, but whenever you and I happen to gripe about the use of let or over drying and extracting setup for tests, specifically, is because then we're not talking about the trade-off of then you're coupling all your other tests to that extracted setup. +And so it's not so much that I care that you dried up your test setup, and now the rest of my tests are likely reliant on that extracted shared setup. And then that's where we've introduced a trade-off, and it's a painful trade-off that I have worked through a number of times. So just to add a bit of persnicketiness to our discussion in terms of it's not so much the DRY in the extraction that bothers me, it's then the trade-off of now everything is coupled. And it becomes much harder to then create independent scenarios that are still easy to read and then modify. +JOËL: Because you're coupling two things that are not the same, that want to diverge. And now you're forcing them down a single path. And I think probably the biggest, reddest flag you can get that you've misDRY-ed is where you try to introduce conditionals to your shared extraction. Because the whole point of a shared extraction is that everything is the same. And so once you start introducing branching in there, you know something's gone horribly wrong with your abstraction. +STEPH: Okay, so I think we've established that we've got very strong, maybe popular, unpopular opinions about DRY and especially using DRY in test setup. What's another unpopular opinion that you have, Joël? +JOËL: This one is a stylistic one. But I think that in Ruby, at least, every if should come with an else. You want something to happen when your condition doesn't trigger. I think it generally makes for more readable code and also prevents some implicit nils from getting through. And nil errors are probably at the top of your bug backlog if you were to look at right now (For all of you listeners, I'm pretty sure that's true.), excluding JavaScript. +CHRIS: Someday, we're going to make undefined a function, and it's going to be a great day. This is an interesting one, Joël. I'm inclined to agree with you, but I know that in my code, I don't necessarily follow this adage. So I find it interesting. I would call them intentional nils; I'm sometimes fine with that, or particularly in side effect-y code, you know, if this condition, then do something, otherwise, nothing. +But yeah, it is interesting. The explicitness, the nil, is a big mistake that seems true. You hang out in Elm for long enough, and you don't have one, and then you got to think about stuff harder. But yeah, I don't find myself doing this. So I find it interesting. I conceptually agree with what you're saying, and yet my code tells other stories. +JOËL: So I would argue that Ruby is an expression-oriented language; all methods auto return something as opposed to a statement-driven language like JavaScript, where nothing returns unless you explicitly return it. Ruby is all about those return values. And so you need to cover all branches, and if you don't, Ruby will implicitly have some branches that you don't have there. And so, I prefer to make visible the branching logic that's happening. +STEPH: I also like this one. I think I'm on the same page as Chris, where I like the opinion and this statement. And then also, you'd asked me earlier about whether something is capable now versus aspirational. And this feels like in the aspirational area for me where I agree with it, but I don't necessarily do it. But I think it makes a lot of sense because then it does force you to think about what is the return value? And to be very explicit and say, yep, no, I want a nil here. That's just what I'm going to return. +JOËL: And maybe even think about in that else case maybe you don't always want nil, maybe you'd rather return an empty string, or a null object, or something like that. And forcing you to actually manually type that value in instead of just being like yeah, Ruby knows. It'll put a nil there. It's easy to not think about the error edge cases, which I know is the opposite of how Chris thinks. Chris thinks about all the error edge cases. +CHRIS: My brain has been shifted by experience. +JOËL: One thing that I think this works really well is a stylistic approach that I use where I separate branching code from doing code. So in a particular method, if there is a conditional, then the body of the conditional calls out to another method. It doesn't implement logic there directly. And if a method does a calculation, or does the side effect, or does some kind of work, it's not allowed to have a conditional in it. So an individual method either gets to branch, or it gets to do a thing but not both. +STEPH: Is that so you can quickly see all of the branching that's involved so you can see it at a very high level versus if you have a very large branching in your method and then it's hard to see how many possible return values that you have? +JOËL: Yes. I like it because when you read code, especially when you're reading code that has a conditional in it, typically, you're reading it at a higher level of abstraction. You just want to know what are the possible ways that it can branch, and then what are the paths it can go down? And you probably don't care about all the nitty gritty implementation details that happen at each branch. +And then you might care about one particular branch and decide to go down that path. At that point, you will jump to that method. But you don't need to have all 2 or 3 or 10 branches expanded for you. It keeps the method at a single level of abstraction and also allows each method, in a certain extent, to have a single responsibility. It does one thing. It's either branching between n choices, or it does one thing, but it doesn't try to do multiple things. +So that's less of a hot take opinion, like, everyone should write code that way. That's just a style I've adopted for myself that works really well. But that particularly dovetails nicely with my hot take, which is if should come with an else. +STEPH: I like it. +JOËL: Yeah, so, Steph, do you have another juicy opinion you'd like to share with our listeners? +STEPH: Yeah, I've got one more to share, and this one is going to show my consulting roots. And it's that developers should be included in the design and planning phases, and not just in the execution phase of the work. So that's something that I've seen a number of teams struggle with where they wait until either design is considered completed or perfect or someone else has figured out the way that they want a feature to be built, and then they just essentially throw it over the wall and kick it over to the development team. +And so then it's laid out with very specific criteria. But it's not clear the problem that's actually being solved. And so developers have done a very narrow focus of what they're working on. And you just often end up building the wrong thing when that happens because people don't have the context. They don't know the questions to ask if they do run into some questions regarding the requirements. +And so I strongly advocate that developers shouldn't just pick up tickets and then write code, that they should be part of the planning and the product process as well. Turns out that developers often have really good ideas when it comes to features. And they also have a lot of knowledge about the application and can ask good questions. So why not include them in that process? +JOËL: You mentioned that this is inspired by your experience as a consultant. I've sometimes heard the contrast between the terms contractor versus consultant. Is that a distinction that you make? +STEPH: Yes and no. Yes, because I've heard other people make that distinction, but I personally wouldn't make that distinction. And even for people who are not a contractor or consultant but they're full-time, I still love when people can adopt the mentality of you have the same responsibility of this product and where it's headed and its technical decisions. +And we all should be mindful of the time that we're spending as we're working on something. And I think being a consultant helps you be more mindful in terms of like, oh, I've spent two hours on this problem. I should probably reach out for help. And I feel like people who haven't had an opportunity to be in that mindset don't think that way. But I think it's a really wonderful state to be in all the time just to think through; okay, I've been stuck for an hour, now's the right time that I should reach out for help. Versus spending like a full day on something and then reaching out for help. +So I have heard that distinction, but I personally wouldn't make that distinction. I would advocate that even if you are a consultant, or full-time, or contractor that ideally, you would still be part of those different processes to then help build a valuable product. +JOËL: Steph, I found it really interesting when you introed this idea. It was about developers bringing their ideas to the business and design side of things. But then, when you dug into the idea a little bit more, you kind of flipped it on its head and said that being involved in those meetings helps developers do their job better because now they can more appropriately timebox a feature or decide when they've hit that 80% point that's good enough to ship, and then they need to reprioritize something else. So it sounds like there are advantages to both sides, both the business side and the dev side, from a tighter integration there. +STEPH: Yeah, thanks for calling that out. I think that's an excellent point that I hadn't really even considered as I was just rambling about a strong feeling. But yes, I think it's beneficial to all sides. It's beneficial to developers who are getting the work done. And then I also think it's really beneficial to the product team and design just because that way, everybody essentially has the same context. They're on the same page. +And then you also have more camaraderie that way too in terms of people know the problems that they're trying to solve. And you can have more opinions. And people can surface those ideas versus if you are kept in the dark as to perhaps why a feature is being built or who it's geared towards, then it's more likely that you're not going to be as connected with the rest of the team and be able to provide helpful ideas because you won't have the fuller context to then surface that to the rest of the team. +So this is definitely coming just from all of my experience in the projects that I've been on that the most successful projects include design, and developers, and product management. And they all get together, and they talk about the problems that are being solved. Versus the projects that I've been on where essentially, all of that work is done separately, and then there's just a Trello board or Jira tickets or whatever tool that you're using. And then developers go and pick up tickets. +Because then you often end up having those discussions anyway because developers are then going to have to check in to say, hey, you said this thing. Did you mean this? What exact requirements am I looking for? By siloing that process elsewhere, you end up just duplicating your efforts because that conversation is ideally going to happen anyways. +JOËL: I recently had a conversation with someone who had been promoted to senior developer and was asking me for some advice on how do you be a senior at your job. And this is at a product company. And basically, what you were saying, Steph, is what I recommended. If, as a senior developer, you are just a machine that converts tickets into code, they're not using you to your full potential. And honestly, they're overpaying for what they're getting. +You need to be in those meetings, in those conversations, so that, as you mentioned, you can be that nexus between business and tech and tell them, look, this is your strategic goal. You think this is the technology thing you want to do. Yes, it will solve your problem, but it will take twice as long. +And that is incredibly valuable to the business people because doable and easy, and very similar solution that is near impossible to do in tech are very common. There's a classic xkcd about this situation. And so having someone who knows that nuance and can recommend and say, look, we can do this in two weeks. That will take six months. Or even just talking through trade-offs is incredibly valuable. +And then, as you said, bring that back in your own work, knowing when to say, look, we thought this is going to take two weeks, and it's taking more. We think this is going further. We know that the business goal is to get to here. So I'm going to pause on this and propose a different technical solution that will get us most of the way towards that goal while still respecting the deadlines we're working under. +I might argue that this sort of mindset is not just a senior developer thing. It's valuable at mid-level and junior as well. And I think that as a consulting firm at thoughtbot, that's something that we bring in from the beginning for everyone that we try to build this. But definitely, as you move up into your career, this is going to become more and more important. +CHRIS: Yeah, I'm surprised. I'm actually totally on the opposite side of this one. I fundamentally disagree with...no, I totally agree with everything you're saying and how important these sorts of conversations are. We're actually working on something at Sagewell right now. It's a new, reasonably large integration with an external platform. +And we're very, very intentionally pushing such that product and design are going off and doing some work, and engineering is going off and doing exploratory what do the APIs actually look like? What's the data that we need? What's the object model in this system? What can we get away with not providing? What do we need to provide? +And continually, we're just trying to encourage communication across those different tracks. So design is thinking about different flows and what's the experience a user is going to have. And ideally, getting engineering to review that and say, "Oh, that's going to be easy. That'll be hard. I think we could do that, but I actually have to go look it up and see if that's possible," and vice versa. +Engineering now being in the depths of saying like, "Oh, actually, this has to be done in this way for legal reasons or whatever it is," and then providing that back to design and product to think about how do we structure it? How do we sequence things? What's part of the MVP? And I've been really happy with the nature of that, that back and forth communication. +But it is definitely something that requires intentional work of making sure that we're not just falling into our own silos, but we're coming up for air, having those conversations, passing ideas back and forth, including each other in the conversations. But without question, it will produce a better outcome at the end of the day. So yeah, I actually do, in fact, agree 100%. +STEPH: Yeah, to add on to that just a bit, there is a particular example that comes to mind where I felt the most pain for when developers and product and design aren't in the same room and then discussing the work to be done. And that's essentially where someone ends up building the wrong thing. And it's because someone decided that they knew the best solution for something, but they didn't really collaborate with the rest of the team. They turned that into a ticket. +So then a developer sees that, and then they start implementing, and it's not until later that someone comes along and starts asking questions to say, "Hey, so what problem are we solving?" Or "Why are we adding this code?" And Joël, I think you said it perfectly and that this is something that I do expect of a more senior developer where they have that experience, and they ask those types of questions that then you realize that, oh, we've actually built the wrong thing, or the thing that we're building doesn't solve the problem that we had in mind. +And at that point, you have someone who has invested a week, maybe a couple of weeks into something, so then that feels really terrible to then say, "We actually need to scrap this" or "We need to totally rethink this." So then you start making trade-offs of like, well, maybe we can keep this portion or preserve some of the work that you've done. And so you just end up in a really messy state. And that can be avoided if people are collaborating at an earlier stage of that process. +JOËL: Yes, you and I, Steph, were in a very particular situation where something like this had happened. Some developer had been working on a ticket for a couple of weeks. And it was one of those tickets that just kept growing. The code kept growing, but then the client kept adding new requests and features onto it. And then, at some point, you and I were brought in to help, and the first thing we had to do is like, let's stop and ask what is the problem that is actually being solved here? +And actually got everyone together with the client. And that conversation helped us do a big reset and helped us find a way that was more focused that actually solved the underlying problem, what the client actually wanted rather than what they said they wanted. +I noticed that for most of these unpopular opinions, it sounds like we pretty much all agree with each other. So either we all have a very similar set of unpopular opinions, or maybe these opinions might be a little bit more mainstream than we give them credit for. I find that oftentimes, at least on Twitter, when people tag things as "unpopular opinion" in quotes, they may be a little bit more popular than people give credit for. +CHRIS: I feel like the RSpec one is unpopular. And also, have you asked Steph about Pop-Tarts? +JOËL: [laughs] +CHRIS: Because we are capable of having sincerely unpopular opinions. +JOËL: Let's save that for the next episode. And on that note, shall we wrap up? +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph and Chris announce Joël Quenneville as the new host of the show! 🎉 Joël talks about his grand plans for where The Bike Shed is going to go from here. (Okay, maybe not grand plans...!)

+ +

Together, the group chats about unpopular opinions and hot programming takes.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Follow Joël on Twitter! Welcome him to the show.
+Joël Quenneville - DRY is harmful for intermediate devs

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript

+ +

CHRIS: Thank you. No brown M&M'S. No asking me weird questions. I ask very little.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: I'm Chris Toomey.

+ +

JOËL: And I'm Joël Quenneville.

+ +

STEPH: And together, we're here to share a bit of what we learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What is new in my world? There is a new friend on the show with us today, Joël, developer extraordinaire, principal developer at thoughtbot, former coach of the Chicago Blackhawks (That one's not true, but it's funny to say.) and friend of the show, many time guest. Joël, so great to see you. How are you today?

+ +

JOËL: I'm excited to be joining the show.

+ +

CHRIS: Fantastic. So Steph and I shared with the audience in the previous episode that we have decided...we've made the heavy decision that it is time for us to hand over the hosting mantle. But we had yet to discuss exactly where that was going to go. And today, we are happy to share with you the specifics of that, which is that Joël will be taking over the hosting detail. So, Joël, do you have grand plans for where The Bike Shed is going to go from here?

+ +

JOËL: Maybe not in grand plans, but I'm definitely already planning content, lining up a few guests. I think the next few weeks are going to be a lot of interviews with some guests, a lot of co-workers at thoughtbot will want to share their stories or some exciting things that they're working on, things they are specialized in.

+ +

One thing that I really appreciate at thoughtbot is that we're all pretty full-stack developers. Everybody tends to have a specialization or an area they're really good at. And so when you're ever stuck, and you need advanced Git help, you go to, historically, Chris. If you want some help on security, you go to Mike Burns, et cetera. And so yeah, I'd love to bring in some of them and get to talk a little bit about some of the areas where they're either doing something interesting, or this is just an area where they have deep expertise.

+ +

STEPH: I have to say that having you take over as host of the show feels like such a nice continuation, given that you've been involved with The Bike Shed since you were a guest on the show back in 2018. And then, since then, you've been a repeat guest. And even when you're not here, Chris and I still frequently bring up your name and mention some of the talks and the blog posts that you have written.

+ +

So I'm super excited for everything that you just said, for all the guests that you're going to bring on the show, and the thoughtbot voices. And I'm looking forward to tuning into future episodes and hearing what happens next.

+ +

JOËL: Yeah, this is a really exciting transition for me. I am a long-time fan of the show. I've been a guest a few times. And now, coming on as a host is just taking it to the next level.

+ +

CHRIS: Yeah, Joël, I'm also super excited to see the new perspective that you bring to the show. And frankly, to Steph's point, you've been on the show a bunch of times. You've been here in spirit. In fact, there was a tweet that someone sent to us which was "Hey, @joelquen," which is your Twitter handle, "I feel as if I know you and your work after listening to @SViccari and @christoomey. They definitely appreciate you," which was true then and is true now. So I couldn't be happier for you to be taking over this hosting slot.

+ +

JOËL: Creating content for developers and sharing the things I've learned, or the things that I've experienced with other people has always been something that's been really important to me. And so, getting a chance to bring that to The Bike Shed is a really exciting opportunity.

+ +

My past work has intersected with the show several times, either that's been conference talks or blog posts, or even just conversations we've all had. Steph and I pair almost every day. So there are a lot of good conversations. A lot of conversations that end with me saying, "You should talk about that in The Bike Shed. That's a good topic."

+ +

STEPH: You have been an excellent source for topics in terms of you've literally added stuff to our Trello board that we use to manage the show and then yes, and all those conversations that we've had. You're like, "Oh, this will be a good Bike Shed topic." And I'm like, "Hold please," while I go and then add it to our board.

+ +

JOËL: The fun of being an employee at thoughtbot is that I have access to the Trello board. And I can just add whatever ideas I have there for you all to talk about. [laughs]

+ +

CHRIS: That is the most direct way to send in a listener question is just to write it into the Trello board directly. Skip all the forms, and the Twitter, and the whatnot.

+ +

JOËL: Yeah, speaking of topics on our Trello board, let's go out on a really spicy one. I see we have a card about unpopular opinions. Chris, you created this. What is your hot programming take?

+ +

CHRIS: This was so long ago, I don't even remember. But this one has interestingly sat on the Trello board for a while. I was like, Steph, let's really lean into it. Let's go out there. What are our extreme takes? And I think we say the stuff that's in our heart most of the time anyway. But we're; also, I don't know, pragmatic, kind of boring up the middle.

+ +

Someone recently described my tech choices as like a Subaru. Like the architecture, the way I built it, you know, it's stable. It'll get to where you want to go. It's not going to be too fancy or too flashy. And I was like, you know, actually, humorously, my wife and I just bought a Subaru. So I was like, I guess I can't say no to that.

+ +

Anyway, though, I think I have one spicy take, which I have shared on The Bike Shed before. But it is the thing that I will die on this hill. I care about this. It feels like I'm just being persnickety, but I think it matters, which is that the phrase single-page application or the idea of an S-P-A or a SPA, which I've heard some people say it, is just a terrible framework. I am so unhappy with it as a concept.

+ +

I think, technically, the implementation of them has often led to some really complicated things, which is why I've spent so much time exploring Inertia, or LiveView or Livewire, or all of the other options that are out there. I think there are some really interesting novel ways. Remix.run is the most recent thing that I've been talking about, which takes a pretty traditional SPA type of build and then makes it behave more like a traditional server-rendered application.

+ +

But just the idea single-page application really grinds my gears that that is a thing that we talk about. Because it's the web, we have URLs; these should all be different pages. I don't care if there's one bundle of JavaScript that we send down or that it begins as a single HTML file that we send down, and then we repopulate constantly. There still should be URLs. Those are a honkin' good idea, and we should use more of those. And we shouldn't anchor to a technology...like, no, SPAs, I don't like it. I'm not a fan. So that is my unpopular opinion, I'm pretty sure.

+ +

STEPH: I think we have a full episode, too, where we focused a lot on that topic where you shake your fist at the SPAs in the world [laughs] and why you don't like them.

+ +

JOËL: I feel like the industry pendulum might be swinging back. I think we've hit peak SPA, and now we're slowly moving back, anecdotally anyway.

+ +

CHRIS: That is definitely what I'm seeing more and more of, and I'm very happy for it. Because I think there's some interesting stuff that came out of SPAs and the ideas of like, oh, let's animate, and let's have more continuity and page transitions and things that I think can really enhance the end-user experience. But I think the cost has been too high. It's broken us from some of the norm.

+ +

Like, how does the web work? That's a thing that we should talk about. Links, they're awesome. You can link between pages. It's so cool. And we just kind of threw that away. And we're like, div onclick. It'll be fun. Don't worry about it. Screen readers, who cares about those? Doesn't even matter. I care. That's who cares. I'm going to calm down now. I'm fine. It's fine. But yes, I agree. I do think the pendulum is swinging back, and I'm very happy to see that.

+ +

JOËL: Long-time listeners of the show will know that I'm a big fan of the Elm language. And for the longest time, I wanted to do a client project at thoughtbot with it. But I agree with you, Chris, that a lot of things shouldn't be SPAs. A lot of things should be just boring Rails apps. And so, every time an opportunity came, I just couldn't justify doing a front-end app. So I would be like, yay, I would love to do Elm here, but this should just be a vanilla Rails app.

+ +

And then, one day, we had a project that came in that was actually a single-page app. It was one page where you loaded up a bunch of data streams and then could interact with them and get all these cool visualizations and things. There was no clicking away. There were no other pages. It was just load some data, and you've got a playground. And that was the moment I knew, okay, this is the app I want to do in Elm. And that was my introduction to bringing Elm to colleagues at thoughtbot to work on a project together.

+ +

STEPH: You put out the signal kind of like the Batman signal, but you put out the Elm signal calling everybody into the project.

+ +

JOËL: [laughs]

+ +

CHRIS: You put a small tree on your desk, and everyone came together around it.

+ +

JOËL: [laughs]

+ +

CHRIS: Also, I want to applaud your pragmatic restraint of I want to use this. This would be fun to use, but it is not the right choice for many particular applications or projects that came through the door. But then you found it. Then you found that magic moment.

+ +

To be extra clear, I'm not opposed like; my distinction is an SPA or traditional server-rendered HTML generation on the server...I got redundant in there, but that'll be fine. It's more the bundle of JavaScript that goes down and that there's no routing on the server-side, et cetera, that all logic is pushed to the client-side.

+ +

I've harped on about Inertia and my love for that framework over many, many an episode on the show. But I feel like that, and many other solutions that are in that similar space, allow us to have the sort of experiences that are traditionally associated with an SPA but don't give up on the idea of auth being simply managed via a cookie on the server sort of thing. Cookie on the server is a phrase that doesn't really make sense. But y'all get what I'm saying, I hope. If not, assume that I said the right thing. It'll be more fun that way.

+ +

JOËL: Steph, I'm curious; what's maybe one of your unpopular opinions or hot takes?

+ +

STEPH: I have a couple, and since Chris used a phrase that has now helped anchor me in terms of like the hill that I will die on, I'm now looking through that list to pick the one that I feel like the most passionate about. So looking through that list, I might just have to go a couple. It's hard to really choose.

+ +

But the first one is I'm going to say you don't need a side project. I can't tell you how much that frustrates me when people just always say you have to do something on the side. You have to stay up late and code. You have to do coding on the weekends. I feel very strongly that software development is a job, and it doesn't have to be your passion; if it is, that is fabulous.

+ +

But it is, at the end of the day, still a job, and you don't need to know three additional languages to be good at your job. And you should be able to focus on learning what makes your day-to-day easier and then learn that during your work hours. So that's something I feel very strongly about.

+ +

JOËL: Do you think that's something that is a current reality or something that is aspirational? As in, an employer shouldn't require it, or it is currently possible to have a completely fine career and never have a side project.

+ +

STEPH: I think it's very possible currently and aspirational for some teams. I think there are some companies and teams that will turn you down because you don't fit that mold. And I think that's what then puts us in that unpopular opinion category. Because there are enough people that still think that that is an important part of being a software developer.

+ +

But I do think that there are still plenty of teams and people that are starting to agree with the idea that it shouldn't be that way and that that is not a requirement for an interview, or for joining the team, or for being a good developer, or for progressing in your skills. So a little bit of both, currently possible and also aspirational.

+ +

JOËL: I'm going to throw a question out, and I think this may be its own complete topic. So feel free to tell me that this is not the day to talk about this, but I'm going to put a question out. Recently, there was a really good conversation that happened internally at thoughtbot where one of our newer developers was asking, is it possible to progress our whole career ladder without ever doing any side projects? So just 32 hours of client work, eight hours investment time every week.

+ +

And maybe a little bit beyond that, maybe it's technically possible. But it takes an excruciatingly long time. Is it possible to progress in a reasonable amount of time through the career ladder without doing any extra work outside of our standard working hours? What are your thoughts on that for thoughtbot?

+ +

STEPH: I think the answer has to be yes. Because I mean, who's creating that ladder that you are climbing? It's going to come down to the company and the managers and the people who are deciding on how you advance, and not everybody has time. So what you're telling me is that if someone can't advance during the normal work hours that they have then...because they have families; they have other priorities in their life; they have other responsibilities, that then they're just stuck? And that feels like an unacceptable answer to me. So my answer is absolutely you can progress during the work hours that you have. And if you can't, then that is a problem for managers and leadership to fix.

+ +

CHRIS: I definitely agree with the assertion that you're making, Steph. And I like the ire that you're bringing to this. This is good. This is the sort of fire that we should have in this particular segment. I do think there was an aspect of the question that is subtle and really interesting to me, which is in a reasonable amount of time. And then you mentioned, or it might take an excruciatingly long amount of time.

+ +

A thing that I observe about our industry is that it is rather young overall, and the expectations of progression are incredibly rapid. This is sort of my second career. I spent three years as a mechanical engineer working in industry. That was the first thing that I did. And that world looks wildly different.

+ +

The idea of achieving principal engineer, which is a little bit more formalized of a concept, but I saw that as 30 years down the road kind of thing, or it may be 20, or something, but a significant chunk of my career. That is something I might achieve towards the end of my career after having put in a lot of time.

+ +

And development is just such a young industry. Like, the idea of going to a bootcamp and then two years later being a senior engineer and continuing to progress just ever so rapidly is interesting. I don't want to slow anyone down by any means. And I don't want to say that like, well, when I was over there, it was slower, and so it should be slower here. But I don't think it's realistic, frankly.

+ +

And I think some of what is at the heart of this question is like, no, this is an industry where you get in there, and in five years, you have achieved the pinnacle of your career. And then you go retire, and you go to a cabin in the woods, and you never talk to humans or touch a computer again. That's the dream. It's like, well, maybe that's not realistic. And what would it actually look like if we were a little more chill about these sorts of things? That is a question that I have.

+ +

STEPH: It's funny that you mentioned that one because that was one that I almost put on my list of unpopular opinions where I think the progression in which we change our titles as developers is silly, [chuckles] is probably the best word that I have for it. Because I agree with you, I don't want to slow people down. And we often change our titles to reflect that, yes, we want more responsibilities. We want more pay, and so that feels like the best way to then achieve those goals.

+ +

But it's so rapid in how we expect people to progress to different levels of engineering. I do think it loses a bit of its meaning because then we progress people so quickly through those different roles. Because then senior developer means so much. I mean, are you a senior developer with two years of experience or ten years of experience? Like, you could be in both of those groups. And so, it just loses some of its meaning because of that.

+ +

JOËL: It's also hard because years of experience aren't really a good way to compare two developers. I mean, two versus 10 is probably something you can compare very roughly. But five versus 7 or 5 versus 10, someone might be much more experienced or be better at solving problems after five years than somebody else in 10.

+ +

CHRIS: I will argue that two years in a consultancy is like five or maybe even ten years in a middle-of-the-road product company that's kind of got its stuff figured out. And just the volume of new and novel that will come at you is quite large. And I strongly recommend working with a lovely company called thoughtbot to get that experience because it'll be a fun time while you're there. And, man, will you learn a lot.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPH: Joël, I have another potentially unpopular opinion I'd love to share. But I'm curious, what's one of yours?

+ +

JOËL: So here's a controversial opinion that I have: DRY, Don't Repeat Yourself, is dangerous, I'd say even a harmful rule of thumb for intermediate developers. It's one of our favorite kind of aphorisms, principles that we try to live by as developers. But I think it often does more harm than good at a certain point in your career.

+ +

When you start off as a new developer, one of the most common sorts of bugs you'll do is where you duplicate code, and then you change it in one place and don't change it in the other. And they're out of sync, and then your code breaks. And then you discover DRY, Don't Repeat Yourself. And it's amazing because this simple rule fixes 80% of the bugs you were creating. And of course, now there are other types of bugs you find out about. But it's a whole class that gets eliminated by that, and it's wonderful.

+ +

But then you get into the intermediate developer, and you start to get clever, and you try to apply this in a lot of places. And you start trying to abstract things that are similar but not the same, and then they start to diverge. And then you've got a mess on your hands. And this happens in application code happens in test code.

+ +

Yeah, you end up doing that, prematurely abstracting, and particularly when it's just based on through a simple substring matching. So you're saying this string of 100 characters is identical in two files. We need an abstraction that shares these two when the fact that the two strings might be similar is just coincidental. And so that's where you cause more harm than good. And then eventually, you kind of transcend that, hopefully, and get back to the point where you can maybe apply DRY more judiciously.

+ +

Now, DRY is no longer for you about similar characters. It's about similar or actually same concepts because similar is not good enough. And hopefully, you have the discernment to distinguish between similar and same. And when you're not quite sure, maybe you leave them separate to see will they diverge in the next few months?

+ +

STEPH: It's almost like you and I are on the same project, and we have felt similar pains in the world.

+ +

JOËL: [laughs] I think this is a thing that a lot of developers eventually get to the point where they can do it decently well in production code. But at least when it comes to RSpec code, the Ruby community has just refused to learn this lesson. We're still stuck in that intermediate developer phase where everything's got to be extracted out as shared setup. And I would argue that shared setup on most tests is similar and not same. And the identical thing is if you're just copying two strings of code that look similar in two files and creating an abstraction that really doesn't need to be there.

+ +

CHRIS: Friends, I have to tell a truth in this moment. I wrote a let within an RSpec file this week. It happened.

+ +

JOËL: [Gasps]

+ +

STEPH: This is actually why you're moving off the show, Chris. This right here. [laughs]

+ +

CHRIS: I'm getting kicked off the island. I've broken rule number one [chuckles]; let's not. This was...I think it was a reasonable one; at least I couldn't figure out a different way to do it. I was defining a class within an RSpec file, a representative implementation of a subclass. And I tried to do it by just defining a class in line, but RuboCop came along; we recently added RuboCop to the app as well. And RuboCop said, no, no, no, you are leaking a constant. And I said, oh, that's true, RuboCop.

+ +

And then, thankfully, the documentation page for that rule had a pointer to what to do instead. And so it ended up with a let. I don't actually think I need to let now that I think about it. You can dynamically define a class within a spec example. So I then, in the rest of the example, started doing that. So I'll probably remove the one let that I actually added. [laughs] But it happened.

+ +

JOËL: That honestly seems reasonable to me. I think there are use cases where let can be done correctly. It's just really hard to have the discipline to not stray off that very narrow path of safety. I recently gave a talk at RailsConf about how your test suite is making too many database calls. And most of them are all related to doing way too much during your setup phase.

+ +

And one of the reasons I gave that this happens too often is shared setup and let in particular. And I thought that I might get booed off the stage. But in fact, several people came up to me afterwards and told me that I had actually given them a whole new perspective they had never seen, and that was interesting to them.

+ +

STEPH: That's awesome. That's so nice that people came up and shared that with you. Yeah, I think one of the areas that I don't know if we highlight enough, but whenever you and I happen to gripe about the use of let or over drying and extracting setup for tests, specifically, is because then we're not talking about the trade-off of then you're coupling all your other tests to that extracted setup.

+ +

And so it's not so much that I care that you dried up your test setup, and now the rest of my tests are likely reliant on that extracted shared setup. And then that's where we've introduced a trade-off, and it's a painful trade-off that I have worked through a number of times. So just to add a bit of persnicketiness to our discussion in terms of it's not so much the DRY in the extraction that bothers me, it's then the trade-off of now everything is coupled. And it becomes much harder to then create independent scenarios that are still easy to read and then modify.

+ +

JOËL: Because you're coupling two things that are not the same, that want to diverge. And now you're forcing them down a single path. And I think probably the biggest, reddest flag you can get that you've misDRY-ed is where you try to introduce conditionals to your shared extraction. Because the whole point of a shared extraction is that everything is the same. And so once you start introducing branching in there, you know something's gone horribly wrong with your abstraction.

+ +

STEPH: Okay, so I think we've established that we've got very strong, maybe popular, unpopular opinions about DRY and especially using DRY in test setup. What's another unpopular opinion that you have, Joël?

+ +

JOËL: This one is a stylistic one. But I think that in Ruby, at least, every if should come with an else. You want something to happen when your condition doesn't trigger. I think it generally makes for more readable code and also prevents some implicit nils from getting through. And nil errors are probably at the top of your bug backlog if you were to look at right now (For all of you listeners, I'm pretty sure that's true.), excluding JavaScript.

+ +

CHRIS: Someday, we're going to make undefined a function, and it's going to be a great day. This is an interesting one, Joël. I'm inclined to agree with you, but I know that in my code, I don't necessarily follow this adage. So I find it interesting. I would call them intentional nils; I'm sometimes fine with that, or particularly in side effect-y code, you know, if this condition, then do something, otherwise, nothing.

+ +

But yeah, it is interesting. The explicitness, the nil, is a big mistake that seems true. You hang out in Elm for long enough, and you don't have one, and then you got to think about stuff harder. But yeah, I don't find myself doing this. So I find it interesting. I conceptually agree with what you're saying, and yet my code tells other stories.

+ +

JOËL: So I would argue that Ruby is an expression-oriented language; all methods auto return something as opposed to a statement-driven language like JavaScript, where nothing returns unless you explicitly return it. Ruby is all about those return values. And so you need to cover all branches, and if you don't, Ruby will implicitly have some branches that you don't have there. And so, I prefer to make visible the branching logic that's happening.

+ +

STEPH: I also like this one. I think I'm on the same page as Chris, where I like the opinion and this statement. And then also, you'd asked me earlier about whether something is capable now versus aspirational. And this feels like in the aspirational area for me where I agree with it, but I don't necessarily do it. But I think it makes a lot of sense because then it does force you to think about what is the return value? And to be very explicit and say, yep, no, I want a nil here. That's just what I'm going to return.

+ +

JOËL: And maybe even think about in that else case maybe you don't always want nil, maybe you'd rather return an empty string, or a null object, or something like that. And forcing you to actually manually type that value in instead of just being like yeah, Ruby knows. It'll put a nil there. It's easy to not think about the error edge cases, which I know is the opposite of how Chris thinks. Chris thinks about all the error edge cases.

+ +

CHRIS: My brain has been shifted by experience.

+ +

JOËL: One thing that I think this works really well is a stylistic approach that I use where I separate branching code from doing code. So in a particular method, if there is a conditional, then the body of the conditional calls out to another method. It doesn't implement logic there directly. And if a method does a calculation, or does the side effect, or does some kind of work, it's not allowed to have a conditional in it. So an individual method either gets to branch, or it gets to do a thing but not both.

+ +

STEPH: Is that so you can quickly see all of the branching that's involved so you can see it at a very high level versus if you have a very large branching in your method and then it's hard to see how many possible return values that you have?

+ +

JOËL: Yes. I like it because when you read code, especially when you're reading code that has a conditional in it, typically, you're reading it at a higher level of abstraction. You just want to know what are the possible ways that it can branch, and then what are the paths it can go down? And you probably don't care about all the nitty gritty implementation details that happen at each branch.

+ +

And then you might care about one particular branch and decide to go down that path. At that point, you will jump to that method. But you don't need to have all 2 or 3 or 10 branches expanded for you. It keeps the method at a single level of abstraction and also allows each method, in a certain extent, to have a single responsibility. It does one thing. It's either branching between n choices, or it does one thing, but it doesn't try to do multiple things.

+ +

So that's less of a hot take opinion, like, everyone should write code that way. That's just a style I've adopted for myself that works really well. But that particularly dovetails nicely with my hot take, which is if should come with an else.

+ +

STEPH: I like it.

+ +

JOËL: Yeah, so, Steph, do you have another juicy opinion you'd like to share with our listeners?

+ +

STEPH: Yeah, I've got one more to share, and this one is going to show my consulting roots. And it's that developers should be included in the design and planning phases, and not just in the execution phase of the work. So that's something that I've seen a number of teams struggle with where they wait until either design is considered completed or perfect or someone else has figured out the way that they want a feature to be built, and then they just essentially throw it over the wall and kick it over to the development team.

+ +

And so then it's laid out with very specific criteria. But it's not clear the problem that's actually being solved. And so developers have done a very narrow focus of what they're working on. And you just often end up building the wrong thing when that happens because people don't have the context. They don't know the questions to ask if they do run into some questions regarding the requirements.

+ +

And so I strongly advocate that developers shouldn't just pick up tickets and then write code, that they should be part of the planning and the product process as well. Turns out that developers often have really good ideas when it comes to features. And they also have a lot of knowledge about the application and can ask good questions. So why not include them in that process?

+ +

JOËL: You mentioned that this is inspired by your experience as a consultant. I've sometimes heard the contrast between the terms contractor versus consultant. Is that a distinction that you make?

+ +

STEPH: Yes and no. Yes, because I've heard other people make that distinction, but I personally wouldn't make that distinction. And even for people who are not a contractor or consultant but they're full-time, I still love when people can adopt the mentality of you have the same responsibility of this product and where it's headed and its technical decisions.

+ +

And we all should be mindful of the time that we're spending as we're working on something. And I think being a consultant helps you be more mindful in terms of like, oh, I've spent two hours on this problem. I should probably reach out for help. And I feel like people who haven't had an opportunity to be in that mindset don't think that way. But I think it's a really wonderful state to be in all the time just to think through; okay, I've been stuck for an hour, now's the right time that I should reach out for help. Versus spending like a full day on something and then reaching out for help.

+ +

So I have heard that distinction, but I personally wouldn't make that distinction. I would advocate that even if you are a consultant, or full-time, or contractor that ideally, you would still be part of those different processes to then help build a valuable product.

+ +

JOËL: Steph, I found it really interesting when you introed this idea. It was about developers bringing their ideas to the business and design side of things. But then, when you dug into the idea a little bit more, you kind of flipped it on its head and said that being involved in those meetings helps developers do their job better because now they can more appropriately timebox a feature or decide when they've hit that 80% point that's good enough to ship, and then they need to reprioritize something else. So it sounds like there are advantages to both sides, both the business side and the dev side, from a tighter integration there.

+ +

STEPH: Yeah, thanks for calling that out. I think that's an excellent point that I hadn't really even considered as I was just rambling about a strong feeling. But yes, I think it's beneficial to all sides. It's beneficial to developers who are getting the work done. And then I also think it's really beneficial to the product team and design just because that way, everybody essentially has the same context. They're on the same page.

+ +

And then you also have more camaraderie that way too in terms of people know the problems that they're trying to solve. And you can have more opinions. And people can surface those ideas versus if you are kept in the dark as to perhaps why a feature is being built or who it's geared towards, then it's more likely that you're not going to be as connected with the rest of the team and be able to provide helpful ideas because you won't have the fuller context to then surface that to the rest of the team.

+ +

So this is definitely coming just from all of my experience in the projects that I've been on that the most successful projects include design, and developers, and product management. And they all get together, and they talk about the problems that are being solved. Versus the projects that I've been on where essentially, all of that work is done separately, and then there's just a Trello board or Jira tickets or whatever tool that you're using. And then developers go and pick up tickets.

+ +

Because then you often end up having those discussions anyway because developers are then going to have to check in to say, hey, you said this thing. Did you mean this? What exact requirements am I looking for? By siloing that process elsewhere, you end up just duplicating your efforts because that conversation is ideally going to happen anyways.

+ +

JOËL: I recently had a conversation with someone who had been promoted to senior developer and was asking me for some advice on how do you be a senior at your job. And this is at a product company. And basically, what you were saying, Steph, is what I recommended. If, as a senior developer, you are just a machine that converts tickets into code, they're not using you to your full potential. And honestly, they're overpaying for what they're getting.

+ +

You need to be in those meetings, in those conversations, so that, as you mentioned, you can be that nexus between business and tech and tell them, look, this is your strategic goal. You think this is the technology thing you want to do. Yes, it will solve your problem, but it will take twice as long.

+ +

And that is incredibly valuable to the business people because doable and easy, and very similar solution that is near impossible to do in tech are very common. There's a classic xkcd about this situation. And so having someone who knows that nuance and can recommend and say, look, we can do this in two weeks. That will take six months. Or even just talking through trade-offs is incredibly valuable.

+ +

And then, as you said, bring that back in your own work, knowing when to say, look, we thought this is going to take two weeks, and it's taking more. We think this is going further. We know that the business goal is to get to here. So I'm going to pause on this and propose a different technical solution that will get us most of the way towards that goal while still respecting the deadlines we're working under.

+ +

I might argue that this sort of mindset is not just a senior developer thing. It's valuable at mid-level and junior as well. And I think that as a consulting firm at thoughtbot, that's something that we bring in from the beginning for everyone that we try to build this. But definitely, as you move up into your career, this is going to become more and more important.

+ +

CHRIS: Yeah, I'm surprised. I'm actually totally on the opposite side of this one. I fundamentally disagree with...no, I totally agree with everything you're saying and how important these sorts of conversations are. We're actually working on something at Sagewell right now. It's a new, reasonably large integration with an external platform.

+ +

And we're very, very intentionally pushing such that product and design are going off and doing some work, and engineering is going off and doing exploratory what do the APIs actually look like? What's the data that we need? What's the object model in this system? What can we get away with not providing? What do we need to provide?

+ +

And continually, we're just trying to encourage communication across those different tracks. So design is thinking about different flows and what's the experience a user is going to have. And ideally, getting engineering to review that and say, "Oh, that's going to be easy. That'll be hard. I think we could do that, but I actually have to go look it up and see if that's possible," and vice versa.

+ +

Engineering now being in the depths of saying like, "Oh, actually, this has to be done in this way for legal reasons or whatever it is," and then providing that back to design and product to think about how do we structure it? How do we sequence things? What's part of the MVP? And I've been really happy with the nature of that, that back and forth communication.

+ +

But it is definitely something that requires intentional work of making sure that we're not just falling into our own silos, but we're coming up for air, having those conversations, passing ideas back and forth, including each other in the conversations. But without question, it will produce a better outcome at the end of the day. So yeah, I actually do, in fact, agree 100%.

+ +

STEPH: Yeah, to add on to that just a bit, there is a particular example that comes to mind where I felt the most pain for when developers and product and design aren't in the same room and then discussing the work to be done. And that's essentially where someone ends up building the wrong thing. And it's because someone decided that they knew the best solution for something, but they didn't really collaborate with the rest of the team. They turned that into a ticket.

+ +

So then a developer sees that, and then they start implementing, and it's not until later that someone comes along and starts asking questions to say, "Hey, so what problem are we solving?" Or "Why are we adding this code?" And Joël, I think you said it perfectly and that this is something that I do expect of a more senior developer where they have that experience, and they ask those types of questions that then you realize that, oh, we've actually built the wrong thing, or the thing that we're building doesn't solve the problem that we had in mind.

+ +

And at that point, you have someone who has invested a week, maybe a couple of weeks into something, so then that feels really terrible to then say, "We actually need to scrap this" or "We need to totally rethink this." So then you start making trade-offs of like, well, maybe we can keep this portion or preserve some of the work that you've done. And so you just end up in a really messy state. And that can be avoided if people are collaborating at an earlier stage of that process.

+ +

JOËL: Yes, you and I, Steph, were in a very particular situation where something like this had happened. Some developer had been working on a ticket for a couple of weeks. And it was one of those tickets that just kept growing. The code kept growing, but then the client kept adding new requests and features onto it. And then, at some point, you and I were brought in to help, and the first thing we had to do is like, let's stop and ask what is the problem that is actually being solved here?

+ +

And actually got everyone together with the client. And that conversation helped us do a big reset and helped us find a way that was more focused that actually solved the underlying problem, what the client actually wanted rather than what they said they wanted.

+ +

I noticed that for most of these unpopular opinions, it sounds like we pretty much all agree with each other. So either we all have a very similar set of unpopular opinions, or maybe these opinions might be a little bit more mainstream than we give them credit for. I find that oftentimes, at least on Twitter, when people tag things as "unpopular opinion" in quotes, they may be a little bit more popular than people give credit for.

+ +

CHRIS: I feel like the RSpec one is unpopular. And also, have you asked Steph about Pop-Tarts?

+ +

JOËL: [laughs]

+ +

CHRIS: Because we are capable of having sincerely unpopular opinions.

+ +

JOËL: Let's save that for the next episode. And on that note, shall we wrap up?

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph and Chris announce Joël Quenneville as the new host of the show! 🎉 Joël talks about his grand plans for where The Bike Shed is going to go from here. (Okay, maybe not grand plans...!)

+ +

Together, the group chats about unpopular opinions and hot programming takes.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Follow Joël on Twitter! Welcome him to the show.
+Joël Quenneville - DRY is harmful for intermediate devs

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript

+ +

CHRIS: Thank you. No brown M&M'S. No asking me weird questions. I ask very little.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: I'm Chris Toomey.

+ +

JOËL: And I'm Joël Quenneville.

+ +

STEPH: And together, we're here to share a bit of what we learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What is new in my world? There is a new friend on the show with us today, Joël, developer extraordinaire, principal developer at thoughtbot, former coach of the Chicago Blackhawks (That one's not true, but it's funny to say.) and friend of the show, many time guest. Joël, so great to see you. How are you today?

+ +

JOËL: I'm excited to be joining the show.

+ +

CHRIS: Fantastic. So Steph and I shared with the audience in the previous episode that we have decided...we've made the heavy decision that it is time for us to hand over the hosting mantle. But we had yet to discuss exactly where that was going to go. And today, we are happy to share with you the specifics of that, which is that Joël will be taking over the hosting detail. So, Joël, do you have grand plans for where The Bike Shed is going to go from here?

+ +

JOËL: Maybe not in grand plans, but I'm definitely already planning content, lining up a few guests. I think the next few weeks are going to be a lot of interviews with some guests, a lot of co-workers at thoughtbot will want to share their stories or some exciting things that they're working on, things they are specialized in.

+ +

One thing that I really appreciate at thoughtbot is that we're all pretty full-stack developers. Everybody tends to have a specialization or an area they're really good at. And so when you're ever stuck, and you need advanced Git help, you go to, historically, Chris. If you want some help on security, you go to Mike Burns, et cetera. And so yeah, I'd love to bring in some of them and get to talk a little bit about some of the areas where they're either doing something interesting, or this is just an area where they have deep expertise.

+ +

STEPH: I have to say that having you take over as host of the show feels like such a nice continuation, given that you've been involved with The Bike Shed since you were a guest on the show back in 2018. And then, since then, you've been a repeat guest. And even when you're not here, Chris and I still frequently bring up your name and mention some of the talks and the blog posts that you have written.

+ +

So I'm super excited for everything that you just said, for all the guests that you're going to bring on the show, and the thoughtbot voices. And I'm looking forward to tuning into future episodes and hearing what happens next.

+ +

JOËL: Yeah, this is a really exciting transition for me. I am a long-time fan of the show. I've been a guest a few times. And now, coming on as a host is just taking it to the next level.

+ +

CHRIS: Yeah, Joël, I'm also super excited to see the new perspective that you bring to the show. And frankly, to Steph's point, you've been on the show a bunch of times. You've been here in spirit. In fact, there was a tweet that someone sent to us which was "Hey, @joelquen," which is your Twitter handle, "I feel as if I know you and your work after listening to @SViccari and @christoomey. They definitely appreciate you," which was true then and is true now. So I couldn't be happier for you to be taking over this hosting slot.

+ +

JOËL: Creating content for developers and sharing the things I've learned, or the things that I've experienced with other people has always been something that's been really important to me. And so, getting a chance to bring that to The Bike Shed is a really exciting opportunity.

+ +

My past work has intersected with the show several times, either that's been conference talks or blog posts, or even just conversations we've all had. Steph and I pair almost every day. So there are a lot of good conversations. A lot of conversations that end with me saying, "You should talk about that in The Bike Shed. That's a good topic."

+ +

STEPH: You have been an excellent source for topics in terms of you've literally added stuff to our Trello board that we use to manage the show and then yes, and all those conversations that we've had. You're like, "Oh, this will be a good Bike Shed topic." And I'm like, "Hold please," while I go and then add it to our board.

+ +

JOËL: The fun of being an employee at thoughtbot is that I have access to the Trello board. And I can just add whatever ideas I have there for you all to talk about. [laughs]

+ +

CHRIS: That is the most direct way to send in a listener question is just to write it into the Trello board directly. Skip all the forms, and the Twitter, and the whatnot.

+ +

JOËL: Yeah, speaking of topics on our Trello board, let's go out on a really spicy one. I see we have a card about unpopular opinions. Chris, you created this. What is your hot programming take?

+ +

CHRIS: This was so long ago, I don't even remember. But this one has interestingly sat on the Trello board for a while. I was like, Steph, let's really lean into it. Let's go out there. What are our extreme takes? And I think we say the stuff that's in our heart most of the time anyway. But we're; also, I don't know, pragmatic, kind of boring up the middle.

+ +

Someone recently described my tech choices as like a Subaru. Like the architecture, the way I built it, you know, it's stable. It'll get to where you want to go. It's not going to be too fancy or too flashy. And I was like, you know, actually, humorously, my wife and I just bought a Subaru. So I was like, I guess I can't say no to that.

+ +

Anyway, though, I think I have one spicy take, which I have shared on The Bike Shed before. But it is the thing that I will die on this hill. I care about this. It feels like I'm just being persnickety, but I think it matters, which is that the phrase single-page application or the idea of an S-P-A or a SPA, which I've heard some people say it, is just a terrible framework. I am so unhappy with it as a concept.

+ +

I think, technically, the implementation of them has often led to some really complicated things, which is why I've spent so much time exploring Inertia, or LiveView or Livewire, or all of the other options that are out there. I think there are some really interesting novel ways. Remix.run is the most recent thing that I've been talking about, which takes a pretty traditional SPA type of build and then makes it behave more like a traditional server-rendered application.

+ +

But just the idea single-page application really grinds my gears that that is a thing that we talk about. Because it's the web, we have URLs; these should all be different pages. I don't care if there's one bundle of JavaScript that we send down or that it begins as a single HTML file that we send down, and then we repopulate constantly. There still should be URLs. Those are a honkin' good idea, and we should use more of those. And we shouldn't anchor to a technology...like, no, SPAs, I don't like it. I'm not a fan. So that is my unpopular opinion, I'm pretty sure.

+ +

STEPH: I think we have a full episode, too, where we focused a lot on that topic where you shake your fist at the SPAs in the world [laughs] and why you don't like them.

+ +

JOËL: I feel like the industry pendulum might be swinging back. I think we've hit peak SPA, and now we're slowly moving back, anecdotally anyway.

+ +

CHRIS: That is definitely what I'm seeing more and more of, and I'm very happy for it. Because I think there's some interesting stuff that came out of SPAs and the ideas of like, oh, let's animate, and let's have more continuity and page transitions and things that I think can really enhance the end-user experience. But I think the cost has been too high. It's broken us from some of the norm.

+ +

Like, how does the web work? That's a thing that we should talk about. Links, they're awesome. You can link between pages. It's so cool. And we just kind of threw that away. And we're like, div onclick. It'll be fun. Don't worry about it. Screen readers, who cares about those? Doesn't even matter. I care. That's who cares. I'm going to calm down now. I'm fine. It's fine. But yes, I agree. I do think the pendulum is swinging back, and I'm very happy to see that.

+ +

JOËL: Long-time listeners of the show will know that I'm a big fan of the Elm language. And for the longest time, I wanted to do a client project at thoughtbot with it. But I agree with you, Chris, that a lot of things shouldn't be SPAs. A lot of things should be just boring Rails apps. And so, every time an opportunity came, I just couldn't justify doing a front-end app. So I would be like, yay, I would love to do Elm here, but this should just be a vanilla Rails app.

+ +

And then, one day, we had a project that came in that was actually a single-page app. It was one page where you loaded up a bunch of data streams and then could interact with them and get all these cool visualizations and things. There was no clicking away. There were no other pages. It was just load some data, and you've got a playground. And that was the moment I knew, okay, this is the app I want to do in Elm. And that was my introduction to bringing Elm to colleagues at thoughtbot to work on a project together.

+ +

STEPH: You put out the signal kind of like the Batman signal, but you put out the Elm signal calling everybody into the project.

+ +

JOËL: [laughs]

+ +

CHRIS: You put a small tree on your desk, and everyone came together around it.

+ +

JOËL: [laughs]

+ +

CHRIS: Also, I want to applaud your pragmatic restraint of I want to use this. This would be fun to use, but it is not the right choice for many particular applications or projects that came through the door. But then you found it. Then you found that magic moment.

+ +

To be extra clear, I'm not opposed like; my distinction is an SPA or traditional server-rendered HTML generation on the server...I got redundant in there, but that'll be fine. It's more the bundle of JavaScript that goes down and that there's no routing on the server-side, et cetera, that all logic is pushed to the client-side.

+ +

I've harped on about Inertia and my love for that framework over many, many an episode on the show. But I feel like that, and many other solutions that are in that similar space, allow us to have the sort of experiences that are traditionally associated with an SPA but don't give up on the idea of auth being simply managed via a cookie on the server sort of thing. Cookie on the server is a phrase that doesn't really make sense. But y'all get what I'm saying, I hope. If not, assume that I said the right thing. It'll be more fun that way.

+ +

JOËL: Steph, I'm curious; what's maybe one of your unpopular opinions or hot takes?

+ +

STEPH: I have a couple, and since Chris used a phrase that has now helped anchor me in terms of like the hill that I will die on, I'm now looking through that list to pick the one that I feel like the most passionate about. So looking through that list, I might just have to go a couple. It's hard to really choose.

+ +

But the first one is I'm going to say you don't need a side project. I can't tell you how much that frustrates me when people just always say you have to do something on the side. You have to stay up late and code. You have to do coding on the weekends. I feel very strongly that software development is a job, and it doesn't have to be your passion; if it is, that is fabulous.

+ +

But it is, at the end of the day, still a job, and you don't need to know three additional languages to be good at your job. And you should be able to focus on learning what makes your day-to-day easier and then learn that during your work hours. So that's something I feel very strongly about.

+ +

JOËL: Do you think that's something that is a current reality or something that is aspirational? As in, an employer shouldn't require it, or it is currently possible to have a completely fine career and never have a side project.

+ +

STEPH: I think it's very possible currently and aspirational for some teams. I think there are some companies and teams that will turn you down because you don't fit that mold. And I think that's what then puts us in that unpopular opinion category. Because there are enough people that still think that that is an important part of being a software developer.

+ +

But I do think that there are still plenty of teams and people that are starting to agree with the idea that it shouldn't be that way and that that is not a requirement for an interview, or for joining the team, or for being a good developer, or for progressing in your skills. So a little bit of both, currently possible and also aspirational.

+ +

JOËL: I'm going to throw a question out, and I think this may be its own complete topic. So feel free to tell me that this is not the day to talk about this, but I'm going to put a question out. Recently, there was a really good conversation that happened internally at thoughtbot where one of our newer developers was asking, is it possible to progress our whole career ladder without ever doing any side projects? So just 32 hours of client work, eight hours investment time every week.

+ +

And maybe a little bit beyond that, maybe it's technically possible. But it takes an excruciatingly long time. Is it possible to progress in a reasonable amount of time through the career ladder without doing any extra work outside of our standard working hours? What are your thoughts on that for thoughtbot?

+ +

STEPH: I think the answer has to be yes. Because I mean, who's creating that ladder that you are climbing? It's going to come down to the company and the managers and the people who are deciding on how you advance, and not everybody has time. So what you're telling me is that if someone can't advance during the normal work hours that they have then...because they have families; they have other priorities in their life; they have other responsibilities, that then they're just stuck? And that feels like an unacceptable answer to me. So my answer is absolutely you can progress during the work hours that you have. And if you can't, then that is a problem for managers and leadership to fix.

+ +

CHRIS: I definitely agree with the assertion that you're making, Steph. And I like the ire that you're bringing to this. This is good. This is the sort of fire that we should have in this particular segment. I do think there was an aspect of the question that is subtle and really interesting to me, which is in a reasonable amount of time. And then you mentioned, or it might take an excruciatingly long amount of time.

+ +

A thing that I observe about our industry is that it is rather young overall, and the expectations of progression are incredibly rapid. This is sort of my second career. I spent three years as a mechanical engineer working in industry. That was the first thing that I did. And that world looks wildly different.

+ +

The idea of achieving principal engineer, which is a little bit more formalized of a concept, but I saw that as 30 years down the road kind of thing, or it may be 20, or something, but a significant chunk of my career. That is something I might achieve towards the end of my career after having put in a lot of time.

+ +

And development is just such a young industry. Like, the idea of going to a bootcamp and then two years later being a senior engineer and continuing to progress just ever so rapidly is interesting. I don't want to slow anyone down by any means. And I don't want to say that like, well, when I was over there, it was slower, and so it should be slower here. But I don't think it's realistic, frankly.

+ +

And I think some of what is at the heart of this question is like, no, this is an industry where you get in there, and in five years, you have achieved the pinnacle of your career. And then you go retire, and you go to a cabin in the woods, and you never talk to humans or touch a computer again. That's the dream. It's like, well, maybe that's not realistic. And what would it actually look like if we were a little more chill about these sorts of things? That is a question that I have.

+ +

STEPH: It's funny that you mentioned that one because that was one that I almost put on my list of unpopular opinions where I think the progression in which we change our titles as developers is silly, [chuckles] is probably the best word that I have for it. Because I agree with you, I don't want to slow people down. And we often change our titles to reflect that, yes, we want more responsibilities. We want more pay, and so that feels like the best way to then achieve those goals.

+ +

But it's so rapid in how we expect people to progress to different levels of engineering. I do think it loses a bit of its meaning because then we progress people so quickly through those different roles. Because then senior developer means so much. I mean, are you a senior developer with two years of experience or ten years of experience? Like, you could be in both of those groups. And so, it just loses some of its meaning because of that.

+ +

JOËL: It's also hard because years of experience aren't really a good way to compare two developers. I mean, two versus 10 is probably something you can compare very roughly. But five versus 7 or 5 versus 10, someone might be much more experienced or be better at solving problems after five years than somebody else in 10.

+ +

CHRIS: I will argue that two years in a consultancy is like five or maybe even ten years in a middle-of-the-road product company that's kind of got its stuff figured out. And just the volume of new and novel that will come at you is quite large. And I strongly recommend working with a lovely company called thoughtbot to get that experience because it'll be a fun time while you're there. And, man, will you learn a lot.

+ +

MID-ROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPH: Joël, I have another potentially unpopular opinion I'd love to share. But I'm curious, what's one of yours?

+ +

JOËL: So here's a controversial opinion that I have: DRY, Don't Repeat Yourself, is dangerous, I'd say even a harmful rule of thumb for intermediate developers. It's one of our favorite kind of aphorisms, principles that we try to live by as developers. But I think it often does more harm than good at a certain point in your career.

+ +

When you start off as a new developer, one of the most common sorts of bugs you'll do is where you duplicate code, and then you change it in one place and don't change it in the other. And they're out of sync, and then your code breaks. And then you discover DRY, Don't Repeat Yourself. And it's amazing because this simple rule fixes 80% of the bugs you were creating. And of course, now there are other types of bugs you find out about. But it's a whole class that gets eliminated by that, and it's wonderful.

+ +

But then you get into the intermediate developer, and you start to get clever, and you try to apply this in a lot of places. And you start trying to abstract things that are similar but not the same, and then they start to diverge. And then you've got a mess on your hands. And this happens in application code happens in test code.

+ +

Yeah, you end up doing that, prematurely abstracting, and particularly when it's just based on through a simple substring matching. So you're saying this string of 100 characters is identical in two files. We need an abstraction that shares these two when the fact that the two strings might be similar is just coincidental. And so that's where you cause more harm than good. And then eventually, you kind of transcend that, hopefully, and get back to the point where you can maybe apply DRY more judiciously.

+ +

Now, DRY is no longer for you about similar characters. It's about similar or actually same concepts because similar is not good enough. And hopefully, you have the discernment to distinguish between similar and same. And when you're not quite sure, maybe you leave them separate to see will they diverge in the next few months?

+ +

STEPH: It's almost like you and I are on the same project, and we have felt similar pains in the world.

+ +

JOËL: [laughs] I think this is a thing that a lot of developers eventually get to the point where they can do it decently well in production code. But at least when it comes to RSpec code, the Ruby community has just refused to learn this lesson. We're still stuck in that intermediate developer phase where everything's got to be extracted out as shared setup. And I would argue that shared setup on most tests is similar and not same. And the identical thing is if you're just copying two strings of code that look similar in two files and creating an abstraction that really doesn't need to be there.

+ +

CHRIS: Friends, I have to tell a truth in this moment. I wrote a let within an RSpec file this week. It happened.

+ +

JOËL: [Gasps]

+ +

STEPH: This is actually why you're moving off the show, Chris. This right here. [laughs]

+ +

CHRIS: I'm getting kicked off the island. I've broken rule number one [chuckles]; let's not. This was...I think it was a reasonable one; at least I couldn't figure out a different way to do it. I was defining a class within an RSpec file, a representative implementation of a subclass. And I tried to do it by just defining a class in line, but RuboCop came along; we recently added RuboCop to the app as well. And RuboCop said, no, no, no, you are leaking a constant. And I said, oh, that's true, RuboCop.

+ +

And then, thankfully, the documentation page for that rule had a pointer to what to do instead. And so it ended up with a let. I don't actually think I need to let now that I think about it. You can dynamically define a class within a spec example. So I then, in the rest of the example, started doing that. So I'll probably remove the one let that I actually added. [laughs] But it happened.

+ +

JOËL: That honestly seems reasonable to me. I think there are use cases where let can be done correctly. It's just really hard to have the discipline to not stray off that very narrow path of safety. I recently gave a talk at RailsConf about how your test suite is making too many database calls. And most of them are all related to doing way too much during your setup phase.

+ +

And one of the reasons I gave that this happens too often is shared setup and let in particular. And I thought that I might get booed off the stage. But in fact, several people came up to me afterwards and told me that I had actually given them a whole new perspective they had never seen, and that was interesting to them.

+ +

STEPH: That's awesome. That's so nice that people came up and shared that with you. Yeah, I think one of the areas that I don't know if we highlight enough, but whenever you and I happen to gripe about the use of let or over drying and extracting setup for tests, specifically, is because then we're not talking about the trade-off of then you're coupling all your other tests to that extracted setup.

+ +

And so it's not so much that I care that you dried up your test setup, and now the rest of my tests are likely reliant on that extracted shared setup. And then that's where we've introduced a trade-off, and it's a painful trade-off that I have worked through a number of times. So just to add a bit of persnicketiness to our discussion in terms of it's not so much the DRY in the extraction that bothers me, it's then the trade-off of now everything is coupled. And it becomes much harder to then create independent scenarios that are still easy to read and then modify.

+ +

JOËL: Because you're coupling two things that are not the same, that want to diverge. And now you're forcing them down a single path. And I think probably the biggest, reddest flag you can get that you've misDRY-ed is where you try to introduce conditionals to your shared extraction. Because the whole point of a shared extraction is that everything is the same. And so once you start introducing branching in there, you know something's gone horribly wrong with your abstraction.

+ +

STEPH: Okay, so I think we've established that we've got very strong, maybe popular, unpopular opinions about DRY and especially using DRY in test setup. What's another unpopular opinion that you have, Joël?

+ +

JOËL: This one is a stylistic one. But I think that in Ruby, at least, every if should come with an else. You want something to happen when your condition doesn't trigger. I think it generally makes for more readable code and also prevents some implicit nils from getting through. And nil errors are probably at the top of your bug backlog if you were to look at right now (For all of you listeners, I'm pretty sure that's true.), excluding JavaScript.

+ +

CHRIS: Someday, we're going to make undefined a function, and it's going to be a great day. This is an interesting one, Joël. I'm inclined to agree with you, but I know that in my code, I don't necessarily follow this adage. So I find it interesting. I would call them intentional nils; I'm sometimes fine with that, or particularly in side effect-y code, you know, if this condition, then do something, otherwise, nothing.

+ +

But yeah, it is interesting. The explicitness, the nil, is a big mistake that seems true. You hang out in Elm for long enough, and you don't have one, and then you got to think about stuff harder. But yeah, I don't find myself doing this. So I find it interesting. I conceptually agree with what you're saying, and yet my code tells other stories.

+ +

JOËL: So I would argue that Ruby is an expression-oriented language; all methods auto return something as opposed to a statement-driven language like JavaScript, where nothing returns unless you explicitly return it. Ruby is all about those return values. And so you need to cover all branches, and if you don't, Ruby will implicitly have some branches that you don't have there. And so, I prefer to make visible the branching logic that's happening.

+ +

STEPH: I also like this one. I think I'm on the same page as Chris, where I like the opinion and this statement. And then also, you'd asked me earlier about whether something is capable now versus aspirational. And this feels like in the aspirational area for me where I agree with it, but I don't necessarily do it. But I think it makes a lot of sense because then it does force you to think about what is the return value? And to be very explicit and say, yep, no, I want a nil here. That's just what I'm going to return.

+ +

JOËL: And maybe even think about in that else case maybe you don't always want nil, maybe you'd rather return an empty string, or a null object, or something like that. And forcing you to actually manually type that value in instead of just being like yeah, Ruby knows. It'll put a nil there. It's easy to not think about the error edge cases, which I know is the opposite of how Chris thinks. Chris thinks about all the error edge cases.

+ +

CHRIS: My brain has been shifted by experience.

+ +

JOËL: One thing that I think this works really well is a stylistic approach that I use where I separate branching code from doing code. So in a particular method, if there is a conditional, then the body of the conditional calls out to another method. It doesn't implement logic there directly. And if a method does a calculation, or does the side effect, or does some kind of work, it's not allowed to have a conditional in it. So an individual method either gets to branch, or it gets to do a thing but not both.

+ +

STEPH: Is that so you can quickly see all of the branching that's involved so you can see it at a very high level versus if you have a very large branching in your method and then it's hard to see how many possible return values that you have?

+ +

JOËL: Yes. I like it because when you read code, especially when you're reading code that has a conditional in it, typically, you're reading it at a higher level of abstraction. You just want to know what are the possible ways that it can branch, and then what are the paths it can go down? And you probably don't care about all the nitty gritty implementation details that happen at each branch.

+ +

And then you might care about one particular branch and decide to go down that path. At that point, you will jump to that method. But you don't need to have all 2 or 3 or 10 branches expanded for you. It keeps the method at a single level of abstraction and also allows each method, in a certain extent, to have a single responsibility. It does one thing. It's either branching between n choices, or it does one thing, but it doesn't try to do multiple things.

+ +

So that's less of a hot take opinion, like, everyone should write code that way. That's just a style I've adopted for myself that works really well. But that particularly dovetails nicely with my hot take, which is if should come with an else.

+ +

STEPH: I like it.

+ +

JOËL: Yeah, so, Steph, do you have another juicy opinion you'd like to share with our listeners?

+ +

STEPH: Yeah, I've got one more to share, and this one is going to show my consulting roots. And it's that developers should be included in the design and planning phases, and not just in the execution phase of the work. So that's something that I've seen a number of teams struggle with where they wait until either design is considered completed or perfect or someone else has figured out the way that they want a feature to be built, and then they just essentially throw it over the wall and kick it over to the development team.

+ +

And so then it's laid out with very specific criteria. But it's not clear the problem that's actually being solved. And so developers have done a very narrow focus of what they're working on. And you just often end up building the wrong thing when that happens because people don't have the context. They don't know the questions to ask if they do run into some questions regarding the requirements.

+ +

And so I strongly advocate that developers shouldn't just pick up tickets and then write code, that they should be part of the planning and the product process as well. Turns out that developers often have really good ideas when it comes to features. And they also have a lot of knowledge about the application and can ask good questions. So why not include them in that process?

+ +

JOËL: You mentioned that this is inspired by your experience as a consultant. I've sometimes heard the contrast between the terms contractor versus consultant. Is that a distinction that you make?

+ +

STEPH: Yes and no. Yes, because I've heard other people make that distinction, but I personally wouldn't make that distinction. And even for people who are not a contractor or consultant but they're full-time, I still love when people can adopt the mentality of you have the same responsibility of this product and where it's headed and its technical decisions.

+ +

And we all should be mindful of the time that we're spending as we're working on something. And I think being a consultant helps you be more mindful in terms of like, oh, I've spent two hours on this problem. I should probably reach out for help. And I feel like people who haven't had an opportunity to be in that mindset don't think that way. But I think it's a really wonderful state to be in all the time just to think through; okay, I've been stuck for an hour, now's the right time that I should reach out for help. Versus spending like a full day on something and then reaching out for help.

+ +

So I have heard that distinction, but I personally wouldn't make that distinction. I would advocate that even if you are a consultant, or full-time, or contractor that ideally, you would still be part of those different processes to then help build a valuable product.

+ +

JOËL: Steph, I found it really interesting when you introed this idea. It was about developers bringing their ideas to the business and design side of things. But then, when you dug into the idea a little bit more, you kind of flipped it on its head and said that being involved in those meetings helps developers do their job better because now they can more appropriately timebox a feature or decide when they've hit that 80% point that's good enough to ship, and then they need to reprioritize something else. So it sounds like there are advantages to both sides, both the business side and the dev side, from a tighter integration there.

+ +

STEPH: Yeah, thanks for calling that out. I think that's an excellent point that I hadn't really even considered as I was just rambling about a strong feeling. But yes, I think it's beneficial to all sides. It's beneficial to developers who are getting the work done. And then I also think it's really beneficial to the product team and design just because that way, everybody essentially has the same context. They're on the same page.

+ +

And then you also have more camaraderie that way too in terms of people know the problems that they're trying to solve. And you can have more opinions. And people can surface those ideas versus if you are kept in the dark as to perhaps why a feature is being built or who it's geared towards, then it's more likely that you're not going to be as connected with the rest of the team and be able to provide helpful ideas because you won't have the fuller context to then surface that to the rest of the team.

+ +

So this is definitely coming just from all of my experience in the projects that I've been on that the most successful projects include design, and developers, and product management. And they all get together, and they talk about the problems that are being solved. Versus the projects that I've been on where essentially, all of that work is done separately, and then there's just a Trello board or Jira tickets or whatever tool that you're using. And then developers go and pick up tickets.

+ +

Because then you often end up having those discussions anyway because developers are then going to have to check in to say, hey, you said this thing. Did you mean this? What exact requirements am I looking for? By siloing that process elsewhere, you end up just duplicating your efforts because that conversation is ideally going to happen anyways.

+ +

JOËL: I recently had a conversation with someone who had been promoted to senior developer and was asking me for some advice on how do you be a senior at your job. And this is at a product company. And basically, what you were saying, Steph, is what I recommended. If, as a senior developer, you are just a machine that converts tickets into code, they're not using you to your full potential. And honestly, they're overpaying for what they're getting.

+ +

You need to be in those meetings, in those conversations, so that, as you mentioned, you can be that nexus between business and tech and tell them, look, this is your strategic goal. You think this is the technology thing you want to do. Yes, it will solve your problem, but it will take twice as long.

+ +

And that is incredibly valuable to the business people because doable and easy, and very similar solution that is near impossible to do in tech are very common. There's a classic xkcd about this situation. And so having someone who knows that nuance and can recommend and say, look, we can do this in two weeks. That will take six months. Or even just talking through trade-offs is incredibly valuable.

+ +

And then, as you said, bring that back in your own work, knowing when to say, look, we thought this is going to take two weeks, and it's taking more. We think this is going further. We know that the business goal is to get to here. So I'm going to pause on this and propose a different technical solution that will get us most of the way towards that goal while still respecting the deadlines we're working under.

+ +

I might argue that this sort of mindset is not just a senior developer thing. It's valuable at mid-level and junior as well. And I think that as a consulting firm at thoughtbot, that's something that we bring in from the beginning for everyone that we try to build this. But definitely, as you move up into your career, this is going to become more and more important.

+ +

CHRIS: Yeah, I'm surprised. I'm actually totally on the opposite side of this one. I fundamentally disagree with...no, I totally agree with everything you're saying and how important these sorts of conversations are. We're actually working on something at Sagewell right now. It's a new, reasonably large integration with an external platform.

+ +

And we're very, very intentionally pushing such that product and design are going off and doing some work, and engineering is going off and doing exploratory what do the APIs actually look like? What's the data that we need? What's the object model in this system? What can we get away with not providing? What do we need to provide?

+ +

And continually, we're just trying to encourage communication across those different tracks. So design is thinking about different flows and what's the experience a user is going to have. And ideally, getting engineering to review that and say, "Oh, that's going to be easy. That'll be hard. I think we could do that, but I actually have to go look it up and see if that's possible," and vice versa.

+ +

Engineering now being in the depths of saying like, "Oh, actually, this has to be done in this way for legal reasons or whatever it is," and then providing that back to design and product to think about how do we structure it? How do we sequence things? What's part of the MVP? And I've been really happy with the nature of that, that back and forth communication.

+ +

But it is definitely something that requires intentional work of making sure that we're not just falling into our own silos, but we're coming up for air, having those conversations, passing ideas back and forth, including each other in the conversations. But without question, it will produce a better outcome at the end of the day. So yeah, I actually do, in fact, agree 100%.

+ +

STEPH: Yeah, to add on to that just a bit, there is a particular example that comes to mind where I felt the most pain for when developers and product and design aren't in the same room and then discussing the work to be done. And that's essentially where someone ends up building the wrong thing. And it's because someone decided that they knew the best solution for something, but they didn't really collaborate with the rest of the team. They turned that into a ticket.

+ +

So then a developer sees that, and then they start implementing, and it's not until later that someone comes along and starts asking questions to say, "Hey, so what problem are we solving?" Or "Why are we adding this code?" And Joël, I think you said it perfectly and that this is something that I do expect of a more senior developer where they have that experience, and they ask those types of questions that then you realize that, oh, we've actually built the wrong thing, or the thing that we're building doesn't solve the problem that we had in mind.

+ +

And at that point, you have someone who has invested a week, maybe a couple of weeks into something, so then that feels really terrible to then say, "We actually need to scrap this" or "We need to totally rethink this." So then you start making trade-offs of like, well, maybe we can keep this portion or preserve some of the work that you've done. And so you just end up in a really messy state. And that can be avoided if people are collaborating at an earlier stage of that process.

+ +

JOËL: Yes, you and I, Steph, were in a very particular situation where something like this had happened. Some developer had been working on a ticket for a couple of weeks. And it was one of those tickets that just kept growing. The code kept growing, but then the client kept adding new requests and features onto it. And then, at some point, you and I were brought in to help, and the first thing we had to do is like, let's stop and ask what is the problem that is actually being solved here?

+ +

And actually got everyone together with the client. And that conversation helped us do a big reset and helped us find a way that was more focused that actually solved the underlying problem, what the client actually wanted rather than what they said they wanted.

+ +

I noticed that for most of these unpopular opinions, it sounds like we pretty much all agree with each other. So either we all have a very similar set of unpopular opinions, or maybe these opinions might be a little bit more mainstream than we give them credit for. I find that oftentimes, at least on Twitter, when people tag things as "unpopular opinion" in quotes, they may be a little bit more popular than people give credit for.

+ +

CHRIS: I feel like the RSpec one is unpopular. And also, have you asked Steph about Pop-Tarts?

+ +

JOËL: [laughs]

+ +

CHRIS: Because we are capable of having sincerely unpopular opinions.

+ +

JOËL: Let's save that for the next episode. And on that note, shall we wrap up?

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+5yiGv6mL + + ]]> + + Chris Toomey + Steph Viccari + + + 348: Breaking News + https://bikeshed.thoughtbot.com/348 + 30883346-7bae-474f-8583-56383623a8f6 + Tue, 02 Aug 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph and Chris share some big news about the future of The Bike Shed. + +Steph shares an update about integrating with Knapsack Pro. Chris is excited for larger projects that will begin in the next few weeks. They answer a listener's question on keeping backlogs connected to the product vision. + 32:13 + no + + + Steph and Chris share some big news about the future of The Bike Shed. +Steph shares an update about integrating with Knapsack Pro. Chris is excited for larger projects that will begin in the next few weeks. They answer a listener's question on keeping backlogs connected to the product vision. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Linear (https://linear.app/) +RailsConf 2022 YouTube Playlist (https://www.youtube.com/playlist?list=PLbHJudTY1K0f1WgIbKCc0_M-XMraWwCmk) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: We don't need Skype anymore. We live in a post-Skype world, audio flapjacks. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. So let's see, recently, Utah, who's my dog for anyone that's not familiar, Utah had his very first beach trip. So we went down to Myrtle Beach area in South Carolina. And he had a grand old time because he's a water baby. Like, if there's water, he is in it. He loves it. So I was confident that he was going to like the beach, but I wasn't sure what he was going to think of the waves. +And luckily, there's an inlet area so that he could splash around and not be too worried about waves and had a wonderful time. He did take a huge gulp of saltwater because he's not used to that, and that threw him for a loop for a while. [chuckles] But overall, it was a lot of fun. He had a wonderful first time at the beach. +CHRIS: A live raptor on the beach. For continuity for anyone listening, I tend to call Utah Raptor because there are things called Utahraptors, and I can't call things by their normal name. It's just an affliction I have. But yeah, a raptor on the beach. +STEPH: He has a couple of nicknames going for him. There's someone else in my family that always refers to him as Tank; I think because they remind him of another dog named Tank. So yeah, he's got all the nicknames. +In some more tech-related news, I'm super excited that the Rails conference talks are now public. There are a number of talks that I'm interested in watching. And there's just such a killer lineup of topics and presenters, including a number of thoughtboters that presented this year. There are also several talks that focus on testing legacy code, which, as you know, is very relevant to my life right now. So I'm particularly interested in those talks. And frankly, I'm running out of doomsday movies to watch. So it's really good timing that I have these talks to help with my evenings where I need something to watch. +CHRIS: Now you say you're running out of doomsday movies, but have you watched Armageddon? +STEPH: [chuckles] No, it is on the list. So I have not completely run out. I have a very good one to still watch. +CHRIS: I'm not even that big a fan of the movie. It's just now a part of my public persona, apparently, and so I got to hold that line. But I didn't realize the RailsConf talks were out. That is super exciting. I will definitely have to check through those and pick out a few at a minimum, watching all of the wonderful talks by thoughtbot folks. So yeah, that's very exciting. +STEPH: Yeah, I'll be sure to include a link in the show notes so that way it's easy for folks to find and watch along. You and I also have some big news to share with everyone. As most listeners know, I've been prepping for maternity leave. And as part of that preparation, you and I have discussed ways to handle that period where I'm away and focused on being a new mom for six months. +We talked through a couple of ideas, and ultimately, you and I came to the conclusion that the timing feels right to end our season as host of The Bike Shed and transition the show to a new host, so a passing of the torch or a passing of the handlebars if you will. So even though you and I are leaving the show, The Bike Shed will continue to exist, and you and I will be here for the next couple of episodes. And the show will continue to be the wonderful show that it is today. And we'll share some more details about that in a future episode. +So while it's really exciting that someone new is going to take over the show, I think I can speak for both of us when I say that this definitely wasn't an easy decision. I know that I've really enjoyed this part of my life where we show up and share our development adventures. Although, to be honest, it's really all the nonsense; that's what I'm here for. That's been my favorite part, like our poor attempts to use sports analogies and renting goats to mow the grass. And I particularly love when you lean into segments about what grinds your gears. There's something about a spirited Chris Toomey "You know what grinds my gears?" rant [laughs] That really brings me a lot of joy. +CHRIS: Oh, well, that feels like it's too kind of a thing for you to say. And, well, this is already an emotional topic now. I'm feeling the feels. But yes, this has been such a joy to record the show with you. And again, we'll be here for a couple more episodes just to sort of segue over and provide some continuity. But yeah, it is, I think, the right time. We've both done this for a good bit of time now. I think we've said a lot of the things that we have to say. +I appreciate both the consistency in what we've had to say and also the way things have changed and the new elements that have come in and out. But yeah, I am excited for the next host, and we will introduce you to them in the very near future, dear listeners. At a minimum, and we'll get another chance to say this, but, Steph, it's been a real pleasure recording this podcast with you. +STEPH: Thank you. It has been a real pleasure. And I'm with you, this is hard to do, and it's hard to announce. But like you said, we'll have some more episodes, and then we will also have more of a finale episode where we can dig into all the feelings. But keeping some of those feelings at bay for now just because we will still have a couple more episodes to chat and then another episode where we can really dig into all of those feelings and then also reflect on our time as host of the show. +But returning to a technical note, I have an update I can share that's related to some of the testing work that Joël and I are doing. Specifically, we started integrating with a service called Knapsack Pro, which is a service that helps you parallelize your test suite across CI nodes to then speed up your test suite. And ultimately, what we really want to use are Knapsack Pro's cue mode and automatic splitting of large test files to help us then distribute those files across all of the available nodes. And we're still working on setting that up. So I don't have any cool or sparkly stats to share just yet. +But I have noticed some other wonderful features about Knapsack, specifically some of the reporting structure that they have. So a lot of this data Joël and I were collecting manually. So we were having to go through and figure out, okay, how long are test files taking? Which files are running on which process? Where do we have, like a tentpole, a particular file that's taking a lot longer than other files to run? And with the Knapsack UI, they're just telling us all of that data where they're showing us how long do the test files take? Which process is completing first versus completing last? +They also show what's the time span between the finished times of the CI node that started first versus the one that finished last? So we can see like, are we balancing well across all of these nodes or workers? So there's been already a lot of really good stuff that I've been seeing from Knapsack Pro that I'm really excited about. And we'll just have to see what comes next with the queue, what kind of time improvements that we can also see by taking this approach. +CHRIS: Oh, that's cool. I didn't realize you had started working with Knapsack Pro. That's definitely on my short list of things to consider, particularly as our test suite grows. Actually, on a quasi-related note, we this week had another developer who had been off for a couple of months in the summer; they just came back this week. And so we're sort of at full capacity. +And I've also been writing a couple of PRs this week. It's been exciting. I actually still remember how to code, which is cool; glad that that's still in there. I'm actually operating as point dev this week, which means that I am the support for our admin team wherever they need changes to customer accounts or things like that happening in the background. I'm also triaging all the bugs and things that are coming in, so there are a bunch of little PRs that I pushed through. +But interestingly, I've just not really looked at or optimized our CircleCI plan. But we keep going over our budget. And then it turns out that their pricing is structured in probably a reasonable way where we buy a plan that is this many build minutes for a month or this many build points or whatever it is, and we keep going over. And each of the overage charges are actually kind of expensive. And we're now doing it on a weekly basis which is I should probably rethink some stuff, figure out a more optimum strategy there. But there's a certain pride of like, oh yeah, look at us. We're burning through CI, really making a lot of PRs happen. +But I do remember there was a particular week where one of the developers was on vacation; somebody else was elsewhere. And so, our throughput on engineering dropped significantly. And we got this email from CircleCI. It was an automated email, but it was like they were negging us and they were like, "Hey, do you need some help unsticking your CI pipeline? Looks like your build minutes have dropped way down." +And I was like, whoa, CircleCI, I do not like the vibe that you're putting out there. So now there's this perverse pleasure in like yeah, that's right. We keep going over our limits, and then you charge us a bunch. But actually, I think you're winning in all of these cases, never mind [laughs] I'm just losing. But yeah, it was a fun sequence of emails from CircleCI. +STEPH: [laughs] That's one of those are you okay? Kind of emails that you get from a service. [laughs] That is fascinating. And yes, I think they're winning because they have then encouraged you to keep it up in terms of like the spend. You made me just think of one of the nice features that we've also noticed with or not so much a feature, but it is a process that they have with when you start your free trial with Knapsack to then integrate and see what the results look like. +I believe it's 14 days that they give you. But those 14 days only count for build time. So it's not just like from the day that you sign up to now you've got 14 days or business days; it is specifically allocated to the days that you're actually running builds. So I don't think they break it down in terms of hours worth of 14 days. +But it's like, hey, did you run a build today? Then we'll calculate that. Which has been nice because then there have been some side adventures that we've been interested in, and we've been allowed to pursue those side adventures because we know we can pause on Knapsack for just a little bit, but we're not going to lose that day as part of our free trial. +Their customer support has also been really nice where they've already...because Joël has been chatting with them with a couple of questions, and they've been very nice with like, hey, we know there are some issues that you're working through in terms of getting the cue mode up and running. So if you do need a couple of extra days, let us know. I wonder if Knapsack Pro will be cool with me sharing that inside baseball, but [laughs] their customer service has been very helpful and nice in that regard. +CHRIS: I feel like there's such a subtle art to structuring a free trial and particularly the thing you're describing of the way they pace it out. And like, we don't really count it if you're not using it, which makes a lot of sense. There have been so many free trials that I've tried in my life. But like, I started the free trial, and then I forgot about you for a few days. And then I didn't integrate or use. If we're being honest, my free trial has expired, and I have no idea if I want to use you as a service. +And I know many platforms will offer to restart your trial or things like that or extend it, or the metered trial days that Knapsack has is an interesting one that I don't think I've heard of before, but I like it as an approach. And I think, frankly, it serves them. They want to give people an actual opportunity to try out the platform and decide if it works for them, and that takes a day or two, it turns out. +STEPH: Yeah, I agree. Some of the additional information that they've shown us, as I've been talking about, like the niceties that they've included around the build metrics. They also show you your longest-running test files. So they also have an auto-splitting feature that we haven't tweaked correctly just yet, so I'm waiting to see that happen. But even then, just knowing the build metrics, because again, this is information that Joël and I were working on manually to collect from all the stats that we could from RSpec and using parallel_tests. +But now we can just go to the build metrics, and we can see like, oh, these are our top files that take the longest, and then Knapsack Pro tells us your ideal test time for a file is like this number. So to give a concrete number for us, it'd be like around 6 minutes, and 20 seconds would be our ideal time that each node runs. Now, that's probably going to require splitting some of those files because we have a couple of files that take more like eight, nine minutes. But it's so nice to be able to see that and not have to run scripts that we have crafted together to then be able to identify our slowest test. +But once we get cue mode working and then also the automatic splitting of files, I'll be sure to keep you updated because I'm hoping we're going to see some sparkly stats in terms of then how the tests are getting distributed and that we'll be able to bring the CI time down at least for this portion; it won't be for the whole build but for running the RSpec suite. +If we can match that ideal time that we've seen and that Knapsack Pro says that if we balance everything in split files, then the ideal run time is around six or seven minutes. So here's hoping. But that's really what's going on in my world. What's going on in your world? +CHRIS: My world is, I would say, largely the same as it has been. We've been sort of between large projects for a bit now. We've been taking that time to build out some infrastructure, get some smaller things done, some niceties, enhancement, tweaks, et cetera. But at this point, I would say the storm's brewing. The larger projects that we are planning for, mostly Q3 sort of thing, are all kind of coming to a head right now. And so I'm kind of excited. +I'm ready. I'm ready for a bigger challenge, something to sink our teeth into and really dive into. So yeah, it's been, I would say, very calm of late in a very positive way but almost maybe too calm. And so I'm ready for, yeah, for different things to try out and some stuff to really dig into and grow the Sagewell platform. But yeah, that's most of what's up in my world. +MIDROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half. +So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPH: Well, that's kind of a perfect topic or a jumping-off point for a question that we received recently from a listener that's very focused around when you have a lot of work. And since you've got a lot of work, it sounds like, coming down the pipeline, then how to manage a lot of small projects, and then keep the team in sync with each other. So let me back up and read their question so that way we don't miss any of the good bits. +But this question comes from Brian, and Brian writes in, "I've got a listener question for y'all. How do you like to or have seen teams keep the vision of the product clear yet connected to the backlog such that tasks don't feel like a disconnected set of work, especially when the team stream count grows? +To expand on my question, the common situation I've seen is when a team has multiple work streams in flight, so using like a backlog tool like Jira or Trello shows a stream of work, but it's hard to associate the stories and tasks either to the bigger picture of the goals or the system's end state. That has slowed down new teammates' onboarding. +It's made identifying necessary but missing stories harder earlier on. It's also made reviewing work require more context switching or made it harder for interested parties to track progress. It's also caused tension on teams when individuals have different ideas of the goals and the end state of the work. I can see some obvious options to help but curious what your general and specific experiences and advice might be." +All right, so speaking of lots of work coming down the pipeline and managing some small projects, Chris, do you have any initial thoughts around lots of big questions here in terms of keeping the backlog connected to the product vision? +CHRIS: Yeah, I have a bunch of little thoughts that I'm happy to share. But to sort of go bigger picture on this, I think the question that Brian is asking here is one of the hard questions of the work that we do. It's like, how do we keep everybody in sync and understanding the big picture while working on the small individual pieces? Like, that's the hard stuff. +That's the place where communication problems can happen or where the larger team you have, you start to feel those growing pains, et cetera. So to name it, this is just a hard thing. This is one of those hard things that I don't have any silver bullet by any means. But I do have a couple of things that have worked for me in the past. +So the first is having some notion within whatever tool that you're working on of the bigger picture of the projects. And so recently, just to use Sagewell as an example, we started on Trello. And when we were using Trello, we had a projects list off to the side. So there's the actual backlog of next-up work. But next to it, we had a projects list that was a little higher level zoomed out, trying to group things into sections. +Pretty quickly, even with our small team, that became insufficient to actually track these things and try and tie small pieces of work back to the bigger project that they were associated with. So we introduced something called I'm going to say it's Hello Epics is the name of the extension for Trello. But it's very much a grafting on of functionality. It's like a Chrome extension; I want to say that takes advantage of card linking and Trello and tries to make some version of this happen. +It was okay, but we, again, sort of hit the ceiling of that. We somewhat recently, I'm going to say, a couple of months ago, moved to Linear, and Linear has a more formal idea of projects within certain functional areas. And there are ways that projects sort of span different teams, and individual tasks can associate back to projects. And I would say, for us, it's been just the right amount of structure. I want to have that continuity and the linking between things. But I don't need it to be too fancy. +There is a Gantt chart view in Linear, and I look at it, and I'm like, wow, those are dates. You made some guesses there, Linear. Good luck, we'll see if it happens; I don't know. But overall, that functionality has been great and sufficient for where we're at. So that's one thing. +Another thing that comes to mind is trying to keep those scoped. So those projects that I'm talking about this is one of the things that I push on a lot is I want that list to be turning over semi-regularly. So we shouldn't have projects that are just like for the next two years, we're building the admin UI, and that's just this sort of open-ended amorphous, unclear project. +I like to really push for let's get to some deliverable, some doable line, some perhaps arbitrary MVP definition that we define. But let's make it so that each of these projects is doable such that if something stays in that list for too long, our attention is drawn to that. We don't just become numb to the idea that I don't know, there's a list of projects, but some of them are kind of dead in the water, kind of just hanging around and not quite complete. I want that to be a mechanism for reviewing the work that we have in process. +And so often, it almost feels somewhat artificial, but we'll break a bigger body of work down into smaller projects. And so there's like V1 of a thing, and then there's V1.2. And we get somewhat cheeky with the names at times. But I found a lot of value in having that sort of idea of let's define a boundary around a portion of this work, give it a name, and decide are we done with that or not? And each week, we get asked that question, particularly around our product planning meeting. And that has been really useful, particularly to make sure that stuff has a broader context that it's connected to. +The last thing that I'll say that has been super useful is retro because what you're describing, again, is one of the harder things. This is really difficult to get right. It's going to be different in each team at different team sizes, at different complexities of product and platform that you're building. You're going to feel this in different ways. And so retro, by far, is the most effective tool I know of to ensure that you are naming and responding to the pain points that you have in your own workflows. +There's no one size fits all for this sort of thing. But if you have a process that regularly has you come up for air, take a look at what you're doing and decide is this going well or is this not well? Are we missing critical features? Are developers lacking context? Is it hard to move people between teams or whatever the pain point may be? Then you can try and focus in and actually find solutions specific to that. +But again, I can't answer it for you. All I can say is like, by far, retro is the most effective thing I've ever seen for trying to answer that question. So yeah, a couple of thoughts. I don't know. What do you think, Steph? +STEPH: I think this is one of those rare moments that you hear someone in a leadership position express that they want high turnover; that is something that they're shooting for. +CHRIS: Turnover projects, not people. I like people. +STEPH: [laughs] I know. +CHRIS: People are moral. People are great. As you said it, I was like, wait, what did I say? Oh, right. No, I didn't. Okay, I got it now. +STEPH: [laughs] I left out that important word, high turnover of projects and tickets, yes. [laughs] It amused me as I was thinking about it as you mentioned that it's nice to have that consistent turnover in terms of like, you know that something may have gotten scoped too largely if it's sitting there for a while. Unsurprisingly, all the things that you said are wonderful. I love that you sprinkled retro in there at the end since, as you mentioned, this is hard, and it's going to be hard to get it right. So keep checking in with your team to see where improvements can be made. +I'm going to share a recommendation that actually starts with a pain point and then kind of walk it through from there. So one of the areas that Brian highlighted about that is that it makes it harder for interested parties to track progress. I really liked that one because I've also felt that pain. One way that I've experienced teams manage it that I wasn't a fan of is where people would just go to developers where they saw someone's name on a ticket, and they would ask for updates. +And the reason I didn't care for that is because it just felt too isolated. And then it felt like work where someone then had to identify who's working on this and getting an update. And then it felt almost stressful to then have someone checking in with you in that regard to be like, hey, how's this ticket going? And then what's the update on this? Versus having a more formal process of like, this is how we update our work. +So that sort of like one-off behavior of where then someone who's interested in this has to go find the person that's working on it and then check in with them, I think wasn't great for that person. And then it's also not great for the developer who then needs to switch context and provide a high-level overview of when they think something might be done or how it's going. Because then they need to translate from their developer-focus to then more product-focused. +A slight improvement on that process was at least to keep it public. So then, if there was someone that was in more of like a sales role or a customer support role, and then they were curious about something, is at least don't make that a private conversation. So instead of messaging that developer directly, at least put it in a channel where then anybody could respond, which is then nice because then other people can see that someone is checking in on this; they're interested in it. If that person's out, maybe someone else can respond on their behalf, but at least at a minimum, keep it public. +Even better is if you can have just a point person, so this is probably your product manager who then someone that's in sales or customer service can go to and say, "Hey, I'd love an update." And then maybe that product manager turns around and goes to the developer and asks questions, but at least they know who to go to, and so they don't have to find the person to follow up with. +Another approach that I'm currently experiencing with my team is we do have a number of small projects that are going on within the same team. So there is an important Ruby and Rails upgrade that's going on. There's the normal day-to-day work that needs to get done. And then there's also the CI performance improvement that Joël and I are working on. And this goes back to your point in terms of use all the tools that can then help you promote the work that's getting done. +So in our case, we've actually built on you can see in one board, but then you can have subsets, or you can have streams inside those boards. So then you can have a board that is titled...board is kind of a fancy term. It's more like a line item on one larger board for a team to use some weird terminology. [laughs] But I can't think of a more correct term for it. +So there's a line item that focuses on Rails and Ruby upgrade. And then there's a line that focuses on other work that's being done, and then that's RSpec-specific performance improvements. And that has felt very nice because then you section each thing together, and you can focus on one at a time. +It does expand the context that you have with the work that's going on with that team. And I do have mixed feelings about it because, on one hand, it does make your daily sync longer because then there are people sharing updates or looking for help on things that you frankly don't have a lot of context and that you're not working on. So it can feel a little wasteful to then sit there while they're going through updates for work that you're not part of. +But then it's also been really nice because then you get that high-level context. So you don't really have to know the details, but you're at least aware of that work that's being done. So then that way, if a question does come up, you have enough context that you can say, "Oh, I know a little bit about that," or "I know who's working on it," or "I know who to follow up with." So I think the time trade-off is worth it. Even if it may feel a little painful some days, I think it's still really nice. +And then also, if you can look for opportunities to form sub-teams where if there's a group and there's work that you can group together. So maybe if you look at the type of work that's coming downstream, like, if you are working on one portion of the application and you see that another big feature is working on that similar area, then maybe grouping that stuff together to reduce some of the context switching is really nice. +The buddy system also works really well, and maybe that's pairing, maybe it's not, but it's at least having two people that are working on a larger project. So using that RSpec CI performance improvement as an example, Joël and I both have a lot of context on this. And so that way, one, we always have a buddy, someone to reach out to and talk to. But then for like the CRs or PRs that I'm pushing up, then I usually will tag Joël on those because I know he already has the context. +So I'm trying not to bring other people in unless they just want to, but that way, Joël's there, and it makes for a quicker review. So that's one nice benefit of the buddy system is because there's at least one person that has enough context where it's not as big of a hurdle for them. And they don't have to ask as many questions and then get caught up to speed before reviewing your changes. +There's another area that Brian identified as struggling to identify important work but missing stories. I'm intrigued by that one because I'm trying to think of where a team is working on a project, but because you've got so many small projects, you may have forgotten about a particular task that needs to get done, or maybe you need to collaborate with another team, and that's something that slipped through the cracks. I don't think I have a great solution for that one, except with time and experience, you'll start to identify some of those areas where have we thought through, like the different teams and communications and the different services that we may need to integrate with? +And then I also think it's fine, like, if you've got someone working on a project, it shouldn't be so thoroughly scoped upfront that there's not room for discovery. So if you have one or two people on that project and they're like, hey, actually, I need to create a ticket for this, I think that feels totally reasonable that that's part of that discovery process. +CHRIS: Yeah, I think I share that take, or I guess a different way to say it is I don't feel the pain of stuff falling through. But that's because we have kind of a continuous process of as we're working on things, we're like, oh, didn't think of X. And then it's very much a part of our process to throw a ticket into the inbox. And our product manager will then triage that and decide relatively where it goes. But everyone is empowered to do that, everyone that's working on the product, such that we have no expectation of being able to fully scope things out in advance. +And thus the idea of missing a ticket...if it gets to a user and like we forgot to build a critical feature, then, well, that would be sad, but that tends to not happen because just the nature of the process is we're in there. And the idea of the fog of war, like, you can't know until you know. You got to go out there in the forest, and then the fog starts to clear. And then you can see, oh, there's a goldmine there. I'm going to stop with my analogy now. +But more generally, this is just sort of agile in my mind. I'm a big fan of limiting the specificity the further out a project plan is. So right now, we're working on the concrete implementation of a thing. Cool, that's real. Let's have detailed tickets that describe as much as necessary to actually do the work. And then like a little further out the projects, let's talk about the feature level. What's the screen that we want to build but not necessarily all of the nitty-gritty details? +And then, further than that, the roadmap, I want to get away from either implementation or feature level and go to benefits. What's the user going to be able to do as a result of this? And user can be a little bit abstract where your customers are developers right now on the team. You're trying to empower them. So it's like CI needs to be faster. And so that's the benefit that we're trying to get to. And then the features are what we want to do — splitting into queues, and then the actual implementation is integrate Knapsack Pro and whatnot. +And the closer the work is to actually being something that you're tackling, the more specificity I think is useful. But very purposefully, I will avoid specificity for things that are more than a month or two out just to be like, can those just be bullet items on a list that kind of talk about how happy a user will be when we do it but not actually constrain ourselves to a particular feature or implementation? Because we're going to figure some stuff out and it's going to change. +And also, it's so much easier, like the idea of the team not being able to picture all of the different moving pieces of work. If your roadmap is simple in a couple of bullet items, then it's much easier for everyone to be like, yeah, I kind of know all the stuff that we're going to be doing, that we think we'll be doing in six months. Could change turns out, but that's a thing that I'm a big fan of is limiting the specificity further out. +And I've worked on many projects where like, no, no, we absolutely need to know down to the day how long this roadmap will take that we think is about a year. And it's like, that's not real. That's not a real thing. Stuff's going to change. I assure you. +STEPH: I love that. The further out that you get, you focus more on benefits versus implementation. I think that hits home for so many reasons and helps address a number of the concerns that Brian brought up. +I did think of one more strategy that I've seen that I've also enjoyed is where if you do have an interested party who is like, hey, I've got, I don't know, maybe you've got a customer that's really mad about something, and there's a bug fix. And so this person in customer support really wants to be able to know exactly how this bug is going. Invite them to your daily sync. Let them attend, and they can come, and they'll know who's working on it. They can get a daily update as to how things are going. I think that's a really nice addition. +There's also the idea that if you are collaborating closely with another team and so your work is very important to theirs or vice versa, also have one person from their team join your daily sync or vice versa. But then that way, you have that communication. And that way, you can check in with each other, and you're at least aware of that high-level context in terms of like, oh, we're waiting on this team for designs or for a new server or something, things like that. Then they can provide an update, or you can provide an update to them. +CHRIS: I probably shouldn't be surprised, but we had a surprising amount to say about that question. [laughs] It's really in our wheelhouse, the sort of stuff that we like to dig into. How do we do the work? You know, that's the question here on The Bike Shed. But I think with all of those notes, Brian, I hope that helps with what you're doing. And yeah, what do you think, Steph? Should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph and Chris share some big news about the future of The Bike Shed.

+ +

Steph shares an update about integrating with Knapsack Pro. Chris is excited for larger projects that will begin in the next few weeks. They answer a listener's question on keeping backlogs connected to the product vision.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Linear
+RailsConf 2022 YouTube Playlist

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: We don't need Skype anymore. We live in a post-Skype world, audio flapjacks.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So let's see, recently, Utah, who's my dog for anyone that's not familiar, Utah had his very first beach trip. So we went down to Myrtle Beach area in South Carolina. And he had a grand old time because he's a water baby. Like, if there's water, he is in it. He loves it. So I was confident that he was going to like the beach, but I wasn't sure what he was going to think of the waves.

+ +

And luckily, there's an inlet area so that he could splash around and not be too worried about waves and had a wonderful time. He did take a huge gulp of saltwater because he's not used to that, and that threw him for a loop for a while. [chuckles] But overall, it was a lot of fun. He had a wonderful first time at the beach.

+ +

CHRIS: A live raptor on the beach. For continuity for anyone listening, I tend to call Utah Raptor because there are things called Utahraptors, and I can't call things by their normal name. It's just an affliction I have. But yeah, a raptor on the beach.

+ +

STEPH: He has a couple of nicknames going for him. There's someone else in my family that always refers to him as Tank; I think because they remind him of another dog named Tank. So yeah, he's got all the nicknames.

+ +

In some more tech-related news, I'm super excited that the Rails conference talks are now public. There are a number of talks that I'm interested in watching. And there's just such a killer lineup of topics and presenters, including a number of thoughtboters that presented this year. There are also several talks that focus on testing legacy code, which, as you know, is very relevant to my life right now. So I'm particularly interested in those talks. And frankly, I'm running out of doomsday movies to watch. So it's really good timing that I have these talks to help with my evenings where I need something to watch.

+ +

CHRIS: Now you say you're running out of doomsday movies, but have you watched Armageddon?

+ +

STEPH: [chuckles] No, it is on the list. So I have not completely run out. I have a very good one to still watch.

+ +

CHRIS: I'm not even that big a fan of the movie. It's just now a part of my public persona, apparently, and so I got to hold that line. But I didn't realize the RailsConf talks were out. That is super exciting. I will definitely have to check through those and pick out a few at a minimum, watching all of the wonderful talks by thoughtbot folks. So yeah, that's very exciting.

+ +

STEPH: Yeah, I'll be sure to include a link in the show notes so that way it's easy for folks to find and watch along. You and I also have some big news to share with everyone. As most listeners know, I've been prepping for maternity leave. And as part of that preparation, you and I have discussed ways to handle that period where I'm away and focused on being a new mom for six months.

+ +

We talked through a couple of ideas, and ultimately, you and I came to the conclusion that the timing feels right to end our season as host of The Bike Shed and transition the show to a new host, so a passing of the torch or a passing of the handlebars if you will. So even though you and I are leaving the show, The Bike Shed will continue to exist, and you and I will be here for the next couple of episodes. And the show will continue to be the wonderful show that it is today. And we'll share some more details about that in a future episode.

+ +

So while it's really exciting that someone new is going to take over the show, I think I can speak for both of us when I say that this definitely wasn't an easy decision. I know that I've really enjoyed this part of my life where we show up and share our development adventures. Although, to be honest, it's really all the nonsense; that's what I'm here for. That's been my favorite part, like our poor attempts to use sports analogies and renting goats to mow the grass. And I particularly love when you lean into segments about what grinds your gears. There's something about a spirited Chris Toomey "You know what grinds my gears?" rant [laughs] That really brings me a lot of joy.

+ +

CHRIS: Oh, well, that feels like it's too kind of a thing for you to say. And, well, this is already an emotional topic now. I'm feeling the feels. But yes, this has been such a joy to record the show with you. And again, we'll be here for a couple more episodes just to sort of segue over and provide some continuity. But yeah, it is, I think, the right time. We've both done this for a good bit of time now. I think we've said a lot of the things that we have to say.

+ +

I appreciate both the consistency in what we've had to say and also the way things have changed and the new elements that have come in and out. But yeah, I am excited for the next host, and we will introduce you to them in the very near future, dear listeners. At a minimum, and we'll get another chance to say this, but, Steph, it's been a real pleasure recording this podcast with you.

+ +

STEPH: Thank you. It has been a real pleasure. And I'm with you, this is hard to do, and it's hard to announce. But like you said, we'll have some more episodes, and then we will also have more of a finale episode where we can dig into all the feelings. But keeping some of those feelings at bay for now just because we will still have a couple more episodes to chat and then another episode where we can really dig into all of those feelings and then also reflect on our time as host of the show.

+ +

But returning to a technical note, I have an update I can share that's related to some of the testing work that Joël and I are doing. Specifically, we started integrating with a service called Knapsack Pro, which is a service that helps you parallelize your test suite across CI nodes to then speed up your test suite. And ultimately, what we really want to use are Knapsack Pro's cue mode and automatic splitting of large test files to help us then distribute those files across all of the available nodes. And we're still working on setting that up. So I don't have any cool or sparkly stats to share just yet.

+ +

But I have noticed some other wonderful features about Knapsack, specifically some of the reporting structure that they have. So a lot of this data Joël and I were collecting manually. So we were having to go through and figure out, okay, how long are test files taking? Which files are running on which process? Where do we have, like a tentpole, a particular file that's taking a lot longer than other files to run? And with the Knapsack UI, they're just telling us all of that data where they're showing us how long do the test files take? Which process is completing first versus completing last?

+ +

They also show what's the time span between the finished times of the CI node that started first versus the one that finished last? So we can see like, are we balancing well across all of these nodes or workers? So there's been already a lot of really good stuff that I've been seeing from Knapsack Pro that I'm really excited about. And we'll just have to see what comes next with the queue, what kind of time improvements that we can also see by taking this approach.

+ +

CHRIS: Oh, that's cool. I didn't realize you had started working with Knapsack Pro. That's definitely on my short list of things to consider, particularly as our test suite grows. Actually, on a quasi-related note, we this week had another developer who had been off for a couple of months in the summer; they just came back this week. And so we're sort of at full capacity.

+ +

And I've also been writing a couple of PRs this week. It's been exciting. I actually still remember how to code, which is cool; glad that that's still in there. I'm actually operating as point dev this week, which means that I am the support for our admin team wherever they need changes to customer accounts or things like that happening in the background. I'm also triaging all the bugs and things that are coming in, so there are a bunch of little PRs that I pushed through.

+ +

But interestingly, I've just not really looked at or optimized our CircleCI plan. But we keep going over our budget. And then it turns out that their pricing is structured in probably a reasonable way where we buy a plan that is this many build minutes for a month or this many build points or whatever it is, and we keep going over. And each of the overage charges are actually kind of expensive. And we're now doing it on a weekly basis which is I should probably rethink some stuff, figure out a more optimum strategy there. But there's a certain pride of like, oh yeah, look at us. We're burning through CI, really making a lot of PRs happen.

+ +

But I do remember there was a particular week where one of the developers was on vacation; somebody else was elsewhere. And so, our throughput on engineering dropped significantly. And we got this email from CircleCI. It was an automated email, but it was like they were negging us and they were like, "Hey, do you need some help unsticking your CI pipeline? Looks like your build minutes have dropped way down."

+ +

And I was like, whoa, CircleCI, I do not like the vibe that you're putting out there. So now there's this perverse pleasure in like yeah, that's right. We keep going over our limits, and then you charge us a bunch. But actually, I think you're winning in all of these cases, never mind [laughs] I'm just losing. But yeah, it was a fun sequence of emails from CircleCI.

+ +

STEPH: [laughs] That's one of those are you okay? Kind of emails that you get from a service. [laughs] That is fascinating. And yes, I think they're winning because they have then encouraged you to keep it up in terms of like the spend. You made me just think of one of the nice features that we've also noticed with or not so much a feature, but it is a process that they have with when you start your free trial with Knapsack to then integrate and see what the results look like.

+ +

I believe it's 14 days that they give you. But those 14 days only count for build time. So it's not just like from the day that you sign up to now you've got 14 days or business days; it is specifically allocated to the days that you're actually running builds. So I don't think they break it down in terms of hours worth of 14 days.

+ +

But it's like, hey, did you run a build today? Then we'll calculate that. Which has been nice because then there have been some side adventures that we've been interested in, and we've been allowed to pursue those side adventures because we know we can pause on Knapsack for just a little bit, but we're not going to lose that day as part of our free trial.

+ +

Their customer support has also been really nice where they've already...because Joël has been chatting with them with a couple of questions, and they've been very nice with like, hey, we know there are some issues that you're working through in terms of getting the cue mode up and running. So if you do need a couple of extra days, let us know. I wonder if Knapsack Pro will be cool with me sharing that inside baseball, but [laughs] their customer service has been very helpful and nice in that regard.

+ +

CHRIS: I feel like there's such a subtle art to structuring a free trial and particularly the thing you're describing of the way they pace it out. And like, we don't really count it if you're not using it, which makes a lot of sense. There have been so many free trials that I've tried in my life. But like, I started the free trial, and then I forgot about you for a few days. And then I didn't integrate or use. If we're being honest, my free trial has expired, and I have no idea if I want to use you as a service.

+ +

And I know many platforms will offer to restart your trial or things like that or extend it, or the metered trial days that Knapsack has is an interesting one that I don't think I've heard of before, but I like it as an approach. And I think, frankly, it serves them. They want to give people an actual opportunity to try out the platform and decide if it works for them, and that takes a day or two, it turns out.

+ +

STEPH: Yeah, I agree. Some of the additional information that they've shown us, as I've been talking about, like the niceties that they've included around the build metrics. They also show you your longest-running test files. So they also have an auto-splitting feature that we haven't tweaked correctly just yet, so I'm waiting to see that happen. But even then, just knowing the build metrics, because again, this is information that Joël and I were working on manually to collect from all the stats that we could from RSpec and using parallel_tests.

+ +

But now we can just go to the build metrics, and we can see like, oh, these are our top files that take the longest, and then Knapsack Pro tells us your ideal test time for a file is like this number. So to give a concrete number for us, it'd be like around 6 minutes, and 20 seconds would be our ideal time that each node runs. Now, that's probably going to require splitting some of those files because we have a couple of files that take more like eight, nine minutes. But it's so nice to be able to see that and not have to run scripts that we have crafted together to then be able to identify our slowest test.

+ +

But once we get cue mode working and then also the automatic splitting of files, I'll be sure to keep you updated because I'm hoping we're going to see some sparkly stats in terms of then how the tests are getting distributed and that we'll be able to bring the CI time down at least for this portion; it won't be for the whole build but for running the RSpec suite.

+ +

If we can match that ideal time that we've seen and that Knapsack Pro says that if we balance everything in split files, then the ideal run time is around six or seven minutes. So here's hoping. But that's really what's going on in my world. What's going on in your world?

+ +

CHRIS: My world is, I would say, largely the same as it has been. We've been sort of between large projects for a bit now. We've been taking that time to build out some infrastructure, get some smaller things done, some niceties, enhancement, tweaks, et cetera. But at this point, I would say the storm's brewing. The larger projects that we are planning for, mostly Q3 sort of thing, are all kind of coming to a head right now. And so I'm kind of excited.

+ +

I'm ready. I'm ready for a bigger challenge, something to sink our teeth into and really dive into. So yeah, it's been, I would say, very calm of late in a very positive way but almost maybe too calm. And so I'm ready for, yeah, for different things to try out and some stuff to really dig into and grow the Sagewell platform. But yeah, that's most of what's up in my world.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPH: Well, that's kind of a perfect topic or a jumping-off point for a question that we received recently from a listener that's very focused around when you have a lot of work. And since you've got a lot of work, it sounds like, coming down the pipeline, then how to manage a lot of small projects, and then keep the team in sync with each other. So let me back up and read their question so that way we don't miss any of the good bits.

+ +

But this question comes from Brian, and Brian writes in, "I've got a listener question for y'all. How do you like to or have seen teams keep the vision of the product clear yet connected to the backlog such that tasks don't feel like a disconnected set of work, especially when the team stream count grows?

+ +

To expand on my question, the common situation I've seen is when a team has multiple work streams in flight, so using like a backlog tool like Jira or Trello shows a stream of work, but it's hard to associate the stories and tasks either to the bigger picture of the goals or the system's end state. That has slowed down new teammates' onboarding.

+ +

It's made identifying necessary but missing stories harder earlier on. It's also made reviewing work require more context switching or made it harder for interested parties to track progress. It's also caused tension on teams when individuals have different ideas of the goals and the end state of the work. I can see some obvious options to help but curious what your general and specific experiences and advice might be."

+ +

All right, so speaking of lots of work coming down the pipeline and managing some small projects, Chris, do you have any initial thoughts around lots of big questions here in terms of keeping the backlog connected to the product vision?

+ +

CHRIS: Yeah, I have a bunch of little thoughts that I'm happy to share. But to sort of go bigger picture on this, I think the question that Brian is asking here is one of the hard questions of the work that we do. It's like, how do we keep everybody in sync and understanding the big picture while working on the small individual pieces? Like, that's the hard stuff.

+ +

That's the place where communication problems can happen or where the larger team you have, you start to feel those growing pains, et cetera. So to name it, this is just a hard thing. This is one of those hard things that I don't have any silver bullet by any means. But I do have a couple of things that have worked for me in the past.

+ +

So the first is having some notion within whatever tool that you're working on of the bigger picture of the projects. And so recently, just to use Sagewell as an example, we started on Trello. And when we were using Trello, we had a projects list off to the side. So there's the actual backlog of next-up work. But next to it, we had a projects list that was a little higher level zoomed out, trying to group things into sections.

+ +

Pretty quickly, even with our small team, that became insufficient to actually track these things and try and tie small pieces of work back to the bigger project that they were associated with. So we introduced something called I'm going to say it's Hello Epics is the name of the extension for Trello. But it's very much a grafting on of functionality. It's like a Chrome extension; I want to say that takes advantage of card linking and Trello and tries to make some version of this happen.

+ +

It was okay, but we, again, sort of hit the ceiling of that. We somewhat recently, I'm going to say, a couple of months ago, moved to Linear, and Linear has a more formal idea of projects within certain functional areas. And there are ways that projects sort of span different teams, and individual tasks can associate back to projects. And I would say, for us, it's been just the right amount of structure. I want to have that continuity and the linking between things. But I don't need it to be too fancy.

+ +

There is a Gantt chart view in Linear, and I look at it, and I'm like, wow, those are dates. You made some guesses there, Linear. Good luck, we'll see if it happens; I don't know. But overall, that functionality has been great and sufficient for where we're at. So that's one thing.

+ +

Another thing that comes to mind is trying to keep those scoped. So those projects that I'm talking about this is one of the things that I push on a lot is I want that list to be turning over semi-regularly. So we shouldn't have projects that are just like for the next two years, we're building the admin UI, and that's just this sort of open-ended amorphous, unclear project.

+ +

I like to really push for let's get to some deliverable, some doable line, some perhaps arbitrary MVP definition that we define. But let's make it so that each of these projects is doable such that if something stays in that list for too long, our attention is drawn to that. We don't just become numb to the idea that I don't know, there's a list of projects, but some of them are kind of dead in the water, kind of just hanging around and not quite complete. I want that to be a mechanism for reviewing the work that we have in process.

+ +

And so often, it almost feels somewhat artificial, but we'll break a bigger body of work down into smaller projects. And so there's like V1 of a thing, and then there's V1.2. And we get somewhat cheeky with the names at times. But I found a lot of value in having that sort of idea of let's define a boundary around a portion of this work, give it a name, and decide are we done with that or not? And each week, we get asked that question, particularly around our product planning meeting. And that has been really useful, particularly to make sure that stuff has a broader context that it's connected to.

+ +

The last thing that I'll say that has been super useful is retro because what you're describing, again, is one of the harder things. This is really difficult to get right. It's going to be different in each team at different team sizes, at different complexities of product and platform that you're building. You're going to feel this in different ways. And so retro, by far, is the most effective tool I know of to ensure that you are naming and responding to the pain points that you have in your own workflows.

+ +

There's no one size fits all for this sort of thing. But if you have a process that regularly has you come up for air, take a look at what you're doing and decide is this going well or is this not well? Are we missing critical features? Are developers lacking context? Is it hard to move people between teams or whatever the pain point may be? Then you can try and focus in and actually find solutions specific to that.

+ +

But again, I can't answer it for you. All I can say is like, by far, retro is the most effective thing I've ever seen for trying to answer that question. So yeah, a couple of thoughts. I don't know. What do you think, Steph?

+ +

STEPH: I think this is one of those rare moments that you hear someone in a leadership position express that they want high turnover; that is something that they're shooting for.

+ +

CHRIS: Turnover projects, not people. I like people.

+ +

STEPH: [laughs] I know.

+ +

CHRIS: People are moral. People are great. As you said it, I was like, wait, what did I say? Oh, right. No, I didn't. Okay, I got it now.

+ +

STEPH: [laughs] I left out that important word, high turnover of projects and tickets, yes. [laughs] It amused me as I was thinking about it as you mentioned that it's nice to have that consistent turnover in terms of like, you know that something may have gotten scoped too largely if it's sitting there for a while. Unsurprisingly, all the things that you said are wonderful. I love that you sprinkled retro in there at the end since, as you mentioned, this is hard, and it's going to be hard to get it right. So keep checking in with your team to see where improvements can be made.

+ +

I'm going to share a recommendation that actually starts with a pain point and then kind of walk it through from there. So one of the areas that Brian highlighted about that is that it makes it harder for interested parties to track progress. I really liked that one because I've also felt that pain. One way that I've experienced teams manage it that I wasn't a fan of is where people would just go to developers where they saw someone's name on a ticket, and they would ask for updates.

+ +

And the reason I didn't care for that is because it just felt too isolated. And then it felt like work where someone then had to identify who's working on this and getting an update. And then it felt almost stressful to then have someone checking in with you in that regard to be like, hey, how's this ticket going? And then what's the update on this? Versus having a more formal process of like, this is how we update our work.

+ +

So that sort of like one-off behavior of where then someone who's interested in this has to go find the person that's working on it and then check in with them, I think wasn't great for that person. And then it's also not great for the developer who then needs to switch context and provide a high-level overview of when they think something might be done or how it's going. Because then they need to translate from their developer-focus to then more product-focused.

+ +

A slight improvement on that process was at least to keep it public. So then, if there was someone that was in more of like a sales role or a customer support role, and then they were curious about something, is at least don't make that a private conversation. So instead of messaging that developer directly, at least put it in a channel where then anybody could respond, which is then nice because then other people can see that someone is checking in on this; they're interested in it. If that person's out, maybe someone else can respond on their behalf, but at least at a minimum, keep it public.

+ +

Even better is if you can have just a point person, so this is probably your product manager who then someone that's in sales or customer service can go to and say, "Hey, I'd love an update." And then maybe that product manager turns around and goes to the developer and asks questions, but at least they know who to go to, and so they don't have to find the person to follow up with.

+ +

Another approach that I'm currently experiencing with my team is we do have a number of small projects that are going on within the same team. So there is an important Ruby and Rails upgrade that's going on. There's the normal day-to-day work that needs to get done. And then there's also the CI performance improvement that Joël and I are working on. And this goes back to your point in terms of use all the tools that can then help you promote the work that's getting done.

+ +

So in our case, we've actually built on you can see in one board, but then you can have subsets, or you can have streams inside those boards. So then you can have a board that is titled...board is kind of a fancy term. It's more like a line item on one larger board for a team to use some weird terminology. [laughs] But I can't think of a more correct term for it.

+ +

So there's a line item that focuses on Rails and Ruby upgrade. And then there's a line that focuses on other work that's being done, and then that's RSpec-specific performance improvements. And that has felt very nice because then you section each thing together, and you can focus on one at a time.

+ +

It does expand the context that you have with the work that's going on with that team. And I do have mixed feelings about it because, on one hand, it does make your daily sync longer because then there are people sharing updates or looking for help on things that you frankly don't have a lot of context and that you're not working on. So it can feel a little wasteful to then sit there while they're going through updates for work that you're not part of.

+ +

But then it's also been really nice because then you get that high-level context. So you don't really have to know the details, but you're at least aware of that work that's being done. So then that way, if a question does come up, you have enough context that you can say, "Oh, I know a little bit about that," or "I know who's working on it," or "I know who to follow up with." So I think the time trade-off is worth it. Even if it may feel a little painful some days, I think it's still really nice.

+ +

And then also, if you can look for opportunities to form sub-teams where if there's a group and there's work that you can group together. So maybe if you look at the type of work that's coming downstream, like, if you are working on one portion of the application and you see that another big feature is working on that similar area, then maybe grouping that stuff together to reduce some of the context switching is really nice.

+ +

The buddy system also works really well, and maybe that's pairing, maybe it's not, but it's at least having two people that are working on a larger project. So using that RSpec CI performance improvement as an example, Joël and I both have a lot of context on this. And so that way, one, we always have a buddy, someone to reach out to and talk to. But then for like the CRs or PRs that I'm pushing up, then I usually will tag Joël on those because I know he already has the context.

+ +

So I'm trying not to bring other people in unless they just want to, but that way, Joël's there, and it makes for a quicker review. So that's one nice benefit of the buddy system is because there's at least one person that has enough context where it's not as big of a hurdle for them. And they don't have to ask as many questions and then get caught up to speed before reviewing your changes.

+ +

There's another area that Brian identified as struggling to identify important work but missing stories. I'm intrigued by that one because I'm trying to think of where a team is working on a project, but because you've got so many small projects, you may have forgotten about a particular task that needs to get done, or maybe you need to collaborate with another team, and that's something that slipped through the cracks. I don't think I have a great solution for that one, except with time and experience, you'll start to identify some of those areas where have we thought through, like the different teams and communications and the different services that we may need to integrate with?

+ +

And then I also think it's fine, like, if you've got someone working on a project, it shouldn't be so thoroughly scoped upfront that there's not room for discovery. So if you have one or two people on that project and they're like, hey, actually, I need to create a ticket for this, I think that feels totally reasonable that that's part of that discovery process.

+ +

CHRIS: Yeah, I think I share that take, or I guess a different way to say it is I don't feel the pain of stuff falling through. But that's because we have kind of a continuous process of as we're working on things, we're like, oh, didn't think of X. And then it's very much a part of our process to throw a ticket into the inbox. And our product manager will then triage that and decide relatively where it goes. But everyone is empowered to do that, everyone that's working on the product, such that we have no expectation of being able to fully scope things out in advance.

+ +

And thus the idea of missing a ticket...if it gets to a user and like we forgot to build a critical feature, then, well, that would be sad, but that tends to not happen because just the nature of the process is we're in there. And the idea of the fog of war, like, you can't know until you know. You got to go out there in the forest, and then the fog starts to clear. And then you can see, oh, there's a goldmine there. I'm going to stop with my analogy now.

+ +

But more generally, this is just sort of agile in my mind. I'm a big fan of limiting the specificity the further out a project plan is. So right now, we're working on the concrete implementation of a thing. Cool, that's real. Let's have detailed tickets that describe as much as necessary to actually do the work. And then like a little further out the projects, let's talk about the feature level. What's the screen that we want to build but not necessarily all of the nitty-gritty details?

+ +

And then, further than that, the roadmap, I want to get away from either implementation or feature level and go to benefits. What's the user going to be able to do as a result of this? And user can be a little bit abstract where your customers are developers right now on the team. You're trying to empower them. So it's like CI needs to be faster. And so that's the benefit that we're trying to get to. And then the features are what we want to do — splitting into queues, and then the actual implementation is integrate Knapsack Pro and whatnot.

+ +

And the closer the work is to actually being something that you're tackling, the more specificity I think is useful. But very purposefully, I will avoid specificity for things that are more than a month or two out just to be like, can those just be bullet items on a list that kind of talk about how happy a user will be when we do it but not actually constrain ourselves to a particular feature or implementation? Because we're going to figure some stuff out and it's going to change.

+ +

And also, it's so much easier, like the idea of the team not being able to picture all of the different moving pieces of work. If your roadmap is simple in a couple of bullet items, then it's much easier for everyone to be like, yeah, I kind of know all the stuff that we're going to be doing, that we think we'll be doing in six months. Could change turns out, but that's a thing that I'm a big fan of is limiting the specificity further out.

+ +

And I've worked on many projects where like, no, no, we absolutely need to know down to the day how long this roadmap will take that we think is about a year. And it's like, that's not real. That's not a real thing. Stuff's going to change. I assure you.

+ +

STEPH: I love that. The further out that you get, you focus more on benefits versus implementation. I think that hits home for so many reasons and helps address a number of the concerns that Brian brought up.

+ +

I did think of one more strategy that I've seen that I've also enjoyed is where if you do have an interested party who is like, hey, I've got, I don't know, maybe you've got a customer that's really mad about something, and there's a bug fix. And so this person in customer support really wants to be able to know exactly how this bug is going. Invite them to your daily sync. Let them attend, and they can come, and they'll know who's working on it. They can get a daily update as to how things are going. I think that's a really nice addition.

+ +

There's also the idea that if you are collaborating closely with another team and so your work is very important to theirs or vice versa, also have one person from their team join your daily sync or vice versa. But then that way, you have that communication. And that way, you can check in with each other, and you're at least aware of that high-level context in terms of like, oh, we're waiting on this team for designs or for a new server or something, things like that. Then they can provide an update, or you can provide an update to them.

+ +

CHRIS: I probably shouldn't be surprised, but we had a surprising amount to say about that question. [laughs] It's really in our wheelhouse, the sort of stuff that we like to dig into. How do we do the work? You know, that's the question here on The Bike Shed. But I think with all of those notes, Brian, I hope that helps with what you're doing. And yeah, what do you think, Steph? Should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph and Chris share some big news about the future of The Bike Shed.

+ +

Steph shares an update about integrating with Knapsack Pro. Chris is excited for larger projects that will begin in the next few weeks. They answer a listener's question on keeping backlogs connected to the product vision.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Linear
+RailsConf 2022 YouTube Playlist

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: We don't need Skype anymore. We live in a post-Skype world, audio flapjacks.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So let's see, recently, Utah, who's my dog for anyone that's not familiar, Utah had his very first beach trip. So we went down to Myrtle Beach area in South Carolina. And he had a grand old time because he's a water baby. Like, if there's water, he is in it. He loves it. So I was confident that he was going to like the beach, but I wasn't sure what he was going to think of the waves.

+ +

And luckily, there's an inlet area so that he could splash around and not be too worried about waves and had a wonderful time. He did take a huge gulp of saltwater because he's not used to that, and that threw him for a loop for a while. [chuckles] But overall, it was a lot of fun. He had a wonderful first time at the beach.

+ +

CHRIS: A live raptor on the beach. For continuity for anyone listening, I tend to call Utah Raptor because there are things called Utahraptors, and I can't call things by their normal name. It's just an affliction I have. But yeah, a raptor on the beach.

+ +

STEPH: He has a couple of nicknames going for him. There's someone else in my family that always refers to him as Tank; I think because they remind him of another dog named Tank. So yeah, he's got all the nicknames.

+ +

In some more tech-related news, I'm super excited that the Rails conference talks are now public. There are a number of talks that I'm interested in watching. And there's just such a killer lineup of topics and presenters, including a number of thoughtboters that presented this year. There are also several talks that focus on testing legacy code, which, as you know, is very relevant to my life right now. So I'm particularly interested in those talks. And frankly, I'm running out of doomsday movies to watch. So it's really good timing that I have these talks to help with my evenings where I need something to watch.

+ +

CHRIS: Now you say you're running out of doomsday movies, but have you watched Armageddon?

+ +

STEPH: [chuckles] No, it is on the list. So I have not completely run out. I have a very good one to still watch.

+ +

CHRIS: I'm not even that big a fan of the movie. It's just now a part of my public persona, apparently, and so I got to hold that line. But I didn't realize the RailsConf talks were out. That is super exciting. I will definitely have to check through those and pick out a few at a minimum, watching all of the wonderful talks by thoughtbot folks. So yeah, that's very exciting.

+ +

STEPH: Yeah, I'll be sure to include a link in the show notes so that way it's easy for folks to find and watch along. You and I also have some big news to share with everyone. As most listeners know, I've been prepping for maternity leave. And as part of that preparation, you and I have discussed ways to handle that period where I'm away and focused on being a new mom for six months.

+ +

We talked through a couple of ideas, and ultimately, you and I came to the conclusion that the timing feels right to end our season as host of The Bike Shed and transition the show to a new host, so a passing of the torch or a passing of the handlebars if you will. So even though you and I are leaving the show, The Bike Shed will continue to exist, and you and I will be here for the next couple of episodes. And the show will continue to be the wonderful show that it is today. And we'll share some more details about that in a future episode.

+ +

So while it's really exciting that someone new is going to take over the show, I think I can speak for both of us when I say that this definitely wasn't an easy decision. I know that I've really enjoyed this part of my life where we show up and share our development adventures. Although, to be honest, it's really all the nonsense; that's what I'm here for. That's been my favorite part, like our poor attempts to use sports analogies and renting goats to mow the grass. And I particularly love when you lean into segments about what grinds your gears. There's something about a spirited Chris Toomey "You know what grinds my gears?" rant [laughs] That really brings me a lot of joy.

+ +

CHRIS: Oh, well, that feels like it's too kind of a thing for you to say. And, well, this is already an emotional topic now. I'm feeling the feels. But yes, this has been such a joy to record the show with you. And again, we'll be here for a couple more episodes just to sort of segue over and provide some continuity. But yeah, it is, I think, the right time. We've both done this for a good bit of time now. I think we've said a lot of the things that we have to say.

+ +

I appreciate both the consistency in what we've had to say and also the way things have changed and the new elements that have come in and out. But yeah, I am excited for the next host, and we will introduce you to them in the very near future, dear listeners. At a minimum, and we'll get another chance to say this, but, Steph, it's been a real pleasure recording this podcast with you.

+ +

STEPH: Thank you. It has been a real pleasure. And I'm with you, this is hard to do, and it's hard to announce. But like you said, we'll have some more episodes, and then we will also have more of a finale episode where we can dig into all the feelings. But keeping some of those feelings at bay for now just because we will still have a couple more episodes to chat and then another episode where we can really dig into all of those feelings and then also reflect on our time as host of the show.

+ +

But returning to a technical note, I have an update I can share that's related to some of the testing work that Joël and I are doing. Specifically, we started integrating with a service called Knapsack Pro, which is a service that helps you parallelize your test suite across CI nodes to then speed up your test suite. And ultimately, what we really want to use are Knapsack Pro's cue mode and automatic splitting of large test files to help us then distribute those files across all of the available nodes. And we're still working on setting that up. So I don't have any cool or sparkly stats to share just yet.

+ +

But I have noticed some other wonderful features about Knapsack, specifically some of the reporting structure that they have. So a lot of this data Joël and I were collecting manually. So we were having to go through and figure out, okay, how long are test files taking? Which files are running on which process? Where do we have, like a tentpole, a particular file that's taking a lot longer than other files to run? And with the Knapsack UI, they're just telling us all of that data where they're showing us how long do the test files take? Which process is completing first versus completing last?

+ +

They also show what's the time span between the finished times of the CI node that started first versus the one that finished last? So we can see like, are we balancing well across all of these nodes or workers? So there's been already a lot of really good stuff that I've been seeing from Knapsack Pro that I'm really excited about. And we'll just have to see what comes next with the queue, what kind of time improvements that we can also see by taking this approach.

+ +

CHRIS: Oh, that's cool. I didn't realize you had started working with Knapsack Pro. That's definitely on my short list of things to consider, particularly as our test suite grows. Actually, on a quasi-related note, we this week had another developer who had been off for a couple of months in the summer; they just came back this week. And so we're sort of at full capacity.

+ +

And I've also been writing a couple of PRs this week. It's been exciting. I actually still remember how to code, which is cool; glad that that's still in there. I'm actually operating as point dev this week, which means that I am the support for our admin team wherever they need changes to customer accounts or things like that happening in the background. I'm also triaging all the bugs and things that are coming in, so there are a bunch of little PRs that I pushed through.

+ +

But interestingly, I've just not really looked at or optimized our CircleCI plan. But we keep going over our budget. And then it turns out that their pricing is structured in probably a reasonable way where we buy a plan that is this many build minutes for a month or this many build points or whatever it is, and we keep going over. And each of the overage charges are actually kind of expensive. And we're now doing it on a weekly basis which is I should probably rethink some stuff, figure out a more optimum strategy there. But there's a certain pride of like, oh yeah, look at us. We're burning through CI, really making a lot of PRs happen.

+ +

But I do remember there was a particular week where one of the developers was on vacation; somebody else was elsewhere. And so, our throughput on engineering dropped significantly. And we got this email from CircleCI. It was an automated email, but it was like they were negging us and they were like, "Hey, do you need some help unsticking your CI pipeline? Looks like your build minutes have dropped way down."

+ +

And I was like, whoa, CircleCI, I do not like the vibe that you're putting out there. So now there's this perverse pleasure in like yeah, that's right. We keep going over our limits, and then you charge us a bunch. But actually, I think you're winning in all of these cases, never mind [laughs] I'm just losing. But yeah, it was a fun sequence of emails from CircleCI.

+ +

STEPH: [laughs] That's one of those are you okay? Kind of emails that you get from a service. [laughs] That is fascinating. And yes, I think they're winning because they have then encouraged you to keep it up in terms of like the spend. You made me just think of one of the nice features that we've also noticed with or not so much a feature, but it is a process that they have with when you start your free trial with Knapsack to then integrate and see what the results look like.

+ +

I believe it's 14 days that they give you. But those 14 days only count for build time. So it's not just like from the day that you sign up to now you've got 14 days or business days; it is specifically allocated to the days that you're actually running builds. So I don't think they break it down in terms of hours worth of 14 days.

+ +

But it's like, hey, did you run a build today? Then we'll calculate that. Which has been nice because then there have been some side adventures that we've been interested in, and we've been allowed to pursue those side adventures because we know we can pause on Knapsack for just a little bit, but we're not going to lose that day as part of our free trial.

+ +

Their customer support has also been really nice where they've already...because Joël has been chatting with them with a couple of questions, and they've been very nice with like, hey, we know there are some issues that you're working through in terms of getting the cue mode up and running. So if you do need a couple of extra days, let us know. I wonder if Knapsack Pro will be cool with me sharing that inside baseball, but [laughs] their customer service has been very helpful and nice in that regard.

+ +

CHRIS: I feel like there's such a subtle art to structuring a free trial and particularly the thing you're describing of the way they pace it out. And like, we don't really count it if you're not using it, which makes a lot of sense. There have been so many free trials that I've tried in my life. But like, I started the free trial, and then I forgot about you for a few days. And then I didn't integrate or use. If we're being honest, my free trial has expired, and I have no idea if I want to use you as a service.

+ +

And I know many platforms will offer to restart your trial or things like that or extend it, or the metered trial days that Knapsack has is an interesting one that I don't think I've heard of before, but I like it as an approach. And I think, frankly, it serves them. They want to give people an actual opportunity to try out the platform and decide if it works for them, and that takes a day or two, it turns out.

+ +

STEPH: Yeah, I agree. Some of the additional information that they've shown us, as I've been talking about, like the niceties that they've included around the build metrics. They also show you your longest-running test files. So they also have an auto-splitting feature that we haven't tweaked correctly just yet, so I'm waiting to see that happen. But even then, just knowing the build metrics, because again, this is information that Joël and I were working on manually to collect from all the stats that we could from RSpec and using parallel_tests.

+ +

But now we can just go to the build metrics, and we can see like, oh, these are our top files that take the longest, and then Knapsack Pro tells us your ideal test time for a file is like this number. So to give a concrete number for us, it'd be like around 6 minutes, and 20 seconds would be our ideal time that each node runs. Now, that's probably going to require splitting some of those files because we have a couple of files that take more like eight, nine minutes. But it's so nice to be able to see that and not have to run scripts that we have crafted together to then be able to identify our slowest test.

+ +

But once we get cue mode working and then also the automatic splitting of files, I'll be sure to keep you updated because I'm hoping we're going to see some sparkly stats in terms of then how the tests are getting distributed and that we'll be able to bring the CI time down at least for this portion; it won't be for the whole build but for running the RSpec suite.

+ +

If we can match that ideal time that we've seen and that Knapsack Pro says that if we balance everything in split files, then the ideal run time is around six or seven minutes. So here's hoping. But that's really what's going on in my world. What's going on in your world?

+ +

CHRIS: My world is, I would say, largely the same as it has been. We've been sort of between large projects for a bit now. We've been taking that time to build out some infrastructure, get some smaller things done, some niceties, enhancement, tweaks, et cetera. But at this point, I would say the storm's brewing. The larger projects that we are planning for, mostly Q3 sort of thing, are all kind of coming to a head right now. And so I'm kind of excited.

+ +

I'm ready. I'm ready for a bigger challenge, something to sink our teeth into and really dive into. So yeah, it's been, I would say, very calm of late in a very positive way but almost maybe too calm. And so I'm ready for, yeah, for different things to try out and some stuff to really dig into and grow the Sagewell platform. But yeah, that's most of what's up in my world.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPH: Well, that's kind of a perfect topic or a jumping-off point for a question that we received recently from a listener that's very focused around when you have a lot of work. And since you've got a lot of work, it sounds like, coming down the pipeline, then how to manage a lot of small projects, and then keep the team in sync with each other. So let me back up and read their question so that way we don't miss any of the good bits.

+ +

But this question comes from Brian, and Brian writes in, "I've got a listener question for y'all. How do you like to or have seen teams keep the vision of the product clear yet connected to the backlog such that tasks don't feel like a disconnected set of work, especially when the team stream count grows?

+ +

To expand on my question, the common situation I've seen is when a team has multiple work streams in flight, so using like a backlog tool like Jira or Trello shows a stream of work, but it's hard to associate the stories and tasks either to the bigger picture of the goals or the system's end state. That has slowed down new teammates' onboarding.

+ +

It's made identifying necessary but missing stories harder earlier on. It's also made reviewing work require more context switching or made it harder for interested parties to track progress. It's also caused tension on teams when individuals have different ideas of the goals and the end state of the work. I can see some obvious options to help but curious what your general and specific experiences and advice might be."

+ +

All right, so speaking of lots of work coming down the pipeline and managing some small projects, Chris, do you have any initial thoughts around lots of big questions here in terms of keeping the backlog connected to the product vision?

+ +

CHRIS: Yeah, I have a bunch of little thoughts that I'm happy to share. But to sort of go bigger picture on this, I think the question that Brian is asking here is one of the hard questions of the work that we do. It's like, how do we keep everybody in sync and understanding the big picture while working on the small individual pieces? Like, that's the hard stuff.

+ +

That's the place where communication problems can happen or where the larger team you have, you start to feel those growing pains, et cetera. So to name it, this is just a hard thing. This is one of those hard things that I don't have any silver bullet by any means. But I do have a couple of things that have worked for me in the past.

+ +

So the first is having some notion within whatever tool that you're working on of the bigger picture of the projects. And so recently, just to use Sagewell as an example, we started on Trello. And when we were using Trello, we had a projects list off to the side. So there's the actual backlog of next-up work. But next to it, we had a projects list that was a little higher level zoomed out, trying to group things into sections.

+ +

Pretty quickly, even with our small team, that became insufficient to actually track these things and try and tie small pieces of work back to the bigger project that they were associated with. So we introduced something called I'm going to say it's Hello Epics is the name of the extension for Trello. But it's very much a grafting on of functionality. It's like a Chrome extension; I want to say that takes advantage of card linking and Trello and tries to make some version of this happen.

+ +

It was okay, but we, again, sort of hit the ceiling of that. We somewhat recently, I'm going to say, a couple of months ago, moved to Linear, and Linear has a more formal idea of projects within certain functional areas. And there are ways that projects sort of span different teams, and individual tasks can associate back to projects. And I would say, for us, it's been just the right amount of structure. I want to have that continuity and the linking between things. But I don't need it to be too fancy.

+ +

There is a Gantt chart view in Linear, and I look at it, and I'm like, wow, those are dates. You made some guesses there, Linear. Good luck, we'll see if it happens; I don't know. But overall, that functionality has been great and sufficient for where we're at. So that's one thing.

+ +

Another thing that comes to mind is trying to keep those scoped. So those projects that I'm talking about this is one of the things that I push on a lot is I want that list to be turning over semi-regularly. So we shouldn't have projects that are just like for the next two years, we're building the admin UI, and that's just this sort of open-ended amorphous, unclear project.

+ +

I like to really push for let's get to some deliverable, some doable line, some perhaps arbitrary MVP definition that we define. But let's make it so that each of these projects is doable such that if something stays in that list for too long, our attention is drawn to that. We don't just become numb to the idea that I don't know, there's a list of projects, but some of them are kind of dead in the water, kind of just hanging around and not quite complete. I want that to be a mechanism for reviewing the work that we have in process.

+ +

And so often, it almost feels somewhat artificial, but we'll break a bigger body of work down into smaller projects. And so there's like V1 of a thing, and then there's V1.2. And we get somewhat cheeky with the names at times. But I found a lot of value in having that sort of idea of let's define a boundary around a portion of this work, give it a name, and decide are we done with that or not? And each week, we get asked that question, particularly around our product planning meeting. And that has been really useful, particularly to make sure that stuff has a broader context that it's connected to.

+ +

The last thing that I'll say that has been super useful is retro because what you're describing, again, is one of the harder things. This is really difficult to get right. It's going to be different in each team at different team sizes, at different complexities of product and platform that you're building. You're going to feel this in different ways. And so retro, by far, is the most effective tool I know of to ensure that you are naming and responding to the pain points that you have in your own workflows.

+ +

There's no one size fits all for this sort of thing. But if you have a process that regularly has you come up for air, take a look at what you're doing and decide is this going well or is this not well? Are we missing critical features? Are developers lacking context? Is it hard to move people between teams or whatever the pain point may be? Then you can try and focus in and actually find solutions specific to that.

+ +

But again, I can't answer it for you. All I can say is like, by far, retro is the most effective thing I've ever seen for trying to answer that question. So yeah, a couple of thoughts. I don't know. What do you think, Steph?

+ +

STEPH: I think this is one of those rare moments that you hear someone in a leadership position express that they want high turnover; that is something that they're shooting for.

+ +

CHRIS: Turnover projects, not people. I like people.

+ +

STEPH: [laughs] I know.

+ +

CHRIS: People are moral. People are great. As you said it, I was like, wait, what did I say? Oh, right. No, I didn't. Okay, I got it now.

+ +

STEPH: [laughs] I left out that important word, high turnover of projects and tickets, yes. [laughs] It amused me as I was thinking about it as you mentioned that it's nice to have that consistent turnover in terms of like, you know that something may have gotten scoped too largely if it's sitting there for a while. Unsurprisingly, all the things that you said are wonderful. I love that you sprinkled retro in there at the end since, as you mentioned, this is hard, and it's going to be hard to get it right. So keep checking in with your team to see where improvements can be made.

+ +

I'm going to share a recommendation that actually starts with a pain point and then kind of walk it through from there. So one of the areas that Brian highlighted about that is that it makes it harder for interested parties to track progress. I really liked that one because I've also felt that pain. One way that I've experienced teams manage it that I wasn't a fan of is where people would just go to developers where they saw someone's name on a ticket, and they would ask for updates.

+ +

And the reason I didn't care for that is because it just felt too isolated. And then it felt like work where someone then had to identify who's working on this and getting an update. And then it felt almost stressful to then have someone checking in with you in that regard to be like, hey, how's this ticket going? And then what's the update on this? Versus having a more formal process of like, this is how we update our work.

+ +

So that sort of like one-off behavior of where then someone who's interested in this has to go find the person that's working on it and then check in with them, I think wasn't great for that person. And then it's also not great for the developer who then needs to switch context and provide a high-level overview of when they think something might be done or how it's going. Because then they need to translate from their developer-focus to then more product-focused.

+ +

A slight improvement on that process was at least to keep it public. So then, if there was someone that was in more of like a sales role or a customer support role, and then they were curious about something, is at least don't make that a private conversation. So instead of messaging that developer directly, at least put it in a channel where then anybody could respond, which is then nice because then other people can see that someone is checking in on this; they're interested in it. If that person's out, maybe someone else can respond on their behalf, but at least at a minimum, keep it public.

+ +

Even better is if you can have just a point person, so this is probably your product manager who then someone that's in sales or customer service can go to and say, "Hey, I'd love an update." And then maybe that product manager turns around and goes to the developer and asks questions, but at least they know who to go to, and so they don't have to find the person to follow up with.

+ +

Another approach that I'm currently experiencing with my team is we do have a number of small projects that are going on within the same team. So there is an important Ruby and Rails upgrade that's going on. There's the normal day-to-day work that needs to get done. And then there's also the CI performance improvement that Joël and I are working on. And this goes back to your point in terms of use all the tools that can then help you promote the work that's getting done.

+ +

So in our case, we've actually built on you can see in one board, but then you can have subsets, or you can have streams inside those boards. So then you can have a board that is titled...board is kind of a fancy term. It's more like a line item on one larger board for a team to use some weird terminology. [laughs] But I can't think of a more correct term for it.

+ +

So there's a line item that focuses on Rails and Ruby upgrade. And then there's a line that focuses on other work that's being done, and then that's RSpec-specific performance improvements. And that has felt very nice because then you section each thing together, and you can focus on one at a time.

+ +

It does expand the context that you have with the work that's going on with that team. And I do have mixed feelings about it because, on one hand, it does make your daily sync longer because then there are people sharing updates or looking for help on things that you frankly don't have a lot of context and that you're not working on. So it can feel a little wasteful to then sit there while they're going through updates for work that you're not part of.

+ +

But then it's also been really nice because then you get that high-level context. So you don't really have to know the details, but you're at least aware of that work that's being done. So then that way, if a question does come up, you have enough context that you can say, "Oh, I know a little bit about that," or "I know who's working on it," or "I know who to follow up with." So I think the time trade-off is worth it. Even if it may feel a little painful some days, I think it's still really nice.

+ +

And then also, if you can look for opportunities to form sub-teams where if there's a group and there's work that you can group together. So maybe if you look at the type of work that's coming downstream, like, if you are working on one portion of the application and you see that another big feature is working on that similar area, then maybe grouping that stuff together to reduce some of the context switching is really nice.

+ +

The buddy system also works really well, and maybe that's pairing, maybe it's not, but it's at least having two people that are working on a larger project. So using that RSpec CI performance improvement as an example, Joël and I both have a lot of context on this. And so that way, one, we always have a buddy, someone to reach out to and talk to. But then for like the CRs or PRs that I'm pushing up, then I usually will tag Joël on those because I know he already has the context.

+ +

So I'm trying not to bring other people in unless they just want to, but that way, Joël's there, and it makes for a quicker review. So that's one nice benefit of the buddy system is because there's at least one person that has enough context where it's not as big of a hurdle for them. And they don't have to ask as many questions and then get caught up to speed before reviewing your changes.

+ +

There's another area that Brian identified as struggling to identify important work but missing stories. I'm intrigued by that one because I'm trying to think of where a team is working on a project, but because you've got so many small projects, you may have forgotten about a particular task that needs to get done, or maybe you need to collaborate with another team, and that's something that slipped through the cracks. I don't think I have a great solution for that one, except with time and experience, you'll start to identify some of those areas where have we thought through, like the different teams and communications and the different services that we may need to integrate with?

+ +

And then I also think it's fine, like, if you've got someone working on a project, it shouldn't be so thoroughly scoped upfront that there's not room for discovery. So if you have one or two people on that project and they're like, hey, actually, I need to create a ticket for this, I think that feels totally reasonable that that's part of that discovery process.

+ +

CHRIS: Yeah, I think I share that take, or I guess a different way to say it is I don't feel the pain of stuff falling through. But that's because we have kind of a continuous process of as we're working on things, we're like, oh, didn't think of X. And then it's very much a part of our process to throw a ticket into the inbox. And our product manager will then triage that and decide relatively where it goes. But everyone is empowered to do that, everyone that's working on the product, such that we have no expectation of being able to fully scope things out in advance.

+ +

And thus the idea of missing a ticket...if it gets to a user and like we forgot to build a critical feature, then, well, that would be sad, but that tends to not happen because just the nature of the process is we're in there. And the idea of the fog of war, like, you can't know until you know. You got to go out there in the forest, and then the fog starts to clear. And then you can see, oh, there's a goldmine there. I'm going to stop with my analogy now.

+ +

But more generally, this is just sort of agile in my mind. I'm a big fan of limiting the specificity the further out a project plan is. So right now, we're working on the concrete implementation of a thing. Cool, that's real. Let's have detailed tickets that describe as much as necessary to actually do the work. And then like a little further out the projects, let's talk about the feature level. What's the screen that we want to build but not necessarily all of the nitty-gritty details?

+ +

And then, further than that, the roadmap, I want to get away from either implementation or feature level and go to benefits. What's the user going to be able to do as a result of this? And user can be a little bit abstract where your customers are developers right now on the team. You're trying to empower them. So it's like CI needs to be faster. And so that's the benefit that we're trying to get to. And then the features are what we want to do — splitting into queues, and then the actual implementation is integrate Knapsack Pro and whatnot.

+ +

And the closer the work is to actually being something that you're tackling, the more specificity I think is useful. But very purposefully, I will avoid specificity for things that are more than a month or two out just to be like, can those just be bullet items on a list that kind of talk about how happy a user will be when we do it but not actually constrain ourselves to a particular feature or implementation? Because we're going to figure some stuff out and it's going to change.

+ +

And also, it's so much easier, like the idea of the team not being able to picture all of the different moving pieces of work. If your roadmap is simple in a couple of bullet items, then it's much easier for everyone to be like, yeah, I kind of know all the stuff that we're going to be doing, that we think we'll be doing in six months. Could change turns out, but that's a thing that I'm a big fan of is limiting the specificity further out.

+ +

And I've worked on many projects where like, no, no, we absolutely need to know down to the day how long this roadmap will take that we think is about a year. And it's like, that's not real. That's not a real thing. Stuff's going to change. I assure you.

+ +

STEPH: I love that. The further out that you get, you focus more on benefits versus implementation. I think that hits home for so many reasons and helps address a number of the concerns that Brian brought up.

+ +

I did think of one more strategy that I've seen that I've also enjoyed is where if you do have an interested party who is like, hey, I've got, I don't know, maybe you've got a customer that's really mad about something, and there's a bug fix. And so this person in customer support really wants to be able to know exactly how this bug is going. Invite them to your daily sync. Let them attend, and they can come, and they'll know who's working on it. They can get a daily update as to how things are going. I think that's a really nice addition.

+ +

There's also the idea that if you are collaborating closely with another team and so your work is very important to theirs or vice versa, also have one person from their team join your daily sync or vice versa. But then that way, you have that communication. And that way, you can check in with each other, and you're at least aware of that high-level context in terms of like, oh, we're waiting on this team for designs or for a new server or something, things like that. Then they can provide an update, or you can provide an update to them.

+ +

CHRIS: I probably shouldn't be surprised, but we had a surprising amount to say about that question. [laughs] It's really in our wheelhouse, the sort of stuff that we like to dig into. How do we do the work? You know, that's the question here on The Bike Shed. But I think with all of those notes, Brian, I hope that helps with what you're doing. And yeah, what do you think, Steph? Should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+OUnS0Bcz + + ]]> + + Chris Toomey + Steph Viccari + + + 347: Tracking Velocity + https://bikeshed.thoughtbot.com/347 + 10fb1ed6-0ff7-4ac8-837d-fad5915ce95b + Tue, 26 Jul 2022 10:45:00 -0400 + thoughtbot + + full + thoughtbot + Chris talks about a small toy app he maintains on the side and working with a project called capybara_table. Steph is getting ready for maternity leave and wonders how you track velocity and know if you're working quickly enough? + +They answer a listener's question about where to get started testing a legacy app. + 38:50 + no + + Chris talks about a small toy app he maintains on the side and working with a project called capybara_table. Steph is getting ready for maternity leave and wonders how you track velocity and know if you're working quickly enough? +They answer a listener's question about where to get started testing a legacy app. +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +jnicklas/capybara_table: (https://github.com/jnicklas/capybara_table) Capybara selectors and matchers for working with HTML tables +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Just gotta hold on. Fly this thing straight to the crash site. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +CHRIS: And I'm Steph Viccari. +STEPH: And together, we're here to share a bit of what we've learned along the way. I love that you rolled with that. [laughs] +CHRIS: No, actually, it was the only thing I could do. I [laughs] was frozen into action is a weird way to describe it, but there we are. +STEPH: I mentioned to you a while back that I've always wanted to do that. Today was the day. It happened. +CHRIS: Today was the day. It wasn't even that long ago that you told me. I feel like you could have waited another week or two. I feel like maybe I was too prepared. But yeah, for anyone listening, you may be surprised to find out that I am not, in fact, Steph Viccari. +STEPH: And they'll be surprised to find out that I actually am Chris Toomey. This is just a solo monologue. And you've done a great job of two voices [laughs] this whole time and been tricking everybody. +CHRIS: It has been a struggle. But I'm glad to now get the proper recognition for the fact that I have actually [laughs] been both sides of this thing the whole time. +STEPH: It's been a very impressive talent in how you've run both sides of the conversation. Well, on that note, [laughs] switching gears just a bit, what's new in your world? +CHRIS: What's new in my world? Answering now as Chris Toomey. Let's see; I got two small updates, one a very positive update, one a less positive update. As is the correct order, I'm going to lead with the less positive thing. So I have a small toy app that I maintain on the side. I used to have a bunch of these little purpose-built singular apps, typically Rails app sort of things where I would play with a new technology, but it was some sort of like, oh, it's a tracker. It's a counter. We talked about breakable toys in the past. These were those, for me, serve different purposes, productivity things, or whatever. +But at some point, I was like, this is too much work, so I consolidated them all. And I kept like, there was a handful of features that I liked, smashed them all together into one Rails app that I maintain. And that's just like my Rails app. It turns out it's useful to be able to program the internet. So I was like, cool, I'll do that for myself. I have this little app that I maintain. +It's got like a journal in it and other things. I think I've talked about the journal in the past. But I don't actually take that good care of it. I haven't added any features in a while. It mostly just does what it's supposed to, but it had...entropy had gotten the better of it. +And so, I had a very small feature that I wanted to add. It was actually just a Rake task that should run in the background on a schedule. And if something is out of order, then it should send me an email. Basically, just an update of like, you need to do something. It seemed like such a simple task. And then, oh goodness, the failure modes that I fell into. +First, I was on Heroku-18. Heroku is currently on their Heroku-22 stack. 18 being the year, so it was like 2018, and then there's a 2020 stack, and then the 2022. That's the current one. So I was two stacks behind, and they were yelling at me about that. So I was like, okay, but whatever. Can I ignore that for a little while? +Turns out no, because I couldn't even get the app to boot locally, something about some gems or some I think Webpacker was broken locally. So I was trying to fix things, finally got that to work. But then I couldn't get it to build on CircleCI because Node needed Python, Python 2 specifically, not Python 3, in order to build Node dependencies, particularly LibSass, I want to say, or node-sass. +So node-sass needed Python 2, which I believe is end of life-d, to build a CSS authoring tool. And I kind of took a step back at that moment, and I was like, what did we do, everybody? What is going on here? And thankfully, I feel like there was more sort of unification of tools and simplification of the build tool space and whatnot. But I patched it, and I fixed some things, then finally I got it working. But then Memcache wasn't working, and I had to de-provision that and reprovision something. +The amount of little...like, each thing that I fixed broke something else. I was like, the only thing I can do at this point is just burn the entire app down and rebuild it. Thankfully, I found a working version of things. But I think at some point, I've got to roll up my sleeves some weekend and do the full Rails, Ruby, everything upgrade, just get back to fresh. But my goodness, it was rough. +STEPH: I feel like this is one of those reasons where we've talked in the past about you want to do something, and you keep putting it off. And it's like, if I had just sat down and done it, I could have knocked it out. Like, oh, it only took me like 5-10 minutes. +But then there's this where you get excited, and then you want to dive in. And then suddenly, you do spend an hour or however long, and you're just focused on trying to get to the point where you can break ground and start building. I think that's the resistance that we're often fighting when we think about, oh, I'm going to keep delaying this because I don't know how long it's going to take. +CHRIS: There's something that I see in certain programming communities, which is sort of a beginner-friendliness or a beginner's mindset or a welcomingness to beginners. I see it, particularly in the Svelte world, where they have a strong focus on being able to pick something up and run with it immediately. The entire tutorial is built as there's the tutorial on the one side, like the text, and then on the right side is an interactive REPL. And you're just playing with the Svelte REPL and poking around. And it's so tangible and immediate. +And they're working on a similar thing now for SvelteKit, which is the meta-framework that does server-side rendering and all the fancy stuff. But I love the idea that that is so core to how the Svelte community works. And I'll be honest that other times, I've looked at it, and I've been like, I don't care as much about the first run experience; I care much more about the long-term maintainability of something. +But it turns out that I think those two are more coupled than I had initially...like, how easy is it for a beginner to get started is closely related to or is, you know, the flip side of how easy is it for me to maintain that over time, to find the documentation, to not have a weird builder that no one else has ever seen. +There's that wonderful XKCD where it's like, what's the saddest thing on the internet? Seeing the question that you have asked by one other person on Stack Overflow and no answers four years ago. It's like, yeah, that's painful. You actually want to be part of the boring, mundane, everybody's getting the same errors, and we have solutions to them. So I really appreciate when frameworks and communities care a lot about both that first run experience but also the maintainability, the error messages, the how okay is it for this system to segfault? Because it turns out segfaults prints some funny characters to your terminal. +And so, like the range from human-friendly error message all the way through to binary character dump, I'm interested in folks that care about that space. But yeah, so that's just a bit of griping. I got through it. I made things work. I appreciate, again, the efforts that people are putting in to make that sad situation that I experienced not as common. +But to highlight something that's really great and wonderful that I've been working with, there is a project called capybaratable. capybaratable is the gem name. And it is just this delightful little set of matchers that you can use within a Capybara, particularly within feature spec. So if you have a table, you can now make an assertion that's like, expect the table to have table row. And then you can basically pass it a hash of the column name and the value, but you can pass it any of the columns that you want. And you can pass it...basically, it reads exactly like the user would read it. +And then, if there's an error, if it actually doesn't find it, if it misses the assertion, it will actually print out a little ASCII table for you, which is so nice. It's like, here's the table row that I saw. It didn't have what you were looking for, friend, sorry about that. And it's just so expressive. It forces accessibility because it basically looks at the semantic structure of a table. And if your table is not properly semantically structured, if you're not using TDs and TRs, and all that kind of stuff, then it will not find it. +And so it's another one of those cases where testing can be a really useful constraint from the usability and accessibility of your application. And so, just in every way, I found this project works so well. Error messages are great. It forces you into a better way of building applications. It is just a wonderful little tool that I found. +STEPH: That's awesome. I've definitely seen other thoughtboters when working in codebases that then they'll add really nice helper methods around that for like checking does this data exist in the table? And so I'm used to seeing that type of approach or taking that type of approach myself. But the ASCII table printout is lovely. That's so...yeah, that's just a nice cherry on top. I will have to lock that one away and use that in the future. +CHRIS: Yeah, really, just such a delightful thing. And again, in contrast to the troubles of my weekend, it was very nice to have this one tool that was just like, oh, here's an error, and it's so easy to follow, and yeah. So it's good that there are good things in the world. But speaking of good things, what's new in your world? I hope good things. And I hope you're not about to be like, everything's terrible. But what's up with you? +[laughter] +STEPH: Everything's on fire. No, I do have some good things. So the good thing is that I'm preparing for...I have maternity leave that's coming up. So I am going to take maternity leave in about four-ish weeks. I know the date, but I'm saying the ish because I don't know when people are listening. [laughs] So I'm taking maternity leave coming up soon. I'm very excited, a little panicked mostly about baby preparedness, because, oh my goodness, it is such an overwhelming world, and what everyone thinks you should or shouldn't have and things that you need to do. +So I've been ramping up heavily in that area. And then also planning for when I'm gone and then what that's going to look like for the team, and for clients, and for making sure I've got work wrapped up nicely. So that's a big project. It's just something that's on my mind, something that I am working through and making plans for. +On the weird side, I ran into something because I'm still in test migration world. That is one of like, this is my mountain. This is my Everest. I am determined to get all of these tests. Thank you to everyone who has listened to me, especially you, listen to me talk about this test migration path I've been on and the journey that it's been. This is the goal that I have in mind that I really want to get done. +CHRIS: I know that when you said, "Especially you," you were talking to me, Chris Toomey. But I want to imagine that every listener out there is just like, aww, you're welcome, Steph. So I'm going to pretend for my own sake that that's what you meant by, especially you. It's especially every one of you out there in the audience. +STEPH: Yes, I love either version. And good point, because you're right, I'm looking at you. So I can say especially you since you've been on this journey with me, but everybody listening has been on this journey with me. So I've got a number of files left that I'm working through. And one of the funky things that I ran into, well, it's really not funky; it was a little bit more of an educational rabbit hole for me because it's something that I hadn't considered. +So migrating over a controller test over from Test::Unit to then RSpec, there are a number of controller tests that issue requests or they call the same controller method multiple times. And at first, I didn't think too much about it. I was like, okay, well, I'm just going to move this over to RSpec, and everything is going to be fine. +But based on the way a lot of the information is getting set around logging in a user and then performing an action, and then trying to log in a different user, and then perform another action that was causing mayhem. Because then the second user was never getting logged in because the first user wasn't getting logged out. And it was causing enough problems that Joël and I both sat back, and we're like, this should really be a request back because that way, we're going through the full Rails routing. We're going through more of the sessions that get set, and then we can emulate that full request and response cycle. +And that was something that I just hadn't, I guess, I hadn't done before. I've never written a controller spec where then I was making multiple calls. And so it took a little while for me to realize, like, oh, yeah, controller specs are really just unit test. And they're not going to emulate, give us the full lifecycle that a request spec does. +And it's something that I've always known, but I've never actually felt that pain point to then push me over to like, hey, move this to a request spec. So that was kind of a nice reminder to go through to be like, this is why we have controller specs. You can unit test a specific action; it is just hitting that controller method. And then, if you want to do something that simulates more of a user flow, then go ahead and move over to the request spec land. +CHRIS: I don't know what the current status is, but am I remembering correctly that the controller specs aren't really a thing anymore and that you're supposed to just use request specs? And then there's features specs. I feel like I'm conflating...there's like controller requests and feature, but feature maybe doesn't...no, system, that's what I'm thinking of. So request specs, I think, are supposed to be the way that you do controller-like things anymore. And the true controller spec unit level thing doesn't exist anymore. It can still be done but isn't recommended or common. Does that sound true to you, or am I making stuff up? +STEPH: No, that sounds true to me. So I think controller specs are something that you can still do and still access. But they are very much at that unit layer focus of a test versus request specs are now more encouraged. Request specs have also been around for a while, but they used to be incredibly slow. +I think it was more around Rails 5 that then they received a big increase in performance. And so that's when RSpec and Rails were like, hey, we've improved request specs. They test more of the framework. So if you're going to test these actions, we recommend going for request specs, but controller specs are still there. I think for smaller things that you may want to test, like perhaps you want to test that an endpoint returns a particular status that shows that you're not authorized or forbidden, something that's very specific, I think I would still reach for a controller spec in that case. +CHRIS: I feel like I have that slight inclination to the unit spec level thing. But I've been caught enough by different things. Like, there was a case where CSRF wasn't working. Like, we made some switch in the application, and suddenly CSRF was broken, and I was like, well, that's bad. And the request spec would have caught it, but the controller spec wouldn't. And there's lots of the middleware stack and all of the before actions. +There is so much hidden complexity in there that I think I'm increasingly of the opinion, although I was definitely resistant to it at first, but like, yeah, maybe just go the request spec route and just like, sure. And they'll be a little more costly, but I think it's worth that trade-off because it's the stuff that you're not thinking about that is probably the stuff that you're going to break. It's not the stuff that you're like, definitely, if true, then do that. Like, that's the easier stuff to get right. But it's the sneaky stuff that you want your tests to tell you when you did something wrong. And that's where they're going to sneak in. +STEPH: I agree. And yeah, by going with the request specs, then you're really leaning into more of an integration test since you are testing more of that request/response lifecycle, and you're not as likely to get caught up on the sneaky stuff that you mentioned. So yeah, overall, it was just one of those nice reminders of I know I use request specs. I know there's a reason that I favor them. But it was one of those like; this is why we lean into request specs. And here's a really good use case of where something had been finagled to work as a controller test but really rightfully lived in more of an integration request spec. +MIDROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half. +So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +STEPH: Changing gears just a bit, I have something that I'd love to chat with you about. It came up while I was having a conversation with another thoughtboter as we were discussing how do you track velocity and know if you're working quickly enough? +So since we often change projects about every six months, there's the question of how do I adapt to this team? Or maybe I'm still newish to thoughtbot or to a team; how do I know that I am producing the amount of work that the client or the team expects of me and then also still balancing that and making sure that I'm working at a sustainable pace? +And I think that's such a wonderful, thoughtful question. And I have some initial thoughts around it as to how someone could track velocity. I also think there are two layers to this; there could be are we looking to track an individual's velocity, or are we looking to track team velocity? I think there are a couple of different ways to look at this question. But I'm curious, what are your thoughts around tracking velocity? +CHRIS: Ooh, interesting. I have never found a formal method that worked in this space, no metric, no analysis, no tool, no technique that really could boil this down and tell a truth, a useful truth about, quote, unquote, "Velocity." I think the question of individual velocity is really interesting. +There's the case of an individual who joins a team who's mostly working to try and support others on the team, so doing a lot of pairing, doing a lot of other things. And their individual velocity, the actual output of lines of code, let's say, is very low, but they are helping the overall team move faster. And so I think you'll see some of that. +There was an episode a while back where we talked about heuristics of a team that's moving reasonably well. And I threw out the like; I don't know, like a pull request a day sort of thing feels like the only arbitrary number that I feel comfortable throwing out there in the world. And ideally, these pull requests are relatively small, individual deployable things. But any other version of it, like, are we thinking lines of code? That doesn't make sense. Is it tickets? Well, it depends on how you size your tickets. +And I think it's really hard. And I think it does boil down to it's sort of a feeling. Do we feel like we're moving at a comfortable clip? Do I feel like I'm roughly keeping pace with the rest of the team, especially given seniority and who's been on the team longer? And all of those sorts of things. So I think it's incredibly difficult to ask about an individual. +I have, I think, some more pointed thoughts around as a team how we would think about it and communicate about velocity. But I'm interested what came to mind for you when you thought about it, particularly for the individual side or for the team if you want to go in that direction. +STEPH: Yeah, most of my initial thoughts were more around the individual because I think that's where this person was coming from because they were more interested in, like, how do I know that I'm producing as much as the team would expect of me? But I think there's also the really interesting element of tracking a team's velocity as well. +For the individual, I think it depends a lot on that particular team and their goals and what pace they're moving at. So when I do join a new team, I will look around to see, okay, well, what's the cadence? What's the standard bar for when someone picks up a ticket and then is able to push it through? How much cruft are we working with in the codebase? +Because then that will change the team's expectations of yes, we know that we have a lot of legacy code that we're working with, and so it does take us longer to get through things. And that is totally fine because we are looking more to optimize our sustainability and improving the code as we go versus just trying to get new features in. +I think there's also an important cultural aspect. So some teams may, unfortunately, work a lot of extra hours. And that's something that I won't bend for. I'm still going to stick to my sustainable hours. But that's something that I keep in mind that just if some other people are working a lot of evenings or just working extra hours to keep that in mind that if they do have a higher velocity to not include that in my calculation as heavily. +I also really liked how you highlighted that certain individuals often their velocity is unblocking others. So it's less about the specific code or features or tickets that they're producing, but it's how many people can they help? And then they're increasing the velocity of those individuals. +And then the other metrics that unfortunately can be gamified, but it's still something to look at is like, how many hours are you spending on a particular feature, the tickets? But I like that phrasing that you used earlier of what's your progress? So if someone comes to daily sync and they mention that they're working on the same thing and we're on like day three, or four, but they haven't given an update around, like, oh, I have this new thing that I'm focused on, or this new area that I'm exploring, that's when I'll start to have alarm bells go off. +And I'm like, okay, you've been working on the same thing. I can't quite tell if you've made progress. It sounds like you're still in the depths of the original thing that you were on a couple of days ago. So at that point, I'm going to want to check in to see how you're doing. +But yeah, I think that's why this question fascinates me so much is because I don't think there's one answer that fits for everybody. There's not a way to tell one person to say, "Hey, this is your output that you should be producing, and this applies to all teams." It's really going to vary from team to team as to what that looks like. +I remember there was one team that I joined that initially; I panicked because I noticed that their team was moving at a slower rate in terms of the number of tickets and PRs and stuff that were getting pushed up, reviewed, and then merged. That was moving at a slower pace than I was used to with previous clients. And I just thought, oh, what's going on? What's slowing us down? Like, why aren't we moving faster? +And I actually realized it's just because they were working at a really sustainable pace. They showed up to the office. This was back in the day when I used to go to an office, and people showed up at like 9:00 a.m. and then 5:00 o'clock; it was a ghost town, and people were gone. So they were doing really solid, great work, but they were sticking to very sustainable hours. +Versus, a previous team that I had been on had more of like a rushed feeling, and so there was more output for it. And that was a really nice reset for me to watch this team and see them do such great work in a sustainable fashion and be like, oh, yeah, not everything has to be a fire, not everything has to be rushed. +I think the biggest thing that I'd look at is if velocity is being called into question, so if someone is concerned that someone's not producing enough or if the team is not producing enough, the first place I'm going to look is what's our priorities and see are we prioritizing correctly? Or are people getting pulled into a lot of work that's not supporting the priorities, and then that's why suddenly it feels like we're not producing at the level that we need to? +I feel like that's the common disconnect between how much work we're getting done versus then what's actually causing people or product managers, or management stress. And so reevaluating to make sure that they're on the same page is where I would look first before then thinking, oh, someone's not working hard enough. +CHRIS: Yeah, I definitely resonate with all of that. That was a mini masterclass that you just gave right there in all of those different facets. The one other thing that comes to mind for me is the question is often about velocity or speed or how fast can we go. But I increasingly am of the opinion that it's less about the actual speed. So it's less about like, if you think about it in terms of the average pace, the average number of features that we're going through, I'm more interested in the standard deviation. +So some days you pick up a ticket, and it takes you a day; some days you pick up a ticket, and suddenly, seven days later, you're still working on it. And both at the individual level and at the team level, I'm really interested in decreasing that standard deviation and making it so that we are more consistently delivering whatever amount of output it is but very consistently doing that. And that really helps with our ability to estimate overall bodies of work with our ability for others to know and for us to be able to sort of uphold expectations. +Versus if randomly someone might pick up a piece of code or might pick up a ticket that happens to hit a landmine in the code, it's like, yeah, we've been meaning to refactor that for a while. And it turns out that thing that you thought would be super easy is really hard because we've been kicking the can on this refactoring of the fundamental data model. Sorry about that. But today's your day; you lose. +Those are the sort of things that I see can be really problematic. And then similarly, on an individual side, maybe there's some stuff that you can work on that is super easy for you. But then there's other stuff that you kind of hit a wall. And I think the dangerous mode to get into is just going internal and not really communicating about that, and struggling and trying to get there on your own rather than asking for help. And it can be very difficult to ask for help in those sorts of situations. +But ideally, if you're focusing on I want to be delivering in that same pace, you probably might need some help in that situation. And I think having a team that really...what you're talking about of like, if I notice someone saying the same thing at daily sync for a couple of days in a row, I will typically reach out in a very friendly, collegial way, hey, do you want someone else to take a look at that with you? Because ideally, we want to unblock those situations. +And then if we do have a team that is pretty consistently delivering whatever overall velocity but it's very consistent at that velocity, it's not like 3 one day and then 0, and then 12, and then 2; it's more of like, 6,5,6,5 sort of thing, to pick random numbers out of the air, then I feel so much more able to grow that, to increase that. +If the question comes to me of like, hey, we're looking at the budget for the next quarter; do we think we want to hire another developer? I think I can answer that much more accurately at that point and say what do I think that additional individual would be able to do on the team. Versus if development is kind of this sporadic thing all over the place, then it's so much harder to understand what someone new joining that team would be able to do. +So it's really the slow is smooth, smooth is fast adage that I've talked about in the past that really captured my mind a while back that just continues to feel true to me. And then yeah, I can work with that so much better than occasional days of wild productivity and then weeks of sadness in the swamp of refactoring. So it's a different way to think about the question, but it is where my mind initially went when I read this question. +STEPH: I'm going to start using that description for when I'm refactoring. I'm in the refactoring swamp. That's where I'm spending my time. [laughs] Talking about this particular question is helping me realize that I do think less in terms of like what is my output in the strict terms of tickets, and PRs, and things like that. But I do think more about my progress and how can I constantly show progress, not just to the world but show it to myself. +So if there are tickets that then maybe the ticket was scoped too big at first and I've definitely made some really solid progress, maybe I'm able to ship something or at least identified some other work that could be broken out, then I'm going to do that. Because then I want everybody to know, like, hey, this is the progress that was made here. And I may even be able to make myself feel good and move something over to the done column. So there's that aspect of the work that I focus on more heavily. +And I feel like that also gives us more opportunities to then iterate on what's the goal? Like, we're not looking to just churn out work. That's not the point. But we really want to focus on meaningful work to get done. So if we're constantly giving an update on this as the progress that I've made in this direction, that gives people more opportunities to then respond to that progress and say, "Oh, actually, I think the work was supposed to do this," or "I have questions about some of the things that you've uncovered." So it's less about just getting something done. But it's still about making sure that we're working on the right thing. +CHRIS: Yeah, it doesn't matter how fast we're going if we're going in the wrong direction, so another critical aspect. You can be that person on the team who actually doesn't ship much code at all. Just make sure that we don't ship the wrong code, and you will be a critical member of that team. +But shifting gears just a little bit, we have another listener question here that I'd love to get into. This one is about testing a legacy app. So reading this question, it starts off with a very nice note to us, Steph. "I want to start by saying thanks for putting out great content week after week." We are very happy to do so." So a question for you two. I just took over a legacy Rails app. It's about 12 years old, and it's a bit of a mess. There was some testing in place, but it was completely broken and hadn't been touched in over seven years. So I decided to just delete it all. +My question is, where do I even start with testing? There are so many callbacks on the models and so many controller hooks that I feel like I somehow need to have a factory for every model in our repo. I need to get testing in place ASAP because that is how I develop. But we are also still on Ruby 2 and Rails 4.0. So we desperately have to upgrade. Thanks in advance for any advice." So Steph, I actually replied in an email to this kind listener who sent this. And so, I definitely have some thoughts, but I'm interested in where would you start with this. +STEPH: Legacy code, I wouldn't know anything about working in legacy code. [laughs] This is a fabulous question. And yeah, the response that you provided is incredible. So I'm very excited for you to share the message that you replied with. So I'm going to try not to steal any of those because they're wonderful. +But to add to that list that is soon to come, often where I start with applications like these where I need some testing in place because, as this person mentioned, that's how they work. And then also, at that point, you're just scared to ship anything because you just don't know what's going to break. So one area that you could start with is what's your rollback strategy? So if you don't have any tests in place and you send something out into the world, then what's your plan to then be able to either roll back to a safe point or perhaps it's using feature flags for anything new that you're adding so that way you can quickly turn something on and off. +But having a strategy there, I think, will help alleviate some of that stress of I need to immediately add tests. It's like, yes, that's wonderful, but that's going to take time. So until you can actually write those tests, then let's figure out a plan to mitigate some of that pain. So that's where I would initially start. +And then, as for adding the test, typically, you start with testing as you go. So I would add tests for the code that I'm adding that I'm working on because that's where I'm going to have the most context. And I'm going to start very high. So I might have really slow tests that test everything that is going to be feature level, integration level specs because I'm at the point that I'm just trying to document the most crucial user flows. And then once I have some of those in place, then even if they are slow, at least I'm like, okay, I know that the most crucial user flows are protected and are still working with this change that I'm making. +And in a recent episode, we were talking about how to get to know a Rails app. You highlighted a really good way to get to know those crucial user flows or the most common user flows by using something like New Relic and then seeing what are the paths that people are using. Maybe there's a product manager or just someone that you're taking the app over that could also give you some help in letting you know what's the most crucial features that users are relying on day to day and then prioritizing writing tests for those particular flows. +So then, at this point, you've got a rollback strategy. And then you've also highlighted what are your most crucial user flows, and then you've added some really high level probably slow tests. Something that I've also done in the past and seen others do at thoughtbot when working on a legacy project or just working on a project, it wasn't even legacy, but it just didn't have any test coverage because the team that had built it before hadn't added test coverage. We would often duplicate a lot of the tests as well. +So you would have some integration tests that, yes, frankly, were very similar to others, which felt like a bad choice. But there was just some slight variation where a user-provided some different input or clicked on some small different field or something else happened. But we found that it was better to have that duplication in the test coverage with those small variations versus spending too much time in finessing those tests. Because then we could always go back and start to improve those tests as we went. +So it really depends. Are you in fire mode, and maybe you need to duplicate some stuff? Or are you in a state where you can be more considerate with your tests, and you don't need to just get something in place right away? Those are some of the initial thoughts I have. I'm very excited for the thoughts that you're about to share. So I'm going to turn it over to you. +CHRIS: It's sneaky in this case. You have advanced notice of what I'm about to say. But yeah, this is a super interesting topic and one of those scary places to find yourself in. Very similar to you, the first thing that I recommended was feature specs, starting at that very high level, particularly as the listener wrote in and saying there are a lot of model callbacks and controller callbacks. +And before filters and all of this, it's very indirect how this application works. And so, really, it's only when the whole thing is integrated together that you're going to have a reasonable sense of what's going on. And so trying to write those high-level feature specs, having a handful of them that give you some confidence when you're deploying that those core workflows are still working as expected. +Beyond that, the other things that I talked about one was observability. As an aside, I didn't mention feature flags or anything like that. And I really loved that that was something you highlighted as a different way to get to confidence, so both feature flags and rollbacks. Testing at the end of the day, the goal is to have confidence that we're deploying software that works, and a different way to get that is feature flags and rollbacks. So I really love that you highlighted that. +Something that goes really well hand in hand with those is observability. This has been a thing that I've been exploring more and more and just having some tooling that at runtime will tell you if your application is behaving as expected or is not. So these can be APM-type tools, but it can also be things like Sentry or Honeybadger error monitoring, those sorts of things. +And in a system like this, I wouldn't be surprised if maybe there was an existing error monitoring tool, but it had just kind of decayed over time and now just has perhaps thousands of different entries in it that have been ignored and whatnot. On more than one occasion, I've declared Sentry bankruptcy working with clients and just saying like, listen; this thing can't tell us any truths anymore. So let's burn it down and restart it. +So I would recommend that and having that as a tool such that much as tests are really wonderful before the code gets out there into the wild; it turns out it's only when users start using it that the real stuff happens. And so, having observability, having tooling in place that will tell you when something breaks is equally critical in my mind. +One of the other things I said, and this is probably the spiciest take on my list, is questioning the trade-off space that you're in. Is this an application that actually has a relatively low defect rate that users use and are quite happy with, and expect that level of performance and correctness, and all of those sorts of things, and so you, frankly, need to be careful with it? Or, is it potentially something that has a handful of bugs and that users are used to a certain lower fidelity experience, let's call it? And can you take advantage of that if that happens to be true? +Like, I would be very careful to break something that has never been broken before that there's no expectation of that. But if we can get away with moving fast and breaking things for a little while just to try and get ourselves out of the spot that we're in, I would at least want to consider that trade-off space. Because caution slows you down, it means that your progress is going to be limited. +And so, if we're able to reduce the caution filter just a little bit and move a little bit more rapidly, then ideally, we can get out of this place that we're in a little more quickly. Again, I think that's a really subtle one and one that you'd have to get buy-in from product managers and probably be very explicit in the conversations and sort of that trade-off space. But it is something that I would want to explore if I found myself in this sort of situation. +The last thing that I highlighted was the fact that the versions of Ruby and Rails that were listed in the question are, I think, both end of life at this point. And so from a security perspective, that is just a giant glaring warning sign in the corner because the day that your app gets hacked, well, that's a bad day. +So testing, unfortunately, I think that's the main way that you're going to get by on that as you're going through upgrades. You can deploy a new version of the application and see what happens and see if your observability can get you there. But really, testing is what you want to do. So that's where building out that testing is all the more critical so that you can perform those security upgrades because they are now truly critical to get done. +And so it gives sort of more than a nice to have, more than this makes me feel comfortable. It is pretty much a necessity if you want to go through that, and you absolutely need to go through the security upgrades because otherwise, you're going to get hacked. There are just automated scanners out there. They're going to find you. You don't need to be a high vulnerability target to get taken down on the internet these days. So if it hasn't happened yet, it's going to. And I think that's an easy business case to sell is, I guess, the way that I would frame it. So those were some of my thoughts. +STEPH: You bring up a really good point about needing to focus on the security upgrades. And I'm thinking that through a little bit further in regards to what trade-offs would I make? Would I wait till I have tests in place to then start the upgrades, or would I start the upgrades now but just know I'm going to spend more time manual testing on staging? Or maybe I'm solo on the project. +If I have a product manager or someone else that can also help the testing with me, I think I would go for that latter approach where I would start the upgrades today and then just do more manual testing of those crucial flows and then have that rollback strategy. And as you mentioned, it's a trade-off in terms of, like, how important is it that we don't break anything? +CHRIS: I think similar to the thing that both of us hit on early on is like, have some feature specs that just kick the whole application as one connected piece of code. Have that in place for the security upgrade, testing. But I agree, I wouldn't want to hold off on that because I think that's probably the scariest part of all of this. But yeah, it is, again, trade-offs. As always, it depends. But I think those are my thoughts. Anything else you want to add, Steph? +STEPH: I think those are fabulous thoughts. I think you covered it all. +CHRIS: Sounds good. Well, in that case, should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris talks about a small toy app he maintains on the side and working with a project called capybara_table. Steph is getting ready for maternity leave and wonders how you track velocity and know if you're working quickly enough?

+ +

They answer a listener's question about where to get started testing a legacy app.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

jnicklas/capybara_table: Capybara selectors and matchers for working with HTML tables

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Just gotta hold on. Fly this thing straight to the crash site.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

CHRIS: And I'm Steph Viccari.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. I love that you rolled with that. [laughs]

+ +

CHRIS: No, actually, it was the only thing I could do. I [laughs] was frozen into action is a weird way to describe it, but there we are.

+ +

STEPH: I mentioned to you a while back that I've always wanted to do that. Today was the day. It happened.

+ +

CHRIS: Today was the day. It wasn't even that long ago that you told me. I feel like you could have waited another week or two. I feel like maybe I was too prepared. But yeah, for anyone listening, you may be surprised to find out that I am not, in fact, Steph Viccari.

+ +

STEPH: And they'll be surprised to find out that I actually am Chris Toomey. This is just a solo monologue. And you've done a great job of two voices [laughs] this whole time and been tricking everybody.

+ +

CHRIS: It has been a struggle. But I'm glad to now get the proper recognition for the fact that I have actually [laughs] been both sides of this thing the whole time.

+ +

STEPH: It's been a very impressive talent in how you've run both sides of the conversation. Well, on that note, [laughs] switching gears just a bit, what's new in your world?

+ +

CHRIS: What's new in my world? Answering now as Chris Toomey. Let's see; I got two small updates, one a very positive update, one a less positive update. As is the correct order, I'm going to lead with the less positive thing. So I have a small toy app that I maintain on the side. I used to have a bunch of these little purpose-built singular apps, typically Rails app sort of things where I would play with a new technology, but it was some sort of like, oh, it's a tracker. It's a counter. We talked about breakable toys in the past. These were those, for me, serve different purposes, productivity things, or whatever.

+ +

But at some point, I was like, this is too much work, so I consolidated them all. And I kept like, there was a handful of features that I liked, smashed them all together into one Rails app that I maintain. And that's just like my Rails app. It turns out it's useful to be able to program the internet. So I was like, cool, I'll do that for myself. I have this little app that I maintain.

+ +

It's got like a journal in it and other things. I think I've talked about the journal in the past. But I don't actually take that good care of it. I haven't added any features in a while. It mostly just does what it's supposed to, but it had...entropy had gotten the better of it.

+ +

And so, I had a very small feature that I wanted to add. It was actually just a Rake task that should run in the background on a schedule. And if something is out of order, then it should send me an email. Basically, just an update of like, you need to do something. It seemed like such a simple task. And then, oh goodness, the failure modes that I fell into.

+ +

First, I was on Heroku-18. Heroku is currently on their Heroku-22 stack. 18 being the year, so it was like 2018, and then there's a 2020 stack, and then the 2022. That's the current one. So I was two stacks behind, and they were yelling at me about that. So I was like, okay, but whatever. Can I ignore that for a little while?

+ +

Turns out no, because I couldn't even get the app to boot locally, something about some gems or some I think Webpacker was broken locally. So I was trying to fix things, finally got that to work. But then I couldn't get it to build on CircleCI because Node needed Python, Python 2 specifically, not Python 3, in order to build Node dependencies, particularly LibSass, I want to say, or node-sass.

+ +

So node-sass needed Python 2, which I believe is end of life-d, to build a CSS authoring tool. And I kind of took a step back at that moment, and I was like, what did we do, everybody? What is going on here? And thankfully, I feel like there was more sort of unification of tools and simplification of the build tool space and whatnot. But I patched it, and I fixed some things, then finally I got it working. But then Memcache wasn't working, and I had to de-provision that and reprovision something.

+ +

The amount of little...like, each thing that I fixed broke something else. I was like, the only thing I can do at this point is just burn the entire app down and rebuild it. Thankfully, I found a working version of things. But I think at some point, I've got to roll up my sleeves some weekend and do the full Rails, Ruby, everything upgrade, just get back to fresh. But my goodness, it was rough.

+ +

STEPH: I feel like this is one of those reasons where we've talked in the past about you want to do something, and you keep putting it off. And it's like, if I had just sat down and done it, I could have knocked it out. Like, oh, it only took me like 5-10 minutes.

+ +

But then there's this where you get excited, and then you want to dive in. And then suddenly, you do spend an hour or however long, and you're just focused on trying to get to the point where you can break ground and start building. I think that's the resistance that we're often fighting when we think about, oh, I'm going to keep delaying this because I don't know how long it's going to take.

+ +

CHRIS: There's something that I see in certain programming communities, which is sort of a beginner-friendliness or a beginner's mindset or a welcomingness to beginners. I see it, particularly in the Svelte world, where they have a strong focus on being able to pick something up and run with it immediately. The entire tutorial is built as there's the tutorial on the one side, like the text, and then on the right side is an interactive REPL. And you're just playing with the Svelte REPL and poking around. And it's so tangible and immediate.

+ +

And they're working on a similar thing now for SvelteKit, which is the meta-framework that does server-side rendering and all the fancy stuff. But I love the idea that that is so core to how the Svelte community works. And I'll be honest that other times, I've looked at it, and I've been like, I don't care as much about the first run experience; I care much more about the long-term maintainability of something.

+ +

But it turns out that I think those two are more coupled than I had initially...like, how easy is it for a beginner to get started is closely related to or is, you know, the flip side of how easy is it for me to maintain that over time, to find the documentation, to not have a weird builder that no one else has ever seen.

+ +

There's that wonderful XKCD where it's like, what's the saddest thing on the internet? Seeing the question that you have asked by one other person on Stack Overflow and no answers four years ago. It's like, yeah, that's painful. You actually want to be part of the boring, mundane, everybody's getting the same errors, and we have solutions to them. So I really appreciate when frameworks and communities care a lot about both that first run experience but also the maintainability, the error messages, the how okay is it for this system to segfault? Because it turns out segfaults prints some funny characters to your terminal.

+ +

And so, like the range from human-friendly error message all the way through to binary character dump, I'm interested in folks that care about that space. But yeah, so that's just a bit of griping. I got through it. I made things work. I appreciate, again, the efforts that people are putting in to make that sad situation that I experienced not as common.

+ +

But to highlight something that's really great and wonderful that I've been working with, there is a project called capybara_table. capybara_table is the gem name. And it is just this delightful little set of matchers that you can use within a Capybara, particularly within feature spec. So if you have a table, you can now make an assertion that's like, expect the table to have table row. And then you can basically pass it a hash of the column name and the value, but you can pass it any of the columns that you want. And you can pass it...basically, it reads exactly like the user would read it.

+ +

And then, if there's an error, if it actually doesn't find it, if it misses the assertion, it will actually print out a little ASCII table for you, which is so nice. It's like, here's the table row that I saw. It didn't have what you were looking for, friend, sorry about that. And it's just so expressive. It forces accessibility because it basically looks at the semantic structure of a table. And if your table is not properly semantically structured, if you're not using TDs and TRs, and all that kind of stuff, then it will not find it.

+ +

And so it's another one of those cases where testing can be a really useful constraint from the usability and accessibility of your application. And so, just in every way, I found this project works so well. Error messages are great. It forces you into a better way of building applications. It is just a wonderful little tool that I found.

+ +

STEPH: That's awesome. I've definitely seen other thoughtboters when working in codebases that then they'll add really nice helper methods around that for like checking does this data exist in the table? And so I'm used to seeing that type of approach or taking that type of approach myself. But the ASCII table printout is lovely. That's so...yeah, that's just a nice cherry on top. I will have to lock that one away and use that in the future.

+ +

CHRIS: Yeah, really, just such a delightful thing. And again, in contrast to the troubles of my weekend, it was very nice to have this one tool that was just like, oh, here's an error, and it's so easy to follow, and yeah. So it's good that there are good things in the world. But speaking of good things, what's new in your world? I hope good things. And I hope you're not about to be like, everything's terrible. But what's up with you?

+ +

[laughter]

+ +

STEPH: Everything's on fire. No, I do have some good things. So the good thing is that I'm preparing for...I have maternity leave that's coming up. So I am going to take maternity leave in about four-ish weeks. I know the date, but I'm saying the ish because I don't know when people are listening. [laughs] So I'm taking maternity leave coming up soon. I'm very excited, a little panicked mostly about baby preparedness, because, oh my goodness, it is such an overwhelming world, and what everyone thinks you should or shouldn't have and things that you need to do.

+ +

So I've been ramping up heavily in that area. And then also planning for when I'm gone and then what that's going to look like for the team, and for clients, and for making sure I've got work wrapped up nicely. So that's a big project. It's just something that's on my mind, something that I am working through and making plans for.

+ +

On the weird side, I ran into something because I'm still in test migration world. That is one of like, this is my mountain. This is my Everest. I am determined to get all of these tests. Thank you to everyone who has listened to me, especially you, listen to me talk about this test migration path I've been on and the journey that it's been. This is the goal that I have in mind that I really want to get done.

+ +

CHRIS: I know that when you said, "Especially you," you were talking to me, Chris Toomey. But I want to imagine that every listener out there is just like, aww, you're welcome, Steph. So I'm going to pretend for my own sake that that's what you meant by, especially you. It's especially every one of you out there in the audience.

+ +

STEPH: Yes, I love either version. And good point, because you're right, I'm looking at you. So I can say especially you since you've been on this journey with me, but everybody listening has been on this journey with me. So I've got a number of files left that I'm working through. And one of the funky things that I ran into, well, it's really not funky; it was a little bit more of an educational rabbit hole for me because it's something that I hadn't considered.

+ +

So migrating over a controller test over from Test::Unit to then RSpec, there are a number of controller tests that issue requests or they call the same controller method multiple times. And at first, I didn't think too much about it. I was like, okay, well, I'm just going to move this over to RSpec, and everything is going to be fine.

+ +

But based on the way a lot of the information is getting set around logging in a user and then performing an action, and then trying to log in a different user, and then perform another action that was causing mayhem. Because then the second user was never getting logged in because the first user wasn't getting logged out. And it was causing enough problems that Joël and I both sat back, and we're like, this should really be a request back because that way, we're going through the full Rails routing. We're going through more of the sessions that get set, and then we can emulate that full request and response cycle.

+ +

And that was something that I just hadn't, I guess, I hadn't done before. I've never written a controller spec where then I was making multiple calls. And so it took a little while for me to realize, like, oh, yeah, controller specs are really just unit test. And they're not going to emulate, give us the full lifecycle that a request spec does.

+ +

And it's something that I've always known, but I've never actually felt that pain point to then push me over to like, hey, move this to a request spec. So that was kind of a nice reminder to go through to be like, this is why we have controller specs. You can unit test a specific action; it is just hitting that controller method. And then, if you want to do something that simulates more of a user flow, then go ahead and move over to the request spec land.

+ +

CHRIS: I don't know what the current status is, but am I remembering correctly that the controller specs aren't really a thing anymore and that you're supposed to just use request specs? And then there's features specs. I feel like I'm conflating...there's like controller requests and feature, but feature maybe doesn't...no, system, that's what I'm thinking of. So request specs, I think, are supposed to be the way that you do controller-like things anymore. And the true controller spec unit level thing doesn't exist anymore. It can still be done but isn't recommended or common. Does that sound true to you, or am I making stuff up?

+ +

STEPH: No, that sounds true to me. So I think controller specs are something that you can still do and still access. But they are very much at that unit layer focus of a test versus request specs are now more encouraged. Request specs have also been around for a while, but they used to be incredibly slow.

+ +

I think it was more around Rails 5 that then they received a big increase in performance. And so that's when RSpec and Rails were like, hey, we've improved request specs. They test more of the framework. So if you're going to test these actions, we recommend going for request specs, but controller specs are still there. I think for smaller things that you may want to test, like perhaps you want to test that an endpoint returns a particular status that shows that you're not authorized or forbidden, something that's very specific, I think I would still reach for a controller spec in that case.

+ +

CHRIS: I feel like I have that slight inclination to the unit spec level thing. But I've been caught enough by different things. Like, there was a case where CSRF wasn't working. Like, we made some switch in the application, and suddenly CSRF was broken, and I was like, well, that's bad. And the request spec would have caught it, but the controller spec wouldn't. And there's lots of the middleware stack and all of the before actions.

+ +

There is so much hidden complexity in there that I think I'm increasingly of the opinion, although I was definitely resistant to it at first, but like, yeah, maybe just go the request spec route and just like, sure. And they'll be a little more costly, but I think it's worth that trade-off because it's the stuff that you're not thinking about that is probably the stuff that you're going to break. It's not the stuff that you're like, definitely, if true, then do that. Like, that's the easier stuff to get right. But it's the sneaky stuff that you want your tests to tell you when you did something wrong. And that's where they're going to sneak in.

+ +

STEPH: I agree. And yeah, by going with the request specs, then you're really leaning into more of an integration test since you are testing more of that request/response lifecycle, and you're not as likely to get caught up on the sneaky stuff that you mentioned. So yeah, overall, it was just one of those nice reminders of I know I use request specs. I know there's a reason that I favor them. But it was one of those like; this is why we lean into request specs. And here's a really good use case of where something had been finagled to work as a controller test but really rightfully lived in more of an integration request spec.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPH: Changing gears just a bit, I have something that I'd love to chat with you about. It came up while I was having a conversation with another thoughtboter as we were discussing how do you track velocity and know if you're working quickly enough?

+ +

So since we often change projects about every six months, there's the question of how do I adapt to this team? Or maybe I'm still newish to thoughtbot or to a team; how do I know that I am producing the amount of work that the client or the team expects of me and then also still balancing that and making sure that I'm working at a sustainable pace?

+ +

And I think that's such a wonderful, thoughtful question. And I have some initial thoughts around it as to how someone could track velocity. I also think there are two layers to this; there could be are we looking to track an individual's velocity, or are we looking to track team velocity? I think there are a couple of different ways to look at this question. But I'm curious, what are your thoughts around tracking velocity?

+ +

CHRIS: Ooh, interesting. I have never found a formal method that worked in this space, no metric, no analysis, no tool, no technique that really could boil this down and tell a truth, a useful truth about, quote, unquote, "Velocity." I think the question of individual velocity is really interesting.

+ +

There's the case of an individual who joins a team who's mostly working to try and support others on the team, so doing a lot of pairing, doing a lot of other things. And their individual velocity, the actual output of lines of code, let's say, is very low, but they are helping the overall team move faster. And so I think you'll see some of that.

+ +

There was an episode a while back where we talked about heuristics of a team that's moving reasonably well. And I threw out the like; I don't know, like a pull request a day sort of thing feels like the only arbitrary number that I feel comfortable throwing out there in the world. And ideally, these pull requests are relatively small, individual deployable things. But any other version of it, like, are we thinking lines of code? That doesn't make sense. Is it tickets? Well, it depends on how you size your tickets.

+ +

And I think it's really hard. And I think it does boil down to it's sort of a feeling. Do we feel like we're moving at a comfortable clip? Do I feel like I'm roughly keeping pace with the rest of the team, especially given seniority and who's been on the team longer? And all of those sorts of things. So I think it's incredibly difficult to ask about an individual.

+ +

I have, I think, some more pointed thoughts around as a team how we would think about it and communicate about velocity. But I'm interested what came to mind for you when you thought about it, particularly for the individual side or for the team if you want to go in that direction.

+ +

STEPH: Yeah, most of my initial thoughts were more around the individual because I think that's where this person was coming from because they were more interested in, like, how do I know that I'm producing as much as the team would expect of me? But I think there's also the really interesting element of tracking a team's velocity as well.

+ +

For the individual, I think it depends a lot on that particular team and their goals and what pace they're moving at. So when I do join a new team, I will look around to see, okay, well, what's the cadence? What's the standard bar for when someone picks up a ticket and then is able to push it through? How much cruft are we working with in the codebase?

+ +

Because then that will change the team's expectations of yes, we know that we have a lot of legacy code that we're working with, and so it does take us longer to get through things. And that is totally fine because we are looking more to optimize our sustainability and improving the code as we go versus just trying to get new features in.

+ +

I think there's also an important cultural aspect. So some teams may, unfortunately, work a lot of extra hours. And that's something that I won't bend for. I'm still going to stick to my sustainable hours. But that's something that I keep in mind that just if some other people are working a lot of evenings or just working extra hours to keep that in mind that if they do have a higher velocity to not include that in my calculation as heavily.

+ +

I also really liked how you highlighted that certain individuals often their velocity is unblocking others. So it's less about the specific code or features or tickets that they're producing, but it's how many people can they help? And then they're increasing the velocity of those individuals.

+ +

And then the other metrics that unfortunately can be gamified, but it's still something to look at is like, how many hours are you spending on a particular feature, the tickets? But I like that phrasing that you used earlier of what's your progress? So if someone comes to daily sync and they mention that they're working on the same thing and we're on like day three, or four, but they haven't given an update around, like, oh, I have this new thing that I'm focused on, or this new area that I'm exploring, that's when I'll start to have alarm bells go off.

+ +

And I'm like, okay, you've been working on the same thing. I can't quite tell if you've made progress. It sounds like you're still in the depths of the original thing that you were on a couple of days ago. So at that point, I'm going to want to check in to see how you're doing.

+ +

But yeah, I think that's why this question fascinates me so much is because I don't think there's one answer that fits for everybody. There's not a way to tell one person to say, "Hey, this is your output that you should be producing, and this applies to all teams." It's really going to vary from team to team as to what that looks like.

+ +

I remember there was one team that I joined that initially; I panicked because I noticed that their team was moving at a slower rate in terms of the number of tickets and PRs and stuff that were getting pushed up, reviewed, and then merged. That was moving at a slower pace than I was used to with previous clients. And I just thought, oh, what's going on? What's slowing us down? Like, why aren't we moving faster?

+ +

And I actually realized it's just because they were working at a really sustainable pace. They showed up to the office. This was back in the day when I used to go to an office, and people showed up at like 9:00 a.m. and then 5:00 o'clock; it was a ghost town, and people were gone. So they were doing really solid, great work, but they were sticking to very sustainable hours.

+ +

Versus, a previous team that I had been on had more of like a rushed feeling, and so there was more output for it. And that was a really nice reset for me to watch this team and see them do such great work in a sustainable fashion and be like, oh, yeah, not everything has to be a fire, not everything has to be rushed.

+ +

I think the biggest thing that I'd look at is if velocity is being called into question, so if someone is concerned that someone's not producing enough or if the team is not producing enough, the first place I'm going to look is what's our priorities and see are we prioritizing correctly? Or are people getting pulled into a lot of work that's not supporting the priorities, and then that's why suddenly it feels like we're not producing at the level that we need to?

+ +

I feel like that's the common disconnect between how much work we're getting done versus then what's actually causing people or product managers, or management stress. And so reevaluating to make sure that they're on the same page is where I would look first before then thinking, oh, someone's not working hard enough.

+ +

CHRIS: Yeah, I definitely resonate with all of that. That was a mini masterclass that you just gave right there in all of those different facets. The one other thing that comes to mind for me is the question is often about velocity or speed or how fast can we go. But I increasingly am of the opinion that it's less about the actual speed. So it's less about like, if you think about it in terms of the average pace, the average number of features that we're going through, I'm more interested in the standard deviation.

+ +

So some days you pick up a ticket, and it takes you a day; some days you pick up a ticket, and suddenly, seven days later, you're still working on it. And both at the individual level and at the team level, I'm really interested in decreasing that standard deviation and making it so that we are more consistently delivering whatever amount of output it is but very consistently doing that. And that really helps with our ability to estimate overall bodies of work with our ability for others to know and for us to be able to sort of uphold expectations.

+ +

Versus if randomly someone might pick up a piece of code or might pick up a ticket that happens to hit a landmine in the code, it's like, yeah, we've been meaning to refactor that for a while. And it turns out that thing that you thought would be super easy is really hard because we've been kicking the can on this refactoring of the fundamental data model. Sorry about that. But today's your day; you lose.

+ +

Those are the sort of things that I see can be really problematic. And then similarly, on an individual side, maybe there's some stuff that you can work on that is super easy for you. But then there's other stuff that you kind of hit a wall. And I think the dangerous mode to get into is just going internal and not really communicating about that, and struggling and trying to get there on your own rather than asking for help. And it can be very difficult to ask for help in those sorts of situations.

+ +

But ideally, if you're focusing on I want to be delivering in that same pace, you probably might need some help in that situation. And I think having a team that really...what you're talking about of like, if I notice someone saying the same thing at daily sync for a couple of days in a row, I will typically reach out in a very friendly, collegial way, hey, do you want someone else to take a look at that with you? Because ideally, we want to unblock those situations.

+ +

And then if we do have a team that is pretty consistently delivering whatever overall velocity but it's very consistent at that velocity, it's not like 3 one day and then 0, and then 12, and then 2; it's more of like, 6,5,6,5 sort of thing, to pick random numbers out of the air, then I feel so much more able to grow that, to increase that.

+ +

If the question comes to me of like, hey, we're looking at the budget for the next quarter; do we think we want to hire another developer? I think I can answer that much more accurately at that point and say what do I think that additional individual would be able to do on the team. Versus if development is kind of this sporadic thing all over the place, then it's so much harder to understand what someone new joining that team would be able to do.

+ +

So it's really the slow is smooth, smooth is fast adage that I've talked about in the past that really captured my mind a while back that just continues to feel true to me. And then yeah, I can work with that so much better than occasional days of wild productivity and then weeks of sadness in the swamp of refactoring. So it's a different way to think about the question, but it is where my mind initially went when I read this question.

+ +

STEPH: I'm going to start using that description for when I'm refactoring. I'm in the refactoring swamp. That's where I'm spending my time. [laughs] Talking about this particular question is helping me realize that I do think less in terms of like what is my output in the strict terms of tickets, and PRs, and things like that. But I do think more about my progress and how can I constantly show progress, not just to the world but show it to myself.

+ +

So if there are tickets that then maybe the ticket was scoped too big at first and I've definitely made some really solid progress, maybe I'm able to ship something or at least identified some other work that could be broken out, then I'm going to do that. Because then I want everybody to know, like, hey, this is the progress that was made here. And I may even be able to make myself feel good and move something over to the done column. So there's that aspect of the work that I focus on more heavily.

+ +

And I feel like that also gives us more opportunities to then iterate on what's the goal? Like, we're not looking to just churn out work. That's not the point. But we really want to focus on meaningful work to get done. So if we're constantly giving an update on this as the progress that I've made in this direction, that gives people more opportunities to then respond to that progress and say, "Oh, actually, I think the work was supposed to do this," or "I have questions about some of the things that you've uncovered." So it's less about just getting something done. But it's still about making sure that we're working on the right thing.

+ +

CHRIS: Yeah, it doesn't matter how fast we're going if we're going in the wrong direction, so another critical aspect. You can be that person on the team who actually doesn't ship much code at all. Just make sure that we don't ship the wrong code, and you will be a critical member of that team.

+ +

But shifting gears just a little bit, we have another listener question here that I'd love to get into. This one is about testing a legacy app. So reading this question, it starts off with a very nice note to us, Steph. "I want to start by saying thanks for putting out great content week after week." We are very happy to do so." So a question for you two. I just took over a legacy Rails app. It's about 12 years old, and it's a bit of a mess. There was some testing in place, but it was completely broken and hadn't been touched in over seven years. So I decided to just delete it all.

+ +

My question is, where do I even start with testing? There are so many callbacks on the models and so many controller hooks that I feel like I somehow need to have a factory for every model in our repo. I need to get testing in place ASAP because that is how I develop. But we are also still on Ruby 2 and Rails 4.0. So we desperately have to upgrade. Thanks in advance for any advice." So Steph, I actually replied in an email to this kind listener who sent this. And so, I definitely have some thoughts, but I'm interested in where would you start with this.

+ +

STEPH: Legacy code, I wouldn't know anything about working in legacy code. [laughs] This is a fabulous question. And yeah, the response that you provided is incredible. So I'm very excited for you to share the message that you replied with. So I'm going to try not to steal any of those because they're wonderful.

+ +

But to add to that list that is soon to come, often where I start with applications like these where I need some testing in place because, as this person mentioned, that's how they work. And then also, at that point, you're just scared to ship anything because you just don't know what's going to break. So one area that you could start with is what's your rollback strategy? So if you don't have any tests in place and you send something out into the world, then what's your plan to then be able to either roll back to a safe point or perhaps it's using feature flags for anything new that you're adding so that way you can quickly turn something on and off.

+ +

But having a strategy there, I think, will help alleviate some of that stress of I need to immediately add tests. It's like, yes, that's wonderful, but that's going to take time. So until you can actually write those tests, then let's figure out a plan to mitigate some of that pain. So that's where I would initially start.

+ +

And then, as for adding the test, typically, you start with testing as you go. So I would add tests for the code that I'm adding that I'm working on because that's where I'm going to have the most context. And I'm going to start very high. So I might have really slow tests that test everything that is going to be feature level, integration level specs because I'm at the point that I'm just trying to document the most crucial user flows. And then once I have some of those in place, then even if they are slow, at least I'm like, okay, I know that the most crucial user flows are protected and are still working with this change that I'm making.

+ +

And in a recent episode, we were talking about how to get to know a Rails app. You highlighted a really good way to get to know those crucial user flows or the most common user flows by using something like New Relic and then seeing what are the paths that people are using. Maybe there's a product manager or just someone that you're taking the app over that could also give you some help in letting you know what's the most crucial features that users are relying on day to day and then prioritizing writing tests for those particular flows.

+ +

So then, at this point, you've got a rollback strategy. And then you've also highlighted what are your most crucial user flows, and then you've added some really high level probably slow tests. Something that I've also done in the past and seen others do at thoughtbot when working on a legacy project or just working on a project, it wasn't even legacy, but it just didn't have any test coverage because the team that had built it before hadn't added test coverage. We would often duplicate a lot of the tests as well.

+ +

So you would have some integration tests that, yes, frankly, were very similar to others, which felt like a bad choice. But there was just some slight variation where a user-provided some different input or clicked on some small different field or something else happened. But we found that it was better to have that duplication in the test coverage with those small variations versus spending too much time in finessing those tests. Because then we could always go back and start to improve those tests as we went.

+ +

So it really depends. Are you in fire mode, and maybe you need to duplicate some stuff? Or are you in a state where you can be more considerate with your tests, and you don't need to just get something in place right away? Those are some of the initial thoughts I have. I'm very excited for the thoughts that you're about to share. So I'm going to turn it over to you.

+ +

CHRIS: It's sneaky in this case. You have advanced notice of what I'm about to say. But yeah, this is a super interesting topic and one of those scary places to find yourself in. Very similar to you, the first thing that I recommended was feature specs, starting at that very high level, particularly as the listener wrote in and saying there are a lot of model callbacks and controller callbacks.

+ +

And before filters and all of this, it's very indirect how this application works. And so, really, it's only when the whole thing is integrated together that you're going to have a reasonable sense of what's going on. And so trying to write those high-level feature specs, having a handful of them that give you some confidence when you're deploying that those core workflows are still working as expected.

+ +

Beyond that, the other things that I talked about one was observability. As an aside, I didn't mention feature flags or anything like that. And I really loved that that was something you highlighted as a different way to get to confidence, so both feature flags and rollbacks. Testing at the end of the day, the goal is to have confidence that we're deploying software that works, and a different way to get that is feature flags and rollbacks. So I really love that you highlighted that.

+ +

Something that goes really well hand in hand with those is observability. This has been a thing that I've been exploring more and more and just having some tooling that at runtime will tell you if your application is behaving as expected or is not. So these can be APM-type tools, but it can also be things like Sentry or Honeybadger error monitoring, those sorts of things.

+ +

And in a system like this, I wouldn't be surprised if maybe there was an existing error monitoring tool, but it had just kind of decayed over time and now just has perhaps thousands of different entries in it that have been ignored and whatnot. On more than one occasion, I've declared Sentry bankruptcy working with clients and just saying like, listen; this thing can't tell us any truths anymore. So let's burn it down and restart it.

+ +

So I would recommend that and having that as a tool such that much as tests are really wonderful before the code gets out there into the wild; it turns out it's only when users start using it that the real stuff happens. And so, having observability, having tooling in place that will tell you when something breaks is equally critical in my mind.

+ +

One of the other things I said, and this is probably the spiciest take on my list, is questioning the trade-off space that you're in. Is this an application that actually has a relatively low defect rate that users use and are quite happy with, and expect that level of performance and correctness, and all of those sorts of things, and so you, frankly, need to be careful with it? Or, is it potentially something that has a handful of bugs and that users are used to a certain lower fidelity experience, let's call it? And can you take advantage of that if that happens to be true?

+ +

Like, I would be very careful to break something that has never been broken before that there's no expectation of that. But if we can get away with moving fast and breaking things for a little while just to try and get ourselves out of the spot that we're in, I would at least want to consider that trade-off space. Because caution slows you down, it means that your progress is going to be limited.

+ +

And so, if we're able to reduce the caution filter just a little bit and move a little bit more rapidly, then ideally, we can get out of this place that we're in a little more quickly. Again, I think that's a really subtle one and one that you'd have to get buy-in from product managers and probably be very explicit in the conversations and sort of that trade-off space. But it is something that I would want to explore if I found myself in this sort of situation.

+ +

The last thing that I highlighted was the fact that the versions of Ruby and Rails that were listed in the question are, I think, both end of life at this point. And so from a security perspective, that is just a giant glaring warning sign in the corner because the day that your app gets hacked, well, that's a bad day.

+ +

So testing, unfortunately, I think that's the main way that you're going to get by on that as you're going through upgrades. You can deploy a new version of the application and see what happens and see if your observability can get you there. But really, testing is what you want to do. So that's where building out that testing is all the more critical so that you can perform those security upgrades because they are now truly critical to get done.

+ +

And so it gives sort of more than a nice to have, more than this makes me feel comfortable. It is pretty much a necessity if you want to go through that, and you absolutely need to go through the security upgrades because otherwise, you're going to get hacked. There are just automated scanners out there. They're going to find you. You don't need to be a high vulnerability target to get taken down on the internet these days. So if it hasn't happened yet, it's going to. And I think that's an easy business case to sell is, I guess, the way that I would frame it. So those were some of my thoughts.

+ +

STEPH: You bring up a really good point about needing to focus on the security upgrades. And I'm thinking that through a little bit further in regards to what trade-offs would I make? Would I wait till I have tests in place to then start the upgrades, or would I start the upgrades now but just know I'm going to spend more time manual testing on staging? Or maybe I'm solo on the project.

+ +

If I have a product manager or someone else that can also help the testing with me, I think I would go for that latter approach where I would start the upgrades today and then just do more manual testing of those crucial flows and then have that rollback strategy. And as you mentioned, it's a trade-off in terms of, like, how important is it that we don't break anything?

+ +

CHRIS: I think similar to the thing that both of us hit on early on is like, have some feature specs that just kick the whole application as one connected piece of code. Have that in place for the security upgrade, testing. But I agree, I wouldn't want to hold off on that because I think that's probably the scariest part of all of this. But yeah, it is, again, trade-offs. As always, it depends. But I think those are my thoughts. Anything else you want to add, Steph?

+ +

STEPH: I think those are fabulous thoughts. I think you covered it all.

+ +

CHRIS: Sounds good. Well, in that case, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris talks about a small toy app he maintains on the side and working with a project called capybara_table. Steph is getting ready for maternity leave and wonders how you track velocity and know if you're working quickly enough?

+ +

They answer a listener's question about where to get started testing a legacy app.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

jnicklas/capybara_table: Capybara selectors and matchers for working with HTML tables

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Just gotta hold on. Fly this thing straight to the crash site.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

CHRIS: And I'm Steph Viccari.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. I love that you rolled with that. [laughs]

+ +

CHRIS: No, actually, it was the only thing I could do. I [laughs] was frozen into action is a weird way to describe it, but there we are.

+ +

STEPH: I mentioned to you a while back that I've always wanted to do that. Today was the day. It happened.

+ +

CHRIS: Today was the day. It wasn't even that long ago that you told me. I feel like you could have waited another week or two. I feel like maybe I was too prepared. But yeah, for anyone listening, you may be surprised to find out that I am not, in fact, Steph Viccari.

+ +

STEPH: And they'll be surprised to find out that I actually am Chris Toomey. This is just a solo monologue. And you've done a great job of two voices [laughs] this whole time and been tricking everybody.

+ +

CHRIS: It has been a struggle. But I'm glad to now get the proper recognition for the fact that I have actually [laughs] been both sides of this thing the whole time.

+ +

STEPH: It's been a very impressive talent in how you've run both sides of the conversation. Well, on that note, [laughs] switching gears just a bit, what's new in your world?

+ +

CHRIS: What's new in my world? Answering now as Chris Toomey. Let's see; I got two small updates, one a very positive update, one a less positive update. As is the correct order, I'm going to lead with the less positive thing. So I have a small toy app that I maintain on the side. I used to have a bunch of these little purpose-built singular apps, typically Rails app sort of things where I would play with a new technology, but it was some sort of like, oh, it's a tracker. It's a counter. We talked about breakable toys in the past. These were those, for me, serve different purposes, productivity things, or whatever.

+ +

But at some point, I was like, this is too much work, so I consolidated them all. And I kept like, there was a handful of features that I liked, smashed them all together into one Rails app that I maintain. And that's just like my Rails app. It turns out it's useful to be able to program the internet. So I was like, cool, I'll do that for myself. I have this little app that I maintain.

+ +

It's got like a journal in it and other things. I think I've talked about the journal in the past. But I don't actually take that good care of it. I haven't added any features in a while. It mostly just does what it's supposed to, but it had...entropy had gotten the better of it.

+ +

And so, I had a very small feature that I wanted to add. It was actually just a Rake task that should run in the background on a schedule. And if something is out of order, then it should send me an email. Basically, just an update of like, you need to do something. It seemed like such a simple task. And then, oh goodness, the failure modes that I fell into.

+ +

First, I was on Heroku-18. Heroku is currently on their Heroku-22 stack. 18 being the year, so it was like 2018, and then there's a 2020 stack, and then the 2022. That's the current one. So I was two stacks behind, and they were yelling at me about that. So I was like, okay, but whatever. Can I ignore that for a little while?

+ +

Turns out no, because I couldn't even get the app to boot locally, something about some gems or some I think Webpacker was broken locally. So I was trying to fix things, finally got that to work. But then I couldn't get it to build on CircleCI because Node needed Python, Python 2 specifically, not Python 3, in order to build Node dependencies, particularly LibSass, I want to say, or node-sass.

+ +

So node-sass needed Python 2, which I believe is end of life-d, to build a CSS authoring tool. And I kind of took a step back at that moment, and I was like, what did we do, everybody? What is going on here? And thankfully, I feel like there was more sort of unification of tools and simplification of the build tool space and whatnot. But I patched it, and I fixed some things, then finally I got it working. But then Memcache wasn't working, and I had to de-provision that and reprovision something.

+ +

The amount of little...like, each thing that I fixed broke something else. I was like, the only thing I can do at this point is just burn the entire app down and rebuild it. Thankfully, I found a working version of things. But I think at some point, I've got to roll up my sleeves some weekend and do the full Rails, Ruby, everything upgrade, just get back to fresh. But my goodness, it was rough.

+ +

STEPH: I feel like this is one of those reasons where we've talked in the past about you want to do something, and you keep putting it off. And it's like, if I had just sat down and done it, I could have knocked it out. Like, oh, it only took me like 5-10 minutes.

+ +

But then there's this where you get excited, and then you want to dive in. And then suddenly, you do spend an hour or however long, and you're just focused on trying to get to the point where you can break ground and start building. I think that's the resistance that we're often fighting when we think about, oh, I'm going to keep delaying this because I don't know how long it's going to take.

+ +

CHRIS: There's something that I see in certain programming communities, which is sort of a beginner-friendliness or a beginner's mindset or a welcomingness to beginners. I see it, particularly in the Svelte world, where they have a strong focus on being able to pick something up and run with it immediately. The entire tutorial is built as there's the tutorial on the one side, like the text, and then on the right side is an interactive REPL. And you're just playing with the Svelte REPL and poking around. And it's so tangible and immediate.

+ +

And they're working on a similar thing now for SvelteKit, which is the meta-framework that does server-side rendering and all the fancy stuff. But I love the idea that that is so core to how the Svelte community works. And I'll be honest that other times, I've looked at it, and I've been like, I don't care as much about the first run experience; I care much more about the long-term maintainability of something.

+ +

But it turns out that I think those two are more coupled than I had initially...like, how easy is it for a beginner to get started is closely related to or is, you know, the flip side of how easy is it for me to maintain that over time, to find the documentation, to not have a weird builder that no one else has ever seen.

+ +

There's that wonderful XKCD where it's like, what's the saddest thing on the internet? Seeing the question that you have asked by one other person on Stack Overflow and no answers four years ago. It's like, yeah, that's painful. You actually want to be part of the boring, mundane, everybody's getting the same errors, and we have solutions to them. So I really appreciate when frameworks and communities care a lot about both that first run experience but also the maintainability, the error messages, the how okay is it for this system to segfault? Because it turns out segfaults prints some funny characters to your terminal.

+ +

And so, like the range from human-friendly error message all the way through to binary character dump, I'm interested in folks that care about that space. But yeah, so that's just a bit of griping. I got through it. I made things work. I appreciate, again, the efforts that people are putting in to make that sad situation that I experienced not as common.

+ +

But to highlight something that's really great and wonderful that I've been working with, there is a project called capybara_table. capybara_table is the gem name. And it is just this delightful little set of matchers that you can use within a Capybara, particularly within feature spec. So if you have a table, you can now make an assertion that's like, expect the table to have table row. And then you can basically pass it a hash of the column name and the value, but you can pass it any of the columns that you want. And you can pass it...basically, it reads exactly like the user would read it.

+ +

And then, if there's an error, if it actually doesn't find it, if it misses the assertion, it will actually print out a little ASCII table for you, which is so nice. It's like, here's the table row that I saw. It didn't have what you were looking for, friend, sorry about that. And it's just so expressive. It forces accessibility because it basically looks at the semantic structure of a table. And if your table is not properly semantically structured, if you're not using TDs and TRs, and all that kind of stuff, then it will not find it.

+ +

And so it's another one of those cases where testing can be a really useful constraint from the usability and accessibility of your application. And so, just in every way, I found this project works so well. Error messages are great. It forces you into a better way of building applications. It is just a wonderful little tool that I found.

+ +

STEPH: That's awesome. I've definitely seen other thoughtboters when working in codebases that then they'll add really nice helper methods around that for like checking does this data exist in the table? And so I'm used to seeing that type of approach or taking that type of approach myself. But the ASCII table printout is lovely. That's so...yeah, that's just a nice cherry on top. I will have to lock that one away and use that in the future.

+ +

CHRIS: Yeah, really, just such a delightful thing. And again, in contrast to the troubles of my weekend, it was very nice to have this one tool that was just like, oh, here's an error, and it's so easy to follow, and yeah. So it's good that there are good things in the world. But speaking of good things, what's new in your world? I hope good things. And I hope you're not about to be like, everything's terrible. But what's up with you?

+ +

[laughter]

+ +

STEPH: Everything's on fire. No, I do have some good things. So the good thing is that I'm preparing for...I have maternity leave that's coming up. So I am going to take maternity leave in about four-ish weeks. I know the date, but I'm saying the ish because I don't know when people are listening. [laughs] So I'm taking maternity leave coming up soon. I'm very excited, a little panicked mostly about baby preparedness, because, oh my goodness, it is such an overwhelming world, and what everyone thinks you should or shouldn't have and things that you need to do.

+ +

So I've been ramping up heavily in that area. And then also planning for when I'm gone and then what that's going to look like for the team, and for clients, and for making sure I've got work wrapped up nicely. So that's a big project. It's just something that's on my mind, something that I am working through and making plans for.

+ +

On the weird side, I ran into something because I'm still in test migration world. That is one of like, this is my mountain. This is my Everest. I am determined to get all of these tests. Thank you to everyone who has listened to me, especially you, listen to me talk about this test migration path I've been on and the journey that it's been. This is the goal that I have in mind that I really want to get done.

+ +

CHRIS: I know that when you said, "Especially you," you were talking to me, Chris Toomey. But I want to imagine that every listener out there is just like, aww, you're welcome, Steph. So I'm going to pretend for my own sake that that's what you meant by, especially you. It's especially every one of you out there in the audience.

+ +

STEPH: Yes, I love either version. And good point, because you're right, I'm looking at you. So I can say especially you since you've been on this journey with me, but everybody listening has been on this journey with me. So I've got a number of files left that I'm working through. And one of the funky things that I ran into, well, it's really not funky; it was a little bit more of an educational rabbit hole for me because it's something that I hadn't considered.

+ +

So migrating over a controller test over from Test::Unit to then RSpec, there are a number of controller tests that issue requests or they call the same controller method multiple times. And at first, I didn't think too much about it. I was like, okay, well, I'm just going to move this over to RSpec, and everything is going to be fine.

+ +

But based on the way a lot of the information is getting set around logging in a user and then performing an action, and then trying to log in a different user, and then perform another action that was causing mayhem. Because then the second user was never getting logged in because the first user wasn't getting logged out. And it was causing enough problems that Joël and I both sat back, and we're like, this should really be a request back because that way, we're going through the full Rails routing. We're going through more of the sessions that get set, and then we can emulate that full request and response cycle.

+ +

And that was something that I just hadn't, I guess, I hadn't done before. I've never written a controller spec where then I was making multiple calls. And so it took a little while for me to realize, like, oh, yeah, controller specs are really just unit test. And they're not going to emulate, give us the full lifecycle that a request spec does.

+ +

And it's something that I've always known, but I've never actually felt that pain point to then push me over to like, hey, move this to a request spec. So that was kind of a nice reminder to go through to be like, this is why we have controller specs. You can unit test a specific action; it is just hitting that controller method. And then, if you want to do something that simulates more of a user flow, then go ahead and move over to the request spec land.

+ +

CHRIS: I don't know what the current status is, but am I remembering correctly that the controller specs aren't really a thing anymore and that you're supposed to just use request specs? And then there's features specs. I feel like I'm conflating...there's like controller requests and feature, but feature maybe doesn't...no, system, that's what I'm thinking of. So request specs, I think, are supposed to be the way that you do controller-like things anymore. And the true controller spec unit level thing doesn't exist anymore. It can still be done but isn't recommended or common. Does that sound true to you, or am I making stuff up?

+ +

STEPH: No, that sounds true to me. So I think controller specs are something that you can still do and still access. But they are very much at that unit layer focus of a test versus request specs are now more encouraged. Request specs have also been around for a while, but they used to be incredibly slow.

+ +

I think it was more around Rails 5 that then they received a big increase in performance. And so that's when RSpec and Rails were like, hey, we've improved request specs. They test more of the framework. So if you're going to test these actions, we recommend going for request specs, but controller specs are still there. I think for smaller things that you may want to test, like perhaps you want to test that an endpoint returns a particular status that shows that you're not authorized or forbidden, something that's very specific, I think I would still reach for a controller spec in that case.

+ +

CHRIS: I feel like I have that slight inclination to the unit spec level thing. But I've been caught enough by different things. Like, there was a case where CSRF wasn't working. Like, we made some switch in the application, and suddenly CSRF was broken, and I was like, well, that's bad. And the request spec would have caught it, but the controller spec wouldn't. And there's lots of the middleware stack and all of the before actions.

+ +

There is so much hidden complexity in there that I think I'm increasingly of the opinion, although I was definitely resistant to it at first, but like, yeah, maybe just go the request spec route and just like, sure. And they'll be a little more costly, but I think it's worth that trade-off because it's the stuff that you're not thinking about that is probably the stuff that you're going to break. It's not the stuff that you're like, definitely, if true, then do that. Like, that's the easier stuff to get right. But it's the sneaky stuff that you want your tests to tell you when you did something wrong. And that's where they're going to sneak in.

+ +

STEPH: I agree. And yeah, by going with the request specs, then you're really leaning into more of an integration test since you are testing more of that request/response lifecycle, and you're not as likely to get caught up on the sneaky stuff that you mentioned. So yeah, overall, it was just one of those nice reminders of I know I use request specs. I know there's a reason that I favor them. But it was one of those like; this is why we lean into request specs. And here's a really good use case of where something had been finagled to work as a controller test but really rightfully lived in more of an integration request spec.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

STEPH: Changing gears just a bit, I have something that I'd love to chat with you about. It came up while I was having a conversation with another thoughtboter as we were discussing how do you track velocity and know if you're working quickly enough?

+ +

So since we often change projects about every six months, there's the question of how do I adapt to this team? Or maybe I'm still newish to thoughtbot or to a team; how do I know that I am producing the amount of work that the client or the team expects of me and then also still balancing that and making sure that I'm working at a sustainable pace?

+ +

And I think that's such a wonderful, thoughtful question. And I have some initial thoughts around it as to how someone could track velocity. I also think there are two layers to this; there could be are we looking to track an individual's velocity, or are we looking to track team velocity? I think there are a couple of different ways to look at this question. But I'm curious, what are your thoughts around tracking velocity?

+ +

CHRIS: Ooh, interesting. I have never found a formal method that worked in this space, no metric, no analysis, no tool, no technique that really could boil this down and tell a truth, a useful truth about, quote, unquote, "Velocity." I think the question of individual velocity is really interesting.

+ +

There's the case of an individual who joins a team who's mostly working to try and support others on the team, so doing a lot of pairing, doing a lot of other things. And their individual velocity, the actual output of lines of code, let's say, is very low, but they are helping the overall team move faster. And so I think you'll see some of that.

+ +

There was an episode a while back where we talked about heuristics of a team that's moving reasonably well. And I threw out the like; I don't know, like a pull request a day sort of thing feels like the only arbitrary number that I feel comfortable throwing out there in the world. And ideally, these pull requests are relatively small, individual deployable things. But any other version of it, like, are we thinking lines of code? That doesn't make sense. Is it tickets? Well, it depends on how you size your tickets.

+ +

And I think it's really hard. And I think it does boil down to it's sort of a feeling. Do we feel like we're moving at a comfortable clip? Do I feel like I'm roughly keeping pace with the rest of the team, especially given seniority and who's been on the team longer? And all of those sorts of things. So I think it's incredibly difficult to ask about an individual.

+ +

I have, I think, some more pointed thoughts around as a team how we would think about it and communicate about velocity. But I'm interested what came to mind for you when you thought about it, particularly for the individual side or for the team if you want to go in that direction.

+ +

STEPH: Yeah, most of my initial thoughts were more around the individual because I think that's where this person was coming from because they were more interested in, like, how do I know that I'm producing as much as the team would expect of me? But I think there's also the really interesting element of tracking a team's velocity as well.

+ +

For the individual, I think it depends a lot on that particular team and their goals and what pace they're moving at. So when I do join a new team, I will look around to see, okay, well, what's the cadence? What's the standard bar for when someone picks up a ticket and then is able to push it through? How much cruft are we working with in the codebase?

+ +

Because then that will change the team's expectations of yes, we know that we have a lot of legacy code that we're working with, and so it does take us longer to get through things. And that is totally fine because we are looking more to optimize our sustainability and improving the code as we go versus just trying to get new features in.

+ +

I think there's also an important cultural aspect. So some teams may, unfortunately, work a lot of extra hours. And that's something that I won't bend for. I'm still going to stick to my sustainable hours. But that's something that I keep in mind that just if some other people are working a lot of evenings or just working extra hours to keep that in mind that if they do have a higher velocity to not include that in my calculation as heavily.

+ +

I also really liked how you highlighted that certain individuals often their velocity is unblocking others. So it's less about the specific code or features or tickets that they're producing, but it's how many people can they help? And then they're increasing the velocity of those individuals.

+ +

And then the other metrics that unfortunately can be gamified, but it's still something to look at is like, how many hours are you spending on a particular feature, the tickets? But I like that phrasing that you used earlier of what's your progress? So if someone comes to daily sync and they mention that they're working on the same thing and we're on like day three, or four, but they haven't given an update around, like, oh, I have this new thing that I'm focused on, or this new area that I'm exploring, that's when I'll start to have alarm bells go off.

+ +

And I'm like, okay, you've been working on the same thing. I can't quite tell if you've made progress. It sounds like you're still in the depths of the original thing that you were on a couple of days ago. So at that point, I'm going to want to check in to see how you're doing.

+ +

But yeah, I think that's why this question fascinates me so much is because I don't think there's one answer that fits for everybody. There's not a way to tell one person to say, "Hey, this is your output that you should be producing, and this applies to all teams." It's really going to vary from team to team as to what that looks like.

+ +

I remember there was one team that I joined that initially; I panicked because I noticed that their team was moving at a slower rate in terms of the number of tickets and PRs and stuff that were getting pushed up, reviewed, and then merged. That was moving at a slower pace than I was used to with previous clients. And I just thought, oh, what's going on? What's slowing us down? Like, why aren't we moving faster?

+ +

And I actually realized it's just because they were working at a really sustainable pace. They showed up to the office. This was back in the day when I used to go to an office, and people showed up at like 9:00 a.m. and then 5:00 o'clock; it was a ghost town, and people were gone. So they were doing really solid, great work, but they were sticking to very sustainable hours.

+ +

Versus, a previous team that I had been on had more of like a rushed feeling, and so there was more output for it. And that was a really nice reset for me to watch this team and see them do such great work in a sustainable fashion and be like, oh, yeah, not everything has to be a fire, not everything has to be rushed.

+ +

I think the biggest thing that I'd look at is if velocity is being called into question, so if someone is concerned that someone's not producing enough or if the team is not producing enough, the first place I'm going to look is what's our priorities and see are we prioritizing correctly? Or are people getting pulled into a lot of work that's not supporting the priorities, and then that's why suddenly it feels like we're not producing at the level that we need to?

+ +

I feel like that's the common disconnect between how much work we're getting done versus then what's actually causing people or product managers, or management stress. And so reevaluating to make sure that they're on the same page is where I would look first before then thinking, oh, someone's not working hard enough.

+ +

CHRIS: Yeah, I definitely resonate with all of that. That was a mini masterclass that you just gave right there in all of those different facets. The one other thing that comes to mind for me is the question is often about velocity or speed or how fast can we go. But I increasingly am of the opinion that it's less about the actual speed. So it's less about like, if you think about it in terms of the average pace, the average number of features that we're going through, I'm more interested in the standard deviation.

+ +

So some days you pick up a ticket, and it takes you a day; some days you pick up a ticket, and suddenly, seven days later, you're still working on it. And both at the individual level and at the team level, I'm really interested in decreasing that standard deviation and making it so that we are more consistently delivering whatever amount of output it is but very consistently doing that. And that really helps with our ability to estimate overall bodies of work with our ability for others to know and for us to be able to sort of uphold expectations.

+ +

Versus if randomly someone might pick up a piece of code or might pick up a ticket that happens to hit a landmine in the code, it's like, yeah, we've been meaning to refactor that for a while. And it turns out that thing that you thought would be super easy is really hard because we've been kicking the can on this refactoring of the fundamental data model. Sorry about that. But today's your day; you lose.

+ +

Those are the sort of things that I see can be really problematic. And then similarly, on an individual side, maybe there's some stuff that you can work on that is super easy for you. But then there's other stuff that you kind of hit a wall. And I think the dangerous mode to get into is just going internal and not really communicating about that, and struggling and trying to get there on your own rather than asking for help. And it can be very difficult to ask for help in those sorts of situations.

+ +

But ideally, if you're focusing on I want to be delivering in that same pace, you probably might need some help in that situation. And I think having a team that really...what you're talking about of like, if I notice someone saying the same thing at daily sync for a couple of days in a row, I will typically reach out in a very friendly, collegial way, hey, do you want someone else to take a look at that with you? Because ideally, we want to unblock those situations.

+ +

And then if we do have a team that is pretty consistently delivering whatever overall velocity but it's very consistent at that velocity, it's not like 3 one day and then 0, and then 12, and then 2; it's more of like, 6,5,6,5 sort of thing, to pick random numbers out of the air, then I feel so much more able to grow that, to increase that.

+ +

If the question comes to me of like, hey, we're looking at the budget for the next quarter; do we think we want to hire another developer? I think I can answer that much more accurately at that point and say what do I think that additional individual would be able to do on the team. Versus if development is kind of this sporadic thing all over the place, then it's so much harder to understand what someone new joining that team would be able to do.

+ +

So it's really the slow is smooth, smooth is fast adage that I've talked about in the past that really captured my mind a while back that just continues to feel true to me. And then yeah, I can work with that so much better than occasional days of wild productivity and then weeks of sadness in the swamp of refactoring. So it's a different way to think about the question, but it is where my mind initially went when I read this question.

+ +

STEPH: I'm going to start using that description for when I'm refactoring. I'm in the refactoring swamp. That's where I'm spending my time. [laughs] Talking about this particular question is helping me realize that I do think less in terms of like what is my output in the strict terms of tickets, and PRs, and things like that. But I do think more about my progress and how can I constantly show progress, not just to the world but show it to myself.

+ +

So if there are tickets that then maybe the ticket was scoped too big at first and I've definitely made some really solid progress, maybe I'm able to ship something or at least identified some other work that could be broken out, then I'm going to do that. Because then I want everybody to know, like, hey, this is the progress that was made here. And I may even be able to make myself feel good and move something over to the done column. So there's that aspect of the work that I focus on more heavily.

+ +

And I feel like that also gives us more opportunities to then iterate on what's the goal? Like, we're not looking to just churn out work. That's not the point. But we really want to focus on meaningful work to get done. So if we're constantly giving an update on this as the progress that I've made in this direction, that gives people more opportunities to then respond to that progress and say, "Oh, actually, I think the work was supposed to do this," or "I have questions about some of the things that you've uncovered." So it's less about just getting something done. But it's still about making sure that we're working on the right thing.

+ +

CHRIS: Yeah, it doesn't matter how fast we're going if we're going in the wrong direction, so another critical aspect. You can be that person on the team who actually doesn't ship much code at all. Just make sure that we don't ship the wrong code, and you will be a critical member of that team.

+ +

But shifting gears just a little bit, we have another listener question here that I'd love to get into. This one is about testing a legacy app. So reading this question, it starts off with a very nice note to us, Steph. "I want to start by saying thanks for putting out great content week after week." We are very happy to do so." So a question for you two. I just took over a legacy Rails app. It's about 12 years old, and it's a bit of a mess. There was some testing in place, but it was completely broken and hadn't been touched in over seven years. So I decided to just delete it all.

+ +

My question is, where do I even start with testing? There are so many callbacks on the models and so many controller hooks that I feel like I somehow need to have a factory for every model in our repo. I need to get testing in place ASAP because that is how I develop. But we are also still on Ruby 2 and Rails 4.0. So we desperately have to upgrade. Thanks in advance for any advice." So Steph, I actually replied in an email to this kind listener who sent this. And so, I definitely have some thoughts, but I'm interested in where would you start with this.

+ +

STEPH: Legacy code, I wouldn't know anything about working in legacy code. [laughs] This is a fabulous question. And yeah, the response that you provided is incredible. So I'm very excited for you to share the message that you replied with. So I'm going to try not to steal any of those because they're wonderful.

+ +

But to add to that list that is soon to come, often where I start with applications like these where I need some testing in place because, as this person mentioned, that's how they work. And then also, at that point, you're just scared to ship anything because you just don't know what's going to break. So one area that you could start with is what's your rollback strategy? So if you don't have any tests in place and you send something out into the world, then what's your plan to then be able to either roll back to a safe point or perhaps it's using feature flags for anything new that you're adding so that way you can quickly turn something on and off.

+ +

But having a strategy there, I think, will help alleviate some of that stress of I need to immediately add tests. It's like, yes, that's wonderful, but that's going to take time. So until you can actually write those tests, then let's figure out a plan to mitigate some of that pain. So that's where I would initially start.

+ +

And then, as for adding the test, typically, you start with testing as you go. So I would add tests for the code that I'm adding that I'm working on because that's where I'm going to have the most context. And I'm going to start very high. So I might have really slow tests that test everything that is going to be feature level, integration level specs because I'm at the point that I'm just trying to document the most crucial user flows. And then once I have some of those in place, then even if they are slow, at least I'm like, okay, I know that the most crucial user flows are protected and are still working with this change that I'm making.

+ +

And in a recent episode, we were talking about how to get to know a Rails app. You highlighted a really good way to get to know those crucial user flows or the most common user flows by using something like New Relic and then seeing what are the paths that people are using. Maybe there's a product manager or just someone that you're taking the app over that could also give you some help in letting you know what's the most crucial features that users are relying on day to day and then prioritizing writing tests for those particular flows.

+ +

So then, at this point, you've got a rollback strategy. And then you've also highlighted what are your most crucial user flows, and then you've added some really high level probably slow tests. Something that I've also done in the past and seen others do at thoughtbot when working on a legacy project or just working on a project, it wasn't even legacy, but it just didn't have any test coverage because the team that had built it before hadn't added test coverage. We would often duplicate a lot of the tests as well.

+ +

So you would have some integration tests that, yes, frankly, were very similar to others, which felt like a bad choice. But there was just some slight variation where a user-provided some different input or clicked on some small different field or something else happened. But we found that it was better to have that duplication in the test coverage with those small variations versus spending too much time in finessing those tests. Because then we could always go back and start to improve those tests as we went.

+ +

So it really depends. Are you in fire mode, and maybe you need to duplicate some stuff? Or are you in a state where you can be more considerate with your tests, and you don't need to just get something in place right away? Those are some of the initial thoughts I have. I'm very excited for the thoughts that you're about to share. So I'm going to turn it over to you.

+ +

CHRIS: It's sneaky in this case. You have advanced notice of what I'm about to say. But yeah, this is a super interesting topic and one of those scary places to find yourself in. Very similar to you, the first thing that I recommended was feature specs, starting at that very high level, particularly as the listener wrote in and saying there are a lot of model callbacks and controller callbacks.

+ +

And before filters and all of this, it's very indirect how this application works. And so, really, it's only when the whole thing is integrated together that you're going to have a reasonable sense of what's going on. And so trying to write those high-level feature specs, having a handful of them that give you some confidence when you're deploying that those core workflows are still working as expected.

+ +

Beyond that, the other things that I talked about one was observability. As an aside, I didn't mention feature flags or anything like that. And I really loved that that was something you highlighted as a different way to get to confidence, so both feature flags and rollbacks. Testing at the end of the day, the goal is to have confidence that we're deploying software that works, and a different way to get that is feature flags and rollbacks. So I really love that you highlighted that.

+ +

Something that goes really well hand in hand with those is observability. This has been a thing that I've been exploring more and more and just having some tooling that at runtime will tell you if your application is behaving as expected or is not. So these can be APM-type tools, but it can also be things like Sentry or Honeybadger error monitoring, those sorts of things.

+ +

And in a system like this, I wouldn't be surprised if maybe there was an existing error monitoring tool, but it had just kind of decayed over time and now just has perhaps thousands of different entries in it that have been ignored and whatnot. On more than one occasion, I've declared Sentry bankruptcy working with clients and just saying like, listen; this thing can't tell us any truths anymore. So let's burn it down and restart it.

+ +

So I would recommend that and having that as a tool such that much as tests are really wonderful before the code gets out there into the wild; it turns out it's only when users start using it that the real stuff happens. And so, having observability, having tooling in place that will tell you when something breaks is equally critical in my mind.

+ +

One of the other things I said, and this is probably the spiciest take on my list, is questioning the trade-off space that you're in. Is this an application that actually has a relatively low defect rate that users use and are quite happy with, and expect that level of performance and correctness, and all of those sorts of things, and so you, frankly, need to be careful with it? Or, is it potentially something that has a handful of bugs and that users are used to a certain lower fidelity experience, let's call it? And can you take advantage of that if that happens to be true?

+ +

Like, I would be very careful to break something that has never been broken before that there's no expectation of that. But if we can get away with moving fast and breaking things for a little while just to try and get ourselves out of the spot that we're in, I would at least want to consider that trade-off space. Because caution slows you down, it means that your progress is going to be limited.

+ +

And so, if we're able to reduce the caution filter just a little bit and move a little bit more rapidly, then ideally, we can get out of this place that we're in a little more quickly. Again, I think that's a really subtle one and one that you'd have to get buy-in from product managers and probably be very explicit in the conversations and sort of that trade-off space. But it is something that I would want to explore if I found myself in this sort of situation.

+ +

The last thing that I highlighted was the fact that the versions of Ruby and Rails that were listed in the question are, I think, both end of life at this point. And so from a security perspective, that is just a giant glaring warning sign in the corner because the day that your app gets hacked, well, that's a bad day.

+ +

So testing, unfortunately, I think that's the main way that you're going to get by on that as you're going through upgrades. You can deploy a new version of the application and see what happens and see if your observability can get you there. But really, testing is what you want to do. So that's where building out that testing is all the more critical so that you can perform those security upgrades because they are now truly critical to get done.

+ +

And so it gives sort of more than a nice to have, more than this makes me feel comfortable. It is pretty much a necessity if you want to go through that, and you absolutely need to go through the security upgrades because otherwise, you're going to get hacked. There are just automated scanners out there. They're going to find you. You don't need to be a high vulnerability target to get taken down on the internet these days. So if it hasn't happened yet, it's going to. And I think that's an easy business case to sell is, I guess, the way that I would frame it. So those were some of my thoughts.

+ +

STEPH: You bring up a really good point about needing to focus on the security upgrades. And I'm thinking that through a little bit further in regards to what trade-offs would I make? Would I wait till I have tests in place to then start the upgrades, or would I start the upgrades now but just know I'm going to spend more time manual testing on staging? Or maybe I'm solo on the project.

+ +

If I have a product manager or someone else that can also help the testing with me, I think I would go for that latter approach where I would start the upgrades today and then just do more manual testing of those crucial flows and then have that rollback strategy. And as you mentioned, it's a trade-off in terms of, like, how important is it that we don't break anything?

+ +

CHRIS: I think similar to the thing that both of us hit on early on is like, have some feature specs that just kick the whole application as one connected piece of code. Have that in place for the security upgrade, testing. But I agree, I wouldn't want to hold off on that because I think that's probably the scariest part of all of this. But yeah, it is, again, trade-offs. As always, it depends. But I think those are my thoughts. Anything else you want to add, Steph?

+ +

STEPH: I think those are fabulous thoughts. I think you covered it all.

+ +

CHRIS: Sounds good. Well, in that case, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+VcOGkCVl + + ]]> + + Chris Toomey + Steph Viccari + + + 346: Occasional Biscuits + https://bikeshed.thoughtbot.com/346 + 0a6f9284-1cb7-4ebd-813d-445ee54168ff + Tue, 19 Jul 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Natural disaster movies, anyone? It's what Steph's been into, and Chris has THOUGHTS on the drilling in Armageddon. + +Additionally, a chat around RuboCop RSpec rules happens, and they answer a listener's question, "how do you get acquainted with a new code base?" + 37:13 + no + + + Natural disaster movies, anyone? It's what Steph's been into, and Chris has THOUGHTS on the drilling in Armageddon. +Additionally, a chat around RuboCop RSpec rules happens, and they answer a listener's question, "how do you get acquainted with a new code base?" +This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. +Greenland (https://www.imdb.com/title/tt7737786/) +Geostorm (https://www.imdb.com/title/tt1981128/) +San Andreas (https://www.imdb.com/title/tt2126355/) +Armageddon (https://www.imdb.com/title/tt0120591/) +This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. +Flaky tests slow everyone down, break your flow, and make things downright miserable. +In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start? +BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! +And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. +So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed. +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. So I've been watching more movies lately. So evenings aren't always great; I don't always feel good being around 33 weeks pregnant now. Evenings I can be just kind of exhausted from the day, and I just need to chill and prop my feet up and all that good stuff. And I've been really drawn to natural disaster like end-of-the-world-type movies, and I'm not sure what that says about me. But it's my truth; it's where I'm at. [chuckles] +I watched Greenland recently, which I really enjoyed. I feel like they ended it well. I won't share any spoilers, but I feel like they ended it well. And they didn't take an easy shortcut out that I kind of thought that they might do, so that one was enjoyable. Geostorm, I watched that one just last night. San Andreas, I feel like that's one that I also watched recently. So yeah, that's what's new in my world, you know, your typical natural disaster end-of-the-world flicks. That's my new evening hobby. +CHRIS: I feel like I haven't heard of any of the three that you just listed, which is wild to me because this is a category that I find enthralling. +STEPH: Well, definitely start with Greenland. I feel like that one was the better of the three that I just mentioned. I don't know Geostorm or San Andreas which one you would prefer there. I feel like they're probably on par with each other in terms of like you're there for entertainment. We're not there to judge and be hypercritical of a storyline. You're there purely for the visual effects and for the ride. +CHRIS: Gotcha. Interesting. So quick question then, since this seems like the category you're interested in, Armageddon or Deep Impact? +STEPH: Ooh, I'm going to have to walk through the differences because I always get those mixed up. Armageddon is where they take Bruce Willis up to an asteroid, and they have to drill and drop a nuke, right? +CHRIS: They sure do. +STEPH: [laughs] And then what's Deep Impact about? I guess the fact that I know Armageddon better means I'm favoring that one. I can't place what...how does Deep Impact go? +CHRIS: Deep Impact is just there's an asteroid coming, and it's the story and what the people do. So it's got less...it doesn't have the same pop. I believe Armageddon was a Michael Bay movie. And so it's got that Michael Bay special bit of something on it. But the interesting thing is they came out the same year; I want to say. +It's one of those like Burger King and McDonald's being right next door to each other. It's like, what are you doing there? Why are you...like, asteroid devastation movies two of you at the same time, really? But yeah, Armageddon is the correct answer. Deep Impact is like a fine movie, but Armageddon is like, all right, we're going to have a movie about asteroids. Let's really go for it. Blow it out. Why not? +STEPH: Yeah, I'm with you. Armageddon definitely sticks out in my memory, so I'd vote that one. Also, for your other question that you didn't ask, but you kind of implicitly asked, I'm going to go McDonald's because Burger King fries are trash, and also, McDonald's has better ice cream cones. +CHRIS: Okay, so McDonald's fries. Oh no, I was thinking Wendy's, get a frosty from there, and then you make that combination because the frostys are great. +STEPH: Oh yeah, that's a good combo. +CHRIS: And you need the french fries to go with it, but then it's a third option that I'm introducing. Also, this wasn't a question, but I want to loop back briefly to Armageddon because it's an important piece of cinema. There's a really great...like it's DVD commentary, and it's Ben Affleck talking with Michael Bay about, "Hey, so in the movie, the premise is that the only way to possibly get this done is to train a bunch of oil drillers to be astronauts. Did we consider it all just having some astronauts learn to do oil drilling?" And Michael Bay's response is not safe for radio is how I would describe it. But it's very humorous hearing Ben Affleck describe Michael Bay responding to that. +STEPH: I think they addressed that in the movie, though. They mentioned like, we're going to train them, but they're like, no, drilling is such an art and a science. There's no way. We don't have time to teach these astronauts how to drill. So instead, it's easier to teach them to be astronauts. +CHRIS: Right. That is what they say in the movie. +STEPH: [laughs] Okay. +CHRIS: But just spending a minute teasing that one apart is like, being an astronaut is easy. You just sit in the spaceship, and it goes, boom. [laughs] It's like; actually, there's a little bit more to being an astronaut. Yes, drilling is very subtle science and art fusion. But the idea that being an astronaut [laughs] is just like, just push the go-to space button, then you go to space. +STEPH: The training montage is definitely better if we get to watch people learn how to be astronauts than if we watch people learn how to drill. [laughs] So that might have also played a role. +CHRIS: No question, it is the correct cinematic choice. But whether or not it's the true answer...say we were actually faced with this problem, I don't know that this is exactly how it would play out. +STEPH: I think we should A/B test it. We'll have one group train to be drill experts and one group train to be astronauts, and we'll send them both up. +CHRIS: This is smart. That's the way you got to do it. The one other thing that I'm going to go...you know what really grinds my gears? In the movie Armageddon, they have this robotic vehicle thing, the armadillo; I believe it's called. I know more than I thought I would remember about this movie. [chuckles] Anyway, continuing on, the armadillo, the vehicle that they use to do the drilling, has the drill arm on it that extends out and drills down into the asteroid. And it has gears on the end of it. It has three gears specifically. +And the first gear is intermeshed with the second gear, which is intermeshed with the third gear, which is intermeshed with the first gear, so imagine which direction the first gear is turning, then imagine the second gear turning, then imagine the third gear turning. They can't. It's a physically impossible object. One tries to turn clockwise, and the other one is trying to go counterclockwise, and they're intermeshed. So the whole thing would just cease up. It just doesn't work. +I've looked at it a bunch of times, and I want to just be wrong about this. I want to be like; I don't know what's going on. But I think the gears on the drilling machine just fundamentally at a very simple mechanical level cannot work. And again, if you're going to do it, really go for it, Michael Bay. I kind of like that, and I really hate it at the same time. +STEPH: I have never noticed this. I'm intrigued. You know what? Maybe Armageddon will be the movie of choice tonight. [chuckles] Maybe that's what I'm going to watch. And I'm going to wait for the armadillo to come out so I can evaluate the gears. And I'm highly amused that this is the thing that grinds your gears are the gears on the armadillo. +CHRIS: Yeah. I was a young child at the time, and I remember I actually went to Disney World, and I saw they had the prop vehicle there. And I just kind of looked up at it, and I was like, no, that's not how gears work. I may have been naive and wrong as a child, and now I've just anchored this memory deep within me. +In a similar way, so I had a moment while traveling; actually, that reminded me of something that I said on a recent podcast episode where I was talking about names and pronunciation. And I was like, yeah, sometimes people ask me how to pronounce my name. And I can't imagine any variation. That was the thing I was just wrong about because 'Toomay' is a perfectly reasonable pronunciation of my name that I didn't even think... +I was just so anchored to the one truth that I know in the world that my name is Toomey. And that's the only possible way anyone could pronounce it. Nope, totally wrong. So maybe the gears in Armageddon actually work really, really well, and maybe I'm just wrong. I'm willing to be wrong on the internet, which I believe is the name of the first episode that we recorded with you formally as a co-host. [chuckles] So yeah. +STEPH: Yeah, that sounds true. So you're going to change the intro? It's now going to be like, and I'm Chris 'Toomay'. +CHRIS: I might change it each time I come up with a new subtle pronunciation. We'll see. So far, I've got two that I know of. I can't imagine a third, but I was wrong about one. So maybe I'm wrong about two. +STEPH: It would be fun to see who pays attention. As someone who deeply values pronouncing someone's name correctly, oh my goodness, that would stress me out to hear someone keep pronouncing their name differently. Or I would be like, okay, they're having fun, and they don't mind how it gets pronounced. +I can't remember if we've talked about this on air but early on, I pronounced my last name differently for like one of the first episodes that we recorded. So it's 'Vicceri,' but it could also be 'Viccari'. And I've defaulted at times to saying 'Viccari' because people can spell that. It seems more natural. They understand it's V-I-C-C-A-R-I. But if I say 'Vicceri', then people want to add two Rs, or they want a Y. I don't know why it just seems to have a difference. And so then I was like, nope, I said it wrong. I need to say it right. It's 'Vicceri' even if it's more challenging for people. +And I think Chad Pytel had just walked in at that moment when I was saying that to you that I had said my name differently. And he's like, "You can't do that." And I'm like, "Well, I did it. It's already out there in the world." [laughs] But also, I'm one of those people that's like, Viccari, 'Vicceri' I will accept either. +In a slightly different topic and something that's going on in my world, there was a small win today with a client team that I really appreciated where someone brought up the conversation around the RuboCop RSpec rules and how RuboCop was fussing at them because they had too many lines in their test example. And so they're like, well, they're like, I feel like I'm competing, or I'm working against RuboCop. RuboCop wants me to shorten my test example lines, but yet, I'm not sure what else to do about it. +And someone's like, "Well, you could extract more into before blocks and to lets and to helpers or things like that to then shorten the test. They're like, "But that does also work against readability of the test if you do that." So then there was a nice, short conversation around well, then we really need more flexibility. We shouldn't let the RuboCop metrics drive us in this particular decision when we really want to optimize for readability. +And so then it was a discussion of okay, well, how much flexibility do we add to it? And I was like, "Well, what if we just got rid of it? Because I don't think there's an ideal length for how long your test should be. And I'd rather empower test authors to use all the space that they need to show their test setup and even lean into duplication before they extract things because this codebase has far more dry tests than they do duplication concerns. So I'd rather lean into the duplication at this point." +And the others that happened to be in that conversation were like, "Yep, that sounds good." So then that person issued a PR that then removed the check for that particular; how long are the examples? And it was lovely. It was just like a nice, quick win and a wonderful discussion that someone had brought up. +CHRIS: Ooh, I like that. That sounds like a great conversation that hit on why do we have this? What are the trade-offs? Let's actually remove it. And it’s also nice that you got to that place. I've seen a lot of folks have a lot of opinions in the past in this space. And opinions can be tricky to work around, and just deeply, deeply entrenched opinions is the thing that I find interesting. And I think I'm increasingly in the space of those sort of, thou shalt not type linter rules are not ideal in my mind. I want true correctness checks that really tell some truth about the codebase. +Like, we still don't have RuboCop on our project at Sagewell. I think that's true. Yeah, that's true. We have ESLint, but it's very minimal, what we have configured. And they more are in the what we deem to be true correctness checks, although that is a little bit of a blurry line there. But I really liked that idea. We turn on formatters. They just do the thing. We're not allowed to discuss the formatting, with the exception of that time that everybody snuck in and switched my 80-line length to a 120-line length, but I don't care. I'm obviously not still bitter about it. [chuckles] And then we've got a very minimal linting layer on top of that. +But like TypeScript, I care deeply, and I think I've talked in previous episodes where I'm like, dial up the strictness to 14 because TypeScript tends to tell me more truths I find, even though I have to jump through some hoops to be like TypeScript, I know that this is fine, but I can't prove it. And TypeScript makes me prove it, which I appreciate about it. +I also really liked the way you referred to RSpec's feedback to you was that RSpec was fussing at you. That was great. I like that. I'm going to internalize that. Whenever a linter or type system or anything like that when they tell me no, I'm going to be like, stop fussing, nope, nope. [chuckles] +STEPH: I don't remember saying that, but I'm going to trust you that that's what I said. That's just my true southern self coming through on the mic, fussing, and then go get a biscuit, and it'll just be a delightful day. +CHRIS: So if I give RuboCop a biscuit, it will stop fussing at me, potentially? +STEPH: No, the biscuit is just for you. You get fussed at; you go get a biscuit. It makes you feel better, and then you deal with the fussing. +CHRIS: Sold. +STEPH: Fussing and cussing, [laughs] that's most of my work life lately, fussing and cussing. [laughs] +CHRIS: And occasional biscuits, I hope. +STEPH: And occasional biscuits. You got it. But that's what's new in my world. What's going on in your world? +CHRIS: Let's see. In my world, it's a short week so far. So recording on Wednesday, Monday was a holiday. And I was out all last week, which very much enjoyed my vacation. It was lovely. Went over to Europe, hung out there for a bit, some time in Paris, some time in Amsterdam, precious little time on a computer, which is very rare for me. So it was very enjoyable. But yeah, back now trying to just get back into the swing of things. +Thankfully, this turned out to be a really great time to step away from the work for a little while because we're still in this calm before the storm but in a good way is how I would describe it. We have a major facet of the Sagewell platform that we are in the planning modes for right now. But we need to get a couple of different considerations, pick a partner vendor, et cetera, that sort of thing. So right now, we're not really in a position to break ground on what we know will be a very large body of work. +We're also not taking on anything else too big. We're using this time to shore up a lot of different things. As an example, one of the fun things that we've done in this period of time is we have a lot of webhooks in the app, like a lot of webhooks coming into the app, just due to the fact that we're an integration of a lot of services under the hood. +And we have a pattern for how we interact with and process, so we actually persist the webhook data when they come in. And then we have a background job that processes and watch our pattern to make sure we're not losing anything and the ability to verify against our local version, and the remote version, a bunch of different things. Because turns out webhooks are critical to how our app works. And so that's something that we really want to take very seriously and build out how we work with that. +I think we have eight different webhook integrations right now; maybe it's more. It's a lot. And with those, we've implemented the same pattern now eight times; I want to say. And in squinting at it from a distance, we're like; it is indeed identically the same pattern in all eight cases or with the tiniest little variation in one of them. And so we've now accepted like, okay, that's true. +So the next one of them that we introduced, we opted to do it in a generic way. So we introduced the abstraction with the next iteration of this thing. And now we're in a position...we're very happy with what we ended up with there. It's like the best of all of the other versions of it. And now, the plan will be to slowly migrate each of the existing ones to be no longer a unique special version of webhook processing but use the generic webhook processing pattern that we have in the app. So that's nice. +I feel good about how long we waited as well because it's like, we have webhooks. Let's introduce the webhook framework to rule them all within our app. It's like, no, wait until you see. Check and make sure they are, in fact, the same and not just incidental duplication. +STEPH: I appreciate that so much. That's awesome. That sounds like a wonderful use of that in-between state that you're in where you still got to make progress but also introduce some refactoring and a new concept. And I also appreciate how long you waited because that's one of those areas where I've just learned, like, just wait. It's not going to hurt you. Just embrace the duplication and then make sure it's the right thing. +Because even if you have to go in and update it in a couple of places, okay, sure, that feels a little tedious, but it feels very safe too. If it doesn't feel safe...I could talk myself back and forth on this one. If it doesn't feel safe, that's a different discussion. But if you're going through and you have to update something in a couple of different places, that's quick. And sure, you had to repeat yourself a little bit, but that's fine. Versus if you have two or three of something and you're like, oh, I immediately must extract. That's probably going to cause more pain than it's worth at this point. +CHRIS: Yeah, exactly, exactly that. And we did get to that place where we were starting to feel a tiny bit of pain. We had a surprising bit of behavior that when we looked at it, we were like, oh, that's interesting, because of how we implemented the webhook pattern, this is happening. And so then we went to fix it, but we were like, oh, it would actually be really nice to have this fixed across everything. +We've had conversations about other refinements, enhancements, et cetera; that we could do in this space. That, again, would be really nice to be able to do holistically across all of the different webhook integration things that we have. And so it feels like we waited the right amount of time. But then we also started to...we're trying to be very responsive to the pressure that the system is pushing back on us. +As an aside, the crispy Brussels snack hour and the crispy Brussels work lunch continue to be utterly fantastic ways in which we work. For anyone that is unfamiliar or hasn't listened to episodes where I rambled about those nonsense phrases that I just said, they're basically just structured time where the engineering team at Sagewell looks at and discusses higher-level architecture, refactoring, developer experience, those sort of things that don't really belong on the core product board. So we have a separate place to organize them, to gather them. +And then also, we have a session where we vote on them, decide which ones feel important to take on but try and make sure we're being intentional about how much of that work we're taking on relative to how much of core product work and try and keep sort of a good ratio in between the two. And thus far, that's been really fantastic and continues to be, I think, really effective. And also the sort of thing that just keeps the developer team really happy. So it's like, I'm happy to work in this system because we know we have a way to change it and improve it where there's pain. +STEPH: I like the idea of this being a game show where it's like refactor island, and everybody gets together and gets to vote which refactor stays or gets booted off the island. I'm also going to go back and qualify something I said a moment ago, where if something feels safe in terms of duplication, where it starts to feel unsafe is if there's like an area that you forgot to update because you didn't realize it's duplicated in several areas and then that causes you pain. Then that's one of those areas where I'll start to say, "Okay, let's rethink the duplication and look to dry this up." +CHRIS: Yep, indeed. It's definitely like a correction early on in my career and overcorrection back and trying to find that happy medium place. But as an aside, just throwing this out there, so webhooks are an interesting space. I wish it were a more commoditized offering of platforms. Every vendor that we're integrating with that does webhooks does it slightly differently. It's like, "Oh, do you folks have retries?" They're like, "No." It's like, oh, what do you mean no? I would love it if you had retries because, I don't know, we might have some reason to not receive one of them. And there's polling, and there are lots of different variations. +But the one thing that I'm surprised by is that webhook signing I don't feel like people take it serious enough. It is a case where it's not a huge security vulnerability in your app. But I was reading someone who is a security analyst at one point. And they were describing sort of, I've done tons of in-the-code audits of security practices, and here are the things that I see. And so it's the normal like OWASP Top 10 Cross-Site Request Forgery, and SQL injection, and all that kind of stuff. +But one of the other ones he highlighted is so often he finds webhooks that are not verified in any way. So it's just like anyone can post data into the system. And if you post it in the right shape, the system's going to do some stuff. And there's no way for the external system to enforce that you properly validate and verify a webhook coming in, verify that payload. It's an extra thing where you do the checksum math and whatnot and take the signature header. I've seen somewhere they just don't provide it. And it's like, what do you mean you don't provide it? You must provide it, please. +So it's either have an API key so that we have some way to verify that you are who you say you are or add a signature, and then we'll calculate it. And it's a little bit of a dance, and everybody does it different, but whatever. But the cases where they just don't have it, I'm like, I'm sorry, what now? You're going to say whom? But yeah, then it's our job to definitely implement that. +So this is just a notice out there to anyone that's listening. If you got a bunch of webhook handling code in your app, maybe spot-check that you're actually verifying the payloads because it's possible that you're not. And that's a weird, very open hole in the side of your application. +STEPH: That's a really great point. I have not worked with webhooks recently. And in the past, I can't recall if that's something that I've really looked at closely. So I'm glad you shared that. +CHRIS: It's such an easy thing to skip. Like, it's one of those things that there's no way to enforce it. And so, I'd be interested in a survey that can't be done because this is all proprietary data. But what percentage of webhook integrations are unverified? Is it 50%? Is it 10%? Is it 100%? It's definitely not 100. But it's somewhere in there that I find interesting. It's not a terribly exploitable vulnerability because you have to have deep knowledge of the system. +In order to take advantage of it, you need to know what endpoint to hit to, what shape of data to send because otherwise, you're probably just going to cause an error or get a bunch of 404s. But like, it's, I don't know, it's discoverable. And yeah, it's an interesting one. So I will hop off my webhook soapbox now, but that's a thought. +MIDROLL AD: +Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half. +So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! +Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. +In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. +Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. +Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. +Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! +CHRIS: But now that I'm off my soapbox, I believe we have a topic that was suggested. Do you want to provide a little bit of context here, Steph? +STEPH: Yeah, I'd love to. So this came up when I was having a conversation with another thoughtboter. And given that we change projects fairly frequently, on the Boost team, we typically change projects around every six months. They asked a really thoughtful question that was "How do you get acquainted with a new codebase? So given that you're changing projects so often, what are some of the tips and tricks for ways that you've learned to then quickly get up to speed with a new codebase?" Because, frankly, that is one of the thoughtbot superpowers is that we are really good at onboarding each other and then also getting up to speed with a new team, and their processes, and their codebase. +So I have a couple of ideas, and then I'd love to hear some of your thoughts as well. So I'll dive in with a couple. So the first one, this one's frankly my favorite. Like day one, if there's a team where I'm joining and they have someone that can walk me through the application from the users' perspective, maybe it's someone that's in sales, or maybe it's someone on the product team, maybe it's a recording that they've already done for other people, but that's my first and favorite way to get to know an application. +I really want to know what are users experience as they're going through this app? That will help me focus on the more critical areas of the application based on usage. So if that's available, that's fabulous. I'm also going to tailor a lot of this more to like a Rails app since that's typically the type of project that I'm onboarding to. So the other types of questions that I like to find answers to are just like, what's my top-level structure? Like to look through the app and see how are things organized? +Chris, you've mentioned in a previous episode where you have your client structure that then highlights all the third-party clients that you're working with. Are we using engines in the app? Is there anything that seems a bit more unique to that application that I'm going to want to brush up on or look into? What's the test coverage like? Do they have something that's already highlighting how much test coverage they have? If not, is there something that then I can run locally that will then show me that test coverage? +I also really like to look at the routes file. That's one of my other favorite places because that also is very similar to getting an overview of the product. I get to see more from the user perspective. What are the common resources that people are going to, and what are the domain topics that I'm working with in this new application? I've got a couple more, but I'm going to pause there and see how you get acquainted with a new app. +CHRIS: Well, unsurprisingly, I agree with all of those. We're still searching for that dare to disagree beyond Pop-Tarts and IPAs situation. To reiterate or to emphasize some of the points you made, the sales demo thing? I absolutely love that one because, yes, absolutely. What's the most customer-centric point of view that I can have? Can I then login to a staging version of the site so I can poke around and hopefully not break anything or move real money or anything like that? But understanding why is this thing, not in code, but in actual practical, observable, intractable software? +Beyond that, your point about the routes, absolutely, that's one of my go-to's, although the routes there often is so much in the routes, and it's like some of those may actually be unused. So a corollary to the routes where available if there's an APM tool like Scout, or New Relic, or something like that, taking a look at that and seeing what are the heavily trafficked endpoints within this app? I like to think about it as the entry points into this codebase. So the routes file enumerates all of them, but some of them matter, and some of them don't. +And so, an APM tool can actually tell you which are the ones that are seeing a ton of traffic. That's a really interesting question for me. Similarly, if we're on Heroku, I might look is there a scheduler? And if so, what are the tasks that are running in the background? That's another entry point into the app. And so I like to think about it from that idea of entry points. +If it's not on Heroku, and then there's some other system, like, I've used Cronic. I think it's Cronic, Whenever the Cron thing. Whenever, that's what it is, the Whenever gem that allows you to implement that, but it's in a file within the codebase, which as an aside, I really love that that's committed and expressive in the code. +Then that's another interesting one to see. If it's more exotic than that, I may have to chase it down or ask someone, but I'll try and find what are all of the entry points and which are the ones that matter the most? I can drill down from there and see, okay, what code then supports these entry points into the application? +I want to give an answer that also includes something like, oh, I do fancy static analysis in the codebase, and I do a churn versus complexity graph, and I start to...but I never do that, if we're being honest. The thing that I do is after that initial cursory scan of the landscape, I try and work on something that is relatively through the layers of the app, so not like, oh, I'll fix the text in a button. +But like, give me something weird and ideally, let me pair with someone and then try and move through the layers of the app. So okay, here's our UI. We're rendering in this way. The controllers are integrated in this way, et cetera. This is our database. Try and get through all the layers if possible to try and get as holistic of a view of how the application works. +The other thing that I think is really interesting about what you just said is you're like, I'm going to give some answers that are somewhat specific to a Rails app. And that totally makes sense to me because I know how to answer this in the context of a Rails app because those organizational patterns are so useful that I can hop into different Rails apps. And I've certainly seen ones that I'm like, this is odd and unfamiliar to me, but most of them are so much more discoverable because of that consistency. +Whereas I have worked on a number of React apps, and every single one I come into, I'm like, okay, wait, what are we doing? How are we doing state management? What's the routing like? Are we server-side rendering, are we not? And it is a thing that...I see that community really moving in the direction of finding the meta frameworks that stitch the pieces together and provide more organizational structure and answer more of the questions out of the box. +But it continues to be something that I absolutely love about Rails is that Rails answers so many of the questions for me. New people joining the team are like, oh, it's a Rails app, cool. I know how to Rails, and we get to run with that. And so that's more of a pitch for Rails than an answer to the question, but it is a thing that I felt in answering this question. [laughs] But yeah, those are some thoughts. But interested, it sounds like you had some more as well. I would love to hear what else was in your mind when you were thinking about this. +STEPH: I do. And I want to highlight you said some really wonderful things. One that really stuck out to me that I had not considered is using Scout APM to look at heavily-trafficked endpoints. I have that on my list in regards as something that I want to know what's my error tracking, observability. Like, if I break something or if you give me a bug ticket to work on, what am I going to use? How am I going to understand what's going wrong? But I hadn't thought of it in terms of seeing which endpoints are heavily used. So I really liked that one. +I also liked how you highlighted that you wish you'd do something fancy around doing a churn versus complexity kind of graph because I thought of that too. I was like, oh, that would be such a nice answer. But the truth is I also don't do that. I think it's all those things. I think it would be fun to make it easy. So I do that with new applications. But I agree; I typically more just dive in like, hey, give me a ticket. Let me go from there. +I might do some simple command-line checking. So, for example, if I want to look through app models, let's find out which model is the largest. I may look for that to see do we have a God object or something like that? So I may look there. I just want to know how long are some of these files? But I also don't use a particular tool for that churn versus complexity. +CHRIS: I think you hit the nail on the head with like, I wish that were easier or more in our toolset. But here on The Bike Shed, we tell the truth. And that is aspirational code flexing that we do not yet have. But I agree, that would be a really nice way to explore exactly what you're describing of, like, who are the God models? I'll definitely do that check, but not some of the more subtle and sophisticated show me the change over time of all these...like nah, that's not what I'm doing, much as I would like to be able to answer that way. +STEPH: But it also feels like one of those areas like, it would be nice, but I would be intrigued to see how much I use that. That might be a nice anecdote to have. But I find the diving into the codebase to be more fruitful because I guess it depends on what I'm really looking at. Am I looking to see how complicated of a codebase this is? Because then I need to give more of a high-level review to someone to say how long I think it's going to take for me to work on a particular feature or before I'm joining a team, like, who do I think are good teammates that would then enjoy working on this application? +That feels like a very different question to me versus the I'm already part of the team. I'm here. We're going to have complexity and churn. So I can just learn some of that over time. I don't have to know that upfront. Although it may be nice to just know at a high level, say like, okay, if I pick up a ticket, and then I look at that churn and complexity, to be like, okay, my ticket falls right smack-dab in the middle of that. So it's going to be a fun first week. That could be a fun fact. But otherwise, I'm not sure. I mean, yeah, I'd be intrigued to see how much it helps me. +One other place that I do browse is I go to the gem file. I'm just always curious, what do people have in their tool bag? I want to see are there any gems that have been pulled in that are helping the team process some deprecated behavior? So something that's been pulled out of Rails but then pulled into a separate gem. So then that way, they don't have to upgrade just yet, or they can upgrade but then still keep some of that existing old deprecated behavior. That kind of stuff is interesting to me. +And also, you called it earlier pairing. That's my other favorite way. I want to hear how people talk about the codebase, how they navigate. What are they frustrated by? What brings them joy? All of that is really helpful too. I think that covers all the ways that I immediately will go to when getting acquainted with a new codebase. +CHRIS: I think that covers most of what I have in mind, although the question is framed in an interesting way that I think really speaks to the consultant mindset. How do I get acquainted with a new codebase? But if you take the question and flip it around sort of 180 degrees, I think the question can be reframed as how does an organization help people onboard into a codebase? And so everything we just described are like, here's what I do, here's how I would go about it, and pairing starts to get to collaboration. +I think we've talked in a number of episodes about our thoughts on onboarding and being intentional with that, pairing people up. A lot of things we described it's like, it's ideal actually if the organization is pushing this. And you and I both worked as consultants for long enough that we're really in the mindset of like, all right, let's assume I'm just showing up. There's no one else there. They give me a laptop and no documentation and no other humans I'm allowed to talk to. How do I figure this out and get the next feature out to production? And ideally, it's something slightly better than that that we experience, but we're ready for whatever it is. +Versus, most people are working within the context of an organization for a longer period of time. And most organizations should be thinking about it from the perspective of how do I help the new hires come into this codebase and become effective as quickly as possible? And so I think a lot of what we said can just be flipped around and said from the other way, like, pair them up, put them on a feature early, give them a walkthrough of the codebase, give them a sales-centric demo. +Yeah, I feel equally about those things when said from the other side, but I do want to emphasize that this shouldn't be you're out there in the middle of the jungle with only a machete, and you got to figure out this codebase. Ideally, the organization is actually like, no, no, we'll help you. It's ours, so we know it. We can help you find the weird stuff. +STEPH: That's a really nice distinction, though, because you're right; I hadn't really thought about this. I was thinking about this from more of the perspective of you're out in the jungle with a machete, minus we did mention pairing in there [laughs] and maybe a demo. I was approaching it more from you're isolated or more solo and then getting accustomed to the codebase versus if you have more people to lean on. +But then that also makes me think of all the other processes that I didn't mention that I would include in that onboarding that you're speaking of, of like, how does this team work in terms of where do I push my code? What hooks are going to run? And then what do I wait for? How many people need to review my code? +There are all those process-y questions that I think would ideally be included on the onboarding. But that has happened before, I mean, where we've joined projects, and it's been like, okay, good luck. Let us know if you need anything. And so then you do need those machete skills to then start hacking away. [laughs] +CHRIS: We've been burned before. +STEPH: They come in handy. [laughs] So when you are in that situation, and there's a comet that's coming to destroy earth, and there's a Rails application that is preventing this big doomsday, the question is, do you take astronauts and train them to be Rails experts, or do you take Rails developers and train them to be astronauts? I think that's the big question. +CHRIS: What would Michael Bay do? +STEPH: On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Natural disaster movies, anyone? It's what Steph's been into, and Chris has THOUGHTS on the drilling in Armageddon.

+ +

Additionally, a chat around RuboCop RSpec rules happens, and they answer a listener's question, "how do you get acquainted with a new code base?"

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ + + +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow, and make things downright miserable.
+In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So I've been watching more movies lately. So evenings aren't always great; I don't always feel good being around 33 weeks pregnant now. Evenings I can be just kind of exhausted from the day, and I just need to chill and prop my feet up and all that good stuff. And I've been really drawn to natural disaster like end-of-the-world-type movies, and I'm not sure what that says about me. But it's my truth; it's where I'm at. [chuckles]

+ +

I watched Greenland recently, which I really enjoyed. I feel like they ended it well. I won't share any spoilers, but I feel like they ended it well. And they didn't take an easy shortcut out that I kind of thought that they might do, so that one was enjoyable. Geostorm, I watched that one just last night. San Andreas, I feel like that's one that I also watched recently. So yeah, that's what's new in my world, you know, your typical natural disaster end-of-the-world flicks. That's my new evening hobby.

+ +

CHRIS: I feel like I haven't heard of any of the three that you just listed, which is wild to me because this is a category that I find enthralling.

+ +

STEPH: Well, definitely start with Greenland. I feel like that one was the better of the three that I just mentioned. I don't know Geostorm or San Andreas which one you would prefer there. I feel like they're probably on par with each other in terms of like you're there for entertainment. We're not there to judge and be hypercritical of a storyline. You're there purely for the visual effects and for the ride.

+ +

CHRIS: Gotcha. Interesting. So quick question then, since this seems like the category you're interested in, Armageddon or Deep Impact?

+ +

STEPH: Ooh, I'm going to have to walk through the differences because I always get those mixed up. Armageddon is where they take Bruce Willis up to an asteroid, and they have to drill and drop a nuke, right?

+ +

CHRIS: They sure do.

+ +

STEPH: [laughs] And then what's Deep Impact about? I guess the fact that I know Armageddon better means I'm favoring that one. I can't place what...how does Deep Impact go?

+ +

CHRIS: Deep Impact is just there's an asteroid coming, and it's the story and what the people do. So it's got less...it doesn't have the same pop. I believe Armageddon was a Michael Bay movie. And so it's got that Michael Bay special bit of something on it. But the interesting thing is they came out the same year; I want to say.

+ +

It's one of those like Burger King and McDonald's being right next door to each other. It's like, what are you doing there? Why are you...like, asteroid devastation movies two of you at the same time, really? But yeah, Armageddon is the correct answer. Deep Impact is like a fine movie, but Armageddon is like, all right, we're going to have a movie about asteroids. Let's really go for it. Blow it out. Why not?

+ +

STEPH: Yeah, I'm with you. Armageddon definitely sticks out in my memory, so I'd vote that one. Also, for your other question that you didn't ask, but you kind of implicitly asked, I'm going to go McDonald's because Burger King fries are trash, and also, McDonald's has better ice cream cones.

+ +

CHRIS: Okay, so McDonald's fries. Oh no, I was thinking Wendy's, get a frosty from there, and then you make that combination because the frostys are great.

+ +

STEPH: Oh yeah, that's a good combo.

+ +

CHRIS: And you need the french fries to go with it, but then it's a third option that I'm introducing. Also, this wasn't a question, but I want to loop back briefly to Armageddon because it's an important piece of cinema. There's a really great...like it's DVD commentary, and it's Ben Affleck talking with Michael Bay about, "Hey, so in the movie, the premise is that the only way to possibly get this done is to train a bunch of oil drillers to be astronauts. Did we consider it all just having some astronauts learn to do oil drilling?" And Michael Bay's response is not safe for radio is how I would describe it. But it's very humorous hearing Ben Affleck describe Michael Bay responding to that.

+ +

STEPH: I think they addressed that in the movie, though. They mentioned like, we're going to train them, but they're like, no, drilling is such an art and a science. There's no way. We don't have time to teach these astronauts how to drill. So instead, it's easier to teach them to be astronauts.

+ +

CHRIS: Right. That is what they say in the movie.

+ +

STEPH: [laughs] Okay.

+ +

CHRIS: But just spending a minute teasing that one apart is like, being an astronaut is easy. You just sit in the spaceship, and it goes, boom. [laughs] It's like; actually, there's a little bit more to being an astronaut. Yes, drilling is very subtle science and art fusion. But the idea that being an astronaut [laughs] is just like, just push the go-to space button, then you go to space.

+ +

STEPH: The training montage is definitely better if we get to watch people learn how to be astronauts than if we watch people learn how to drill. [laughs] So that might have also played a role.

+ +

CHRIS: No question, it is the correct cinematic choice. But whether or not it's the true answer...say we were actually faced with this problem, I don't know that this is exactly how it would play out.

+ +

STEPH: I think we should A/B test it. We'll have one group train to be drill experts and one group train to be astronauts, and we'll send them both up.

+ +

CHRIS: This is smart. That's the way you got to do it. The one other thing that I'm going to go...you know what really grinds my gears? In the movie Armageddon, they have this robotic vehicle thing, the armadillo; I believe it's called. I know more than I thought I would remember about this movie. [chuckles] Anyway, continuing on, the armadillo, the vehicle that they use to do the drilling, has the drill arm on it that extends out and drills down into the asteroid. And it has gears on the end of it. It has three gears specifically.

+ +

And the first gear is intermeshed with the second gear, which is intermeshed with the third gear, which is intermeshed with the first gear, so imagine which direction the first gear is turning, then imagine the second gear turning, then imagine the third gear turning. They can't. It's a physically impossible object. One tries to turn clockwise, and the other one is trying to go counterclockwise, and they're intermeshed. So the whole thing would just cease up. It just doesn't work.

+ +

I've looked at it a bunch of times, and I want to just be wrong about this. I want to be like; I don't know what's going on. But I think the gears on the drilling machine just fundamentally at a very simple mechanical level cannot work. And again, if you're going to do it, really go for it, Michael Bay. I kind of like that, and I really hate it at the same time.

+ +

STEPH: I have never noticed this. I'm intrigued. You know what? Maybe Armageddon will be the movie of choice tonight. [chuckles] Maybe that's what I'm going to watch. And I'm going to wait for the armadillo to come out so I can evaluate the gears. And I'm highly amused that this is the thing that grinds your gears are the gears on the armadillo.

+ +

CHRIS: Yeah. I was a young child at the time, and I remember I actually went to Disney World, and I saw they had the prop vehicle there. And I just kind of looked up at it, and I was like, no, that's not how gears work. I may have been naive and wrong as a child, and now I've just anchored this memory deep within me.

+ +

In a similar way, so I had a moment while traveling; actually, that reminded me of something that I said on a recent podcast episode where I was talking about names and pronunciation. And I was like, yeah, sometimes people ask me how to pronounce my name. And I can't imagine any variation. That was the thing I was just wrong about because 'Toomay' is a perfectly reasonable pronunciation of my name that I didn't even think...

+ +

I was just so anchored to the one truth that I know in the world that my name is Toomey. And that's the only possible way anyone could pronounce it. Nope, totally wrong. So maybe the gears in Armageddon actually work really, really well, and maybe I'm just wrong. I'm willing to be wrong on the internet, which I believe is the name of the first episode that we recorded with you formally as a co-host. [chuckles] So yeah.

+ +

STEPH: Yeah, that sounds true. So you're going to change the intro? It's now going to be like, and I'm Chris 'Toomay'.

+ +

CHRIS: I might change it each time I come up with a new subtle pronunciation. We'll see. So far, I've got two that I know of. I can't imagine a third, but I was wrong about one. So maybe I'm wrong about two.

+ +

STEPH: It would be fun to see who pays attention. As someone who deeply values pronouncing someone's name correctly, oh my goodness, that would stress me out to hear someone keep pronouncing their name differently. Or I would be like, okay, they're having fun, and they don't mind how it gets pronounced.

+ +

I can't remember if we've talked about this on air but early on, I pronounced my last name differently for like one of the first episodes that we recorded. So it's 'Vicceri,' but it could also be 'Viccari'. And I've defaulted at times to saying 'Viccari' because people can spell that. It seems more natural. They understand it's V-I-C-C-A-R-I. But if I say 'Vicceri', then people want to add two Rs, or they want a Y. I don't know why it just seems to have a difference. And so then I was like, nope, I said it wrong. I need to say it right. It's 'Vicceri' even if it's more challenging for people.

+ +

And I think Chad Pytel had just walked in at that moment when I was saying that to you that I had said my name differently. And he's like, "You can't do that." And I'm like, "Well, I did it. It's already out there in the world." [laughs] But also, I'm one of those people that's like, Viccari, 'Vicceri' I will accept either.

+ +

In a slightly different topic and something that's going on in my world, there was a small win today with a client team that I really appreciated where someone brought up the conversation around the RuboCop RSpec rules and how RuboCop was fussing at them because they had too many lines in their test example. And so they're like, well, they're like, I feel like I'm competing, or I'm working against RuboCop. RuboCop wants me to shorten my test example lines, but yet, I'm not sure what else to do about it.

+ +

And someone's like, "Well, you could extract more into before blocks and to lets and to helpers or things like that to then shorten the test. They're like, "But that does also work against readability of the test if you do that." So then there was a nice, short conversation around well, then we really need more flexibility. We shouldn't let the RuboCop metrics drive us in this particular decision when we really want to optimize for readability.

+ +

And so then it was a discussion of okay, well, how much flexibility do we add to it? And I was like, "Well, what if we just got rid of it? Because I don't think there's an ideal length for how long your test should be. And I'd rather empower test authors to use all the space that they need to show their test setup and even lean into duplication before they extract things because this codebase has far more dry tests than they do duplication concerns. So I'd rather lean into the duplication at this point."

+ +

And the others that happened to be in that conversation were like, "Yep, that sounds good." So then that person issued a PR that then removed the check for that particular; how long are the examples? And it was lovely. It was just like a nice, quick win and a wonderful discussion that someone had brought up.

+ +

CHRIS: Ooh, I like that. That sounds like a great conversation that hit on why do we have this? What are the trade-offs? Let's actually remove it. And it’s also nice that you got to that place. I've seen a lot of folks have a lot of opinions in the past in this space. And opinions can be tricky to work around, and just deeply, deeply entrenched opinions is the thing that I find interesting. And I think I'm increasingly in the space of those sort of, thou shalt not type linter rules are not ideal in my mind. I want true correctness checks that really tell some truth about the codebase.

+ +

Like, we still don't have RuboCop on our project at Sagewell. I think that's true. Yeah, that's true. We have ESLint, but it's very minimal, what we have configured. And they more are in the what we deem to be true correctness checks, although that is a little bit of a blurry line there. But I really liked that idea. We turn on formatters. They just do the thing. We're not allowed to discuss the formatting, with the exception of that time that everybody snuck in and switched my 80-line length to a 120-line length, but I don't care. I'm obviously not still bitter about it. [chuckles] And then we've got a very minimal linting layer on top of that.

+ +

But like TypeScript, I care deeply, and I think I've talked in previous episodes where I'm like, dial up the strictness to 14 because TypeScript tends to tell me more truths I find, even though I have to jump through some hoops to be like TypeScript, I know that this is fine, but I can't prove it. And TypeScript makes me prove it, which I appreciate about it.

+ +

I also really liked the way you referred to RSpec's feedback to you was that RSpec was fussing at you. That was great. I like that. I'm going to internalize that. Whenever a linter or type system or anything like that when they tell me no, I'm going to be like, stop fussing, nope, nope. [chuckles]

+ +

STEPH: I don't remember saying that, but I'm going to trust you that that's what I said. That's just my true southern self coming through on the mic, fussing, and then go get a biscuit, and it'll just be a delightful day.

+ +

CHRIS: So if I give RuboCop a biscuit, it will stop fussing at me, potentially?

+ +

STEPH: No, the biscuit is just for you. You get fussed at; you go get a biscuit. It makes you feel better, and then you deal with the fussing.

+ +

CHRIS: Sold.

+ +

STEPH: Fussing and cussing, [laughs] that's most of my work life lately, fussing and cussing. [laughs]

+ +

CHRIS: And occasional biscuits, I hope.

+ +

STEPH: And occasional biscuits. You got it. But that's what's new in my world. What's going on in your world?

+ +

CHRIS: Let's see. In my world, it's a short week so far. So recording on Wednesday, Monday was a holiday. And I was out all last week, which very much enjoyed my vacation. It was lovely. Went over to Europe, hung out there for a bit, some time in Paris, some time in Amsterdam, precious little time on a computer, which is very rare for me. So it was very enjoyable. But yeah, back now trying to just get back into the swing of things.

+ +

Thankfully, this turned out to be a really great time to step away from the work for a little while because we're still in this calm before the storm but in a good way is how I would describe it. We have a major facet of the Sagewell platform that we are in the planning modes for right now. But we need to get a couple of different considerations, pick a partner vendor, et cetera, that sort of thing. So right now, we're not really in a position to break ground on what we know will be a very large body of work.

+ +

We're also not taking on anything else too big. We're using this time to shore up a lot of different things. As an example, one of the fun things that we've done in this period of time is we have a lot of webhooks in the app, like a lot of webhooks coming into the app, just due to the fact that we're an integration of a lot of services under the hood.

+ +

And we have a pattern for how we interact with and process, so we actually persist the webhook data when they come in. And then we have a background job that processes and watch our pattern to make sure we're not losing anything and the ability to verify against our local version, and the remote version, a bunch of different things. Because turns out webhooks are critical to how our app works. And so that's something that we really want to take very seriously and build out how we work with that.

+ +

I think we have eight different webhook integrations right now; maybe it's more. It's a lot. And with those, we've implemented the same pattern now eight times; I want to say. And in squinting at it from a distance, we're like; it is indeed identically the same pattern in all eight cases or with the tiniest little variation in one of them. And so we've now accepted like, okay, that's true.

+ +

So the next one of them that we introduced, we opted to do it in a generic way. So we introduced the abstraction with the next iteration of this thing. And now we're in a position...we're very happy with what we ended up with there. It's like the best of all of the other versions of it. And now, the plan will be to slowly migrate each of the existing ones to be no longer a unique special version of webhook processing but use the generic webhook processing pattern that we have in the app. So that's nice.

+ +

I feel good about how long we waited as well because it's like, we have webhooks. Let's introduce the webhook framework to rule them all within our app. It's like, no, wait until you see. Check and make sure they are, in fact, the same and not just incidental duplication.

+ +

STEPH: I appreciate that so much. That's awesome. That sounds like a wonderful use of that in-between state that you're in where you still got to make progress but also introduce some refactoring and a new concept. And I also appreciate how long you waited because that's one of those areas where I've just learned, like, just wait. It's not going to hurt you. Just embrace the duplication and then make sure it's the right thing.

+ +

Because even if you have to go in and update it in a couple of places, okay, sure, that feels a little tedious, but it feels very safe too. If it doesn't feel safe...I could talk myself back and forth on this one. If it doesn't feel safe, that's a different discussion. But if you're going through and you have to update something in a couple of different places, that's quick. And sure, you had to repeat yourself a little bit, but that's fine. Versus if you have two or three of something and you're like, oh, I immediately must extract. That's probably going to cause more pain than it's worth at this point.

+ +

CHRIS: Yeah, exactly, exactly that. And we did get to that place where we were starting to feel a tiny bit of pain. We had a surprising bit of behavior that when we looked at it, we were like, oh, that's interesting, because of how we implemented the webhook pattern, this is happening. And so then we went to fix it, but we were like, oh, it would actually be really nice to have this fixed across everything.

+ +

We've had conversations about other refinements, enhancements, et cetera; that we could do in this space. That, again, would be really nice to be able to do holistically across all of the different webhook integration things that we have. And so it feels like we waited the right amount of time. But then we also started to...we're trying to be very responsive to the pressure that the system is pushing back on us.

+ +

As an aside, the crispy Brussels snack hour and the crispy Brussels work lunch continue to be utterly fantastic ways in which we work. For anyone that is unfamiliar or hasn't listened to episodes where I rambled about those nonsense phrases that I just said, they're basically just structured time where the engineering team at Sagewell looks at and discusses higher-level architecture, refactoring, developer experience, those sort of things that don't really belong on the core product board. So we have a separate place to organize them, to gather them.

+ +

And then also, we have a session where we vote on them, decide which ones feel important to take on but try and make sure we're being intentional about how much of that work we're taking on relative to how much of core product work and try and keep sort of a good ratio in between the two. And thus far, that's been really fantastic and continues to be, I think, really effective. And also the sort of thing that just keeps the developer team really happy. So it's like, I'm happy to work in this system because we know we have a way to change it and improve it where there's pain.

+ +

STEPH: I like the idea of this being a game show where it's like refactor island, and everybody gets together and gets to vote which refactor stays or gets booted off the island. I'm also going to go back and qualify something I said a moment ago, where if something feels safe in terms of duplication, where it starts to feel unsafe is if there's like an area that you forgot to update because you didn't realize it's duplicated in several areas and then that causes you pain. Then that's one of those areas where I'll start to say, "Okay, let's rethink the duplication and look to dry this up."

+ +

CHRIS: Yep, indeed. It's definitely like a correction early on in my career and overcorrection back and trying to find that happy medium place. But as an aside, just throwing this out there, so webhooks are an interesting space. I wish it were a more commoditized offering of platforms. Every vendor that we're integrating with that does webhooks does it slightly differently. It's like, "Oh, do you folks have retries?" They're like, "No." It's like, oh, what do you mean no? I would love it if you had retries because, I don't know, we might have some reason to not receive one of them. And there's polling, and there are lots of different variations.

+ +

But the one thing that I'm surprised by is that webhook signing I don't feel like people take it serious enough. It is a case where it's not a huge security vulnerability in your app. But I was reading someone who is a security analyst at one point. And they were describing sort of, I've done tons of in-the-code audits of security practices, and here are the things that I see. And so it's the normal like OWASP Top 10 Cross-Site Request Forgery, and SQL injection, and all that kind of stuff.

+ +

But one of the other ones he highlighted is so often he finds webhooks that are not verified in any way. So it's just like anyone can post data into the system. And if you post it in the right shape, the system's going to do some stuff. And there's no way for the external system to enforce that you properly validate and verify a webhook coming in, verify that payload. It's an extra thing where you do the checksum math and whatnot and take the signature header. I've seen somewhere they just don't provide it. And it's like, what do you mean you don't provide it? You must provide it, please.

+ +

So it's either have an API key so that we have some way to verify that you are who you say you are or add a signature, and then we'll calculate it. And it's a little bit of a dance, and everybody does it different, but whatever. But the cases where they just don't have it, I'm like, I'm sorry, what now? You're going to say whom? But yeah, then it's our job to definitely implement that.

+ +

So this is just a notice out there to anyone that's listening. If you got a bunch of webhook handling code in your app, maybe spot-check that you're actually verifying the payloads because it's possible that you're not. And that's a weird, very open hole in the side of your application.

+ +

STEPH: That's a really great point. I have not worked with webhooks recently. And in the past, I can't recall if that's something that I've really looked at closely. So I'm glad you shared that.

+ +

CHRIS: It's such an easy thing to skip. Like, it's one of those things that there's no way to enforce it. And so, I'd be interested in a survey that can't be done because this is all proprietary data. But what percentage of webhook integrations are unverified? Is it 50%? Is it 10%? Is it 100%? It's definitely not 100. But it's somewhere in there that I find interesting. It's not a terribly exploitable vulnerability because you have to have deep knowledge of the system.

+ +

In order to take advantage of it, you need to know what endpoint to hit to, what shape of data to send because otherwise, you're probably just going to cause an error or get a bunch of 404s. But like, it's, I don't know, it's discoverable. And yeah, it's an interesting one. So I will hop off my webhook soapbox now, but that's a thought.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

CHRIS: But now that I'm off my soapbox, I believe we have a topic that was suggested. Do you want to provide a little bit of context here, Steph?

+ +

STEPH: Yeah, I'd love to. So this came up when I was having a conversation with another thoughtboter. And given that we change projects fairly frequently, on the Boost team, we typically change projects around every six months. They asked a really thoughtful question that was "How do you get acquainted with a new codebase? So given that you're changing projects so often, what are some of the tips and tricks for ways that you've learned to then quickly get up to speed with a new codebase?" Because, frankly, that is one of the thoughtbot superpowers is that we are really good at onboarding each other and then also getting up to speed with a new team, and their processes, and their codebase.

+ +

So I have a couple of ideas, and then I'd love to hear some of your thoughts as well. So I'll dive in with a couple. So the first one, this one's frankly my favorite. Like day one, if there's a team where I'm joining and they have someone that can walk me through the application from the users' perspective, maybe it's someone that's in sales, or maybe it's someone on the product team, maybe it's a recording that they've already done for other people, but that's my first and favorite way to get to know an application.

+ +

I really want to know what are users experience as they're going through this app? That will help me focus on the more critical areas of the application based on usage. So if that's available, that's fabulous. I'm also going to tailor a lot of this more to like a Rails app since that's typically the type of project that I'm onboarding to. So the other types of questions that I like to find answers to are just like, what's my top-level structure? Like to look through the app and see how are things organized?

+ +

Chris, you've mentioned in a previous episode where you have your client structure that then highlights all the third-party clients that you're working with. Are we using engines in the app? Is there anything that seems a bit more unique to that application that I'm going to want to brush up on or look into? What's the test coverage like? Do they have something that's already highlighting how much test coverage they have? If not, is there something that then I can run locally that will then show me that test coverage?

+ +

I also really like to look at the routes file. That's one of my other favorite places because that also is very similar to getting an overview of the product. I get to see more from the user perspective. What are the common resources that people are going to, and what are the domain topics that I'm working with in this new application? I've got a couple more, but I'm going to pause there and see how you get acquainted with a new app.

+ +

CHRIS: Well, unsurprisingly, I agree with all of those. We're still searching for that dare to disagree beyond Pop-Tarts and IPAs situation. To reiterate or to emphasize some of the points you made, the sales demo thing? I absolutely love that one because, yes, absolutely. What's the most customer-centric point of view that I can have? Can I then login to a staging version of the site so I can poke around and hopefully not break anything or move real money or anything like that? But understanding why is this thing, not in code, but in actual practical, observable, intractable software?

+ +

Beyond that, your point about the routes, absolutely, that's one of my go-to's, although the routes there often is so much in the routes, and it's like some of those may actually be unused. So a corollary to the routes where available if there's an APM tool like Scout, or New Relic, or something like that, taking a look at that and seeing what are the heavily trafficked endpoints within this app? I like to think about it as the entry points into this codebase. So the routes file enumerates all of them, but some of them matter, and some of them don't.

+ +

And so, an APM tool can actually tell you which are the ones that are seeing a ton of traffic. That's a really interesting question for me. Similarly, if we're on Heroku, I might look is there a scheduler? And if so, what are the tasks that are running in the background? That's another entry point into the app. And so I like to think about it from that idea of entry points.

+ +

If it's not on Heroku, and then there's some other system, like, I've used Cronic. I think it's Cronic, Whenever the Cron thing. Whenever, that's what it is, the Whenever gem that allows you to implement that, but it's in a file within the codebase, which as an aside, I really love that that's committed and expressive in the code.

+ +

Then that's another interesting one to see. If it's more exotic than that, I may have to chase it down or ask someone, but I'll try and find what are all of the entry points and which are the ones that matter the most? I can drill down from there and see, okay, what code then supports these entry points into the application?

+ +

I want to give an answer that also includes something like, oh, I do fancy static analysis in the codebase, and I do a churn versus complexity graph, and I start to...but I never do that, if we're being honest. The thing that I do is after that initial cursory scan of the landscape, I try and work on something that is relatively through the layers of the app, so not like, oh, I'll fix the text in a button.

+ +

But like, give me something weird and ideally, let me pair with someone and then try and move through the layers of the app. So okay, here's our UI. We're rendering in this way. The controllers are integrated in this way, et cetera. This is our database. Try and get through all the layers if possible to try and get as holistic of a view of how the application works.

+ +

The other thing that I think is really interesting about what you just said is you're like, I'm going to give some answers that are somewhat specific to a Rails app. And that totally makes sense to me because I know how to answer this in the context of a Rails app because those organizational patterns are so useful that I can hop into different Rails apps. And I've certainly seen ones that I'm like, this is odd and unfamiliar to me, but most of them are so much more discoverable because of that consistency.

+ +

Whereas I have worked on a number of React apps, and every single one I come into, I'm like, okay, wait, what are we doing? How are we doing state management? What's the routing like? Are we server-side rendering, are we not? And it is a thing that...I see that community really moving in the direction of finding the meta frameworks that stitch the pieces together and provide more organizational structure and answer more of the questions out of the box.

+ +

But it continues to be something that I absolutely love about Rails is that Rails answers so many of the questions for me. New people joining the team are like, oh, it's a Rails app, cool. I know how to Rails, and we get to run with that. And so that's more of a pitch for Rails than an answer to the question, but it is a thing that I felt in answering this question. [laughs] But yeah, those are some thoughts. But interested, it sounds like you had some more as well. I would love to hear what else was in your mind when you were thinking about this.

+ +

STEPH: I do. And I want to highlight you said some really wonderful things. One that really stuck out to me that I had not considered is using Scout APM to look at heavily-trafficked endpoints. I have that on my list in regards as something that I want to know what's my error tracking, observability. Like, if I break something or if you give me a bug ticket to work on, what am I going to use? How am I going to understand what's going wrong? But I hadn't thought of it in terms of seeing which endpoints are heavily used. So I really liked that one.

+ +

I also liked how you highlighted that you wish you'd do something fancy around doing a churn versus complexity kind of graph because I thought of that too. I was like, oh, that would be such a nice answer. But the truth is I also don't do that. I think it's all those things. I think it would be fun to make it easy. So I do that with new applications. But I agree; I typically more just dive in like, hey, give me a ticket. Let me go from there.

+ +

I might do some simple command-line checking. So, for example, if I want to look through app models, let's find out which model is the largest. I may look for that to see do we have a God object or something like that? So I may look there. I just want to know how long are some of these files? But I also don't use a particular tool for that churn versus complexity.

+ +

CHRIS: I think you hit the nail on the head with like, I wish that were easier or more in our toolset. But here on The Bike Shed, we tell the truth. And that is aspirational code flexing that we do not yet have. But I agree, that would be a really nice way to explore exactly what you're describing of, like, who are the God models? I'll definitely do that check, but not some of the more subtle and sophisticated show me the change over time of all these...like nah, that's not what I'm doing, much as I would like to be able to answer that way.

+ +

STEPH: But it also feels like one of those areas like, it would be nice, but I would be intrigued to see how much I use that. That might be a nice anecdote to have. But I find the diving into the codebase to be more fruitful because I guess it depends on what I'm really looking at. Am I looking to see how complicated of a codebase this is? Because then I need to give more of a high-level review to someone to say how long I think it's going to take for me to work on a particular feature or before I'm joining a team, like, who do I think are good teammates that would then enjoy working on this application?

+ +

That feels like a very different question to me versus the I'm already part of the team. I'm here. We're going to have complexity and churn. So I can just learn some of that over time. I don't have to know that upfront. Although it may be nice to just know at a high level, say like, okay, if I pick up a ticket, and then I look at that churn and complexity, to be like, okay, my ticket falls right smack-dab in the middle of that. So it's going to be a fun first week. That could be a fun fact. But otherwise, I'm not sure. I mean, yeah, I'd be intrigued to see how much it helps me.

+ +

One other place that I do browse is I go to the gem file. I'm just always curious, what do people have in their tool bag? I want to see are there any gems that have been pulled in that are helping the team process some deprecated behavior? So something that's been pulled out of Rails but then pulled into a separate gem. So then that way, they don't have to upgrade just yet, or they can upgrade but then still keep some of that existing old deprecated behavior. That kind of stuff is interesting to me.

+ +

And also, you called it earlier pairing. That's my other favorite way. I want to hear how people talk about the codebase, how they navigate. What are they frustrated by? What brings them joy? All of that is really helpful too. I think that covers all the ways that I immediately will go to when getting acquainted with a new codebase.

+ +

CHRIS: I think that covers most of what I have in mind, although the question is framed in an interesting way that I think really speaks to the consultant mindset. How do I get acquainted with a new codebase? But if you take the question and flip it around sort of 180 degrees, I think the question can be reframed as how does an organization help people onboard into a codebase? And so everything we just described are like, here's what I do, here's how I would go about it, and pairing starts to get to collaboration.

+ +

I think we've talked in a number of episodes about our thoughts on onboarding and being intentional with that, pairing people up. A lot of things we described it's like, it's ideal actually if the organization is pushing this. And you and I both worked as consultants for long enough that we're really in the mindset of like, all right, let's assume I'm just showing up. There's no one else there. They give me a laptop and no documentation and no other humans I'm allowed to talk to. How do I figure this out and get the next feature out to production? And ideally, it's something slightly better than that that we experience, but we're ready for whatever it is.

+ +

Versus, most people are working within the context of an organization for a longer period of time. And most organizations should be thinking about it from the perspective of how do I help the new hires come into this codebase and become effective as quickly as possible? And so I think a lot of what we said can just be flipped around and said from the other way, like, pair them up, put them on a feature early, give them a walkthrough of the codebase, give them a sales-centric demo.

+ +

Yeah, I feel equally about those things when said from the other side, but I do want to emphasize that this shouldn't be you're out there in the middle of the jungle with only a machete, and you got to figure out this codebase. Ideally, the organization is actually like, no, no, we'll help you. It's ours, so we know it. We can help you find the weird stuff.

+ +

STEPH: That's a really nice distinction, though, because you're right; I hadn't really thought about this. I was thinking about this from more of the perspective of you're out in the jungle with a machete, minus we did mention pairing in there [laughs] and maybe a demo. I was approaching it more from you're isolated or more solo and then getting accustomed to the codebase versus if you have more people to lean on.

+ +

But then that also makes me think of all the other processes that I didn't mention that I would include in that onboarding that you're speaking of, of like, how does this team work in terms of where do I push my code? What hooks are going to run? And then what do I wait for? How many people need to review my code?

+ +

There are all those process-y questions that I think would ideally be included on the onboarding. But that has happened before, I mean, where we've joined projects, and it's been like, okay, good luck. Let us know if you need anything. And so then you do need those machete skills to then start hacking away. [laughs]

+ +

CHRIS: We've been burned before.

+ +

STEPH: They come in handy. [laughs] So when you are in that situation, and there's a comet that's coming to destroy earth, and there's a Rails application that is preventing this big doomsday, the question is, do you take astronauts and train them to be Rails experts, or do you take Rails developers and train them to be astronauts? I think that's the big question.

+ +

CHRIS: What would Michael Bay do?

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Natural disaster movies, anyone? It's what Steph's been into, and Chris has THOUGHTS on the drilling in Armageddon.

+ +

Additionally, a chat around RuboCop RSpec rules happens, and they answer a listener's question, "how do you get acquainted with a new code base?"

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ + + +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow, and make things downright miserable.
+In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So I've been watching more movies lately. So evenings aren't always great; I don't always feel good being around 33 weeks pregnant now. Evenings I can be just kind of exhausted from the day, and I just need to chill and prop my feet up and all that good stuff. And I've been really drawn to natural disaster like end-of-the-world-type movies, and I'm not sure what that says about me. But it's my truth; it's where I'm at. [chuckles]

+ +

I watched Greenland recently, which I really enjoyed. I feel like they ended it well. I won't share any spoilers, but I feel like they ended it well. And they didn't take an easy shortcut out that I kind of thought that they might do, so that one was enjoyable. Geostorm, I watched that one just last night. San Andreas, I feel like that's one that I also watched recently. So yeah, that's what's new in my world, you know, your typical natural disaster end-of-the-world flicks. That's my new evening hobby.

+ +

CHRIS: I feel like I haven't heard of any of the three that you just listed, which is wild to me because this is a category that I find enthralling.

+ +

STEPH: Well, definitely start with Greenland. I feel like that one was the better of the three that I just mentioned. I don't know Geostorm or San Andreas which one you would prefer there. I feel like they're probably on par with each other in terms of like you're there for entertainment. We're not there to judge and be hypercritical of a storyline. You're there purely for the visual effects and for the ride.

+ +

CHRIS: Gotcha. Interesting. So quick question then, since this seems like the category you're interested in, Armageddon or Deep Impact?

+ +

STEPH: Ooh, I'm going to have to walk through the differences because I always get those mixed up. Armageddon is where they take Bruce Willis up to an asteroid, and they have to drill and drop a nuke, right?

+ +

CHRIS: They sure do.

+ +

STEPH: [laughs] And then what's Deep Impact about? I guess the fact that I know Armageddon better means I'm favoring that one. I can't place what...how does Deep Impact go?

+ +

CHRIS: Deep Impact is just there's an asteroid coming, and it's the story and what the people do. So it's got less...it doesn't have the same pop. I believe Armageddon was a Michael Bay movie. And so it's got that Michael Bay special bit of something on it. But the interesting thing is they came out the same year; I want to say.

+ +

It's one of those like Burger King and McDonald's being right next door to each other. It's like, what are you doing there? Why are you...like, asteroid devastation movies two of you at the same time, really? But yeah, Armageddon is the correct answer. Deep Impact is like a fine movie, but Armageddon is like, all right, we're going to have a movie about asteroids. Let's really go for it. Blow it out. Why not?

+ +

STEPH: Yeah, I'm with you. Armageddon definitely sticks out in my memory, so I'd vote that one. Also, for your other question that you didn't ask, but you kind of implicitly asked, I'm going to go McDonald's because Burger King fries are trash, and also, McDonald's has better ice cream cones.

+ +

CHRIS: Okay, so McDonald's fries. Oh no, I was thinking Wendy's, get a frosty from there, and then you make that combination because the frostys are great.

+ +

STEPH: Oh yeah, that's a good combo.

+ +

CHRIS: And you need the french fries to go with it, but then it's a third option that I'm introducing. Also, this wasn't a question, but I want to loop back briefly to Armageddon because it's an important piece of cinema. There's a really great...like it's DVD commentary, and it's Ben Affleck talking with Michael Bay about, "Hey, so in the movie, the premise is that the only way to possibly get this done is to train a bunch of oil drillers to be astronauts. Did we consider it all just having some astronauts learn to do oil drilling?" And Michael Bay's response is not safe for radio is how I would describe it. But it's very humorous hearing Ben Affleck describe Michael Bay responding to that.

+ +

STEPH: I think they addressed that in the movie, though. They mentioned like, we're going to train them, but they're like, no, drilling is such an art and a science. There's no way. We don't have time to teach these astronauts how to drill. So instead, it's easier to teach them to be astronauts.

+ +

CHRIS: Right. That is what they say in the movie.

+ +

STEPH: [laughs] Okay.

+ +

CHRIS: But just spending a minute teasing that one apart is like, being an astronaut is easy. You just sit in the spaceship, and it goes, boom. [laughs] It's like; actually, there's a little bit more to being an astronaut. Yes, drilling is very subtle science and art fusion. But the idea that being an astronaut [laughs] is just like, just push the go-to space button, then you go to space.

+ +

STEPH: The training montage is definitely better if we get to watch people learn how to be astronauts than if we watch people learn how to drill. [laughs] So that might have also played a role.

+ +

CHRIS: No question, it is the correct cinematic choice. But whether or not it's the true answer...say we were actually faced with this problem, I don't know that this is exactly how it would play out.

+ +

STEPH: I think we should A/B test it. We'll have one group train to be drill experts and one group train to be astronauts, and we'll send them both up.

+ +

CHRIS: This is smart. That's the way you got to do it. The one other thing that I'm going to go...you know what really grinds my gears? In the movie Armageddon, they have this robotic vehicle thing, the armadillo; I believe it's called. I know more than I thought I would remember about this movie. [chuckles] Anyway, continuing on, the armadillo, the vehicle that they use to do the drilling, has the drill arm on it that extends out and drills down into the asteroid. And it has gears on the end of it. It has three gears specifically.

+ +

And the first gear is intermeshed with the second gear, which is intermeshed with the third gear, which is intermeshed with the first gear, so imagine which direction the first gear is turning, then imagine the second gear turning, then imagine the third gear turning. They can't. It's a physically impossible object. One tries to turn clockwise, and the other one is trying to go counterclockwise, and they're intermeshed. So the whole thing would just cease up. It just doesn't work.

+ +

I've looked at it a bunch of times, and I want to just be wrong about this. I want to be like; I don't know what's going on. But I think the gears on the drilling machine just fundamentally at a very simple mechanical level cannot work. And again, if you're going to do it, really go for it, Michael Bay. I kind of like that, and I really hate it at the same time.

+ +

STEPH: I have never noticed this. I'm intrigued. You know what? Maybe Armageddon will be the movie of choice tonight. [chuckles] Maybe that's what I'm going to watch. And I'm going to wait for the armadillo to come out so I can evaluate the gears. And I'm highly amused that this is the thing that grinds your gears are the gears on the armadillo.

+ +

CHRIS: Yeah. I was a young child at the time, and I remember I actually went to Disney World, and I saw they had the prop vehicle there. And I just kind of looked up at it, and I was like, no, that's not how gears work. I may have been naive and wrong as a child, and now I've just anchored this memory deep within me.

+ +

In a similar way, so I had a moment while traveling; actually, that reminded me of something that I said on a recent podcast episode where I was talking about names and pronunciation. And I was like, yeah, sometimes people ask me how to pronounce my name. And I can't imagine any variation. That was the thing I was just wrong about because 'Toomay' is a perfectly reasonable pronunciation of my name that I didn't even think...

+ +

I was just so anchored to the one truth that I know in the world that my name is Toomey. And that's the only possible way anyone could pronounce it. Nope, totally wrong. So maybe the gears in Armageddon actually work really, really well, and maybe I'm just wrong. I'm willing to be wrong on the internet, which I believe is the name of the first episode that we recorded with you formally as a co-host. [chuckles] So yeah.

+ +

STEPH: Yeah, that sounds true. So you're going to change the intro? It's now going to be like, and I'm Chris 'Toomay'.

+ +

CHRIS: I might change it each time I come up with a new subtle pronunciation. We'll see. So far, I've got two that I know of. I can't imagine a third, but I was wrong about one. So maybe I'm wrong about two.

+ +

STEPH: It would be fun to see who pays attention. As someone who deeply values pronouncing someone's name correctly, oh my goodness, that would stress me out to hear someone keep pronouncing their name differently. Or I would be like, okay, they're having fun, and they don't mind how it gets pronounced.

+ +

I can't remember if we've talked about this on air but early on, I pronounced my last name differently for like one of the first episodes that we recorded. So it's 'Vicceri,' but it could also be 'Viccari'. And I've defaulted at times to saying 'Viccari' because people can spell that. It seems more natural. They understand it's V-I-C-C-A-R-I. But if I say 'Vicceri', then people want to add two Rs, or they want a Y. I don't know why it just seems to have a difference. And so then I was like, nope, I said it wrong. I need to say it right. It's 'Vicceri' even if it's more challenging for people.

+ +

And I think Chad Pytel had just walked in at that moment when I was saying that to you that I had said my name differently. And he's like, "You can't do that." And I'm like, "Well, I did it. It's already out there in the world." [laughs] But also, I'm one of those people that's like, Viccari, 'Vicceri' I will accept either.

+ +

In a slightly different topic and something that's going on in my world, there was a small win today with a client team that I really appreciated where someone brought up the conversation around the RuboCop RSpec rules and how RuboCop was fussing at them because they had too many lines in their test example. And so they're like, well, they're like, I feel like I'm competing, or I'm working against RuboCop. RuboCop wants me to shorten my test example lines, but yet, I'm not sure what else to do about it.

+ +

And someone's like, "Well, you could extract more into before blocks and to lets and to helpers or things like that to then shorten the test. They're like, "But that does also work against readability of the test if you do that." So then there was a nice, short conversation around well, then we really need more flexibility. We shouldn't let the RuboCop metrics drive us in this particular decision when we really want to optimize for readability.

+ +

And so then it was a discussion of okay, well, how much flexibility do we add to it? And I was like, "Well, what if we just got rid of it? Because I don't think there's an ideal length for how long your test should be. And I'd rather empower test authors to use all the space that they need to show their test setup and even lean into duplication before they extract things because this codebase has far more dry tests than they do duplication concerns. So I'd rather lean into the duplication at this point."

+ +

And the others that happened to be in that conversation were like, "Yep, that sounds good." So then that person issued a PR that then removed the check for that particular; how long are the examples? And it was lovely. It was just like a nice, quick win and a wonderful discussion that someone had brought up.

+ +

CHRIS: Ooh, I like that. That sounds like a great conversation that hit on why do we have this? What are the trade-offs? Let's actually remove it. And it’s also nice that you got to that place. I've seen a lot of folks have a lot of opinions in the past in this space. And opinions can be tricky to work around, and just deeply, deeply entrenched opinions is the thing that I find interesting. And I think I'm increasingly in the space of those sort of, thou shalt not type linter rules are not ideal in my mind. I want true correctness checks that really tell some truth about the codebase.

+ +

Like, we still don't have RuboCop on our project at Sagewell. I think that's true. Yeah, that's true. We have ESLint, but it's very minimal, what we have configured. And they more are in the what we deem to be true correctness checks, although that is a little bit of a blurry line there. But I really liked that idea. We turn on formatters. They just do the thing. We're not allowed to discuss the formatting, with the exception of that time that everybody snuck in and switched my 80-line length to a 120-line length, but I don't care. I'm obviously not still bitter about it. [chuckles] And then we've got a very minimal linting layer on top of that.

+ +

But like TypeScript, I care deeply, and I think I've talked in previous episodes where I'm like, dial up the strictness to 14 because TypeScript tends to tell me more truths I find, even though I have to jump through some hoops to be like TypeScript, I know that this is fine, but I can't prove it. And TypeScript makes me prove it, which I appreciate about it.

+ +

I also really liked the way you referred to RSpec's feedback to you was that RSpec was fussing at you. That was great. I like that. I'm going to internalize that. Whenever a linter or type system or anything like that when they tell me no, I'm going to be like, stop fussing, nope, nope. [chuckles]

+ +

STEPH: I don't remember saying that, but I'm going to trust you that that's what I said. That's just my true southern self coming through on the mic, fussing, and then go get a biscuit, and it'll just be a delightful day.

+ +

CHRIS: So if I give RuboCop a biscuit, it will stop fussing at me, potentially?

+ +

STEPH: No, the biscuit is just for you. You get fussed at; you go get a biscuit. It makes you feel better, and then you deal with the fussing.

+ +

CHRIS: Sold.

+ +

STEPH: Fussing and cussing, [laughs] that's most of my work life lately, fussing and cussing. [laughs]

+ +

CHRIS: And occasional biscuits, I hope.

+ +

STEPH: And occasional biscuits. You got it. But that's what's new in my world. What's going on in your world?

+ +

CHRIS: Let's see. In my world, it's a short week so far. So recording on Wednesday, Monday was a holiday. And I was out all last week, which very much enjoyed my vacation. It was lovely. Went over to Europe, hung out there for a bit, some time in Paris, some time in Amsterdam, precious little time on a computer, which is very rare for me. So it was very enjoyable. But yeah, back now trying to just get back into the swing of things.

+ +

Thankfully, this turned out to be a really great time to step away from the work for a little while because we're still in this calm before the storm but in a good way is how I would describe it. We have a major facet of the Sagewell platform that we are in the planning modes for right now. But we need to get a couple of different considerations, pick a partner vendor, et cetera, that sort of thing. So right now, we're not really in a position to break ground on what we know will be a very large body of work.

+ +

We're also not taking on anything else too big. We're using this time to shore up a lot of different things. As an example, one of the fun things that we've done in this period of time is we have a lot of webhooks in the app, like a lot of webhooks coming into the app, just due to the fact that we're an integration of a lot of services under the hood.

+ +

And we have a pattern for how we interact with and process, so we actually persist the webhook data when they come in. And then we have a background job that processes and watch our pattern to make sure we're not losing anything and the ability to verify against our local version, and the remote version, a bunch of different things. Because turns out webhooks are critical to how our app works. And so that's something that we really want to take very seriously and build out how we work with that.

+ +

I think we have eight different webhook integrations right now; maybe it's more. It's a lot. And with those, we've implemented the same pattern now eight times; I want to say. And in squinting at it from a distance, we're like; it is indeed identically the same pattern in all eight cases or with the tiniest little variation in one of them. And so we've now accepted like, okay, that's true.

+ +

So the next one of them that we introduced, we opted to do it in a generic way. So we introduced the abstraction with the next iteration of this thing. And now we're in a position...we're very happy with what we ended up with there. It's like the best of all of the other versions of it. And now, the plan will be to slowly migrate each of the existing ones to be no longer a unique special version of webhook processing but use the generic webhook processing pattern that we have in the app. So that's nice.

+ +

I feel good about how long we waited as well because it's like, we have webhooks. Let's introduce the webhook framework to rule them all within our app. It's like, no, wait until you see. Check and make sure they are, in fact, the same and not just incidental duplication.

+ +

STEPH: I appreciate that so much. That's awesome. That sounds like a wonderful use of that in-between state that you're in where you still got to make progress but also introduce some refactoring and a new concept. And I also appreciate how long you waited because that's one of those areas where I've just learned, like, just wait. It's not going to hurt you. Just embrace the duplication and then make sure it's the right thing.

+ +

Because even if you have to go in and update it in a couple of places, okay, sure, that feels a little tedious, but it feels very safe too. If it doesn't feel safe...I could talk myself back and forth on this one. If it doesn't feel safe, that's a different discussion. But if you're going through and you have to update something in a couple of different places, that's quick. And sure, you had to repeat yourself a little bit, but that's fine. Versus if you have two or three of something and you're like, oh, I immediately must extract. That's probably going to cause more pain than it's worth at this point.

+ +

CHRIS: Yeah, exactly, exactly that. And we did get to that place where we were starting to feel a tiny bit of pain. We had a surprising bit of behavior that when we looked at it, we were like, oh, that's interesting, because of how we implemented the webhook pattern, this is happening. And so then we went to fix it, but we were like, oh, it would actually be really nice to have this fixed across everything.

+ +

We've had conversations about other refinements, enhancements, et cetera; that we could do in this space. That, again, would be really nice to be able to do holistically across all of the different webhook integration things that we have. And so it feels like we waited the right amount of time. But then we also started to...we're trying to be very responsive to the pressure that the system is pushing back on us.

+ +

As an aside, the crispy Brussels snack hour and the crispy Brussels work lunch continue to be utterly fantastic ways in which we work. For anyone that is unfamiliar or hasn't listened to episodes where I rambled about those nonsense phrases that I just said, they're basically just structured time where the engineering team at Sagewell looks at and discusses higher-level architecture, refactoring, developer experience, those sort of things that don't really belong on the core product board. So we have a separate place to organize them, to gather them.

+ +

And then also, we have a session where we vote on them, decide which ones feel important to take on but try and make sure we're being intentional about how much of that work we're taking on relative to how much of core product work and try and keep sort of a good ratio in between the two. And thus far, that's been really fantastic and continues to be, I think, really effective. And also the sort of thing that just keeps the developer team really happy. So it's like, I'm happy to work in this system because we know we have a way to change it and improve it where there's pain.

+ +

STEPH: I like the idea of this being a game show where it's like refactor island, and everybody gets together and gets to vote which refactor stays or gets booted off the island. I'm also going to go back and qualify something I said a moment ago, where if something feels safe in terms of duplication, where it starts to feel unsafe is if there's like an area that you forgot to update because you didn't realize it's duplicated in several areas and then that causes you pain. Then that's one of those areas where I'll start to say, "Okay, let's rethink the duplication and look to dry this up."

+ +

CHRIS: Yep, indeed. It's definitely like a correction early on in my career and overcorrection back and trying to find that happy medium place. But as an aside, just throwing this out there, so webhooks are an interesting space. I wish it were a more commoditized offering of platforms. Every vendor that we're integrating with that does webhooks does it slightly differently. It's like, "Oh, do you folks have retries?" They're like, "No." It's like, oh, what do you mean no? I would love it if you had retries because, I don't know, we might have some reason to not receive one of them. And there's polling, and there are lots of different variations.

+ +

But the one thing that I'm surprised by is that webhook signing I don't feel like people take it serious enough. It is a case where it's not a huge security vulnerability in your app. But I was reading someone who is a security analyst at one point. And they were describing sort of, I've done tons of in-the-code audits of security practices, and here are the things that I see. And so it's the normal like OWASP Top 10 Cross-Site Request Forgery, and SQL injection, and all that kind of stuff.

+ +

But one of the other ones he highlighted is so often he finds webhooks that are not verified in any way. So it's just like anyone can post data into the system. And if you post it in the right shape, the system's going to do some stuff. And there's no way for the external system to enforce that you properly validate and verify a webhook coming in, verify that payload. It's an extra thing where you do the checksum math and whatnot and take the signature header. I've seen somewhere they just don't provide it. And it's like, what do you mean you don't provide it? You must provide it, please.

+ +

So it's either have an API key so that we have some way to verify that you are who you say you are or add a signature, and then we'll calculate it. And it's a little bit of a dance, and everybody does it different, but whatever. But the cases where they just don't have it, I'm like, I'm sorry, what now? You're going to say whom? But yeah, then it's our job to definitely implement that.

+ +

So this is just a notice out there to anyone that's listening. If you got a bunch of webhook handling code in your app, maybe spot-check that you're actually verifying the payloads because it's possible that you're not. And that's a weird, very open hole in the side of your application.

+ +

STEPH: That's a really great point. I have not worked with webhooks recently. And in the past, I can't recall if that's something that I've really looked at closely. So I'm glad you shared that.

+ +

CHRIS: It's such an easy thing to skip. Like, it's one of those things that there's no way to enforce it. And so, I'd be interested in a survey that can't be done because this is all proprietary data. But what percentage of webhook integrations are unverified? Is it 50%? Is it 10%? Is it 100%? It's definitely not 100. But it's somewhere in there that I find interesting. It's not a terribly exploitable vulnerability because you have to have deep knowledge of the system.

+ +

In order to take advantage of it, you need to know what endpoint to hit to, what shape of data to send because otherwise, you're probably just going to cause an error or get a bunch of 404s. But like, it's, I don't know, it's discoverable. And yeah, it's an interesting one. So I will hop off my webhook soapbox now, but that's a thought.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

CHRIS: But now that I'm off my soapbox, I believe we have a topic that was suggested. Do you want to provide a little bit of context here, Steph?

+ +

STEPH: Yeah, I'd love to. So this came up when I was having a conversation with another thoughtboter. And given that we change projects fairly frequently, on the Boost team, we typically change projects around every six months. They asked a really thoughtful question that was "How do you get acquainted with a new codebase? So given that you're changing projects so often, what are some of the tips and tricks for ways that you've learned to then quickly get up to speed with a new codebase?" Because, frankly, that is one of the thoughtbot superpowers is that we are really good at onboarding each other and then also getting up to speed with a new team, and their processes, and their codebase.

+ +

So I have a couple of ideas, and then I'd love to hear some of your thoughts as well. So I'll dive in with a couple. So the first one, this one's frankly my favorite. Like day one, if there's a team where I'm joining and they have someone that can walk me through the application from the users' perspective, maybe it's someone that's in sales, or maybe it's someone on the product team, maybe it's a recording that they've already done for other people, but that's my first and favorite way to get to know an application.

+ +

I really want to know what are users experience as they're going through this app? That will help me focus on the more critical areas of the application based on usage. So if that's available, that's fabulous. I'm also going to tailor a lot of this more to like a Rails app since that's typically the type of project that I'm onboarding to. So the other types of questions that I like to find answers to are just like, what's my top-level structure? Like to look through the app and see how are things organized?

+ +

Chris, you've mentioned in a previous episode where you have your client structure that then highlights all the third-party clients that you're working with. Are we using engines in the app? Is there anything that seems a bit more unique to that application that I'm going to want to brush up on or look into? What's the test coverage like? Do they have something that's already highlighting how much test coverage they have? If not, is there something that then I can run locally that will then show me that test coverage?

+ +

I also really like to look at the routes file. That's one of my other favorite places because that also is very similar to getting an overview of the product. I get to see more from the user perspective. What are the common resources that people are going to, and what are the domain topics that I'm working with in this new application? I've got a couple more, but I'm going to pause there and see how you get acquainted with a new app.

+ +

CHRIS: Well, unsurprisingly, I agree with all of those. We're still searching for that dare to disagree beyond Pop-Tarts and IPAs situation. To reiterate or to emphasize some of the points you made, the sales demo thing? I absolutely love that one because, yes, absolutely. What's the most customer-centric point of view that I can have? Can I then login to a staging version of the site so I can poke around and hopefully not break anything or move real money or anything like that? But understanding why is this thing, not in code, but in actual practical, observable, intractable software?

+ +

Beyond that, your point about the routes, absolutely, that's one of my go-to's, although the routes there often is so much in the routes, and it's like some of those may actually be unused. So a corollary to the routes where available if there's an APM tool like Scout, or New Relic, or something like that, taking a look at that and seeing what are the heavily trafficked endpoints within this app? I like to think about it as the entry points into this codebase. So the routes file enumerates all of them, but some of them matter, and some of them don't.

+ +

And so, an APM tool can actually tell you which are the ones that are seeing a ton of traffic. That's a really interesting question for me. Similarly, if we're on Heroku, I might look is there a scheduler? And if so, what are the tasks that are running in the background? That's another entry point into the app. And so I like to think about it from that idea of entry points.

+ +

If it's not on Heroku, and then there's some other system, like, I've used Cronic. I think it's Cronic, Whenever the Cron thing. Whenever, that's what it is, the Whenever gem that allows you to implement that, but it's in a file within the codebase, which as an aside, I really love that that's committed and expressive in the code.

+ +

Then that's another interesting one to see. If it's more exotic than that, I may have to chase it down or ask someone, but I'll try and find what are all of the entry points and which are the ones that matter the most? I can drill down from there and see, okay, what code then supports these entry points into the application?

+ +

I want to give an answer that also includes something like, oh, I do fancy static analysis in the codebase, and I do a churn versus complexity graph, and I start to...but I never do that, if we're being honest. The thing that I do is after that initial cursory scan of the landscape, I try and work on something that is relatively through the layers of the app, so not like, oh, I'll fix the text in a button.

+ +

But like, give me something weird and ideally, let me pair with someone and then try and move through the layers of the app. So okay, here's our UI. We're rendering in this way. The controllers are integrated in this way, et cetera. This is our database. Try and get through all the layers if possible to try and get as holistic of a view of how the application works.

+ +

The other thing that I think is really interesting about what you just said is you're like, I'm going to give some answers that are somewhat specific to a Rails app. And that totally makes sense to me because I know how to answer this in the context of a Rails app because those organizational patterns are so useful that I can hop into different Rails apps. And I've certainly seen ones that I'm like, this is odd and unfamiliar to me, but most of them are so much more discoverable because of that consistency.

+ +

Whereas I have worked on a number of React apps, and every single one I come into, I'm like, okay, wait, what are we doing? How are we doing state management? What's the routing like? Are we server-side rendering, are we not? And it is a thing that...I see that community really moving in the direction of finding the meta frameworks that stitch the pieces together and provide more organizational structure and answer more of the questions out of the box.

+ +

But it continues to be something that I absolutely love about Rails is that Rails answers so many of the questions for me. New people joining the team are like, oh, it's a Rails app, cool. I know how to Rails, and we get to run with that. And so that's more of a pitch for Rails than an answer to the question, but it is a thing that I felt in answering this question. [laughs] But yeah, those are some thoughts. But interested, it sounds like you had some more as well. I would love to hear what else was in your mind when you were thinking about this.

+ +

STEPH: I do. And I want to highlight you said some really wonderful things. One that really stuck out to me that I had not considered is using Scout APM to look at heavily-trafficked endpoints. I have that on my list in regards as something that I want to know what's my error tracking, observability. Like, if I break something or if you give me a bug ticket to work on, what am I going to use? How am I going to understand what's going wrong? But I hadn't thought of it in terms of seeing which endpoints are heavily used. So I really liked that one.

+ +

I also liked how you highlighted that you wish you'd do something fancy around doing a churn versus complexity kind of graph because I thought of that too. I was like, oh, that would be such a nice answer. But the truth is I also don't do that. I think it's all those things. I think it would be fun to make it easy. So I do that with new applications. But I agree; I typically more just dive in like, hey, give me a ticket. Let me go from there.

+ +

I might do some simple command-line checking. So, for example, if I want to look through app models, let's find out which model is the largest. I may look for that to see do we have a God object or something like that? So I may look there. I just want to know how long are some of these files? But I also don't use a particular tool for that churn versus complexity.

+ +

CHRIS: I think you hit the nail on the head with like, I wish that were easier or more in our toolset. But here on The Bike Shed, we tell the truth. And that is aspirational code flexing that we do not yet have. But I agree, that would be a really nice way to explore exactly what you're describing of, like, who are the God models? I'll definitely do that check, but not some of the more subtle and sophisticated show me the change over time of all these...like nah, that's not what I'm doing, much as I would like to be able to answer that way.

+ +

STEPH: But it also feels like one of those areas like, it would be nice, but I would be intrigued to see how much I use that. That might be a nice anecdote to have. But I find the diving into the codebase to be more fruitful because I guess it depends on what I'm really looking at. Am I looking to see how complicated of a codebase this is? Because then I need to give more of a high-level review to someone to say how long I think it's going to take for me to work on a particular feature or before I'm joining a team, like, who do I think are good teammates that would then enjoy working on this application?

+ +

That feels like a very different question to me versus the I'm already part of the team. I'm here. We're going to have complexity and churn. So I can just learn some of that over time. I don't have to know that upfront. Although it may be nice to just know at a high level, say like, okay, if I pick up a ticket, and then I look at that churn and complexity, to be like, okay, my ticket falls right smack-dab in the middle of that. So it's going to be a fun first week. That could be a fun fact. But otherwise, I'm not sure. I mean, yeah, I'd be intrigued to see how much it helps me.

+ +

One other place that I do browse is I go to the gem file. I'm just always curious, what do people have in their tool bag? I want to see are there any gems that have been pulled in that are helping the team process some deprecated behavior? So something that's been pulled out of Rails but then pulled into a separate gem. So then that way, they don't have to upgrade just yet, or they can upgrade but then still keep some of that existing old deprecated behavior. That kind of stuff is interesting to me.

+ +

And also, you called it earlier pairing. That's my other favorite way. I want to hear how people talk about the codebase, how they navigate. What are they frustrated by? What brings them joy? All of that is really helpful too. I think that covers all the ways that I immediately will go to when getting acquainted with a new codebase.

+ +

CHRIS: I think that covers most of what I have in mind, although the question is framed in an interesting way that I think really speaks to the consultant mindset. How do I get acquainted with a new codebase? But if you take the question and flip it around sort of 180 degrees, I think the question can be reframed as how does an organization help people onboard into a codebase? And so everything we just described are like, here's what I do, here's how I would go about it, and pairing starts to get to collaboration.

+ +

I think we've talked in a number of episodes about our thoughts on onboarding and being intentional with that, pairing people up. A lot of things we described it's like, it's ideal actually if the organization is pushing this. And you and I both worked as consultants for long enough that we're really in the mindset of like, all right, let's assume I'm just showing up. There's no one else there. They give me a laptop and no documentation and no other humans I'm allowed to talk to. How do I figure this out and get the next feature out to production? And ideally, it's something slightly better than that that we experience, but we're ready for whatever it is.

+ +

Versus, most people are working within the context of an organization for a longer period of time. And most organizations should be thinking about it from the perspective of how do I help the new hires come into this codebase and become effective as quickly as possible? And so I think a lot of what we said can just be flipped around and said from the other way, like, pair them up, put them on a feature early, give them a walkthrough of the codebase, give them a sales-centric demo.

+ +

Yeah, I feel equally about those things when said from the other side, but I do want to emphasize that this shouldn't be you're out there in the middle of the jungle with only a machete, and you got to figure out this codebase. Ideally, the organization is actually like, no, no, we'll help you. It's ours, so we know it. We can help you find the weird stuff.

+ +

STEPH: That's a really nice distinction, though, because you're right; I hadn't really thought about this. I was thinking about this from more of the perspective of you're out in the jungle with a machete, minus we did mention pairing in there [laughs] and maybe a demo. I was approaching it more from you're isolated or more solo and then getting accustomed to the codebase versus if you have more people to lean on.

+ +

But then that also makes me think of all the other processes that I didn't mention that I would include in that onboarding that you're speaking of, of like, how does this team work in terms of where do I push my code? What hooks are going to run? And then what do I wait for? How many people need to review my code?

+ +

There are all those process-y questions that I think would ideally be included on the onboarding. But that has happened before, I mean, where we've joined projects, and it's been like, okay, good luck. Let us know if you need anything. And so then you do need those machete skills to then start hacking away. [laughs]

+ +

CHRIS: We've been burned before.

+ +

STEPH: They come in handy. [laughs] So when you are in that situation, and there's a comet that's coming to destroy earth, and there's a Rails application that is preventing this big doomsday, the question is, do you take astronauts and train them to be Rails experts, or do you take Rails developers and train them to be astronauts? I think that's the big question.

+ +

CHRIS: What would Michael Bay do?

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

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

+ +

Steph talks books perfect for vacations and feels sufficiently scarred regarding still working with moving fixtures over to FactoryBot.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: All right, I am now officially recording as well. Let me make sure my microphone is in front of my face.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Today is an interesting day. We are recording on a Friday, which is not normal for us, was normal for a long time and then stopped, but now it's back to being normal. But it's the morning, which is confusing. Also, I am traveling this evening. I leave on a flight going to Europe. So I'm going to do a red-eye, that whole thing. So I got a lot to pack into today, literally packing being one of those things.

+ +

And then this morning, because obviously, this is the way the world should play out, we started the day with an incident at Sagewell, a situation. Some code had gotten out there that was doing some stuff that we didn't want it to do. And so we had to sort of call in the dev team. And we all huddled together and tried to figure it out. Thankfully, it was a series of edge cases. It was sort of one of those perfect storms. So when this edge case happens in this context, then a bad thing could happen. Luckily, we were able to review the logs; nothing bad happened.

+ +

While I'm unhappy that we had this situation play out... basically, it was a caching thing, just to throw that out there. Caching turns out to be very hard. And the particular way it played out could have manifested in behavior that would have been not good in our system, or an admin would have inadvertently done something that would have been incorrect.

+ +

But on the positive side, we have an incident review process that we've been slowly incubating within the team. One of our team members introduced it to us, and then we've been using it on a few different cases. And it's really great to just have a structured process. I think it's one of those things that will grow over time. It's a very simple; what's the timeline of what happened? What's the story as to why it happened and why it wasn't caught earlier? What are the actions that we're going to take? And then what's the appendix? What's the data that we have around it? And so it's really great to just have that structure to work within.

+ +

And then similarly, as far as I can tell, the first even observable instance of this behavior in our system was yesterday morning. We saw it, started to respond to it, saw one more. We were able to chase it down in the logs. Overall, the combination of the alerting that we have in Sentry and the way in which we respond to the alerting in Sentry, which I think is probably the most critical part. Datadog is our log metrics tool right now. So we're able to go through Datadog, and we have Lograge configured to add more detail to our log lines.

+ +

And so we're able to see a very robust story of exactly what happened and ask the question, did anything actually bad happen? Or was it just possible that something bad could happen? And it turns out just possible. Nothing actually happened. We were able to determine that. We were even able to get a more detailed picture of who were all the users who potentially could have been impacted. Again, I don't think there was any impact.

+ +

But all total, it was both a very stressful process, especially as I'm about to go on vacation. It's like, oh cool, start to the day where I'm trying to wrap up things, and instead, we're going to spend a couple of hours chasing down an incident. But that said, these things will happen. The way in which we were able to respond, the alerting and observability that we had in place make me feel good.

+ +

STEPH: I like the incident structure that you just laid out. That sounds really nice in clarifying what happened when it happened in the logs. And the fact that you're able to go through and confirm if anything really bad happened or not is really nice. And I was also just debating this is one of those things, right? Right when you're about to go on vacation, that's when something's going to break. And that's like, is that good or bad? Is it good that I was here to take care of it right before, or is it bad? Because I'd really like to not be here to take care of it. [laughs] You may have mixed feelings. I have mixed feelings.

+ +

CHRIS: I think I'm happy. Unsurprisingly, this exists in one of the most complex parts of our codebase. And it involves caching. And I remember when we introduced the caching, I looked at it, and I was like, hmm, we have a performance hotspot that involves us making a lot of requests to an external system. And so we thought about it a little bit, and we were like, well, if we do a little bit of caching here, we can actually reduce that down from seven calls down to one over external HTTP. And so okay, that seems to make sense.

+ +

We had a pull request. We did a formal review. And even I looked at the pull request where this was introduced initially, and my comments on it were like, yep, this all looks good. Makes sense to me. But it's caching-related. So let's be very careful and look very closely at it and determine if there's anything, but it's so hard to know. And in fact, the code that actually was at play here was introduced a month ago.

+ +

And interestingly, the observable side effect only occurred in the past two days, which we find very surprising. But again, it's this weird like, if A happens and then within a short period after that B happens...and so it's not quite a race condition. But it was something where a lot of stuff had to happen in a short span of time for this to actually manifest. And so, again, we were able to look through the logs and see all of the instances where it could have happened and then what did happen. Everything was fine, but yeah, it was interesting.

+ +

I feel actually good to have seen it. And I think we've cleared everything up related to it and been very proactive in our response to it so that all feels good. And also, this is the sort of thing we've done this a few times now where we've had what I would call lesser incidents. There was no customer-facing impact to this. Similarly, previous incidents, we've had no or very minimal customer-facing impact.

+ +

So at one point, we had a situation where we weren't processing our background jobs for a little while. So we eventually caught up and did everything we needed to. It just meant that something may not have happened in as timely a fashion as necessary. But there were no deep ramifications to that.

+ +

But in each of those cases, we've pushed ourselves to go through the incident process to make sure that we're building the muscle as a team to like, actually, when the bad one comes, we want to be ready. We want to have done a couple of fire drills first. And so partly, I viewed this as that because again, there was smoke, but no fire is how we would describe it.

+ +

STEPH: Nice. And that also makes sense to me how you were saying y'all introduced this about a month ago, but you were just now seeing that observable side effect. I feel like that's also how it goes. Like, you implement, especially with caching, some performance improvement, and then you immediately see that. And it's like, yay, this is wonderful.

+ +

And then it's not til sometime passes that then you get that perfect storm of user interactions that then trigger some flow that you didn't consider or realize that could create an issue with that caching behavior. So yeah, that resonates. That seems right. All caching problems usually take about a month or two when you've just forgotten about what you've done. And then you have to go back in.

+ +

CHRIS: Yep. Yep, yep, yep. So now we've done the obvious thing, which is we've removed every cache from the system whatsoever. There are no caches anymore because it turns out we just can't be trusted with caches in any form whatsoever. ActiveRecord, we turned off caching, Redis we threw it out. No, I'm kidding. We still have lots of caching in the app. But, man, caching is so hard.

+ +

STEPH: I would love if that's in the project README where it says, "We can't be trusted with caches. No caches allowed." [laughs]

+ +

CHRIS: Yeah, we have not gone all the way to forbid caching within the application. It's a trade-off. But this does have that you get those scars over time. You have that incident that happens, and then forever you're like, no, no, no, we can't do X. And I feel like I'm just a collection of those. Again, I think we've talked about this in previous episodes. But consulting for as long as I did, I saw a lot of stuff. And a lot of it was not great. And so I basically just look at everything, and I'm like, urgh, no, this will be hard to maintain. This is going to go wrong. That's going to blow up someday.

+ +

And so, I'm having to work on trying to be a little more positive in my development work. But I do like that I have that inclination to be very cautious, be very pessimistic, assume the worst. I think it leads to safer code in general. There was actually a tweet by Sarah Drasner that was really wonderful. And it's basically a conversation between her and another developer. It's a pretend conversation. But it's like, "But why don't you like higher-order components?" And then it's Squints. "Well, in the summer of 2018, something bad happened, Takes a long drag of a cigarette. something very bad."

+ +

It's just written so well and captures the ethos just perfectly. Like, sit down. Let me tell you a tale of the time in 2018. [laughs] So I'll include a link to that in the show notes because she actually wrote it so well too. It's got like scene direction within a tweet and really fantastic stuff. But yeah, we'll allow some caching to continue within the app.

+ +

STEPH: That's amazing. So I was just thinking where you're talking about being more pessimistic versus optimistic. And there's an interesting nuance there for me because there's a difference in like if someone's pessimistic where if someone just brings up an idea and someone's like, "Nope, like, that's just not going to work," and they just always shoot it down, that level of being pessimistic is too much. And it's just going to prevent the team from having a collaborative and experimental environment.

+ +

But always asking the question of like, well, what's the worst that could happen? And what are the things that we should mitigate for? And what are the things that are probably so unlikely that we should just wait and see if that happens and then address it? That feels like a really nice balance. So it's not just leaning into saying no to everything. But sure, let's consider all the really bad things that could happen, make a plan for those, but still move forward with trying things out.

+ +

And I realized I do this in my own life, like when someone asks me a question around if there's something that we want to do that's a bit kind of risky. And the first thing I always think of is like, well, what's the worst that could happen? And I think that has confused people that I immediately go there because they think that I'm immediately saying no to the idea.

+ +

And so I have to explain like, no, no, no. I'm very intrigued, very interested. I just have to think through what's the worst that can happen. And if I'm okay with that, then I feel better about accepting it. But my emotional state, I have to think through what's the worst and then go from there.

+ +

CHRIS: Wow, it's a very bottom-up approach for your life planning there. [chuckles]

+ +

STEPH: Yep, I think that's, you know, it's from being a developer for so long. It has impacted now how I make other decisions. Good or bad? Who knows? Yeah, it turns out being a developer has leaked into my personal life. I've got leaky abstractions over here. So, good or bad? Who knows?

+ +

CHRIS: Leaky abstractions all the way down. Yeah, circling back to, like, I don't think I'm pessimistic per se. The way that I see this playing out often is there will be a discussion of an architectural approach, or there's a PR that goes up. And my reaction isn't no, or this has a known failure point; it is more of uh, this makes me uncomfortable. And it's that like; I can't even say exactly why, and that's what makes it so difficult.

+ +

And I think this is a place that can be really complicated for communication, particularly between developers who have been around for a little bit longer and have done this sort of thing and have gathered these battle scars and developers who are a bit newer. Having that conversation and being like, um, I can't say exactly why. I can tell you some weird stories. I might not even remember the stories. Some of it just feeds into just like, does this code make me uncomfortable? Or does this code make me happy? And I tend towards wildly explicit code for these reasons.

+ +

I want to make it as clear as possible and match as close as possible to the words that we're saying because I know that the bugs hide in the weird corners of our code. So I try and have as few corners. Make very rounded rooms of code is a weird analogy that doesn't play, but here we go. That's what I do on this show is I make weird analogies.

+ +

Actually, we were working on some code that was dealing with branching conditional things. So we had a record which has a boolean value on it. So we've got true or false, and then we've got two states, and then we've gotten an enum with three states. So all total, we have six possible states. But as we were going through this conversation, I was pairing with another developer on the team. And I was like, something feels weird here. And I actually invoked the name of Joël Quenneville because much of the data structure thought that I had here I associate with work that Joël has done around Maybe and things like that.

+ +

And then also, my suggestion was let's build a truth table because that seems like a fun way to manage this and look at it and see what's true. Because I know that there are spots on this two-by-three grid that should never happen. So let's name that and then put that in the code. We couldn't quite get it to map into the data type, like into that Boolean in the enum. Because it's possible to get into those states, but we never should. And therefore, we should alert and handle that and understand, like, how did this even happen? This should never happen.

+ +

And so we ended up taking what was a larger method body with some of the logic in it and collapsing it down to very explicitly enumerate the branches of the conditional and then feed out to a method. Like, call a method that had a very explicit name to say, okay, if it's true and we're in this enum state, then it's bad, alert bad. And then the other case like, handle the good case.

+ +

And I was very happy with what we refactored down to because this is another one of those very complex parts of our code. Critical infrastructure-y is how I would describe it. And so, in my mind, it was worth the I'm going to go with pathological refactoring that we got to there. But yes, I was channeling Joël in that moment. I'm very happy to have had many conversations with him that help me think through these things.

+ +

STEPH: That's awesome. Yeah, those truth tables can be so helpful. There's a particular article that, of course, Joël has written that then describes how a truth table works and ways that you can implement it into your habits. It's called Back to Basics: Boolean Expressions. I will be sure to include a link in the show notes.

+ +

CHRIS: But yeah, I think that summarizes my day and probably the next couple of days as I prepare for an adventure over to Europe and chat about developer spidey sense. But yeah, what's new in your world?

+ +

STEPH: Yeah, that's a big day. There's a lot going on. Well, I actually want to circle back because you mentioned that you're packing and you're going on this trip. And I'm curious, do you have any books queued up for vacation?

+ +

CHRIS: I do, yeah. I'm currently reading Elantris by Brandon Sanderson. Folks might be aware of his work from the highest-funded Kickstarter of all time, which was absurd. Did you see this happen?

+ +

STEPH: I don't think so, uh-uh.

+ +

CHRIS: He did this fun, cheeky little Kickstarter. The video was sort of a fake around...oh, it almost sounded like he might be retiring or something like that. And then he's like, JK, I wrote five new books. And so the Kickstarter was for those books with different tiered packages and whatnot. I think he got just the right viral coefficient going on. And apologies for the spoiler if anyone's not seen the video, but it's been out there for a while.

+ +

So he wrote some books, and that's what the Kickstarter is for. You get some books. You sort of join a book club, and you'll get one a quarter. A million dollars seems like that will be a bunch for that. That'd be great. If he raised a million dollars, that'd be amazing. $40 million four-zero million dollars. [laughs] I'm just watching it play out in real-time as well. It just skyrocketed up. The video, I think, was structured just right. He got it onto the...it was on Reddit and Twitter and just bouncing around, and people were sharing it. And just everything about it seemed to go perfectly. And yes, the highest-funded Kickstarter of all time, I believe, certainly within the publishing world.

+ +

But yeah, Brandon Sanderson, prolific author, and his stuff ends up just being kind of light and fun. And so I was reading Elantris for that. It's been a little bit slower to pick up than I would like. So I'm now in the latter half. I'm hoping it'll go a little bit more quickly and be...I'm just kind of looking for a fun read, some fantasy thing to go on an adventure.

+ +

But as the next book, I downloaded a second one just to make sure I'm covered. I have a book by John Scalzi, who's a sci-fi, fantasy, more on the sci-fi end of the spectrum. And I've read some of his other stuff and enjoyed it. And this particular book has a very consistent set of reviews. I've read the reviews a few times. And everybody who reviews it is just like, "This isn't the greatest book I've ever read, but man was it a fun ride." Or "Yeah, no, best book? No. Fun book? Yes." And just like, "This book was a fun ride. This was great." And I was like, perfect. That is exactly what I'm looking for on a European vacation.

+ +

The book is called The Kaiju Preservation Society, which also plays on monsters, Pacific Rim Godzilla. Kaiju, I think, is the word for that category of giant dinosaur-like monster. And so it's the Kaiju Preservation Society, which, I don't know, means some stuff, and I'm going to go on a fun adventure. So yeah, those are my books.

+ +

STEPH: Nice. I've got one that I'm reading right now. It's called Clementine: The Life of Mrs. Winston Churchill, written by Sonia Purnell. And Sonia Purnell tends to focus on female historical figures. And so it's historical fiction, which is a sweet spot for me. The only thing I'm debating on is because I'm realizing as I'm reading through it, I'm questioning, okay, well, what's real and what's not? Because I don't want to be that person that's like, did you know? And then, I quote this fictional fact about somebody that was made up for the novel. [laughs]

+ +

So I'm realizing that maybe historical fiction is fun, but then I'm having to fact-check all the things because then I'm just curious. I'm like, oh, did this really happen, or how did it go down? So it's been pretty good so far. But then it makes me wish that historical fiction novels had at the back of them they're like, these are all the events that were real versus some of the stuff that we fictionalized or added a little flair to. I'm in that interesting space.

+ +

I also like how you highlighted that you chose a fun book. I was having a conversation with a colleague recently about downtime. And like, do you consume more tech during downtime? Like, are you actively looking for technical blog posts or technical books to read or podcasts, things like that? And I was like, I don't. My downtime is for fun. Like, I want it to be all the things that are not tech.

+ +

Maybe some tech sneaks in there here and there, but for the most part, I definitely prioritize stuff that's fun over more technical content in my spare time, which has taken me a little while to not feel guilty about. Earlier in my career, I definitely felt like I should be crunching technical content all the time. And now I'm just like, nope, this is a job. I'm very thankful that I really enjoy my job, but it's still a job.

+ +

CHRIS: It is an interesting aspect of the world that we work in where that's even a question. In my previous life as a mechanical engineer, the idea that I would go home and read about mechanical engineering...I could attend a conference, but I would do that for very particular reasons and not because, like, oh, it's fun. I'll go meet my friends. For me, this was a big reason that I moved into tech because I am one of those folks who will, like, I will probably watch a video about Remix in particular because that's my new thing that I like to play around with and think about.

+ +

But it needs to be a particular shape of thing I've found. It needs to be exploratory, puzzle-y. Fun code, reading, learning work that I do needs to be separated from my work-work in a certain way. Otherwise, then it feels like work, then it is sort of a drudgery. But yeah, my brain just seems to really like the puzzle of programming and trying to build things. And being able to come into a world where people share as much as they do blogs and conference talks and all of that is utterly fantastic.

+ +

But it is a double-edged sword because I 100% agree that the ability to disconnect to, like, work a nine-to-five and then go home at the end of the day. Yeah, go home, you know, because you remember when we went to an office and then we would go home afterwards? I have to commute every once in a while into the city and --

+ +

STEPH: You mean go downstairs or go to another room? That's what you mean? [laughs]

+ +

CHRIS: I used to commute every day, and it took a lot of time. And now when I do it, I feel that so viscerally because I'm like, it's just a lot easier to just walk to my office in my house. But yes, I 100% I'm aligned to that like, yeah, no, you're done with work for the day, walk away. That's that.

+ +

And learning a new technology or things like that, that's part of the job. There shouldn't be the expectation that that just happens. There's continuing education in every other field. It's like, oh, we'll pay for your master's degree so you can go learn a thing. That's the norm in every other...not in every other industry but many, many, many industries.

+ +

And yet the nature of our world the accessibility of it is one of the most wonderful things about it. But it can be a double-edged sword in that if there are the expectations that, oh yeah, and then, of course, you're going to go home and have side projects and be learning things. Like, no, that is an unreasonable expectation, and we got to cut that off. But then again, I do do that. So I'm saying two things at the same time, and that's always complicated.

+ +

STEPH: But I agree with what you're saying because you're basically respecting both sides. If people enjoy this as a hobby, more power to you.; that's great. This is what you enjoy doing. If you don't want to do this as a hobby and respect it as a job, then that's also great too. There can be both sides, and no side should feel guilty or judged for whichever path that they pursue.

+ +

And I absolutely agree, if there are new skills that you need to learn for a job, then there should be time that's carved out during your work hours that then you get to focus on those new skills. It shouldn't be an expectation that then you're going to work all day and then spend your evening hours learning something else. And same for interviews; there shouldn't be a field that says, "Hey, what are your side projects?" Or at least that should not be an important part of the interview.

+ +

There should be an alternative to be like, "Or what work code do you want to talk about?" Or something else that's more in that nine-to-five window that you want to talk about. That way, there's a balance between like, sure, if you have something that you want to talk about on the side, great, but if not, then let's focus on something that you've done during your actual work hours because that's more realistic.

+ +

CHRIS: I do think there's an interesting aspect at play because the world of development moves so rapidly and because it's constantly changing. And to frame it differently, I don't think we've got this thing figured out. And so many people lament how quickly it changes and that there's a new framework every other week. And there's a bit of churn that is perhaps unnecessary.

+ +

But at the same time, I do not feel like as a community, as a working population, that we're like, yeah, got it, crushed it. We know how to make great software, no question about it. It's going to be awesome. We're going to be able to maintain it for forever, don't even worry about it. New feature? We can get that in there. They're actually still pretty rare.

+ +

So we need to be learning, and evolving, and exploring new techniques. I think the amount of thinking is probably good mostly in the development world. But organizations have to make space for that with their teams. And thoughtbot obviously does that with investment days. That's just such a wonderful structure that embraces that reality and also brings happiness, and it's just a pleasant way to work. And frankly, my team does not have that right now.

+ +

We do the crispy Brussels snack hour, which also now has a corresponding crispy Brussels work lunch, which is one week we think about it, and the next week we do the thing. We're trying to make space for that. But even that is still more intentional and purposeful and less exploratory and learning. And so it's an interesting trade-off. I deeply believe in this thing, and also, the team that I'm leading isn't doing it right now. Granted, we're an early-stage startup. We got to build a bunch of stuff. I think that's fine for right now. But it is a thing that...again, I'm saying two things at the same time, always fun.

+ +

STEPH: Well, and there might be a nice incremental approach to this as well. So thoughtbot has the entire day, and maybe it's less than a full day. So perhaps it's just there's an hour or two hours or something like that where you start to introduce some of that self-improvement time and then blossom out from there. Because yeah, I understand that not all teams may feel like they have the space for that.

+ +

But then I agree with everything else you said that it really does improve team morale and gives people a space to then be able to get to explore some of those questions that they had earlier. So then they don't feel like they have to then dedicate some weekend time or off hours’ time to then look into a question.

+ +

And I admit, I'm totally guilty too. I am that person that then I've worked extra hours, but it's because, like you said, if there's a puzzle that my brain is stuck on and I just feel the need to get through it. But then I look at that as am I doing this because I want to? Yes. Okay, then as long as I'm happy and I don't feel like this is increasing any concern around burnout, then I don't worry about it.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare… but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

Circling back to your original question about what's going on in my world, and you mentioned scarring earlier. I feel sufficiently scarred [laughs] in regards to still working with moving fixtures over to FactoryBot. This week has really confirmed that fixtures don't trigger a lot of the callbacks, the model callbacks that exist. And so this really means that you can just create bad data that your application doesn't actually allow your application to create.

+ +

So there are tests that are exercising behavior that should never exist. And then porting that over to FactoryBot then highlights that because then as soon as I move that record over and then try to create it or do something with it, then the app, the test, do the right thing and let me know saying no, no, no, we've added validations. You can't do that anymore. That has been grinding my gears in terms of trying to then translate. Because then I have to really dive into the code to understand it. And the goal here is to stay as high level as possible and not have to dive in too much. But then that means that I do have to dive in and understand more.

+ +

So this has frankly just been one of those times in my career where you just kind of have to slog through the work. It's important work to be done. It'll be great once it's done. But it's a painful process. And the best way that I've found to make it more enjoyable is to be in heavy communication with Joël, who's on the project with me, just so if we get stuck on something, then we can chat with each other.

+ +

And then also there's one file that's particularly gnarly. And so we moved over one test. We were successful, and which felt great because then we could at least document like, okay, when we come back to this, at least we have one example that highlights the wonkiness that we ran into. But we've decided, okay, we're done with that file. We're going to take a break. There's a lot there, but we're going to move on and give ourselves a break and do some of the easier ones, and then we'll circle back to the harder one.

+ +

Which was, I think, just a bit of bad luck in terms of, like, as we're going down the list, that happened to be like the gnarliest one, and it was like the first one that Joël picked up. And so I'm going through a couple of files, and Joël is like, "What? [laughs] How are you making progress?" And we realize it's just because that file, in particular, is very hard to find all the mystery guests and then to move everything over.

+ +

Finding a positive note through all of the cruft, I will say this is helping with some of my code sleuthing skills. So as I am running into these problems and then looking for mystery guests, I'm noticing ways that I can then, as quickly as possible, try to triage and identify as to why one test doesn't match another test. Some of it is more specific to the application setup, so it won't be as applicable to future projects. But then some other areas have been really helpful.

+ +

Like, I'm using caller a lot more to understand, like, I know this is getting called, but I don't know who's calling you. So I can put in a line that basically outputs like, show me your stack traces to how you got here. So that's been really nice as well. So it has improved some of my code sleuthing skills and also my spidey sense in terms of it's typically mystery guests.

+ +

Like when a test isn't passing, it's because fixtures are creating extra data that are getting pulled in when there are queries that are being run. But they're not explicitly referenced in the test setup itself. So that's typically then where I start is looking for what record looks relevant to this test that I haven't pulled over to my test setup.

+ +

CHRIS: I appreciate you finding the silver lining, the positive bit of this. Because as you're describing, the work that you're doing sounds like I think you use the word slog, which seems like a very accurate term. But sometimes we have to do that sometimes for a variety of reasons. We end up either having to introduce new code or fix old code, but this is sometimes the work.

+ +

And this is something that I think you and I share about this show is we get to show all sides of the work. And the work can be glamorous and new. And oh, I've got this greenfield app that I'm building, and it's wonderful. Look at the architecture. And I know in the moment that I'm building someone else's legacy code three years from now. [laughs]

+ +

And so telling the other side of the story and providing that rounded point of view, because like, yeah, this is all part of it. Again, I don't believe that this is a solved problem, building robust software that we can maintain. And so yeah, you're doing the good work in there. And I thank you for sharing it with us.

+ +

STEPH: Thanks. Just don't use fixtures in your test, I beg of you. Please don't do that to the legacy code that you're writing for future developers. [laughs] That is my one request.

+ +

CHRIS: And I will maybe add on to that, sparingly use callbacks. Maybe don't use them at all, and certainly don't use the combination because, my goodness, that'll lead you into some fun times. But yeah, just two small recommendations there.

+ +

STEPH: Oh, there's something else I wanted to share. I saw that Slack added a new audio feature that allows you to record the pronunciation of your name, which is the feature that I was so excited about when we added it to our internal tool called Hub at thoughtbot. And now Slack has it on their profile so that way you can upload the pronunciation. And then anyone looking at your profile can then listen to how to pronounce your name.

+ +

There are a couple of other features that they released, I think just in June, so about a month ago from the recording of today. [laughs] That's weird to say, but here we are. So I'll include a link in the show notes so folks can see that feature in addition to others, but I'm super excited.

+ +

CHRIS: Oh, that is nice. I also like all right, so Slack now has it. Hub now has it. But I don't have access to Hub anymore. And I don't have access to every Slack in the world yet. But here's my suggestion. All right, everybody, stick with me here. I want you to own a domain. I want you to have a personal site on it. And I want the personal site to include the pronunciation of your name.

+ +

I get that that's a big ask. And I get that there are other platforms that are calling to you, and you may be writing on those. But you know what? Just stand up a little site, just a little place on the internet that you own. And if it includes the pronunciation of your name, I will be forever grateful.

+ +

STEPH: I like this idea. I initially was taking your idea and immediately running with it as you were speaking it because then I wondered if everyone had their own YouTube channel. But I don't know how hard it is to create a YouTube channel. I am not a YouTube channeler, so I don't know what that looks like. [laughs] But not everybody will know how to purchase a domain. So that might be another approach.

+ +

CHRIS: I think it's pretty easy to do a YouTube channel. I'm conflating a couple of things. This is my basket of beliefs about people on the internet, but I kind of think everybody should own their own little slice of the internet. And so totally, YouTube is a place where the people make some stuff, make videos, put them on YouTube, absolutely. But ideally, you own something. I see a lot of people that are on YouTube, and that's it, and so their entire audience lives on YouTube. And if YouTube someday decides to change or remove them or say Medium as an example, Medium actually, I think, does a more interesting version of this where your identity kind of gets subsumed into Medium.

+ +

And I really think everybody should just have their own little, tiny slice of the internet that's there. It has their name that they own that no platform can decide; hey, we've shifted, and now your stuff is gone. Cool URIs don't change as they say, and that's what I want. And then yeah, if you can have the pronunciation of your name on there, that's extra nice.

+ +

Although I say that, and I don't know that I would do it because my name feels very obvious. One day someone was like, "Oh, how do you pronounce your last name?" I forget if I actually replied with the pronunciation. Or if I was like, "I need to know what options you're considering. I'm so interested because I've really only got the one." Maybe I'm anchored. Maybe I'm biased. [chuckles] I've been doing this for a while. But I really cannot think of another pronunciation of my name.

+ +

STEPH: You might hear another one that you really like, and you need to pivot.

+ +

CHRIS: Oh gosh.

+ +

STEPH: That's the point where you start pronouncing your name differently.

+ +

CHRIS: Wow, that would be a lot. And then, I could have a change log on my personal site where people can see this is the pronunciation, and this is what the pronunciation used to be.

+ +

STEPH: [laughs] I like this idea. I also like this idea that everybody has their own slice of internet land. I like this encouragement that you're providing for everyone.
+On a slightly different note, there's a blog post that I'm really excited to talk about. It's written by Eric Bailey, who's a former thoughtboter. It's called The Optics of Pair Programming. And given how much pair programming that I'm doing, especially with Joël on the current project, it was a really wonderful read.

+ +

And it also helped me think about pairing from a different perspective because we do have a very strong pairing culture at thoughtbot. So there's a lot of nuance, especially social nuances that can go along with when you invite someone to pair with you that I had not considered until I read this wonderful post by Eric. And we'll be sure to include a link in the show notes.

+ +

But to provide an overview, essentially, Eric shares that given coming from thoughtbot where we do have a very open approach to pairing where pairing sessions are voluntary and then also last as long as the problem will last...but then when you're at a new company, you could experience pushback if you're inviting someone to pair and then to consider why that pushback may exist. And some of the high-level areas that Eric highlighted are power dynamics, assessment, privacy, and learning styles.

+ +

So to dive into each of some of those, there's a power dynamics of it's important to consider who's offering to pair. So if I've joined a team as a consultant, there may be a power dynamic there that someone is feeling where their team is paying for my time. So they may feel like they can't say no if I offered to pair. They feel like they need to say yes to the invitation, even if they don't really want to.

+ +

Or probably a more classic example would be like, what if your boss wants to pair or someone that's just more senior than you? Then it could leave you feeling like, well, I can't say no to this person, can I? Which yes, you totally can say no to that person, but it may leave you in a place where you feel like you can't. And so, it puts you in this sort of uncomfortable and powerless position.

+ +

The other one is assessment, so offering to pair with someone could feel like you are implying that you want to assess their skills or that you're implying that they're not up to the task and therefore they need your help. So then that could also place someone in an uncomfortable position. There's also privacy. So someone who isn't confident may not want someone to observe their behavior or observe how they're working. It could make them feel really anxious, which then I love that Eric points this out.

+ +

Ironically, pairing is really good at addressing that lack of confidence because then you get to see how other people work through their problems or how they think, or they may also have some anxiety. Or it just helps you become more comfortable in talking and thinking through with other people. So that one is a tough one where it's hard to get over that initial hurdle. But actually, the more you pair, then the less anxious you'll feel when you pair.

+ +

And then there's also learning styles because pairing really involves a lot of deep thinking but in our personal time. And it can be hard to balance both of those, and it's just not as effective for some people. So I know that even as much as I really enjoy pairing, I just need to sit with code on my own sometimes. I need to think about it. I need to run it; I need to look at it.

+ +

So it's really nice to talk with someone. But then I also need that alone time to then just think through it on my own because I can't have that same deep focus if I'm also worried about how the other person is experiencing that session because then my mental energy is going towards them.

+ +

So that covers a number of the social nuances that can be included or running through someone's mind when you extend an invitation to them to pair. And it really resonated with me the areas that Eric highlights in this blog post. He also talks about a couple of strategies, which I'd love to dive into as well. But I'm going to pause here and see what thoughts you have.

+ +

CHRIS: Yeah, I love this post. And it got me thinking about pairing and the broader human backdrop of all of the processes and workflows that we have. Everything he highlighted about pairing feels true. Although similar to you and to Eric, I've worked in a context where pairing was a very natural, very regular part of the work and sort of from the very top-down. And so everyone pairing between developers of any different level or developers and designers or really anyone in the...it was just such a part of how we worked that no one really questioned it or at least not after the first couple of weeks.

+ +

I imagine joining thoughtbot those first weeks; you're like, oh God. As I shared, I think in the previous episode that we recorded, my pairing interview was with Joe Ferris, the CTO of thoughtbot, [laughs] writing a book about good and bad code. And I was like, I don't know what anything is here but very quickly getting over that hurdle. And having that normalizing experience was actually really great, and then have been comfortable with it since. But the idea that there are so many different social dynamics at play feels true.

+ +

And then as I think about other things, like stand-up is one that I think of as this very simple this is a way to communicate where we're at. And where necessary or where useful, allow people to interject or step in to say, "Oh, let me help you get unblocked there or whatever it is." But so often, I see stand-up being a ritual about demonstrating that you are, in fact, doing work, which is like, here's what I did yesterday. I don't know if it's useful. Then mention that you're working on this project. But the enumeration of look, obviously, work was done by me. You can see it; here are the receipts. It's very much this social dynamic at play.

+ +

And retro is another one where like, if retro is very much owned by one voice and not a place that change actually happens where people feel safe airing their opinions or their concerns, then it's going to be a terrible experience. But if you can structure it and enforce that it is a space that we can have a conversation, that everyone's voice is welcome and that real change happens as a result of, then it's a magical tool for making sure we're doing the right things. But always behind these are the people, and feelings, and the psychology at play. And so this was just such an interesting post to read and ruminate on that a little bit more.

+ +

STEPH: Yeah, I agree, especially with a comment that you made about those daily syncs where I really just want to focus on today and what you have that you're blocked on. So it's a really nice update in case there are any cross-collaboration opportunities. That's really what I'm looking for in a daily update. And so I appreciate when people don't go through a laundry list of what they did yesterday because it's like, that's great. But then, like you said, it's just like you're trying to prove here's what I've done, and I trust you; you're working. So just let me know what you're doing today, friend.

+ +

So Eric does a wonderful job of also including some strategies for ways that then you can address some of these concerns and then how there may be some extra anxiety that's increased when you're inviting somebody to pair. There are some wonderful strategies. I'll let folks read through the blog post itself.

+ +

There are a couple in particular that came to mind for me because I was then self-assessing how do I tend to approach pairing with someone? And some ways that I want them to feel very comfortable with that experience. And there's a couple. There's one where I recognize that I need to build trust with each person. I can't just go on to a team and expect everyone to know that I have good intentions and that I'm going to do my best to be a fun, helpful pairing partner, and that it's not a zone of judgment. And that has to be cultivated with each person.

+ +

Because especially as a consultant, if I'm joining a team, the people who hired me are not necessarily the people that I'm working with. It's someone that's probably in leadership or management that has then brought on thoughtbot. And so then the people that I'm working with they don't know me, and they don't know what my pairing style is going to be. So looking for ways to build trust with each person and then also inviting them or asking for help myself.

+ +

So there's a bit of vulnerability that has to be shown to build trust with someone to say," Hey, I'm stuck on a problem. I would love a second set of eyes. Would you be willing to help me out with this?" So then that way, they're coming in to help me initially versus I'm going in and saying, "Hey, can I help you?" I have found that to be an effective strategy.

+ +

And there's one that I do really want to talk about, and that's not everyone is going to pair well together. Like, you may find someone who always leaves you feeling just stressed or demoralized. And while it's important to consider your role and why that's true, that does not mean it's your fault and necessarily your problem to fix.

+ +

So similar to having to manage up, you may need to coach the person that you're pairing with in ways that help you feel comfortable pairing. But if they don't listen to your requests and implement any of that feedback, then just don't pair with that person. That is a very fine option to recognize people that are not receptive to your needs and, therefore, not someone that you need to then force into being a great pairing buddy.

+ +

And I emphasize that last one because it took me a little while to become comfortable with that and accepting that it wasn't my fault that I wasn't having a great pairing session with people. Similar to when I'm learning from someone that if someone is explaining something to me and they're making me feel inadequate while they're explaining it to me, that's not necessarily my fault. Like, I used to internalize that as like, oh, I just can't get this.

+ +

But I am now a very staunch believer in if you can't explain it to me in a way that I understand, then that's probably more on you than on me. And that has also taken me time to just really accept and embrace. But once you do, it is so freeing to realize that if someone's explaining a concept and you're still not getting it, it's like, hey, how can we try harder together versus you just making me try harder?

+ +

CHRIS: I like that right there of like, if I don't understand this, it may actually be you, not me, or something to that effect. Let's get that on a bumper sticker and put that in The Bike Shed store so that everybody can buy it and put it on their cars or at least just us. But yeah, that starting from the bottom sometimes it's just not going to work great. There are even...I think what you're describing sounds a little more complicated, individuals who are personally not great at communicating or pairing or things like that. And that's going to happen.

+ +

We're going to run into folks that...pairing is communication. That's just the core of it, and some folks, that may not be their strongest suit. But I think there's another category of just like different working styles. And whereas I might...judge is such a heavy word, but I'm going to use it. I might judge someone who is not doing a great job at communicating to someone else, or understanding their point of view, or striving to do that, or taking feedback. Like, those are not great things.

+ +

Whereas there may just be two different development styles or backgrounds, or there are other reasons that actually they may be not an ideal fit. That said, I have definitely found that in almost every variation of pairing, I've seen work at some point. Like, when I was very early on in my career pairing with folks that are very senior, I didn't get most of it, but I got some stuff. And then folks that are very much on the same level or folks that have a deep knowledge in framework, code base language, whatever and folks that are new to it but have a different set of experiences.

+ +

Basically, every version of that, I found that pairing is actually an incredibly powerful technique for knowledge sharing, for collaboration, for all of that. So although there are rare cases where there might be some misalignment, in general, I think pairing can work.

+ +

I do think you hit on something earlier of there are certain folks that are more private thinkers, is how I would describe it, where thinking out loud is complicated for them. I'm very much someone who talks. That's how I figure out what I think is I say stuff. And I'm like, oh, I agree with what I just said. That's good. But I find I actually struggle. There's something I think of...maybe I'm just a loudmouth is what I'm hearing as I say it, but that is how I process things. Other folks, that is not true.

+Other folks, it's quite internal, and actually trying to vocalize that or trying to share the thought process as they're going may be uncomfortable. And I think that's perfectly reasonable and something that we should recognize and make space for. And so pairing should not be forced upon a team or an individual because there are just different mindsets, different ways of thinking that we need to account for.

+ +

But again, the vast majority of cases...I've seen plenty of cases where it's someone's like, "I don't like to pair. That's not my thing." And it's actually that they've had bad experiences. And then when they find a space that feels safe or they see the pattern demonstrated in a way that is collegial, and useful, and friendly, then they're like, oh, actually, I thought I didn't like pairing. I thought I didn't like retro. I thought I didn't like stand-up. But actually, all of these things can be good.

+ +

STEPH: Yeah, absolutely. It's a skill like anything else. You need to see value in it. And if you haven't seen value in it yet or if it's always made you anxious and uncomfortable, then it's something that you're going to avoid as much as possible until someone can provide a valuable, positive experience around how it can go.

+ +

I'm going to pull back the curtains just a little bit on our recording and share because you've mentioned that you are very much you think out loud, and that's how you decide that you agree with yourself. And I think already at least twice while we've been recording this episode, I have started to say something, and I'm like, no, wait, I don't agree with that and have backed myself up.

+ +

CHRIS: [laughs]

+ +

STEPH: And I'm like, no, I just thought through it; I'm going to cancel it out, [laughs] and then moved in a different direction. So I, too, seem to be someone that I start to say things, and I'm like, oh, wait, I don't actually agree with what I just said [laughs], so let's remove that.

+ +

CHRIS: Yep. You've described it as Michael Scott-ing on a handful of different episodes or maybe things that were cut from episodes. But where you start a sentence and then you're like, I don't know where I was going to end up there. I hoped I'd figure it out by the end, but then I did not get there. And yeah, I think we've all experienced that at various times.

+ +

STEPH: That’s some of my favorite advice from you is where you've been like, just lean into it, just see where it goes. Finish it out. We can always take it out later. [laughs] Because I stop myself because I immediately start editing what I'm trying to say and you're like, "No, no, just finish it, and then we'll see what happens." That's been fun.

+ +

CHRIS: This is how you find out what you think. You say it out loud, and then you're like, never mind. That was ridic –

+ +

STEPH: [laughs]

+ +

CHRIS: I do. Actually, now I'm thinking back, and I have plenty of those where I'll say a thing, and I'm like, nope, never mind, send that one back. [chuckles] As an aside, so we do this thing where we host a podcast, and we get to talk. But we're both now describing the pattern where we'll start to say something, and we’ll be like no, no, no, actually, not that. And I think, dear listeners out there, you probably don't hear any of this, the vast majority of it, because we have wonderful editors behind the scenes, Thom Obarski for many years, and now Mandy Moore, who's been with us for a while.

+ +

And so once again, thank you so much to the editor team that allows us to, I think, again, feel safe in this conversation that we can say whatever feels true and then know that we'll be able to switch that around. So thank you so much to the editors who help us out and make us sound better than we are.

+ +

STEPH: Yeah, that has made a big difference in my capabilities to podcast. If we were doing this live, ooh goodness, this might be a whole different, weird show. [laughs]

+ +

CHRIS: I mean, the same is true for code, right? I deeply value the ability to make an absolute mess in my local editor and have nine different commits that eventually I throw two out. And then I revert that file, and then eventually, the PR that I put up that's my Instagram selfie. That's like, I carefully curated this, but what's behind the scenes it's just a pile of trash. So yeah, the ability to separate the creation and the editing that's a meaningful thing to have in life.

+ +

STEPH: Oh, I can't unsee that now. [laughs] A pull request is now the equivalent of that curated Instagram selfie. That is beautiful. [laughs]

+ +

CHRIS: To be clear, I don't think I've ever taken an Instagram selfie. But I get the idea, and I felt like it was an analogy that would work. Again, I try out analogies on this show, and many of them do not stick. But I think that one is all right.

+ +

STEPH: It might even go back to pairing because then you've got help in taking that picture. So hey, you're making a mess with somebody until you get that right perfect thing, and then you push it up for the world to see. So safe spaces for all the activities, I think that's the takeaway. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris is getting ready to travel, and of course, Sagewell started the day with an incident, a situation, if you will...

+ +

Steph talks books perfect for vacations and feels sufficiently scarred regarding still working with moving fixtures over to FactoryBot.

+ +
+ +

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: All right, I am now officially recording as well. Let me make sure my microphone is in front of my face.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Today is an interesting day. We are recording on a Friday, which is not normal for us, was normal for a long time and then stopped, but now it's back to being normal. But it's the morning, which is confusing. Also, I am traveling this evening. I leave on a flight going to Europe. So I'm going to do a red-eye, that whole thing. So I got a lot to pack into today, literally packing being one of those things.

+ +

And then this morning, because obviously, this is the way the world should play out, we started the day with an incident at Sagewell, a situation. Some code had gotten out there that was doing some stuff that we didn't want it to do. And so we had to sort of call in the dev team. And we all huddled together and tried to figure it out. Thankfully, it was a series of edge cases. It was sort of one of those perfect storms. So when this edge case happens in this context, then a bad thing could happen. Luckily, we were able to review the logs; nothing bad happened.

+ +

While I'm unhappy that we had this situation play out... basically, it was a caching thing, just to throw that out there. Caching turns out to be very hard. And the particular way it played out could have manifested in behavior that would have been not good in our system, or an admin would have inadvertently done something that would have been incorrect.

+ +

But on the positive side, we have an incident review process that we've been slowly incubating within the team. One of our team members introduced it to us, and then we've been using it on a few different cases. And it's really great to just have a structured process. I think it's one of those things that will grow over time. It's a very simple; what's the timeline of what happened? What's the story as to why it happened and why it wasn't caught earlier? What are the actions that we're going to take? And then what's the appendix? What's the data that we have around it? And so it's really great to just have that structure to work within.

+ +

And then similarly, as far as I can tell, the first even observable instance of this behavior in our system was yesterday morning. We saw it, started to respond to it, saw one more. We were able to chase it down in the logs. Overall, the combination of the alerting that we have in Sentry and the way in which we respond to the alerting in Sentry, which I think is probably the most critical part. Datadog is our log metrics tool right now. So we're able to go through Datadog, and we have Lograge configured to add more detail to our log lines.

+ +

And so we're able to see a very robust story of exactly what happened and ask the question, did anything actually bad happen? Or was it just possible that something bad could happen? And it turns out just possible. Nothing actually happened. We were able to determine that. We were even able to get a more detailed picture of who were all the users who potentially could have been impacted. Again, I don't think there was any impact.

+ +

But all total, it was both a very stressful process, especially as I'm about to go on vacation. It's like, oh cool, start to the day where I'm trying to wrap up things, and instead, we're going to spend a couple of hours chasing down an incident. But that said, these things will happen. The way in which we were able to respond, the alerting and observability that we had in place make me feel good.

+ +

STEPH: I like the incident structure that you just laid out. That sounds really nice in clarifying what happened when it happened in the logs. And the fact that you're able to go through and confirm if anything really bad happened or not is really nice. And I was also just debating this is one of those things, right? Right when you're about to go on vacation, that's when something's going to break. And that's like, is that good or bad? Is it good that I was here to take care of it right before, or is it bad? Because I'd really like to not be here to take care of it. [laughs] You may have mixed feelings. I have mixed feelings.

+ +

CHRIS: I think I'm happy. Unsurprisingly, this exists in one of the most complex parts of our codebase. And it involves caching. And I remember when we introduced the caching, I looked at it, and I was like, hmm, we have a performance hotspot that involves us making a lot of requests to an external system. And so we thought about it a little bit, and we were like, well, if we do a little bit of caching here, we can actually reduce that down from seven calls down to one over external HTTP. And so okay, that seems to make sense.

+ +

We had a pull request. We did a formal review. And even I looked at the pull request where this was introduced initially, and my comments on it were like, yep, this all looks good. Makes sense to me. But it's caching-related. So let's be very careful and look very closely at it and determine if there's anything, but it's so hard to know. And in fact, the code that actually was at play here was introduced a month ago.

+ +

And interestingly, the observable side effect only occurred in the past two days, which we find very surprising. But again, it's this weird like, if A happens and then within a short period after that B happens...and so it's not quite a race condition. But it was something where a lot of stuff had to happen in a short span of time for this to actually manifest. And so, again, we were able to look through the logs and see all of the instances where it could have happened and then what did happen. Everything was fine, but yeah, it was interesting.

+ +

I feel actually good to have seen it. And I think we've cleared everything up related to it and been very proactive in our response to it so that all feels good. And also, this is the sort of thing we've done this a few times now where we've had what I would call lesser incidents. There was no customer-facing impact to this. Similarly, previous incidents, we've had no or very minimal customer-facing impact.

+ +

So at one point, we had a situation where we weren't processing our background jobs for a little while. So we eventually caught up and did everything we needed to. It just meant that something may not have happened in as timely a fashion as necessary. But there were no deep ramifications to that.

+ +

But in each of those cases, we've pushed ourselves to go through the incident process to make sure that we're building the muscle as a team to like, actually, when the bad one comes, we want to be ready. We want to have done a couple of fire drills first. And so partly, I viewed this as that because again, there was smoke, but no fire is how we would describe it.

+ +

STEPH: Nice. And that also makes sense to me how you were saying y'all introduced this about a month ago, but you were just now seeing that observable side effect. I feel like that's also how it goes. Like, you implement, especially with caching, some performance improvement, and then you immediately see that. And it's like, yay, this is wonderful.

+ +

And then it's not til sometime passes that then you get that perfect storm of user interactions that then trigger some flow that you didn't consider or realize that could create an issue with that caching behavior. So yeah, that resonates. That seems right. All caching problems usually take about a month or two when you've just forgotten about what you've done. And then you have to go back in.

+ +

CHRIS: Yep. Yep, yep, yep. So now we've done the obvious thing, which is we've removed every cache from the system whatsoever. There are no caches anymore because it turns out we just can't be trusted with caches in any form whatsoever. ActiveRecord, we turned off caching, Redis we threw it out. No, I'm kidding. We still have lots of caching in the app. But, man, caching is so hard.

+ +

STEPH: I would love if that's in the project README where it says, "We can't be trusted with caches. No caches allowed." [laughs]

+ +

CHRIS: Yeah, we have not gone all the way to forbid caching within the application. It's a trade-off. But this does have that you get those scars over time. You have that incident that happens, and then forever you're like, no, no, no, we can't do X. And I feel like I'm just a collection of those. Again, I think we've talked about this in previous episodes. But consulting for as long as I did, I saw a lot of stuff. And a lot of it was not great. And so I basically just look at everything, and I'm like, urgh, no, this will be hard to maintain. This is going to go wrong. That's going to blow up someday.

+ +

And so, I'm having to work on trying to be a little more positive in my development work. But I do like that I have that inclination to be very cautious, be very pessimistic, assume the worst. I think it leads to safer code in general. There was actually a tweet by Sarah Drasner that was really wonderful. And it's basically a conversation between her and another developer. It's a pretend conversation. But it's like, "But why don't you like higher-order components?" And then it's Squints. "Well, in the summer of 2018, something bad happened, Takes a long drag of a cigarette. something very bad."

+ +

It's just written so well and captures the ethos just perfectly. Like, sit down. Let me tell you a tale of the time in 2018. [laughs] So I'll include a link to that in the show notes because she actually wrote it so well too. It's got like scene direction within a tweet and really fantastic stuff. But yeah, we'll allow some caching to continue within the app.

+ +

STEPH: That's amazing. So I was just thinking where you're talking about being more pessimistic versus optimistic. And there's an interesting nuance there for me because there's a difference in like if someone's pessimistic where if someone just brings up an idea and someone's like, "Nope, like, that's just not going to work," and they just always shoot it down, that level of being pessimistic is too much. And it's just going to prevent the team from having a collaborative and experimental environment.

+ +

But always asking the question of like, well, what's the worst that could happen? And what are the things that we should mitigate for? And what are the things that are probably so unlikely that we should just wait and see if that happens and then address it? That feels like a really nice balance. So it's not just leaning into saying no to everything. But sure, let's consider all the really bad things that could happen, make a plan for those, but still move forward with trying things out.

+ +

And I realized I do this in my own life, like when someone asks me a question around if there's something that we want to do that's a bit kind of risky. And the first thing I always think of is like, well, what's the worst that could happen? And I think that has confused people that I immediately go there because they think that I'm immediately saying no to the idea.

+ +

And so I have to explain like, no, no, no. I'm very intrigued, very interested. I just have to think through what's the worst that can happen. And if I'm okay with that, then I feel better about accepting it. But my emotional state, I have to think through what's the worst and then go from there.

+ +

CHRIS: Wow, it's a very bottom-up approach for your life planning there. [chuckles]

+ +

STEPH: Yep, I think that's, you know, it's from being a developer for so long. It has impacted now how I make other decisions. Good or bad? Who knows? Yeah, it turns out being a developer has leaked into my personal life. I've got leaky abstractions over here. So, good or bad? Who knows?

+ +

CHRIS: Leaky abstractions all the way down. Yeah, circling back to, like, I don't think I'm pessimistic per se. The way that I see this playing out often is there will be a discussion of an architectural approach, or there's a PR that goes up. And my reaction isn't no, or this has a known failure point; it is more of uh, this makes me uncomfortable. And it's that like; I can't even say exactly why, and that's what makes it so difficult.

+ +

And I think this is a place that can be really complicated for communication, particularly between developers who have been around for a little bit longer and have done this sort of thing and have gathered these battle scars and developers who are a bit newer. Having that conversation and being like, um, I can't say exactly why. I can tell you some weird stories. I might not even remember the stories. Some of it just feeds into just like, does this code make me uncomfortable? Or does this code make me happy? And I tend towards wildly explicit code for these reasons.

+ +

I want to make it as clear as possible and match as close as possible to the words that we're saying because I know that the bugs hide in the weird corners of our code. So I try and have as few corners. Make very rounded rooms of code is a weird analogy that doesn't play, but here we go. That's what I do on this show is I make weird analogies.

+ +

Actually, we were working on some code that was dealing with branching conditional things. So we had a record which has a boolean value on it. So we've got true or false, and then we've got two states, and then we've gotten an enum with three states. So all total, we have six possible states. But as we were going through this conversation, I was pairing with another developer on the team. And I was like, something feels weird here. And I actually invoked the name of Joël Quenneville because much of the data structure thought that I had here I associate with work that Joël has done around Maybe and things like that.

+ +

And then also, my suggestion was let's build a truth table because that seems like a fun way to manage this and look at it and see what's true. Because I know that there are spots on this two-by-three grid that should never happen. So let's name that and then put that in the code. We couldn't quite get it to map into the data type, like into that Boolean in the enum. Because it's possible to get into those states, but we never should. And therefore, we should alert and handle that and understand, like, how did this even happen? This should never happen.

+ +

And so we ended up taking what was a larger method body with some of the logic in it and collapsing it down to very explicitly enumerate the branches of the conditional and then feed out to a method. Like, call a method that had a very explicit name to say, okay, if it's true and we're in this enum state, then it's bad, alert bad. And then the other case like, handle the good case.

+ +

And I was very happy with what we refactored down to because this is another one of those very complex parts of our code. Critical infrastructure-y is how I would describe it. And so, in my mind, it was worth the I'm going to go with pathological refactoring that we got to there. But yes, I was channeling Joël in that moment. I'm very happy to have had many conversations with him that help me think through these things.

+ +

STEPH: That's awesome. Yeah, those truth tables can be so helpful. There's a particular article that, of course, Joël has written that then describes how a truth table works and ways that you can implement it into your habits. It's called Back to Basics: Boolean Expressions. I will be sure to include a link in the show notes.

+ +

CHRIS: But yeah, I think that summarizes my day and probably the next couple of days as I prepare for an adventure over to Europe and chat about developer spidey sense. But yeah, what's new in your world?

+ +

STEPH: Yeah, that's a big day. There's a lot going on. Well, I actually want to circle back because you mentioned that you're packing and you're going on this trip. And I'm curious, do you have any books queued up for vacation?

+ +

CHRIS: I do, yeah. I'm currently reading Elantris by Brandon Sanderson. Folks might be aware of his work from the highest-funded Kickstarter of all time, which was absurd. Did you see this happen?

+ +

STEPH: I don't think so, uh-uh.

+ +

CHRIS: He did this fun, cheeky little Kickstarter. The video was sort of a fake around...oh, it almost sounded like he might be retiring or something like that. And then he's like, JK, I wrote five new books. And so the Kickstarter was for those books with different tiered packages and whatnot. I think he got just the right viral coefficient going on. And apologies for the spoiler if anyone's not seen the video, but it's been out there for a while.

+ +

So he wrote some books, and that's what the Kickstarter is for. You get some books. You sort of join a book club, and you'll get one a quarter. A million dollars seems like that will be a bunch for that. That'd be great. If he raised a million dollars, that'd be amazing. $40 million four-zero million dollars. [laughs] I'm just watching it play out in real-time as well. It just skyrocketed up. The video, I think, was structured just right. He got it onto the...it was on Reddit and Twitter and just bouncing around, and people were sharing it. And just everything about it seemed to go perfectly. And yes, the highest-funded Kickstarter of all time, I believe, certainly within the publishing world.

+ +

But yeah, Brandon Sanderson, prolific author, and his stuff ends up just being kind of light and fun. And so I was reading Elantris for that. It's been a little bit slower to pick up than I would like. So I'm now in the latter half. I'm hoping it'll go a little bit more quickly and be...I'm just kind of looking for a fun read, some fantasy thing to go on an adventure.

+ +

But as the next book, I downloaded a second one just to make sure I'm covered. I have a book by John Scalzi, who's a sci-fi, fantasy, more on the sci-fi end of the spectrum. And I've read some of his other stuff and enjoyed it. And this particular book has a very consistent set of reviews. I've read the reviews a few times. And everybody who reviews it is just like, "This isn't the greatest book I've ever read, but man was it a fun ride." Or "Yeah, no, best book? No. Fun book? Yes." And just like, "This book was a fun ride. This was great." And I was like, perfect. That is exactly what I'm looking for on a European vacation.

+ +

The book is called The Kaiju Preservation Society, which also plays on monsters, Pacific Rim Godzilla. Kaiju, I think, is the word for that category of giant dinosaur-like monster. And so it's the Kaiju Preservation Society, which, I don't know, means some stuff, and I'm going to go on a fun adventure. So yeah, those are my books.

+ +

STEPH: Nice. I've got one that I'm reading right now. It's called Clementine: The Life of Mrs. Winston Churchill, written by Sonia Purnell. And Sonia Purnell tends to focus on female historical figures. And so it's historical fiction, which is a sweet spot for me. The only thing I'm debating on is because I'm realizing as I'm reading through it, I'm questioning, okay, well, what's real and what's not? Because I don't want to be that person that's like, did you know? And then, I quote this fictional fact about somebody that was made up for the novel. [laughs]

+ +

So I'm realizing that maybe historical fiction is fun, but then I'm having to fact-check all the things because then I'm just curious. I'm like, oh, did this really happen, or how did it go down? So it's been pretty good so far. But then it makes me wish that historical fiction novels had at the back of them they're like, these are all the events that were real versus some of the stuff that we fictionalized or added a little flair to. I'm in that interesting space.

+ +

I also like how you highlighted that you chose a fun book. I was having a conversation with a colleague recently about downtime. And like, do you consume more tech during downtime? Like, are you actively looking for technical blog posts or technical books to read or podcasts, things like that? And I was like, I don't. My downtime is for fun. Like, I want it to be all the things that are not tech.

+ +

Maybe some tech sneaks in there here and there, but for the most part, I definitely prioritize stuff that's fun over more technical content in my spare time, which has taken me a little while to not feel guilty about. Earlier in my career, I definitely felt like I should be crunching technical content all the time. And now I'm just like, nope, this is a job. I'm very thankful that I really enjoy my job, but it's still a job.

+ +

CHRIS: It is an interesting aspect of the world that we work in where that's even a question. In my previous life as a mechanical engineer, the idea that I would go home and read about mechanical engineering...I could attend a conference, but I would do that for very particular reasons and not because, like, oh, it's fun. I'll go meet my friends. For me, this was a big reason that I moved into tech because I am one of those folks who will, like, I will probably watch a video about Remix in particular because that's my new thing that I like to play around with and think about.

+ +

But it needs to be a particular shape of thing I've found. It needs to be exploratory, puzzle-y. Fun code, reading, learning work that I do needs to be separated from my work-work in a certain way. Otherwise, then it feels like work, then it is sort of a drudgery. But yeah, my brain just seems to really like the puzzle of programming and trying to build things. And being able to come into a world where people share as much as they do blogs and conference talks and all of that is utterly fantastic.

+ +

But it is a double-edged sword because I 100% agree that the ability to disconnect to, like, work a nine-to-five and then go home at the end of the day. Yeah, go home, you know, because you remember when we went to an office and then we would go home afterwards? I have to commute every once in a while into the city and --

+ +

STEPH: You mean go downstairs or go to another room? That's what you mean? [laughs]

+ +

CHRIS: I used to commute every day, and it took a lot of time. And now when I do it, I feel that so viscerally because I'm like, it's just a lot easier to just walk to my office in my house. But yes, I 100% I'm aligned to that like, yeah, no, you're done with work for the day, walk away. That's that.

+ +

And learning a new technology or things like that, that's part of the job. There shouldn't be the expectation that that just happens. There's continuing education in every other field. It's like, oh, we'll pay for your master's degree so you can go learn a thing. That's the norm in every other...not in every other industry but many, many, many industries.

+ +

And yet the nature of our world the accessibility of it is one of the most wonderful things about it. But it can be a double-edged sword in that if there are the expectations that, oh yeah, and then, of course, you're going to go home and have side projects and be learning things. Like, no, that is an unreasonable expectation, and we got to cut that off. But then again, I do do that. So I'm saying two things at the same time, and that's always complicated.

+ +

STEPH: But I agree with what you're saying because you're basically respecting both sides. If people enjoy this as a hobby, more power to you.; that's great. This is what you enjoy doing. If you don't want to do this as a hobby and respect it as a job, then that's also great too. There can be both sides, and no side should feel guilty or judged for whichever path that they pursue.

+ +

And I absolutely agree, if there are new skills that you need to learn for a job, then there should be time that's carved out during your work hours that then you get to focus on those new skills. It shouldn't be an expectation that then you're going to work all day and then spend your evening hours learning something else. And same for interviews; there shouldn't be a field that says, "Hey, what are your side projects?" Or at least that should not be an important part of the interview.

+ +

There should be an alternative to be like, "Or what work code do you want to talk about?" Or something else that's more in that nine-to-five window that you want to talk about. That way, there's a balance between like, sure, if you have something that you want to talk about on the side, great, but if not, then let's focus on something that you've done during your actual work hours because that's more realistic.

+ +

CHRIS: I do think there's an interesting aspect at play because the world of development moves so rapidly and because it's constantly changing. And to frame it differently, I don't think we've got this thing figured out. And so many people lament how quickly it changes and that there's a new framework every other week. And there's a bit of churn that is perhaps unnecessary.

+ +

But at the same time, I do not feel like as a community, as a working population, that we're like, yeah, got it, crushed it. We know how to make great software, no question about it. It's going to be awesome. We're going to be able to maintain it for forever, don't even worry about it. New feature? We can get that in there. They're actually still pretty rare.

+ +

So we need to be learning, and evolving, and exploring new techniques. I think the amount of thinking is probably good mostly in the development world. But organizations have to make space for that with their teams. And thoughtbot obviously does that with investment days. That's just such a wonderful structure that embraces that reality and also brings happiness, and it's just a pleasant way to work. And frankly, my team does not have that right now.

+ +

We do the crispy Brussels snack hour, which also now has a corresponding crispy Brussels work lunch, which is one week we think about it, and the next week we do the thing. We're trying to make space for that. But even that is still more intentional and purposeful and less exploratory and learning. And so it's an interesting trade-off. I deeply believe in this thing, and also, the team that I'm leading isn't doing it right now. Granted, we're an early-stage startup. We got to build a bunch of stuff. I think that's fine for right now. But it is a thing that...again, I'm saying two things at the same time, always fun.

+ +

STEPH: Well, and there might be a nice incremental approach to this as well. So thoughtbot has the entire day, and maybe it's less than a full day. So perhaps it's just there's an hour or two hours or something like that where you start to introduce some of that self-improvement time and then blossom out from there. Because yeah, I understand that not all teams may feel like they have the space for that.

+ +

But then I agree with everything else you said that it really does improve team morale and gives people a space to then be able to get to explore some of those questions that they had earlier. So then they don't feel like they have to then dedicate some weekend time or off hours’ time to then look into a question.

+ +

And I admit, I'm totally guilty too. I am that person that then I've worked extra hours, but it's because, like you said, if there's a puzzle that my brain is stuck on and I just feel the need to get through it. But then I look at that as am I doing this because I want to? Yes. Okay, then as long as I'm happy and I don't feel like this is increasing any concern around burnout, then I don't worry about it.

+ +

MIDROLL AD:

+ +

Debugging errors can be a developer’s worst nightmare… but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help you cut your debugging time in half.

+ +

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

+ +

Airbrake’s debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

+ +

In addition to stellar error monitoring, Airbrake’s lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

+ +

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

+ +

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

+ +

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

+ +

Circling back to your original question about what's going on in my world, and you mentioned scarring earlier. I feel sufficiently scarred [laughs] in regards to still working with moving fixtures over to FactoryBot. This week has really confirmed that fixtures don't trigger a lot of the callbacks, the model callbacks that exist. And so this really means that you can just create bad data that your application doesn't actually allow your application to create.

+ +

So there are tests that are exercising behavior that should never exist. And then porting that over to FactoryBot then highlights that because then as soon as I move that record over and then try to create it or do something with it, then the app, the test, do the right thing and let me know saying no, no, no, we've added validations. You can't do that anymore. That has been grinding my gears in terms of trying to then translate. Because then I have to really dive into the code to understand it. And the goal here is to stay as high level as possible and not have to dive in too much. But then that means that I do have to dive in and understand more.

+ +

So this has frankly just been one of those times in my career where you just kind of have to slog through the work. It's important work to be done. It'll be great once it's done. But it's a painful process. And the best way that I've found to make it more enjoyable is to be in heavy communication with Joël, who's on the project with me, just so if we get stuck on something, then we can chat with each other.

+ +

And then also there's one file that's particularly gnarly. And so we moved over one test. We were successful, and which felt great because then we could at least document like, okay, when we come back to this, at least we have one example that highlights the wonkiness that we ran into. But we've decided, okay, we're done with that file. We're going to take a break. There's a lot there, but we're going to move on and give ourselves a break and do some of the easier ones, and then we'll circle back to the harder one.

+ +

Which was, I think, just a bit of bad luck in terms of, like, as we're going down the list, that happened to be like the gnarliest one, and it was like the first one that Joël picked up. And so I'm going through a couple of files, and Joël is like, "What? [laughs] How are you making progress?" And we realize it's just because that file, in particular, is very hard to find all the mystery guests and then to move everything over.

+ +

Finding a positive note through all of the cruft, I will say this is helping with some of my code sleuthing skills. So as I am running into these problems and then looking for mystery guests, I'm noticing ways that I can then, as quickly as possible, try to triage and identify as to why one test doesn't match another test. Some of it is more specific to the application setup, so it won't be as applicable to future projects. But then some other areas have been really helpful.

+ +

Like, I'm using caller a lot more to understand, like, I know this is getting called, but I don't know who's calling you. So I can put in a line that basically outputs like, show me your stack traces to how you got here. So that's been really nice as well. So it has improved some of my code sleuthing skills and also my spidey sense in terms of it's typically mystery guests.

+ +

Like when a test isn't passing, it's because fixtures are creating extra data that are getting pulled in when there are queries that are being run. But they're not explicitly referenced in the test setup itself. So that's typically then where I start is looking for what record looks relevant to this test that I haven't pulled over to my test setup.

+ +

CHRIS: I appreciate you finding the silver lining, the positive bit of this. Because as you're describing, the work that you're doing sounds like I think you use the word slog, which seems like a very accurate term. But sometimes we have to do that sometimes for a variety of reasons. We end up either having to introduce new code or fix old code, but this is sometimes the work.

+ +

And this is something that I think you and I share about this show is we get to show all sides of the work. And the work can be glamorous and new. And oh, I've got this greenfield app that I'm building, and it's wonderful. Look at the architecture. And I know in the moment that I'm building someone else's legacy code three years from now. [laughs]

+ +

And so telling the other side of the story and providing that rounded point of view, because like, yeah, this is all part of it. Again, I don't believe that this is a solved problem, building robust software that we can maintain. And so yeah, you're doing the good work in there. And I thank you for sharing it with us.

+ +

STEPH: Thanks. Just don't use fixtures in your test, I beg of you. Please don't do that to the legacy code that you're writing for future developers. [laughs] That is my one request.

+ +

CHRIS: And I will maybe add on to that, sparingly use callbacks. Maybe don't use them at all, and certainly don't use the combination because, my goodness, that'll lead you into some fun times. But yeah, just two small recommendations there.

+ +

STEPH: Oh, there's something else I wanted to share. I saw that Slack added a new audio feature that allows you to record the pronunciation of your name, which is the feature that I was so excited about when we added it to our internal tool called Hub at thoughtbot. And now Slack has it on their profile so that way you can upload the pronunciation. And then anyone looking at your profile can then listen to how to pronounce your name.

+ +

There are a couple of other features that they released, I think just in June, so about a month ago from the recording of today. [laughs] That's weird to say, but here we are. So I'll include a link in the show notes so folks can see that feature in addition to others, but I'm super excited.

+ +

CHRIS: Oh, that is nice. I also like all right, so Slack now has it. Hub now has it. But I don't have access to Hub anymore. And I don't have access to every Slack in the world yet. But here's my suggestion. All right, everybody, stick with me here. I want you to own a domain. I want you to have a personal site on it. And I want the personal site to include the pronunciation of your name.

+ +

I get that that's a big ask. And I get that there are other platforms that are calling to you, and you may be writing on those. But you know what? Just stand up a little site, just a little place on the internet that you own. And if it includes the pronunciation of your name, I will be forever grateful.

+ +

STEPH: I like this idea. I initially was taking your idea and immediately running with it as you were speaking it because then I wondered if everyone had their own YouTube channel. But I don't know how hard it is to create a YouTube channel. I am not a YouTube channeler, so I don't know what that looks like. [laughs] But not everybody will know how to purchase a domain. So that might be another approach.

+ +

CHRIS: I think it's pretty easy to do a YouTube channel. I'm conflating a couple of things. This is my basket of beliefs about people on the internet, but I kind of think everybody should own their own little slice of the internet. And so totally, YouTube is a place where the people make some stuff, make videos, put them on YouTube, absolutely. But ideally, you own something. I see a lot of people that are on YouTube, and that's it, and so their entire audience lives on YouTube. And if YouTube someday decides to change or remove them or say Medium as an example, Medium actually, I think, does a more interesting version of this where your identity kind of gets subsumed into Medium.

+ +

And I really think everybody should just have their own little, tiny slice of the internet that's there. It has their name that they own that no platform can decide; hey, we've shifted, and now your stuff is gone. Cool URIs don't change as they say, and that's what I want. And then yeah, if you can have the pronunciation of your name on there, that's extra nice.

+ +

Although I say that, and I don't know that I would do it because my name feels very obvious. One day someone was like, "Oh, how do you pronounce your last name?" I forget if I actually replied with the pronunciation. Or if I was like, "I need to know what options you're considering. I'm so interested because I've really only got the one." Maybe I'm anchored. Maybe I'm biased. [chuckles] I've been doing this for a while. But I really cannot think of another pronunciation of my name.

+ +

STEPH: You might hear another one that you really like, and you need to pivot.

+ +

CHRIS: Oh gosh.

+ +

STEPH: That's the point where you start pronouncing your name differently.

+ +

CHRIS: Wow, that would be a lot. And then, I could have a change log on my personal site where people can see this is the pronunciation, and this is what the pronunciation used to be.

+ +

STEPH: [laughs] I like this idea. I also like this idea that everybody has their own slice of internet land. I like this encouragement that you're providing for everyone.
+On a slightly different note, there's a blog post that I'm really excited to talk about. It's written by Eric Bailey, who's a former thoughtboter. It's called The Optics of Pair Programming. And given how much pair programming that I'm doing, especially with Joël on the current project, it was a really wonderful read.

+ +

And it also helped me think about pairing from a different perspective because we do have a very strong pairing culture at thoughtbot. So there's a lot of nuance, especially social nuances that can go along with when you invite someone to pair with you that I had not considered until I read this wonderful post by Eric. And we'll be sure to include a link in the show notes.

+ +

But to provide an overview, essentially, Eric shares that given coming from thoughtbot where we do have a very open approach to pairing where pairing sessions are voluntary and then also last as long as the problem will last...but then when you're at a new company, you could experience pushback if you're inviting someone to pair and then to consider why that pushback may exist. And some of the high-level areas that Eric highlighted are power dynamics, assessment, privacy, and learning styles.

+ +

So to dive into each of some of those, there's a power dynamics of it's important to consider who's offering to pair. So if I've joined a team as a consultant, there may be a power dynamic there that someone is feeling where their team is paying for my time. So they may feel like they can't say no if I offered to pair. They feel like they need to say yes to the invitation, even if they don't really want to.

+ +

Or probably a more classic example would be like, what if your boss wants to pair or someone that's just more senior than you? Then it could leave you feeling like, well, I can't say no to this person, can I? Which yes, you totally can say no to that person, but it may leave you in a place where you feel like you can't. And so, it puts you in this sort of uncomfortable and powerless position.

+ +

The other one is assessment, so offering to pair with someone could feel like you are implying that you want to assess their skills or that you're implying that they're not up to the task and therefore they need your help. So then that could also place someone in an uncomfortable position. There's also privacy. So someone who isn't confident may not want someone to observe their behavior or observe how they're working. It could make them feel really anxious, which then I love that Eric points this out.

+ +

Ironically, pairing is really good at addressing that lack of confidence because then you get to see how other people work through their problems or how they think, or they may also have some anxiety. Or it just helps you become more comfortable in talking and thinking through with other people. So that one is a tough one where it's hard to get over that initial hurdle. But actually, the more you pair, then the less anxious you'll feel when you pair.

+ +

And then there's also learning styles because pairing really involves a lot of deep thinking but in our personal time. And it can be hard to balance both of those, and it's just not as effective for some people. So I know that even as much as I really enjoy pairing, I just need to sit with code on my own sometimes. I need to think about it. I need to run it; I need to look at it.

+ +

So it's really nice to talk with someone. But then I also need that alone time to then just think through it on my own because I can't have that same deep focus if I'm also worried about how the other person is experiencing that session because then my mental energy is going towards them.

+ +

So that covers a number of the social nuances that can be included or running through someone's mind when you extend an invitation to them to pair. And it really resonated with me the areas that Eric highlights in this blog post. He also talks about a couple of strategies, which I'd love to dive into as well. But I'm going to pause here and see what thoughts you have.

+ +

CHRIS: Yeah, I love this post. And it got me thinking about pairing and the broader human backdrop of all of the processes and workflows that we have. Everything he highlighted about pairing feels true. Although similar to you and to Eric, I've worked in a context where pairing was a very natural, very regular part of the work and sort of from the very top-down. And so everyone pairing between developers of any different level or developers and designers or really anyone in the...it was just such a part of how we worked that no one really questioned it or at least not after the first couple of weeks.

+ +

I imagine joining thoughtbot those first weeks; you're like, oh God. As I shared, I think in the previous episode that we recorded, my pairing interview was with Joe Ferris, the CTO of thoughtbot, [laughs] writing a book about good and bad code. And I was like, I don't know what anything is here but very quickly getting over that hurdle. And having that normalizing experience was actually really great, and then have been comfortable with it since. But the idea that there are so many different social dynamics at play feels true.

+ +

And then as I think about other things, like stand-up is one that I think of as this very simple this is a way to communicate where we're at. And where necessary or where useful, allow people to interject or step in to say, "Oh, let me help you get unblocked there or whatever it is." But so often, I see stand-up being a ritual about demonstrating that you are, in fact, doing work, which is like, here's what I did yesterday. I don't know if it's useful. Then mention that you're working on this project. But the enumeration of look, obviously, work was done by me. You can see it; here are the receipts. It's very much this social dynamic at play.

+ +

And retro is another one where like, if retro is very much owned by one voice and not a place that change actually happens where people feel safe airing their opinions or their concerns, then it's going to be a terrible experience. But if you can structure it and enforce that it is a space that we can have a conversation, that everyone's voice is welcome and that real change happens as a result of, then it's a magical tool for making sure we're doing the right things. But always behind these are the people, and feelings, and the psychology at play. And so this was just such an interesting post to read and ruminate on that a little bit more.

+ +

STEPH: Yeah, I agree, especially with a comment that you made about those daily syncs where I really just want to focus on today and what you have that you're blocked on. So it's a really nice update in case there are any cross-collaboration opportunities. That's really what I'm looking for in a daily update. And so I appreciate when people don't go through a laundry list of what they did yesterday because it's like, that's great. But then, like you said, it's just like you're trying to prove here's what I've done, and I trust you; you're working. So just let me know what you're doing today, friend.

+ +

So Eric does a wonderful job of also including some strategies for ways that then you can address some of these concerns and then how there may be some extra anxiety that's increased when you're inviting somebody to pair. There are some wonderful strategies. I'll let folks read through the blog post itself.

+ +

There are a couple in particular that came to mind for me because I was then self-assessing how do I tend to approach pairing with someone? And some ways that I want them to feel very comfortable with that experience. And there's a couple. There's one where I recognize that I need to build trust with each person. I can't just go on to a team and expect everyone to know that I have good intentions and that I'm going to do my best to be a fun, helpful pairing partner, and that it's not a zone of judgment. And that has to be cultivated with each person.

+ +

Because especially as a consultant, if I'm joining a team, the people who hired me are not necessarily the people that I'm working with. It's someone that's probably in leadership or management that has then brought on thoughtbot. And so then the people that I'm working with they don't know me, and they don't know what my pairing style is going to be. So looking for ways to build trust with each person and then also inviting them or asking for help myself.

+ +

So there's a bit of vulnerability that has to be shown to build trust with someone to say," Hey, I'm stuck on a problem. I would love a second set of eyes. Would you be willing to help me out with this?" So then that way, they're coming in to help me initially versus I'm going in and saying, "Hey, can I help you?" I have found that to be an effective strategy.

+ +

And there's one that I do really want to talk about, and that's not everyone is going to pair well together. Like, you may find someone who always leaves you feeling just stressed or demoralized. And while it's important to consider your role and why that's true, that does not mean it's your fault and necessarily your problem to fix.

+ +

So similar to having to manage up, you may need to coach the person that you're pairing with in ways that help you feel comfortable pairing. But if they don't listen to your requests and implement any of that feedback, then just don't pair with that person. That is a very fine option to recognize people that are not receptive to your needs and, therefore, not someone that you need to then force into being a great pairing buddy.

+ +

And I emphasize that last one because it took me a little while to become comfortable with that and accepting that it wasn't my fault that I wasn't having a great pairing session with people. Similar to when I'm learning from someone that if someone is explaining something to me and they're making me feel inadequate while they're explaining it to me, that's not necessarily my fault. Like, I used to internalize that as like, oh, I just can't get this.

+ +

But I am now a very staunch believer in if you can't explain it to me in a way that I understand, then that's probably more on you than on me. And that has also taken me time to just really accept and embrace. But once you do, it is so freeing to realize that if someone's explaining a concept and you're still not getting it, it's like, hey, how can we try harder together versus you just making me try harder?

+ +

CHRIS: I like that right there of like, if I don't understand this, it may actually be you, not me, or something to that effect. Let's get that on a bumper sticker and put that in The Bike Shed store so that everybody can buy it and put it on their cars or at least just us. But yeah, that starting from the bottom sometimes it's just not going to work great. There are even...I think what you're describing sounds a little more complicated, individuals who are personally not great at communicating or pairing or things like that. And that's going to happen.

+ +

We're going to run into folks that...pairing is communication. That's just the core of it, and some folks, that may not be their strongest suit. But I think there's another category of just like different working styles. And whereas I might...judge is such a heavy word, but I'm going to use it. I might judge someone who is not doing a great job at communicating to someone else, or understanding their point of view, or striving to do that, or taking feedback. Like, those are not great things.

+ +

Whereas there may just be two different development styles or backgrounds, or there are other reasons that actually they may be not an ideal fit. That said, I have definitely found that in almost every variation of pairing, I've seen work at some point. Like, when I was very early on in my career pairing with folks that are very senior, I didn't get most of it, but I got some stuff. And then folks that are very much on the same level or folks that have a deep knowledge in framework, code base language, whatever and folks that are new to it but have a different set of experiences.

+ +

Basically, every version of that, I found that pairing is actually an incredibly powerful technique for knowledge sharing, for collaboration, for all of that. So although there are rare cases where there might be some misalignment, in general, I think pairing can work.

+ +

I do think you hit on something earlier of there are certain folks that are more private thinkers, is how I would describe it, where thinking out loud is complicated for them. I'm very much someone who talks. That's how I figure out what I think is I say stuff. And I'm like, oh, I agree with what I just said. That's good. But I find I actually struggle. There's something I think of...maybe I'm just a loudmouth is what I'm hearing as I say it, but that is how I process things. Other folks, that is not true.

+Other folks, it's quite internal, and actually trying to vocalize that or trying to share the thought process as they're going may be uncomfortable. And I think that's perfectly reasonable and something that we should recognize and make space for. And so pairing should not be forced upon a team or an individual because there are just different mindsets, different ways of thinking that we need to account for.

+ +

But again, the vast majority of cases...I've seen plenty of cases where it's someone's like, "I don't like to pair. That's not my thing." And it's actually that they've had bad experiences. And then when they find a space that feels safe or they see the pattern demonstrated in a way that is collegial, and useful, and friendly, then they're like, oh, actually, I thought I didn't like pairing. I thought I didn't like retro. I thought I didn't like stand-up. But actually, all of these things can be good.

+ +

STEPH: Yeah, absolutely. It's a skill like anything else. You need to see value in it. And if you haven't seen value in it yet or if it's always made you anxious and uncomfortable, then it's something that you're going to avoid as much as possible until someone can provide a valuable, positive experience around how it can go.

+ +

I'm going to pull back the curtains just a little bit on our recording and share because you've mentioned that you are very much you think out loud, and that's how you decide that you agree with yourself. And I think already at least twice while we've been recording this episode, I have started to say something, and I'm like, no, wait, I don't agree with that and have backed myself up.

+ +

CHRIS: [laughs]

+ +

STEPH: And I'm like, no, I just thought through it; I'm going to cancel it out, [laughs] and then moved in a different direction. So I, too, seem to be someone that I start to say things, and I'm like, oh, wait, I don't actually agree with what I just said [laughs], so let's remove that.

+ +

CHRIS: Yep. You've described it as Michael Scott-ing on a handful of different episodes or maybe things that were cut from episodes. But where you start a sentence and then you're like, I don't know where I was going to end up there. I hoped I'd figure it out by the end, but then I did not get there. And yeah, I think we've all experienced that at various times.

+ +

STEPH: That’s some of my favorite advice from you is where you've been like, just lean into it, just see where it goes. Finish it out. We can always take it out later. [laughs] Because I stop myself because I immediately start editing what I'm trying to say and you're like, "No, no, just finish it, and then we'll see what happens." That's been fun.

+ +

CHRIS: This is how you find out what you think. You say it out loud, and then you're like, never mind. That was ridic –

+ +

STEPH: [laughs]

+ +

CHRIS: I do. Actually, now I'm thinking back, and I have plenty of those where I'll say a thing, and I'm like, nope, never mind, send that one back. [chuckles] As an aside, so we do this thing where we host a podcast, and we get to talk. But we're both now describing the pattern where we'll start to say something, and we’ll be like no, no, no, actually, not that. And I think, dear listeners out there, you probably don't hear any of this, the vast majority of it, because we have wonderful editors behind the scenes, Thom Obarski for many years, and now Mandy Moore, who's been with us for a while.

+ +

And so once again, thank you so much to the editor team that allows us to, I think, again, feel safe in this conversation that we can say whatever feels true and then know that we'll be able to switch that around. So thank you so much to the editors who help us out and make us sound better than we are.

+ +

STEPH: Yeah, that has made a big difference in my capabilities to podcast. If we were doing this live, ooh goodness, this might be a whole different, weird show. [laughs]

+ +

CHRIS: I mean, the same is true for code, right? I deeply value the ability to make an absolute mess in my local editor and have nine different commits that eventually I throw two out. And then I revert that file, and then eventually, the PR that I put up that's my Instagram selfie. That's like, I carefully curated this, but what's behind the scenes it's just a pile of trash. So yeah, the ability to separate the creation and the editing that's a meaningful thing to have in life.

+ +

STEPH: Oh, I can't unsee that now. [laughs] A pull request is now the equivalent of that curated Instagram selfie. That is beautiful. [laughs]

+ +

CHRIS: To be clear, I don't think I've ever taken an Instagram selfie. But I get the idea, and I felt like it was an analogy that would work. Again, I try out analogies on this show, and many of them do not stick. But I think that one is all right.

+ +

STEPH: It might even go back to pairing because then you've got help in taking that picture. So hey, you're making a mess with somebody until you get that right perfect thing, and then you push it up for the world to see. So safe spaces for all the activities, I think that's the takeaway. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4cEEyq4z + + ]]> + + Chris Toomey + Steph Viccari + + + 344: Spinner Armageddon + https://bikeshed.thoughtbot.com/344 + 1aa7194f-8d54-4a5b-8118-3a10216d2208 + Tue, 28 Jun 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph has an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. + +Chris got to do something exciting this week using dry-monads. Success or failure? + 38:50 + no + + + Steph has an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. +Chris got to do something exciting this week using dry-monads. Success or failure? +This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. +Bartender (https://www.macbartender.com/) +dry-rb - dry-monads v1.0 - Pattern matching (https://dry-rb.org/gems/dry-monads/1.0/pattern-matching/) +alfred-workflows (https://github.com/tupleapp/alfred-workflows/blob/master/scripts/online_users.rb) +Raycast (https://www.raycast.com/) +ruby-science (https://github.com/thoughtbot/ruby-science) +Inertia.js (https://inertiajs.com/) +Remix (https://remix.run/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. +Flaky tests slow everyone down, break your flow, and make things downright miserable. +In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start? +BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! +And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. +So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed. +STEPH: What type of bird is the strongest bird? +CHRIS: I don't know. +STEPH: A crane. +[laughter] +STEPH: You're welcome. And on that note, shall we wrap up? +CHRIS: Let's wrap up. +[laughter] +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris, I saw a good movie I'd like to tell you about. It was just over the weekend. It's called The Duke, and it's based on a real story. I should ask, have you seen it? Have you heard of this movie called The Duke? +CHRIS: I don't think so. +STEPH: Okay, cool. It's a true story, and it's based on an individual named Kempton Bunton who then stole a particular portrait, a Goya portrait; if you know your artist, I do not. But he stole a Goya portrait and then essentially held at ransom because he was a big advocate that the BBC News channel should be free for people that are living on a pension or that are war veterans because then they're not able to afford that fee. But then, if you take the BBC channel away from them, it disconnects them from society. And it's a very good movie. I highly recommend it. So I really enjoyed watching that over the weekend. +CHRIS: All right. Excellent recommendation. We will, of course, add that to the show notes mostly so that I can find it again later. +STEPH: On a more technical note, I have a small update, or it's more of a question. It's an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. This has been quite a journey that Joël and I have been on for a while now. And we're making progress, but we're realizing that we're spending like 95% of our time in the test setup and porting that over, specifically because we're mapping fixture data over to FactoryBot, and we're just realizing that's really painful. It's taking up a lot of time to do that. +And initially, when I realized we were just doing that, we hadn't even really talked about it, but we were moving it over to FactoryBot. I was like, oh, cool. We'll get to delete all these fixtures because there are around 208 files of them. And so that felt like a really good additional accomplishment to migrating the test over. +But now that we realize how much time we're spending migrating the data over for that test setup, we've reevaluated, and I shared with Joël in the Slack channel. I was like, crap. I was like, I have a bad idea, and I can't not say it now because it's crossed my mind. And my bad idea was what if we stopped porting over fixtures to FactoryBot and then we just added the fixtures to a directory that RSpec would look so then we can rely on those fixtures? And then that way, we're literally then ideally just copying over from Test::Unit over to RSpec. +But it does mean a couple of things. Well, one, it means that we're now running those fixtures at the beginning of RSpec test. We're introducing another pattern of where these tests are already using FactoryBot, but now they have fixtures at the top, and then we won't get to delete the fixtures. So we had a conversation around how to manage and mitigate some of those concerns. And we're still in that exploratory. We're going to test it out and see if this really speeds us up referencing the fixtures. +The question that's wrapped up in this is there's something different between how fixtures generate data and how factories generate data. So I've run into this a couple of times now where I moved data over to just call a factory. But then I was hitting these callbacks or after-save-hooks or weird things that were then preventing me from creating the record, even though fixtures was creating them just fine. And then Joël pointed out today that he was running into something similar where there were private methods that were getting called. And there were all sorts of additional code that was getting run with factories versus fixtures. And I don't have an answer. +Like, I haven't looked into this. And it's frankly intentional because I was trying hard to not dive into understanding the mechanics. We really want to get through this. But now I'm starting to ponder a little more as to what is different with fixtures and factories? And I liked that factories is running these callbacks; that feels correct. But I'm surprised that fixtures doesn't, or at least that's the experience that I'm having. +So there's some funkiness there that I'd like to explore. I'll be honest; I don't know if I'm going to. But if anybody happens to know what that funkiness is or why fixtures and factories are different in that regard, I would be very intrigued because, at some point, I might look into it just because I would like to know. +CHRIS: Oh, that is interesting. I have not really worked with fixtures much at all. I've lived a factory life myself, and thus that's where almost all of my experience is. I'm not super surprised if this ends up being the case, like, the idea that fixtures are just some data that gets shoveled into the database directly as opposed to FactoryBot going through the model layer. And so it's sort of like that difference. But I don't know that for certain. That sounds like what this is and makes sense conceptually. +But I think this is what you were saying like, that also kind of pushes me more in the direction of factories because it's like, oh, they're now representative. They're using our model layer, where we're defining certain truths. And I don't love callbacks as a mechanism. But if your app has them, then getting data that is representative is useful in tests. Like one of the things I add whenever I'm working with FactoryBot is the FactoryBot lint rake task RSpec thing that basically just says, "Are your factories valid?" which I think is a great baseline to have. +Because you may add a migration that adds a default constraint or something like that to the database that suddenly all your factories are invalid, and it's breaking tests, but you don't know it. Like subtly, you change it, and it doesn't actually break a test, but then it's harder later. So that idea of just having more correctness baked in is always nice, especially when it can be automated like that, so definitely a fan of that. But yeah, interested if you do figure out the distinction. +I do like your take, though, of like, but also, maybe I just won't figure this out. Maybe this isn't worth figuring it out. Although you were in the interesting spot of, you could just port the fixtures over and then be done and call the larger body of work done. But it's done in sort of a half-complete way, so it's an interesting trade-off space. I'm also interested to hear where you end up on that. +STEPH: Yeah, it's a tough trade-off. It's one that we don't feel great about. But then it's also recognizing what's the true value of what we're trying to deliver? And it also comes down to the idea of churn versus complexity. And I feel like we are porting over existing complexity and even adding a smidge, not actual complexity but adding a smidge of indirection in terms that when someone sees this file, they're going to see a mixed-use of fixtures and factories, and that doesn't feel good. +And so we've already talked about adding a giant comment above fixtures that just is very honest and says, "Hey, these were ported over. Please don't mimic this. But this is some legacy tests that we have brought over. And we haven't migrated the fixtures over to use factories." And then, in regards to the churn versus complexity, this code isn't likely to get touched like these tests. We really just need them to keep running and keep validating scenarios. But it's not likely that someone's going to come in here and really need to manage these anytime soon. At least, this is what I'm telling myself to make me feel better about it. +So there's also that idea of yes, we are porting this over. This is also how they already exist. So if someone did need to manage these tests, then going to Test::Unit, they would have the same experience that they're going to have in RSpec. So that's really the crux of it is that we're not improving that experience. We're just moving it over and then trying to communicate that; yes, we have muddied the waters a little bit by introducing this other pattern. So we're going to find a way to communicate why we've introduced this other pattern, but that way, we can stay focused on actually porting things over to RSpec. +As for the factories versus fixtures, I feel like you're onto something in terms of it's just skipping that model layer. And that's why a lot of that functionality isn't getting run. And I do appreciate the accuracy of factories. I'd much rather know is my data representative of real data that can get created in the world? And right now, it feels like some of the fixtures aren't. +Like, how they're getting created seemed to bypass really important checks and validations, and that is wrong. That's not what we want to have in our test is, where we're creating data that then the rest of the application can't truly create. But that's another problem for another day. So that's an update on a trade-off that we have made in regards to the testing journey that we are on. What's going on in your world? +CHRIS: Well, we got to do something exciting this week. I was working on some code. This is using dry-monads, the dry-rb space. So we have these result objects that we use pretty pervasively throughout the app, and often, we're in a controller. We run one of these command objects. So it's create user, and create user actually encompasses a ton of logic in our app, and that object returns a result. +So it's either a success or a failure. And if it's a success, it'll be a success with that new user wrapped up inside of it, or if it's a failure, it's a specific error message. Actually, different structured error messages in different ways, some that would be pushed to the form, some that would be a flash message. There are actually fun, different things that we do there. +But in the controller, when we interact with those result objects, typically what we'll do is we'll say result equals create user dot run, (result=createuser.run) and then pass it whatever data it needs. And then on the next line, we'll say results dot either, (results.either), which is a method on these result objects. It's on both the success and failure so you can treat them the same. And then you pass what ends up being a lambda or a stabby proc, or I forget what they are. But one of those sort of inline function type things in Ruby that always feel kind of weird. +But you pass one of those, and you actually pass two of them, one for the success case and one for the failure case. And so in the success case, we redirect back with a notice of congratulations, your user was created. Or, in the failure case, we potentially do a flash message of an alert, or we send the errors down, or whatever it ends up being. But it allows us to handle both of those cases. But it's always been syntactically terrible, is how I would describe it. It's, yeah, I'm just going to leave it at that. We are now living in a wonderful, new world. +This has been something that I've wanted to try for a while. But I finally realized we're actually on Ruby 2.7, and so thus, we have access to pattern matching in Ruby. So I get to take it for a spin for the first time, realizing that we were already on the correct version. And in particular, dry-monads has a page in their docs specific to how we can take advantage of pattern matching with the result objects that they provide us. There's nothing specific in the library as far as I understand it. This is just them showing a bunch of examples of how one might want to do it if they're working with these result objects. +But it's really great because it gives the ability to interact with, you know, success is typically going to be a singular case. There's one success branch to this whole logic, but there are like seven different ways it can fail. And that's the whole idea as to why we use these command objects and the whole Railway Oriented Programming and that whole thing which I have...what is this word? [laughs] I feel like I should know it. It's a positive rant. I have raved; that is how our users kindly pointed that out to us. I have raved about the Railway Oriented Programming that allows us to do. +But it's that idea that they're actually, you know, there's one happy path, and there are seven distinct failure modes, seven unhappy paths. And now, using pattern matching, we actually get a really expressive, readable, useful way to destructure each of those distinct failures to work with the particular bits of data that we need. So it was a very happy day, and I got to explore it. This is, again, a feature of Ruby, not a feature of dry-monads. But dry-monads just happens to embrace it and work really well with it. So that was awesome. +STEPH: That is awesome. I've seen one or two; I don't know, I've seen a couple of tweets where people are like, yeah, Ruby pattern matching. I haven't found a way to use it. So I'm excited that you just shared a way that you found to use it. I'm also worried what it says about our developer culture that we know the word rant so well, but rave, we always have to reach back into our memory to be like, what's that positive word or something that we like? [laughs] +CHRIS: And especially here on The Bike Shed, where we try to gravitate towards the positive. But yeah, it's an interesting point that you make. +STEPH: We're a bunch of ranters. It's what we do, pranting ranters. I don't know why we're pranting. [laughs] +CHRIS: Because it's that exciting. That's what it is. Actually, there was an interesting thing as we were playing around with the pattern matching code, just poking around in the console session with it, and it prints out a deprecation warning. It's like, warning: this is an experimental feature. Do not use it, be careful. But in the back of my head, I was like, I actually know how this whole thing plays out, Ruby 2.7, and I assure you, it's going to be fine. I have been to the future, at least I'm pretty sure. +I think the version that is in Ruby 2.7 did end up getting adopted basically as it stands. And so, I think there is also a setting to turn off that deprecation warning. I haven't done it yet, but I mostly just enjoyed the conversation that I had with this deprecation message of like, listen, I've been to the future, and it's great. Well, it's complicated, but specific to this pattern matching [laughs] in Ruby 3+ versions, it went awesome. And I'm really excited about that future that we now live in. +STEPH: I wish we had that for so many more things in our life [laughs] of like, here's a warning, and it's like, no, no, I've seen the future. It's all right. Or you're totally right; I should avoid and back out of this now. +CHRIS: If only we could know how the things would play out, you know. But yeah, so pattern matching, very cool. I'll include a link in the show notes to the particular page in the dry-monads docs. But there are also other cool things on the internet. In an unrelated but also cool thing that I found this week, we use Tuple a lot within our organization for pair programming. For anyone who's not familiar with it, it's a really wonderful piece of technology that allows you to pair program pretty seamlessly, better video quality, all of those nice things that we want. +But I found there was just the tiniest bit of friction in starting a Tuple call. I know I want to pair with this person. And I have to go up and click on the little menu bar, and then I have to find their name, then I have to click a button. That's just too much. That's not how...I want to live my life at the keyboard. I have a thing called Bartender, which is a little menu bar manager utility app that will collapse down and hide the icons. But it's also got a nice, little hotkey accessible pop-up window that allows me to filter down and open one of the menu bar pop-out menus. +But unfortunately, when that happens, the Tuple window isn't interactive at that point. I can't use the arrow keys to go up and down. And so I was like, oh, man, I wonder if there's like an Alfred workflow for this. And it turns out indeed there is actually managed by the kind folks at Tuple themselves. So I was able to find that, install it; it's great. I have it now. I can use that. +So that was a nice little upgrade to my workflow. I can just type like TC space and then start typing out the person's name, and then hit enter, and it will start a call immediately. And it doesn't actually make me more productive, but it makes me happier. And some days, that's what matters. +STEPH: That's always so impressive to me when that happens where you're like, oh, I need a thing. And then you went through the saga that you just went through. And then the people who manage the application have already gotten there ahead of you, and they're like, don't worry, we've created this for you. That's one of those just beautiful moments of like, wow, y'all have really thought this through on a bunch of different levels and got there before me. +CHRIS: It's somewhat unsurprising in this case because it's a very developer-centric organization, and Ben's background being a thoughtbot developer and Alfred user, I'm almost certain. Although I've seen folks talking about Raycast, which is the new hotness on the quick launcher world. I started eons ago in Quicksilver, and then I moved to Alfred, I don't know, ten years ago. I don't know what time it is anymore. +But I've been in Alfred land for a while, but Raycast seems very cool. Just as an aside, I have not allowed myself... [laughs] this is another one of those like; I do not have permission to go explore this new tool yet because I don't think it will actually make me more productive, although it could make me happier. So... +STEPH: I haven't heard of that one, Raycast. I'm literally adding it to the show notes right now as a way so you can find The Duke later, and I can find Raycast later [chuckles] and take a look at it and check it out. Although I really haven't embraced the whole Alfred workflow. I've seen people really enjoy it and just rave about it and how wonderful it is. But I haven't really leaned into that part of the world; I don't know why. I haven't set any hard and fast rules for myself where I can't play around with these technologies, but I haven't taken the time to do it either. +CHRIS: You've also not found yourself writing thousands of lines of Vimscript because you thought that was a good idea. So you don't need as many guardrails it would seem. That's my guess. +STEPH: This is true. +CHRIS: Whereas I need to be intentional [laughs] with how I structure my interaction with my dev tools. +STEPH: Instead, I'm just porting over fixtures from one place to another. [laughs] That's the weird space that I'm living in instead. [laughs] +CHRIS: But you're getting paid for that. No one paid me for the Vimscript I wrote. +[laughter] +STEPH: That's fair. Speaking around process-y things, there's something that's been on my mind that Valeria, another thoughtboter, suggested around how we structure our meetings and the default timing that we have for meetings. So Thursdays are my team-focused day. And it's the day where I have a lot of one on ones. And I realized that I've scheduled them back to back, which is problematic because then I have zero break in between them, which I'm less concerned about that because then I can go for an hour or something and not have a break. And I'm not worried about that part. +But it does mean that if one of those discussions happens to go over just even for like two or three minutes, then it means that someone else is waiting for me in those two to three minutes. And that feels unacceptable to me. So Valeria brought up a really good idea where I think it's only with the Google Meet paid version. I could be wrong there. But I think with the paid version of it that then you can set the new default for how long a meeting is going to last. +So instead of having it default to 30 minutes, have it default to 25 minutes. So then, that way, you do have that five-minute buffer. So if you do go over just like two or three minutes with someone, you've still got like two minutes to then hop to the next call, and nobody's waiting for you. Or if you want those five minutes to then grab some water or something like that. +So we haven't implemented it just yet because then there's discussion around is this a new practice that we want everybody to move to? Because I mean, if just one person does it, it doesn't work. You really need everybody to buy into the concept of we're now defaulting to 25 versus 30-minute meetings. So I'll have to let you know how that goes. But I'm intrigued to try it out because I think that would be very helpful for me. +Although there's a part of me that then feels bad because it's like, well, if I have 30 minutes to chat with somebody, but now I'm reducing it to 25 minutes each time, I didn't love that I'm taking time away from our discussion. But that still feels like a better outcome than making somebody wait for three to five minutes if something else goes over. So have you ever run into something like that? How do you manage back-to-back meetings? Do you intentionally schedule a break in between or? +CHRIS: I do try to give myself some buffer time. I stack meetings but not so much so that they're just back to back. So I'll stack them like Wednesdays are a meeting-heavy day for me. That's intentional just to be like, all right, I know that my day is going to get chopped up. So let's just really lean into that, chop the heck out of Wednesday afternoons, and then the rest of the week can hopefully have slightly longer deep work-type sessions. And, yeah, in general, I try and have like a little gap in between them. +But often what I'll do for that is I'll stagger the start of the next meeting to be rather than on the hour or the half-hour, I start it on the 15th minute. And so then it's sort of I now have these little 15-minute gaps in my workflow, which is enough time to do one or two small things or to go get a drink or whatever it is or if things do run over. Like, again, I feel what you're saying of like, I don't necessarily want to constrain a meeting. Or I also don't necessarily want to go into the habit of often over-running. +I think it's good to be intentional. Start meetings on time, end meetings on time. If there's a great conversation that's happening, maybe there's another follow-up meeting that should happen or something like that. But for as nonsensical of a human as I believe myself to be, I am rather rigid about meetings. I try very hard to be on time. I try very hard to wrap them up on time to make sure I go to the next one. And so with that, the 15-minute staggering is what I've found works for me. +STEPH: Yeah, that makes sense. One-on-ones feels special to me because I wholeheartedly agree with being very diligent about like, hey, this is our meeting time. Let's do a time check. Someone says that at the end, and then that way, everybody can move on. But one on ones are, there's more open discussion space, and I hate cutting people off, especially because it might not be until the last 15 minutes that you really got into the meat of the conversation. +Or you really got somewhere that's a little bit more personal or things that you want to talk about. So if someone's like, "Yeah, let me tell you about my life goals," and you're like, "Oh, no, wait, sorry. We're out of time." That feels terrible and tragic to do. So I struggle with that part of it. +CHRIS: I will say actually, on that note, I'm now thinking through, but I believe this to be true. Everyone that reports to me I have a 45-minute one-on-one with, and then my CEO I set up the one-on-one. So I also made that one a 45-minute one-on-one. And that has worked out really well. +Typically, I try and structure it and reiterate this from time to time of, like, hey, this is your space, not mine. So let's have whatever conversation fits in here. And it's fine if we don't need to use the whole time, but I want to make sure that we have it and that we protect it. Because I often find much like retro, I don't know; I think everything's fine. And then suddenly the conversation starts, and you're like, you know what? Actually, I'm really concerned now that you mentioned it. And you need that sort of empty space that then the reality sort of pop up into. +And so with one on one, I try and make sure that there is that space, but I'm fine with being like, we can cut this short. We can move on from one-on-one topics to more of status updates; let's talk about the work. But I want to make sure that we lead with is there anything deeper, any concerns, anything you want to talk through? And sort of having the space and time for that. +STEPH: I like that. And I also think it speaks more directly to the problem I'm having because I'm saying that we keep running over a couple of minutes, and so someone else is waiting. So rather than shorten it, which is where I'm already feeling some pain...although I still think that's a good idea to have a default of 25-minute meetings so then that way, there is a break versus the full 30. So if people want to have back-to-back meetings, they still have a little bit of time in between. +But for one on ones specifically, upping it to 45 minutes feels nice because then you've got that 15-minute buffer likely. I mean, maybe you schedule a meeting, but, I don't know, that's funky. But likely, you've got a 15-minute buffer until your next one. And then that's also an area that I feel comfortable in sharing with folks and saying, "Hey, I've booked this whole 45 minutes. But if we don't need the whole time, that's fine." +I'm comfortable saying, "Hey, we can end early, and you can get more of your time back to focus on some other areas." It's more the cutting someone off when they're talking because I have to hop to the next thing. I absolutely hate that feeling. So thanks, I think I'll give that a go. I think I'll try actually bumping it up to 45 minutes, presuming that other people like that strategy too, since they're opting in [laughs] to the 45 minutes structure. But that sounds like a nice solution. +CHRIS: Well yeah, happy to share it. Actually, one interesting thing that I'm realizing, having been a manager at thoughtbot and then now being a manager within Sagewell, the nature of the interactions are very different. With thoughtbot, I was often on other projects. I was not working with my team day to day in any real capacity. So it was once every two weeks, I would have this moment to reconnect with them. And there was some amount of just catching up. Ideally, not like status update, low-level sort of thing, but sort of just like hey, what have you been working on? What have you been struggling with? What have you been enjoying? +There was more like I needed bigger space, I would say for that, or it's not surprising to me that you're bumping into 30 minutes not being quite long enough. Whereas regularly, in the one on ones that I have now, we end up cutting them short or shifting out of true one-on-one mode into more general conversation and chatting about Raycast or other tools or whatever it is because we are working together daily. And we're pairing very regularly, and we're all on the same project and all sorts of in sync and know what's going on. And we're having retro together. We have plenty of places to have the conversation. +So the one-on-one again, still, I keep the same cadence and the same time structure just because I want to make sure we have the space for any day that we really need that. But in general, we don't. Whereas when I was at thoughtbot, it was all the more necessary. And I think for folks listening; I could imagine if you're in a team lead position and if you're working very closely with folks, then you may be on the one side of things versus if you're a little bit more at a distance from the work that they're doing day to day. That's probably an interesting question to ask, and think about how you want to structure it. +STEPH: Yeah, I think that's an excellent point. Because you're right; I don't see these individuals. We may not have really gotten to interact, except for our daily syncs outside of that. So then yeah, there's always like a good first 10 minutes of where we're just chatting about life and catching up on how things are going before then we dive into some other things. So I think that's a really good point. Cool, solving management problems on the mic. I dig it. +In slightly different news, I've joined a book club, which I'm excited about. This book club is about Ruby. It's specifically reading the book Ruby Science, which is a book that was written and published by thoughtbot. And it requires zero homework, which is my favorite type of book club. Because I have found I always want to be part of book clubs. I'm always interested in them, but then I'm not great at budgeting the time to make sure I read everything I'm supposed to read. And so then it comes time for folks to get together. And I'm like, well, I didn't do my homework, so I can't join it. +But for this one, it's being led by Joël, and the goal is that you don't have to do the homework. And they're just really short sections. So whoever's in charge of leading that particular session of the book club they're going to provide an overview of what's covered in whatever the reading material that we're supposed to read, whatever topic we're covering that day. They're going to provide an overview of it, an example of it, so then we can all talk about it together. So if you read it, that's wonderful. You're a bit ahead and could even join the meeting like five minutes late. Or, if you haven't read it, then you could join and then get that update. So I'm very excited about it. +And this was one of those books that I'd forgotten that thoughtbot had written, and it's one that I've never read. And it's public for anybody that's interested in it. So to cover a little bit of details about it, so it talks about code smells, ways to refactor code, and then also common patterns that you can use to solve some issues. So there's a lot of really just great content that's in it. And I'll be sure to include a link in the show notes for anyone else that's interested. +CHRIS: And again, to reiterate, this book is free at this point. Previously, in the past, it was available for purchase. But at one point a number of years ago, thoughtbot set all of the books free. And so now that along with a handful of other books like...what's Edward's DNS book? Domain Name Sanity, I believe, is Edward's book name that Edward Loveall wrote when he was not a thoughtboter, [laughs] and then later joined as a thoughtboter, and then we made the book free. +But on the specific topic of Ruby Science, that is a book that I will never forget. And the reason I will never forget it is that book was written by the one and only CTO Joe Ferris, who is an incredibly talented developer. And when I was interviewing with thoughtbot, I got down to the final day, which is a pairing session. You do a morning pairing session with one thoughtbot developer, and you do an afternoon pairing session with another thoughtbot developer. +So in the morning, I was working with someone on actually a patch to Rails which was pretty cool. I'd never really done that, so that was exciting. And that went fine with the exception that I kept turning on Caps Lock on their keyboard because I was used to Caps Lock being CTRL, and then Vim was going real weird for me. But otherwise, that went really well. But then, in the afternoon, I was paired with the one and only CTO Joe Ferris, who was writing the book Ruby Science at that time. +And the nature of the book is like, here's a code sample, and then here's that code sample improved, just a lot of sort of side-by-side comparisons of code. And I forget the exact way that this went, but I just remember being terrified because Joe would put some code up on the screen and be like, "What do you think?" And I was like, oh, is this the good code or the bad code? I feel like I should know. I do not know. I'm not sure. It worked out fine, I guess. I made it through. But I just remember being so terrified at that point. I was just like, oh no, this is how it ends for me. It's been a good run. +STEPH: [laughs] +CHRIS: I made it this far. I would have loved to work for this nice thoughtbot company, but here we are. But yeah, I made it through. [laughs] +STEPH: There are so many layers to that too where it's like, well if I say it's terrible, are you going to be offended? Like, how's this going to go for me if I speak my truths? Or what am I going to miss? Yeah, that seems very interesting (I kind of like it.) but also a terrifying pairing session. +CHRIS: I think it went well because I think the code...I'd been following thoughtbot's work, and I knew who Joe was and had heard him on podcasts and things. And I kind of knew roughly where things were, and I was like, that code looks messy. And so I think I mostly got it right, but just the openness of the question of like, what do you think? I was like, oh God. [laughs] So yeah, that book will always be in my memories, is how I would describe it. +STEPH: Well, I'm glad it worked out so we could be here today recording a podcast together. [laughs] +CHRIS: Recording a podcast together. Now that I say all that, though, it's been a long time since I've read the book. So maybe I'll take a revisit. And definitely interested to hear more about your book club and how that goes. +But shifting ever so slightly (I don't have a lot to say on this topic.) but there's a new framework technology thing out there that has caught my attention. And this hasn't happened for a while, so it's kind of novel for me. So I tend to try and keep my eye on where is the sort of trend of web development going? And I found Inertia a while ago, and I've been very, very happy with that as sort of this is the default answer as to how I build websites. +To be clear, Inertia is still the answer as to how I build websites. I love Inertia. I love what it represents. But I'm seeing some stuff that's really interesting that is different. Specifically, Remix.run is the thing that I'm seeing. I mentioned it, I think, in the last episode talking about there was some stuff that they were doing with data loading and async versus synchronous, and do you wait on it or? They had built some really nice levers and trade-offs into the framework. And there's a really great talk that Ryan Florence, one of the creators of Remix.run, gave about that and showed what they were building. +I've been exploring it a little bit more in-depth now. And there is some really, really interesting stuff in Remix. In particular, it's a meta-framework, I think, is the nonsense phrase that we use to describe it. But it's built on top of React. That won't be true for forever. I think it's actually they would say it's more built on top of React Router. But it is very similar to Next.js for folks that have seen that. But it's got a little bit more thought around data loading. How do we change data? How do we revalidate data after? +There's a ton of stuff that, having worked in many React client-side API-heavy apps that there's so much pain, cache invalidation. How do you think about the cache? When do you fetch from the network? How do you avoid showing 19 different loading spinners on the page? And Remix as a framework has some really, I think, robust and well-thought-out answers to a lot of that. So I am super-duper intrigued by what they're doing over there. There's a particular video that I think shows off what Remix represents really well. It's Ryan Florence, that same individual, the creator of Remix, building just a newsletter signup page. +But he goes through like, let's start from the bare bones, simplest thing. It's just an input, and a form submits to the server. That's it. And so we're starting from web 2.0, long, long ago, sort of ideas, and then he gradually enhances it with animations and transitions and error states. And even at the end, goes through an accessibility audit using the screen reader to say, "Look, Remix helps you get really close because you're just using web fundamentals." +But then goes a couple of steps further and actually makes it work really, really well for a screen reader. And, yeah, overall, I'm just super impressed by the project, really, really intrigued by the work that they're doing. And frankly, I see a couple of different projects that are sort of in this space. So yeah, again, very early but excited. +STEPH: On their website...I'm checking it out as you're walking me through it, and on their website, they have "Say goodbye to Spinnageddon." And that's very cute. [laughs] +CHRIS: There's some fundamental stuff that I think we've just kind of as a web community, we made some trade-offs that I personally really don't like. And that idea of just spinners everywhere just sending down a ball of application logic and a giant JavaScript file turning it on on someone's computer. And then immediately, it has to fetch back to the server. There are just trade-offs there that are not great. I love that Remix is sort of flipping that around. +I will say, just to sort of couch the excitement that I'm expressing right now, that Remix exists in a certain place. It helps with building complex UIs. But it doesn't have anything in the data layer. So you have to bring your own data layer and figure out what that means. We have ActiveRecord within Rails, and it's deeply integrated. And so you would need to bring a Prisma or some other database connection or whatever it is. And it also doesn't have more sort of full-featured framework things. Like with Rails, it's very easy to get started with a background job system. Remix has no answer to that because they're like, no, no, this is what we're doing over here. +But similarly, security is probably the one that concerns me the most. There's an open conversation in their discussion portal about CSRF protection and a back and forth of whether or not Remix should have that out of the box or not. And there are trade-offs because there are different adapters that you can use for auth. And each would require their own CSRF mitigation. But to me, that is the sort of thing that I would want a framework to have. +Or I'd be interested in a framework that continues to build on top of Remix that adds in background jobs and databases and all that kind of stuff as a complete solution, something more akin to a Rails or a Laravel where it's like, here we go. This is everything. But again, having some of these more advanced concepts and patterns to build really, really delightful UIs without having to change out the fundamental way that you're building things. +STEPH: Interesting. Yeah, I think you've answered a couple of questions that I had about it. I am curious as to how it fits into your current tech stack. So you've mentioned that you're excited and that it's helpful. But given that you already have Rails, and Inertia, and Svelte, does it plug and play with the other libraries or the other frameworks that you have? Are you going to have to replace something to then take advantage of Remix? What does that roadmap look like? +CHRIS: Oh yeah, I don't expect to be using Remix anytime soon. I'm just keeping an eye on it. I think it would be a pretty fundamental shift because it ends up being the server layer. So it would replace Rails. It would replace the Inertia within the stack that I'm using. This is why as I started, I was like, Inertia is still my answer. Because Inertia integrates really well with Rails and allows me to do the sort of it's not progressive enhancement, but it's like, I want fancy UI, and I don't want to give up on Rails. And so, Inertia is a great answer for that. Remix does not quite fit in the same way. Remix will own all of the request-response lifecycle. +And so, if I were to use it, I would need to build out the rest of that myself. So I would need to figure out the data layer. I would need to figure out other things. I wouldn't be using Rails. I'm sure there's a way to shoehorn the technologies together, but I think it sort of architecturally would be misaligned. And so my sense is that folks out there are building...they're sort of piecing together parts of the stack to fill out the rest. +And Remix is a really fantastic controller and view from their down experience and routing layer. So it's routing, controller, view I would say Remix has a really great answer to, but it doesn't have as much of the other stuff. Whereas in my case, Inertia and Rails come together and give me a great answer to the whole story. +STEPH: Got it. Okay, that's super helpful. +CHRIS: But yeah, again, I'm in very much the exploratory phase. I'm super intrigued by a lot of what I've seen of it and also just sort of the mindset, the ethos of the project as it were. That sounds fancy as I say it, but it's what I mean. I think they want to build from web fundamentals and then enhance the experience on top of that, and I think that's a really great way to go. It means that links will work. It means that routing and URLs will work by default. +It means that you won't have loading spinner Armageddon, and these are core fundamentals that I believe make for good websites and web applications. So super interested to see where they go with it. But again, for me, I'm still very much in the Rails Inertia camp. Certainly, I mean, I've built Sagewell on top of it, so I'm going to be hanging out with it for a while, but also, it would still be my answer if I were starting something new right now. +I'm just really intrigued by there's a new example out there in the world, this Remix thing that's pushing the envelope in a way that I think is really great. But with that, my now…what was that? My second or my third rave? Also called the positive rant, as we call it. But yeah, I think on that note, what do you think? Should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph has an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec.

+ +

Chris got to do something exciting this week using dry-monads. Success or failure?

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow, and make things downright miserable.
+In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed.

+ +

STEPH: What type of bird is the strongest bird?

+ +

CHRIS: I don't know.

+ +

STEPH: A crane.

+ +

[laughter]

+ +

STEPH: You're welcome. And on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

[laughter]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris, I saw a good movie I'd like to tell you about. It was just over the weekend. It's called The Duke, and it's based on a real story. I should ask, have you seen it? Have you heard of this movie called The Duke?

+ +

CHRIS: I don't think so.

+ +

STEPH: Okay, cool. It's a true story, and it's based on an individual named Kempton Bunton who then stole a particular portrait, a Goya portrait; if you know your artist, I do not. But he stole a Goya portrait and then essentially held at ransom because he was a big advocate that the BBC News channel should be free for people that are living on a pension or that are war veterans because then they're not able to afford that fee. But then, if you take the BBC channel away from them, it disconnects them from society. And it's a very good movie. I highly recommend it. So I really enjoyed watching that over the weekend.

+ +

CHRIS: All right. Excellent recommendation. We will, of course, add that to the show notes mostly so that I can find it again later.

+ +

STEPH: On a more technical note, I have a small update, or it's more of a question. It's an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. This has been quite a journey that Joël and I have been on for a while now. And we're making progress, but we're realizing that we're spending like 95% of our time in the test setup and porting that over, specifically because we're mapping fixture data over to FactoryBot, and we're just realizing that's really painful. It's taking up a lot of time to do that.

+ +

And initially, when I realized we were just doing that, we hadn't even really talked about it, but we were moving it over to FactoryBot. I was like, oh, cool. We'll get to delete all these fixtures because there are around 208 files of them. And so that felt like a really good additional accomplishment to migrating the test over.

+ +

But now that we realize how much time we're spending migrating the data over for that test setup, we've reevaluated, and I shared with Joël in the Slack channel. I was like, crap. I was like, I have a bad idea, and I can't not say it now because it's crossed my mind. And my bad idea was what if we stopped porting over fixtures to FactoryBot and then we just added the fixtures to a directory that RSpec would look so then we can rely on those fixtures? And then that way, we're literally then ideally just copying over from Test::Unit over to RSpec.

+ +

But it does mean a couple of things. Well, one, it means that we're now running those fixtures at the beginning of RSpec test. We're introducing another pattern of where these tests are already using FactoryBot, but now they have fixtures at the top, and then we won't get to delete the fixtures. So we had a conversation around how to manage and mitigate some of those concerns. And we're still in that exploratory. We're going to test it out and see if this really speeds us up referencing the fixtures.

+ +

The question that's wrapped up in this is there's something different between how fixtures generate data and how factories generate data. So I've run into this a couple of times now where I moved data over to just call a factory. But then I was hitting these callbacks or after-save-hooks or weird things that were then preventing me from creating the record, even though fixtures was creating them just fine. And then Joël pointed out today that he was running into something similar where there were private methods that were getting called. And there were all sorts of additional code that was getting run with factories versus fixtures. And I don't have an answer.

+ +

Like, I haven't looked into this. And it's frankly intentional because I was trying hard to not dive into understanding the mechanics. We really want to get through this. But now I'm starting to ponder a little more as to what is different with fixtures and factories? And I liked that factories is running these callbacks; that feels correct. But I'm surprised that fixtures doesn't, or at least that's the experience that I'm having.

+ +

So there's some funkiness there that I'd like to explore. I'll be honest; I don't know if I'm going to. But if anybody happens to know what that funkiness is or why fixtures and factories are different in that regard, I would be very intrigued because, at some point, I might look into it just because I would like to know.

+ +

CHRIS: Oh, that is interesting. I have not really worked with fixtures much at all. I've lived a factory life myself, and thus that's where almost all of my experience is. I'm not super surprised if this ends up being the case, like, the idea that fixtures are just some data that gets shoveled into the database directly as opposed to FactoryBot going through the model layer. And so it's sort of like that difference. But I don't know that for certain. That sounds like what this is and makes sense conceptually.

+ +

But I think this is what you were saying like, that also kind of pushes me more in the direction of factories because it's like, oh, they're now representative. They're using our model layer, where we're defining certain truths. And I don't love callbacks as a mechanism. But if your app has them, then getting data that is representative is useful in tests. Like one of the things I add whenever I'm working with FactoryBot is the FactoryBot lint rake task RSpec thing that basically just says, "Are your factories valid?" which I think is a great baseline to have.

+ +

Because you may add a migration that adds a default constraint or something like that to the database that suddenly all your factories are invalid, and it's breaking tests, but you don't know it. Like subtly, you change it, and it doesn't actually break a test, but then it's harder later. So that idea of just having more correctness baked in is always nice, especially when it can be automated like that, so definitely a fan of that. But yeah, interested if you do figure out the distinction.

+ +

I do like your take, though, of like, but also, maybe I just won't figure this out. Maybe this isn't worth figuring it out. Although you were in the interesting spot of, you could just port the fixtures over and then be done and call the larger body of work done. But it's done in sort of a half-complete way, so it's an interesting trade-off space. I'm also interested to hear where you end up on that.

+ +

STEPH: Yeah, it's a tough trade-off. It's one that we don't feel great about. But then it's also recognizing what's the true value of what we're trying to deliver? And it also comes down to the idea of churn versus complexity. And I feel like we are porting over existing complexity and even adding a smidge, not actual complexity but adding a smidge of indirection in terms that when someone sees this file, they're going to see a mixed-use of fixtures and factories, and that doesn't feel good.

+ +

And so we've already talked about adding a giant comment above fixtures that just is very honest and says, "Hey, these were ported over. Please don't mimic this. But this is some legacy tests that we have brought over. And we haven't migrated the fixtures over to use factories." And then, in regards to the churn versus complexity, this code isn't likely to get touched like these tests. We really just need them to keep running and keep validating scenarios. But it's not likely that someone's going to come in here and really need to manage these anytime soon. At least, this is what I'm telling myself to make me feel better about it.

+ +

So there's also that idea of yes, we are porting this over. This is also how they already exist. So if someone did need to manage these tests, then going to Test::Unit, they would have the same experience that they're going to have in RSpec. So that's really the crux of it is that we're not improving that experience. We're just moving it over and then trying to communicate that; yes, we have muddied the waters a little bit by introducing this other pattern. So we're going to find a way to communicate why we've introduced this other pattern, but that way, we can stay focused on actually porting things over to RSpec.

+ +

As for the factories versus fixtures, I feel like you're onto something in terms of it's just skipping that model layer. And that's why a lot of that functionality isn't getting run. And I do appreciate the accuracy of factories. I'd much rather know is my data representative of real data that can get created in the world? And right now, it feels like some of the fixtures aren't.

+ +

Like, how they're getting created seemed to bypass really important checks and validations, and that is wrong. That's not what we want to have in our test is, where we're creating data that then the rest of the application can't truly create. But that's another problem for another day. So that's an update on a trade-off that we have made in regards to the testing journey that we are on. What's going on in your world?

+ +

CHRIS: Well, we got to do something exciting this week. I was working on some code. This is using dry-monads, the dry-rb space. So we have these result objects that we use pretty pervasively throughout the app, and often, we're in a controller. We run one of these command objects. So it's create user, and create user actually encompasses a ton of logic in our app, and that object returns a result.

+ +

So it's either a success or a failure. And if it's a success, it'll be a success with that new user wrapped up inside of it, or if it's a failure, it's a specific error message. Actually, different structured error messages in different ways, some that would be pushed to the form, some that would be a flash message. There are actually fun, different things that we do there.

+ +

But in the controller, when we interact with those result objects, typically what we'll do is we'll say result equals create user dot run, (result=createuser.run) and then pass it whatever data it needs. And then on the next line, we'll say results dot either, (results.either), which is a method on these result objects. It's on both the success and failure so you can treat them the same. And then you pass what ends up being a lambda or a stabby proc, or I forget what they are. But one of those sort of inline function type things in Ruby that always feel kind of weird.

+ +

But you pass one of those, and you actually pass two of them, one for the success case and one for the failure case. And so in the success case, we redirect back with a notice of congratulations, your user was created. Or, in the failure case, we potentially do a flash message of an alert, or we send the errors down, or whatever it ends up being. But it allows us to handle both of those cases. But it's always been syntactically terrible, is how I would describe it. It's, yeah, I'm just going to leave it at that. We are now living in a wonderful, new world.

+ +

This has been something that I've wanted to try for a while. But I finally realized we're actually on Ruby 2.7, and so thus, we have access to pattern matching in Ruby. So I get to take it for a spin for the first time, realizing that we were already on the correct version. And in particular, dry-monads has a page in their docs specific to how we can take advantage of pattern matching with the result objects that they provide us. There's nothing specific in the library as far as I understand it. This is just them showing a bunch of examples of how one might want to do it if they're working with these result objects.

+ +

But it's really great because it gives the ability to interact with, you know, success is typically going to be a singular case. There's one success branch to this whole logic, but there are like seven different ways it can fail. And that's the whole idea as to why we use these command objects and the whole Railway Oriented Programming and that whole thing which I have...what is this word? [laughs] I feel like I should know it. It's a positive rant. I have raved; that is how our users kindly pointed that out to us. I have raved about the Railway Oriented Programming that allows us to do.

+ +

But it's that idea that they're actually, you know, there's one happy path, and there are seven distinct failure modes, seven unhappy paths. And now, using pattern matching, we actually get a really expressive, readable, useful way to destructure each of those distinct failures to work with the particular bits of data that we need. So it was a very happy day, and I got to explore it. This is, again, a feature of Ruby, not a feature of dry-monads. But dry-monads just happens to embrace it and work really well with it. So that was awesome.

+ +

STEPH: That is awesome. I've seen one or two; I don't know, I've seen a couple of tweets where people are like, yeah, Ruby pattern matching. I haven't found a way to use it. So I'm excited that you just shared a way that you found to use it. I'm also worried what it says about our developer culture that we know the word rant so well, but rave, we always have to reach back into our memory to be like, what's that positive word or something that we like? [laughs]

+ +

CHRIS: And especially here on The Bike Shed, where we try to gravitate towards the positive. But yeah, it's an interesting point that you make.

+ +

STEPH: We're a bunch of ranters. It's what we do, pranting ranters. I don't know why we're pranting. [laughs]

+ +

CHRIS: Because it's that exciting. That's what it is. Actually, there was an interesting thing as we were playing around with the pattern matching code, just poking around in the console session with it, and it prints out a deprecation warning. It's like, warning: this is an experimental feature. Do not use it, be careful. But in the back of my head, I was like, I actually know how this whole thing plays out, Ruby 2.7, and I assure you, it's going to be fine. I have been to the future, at least I'm pretty sure.

+ +

I think the version that is in Ruby 2.7 did end up getting adopted basically as it stands. And so, I think there is also a setting to turn off that deprecation warning. I haven't done it yet, but I mostly just enjoyed the conversation that I had with this deprecation message of like, listen, I've been to the future, and it's great. Well, it's complicated, but specific to this pattern matching [laughs] in Ruby 3+ versions, it went awesome. And I'm really excited about that future that we now live in.

+ +

STEPH: I wish we had that for so many more things in our life [laughs] of like, here's a warning, and it's like, no, no, I've seen the future. It's all right. Or you're totally right; I should avoid and back out of this now.

+ +

CHRIS: If only we could know how the things would play out, you know. But yeah, so pattern matching, very cool. I'll include a link in the show notes to the particular page in the dry-monads docs. But there are also other cool things on the internet. In an unrelated but also cool thing that I found this week, we use Tuple a lot within our organization for pair programming. For anyone who's not familiar with it, it's a really wonderful piece of technology that allows you to pair program pretty seamlessly, better video quality, all of those nice things that we want.

+ +

But I found there was just the tiniest bit of friction in starting a Tuple call. I know I want to pair with this person. And I have to go up and click on the little menu bar, and then I have to find their name, then I have to click a button. That's just too much. That's not how...I want to live my life at the keyboard. I have a thing called Bartender, which is a little menu bar manager utility app that will collapse down and hide the icons. But it's also got a nice, little hotkey accessible pop-up window that allows me to filter down and open one of the menu bar pop-out menus.

+ +

But unfortunately, when that happens, the Tuple window isn't interactive at that point. I can't use the arrow keys to go up and down. And so I was like, oh, man, I wonder if there's like an Alfred workflow for this. And it turns out indeed there is actually managed by the kind folks at Tuple themselves. So I was able to find that, install it; it's great. I have it now. I can use that.

+ +

So that was a nice little upgrade to my workflow. I can just type like TC space and then start typing out the person's name, and then hit enter, and it will start a call immediately. And it doesn't actually make me more productive, but it makes me happier. And some days, that's what matters.

+ +

STEPH: That's always so impressive to me when that happens where you're like, oh, I need a thing. And then you went through the saga that you just went through. And then the people who manage the application have already gotten there ahead of you, and they're like, don't worry, we've created this for you. That's one of those just beautiful moments of like, wow, y'all have really thought this through on a bunch of different levels and got there before me.

+ +

CHRIS: It's somewhat unsurprising in this case because it's a very developer-centric organization, and Ben's background being a thoughtbot developer and Alfred user, I'm almost certain. Although I've seen folks talking about Raycast, which is the new hotness on the quick launcher world. I started eons ago in Quicksilver, and then I moved to Alfred, I don't know, ten years ago. I don't know what time it is anymore.

+ +

But I've been in Alfred land for a while, but Raycast seems very cool. Just as an aside, I have not allowed myself... [laughs] this is another one of those like; I do not have permission to go explore this new tool yet because I don't think it will actually make me more productive, although it could make me happier. So...

+ +

STEPH: I haven't heard of that one, Raycast. I'm literally adding it to the show notes right now as a way so you can find The Duke later, and I can find Raycast later [chuckles] and take a look at it and check it out. Although I really haven't embraced the whole Alfred workflow. I've seen people really enjoy it and just rave about it and how wonderful it is. But I haven't really leaned into that part of the world; I don't know why. I haven't set any hard and fast rules for myself where I can't play around with these technologies, but I haven't taken the time to do it either.

+ +

CHRIS: You've also not found yourself writing thousands of lines of Vimscript because you thought that was a good idea. So you don't need as many guardrails it would seem. That's my guess.

+ +

STEPH: This is true.

+ +

CHRIS: Whereas I need to be intentional [laughs] with how I structure my interaction with my dev tools.

+ +

STEPH: Instead, I'm just porting over fixtures from one place to another. [laughs] That's the weird space that I'm living in instead. [laughs]

+ +

CHRIS: But you're getting paid for that. No one paid me for the Vimscript I wrote.

+ +

[laughter]

+ +

STEPH: That's fair. Speaking around process-y things, there's something that's been on my mind that Valeria, another thoughtboter, suggested around how we structure our meetings and the default timing that we have for meetings. So Thursdays are my team-focused day. And it's the day where I have a lot of one on ones. And I realized that I've scheduled them back to back, which is problematic because then I have zero break in between them, which I'm less concerned about that because then I can go for an hour or something and not have a break. And I'm not worried about that part.

+ +

But it does mean that if one of those discussions happens to go over just even for like two or three minutes, then it means that someone else is waiting for me in those two to three minutes. And that feels unacceptable to me. So Valeria brought up a really good idea where I think it's only with the Google Meet paid version. I could be wrong there. But I think with the paid version of it that then you can set the new default for how long a meeting is going to last.

+ +

So instead of having it default to 30 minutes, have it default to 25 minutes. So then, that way, you do have that five-minute buffer. So if you do go over just like two or three minutes with someone, you've still got like two minutes to then hop to the next call, and nobody's waiting for you. Or if you want those five minutes to then grab some water or something like that.

+ +

So we haven't implemented it just yet because then there's discussion around is this a new practice that we want everybody to move to? Because I mean, if just one person does it, it doesn't work. You really need everybody to buy into the concept of we're now defaulting to 25 versus 30-minute meetings. So I'll have to let you know how that goes. But I'm intrigued to try it out because I think that would be very helpful for me.

+ +

Although there's a part of me that then feels bad because it's like, well, if I have 30 minutes to chat with somebody, but now I'm reducing it to 25 minutes each time, I didn't love that I'm taking time away from our discussion. But that still feels like a better outcome than making somebody wait for three to five minutes if something else goes over. So have you ever run into something like that? How do you manage back-to-back meetings? Do you intentionally schedule a break in between or?

+ +

CHRIS: I do try to give myself some buffer time. I stack meetings but not so much so that they're just back to back. So I'll stack them like Wednesdays are a meeting-heavy day for me. That's intentional just to be like, all right, I know that my day is going to get chopped up. So let's just really lean into that, chop the heck out of Wednesday afternoons, and then the rest of the week can hopefully have slightly longer deep work-type sessions. And, yeah, in general, I try and have like a little gap in between them.

+ +

But often what I'll do for that is I'll stagger the start of the next meeting to be rather than on the hour or the half-hour, I start it on the 15th minute. And so then it's sort of I now have these little 15-minute gaps in my workflow, which is enough time to do one or two small things or to go get a drink or whatever it is or if things do run over. Like, again, I feel what you're saying of like, I don't necessarily want to constrain a meeting. Or I also don't necessarily want to go into the habit of often over-running.

+ +

I think it's good to be intentional. Start meetings on time, end meetings on time. If there's a great conversation that's happening, maybe there's another follow-up meeting that should happen or something like that. But for as nonsensical of a human as I believe myself to be, I am rather rigid about meetings. I try very hard to be on time. I try very hard to wrap them up on time to make sure I go to the next one. And so with that, the 15-minute staggering is what I've found works for me.

+ +

STEPH: Yeah, that makes sense. One-on-ones feels special to me because I wholeheartedly agree with being very diligent about like, hey, this is our meeting time. Let's do a time check. Someone says that at the end, and then that way, everybody can move on. But one on ones are, there's more open discussion space, and I hate cutting people off, especially because it might not be until the last 15 minutes that you really got into the meat of the conversation.

+ +

Or you really got somewhere that's a little bit more personal or things that you want to talk about. So if someone's like, "Yeah, let me tell you about my life goals," and you're like, "Oh, no, wait, sorry. We're out of time." That feels terrible and tragic to do. So I struggle with that part of it.

+ +

CHRIS: I will say actually, on that note, I'm now thinking through, but I believe this to be true. Everyone that reports to me I have a 45-minute one-on-one with, and then my CEO I set up the one-on-one. So I also made that one a 45-minute one-on-one. And that has worked out really well.

+ +

Typically, I try and structure it and reiterate this from time to time of, like, hey, this is your space, not mine. So let's have whatever conversation fits in here. And it's fine if we don't need to use the whole time, but I want to make sure that we have it and that we protect it. Because I often find much like retro, I don't know; I think everything's fine. And then suddenly the conversation starts, and you're like, you know what? Actually, I'm really concerned now that you mentioned it. And you need that sort of empty space that then the reality sort of pop up into.

+ +

And so with one on one, I try and make sure that there is that space, but I'm fine with being like, we can cut this short. We can move on from one-on-one topics to more of status updates; let's talk about the work. But I want to make sure that we lead with is there anything deeper, any concerns, anything you want to talk through? And sort of having the space and time for that.

+ +

STEPH: I like that. And I also think it speaks more directly to the problem I'm having because I'm saying that we keep running over a couple of minutes, and so someone else is waiting. So rather than shorten it, which is where I'm already feeling some pain...although I still think that's a good idea to have a default of 25-minute meetings so then that way, there is a break versus the full 30. So if people want to have back-to-back meetings, they still have a little bit of time in between.

+ +

But for one on ones specifically, upping it to 45 minutes feels nice because then you've got that 15-minute buffer likely. I mean, maybe you schedule a meeting, but, I don't know, that's funky. But likely, you've got a 15-minute buffer until your next one. And then that's also an area that I feel comfortable in sharing with folks and saying, "Hey, I've booked this whole 45 minutes. But if we don't need the whole time, that's fine."

+ +

I'm comfortable saying, "Hey, we can end early, and you can get more of your time back to focus on some other areas." It's more the cutting someone off when they're talking because I have to hop to the next thing. I absolutely hate that feeling. So thanks, I think I'll give that a go. I think I'll try actually bumping it up to 45 minutes, presuming that other people like that strategy too, since they're opting in [laughs] to the 45 minutes structure. But that sounds like a nice solution.

+ +

CHRIS: Well yeah, happy to share it. Actually, one interesting thing that I'm realizing, having been a manager at thoughtbot and then now being a manager within Sagewell, the nature of the interactions are very different. With thoughtbot, I was often on other projects. I was not working with my team day to day in any real capacity. So it was once every two weeks, I would have this moment to reconnect with them. And there was some amount of just catching up. Ideally, not like status update, low-level sort of thing, but sort of just like hey, what have you been working on? What have you been struggling with? What have you been enjoying?

+ +

There was more like I needed bigger space, I would say for that, or it's not surprising to me that you're bumping into 30 minutes not being quite long enough. Whereas regularly, in the one on ones that I have now, we end up cutting them short or shifting out of true one-on-one mode into more general conversation and chatting about Raycast or other tools or whatever it is because we are working together daily. And we're pairing very regularly, and we're all on the same project and all sorts of in sync and know what's going on. And we're having retro together. We have plenty of places to have the conversation.

+ +

So the one-on-one again, still, I keep the same cadence and the same time structure just because I want to make sure we have the space for any day that we really need that. But in general, we don't. Whereas when I was at thoughtbot, it was all the more necessary. And I think for folks listening; I could imagine if you're in a team lead position and if you're working very closely with folks, then you may be on the one side of things versus if you're a little bit more at a distance from the work that they're doing day to day. That's probably an interesting question to ask, and think about how you want to structure it.

+ +

STEPH: Yeah, I think that's an excellent point. Because you're right; I don't see these individuals. We may not have really gotten to interact, except for our daily syncs outside of that. So then yeah, there's always like a good first 10 minutes of where we're just chatting about life and catching up on how things are going before then we dive into some other things. So I think that's a really good point. Cool, solving management problems on the mic. I dig it.

+ +

In slightly different news, I've joined a book club, which I'm excited about. This book club is about Ruby. It's specifically reading the book Ruby Science, which is a book that was written and published by thoughtbot. And it requires zero homework, which is my favorite type of book club. Because I have found I always want to be part of book clubs. I'm always interested in them, but then I'm not great at budgeting the time to make sure I read everything I'm supposed to read. And so then it comes time for folks to get together. And I'm like, well, I didn't do my homework, so I can't join it.

+ +

But for this one, it's being led by Joël, and the goal is that you don't have to do the homework. And they're just really short sections. So whoever's in charge of leading that particular session of the book club they're going to provide an overview of what's covered in whatever the reading material that we're supposed to read, whatever topic we're covering that day. They're going to provide an overview of it, an example of it, so then we can all talk about it together. So if you read it, that's wonderful. You're a bit ahead and could even join the meeting like five minutes late. Or, if you haven't read it, then you could join and then get that update. So I'm very excited about it.

+ +

And this was one of those books that I'd forgotten that thoughtbot had written, and it's one that I've never read. And it's public for anybody that's interested in it. So to cover a little bit of details about it, so it talks about code smells, ways to refactor code, and then also common patterns that you can use to solve some issues. So there's a lot of really just great content that's in it. And I'll be sure to include a link in the show notes for anyone else that's interested.

+ +

CHRIS: And again, to reiterate, this book is free at this point. Previously, in the past, it was available for purchase. But at one point a number of years ago, thoughtbot set all of the books free. And so now that along with a handful of other books like...what's Edward's DNS book? Domain Name Sanity, I believe, is Edward's book name that Edward Loveall wrote when he was not a thoughtboter, [laughs] and then later joined as a thoughtboter, and then we made the book free.

+ +

But on the specific topic of Ruby Science, that is a book that I will never forget. And the reason I will never forget it is that book was written by the one and only CTO Joe Ferris, who is an incredibly talented developer. And when I was interviewing with thoughtbot, I got down to the final day, which is a pairing session. You do a morning pairing session with one thoughtbot developer, and you do an afternoon pairing session with another thoughtbot developer.

+ +

So in the morning, I was working with someone on actually a patch to Rails which was pretty cool. I'd never really done that, so that was exciting. And that went fine with the exception that I kept turning on Caps Lock on their keyboard because I was used to Caps Lock being CTRL, and then Vim was going real weird for me. But otherwise, that went really well. But then, in the afternoon, I was paired with the one and only CTO Joe Ferris, who was writing the book Ruby Science at that time.

+ +

And the nature of the book is like, here's a code sample, and then here's that code sample improved, just a lot of sort of side-by-side comparisons of code. And I forget the exact way that this went, but I just remember being terrified because Joe would put some code up on the screen and be like, "What do you think?" And I was like, oh, is this the good code or the bad code? I feel like I should know. I do not know. I'm not sure. It worked out fine, I guess. I made it through. But I just remember being so terrified at that point. I was just like, oh no, this is how it ends for me. It's been a good run.

+ +

STEPH: [laughs]

+ +

CHRIS: I made it this far. I would have loved to work for this nice thoughtbot company, but here we are. But yeah, I made it through. [laughs]

+ +

STEPH: There are so many layers to that too where it's like, well if I say it's terrible, are you going to be offended? Like, how's this going to go for me if I speak my truths? Or what am I going to miss? Yeah, that seems very interesting (I kind of like it.) but also a terrifying pairing session.

+ +

CHRIS: I think it went well because I think the code...I'd been following thoughtbot's work, and I knew who Joe was and had heard him on podcasts and things. And I kind of knew roughly where things were, and I was like, that code looks messy. And so I think I mostly got it right, but just the openness of the question of like, what do you think? I was like, oh God. [laughs] So yeah, that book will always be in my memories, is how I would describe it.

+ +

STEPH: Well, I'm glad it worked out so we could be here today recording a podcast together. [laughs]

+ +

CHRIS: Recording a podcast together. Now that I say all that, though, it's been a long time since I've read the book. So maybe I'll take a revisit. And definitely interested to hear more about your book club and how that goes.

+ +

But shifting ever so slightly (I don't have a lot to say on this topic.) but there's a new framework technology thing out there that has caught my attention. And this hasn't happened for a while, so it's kind of novel for me. So I tend to try and keep my eye on where is the sort of trend of web development going? And I found Inertia a while ago, and I've been very, very happy with that as sort of this is the default answer as to how I build websites.

+ +

To be clear, Inertia is still the answer as to how I build websites. I love Inertia. I love what it represents. But I'm seeing some stuff that's really interesting that is different. Specifically, Remix.run is the thing that I'm seeing. I mentioned it, I think, in the last episode talking about there was some stuff that they were doing with data loading and async versus synchronous, and do you wait on it or? They had built some really nice levers and trade-offs into the framework. And there's a really great talk that Ryan Florence, one of the creators of Remix.run, gave about that and showed what they were building.

+ +

I've been exploring it a little bit more in-depth now. And there is some really, really interesting stuff in Remix. In particular, it's a meta-framework, I think, is the nonsense phrase that we use to describe it. But it's built on top of React. That won't be true for forever. I think it's actually they would say it's more built on top of React Router. But it is very similar to Next.js for folks that have seen that. But it's got a little bit more thought around data loading. How do we change data? How do we revalidate data after?

+ +

There's a ton of stuff that, having worked in many React client-side API-heavy apps that there's so much pain, cache invalidation. How do you think about the cache? When do you fetch from the network? How do you avoid showing 19 different loading spinners on the page? And Remix as a framework has some really, I think, robust and well-thought-out answers to a lot of that. So I am super-duper intrigued by what they're doing over there. There's a particular video that I think shows off what Remix represents really well. It's Ryan Florence, that same individual, the creator of Remix, building just a newsletter signup page.

+ +

But he goes through like, let's start from the bare bones, simplest thing. It's just an input, and a form submits to the server. That's it. And so we're starting from web 2.0, long, long ago, sort of ideas, and then he gradually enhances it with animations and transitions and error states. And even at the end, goes through an accessibility audit using the screen reader to say, "Look, Remix helps you get really close because you're just using web fundamentals."

+ +

But then goes a couple of steps further and actually makes it work really, really well for a screen reader. And, yeah, overall, I'm just super impressed by the project, really, really intrigued by the work that they're doing. And frankly, I see a couple of different projects that are sort of in this space. So yeah, again, very early but excited.

+ +

STEPH: On their website...I'm checking it out as you're walking me through it, and on their website, they have "Say goodbye to Spinnageddon." And that's very cute. [laughs]

+ +

CHRIS: There's some fundamental stuff that I think we've just kind of as a web community, we made some trade-offs that I personally really don't like. And that idea of just spinners everywhere just sending down a ball of application logic and a giant JavaScript file turning it on on someone's computer. And then immediately, it has to fetch back to the server. There are just trade-offs there that are not great. I love that Remix is sort of flipping that around.

+ +

I will say, just to sort of couch the excitement that I'm expressing right now, that Remix exists in a certain place. It helps with building complex UIs. But it doesn't have anything in the data layer. So you have to bring your own data layer and figure out what that means. We have ActiveRecord within Rails, and it's deeply integrated. And so you would need to bring a Prisma or some other database connection or whatever it is. And it also doesn't have more sort of full-featured framework things. Like with Rails, it's very easy to get started with a background job system. Remix has no answer to that because they're like, no, no, this is what we're doing over here.

+ +

But similarly, security is probably the one that concerns me the most. There's an open conversation in their discussion portal about CSRF protection and a back and forth of whether or not Remix should have that out of the box or not. And there are trade-offs because there are different adapters that you can use for auth. And each would require their own CSRF mitigation. But to me, that is the sort of thing that I would want a framework to have.

+ +

Or I'd be interested in a framework that continues to build on top of Remix that adds in background jobs and databases and all that kind of stuff as a complete solution, something more akin to a Rails or a Laravel where it's like, here we go. This is everything. But again, having some of these more advanced concepts and patterns to build really, really delightful UIs without having to change out the fundamental way that you're building things.

+ +

STEPH: Interesting. Yeah, I think you've answered a couple of questions that I had about it. I am curious as to how it fits into your current tech stack. So you've mentioned that you're excited and that it's helpful. But given that you already have Rails, and Inertia, and Svelte, does it plug and play with the other libraries or the other frameworks that you have? Are you going to have to replace something to then take advantage of Remix? What does that roadmap look like?

+ +

CHRIS: Oh yeah, I don't expect to be using Remix anytime soon. I'm just keeping an eye on it. I think it would be a pretty fundamental shift because it ends up being the server layer. So it would replace Rails. It would replace the Inertia within the stack that I'm using. This is why as I started, I was like, Inertia is still my answer. Because Inertia integrates really well with Rails and allows me to do the sort of it's not progressive enhancement, but it's like, I want fancy UI, and I don't want to give up on Rails. And so, Inertia is a great answer for that. Remix does not quite fit in the same way. Remix will own all of the request-response lifecycle.

+ +

And so, if I were to use it, I would need to build out the rest of that myself. So I would need to figure out the data layer. I would need to figure out other things. I wouldn't be using Rails. I'm sure there's a way to shoehorn the technologies together, but I think it sort of architecturally would be misaligned. And so my sense is that folks out there are building...they're sort of piecing together parts of the stack to fill out the rest.

+ +

And Remix is a really fantastic controller and view from their down experience and routing layer. So it's routing, controller, view I would say Remix has a really great answer to, but it doesn't have as much of the other stuff. Whereas in my case, Inertia and Rails come together and give me a great answer to the whole story.

+ +

STEPH: Got it. Okay, that's super helpful.

+ +

CHRIS: But yeah, again, I'm in very much the exploratory phase. I'm super intrigued by a lot of what I've seen of it and also just sort of the mindset, the ethos of the project as it were. That sounds fancy as I say it, but it's what I mean. I think they want to build from web fundamentals and then enhance the experience on top of that, and I think that's a really great way to go. It means that links will work. It means that routing and URLs will work by default.

+ +

It means that you won't have loading spinner Armageddon, and these are core fundamentals that I believe make for good websites and web applications. So super interested to see where they go with it. But again, for me, I'm still very much in the Rails Inertia camp. Certainly, I mean, I've built Sagewell on top of it, so I'm going to be hanging out with it for a while, but also, it would still be my answer if I were starting something new right now.

+ +

I'm just really intrigued by there's a new example out there in the world, this Remix thing that's pushing the envelope in a way that I think is really great. But with that, my now…what was that? My second or my third rave? Also called the positive rant, as we call it. But yeah, I think on that note, what do you think? Should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph has an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec.

+ +

Chris got to do something exciting this week using dry-monads. Success or failure?

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow, and make things downright miserable.
+In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix all of them today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all of the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed.

+ +

STEPH: What type of bird is the strongest bird?

+ +

CHRIS: I don't know.

+ +

STEPH: A crane.

+ +

[laughter]

+ +

STEPH: You're welcome. And on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

[laughter]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris, I saw a good movie I'd like to tell you about. It was just over the weekend. It's called The Duke, and it's based on a real story. I should ask, have you seen it? Have you heard of this movie called The Duke?

+ +

CHRIS: I don't think so.

+ +

STEPH: Okay, cool. It's a true story, and it's based on an individual named Kempton Bunton who then stole a particular portrait, a Goya portrait; if you know your artist, I do not. But he stole a Goya portrait and then essentially held at ransom because he was a big advocate that the BBC News channel should be free for people that are living on a pension or that are war veterans because then they're not able to afford that fee. But then, if you take the BBC channel away from them, it disconnects them from society. And it's a very good movie. I highly recommend it. So I really enjoyed watching that over the weekend.

+ +

CHRIS: All right. Excellent recommendation. We will, of course, add that to the show notes mostly so that I can find it again later.

+ +

STEPH: On a more technical note, I have a small update, or it's more of a question. It's an update and a question wrapped into one about the work that is being done to migrate the Test::Unit test over to RSpec. This has been quite a journey that Joël and I have been on for a while now. And we're making progress, but we're realizing that we're spending like 95% of our time in the test setup and porting that over, specifically because we're mapping fixture data over to FactoryBot, and we're just realizing that's really painful. It's taking up a lot of time to do that.

+ +

And initially, when I realized we were just doing that, we hadn't even really talked about it, but we were moving it over to FactoryBot. I was like, oh, cool. We'll get to delete all these fixtures because there are around 208 files of them. And so that felt like a really good additional accomplishment to migrating the test over.

+ +

But now that we realize how much time we're spending migrating the data over for that test setup, we've reevaluated, and I shared with Joël in the Slack channel. I was like, crap. I was like, I have a bad idea, and I can't not say it now because it's crossed my mind. And my bad idea was what if we stopped porting over fixtures to FactoryBot and then we just added the fixtures to a directory that RSpec would look so then we can rely on those fixtures? And then that way, we're literally then ideally just copying over from Test::Unit over to RSpec.

+ +

But it does mean a couple of things. Well, one, it means that we're now running those fixtures at the beginning of RSpec test. We're introducing another pattern of where these tests are already using FactoryBot, but now they have fixtures at the top, and then we won't get to delete the fixtures. So we had a conversation around how to manage and mitigate some of those concerns. And we're still in that exploratory. We're going to test it out and see if this really speeds us up referencing the fixtures.

+ +

The question that's wrapped up in this is there's something different between how fixtures generate data and how factories generate data. So I've run into this a couple of times now where I moved data over to just call a factory. But then I was hitting these callbacks or after-save-hooks or weird things that were then preventing me from creating the record, even though fixtures was creating them just fine. And then Joël pointed out today that he was running into something similar where there were private methods that were getting called. And there were all sorts of additional code that was getting run with factories versus fixtures. And I don't have an answer.

+ +

Like, I haven't looked into this. And it's frankly intentional because I was trying hard to not dive into understanding the mechanics. We really want to get through this. But now I'm starting to ponder a little more as to what is different with fixtures and factories? And I liked that factories is running these callbacks; that feels correct. But I'm surprised that fixtures doesn't, or at least that's the experience that I'm having.

+ +

So there's some funkiness there that I'd like to explore. I'll be honest; I don't know if I'm going to. But if anybody happens to know what that funkiness is or why fixtures and factories are different in that regard, I would be very intrigued because, at some point, I might look into it just because I would like to know.

+ +

CHRIS: Oh, that is interesting. I have not really worked with fixtures much at all. I've lived a factory life myself, and thus that's where almost all of my experience is. I'm not super surprised if this ends up being the case, like, the idea that fixtures are just some data that gets shoveled into the database directly as opposed to FactoryBot going through the model layer. And so it's sort of like that difference. But I don't know that for certain. That sounds like what this is and makes sense conceptually.

+ +

But I think this is what you were saying like, that also kind of pushes me more in the direction of factories because it's like, oh, they're now representative. They're using our model layer, where we're defining certain truths. And I don't love callbacks as a mechanism. But if your app has them, then getting data that is representative is useful in tests. Like one of the things I add whenever I'm working with FactoryBot is the FactoryBot lint rake task RSpec thing that basically just says, "Are your factories valid?" which I think is a great baseline to have.

+ +

Because you may add a migration that adds a default constraint or something like that to the database that suddenly all your factories are invalid, and it's breaking tests, but you don't know it. Like subtly, you change it, and it doesn't actually break a test, but then it's harder later. So that idea of just having more correctness baked in is always nice, especially when it can be automated like that, so definitely a fan of that. But yeah, interested if you do figure out the distinction.

+ +

I do like your take, though, of like, but also, maybe I just won't figure this out. Maybe this isn't worth figuring it out. Although you were in the interesting spot of, you could just port the fixtures over and then be done and call the larger body of work done. But it's done in sort of a half-complete way, so it's an interesting trade-off space. I'm also interested to hear where you end up on that.

+ +

STEPH: Yeah, it's a tough trade-off. It's one that we don't feel great about. But then it's also recognizing what's the true value of what we're trying to deliver? And it also comes down to the idea of churn versus complexity. And I feel like we are porting over existing complexity and even adding a smidge, not actual complexity but adding a smidge of indirection in terms that when someone sees this file, they're going to see a mixed-use of fixtures and factories, and that doesn't feel good.

+ +

And so we've already talked about adding a giant comment above fixtures that just is very honest and says, "Hey, these were ported over. Please don't mimic this. But this is some legacy tests that we have brought over. And we haven't migrated the fixtures over to use factories." And then, in regards to the churn versus complexity, this code isn't likely to get touched like these tests. We really just need them to keep running and keep validating scenarios. But it's not likely that someone's going to come in here and really need to manage these anytime soon. At least, this is what I'm telling myself to make me feel better about it.

+ +

So there's also that idea of yes, we are porting this over. This is also how they already exist. So if someone did need to manage these tests, then going to Test::Unit, they would have the same experience that they're going to have in RSpec. So that's really the crux of it is that we're not improving that experience. We're just moving it over and then trying to communicate that; yes, we have muddied the waters a little bit by introducing this other pattern. So we're going to find a way to communicate why we've introduced this other pattern, but that way, we can stay focused on actually porting things over to RSpec.

+ +

As for the factories versus fixtures, I feel like you're onto something in terms of it's just skipping that model layer. And that's why a lot of that functionality isn't getting run. And I do appreciate the accuracy of factories. I'd much rather know is my data representative of real data that can get created in the world? And right now, it feels like some of the fixtures aren't.

+ +

Like, how they're getting created seemed to bypass really important checks and validations, and that is wrong. That's not what we want to have in our test is, where we're creating data that then the rest of the application can't truly create. But that's another problem for another day. So that's an update on a trade-off that we have made in regards to the testing journey that we are on. What's going on in your world?

+ +

CHRIS: Well, we got to do something exciting this week. I was working on some code. This is using dry-monads, the dry-rb space. So we have these result objects that we use pretty pervasively throughout the app, and often, we're in a controller. We run one of these command objects. So it's create user, and create user actually encompasses a ton of logic in our app, and that object returns a result.

+ +

So it's either a success or a failure. And if it's a success, it'll be a success with that new user wrapped up inside of it, or if it's a failure, it's a specific error message. Actually, different structured error messages in different ways, some that would be pushed to the form, some that would be a flash message. There are actually fun, different things that we do there.

+ +

But in the controller, when we interact with those result objects, typically what we'll do is we'll say result equals create user dot run, (result=createuser.run) and then pass it whatever data it needs. And then on the next line, we'll say results dot either, (results.either), which is a method on these result objects. It's on both the success and failure so you can treat them the same. And then you pass what ends up being a lambda or a stabby proc, or I forget what they are. But one of those sort of inline function type things in Ruby that always feel kind of weird.

+ +

But you pass one of those, and you actually pass two of them, one for the success case and one for the failure case. And so in the success case, we redirect back with a notice of congratulations, your user was created. Or, in the failure case, we potentially do a flash message of an alert, or we send the errors down, or whatever it ends up being. But it allows us to handle both of those cases. But it's always been syntactically terrible, is how I would describe it. It's, yeah, I'm just going to leave it at that. We are now living in a wonderful, new world.

+ +

This has been something that I've wanted to try for a while. But I finally realized we're actually on Ruby 2.7, and so thus, we have access to pattern matching in Ruby. So I get to take it for a spin for the first time, realizing that we were already on the correct version. And in particular, dry-monads has a page in their docs specific to how we can take advantage of pattern matching with the result objects that they provide us. There's nothing specific in the library as far as I understand it. This is just them showing a bunch of examples of how one might want to do it if they're working with these result objects.

+ +

But it's really great because it gives the ability to interact with, you know, success is typically going to be a singular case. There's one success branch to this whole logic, but there are like seven different ways it can fail. And that's the whole idea as to why we use these command objects and the whole Railway Oriented Programming and that whole thing which I have...what is this word? [laughs] I feel like I should know it. It's a positive rant. I have raved; that is how our users kindly pointed that out to us. I have raved about the Railway Oriented Programming that allows us to do.

+ +

But it's that idea that they're actually, you know, there's one happy path, and there are seven distinct failure modes, seven unhappy paths. And now, using pattern matching, we actually get a really expressive, readable, useful way to destructure each of those distinct failures to work with the particular bits of data that we need. So it was a very happy day, and I got to explore it. This is, again, a feature of Ruby, not a feature of dry-monads. But dry-monads just happens to embrace it and work really well with it. So that was awesome.

+ +

STEPH: That is awesome. I've seen one or two; I don't know, I've seen a couple of tweets where people are like, yeah, Ruby pattern matching. I haven't found a way to use it. So I'm excited that you just shared a way that you found to use it. I'm also worried what it says about our developer culture that we know the word rant so well, but rave, we always have to reach back into our memory to be like, what's that positive word or something that we like? [laughs]

+ +

CHRIS: And especially here on The Bike Shed, where we try to gravitate towards the positive. But yeah, it's an interesting point that you make.

+ +

STEPH: We're a bunch of ranters. It's what we do, pranting ranters. I don't know why we're pranting. [laughs]

+ +

CHRIS: Because it's that exciting. That's what it is. Actually, there was an interesting thing as we were playing around with the pattern matching code, just poking around in the console session with it, and it prints out a deprecation warning. It's like, warning: this is an experimental feature. Do not use it, be careful. But in the back of my head, I was like, I actually know how this whole thing plays out, Ruby 2.7, and I assure you, it's going to be fine. I have been to the future, at least I'm pretty sure.

+ +

I think the version that is in Ruby 2.7 did end up getting adopted basically as it stands. And so, I think there is also a setting to turn off that deprecation warning. I haven't done it yet, but I mostly just enjoyed the conversation that I had with this deprecation message of like, listen, I've been to the future, and it's great. Well, it's complicated, but specific to this pattern matching [laughs] in Ruby 3+ versions, it went awesome. And I'm really excited about that future that we now live in.

+ +

STEPH: I wish we had that for so many more things in our life [laughs] of like, here's a warning, and it's like, no, no, I've seen the future. It's all right. Or you're totally right; I should avoid and back out of this now.

+ +

CHRIS: If only we could know how the things would play out, you know. But yeah, so pattern matching, very cool. I'll include a link in the show notes to the particular page in the dry-monads docs. But there are also other cool things on the internet. In an unrelated but also cool thing that I found this week, we use Tuple a lot within our organization for pair programming. For anyone who's not familiar with it, it's a really wonderful piece of technology that allows you to pair program pretty seamlessly, better video quality, all of those nice things that we want.

+ +

But I found there was just the tiniest bit of friction in starting a Tuple call. I know I want to pair with this person. And I have to go up and click on the little menu bar, and then I have to find their name, then I have to click a button. That's just too much. That's not how...I want to live my life at the keyboard. I have a thing called Bartender, which is a little menu bar manager utility app that will collapse down and hide the icons. But it's also got a nice, little hotkey accessible pop-up window that allows me to filter down and open one of the menu bar pop-out menus.

+ +

But unfortunately, when that happens, the Tuple window isn't interactive at that point. I can't use the arrow keys to go up and down. And so I was like, oh, man, I wonder if there's like an Alfred workflow for this. And it turns out indeed there is actually managed by the kind folks at Tuple themselves. So I was able to find that, install it; it's great. I have it now. I can use that.

+ +

So that was a nice little upgrade to my workflow. I can just type like TC space and then start typing out the person's name, and then hit enter, and it will start a call immediately. And it doesn't actually make me more productive, but it makes me happier. And some days, that's what matters.

+ +

STEPH: That's always so impressive to me when that happens where you're like, oh, I need a thing. And then you went through the saga that you just went through. And then the people who manage the application have already gotten there ahead of you, and they're like, don't worry, we've created this for you. That's one of those just beautiful moments of like, wow, y'all have really thought this through on a bunch of different levels and got there before me.

+ +

CHRIS: It's somewhat unsurprising in this case because it's a very developer-centric organization, and Ben's background being a thoughtbot developer and Alfred user, I'm almost certain. Although I've seen folks talking about Raycast, which is the new hotness on the quick launcher world. I started eons ago in Quicksilver, and then I moved to Alfred, I don't know, ten years ago. I don't know what time it is anymore.

+ +

But I've been in Alfred land for a while, but Raycast seems very cool. Just as an aside, I have not allowed myself... [laughs] this is another one of those like; I do not have permission to go explore this new tool yet because I don't think it will actually make me more productive, although it could make me happier. So...

+ +

STEPH: I haven't heard of that one, Raycast. I'm literally adding it to the show notes right now as a way so you can find The Duke later, and I can find Raycast later [chuckles] and take a look at it and check it out. Although I really haven't embraced the whole Alfred workflow. I've seen people really enjoy it and just rave about it and how wonderful it is. But I haven't really leaned into that part of the world; I don't know why. I haven't set any hard and fast rules for myself where I can't play around with these technologies, but I haven't taken the time to do it either.

+ +

CHRIS: You've also not found yourself writing thousands of lines of Vimscript because you thought that was a good idea. So you don't need as many guardrails it would seem. That's my guess.

+ +

STEPH: This is true.

+ +

CHRIS: Whereas I need to be intentional [laughs] with how I structure my interaction with my dev tools.

+ +

STEPH: Instead, I'm just porting over fixtures from one place to another. [laughs] That's the weird space that I'm living in instead. [laughs]

+ +

CHRIS: But you're getting paid for that. No one paid me for the Vimscript I wrote.

+ +

[laughter]

+ +

STEPH: That's fair. Speaking around process-y things, there's something that's been on my mind that Valeria, another thoughtboter, suggested around how we structure our meetings and the default timing that we have for meetings. So Thursdays are my team-focused day. And it's the day where I have a lot of one on ones. And I realized that I've scheduled them back to back, which is problematic because then I have zero break in between them, which I'm less concerned about that because then I can go for an hour or something and not have a break. And I'm not worried about that part.

+ +

But it does mean that if one of those discussions happens to go over just even for like two or three minutes, then it means that someone else is waiting for me in those two to three minutes. And that feels unacceptable to me. So Valeria brought up a really good idea where I think it's only with the Google Meet paid version. I could be wrong there. But I think with the paid version of it that then you can set the new default for how long a meeting is going to last.

+ +

So instead of having it default to 30 minutes, have it default to 25 minutes. So then, that way, you do have that five-minute buffer. So if you do go over just like two or three minutes with someone, you've still got like two minutes to then hop to the next call, and nobody's waiting for you. Or if you want those five minutes to then grab some water or something like that.

+ +

So we haven't implemented it just yet because then there's discussion around is this a new practice that we want everybody to move to? Because I mean, if just one person does it, it doesn't work. You really need everybody to buy into the concept of we're now defaulting to 25 versus 30-minute meetings. So I'll have to let you know how that goes. But I'm intrigued to try it out because I think that would be very helpful for me.

+ +

Although there's a part of me that then feels bad because it's like, well, if I have 30 minutes to chat with somebody, but now I'm reducing it to 25 minutes each time, I didn't love that I'm taking time away from our discussion. But that still feels like a better outcome than making somebody wait for three to five minutes if something else goes over. So have you ever run into something like that? How do you manage back-to-back meetings? Do you intentionally schedule a break in between or?

+ +

CHRIS: I do try to give myself some buffer time. I stack meetings but not so much so that they're just back to back. So I'll stack them like Wednesdays are a meeting-heavy day for me. That's intentional just to be like, all right, I know that my day is going to get chopped up. So let's just really lean into that, chop the heck out of Wednesday afternoons, and then the rest of the week can hopefully have slightly longer deep work-type sessions. And, yeah, in general, I try and have like a little gap in between them.

+ +

But often what I'll do for that is I'll stagger the start of the next meeting to be rather than on the hour or the half-hour, I start it on the 15th minute. And so then it's sort of I now have these little 15-minute gaps in my workflow, which is enough time to do one or two small things or to go get a drink or whatever it is or if things do run over. Like, again, I feel what you're saying of like, I don't necessarily want to constrain a meeting. Or I also don't necessarily want to go into the habit of often over-running.

+ +

I think it's good to be intentional. Start meetings on time, end meetings on time. If there's a great conversation that's happening, maybe there's another follow-up meeting that should happen or something like that. But for as nonsensical of a human as I believe myself to be, I am rather rigid about meetings. I try very hard to be on time. I try very hard to wrap them up on time to make sure I go to the next one. And so with that, the 15-minute staggering is what I've found works for me.

+ +

STEPH: Yeah, that makes sense. One-on-ones feels special to me because I wholeheartedly agree with being very diligent about like, hey, this is our meeting time. Let's do a time check. Someone says that at the end, and then that way, everybody can move on. But one on ones are, there's more open discussion space, and I hate cutting people off, especially because it might not be until the last 15 minutes that you really got into the meat of the conversation.

+ +

Or you really got somewhere that's a little bit more personal or things that you want to talk about. So if someone's like, "Yeah, let me tell you about my life goals," and you're like, "Oh, no, wait, sorry. We're out of time." That feels terrible and tragic to do. So I struggle with that part of it.

+ +

CHRIS: I will say actually, on that note, I'm now thinking through, but I believe this to be true. Everyone that reports to me I have a 45-minute one-on-one with, and then my CEO I set up the one-on-one. So I also made that one a 45-minute one-on-one. And that has worked out really well.

+ +

Typically, I try and structure it and reiterate this from time to time of, like, hey, this is your space, not mine. So let's have whatever conversation fits in here. And it's fine if we don't need to use the whole time, but I want to make sure that we have it and that we protect it. Because I often find much like retro, I don't know; I think everything's fine. And then suddenly the conversation starts, and you're like, you know what? Actually, I'm really concerned now that you mentioned it. And you need that sort of empty space that then the reality sort of pop up into.

+ +

And so with one on one, I try and make sure that there is that space, but I'm fine with being like, we can cut this short. We can move on from one-on-one topics to more of status updates; let's talk about the work. But I want to make sure that we lead with is there anything deeper, any concerns, anything you want to talk through? And sort of having the space and time for that.

+ +

STEPH: I like that. And I also think it speaks more directly to the problem I'm having because I'm saying that we keep running over a couple of minutes, and so someone else is waiting. So rather than shorten it, which is where I'm already feeling some pain...although I still think that's a good idea to have a default of 25-minute meetings so then that way, there is a break versus the full 30. So if people want to have back-to-back meetings, they still have a little bit of time in between.

+ +

But for one on ones specifically, upping it to 45 minutes feels nice because then you've got that 15-minute buffer likely. I mean, maybe you schedule a meeting, but, I don't know, that's funky. But likely, you've got a 15-minute buffer until your next one. And then that's also an area that I feel comfortable in sharing with folks and saying, "Hey, I've booked this whole 45 minutes. But if we don't need the whole time, that's fine."

+ +

I'm comfortable saying, "Hey, we can end early, and you can get more of your time back to focus on some other areas." It's more the cutting someone off when they're talking because I have to hop to the next thing. I absolutely hate that feeling. So thanks, I think I'll give that a go. I think I'll try actually bumping it up to 45 minutes, presuming that other people like that strategy too, since they're opting in [laughs] to the 45 minutes structure. But that sounds like a nice solution.

+ +

CHRIS: Well yeah, happy to share it. Actually, one interesting thing that I'm realizing, having been a manager at thoughtbot and then now being a manager within Sagewell, the nature of the interactions are very different. With thoughtbot, I was often on other projects. I was not working with my team day to day in any real capacity. So it was once every two weeks, I would have this moment to reconnect with them. And there was some amount of just catching up. Ideally, not like status update, low-level sort of thing, but sort of just like hey, what have you been working on? What have you been struggling with? What have you been enjoying?

+ +

There was more like I needed bigger space, I would say for that, or it's not surprising to me that you're bumping into 30 minutes not being quite long enough. Whereas regularly, in the one on ones that I have now, we end up cutting them short or shifting out of true one-on-one mode into more general conversation and chatting about Raycast or other tools or whatever it is because we are working together daily. And we're pairing very regularly, and we're all on the same project and all sorts of in sync and know what's going on. And we're having retro together. We have plenty of places to have the conversation.

+ +

So the one-on-one again, still, I keep the same cadence and the same time structure just because I want to make sure we have the space for any day that we really need that. But in general, we don't. Whereas when I was at thoughtbot, it was all the more necessary. And I think for folks listening; I could imagine if you're in a team lead position and if you're working very closely with folks, then you may be on the one side of things versus if you're a little bit more at a distance from the work that they're doing day to day. That's probably an interesting question to ask, and think about how you want to structure it.

+ +

STEPH: Yeah, I think that's an excellent point. Because you're right; I don't see these individuals. We may not have really gotten to interact, except for our daily syncs outside of that. So then yeah, there's always like a good first 10 minutes of where we're just chatting about life and catching up on how things are going before then we dive into some other things. So I think that's a really good point. Cool, solving management problems on the mic. I dig it.

+ +

In slightly different news, I've joined a book club, which I'm excited about. This book club is about Ruby. It's specifically reading the book Ruby Science, which is a book that was written and published by thoughtbot. And it requires zero homework, which is my favorite type of book club. Because I have found I always want to be part of book clubs. I'm always interested in them, but then I'm not great at budgeting the time to make sure I read everything I'm supposed to read. And so then it comes time for folks to get together. And I'm like, well, I didn't do my homework, so I can't join it.

+ +

But for this one, it's being led by Joël, and the goal is that you don't have to do the homework. And they're just really short sections. So whoever's in charge of leading that particular session of the book club they're going to provide an overview of what's covered in whatever the reading material that we're supposed to read, whatever topic we're covering that day. They're going to provide an overview of it, an example of it, so then we can all talk about it together. So if you read it, that's wonderful. You're a bit ahead and could even join the meeting like five minutes late. Or, if you haven't read it, then you could join and then get that update. So I'm very excited about it.

+ +

And this was one of those books that I'd forgotten that thoughtbot had written, and it's one that I've never read. And it's public for anybody that's interested in it. So to cover a little bit of details about it, so it talks about code smells, ways to refactor code, and then also common patterns that you can use to solve some issues. So there's a lot of really just great content that's in it. And I'll be sure to include a link in the show notes for anyone else that's interested.

+ +

CHRIS: And again, to reiterate, this book is free at this point. Previously, in the past, it was available for purchase. But at one point a number of years ago, thoughtbot set all of the books free. And so now that along with a handful of other books like...what's Edward's DNS book? Domain Name Sanity, I believe, is Edward's book name that Edward Loveall wrote when he was not a thoughtboter, [laughs] and then later joined as a thoughtboter, and then we made the book free.

+ +

But on the specific topic of Ruby Science, that is a book that I will never forget. And the reason I will never forget it is that book was written by the one and only CTO Joe Ferris, who is an incredibly talented developer. And when I was interviewing with thoughtbot, I got down to the final day, which is a pairing session. You do a morning pairing session with one thoughtbot developer, and you do an afternoon pairing session with another thoughtbot developer.

+ +

So in the morning, I was working with someone on actually a patch to Rails which was pretty cool. I'd never really done that, so that was exciting. And that went fine with the exception that I kept turning on Caps Lock on their keyboard because I was used to Caps Lock being CTRL, and then Vim was going real weird for me. But otherwise, that went really well. But then, in the afternoon, I was paired with the one and only CTO Joe Ferris, who was writing the book Ruby Science at that time.

+ +

And the nature of the book is like, here's a code sample, and then here's that code sample improved, just a lot of sort of side-by-side comparisons of code. And I forget the exact way that this went, but I just remember being terrified because Joe would put some code up on the screen and be like, "What do you think?" And I was like, oh, is this the good code or the bad code? I feel like I should know. I do not know. I'm not sure. It worked out fine, I guess. I made it through. But I just remember being so terrified at that point. I was just like, oh no, this is how it ends for me. It's been a good run.

+ +

STEPH: [laughs]

+ +

CHRIS: I made it this far. I would have loved to work for this nice thoughtbot company, but here we are. But yeah, I made it through. [laughs]

+ +

STEPH: There are so many layers to that too where it's like, well if I say it's terrible, are you going to be offended? Like, how's this going to go for me if I speak my truths? Or what am I going to miss? Yeah, that seems very interesting (I kind of like it.) but also a terrifying pairing session.

+ +

CHRIS: I think it went well because I think the code...I'd been following thoughtbot's work, and I knew who Joe was and had heard him on podcasts and things. And I kind of knew roughly where things were, and I was like, that code looks messy. And so I think I mostly got it right, but just the openness of the question of like, what do you think? I was like, oh God. [laughs] So yeah, that book will always be in my memories, is how I would describe it.

+ +

STEPH: Well, I'm glad it worked out so we could be here today recording a podcast together. [laughs]

+ +

CHRIS: Recording a podcast together. Now that I say all that, though, it's been a long time since I've read the book. So maybe I'll take a revisit. And definitely interested to hear more about your book club and how that goes.

+ +

But shifting ever so slightly (I don't have a lot to say on this topic.) but there's a new framework technology thing out there that has caught my attention. And this hasn't happened for a while, so it's kind of novel for me. So I tend to try and keep my eye on where is the sort of trend of web development going? And I found Inertia a while ago, and I've been very, very happy with that as sort of this is the default answer as to how I build websites.

+ +

To be clear, Inertia is still the answer as to how I build websites. I love Inertia. I love what it represents. But I'm seeing some stuff that's really interesting that is different. Specifically, Remix.run is the thing that I'm seeing. I mentioned it, I think, in the last episode talking about there was some stuff that they were doing with data loading and async versus synchronous, and do you wait on it or? They had built some really nice levers and trade-offs into the framework. And there's a really great talk that Ryan Florence, one of the creators of Remix.run, gave about that and showed what they were building.

+ +

I've been exploring it a little bit more in-depth now. And there is some really, really interesting stuff in Remix. In particular, it's a meta-framework, I think, is the nonsense phrase that we use to describe it. But it's built on top of React. That won't be true for forever. I think it's actually they would say it's more built on top of React Router. But it is very similar to Next.js for folks that have seen that. But it's got a little bit more thought around data loading. How do we change data? How do we revalidate data after?

+ +

There's a ton of stuff that, having worked in many React client-side API-heavy apps that there's so much pain, cache invalidation. How do you think about the cache? When do you fetch from the network? How do you avoid showing 19 different loading spinners on the page? And Remix as a framework has some really, I think, robust and well-thought-out answers to a lot of that. So I am super-duper intrigued by what they're doing over there. There's a particular video that I think shows off what Remix represents really well. It's Ryan Florence, that same individual, the creator of Remix, building just a newsletter signup page.

+ +

But he goes through like, let's start from the bare bones, simplest thing. It's just an input, and a form submits to the server. That's it. And so we're starting from web 2.0, long, long ago, sort of ideas, and then he gradually enhances it with animations and transitions and error states. And even at the end, goes through an accessibility audit using the screen reader to say, "Look, Remix helps you get really close because you're just using web fundamentals."

+ +

But then goes a couple of steps further and actually makes it work really, really well for a screen reader. And, yeah, overall, I'm just super impressed by the project, really, really intrigued by the work that they're doing. And frankly, I see a couple of different projects that are sort of in this space. So yeah, again, very early but excited.

+ +

STEPH: On their website...I'm checking it out as you're walking me through it, and on their website, they have "Say goodbye to Spinnageddon." And that's very cute. [laughs]

+ +

CHRIS: There's some fundamental stuff that I think we've just kind of as a web community, we made some trade-offs that I personally really don't like. And that idea of just spinners everywhere just sending down a ball of application logic and a giant JavaScript file turning it on on someone's computer. And then immediately, it has to fetch back to the server. There are just trade-offs there that are not great. I love that Remix is sort of flipping that around.

+ +

I will say, just to sort of couch the excitement that I'm expressing right now, that Remix exists in a certain place. It helps with building complex UIs. But it doesn't have anything in the data layer. So you have to bring your own data layer and figure out what that means. We have ActiveRecord within Rails, and it's deeply integrated. And so you would need to bring a Prisma or some other database connection or whatever it is. And it also doesn't have more sort of full-featured framework things. Like with Rails, it's very easy to get started with a background job system. Remix has no answer to that because they're like, no, no, this is what we're doing over here.

+ +

But similarly, security is probably the one that concerns me the most. There's an open conversation in their discussion portal about CSRF protection and a back and forth of whether or not Remix should have that out of the box or not. And there are trade-offs because there are different adapters that you can use for auth. And each would require their own CSRF mitigation. But to me, that is the sort of thing that I would want a framework to have.

+ +

Or I'd be interested in a framework that continues to build on top of Remix that adds in background jobs and databases and all that kind of stuff as a complete solution, something more akin to a Rails or a Laravel where it's like, here we go. This is everything. But again, having some of these more advanced concepts and patterns to build really, really delightful UIs without having to change out the fundamental way that you're building things.

+ +

STEPH: Interesting. Yeah, I think you've answered a couple of questions that I had about it. I am curious as to how it fits into your current tech stack. So you've mentioned that you're excited and that it's helpful. But given that you already have Rails, and Inertia, and Svelte, does it plug and play with the other libraries or the other frameworks that you have? Are you going to have to replace something to then take advantage of Remix? What does that roadmap look like?

+ +

CHRIS: Oh yeah, I don't expect to be using Remix anytime soon. I'm just keeping an eye on it. I think it would be a pretty fundamental shift because it ends up being the server layer. So it would replace Rails. It would replace the Inertia within the stack that I'm using. This is why as I started, I was like, Inertia is still my answer. Because Inertia integrates really well with Rails and allows me to do the sort of it's not progressive enhancement, but it's like, I want fancy UI, and I don't want to give up on Rails. And so, Inertia is a great answer for that. Remix does not quite fit in the same way. Remix will own all of the request-response lifecycle.

+ +

And so, if I were to use it, I would need to build out the rest of that myself. So I would need to figure out the data layer. I would need to figure out other things. I wouldn't be using Rails. I'm sure there's a way to shoehorn the technologies together, but I think it sort of architecturally would be misaligned. And so my sense is that folks out there are building...they're sort of piecing together parts of the stack to fill out the rest.

+ +

And Remix is a really fantastic controller and view from their down experience and routing layer. So it's routing, controller, view I would say Remix has a really great answer to, but it doesn't have as much of the other stuff. Whereas in my case, Inertia and Rails come together and give me a great answer to the whole story.

+ +

STEPH: Got it. Okay, that's super helpful.

+ +

CHRIS: But yeah, again, I'm in very much the exploratory phase. I'm super intrigued by a lot of what I've seen of it and also just sort of the mindset, the ethos of the project as it were. That sounds fancy as I say it, but it's what I mean. I think they want to build from web fundamentals and then enhance the experience on top of that, and I think that's a really great way to go. It means that links will work. It means that routing and URLs will work by default.

+ +

It means that you won't have loading spinner Armageddon, and these are core fundamentals that I believe make for good websites and web applications. So super interested to see where they go with it. But again, for me, I'm still very much in the Rails Inertia camp. Certainly, I mean, I've built Sagewell on top of it, so I'm going to be hanging out with it for a while, but also, it would still be my answer if I were starting something new right now.

+ +

I'm just really intrigued by there's a new example out there in the world, this Remix thing that's pushing the envelope in a way that I think is really great. But with that, my now…what was that? My second or my third rave? Also called the positive rant, as we call it. But yeah, I think on that note, what do you think? Should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+x1Mr1-Cz + + ]]> + + Chris Toomey + Steph Viccari + + + 343: Opt-In To Oversharing + https://bikeshed.thoughtbot.com/343 + 6ba4d941-c0bf-4628-b905-55c4f08a64de + Tue, 21 Jun 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris is weathering through a slight lull, a holding period, where his team waits for new features to become available with some of the platforms they integrate with, and as they think out new facets of the platform they're building. + +Steph has been thinking recently about working in isolation. It's a topic that Joël Quenneville pointed out to her and mentioned. Can engineers work in isolation and be successful? + 30:31 + no + + + Chris is weathering through a slight lull, a holding period, where his team waits for new features to become available with some of the platforms they integrate with, and as they think out new facets of the platform they're building. +Steph has been thinking recently about working in isolation. It's a topic that Joël Quenneville pointed out to her and mentioned. Can engineers work in isolation and be successful? +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Always be singing. +STEPH: I can't remember if I've shared the story with you. But I had a beautiful little human moment with someone at airport security. Because when I travel with my mic, I always get stopped because there's the middle long, thin piece that looks like what you would screw on to a gun like for a silencer. And so [laughs] as he was going through, the person was looking at it, and then he called over a buddy. And then they called over another buddy, and there's like three TSA agents all looking at the X-ray screen. And finally, they're like, "Yeah, we need to flag it." So they moved it over. +And then he was digging through, and he pulled out the big metal piece. And I said, "It's for a microphone." And he's like, "Okay," and he kept looking, and then he finally found the microphone. And he lit up because I guess he wasn't really sure to believe me at first when I said it. But he lit up, and he was like, "Karaoke?" [laughs] I was like, "No, it's for podcasting." +CHRIS: But not 100% no because we do sing plenty on this show, so... +STEPH: I think that's what made me think of it. It was your singing. [laughs] +CHRIS: Yep. My wonderful, wonderful singing. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly Podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris? What's new in your world? +CHRIS: What's new in my world? We are in sort of a...what's the word? There's a bit of a lull right now, not like a big lull, but we had a bunch of clear work that came into the team, did a bunch of iterations, some testing, built some new features, et cetera. And now there's a small holding period basically where we wait for some new features to become available with some of the platforms that we integrate with and also as we think out some new facets of the platform that we're building. +So we've got this little bit of time here where we're not necessarily building out as many new novel features. But instead, as a dev team, we're taking this moment to be like, oh, cool, let's tie down. I want to make a sailing analogy here, but I don't know sailing. It's like tie down the somethings and batten the hatches, maybe. That sounds like a thing. [chuckles] But so we have a couple of projects going right now. We want to really accept the truth and lean into Sidekiq. So right now, we have a mix of ActiveJob and Sidekiq jobs. And they're confusing, and et cetera, et cetera. +So we want to kind of lean into that, upgrade dependencies, that sort of thing. We are, again, doing a little bit of work on the observability foundation of our system. so how do we know what's going on at runtime? Also, working on just some core features and functionality. We have done a little bit of an exploration into the event processing stuff, some of that that I've been talking about. It's actually been very interesting. So we're working with Customer.io as a platform, which is omnichannel communication behavior-based messaging sort of thing. So when a user does X, send them an email and then wait three days. And if they haven't responded, then do this other thing. +And I think I've said this in previous episodes; I'm so wildly impressed with that platform. They have done such a good job. And I know that good software doesn't happen in a vacuum. In fact, if we're being honest, a lot of the software out there is not very good. And not only do they do a good job, but it's across...there's a ton of functionality in Customer.io. +And it's interesting because we're finding ourselves leaning into it even more because it is such a solid platform and because it connects into our event system. Like, it's a segment destination, so all of our analytics events get piped into Customer.io, and then we can action on any of them. And the actions can be quite complicated. +And this is where we're getting into good idea, terrible idea space. And to be clear, this is still just an exploration. But we basically wanted a way to do more. There are a bunch of different actions that you can take so, like send an email, send an SMS, or there are a couple of other slightly fancier ones. You can trigger an event within the Customer.io system. You can actually do an arbitrary HTTP POST, PUT, PATCH, whatever, any web requests you want to make. So if you want to integrate with essentially anything else out there, you can do that. You can send some structured data over the wire. +And so we've now been like, okay, what if, and stay with me here, what if we use our analytic system and we send events whenever a user does something, and then that event eventually trickles down to Customer.io? Within that, we allow ourselves to respond to that event by emitting a different event within the system, within Customer.io. And then, via the webhook functionality, we fire that back to the Rails application. And then there we can do whatever we want. +And in a way, that sounds absurd because we're starting from our app, and then we're sending some events down, processing them in certain ways, sending it back to the app, and then maybe doing something. In particular, one of the things we want to do is richly formatted Slack alerts. And Customer.io has a Slack alert functionality, but they can't have any of the fancy stuff. They can't link to our customer in the admin dashboard. So we found that that functionality is particularly useful for our admin team. And so we're like, ah, this feels weird. +But if we were to do this loop out and back, then ideally, we get the power of Customer.io for non-technical users or non-engineering team users to configure workflows and to say, "When a user does this, I actually want to alert the admin team via Slack." And we want it to be rich and have buttons that you can click and all that kind of stuff. And although the thing that I just described seems complicated, is a word that I'll use for it, confusing at times, it isn't...like, I don't want to do all of that in the app. +I don't want the app to have to think about how do I wait three days? We technically can do that with Sidekiq, but it gets us in trouble and whatnot, whereas Customer.io that's a core concept for them. And so, again, very much exploration. This will probably be a future good idea, terrible idea segment. But that's been an interesting one to explore. +STEPH: You have quite a talent for you preface something as a bad idea, and you do a very good job of making it sound reasonable and good. [laughs] So it's interesting to be on that side of like, good idea, bad idea. It's like, I'm looking for the bad. And I have questions, but overall, [chuckles] you do a very good job of being very thoughtful and walking through why it makes sense or what are the benefits of it. So you answered some of my questions around why still send it to Customer.io versus just having it all in-house. So the fact that the admin team has access to it makes a lot of sense. +I want to clarify one point. So when you send it to Customer.io, Customer.io then needs to send a message back to your application. And then that's when you customize the Slack message. Do you need Customer.io to send that message, or could you just fire off an event to Customer.io to say, "Hey, capture this, but don't do anything with this. And then we're going to send the Slack message because we want to customize it."? +CHRIS: I think the key is that we want to leverage the fact that Customer.io is the platform that our operations team really is now becoming comfortable with and using for this behavioral automation workflow type logic. So that idea of when this event, you know, when this triggering event happens, if this condition is true, then respond in this way. +And so because Customer.io is the platform that A, is quite good at that and B, is where our admin team is now thinking about doing that, one thing that we might do let's say a user completes some action within the application. So they fill out a form to submit their interest in some new platform feature. Initially, what we might want to do there is alert ourselves to say, "Hey, this happened. Take some action." And then eventually, we may want to instead switch that over and send an email to the customer with the next steps that they need to do. +And the ability to gradually transition across that spectrum is really interesting to me, and again, Customer.io being the platform, sort of the hub for how we respond to these events. At the same time, I know that this feels like a generic message processing system that might be a Kafka queue somewhere else. And so I've got that in the back of my head of like, is this weird? I think it's a little weird. But it also, thus far as we're exploring it, is very approachable for the admin team, very familiar for them, and reasonably powerful. +And also, there's a drag and drop editor for the events and the payloads. And it knows for this event, here's the stuff that's available to you. And so the ability for our admin team to interact with that interface is really great. And we don't have to build it. We don't have to think about it. But I will say I've worked at so many different companies that have their ad hoc system that makes it easy to do generic X, Y, and Z. And it's bad, and it falls down. And it's impossible to know when anything happens. +And so, I've got a lot of concerns in the back of my head, which I will want to at least think through and understand the trade-offs that we're making if we pursue this path, but it is very interesting to me. So right now, a lot of this logic does live in the app. But it means that it requires a code change for anything that we want to do like this. We want to have a Slack alert whenever X happens. Now, the developers are in the loop for all of that. And really, it's the operations team that owns the decisioning on that. +And so if they can also self-serve and instrument the action, the alert, the follow-up, the whatever it is, if we can give them those primitives in a platform that they already understand, that sounds nice. I'm intrigued, is what I'll say. So anyway, while we're in this lull period, we are trying out some fun stuff like that and exploring those sorts of things. +STEPH: I like that perspective that you're putting on it, or at least the one that's standing out to me is the concept of ownership is like who gets to own these actions. But then beyond that, that's the part where I feel a little squirmy is, so we are using this third-party tool because it makes life easier. But then, at what point when we start building software around this third-party tool to then customize it back on our own side. Then if someone is in Customer.io, so if an admin user is in there and then they trigger an event, is there going to be confusion as to what's going to happen? And can they retry an event? +Because I'm realizing my initial suggestion where it was like, hey, notify Customer.io that this is there but then also manage sending the Slack message that would prevent them from being able to have that retry capability. And that may be very much worth preserving. So then it's understood that hey, if you want to manage this, we are giving you full access to manage this work. We may customize it, but this is still the interface in which you go through to have three tries or to manage that workflow or these actions that get sent to users. +CHRIS: Yeah. I think you've perfectly highlighted the why this might not be a great idea or at least the concerns to explore before adopting this more thoroughly. And even just the idea of adopting it more thoroughly, like, how tied into the system are we? How business-critical does this new external piece of software become? Because I've seen that to be really problematic where there are organizations that I've worked with that are like, "Oh God, we would love to move off of system X. But unfortunately, it's basically the one thing holding this business up." And I'm like, yeah, I get that. And that happens. So yeah, being really intentional with that. +And that's why we're very much in an exploration place. But we have a bunch of stuff that we've done that required engineering work. And we're now seeing like, actually, could we map this into this other tool? And can we build the set of primitives in that space that now this team can own that whole experience? And then critically, can they debug it? Will we know when something goes wrong, et cetera? Those are always parts. At this point, I don't think I can just imagine a happy path. And I hope this isn't true for the rest of my life. +But the work as a software developer, especially after having done a couple of rounds of it and as a consultant, I just imagine failure modes. It's all I do. I'll be like, okay, we just need to wire X up to Z, and then we need to fire off a request. And then, once we get the message back, then we can process them. I'm like, right. You just described 13 things that can go wrong. Now let's imagine each of the different failure states because that's all I'm going to do. +Who cares about the happy path? Those are easy. Those write themselves. It's all of the failure modes that I need to think about. And someday, when I retire, and I go to a log cabin in the woods, and I don't talk to people for a while, maybe I'll go back to a place of only happy paths. But that is not my truth right now. +STEPH: I can't tell you how many people in my personal life I have annoyed so much [laughs] because all I see are failure modes. And one, that's a delightful t-shirt. [laughs] I'd love to have that. And then yeah, I feel you because there are so many times where someone is...like, I'm with someone who's like a big idea person. And so they're just launching into what-ifs, and we did this. And I can't help it, and I have learned to help it. +But it has been a struggle with some strong feedback from family and friends to reel it in. Because then I will start to think through okay, well, what's the details? And I have some questions. What happens when this happens? And yeah, all I see are failure modes. [laughs] It is very true for me too, and not always...not so great. So I, too, shall get a log cabin one day and try to forget all of that. +CHRIS: I will say I painted that as a particularly glib version of myself. But some of what I'm doing right now, particularly joining an early-stage startup and taking the role of CTO, was very much to try and intentionally resist that. Because right now, I have to be really careful with how much of the potential edge cases and whatnot. I'm considering exactly how robust of a platform are we building? Very is the answer. But what about extremely? Because extremely is an option but extremely costs four times as much. Mostly in time being the critical element there. +And so part of the work that I'm doing now is just trying to push on those edges, push on those boundaries, find the places where we can move quickly, and still build a robust platform because frankly, we're building...Sagewell is a financial platform under the hood, and I can't be flippant with that. We as a team have to be really careful with the thing that we're building. But we also have to move quickly. +We have to be able to iterate. We have to be able to build something and try it out and see if it works. And then, if it doesn't, maybe shelve it and pull it out of the codebase. And it has been a real challenge, but it was the challenge that I wanted here. And so I've been enjoying that work, but it has been a stretch, a growth moment, let's call it. +STEPH: I don't know if you've shared that particular goal with me in transitioning to a CTO role, but I really, really like it. One, it's very aligned with who you are. You're very thoughtful, and you look for areas to push and ways to do that. And then I also struggle in those areas, and thoughtbot specifically and consulting has helped push me in directions, push me out of my comfort zones but still in a safe space where I have other people to talk to as I'm making those decisions and pushing past the comfort areas that I have. +But one of them is that I will initially think things have to be perfect or really planned. And I had a really nice conversation with Chad Pytel, who is one of the Founders of thoughtbot and also COO and host of the Giant Robots Smashing Into Other Giant Robots Podcast. And we were chatting about a new offering that thoughtbot is bringing to the market. And it's one that I've been involved with. And I started getting really in the weeds of like, but we really have to plan out how this is going to look and all the actions that need to take place before then we can really sell this type of engagement to a new client. +And as I was going through this list of worries, when I was done, he mentioned he's like, "All of those are valid and something to consider." He's like, "But we don't have any customers yet." So the first part is we feel that we are in a space that we have enough of information to get started. And it's something that we've done before. And then, we'd like to see where customers align with us on this need because we're going to end up shaping this work in response to what their needs are. And so, we can't really begin that shaping until we understand more of what people are looking for. +I was like, oh yeah, that's such a nice point. It just reminded me in regard to pushing those boundaries of yes, we need planning upfront, and we look for failure modes. But then there's also an important aspect of then finding ways to keep moving forward and getting more feedback and then balancing those two. +CHRIS: Yeah, I think that's definitely right the as always, anchoring it to the customer. What is it that they need? How do we connect with them and hear from them? And ideally, keep those feedback loops as short as possible. That's the game, and everything else fits around that. But yeah, so we're trying some stuff. We'll see how it goes. I will certainly report back, depending on how it plays out. But that's a little bit of what's up in my world. What's up in your world? +STEPH: I have been thinking recently about working in isolation. It's a topic that Joël Quenneville, who's another thoughtboter and has been on the show a number of times, it was a topic that he'd actually pointed out to me and mentioned. And so, I wanted to bring that here and share it with you because I'd love to get some of your thoughts on this as well. But I've typically had the viewpoint that when developers are sent off to work on a large, nebulous task, that it's a recipe for disaster, and almost everyone's going to lose in that scenario. And it tends to be a combination of isolation, very distant due dates, and loosely defined scope that leads to those really poor results. +However, as developers, it's not inconceivable for us to land in that position. And it's very similar to my current project, who I'm working with Joël on, where we were given a very fuzzy project with some really aggressive goals, and the engagement is going really well. So that led Joël and I to wonder why is this working? This is the thing that we said that people should never do, but it's actually going quite well for us. +So reflecting upon some of the things that are working well for us, even though we are in more of an isolated state than we would typically work, some of the things that I've been reflecting on or some of the strategies I should say that we've applied to this situation is number one, we did work hard to plug into an existing team. So when we joined, we joined more of an ad hoc volunteer team. +And in everybody's spare time, those individuals were then contributing to the CI process in terms of trying to speed things up and improve things for the rest of the team. But otherwise, there wasn't really a team. There wasn't much structure to it. So it felt like everybody was very much off in their own world doing their own thing, occasionally putting up some code changes for review. And then you had to gain a lot of context to understand what it was that they were doing. +So one of the things that I advocated for early on that I thought was more of just my personal preference but I think has actually worked well in regards to the success of the project as well is to plug into an existing team. So even if you are not working with that team on their day-to-day tasks, but you want to have more people to interact with and more people to share your context with. So you are essentially reducing the isolation of you're no longer these two people who are off in a corner working on something, and nobody has any idea what you're doing, and only one person is getting a status update. +There is now a whole channel or team of people that have some insight as to what's going on. And they can also really unblock you for when you get stuck because then if you do have a question, but there's that one person who has been like your go-to person for this whole project, if they're out on vacation, or if they leave, or just something happens, you're suddenly blocked. +And you don't know who to go to because you've been part of this larger company, but you haven't interacted with anybody outside of that one person. So at least if you're plugged into another team, you've immediately got some friends or some other people to go to and say, "Hey, I'm not sure who can help me with this, but I have this problem." And then, from there, you can get more help. +CHRIS: This is super interesting. To start, I really like that you're framing this in terms of this is a thing that we often recommend against or see as an anti-pattern, and yet in this particular case, it's working. Let's look at that. Because I think the things that you're like, huh, that's interesting. That phrase "Huh, that's interesting" is very interesting. It often highlights like oh, something is behaving counter to how we would expect it to, so let's dig in and explore that. And so I love that that was the reaction and then sort of the conversation that spilled out of that. +I'm also not super surprised that the combination of you and Joël were able to find a way to make this successful because you are two of the most capable developers that I've worked with but also particularly excellent communicators and advocates for the work that you're doing and the way that one should do the work. So the idea that there's a situation that may not be the ideal mode of working and that you're able to take that and say, "What if we shift it just a little bit and make it a little bit more manageable and whatnot?" So unsurprised, frankly, that you found a way collectively to make this a little bit better. +And then I think yeah, it sounds like you're doing the things...so just like, we're in isolation, hmm, that doesn't seem great. Let's unisolate and connect to some people, and that just feels so true. I'm very interested to hear, though. I'm guessing there's more to this story or other things that you've done. Are there other tactics or ways that you've shifted this around? +STEPH: Yeah, there's a couple more. So this is one that (And thank you for the kind words.) this was one that I think Joël is really exceptional at. So Joël is really good at building diagrams and graphs and then sharing that with the team as sort of like we've spent a couple of days understanding this big, messy concept. Here's a nice condensed graph that shows how we went about understanding this. And then here's the big overall picture of what we've learned from this, which has been wonderful for so many reasons. +And every time that we share something with the team, one, it just helps build camaraderie, especially in remote days, it just builds camaraderie on hey, we're all online. And we're working. And here's the thing that I'm working through or struggling with or something that I learned. I often do that, especially when I get frustrated and something goes wrong. I love to share the I did this today. It went terribly. [laughs] Let me tell you about it, so you're aware of it in case it helps you. +And specifically, the diagrams are really nice because then other people can just see and appreciate it, or they can point something out that we didn't know. Or they'll see a different angle because they're more familiar with the system. So they can say, "Oh yeah, that totally makes sense," or "I had no idea that was happening." So that's been a really nice way to engage with the team. +And so, essentially, the little title for that strategy is just overshare. Just share all the things that you're doing and find ways to make it digestible for the team so then they can go along on this big, nebulous journey with you. And you can also put it in threads so that way, you're not flooding a channel, but then people can opt-in to that oversharing if they would like more insight into the work that you're doing. +CHRIS: Opt-in to that oversharing. [laughs] +STEPH: Exactly. I mean, it's not forced oversharing; it's just it's here if people would like it. That was a really nice compliment that some other thoughtboters received from their client team is someone had mentioned that there's so much information that's getting shared from the thoughtboters that they had trouble keeping up. And they really liked that. They really appreciated that they could then go check out this channel or these threads and see exactly the type of work that was happening and the outcomes of it. And then they could just check it maybe beginning of the day, end of the day and get that knowledge dump. +Some of the other strategies that we've used are giving ourselves mini-goals to accomplish as part of the larger, more nebulous task. So as we have this very large goal in mind, it's like, where's the small piece? Where's an entry point? What's a task or a goal that we can define? And then we want to break that down into what questions do we need to ask? How can we start moving in this direction? And we want to find something that has an answer. +So each time that we start researching once we've gotten to that point...and this is hard. I feel like people may know that, but I should just say that this is hard to take something nebulous and then find the entry point and break down some goals. And that has been one of the wonderful parts of then having a buddy for this type of project because then we can bounce ideas off of each other. +And we can also help the other person not go too deep into an area. Because I have definitely had moments where I've been very passionate about like, "We need to do this," and Joël is just like, do we? And I'm like, "Yeah." And he's like, "Do we though?" And I'm like, "I guess not. I just really, really want to." [laughs] It's been very helpful to have a partner balance some of those feelings. +And once you can break down some of that amorphous problem into those smaller goals, then you can also create tickets, which is also a really nice way to then surface the work that you're doing. You can document how you're researching, document the question. And then once you have that question of what you're in search of, it's so nice because then once you find the answer, that's immediately a good moment to pause and reflect. +So I think in a recent episode, we were chatting about this where Joël and I were trying to understand why the tests weren't being balanced properly across each process that was available. And we found the answer, and we started immediately digging into fixing it or solutions. And then it took us a moment to go back and say, "Actually, this ticket is really just about understanding the problem, not fixing the problem." And so that was a nice; now that we understand the problem, let's go back high-level to define our next goal from this big, nebulous task because maybe fixing that balancing is the right thing to do, but maybe not, and we just need to reconsider. +So for that portion of breaking down a big, nebulous task and then identifying smaller tasks that you can achieve, time-boxing has been huge for us in regards of what’s something that we can accomplish this week, or what's something we can accomplish today that will then move us forward? And then making sure that we are setting deadlines for ourselves. So normally, this is another area where it's like, huh, that's interesting. I'm a big believer in deadlines. But I do think self-imposed deadlines are really helpful. +CHRIS: I'm intrigued to hear you say that you're not a big fan of deadlines because I assume we're actually more aligned on this. But deadlines that are arbitrary and also come with fixed scope and other immovable things, yes, those are the worst in the world. But deadlines that we set for ourselves, and then we use that as a mechanism to hone and refine the scope that we're going to get out the door by that deadline, I find those incredibly useful. And that sounds like that's the same sort of thing you have going on here is like by saying we're willing to expend this much to get a result, that defines the work going into it. +STEPH: Yeah, that's fair. Everything that you said is true, too; in regards to, I'm realizing I default that when I hear the word deadline, I'm so used to teams having deadlines that are defined by other individuals that are not part of the work. And as you said, the scope has already been defined, and it can't be changed. And it's all of the bad things that then go with it. +So when I think of deadlines, I immediately think of that type of deadline versus the more self-imposed, yes, we can revisit, yes, the team has bought in and understands why this is important. Those types of deadlines are very helpful. It's that first part that I default to that I think of immediately, and I need some reassurance that that is not the type of deadline that I'm looking at or being forced to meet. +I have a very similar feeling for estimates. Like, those both fall in the same category for me is; as soon as I hear estimation and deadline, I get nervous. And then I just need to understand the purpose of both and who is setting both of those and the communication around them. And then what does that failure mode look like, the one that we're always looking for? So yeah, deadlines and estimations fit into that. Initially, I'm very hesitant and cautious, but I think they're both very good tools. +CHRIS: Yeah, I feel like those are very closely related. And they're definitely tools that can be used for great good or for great evil. And so, ideally, we advocate for the great good usage. But more generally, I love, again, the sharing around the process and what's worked for you in this less typical or often somewhat problematic workflow. I will say, again, so I gave you the series of compliments earlier, and I stand by those compliments for you and Joël. +But I think also the sort of related aspect is that you two are both quite senior, very capable, very comfortable suggesting changes, suggesting workflows. So I think the potential dangers of isolation are still very much there. And the fact that the two of you have been able to find a way to work more effectively and perhaps change the terms of things just a little bit to make this effective is A, unsurprising but B, not something that I would expect of every team. +I think you've described a wonderful list of the specifics as to how you did that. And ideally, if folks that are perhaps a little earlier on in their career are sent out for a month with a wild project, and they're sent to do it in isolation, hopefully, they can borrow from that list. But again, I do think this is a thing that, from an organizational perspective, we should be very careful with when we're imposing this isolation on it because it takes two fantastic folks like you and Joël to break out of the shackles of it. +STEPH: The more we're talking about this, the more apparent it's also becoming that I started with this; how do you manage isolation? And my answer is you get out of it. [laughs] Get out of isolation as quickly as possible. Someone thought it was a good idea to put you there or a good idea to structure it that way. Or maybe they didn't mean it intentionally, but that's how things then shook out. So that's really what a lot of those strategies are about is, then how do I get myself out of this corner that you put me in? Because nobody put Stephanie in a corner. +So it's essentially that's all the strategies are looking for ways to say, hey, I'm isolated, but I really don't want to be, and it's dangerous for me to be isolated in this way. Even as a more senior capable developer, it's more likely that things could go wrong, and miscommunications, misaligned expectations. So I need to find ways to then bring the work that I'm doing to make it more relevant to other people on the team. So then we can have more overlap, or at least I can share a lot of the work that's being done. +CHRIS: Yeah, absolutely. I think with that wonderful summary and, frankly, utterly fantastic movie reference, what do you think? Should we wrap up? +STEPH: Let's do it. Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris is weathering through a slight lull, a holding period, where his team waits for new features to become available with some of the platforms they integrate with, and as they think out new facets of the platform they're building.

+ +

Steph has been thinking recently about working in isolation. It's a topic that Joël Quenneville pointed out to her and mentioned. Can engineers work in isolation and be successful?

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Always be singing.

+ +

STEPH: I can't remember if I've shared the story with you. But I had a beautiful little human moment with someone at airport security. Because when I travel with my mic, I always get stopped because there's the middle long, thin piece that looks like what you would screw on to a gun like for a silencer. And so [laughs] as he was going through, the person was looking at it, and then he called over a buddy. And then they called over another buddy, and there's like three TSA agents all looking at the X-ray screen. And finally, they're like, "Yeah, we need to flag it." So they moved it over.

+ +

And then he was digging through, and he pulled out the big metal piece. And I said, "It's for a microphone." And he's like, "Okay," and he kept looking, and then he finally found the microphone. And he lit up because I guess he wasn't really sure to believe me at first when I said it. But he lit up, and he was like, "Karaoke?" [laughs] I was like, "No, it's for podcasting."

+ +

CHRIS: But not 100% no because we do sing plenty on this show, so...

+ +

STEPH: I think that's what made me think of it. It was your singing. [laughs]

+ +

CHRIS: Yep. My wonderful, wonderful singing.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly Podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris? What's new in your world?

+ +

CHRIS: What's new in my world? We are in sort of a...what's the word? There's a bit of a lull right now, not like a big lull, but we had a bunch of clear work that came into the team, did a bunch of iterations, some testing, built some new features, et cetera. And now there's a small holding period basically where we wait for some new features to become available with some of the platforms that we integrate with and also as we think out some new facets of the platform that we're building.

+ +

So we've got this little bit of time here where we're not necessarily building out as many new novel features. But instead, as a dev team, we're taking this moment to be like, oh, cool, let's tie down. I want to make a sailing analogy here, but I don't know sailing. It's like tie down the somethings and batten the hatches, maybe. That sounds like a thing. [chuckles] But so we have a couple of projects going right now. We want to really accept the truth and lean into Sidekiq. So right now, we have a mix of ActiveJob and Sidekiq jobs. And they're confusing, and et cetera, et cetera.

+ +

So we want to kind of lean into that, upgrade dependencies, that sort of thing. We are, again, doing a little bit of work on the observability foundation of our system. so how do we know what's going on at runtime? Also, working on just some core features and functionality. We have done a little bit of an exploration into the event processing stuff, some of that that I've been talking about. It's actually been very interesting. So we're working with Customer.io as a platform, which is omnichannel communication behavior-based messaging sort of thing. So when a user does X, send them an email and then wait three days. And if they haven't responded, then do this other thing.

+ +

And I think I've said this in previous episodes; I'm so wildly impressed with that platform. They have done such a good job. And I know that good software doesn't happen in a vacuum. In fact, if we're being honest, a lot of the software out there is not very good. And not only do they do a good job, but it's across...there's a ton of functionality in Customer.io.

+ +

And it's interesting because we're finding ourselves leaning into it even more because it is such a solid platform and because it connects into our event system. Like, it's a segment destination, so all of our analytics events get piped into Customer.io, and then we can action on any of them. And the actions can be quite complicated.

+ +

And this is where we're getting into good idea, terrible idea space. And to be clear, this is still just an exploration. But we basically wanted a way to do more. There are a bunch of different actions that you can take so, like send an email, send an SMS, or there are a couple of other slightly fancier ones. You can trigger an event within the Customer.io system. You can actually do an arbitrary HTTP POST, PUT, PATCH, whatever, any web requests you want to make. So if you want to integrate with essentially anything else out there, you can do that. You can send some structured data over the wire.

+ +

And so we've now been like, okay, what if, and stay with me here, what if we use our analytic system and we send events whenever a user does something, and then that event eventually trickles down to Customer.io? Within that, we allow ourselves to respond to that event by emitting a different event within the system, within Customer.io. And then, via the webhook functionality, we fire that back to the Rails application. And then there we can do whatever we want.

+ +

And in a way, that sounds absurd because we're starting from our app, and then we're sending some events down, processing them in certain ways, sending it back to the app, and then maybe doing something. In particular, one of the things we want to do is richly formatted Slack alerts. And Customer.io has a Slack alert functionality, but they can't have any of the fancy stuff. They can't link to our customer in the admin dashboard. So we found that that functionality is particularly useful for our admin team. And so we're like, ah, this feels weird.

+ +

But if we were to do this loop out and back, then ideally, we get the power of Customer.io for non-technical users or non-engineering team users to configure workflows and to say, "When a user does this, I actually want to alert the admin team via Slack." And we want it to be rich and have buttons that you can click and all that kind of stuff. And although the thing that I just described seems complicated, is a word that I'll use for it, confusing at times, it isn't...like, I don't want to do all of that in the app.

+ +

I don't want the app to have to think about how do I wait three days? We technically can do that with Sidekiq, but it gets us in trouble and whatnot, whereas Customer.io that's a core concept for them. And so, again, very much exploration. This will probably be a future good idea, terrible idea segment. But that's been an interesting one to explore.

+ +

STEPH: You have quite a talent for you preface something as a bad idea, and you do a very good job of making it sound reasonable and good. [laughs] So it's interesting to be on that side of like, good idea, bad idea. It's like, I'm looking for the bad. And I have questions, but overall, [chuckles] you do a very good job of being very thoughtful and walking through why it makes sense or what are the benefits of it. So you answered some of my questions around why still send it to Customer.io versus just having it all in-house. So the fact that the admin team has access to it makes a lot of sense.

+ +

I want to clarify one point. So when you send it to Customer.io, Customer.io then needs to send a message back to your application. And then that's when you customize the Slack message. Do you need Customer.io to send that message, or could you just fire off an event to Customer.io to say, "Hey, capture this, but don't do anything with this. And then we're going to send the Slack message because we want to customize it."?

+ +

CHRIS: I think the key is that we want to leverage the fact that Customer.io is the platform that our operations team really is now becoming comfortable with and using for this behavioral automation workflow type logic. So that idea of when this event, you know, when this triggering event happens, if this condition is true, then respond in this way.

+ +

And so because Customer.io is the platform that A, is quite good at that and B, is where our admin team is now thinking about doing that, one thing that we might do let's say a user completes some action within the application. So they fill out a form to submit their interest in some new platform feature. Initially, what we might want to do there is alert ourselves to say, "Hey, this happened. Take some action." And then eventually, we may want to instead switch that over and send an email to the customer with the next steps that they need to do.

+ +

And the ability to gradually transition across that spectrum is really interesting to me, and again, Customer.io being the platform, sort of the hub for how we respond to these events. At the same time, I know that this feels like a generic message processing system that might be a Kafka queue somewhere else. And so I've got that in the back of my head of like, is this weird? I think it's a little weird. But it also, thus far as we're exploring it, is very approachable for the admin team, very familiar for them, and reasonably powerful.

+ +

And also, there's a drag and drop editor for the events and the payloads. And it knows for this event, here's the stuff that's available to you. And so the ability for our admin team to interact with that interface is really great. And we don't have to build it. We don't have to think about it. But I will say I've worked at so many different companies that have their ad hoc system that makes it easy to do generic X, Y, and Z. And it's bad, and it falls down. And it's impossible to know when anything happens.

+ +

And so, I've got a lot of concerns in the back of my head, which I will want to at least think through and understand the trade-offs that we're making if we pursue this path, but it is very interesting to me. So right now, a lot of this logic does live in the app. But it means that it requires a code change for anything that we want to do like this. We want to have a Slack alert whenever X happens. Now, the developers are in the loop for all of that. And really, it's the operations team that owns the decisioning on that.

+ +

And so if they can also self-serve and instrument the action, the alert, the follow-up, the whatever it is, if we can give them those primitives in a platform that they already understand, that sounds nice. I'm intrigued, is what I'll say. So anyway, while we're in this lull period, we are trying out some fun stuff like that and exploring those sorts of things.

+ +

STEPH: I like that perspective that you're putting on it, or at least the one that's standing out to me is the concept of ownership is like who gets to own these actions. But then beyond that, that's the part where I feel a little squirmy is, so we are using this third-party tool because it makes life easier. But then, at what point when we start building software around this third-party tool to then customize it back on our own side. Then if someone is in Customer.io, so if an admin user is in there and then they trigger an event, is there going to be confusion as to what's going to happen? And can they retry an event?

+ +

Because I'm realizing my initial suggestion where it was like, hey, notify Customer.io that this is there but then also manage sending the Slack message that would prevent them from being able to have that retry capability. And that may be very much worth preserving. So then it's understood that hey, if you want to manage this, we are giving you full access to manage this work. We may customize it, but this is still the interface in which you go through to have three tries or to manage that workflow or these actions that get sent to users.

+ +

CHRIS: Yeah. I think you've perfectly highlighted the why this might not be a great idea or at least the concerns to explore before adopting this more thoroughly. And even just the idea of adopting it more thoroughly, like, how tied into the system are we? How business-critical does this new external piece of software become? Because I've seen that to be really problematic where there are organizations that I've worked with that are like, "Oh God, we would love to move off of system X. But unfortunately, it's basically the one thing holding this business up." And I'm like, yeah, I get that. And that happens. So yeah, being really intentional with that.

+ +

And that's why we're very much in an exploration place. But we have a bunch of stuff that we've done that required engineering work. And we're now seeing like, actually, could we map this into this other tool? And can we build the set of primitives in that space that now this team can own that whole experience? And then critically, can they debug it? Will we know when something goes wrong, et cetera? Those are always parts. At this point, I don't think I can just imagine a happy path. And I hope this isn't true for the rest of my life.

+ +

But the work as a software developer, especially after having done a couple of rounds of it and as a consultant, I just imagine failure modes. It's all I do. I'll be like, okay, we just need to wire X up to Z, and then we need to fire off a request. And then, once we get the message back, then we can process them. I'm like, right. You just described 13 things that can go wrong. Now let's imagine each of the different failure states because that's all I'm going to do.

+ +

Who cares about the happy path? Those are easy. Those write themselves. It's all of the failure modes that I need to think about. And someday, when I retire, and I go to a log cabin in the woods, and I don't talk to people for a while, maybe I'll go back to a place of only happy paths. But that is not my truth right now.

+ +

STEPH: I can't tell you how many people in my personal life I have annoyed so much [laughs] because all I see are failure modes. And one, that's a delightful t-shirt. [laughs] I'd love to have that. And then yeah, I feel you because there are so many times where someone is...like, I'm with someone who's like a big idea person. And so they're just launching into what-ifs, and we did this. And I can't help it, and I have learned to help it.

+ +

But it has been a struggle with some strong feedback from family and friends to reel it in. Because then I will start to think through okay, well, what's the details? And I have some questions. What happens when this happens? And yeah, all I see are failure modes. [laughs] It is very true for me too, and not always...not so great. So I, too, shall get a log cabin one day and try to forget all of that.

+ +

CHRIS: I will say I painted that as a particularly glib version of myself. But some of what I'm doing right now, particularly joining an early-stage startup and taking the role of CTO, was very much to try and intentionally resist that. Because right now, I have to be really careful with how much of the potential edge cases and whatnot. I'm considering exactly how robust of a platform are we building? Very is the answer. But what about extremely? Because extremely is an option but extremely costs four times as much. Mostly in time being the critical element there.

+ +

And so part of the work that I'm doing now is just trying to push on those edges, push on those boundaries, find the places where we can move quickly, and still build a robust platform because frankly, we're building...Sagewell is a financial platform under the hood, and I can't be flippant with that. We as a team have to be really careful with the thing that we're building. But we also have to move quickly.

+ +

We have to be able to iterate. We have to be able to build something and try it out and see if it works. And then, if it doesn't, maybe shelve it and pull it out of the codebase. And it has been a real challenge, but it was the challenge that I wanted here. And so I've been enjoying that work, but it has been a stretch, a growth moment, let's call it.

+ +

STEPH: I don't know if you've shared that particular goal with me in transitioning to a CTO role, but I really, really like it. One, it's very aligned with who you are. You're very thoughtful, and you look for areas to push and ways to do that. And then I also struggle in those areas, and thoughtbot specifically and consulting has helped push me in directions, push me out of my comfort zones but still in a safe space where I have other people to talk to as I'm making those decisions and pushing past the comfort areas that I have.

+ +

But one of them is that I will initially think things have to be perfect or really planned. And I had a really nice conversation with Chad Pytel, who is one of the Founders of thoughtbot and also COO and host of the Giant Robots Smashing Into Other Giant Robots Podcast. And we were chatting about a new offering that thoughtbot is bringing to the market. And it's one that I've been involved with. And I started getting really in the weeds of like, but we really have to plan out how this is going to look and all the actions that need to take place before then we can really sell this type of engagement to a new client.

+ +

And as I was going through this list of worries, when I was done, he mentioned he's like, "All of those are valid and something to consider." He's like, "But we don't have any customers yet." So the first part is we feel that we are in a space that we have enough of information to get started. And it's something that we've done before. And then, we'd like to see where customers align with us on this need because we're going to end up shaping this work in response to what their needs are. And so, we can't really begin that shaping until we understand more of what people are looking for.

+ +

I was like, oh yeah, that's such a nice point. It just reminded me in regard to pushing those boundaries of yes, we need planning upfront, and we look for failure modes. But then there's also an important aspect of then finding ways to keep moving forward and getting more feedback and then balancing those two.

+ +

CHRIS: Yeah, I think that's definitely right the as always, anchoring it to the customer. What is it that they need? How do we connect with them and hear from them? And ideally, keep those feedback loops as short as possible. That's the game, and everything else fits around that. But yeah, so we're trying some stuff. We'll see how it goes. I will certainly report back, depending on how it plays out. But that's a little bit of what's up in my world. What's up in your world?

+ +

STEPH: I have been thinking recently about working in isolation. It's a topic that Joël Quenneville, who's another thoughtboter and has been on the show a number of times, it was a topic that he'd actually pointed out to me and mentioned. And so, I wanted to bring that here and share it with you because I'd love to get some of your thoughts on this as well. But I've typically had the viewpoint that when developers are sent off to work on a large, nebulous task, that it's a recipe for disaster, and almost everyone's going to lose in that scenario. And it tends to be a combination of isolation, very distant due dates, and loosely defined scope that leads to those really poor results.

+ +

However, as developers, it's not inconceivable for us to land in that position. And it's very similar to my current project, who I'm working with Joël on, where we were given a very fuzzy project with some really aggressive goals, and the engagement is going really well. So that led Joël and I to wonder why is this working? This is the thing that we said that people should never do, but it's actually going quite well for us.

+ +

So reflecting upon some of the things that are working well for us, even though we are in more of an isolated state than we would typically work, some of the things that I've been reflecting on or some of the strategies I should say that we've applied to this situation is number one, we did work hard to plug into an existing team. So when we joined, we joined more of an ad hoc volunteer team.

+ +

And in everybody's spare time, those individuals were then contributing to the CI process in terms of trying to speed things up and improve things for the rest of the team. But otherwise, there wasn't really a team. There wasn't much structure to it. So it felt like everybody was very much off in their own world doing their own thing, occasionally putting up some code changes for review. And then you had to gain a lot of context to understand what it was that they were doing.

+ +

So one of the things that I advocated for early on that I thought was more of just my personal preference but I think has actually worked well in regards to the success of the project as well is to plug into an existing team. So even if you are not working with that team on their day-to-day tasks, but you want to have more people to interact with and more people to share your context with. So you are essentially reducing the isolation of you're no longer these two people who are off in a corner working on something, and nobody has any idea what you're doing, and only one person is getting a status update.

+ +

There is now a whole channel or team of people that have some insight as to what's going on. And they can also really unblock you for when you get stuck because then if you do have a question, but there's that one person who has been like your go-to person for this whole project, if they're out on vacation, or if they leave, or just something happens, you're suddenly blocked.

+ +

And you don't know who to go to because you've been part of this larger company, but you haven't interacted with anybody outside of that one person. So at least if you're plugged into another team, you've immediately got some friends or some other people to go to and say, "Hey, I'm not sure who can help me with this, but I have this problem." And then, from there, you can get more help.

+ +

CHRIS: This is super interesting. To start, I really like that you're framing this in terms of this is a thing that we often recommend against or see as an anti-pattern, and yet in this particular case, it's working. Let's look at that. Because I think the things that you're like, huh, that's interesting. That phrase "Huh, that's interesting" is very interesting. It often highlights like oh, something is behaving counter to how we would expect it to, so let's dig in and explore that. And so I love that that was the reaction and then sort of the conversation that spilled out of that.

+ +

I'm also not super surprised that the combination of you and Joël were able to find a way to make this successful because you are two of the most capable developers that I've worked with but also particularly excellent communicators and advocates for the work that you're doing and the way that one should do the work. So the idea that there's a situation that may not be the ideal mode of working and that you're able to take that and say, "What if we shift it just a little bit and make it a little bit more manageable and whatnot?" So unsurprised, frankly, that you found a way collectively to make this a little bit better.

+ +

And then I think yeah, it sounds like you're doing the things...so just like, we're in isolation, hmm, that doesn't seem great. Let's unisolate and connect to some people, and that just feels so true. I'm very interested to hear, though. I'm guessing there's more to this story or other things that you've done. Are there other tactics or ways that you've shifted this around?

+ +

STEPH: Yeah, there's a couple more. So this is one that (And thank you for the kind words.) this was one that I think Joël is really exceptional at. So Joël is really good at building diagrams and graphs and then sharing that with the team as sort of like we've spent a couple of days understanding this big, messy concept. Here's a nice condensed graph that shows how we went about understanding this. And then here's the big overall picture of what we've learned from this, which has been wonderful for so many reasons.

+ +

And every time that we share something with the team, one, it just helps build camaraderie, especially in remote days, it just builds camaraderie on hey, we're all online. And we're working. And here's the thing that I'm working through or struggling with or something that I learned. I often do that, especially when I get frustrated and something goes wrong. I love to share the I did this today. It went terribly. [laughs] Let me tell you about it, so you're aware of it in case it helps you.

+ +

And specifically, the diagrams are really nice because then other people can just see and appreciate it, or they can point something out that we didn't know. Or they'll see a different angle because they're more familiar with the system. So they can say, "Oh yeah, that totally makes sense," or "I had no idea that was happening." So that's been a really nice way to engage with the team.

+ +

And so, essentially, the little title for that strategy is just overshare. Just share all the things that you're doing and find ways to make it digestible for the team so then they can go along on this big, nebulous journey with you. And you can also put it in threads so that way, you're not flooding a channel, but then people can opt-in to that oversharing if they would like more insight into the work that you're doing.

+ +

CHRIS: Opt-in to that oversharing. [laughs]

+ +

STEPH: Exactly. I mean, it's not forced oversharing; it's just it's here if people would like it. That was a really nice compliment that some other thoughtboters received from their client team is someone had mentioned that there's so much information that's getting shared from the thoughtboters that they had trouble keeping up. And they really liked that. They really appreciated that they could then go check out this channel or these threads and see exactly the type of work that was happening and the outcomes of it. And then they could just check it maybe beginning of the day, end of the day and get that knowledge dump.

+ +

Some of the other strategies that we've used are giving ourselves mini-goals to accomplish as part of the larger, more nebulous task. So as we have this very large goal in mind, it's like, where's the small piece? Where's an entry point? What's a task or a goal that we can define? And then we want to break that down into what questions do we need to ask? How can we start moving in this direction? And we want to find something that has an answer.

+ +

So each time that we start researching once we've gotten to that point...and this is hard. I feel like people may know that, but I should just say that this is hard to take something nebulous and then find the entry point and break down some goals. And that has been one of the wonderful parts of then having a buddy for this type of project because then we can bounce ideas off of each other.

+ +

And we can also help the other person not go too deep into an area. Because I have definitely had moments where I've been very passionate about like, "We need to do this," and Joël is just like, do we? And I'm like, "Yeah." And he's like, "Do we though?" And I'm like, "I guess not. I just really, really want to." [laughs] It's been very helpful to have a partner balance some of those feelings.

+ +

And once you can break down some of that amorphous problem into those smaller goals, then you can also create tickets, which is also a really nice way to then surface the work that you're doing. You can document how you're researching, document the question. And then once you have that question of what you're in search of, it's so nice because then once you find the answer, that's immediately a good moment to pause and reflect.

+ +

So I think in a recent episode, we were chatting about this where Joël and I were trying to understand why the tests weren't being balanced properly across each process that was available. And we found the answer, and we started immediately digging into fixing it or solutions. And then it took us a moment to go back and say, "Actually, this ticket is really just about understanding the problem, not fixing the problem." And so that was a nice; now that we understand the problem, let's go back high-level to define our next goal from this big, nebulous task because maybe fixing that balancing is the right thing to do, but maybe not, and we just need to reconsider.

+ +

So for that portion of breaking down a big, nebulous task and then identifying smaller tasks that you can achieve, time-boxing has been huge for us in regards of what’s something that we can accomplish this week, or what's something we can accomplish today that will then move us forward? And then making sure that we are setting deadlines for ourselves. So normally, this is another area where it's like, huh, that's interesting. I'm a big believer in deadlines. But I do think self-imposed deadlines are really helpful.

+ +

CHRIS: I'm intrigued to hear you say that you're not a big fan of deadlines because I assume we're actually more aligned on this. But deadlines that are arbitrary and also come with fixed scope and other immovable things, yes, those are the worst in the world. But deadlines that we set for ourselves, and then we use that as a mechanism to hone and refine the scope that we're going to get out the door by that deadline, I find those incredibly useful. And that sounds like that's the same sort of thing you have going on here is like by saying we're willing to expend this much to get a result, that defines the work going into it.

+ +

STEPH: Yeah, that's fair. Everything that you said is true, too; in regards to, I'm realizing I default that when I hear the word deadline, I'm so used to teams having deadlines that are defined by other individuals that are not part of the work. And as you said, the scope has already been defined, and it can't be changed. And it's all of the bad things that then go with it.

+ +

So when I think of deadlines, I immediately think of that type of deadline versus the more self-imposed, yes, we can revisit, yes, the team has bought in and understands why this is important. Those types of deadlines are very helpful. It's that first part that I default to that I think of immediately, and I need some reassurance that that is not the type of deadline that I'm looking at or being forced to meet.

+ +

I have a very similar feeling for estimates. Like, those both fall in the same category for me is; as soon as I hear estimation and deadline, I get nervous. And then I just need to understand the purpose of both and who is setting both of those and the communication around them. And then what does that failure mode look like, the one that we're always looking for? So yeah, deadlines and estimations fit into that. Initially, I'm very hesitant and cautious, but I think they're both very good tools.

+ +

CHRIS: Yeah, I feel like those are very closely related. And they're definitely tools that can be used for great good or for great evil. And so, ideally, we advocate for the great good usage. But more generally, I love, again, the sharing around the process and what's worked for you in this less typical or often somewhat problematic workflow. I will say, again, so I gave you the series of compliments earlier, and I stand by those compliments for you and Joël.

+ +

But I think also the sort of related aspect is that you two are both quite senior, very capable, very comfortable suggesting changes, suggesting workflows. So I think the potential dangers of isolation are still very much there. And the fact that the two of you have been able to find a way to work more effectively and perhaps change the terms of things just a little bit to make this effective is A, unsurprising but B, not something that I would expect of every team.

+ +

I think you've described a wonderful list of the specifics as to how you did that. And ideally, if folks that are perhaps a little earlier on in their career are sent out for a month with a wild project, and they're sent to do it in isolation, hopefully, they can borrow from that list. But again, I do think this is a thing that, from an organizational perspective, we should be very careful with when we're imposing this isolation on it because it takes two fantastic folks like you and Joël to break out of the shackles of it.

+ +

STEPH: The more we're talking about this, the more apparent it's also becoming that I started with this; how do you manage isolation? And my answer is you get out of it. [laughs] Get out of isolation as quickly as possible. Someone thought it was a good idea to put you there or a good idea to structure it that way. Or maybe they didn't mean it intentionally, but that's how things then shook out. So that's really what a lot of those strategies are about is, then how do I get myself out of this corner that you put me in? Because nobody put Stephanie in a corner.

+ +

So it's essentially that's all the strategies are looking for ways to say, hey, I'm isolated, but I really don't want to be, and it's dangerous for me to be isolated in this way. Even as a more senior capable developer, it's more likely that things could go wrong, and miscommunications, misaligned expectations. So I need to find ways to then bring the work that I'm doing to make it more relevant to other people on the team. So then we can have more overlap, or at least I can share a lot of the work that's being done.

+ +

CHRIS: Yeah, absolutely. I think with that wonderful summary and, frankly, utterly fantastic movie reference, what do you think? Should we wrap up?

+ +

STEPH: Let's do it. Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Chris is weathering through a slight lull, a holding period, where his team waits for new features to become available with some of the platforms they integrate with, and as they think out new facets of the platform they're building.

+ +

Steph has been thinking recently about working in isolation. It's a topic that Joël Quenneville pointed out to her and mentioned. Can engineers work in isolation and be successful?

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Always be singing.

+ +

STEPH: I can't remember if I've shared the story with you. But I had a beautiful little human moment with someone at airport security. Because when I travel with my mic, I always get stopped because there's the middle long, thin piece that looks like what you would screw on to a gun like for a silencer. And so [laughs] as he was going through, the person was looking at it, and then he called over a buddy. And then they called over another buddy, and there's like three TSA agents all looking at the X-ray screen. And finally, they're like, "Yeah, we need to flag it." So they moved it over.

+ +

And then he was digging through, and he pulled out the big metal piece. And I said, "It's for a microphone." And he's like, "Okay," and he kept looking, and then he finally found the microphone. And he lit up because I guess he wasn't really sure to believe me at first when I said it. But he lit up, and he was like, "Karaoke?" [laughs] I was like, "No, it's for podcasting."

+ +

CHRIS: But not 100% no because we do sing plenty on this show, so...

+ +

STEPH: I think that's what made me think of it. It was your singing. [laughs]

+ +

CHRIS: Yep. My wonderful, wonderful singing.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly Podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris? What's new in your world?

+ +

CHRIS: What's new in my world? We are in sort of a...what's the word? There's a bit of a lull right now, not like a big lull, but we had a bunch of clear work that came into the team, did a bunch of iterations, some testing, built some new features, et cetera. And now there's a small holding period basically where we wait for some new features to become available with some of the platforms that we integrate with and also as we think out some new facets of the platform that we're building.

+ +

So we've got this little bit of time here where we're not necessarily building out as many new novel features. But instead, as a dev team, we're taking this moment to be like, oh, cool, let's tie down. I want to make a sailing analogy here, but I don't know sailing. It's like tie down the somethings and batten the hatches, maybe. That sounds like a thing. [chuckles] But so we have a couple of projects going right now. We want to really accept the truth and lean into Sidekiq. So right now, we have a mix of ActiveJob and Sidekiq jobs. And they're confusing, and et cetera, et cetera.

+ +

So we want to kind of lean into that, upgrade dependencies, that sort of thing. We are, again, doing a little bit of work on the observability foundation of our system. so how do we know what's going on at runtime? Also, working on just some core features and functionality. We have done a little bit of an exploration into the event processing stuff, some of that that I've been talking about. It's actually been very interesting. So we're working with Customer.io as a platform, which is omnichannel communication behavior-based messaging sort of thing. So when a user does X, send them an email and then wait three days. And if they haven't responded, then do this other thing.

+ +

And I think I've said this in previous episodes; I'm so wildly impressed with that platform. They have done such a good job. And I know that good software doesn't happen in a vacuum. In fact, if we're being honest, a lot of the software out there is not very good. And not only do they do a good job, but it's across...there's a ton of functionality in Customer.io.

+ +

And it's interesting because we're finding ourselves leaning into it even more because it is such a solid platform and because it connects into our event system. Like, it's a segment destination, so all of our analytics events get piped into Customer.io, and then we can action on any of them. And the actions can be quite complicated.

+ +

And this is where we're getting into good idea, terrible idea space. And to be clear, this is still just an exploration. But we basically wanted a way to do more. There are a bunch of different actions that you can take so, like send an email, send an SMS, or there are a couple of other slightly fancier ones. You can trigger an event within the Customer.io system. You can actually do an arbitrary HTTP POST, PUT, PATCH, whatever, any web requests you want to make. So if you want to integrate with essentially anything else out there, you can do that. You can send some structured data over the wire.

+ +

And so we've now been like, okay, what if, and stay with me here, what if we use our analytic system and we send events whenever a user does something, and then that event eventually trickles down to Customer.io? Within that, we allow ourselves to respond to that event by emitting a different event within the system, within Customer.io. And then, via the webhook functionality, we fire that back to the Rails application. And then there we can do whatever we want.

+ +

And in a way, that sounds absurd because we're starting from our app, and then we're sending some events down, processing them in certain ways, sending it back to the app, and then maybe doing something. In particular, one of the things we want to do is richly formatted Slack alerts. And Customer.io has a Slack alert functionality, but they can't have any of the fancy stuff. They can't link to our customer in the admin dashboard. So we found that that functionality is particularly useful for our admin team. And so we're like, ah, this feels weird.

+ +

But if we were to do this loop out and back, then ideally, we get the power of Customer.io for non-technical users or non-engineering team users to configure workflows and to say, "When a user does this, I actually want to alert the admin team via Slack." And we want it to be rich and have buttons that you can click and all that kind of stuff. And although the thing that I just described seems complicated, is a word that I'll use for it, confusing at times, it isn't...like, I don't want to do all of that in the app.

+ +

I don't want the app to have to think about how do I wait three days? We technically can do that with Sidekiq, but it gets us in trouble and whatnot, whereas Customer.io that's a core concept for them. And so, again, very much exploration. This will probably be a future good idea, terrible idea segment. But that's been an interesting one to explore.

+ +

STEPH: You have quite a talent for you preface something as a bad idea, and you do a very good job of making it sound reasonable and good. [laughs] So it's interesting to be on that side of like, good idea, bad idea. It's like, I'm looking for the bad. And I have questions, but overall, [chuckles] you do a very good job of being very thoughtful and walking through why it makes sense or what are the benefits of it. So you answered some of my questions around why still send it to Customer.io versus just having it all in-house. So the fact that the admin team has access to it makes a lot of sense.

+ +

I want to clarify one point. So when you send it to Customer.io, Customer.io then needs to send a message back to your application. And then that's when you customize the Slack message. Do you need Customer.io to send that message, or could you just fire off an event to Customer.io to say, "Hey, capture this, but don't do anything with this. And then we're going to send the Slack message because we want to customize it."?

+ +

CHRIS: I think the key is that we want to leverage the fact that Customer.io is the platform that our operations team really is now becoming comfortable with and using for this behavioral automation workflow type logic. So that idea of when this event, you know, when this triggering event happens, if this condition is true, then respond in this way.

+ +

And so because Customer.io is the platform that A, is quite good at that and B, is where our admin team is now thinking about doing that, one thing that we might do let's say a user completes some action within the application. So they fill out a form to submit their interest in some new platform feature. Initially, what we might want to do there is alert ourselves to say, "Hey, this happened. Take some action." And then eventually, we may want to instead switch that over and send an email to the customer with the next steps that they need to do.

+ +

And the ability to gradually transition across that spectrum is really interesting to me, and again, Customer.io being the platform, sort of the hub for how we respond to these events. At the same time, I know that this feels like a generic message processing system that might be a Kafka queue somewhere else. And so I've got that in the back of my head of like, is this weird? I think it's a little weird. But it also, thus far as we're exploring it, is very approachable for the admin team, very familiar for them, and reasonably powerful.

+ +

And also, there's a drag and drop editor for the events and the payloads. And it knows for this event, here's the stuff that's available to you. And so the ability for our admin team to interact with that interface is really great. And we don't have to build it. We don't have to think about it. But I will say I've worked at so many different companies that have their ad hoc system that makes it easy to do generic X, Y, and Z. And it's bad, and it falls down. And it's impossible to know when anything happens.

+ +

And so, I've got a lot of concerns in the back of my head, which I will want to at least think through and understand the trade-offs that we're making if we pursue this path, but it is very interesting to me. So right now, a lot of this logic does live in the app. But it means that it requires a code change for anything that we want to do like this. We want to have a Slack alert whenever X happens. Now, the developers are in the loop for all of that. And really, it's the operations team that owns the decisioning on that.

+ +

And so if they can also self-serve and instrument the action, the alert, the follow-up, the whatever it is, if we can give them those primitives in a platform that they already understand, that sounds nice. I'm intrigued, is what I'll say. So anyway, while we're in this lull period, we are trying out some fun stuff like that and exploring those sorts of things.

+ +

STEPH: I like that perspective that you're putting on it, or at least the one that's standing out to me is the concept of ownership is like who gets to own these actions. But then beyond that, that's the part where I feel a little squirmy is, so we are using this third-party tool because it makes life easier. But then, at what point when we start building software around this third-party tool to then customize it back on our own side. Then if someone is in Customer.io, so if an admin user is in there and then they trigger an event, is there going to be confusion as to what's going to happen? And can they retry an event?

+ +

Because I'm realizing my initial suggestion where it was like, hey, notify Customer.io that this is there but then also manage sending the Slack message that would prevent them from being able to have that retry capability. And that may be very much worth preserving. So then it's understood that hey, if you want to manage this, we are giving you full access to manage this work. We may customize it, but this is still the interface in which you go through to have three tries or to manage that workflow or these actions that get sent to users.

+ +

CHRIS: Yeah. I think you've perfectly highlighted the why this might not be a great idea or at least the concerns to explore before adopting this more thoroughly. And even just the idea of adopting it more thoroughly, like, how tied into the system are we? How business-critical does this new external piece of software become? Because I've seen that to be really problematic where there are organizations that I've worked with that are like, "Oh God, we would love to move off of system X. But unfortunately, it's basically the one thing holding this business up." And I'm like, yeah, I get that. And that happens. So yeah, being really intentional with that.

+ +

And that's why we're very much in an exploration place. But we have a bunch of stuff that we've done that required engineering work. And we're now seeing like, actually, could we map this into this other tool? And can we build the set of primitives in that space that now this team can own that whole experience? And then critically, can they debug it? Will we know when something goes wrong, et cetera? Those are always parts. At this point, I don't think I can just imagine a happy path. And I hope this isn't true for the rest of my life.

+ +

But the work as a software developer, especially after having done a couple of rounds of it and as a consultant, I just imagine failure modes. It's all I do. I'll be like, okay, we just need to wire X up to Z, and then we need to fire off a request. And then, once we get the message back, then we can process them. I'm like, right. You just described 13 things that can go wrong. Now let's imagine each of the different failure states because that's all I'm going to do.

+ +

Who cares about the happy path? Those are easy. Those write themselves. It's all of the failure modes that I need to think about. And someday, when I retire, and I go to a log cabin in the woods, and I don't talk to people for a while, maybe I'll go back to a place of only happy paths. But that is not my truth right now.

+ +

STEPH: I can't tell you how many people in my personal life I have annoyed so much [laughs] because all I see are failure modes. And one, that's a delightful t-shirt. [laughs] I'd love to have that. And then yeah, I feel you because there are so many times where someone is...like, I'm with someone who's like a big idea person. And so they're just launching into what-ifs, and we did this. And I can't help it, and I have learned to help it.

+ +

But it has been a struggle with some strong feedback from family and friends to reel it in. Because then I will start to think through okay, well, what's the details? And I have some questions. What happens when this happens? And yeah, all I see are failure modes. [laughs] It is very true for me too, and not always...not so great. So I, too, shall get a log cabin one day and try to forget all of that.

+ +

CHRIS: I will say I painted that as a particularly glib version of myself. But some of what I'm doing right now, particularly joining an early-stage startup and taking the role of CTO, was very much to try and intentionally resist that. Because right now, I have to be really careful with how much of the potential edge cases and whatnot. I'm considering exactly how robust of a platform are we building? Very is the answer. But what about extremely? Because extremely is an option but extremely costs four times as much. Mostly in time being the critical element there.

+ +

And so part of the work that I'm doing now is just trying to push on those edges, push on those boundaries, find the places where we can move quickly, and still build a robust platform because frankly, we're building...Sagewell is a financial platform under the hood, and I can't be flippant with that. We as a team have to be really careful with the thing that we're building. But we also have to move quickly.

+ +

We have to be able to iterate. We have to be able to build something and try it out and see if it works. And then, if it doesn't, maybe shelve it and pull it out of the codebase. And it has been a real challenge, but it was the challenge that I wanted here. And so I've been enjoying that work, but it has been a stretch, a growth moment, let's call it.

+ +

STEPH: I don't know if you've shared that particular goal with me in transitioning to a CTO role, but I really, really like it. One, it's very aligned with who you are. You're very thoughtful, and you look for areas to push and ways to do that. And then I also struggle in those areas, and thoughtbot specifically and consulting has helped push me in directions, push me out of my comfort zones but still in a safe space where I have other people to talk to as I'm making those decisions and pushing past the comfort areas that I have.

+ +

But one of them is that I will initially think things have to be perfect or really planned. And I had a really nice conversation with Chad Pytel, who is one of the Founders of thoughtbot and also COO and host of the Giant Robots Smashing Into Other Giant Robots Podcast. And we were chatting about a new offering that thoughtbot is bringing to the market. And it's one that I've been involved with. And I started getting really in the weeds of like, but we really have to plan out how this is going to look and all the actions that need to take place before then we can really sell this type of engagement to a new client.

+ +

And as I was going through this list of worries, when I was done, he mentioned he's like, "All of those are valid and something to consider." He's like, "But we don't have any customers yet." So the first part is we feel that we are in a space that we have enough of information to get started. And it's something that we've done before. And then, we'd like to see where customers align with us on this need because we're going to end up shaping this work in response to what their needs are. And so, we can't really begin that shaping until we understand more of what people are looking for.

+ +

I was like, oh yeah, that's such a nice point. It just reminded me in regard to pushing those boundaries of yes, we need planning upfront, and we look for failure modes. But then there's also an important aspect of then finding ways to keep moving forward and getting more feedback and then balancing those two.

+ +

CHRIS: Yeah, I think that's definitely right the as always, anchoring it to the customer. What is it that they need? How do we connect with them and hear from them? And ideally, keep those feedback loops as short as possible. That's the game, and everything else fits around that. But yeah, so we're trying some stuff. We'll see how it goes. I will certainly report back, depending on how it plays out. But that's a little bit of what's up in my world. What's up in your world?

+ +

STEPH: I have been thinking recently about working in isolation. It's a topic that Joël Quenneville, who's another thoughtboter and has been on the show a number of times, it was a topic that he'd actually pointed out to me and mentioned. And so, I wanted to bring that here and share it with you because I'd love to get some of your thoughts on this as well. But I've typically had the viewpoint that when developers are sent off to work on a large, nebulous task, that it's a recipe for disaster, and almost everyone's going to lose in that scenario. And it tends to be a combination of isolation, very distant due dates, and loosely defined scope that leads to those really poor results.

+ +

However, as developers, it's not inconceivable for us to land in that position. And it's very similar to my current project, who I'm working with Joël on, where we were given a very fuzzy project with some really aggressive goals, and the engagement is going really well. So that led Joël and I to wonder why is this working? This is the thing that we said that people should never do, but it's actually going quite well for us.

+ +

So reflecting upon some of the things that are working well for us, even though we are in more of an isolated state than we would typically work, some of the things that I've been reflecting on or some of the strategies I should say that we've applied to this situation is number one, we did work hard to plug into an existing team. So when we joined, we joined more of an ad hoc volunteer team.

+ +

And in everybody's spare time, those individuals were then contributing to the CI process in terms of trying to speed things up and improve things for the rest of the team. But otherwise, there wasn't really a team. There wasn't much structure to it. So it felt like everybody was very much off in their own world doing their own thing, occasionally putting up some code changes for review. And then you had to gain a lot of context to understand what it was that they were doing.

+ +

So one of the things that I advocated for early on that I thought was more of just my personal preference but I think has actually worked well in regards to the success of the project as well is to plug into an existing team. So even if you are not working with that team on their day-to-day tasks, but you want to have more people to interact with and more people to share your context with. So you are essentially reducing the isolation of you're no longer these two people who are off in a corner working on something, and nobody has any idea what you're doing, and only one person is getting a status update.

+ +

There is now a whole channel or team of people that have some insight as to what's going on. And they can also really unblock you for when you get stuck because then if you do have a question, but there's that one person who has been like your go-to person for this whole project, if they're out on vacation, or if they leave, or just something happens, you're suddenly blocked.

+ +

And you don't know who to go to because you've been part of this larger company, but you haven't interacted with anybody outside of that one person. So at least if you're plugged into another team, you've immediately got some friends or some other people to go to and say, "Hey, I'm not sure who can help me with this, but I have this problem." And then, from there, you can get more help.

+ +

CHRIS: This is super interesting. To start, I really like that you're framing this in terms of this is a thing that we often recommend against or see as an anti-pattern, and yet in this particular case, it's working. Let's look at that. Because I think the things that you're like, huh, that's interesting. That phrase "Huh, that's interesting" is very interesting. It often highlights like oh, something is behaving counter to how we would expect it to, so let's dig in and explore that. And so I love that that was the reaction and then sort of the conversation that spilled out of that.

+ +

I'm also not super surprised that the combination of you and Joël were able to find a way to make this successful because you are two of the most capable developers that I've worked with but also particularly excellent communicators and advocates for the work that you're doing and the way that one should do the work. So the idea that there's a situation that may not be the ideal mode of working and that you're able to take that and say, "What if we shift it just a little bit and make it a little bit more manageable and whatnot?" So unsurprised, frankly, that you found a way collectively to make this a little bit better.

+ +

And then I think yeah, it sounds like you're doing the things...so just like, we're in isolation, hmm, that doesn't seem great. Let's unisolate and connect to some people, and that just feels so true. I'm very interested to hear, though. I'm guessing there's more to this story or other things that you've done. Are there other tactics or ways that you've shifted this around?

+ +

STEPH: Yeah, there's a couple more. So this is one that (And thank you for the kind words.) this was one that I think Joël is really exceptional at. So Joël is really good at building diagrams and graphs and then sharing that with the team as sort of like we've spent a couple of days understanding this big, messy concept. Here's a nice condensed graph that shows how we went about understanding this. And then here's the big overall picture of what we've learned from this, which has been wonderful for so many reasons.

+ +

And every time that we share something with the team, one, it just helps build camaraderie, especially in remote days, it just builds camaraderie on hey, we're all online. And we're working. And here's the thing that I'm working through or struggling with or something that I learned. I often do that, especially when I get frustrated and something goes wrong. I love to share the I did this today. It went terribly. [laughs] Let me tell you about it, so you're aware of it in case it helps you.

+ +

And specifically, the diagrams are really nice because then other people can just see and appreciate it, or they can point something out that we didn't know. Or they'll see a different angle because they're more familiar with the system. So they can say, "Oh yeah, that totally makes sense," or "I had no idea that was happening." So that's been a really nice way to engage with the team.

+ +

And so, essentially, the little title for that strategy is just overshare. Just share all the things that you're doing and find ways to make it digestible for the team so then they can go along on this big, nebulous journey with you. And you can also put it in threads so that way, you're not flooding a channel, but then people can opt-in to that oversharing if they would like more insight into the work that you're doing.

+ +

CHRIS: Opt-in to that oversharing. [laughs]

+ +

STEPH: Exactly. I mean, it's not forced oversharing; it's just it's here if people would like it. That was a really nice compliment that some other thoughtboters received from their client team is someone had mentioned that there's so much information that's getting shared from the thoughtboters that they had trouble keeping up. And they really liked that. They really appreciated that they could then go check out this channel or these threads and see exactly the type of work that was happening and the outcomes of it. And then they could just check it maybe beginning of the day, end of the day and get that knowledge dump.

+ +

Some of the other strategies that we've used are giving ourselves mini-goals to accomplish as part of the larger, more nebulous task. So as we have this very large goal in mind, it's like, where's the small piece? Where's an entry point? What's a task or a goal that we can define? And then we want to break that down into what questions do we need to ask? How can we start moving in this direction? And we want to find something that has an answer.

+ +

So each time that we start researching once we've gotten to that point...and this is hard. I feel like people may know that, but I should just say that this is hard to take something nebulous and then find the entry point and break down some goals. And that has been one of the wonderful parts of then having a buddy for this type of project because then we can bounce ideas off of each other.

+ +

And we can also help the other person not go too deep into an area. Because I have definitely had moments where I've been very passionate about like, "We need to do this," and Joël is just like, do we? And I'm like, "Yeah." And he's like, "Do we though?" And I'm like, "I guess not. I just really, really want to." [laughs] It's been very helpful to have a partner balance some of those feelings.

+ +

And once you can break down some of that amorphous problem into those smaller goals, then you can also create tickets, which is also a really nice way to then surface the work that you're doing. You can document how you're researching, document the question. And then once you have that question of what you're in search of, it's so nice because then once you find the answer, that's immediately a good moment to pause and reflect.

+ +

So I think in a recent episode, we were chatting about this where Joël and I were trying to understand why the tests weren't being balanced properly across each process that was available. And we found the answer, and we started immediately digging into fixing it or solutions. And then it took us a moment to go back and say, "Actually, this ticket is really just about understanding the problem, not fixing the problem." And so that was a nice; now that we understand the problem, let's go back high-level to define our next goal from this big, nebulous task because maybe fixing that balancing is the right thing to do, but maybe not, and we just need to reconsider.

+ +

So for that portion of breaking down a big, nebulous task and then identifying smaller tasks that you can achieve, time-boxing has been huge for us in regards of what’s something that we can accomplish this week, or what's something we can accomplish today that will then move us forward? And then making sure that we are setting deadlines for ourselves. So normally, this is another area where it's like, huh, that's interesting. I'm a big believer in deadlines. But I do think self-imposed deadlines are really helpful.

+ +

CHRIS: I'm intrigued to hear you say that you're not a big fan of deadlines because I assume we're actually more aligned on this. But deadlines that are arbitrary and also come with fixed scope and other immovable things, yes, those are the worst in the world. But deadlines that we set for ourselves, and then we use that as a mechanism to hone and refine the scope that we're going to get out the door by that deadline, I find those incredibly useful. And that sounds like that's the same sort of thing you have going on here is like by saying we're willing to expend this much to get a result, that defines the work going into it.

+ +

STEPH: Yeah, that's fair. Everything that you said is true, too; in regards to, I'm realizing I default that when I hear the word deadline, I'm so used to teams having deadlines that are defined by other individuals that are not part of the work. And as you said, the scope has already been defined, and it can't be changed. And it's all of the bad things that then go with it.

+ +

So when I think of deadlines, I immediately think of that type of deadline versus the more self-imposed, yes, we can revisit, yes, the team has bought in and understands why this is important. Those types of deadlines are very helpful. It's that first part that I default to that I think of immediately, and I need some reassurance that that is not the type of deadline that I'm looking at or being forced to meet.

+ +

I have a very similar feeling for estimates. Like, those both fall in the same category for me is; as soon as I hear estimation and deadline, I get nervous. And then I just need to understand the purpose of both and who is setting both of those and the communication around them. And then what does that failure mode look like, the one that we're always looking for? So yeah, deadlines and estimations fit into that. Initially, I'm very hesitant and cautious, but I think they're both very good tools.

+ +

CHRIS: Yeah, I feel like those are very closely related. And they're definitely tools that can be used for great good or for great evil. And so, ideally, we advocate for the great good usage. But more generally, I love, again, the sharing around the process and what's worked for you in this less typical or often somewhat problematic workflow. I will say, again, so I gave you the series of compliments earlier, and I stand by those compliments for you and Joël.

+ +

But I think also the sort of related aspect is that you two are both quite senior, very capable, very comfortable suggesting changes, suggesting workflows. So I think the potential dangers of isolation are still very much there. And the fact that the two of you have been able to find a way to work more effectively and perhaps change the terms of things just a little bit to make this effective is A, unsurprising but B, not something that I would expect of every team.

+ +

I think you've described a wonderful list of the specifics as to how you did that. And ideally, if folks that are perhaps a little earlier on in their career are sent out for a month with a wild project, and they're sent to do it in isolation, hopefully, they can borrow from that list. But again, I do think this is a thing that, from an organizational perspective, we should be very careful with when we're imposing this isolation on it because it takes two fantastic folks like you and Joël to break out of the shackles of it.

+ +

STEPH: The more we're talking about this, the more apparent it's also becoming that I started with this; how do you manage isolation? And my answer is you get out of it. [laughs] Get out of isolation as quickly as possible. Someone thought it was a good idea to put you there or a good idea to structure it that way. Or maybe they didn't mean it intentionally, but that's how things then shook out. So that's really what a lot of those strategies are about is, then how do I get myself out of this corner that you put me in? Because nobody put Stephanie in a corner.

+ +

So it's essentially that's all the strategies are looking for ways to say, hey, I'm isolated, but I really don't want to be, and it's dangerous for me to be isolated in this way. Even as a more senior capable developer, it's more likely that things could go wrong, and miscommunications, misaligned expectations. So I need to find ways to then bring the work that I'm doing to make it more relevant to other people on the team. So then we can have more overlap, or at least I can share a lot of the work that's being done.

+ +

CHRIS: Yeah, absolutely. I think with that wonderful summary and, frankly, utterly fantastic movie reference, what do you think? Should we wrap up?

+ +

STEPH: Let's do it. Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+KBCHXjeG + + ]]> + + Chris Toomey + Steph Viccari + + + 342: Sky Icing + https://bikeshed.thoughtbot.com/342 + 5f59d009-75eb-4c03-8ecc-e77160b2e135 + Tue, 14 Jun 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Another toaster strudel debate?! Plus, the results are in for the most listened-to podcast in the RoR community! :: drum roll :: + +Steph has a "Dear Gerrit" message to share. Chris has a follow-up on mobile app strategy. + 43:42 + no + + + Another toaster strudel debate?! Plus, the results are in for the most listened-to podcast in the RoR community! :: drum roll :: +Steph has a "Dear Gerrit" message to share. Chris has a follow-up on mobile app strategy. +The Bike Shed: 328: Terrible Simplicity (https://www.bikeshed.fm/328) +When To Fetch: Remixing React Router - Ryan Florence (https://www.youtube.com/watch?v=95B8mnhzoCM) +Virtual Event - Save Time & Money with Discovery Sprints (https://thoughtbot.com/events/save-time-money-with-discovery) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: thoughtbot's next virtual event "Save Time & Money with Discovery Sprints" is coming up on June 17th, from 2 - 3 PM Eastern. It's a discussion with team members from product management, design and development. From a developer perspective, topics will include how to plan a product's architecture, both the MVP and future version, how to lead a tech spikes into integrations and conduct a build vs buy reviews of third party providers. Head to thoughtbot.com/events to register, the event is June 17th 2 - 3 PM ET. Even if you can't make it, registering will get you on the list for the recording. +CHRIS: We're the second-best. We're the second-best. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: I'm very happy to report that I picked up a treat from the store recently. So while I was in Boston and we were hanging out in person, we talked about Pop-Tarts because that always comes up as a debate, as it should. And then also Toaster Strudels came up, so I now have a package of Toaster Strudels, and those are legit. Pop-Tart or Toaster Strudel, I am team Toaster Strudel, which I know you're going to ask me about icing and if I put it on there, so go ahead. I'm going to pause. [laughs] +CHRIS: It sounds like I don't even need to say anything. But yes, inquiring minds want to know. +STEPH: I think that's also my very defensive response because yes, I put icing on my Toaster Strudel. +CHRIS: How interesting. [laughs] +STEPH: But it feels like a whole different class of pastry. So I'm very defensive about my stance on Pop-Tarts with no icing put Strudel with icing. +CHRIS: A whole different class of pastry. Got it. Noted. Understood. So did you travel? Like, were these in your luggage that you flew back with? +STEPH: [laughs] Oh no. They would be all gooey and melty. No, we bought them when we got back to North Carolina. Oh, that'd be a pro move; just pack little individual Strudels as your airplane snack. Ooh, I might start doing that now. That sounds like a great airplane snack. +CHRIS: You got to be careful though if the icing, you know, if it's pressurized from ground level and then you get up there, and it explodes. And you gotta be careful. Or is it the reverse? It's lower pressure up in the plane. So it might explode. +STEPH: [laughs] Either way, it might explode. +CHRIS: Well, yeah. If you somehow buy a packet of icing that is sky icing that is at that pressure, and you bring it down, then...but if you take it up and down, I think it's fine. If you open it at the top, you might be in danger. If you open icing under the ocean, I think nothing's going to happen. So these are the ranges that we're playing with. +STEPH: I will be very careful sky icing and probably pack two so that way I have a backup just in case. So if one explodes, we'll be like, all right, now I know what I'm working with and be more prepared for the next one. +CHRIS: That's just smart. +STEPH: I try to make smart travel decisions, Toaster Strudels on the go. Aside from travel treats and sky icing, I have some news regarding Planet Argon, who is a Ruby on Rails consultancy regarding their latest published this year's Ruby on Rails community survey results. And so they list a lot of fabulous different topics in there. And one of them includes a learning section that highlights most listened to podcasts in the Ruby on Rails community as well as blogs and some other resources. And Bike Shed is listed as the second most listened to podcast in the Ruby on Rails community, so whoo, golf clap. +CHRIS: Fantastic. +STEPH: And in addition to that, the thoughtbot blog got a really nice shout-out. So the thoughtbot blog is in the number two spot for the most visited blogs in the community. In the first spot is Ruby Weekly, which is like, you know, okay, that feels fair, that feels good. So it's really exciting for the thoughtbot blog because a lot of people work really hard on curating and creating that content. So that's wonderful that so many people are enjoying it. +And then I should also highlight that for the podcast in first place is Remote Ruby, so congrats to Chris, Jason, and Andrew for grabbing that number one spot. And Brittany Martin, host of the Ruby on Rails Podcast, along with Brian Mariani, Jemma Issroff, and Nick Schwaderer, are in the number three spot. And some people say that Ruby is losing steam but look at all that content and all those highly ranked podcasts. I mean, we like Ruby so much we're spending time recording ourselves talking about it. So I say long live Ruby, long live Rails. +CHRIS: Yes. Long live Ruby indeed. And yeah, it's definitely an honor to be on the list and to be amongst such other wonderful shows. Certainly big fans of the work of those other podcasts. We even did a joint adventure with them at one point, and that was a really wonderful experience, so yeah, honored to be on the list alongside them. And to have folks out there in the world listening to our tech talk and nonsense always nice to hear. +STEPH: Yeah. You and I show up and say lots of silly things and technical things into the podcast. The true heroes are the ones that went and voted. So thank you to everybody who voted. That's greatly appreciated. It's really nice feedback. Because we get listener responses and questions, and those are wonderful because it lets us know that people are listening. But I have to say that having the survey results is also really nice. It lets us know people like the show. +Oh, but I did go back and look at some of the previous stats because then I was like, huh, so I'm paying attention. I looked at this year's, and I was like, I wonder what last year’s was or the year before that. And I think this survey comes out every two years because I didn't see one for 2021. But I did find the survey results for 2020, which we were in the number one spot for 2020, and Remote Ruby was in the second spot. +So I feel like now we've got a really nice, healthy podcasting war situation going on to see who can grab the first spot. We've got two years, everybody, to see who [laughs] grabs the number one spot. That's a lot of prep time for a competition. +CHRIS: Yeah, I feel like we should be like, I don't know, planning elaborate pranks on them or something like that now. Is that where this is at? It's something like that, I think. +STEPH: I think so. I think this is where you put like sky frosting inside someone's suitcase, and that's the type of prank that you play. [laughs] +CHRIS: The best of pranks. +STEPH: We'll definitely put together a little task force. And we'll start thinking of pranks that we all need to start playing on each other for the podcasting wars that we're entering for the next few years. But anywho, what's going on in your world? +CHRIS: Let's see, what's going on in my world? A fun thing happened recently. I had a chance to reflect back on some architectural choices that we've made in the Sagewell platform. And one of those specific choices is how we've approached building our native mobile apps. We made what some listeners may remember is an interesting set of choices. In particular, in Episode 328, which we'll include a link to in the show notes, I shared with you the approach that we're doing, which is basically like, Inertia is great, web user great. We like the web as a platform. What if we were to wrap it in a native shell and find this interesting and somewhat unique hybrid trade-off point? +And so, at that point, we were building it. We had most of it built out, and things were going quite well. I think we maybe had the iOS app in the store and the Android app approaching the store or something like that. At this point, both apps have been released to the store, so they are live. Production users are signing in. It's wonderful. But I had a moment in the past couple of weeks to reassess or look at that set of choices and evaluate it. And thankfully, I'm happy with the choices that we've made. So that's good. +But to get into the specifics, there were two things that happened that really, really framed the choice that we made, so one was we introduced a major new feature. We basically overhauled the first-run experience, the onboarding that users experience, and added a new, pretty fundamental facet to the platform. It's a bunch of new screens, and flows, and error states, and all of this complexity. And in the process, we iterated on it a bunch. Like, first, it looked like this, and then we changed the order of the screens and switched out the error messages, and et cetera, et cetera. +And I'll be honest, we never even thought about the mobile apps. It just wasn't even a consideration. And interestingly, we did as a final check before going fully live and releasing this out to the full production audience; we did spot check it in the mobile apps, and it didn't work. But it didn't work for a very specific, boring, technical reason that we were able to resolve. It has to do with iframes and WebViews and embedded something, something. And we had to set a flag. Thankfully, it was solvable without a deploy of the native mobile apps. And otherwise, we never thought about the native apps. +Specifically, we were able to add this fundamental set of features to our platform. And they just worked in native mobile. And they were the same as they roughly are if you're on a mobile WebView or if you're on a desktop web, you know, slightly different in terms of form factor. But the functionality was all the same. And critically, the error states and the edge cases and the flow, there's so much to think about when you're adding a nontrivial feature to an app. And the fact that we didn't have to consider it really spoke to the choice that we made here. +And again, to name it, the choice that we made is we're basically just reusing the same WebViews, the same Rails controllers, and the same what are Svelte components under the hood but the same essentially view layer as well. And we are wrapping that in a native iOS. It's a Swift application shell, and on Android, it's a Kotlin application shell. But under the hood, it's the same web stuff. And that was really great. +We just got these new features. And you know what? If we have to rip that whole set of functionality out, again, we won't need to deploy. We won't need to rethink it. Or, if we want to subtly tweak it, we can do that. If we want to think about feature flags or analytics, or error states or error reporting, all of this just naturally falls out of the approach that we took. And that was really wonderful. +STEPH: That's super nice. I also love this saga of like, you made a choice, and then you're coming back to revisit and share how it's going. So as someone who's never done this before, in regards of wrapping an application in the manner that you have and then publishing it and distributing it that way, what does that process look like? Is this one of those like you run a command, and literally, it's going to wrap the application and then make it hostable on the different mobile app stores? Or what's that? Am I oversimplifying the process? What does that look like? +CHRIS: I think there are a lot of platforms or frameworks I think would probably be the better word like Capacitor is something that comes to mind or Ionic or Expo. There are a handful of them that are a little more fully featured in what they provide. So you just point us at your React Views and whatnot, and we'll wrap that up, and it'll be great. But those are for, I may be overgeneralizing here, but my understanding is those are for more heavy client-side bundles that are talking to a common API. And so you're basically taking your same rich client-side application and bundling that up for reuse on the native app, the native app platforms. +And so I think those do have some release to the store sort of thing. In our case, we went a little bit further with that integration wrapper thing that we built. So that is a thing that we maintain. We have a Sagewell iOS repo and a Sagewell Android repo. There's a bunch of Swift and Kotlin code, respectively, in each of them, and we deploy to the stores manually. We're doing that whole process. But critically, the code that is in each of those repositories is just the bridge glue code that says, oh, when this Inertia navigation event happens, I'm going to push a WebView to the navigation stack. And that's what that is. +I'm going to render the tab bar of buttons at the bottom with the navigation elements that I get from the server. But it's very much server-driven UI, is the way that I would describe it. And it's wrapping WebViews versus actually having the whole client bundle wrapped up in the thing. It's unfortunately subtle to try and talk through on the radio, but yeah. [laughs] +STEPH: You're doing great; this is helping. So if there's a change that you want to make, you go to the Rails application, and you make that change. And then do you need to update anything on that iOS repo? It sounds like you don't, which then you don't have to push a new update to the store. +CHRIS: Correct. For the vast majority of things, we do not need to make any changes. It's very rare for us to deploy the iOS or the Android app is a different way to put it or to push new releases to the store. It happens we may want to add a new feature to the sort of bridge layer that we built, but increasingly, those are rare. And now it's basically like, yeah, we're just wrapping those WebViews, and it's going great. And again, to name it, it's a trade-off. It's an intentional trade-off that we've made. +We're never going to have the richest, most deep platform integration, smooth experience. We are making a small trade-off on that front. But given where we're at as an organization, given how early we are, how much iteration and change, we chose an architecture that optimizes for that change. And so again, like what you just said, yeah, I can...you know how it's really nice to be able to deploy six times a day on a web app, and that's a very straightforward thing to do? It is not so straightforward in the native mobile world. And so, we now have afforded ourselves the ability to do that. +But critically, and this is the fun part in my mind, have the trade-offs in the controls. So if we were just like, it's just a WebView, and that's it, and we put it in the stores, and we're done, that is too far of an extreme in my mind. I think the performance trade-offs, the experience trade-offs, it wouldn't feel like a native app like in a deep way, in a problematic way. And so as an example, we have a navigation bar at the top of our app, particularly on iOS, that is native iOS navigation. And we have a tab bar at the bottom, which is native tab UI element. I forget actually what it's called, but it's those elements. +And we hide the web application navigation when we're in the mobile context. So we actually swap those out and say, like, let's actually promote these to formal native functionality. We also, within our UI on the web, have a persistent button in the top right corner of your screen that says, "Need help? Reach out to your retirement advocate." who is the person that you get to work with. You can send questions, et cetera, et cetera. It's this little help sidebar drawer thing that pops out. And we have that as a persistent HTML button in the top corner of the web frame. +But when we're on native, we push that up as a distinct element in the native UI section. And then again, the bridge that I'm talking about allows for bi-directional communication between the JavaScript side and the native side or the native side and the JavaScript side. And so it's those sorts of pieces that have now afforded us all of the freedom to tinker, and we don't need to re-release where we're like, oh, we want to add a new weird button that does a thing in the WebView when you click on a button outside the WebView. We now just have that built-in. +STEPH: Yeah, I really like the flexibility that you're describing. When you promoted those elements to be more native-friendly so, like the navigation or the footer or the little get help chat, is that something that then your team implemented in like the iOS or the Kotlin repo? Okay, I see you nodding, but other people can't see that, so...[laughs] +CHRIS: Yeah. I was going to also say the words, but yes, those are now implemented as native parts. So the thing that we built isn't purely agnostic decoupled. It is Sagewell-specific; a lot of it is low-level. Like, let's say we want to wrap an Inertia app in a native mobile wrapper. Like, 90% of the code in it is that, but then there are little bits that are like, and put a button up there. And that button is the Sagewell button. And so it's not entirely decoupled from us. But it mostly is this agnostic bridge to connect things together. +STEPH: Yeah, the way you're describing it sounds really nice in terms of you're able to get out the app quickly and have a mobile app quickly that works on both platforms, and then you're still able to deploy changes without having to push that. That was always my biggest mental, or emotional hurdle with the idea of mobile development was the concept of that you really had to batch everything together and then submit it for review and approval and then get it released. +And then you got to hope people then upgrade and get the newest version. And it just felt like such a process, not that I ever did much of it. This was all just even watching like the mobile team and all the work that they had to do. And I had sympathy pains for them. But the fact that this approach allows you to avoid a lot of that but still have some nice, customized, more native elements. Yeah, I'm basically just recapping everything you said because I like all of it. +CHRIS: Well, thank you, friend. Like I said, I've really enjoyed it, and similar to you, I'm addicted to the feedback loop of the web. It's beautiful. I can deploy ten times or however many I want. Anytime I want, I can push out a new version. And that ability to iterate, to test, to explore, to tweak, to not have to do as much formal testing upfront because I'm terrified that if a bug sneaks out, then, it'll take me two weeks to address it; it just is so, so freeing. And so to give that up moving into a native context. +Perhaps I'm fighting too hard to hold on to my dream of the ability to rapidly iterate. But I really do believe in that and especially for where we're at as an organization right now. But, and a critical but here, again, it's a trade-off like anything else. And recently, I happened to be out about in the town, and I decided, oh, you know what? Let me open up the app. Let me see what it's like. And I wasn't on great internet. And so I open the app, and it loads because, you know, it's a native app, so it pops up. +But then the thing that actually happened is a loading spinner in the middle of the screen and sort of a gray nothing for a little while until the server request to fetch the necessary UI elements to render the login screen appeared. And that experience was not great. In particular, that experience is core to the experience of using the app every single time. Every time you use it, you're going to have a bad time because we're re-downloading that UI element. And there's caching, and there's things that could happen there to help with that. But fundamentally, that experience is going to be a pretty common one. It's the first thing that you experience when you're opening the app. +And so I noticed that and I chatted with the team, and I was like, hey, I feel like this is actually something that fixing this I think would really fundamentally move us along that spectrum of like, we've definitely made some trade-offs here. But overall, it feels snappy and like a native app. And so, we opted to prioritize work on a native login screen for both platforms. This also allows us to more deeply integrate. So particularly, we're going to get biometric logins like fingerprints or face scans, or whatever it is. +But critically, it's that experience of like, I open the Sagewell native app on my iOS phone, and then it loads immediately. And then I show it my face like we do these days, and then it opens up and shows me everything that I want to see inside of it. And it's that first-run experience that feels worth the extra effort and the constraints. Because now that it's native mobile, that means in order to change it, we have to do a deploy, not a deploy, release; that's what they call it in the native world. [laughs] You can tell I'm well-versed in this ecosystem. +But yeah, we're now choosing that trade-off. And what I really liked about this sort of set of things like the feature that we were able to just accidentally get for free on native because that's how this thing is built. And then likewise, the choice to opt into a fully native login screen like having that lever, having that control over I'm going to optimize for iteration generally, but where it's important, we want to optimize for performance and experience. And now we have this little slider that we can go back and forth. +And frankly, we could choose to screen by screen just slowly replace everything in the app with true native WebViews backed by APIs. And we could Ship of Theseus style replace every element of the app with true native mobile things until none of the old bridge code exists. And our users, in theory, would never know. Having that flexibility is really nice given the trade-off and the choice that we've made. +STEPH: You said a word there that I missed. You said ship something style. +CHRIS: Ship of Theseus. +STEPH: What is that? +CHRIS: It's like an old biblical story, I want to say, but it's basically the idea of, like, you have the ship. And then some boards start to rot out, so replace those boards. And then the mast breaks, you replace the mast. And slowly, you've replaced every element on the ship. Is it still the same ship at that point? And so it's sort of a philosophical question. So if we replace every single view in this app with a native view, is it still the same map? Philosophers will philosophize about it forever, but whatever. As long as we get to keep iterating and shipping software, then I'm happy. +STEPH: [laughs] Y’all philosophize. That's that word, right? +CHRIS: Yeah. +STEPH: And do your philosopher thing. We'll just keep building and shipping. +CHRIS: I don't know if I pronounced it right. It's like either Theseus or Theseus, and I'm sure I said the wrong one. And now that I've said the other, I'm sure both of them are wrong somehow. It's like a USB where there's up and down, and yet somehow it takes three tries. So anyway, I may have mispronounced it, and I may be misattributing it, but that's the idea I was going for. +STEPH: Well, given I wasn't even familiar with the word until just now, I'm going to give both pronunciations a thumbs up. I also really like how you decided that for the login screen, that's the area that you don't want people to wait because I agree if you're opening an application or opening...maybe it's the first time, maybe it's the 100th time. Who knows? But that feels important. Like, that needs to be snappy. I need to know it's responsive. And it builds trust from the minute that I clicked on that application. And if it takes a long time, I just immediately I'm like, what are y'all doing? Are y'all real? Do you know what you're doing over there? +So I like how you focused on that experience. But then once I log in, like if something is slow to log me in, I will make up excuses for the application all day where I'm like, well, you know, maybe it's my connection. It's fine. I can wait for the next screen to load. That feels more reasonable. And it doesn't undermine my trust nearly as much as when I first click on the app. So that feels like a really nice trade-off as well, or at least a nice area that you've improved while still having those other trade-offs and benefits that you mentioned. +CHRIS: To highlight it, you used a phrase there which I really liked. Like, it's building trust. If something's a little bit off in that first run experience every single time, then it kind of puts a question in the back of your head, maybe not even consciously. But you're just kind of looking at it, and you're like, what are you doing there? What are you up to, friend? Humans say to the apps they use on their phone. That's normal, right? When you talk... +But to name it, we've also done a round of performance work throughout the app. And so there are a couple of layers to it. But it was work that we had planned for a while, but we kept deferring. But now that we're seeing more usage of the native apps, the native apps experience the same surface area of performance stuff but all the more so because they may be on degraded network connections, et cetera. +And so this is another example where this whole thing kind of pays off. The performance work that we did affects everything. It affects the web. It's the same under the hood. It's let's reduce the network requests that we're making in the payloads that we're sending, particularly the network requests to upstream things, so like the banking partner that we're using and those APIs, like, collating all the data to then render the screen. +Because of Inertia, we only have a single sort of back and forth conversation via the API as opposed to I think it's pretty common to have like seven different APIs and four different spinners on the screen. We're not doing that, none of that on my watch. [chuckles] But we minimize the background calls to the other parties that we're integrating with. And then, we reduce the payload of data that we're sending on each request. +And each of those were like, we had to think about things and tweak and poke, but again it's uniform. So mobile web has that now, desktop web has that now. Android, iOS, they all just inherited it sort of that just happened one day without a deploy or release, without a release of either of the native mobile apps. We did deploy to the web to make that happen, but that's easy. I can do that a bunch of times a day. +One last thing I want to share as we're on this topic of trade-offs and levers, there was a really great conference talk that I watched recently, which was Ryan Florence of remix.run also React Router fame if you're familiar with him from that. But he was talking about the most recent version of Remix, which is their meta framework on top of React. +But they've done some really interesting stuff around processing data, fetching data, when and how to sequence that. And again, that thing that I talked about of nine different loading spinners on the screen, Remix is taking a very different approach but is targeting that same thing of like, that's not great for user experience. Cumulative layout shift being the actual number that you can monitor for this. +But in that talk, there are features that they've added to Remix as a framework where you can just decide, like, do we wait for this or do we not? Do we make sure we have all of the data, or do we say, you know what? Actually, this is going to be below the fold. So it's okay to defer loading this until after we send down the first payload. And then we'll kick in, and we'll do it from the client-side. But it's this wonderful feature of the framework that they're adding in where there's basically just a keyword that you can add to sort of toggle that behavior. +And again, it's this idea of like trade-offs. Are we okay with more layout shift, or are we okay with more waiting? Which is it that we're going to optimize for? And I really love that idea of putting that power very simply in the hands of the developers to make those trade-off decisions and optimize over time for what's important. So we'll share a link to that talk in the show notes as well. +But it was very much in the same space of like, how do I have the power to decide and to change my mind over time? That's what I want. But yeah, with that, I think that's enough of me updating on the mobile app. I'll continue to share as new things happen. But again, I'm at this point very happy with where we're at. So yeah, it's been fun. But yeah, what else is up in your world? +STEPH: I have a dear Gerrit message that I wrote earlier, so I want to share that with you. Gerrit is the system that we're using for when we push up code changes that then manages very similar in the competitive space of like GitHub and GitLab, and Bitbucket. And so the team that I'm working with we are using Gerrit. And Gerrit and I, you know, we get along for the most part. We've managed to have a working relationship. [chuckles] But this week, I wrote my dear Gerrit letter is that I really miss being able to tell a story with my commit messages. That is the biggest pain that I'm feeling right now. +So for anyone that's less familiar or if you already are familiar with Gerrit, each change that Gerrit shows represents a single commit that's under review. And each change is identified by a Change-Id. So the basic concept of Gerrit is that you only have one commit per review. So if you were to translate that to GitHub terminology, every pull request is only going to have one commit, and so you really can't push up multiple. +And so, where that has been causing me the most pain is I miss being able to tell a story. So like even simple stories that are like, hey, I removed something that's not used. I love separating that type of stuff into its own commit just so then people can see that as they're going through review. Now, before I merge, I'm likely to squash, and that doesn't feel important that it needs to be its own commit. That's really just for the reviewer so they can follow along for the changes. +But the other one, I can slowly get over that one. Because essentially, the way I get around that is then when I do push up my code for review, is I then go through my change request, and then I just add comments. So I will highlight that line and say, "Hey, I'm removing this because it's not in use." And so, I found a workaround for that one. +But the one I haven't found a workaround for is that I don't push up my local work very often because I love having lots of local, tiny, green commits so that way I can know the progress that I'm at. I know where I'm headed. Also, I have a safe space to roll back to, but then that means that I may have five or six commits that I have locally, but I haven't pushed up somewhere. And that is bothering me more and more hour by hour the more I think about it that I can't push stuff up because it makes me nervous. +Because, I mean, usually, at least by the end of the day, I push everything up, so it's stored somewhere. And I don't have to worry about that work disappearing. Now I am working on a dev machine. So there is that aspect of it's technically...it's not even on my local machine. It is stored somewhere that I should still be able to access. +CHRIS: What's a dev machine? The way you're saying it, it sounds like it's a virtual machine, not like a laptop. But what's a dev machine? +STEPH: Good question. So the dev machine is a remote server or remote machine that then I am accessing, and then that's where I'm performing. That's where I'm writing all of my work. And then that's also kind of the benefit is everything is not local; it's controlled by the team. So then that also means that other teams, other individuals can help set up these environments for future developers. +So then you have that consistency across everyone's working with the same Rails version, or gems, or has access to the same tools. So in that sense, my work isn't just on my laptop because then that would really worry me because then I've got nowhere...it's not backed up anywhere. So at least it is somewhere it's being stored that then could be accessed by someone. +So actually, now, as I'm talking this through, that does help alleviate my concern about this a bit. [laughs] But I still miss it; I still miss being able to just push up my work and then have multiple commits. And I looked into it because I was like, well, maybe I'm misunderstanding something about Gerrit, and there's a way around this. And that's still always a chance. But from the research that I've done, it doesn't seem to be. And there are actually two very fiery takes that I saw that I have to share because they made me laugh. +When I was Googling, the question of like, "Can I push up multiple commits to one single Gerrit CR? Or is there just a way to, like, can I have this concept of like a branch and then I have many commits, but then I turn it into one CR? Whatever the world would give me. What do they have? [laughs] I'm laughing just looking at this now. One of the responses was, have you tried squashing your commits into one commit? And I was like, [laughs] "Yeah, that's not what I had in mind, but sure." +And then the other one, this is the more fiery take. They were very defensive about Gerrit, and they wrote that "People who don't like Gerrit usually just hack shit together. They cut corners and love squashing commits or throwing away history. And those people hate Gerrit. Developers who care love it. It's definitely possible and easy to produce agile software." And I just...that made me laugh. I was like, cool, I'm a developer that cuts corners and loves squashing commits. [laughs] +CHRIS: So you don't care is what that take says. +STEPH: I'm a developer who does not care. +CHRIS: You know, Steph, I've worked with you for a while. And I've been looking for the opportunity to have this hard conversation with you. But I just wish you cared a little more about the software that you're writing, about the people that you're working with, about the commits that you're authoring. I just see it in every facet of your work. You just don't care. To be very clear for anyone listening at home, that is the deepest of sarcasm that I can make. Steph cares so very much. It's one of the things that I really enjoy about you. +STEPH: I mean, we had the episode about toxic traits. This would have been the perfect time to confront me about my lack of caring about software and the processes that we have. So winding down on that saga, it seems to be the answer is no, friend; I cannot push up multiple commits. Oh, I tried to hack it. I am someone that tries to hack shit together because I tried to get around it just to see what would happen. [laughs] Because the docs had suggested that each change is identified by a Change-Id. And I was like, hmm, so what if there were two commits that had the same Change-Id, would Gerrit treat those as patch sets? +Because right now, when you push up a change, you can see all the different patch sets, so that's nice. So that's a nice feature of Gerrit as you can see the history of, like, someone pushed up this change. They took in some feedback. They pushed up a new change. And so that history is there for each push that someone has provided. And I wondered maybe if they had the same Change-Id that then the patch sets would show the first commit and then the second commit. And so I manually altered the commits two of them to reference the same Change-Id. +And I have to say, Gerrit was on to me because they gave me a very nice error message that said, "Same Change-Id and multiple changes. Squash the commits with the same Change-Ids or ensure Change-Ids are unique for each commit. And I thought, dang, Gerrit, you saw me coming. [laughs] So that didn't work either. I'm still in a world of where I now wait. I wait until I'm ready for someone to review stuff, and I have to squash everything, and then I go comment on my CRs to help out reviewers. +CHRIS: I really like the emotional backdrop that you provided here where you're spending a minute; you're like, you know what? Maybe it's me. And there's the classic Seymour Skinner principle from The Simpsons. Am I out of touch? No, it's the children who are wrong. [laughs] And I liked that you took us on a whole tour of that. You're like, maybe it's me. I’ll maybe read up. Nope, nope. So yeah, that's rough. +There's a really interesting thing of tools constraining you. And then sometimes being like, I'm just going to yield control and back away and accept this thing that doesn't feel right to me. Like, Prettier does a bunch of stuff that I really don't like. It shapes code in a way, and I'm just like, no, that's not...nope, you know what? I've chosen to never care about this again. And there's so much utility in that choice. And so I've had that work out really well. Like with Prettier, that's a great example whereby yielding control over to this tool and just saying, you know what? Whatever you produce, that is our format; I don't care. And we're not going to talk about it, and that's that. +That's been really useful for myself and for the teams that I'm on to just all kind of adopt that mindset and be like, yeah, no, it may not be what I would choose but whatever. And then we have nice formatted code; it's great. It happens automatically, love it. But then there are those times where I'm like; I tried to do that because I've had success with that mindset of being like, I know my natural thing is to try and micromanage and control every little bit of this code. +But remember that time where it worked out really well for me to be like, I don't care, I'm just going to not care about this thing? And I try to not care about some stuff, which it sounds like that's what you're doing right here. [laughs] And you're like, I tried to not care, but I care. I care so much. And now you're in that [chuckles] complicated space. So I feel for you, Steph. I'm sorry you're in that complicated space of caring so much and not being able to turn that off [laughs] nor configure the software to do the thing you want. +STEPH: I appreciate it. I should also share that the team that I'm working with they also don't love this. Like, they don't love Gerrit. So when I shared in the Slack channel my dear Gerrit message, they're both like, "Yeah, we feel you. [laughs] Like, we're in the same spot," which was also helpful because I just wanted to validate like, this is the pain I'm feeling. Is someone else doing something clever or different that I just don't know about? And so that was very helpful for them to say, "Nope, we feel you. We're in the same spot. And this is just the state that we're in." +I think they have started transitioning some other repos over to GitLab and have several repos in Gitlab, but this one is still currently using Gerrit. So they very much commiserate with some of the things that I'm feeling and understand. And this does feel like one of those areas where I do care deeply. +And frankly, this is one of those spaces that I do care about, but it's also like, I can work around it. There are some reasonable things that I can do, and it's fine as we just talked through. Like, the fact that my commits are not just locally on my machine already makes me feel better now that I've really processed that. So there are lower risks. It is more of just like a workflow. It's just, you know, it's crushing my work vibe. +CHRIS: Harshing your buzz. +STEPH: In the great words of Queen Elsa, I gotta let it go. This is the thing I'm letting go. So that's kind of what's going on in my world. What else is going on in your world? +CHRIS: Well, first and foremost, fantastic reference and segue. I really liked that. But yeah, let's see, [laughs] what else is going on in my world? We had an interesting thing happen last week. So we had an outage on the platform last week. And then we had an incident review today, so a formal sort of post-mortem incident review. There are a couple of different names that folks have given to these. But this is a practice that we want to build within our engineering culture is when stuff goes wrong, we want to make sure that we have meaningful conversations around to try to address the root causes. +Ideally, blameless is a word that gets used often in this context. And I've heard folks sort of take either side of that. Like, it's critical that it's blameless so that it doesn't feel like it's an attack. But also, like, I don't know, if one person did something, we should say that. So finding that gentle middle ground of having honest, real conversations but in a context of safety. Like, we're all going to make mistakes. We're all going to ship bugs; let's be clear about that. And so it's okay to sort of...anyway, that's about the process. +We had an outage. The specific outage was that we have introduced a new process. This is a Sidekiq process to work off a specific queue. So we wanted that to have discrete treatment. That had been running, and then it stopped running; we still don't know why. So we never got to the root-root cause. Well, we know what the mechanism was, which was the dyno count for that process was at zero. And so, eventually, we found a bunch of jobs backed up in the Sidekiq admin. We're like, that's weird. +And then, we went over to Heroku's configuration dashboard. And we saw, huh, that's weird. There are zero dynos processing this. That wasn't true yesterday. But unfortunately, Heroku doesn't log or have an audit trail around changes to those process counts. It's just not available. So that's unfortunate. And then the actual question of like, how did this happen? It probably had to be someone on the team. So there is like, someone did a thing. But that is almost immaterial because, again, people are going to do things, bugs will get shipped, et cetera. +So the conversation very quickly turned to observability and understanding. I think we've done a pretty good job of instrumenting error reporting and being quite responsive to that, making sure the signal-to-noise ratio is very actionable. So if we see a bug or a Sentry alert come through, we're able to triage that pretty quickly, act on it where it is a real bug, understand where it's a bit of noise in the system, that sort of thing. But in this case, there were no errors. There was no Sentry. There was nothing; there was the absence of something. +And so it was this really interesting case of that's where observability, I think, can really come in and help. So the idea of what can we do here? Well, we can monitor the count of jobs backed up in Sidekiq queue. That's one option. We could do some threshold alerting around the throughput of processed events coming from this other backend. There are a bunch of different ways, but it basically pushed us in the direction of doubling down and reinforcing the foundation of our observability within the platform. +So we're just kicking that mini-project off now, but it is something we're like, yeah, we feel like we could add some here. In particular, we recently added Datadog to the stack. So we now have Datadog to aggregate our logs and ideally do some metric analysis, those sort of things, build some dashboards, et cetera. I haven't explored Datadog much thus far. But my sense is they've got the whiz-bang things that we need here. But yeah, it was an interesting outage. That wasn't fun. The incident conversation was actually a good conversation as a team. And then the outcome of like, how do we double down on observability? I'm actually quite excited for. +STEPH: This is a fun moment for me because I have either joined teams that didn't have Datadog or have any of that sort of observability built into their system or that sort of dashboard that people go to. Or I've joined teams, and they already have it, and then nobody or people rarely look at it. And so I'm always intrigued between like what's that catalyst that then sparked a team to then go ahead and add this? And so I'm excited to hear you're in that moment of like, we need more observability. How do we go about this? +And as soon as you said Datadog, I was like, yeah, that sounds nice because then it sounds like a place that you can check on to make sure that everything is still running. But then there's still also that manual process where I'm presuming unless there's something else you have in mind. There's still that manual process of someone has to check the dashboard; someone then has to understand if there's no count, no squiggly lines, that's a bad thing and to raise a concern. +So I'm intrigued with my own initial reaction of, like, yeah, that sounds great. But now I'm also thinking about it still adds a lot of...the responsibility is still on a human to think of this thing and to go check it. Versus if there's something that gets sent to someone to alert you and say like, "Hey, this queue hasn't been processed in 48 hours. There may be a concern that actually feels nicer." It feels safer. +CHRIS: Oh yeah, definitely. I think observability is this category of tools and workflows and whatnot. But I think what you're describing of proactive alerting that's the ideal. And so it would be wonderful if I never had to look at any of these tools ever. And I just knew if I got, let's say, it's PagerDuty connected up whatever, and I got a push notification from PagerDuty saying, "Hey, go look at this thing." That's all I ever need to think about. It’s like, well, I haven't gotten a PagerDuty in a while, so everything must be fine, and having a deep trust in that. +Similar to like, if we have a great test suite and it's green, I feel confident deploying the sort of absence of an alert being the thing that I can trust. But right now, we're early enough in this journey that I think what we need to do is stand up a bunch of these different graphs and charts and metric analysis and aggregations and whatnot, and then start to squint at it for a while and be like, which of these would I be really concerned if it started to wibble? +And then you can figure the alerting around said wibble rate. And that's the dream. That's where we want to get to, but I think we've got to crawl, walk, run on this. So it'll be an adventure. This is very much the like; we're starting a thing. I'll tell you about it more when we've done it. But what you're describing is exactly what we want to get to. +STEPH: I love wibble rate. That's my new measurement I'm going to start using for everything. It's funny, as you're bringing this up, it's making me think about the past week that Joël Quenneville and I have had with our client work. Because a somewhat similar situation came up in regards where something happened, and something was broken. And it seemed it was hard to define exactly what moment caused that to break and what was going on. +But it had a big impact on the team because it essentially meant none of the bills were going through. And so that's a big situation when you got 100-plus people that are pushing up code and expecting some of the build processes to run. But it was one of those that the more we dug into it, the more it seemed very rare that it would happen. +So, in this case, as a sort of a juxtaposition to your scenario, we actually took the opposite approach of where we're like; this is rare. But we did load up a lot of contexts. Actually, I was thinking back to the advice that you gave me in a previous episode where I was talking about at what point do you dig in versus try to stay at surface level? And this was one of those, like, we've spent a couple of days on getting context for this and understanding. So it felt really important and worthwhile to then invest a little bit more time to then document it. +But then we still went with the simplest approach of like, this is weird. It shouldn't happen again. We think we understand it but then let's add a little bit of documentation or wiki page around like, hey, if you do run into this, here are some steps that will fix everything. And then, if you need to use this, let somebody know because this is so odd it shouldn't happen. So we took that approach in this case where we didn't increase the observability. It was more like we provided a fire extinguisher very close to the location in case it happens. And so that way, it's there should the need arise, but we're hoping it just never gets used. +We're also in the process of changing how a lot of that logic works. So we didn't really want to optimize for observability into a system that is actively being changed because it should look very different in upcoming months. But overall, I love the conversations that you bring about observability, and I'm excited to hear about what wibble rates you decide to add to your Datadog dashboard. +CHRIS: There's a delicate art and science to the selection of the wibble rates. So I will certainly report back as we get into that work. But with that, shall we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Another toaster strudel debate?! Plus, the results are in for the most listened-to podcast in the RoR community! :: drum roll ::

+ +

Steph has a "Dear Gerrit" message to share. Chris has a follow-up on mobile app strategy.

+ +
+ +

The Bike Shed: 328: Terrible Simplicity
+When To Fetch: Remixing React Router - Ryan Florence
+Virtual Event - Save Time & Money with Discovery Sprints

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: thoughtbot's next virtual event "Save Time & Money with Discovery Sprints" is coming up on June 17th, from 2 - 3 PM Eastern. It's a discussion with team members from product management, design and development. From a developer perspective, topics will include how to plan a product's architecture, both the MVP and future version, how to lead a tech spikes into integrations and conduct a build vs buy reviews of third party providers. Head to thoughtbot.com/events to register, the event is June 17th 2 - 3 PM ET. Even if you can't make it, registering will get you on the list for the recording.

+ +

CHRIS: We're the second-best. We're the second-best. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: I'm very happy to report that I picked up a treat from the store recently. So while I was in Boston and we were hanging out in person, we talked about Pop-Tarts because that always comes up as a debate, as it should. And then also Toaster Strudels came up, so I now have a package of Toaster Strudels, and those are legit. Pop-Tart or Toaster Strudel, I am team Toaster Strudel, which I know you're going to ask me about icing and if I put it on there, so go ahead. I'm going to pause. [laughs]

+ +

CHRIS: It sounds like I don't even need to say anything. But yes, inquiring minds want to know.

+ +

STEPH: I think that's also my very defensive response because yes, I put icing on my Toaster Strudel.

+ +

CHRIS: How interesting. [laughs]

+ +

STEPH: But it feels like a whole different class of pastry. So I'm very defensive about my stance on Pop-Tarts with no icing put Strudel with icing.

+ +

CHRIS: A whole different class of pastry. Got it. Noted. Understood. So did you travel? Like, were these in your luggage that you flew back with?

+ +

STEPH: [laughs] Oh no. They would be all gooey and melty. No, we bought them when we got back to North Carolina. Oh, that'd be a pro move; just pack little individual Strudels as your airplane snack. Ooh, I might start doing that now. That sounds like a great airplane snack.

+ +

CHRIS: You got to be careful though if the icing, you know, if it's pressurized from ground level and then you get up there, and it explodes. And you gotta be careful. Or is it the reverse? It's lower pressure up in the plane. So it might explode.

+ +

STEPH: [laughs] Either way, it might explode.

+ +

CHRIS: Well, yeah. If you somehow buy a packet of icing that is sky icing that is at that pressure, and you bring it down, then...but if you take it up and down, I think it's fine. If you open it at the top, you might be in danger. If you open icing under the ocean, I think nothing's going to happen. So these are the ranges that we're playing with.

+ +

STEPH: I will be very careful sky icing and probably pack two so that way I have a backup just in case. So if one explodes, we'll be like, all right, now I know what I'm working with and be more prepared for the next one.

+ +

CHRIS: That's just smart.

+ +

STEPH: I try to make smart travel decisions, Toaster Strudels on the go. Aside from travel treats and sky icing, I have some news regarding Planet Argon, who is a Ruby on Rails consultancy regarding their latest published this year's Ruby on Rails community survey results. And so they list a lot of fabulous different topics in there. And one of them includes a learning section that highlights most listened to podcasts in the Ruby on Rails community as well as blogs and some other resources. And Bike Shed is listed as the second most listened to podcast in the Ruby on Rails community, so whoo, golf clap.

+ +

CHRIS: Fantastic.

+ +

STEPH: And in addition to that, the thoughtbot blog got a really nice shout-out. So the thoughtbot blog is in the number two spot for the most visited blogs in the community. In the first spot is Ruby Weekly, which is like, you know, okay, that feels fair, that feels good. So it's really exciting for the thoughtbot blog because a lot of people work really hard on curating and creating that content. So that's wonderful that so many people are enjoying it.

+ +

And then I should also highlight that for the podcast in first place is Remote Ruby, so congrats to Chris, Jason, and Andrew for grabbing that number one spot. And Brittany Martin, host of the Ruby on Rails Podcast, along with Brian Mariani, Jemma Issroff, and Nick Schwaderer, are in the number three spot. And some people say that Ruby is losing steam but look at all that content and all those highly ranked podcasts. I mean, we like Ruby so much we're spending time recording ourselves talking about it. So I say long live Ruby, long live Rails.

+ +

CHRIS: Yes. Long live Ruby indeed. And yeah, it's definitely an honor to be on the list and to be amongst such other wonderful shows. Certainly big fans of the work of those other podcasts. We even did a joint adventure with them at one point, and that was a really wonderful experience, so yeah, honored to be on the list alongside them. And to have folks out there in the world listening to our tech talk and nonsense always nice to hear.

+ +

STEPH: Yeah. You and I show up and say lots of silly things and technical things into the podcast. The true heroes are the ones that went and voted. So thank you to everybody who voted. That's greatly appreciated. It's really nice feedback. Because we get listener responses and questions, and those are wonderful because it lets us know that people are listening. But I have to say that having the survey results is also really nice. It lets us know people like the show.

+ +

Oh, but I did go back and look at some of the previous stats because then I was like, huh, so I'm paying attention. I looked at this year's, and I was like, I wonder what last year’s was or the year before that. And I think this survey comes out every two years because I didn't see one for 2021. But I did find the survey results for 2020, which we were in the number one spot for 2020, and Remote Ruby was in the second spot.

+ +

So I feel like now we've got a really nice, healthy podcasting war situation going on to see who can grab the first spot. We've got two years, everybody, to see who [laughs] grabs the number one spot. That's a lot of prep time for a competition.

+ +

CHRIS: Yeah, I feel like we should be like, I don't know, planning elaborate pranks on them or something like that now. Is that where this is at? It's something like that, I think.

+ +

STEPH: I think so. I think this is where you put like sky frosting inside someone's suitcase, and that's the type of prank that you play. [laughs]

+ +

CHRIS: The best of pranks.

+ +

STEPH: We'll definitely put together a little task force. And we'll start thinking of pranks that we all need to start playing on each other for the podcasting wars that we're entering for the next few years. But anywho, what's going on in your world?

+ +

CHRIS: Let's see, what's going on in my world? A fun thing happened recently. I had a chance to reflect back on some architectural choices that we've made in the Sagewell platform. And one of those specific choices is how we've approached building our native mobile apps. We made what some listeners may remember is an interesting set of choices. In particular, in Episode 328, which we'll include a link to in the show notes, I shared with you the approach that we're doing, which is basically like, Inertia is great, web user great. We like the web as a platform. What if we were to wrap it in a native shell and find this interesting and somewhat unique hybrid trade-off point?

+ +

And so, at that point, we were building it. We had most of it built out, and things were going quite well. I think we maybe had the iOS app in the store and the Android app approaching the store or something like that. At this point, both apps have been released to the store, so they are live. Production users are signing in. It's wonderful. But I had a moment in the past couple of weeks to reassess or look at that set of choices and evaluate it. And thankfully, I'm happy with the choices that we've made. So that's good.

+ +

But to get into the specifics, there were two things that happened that really, really framed the choice that we made, so one was we introduced a major new feature. We basically overhauled the first-run experience, the onboarding that users experience, and added a new, pretty fundamental facet to the platform. It's a bunch of new screens, and flows, and error states, and all of this complexity. And in the process, we iterated on it a bunch. Like, first, it looked like this, and then we changed the order of the screens and switched out the error messages, and et cetera, et cetera.

+ +

And I'll be honest, we never even thought about the mobile apps. It just wasn't even a consideration. And interestingly, we did as a final check before going fully live and releasing this out to the full production audience; we did spot check it in the mobile apps, and it didn't work. But it didn't work for a very specific, boring, technical reason that we were able to resolve. It has to do with iframes and WebViews and embedded something, something. And we had to set a flag. Thankfully, it was solvable without a deploy of the native mobile apps. And otherwise, we never thought about the native apps.

+ +

Specifically, we were able to add this fundamental set of features to our platform. And they just worked in native mobile. And they were the same as they roughly are if you're on a mobile WebView or if you're on a desktop web, you know, slightly different in terms of form factor. But the functionality was all the same. And critically, the error states and the edge cases and the flow, there's so much to think about when you're adding a nontrivial feature to an app. And the fact that we didn't have to consider it really spoke to the choice that we made here.

+ +

And again, to name it, the choice that we made is we're basically just reusing the same WebViews, the same Rails controllers, and the same what are Svelte components under the hood but the same essentially view layer as well. And we are wrapping that in a native iOS. It's a Swift application shell, and on Android, it's a Kotlin application shell. But under the hood, it's the same web stuff. And that was really great.

+ +

We just got these new features. And you know what? If we have to rip that whole set of functionality out, again, we won't need to deploy. We won't need to rethink it. Or, if we want to subtly tweak it, we can do that. If we want to think about feature flags or analytics, or error states or error reporting, all of this just naturally falls out of the approach that we took. And that was really wonderful.

+ +

STEPH: That's super nice. I also love this saga of like, you made a choice, and then you're coming back to revisit and share how it's going. So as someone who's never done this before, in regards of wrapping an application in the manner that you have and then publishing it and distributing it that way, what does that process look like? Is this one of those like you run a command, and literally, it's going to wrap the application and then make it hostable on the different mobile app stores? Or what's that? Am I oversimplifying the process? What does that look like?

+ +

CHRIS: I think there are a lot of platforms or frameworks I think would probably be the better word like Capacitor is something that comes to mind or Ionic or Expo. There are a handful of them that are a little more fully featured in what they provide. So you just point us at your React Views and whatnot, and we'll wrap that up, and it'll be great. But those are for, I may be overgeneralizing here, but my understanding is those are for more heavy client-side bundles that are talking to a common API. And so you're basically taking your same rich client-side application and bundling that up for reuse on the native app, the native app platforms.

+ +

And so I think those do have some release to the store sort of thing. In our case, we went a little bit further with that integration wrapper thing that we built. So that is a thing that we maintain. We have a Sagewell iOS repo and a Sagewell Android repo. There's a bunch of Swift and Kotlin code, respectively, in each of them, and we deploy to the stores manually. We're doing that whole process. But critically, the code that is in each of those repositories is just the bridge glue code that says, oh, when this Inertia navigation event happens, I'm going to push a WebView to the navigation stack. And that's what that is.

+ +

I'm going to render the tab bar of buttons at the bottom with the navigation elements that I get from the server. But it's very much server-driven UI, is the way that I would describe it. And it's wrapping WebViews versus actually having the whole client bundle wrapped up in the thing. It's unfortunately subtle to try and talk through on the radio, but yeah. [laughs]

+ +

STEPH: You're doing great; this is helping. So if there's a change that you want to make, you go to the Rails application, and you make that change. And then do you need to update anything on that iOS repo? It sounds like you don't, which then you don't have to push a new update to the store.

+ +

CHRIS: Correct. For the vast majority of things, we do not need to make any changes. It's very rare for us to deploy the iOS or the Android app is a different way to put it or to push new releases to the store. It happens we may want to add a new feature to the sort of bridge layer that we built, but increasingly, those are rare. And now it's basically like, yeah, we're just wrapping those WebViews, and it's going great. And again, to name it, it's a trade-off. It's an intentional trade-off that we've made.

+ +

We're never going to have the richest, most deep platform integration, smooth experience. We are making a small trade-off on that front. But given where we're at as an organization, given how early we are, how much iteration and change, we chose an architecture that optimizes for that change. And so again, like what you just said, yeah, I can...you know how it's really nice to be able to deploy six times a day on a web app, and that's a very straightforward thing to do? It is not so straightforward in the native mobile world. And so, we now have afforded ourselves the ability to do that.

+ +

But critically, and this is the fun part in my mind, have the trade-offs in the controls. So if we were just like, it's just a WebView, and that's it, and we put it in the stores, and we're done, that is too far of an extreme in my mind. I think the performance trade-offs, the experience trade-offs, it wouldn't feel like a native app like in a deep way, in a problematic way. And so as an example, we have a navigation bar at the top of our app, particularly on iOS, that is native iOS navigation. And we have a tab bar at the bottom, which is native tab UI element. I forget actually what it's called, but it's those elements.

+ +

And we hide the web application navigation when we're in the mobile context. So we actually swap those out and say, like, let's actually promote these to formal native functionality. We also, within our UI on the web, have a persistent button in the top right corner of your screen that says, "Need help? Reach out to your retirement advocate." who is the person that you get to work with. You can send questions, et cetera, et cetera. It's this little help sidebar drawer thing that pops out. And we have that as a persistent HTML button in the top corner of the web frame.

+ +

But when we're on native, we push that up as a distinct element in the native UI section. And then again, the bridge that I'm talking about allows for bi-directional communication between the JavaScript side and the native side or the native side and the JavaScript side. And so it's those sorts of pieces that have now afforded us all of the freedom to tinker, and we don't need to re-release where we're like, oh, we want to add a new weird button that does a thing in the WebView when you click on a button outside the WebView. We now just have that built-in.

+ +

STEPH: Yeah, I really like the flexibility that you're describing. When you promoted those elements to be more native-friendly so, like the navigation or the footer or the little get help chat, is that something that then your team implemented in like the iOS or the Kotlin repo? Okay, I see you nodding, but other people can't see that, so...[laughs]

+ +

CHRIS: Yeah. I was going to also say the words, but yes, those are now implemented as native parts. So the thing that we built isn't purely agnostic decoupled. It is Sagewell-specific; a lot of it is low-level. Like, let's say we want to wrap an Inertia app in a native mobile wrapper. Like, 90% of the code in it is that, but then there are little bits that are like, and put a button up there. And that button is the Sagewell button. And so it's not entirely decoupled from us. But it mostly is this agnostic bridge to connect things together.

+ +

STEPH: Yeah, the way you're describing it sounds really nice in terms of you're able to get out the app quickly and have a mobile app quickly that works on both platforms, and then you're still able to deploy changes without having to push that. That was always my biggest mental, or emotional hurdle with the idea of mobile development was the concept of that you really had to batch everything together and then submit it for review and approval and then get it released.

+ +

And then you got to hope people then upgrade and get the newest version. And it just felt like such a process, not that I ever did much of it. This was all just even watching like the mobile team and all the work that they had to do. And I had sympathy pains for them. But the fact that this approach allows you to avoid a lot of that but still have some nice, customized, more native elements. Yeah, I'm basically just recapping everything you said because I like all of it.

+ +

CHRIS: Well, thank you, friend. Like I said, I've really enjoyed it, and similar to you, I'm addicted to the feedback loop of the web. It's beautiful. I can deploy ten times or however many I want. Anytime I want, I can push out a new version. And that ability to iterate, to test, to explore, to tweak, to not have to do as much formal testing upfront because I'm terrified that if a bug sneaks out, then, it'll take me two weeks to address it; it just is so, so freeing. And so to give that up moving into a native context.

+ +

Perhaps I'm fighting too hard to hold on to my dream of the ability to rapidly iterate. But I really do believe in that and especially for where we're at as an organization right now. But, and a critical but here, again, it's a trade-off like anything else. And recently, I happened to be out about in the town, and I decided, oh, you know what? Let me open up the app. Let me see what it's like. And I wasn't on great internet. And so I open the app, and it loads because, you know, it's a native app, so it pops up.

+ +

But then the thing that actually happened is a loading spinner in the middle of the screen and sort of a gray nothing for a little while until the server request to fetch the necessary UI elements to render the login screen appeared. And that experience was not great. In particular, that experience is core to the experience of using the app every single time. Every time you use it, you're going to have a bad time because we're re-downloading that UI element. And there's caching, and there's things that could happen there to help with that. But fundamentally, that experience is going to be a pretty common one. It's the first thing that you experience when you're opening the app.

+ +

And so I noticed that and I chatted with the team, and I was like, hey, I feel like this is actually something that fixing this I think would really fundamentally move us along that spectrum of like, we've definitely made some trade-offs here. But overall, it feels snappy and like a native app. And so, we opted to prioritize work on a native login screen for both platforms. This also allows us to more deeply integrate. So particularly, we're going to get biometric logins like fingerprints or face scans, or whatever it is.

+ +

But critically, it's that experience of like, I open the Sagewell native app on my iOS phone, and then it loads immediately. And then I show it my face like we do these days, and then it opens up and shows me everything that I want to see inside of it. And it's that first-run experience that feels worth the extra effort and the constraints. Because now that it's native mobile, that means in order to change it, we have to do a deploy, not a deploy, release; that's what they call it in the native world. [laughs] You can tell I'm well-versed in this ecosystem.

+ +

But yeah, we're now choosing that trade-off. And what I really liked about this sort of set of things like the feature that we were able to just accidentally get for free on native because that's how this thing is built. And then likewise, the choice to opt into a fully native login screen like having that lever, having that control over I'm going to optimize for iteration generally, but where it's important, we want to optimize for performance and experience. And now we have this little slider that we can go back and forth.

+ +

And frankly, we could choose to screen by screen just slowly replace everything in the app with true native WebViews backed by APIs. And we could Ship of Theseus style replace every element of the app with true native mobile things until none of the old bridge code exists. And our users, in theory, would never know. Having that flexibility is really nice given the trade-off and the choice that we've made.

+ +

STEPH: You said a word there that I missed. You said ship something style.

+ +

CHRIS: Ship of Theseus.

+ +

STEPH: What is that?

+ +

CHRIS: It's like an old biblical story, I want to say, but it's basically the idea of, like, you have the ship. And then some boards start to rot out, so replace those boards. And then the mast breaks, you replace the mast. And slowly, you've replaced every element on the ship. Is it still the same ship at that point? And so it's sort of a philosophical question. So if we replace every single view in this app with a native view, is it still the same map? Philosophers will philosophize about it forever, but whatever. As long as we get to keep iterating and shipping software, then I'm happy.

+ +

STEPH: [laughs] Y’all philosophize. That's that word, right?

+ +

CHRIS: Yeah.

+ +

STEPH: And do your philosopher thing. We'll just keep building and shipping.

+ +

CHRIS: I don't know if I pronounced it right. It's like either Theseus or Theseus, and I'm sure I said the wrong one. And now that I've said the other, I'm sure both of them are wrong somehow. It's like a USB where there's up and down, and yet somehow it takes three tries. So anyway, I may have mispronounced it, and I may be misattributing it, but that's the idea I was going for.

+ +

STEPH: Well, given I wasn't even familiar with the word until just now, I'm going to give both pronunciations a thumbs up. I also really like how you decided that for the login screen, that's the area that you don't want people to wait because I agree if you're opening an application or opening...maybe it's the first time, maybe it's the 100th time. Who knows? But that feels important. Like, that needs to be snappy. I need to know it's responsive. And it builds trust from the minute that I clicked on that application. And if it takes a long time, I just immediately I'm like, what are y'all doing? Are y'all real? Do you know what you're doing over there?

+ +

So I like how you focused on that experience. But then once I log in, like if something is slow to log me in, I will make up excuses for the application all day where I'm like, well, you know, maybe it's my connection. It's fine. I can wait for the next screen to load. That feels more reasonable. And it doesn't undermine my trust nearly as much as when I first click on the app. So that feels like a really nice trade-off as well, or at least a nice area that you've improved while still having those other trade-offs and benefits that you mentioned.

+ +

CHRIS: To highlight it, you used a phrase there which I really liked. Like, it's building trust. If something's a little bit off in that first run experience every single time, then it kind of puts a question in the back of your head, maybe not even consciously. But you're just kind of looking at it, and you're like, what are you doing there? What are you up to, friend? Humans say to the apps they use on their phone. That's normal, right? When you talk...

+ +

But to name it, we've also done a round of performance work throughout the app. And so there are a couple of layers to it. But it was work that we had planned for a while, but we kept deferring. But now that we're seeing more usage of the native apps, the native apps experience the same surface area of performance stuff but all the more so because they may be on degraded network connections, et cetera.

+ +

And so this is another example where this whole thing kind of pays off. The performance work that we did affects everything. It affects the web. It's the same under the hood. It's let's reduce the network requests that we're making in the payloads that we're sending, particularly the network requests to upstream things, so like the banking partner that we're using and those APIs, like, collating all the data to then render the screen.

+ +

Because of Inertia, we only have a single sort of back and forth conversation via the API as opposed to I think it's pretty common to have like seven different APIs and four different spinners on the screen. We're not doing that, none of that on my watch. [chuckles] But we minimize the background calls to the other parties that we're integrating with. And then, we reduce the payload of data that we're sending on each request.

+ +

And each of those were like, we had to think about things and tweak and poke, but again it's uniform. So mobile web has that now, desktop web has that now. Android, iOS, they all just inherited it sort of that just happened one day without a deploy or release, without a release of either of the native mobile apps. We did deploy to the web to make that happen, but that's easy. I can do that a bunch of times a day.

+ +

One last thing I want to share as we're on this topic of trade-offs and levers, there was a really great conference talk that I watched recently, which was Ryan Florence of remix.run also React Router fame if you're familiar with him from that. But he was talking about the most recent version of Remix, which is their meta framework on top of React.

+ +

But they've done some really interesting stuff around processing data, fetching data, when and how to sequence that. And again, that thing that I talked about of nine different loading spinners on the screen, Remix is taking a very different approach but is targeting that same thing of like, that's not great for user experience. Cumulative layout shift being the actual number that you can monitor for this.

+ +

But in that talk, there are features that they've added to Remix as a framework where you can just decide, like, do we wait for this or do we not? Do we make sure we have all of the data, or do we say, you know what? Actually, this is going to be below the fold. So it's okay to defer loading this until after we send down the first payload. And then we'll kick in, and we'll do it from the client-side. But it's this wonderful feature of the framework that they're adding in where there's basically just a keyword that you can add to sort of toggle that behavior.

+ +

And again, it's this idea of like trade-offs. Are we okay with more layout shift, or are we okay with more waiting? Which is it that we're going to optimize for? And I really love that idea of putting that power very simply in the hands of the developers to make those trade-off decisions and optimize over time for what's important. So we'll share a link to that talk in the show notes as well.

+ +

But it was very much in the same space of like, how do I have the power to decide and to change my mind over time? That's what I want. But yeah, with that, I think that's enough of me updating on the mobile app. I'll continue to share as new things happen. But again, I'm at this point very happy with where we're at. So yeah, it's been fun. But yeah, what else is up in your world?

+ +

STEPH: I have a dear Gerrit message that I wrote earlier, so I want to share that with you. Gerrit is the system that we're using for when we push up code changes that then manages very similar in the competitive space of like GitHub and GitLab, and Bitbucket. And so the team that I'm working with we are using Gerrit. And Gerrit and I, you know, we get along for the most part. We've managed to have a working relationship. [chuckles] But this week, I wrote my dear Gerrit letter is that I really miss being able to tell a story with my commit messages. That is the biggest pain that I'm feeling right now.

+ +

So for anyone that's less familiar or if you already are familiar with Gerrit, each change that Gerrit shows represents a single commit that's under review. And each change is identified by a Change-Id. So the basic concept of Gerrit is that you only have one commit per review. So if you were to translate that to GitHub terminology, every pull request is only going to have one commit, and so you really can't push up multiple.

+ +

And so, where that has been causing me the most pain is I miss being able to tell a story. So like even simple stories that are like, hey, I removed something that's not used. I love separating that type of stuff into its own commit just so then people can see that as they're going through review. Now, before I merge, I'm likely to squash, and that doesn't feel important that it needs to be its own commit. That's really just for the reviewer so they can follow along for the changes.

+ +

But the other one, I can slowly get over that one. Because essentially, the way I get around that is then when I do push up my code for review, is I then go through my change request, and then I just add comments. So I will highlight that line and say, "Hey, I'm removing this because it's not in use." And so, I found a workaround for that one.

+ +

But the one I haven't found a workaround for is that I don't push up my local work very often because I love having lots of local, tiny, green commits so that way I can know the progress that I'm at. I know where I'm headed. Also, I have a safe space to roll back to, but then that means that I may have five or six commits that I have locally, but I haven't pushed up somewhere. And that is bothering me more and more hour by hour the more I think about it that I can't push stuff up because it makes me nervous.

+ +

Because, I mean, usually, at least by the end of the day, I push everything up, so it's stored somewhere. And I don't have to worry about that work disappearing. Now I am working on a dev machine. So there is that aspect of it's technically...it's not even on my local machine. It is stored somewhere that I should still be able to access.

+ +

CHRIS: What's a dev machine? The way you're saying it, it sounds like it's a virtual machine, not like a laptop. But what's a dev machine?

+ +

STEPH: Good question. So the dev machine is a remote server or remote machine that then I am accessing, and then that's where I'm performing. That's where I'm writing all of my work. And then that's also kind of the benefit is everything is not local; it's controlled by the team. So then that also means that other teams, other individuals can help set up these environments for future developers.

+ +

So then you have that consistency across everyone's working with the same Rails version, or gems, or has access to the same tools. So in that sense, my work isn't just on my laptop because then that would really worry me because then I've got nowhere...it's not backed up anywhere. So at least it is somewhere it's being stored that then could be accessed by someone.

+ +

So actually, now, as I'm talking this through, that does help alleviate my concern about this a bit. [laughs] But I still miss it; I still miss being able to just push up my work and then have multiple commits. And I looked into it because I was like, well, maybe I'm misunderstanding something about Gerrit, and there's a way around this. And that's still always a chance. But from the research that I've done, it doesn't seem to be. And there are actually two very fiery takes that I saw that I have to share because they made me laugh.

+ +

When I was Googling, the question of like, "Can I push up multiple commits to one single Gerrit CR? Or is there just a way to, like, can I have this concept of like a branch and then I have many commits, but then I turn it into one CR? Whatever the world would give me. What do they have? [laughs] I'm laughing just looking at this now. One of the responses was, have you tried squashing your commits into one commit? And I was like, [laughs] "Yeah, that's not what I had in mind, but sure."

+ +

And then the other one, this is the more fiery take. They were very defensive about Gerrit, and they wrote that "People who don't like Gerrit usually just hack shit together. They cut corners and love squashing commits or throwing away history. And those people hate Gerrit. Developers who care love it. It's definitely possible and easy to produce agile software." And I just...that made me laugh. I was like, cool, I'm a developer that cuts corners and loves squashing commits. [laughs]

+ +

CHRIS: So you don't care is what that take says.

+ +

STEPH: I'm a developer who does not care.

+ +

CHRIS: You know, Steph, I've worked with you for a while. And I've been looking for the opportunity to have this hard conversation with you. But I just wish you cared a little more about the software that you're writing, about the people that you're working with, about the commits that you're authoring. I just see it in every facet of your work. You just don't care. To be very clear for anyone listening at home, that is the deepest of sarcasm that I can make. Steph cares so very much. It's one of the things that I really enjoy about you.

+ +

STEPH: I mean, we had the episode about toxic traits. This would have been the perfect time to confront me about my lack of caring about software and the processes that we have. So winding down on that saga, it seems to be the answer is no, friend; I cannot push up multiple commits. Oh, I tried to hack it. I am someone that tries to hack shit together because I tried to get around it just to see what would happen. [laughs] Because the docs had suggested that each change is identified by a Change-Id. And I was like, hmm, so what if there were two commits that had the same Change-Id, would Gerrit treat those as patch sets?

+ +

Because right now, when you push up a change, you can see all the different patch sets, so that's nice. So that's a nice feature of Gerrit as you can see the history of, like, someone pushed up this change. They took in some feedback. They pushed up a new change. And so that history is there for each push that someone has provided. And I wondered maybe if they had the same Change-Id that then the patch sets would show the first commit and then the second commit. And so I manually altered the commits two of them to reference the same Change-Id.

+ +

And I have to say, Gerrit was on to me because they gave me a very nice error message that said, "Same Change-Id and multiple changes. Squash the commits with the same Change-Ids or ensure Change-Ids are unique for each commit. And I thought, dang, Gerrit, you saw me coming. [laughs] So that didn't work either. I'm still in a world of where I now wait. I wait until I'm ready for someone to review stuff, and I have to squash everything, and then I go comment on my CRs to help out reviewers.

+ +

CHRIS: I really like the emotional backdrop that you provided here where you're spending a minute; you're like, you know what? Maybe it's me. And there's the classic Seymour Skinner principle from The Simpsons. Am I out of touch? No, it's the children who are wrong. [laughs] And I liked that you took us on a whole tour of that. You're like, maybe it's me. I’ll maybe read up. Nope, nope. So yeah, that's rough.

+ +

There's a really interesting thing of tools constraining you. And then sometimes being like, I'm just going to yield control and back away and accept this thing that doesn't feel right to me. Like, Prettier does a bunch of stuff that I really don't like. It shapes code in a way, and I'm just like, no, that's not...nope, you know what? I've chosen to never care about this again. And there's so much utility in that choice. And so I've had that work out really well. Like with Prettier, that's a great example whereby yielding control over to this tool and just saying, you know what? Whatever you produce, that is our format; I don't care. And we're not going to talk about it, and that's that.

+ +

That's been really useful for myself and for the teams that I'm on to just all kind of adopt that mindset and be like, yeah, no, it may not be what I would choose but whatever. And then we have nice formatted code; it's great. It happens automatically, love it. But then there are those times where I'm like; I tried to do that because I've had success with that mindset of being like, I know my natural thing is to try and micromanage and control every little bit of this code.

+ +

But remember that time where it worked out really well for me to be like, I don't care, I'm just going to not care about this thing? And I try to not care about some stuff, which it sounds like that's what you're doing right here. [laughs] And you're like, I tried to not care, but I care. I care so much. And now you're in that [chuckles] complicated space. So I feel for you, Steph. I'm sorry you're in that complicated space of caring so much and not being able to turn that off [laughs] nor configure the software to do the thing you want.

+ +

STEPH: I appreciate it. I should also share that the team that I'm working with they also don't love this. Like, they don't love Gerrit. So when I shared in the Slack channel my dear Gerrit message, they're both like, "Yeah, we feel you. [laughs] Like, we're in the same spot," which was also helpful because I just wanted to validate like, this is the pain I'm feeling. Is someone else doing something clever or different that I just don't know about? And so that was very helpful for them to say, "Nope, we feel you. We're in the same spot. And this is just the state that we're in."

+ +

I think they have started transitioning some other repos over to GitLab and have several repos in Gitlab, but this one is still currently using Gerrit. So they very much commiserate with some of the things that I'm feeling and understand. And this does feel like one of those areas where I do care deeply.

+ +

And frankly, this is one of those spaces that I do care about, but it's also like, I can work around it. There are some reasonable things that I can do, and it's fine as we just talked through. Like, the fact that my commits are not just locally on my machine already makes me feel better now that I've really processed that. So there are lower risks. It is more of just like a workflow. It's just, you know, it's crushing my work vibe.

+ +

CHRIS: Harshing your buzz.

+ +

STEPH: In the great words of Queen Elsa, I gotta let it go. This is the thing I'm letting go. So that's kind of what's going on in my world. What else is going on in your world?

+ +

CHRIS: Well, first and foremost, fantastic reference and segue. I really liked that. But yeah, let's see, [laughs] what else is going on in my world? We had an interesting thing happen last week. So we had an outage on the platform last week. And then we had an incident review today, so a formal sort of post-mortem incident review. There are a couple of different names that folks have given to these. But this is a practice that we want to build within our engineering culture is when stuff goes wrong, we want to make sure that we have meaningful conversations around to try to address the root causes.

+ +

Ideally, blameless is a word that gets used often in this context. And I've heard folks sort of take either side of that. Like, it's critical that it's blameless so that it doesn't feel like it's an attack. But also, like, I don't know, if one person did something, we should say that. So finding that gentle middle ground of having honest, real conversations but in a context of safety. Like, we're all going to make mistakes. We're all going to ship bugs; let's be clear about that. And so it's okay to sort of...anyway, that's about the process.

+ +

We had an outage. The specific outage was that we have introduced a new process. This is a Sidekiq process to work off a specific queue. So we wanted that to have discrete treatment. That had been running, and then it stopped running; we still don't know why. So we never got to the root-root cause. Well, we know what the mechanism was, which was the dyno count for that process was at zero. And so, eventually, we found a bunch of jobs backed up in the Sidekiq admin. We're like, that's weird.

+ +

And then, we went over to Heroku's configuration dashboard. And we saw, huh, that's weird. There are zero dynos processing this. That wasn't true yesterday. But unfortunately, Heroku doesn't log or have an audit trail around changes to those process counts. It's just not available. So that's unfortunate. And then the actual question of like, how did this happen? It probably had to be someone on the team. So there is like, someone did a thing. But that is almost immaterial because, again, people are going to do things, bugs will get shipped, et cetera.

+ +

So the conversation very quickly turned to observability and understanding. I think we've done a pretty good job of instrumenting error reporting and being quite responsive to that, making sure the signal-to-noise ratio is very actionable. So if we see a bug or a Sentry alert come through, we're able to triage that pretty quickly, act on it where it is a real bug, understand where it's a bit of noise in the system, that sort of thing. But in this case, there were no errors. There was no Sentry. There was nothing; there was the absence of something.

+ +

And so it was this really interesting case of that's where observability, I think, can really come in and help. So the idea of what can we do here? Well, we can monitor the count of jobs backed up in Sidekiq queue. That's one option. We could do some threshold alerting around the throughput of processed events coming from this other backend. There are a bunch of different ways, but it basically pushed us in the direction of doubling down and reinforcing the foundation of our observability within the platform.

+So we're just kicking that mini-project off now, but it is something we're like, yeah, we feel like we could add some here. In particular, we recently added Datadog to the stack. So we now have Datadog to aggregate our logs and ideally do some metric analysis, those sort of things, build some dashboards, et cetera. I haven't explored Datadog much thus far. But my sense is they've got the whiz-bang things that we need here. But yeah, it was an interesting outage. That wasn't fun. The incident conversation was actually a good conversation as a team. And then the outcome of like, how do we double down on observability? I'm actually quite excited for.

+ +

STEPH: This is a fun moment for me because I have either joined teams that didn't have Datadog or have any of that sort of observability built into their system or that sort of dashboard that people go to. Or I've joined teams, and they already have it, and then nobody or people rarely look at it. And so I'm always intrigued between like what's that catalyst that then sparked a team to then go ahead and add this? And so I'm excited to hear you're in that moment of like, we need more observability. How do we go about this?

+ +

And as soon as you said Datadog, I was like, yeah, that sounds nice because then it sounds like a place that you can check on to make sure that everything is still running. But then there's still also that manual process where I'm presuming unless there's something else you have in mind. There's still that manual process of someone has to check the dashboard; someone then has to understand if there's no count, no squiggly lines, that's a bad thing and to raise a concern.

+ +

So I'm intrigued with my own initial reaction of, like, yeah, that sounds great. But now I'm also thinking about it still adds a lot of...the responsibility is still on a human to think of this thing and to go check it. Versus if there's something that gets sent to someone to alert you and say like, "Hey, this queue hasn't been processed in 48 hours. There may be a concern that actually feels nicer." It feels safer.

+ +

CHRIS: Oh yeah, definitely. I think observability is this category of tools and workflows and whatnot. But I think what you're describing of proactive alerting that's the ideal. And so it would be wonderful if I never had to look at any of these tools ever. And I just knew if I got, let's say, it's PagerDuty connected up whatever, and I got a push notification from PagerDuty saying, "Hey, go look at this thing." That's all I ever need to think about. It’s like, well, I haven't gotten a PagerDuty in a while, so everything must be fine, and having a deep trust in that.

+ +

Similar to like, if we have a great test suite and it's green, I feel confident deploying the sort of absence of an alert being the thing that I can trust. But right now, we're early enough in this journey that I think what we need to do is stand up a bunch of these different graphs and charts and metric analysis and aggregations and whatnot, and then start to squint at it for a while and be like, which of these would I be really concerned if it started to wibble?

+ +

And then you can figure the alerting around said wibble rate. And that's the dream. That's where we want to get to, but I think we've got to crawl, walk, run on this. So it'll be an adventure. This is very much the like; we're starting a thing. I'll tell you about it more when we've done it. But what you're describing is exactly what we want to get to.

+ +

STEPH: I love wibble rate. That's my new measurement I'm going to start using for everything. It's funny, as you're bringing this up, it's making me think about the past week that Joël Quenneville and I have had with our client work. Because a somewhat similar situation came up in regards where something happened, and something was broken. And it seemed it was hard to define exactly what moment caused that to break and what was going on.

+ +

But it had a big impact on the team because it essentially meant none of the bills were going through. And so that's a big situation when you got 100-plus people that are pushing up code and expecting some of the build processes to run. But it was one of those that the more we dug into it, the more it seemed very rare that it would happen.

+ +

So, in this case, as a sort of a juxtaposition to your scenario, we actually took the opposite approach of where we're like; this is rare. But we did load up a lot of contexts. Actually, I was thinking back to the advice that you gave me in a previous episode where I was talking about at what point do you dig in versus try to stay at surface level? And this was one of those, like, we've spent a couple of days on getting context for this and understanding. So it felt really important and worthwhile to then invest a little bit more time to then document it.

+ +

But then we still went with the simplest approach of like, this is weird. It shouldn't happen again. We think we understand it but then let's add a little bit of documentation or wiki page around like, hey, if you do run into this, here are some steps that will fix everything. And then, if you need to use this, let somebody know because this is so odd it shouldn't happen. So we took that approach in this case where we didn't increase the observability. It was more like we provided a fire extinguisher very close to the location in case it happens. And so that way, it's there should the need arise, but we're hoping it just never gets used.

+ +

We're also in the process of changing how a lot of that logic works. So we didn't really want to optimize for observability into a system that is actively being changed because it should look very different in upcoming months. But overall, I love the conversations that you bring about observability, and I'm excited to hear about what wibble rates you decide to add to your Datadog dashboard.

+ +

CHRIS: There's a delicate art and science to the selection of the wibble rates. So I will certainly report back as we get into that work. But with that, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Another toaster strudel debate?! Plus, the results are in for the most listened-to podcast in the RoR community! :: drum roll ::

+ +

Steph has a "Dear Gerrit" message to share. Chris has a follow-up on mobile app strategy.

+ +
+ +

The Bike Shed: 328: Terrible Simplicity
+When To Fetch: Remixing React Router - Ryan Florence
+Virtual Event - Save Time & Money with Discovery Sprints

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: thoughtbot's next virtual event "Save Time & Money with Discovery Sprints" is coming up on June 17th, from 2 - 3 PM Eastern. It's a discussion with team members from product management, design and development. From a developer perspective, topics will include how to plan a product's architecture, both the MVP and future version, how to lead a tech spikes into integrations and conduct a build vs buy reviews of third party providers. Head to thoughtbot.com/events to register, the event is June 17th 2 - 3 PM ET. Even if you can't make it, registering will get you on the list for the recording.

+ +

CHRIS: We're the second-best. We're the second-best. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: I'm very happy to report that I picked up a treat from the store recently. So while I was in Boston and we were hanging out in person, we talked about Pop-Tarts because that always comes up as a debate, as it should. And then also Toaster Strudels came up, so I now have a package of Toaster Strudels, and those are legit. Pop-Tart or Toaster Strudel, I am team Toaster Strudel, which I know you're going to ask me about icing and if I put it on there, so go ahead. I'm going to pause. [laughs]

+ +

CHRIS: It sounds like I don't even need to say anything. But yes, inquiring minds want to know.

+ +

STEPH: I think that's also my very defensive response because yes, I put icing on my Toaster Strudel.

+ +

CHRIS: How interesting. [laughs]

+ +

STEPH: But it feels like a whole different class of pastry. So I'm very defensive about my stance on Pop-Tarts with no icing put Strudel with icing.

+ +

CHRIS: A whole different class of pastry. Got it. Noted. Understood. So did you travel? Like, were these in your luggage that you flew back with?

+ +

STEPH: [laughs] Oh no. They would be all gooey and melty. No, we bought them when we got back to North Carolina. Oh, that'd be a pro move; just pack little individual Strudels as your airplane snack. Ooh, I might start doing that now. That sounds like a great airplane snack.

+ +

CHRIS: You got to be careful though if the icing, you know, if it's pressurized from ground level and then you get up there, and it explodes. And you gotta be careful. Or is it the reverse? It's lower pressure up in the plane. So it might explode.

+ +

STEPH: [laughs] Either way, it might explode.

+ +

CHRIS: Well, yeah. If you somehow buy a packet of icing that is sky icing that is at that pressure, and you bring it down, then...but if you take it up and down, I think it's fine. If you open it at the top, you might be in danger. If you open icing under the ocean, I think nothing's going to happen. So these are the ranges that we're playing with.

+ +

STEPH: I will be very careful sky icing and probably pack two so that way I have a backup just in case. So if one explodes, we'll be like, all right, now I know what I'm working with and be more prepared for the next one.

+ +

CHRIS: That's just smart.

+ +

STEPH: I try to make smart travel decisions, Toaster Strudels on the go. Aside from travel treats and sky icing, I have some news regarding Planet Argon, who is a Ruby on Rails consultancy regarding their latest published this year's Ruby on Rails community survey results. And so they list a lot of fabulous different topics in there. And one of them includes a learning section that highlights most listened to podcasts in the Ruby on Rails community as well as blogs and some other resources. And Bike Shed is listed as the second most listened to podcast in the Ruby on Rails community, so whoo, golf clap.

+ +

CHRIS: Fantastic.

+ +

STEPH: And in addition to that, the thoughtbot blog got a really nice shout-out. So the thoughtbot blog is in the number two spot for the most visited blogs in the community. In the first spot is Ruby Weekly, which is like, you know, okay, that feels fair, that feels good. So it's really exciting for the thoughtbot blog because a lot of people work really hard on curating and creating that content. So that's wonderful that so many people are enjoying it.

+ +

And then I should also highlight that for the podcast in first place is Remote Ruby, so congrats to Chris, Jason, and Andrew for grabbing that number one spot. And Brittany Martin, host of the Ruby on Rails Podcast, along with Brian Mariani, Jemma Issroff, and Nick Schwaderer, are in the number three spot. And some people say that Ruby is losing steam but look at all that content and all those highly ranked podcasts. I mean, we like Ruby so much we're spending time recording ourselves talking about it. So I say long live Ruby, long live Rails.

+ +

CHRIS: Yes. Long live Ruby indeed. And yeah, it's definitely an honor to be on the list and to be amongst such other wonderful shows. Certainly big fans of the work of those other podcasts. We even did a joint adventure with them at one point, and that was a really wonderful experience, so yeah, honored to be on the list alongside them. And to have folks out there in the world listening to our tech talk and nonsense always nice to hear.

+ +

STEPH: Yeah. You and I show up and say lots of silly things and technical things into the podcast. The true heroes are the ones that went and voted. So thank you to everybody who voted. That's greatly appreciated. It's really nice feedback. Because we get listener responses and questions, and those are wonderful because it lets us know that people are listening. But I have to say that having the survey results is also really nice. It lets us know people like the show.

+ +

Oh, but I did go back and look at some of the previous stats because then I was like, huh, so I'm paying attention. I looked at this year's, and I was like, I wonder what last year’s was or the year before that. And I think this survey comes out every two years because I didn't see one for 2021. But I did find the survey results for 2020, which we were in the number one spot for 2020, and Remote Ruby was in the second spot.

+ +

So I feel like now we've got a really nice, healthy podcasting war situation going on to see who can grab the first spot. We've got two years, everybody, to see who [laughs] grabs the number one spot. That's a lot of prep time for a competition.

+ +

CHRIS: Yeah, I feel like we should be like, I don't know, planning elaborate pranks on them or something like that now. Is that where this is at? It's something like that, I think.

+ +

STEPH: I think so. I think this is where you put like sky frosting inside someone's suitcase, and that's the type of prank that you play. [laughs]

+ +

CHRIS: The best of pranks.

+ +

STEPH: We'll definitely put together a little task force. And we'll start thinking of pranks that we all need to start playing on each other for the podcasting wars that we're entering for the next few years. But anywho, what's going on in your world?

+ +

CHRIS: Let's see, what's going on in my world? A fun thing happened recently. I had a chance to reflect back on some architectural choices that we've made in the Sagewell platform. And one of those specific choices is how we've approached building our native mobile apps. We made what some listeners may remember is an interesting set of choices. In particular, in Episode 328, which we'll include a link to in the show notes, I shared with you the approach that we're doing, which is basically like, Inertia is great, web user great. We like the web as a platform. What if we were to wrap it in a native shell and find this interesting and somewhat unique hybrid trade-off point?

+ +

And so, at that point, we were building it. We had most of it built out, and things were going quite well. I think we maybe had the iOS app in the store and the Android app approaching the store or something like that. At this point, both apps have been released to the store, so they are live. Production users are signing in. It's wonderful. But I had a moment in the past couple of weeks to reassess or look at that set of choices and evaluate it. And thankfully, I'm happy with the choices that we've made. So that's good.

+ +

But to get into the specifics, there were two things that happened that really, really framed the choice that we made, so one was we introduced a major new feature. We basically overhauled the first-run experience, the onboarding that users experience, and added a new, pretty fundamental facet to the platform. It's a bunch of new screens, and flows, and error states, and all of this complexity. And in the process, we iterated on it a bunch. Like, first, it looked like this, and then we changed the order of the screens and switched out the error messages, and et cetera, et cetera.

+ +

And I'll be honest, we never even thought about the mobile apps. It just wasn't even a consideration. And interestingly, we did as a final check before going fully live and releasing this out to the full production audience; we did spot check it in the mobile apps, and it didn't work. But it didn't work for a very specific, boring, technical reason that we were able to resolve. It has to do with iframes and WebViews and embedded something, something. And we had to set a flag. Thankfully, it was solvable without a deploy of the native mobile apps. And otherwise, we never thought about the native apps.

+ +

Specifically, we were able to add this fundamental set of features to our platform. And they just worked in native mobile. And they were the same as they roughly are if you're on a mobile WebView or if you're on a desktop web, you know, slightly different in terms of form factor. But the functionality was all the same. And critically, the error states and the edge cases and the flow, there's so much to think about when you're adding a nontrivial feature to an app. And the fact that we didn't have to consider it really spoke to the choice that we made here.

+ +

And again, to name it, the choice that we made is we're basically just reusing the same WebViews, the same Rails controllers, and the same what are Svelte components under the hood but the same essentially view layer as well. And we are wrapping that in a native iOS. It's a Swift application shell, and on Android, it's a Kotlin application shell. But under the hood, it's the same web stuff. And that was really great.

+ +

We just got these new features. And you know what? If we have to rip that whole set of functionality out, again, we won't need to deploy. We won't need to rethink it. Or, if we want to subtly tweak it, we can do that. If we want to think about feature flags or analytics, or error states or error reporting, all of this just naturally falls out of the approach that we took. And that was really wonderful.

+ +

STEPH: That's super nice. I also love this saga of like, you made a choice, and then you're coming back to revisit and share how it's going. So as someone who's never done this before, in regards of wrapping an application in the manner that you have and then publishing it and distributing it that way, what does that process look like? Is this one of those like you run a command, and literally, it's going to wrap the application and then make it hostable on the different mobile app stores? Or what's that? Am I oversimplifying the process? What does that look like?

+ +

CHRIS: I think there are a lot of platforms or frameworks I think would probably be the better word like Capacitor is something that comes to mind or Ionic or Expo. There are a handful of them that are a little more fully featured in what they provide. So you just point us at your React Views and whatnot, and we'll wrap that up, and it'll be great. But those are for, I may be overgeneralizing here, but my understanding is those are for more heavy client-side bundles that are talking to a common API. And so you're basically taking your same rich client-side application and bundling that up for reuse on the native app, the native app platforms.

+ +

And so I think those do have some release to the store sort of thing. In our case, we went a little bit further with that integration wrapper thing that we built. So that is a thing that we maintain. We have a Sagewell iOS repo and a Sagewell Android repo. There's a bunch of Swift and Kotlin code, respectively, in each of them, and we deploy to the stores manually. We're doing that whole process. But critically, the code that is in each of those repositories is just the bridge glue code that says, oh, when this Inertia navigation event happens, I'm going to push a WebView to the navigation stack. And that's what that is.

+ +

I'm going to render the tab bar of buttons at the bottom with the navigation elements that I get from the server. But it's very much server-driven UI, is the way that I would describe it. And it's wrapping WebViews versus actually having the whole client bundle wrapped up in the thing. It's unfortunately subtle to try and talk through on the radio, but yeah. [laughs]

+ +

STEPH: You're doing great; this is helping. So if there's a change that you want to make, you go to the Rails application, and you make that change. And then do you need to update anything on that iOS repo? It sounds like you don't, which then you don't have to push a new update to the store.

+ +

CHRIS: Correct. For the vast majority of things, we do not need to make any changes. It's very rare for us to deploy the iOS or the Android app is a different way to put it or to push new releases to the store. It happens we may want to add a new feature to the sort of bridge layer that we built, but increasingly, those are rare. And now it's basically like, yeah, we're just wrapping those WebViews, and it's going great. And again, to name it, it's a trade-off. It's an intentional trade-off that we've made.

+ +

We're never going to have the richest, most deep platform integration, smooth experience. We are making a small trade-off on that front. But given where we're at as an organization, given how early we are, how much iteration and change, we chose an architecture that optimizes for that change. And so again, like what you just said, yeah, I can...you know how it's really nice to be able to deploy six times a day on a web app, and that's a very straightforward thing to do? It is not so straightforward in the native mobile world. And so, we now have afforded ourselves the ability to do that.

+ +

But critically, and this is the fun part in my mind, have the trade-offs in the controls. So if we were just like, it's just a WebView, and that's it, and we put it in the stores, and we're done, that is too far of an extreme in my mind. I think the performance trade-offs, the experience trade-offs, it wouldn't feel like a native app like in a deep way, in a problematic way. And so as an example, we have a navigation bar at the top of our app, particularly on iOS, that is native iOS navigation. And we have a tab bar at the bottom, which is native tab UI element. I forget actually what it's called, but it's those elements.

+ +

And we hide the web application navigation when we're in the mobile context. So we actually swap those out and say, like, let's actually promote these to formal native functionality. We also, within our UI on the web, have a persistent button in the top right corner of your screen that says, "Need help? Reach out to your retirement advocate." who is the person that you get to work with. You can send questions, et cetera, et cetera. It's this little help sidebar drawer thing that pops out. And we have that as a persistent HTML button in the top corner of the web frame.

+ +

But when we're on native, we push that up as a distinct element in the native UI section. And then again, the bridge that I'm talking about allows for bi-directional communication between the JavaScript side and the native side or the native side and the JavaScript side. And so it's those sorts of pieces that have now afforded us all of the freedom to tinker, and we don't need to re-release where we're like, oh, we want to add a new weird button that does a thing in the WebView when you click on a button outside the WebView. We now just have that built-in.

+ +

STEPH: Yeah, I really like the flexibility that you're describing. When you promoted those elements to be more native-friendly so, like the navigation or the footer or the little get help chat, is that something that then your team implemented in like the iOS or the Kotlin repo? Okay, I see you nodding, but other people can't see that, so...[laughs]

+ +

CHRIS: Yeah. I was going to also say the words, but yes, those are now implemented as native parts. So the thing that we built isn't purely agnostic decoupled. It is Sagewell-specific; a lot of it is low-level. Like, let's say we want to wrap an Inertia app in a native mobile wrapper. Like, 90% of the code in it is that, but then there are little bits that are like, and put a button up there. And that button is the Sagewell button. And so it's not entirely decoupled from us. But it mostly is this agnostic bridge to connect things together.

+ +

STEPH: Yeah, the way you're describing it sounds really nice in terms of you're able to get out the app quickly and have a mobile app quickly that works on both platforms, and then you're still able to deploy changes without having to push that. That was always my biggest mental, or emotional hurdle with the idea of mobile development was the concept of that you really had to batch everything together and then submit it for review and approval and then get it released.

+ +

And then you got to hope people then upgrade and get the newest version. And it just felt like such a process, not that I ever did much of it. This was all just even watching like the mobile team and all the work that they had to do. And I had sympathy pains for them. But the fact that this approach allows you to avoid a lot of that but still have some nice, customized, more native elements. Yeah, I'm basically just recapping everything you said because I like all of it.

+ +

CHRIS: Well, thank you, friend. Like I said, I've really enjoyed it, and similar to you, I'm addicted to the feedback loop of the web. It's beautiful. I can deploy ten times or however many I want. Anytime I want, I can push out a new version. And that ability to iterate, to test, to explore, to tweak, to not have to do as much formal testing upfront because I'm terrified that if a bug sneaks out, then, it'll take me two weeks to address it; it just is so, so freeing. And so to give that up moving into a native context.

+ +

Perhaps I'm fighting too hard to hold on to my dream of the ability to rapidly iterate. But I really do believe in that and especially for where we're at as an organization right now. But, and a critical but here, again, it's a trade-off like anything else. And recently, I happened to be out about in the town, and I decided, oh, you know what? Let me open up the app. Let me see what it's like. And I wasn't on great internet. And so I open the app, and it loads because, you know, it's a native app, so it pops up.

+ +

But then the thing that actually happened is a loading spinner in the middle of the screen and sort of a gray nothing for a little while until the server request to fetch the necessary UI elements to render the login screen appeared. And that experience was not great. In particular, that experience is core to the experience of using the app every single time. Every time you use it, you're going to have a bad time because we're re-downloading that UI element. And there's caching, and there's things that could happen there to help with that. But fundamentally, that experience is going to be a pretty common one. It's the first thing that you experience when you're opening the app.

+ +

And so I noticed that and I chatted with the team, and I was like, hey, I feel like this is actually something that fixing this I think would really fundamentally move us along that spectrum of like, we've definitely made some trade-offs here. But overall, it feels snappy and like a native app. And so, we opted to prioritize work on a native login screen for both platforms. This also allows us to more deeply integrate. So particularly, we're going to get biometric logins like fingerprints or face scans, or whatever it is.

+ +

But critically, it's that experience of like, I open the Sagewell native app on my iOS phone, and then it loads immediately. And then I show it my face like we do these days, and then it opens up and shows me everything that I want to see inside of it. And it's that first-run experience that feels worth the extra effort and the constraints. Because now that it's native mobile, that means in order to change it, we have to do a deploy, not a deploy, release; that's what they call it in the native world. [laughs] You can tell I'm well-versed in this ecosystem.

+ +

But yeah, we're now choosing that trade-off. And what I really liked about this sort of set of things like the feature that we were able to just accidentally get for free on native because that's how this thing is built. And then likewise, the choice to opt into a fully native login screen like having that lever, having that control over I'm going to optimize for iteration generally, but where it's important, we want to optimize for performance and experience. And now we have this little slider that we can go back and forth.

+ +

And frankly, we could choose to screen by screen just slowly replace everything in the app with true native WebViews backed by APIs. And we could Ship of Theseus style replace every element of the app with true native mobile things until none of the old bridge code exists. And our users, in theory, would never know. Having that flexibility is really nice given the trade-off and the choice that we've made.

+ +

STEPH: You said a word there that I missed. You said ship something style.

+ +

CHRIS: Ship of Theseus.

+ +

STEPH: What is that?

+ +

CHRIS: It's like an old biblical story, I want to say, but it's basically the idea of, like, you have the ship. And then some boards start to rot out, so replace those boards. And then the mast breaks, you replace the mast. And slowly, you've replaced every element on the ship. Is it still the same ship at that point? And so it's sort of a philosophical question. So if we replace every single view in this app with a native view, is it still the same map? Philosophers will philosophize about it forever, but whatever. As long as we get to keep iterating and shipping software, then I'm happy.

+ +

STEPH: [laughs] Y’all philosophize. That's that word, right?

+ +

CHRIS: Yeah.

+ +

STEPH: And do your philosopher thing. We'll just keep building and shipping.

+ +

CHRIS: I don't know if I pronounced it right. It's like either Theseus or Theseus, and I'm sure I said the wrong one. And now that I've said the other, I'm sure both of them are wrong somehow. It's like a USB where there's up and down, and yet somehow it takes three tries. So anyway, I may have mispronounced it, and I may be misattributing it, but that's the idea I was going for.

+ +

STEPH: Well, given I wasn't even familiar with the word until just now, I'm going to give both pronunciations a thumbs up. I also really like how you decided that for the login screen, that's the area that you don't want people to wait because I agree if you're opening an application or opening...maybe it's the first time, maybe it's the 100th time. Who knows? But that feels important. Like, that needs to be snappy. I need to know it's responsive. And it builds trust from the minute that I clicked on that application. And if it takes a long time, I just immediately I'm like, what are y'all doing? Are y'all real? Do you know what you're doing over there?

+ +

So I like how you focused on that experience. But then once I log in, like if something is slow to log me in, I will make up excuses for the application all day where I'm like, well, you know, maybe it's my connection. It's fine. I can wait for the next screen to load. That feels more reasonable. And it doesn't undermine my trust nearly as much as when I first click on the app. So that feels like a really nice trade-off as well, or at least a nice area that you've improved while still having those other trade-offs and benefits that you mentioned.

+ +

CHRIS: To highlight it, you used a phrase there which I really liked. Like, it's building trust. If something's a little bit off in that first run experience every single time, then it kind of puts a question in the back of your head, maybe not even consciously. But you're just kind of looking at it, and you're like, what are you doing there? What are you up to, friend? Humans say to the apps they use on their phone. That's normal, right? When you talk...

+ +

But to name it, we've also done a round of performance work throughout the app. And so there are a couple of layers to it. But it was work that we had planned for a while, but we kept deferring. But now that we're seeing more usage of the native apps, the native apps experience the same surface area of performance stuff but all the more so because they may be on degraded network connections, et cetera.

+ +

And so this is another example where this whole thing kind of pays off. The performance work that we did affects everything. It affects the web. It's the same under the hood. It's let's reduce the network requests that we're making in the payloads that we're sending, particularly the network requests to upstream things, so like the banking partner that we're using and those APIs, like, collating all the data to then render the screen.

+ +

Because of Inertia, we only have a single sort of back and forth conversation via the API as opposed to I think it's pretty common to have like seven different APIs and four different spinners on the screen. We're not doing that, none of that on my watch. [chuckles] But we minimize the background calls to the other parties that we're integrating with. And then, we reduce the payload of data that we're sending on each request.

+ +

And each of those were like, we had to think about things and tweak and poke, but again it's uniform. So mobile web has that now, desktop web has that now. Android, iOS, they all just inherited it sort of that just happened one day without a deploy or release, without a release of either of the native mobile apps. We did deploy to the web to make that happen, but that's easy. I can do that a bunch of times a day.

+ +

One last thing I want to share as we're on this topic of trade-offs and levers, there was a really great conference talk that I watched recently, which was Ryan Florence of remix.run also React Router fame if you're familiar with him from that. But he was talking about the most recent version of Remix, which is their meta framework on top of React.

+ +

But they've done some really interesting stuff around processing data, fetching data, when and how to sequence that. And again, that thing that I talked about of nine different loading spinners on the screen, Remix is taking a very different approach but is targeting that same thing of like, that's not great for user experience. Cumulative layout shift being the actual number that you can monitor for this.

+ +

But in that talk, there are features that they've added to Remix as a framework where you can just decide, like, do we wait for this or do we not? Do we make sure we have all of the data, or do we say, you know what? Actually, this is going to be below the fold. So it's okay to defer loading this until after we send down the first payload. And then we'll kick in, and we'll do it from the client-side. But it's this wonderful feature of the framework that they're adding in where there's basically just a keyword that you can add to sort of toggle that behavior.

+ +

And again, it's this idea of like trade-offs. Are we okay with more layout shift, or are we okay with more waiting? Which is it that we're going to optimize for? And I really love that idea of putting that power very simply in the hands of the developers to make those trade-off decisions and optimize over time for what's important. So we'll share a link to that talk in the show notes as well.

+ +

But it was very much in the same space of like, how do I have the power to decide and to change my mind over time? That's what I want. But yeah, with that, I think that's enough of me updating on the mobile app. I'll continue to share as new things happen. But again, I'm at this point very happy with where we're at. So yeah, it's been fun. But yeah, what else is up in your world?

+ +

STEPH: I have a dear Gerrit message that I wrote earlier, so I want to share that with you. Gerrit is the system that we're using for when we push up code changes that then manages very similar in the competitive space of like GitHub and GitLab, and Bitbucket. And so the team that I'm working with we are using Gerrit. And Gerrit and I, you know, we get along for the most part. We've managed to have a working relationship. [chuckles] But this week, I wrote my dear Gerrit letter is that I really miss being able to tell a story with my commit messages. That is the biggest pain that I'm feeling right now.

+ +

So for anyone that's less familiar or if you already are familiar with Gerrit, each change that Gerrit shows represents a single commit that's under review. And each change is identified by a Change-Id. So the basic concept of Gerrit is that you only have one commit per review. So if you were to translate that to GitHub terminology, every pull request is only going to have one commit, and so you really can't push up multiple.

+ +

And so, where that has been causing me the most pain is I miss being able to tell a story. So like even simple stories that are like, hey, I removed something that's not used. I love separating that type of stuff into its own commit just so then people can see that as they're going through review. Now, before I merge, I'm likely to squash, and that doesn't feel important that it needs to be its own commit. That's really just for the reviewer so they can follow along for the changes.

+ +

But the other one, I can slowly get over that one. Because essentially, the way I get around that is then when I do push up my code for review, is I then go through my change request, and then I just add comments. So I will highlight that line and say, "Hey, I'm removing this because it's not in use." And so, I found a workaround for that one.

+ +

But the one I haven't found a workaround for is that I don't push up my local work very often because I love having lots of local, tiny, green commits so that way I can know the progress that I'm at. I know where I'm headed. Also, I have a safe space to roll back to, but then that means that I may have five or six commits that I have locally, but I haven't pushed up somewhere. And that is bothering me more and more hour by hour the more I think about it that I can't push stuff up because it makes me nervous.

+ +

Because, I mean, usually, at least by the end of the day, I push everything up, so it's stored somewhere. And I don't have to worry about that work disappearing. Now I am working on a dev machine. So there is that aspect of it's technically...it's not even on my local machine. It is stored somewhere that I should still be able to access.

+ +

CHRIS: What's a dev machine? The way you're saying it, it sounds like it's a virtual machine, not like a laptop. But what's a dev machine?

+ +

STEPH: Good question. So the dev machine is a remote server or remote machine that then I am accessing, and then that's where I'm performing. That's where I'm writing all of my work. And then that's also kind of the benefit is everything is not local; it's controlled by the team. So then that also means that other teams, other individuals can help set up these environments for future developers.

+ +

So then you have that consistency across everyone's working with the same Rails version, or gems, or has access to the same tools. So in that sense, my work isn't just on my laptop because then that would really worry me because then I've got nowhere...it's not backed up anywhere. So at least it is somewhere it's being stored that then could be accessed by someone.

+ +

So actually, now, as I'm talking this through, that does help alleviate my concern about this a bit. [laughs] But I still miss it; I still miss being able to just push up my work and then have multiple commits. And I looked into it because I was like, well, maybe I'm misunderstanding something about Gerrit, and there's a way around this. And that's still always a chance. But from the research that I've done, it doesn't seem to be. And there are actually two very fiery takes that I saw that I have to share because they made me laugh.

+ +

When I was Googling, the question of like, "Can I push up multiple commits to one single Gerrit CR? Or is there just a way to, like, can I have this concept of like a branch and then I have many commits, but then I turn it into one CR? Whatever the world would give me. What do they have? [laughs] I'm laughing just looking at this now. One of the responses was, have you tried squashing your commits into one commit? And I was like, [laughs] "Yeah, that's not what I had in mind, but sure."

+ +

And then the other one, this is the more fiery take. They were very defensive about Gerrit, and they wrote that "People who don't like Gerrit usually just hack shit together. They cut corners and love squashing commits or throwing away history. And those people hate Gerrit. Developers who care love it. It's definitely possible and easy to produce agile software." And I just...that made me laugh. I was like, cool, I'm a developer that cuts corners and loves squashing commits. [laughs]

+ +

CHRIS: So you don't care is what that take says.

+ +

STEPH: I'm a developer who does not care.

+ +

CHRIS: You know, Steph, I've worked with you for a while. And I've been looking for the opportunity to have this hard conversation with you. But I just wish you cared a little more about the software that you're writing, about the people that you're working with, about the commits that you're authoring. I just see it in every facet of your work. You just don't care. To be very clear for anyone listening at home, that is the deepest of sarcasm that I can make. Steph cares so very much. It's one of the things that I really enjoy about you.

+ +

STEPH: I mean, we had the episode about toxic traits. This would have been the perfect time to confront me about my lack of caring about software and the processes that we have. So winding down on that saga, it seems to be the answer is no, friend; I cannot push up multiple commits. Oh, I tried to hack it. I am someone that tries to hack shit together because I tried to get around it just to see what would happen. [laughs] Because the docs had suggested that each change is identified by a Change-Id. And I was like, hmm, so what if there were two commits that had the same Change-Id, would Gerrit treat those as patch sets?

+ +

Because right now, when you push up a change, you can see all the different patch sets, so that's nice. So that's a nice feature of Gerrit as you can see the history of, like, someone pushed up this change. They took in some feedback. They pushed up a new change. And so that history is there for each push that someone has provided. And I wondered maybe if they had the same Change-Id that then the patch sets would show the first commit and then the second commit. And so I manually altered the commits two of them to reference the same Change-Id.

+ +

And I have to say, Gerrit was on to me because they gave me a very nice error message that said, "Same Change-Id and multiple changes. Squash the commits with the same Change-Ids or ensure Change-Ids are unique for each commit. And I thought, dang, Gerrit, you saw me coming. [laughs] So that didn't work either. I'm still in a world of where I now wait. I wait until I'm ready for someone to review stuff, and I have to squash everything, and then I go comment on my CRs to help out reviewers.

+ +

CHRIS: I really like the emotional backdrop that you provided here where you're spending a minute; you're like, you know what? Maybe it's me. And there's the classic Seymour Skinner principle from The Simpsons. Am I out of touch? No, it's the children who are wrong. [laughs] And I liked that you took us on a whole tour of that. You're like, maybe it's me. I’ll maybe read up. Nope, nope. So yeah, that's rough.

+ +

There's a really interesting thing of tools constraining you. And then sometimes being like, I'm just going to yield control and back away and accept this thing that doesn't feel right to me. Like, Prettier does a bunch of stuff that I really don't like. It shapes code in a way, and I'm just like, no, that's not...nope, you know what? I've chosen to never care about this again. And there's so much utility in that choice. And so I've had that work out really well. Like with Prettier, that's a great example whereby yielding control over to this tool and just saying, you know what? Whatever you produce, that is our format; I don't care. And we're not going to talk about it, and that's that.

+ +

That's been really useful for myself and for the teams that I'm on to just all kind of adopt that mindset and be like, yeah, no, it may not be what I would choose but whatever. And then we have nice formatted code; it's great. It happens automatically, love it. But then there are those times where I'm like; I tried to do that because I've had success with that mindset of being like, I know my natural thing is to try and micromanage and control every little bit of this code.

+ +

But remember that time where it worked out really well for me to be like, I don't care, I'm just going to not care about this thing? And I try to not care about some stuff, which it sounds like that's what you're doing right here. [laughs] And you're like, I tried to not care, but I care. I care so much. And now you're in that [chuckles] complicated space. So I feel for you, Steph. I'm sorry you're in that complicated space of caring so much and not being able to turn that off [laughs] nor configure the software to do the thing you want.

+ +

STEPH: I appreciate it. I should also share that the team that I'm working with they also don't love this. Like, they don't love Gerrit. So when I shared in the Slack channel my dear Gerrit message, they're both like, "Yeah, we feel you. [laughs] Like, we're in the same spot," which was also helpful because I just wanted to validate like, this is the pain I'm feeling. Is someone else doing something clever or different that I just don't know about? And so that was very helpful for them to say, "Nope, we feel you. We're in the same spot. And this is just the state that we're in."

+ +

I think they have started transitioning some other repos over to GitLab and have several repos in Gitlab, but this one is still currently using Gerrit. So they very much commiserate with some of the things that I'm feeling and understand. And this does feel like one of those areas where I do care deeply.

+ +

And frankly, this is one of those spaces that I do care about, but it's also like, I can work around it. There are some reasonable things that I can do, and it's fine as we just talked through. Like, the fact that my commits are not just locally on my machine already makes me feel better now that I've really processed that. So there are lower risks. It is more of just like a workflow. It's just, you know, it's crushing my work vibe.

+ +

CHRIS: Harshing your buzz.

+ +

STEPH: In the great words of Queen Elsa, I gotta let it go. This is the thing I'm letting go. So that's kind of what's going on in my world. What else is going on in your world?

+ +

CHRIS: Well, first and foremost, fantastic reference and segue. I really liked that. But yeah, let's see, [laughs] what else is going on in my world? We had an interesting thing happen last week. So we had an outage on the platform last week. And then we had an incident review today, so a formal sort of post-mortem incident review. There are a couple of different names that folks have given to these. But this is a practice that we want to build within our engineering culture is when stuff goes wrong, we want to make sure that we have meaningful conversations around to try to address the root causes.

+ +

Ideally, blameless is a word that gets used often in this context. And I've heard folks sort of take either side of that. Like, it's critical that it's blameless so that it doesn't feel like it's an attack. But also, like, I don't know, if one person did something, we should say that. So finding that gentle middle ground of having honest, real conversations but in a context of safety. Like, we're all going to make mistakes. We're all going to ship bugs; let's be clear about that. And so it's okay to sort of...anyway, that's about the process.

+ +

We had an outage. The specific outage was that we have introduced a new process. This is a Sidekiq process to work off a specific queue. So we wanted that to have discrete treatment. That had been running, and then it stopped running; we still don't know why. So we never got to the root-root cause. Well, we know what the mechanism was, which was the dyno count for that process was at zero. And so, eventually, we found a bunch of jobs backed up in the Sidekiq admin. We're like, that's weird.

+ +

And then, we went over to Heroku's configuration dashboard. And we saw, huh, that's weird. There are zero dynos processing this. That wasn't true yesterday. But unfortunately, Heroku doesn't log or have an audit trail around changes to those process counts. It's just not available. So that's unfortunate. And then the actual question of like, how did this happen? It probably had to be someone on the team. So there is like, someone did a thing. But that is almost immaterial because, again, people are going to do things, bugs will get shipped, et cetera.

+ +

So the conversation very quickly turned to observability and understanding. I think we've done a pretty good job of instrumenting error reporting and being quite responsive to that, making sure the signal-to-noise ratio is very actionable. So if we see a bug or a Sentry alert come through, we're able to triage that pretty quickly, act on it where it is a real bug, understand where it's a bit of noise in the system, that sort of thing. But in this case, there were no errors. There was no Sentry. There was nothing; there was the absence of something.

+ +

And so it was this really interesting case of that's where observability, I think, can really come in and help. So the idea of what can we do here? Well, we can monitor the count of jobs backed up in Sidekiq queue. That's one option. We could do some threshold alerting around the throughput of processed events coming from this other backend. There are a bunch of different ways, but it basically pushed us in the direction of doubling down and reinforcing the foundation of our observability within the platform.

+So we're just kicking that mini-project off now, but it is something we're like, yeah, we feel like we could add some here. In particular, we recently added Datadog to the stack. So we now have Datadog to aggregate our logs and ideally do some metric analysis, those sort of things, build some dashboards, et cetera. I haven't explored Datadog much thus far. But my sense is they've got the whiz-bang things that we need here. But yeah, it was an interesting outage. That wasn't fun. The incident conversation was actually a good conversation as a team. And then the outcome of like, how do we double down on observability? I'm actually quite excited for.

+ +

STEPH: This is a fun moment for me because I have either joined teams that didn't have Datadog or have any of that sort of observability built into their system or that sort of dashboard that people go to. Or I've joined teams, and they already have it, and then nobody or people rarely look at it. And so I'm always intrigued between like what's that catalyst that then sparked a team to then go ahead and add this? And so I'm excited to hear you're in that moment of like, we need more observability. How do we go about this?

+ +

And as soon as you said Datadog, I was like, yeah, that sounds nice because then it sounds like a place that you can check on to make sure that everything is still running. But then there's still also that manual process where I'm presuming unless there's something else you have in mind. There's still that manual process of someone has to check the dashboard; someone then has to understand if there's no count, no squiggly lines, that's a bad thing and to raise a concern.

+ +

So I'm intrigued with my own initial reaction of, like, yeah, that sounds great. But now I'm also thinking about it still adds a lot of...the responsibility is still on a human to think of this thing and to go check it. Versus if there's something that gets sent to someone to alert you and say like, "Hey, this queue hasn't been processed in 48 hours. There may be a concern that actually feels nicer." It feels safer.

+ +

CHRIS: Oh yeah, definitely. I think observability is this category of tools and workflows and whatnot. But I think what you're describing of proactive alerting that's the ideal. And so it would be wonderful if I never had to look at any of these tools ever. And I just knew if I got, let's say, it's PagerDuty connected up whatever, and I got a push notification from PagerDuty saying, "Hey, go look at this thing." That's all I ever need to think about. It’s like, well, I haven't gotten a PagerDuty in a while, so everything must be fine, and having a deep trust in that.

+ +

Similar to like, if we have a great test suite and it's green, I feel confident deploying the sort of absence of an alert being the thing that I can trust. But right now, we're early enough in this journey that I think what we need to do is stand up a bunch of these different graphs and charts and metric analysis and aggregations and whatnot, and then start to squint at it for a while and be like, which of these would I be really concerned if it started to wibble?

+ +

And then you can figure the alerting around said wibble rate. And that's the dream. That's where we want to get to, but I think we've got to crawl, walk, run on this. So it'll be an adventure. This is very much the like; we're starting a thing. I'll tell you about it more when we've done it. But what you're describing is exactly what we want to get to.

+ +

STEPH: I love wibble rate. That's my new measurement I'm going to start using for everything. It's funny, as you're bringing this up, it's making me think about the past week that Joël Quenneville and I have had with our client work. Because a somewhat similar situation came up in regards where something happened, and something was broken. And it seemed it was hard to define exactly what moment caused that to break and what was going on.

+ +

But it had a big impact on the team because it essentially meant none of the bills were going through. And so that's a big situation when you got 100-plus people that are pushing up code and expecting some of the build processes to run. But it was one of those that the more we dug into it, the more it seemed very rare that it would happen.

+ +

So, in this case, as a sort of a juxtaposition to your scenario, we actually took the opposite approach of where we're like; this is rare. But we did load up a lot of contexts. Actually, I was thinking back to the advice that you gave me in a previous episode where I was talking about at what point do you dig in versus try to stay at surface level? And this was one of those, like, we've spent a couple of days on getting context for this and understanding. So it felt really important and worthwhile to then invest a little bit more time to then document it.

+ +

But then we still went with the simplest approach of like, this is weird. It shouldn't happen again. We think we understand it but then let's add a little bit of documentation or wiki page around like, hey, if you do run into this, here are some steps that will fix everything. And then, if you need to use this, let somebody know because this is so odd it shouldn't happen. So we took that approach in this case where we didn't increase the observability. It was more like we provided a fire extinguisher very close to the location in case it happens. And so that way, it's there should the need arise, but we're hoping it just never gets used.

+ +

We're also in the process of changing how a lot of that logic works. So we didn't really want to optimize for observability into a system that is actively being changed because it should look very different in upcoming months. But overall, I love the conversations that you bring about observability, and I'm excited to hear about what wibble rates you decide to add to your Datadog dashboard.

+ +

CHRIS: There's a delicate art and science to the selection of the wibble rates. So I will certainly report back as we get into that work. But with that, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+y9jFOpC- + + ]]> + + Chris Toomey + Steph Viccari + + + 341: Fundamentals and Weird Stuff + https://bikeshed.thoughtbot.com/341 + f07f32d7-5f01-4241-8b4c-42196d98304b + Tue, 07 Jun 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph and Chris are recording together! Like, in the same room, physically together. + +Chris talks about slowly evolving the architecture in an app they're working on and settling on directory structure. Steph's still working on migrating unit tests over to RSpec. + +They answer a listener question: "As senior-level developers, how do you set goals to ensure that you keep growing?" + 35:27 + no + + + Steph and Chris are recording together! Like, in the same room, physically together. +Chris talks about slowly evolving the architecture in an app they're working on and settling on directory structure. Steph's still working on migrating unit tests over to RSpec. +They answer a listener question: "As senior-level developers, how do you set goals to ensure that you keep growing?" +This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. +Faking External Services In Tests With Adapters (https://thoughtbot.com/blog/faking-external-services-in-tests-with-adapters) +Testing Third-Party Interactions (https://thoughtbot.com/blog/testing-third-party-interactions) +Jen Dary - On Future Goals (https://www.beplucky.com/on-future-goals/) +Charity Majors - The Engineer Manager Pedulum (https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) +Charity Majors Bike Shed Episode (https://www.bikeshed.fm/302) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? +CHRIS: What is new in my world? Actually, this episode feels different. There's something different about it. I can't quite put my finger on it. I think it may be that we're actually physically in the same room recording for the first time in two years and a little bit more, which is wild. +STEPH: I can't believe it's been that long. I feel like it wasn't that long ago that we were in The Bike Shed...oh, I said The Bike Shed studio. I'm being very biased. Our recording studio [laughs] is the more proper description for it. Yeah, two and a half years. And we tried to make this happen a couple of months ago when I was visiting Boston, and then it just didn't work out. But today, we made it. +CHRIS: Today, we made it. Here we are. So hopefully, the audio sounds great, and we get all that more richness in conversation because of the physical in-person manner. We're trying it out. It'll be fun. But let's see, to the normal tech talk and nonsense, what's new in my world? So we've been slowly evolving the architecture in the app that we're working on. And we settled on something that I kind of like, so I wanted to talk about it, directory structure, probably the most interesting topic in the world. I think there's some good stuff in here. +So we have the normal stuff. There are app models, app controllers, all those; those make sense. We have app jobs which right now, I would say, is in a state of flux. We're in the sad place where some things are application records, and some things are Sidekiq workers. We have made the decision to consolidate everything onto Sidekiq workers, which is just strictly more powerful as to the direction we're going to go. But for right now, I'm not super happy with the state of app jobs, but whatever, we have that. +But the things that I like so we have app commands; I've talked about app commands before. Those are command objects. They use dry-rb do notation, and they allow us to sequence a bunch of things that all may fail, and we can process them all in a much more reasonable way. It's been really interesting exploring that, building on it, introducing it to new developers who haven't worked in that mode before. And everyone who's come into the project has both picked it up very quickly and enjoyed it, and found it to be a nice expressive mode. So app commands very happy with that. +App queries is another one that we have. We've talked about this before, query objects. I know we're a big fan. [laughs] I got a golf clap across the room here, which I could see live in person. It was amazing. I could feel the wind wafting across the room from the golf clap. [chuckles] But yeah, query objects, they're fantastic. They take a relation, they return a relation, but they allow us to build more complex queries outside of our models. +The new one, here we go. So this stuff would all normally fall into app services, which services don't mean anything. So we do not have an app services directory in our application. But the new one that we have is app clients. So these are all of our HTTP clients wrapping external third parties that we're interacting with. But with each of them, we've taken a particular structure, a particular approach. So for each of them, we're using the adapter pattern. There's a blog post on the Giant Robots blog that I can point to that sort of speaks to the adapter pattern that we're using here. +But basically, in production mode, there is an HTTP backend that actually makes the real requests and does all that stuff. And in test mode, there is a test backend for each of these clients that allows us to build up a pretty representative fake, and so we're faking it up before the HTTP layer. But we found that that's a good trade-off for us. And then we can say, like, if this fake backend gets a request to /users, then we can respond in whatever way that we want. +And overall, we found that pattern to be really fantastic. We've been very happy with it. So it's one more thing. All of them were just gathering in-app models. And so it was only very recently that we said no, no, these deserve their own name. They are a pattern. We've repeated this pattern a bunch. We like this pattern. We want to even embrace this pattern more, so long live app clients. +STEPH: I love it. I love app clients. It's been a while since I've been on a project that had that directory. But there was a greenfield project that I was working on. I think it might have been I was working with Boston.rb and working on giving them a new site or something like that and introduced app clients. And what you just said is perfect in terms of you've identified a pattern, and then you captured that and gave it its own directory to say, "Hey, this is our pattern. We've established it, and we really like it." That sounds awesome. +It's also really nice as someone who's new to a codebase; if I jump in and if I look at app clients, I can immediately see what are the third parties that we're working with? And that feels really nice. So yeah, that sounds great. I'm into it. +CHRIS: Yeah, I think it really was the question of like, is this a pattern we want to embrace and highlight within the codebase, or is this sort of a duplication but irrelevant like not really that important? And we decided no, this is a thing that matters. We currently have 17 of these clients, so 17 different third-party external things that we're integrating with. So for someone who doesn't really like service-oriented architecture, I do seem to have found myself in a place. But here we are, you know, we do what we have to with what we're given. But yes, 17 and growing our app clients. +STEPH: That is a lot. [laughs] My eyes widened a bit when you said 17. I'm curious because you highlighted that app services that's not really a thing. Like, it doesn't mean anything. It doesn't have the same meaning of the app queries directory or app commands or app clients where it's like, this is a pattern we've identified, and named, and want to propagate. +For app services, I agree; it's that junk drawer. But I guess in some ways...well, I'm going to say something, and then I'm going to decide how I feel about it. That feels useful because then, if you have something but you haven't established a pattern for it, you need a place for it to go. It still needs to live somewhere. And you don't necessarily want to put it in app models. So I'm curious, where do you put stuff that doesn't have an established pattern yet? +CHRIS: It's a good question. I think it's probably app models is our current answer. Like, these are things that model stuff. And I'm a big believer in the it doesn't need to be an application record-backed object to go on app models. But slowly, we've been taking stuff out. I think it'd be very common for what we talk about as query objects to just be methods in the respective application record. So the user record, as a great example, has all of these methods for doing any sort of query that you might want to do. And I'm a fan of extracting that out into this very specific place called app queries. +Commands are now another thing that I think very typically would fall into the app services place. Jobs naming that is something different. Clients we've got serializers is another one that we have at the top level, so those are four. We use Blueprinter within the app. And again, it's sort of weird. We don't really have an API. We're using Inertia. So we are still serializing to JSON across the boundary. And we found it was useful to encapsulate that. And so we have serializers as a directory, but they just do that. We do have policies. We're using Pundit for authorization, so that's another one that we have. +But yeah, I think the junk drawerness probably most goes to app models. But at this point, more and more, I feel like we have a place to put things. It's relatively clear should this be in a controller, or should this be in a query object, or should this be in a command? I think I'm finding a place of happiness that, frankly, I've been searching for for a long time. You could say my whole life I've been searching for this contented state of I think I know where stuff goes in the app, mostly, most of the time. +I'm just going to say this, and now that you've asked the excellent question of like, yeah, but no, where are you hiding some stuff? I'm going to open up models. Next week I’m going to be like, oh, I forgot about all of that nonsense. But the things that we have defined I'm very happy with. +STEPH: That feels really fair for app models. Because like you said, I agree that it doesn't need to be ActiveRecord-backed to go on app models. And so, if it needs to live somewhere, do you add a junk drawer, or do you just create app models and reuse that? And I think it makes a lot of sense to repurpose app models or to let things slide in there until you can extract them and let them live there until there's a pattern that you see. +CHRIS: We do. There's one more that I find hilarious, which is app lib, which my understanding...I remember at one point having one of those afternoons where I'm just like, I thought stuff works, but stuff doesn't seem to work. I thought lib was a directory in Rails apps. And it was like, oh no, now we autoload only under the app. So you should put lib under app. And I was just like, okay, whatever. +So we have app lib with very little in it. [laughs] But that isn't so much a junk drawer as it is stuff that's like, this doesn't feel specific to us. This goes somewhere else. This could be extracted from the app. But I just find it funny that we have an app lib. It just seems wrong. +STEPH: That feels like one of those directories that I've just accepted. Like, it's everywhere. It's like in all the apps that I work in. And so I've become very accustomed to it, and I haven't given it the same thoughtfulness that I think you have. I'm just like, yeah, it's another place to look. It's another place to go find some stuff. And then if I'm adding to it, yeah, I don't think I've been as thoughtful about it. But that makes sense that it's kind of silly that we have it, and that becomes like the junk drawer. If you're not careful with it, that's where you stick things. +CHRIS: I appreciate you're describing my point of view as thoughtfulness. I feel like I may actually be burdened with historical knowledge here because I worked on Rails apps long, long ago when lib didn't go in-app, and now it does. And I'm like, wait a minute, but like, no, no, it's fine. These are the libraries within your app. I can tell that story. So, again, thank you for saying that I was being thoughtful. I think I was just being persnickety, and get off my lawn is probably where I was at. +STEPH: Oh, full persnicketiness. Ooh, that's tough to say. [laughs] +CHRIS: But yeah, I just wanted to share that little summary, particularly the app clients is an interesting one. And again, I'll share the adapter pattern blog post because I think it's worked really well for us. And it's allowed us to slowly build up a more robust test suite. And so now our feature specs do a very good job of simulating the reality of the world while also dealing with the fact that we have these 17 external situations that we have to interact with. +And so, how do you balance that VCR versus other things? We've talked about this a bunch of times on different episodes. But app clients has worked great with the adapter pattern, so once more, rounding out our organizational approach. But yeah, that's what's up in my world. What's up in your world? +STEPH: So I have a small update to give. But before I do, you just made me think of something in regards to that article that talks about the adapter pattern. And there's also another article that's by Joël Quenneville that's testing third-party interactions. And he made me reflect on a time where I was giving the RSpec course, and we were talking about different ways to test third-party interactions. And there are a couple of different ways that are mentioned in this article. There are stub methods on adapter, stub HTTP request, stub request to fake adapter, and stub HTTP request to fake service. All that sounds like a lot. But if you read through the article, then it gives an example of each one. +But I've found it really helpful that if you're in a space that you still don't feel great about testing third-party interactions and you're not sure which approach to take; if you work with one API and apply all four different strategies, it really helps cement how to work through that process and the different benefits of each approach and the trade-offs. And we did that during the RSpec course, and I found it really helpful just from the teacher perspective to go through each one. And there were some great questions and discussions that came out of it. +So I wanted to put that plug out there in the world that if you're struggling testing third-party interactions, we'll include a link to this article. But I think that's a really solid way to build a great foundation of, like, I know how to test a third-party app. Let me choose which strategy that I want to use. +Circling back to what's going on in my world, I am still working on migrating unit tests over to RSpec. It's a thing. It's part of the work that I do. [laughs] I can't say it's particularly enjoyable, but it will have a positive payoff. And along that journey, I've learned some things or rediscovered some things. One of them is read expectations very carefully. +So when I was migrating a test over to RSpec, I read it as where we expected a record to exist. The test was actually testing that a record did not exist. And so I probably spent an hour understanding, going through the code being like, why isn't this record getting created like I expect it to? And I finally went back, and I took a break, and I went back. And I was like, oh, crap, I read the expectation wrong. So read expectations very carefully. +The other one...this one's not learned, but it is reinforced. Mystery Guests are awful. So as I've been porting over the behavior over to RSpec, the other tests are using fixtures, and I'm moving that over to use factorybot instead. And at first, I was trying to be minimal with the data that I was bringing over. That failed pretty spectacularly. So I have learned now that I have to go and copy everything that's in the fixtures, and then I move it over to factorybot. And it's painful, but at least then I'm doing that thing that we talked about before where I'm trying to load as little context as possible for each test. +But then once I do have a green test, I'm going back through it, and I'm like, okay, we probably don't care about when you were created. We probably don't care when you're updated because every field is set for every single record. So I am going back and then playing a game of if I remove this line, does the test still pass? And if I remove that line, does the test still pass? And so far, that has been painful, but it does have the benefit of then I'm removing some of the setup. So Mystery Guests are very painful. +I've also discovered that custom error messages can be tricky because I brought over some tests. And some of these, I'm realizing, are more user error than anything else. Anywho, I added one of the custom error messages that you can add, and I added it over to RSpec. But I had written an incorrect, invalid statement in RSpec where I was looking...I was expecting for a record to exist. But I was using the find by instead of where. So you can call exist on the ActiveRecord relation but not on the actual record that gets returned. +But I had the custom error message that was popping up and saying, "Oh, your record wasn't found," and I just kept getting that. So I was then diving through the code to understand again why my record wasn't found. And once I removed that custom error message, I realized that it was actually because of how I'd written the RSpec assertion that was wrong because then RSpec gave me a wonderful message that was like, hey, you're trying to call exist on this record, and you can't do that. Instead, you need to call it on a relation. +So I've also learned don't bring over custom error messages until you have a green test, and even then, consider if it's helpful because, frankly, the custom error message wasn't that helpful. It was very similar to what RSpec was going to tell us in general. So there was really no need to add that custom step to it. +For the final bit that I've learned or the hurdle that I've been facing is that migrating tests descriptions are hard unless they map over. So RSpec has the context and then a description for it that goes with the test. Test::Unit has methods like method names instead. So it may be something like test redemption codes, and then it runs through the code. +Well, as I'm trying to migrate that knowledge over to RSpec, it's not clear to me what we're testing. Okay, we're testing redemption codes. What about them? Should they pass? Should they fail? Should they change? What are they redeeming? There's very little context. So a lot of my tests are copying that method name, so I know which tests I'm focused on, and I'm bringing over. +And then in the description, it's like, Steph needs help adding a test description, and then I'm pushing that up and then going to the team for help. So they can help me look through to understand, like, what is it that this test is doing? What's important about this domain? What sort of terminology should I include? And that has been working, but I didn't see that coming as part of this whole migrating stuff over. I really thought this might be a little bit more of a copypasta job. And I have learned some trickery is afoot. And it's been more complicated than I thought it was going to be. +CHRIS: Well, at a minimum, I can say thank you for sharing all of your hard-learned lessons throughout this process. This does sound arduous, but hopefully, at the end of it, there will be a lot of value and a cleaned-up test suite and all of those sorts of things. But yeah, it's been an adventure you've been on. So on behalf of the people who you are sharing all of these things with, thank you. +STEPH: Well, thank you. Yeah, I'm hoping this is very niche knowledge that there aren't many people in the world that are doing this exact work that this happens to be what this team needs. So yeah, it's been an adventure. I've certainly learned some things from it, and I still have more to go. So not there yet, but I'm also excited for when we can actually then delete this portion of the build process. +And then also, I think, get rid of fixtures because I didn't think about that from the beginning either. But now that I'm realizing that's how those tests are working, I suspect we'll be able to delete those. And that'll be really nice because now we also have another single source of truth in factory_bot as to how valid records are being built. +Mid-Roll Ad: +Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time. +Flaky tests slow everyone down, break your flow and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix them all today. So how do you know where to start? +BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! +And you can do the same because BuildPulse integrates with the tools you're already using. It supports all the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. +So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/ bikeshed. That's buildpulse.io/bikeshed. +Pivoting just a bit, there's a listener question that I'm really excited for us to dive into. And this listener question comes from Joël Quenneville. Hey, Joël. All right, so Joël writes in, "As senior-level developers, how do you set goals to ensure that you keep growing? How do you know what are high-value areas for you to improve? How do you stay sharp? Do you just keep adding new languages to your tool belt? Do you pull back and try to dig into more theoretical concepts? Do you feel like you have enough tech skills and pivot to other things like communication or management skills? +At the start of a dev career, there's an overwhelming list of things that it feels like you need to know all at once. Eventually, there comes a point where you no longer feel like you're drowning under the list of things that you need to learn. You're at least moderately competent in all the core concepts. So what's next?" This is a big, fun, scary question. I really like this question. Thank you, Joël, for sending it in because I think there's so much here that can be discussed. +I can kick us off with a few thoughts. I want to first highlight one of the things that...or one of the things that resonates with me from this question is how Joël describes going through and reaching senior status how it can really feel like working through a backlog of features. So as a developer, I want to understand this particular framework, or as a developer, I want to be able to write clear and fast tests, or as a developer, I want to contribute to an open-source project. But now that that backlog is empty, you're wondering what's next on your roadmap, which is where I think that sort of big, fun scariness comes into play. +So the first idea is to take a moment and embrace that success. You have probably worked really hard to get where you're at in your career. And there's nothing wrong with taking a pause and enjoying the view and just being appreciative of the fact that you are able to get your work done quickly or that you feel very confident in the work that you're doing. Growth is often very important to our careers, but I also think it's important to recognize when you've achieved certain growth and then, if you want to, just enjoy that and pause. And you're not constantly pushing yourself to the next level. I think that is a totally reasonable and healthy thing to do. +The second thing that comes to mind is that you're on a Choose Your Own Adventure mode now, so you get to...I would encourage folks, once you've reached this stage, to reflect on where you're at and consider what is your dream? What are your aspirations? Maybe they're related to tech; maybe they're not. And consider where is it that you want to go next? And then, what are the concrete steps that will help you achieve those goals? +So there's a really great article by Jen Dary, who's a career coach and owner of Plucky Manager Training, that describes this process. And there's a really great blog post that I'll be sure to include a link to in the show notes. But she has a couple of great questions that will then help you identify, like, what are my goals? Some of those questions are, "If I could do anything and money wasn't an object, I'd spend my time doing dot dot dot." And that doesn't necessarily mean sitting on a beach with your toes in the sand all day. I mean, it could, but then that probably just means you need a vacation. So take the vacation. +And then, once you start to get bored, where does your mind start to wander? What are the things that you want to do? Where are you interested in spending your time? And then, once you have an idea of how you'd like to spend your time, you can consider what actions you could take next that will point you in that direction. +There's also the benefit that by this point, you probably have an idea of the type of things that you like to do and where you like to spend your time. And so you can figure out which areas of expertise you want to invest in. So do you like more greenfield projects? Do you like architecture discussions? Do you like giving talks? Do you like teaching? Or maybe you're interested in management. I think there's also a more concrete approach that you can take that. +You can just talk to your managers in your team and say, "Hey, what big, hard problems are you looking to solve? And then, you can get some inspiration from them and see if their problems align with your interests. Maybe it's not even your own team, but you can talk to other companies and see what other problems industries are trying to solve. That might be an area that then spurs some curiosity or some interest. +And then, where do you feel underutilized? So with your current day-to-day, are there areas where you feel that you wish you had more responsibilities or more opportunities, but you feel like you don't have access to those opportunities? Maybe that's an area to explore as well. +This feels like a wonderful coaching question in terms of you have done it; congratulations. You've reached a really great spot in your career. And so now you're figuring out that big next step. This is going to be highly customized to each person to then figuring out what it is that's going to help you feel fulfilled over the next five years, ten years, however long you want to project out. Those are some of my thoughts. How about you? What do you think? +CHRIS: Well, first, those are some great thoughts. I appreciate that I get to follow them now. It's going to be a hard act to follow. But yeah, I think Joël has asked a fantastic question. And coming from Joël, I know how intentional and thoughtful a learner, and sharer, and teacher and all of these things are. So it's all the more sort of framed in that for me knowing Joël personally. +I think to start, the kernel of the question is as senior developers, that's the like...or senior level developers is the way Joël phrased it, but it treats it as sort of this discrete moment in time, which I think there's maybe even something to unpack. And I think we've probably talked about this in previous episodes, but like, what does that even mean? +And I think part of the story here is going from reactive where it's like, I don't know how anything works. I know a little bit. I can code some. And every day, I'm presented with new problems that I just don't understand. And I'm trying to build up that base of knowledge. Slowly, you know, you start, and it's like 95% of the time you feel like that. And slowly, the dial switches over, and maybe it's only 25% of the time you feel like that. +Somewhere along that spectrum is the line of senior developer. I don't actually know where it is, but it's somewhere in there. And so I think it's that space where you can move from reactive learning things as necessitated by the work that's coming at you to I want to proactively choose the things that I want to be learning to try and expand the stuff that I know, and the ways that I can think about the work without being in direct response to a piece of work coming at me. +So with that in mind, what do you do with this proactive space? And I think the way Joël frames the question, again, to what I know of Joël, he's such an intentional person. And I wouldn't be surprised if Joël is very purposeful and thinks about this and has approached it as a specific thing that he's doing. I have certainly been in more of “I'll figure it out when I get there.” I'll explore. +Or actually, probably the most pointed thing that I did was I joined a consultancy. And that was a very purposeful choice early on in my career because I'm like, I think I know a little bit. I don't think I know a lot. I would like to know a lot. That seems fun. So what do I think is the best way to do that? My guess, and it turned out to be very much true, is if I join a consultancy, I'm going to see a bunch of different projects, different types of technologies, organizations, communication structure, stuff that works, stuff that doesn't work. +And to be honest, I actually thought I would try out the consultancy thing for a little while, like a year or two, and then go on to my next adventure. Spoiler alert: I stayed for seven years. It was one of the best periods of my professional life. And I found it to be a much deeper well than I expected it to be. But for anyone that's looking for, like, how can I structure my career in a way that will just automatically provide the sort of novelty and space to grow? I would highly recommend a consultancy like thoughtbot. I wonder if they're hiring. +STEPH: Well, yes, we are hiring. That was a perfect plug that I wasn't expecting for that to come. But yes, thoughtbot is totally hiring. We'll include a link in the show notes to all the jobs. [laughs] +CHRIS: Sounds fantastic. But very sincerely, that was the best choice that I could have made and was a way to flip the situation around such that I don't have to be thinking about what I want to be learning. The learning will come to me. But even within that, I still tried to be intentional from time to time. And I would say, again, I don't have a holistic theory of how to improve. I just have some stuff that's kind of worked out well. One thing is focusing on fundamentals wherever I can, or a different way to put it is giving myself permission to spend a little bit more time whenever my work brushes up against what I would consider fundamentals. +So things that are in that space are like SQL. Every time I'm working on something, I'm like, ah, I could use like a CROSS JOIN here, but I don't know what that is. Maybe I'll spend an extra 30 minutes Googling around and trying to figure out what a CROSS JOIN is. Is that a thing? Is a CROSS JOIN a real thing? I may be making it up. [laughs] A window function, I know that those are real. Maybe I'll learn what a window function is. I think a CROSS JOIN is a real thing. A LEFT OUTER JOIN that's a cool thing. +And so, each time I've had that, SQL has been something that expanding my knowledge; I've continually felt like that was a good investment. Or fundamentals of HTTP, that's another one that really has served me well. With Ruby being the primary language that I program in, deeply understanding the language and the fundamentals and the semantics of it that's another place that has been a good investment. But by contrast, I would say I probably haven't gone as deep on the frameworks that I work with. So Rails is maybe a little bit different just because, like many people, I came to Ruby through Rails, and I've learned a lot of Rails. +But like in JavaScript, I've worked with many different JavaScript frameworks. And I have been a little more intentional with how much time I invest into furthering my skills in them because I've seen them change and evolve enough times. And if anything, I'm trying to look for ones that are like, what if it's less about the framework and more about JavaScript and web fundamentals underneath? Thus, I've found myself in Svelte land. But I think it's that choice of trying to anchor to fundamentals wherever possible. +And then I would say the other thing that's been really beneficial for me is what can I do that's wildly outside the stuff that I already know? And so probably the most pointed example I have of this is learning Elm. So I previously spent most of my career working in Ruby and JavaScript, so primarily object-oriented languages without a strong type system. And then, I was able to go over and experience this whole different paradigm way of working, way of structuring programs, feedback loop. There was so much about it that was really, really interesting. +And even though I don't get to work in Elm, frankly, as much as I would want at this point or really at all, it informs everything that I do moving forward. And I think that falls out of the fact that it was so different than what I was doing. So if I were to do that again, probably the next type of language I would learn is Lisp because those are like, well, that's a whole other category of thing that I've heard about. People say some fun stuff about them, but I don't really know. So it's that fundamentals and weird stuff is how I would describe it. And by weird, I mean outside of the core base of knowledge that I have. +STEPH: I love that categorization, and I'll stick with it, fundamentals and weird stuff, to stretch and grow and find some other areas. I also really like your framing, the reactive versus proactive. I think that's a really nice way to put it because so much of your career is you are just learning what your company needs you to learn, or you're learning what you need to keep progressing and to feel more competent with the types of features or the work that you're handling. +And I think that's why Jen Dary's blog post resonates with me so much because it's probably...up until now, a lot of someone's career, maybe not Joël's particularly, but I know probably for my career, a lot of it has been reactive in terms of what are the things that I need to learn? And so then once you reach that point of like, okay, I feel competent and reasonably good at all the things that I needed to know, where do I want to go next? +And rather than focus on necessarily the plans that are laid out in front of me, I can then go wide and think about what are some of the bigger things that I want to tackle? What are the things that are meaningful to me? Because then I can now push forward to this bigger goal versus achieving a particular salary band or title or things like that. But I can focus on something else that I really want to contribute to. +And there do seem to be two common paths. So once you reach that level, either you typically go into management, or you become that more like principal and then onward and upward, whatever is after principal. I don't even know what's after that, [laughs] but the titles that come after principal. So there's management, and then I've seen the other very strong contributors, so Aaron Patterson comes to mind. And I feel like those people then typically will migrate to places where they get to contribute to a language or to a framework. +And I think it comes down to the idea of impact because both of those provide a greater impact. So if you go into management, you can influence and affect a team of individuals, and you can increase the value created by that team. Then you've likely exceeded the value that you would have created as your own individual contributor. +Or, if you contribute to a language or a framework, then your technical decisions impact a larger community. So I think that would be another good thing to reflect on is what type of impact am I looking for? What type of communities do I want to have a positive impact on? And that may spur some inspiration around where you want to go next, the things that you want to focus on. +CHRIS: Yeah, I think one of the things we're picking up in that that Joël mentioned in his question is the idea of there is the individual contributor path. But then there's also the management path, which is the typical sort of that's the progression. And I think, for one, naming that the individual contributor path and the idea of going to principal dev and those sorts of outcomes is a fantastic path in and of itself. +I think often it's like, well, you know, you go along for a certain amount of time, and then you become a manager. It's like, those are actually distinctly different things. And people have different levels of interest and aptitude in them, and I think recognizing that is critically important. And so, not expecting that management just comes after individual contributor is an important thing. +The other thing I'll say is Charity Majors, who we had on the podcast a bit back, has a wonderful blog post about the pendulum swing called The Engineer/Manager Pendulum. And so in it, she talks about folks that have taken an exploration over into manager land and then come back to the individual contributor path or vice versa sort of being able to move between them, treating them as two potentially parallel career tracks but ones that we can move between. +And her assertion is that often folks that are particularly strong have spent some time in both camps because then you gain this empathy, this understanding of what's the whole picture? How are we doing all of this? How do we think about communication, et cetera? So, again, to name it, like, I think it's totally fine to stay on one of those tracks to really know which of those tracks speaks to you or to even move between them a little bit and to explore it and to find out what's true. +So we'll include a link to that in the show notes. And we'll also include a link to the previous episode a while back when we had Charity on. But yeah, those I think are some critical thoughts as well because those are different areas that we can grow as developers and expand on our impact within the team. And so, we want to make sure we have those options on the table as well. +STEPH: Absolutely. I love where teams will support individuals to feel comfortable shifting between experiences like that because it does make you a more well-rounded contributor to that product team, not just as an engineer, but then you will also understand what everybody else is working on and be able to have more meaningful conversations with them about the company goals and then the type of work that's being done. So yeah, I love it. +If you're in a place that you can maybe fail a little bit, hopefully not in a too painful way, but you can take a risk and say, "Hey, I want to try something and see if I like it," then I think that's wonderful. And take the risk and see how it goes. And just know that you have an exit strategy should you decide that you don't like that work or that type of work isn't for you. But at least now you know a little bit more about yourself. +Overall, I want to respond directly to something that Joël highlighted around how do you know what are high-value areas for you to improve? And I think there are two definitions there because you can either let the people around you and your team define that high value for you, and maybe that really resonates with you, and it's something that you enjoy. And so you can go to your manager and say, "Hey, what are some high-value areas where I can make an impact for the team?" +Or it could be very personal. And what are the high-value areas for you? Maybe there's a particular industry that you want to work on. Maybe you want to hit the public speaking circuit. And so you define more intrinsically what are those high-value areas for you? And I think that's a good place to start collecting feedback and start looking at what's high value for you personally and then what's high value to the company and see if there's any overlap there. +With that, I think we've covered a good variety of things to explore and then highlighted some of the different ways that you and I have also considered this question. I think it's a fabulous question. Also, I think it's one, even if you're not at that senior level, to ask this question. Like, go ahead and start asking it early and often and revisit your answers and see how they change. I think that would be a really powerful habit to establish early in your career and then could help guide you along, and then you can reflect on some of your earlier choices. So, Joël, thank you so much for that question. +STEPH: On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph and Chris are recording together! Like, in the same room, physically together.

+ +

Chris talks about slowly evolving the architecture in an app they're working on and settling on directory structure. Steph's still working on migrating unit tests over to RSpec.

+ +

They answer a listener question: "As senior-level developers, how do you set goals to ensure that you keep growing?"

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ +

Faking External Services In Tests With Adapters
+Testing Third-Party Interactions
+Jen Dary - On Future Goals
+Charity Majors - The Engineer Manager Pedulum
+Charity Majors Bike Shed Episode

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What is new in my world? Actually, this episode feels different. There's something different about it. I can't quite put my finger on it. I think it may be that we're actually physically in the same room recording for the first time in two years and a little bit more, which is wild.

+ +

STEPH: I can't believe it's been that long. I feel like it wasn't that long ago that we were in The Bike Shed...oh, I said The Bike Shed studio. I'm being very biased. Our recording studio [laughs] is the more proper description for it. Yeah, two and a half years. And we tried to make this happen a couple of months ago when I was visiting Boston, and then it just didn't work out. But today, we made it.

+ +

CHRIS: Today, we made it. Here we are. So hopefully, the audio sounds great, and we get all that more richness in conversation because of the physical in-person manner. We're trying it out. It'll be fun. But let's see, to the normal tech talk and nonsense, what's new in my world? So we've been slowly evolving the architecture in the app that we're working on. And we settled on something that I kind of like, so I wanted to talk about it, directory structure, probably the most interesting topic in the world. I think there's some good stuff in here.

+ +

So we have the normal stuff. There are app models, app controllers, all those; those make sense. We have app jobs which right now, I would say, is in a state of flux. We're in the sad place where some things are application records, and some things are Sidekiq workers. We have made the decision to consolidate everything onto Sidekiq workers, which is just strictly more powerful as to the direction we're going to go. But for right now, I'm not super happy with the state of app jobs, but whatever, we have that.

+ +

But the things that I like so we have app commands; I've talked about app commands before. Those are command objects. They use dry-rb do notation, and they allow us to sequence a bunch of things that all may fail, and we can process them all in a much more reasonable way. It's been really interesting exploring that, building on it, introducing it to new developers who haven't worked in that mode before. And everyone who's come into the project has both picked it up very quickly and enjoyed it, and found it to be a nice expressive mode. So app commands very happy with that.

+ +

App queries is another one that we have. We've talked about this before, query objects. I know we're a big fan. [laughs] I got a golf clap across the room here, which I could see live in person. It was amazing. I could feel the wind wafting across the room from the golf clap. [chuckles] But yeah, query objects, they're fantastic. They take a relation, they return a relation, but they allow us to build more complex queries outside of our models.

+ +

The new one, here we go. So this stuff would all normally fall into app services, which services don't mean anything. So we do not have an app services directory in our application. But the new one that we have is app clients. So these are all of our HTTP clients wrapping external third parties that we're interacting with. But with each of them, we've taken a particular structure, a particular approach. So for each of them, we're using the adapter pattern. There's a blog post on the Giant Robots blog that I can point to that sort of speaks to the adapter pattern that we're using here.

+ +

But basically, in production mode, there is an HTTP backend that actually makes the real requests and does all that stuff. And in test mode, there is a test backend for each of these clients that allows us to build up a pretty representative fake, and so we're faking it up before the HTTP layer. But we found that that's a good trade-off for us. And then we can say, like, if this fake backend gets a request to /users, then we can respond in whatever way that we want.

+ +

And overall, we found that pattern to be really fantastic. We've been very happy with it. So it's one more thing. All of them were just gathering in-app models. And so it was only very recently that we said no, no, these deserve their own name. They are a pattern. We've repeated this pattern a bunch. We like this pattern. We want to even embrace this pattern more, so long live app clients.

+ +

STEPH: I love it. I love app clients. It's been a while since I've been on a project that had that directory. But there was a greenfield project that I was working on. I think it might have been I was working with Boston.rb and working on giving them a new site or something like that and introduced app clients. And what you just said is perfect in terms of you've identified a pattern, and then you captured that and gave it its own directory to say, "Hey, this is our pattern. We've established it, and we really like it." That sounds awesome.

+ +

It's also really nice as someone who's new to a codebase; if I jump in and if I look at app clients, I can immediately see what are the third parties that we're working with? And that feels really nice. So yeah, that sounds great. I'm into it.

+ +

CHRIS: Yeah, I think it really was the question of like, is this a pattern we want to embrace and highlight within the codebase, or is this sort of a duplication but irrelevant like not really that important? And we decided no, this is a thing that matters. We currently have 17 of these clients, so 17 different third-party external things that we're integrating with. So for someone who doesn't really like service-oriented architecture, I do seem to have found myself in a place. But here we are, you know, we do what we have to with what we're given. But yes, 17 and growing our app clients.

+ +

STEPH: That is a lot. [laughs] My eyes widened a bit when you said 17. I'm curious because you highlighted that app services that's not really a thing. Like, it doesn't mean anything. It doesn't have the same meaning of the app queries directory or app commands or app clients where it's like, this is a pattern we've identified, and named, and want to propagate.

+ +

For app services, I agree; it's that junk drawer. But I guess in some ways...well, I'm going to say something, and then I'm going to decide how I feel about it. That feels useful because then, if you have something but you haven't established a pattern for it, you need a place for it to go. It still needs to live somewhere. And you don't necessarily want to put it in app models. So I'm curious, where do you put stuff that doesn't have an established pattern yet?

+ +

CHRIS: It's a good question. I think it's probably app models is our current answer. Like, these are things that model stuff. And I'm a big believer in the it doesn't need to be an application record-backed object to go on app models. But slowly, we've been taking stuff out. I think it'd be very common for what we talk about as query objects to just be methods in the respective application record. So the user record, as a great example, has all of these methods for doing any sort of query that you might want to do. And I'm a fan of extracting that out into this very specific place called app queries.

+ +

Commands are now another thing that I think very typically would fall into the app services place. Jobs naming that is something different. Clients we've got serializers is another one that we have at the top level, so those are four. We use Blueprinter within the app. And again, it's sort of weird. We don't really have an API. We're using Inertia. So we are still serializing to JSON across the boundary. And we found it was useful to encapsulate that. And so we have serializers as a directory, but they just do that. We do have policies. We're using Pundit for authorization, so that's another one that we have.

+ +

But yeah, I think the junk drawerness probably most goes to app models. But at this point, more and more, I feel like we have a place to put things. It's relatively clear should this be in a controller, or should this be in a query object, or should this be in a command? I think I'm finding a place of happiness that, frankly, I've been searching for for a long time. You could say my whole life I've been searching for this contented state of I think I know where stuff goes in the app, mostly, most of the time.

+ +

I'm just going to say this, and now that you've asked the excellent question of like, yeah, but no, where are you hiding some stuff? I'm going to open up models. Next week I’m going to be like, oh, I forgot about all of that nonsense. But the things that we have defined I'm very happy with.

+ +

STEPH: That feels really fair for app models. Because like you said, I agree that it doesn't need to be ActiveRecord-backed to go on app models. And so, if it needs to live somewhere, do you add a junk drawer, or do you just create app models and reuse that? And I think it makes a lot of sense to repurpose app models or to let things slide in there until you can extract them and let them live there until there's a pattern that you see.

+ +

CHRIS: We do. There's one more that I find hilarious, which is app lib, which my understanding...I remember at one point having one of those afternoons where I'm just like, I thought stuff works, but stuff doesn't seem to work. I thought lib was a directory in Rails apps. And it was like, oh no, now we autoload only under the app. So you should put lib under app. And I was just like, okay, whatever.

+ +

So we have app lib with very little in it. [laughs] But that isn't so much a junk drawer as it is stuff that's like, this doesn't feel specific to us. This goes somewhere else. This could be extracted from the app. But I just find it funny that we have an app lib. It just seems wrong.

+ +

STEPH: That feels like one of those directories that I've just accepted. Like, it's everywhere. It's like in all the apps that I work in. And so I've become very accustomed to it, and I haven't given it the same thoughtfulness that I think you have. I'm just like, yeah, it's another place to look. It's another place to go find some stuff. And then if I'm adding to it, yeah, I don't think I've been as thoughtful about it. But that makes sense that it's kind of silly that we have it, and that becomes like the junk drawer. If you're not careful with it, that's where you stick things.

+ +

CHRIS: I appreciate you're describing my point of view as thoughtfulness. I feel like I may actually be burdened with historical knowledge here because I worked on Rails apps long, long ago when lib didn't go in-app, and now it does. And I'm like, wait a minute, but like, no, no, it's fine. These are the libraries within your app. I can tell that story. So, again, thank you for saying that I was being thoughtful. I think I was just being persnickety, and get off my lawn is probably where I was at.

+ +

STEPH: Oh, full persnicketiness. Ooh, that's tough to say. [laughs]

+ +

CHRIS: But yeah, I just wanted to share that little summary, particularly the app clients is an interesting one. And again, I'll share the adapter pattern blog post because I think it's worked really well for us. And it's allowed us to slowly build up a more robust test suite. And so now our feature specs do a very good job of simulating the reality of the world while also dealing with the fact that we have these 17 external situations that we have to interact with.

+ +

And so, how do you balance that VCR versus other things? We've talked about this a bunch of times on different episodes. But app clients has worked great with the adapter pattern, so once more, rounding out our organizational approach. But yeah, that's what's up in my world. What's up in your world?

+ +

STEPH: So I have a small update to give. But before I do, you just made me think of something in regards to that article that talks about the adapter pattern. And there's also another article that's by Joël Quenneville that's testing third-party interactions. And he made me reflect on a time where I was giving the RSpec course, and we were talking about different ways to test third-party interactions. And there are a couple of different ways that are mentioned in this article. There are stub methods on adapter, stub HTTP request, stub request to fake adapter, and stub HTTP request to fake service. All that sounds like a lot. But if you read through the article, then it gives an example of each one.

+ +

But I've found it really helpful that if you're in a space that you still don't feel great about testing third-party interactions and you're not sure which approach to take; if you work with one API and apply all four different strategies, it really helps cement how to work through that process and the different benefits of each approach and the trade-offs. And we did that during the RSpec course, and I found it really helpful just from the teacher perspective to go through each one. And there were some great questions and discussions that came out of it.

+ +

So I wanted to put that plug out there in the world that if you're struggling testing third-party interactions, we'll include a link to this article. But I think that's a really solid way to build a great foundation of, like, I know how to test a third-party app. Let me choose which strategy that I want to use.

+ +

Circling back to what's going on in my world, I am still working on migrating unit tests over to RSpec. It's a thing. It's part of the work that I do. [laughs] I can't say it's particularly enjoyable, but it will have a positive payoff. And along that journey, I've learned some things or rediscovered some things. One of them is read expectations very carefully.

+ +

So when I was migrating a test over to RSpec, I read it as where we expected a record to exist. The test was actually testing that a record did not exist. And so I probably spent an hour understanding, going through the code being like, why isn't this record getting created like I expect it to? And I finally went back, and I took a break, and I went back. And I was like, oh, crap, I read the expectation wrong. So read expectations very carefully.

+ +

The other one...this one's not learned, but it is reinforced. Mystery Guests are awful. So as I've been porting over the behavior over to RSpec, the other tests are using fixtures, and I'm moving that over to use factory_bot instead. And at first, I was trying to be minimal with the data that I was bringing over. That failed pretty spectacularly. So I have learned now that I have to go and copy everything that's in the fixtures, and then I move it over to factory_bot. And it's painful, but at least then I'm doing that thing that we talked about before where I'm trying to load as little context as possible for each test.

+ +

But then once I do have a green test, I'm going back through it, and I'm like, okay, we probably don't care about when you were created. We probably don't care when you're updated because every field is set for every single record. So I am going back and then playing a game of if I remove this line, does the test still pass? And if I remove that line, does the test still pass? And so far, that has been painful, but it does have the benefit of then I'm removing some of the setup. So Mystery Guests are very painful.

+ +

I've also discovered that custom error messages can be tricky because I brought over some tests. And some of these, I'm realizing, are more user error than anything else. Anywho, I added one of the custom error messages that you can add, and I added it over to RSpec. But I had written an incorrect, invalid statement in RSpec where I was looking...I was expecting for a record to exist. But I was using the find by instead of where. So you can call exist on the ActiveRecord relation but not on the actual record that gets returned.

+ +

But I had the custom error message that was popping up and saying, "Oh, your record wasn't found," and I just kept getting that. So I was then diving through the code to understand again why my record wasn't found. And once I removed that custom error message, I realized that it was actually because of how I'd written the RSpec assertion that was wrong because then RSpec gave me a wonderful message that was like, hey, you're trying to call exist on this record, and you can't do that. Instead, you need to call it on a relation.

+ +

So I've also learned don't bring over custom error messages until you have a green test, and even then, consider if it's helpful because, frankly, the custom error message wasn't that helpful. It was very similar to what RSpec was going to tell us in general. So there was really no need to add that custom step to it.

+ +

For the final bit that I've learned or the hurdle that I've been facing is that migrating tests descriptions are hard unless they map over. So RSpec has the context and then a description for it that goes with the test. Test::Unit has methods like method names instead. So it may be something like test redemption codes, and then it runs through the code.

+ +

Well, as I'm trying to migrate that knowledge over to RSpec, it's not clear to me what we're testing. Okay, we're testing redemption codes. What about them? Should they pass? Should they fail? Should they change? What are they redeeming? There's very little context. So a lot of my tests are copying that method name, so I know which tests I'm focused on, and I'm bringing over.

+ +

And then in the description, it's like, Steph needs help adding a test description, and then I'm pushing that up and then going to the team for help. So they can help me look through to understand, like, what is it that this test is doing? What's important about this domain? What sort of terminology should I include? And that has been working, but I didn't see that coming as part of this whole migrating stuff over. I really thought this might be a little bit more of a copypasta job. And I have learned some trickery is afoot. And it's been more complicated than I thought it was going to be.

+ +

CHRIS: Well, at a minimum, I can say thank you for sharing all of your hard-learned lessons throughout this process. This does sound arduous, but hopefully, at the end of it, there will be a lot of value and a cleaned-up test suite and all of those sorts of things. But yeah, it's been an adventure you've been on. So on behalf of the people who you are sharing all of these things with, thank you.

+ +

STEPH: Well, thank you. Yeah, I'm hoping this is very niche knowledge that there aren't many people in the world that are doing this exact work that this happens to be what this team needs. So yeah, it's been an adventure. I've certainly learned some things from it, and I still have more to go. So not there yet, but I'm also excited for when we can actually then delete this portion of the build process.

+ +

And then also, I think, get rid of fixtures because I didn't think about that from the beginning either. But now that I'm realizing that's how those tests are working, I suspect we'll be able to delete those. And that'll be really nice because now we also have another single source of truth in factory_bot as to how valid records are being built.

+ +

Mid-Roll Ad:

+ +

Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix them all today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/ bikeshed. That's buildpulse.io/bikeshed.

+ +

Pivoting just a bit, there's a listener question that I'm really excited for us to dive into. And this listener question comes from Joël Quenneville. Hey, Joël. All right, so Joël writes in, "As senior-level developers, how do you set goals to ensure that you keep growing? How do you know what are high-value areas for you to improve? How do you stay sharp? Do you just keep adding new languages to your tool belt? Do you pull back and try to dig into more theoretical concepts? Do you feel like you have enough tech skills and pivot to other things like communication or management skills?

+ +

At the start of a dev career, there's an overwhelming list of things that it feels like you need to know all at once. Eventually, there comes a point where you no longer feel like you're drowning under the list of things that you need to learn. You're at least moderately competent in all the core concepts. So what's next?" This is a big, fun, scary question. I really like this question. Thank you, Joël, for sending it in because I think there's so much here that can be discussed.

+ +

I can kick us off with a few thoughts. I want to first highlight one of the things that...or one of the things that resonates with me from this question is how Joël describes going through and reaching senior status how it can really feel like working through a backlog of features. So as a developer, I want to understand this particular framework, or as a developer, I want to be able to write clear and fast tests, or as a developer, I want to contribute to an open-source project. But now that that backlog is empty, you're wondering what's next on your roadmap, which is where I think that sort of big, fun scariness comes into play.

+ +

So the first idea is to take a moment and embrace that success. You have probably worked really hard to get where you're at in your career. And there's nothing wrong with taking a pause and enjoying the view and just being appreciative of the fact that you are able to get your work done quickly or that you feel very confident in the work that you're doing. Growth is often very important to our careers, but I also think it's important to recognize when you've achieved certain growth and then, if you want to, just enjoy that and pause. And you're not constantly pushing yourself to the next level. I think that is a totally reasonable and healthy thing to do.

+ +

The second thing that comes to mind is that you're on a Choose Your Own Adventure mode now, so you get to...I would encourage folks, once you've reached this stage, to reflect on where you're at and consider what is your dream? What are your aspirations? Maybe they're related to tech; maybe they're not. And consider where is it that you want to go next? And then, what are the concrete steps that will help you achieve those goals?

+ +

So there's a really great article by Jen Dary, who's a career coach and owner of Plucky Manager Training, that describes this process. And there's a really great blog post that I'll be sure to include a link to in the show notes. But she has a couple of great questions that will then help you identify, like, what are my goals? Some of those questions are, "If I could do anything and money wasn't an object, I'd spend my time doing dot dot dot." And that doesn't necessarily mean sitting on a beach with your toes in the sand all day. I mean, it could, but then that probably just means you need a vacation. So take the vacation.

+ +

And then, once you start to get bored, where does your mind start to wander? What are the things that you want to do? Where are you interested in spending your time? And then, once you have an idea of how you'd like to spend your time, you can consider what actions you could take next that will point you in that direction.

+ +

There's also the benefit that by this point, you probably have an idea of the type of things that you like to do and where you like to spend your time. And so you can figure out which areas of expertise you want to invest in. So do you like more greenfield projects? Do you like architecture discussions? Do you like giving talks? Do you like teaching? Or maybe you're interested in management. I think there's also a more concrete approach that you can take that.

+ +

You can just talk to your managers in your team and say, "Hey, what big, hard problems are you looking to solve? And then, you can get some inspiration from them and see if their problems align with your interests. Maybe it's not even your own team, but you can talk to other companies and see what other problems industries are trying to solve. That might be an area that then spurs some curiosity or some interest.

+ +

And then, where do you feel underutilized? So with your current day-to-day, are there areas where you feel that you wish you had more responsibilities or more opportunities, but you feel like you don't have access to those opportunities? Maybe that's an area to explore as well.

+ +

This feels like a wonderful coaching question in terms of you have done it; congratulations. You've reached a really great spot in your career. And so now you're figuring out that big next step. This is going to be highly customized to each person to then figuring out what it is that's going to help you feel fulfilled over the next five years, ten years, however long you want to project out. Those are some of my thoughts. How about you? What do you think?

+ +

CHRIS: Well, first, those are some great thoughts. I appreciate that I get to follow them now. It's going to be a hard act to follow. But yeah, I think Joël has asked a fantastic question. And coming from Joël, I know how intentional and thoughtful a learner, and sharer, and teacher and all of these things are. So it's all the more sort of framed in that for me knowing Joël personally.

+ +

I think to start, the kernel of the question is as senior developers, that's the like...or senior level developers is the way Joël phrased it, but it treats it as sort of this discrete moment in time, which I think there's maybe even something to unpack. And I think we've probably talked about this in previous episodes, but like, what does that even mean?

+ +

And I think part of the story here is going from reactive where it's like, I don't know how anything works. I know a little bit. I can code some. And every day, I'm presented with new problems that I just don't understand. And I'm trying to build up that base of knowledge. Slowly, you know, you start, and it's like 95% of the time you feel like that. And slowly, the dial switches over, and maybe it's only 25% of the time you feel like that.

+ +

Somewhere along that spectrum is the line of senior developer. I don't actually know where it is, but it's somewhere in there. And so I think it's that space where you can move from reactive learning things as necessitated by the work that's coming at you to I want to proactively choose the things that I want to be learning to try and expand the stuff that I know, and the ways that I can think about the work without being in direct response to a piece of work coming at me.

+ +

So with that in mind, what do you do with this proactive space? And I think the way Joël frames the question, again, to what I know of Joël, he's such an intentional person. And I wouldn't be surprised if Joël is very purposeful and thinks about this and has approached it as a specific thing that he's doing. I have certainly been in more of “I'll figure it out when I get there.” I'll explore.

+ +

Or actually, probably the most pointed thing that I did was I joined a consultancy. And that was a very purposeful choice early on in my career because I'm like, I think I know a little bit. I don't think I know a lot. I would like to know a lot. That seems fun. So what do I think is the best way to do that? My guess, and it turned out to be very much true, is if I join a consultancy, I'm going to see a bunch of different projects, different types of technologies, organizations, communication structure, stuff that works, stuff that doesn't work.

+ +

And to be honest, I actually thought I would try out the consultancy thing for a little while, like a year or two, and then go on to my next adventure. Spoiler alert: I stayed for seven years. It was one of the best periods of my professional life. And I found it to be a much deeper well than I expected it to be. But for anyone that's looking for, like, how can I structure my career in a way that will just automatically provide the sort of novelty and space to grow? I would highly recommend a consultancy like thoughtbot. I wonder if they're hiring.

+ +

STEPH: Well, yes, we are hiring. That was a perfect plug that I wasn't expecting for that to come. But yes, thoughtbot is totally hiring. We'll include a link in the show notes to all the jobs. [laughs]

+ +

CHRIS: Sounds fantastic. But very sincerely, that was the best choice that I could have made and was a way to flip the situation around such that I don't have to be thinking about what I want to be learning. The learning will come to me. But even within that, I still tried to be intentional from time to time. And I would say, again, I don't have a holistic theory of how to improve. I just have some stuff that's kind of worked out well. One thing is focusing on fundamentals wherever I can, or a different way to put it is giving myself permission to spend a little bit more time whenever my work brushes up against what I would consider fundamentals.

+ +

So things that are in that space are like SQL. Every time I'm working on something, I'm like, ah, I could use like a CROSS JOIN here, but I don't know what that is. Maybe I'll spend an extra 30 minutes Googling around and trying to figure out what a CROSS JOIN is. Is that a thing? Is a CROSS JOIN a real thing? I may be making it up. [laughs] A window function, I know that those are real. Maybe I'll learn what a window function is. I think a CROSS JOIN is a real thing. A LEFT OUTER JOIN that's a cool thing.

+ +

And so, each time I've had that, SQL has been something that expanding my knowledge; I've continually felt like that was a good investment. Or fundamentals of HTTP, that's another one that really has served me well. With Ruby being the primary language that I program in, deeply understanding the language and the fundamentals and the semantics of it that's another place that has been a good investment. But by contrast, I would say I probably haven't gone as deep on the frameworks that I work with. So Rails is maybe a little bit different just because, like many people, I came to Ruby through Rails, and I've learned a lot of Rails.

+ +

But like in JavaScript, I've worked with many different JavaScript frameworks. And I have been a little more intentional with how much time I invest into furthering my skills in them because I've seen them change and evolve enough times. And if anything, I'm trying to look for ones that are like, what if it's less about the framework and more about JavaScript and web fundamentals underneath? Thus, I've found myself in Svelte land. But I think it's that choice of trying to anchor to fundamentals wherever possible.

+ +

And then I would say the other thing that's been really beneficial for me is what can I do that's wildly outside the stuff that I already know? And so probably the most pointed example I have of this is learning Elm. So I previously spent most of my career working in Ruby and JavaScript, so primarily object-oriented languages without a strong type system. And then, I was able to go over and experience this whole different paradigm way of working, way of structuring programs, feedback loop. There was so much about it that was really, really interesting.

+ +

And even though I don't get to work in Elm, frankly, as much as I would want at this point or really at all, it informs everything that I do moving forward. And I think that falls out of the fact that it was so different than what I was doing. So if I were to do that again, probably the next type of language I would learn is Lisp because those are like, well, that's a whole other category of thing that I've heard about. People say some fun stuff about them, but I don't really know. So it's that fundamentals and weird stuff is how I would describe it. And by weird, I mean outside of the core base of knowledge that I have.

+ +

STEPH: I love that categorization, and I'll stick with it, fundamentals and weird stuff, to stretch and grow and find some other areas. I also really like your framing, the reactive versus proactive. I think that's a really nice way to put it because so much of your career is you are just learning what your company needs you to learn, or you're learning what you need to keep progressing and to feel more competent with the types of features or the work that you're handling.

+ +

And I think that's why Jen Dary's blog post resonates with me so much because it's probably...up until now, a lot of someone's career, maybe not Joël's particularly, but I know probably for my career, a lot of it has been reactive in terms of what are the things that I need to learn? And so then once you reach that point of like, okay, I feel competent and reasonably good at all the things that I needed to know, where do I want to go next?

+ +

And rather than focus on necessarily the plans that are laid out in front of me, I can then go wide and think about what are some of the bigger things that I want to tackle? What are the things that are meaningful to me? Because then I can now push forward to this bigger goal versus achieving a particular salary band or title or things like that. But I can focus on something else that I really want to contribute to.

+ +

And there do seem to be two common paths. So once you reach that level, either you typically go into management, or you become that more like principal and then onward and upward, whatever is after principal. I don't even know what's after that, [laughs] but the titles that come after principal. So there's management, and then I've seen the other very strong contributors, so Aaron Patterson comes to mind. And I feel like those people then typically will migrate to places where they get to contribute to a language or to a framework.

+ +

And I think it comes down to the idea of impact because both of those provide a greater impact. So if you go into management, you can influence and affect a team of individuals, and you can increase the value created by that team. Then you've likely exceeded the value that you would have created as your own individual contributor.

+ +

Or, if you contribute to a language or a framework, then your technical decisions impact a larger community. So I think that would be another good thing to reflect on is what type of impact am I looking for? What type of communities do I want to have a positive impact on? And that may spur some inspiration around where you want to go next, the things that you want to focus on.

+ +

CHRIS: Yeah, I think one of the things we're picking up in that that Joël mentioned in his question is the idea of there is the individual contributor path. But then there's also the management path, which is the typical sort of that's the progression. And I think, for one, naming that the individual contributor path and the idea of going to principal dev and those sorts of outcomes is a fantastic path in and of itself.

+ +

I think often it's like, well, you know, you go along for a certain amount of time, and then you become a manager. It's like, those are actually distinctly different things. And people have different levels of interest and aptitude in them, and I think recognizing that is critically important. And so, not expecting that management just comes after individual contributor is an important thing.

+ +

The other thing I'll say is Charity Majors, who we had on the podcast a bit back, has a wonderful blog post about the pendulum swing called The Engineer/Manager Pendulum. And so in it, she talks about folks that have taken an exploration over into manager land and then come back to the individual contributor path or vice versa sort of being able to move between them, treating them as two potentially parallel career tracks but ones that we can move between.

+ +

And her assertion is that often folks that are particularly strong have spent some time in both camps because then you gain this empathy, this understanding of what's the whole picture? How are we doing all of this? How do we think about communication, et cetera? So, again, to name it, like, I think it's totally fine to stay on one of those tracks to really know which of those tracks speaks to you or to even move between them a little bit and to explore it and to find out what's true.

+ +

So we'll include a link to that in the show notes. And we'll also include a link to the previous episode a while back when we had Charity on. But yeah, those I think are some critical thoughts as well because those are different areas that we can grow as developers and expand on our impact within the team. And so, we want to make sure we have those options on the table as well.

+ +

STEPH: Absolutely. I love where teams will support individuals to feel comfortable shifting between experiences like that because it does make you a more well-rounded contributor to that product team, not just as an engineer, but then you will also understand what everybody else is working on and be able to have more meaningful conversations with them about the company goals and then the type of work that's being done. So yeah, I love it.

+ +

If you're in a place that you can maybe fail a little bit, hopefully not in a too painful way, but you can take a risk and say, "Hey, I want to try something and see if I like it," then I think that's wonderful. And take the risk and see how it goes. And just know that you have an exit strategy should you decide that you don't like that work or that type of work isn't for you. But at least now you know a little bit more about yourself.

+ +

Overall, I want to respond directly to something that Joël highlighted around how do you know what are high-value areas for you to improve? And I think there are two definitions there because you can either let the people around you and your team define that high value for you, and maybe that really resonates with you, and it's something that you enjoy. And so you can go to your manager and say, "Hey, what are some high-value areas where I can make an impact for the team?"

+ +

Or it could be very personal. And what are the high-value areas for you? Maybe there's a particular industry that you want to work on. Maybe you want to hit the public speaking circuit. And so you define more intrinsically what are those high-value areas for you? And I think that's a good place to start collecting feedback and start looking at what's high value for you personally and then what's high value to the company and see if there's any overlap there.

+ +

With that, I think we've covered a good variety of things to explore and then highlighted some of the different ways that you and I have also considered this question. I think it's a fabulous question. Also, I think it's one, even if you're not at that senior level, to ask this question. Like, go ahead and start asking it early and often and revisit your answers and see how they change. I think that would be a really powerful habit to establish early in your career and then could help guide you along, and then you can reflect on some of your earlier choices. So, Joël, thank you so much for that question.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph and Chris are recording together! Like, in the same room, physically together.

+ +

Chris talks about slowly evolving the architecture in an app they're working on and settling on directory structure. Steph's still working on migrating unit tests over to RSpec.

+ +

They answer a listener question: "As senior-level developers, how do you set goals to ensure that you keep growing?"

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ +

Faking External Services In Tests With Adapters
+Testing Third-Party Interactions
+Jen Dary - On Future Goals
+Charity Majors - The Engineer Manager Pedulum
+Charity Majors Bike Shed Episode

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What is new in my world? Actually, this episode feels different. There's something different about it. I can't quite put my finger on it. I think it may be that we're actually physically in the same room recording for the first time in two years and a little bit more, which is wild.

+ +

STEPH: I can't believe it's been that long. I feel like it wasn't that long ago that we were in The Bike Shed...oh, I said The Bike Shed studio. I'm being very biased. Our recording studio [laughs] is the more proper description for it. Yeah, two and a half years. And we tried to make this happen a couple of months ago when I was visiting Boston, and then it just didn't work out. But today, we made it.

+ +

CHRIS: Today, we made it. Here we are. So hopefully, the audio sounds great, and we get all that more richness in conversation because of the physical in-person manner. We're trying it out. It'll be fun. But let's see, to the normal tech talk and nonsense, what's new in my world? So we've been slowly evolving the architecture in the app that we're working on. And we settled on something that I kind of like, so I wanted to talk about it, directory structure, probably the most interesting topic in the world. I think there's some good stuff in here.

+ +

So we have the normal stuff. There are app models, app controllers, all those; those make sense. We have app jobs which right now, I would say, is in a state of flux. We're in the sad place where some things are application records, and some things are Sidekiq workers. We have made the decision to consolidate everything onto Sidekiq workers, which is just strictly more powerful as to the direction we're going to go. But for right now, I'm not super happy with the state of app jobs, but whatever, we have that.

+ +

But the things that I like so we have app commands; I've talked about app commands before. Those are command objects. They use dry-rb do notation, and they allow us to sequence a bunch of things that all may fail, and we can process them all in a much more reasonable way. It's been really interesting exploring that, building on it, introducing it to new developers who haven't worked in that mode before. And everyone who's come into the project has both picked it up very quickly and enjoyed it, and found it to be a nice expressive mode. So app commands very happy with that.

+ +

App queries is another one that we have. We've talked about this before, query objects. I know we're a big fan. [laughs] I got a golf clap across the room here, which I could see live in person. It was amazing. I could feel the wind wafting across the room from the golf clap. [chuckles] But yeah, query objects, they're fantastic. They take a relation, they return a relation, but they allow us to build more complex queries outside of our models.

+ +

The new one, here we go. So this stuff would all normally fall into app services, which services don't mean anything. So we do not have an app services directory in our application. But the new one that we have is app clients. So these are all of our HTTP clients wrapping external third parties that we're interacting with. But with each of them, we've taken a particular structure, a particular approach. So for each of them, we're using the adapter pattern. There's a blog post on the Giant Robots blog that I can point to that sort of speaks to the adapter pattern that we're using here.

+ +

But basically, in production mode, there is an HTTP backend that actually makes the real requests and does all that stuff. And in test mode, there is a test backend for each of these clients that allows us to build up a pretty representative fake, and so we're faking it up before the HTTP layer. But we found that that's a good trade-off for us. And then we can say, like, if this fake backend gets a request to /users, then we can respond in whatever way that we want.

+ +

And overall, we found that pattern to be really fantastic. We've been very happy with it. So it's one more thing. All of them were just gathering in-app models. And so it was only very recently that we said no, no, these deserve their own name. They are a pattern. We've repeated this pattern a bunch. We like this pattern. We want to even embrace this pattern more, so long live app clients.

+ +

STEPH: I love it. I love app clients. It's been a while since I've been on a project that had that directory. But there was a greenfield project that I was working on. I think it might have been I was working with Boston.rb and working on giving them a new site or something like that and introduced app clients. And what you just said is perfect in terms of you've identified a pattern, and then you captured that and gave it its own directory to say, "Hey, this is our pattern. We've established it, and we really like it." That sounds awesome.

+ +

It's also really nice as someone who's new to a codebase; if I jump in and if I look at app clients, I can immediately see what are the third parties that we're working with? And that feels really nice. So yeah, that sounds great. I'm into it.

+ +

CHRIS: Yeah, I think it really was the question of like, is this a pattern we want to embrace and highlight within the codebase, or is this sort of a duplication but irrelevant like not really that important? And we decided no, this is a thing that matters. We currently have 17 of these clients, so 17 different third-party external things that we're integrating with. So for someone who doesn't really like service-oriented architecture, I do seem to have found myself in a place. But here we are, you know, we do what we have to with what we're given. But yes, 17 and growing our app clients.

+ +

STEPH: That is a lot. [laughs] My eyes widened a bit when you said 17. I'm curious because you highlighted that app services that's not really a thing. Like, it doesn't mean anything. It doesn't have the same meaning of the app queries directory or app commands or app clients where it's like, this is a pattern we've identified, and named, and want to propagate.

+ +

For app services, I agree; it's that junk drawer. But I guess in some ways...well, I'm going to say something, and then I'm going to decide how I feel about it. That feels useful because then, if you have something but you haven't established a pattern for it, you need a place for it to go. It still needs to live somewhere. And you don't necessarily want to put it in app models. So I'm curious, where do you put stuff that doesn't have an established pattern yet?

+ +

CHRIS: It's a good question. I think it's probably app models is our current answer. Like, these are things that model stuff. And I'm a big believer in the it doesn't need to be an application record-backed object to go on app models. But slowly, we've been taking stuff out. I think it'd be very common for what we talk about as query objects to just be methods in the respective application record. So the user record, as a great example, has all of these methods for doing any sort of query that you might want to do. And I'm a fan of extracting that out into this very specific place called app queries.

+ +

Commands are now another thing that I think very typically would fall into the app services place. Jobs naming that is something different. Clients we've got serializers is another one that we have at the top level, so those are four. We use Blueprinter within the app. And again, it's sort of weird. We don't really have an API. We're using Inertia. So we are still serializing to JSON across the boundary. And we found it was useful to encapsulate that. And so we have serializers as a directory, but they just do that. We do have policies. We're using Pundit for authorization, so that's another one that we have.

+ +

But yeah, I think the junk drawerness probably most goes to app models. But at this point, more and more, I feel like we have a place to put things. It's relatively clear should this be in a controller, or should this be in a query object, or should this be in a command? I think I'm finding a place of happiness that, frankly, I've been searching for for a long time. You could say my whole life I've been searching for this contented state of I think I know where stuff goes in the app, mostly, most of the time.

+ +

I'm just going to say this, and now that you've asked the excellent question of like, yeah, but no, where are you hiding some stuff? I'm going to open up models. Next week I’m going to be like, oh, I forgot about all of that nonsense. But the things that we have defined I'm very happy with.

+ +

STEPH: That feels really fair for app models. Because like you said, I agree that it doesn't need to be ActiveRecord-backed to go on app models. And so, if it needs to live somewhere, do you add a junk drawer, or do you just create app models and reuse that? And I think it makes a lot of sense to repurpose app models or to let things slide in there until you can extract them and let them live there until there's a pattern that you see.

+ +

CHRIS: We do. There's one more that I find hilarious, which is app lib, which my understanding...I remember at one point having one of those afternoons where I'm just like, I thought stuff works, but stuff doesn't seem to work. I thought lib was a directory in Rails apps. And it was like, oh no, now we autoload only under the app. So you should put lib under app. And I was just like, okay, whatever.

+ +

So we have app lib with very little in it. [laughs] But that isn't so much a junk drawer as it is stuff that's like, this doesn't feel specific to us. This goes somewhere else. This could be extracted from the app. But I just find it funny that we have an app lib. It just seems wrong.

+ +

STEPH: That feels like one of those directories that I've just accepted. Like, it's everywhere. It's like in all the apps that I work in. And so I've become very accustomed to it, and I haven't given it the same thoughtfulness that I think you have. I'm just like, yeah, it's another place to look. It's another place to go find some stuff. And then if I'm adding to it, yeah, I don't think I've been as thoughtful about it. But that makes sense that it's kind of silly that we have it, and that becomes like the junk drawer. If you're not careful with it, that's where you stick things.

+ +

CHRIS: I appreciate you're describing my point of view as thoughtfulness. I feel like I may actually be burdened with historical knowledge here because I worked on Rails apps long, long ago when lib didn't go in-app, and now it does. And I'm like, wait a minute, but like, no, no, it's fine. These are the libraries within your app. I can tell that story. So, again, thank you for saying that I was being thoughtful. I think I was just being persnickety, and get off my lawn is probably where I was at.

+ +

STEPH: Oh, full persnicketiness. Ooh, that's tough to say. [laughs]

+ +

CHRIS: But yeah, I just wanted to share that little summary, particularly the app clients is an interesting one. And again, I'll share the adapter pattern blog post because I think it's worked really well for us. And it's allowed us to slowly build up a more robust test suite. And so now our feature specs do a very good job of simulating the reality of the world while also dealing with the fact that we have these 17 external situations that we have to interact with.

+ +

And so, how do you balance that VCR versus other things? We've talked about this a bunch of times on different episodes. But app clients has worked great with the adapter pattern, so once more, rounding out our organizational approach. But yeah, that's what's up in my world. What's up in your world?

+ +

STEPH: So I have a small update to give. But before I do, you just made me think of something in regards to that article that talks about the adapter pattern. And there's also another article that's by Joël Quenneville that's testing third-party interactions. And he made me reflect on a time where I was giving the RSpec course, and we were talking about different ways to test third-party interactions. And there are a couple of different ways that are mentioned in this article. There are stub methods on adapter, stub HTTP request, stub request to fake adapter, and stub HTTP request to fake service. All that sounds like a lot. But if you read through the article, then it gives an example of each one.

+ +

But I've found it really helpful that if you're in a space that you still don't feel great about testing third-party interactions and you're not sure which approach to take; if you work with one API and apply all four different strategies, it really helps cement how to work through that process and the different benefits of each approach and the trade-offs. And we did that during the RSpec course, and I found it really helpful just from the teacher perspective to go through each one. And there were some great questions and discussions that came out of it.

+ +

So I wanted to put that plug out there in the world that if you're struggling testing third-party interactions, we'll include a link to this article. But I think that's a really solid way to build a great foundation of, like, I know how to test a third-party app. Let me choose which strategy that I want to use.

+ +

Circling back to what's going on in my world, I am still working on migrating unit tests over to RSpec. It's a thing. It's part of the work that I do. [laughs] I can't say it's particularly enjoyable, but it will have a positive payoff. And along that journey, I've learned some things or rediscovered some things. One of them is read expectations very carefully.

+ +

So when I was migrating a test over to RSpec, I read it as where we expected a record to exist. The test was actually testing that a record did not exist. And so I probably spent an hour understanding, going through the code being like, why isn't this record getting created like I expect it to? And I finally went back, and I took a break, and I went back. And I was like, oh, crap, I read the expectation wrong. So read expectations very carefully.

+ +

The other one...this one's not learned, but it is reinforced. Mystery Guests are awful. So as I've been porting over the behavior over to RSpec, the other tests are using fixtures, and I'm moving that over to use factory_bot instead. And at first, I was trying to be minimal with the data that I was bringing over. That failed pretty spectacularly. So I have learned now that I have to go and copy everything that's in the fixtures, and then I move it over to factory_bot. And it's painful, but at least then I'm doing that thing that we talked about before where I'm trying to load as little context as possible for each test.

+ +

But then once I do have a green test, I'm going back through it, and I'm like, okay, we probably don't care about when you were created. We probably don't care when you're updated because every field is set for every single record. So I am going back and then playing a game of if I remove this line, does the test still pass? And if I remove that line, does the test still pass? And so far, that has been painful, but it does have the benefit of then I'm removing some of the setup. So Mystery Guests are very painful.

+ +

I've also discovered that custom error messages can be tricky because I brought over some tests. And some of these, I'm realizing, are more user error than anything else. Anywho, I added one of the custom error messages that you can add, and I added it over to RSpec. But I had written an incorrect, invalid statement in RSpec where I was looking...I was expecting for a record to exist. But I was using the find by instead of where. So you can call exist on the ActiveRecord relation but not on the actual record that gets returned.

+ +

But I had the custom error message that was popping up and saying, "Oh, your record wasn't found," and I just kept getting that. So I was then diving through the code to understand again why my record wasn't found. And once I removed that custom error message, I realized that it was actually because of how I'd written the RSpec assertion that was wrong because then RSpec gave me a wonderful message that was like, hey, you're trying to call exist on this record, and you can't do that. Instead, you need to call it on a relation.

+ +

So I've also learned don't bring over custom error messages until you have a green test, and even then, consider if it's helpful because, frankly, the custom error message wasn't that helpful. It was very similar to what RSpec was going to tell us in general. So there was really no need to add that custom step to it.

+ +

For the final bit that I've learned or the hurdle that I've been facing is that migrating tests descriptions are hard unless they map over. So RSpec has the context and then a description for it that goes with the test. Test::Unit has methods like method names instead. So it may be something like test redemption codes, and then it runs through the code.

+ +

Well, as I'm trying to migrate that knowledge over to RSpec, it's not clear to me what we're testing. Okay, we're testing redemption codes. What about them? Should they pass? Should they fail? Should they change? What are they redeeming? There's very little context. So a lot of my tests are copying that method name, so I know which tests I'm focused on, and I'm bringing over.

+ +

And then in the description, it's like, Steph needs help adding a test description, and then I'm pushing that up and then going to the team for help. So they can help me look through to understand, like, what is it that this test is doing? What's important about this domain? What sort of terminology should I include? And that has been working, but I didn't see that coming as part of this whole migrating stuff over. I really thought this might be a little bit more of a copypasta job. And I have learned some trickery is afoot. And it's been more complicated than I thought it was going to be.

+ +

CHRIS: Well, at a minimum, I can say thank you for sharing all of your hard-learned lessons throughout this process. This does sound arduous, but hopefully, at the end of it, there will be a lot of value and a cleaned-up test suite and all of those sorts of things. But yeah, it's been an adventure you've been on. So on behalf of the people who you are sharing all of these things with, thank you.

+ +

STEPH: Well, thank you. Yeah, I'm hoping this is very niche knowledge that there aren't many people in the world that are doing this exact work that this happens to be what this team needs. So yeah, it's been an adventure. I've certainly learned some things from it, and I still have more to go. So not there yet, but I'm also excited for when we can actually then delete this portion of the build process.

+ +

And then also, I think, get rid of fixtures because I didn't think about that from the beginning either. But now that I'm realizing that's how those tests are working, I suspect we'll be able to delete those. And that'll be really nice because now we also have another single source of truth in factory_bot as to how valid records are being built.

+ +

Mid-Roll Ad:

+ +

Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild, and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow and make things downright miserable. In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix them all today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/ bikeshed. That's buildpulse.io/bikeshed.

+ +

Pivoting just a bit, there's a listener question that I'm really excited for us to dive into. And this listener question comes from Joël Quenneville. Hey, Joël. All right, so Joël writes in, "As senior-level developers, how do you set goals to ensure that you keep growing? How do you know what are high-value areas for you to improve? How do you stay sharp? Do you just keep adding new languages to your tool belt? Do you pull back and try to dig into more theoretical concepts? Do you feel like you have enough tech skills and pivot to other things like communication or management skills?

+ +

At the start of a dev career, there's an overwhelming list of things that it feels like you need to know all at once. Eventually, there comes a point where you no longer feel like you're drowning under the list of things that you need to learn. You're at least moderately competent in all the core concepts. So what's next?" This is a big, fun, scary question. I really like this question. Thank you, Joël, for sending it in because I think there's so much here that can be discussed.

+ +

I can kick us off with a few thoughts. I want to first highlight one of the things that...or one of the things that resonates with me from this question is how Joël describes going through and reaching senior status how it can really feel like working through a backlog of features. So as a developer, I want to understand this particular framework, or as a developer, I want to be able to write clear and fast tests, or as a developer, I want to contribute to an open-source project. But now that that backlog is empty, you're wondering what's next on your roadmap, which is where I think that sort of big, fun scariness comes into play.

+ +

So the first idea is to take a moment and embrace that success. You have probably worked really hard to get where you're at in your career. And there's nothing wrong with taking a pause and enjoying the view and just being appreciative of the fact that you are able to get your work done quickly or that you feel very confident in the work that you're doing. Growth is often very important to our careers, but I also think it's important to recognize when you've achieved certain growth and then, if you want to, just enjoy that and pause. And you're not constantly pushing yourself to the next level. I think that is a totally reasonable and healthy thing to do.

+ +

The second thing that comes to mind is that you're on a Choose Your Own Adventure mode now, so you get to...I would encourage folks, once you've reached this stage, to reflect on where you're at and consider what is your dream? What are your aspirations? Maybe they're related to tech; maybe they're not. And consider where is it that you want to go next? And then, what are the concrete steps that will help you achieve those goals?

+ +

So there's a really great article by Jen Dary, who's a career coach and owner of Plucky Manager Training, that describes this process. And there's a really great blog post that I'll be sure to include a link to in the show notes. But she has a couple of great questions that will then help you identify, like, what are my goals? Some of those questions are, "If I could do anything and money wasn't an object, I'd spend my time doing dot dot dot." And that doesn't necessarily mean sitting on a beach with your toes in the sand all day. I mean, it could, but then that probably just means you need a vacation. So take the vacation.

+ +

And then, once you start to get bored, where does your mind start to wander? What are the things that you want to do? Where are you interested in spending your time? And then, once you have an idea of how you'd like to spend your time, you can consider what actions you could take next that will point you in that direction.

+ +

There's also the benefit that by this point, you probably have an idea of the type of things that you like to do and where you like to spend your time. And so you can figure out which areas of expertise you want to invest in. So do you like more greenfield projects? Do you like architecture discussions? Do you like giving talks? Do you like teaching? Or maybe you're interested in management. I think there's also a more concrete approach that you can take that.

+ +

You can just talk to your managers in your team and say, "Hey, what big, hard problems are you looking to solve? And then, you can get some inspiration from them and see if their problems align with your interests. Maybe it's not even your own team, but you can talk to other companies and see what other problems industries are trying to solve. That might be an area that then spurs some curiosity or some interest.

+ +

And then, where do you feel underutilized? So with your current day-to-day, are there areas where you feel that you wish you had more responsibilities or more opportunities, but you feel like you don't have access to those opportunities? Maybe that's an area to explore as well.

+ +

This feels like a wonderful coaching question in terms of you have done it; congratulations. You've reached a really great spot in your career. And so now you're figuring out that big next step. This is going to be highly customized to each person to then figuring out what it is that's going to help you feel fulfilled over the next five years, ten years, however long you want to project out. Those are some of my thoughts. How about you? What do you think?

+ +

CHRIS: Well, first, those are some great thoughts. I appreciate that I get to follow them now. It's going to be a hard act to follow. But yeah, I think Joël has asked a fantastic question. And coming from Joël, I know how intentional and thoughtful a learner, and sharer, and teacher and all of these things are. So it's all the more sort of framed in that for me knowing Joël personally.

+ +

I think to start, the kernel of the question is as senior developers, that's the like...or senior level developers is the way Joël phrased it, but it treats it as sort of this discrete moment in time, which I think there's maybe even something to unpack. And I think we've probably talked about this in previous episodes, but like, what does that even mean?

+ +

And I think part of the story here is going from reactive where it's like, I don't know how anything works. I know a little bit. I can code some. And every day, I'm presented with new problems that I just don't understand. And I'm trying to build up that base of knowledge. Slowly, you know, you start, and it's like 95% of the time you feel like that. And slowly, the dial switches over, and maybe it's only 25% of the time you feel like that.

+ +

Somewhere along that spectrum is the line of senior developer. I don't actually know where it is, but it's somewhere in there. And so I think it's that space where you can move from reactive learning things as necessitated by the work that's coming at you to I want to proactively choose the things that I want to be learning to try and expand the stuff that I know, and the ways that I can think about the work without being in direct response to a piece of work coming at me.

+ +

So with that in mind, what do you do with this proactive space? And I think the way Joël frames the question, again, to what I know of Joël, he's such an intentional person. And I wouldn't be surprised if Joël is very purposeful and thinks about this and has approached it as a specific thing that he's doing. I have certainly been in more of “I'll figure it out when I get there.” I'll explore.

+ +

Or actually, probably the most pointed thing that I did was I joined a consultancy. And that was a very purposeful choice early on in my career because I'm like, I think I know a little bit. I don't think I know a lot. I would like to know a lot. That seems fun. So what do I think is the best way to do that? My guess, and it turned out to be very much true, is if I join a consultancy, I'm going to see a bunch of different projects, different types of technologies, organizations, communication structure, stuff that works, stuff that doesn't work.

+ +

And to be honest, I actually thought I would try out the consultancy thing for a little while, like a year or two, and then go on to my next adventure. Spoiler alert: I stayed for seven years. It was one of the best periods of my professional life. And I found it to be a much deeper well than I expected it to be. But for anyone that's looking for, like, how can I structure my career in a way that will just automatically provide the sort of novelty and space to grow? I would highly recommend a consultancy like thoughtbot. I wonder if they're hiring.

+ +

STEPH: Well, yes, we are hiring. That was a perfect plug that I wasn't expecting for that to come. But yes, thoughtbot is totally hiring. We'll include a link in the show notes to all the jobs. [laughs]

+ +

CHRIS: Sounds fantastic. But very sincerely, that was the best choice that I could have made and was a way to flip the situation around such that I don't have to be thinking about what I want to be learning. The learning will come to me. But even within that, I still tried to be intentional from time to time. And I would say, again, I don't have a holistic theory of how to improve. I just have some stuff that's kind of worked out well. One thing is focusing on fundamentals wherever I can, or a different way to put it is giving myself permission to spend a little bit more time whenever my work brushes up against what I would consider fundamentals.

+ +

So things that are in that space are like SQL. Every time I'm working on something, I'm like, ah, I could use like a CROSS JOIN here, but I don't know what that is. Maybe I'll spend an extra 30 minutes Googling around and trying to figure out what a CROSS JOIN is. Is that a thing? Is a CROSS JOIN a real thing? I may be making it up. [laughs] A window function, I know that those are real. Maybe I'll learn what a window function is. I think a CROSS JOIN is a real thing. A LEFT OUTER JOIN that's a cool thing.

+ +

And so, each time I've had that, SQL has been something that expanding my knowledge; I've continually felt like that was a good investment. Or fundamentals of HTTP, that's another one that really has served me well. With Ruby being the primary language that I program in, deeply understanding the language and the fundamentals and the semantics of it that's another place that has been a good investment. But by contrast, I would say I probably haven't gone as deep on the frameworks that I work with. So Rails is maybe a little bit different just because, like many people, I came to Ruby through Rails, and I've learned a lot of Rails.

+ +

But like in JavaScript, I've worked with many different JavaScript frameworks. And I have been a little more intentional with how much time I invest into furthering my skills in them because I've seen them change and evolve enough times. And if anything, I'm trying to look for ones that are like, what if it's less about the framework and more about JavaScript and web fundamentals underneath? Thus, I've found myself in Svelte land. But I think it's that choice of trying to anchor to fundamentals wherever possible.

+ +

And then I would say the other thing that's been really beneficial for me is what can I do that's wildly outside the stuff that I already know? And so probably the most pointed example I have of this is learning Elm. So I previously spent most of my career working in Ruby and JavaScript, so primarily object-oriented languages without a strong type system. And then, I was able to go over and experience this whole different paradigm way of working, way of structuring programs, feedback loop. There was so much about it that was really, really interesting.

+ +

And even though I don't get to work in Elm, frankly, as much as I would want at this point or really at all, it informs everything that I do moving forward. And I think that falls out of the fact that it was so different than what I was doing. So if I were to do that again, probably the next type of language I would learn is Lisp because those are like, well, that's a whole other category of thing that I've heard about. People say some fun stuff about them, but I don't really know. So it's that fundamentals and weird stuff is how I would describe it. And by weird, I mean outside of the core base of knowledge that I have.

+ +

STEPH: I love that categorization, and I'll stick with it, fundamentals and weird stuff, to stretch and grow and find some other areas. I also really like your framing, the reactive versus proactive. I think that's a really nice way to put it because so much of your career is you are just learning what your company needs you to learn, or you're learning what you need to keep progressing and to feel more competent with the types of features or the work that you're handling.

+ +

And I think that's why Jen Dary's blog post resonates with me so much because it's probably...up until now, a lot of someone's career, maybe not Joël's particularly, but I know probably for my career, a lot of it has been reactive in terms of what are the things that I need to learn? And so then once you reach that point of like, okay, I feel competent and reasonably good at all the things that I needed to know, where do I want to go next?

+ +

And rather than focus on necessarily the plans that are laid out in front of me, I can then go wide and think about what are some of the bigger things that I want to tackle? What are the things that are meaningful to me? Because then I can now push forward to this bigger goal versus achieving a particular salary band or title or things like that. But I can focus on something else that I really want to contribute to.

+ +

And there do seem to be two common paths. So once you reach that level, either you typically go into management, or you become that more like principal and then onward and upward, whatever is after principal. I don't even know what's after that, [laughs] but the titles that come after principal. So there's management, and then I've seen the other very strong contributors, so Aaron Patterson comes to mind. And I feel like those people then typically will migrate to places where they get to contribute to a language or to a framework.

+ +

And I think it comes down to the idea of impact because both of those provide a greater impact. So if you go into management, you can influence and affect a team of individuals, and you can increase the value created by that team. Then you've likely exceeded the value that you would have created as your own individual contributor.

+ +

Or, if you contribute to a language or a framework, then your technical decisions impact a larger community. So I think that would be another good thing to reflect on is what type of impact am I looking for? What type of communities do I want to have a positive impact on? And that may spur some inspiration around where you want to go next, the things that you want to focus on.

+ +

CHRIS: Yeah, I think one of the things we're picking up in that that Joël mentioned in his question is the idea of there is the individual contributor path. But then there's also the management path, which is the typical sort of that's the progression. And I think, for one, naming that the individual contributor path and the idea of going to principal dev and those sorts of outcomes is a fantastic path in and of itself.

+ +

I think often it's like, well, you know, you go along for a certain amount of time, and then you become a manager. It's like, those are actually distinctly different things. And people have different levels of interest and aptitude in them, and I think recognizing that is critically important. And so, not expecting that management just comes after individual contributor is an important thing.

+ +

The other thing I'll say is Charity Majors, who we had on the podcast a bit back, has a wonderful blog post about the pendulum swing called The Engineer/Manager Pendulum. And so in it, she talks about folks that have taken an exploration over into manager land and then come back to the individual contributor path or vice versa sort of being able to move between them, treating them as two potentially parallel career tracks but ones that we can move between.

+ +

And her assertion is that often folks that are particularly strong have spent some time in both camps because then you gain this empathy, this understanding of what's the whole picture? How are we doing all of this? How do we think about communication, et cetera? So, again, to name it, like, I think it's totally fine to stay on one of those tracks to really know which of those tracks speaks to you or to even move between them a little bit and to explore it and to find out what's true.

+ +

So we'll include a link to that in the show notes. And we'll also include a link to the previous episode a while back when we had Charity on. But yeah, those I think are some critical thoughts as well because those are different areas that we can grow as developers and expand on our impact within the team. And so, we want to make sure we have those options on the table as well.

+ +

STEPH: Absolutely. I love where teams will support individuals to feel comfortable shifting between experiences like that because it does make you a more well-rounded contributor to that product team, not just as an engineer, but then you will also understand what everybody else is working on and be able to have more meaningful conversations with them about the company goals and then the type of work that's being done. So yeah, I love it.

+ +

If you're in a place that you can maybe fail a little bit, hopefully not in a too painful way, but you can take a risk and say, "Hey, I want to try something and see if I like it," then I think that's wonderful. And take the risk and see how it goes. And just know that you have an exit strategy should you decide that you don't like that work or that type of work isn't for you. But at least now you know a little bit more about yourself.

+ +

Overall, I want to respond directly to something that Joël highlighted around how do you know what are high-value areas for you to improve? And I think there are two definitions there because you can either let the people around you and your team define that high value for you, and maybe that really resonates with you, and it's something that you enjoy. And so you can go to your manager and say, "Hey, what are some high-value areas where I can make an impact for the team?"

+ +

Or it could be very personal. And what are the high-value areas for you? Maybe there's a particular industry that you want to work on. Maybe you want to hit the public speaking circuit. And so you define more intrinsically what are those high-value areas for you? And I think that's a good place to start collecting feedback and start looking at what's high value for you personally and then what's high value to the company and see if there's any overlap there.

+ +

With that, I think we've covered a good variety of things to explore and then highlighted some of the different ways that you and I have also considered this question. I think it's a fabulous question. Also, I think it's one, even if you're not at that senior level, to ask this question. Like, go ahead and start asking it early and often and revisit your answers and see how they change. I think that would be a really powerful habit to establish early in your career and then could help guide you along, and then you can reflect on some of your earlier choices. So, Joël, thank you so much for that question.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NDLzebfO + + ]]> + + Chris Toomey + Steph Viccari + + + 340: Solving People Problems with Rob Whittaker + https://bikeshed.thoughtbot.com/340 + 3acfe38b-4aad-4d22-af7d-759468c3eb56 + Tue, 31 May 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph is joined by a very special guest and fellow thoughtbotter, Rob Whittaker. + +Rob shares how he became the Software Development Director for Launchpad II, thoughtbot's Europe, Middle East, and Africa team. They also dive into what it's like to be a Development Director, the differences between mentoring and coaching, working with GitHub Codespaces, and strategies for boosting your creativity and problem solving capabilities. + 50:36 + no + + + Steph is joined by a very special guest and fellow thoughtbotter, Rob Whittaker. +Rob shares how he became the Software Development Director for Launchpad II, thoughtbot's Europe, Middle East, and Africa team. They also dive into what it's like to be a Development Director, the differences between mentoring and coaching, working with GitHub Codespaces, and strategies for boosting your creativity and problem solving capabilities. +thoughtbot is hiring! (https://thoughtbot.com/jobs) +ngrok (https://ngrok.com/) +Time Off Book (https://www.timeoffbook.com/) +Rob's Codespace Setup (https://github.com/purinkle/codespace) +Rob Whittaker on Twitter (https://twitter.com/purinkle) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker. +Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today. +ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is. +STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs] +ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is. +STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team. +ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II. +I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap. +So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up. +And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director. +The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot. +And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby. +I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize. +STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question. +So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director? +ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out. +So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point. +And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed. +And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction. +STEPH: I think the fancy term for that is just delegating. [laughs] +ROB: Yes, thank you. [laughs] +STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship. +And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career. +ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations. +Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary. +STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life. +So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in. +ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people. +STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that? +ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars. +And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates. +And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right. +But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying. +STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on. +But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process? +ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different. +The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for. +We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency. +STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings. +And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do. +ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess. +STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways. +ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days. +Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment. +STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities? +Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work. +ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that. +It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones. +And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine. +So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly. +So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment. +It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view. +STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally? +ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun. +And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup? +STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out. +Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too. +ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers. +And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something. +There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started? +I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago. +STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out. +And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not. +But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit. +GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work. +And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it? +And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it. +ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place. +So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service. +So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction. +Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with. +STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that. +ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting. +STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well. +ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than... +Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know. +STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week? +ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible. +As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water. +I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head. +And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done. +And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose. +The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available? +We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies. +But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room. +And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people. +STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier. +I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me. +And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit. +And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime. +I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone. +So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful. +ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else? +STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone. +ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification. +STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs] +Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers? +ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot. +But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down. +And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair." +One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people. +There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems. +STEPH: Have you found any helpful strategies to normalize that take a break culture? +ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from. +And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well. +A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together. +STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea. +On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk." +And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example. +ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards. +STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose? +ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer. +STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up. +Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that? +ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily. +And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you. +STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up? +ROB: Yeah, let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph is joined by a very special guest and fellow thoughtbotter, Rob Whittaker.

+ +

Rob shares how he became the Software Development Director for Launchpad II, thoughtbot's Europe, Middle East, and Africa team. They also dive into what it's like to be a Development Director, the differences between mentoring and coaching, working with GitHub Codespaces, and strategies for boosting your creativity and problem solving capabilities.

+ +
+ +

thoughtbot is hiring!
+ngrok
+Time Off Book
+Rob's Codespace Setup
+Rob Whittaker on Twitter

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker.

+ +

Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today.

+ +

ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is.

+ +

STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs]

+ +

ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is.

+ +

STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team.

+ +

ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II.

+ +

I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap.

+ +

So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up.

+ +

And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director.

+ +

The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot.

+ +

And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby.

+ +

I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize.

+ +

STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question.

+ +

So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director?

+ +

ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out.

+ +

So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point.

+ +

And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed.

+ +

And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction.

+ +

STEPH: I think the fancy term for that is just delegating. [laughs]

+ +

ROB: Yes, thank you. [laughs]

+ +

STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship.

+ +

And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career.
+ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations.

+ +

Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary.

+ +

STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life.

+ +

So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in.

+ +

ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people.

+ +

STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that?

+ +

ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars.

+ +

And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates.

+ +

And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right.

+ +

But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying.

+ +

STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on.

+ +

But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process?

+ +

ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different.

+ +

The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for.

+ +

We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency.

+ +

STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings.

+ +

And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do.

+ +

ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess.

+ +

STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways.

+ +

ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days.

+ +

Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment.

+ +

STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities?

+ +

Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work.

+ +

ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that.

+ +

It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones.

+ +

And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine.

+ +

So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly.

+ +

So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment.

+ +

It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view.

+ +

STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally?

+ +

ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun.

+ +

And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup?

+ +

STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out.

+ +

Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too.

+ +

ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers.

+ +

And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something.

+ +

There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started?

+ +

I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago.

+ +

STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out.

+ +

And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not.

+ +

But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit.

+ +

GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work.

+ +

And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it?

+ +

And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it.

+ +

ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place.

+ +

So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service.

+ +

So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction.

+ +

Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with.

+ +

STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that.

+ +

ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting.

+ +

STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well.

+ +

ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than...

+ +

Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know.

+ +

STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week?

+ +

ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible.

+ +

As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water.

+ +

I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head.

+ +

And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done.

+ +

And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose.

+ +

The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available?

+ +

We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies.

+ +

But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room.

+ +

And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people.

+ +

STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier.

+ +

I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me.

+ +

And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit.

+ +

And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime.

+ +

I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone.

+ +

So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful.

+ +

ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else?

+ +

STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone.

+ +

ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification.

+ +

STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs]

+ +

Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers?

+ +

ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot.

+ +

But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down.

+ +

And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair."

+ +

One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people.

+ +

There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems.

+ +

STEPH: Have you found any helpful strategies to normalize that take a break culture?

+ +

ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from.

+ +

And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well.

+ +

A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together.

+ +

STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea.

+ +

On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk."

+ +

And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example.

+ +

ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards.

+ +

STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose?

+ +

ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer.

+ +

STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up.

+ +

Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that?

+ +

ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily.

+ +

And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you.

+ +

STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up?

+ +

ROB: Yeah, let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Steph is joined by a very special guest and fellow thoughtbotter, Rob Whittaker.

+ +

Rob shares how he became the Software Development Director for Launchpad II, thoughtbot's Europe, Middle East, and Africa team. They also dive into what it's like to be a Development Director, the differences between mentoring and coaching, working with GitHub Codespaces, and strategies for boosting your creativity and problem solving capabilities.

+ +
+ +

thoughtbot is hiring!
+ngrok
+Time Off Book
+Rob's Codespace Setup
+Rob Whittaker on Twitter

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker.

+ +

Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today.

+ +

ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is.

+ +

STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs]

+ +

ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is.

+ +

STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team.

+ +

ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II.

+ +

I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap.

+ +

So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up.

+ +

And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director.

+ +

The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot.

+ +

And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby.

+ +

I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize.

+ +

STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question.

+ +

So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director?

+ +

ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out.

+ +

So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point.

+ +

And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed.

+ +

And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction.

+ +

STEPH: I think the fancy term for that is just delegating. [laughs]

+ +

ROB: Yes, thank you. [laughs]

+ +

STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship.

+ +

And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career.
+ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations.

+ +

Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary.

+ +

STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life.

+ +

So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in.

+ +

ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people.

+ +

STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that?

+ +

ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars.

+ +

And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates.

+ +

And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right.

+ +

But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying.

+ +

STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on.

+ +

But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process?

+ +

ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different.

+ +

The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for.

+ +

We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency.

+ +

STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings.

+ +

And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do.

+ +

ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess.

+ +

STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways.

+ +

ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days.

+ +

Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment.

+ +

STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities?

+ +

Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work.

+ +

ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that.

+ +

It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones.

+ +

And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine.

+ +

So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly.

+ +

So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment.

+ +

It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view.

+ +

STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally?

+ +

ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun.

+ +

And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup?

+ +

STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out.

+ +

Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too.

+ +

ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers.

+ +

And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something.

+ +

There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started?

+ +

I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago.

+ +

STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out.

+ +

And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not.

+ +

But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit.

+ +

GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work.

+ +

And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it?

+ +

And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it.

+ +

ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place.

+ +

So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service.

+ +

So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction.

+ +

Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with.

+ +

STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that.

+ +

ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting.

+ +

STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well.

+ +

ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than...

+ +

Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know.

+ +

STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week?

+ +

ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible.

+ +

As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water.

+ +

I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head.

+ +

And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done.

+ +

And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose.

+ +

The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available?

+ +

We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies.

+ +

But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room.

+ +

And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people.

+ +

STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier.

+ +

I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me.

+ +

And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit.

+ +

And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime.

+ +

I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone.

+ +

So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful.

+ +

ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else?

+ +

STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone.

+ +

ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification.

+ +

STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs]

+ +

Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers?

+ +

ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot.

+ +

But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down.

+ +

And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair."

+ +

One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people.

+ +

There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems.

+ +

STEPH: Have you found any helpful strategies to normalize that take a break culture?

+ +

ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from.

+ +

And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well.

+ +

A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together.

+ +

STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea.

+ +

On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk."

+ +

And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example.

+ +

ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards.

+ +

STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose?

+ +

ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer.

+ +

STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up.

+ +

Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that?

+ +

ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily.

+ +

And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you.

+ +

STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up?

+ +

ROB: Yeah, let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+dIYIpwby + + ]]> + + Steph Viccari + + + 339: What About Pictures? + https://bikeshed.thoughtbot.com/339 + fbede0fa-297b-427d-9bf1-1f33a9cce6df + Tue, 24 May 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec. + +Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure! + 45:03 + no + + + Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec. +Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure! +Page transitions Overview (https://youtu.be/JCJUPJ_zDQ4) +Using yield_self for composable ActiveRecord relations (https://thoughtbot.com/blog/using-yieldself-for-composable-activerecord-relations) +A Case for Query Objects in Rails (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) +Customer.io (https://customer.io/) +Turning the database inside-out with Apache Samza | Confluent (https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/) +Datomic (https://www.datomic.com/) +About CRDTs • Conflict-free Replicated Data Types (https://crdt.tech/) +Apache Kafka (https://kafka.apache.org/) +Resilient Management | A book for new managers in tech (https://resilient-management.com/) +Mixpanel: Product Analytics for Mobile, Web, & More (https://mixpanel.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're -- +STEPH: Oh, I have golden roads, yes. +[laughter] +CHRIS: You might should inform that you've got golden roads, yeah. +STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that. +CHRIS: [laughs] +STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it? +[laughter] +CHRIS: Do you want to fight? +STEPH: Yeah, are we going to fight? +CHRIS: I might could fight you. +STEPH: I might could. I might should. +[laughter] +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari. +But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming. +CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others? +STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those. +CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody. +STEPH: Oh, I'm behind. +CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it. +STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie. +CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene. +[laughter] +STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is. +CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs] +STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five. +CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie. +STEPH: Yeah, that would be death by Top Gun. +CHRIS: But not the normal way, the different, indirect death by Top Gun. +STEPH: I don't know what the normal way is. [laughs] +CHRIS: Like getting shot down by a Top Gun pilot. +[laughter] +STEPH: Yeah, that makes sense. [laughs] +CHRIS: You know, the dogfighting in the plane. +STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note. +And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec. +And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things. +But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name. +Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up. +But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over? +How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never. +CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles] +STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup. +CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior’s phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here... +I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise. +And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal. +But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it. +STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it. +And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do. +CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing. +STEPH: Cool. Well, that's a huge help to me. What's going on in your world? +CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well." +So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at. +But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty. +One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there. +And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this. +STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I? +[laughter] +CHRIS: What am I actually? +STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating. +CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly. +There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me. +Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures. +STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool. +CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures. +And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through. +So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting. +STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs] +CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs] +STEPH: No, raving. I will never forget now, raving. [laughs] +CHRIS: So, I mean, we've done this before. +STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends." +[laughter] +CHRIS: Actually, we got a handful of emails on that. +[laughter] +STEPH: Did you know the English language? +CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs] +But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it. +But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake. +Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph? +STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know. +CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still. +[laughter] +STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters. +So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it. +So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there. +And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it. +But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods. +So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by. +And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this? +CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic. +And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can. +The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before. +STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process. +Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time. +CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that. +STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world? +CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing. +Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event. +And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy. +As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set. +So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either. +There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream. +So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that. +And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together. +STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world. +And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next? +CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application. +So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit. +But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there. +There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It’s like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this. +But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out. +STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again? +While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world? +CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me. +We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it. +But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it. +STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next. +But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it would be great to own that. But that the other time if there's this other service that has already built that product and they're doing it super well, then let's keep letting them manage that portion of our business until we really need to bring it in-house. Because then we need to incorporate it more into our application itself so then we can surface things to the user. +That's the part where then I get really interested, or that's the pain point that I could see is if we wanted more of that behavior analysis, that then we want to surface that in the app, then always having to go to a third-party would start to feel tedious or could feel more brittle. +CHRIS: Yeah, I'm definitely 100% on not rebuilding Mixpanel in our app and being okay with the fact that we're sending that. Again, the thing that I did to make myself feel better about this is stream the data to S3 so that I have a version of it. And if we want to rebuild the data warehouse down the road to build some sort of machine learning data pipeline thing, we've got some raw data to work with. But I'm noticing lots of places where we're transforming a side effect, a behavior that we have in the system to dispatching an event. +And so right now, we have a bunch of stuff that we pipe over to Slack to inform our admin team, hey, this thing happened. You should probably intervene. But I'm looking at that, and we're doing it directly because we can control the message in Slack a little bit better. But I had this thought in the back of my mind; it's like, could we just send that as an event, and then some downstream tool can configure messages and alerts into Slack? Because then the admin team could actually instrument this themselves. And they could be like; we are no longer interested in this event. Users seem fine on that front. But we do care about this new event. +And all we need to do as the engineering team is properly instrument all of that event stream tapping. Every event just needs to get piped over. And then lots of powerful tools downstream from that that can allow different consumers of that data to do things, and broadly, that dispatch events, consume them on the other side, do fun stuff. That's the story. That's the dream. But I don't know; I can't connect all the dots. It's probably going to take me a couple of weeks to connect all these dots, or maybe years, or maybe my entire career, something like that. But, I don't know, I'm going to keep trying. +STEPH: This feels like a fun startup narrative, though, where you start by building the thing that people can interact with. As more people start to interact with it, how do we start giving more of our team the ability to then manage the product that then all of these users are interacting with? And then that's the part that you start optimizing for. So there are always different interesting bits when you talk about the different stages of Sagewell, and like, what's the thing you're optimizing for? And I'm sure it's still heavily users. But now there's also this addition of we are also optimizing for our team to now manage the product. +CHRIS: Yes, you're 100%. You're spot on there. We have definitely joked internally about spinning out a small company to build this analytics alerting tool [laughs] but obviously not going to do that because that's a distraction. And it is interesting, like, we want to build for the users the best thing that we can and where the admin team fits within that. To me, they're very much customers of engineering. Our job is to build the thing for the users but also, to be honest, we have to build a thing for the admins to support the users and exactly where that falls. +Like, you and I have talked a handful of times about maybe the admin isn't as polished in design as other things. But it's definitely tested because that's a critical part of how this application works. Maybe not directly for a user but one step removed for a user, so it matters. Absolutely we're writing tests to cover that behavior. And so yeah, those trade-offs are always interesting to me and exploring that space. But 100%: our admin team are core customers of the work that we're doing in engineering. And we try and stay very close and very friendly with them. +STEPH: Yeah, I really appreciate how you're framing that. And I very much agree and believe with you that our admin users are incredibly important. +CHRIS: Well, thank you. Yeah, we're trying over here. But yeah, I think I can wrap up that segment of me rambling about ideas that are half-formed in my mind but hopefully are directionally important. Anyway, what else is up with you? +STEPH: So, not that long ago, I asked you a question around how the heck to manage themes that I have going on. So we've talked about lots of fun productivity things around managing to-dos, and emails, and all that stuff. And my latest one is thinking about, like, I have a theme that I want to focus on, maybe it's this week, maybe it's for a couple of months. And how do I capture that and surface it to myself and see that I'm making progress on that? And I don't have an answer to that. +But I do have a theme that I wanted to share. And the one that I'm currently focused on is building up management skills and team lead skills. That is something that I'm focused on at the moment and partially because I was inspired to read the book Resilient Management written by Lara Hogan. And so I think that is what has really set the idea. But as I picked up the book, I was like, this is a really great book, and I'd really like to share some of this. And then so that grew into like, well, let's just go ahead and make this a theme where I'm learning this, and I'm sharing this with everyone else. +So along that note, I figured I would share that here. So we use Basecamp at thoughtbot. And so, I've been sharing some Basecamp posts around what I'm learning in each chapter. But to bring some of that knowledge here as well, some of the cool stuff that I have learned so far...and this is just still very early on in the book. There are a couple of different topics that Laura covers in the first chapter, and one of them is humans’ core needs at work. And then there's also the concept of meeting your team, some really good questions that you can ask during your first one-on-one to get to know the person that then you're going to be managing. +The part that really resonated with me and something that I would like to then coach myself to try is helping the team get to know you. So as a manager, not only are you going out of your way to really get to know that person, but how are you then helping them get to know you as well? Because then that's really going to help set that relationship in regards of they know what kind of things that you're optimizing for. Maybe you're optimizing for a deadline, or for business goals, or maybe it's for transparency, or maybe it would be helpful to communicate to someone that you're managing to say, "Hey, I'm trying some new management techniques. Let me know how this goes." [chuckles] +So there's a healthier relationship of not only are you learning them, but they're also learning you. So some of the questions that Laura includes as examples as something that you can share with your team is what do you optimize for in your role? So is it that you're optimizing for specific financial goals or building up teammates? Or maybe it's collaboration, so you're really looking for opportunities for people to pair together. +What do you want your teammates to lean on you for? I really liked that question. Like, what are some of the areas that bring you joy or something that you feel really skilled in that then you want people to come to you for? Because that's something that before I was a manager...but it's just as you are growing as a developer, that's such a great question of like, what do you want to be known for? What do you want to be that thing that when people think of, they're like, oh, you should go see Chris about this, or you should go see Steph about this? +And two other good questions include what are your work styles and preferences? And what management skills are you currently working on learning or improving? So I really like this concept of how can I share more of myself? And the great thing about this book that I'm learning too is while it is geared towards people that are managers, I think it's so wonderful for people who are non-managers or aspiring managers to read this as well because then it can help you manage whoever's managing you. So then that way, you can have some upward management. +So we had recent conversations around when you are new to a team and getting used to a manager, or maybe if you're a junior, you have to take a lot of self-advocacy into your role to make sure things are going well. And I think this book does a really good job for people that are looking to not only manage others but also manage themselves and manage upward. So that's some of the journeys from the first chapter. I'll keep you posted on the other chapters as I'm learning more. And yeah, if anybody hasn't read this book or if you're interested, I highly recommend it. I'll make sure to include a link in the show notes. +CHRIS: That was just the first chapter? +STEPH: Yeah, that was just the first chapter. +CHRIS: My goodness. +STEPH: And I shortened it drastically. [laughs] +CHRIS: Okay. All right, off to the races. But I think the summary that you gave there, particularly these are true when you're managing folks but also to manage yourself and to manage up, like, this is relevant to everyone in some capacity in some shape or form. And so that feels very true. +STEPH: I will include one more fun aspect from the book, and that's circling back to the humans' core needs at work. And she references Paloma Medina, a coach, and trainer who came up with this acronym. The acronym is BICEPS, and it stands for belonging, improvement, choice, equality, predictability, and significance. And then details how each of those are important to us in our work and how when one of those feels threatened, then that can lead to some problems at work or just even in our personal life. +But the fun example that she gave was not when there's a huge restructuring of the organization and things like that are going on as being the most concerning in terms of how many of these needs are going to be threatened or become vulnerable. But changing where someone sits at work can actually hit all of these, and it can threaten each of these needs. And it made me think, oh, cool, plus-one for being remote because we can sit wherever we want. [laughs] +But that was a really fun example of how someone's needs at work, I mean, just moving their desk, which resonates, too, because I've heard that from other people. Some of the friends that I have that work in more of a People Ops role talk about when they had to shift people around how that caused so much grief. And they were just shocked that it caused so much grief. And this explains why that can be such a big deal. So that was a fun example to read through. +CHRIS: I'm now having flashbacks to times where I was like, oh, I love my spot in the office. I love the people I'm sitting with. And then there was that day, and I had to move. Yeah, no, those were days. This is true. +STEPH: It triggered all the core BICEPS, all the things that you need to work. It threatened all of them. Or it could have improved them; who knows? +CHRIS: There were definitely those as well, yeah. Although I think it's harder to know that it's going to be great on the way in, so it's mostly negative. I think it has that weird bias because you're like, this was a thing, I knew it. I at least understood it. And then you're in a new space, and you're like, I don't know, is this going to be terrible or great? I mean, hopefully, it's only great because you work with great people, and it's a great office. [laughs] But, like, the unknown, you're moving into the unknown, and so I think it has an inherent at least questioning bias to it. +STEPH: Agreed. On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec.

+ +

Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure!

+ +
+ +

Page transitions Overview
+Using yield_self for composable ActiveRecord relations
+A Case for Query Objects in Rails
+Customer.io
+Turning the database inside-out with Apache Samza | Confluent
+Datomic
+About CRDTs • Conflict-free Replicated Data Types
+Apache Kafka
+Resilient Management | A book for new managers in tech
+Mixpanel: Product Analytics for Mobile, Web, & More

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're --

+ +

STEPH: Oh, I have golden roads, yes.

+ +

[laughter]

+ +

CHRIS: You might should inform that you've got golden roads, yeah.

+ +

STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that.

+ +

CHRIS: [laughs]

+ +

STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it?

+ +

[laughter]

+ +

CHRIS: Do you want to fight?

+ +

STEPH: Yeah, are we going to fight?

+ +

CHRIS: I might could fight you.

+ +

STEPH: I might could. I might should.

+ +

[laughter]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari.

+ +

But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming.

+ +

CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others?

+ +

STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those.

+ +

CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody.

+ +

STEPH: Oh, I'm behind.

+ +

CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it.

+ +

STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie.

+ +

CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene.

+ +

[laughter]

+ +

STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is.

+ +

CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs]

+ +

STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five.

+ +

CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie.

+ +

STEPH: Yeah, that would be death by Top Gun.

+ +

CHRIS: But not the normal way, the different, indirect death by Top Gun.

+ +

STEPH: I don't know what the normal way is. [laughs]

+ +

CHRIS: Like getting shot down by a Top Gun pilot.

+ +

[laughter]

+ +

STEPH: Yeah, that makes sense. [laughs]

+ +

CHRIS: You know, the dogfighting in the plane.

+ +

STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note.

+ +

And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec.

+ +

And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things.

+ +

But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name.

+ +

Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up.

+ +

But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over?

+ +

How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never.

+ +

CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles]

+ +

STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup.

+ +

CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior’s phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here...

+ +

I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise.

+ +

And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal.

+ +

But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it.

+ +

STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it.

+ +

And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do.

+ +

CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing.

+ +

STEPH: Cool. Well, that's a huge help to me. What's going on in your world?

+ +

CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well."

+ +

So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at.

+ +

But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty.

+ +

One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there.

+ +

And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this.

+ +

STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I?

+ +

[laughter]

+ +

CHRIS: What am I actually?

+ +

STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating.

+ +

CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly.

+ +

There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me.

+ +

Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures.

+ +

STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool.

+ +

CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures.

+ +

And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through.

+ +

So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting.

+ +

STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs]

+ +

CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs]

+ +

STEPH: No, raving. I will never forget now, raving. [laughs]

+ +

CHRIS: So, I mean, we've done this before.

+ +

STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends."

+ +

[laughter]

+ +

CHRIS: Actually, we got a handful of emails on that.

+ +

[laughter]

+ +

STEPH: Did you know the English language?

+ +

CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs]

+ +

But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it.

+ +

But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake.

+ +

Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph?

+ +

STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know.

+ +

CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still.

+ +

[laughter]

+ +

STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters.

+ +

So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it.

+ +

So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there.

+ +

And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it.

+ +

But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods.

+ +

So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by.

+ +

And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this?

+ +

CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic.

+ +

And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can.

+ +

The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before.

+ +

STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process.

+ +

Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time.

+ +

CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that.

+ +

STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world?

+ +

CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing.

+ +

Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event.

+ +

And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy.

+ +

As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set.

+ +

So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either.

+ +

There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream.

+ +

So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that.

+ +

And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together.

+ +

STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world.

+ +

And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next?

+ +

CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application.

+ +

So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit.

+ +

But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there.

+ +

There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It’s like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this.

+ +

But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out.

+ +

STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again?

+ +

While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world?

+ +

CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me.

+ +

We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it.

+ +

But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it.

+ +

STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next.

+ +

But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it would be great to own that. But that the other time if there's this other service that has already built that product and they're doing it super well, then let's keep letting them manage that portion of our business until we really need to bring it in-house. Because then we need to incorporate it more into our application itself so then we can surface things to the user.

+ +

That's the part where then I get really interested, or that's the pain point that I could see is if we wanted more of that behavior analysis, that then we want to surface that in the app, then always having to go to a third-party would start to feel tedious or could feel more brittle.

+ +

CHRIS: Yeah, I'm definitely 100% on not rebuilding Mixpanel in our app and being okay with the fact that we're sending that. Again, the thing that I did to make myself feel better about this is stream the data to S3 so that I have a version of it. And if we want to rebuild the data warehouse down the road to build some sort of machine learning data pipeline thing, we've got some raw data to work with. But I'm noticing lots of places where we're transforming a side effect, a behavior that we have in the system to dispatching an event.

+ +

And so right now, we have a bunch of stuff that we pipe over to Slack to inform our admin team, hey, this thing happened. You should probably intervene. But I'm looking at that, and we're doing it directly because we can control the message in Slack a little bit better. But I had this thought in the back of my mind; it's like, could we just send that as an event, and then some downstream tool can configure messages and alerts into Slack? Because then the admin team could actually instrument this themselves. And they could be like; we are no longer interested in this event. Users seem fine on that front. But we do care about this new event.

+ +

And all we need to do as the engineering team is properly instrument all of that event stream tapping. Every event just needs to get piped over. And then lots of powerful tools downstream from that that can allow different consumers of that data to do things, and broadly, that dispatch events, consume them on the other side, do fun stuff. That's the story. That's the dream. But I don't know; I can't connect all the dots. It's probably going to take me a couple of weeks to connect all these dots, or maybe years, or maybe my entire career, something like that. But, I don't know, I'm going to keep trying.

+ +

STEPH: This feels like a fun startup narrative, though, where you start by building the thing that people can interact with. As more people start to interact with it, how do we start giving more of our team the ability to then manage the product that then all of these users are interacting with? And then that's the part that you start optimizing for. So there are always different interesting bits when you talk about the different stages of Sagewell, and like, what's the thing you're optimizing for? And I'm sure it's still heavily users. But now there's also this addition of we are also optimizing for our team to now manage the product.

+ +

CHRIS: Yes, you're 100%. You're spot on there. We have definitely joked internally about spinning out a small company to build this analytics alerting tool [laughs] but obviously not going to do that because that's a distraction. And it is interesting, like, we want to build for the users the best thing that we can and where the admin team fits within that. To me, they're very much customers of engineering. Our job is to build the thing for the users but also, to be honest, we have to build a thing for the admins to support the users and exactly where that falls.

+ +

Like, you and I have talked a handful of times about maybe the admin isn't as polished in design as other things. But it's definitely tested because that's a critical part of how this application works. Maybe not directly for a user but one step removed for a user, so it matters. Absolutely we're writing tests to cover that behavior. And so yeah, those trade-offs are always interesting to me and exploring that space. But 100%: our admin team are core customers of the work that we're doing in engineering. And we try and stay very close and very friendly with them.

+ +

STEPH: Yeah, I really appreciate how you're framing that. And I very much agree and believe with you that our admin users are incredibly important.

+ +

CHRIS: Well, thank you. Yeah, we're trying over here. But yeah, I think I can wrap up that segment of me rambling about ideas that are half-formed in my mind but hopefully are directionally important. Anyway, what else is up with you?

+ +

STEPH: So, not that long ago, I asked you a question around how the heck to manage themes that I have going on. So we've talked about lots of fun productivity things around managing to-dos, and emails, and all that stuff. And my latest one is thinking about, like, I have a theme that I want to focus on, maybe it's this week, maybe it's for a couple of months. And how do I capture that and surface it to myself and see that I'm making progress on that? And I don't have an answer to that.

+ +

But I do have a theme that I wanted to share. And the one that I'm currently focused on is building up management skills and team lead skills. That is something that I'm focused on at the moment and partially because I was inspired to read the book Resilient Management written by Lara Hogan. And so I think that is what has really set the idea. But as I picked up the book, I was like, this is a really great book, and I'd really like to share some of this. And then so that grew into like, well, let's just go ahead and make this a theme where I'm learning this, and I'm sharing this with everyone else.

+ +

So along that note, I figured I would share that here. So we use Basecamp at thoughtbot. And so, I've been sharing some Basecamp posts around what I'm learning in each chapter. But to bring some of that knowledge here as well, some of the cool stuff that I have learned so far...and this is just still very early on in the book. There are a couple of different topics that Laura covers in the first chapter, and one of them is humans’ core needs at work. And then there's also the concept of meeting your team, some really good questions that you can ask during your first one-on-one to get to know the person that then you're going to be managing.

+ +

The part that really resonated with me and something that I would like to then coach myself to try is helping the team get to know you. So as a manager, not only are you going out of your way to really get to know that person, but how are you then helping them get to know you as well? Because then that's really going to help set that relationship in regards of they know what kind of things that you're optimizing for. Maybe you're optimizing for a deadline, or for business goals, or maybe it's for transparency, or maybe it would be helpful to communicate to someone that you're managing to say, "Hey, I'm trying some new management techniques. Let me know how this goes." [chuckles]

+ +

So there's a healthier relationship of not only are you learning them, but they're also learning you. So some of the questions that Laura includes as examples as something that you can share with your team is what do you optimize for in your role? So is it that you're optimizing for specific financial goals or building up teammates? Or maybe it's collaboration, so you're really looking for opportunities for people to pair together.

+ +

What do you want your teammates to lean on you for? I really liked that question. Like, what are some of the areas that bring you joy or something that you feel really skilled in that then you want people to come to you for? Because that's something that before I was a manager...but it's just as you are growing as a developer, that's such a great question of like, what do you want to be known for? What do you want to be that thing that when people think of, they're like, oh, you should go see Chris about this, or you should go see Steph about this?

+ +

And two other good questions include what are your work styles and preferences? And what management skills are you currently working on learning or improving? So I really like this concept of how can I share more of myself? And the great thing about this book that I'm learning too is while it is geared towards people that are managers, I think it's so wonderful for people who are non-managers or aspiring managers to read this as well because then it can help you manage whoever's managing you. So then that way, you can have some upward management.

+ +

So we had recent conversations around when you are new to a team and getting used to a manager, or maybe if you're a junior, you have to take a lot of self-advocacy into your role to make sure things are going well. And I think this book does a really good job for people that are looking to not only manage others but also manage themselves and manage upward. So that's some of the journeys from the first chapter. I'll keep you posted on the other chapters as I'm learning more. And yeah, if anybody hasn't read this book or if you're interested, I highly recommend it. I'll make sure to include a link in the show notes.

+ +

CHRIS: That was just the first chapter?

+ +

STEPH: Yeah, that was just the first chapter.

+ +

CHRIS: My goodness.

+ +

STEPH: And I shortened it drastically. [laughs]

+ +

CHRIS: Okay. All right, off to the races. But I think the summary that you gave there, particularly these are true when you're managing folks but also to manage yourself and to manage up, like, this is relevant to everyone in some capacity in some shape or form. And so that feels very true.

+ +

STEPH: I will include one more fun aspect from the book, and that's circling back to the humans' core needs at work. And she references Paloma Medina, a coach, and trainer who came up with this acronym. The acronym is BICEPS, and it stands for belonging, improvement, choice, equality, predictability, and significance. And then details how each of those are important to us in our work and how when one of those feels threatened, then that can lead to some problems at work or just even in our personal life.

+ +

But the fun example that she gave was not when there's a huge restructuring of the organization and things like that are going on as being the most concerning in terms of how many of these needs are going to be threatened or become vulnerable. But changing where someone sits at work can actually hit all of these, and it can threaten each of these needs. And it made me think, oh, cool, plus-one for being remote because we can sit wherever we want. [laughs]

+ +

But that was a really fun example of how someone's needs at work, I mean, just moving their desk, which resonates, too, because I've heard that from other people. Some of the friends that I have that work in more of a People Ops role talk about when they had to shift people around how that caused so much grief. And they were just shocked that it caused so much grief. And this explains why that can be such a big deal. So that was a fun example to read through.

+ +

CHRIS: I'm now having flashbacks to times where I was like, oh, I love my spot in the office. I love the people I'm sitting with. And then there was that day, and I had to move. Yeah, no, those were days. This is true.

+ +

STEPH: It triggered all the core BICEPS, all the things that you need to work. It threatened all of them. Or it could have improved them; who knows?

+ +

CHRIS: There were definitely those as well, yeah. Although I think it's harder to know that it's going to be great on the way in, so it's mostly negative. I think it has that weird bias because you're like, this was a thing, I knew it. I at least understood it. And then you're in a new space, and you're like, I don't know, is this going to be terrible or great? I mean, hopefully, it's only great because you work with great people, and it's a great office. [laughs] But, like, the unknown, you're moving into the unknown, and so I think it has an inherent at least questioning bias to it.

+ +

STEPH: Agreed. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec.

+ +

Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure!

+ +
+ +

Page transitions Overview
+Using yield_self for composable ActiveRecord relations
+A Case for Query Objects in Rails
+Customer.io
+Turning the database inside-out with Apache Samza | Confluent
+Datomic
+About CRDTs • Conflict-free Replicated Data Types
+Apache Kafka
+Resilient Management | A book for new managers in tech
+Mixpanel: Product Analytics for Mobile, Web, & More

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're --

+ +

STEPH: Oh, I have golden roads, yes.

+ +

[laughter]

+ +

CHRIS: You might should inform that you've got golden roads, yeah.

+ +

STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that.

+ +

CHRIS: [laughs]

+ +

STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it?

+ +

[laughter]

+ +

CHRIS: Do you want to fight?

+ +

STEPH: Yeah, are we going to fight?

+ +

CHRIS: I might could fight you.

+ +

STEPH: I might could. I might should.

+ +

[laughter]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari.

+ +

But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming.

+ +

CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others?

+ +

STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those.

+ +

CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody.

+ +

STEPH: Oh, I'm behind.

+ +

CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it.

+ +

STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie.

+ +

CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene.

+ +

[laughter]

+ +

STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is.

+ +

CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs]

+ +

STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five.

+ +

CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie.

+ +

STEPH: Yeah, that would be death by Top Gun.

+ +

CHRIS: But not the normal way, the different, indirect death by Top Gun.

+ +

STEPH: I don't know what the normal way is. [laughs]

+ +

CHRIS: Like getting shot down by a Top Gun pilot.

+ +

[laughter]

+ +

STEPH: Yeah, that makes sense. [laughs]

+ +

CHRIS: You know, the dogfighting in the plane.

+ +

STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note.

+ +

And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec.

+ +

And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things.

+ +

But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name.

+ +

Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up.

+ +

But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over?

+ +

How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never.

+ +

CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles]

+ +

STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup.

+ +

CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior’s phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here...

+ +

I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise.

+ +

And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal.

+ +

But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it.

+ +

STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it.

+ +

And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do.

+ +

CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing.

+ +

STEPH: Cool. Well, that's a huge help to me. What's going on in your world?

+ +

CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well."

+ +

So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at.

+ +

But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty.

+ +

One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there.

+ +

And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this.

+ +

STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I?

+ +

[laughter]

+ +

CHRIS: What am I actually?

+ +

STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating.

+ +

CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly.

+ +

There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me.

+ +

Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures.

+ +

STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool.

+ +

CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures.

+ +

And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through.

+ +

So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting.

+ +

STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs]

+ +

CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs]

+ +

STEPH: No, raving. I will never forget now, raving. [laughs]

+ +

CHRIS: So, I mean, we've done this before.

+ +

STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends."

+ +

[laughter]

+ +

CHRIS: Actually, we got a handful of emails on that.

+ +

[laughter]

+ +

STEPH: Did you know the English language?

+ +

CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs]

+ +

But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it.

+ +

But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake.

+ +

Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph?

+ +

STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know.

+ +

CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still.

+ +

[laughter]

+ +

STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters.

+ +

So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it.

+ +

So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there.

+ +

And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it.

+ +

But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods.

+ +

So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by.

+ +

And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this?

+ +

CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic.

+ +

And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can.

+ +

The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before.

+ +

STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process.

+ +

Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time.

+ +

CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that.

+ +

STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world?

+ +

CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing.

+ +

Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event.

+ +

And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy.

+ +

As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set.

+ +

So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either.

+ +

There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream.

+ +

So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that.

+ +

And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together.

+ +

STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world.

+ +

And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next?

+ +

CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application.

+ +

So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit.

+ +

But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there.

+ +

There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It’s like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this.

+ +

But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out.

+ +

STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again?

+ +

While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world?

+ +

CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me.

+ +

We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it.

+ +

But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it.

+ +

STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next.

+ +

But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it would be great to own that. But that the other time if there's this other service that has already built that product and they're doing it super well, then let's keep letting them manage that portion of our business until we really need to bring it in-house. Because then we need to incorporate it more into our application itself so then we can surface things to the user.

+ +

That's the part where then I get really interested, or that's the pain point that I could see is if we wanted more of that behavior analysis, that then we want to surface that in the app, then always having to go to a third-party would start to feel tedious or could feel more brittle.

+ +

CHRIS: Yeah, I'm definitely 100% on not rebuilding Mixpanel in our app and being okay with the fact that we're sending that. Again, the thing that I did to make myself feel better about this is stream the data to S3 so that I have a version of it. And if we want to rebuild the data warehouse down the road to build some sort of machine learning data pipeline thing, we've got some raw data to work with. But I'm noticing lots of places where we're transforming a side effect, a behavior that we have in the system to dispatching an event.

+ +

And so right now, we have a bunch of stuff that we pipe over to Slack to inform our admin team, hey, this thing happened. You should probably intervene. But I'm looking at that, and we're doing it directly because we can control the message in Slack a little bit better. But I had this thought in the back of my mind; it's like, could we just send that as an event, and then some downstream tool can configure messages and alerts into Slack? Because then the admin team could actually instrument this themselves. And they could be like; we are no longer interested in this event. Users seem fine on that front. But we do care about this new event.

+ +

And all we need to do as the engineering team is properly instrument all of that event stream tapping. Every event just needs to get piped over. And then lots of powerful tools downstream from that that can allow different consumers of that data to do things, and broadly, that dispatch events, consume them on the other side, do fun stuff. That's the story. That's the dream. But I don't know; I can't connect all the dots. It's probably going to take me a couple of weeks to connect all these dots, or maybe years, or maybe my entire career, something like that. But, I don't know, I'm going to keep trying.

+ +

STEPH: This feels like a fun startup narrative, though, where you start by building the thing that people can interact with. As more people start to interact with it, how do we start giving more of our team the ability to then manage the product that then all of these users are interacting with? And then that's the part that you start optimizing for. So there are always different interesting bits when you talk about the different stages of Sagewell, and like, what's the thing you're optimizing for? And I'm sure it's still heavily users. But now there's also this addition of we are also optimizing for our team to now manage the product.

+ +

CHRIS: Yes, you're 100%. You're spot on there. We have definitely joked internally about spinning out a small company to build this analytics alerting tool [laughs] but obviously not going to do that because that's a distraction. And it is interesting, like, we want to build for the users the best thing that we can and where the admin team fits within that. To me, they're very much customers of engineering. Our job is to build the thing for the users but also, to be honest, we have to build a thing for the admins to support the users and exactly where that falls.

+ +

Like, you and I have talked a handful of times about maybe the admin isn't as polished in design as other things. But it's definitely tested because that's a critical part of how this application works. Maybe not directly for a user but one step removed for a user, so it matters. Absolutely we're writing tests to cover that behavior. And so yeah, those trade-offs are always interesting to me and exploring that space. But 100%: our admin team are core customers of the work that we're doing in engineering. And we try and stay very close and very friendly with them.

+ +

STEPH: Yeah, I really appreciate how you're framing that. And I very much agree and believe with you that our admin users are incredibly important.

+ +

CHRIS: Well, thank you. Yeah, we're trying over here. But yeah, I think I can wrap up that segment of me rambling about ideas that are half-formed in my mind but hopefully are directionally important. Anyway, what else is up with you?

+ +

STEPH: So, not that long ago, I asked you a question around how the heck to manage themes that I have going on. So we've talked about lots of fun productivity things around managing to-dos, and emails, and all that stuff. And my latest one is thinking about, like, I have a theme that I want to focus on, maybe it's this week, maybe it's for a couple of months. And how do I capture that and surface it to myself and see that I'm making progress on that? And I don't have an answer to that.

+ +

But I do have a theme that I wanted to share. And the one that I'm currently focused on is building up management skills and team lead skills. That is something that I'm focused on at the moment and partially because I was inspired to read the book Resilient Management written by Lara Hogan. And so I think that is what has really set the idea. But as I picked up the book, I was like, this is a really great book, and I'd really like to share some of this. And then so that grew into like, well, let's just go ahead and make this a theme where I'm learning this, and I'm sharing this with everyone else.

+ +

So along that note, I figured I would share that here. So we use Basecamp at thoughtbot. And so, I've been sharing some Basecamp posts around what I'm learning in each chapter. But to bring some of that knowledge here as well, some of the cool stuff that I have learned so far...and this is just still very early on in the book. There are a couple of different topics that Laura covers in the first chapter, and one of them is humans’ core needs at work. And then there's also the concept of meeting your team, some really good questions that you can ask during your first one-on-one to get to know the person that then you're going to be managing.

+ +

The part that really resonated with me and something that I would like to then coach myself to try is helping the team get to know you. So as a manager, not only are you going out of your way to really get to know that person, but how are you then helping them get to know you as well? Because then that's really going to help set that relationship in regards of they know what kind of things that you're optimizing for. Maybe you're optimizing for a deadline, or for business goals, or maybe it's for transparency, or maybe it would be helpful to communicate to someone that you're managing to say, "Hey, I'm trying some new management techniques. Let me know how this goes." [chuckles]

+ +

So there's a healthier relationship of not only are you learning them, but they're also learning you. So some of the questions that Laura includes as examples as something that you can share with your team is what do you optimize for in your role? So is it that you're optimizing for specific financial goals or building up teammates? Or maybe it's collaboration, so you're really looking for opportunities for people to pair together.

+ +

What do you want your teammates to lean on you for? I really liked that question. Like, what are some of the areas that bring you joy or something that you feel really skilled in that then you want people to come to you for? Because that's something that before I was a manager...but it's just as you are growing as a developer, that's such a great question of like, what do you want to be known for? What do you want to be that thing that when people think of, they're like, oh, you should go see Chris about this, or you should go see Steph about this?

+ +

And two other good questions include what are your work styles and preferences? And what management skills are you currently working on learning or improving? So I really like this concept of how can I share more of myself? And the great thing about this book that I'm learning too is while it is geared towards people that are managers, I think it's so wonderful for people who are non-managers or aspiring managers to read this as well because then it can help you manage whoever's managing you. So then that way, you can have some upward management.

+ +

So we had recent conversations around when you are new to a team and getting used to a manager, or maybe if you're a junior, you have to take a lot of self-advocacy into your role to make sure things are going well. And I think this book does a really good job for people that are looking to not only manage others but also manage themselves and manage upward. So that's some of the journeys from the first chapter. I'll keep you posted on the other chapters as I'm learning more. And yeah, if anybody hasn't read this book or if you're interested, I highly recommend it. I'll make sure to include a link in the show notes.

+ +

CHRIS: That was just the first chapter?

+ +

STEPH: Yeah, that was just the first chapter.

+ +

CHRIS: My goodness.

+ +

STEPH: And I shortened it drastically. [laughs]

+ +

CHRIS: Okay. All right, off to the races. But I think the summary that you gave there, particularly these are true when you're managing folks but also to manage yourself and to manage up, like, this is relevant to everyone in some capacity in some shape or form. And so that feels very true.

+ +

STEPH: I will include one more fun aspect from the book, and that's circling back to the humans' core needs at work. And she references Paloma Medina, a coach, and trainer who came up with this acronym. The acronym is BICEPS, and it stands for belonging, improvement, choice, equality, predictability, and significance. And then details how each of those are important to us in our work and how when one of those feels threatened, then that can lead to some problems at work or just even in our personal life.

+ +

But the fun example that she gave was not when there's a huge restructuring of the organization and things like that are going on as being the most concerning in terms of how many of these needs are going to be threatened or become vulnerable. But changing where someone sits at work can actually hit all of these, and it can threaten each of these needs. And it made me think, oh, cool, plus-one for being remote because we can sit wherever we want. [laughs]

+ +

But that was a really fun example of how someone's needs at work, I mean, just moving their desk, which resonates, too, because I've heard that from other people. Some of the friends that I have that work in more of a People Ops role talk about when they had to shift people around how that caused so much grief. And they were just shocked that it caused so much grief. And this explains why that can be such a big deal. So that was a fun example to read through.

+ +

CHRIS: I'm now having flashbacks to times where I was like, oh, I love my spot in the office. I love the people I'm sitting with. And then there was that day, and I had to move. Yeah, no, those were days. This is true.

+ +

STEPH: It triggered all the core BICEPS, all the things that you need to work. It threatened all of them. Or it could have improved them; who knows?

+ +

CHRIS: There were definitely those as well, yeah. Although I think it's harder to know that it's going to be great on the way in, so it's mostly negative. I think it has that weird bias because you're like, this was a thing, I knew it. I at least understood it. And then you're in a new space, and you're like, I don't know, is this going to be terrible or great? I mean, hopefully, it's only great because you work with great people, and it's a great office. [laughs] But, like, the unknown, you're moving into the unknown, and so I think it has an inherent at least questioning bias to it.

+ +

STEPH: Agreed. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+HpRORT07 + + ]]> + + Chris Toomey + Steph Viccari + + + 338: Meticulously Wrong + https://bikeshed.thoughtbot.com/338 + 1e75519f-cd76-444e-8bd1-a60d1f1e7163 + Tue, 17 May 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris switched from Trello over to Linear for product management and talks about prioritizing backlogs. + +Steph shares and discusses a tweet from Curtis Einsmann that super resonated with the work she's doing right now: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one." + 45:52 + no + + + Chris switched from Trello over to Linear for product management and talks about prioritizing backlogs. +Steph shares and discusses a tweet from Curtis Einsmann that super resonated with the work she's doing right now: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one." +This episode is brought to you by BuildPulse (https://buildpulse.io/bikeshed). Start your 14-day free trial of BuildPulse today. +Linear (https://linear.app/) +Curtis Einsmann Tweet (https://twitter.com/curtiseinsmann/status/1521451508943843329) +Louie Bacaj Tweet (https://twitter.com/LBacaj/status/1478241322637033474?s=20) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild and you wait. Again. And you hope you're lucky enough to get a passing build this time. +Flaky tests slow everyone down, break your flow and make things downright miserable. +In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix them all today. So how do you know where to start? +BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month! +And you can do the same because BuildPulse integrates with the tools you're already using. It supports all the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more. +So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed. +CHRIS: Good morning, and welcome to Tech Talk with Steph and Chris. Today at the top of the hour, it's tech traffic hits. +STEPH: Ooh, tech traffic. [laughs] I like that statement. +CHRIS: Yeah. The Git lanes are clogged up with...I don't know. I got nothing. +STEPH: [laughs] +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? +CHRIS: What's new in my world? Actually, I have a specific new thing that I can share, which is, as of the past week, I would say, switched from Trello over to Linear for product management. It's been great. It was a super straightforward transfer. They actually had an importer. We lost some of the comment threads on the Trello cards. But that was easy enough to like each Linear ticket has a link back to Trello. So it's easy enough to keep the continuity. +But yeah, we're in a whole new world, a system actually built for maintaining a product backlog, and, man, it shows. Trello was a bunch of lists and cards and stuff that you could link between, which was cool. But Linear is just much more purpose-built and already very, very nice. And we're very happy with the switch. +STEPH: I feel like you came in real casual with that news, but that is big news, that you did a switch. +[laughter] +CHRIS: How are you going to bury the lead like that? You switched project management...[laughter] I actually didn't think it was...I'm excited about it but low-key excited, which is weird because I do like productivity and task management software. So you would think I would be really excited about this. But I've also tried enough of them historically to know that that's never going to be the thing that actually makes or breaks your team's productivity. It can make things worse, but it can't make you great. That's the thing that I believe. And so it's a wonderful piece of software. I'm very excited about it but -- +STEPH: Ooh, I like that. It can make you worse, but it doesn't make you great. That's so true, yeah, where it causes pain. Well, and it does make sense. You've been complaining a bit about the whole login with Trello and how that's been frustrating. But I haven't even heard of Linear. That's just...that's, I mean, you're just doing what you do where you bring that new-new. I haven't heard of Linear before. +CHRIS: I try to live on the cutting edge. Actually, I deeply try to not live on the cutting edge at this point in my life. That early adopter wave, no, no, no, that's not for me anymore. But I've known a few folks who've moved to Linear. And everyone that I've spoken to who has moved to it has been like, "Yeah, it's been great." I've not heard anything negative. And I've heard or experienced negative things about every other product management tool out there. And so, it seemed like an easy thing. +And it was a low-cost enough switch in terms of opportunity costs or the like, it took the effort of someone on our team moving those cards over and setting up the new system and training, but it was relatively straightforward. And yeah, we're super happy with it. And it feels different now. I feel like I can see the work in a different way which is interesting. +I think we had brought in a Chrome extension for Trello. I think it's like Hello Epics or something like that that allows...it abuses the card linking functionality in Trello and repurchases that feature as an epic management thing. But it's quarter-baked is how I would describe it, or it's clearly built on top of existing things that were not intended to be used exactly in that way. So it does a great job. Hello Epics does a great job of trying to make something like parent-child list management stuff happen in Trello. But it's always going feel like an afterthought, a secondary feature, something that's bolted on. +Whereas in Linear, it's like, no, no, we absolutely have the idea of projects, of course, and you can see burndown charts and things. And the thing that I do want to be careful about is not leaning too much into management. Linear has the idea of cycles or sprints, as many other folks think of them, or iterations or whatever you want to call them. But we've largely not been working in that mode. We've just continued to work through the next up list; that's it. The next up list should be prioritized and well defined at the top and roughly in priority order. So just pick up the next card and work on it. And we just do that every single day. +And now we're in a piece of software that has the idea of cycles, and I'm like, oh, this is vaguely interesting. Do we want to do that? Oh, but if you're going to do that, you probably do some estimation, right? And I was like, oh no, now we're into a place that's...okay, I have feelings. I got to decide how to approach that. And so, I am intrigued. And I wonder if we could just say like ten carts that's how many come into a cycle, and that's it. And we use the loosest heuristics possible to define how we structure a cycle so that we don't fall into the trap of, oh, what's our roadmap going to look like six months from now? JK, what's anything going to look like six months from now? That's not a knowable fact. +STEPH: I was just thinking where you said that you're moving into sprints or cycles, and then there's that push, well, now you got to estimate. And I just thought, do you? Do you have to estimate? [laughs] +CHRIS: We need a burndown chart through 2024, and it must be meticulously accurate down to the hour. +STEPH: I think meticulously wrong is how that goes. [laughs] +CHRIS: Which is the best kind of wrong. If you're going to be wrong, be meticulous about it. +STEPH: Be thorough about it. [laughs] Yeah, the team that I'm on right now, we have our bi-weekly planning, and we go through the board, and we pull stuff in. But there's never a discussion about estimation. And I hadn't really appreciated that until just now. How we don't think about how long is this going to take? We just talked about, well, what's in-flight? And how much work do people still have going on? And then here's the list of things we can pull in. But there's always a list that you can go back to. +Like, it's very...we pull in the minimum and knowing that if we run out of work, there's another place to go where there's stuff that's organized. And I just love that cadence, that idea of like, let's not try to make guesses about the future; let's just have it lined up and ready for us to go when we're ready to pull it in. Although I know, that's also coming from a very developer's perspective, and there are product managers who are trying to communicate as to when features are going to get out into the world. So I get that there's a balance, but I still have strong feelings and hesitations around estimating work. +CHRIS: Well, I feel like there is a balance there. And so many things in history are like, well, this is an overcorrection against that, and that's an overcorrection against this. And the idea that we can estimate our work that far out into the future that's just obviously false to me based on every project I've ever worked on that has tried to do it. And it has always failed without question. +But critically, there is the necessity to sync up work and like, oh, marketing needs to plan the launch of this feature, and it's a critical one. What's it going to look like? When's it going to be ready? You know, we're trying to go for an event, it's not just know...we developers never estimate anything past the immediate moment where like, that's not acceptable. We got to find a middle ground here. But where that middle ground is, is interesting. And so, just operating in the sort of we do work as it comes up is the easiest thing because no one's lying about anything at that point. +But sometimes you got to make some guesses and make some estimations. And then it gets into the murky area of I believe with 75% confidence that in three weeks, we will have this feature ready. But to be clear, I said with 75% confidence that means one-quarter of the time; we will not be there at that date. What does that mean? What does that failure mode look like? Let's talk about that. And can you have honest, open, transparent, useful conversations there? That's the space that it becomes more subtle if you need to do that. +STEPH: You're reminding me of a conversation that I had with someone where they shared with me some very aggressive team goals. And it was a very friendly conversation. And they're like, "How do you feel about aggressive goals?" And I was like, "Well, it depends. How do you feel about aggressive failure?" Because then once I know where you stand there, then we can talk about aggressive goals. Now, if we're being aggressive, but then we fail to achieve that, and it's one of those, okay, we didn't meet the goal that we'd expected, but everything is fine, and it's not a big deal, then I am okay. Sure, let's shoot for the stars. +But if it's one of those, we are communicating these goals to the outside world, and it's going to become incredibly important that we meet these goals, and if we don't, then things are going to go on fire, people are going to be in trouble, and it's just going to be awful, then let's not set aggressive goals. Let's not box ourselves into a space where we are setting ourselves up to fail or feel pain in a meaningful way. I agree that estimations are important, especially in terms of you need to collaborate with other departments, and then also just to provide some sense of where the product is headed and when things may be released. +I think estimations then just become problematic when they do become definite, and they're based on so many unknowns, and then when I don't know is not an answer. So if someone asked, "What's your estimate for this?" And the very honest real answer is I don't know, like, we haven't done this type of work before, or these are all the unknowns, and then someone's like, "Well, let's just put an estimation of like two weeks on it," and they just sort of try to force-fit it into being what they want, then that's where it starts to just feel incredibly problematic. +CHRIS: Yeah, estimation is a very murky area that we could spend entire episodes talking about, and in fact, I think we have a handful of times. So with that, Linear has been great. We're going to see just how much or how little estimation we actually want to do. But it's been a very nice addition to the toolset. And I'll let you know as we deepen our usage of it what the experience is like, but that's the main thing that's new in my world. What's new in your world? +STEPH: Well, before we bounce over to my world, you said something that has intrigued me that has also made me start reflecting on some of the ways that I like to work. And you'd mentioned that you have this prioritized backlog that people are pulling tickets from. And I don't know exactly if there's a planning session or how that looks, but I have recognized that when I am working with a team, and we don't have any planning session, if everybody is just pulling from this backlog, that's being prioritized by someone on the team, that I find that a bit overwhelming. +Because the types of work being done can vary so drastically that I find I'm less able to help my colleagues or my teammates because I don't have the context for what they're working on. It surprises me. I'm like, oh, I didn't even know we're working on that feature, or I don't have the context for what's the problem that we're trying to solve here. And it makes it just a lot harder to review and then have conversations with them. And I get overwhelmed in that environment. +And I've recognized that about myself based on previous projects that were more similar to that versus if I'm on a project where the team does get together every so often, even if it's high level to be like, hey, here's the theme of the tickets that we're working on, or here's just some of the stuff, then I feel much more prepared for the work that is coming in and to be able to context switch and review. And yeah, so I've kind of learned that about myself. I'm curious, are you similar, or how does that work for you? +CHRIS: I'm definitely similar. And I think probably the team is closer to what you're describing. So we do have a planning session every week, just a quick 30-minute scan through the backlog, look at the things that are coming up and also the larger themes. Previously, Epics and Trello now projects and Linear. But talking about what are the bigger pieces of work that we're moving on, and then what are the individual tickets associated with that that we'll be expecting to work on in the next week? And just making sure that everyone has broad clarity around what that feature set is. +Also, we're a very small team at this point. Still, we're four people total, but one of the developers is on a break for a couple of weeks this summer. And so there are really only three of us that are driving on the code. And so, with three of us working on the projects, we try very intentionally to have significant overlap between the various...like, we don't want any one person to own any portion of things at this point. And so we're doing a good amount of pairing to cross-pollinate and make sure everyone's...not everyone's aware of everything, but at least one other person is sufficiently aware of everything between the three of us. And I think that's been working well. +I don't think we have any major gaps, save for the way that we're doing our mobile architecture that's largely managed by one of the developers on the team and a contractor that we're working with to help do a lot of the implementation. That's a known we chose to silo that thing. We've accepted the cost of that for now. And architecturally, the rest of us are aware of it, but we're not like in the Swift code writing anything because I don't know how to write Swift at this point. I'd love to learn it. I hear good things about the language. +[12:26] +So yeah, I think conceptually very similar to what you're describing of still want to have people be able to review. Like, I don't want to put up a PR and people be like, I don't know, that looks like code, I guess. I'm not sure what it does. Like, I want it to be very...I want us all to be roughly on the same page, and thus far, we are. +As the team grows, that will become trickier to maintain because there are just inherently probably more things that are moving, more different feature areas and surface area that we're tackling in any given week, or there are different ways to approach that. I know you've talked about having a limited number of themes for a given cycle, so that's an idea that can pop up. But that's something that we'll figure out as we get further. I think I'm happy with where we're at right now, so yeah, that's the story there. +STEPH: Okay, cool. Yeah, all of that resonates with me, and thinking about it a little more deeply in this moment, I'm realizing I think something you said helped me put this together where when I'm reviewing someone's change, I'm not necessarily just looking to see does your code work? I'm going to trust you that your code works. I may have thoughts about design and other things, but I really want to understand more what's the change to the product that we're making? What's the goal that we're looking to achieve? How are we measuring this? +And so if I don't have that context, that's what contributes to that feeling of like, hard context switching of not just context switching, but now I have to level myself up to then understand the problem that's being solved by this. Versus had I known some of the themes going into that particular cycle or sprint, I would have felt far more prepared for that review session versus having to then dig through all the data and/or tickets or talk to someone. +Well, switching back to what's going on in my world, I have a particular tweet that I want to share, and it's one that Joël Quenneville brought to my attention. And it just resonates so much with all the type of work that I'm doing right now. So I'm going to read the tweet, and then we'll link to it in the show notes as well. But it's from Curtis Einsmann, and Curtis wrote: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one." +And that describes all the work that I'm doing right now. It's a lot of exploratory, a lot of data-driven work, and finding ways that we can reduce the time that it takes to run RSpec on CI. And it also ties in nicely to one of the things that I think we talked about last week, where we discovered that a number of files have a high runtime variance. And I've really dug into the data there to understand, okay, is it always specific files that have these high runtime variants? Are there any obvious contributions to what's causing this? Are we making real network calls that then could sometimes take a long time to return? And the result is there's nothing obvious. +They're giant files. The number of SQL commands that are being run for each file varies drastically. They're all high, but it's still very different. There's no single fact about these files that has really been like, yes, this is what's causing these files to have such a runtime variance. And so while I've been in the data, I'm documenting it, and I'm making a list and putting it all together in a ticket so at least it's there to look at later. But I'm going to move on. It's one of those I would love to know what's causing this. I would love to address it because it would put us in an ideal state for how we're distributing tests, which would have a significant impact on our runtime. +But it also feels a little bit like chasing my tail because I'm worried, like with some of the other experiments that we've done in the past where we've addressed tentpoles, that as soon as you address the issue for one or two files, then other files start having the same problem. And you're just going to continue to chase and chase, and I don't want to be in that. So upfront, this was one of those; hey, let's look at the data. If there's something obvious, let's address it; if not, move on. So I'm at that point today where I'm wrapping up all of that data, and then I'm going to move on, move on to the next thing. +CHRIS: There's deep truth in that tweet that you shared at the start of this segment. The idea like if we knew the work that we had to do at the front, yeah, we would just do that, but often, we don't. And so, being able to not treat it as a failure when something doesn't work out is, I think, so critical. I think to expand on the idea just a tiny bit, the idea of the scientific method, failure is totally an option and is part of science. +I remember watching MythBusters, and Adam Savage is just kind of like, "Failure is always an option," and highlighting that as part of it. Like, it's an outcome. You've learned something. You have a new data point. You can take that and then carry it forward with you. But it's rough in the moment. And so, I do think that this is a worthwhile thing to meditate on. And it's something that I've had to revisit a handful of times in my career of just like, man, I feel like I've just been spinning my tires all week. I'm like, we know what we want to get done, but just each approach I take isn't working for one reason or another. +And then, finally, you get to the end. And then you've got this paragraph-long summary of all the things that didn't work in your PR and one-line change sort of thing. And those are painful, but they're part of the game. Like, that is unavoidable. I have not found a way to just know how to do the work upfront always. I would love that. I would sign up for whatever seminar was selling that. I wouldn't. I would know that that seminar is a lie, actually. But broadly, I'm intrigued by the idea if someone were selling that, I'd be like, well, I mean, pitch me on it. Tell me why I should believe you; I don't, just to be clear. But yeah. +STEPH: This project has really helped me embrace always setting a goal or a question upfront about what I'm wanting to achieve or what I'm looking to answer because a number of times while Joël and I have been spelunking through data...And then so originally, with the saga, we started out with why doesn’t our math match reality? We understand that if these tests are distributed perfectly across the CPUs, then that should cut the runtime in half. But yet, we weren't seeing that even though we had addressed the tentpoles. +So we dug into understanding why. And the answer is because they're not perfectly distributed, and it's because of the runtime variance. And that was a critical moment to look back and say, "Did we achieve the goal?" Yes, we identified the problem. But once you see a problem, it's just so easy to dig in and keep going. It's like, well, now I want to know what's causing these files to have a runtime variance. +But it's one of those we achieved our goal. We acknowledged upfront that we wanted to at least understand why. Let's make a second decision, do we keep going? And I'm at that point where, frankly, I probably dug in a little more than I should because I'm stubborn. But I'm recognizing that now's the time to back away and then go back and move on to the next high-priority item, which is converting for funsies; I'll share. +The next thing is converting Test::Unit test over to RSpec because we have, I think, around 25 tests that are written in Test::Unit. And we want to move them over to RSpec because that particular just step in the build process takes a good three to four minutes. And part of that is just booting up Rails and then running the tests very fast. And we're underutilizing the machine that's running them because it's only 25 tests, but there are 86 CPUs to run it. +So we'd really like to combine those 25 tests with the rest of the RSpec suite and drop that step. So then that should add minimal time to the overall build but then should take us down at least a couple of minutes. And then also makes it easier to manage and help folks so that way, there's one consistent testing framework that's in use versus having to manage some of these older tests. +CHRIS: It's funny; I think it was just two episodes back where we talked about why RSpec, and I think both of us were just like, well yeah. But I mean, if there are tests and another, like, it's fine, you just leave them with the exception that if there's like 2% of our tests are in Test::Unit, and everything else is in RSpec, yeah, maybe that that conversion efforts seem totally worth it. +But again, I think as you're describing that, what I'm hearing is just like the scientific method, just being somewhat structured in the approach to what's the hypothesis? And what's the procedure we're going to use to determine if that hypothesis is true or false? And then what do we do? And then what are the results? And then you just do that on loop. But being not just sort of exploring. Sometimes you have to be on exploratory mode. But I definitely find that that tiny bit of rigor of just like, wait, okay, before I actually do anything, what do I think is going on here? What's my guess? +And then, okay, if that guess were true, what would I be able to observe in the world? Okay, here we go. And just that tiny bit of structure is so...it sometimes feels highly formal to go into that mode and be like, no, no, no, let me take a step back. Let me write down my thoughts. I'm going to have a little checklist and do the thing. But I've never regretted doing it. I will say that. I have deeply regretted not doing it. I feel like I should make a list of things that fit that structure. +I've never regretted committing in Git ever. That's been great. I've always been able to unwind it, but I've never been able to not unwind it or the opposite. I've regretted not committing. I have not regretted committing. I have regretted not writing out my hypothesis or approach. I have not regretted doing it. And so, yeah, this feels like it falls firmly in that category of like, it's worth just a tiny bit of structure. There's a reason it is the scientific method. +STEPH: Yeah, I agree. I've not regretted documenting upfront what it is I look to achieve and how I think I'm going to answer the question. That has been immensely helpful. Because then I also forget, like, two weeks ago, I'll be like, wasn't there a question around why this was happening, and I need to understand? And all of that was so context-heavy that as soon as I'm out of the thick of it, I completely forget it. So if I care about it deeply or if I want to be able to revisit it, then I need to document it for myself. +It's given me a lot of empathy for people who do more scientific research around, oh my gosh, like, you have to document everything you do and then still be able to prove it five years from now or however long. I'm just throwing out numbers. And it needs to be organized enough that someone, if they do question your research that, then you have it there. My research documents would not withstand scrutiny at this point because they are still just more personal notes. But yes, it's given me a lot of empathy and respect for people who do run very serious research, experiments, and trials, and then have to be able to prove it to the world. +Pivoting just a bit, there's a particular topic that resonated with both you and I; in fact, it's a particular tweet. And, Louie, I do apologize if I mispronounce your last name, but Louie Bacaj. And we'll include a link in the show notes to the tweet, but Louis shared, "I managed multiple engineering teams before quitting tech. Now that I quit, I can speak freely. Here are 12 things your manager may not be telling you, but I know for a fact will help you." +So there are a number of interesting discussions and comments that are in this thread. The one thing in particular that really caught my attention is number 10, and it's "Advocate for junior developers." So they said that their friend reminded them that just because you don't have 10-plus years of experience does not mean that they won't be good. Without junior engineers on the team, no one will grow. Help others grow; you'll grow too. +And that's the part that I love so much is that without junior engineers on the team, no one will grow because that was very thought-provoking for me. It's something that I find that I agree with deeply, but I hadn't really considered why I agree with that so much. So I'm excited to dive into that topic with you. And then, as a second topic to go along with that is, can juniors start with a remote team? I think that's one of the other questions when you and I were chatting about this. And I'm intrigued to hear your thoughts. +CHRIS: A bunch of stuff there. Starting with the tweet, I love elements of this. Some of it feels like it's intentionally somewhat provocative. So like, without junior engineers on the team, no one will grow. That feels maybe a little bit past the bar because I think we can technically grow, and we can build things and whatnot. But I think what feels deeply true to me is truly help others grow; you'll grow too. The act of mentoring, of guiding, of training, of helping someone on their journey will inherently help you grow and, I think, change the way that you think about the work. +I think the beginner mind, the earlier in the career folks coming into a codebase, they will see things fundamentally differently in a really useful way. It's possible that along your career, you've just internalized things. You've been like, yeah, no, that was weird. But then I smashed my head against it for a while, and now I understand this thing. And it just makes sense to me. But it's like, that thing actually doesn't make sense. You have warped your mind to match the thing, not, quote, unquote, "come to understand it." This is sounding too judgmental to people who've been in the industry for a while, but I found this of myself. +Or I can just take for granted things that took a long time to adapt my head to, and if anything, maybe I should have pushed back a little more. And so, I find that junior engineers can be a really fantastic lens for the complexity of a project. Like, the world is truly a complex place, and that's just true. But our job as software engineers is to tame that complexity and manage it. And so, I love the mindset that can come or the conversations that can come out of that. +And it's much like test-driven development is a pressure on the complexity of your code, having junior engineers join the team and needing to explain how all of the different features work, and what the overall architecture is, and the message passing under this and that, it's a really useful conversation to have. And so that "Help others grow; you'll grow too" feels deeply, deeply true to me. +STEPH: Yeah, I couldn't agree more in regards to how juniors really help our team and especially, as you mentioned, with complexity and ¬having those conversations. Some of the other things that have come to mind for me as well around the importance of having junior developers on your team...and maybe it's not specifically they're junior developers but that you just have a variety of experience on your team. It's going to help you lean into a culture of learning because you have people that are at different stages of their career. +And so you want an environment where people can learn together, that they can fail together, and they can be public about it. And having people that are at different stages of their career will lead, well, at least ideally, it'll lead to more pair programming. It's going to lead to more productive code reviews because then people can ask more questions around why did you choose this, or why are you doing that? Versus if everybody is at the same level, then they may just intuitively have reasons that they think someone did something. +But it takes someone that's a bit new to say, "Hey, why did you choose this?" or to bring up some other ideas or ways that they could pursue it. They may bring in new ideas for, like, why has the team always done something this way? Let's think about new ways that we could do this. Or maybe this is really unfriendly, the way that we're doing this, not just for junior people but for people that are new to the team. +And then there's typically less knowledge siloing because then you're going to want to pair the newer folks with the more experienced folks. So that way, you don't have this more senior developer who's then off in a corner working by themselves. And it's going to improve your communication skills. There's just...I realized I'm just rambling because I feel like there are so many benefits that go along with having a variety of people on your team, especially in terms of experience. And that just leads to such a better learning environment and, ultimately, better software and better products. +And yet, I find that so many companies won't embrace people that are newer to software. They always want the senior developers. They want the 10x-er or whatever those are. They want the people that have many, many years of experience. And there's so much value that comes from mentoring the next group of developers. And it's incredibly frustrating to me that one, companies often aren't open to it. But honestly, more than that, as long as you're upfront and honest about like, hey, this is the team that we need right now to build what we're looking to build, I can get past that; I can understand that. But please don't then mislead people and say that you're a junior-friendly team, and then not be prepared. +I feel like some teams will go so far as to say, "Yes, we are junior-friendly," and they may even tweak their interview process to where it is a bit more junior-friendly. But then, by the time that person joins the team, they're really not prepared. They don't have an onboarding plan. They don't have a mentorship plan. And then they fail that person because that person has worked hard to get there. And they've worked hard to bring that person onto the team, but then they don't have a plan from there. +And I've seen it too many times. And it just frustrates me so much because it puts that junior person in such a vulnerable state where they really have to be an incredible self-advocate to then overcome those hurdles from a lack of preparation on that company's part. Okay, I think that's my event. I'm sure I could vent about this a lot more, but I will cut it off there. That's the heart of it. +CHRIS: I do think, like, with anything else, it's something that we have to be intentional about. And so what you're saying of like, yeah, we're a junior-friendly company, but then you're just hiring folks, trying to find folks that may work at a slightly lower pay grade, and that's what that means to you. So like, no, no, that's not what this is. This needs to be something different. We need to have a structure and an organization that can support folks at different points in their career. +But it's interesting to me to think about the sort of why of it. And the earlier part of this conversation, we talked about some of the benefits that can come organizationally from it, and I do sincerely believe in that. But I also believe that it is fundamentally one of the best ways to find really talented people early on in their career and be in a position to hire them where maybe later on in their career, that just wouldn't happen naturally. And I've seen this play out in a number of organizations. +I went to Northeastern University for my college, and Northeastern is famous for the co-op program. Northeastern sounds really fancy. Now I learned that they have like a 7% acceptance rate for college applications right now, which is wildly low. When I went to Northeastern, it was not so fancy. So just in case anyone's hearing that and they're like, "Oh, Northeastern, wow." I'm not that fancy. [laughs] +But they did have the co-op then, and they still have it now. And the co-op really is a differentiating thing. You do three six-month rotations. And it is this fundamental differentiator in terms of when you're graduating. Particularly, I was in mechanical engineering. I came out, and I actually knew what that meant in the world. And I'd used Outlook, and I knew what a water cooler was and how to talk near one because that's a critical thing to learn in the world. And really transformative experience for me. +But also, a thing that I observed was many of my friends ended up working at companies that they had co-opted for. I'm one of those people. I would say more than 50% of my friends ended up with a position at a company that they had done a co-op rotation with. And it really worked out fantastically. That organization and the individual got to try things out, experience. And then, I ended up staying at that company for a number of years, and it was a wonderful experience. But I don't know that I would have ended up there otherwise. That's not necessarily the way that would have played out. +And similarly like, thoughtbot has the apprenticeship. And I have seen so many wonderful developers start at that very early point in their career. And there was this wonderful structure around them joining the thoughtbot team, intentional, structured, supported. And then those folks went on to be some of the most talented developers that I've ever worked with at a wonderfully talented organization. And so the story of like, you should do this, organizations. This is a thing that you should invest in for yourself, not just for the individual, like, for both. Everybody wins in this case, in my mind. +I will say, though, in terms of transparency, I currently manage a team of three developers. And we hired very intentionally for senior folks this early on in where we're at. And that was an intentional choice because I do believe that if you're going to be hiring more junior developers, that needs to be something that you do very intentionally, that you have a support structure in place, that you're able to invest the time in where they're at and make sure we have sort of... +I think a larger team makes more sense to bring juniors into broadly. That's the thing that I'm saying out loud that I'm like, I should push on that a little bit. Is that true? Do I really believe that? But I think so, my actions obviously point to it. But it is an interesting trade-off space of how do you think about that? My hope is that as we grow as an organization, that we would then very intentionally start hiring folks in a more junior, mid-level to junior and be very intentional about how we support them, bring them into the organization, et cetera. I do believe it is a win-win situation for everyone when done with intention and with focus. +STEPH: That's such an interesting bit that you just said because I very much appreciate when companies recognize do we have the bandwidth to support someone that's more junior? Because at thoughtbot, we go through periods where we don't have our apprenticeship that's open because we recognize we're not in a place that we can support someone. And we don't want to bring someone in unless we can help them be successful. I very much admire that and appreciate that about companies when they can perform that self-assessment. +I am so intrigued. You'd mentioned being a smaller team. So you more intentionally hire senior developers. And I think that also makes sense because then you need to build up who's going to be in that mentorship pool? Because then people could leave, people could take vacations, and so then you need to have that support system in place. But yeah, I don't know what that then perfect balance is. It's like, okay, so then as soon as you have like five people available to mentor or interested in mentorship, it's like, then do you start bringing in the conversation of like, let's bring in someone that we can help build up and help them be successful and join our team? And I don't know what that magical number is. +I do think it's important for teams to reflect to say, "Can we take on someone that's junior?" All the benefits of having someone that's junior. And then just being very honest and then having a plan for once that junior person does arrive. What does their career path look like while they've joined that team, and who's going to be that person that's going to help them level up? So not only make that choice upfront of yes, we are bringing someone on but let's also think about like the first six months of their work here at the company and what that's going to look like. +It feels like an important step that a lot of companies fail to do. And I think that's why there are so many articles that then are like, hey, if you're a junior dev, here's all the things that you should do to be the best junior dev. That's fabulous. And we're constantly shoring up junior devs to be like, hey, here's all the things that you need to be great at. But we don't have as many conversations around; hey, here's all the things that your manager or the rest of your team should be great at to then support you equally as you are also doing your best to meet them. Like, they need to meet you halfway. +And I'm not completely unsympathetic to the plight; I understand. It's often where I've seen with teams the more senior developers that have very strong mentorship communication skills are then also the teammates that get pulled into all the meetings and all the different projects, so then they are less available to be that mentor. And then that's how this often fails. So I don't think anybody is going into this intentionally, but yet, it's what happens for when someone is new and joining a team, and it hasn't been determined the next six months what that person's onboarding and career path looks like. +Circling back just a bit, there's the question around, can juniors start with a remote team? I can go first. And I'm going to say unequivocally yes. There's no reason a junior can't start with a remote team. Because all the things that I feel strongly about come down to how is your team going to plan for this person? And how are they going to support this person? And all the benefits that you get from being in an office with a team, I think those do exist. +And frankly, for someone like myself, it can be easier to establish a bond with someone that you get to see each day, get to see in person. You can walk up to their desk and can say, "Hey, I've got a question for you." But I think all those benefits just need to be transferred into a remote-friendly way. So I think it does ratchet up how intentional you have to be with your team and then onboarding a junior developer. But I absolutely think it's doable, and we should do it. +CHRIS: You went with unequivocally yes as your answer. I'm going to go with a qualified maybe as my answer. I want this to be true, and I think it can be true. But I think it takes all the more intentionality than even what we've been describing. To shift the question around a little bit, what does remote work mean? It doesn't just mean we're doing the work, but we're separate. I think remote work inherently is at its best when we also are largely async first. And so that means more structured writing. +The nature of the conversation tends to be more well-formed in each interaction. So it's like I read a big document, and then I pass it over to you. And at your leisure, you respond to it with a bunch of notes, and then it comes back to me. And I think that mode of interaction, while absolutely wonderful and something that I love, I think it fits really well when you're a little bit further on in your career when you understand things a little bit better. And I think the dance of conversation is more useful earlier on and so forth. +And so, for someone who's newer to a team, I think having the ability to ask a quick question over and over is really useful to someone who's early on in their career. And remote, again, I think it's at its best when it's async. And those two are sort of at odds. And so it's that mild tension that gives me pause of like, something that I think that makes remote work great I do think is at least a hurdle that you would have to get over in supporting someone who's a little bit newer. Because I want to be deeply present for someone who's newer to their journey so that they can ask a lot of questions so that I am available to be interrupted regularly. +I loved at thoughtbot sitting next to someone and being their mentor and being like, yeah, anytime you want, just tap on my desk. If I got my headphones on, that doesn't mean I'm ignoring you; it means I just need to make the sounds go away for a minute because that's the only way my brain will work. But feel free to just tap on my desk or whatever and grab my attention for a moment. And I'm available for that. That's an intentional choice. That's breaking up my continuity of the day, but we're choosing that for a reason. +I think that's just a little harder to do in a remote context and all the more so if we're saying, hey, we're going to try this async thing where we write structured documents, and we communicate in these larger, more well-formed, communicates back and forth. But I do believe it can be done. I think it should be done. I just think it's all the harder for all of those reasons. +STEPH: I agree that definitely makes it harder. But I'm going to push a little bit and say that when you mentioned being deeply present, I think we can be deeply present with someone and be remote. We can reduce the async requirements. So if you are someone that is more senior or more accustomed to the team, you can fall back to more of those async ways to communicate. +But if someone is new, and needs more mentorship, then let's just set up time where we're going to literally hang out for a couple of hours each day or whatever pairing environment works best for them because pairing can also be exhausting. But hey, we're going to have a check-in each day; maybe we close out each day and touchpoint. And feel free to still message me and interrupt me. Like, you're going to just heighten your availability, even though it is remote. And be aware, like, hey, this person could message me at more times, and I'm okay with that. I have opted into this form of communication. +So I think we just take that mindset of, hey, there's this person next to me, and I'm their mentor to like, hey, they're not next to me, but I'm still their mentor, and I'm still here for them. So I agree that it's harder. I think it falls on us and the team and the mentors to change ourselves versus saying to juniors, "Hey, sorry, it's remote. That's not going to work for you." It totally works for them. It's us, the mentors, that need to figure out how to make it work. +I will say being on that mentor side that then not being able to see someone so if they are next to me, I can pick up on body language and facial expressions, and I can tell when somebody's stuck. And I can see that they're frustrated, or I can see that now's a good time for me to just be like, "Hey, how's it going? What are you working on? Or do you need help with something?" And I don't have that insight when I'm away. So there are real challenges like that that I don't know how to address. +I have gone the obnoxious route [laughs] where I just message people, and I'm like, "Hey, how's it going? How's it going? How's it going?" And I try not to do that too much. But I haven't found a better way to manage that other than to constantly check in because I do have less feedback from that person that I'm working with unless they are just incredibly open about sharing when they're stuck. But typically, when you're newer to a team or newer to a career, you're going to be less willing to share when you're stuck. +But yeah, there are some real challenges, but I still think it's something for us to figure out. Because otherwise, if we cut off access for remote teams to junior folks, I mean, that's where we're headed. There are so many companies and jobs that are headed remote that not being junior friendly and being remote in my mind is just not an option. It's something that we need to figure out. And it's hard, but we need to figure it out. +CHRIS: Yeah, 100% on we need to figure that out and that that's on us as the people managing and structuring and bringing folks into teams. I think my stance would be like, let's just be clear that this is hard. It takes effort to make sure that we've provided a structure in which someone newer to a team can be successful. It takes all the more effort to do so in a remote context, I think. And it's that recognition that I think is critical. +Because if we go into this with the wrong mindset, it's like, oh yeah, it's great. We got this new person on the team. And yeah, they should be ready to go in like two weeks, right? It's like, no, no, this is a different thing. We need to be very clear about it. This is going to require that we have someone who is able to work with them and support them in this. And that means that that person's output will likely be a little bit reduced for the period of time that we're talking about. But we're playing a long game here. Let's make sure we're clear on that. This is intentional. +And let's be clear, the world of hiring and software right now it's not like super easy. There aren't way more software developers than there are jobs; at least, that's been my experience. So this is something absolutely worth investing in for just core business reasons and also good for people. So hey, it's a win-win. Let's do it. Let's figure it out. But also, let's be clear that it's going to be a little tricky along the way. So, you know, let's be intentional about that. But yeah, obviously do it, got to do it. +STEPH: Wait, so I feel like we might have circled back to unequivocally yes. [laughs] Have we gotten there, or are you still on the fence? +CHRIS: I was unequivocally yes from the beginning, but I couched it in, but...yeah, I said other things. You're right. I have now come around; let's say to unequivocally yes. +STEPH: [laughs] Cool. I don't want to feel like I'm forcing you to agree with me. [laughs] But I mean, we just so rarely disagree. So we've either got to identify this as something that we disagree on, which would be one of those rare occasions like beer and Pop-Tarts. +CHRIS: A watershed moment. Beer and Pop-Tarts. +STEPH: Yeah, those are the only two so far. +[laughter] +CHRIS: Not together also. I just want to go on record beer and Pop-Tarts; I don't think would be...anyway. +STEPH: Ooh, I don't know. It could work. It could work. +CHRIS: Well, there's another thing we disagree on. +STEPH: I would not turn it down. If I was eating a Pop-Tart, and you're like, "Hey, you want a beer?" I'd be like, "Sure," vice versa. I'm drinking a beer. "Hey, you want a Pop-Tart?" "Totally." +CHRIS: Okay. Well yeah, if I'm making bad decisions, I'm obviously going to chain them together, but that doesn't mean that they're a good decision. It's just a chain of bad decisions. +STEPH: I feel like one true thing I know about you is that when you make a decision, you're going to lean into it. So like, this is why you are all about if you're going to have a Pop-Tart, you're going to have the highest sugary junk content Pop-Tart possible. So it makes sense to me. +CHRIS: It's the Mountain Dew theorem, yeah. +STEPH: I didn't know this had a theorem. The Mountain Dew theorem? +CHRIS: No, that's just my name. Well, yeah, if I'm going to drink soda, I'm going to drink Mountain Dew, the nonsense nuclear option of soda. So yeah, I guess you're describing me, although as you say it back to me, I suddenly feel very, like, oh God, is this who I am as a person? [laughs] And I'm not going to say you're wrong. I'm just going to spend a little while thinking about some stuff. +STEPH: I mean, you embrace it. I think that's lovely. You know what you want. It's like, all right, let's do this. Let's go all in. +CHRIS: Thank you for finding a wonderfully positive way to frame it here at the end. But I think on that note, should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris switched from Trello over to Linear for product management and talks about prioritizing backlogs.

+ +

Steph shares and discusses a tweet from Curtis Einsmann that super resonated with the work she's doing right now: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one."

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ +

Linear
+Curtis Einsmann Tweet
+Louie Bacaj Tweet

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow and make things downright miserable.
+In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix them all today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed.

+ +

CHRIS: Good morning, and welcome to Tech Talk with Steph and Chris. Today at the top of the hour, it's tech traffic hits.

+ +

STEPH: Ooh, tech traffic. [laughs] I like that statement.

+ +

CHRIS: Yeah. The Git lanes are clogged up with...I don't know. I got nothing.

+ +

STEPH: [laughs]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Actually, I have a specific new thing that I can share, which is, as of the past week, I would say, switched from Trello over to Linear for product management. It's been great. It was a super straightforward transfer. They actually had an importer. We lost some of the comment threads on the Trello cards. But that was easy enough to like each Linear ticket has a link back to Trello. So it's easy enough to keep the continuity.

+ +

But yeah, we're in a whole new world, a system actually built for maintaining a product backlog, and, man, it shows. Trello was a bunch of lists and cards and stuff that you could link between, which was cool. But Linear is just much more purpose-built and already very, very nice. And we're very happy with the switch.

+ +

STEPH: I feel like you came in real casual with that news, but that is big news, that you did a switch.

+ +

[laughter]

+ +

CHRIS: How are you going to bury the lead like that? You switched project management...[laughter] I actually didn't think it was...I'm excited about it but low-key excited, which is weird because I do like productivity and task management software. So you would think I would be really excited about this. But I've also tried enough of them historically to know that that's never going to be the thing that actually makes or breaks your team's productivity. It can make things worse, but it can't make you great. That's the thing that I believe. And so it's a wonderful piece of software. I'm very excited about it but --

+ +

STEPH: Ooh, I like that. It can make you worse, but it doesn't make you great. That's so true, yeah, where it causes pain. Well, and it does make sense. You've been complaining a bit about the whole login with Trello and how that's been frustrating. But I haven't even heard of Linear. That's just...that's, I mean, you're just doing what you do where you bring that new-new. I haven't heard of Linear before.

+ +

CHRIS: I try to live on the cutting edge. Actually, I deeply try to not live on the cutting edge at this point in my life. That early adopter wave, no, no, no, that's not for me anymore. But I've known a few folks who've moved to Linear. And everyone that I've spoken to who has moved to it has been like, "Yeah, it's been great." I've not heard anything negative. And I've heard or experienced negative things about every other product management tool out there. And so, it seemed like an easy thing.

+ +

And it was a low-cost enough switch in terms of opportunity costs or the like, it took the effort of someone on our team moving those cards over and setting up the new system and training, but it was relatively straightforward. And yeah, we're super happy with it. And it feels different now. I feel like I can see the work in a different way which is interesting.

+ +

I think we had brought in a Chrome extension for Trello. I think it's like Hello Epics or something like that that allows...it abuses the card linking functionality in Trello and repurchases that feature as an epic management thing. But it's quarter-baked is how I would describe it, or it's clearly built on top of existing things that were not intended to be used exactly in that way. So it does a great job. Hello Epics does a great job of trying to make something like parent-child list management stuff happen in Trello. But it's always going feel like an afterthought, a secondary feature, something that's bolted on.

+ +

Whereas in Linear, it's like, no, no, we absolutely have the idea of projects, of course, and you can see burndown charts and things. And the thing that I do want to be careful about is not leaning too much into management. Linear has the idea of cycles or sprints, as many other folks think of them, or iterations or whatever you want to call them. But we've largely not been working in that mode. We've just continued to work through the next up list; that's it. The next up list should be prioritized and well defined at the top and roughly in priority order. So just pick up the next card and work on it. And we just do that every single day.

+ +

And now we're in a piece of software that has the idea of cycles, and I'm like, oh, this is vaguely interesting. Do we want to do that? Oh, but if you're going to do that, you probably do some estimation, right? And I was like, oh no, now we're into a place that's...okay, I have feelings. I got to decide how to approach that. And so, I am intrigued. And I wonder if we could just say like ten carts that's how many come into a cycle, and that's it. And we use the loosest heuristics possible to define how we structure a cycle so that we don't fall into the trap of, oh, what's our roadmap going to look like six months from now? JK, what's anything going to look like six months from now? That's not a knowable fact.

+ +

STEPH: I was just thinking where you said that you're moving into sprints or cycles, and then there's that push, well, now you got to estimate. And I just thought, do you? Do you have to estimate? [laughs]

+ +

CHRIS: We need a burndown chart through 2024, and it must be meticulously accurate down to the hour.

+ +

STEPH: I think meticulously wrong is how that goes. [laughs]

+ +

CHRIS: Which is the best kind of wrong. If you're going to be wrong, be meticulous about it.

+ +

STEPH: Be thorough about it. [laughs] Yeah, the team that I'm on right now, we have our bi-weekly planning, and we go through the board, and we pull stuff in. But there's never a discussion about estimation. And I hadn't really appreciated that until just now. How we don't think about how long is this going to take? We just talked about, well, what's in-flight? And how much work do people still have going on? And then here's the list of things we can pull in. But there's always a list that you can go back to.

+ +

Like, it's very...we pull in the minimum and knowing that if we run out of work, there's another place to go where there's stuff that's organized. And I just love that cadence, that idea of like, let's not try to make guesses about the future; let's just have it lined up and ready for us to go when we're ready to pull it in. Although I know, that's also coming from a very developer's perspective, and there are product managers who are trying to communicate as to when features are going to get out into the world. So I get that there's a balance, but I still have strong feelings and hesitations around estimating work.

+ +

CHRIS: Well, I feel like there is a balance there. And so many things in history are like, well, this is an overcorrection against that, and that's an overcorrection against this. And the idea that we can estimate our work that far out into the future that's just obviously false to me based on every project I've ever worked on that has tried to do it. And it has always failed without question.

+ +

But critically, there is the necessity to sync up work and like, oh, marketing needs to plan the launch of this feature, and it's a critical one. What's it going to look like? When's it going to be ready? You know, we're trying to go for an event, it's not just know...we developers never estimate anything past the immediate moment where like, that's not acceptable. We got to find a middle ground here. But where that middle ground is, is interesting. And so, just operating in the sort of we do work as it comes up is the easiest thing because no one's lying about anything at that point.

+ +

But sometimes you got to make some guesses and make some estimations. And then it gets into the murky area of I believe with 75% confidence that in three weeks, we will have this feature ready. But to be clear, I said with 75% confidence that means one-quarter of the time; we will not be there at that date. What does that mean? What does that failure mode look like? Let's talk about that. And can you have honest, open, transparent, useful conversations there? That's the space that it becomes more subtle if you need to do that.

+ +

STEPH: You're reminding me of a conversation that I had with someone where they shared with me some very aggressive team goals. And it was a very friendly conversation. And they're like, "How do you feel about aggressive goals?" And I was like, "Well, it depends. How do you feel about aggressive failure?" Because then once I know where you stand there, then we can talk about aggressive goals. Now, if we're being aggressive, but then we fail to achieve that, and it's one of those, okay, we didn't meet the goal that we'd expected, but everything is fine, and it's not a big deal, then I am okay. Sure, let's shoot for the stars.

+ +

But if it's one of those, we are communicating these goals to the outside world, and it's going to become incredibly important that we meet these goals, and if we don't, then things are going to go on fire, people are going to be in trouble, and it's just going to be awful, then let's not set aggressive goals. Let's not box ourselves into a space where we are setting ourselves up to fail or feel pain in a meaningful way. I agree that estimations are important, especially in terms of you need to collaborate with other departments, and then also just to provide some sense of where the product is headed and when things may be released.

+ +

I think estimations then just become problematic when they do become definite, and they're based on so many unknowns, and then when I don't know is not an answer. So if someone asked, "What's your estimate for this?" And the very honest real answer is I don't know, like, we haven't done this type of work before, or these are all the unknowns, and then someone's like, "Well, let's just put an estimation of like two weeks on it," and they just sort of try to force-fit it into being what they want, then that's where it starts to just feel incredibly problematic.

+ +

CHRIS: Yeah, estimation is a very murky area that we could spend entire episodes talking about, and in fact, I think we have a handful of times. So with that, Linear has been great. We're going to see just how much or how little estimation we actually want to do. But it's been a very nice addition to the toolset. And I'll let you know as we deepen our usage of it what the experience is like, but that's the main thing that's new in my world. What's new in your world?

+ +

STEPH: Well, before we bounce over to my world, you said something that has intrigued me that has also made me start reflecting on some of the ways that I like to work. And you'd mentioned that you have this prioritized backlog that people are pulling tickets from. And I don't know exactly if there's a planning session or how that looks, but I have recognized that when I am working with a team, and we don't have any planning session, if everybody is just pulling from this backlog, that's being prioritized by someone on the team, that I find that a bit overwhelming.

+ +

Because the types of work being done can vary so drastically that I find I'm less able to help my colleagues or my teammates because I don't have the context for what they're working on. It surprises me. I'm like, oh, I didn't even know we're working on that feature, or I don't have the context for what's the problem that we're trying to solve here. And it makes it just a lot harder to review and then have conversations with them. And I get overwhelmed in that environment.

+ +

And I've recognized that about myself based on previous projects that were more similar to that versus if I'm on a project where the team does get together every so often, even if it's high level to be like, hey, here's the theme of the tickets that we're working on, or here's just some of the stuff, then I feel much more prepared for the work that is coming in and to be able to context switch and review. And yeah, so I've kind of learned that about myself. I'm curious, are you similar, or how does that work for you?

+ +

CHRIS: I'm definitely similar. And I think probably the team is closer to what you're describing. So we do have a planning session every week, just a quick 30-minute scan through the backlog, look at the things that are coming up and also the larger themes. Previously, Epics and Trello now projects and Linear. But talking about what are the bigger pieces of work that we're moving on, and then what are the individual tickets associated with that that we'll be expecting to work on in the next week? And just making sure that everyone has broad clarity around what that feature set is.

+ +

Also, we're a very small team at this point. Still, we're four people total, but one of the developers is on a break for a couple of weeks this summer. And so there are really only three of us that are driving on the code. And so, with three of us working on the projects, we try very intentionally to have significant overlap between the various...like, we don't want any one person to own any portion of things at this point. And so we're doing a good amount of pairing to cross-pollinate and make sure everyone's...not everyone's aware of everything, but at least one other person is sufficiently aware of everything between the three of us. And I think that's been working well.

+ +

I don't think we have any major gaps, save for the way that we're doing our mobile architecture that's largely managed by one of the developers on the team and a contractor that we're working with to help do a lot of the implementation. That's a known we chose to silo that thing. We've accepted the cost of that for now. And architecturally, the rest of us are aware of it, but we're not like in the Swift code writing anything because I don't know how to write Swift at this point. I'd love to learn it. I hear good things about the language.

+ +

[12:26]

+ +

So yeah, I think conceptually very similar to what you're describing of still want to have people be able to review. Like, I don't want to put up a PR and people be like, I don't know, that looks like code, I guess. I'm not sure what it does. Like, I want it to be very...I want us all to be roughly on the same page, and thus far, we are.

+ +

As the team grows, that will become trickier to maintain because there are just inherently probably more things that are moving, more different feature areas and surface area that we're tackling in any given week, or there are different ways to approach that. I know you've talked about having a limited number of themes for a given cycle, so that's an idea that can pop up. But that's something that we'll figure out as we get further. I think I'm happy with where we're at right now, so yeah, that's the story there.

+ +

STEPH: Okay, cool. Yeah, all of that resonates with me, and thinking about it a little more deeply in this moment, I'm realizing I think something you said helped me put this together where when I'm reviewing someone's change, I'm not necessarily just looking to see does your code work? I'm going to trust you that your code works. I may have thoughts about design and other things, but I really want to understand more what's the change to the product that we're making? What's the goal that we're looking to achieve? How are we measuring this?

+ +

And so if I don't have that context, that's what contributes to that feeling of like, hard context switching of not just context switching, but now I have to level myself up to then understand the problem that's being solved by this. Versus had I known some of the themes going into that particular cycle or sprint, I would have felt far more prepared for that review session versus having to then dig through all the data and/or tickets or talk to someone.

+ +

Well, switching back to what's going on in my world, I have a particular tweet that I want to share, and it's one that Joël Quenneville brought to my attention. And it just resonates so much with all the type of work that I'm doing right now. So I'm going to read the tweet, and then we'll link to it in the show notes as well. But it's from Curtis Einsmann, and Curtis wrote: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one."

+ +

And that describes all the work that I'm doing right now. It's a lot of exploratory, a lot of data-driven work, and finding ways that we can reduce the time that it takes to run RSpec on CI. And it also ties in nicely to one of the things that I think we talked about last week, where we discovered that a number of files have a high runtime variance. And I've really dug into the data there to understand, okay, is it always specific files that have these high runtime variants? Are there any obvious contributions to what's causing this? Are we making real network calls that then could sometimes take a long time to return? And the result is there's nothing obvious.

+ +

They're giant files. The number of SQL commands that are being run for each file varies drastically. They're all high, but it's still very different. There's no single fact about these files that has really been like, yes, this is what's causing these files to have such a runtime variance. And so while I've been in the data, I'm documenting it, and I'm making a list and putting it all together in a ticket so at least it's there to look at later. But I'm going to move on. It's one of those I would love to know what's causing this. I would love to address it because it would put us in an ideal state for how we're distributing tests, which would have a significant impact on our runtime.

+ +

But it also feels a little bit like chasing my tail because I'm worried, like with some of the other experiments that we've done in the past where we've addressed tentpoles, that as soon as you address the issue for one or two files, then other files start having the same problem. And you're just going to continue to chase and chase, and I don't want to be in that. So upfront, this was one of those; hey, let's look at the data. If there's something obvious, let's address it; if not, move on. So I'm at that point today where I'm wrapping up all of that data, and then I'm going to move on, move on to the next thing.

+ +

CHRIS: There's deep truth in that tweet that you shared at the start of this segment. The idea like if we knew the work that we had to do at the front, yeah, we would just do that, but often, we don't. And so, being able to not treat it as a failure when something doesn't work out is, I think, so critical. I think to expand on the idea just a tiny bit, the idea of the scientific method, failure is totally an option and is part of science.

+ +

I remember watching MythBusters, and Adam Savage is just kind of like, "Failure is always an option," and highlighting that as part of it. Like, it's an outcome. You've learned something. You have a new data point. You can take that and then carry it forward with you. But it's rough in the moment. And so, I do think that this is a worthwhile thing to meditate on. And it's something that I've had to revisit a handful of times in my career of just like, man, I feel like I've just been spinning my tires all week. I'm like, we know what we want to get done, but just each approach I take isn't working for one reason or another.

+ +

And then, finally, you get to the end. And then you've got this paragraph-long summary of all the things that didn't work in your PR and one-line change sort of thing. And those are painful, but they're part of the game. Like, that is unavoidable. I have not found a way to just know how to do the work upfront always. I would love that. I would sign up for whatever seminar was selling that. I wouldn't. I would know that that seminar is a lie, actually. But broadly, I'm intrigued by the idea if someone were selling that, I'd be like, well, I mean, pitch me on it. Tell me why I should believe you; I don't, just to be clear. But yeah.

+ +

STEPH: This project has really helped me embrace always setting a goal or a question upfront about what I'm wanting to achieve or what I'm looking to answer because a number of times while Joël and I have been spelunking through data...And then so originally, with the saga, we started out with why doesn’t our math match reality? We understand that if these tests are distributed perfectly across the CPUs, then that should cut the runtime in half. But yet, we weren't seeing that even though we had addressed the tentpoles.

+ +

So we dug into understanding why. And the answer is because they're not perfectly distributed, and it's because of the runtime variance. And that was a critical moment to look back and say, "Did we achieve the goal?" Yes, we identified the problem. But once you see a problem, it's just so easy to dig in and keep going. It's like, well, now I want to know what's causing these files to have a runtime variance.

+ +

But it's one of those we achieved our goal. We acknowledged upfront that we wanted to at least understand why. Let's make a second decision, do we keep going? And I'm at that point where, frankly, I probably dug in a little more than I should because I'm stubborn. But I'm recognizing that now's the time to back away and then go back and move on to the next high-priority item, which is converting for funsies; I'll share.

+ +

The next thing is converting Test::Unit test over to RSpec because we have, I think, around 25 tests that are written in Test::Unit. And we want to move them over to RSpec because that particular just step in the build process takes a good three to four minutes. And part of that is just booting up Rails and then running the tests very fast. And we're underutilizing the machine that's running them because it's only 25 tests, but there are 86 CPUs to run it.

+ +

So we'd really like to combine those 25 tests with the rest of the RSpec suite and drop that step. So then that should add minimal time to the overall build but then should take us down at least a couple of minutes. And then also makes it easier to manage and help folks so that way, there's one consistent testing framework that's in use versus having to manage some of these older tests.

+ +

CHRIS: It's funny; I think it was just two episodes back where we talked about why RSpec, and I think both of us were just like, well yeah. But I mean, if there are tests and another, like, it's fine, you just leave them with the exception that if there's like 2% of our tests are in Test::Unit, and everything else is in RSpec, yeah, maybe that that conversion efforts seem totally worth it.

+ +

But again, I think as you're describing that, what I'm hearing is just like the scientific method, just being somewhat structured in the approach to what's the hypothesis? And what's the procedure we're going to use to determine if that hypothesis is true or false? And then what do we do? And then what are the results? And then you just do that on loop. But being not just sort of exploring. Sometimes you have to be on exploratory mode. But I definitely find that that tiny bit of rigor of just like, wait, okay, before I actually do anything, what do I think is going on here? What's my guess?

+ +

And then, okay, if that guess were true, what would I be able to observe in the world? Okay, here we go. And just that tiny bit of structure is so...it sometimes feels highly formal to go into that mode and be like, no, no, no, let me take a step back. Let me write down my thoughts. I'm going to have a little checklist and do the thing. But I've never regretted doing it. I will say that. I have deeply regretted not doing it. I feel like I should make a list of things that fit that structure.

+ +

I've never regretted committing in Git ever. That's been great. I've always been able to unwind it, but I've never been able to not unwind it or the opposite. I've regretted not committing. I have not regretted committing. I have regretted not writing out my hypothesis or approach. I have not regretted doing it. And so, yeah, this feels like it falls firmly in that category of like, it's worth just a tiny bit of structure. There's a reason it is the scientific method.

+ +

STEPH: Yeah, I agree. I've not regretted documenting upfront what it is I look to achieve and how I think I'm going to answer the question. That has been immensely helpful. Because then I also forget, like, two weeks ago, I'll be like, wasn't there a question around why this was happening, and I need to understand? And all of that was so context-heavy that as soon as I'm out of the thick of it, I completely forget it. So if I care about it deeply or if I want to be able to revisit it, then I need to document it for myself.

+ +

It's given me a lot of empathy for people who do more scientific research around, oh my gosh, like, you have to document everything you do and then still be able to prove it five years from now or however long. I'm just throwing out numbers. And it needs to be organized enough that someone, if they do question your research that, then you have it there. My research documents would not withstand scrutiny at this point because they are still just more personal notes. But yes, it's given me a lot of empathy and respect for people who do run very serious research, experiments, and trials, and then have to be able to prove it to the world.

+ +

Pivoting just a bit, there's a particular topic that resonated with both you and I; in fact, it's a particular tweet. And, Louie, I do apologize if I mispronounce your last name, but Louie Bacaj. And we'll include a link in the show notes to the tweet, but Louis shared, "I managed multiple engineering teams before quitting tech. Now that I quit, I can speak freely. Here are 12 things your manager may not be telling you, but I know for a fact will help you."

+ +

So there are a number of interesting discussions and comments that are in this thread. The one thing in particular that really caught my attention is number 10, and it's "Advocate for junior developers." So they said that their friend reminded them that just because you don't have 10-plus years of experience does not mean that they won't be good. Without junior engineers on the team, no one will grow. Help others grow; you'll grow too.

+ +

And that's the part that I love so much is that without junior engineers on the team, no one will grow because that was very thought-provoking for me. It's something that I find that I agree with deeply, but I hadn't really considered why I agree with that so much. So I'm excited to dive into that topic with you. And then, as a second topic to go along with that is, can juniors start with a remote team? I think that's one of the other questions when you and I were chatting about this. And I'm intrigued to hear your thoughts.

+ +

CHRIS: A bunch of stuff there. Starting with the tweet, I love elements of this. Some of it feels like it's intentionally somewhat provocative. So like, without junior engineers on the team, no one will grow. That feels maybe a little bit past the bar because I think we can technically grow, and we can build things and whatnot. But I think what feels deeply true to me is truly help others grow; you'll grow too. The act of mentoring, of guiding, of training, of helping someone on their journey will inherently help you grow and, I think, change the way that you think about the work.

+ +

I think the beginner mind, the earlier in the career folks coming into a codebase, they will see things fundamentally differently in a really useful way. It's possible that along your career, you've just internalized things. You've been like, yeah, no, that was weird. But then I smashed my head against it for a while, and now I understand this thing. And it just makes sense to me. But it's like, that thing actually doesn't make sense. You have warped your mind to match the thing, not, quote, unquote, "come to understand it." This is sounding too judgmental to people who've been in the industry for a while, but I found this of myself.

+ +

Or I can just take for granted things that took a long time to adapt my head to, and if anything, maybe I should have pushed back a little more. And so, I find that junior engineers can be a really fantastic lens for the complexity of a project. Like, the world is truly a complex place, and that's just true. But our job as software engineers is to tame that complexity and manage it. And so, I love the mindset that can come or the conversations that can come out of that.

+ +

And it's much like test-driven development is a pressure on the complexity of your code, having junior engineers join the team and needing to explain how all of the different features work, and what the overall architecture is, and the message passing under this and that, it's a really useful conversation to have. And so that "Help others grow; you'll grow too" feels deeply, deeply true to me.

+ +

STEPH: Yeah, I couldn't agree more in regards to how juniors really help our team and especially, as you mentioned, with complexity and ¬having those conversations. Some of the other things that have come to mind for me as well around the importance of having junior developers on your team...and maybe it's not specifically they're junior developers but that you just have a variety of experience on your team. It's going to help you lean into a culture of learning because you have people that are at different stages of their career.

+ +

And so you want an environment where people can learn together, that they can fail together, and they can be public about it. And having people that are at different stages of their career will lead, well, at least ideally, it'll lead to more pair programming. It's going to lead to more productive code reviews because then people can ask more questions around why did you choose this, or why are you doing that? Versus if everybody is at the same level, then they may just intuitively have reasons that they think someone did something.

+ +

But it takes someone that's a bit new to say, "Hey, why did you choose this?" or to bring up some other ideas or ways that they could pursue it. They may bring in new ideas for, like, why has the team always done something this way? Let's think about new ways that we could do this. Or maybe this is really unfriendly, the way that we're doing this, not just for junior people but for people that are new to the team.

+ +

And then there's typically less knowledge siloing because then you're going to want to pair the newer folks with the more experienced folks. So that way, you don't have this more senior developer who's then off in a corner working by themselves. And it's going to improve your communication skills. There's just...I realized I'm just rambling because I feel like there are so many benefits that go along with having a variety of people on your team, especially in terms of experience. And that just leads to such a better learning environment and, ultimately, better software and better products.

+ +

And yet, I find that so many companies won't embrace people that are newer to software. They always want the senior developers. They want the 10x-er or whatever those are. They want the people that have many, many years of experience. And there's so much value that comes from mentoring the next group of developers. And it's incredibly frustrating to me that one, companies often aren't open to it. But honestly, more than that, as long as you're upfront and honest about like, hey, this is the team that we need right now to build what we're looking to build, I can get past that; I can understand that. But please don't then mislead people and say that you're a junior-friendly team, and then not be prepared.

+ +

I feel like some teams will go so far as to say, "Yes, we are junior-friendly," and they may even tweak their interview process to where it is a bit more junior-friendly. But then, by the time that person joins the team, they're really not prepared. They don't have an onboarding plan. They don't have a mentorship plan. And then they fail that person because that person has worked hard to get there. And they've worked hard to bring that person onto the team, but then they don't have a plan from there.

+ +

And I've seen it too many times. And it just frustrates me so much because it puts that junior person in such a vulnerable state where they really have to be an incredible self-advocate to then overcome those hurdles from a lack of preparation on that company's part. Okay, I think that's my event. I'm sure I could vent about this a lot more, but I will cut it off there. That's the heart of it.

+ +

CHRIS: I do think, like, with anything else, it's something that we have to be intentional about. And so what you're saying of like, yeah, we're a junior-friendly company, but then you're just hiring folks, trying to find folks that may work at a slightly lower pay grade, and that's what that means to you. So like, no, no, that's not what this is. This needs to be something different. We need to have a structure and an organization that can support folks at different points in their career.

+ +

But it's interesting to me to think about the sort of why of it. And the earlier part of this conversation, we talked about some of the benefits that can come organizationally from it, and I do sincerely believe in that. But I also believe that it is fundamentally one of the best ways to find really talented people early on in their career and be in a position to hire them where maybe later on in their career, that just wouldn't happen naturally. And I've seen this play out in a number of organizations.

+ +

I went to Northeastern University for my college, and Northeastern is famous for the co-op program. Northeastern sounds really fancy. Now I learned that they have like a 7% acceptance rate for college applications right now, which is wildly low. When I went to Northeastern, it was not so fancy. So just in case anyone's hearing that and they're like, "Oh, Northeastern, wow." I'm not that fancy. [laughs]

+ +

But they did have the co-op then, and they still have it now. And the co-op really is a differentiating thing. You do three six-month rotations. And it is this fundamental differentiator in terms of when you're graduating. Particularly, I was in mechanical engineering. I came out, and I actually knew what that meant in the world. And I'd used Outlook, and I knew what a water cooler was and how to talk near one because that's a critical thing to learn in the world. And really transformative experience for me.

+ +

But also, a thing that I observed was many of my friends ended up working at companies that they had co-opted for. I'm one of those people. I would say more than 50% of my friends ended up with a position at a company that they had done a co-op rotation with. And it really worked out fantastically. That organization and the individual got to try things out, experience. And then, I ended up staying at that company for a number of years, and it was a wonderful experience. But I don't know that I would have ended up there otherwise. That's not necessarily the way that would have played out.

+ +

And similarly like, thoughtbot has the apprenticeship. And I have seen so many wonderful developers start at that very early point in their career. And there was this wonderful structure around them joining the thoughtbot team, intentional, structured, supported. And then those folks went on to be some of the most talented developers that I've ever worked with at a wonderfully talented organization. And so the story of like, you should do this, organizations. This is a thing that you should invest in for yourself, not just for the individual, like, for both. Everybody wins in this case, in my mind.

+ +

I will say, though, in terms of transparency, I currently manage a team of three developers. And we hired very intentionally for senior folks this early on in where we're at. And that was an intentional choice because I do believe that if you're going to be hiring more junior developers, that needs to be something that you do very intentionally, that you have a support structure in place, that you're able to invest the time in where they're at and make sure we have sort of...

+ +

I think a larger team makes more sense to bring juniors into broadly. That's the thing that I'm saying out loud that I'm like, I should push on that a little bit. Is that true? Do I really believe that? But I think so, my actions obviously point to it. But it is an interesting trade-off space of how do you think about that? My hope is that as we grow as an organization, that we would then very intentionally start hiring folks in a more junior, mid-level to junior and be very intentional about how we support them, bring them into the organization, et cetera. I do believe it is a win-win situation for everyone when done with intention and with focus.

+ +

STEPH: That's such an interesting bit that you just said because I very much appreciate when companies recognize do we have the bandwidth to support someone that's more junior? Because at thoughtbot, we go through periods where we don't have our apprenticeship that's open because we recognize we're not in a place that we can support someone. And we don't want to bring someone in unless we can help them be successful. I very much admire that and appreciate that about companies when they can perform that self-assessment.

+ +

I am so intrigued. You'd mentioned being a smaller team. So you more intentionally hire senior developers. And I think that also makes sense because then you need to build up who's going to be in that mentorship pool? Because then people could leave, people could take vacations, and so then you need to have that support system in place. But yeah, I don't know what that then perfect balance is. It's like, okay, so then as soon as you have like five people available to mentor or interested in mentorship, it's like, then do you start bringing in the conversation of like, let's bring in someone that we can help build up and help them be successful and join our team? And I don't know what that magical number is.

+ +

I do think it's important for teams to reflect to say, "Can we take on someone that's junior?" All the benefits of having someone that's junior. And then just being very honest and then having a plan for once that junior person does arrive. What does their career path look like while they've joined that team, and who's going to be that person that's going to help them level up? So not only make that choice upfront of yes, we are bringing someone on but let's also think about like the first six months of their work here at the company and what that's going to look like.

+ +

It feels like an important step that a lot of companies fail to do. And I think that's why there are so many articles that then are like, hey, if you're a junior dev, here's all the things that you should do to be the best junior dev. That's fabulous. And we're constantly shoring up junior devs to be like, hey, here's all the things that you need to be great at. But we don't have as many conversations around; hey, here's all the things that your manager or the rest of your team should be great at to then support you equally as you are also doing your best to meet them. Like, they need to meet you halfway.

+ +

And I'm not completely unsympathetic to the plight; I understand. It's often where I've seen with teams the more senior developers that have very strong mentorship communication skills are then also the teammates that get pulled into all the meetings and all the different projects, so then they are less available to be that mentor. And then that's how this often fails. So I don't think anybody is going into this intentionally, but yet, it's what happens for when someone is new and joining a team, and it hasn't been determined the next six months what that person's onboarding and career path looks like.

+ +

Circling back just a bit, there's the question around, can juniors start with a remote team? I can go first. And I'm going to say unequivocally yes. There's no reason a junior can't start with a remote team. Because all the things that I feel strongly about come down to how is your team going to plan for this person? And how are they going to support this person? And all the benefits that you get from being in an office with a team, I think those do exist.

+ +

And frankly, for someone like myself, it can be easier to establish a bond with someone that you get to see each day, get to see in person. You can walk up to their desk and can say, "Hey, I've got a question for you." But I think all those benefits just need to be transferred into a remote-friendly way. So I think it does ratchet up how intentional you have to be with your team and then onboarding a junior developer. But I absolutely think it's doable, and we should do it.

+ +

CHRIS: You went with unequivocally yes as your answer. I'm going to go with a qualified maybe as my answer. I want this to be true, and I think it can be true. But I think it takes all the more intentionality than even what we've been describing. To shift the question around a little bit, what does remote work mean? It doesn't just mean we're doing the work, but we're separate. I think remote work inherently is at its best when we also are largely async first. And so that means more structured writing.

+ +

The nature of the conversation tends to be more well-formed in each interaction. So it's like I read a big document, and then I pass it over to you. And at your leisure, you respond to it with a bunch of notes, and then it comes back to me. And I think that mode of interaction, while absolutely wonderful and something that I love, I think it fits really well when you're a little bit further on in your career when you understand things a little bit better. And I think the dance of conversation is more useful earlier on and so forth.

+ +

And so, for someone who's newer to a team, I think having the ability to ask a quick question over and over is really useful to someone who's early on in their career. And remote, again, I think it's at its best when it's async. And those two are sort of at odds. And so it's that mild tension that gives me pause of like, something that I think that makes remote work great I do think is at least a hurdle that you would have to get over in supporting someone who's a little bit newer. Because I want to be deeply present for someone who's newer to their journey so that they can ask a lot of questions so that I am available to be interrupted regularly.

+ +

I loved at thoughtbot sitting next to someone and being their mentor and being like, yeah, anytime you want, just tap on my desk. If I got my headphones on, that doesn't mean I'm ignoring you; it means I just need to make the sounds go away for a minute because that's the only way my brain will work. But feel free to just tap on my desk or whatever and grab my attention for a moment. And I'm available for that. That's an intentional choice. That's breaking up my continuity of the day, but we're choosing that for a reason.

+ +

I think that's just a little harder to do in a remote context and all the more so if we're saying, hey, we're going to try this async thing where we write structured documents, and we communicate in these larger, more well-formed, communicates back and forth. But I do believe it can be done. I think it should be done. I just think it's all the harder for all of those reasons.

+ +

STEPH: I agree that definitely makes it harder. But I'm going to push a little bit and say that when you mentioned being deeply present, I think we can be deeply present with someone and be remote. We can reduce the async requirements. So if you are someone that is more senior or more accustomed to the team, you can fall back to more of those async ways to communicate.

+ +

But if someone is new, and needs more mentorship, then let's just set up time where we're going to literally hang out for a couple of hours each day or whatever pairing environment works best for them because pairing can also be exhausting. But hey, we're going to have a check-in each day; maybe we close out each day and touchpoint. And feel free to still message me and interrupt me. Like, you're going to just heighten your availability, even though it is remote. And be aware, like, hey, this person could message me at more times, and I'm okay with that. I have opted into this form of communication.

+ +

So I think we just take that mindset of, hey, there's this person next to me, and I'm their mentor to like, hey, they're not next to me, but I'm still their mentor, and I'm still here for them. So I agree that it's harder. I think it falls on us and the team and the mentors to change ourselves versus saying to juniors, "Hey, sorry, it's remote. That's not going to work for you." It totally works for them. It's us, the mentors, that need to figure out how to make it work.

+ +

I will say being on that mentor side that then not being able to see someone so if they are next to me, I can pick up on body language and facial expressions, and I can tell when somebody's stuck. And I can see that they're frustrated, or I can see that now's a good time for me to just be like, "Hey, how's it going? What are you working on? Or do you need help with something?" And I don't have that insight when I'm away. So there are real challenges like that that I don't know how to address.

+ +

I have gone the obnoxious route [laughs] where I just message people, and I'm like, "Hey, how's it going? How's it going? How's it going?" And I try not to do that too much. But I haven't found a better way to manage that other than to constantly check in because I do have less feedback from that person that I'm working with unless they are just incredibly open about sharing when they're stuck. But typically, when you're newer to a team or newer to a career, you're going to be less willing to share when you're stuck.

+ +

But yeah, there are some real challenges, but I still think it's something for us to figure out. Because otherwise, if we cut off access for remote teams to junior folks, I mean, that's where we're headed. There are so many companies and jobs that are headed remote that not being junior friendly and being remote in my mind is just not an option. It's something that we need to figure out. And it's hard, but we need to figure it out.

+ +

CHRIS: Yeah, 100% on we need to figure that out and that that's on us as the people managing and structuring and bringing folks into teams. I think my stance would be like, let's just be clear that this is hard. It takes effort to make sure that we've provided a structure in which someone newer to a team can be successful. It takes all the more effort to do so in a remote context, I think. And it's that recognition that I think is critical.

+ +

Because if we go into this with the wrong mindset, it's like, oh yeah, it's great. We got this new person on the team. And yeah, they should be ready to go in like two weeks, right? It's like, no, no, this is a different thing. We need to be very clear about it. This is going to require that we have someone who is able to work with them and support them in this. And that means that that person's output will likely be a little bit reduced for the period of time that we're talking about. But we're playing a long game here. Let's make sure we're clear on that. This is intentional.

+ +

And let's be clear, the world of hiring and software right now it's not like super easy. There aren't way more software developers than there are jobs; at least, that's been my experience. So this is something absolutely worth investing in for just core business reasons and also good for people. So hey, it's a win-win. Let's do it. Let's figure it out. But also, let's be clear that it's going to be a little tricky along the way. So, you know, let's be intentional about that. But yeah, obviously do it, got to do it.

+ +

STEPH: Wait, so I feel like we might have circled back to unequivocally yes. [laughs] Have we gotten there, or are you still on the fence?

+ +

CHRIS: I was unequivocally yes from the beginning, but I couched it in, but...yeah, I said other things. You're right. I have now come around; let's say to unequivocally yes.

+ +

STEPH: [laughs] Cool. I don't want to feel like I'm forcing you to agree with me. [laughs] But I mean, we just so rarely disagree. So we've either got to identify this as something that we disagree on, which would be one of those rare occasions like beer and Pop-Tarts.

+ +

CHRIS: A watershed moment. Beer and Pop-Tarts.

+ +

STEPH: Yeah, those are the only two so far.

+ +

[laughter]

+ +

CHRIS: Not together also. I just want to go on record beer and Pop-Tarts; I don't think would be...anyway.

+ +

STEPH: Ooh, I don't know. It could work. It could work.

+ +

CHRIS: Well, there's another thing we disagree on.

+ +

STEPH: I would not turn it down. If I was eating a Pop-Tart, and you're like, "Hey, you want a beer?" I'd be like, "Sure," vice versa. I'm drinking a beer. "Hey, you want a Pop-Tart?" "Totally."

+ +

CHRIS: Okay. Well yeah, if I'm making bad decisions, I'm obviously going to chain them together, but that doesn't mean that they're a good decision. It's just a chain of bad decisions.

+ +

STEPH: I feel like one true thing I know about you is that when you make a decision, you're going to lean into it. So like, this is why you are all about if you're going to have a Pop-Tart, you're going to have the highest sugary junk content Pop-Tart possible. So it makes sense to me.

+ +

CHRIS: It's the Mountain Dew theorem, yeah.

+ +

STEPH: I didn't know this had a theorem. The Mountain Dew theorem?

+ +

CHRIS: No, that's just my name. Well, yeah, if I'm going to drink soda, I'm going to drink Mountain Dew, the nonsense nuclear option of soda. So yeah, I guess you're describing me, although as you say it back to me, I suddenly feel very, like, oh God, is this who I am as a person? [laughs] And I'm not going to say you're wrong. I'm just going to spend a little while thinking about some stuff.

+ +

STEPH: I mean, you embrace it. I think that's lovely. You know what you want. It's like, all right, let's do this. Let's go all in.

+ +

CHRIS: Thank you for finding a wonderfully positive way to frame it here at the end. But I think on that note, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris switched from Trello over to Linear for product management and talks about prioritizing backlogs.

+ +

Steph shares and discusses a tweet from Curtis Einsmann that super resonated with the work she's doing right now: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one."

+ +
+ +

This episode is brought to you by BuildPulse. Start your 14-day free trial of BuildPulse today.

+ +
+ +

Linear
+Curtis Einsmann Tweet
+Louie Bacaj Tweet

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

AD: Flaky tests take the joy out of programming. You push up some code, wait for the tests to run, and the build fails because of a test that has nothing to do with your change. So you click rebuild and you wait. Again. And you hope you're lucky enough to get a passing build this time.

+ +

Flaky tests slow everyone down, break your flow and make things downright miserable.
+In a perfect world, tests would only break if there's a legitimate problem that would impact production. They'd fail immediately and consistently, not intermittently. But the world's not perfect, and flaky tests will happen, and you don't have time to fix them all today. So how do you know where to start?

+ +

BuildPulse automatically detects and tracks your team's flaky tests. Better still, it pinpoints the ones that are disrupting your team the most. With this list of top offenders, you'll know exactly where to focus your effort for maximum impact on making your builds more stable. In fact, the team at Codecademy was able to identify their flakiest tests with BuildPulse in just a few days. By focusing on those tests first, they reduced their flaky builds by more than 68% in less than a month!

+ +

And you can do the same because BuildPulse integrates with the tools you're already using. It supports all the major CI systems, including CircleCI, GitHub Actions, Jenkins, and others. And it analyzes test results for all popular test frameworks and programming languages, like RSpec, Jest, Go, pytest, PHPUnit, and more.

+ +

So stop letting flaky tests slow you down. Start your 14-day free trial of BuildPulse today. To learn more, visit buildpulse.io/bikeshed. That's buildpulse.io/bikeshed.

+ +

CHRIS: Good morning, and welcome to Tech Talk with Steph and Chris. Today at the top of the hour, it's tech traffic hits.

+ +

STEPH: Ooh, tech traffic. [laughs] I like that statement.

+ +

CHRIS: Yeah. The Git lanes are clogged up with...I don't know. I got nothing.

+ +

STEPH: [laughs]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Actually, I have a specific new thing that I can share, which is, as of the past week, I would say, switched from Trello over to Linear for product management. It's been great. It was a super straightforward transfer. They actually had an importer. We lost some of the comment threads on the Trello cards. But that was easy enough to like each Linear ticket has a link back to Trello. So it's easy enough to keep the continuity.

+ +

But yeah, we're in a whole new world, a system actually built for maintaining a product backlog, and, man, it shows. Trello was a bunch of lists and cards and stuff that you could link between, which was cool. But Linear is just much more purpose-built and already very, very nice. And we're very happy with the switch.

+ +

STEPH: I feel like you came in real casual with that news, but that is big news, that you did a switch.

+ +

[laughter]

+ +

CHRIS: How are you going to bury the lead like that? You switched project management...[laughter] I actually didn't think it was...I'm excited about it but low-key excited, which is weird because I do like productivity and task management software. So you would think I would be really excited about this. But I've also tried enough of them historically to know that that's never going to be the thing that actually makes or breaks your team's productivity. It can make things worse, but it can't make you great. That's the thing that I believe. And so it's a wonderful piece of software. I'm very excited about it but --

+ +

STEPH: Ooh, I like that. It can make you worse, but it doesn't make you great. That's so true, yeah, where it causes pain. Well, and it does make sense. You've been complaining a bit about the whole login with Trello and how that's been frustrating. But I haven't even heard of Linear. That's just...that's, I mean, you're just doing what you do where you bring that new-new. I haven't heard of Linear before.

+ +

CHRIS: I try to live on the cutting edge. Actually, I deeply try to not live on the cutting edge at this point in my life. That early adopter wave, no, no, no, that's not for me anymore. But I've known a few folks who've moved to Linear. And everyone that I've spoken to who has moved to it has been like, "Yeah, it's been great." I've not heard anything negative. And I've heard or experienced negative things about every other product management tool out there. And so, it seemed like an easy thing.

+ +

And it was a low-cost enough switch in terms of opportunity costs or the like, it took the effort of someone on our team moving those cards over and setting up the new system and training, but it was relatively straightforward. And yeah, we're super happy with it. And it feels different now. I feel like I can see the work in a different way which is interesting.

+ +

I think we had brought in a Chrome extension for Trello. I think it's like Hello Epics or something like that that allows...it abuses the card linking functionality in Trello and repurchases that feature as an epic management thing. But it's quarter-baked is how I would describe it, or it's clearly built on top of existing things that were not intended to be used exactly in that way. So it does a great job. Hello Epics does a great job of trying to make something like parent-child list management stuff happen in Trello. But it's always going feel like an afterthought, a secondary feature, something that's bolted on.

+ +

Whereas in Linear, it's like, no, no, we absolutely have the idea of projects, of course, and you can see burndown charts and things. And the thing that I do want to be careful about is not leaning too much into management. Linear has the idea of cycles or sprints, as many other folks think of them, or iterations or whatever you want to call them. But we've largely not been working in that mode. We've just continued to work through the next up list; that's it. The next up list should be prioritized and well defined at the top and roughly in priority order. So just pick up the next card and work on it. And we just do that every single day.

+ +

And now we're in a piece of software that has the idea of cycles, and I'm like, oh, this is vaguely interesting. Do we want to do that? Oh, but if you're going to do that, you probably do some estimation, right? And I was like, oh no, now we're into a place that's...okay, I have feelings. I got to decide how to approach that. And so, I am intrigued. And I wonder if we could just say like ten carts that's how many come into a cycle, and that's it. And we use the loosest heuristics possible to define how we structure a cycle so that we don't fall into the trap of, oh, what's our roadmap going to look like six months from now? JK, what's anything going to look like six months from now? That's not a knowable fact.

+ +

STEPH: I was just thinking where you said that you're moving into sprints or cycles, and then there's that push, well, now you got to estimate. And I just thought, do you? Do you have to estimate? [laughs]

+ +

CHRIS: We need a burndown chart through 2024, and it must be meticulously accurate down to the hour.

+ +

STEPH: I think meticulously wrong is how that goes. [laughs]

+ +

CHRIS: Which is the best kind of wrong. If you're going to be wrong, be meticulous about it.

+ +

STEPH: Be thorough about it. [laughs] Yeah, the team that I'm on right now, we have our bi-weekly planning, and we go through the board, and we pull stuff in. But there's never a discussion about estimation. And I hadn't really appreciated that until just now. How we don't think about how long is this going to take? We just talked about, well, what's in-flight? And how much work do people still have going on? And then here's the list of things we can pull in. But there's always a list that you can go back to.

+ +

Like, it's very...we pull in the minimum and knowing that if we run out of work, there's another place to go where there's stuff that's organized. And I just love that cadence, that idea of like, let's not try to make guesses about the future; let's just have it lined up and ready for us to go when we're ready to pull it in. Although I know, that's also coming from a very developer's perspective, and there are product managers who are trying to communicate as to when features are going to get out into the world. So I get that there's a balance, but I still have strong feelings and hesitations around estimating work.

+ +

CHRIS: Well, I feel like there is a balance there. And so many things in history are like, well, this is an overcorrection against that, and that's an overcorrection against this. And the idea that we can estimate our work that far out into the future that's just obviously false to me based on every project I've ever worked on that has tried to do it. And it has always failed without question.

+ +

But critically, there is the necessity to sync up work and like, oh, marketing needs to plan the launch of this feature, and it's a critical one. What's it going to look like? When's it going to be ready? You know, we're trying to go for an event, it's not just know...we developers never estimate anything past the immediate moment where like, that's not acceptable. We got to find a middle ground here. But where that middle ground is, is interesting. And so, just operating in the sort of we do work as it comes up is the easiest thing because no one's lying about anything at that point.

+ +

But sometimes you got to make some guesses and make some estimations. And then it gets into the murky area of I believe with 75% confidence that in three weeks, we will have this feature ready. But to be clear, I said with 75% confidence that means one-quarter of the time; we will not be there at that date. What does that mean? What does that failure mode look like? Let's talk about that. And can you have honest, open, transparent, useful conversations there? That's the space that it becomes more subtle if you need to do that.

+ +

STEPH: You're reminding me of a conversation that I had with someone where they shared with me some very aggressive team goals. And it was a very friendly conversation. And they're like, "How do you feel about aggressive goals?" And I was like, "Well, it depends. How do you feel about aggressive failure?" Because then once I know where you stand there, then we can talk about aggressive goals. Now, if we're being aggressive, but then we fail to achieve that, and it's one of those, okay, we didn't meet the goal that we'd expected, but everything is fine, and it's not a big deal, then I am okay. Sure, let's shoot for the stars.

+ +

But if it's one of those, we are communicating these goals to the outside world, and it's going to become incredibly important that we meet these goals, and if we don't, then things are going to go on fire, people are going to be in trouble, and it's just going to be awful, then let's not set aggressive goals. Let's not box ourselves into a space where we are setting ourselves up to fail or feel pain in a meaningful way. I agree that estimations are important, especially in terms of you need to collaborate with other departments, and then also just to provide some sense of where the product is headed and when things may be released.

+ +

I think estimations then just become problematic when they do become definite, and they're based on so many unknowns, and then when I don't know is not an answer. So if someone asked, "What's your estimate for this?" And the very honest real answer is I don't know, like, we haven't done this type of work before, or these are all the unknowns, and then someone's like, "Well, let's just put an estimation of like two weeks on it," and they just sort of try to force-fit it into being what they want, then that's where it starts to just feel incredibly problematic.

+ +

CHRIS: Yeah, estimation is a very murky area that we could spend entire episodes talking about, and in fact, I think we have a handful of times. So with that, Linear has been great. We're going to see just how much or how little estimation we actually want to do. But it's been a very nice addition to the toolset. And I'll let you know as we deepen our usage of it what the experience is like, but that's the main thing that's new in my world. What's new in your world?

+ +

STEPH: Well, before we bounce over to my world, you said something that has intrigued me that has also made me start reflecting on some of the ways that I like to work. And you'd mentioned that you have this prioritized backlog that people are pulling tickets from. And I don't know exactly if there's a planning session or how that looks, but I have recognized that when I am working with a team, and we don't have any planning session, if everybody is just pulling from this backlog, that's being prioritized by someone on the team, that I find that a bit overwhelming.

+ +

Because the types of work being done can vary so drastically that I find I'm less able to help my colleagues or my teammates because I don't have the context for what they're working on. It surprises me. I'm like, oh, I didn't even know we're working on that feature, or I don't have the context for what's the problem that we're trying to solve here. And it makes it just a lot harder to review and then have conversations with them. And I get overwhelmed in that environment.

+ +

And I've recognized that about myself based on previous projects that were more similar to that versus if I'm on a project where the team does get together every so often, even if it's high level to be like, hey, here's the theme of the tickets that we're working on, or here's just some of the stuff, then I feel much more prepared for the work that is coming in and to be able to context switch and review. And yeah, so I've kind of learned that about myself. I'm curious, are you similar, or how does that work for you?

+ +

CHRIS: I'm definitely similar. And I think probably the team is closer to what you're describing. So we do have a planning session every week, just a quick 30-minute scan through the backlog, look at the things that are coming up and also the larger themes. Previously, Epics and Trello now projects and Linear. But talking about what are the bigger pieces of work that we're moving on, and then what are the individual tickets associated with that that we'll be expecting to work on in the next week? And just making sure that everyone has broad clarity around what that feature set is.

+ +

Also, we're a very small team at this point. Still, we're four people total, but one of the developers is on a break for a couple of weeks this summer. And so there are really only three of us that are driving on the code. And so, with three of us working on the projects, we try very intentionally to have significant overlap between the various...like, we don't want any one person to own any portion of things at this point. And so we're doing a good amount of pairing to cross-pollinate and make sure everyone's...not everyone's aware of everything, but at least one other person is sufficiently aware of everything between the three of us. And I think that's been working well.

+ +

I don't think we have any major gaps, save for the way that we're doing our mobile architecture that's largely managed by one of the developers on the team and a contractor that we're working with to help do a lot of the implementation. That's a known we chose to silo that thing. We've accepted the cost of that for now. And architecturally, the rest of us are aware of it, but we're not like in the Swift code writing anything because I don't know how to write Swift at this point. I'd love to learn it. I hear good things about the language.

+ +

[12:26]

+ +

So yeah, I think conceptually very similar to what you're describing of still want to have people be able to review. Like, I don't want to put up a PR and people be like, I don't know, that looks like code, I guess. I'm not sure what it does. Like, I want it to be very...I want us all to be roughly on the same page, and thus far, we are.

+ +

As the team grows, that will become trickier to maintain because there are just inherently probably more things that are moving, more different feature areas and surface area that we're tackling in any given week, or there are different ways to approach that. I know you've talked about having a limited number of themes for a given cycle, so that's an idea that can pop up. But that's something that we'll figure out as we get further. I think I'm happy with where we're at right now, so yeah, that's the story there.

+ +

STEPH: Okay, cool. Yeah, all of that resonates with me, and thinking about it a little more deeply in this moment, I'm realizing I think something you said helped me put this together where when I'm reviewing someone's change, I'm not necessarily just looking to see does your code work? I'm going to trust you that your code works. I may have thoughts about design and other things, but I really want to understand more what's the change to the product that we're making? What's the goal that we're looking to achieve? How are we measuring this?

+ +

And so if I don't have that context, that's what contributes to that feeling of like, hard context switching of not just context switching, but now I have to level myself up to then understand the problem that's being solved by this. Versus had I known some of the themes going into that particular cycle or sprint, I would have felt far more prepared for that review session versus having to then dig through all the data and/or tickets or talk to someone.

+ +

Well, switching back to what's going on in my world, I have a particular tweet that I want to share, and it's one that Joël Quenneville brought to my attention. And it just resonates so much with all the type of work that I'm doing right now. So I'm going to read the tweet, and then we'll link to it in the show notes as well. But it's from Curtis Einsmann, and Curtis wrote: "In software engineering, rabbit holes are inevitable. You will research libraries and not use them. You'll write code just to delete it. This isn't a waste; sometimes, you need to go down a few wrong paths to get to the right one."

+ +

And that describes all the work that I'm doing right now. It's a lot of exploratory, a lot of data-driven work, and finding ways that we can reduce the time that it takes to run RSpec on CI. And it also ties in nicely to one of the things that I think we talked about last week, where we discovered that a number of files have a high runtime variance. And I've really dug into the data there to understand, okay, is it always specific files that have these high runtime variants? Are there any obvious contributions to what's causing this? Are we making real network calls that then could sometimes take a long time to return? And the result is there's nothing obvious.

+ +

They're giant files. The number of SQL commands that are being run for each file varies drastically. They're all high, but it's still very different. There's no single fact about these files that has really been like, yes, this is what's causing these files to have such a runtime variance. And so while I've been in the data, I'm documenting it, and I'm making a list and putting it all together in a ticket so at least it's there to look at later. But I'm going to move on. It's one of those I would love to know what's causing this. I would love to address it because it would put us in an ideal state for how we're distributing tests, which would have a significant impact on our runtime.

+ +

But it also feels a little bit like chasing my tail because I'm worried, like with some of the other experiments that we've done in the past where we've addressed tentpoles, that as soon as you address the issue for one or two files, then other files start having the same problem. And you're just going to continue to chase and chase, and I don't want to be in that. So upfront, this was one of those; hey, let's look at the data. If there's something obvious, let's address it; if not, move on. So I'm at that point today where I'm wrapping up all of that data, and then I'm going to move on, move on to the next thing.

+ +

CHRIS: There's deep truth in that tweet that you shared at the start of this segment. The idea like if we knew the work that we had to do at the front, yeah, we would just do that, but often, we don't. And so, being able to not treat it as a failure when something doesn't work out is, I think, so critical. I think to expand on the idea just a tiny bit, the idea of the scientific method, failure is totally an option and is part of science.

+ +

I remember watching MythBusters, and Adam Savage is just kind of like, "Failure is always an option," and highlighting that as part of it. Like, it's an outcome. You've learned something. You have a new data point. You can take that and then carry it forward with you. But it's rough in the moment. And so, I do think that this is a worthwhile thing to meditate on. And it's something that I've had to revisit a handful of times in my career of just like, man, I feel like I've just been spinning my tires all week. I'm like, we know what we want to get done, but just each approach I take isn't working for one reason or another.

+ +

And then, finally, you get to the end. And then you've got this paragraph-long summary of all the things that didn't work in your PR and one-line change sort of thing. And those are painful, but they're part of the game. Like, that is unavoidable. I have not found a way to just know how to do the work upfront always. I would love that. I would sign up for whatever seminar was selling that. I wouldn't. I would know that that seminar is a lie, actually. But broadly, I'm intrigued by the idea if someone were selling that, I'd be like, well, I mean, pitch me on it. Tell me why I should believe you; I don't, just to be clear. But yeah.

+ +

STEPH: This project has really helped me embrace always setting a goal or a question upfront about what I'm wanting to achieve or what I'm looking to answer because a number of times while Joël and I have been spelunking through data...And then so originally, with the saga, we started out with why doesn’t our math match reality? We understand that if these tests are distributed perfectly across the CPUs, then that should cut the runtime in half. But yet, we weren't seeing that even though we had addressed the tentpoles.

+ +

So we dug into understanding why. And the answer is because they're not perfectly distributed, and it's because of the runtime variance. And that was a critical moment to look back and say, "Did we achieve the goal?" Yes, we identified the problem. But once you see a problem, it's just so easy to dig in and keep going. It's like, well, now I want to know what's causing these files to have a runtime variance.

+ +

But it's one of those we achieved our goal. We acknowledged upfront that we wanted to at least understand why. Let's make a second decision, do we keep going? And I'm at that point where, frankly, I probably dug in a little more than I should because I'm stubborn. But I'm recognizing that now's the time to back away and then go back and move on to the next high-priority item, which is converting for funsies; I'll share.

+ +

The next thing is converting Test::Unit test over to RSpec because we have, I think, around 25 tests that are written in Test::Unit. And we want to move them over to RSpec because that particular just step in the build process takes a good three to four minutes. And part of that is just booting up Rails and then running the tests very fast. And we're underutilizing the machine that's running them because it's only 25 tests, but there are 86 CPUs to run it.

+ +

So we'd really like to combine those 25 tests with the rest of the RSpec suite and drop that step. So then that should add minimal time to the overall build but then should take us down at least a couple of minutes. And then also makes it easier to manage and help folks so that way, there's one consistent testing framework that's in use versus having to manage some of these older tests.

+ +

CHRIS: It's funny; I think it was just two episodes back where we talked about why RSpec, and I think both of us were just like, well yeah. But I mean, if there are tests and another, like, it's fine, you just leave them with the exception that if there's like 2% of our tests are in Test::Unit, and everything else is in RSpec, yeah, maybe that that conversion efforts seem totally worth it.

+ +

But again, I think as you're describing that, what I'm hearing is just like the scientific method, just being somewhat structured in the approach to what's the hypothesis? And what's the procedure we're going to use to determine if that hypothesis is true or false? And then what do we do? And then what are the results? And then you just do that on loop. But being not just sort of exploring. Sometimes you have to be on exploratory mode. But I definitely find that that tiny bit of rigor of just like, wait, okay, before I actually do anything, what do I think is going on here? What's my guess?

+ +

And then, okay, if that guess were true, what would I be able to observe in the world? Okay, here we go. And just that tiny bit of structure is so...it sometimes feels highly formal to go into that mode and be like, no, no, no, let me take a step back. Let me write down my thoughts. I'm going to have a little checklist and do the thing. But I've never regretted doing it. I will say that. I have deeply regretted not doing it. I feel like I should make a list of things that fit that structure.

+ +

I've never regretted committing in Git ever. That's been great. I've always been able to unwind it, but I've never been able to not unwind it or the opposite. I've regretted not committing. I have not regretted committing. I have regretted not writing out my hypothesis or approach. I have not regretted doing it. And so, yeah, this feels like it falls firmly in that category of like, it's worth just a tiny bit of structure. There's a reason it is the scientific method.

+ +

STEPH: Yeah, I agree. I've not regretted documenting upfront what it is I look to achieve and how I think I'm going to answer the question. That has been immensely helpful. Because then I also forget, like, two weeks ago, I'll be like, wasn't there a question around why this was happening, and I need to understand? And all of that was so context-heavy that as soon as I'm out of the thick of it, I completely forget it. So if I care about it deeply or if I want to be able to revisit it, then I need to document it for myself.

+ +

It's given me a lot of empathy for people who do more scientific research around, oh my gosh, like, you have to document everything you do and then still be able to prove it five years from now or however long. I'm just throwing out numbers. And it needs to be organized enough that someone, if they do question your research that, then you have it there. My research documents would not withstand scrutiny at this point because they are still just more personal notes. But yes, it's given me a lot of empathy and respect for people who do run very serious research, experiments, and trials, and then have to be able to prove it to the world.

+ +

Pivoting just a bit, there's a particular topic that resonated with both you and I; in fact, it's a particular tweet. And, Louie, I do apologize if I mispronounce your last name, but Louie Bacaj. And we'll include a link in the show notes to the tweet, but Louis shared, "I managed multiple engineering teams before quitting tech. Now that I quit, I can speak freely. Here are 12 things your manager may not be telling you, but I know for a fact will help you."

+ +

So there are a number of interesting discussions and comments that are in this thread. The one thing in particular that really caught my attention is number 10, and it's "Advocate for junior developers." So they said that their friend reminded them that just because you don't have 10-plus years of experience does not mean that they won't be good. Without junior engineers on the team, no one will grow. Help others grow; you'll grow too.

+ +

And that's the part that I love so much is that without junior engineers on the team, no one will grow because that was very thought-provoking for me. It's something that I find that I agree with deeply, but I hadn't really considered why I agree with that so much. So I'm excited to dive into that topic with you. And then, as a second topic to go along with that is, can juniors start with a remote team? I think that's one of the other questions when you and I were chatting about this. And I'm intrigued to hear your thoughts.

+ +

CHRIS: A bunch of stuff there. Starting with the tweet, I love elements of this. Some of it feels like it's intentionally somewhat provocative. So like, without junior engineers on the team, no one will grow. That feels maybe a little bit past the bar because I think we can technically grow, and we can build things and whatnot. But I think what feels deeply true to me is truly help others grow; you'll grow too. The act of mentoring, of guiding, of training, of helping someone on their journey will inherently help you grow and, I think, change the way that you think about the work.

+ +

I think the beginner mind, the earlier in the career folks coming into a codebase, they will see things fundamentally differently in a really useful way. It's possible that along your career, you've just internalized things. You've been like, yeah, no, that was weird. But then I smashed my head against it for a while, and now I understand this thing. And it just makes sense to me. But it's like, that thing actually doesn't make sense. You have warped your mind to match the thing, not, quote, unquote, "come to understand it." This is sounding too judgmental to people who've been in the industry for a while, but I found this of myself.

+ +

Or I can just take for granted things that took a long time to adapt my head to, and if anything, maybe I should have pushed back a little more. And so, I find that junior engineers can be a really fantastic lens for the complexity of a project. Like, the world is truly a complex place, and that's just true. But our job as software engineers is to tame that complexity and manage it. And so, I love the mindset that can come or the conversations that can come out of that.

+ +

And it's much like test-driven development is a pressure on the complexity of your code, having junior engineers join the team and needing to explain how all of the different features work, and what the overall architecture is, and the message passing under this and that, it's a really useful conversation to have. And so that "Help others grow; you'll grow too" feels deeply, deeply true to me.

+ +

STEPH: Yeah, I couldn't agree more in regards to how juniors really help our team and especially, as you mentioned, with complexity and ¬having those conversations. Some of the other things that have come to mind for me as well around the importance of having junior developers on your team...and maybe it's not specifically they're junior developers but that you just have a variety of experience on your team. It's going to help you lean into a culture of learning because you have people that are at different stages of their career.

+ +

And so you want an environment where people can learn together, that they can fail together, and they can be public about it. And having people that are at different stages of their career will lead, well, at least ideally, it'll lead to more pair programming. It's going to lead to more productive code reviews because then people can ask more questions around why did you choose this, or why are you doing that? Versus if everybody is at the same level, then they may just intuitively have reasons that they think someone did something.

+ +

But it takes someone that's a bit new to say, "Hey, why did you choose this?" or to bring up some other ideas or ways that they could pursue it. They may bring in new ideas for, like, why has the team always done something this way? Let's think about new ways that we could do this. Or maybe this is really unfriendly, the way that we're doing this, not just for junior people but for people that are new to the team.

+ +

And then there's typically less knowledge siloing because then you're going to want to pair the newer folks with the more experienced folks. So that way, you don't have this more senior developer who's then off in a corner working by themselves. And it's going to improve your communication skills. There's just...I realized I'm just rambling because I feel like there are so many benefits that go along with having a variety of people on your team, especially in terms of experience. And that just leads to such a better learning environment and, ultimately, better software and better products.

+ +

And yet, I find that so many companies won't embrace people that are newer to software. They always want the senior developers. They want the 10x-er or whatever those are. They want the people that have many, many years of experience. And there's so much value that comes from mentoring the next group of developers. And it's incredibly frustrating to me that one, companies often aren't open to it. But honestly, more than that, as long as you're upfront and honest about like, hey, this is the team that we need right now to build what we're looking to build, I can get past that; I can understand that. But please don't then mislead people and say that you're a junior-friendly team, and then not be prepared.

+ +

I feel like some teams will go so far as to say, "Yes, we are junior-friendly," and they may even tweak their interview process to where it is a bit more junior-friendly. But then, by the time that person joins the team, they're really not prepared. They don't have an onboarding plan. They don't have a mentorship plan. And then they fail that person because that person has worked hard to get there. And they've worked hard to bring that person onto the team, but then they don't have a plan from there.

+ +

And I've seen it too many times. And it just frustrates me so much because it puts that junior person in such a vulnerable state where they really have to be an incredible self-advocate to then overcome those hurdles from a lack of preparation on that company's part. Okay, I think that's my event. I'm sure I could vent about this a lot more, but I will cut it off there. That's the heart of it.

+ +

CHRIS: I do think, like, with anything else, it's something that we have to be intentional about. And so what you're saying of like, yeah, we're a junior-friendly company, but then you're just hiring folks, trying to find folks that may work at a slightly lower pay grade, and that's what that means to you. So like, no, no, that's not what this is. This needs to be something different. We need to have a structure and an organization that can support folks at different points in their career.

+ +

But it's interesting to me to think about the sort of why of it. And the earlier part of this conversation, we talked about some of the benefits that can come organizationally from it, and I do sincerely believe in that. But I also believe that it is fundamentally one of the best ways to find really talented people early on in their career and be in a position to hire them where maybe later on in their career, that just wouldn't happen naturally. And I've seen this play out in a number of organizations.

+ +

I went to Northeastern University for my college, and Northeastern is famous for the co-op program. Northeastern sounds really fancy. Now I learned that they have like a 7% acceptance rate for college applications right now, which is wildly low. When I went to Northeastern, it was not so fancy. So just in case anyone's hearing that and they're like, "Oh, Northeastern, wow." I'm not that fancy. [laughs]

+ +

But they did have the co-op then, and they still have it now. And the co-op really is a differentiating thing. You do three six-month rotations. And it is this fundamental differentiator in terms of when you're graduating. Particularly, I was in mechanical engineering. I came out, and I actually knew what that meant in the world. And I'd used Outlook, and I knew what a water cooler was and how to talk near one because that's a critical thing to learn in the world. And really transformative experience for me.

+ +

But also, a thing that I observed was many of my friends ended up working at companies that they had co-opted for. I'm one of those people. I would say more than 50% of my friends ended up with a position at a company that they had done a co-op rotation with. And it really worked out fantastically. That organization and the individual got to try things out, experience. And then, I ended up staying at that company for a number of years, and it was a wonderful experience. But I don't know that I would have ended up there otherwise. That's not necessarily the way that would have played out.

+ +

And similarly like, thoughtbot has the apprenticeship. And I have seen so many wonderful developers start at that very early point in their career. And there was this wonderful structure around them joining the thoughtbot team, intentional, structured, supported. And then those folks went on to be some of the most talented developers that I've ever worked with at a wonderfully talented organization. And so the story of like, you should do this, organizations. This is a thing that you should invest in for yourself, not just for the individual, like, for both. Everybody wins in this case, in my mind.

+ +

I will say, though, in terms of transparency, I currently manage a team of three developers. And we hired very intentionally for senior folks this early on in where we're at. And that was an intentional choice because I do believe that if you're going to be hiring more junior developers, that needs to be something that you do very intentionally, that you have a support structure in place, that you're able to invest the time in where they're at and make sure we have sort of...

+ +

I think a larger team makes more sense to bring juniors into broadly. That's the thing that I'm saying out loud that I'm like, I should push on that a little bit. Is that true? Do I really believe that? But I think so, my actions obviously point to it. But it is an interesting trade-off space of how do you think about that? My hope is that as we grow as an organization, that we would then very intentionally start hiring folks in a more junior, mid-level to junior and be very intentional about how we support them, bring them into the organization, et cetera. I do believe it is a win-win situation for everyone when done with intention and with focus.

+ +

STEPH: That's such an interesting bit that you just said because I very much appreciate when companies recognize do we have the bandwidth to support someone that's more junior? Because at thoughtbot, we go through periods where we don't have our apprenticeship that's open because we recognize we're not in a place that we can support someone. And we don't want to bring someone in unless we can help them be successful. I very much admire that and appreciate that about companies when they can perform that self-assessment.

+ +

I am so intrigued. You'd mentioned being a smaller team. So you more intentionally hire senior developers. And I think that also makes sense because then you need to build up who's going to be in that mentorship pool? Because then people could leave, people could take vacations, and so then you need to have that support system in place. But yeah, I don't know what that then perfect balance is. It's like, okay, so then as soon as you have like five people available to mentor or interested in mentorship, it's like, then do you start bringing in the conversation of like, let's bring in someone that we can help build up and help them be successful and join our team? And I don't know what that magical number is.

+ +

I do think it's important for teams to reflect to say, "Can we take on someone that's junior?" All the benefits of having someone that's junior. And then just being very honest and then having a plan for once that junior person does arrive. What does their career path look like while they've joined that team, and who's going to be that person that's going to help them level up? So not only make that choice upfront of yes, we are bringing someone on but let's also think about like the first six months of their work here at the company and what that's going to look like.

+ +

It feels like an important step that a lot of companies fail to do. And I think that's why there are so many articles that then are like, hey, if you're a junior dev, here's all the things that you should do to be the best junior dev. That's fabulous. And we're constantly shoring up junior devs to be like, hey, here's all the things that you need to be great at. But we don't have as many conversations around; hey, here's all the things that your manager or the rest of your team should be great at to then support you equally as you are also doing your best to meet them. Like, they need to meet you halfway.

+ +

And I'm not completely unsympathetic to the plight; I understand. It's often where I've seen with teams the more senior developers that have very strong mentorship communication skills are then also the teammates that get pulled into all the meetings and all the different projects, so then they are less available to be that mentor. And then that's how this often fails. So I don't think anybody is going into this intentionally, but yet, it's what happens for when someone is new and joining a team, and it hasn't been determined the next six months what that person's onboarding and career path looks like.

+ +

Circling back just a bit, there's the question around, can juniors start with a remote team? I can go first. And I'm going to say unequivocally yes. There's no reason a junior can't start with a remote team. Because all the things that I feel strongly about come down to how is your team going to plan for this person? And how are they going to support this person? And all the benefits that you get from being in an office with a team, I think those do exist.

+ +

And frankly, for someone like myself, it can be easier to establish a bond with someone that you get to see each day, get to see in person. You can walk up to their desk and can say, "Hey, I've got a question for you." But I think all those benefits just need to be transferred into a remote-friendly way. So I think it does ratchet up how intentional you have to be with your team and then onboarding a junior developer. But I absolutely think it's doable, and we should do it.

+ +

CHRIS: You went with unequivocally yes as your answer. I'm going to go with a qualified maybe as my answer. I want this to be true, and I think it can be true. But I think it takes all the more intentionality than even what we've been describing. To shift the question around a little bit, what does remote work mean? It doesn't just mean we're doing the work, but we're separate. I think remote work inherently is at its best when we also are largely async first. And so that means more structured writing.

+ +

The nature of the conversation tends to be more well-formed in each interaction. So it's like I read a big document, and then I pass it over to you. And at your leisure, you respond to it with a bunch of notes, and then it comes back to me. And I think that mode of interaction, while absolutely wonderful and something that I love, I think it fits really well when you're a little bit further on in your career when you understand things a little bit better. And I think the dance of conversation is more useful earlier on and so forth.

+ +

And so, for someone who's newer to a team, I think having the ability to ask a quick question over and over is really useful to someone who's early on in their career. And remote, again, I think it's at its best when it's async. And those two are sort of at odds. And so it's that mild tension that gives me pause of like, something that I think that makes remote work great I do think is at least a hurdle that you would have to get over in supporting someone who's a little bit newer. Because I want to be deeply present for someone who's newer to their journey so that they can ask a lot of questions so that I am available to be interrupted regularly.

+ +

I loved at thoughtbot sitting next to someone and being their mentor and being like, yeah, anytime you want, just tap on my desk. If I got my headphones on, that doesn't mean I'm ignoring you; it means I just need to make the sounds go away for a minute because that's the only way my brain will work. But feel free to just tap on my desk or whatever and grab my attention for a moment. And I'm available for that. That's an intentional choice. That's breaking up my continuity of the day, but we're choosing that for a reason.

+ +

I think that's just a little harder to do in a remote context and all the more so if we're saying, hey, we're going to try this async thing where we write structured documents, and we communicate in these larger, more well-formed, communicates back and forth. But I do believe it can be done. I think it should be done. I just think it's all the harder for all of those reasons.

+ +

STEPH: I agree that definitely makes it harder. But I'm going to push a little bit and say that when you mentioned being deeply present, I think we can be deeply present with someone and be remote. We can reduce the async requirements. So if you are someone that is more senior or more accustomed to the team, you can fall back to more of those async ways to communicate.

+ +

But if someone is new, and needs more mentorship, then let's just set up time where we're going to literally hang out for a couple of hours each day or whatever pairing environment works best for them because pairing can also be exhausting. But hey, we're going to have a check-in each day; maybe we close out each day and touchpoint. And feel free to still message me and interrupt me. Like, you're going to just heighten your availability, even though it is remote. And be aware, like, hey, this person could message me at more times, and I'm okay with that. I have opted into this form of communication.

+ +

So I think we just take that mindset of, hey, there's this person next to me, and I'm their mentor to like, hey, they're not next to me, but I'm still their mentor, and I'm still here for them. So I agree that it's harder. I think it falls on us and the team and the mentors to change ourselves versus saying to juniors, "Hey, sorry, it's remote. That's not going to work for you." It totally works for them. It's us, the mentors, that need to figure out how to make it work.

+ +

I will say being on that mentor side that then not being able to see someone so if they are next to me, I can pick up on body language and facial expressions, and I can tell when somebody's stuck. And I can see that they're frustrated, or I can see that now's a good time for me to just be like, "Hey, how's it going? What are you working on? Or do you need help with something?" And I don't have that insight when I'm away. So there are real challenges like that that I don't know how to address.

+ +

I have gone the obnoxious route [laughs] where I just message people, and I'm like, "Hey, how's it going? How's it going? How's it going?" And I try not to do that too much. But I haven't found a better way to manage that other than to constantly check in because I do have less feedback from that person that I'm working with unless they are just incredibly open about sharing when they're stuck. But typically, when you're newer to a team or newer to a career, you're going to be less willing to share when you're stuck.

+ +

But yeah, there are some real challenges, but I still think it's something for us to figure out. Because otherwise, if we cut off access for remote teams to junior folks, I mean, that's where we're headed. There are so many companies and jobs that are headed remote that not being junior friendly and being remote in my mind is just not an option. It's something that we need to figure out. And it's hard, but we need to figure it out.

+ +

CHRIS: Yeah, 100% on we need to figure that out and that that's on us as the people managing and structuring and bringing folks into teams. I think my stance would be like, let's just be clear that this is hard. It takes effort to make sure that we've provided a structure in which someone newer to a team can be successful. It takes all the more effort to do so in a remote context, I think. And it's that recognition that I think is critical.

+ +

Because if we go into this with the wrong mindset, it's like, oh yeah, it's great. We got this new person on the team. And yeah, they should be ready to go in like two weeks, right? It's like, no, no, this is a different thing. We need to be very clear about it. This is going to require that we have someone who is able to work with them and support them in this. And that means that that person's output will likely be a little bit reduced for the period of time that we're talking about. But we're playing a long game here. Let's make sure we're clear on that. This is intentional.

+ +

And let's be clear, the world of hiring and software right now it's not like super easy. There aren't way more software developers than there are jobs; at least, that's been my experience. So this is something absolutely worth investing in for just core business reasons and also good for people. So hey, it's a win-win. Let's do it. Let's figure it out. But also, let's be clear that it's going to be a little tricky along the way. So, you know, let's be intentional about that. But yeah, obviously do it, got to do it.

+ +

STEPH: Wait, so I feel like we might have circled back to unequivocally yes. [laughs] Have we gotten there, or are you still on the fence?

+ +

CHRIS: I was unequivocally yes from the beginning, but I couched it in, but...yeah, I said other things. You're right. I have now come around; let's say to unequivocally yes.

+ +

STEPH: [laughs] Cool. I don't want to feel like I'm forcing you to agree with me. [laughs] But I mean, we just so rarely disagree. So we've either got to identify this as something that we disagree on, which would be one of those rare occasions like beer and Pop-Tarts.

+ +

CHRIS: A watershed moment. Beer and Pop-Tarts.

+ +

STEPH: Yeah, those are the only two so far.

+ +

[laughter]

+ +

CHRIS: Not together also. I just want to go on record beer and Pop-Tarts; I don't think would be...anyway.

+ +

STEPH: Ooh, I don't know. It could work. It could work.

+ +

CHRIS: Well, there's another thing we disagree on.

+ +

STEPH: I would not turn it down. If I was eating a Pop-Tart, and you're like, "Hey, you want a beer?" I'd be like, "Sure," vice versa. I'm drinking a beer. "Hey, you want a Pop-Tart?" "Totally."

+ +

CHRIS: Okay. Well yeah, if I'm making bad decisions, I'm obviously going to chain them together, but that doesn't mean that they're a good decision. It's just a chain of bad decisions.

+ +

STEPH: I feel like one true thing I know about you is that when you make a decision, you're going to lean into it. So like, this is why you are all about if you're going to have a Pop-Tart, you're going to have the highest sugary junk content Pop-Tart possible. So it makes sense to me.

+ +

CHRIS: It's the Mountain Dew theorem, yeah.

+ +

STEPH: I didn't know this had a theorem. The Mountain Dew theorem?

+ +

CHRIS: No, that's just my name. Well, yeah, if I'm going to drink soda, I'm going to drink Mountain Dew, the nonsense nuclear option of soda. So yeah, I guess you're describing me, although as you say it back to me, I suddenly feel very, like, oh God, is this who I am as a person? [laughs] And I'm not going to say you're wrong. I'm just going to spend a little while thinking about some stuff.

+ +

STEPH: I mean, you embrace it. I think that's lovely. You know what you want. It's like, all right, let's do this. Let's go all in.

+ +

CHRIS: Thank you for finding a wonderfully positive way to frame it here at the end. But I think on that note, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+No3RmsYl + + ]]> + + Chris Toomey + Steph Viccari + + + 337: Oh, Henry + https://bikeshed.thoughtbot.com/337 + c594b1a6-41fb-4a14-82a6-22599dd5b75f + Tue, 10 May 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + We've got a tricycle anniversary! 🥳 Will it be ruined by a cockroach? + +Steph shares an update regarding some of the progress and discoveries that she's helped make with a client in regards to speeding up CI. + +Chris is finally getting a little bit more back into the code at work and finds himself riding another time management struggle bus. P.S.: Who even names these apps?!?! + 43:46 + no + + + We've got a tricycle anniversary! 🥳 Will it be ruined by a cockroach? +Steph shares an update regarding some of the progress and discoveries that she's helped make with a client in regards to speeding up CI. +Chris is finally getting a little bit more back into the code at work and finds himself riding another time management struggle bus. P.S.: Who even names these apps?!?! +Children of Time (https://www.goodreads.com/book/show/25499718-children-of-time) +Maker's Schedule, Manager's Schedule (http://www.paulgraham.com/makersschedule.html) +The Backwards Brain Bicycle - Smarter Every Day 133 (https://www.youtube.com/watch?v=MFzDaBzBlL0) +Clockwise - Time Management For Teams (https://www.getclockwise.com/) +One month on Analog (https://daverupert.com/2021/02/one-month-on-analog/) +Getting Things Done (https://gettingthingsdone.com/) +Bullet Journal (https://bulletjournal.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: I have officially started recording. You are on the mic, friend. +CHRIS: This is on the mic. Oh goodness. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, normally, I would say, "What's new in your world?" But this week, this day, in fact, is a very special day. Actually, technically, it's tomorrow. But did you happen to know that you have achieved your tricycle anniversary here on The Bike Shed? +STEPH: No. [laughs] +CHRIS: Three years. Three years ago tomorrow, Episode 196:I Can Be Wrong on the Internet, wonderful title for it, was released. That was the first episode where you were formally a co-host. You'd come on a few times before that, but that was three years ago. +STEPH: That's incredible. Man, you totally got me. [laughs] You were switching it up for our intro, and our intro is very formalized. As you've said before, it is per your contract that’s how we do our intro. [laughs] +CHRIS: Yes. +STEPH: That is incredible. Three years. Wow. You know, I had thought about not the particular anniversary, but I was chatting with the Boost team earlier because I'm always encouraging people like, "Hey, write a blog post. What you just said sounds incredible. That would be wonderful as a blog post." And so I felt the need to convey like, I'm terrible at writing blog posts. I have written a grand total of two. I have a third one that's in draft state and has been that way for a long time, at least a month, I believe. +And so, I am not great about writing and publishing blog posts. But I was like, but I could podcast. And so I looked up, and I was like, I know I've done around over 100; I think around 140 episodes. And so I was like, that makes me feel better. Those who can't write podcast. [laughs] +CHRIS: I'm with you on that front, that she can just keep editing a blog post for forever. I actually do have some stats that I gathered for this as well. So like you said, you're close to 140 episodes. Let's assume an average of 40 minutes per. That gets us to around 5,000 minutes of audio or said differently; that's like 87 hours or 3.6 days. +STEPH: Whoa. +CHRIS: I know, right? +STEPH: The hours really hit home for me. [laughs] +CHRIS: Not the days? I like the days one. +STEPH: No. The hours one, I don't know, the hours one resonates with me. That is something. That's very cool. +CHRIS: 87 hours, yeah. Hopefully, in that time, I think we've said some useful things. +STEPH: I was going to say as someone who started out as your co-host, and I was really certain I had nothing to say, I have 87 hours that documents otherwise. [chuckles] +CHRIS: Indeed. And having been on the other side of the mic from you for most, if not the vast majority of those, you have wonderful things to say. It has been such an absolute pleasure getting to share the mic with you and talk about tech, and nonsense, and life, and all of the things. So yeah, thanks for coming on this adventure. +STEPH: Well, that's very sweet. Thank you so much. And I appreciate you. And it has been amazing. It's been so fun to be your co-host. So I'm really glad that you convinced me to come on this adventure with you. Speaking of adventures, I have a very silly one that I'm going to start us out with. I want to tell you about Henry. You don't know Henry, so I'm going to introduce you to who Henry is. +So we have moved into our new place in North Carolina, and I went to our bathroom to brush my teeth and get ready for bed. And when I turned on the water, out popped this giant cockroach that just came scurrying across the sink, and I panicked. And so I went flying out of the bathroom and hopped up on the bed because I'm an adult, and that's what you do when you encounter a cockroach. And I was like, okay, it's just a cockroach, calm down, which is funny. Like, cockroaches and spiders, I can't do. Snakes and mice totally cool with; I can handle them. But cockroaches and spiders are my fear. +So then I was like, well, maybe if I name him or if I named them, this cockroach, then that will help, and I will be less scared of them. So I have named this cockroach Henry. And so now, when I go into the bathroom, I will often tell Henry like, "Hey, I need you to vacate. I'm coming in." And I reached over…it was a day or two later I reached over to get some soap, and then out pops Henry. +Turns out naming them didn't help. I immediately ran out of the bathroom because [laughs] they are just so fast. Something moving that quickly just scares me. So I now have this ongoing battle with Henry. I think Henry is going to win, and I'm going to end up having to use the guest bathroom until Henry decides to vacate the home. +CHRIS: Oh, Henry. Well, Henry wins this game. But I like that you tried, though, giving it a name. I will say I've actually had an experience very similar to this, and it worked in my case. So there's a really fantastic book series that I've read called The Children of Time I believe is the first one. There's the Children of Time and then The Children of Ruin. And then there's a third one coming out. It's by a fantastic author, Adrian Tchaikovsky. The first book, The Children of Time, was recommended to me by another former thoughtboter, Greg Fisher. +It's just such a unique book. It's about spiders; just it's super-duper about spiders. Whenever I tell anyone this, they're like, "I don't like spiders." I'm like, "Trust me; I'm not a spider guy. That's not who I am." And yet reading this book, these spiders they've got personality. It's just fantastic. This author has such a unique voice and really does such a fantastic job of bringing to life a different type of intelligence, a different sort of point of view on the world and the universe, spiders specifically. And I found myself thinking about spiders differently. +In the book, there are a handful of names for spiders. They're not specific characters in the book. It's almost like the names get reused for different representative spiders, which I realize I'm doing a terrible job of describing it. Everyone should read this book. It's utterly fantastic. But I found myself I would see a spider out in the world, and I'd be like, "Oh, that's Fabian. Yeah, no, Fabian is our friend," literally, this happened. +There was a large spider that was living out on our deck, and I was like, oh, no, no, no, we have to protect Fabian. This is Fabian's spot now. Like, he's just chilling. He's killing some bugs that we don't want. Like, Fabian is our friend. And so this totally worked for me with that book. But I had to go to that level; just giving it a name would not have been enough. They needed to have a backstory, and a history, and all of that. But yeah, again, cannot recommend these books enough. +STEPH: I really appreciate that I'm not alone in this approach and that it resonated with you as well. Okay. All right. So next, I will work on a backstory for Henry, and then maybe this will help. I also just need Henry to slow down. Henry is just…he's too fast. And so when he comes charging out of these hidden places, it scares me. [laughs] So I also need Henry to just be a little slower or a lot slower or to just go find another home. That would be great too. +CHRIS: Yeah, I'll be honest; I haven't read a book about sentient cockroaches. I feel like, I don't know, maybe I could come around. But I was surprised by what happened with spiders, so... +STEPH: Just the idea of that book, ugh. Okay, I'm going to move on. I'm going to move on. [laughs] +CHRIS: It's so good. You have to read it. Here's the thing, like that feeling, what if that feeling got to go away and you could think about spiders differently? Because here's the thing, spiders are friends. Spiders are on our team. +STEPH: Spiders I can handle. I'm into the idea of that book, but when you said a book about sentient cockroaches, that one just ugh. [laughs] +CHRIS: Gotcha. Okay. All right. Okay. Sure. +STEPH: So I appreciate you humoring my Henry story. But now, for my own sake, I'm going to move away from the topic of cockroaches. [laughs] That's what people came to listen to, right? So a story about roaches named Henry and spiders named Fabian. +On a more technical note, I have an update that I'm very excited to share in regards to some of the progress and discoveries that Joël and I have made with our current client in regards that we're looking to speed up CI, interested in adding some more machines to then also speed up how quickly the tests run. +And along that journey, we have also talked about tentpole. In terms of how we're splitting up and distributing that work right now, it's based per file. So for a tentpole, if you have a file that takes 10 minutes but all of your other files take 2 minutes to complete, then 10 minutes is the fastest that you're ever going to achieve because you have this one file that's holding everything else up. +So we have manually addressed a lot of those files by splitting them out. So just literally taking like this 10-minute file and splitting it into three or four files, whatever we need to bring it in line with the other files. And that had some really positive results theoretically. +So looking at the math, if we start with our current state, so we have 86 processors; this is on one machine. So on one machine, we have 86 processors with the presence of tentpoles, so we haven't manually split any files. It takes around 14 minutes for all of the RSpec tests to run. So that's around 560 minutes total of work that is then being distributed across these 86 processors. +In theory, if we addressed all of those tentpoles and we could bring all the files down where they only take six and a half minutes to complete so everything is equal in that regard, we should be able to have the RSpec test complete in around eight and a half minutes. So essentially, the math behind that is we have 560 minutes' worth of work. We divide that by 86 CPUs. We added two minutes because there's going to be a little bit of like boot-up time and just maybe some other noise that's there. So then that brings us to around eight and a half minutes. The problem is we haven't seen that. We haven't gotten that low when we actually run the RSpec test suite. +So we're seeing around more like 11 minutes. So it currently takes around 14 minutes. We've manually split files, and we're seeing more consistently that things are taking to 11 and 11 and a half minutes. And so we really paused because our next step is we want to automate how we address these tentpole files where we don't want to have to manually split files. That is just too brittle. It's very easy for someone to add to that file, and then suddenly it spikes back up, and it becomes the file that's holding up everything else. +It's also really hard to split these files. I'm not going to go there, but this is one of my other gripes with shared examples. These files can be difficult to split because you don't exactly know what's getting run, and then trying to chunk them into different files is tedious and not an easy task. So we really don't want people to have to do that either or introduce metrics. We don't really want to do that, although we would around like, "Hey, you have now introduced some tests to this file. And it now exceeds the threshold that we're looking for in terms of how we want to make sure there aren't any tentpoles in the test suite." +So to avoid a lot of those concerns, ideas, then we automate. So there are some tools that we could use. paralleltests is the tool that we're using right now, but that's per file. There's another gem that I'd mentioned before called parallelsplittest that we have taken a look at that will then chunk them at smaller levels. I'm still not exactly sure how because even though I declared that I'm looking into that gem, we've gotten distracted with some other work. But there's parallelsplit_test. There are also some other approaches. There's RSpec Queue. There's Knapsack Pro that will then split tests more at the individual example level, so then you don't have a bottleneck as to how long the file is. We don't care anymore. +So we wanted to start looking into how we could automate using those tools. But now that we're not seeing the payoff from when we've done the manual splitting, we've now backed up to say, "Okay, before we invest in this automation, we really want to see this pay off first." So that's where we're at right now. And the mantra that has been in my mind as we're going through this is verify twice, automate once. +And we've realized that we're just not there yet when it comes to automating. So to help us verify, before we go into automation mode, we are tracking the data in terms of we see how the tests are actually getting distributed across all the CPUs. We can see which tests were run for each CPU, and then we can see across which CPU how much work each process was given. +And we're seeing that some of the processes are given more work, like maybe one process is given like nine minutes of work, but another one's only given like five minutes of work. But then, if we look at the individual tests that are being distributed, there's room. It's like, okay, well, why didn't parallel_tests then distribute some of these groups of tests over to this other CPU that only was given four minutes of work? +And we see there's an opportunity because not all of those tests...it's like, well, maybe it's too big. They couldn't bring it over to the other CPU because then that would have pushed it to 10 minutes or something like that. But that's not the case because some of the test files are short enough where it's maybe like 30 seconds or maybe a minute. So it's like, it seems like a really good candidate that it could have gotten shifted to a CPU that has less work. +The thing that we have discovered is we're analyzing two different things. So we are looking at the expectation. So we are providing to parallel_tests like, hey, in a previous run, this is how you split the test, or here's the runtime for every single file, so use this data to assign work to every CPU. Based on that data, then some of the CPUs weren't given more work because we expected that CPU to take longer to complete. But then, in reality, it took less time. So we're seeing that there is a variation in terms of how long a test file takes to run. +So based on historical data, let's say we have like a controller test, and based on historical data, it took four minutes to run. But then, in actuality, maybe it took suddenly eight minutes to run, or maybe it took like two minutes to run. So we have this level of variation in how long a test actually takes to run that we can't achieve a perfect distribution because it's fluctuating so much. +And that's why we're seeing in these graphs that we're creating around why one CPU has a lot more work than another CPU is because yes, based on historical data, this should have been distributed perfectly, but the actual runtime then of those tests has changed enough. That's why it looks like our distribution algorithm isn't working. +And one of the ways we confirmed this is Joël took the parallel RSpec runtime log that is being generated from running that test (So that's the historical data that we're providing that shows how long each test takes to run.) and ran that through the paralleltests algorithm, and it was perfect. Paralleltests did a beautiful job of assigning those to all of the CPU. So we realized it had to be some fluctuation in the actual runtime that's then causing this concern. +So I'm going to share some stats; a couple of these are a little scary stats where, for example, we have a test that could run anywhere between 6.4 seconds but has taken as long as 60 seconds to run. So when you have that level of variation in terms of how long the test takes to run, you can't begin to distribute the work perfectly because it's going to differ each time. +And so now we're looking to understand what's causing that variation. Maybe it's real network requests that are going out that are then causing that fluctuation in timing. Maybe it's database contention in terms of some of those files are just creating a lot of records, and then sometimes it runs quickly, and sometimes it goes more slowly if there are a lot of other tests that are also running and hitting the database at that same time. Who knows? +We have lots of interesting options to explore, but I know I've shared a lot. Hopefully, that painted a helpful picture as to some of the discoveries that we have made around how we're distributing this work. But yeah, I'm going to pause there. +CHRIS: Oof. Yeah, that's an adventure. Partly, I think you're just making a great sales pitch for Knapsack because my understanding is this is exactly what their point of view and approach is; like, don't try and think your way out of this problem, just try and distribute the work on demand. Just in time distribution sort of thing of like, you got a bunch of workers, and each worker pulls off the queue. +There's probably some intelligence to how to sort the queue like maybe you lead with feature specs or the things that have the highest variance put them earliest in the queue such that at the end, you're getting a very deterministic distribution such that you get nice and even performance across them. +But nonetheless, Knapsack Pro seems like a very good thing. I'm intrigued by it for our usage as well. But I'm super intrigued by something that can vary by 10X, 6 seconds versus 60 seconds is just so interesting. Like, are these features-specs first of all? Because that's the only thing that could make sense. If this is a model spec and this is happening, I'm like, wow, what? A feature spec, maybe. But even then, it's still surprising. +STEPH: So I haven't dug into the specifics of that file. There are some other files that also have some scary stats. So that is next on my list to figure out how that variation is taking place. I don't think it's a feature spec just from glancing at the title of the file. But I'm also intrigued. +CHRIS: Huh. Like, the feature specs is one standout that could make sense to me because, inherently, there is waiting. There are wait characteristics in feature specs. And so they can have you stack up enough of those waits for each of the sort of like find, assert, look for, fill in, et cetera. Each of those can have a couple of seconds attached to it. But other stuff is...even a feature spec; it's surprising to take that long. Anything else is super surprising. +A couple of things stood out to me otherwise on what you said; the verify twice, automate once I love that. The general sort of the follow-up, if nothing else, of did that thing that we thought might make a change actually do it? Is it impacting in the way that we expected? Are our assumptions being validated? +There's a wonderful blog post that I read a while back that just sort of named an idea that has stuck in my head; it was called Calling Your Shot with TDD. I think I'm misrepresenting the title. But it was something in that space where TDD as an approach is a way to be like, I think I have a mental model of how the system works, and I'm now going to write a test that constrains to that behavior, and then we go from there. +And TDD as a practice represents a certain sort of specific example of this. But what you're describing of like, well, we made this change. Did it produce the outcome? Or it's so easy to do this with performance optimizations of, oh yeah, an N+1 query. Let's fix that, and then the page will be better. And it's like, is it actually, though? In some cases, in most cases, fixing an N+1 will improve performance. But will it improve performance in a useful amount? Or is it the limiting factor in terms of the performance fixes? +And so having that habit and that muscle of having the hypothesis, making the change, and then verifying that you get the expected result is so, so critical. And just sort of going through that loop is so important. It's interesting to hear that you're like, we had some ideas. And then we tried some stuff, and we're not super-duper seeing what we expected is...yeah, you're doing the work there if nothing else. +STEPH: Yeah, we have found on this project that it's really important that, as you said, to call your shot in terms of like, what's the math telling us in terms of what we think is achievable versus what are the actual results that we're seeing? And then verifying it. And I feel a lot better because before, it was just like, we don't know why this isn't paying off. We thought that splitting up these files would totally pay off, and we would drop from 14 minutes to suddenly eight and a half minutes, and it was going to be beautiful. And we didn't get there. Why is that? +And so this journey has helped me feel a lot better in regards to we have more of an understanding as to why, and it's because we validated that parallel_tests is doing a great job in terms of distributing the work across each of the processes. But because there's that variance in the test files, the algorithm can't begin to then manage that. I mean, there's if you have your data kind of lies to you in terms of what you think is going to run versus what actually may run, then we're always going to have this poorly distribution of work. +And so then the next step is, do we actually dig into understanding more of like do we want to look at those files specifically and address that concern? Or do we want to go ahead and take that leap of faith over to Knapsack Pro? Because that's what paused us from moving on to something bigger to then automate how we distribute work +Maybe since we now understand why we didn't see the payoff, we feel more comfortable taking that leap of faith that we will still see the payoff once we hand this off to a different process. And we're actually breaking it up per test or per example versus per test file. We may see less variation. Maybe that's not true. Maybe there will actually be some examples that still have a high variation, but at least it won't be grouped as an entire file, so it may get a little better. There's also the fun idea...I'm going to categorize this under the good idea, bad idea area. +CHRIS: I think I go good idea, terrible idea, just to be clear [laughs] but. +STEPH: I like it. All right. Yeah, good idea, terrible idea. So for this, one of the ideas that came up was, what if we try to finagle some of this just to still see some of the reward? Because there's part of us that we just want to see it pay off. Like, we've put a lot of effort into this. We want to see something get faster. +And it's like, well, if we know there's some variance with these files, what if we had those files, like, we added to them in terms of instead of parallel_tests ever thinking that this test could take as few as six seconds, we just say, "Nope, we know this file is always going to take more somewhere in the middle," so to then improve our distribution. And that way, there's not such a high variance of maybe the historical data will show that it took 10 seconds, but then the next run it takes more like a full minute. +And in this case, we're just like, no, you always take a full minute, or you always take 30 seconds. That might even out some of the distribution. That was one of the fun ideas that came up in terms of how could we help improve the distribution? I don't think we'll actually do that because that seems like unnecessary work and then has to be managed and justified and documented somewhere. And there are concerns that go with that. But it was still fun to brainstorm of, like, we have this thing. How do we want to do a better job of distributing between the actual work, tricking it, and then moving to another service? +CHRIS: I vote I'm team tricking it just to be clear but nah, probably not. Looping back, there is one other thing that you said in there that really stands out to me is there's a moment as you're looking through all this data, like, A, again to highlight the important work of measuring and actually validating that your hypothesis and procedure and everything's doing what you expected. +But then there was that moment of huh, that's weird, which is that is like a quote. That is an idea. That is a feeling; huh, that's weird. And whether or not you pursue it is such an interesting space to be in because a lot of the time, the work that we're doing has little bits of huh, that's weird. And do you pursue it, or do you not? Do you ignore it? And you're like, oh, that bug report is interesting. That could be a gigantic problem in our system, or it could just be a noisy network connection. I don't know. +As I think about the spectrum between folks very early in their career and senior developer as we try and think about what that means, this is one of those spaces that becomes really interesting to me. How much stuff...like, how deep is your understanding of all of the different things that you're working on such that most of the time, you have a mental model, and then the system behaves roughly in accordance with your mental model? +I think very early on in your career; I remember when I was starting out, I was like, I don't know how anything works. This is fun. I type some stuff. It works some of the time, and this is great. And slowly, over time, my knowledge and experience grew such that most of the stuff that I was doing fits within my mental model. +And then every once in a while, there's those huh, that's weird moments, and do you pursue them or do you not? Do you put them on a list to follow up on later? Just, like, that judgment point becomes a really interesting variation of what you know and don't know. And so, just the way you described that was interesting to me because it reminded me of that sort of conceptual space. +STEPH: I like that a lot because, yeah, that's constantly the space that we're in. And one of the things that I find so interesting about these kinds of Rails rescue or working with legacy code, I mean, I'm sure they apply to newer projects too. But there's a goal that you have in mind. And when do you recognize that you need to shift the goal, or you need to stick even more diligently to that goal? +And we're in that space of where we're constantly reassessing; this is our goal to speed up CI. Do we need to break for a week or two to then improve some of these tests concerns that we see? Or is this one of those times where we need to ignore that and acknowledge that it's a thing and be glad that we know about it but then really stick to our goal of speeding up CI and then moving forward with pulling in a service like RSpec Queue or Knapsack? One of those. And I agree; I think that's incredibly interesting. +And I like having those conversations of how do you decide what's the next best goal or a path to pursue? In my case, I often use timeboxing as my way to get around it where it's one of those okay; we have this idea. So like, I would like to timebox a couple of hours to look at those files to see. +Because then I can collect more data to be like, how obvious is this as to why we have this fluctuation and how long it takes this test file to run? Is it because we're making a real network call? Is it that obvious? Or is it something that's a bit more murky, and it's going to take a lot more time for us to then triage? +That is typically the tool that I will use that if I'm still not sure between two decision points, I'm like, okay, well, let me timebox and collect a few more data as if I'm pursuing this direction and then come back in a couple of hours to then reconsider which path I want to go down. I will keep you up to date as to which way we pursue, and yeah, I'll let you know how it goes. But that's most of what's going on in my world. What's new in your world? +CHRIS: What's new in my world? This week I've been getting a little bit more back into the code. We've just got a bunch of work to do. And so I've been trying to move from more of the defining the work thinking about it into actually writing some code, as it were. And it has been harder than I expected, and I've been surprised by it. And specifically, what I mean by that is I have spent a lot of my time over the past handful of weeks more in the conversation, planning, negotiating, management-y type space. So we have a lot of different integrations that we're trying to work on. +So many of the things that I'm doing are having meetings with the external companies and talking through those integrations and what does that look like? And what features do we need? And what's the contract going to look like? Yeah, interesting, fun little things, maybe not my favorite stuff in the world, but that's fine. It needs to happen. It's critical work. But at this point, I'm now ready to move back in and actually start writing some code. +It was odd to me as I was struggling more than I expected to to get back into the code. And then it kind of clicked back in, and I was like, oh no, wait, the work was too nebulous, and I couldn't find an angle of attack. Where do I start with this big, amorphous...like, build the integration for system X. I was like, I don't know how to do that. And I was kind of like, you know, like a kid rolling around the peas on their plate and not actually eating any of them sort of thing. I was just like, well, or I could... +It was weird. It was almost like in a dream where your legs don't quite work. I'm using a lot of analogies today, but that's fine. You think you can run. You're certain you knew how to run at one point in your life, but your legs just won't work. It was a little bit of that. And then I sort of snapped back in, and I remembered. I was like, oh, just break it apart into little pieces, write a checklist, sort that checklist by the things that make sense to you, start with the first one, and then work through it. And it came back. But there was this very odd moment where I didn't know how to do the work anymore. And it was like, that was scary. Yeah, it was weird. +STEPH: I find it so heartwarming that someone who is as skilled as you are and experienced as you are that you still can have those moments of like, there's this really big task in front of me, and I'm not entirely sure how to do this. And then I love that you fell back to sort of that what's my systems approach and to like, how do I solve big, murky problems? And that is to start with creating a list of some of the things that I know to do to move this forward and then organizing those. I love that story. +CHRIS: It's funny you mentioned timeboxing a minute ago, and I was like, yeah, right. That's another of the tactics that I use. And there's this whole toolset that exists, but it exists largely for me in the implementation side of the work that I do. And the other side, the conversations, and the planning and all of that, they really feel like these very distinct spaces. There's the Maker Versus Manager Schedule article by Paul Graham. +And really, it's interesting to me to experience how I'm moving across what feels like a wider gap. Like, I've bounced from the frontend to the backend a lot, or from I'll do some product management planning sort of stuff, and then I'll get back into the work. And somehow, that has all felt more cohesive and consistent. +And yet the nature of this work is sort of I'm finding that as I go back and forth between the two different sides, too, is also probably reductive. And there are probably like nine different ways in which this thing gets sliced up. But as I'm bouncing between the different facets of my work, it's been trickier. And so it was useful to just recognize that and to recognize the fact that I was able to click back in. +There's a really fantastic video on YouTube. It's by...I believe the title of the channel is Smarter Every Day. It's this guy Destin who talks about different ideas and mechanical things and whatnot. But at one point, he built a bike that was backwards. And specifically, the way that it was backwards is your handlebars; when you turn your handlebars to the right, your front wheel turns to the right, when you turn to the left, your wheel goes to the left. So it's a very direct connection. +He made a bike that was reversed such that when he turned the handlebars to the right, the front wheel would turn to the left. And obviously, he could not ride this bike. This is an impossible bike to ride for a person who has learned to ride a bike under the normal circumstances. But he battled, and he fought, and eventually, he tricked his brain into learning how to ride this new bike. +But then he couldn't ride a regular bike. And there's actually a video of it. He describes the experience of trying to ride a regular bike and how it became this other foreign thing. And yet, at one point, his brain just clicked back in, and suddenly, he knew how to ride a bike again. And the people that were watching him thought he was pretending or something; really fantastic video. +And it speaks to this sort of thing. There are modes of thinking and ways that you're operating, and it sort of felt like that. If you watch this video and you go to the end where he's in Amsterdam, and he has to try and ride a regular bike, and it clicks back in, that's what work kind of felt like for me this week. So I'm going to stop stacking analogies on top of each other, but that's sort of where I'm at right now. In a way, it's been fun. +STEPH: Well, to be fair, your analogy of pushing the peas around on the plate, I could just see it. [laughs] I think that was a really good analogy for me that really resonated. I loved that one. I haven't seen that video. That makes a lot of sense to me. I think it does. I don't know. If someone was like, "Can you ride a bike with backwards handlebars?" I probably would have been like, "Sure," and then totally failed. +I can't recall if we've talked about this before, but in everything that you're sharing, it made me think about the context switching in regards to how my schedule has changed where before, I have my one on ones, and then I also have client work. And then I was interstitialing a lot of those one on ones with client work. But now I have three days that are dedicated to client work, and I have one day that is dedicated to the Boost team, and then I have Friday for investment days. And that has been huge for me. +I didn't realize how exhausting it was for me when I was switching context so much because then there's also some prep work and a little after work that goes with each one on one. And then just knowing that I had it and I had to make sure I budgeted time for that each day in addition to the client work. But then once I shifted to like, I have a day to just focus on this particular...like, my brain can click in to like, this is the mode I'm in. I am totally focused on my team and being a good team lead and having one on ones versus I am totally focused on I can just work on code and work on some of those gnarly problems. +That has been a really big shift for me and something that I just can't unsee now to realize how stressful it was before and how I feel like I wasn't doing as good of a job. But now, I feel really good at the end of each day that I was in a particular mode, and I was more productive because I was focused on that mode. +CHRIS: Yeah, absolutely. The phrase "click in" there I love that as a mental-physical sort of representation of the thing. There's a friend of ours and former guest on the show, Matt Sumner, has recommended a piece of software to me a few times, which is called Clockwise. And Clockwise does an interesting thing that I feel calm. I've not yet pursued it because I think there's sort of a...well, anyway, the thing that it does is it rearranges schedules to try and push meetings together such that you have larger gaps of heads down deep work focused time. I love that idea. I absolutely love it. +But I think it's really interesting to like; I believe very strongly as a manager in not rescheduling one on ones with my teammates. I want to make sure that that time is protected, that to them, it's very clear that we have this time. This is the space that we've carved out to have these sorts of conversations. I'm more okay with them switching it on me. But I think it's very important for me to not change that out on them or to not reschedule at the last minute. +And so I'm sensitive to just juggling around the meetings. But I love the idea of this thing of let's just try and squash all the meetings together. I'm happy to just have like three hours straight. I'm in that mode. That's the I'm thinking about people and process and all of that kind of stuff. And then I break, I have lunch, and I come back in the afternoon, and the afternoon is entirely clear. And that's heads down working time or vice versa. +I'm actually more of I would like to have my mornings entirely clear, and that's where I do my heads down thinking work, precious brain, all that kind of stuff. And then in the afternoon, I'd prefer all my meetings. I don't necessarily want the world to entirely go around my preferences for meetings, but if it happened, it'd be fine. But Clockwise is a really interesting sort of technical solution to this problem that I've yet to pursue, but I'm intrigued by. +STEPH: I'm intrigued by this too because I did this just today where I was going through, and I was updating my schedule. And I do this on my own. I am my own AI in this case where I'm thinking through, like, okay, I want to stack meetings together so that I don't have these awkward like 15-30 minute breaks, and then I still have more of a big chunk of focus time. And so, I am manually doing that for my schedule. And I would be intrigued to see what software would recommend...they could show me a pattern that I hadn't considered that works better for me than the version that I have. +The flip side is I've also learned to just be really good with, like, I have 10 minutes. Well, let's look at my to-do list, and what can I push along for 10 minutes? That is the other thing that having a tight schedule has helped me get better at is where even if I only have 10 minutes, before, I might have been like, oh, that's not enough time to do anything. Totally a lie. Ten minutes is great. Ten minutes you can totally take a look at something and then make a comment, or read it, or just have a little more context and nudge it along. I love the nudge it along approach versus the I have to sit down and get it done approach. +On this particular theme of context switching and productivity, I have a question for you. I was debating as to whether I was going to share it or not because I feel like it's still hand-wavy enough. I'm not sure I'm going to do a great job asking this question, but I'm going to go for it. I am looking for a way to manage not just the things that I have to do each day but some higher goals. So I really like the idea of themes. So I love when a week has a theme, a month has a theme. These are the things that I'm focused on. +So then, when I do have like these 10-15 minutes or this focus time, I know there's a particular theme that I'm pursuing, maybe it's more technical related, maybe it's more mentorship, or it's something I'm interested in pursuing. But I know it's going to take a couple of iterations to work on. And I haven't found a really good way to capture those themes. +Right now, if I have something like I know I'm meeting with someone on Friday and we have a goal that we're going to collect some examples of this topic, so then what I am currently doing is for my calendar is I'm setting a daily reminder each morning to be like, hey, just so this is like simmering in the back of your mind, don't forget about it. Collect some examples about this topic. So it's one of those if I happen to see something; I want to be able to grab it and remind myself, like, hey, you're looking for this. +But it's been okay. I haven't loved it. And so I'm just in that space of where I'm trying to find a way of how do I capture the theme that I'm working on for a week or for a month but still keep that in line with my to-do items and my calendar and still ideally keep it all together? I don't want to have so many disparate places I have to go look to understand all the things that I'm focused on. Do you have any thoughts? Do you have a system for how you manage or even think about things in that space? +CHRIS: Oof. You've opened Pandora's Box here. +STEPH: [laughs] +CHRIS: I have some thoughts. What you asked, I think, is an incredibly deep question or one that there's no singular answer to this sort of thing. And the answer is specific to the person, and it's an evolving thing. Like for me, I have explored this space, personal productivity, and how to think about the bigger goals and all of that. I've explored it a lot. And it's evolved, and each phase of my life has a slightly different answer to how I think about this. +Also, to be clear, sometimes I say stuff, and it sounds like I know what I'm talking about or I've thought about this. And I'm like; I got it; I do not have it. This is a I do not have this one on lock. I'm constantly trying to solve this problem. I think the first thing that I'd go to is Getting Things Done book on personal productivity. It's the most sort of impactful or foundational in my thinking about how to look at this. And in particular, it has some ideas around the different levels at which we think about our work. There's like the day-to-day actions, and there are projects and areas. +And it's a little bit formal, frankly, in my opinion. But it does introduce the idea of the weekly review. And I think that structure that's one of the things that has been true for me throughout all of the different variations of tools, and approaches, and productivity whatnots. But the weekly review being a really useful time to sort of take a step back and think about things at a slightly higher level to make sure that you're staying connected to bigger goals and whatnot. +The other thing that comes to mind as you say this is Dave Rupert, another person who has been a guest on the show, has written a couple of times about his analog productivity system. So there's this...I think Ugmonk is the name of the cards, if I'm remembering correctly. But they're little index cards, basically, and you basically rewrite them every day. And it's this very manual, almost meditative, but very focused practice. It's vaguely similar to bullet journaling, which is another approach. +But each of them have this structured way in which you look at the work that you're doing. And I think there's a good opportunity in both of those systems, either the analog productivity thing that Dave Rupert does or bullet journaling to be like, this is where my goals go, and so these are the goals for the week, and they're written at the top of the page, and then everything else goes underneath that. +But you always have top of mind and very visible the goals that you're going towards. And so it's things like that that have been my answer to this of like, I need to find somewhere within the system that I'm working in to have the overarching goals be present and accounted for. That's tricky. And analog actually seems to be a really great way to do it, just like pen and paper is a great solution. +So even if you're using a system like Todoist, then maybe your daily structure is written on a piece of paper such that at the top of it, you write those things that are true for the week, or they're on your iPhone, desktop, or whatever, that's not a thing. They're in like a widget on your iPhone screen or on your computer desktop or something like that. But you keep them top of mind. You find some way to do that such that you're constantly anchored to the things that you say or the big rocks that you want to fill the sand around. +STEPH: I really like that book, Getting Things Done. I read it a long time ago, so that would be fun to revisit and see if I get any new bits of knowledge that are helpful for me. I like the idea of that more manual task of writing things down. I have found that to be very helpful for me because I am someone that I really like to have as little screen time as possible. +So if I can have my to-do list away from my screen, that's really nice. But then I also just recognize that there's a nicety to having it stored in an app. So then that way, it is shared across devices, and I can see it at any point. And it's stored somewhere, and I don't have to try to reread my messy handwriting. There are benefits. +But I think you highlighted the thing that I'm looking for, which is in Todoist or something similar. Right now, I have these discrete action items, and I would love if at the top...I've done this with Trello boards before where a team is working on a particular experiment or trying something new that for that iteration, we make a ticket and then we will label it something, some bright, pretty color, and then just keep it at the top of to-do and then each day we walk the board. And it's a friendly reminder of, like, hey, this is our theme for this iteration. Here's a friendly reminder. +I would love something that's like that where it's like, hey, this is your theme for this week, or this is your theme for the month; here's a friendly reminder. And I think I'm going to see if there's a way I can do that with Todoist to keep things on the same space even though I don't think it's really built to support something like that. But I'm going to check it out. +And there is a boards feature in Todoist that I haven't leveraged. So maybe if I, instead of doing the ordered list view if I do the boards view, then I could do what I just said with Trello in terms where I have a card that stays there for the week and reminds me of a goal that I'm working on or a theme that I'm working on. Cool. That was helpful, thank you. But yeah, I've been in that space of trying to figure out how to capture goals. So I appreciate you sharing those ideas with me. +CHRIS: Oh, I'm always happy to talk about this. If anything, I've been trying to be somewhat reserved so that every episode of the show isn't me talking about my continuous search for a new productivity tool. I'm still in Things. I'm not super happy about it. I keep looking at TickTick. I want Todoist to work, but it doesn't. OmniFocus calls to me. +I have a note on my phone with the list of features that I want. And I keep telling myself over and over, you're not allowed to write your own software for this. And thus far, I have successfully avoided once again writing my own productivity and list management software. [laughs] But I don't know how long I can hold out. +STEPH: As you list the names for the different apps you're using, like, what was the first one? +CHRIS: Things. +STEPH: Things. Thank you. +CHRIS: OmniFocus, TickTick. What else? There's plenty more that I've looked at, [laughs] Todoist. Yeah. +STEPH: Yeah. As you're listing all of those, that reminds me that I have decided that I think people who name apps and startups are also the same people that name baby items because I've joined a mother's group. So another thoughtboter, Elaina, runs a really wonderful group of where moms get together once a month, and we just chat about all the mama things. And they were helping supply some recommendations. They were like, "Do you know what stuff you need to buy?" And I'm like, "No. Please, please tell me. What am I going to need?" +But they're having this conversation around like, "Oh, you've got to get the Björn bouncer, and the SNOO, and the Cuzzle Wuzzle, and the Bippity Bop, and the like...all these things. I'm like, "I'm going to need y'all to use different terms because I have no idea what you're talking about." [laughs] And that is also, I think...yeah, that also goes with people who are naming things like TickTick and Things, naming those apps. +CHRIS: I'm also going to need you to spell them because many of these are not phonetic or broadly, the English languages and phonetic, the BabyBjörn, you know, that sort of thing. To do but T-E-D-E-A-U-X, I think, is one of them. It's like, come on, what are we doing here? [laughs] So yes, it's complicated out there. +STEPH: All I can think of is anytime someone's like, "Come on," all I can think of is that Peter Griffin clip where he's like, "Come on," and he's trying to get people to agree. I feel like that's some of the...that's my reaction when I read some of these [laughs] or some of those names where it's like, you're just trying to trip me up. But yeah, startups and naming baby items. +CHRIS: That's what this podcast is about. +STEPH: That's what it's all about, and cockroaches and spiders. [laughs] And I'm going to stop myself. On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + We've got a tricycle anniversary! 🥳 Will it be ruined by a cockroach?

+ +

Steph shares an update regarding some of the progress and discoveries that she's helped make with a client in regards to speeding up CI.

+ +

Chris is finally getting a little bit more back into the code at work and finds himself riding another time management struggle bus. P.S.: Who even names these apps?!?!

+ +
+ +

Children of Time
+Maker's Schedule, Manager's Schedule
+The Backwards Brain Bicycle - Smarter Every Day 133
+Clockwise - Time Management For Teams
+One month on Analog
+Getting Things Done
+Bullet Journal

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: I have officially started recording. You are on the mic, friend.

+ +

CHRIS: This is on the mic. Oh goodness.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, normally, I would say, "What's new in your world?" But this week, this day, in fact, is a very special day. Actually, technically, it's tomorrow. But did you happen to know that you have achieved your tricycle anniversary here on The Bike Shed?

+ +

STEPH: No. [laughs]

+ +

CHRIS: Three years. Three years ago tomorrow, Episode 196:I Can Be Wrong on the Internet, wonderful title for it, was released. That was the first episode where you were formally a co-host. You'd come on a few times before that, but that was three years ago.

+ +

STEPH: That's incredible. Man, you totally got me. [laughs] You were switching it up for our intro, and our intro is very formalized. As you've said before, it is per your contract that’s how we do our intro. [laughs]

+ +

CHRIS: Yes.

+ +

STEPH: That is incredible. Three years. Wow. You know, I had thought about not the particular anniversary, but I was chatting with the Boost team earlier because I'm always encouraging people like, "Hey, write a blog post. What you just said sounds incredible. That would be wonderful as a blog post." And so I felt the need to convey like, I'm terrible at writing blog posts. I have written a grand total of two. I have a third one that's in draft state and has been that way for a long time, at least a month, I believe.

+ +

And so, I am not great about writing and publishing blog posts. But I was like, but I could podcast. And so I looked up, and I was like, I know I've done around over 100; I think around 140 episodes. And so I was like, that makes me feel better. Those who can't write podcast. [laughs]

+ +

CHRIS: I'm with you on that front, that she can just keep editing a blog post for forever. I actually do have some stats that I gathered for this as well. So like you said, you're close to 140 episodes. Let's assume an average of 40 minutes per. That gets us to around 5,000 minutes of audio or said differently; that's like 87 hours or 3.6 days.

+ +

STEPH: Whoa.

+ +

CHRIS: I know, right?

+ +

STEPH: The hours really hit home for me. [laughs]

+ +

CHRIS: Not the days? I like the days one.

+ +

STEPH: No. The hours one, I don't know, the hours one resonates with me. That is something. That's very cool.

+ +

CHRIS: 87 hours, yeah. Hopefully, in that time, I think we've said some useful things.

+ +

STEPH: I was going to say as someone who started out as your co-host, and I was really certain I had nothing to say, I have 87 hours that documents otherwise. [chuckles]

+ +

CHRIS: Indeed. And having been on the other side of the mic from you for most, if not the vast majority of those, you have wonderful things to say. It has been such an absolute pleasure getting to share the mic with you and talk about tech, and nonsense, and life, and all of the things. So yeah, thanks for coming on this adventure.

+ +

STEPH: Well, that's very sweet. Thank you so much. And I appreciate you. And it has been amazing. It's been so fun to be your co-host. So I'm really glad that you convinced me to come on this adventure with you. Speaking of adventures, I have a very silly one that I'm going to start us out with. I want to tell you about Henry. You don't know Henry, so I'm going to introduce you to who Henry is.

+ +

So we have moved into our new place in North Carolina, and I went to our bathroom to brush my teeth and get ready for bed. And when I turned on the water, out popped this giant cockroach that just came scurrying across the sink, and I panicked. And so I went flying out of the bathroom and hopped up on the bed because I'm an adult, and that's what you do when you encounter a cockroach. And I was like, okay, it's just a cockroach, calm down, which is funny. Like, cockroaches and spiders, I can't do. Snakes and mice totally cool with; I can handle them. But cockroaches and spiders are my fear.

+ +

So then I was like, well, maybe if I name him or if I named them, this cockroach, then that will help, and I will be less scared of them. So I have named this cockroach Henry. And so now, when I go into the bathroom, I will often tell Henry like, "Hey, I need you to vacate. I'm coming in." And I reached over…it was a day or two later I reached over to get some soap, and then out pops Henry.

+ +

Turns out naming them didn't help. I immediately ran out of the bathroom because [laughs] they are just so fast. Something moving that quickly just scares me. So I now have this ongoing battle with Henry. I think Henry is going to win, and I'm going to end up having to use the guest bathroom until Henry decides to vacate the home.

+ +

CHRIS: Oh, Henry. Well, Henry wins this game. But I like that you tried, though, giving it a name. I will say I've actually had an experience very similar to this, and it worked in my case. So there's a really fantastic book series that I've read called The Children of Time I believe is the first one. There's the Children of Time and then The Children of Ruin. And then there's a third one coming out. It's by a fantastic author, Adrian Tchaikovsky. The first book, The Children of Time, was recommended to me by another former thoughtboter, Greg Fisher.

+ +

It's just such a unique book. It's about spiders; just it's super-duper about spiders. Whenever I tell anyone this, they're like, "I don't like spiders." I'm like, "Trust me; I'm not a spider guy. That's not who I am." And yet reading this book, these spiders they've got personality. It's just fantastic. This author has such a unique voice and really does such a fantastic job of bringing to life a different type of intelligence, a different sort of point of view on the world and the universe, spiders specifically. And I found myself thinking about spiders differently.

+ +

In the book, there are a handful of names for spiders. They're not specific characters in the book. It's almost like the names get reused for different representative spiders, which I realize I'm doing a terrible job of describing it. Everyone should read this book. It's utterly fantastic. But I found myself I would see a spider out in the world, and I'd be like, "Oh, that's Fabian. Yeah, no, Fabian is our friend," literally, this happened.

+ +

There was a large spider that was living out on our deck, and I was like, oh, no, no, no, we have to protect Fabian. This is Fabian's spot now. Like, he's just chilling. He's killing some bugs that we don't want. Like, Fabian is our friend. And so this totally worked for me with that book. But I had to go to that level; just giving it a name would not have been enough. They needed to have a backstory, and a history, and all of that. But yeah, again, cannot recommend these books enough.

+ +

STEPH: I really appreciate that I'm not alone in this approach and that it resonated with you as well. Okay. All right. So next, I will work on a backstory for Henry, and then maybe this will help. I also just need Henry to slow down. Henry is just…he's too fast. And so when he comes charging out of these hidden places, it scares me. [laughs] So I also need Henry to just be a little slower or a lot slower or to just go find another home. That would be great too.

+ +

CHRIS: Yeah, I'll be honest; I haven't read a book about sentient cockroaches. I feel like, I don't know, maybe I could come around. But I was surprised by what happened with spiders, so...

+ +

STEPH: Just the idea of that book, ugh. Okay, I'm going to move on. I'm going to move on. [laughs]

+ +

CHRIS: It's so good. You have to read it. Here's the thing, like that feeling, what if that feeling got to go away and you could think about spiders differently? Because here's the thing, spiders are friends. Spiders are on our team.

+ +

STEPH: Spiders I can handle. I'm into the idea of that book, but when you said a book about sentient cockroaches, that one just ugh. [laughs]

+ +

CHRIS: Gotcha. Okay. All right. Okay. Sure.

+ +

STEPH: So I appreciate you humoring my Henry story. But now, for my own sake, I'm going to move away from the topic of cockroaches. [laughs] That's what people came to listen to, right? So a story about roaches named Henry and spiders named Fabian.

+ +

On a more technical note, I have an update that I'm very excited to share in regards to some of the progress and discoveries that Joël and I have made with our current client in regards that we're looking to speed up CI, interested in adding some more machines to then also speed up how quickly the tests run.

+ +

And along that journey, we have also talked about tentpole. In terms of how we're splitting up and distributing that work right now, it's based per file. So for a tentpole, if you have a file that takes 10 minutes but all of your other files take 2 minutes to complete, then 10 minutes is the fastest that you're ever going to achieve because you have this one file that's holding everything else up.

+ +

So we have manually addressed a lot of those files by splitting them out. So just literally taking like this 10-minute file and splitting it into three or four files, whatever we need to bring it in line with the other files. And that had some really positive results theoretically.

+ +

So looking at the math, if we start with our current state, so we have 86 processors; this is on one machine. So on one machine, we have 86 processors with the presence of tentpoles, so we haven't manually split any files. It takes around 14 minutes for all of the RSpec tests to run. So that's around 560 minutes total of work that is then being distributed across these 86 processors.

+ +

In theory, if we addressed all of those tentpoles and we could bring all the files down where they only take six and a half minutes to complete so everything is equal in that regard, we should be able to have the RSpec test complete in around eight and a half minutes. So essentially, the math behind that is we have 560 minutes' worth of work. We divide that by 86 CPUs. We added two minutes because there's going to be a little bit of like boot-up time and just maybe some other noise that's there. So then that brings us to around eight and a half minutes. The problem is we haven't seen that. We haven't gotten that low when we actually run the RSpec test suite.

+ +

So we're seeing around more like 11 minutes. So it currently takes around 14 minutes. We've manually split files, and we're seeing more consistently that things are taking to 11 and 11 and a half minutes. And so we really paused because our next step is we want to automate how we address these tentpole files where we don't want to have to manually split files. That is just too brittle. It's very easy for someone to add to that file, and then suddenly it spikes back up, and it becomes the file that's holding up everything else.

+ +

It's also really hard to split these files. I'm not going to go there, but this is one of my other gripes with shared examples. These files can be difficult to split because you don't exactly know what's getting run, and then trying to chunk them into different files is tedious and not an easy task. So we really don't want people to have to do that either or introduce metrics. We don't really want to do that, although we would around like, "Hey, you have now introduced some tests to this file. And it now exceeds the threshold that we're looking for in terms of how we want to make sure there aren't any tentpoles in the test suite."

+ +

So to avoid a lot of those concerns, ideas, then we automate. So there are some tools that we could use. parallel_tests is the tool that we're using right now, but that's per file. There's another gem that I'd mentioned before called parallel_split_test that we have taken a look at that will then chunk them at smaller levels. I'm still not exactly sure how because even though I declared that I'm looking into that gem, we've gotten distracted with some other work. But there's parallel_split_test. There are also some other approaches. There's RSpec Queue. There's Knapsack Pro that will then split tests more at the individual example level, so then you don't have a bottleneck as to how long the file is. We don't care anymore.

+ +

So we wanted to start looking into how we could automate using those tools. But now that we're not seeing the payoff from when we've done the manual splitting, we've now backed up to say, "Okay, before we invest in this automation, we really want to see this pay off first." So that's where we're at right now. And the mantra that has been in my mind as we're going through this is verify twice, automate once.

+ +

And we've realized that we're just not there yet when it comes to automating. So to help us verify, before we go into automation mode, we are tracking the data in terms of we see how the tests are actually getting distributed across all the CPUs. We can see which tests were run for each CPU, and then we can see across which CPU how much work each process was given.

+ +

And we're seeing that some of the processes are given more work, like maybe one process is given like nine minutes of work, but another one's only given like five minutes of work. But then, if we look at the individual tests that are being distributed, there's room. It's like, okay, well, why didn't parallel_tests then distribute some of these groups of tests over to this other CPU that only was given four minutes of work?

+ +

And we see there's an opportunity because not all of those tests...it's like, well, maybe it's too big. They couldn't bring it over to the other CPU because then that would have pushed it to 10 minutes or something like that. But that's not the case because some of the test files are short enough where it's maybe like 30 seconds or maybe a minute. So it's like, it seems like a really good candidate that it could have gotten shifted to a CPU that has less work.

+ +

The thing that we have discovered is we're analyzing two different things. So we are looking at the expectation. So we are providing to parallel_tests like, hey, in a previous run, this is how you split the test, or here's the runtime for every single file, so use this data to assign work to every CPU. Based on that data, then some of the CPUs weren't given more work because we expected that CPU to take longer to complete. But then, in reality, it took less time. So we're seeing that there is a variation in terms of how long a test file takes to run.

+ +

So based on historical data, let's say we have like a controller test, and based on historical data, it took four minutes to run. But then, in actuality, maybe it took suddenly eight minutes to run, or maybe it took like two minutes to run. So we have this level of variation in how long a test actually takes to run that we can't achieve a perfect distribution because it's fluctuating so much.

+ +

And that's why we're seeing in these graphs that we're creating around why one CPU has a lot more work than another CPU is because yes, based on historical data, this should have been distributed perfectly, but the actual runtime then of those tests has changed enough. That's why it looks like our distribution algorithm isn't working.

+ +

And one of the ways we confirmed this is Joël took the parallel RSpec runtime log that is being generated from running that test (So that's the historical data that we're providing that shows how long each test takes to run.) and ran that through the parallel_tests algorithm, and it was perfect. Parallel_tests did a beautiful job of assigning those to all of the CPU. So we realized it had to be some fluctuation in the actual runtime that's then causing this concern.

+ +

So I'm going to share some stats; a couple of these are a little scary stats where, for example, we have a test that could run anywhere between 6.4 seconds but has taken as long as 60 seconds to run. So when you have that level of variation in terms of how long the test takes to run, you can't begin to distribute the work perfectly because it's going to differ each time.

+ +

And so now we're looking to understand what's causing that variation. Maybe it's real network requests that are going out that are then causing that fluctuation in timing. Maybe it's database contention in terms of some of those files are just creating a lot of records, and then sometimes it runs quickly, and sometimes it goes more slowly if there are a lot of other tests that are also running and hitting the database at that same time. Who knows?

+ +

We have lots of interesting options to explore, but I know I've shared a lot. Hopefully, that painted a helpful picture as to some of the discoveries that we have made around how we're distributing this work. But yeah, I'm going to pause there.

+ +

CHRIS: Oof. Yeah, that's an adventure. Partly, I think you're just making a great sales pitch for Knapsack because my understanding is this is exactly what their point of view and approach is; like, don't try and think your way out of this problem, just try and distribute the work on demand. Just in time distribution sort of thing of like, you got a bunch of workers, and each worker pulls off the queue.

+ +

There's probably some intelligence to how to sort the queue like maybe you lead with feature specs or the things that have the highest variance put them earliest in the queue such that at the end, you're getting a very deterministic distribution such that you get nice and even performance across them.

+ +

But nonetheless, Knapsack Pro seems like a very good thing. I'm intrigued by it for our usage as well. But I'm super intrigued by something that can vary by 10X, 6 seconds versus 60 seconds is just so interesting. Like, are these features-specs first of all? Because that's the only thing that could make sense. If this is a model spec and this is happening, I'm like, wow, what? A feature spec, maybe. But even then, it's still surprising.

+ +

STEPH: So I haven't dug into the specifics of that file. There are some other files that also have some scary stats. So that is next on my list to figure out how that variation is taking place. I don't think it's a feature spec just from glancing at the title of the file. But I'm also intrigued.

+ +

CHRIS: Huh. Like, the feature specs is one standout that could make sense to me because, inherently, there is waiting. There are wait characteristics in feature specs. And so they can have you stack up enough of those waits for each of the sort of like find, assert, look for, fill in, et cetera. Each of those can have a couple of seconds attached to it. But other stuff is...even a feature spec; it's surprising to take that long. Anything else is super surprising.

+ +

A couple of things stood out to me otherwise on what you said; the verify twice, automate once I love that. The general sort of the follow-up, if nothing else, of did that thing that we thought might make a change actually do it? Is it impacting in the way that we expected? Are our assumptions being validated?

+ +

There's a wonderful blog post that I read a while back that just sort of named an idea that has stuck in my head; it was called Calling Your Shot with TDD. I think I'm misrepresenting the title. But it was something in that space where TDD as an approach is a way to be like, I think I have a mental model of how the system works, and I'm now going to write a test that constrains to that behavior, and then we go from there.

+ +

And TDD as a practice represents a certain sort of specific example of this. But what you're describing of like, well, we made this change. Did it produce the outcome? Or it's so easy to do this with performance optimizations of, oh yeah, an N+1 query. Let's fix that, and then the page will be better. And it's like, is it actually, though? In some cases, in most cases, fixing an N+1 will improve performance. But will it improve performance in a useful amount? Or is it the limiting factor in terms of the performance fixes?

+ +

And so having that habit and that muscle of having the hypothesis, making the change, and then verifying that you get the expected result is so, so critical. And just sort of going through that loop is so important. It's interesting to hear that you're like, we had some ideas. And then we tried some stuff, and we're not super-duper seeing what we expected is...yeah, you're doing the work there if nothing else.

+ +

STEPH: Yeah, we have found on this project that it's really important that, as you said, to call your shot in terms of like, what's the math telling us in terms of what we think is achievable versus what are the actual results that we're seeing? And then verifying it. And I feel a lot better because before, it was just like, we don't know why this isn't paying off. We thought that splitting up these files would totally pay off, and we would drop from 14 minutes to suddenly eight and a half minutes, and it was going to be beautiful. And we didn't get there. Why is that?

+ +

And so this journey has helped me feel a lot better in regards to we have more of an understanding as to why, and it's because we validated that parallel_tests is doing a great job in terms of distributing the work across each of the processes. But because there's that variance in the test files, the algorithm can't begin to then manage that. I mean, there's if you have your data kind of lies to you in terms of what you think is going to run versus what actually may run, then we're always going to have this poorly distribution of work.

+ +

And so then the next step is, do we actually dig into understanding more of like do we want to look at those files specifically and address that concern? Or do we want to go ahead and take that leap of faith over to Knapsack Pro? Because that's what paused us from moving on to something bigger to then automate how we distribute work

+ +

Maybe since we now understand why we didn't see the payoff, we feel more comfortable taking that leap of faith that we will still see the payoff once we hand this off to a different process. And we're actually breaking it up per test or per example versus per test file. We may see less variation. Maybe that's not true. Maybe there will actually be some examples that still have a high variation, but at least it won't be grouped as an entire file, so it may get a little better. There's also the fun idea...I'm going to categorize this under the good idea, bad idea area.

+ +

CHRIS: I think I go good idea, terrible idea, just to be clear [laughs] but.

+ +

STEPH: I like it. All right. Yeah, good idea, terrible idea. So for this, one of the ideas that came up was, what if we try to finagle some of this just to still see some of the reward? Because there's part of us that we just want to see it pay off. Like, we've put a lot of effort into this. We want to see something get faster.

+ +

And it's like, well, if we know there's some variance with these files, what if we had those files, like, we added to them in terms of instead of parallel_tests ever thinking that this test could take as few as six seconds, we just say, "Nope, we know this file is always going to take more somewhere in the middle," so to then improve our distribution. And that way, there's not such a high variance of maybe the historical data will show that it took 10 seconds, but then the next run it takes more like a full minute.

+ +

And in this case, we're just like, no, you always take a full minute, or you always take 30 seconds. That might even out some of the distribution. That was one of the fun ideas that came up in terms of how could we help improve the distribution? I don't think we'll actually do that because that seems like unnecessary work and then has to be managed and justified and documented somewhere. And there are concerns that go with that. But it was still fun to brainstorm of, like, we have this thing. How do we want to do a better job of distributing between the actual work, tricking it, and then moving to another service?

+ +

CHRIS: I vote I'm team tricking it just to be clear but nah, probably not. Looping back, there is one other thing that you said in there that really stands out to me is there's a moment as you're looking through all this data, like, A, again to highlight the important work of measuring and actually validating that your hypothesis and procedure and everything's doing what you expected.

+ +

But then there was that moment of huh, that's weird, which is that is like a quote. That is an idea. That is a feeling; huh, that's weird. And whether or not you pursue it is such an interesting space to be in because a lot of the time, the work that we're doing has little bits of huh, that's weird. And do you pursue it, or do you not? Do you ignore it? And you're like, oh, that bug report is interesting. That could be a gigantic problem in our system, or it could just be a noisy network connection. I don't know.

+ +

As I think about the spectrum between folks very early in their career and senior developer as we try and think about what that means, this is one of those spaces that becomes really interesting to me. How much stuff...like, how deep is your understanding of all of the different things that you're working on such that most of the time, you have a mental model, and then the system behaves roughly in accordance with your mental model?

+ +

I think very early on in your career; I remember when I was starting out, I was like, I don't know how anything works. This is fun. I type some stuff. It works some of the time, and this is great. And slowly, over time, my knowledge and experience grew such that most of the stuff that I was doing fits within my mental model.

+ +

And then every once in a while, there's those huh, that's weird moments, and do you pursue them or do you not? Do you put them on a list to follow up on later? Just, like, that judgment point becomes a really interesting variation of what you know and don't know. And so, just the way you described that was interesting to me because it reminded me of that sort of conceptual space.

+ +

STEPH: I like that a lot because, yeah, that's constantly the space that we're in. And one of the things that I find so interesting about these kinds of Rails rescue or working with legacy code, I mean, I'm sure they apply to newer projects too. But there's a goal that you have in mind. And when do you recognize that you need to shift the goal, or you need to stick even more diligently to that goal?

+ +

And we're in that space of where we're constantly reassessing; this is our goal to speed up CI. Do we need to break for a week or two to then improve some of these tests concerns that we see? Or is this one of those times where we need to ignore that and acknowledge that it's a thing and be glad that we know about it but then really stick to our goal of speeding up CI and then moving forward with pulling in a service like RSpec Queue or Knapsack? One of those. And I agree; I think that's incredibly interesting.

+ +

And I like having those conversations of how do you decide what's the next best goal or a path to pursue? In my case, I often use timeboxing as my way to get around it where it's one of those okay; we have this idea. So like, I would like to timebox a couple of hours to look at those files to see.

+ +

Because then I can collect more data to be like, how obvious is this as to why we have this fluctuation and how long it takes this test file to run? Is it because we're making a real network call? Is it that obvious? Or is it something that's a bit more murky, and it's going to take a lot more time for us to then triage?

+ +

That is typically the tool that I will use that if I'm still not sure between two decision points, I'm like, okay, well, let me timebox and collect a few more data as if I'm pursuing this direction and then come back in a couple of hours to then reconsider which path I want to go down. I will keep you up to date as to which way we pursue, and yeah, I'll let you know how it goes. But that's most of what's going on in my world. What's new in your world?

+ +

CHRIS: What's new in my world? This week I've been getting a little bit more back into the code. We've just got a bunch of work to do. And so I've been trying to move from more of the defining the work thinking about it into actually writing some code, as it were. And it has been harder than I expected, and I've been surprised by it. And specifically, what I mean by that is I have spent a lot of my time over the past handful of weeks more in the conversation, planning, negotiating, management-y type space. So we have a lot of different integrations that we're trying to work on.

+ +

So many of the things that I'm doing are having meetings with the external companies and talking through those integrations and what does that look like? And what features do we need? And what's the contract going to look like? Yeah, interesting, fun little things, maybe not my favorite stuff in the world, but that's fine. It needs to happen. It's critical work. But at this point, I'm now ready to move back in and actually start writing some code.

+ +

It was odd to me as I was struggling more than I expected to to get back into the code. And then it kind of clicked back in, and I was like, oh no, wait, the work was too nebulous, and I couldn't find an angle of attack. Where do I start with this big, amorphous...like, build the integration for system X. I was like, I don't know how to do that. And I was kind of like, you know, like a kid rolling around the peas on their plate and not actually eating any of them sort of thing. I was just like, well, or I could...

+ +

It was weird. It was almost like in a dream where your legs don't quite work. I'm using a lot of analogies today, but that's fine. You think you can run. You're certain you knew how to run at one point in your life, but your legs just won't work. It was a little bit of that. And then I sort of snapped back in, and I remembered. I was like, oh, just break it apart into little pieces, write a checklist, sort that checklist by the things that make sense to you, start with the first one, and then work through it. And it came back. But there was this very odd moment where I didn't know how to do the work anymore. And it was like, that was scary. Yeah, it was weird.

+ +

STEPH: I find it so heartwarming that someone who is as skilled as you are and experienced as you are that you still can have those moments of like, there's this really big task in front of me, and I'm not entirely sure how to do this. And then I love that you fell back to sort of that what's my systems approach and to like, how do I solve big, murky problems? And that is to start with creating a list of some of the things that I know to do to move this forward and then organizing those. I love that story.

+ +

CHRIS: It's funny you mentioned timeboxing a minute ago, and I was like, yeah, right. That's another of the tactics that I use. And there's this whole toolset that exists, but it exists largely for me in the implementation side of the work that I do. And the other side, the conversations, and the planning and all of that, they really feel like these very distinct spaces. There's the Maker Versus Manager Schedule article by Paul Graham.

+ +

And really, it's interesting to me to experience how I'm moving across what feels like a wider gap. Like, I've bounced from the frontend to the backend a lot, or from I'll do some product management planning sort of stuff, and then I'll get back into the work. And somehow, that has all felt more cohesive and consistent.

+ +

And yet the nature of this work is sort of I'm finding that as I go back and forth between the two different sides, too, is also probably reductive. And there are probably like nine different ways in which this thing gets sliced up. But as I'm bouncing between the different facets of my work, it's been trickier. And so it was useful to just recognize that and to recognize the fact that I was able to click back in.

+ +

There's a really fantastic video on YouTube. It's by...I believe the title of the channel is Smarter Every Day. It's this guy Destin who talks about different ideas and mechanical things and whatnot. But at one point, he built a bike that was backwards. And specifically, the way that it was backwards is your handlebars; when you turn your handlebars to the right, your front wheel turns to the right, when you turn to the left, your wheel goes to the left. So it's a very direct connection.

+ +

He made a bike that was reversed such that when he turned the handlebars to the right, the front wheel would turn to the left. And obviously, he could not ride this bike. This is an impossible bike to ride for a person who has learned to ride a bike under the normal circumstances. But he battled, and he fought, and eventually, he tricked his brain into learning how to ride this new bike.

+ +

But then he couldn't ride a regular bike. And there's actually a video of it. He describes the experience of trying to ride a regular bike and how it became this other foreign thing. And yet, at one point, his brain just clicked back in, and suddenly, he knew how to ride a bike again. And the people that were watching him thought he was pretending or something; really fantastic video.

+ +

And it speaks to this sort of thing. There are modes of thinking and ways that you're operating, and it sort of felt like that. If you watch this video and you go to the end where he's in Amsterdam, and he has to try and ride a regular bike, and it clicks back in, that's what work kind of felt like for me this week. So I'm going to stop stacking analogies on top of each other, but that's sort of where I'm at right now. In a way, it's been fun.

+ +

STEPH: Well, to be fair, your analogy of pushing the peas around on the plate, I could just see it. [laughs] I think that was a really good analogy for me that really resonated. I loved that one. I haven't seen that video. That makes a lot of sense to me. I think it does. I don't know. If someone was like, "Can you ride a bike with backwards handlebars?" I probably would have been like, "Sure," and then totally failed.

+ +

I can't recall if we've talked about this before, but in everything that you're sharing, it made me think about the context switching in regards to how my schedule has changed where before, I have my one on ones, and then I also have client work. And then I was interstitialing a lot of those one on ones with client work. But now I have three days that are dedicated to client work, and I have one day that is dedicated to the Boost team, and then I have Friday for investment days. And that has been huge for me.

+ +

I didn't realize how exhausting it was for me when I was switching context so much because then there's also some prep work and a little after work that goes with each one on one. And then just knowing that I had it and I had to make sure I budgeted time for that each day in addition to the client work. But then once I shifted to like, I have a day to just focus on this particular...like, my brain can click in to like, this is the mode I'm in. I am totally focused on my team and being a good team lead and having one on ones versus I am totally focused on I can just work on code and work on some of those gnarly problems.

+ +

That has been a really big shift for me and something that I just can't unsee now to realize how stressful it was before and how I feel like I wasn't doing as good of a job. But now, I feel really good at the end of each day that I was in a particular mode, and I was more productive because I was focused on that mode.

+ +

CHRIS: Yeah, absolutely. The phrase "click in" there I love that as a mental-physical sort of representation of the thing. There's a friend of ours and former guest on the show, Matt Sumner, has recommended a piece of software to me a few times, which is called Clockwise. And Clockwise does an interesting thing that I feel calm. I've not yet pursued it because I think there's sort of a...well, anyway, the thing that it does is it rearranges schedules to try and push meetings together such that you have larger gaps of heads down deep work focused time. I love that idea. I absolutely love it.

+ +

But I think it's really interesting to like; I believe very strongly as a manager in not rescheduling one on ones with my teammates. I want to make sure that that time is protected, that to them, it's very clear that we have this time. This is the space that we've carved out to have these sorts of conversations. I'm more okay with them switching it on me. But I think it's very important for me to not change that out on them or to not reschedule at the last minute.

+ +

And so I'm sensitive to just juggling around the meetings. But I love the idea of this thing of let's just try and squash all the meetings together. I'm happy to just have like three hours straight. I'm in that mode. That's the I'm thinking about people and process and all of that kind of stuff. And then I break, I have lunch, and I come back in the afternoon, and the afternoon is entirely clear. And that's heads down working time or vice versa.

+ +

I'm actually more of I would like to have my mornings entirely clear, and that's where I do my heads down thinking work, precious brain, all that kind of stuff. And then in the afternoon, I'd prefer all my meetings. I don't necessarily want the world to entirely go around my preferences for meetings, but if it happened, it'd be fine. But Clockwise is a really interesting sort of technical solution to this problem that I've yet to pursue, but I'm intrigued by.

+ +

STEPH: I'm intrigued by this too because I did this just today where I was going through, and I was updating my schedule. And I do this on my own. I am my own AI in this case where I'm thinking through, like, okay, I want to stack meetings together so that I don't have these awkward like 15-30 minute breaks, and then I still have more of a big chunk of focus time. And so, I am manually doing that for my schedule. And I would be intrigued to see what software would recommend...they could show me a pattern that I hadn't considered that works better for me than the version that I have.

+ +

The flip side is I've also learned to just be really good with, like, I have 10 minutes. Well, let's look at my to-do list, and what can I push along for 10 minutes? That is the other thing that having a tight schedule has helped me get better at is where even if I only have 10 minutes, before, I might have been like, oh, that's not enough time to do anything. Totally a lie. Ten minutes is great. Ten minutes you can totally take a look at something and then make a comment, or read it, or just have a little more context and nudge it along. I love the nudge it along approach versus the I have to sit down and get it done approach.

+ +

On this particular theme of context switching and productivity, I have a question for you. I was debating as to whether I was going to share it or not because I feel like it's still hand-wavy enough. I'm not sure I'm going to do a great job asking this question, but I'm going to go for it. I am looking for a way to manage not just the things that I have to do each day but some higher goals. So I really like the idea of themes. So I love when a week has a theme, a month has a theme. These are the things that I'm focused on.

+ +

So then, when I do have like these 10-15 minutes or this focus time, I know there's a particular theme that I'm pursuing, maybe it's more technical related, maybe it's more mentorship, or it's something I'm interested in pursuing. But I know it's going to take a couple of iterations to work on. And I haven't found a really good way to capture those themes.

+ +

Right now, if I have something like I know I'm meeting with someone on Friday and we have a goal that we're going to collect some examples of this topic, so then what I am currently doing is for my calendar is I'm setting a daily reminder each morning to be like, hey, just so this is like simmering in the back of your mind, don't forget about it. Collect some examples about this topic. So it's one of those if I happen to see something; I want to be able to grab it and remind myself, like, hey, you're looking for this.

+ +

But it's been okay. I haven't loved it. And so I'm just in that space of where I'm trying to find a way of how do I capture the theme that I'm working on for a week or for a month but still keep that in line with my to-do items and my calendar and still ideally keep it all together? I don't want to have so many disparate places I have to go look to understand all the things that I'm focused on. Do you have any thoughts? Do you have a system for how you manage or even think about things in that space?

+ +

CHRIS: Oof. You've opened Pandora's Box here.

+ +

STEPH: [laughs]

+ +

CHRIS: I have some thoughts. What you asked, I think, is an incredibly deep question or one that there's no singular answer to this sort of thing. And the answer is specific to the person, and it's an evolving thing. Like for me, I have explored this space, personal productivity, and how to think about the bigger goals and all of that. I've explored it a lot. And it's evolved, and each phase of my life has a slightly different answer to how I think about this.

+ +

Also, to be clear, sometimes I say stuff, and it sounds like I know what I'm talking about or I've thought about this. And I'm like; I got it; I do not have it. This is a I do not have this one on lock. I'm constantly trying to solve this problem. I think the first thing that I'd go to is Getting Things Done book on personal productivity. It's the most sort of impactful or foundational in my thinking about how to look at this. And in particular, it has some ideas around the different levels at which we think about our work. There's like the day-to-day actions, and there are projects and areas.

+ +

And it's a little bit formal, frankly, in my opinion. But it does introduce the idea of the weekly review. And I think that structure that's one of the things that has been true for me throughout all of the different variations of tools, and approaches, and productivity whatnots. But the weekly review being a really useful time to sort of take a step back and think about things at a slightly higher level to make sure that you're staying connected to bigger goals and whatnot.

+ +

The other thing that comes to mind as you say this is Dave Rupert, another person who has been a guest on the show, has written a couple of times about his analog productivity system. So there's this...I think Ugmonk is the name of the cards, if I'm remembering correctly. But they're little index cards, basically, and you basically rewrite them every day. And it's this very manual, almost meditative, but very focused practice. It's vaguely similar to bullet journaling, which is another approach.

+ +

But each of them have this structured way in which you look at the work that you're doing. And I think there's a good opportunity in both of those systems, either the analog productivity thing that Dave Rupert does or bullet journaling to be like, this is where my goals go, and so these are the goals for the week, and they're written at the top of the page, and then everything else goes underneath that.

+ +

But you always have top of mind and very visible the goals that you're going towards. And so it's things like that that have been my answer to this of like, I need to find somewhere within the system that I'm working in to have the overarching goals be present and accounted for. That's tricky. And analog actually seems to be a really great way to do it, just like pen and paper is a great solution.

+ +

So even if you're using a system like Todoist, then maybe your daily structure is written on a piece of paper such that at the top of it, you write those things that are true for the week, or they're on your iPhone, desktop, or whatever, that's not a thing. They're in like a widget on your iPhone screen or on your computer desktop or something like that. But you keep them top of mind. You find some way to do that such that you're constantly anchored to the things that you say or the big rocks that you want to fill the sand around.

+ +

STEPH: I really like that book, Getting Things Done. I read it a long time ago, so that would be fun to revisit and see if I get any new bits of knowledge that are helpful for me. I like the idea of that more manual task of writing things down. I have found that to be very helpful for me because I am someone that I really like to have as little screen time as possible.

+ +

So if I can have my to-do list away from my screen, that's really nice. But then I also just recognize that there's a nicety to having it stored in an app. So then that way, it is shared across devices, and I can see it at any point. And it's stored somewhere, and I don't have to try to reread my messy handwriting. There are benefits.

+ +

But I think you highlighted the thing that I'm looking for, which is in Todoist or something similar. Right now, I have these discrete action items, and I would love if at the top...I've done this with Trello boards before where a team is working on a particular experiment or trying something new that for that iteration, we make a ticket and then we will label it something, some bright, pretty color, and then just keep it at the top of to-do and then each day we walk the board. And it's a friendly reminder of, like, hey, this is our theme for this iteration. Here's a friendly reminder.

+ +

I would love something that's like that where it's like, hey, this is your theme for this week, or this is your theme for the month; here's a friendly reminder. And I think I'm going to see if there's a way I can do that with Todoist to keep things on the same space even though I don't think it's really built to support something like that. But I'm going to check it out.

+ +

And there is a boards feature in Todoist that I haven't leveraged. So maybe if I, instead of doing the ordered list view if I do the boards view, then I could do what I just said with Trello in terms where I have a card that stays there for the week and reminds me of a goal that I'm working on or a theme that I'm working on. Cool. That was helpful, thank you. But yeah, I've been in that space of trying to figure out how to capture goals. So I appreciate you sharing those ideas with me.

+ +

CHRIS: Oh, I'm always happy to talk about this. If anything, I've been trying to be somewhat reserved so that every episode of the show isn't me talking about my continuous search for a new productivity tool. I'm still in Things. I'm not super happy about it. I keep looking at TickTick. I want Todoist to work, but it doesn't. OmniFocus calls to me.

+ +

I have a note on my phone with the list of features that I want. And I keep telling myself over and over, you're not allowed to write your own software for this. And thus far, I have successfully avoided once again writing my own productivity and list management software. [laughs] But I don't know how long I can hold out.

+ +

STEPH: As you list the names for the different apps you're using, like, what was the first one?

+ +

CHRIS: Things.

+ +

STEPH: Things. Thank you.

+ +

CHRIS: OmniFocus, TickTick. What else? There's plenty more that I've looked at, [laughs] Todoist. Yeah.

+ +

STEPH: Yeah. As you're listing all of those, that reminds me that I have decided that I think people who name apps and startups are also the same people that name baby items because I've joined a mother's group. So another thoughtboter, Elaina, runs a really wonderful group of where moms get together once a month, and we just chat about all the mama things. And they were helping supply some recommendations. They were like, "Do you know what stuff you need to buy?" And I'm like, "No. Please, please tell me. What am I going to need?"

+ +

But they're having this conversation around like, "Oh, you've got to get the Björn bouncer, and the SNOO, and the Cuzzle Wuzzle, and the Bippity Bop, and the like...all these things. I'm like, "I'm going to need y'all to use different terms because I have no idea what you're talking about." [laughs] And that is also, I think...yeah, that also goes with people who are naming things like TickTick and Things, naming those apps.

+ +

CHRIS: I'm also going to need you to spell them because many of these are not phonetic or broadly, the English languages and phonetic, the BabyBjörn, you know, that sort of thing. To do but T-E-D-E-A-U-X, I think, is one of them. It's like, come on, what are we doing here? [laughs] So yes, it's complicated out there.

+ +

STEPH: All I can think of is anytime someone's like, "Come on," all I can think of is that Peter Griffin clip where he's like, "Come on," and he's trying to get people to agree. I feel like that's some of the...that's my reaction when I read some of these [laughs] or some of those names where it's like, you're just trying to trip me up. But yeah, startups and naming baby items.

+ +

CHRIS: That's what this podcast is about.

+ +

STEPH: That's what it's all about, and cockroaches and spiders. [laughs] And I'm going to stop myself. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + We've got a tricycle anniversary! 🥳 Will it be ruined by a cockroach?

+ +

Steph shares an update regarding some of the progress and discoveries that she's helped make with a client in regards to speeding up CI.

+ +

Chris is finally getting a little bit more back into the code at work and finds himself riding another time management struggle bus. P.S.: Who even names these apps?!?!

+ +
+ +

Children of Time
+Maker's Schedule, Manager's Schedule
+The Backwards Brain Bicycle - Smarter Every Day 133
+Clockwise - Time Management For Teams
+One month on Analog
+Getting Things Done
+Bullet Journal

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: I have officially started recording. You are on the mic, friend.

+ +

CHRIS: This is on the mic. Oh goodness.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, normally, I would say, "What's new in your world?" But this week, this day, in fact, is a very special day. Actually, technically, it's tomorrow. But did you happen to know that you have achieved your tricycle anniversary here on The Bike Shed?

+ +

STEPH: No. [laughs]

+ +

CHRIS: Three years. Three years ago tomorrow, Episode 196:I Can Be Wrong on the Internet, wonderful title for it, was released. That was the first episode where you were formally a co-host. You'd come on a few times before that, but that was three years ago.

+ +

STEPH: That's incredible. Man, you totally got me. [laughs] You were switching it up for our intro, and our intro is very formalized. As you've said before, it is per your contract that’s how we do our intro. [laughs]

+ +

CHRIS: Yes.

+ +

STEPH: That is incredible. Three years. Wow. You know, I had thought about not the particular anniversary, but I was chatting with the Boost team earlier because I'm always encouraging people like, "Hey, write a blog post. What you just said sounds incredible. That would be wonderful as a blog post." And so I felt the need to convey like, I'm terrible at writing blog posts. I have written a grand total of two. I have a third one that's in draft state and has been that way for a long time, at least a month, I believe.

+ +

And so, I am not great about writing and publishing blog posts. But I was like, but I could podcast. And so I looked up, and I was like, I know I've done around over 100; I think around 140 episodes. And so I was like, that makes me feel better. Those who can't write podcast. [laughs]

+ +

CHRIS: I'm with you on that front, that she can just keep editing a blog post for forever. I actually do have some stats that I gathered for this as well. So like you said, you're close to 140 episodes. Let's assume an average of 40 minutes per. That gets us to around 5,000 minutes of audio or said differently; that's like 87 hours or 3.6 days.

+ +

STEPH: Whoa.

+ +

CHRIS: I know, right?

+ +

STEPH: The hours really hit home for me. [laughs]

+ +

CHRIS: Not the days? I like the days one.

+ +

STEPH: No. The hours one, I don't know, the hours one resonates with me. That is something. That's very cool.

+ +

CHRIS: 87 hours, yeah. Hopefully, in that time, I think we've said some useful things.

+ +

STEPH: I was going to say as someone who started out as your co-host, and I was really certain I had nothing to say, I have 87 hours that documents otherwise. [chuckles]

+ +

CHRIS: Indeed. And having been on the other side of the mic from you for most, if not the vast majority of those, you have wonderful things to say. It has been such an absolute pleasure getting to share the mic with you and talk about tech, and nonsense, and life, and all of the things. So yeah, thanks for coming on this adventure.

+ +

STEPH: Well, that's very sweet. Thank you so much. And I appreciate you. And it has been amazing. It's been so fun to be your co-host. So I'm really glad that you convinced me to come on this adventure with you. Speaking of adventures, I have a very silly one that I'm going to start us out with. I want to tell you about Henry. You don't know Henry, so I'm going to introduce you to who Henry is.

+ +

So we have moved into our new place in North Carolina, and I went to our bathroom to brush my teeth and get ready for bed. And when I turned on the water, out popped this giant cockroach that just came scurrying across the sink, and I panicked. And so I went flying out of the bathroom and hopped up on the bed because I'm an adult, and that's what you do when you encounter a cockroach. And I was like, okay, it's just a cockroach, calm down, which is funny. Like, cockroaches and spiders, I can't do. Snakes and mice totally cool with; I can handle them. But cockroaches and spiders are my fear.

+ +

So then I was like, well, maybe if I name him or if I named them, this cockroach, then that will help, and I will be less scared of them. So I have named this cockroach Henry. And so now, when I go into the bathroom, I will often tell Henry like, "Hey, I need you to vacate. I'm coming in." And I reached over…it was a day or two later I reached over to get some soap, and then out pops Henry.

+ +

Turns out naming them didn't help. I immediately ran out of the bathroom because [laughs] they are just so fast. Something moving that quickly just scares me. So I now have this ongoing battle with Henry. I think Henry is going to win, and I'm going to end up having to use the guest bathroom until Henry decides to vacate the home.

+ +

CHRIS: Oh, Henry. Well, Henry wins this game. But I like that you tried, though, giving it a name. I will say I've actually had an experience very similar to this, and it worked in my case. So there's a really fantastic book series that I've read called The Children of Time I believe is the first one. There's the Children of Time and then The Children of Ruin. And then there's a third one coming out. It's by a fantastic author, Adrian Tchaikovsky. The first book, The Children of Time, was recommended to me by another former thoughtboter, Greg Fisher.

+ +

It's just such a unique book. It's about spiders; just it's super-duper about spiders. Whenever I tell anyone this, they're like, "I don't like spiders." I'm like, "Trust me; I'm not a spider guy. That's not who I am." And yet reading this book, these spiders they've got personality. It's just fantastic. This author has such a unique voice and really does such a fantastic job of bringing to life a different type of intelligence, a different sort of point of view on the world and the universe, spiders specifically. And I found myself thinking about spiders differently.

+ +

In the book, there are a handful of names for spiders. They're not specific characters in the book. It's almost like the names get reused for different representative spiders, which I realize I'm doing a terrible job of describing it. Everyone should read this book. It's utterly fantastic. But I found myself I would see a spider out in the world, and I'd be like, "Oh, that's Fabian. Yeah, no, Fabian is our friend," literally, this happened.

+ +

There was a large spider that was living out on our deck, and I was like, oh, no, no, no, we have to protect Fabian. This is Fabian's spot now. Like, he's just chilling. He's killing some bugs that we don't want. Like, Fabian is our friend. And so this totally worked for me with that book. But I had to go to that level; just giving it a name would not have been enough. They needed to have a backstory, and a history, and all of that. But yeah, again, cannot recommend these books enough.

+ +

STEPH: I really appreciate that I'm not alone in this approach and that it resonated with you as well. Okay. All right. So next, I will work on a backstory for Henry, and then maybe this will help. I also just need Henry to slow down. Henry is just…he's too fast. And so when he comes charging out of these hidden places, it scares me. [laughs] So I also need Henry to just be a little slower or a lot slower or to just go find another home. That would be great too.

+ +

CHRIS: Yeah, I'll be honest; I haven't read a book about sentient cockroaches. I feel like, I don't know, maybe I could come around. But I was surprised by what happened with spiders, so...

+ +

STEPH: Just the idea of that book, ugh. Okay, I'm going to move on. I'm going to move on. [laughs]

+ +

CHRIS: It's so good. You have to read it. Here's the thing, like that feeling, what if that feeling got to go away and you could think about spiders differently? Because here's the thing, spiders are friends. Spiders are on our team.

+ +

STEPH: Spiders I can handle. I'm into the idea of that book, but when you said a book about sentient cockroaches, that one just ugh. [laughs]

+ +

CHRIS: Gotcha. Okay. All right. Okay. Sure.

+ +

STEPH: So I appreciate you humoring my Henry story. But now, for my own sake, I'm going to move away from the topic of cockroaches. [laughs] That's what people came to listen to, right? So a story about roaches named Henry and spiders named Fabian.

+ +

On a more technical note, I have an update that I'm very excited to share in regards to some of the progress and discoveries that Joël and I have made with our current client in regards that we're looking to speed up CI, interested in adding some more machines to then also speed up how quickly the tests run.

+ +

And along that journey, we have also talked about tentpole. In terms of how we're splitting up and distributing that work right now, it's based per file. So for a tentpole, if you have a file that takes 10 minutes but all of your other files take 2 minutes to complete, then 10 minutes is the fastest that you're ever going to achieve because you have this one file that's holding everything else up.

+ +

So we have manually addressed a lot of those files by splitting them out. So just literally taking like this 10-minute file and splitting it into three or four files, whatever we need to bring it in line with the other files. And that had some really positive results theoretically.

+ +

So looking at the math, if we start with our current state, so we have 86 processors; this is on one machine. So on one machine, we have 86 processors with the presence of tentpoles, so we haven't manually split any files. It takes around 14 minutes for all of the RSpec tests to run. So that's around 560 minutes total of work that is then being distributed across these 86 processors.

+ +

In theory, if we addressed all of those tentpoles and we could bring all the files down where they only take six and a half minutes to complete so everything is equal in that regard, we should be able to have the RSpec test complete in around eight and a half minutes. So essentially, the math behind that is we have 560 minutes' worth of work. We divide that by 86 CPUs. We added two minutes because there's going to be a little bit of like boot-up time and just maybe some other noise that's there. So then that brings us to around eight and a half minutes. The problem is we haven't seen that. We haven't gotten that low when we actually run the RSpec test suite.

+ +

So we're seeing around more like 11 minutes. So it currently takes around 14 minutes. We've manually split files, and we're seeing more consistently that things are taking to 11 and 11 and a half minutes. And so we really paused because our next step is we want to automate how we address these tentpole files where we don't want to have to manually split files. That is just too brittle. It's very easy for someone to add to that file, and then suddenly it spikes back up, and it becomes the file that's holding up everything else.

+ +

It's also really hard to split these files. I'm not going to go there, but this is one of my other gripes with shared examples. These files can be difficult to split because you don't exactly know what's getting run, and then trying to chunk them into different files is tedious and not an easy task. So we really don't want people to have to do that either or introduce metrics. We don't really want to do that, although we would around like, "Hey, you have now introduced some tests to this file. And it now exceeds the threshold that we're looking for in terms of how we want to make sure there aren't any tentpoles in the test suite."

+ +

So to avoid a lot of those concerns, ideas, then we automate. So there are some tools that we could use. parallel_tests is the tool that we're using right now, but that's per file. There's another gem that I'd mentioned before called parallel_split_test that we have taken a look at that will then chunk them at smaller levels. I'm still not exactly sure how because even though I declared that I'm looking into that gem, we've gotten distracted with some other work. But there's parallel_split_test. There are also some other approaches. There's RSpec Queue. There's Knapsack Pro that will then split tests more at the individual example level, so then you don't have a bottleneck as to how long the file is. We don't care anymore.

+ +

So we wanted to start looking into how we could automate using those tools. But now that we're not seeing the payoff from when we've done the manual splitting, we've now backed up to say, "Okay, before we invest in this automation, we really want to see this pay off first." So that's where we're at right now. And the mantra that has been in my mind as we're going through this is verify twice, automate once.

+ +

And we've realized that we're just not there yet when it comes to automating. So to help us verify, before we go into automation mode, we are tracking the data in terms of we see how the tests are actually getting distributed across all the CPUs. We can see which tests were run for each CPU, and then we can see across which CPU how much work each process was given.

+ +

And we're seeing that some of the processes are given more work, like maybe one process is given like nine minutes of work, but another one's only given like five minutes of work. But then, if we look at the individual tests that are being distributed, there's room. It's like, okay, well, why didn't parallel_tests then distribute some of these groups of tests over to this other CPU that only was given four minutes of work?

+ +

And we see there's an opportunity because not all of those tests...it's like, well, maybe it's too big. They couldn't bring it over to the other CPU because then that would have pushed it to 10 minutes or something like that. But that's not the case because some of the test files are short enough where it's maybe like 30 seconds or maybe a minute. So it's like, it seems like a really good candidate that it could have gotten shifted to a CPU that has less work.

+ +

The thing that we have discovered is we're analyzing two different things. So we are looking at the expectation. So we are providing to parallel_tests like, hey, in a previous run, this is how you split the test, or here's the runtime for every single file, so use this data to assign work to every CPU. Based on that data, then some of the CPUs weren't given more work because we expected that CPU to take longer to complete. But then, in reality, it took less time. So we're seeing that there is a variation in terms of how long a test file takes to run.

+ +

So based on historical data, let's say we have like a controller test, and based on historical data, it took four minutes to run. But then, in actuality, maybe it took suddenly eight minutes to run, or maybe it took like two minutes to run. So we have this level of variation in how long a test actually takes to run that we can't achieve a perfect distribution because it's fluctuating so much.

+ +

And that's why we're seeing in these graphs that we're creating around why one CPU has a lot more work than another CPU is because yes, based on historical data, this should have been distributed perfectly, but the actual runtime then of those tests has changed enough. That's why it looks like our distribution algorithm isn't working.

+ +

And one of the ways we confirmed this is Joël took the parallel RSpec runtime log that is being generated from running that test (So that's the historical data that we're providing that shows how long each test takes to run.) and ran that through the parallel_tests algorithm, and it was perfect. Parallel_tests did a beautiful job of assigning those to all of the CPU. So we realized it had to be some fluctuation in the actual runtime that's then causing this concern.

+ +

So I'm going to share some stats; a couple of these are a little scary stats where, for example, we have a test that could run anywhere between 6.4 seconds but has taken as long as 60 seconds to run. So when you have that level of variation in terms of how long the test takes to run, you can't begin to distribute the work perfectly because it's going to differ each time.

+ +

And so now we're looking to understand what's causing that variation. Maybe it's real network requests that are going out that are then causing that fluctuation in timing. Maybe it's database contention in terms of some of those files are just creating a lot of records, and then sometimes it runs quickly, and sometimes it goes more slowly if there are a lot of other tests that are also running and hitting the database at that same time. Who knows?

+ +

We have lots of interesting options to explore, but I know I've shared a lot. Hopefully, that painted a helpful picture as to some of the discoveries that we have made around how we're distributing this work. But yeah, I'm going to pause there.

+ +

CHRIS: Oof. Yeah, that's an adventure. Partly, I think you're just making a great sales pitch for Knapsack because my understanding is this is exactly what their point of view and approach is; like, don't try and think your way out of this problem, just try and distribute the work on demand. Just in time distribution sort of thing of like, you got a bunch of workers, and each worker pulls off the queue.

+ +

There's probably some intelligence to how to sort the queue like maybe you lead with feature specs or the things that have the highest variance put them earliest in the queue such that at the end, you're getting a very deterministic distribution such that you get nice and even performance across them.

+ +

But nonetheless, Knapsack Pro seems like a very good thing. I'm intrigued by it for our usage as well. But I'm super intrigued by something that can vary by 10X, 6 seconds versus 60 seconds is just so interesting. Like, are these features-specs first of all? Because that's the only thing that could make sense. If this is a model spec and this is happening, I'm like, wow, what? A feature spec, maybe. But even then, it's still surprising.

+ +

STEPH: So I haven't dug into the specifics of that file. There are some other files that also have some scary stats. So that is next on my list to figure out how that variation is taking place. I don't think it's a feature spec just from glancing at the title of the file. But I'm also intrigued.

+ +

CHRIS: Huh. Like, the feature specs is one standout that could make sense to me because, inherently, there is waiting. There are wait characteristics in feature specs. And so they can have you stack up enough of those waits for each of the sort of like find, assert, look for, fill in, et cetera. Each of those can have a couple of seconds attached to it. But other stuff is...even a feature spec; it's surprising to take that long. Anything else is super surprising.

+ +

A couple of things stood out to me otherwise on what you said; the verify twice, automate once I love that. The general sort of the follow-up, if nothing else, of did that thing that we thought might make a change actually do it? Is it impacting in the way that we expected? Are our assumptions being validated?

+ +

There's a wonderful blog post that I read a while back that just sort of named an idea that has stuck in my head; it was called Calling Your Shot with TDD. I think I'm misrepresenting the title. But it was something in that space where TDD as an approach is a way to be like, I think I have a mental model of how the system works, and I'm now going to write a test that constrains to that behavior, and then we go from there.

+ +

And TDD as a practice represents a certain sort of specific example of this. But what you're describing of like, well, we made this change. Did it produce the outcome? Or it's so easy to do this with performance optimizations of, oh yeah, an N+1 query. Let's fix that, and then the page will be better. And it's like, is it actually, though? In some cases, in most cases, fixing an N+1 will improve performance. But will it improve performance in a useful amount? Or is it the limiting factor in terms of the performance fixes?

+ +

And so having that habit and that muscle of having the hypothesis, making the change, and then verifying that you get the expected result is so, so critical. And just sort of going through that loop is so important. It's interesting to hear that you're like, we had some ideas. And then we tried some stuff, and we're not super-duper seeing what we expected is...yeah, you're doing the work there if nothing else.

+ +

STEPH: Yeah, we have found on this project that it's really important that, as you said, to call your shot in terms of like, what's the math telling us in terms of what we think is achievable versus what are the actual results that we're seeing? And then verifying it. And I feel a lot better because before, it was just like, we don't know why this isn't paying off. We thought that splitting up these files would totally pay off, and we would drop from 14 minutes to suddenly eight and a half minutes, and it was going to be beautiful. And we didn't get there. Why is that?

+ +

And so this journey has helped me feel a lot better in regards to we have more of an understanding as to why, and it's because we validated that parallel_tests is doing a great job in terms of distributing the work across each of the processes. But because there's that variance in the test files, the algorithm can't begin to then manage that. I mean, there's if you have your data kind of lies to you in terms of what you think is going to run versus what actually may run, then we're always going to have this poorly distribution of work.

+ +

And so then the next step is, do we actually dig into understanding more of like do we want to look at those files specifically and address that concern? Or do we want to go ahead and take that leap of faith over to Knapsack Pro? Because that's what paused us from moving on to something bigger to then automate how we distribute work

+ +

Maybe since we now understand why we didn't see the payoff, we feel more comfortable taking that leap of faith that we will still see the payoff once we hand this off to a different process. And we're actually breaking it up per test or per example versus per test file. We may see less variation. Maybe that's not true. Maybe there will actually be some examples that still have a high variation, but at least it won't be grouped as an entire file, so it may get a little better. There's also the fun idea...I'm going to categorize this under the good idea, bad idea area.

+ +

CHRIS: I think I go good idea, terrible idea, just to be clear [laughs] but.

+ +

STEPH: I like it. All right. Yeah, good idea, terrible idea. So for this, one of the ideas that came up was, what if we try to finagle some of this just to still see some of the reward? Because there's part of us that we just want to see it pay off. Like, we've put a lot of effort into this. We want to see something get faster.

+ +

And it's like, well, if we know there's some variance with these files, what if we had those files, like, we added to them in terms of instead of parallel_tests ever thinking that this test could take as few as six seconds, we just say, "Nope, we know this file is always going to take more somewhere in the middle," so to then improve our distribution. And that way, there's not such a high variance of maybe the historical data will show that it took 10 seconds, but then the next run it takes more like a full minute.

+ +

And in this case, we're just like, no, you always take a full minute, or you always take 30 seconds. That might even out some of the distribution. That was one of the fun ideas that came up in terms of how could we help improve the distribution? I don't think we'll actually do that because that seems like unnecessary work and then has to be managed and justified and documented somewhere. And there are concerns that go with that. But it was still fun to brainstorm of, like, we have this thing. How do we want to do a better job of distributing between the actual work, tricking it, and then moving to another service?

+ +

CHRIS: I vote I'm team tricking it just to be clear but nah, probably not. Looping back, there is one other thing that you said in there that really stands out to me is there's a moment as you're looking through all this data, like, A, again to highlight the important work of measuring and actually validating that your hypothesis and procedure and everything's doing what you expected.

+ +

But then there was that moment of huh, that's weird, which is that is like a quote. That is an idea. That is a feeling; huh, that's weird. And whether or not you pursue it is such an interesting space to be in because a lot of the time, the work that we're doing has little bits of huh, that's weird. And do you pursue it, or do you not? Do you ignore it? And you're like, oh, that bug report is interesting. That could be a gigantic problem in our system, or it could just be a noisy network connection. I don't know.

+ +

As I think about the spectrum between folks very early in their career and senior developer as we try and think about what that means, this is one of those spaces that becomes really interesting to me. How much stuff...like, how deep is your understanding of all of the different things that you're working on such that most of the time, you have a mental model, and then the system behaves roughly in accordance with your mental model?

+ +

I think very early on in your career; I remember when I was starting out, I was like, I don't know how anything works. This is fun. I type some stuff. It works some of the time, and this is great. And slowly, over time, my knowledge and experience grew such that most of the stuff that I was doing fits within my mental model.

+ +

And then every once in a while, there's those huh, that's weird moments, and do you pursue them or do you not? Do you put them on a list to follow up on later? Just, like, that judgment point becomes a really interesting variation of what you know and don't know. And so, just the way you described that was interesting to me because it reminded me of that sort of conceptual space.

+ +

STEPH: I like that a lot because, yeah, that's constantly the space that we're in. And one of the things that I find so interesting about these kinds of Rails rescue or working with legacy code, I mean, I'm sure they apply to newer projects too. But there's a goal that you have in mind. And when do you recognize that you need to shift the goal, or you need to stick even more diligently to that goal?

+ +

And we're in that space of where we're constantly reassessing; this is our goal to speed up CI. Do we need to break for a week or two to then improve some of these tests concerns that we see? Or is this one of those times where we need to ignore that and acknowledge that it's a thing and be glad that we know about it but then really stick to our goal of speeding up CI and then moving forward with pulling in a service like RSpec Queue or Knapsack? One of those. And I agree; I think that's incredibly interesting.

+ +

And I like having those conversations of how do you decide what's the next best goal or a path to pursue? In my case, I often use timeboxing as my way to get around it where it's one of those okay; we have this idea. So like, I would like to timebox a couple of hours to look at those files to see.

+ +

Because then I can collect more data to be like, how obvious is this as to why we have this fluctuation and how long it takes this test file to run? Is it because we're making a real network call? Is it that obvious? Or is it something that's a bit more murky, and it's going to take a lot more time for us to then triage?

+ +

That is typically the tool that I will use that if I'm still not sure between two decision points, I'm like, okay, well, let me timebox and collect a few more data as if I'm pursuing this direction and then come back in a couple of hours to then reconsider which path I want to go down. I will keep you up to date as to which way we pursue, and yeah, I'll let you know how it goes. But that's most of what's going on in my world. What's new in your world?

+ +

CHRIS: What's new in my world? This week I've been getting a little bit more back into the code. We've just got a bunch of work to do. And so I've been trying to move from more of the defining the work thinking about it into actually writing some code, as it were. And it has been harder than I expected, and I've been surprised by it. And specifically, what I mean by that is I have spent a lot of my time over the past handful of weeks more in the conversation, planning, negotiating, management-y type space. So we have a lot of different integrations that we're trying to work on.

+ +

So many of the things that I'm doing are having meetings with the external companies and talking through those integrations and what does that look like? And what features do we need? And what's the contract going to look like? Yeah, interesting, fun little things, maybe not my favorite stuff in the world, but that's fine. It needs to happen. It's critical work. But at this point, I'm now ready to move back in and actually start writing some code.

+ +

It was odd to me as I was struggling more than I expected to to get back into the code. And then it kind of clicked back in, and I was like, oh no, wait, the work was too nebulous, and I couldn't find an angle of attack. Where do I start with this big, amorphous...like, build the integration for system X. I was like, I don't know how to do that. And I was kind of like, you know, like a kid rolling around the peas on their plate and not actually eating any of them sort of thing. I was just like, well, or I could...

+ +

It was weird. It was almost like in a dream where your legs don't quite work. I'm using a lot of analogies today, but that's fine. You think you can run. You're certain you knew how to run at one point in your life, but your legs just won't work. It was a little bit of that. And then I sort of snapped back in, and I remembered. I was like, oh, just break it apart into little pieces, write a checklist, sort that checklist by the things that make sense to you, start with the first one, and then work through it. And it came back. But there was this very odd moment where I didn't know how to do the work anymore. And it was like, that was scary. Yeah, it was weird.

+ +

STEPH: I find it so heartwarming that someone who is as skilled as you are and experienced as you are that you still can have those moments of like, there's this really big task in front of me, and I'm not entirely sure how to do this. And then I love that you fell back to sort of that what's my systems approach and to like, how do I solve big, murky problems? And that is to start with creating a list of some of the things that I know to do to move this forward and then organizing those. I love that story.

+ +

CHRIS: It's funny you mentioned timeboxing a minute ago, and I was like, yeah, right. That's another of the tactics that I use. And there's this whole toolset that exists, but it exists largely for me in the implementation side of the work that I do. And the other side, the conversations, and the planning and all of that, they really feel like these very distinct spaces. There's the Maker Versus Manager Schedule article by Paul Graham.

+ +

And really, it's interesting to me to experience how I'm moving across what feels like a wider gap. Like, I've bounced from the frontend to the backend a lot, or from I'll do some product management planning sort of stuff, and then I'll get back into the work. And somehow, that has all felt more cohesive and consistent.

+ +

And yet the nature of this work is sort of I'm finding that as I go back and forth between the two different sides, too, is also probably reductive. And there are probably like nine different ways in which this thing gets sliced up. But as I'm bouncing between the different facets of my work, it's been trickier. And so it was useful to just recognize that and to recognize the fact that I was able to click back in.

+ +

There's a really fantastic video on YouTube. It's by...I believe the title of the channel is Smarter Every Day. It's this guy Destin who talks about different ideas and mechanical things and whatnot. But at one point, he built a bike that was backwards. And specifically, the way that it was backwards is your handlebars; when you turn your handlebars to the right, your front wheel turns to the right, when you turn to the left, your wheel goes to the left. So it's a very direct connection.

+ +

He made a bike that was reversed such that when he turned the handlebars to the right, the front wheel would turn to the left. And obviously, he could not ride this bike. This is an impossible bike to ride for a person who has learned to ride a bike under the normal circumstances. But he battled, and he fought, and eventually, he tricked his brain into learning how to ride this new bike.

+ +

But then he couldn't ride a regular bike. And there's actually a video of it. He describes the experience of trying to ride a regular bike and how it became this other foreign thing. And yet, at one point, his brain just clicked back in, and suddenly, he knew how to ride a bike again. And the people that were watching him thought he was pretending or something; really fantastic video.

+ +

And it speaks to this sort of thing. There are modes of thinking and ways that you're operating, and it sort of felt like that. If you watch this video and you go to the end where he's in Amsterdam, and he has to try and ride a regular bike, and it clicks back in, that's what work kind of felt like for me this week. So I'm going to stop stacking analogies on top of each other, but that's sort of where I'm at right now. In a way, it's been fun.

+ +

STEPH: Well, to be fair, your analogy of pushing the peas around on the plate, I could just see it. [laughs] I think that was a really good analogy for me that really resonated. I loved that one. I haven't seen that video. That makes a lot of sense to me. I think it does. I don't know. If someone was like, "Can you ride a bike with backwards handlebars?" I probably would have been like, "Sure," and then totally failed.

+ +

I can't recall if we've talked about this before, but in everything that you're sharing, it made me think about the context switching in regards to how my schedule has changed where before, I have my one on ones, and then I also have client work. And then I was interstitialing a lot of those one on ones with client work. But now I have three days that are dedicated to client work, and I have one day that is dedicated to the Boost team, and then I have Friday for investment days. And that has been huge for me.

+ +

I didn't realize how exhausting it was for me when I was switching context so much because then there's also some prep work and a little after work that goes with each one on one. And then just knowing that I had it and I had to make sure I budgeted time for that each day in addition to the client work. But then once I shifted to like, I have a day to just focus on this particular...like, my brain can click in to like, this is the mode I'm in. I am totally focused on my team and being a good team lead and having one on ones versus I am totally focused on I can just work on code and work on some of those gnarly problems.

+ +

That has been a really big shift for me and something that I just can't unsee now to realize how stressful it was before and how I feel like I wasn't doing as good of a job. But now, I feel really good at the end of each day that I was in a particular mode, and I was more productive because I was focused on that mode.

+ +

CHRIS: Yeah, absolutely. The phrase "click in" there I love that as a mental-physical sort of representation of the thing. There's a friend of ours and former guest on the show, Matt Sumner, has recommended a piece of software to me a few times, which is called Clockwise. And Clockwise does an interesting thing that I feel calm. I've not yet pursued it because I think there's sort of a...well, anyway, the thing that it does is it rearranges schedules to try and push meetings together such that you have larger gaps of heads down deep work focused time. I love that idea. I absolutely love it.

+ +

But I think it's really interesting to like; I believe very strongly as a manager in not rescheduling one on ones with my teammates. I want to make sure that that time is protected, that to them, it's very clear that we have this time. This is the space that we've carved out to have these sorts of conversations. I'm more okay with them switching it on me. But I think it's very important for me to not change that out on them or to not reschedule at the last minute.

+ +

And so I'm sensitive to just juggling around the meetings. But I love the idea of this thing of let's just try and squash all the meetings together. I'm happy to just have like three hours straight. I'm in that mode. That's the I'm thinking about people and process and all of that kind of stuff. And then I break, I have lunch, and I come back in the afternoon, and the afternoon is entirely clear. And that's heads down working time or vice versa.

+ +

I'm actually more of I would like to have my mornings entirely clear, and that's where I do my heads down thinking work, precious brain, all that kind of stuff. And then in the afternoon, I'd prefer all my meetings. I don't necessarily want the world to entirely go around my preferences for meetings, but if it happened, it'd be fine. But Clockwise is a really interesting sort of technical solution to this problem that I've yet to pursue, but I'm intrigued by.

+ +

STEPH: I'm intrigued by this too because I did this just today where I was going through, and I was updating my schedule. And I do this on my own. I am my own AI in this case where I'm thinking through, like, okay, I want to stack meetings together so that I don't have these awkward like 15-30 minute breaks, and then I still have more of a big chunk of focus time. And so, I am manually doing that for my schedule. And I would be intrigued to see what software would recommend...they could show me a pattern that I hadn't considered that works better for me than the version that I have.

+ +

The flip side is I've also learned to just be really good with, like, I have 10 minutes. Well, let's look at my to-do list, and what can I push along for 10 minutes? That is the other thing that having a tight schedule has helped me get better at is where even if I only have 10 minutes, before, I might have been like, oh, that's not enough time to do anything. Totally a lie. Ten minutes is great. Ten minutes you can totally take a look at something and then make a comment, or read it, or just have a little more context and nudge it along. I love the nudge it along approach versus the I have to sit down and get it done approach.

+ +

On this particular theme of context switching and productivity, I have a question for you. I was debating as to whether I was going to share it or not because I feel like it's still hand-wavy enough. I'm not sure I'm going to do a great job asking this question, but I'm going to go for it. I am looking for a way to manage not just the things that I have to do each day but some higher goals. So I really like the idea of themes. So I love when a week has a theme, a month has a theme. These are the things that I'm focused on.

+ +

So then, when I do have like these 10-15 minutes or this focus time, I know there's a particular theme that I'm pursuing, maybe it's more technical related, maybe it's more mentorship, or it's something I'm interested in pursuing. But I know it's going to take a couple of iterations to work on. And I haven't found a really good way to capture those themes.

+ +

Right now, if I have something like I know I'm meeting with someone on Friday and we have a goal that we're going to collect some examples of this topic, so then what I am currently doing is for my calendar is I'm setting a daily reminder each morning to be like, hey, just so this is like simmering in the back of your mind, don't forget about it. Collect some examples about this topic. So it's one of those if I happen to see something; I want to be able to grab it and remind myself, like, hey, you're looking for this.

+ +

But it's been okay. I haven't loved it. And so I'm just in that space of where I'm trying to find a way of how do I capture the theme that I'm working on for a week or for a month but still keep that in line with my to-do items and my calendar and still ideally keep it all together? I don't want to have so many disparate places I have to go look to understand all the things that I'm focused on. Do you have any thoughts? Do you have a system for how you manage or even think about things in that space?

+ +

CHRIS: Oof. You've opened Pandora's Box here.

+ +

STEPH: [laughs]

+ +

CHRIS: I have some thoughts. What you asked, I think, is an incredibly deep question or one that there's no singular answer to this sort of thing. And the answer is specific to the person, and it's an evolving thing. Like for me, I have explored this space, personal productivity, and how to think about the bigger goals and all of that. I've explored it a lot. And it's evolved, and each phase of my life has a slightly different answer to how I think about this.

+ +

Also, to be clear, sometimes I say stuff, and it sounds like I know what I'm talking about or I've thought about this. And I'm like; I got it; I do not have it. This is a I do not have this one on lock. I'm constantly trying to solve this problem. I think the first thing that I'd go to is Getting Things Done book on personal productivity. It's the most sort of impactful or foundational in my thinking about how to look at this. And in particular, it has some ideas around the different levels at which we think about our work. There's like the day-to-day actions, and there are projects and areas.

+ +

And it's a little bit formal, frankly, in my opinion. But it does introduce the idea of the weekly review. And I think that structure that's one of the things that has been true for me throughout all of the different variations of tools, and approaches, and productivity whatnots. But the weekly review being a really useful time to sort of take a step back and think about things at a slightly higher level to make sure that you're staying connected to bigger goals and whatnot.

+ +

The other thing that comes to mind as you say this is Dave Rupert, another person who has been a guest on the show, has written a couple of times about his analog productivity system. So there's this...I think Ugmonk is the name of the cards, if I'm remembering correctly. But they're little index cards, basically, and you basically rewrite them every day. And it's this very manual, almost meditative, but very focused practice. It's vaguely similar to bullet journaling, which is another approach.

+ +

But each of them have this structured way in which you look at the work that you're doing. And I think there's a good opportunity in both of those systems, either the analog productivity thing that Dave Rupert does or bullet journaling to be like, this is where my goals go, and so these are the goals for the week, and they're written at the top of the page, and then everything else goes underneath that.

+ +

But you always have top of mind and very visible the goals that you're going towards. And so it's things like that that have been my answer to this of like, I need to find somewhere within the system that I'm working in to have the overarching goals be present and accounted for. That's tricky. And analog actually seems to be a really great way to do it, just like pen and paper is a great solution.

+ +

So even if you're using a system like Todoist, then maybe your daily structure is written on a piece of paper such that at the top of it, you write those things that are true for the week, or they're on your iPhone, desktop, or whatever, that's not a thing. They're in like a widget on your iPhone screen or on your computer desktop or something like that. But you keep them top of mind. You find some way to do that such that you're constantly anchored to the things that you say or the big rocks that you want to fill the sand around.

+ +

STEPH: I really like that book, Getting Things Done. I read it a long time ago, so that would be fun to revisit and see if I get any new bits of knowledge that are helpful for me. I like the idea of that more manual task of writing things down. I have found that to be very helpful for me because I am someone that I really like to have as little screen time as possible.

+ +

So if I can have my to-do list away from my screen, that's really nice. But then I also just recognize that there's a nicety to having it stored in an app. So then that way, it is shared across devices, and I can see it at any point. And it's stored somewhere, and I don't have to try to reread my messy handwriting. There are benefits.

+ +

But I think you highlighted the thing that I'm looking for, which is in Todoist or something similar. Right now, I have these discrete action items, and I would love if at the top...I've done this with Trello boards before where a team is working on a particular experiment or trying something new that for that iteration, we make a ticket and then we will label it something, some bright, pretty color, and then just keep it at the top of to-do and then each day we walk the board. And it's a friendly reminder of, like, hey, this is our theme for this iteration. Here's a friendly reminder.

+ +

I would love something that's like that where it's like, hey, this is your theme for this week, or this is your theme for the month; here's a friendly reminder. And I think I'm going to see if there's a way I can do that with Todoist to keep things on the same space even though I don't think it's really built to support something like that. But I'm going to check it out.

+ +

And there is a boards feature in Todoist that I haven't leveraged. So maybe if I, instead of doing the ordered list view if I do the boards view, then I could do what I just said with Trello in terms where I have a card that stays there for the week and reminds me of a goal that I'm working on or a theme that I'm working on. Cool. That was helpful, thank you. But yeah, I've been in that space of trying to figure out how to capture goals. So I appreciate you sharing those ideas with me.

+ +

CHRIS: Oh, I'm always happy to talk about this. If anything, I've been trying to be somewhat reserved so that every episode of the show isn't me talking about my continuous search for a new productivity tool. I'm still in Things. I'm not super happy about it. I keep looking at TickTick. I want Todoist to work, but it doesn't. OmniFocus calls to me.

+ +

I have a note on my phone with the list of features that I want. And I keep telling myself over and over, you're not allowed to write your own software for this. And thus far, I have successfully avoided once again writing my own productivity and list management software. [laughs] But I don't know how long I can hold out.

+ +

STEPH: As you list the names for the different apps you're using, like, what was the first one?

+ +

CHRIS: Things.

+ +

STEPH: Things. Thank you.

+ +

CHRIS: OmniFocus, TickTick. What else? There's plenty more that I've looked at, [laughs] Todoist. Yeah.

+ +

STEPH: Yeah. As you're listing all of those, that reminds me that I have decided that I think people who name apps and startups are also the same people that name baby items because I've joined a mother's group. So another thoughtboter, Elaina, runs a really wonderful group of where moms get together once a month, and we just chat about all the mama things. And they were helping supply some recommendations. They were like, "Do you know what stuff you need to buy?" And I'm like, "No. Please, please tell me. What am I going to need?"

+ +

But they're having this conversation around like, "Oh, you've got to get the Björn bouncer, and the SNOO, and the Cuzzle Wuzzle, and the Bippity Bop, and the like...all these things. I'm like, "I'm going to need y'all to use different terms because I have no idea what you're talking about." [laughs] And that is also, I think...yeah, that also goes with people who are naming things like TickTick and Things, naming those apps.

+ +

CHRIS: I'm also going to need you to spell them because many of these are not phonetic or broadly, the English languages and phonetic, the BabyBjörn, you know, that sort of thing. To do but T-E-D-E-A-U-X, I think, is one of them. It's like, come on, what are we doing here? [laughs] So yes, it's complicated out there.

+ +

STEPH: All I can think of is anytime someone's like, "Come on," all I can think of is that Peter Griffin clip where he's like, "Come on," and he's trying to get people to agree. I feel like that's some of the...that's my reaction when I read some of these [laughs] or some of those names where it's like, you're just trying to trip me up. But yeah, startups and naming baby items.

+ +

CHRIS: That's what this podcast is about.

+ +

STEPH: That's what it's all about, and cockroaches and spiders. [laughs] And I'm going to stop myself. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+KTEjxqcd + + ]]> + + Chris Toomey + Steph Viccari + + + 336: Million Dollar Password + https://bikeshed.thoughtbot.com/336 + 2034d347-ac16-406a-a3de-8c8e6fc35d2e + Tue, 03 May 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris came up with a mnemonic device: Fn-Delete – for when he really wants to delete something and is also thinking about password complexity requirements, which leads to an exciting discussion around security theater. + +Steph talks about the upcoming RailsConf and the not-in-person option for virtual attendees. She also gives a shoutout to the Ruby Weekly newsletter for being awesome. + 35:07 + no + + + Chris came up with a mnemonic device: Fn-Delete – for when he really wants to delete something and is also thinking about password complexity requirements, which leads to an exciting discussion around security theater. +Steph talks about the upcoming RailsConf and the not-in-person option for virtual attendees. She also gives a shoutout to the Ruby Weekly newsletter for being awesome. +NIST Password Standards (https://specopssoft.com/blog/nist-password-standards/) +3 ActiveRecord Mistakes That Slow Down Rails Apps: Count, Where and Present (https://www.speedshop.co/2019/01/10/three-activerecord-mistakes.html) +Difference between count, length and size in an association with ActiveRecord (https://bhserna.com/count-size-length-active-record.html) +Ruby Weekly (https://rubyweekly.com/) +Railsconf 2022 (https://railsconf.org/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, happy Friday. You know, each time I do that, I can't resist the urge to say happy Friday, but then I realize people aren't listening on a Friday. So happy day to anyone that's listening. What's new in your world, friend? +CHRIS: I'm going to be honest; you threw me for a loop there. [laughs] I think it was the most recent episode where we talked about my very specific...[laughs] it's a lovely Friday, that's true. There's sun and clouds. Those are true things. But yeah, what's new in my world? [laughs] I can do this. I can focus. I got this. +Actually, I have one thing. So this is going to be, I'm going to say vaguely selfish, but I have this thing that I've been trying to commit into my brain for a long time, and I just can't get it to stick. So today, I came up with like a mnemonic device for it. And I'm going to share it on The Bike Shed because maybe it'll be useful for other people. And then hopefully, in quote, unquote, "teaching it," I will deeply learn it. +So the thing that happens in my world is occasionally, I want to delete a URL from Chrome's autocomplete. To be more specific, because it's easier for people to run away with that idea, it's The Weather Channel. I do not like weather.com. I try to type weather often, and I just want Google to show me the little, very quick pop-up thing there. I don't want any ads. I don't want to deal with that. +But somehow, often, weather.com ends up in my results. I somehow accidentally click on it. It just gets auto-populated, and then that's the first thing that happens whenever I type weather into the Omnibox in Chrome. And I get unhappy, and I deal with it for a while, then eventually I'm like, you know what? I'm deleting it. I'm getting it out of there. And then I try and remember whatever magical key combination it is that allows you to delete an entry from the drop-down list there. And I know it's a weird combination of like, Command-Shift-Alt-Delete, Backspace, something. +And every single time, it's the same. I'm like, I know it's weird, but let me try this one. How about that one? How about that one? I feel like I try every possible combination. It's like when you try and plug in a USB drive, and you're like, well, it's this way. No, it's the other way. Well, there are only two options, and I've already tried two things. How can I not have gotten it yet? But I got it now. +Okay, so on a Mac specifically, the key sequence is Shift-Function-Delete. So the way I'm going to remember this is Function is abbreviated on the keyboard as Fn. So that can be like I'm swearing, like, I'm very angry about this. And then Shift is the way to uppercase something like you're shouting. So I just really need to Fn-Delete this. So that's how I'm going to remember it. Now I've shared it with everyone else, and hopefully, some other folks can get utility out of that. But really, I hope that I remember it now that I've tried to boil it down to a memorable thing. +STEPH: [laughs] It's definitely memorable. I'm now going to remember just that I need to Fn-Delete this. And I'm not going to remember what it all is tied to. [laughs] +CHRIS: That is the power of a mnemonic device. Yeah. +STEPH: Like, I know this is useful in some way, but I can't remember what it is. But yeah, that's wonderful. I love it. That's something that I haven't had to do in a long time, and I hadn't thought about. I need to do that more. Because you're right, especially changing projects or things like that, there are just some URLs that I don't need cached anymore; I don't want auto-completed. So yeah, okay. I just need to Fn-Delete it. I'll remember it. Here we go. I'm speaking this into the universe, so it'll be true. +CHRIS: Just Fn-Delete it. +STEPH: Your bit about the USB and always getting it wrong, you get it 50-50 [laughs] by getting it wrong, resonates so deeply with me and my capability with directions where I am just terrible whether I have to go right or left. My inner compass is going to get it wrong. And I've even tried to trick myself where I'm like, okay, I know I'm always wrong. So what if I do the opposite of what Stephanie would do? And it's still somehow wrong. [laughs] +CHRIS: Somehow, your brain compensates and is like, oh, I know that we're going to do that. So let's...yeah, it's amazing the way these things happen. +STEPH: Yep. I don't understand it. I've tried to trick the software, but I haven't figured out the right way. I should probably just learn and get better at directions. But here we are. Here we are. +CHRIS: You just loosely referred to the software, but I think you're referring to the Steph software when you say that. +STEPH: Yes. Oh yeah, Steph software totally. You got it. [laughs] +CHRIS: Gotcha. Cool. Glad that I checked in on that because that's great. But shifting gears to something a little bit deeper in the technical space, this past week, we've been thinking about passwords within our organization at Sagewell. And we're trying to decide what we want to do. We had an initial card that came through and actually got most of the way to implemented to dial up our password strictness requirements. And as I saw that come through, I was like, oh, wait, actually, I would love to talk about this. +And so we had the work that was coming through the PR that had been opened was a pretty traditional set of let's introduce some requirements on our passwords for complexity, so let's make it longer. We're going from; I think six was the default that Devise shipped with, so we're increasing that to, I think it was eight. And then let's say that it needs a number, and a special character, and an uppercase letter or something like that. +I've recently read the NIST rules, so the National Institute of Standards and Technology, I think, is what they are. But they're the ones who define a set of rules around this or guidelines. But I think they are...I don't know if they are laws or what at this point. But they tell you, "This is what you should and shouldn't do." And I know that the password complexity stuff is on the don't do that list these days. So I was like, this is interesting, and then I wanted to follow through. +Interestingly, right now, I've got the Trello boards up for The Bike Shed right now. But as a result, I can't look at the linked Trello card that is on the workboards because they're in different accounts. And Trello really has made my life more difficult than I wanted. But I'm going to pull this up elsewhere. So let's see. +So NIST stuff, just to talk through that, we can include a link in the show notes to a nice summary. But what are the NIST password requirements? Eight character minimum, that's great. Change passwords only if there is evidence of a compromise. Screen new passwords against a list of known compromised passwords. That's a really interesting one. Skip password hints, limit the number of failed authentication attempts. These all sound great to me. +The maximum password length should be at least 64 characters, so don't constrain how much someone can put in. If they want to have a very long password, let them go for it. Don't have any sort of required rotation. Allow copy and pasting or functionality that allows for password managers. +And allow the use of all printable ASCII characters as well as all Unicode characters, including emojis. And that one really caught my attention. I was like, that sounds fun. I wish I could look at all the passwords in our database. I obviously can't because they're salted and encrypted, and hashed, and all those sorts of things where I'm like, I wonder if anybody's using emojis. I'm pretty sure we would just support it. But I'm kind of intrigued. +STEPH: You said something in that list that caught my attention, and I just want to see if I heard it correctly. So you said only offer change password if compromised? Does that mean I can't just change my password if I want to? +CHRIS: Sorry. Yeah, I think the phrasing here might be a little bit odd. So it's essentially a different way to phrase this requirement is don't require rotation of passwords every six or whatever months. Forgotten password that's still a reasonable thing to have in your application, probably a necessity in most applications. But don't auto-rotate passwords, so don't say, "Your password has expired after six months." +STEPH: Got it. Okay, cool. That makes sense. Then the emojis, oh no, it's like, I mean, I use a password manager now, and thanks to several years ago where he shamed me into using one. Thank you. That was great. [laughs] +CHRIS: I hope it was friendly shame, but yeah. +STEPH: Yes, it was friendly; kind shame if that sounds like a weird sentence to say. But yes, it was a very positive change. And I can't go back now that I have a password manager in my life. Because yeah, now I'm thinking like, if I had emojis, I'd be like, oh great, now I have to think about how I was feeling at the time that then I introduced a new password. Was I happy? Was I angry? Is it a poop emoji? Is unicorn? What is it? [laughs] So that feels complicated and novel. +You also mentioned on that list that going for more complexity in terms of you have to have uppercase; you have to have a particular symbol, things like that are not on the recommended list. And I didn't know that. I'm so accustomed to that being requirements for passwords and the idea of how we create something that is secure and less easy to guess or to essentially hack. So I'm curious about that one if you know any more details about it as to why that's not the standard anymore. +CHRIS: Yeah, I think I have some ideas around it. My understanding is mostly that introducing the password complexity requirements while intended to prevent people from using very common things like names or their user name or things like that, it's like, no, no, no, you can't because we've now constrained the system in that way. It tends in practice to lead to people having a variety of passwords that they forget all the time, and then they're using the forgotten password flow more often. +And it basically, for human and behavior reasons, increases the threat surface area because it means that they're not able to use...say someone has a password scheme in mind where it's like, well, my passwords are, you know, it's this common base, and then some number of things specific to the site. It's like, oh no, no, we require three special characters, so it's like they can't do their thing. And now they have to write it down on a Post-it Note because they're not going to remember it otherwise. Or there are a variety of ways in which those complexity requirements lead to behavior that's actually less useful. +STEPH: Okay, so it's the Post-it Note threat vector that we have to be worried about. [laughs] +CHRIS: Which is a very real threat factor. +STEPH: I believe it. [laughs] Yes, I know people that keep lists of passwords on paper near their desk. [laughs] This is a thing. +CHRIS: Yep, yep, yep. The other thing that's interesting is, as you think about it, password complexity requirements technically reduce the overall combinatoric space that the passwords can exist in. Because imagine that you're a password hacker, and you're like, I have no idea what this password is. All I have is an encrypted hashed salted value, and I'm trying to crack it. And so you know the algorithm, you know how many passes, you know potentially the salt because often that is available. I think it has to be available now that I think about that out loud. +But so you've got all these pieces, and you're like, I don't know, now it's time to guess. So what's a good guess of a password? And so if you know the minimum number of characters is eight and, the maximum is 12 because that actually happens on a lot of systems, that's actually not a huge combinatoric space. And then if you say, oh, and it has to have a number, and it has to have an uppercase letter, and it has to have a special character, you're just reducing the number of possible options in that space. +And so, although this is more like a mathematical thing, but in my mind, I'm like, yeah, wait, that actually makes things less secure because now there are fewer passwords to check because they don't meet the complexity requirements. So you don't even have to try them if you're trying to brute-force crack a password. +STEPH: Yeah, you make a really good point that I hadn't really thought about because I've definitely seen those sites that, yeah, constrain you in terms of like, has to have a minimum, has to have a maximum, and I hadn't really considered the fact that they are constraining it and then reducing the values that it could be. I am curious, though, because then it doesn't feel right to have no limit in terms of, like, you don't want people then just spamming your sign up and then putting something awful in there that has a ridiculous length. So do you have any thoughts on that and providing some sort of length requirement or length maximum? +CHRIS: Yeah, I think the idea is don't prevent someone who wants to put in a long passphrase, like, let them do that. But there is, the NIST guidelines specifically say 64 characters. Devise out of the box is 128, I believe. I don't think we tweaked that, and that's what we're at right now. So you can write an old-style tweet and that can be your password if that's what you want to do. But there is an upper limit to that. So there is a reasonable upper limit, but it should be very permissive to anyone who's like, I want to crank it up. +STEPH: Cool. Cool. Yeah, I just wanted to validate that; yeah, having an upper bound is still important. +CHRIS: Yeah, definitely. Important...it's more for implementation and our database having a reasonable size and those sorts of things. Although at the end of the day, the thing that we saw is the encrypted password. So I don't know if bcrypt would run slower on a giant body of text versus a couple of characters; that might be the impact. So it would be speed as opposed to storage space because you always end up with a fixed-length hash of the same length, as far as I understand it. +But yeah, it's interesting little trade-offs like that where the complexity requirements do a good job of forcing people to not use very obvious things like password. Password does not fit nearly any complexity requirements. But we're going to try and deal with that in a different way. We don't want to try and prevent you from using password by saying you must use an uppercase letter and a special character and things that make real passwords harder as well. But it is an interesting trade-off because, technically, you're making the crackability easier. So it gets into the human and the technical and the interplay between them. +Thinking about it somewhat differently as well, there's all this stuff about you should salt your passwords, then you should hash them. You should run them through a good password hashing algorithm. So we're using bcrypt right now because I believe that's the default that Devise ships with. I've heard good things about Argon2; I think is the name of the new cool kid on the block in terms of password hashing. That whole world is very interesting to me, but at the end of the day, we can just go with Devise's defaults, and I'll feel pretty good about that and have a reasonable cost factor. Those all seem like smart things. +But then, as we start to think about the complexity requirements and especially as we start to interact with an audience like Sagewell's demographics where we're working with seniors who are perhaps less tech native, less familiar, we want to reduce the complexity there in terms of them thinking of and remembering their passwords. And so, rather than having those complexity requirements, which I think can do a good job but still make stuff harder, and how do you communicate the failure modes, et cetera, et cetera, we're switching it. +And the things that we're introducing are we have increased the minimum length, so we're up to eight characters now, which is NIST's low-end recommended, so it's between 8 and 128 characters. We are capturing anytime a I forgot password reset attempt happens and the outcome of it. So we're storing those now in the database, and we're showing them to the admins. +So our admin team can see if password reset attempts have happened and if they were successful. That feels like good information to keep around. Technically, we could get it from the logs, but that's deeply hidden away and only really accessible to the developers. So we're now surfacing that information because it feels like a particularly pertinent thing for us. +We've introduced Rack::Attack. So we're throttling those attempts, and if someone tries to just brute force through that credential stuffing, as the terminology goes, we will lock them out so either based on IP address or the account that they're trying to log into. We also have Devise's lockable module enabled. So if someone tries to log in a bunch of times and fails, their account will go into a locked state, and then an admin can unlock it. But it gives us a little more control there. So a bunch of those are already in place. +The new one, this is the one that I'm most excited about, is we're going to introduce Have I Been Pwned? And so, they have an API. We can hit it. It's a really interesting model as to how do we ask if a password has been compromised without giving them the password? And it turns out there's this fun sort of cryptographic handshake thing that happens. K-anonymity is apparently the mechanism or the underpinning technology or idea. +Anyway, it's super cool; I'm excited to build it. It's going to be fun. But the idea there is rather than saying, "Don't use a password that might not be secure," it's, "Hey, we actually definitively know that your password has been cracked and is available in plaintext on the internet, so we're not going to let you use that one." +STEPH: And that's part of the signup flow as to where you would catch that? +CHRIS: So we're going to introduce on both signup and sign-in because a password can be compromised after a user signs up for our system. So we want to have it at any point. Obviously, we do not keep their plaintext password, so we can't do this retroactively. We can only do it at the point in time that they are either signing up or signing in because that's when we do have access to the password. We otherwise throw it away and keep only the hashed value. But we'll probably introduce it at both points. +And the interesting thing is communicating this failure mode is really tricky. Like, "Hey, your password is cracked, not like here, not on our site, no, we're fine. Well, you should probably change your password. So here's what it means, there's actually this database that's called Have I Been Pwned? Don't worry; it's good, though. It's P-W-N-E-D. But that's fine." That's too many words to put on a page. I can't even say it here in a podcast. +And so what we're likely to do initially is instrument it such that our admin team will get a notification and can see that a user's password has been compromised. At that point, we will reach out to them and then, using the magic of human conversation, try and actually communicate that and help them understand the ramifications, what they should do, et cetera. Longer-term, we may find a way to build up an FAQ page that describes it and then say, "Feel free to reach out if you have questions." But we want to start with the higher touch approach, so that's where we're at. +STEPH: I love it. I love that you dove into how to explain this to people as well because I was just thinking, like, this is complicated, and you're going to freak people out in panic. But you want them to take action but not panic. Well, I don't know, maybe they should panic a little bit. [laughs] +CHRIS: They should panic just the right amount. +STEPH: Right.[laughs] So I like the starting with the more manual process of reaching out to people because then you can find out more, like, how did people react to this? What kind of questions did they ask? And then collect that data and then turn that into an FAQ page. Just, well done. +CHRIS: We haven't quite done it yet. But I am very happy with the collection of ideas that we've come to here. We have a security firm that we're working with as well. And so I had my weekly meeting with them, and I was like, "Oh yeah, we also thought about passwords a bunch, and here's what we came up with." And I was very happy that they were like, "Yeah, that sounds like a good set." I was like, "Cool. All right, I feel good." I'm very happy that we're getting to do this. +And there's an interesting sort of interplay between security theater and real security. And security theater, just to explain the phrase if anyone's unfamiliar with it, is things that look like security, so, you know, big green lock up in the top-left corner of the URL bar. That actually doesn't mean anything historically or now. But it really looks like it's very secure, right? Or password complexity requirements make you think, oh, this must be a very secure site. But for reasons, that actually doesn't necessarily prove that at all. +And so we tried to find the balance of what are the things that obviously demonstrate our considerations around security to the user? At the end of the day, what are the things that actually will help protect our users? That's what I really care about. But occasionally, you got to play the security theater game. Every other financial institution on the internet kind of looks and feels a certain way in how they deal with passwords. +And so will a user look at our seemingly laxer requirements or laxer approach to passwords and judge us for that and consider us less secure despite the fact that behind the scenes look at all the fun stuff we're doing for you? But it's an interesting question and interesting trade-off that we're going to have to spend time with. We may end up with the complexity requirements despite the fact that I would really rather we didn't. But it may be the sort of thing that there is not a good way to communicate the thought and decision-making process that led us to where we're at and the other things that we're doing. +And so we're like, fine, we just got to put them in and try and do a great job and make that as usable of an experience as possible because usability is, I think, one of the things that suffers there. You didn't do one of the things on the list, or like, it's green for each of the ones that you did, but it's red for the one that you didn't. And your password and your password confirmation don't match, and you can't paste...it's very easy to make this wildly complex for users. +STEPH: Security theater is a phrase that I don't think I've used, but the way you're describing it, I really like. And I have a solution for you: underneath the password where you have "We don't partake in security theater, and we don't have all the other fancy requirements that you may have seen floating around the internet and here's why," and then just drop a link to the episode. And, you know, people can come here and listen. It'll totally be great. It won't annoy anyone at all. [laughs] +CHRIS: And it'll start, and they'll hear me yelling about Fn-Delete that weather.com URL. +[laughter] +STEPH: Okay, maybe fast forward then to the part about -- +CHRIS: Drop them to the timestamp. That makes sense. Yep. Yep. +STEPH: Mm-hmm. Mm-hmm. [laughs] +CHRIS: I like it. I think that's what we should do, yeah. Most features on the app should have a link to a Bike Shed episode. That feels true. +STEPH: Excellent Easter egg. I'm into it. But yeah, I like all the thoughtfulness that y'all have put into this because I haven't had to think about passwords in this level of detail. And then also, yeah, switching over to when things start to change and start to move away, you're right; there's still that we need to help people then become comfortable with this new way and let them know that this is just as secure if not more secure. But then there's already been that standard that has been set for your expectations, and then how do you help people along that path? So yeah, seems like y'all have a lot of really great thoughtfulness going into it. +CHRIS: Well, thank you. Yeah, it's frankly been a lot of fun. I really like thinking in this space. It's a fun sort of almost hobby that happens to align very well with my profession sort of thing. Actually, oh, I have one other idea that we're not going to do, but this is something that I've had in the back of my mind for a long time. +So when we use bcrypt or Devise uses bcrypt under the hood, one of the things that it configures is the cost factor, which I believe is just the number of times that the password plus the salts and whatnot is run through the bcrypt algorithm. The idea there is you want it to be computationally difficult, and so by doing it multiple times, you increase that difficulty. +But what I'd love is instead of thinking of it in terms of an arbitrary cost factor which I think is 12, like, I don't know what 12 means. I want to know it, in terms of dollars, how much would it cost to, like dollars and cents, to crack a password. Because, in theory, you can distribute this across any number of EC2 instances that you spin up. The idea of cracking a password that's a very map-reducible type problem. +So let's assume that you can infinitely scale up compute on-demand; how much would it cost in dollars to break this password? And I feel like there's an answer. Like, I want that number to be like a million dollars. But as EC2 costs go down over time, I want to hold that line. I want to be like, a million dollars is the line that we want to have. And so, as EC2 prices go down, we need to increase our bcrypt cost factor over time to adjust for that and maintain the million dollar per password cracking sort of high bar. That's the dream. +Swapping out the cost factor is actually really difficult. I've looked into it, and you have to like double encrypt and do weird stuff. So for a bunch of reasons, I haven't done this, but I just like that idea. Let's pin this to $1 value. And then, from there, decisions naturally flow out of it. But it's so much more of a real thing. A million dollars, I know what that means; 12, I don't know what 12 means. +STEPH: A million-dollar password, I like it. I feel like -- +CHRIS: We named the episode. +STEPH: I was going to say that's a perfect title, A Million-Dollar Password. [laughs] +CHRIS: A Million-Dollar Password. But with that wonderful episode naming cap there, I think I'm done rambling about passwords. What's up in your world, Steph? +STEPH: One of the things that I've been chatting with folks lately is RailsConf is coming up; it's May 17 through the 19th. And it's been sort of like that casual conversation of like, "Hey, are you going? Are you going? Who's going? It's going to be great." And as people have asked like, "Are you going?" And I'm always like, "No, I'm not going." But then I popped on to the RailsConf website today because I was just curious. I wanted to see the schedule and the talks that are being given. +And I keep forgetting that there's the in-person version, but there's also the home edition. And I was like, oh, I could go, I could do this. [laughs] And I just forget that that is something that is just more common now for conferences where you can attend them virtually, and that is just really neat. So I started looking a little more closely at the talks. And I'm really excited because we have a number of thoughtboters that are giving a talk at RailsConf this year. +So there's a talk being given by Fernando Perales that's called Open the Gate a Little: Strategies to Protect and Share Data. There's also a talk being given by Joël Quenneville: Your Test Suite is Making Too Many Database Calls. I'm very excited; just that one is near and dear to my heart, given the current client experiences that I'm having. And then there's another one from someone who just joined thoughtbot, Christopher "Aji" Slater, Your TDD Treasure Map. +So we'll be sure to include a link to those for anyone that's curious. But it's a stellar lineup. I mean, I'm always impressed with RailsConf talks. But this one, in particular, has me very excited. Do you have any plans for RailsConf? Do you typically wait for them to come out later and then watch them, or what's your MO? +CHRIS: Historically, I've tended to watch the conference recordings after the fact. I went one year. I actually met Christopher "Aji" Slater at that very RailsConf that I went to, and I believe Joël Quenneville was speaking at that one. So lots of everything old is new again. But yeah, I think I'll probably catch it after the fact in this case. +I'd love to go back in person at some point because I really do like the in-person thing. I'm thrilled that there is the remote option as well. But for me personally, the hallway track and hanging out and meeting folks is a very exciting part. So that's probably the mode that I would go with in the future. But I think, for now, I'm probably just going to watch some talks as they come out. +STEPH: Yeah, that's typically what I've done in the past, too, is I kind of wait for things to come out, and then I go through and make a list of the ones that I want to watch, and then, you know, I can make popcorn at home. It's delightful. I can just get cozy and have an evening of RailsConf talks. That's what normal people do on Friday nights, right? That's totally normal. [laughs] +CHRIS: I mean, yeah, maybe not the popcorn part. +STEPH: No popcorn? +CHRIS: But not that I'm opposed to popcorn just —- +STEPH: Brussels sprouts? What do you need? [laughs] +CHRIS: Yeah, Brussels sprouts, that's what it is. Just sitting there eating handfuls of Brussels sprouts watching Ruby conference talks. +STEPH: [laughs] +CHRIS: I do love Brussels sprouts, just to throw it out there. I don't want it to be out in the ether that I don't like them. I got an air fryer, and so I can air fry Brussels sprouts. And they're delicious. I mean, I like them regardless. But that is a really fantastic way to cook them at home. So I'm a big fan. +STEPH: All right, I'm moving you into the category of fancy friends, fancy friends with an air fryer. +CHRIS: I wasn't already in your category of fancy friends? +STEPH: [laughs] I didn't think you'd take it that way. I'm sorry to break it to you. +[laughter] +CHRIS: I'm actually a little hurt that I'm now in the category of fancy friends. It makes a lot of sense that I wasn't there before. So I'll just deal with...yeah, it's fine. I'm fine. +STEPH: It's a weird rubric that I'm running over here. Pivoting away quickly, so I don't have to explain the categorization for fancy friends, I saw something in the Ruby Weekly Newsletter that had just come out. And it's one of those that I see surface every so often, and I feel like it's a nice reminder because I know it's something that even I tend to forget. And so I thought it'd be fun just to resurface it here. And then, we can also provide a link to the wonderful blog post that's written by Benito Serna. +And it's the difference between count, length, and size and an association with ActiveRecord. So for folks that would love a refresher, so count, that's a method that's always going to perform a SQL count query. So even if the collection has already been loaded, then calling count is always going to execute a database query. So this is the one that's just like, watch out, avoid it. You're always going to hit your database when you use this one. +And then next is length. And so, length loads the whole collection into memory and then returns that length to the number of items in that collection. If the collection has been loaded, then it's not going to issue a database call. And then it's just still going to use...it's going to delegate to that Ruby length method and let you know how many records are in that collection. So that one is a little bit better because then that way, if it's already loaded, at least you're not going to have a database call. +And then next is the size method, which is just the one that's more highly recommended that you use because this one does have a nice safety net that is built-in because first, it's going to check if we need to perform a database call, if the records have been loaded or not. So if the collection has not been loaded, so we haven't executed a database query and stored the result, then size is going to perform a database query. Specifically, it's using that SQL count under the hood. And if the collection has been loaded, then a database call is not issued, and then going to use the Ruby length method to then return the number of records. +So it just helps you prevent unnecessary database calls. And it's the reason that that one is recommended over using count, which is going to always issue a call. And then also to avoid length where you can because it's going to load the whole collection into memory, and we want to avoid that. So it was a nice refresher. I'll be sure to include a link in the show notes. +But yeah, I find that I myself often forget about the difference in count and size. And so if I'm just in the console and I just want to know something, that I still reach for count. It is still a default for mine. But then, if I'm writing production code, then I will be more considered as to which one I'm using. +CHRIS: I feel like this is one of those that I've struggled to lock into my head, but as you're describing it right now, I think I've got, again, another mnemonic device that we can lock on to. So I know that SQL uses the keyword count, so count that's SQL definitely. Length I know that because I use that on other stuff. And so it's size that is different and therefore special. That all seems good. Cool, locking that in my brain along with Fn-Delete. I have two things that are now firmly locked in. +So you were just mentioning being in the console and working with this. And one of the things that I've noticed a lot with folks that are newer to ActiveRecord and the idea of relations and the fact that they're lazy, is that that concept is very hard to grasp when working in a console because at the console, they don't seem lazy. +The minute you type out user.where some clause, and the minute you type that and hit enter in the console, Ruby is going to do its normal thing, which is like, okay, cool, I want to...I forget what it is that IRB or any of the REPLs are going to do, but it's either inspect or to_s or something like that. But it's looking for a representation that it can display in the console. And ActiveRecord relations will typically say like, "Oh, cool, you need the records now because you want to show it like an array because that's what inspect is doing under the hood." +So at the console, it looks like ActiveRecord is eager and will evaluate the query the minute you type it, but that's not true. And this is a critical thing that if you can think about it in that way and the fact that ActiveRecord relations are lazy and then take advantage of it, you can chain queries, you can build them up, you can break that apart. You can compose them together. There's really magical stuff that falls out of that. +But it's interesting because sort of like a Heisenberg where the minute you go to look at it in the REPL, it's like, oh, it is not lazy; it is eager. It evaluates it the minute I type the query. But that's not true; that's actually the REPL tricking you. I will often just throw a semicolon at the end of it because I'm like, I don't want to see all that noise. Just give me the relation. I want the relation, not the results of executing that query. So if you tack a semicolon at the end of the line, that tells Ruby not to print the thing, and then you're good to go from there. +STEPH: That's a great pro-tip. Yeah, I've forgotten about the semicolon. And I haven't been using that in my workflow as much. So I'm so glad you mentioned that. Yeah, I'm sure that's part of the thing that's added to my confusion around this, too, or something that has just taken me a while to lock it in as to which approach I want to use for when I'm querying data or for when I need to get a particular count, or length, or size. And by using all three, I'm just confusing myself more. So I should really just stick to using size. +There's also a fabulous article by Nate Berkopec that's titled Three ActiveRecord Mistakes That Slow Down Rails Apps. And he does a fabulous job of also talking about the differences of when to use size and then some of the benefits of when you might use count. The short version is that you can use count if you truly don't care about using any of those records. Like, you're not going to do anything with them. You don't need to load them, like; you truly just want to get a count. Then sure, because then you're issuing a database query, but then you're not going to then, in a view, very soon issue another database query to collect those records again. So he has some really great examples, and I'll be sure to include a link to his article as well. +Speaking of Ruby tidbits and kind of how this particular article about count, length, and size came across my view earlier today, Ruby Weekly is a wonderful newsletter. And I feel like I don't know if I've given them a shout-out. They do a wonderful job. So if you haven't yet checked out Ruby Weekly, I highly recommend it. +There are just always really great, interesting articles either about stuff that's a little bit more like cutting edge or things that are being released with newer versions, or they might be just really helpful tips around something that someone learned, like the difference between count, length, and size, and I really enjoy it. So I'll also be sure to include a link in the show notes for anyone that wants to check that out. +They also do something that I really appreciate where when you go to their website, you have the option to subscribe, but I am terrible about subscribing to stuff. So you can still click and check out the latest issue, which I really appreciate because then, that way, I don't feel obligated to subscribe, but I can still see the content. +CHRIS: Oh yeah. Ruby Weekly is fantastic. In fact, I think Peter Cooper is the person behind it, or Cooperpress as the company goes. And there is a whole slew of newsletters that they produce. So there's JavaScript Weekly, there's Ruby Weekly, there's Node Weekly, Golang Weekly, React Status, Postgres Weekly. There's a whole bunch of them. They're all equally fantastic, the same level of curation and intentional content and all those wonderful things. So I'm a big fan. I'm subscribed to a handful of them. +And just because I can't go an episode without mentioning inbox zero, if you are the sort of person that likes to defend the pristine nature of your email inbox, I highly recommend Feedbin and their ability to set up a special email address that you can use to then turn it into an RSS feed because that's magical. Actually, these ones might already have an RSS feed under the hood. But yeah, RSS is still alive. It's still out there. I love it. It's great. And that ends my thoughts on that matter. +STEPH: I have what I feel is a developer confession. I don't think I really appreciate RSS feeds. I know they're out there in the ether, and people love them. And I just have no emotion, no opinion attached to them. So one day, I think I need to enjoy the enrichment that is RSS feeds, or maybe I'll hate it. Who knows? I'm reserving judgment. Either way, I don't think I will. [laughs] But I don't want to box future Stephanie in. +CHRIS: Gotta maintain that freedom. +STEPH: On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris came up with a mnemonic device: Fn-Delete – for when he really wants to delete something and is also thinking about password complexity requirements, which leads to an exciting discussion around security theater.

+ +

Steph talks about the upcoming RailsConf and the not-in-person option for virtual attendees. She also gives a shoutout to the Ruby Weekly newsletter for being awesome.

+ +
+ +

NIST Password Standards
+3 ActiveRecord Mistakes That Slow Down Rails Apps: Count, Where and Present
+Difference between count, length and size in an association with ActiveRecord
+Ruby Weekly
+Railsconf 2022

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, happy Friday. You know, each time I do that, I can't resist the urge to say happy Friday, but then I realize people aren't listening on a Friday. So happy day to anyone that's listening. What's new in your world, friend?

+ +

CHRIS: I'm going to be honest; you threw me for a loop there. [laughs] I think it was the most recent episode where we talked about my very specific...[laughs] it's a lovely Friday, that's true. There's sun and clouds. Those are true things. But yeah, what's new in my world? [laughs] I can do this. I can focus. I got this.

+ +

Actually, I have one thing. So this is going to be, I'm going to say vaguely selfish, but I have this thing that I've been trying to commit into my brain for a long time, and I just can't get it to stick. So today, I came up with like a mnemonic device for it. And I'm going to share it on The Bike Shed because maybe it'll be useful for other people. And then hopefully, in quote, unquote, "teaching it," I will deeply learn it.

+ +

So the thing that happens in my world is occasionally, I want to delete a URL from Chrome's autocomplete. To be more specific, because it's easier for people to run away with that idea, it's The Weather Channel. I do not like weather.com. I try to type weather often, and I just want Google to show me the little, very quick pop-up thing there. I don't want any ads. I don't want to deal with that.

+ +

But somehow, often, weather.com ends up in my results. I somehow accidentally click on it. It just gets auto-populated, and then that's the first thing that happens whenever I type weather into the Omnibox in Chrome. And I get unhappy, and I deal with it for a while, then eventually I'm like, you know what? I'm deleting it. I'm getting it out of there. And then I try and remember whatever magical key combination it is that allows you to delete an entry from the drop-down list there. And I know it's a weird combination of like, Command-Shift-Alt-Delete, Backspace, something.

+ +

And every single time, it's the same. I'm like, I know it's weird, but let me try this one. How about that one? How about that one? I feel like I try every possible combination. It's like when you try and plug in a USB drive, and you're like, well, it's this way. No, it's the other way. Well, there are only two options, and I've already tried two things. How can I not have gotten it yet? But I got it now.

+ +

Okay, so on a Mac specifically, the key sequence is Shift-Function-Delete. So the way I'm going to remember this is Function is abbreviated on the keyboard as Fn. So that can be like I'm swearing, like, I'm very angry about this. And then Shift is the way to uppercase something like you're shouting. So I just really need to Fn-Delete this. So that's how I'm going to remember it. Now I've shared it with everyone else, and hopefully, some other folks can get utility out of that. But really, I hope that I remember it now that I've tried to boil it down to a memorable thing.

+ +

STEPH: [laughs] It's definitely memorable. I'm now going to remember just that I need to Fn-Delete this. And I'm not going to remember what it all is tied to. [laughs]

+ +

CHRIS: That is the power of a mnemonic device. Yeah.

+ +

STEPH: Like, I know this is useful in some way, but I can't remember what it is. But yeah, that's wonderful. I love it. That's something that I haven't had to do in a long time, and I hadn't thought about. I need to do that more. Because you're right, especially changing projects or things like that, there are just some URLs that I don't need cached anymore; I don't want auto-completed. So yeah, okay. I just need to Fn-Delete it. I'll remember it. Here we go. I'm speaking this into the universe, so it'll be true.

+ +

CHRIS: Just Fn-Delete it.

+ +

STEPH: Your bit about the USB and always getting it wrong, you get it 50-50 [laughs] by getting it wrong, resonates so deeply with me and my capability with directions where I am just terrible whether I have to go right or left. My inner compass is going to get it wrong. And I've even tried to trick myself where I'm like, okay, I know I'm always wrong. So what if I do the opposite of what Stephanie would do? And it's still somehow wrong. [laughs]

+ +

CHRIS: Somehow, your brain compensates and is like, oh, I know that we're going to do that. So let's...yeah, it's amazing the way these things happen.

+ +

STEPH: Yep. I don't understand it. I've tried to trick the software, but I haven't figured out the right way. I should probably just learn and get better at directions. But here we are. Here we are.

+ +

CHRIS: You just loosely referred to the software, but I think you're referring to the Steph software when you say that.

+ +

STEPH: Yes. Oh yeah, Steph software totally. You got it. [laughs]

+ +

CHRIS: Gotcha. Cool. Glad that I checked in on that because that's great. But shifting gears to something a little bit deeper in the technical space, this past week, we've been thinking about passwords within our organization at Sagewell. And we're trying to decide what we want to do. We had an initial card that came through and actually got most of the way to implemented to dial up our password strictness requirements. And as I saw that come through, I was like, oh, wait, actually, I would love to talk about this.

+ +

And so we had the work that was coming through the PR that had been opened was a pretty traditional set of let's introduce some requirements on our passwords for complexity, so let's make it longer. We're going from; I think six was the default that Devise shipped with, so we're increasing that to, I think it was eight. And then let's say that it needs a number, and a special character, and an uppercase letter or something like that.

+ +

I've recently read the NIST rules, so the National Institute of Standards and Technology, I think, is what they are. But they're the ones who define a set of rules around this or guidelines. But I think they are...I don't know if they are laws or what at this point. But they tell you, "This is what you should and shouldn't do." And I know that the password complexity stuff is on the don't do that list these days. So I was like, this is interesting, and then I wanted to follow through.

+ +

Interestingly, right now, I've got the Trello boards up for The Bike Shed right now. But as a result, I can't look at the linked Trello card that is on the workboards because they're in different accounts. And Trello really has made my life more difficult than I wanted. But I'm going to pull this up elsewhere. So let's see.

+ +

So NIST stuff, just to talk through that, we can include a link in the show notes to a nice summary. But what are the NIST password requirements? Eight character minimum, that's great. Change passwords only if there is evidence of a compromise. Screen new passwords against a list of known compromised passwords. That's a really interesting one. Skip password hints, limit the number of failed authentication attempts. These all sound great to me.

+ +

The maximum password length should be at least 64 characters, so don't constrain how much someone can put in. If they want to have a very long password, let them go for it. Don't have any sort of required rotation. Allow copy and pasting or functionality that allows for password managers.

+ +

And allow the use of all printable ASCII characters as well as all Unicode characters, including emojis. And that one really caught my attention. I was like, that sounds fun. I wish I could look at all the passwords in our database. I obviously can't because they're salted and encrypted, and hashed, and all those sorts of things where I'm like, I wonder if anybody's using emojis. I'm pretty sure we would just support it. But I'm kind of intrigued.

+ +

STEPH: You said something in that list that caught my attention, and I just want to see if I heard it correctly. So you said only offer change password if compromised? Does that mean I can't just change my password if I want to?

+ +

CHRIS: Sorry. Yeah, I think the phrasing here might be a little bit odd. So it's essentially a different way to phrase this requirement is don't require rotation of passwords every six or whatever months. Forgotten password that's still a reasonable thing to have in your application, probably a necessity in most applications. But don't auto-rotate passwords, so don't say, "Your password has expired after six months."

+ +

STEPH: Got it. Okay, cool. That makes sense. Then the emojis, oh no, it's like, I mean, I use a password manager now, and thanks to several years ago where he shamed me into using one. Thank you. That was great. [laughs]

+ +

CHRIS: I hope it was friendly shame, but yeah.

+ +

STEPH: Yes, it was friendly; kind shame if that sounds like a weird sentence to say. But yes, it was a very positive change. And I can't go back now that I have a password manager in my life. Because yeah, now I'm thinking like, if I had emojis, I'd be like, oh great, now I have to think about how I was feeling at the time that then I introduced a new password. Was I happy? Was I angry? Is it a poop emoji? Is unicorn? What is it? [laughs] So that feels complicated and novel.

+ +

You also mentioned on that list that going for more complexity in terms of you have to have uppercase; you have to have a particular symbol, things like that are not on the recommended list. And I didn't know that. I'm so accustomed to that being requirements for passwords and the idea of how we create something that is secure and less easy to guess or to essentially hack. So I'm curious about that one if you know any more details about it as to why that's not the standard anymore.

+ +

CHRIS: Yeah, I think I have some ideas around it. My understanding is mostly that introducing the password complexity requirements while intended to prevent people from using very common things like names or their user name or things like that, it's like, no, no, no, you can't because we've now constrained the system in that way. It tends in practice to lead to people having a variety of passwords that they forget all the time, and then they're using the forgotten password flow more often.

+ +

And it basically, for human and behavior reasons, increases the threat surface area because it means that they're not able to use...say someone has a password scheme in mind where it's like, well, my passwords are, you know, it's this common base, and then some number of things specific to the site. It's like, oh no, no, we require three special characters, so it's like they can't do their thing. And now they have to write it down on a Post-it Note because they're not going to remember it otherwise. Or there are a variety of ways in which those complexity requirements lead to behavior that's actually less useful.

+ +

STEPH: Okay, so it's the Post-it Note threat vector that we have to be worried about. [laughs]

+ +

CHRIS: Which is a very real threat factor.

+ +

STEPH: I believe it. [laughs] Yes, I know people that keep lists of passwords on paper near their desk. [laughs] This is a thing.

+ +

CHRIS: Yep, yep, yep. The other thing that's interesting is, as you think about it, password complexity requirements technically reduce the overall combinatoric space that the passwords can exist in. Because imagine that you're a password hacker, and you're like, I have no idea what this password is. All I have is an encrypted hashed salted value, and I'm trying to crack it. And so you know the algorithm, you know how many passes, you know potentially the salt because often that is available. I think it has to be available now that I think about that out loud.

+ +

But so you've got all these pieces, and you're like, I don't know, now it's time to guess. So what's a good guess of a password? And so if you know the minimum number of characters is eight and, the maximum is 12 because that actually happens on a lot of systems, that's actually not a huge combinatoric space. And then if you say, oh, and it has to have a number, and it has to have an uppercase letter, and it has to have a special character, you're just reducing the number of possible options in that space.

+ +

And so, although this is more like a mathematical thing, but in my mind, I'm like, yeah, wait, that actually makes things less secure because now there are fewer passwords to check because they don't meet the complexity requirements. So you don't even have to try them if you're trying to brute-force crack a password.

+ +

STEPH: Yeah, you make a really good point that I hadn't really thought about because I've definitely seen those sites that, yeah, constrain you in terms of like, has to have a minimum, has to have a maximum, and I hadn't really considered the fact that they are constraining it and then reducing the values that it could be. I am curious, though, because then it doesn't feel right to have no limit in terms of, like, you don't want people then just spamming your sign up and then putting something awful in there that has a ridiculous length. So do you have any thoughts on that and providing some sort of length requirement or length maximum?

+ +

CHRIS: Yeah, I think the idea is don't prevent someone who wants to put in a long passphrase, like, let them do that. But there is, the NIST guidelines specifically say 64 characters. Devise out of the box is 128, I believe. I don't think we tweaked that, and that's what we're at right now. So you can write an old-style tweet and that can be your password if that's what you want to do. But there is an upper limit to that. So there is a reasonable upper limit, but it should be very permissive to anyone who's like, I want to crank it up.

+ +

STEPH: Cool. Cool. Yeah, I just wanted to validate that; yeah, having an upper bound is still important.

+ +

CHRIS: Yeah, definitely. Important...it's more for implementation and our database having a reasonable size and those sorts of things. Although at the end of the day, the thing that we saw is the encrypted password. So I don't know if bcrypt would run slower on a giant body of text versus a couple of characters; that might be the impact. So it would be speed as opposed to storage space because you always end up with a fixed-length hash of the same length, as far as I understand it.

+ +

But yeah, it's interesting little trade-offs like that where the complexity requirements do a good job of forcing people to not use very obvious things like password. Password does not fit nearly any complexity requirements. But we're going to try and deal with that in a different way. We don't want to try and prevent you from using password by saying you must use an uppercase letter and a special character and things that make real passwords harder as well. But it is an interesting trade-off because, technically, you're making the crackability easier. So it gets into the human and the technical and the interplay between them.

+ +

Thinking about it somewhat differently as well, there's all this stuff about you should salt your passwords, then you should hash them. You should run them through a good password hashing algorithm. So we're using bcrypt right now because I believe that's the default that Devise ships with. I've heard good things about Argon2; I think is the name of the new cool kid on the block in terms of password hashing. That whole world is very interesting to me, but at the end of the day, we can just go with Devise's defaults, and I'll feel pretty good about that and have a reasonable cost factor. Those all seem like smart things.

+ +

But then, as we start to think about the complexity requirements and especially as we start to interact with an audience like Sagewell's demographics where we're working with seniors who are perhaps less tech native, less familiar, we want to reduce the complexity there in terms of them thinking of and remembering their passwords. And so, rather than having those complexity requirements, which I think can do a good job but still make stuff harder, and how do you communicate the failure modes, et cetera, et cetera, we're switching it.

+ +

And the things that we're introducing are we have increased the minimum length, so we're up to eight characters now, which is NIST's low-end recommended, so it's between 8 and 128 characters. We are capturing anytime a I forgot password reset attempt happens and the outcome of it. So we're storing those now in the database, and we're showing them to the admins.

+ +

So our admin team can see if password reset attempts have happened and if they were successful. That feels like good information to keep around. Technically, we could get it from the logs, but that's deeply hidden away and only really accessible to the developers. So we're now surfacing that information because it feels like a particularly pertinent thing for us.

+ +

We've introduced Rack::Attack. So we're throttling those attempts, and if someone tries to just brute force through that credential stuffing, as the terminology goes, we will lock them out so either based on IP address or the account that they're trying to log into. We also have Devise's lockable module enabled. So if someone tries to log in a bunch of times and fails, their account will go into a locked state, and then an admin can unlock it. But it gives us a little more control there. So a bunch of those are already in place.

+ +

The new one, this is the one that I'm most excited about, is we're going to introduce Have I Been Pwned? And so, they have an API. We can hit it. It's a really interesting model as to how do we ask if a password has been compromised without giving them the password? And it turns out there's this fun sort of cryptographic handshake thing that happens. K-anonymity is apparently the mechanism or the underpinning technology or idea.

+ +

Anyway, it's super cool; I'm excited to build it. It's going to be fun. But the idea there is rather than saying, "Don't use a password that might not be secure," it's, "Hey, we actually definitively know that your password has been cracked and is available in plaintext on the internet, so we're not going to let you use that one."

+ +

STEPH: And that's part of the signup flow as to where you would catch that?

+ +

CHRIS: So we're going to introduce on both signup and sign-in because a password can be compromised after a user signs up for our system. So we want to have it at any point. Obviously, we do not keep their plaintext password, so we can't do this retroactively. We can only do it at the point in time that they are either signing up or signing in because that's when we do have access to the password. We otherwise throw it away and keep only the hashed value. But we'll probably introduce it at both points.

+ +

And the interesting thing is communicating this failure mode is really tricky. Like, "Hey, your password is cracked, not like here, not on our site, no, we're fine. Well, you should probably change your password. So here's what it means, there's actually this database that's called Have I Been Pwned? Don't worry; it's good, though. It's P-W-N-E-D. But that's fine." That's too many words to put on a page. I can't even say it here in a podcast.

+ +

And so what we're likely to do initially is instrument it such that our admin team will get a notification and can see that a user's password has been compromised. At that point, we will reach out to them and then, using the magic of human conversation, try and actually communicate that and help them understand the ramifications, what they should do, et cetera. Longer-term, we may find a way to build up an FAQ page that describes it and then say, "Feel free to reach out if you have questions." But we want to start with the higher touch approach, so that's where we're at.

+ +

STEPH: I love it. I love that you dove into how to explain this to people as well because I was just thinking, like, this is complicated, and you're going to freak people out in panic. But you want them to take action but not panic. Well, I don't know, maybe they should panic a little bit. [laughs]

+ +

CHRIS: They should panic just the right amount.

+ +

STEPH: Right.[laughs] So I like the starting with the more manual process of reaching out to people because then you can find out more, like, how did people react to this? What kind of questions did they ask? And then collect that data and then turn that into an FAQ page. Just, well done.

+ +

CHRIS: We haven't quite done it yet. But I am very happy with the collection of ideas that we've come to here. We have a security firm that we're working with as well. And so I had my weekly meeting with them, and I was like, "Oh yeah, we also thought about passwords a bunch, and here's what we came up with." And I was very happy that they were like, "Yeah, that sounds like a good set." I was like, "Cool. All right, I feel good." I'm very happy that we're getting to do this.

+ +

And there's an interesting sort of interplay between security theater and real security. And security theater, just to explain the phrase if anyone's unfamiliar with it, is things that look like security, so, you know, big green lock up in the top-left corner of the URL bar. That actually doesn't mean anything historically or now. But it really looks like it's very secure, right? Or password complexity requirements make you think, oh, this must be a very secure site. But for reasons, that actually doesn't necessarily prove that at all.

+ +

And so we tried to find the balance of what are the things that obviously demonstrate our considerations around security to the user? At the end of the day, what are the things that actually will help protect our users? That's what I really care about. But occasionally, you got to play the security theater game. Every other financial institution on the internet kind of looks and feels a certain way in how they deal with passwords.

+ +

And so will a user look at our seemingly laxer requirements or laxer approach to passwords and judge us for that and consider us less secure despite the fact that behind the scenes look at all the fun stuff we're doing for you? But it's an interesting question and interesting trade-off that we're going to have to spend time with. We may end up with the complexity requirements despite the fact that I would really rather we didn't. But it may be the sort of thing that there is not a good way to communicate the thought and decision-making process that led us to where we're at and the other things that we're doing.

+ +

And so we're like, fine, we just got to put them in and try and do a great job and make that as usable of an experience as possible because usability is, I think, one of the things that suffers there. You didn't do one of the things on the list, or like, it's green for each of the ones that you did, but it's red for the one that you didn't. And your password and your password confirmation don't match, and you can't paste...it's very easy to make this wildly complex for users.

+ +

STEPH: Security theater is a phrase that I don't think I've used, but the way you're describing it, I really like. And I have a solution for you: underneath the password where you have "We don't partake in security theater, and we don't have all the other fancy requirements that you may have seen floating around the internet and here's why," and then just drop a link to the episode. And, you know, people can come here and listen. It'll totally be great. It won't annoy anyone at all. [laughs]

+ +

CHRIS: And it'll start, and they'll hear me yelling about Fn-Delete that weather.com URL.

+ +

[laughter]

+ +

STEPH: Okay, maybe fast forward then to the part about --

+ +

CHRIS: Drop them to the timestamp. That makes sense. Yep. Yep.

+ +

STEPH: Mm-hmm. Mm-hmm. [laughs]

+ +

CHRIS: I like it. I think that's what we should do, yeah. Most features on the app should have a link to a Bike Shed episode. That feels true.

+ +

STEPH: Excellent Easter egg. I'm into it. But yeah, I like all the thoughtfulness that y'all have put into this because I haven't had to think about passwords in this level of detail. And then also, yeah, switching over to when things start to change and start to move away, you're right; there's still that we need to help people then become comfortable with this new way and let them know that this is just as secure if not more secure. But then there's already been that standard that has been set for your expectations, and then how do you help people along that path? So yeah, seems like y'all have a lot of really great thoughtfulness going into it.

+ +

CHRIS: Well, thank you. Yeah, it's frankly been a lot of fun. I really like thinking in this space. It's a fun sort of almost hobby that happens to align very well with my profession sort of thing. Actually, oh, I have one other idea that we're not going to do, but this is something that I've had in the back of my mind for a long time.

+ +

So when we use bcrypt or Devise uses bcrypt under the hood, one of the things that it configures is the cost factor, which I believe is just the number of times that the password plus the salts and whatnot is run through the bcrypt algorithm. The idea there is you want it to be computationally difficult, and so by doing it multiple times, you increase that difficulty.

+ +

But what I'd love is instead of thinking of it in terms of an arbitrary cost factor which I think is 12, like, I don't know what 12 means. I want to know it, in terms of dollars, how much would it cost to, like dollars and cents, to crack a password. Because, in theory, you can distribute this across any number of EC2 instances that you spin up. The idea of cracking a password that's a very map-reducible type problem.

+ +

So let's assume that you can infinitely scale up compute on-demand; how much would it cost in dollars to break this password? And I feel like there's an answer. Like, I want that number to be like a million dollars. But as EC2 costs go down over time, I want to hold that line. I want to be like, a million dollars is the line that we want to have. And so, as EC2 prices go down, we need to increase our bcrypt cost factor over time to adjust for that and maintain the million dollar per password cracking sort of high bar. That's the dream.

+ +

Swapping out the cost factor is actually really difficult. I've looked into it, and you have to like double encrypt and do weird stuff. So for a bunch of reasons, I haven't done this, but I just like that idea. Let's pin this to $1 value. And then, from there, decisions naturally flow out of it. But it's so much more of a real thing. A million dollars, I know what that means; 12, I don't know what 12 means.

+ +

STEPH: A million-dollar password, I like it. I feel like --

+ +

CHRIS: We named the episode.

+ +

STEPH: I was going to say that's a perfect title, A Million-Dollar Password. [laughs]

+ +

CHRIS: A Million-Dollar Password. But with that wonderful episode naming cap there, I think I'm done rambling about passwords. What's up in your world, Steph?

+ +

STEPH: One of the things that I've been chatting with folks lately is RailsConf is coming up; it's May 17 through the 19th. And it's been sort of like that casual conversation of like, "Hey, are you going? Are you going? Who's going? It's going to be great." And as people have asked like, "Are you going?" And I'm always like, "No, I'm not going." But then I popped on to the RailsConf website today because I was just curious. I wanted to see the schedule and the talks that are being given.

+ +

And I keep forgetting that there's the in-person version, but there's also the home edition. And I was like, oh, I could go, I could do this. [laughs] And I just forget that that is something that is just more common now for conferences where you can attend them virtually, and that is just really neat. So I started looking a little more closely at the talks. And I'm really excited because we have a number of thoughtboters that are giving a talk at RailsConf this year.

+ +

So there's a talk being given by Fernando Perales that's called Open the Gate a Little: Strategies to Protect and Share Data. There's also a talk being given by Joël Quenneville: Your Test Suite is Making Too Many Database Calls. I'm very excited; just that one is near and dear to my heart, given the current client experiences that I'm having. And then there's another one from someone who just joined thoughtbot, Christopher "Aji" Slater, Your TDD Treasure Map.

+ +

So we'll be sure to include a link to those for anyone that's curious. But it's a stellar lineup. I mean, I'm always impressed with RailsConf talks. But this one, in particular, has me very excited. Do you have any plans for RailsConf? Do you typically wait for them to come out later and then watch them, or what's your MO?

+ +

CHRIS: Historically, I've tended to watch the conference recordings after the fact. I went one year. I actually met Christopher "Aji" Slater at that very RailsConf that I went to, and I believe Joël Quenneville was speaking at that one. So lots of everything old is new again. But yeah, I think I'll probably catch it after the fact in this case.

+ +

I'd love to go back in person at some point because I really do like the in-person thing. I'm thrilled that there is the remote option as well. But for me personally, the hallway track and hanging out and meeting folks is a very exciting part. So that's probably the mode that I would go with in the future. But I think, for now, I'm probably just going to watch some talks as they come out.

+ +

STEPH: Yeah, that's typically what I've done in the past, too, is I kind of wait for things to come out, and then I go through and make a list of the ones that I want to watch, and then, you know, I can make popcorn at home. It's delightful. I can just get cozy and have an evening of RailsConf talks. That's what normal people do on Friday nights, right? That's totally normal. [laughs]

+ +

CHRIS: I mean, yeah, maybe not the popcorn part.

+ +

STEPH: No popcorn?

+ +

CHRIS: But not that I'm opposed to popcorn just —-

+ +

STEPH: Brussels sprouts? What do you need? [laughs]

+ +

CHRIS: Yeah, Brussels sprouts, that's what it is. Just sitting there eating handfuls of Brussels sprouts watching Ruby conference talks.

+ +

STEPH: [laughs]

+ +

CHRIS: I do love Brussels sprouts, just to throw it out there. I don't want it to be out in the ether that I don't like them. I got an air fryer, and so I can air fry Brussels sprouts. And they're delicious. I mean, I like them regardless. But that is a really fantastic way to cook them at home. So I'm a big fan.

+ +

STEPH: All right, I'm moving you into the category of fancy friends, fancy friends with an air fryer.

+ +

CHRIS: I wasn't already in your category of fancy friends?

+ +

STEPH: [laughs] I didn't think you'd take it that way. I'm sorry to break it to you.

+ +

[laughter]

+ +

CHRIS: I'm actually a little hurt that I'm now in the category of fancy friends. It makes a lot of sense that I wasn't there before. So I'll just deal with...yeah, it's fine. I'm fine.

+ +

STEPH: It's a weird rubric that I'm running over here. Pivoting away quickly, so I don't have to explain the categorization for fancy friends, I saw something in the Ruby Weekly Newsletter that had just come out. And it's one of those that I see surface every so often, and I feel like it's a nice reminder because I know it's something that even I tend to forget. And so I thought it'd be fun just to resurface it here. And then, we can also provide a link to the wonderful blog post that's written by Benito Serna.

+ +

And it's the difference between count, length, and size and an association with ActiveRecord. So for folks that would love a refresher, so count, that's a method that's always going to perform a SQL count query. So even if the collection has already been loaded, then calling count is always going to execute a database query. So this is the one that's just like, watch out, avoid it. You're always going to hit your database when you use this one.

+ +

And then next is length. And so, length loads the whole collection into memory and then returns that length to the number of items in that collection. If the collection has been loaded, then it's not going to issue a database call. And then it's just still going to use...it's going to delegate to that Ruby length method and let you know how many records are in that collection. So that one is a little bit better because then that way, if it's already loaded, at least you're not going to have a database call.

+ +

And then next is the size method, which is just the one that's more highly recommended that you use because this one does have a nice safety net that is built-in because first, it's going to check if we need to perform a database call, if the records have been loaded or not. So if the collection has not been loaded, so we haven't executed a database query and stored the result, then size is going to perform a database query. Specifically, it's using that SQL count under the hood. And if the collection has been loaded, then a database call is not issued, and then going to use the Ruby length method to then return the number of records.

+ +

So it just helps you prevent unnecessary database calls. And it's the reason that that one is recommended over using count, which is going to always issue a call. And then also to avoid length where you can because it's going to load the whole collection into memory, and we want to avoid that. So it was a nice refresher. I'll be sure to include a link in the show notes.

+ +

But yeah, I find that I myself often forget about the difference in count and size. And so if I'm just in the console and I just want to know something, that I still reach for count. It is still a default for mine. But then, if I'm writing production code, then I will be more considered as to which one I'm using.

+ +

CHRIS: I feel like this is one of those that I've struggled to lock into my head, but as you're describing it right now, I think I've got, again, another mnemonic device that we can lock on to. So I know that SQL uses the keyword count, so count that's SQL definitely. Length I know that because I use that on other stuff. And so it's size that is different and therefore special. That all seems good. Cool, locking that in my brain along with Fn-Delete. I have two things that are now firmly locked in.

+ +

So you were just mentioning being in the console and working with this. And one of the things that I've noticed a lot with folks that are newer to ActiveRecord and the idea of relations and the fact that they're lazy, is that that concept is very hard to grasp when working in a console because at the console, they don't seem lazy.

+ +

The minute you type out user.where some clause, and the minute you type that and hit enter in the console, Ruby is going to do its normal thing, which is like, okay, cool, I want to...I forget what it is that IRB or any of the REPLs are going to do, but it's either inspect or to_s or something like that. But it's looking for a representation that it can display in the console. And ActiveRecord relations will typically say like, "Oh, cool, you need the records now because you want to show it like an array because that's what inspect is doing under the hood."

+ +

So at the console, it looks like ActiveRecord is eager and will evaluate the query the minute you type it, but that's not true. And this is a critical thing that if you can think about it in that way and the fact that ActiveRecord relations are lazy and then take advantage of it, you can chain queries, you can build them up, you can break that apart. You can compose them together. There's really magical stuff that falls out of that.

+ +

But it's interesting because sort of like a Heisenberg where the minute you go to look at it in the REPL, it's like, oh, it is not lazy; it is eager. It evaluates it the minute I type the query. But that's not true; that's actually the REPL tricking you. I will often just throw a semicolon at the end of it because I'm like, I don't want to see all that noise. Just give me the relation. I want the relation, not the results of executing that query. So if you tack a semicolon at the end of the line, that tells Ruby not to print the thing, and then you're good to go from there.

+ +

STEPH: That's a great pro-tip. Yeah, I've forgotten about the semicolon. And I haven't been using that in my workflow as much. So I'm so glad you mentioned that. Yeah, I'm sure that's part of the thing that's added to my confusion around this, too, or something that has just taken me a while to lock it in as to which approach I want to use for when I'm querying data or for when I need to get a particular count, or length, or size. And by using all three, I'm just confusing myself more. So I should really just stick to using size.

+ +

There's also a fabulous article by Nate Berkopec that's titled Three ActiveRecord Mistakes That Slow Down Rails Apps. And he does a fabulous job of also talking about the differences of when to use size and then some of the benefits of when you might use count. The short version is that you can use count if you truly don't care about using any of those records. Like, you're not going to do anything with them. You don't need to load them, like; you truly just want to get a count. Then sure, because then you're issuing a database query, but then you're not going to then, in a view, very soon issue another database query to collect those records again. So he has some really great examples, and I'll be sure to include a link to his article as well.

+ +

Speaking of Ruby tidbits and kind of how this particular article about count, length, and size came across my view earlier today, Ruby Weekly is a wonderful newsletter. And I feel like I don't know if I've given them a shout-out. They do a wonderful job. So if you haven't yet checked out Ruby Weekly, I highly recommend it.

+ +

There are just always really great, interesting articles either about stuff that's a little bit more like cutting edge or things that are being released with newer versions, or they might be just really helpful tips around something that someone learned, like the difference between count, length, and size, and I really enjoy it. So I'll also be sure to include a link in the show notes for anyone that wants to check that out.

+ +

They also do something that I really appreciate where when you go to their website, you have the option to subscribe, but I am terrible about subscribing to stuff. So you can still click and check out the latest issue, which I really appreciate because then, that way, I don't feel obligated to subscribe, but I can still see the content.

+ +

CHRIS: Oh yeah. Ruby Weekly is fantastic. In fact, I think Peter Cooper is the person behind it, or Cooperpress as the company goes. And there is a whole slew of newsletters that they produce. So there's JavaScript Weekly, there's Ruby Weekly, there's Node Weekly, Golang Weekly, React Status, Postgres Weekly. There's a whole bunch of them. They're all equally fantastic, the same level of curation and intentional content and all those wonderful things. So I'm a big fan. I'm subscribed to a handful of them.

+ +

And just because I can't go an episode without mentioning inbox zero, if you are the sort of person that likes to defend the pristine nature of your email inbox, I highly recommend Feedbin and their ability to set up a special email address that you can use to then turn it into an RSS feed because that's magical. Actually, these ones might already have an RSS feed under the hood. But yeah, RSS is still alive. It's still out there. I love it. It's great. And that ends my thoughts on that matter.

+ +

STEPH: I have what I feel is a developer confession. I don't think I really appreciate RSS feeds. I know they're out there in the ether, and people love them. And I just have no emotion, no opinion attached to them. So one day, I think I need to enjoy the enrichment that is RSS feeds, or maybe I'll hate it. Who knows? I'm reserving judgment. Either way, I don't think I will. [laughs] But I don't want to box future Stephanie in.

+ +

CHRIS: Gotta maintain that freedom.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Chris came up with a mnemonic device: Fn-Delete – for when he really wants to delete something and is also thinking about password complexity requirements, which leads to an exciting discussion around security theater.

+ +

Steph talks about the upcoming RailsConf and the not-in-person option for virtual attendees. She also gives a shoutout to the Ruby Weekly newsletter for being awesome.

+ +
+ +

NIST Password Standards
+3 ActiveRecord Mistakes That Slow Down Rails Apps: Count, Where and Present
+Difference between count, length and size in an association with ActiveRecord
+Ruby Weekly
+Railsconf 2022

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, happy Friday. You know, each time I do that, I can't resist the urge to say happy Friday, but then I realize people aren't listening on a Friday. So happy day to anyone that's listening. What's new in your world, friend?

+ +

CHRIS: I'm going to be honest; you threw me for a loop there. [laughs] I think it was the most recent episode where we talked about my very specific...[laughs] it's a lovely Friday, that's true. There's sun and clouds. Those are true things. But yeah, what's new in my world? [laughs] I can do this. I can focus. I got this.

+ +

Actually, I have one thing. So this is going to be, I'm going to say vaguely selfish, but I have this thing that I've been trying to commit into my brain for a long time, and I just can't get it to stick. So today, I came up with like a mnemonic device for it. And I'm going to share it on The Bike Shed because maybe it'll be useful for other people. And then hopefully, in quote, unquote, "teaching it," I will deeply learn it.

+ +

So the thing that happens in my world is occasionally, I want to delete a URL from Chrome's autocomplete. To be more specific, because it's easier for people to run away with that idea, it's The Weather Channel. I do not like weather.com. I try to type weather often, and I just want Google to show me the little, very quick pop-up thing there. I don't want any ads. I don't want to deal with that.

+ +

But somehow, often, weather.com ends up in my results. I somehow accidentally click on it. It just gets auto-populated, and then that's the first thing that happens whenever I type weather into the Omnibox in Chrome. And I get unhappy, and I deal with it for a while, then eventually I'm like, you know what? I'm deleting it. I'm getting it out of there. And then I try and remember whatever magical key combination it is that allows you to delete an entry from the drop-down list there. And I know it's a weird combination of like, Command-Shift-Alt-Delete, Backspace, something.

+ +

And every single time, it's the same. I'm like, I know it's weird, but let me try this one. How about that one? How about that one? I feel like I try every possible combination. It's like when you try and plug in a USB drive, and you're like, well, it's this way. No, it's the other way. Well, there are only two options, and I've already tried two things. How can I not have gotten it yet? But I got it now.

+ +

Okay, so on a Mac specifically, the key sequence is Shift-Function-Delete. So the way I'm going to remember this is Function is abbreviated on the keyboard as Fn. So that can be like I'm swearing, like, I'm very angry about this. And then Shift is the way to uppercase something like you're shouting. So I just really need to Fn-Delete this. So that's how I'm going to remember it. Now I've shared it with everyone else, and hopefully, some other folks can get utility out of that. But really, I hope that I remember it now that I've tried to boil it down to a memorable thing.

+ +

STEPH: [laughs] It's definitely memorable. I'm now going to remember just that I need to Fn-Delete this. And I'm not going to remember what it all is tied to. [laughs]

+ +

CHRIS: That is the power of a mnemonic device. Yeah.

+ +

STEPH: Like, I know this is useful in some way, but I can't remember what it is. But yeah, that's wonderful. I love it. That's something that I haven't had to do in a long time, and I hadn't thought about. I need to do that more. Because you're right, especially changing projects or things like that, there are just some URLs that I don't need cached anymore; I don't want auto-completed. So yeah, okay. I just need to Fn-Delete it. I'll remember it. Here we go. I'm speaking this into the universe, so it'll be true.

+ +

CHRIS: Just Fn-Delete it.

+ +

STEPH: Your bit about the USB and always getting it wrong, you get it 50-50 [laughs] by getting it wrong, resonates so deeply with me and my capability with directions where I am just terrible whether I have to go right or left. My inner compass is going to get it wrong. And I've even tried to trick myself where I'm like, okay, I know I'm always wrong. So what if I do the opposite of what Stephanie would do? And it's still somehow wrong. [laughs]

+ +

CHRIS: Somehow, your brain compensates and is like, oh, I know that we're going to do that. So let's...yeah, it's amazing the way these things happen.

+ +

STEPH: Yep. I don't understand it. I've tried to trick the software, but I haven't figured out the right way. I should probably just learn and get better at directions. But here we are. Here we are.

+ +

CHRIS: You just loosely referred to the software, but I think you're referring to the Steph software when you say that.

+ +

STEPH: Yes. Oh yeah, Steph software totally. You got it. [laughs]

+ +

CHRIS: Gotcha. Cool. Glad that I checked in on that because that's great. But shifting gears to something a little bit deeper in the technical space, this past week, we've been thinking about passwords within our organization at Sagewell. And we're trying to decide what we want to do. We had an initial card that came through and actually got most of the way to implemented to dial up our password strictness requirements. And as I saw that come through, I was like, oh, wait, actually, I would love to talk about this.

+ +

And so we had the work that was coming through the PR that had been opened was a pretty traditional set of let's introduce some requirements on our passwords for complexity, so let's make it longer. We're going from; I think six was the default that Devise shipped with, so we're increasing that to, I think it was eight. And then let's say that it needs a number, and a special character, and an uppercase letter or something like that.

+ +

I've recently read the NIST rules, so the National Institute of Standards and Technology, I think, is what they are. But they're the ones who define a set of rules around this or guidelines. But I think they are...I don't know if they are laws or what at this point. But they tell you, "This is what you should and shouldn't do." And I know that the password complexity stuff is on the don't do that list these days. So I was like, this is interesting, and then I wanted to follow through.

+ +

Interestingly, right now, I've got the Trello boards up for The Bike Shed right now. But as a result, I can't look at the linked Trello card that is on the workboards because they're in different accounts. And Trello really has made my life more difficult than I wanted. But I'm going to pull this up elsewhere. So let's see.

+ +

So NIST stuff, just to talk through that, we can include a link in the show notes to a nice summary. But what are the NIST password requirements? Eight character minimum, that's great. Change passwords only if there is evidence of a compromise. Screen new passwords against a list of known compromised passwords. That's a really interesting one. Skip password hints, limit the number of failed authentication attempts. These all sound great to me.

+ +

The maximum password length should be at least 64 characters, so don't constrain how much someone can put in. If they want to have a very long password, let them go for it. Don't have any sort of required rotation. Allow copy and pasting or functionality that allows for password managers.

+ +

And allow the use of all printable ASCII characters as well as all Unicode characters, including emojis. And that one really caught my attention. I was like, that sounds fun. I wish I could look at all the passwords in our database. I obviously can't because they're salted and encrypted, and hashed, and all those sorts of things where I'm like, I wonder if anybody's using emojis. I'm pretty sure we would just support it. But I'm kind of intrigued.

+ +

STEPH: You said something in that list that caught my attention, and I just want to see if I heard it correctly. So you said only offer change password if compromised? Does that mean I can't just change my password if I want to?

+ +

CHRIS: Sorry. Yeah, I think the phrasing here might be a little bit odd. So it's essentially a different way to phrase this requirement is don't require rotation of passwords every six or whatever months. Forgotten password that's still a reasonable thing to have in your application, probably a necessity in most applications. But don't auto-rotate passwords, so don't say, "Your password has expired after six months."

+ +

STEPH: Got it. Okay, cool. That makes sense. Then the emojis, oh no, it's like, I mean, I use a password manager now, and thanks to several years ago where he shamed me into using one. Thank you. That was great. [laughs]

+ +

CHRIS: I hope it was friendly shame, but yeah.

+ +

STEPH: Yes, it was friendly; kind shame if that sounds like a weird sentence to say. But yes, it was a very positive change. And I can't go back now that I have a password manager in my life. Because yeah, now I'm thinking like, if I had emojis, I'd be like, oh great, now I have to think about how I was feeling at the time that then I introduced a new password. Was I happy? Was I angry? Is it a poop emoji? Is unicorn? What is it? [laughs] So that feels complicated and novel.

+ +

You also mentioned on that list that going for more complexity in terms of you have to have uppercase; you have to have a particular symbol, things like that are not on the recommended list. And I didn't know that. I'm so accustomed to that being requirements for passwords and the idea of how we create something that is secure and less easy to guess or to essentially hack. So I'm curious about that one if you know any more details about it as to why that's not the standard anymore.

+ +

CHRIS: Yeah, I think I have some ideas around it. My understanding is mostly that introducing the password complexity requirements while intended to prevent people from using very common things like names or their user name or things like that, it's like, no, no, no, you can't because we've now constrained the system in that way. It tends in practice to lead to people having a variety of passwords that they forget all the time, and then they're using the forgotten password flow more often.

+ +

And it basically, for human and behavior reasons, increases the threat surface area because it means that they're not able to use...say someone has a password scheme in mind where it's like, well, my passwords are, you know, it's this common base, and then some number of things specific to the site. It's like, oh no, no, we require three special characters, so it's like they can't do their thing. And now they have to write it down on a Post-it Note because they're not going to remember it otherwise. Or there are a variety of ways in which those complexity requirements lead to behavior that's actually less useful.

+ +

STEPH: Okay, so it's the Post-it Note threat vector that we have to be worried about. [laughs]

+ +

CHRIS: Which is a very real threat factor.

+ +

STEPH: I believe it. [laughs] Yes, I know people that keep lists of passwords on paper near their desk. [laughs] This is a thing.

+ +

CHRIS: Yep, yep, yep. The other thing that's interesting is, as you think about it, password complexity requirements technically reduce the overall combinatoric space that the passwords can exist in. Because imagine that you're a password hacker, and you're like, I have no idea what this password is. All I have is an encrypted hashed salted value, and I'm trying to crack it. And so you know the algorithm, you know how many passes, you know potentially the salt because often that is available. I think it has to be available now that I think about that out loud.

+ +

But so you've got all these pieces, and you're like, I don't know, now it's time to guess. So what's a good guess of a password? And so if you know the minimum number of characters is eight and, the maximum is 12 because that actually happens on a lot of systems, that's actually not a huge combinatoric space. And then if you say, oh, and it has to have a number, and it has to have an uppercase letter, and it has to have a special character, you're just reducing the number of possible options in that space.

+ +

And so, although this is more like a mathematical thing, but in my mind, I'm like, yeah, wait, that actually makes things less secure because now there are fewer passwords to check because they don't meet the complexity requirements. So you don't even have to try them if you're trying to brute-force crack a password.

+ +

STEPH: Yeah, you make a really good point that I hadn't really thought about because I've definitely seen those sites that, yeah, constrain you in terms of like, has to have a minimum, has to have a maximum, and I hadn't really considered the fact that they are constraining it and then reducing the values that it could be. I am curious, though, because then it doesn't feel right to have no limit in terms of, like, you don't want people then just spamming your sign up and then putting something awful in there that has a ridiculous length. So do you have any thoughts on that and providing some sort of length requirement or length maximum?

+ +

CHRIS: Yeah, I think the idea is don't prevent someone who wants to put in a long passphrase, like, let them do that. But there is, the NIST guidelines specifically say 64 characters. Devise out of the box is 128, I believe. I don't think we tweaked that, and that's what we're at right now. So you can write an old-style tweet and that can be your password if that's what you want to do. But there is an upper limit to that. So there is a reasonable upper limit, but it should be very permissive to anyone who's like, I want to crank it up.

+ +

STEPH: Cool. Cool. Yeah, I just wanted to validate that; yeah, having an upper bound is still important.

+ +

CHRIS: Yeah, definitely. Important...it's more for implementation and our database having a reasonable size and those sorts of things. Although at the end of the day, the thing that we saw is the encrypted password. So I don't know if bcrypt would run slower on a giant body of text versus a couple of characters; that might be the impact. So it would be speed as opposed to storage space because you always end up with a fixed-length hash of the same length, as far as I understand it.

+ +

But yeah, it's interesting little trade-offs like that where the complexity requirements do a good job of forcing people to not use very obvious things like password. Password does not fit nearly any complexity requirements. But we're going to try and deal with that in a different way. We don't want to try and prevent you from using password by saying you must use an uppercase letter and a special character and things that make real passwords harder as well. But it is an interesting trade-off because, technically, you're making the crackability easier. So it gets into the human and the technical and the interplay between them.

+ +

Thinking about it somewhat differently as well, there's all this stuff about you should salt your passwords, then you should hash them. You should run them through a good password hashing algorithm. So we're using bcrypt right now because I believe that's the default that Devise ships with. I've heard good things about Argon2; I think is the name of the new cool kid on the block in terms of password hashing. That whole world is very interesting to me, but at the end of the day, we can just go with Devise's defaults, and I'll feel pretty good about that and have a reasonable cost factor. Those all seem like smart things.

+ +

But then, as we start to think about the complexity requirements and especially as we start to interact with an audience like Sagewell's demographics where we're working with seniors who are perhaps less tech native, less familiar, we want to reduce the complexity there in terms of them thinking of and remembering their passwords. And so, rather than having those complexity requirements, which I think can do a good job but still make stuff harder, and how do you communicate the failure modes, et cetera, et cetera, we're switching it.

+ +

And the things that we're introducing are we have increased the minimum length, so we're up to eight characters now, which is NIST's low-end recommended, so it's between 8 and 128 characters. We are capturing anytime a I forgot password reset attempt happens and the outcome of it. So we're storing those now in the database, and we're showing them to the admins.

+ +

So our admin team can see if password reset attempts have happened and if they were successful. That feels like good information to keep around. Technically, we could get it from the logs, but that's deeply hidden away and only really accessible to the developers. So we're now surfacing that information because it feels like a particularly pertinent thing for us.

+ +

We've introduced Rack::Attack. So we're throttling those attempts, and if someone tries to just brute force through that credential stuffing, as the terminology goes, we will lock them out so either based on IP address or the account that they're trying to log into. We also have Devise's lockable module enabled. So if someone tries to log in a bunch of times and fails, their account will go into a locked state, and then an admin can unlock it. But it gives us a little more control there. So a bunch of those are already in place.

+ +

The new one, this is the one that I'm most excited about, is we're going to introduce Have I Been Pwned? And so, they have an API. We can hit it. It's a really interesting model as to how do we ask if a password has been compromised without giving them the password? And it turns out there's this fun sort of cryptographic handshake thing that happens. K-anonymity is apparently the mechanism or the underpinning technology or idea.

+ +

Anyway, it's super cool; I'm excited to build it. It's going to be fun. But the idea there is rather than saying, "Don't use a password that might not be secure," it's, "Hey, we actually definitively know that your password has been cracked and is available in plaintext on the internet, so we're not going to let you use that one."

+ +

STEPH: And that's part of the signup flow as to where you would catch that?

+ +

CHRIS: So we're going to introduce on both signup and sign-in because a password can be compromised after a user signs up for our system. So we want to have it at any point. Obviously, we do not keep their plaintext password, so we can't do this retroactively. We can only do it at the point in time that they are either signing up or signing in because that's when we do have access to the password. We otherwise throw it away and keep only the hashed value. But we'll probably introduce it at both points.

+ +

And the interesting thing is communicating this failure mode is really tricky. Like, "Hey, your password is cracked, not like here, not on our site, no, we're fine. Well, you should probably change your password. So here's what it means, there's actually this database that's called Have I Been Pwned? Don't worry; it's good, though. It's P-W-N-E-D. But that's fine." That's too many words to put on a page. I can't even say it here in a podcast.

+ +

And so what we're likely to do initially is instrument it such that our admin team will get a notification and can see that a user's password has been compromised. At that point, we will reach out to them and then, using the magic of human conversation, try and actually communicate that and help them understand the ramifications, what they should do, et cetera. Longer-term, we may find a way to build up an FAQ page that describes it and then say, "Feel free to reach out if you have questions." But we want to start with the higher touch approach, so that's where we're at.

+ +

STEPH: I love it. I love that you dove into how to explain this to people as well because I was just thinking, like, this is complicated, and you're going to freak people out in panic. But you want them to take action but not panic. Well, I don't know, maybe they should panic a little bit. [laughs]

+ +

CHRIS: They should panic just the right amount.

+ +

STEPH: Right.[laughs] So I like the starting with the more manual process of reaching out to people because then you can find out more, like, how did people react to this? What kind of questions did they ask? And then collect that data and then turn that into an FAQ page. Just, well done.

+ +

CHRIS: We haven't quite done it yet. But I am very happy with the collection of ideas that we've come to here. We have a security firm that we're working with as well. And so I had my weekly meeting with them, and I was like, "Oh yeah, we also thought about passwords a bunch, and here's what we came up with." And I was very happy that they were like, "Yeah, that sounds like a good set." I was like, "Cool. All right, I feel good." I'm very happy that we're getting to do this.

+ +

And there's an interesting sort of interplay between security theater and real security. And security theater, just to explain the phrase if anyone's unfamiliar with it, is things that look like security, so, you know, big green lock up in the top-left corner of the URL bar. That actually doesn't mean anything historically or now. But it really looks like it's very secure, right? Or password complexity requirements make you think, oh, this must be a very secure site. But for reasons, that actually doesn't necessarily prove that at all.

+ +

And so we tried to find the balance of what are the things that obviously demonstrate our considerations around security to the user? At the end of the day, what are the things that actually will help protect our users? That's what I really care about. But occasionally, you got to play the security theater game. Every other financial institution on the internet kind of looks and feels a certain way in how they deal with passwords.

+ +

And so will a user look at our seemingly laxer requirements or laxer approach to passwords and judge us for that and consider us less secure despite the fact that behind the scenes look at all the fun stuff we're doing for you? But it's an interesting question and interesting trade-off that we're going to have to spend time with. We may end up with the complexity requirements despite the fact that I would really rather we didn't. But it may be the sort of thing that there is not a good way to communicate the thought and decision-making process that led us to where we're at and the other things that we're doing.

+ +

And so we're like, fine, we just got to put them in and try and do a great job and make that as usable of an experience as possible because usability is, I think, one of the things that suffers there. You didn't do one of the things on the list, or like, it's green for each of the ones that you did, but it's red for the one that you didn't. And your password and your password confirmation don't match, and you can't paste...it's very easy to make this wildly complex for users.

+ +

STEPH: Security theater is a phrase that I don't think I've used, but the way you're describing it, I really like. And I have a solution for you: underneath the password where you have "We don't partake in security theater, and we don't have all the other fancy requirements that you may have seen floating around the internet and here's why," and then just drop a link to the episode. And, you know, people can come here and listen. It'll totally be great. It won't annoy anyone at all. [laughs]

+ +

CHRIS: And it'll start, and they'll hear me yelling about Fn-Delete that weather.com URL.

+ +

[laughter]

+ +

STEPH: Okay, maybe fast forward then to the part about --

+ +

CHRIS: Drop them to the timestamp. That makes sense. Yep. Yep.

+ +

STEPH: Mm-hmm. Mm-hmm. [laughs]

+ +

CHRIS: I like it. I think that's what we should do, yeah. Most features on the app should have a link to a Bike Shed episode. That feels true.

+ +

STEPH: Excellent Easter egg. I'm into it. But yeah, I like all the thoughtfulness that y'all have put into this because I haven't had to think about passwords in this level of detail. And then also, yeah, switching over to when things start to change and start to move away, you're right; there's still that we need to help people then become comfortable with this new way and let them know that this is just as secure if not more secure. But then there's already been that standard that has been set for your expectations, and then how do you help people along that path? So yeah, seems like y'all have a lot of really great thoughtfulness going into it.

+ +

CHRIS: Well, thank you. Yeah, it's frankly been a lot of fun. I really like thinking in this space. It's a fun sort of almost hobby that happens to align very well with my profession sort of thing. Actually, oh, I have one other idea that we're not going to do, but this is something that I've had in the back of my mind for a long time.

+ +

So when we use bcrypt or Devise uses bcrypt under the hood, one of the things that it configures is the cost factor, which I believe is just the number of times that the password plus the salts and whatnot is run through the bcrypt algorithm. The idea there is you want it to be computationally difficult, and so by doing it multiple times, you increase that difficulty.

+ +

But what I'd love is instead of thinking of it in terms of an arbitrary cost factor which I think is 12, like, I don't know what 12 means. I want to know it, in terms of dollars, how much would it cost to, like dollars and cents, to crack a password. Because, in theory, you can distribute this across any number of EC2 instances that you spin up. The idea of cracking a password that's a very map-reducible type problem.

+ +

So let's assume that you can infinitely scale up compute on-demand; how much would it cost in dollars to break this password? And I feel like there's an answer. Like, I want that number to be like a million dollars. But as EC2 costs go down over time, I want to hold that line. I want to be like, a million dollars is the line that we want to have. And so, as EC2 prices go down, we need to increase our bcrypt cost factor over time to adjust for that and maintain the million dollar per password cracking sort of high bar. That's the dream.

+ +

Swapping out the cost factor is actually really difficult. I've looked into it, and you have to like double encrypt and do weird stuff. So for a bunch of reasons, I haven't done this, but I just like that idea. Let's pin this to $1 value. And then, from there, decisions naturally flow out of it. But it's so much more of a real thing. A million dollars, I know what that means; 12, I don't know what 12 means.

+ +

STEPH: A million-dollar password, I like it. I feel like --

+ +

CHRIS: We named the episode.

+ +

STEPH: I was going to say that's a perfect title, A Million-Dollar Password. [laughs]

+ +

CHRIS: A Million-Dollar Password. But with that wonderful episode naming cap there, I think I'm done rambling about passwords. What's up in your world, Steph?

+ +

STEPH: One of the things that I've been chatting with folks lately is RailsConf is coming up; it's May 17 through the 19th. And it's been sort of like that casual conversation of like, "Hey, are you going? Are you going? Who's going? It's going to be great." And as people have asked like, "Are you going?" And I'm always like, "No, I'm not going." But then I popped on to the RailsConf website today because I was just curious. I wanted to see the schedule and the talks that are being given.

+ +

And I keep forgetting that there's the in-person version, but there's also the home edition. And I was like, oh, I could go, I could do this. [laughs] And I just forget that that is something that is just more common now for conferences where you can attend them virtually, and that is just really neat. So I started looking a little more closely at the talks. And I'm really excited because we have a number of thoughtboters that are giving a talk at RailsConf this year.

+ +

So there's a talk being given by Fernando Perales that's called Open the Gate a Little: Strategies to Protect and Share Data. There's also a talk being given by Joël Quenneville: Your Test Suite is Making Too Many Database Calls. I'm very excited; just that one is near and dear to my heart, given the current client experiences that I'm having. And then there's another one from someone who just joined thoughtbot, Christopher "Aji" Slater, Your TDD Treasure Map.

+ +

So we'll be sure to include a link to those for anyone that's curious. But it's a stellar lineup. I mean, I'm always impressed with RailsConf talks. But this one, in particular, has me very excited. Do you have any plans for RailsConf? Do you typically wait for them to come out later and then watch them, or what's your MO?

+ +

CHRIS: Historically, I've tended to watch the conference recordings after the fact. I went one year. I actually met Christopher "Aji" Slater at that very RailsConf that I went to, and I believe Joël Quenneville was speaking at that one. So lots of everything old is new again. But yeah, I think I'll probably catch it after the fact in this case.

+ +

I'd love to go back in person at some point because I really do like the in-person thing. I'm thrilled that there is the remote option as well. But for me personally, the hallway track and hanging out and meeting folks is a very exciting part. So that's probably the mode that I would go with in the future. But I think, for now, I'm probably just going to watch some talks as they come out.

+ +

STEPH: Yeah, that's typically what I've done in the past, too, is I kind of wait for things to come out, and then I go through and make a list of the ones that I want to watch, and then, you know, I can make popcorn at home. It's delightful. I can just get cozy and have an evening of RailsConf talks. That's what normal people do on Friday nights, right? That's totally normal. [laughs]

+ +

CHRIS: I mean, yeah, maybe not the popcorn part.

+ +

STEPH: No popcorn?

+ +

CHRIS: But not that I'm opposed to popcorn just —-

+ +

STEPH: Brussels sprouts? What do you need? [laughs]

+ +

CHRIS: Yeah, Brussels sprouts, that's what it is. Just sitting there eating handfuls of Brussels sprouts watching Ruby conference talks.

+ +

STEPH: [laughs]

+ +

CHRIS: I do love Brussels sprouts, just to throw it out there. I don't want it to be out in the ether that I don't like them. I got an air fryer, and so I can air fry Brussels sprouts. And they're delicious. I mean, I like them regardless. But that is a really fantastic way to cook them at home. So I'm a big fan.

+ +

STEPH: All right, I'm moving you into the category of fancy friends, fancy friends with an air fryer.

+ +

CHRIS: I wasn't already in your category of fancy friends?

+ +

STEPH: [laughs] I didn't think you'd take it that way. I'm sorry to break it to you.

+ +

[laughter]

+ +

CHRIS: I'm actually a little hurt that I'm now in the category of fancy friends. It makes a lot of sense that I wasn't there before. So I'll just deal with...yeah, it's fine. I'm fine.

+ +

STEPH: It's a weird rubric that I'm running over here. Pivoting away quickly, so I don't have to explain the categorization for fancy friends, I saw something in the Ruby Weekly Newsletter that had just come out. And it's one of those that I see surface every so often, and I feel like it's a nice reminder because I know it's something that even I tend to forget. And so I thought it'd be fun just to resurface it here. And then, we can also provide a link to the wonderful blog post that's written by Benito Serna.

+ +

And it's the difference between count, length, and size and an association with ActiveRecord. So for folks that would love a refresher, so count, that's a method that's always going to perform a SQL count query. So even if the collection has already been loaded, then calling count is always going to execute a database query. So this is the one that's just like, watch out, avoid it. You're always going to hit your database when you use this one.

+ +

And then next is length. And so, length loads the whole collection into memory and then returns that length to the number of items in that collection. If the collection has been loaded, then it's not going to issue a database call. And then it's just still going to use...it's going to delegate to that Ruby length method and let you know how many records are in that collection. So that one is a little bit better because then that way, if it's already loaded, at least you're not going to have a database call.

+ +

And then next is the size method, which is just the one that's more highly recommended that you use because this one does have a nice safety net that is built-in because first, it's going to check if we need to perform a database call, if the records have been loaded or not. So if the collection has not been loaded, so we haven't executed a database query and stored the result, then size is going to perform a database query. Specifically, it's using that SQL count under the hood. And if the collection has been loaded, then a database call is not issued, and then going to use the Ruby length method to then return the number of records.

+ +

So it just helps you prevent unnecessary database calls. And it's the reason that that one is recommended over using count, which is going to always issue a call. And then also to avoid length where you can because it's going to load the whole collection into memory, and we want to avoid that. So it was a nice refresher. I'll be sure to include a link in the show notes.

+ +

But yeah, I find that I myself often forget about the difference in count and size. And so if I'm just in the console and I just want to know something, that I still reach for count. It is still a default for mine. But then, if I'm writing production code, then I will be more considered as to which one I'm using.

+ +

CHRIS: I feel like this is one of those that I've struggled to lock into my head, but as you're describing it right now, I think I've got, again, another mnemonic device that we can lock on to. So I know that SQL uses the keyword count, so count that's SQL definitely. Length I know that because I use that on other stuff. And so it's size that is different and therefore special. That all seems good. Cool, locking that in my brain along with Fn-Delete. I have two things that are now firmly locked in.

+ +

So you were just mentioning being in the console and working with this. And one of the things that I've noticed a lot with folks that are newer to ActiveRecord and the idea of relations and the fact that they're lazy, is that that concept is very hard to grasp when working in a console because at the console, they don't seem lazy.

+ +

The minute you type out user.where some clause, and the minute you type that and hit enter in the console, Ruby is going to do its normal thing, which is like, okay, cool, I want to...I forget what it is that IRB or any of the REPLs are going to do, but it's either inspect or to_s or something like that. But it's looking for a representation that it can display in the console. And ActiveRecord relations will typically say like, "Oh, cool, you need the records now because you want to show it like an array because that's what inspect is doing under the hood."

+ +

So at the console, it looks like ActiveRecord is eager and will evaluate the query the minute you type it, but that's not true. And this is a critical thing that if you can think about it in that way and the fact that ActiveRecord relations are lazy and then take advantage of it, you can chain queries, you can build them up, you can break that apart. You can compose them together. There's really magical stuff that falls out of that.

+ +

But it's interesting because sort of like a Heisenberg where the minute you go to look at it in the REPL, it's like, oh, it is not lazy; it is eager. It evaluates it the minute I type the query. But that's not true; that's actually the REPL tricking you. I will often just throw a semicolon at the end of it because I'm like, I don't want to see all that noise. Just give me the relation. I want the relation, not the results of executing that query. So if you tack a semicolon at the end of the line, that tells Ruby not to print the thing, and then you're good to go from there.

+ +

STEPH: That's a great pro-tip. Yeah, I've forgotten about the semicolon. And I haven't been using that in my workflow as much. So I'm so glad you mentioned that. Yeah, I'm sure that's part of the thing that's added to my confusion around this, too, or something that has just taken me a while to lock it in as to which approach I want to use for when I'm querying data or for when I need to get a particular count, or length, or size. And by using all three, I'm just confusing myself more. So I should really just stick to using size.

+ +

There's also a fabulous article by Nate Berkopec that's titled Three ActiveRecord Mistakes That Slow Down Rails Apps. And he does a fabulous job of also talking about the differences of when to use size and then some of the benefits of when you might use count. The short version is that you can use count if you truly don't care about using any of those records. Like, you're not going to do anything with them. You don't need to load them, like; you truly just want to get a count. Then sure, because then you're issuing a database query, but then you're not going to then, in a view, very soon issue another database query to collect those records again. So he has some really great examples, and I'll be sure to include a link to his article as well.

+ +

Speaking of Ruby tidbits and kind of how this particular article about count, length, and size came across my view earlier today, Ruby Weekly is a wonderful newsletter. And I feel like I don't know if I've given them a shout-out. They do a wonderful job. So if you haven't yet checked out Ruby Weekly, I highly recommend it.

+ +

There are just always really great, interesting articles either about stuff that's a little bit more like cutting edge or things that are being released with newer versions, or they might be just really helpful tips around something that someone learned, like the difference between count, length, and size, and I really enjoy it. So I'll also be sure to include a link in the show notes for anyone that wants to check that out.

+ +

They also do something that I really appreciate where when you go to their website, you have the option to subscribe, but I am terrible about subscribing to stuff. So you can still click and check out the latest issue, which I really appreciate because then, that way, I don't feel obligated to subscribe, but I can still see the content.

+ +

CHRIS: Oh yeah. Ruby Weekly is fantastic. In fact, I think Peter Cooper is the person behind it, or Cooperpress as the company goes. And there is a whole slew of newsletters that they produce. So there's JavaScript Weekly, there's Ruby Weekly, there's Node Weekly, Golang Weekly, React Status, Postgres Weekly. There's a whole bunch of them. They're all equally fantastic, the same level of curation and intentional content and all those wonderful things. So I'm a big fan. I'm subscribed to a handful of them.

+ +

And just because I can't go an episode without mentioning inbox zero, if you are the sort of person that likes to defend the pristine nature of your email inbox, I highly recommend Feedbin and their ability to set up a special email address that you can use to then turn it into an RSS feed because that's magical. Actually, these ones might already have an RSS feed under the hood. But yeah, RSS is still alive. It's still out there. I love it. It's great. And that ends my thoughts on that matter.

+ +

STEPH: I have what I feel is a developer confession. I don't think I really appreciate RSS feeds. I know they're out there in the ether, and people love them. And I just have no emotion, no opinion attached to them. So one day, I think I need to enjoy the enrichment that is RSS feeds, or maybe I'll hate it. Who knows? I'm reserving judgment. Either way, I don't think I will. [laughs] But I don't want to box future Stephanie in.

+ +

CHRIS: Gotta maintain that freedom.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+f-98uVlQ + + ]]> + + Chris Toomey + Steph Viccari + + + 335: Start Messy + https://bikeshed.thoughtbot.com/335 + ef7dbcf6-9c96-4a1e-953c-3cefd1584693 + Tue, 26 Apr 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph has a question for Chris: When you have no idea how you're going to implement a feature, how do you write your first test? + +Chris has thoughts about hybrid teams (remote/in-person) and masked inputs. + 35:38 + no + + + Steph has a question for Chris: When you have no idea how you're going to implement a feature, how do you write your first test? +Chris has thoughts about hybrid teams (remote/in-person) and masked inputs. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Preemptive Pluralization is (Probably) Not Evil (https://www.swyx.io/preemptive-pluralization) +iMask (https://imask.js.org/) +Mitch Hedberg - Escalator Joke (https://www.youtube.com/watch?v=yHopAo_Ohy0) +This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: I am recording in a new room because we're in Pennsylvania, and so I'm recording at this little vanity desk which is something. [laughs] But there's a mirror right in front of me, so I feel very vain because it's just like, [laughs] I'm just looking at myself while I'm recording with you. It's something. +CHRIS: [laughs] That is something. +STEPH: [laughs] So, you know. +CHRIS: Fun times. +STEPH: Pro podcast tip, you know, just stare at yourself while you chat, while you record. +CHRIS: I mean, if that works for you, you know, plenty of people in the gym have the mirrors up, so podcasting is like exercising in a way, and I think it makes sense. +STEPH: I appreciate the generosity. [laughs] +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. So I have a funny/emotional story that [laughs] I'm going to share with you first because I feel like it kind of encapsulates how life is going at the moment. So we've officially moved from South Carolina to North Carolina. I feel like I've been talking about that for several episodes now. But this is it: we have finally vacated all of our stuff out of South Carolina house and relocated to North Carolina. And once we got to North Carolina, we immediately had to then leave town for a couple of days. +And normally, Utah, our dog, stays with an individual in South Carolina, someone that we found, trust, and love. And he has a great time, and I just know he's happy. But we didn't have that this time. So I had to find just a boarding facility that had really high reviews that I felt like I could trust him with. I didn't even have time to take him for a day to test it out. It was one of those like, I got to show up and just drop him off and hope this goes well, so I did. +And everything looks wonderful. Like, the facility is very clean. I had a list of things to look for to make sure it was a good place. But it's the first time leaving him somewhere where he's going to spend significant time in a kennel that has indoor-outdoor access. And as I walked away from him, I started to cry. And I just thought, oh no, this is embarrassing. I'm that dog mom who's going to start crying in this boarding facility as she's leaving her dog for the first time. So I put on my shades, and I managed to make it through the checkout process. +But then I went to my truck and just sat there and cried for 15 minutes and called my husband and was like, "I'm doing the right thing, right? Like, tell me this is okay because I'm having a moment." And I finally got through that moment. But then I even called you because you and I were scheduled to chat. And I was like, I am not in a place that I can chat right now. I think I told you when you answered the phone. I was like, "Everything is fine, but I sound like the world's ending, or I sound like a mess." [laughs] +And yeah, so I had like two hours of where I just couldn't stop crying. I partially blame pregnancy hormones. I'm going to go with that as my escape rope for now. So I feel like that's been life lately. Life's been a little overwhelming, and that felt like the cherry on top. And that was the moment that I broke. Update: he's doing great. I've gotten pictures of Utah. He's having a wonderful time at camp, it seems. [laughs] It was just me, his mom, who is having trouble. +CHRIS: Well, you know, reasonable to worry, and life's dialed up to 11 and all of that. But yeah, I will say even though you lead the conversation with everything's fine, your tone of voice did not imply that everything was fine. So when I eventually came to understand what we were talking about, I hope I was kind in the moment. But I was like, oh, okay, this is fine. We're fine. I'm so sorry you're feeling terrible right now. +STEPH: [laughs] +CHRIS: But okay, we're fine. For me, there was a palpable moment of like, okay, my stress is now back down a little bit. But I'm glad that things are going well and that Utah is having a fun vacation. +STEPH: Yep, he seems to be doing fine. I've calmed down. You know, as you said, life's been dialed up lately. On a less emotional note and something that's a little bit more technical, I had a really great conversation with another thoughtboter where we were talking about testing. And the idea of when you learn testing, it's often very focused on like, you have this object, and it has a method. And so, you're going to write a unit test for this particular method. And it's very isolated, very specific as to the thing that you're looking to test. +Versus in reality, when you pick up tickets, you don't have that scope, and like, it is so broad. You have to figure out what feature you're implementing, figure out how to test it. And it feels like this mismatch between how a lot of people learn to test and learn TDD versus then how we actually practice it in the wild. +And so we had a phone conversation around when you are presented with a ticket like that, and you have no idea how you're going to implement a feature, how do you get started with testing, and when do you write your first test? Do you TDD? Do you BDD? Or do you PDD? That last one I made up, it stands for Panic-driven development. But it's what's your approach to how do you actually then get to the point where you can write a test? And I have a couple of thoughts. But I'm really curious, how does that flow work for you? What have you learned throughout the years to then help yourself write that first test? Or where do you start? +CHRIS: Well, this is an interesting question. I like this one. I think it varies. And I think there's a lot of dogma around TDD as a practice. And I think it is super useful to break that apart and hear different individual stories of it. I know there are plenty of folks who are like, TDD is just not a thing and whatnot, and I'm certainly not in that camp. But I also don't TDD 100% of the time because sometimes I'm not super clear on what I'm doing, or I'm in more of an exploratory phase. +That said, I think there's a...I want to answer the question somewhat indirectly, which is I know how to test most of the code that I work on now as a web developer in a Rails application because I've done most of the things a bunch of times. And the specifics may be different, but the like, to integrate with this external system, and I have to build an API client or whatever, I know how to do that. +And there is a public API of some class that I will be exercising against and so I can write tests against that. Or I know that the user is going to click a button, and then something needs to happen. And so I can write that test, and it fails, and then it starts to push me towards the implementation. There are also times where it's actually quite hard to get the test to lead you in the right direction, and you have to know what hop to make, and so sometimes I just do that. +But yeah, rolling back a little bit, I think there is a certain amount of experience that is necessary. And I think one of the critical things that I want to share with folks that are potentially newer to testing overall is that it is actually quite hard. You have to understand your system and how you're going to approach it, you know, one step removed, or it's like a game of chess where you're thinking a couple of moves ahead. You have to understand it in a deeper way. +And so, if testing is difficult, that might just be totally reasonable at this point. And as you come to see the patterns within a Rails application or whatever type of application you're working on over and over, it becomes easier to test. But if testing is hard, that may not mean...like, how do I phrase this? There's like an impostor syndrome story in here of like, if you're struggling with testing, it may not be that something is fundamentally broken. You just may need a couple more chances to see that sort of thing play out. +And so, for me, in most cases, I tend to know where to start or when not to. Like, I feel fine not testing when I don't test most of the time. I will eventually get things under test coverage such that I feel confident in that. And whenever I have one of those moments, I will stop and look at it and say, "Why didn't I know how to test this from the front, like, from the start?" +But it's rare at this point for things to be truly exploratory. There's always some outer layer that I can wrap around. But like, I know X needs to happen when Y occurs. So how do I instrument the system in that way? But yeah, those are some thoughts. What are your thoughts? Does what I said sound reasonable here? +STEPH: Yeah, I really like how you highlighted that pausing for reflection. That was something that I didn't initially think of, but I really liked that, to then go back to be like, okay, revisiting myself a couple of days or however earlier when I first started this. Now I can see where I've ended up. How could I have made that connection sooner as to where I was versus the tests I ended up with? Or perhaps recognizing that I couldn't have gotten there sooner, that I needed that journey to help me get there. So I really like the idea of pausing for reflection because then it helps cement any of those learnings that you have made during that time. +Also, the other part where you mentioned the user clicks a button, and something happens, that's where I immediately went with this. I also liked that you highlighted that TDD has that bit of dogma, and I don't always TDD. I do what I can, and it helps me. But it has to be a tool versus something that I just do 100% of the time. But with more of that BDD approach or that very high-level user-level integration test of where if I need to pull data from an API and then show it to the user, okay, I know I can at least start with a high-level test of I want the user to then see some data on a page. +And that will lead me down some path of errors. It might help me implement a route and a controller and then a show action, so it will at least help me get started. Or even if it doesn't give me helpful enough errors, it at least serves as my guideline of like, this is my North Star. This is where I'm headed. So then, if I need to revisit, okay, what's the thing that I'm focused on at the moment? I can go back and be like, okay, I'm focused on achieving this. What's the next smallest step I can take to get there? +The other thing that I've learned over time is I've given myself the chance to be messy because I got so excited about the idea of unit testing and writing small, fast test that I would often try to start with small objects and then work my way backwards into like, okay, I have this one object that does this thing and one object that like...let's use a concrete example. So one object that knows how to communicate with API and one object that knows how to then parse and format the data I want and then something else that's then going to present that data to the user. +But I found when I started with small objects, I would get a little lost, and I wasn't always great at bringing them together. So I've taken the opposite approach of where if I'm really not sure where I'm headed and I'm in that more exploratory phase or even just that first initial parse of a feature, I will just start messy. So if I am pulling data from an API and need to show it to a user on a screen, I'll just dump it in the controller if I need to. I'll put it all there together. +And then once I actually have something that is parsing, or I have something appearing on the page, then I will start to say, "Okay, now that I can see what I need and I can see the pieces that I've written, how can I then start to extract this into smaller objects?” And now, I can start writing unit tests for that data. So that is something that has helped me is just start high, keep it high, be messy, and until you start to see some of the smaller objects that you can pull out. +CHRIS: Yeah, I think there's something that you were just saying there that clicked for me of we didn't start with the why of TDD. And I don't think we've talked about why we believe in TDD in a while. So this feels like a thing we're saying. It's not good just because it's good, or we don't believe it's good just because that's what we say. For me, it is because it anchors us outside of the code sort of it starts to think of it from the user perspective or some outer layer. +So even if you're unit testing some deeply nested class within your application, there's still an outer layer. There's still a user of that class. And so, thinking about the public API, I think is really useful. And then the further out you get, the better that is, and I believe strongly in thinking from the outside in on these sort of things. +And then the other thing you said of allowing for refactoring. And if we have tests, then it's so much easier to sort of...I totally 100% agree with like; I start messy. I start very messy. I wanted to pretend that I was going to be like, oh, I'm so...Steph, I can't believe this. But no, of course, I start messy. +Why would you start trying to do the hard thing first? No, get something that works. But then having the test coverage around that makes it so much easier to go through those sequential refactoring steps. Versus if you have to write the code correctly upfront and then add test coverage around that, it sort of inverts that whole thing. +And so, although it may take a little bit longer to write the tests upfront, I do exactly what you're describing of like, I write the tests that tell some truth about the system and constrain the system to do that thing. And then I can have a messy implementation that I can iteratively refactor over and over, and I can extract things from. And then, I can tell a more concise testing story about those. And so it really is both the higher-level perspective I think is super useful and then the ability to refactor under that test coverage is also very useful. And it makes my job easier because I can start messy. I love starting messy. It's so much better. +STEPH: Yeah, and I think former me had the idea that for me to do TDD properly meant that I had these small, encapsulated objects that I wrote unit tests for. And yes, that is the goal. I do want that, but that doesn't mean I have to start there. That is something that then I can work my way towards. +That also falls in line with the adage from Sandi Metz that the wrong abstraction is more costly than no abstraction. And so I'd rather start with no abstractions and then start to consider, okay, how can I actually move this out into smaller objects and then test it from there? +There's also something that I heard that I haven't done as often, but I really liked the idea; it feels very freeing, is that when you do get started and if you write your first test, if you write a test and it helps you make some progress but then you come back to it later and you're like, you know, the test doesn't really add value, or it's not helping me anymore, just thank it and delete it and move on. Just because you wrote it doesn't mean it needs to stay. +So if it provided some benefit to you and helped you through that journey of adding the feature, then that's wonderful. But don't be timid about deleting it or changing it so that it does serve you because otherwise, it's just going to be this toxic test that gets merged into the main branch, and it's going to be untrustworthy. Or maybe it's fussy and hard to please, or it's just really not the supportive test that you're looking for. And so then you can turn it into more of a supportive test and make it fit your goals instead of just clinging to every test that we've written. +CHRIS: I like the framing of tests as scaffolding to help you build up the structure. But then, at the end, some of the scaffolding gets ripped away and thrown out. And I do think, again, testing ends up in this weird place. The dogmatic thing that we were talking about earlier feels very true. And I've noticed, particularly on larger teams, folks being very hesitant to delete tests like, that feels like sacrilege. Of course, you can't delete tests; the tests are how we know it's true, which is true, but you can interrogate that. You can see like, how true is it? +And every test has a cost and maintenance burden, runtime, et cetera. You probably know well, Steph, about having test suites that take a bunch of time to run and then maybe wanting to spend a little bit of time trying to reduce that overall time. And so there's always going to be a trade-off there. +Actually, someone reminded me of an anecdote recently. I joined a project, and most of the test suite or all of the test suite was commented out because it was flaky or intermittent. And I was like, "Oh, I'm going to delete that." And people were like, "You're what?" I'm like; it's commented out. We're not using it. Let's tell the truth. Git will have it. We can go back and get it. But let's tell the truth with what we're like...this commented-out test suite is almost worse in my mind than having nothing there. The nothing feels painful, right? Let's experience that. +Whereas the commented out stuff is like, well, we have a test suite; it's just commented out. It's like, no, you don't have a test suite at all. That's not what's going on here. But there were other thoughtboters on the project that poked a good amount of fun at me when they were like, "The first thing you did on this project was delete the test suite?" As I was like, "Yeah, I don't know, I was feeling spicy that day or something." +But I think the test suite needs to serve the work that we're doing in the same way that everything else does. And so occasionally, yeah, deleting tests is absolutely the right thing and then probably add back some more. +STEPH: It's funny how that reaction exists. And I've done it before myself where like, if you see commented out code and you put up a PR to remove it, I feel like most people are going to be like, yeah, yeah, that's great. Let's get rid of this. It's clearly not news. It's commented out. But then removing a skipped test then has people like, "Well, but that test looks like it could be valuable, and we're going to fix it." +And it's like...all I can go back to is that silly example of like, you've got your skinny jeans, one day I'm going to fit into those skinny jeans. And so one day, I'm going to fix this test, and it's going to serve the purpose. And it's going to be the me I want to be. [laughs] And it is funny how we do that. With code, we're like, sure, we can get rid of it. But with tests, we feel this clinginess to them where we want to hold on to it and make it pass. And I think that sometimes has to do with the descriptions. +There are test descriptions commented out that I've seen are like, user can log in, or if given a user without permission, they can't access. And it's like, oh, that sounds important. I'm now nervous to delete you versus fix you, but you're still not actually running and providing value. And so then I have to negotiate with myself as to where do we actually go from here? But I do love the idea of deleting tests that are skipped because we should just let them go. We either have to dedicate time to fix them or let them go and make that hard decision. +CHRIS: The critical idea of future me will have more time, future me will be calm and will work through all the other bugs and future discounting; as far as I understand it as a formalization of the term, yeah, it's never true. I've only gotten busier over time, just broadly speaking. +And that seems to be a truism in software projects as well. It's like, oh, we just have to write a bunch of features, and then it'll be calm. I don't even think I'd want that. But future me will not have more time. And so choosing the things that we do invest in versus not is tricky, but the idea of that future me will have a lot of time or future us probably not true. +STEPH: Well, I think the story that I just shared at the beginning of our chat highlights that future me won't always be calm. [laughs] So let's work with what I've got. Let's not bank on that. Future Stephanie might be very emotional about dropping her dog off at boarding for a couple of days. [laughs] Future me might be very emotional about fixing this test. All right, well, thanks for going on that journey with me. That's really helpful. I knew you'd have some great insights there. +Mid-roll Ad: +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: What's going on in my world? Last week we had our first ever Sagewell all-hands get-together in person. Many of us have met in person before, but not everyone. And so this was a combination celebration for our seed fundraising round, which had happened actually sometime right at the end of last year. But due to COVID in the world and complexity, it was difficult to get everybody together. So that finally happened. And then we sort of grafted on to that celebration, that party that we were having. Like, let's just extend a day in either direction and do some in-person working and all of that. And that was really great. +I'm trying to find that ideal middle ground between we are a remote team, but there is definitely value in occasionally being in person, particularly getting to know people but also just having some higher bandwidth conversations, planning, things like that. They just feel different in person. And so, how do we balance that? And how do we be most productive and all that? +But it was really great to meet the team more so than I had on the internet and get to spend some time in person and do some whiteboarding. I drew on a whiteboard with a team. We were all looking at the same whiteboard. We're in the same room. And I drew on a whiteboard some entity relationship diagrams. It was awesome. [laughs] It was super fun. It was one of those cases where we had built an assumption deeply into our codebase, and suddenly instead of having one of a thing, we may now have multiple of a thing. +There's a wonderful blog post by Shawn Wang called Preemptive Pluralization which I think is based on an episode of Ben Orenstein's podcast, The Art of Product, where Ben basically framed the idea of like, I've never regretted pluralizing something earlier. A user has one account; they have multiple accounts. They just happen to have one at this time, et cetera. So we're in one of those. +And it was a great thing to be able to be in a room and whiteboard. I knew at the time when I did it way back when that I was making the wrong decision. But I didn't know exactly how and the shape. And so now we have to do that fun refactoring so glad that we have a giant test suite that will help us with said refactoring. But yeah, so that was really great to be able to do in person. +STEPH: I think there can be so much value in getting together and getting to see your team and, like you said, have those high-level conversations and then just also getting to hang out. So it's really nice to hear that reinforced since you experienced that same positivity from that experience. Do you think that's something that y'all will have going forward? Do you think you're going to try to get together like once a year, once a quarter? Maybe it hasn't even been talked about. But I'm hearing that it was great and that maybe there will be some repeats. +CHRIS: Yes, yeah. I think I'm inclined to quarterly at a minimum and maybe even slightly more than that. Some of us are centered around Boston, and so it's a little bit easier for us to pop in and work at a WeWork, that sort of thing. But I think broadly, getting the team together and having that be intentional. And personally, I'm inclined to that being more social time than productive time because I think that's the thing that is most useful in person is building relationship and rapport and understanding folks better. +I remember so pointedly when thoughtbot would have the annual Summer Summit, and leading up to that; there was a certain amount of conversation. But there were also location-specific rooms, and a lot of the conversation happened like in the Boston channel or whatnot. And then, without fail, every year after the Summer Summit, suddenly, there was a spike in cross-team chatter. Like, the Ruby room now had a bunch of people from San Francisco talking to Boston, talking to New York, et cetera. And it was just this incredibly clear...I think we could actually, like, I think at one point someone plotted the data, and there's just this stepwise jump that would happen every time. +And so that sort of connecting folks is really what I believe in there. And the more we're leaning into the remote thing, then the more I think this is important. So I think quarterly is probably the lowest end that I would think of, but it might be more. And it's also a question of like, what shape does this take? Is it just us going and hanging out somewhere? Or are we productively trying to get together with a whiteboard? I think we'll figure that out as we go on. But it's definitely something that I'm glad we've done now, set the precedent for, and we'll hopefully do more of moving on. +STEPH: Yeah, I always really love the thoughtbot Summits. In fact, we have one coming up. It's coming up in May, and this one's taking place in UK. But there have been some interesting conversations around Summit because before, it was the idea that everybody traveled. But typically, they were in Boston, so for me, it was particularly easy because it was already where I lived. So then showing up for Summit was no biggie. +But with this one happening in UK and COVID and travel still being a concern, there's been more conversations around; okay, this is awesome. People who want to get together can. There are these events going on. But there are people who don't want to travel, don't feel up to travel. They have family obligations that then make it very difficult for them to leave one partner at home with the kids. And I myself I'm in that space where I thought really hard about whether I was going to travel or not. And I've decided not to just for personal reasons. +But then it brings up the question of okay, well, if we have a number of people that are going to be in person together, then what about the people who are remote? And the idea of running something that's hybrid is not something that we've really figured out. But those that are remote, we're going to get together and figure out what we want to do and maybe what's our version of our remote summit since we're not going to be traveling. +But I feel like that's definitely a direction that needs to be considered as teams are getting in person because if you do have people that can't make it, how can you still bring them in so it's an inclusive event but respect to the fact that they can't necessarily travel? I don't know if that's a concern that every team needs to have, but it's one that I've been thinking about with our team. And then I know others at thoughtbot we've been considering just because we do have such a disparate team. And we want to make everybody comfortable and feel included. +CHRIS: Yeah, as with everything in this world, there's always complexities and subtlety. Thankfully, for our first get-together, we were able to get everyone into the same space. But I do wonder, especially as the team grows, even just scheduling, the logistics of it become really complicated. +So then does the engineering team have get-togethers that are slightly different, and then there's like once yearly a big get-together of the whole team? Or how do you manage that and dealing with family situations and all that? It is very much a complicated thing that thankfully was very straightforward for us this first time, but I fully expect that we'll have to be all the more intentional with it moving forward. And, you know, that's just the game. +But switching gears ever so slightly, we did have a fun thing that we've worked on a little bit over the past few weeks. We've finally landed it in the app. But we were swapping out our masked input library that we were using, so this is for someone entering their birthday, or a phone number, or social security number, or dates. I guess I already said dates. Passwords I think we also use here. But we have a bunch of different inputs in the app that behave specially. +And my goodness, is this one of those things that falls into the category of, oh yeah, I assume this is a solved problem, right? We just have a library out there that does it. And each library is like, oh no, all of the other libraries are bad. I will come along, and I will write the one library to solve all of the problems, and then we'll be good. And it is just such a surprisingly complicated space. It feels like it should be more straightforward. +And as I think about it, it's not; it's dealing with imperative interactions between a user and this input. And you need to transform it from what happens when you hit the delete key? What do you want to happen? What's the most discoverable for every user? How do we make sure they're accessible? But my goodness, was it complicated. I think we're happy with where we landed, but it was an adventure. +STEPH: I'll be honest, that's something that I haven't given as much thought to. But I guess that's also I just haven't worked with that lately in terms of a particular library that then masks those inputs. So I'm curious, which library were using before, and then which one did you switch to? +CHRIS: That's a critical piece of information that I have left off here. So for the previous one, we were using one called svelte-input-mask, which, again, part of the fun here is you want to have bindings into whatever framework that you're using. So svelte-input-mask is what we were using before. We have now moved on to using iMask, which is not like the thing you wear on your face, but it is the letter I so like igloo, Mike, et cetera, I-M-A-S-K, iMask. +And so that is a lower-level library. There are bindings to other things. But for TypeScript and other reasons, we ended up implementing our own bindings in Svelte, which was actually relatively straightforward. Again, big fan of Svelte; it's a wonderful little framework. But that is what we're using now, and it is excellent. It's got a lot of features. We ended up using it in a slightly more simple version or implementation. It's got a lot of bells and whistles and configurations. We went up the middle with it. But yeah, we're on iMask, which also led to a very entertaining moment where it was interacting with our test suite in an interesting way. +And so, one of the developers on the team searched for Capybara iMask. [laughs] And I forget exactly how it happened, but if you Google search that, for some reason, the internet thinks an iMask is a thing that goes over your mouth. And so it's a Capybara, like the animal, facemask. It's very confusing, but this got dropped into our Slack at one point, someone being like, "I searched for Capybara iMask, and it got weird, everybody." So yeah, that was a fun, little side quest that we got to go on. +STEPH: [laughs] I just Googled it as you told me to, and it's adorable. Yeah, it's a face mask, and it has a little capybara cartoon on the front of it. Yeah, there are many of these. [laughs] +CHRIS: When I think of an iMask, though, it's the thing that you put over your eyes to block the light if you want to sleep. But they're like, an iMask like, a mask that still keeps her eyes outside of it. I don't understand the internet. It's a weird place. +STEPH: I think that was just Google saying Capybara iMask. Nope, don't know I, so let's put together Capybara mask, and that's what you got back. [laughs] +CHRIS: I guess, yeah. It's just a Capybara mask. And I'm projecting the ‘I’ because I phonetically heard that for a while. Anyway, yes. But yeah, masked inputs so complicated. +STEPH: This is adorable. I feel like there should be swag for when people move. Like when people find things like this, this is the type of thing that then I stash and then wait for their anniversary at the company, and then I send it to them to remind them of this time that we had together. [laughs] +There was also a moment where you said, ‘I.’ You were explaining I as in in the letter I, not E-Y-E for eyemask. And you said igloo, and my brain definitely short-circuited for a minute to be like, did he just say igloo? Why did he say igloo? And it took me a minute to, oh, he's helping phonetically say that this is for the letter I. +CHRIS: Yep. The NATO phonetic alphabet that if you don't explain that that's what you're doing, now I'm just naming random other objects in the world. Sorry. +STEPH: [laughs] +CHRIS: And that's why I cut myself off halfway through. I'm like, now you're just naming stuff. This isn't helping. +STEPH: [laughs] +CHRIS: Yes, the letter I, the letter M. [laughs] +STEPH: All of that was a delightful journey for me, and I was curious. I'm glad you brought the test because I was curious if y'all are testing if things are getting obscured, but it sounds like y'all are, which is what helped give you confidence as you were switching over to the new library. +CHRIS: Yeah, although to name it, we're not testing at a terribly low level. This is a great example of where I believe in feature specs. Like, within our Capybara feature spec, we are saying, and then as a user, I type in this value into the input. And critically, although this input needs to have special formatting and presentational behavior, it should functionally be identical. And so it was a very good litmus test of does this just work? +And then, actually, our feature specs ended up in a race condition, which is just an annoying situation where Capybara moves so quickly that it represented a user. But as we were having that conversation, I was like, wait a minute; I know that users are slower than a computer. But is this actually an edge case that's real that we need to think about? And I think we did end up slightly changing our implementation. So our feature specs did, in a way, highlight that. +But mostly, our feature specs did not need to change to adapt to and then fill in the formatted input. It was just fill in the input with the value. And that did not change at all, but it did put a tiny bit of pressure on our implementation to say, oh, there is a weird, tiny, little race condition here. Let's fix that. And so we did race conditions, no fun at all. +STEPH: Interesting. Okay, so y'all aren't actually testing. Like, there's no test that says, "Hey, that when someone types into this field, that then there should be this different UI that's present because then we are obscuring the text that they're putting into this field." It was, as you mentioned, we're just testing that we changed over libraries, and everything still works. So then do you just go through that manual test of, then you go to staging, and then you test it that way? +CHRIS: Yeah, that's a great question, yes, although as you say it, it's interesting. I guess there's a failure mode here or that our test suite does not enforce that the formatting masking behavior is happening. But it does test that the value goes through this input, gets submitted to the server, turns into the right type of value in the back end, all of that. And so I guess this is an example of how I think about testing, like, that's the critical bit, and then it's a nicety. It's an enhancement that we have this masking behavior. +But if that broke, as long as the actual flow of data is still working, that can't break in a way that a user can't use. It sort of reminds me of the Mitch Hedberg joke, an escalator can never break, and it can only become stairs. And so I'm in that mindset here where a masked input that you have proper feature spec coverage around can never quote, unquote, "break." It can just become a plain text input. +STEPH: I love how much that resonates with me. And I now know that when I'm writing tests, I'm going to think back to Mitch Hedberg and be like, oh, but is it broken-broken, or is it just now stairs? Because that's often how I will think of feature specs and how low level I will get with them. And this is on that boundary of like, yes, it's important that we want to obscure that data that someone's typing in, but it's not broken if it's not obscured. +So there's that balance of I don't really want to test it. Someone will alert us. Like if that breaks, someone will alert us, and it's not the end of the world. It's just unfortunate. But if they can't sign in or they can't actually submit the form, that's a big problem. So yes, I love this comparison now of is it actually broken, or is it just stairs? [laughs] As a guideline for, how much should we test at this feature level or test in general? What should we care about? +CHRIS: I feel like this is a deep truth that I believed for a long time. And I think I probably, somewhere in the back of my head, connected it to this joke. But I feel really good that I formally made that connection now because I feel like it helps me categorize this whole thing. Sorry for the convenience as a joke. And so yeah, that's where we're at. +STEPH: For anyone that's not familiar with the comedian Mitch Hedberg, we'll be sure to include a link to that particular joke because it's delightful. And now it's connected to tech, which makes it just even more delightful. +CHRIS: I only understand anything by analogy, especially humorous analogy. So this is just critical to my progression as a developer and technologist. +STEPH: Yeah, I've learned over the years that there are two ways that I retain knowledge: it either caused me pain, or it made me laugh. Otherwise, it's mundane, and it gets filtered out. Laughter is, of course, my favorite. I mean, pain sticks with me as well. But if it's something that made me laugh, I just know I'm far more likely to retain it, and it's going to stick with me. +Mid-Roll AD: +And now a quick break to hear from today's sponsor, Studio 3T. +When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines, Studio 3T makes it easy. +And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. +You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free. +CHRIS: On that wonderful framing there, I think we should wrap up. What do you think? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph has a question for Chris: When you have no idea how you're going to implement a feature, how do you write your first test?

+ +

Chris has thoughts about hybrid teams (remote/in-person) and masked inputs.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Preemptive Pluralization is (Probably) Not Evil
+iMask
+Mitch Hedberg - Escalator Joke

+ +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: I am recording in a new room because we're in Pennsylvania, and so I'm recording at this little vanity desk which is something. [laughs] But there's a mirror right in front of me, so I feel very vain because it's just like, [laughs] I'm just looking at myself while I'm recording with you. It's something.

+ +

CHRIS: [laughs] That is something.

+ +

STEPH: [laughs] So, you know.

+ +

CHRIS: Fun times.

+ +

STEPH: Pro podcast tip, you know, just stare at yourself while you chat, while you record.

+ +

CHRIS: I mean, if that works for you, you know, plenty of people in the gym have the mirrors up, so podcasting is like exercising in a way, and I think it makes sense.

+ +

STEPH: I appreciate the generosity. [laughs]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So I have a funny/emotional story that [laughs] I'm going to share with you first because I feel like it kind of encapsulates how life is going at the moment. So we've officially moved from South Carolina to North Carolina. I feel like I've been talking about that for several episodes now. But this is it: we have finally vacated all of our stuff out of South Carolina house and relocated to North Carolina. And once we got to North Carolina, we immediately had to then leave town for a couple of days.

+ +

And normally, Utah, our dog, stays with an individual in South Carolina, someone that we found, trust, and love. And he has a great time, and I just know he's happy. But we didn't have that this time. So I had to find just a boarding facility that had really high reviews that I felt like I could trust him with. I didn't even have time to take him for a day to test it out. It was one of those like, I got to show up and just drop him off and hope this goes well, so I did.

+ +

And everything looks wonderful. Like, the facility is very clean. I had a list of things to look for to make sure it was a good place. But it's the first time leaving him somewhere where he's going to spend significant time in a kennel that has indoor-outdoor access. And as I walked away from him, I started to cry. And I just thought, oh no, this is embarrassing. I'm that dog mom who's going to start crying in this boarding facility as she's leaving her dog for the first time. So I put on my shades, and I managed to make it through the checkout process.

+ +

But then I went to my truck and just sat there and cried for 15 minutes and called my husband and was like, "I'm doing the right thing, right? Like, tell me this is okay because I'm having a moment." And I finally got through that moment. But then I even called you because you and I were scheduled to chat. And I was like, I am not in a place that I can chat right now. I think I told you when you answered the phone. I was like, "Everything is fine, but I sound like the world's ending, or I sound like a mess." [laughs]

+ +

And yeah, so I had like two hours of where I just couldn't stop crying. I partially blame pregnancy hormones. I'm going to go with that as my escape rope for now. So I feel like that's been life lately. Life's been a little overwhelming, and that felt like the cherry on top. And that was the moment that I broke. Update: he's doing great. I've gotten pictures of Utah. He's having a wonderful time at camp, it seems. [laughs] It was just me, his mom, who is having trouble.

+ +

CHRIS: Well, you know, reasonable to worry, and life's dialed up to 11 and all of that. But yeah, I will say even though you lead the conversation with everything's fine, your tone of voice did not imply that everything was fine. So when I eventually came to understand what we were talking about, I hope I was kind in the moment. But I was like, oh, okay, this is fine. We're fine. I'm so sorry you're feeling terrible right now.

+ +

STEPH: [laughs]

+ +

CHRIS: But okay, we're fine. For me, there was a palpable moment of like, okay, my stress is now back down a little bit. But I'm glad that things are going well and that Utah is having a fun vacation.

+ +

STEPH: Yep, he seems to be doing fine. I've calmed down. You know, as you said, life's been dialed up lately. On a less emotional note and something that's a little bit more technical, I had a really great conversation with another thoughtboter where we were talking about testing. And the idea of when you learn testing, it's often very focused on like, you have this object, and it has a method. And so, you're going to write a unit test for this particular method. And it's very isolated, very specific as to the thing that you're looking to test.

+ +

Versus in reality, when you pick up tickets, you don't have that scope, and like, it is so broad. You have to figure out what feature you're implementing, figure out how to test it. And it feels like this mismatch between how a lot of people learn to test and learn TDD versus then how we actually practice it in the wild.

+ +

And so we had a phone conversation around when you are presented with a ticket like that, and you have no idea how you're going to implement a feature, how do you get started with testing, and when do you write your first test? Do you TDD? Do you BDD? Or do you PDD? That last one I made up, it stands for Panic-driven development. But it's what's your approach to how do you actually then get to the point where you can write a test? And I have a couple of thoughts. But I'm really curious, how does that flow work for you? What have you learned throughout the years to then help yourself write that first test? Or where do you start?

+ +

CHRIS: Well, this is an interesting question. I like this one. I think it varies. And I think there's a lot of dogma around TDD as a practice. And I think it is super useful to break that apart and hear different individual stories of it. I know there are plenty of folks who are like, TDD is just not a thing and whatnot, and I'm certainly not in that camp. But I also don't TDD 100% of the time because sometimes I'm not super clear on what I'm doing, or I'm in more of an exploratory phase.

+ +

That said, I think there's a...I want to answer the question somewhat indirectly, which is I know how to test most of the code that I work on now as a web developer in a Rails application because I've done most of the things a bunch of times. And the specifics may be different, but the like, to integrate with this external system, and I have to build an API client or whatever, I know how to do that.

+ +

And there is a public API of some class that I will be exercising against and so I can write tests against that. Or I know that the user is going to click a button, and then something needs to happen. And so I can write that test, and it fails, and then it starts to push me towards the implementation. There are also times where it's actually quite hard to get the test to lead you in the right direction, and you have to know what hop to make, and so sometimes I just do that.

+ +

But yeah, rolling back a little bit, I think there is a certain amount of experience that is necessary. And I think one of the critical things that I want to share with folks that are potentially newer to testing overall is that it is actually quite hard. You have to understand your system and how you're going to approach it, you know, one step removed, or it's like a game of chess where you're thinking a couple of moves ahead. You have to understand it in a deeper way.

+ +

And so, if testing is difficult, that might just be totally reasonable at this point. And as you come to see the patterns within a Rails application or whatever type of application you're working on over and over, it becomes easier to test. But if testing is hard, that may not mean...like, how do I phrase this? There's like an impostor syndrome story in here of like, if you're struggling with testing, it may not be that something is fundamentally broken. You just may need a couple more chances to see that sort of thing play out.

+ +

And so, for me, in most cases, I tend to know where to start or when not to. Like, I feel fine not testing when I don't test most of the time. I will eventually get things under test coverage such that I feel confident in that. And whenever I have one of those moments, I will stop and look at it and say, "Why didn't I know how to test this from the front, like, from the start?"

+ +

But it's rare at this point for things to be truly exploratory. There's always some outer layer that I can wrap around. But like, I know X needs to happen when Y occurs. So how do I instrument the system in that way? But yeah, those are some thoughts. What are your thoughts? Does what I said sound reasonable here?

+ +

STEPH: Yeah, I really like how you highlighted that pausing for reflection. That was something that I didn't initially think of, but I really liked that, to then go back to be like, okay, revisiting myself a couple of days or however earlier when I first started this. Now I can see where I've ended up. How could I have made that connection sooner as to where I was versus the tests I ended up with? Or perhaps recognizing that I couldn't have gotten there sooner, that I needed that journey to help me get there. So I really like the idea of pausing for reflection because then it helps cement any of those learnings that you have made during that time.

+ +

Also, the other part where you mentioned the user clicks a button, and something happens, that's where I immediately went with this. I also liked that you highlighted that TDD has that bit of dogma, and I don't always TDD. I do what I can, and it helps me. But it has to be a tool versus something that I just do 100% of the time. But with more of that BDD approach or that very high-level user-level integration test of where if I need to pull data from an API and then show it to the user, okay, I know I can at least start with a high-level test of I want the user to then see some data on a page.

+ +

And that will lead me down some path of errors. It might help me implement a route and a controller and then a show action, so it will at least help me get started. Or even if it doesn't give me helpful enough errors, it at least serves as my guideline of like, this is my North Star. This is where I'm headed. So then, if I need to revisit, okay, what's the thing that I'm focused on at the moment? I can go back and be like, okay, I'm focused on achieving this. What's the next smallest step I can take to get there?

+ +

The other thing that I've learned over time is I've given myself the chance to be messy because I got so excited about the idea of unit testing and writing small, fast test that I would often try to start with small objects and then work my way backwards into like, okay, I have this one object that does this thing and one object that like...let's use a concrete example. So one object that knows how to communicate with API and one object that knows how to then parse and format the data I want and then something else that's then going to present that data to the user.

+ +

But I found when I started with small objects, I would get a little lost, and I wasn't always great at bringing them together. So I've taken the opposite approach of where if I'm really not sure where I'm headed and I'm in that more exploratory phase or even just that first initial parse of a feature, I will just start messy. So if I am pulling data from an API and need to show it to a user on a screen, I'll just dump it in the controller if I need to. I'll put it all there together.

+ +

And then once I actually have something that is parsing, or I have something appearing on the page, then I will start to say, "Okay, now that I can see what I need and I can see the pieces that I've written, how can I then start to extract this into smaller objects?” And now, I can start writing unit tests for that data. So that is something that has helped me is just start high, keep it high, be messy, and until you start to see some of the smaller objects that you can pull out.

+ +

CHRIS: Yeah, I think there's something that you were just saying there that clicked for me of we didn't start with the why of TDD. And I don't think we've talked about why we believe in TDD in a while. So this feels like a thing we're saying. It's not good just because it's good, or we don't believe it's good just because that's what we say. For me, it is because it anchors us outside of the code sort of it starts to think of it from the user perspective or some outer layer.

+ +

So even if you're unit testing some deeply nested class within your application, there's still an outer layer. There's still a user of that class. And so, thinking about the public API, I think is really useful. And then the further out you get, the better that is, and I believe strongly in thinking from the outside in on these sort of things.

+ +

And then the other thing you said of allowing for refactoring. And if we have tests, then it's so much easier to sort of...I totally 100% agree with like; I start messy. I start very messy. I wanted to pretend that I was going to be like, oh, I'm so...Steph, I can't believe this. But no, of course, I start messy.

+ +

Why would you start trying to do the hard thing first? No, get something that works. But then having the test coverage around that makes it so much easier to go through those sequential refactoring steps. Versus if you have to write the code correctly upfront and then add test coverage around that, it sort of inverts that whole thing.

+ +

And so, although it may take a little bit longer to write the tests upfront, I do exactly what you're describing of like, I write the tests that tell some truth about the system and constrain the system to do that thing. And then I can have a messy implementation that I can iteratively refactor over and over, and I can extract things from. And then, I can tell a more concise testing story about those. And so it really is both the higher-level perspective I think is super useful and then the ability to refactor under that test coverage is also very useful. And it makes my job easier because I can start messy. I love starting messy. It's so much better.

+ +

STEPH: Yeah, and I think former me had the idea that for me to do TDD properly meant that I had these small, encapsulated objects that I wrote unit tests for. And yes, that is the goal. I do want that, but that doesn't mean I have to start there. That is something that then I can work my way towards.

+ +

That also falls in line with the adage from Sandi Metz that the wrong abstraction is more costly than no abstraction. And so I'd rather start with no abstractions and then start to consider, okay, how can I actually move this out into smaller objects and then test it from there?

+ +

There's also something that I heard that I haven't done as often, but I really liked the idea; it feels very freeing, is that when you do get started and if you write your first test, if you write a test and it helps you make some progress but then you come back to it later and you're like, you know, the test doesn't really add value, or it's not helping me anymore, just thank it and delete it and move on. Just because you wrote it doesn't mean it needs to stay.

+ +

So if it provided some benefit to you and helped you through that journey of adding the feature, then that's wonderful. But don't be timid about deleting it or changing it so that it does serve you because otherwise, it's just going to be this toxic test that gets merged into the main branch, and it's going to be untrustworthy. Or maybe it's fussy and hard to please, or it's just really not the supportive test that you're looking for. And so then you can turn it into more of a supportive test and make it fit your goals instead of just clinging to every test that we've written.

+ +

CHRIS: I like the framing of tests as scaffolding to help you build up the structure. But then, at the end, some of the scaffolding gets ripped away and thrown out. And I do think, again, testing ends up in this weird place. The dogmatic thing that we were talking about earlier feels very true. And I've noticed, particularly on larger teams, folks being very hesitant to delete tests like, that feels like sacrilege. Of course, you can't delete tests; the tests are how we know it's true, which is true, but you can interrogate that. You can see like, how true is it?

+ +

And every test has a cost and maintenance burden, runtime, et cetera. You probably know well, Steph, about having test suites that take a bunch of time to run and then maybe wanting to spend a little bit of time trying to reduce that overall time. And so there's always going to be a trade-off there.

+ +

Actually, someone reminded me of an anecdote recently. I joined a project, and most of the test suite or all of the test suite was commented out because it was flaky or intermittent. And I was like, "Oh, I'm going to delete that." And people were like, "You're what?" I'm like; it's commented out. We're not using it. Let's tell the truth. Git will have it. We can go back and get it. But let's tell the truth with what we're like...this commented-out test suite is almost worse in my mind than having nothing there. The nothing feels painful, right? Let's experience that.

+ +

Whereas the commented out stuff is like, well, we have a test suite; it's just commented out. It's like, no, you don't have a test suite at all. That's not what's going on here. But there were other thoughtboters on the project that poked a good amount of fun at me when they were like, "The first thing you did on this project was delete the test suite?" As I was like, "Yeah, I don't know, I was feeling spicy that day or something."

+ +

But I think the test suite needs to serve the work that we're doing in the same way that everything else does. And so occasionally, yeah, deleting tests is absolutely the right thing and then probably add back some more.

+ +

STEPH: It's funny how that reaction exists. And I've done it before myself where like, if you see commented out code and you put up a PR to remove it, I feel like most people are going to be like, yeah, yeah, that's great. Let's get rid of this. It's clearly not news. It's commented out. But then removing a skipped test then has people like, "Well, but that test looks like it could be valuable, and we're going to fix it."

+ +

And it's like...all I can go back to is that silly example of like, you've got your skinny jeans, one day I'm going to fit into those skinny jeans. And so one day, I'm going to fix this test, and it's going to serve the purpose. And it's going to be the me I want to be. [laughs] And it is funny how we do that. With code, we're like, sure, we can get rid of it. But with tests, we feel this clinginess to them where we want to hold on to it and make it pass. And I think that sometimes has to do with the descriptions.

+ +

There are test descriptions commented out that I've seen are like, user can log in, or if given a user without permission, they can't access. And it's like, oh, that sounds important. I'm now nervous to delete you versus fix you, but you're still not actually running and providing value. And so then I have to negotiate with myself as to where do we actually go from here? But I do love the idea of deleting tests that are skipped because we should just let them go. We either have to dedicate time to fix them or let them go and make that hard decision.

+ +

CHRIS: The critical idea of future me will have more time, future me will be calm and will work through all the other bugs and future discounting; as far as I understand it as a formalization of the term, yeah, it's never true. I've only gotten busier over time, just broadly speaking.

+ +

And that seems to be a truism in software projects as well. It's like, oh, we just have to write a bunch of features, and then it'll be calm. I don't even think I'd want that. But future me will not have more time. And so choosing the things that we do invest in versus not is tricky, but the idea of that future me will have a lot of time or future us probably not true.

+ +

STEPH: Well, I think the story that I just shared at the beginning of our chat highlights that future me won't always be calm. [laughs] So let's work with what I've got. Let's not bank on that. Future Stephanie might be very emotional about dropping her dog off at boarding for a couple of days. [laughs] Future me might be very emotional about fixing this test. All right, well, thanks for going on that journey with me. That's really helpful. I knew you'd have some great insights there.

+ +

Mid-roll Ad:

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: What's going on in my world? Last week we had our first ever Sagewell all-hands get-together in person. Many of us have met in person before, but not everyone. And so this was a combination celebration for our seed fundraising round, which had happened actually sometime right at the end of last year. But due to COVID in the world and complexity, it was difficult to get everybody together. So that finally happened. And then we sort of grafted on to that celebration, that party that we were having. Like, let's just extend a day in either direction and do some in-person working and all of that. And that was really great.

+ +

I'm trying to find that ideal middle ground between we are a remote team, but there is definitely value in occasionally being in person, particularly getting to know people but also just having some higher bandwidth conversations, planning, things like that. They just feel different in person. And so, how do we balance that? And how do we be most productive and all that?

+ +

But it was really great to meet the team more so than I had on the internet and get to spend some time in person and do some whiteboarding. I drew on a whiteboard with a team. We were all looking at the same whiteboard. We're in the same room. And I drew on a whiteboard some entity relationship diagrams. It was awesome. [laughs] It was super fun. It was one of those cases where we had built an assumption deeply into our codebase, and suddenly instead of having one of a thing, we may now have multiple of a thing.

+ +

There's a wonderful blog post by Shawn Wang called Preemptive Pluralization which I think is based on an episode of Ben Orenstein's podcast, The Art of Product, where Ben basically framed the idea of like, I've never regretted pluralizing something earlier. A user has one account; they have multiple accounts. They just happen to have one at this time, et cetera. So we're in one of those.

+ +

And it was a great thing to be able to be in a room and whiteboard. I knew at the time when I did it way back when that I was making the wrong decision. But I didn't know exactly how and the shape. And so now we have to do that fun refactoring so glad that we have a giant test suite that will help us with said refactoring. But yeah, so that was really great to be able to do in person.

+ +

STEPH: I think there can be so much value in getting together and getting to see your team and, like you said, have those high-level conversations and then just also getting to hang out. So it's really nice to hear that reinforced since you experienced that same positivity from that experience. Do you think that's something that y'all will have going forward? Do you think you're going to try to get together like once a year, once a quarter? Maybe it hasn't even been talked about. But I'm hearing that it was great and that maybe there will be some repeats.

+ +

CHRIS: Yes, yeah. I think I'm inclined to quarterly at a minimum and maybe even slightly more than that. Some of us are centered around Boston, and so it's a little bit easier for us to pop in and work at a WeWork, that sort of thing. But I think broadly, getting the team together and having that be intentional. And personally, I'm inclined to that being more social time than productive time because I think that's the thing that is most useful in person is building relationship and rapport and understanding folks better.

+ +

I remember so pointedly when thoughtbot would have the annual Summer Summit, and leading up to that; there was a certain amount of conversation. But there were also location-specific rooms, and a lot of the conversation happened like in the Boston channel or whatnot. And then, without fail, every year after the Summer Summit, suddenly, there was a spike in cross-team chatter. Like, the Ruby room now had a bunch of people from San Francisco talking to Boston, talking to New York, et cetera. And it was just this incredibly clear...I think we could actually, like, I think at one point someone plotted the data, and there's just this stepwise jump that would happen every time.

+ +

And so that sort of connecting folks is really what I believe in there. And the more we're leaning into the remote thing, then the more I think this is important. So I think quarterly is probably the lowest end that I would think of, but it might be more. And it's also a question of like, what shape does this take? Is it just us going and hanging out somewhere? Or are we productively trying to get together with a whiteboard? I think we'll figure that out as we go on. But it's definitely something that I'm glad we've done now, set the precedent for, and we'll hopefully do more of moving on.

+ +

STEPH: Yeah, I always really love the thoughtbot Summits. In fact, we have one coming up. It's coming up in May, and this one's taking place in UK. But there have been some interesting conversations around Summit because before, it was the idea that everybody traveled. But typically, they were in Boston, so for me, it was particularly easy because it was already where I lived. So then showing up for Summit was no biggie.

+ +

But with this one happening in UK and COVID and travel still being a concern, there's been more conversations around; okay, this is awesome. People who want to get together can. There are these events going on. But there are people who don't want to travel, don't feel up to travel. They have family obligations that then make it very difficult for them to leave one partner at home with the kids. And I myself I'm in that space where I thought really hard about whether I was going to travel or not. And I've decided not to just for personal reasons.

+ +

But then it brings up the question of okay, well, if we have a number of people that are going to be in person together, then what about the people who are remote? And the idea of running something that's hybrid is not something that we've really figured out. But those that are remote, we're going to get together and figure out what we want to do and maybe what's our version of our remote summit since we're not going to be traveling.

+ +

But I feel like that's definitely a direction that needs to be considered as teams are getting in person because if you do have people that can't make it, how can you still bring them in so it's an inclusive event but respect to the fact that they can't necessarily travel? I don't know if that's a concern that every team needs to have, but it's one that I've been thinking about with our team. And then I know others at thoughtbot we've been considering just because we do have such a disparate team. And we want to make everybody comfortable and feel included.

+ +

CHRIS: Yeah, as with everything in this world, there's always complexities and subtlety. Thankfully, for our first get-together, we were able to get everyone into the same space. But I do wonder, especially as the team grows, even just scheduling, the logistics of it become really complicated.

+ +

So then does the engineering team have get-togethers that are slightly different, and then there's like once yearly a big get-together of the whole team? Or how do you manage that and dealing with family situations and all that? It is very much a complicated thing that thankfully was very straightforward for us this first time, but I fully expect that we'll have to be all the more intentional with it moving forward. And, you know, that's just the game.

+ +

But switching gears ever so slightly, we did have a fun thing that we've worked on a little bit over the past few weeks. We've finally landed it in the app. But we were swapping out our masked input library that we were using, so this is for someone entering their birthday, or a phone number, or social security number, or dates. I guess I already said dates. Passwords I think we also use here. But we have a bunch of different inputs in the app that behave specially.

+ +

And my goodness, is this one of those things that falls into the category of, oh yeah, I assume this is a solved problem, right? We just have a library out there that does it. And each library is like, oh no, all of the other libraries are bad. I will come along, and I will write the one library to solve all of the problems, and then we'll be good. And it is just such a surprisingly complicated space. It feels like it should be more straightforward.

+ +

And as I think about it, it's not; it's dealing with imperative interactions between a user and this input. And you need to transform it from what happens when you hit the delete key? What do you want to happen? What's the most discoverable for every user? How do we make sure they're accessible? But my goodness, was it complicated. I think we're happy with where we landed, but it was an adventure.

+ +

STEPH: I'll be honest, that's something that I haven't given as much thought to. But I guess that's also I just haven't worked with that lately in terms of a particular library that then masks those inputs. So I'm curious, which library were using before, and then which one did you switch to?

+ +

CHRIS: That's a critical piece of information that I have left off here. So for the previous one, we were using one called svelte-input-mask, which, again, part of the fun here is you want to have bindings into whatever framework that you're using. So svelte-input-mask is what we were using before. We have now moved on to using iMask, which is not like the thing you wear on your face, but it is the letter I so like igloo, Mike, et cetera, I-M-A-S-K, iMask.

+ +

And so that is a lower-level library. There are bindings to other things. But for TypeScript and other reasons, we ended up implementing our own bindings in Svelte, which was actually relatively straightforward. Again, big fan of Svelte; it's a wonderful little framework. But that is what we're using now, and it is excellent. It's got a lot of features. We ended up using it in a slightly more simple version or implementation. It's got a lot of bells and whistles and configurations. We went up the middle with it. But yeah, we're on iMask, which also led to a very entertaining moment where it was interacting with our test suite in an interesting way.

+ +

And so, one of the developers on the team searched for Capybara iMask. [laughs] And I forget exactly how it happened, but if you Google search that, for some reason, the internet thinks an iMask is a thing that goes over your mouth. And so it's a Capybara, like the animal, facemask. It's very confusing, but this got dropped into our Slack at one point, someone being like, "I searched for Capybara iMask, and it got weird, everybody." So yeah, that was a fun, little side quest that we got to go on.

+ +

STEPH: [laughs] I just Googled it as you told me to, and it's adorable. Yeah, it's a face mask, and it has a little capybara cartoon on the front of it. Yeah, there are many of these. [laughs]

+ +

CHRIS: When I think of an iMask, though, it's the thing that you put over your eyes to block the light if you want to sleep. But they're like, an iMask like, a mask that still keeps her eyes outside of it. I don't understand the internet. It's a weird place.

+ +

STEPH: I think that was just Google saying Capybara iMask. Nope, don't know I, so let's put together Capybara mask, and that's what you got back. [laughs]

+ +

CHRIS: I guess, yeah. It's just a Capybara mask. And I'm projecting the ‘I’ because I phonetically heard that for a while. Anyway, yes. But yeah, masked inputs so complicated.

+ +

STEPH: This is adorable. I feel like there should be swag for when people move. Like when people find things like this, this is the type of thing that then I stash and then wait for their anniversary at the company, and then I send it to them to remind them of this time that we had together. [laughs]

+ +

There was also a moment where you said, ‘I.’ You were explaining I as in in the letter I, not E-Y-E for eyemask. And you said igloo, and my brain definitely short-circuited for a minute to be like, did he just say igloo? Why did he say igloo? And it took me a minute to, oh, he's helping phonetically say that this is for the letter I.

+ +

CHRIS: Yep. The NATO phonetic alphabet that if you don't explain that that's what you're doing, now I'm just naming random other objects in the world. Sorry.

+ +

STEPH: [laughs]

+ +

CHRIS: And that's why I cut myself off halfway through. I'm like, now you're just naming stuff. This isn't helping.

+ +

STEPH: [laughs]

+ +

CHRIS: Yes, the letter I, the letter M. [laughs]

+ +

STEPH: All of that was a delightful journey for me, and I was curious. I'm glad you brought the test because I was curious if y'all are testing if things are getting obscured, but it sounds like y'all are, which is what helped give you confidence as you were switching over to the new library.

+ +

CHRIS: Yeah, although to name it, we're not testing at a terribly low level. This is a great example of where I believe in feature specs. Like, within our Capybara feature spec, we are saying, and then as a user, I type in this value into the input. And critically, although this input needs to have special formatting and presentational behavior, it should functionally be identical. And so it was a very good litmus test of does this just work?

+ +

And then, actually, our feature specs ended up in a race condition, which is just an annoying situation where Capybara moves so quickly that it represented a user. But as we were having that conversation, I was like, wait a minute; I know that users are slower than a computer. But is this actually an edge case that's real that we need to think about? And I think we did end up slightly changing our implementation. So our feature specs did, in a way, highlight that.

+ +

But mostly, our feature specs did not need to change to adapt to and then fill in the formatted input. It was just fill in the input with the value. And that did not change at all, but it did put a tiny bit of pressure on our implementation to say, oh, there is a weird, tiny, little race condition here. Let's fix that. And so we did race conditions, no fun at all.

+ +

STEPH: Interesting. Okay, so y'all aren't actually testing. Like, there's no test that says, "Hey, that when someone types into this field, that then there should be this different UI that's present because then we are obscuring the text that they're putting into this field." It was, as you mentioned, we're just testing that we changed over libraries, and everything still works. So then do you just go through that manual test of, then you go to staging, and then you test it that way?

+ +

CHRIS: Yeah, that's a great question, yes, although as you say it, it's interesting. I guess there's a failure mode here or that our test suite does not enforce that the formatting masking behavior is happening. But it does test that the value goes through this input, gets submitted to the server, turns into the right type of value in the back end, all of that. And so I guess this is an example of how I think about testing, like, that's the critical bit, and then it's a nicety. It's an enhancement that we have this masking behavior.

+ +

But if that broke, as long as the actual flow of data is still working, that can't break in a way that a user can't use. It sort of reminds me of the Mitch Hedberg joke, an escalator can never break, and it can only become stairs. And so I'm in that mindset here where a masked input that you have proper feature spec coverage around can never quote, unquote, "break." It can just become a plain text input.

+ +

STEPH: I love how much that resonates with me. And I now know that when I'm writing tests, I'm going to think back to Mitch Hedberg and be like, oh, but is it broken-broken, or is it just now stairs? Because that's often how I will think of feature specs and how low level I will get with them. And this is on that boundary of like, yes, it's important that we want to obscure that data that someone's typing in, but it's not broken if it's not obscured.

+ +

So there's that balance of I don't really want to test it. Someone will alert us. Like if that breaks, someone will alert us, and it's not the end of the world. It's just unfortunate. But if they can't sign in or they can't actually submit the form, that's a big problem. So yes, I love this comparison now of is it actually broken, or is it just stairs? [laughs] As a guideline for, how much should we test at this feature level or test in general? What should we care about?

+ +

CHRIS: I feel like this is a deep truth that I believed for a long time. And I think I probably, somewhere in the back of my head, connected it to this joke. But I feel really good that I formally made that connection now because I feel like it helps me categorize this whole thing. Sorry for the convenience as a joke. And so yeah, that's where we're at.

+ +

STEPH: For anyone that's not familiar with the comedian Mitch Hedberg, we'll be sure to include a link to that particular joke because it's delightful. And now it's connected to tech, which makes it just even more delightful.

+ +

CHRIS: I only understand anything by analogy, especially humorous analogy. So this is just critical to my progression as a developer and technologist.

+ +

STEPH: Yeah, I've learned over the years that there are two ways that I retain knowledge: it either caused me pain, or it made me laugh. Otherwise, it's mundane, and it gets filtered out. Laughter is, of course, my favorite. I mean, pain sticks with me as well. But if it's something that made me laugh, I just know I'm far more likely to retain it, and it's going to stick with me.

+ +

Mid-Roll AD:

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines, Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free.

+ +

CHRIS: On that wonderful framing there, I think we should wrap up. What do you think?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph has a question for Chris: When you have no idea how you're going to implement a feature, how do you write your first test?

+ +

Chris has thoughts about hybrid teams (remote/in-person) and masked inputs.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Preemptive Pluralization is (Probably) Not Evil
+iMask
+Mitch Hedberg - Escalator Joke

+ +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: I am recording in a new room because we're in Pennsylvania, and so I'm recording at this little vanity desk which is something. [laughs] But there's a mirror right in front of me, so I feel very vain because it's just like, [laughs] I'm just looking at myself while I'm recording with you. It's something.

+ +

CHRIS: [laughs] That is something.

+ +

STEPH: [laughs] So, you know.

+ +

CHRIS: Fun times.

+ +

STEPH: Pro podcast tip, you know, just stare at yourself while you chat, while you record.

+ +

CHRIS: I mean, if that works for you, you know, plenty of people in the gym have the mirrors up, so podcasting is like exercising in a way, and I think it makes sense.

+ +

STEPH: I appreciate the generosity. [laughs]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So I have a funny/emotional story that [laughs] I'm going to share with you first because I feel like it kind of encapsulates how life is going at the moment. So we've officially moved from South Carolina to North Carolina. I feel like I've been talking about that for several episodes now. But this is it: we have finally vacated all of our stuff out of South Carolina house and relocated to North Carolina. And once we got to North Carolina, we immediately had to then leave town for a couple of days.

+ +

And normally, Utah, our dog, stays with an individual in South Carolina, someone that we found, trust, and love. And he has a great time, and I just know he's happy. But we didn't have that this time. So I had to find just a boarding facility that had really high reviews that I felt like I could trust him with. I didn't even have time to take him for a day to test it out. It was one of those like, I got to show up and just drop him off and hope this goes well, so I did.

+ +

And everything looks wonderful. Like, the facility is very clean. I had a list of things to look for to make sure it was a good place. But it's the first time leaving him somewhere where he's going to spend significant time in a kennel that has indoor-outdoor access. And as I walked away from him, I started to cry. And I just thought, oh no, this is embarrassing. I'm that dog mom who's going to start crying in this boarding facility as she's leaving her dog for the first time. So I put on my shades, and I managed to make it through the checkout process.

+ +

But then I went to my truck and just sat there and cried for 15 minutes and called my husband and was like, "I'm doing the right thing, right? Like, tell me this is okay because I'm having a moment." And I finally got through that moment. But then I even called you because you and I were scheduled to chat. And I was like, I am not in a place that I can chat right now. I think I told you when you answered the phone. I was like, "Everything is fine, but I sound like the world's ending, or I sound like a mess." [laughs]

+ +

And yeah, so I had like two hours of where I just couldn't stop crying. I partially blame pregnancy hormones. I'm going to go with that as my escape rope for now. So I feel like that's been life lately. Life's been a little overwhelming, and that felt like the cherry on top. And that was the moment that I broke. Update: he's doing great. I've gotten pictures of Utah. He's having a wonderful time at camp, it seems. [laughs] It was just me, his mom, who is having trouble.

+ +

CHRIS: Well, you know, reasonable to worry, and life's dialed up to 11 and all of that. But yeah, I will say even though you lead the conversation with everything's fine, your tone of voice did not imply that everything was fine. So when I eventually came to understand what we were talking about, I hope I was kind in the moment. But I was like, oh, okay, this is fine. We're fine. I'm so sorry you're feeling terrible right now.

+ +

STEPH: [laughs]

+ +

CHRIS: But okay, we're fine. For me, there was a palpable moment of like, okay, my stress is now back down a little bit. But I'm glad that things are going well and that Utah is having a fun vacation.

+ +

STEPH: Yep, he seems to be doing fine. I've calmed down. You know, as you said, life's been dialed up lately. On a less emotional note and something that's a little bit more technical, I had a really great conversation with another thoughtboter where we were talking about testing. And the idea of when you learn testing, it's often very focused on like, you have this object, and it has a method. And so, you're going to write a unit test for this particular method. And it's very isolated, very specific as to the thing that you're looking to test.

+ +

Versus in reality, when you pick up tickets, you don't have that scope, and like, it is so broad. You have to figure out what feature you're implementing, figure out how to test it. And it feels like this mismatch between how a lot of people learn to test and learn TDD versus then how we actually practice it in the wild.

+ +

And so we had a phone conversation around when you are presented with a ticket like that, and you have no idea how you're going to implement a feature, how do you get started with testing, and when do you write your first test? Do you TDD? Do you BDD? Or do you PDD? That last one I made up, it stands for Panic-driven development. But it's what's your approach to how do you actually then get to the point where you can write a test? And I have a couple of thoughts. But I'm really curious, how does that flow work for you? What have you learned throughout the years to then help yourself write that first test? Or where do you start?

+ +

CHRIS: Well, this is an interesting question. I like this one. I think it varies. And I think there's a lot of dogma around TDD as a practice. And I think it is super useful to break that apart and hear different individual stories of it. I know there are plenty of folks who are like, TDD is just not a thing and whatnot, and I'm certainly not in that camp. But I also don't TDD 100% of the time because sometimes I'm not super clear on what I'm doing, or I'm in more of an exploratory phase.

+ +

That said, I think there's a...I want to answer the question somewhat indirectly, which is I know how to test most of the code that I work on now as a web developer in a Rails application because I've done most of the things a bunch of times. And the specifics may be different, but the like, to integrate with this external system, and I have to build an API client or whatever, I know how to do that.

+ +

And there is a public API of some class that I will be exercising against and so I can write tests against that. Or I know that the user is going to click a button, and then something needs to happen. And so I can write that test, and it fails, and then it starts to push me towards the implementation. There are also times where it's actually quite hard to get the test to lead you in the right direction, and you have to know what hop to make, and so sometimes I just do that.

+ +

But yeah, rolling back a little bit, I think there is a certain amount of experience that is necessary. And I think one of the critical things that I want to share with folks that are potentially newer to testing overall is that it is actually quite hard. You have to understand your system and how you're going to approach it, you know, one step removed, or it's like a game of chess where you're thinking a couple of moves ahead. You have to understand it in a deeper way.

+ +

And so, if testing is difficult, that might just be totally reasonable at this point. And as you come to see the patterns within a Rails application or whatever type of application you're working on over and over, it becomes easier to test. But if testing is hard, that may not mean...like, how do I phrase this? There's like an impostor syndrome story in here of like, if you're struggling with testing, it may not be that something is fundamentally broken. You just may need a couple more chances to see that sort of thing play out.

+ +

And so, for me, in most cases, I tend to know where to start or when not to. Like, I feel fine not testing when I don't test most of the time. I will eventually get things under test coverage such that I feel confident in that. And whenever I have one of those moments, I will stop and look at it and say, "Why didn't I know how to test this from the front, like, from the start?"

+ +

But it's rare at this point for things to be truly exploratory. There's always some outer layer that I can wrap around. But like, I know X needs to happen when Y occurs. So how do I instrument the system in that way? But yeah, those are some thoughts. What are your thoughts? Does what I said sound reasonable here?

+ +

STEPH: Yeah, I really like how you highlighted that pausing for reflection. That was something that I didn't initially think of, but I really liked that, to then go back to be like, okay, revisiting myself a couple of days or however earlier when I first started this. Now I can see where I've ended up. How could I have made that connection sooner as to where I was versus the tests I ended up with? Or perhaps recognizing that I couldn't have gotten there sooner, that I needed that journey to help me get there. So I really like the idea of pausing for reflection because then it helps cement any of those learnings that you have made during that time.

+ +

Also, the other part where you mentioned the user clicks a button, and something happens, that's where I immediately went with this. I also liked that you highlighted that TDD has that bit of dogma, and I don't always TDD. I do what I can, and it helps me. But it has to be a tool versus something that I just do 100% of the time. But with more of that BDD approach or that very high-level user-level integration test of where if I need to pull data from an API and then show it to the user, okay, I know I can at least start with a high-level test of I want the user to then see some data on a page.

+ +

And that will lead me down some path of errors. It might help me implement a route and a controller and then a show action, so it will at least help me get started. Or even if it doesn't give me helpful enough errors, it at least serves as my guideline of like, this is my North Star. This is where I'm headed. So then, if I need to revisit, okay, what's the thing that I'm focused on at the moment? I can go back and be like, okay, I'm focused on achieving this. What's the next smallest step I can take to get there?

+ +

The other thing that I've learned over time is I've given myself the chance to be messy because I got so excited about the idea of unit testing and writing small, fast test that I would often try to start with small objects and then work my way backwards into like, okay, I have this one object that does this thing and one object that like...let's use a concrete example. So one object that knows how to communicate with API and one object that knows how to then parse and format the data I want and then something else that's then going to present that data to the user.

+ +

But I found when I started with small objects, I would get a little lost, and I wasn't always great at bringing them together. So I've taken the opposite approach of where if I'm really not sure where I'm headed and I'm in that more exploratory phase or even just that first initial parse of a feature, I will just start messy. So if I am pulling data from an API and need to show it to a user on a screen, I'll just dump it in the controller if I need to. I'll put it all there together.

+ +

And then once I actually have something that is parsing, or I have something appearing on the page, then I will start to say, "Okay, now that I can see what I need and I can see the pieces that I've written, how can I then start to extract this into smaller objects?” And now, I can start writing unit tests for that data. So that is something that has helped me is just start high, keep it high, be messy, and until you start to see some of the smaller objects that you can pull out.

+ +

CHRIS: Yeah, I think there's something that you were just saying there that clicked for me of we didn't start with the why of TDD. And I don't think we've talked about why we believe in TDD in a while. So this feels like a thing we're saying. It's not good just because it's good, or we don't believe it's good just because that's what we say. For me, it is because it anchors us outside of the code sort of it starts to think of it from the user perspective or some outer layer.

+ +

So even if you're unit testing some deeply nested class within your application, there's still an outer layer. There's still a user of that class. And so, thinking about the public API, I think is really useful. And then the further out you get, the better that is, and I believe strongly in thinking from the outside in on these sort of things.

+ +

And then the other thing you said of allowing for refactoring. And if we have tests, then it's so much easier to sort of...I totally 100% agree with like; I start messy. I start very messy. I wanted to pretend that I was going to be like, oh, I'm so...Steph, I can't believe this. But no, of course, I start messy.

+ +

Why would you start trying to do the hard thing first? No, get something that works. But then having the test coverage around that makes it so much easier to go through those sequential refactoring steps. Versus if you have to write the code correctly upfront and then add test coverage around that, it sort of inverts that whole thing.

+ +

And so, although it may take a little bit longer to write the tests upfront, I do exactly what you're describing of like, I write the tests that tell some truth about the system and constrain the system to do that thing. And then I can have a messy implementation that I can iteratively refactor over and over, and I can extract things from. And then, I can tell a more concise testing story about those. And so it really is both the higher-level perspective I think is super useful and then the ability to refactor under that test coverage is also very useful. And it makes my job easier because I can start messy. I love starting messy. It's so much better.

+ +

STEPH: Yeah, and I think former me had the idea that for me to do TDD properly meant that I had these small, encapsulated objects that I wrote unit tests for. And yes, that is the goal. I do want that, but that doesn't mean I have to start there. That is something that then I can work my way towards.

+ +

That also falls in line with the adage from Sandi Metz that the wrong abstraction is more costly than no abstraction. And so I'd rather start with no abstractions and then start to consider, okay, how can I actually move this out into smaller objects and then test it from there?

+ +

There's also something that I heard that I haven't done as often, but I really liked the idea; it feels very freeing, is that when you do get started and if you write your first test, if you write a test and it helps you make some progress but then you come back to it later and you're like, you know, the test doesn't really add value, or it's not helping me anymore, just thank it and delete it and move on. Just because you wrote it doesn't mean it needs to stay.

+ +

So if it provided some benefit to you and helped you through that journey of adding the feature, then that's wonderful. But don't be timid about deleting it or changing it so that it does serve you because otherwise, it's just going to be this toxic test that gets merged into the main branch, and it's going to be untrustworthy. Or maybe it's fussy and hard to please, or it's just really not the supportive test that you're looking for. And so then you can turn it into more of a supportive test and make it fit your goals instead of just clinging to every test that we've written.

+ +

CHRIS: I like the framing of tests as scaffolding to help you build up the structure. But then, at the end, some of the scaffolding gets ripped away and thrown out. And I do think, again, testing ends up in this weird place. The dogmatic thing that we were talking about earlier feels very true. And I've noticed, particularly on larger teams, folks being very hesitant to delete tests like, that feels like sacrilege. Of course, you can't delete tests; the tests are how we know it's true, which is true, but you can interrogate that. You can see like, how true is it?

+ +

And every test has a cost and maintenance burden, runtime, et cetera. You probably know well, Steph, about having test suites that take a bunch of time to run and then maybe wanting to spend a little bit of time trying to reduce that overall time. And so there's always going to be a trade-off there.

+ +

Actually, someone reminded me of an anecdote recently. I joined a project, and most of the test suite or all of the test suite was commented out because it was flaky or intermittent. And I was like, "Oh, I'm going to delete that." And people were like, "You're what?" I'm like; it's commented out. We're not using it. Let's tell the truth. Git will have it. We can go back and get it. But let's tell the truth with what we're like...this commented-out test suite is almost worse in my mind than having nothing there. The nothing feels painful, right? Let's experience that.

+ +

Whereas the commented out stuff is like, well, we have a test suite; it's just commented out. It's like, no, you don't have a test suite at all. That's not what's going on here. But there were other thoughtboters on the project that poked a good amount of fun at me when they were like, "The first thing you did on this project was delete the test suite?" As I was like, "Yeah, I don't know, I was feeling spicy that day or something."

+ +

But I think the test suite needs to serve the work that we're doing in the same way that everything else does. And so occasionally, yeah, deleting tests is absolutely the right thing and then probably add back some more.

+ +

STEPH: It's funny how that reaction exists. And I've done it before myself where like, if you see commented out code and you put up a PR to remove it, I feel like most people are going to be like, yeah, yeah, that's great. Let's get rid of this. It's clearly not news. It's commented out. But then removing a skipped test then has people like, "Well, but that test looks like it could be valuable, and we're going to fix it."

+ +

And it's like...all I can go back to is that silly example of like, you've got your skinny jeans, one day I'm going to fit into those skinny jeans. And so one day, I'm going to fix this test, and it's going to serve the purpose. And it's going to be the me I want to be. [laughs] And it is funny how we do that. With code, we're like, sure, we can get rid of it. But with tests, we feel this clinginess to them where we want to hold on to it and make it pass. And I think that sometimes has to do with the descriptions.

+ +

There are test descriptions commented out that I've seen are like, user can log in, or if given a user without permission, they can't access. And it's like, oh, that sounds important. I'm now nervous to delete you versus fix you, but you're still not actually running and providing value. And so then I have to negotiate with myself as to where do we actually go from here? But I do love the idea of deleting tests that are skipped because we should just let them go. We either have to dedicate time to fix them or let them go and make that hard decision.

+ +

CHRIS: The critical idea of future me will have more time, future me will be calm and will work through all the other bugs and future discounting; as far as I understand it as a formalization of the term, yeah, it's never true. I've only gotten busier over time, just broadly speaking.

+ +

And that seems to be a truism in software projects as well. It's like, oh, we just have to write a bunch of features, and then it'll be calm. I don't even think I'd want that. But future me will not have more time. And so choosing the things that we do invest in versus not is tricky, but the idea of that future me will have a lot of time or future us probably not true.

+ +

STEPH: Well, I think the story that I just shared at the beginning of our chat highlights that future me won't always be calm. [laughs] So let's work with what I've got. Let's not bank on that. Future Stephanie might be very emotional about dropping her dog off at boarding for a couple of days. [laughs] Future me might be very emotional about fixing this test. All right, well, thanks for going on that journey with me. That's really helpful. I knew you'd have some great insights there.

+ +

Mid-roll Ad:

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: What's going on in my world? Last week we had our first ever Sagewell all-hands get-together in person. Many of us have met in person before, but not everyone. And so this was a combination celebration for our seed fundraising round, which had happened actually sometime right at the end of last year. But due to COVID in the world and complexity, it was difficult to get everybody together. So that finally happened. And then we sort of grafted on to that celebration, that party that we were having. Like, let's just extend a day in either direction and do some in-person working and all of that. And that was really great.

+ +

I'm trying to find that ideal middle ground between we are a remote team, but there is definitely value in occasionally being in person, particularly getting to know people but also just having some higher bandwidth conversations, planning, things like that. They just feel different in person. And so, how do we balance that? And how do we be most productive and all that?

+ +

But it was really great to meet the team more so than I had on the internet and get to spend some time in person and do some whiteboarding. I drew on a whiteboard with a team. We were all looking at the same whiteboard. We're in the same room. And I drew on a whiteboard some entity relationship diagrams. It was awesome. [laughs] It was super fun. It was one of those cases where we had built an assumption deeply into our codebase, and suddenly instead of having one of a thing, we may now have multiple of a thing.

+ +

There's a wonderful blog post by Shawn Wang called Preemptive Pluralization which I think is based on an episode of Ben Orenstein's podcast, The Art of Product, where Ben basically framed the idea of like, I've never regretted pluralizing something earlier. A user has one account; they have multiple accounts. They just happen to have one at this time, et cetera. So we're in one of those.

+ +

And it was a great thing to be able to be in a room and whiteboard. I knew at the time when I did it way back when that I was making the wrong decision. But I didn't know exactly how and the shape. And so now we have to do that fun refactoring so glad that we have a giant test suite that will help us with said refactoring. But yeah, so that was really great to be able to do in person.

+ +

STEPH: I think there can be so much value in getting together and getting to see your team and, like you said, have those high-level conversations and then just also getting to hang out. So it's really nice to hear that reinforced since you experienced that same positivity from that experience. Do you think that's something that y'all will have going forward? Do you think you're going to try to get together like once a year, once a quarter? Maybe it hasn't even been talked about. But I'm hearing that it was great and that maybe there will be some repeats.

+ +

CHRIS: Yes, yeah. I think I'm inclined to quarterly at a minimum and maybe even slightly more than that. Some of us are centered around Boston, and so it's a little bit easier for us to pop in and work at a WeWork, that sort of thing. But I think broadly, getting the team together and having that be intentional. And personally, I'm inclined to that being more social time than productive time because I think that's the thing that is most useful in person is building relationship and rapport and understanding folks better.

+ +

I remember so pointedly when thoughtbot would have the annual Summer Summit, and leading up to that; there was a certain amount of conversation. But there were also location-specific rooms, and a lot of the conversation happened like in the Boston channel or whatnot. And then, without fail, every year after the Summer Summit, suddenly, there was a spike in cross-team chatter. Like, the Ruby room now had a bunch of people from San Francisco talking to Boston, talking to New York, et cetera. And it was just this incredibly clear...I think we could actually, like, I think at one point someone plotted the data, and there's just this stepwise jump that would happen every time.

+ +

And so that sort of connecting folks is really what I believe in there. And the more we're leaning into the remote thing, then the more I think this is important. So I think quarterly is probably the lowest end that I would think of, but it might be more. And it's also a question of like, what shape does this take? Is it just us going and hanging out somewhere? Or are we productively trying to get together with a whiteboard? I think we'll figure that out as we go on. But it's definitely something that I'm glad we've done now, set the precedent for, and we'll hopefully do more of moving on.

+ +

STEPH: Yeah, I always really love the thoughtbot Summits. In fact, we have one coming up. It's coming up in May, and this one's taking place in UK. But there have been some interesting conversations around Summit because before, it was the idea that everybody traveled. But typically, they were in Boston, so for me, it was particularly easy because it was already where I lived. So then showing up for Summit was no biggie.

+ +

But with this one happening in UK and COVID and travel still being a concern, there's been more conversations around; okay, this is awesome. People who want to get together can. There are these events going on. But there are people who don't want to travel, don't feel up to travel. They have family obligations that then make it very difficult for them to leave one partner at home with the kids. And I myself I'm in that space where I thought really hard about whether I was going to travel or not. And I've decided not to just for personal reasons.

+ +

But then it brings up the question of okay, well, if we have a number of people that are going to be in person together, then what about the people who are remote? And the idea of running something that's hybrid is not something that we've really figured out. But those that are remote, we're going to get together and figure out what we want to do and maybe what's our version of our remote summit since we're not going to be traveling.

+ +

But I feel like that's definitely a direction that needs to be considered as teams are getting in person because if you do have people that can't make it, how can you still bring them in so it's an inclusive event but respect to the fact that they can't necessarily travel? I don't know if that's a concern that every team needs to have, but it's one that I've been thinking about with our team. And then I know others at thoughtbot we've been considering just because we do have such a disparate team. And we want to make everybody comfortable and feel included.

+ +

CHRIS: Yeah, as with everything in this world, there's always complexities and subtlety. Thankfully, for our first get-together, we were able to get everyone into the same space. But I do wonder, especially as the team grows, even just scheduling, the logistics of it become really complicated.

+ +

So then does the engineering team have get-togethers that are slightly different, and then there's like once yearly a big get-together of the whole team? Or how do you manage that and dealing with family situations and all that? It is very much a complicated thing that thankfully was very straightforward for us this first time, but I fully expect that we'll have to be all the more intentional with it moving forward. And, you know, that's just the game.

+ +

But switching gears ever so slightly, we did have a fun thing that we've worked on a little bit over the past few weeks. We've finally landed it in the app. But we were swapping out our masked input library that we were using, so this is for someone entering their birthday, or a phone number, or social security number, or dates. I guess I already said dates. Passwords I think we also use here. But we have a bunch of different inputs in the app that behave specially.

+ +

And my goodness, is this one of those things that falls into the category of, oh yeah, I assume this is a solved problem, right? We just have a library out there that does it. And each library is like, oh no, all of the other libraries are bad. I will come along, and I will write the one library to solve all of the problems, and then we'll be good. And it is just such a surprisingly complicated space. It feels like it should be more straightforward.

+ +

And as I think about it, it's not; it's dealing with imperative interactions between a user and this input. And you need to transform it from what happens when you hit the delete key? What do you want to happen? What's the most discoverable for every user? How do we make sure they're accessible? But my goodness, was it complicated. I think we're happy with where we landed, but it was an adventure.

+ +

STEPH: I'll be honest, that's something that I haven't given as much thought to. But I guess that's also I just haven't worked with that lately in terms of a particular library that then masks those inputs. So I'm curious, which library were using before, and then which one did you switch to?

+ +

CHRIS: That's a critical piece of information that I have left off here. So for the previous one, we were using one called svelte-input-mask, which, again, part of the fun here is you want to have bindings into whatever framework that you're using. So svelte-input-mask is what we were using before. We have now moved on to using iMask, which is not like the thing you wear on your face, but it is the letter I so like igloo, Mike, et cetera, I-M-A-S-K, iMask.

+ +

And so that is a lower-level library. There are bindings to other things. But for TypeScript and other reasons, we ended up implementing our own bindings in Svelte, which was actually relatively straightforward. Again, big fan of Svelte; it's a wonderful little framework. But that is what we're using now, and it is excellent. It's got a lot of features. We ended up using it in a slightly more simple version or implementation. It's got a lot of bells and whistles and configurations. We went up the middle with it. But yeah, we're on iMask, which also led to a very entertaining moment where it was interacting with our test suite in an interesting way.

+ +

And so, one of the developers on the team searched for Capybara iMask. [laughs] And I forget exactly how it happened, but if you Google search that, for some reason, the internet thinks an iMask is a thing that goes over your mouth. And so it's a Capybara, like the animal, facemask. It's very confusing, but this got dropped into our Slack at one point, someone being like, "I searched for Capybara iMask, and it got weird, everybody." So yeah, that was a fun, little side quest that we got to go on.

+ +

STEPH: [laughs] I just Googled it as you told me to, and it's adorable. Yeah, it's a face mask, and it has a little capybara cartoon on the front of it. Yeah, there are many of these. [laughs]

+ +

CHRIS: When I think of an iMask, though, it's the thing that you put over your eyes to block the light if you want to sleep. But they're like, an iMask like, a mask that still keeps her eyes outside of it. I don't understand the internet. It's a weird place.

+ +

STEPH: I think that was just Google saying Capybara iMask. Nope, don't know I, so let's put together Capybara mask, and that's what you got back. [laughs]

+ +

CHRIS: I guess, yeah. It's just a Capybara mask. And I'm projecting the ‘I’ because I phonetically heard that for a while. Anyway, yes. But yeah, masked inputs so complicated.

+ +

STEPH: This is adorable. I feel like there should be swag for when people move. Like when people find things like this, this is the type of thing that then I stash and then wait for their anniversary at the company, and then I send it to them to remind them of this time that we had together. [laughs]

+ +

There was also a moment where you said, ‘I.’ You were explaining I as in in the letter I, not E-Y-E for eyemask. And you said igloo, and my brain definitely short-circuited for a minute to be like, did he just say igloo? Why did he say igloo? And it took me a minute to, oh, he's helping phonetically say that this is for the letter I.

+ +

CHRIS: Yep. The NATO phonetic alphabet that if you don't explain that that's what you're doing, now I'm just naming random other objects in the world. Sorry.

+ +

STEPH: [laughs]

+ +

CHRIS: And that's why I cut myself off halfway through. I'm like, now you're just naming stuff. This isn't helping.

+ +

STEPH: [laughs]

+ +

CHRIS: Yes, the letter I, the letter M. [laughs]

+ +

STEPH: All of that was a delightful journey for me, and I was curious. I'm glad you brought the test because I was curious if y'all are testing if things are getting obscured, but it sounds like y'all are, which is what helped give you confidence as you were switching over to the new library.

+ +

CHRIS: Yeah, although to name it, we're not testing at a terribly low level. This is a great example of where I believe in feature specs. Like, within our Capybara feature spec, we are saying, and then as a user, I type in this value into the input. And critically, although this input needs to have special formatting and presentational behavior, it should functionally be identical. And so it was a very good litmus test of does this just work?

+ +

And then, actually, our feature specs ended up in a race condition, which is just an annoying situation where Capybara moves so quickly that it represented a user. But as we were having that conversation, I was like, wait a minute; I know that users are slower than a computer. But is this actually an edge case that's real that we need to think about? And I think we did end up slightly changing our implementation. So our feature specs did, in a way, highlight that.

+ +

But mostly, our feature specs did not need to change to adapt to and then fill in the formatted input. It was just fill in the input with the value. And that did not change at all, but it did put a tiny bit of pressure on our implementation to say, oh, there is a weird, tiny, little race condition here. Let's fix that. And so we did race conditions, no fun at all.

+ +

STEPH: Interesting. Okay, so y'all aren't actually testing. Like, there's no test that says, "Hey, that when someone types into this field, that then there should be this different UI that's present because then we are obscuring the text that they're putting into this field." It was, as you mentioned, we're just testing that we changed over libraries, and everything still works. So then do you just go through that manual test of, then you go to staging, and then you test it that way?

+ +

CHRIS: Yeah, that's a great question, yes, although as you say it, it's interesting. I guess there's a failure mode here or that our test suite does not enforce that the formatting masking behavior is happening. But it does test that the value goes through this input, gets submitted to the server, turns into the right type of value in the back end, all of that. And so I guess this is an example of how I think about testing, like, that's the critical bit, and then it's a nicety. It's an enhancement that we have this masking behavior.

+ +

But if that broke, as long as the actual flow of data is still working, that can't break in a way that a user can't use. It sort of reminds me of the Mitch Hedberg joke, an escalator can never break, and it can only become stairs. And so I'm in that mindset here where a masked input that you have proper feature spec coverage around can never quote, unquote, "break." It can just become a plain text input.

+ +

STEPH: I love how much that resonates with me. And I now know that when I'm writing tests, I'm going to think back to Mitch Hedberg and be like, oh, but is it broken-broken, or is it just now stairs? Because that's often how I will think of feature specs and how low level I will get with them. And this is on that boundary of like, yes, it's important that we want to obscure that data that someone's typing in, but it's not broken if it's not obscured.

+ +

So there's that balance of I don't really want to test it. Someone will alert us. Like if that breaks, someone will alert us, and it's not the end of the world. It's just unfortunate. But if they can't sign in or they can't actually submit the form, that's a big problem. So yes, I love this comparison now of is it actually broken, or is it just stairs? [laughs] As a guideline for, how much should we test at this feature level or test in general? What should we care about?

+ +

CHRIS: I feel like this is a deep truth that I believed for a long time. And I think I probably, somewhere in the back of my head, connected it to this joke. But I feel really good that I formally made that connection now because I feel like it helps me categorize this whole thing. Sorry for the convenience as a joke. And so yeah, that's where we're at.

+ +

STEPH: For anyone that's not familiar with the comedian Mitch Hedberg, we'll be sure to include a link to that particular joke because it's delightful. And now it's connected to tech, which makes it just even more delightful.

+ +

CHRIS: I only understand anything by analogy, especially humorous analogy. So this is just critical to my progression as a developer and technologist.

+ +

STEPH: Yeah, I've learned over the years that there are two ways that I retain knowledge: it either caused me pain, or it made me laugh. Otherwise, it's mundane, and it gets filtered out. Laughter is, of course, my favorite. I mean, pain sticks with me as well. But if it's something that made me laugh, I just know I'm far more likely to retain it, and it's going to stick with me.

+ +

Mid-Roll AD:

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines, Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free.

+ +

CHRIS: On that wonderful framing there, I think we should wrap up. What do you think?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+IFpo3pwA + + ]]> + + Chris Toomey + Steph Viccari + + + 334: Name That Bike + https://bikeshed.thoughtbot.com/334 + da71a49d-9580-4212-8c6f-0cff0c7da5ce + Tue, 19 Apr 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris got a bike. Specifically, he bought a bike to use in a triathlon he signed up to participate in. Now he needs to name the bike, and speaking of naming things, a more technical topic that he talks about is the Crispy Brussels Snack Hour. + +Steph talks about Rescue Rails projects and increasing developer acceleration. + +They answer a listener question asking, "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?" + 42:24 + no + + + Chris got a bike. Specifically, he bought a bike to use in a triathlon he signed up to participate in. Now he needs to name the bike, and speaking of naming things, a more technical topic that he talks about is the Crispy Brussels Snack Hour. +Steph talks about Rescue Rails projects and increasing developer acceleration. +They answer a listener question asking, "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?" +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Translate frustrations into professional corporate (https://twitter.com/MeanestTA/status/1509936432625897474) +Learn Hotwire by Building a Forum (https://twitter.com/afomera/status/1512287468078264322) +parallel_tests (https://github.com/grosser/parallel_tests) +parallelsplittest (https://github.com/grosser/parallel_split_test) +This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Oh, but I recently learned that Robert Downey Jr. in the Marvel movies he's snacking a lot, maybe not Iron Man, but something...oh no, he's stacking a lot. And I'd read that he was snacking a lot on set, and so they just built it in to where like, sure, you can snack as your character while you're doing stuff. +CHRIS: [laughs] +STEPH: And I think that's so cool because I find that I am eating every time I show up to record with you. So I would like the same special star treatment as Robert Downey Jr., [laughs] and I just get to eat during each Bike Shed. [laughs] +CHRIS: All right. [chuckles] My understanding is also that he was wildly the highest paid of all the actors, so I think that should also come along with this. +STEPH: [laughs] +CHRIS: Yeah, there's a lot that we can sort of layer on here, but it makes sense to me, and I'm fully on board. +STEPH: You're an excellent agent. Thank you for fighting for my higher pay. +[laughter] +CHRIS: You are welcome. +STEPH: What a good co-host you are. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. One of these days, I'm going to say, "I'm Chris Toomey," and then I'm just going to see how you roll with it, although now I'm ruining it, I should have just gone for it. [laughs] +CHRIS: Nothing can prepare me for this despite the fact that you're telling me in this moment. In that future moment when you do it, I will still be completely knocked out of whack. Just like for anyone out there listening, the thing that Steph would normally have said instead of what [laughs] she just said was, "What's new in your world?" +STEPH: [laughs] +CHRIS: And I contractually require that that is the only way she starts this question to me because I get completely lost. She's like, "How are you doing?" I just overthink it, and I get lost, and then we end up in a place like this where I'm just rambling. +STEPH: Every podcast contract you have from here on out must begin with hey, Chris, what's new in your world? [laughs] I will still get to that question. I just also had to tell you my future joke. I'm going to play that. Hopefully, you'll forget, and one day I will resurface. +CHRIS: I can pretty much promise you that I'm going to forget it. +[laughter] +STEPH: Excellent. Well, to make sure I stick within the Chris Toomey contract guidelines, hey, Chris, what's new in your world? +CHRIS: What's new in my world? Now I just want to spend a lot of time putting together my rider. There can be no brown M&M's in the bowl. No eye contact, please. And I can only be addressed with this one question which is, to be clear, very not true, Steph. And I always record with a video because we actually like to have human faces attached to things. Anyway, I'm going to tighten this all up. When we get to the technical segment of my world, I'm going to tell you about Crispy Brussels Snack Hour, so just throwing that out there as an idea. +But before we do that, I'm going to share a fun little thing which is I bought a bike, which is exciting. It's not that exciting. People have bikes. This is exciting for me. But the associated thing that is more exciting/a little terrifying is I'm going to try and run a triathlon. I'm going to try and run, swim, and bike a triathlon as they go, specifically a sprint triathlon for anyone out there that's listening and thinking, oh wow, that sounds like a thing. The sprint is the shortest of the distances, so that's what I'm going to go for. But yeah, that's a thing that I'm thinking about in my world now. +STEPH: I know next to nothing about triathlons. So what is a sprint in terms of like, what is the shortest? What does that mean? +CHRIS: I think there actually maybe even shorter distances but of the common, there's sprint, Olympic. I want to say half Ironman, and then Ironman are the sequence. And an Ironman, as far as I understand it, I think it's a full marathon. It's like a century bike ride or something like that. It's an astronomical amount of everything. +Whereas the sprint triathlon being the shortest, I think it's a 3.6-mile run, so a little over a 5K run, a 10-mile bike ride, and a quarter-mile swim, I want to say, something like that. But they're each scaled down to the rough equivalent of a 5K but in each of the different events. So you swim, and then you bike, and then you run. +And so I'm going to try that, or at least I'm going to try to try. It's in September, and now is not September. So I have a lot of time between now and then to do some swimming, which I haven't done...like, I've swum but not in a serious way, not in an intentional way. So I got to figure out if I still know how to swim, probably get better at biking, and do a little bit of running, and it's going to be great. It's going to be a lot of fun. I'm super excited about it. Only a little terrified. +STEPH: I think this is where as your co-host coach, which you have not asked me to be, where I would say something about there is no try, to mimic Yoda. [laughs] +CHRIS: Yep, yep. Yep. Do or do not. Sprint or sprint not. There is no trying. Oh, were you making a try pun there? +STEPH: I didn't go that far, but you just brought it home. I see where you're going. [laughs] +CHRIS: This is pretty much what I do professionally is I just take words, and I roll them around until I find something else to do with them. So glad that we got there together. +STEPH: Well, I'm really excited to hear about this. I don't know anyone that's trained for a triathlon. I think that's true. Yeah, I don't think I know anyone that's trained for a triathlon. So I'm curious to hear about how that goes because that sounds intense, friend. +CHRIS: I think so. None of the individual segments sound that bad but stitching them all together, and I think the transitions are some of the tricky parts there. So yeah, it'll be fun. It's something I find...I used to never run; that was the thing. Like, deeply true in my head was that I'm not a runner. This is just a true fact about me. And then I ran a 5K one year for...it was like a holiday 5K fun run with friends. And every bit of the training leading up to it was awful. I did Couch to 5K. I hated it. +My story in my head of I'm not a runner was proven with every single training run. Man, did I hate it. And then something magical happened on the day that I actually ran the race, and it was fun. And I was out there, and there was the energy of being in this group of people. But it was competitive and not competitive in this really interesting way. And then it ended, and we were just hanging out in a parking lot, and they gave us beer. And I was like, well, this is actually delightful. Maybe I actually like this thing. +And so I've run a bunch of different races. And I've found that having a race to train for, and by train, I just mean some structured attempt at running, has been really enjoyable and useful for me. So yeah, this is just ratcheting that up a tiny bit. I've done a couple of half marathons is the high watermark so far. It's a good distance. But I don't know that a full marathon makes sense; that's a real commitment. And I'm looking to move laterally rather than just keep getting more complex in my running. So we're trying the shortest possible triathlon that I know of. +STEPH: I am such a believer that exercise should be fun, so I love that. Like, I'm not a runner, but then you get around people, and it's exciting. And then there's that motivation, and then there's a fun ending with beers that totally jives with me. Because sure, I can go to the gym; I can lift weights, I can make myself exercise. There's some fun to it. +But I strongly prefer anything that's more of like a sport or group exercise; that's just so much more fun. Well, super cool. Well, I'm excited. I would ask you all the details about your bike, but I know nothing. Do you want to share details about your bike? There may be other people that are interested. +CHRIS: Oh yeah, my bike. I went to the bike store, and I said, "Could I have a bike, please?" And then they toured me around and showed me all the fancy...they were like, "This is our most modest entry-level bike." And then they kept walking around and showing me fancier bikes. And I was like, "Can we go back to that first one? That one seemed great." +STEPH: [laughs] +CHRIS: Because it got all of the checkboxes I was looking for, which is basically it's a bike. So actually, the specifics on it are it's a hybrid bike, so like a mix between road, and I don't even know the other road bikes I know of, and maybe it's trail. But I don't think it's meant for going on the trail. But for me, it'll be fine for what I'm trying to do as far as I understand it. +It's technically a fitness hybrid, which I was like, oh, fancy. It's a fitness bike; look at me go. But it was basically just like, I would like a bike. General-purpose hybrid seems like the thing that makes sense. So I got a hybrid bike. And that's where I'm at. Oh, and I got a helmet because that seems like a smart move. +STEPH: Nice. Yeah, the bike I own is also one of those hybrids where it's like…because when I moved to Boston...and lots of people have the road bikes, but their tires are just so skinny; it made me nervous. And so I saw one of the hybrid bikes, and I was like, that one. That looks a little more steady and secure, so I went with that one even though it's heavier. Do you have a name for your bike? Are you going to think of a name for your bike? +CHRIS: I didn't, and I wasn't planning on it. But now that you've incepted me with this idea that I have to name my bike, of course, I have to name my bike. I'm going to need a couple of weeks to figure it out, though. We're going to have to get to know each other. And you know, something will become true in the universe for me to answer that question. But as of so far, no, I do not have a name for the bike. +STEPH: Cool. I'll check back in. Yeah, it takes time to find that name. I feel you. +CHRIS: [laughs] Yeah, don't make up a name. I have to find what's already true and then just say it out loud. Speaking of naming things and perhaps doing so in a frivolous way, as I mentioned earlier, the more technical topic that I want to talk about, oddly, is called Crispy Brussels Snack Hour. [laughs] So, within our dev team, we have started to collect together different things that don't quite belong on the product board, or at least they're a little more confusing. They're much more technical. +In a lot of cases, they are...our form handling is a little rough. And it's the sort of thing that comes up a lot in pull requests where we'll say, "I feel like this could be improved." And we're like, "Yeah, but not in this pull request." And so then it's what do you do with that? Do you put a tech debt card in the product board? You and I have talked about tech debt cards plenty of times, and it's a murky topic. +But we're trying within the team to make space and a way and a little bit of process around how do we think about these sorts of things? What are the pain points as a developer is working on the system? So to be clear, this isn’t there is a bug because bugs we should just fix; that's my strong feeling, or we should prioritize them relative to the rest of the work. But this is a lower level. This is as a developer; I'm specifically feeling this sort of pain. +And so we decided we should have a Trello board for it. And they were like, "Oh, what should we name the Trello board?" [laughs] And I decided in this moment I was like, "You know, if we're being honest, I've named everything very boring, very straight up the middle. We don't even have that many things to name. So we have zero frivolous names within our team. I think this is our opportunity. We should go with a frivolous name. Anybody have any ideas?" +And someone had worked on a team previously where maybe it was a microservice or something like that was called crispy Brussels, like, crispy Brussels sprouts but just crispy Brussels. And so I was like, "Sure, something like that. That sounds great." And then they ended up naming it that which was funny, and fun, and playful in and of itself. +But then we were like, "Oh, we should have a time to get together and discuss this." So we're now exploring how regularly we're going to do it. But we were like, let's have a meeting that is the dev team getting together to review that board. And we were like, "What do we call the meeting?" And so we went around a little bit, but we ended with the Crispy Brussels Snack Hour. +STEPH: That's delightful. I love the idea of onboarding new people, and they just see on their calendar it's Crispy Brussels Snack Hour, come on down. [laughs] +CHRIS: It's also got an emoji Brussel sprout and an emoji TV on either side of the words Crispy Brussels Snack Hour. So it's really just a fantastic little bit of frivolity in our calendars. +STEPH: [laughs] That's delightful. How's that going? I don't think we've tried something like that explicitly in terms of, like you said, there are discussions we want to have, but they're not in the sprint. They're not tech debt cards that we want to create because, like you said, we've had conversations. So yeah, I'm curious how that's working for you. +CHRIS: Well, so we've only had the one so far; it went quite well. We had a handful of different discussions. We were able to relatively prioritize this type of work within that. But one of the other things that we did was we had a conversation about this process, about this meeting, and the board. And whatnot. +So we identified a couple of rules of the road or how we want to approach this that I think will hopefully be useful in trying to constrain this work because it's very easy to just like; nothing's ever perfect. And so this could very easily be a dumping ground for half-formed ideas that sound good but aren't necessarily worth the continued effort, that sort of thing. +So the agenda for the meeting as described right now is async between meetings. Any of us can add new cards, ideally stated as problems and not solutions. So our form handling could use improvement. And then in the card, you can maybe make a suggestion of I think we could use this library or something like that. But rather than saying use this library or move to this library, we frame in terms of the problem, not necessarily the solution. +And then, at the start of the meeting, any individual can champion a card so they can say, "Here's the thing that I really want everyone to know about that I've been feeling a lot of pain on." So it's a way for individuals who have added things to this to add a little bit more detail. Then using Trello as voting functionality, we each get a couple of votes, and we get to sprinkle them across different cards, and then using that now allows us collectively to prioritize based on those votes. And so the things that get voted up to the top we talk about; we prioritize some amount of work coming into the sprint. +If it's actually going to turn into work, then it'll go onto the product board because ideally, it's moved from problem space to more of solution space even if the solution, the work to be done is do a spike on XYZ library or approach to form handling or whatever it is. But so ideally, it then moves on to the other board. +The other thing that I felt was important is it's very easy for this to be a dumping ground for ideas. So my suggestion is at the end of the meeting, we sort by date, and we prune the oldest things. So it's like, if it's still hanging around and we haven't done it yet, and it's not getting voted up, then yes, we might feel some pain but not enough. It's not earning its place on this board. So that's my hope is we're weeding the Brussel sprouts garden that we have at the end of the meeting. +That's roughly what we have now. We really only had the one, so that idea of pruning will probably come in later on. And it may be that this doesn't work out at all, and this ends up being tech debt cards that get stale and don't capture the truth. But I'm hopeful because there's definitely...there's a conversation to be had here. It's just whether or not we can make sure that conversation is useful and capturing the right amount of context and at the right points in time and all of that. +STEPH: Yeah, I like it. I like the whole process you outlined. You know what it made me think of? It sounds like a technical retro, not that retros can't be technical; we bring up technical stuff all the time. But this one sounds like there was more technical discussion that was still looking for space to bring up. So the way that you mentioned that people add their thoughts, that it can be done async, and then you vote up, and then as things get stale, you remove them and focus on the things that the team voted for, that's really cool. I've never thought of having just a technical-specific retro. +CHRIS: Yeah, definitely informed by retro. But again, just that slight honing the specific focus of this is just the dev team chatting about deeply dev-y things and making a little bit of space for that. I think the difficulty will be does this encourage us to work on this stuff too much? And that's the counterbalance that we have to have because this work can be critically important. +But it can also be a distraction from features that we got to ship or bugs that are in the platform or other things like that. So that balancing act is something that I'm keeping in mind, but thus far, the way we structured it, I'm hopeful. And I'm interested in exploring it more, so we'll see where we get to. And I'll certainly report back as we refine the Crispy Brussels Snack Hour over time. +STEPH: I feel like the opposite is true as well, where you have these types of concerns and things that you want to bring up. And even if they're on the board, once you get to sprint planning, there's a lot of context and conversation there that maybe the whole team doesn't have. It doesn't feel like the right moment to dive into this because you're trying to plan a new sprint. +So then that stuff gets bumped down to the bottom or just never really discussed, or it gets archived. So I feel like the opposite is totally true, too, where you have this stuff, but then it never gets talked about because sprint planning is not the right place. So yeah, I'm really intrigued to see how that balance works out for y'all as well. +CHRIS: Yeah, I think it's an exciting time, and we'll see where it goes. But like I said, I'm hopeful on it. But yeah, bikes, triathlons, and crispy Brussels, that's my world. +Mid-roll Ad: +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: I have a couple of fun things that I want to share and then something that's a little more in the techie space. The first one is there's a delightful Twitter thread that caught my attention recently that I just want to share; totally not tech-related. But this person shared a thread talking about how they help everyone on their team who's older than they are, making sure that the slang that they're using is correct in its context. And so they provided some funny examples. +And then, in return, they also will translate this person's frustrations into professional corporate-speak, and it's such a good thread. So if you need a good laugh, I will make sure to include a link in the show notes. The slang is really funny, but it's actually the translation of frustrations into professional corporate-speak that that's the part that resonated with me. That was really good. [laughs] +CHRIS: You shared this with me outside of this conversation, and I've read through them. Listeners out there, do not sleep on this. I highly suggest reading through this thread because it is fantastic. +STEPH: The other thing that I saw is Andrea Fomera, who is a Rails developer and creates a fair amount of content...I haven't been through some of that content, but I know there's content around Rails. And specifically, there is a newer course called Learn Hotwire by Building a Forum. And she has made this totally free, and I just think that is so cool. +And she shared that on Twitter, so I'll be sure to include a link in that to the show notes because Hotwire is something I haven't used yet. And so I saw this free course, and I think it would be fun to dabble and go through the course. And I know there are some other people at thoughtbot that have used it and seem really happy with it or interested in using it as well. Is that something that you've used? +CHRIS: I have not. I skipped over Hotwire in my adventures. I'd found Inertia and was quite happy with that. And then, in that way that, I sometimes limit the amount of things that I'm allowed to explore on the internet in hopes of actually getting some work done; I have not spent much time. +But enough folks that I deeply respect are very excited about Hotwire that it remains in the like; I would love to have an afternoon just to poke around with that. So I may take a look at this, although I don't know, I'm probably still in my moratorium. I'm not allowed to look at new frameworks for a little while time period. But I hear great things. +STEPH: That's fair. That's also what I've heard. I've heard great things. So yeah, I just figured I would share that in case anybody else is interested in looking for a course that they could take and also dabble at Hotwire. +The other thing that's on my mind is more the type of projects that I'm really getting a lot of joy from. Because I've known about myself for a while that greenfield projects are nifty, but they're not my thing. They're not the thing that brings me a lot of joy. It's just kind of nice. You got your own space, and you're building from the ground up, cool, cool, cool. +But this one, I found that the projects that I’m really starting to gravitate towards are what I've heard someone else call Rails Rescue projects. So those are the projects where they have been around for a while, or they've just been built in a way that the data modeling structure makes it really hard to implement new features. Maybe there's a lack of test coverage that makes it really risky to ship new work or to make changes. There are lots of bug reports and errors that the team is fighting with. +So then that type of work comes down to where you're trying to either increase stability for the application and for users and/or you're looking to increase developer acceleration. And I really, really liked those projects. That's the type of project that I've been a part of for...I think my last couple of clients have been in that way. I don't know that they would describe it that way, that it's a Rails Rescue project. +But if I can see that opportunity where I see there's a stability issue or developers are feeling a lot of pain in one area, then that's the portion of the application, the portion of the team that I'm going to gravitate towards. Or like the current work that I'm doing where we're really focused on testing and making some improvements there or reducing that pain that the team is feeling around how long CI takes to run or the flakiness because then you're having to re-verify your CI runs. +I like that work. It's a bit slow and frustrating, so it does seem to require a patient person. You also have to have lots of metrics that are guiding you because you can have a lot of assumptions around I'm going to make this improvement, but it's going to take effort to get there. And it'd be great if I can validate that effort upfront. So I feel like a lot of my time is spent more around metrics, and data, and excel sheets than necessarily coding. I don't know if that's great, but it's part of the work. There's a balance there. So I just found that interesting. +I don't think I would have thought this is something I was interested in until now that I've been on these projects for a while. And I've started noticing a theme where I really enjoy them. Although I realize looking back at former Stephanie days when I was going through Launch Academy and learning to code, I really thought I wanted to be in DevOps. DevOps seemed like the cool kids’ corner. They knew how the internet worked. They knew what was happening. They were making it live. And I just thought it seemed really cool. For the record, it is still a cool kids’ corner. +But I have also learned that the work-life balance isn't great with DevOps because you just never know when you're going to be on call. And that really stood out to me as something that I didn't want to do. And I do like building some features. But essentially, it's that developer acceleration that I really liked because they were the ones that were coming and often building tools and making it easier for then people to then ship their code and get it out into the world and triage. +And so I liked the fact that their users were developers versus the people using the application as much, although, I guess, technically both. But the people they were often striving to help the most was the internal team, and that resonated with me. So I guess I have eventually found my way into that space. It wasn't through DevOps, but it is now through this idea of projects that need some rescuing. +CHRIS: I love that you've spent enough time now to figure out what it is that draws you in the work and the shape of projects that is meaningful to you. Interestingly, I find myself not on the opposite side of things...you know, we're always looking for a disagreement, and this isn't a disagreement, but this is a thing on which we differ a surprising amount because I do like the early-stage stuff, the new, the breaking ground, all of that exciting whatnot. +But how do I not make this a more complicated statement? I appreciate that you have the point of view that you do. I think the world needs more of what you're doing than the inclination that I have, like; I want to start something bright, and fresh, and new, and I can see so much progress immediately in front of me. And this is amazing. But the hard, meaningful work like maintenance, and support, and legacy, and rescue where necessary is such a critical aspect of the work. +I see this in open source so often where there are people who are like; I made an open-source project; this is great. I hacked for a bunch of weekends, and look; I made a thing. And then the support burden builds up. And open source can be this wildly undervalued thing overall. And the maintenance of open source is even more so, and you have this asymmetry between the people that are using it and don't think that their voice is one of the thousands that are out there requesting a new feature or anything like that. +The handful of people that I see out there in the world that come along later in the lifespan of an open-source project and just step in to do maintenance, my goodness, is that heroic work, just quiet, necessary heroic work. And what you're describing feels sort of similar but at the project level. And I don't know; I'm sort of like silent. I'm out loud on a podcast, not silently at all judging myself because I'm like, I feel like you're doing the thing over there. That seems like a good thing. But I also like my early projects... [laughs] +STEPH: I think they're...I mean, we need each other. I need you to start the code, and the applications for them to then need some help down the road [laughs] to [crosstalk 24:30]. +CHRIS: But I need to do a bad enough job that we have to be rescued by you. +STEPH: [laughs] +CHRIS: Hey, don't you worry, friend, I'm doing a terrible...no, I think I'm doing an okay [laughter] job. Hopefully, I'm avoiding those traps, but it's hard to know when you're writing legacy code, you know. +STEPH: It is hard for the reasons we were talking about earlier. Like, those technical discussions build-up, and then if you don't really have a space to then address it, then it just keeps getting sidelined until you suddenly get to this point of it's either we come to a grinding halt because we can't ship work, or we find ways to start bringing this into our process. +And so that's the other part of the Rails Rescue projects is often looking at the team's process and figuring out, okay, instead of hiring consultants to come in and then try to help with this, how else can they also integrate this into their own project? So then, once thoughtbot lives, they now have ownership of this, and they can carry it forward as well. +There is an aspect of this work that I'm still working on, and it comes around to the definition of work because if you go into a team or a project that's like, hey, we really need help with X. We really need help with addressing all these errors. Or we really need help improving developer happiness or getting test coverage in place. Finding out exactly how you're going to tackle that, are you going to join a team of the other developers? +Like, are you looking for more of a mentorship? Like, hey, we're going to work alongside your team to then mentor them to then bring this into their own process and their own habits, so then they feel empowered to address this in the future. Are we doing this more as a triage where then we have a specific goal or two that then we're going to meet? And then once we get stuff out of this on fire state, then maybe we start pairing with other people. Or are we going to work closely with the people who are fighting fires with the bug reports and the errors? +There are a bunch of different ways that you can tackle that. And I think it really helps define the success of that engagement and then your outcomes because otherwise, I feel like you can get distracted by so much. Because there's so much that's going to try to get your attention that you want to work on and fix. So you have to be very upfront about there are different areas that we can work on. Let's figure out some metrics together that we're really going after to then help define what does success look like for this first iteration of our work? +And then what's the long-term plan for this work? Then how do we keep it going forward? How do we empower the team to keep this work going forward? And that's an area that I've learned just from trial and error from being part of these projects. And I'm very interested in still cultivating that skill and figuring out what's the area that we're focused on? +CHRIS: There's something that you said in there that I want to hone in on, which is the idea of you've learned from going on so many of these different projects, and you're carrying forward ideas that you have. But I think more generally, there's something interesting in what you were just saying there around you've worked on a bunch of different projects at different organizations with certain things that they were great at, with certain things that they struggled with at different sizes. And you're able to bring all that experience to bear on each project. +But I think also taking a step back, as you were describing, you're like, I think I've figured out what it is that I like and the type of projects that I want to do. I cannot say enough good things about working in a consultancy for a while because, my goodness, you get to try out a bunch of different stuff. And A, you get to learn a ton about how to do the work, and how to communicate, and different technologies and all of that. But you also get to figure out what it is that you might want to double down on and lean into in terms of the work. That's definitely a big part of my story. +Seven years at thoughtbot, I tried a lot of different stuff, worked at a lot of different companies. And I would describe it as I found a lot of things that I didn't want. And then there's that handful of things that I really did want, and I was able to then more intentionally pursue that. So for anyone out there that's considering it, working at a consultancy is fantastic, or at least it has fantastic elements to it. +It also can be complicated as you talk about finding organizations and having to, you know, if you're brought in for a certain job, but when you get there, you're like, "Ooh, I know you want me to fix bugs, but actually, I think I just need to work with your team because they're the ones writing the bugs. And why are they writing the bugs" "Well, because the salespeople are selling things, and then we have timelines." Like, we got to start at the very top of this whole pyramid and fix it. And so it can be very complicated. But there's so much that you can learn about yourself in the process, in the work, and I adored that portion of my career. +STEPH: Yeah, I totally agree. Anytime someone mentions, they're like, "Oh, consultancy work. What's that like?" And I remember it was a couple of years ago I mentioned I was working for a consultancy, and they were like, "Oh, you must travel a lot." I was like, "No, [laughter] I stay put. I just work from an office in Boston." But I remember that caught me off guard because I hadn't considered that I was supposed to travel, but that makes sense that you think of consultants that travel. +But when I meet people or talk to people, and they're like, "Oh, you've been at thoughtbot for five-plus years, and how's that going? And what's it like to be at a consultancy?" And exactly what you just said, it's the variety that I really like and getting to try on so many different hats and see how different teams and processes work and then identify like, oh, that worked really well for that team, or this isn't working well for that team. I have really enjoyed that. +And it can be a roller coaster because you have to get really good at onboarding. You have to go through that initial phase of like; I swear I'm smart. I will get up to speed quickly, and I will learn things. But it's a period that you just have to go through with each team that you join, but you do it twice a year, maybe three times a year. And so you get comfortable with that over time. +So there are definitely some challenges that then have to fit your personality and things that work for you and bring you joy. And I completely understand that it's not for everybody, just kind of I really enjoy product work, but I also really enjoy being able to move around to different teams and help folks. +CHRIS: I love the idea that as a consultant, your job is to just walk through airports and high-five every Accenture billboard in it and just go up to the wall and pay your respects. But no, no, that is not our version of consulting. [laughs] +STEPH: That's why I have so much time for The Bike Shed. It's because I'm just, you know, I'm in different airports high-fiving signs. And then this is my real job; Bike Shed is my real job. +CHRIS: Oh, that would be fun. +STEPH: [laughs] You know, I have such a fondness of Bike Shed that now something interesting has happened where someone was like, "Oh, you're bike-shedding." And they're not being mean, but they're just like, "Oh, we're totally bike-shedding," or "This is dissolving into bike-shedding." And I'm like, oh, bike-shedding, hooray. And I'm like, oh, wait, bad. [laughter] And I have to catch myself each time. +CHRIS: Yeah, we've taken away a lot of the meaning. Well, I mean, have we or do we live up to it every single week? Who can say? But I, too, have a fondness for this phrase, perhaps not aligned with what it is actually meant to signify. +STEPH: On a slightly different tech-related note, there is a gem that I'm really excited to check out. I saw it mentioned on the paralleltests gem, which is what helps you run your tests in parallel, and it's what we're currently using. But you can group your tests in different ways. And right now, we're using the runtime strategy where essentially then we use the output from RSpec where we know how long each file took to run. And then paralleltests will then use that data to then figure out, okay, how should I split up your test file? So then try to balance them as evenly as possible. +We're at that point, though, where we've talked about tentpoles, so we have certain files that, say, take 10 minutes; other files will only take two minutes. And that balance is really throwing off our ability to then bring down the CI build time. So on paralleltests, there's reference to another gem called parallelsplit_test, where then you can run multiple test scenarios that are in one file but then split them out across different processes or different machines. And that is exactly what I want in my life right now. +I haven't checked it out yet, so I feel like I'm giving a daily sync update of like, I'm going to go off and explore this thing. I will report back and see how it goes. [laughs] In the past, I usually try to say, "I've tried this thing, and this is how it went," nope, opposite today. I am sharing the thing I'm going to try, and then hopefully, it goes well. +CHRIS: Well, either way, we should definitely report back. That's the truth. I like that you're leading us into this and giving us a preview. But then yeah, we'll see where we get to. That does sound like the thing you want, though. So I hope it goes well. +STEPH: Yeah, we've learned at this point where we are splitting work across different machines that until we address some of those tentpole concerns, adding more machines won't help us because then a machine's going to run as long as the longest file. So we've been doing some manual work to split up those files. That's not the best, but it does help you see some results. So then, at least you know you're making progress. +So now we really need to find a way to automate that because we don't want someone to have to manually figure out where are the tentpoles, split those files up, commit that, and then keep track of, like, do we have another tentpole on the horizon? We really need a gem or something to help us automate that process. So yeah, I will be happy to report back. +MIDROLL AD: +And now a quick break to hear from today's sponsor, Studio 3T. +When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. +And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. +You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free. +STEPH: Pivoting just a bit, we have a listener question. This question comes from Steve Polito. And Steve wrote in, "Longtime listener, first-time thoughboter." Yay. Yay is my addition. Anything that goes up in voice is probably my addition, [laughs] just so people know. All right, back to what Steve said. "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec? +Not only does Rails provide a fully functional test suite by default," looking at you Minitest, "but it's also well-documented and even provides the ability to run system tests. Rails is built on the principle of convention over configuration. And it seems odd to me that so many developers want to override such a fundamental piece of framework." Thanks in advance, [singing] Steve Polito. Steve, I hope it's okay I sang your name [laughs] because we're here now. +That is an awesome question. I'm going to give what may be less of an awesome answer which is, well, one; Steve highlights that people will then replace Minitest with RSpec. I haven't done that. I haven't actually gone into a project and said, "Okay, we need to replace your test suite and bring in RSpec instead." But if I'm starting out a project, I do have a heavy preference for RSpec, and frankly, that's just from experience. Like, that's what I was raised on, to say it in that way. [laughs] +RSpec is what I know; it's what I'm used to. It's what, even when I joined thoughtbot, was just the framework that we used for all of our testing and what we focused on so heavily. So frankly, for me, it's just a really strong bias. I know it's something that I'm really good at. I know it's something that works really well. I know it's well-documented. I know it's also very accessible for other people to use. +But actually replacing it on a different project, I don't think I would do that. I'd have to have a really strong reason, or maybe if we haven't actually started testing anything yet, to then replace it because that feels a bit aggressive to me. But then it just depends on the situation, I suppose. But yeah, overall, I just default to RSpec because that's what I'm accustomed to, and it's the testing framework that I know. +CHRIS: Yeah, I think my answer is largely the same. It's the thing that I've worked with by far the most. Similarly, I've been on projects that were using Minitest, and therefore I used Minitest because it's definitely not worth the effort to switch. But in a lot of...well, I will say this, I've much less experience, and this may be less true over time. But there were many things that drew me to RSpec, and that continues to be interesting to me in the RSpec world. +Even things as small as the assertion syntax, assertequal is the method that's, you know, this is how you do an assertion in Minitest, and it's assertequal expected, actual. That's the order of the arguments. It's expected first and then actual. That makes sense, probably with the expected, but I would get that wrong constantly. I do get that sort of thing wrong. They're just positional arguments that there's nothing about this that tells me which way to go. And so it's very easy to get failure messages that are inverted, and so it's just this tiny little thing. +But with RSpec, we end up with expect and then in parentheses, the thing that we are expecting to equal the other thing, and it just reads a little more honestly. It fits within the Ruby mindset in my world. I want my code to be as expressive as possible, and Minitest feels much lower level to me. It feels more, you know, assert as a word is just...I'm not asserting. That just feels so formal. And so these are, again, to be clear, very, very small things, but they all add up. +And there's a reason that we're using Ruby overall. And there's a reason that we're using Rails is this expressiveness is a big part of it for me, so I'll cling to that. I'll hold on to that as something that's true. Also, Rspec's mocking support, rspec-mocks as the library, I found to be really fantastic, and I've grown very comfortable working with it. And I know how and where to use that. +I also have so much built-up knowledge, like the idea of when to use let and not use let in RSpec. It's just this deep thing that I know about. I'm sure there's an equivalent in the Minitest world, but I would have to have a different understanding in argument, and that conversation would just feel different. +I think the other thing that's worth saying is this is a default for us at this point that I personally have not felt the need to reconsider. When I've worked on projects that have used Minitest, I certainly wasn't called to it. I wasn't like, oh, this seems really interesting; I'm going to lean into this more. I was like, I miss RSpec. And some of that is, again, just familiarity. But at the end of the day, we only have so much time to do things. And so, I firmly stand by my not reconsidering my testing option at this point. +Like, RSpec does the things that I want. It does it really well. Critically, I'm able to build a system and write a test suite and maintain that test suite over time and have it tell me the truth as to whether or not my application should be deployed to production. That is the measure. That's the thing that I care about. I think it's maybe a little bit slower than Minitest, but I'm fine with that. I have solutions to that problem. +And the thing that I care about is when the test suite is green, do I feel confident deploying? RSpec has helped me for years on that journey. And I've never questioned whether or not I should go back to the drawing board and revisit that consideration. So initially, it was probably because it was the thing that we were all using, and then that is for me why it has stuck around. And I love RSpec. I think how many episodes have we just said, "Thanks, RSpec," as a little aside? So we do love it in a deep way. +STEPH: Probably not enough episodes have we said that. [laughs] Yeah, I like what you said where you haven't felt the need to switch over or to move away from RSpec. And I wonder, looking back at some of the earlier projects that I joined that were using RSpec, I don't know if maybe they chose RSpec at that time because RSpec had more of those features built-in, and Minitest was still working on those. Maybe they were parallel at the time; I'm not sure. +But I like what you said about you just haven't had a need to go back and change. At this point, if I switched over to Minitest, it would definitely be a learning curve for me, which is totally fine. But yeah, I'm just happy with it, so I stick with it. +And I also appreciate that idea that, yeah, unless you're new in a project, I wouldn't encourage someone to then switch over to something else unless I feel like there's just a lot of pain for some reason with the current testing setup. There has to be a reason. There has to be a drive. It can't be just a personal bias of like, I know this thing, so I want to use it. There's got to be a better reason that benefits the whole team versus just a personal preference. +But overall, I think it comes down to for us; it's just a choice because it's the familiar choice. It's the one that we know. But I think Minitest and RSpec are both so widely supported. I was thinking about that convention over configuration. And yes, Rails ships with Minitest, but RSpec is so common that I don't feel like I'm breaking convention at that point. They're both so widely supported and used that I feel very comfortable going with either option. And then it's just my personal preference for RSpec. +So thanks, Steve, for sending in that question. And for anyone else that has a question that you would love to share with Chris and I, you can reach us in a couple of different ways. You can reach us on Twitter via @_bikeshed. You can also go to the website, bikeshed.fm/content. We will drop some links in the show notes. But if you go there, then you can send a question or also email us directly at hosts@bikeshed.fm. +And we're running a little low on listener questions, so we would love to have a listener question from you. And we would love to talk about anything that y'all want to talk about, okay, within reason, you know, triathlons, Brussel sprouts, things like that. All of that falls within the wheelhouse. +CHRIS: Normal stuff. +STEPH: Normal stuff, yeah. +CHRIS: And to be clear, despite the fact that Steve did recently become a thoughtboter, you don't have to be a thoughtboter to send in a listener question. [laughs] In fact, it's much more common to not be a thoughtboter when sending in a listener question. But we'll take them from anybody. We're happy to chat with you. +STEPH: On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris got a bike. Specifically, he bought a bike to use in a triathlon he signed up to participate in. Now he needs to name the bike, and speaking of naming things, a more technical topic that he talks about is the Crispy Brussels Snack Hour.

+ +

Steph talks about Rescue Rails projects and increasing developer acceleration.

+ +

They answer a listener question asking, "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?"

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Translate frustrations into professional corporate
+Learn Hotwire by Building a Forum
+parallel_tests
+parallel_split_test

+ +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Oh, but I recently learned that Robert Downey Jr. in the Marvel movies he's snacking a lot, maybe not Iron Man, but something...oh no, he's stacking a lot. And I'd read that he was snacking a lot on set, and so they just built it in to where like, sure, you can snack as your character while you're doing stuff.

+ +

CHRIS: [laughs]

+ +

STEPH: And I think that's so cool because I find that I am eating every time I show up to record with you. So I would like the same special star treatment as Robert Downey Jr., [laughs] and I just get to eat during each Bike Shed. [laughs]

+ +

CHRIS: All right. [chuckles] My understanding is also that he was wildly the highest paid of all the actors, so I think that should also come along with this.

+ +

STEPH: [laughs]

+ +

CHRIS: Yeah, there's a lot that we can sort of layer on here, but it makes sense to me, and I'm fully on board.

+ +

STEPH: You're an excellent agent. Thank you for fighting for my higher pay.

+ +

[laughter]

+ +

CHRIS: You are welcome.

+ +

STEPH: What a good co-host you are.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. One of these days, I'm going to say, "I'm Chris Toomey," and then I'm just going to see how you roll with it, although now I'm ruining it, I should have just gone for it. [laughs]

+ +

CHRIS: Nothing can prepare me for this despite the fact that you're telling me in this moment. In that future moment when you do it, I will still be completely knocked out of whack. Just like for anyone out there listening, the thing that Steph would normally have said instead of what [laughs] she just said was, "What's new in your world?"

+ +

STEPH: [laughs]

+ +

CHRIS: And I contractually require that that is the only way she starts this question to me because I get completely lost. She's like, "How are you doing?" I just overthink it, and I get lost, and then we end up in a place like this where I'm just rambling.

+ +

STEPH: Every podcast contract you have from here on out must begin with hey, Chris, what's new in your world? [laughs] I will still get to that question. I just also had to tell you my future joke. I'm going to play that. Hopefully, you'll forget, and one day I will resurface.

+ +

CHRIS: I can pretty much promise you that I'm going to forget it.

+ +

[laughter]

+ +

STEPH: Excellent. Well, to make sure I stick within the Chris Toomey contract guidelines, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Now I just want to spend a lot of time putting together my rider. There can be no brown M&M's in the bowl. No eye contact, please. And I can only be addressed with this one question which is, to be clear, very not true, Steph. And I always record with a video because we actually like to have human faces attached to things. Anyway, I'm going to tighten this all up. When we get to the technical segment of my world, I'm going to tell you about Crispy Brussels Snack Hour, so just throwing that out there as an idea.

+ +

But before we do that, I'm going to share a fun little thing which is I bought a bike, which is exciting. It's not that exciting. People have bikes. This is exciting for me. But the associated thing that is more exciting/a little terrifying is I'm going to try and run a triathlon. I'm going to try and run, swim, and bike a triathlon as they go, specifically a sprint triathlon for anyone out there that's listening and thinking, oh wow, that sounds like a thing. The sprint is the shortest of the distances, so that's what I'm going to go for. But yeah, that's a thing that I'm thinking about in my world now.

+ +

STEPH: I know next to nothing about triathlons. So what is a sprint in terms of like, what is the shortest? What does that mean?

+ +

CHRIS: I think there actually maybe even shorter distances but of the common, there's sprint, Olympic. I want to say half Ironman, and then Ironman are the sequence. And an Ironman, as far as I understand it, I think it's a full marathon. It's like a century bike ride or something like that. It's an astronomical amount of everything.

+ +

Whereas the sprint triathlon being the shortest, I think it's a 3.6-mile run, so a little over a 5K run, a 10-mile bike ride, and a quarter-mile swim, I want to say, something like that. But they're each scaled down to the rough equivalent of a 5K but in each of the different events. So you swim, and then you bike, and then you run.

+ +

And so I'm going to try that, or at least I'm going to try to try. It's in September, and now is not September. So I have a lot of time between now and then to do some swimming, which I haven't done...like, I've swum but not in a serious way, not in an intentional way. So I got to figure out if I still know how to swim, probably get better at biking, and do a little bit of running, and it's going to be great. It's going to be a lot of fun. I'm super excited about it. Only a little terrified.

+ +

STEPH: I think this is where as your co-host coach, which you have not asked me to be, where I would say something about there is no try, to mimic Yoda. [laughs]

+ +

CHRIS: Yep, yep. Yep. Do or do not. Sprint or sprint not. There is no trying. Oh, were you making a try pun there?

+ +

STEPH: I didn't go that far, but you just brought it home. I see where you're going. [laughs]

+ +

CHRIS: This is pretty much what I do professionally is I just take words, and I roll them around until I find something else to do with them. So glad that we got there together.

+ +

STEPH: Well, I'm really excited to hear about this. I don't know anyone that's trained for a triathlon. I think that's true. Yeah, I don't think I know anyone that's trained for a triathlon. So I'm curious to hear about how that goes because that sounds intense, friend.

+ +

CHRIS: I think so. None of the individual segments sound that bad but stitching them all together, and I think the transitions are some of the tricky parts there. So yeah, it'll be fun. It's something I find...I used to never run; that was the thing. Like, deeply true in my head was that I'm not a runner. This is just a true fact about me. And then I ran a 5K one year for...it was like a holiday 5K fun run with friends. And every bit of the training leading up to it was awful. I did Couch to 5K. I hated it.

+ +

My story in my head of I'm not a runner was proven with every single training run. Man, did I hate it. And then something magical happened on the day that I actually ran the race, and it was fun. And I was out there, and there was the energy of being in this group of people. But it was competitive and not competitive in this really interesting way. And then it ended, and we were just hanging out in a parking lot, and they gave us beer. And I was like, well, this is actually delightful. Maybe I actually like this thing.

+ +

And so I've run a bunch of different races. And I've found that having a race to train for, and by train, I just mean some structured attempt at running, has been really enjoyable and useful for me. So yeah, this is just ratcheting that up a tiny bit. I've done a couple of half marathons is the high watermark so far. It's a good distance. But I don't know that a full marathon makes sense; that's a real commitment. And I'm looking to move laterally rather than just keep getting more complex in my running. So we're trying the shortest possible triathlon that I know of.

+ +

STEPH: I am such a believer that exercise should be fun, so I love that. Like, I'm not a runner, but then you get around people, and it's exciting. And then there's that motivation, and then there's a fun ending with beers that totally jives with me. Because sure, I can go to the gym; I can lift weights, I can make myself exercise. There's some fun to it.

+ +

But I strongly prefer anything that's more of like a sport or group exercise; that's just so much more fun. Well, super cool. Well, I'm excited. I would ask you all the details about your bike, but I know nothing. Do you want to share details about your bike? There may be other people that are interested.

+ +

CHRIS: Oh yeah, my bike. I went to the bike store, and I said, "Could I have a bike, please?" And then they toured me around and showed me all the fancy...they were like, "This is our most modest entry-level bike." And then they kept walking around and showing me fancier bikes. And I was like, "Can we go back to that first one? That one seemed great."

+ +

STEPH: [laughs]

+ +

CHRIS: Because it got all of the checkboxes I was looking for, which is basically it's a bike. So actually, the specifics on it are it's a hybrid bike, so like a mix between road, and I don't even know the other road bikes I know of, and maybe it's trail. But I don't think it's meant for going on the trail. But for me, it'll be fine for what I'm trying to do as far as I understand it.

+ +

It's technically a fitness hybrid, which I was like, oh, fancy. It's a fitness bike; look at me go. But it was basically just like, I would like a bike. General-purpose hybrid seems like the thing that makes sense. So I got a hybrid bike. And that's where I'm at. Oh, and I got a helmet because that seems like a smart move.

+ +

STEPH: Nice. Yeah, the bike I own is also one of those hybrids where it's like…because when I moved to Boston...and lots of people have the road bikes, but their tires are just so skinny; it made me nervous. And so I saw one of the hybrid bikes, and I was like, that one. That looks a little more steady and secure, so I went with that one even though it's heavier. Do you have a name for your bike? Are you going to think of a name for your bike?

+ +

CHRIS: I didn't, and I wasn't planning on it. But now that you've incepted me with this idea that I have to name my bike, of course, I have to name my bike. I'm going to need a couple of weeks to figure it out, though. We're going to have to get to know each other. And you know, something will become true in the universe for me to answer that question. But as of so far, no, I do not have a name for the bike.

+ +

STEPH: Cool. I'll check back in. Yeah, it takes time to find that name. I feel you.

+ +

CHRIS: [laughs] Yeah, don't make up a name. I have to find what's already true and then just say it out loud. Speaking of naming things and perhaps doing so in a frivolous way, as I mentioned earlier, the more technical topic that I want to talk about, oddly, is called Crispy Brussels Snack Hour. [laughs] So, within our dev team, we have started to collect together different things that don't quite belong on the product board, or at least they're a little more confusing. They're much more technical.

+ +

In a lot of cases, they are...our form handling is a little rough. And it's the sort of thing that comes up a lot in pull requests where we'll say, "I feel like this could be improved." And we're like, "Yeah, but not in this pull request." And so then it's what do you do with that? Do you put a tech debt card in the product board? You and I have talked about tech debt cards plenty of times, and it's a murky topic.

+ +

But we're trying within the team to make space and a way and a little bit of process around how do we think about these sorts of things? What are the pain points as a developer is working on the system? So to be clear, this isn’t there is a bug because bugs we should just fix; that's my strong feeling, or we should prioritize them relative to the rest of the work. But this is a lower level. This is as a developer; I'm specifically feeling this sort of pain.

+ +

And so we decided we should have a Trello board for it. And they were like, "Oh, what should we name the Trello board?" [laughs] And I decided in this moment I was like, "You know, if we're being honest, I've named everything very boring, very straight up the middle. We don't even have that many things to name. So we have zero frivolous names within our team. I think this is our opportunity. We should go with a frivolous name. Anybody have any ideas?"

+ +

And someone had worked on a team previously where maybe it was a microservice or something like that was called crispy Brussels, like, crispy Brussels sprouts but just crispy Brussels. And so I was like, "Sure, something like that. That sounds great." And then they ended up naming it that which was funny, and fun, and playful in and of itself.

+ +

But then we were like, "Oh, we should have a time to get together and discuss this." So we're now exploring how regularly we're going to do it. But we were like, let's have a meeting that is the dev team getting together to review that board. And we were like, "What do we call the meeting?" And so we went around a little bit, but we ended with the Crispy Brussels Snack Hour.

+ +

STEPH: That's delightful. I love the idea of onboarding new people, and they just see on their calendar it's Crispy Brussels Snack Hour, come on down. [laughs]

+ +

CHRIS: It's also got an emoji Brussel sprout and an emoji TV on either side of the words Crispy Brussels Snack Hour. So it's really just a fantastic little bit of frivolity in our calendars.

+ +

STEPH: [laughs] That's delightful. How's that going? I don't think we've tried something like that explicitly in terms of, like you said, there are discussions we want to have, but they're not in the sprint. They're not tech debt cards that we want to create because, like you said, we've had conversations. So yeah, I'm curious how that's working for you.

+ +

CHRIS: Well, so we've only had the one so far; it went quite well. We had a handful of different discussions. We were able to relatively prioritize this type of work within that. But one of the other things that we did was we had a conversation about this process, about this meeting, and the board. And whatnot.

+ +

So we identified a couple of rules of the road or how we want to approach this that I think will hopefully be useful in trying to constrain this work because it's very easy to just like; nothing's ever perfect. And so this could very easily be a dumping ground for half-formed ideas that sound good but aren't necessarily worth the continued effort, that sort of thing.

+ +

So the agenda for the meeting as described right now is async between meetings. Any of us can add new cards, ideally stated as problems and not solutions. So our form handling could use improvement. And then in the card, you can maybe make a suggestion of I think we could use this library or something like that. But rather than saying use this library or move to this library, we frame in terms of the problem, not necessarily the solution.

+ +

And then, at the start of the meeting, any individual can champion a card so they can say, "Here's the thing that I really want everyone to know about that I've been feeling a lot of pain on." So it's a way for individuals who have added things to this to add a little bit more detail. Then using Trello as voting functionality, we each get a couple of votes, and we get to sprinkle them across different cards, and then using that now allows us collectively to prioritize based on those votes. And so the things that get voted up to the top we talk about; we prioritize some amount of work coming into the sprint.

+ +

If it's actually going to turn into work, then it'll go onto the product board because ideally, it's moved from problem space to more of solution space even if the solution, the work to be done is do a spike on XYZ library or approach to form handling or whatever it is. But so ideally, it then moves on to the other board.

+ +

The other thing that I felt was important is it's very easy for this to be a dumping ground for ideas. So my suggestion is at the end of the meeting, we sort by date, and we prune the oldest things. So it's like, if it's still hanging around and we haven't done it yet, and it's not getting voted up, then yes, we might feel some pain but not enough. It's not earning its place on this board. So that's my hope is we're weeding the Brussel sprouts garden that we have at the end of the meeting.

+ +

That's roughly what we have now. We really only had the one, so that idea of pruning will probably come in later on. And it may be that this doesn't work out at all, and this ends up being tech debt cards that get stale and don't capture the truth. But I'm hopeful because there's definitely...there's a conversation to be had here. It's just whether or not we can make sure that conversation is useful and capturing the right amount of context and at the right points in time and all of that.

+ +

STEPH: Yeah, I like it. I like the whole process you outlined. You know what it made me think of? It sounds like a technical retro, not that retros can't be technical; we bring up technical stuff all the time. But this one sounds like there was more technical discussion that was still looking for space to bring up. So the way that you mentioned that people add their thoughts, that it can be done async, and then you vote up, and then as things get stale, you remove them and focus on the things that the team voted for, that's really cool. I've never thought of having just a technical-specific retro.

+ +

CHRIS: Yeah, definitely informed by retro. But again, just that slight honing the specific focus of this is just the dev team chatting about deeply dev-y things and making a little bit of space for that. I think the difficulty will be does this encourage us to work on this stuff too much? And that's the counterbalance that we have to have because this work can be critically important.

+ +

But it can also be a distraction from features that we got to ship or bugs that are in the platform or other things like that. So that balancing act is something that I'm keeping in mind, but thus far, the way we structured it, I'm hopeful. And I'm interested in exploring it more, so we'll see where we get to. And I'll certainly report back as we refine the Crispy Brussels Snack Hour over time.

+ +

STEPH: I feel like the opposite is true as well, where you have these types of concerns and things that you want to bring up. And even if they're on the board, once you get to sprint planning, there's a lot of context and conversation there that maybe the whole team doesn't have. It doesn't feel like the right moment to dive into this because you're trying to plan a new sprint.

+ +

So then that stuff gets bumped down to the bottom or just never really discussed, or it gets archived. So I feel like the opposite is totally true, too, where you have this stuff, but then it never gets talked about because sprint planning is not the right place. So yeah, I'm really intrigued to see how that balance works out for y'all as well.

+ +

CHRIS: Yeah, I think it's an exciting time, and we'll see where it goes. But like I said, I'm hopeful on it. But yeah, bikes, triathlons, and crispy Brussels, that's my world.

+ +

Mid-roll Ad:

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: I have a couple of fun things that I want to share and then something that's a little more in the techie space. The first one is there's a delightful Twitter thread that caught my attention recently that I just want to share; totally not tech-related. But this person shared a thread talking about how they help everyone on their team who's older than they are, making sure that the slang that they're using is correct in its context. And so they provided some funny examples.

+ +

And then, in return, they also will translate this person's frustrations into professional corporate-speak, and it's such a good thread. So if you need a good laugh, I will make sure to include a link in the show notes. The slang is really funny, but it's actually the translation of frustrations into professional corporate-speak that that's the part that resonated with me. That was really good. [laughs]

+ +

CHRIS: You shared this with me outside of this conversation, and I've read through them. Listeners out there, do not sleep on this. I highly suggest reading through this thread because it is fantastic.

+ +

STEPH: The other thing that I saw is Andrea Fomera, who is a Rails developer and creates a fair amount of content...I haven't been through some of that content, but I know there's content around Rails. And specifically, there is a newer course called Learn Hotwire by Building a Forum. And she has made this totally free, and I just think that is so cool.

+ +

And she shared that on Twitter, so I'll be sure to include a link in that to the show notes because Hotwire is something I haven't used yet. And so I saw this free course, and I think it would be fun to dabble and go through the course. And I know there are some other people at thoughtbot that have used it and seem really happy with it or interested in using it as well. Is that something that you've used?

+ +

CHRIS: I have not. I skipped over Hotwire in my adventures. I'd found Inertia and was quite happy with that. And then, in that way that, I sometimes limit the amount of things that I'm allowed to explore on the internet in hopes of actually getting some work done; I have not spent much time.

+ +

But enough folks that I deeply respect are very excited about Hotwire that it remains in the like; I would love to have an afternoon just to poke around with that. So I may take a look at this, although I don't know, I'm probably still in my moratorium. I'm not allowed to look at new frameworks for a little while time period. But I hear great things.

+ +

STEPH: That's fair. That's also what I've heard. I've heard great things. So yeah, I just figured I would share that in case anybody else is interested in looking for a course that they could take and also dabble at Hotwire.

+ +

The other thing that's on my mind is more the type of projects that I'm really getting a lot of joy from. Because I've known about myself for a while that greenfield projects are nifty, but they're not my thing. They're not the thing that brings me a lot of joy. It's just kind of nice. You got your own space, and you're building from the ground up, cool, cool, cool.

+ +

But this one, I found that the projects that I’m really starting to gravitate towards are what I've heard someone else call Rails Rescue projects. So those are the projects where they have been around for a while, or they've just been built in a way that the data modeling structure makes it really hard to implement new features. Maybe there's a lack of test coverage that makes it really risky to ship new work or to make changes. There are lots of bug reports and errors that the team is fighting with.

+ +

So then that type of work comes down to where you're trying to either increase stability for the application and for users and/or you're looking to increase developer acceleration. And I really, really liked those projects. That's the type of project that I've been a part of for...I think my last couple of clients have been in that way. I don't know that they would describe it that way, that it's a Rails Rescue project.

+ +

But if I can see that opportunity where I see there's a stability issue or developers are feeling a lot of pain in one area, then that's the portion of the application, the portion of the team that I'm going to gravitate towards. Or like the current work that I'm doing where we're really focused on testing and making some improvements there or reducing that pain that the team is feeling around how long CI takes to run or the flakiness because then you're having to re-verify your CI runs.

+ +

I like that work. It's a bit slow and frustrating, so it does seem to require a patient person. You also have to have lots of metrics that are guiding you because you can have a lot of assumptions around I'm going to make this improvement, but it's going to take effort to get there. And it'd be great if I can validate that effort upfront. So I feel like a lot of my time is spent more around metrics, and data, and excel sheets than necessarily coding. I don't know if that's great, but it's part of the work. There's a balance there. So I just found that interesting.

+ +

I don't think I would have thought this is something I was interested in until now that I've been on these projects for a while. And I've started noticing a theme where I really enjoy them. Although I realize looking back at former Stephanie days when I was going through Launch Academy and learning to code, I really thought I wanted to be in DevOps. DevOps seemed like the cool kids’ corner. They knew how the internet worked. They knew what was happening. They were making it live. And I just thought it seemed really cool. For the record, it is still a cool kids’ corner.

+ +

But I have also learned that the work-life balance isn't great with DevOps because you just never know when you're going to be on call. And that really stood out to me as something that I didn't want to do. And I do like building some features. But essentially, it's that developer acceleration that I really liked because they were the ones that were coming and often building tools and making it easier for then people to then ship their code and get it out into the world and triage.

+ +

And so I liked the fact that their users were developers versus the people using the application as much, although, I guess, technically both. But the people they were often striving to help the most was the internal team, and that resonated with me. So I guess I have eventually found my way into that space. It wasn't through DevOps, but it is now through this idea of projects that need some rescuing.

+ +

CHRIS: I love that you've spent enough time now to figure out what it is that draws you in the work and the shape of projects that is meaningful to you. Interestingly, I find myself not on the opposite side of things...you know, we're always looking for a disagreement, and this isn't a disagreement, but this is a thing on which we differ a surprising amount because I do like the early-stage stuff, the new, the breaking ground, all of that exciting whatnot.

+ +

But how do I not make this a more complicated statement? I appreciate that you have the point of view that you do. I think the world needs more of what you're doing than the inclination that I have, like; I want to start something bright, and fresh, and new, and I can see so much progress immediately in front of me. And this is amazing. But the hard, meaningful work like maintenance, and support, and legacy, and rescue where necessary is such a critical aspect of the work.

+ +

I see this in open source so often where there are people who are like; I made an open-source project; this is great. I hacked for a bunch of weekends, and look; I made a thing. And then the support burden builds up. And open source can be this wildly undervalued thing overall. And the maintenance of open source is even more so, and you have this asymmetry between the people that are using it and don't think that their voice is one of the thousands that are out there requesting a new feature or anything like that.

+ +

The handful of people that I see out there in the world that come along later in the lifespan of an open-source project and just step in to do maintenance, my goodness, is that heroic work, just quiet, necessary heroic work. And what you're describing feels sort of similar but at the project level. And I don't know; I'm sort of like silent. I'm out loud on a podcast, not silently at all judging myself because I'm like, I feel like you're doing the thing over there. That seems like a good thing. But I also like my early projects... [laughs]

+ +

STEPH: I think they're...I mean, we need each other. I need you to start the code, and the applications for them to then need some help down the road [laughs] to [crosstalk 24:30].

+ +

CHRIS: But I need to do a bad enough job that we have to be rescued by you.

+ +

STEPH: [laughs]

+ +

CHRIS: Hey, don't you worry, friend, I'm doing a terrible...no, I think I'm doing an okay [laughter] job. Hopefully, I'm avoiding those traps, but it's hard to know when you're writing legacy code, you know.

+ +

STEPH: It is hard for the reasons we were talking about earlier. Like, those technical discussions build-up, and then if you don't really have a space to then address it, then it just keeps getting sidelined until you suddenly get to this point of it's either we come to a grinding halt because we can't ship work, or we find ways to start bringing this into our process.

+ +

And so that's the other part of the Rails Rescue projects is often looking at the team's process and figuring out, okay, instead of hiring consultants to come in and then try to help with this, how else can they also integrate this into their own project? So then, once thoughtbot lives, they now have ownership of this, and they can carry it forward as well.

+ +

There is an aspect of this work that I'm still working on, and it comes around to the definition of work because if you go into a team or a project that's like, hey, we really need help with X. We really need help with addressing all these errors. Or we really need help improving developer happiness or getting test coverage in place. Finding out exactly how you're going to tackle that, are you going to join a team of the other developers?

+ +

Like, are you looking for more of a mentorship? Like, hey, we're going to work alongside your team to then mentor them to then bring this into their own process and their own habits, so then they feel empowered to address this in the future. Are we doing this more as a triage where then we have a specific goal or two that then we're going to meet? And then once we get stuff out of this on fire state, then maybe we start pairing with other people. Or are we going to work closely with the people who are fighting fires with the bug reports and the errors?

+ +

There are a bunch of different ways that you can tackle that. And I think it really helps define the success of that engagement and then your outcomes because otherwise, I feel like you can get distracted by so much. Because there's so much that's going to try to get your attention that you want to work on and fix. So you have to be very upfront about there are different areas that we can work on. Let's figure out some metrics together that we're really going after to then help define what does success look like for this first iteration of our work?

+ +

And then what's the long-term plan for this work? Then how do we keep it going forward? How do we empower the team to keep this work going forward? And that's an area that I've learned just from trial and error from being part of these projects. And I'm very interested in still cultivating that skill and figuring out what's the area that we're focused on?

+ +

CHRIS: There's something that you said in there that I want to hone in on, which is the idea of you've learned from going on so many of these different projects, and you're carrying forward ideas that you have. But I think more generally, there's something interesting in what you were just saying there around you've worked on a bunch of different projects at different organizations with certain things that they were great at, with certain things that they struggled with at different sizes. And you're able to bring all that experience to bear on each project.

+ +

But I think also taking a step back, as you were describing, you're like, I think I've figured out what it is that I like and the type of projects that I want to do. I cannot say enough good things about working in a consultancy for a while because, my goodness, you get to try out a bunch of different stuff. And A, you get to learn a ton about how to do the work, and how to communicate, and different technologies and all of that. But you also get to figure out what it is that you might want to double down on and lean into in terms of the work. That's definitely a big part of my story.

+ +

Seven years at thoughtbot, I tried a lot of different stuff, worked at a lot of different companies. And I would describe it as I found a lot of things that I didn't want. And then there's that handful of things that I really did want, and I was able to then more intentionally pursue that. So for anyone out there that's considering it, working at a consultancy is fantastic, or at least it has fantastic elements to it.

+ +

It also can be complicated as you talk about finding organizations and having to, you know, if you're brought in for a certain job, but when you get there, you're like, "Ooh, I know you want me to fix bugs, but actually, I think I just need to work with your team because they're the ones writing the bugs. And why are they writing the bugs" "Well, because the salespeople are selling things, and then we have timelines." Like, we got to start at the very top of this whole pyramid and fix it. And so it can be very complicated. But there's so much that you can learn about yourself in the process, in the work, and I adored that portion of my career.

+ +

STEPH: Yeah, I totally agree. Anytime someone mentions, they're like, "Oh, consultancy work. What's that like?" And I remember it was a couple of years ago I mentioned I was working for a consultancy, and they were like, "Oh, you must travel a lot." I was like, "No, [laughter] I stay put. I just work from an office in Boston." But I remember that caught me off guard because I hadn't considered that I was supposed to travel, but that makes sense that you think of consultants that travel.

+ +

But when I meet people or talk to people, and they're like, "Oh, you've been at thoughtbot for five-plus years, and how's that going? And what's it like to be at a consultancy?" And exactly what you just said, it's the variety that I really like and getting to try on so many different hats and see how different teams and processes work and then identify like, oh, that worked really well for that team, or this isn't working well for that team. I have really enjoyed that.

+ +

And it can be a roller coaster because you have to get really good at onboarding. You have to go through that initial phase of like; I swear I'm smart. I will get up to speed quickly, and I will learn things. But it's a period that you just have to go through with each team that you join, but you do it twice a year, maybe three times a year. And so you get comfortable with that over time.

+ +

So there are definitely some challenges that then have to fit your personality and things that work for you and bring you joy. And I completely understand that it's not for everybody, just kind of I really enjoy product work, but I also really enjoy being able to move around to different teams and help folks.

+ +

CHRIS: I love the idea that as a consultant, your job is to just walk through airports and high-five every Accenture billboard in it and just go up to the wall and pay your respects. But no, no, that is not our version of consulting. [laughs]

+ +

STEPH: That's why I have so much time for The Bike Shed. It's because I'm just, you know, I'm in different airports high-fiving signs. And then this is my real job; Bike Shed is my real job.

+ +

CHRIS: Oh, that would be fun.

+ +

STEPH: [laughs] You know, I have such a fondness of Bike Shed that now something interesting has happened where someone was like, "Oh, you're bike-shedding." And they're not being mean, but they're just like, "Oh, we're totally bike-shedding," or "This is dissolving into bike-shedding." And I'm like, oh, bike-shedding, hooray. And I'm like, oh, wait, bad. [laughter] And I have to catch myself each time.

+ +

CHRIS: Yeah, we've taken away a lot of the meaning. Well, I mean, have we or do we live up to it every single week? Who can say? But I, too, have a fondness for this phrase, perhaps not aligned with what it is actually meant to signify.

+ +

STEPH: On a slightly different tech-related note, there is a gem that I'm really excited to check out. I saw it mentioned on the parallel_tests gem, which is what helps you run your tests in parallel, and it's what we're currently using. But you can group your tests in different ways. And right now, we're using the runtime strategy where essentially then we use the output from RSpec where we know how long each file took to run. And then parallel_tests will then use that data to then figure out, okay, how should I split up your test file? So then try to balance them as evenly as possible.

+ +

We're at that point, though, where we've talked about tentpoles, so we have certain files that, say, take 10 minutes; other files will only take two minutes. And that balance is really throwing off our ability to then bring down the CI build time. So on parallel_tests, there's reference to another gem called parallel_split_test, where then you can run multiple test scenarios that are in one file but then split them out across different processes or different machines. And that is exactly what I want in my life right now.

+ +

I haven't checked it out yet, so I feel like I'm giving a daily sync update of like, I'm going to go off and explore this thing. I will report back and see how it goes. [laughs] In the past, I usually try to say, "I've tried this thing, and this is how it went," nope, opposite today. I am sharing the thing I'm going to try, and then hopefully, it goes well.

+ +

CHRIS: Well, either way, we should definitely report back. That's the truth. I like that you're leading us into this and giving us a preview. But then yeah, we'll see where we get to. That does sound like the thing you want, though. So I hope it goes well.

+ +

STEPH: Yeah, we've learned at this point where we are splitting work across different machines that until we address some of those tentpole concerns, adding more machines won't help us because then a machine's going to run as long as the longest file. So we've been doing some manual work to split up those files. That's not the best, but it does help you see some results. So then, at least you know you're making progress.

+ +

So now we really need to find a way to automate that because we don't want someone to have to manually figure out where are the tentpoles, split those files up, commit that, and then keep track of, like, do we have another tentpole on the horizon? We really need a gem or something to help us automate that process. So yeah, I will be happy to report back.

+ +

MIDROLL AD:

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free.

+ +

STEPH: Pivoting just a bit, we have a listener question. This question comes from Steve Polito. And Steve wrote in, "Longtime listener, first-time thoughboter." Yay. Yay is my addition. Anything that goes up in voice is probably my addition, [laughs] just so people know. All right, back to what Steve said. "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?

+ +

Not only does Rails provide a fully functional test suite by default," looking at you Minitest, "but it's also well-documented and even provides the ability to run system tests. Rails is built on the principle of convention over configuration. And it seems odd to me that so many developers want to override such a fundamental piece of framework." Thanks in advance, [singing] Steve Polito. Steve, I hope it's okay I sang your name [laughs] because we're here now.

+ +

That is an awesome question. I'm going to give what may be less of an awesome answer which is, well, one; Steve highlights that people will then replace Minitest with RSpec. I haven't done that. I haven't actually gone into a project and said, "Okay, we need to replace your test suite and bring in RSpec instead." But if I'm starting out a project, I do have a heavy preference for RSpec, and frankly, that's just from experience. Like, that's what I was raised on, to say it in that way. [laughs]

+ +

RSpec is what I know; it's what I'm used to. It's what, even when I joined thoughtbot, was just the framework that we used for all of our testing and what we focused on so heavily. So frankly, for me, it's just a really strong bias. I know it's something that I'm really good at. I know it's something that works really well. I know it's well-documented. I know it's also very accessible for other people to use.

+ +

But actually replacing it on a different project, I don't think I would do that. I'd have to have a really strong reason, or maybe if we haven't actually started testing anything yet, to then replace it because that feels a bit aggressive to me. But then it just depends on the situation, I suppose. But yeah, overall, I just default to RSpec because that's what I'm accustomed to, and it's the testing framework that I know.

+ +

CHRIS: Yeah, I think my answer is largely the same. It's the thing that I've worked with by far the most. Similarly, I've been on projects that were using Minitest, and therefore I used Minitest because it's definitely not worth the effort to switch. But in a lot of...well, I will say this, I've much less experience, and this may be less true over time. But there were many things that drew me to RSpec, and that continues to be interesting to me in the RSpec world.

+ +

Even things as small as the assertion syntax, assert_equal is the method that's, you know, this is how you do an assertion in Minitest, and it's assert_equal expected, actual. That's the order of the arguments. It's expected first and then actual. That makes sense, probably with the expected, but I would get that wrong constantly. I do get that sort of thing wrong. They're just positional arguments that there's nothing about this that tells me which way to go. And so it's very easy to get failure messages that are inverted, and so it's just this tiny little thing.

+ +

But with RSpec, we end up with expect and then in parentheses, the thing that we are expecting to equal the other thing, and it just reads a little more honestly. It fits within the Ruby mindset in my world. I want my code to be as expressive as possible, and Minitest feels much lower level to me. It feels more, you know, assert as a word is just...I'm not asserting. That just feels so formal. And so these are, again, to be clear, very, very small things, but they all add up.

+ +

And there's a reason that we're using Ruby overall. And there's a reason that we're using Rails is this expressiveness is a big part of it for me, so I'll cling to that. I'll hold on to that as something that's true. Also, Rspec's mocking support, rspec-mocks as the library, I found to be really fantastic, and I've grown very comfortable working with it. And I know how and where to use that.

+ +

I also have so much built-up knowledge, like the idea of when to use let and not use let in RSpec. It's just this deep thing that I know about. I'm sure there's an equivalent in the Minitest world, but I would have to have a different understanding in argument, and that conversation would just feel different.

+ +

I think the other thing that's worth saying is this is a default for us at this point that I personally have not felt the need to reconsider. When I've worked on projects that have used Minitest, I certainly wasn't called to it. I wasn't like, oh, this seems really interesting; I'm going to lean into this more. I was like, I miss RSpec. And some of that is, again, just familiarity. But at the end of the day, we only have so much time to do things. And so, I firmly stand by my not reconsidering my testing option at this point.

+ +

Like, RSpec does the things that I want. It does it really well. Critically, I'm able to build a system and write a test suite and maintain that test suite over time and have it tell me the truth as to whether or not my application should be deployed to production. That is the measure. That's the thing that I care about. I think it's maybe a little bit slower than Minitest, but I'm fine with that. I have solutions to that problem.

+ +

And the thing that I care about is when the test suite is green, do I feel confident deploying? RSpec has helped me for years on that journey. And I've never questioned whether or not I should go back to the drawing board and revisit that consideration. So initially, it was probably because it was the thing that we were all using, and then that is for me why it has stuck around. And I love RSpec. I think how many episodes have we just said, "Thanks, RSpec," as a little aside? So we do love it in a deep way.

+ +

STEPH: Probably not enough episodes have we said that. [laughs] Yeah, I like what you said where you haven't felt the need to switch over or to move away from RSpec. And I wonder, looking back at some of the earlier projects that I joined that were using RSpec, I don't know if maybe they chose RSpec at that time because RSpec had more of those features built-in, and Minitest was still working on those. Maybe they were parallel at the time; I'm not sure.

+ +

But I like what you said about you just haven't had a need to go back and change. At this point, if I switched over to Minitest, it would definitely be a learning curve for me, which is totally fine. But yeah, I'm just happy with it, so I stick with it.

+ +

And I also appreciate that idea that, yeah, unless you're new in a project, I wouldn't encourage someone to then switch over to something else unless I feel like there's just a lot of pain for some reason with the current testing setup. There has to be a reason. There has to be a drive. It can't be just a personal bias of like, I know this thing, so I want to use it. There's got to be a better reason that benefits the whole team versus just a personal preference.

+ +

But overall, I think it comes down to for us; it's just a choice because it's the familiar choice. It's the one that we know. But I think Minitest and RSpec are both so widely supported. I was thinking about that convention over configuration. And yes, Rails ships with Minitest, but RSpec is so common that I don't feel like I'm breaking convention at that point. They're both so widely supported and used that I feel very comfortable going with either option. And then it's just my personal preference for RSpec.

+ +

So thanks, Steve, for sending in that question. And for anyone else that has a question that you would love to share with Chris and I, you can reach us in a couple of different ways. You can reach us on Twitter via @_bikeshed. You can also go to the website, bikeshed.fm/content. We will drop some links in the show notes. But if you go there, then you can send a question or also email us directly at hosts@bikeshed.fm.

+ +

And we're running a little low on listener questions, so we would love to have a listener question from you. And we would love to talk about anything that y'all want to talk about, okay, within reason, you know, triathlons, Brussel sprouts, things like that. All of that falls within the wheelhouse.

+ +

CHRIS: Normal stuff.

+ +

STEPH: Normal stuff, yeah.

+ +

CHRIS: And to be clear, despite the fact that Steve did recently become a thoughtboter, you don't have to be a thoughtboter to send in a listener question. [laughs] In fact, it's much more common to not be a thoughtboter when sending in a listener question. But we'll take them from anybody. We're happy to chat with you.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris got a bike. Specifically, he bought a bike to use in a triathlon he signed up to participate in. Now he needs to name the bike, and speaking of naming things, a more technical topic that he talks about is the Crispy Brussels Snack Hour.

+ +

Steph talks about Rescue Rails projects and increasing developer acceleration.

+ +

They answer a listener question asking, "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?"

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Translate frustrations into professional corporate
+Learn Hotwire by Building a Forum
+parallel_tests
+parallel_split_test

+ +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Oh, but I recently learned that Robert Downey Jr. in the Marvel movies he's snacking a lot, maybe not Iron Man, but something...oh no, he's stacking a lot. And I'd read that he was snacking a lot on set, and so they just built it in to where like, sure, you can snack as your character while you're doing stuff.

+ +

CHRIS: [laughs]

+ +

STEPH: And I think that's so cool because I find that I am eating every time I show up to record with you. So I would like the same special star treatment as Robert Downey Jr., [laughs] and I just get to eat during each Bike Shed. [laughs]

+ +

CHRIS: All right. [chuckles] My understanding is also that he was wildly the highest paid of all the actors, so I think that should also come along with this.

+ +

STEPH: [laughs]

+ +

CHRIS: Yeah, there's a lot that we can sort of layer on here, but it makes sense to me, and I'm fully on board.

+ +

STEPH: You're an excellent agent. Thank you for fighting for my higher pay.

+ +

[laughter]

+ +

CHRIS: You are welcome.

+ +

STEPH: What a good co-host you are.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. One of these days, I'm going to say, "I'm Chris Toomey," and then I'm just going to see how you roll with it, although now I'm ruining it, I should have just gone for it. [laughs]

+ +

CHRIS: Nothing can prepare me for this despite the fact that you're telling me in this moment. In that future moment when you do it, I will still be completely knocked out of whack. Just like for anyone out there listening, the thing that Steph would normally have said instead of what [laughs] she just said was, "What's new in your world?"

+ +

STEPH: [laughs]

+ +

CHRIS: And I contractually require that that is the only way she starts this question to me because I get completely lost. She's like, "How are you doing?" I just overthink it, and I get lost, and then we end up in a place like this where I'm just rambling.

+ +

STEPH: Every podcast contract you have from here on out must begin with hey, Chris, what's new in your world? [laughs] I will still get to that question. I just also had to tell you my future joke. I'm going to play that. Hopefully, you'll forget, and one day I will resurface.

+ +

CHRIS: I can pretty much promise you that I'm going to forget it.

+ +

[laughter]

+ +

STEPH: Excellent. Well, to make sure I stick within the Chris Toomey contract guidelines, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Now I just want to spend a lot of time putting together my rider. There can be no brown M&M's in the bowl. No eye contact, please. And I can only be addressed with this one question which is, to be clear, very not true, Steph. And I always record with a video because we actually like to have human faces attached to things. Anyway, I'm going to tighten this all up. When we get to the technical segment of my world, I'm going to tell you about Crispy Brussels Snack Hour, so just throwing that out there as an idea.

+ +

But before we do that, I'm going to share a fun little thing which is I bought a bike, which is exciting. It's not that exciting. People have bikes. This is exciting for me. But the associated thing that is more exciting/a little terrifying is I'm going to try and run a triathlon. I'm going to try and run, swim, and bike a triathlon as they go, specifically a sprint triathlon for anyone out there that's listening and thinking, oh wow, that sounds like a thing. The sprint is the shortest of the distances, so that's what I'm going to go for. But yeah, that's a thing that I'm thinking about in my world now.

+ +

STEPH: I know next to nothing about triathlons. So what is a sprint in terms of like, what is the shortest? What does that mean?

+ +

CHRIS: I think there actually maybe even shorter distances but of the common, there's sprint, Olympic. I want to say half Ironman, and then Ironman are the sequence. And an Ironman, as far as I understand it, I think it's a full marathon. It's like a century bike ride or something like that. It's an astronomical amount of everything.

+ +

Whereas the sprint triathlon being the shortest, I think it's a 3.6-mile run, so a little over a 5K run, a 10-mile bike ride, and a quarter-mile swim, I want to say, something like that. But they're each scaled down to the rough equivalent of a 5K but in each of the different events. So you swim, and then you bike, and then you run.

+ +

And so I'm going to try that, or at least I'm going to try to try. It's in September, and now is not September. So I have a lot of time between now and then to do some swimming, which I haven't done...like, I've swum but not in a serious way, not in an intentional way. So I got to figure out if I still know how to swim, probably get better at biking, and do a little bit of running, and it's going to be great. It's going to be a lot of fun. I'm super excited about it. Only a little terrified.

+ +

STEPH: I think this is where as your co-host coach, which you have not asked me to be, where I would say something about there is no try, to mimic Yoda. [laughs]

+ +

CHRIS: Yep, yep. Yep. Do or do not. Sprint or sprint not. There is no trying. Oh, were you making a try pun there?

+ +

STEPH: I didn't go that far, but you just brought it home. I see where you're going. [laughs]

+ +

CHRIS: This is pretty much what I do professionally is I just take words, and I roll them around until I find something else to do with them. So glad that we got there together.

+ +

STEPH: Well, I'm really excited to hear about this. I don't know anyone that's trained for a triathlon. I think that's true. Yeah, I don't think I know anyone that's trained for a triathlon. So I'm curious to hear about how that goes because that sounds intense, friend.

+ +

CHRIS: I think so. None of the individual segments sound that bad but stitching them all together, and I think the transitions are some of the tricky parts there. So yeah, it'll be fun. It's something I find...I used to never run; that was the thing. Like, deeply true in my head was that I'm not a runner. This is just a true fact about me. And then I ran a 5K one year for...it was like a holiday 5K fun run with friends. And every bit of the training leading up to it was awful. I did Couch to 5K. I hated it.

+ +

My story in my head of I'm not a runner was proven with every single training run. Man, did I hate it. And then something magical happened on the day that I actually ran the race, and it was fun. And I was out there, and there was the energy of being in this group of people. But it was competitive and not competitive in this really interesting way. And then it ended, and we were just hanging out in a parking lot, and they gave us beer. And I was like, well, this is actually delightful. Maybe I actually like this thing.

+ +

And so I've run a bunch of different races. And I've found that having a race to train for, and by train, I just mean some structured attempt at running, has been really enjoyable and useful for me. So yeah, this is just ratcheting that up a tiny bit. I've done a couple of half marathons is the high watermark so far. It's a good distance. But I don't know that a full marathon makes sense; that's a real commitment. And I'm looking to move laterally rather than just keep getting more complex in my running. So we're trying the shortest possible triathlon that I know of.

+ +

STEPH: I am such a believer that exercise should be fun, so I love that. Like, I'm not a runner, but then you get around people, and it's exciting. And then there's that motivation, and then there's a fun ending with beers that totally jives with me. Because sure, I can go to the gym; I can lift weights, I can make myself exercise. There's some fun to it.

+ +

But I strongly prefer anything that's more of like a sport or group exercise; that's just so much more fun. Well, super cool. Well, I'm excited. I would ask you all the details about your bike, but I know nothing. Do you want to share details about your bike? There may be other people that are interested.

+ +

CHRIS: Oh yeah, my bike. I went to the bike store, and I said, "Could I have a bike, please?" And then they toured me around and showed me all the fancy...they were like, "This is our most modest entry-level bike." And then they kept walking around and showing me fancier bikes. And I was like, "Can we go back to that first one? That one seemed great."

+ +

STEPH: [laughs]

+ +

CHRIS: Because it got all of the checkboxes I was looking for, which is basically it's a bike. So actually, the specifics on it are it's a hybrid bike, so like a mix between road, and I don't even know the other road bikes I know of, and maybe it's trail. But I don't think it's meant for going on the trail. But for me, it'll be fine for what I'm trying to do as far as I understand it.

+ +

It's technically a fitness hybrid, which I was like, oh, fancy. It's a fitness bike; look at me go. But it was basically just like, I would like a bike. General-purpose hybrid seems like the thing that makes sense. So I got a hybrid bike. And that's where I'm at. Oh, and I got a helmet because that seems like a smart move.

+ +

STEPH: Nice. Yeah, the bike I own is also one of those hybrids where it's like…because when I moved to Boston...and lots of people have the road bikes, but their tires are just so skinny; it made me nervous. And so I saw one of the hybrid bikes, and I was like, that one. That looks a little more steady and secure, so I went with that one even though it's heavier. Do you have a name for your bike? Are you going to think of a name for your bike?

+ +

CHRIS: I didn't, and I wasn't planning on it. But now that you've incepted me with this idea that I have to name my bike, of course, I have to name my bike. I'm going to need a couple of weeks to figure it out, though. We're going to have to get to know each other. And you know, something will become true in the universe for me to answer that question. But as of so far, no, I do not have a name for the bike.

+ +

STEPH: Cool. I'll check back in. Yeah, it takes time to find that name. I feel you.

+ +

CHRIS: [laughs] Yeah, don't make up a name. I have to find what's already true and then just say it out loud. Speaking of naming things and perhaps doing so in a frivolous way, as I mentioned earlier, the more technical topic that I want to talk about, oddly, is called Crispy Brussels Snack Hour. [laughs] So, within our dev team, we have started to collect together different things that don't quite belong on the product board, or at least they're a little more confusing. They're much more technical.

+ +

In a lot of cases, they are...our form handling is a little rough. And it's the sort of thing that comes up a lot in pull requests where we'll say, "I feel like this could be improved." And we're like, "Yeah, but not in this pull request." And so then it's what do you do with that? Do you put a tech debt card in the product board? You and I have talked about tech debt cards plenty of times, and it's a murky topic.

+ +

But we're trying within the team to make space and a way and a little bit of process around how do we think about these sorts of things? What are the pain points as a developer is working on the system? So to be clear, this isn’t there is a bug because bugs we should just fix; that's my strong feeling, or we should prioritize them relative to the rest of the work. But this is a lower level. This is as a developer; I'm specifically feeling this sort of pain.

+ +

And so we decided we should have a Trello board for it. And they were like, "Oh, what should we name the Trello board?" [laughs] And I decided in this moment I was like, "You know, if we're being honest, I've named everything very boring, very straight up the middle. We don't even have that many things to name. So we have zero frivolous names within our team. I think this is our opportunity. We should go with a frivolous name. Anybody have any ideas?"

+ +

And someone had worked on a team previously where maybe it was a microservice or something like that was called crispy Brussels, like, crispy Brussels sprouts but just crispy Brussels. And so I was like, "Sure, something like that. That sounds great." And then they ended up naming it that which was funny, and fun, and playful in and of itself.

+ +

But then we were like, "Oh, we should have a time to get together and discuss this." So we're now exploring how regularly we're going to do it. But we were like, let's have a meeting that is the dev team getting together to review that board. And we were like, "What do we call the meeting?" And so we went around a little bit, but we ended with the Crispy Brussels Snack Hour.

+ +

STEPH: That's delightful. I love the idea of onboarding new people, and they just see on their calendar it's Crispy Brussels Snack Hour, come on down. [laughs]

+ +

CHRIS: It's also got an emoji Brussel sprout and an emoji TV on either side of the words Crispy Brussels Snack Hour. So it's really just a fantastic little bit of frivolity in our calendars.

+ +

STEPH: [laughs] That's delightful. How's that going? I don't think we've tried something like that explicitly in terms of, like you said, there are discussions we want to have, but they're not in the sprint. They're not tech debt cards that we want to create because, like you said, we've had conversations. So yeah, I'm curious how that's working for you.

+ +

CHRIS: Well, so we've only had the one so far; it went quite well. We had a handful of different discussions. We were able to relatively prioritize this type of work within that. But one of the other things that we did was we had a conversation about this process, about this meeting, and the board. And whatnot.

+ +

So we identified a couple of rules of the road or how we want to approach this that I think will hopefully be useful in trying to constrain this work because it's very easy to just like; nothing's ever perfect. And so this could very easily be a dumping ground for half-formed ideas that sound good but aren't necessarily worth the continued effort, that sort of thing.

+ +

So the agenda for the meeting as described right now is async between meetings. Any of us can add new cards, ideally stated as problems and not solutions. So our form handling could use improvement. And then in the card, you can maybe make a suggestion of I think we could use this library or something like that. But rather than saying use this library or move to this library, we frame in terms of the problem, not necessarily the solution.

+ +

And then, at the start of the meeting, any individual can champion a card so they can say, "Here's the thing that I really want everyone to know about that I've been feeling a lot of pain on." So it's a way for individuals who have added things to this to add a little bit more detail. Then using Trello as voting functionality, we each get a couple of votes, and we get to sprinkle them across different cards, and then using that now allows us collectively to prioritize based on those votes. And so the things that get voted up to the top we talk about; we prioritize some amount of work coming into the sprint.

+ +

If it's actually going to turn into work, then it'll go onto the product board because ideally, it's moved from problem space to more of solution space even if the solution, the work to be done is do a spike on XYZ library or approach to form handling or whatever it is. But so ideally, it then moves on to the other board.

+ +

The other thing that I felt was important is it's very easy for this to be a dumping ground for ideas. So my suggestion is at the end of the meeting, we sort by date, and we prune the oldest things. So it's like, if it's still hanging around and we haven't done it yet, and it's not getting voted up, then yes, we might feel some pain but not enough. It's not earning its place on this board. So that's my hope is we're weeding the Brussel sprouts garden that we have at the end of the meeting.

+ +

That's roughly what we have now. We really only had the one, so that idea of pruning will probably come in later on. And it may be that this doesn't work out at all, and this ends up being tech debt cards that get stale and don't capture the truth. But I'm hopeful because there's definitely...there's a conversation to be had here. It's just whether or not we can make sure that conversation is useful and capturing the right amount of context and at the right points in time and all of that.

+ +

STEPH: Yeah, I like it. I like the whole process you outlined. You know what it made me think of? It sounds like a technical retro, not that retros can't be technical; we bring up technical stuff all the time. But this one sounds like there was more technical discussion that was still looking for space to bring up. So the way that you mentioned that people add their thoughts, that it can be done async, and then you vote up, and then as things get stale, you remove them and focus on the things that the team voted for, that's really cool. I've never thought of having just a technical-specific retro.

+ +

CHRIS: Yeah, definitely informed by retro. But again, just that slight honing the specific focus of this is just the dev team chatting about deeply dev-y things and making a little bit of space for that. I think the difficulty will be does this encourage us to work on this stuff too much? And that's the counterbalance that we have to have because this work can be critically important.

+ +

But it can also be a distraction from features that we got to ship or bugs that are in the platform or other things like that. So that balancing act is something that I'm keeping in mind, but thus far, the way we structured it, I'm hopeful. And I'm interested in exploring it more, so we'll see where we get to. And I'll certainly report back as we refine the Crispy Brussels Snack Hour over time.

+ +

STEPH: I feel like the opposite is true as well, where you have these types of concerns and things that you want to bring up. And even if they're on the board, once you get to sprint planning, there's a lot of context and conversation there that maybe the whole team doesn't have. It doesn't feel like the right moment to dive into this because you're trying to plan a new sprint.

+ +

So then that stuff gets bumped down to the bottom or just never really discussed, or it gets archived. So I feel like the opposite is totally true, too, where you have this stuff, but then it never gets talked about because sprint planning is not the right place. So yeah, I'm really intrigued to see how that balance works out for y'all as well.

+ +

CHRIS: Yeah, I think it's an exciting time, and we'll see where it goes. But like I said, I'm hopeful on it. But yeah, bikes, triathlons, and crispy Brussels, that's my world.

+ +

Mid-roll Ad:

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: I have a couple of fun things that I want to share and then something that's a little more in the techie space. The first one is there's a delightful Twitter thread that caught my attention recently that I just want to share; totally not tech-related. But this person shared a thread talking about how they help everyone on their team who's older than they are, making sure that the slang that they're using is correct in its context. And so they provided some funny examples.

+ +

And then, in return, they also will translate this person's frustrations into professional corporate-speak, and it's such a good thread. So if you need a good laugh, I will make sure to include a link in the show notes. The slang is really funny, but it's actually the translation of frustrations into professional corporate-speak that that's the part that resonated with me. That was really good. [laughs]

+ +

CHRIS: You shared this with me outside of this conversation, and I've read through them. Listeners out there, do not sleep on this. I highly suggest reading through this thread because it is fantastic.

+ +

STEPH: The other thing that I saw is Andrea Fomera, who is a Rails developer and creates a fair amount of content...I haven't been through some of that content, but I know there's content around Rails. And specifically, there is a newer course called Learn Hotwire by Building a Forum. And she has made this totally free, and I just think that is so cool.

+ +

And she shared that on Twitter, so I'll be sure to include a link in that to the show notes because Hotwire is something I haven't used yet. And so I saw this free course, and I think it would be fun to dabble and go through the course. And I know there are some other people at thoughtbot that have used it and seem really happy with it or interested in using it as well. Is that something that you've used?

+ +

CHRIS: I have not. I skipped over Hotwire in my adventures. I'd found Inertia and was quite happy with that. And then, in that way that, I sometimes limit the amount of things that I'm allowed to explore on the internet in hopes of actually getting some work done; I have not spent much time.

+ +

But enough folks that I deeply respect are very excited about Hotwire that it remains in the like; I would love to have an afternoon just to poke around with that. So I may take a look at this, although I don't know, I'm probably still in my moratorium. I'm not allowed to look at new frameworks for a little while time period. But I hear great things.

+ +

STEPH: That's fair. That's also what I've heard. I've heard great things. So yeah, I just figured I would share that in case anybody else is interested in looking for a course that they could take and also dabble at Hotwire.

+ +

The other thing that's on my mind is more the type of projects that I'm really getting a lot of joy from. Because I've known about myself for a while that greenfield projects are nifty, but they're not my thing. They're not the thing that brings me a lot of joy. It's just kind of nice. You got your own space, and you're building from the ground up, cool, cool, cool.

+ +

But this one, I found that the projects that I’m really starting to gravitate towards are what I've heard someone else call Rails Rescue projects. So those are the projects where they have been around for a while, or they've just been built in a way that the data modeling structure makes it really hard to implement new features. Maybe there's a lack of test coverage that makes it really risky to ship new work or to make changes. There are lots of bug reports and errors that the team is fighting with.

+ +

So then that type of work comes down to where you're trying to either increase stability for the application and for users and/or you're looking to increase developer acceleration. And I really, really liked those projects. That's the type of project that I've been a part of for...I think my last couple of clients have been in that way. I don't know that they would describe it that way, that it's a Rails Rescue project.

+ +

But if I can see that opportunity where I see there's a stability issue or developers are feeling a lot of pain in one area, then that's the portion of the application, the portion of the team that I'm going to gravitate towards. Or like the current work that I'm doing where we're really focused on testing and making some improvements there or reducing that pain that the team is feeling around how long CI takes to run or the flakiness because then you're having to re-verify your CI runs.

+ +

I like that work. It's a bit slow and frustrating, so it does seem to require a patient person. You also have to have lots of metrics that are guiding you because you can have a lot of assumptions around I'm going to make this improvement, but it's going to take effort to get there. And it'd be great if I can validate that effort upfront. So I feel like a lot of my time is spent more around metrics, and data, and excel sheets than necessarily coding. I don't know if that's great, but it's part of the work. There's a balance there. So I just found that interesting.

+ +

I don't think I would have thought this is something I was interested in until now that I've been on these projects for a while. And I've started noticing a theme where I really enjoy them. Although I realize looking back at former Stephanie days when I was going through Launch Academy and learning to code, I really thought I wanted to be in DevOps. DevOps seemed like the cool kids’ corner. They knew how the internet worked. They knew what was happening. They were making it live. And I just thought it seemed really cool. For the record, it is still a cool kids’ corner.

+ +

But I have also learned that the work-life balance isn't great with DevOps because you just never know when you're going to be on call. And that really stood out to me as something that I didn't want to do. And I do like building some features. But essentially, it's that developer acceleration that I really liked because they were the ones that were coming and often building tools and making it easier for then people to then ship their code and get it out into the world and triage.

+ +

And so I liked the fact that their users were developers versus the people using the application as much, although, I guess, technically both. But the people they were often striving to help the most was the internal team, and that resonated with me. So I guess I have eventually found my way into that space. It wasn't through DevOps, but it is now through this idea of projects that need some rescuing.

+ +

CHRIS: I love that you've spent enough time now to figure out what it is that draws you in the work and the shape of projects that is meaningful to you. Interestingly, I find myself not on the opposite side of things...you know, we're always looking for a disagreement, and this isn't a disagreement, but this is a thing on which we differ a surprising amount because I do like the early-stage stuff, the new, the breaking ground, all of that exciting whatnot.

+ +

But how do I not make this a more complicated statement? I appreciate that you have the point of view that you do. I think the world needs more of what you're doing than the inclination that I have, like; I want to start something bright, and fresh, and new, and I can see so much progress immediately in front of me. And this is amazing. But the hard, meaningful work like maintenance, and support, and legacy, and rescue where necessary is such a critical aspect of the work.

+ +

I see this in open source so often where there are people who are like; I made an open-source project; this is great. I hacked for a bunch of weekends, and look; I made a thing. And then the support burden builds up. And open source can be this wildly undervalued thing overall. And the maintenance of open source is even more so, and you have this asymmetry between the people that are using it and don't think that their voice is one of the thousands that are out there requesting a new feature or anything like that.

+ +

The handful of people that I see out there in the world that come along later in the lifespan of an open-source project and just step in to do maintenance, my goodness, is that heroic work, just quiet, necessary heroic work. And what you're describing feels sort of similar but at the project level. And I don't know; I'm sort of like silent. I'm out loud on a podcast, not silently at all judging myself because I'm like, I feel like you're doing the thing over there. That seems like a good thing. But I also like my early projects... [laughs]

+ +

STEPH: I think they're...I mean, we need each other. I need you to start the code, and the applications for them to then need some help down the road [laughs] to [crosstalk 24:30].

+ +

CHRIS: But I need to do a bad enough job that we have to be rescued by you.

+ +

STEPH: [laughs]

+ +

CHRIS: Hey, don't you worry, friend, I'm doing a terrible...no, I think I'm doing an okay [laughter] job. Hopefully, I'm avoiding those traps, but it's hard to know when you're writing legacy code, you know.

+ +

STEPH: It is hard for the reasons we were talking about earlier. Like, those technical discussions build-up, and then if you don't really have a space to then address it, then it just keeps getting sidelined until you suddenly get to this point of it's either we come to a grinding halt because we can't ship work, or we find ways to start bringing this into our process.

+ +

And so that's the other part of the Rails Rescue projects is often looking at the team's process and figuring out, okay, instead of hiring consultants to come in and then try to help with this, how else can they also integrate this into their own project? So then, once thoughtbot lives, they now have ownership of this, and they can carry it forward as well.

+ +

There is an aspect of this work that I'm still working on, and it comes around to the definition of work because if you go into a team or a project that's like, hey, we really need help with X. We really need help with addressing all these errors. Or we really need help improving developer happiness or getting test coverage in place. Finding out exactly how you're going to tackle that, are you going to join a team of the other developers?

+ +

Like, are you looking for more of a mentorship? Like, hey, we're going to work alongside your team to then mentor them to then bring this into their own process and their own habits, so then they feel empowered to address this in the future. Are we doing this more as a triage where then we have a specific goal or two that then we're going to meet? And then once we get stuff out of this on fire state, then maybe we start pairing with other people. Or are we going to work closely with the people who are fighting fires with the bug reports and the errors?

+ +

There are a bunch of different ways that you can tackle that. And I think it really helps define the success of that engagement and then your outcomes because otherwise, I feel like you can get distracted by so much. Because there's so much that's going to try to get your attention that you want to work on and fix. So you have to be very upfront about there are different areas that we can work on. Let's figure out some metrics together that we're really going after to then help define what does success look like for this first iteration of our work?

+ +

And then what's the long-term plan for this work? Then how do we keep it going forward? How do we empower the team to keep this work going forward? And that's an area that I've learned just from trial and error from being part of these projects. And I'm very interested in still cultivating that skill and figuring out what's the area that we're focused on?

+ +

CHRIS: There's something that you said in there that I want to hone in on, which is the idea of you've learned from going on so many of these different projects, and you're carrying forward ideas that you have. But I think more generally, there's something interesting in what you were just saying there around you've worked on a bunch of different projects at different organizations with certain things that they were great at, with certain things that they struggled with at different sizes. And you're able to bring all that experience to bear on each project.

+ +

But I think also taking a step back, as you were describing, you're like, I think I've figured out what it is that I like and the type of projects that I want to do. I cannot say enough good things about working in a consultancy for a while because, my goodness, you get to try out a bunch of different stuff. And A, you get to learn a ton about how to do the work, and how to communicate, and different technologies and all of that. But you also get to figure out what it is that you might want to double down on and lean into in terms of the work. That's definitely a big part of my story.

+ +

Seven years at thoughtbot, I tried a lot of different stuff, worked at a lot of different companies. And I would describe it as I found a lot of things that I didn't want. And then there's that handful of things that I really did want, and I was able to then more intentionally pursue that. So for anyone out there that's considering it, working at a consultancy is fantastic, or at least it has fantastic elements to it.

+ +

It also can be complicated as you talk about finding organizations and having to, you know, if you're brought in for a certain job, but when you get there, you're like, "Ooh, I know you want me to fix bugs, but actually, I think I just need to work with your team because they're the ones writing the bugs. And why are they writing the bugs" "Well, because the salespeople are selling things, and then we have timelines." Like, we got to start at the very top of this whole pyramid and fix it. And so it can be very complicated. But there's so much that you can learn about yourself in the process, in the work, and I adored that portion of my career.

+ +

STEPH: Yeah, I totally agree. Anytime someone mentions, they're like, "Oh, consultancy work. What's that like?" And I remember it was a couple of years ago I mentioned I was working for a consultancy, and they were like, "Oh, you must travel a lot." I was like, "No, [laughter] I stay put. I just work from an office in Boston." But I remember that caught me off guard because I hadn't considered that I was supposed to travel, but that makes sense that you think of consultants that travel.

+ +

But when I meet people or talk to people, and they're like, "Oh, you've been at thoughtbot for five-plus years, and how's that going? And what's it like to be at a consultancy?" And exactly what you just said, it's the variety that I really like and getting to try on so many different hats and see how different teams and processes work and then identify like, oh, that worked really well for that team, or this isn't working well for that team. I have really enjoyed that.

+ +

And it can be a roller coaster because you have to get really good at onboarding. You have to go through that initial phase of like; I swear I'm smart. I will get up to speed quickly, and I will learn things. But it's a period that you just have to go through with each team that you join, but you do it twice a year, maybe three times a year. And so you get comfortable with that over time.

+ +

So there are definitely some challenges that then have to fit your personality and things that work for you and bring you joy. And I completely understand that it's not for everybody, just kind of I really enjoy product work, but I also really enjoy being able to move around to different teams and help folks.

+ +

CHRIS: I love the idea that as a consultant, your job is to just walk through airports and high-five every Accenture billboard in it and just go up to the wall and pay your respects. But no, no, that is not our version of consulting. [laughs]

+ +

STEPH: That's why I have so much time for The Bike Shed. It's because I'm just, you know, I'm in different airports high-fiving signs. And then this is my real job; Bike Shed is my real job.

+ +

CHRIS: Oh, that would be fun.

+ +

STEPH: [laughs] You know, I have such a fondness of Bike Shed that now something interesting has happened where someone was like, "Oh, you're bike-shedding." And they're not being mean, but they're just like, "Oh, we're totally bike-shedding," or "This is dissolving into bike-shedding." And I'm like, oh, bike-shedding, hooray. And I'm like, oh, wait, bad. [laughter] And I have to catch myself each time.

+ +

CHRIS: Yeah, we've taken away a lot of the meaning. Well, I mean, have we or do we live up to it every single week? Who can say? But I, too, have a fondness for this phrase, perhaps not aligned with what it is actually meant to signify.

+ +

STEPH: On a slightly different tech-related note, there is a gem that I'm really excited to check out. I saw it mentioned on the parallel_tests gem, which is what helps you run your tests in parallel, and it's what we're currently using. But you can group your tests in different ways. And right now, we're using the runtime strategy where essentially then we use the output from RSpec where we know how long each file took to run. And then parallel_tests will then use that data to then figure out, okay, how should I split up your test file? So then try to balance them as evenly as possible.

+ +

We're at that point, though, where we've talked about tentpoles, so we have certain files that, say, take 10 minutes; other files will only take two minutes. And that balance is really throwing off our ability to then bring down the CI build time. So on parallel_tests, there's reference to another gem called parallel_split_test, where then you can run multiple test scenarios that are in one file but then split them out across different processes or different machines. And that is exactly what I want in my life right now.

+ +

I haven't checked it out yet, so I feel like I'm giving a daily sync update of like, I'm going to go off and explore this thing. I will report back and see how it goes. [laughs] In the past, I usually try to say, "I've tried this thing, and this is how it went," nope, opposite today. I am sharing the thing I'm going to try, and then hopefully, it goes well.

+ +

CHRIS: Well, either way, we should definitely report back. That's the truth. I like that you're leading us into this and giving us a preview. But then yeah, we'll see where we get to. That does sound like the thing you want, though. So I hope it goes well.

+ +

STEPH: Yeah, we've learned at this point where we are splitting work across different machines that until we address some of those tentpole concerns, adding more machines won't help us because then a machine's going to run as long as the longest file. So we've been doing some manual work to split up those files. That's not the best, but it does help you see some results. So then, at least you know you're making progress.

+ +

So now we really need to find a way to automate that because we don't want someone to have to manually figure out where are the tentpoles, split those files up, commit that, and then keep track of, like, do we have another tentpole on the horizon? We really need a gem or something to help us automate that process. So yeah, I will be happy to report back.

+ +

MIDROLL AD:

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free. That's studio3t.com/free.

+ +

STEPH: Pivoting just a bit, we have a listener question. This question comes from Steve Polito. And Steve wrote in, "Longtime listener, first-time thoughboter." Yay. Yay is my addition. Anything that goes up in voice is probably my addition, [laughs] just so people know. All right, back to what Steve said. "Why do so many developers and agencies, thoughtbot included, replace the default test suite in Rails with RSpec?

+ +

Not only does Rails provide a fully functional test suite by default," looking at you Minitest, "but it's also well-documented and even provides the ability to run system tests. Rails is built on the principle of convention over configuration. And it seems odd to me that so many developers want to override such a fundamental piece of framework." Thanks in advance, [singing] Steve Polito. Steve, I hope it's okay I sang your name [laughs] because we're here now.

+ +

That is an awesome question. I'm going to give what may be less of an awesome answer which is, well, one; Steve highlights that people will then replace Minitest with RSpec. I haven't done that. I haven't actually gone into a project and said, "Okay, we need to replace your test suite and bring in RSpec instead." But if I'm starting out a project, I do have a heavy preference for RSpec, and frankly, that's just from experience. Like, that's what I was raised on, to say it in that way. [laughs]

+ +

RSpec is what I know; it's what I'm used to. It's what, even when I joined thoughtbot, was just the framework that we used for all of our testing and what we focused on so heavily. So frankly, for me, it's just a really strong bias. I know it's something that I'm really good at. I know it's something that works really well. I know it's well-documented. I know it's also very accessible for other people to use.

+ +

But actually replacing it on a different project, I don't think I would do that. I'd have to have a really strong reason, or maybe if we haven't actually started testing anything yet, to then replace it because that feels a bit aggressive to me. But then it just depends on the situation, I suppose. But yeah, overall, I just default to RSpec because that's what I'm accustomed to, and it's the testing framework that I know.

+ +

CHRIS: Yeah, I think my answer is largely the same. It's the thing that I've worked with by far the most. Similarly, I've been on projects that were using Minitest, and therefore I used Minitest because it's definitely not worth the effort to switch. But in a lot of...well, I will say this, I've much less experience, and this may be less true over time. But there were many things that drew me to RSpec, and that continues to be interesting to me in the RSpec world.

+ +

Even things as small as the assertion syntax, assert_equal is the method that's, you know, this is how you do an assertion in Minitest, and it's assert_equal expected, actual. That's the order of the arguments. It's expected first and then actual. That makes sense, probably with the expected, but I would get that wrong constantly. I do get that sort of thing wrong. They're just positional arguments that there's nothing about this that tells me which way to go. And so it's very easy to get failure messages that are inverted, and so it's just this tiny little thing.

+ +

But with RSpec, we end up with expect and then in parentheses, the thing that we are expecting to equal the other thing, and it just reads a little more honestly. It fits within the Ruby mindset in my world. I want my code to be as expressive as possible, and Minitest feels much lower level to me. It feels more, you know, assert as a word is just...I'm not asserting. That just feels so formal. And so these are, again, to be clear, very, very small things, but they all add up.

+ +

And there's a reason that we're using Ruby overall. And there's a reason that we're using Rails is this expressiveness is a big part of it for me, so I'll cling to that. I'll hold on to that as something that's true. Also, Rspec's mocking support, rspec-mocks as the library, I found to be really fantastic, and I've grown very comfortable working with it. And I know how and where to use that.

+ +

I also have so much built-up knowledge, like the idea of when to use let and not use let in RSpec. It's just this deep thing that I know about. I'm sure there's an equivalent in the Minitest world, but I would have to have a different understanding in argument, and that conversation would just feel different.

+ +

I think the other thing that's worth saying is this is a default for us at this point that I personally have not felt the need to reconsider. When I've worked on projects that have used Minitest, I certainly wasn't called to it. I wasn't like, oh, this seems really interesting; I'm going to lean into this more. I was like, I miss RSpec. And some of that is, again, just familiarity. But at the end of the day, we only have so much time to do things. And so, I firmly stand by my not reconsidering my testing option at this point.

+ +

Like, RSpec does the things that I want. It does it really well. Critically, I'm able to build a system and write a test suite and maintain that test suite over time and have it tell me the truth as to whether or not my application should be deployed to production. That is the measure. That's the thing that I care about. I think it's maybe a little bit slower than Minitest, but I'm fine with that. I have solutions to that problem.

+ +

And the thing that I care about is when the test suite is green, do I feel confident deploying? RSpec has helped me for years on that journey. And I've never questioned whether or not I should go back to the drawing board and revisit that consideration. So initially, it was probably because it was the thing that we were all using, and then that is for me why it has stuck around. And I love RSpec. I think how many episodes have we just said, "Thanks, RSpec," as a little aside? So we do love it in a deep way.

+ +

STEPH: Probably not enough episodes have we said that. [laughs] Yeah, I like what you said where you haven't felt the need to switch over or to move away from RSpec. And I wonder, looking back at some of the earlier projects that I joined that were using RSpec, I don't know if maybe they chose RSpec at that time because RSpec had more of those features built-in, and Minitest was still working on those. Maybe they were parallel at the time; I'm not sure.

+ +

But I like what you said about you just haven't had a need to go back and change. At this point, if I switched over to Minitest, it would definitely be a learning curve for me, which is totally fine. But yeah, I'm just happy with it, so I stick with it.

+ +

And I also appreciate that idea that, yeah, unless you're new in a project, I wouldn't encourage someone to then switch over to something else unless I feel like there's just a lot of pain for some reason with the current testing setup. There has to be a reason. There has to be a drive. It can't be just a personal bias of like, I know this thing, so I want to use it. There's got to be a better reason that benefits the whole team versus just a personal preference.

+ +

But overall, I think it comes down to for us; it's just a choice because it's the familiar choice. It's the one that we know. But I think Minitest and RSpec are both so widely supported. I was thinking about that convention over configuration. And yes, Rails ships with Minitest, but RSpec is so common that I don't feel like I'm breaking convention at that point. They're both so widely supported and used that I feel very comfortable going with either option. And then it's just my personal preference for RSpec.

+ +

So thanks, Steve, for sending in that question. And for anyone else that has a question that you would love to share with Chris and I, you can reach us in a couple of different ways. You can reach us on Twitter via @_bikeshed. You can also go to the website, bikeshed.fm/content. We will drop some links in the show notes. But if you go there, then you can send a question or also email us directly at hosts@bikeshed.fm.

+ +

And we're running a little low on listener questions, so we would love to have a listener question from you. And we would love to talk about anything that y'all want to talk about, okay, within reason, you know, triathlons, Brussel sprouts, things like that. All of that falls within the wheelhouse.

+ +

CHRIS: Normal stuff.

+ +

STEPH: Normal stuff, yeah.

+ +

CHRIS: And to be clear, despite the fact that Steve did recently become a thoughtboter, you don't have to be a thoughtboter to send in a listener question. [laughs] In fact, it's much more common to not be a thoughtboter when sending in a listener question. But we'll take them from anybody. We're happy to chat with you.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7aiLOek- + + ]]> + + Chris Toomey + Steph Viccari + + + 333: Tapas + https://bikeshed.thoughtbot.com/333 + a9fd3047-7158-4352-a52d-7b903a8c9899 + Tue, 12 Apr 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases. + +Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes. + 41:53 + no + + + Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases. +Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Emma Bostian (https://twitter.com/EmmaBostian) +Ladybug Podcast (https://www.ladybug.dev/) +Gerrit (https://www.gerritcodereview.com/) +Gregg Tobo the Magician (https://astonishingproductions.com/) +Sean Wang - swyx - better twitter search (https://twitter.com/swyx/status/1328086859356913664) +Twemex (https://twemex.app/) +GitHub Pull Request File Tree Beta (https://github.blog/changelog/2022-03-16-pull-request-file-tree-beta/) +Sam Zimmerman - CEO of Sagewell Financial on Giant Robots (https://www.giantrobots.fm/414) +TypeScript 4.1 feature (https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/) +The Bike Shed: 269: Things are Knowable (Gary Bernhardt) (https://www.bikeshed.fm/269) +TSConfig Reference - Docs on every TSConfig option (https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess) +Rails I18n (https://guides.rubyonrails.org/i18n.html) +This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. There are a couple of new things in my world, so one of them that I wanted to talk about is the fact that being pregnant is hard. I feel like this is probably a known thing, but I feel like I don't hear it talked about as much as I'd really like, especially in sort of like a professional context. And so I just wanted to share for anyone else that may be listening, if you're also pregnant, this is hard. +And I also really appreciate my team. Going through the first trimester is typically where you experience a lot of morning sickness and fatigue, and I had all of that. And so I was at the point that most of my days, I didn't even start till about noon and even some days, starting at noon was a struggle. And thankfully, the thoughtbot client that I'm working with most of the teams are on West Coast hours, so that worked out pretty well. +But I even shared a post internally and was like, "Hey, I'm not doing great in the mornings. And so I really can't facilitate any morning meetings. I can't be part of some of the hiring intros that we do," because we like to have a team lead provide a welcoming and then closing for anyone that's coming for interview day. I couldn't do those, and those normally happen around 9:00 a.m. for Eastern Time. And everybody was super supportive of it. So I really appreciate all of thoughtbot and my managers and team being so great about this. Also, the client team they're wonderful. +It turns out growing a little human; I'm learning how hard it is and working full time. It's an interesting challenge. Oh, and as part of that appreciation because…so there's just not a lot of women that I've worked with. This may be one of those symptoms of being in tech where one, I haven't worked with tons of women, and then two, working with a woman who is also pregnant and going through that as well. So it's been a little bit isolating in that experience. +But there is someone that I follow on Twitter, @EmmaBostian. She's also one of the co-hosts for the Ladybug Podcast. And she has been just sharing some of her, like, I am two months sleep deprived. She's had her baby now, and she is sharing some of that journey. And I really appreciate people who just share that journey and what they're going through because then it helps normalize it for me in terms of what I'm feeling. I hope this helps normalize it for anybody else that might be listening too. +CHRIS: I certainly can't speak to the specifics of being pregnant. But I do think it's wonderful for you to use this space that we have here to try and forward that along and say what your experience is like and share that with folks and hopefully make it a little bit better for everyone else out there. Also, you snuck in a sneaky pro-tip there, which is work on the East Coast and have a West Coast team. That just sounds like the obvious correct way to go about this. +STEPH: That has worked out really well and been very helpful for me. I'm already not a great morning person; I've tried. I've really strived at times to be a morning person because I just have this idea in my head morning people get more stuff done. I don't think that's true, but I just have that idea. And I'm not the world's best morning person, so it has worked out for many reasons but yeah, especially in helping me get through that first trimester and also just supporting family and other things that are going on. +Oh, I also learned a pro-tip about Twitter. This is going to seem totally random, but it was relevant when I was searching for stuff on Twitter [laughs] that was related to tech and pregnancy. But I learned...because I wanted to be able to search for something that someone that I follow what they said but I couldn't remember who said it. +And so I found that in the search bar, I can add filter:follows. So you can have your search term like if you're looking for cake or pregnancy, or sleep-deprived and then look for filter:follows, and then that will filter the search results to everybody that you follow. I imagine that that probably works for followers too, but I haven't tried it. +CHRIS: I like the left turn you took us on there but still keeping it connected. On the topic of Twitter search, they apparently have a very powerful search, but it's also hidden, and you got to know the specific syntax and whatnot. But there is a wonderful project by Shawn Wang, AKA Swyx, on the internet, bettertwitter.netlify.com is the URL for it. I will share a link to his tweet introducing it. But it's a really wonderful tool that just provides a UI for all of these different filters and configurations. And both make discoverability that much better and then also make it easy to just compose one of these searches and use that. +The other thing that I'll recommend is, I think it's a Chrome plugin. I'm guessing is what I'm working with here like a browser extension, but it's called Twemex, T-W-E-M-EX. And there's a sidebar in Twitter now, which just seems wonderful and useful. So as I'm looking at a Swyx post here, or a tweet as they're called on Twitter because I know that vernacular, there's a sidebar which is specific to Shawn Wang. +And there's a search at the top so I can search within it. But it's just finding their most popular tweets and putting that on a sidebar. It's a very useful contextual addition to Twitter that I found just awesome. So that combination of things has made my Twitter experience much better. So yeah, we'll have show notes for both of those as well. +STEPH: Nice. I did not know about those. This may cause someone to laugh at me because maybe it's easier than I think. But I can never remember that advanced search that Twitter does offer; I have to search it every time. I just go to Google, and I'm like, advanced Twitter search, and then it brings up a site for me, and then I use that as the one that Twitter does provide. But yeah, from the normal UI, I don't know how to get there. Maybe I haven't tried hard enough. Maybe it's hidden. +CHRIS: It's like they're hiding it. +STEPH: Yeah, one of those. [laughs] +CHRIS: It's very costly. They have to like MapReduce the entire internet in order to make that search work. So they're like, well, what if we hide it because it's like 50 cents per query? And so maybe we shouldn't promote this too much. +STEPH: [laughs] +CHRIS: And let's just live in the moment, everybody. Let's just swim in the Twitter stream rather than look back at the history. I make guesses about the universe now. +STEPH: [laughs] On a different note, I also discovered at thoughtbot in our variety of Slack channels that we have a yelling channel, and I had not used it before. I had not hung out there before. It's a delightful channel. It's a place that you just go, and you type in all caps. You can yell about anything that you would like to. And I specifically needed to yell about Gerrit, which is the replacement or the alternative that we're using for GitHub or GitLab, or Bitbucket, or any of those services. +So we're using Gerrit, and I've been working to feel comfortable with the UI and then be able to review CRs and things like that. My vernacular is also changing because my team refers to them as change requests instead of pull requests. So I'm floating back and forth between CRs and PRs. And because I'm in Gerrit world, I missed some of the updates that GitHub made to their pull request review screen. And so then I happened to hop in GitHub one day, and I saw it, and I was like, what is this? So that was novel. +But going back to yelling, I needed to yell about Gerrit because I have not found a way to collaborate with someone who has already pushed up changes. I have found ways that I can pull their changes which then took a little while. I found it in a sneaky little tab called download. I didn't expect it to be there. But then the actual snippet it's like, run this in your terminal, and this is then how you pull down the changes. And I'm like, okay, so I did that. +But I can't push to their existing changes because then I get like, well, you're not the owner, so we're going block you, which is like, cool, cool, cool. Okay, I kind of get that because you don't want me messing up somebody else's content or something that they've done. But I really, really, really want to collaborate with this person, and we're trying to do something together, and you're blocking me. And so I had to go to the yelling channel, and I felt better. And I'm yelling again. [laughs] Maybe I don't feel that great because I'm getting angry again talking about it. +CHRIS: You vented a little into the yelling channel; maybe not everything, though. +STEPH: Yeah, I still have more to vent because it's made life hard. Every time I wanted to push up a change or pull down someone else's changes, there are now all these CRs that then I just have to go and abandon, which is then the terminology for then essentially closing it and ignoring it, so I'm constantly going through. +And if I do want to pull in changes or collaborate, then there's a flow of either where I abandon mine, or I pull in their changes, but then I have to squash everything because if you push up multiple commits to Gerrit, it's going to split those commits into different CRs, don't like that. So there are a couple of things that have been pain points. And yeah, so plus-one for yelling channels, let people get it out. +CHRIS: Okay, so definitely some feelings that you are working through here. I'm happy to work together as a team to get through some of them. One thing that I want to touch on is you very quickly hinted at GitHub has got a bunch of new things that are cool. I want to talk about those. But I want to touch [laughs] on an anecdote. You talked about pushing something up to someone else's branch. You're like, oh, you know, I made some changes locally, and I'm going to push them up. +I had an interesting experience once where I was interacting with another developer. I had done some code review. They weren't quite understanding where I was. They had a lot of questions. And finally, I said, you know what? This will just be easier. Here, I pushed up a commit to your branch, so now you can see what I'm talking about. And I thought of this as a very innocuous act, but it was not interpreted that way. That individual interpreted it in a very aggressive sort of; it was not taken well. +And I think part of that was related to I think of Git commits as just these little ephemeral things where you're like, throw it out, feel free. This is just the easiest way for me to communicate this change in the context of the work that you're doing. I thought I was doing a nice favor thing here. That was not how it went. We had a good conversation after I got to the heart of where we both were emotionally on this thing. It was interesting. The interaction of emotion and tech is always interesting. +But as a result, I'm very, very careful with that now. I do think it's a great way as long as I've gotten buy-in from the person beforehand. But I will always spot check and be like, "Hey, just to confirm, I can just push up a commit to your branch, but are you okay with that? Is that fine with you?" So I've become very cautious with that. +STEPH: Yeah, that feels like one of those painful moments where it highlights that the people that you work with that you are accustomed to having a certain level of trust or default trust with those individuals, and then working with someone else that they don't have that where the cup is half-full in terms of that trust, or that this person means well kind of feelings towards a colleague or towards someone that they're working with. +So it totally makes sense that it's always good to check and just to be like, "Hey, I'd love to push up some changes to your branch. Is that cool?" And then once you've established that, then that just makes it easier. But I do remember that happening, and yeah, that was a bit painful and shocking because we didn't see that coming and then learned from it. +CHRIS: I do think it's an important thing to learn, though, because for me, in that moment, this was this throwaway operation that I thought almost nothing of, but then another individual interpreted it in a very different way. And that can happen, that can happen across tons of different things. And I don't even want to live in the idealized world where it's just tech; we're just pushing around zeros and ones; there's no human to this. But no, I actually believe it's a deeply human thing that we're doing here. +It's our job to teach the computers to be a little closer to us humans or something like that. And so it was a really pointed clarification of that for me where it was this thing that I didn't even think once about, no less twice, and yet someone else interpreted it in such a different way. So it was a useful learning situation for me. +STEPH: Yeah, I totally agree. I think that's a really wise default to have to check in with people before assuming that they'll be comfortable with something that we're comfortable with. +CHRIS: Indeed. But shifting back to what you mentioned of GitHub, a bunch of new stuff came in GitHub, and you were super excited about it. And then you went on to say other things about another system. [laughs] But let's talk about the great things in GitHub. What are the particular ones that have caught your eye? I've seen some, but I'm intrigued. Let's compare notes. +STEPH: So this is one of those where I hadn't seen GitHub in quite a while, and then I hopped in, and I was like, this is different. But some of the things that did stand out to me right away is that on the left-hand side, I can see all of the files that have been changed, and so that's a really nice tree where I just then immediately know. +Because that was one of the things that I often did going to a PR is that I would see what files are involved in this change because it was just a nice overview of what part of the applications am I walking through? Are there tests for this? Have they altered or added tests? And so I really like that about it. I'm sure there's other stuff. But that is the main thing that stood out to me. How about you? +CHRIS: Yeah, that sidebar file tree is very, very nice, which I find surprising because I don't use a file tree in my editor. I only do fuzzy finding to jump to files. But I think there's something about whenever GitHub had the file list; these are all the files that are changed. I'm like, this is just noise. I can't look at this and get anything out of it. But the file tree is so much more...there's a shape to it that my brain can sort of pattern match on. And it's just a much more discoverable way to observe that information. So I've really loved that. That was a wonderful one. +The other one that I was surprised by is GitHub semantic code analysis; stuff has gotten much, much better over time subtly. I didn't even notice this happening. But I was discussing something with someone today, and we were looking at it on GitHub, and I just happened to click on an identifier, and it popped up a little thing that says, "Oh, do you want to hop to the references or the definition of this?" I was like, that is what I want to do. And so I hopped to the definition, hopped to the definition of another thing, and was just jumping around in the code in a way that I didn't know was available. So that was really neat. +But then also, I was in a pull request at one point, and someone was writing a spec, and they had introduced a helper just like stub something at the bottom of a given spec file. And it's like, I feel like we have this one already. And I just clicked on the identifier. I think it might have actually been a matcher in RSpec, so it was like, have alert. And I was like, oh, I feel like we have this one, a matcher specific to flash message alerts on the page. And I clicked on it, and GitHub provided me a nice little inline dialog that showed me all of the definitions of have alert, which I think we were up to like four of them at that point. +So it had been copied and pasted across a couple of different files, which I think is totally fine and a great way to start, but they were very similar implementations. I was like, oh, looks like we actually already have this in a couple of places, maybe we clean it up and extract it to a common spec support thing, and ta-da, I was able to do all of that from the GitHub pull requests UI. And I was like, this is awesome. So kudos to the GitHub team for doing some nifty stuff. Also, can I get into the merge queue? Thank you. +... +STEPH: [laughs] There it is. That is very cool. I didn't know I could do that from the pull request screen. I've seen it where if I'm browsing code that, then I can see a snippet of where everything's defined and then go there, but I hadn't seen that from the pull request. I did find the changelogs for GitHub that talk about the introduction of having the tree, so we'll be sure to include a link in the show notes for that too. But yes, thank you for letting me use our podcast as a yelling channel. It's been delightful. [laughs] +Mid-roll Ad +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: Well, speaking of podcasts, actually, there was an interesting thing that happened where the CEO of Sagewell Financial, the company of which I am the CTO of, Sam Zimmerman is his name, and he went on the Giant Robots Podcast with Chad a couple of weeks ago. So that is now available. We'll link to that in the show notes. I'll be honest; it was a very interesting experience for me. I listened to portions of it. If we're being honest, I searched for my name in the transcript, and it showed up, and I was like, okay, that's cool. And it was interesting to hear two different individuals that I've worked with either in the past or currently talking about it. +But then also, for anyone that's been interested in what I'm building over at Sagewell Financial and wants to hear it from someone who can probably do a much better job of pitching and describing the problem space that we're working in, and all of the fun challenges that we have, and that we're hopefully living up to and building something very interesting, I think Sam does a really fantastic job of that. That's the reason I'm at the company, frankly. +So yeah, if anyone wants to hear a little bit more about that, that is a very interesting episode. It was a little weird for me to listen to personally, but I think everybody else will probably have a normal experience listening to it because they're not the CTO of the company. So that's one thing. +But moving on, I feel like today's going to be a grab bag episode or tapas episode, lots of small plates, as we were discussing as we were prepping for this episode. But to share one little thing that happened, I've been a little more removed from the code of late, something that we've talked about on and off in previous episodes. Thankfully, I have a wonderful team that's doing an absolutely fantastic job moving very rapidly through features and bug fixes and all those sorts of things. +But also, I'm just not as involved even in code review at this point. And so I saw one that snuck through today that, I'm going to be honest, I had an emotional reaction to. I've talked myself down; we're fine now. But the team collectively made the decision to move from a line length of 80 characters to a line length of 120 characters, and I had some feelings. +STEPH: Did you fire everybody? [laughs] +CHRIS: No. I immediately said, doesn't really matter. This is the whole conversation around auto-formatting tools is like we're just taking the decision away. I personally am a fan of the smaller line length because I like to have multiple files open left to right. That is my reason for it, but that's my reason. A collective of the developers that are frankly working more in the code than I am at this point decided this was meaningful. It was a thing that we could automate. I think that we can, you know, it's not a thing that we have to manage. So I was like, cool. There we go. +The one thing that I did follow up on I was like, okay; y'all snuck this one in, it's fine, I'm fine with it. I feel fine; everything's fine. But let's add that to the git-blame-ignore-revs file, which is a useful thing to know about. Because otherwise, we have a handful of different changes like this where we upgrade Prettier, and suddenly, the manner in which it formats the files changes, so we have to reformat everything at once. And this magical file that exists in Git to say, "Hey, ignore this revision because it is not relevant to the semantic history of the app," and so it also takes that decision out of the consideration like yeah, should we reformat or not? Because then it'll be noisy. That magical file takes that decision away, and so I love that. +STEPH: I so love the idea because you took vacation recently twice. So I love the idea of there was a little coup and people are applauding, and they're like, while Chris is on vacation, we're going to merge this change [laughs] that changes the character line. And yeah, that brings me joy. Well, I'm glad you're working through it. Sounds like we're both working through some hard emotional stuff. [laughs] +CHRIS: Life's tricky, is all I'm going to say. +STEPH: I am curious, what prompted the 80 characters versus 120? This is one of those areas that's like, yeah, I have my default preference like you said. But I'm more intrigued just when people are interested in changing it and what goes with it. So do you remember one of the reasons that 120 just suited their preferences better? +CHRIS: Frankly, again, I was not super involved in the discussion or what led them to it. +STEPH: [laughs] +CHRIS: My guess is 120 is used...I think 80 is a pretty common one. I think 120 is another of the common ones. So I think it's just a thing that exists out there in the mindshare. But also, my guess is they made the switch to 120 and then reformatted a few files that had like, ah, this is like 85 characters, and that's annoying. What does it look like if we bump it up? +And so 120 provided a meaningful change of like, this is a thing that splits to four lines if we have an 80 character thing, or it's one line if it's 120 characters, which is a surprising thing to say, but that's actually the way it plays out in certain cases because the way Prettier will break lines isn't just put stuff on the next line always. It's got to break across multiple lines, actually. All right, now that we're back in the opinion space, I have a strong one. +STEPH: This is The Bikeshed. We can live up to that name. [laughs] +CHRIS: So I do want an additional configuration in Prettier Ruby. This is the thing I'll say. Maybe I can chase down Kevin Newton and see if he's open to this. But when Prettier does break method call with arguments going into it but no parens on that method call, and it breaks out to multiple lines, it does the dangling indent thing, which I do not like. I find it distasteful; I find it noisy, the shape of the code. I'm a big fan of the squint test. I know that from Sandi Metz, I believe, or maybe it's Avdi Grimm. I associate it with both of them in my mind. +But it's just a way to look at the code and kind of squint, and you see the shape of it, and it tells you something. And when the lines break in that weird way, and you have these arbitrary dangling indents, the shape of the code is broken up. And I don't feel so strongly. I actually regularly stop myself from commenting on pull requests on this because it's very easy. All you need to do is add explicit parens, and then Prettier will wrap the line in what I believe is a much more aesthetically pleasing, concise, consistent, lots of other good adjectives here that are definitely just my preferences and not facts about the world. +But so what I want is, Prettier, hey, if you're going to break this line across multiple lines, insert the parens. Parens are no longer optional for breaking across multiple lines; parens are only optional within a given line. So if we're not breaking across lines, I want that configuration because this is now one of those things where I could comment on this. And if they added the optional parens, then Prettier would reform it in a different way. And I want my auto formatter don't give me ways to do stuff. Like, constrain me more but also within the constraints of the preferences that I have, please, thank you. +STEPH: I love all the varying levels there [laughter] of you want a thing, but you know it's also very personal to you and how you're walking that line and hopping back and forth on each side. I also love the idea. We have the idea of clean code. I really want something that's called distasteful code now [laughs] where you just give examples of distasteful code, yes. Well, I wish you good luck in your journey [laughs] and how this goes and how you continue to battle. +I also appreciate that you mentioned when you're reviewing code how you know it's something that you really want, but you will refrain from commenting on that. I just appreciate when people have that filter to recognize, like, is this valuable? Is it important? Or, like you said, how can we just make this more of the default so then we don't even have to talk about it? And then lean into whatever the default the team goes with. +CHRIS: Well, thank you. I very much appreciate that because, frankly, it's been very difficult. +STEPH: I do have something I want to yell about but in a very positive way or pranting as we determined or, you know, raving, the actual real term that wonderful listeners pointed out to us. +CHRIS: Prant for life. That's my stance. +STEPH: We had a magic show at thoughtbot. It was all remote, but the wonderful Gregg Tobo, the magician, performed a magic show for us where we all showed up on Zoom. And it was interactive, and it was delightful, and it was so much fun. And so if you need something fun for your team that you just want to bring folks together, highly recommend. I had no idea I was going to enjoy a magic show this much, but it was a lot of fun. So I'll be sure to include some links in the show notes in case that interests anyone. But yeah, magic. I'm doing jazz hands. People can't see it, but magic. +I like how you referred earlier, saying that today is more of like a tapas episode. And I'm realizing that all of my tapas are related to being pregnant, yelling, and magic shows, and I'm okay with that. [laughs] But on that note, what else is on your tapas plate? +CHRIS: Actually, a nice positive one that came into the world...I always like when we get those. So this is interesting because I was actually looking back at the history, and I had Gary Bernhardt on The Bike Shed back in Episode 269. We'll include a link in the show notes. But we talked a bunch about various things, including TypeScript. And I was lamenting what I saw as a pretty big edge case in TypeScript. +So the goal of TypeScript is like, all right, JavaScript exists, this is true. What can we do on top of that? Let's not fundamentally change it, but let's build a type system on top of it and try and make it so that we can enforce correctness but understand that JavaScript is a highly dynamic language and that we don't want to overconstrain and that we've got to meet it where it is. +And so one of the design decisions early on with TypeScript is if you have an array and you say like it's an array of integers, so you have typed that array to be this is an array of int, or it will be an array of number in JavaScript because JavaScript doesn't have integers; they only have numbers. Cool. [laughs] Setting aside other JavaScript variables here, you have an array of numbers. And so if you use element access to say, like, say the name of array is array of nums and then use brackets and you say zero, so get me the first element of that array. +TypeScript will infer the type of that to be a number. Of course, it's a number, right? You got an array of numbers, you take a number out of it, of course, you're going to have a number, except you know what's also an array of numbers? An empty array. Well, of course. So there's no way for TypeScript because that's a runtime thing, whether or not the array is full of things or not. Or imagine you get the third element from the array. Well, JavaScript will either return you the third element, which indeed is a number, or undefined because there's no third element in this array. +So that is an unfortunate but very understandable edge case that TypeScript was like, listen, this is how JavaScript works. So we're not going to…frankly, we don't think the people embracing TypeScript and bringing it into their world would accept this amount of noise because this is everywhere. Anytime you interact with an array, you are going to run into this, this sort of uncertainty of did I actually get the thing? And it's like, yeah, no, I know how many things are in the array that I'm working with. Spoiler, you maybe don't is the answer. +And so, we ran into this edge case in our codebase. We were accessing an element, but TypeScript was telling us, "Yes, definitively, you have an object of that type because you just got it out of an array, which is an array of that type." But we did not; we had undefined. And so we had, you know blah is not a method on undefined or whatever that classic JavaScript runtime error is. And I was like, well, that's very sad. +But now we get to the fun part of the story, TypeScript, as of version 4.1, which came out like the week that I recorded with Gary Bernhardt, which was interesting to look at the timeline here. TypeScript has added a new configuration. So a new strictness dial that you can configure in your tsconfig called noUncheckedIndexedAccess. So if you have an array and you are getting an element out of it by index, TypeScript will say, "Hey, you got to check if that's undefined," because to be clear, very much could be undefined. And I was so happy to find this. +We turned it on in our codebase. It found the error in the place that we actually had an error and then found a few others that I think probably had errored at some times. But it was just one of those for me very nice things to be able to dial up the strictness and enforce correctness within our codebase, and so I was very happy about it. Other folks may say that seems like too much work. And, you know, I get that, I get that take. I'm definitely on the side of I'm willing to go through the effort to have enforced correctness, but you know, that's a choice. +STEPH: Yeah, that's thoughtful. I like that, how you said you can dial up the strictness so then as you are introducing TypeScript, then people have that option. There is an argument there in the back of my head that's like, well, if you're introducing types, then you want to start more strict because then you're just creating problems for yourself down the road. But I also understand that that can make things very difficult to then introduce it to teams in existing codebases. So that seems like a really nice addition where then people can say, "Yeah, no, I really want the strictness. This is why I'm here," and then they can turn that on. +CHRIS: So TypeScript in the configuration has strict mode, so you say strict true. And that is a moving target with each new version of TypeScript. But it's their sort of [inaudible 28:14] set of things that are part of strict, but apparently, this one's not in it. So now I'm like, wait, can I have a stricter? Can I have a strictest option? Can I have dial it to 11, please? [laughs] Really rough me up and make sure my code is correct. +But it is the sort of thing like when we turn any of these on; it will find things in our codebase. Some of them, we have to appease the compiler even though we know the code to be correct. But the code is not provably correct as it sits in our file. So I am, again, happy to make that exchange. And I like that TypeScript as a project gives us configurability. But again, I am on team where's the strictest button? I would like to push that as hard as I can and live that life. +STEPH: Yeah, I like that phrasing that you just said about provably correct. That's nice. +CHRIS: That's the world I want to live in, everything you own in the box to the left, which is probably correct. +STEPH: [laughs] That's how that song goes. +CHRIS: Yeah. This is a reference to move errors to the left, which I think I've referenced before. But now that I'm just referencing Beyoncé and not the actual article, it's probably worth referencing the article, but the idea of, like, if a user hits an error, that's not great. So let's move it back to QA, that's a little further to the left in sort of the timeline. +But what if we could move it to an automated test in CI? But what if we could move it into your editor? What if we could move it even further to the left? And so, a type system tends to be sort of very far ratcheted up to the left. It's as early as possible that you can catch these. So again, to reference Beyoncé, everything you own in a box to the left. +STEPH: [singing] Everything you own in the box to the left. +CHRIS: Thank you for doing the needful work there. +STEPH: [laughs] +Mid-roll Ad +And now a quick break to hear from today's sponsor, Studio 3T. +When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. +And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. +You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free that's studio3t.com/free. +STEPH: I have a question for you that I'd really love to get your opinion on because I myself I’m waffling back and forth where someone brought up some really great points about a concern or just a question they had brought up around testing and i18n specifically. And I agree with the things that they're saying, but yet, there's also a part of me that doesn't, and so I'm Stephanie divided. And so, I'm trying to figure out where I stand on this. +So let me dive in and give you some context; I'm going to share the statement/question that they had asked. So here we go. "One of my priorities has been I should be able to review a test without having to reference any other code. References to i18n means that I have to go over to YAML and make sure the right keys have the right values, and that seems error-prone. +In some cases, a lack of a hit in the YAML defers to defaults. If the intent is to override the name of model attribute and error messages and it is coded incorrectly, the code fails silently without translating and uses the humanized attribute name, and that would go undetected. If libraries change structure, it might also fail silently as well, so to me, the only failsafe way is to be fully explicit in test." +So this goes with the idea that if you're writing tests and then you're testing text, but it’s on the screen or perhaps an email, that you're actually going to assert against that string that is shown to the user instead of referencing the i18n keys. And then that also backs up this person's idea that you really want to not have to jump around. If you're reading a test, everything you really need to know about that test should live very close by. +And I really agree with that initial statement; I want everything that's very close to the test, especially if it's anywhere in that expectation line, I really want it close, so I can understand what's the expectation, what's under test, what are the inputs, what's the expected outcome. So I wholeheartedly support that idea. +But yet, I am in the camp that I then will use YAML keys instead of providing that exact string because I do look at i18n as a helpful abstraction, and I want to trust that i18n is doing its job. And so that way, I don't have to provide that string that's there because then we're also choosing, okay, well, which language are we going to always use for our test? +So this is the part where I feel divided. So I'm going to walk you through some of the reasons that I really support this idea and other reasons that I still use the i18n keys and then get your take on it. So there is a part of me that when I'm using the i18n YAML keys, it does make me sad because it reduces the readability in tests. Sometimes the keys are really well named where maybe it's a mailer.welcomemessage. And I'm like, okay, I understand the gist. I don't need to go see the actual string. +I also think they highlighted a really good use case where if you're overriding behavior and it could default to something else, your test is still going to pass, and you don't actually know. So I could see the use case there where if you are overriding, then you want to be explicit about the string that you expect back. I also think there are some i18n messages that are fairly complex, and where then I really would like to see the string. +So if you are formatting a date or a time or you're passing in just a lot of variables, then there's a chance that I do want to see how did that actually get generated for the person who's going to be reading it versus just maybe it's garbage text that came out? And I want to validate that the message that we think we're crafting is actually the one that the user is going to see. +The case against actually being explicit, my biggest one is because then I do see i18n as a helpful abstraction. And I want to trust this abstraction that it's doing its job and it's doing it well. Because then if I do use explicit strings, it makes me sad if I change text from like hello to welcome, and now I have a failing test. I don't like that idea either. +So I'm torn between these two worlds of it is very nice to have everything that you need in a test to be able to understand what is the expectation, but then I also lean into this abstraction and reference the i18n keys. So, Chris, with all of that, that was a bit of a whirlwind, [laughs] what are your thoughts? How do you test this stuff? +CHRIS: Honestly, I'm surprised that you've got that much division in your own answer because for me, this is very obvious there's one...no, I'm kidding. This is obviously complicated. Similar to you, I think I'm going to have to give a grab bag of answers because I don't have a singular thought of like it is concretely this or that. +I tend to go for explicit strings and tests all the way to...so like the readability of a test, and the conciseness of a test is interesting. I will often see developers extract. Say they're creating a user with a specific email, and then they log in with that email later, and then they expect something else. And so the email is referenced a few times, and they'll extract that into a variable called email. And I personally will tend to not do that. I will inline the literal string like user@example.com, and I'll do it in a few places. And I'm fine with that duplication because I like the readability of any given line that you're reading. So I will make that trade-off within tests. +This is the thing I think we've talked about before, but the idea of DRY in tests is like I want to be careful applying that idea, Don't Repeat Yourself, to break apart the acronym. Those abstractions I will use them less than tests. And so I want the explicitness, I want the readability, I want to tell a little story, all of that feels true. +That said, to flip it around, one of the things that I'm hearing...so I think I'm hearing a part of this that is around well, we can fail silently because we fail symmetrically in both the implementation and our test. Then an assertion may actually match even though it's matching on a fallback. I think that's a configurable thing. I would actually want my test to raise if I'm referencing an i18n key that is not defined. +Now, granted, that's different for languages. And maybe this becomes a more complex story of like in production; in a different locale, it will fail because we don't have 100% parity across all our locale files. But fundamentally, I want to make sure that at least exists in our base, which I think typically would be en-US as the locale. I want to make sure all keys are looked up and found, and it's an error otherwise in our test. So that's a feeling. But am I misunderstanding that part of the story or how that configuration typically works? +STEPH: No, I think you've got it. But just to make sure we're on the same page, so if you reference a key that doesn't exist, then it is going to fail. So at least you have your test failure is going to let you know that you've referenced something that doesn't exist. But if you are referencing, like if you want to override the defaults that Rails or i18n has provided for a model and say for an error message, if you reference that, but you want to override it, but then you've forgotten, that does exist. +So you're not going to get the failure; you're going to get a different message. So it's probably not a terrible experience for the user. It's not going to crash. They're going to see something, but they're not going to see the custom message that you intended them to see. +CHRIS: Gotcha. Okay, well, just to name it, the thing that I was describing, I don't know that that would be the configuration for every system. So I would strongly encourage any system where i18n just has a singular behavior which is we fall back to the key. I want my test to absolutely tell me if that's happening. And that should be a failure of the test. But to the discoverability documentation bit, I do wonder if tooling can actually help answer the question. +And as I was describing the wonderful experience I had on GitHub the other day, viewing code as just static characters in a file is both true and also, I think increasingly, a limited view of it. We have editors, and we have code hosting tools that can understand semantically our code a little bit better. There's got to be like 20 Different VS Code plugins that, when you hover on an i18n reference, it will do the lookup for you. That feels like a thing that exists, and if it doesn't, well, now I’ve nerd-sniped myself, and I got a weekend project. JK, I'm definitely not building that this weekend. +But that feels like can we use that to solve this? Maybe not. But that's just another thought of where we have these limitations where it's static, like those abstractions can be useful. But if we can very quickly dereference them, then the cost of the abstraction or that separation becomes smaller, and so the pain is reduced. And I wonder if that's a way to sort of offset it. +STEPH: If I can poke at that a little bit more, because I think you're touching on something that I haven't expressed or thought through explicitly, but it's the idea of, like, why do I like the abstraction? What is it that's drawing me towards using these keys? And I think it's because most of the cases, I don't care. I don't care what the string is, and so that feels nice. Like, I understand that, yes, we're referencing something. If that key didn't exist, I'm going to see a failure. +So I know that there's text there, and that's why I do lean into referencing the keys instead of the text because it feels good to not have to care about that stuff. And if we do make changes to the text, then it suddenly doesn't fail, and then I have to go update a test because we added a period or added a comma. I think that's the path of more sadness for me. And my goal is always a path of least sadness. So I think that's why I lean into it [laughs], I'm guessing. Is that why you lean into it as well? Or what do you like about referencing the keys over the explicit text? +CHRIS: No, I think I share your inclination there, and the reason that you're in favor of it, and I think the consistency like if we're going to use i18n, then we should lean in because it's a non-trivial thing to do like porting to i18n projects, and they're tricky. Getting it right from the first step is also tricky. If you're going to do it, then let's lean in, and thus let's use that abstraction overall. But yeah, same ideas as you. +STEPH: Cool. I think that helps validate where I'm at in terms of how I rationalize about this where ultimately, I do like leaning into that abstraction. And as you'd mentioned, some of those porting projects, I haven't been on one specifically, but I've seen that they are a lot of work. And so, if we have that in our system, then we want to continue to use it. +It does reduce some of the readability. Like you said, maybe there's a VS Code plugin or some way that then we can help people be able to see if they want that full context in the test and not have to jump over to YAML. But yeah, otherwise, unless it's overriding default behavior or complex, then that's what I'm going to go with is with the keys. +But I really appreciate this person's very thoughtful question and approach to testing because, normally or typically, I fully agree with I want full context in the test. And this one was one of those outliers that came up for me, and I had to really think through all the feelings and the reasons that I have for those feelings. On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeee!!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases.

+ +

Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Emma Bostian
+Ladybug Podcast
+Gerrit
+Gregg Tobo the Magician
+Sean Wang - swyx - better twitter search
+Twemex
+GitHub Pull Request File Tree Beta
+Sam Zimmerman - CEO of Sagewell Financial on Giant Robots
+TypeScript 4.1 feature
+The Bike Shed: 269: Things are Knowable (Gary Bernhardt)
+TSConfig Reference - Docs on every TSConfig option
+Rails I18n

+ +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. There are a couple of new things in my world, so one of them that I wanted to talk about is the fact that being pregnant is hard. I feel like this is probably a known thing, but I feel like I don't hear it talked about as much as I'd really like, especially in sort of like a professional context. And so I just wanted to share for anyone else that may be listening, if you're also pregnant, this is hard.

+ +

And I also really appreciate my team. Going through the first trimester is typically where you experience a lot of morning sickness and fatigue, and I had all of that. And so I was at the point that most of my days, I didn't even start till about noon and even some days, starting at noon was a struggle. And thankfully, the thoughtbot client that I'm working with most of the teams are on West Coast hours, so that worked out pretty well.

+ +

But I even shared a post internally and was like, "Hey, I'm not doing great in the mornings. And so I really can't facilitate any morning meetings. I can't be part of some of the hiring intros that we do," because we like to have a team lead provide a welcoming and then closing for anyone that's coming for interview day. I couldn't do those, and those normally happen around 9:00 a.m. for Eastern Time. And everybody was super supportive of it. So I really appreciate all of thoughtbot and my managers and team being so great about this. Also, the client team they're wonderful.

+ +

It turns out growing a little human; I'm learning how hard it is and working full time. It's an interesting challenge. Oh, and as part of that appreciation because…so there's just not a lot of women that I've worked with. This may be one of those symptoms of being in tech where one, I haven't worked with tons of women, and then two, working with a woman who is also pregnant and going through that as well. So it's been a little bit isolating in that experience.

+ +

But there is someone that I follow on Twitter, @EmmaBostian. She's also one of the co-hosts for the Ladybug Podcast. And she has been just sharing some of her, like, I am two months sleep deprived. She's had her baby now, and she is sharing some of that journey. And I really appreciate people who just share that journey and what they're going through because then it helps normalize it for me in terms of what I'm feeling. I hope this helps normalize it for anybody else that might be listening too.

+ +

CHRIS: I certainly can't speak to the specifics of being pregnant. But I do think it's wonderful for you to use this space that we have here to try and forward that along and say what your experience is like and share that with folks and hopefully make it a little bit better for everyone else out there. Also, you snuck in a sneaky pro-tip there, which is work on the East Coast and have a West Coast team. That just sounds like the obvious correct way to go about this.

+ +

STEPH: That has worked out really well and been very helpful for me. I'm already not a great morning person; I've tried. I've really strived at times to be a morning person because I just have this idea in my head morning people get more stuff done. I don't think that's true, but I just have that idea. And I'm not the world's best morning person, so it has worked out for many reasons but yeah, especially in helping me get through that first trimester and also just supporting family and other things that are going on.

+ +

Oh, I also learned a pro-tip about Twitter. This is going to seem totally random, but it was relevant when I was searching for stuff on Twitter [laughs] that was related to tech and pregnancy. But I learned...because I wanted to be able to search for something that someone that I follow what they said but I couldn't remember who said it.

+ +

And so I found that in the search bar, I can add filter:follows. So you can have your search term like if you're looking for cake or pregnancy, or sleep-deprived and then look for filter:follows, and then that will filter the search results to everybody that you follow. I imagine that that probably works for followers too, but I haven't tried it.

+ +

CHRIS: I like the left turn you took us on there but still keeping it connected. On the topic of Twitter search, they apparently have a very powerful search, but it's also hidden, and you got to know the specific syntax and whatnot. But there is a wonderful project by Shawn Wang, AKA Swyx, on the internet, bettertwitter.netlify.com is the URL for it. I will share a link to his tweet introducing it. But it's a really wonderful tool that just provides a UI for all of these different filters and configurations. And both make discoverability that much better and then also make it easy to just compose one of these searches and use that.

+ +

The other thing that I'll recommend is, I think it's a Chrome plugin. I'm guessing is what I'm working with here like a browser extension, but it's called Twemex, T-W-E-M-EX. And there's a sidebar in Twitter now, which just seems wonderful and useful. So as I'm looking at a Swyx post here, or a tweet as they're called on Twitter because I know that vernacular, there's a sidebar which is specific to Shawn Wang.

+ +

And there's a search at the top so I can search within it. But it's just finding their most popular tweets and putting that on a sidebar. It's a very useful contextual addition to Twitter that I found just awesome. So that combination of things has made my Twitter experience much better. So yeah, we'll have show notes for both of those as well.

+ +

STEPH: Nice. I did not know about those. This may cause someone to laugh at me because maybe it's easier than I think. But I can never remember that advanced search that Twitter does offer; I have to search it every time. I just go to Google, and I'm like, advanced Twitter search, and then it brings up a site for me, and then I use that as the one that Twitter does provide. But yeah, from the normal UI, I don't know how to get there. Maybe I haven't tried hard enough. Maybe it's hidden.

+ +

CHRIS: It's like they're hiding it.

+ +

STEPH: Yeah, one of those. [laughs]

+ +

CHRIS: It's very costly. They have to like MapReduce the entire internet in order to make that search work. So they're like, well, what if we hide it because it's like 50 cents per query? And so maybe we shouldn't promote this too much.

+ +

STEPH: [laughs]

+ +

CHRIS: And let's just live in the moment, everybody. Let's just swim in the Twitter stream rather than look back at the history. I make guesses about the universe now.

+ +

STEPH: [laughs] On a different note, I also discovered at thoughtbot in our variety of Slack channels that we have a yelling channel, and I had not used it before. I had not hung out there before. It's a delightful channel. It's a place that you just go, and you type in all caps. You can yell about anything that you would like to. And I specifically needed to yell about Gerrit, which is the replacement or the alternative that we're using for GitHub or GitLab, or Bitbucket, or any of those services.

+ +

So we're using Gerrit, and I've been working to feel comfortable with the UI and then be able to review CRs and things like that. My vernacular is also changing because my team refers to them as change requests instead of pull requests. So I'm floating back and forth between CRs and PRs. And because I'm in Gerrit world, I missed some of the updates that GitHub made to their pull request review screen. And so then I happened to hop in GitHub one day, and I saw it, and I was like, what is this? So that was novel.

+ +

But going back to yelling, I needed to yell about Gerrit because I have not found a way to collaborate with someone who has already pushed up changes. I have found ways that I can pull their changes which then took a little while. I found it in a sneaky little tab called download. I didn't expect it to be there. But then the actual snippet it's like, run this in your terminal, and this is then how you pull down the changes. And I'm like, okay, so I did that.

+ +

But I can't push to their existing changes because then I get like, well, you're not the owner, so we're going block you, which is like, cool, cool, cool. Okay, I kind of get that because you don't want me messing up somebody else's content or something that they've done. But I really, really, really want to collaborate with this person, and we're trying to do something together, and you're blocking me. And so I had to go to the yelling channel, and I felt better. And I'm yelling again. [laughs] Maybe I don't feel that great because I'm getting angry again talking about it.

+ +

CHRIS: You vented a little into the yelling channel; maybe not everything, though.

+ +

STEPH: Yeah, I still have more to vent because it's made life hard. Every time I wanted to push up a change or pull down someone else's changes, there are now all these CRs that then I just have to go and abandon, which is then the terminology for then essentially closing it and ignoring it, so I'm constantly going through.

+ +

And if I do want to pull in changes or collaborate, then there's a flow of either where I abandon mine, or I pull in their changes, but then I have to squash everything because if you push up multiple commits to Gerrit, it's going to split those commits into different CRs, don't like that. So there are a couple of things that have been pain points. And yeah, so plus-one for yelling channels, let people get it out.

+ +

CHRIS: Okay, so definitely some feelings that you are working through here. I'm happy to work together as a team to get through some of them. One thing that I want to touch on is you very quickly hinted at GitHub has got a bunch of new things that are cool. I want to talk about those. But I want to touch [laughs] on an anecdote. You talked about pushing something up to someone else's branch. You're like, oh, you know, I made some changes locally, and I'm going to push them up.

+ +

I had an interesting experience once where I was interacting with another developer. I had done some code review. They weren't quite understanding where I was. They had a lot of questions. And finally, I said, you know what? This will just be easier. Here, I pushed up a commit to your branch, so now you can see what I'm talking about. And I thought of this as a very innocuous act, but it was not interpreted that way. That individual interpreted it in a very aggressive sort of; it was not taken well.

+ +

And I think part of that was related to I think of Git commits as just these little ephemeral things where you're like, throw it out, feel free. This is just the easiest way for me to communicate this change in the context of the work that you're doing. I thought I was doing a nice favor thing here. That was not how it went. We had a good conversation after I got to the heart of where we both were emotionally on this thing. It was interesting. The interaction of emotion and tech is always interesting.

+ +

But as a result, I'm very, very careful with that now. I do think it's a great way as long as I've gotten buy-in from the person beforehand. But I will always spot check and be like, "Hey, just to confirm, I can just push up a commit to your branch, but are you okay with that? Is that fine with you?" So I've become very cautious with that.

+ +

STEPH: Yeah, that feels like one of those painful moments where it highlights that the people that you work with that you are accustomed to having a certain level of trust or default trust with those individuals, and then working with someone else that they don't have that where the cup is half-full in terms of that trust, or that this person means well kind of feelings towards a colleague or towards someone that they're working with.

+ +

So it totally makes sense that it's always good to check and just to be like, "Hey, I'd love to push up some changes to your branch. Is that cool?" And then once you've established that, then that just makes it easier. But I do remember that happening, and yeah, that was a bit painful and shocking because we didn't see that coming and then learned from it.

+ +

CHRIS: I do think it's an important thing to learn, though, because for me, in that moment, this was this throwaway operation that I thought almost nothing of, but then another individual interpreted it in a very different way. And that can happen, that can happen across tons of different things. And I don't even want to live in the idealized world where it's just tech; we're just pushing around zeros and ones; there's no human to this. But no, I actually believe it's a deeply human thing that we're doing here.

+ +

It's our job to teach the computers to be a little closer to us humans or something like that. And so it was a really pointed clarification of that for me where it was this thing that I didn't even think once about, no less twice, and yet someone else interpreted it in such a different way. So it was a useful learning situation for me.

+ +

STEPH: Yeah, I totally agree. I think that's a really wise default to have to check in with people before assuming that they'll be comfortable with something that we're comfortable with.

+ +

CHRIS: Indeed. But shifting back to what you mentioned of GitHub, a bunch of new stuff came in GitHub, and you were super excited about it. And then you went on to say other things about another system. [laughs] But let's talk about the great things in GitHub. What are the particular ones that have caught your eye? I've seen some, but I'm intrigued. Let's compare notes.

+ +

STEPH: So this is one of those where I hadn't seen GitHub in quite a while, and then I hopped in, and I was like, this is different. But some of the things that did stand out to me right away is that on the left-hand side, I can see all of the files that have been changed, and so that's a really nice tree where I just then immediately know.

+ +

Because that was one of the things that I often did going to a PR is that I would see what files are involved in this change because it was just a nice overview of what part of the applications am I walking through? Are there tests for this? Have they altered or added tests? And so I really like that about it. I'm sure there's other stuff. But that is the main thing that stood out to me. How about you?

+ +

CHRIS: Yeah, that sidebar file tree is very, very nice, which I find surprising because I don't use a file tree in my editor. I only do fuzzy finding to jump to files. But I think there's something about whenever GitHub had the file list; these are all the files that are changed. I'm like, this is just noise. I can't look at this and get anything out of it. But the file tree is so much more...there's a shape to it that my brain can sort of pattern match on. And it's just a much more discoverable way to observe that information. So I've really loved that. That was a wonderful one.

+ +

The other one that I was surprised by is GitHub semantic code analysis; stuff has gotten much, much better over time subtly. I didn't even notice this happening. But I was discussing something with someone today, and we were looking at it on GitHub, and I just happened to click on an identifier, and it popped up a little thing that says, "Oh, do you want to hop to the references or the definition of this?" I was like, that is what I want to do. And so I hopped to the definition, hopped to the definition of another thing, and was just jumping around in the code in a way that I didn't know was available. So that was really neat.

+ +

But then also, I was in a pull request at one point, and someone was writing a spec, and they had introduced a helper just like stub something at the bottom of a given spec file. And it's like, I feel like we have this one already. And I just clicked on the identifier. I think it might have actually been a matcher in RSpec, so it was like, have alert. And I was like, oh, I feel like we have this one, a matcher specific to flash message alerts on the page. And I clicked on it, and GitHub provided me a nice little inline dialog that showed me all of the definitions of have alert, which I think we were up to like four of them at that point.

+ +

So it had been copied and pasted across a couple of different files, which I think is totally fine and a great way to start, but they were very similar implementations. I was like, oh, looks like we actually already have this in a couple of places, maybe we clean it up and extract it to a common spec support thing, and ta-da, I was able to do all of that from the GitHub pull requests UI. And I was like, this is awesome. So kudos to the GitHub team for doing some nifty stuff. Also, can I get into the merge queue? Thank you.

+ +

...
+STEPH: [laughs] There it is. That is very cool. I didn't know I could do that from the pull request screen. I've seen it where if I'm browsing code that, then I can see a snippet of where everything's defined and then go there, but I hadn't seen that from the pull request. I did find the changelogs for GitHub that talk about the introduction of having the tree, so we'll be sure to include a link in the show notes for that too. But yes, thank you for letting me use our podcast as a yelling channel. It's been delightful. [laughs]

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: Well, speaking of podcasts, actually, there was an interesting thing that happened where the CEO of Sagewell Financial, the company of which I am the CTO of, Sam Zimmerman is his name, and he went on the Giant Robots Podcast with Chad a couple of weeks ago. So that is now available. We'll link to that in the show notes. I'll be honest; it was a very interesting experience for me. I listened to portions of it. If we're being honest, I searched for my name in the transcript, and it showed up, and I was like, okay, that's cool. And it was interesting to hear two different individuals that I've worked with either in the past or currently talking about it.

+ +

But then also, for anyone that's been interested in what I'm building over at Sagewell Financial and wants to hear it from someone who can probably do a much better job of pitching and describing the problem space that we're working in, and all of the fun challenges that we have, and that we're hopefully living up to and building something very interesting, I think Sam does a really fantastic job of that. That's the reason I'm at the company, frankly.

+ +

So yeah, if anyone wants to hear a little bit more about that, that is a very interesting episode. It was a little weird for me to listen to personally, but I think everybody else will probably have a normal experience listening to it because they're not the CTO of the company. So that's one thing.

+ +

But moving on, I feel like today's going to be a grab bag episode or tapas episode, lots of small plates, as we were discussing as we were prepping for this episode. But to share one little thing that happened, I've been a little more removed from the code of late, something that we've talked about on and off in previous episodes. Thankfully, I have a wonderful team that's doing an absolutely fantastic job moving very rapidly through features and bug fixes and all those sorts of things.

+ +

But also, I'm just not as involved even in code review at this point. And so I saw one that snuck through today that, I'm going to be honest, I had an emotional reaction to. I've talked myself down; we're fine now. But the team collectively made the decision to move from a line length of 80 characters to a line length of 120 characters, and I had some feelings.

+ +

STEPH: Did you fire everybody? [laughs]

+ +

CHRIS: No. I immediately said, doesn't really matter. This is the whole conversation around auto-formatting tools is like we're just taking the decision away. I personally am a fan of the smaller line length because I like to have multiple files open left to right. That is my reason for it, but that's my reason. A collective of the developers that are frankly working more in the code than I am at this point decided this was meaningful. It was a thing that we could automate. I think that we can, you know, it's not a thing that we have to manage. So I was like, cool. There we go.

+ +

The one thing that I did follow up on I was like, okay; y'all snuck this one in, it's fine, I'm fine with it. I feel fine; everything's fine. But let's add that to the git-blame-ignore-revs file, which is a useful thing to know about. Because otherwise, we have a handful of different changes like this where we upgrade Prettier, and suddenly, the manner in which it formats the files changes, so we have to reformat everything at once. And this magical file that exists in Git to say, "Hey, ignore this revision because it is not relevant to the semantic history of the app," and so it also takes that decision out of the consideration like yeah, should we reformat or not? Because then it'll be noisy. That magical file takes that decision away, and so I love that.

+ +

STEPH: I so love the idea because you took vacation recently twice. So I love the idea of there was a little coup and people are applauding, and they're like, while Chris is on vacation, we're going to merge this change [laughs] that changes the character line. And yeah, that brings me joy. Well, I'm glad you're working through it. Sounds like we're both working through some hard emotional stuff. [laughs]

+ +

CHRIS: Life's tricky, is all I'm going to say.

+ +

STEPH: I am curious, what prompted the 80 characters versus 120? This is one of those areas that's like, yeah, I have my default preference like you said. But I'm more intrigued just when people are interested in changing it and what goes with it. So do you remember one of the reasons that 120 just suited their preferences better?

+ +

CHRIS: Frankly, again, I was not super involved in the discussion or what led them to it.

+ +

STEPH: [laughs]

+ +

CHRIS: My guess is 120 is used...I think 80 is a pretty common one. I think 120 is another of the common ones. So I think it's just a thing that exists out there in the mindshare. But also, my guess is they made the switch to 120 and then reformatted a few files that had like, ah, this is like 85 characters, and that's annoying. What does it look like if we bump it up?

+ +

And so 120 provided a meaningful change of like, this is a thing that splits to four lines if we have an 80 character thing, or it's one line if it's 120 characters, which is a surprising thing to say, but that's actually the way it plays out in certain cases because the way Prettier will break lines isn't just put stuff on the next line always. It's got to break across multiple lines, actually. All right, now that we're back in the opinion space, I have a strong one.

+ +

STEPH: This is The Bikeshed. We can live up to that name. [laughs]

+ +

CHRIS: So I do want an additional configuration in Prettier Ruby. This is the thing I'll say. Maybe I can chase down Kevin Newton and see if he's open to this. But when Prettier does break method call with arguments going into it but no parens on that method call, and it breaks out to multiple lines, it does the dangling indent thing, which I do not like. I find it distasteful; I find it noisy, the shape of the code. I'm a big fan of the squint test. I know that from Sandi Metz, I believe, or maybe it's Avdi Grimm. I associate it with both of them in my mind.

+ +

But it's just a way to look at the code and kind of squint, and you see the shape of it, and it tells you something. And when the lines break in that weird way, and you have these arbitrary dangling indents, the shape of the code is broken up. And I don't feel so strongly. I actually regularly stop myself from commenting on pull requests on this because it's very easy. All you need to do is add explicit parens, and then Prettier will wrap the line in what I believe is a much more aesthetically pleasing, concise, consistent, lots of other good adjectives here that are definitely just my preferences and not facts about the world.

+ +

But so what I want is, Prettier, hey, if you're going to break this line across multiple lines, insert the parens. Parens are no longer optional for breaking across multiple lines; parens are only optional within a given line. So if we're not breaking across lines, I want that configuration because this is now one of those things where I could comment on this. And if they added the optional parens, then Prettier would reform it in a different way. And I want my auto formatter don't give me ways to do stuff. Like, constrain me more but also within the constraints of the preferences that I have, please, thank you.

+ +

STEPH: I love all the varying levels there [laughter] of you want a thing, but you know it's also very personal to you and how you're walking that line and hopping back and forth on each side. I also love the idea. We have the idea of clean code. I really want something that's called distasteful code now [laughs] where you just give examples of distasteful code, yes. Well, I wish you good luck in your journey [laughs] and how this goes and how you continue to battle.

+ +

I also appreciate that you mentioned when you're reviewing code how you know it's something that you really want, but you will refrain from commenting on that. I just appreciate when people have that filter to recognize, like, is this valuable? Is it important? Or, like you said, how can we just make this more of the default so then we don't even have to talk about it? And then lean into whatever the default the team goes with.

+ +

CHRIS: Well, thank you. I very much appreciate that because, frankly, it's been very difficult.

+ +

STEPH: I do have something I want to yell about but in a very positive way or pranting as we determined or, you know, raving, the actual real term that wonderful listeners pointed out to us.

+ +

CHRIS: Prant for life. That's my stance.

+ +

STEPH: We had a magic show at thoughtbot. It was all remote, but the wonderful Gregg Tobo, the magician, performed a magic show for us where we all showed up on Zoom. And it was interactive, and it was delightful, and it was so much fun. And so if you need something fun for your team that you just want to bring folks together, highly recommend. I had no idea I was going to enjoy a magic show this much, but it was a lot of fun. So I'll be sure to include some links in the show notes in case that interests anyone. But yeah, magic. I'm doing jazz hands. People can't see it, but magic.

+ +

I like how you referred earlier, saying that today is more of like a tapas episode. And I'm realizing that all of my tapas are related to being pregnant, yelling, and magic shows, and I'm okay with that. [laughs] But on that note, what else is on your tapas plate?

+ +

CHRIS: Actually, a nice positive one that came into the world...I always like when we get those. So this is interesting because I was actually looking back at the history, and I had Gary Bernhardt on The Bike Shed back in Episode 269. We'll include a link in the show notes. But we talked a bunch about various things, including TypeScript. And I was lamenting what I saw as a pretty big edge case in TypeScript.

+ +

So the goal of TypeScript is like, all right, JavaScript exists, this is true. What can we do on top of that? Let's not fundamentally change it, but let's build a type system on top of it and try and make it so that we can enforce correctness but understand that JavaScript is a highly dynamic language and that we don't want to overconstrain and that we've got to meet it where it is.

+ +

And so one of the design decisions early on with TypeScript is if you have an array and you say like it's an array of integers, so you have typed that array to be this is an array of int, or it will be an array of number in JavaScript because JavaScript doesn't have integers; they only have numbers. Cool. [laughs] Setting aside other JavaScript variables here, you have an array of numbers. And so if you use element access to say, like, say the name of array is array of nums and then use brackets and you say zero, so get me the first element of that array.

+ +

TypeScript will infer the type of that to be a number. Of course, it's a number, right? You got an array of numbers, you take a number out of it, of course, you're going to have a number, except you know what's also an array of numbers? An empty array. Well, of course. So there's no way for TypeScript because that's a runtime thing, whether or not the array is full of things or not. Or imagine you get the third element from the array. Well, JavaScript will either return you the third element, which indeed is a number, or undefined because there's no third element in this array.

+ +

So that is an unfortunate but very understandable edge case that TypeScript was like, listen, this is how JavaScript works. So we're not going to…frankly, we don't think the people embracing TypeScript and bringing it into their world would accept this amount of noise because this is everywhere. Anytime you interact with an array, you are going to run into this, this sort of uncertainty of did I actually get the thing? And it's like, yeah, no, I know how many things are in the array that I'm working with. Spoiler, you maybe don't is the answer.

+ +

And so, we ran into this edge case in our codebase. We were accessing an element, but TypeScript was telling us, "Yes, definitively, you have an object of that type because you just got it out of an array, which is an array of that type." But we did not; we had undefined. And so we had, you know blah is not a method on undefined or whatever that classic JavaScript runtime error is. And I was like, well, that's very sad.

+ +

But now we get to the fun part of the story, TypeScript, as of version 4.1, which came out like the week that I recorded with Gary Bernhardt, which was interesting to look at the timeline here. TypeScript has added a new configuration. So a new strictness dial that you can configure in your tsconfig called noUncheckedIndexedAccess. So if you have an array and you are getting an element out of it by index, TypeScript will say, "Hey, you got to check if that's undefined," because to be clear, very much could be undefined. And I was so happy to find this.

+ +

We turned it on in our codebase. It found the error in the place that we actually had an error and then found a few others that I think probably had errored at some times. But it was just one of those for me very nice things to be able to dial up the strictness and enforce correctness within our codebase, and so I was very happy about it. Other folks may say that seems like too much work. And, you know, I get that, I get that take. I'm definitely on the side of I'm willing to go through the effort to have enforced correctness, but you know, that's a choice.

+ +

STEPH: Yeah, that's thoughtful. I like that, how you said you can dial up the strictness so then as you are introducing TypeScript, then people have that option. There is an argument there in the back of my head that's like, well, if you're introducing types, then you want to start more strict because then you're just creating problems for yourself down the road. But I also understand that that can make things very difficult to then introduce it to teams in existing codebases. So that seems like a really nice addition where then people can say, "Yeah, no, I really want the strictness. This is why I'm here," and then they can turn that on.

+ +

CHRIS: So TypeScript in the configuration has strict mode, so you say strict true. And that is a moving target with each new version of TypeScript. But it's their sort of [inaudible 28:14] set of things that are part of strict, but apparently, this one's not in it. So now I'm like, wait, can I have a stricter? Can I have a strictest option? Can I have dial it to 11, please? [laughs] Really rough me up and make sure my code is correct.

+ +

But it is the sort of thing like when we turn any of these on; it will find things in our codebase. Some of them, we have to appease the compiler even though we know the code to be correct. But the code is not provably correct as it sits in our file. So I am, again, happy to make that exchange. And I like that TypeScript as a project gives us configurability. But again, I am on team where's the strictest button? I would like to push that as hard as I can and live that life.

+ +

STEPH: Yeah, I like that phrasing that you just said about provably correct. That's nice.

+ +

CHRIS: That's the world I want to live in, everything you own in the box to the left, which is probably correct.

+ +

STEPH: [laughs] That's how that song goes.

+ +

CHRIS: Yeah. This is a reference to move errors to the left, which I think I've referenced before. But now that I'm just referencing Beyoncé and not the actual article, it's probably worth referencing the article, but the idea of, like, if a user hits an error, that's not great. So let's move it back to QA, that's a little further to the left in sort of the timeline.

+ +

But what if we could move it to an automated test in CI? But what if we could move it into your editor? What if we could move it even further to the left? And so, a type system tends to be sort of very far ratcheted up to the left. It's as early as possible that you can catch these. So again, to reference Beyoncé, everything you own in a box to the left.

+ +

STEPH: [singing] Everything you own in the box to the left.

+ +

CHRIS: Thank you for doing the needful work there.

+ +

STEPH: [laughs]

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free that's studio3t.com/free.

+ +

STEPH: I have a question for you that I'd really love to get your opinion on because I myself I’m waffling back and forth where someone brought up some really great points about a concern or just a question they had brought up around testing and i18n specifically. And I agree with the things that they're saying, but yet, there's also a part of me that doesn't, and so I'm Stephanie divided. And so, I'm trying to figure out where I stand on this.

+ +

So let me dive in and give you some context; I'm going to share the statement/question that they had asked. So here we go. "One of my priorities has been I should be able to review a test without having to reference any other code. References to i18n means that I have to go over to YAML and make sure the right keys have the right values, and that seems error-prone.

+ +

In some cases, a lack of a hit in the YAML defers to defaults. If the intent is to override the name of model attribute and error messages and it is coded incorrectly, the code fails silently without translating and uses the humanized attribute name, and that would go undetected. If libraries change structure, it might also fail silently as well, so to me, the only failsafe way is to be fully explicit in test."

+ +

So this goes with the idea that if you're writing tests and then you're testing text, but it’s on the screen or perhaps an email, that you're actually going to assert against that string that is shown to the user instead of referencing the i18n keys. And then that also backs up this person's idea that you really want to not have to jump around. If you're reading a test, everything you really need to know about that test should live very close by.

+ +

And I really agree with that initial statement; I want everything that's very close to the test, especially if it's anywhere in that expectation line, I really want it close, so I can understand what's the expectation, what's under test, what are the inputs, what's the expected outcome. So I wholeheartedly support that idea.

+ +

But yet, I am in the camp that I then will use YAML keys instead of providing that exact string because I do look at i18n as a helpful abstraction, and I want to trust that i18n is doing its job. And so that way, I don't have to provide that string that's there because then we're also choosing, okay, well, which language are we going to always use for our test?

+ +

So this is the part where I feel divided. So I'm going to walk you through some of the reasons that I really support this idea and other reasons that I still use the i18n keys and then get your take on it. So there is a part of me that when I'm using the i18n YAML keys, it does make me sad because it reduces the readability in tests. Sometimes the keys are really well named where maybe it's a mailer.welcomemessage. And I'm like, okay, I understand the gist. I don't need to go see the actual string.

+ +

I also think they highlighted a really good use case where if you're overriding behavior and it could default to something else, your test is still going to pass, and you don't actually know. So I could see the use case there where if you are overriding, then you want to be explicit about the string that you expect back. I also think there are some i18n messages that are fairly complex, and where then I really would like to see the string.

+ +

So if you are formatting a date or a time or you're passing in just a lot of variables, then there's a chance that I do want to see how did that actually get generated for the person who's going to be reading it versus just maybe it's garbage text that came out? And I want to validate that the message that we think we're crafting is actually the one that the user is going to see.

+ +

The case against actually being explicit, my biggest one is because then I do see i18n as a helpful abstraction. And I want to trust this abstraction that it's doing its job and it's doing it well. Because then if I do use explicit strings, it makes me sad if I change text from like hello to welcome, and now I have a failing test. I don't like that idea either.

+ +

So I'm torn between these two worlds of it is very nice to have everything that you need in a test to be able to understand what is the expectation, but then I also lean into this abstraction and reference the i18n keys. So, Chris, with all of that, that was a bit of a whirlwind, [laughs] what are your thoughts? How do you test this stuff?

+ +

CHRIS: Honestly, I'm surprised that you've got that much division in your own answer because for me, this is very obvious there's one...no, I'm kidding. This is obviously complicated. Similar to you, I think I'm going to have to give a grab bag of answers because I don't have a singular thought of like it is concretely this or that.

+ +

I tend to go for explicit strings and tests all the way to...so like the readability of a test, and the conciseness of a test is interesting. I will often see developers extract. Say they're creating a user with a specific email, and then they log in with that email later, and then they expect something else. And so the email is referenced a few times, and they'll extract that into a variable called email. And I personally will tend to not do that. I will inline the literal string like user@example.com, and I'll do it in a few places. And I'm fine with that duplication because I like the readability of any given line that you're reading. So I will make that trade-off within tests.

+ +

This is the thing I think we've talked about before, but the idea of DRY in tests is like I want to be careful applying that idea, Don't Repeat Yourself, to break apart the acronym. Those abstractions I will use them less than tests. And so I want the explicitness, I want the readability, I want to tell a little story, all of that feels true.

+ +

That said, to flip it around, one of the things that I'm hearing...so I think I'm hearing a part of this that is around well, we can fail silently because we fail symmetrically in both the implementation and our test. Then an assertion may actually match even though it's matching on a fallback. I think that's a configurable thing. I would actually want my test to raise if I'm referencing an i18n key that is not defined.

+ +

Now, granted, that's different for languages. And maybe this becomes a more complex story of like in production; in a different locale, it will fail because we don't have 100% parity across all our locale files. But fundamentally, I want to make sure that at least exists in our base, which I think typically would be en-US as the locale. I want to make sure all keys are looked up and found, and it's an error otherwise in our test. So that's a feeling. But am I misunderstanding that part of the story or how that configuration typically works?

+ +

STEPH: No, I think you've got it. But just to make sure we're on the same page, so if you reference a key that doesn't exist, then it is going to fail. So at least you have your test failure is going to let you know that you've referenced something that doesn't exist. But if you are referencing, like if you want to override the defaults that Rails or i18n has provided for a model and say for an error message, if you reference that, but you want to override it, but then you've forgotten, that does exist.

+ +

So you're not going to get the failure; you're going to get a different message. So it's probably not a terrible experience for the user. It's not going to crash. They're going to see something, but they're not going to see the custom message that you intended them to see.

+ +

CHRIS: Gotcha. Okay, well, just to name it, the thing that I was describing, I don't know that that would be the configuration for every system. So I would strongly encourage any system where i18n just has a singular behavior which is we fall back to the key. I want my test to absolutely tell me if that's happening. And that should be a failure of the test. But to the discoverability documentation bit, I do wonder if tooling can actually help answer the question.

+ +

And as I was describing the wonderful experience I had on GitHub the other day, viewing code as just static characters in a file is both true and also, I think increasingly, a limited view of it. We have editors, and we have code hosting tools that can understand semantically our code a little bit better. There's got to be like 20 Different VS Code plugins that, when you hover on an i18n reference, it will do the lookup for you. That feels like a thing that exists, and if it doesn't, well, now I’ve nerd-sniped myself, and I got a weekend project. JK, I'm definitely not building that this weekend.

+ +

But that feels like can we use that to solve this? Maybe not. But that's just another thought of where we have these limitations where it's static, like those abstractions can be useful. But if we can very quickly dereference them, then the cost of the abstraction or that separation becomes smaller, and so the pain is reduced. And I wonder if that's a way to sort of offset it.

+ +

STEPH: If I can poke at that a little bit more, because I think you're touching on something that I haven't expressed or thought through explicitly, but it's the idea of, like, why do I like the abstraction? What is it that's drawing me towards using these keys? And I think it's because most of the cases, I don't care. I don't care what the string is, and so that feels nice. Like, I understand that, yes, we're referencing something. If that key didn't exist, I'm going to see a failure.

+ +

So I know that there's text there, and that's why I do lean into referencing the keys instead of the text because it feels good to not have to care about that stuff. And if we do make changes to the text, then it suddenly doesn't fail, and then I have to go update a test because we added a period or added a comma. I think that's the path of more sadness for me. And my goal is always a path of least sadness. So I think that's why I lean into it [laughs], I'm guessing. Is that why you lean into it as well? Or what do you like about referencing the keys over the explicit text?

+ +

CHRIS: No, I think I share your inclination there, and the reason that you're in favor of it, and I think the consistency like if we're going to use i18n, then we should lean in because it's a non-trivial thing to do like porting to i18n projects, and they're tricky. Getting it right from the first step is also tricky. If you're going to do it, then let's lean in, and thus let's use that abstraction overall. But yeah, same ideas as you.

+ +

STEPH: Cool. I think that helps validate where I'm at in terms of how I rationalize about this where ultimately, I do like leaning into that abstraction. And as you'd mentioned, some of those porting projects, I haven't been on one specifically, but I've seen that they are a lot of work. And so, if we have that in our system, then we want to continue to use it.

+ +

It does reduce some of the readability. Like you said, maybe there's a VS Code plugin or some way that then we can help people be able to see if they want that full context in the test and not have to jump over to YAML. But yeah, otherwise, unless it's overriding default behavior or complex, then that's what I'm going to go with is with the keys.

+ +

But I really appreciate this person's very thoughtful question and approach to testing because, normally or typically, I fully agree with I want full context in the test. And this one was one of those outliers that came up for me, and I had to really think through all the feelings and the reasons that I have for those feelings. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases.

+ +

Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Emma Bostian
+Ladybug Podcast
+Gerrit
+Gregg Tobo the Magician
+Sean Wang - swyx - better twitter search
+Twemex
+GitHub Pull Request File Tree Beta
+Sam Zimmerman - CEO of Sagewell Financial on Giant Robots
+TypeScript 4.1 feature
+The Bike Shed: 269: Things are Knowable (Gary Bernhardt)
+TSConfig Reference - Docs on every TSConfig option
+Rails I18n

+ +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. There are a couple of new things in my world, so one of them that I wanted to talk about is the fact that being pregnant is hard. I feel like this is probably a known thing, but I feel like I don't hear it talked about as much as I'd really like, especially in sort of like a professional context. And so I just wanted to share for anyone else that may be listening, if you're also pregnant, this is hard.

+ +

And I also really appreciate my team. Going through the first trimester is typically where you experience a lot of morning sickness and fatigue, and I had all of that. And so I was at the point that most of my days, I didn't even start till about noon and even some days, starting at noon was a struggle. And thankfully, the thoughtbot client that I'm working with most of the teams are on West Coast hours, so that worked out pretty well.

+ +

But I even shared a post internally and was like, "Hey, I'm not doing great in the mornings. And so I really can't facilitate any morning meetings. I can't be part of some of the hiring intros that we do," because we like to have a team lead provide a welcoming and then closing for anyone that's coming for interview day. I couldn't do those, and those normally happen around 9:00 a.m. for Eastern Time. And everybody was super supportive of it. So I really appreciate all of thoughtbot and my managers and team being so great about this. Also, the client team they're wonderful.

+ +

It turns out growing a little human; I'm learning how hard it is and working full time. It's an interesting challenge. Oh, and as part of that appreciation because…so there's just not a lot of women that I've worked with. This may be one of those symptoms of being in tech where one, I haven't worked with tons of women, and then two, working with a woman who is also pregnant and going through that as well. So it's been a little bit isolating in that experience.

+ +

But there is someone that I follow on Twitter, @EmmaBostian. She's also one of the co-hosts for the Ladybug Podcast. And she has been just sharing some of her, like, I am two months sleep deprived. She's had her baby now, and she is sharing some of that journey. And I really appreciate people who just share that journey and what they're going through because then it helps normalize it for me in terms of what I'm feeling. I hope this helps normalize it for anybody else that might be listening too.

+ +

CHRIS: I certainly can't speak to the specifics of being pregnant. But I do think it's wonderful for you to use this space that we have here to try and forward that along and say what your experience is like and share that with folks and hopefully make it a little bit better for everyone else out there. Also, you snuck in a sneaky pro-tip there, which is work on the East Coast and have a West Coast team. That just sounds like the obvious correct way to go about this.

+ +

STEPH: That has worked out really well and been very helpful for me. I'm already not a great morning person; I've tried. I've really strived at times to be a morning person because I just have this idea in my head morning people get more stuff done. I don't think that's true, but I just have that idea. And I'm not the world's best morning person, so it has worked out for many reasons but yeah, especially in helping me get through that first trimester and also just supporting family and other things that are going on.

+ +

Oh, I also learned a pro-tip about Twitter. This is going to seem totally random, but it was relevant when I was searching for stuff on Twitter [laughs] that was related to tech and pregnancy. But I learned...because I wanted to be able to search for something that someone that I follow what they said but I couldn't remember who said it.

+ +

And so I found that in the search bar, I can add filter:follows. So you can have your search term like if you're looking for cake or pregnancy, or sleep-deprived and then look for filter:follows, and then that will filter the search results to everybody that you follow. I imagine that that probably works for followers too, but I haven't tried it.

+ +

CHRIS: I like the left turn you took us on there but still keeping it connected. On the topic of Twitter search, they apparently have a very powerful search, but it's also hidden, and you got to know the specific syntax and whatnot. But there is a wonderful project by Shawn Wang, AKA Swyx, on the internet, bettertwitter.netlify.com is the URL for it. I will share a link to his tweet introducing it. But it's a really wonderful tool that just provides a UI for all of these different filters and configurations. And both make discoverability that much better and then also make it easy to just compose one of these searches and use that.

+ +

The other thing that I'll recommend is, I think it's a Chrome plugin. I'm guessing is what I'm working with here like a browser extension, but it's called Twemex, T-W-E-M-EX. And there's a sidebar in Twitter now, which just seems wonderful and useful. So as I'm looking at a Swyx post here, or a tweet as they're called on Twitter because I know that vernacular, there's a sidebar which is specific to Shawn Wang.

+ +

And there's a search at the top so I can search within it. But it's just finding their most popular tweets and putting that on a sidebar. It's a very useful contextual addition to Twitter that I found just awesome. So that combination of things has made my Twitter experience much better. So yeah, we'll have show notes for both of those as well.

+ +

STEPH: Nice. I did not know about those. This may cause someone to laugh at me because maybe it's easier than I think. But I can never remember that advanced search that Twitter does offer; I have to search it every time. I just go to Google, and I'm like, advanced Twitter search, and then it brings up a site for me, and then I use that as the one that Twitter does provide. But yeah, from the normal UI, I don't know how to get there. Maybe I haven't tried hard enough. Maybe it's hidden.

+ +

CHRIS: It's like they're hiding it.

+ +

STEPH: Yeah, one of those. [laughs]

+ +

CHRIS: It's very costly. They have to like MapReduce the entire internet in order to make that search work. So they're like, well, what if we hide it because it's like 50 cents per query? And so maybe we shouldn't promote this too much.

+ +

STEPH: [laughs]

+ +

CHRIS: And let's just live in the moment, everybody. Let's just swim in the Twitter stream rather than look back at the history. I make guesses about the universe now.

+ +

STEPH: [laughs] On a different note, I also discovered at thoughtbot in our variety of Slack channels that we have a yelling channel, and I had not used it before. I had not hung out there before. It's a delightful channel. It's a place that you just go, and you type in all caps. You can yell about anything that you would like to. And I specifically needed to yell about Gerrit, which is the replacement or the alternative that we're using for GitHub or GitLab, or Bitbucket, or any of those services.

+ +

So we're using Gerrit, and I've been working to feel comfortable with the UI and then be able to review CRs and things like that. My vernacular is also changing because my team refers to them as change requests instead of pull requests. So I'm floating back and forth between CRs and PRs. And because I'm in Gerrit world, I missed some of the updates that GitHub made to their pull request review screen. And so then I happened to hop in GitHub one day, and I saw it, and I was like, what is this? So that was novel.

+ +

But going back to yelling, I needed to yell about Gerrit because I have not found a way to collaborate with someone who has already pushed up changes. I have found ways that I can pull their changes which then took a little while. I found it in a sneaky little tab called download. I didn't expect it to be there. But then the actual snippet it's like, run this in your terminal, and this is then how you pull down the changes. And I'm like, okay, so I did that.

+ +

But I can't push to their existing changes because then I get like, well, you're not the owner, so we're going block you, which is like, cool, cool, cool. Okay, I kind of get that because you don't want me messing up somebody else's content or something that they've done. But I really, really, really want to collaborate with this person, and we're trying to do something together, and you're blocking me. And so I had to go to the yelling channel, and I felt better. And I'm yelling again. [laughs] Maybe I don't feel that great because I'm getting angry again talking about it.

+ +

CHRIS: You vented a little into the yelling channel; maybe not everything, though.

+ +

STEPH: Yeah, I still have more to vent because it's made life hard. Every time I wanted to push up a change or pull down someone else's changes, there are now all these CRs that then I just have to go and abandon, which is then the terminology for then essentially closing it and ignoring it, so I'm constantly going through.

+ +

And if I do want to pull in changes or collaborate, then there's a flow of either where I abandon mine, or I pull in their changes, but then I have to squash everything because if you push up multiple commits to Gerrit, it's going to split those commits into different CRs, don't like that. So there are a couple of things that have been pain points. And yeah, so plus-one for yelling channels, let people get it out.

+ +

CHRIS: Okay, so definitely some feelings that you are working through here. I'm happy to work together as a team to get through some of them. One thing that I want to touch on is you very quickly hinted at GitHub has got a bunch of new things that are cool. I want to talk about those. But I want to touch [laughs] on an anecdote. You talked about pushing something up to someone else's branch. You're like, oh, you know, I made some changes locally, and I'm going to push them up.

+ +

I had an interesting experience once where I was interacting with another developer. I had done some code review. They weren't quite understanding where I was. They had a lot of questions. And finally, I said, you know what? This will just be easier. Here, I pushed up a commit to your branch, so now you can see what I'm talking about. And I thought of this as a very innocuous act, but it was not interpreted that way. That individual interpreted it in a very aggressive sort of; it was not taken well.

+ +

And I think part of that was related to I think of Git commits as just these little ephemeral things where you're like, throw it out, feel free. This is just the easiest way for me to communicate this change in the context of the work that you're doing. I thought I was doing a nice favor thing here. That was not how it went. We had a good conversation after I got to the heart of where we both were emotionally on this thing. It was interesting. The interaction of emotion and tech is always interesting.

+ +

But as a result, I'm very, very careful with that now. I do think it's a great way as long as I've gotten buy-in from the person beforehand. But I will always spot check and be like, "Hey, just to confirm, I can just push up a commit to your branch, but are you okay with that? Is that fine with you?" So I've become very cautious with that.

+ +

STEPH: Yeah, that feels like one of those painful moments where it highlights that the people that you work with that you are accustomed to having a certain level of trust or default trust with those individuals, and then working with someone else that they don't have that where the cup is half-full in terms of that trust, or that this person means well kind of feelings towards a colleague or towards someone that they're working with.

+ +

So it totally makes sense that it's always good to check and just to be like, "Hey, I'd love to push up some changes to your branch. Is that cool?" And then once you've established that, then that just makes it easier. But I do remember that happening, and yeah, that was a bit painful and shocking because we didn't see that coming and then learned from it.

+ +

CHRIS: I do think it's an important thing to learn, though, because for me, in that moment, this was this throwaway operation that I thought almost nothing of, but then another individual interpreted it in a very different way. And that can happen, that can happen across tons of different things. And I don't even want to live in the idealized world where it's just tech; we're just pushing around zeros and ones; there's no human to this. But no, I actually believe it's a deeply human thing that we're doing here.

+ +

It's our job to teach the computers to be a little closer to us humans or something like that. And so it was a really pointed clarification of that for me where it was this thing that I didn't even think once about, no less twice, and yet someone else interpreted it in such a different way. So it was a useful learning situation for me.

+ +

STEPH: Yeah, I totally agree. I think that's a really wise default to have to check in with people before assuming that they'll be comfortable with something that we're comfortable with.

+ +

CHRIS: Indeed. But shifting back to what you mentioned of GitHub, a bunch of new stuff came in GitHub, and you were super excited about it. And then you went on to say other things about another system. [laughs] But let's talk about the great things in GitHub. What are the particular ones that have caught your eye? I've seen some, but I'm intrigued. Let's compare notes.

+ +

STEPH: So this is one of those where I hadn't seen GitHub in quite a while, and then I hopped in, and I was like, this is different. But some of the things that did stand out to me right away is that on the left-hand side, I can see all of the files that have been changed, and so that's a really nice tree where I just then immediately know.

+ +

Because that was one of the things that I often did going to a PR is that I would see what files are involved in this change because it was just a nice overview of what part of the applications am I walking through? Are there tests for this? Have they altered or added tests? And so I really like that about it. I'm sure there's other stuff. But that is the main thing that stood out to me. How about you?

+ +

CHRIS: Yeah, that sidebar file tree is very, very nice, which I find surprising because I don't use a file tree in my editor. I only do fuzzy finding to jump to files. But I think there's something about whenever GitHub had the file list; these are all the files that are changed. I'm like, this is just noise. I can't look at this and get anything out of it. But the file tree is so much more...there's a shape to it that my brain can sort of pattern match on. And it's just a much more discoverable way to observe that information. So I've really loved that. That was a wonderful one.

+ +

The other one that I was surprised by is GitHub semantic code analysis; stuff has gotten much, much better over time subtly. I didn't even notice this happening. But I was discussing something with someone today, and we were looking at it on GitHub, and I just happened to click on an identifier, and it popped up a little thing that says, "Oh, do you want to hop to the references or the definition of this?" I was like, that is what I want to do. And so I hopped to the definition, hopped to the definition of another thing, and was just jumping around in the code in a way that I didn't know was available. So that was really neat.

+ +

But then also, I was in a pull request at one point, and someone was writing a spec, and they had introduced a helper just like stub something at the bottom of a given spec file. And it's like, I feel like we have this one already. And I just clicked on the identifier. I think it might have actually been a matcher in RSpec, so it was like, have alert. And I was like, oh, I feel like we have this one, a matcher specific to flash message alerts on the page. And I clicked on it, and GitHub provided me a nice little inline dialog that showed me all of the definitions of have alert, which I think we were up to like four of them at that point.

+ +

So it had been copied and pasted across a couple of different files, which I think is totally fine and a great way to start, but they were very similar implementations. I was like, oh, looks like we actually already have this in a couple of places, maybe we clean it up and extract it to a common spec support thing, and ta-da, I was able to do all of that from the GitHub pull requests UI. And I was like, this is awesome. So kudos to the GitHub team for doing some nifty stuff. Also, can I get into the merge queue? Thank you.

+ +

...
+STEPH: [laughs] There it is. That is very cool. I didn't know I could do that from the pull request screen. I've seen it where if I'm browsing code that, then I can see a snippet of where everything's defined and then go there, but I hadn't seen that from the pull request. I did find the changelogs for GitHub that talk about the introduction of having the tree, so we'll be sure to include a link in the show notes for that too. But yes, thank you for letting me use our podcast as a yelling channel. It's been delightful. [laughs]

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: Well, speaking of podcasts, actually, there was an interesting thing that happened where the CEO of Sagewell Financial, the company of which I am the CTO of, Sam Zimmerman is his name, and he went on the Giant Robots Podcast with Chad a couple of weeks ago. So that is now available. We'll link to that in the show notes. I'll be honest; it was a very interesting experience for me. I listened to portions of it. If we're being honest, I searched for my name in the transcript, and it showed up, and I was like, okay, that's cool. And it was interesting to hear two different individuals that I've worked with either in the past or currently talking about it.

+ +

But then also, for anyone that's been interested in what I'm building over at Sagewell Financial and wants to hear it from someone who can probably do a much better job of pitching and describing the problem space that we're working in, and all of the fun challenges that we have, and that we're hopefully living up to and building something very interesting, I think Sam does a really fantastic job of that. That's the reason I'm at the company, frankly.

+ +

So yeah, if anyone wants to hear a little bit more about that, that is a very interesting episode. It was a little weird for me to listen to personally, but I think everybody else will probably have a normal experience listening to it because they're not the CTO of the company. So that's one thing.

+ +

But moving on, I feel like today's going to be a grab bag episode or tapas episode, lots of small plates, as we were discussing as we were prepping for this episode. But to share one little thing that happened, I've been a little more removed from the code of late, something that we've talked about on and off in previous episodes. Thankfully, I have a wonderful team that's doing an absolutely fantastic job moving very rapidly through features and bug fixes and all those sorts of things.

+ +

But also, I'm just not as involved even in code review at this point. And so I saw one that snuck through today that, I'm going to be honest, I had an emotional reaction to. I've talked myself down; we're fine now. But the team collectively made the decision to move from a line length of 80 characters to a line length of 120 characters, and I had some feelings.

+ +

STEPH: Did you fire everybody? [laughs]

+ +

CHRIS: No. I immediately said, doesn't really matter. This is the whole conversation around auto-formatting tools is like we're just taking the decision away. I personally am a fan of the smaller line length because I like to have multiple files open left to right. That is my reason for it, but that's my reason. A collective of the developers that are frankly working more in the code than I am at this point decided this was meaningful. It was a thing that we could automate. I think that we can, you know, it's not a thing that we have to manage. So I was like, cool. There we go.

+ +

The one thing that I did follow up on I was like, okay; y'all snuck this one in, it's fine, I'm fine with it. I feel fine; everything's fine. But let's add that to the git-blame-ignore-revs file, which is a useful thing to know about. Because otherwise, we have a handful of different changes like this where we upgrade Prettier, and suddenly, the manner in which it formats the files changes, so we have to reformat everything at once. And this magical file that exists in Git to say, "Hey, ignore this revision because it is not relevant to the semantic history of the app," and so it also takes that decision out of the consideration like yeah, should we reformat or not? Because then it'll be noisy. That magical file takes that decision away, and so I love that.

+ +

STEPH: I so love the idea because you took vacation recently twice. So I love the idea of there was a little coup and people are applauding, and they're like, while Chris is on vacation, we're going to merge this change [laughs] that changes the character line. And yeah, that brings me joy. Well, I'm glad you're working through it. Sounds like we're both working through some hard emotional stuff. [laughs]

+ +

CHRIS: Life's tricky, is all I'm going to say.

+ +

STEPH: I am curious, what prompted the 80 characters versus 120? This is one of those areas that's like, yeah, I have my default preference like you said. But I'm more intrigued just when people are interested in changing it and what goes with it. So do you remember one of the reasons that 120 just suited their preferences better?

+ +

CHRIS: Frankly, again, I was not super involved in the discussion or what led them to it.

+ +

STEPH: [laughs]

+ +

CHRIS: My guess is 120 is used...I think 80 is a pretty common one. I think 120 is another of the common ones. So I think it's just a thing that exists out there in the mindshare. But also, my guess is they made the switch to 120 and then reformatted a few files that had like, ah, this is like 85 characters, and that's annoying. What does it look like if we bump it up?

+ +

And so 120 provided a meaningful change of like, this is a thing that splits to four lines if we have an 80 character thing, or it's one line if it's 120 characters, which is a surprising thing to say, but that's actually the way it plays out in certain cases because the way Prettier will break lines isn't just put stuff on the next line always. It's got to break across multiple lines, actually. All right, now that we're back in the opinion space, I have a strong one.

+ +

STEPH: This is The Bikeshed. We can live up to that name. [laughs]

+ +

CHRIS: So I do want an additional configuration in Prettier Ruby. This is the thing I'll say. Maybe I can chase down Kevin Newton and see if he's open to this. But when Prettier does break method call with arguments going into it but no parens on that method call, and it breaks out to multiple lines, it does the dangling indent thing, which I do not like. I find it distasteful; I find it noisy, the shape of the code. I'm a big fan of the squint test. I know that from Sandi Metz, I believe, or maybe it's Avdi Grimm. I associate it with both of them in my mind.

+ +

But it's just a way to look at the code and kind of squint, and you see the shape of it, and it tells you something. And when the lines break in that weird way, and you have these arbitrary dangling indents, the shape of the code is broken up. And I don't feel so strongly. I actually regularly stop myself from commenting on pull requests on this because it's very easy. All you need to do is add explicit parens, and then Prettier will wrap the line in what I believe is a much more aesthetically pleasing, concise, consistent, lots of other good adjectives here that are definitely just my preferences and not facts about the world.

+ +

But so what I want is, Prettier, hey, if you're going to break this line across multiple lines, insert the parens. Parens are no longer optional for breaking across multiple lines; parens are only optional within a given line. So if we're not breaking across lines, I want that configuration because this is now one of those things where I could comment on this. And if they added the optional parens, then Prettier would reform it in a different way. And I want my auto formatter don't give me ways to do stuff. Like, constrain me more but also within the constraints of the preferences that I have, please, thank you.

+ +

STEPH: I love all the varying levels there [laughter] of you want a thing, but you know it's also very personal to you and how you're walking that line and hopping back and forth on each side. I also love the idea. We have the idea of clean code. I really want something that's called distasteful code now [laughs] where you just give examples of distasteful code, yes. Well, I wish you good luck in your journey [laughs] and how this goes and how you continue to battle.

+ +

I also appreciate that you mentioned when you're reviewing code how you know it's something that you really want, but you will refrain from commenting on that. I just appreciate when people have that filter to recognize, like, is this valuable? Is it important? Or, like you said, how can we just make this more of the default so then we don't even have to talk about it? And then lean into whatever the default the team goes with.

+ +

CHRIS: Well, thank you. I very much appreciate that because, frankly, it's been very difficult.

+ +

STEPH: I do have something I want to yell about but in a very positive way or pranting as we determined or, you know, raving, the actual real term that wonderful listeners pointed out to us.

+ +

CHRIS: Prant for life. That's my stance.

+ +

STEPH: We had a magic show at thoughtbot. It was all remote, but the wonderful Gregg Tobo, the magician, performed a magic show for us where we all showed up on Zoom. And it was interactive, and it was delightful, and it was so much fun. And so if you need something fun for your team that you just want to bring folks together, highly recommend. I had no idea I was going to enjoy a magic show this much, but it was a lot of fun. So I'll be sure to include some links in the show notes in case that interests anyone. But yeah, magic. I'm doing jazz hands. People can't see it, but magic.

+ +

I like how you referred earlier, saying that today is more of like a tapas episode. And I'm realizing that all of my tapas are related to being pregnant, yelling, and magic shows, and I'm okay with that. [laughs] But on that note, what else is on your tapas plate?

+ +

CHRIS: Actually, a nice positive one that came into the world...I always like when we get those. So this is interesting because I was actually looking back at the history, and I had Gary Bernhardt on The Bike Shed back in Episode 269. We'll include a link in the show notes. But we talked a bunch about various things, including TypeScript. And I was lamenting what I saw as a pretty big edge case in TypeScript.

+ +

So the goal of TypeScript is like, all right, JavaScript exists, this is true. What can we do on top of that? Let's not fundamentally change it, but let's build a type system on top of it and try and make it so that we can enforce correctness but understand that JavaScript is a highly dynamic language and that we don't want to overconstrain and that we've got to meet it where it is.

+ +

And so one of the design decisions early on with TypeScript is if you have an array and you say like it's an array of integers, so you have typed that array to be this is an array of int, or it will be an array of number in JavaScript because JavaScript doesn't have integers; they only have numbers. Cool. [laughs] Setting aside other JavaScript variables here, you have an array of numbers. And so if you use element access to say, like, say the name of array is array of nums and then use brackets and you say zero, so get me the first element of that array.

+ +

TypeScript will infer the type of that to be a number. Of course, it's a number, right? You got an array of numbers, you take a number out of it, of course, you're going to have a number, except you know what's also an array of numbers? An empty array. Well, of course. So there's no way for TypeScript because that's a runtime thing, whether or not the array is full of things or not. Or imagine you get the third element from the array. Well, JavaScript will either return you the third element, which indeed is a number, or undefined because there's no third element in this array.

+ +

So that is an unfortunate but very understandable edge case that TypeScript was like, listen, this is how JavaScript works. So we're not going to…frankly, we don't think the people embracing TypeScript and bringing it into their world would accept this amount of noise because this is everywhere. Anytime you interact with an array, you are going to run into this, this sort of uncertainty of did I actually get the thing? And it's like, yeah, no, I know how many things are in the array that I'm working with. Spoiler, you maybe don't is the answer.

+ +

And so, we ran into this edge case in our codebase. We were accessing an element, but TypeScript was telling us, "Yes, definitively, you have an object of that type because you just got it out of an array, which is an array of that type." But we did not; we had undefined. And so we had, you know blah is not a method on undefined or whatever that classic JavaScript runtime error is. And I was like, well, that's very sad.

+ +

But now we get to the fun part of the story, TypeScript, as of version 4.1, which came out like the week that I recorded with Gary Bernhardt, which was interesting to look at the timeline here. TypeScript has added a new configuration. So a new strictness dial that you can configure in your tsconfig called noUncheckedIndexedAccess. So if you have an array and you are getting an element out of it by index, TypeScript will say, "Hey, you got to check if that's undefined," because to be clear, very much could be undefined. And I was so happy to find this.

+ +

We turned it on in our codebase. It found the error in the place that we actually had an error and then found a few others that I think probably had errored at some times. But it was just one of those for me very nice things to be able to dial up the strictness and enforce correctness within our codebase, and so I was very happy about it. Other folks may say that seems like too much work. And, you know, I get that, I get that take. I'm definitely on the side of I'm willing to go through the effort to have enforced correctness, but you know, that's a choice.

+ +

STEPH: Yeah, that's thoughtful. I like that, how you said you can dial up the strictness so then as you are introducing TypeScript, then people have that option. There is an argument there in the back of my head that's like, well, if you're introducing types, then you want to start more strict because then you're just creating problems for yourself down the road. But I also understand that that can make things very difficult to then introduce it to teams in existing codebases. So that seems like a really nice addition where then people can say, "Yeah, no, I really want the strictness. This is why I'm here," and then they can turn that on.

+ +

CHRIS: So TypeScript in the configuration has strict mode, so you say strict true. And that is a moving target with each new version of TypeScript. But it's their sort of [inaudible 28:14] set of things that are part of strict, but apparently, this one's not in it. So now I'm like, wait, can I have a stricter? Can I have a strictest option? Can I have dial it to 11, please? [laughs] Really rough me up and make sure my code is correct.

+ +

But it is the sort of thing like when we turn any of these on; it will find things in our codebase. Some of them, we have to appease the compiler even though we know the code to be correct. But the code is not provably correct as it sits in our file. So I am, again, happy to make that exchange. And I like that TypeScript as a project gives us configurability. But again, I am on team where's the strictest button? I would like to push that as hard as I can and live that life.

+ +

STEPH: Yeah, I like that phrasing that you just said about provably correct. That's nice.

+ +

CHRIS: That's the world I want to live in, everything you own in the box to the left, which is probably correct.

+ +

STEPH: [laughs] That's how that song goes.

+ +

CHRIS: Yeah. This is a reference to move errors to the left, which I think I've referenced before. But now that I'm just referencing Beyoncé and not the actual article, it's probably worth referencing the article, but the idea of, like, if a user hits an error, that's not great. So let's move it back to QA, that's a little further to the left in sort of the timeline.

+ +

But what if we could move it to an automated test in CI? But what if we could move it into your editor? What if we could move it even further to the left? And so, a type system tends to be sort of very far ratcheted up to the left. It's as early as possible that you can catch these. So again, to reference Beyoncé, everything you own in a box to the left.

+ +

STEPH: [singing] Everything you own in the box to the left.

+ +

CHRIS: Thank you for doing the needful work there.

+ +

STEPH: [laughs]

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free that's studio3t.com/free.

+ +

STEPH: I have a question for you that I'd really love to get your opinion on because I myself I’m waffling back and forth where someone brought up some really great points about a concern or just a question they had brought up around testing and i18n specifically. And I agree with the things that they're saying, but yet, there's also a part of me that doesn't, and so I'm Stephanie divided. And so, I'm trying to figure out where I stand on this.

+ +

So let me dive in and give you some context; I'm going to share the statement/question that they had asked. So here we go. "One of my priorities has been I should be able to review a test without having to reference any other code. References to i18n means that I have to go over to YAML and make sure the right keys have the right values, and that seems error-prone.

+ +

In some cases, a lack of a hit in the YAML defers to defaults. If the intent is to override the name of model attribute and error messages and it is coded incorrectly, the code fails silently without translating and uses the humanized attribute name, and that would go undetected. If libraries change structure, it might also fail silently as well, so to me, the only failsafe way is to be fully explicit in test."

+ +

So this goes with the idea that if you're writing tests and then you're testing text, but it’s on the screen or perhaps an email, that you're actually going to assert against that string that is shown to the user instead of referencing the i18n keys. And then that also backs up this person's idea that you really want to not have to jump around. If you're reading a test, everything you really need to know about that test should live very close by.

+ +

And I really agree with that initial statement; I want everything that's very close to the test, especially if it's anywhere in that expectation line, I really want it close, so I can understand what's the expectation, what's under test, what are the inputs, what's the expected outcome. So I wholeheartedly support that idea.

+ +

But yet, I am in the camp that I then will use YAML keys instead of providing that exact string because I do look at i18n as a helpful abstraction, and I want to trust that i18n is doing its job. And so that way, I don't have to provide that string that's there because then we're also choosing, okay, well, which language are we going to always use for our test?

+ +

So this is the part where I feel divided. So I'm going to walk you through some of the reasons that I really support this idea and other reasons that I still use the i18n keys and then get your take on it. So there is a part of me that when I'm using the i18n YAML keys, it does make me sad because it reduces the readability in tests. Sometimes the keys are really well named where maybe it's a mailer.welcomemessage. And I'm like, okay, I understand the gist. I don't need to go see the actual string.

+ +

I also think they highlighted a really good use case where if you're overriding behavior and it could default to something else, your test is still going to pass, and you don't actually know. So I could see the use case there where if you are overriding, then you want to be explicit about the string that you expect back. I also think there are some i18n messages that are fairly complex, and where then I really would like to see the string.

+ +

So if you are formatting a date or a time or you're passing in just a lot of variables, then there's a chance that I do want to see how did that actually get generated for the person who's going to be reading it versus just maybe it's garbage text that came out? And I want to validate that the message that we think we're crafting is actually the one that the user is going to see.

+ +

The case against actually being explicit, my biggest one is because then I do see i18n as a helpful abstraction. And I want to trust this abstraction that it's doing its job and it's doing it well. Because then if I do use explicit strings, it makes me sad if I change text from like hello to welcome, and now I have a failing test. I don't like that idea either.

+ +

So I'm torn between these two worlds of it is very nice to have everything that you need in a test to be able to understand what is the expectation, but then I also lean into this abstraction and reference the i18n keys. So, Chris, with all of that, that was a bit of a whirlwind, [laughs] what are your thoughts? How do you test this stuff?

+ +

CHRIS: Honestly, I'm surprised that you've got that much division in your own answer because for me, this is very obvious there's one...no, I'm kidding. This is obviously complicated. Similar to you, I think I'm going to have to give a grab bag of answers because I don't have a singular thought of like it is concretely this or that.

+ +

I tend to go for explicit strings and tests all the way to...so like the readability of a test, and the conciseness of a test is interesting. I will often see developers extract. Say they're creating a user with a specific email, and then they log in with that email later, and then they expect something else. And so the email is referenced a few times, and they'll extract that into a variable called email. And I personally will tend to not do that. I will inline the literal string like user@example.com, and I'll do it in a few places. And I'm fine with that duplication because I like the readability of any given line that you're reading. So I will make that trade-off within tests.

+ +

This is the thing I think we've talked about before, but the idea of DRY in tests is like I want to be careful applying that idea, Don't Repeat Yourself, to break apart the acronym. Those abstractions I will use them less than tests. And so I want the explicitness, I want the readability, I want to tell a little story, all of that feels true.

+ +

That said, to flip it around, one of the things that I'm hearing...so I think I'm hearing a part of this that is around well, we can fail silently because we fail symmetrically in both the implementation and our test. Then an assertion may actually match even though it's matching on a fallback. I think that's a configurable thing. I would actually want my test to raise if I'm referencing an i18n key that is not defined.

+ +

Now, granted, that's different for languages. And maybe this becomes a more complex story of like in production; in a different locale, it will fail because we don't have 100% parity across all our locale files. But fundamentally, I want to make sure that at least exists in our base, which I think typically would be en-US as the locale. I want to make sure all keys are looked up and found, and it's an error otherwise in our test. So that's a feeling. But am I misunderstanding that part of the story or how that configuration typically works?

+ +

STEPH: No, I think you've got it. But just to make sure we're on the same page, so if you reference a key that doesn't exist, then it is going to fail. So at least you have your test failure is going to let you know that you've referenced something that doesn't exist. But if you are referencing, like if you want to override the defaults that Rails or i18n has provided for a model and say for an error message, if you reference that, but you want to override it, but then you've forgotten, that does exist.

+ +

So you're not going to get the failure; you're going to get a different message. So it's probably not a terrible experience for the user. It's not going to crash. They're going to see something, but they're not going to see the custom message that you intended them to see.

+ +

CHRIS: Gotcha. Okay, well, just to name it, the thing that I was describing, I don't know that that would be the configuration for every system. So I would strongly encourage any system where i18n just has a singular behavior which is we fall back to the key. I want my test to absolutely tell me if that's happening. And that should be a failure of the test. But to the discoverability documentation bit, I do wonder if tooling can actually help answer the question.

+ +

And as I was describing the wonderful experience I had on GitHub the other day, viewing code as just static characters in a file is both true and also, I think increasingly, a limited view of it. We have editors, and we have code hosting tools that can understand semantically our code a little bit better. There's got to be like 20 Different VS Code plugins that, when you hover on an i18n reference, it will do the lookup for you. That feels like a thing that exists, and if it doesn't, well, now I’ve nerd-sniped myself, and I got a weekend project. JK, I'm definitely not building that this weekend.

+ +

But that feels like can we use that to solve this? Maybe not. But that's just another thought of where we have these limitations where it's static, like those abstractions can be useful. But if we can very quickly dereference them, then the cost of the abstraction or that separation becomes smaller, and so the pain is reduced. And I wonder if that's a way to sort of offset it.

+ +

STEPH: If I can poke at that a little bit more, because I think you're touching on something that I haven't expressed or thought through explicitly, but it's the idea of, like, why do I like the abstraction? What is it that's drawing me towards using these keys? And I think it's because most of the cases, I don't care. I don't care what the string is, and so that feels nice. Like, I understand that, yes, we're referencing something. If that key didn't exist, I'm going to see a failure.

+ +

So I know that there's text there, and that's why I do lean into referencing the keys instead of the text because it feels good to not have to care about that stuff. And if we do make changes to the text, then it suddenly doesn't fail, and then I have to go update a test because we added a period or added a comma. I think that's the path of more sadness for me. And my goal is always a path of least sadness. So I think that's why I lean into it [laughs], I'm guessing. Is that why you lean into it as well? Or what do you like about referencing the keys over the explicit text?

+ +

CHRIS: No, I think I share your inclination there, and the reason that you're in favor of it, and I think the consistency like if we're going to use i18n, then we should lean in because it's a non-trivial thing to do like porting to i18n projects, and they're tricky. Getting it right from the first step is also tricky. If you're going to do it, then let's lean in, and thus let's use that abstraction overall. But yeah, same ideas as you.

+ +

STEPH: Cool. I think that helps validate where I'm at in terms of how I rationalize about this where ultimately, I do like leaning into that abstraction. And as you'd mentioned, some of those porting projects, I haven't been on one specifically, but I've seen that they are a lot of work. And so, if we have that in our system, then we want to continue to use it.

+ +

It does reduce some of the readability. Like you said, maybe there's a VS Code plugin or some way that then we can help people be able to see if they want that full context in the test and not have to jump over to YAML. But yeah, otherwise, unless it's overriding default behavior or complex, then that's what I'm going to go with is with the keys.

+ +

But I really appreciate this person's very thoughtful question and approach to testing because, normally or typically, I fully agree with I want full context in the test. And this one was one of those outliers that came up for me, and I had to really think through all the feelings and the reasons that I have for those feelings. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeee!!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+_dupaYWF + + ]]> + + Chris Toomey + Steph Viccari + + + 332: Ludicrous Speed + https://bikeshed.thoughtbot.com/332 + f3ecbaae-ac36-4a5b-910a-526d647135a0 + Tue, 05 Apr 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris is back from vacation and gives hiring and onboarding updates. + +Steph has an update about the CI slowdown and scaling CI. + +They tackle a listener question regarding having some fear around potential merge conflicts. + 39:28 + no + + + Chris is back from vacation and gives hiring and onboarding updates. +Steph has an update about the CI slowdown and scaling CI. +They tackle a listener question regarding having some fear around potential merge conflicts. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Deckset (https://www.deckset.com/) +parallel_tests (https://github.com/grosser/parallel_tests) +paralleltests - important line that may alter the `groupby` strategy (https://github.com/grosser/parallel_tests/blob/9bc92338e2668ca4c2df81ba79a38759fcee2300/lib/parallel_tests/cli.rb#L305) +KnapsackPro (https://knapsackpro.com/) +rspec-queue (https://github.com/conversation/rspec-queue) +Vim Conflicted Overview (https://github.com/christoomey/vim-conflicted#overview) +Mastering Git Course on Upcase (https://thoughtbot.com/upcase/mastering-git) +Git Object Model (https://thoughtbot.com/upcase/videos/git-object-model) +Git Object Model Operations (https://thoughtbot.com/upcase/videos/git-object-model-operations) +The Opportunity Will Find You (https://thoughtbot.com/blog/the-opportunity-will-find-you) +This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Golden roads are golden. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Oh, I also have a new intro that I want to try out. This is thanks to Irmela from Twitter, where it's good morning and hooray; today is Bike Shed day. They technically said Tuesday, but we don't record on Tuesdays. So today is Bike Shed day, so happy Bike Shed day. And hey, Chris, what's new in your world? +CHRIS: What is new in my world? Yeah, I loved when I saw that tweet come out. It really warmed my heart. So Tuesday, in theory, is Bike Shed day, but for you and I, Friday is Bike Shed day. It's confusing breaking the fourth wall, as I so often do. But yeah, what's new in my world? I'm back from vacation, which is the thing that I did. For listeners, well, I have been absent the previous week related to vacation and all those sorts of things. +But I did what we're going to describe as a not smart thing. It wasn't intentional. The world just kind of conspired in this way. But I had two separate vacation islands that existed in my mind, and then they both kind of congealed, but as they did that, they moved towards each other, but they didn't connect. +And so what I ended up with was two weeks back to back where I was out on Thursday and Friday of one week, and then I was back for Monday and Tuesday. And then I was out for Wednesday, Thursday, Friday of the following week. Protip: that's a terrible idea. It's just not enough time to sort of catch up. +The whole of it was like the ramp-up to vacation and then the noise of vacation, then getting back and being like, oh, there are so many emails. Let me try and catch up on them. But also, on the very positive side, we had a new hire join the team, and so most of my focus on the days that I was in the office was around getting that new person comfortable on the team, onboarding, spending as much time as possible with them. +And so, all total, it was an adventure. And again, I would strongly recommend against this. The world just kind of conspired, and suddenly these three different forces in my life came together. And this was just the shape of things. But yeah, I went on vacation, and it was great. The vacation part was great. +STEPH: I will take your advice. So next time I have like two segments of PTO, I'm just going to stitch them together and just go ahead and take that whole intermittent time off. +CHRIS: That probably would have been better. Again, someone new joining the team, it was very important to me to get some time with them early on, and so I opted not to do that. But yeah, the attempt to catch up in between was a completely lost effort, I would say. But I think I'm mostly caught up now, having been back in the office for about a week, so yeah. +But let's see, what else has been up in my world? It's actually been a while since you and I have chatted based on the various timing and schedules and the nonsense vacation schedule that I had that you so kindly accommodated across a couple of weeks. Let's see, hiring and onboarding; the hiring went really well. We talked about that a bunch of weeks back. But now we're in the onboarding phase. And so next week will be the first week that all four of us on the engineering team are in the office together for the full week. I'm super excited to experience that. +We've had different portions of it, with me being on vacation and other folks being on vacation. But now, for the first time, we're really going to feel what it’s like as this team. And we're going to have our first retro as a group and all those sorts of things, so I'm very excited to do that. And thus far, all of the interactions that we've had have been really wonderful as a team. And so now it'll be the first time we're just bringing all of those various pieces together. +STEPH: I just have to clarify; you said all of y'all in the office together. Do you still mean remotely? +CHRIS: Oh, yes, yes, I just mean not on vacation, all present and accounted for on the internet. Remote is another interesting facet of what we're doing here and trying to figure out how to navigate that, particularly where there are some folks that are closer and can potentially get together in the city, that sort of thing, and then folks that are truly remote and making sure that we're...I'm very much of the opinion if we have anyone that's remote, we are remote team, and we must embrace async communication and really lean into that. +And I think the benefits of async communication as its own consideration are so worth it. And it's one of those things that's hard to do. It requires careful, intentional thought. It requires more purposeful communication. But I think there are a lot of good things that fall out of that. It's similar to TDD in that way in my mind, like, it's not easy. It's actually quite difficult. But all the effort that I put into trying to learn how to do that has made me a better developer, I think, on all the various fronts. +And I think similarly, async communication I believe in as a tool to force just better communication. And so I'm a big believer in it, and I've found a ton of benefit in remote that I'm also a big believer in that now. I, like everyone else, was forced into it as the world was, but I've really come to enjoy it a lot. And so yeah, so, no, not physically in the office, to answer your very short question with a long rambling aside. +STEPH: [laughs] I like that comparison. I hadn't thought about it in that way but comparing that thoughtfulness and helpfulness of async communication and then also to TDD, where it's not easy, but the payoff is so worth it, the upfront cost of it. That is something that at thoughtbot, we've had conversations around where there are folks that really value...they want to be around people. They get energy from people, and so they want that option to be able to rent a WeWork space and maybe get together with a colleague once or twice a week, and that was supported by thoughtbot. +But we also wanted to express well, if you are together, do treat everything still as a remote work environment. So let's say if you and your colleagues are on a project, but then there's a third person on that project that's remote, you still need to act like everything's remote to make sure that everyone else is still getting to participate and hear everything and be part of the conversation. So just keeping that in mind that yes, we want to support you doing your best work, and if that's around people, that's wonderful. But we are still remote-first, and communication needs to be in that fashion. +Well, that's super exciting that you'll have all of the team together. That sounds like it will be wonderful to hear about and then also retros and meetings, and yeah, it sounds like you've got a fun week ahead. +CHRIS: Indeed. I'm super excited to see what sort of new things come out of the new voices on the team and practices that each of the individuals have experienced at other companies that we can now fold together. The work that we've done so far has been very much inspired by thoughtbot ideas, and approaches, and workflows, and processes because that's what I brought to the table. But I'm super excited to bring in more voices and see what of that 100% stays on versus does anything change? Do we get entirely new things? So yeah, very excited about all of that. +But to revisit a topic that we've talked about in the past, this week is catching up from vacation, so there's a certain amount that will constrain my work. But this was definitely another week of I did not do much coding. I'm trying to think if I did any coding this week. It's possible that the answer is no. The fact that I don't even know the answer to that is an interesting one. I still have in my mind the desire to get back to it, and I think I will. But there's so much other stuff to do. +Recently, this week, there's been a lot of vendor selection and contract negotiation, which is an interesting facet of the work, but just trying to figure out, oh, we need platforms to do X, Y, and Z. And it turns out they're wildly costly and have long sales cycles. And how do you go through that, and how do you make sure that we're getting the right thing? And so that's been a big part of my work. Hiring and onboarding, again, has been a big part of it. +There's also some amount of communicating back to the broader team - what are we doing? What is the product organization or the engineering team delivering? And so I'm okay at presentations, I think. I'm comfortable with giving presentations. The thing that I struggle with is finding the optimization point in preparation. I will, of my own accord, over-prepare. And that may sound a little bit like, oh, what's my greatest weakness? That I care too much. +But I mean it sincerely as like, I would love to find that right amount of like, it's like an hour of preparation for a 15-minute presentation to the team. That's the right ratio. And I just hit that on the head, and it's great. But whenever I know that I need to give a larger presentation, it will distract me. And it's work that can expand to fill whatever time you give it, and so trying to thread that needle is a tricky one for me. +STEPH: Yeah, I'm with you. Presentations, for me, they're one of those things that it's very stressful, anxiety-inducing; all the prep feels distracting from some of the other work that I want to do. Or maybe I'm excited about the presentation, and that is the work that I want to do. But it's not until it's done that then I'm like, oh, that was fun. That went well. This was great. +It's not until after that then I feel good about it. So the lead-up to it is very stressful. And so if you can optimize that to say, well, I know exactly what this group needs, where I can cut corners, where I have to go into details, that sounds incredibly valuable. +I'm curious, so this is probably a bad idea, but it's the only way I really know how to find those boundaries is you got to experiment and tweak a little bit and let yourself fail a little bit or just be very explicit with folks about this is what the presentation is, if you expected something else, let me know. Or here's what I've got, have someone to bounce ideas off of. +But there's such a nicety if you can find that I'm going to try failing just a little bit and get some feedback. Or maybe it's not failing at all, but you are testing that boundary to find out did this work, or should I put more effort into this? I'm curious, do you have thoughts on that? How you're going to find that right optimization level? +CHRIS: Not as specific to truly honing in on whatever the correct number is. The thing that I've been doing is I...this will sound complicated, but I wait until the last minute but a specific version of the last minute. So at most, I start working on it an hour and a half before the meeting. And these are, again, not particularly large presentations, and it's a recurring sort of thing. So it's sort of engineering talking about the work that we've done recently and trying to find the right level of detail and whatnot, so giving myself a smaller time window. +I think that's enough time to tell the story and to find a meaningful way to tell the story and grab the screenshots and all of that, but it's constrained so that I don't over-optimize, over-edit, overthink. I'm using Deckset, which is a presentation tool that starts from a Markdown file. So it's just a Markdown file that I'm editing. That's great; that works really well. I do not twiddle with fonts. There's one theme that I use. It is white background with black text. That's it. +And I think I've given myself deep permission to be the CTO that has a white background with black text and no transitions. I don't even go into presentation mode for it. I'm literally showing the UI of Deckset, and then just hitting the arrow to move between them. But the Chrome and the drop-down menu at the top is still visible because I want to see people's faces as I'm presenting. And I haven't figured out how to do that correctly on my computer. So I'm just presenting the window of Deckset. +And I'm like, I have given myself permission to do all of those things, and that has been super helpful, actually. So that's a version of me negotiating what this means. Where I do invest the effort is trying to enumerate all of the things and then understand what is the story that I'm telling around the things and how do I get the message right for the collective audience? So, for a developer team, I would say much more nuanced technical things, for marketing folks, it would be at this end of the spectrum. +I do lean on the old idea of, like, let us talk about it in the mindset of the user, so it's very much user-centric, but then some of the things that we're doing are important but invisible to the users. They're part of how we broadly build the platform that we need to, but they're completely invisible to users. And so, how do I then tell that story still with ideally a user-centric point of view? So that's where I do invest the time, and I give myself complete freedom to just grab screenshots, put black text on a white background, and then talk over it. +STEPH: I love it. Because you made this comparison earlier, so now I'm thinking of a comparison of like TDD-driven presentations where it's like, what's the end goal? What's the assertion? What's the outcome that I want? And then backfilling from there. Or, in your case, you're talking about what's the story that I need to tell? What's the takeaway that I want people to have? So then you start there, and then you figure out what's the supplemental information that you need to provide to then get there. +And the fact that you don't twiddle with fonts and all that stuff, I think you're already really on your way [chuckles] in terms of finding that right optimization of I need to present a clear and helpful message but not sink too much time into this +CHRIS: Black text on a white background is very clear. So... +STEPH: [laughs] If there are any designers listening to this, they might just be cringing to this conversation right now. [laughs] +CHRIS: I actually wonder about what the...I know that dark mode is a thing that lots of folks care about. I'm thinking about the accessibility affordance of it now. I'm actually thinking through it now that I said it somewhat flippantly. I actually don't know what I'm talking about, but it was easy, and it wasn't a choice that I allowed myself to think about. So there we are. +Mid-roll Ad +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: In my personal world, so Tim and I are moving. We're on the move. We are transitioning from South Carolina to North Carolina. So I think I may have shared a bit of this news, but Tim has acquired his first software developer job, which is just phenomenal. It is in North Carolina. He does need to be there in person for it. So we are currently selling our South Carolina house and then moving. +It's not too far. It's like three and a half hours away to where we're moving in North Carolina because we're already pretty far in North and South Carolina. So yeah, there's always another box that needs to be packed. And there's always just something else that you forget, another thing that you want to take to Goodwill or try to give to a neighbor. It's a good way to purge. I will definitely say that every time you move, it's a good time to get rid of things. +CHRIS: That is a very cup half-full point of view on it, but yeah, it feels true. +STEPH: [laughs] It's true. I'm a very cup half-full person. For more technical news, for more client stuff that I've been working on, so I think the last time we chatted, I was sharing that we had this mysterious CI slowdown where we were going from CI builds taking around 25 minutes to spiking to 35, sometimes 45 minutes, and I have an update there. So we found out some really great things, and we have gotten it back down to probably more about 23 minutes is where the CI is running currently. +As for the actual who done it, like what caused this specific slowdown, we got to a point where we were like, we're doing so much investigative work to understand exactly what caused this that it felt less helpful because at the end of the day, we really just wanted to address the issue. And so solving the mystery of exactly what caused this started to feel less and less meaningful because we're like, well, we want to improve this anyways. +So even if we found that one line or something that happened that caused this, we want a bigger solution to this type of problem because then this could happen again like, someone else maybe adds one line or something happens, and things get thrown off balance, and then suddenly, we have a slowdown, and that just takes too long to investigate. +So I don't have a concrete who done it answer for the slowdown. But we've learned a couple of things; one of the things that we learned is we're using parallel_tests to then split our tests across all of the CPUs that are then running the RSpec test. And we realized that we weren't actually splitting tests based on runtime data. +So there are a couple of ways that paralleltests will let you divvy up your test, and two of those ways one is file size. So you can split the files based on the size of the file, or you can use info from the runtime log. So then paralleltests can be a little bit more intelligent about like, well, I know how long these files take, so I'm going to split it based on that versus just the size of the file. +And we realized that we were defaulting and using the file size instead of the runtime even though we all thought we were using runtime. And the reason for this took a bit of source code diving because looking at the README for paralleltests; it looked like as long as we're passing in a file to the runtime log path, then paralleltests is going to use that runtime data. But then there's some sneaky-sneaky in there that I'll actually link to in the show notes in case anybody's interested. +But if you are setting a particular flag and don't pass in another flag, then paralleltests is going to be like, cool, I'm going to portion out your test based on file size instead of the runtime. So we fixed that, or we updated that, and that has had a significant improvement for the test being split out more evenly. So we didn't have a CPU that was taking 25 minutes while the next CPU was only taking like 17 minutes. And paralleltests also provides some really helpful data that because we have that runtime log file, we could tell how long each CPU is running and how they're getting split. +So the past couple of weeks, it's heavy measure, measure, measure, take all the data, create lots of graphs, understand what's happening, and then look for ways to then fix it. So figuring out how these files or how the tests were being distributed across, we had a number of graphs that were just showing us what's actually happening. So then we could track the improvement, so that was really nice. It was the measure twice and change something once [laughs], and then we got to see the benefit from it. +For scaling the CI, so we are looking on adding more machines to then process tests. That has been really interesting because we're at the point where we are adding more machines, but if we add more machines, we're not going to speed up how quickly our CI processes everything. Because we are splitting tests based on file size and not by examples, we're always going to have this effect of a tentpole. So if we have a file that takes 10 minutes, that's the fastest we're ever going to get. +So Joël and I are in discussions right now of where we still really want to understand what's the fastest we can achieve just by adding another machine or two versus are we at the point that, okay, scaling horizontally and adding more machines has been helpful, but we have reached the breaking point where we actually need to divvy out the tests at a smaller scale and have a queue approach? So then that way, we can really harness the power of then we don't have one file that takes 10 minutes, and we don't have to care either. +So if somebody adds a test to a file and suddenly a file goes from 12 minutes to like...well, hopefully, they added more than one test. [laughs] But let's say it goes from 10 minutes to 15 minutes; we don't want to have to manage that and understand that there's a tentpole. We just want to be able to divvy out all the examples and then have a queue approach. +That's probably going to be MVP two of this, but we're still waiting that out. But it's just been really interesting to realize that scaling horizontally really only takes you so far. Like, we've added one machine, maybe one more, so then we'll have three total. And then it's like, okay, that's great, but now we need to actually address this other bigger problem. +CHRIS: I know we've talked about this in previous episodes, but I'm super interested to hear as you progress into the queue approach because that's something that's been top of mind for me for a while. I don't know if we've talked about it before specifically, but Knapsack Pro is the one thing that I'm available as a service that does this. Do you have other tools that you're looking at for that, or is this still in the exploratory phase? +STEPH: Knapsack is still a top contender. There's also RSpec Queue; that's another one that we have in mind. Unfortunately, I really wish paralleltests let us do this, but paralleltests just doesn't quite offer that feature. And someone in the team, I think, even reached out to the maintainer of paralleltests, and they were like, "Yep, you're totally right. We're actually more focused in making sure that this works for everybody versus has specific features." And they gave a really nice thoughtful response, which we appreciated, so at least we could confirm that paralleltests won't do exactly the thing that we need. So yeah, RSpec Queue, Knapsack, I think those are the top two that I'm familiar with. +CHRIS: Gotcha. I don't know if I've seen RSpec Queue before. I'm intrigued. So actually, an interesting thing happened. While I was away on vacation, one of the folks who just joined the team as one of their first steps joining the team, noticed that our CircleCI config wasn't actually taking advantage of the parallelism that we had configured; that's on me. I turned on parallelism and then never did anything with it, which is a complete waste. +And so I was super happy to come back and saw that CI, which had been creeping up to six or seven minutes, had suddenly dropped back down to two to three minutes sort of thing. I was like, this is amazing. But now I'm at the point where our RSpec suite is spreading across the different, I think, it's like four different cores that we have available, but it's not doing it as efficiently as we would like. So I'm like, oh, okay, can we dial it up to 11? +But I'm intrigued; I've only looked very much in passing at RSpec Queue literally now that you've mentioned it. But Knapsack Pro exists as a different service. And so, as far as I understand, the agent that's running is going to communicate and say, "Give me another test. Give me another test." But there needs to be some external process running and managing that queue. Does RSpec Queue do that? Somebody owns the queue, right? Who owns it? Do you understand how that works? +STEPH: So I was definitely familiar with this. If you'd asked me a couple of weeks ago, when I was diving heavily into the queue work before then, we transitioned more into focusing on then adding new machines; I was very up to speed on this. So I may get a couple of things wrong, but my understanding is that RSpec Queue, you're going to manage your own queue. So you bring in the gem and then use something like Redis, so then you are in charge of that. +And with Knapsack, then you are using their service to manage that queue. And then they have found ways to optimize around what if you can't reach their API or something; their service is down? And making sure that that doesn't impact your CI so then you can't still run your test just because you can't reach their queue somewhere. So that's my current understanding, RSpec Queue you own it, Knapsack they're going to own it. +CHRIS: Gotcha. That makes sense. That about maps to what I was expecting, and so I wonder if I could use RSpec Queue. Now I'm going to have to go research that. But it's always nice to have new things to look at on this to go at ludicrous speed. That's what I'm going for. I want to get to ludicrous speed for our CI. +STEPH: I like that name. I haven't heard of that speed. I feel like I have. I feel like you've dropped that before, [laughs] like you've used that. +CHRIS: I don't know; quite possibly, I have. It's a Spaceball’s reference. It's a throwback to days of old. +STEPH: Well, then we may be investigating RSpec Queue together. Because yeah, Joël's and I goal for this week has been very much to figure out what's our boundaries with TeamCity? What are our boundaries with horizontal scaling? And I think we're both getting to that conclusion of like, okay, this has been good, it's helpful, but we really need to look into the queue stuff if we really want to see significant progress. +Also, some of the stuff we're doing because we're pushing on it, we are manually splitting files. So if there's a file that has created this tentpole that's taking 10 minutes, but we know ideally most of the other files only take six minutes, then we are splitting that file, so then we have two spec files that are associated with the same class. And then using that as a way to say, okay, what would this look like? Let's say if this were better balanced. +And that's also been pushing us in the direction of like, okay, this is fun, this is informative, but it's not sustainable. We don't want to have to keep worrying about splitting these files and doing this manually and pushing us towards that queue-based approach. +MIDROLL AD: +And now a quick break to hear from today's sponsor, Studio 3T. +When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. +And now, there's Studio 3T Free, a free edition of Studio 3T which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with Mongo DB, SQL, Oracle and Sybase. +You can start today by downloading Studio 3T Free, which also includes a 30 day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial head to studio3t dot com forward slash free. That's studio dot com forward slash free. +But shifting gears just a bit, we have a listener question. So this person wrote in, "I have listened and loved your podcast for many years dreaming of getting a job with people half as thoughtful and intentional as you, and finally it happened. I have my first junior dev job, and my co-workers and bosses are all super awesome. Up until now, I've been flying solo. +And in my new job, I've been finding it very unsettling to resolve merge conflicts. As careful as I am to comb through the conflict and contact the other developer if needed, I feel like I am covering my eyes and crossing my fingers whenever I select the resolve conflict button. Is there some type of process or checklist I could rely on? Is it normal to have such a high fear factor with a merge conflict? Any advice or maybe just a bit of been there felt that way...?" +All right. So one, that's fabulous, congratulations on the new job. That's very exciting. I think I've voiced this many times, getting your first junior dev job is so hard, and so I'm so excited when it works out for people, and they get there. And then, for the merge conflict, I have thoughts. Chris, do you want to start? Shall I start? How are you feeling? +CHRIS: Why don't you start? Well, actually, I'm going to add some pre-commentary, and then I think you should lead into our actual answer. But first, I just want to say a deep thank you to this listener for sending in the question. Again, we really love getting these questions. And also, thank you for the very kind words. +To be clear, listener, if you're going to send in a question, you don't have to say very kind words, but they are really wonderful to hear and especially to hear if we had any part in helping this person feel more comfortable getting into that first dev role and having an idea of what maybe a good version of that could look like. +Additionally, I really love the shape of this question because it gets into the people stuff and the tech stuff, so I'm super excited about this question. Actually, both Steph you and I responded very quickly to this one. And so it really did catch our attention because I think it crosses that boundary in an interesting way that I think is sort of The Bike Shed space in the world. But to that end, you did reply first in our email chain. So I think you should start, and then I'll follow on after that. +STEPH: I should also check with you. Wait, so you don't have a filter on your email that's like kind words only to The Bike Shed, and then you filter out anything that's negative? +CHRIS: I have a sentiment analysis, and if it's even neutral, it gets sent straight to the trash, only purely positive. No, constructive feedback is welcome too. We would love to hear that. Well, love is a strong word. We would accept it into our inboxes and then deal with it, but yeah. +STEPH: [laughs] It will be tolerated. Must require at least three hearts in all emails; just kidding. [laughs] +CHRIS: Are you kidding? I'm counting them now, and I see a lot of hearts in our emails. +[laughter] +STEPH: Merge conflicts. So is it normal to have such a high fear factor with a merge conflict? I'm going to say absolutely. Resolving a merge conflict can be really tricky and confusing. And I think; frankly, it's something that comes with just time and practice where then you start to feel more confident. +As you're resolving these, you're going to feel more comfortable with understanding what's in the branch and the code changes that you're pulling in versus something that you need to keep on your side. So I think over time, that fear will subside. But I do think it's totally normal for that to be a very scary thing that then takes practice to become accustomed to it. +As for if there is some type of process or checklist, I don't know of a particular checklist, but I do have a couple of ideas. So one of the things that I do is I will often push my code to whatever management system I'm using. So if I'm using GitHub, then I'm going to push up my branch because then, at least that way, someone has a copy of my work. +So if I do something and I completely botch it locally, I know I can always reset to whatever it is that I pushed up to GitHub, so then that way, I have more freedom to make mistakes and then reset from there. So that is one idea is just put it somewhere that you know is safe, so that way you now have this comfortable sandbox to then make mistakes. +The other one is run the test. So hopefully, the application that you're working with has tests that you can trust; if not, that could be another conversation. But if they do have tests, then you can run those, and then hopefully, that would let you know that if you have left something in, like maybe you left a syntax error, or maybe you removed some code that you shouldn't have because you weren't sure, then those tests are going to fail, and they'll let you know that something went wrong. +And you can run those while you're still in the middle of that merge conflict as long as you've addressed like...well, no, if you haven't addressed syntax errors, that's still a time that you can run it, and it's going to let you know that you haven't caught all of the issues yet. So you don't have to wait till you're done to then go ahead and run that. +A couple of other ideas, practice. So go ahead and create your own merge conflicts on purpose. So this is something that I think is really helpful because it will teach you, one, what causes a merge conflict? Because now you have to figure out how to create one, and then it will help you become comfortable because you're in a completely safe place where you have made up the issue, and now you're having to resolve that, so it'll help you become more confident in reading that merge conflict message. +And then last but certainly not least, grab a buddy so if you are just feeling super nervous. Anytime I'm doing something that I just feel a little nervous about, then I just ask someone like, "Hey, would you look over my shoulder? Would you pair with me while I do this?" And I have found that's incredibly helpful because it eases some of my fear. I've got someone else that is also looking through this with me. But I also find it really helpful because then it encourages that person to be like, hey, if they're ever in a spot that they need to pair, I want them to know that they can also reach out to me and have that same buddy system. +I guess that's my checklist. That's the one I would create. How about you, Chris? What do you think? +CHRIS: Well, first, I just want to say that basically everything you said I 100% agree with, and purposely I think was great that you actually replied to the email first and that you're saying those things first because I think everything that you said is true and is foundational. And it's sort of the approach that I would definitely recommend taking as well. +My answer, then adding on to that, has to do with how I've approached learning about this space in my own career. To name it, to answer the core question, is it reasonable to be scared of this? Yes, Git is confusing. Git is deeply confusing. I absolutely love Git. I have spent a lot of time trying to understand it, and in understanding it, I've come to love it. But it's only through deep effort that I've gotten to that place. And actually, the interface, the way that we work with Git on a day-to-day basis, particularly the command line is rough. +I'm going to say, what does Git checkout do? Well, it does just about everything, it turns out. That command just does all of the stuff, and that's too much. It's, frankly, the UI for Git, specifically the command-line user interface; the commands that we run to manipulate the Git history are not super intuitive. But it turns out if you pop open the hood, the object model underneath the core way that Git stores your code is actually very simple. I find it's very easy to understand, but I, unfortunately, have found that I can't understand it without dropping down to that level. +And so, in my own adventures, I kind of went deep on this topic a couple of years ago, and I created a Vim plugin because obviously, that's the best way to encapsulate your knowledge about Git, and so I created a plugin called Vim Conflicted. I don't necessarily recommend the plugin. It's fine if you want to use it. I don't do a great job of maintaining my plugins at this point, to be honest. But there was a weekend where I was trying to understand the world of Git and merge conflicts in particular, and it was really sort of fighting me. +And as I started to understand it better, there's a little diagram that I drew on the README that I think is probably the most interesting artifact from it. But it's this idea that there are actually four files, four versions of a given file involved in any merge conflict. And that realization shifted my thinking a good amount. And then as I started to think about that, I was like, oh, okay, and then I want to see this version of it, and this version of it, and this combination, and the diff between these two, and that was super helpful for me. +More generally, I also made a course on Upcase about Git as I tried to understand it better. And there are two particular videos from the middle of the course named the Git Object Model and Object Model Operations. And again, those two videos deal with popping the hood on Git, looking inside it, and what actually is happening to your code as you perform different Git operations. +One of the wonderful things about Git is it is immutable. So you're never going to destroy your Git history if you've committed. So one of the rules that I have is just always be committing, never worry about committing. If you've committed, you can always get back to that version. You would have to try very hard to destroy committed code in Git. It's the things that you do when you haven't yet committed the code that are dangerous. +So commit the code, like you said, Steph, push that up to GitHub, so you have a backup of it. You will have a backup locally as well, and that's a thing that you can come to be more comfortable with. But then, from there, there's actually a lot of room to experiment and play around because there's a ton of safety in the way that Git stores the code. You do have to know how to get at it, and that's the unfortunate and tricky part. +But I think, again, to sort of summarize, yes, this is confusing. Your feelings are absolutely valid and totally grounded, but it is also knowable, is what I would say. And so, hopefully, there are a couple of breadcrumbs that we've laid there in how you might go about learning about it. But yeah, find a buddy, watch a video or two, and give it a try. This is definitely a thing that you can get there but totally reasonable that your first approximation is this is confusing because it sure is. +STEPH: I often forget that Git has that local copy of my code, so I'm so glad you mentioned that. And then yeah, I saw when you linked to Vim Conflicted. The diagrams are great. I had not seen these before. So yeah, I highly recommend folks take a look at those because I found those very valuable. +CHRIS: In that case, it's a white background, but I allowed myself to use some colors in the little images to help differentiate the different pieces. And it's an animated diagram, so it's really a high bar for me. [laughs] +STEPH: So now the question is, did you go too far? Have you over-optimized? [laughs] +CHRIS: I'm going to be honest; it was a weird weekend. +STEPH: [laughs] Well, I don't think you've over-optimized. I do think it's wonderful. And I think this is definitely a reference that I'll keep in mind for folks whenever they're learning about merge conflicts or just want to get more knowledgeable about them. I think these diagrams are fabulous. +CHRIS: Well, thanks. Yeah, I hope...they frankly were a labor of love, and the course is three and a half hours of me rambling about Git, so hopefully, it's useful to folks. If anything, it was super useful to me because my understanding of Git was deeply crystallized in making that course. But I do hope that it's useful to other folks. And particularly those two videos that I highlighted, I think are the ones that have been most impactful for me in terms of how I think about working with Git and getting comfortable with it. +STEPH: Do you still receive emails every now and then from people, or maybe they are tweets from people that are like, "Hey, I watched one of your videos and found it really helpful." I feel like I still see that every now and then where people are just commenting on like, they watched some of the content that you created for Upcase a while back, and I think that's really cool. I'm curious if you still see that. +CHRIS: I do, yeah, from time to time. It is absolutely wonderful whenever I hear that. Again, listener, do not feel the need to send me anything, but it is nice when I get them. +STEPH: It does seem like I'm fishing for compliments now. [laughs] +CHRIS: It does seem like that. So I want to be clear that's not what's going on here. But it is nice because I do actually forget that they're out there. But a lot of the stuff that I produced for Upcase, in particular, I tried to do more timeless stuff, so like the Vim content was really about how Vim works in a deep way. +And the tmux course and the Upcase course...or the tmux course, the Git course. I look back at them, and a couple of little syntactic things have changed. But I'm still like, yeah, I agree with me from six years ago or whatever it was. Oh, that's a weird number to say, and I think is honest. It's fine. I'll just be over here. [laughs] +STEPH: [laughs] That's helpful to hear, though, because that's always one of my fears in creating content. It's like, I don't know, it's okay if it's more opinionated and I change my mind and disagree with my past self. But it's more like, yeah, keeping up with is this still accurate? Is this still reflective of the times? And then having to keep that stuff updated. Anywho, that's a whole big thing, content creation. +CHRIS: Content creation, but there's a parallel to it that many folks will not be creating content, and I think that's a very fine and good way to go about progressing on the internet. But there's a parallel to it in learning that I think is useful. I, at this point, will typically lean in if there is something in the SQL layer that is fighting me. I have never found effort spent trying to better understand the structured query language to be wasted time. +Similarly, Git is one of those tools that is just so core to the workflow that it felt very worth it to me to spend a little bit of extra time to get to a deeper level of comfort with it, and I have not regretted one minute of that. Vim and tmux are pretty similar because they're such core tools for me. +But React, I would not call myself a deep expert of React. I follow some of the changes that are happening but not as deeply, and I'm not as worried about it. And if I'm like, I don't know how to do this thing, should I spend two hours learning about it or not? With frameworks and tools that have not been part of my toolset for as long, I will spend less time on them. +And I think that the courses that I produced on Upcase mirror that. They're the things that I'm like; I feel very true about these things versus other stuff. Maybe it was in a weekly iteration episode or something like that. But that very much mirrors how I think about learning as well. What are the things that I'm going to continually invest in versus what are the things that I’ll sort of keep an eye on from a distance but not necessarily invest as much time in? +STEPH: There's a particular article that you're making me think of as we're talking about content creation and, as you mentioned, finding the things that you always find value in investing in. There's a wonderful blog post that was recently posted on the thoughtbot blog by Matheus Richard, and it's called The Opportunity Will Find You. +And it made me think a lot about what you're talking about, find the things that you're excited about, find the things that you think are a good investment and just go ahead and lean into it. And it's okay if maybe that's not the thing that you're using currently at your work, but if it's something that gets you excited, then go ahead and pursue that. +So in this article, for example, Matheus uses the example of learning Rust, and that's something that he's very excited about and wants to learn more about. And then there's another one where he started looking into crafting interpreters. And then that has actually led to then some fruitful work around creating custom RuboCops because then he had more knowledge around how the code is being interpreted so then he could write custom RuboCops. +So yeah, plus-one to finding the things that give you energy and joy and leaning into that and investing in it. And if you share it with the world, that's fabulous, and if you don't, then keep it for yourself and enjoy it, whatever makes you happy. On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris is back from vacation and gives hiring and onboarding updates.

+ +

Steph has an update about the CI slowdown and scaling CI.

+ +

They tackle a listener question regarding having some fear around potential merge conflicts.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Golden roads are golden.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Oh, I also have a new intro that I want to try out. This is thanks to Irmela from Twitter, where it's good morning and hooray; today is Bike Shed day. They technically said Tuesday, but we don't record on Tuesdays. So today is Bike Shed day, so happy Bike Shed day. And hey, Chris, what's new in your world?

+ +

CHRIS: What is new in my world? Yeah, I loved when I saw that tweet come out. It really warmed my heart. So Tuesday, in theory, is Bike Shed day, but for you and I, Friday is Bike Shed day. It's confusing breaking the fourth wall, as I so often do. But yeah, what's new in my world? I'm back from vacation, which is the thing that I did. For listeners, well, I have been absent the previous week related to vacation and all those sorts of things.

+ +

But I did what we're going to describe as a not smart thing. It wasn't intentional. The world just kind of conspired in this way. But I had two separate vacation islands that existed in my mind, and then they both kind of congealed, but as they did that, they moved towards each other, but they didn't connect.

+ +

And so what I ended up with was two weeks back to back where I was out on Thursday and Friday of one week, and then I was back for Monday and Tuesday. And then I was out for Wednesday, Thursday, Friday of the following week. Protip: that's a terrible idea. It's just not enough time to sort of catch up.

+ +

The whole of it was like the ramp-up to vacation and then the noise of vacation, then getting back and being like, oh, there are so many emails. Let me try and catch up on them. But also, on the very positive side, we had a new hire join the team, and so most of my focus on the days that I was in the office was around getting that new person comfortable on the team, onboarding, spending as much time as possible with them.

+ +

And so, all total, it was an adventure. And again, I would strongly recommend against this. The world just kind of conspired, and suddenly these three different forces in my life came together. And this was just the shape of things. But yeah, I went on vacation, and it was great. The vacation part was great.

+ +

STEPH: I will take your advice. So next time I have like two segments of PTO, I'm just going to stitch them together and just go ahead and take that whole intermittent time off.

+ +

CHRIS: That probably would have been better. Again, someone new joining the team, it was very important to me to get some time with them early on, and so I opted not to do that. But yeah, the attempt to catch up in between was a completely lost effort, I would say. But I think I'm mostly caught up now, having been back in the office for about a week, so yeah.

+ +

But let's see, what else has been up in my world? It's actually been a while since you and I have chatted based on the various timing and schedules and the nonsense vacation schedule that I had that you so kindly accommodated across a couple of weeks. Let's see, hiring and onboarding; the hiring went really well. We talked about that a bunch of weeks back. But now we're in the onboarding phase. And so next week will be the first week that all four of us on the engineering team are in the office together for the full week. I'm super excited to experience that.

+ +

We've had different portions of it, with me being on vacation and other folks being on vacation. But now, for the first time, we're really going to feel what it’s like as this team. And we're going to have our first retro as a group and all those sorts of things, so I'm very excited to do that. And thus far, all of the interactions that we've had have been really wonderful as a team. And so now it'll be the first time we're just bringing all of those various pieces together.

+ +

STEPH: I just have to clarify; you said all of y'all in the office together. Do you still mean remotely?

+ +

CHRIS: Oh, yes, yes, I just mean not on vacation, all present and accounted for on the internet. Remote is another interesting facet of what we're doing here and trying to figure out how to navigate that, particularly where there are some folks that are closer and can potentially get together in the city, that sort of thing, and then folks that are truly remote and making sure that we're...I'm very much of the opinion if we have anyone that's remote, we are remote team, and we must embrace async communication and really lean into that.

+ +

And I think the benefits of async communication as its own consideration are so worth it. And it's one of those things that's hard to do. It requires careful, intentional thought. It requires more purposeful communication. But I think there are a lot of good things that fall out of that. It's similar to TDD in that way in my mind, like, it's not easy. It's actually quite difficult. But all the effort that I put into trying to learn how to do that has made me a better developer, I think, on all the various fronts.

+ +

And I think similarly, async communication I believe in as a tool to force just better communication. And so I'm a big believer in it, and I've found a ton of benefit in remote that I'm also a big believer in that now. I, like everyone else, was forced into it as the world was, but I've really come to enjoy it a lot. And so yeah, so, no, not physically in the office, to answer your very short question with a long rambling aside.

+ +

STEPH: [laughs] I like that comparison. I hadn't thought about it in that way but comparing that thoughtfulness and helpfulness of async communication and then also to TDD, where it's not easy, but the payoff is so worth it, the upfront cost of it. That is something that at thoughtbot, we've had conversations around where there are folks that really value...they want to be around people. They get energy from people, and so they want that option to be able to rent a WeWork space and maybe get together with a colleague once or twice a week, and that was supported by thoughtbot.

+ +

But we also wanted to express well, if you are together, do treat everything still as a remote work environment. So let's say if you and your colleagues are on a project, but then there's a third person on that project that's remote, you still need to act like everything's remote to make sure that everyone else is still getting to participate and hear everything and be part of the conversation. So just keeping that in mind that yes, we want to support you doing your best work, and if that's around people, that's wonderful. But we are still remote-first, and communication needs to be in that fashion.

+ +

Well, that's super exciting that you'll have all of the team together. That sounds like it will be wonderful to hear about and then also retros and meetings, and yeah, it sounds like you've got a fun week ahead.

+ +

CHRIS: Indeed. I'm super excited to see what sort of new things come out of the new voices on the team and practices that each of the individuals have experienced at other companies that we can now fold together. The work that we've done so far has been very much inspired by thoughtbot ideas, and approaches, and workflows, and processes because that's what I brought to the table. But I'm super excited to bring in more voices and see what of that 100% stays on versus does anything change? Do we get entirely new things? So yeah, very excited about all of that.

+ +

But to revisit a topic that we've talked about in the past, this week is catching up from vacation, so there's a certain amount that will constrain my work. But this was definitely another week of I did not do much coding. I'm trying to think if I did any coding this week. It's possible that the answer is no. The fact that I don't even know the answer to that is an interesting one. I still have in my mind the desire to get back to it, and I think I will. But there's so much other stuff to do.

+ +

Recently, this week, there's been a lot of vendor selection and contract negotiation, which is an interesting facet of the work, but just trying to figure out, oh, we need platforms to do X, Y, and Z. And it turns out they're wildly costly and have long sales cycles. And how do you go through that, and how do you make sure that we're getting the right thing? And so that's been a big part of my work. Hiring and onboarding, again, has been a big part of it.

+ +

There's also some amount of communicating back to the broader team - what are we doing? What is the product organization or the engineering team delivering? And so I'm okay at presentations, I think. I'm comfortable with giving presentations. The thing that I struggle with is finding the optimization point in preparation. I will, of my own accord, over-prepare. And that may sound a little bit like, oh, what's my greatest weakness? That I care too much.

+ +

But I mean it sincerely as like, I would love to find that right amount of like, it's like an hour of preparation for a 15-minute presentation to the team. That's the right ratio. And I just hit that on the head, and it's great. But whenever I know that I need to give a larger presentation, it will distract me. And it's work that can expand to fill whatever time you give it, and so trying to thread that needle is a tricky one for me.

+ +

STEPH: Yeah, I'm with you. Presentations, for me, they're one of those things that it's very stressful, anxiety-inducing; all the prep feels distracting from some of the other work that I want to do. Or maybe I'm excited about the presentation, and that is the work that I want to do. But it's not until it's done that then I'm like, oh, that was fun. That went well. This was great.

+ +

It's not until after that then I feel good about it. So the lead-up to it is very stressful. And so if you can optimize that to say, well, I know exactly what this group needs, where I can cut corners, where I have to go into details, that sounds incredibly valuable.

+ +

I'm curious, so this is probably a bad idea, but it's the only way I really know how to find those boundaries is you got to experiment and tweak a little bit and let yourself fail a little bit or just be very explicit with folks about this is what the presentation is, if you expected something else, let me know. Or here's what I've got, have someone to bounce ideas off of.

+ +

But there's such a nicety if you can find that I'm going to try failing just a little bit and get some feedback. Or maybe it's not failing at all, but you are testing that boundary to find out did this work, or should I put more effort into this? I'm curious, do you have thoughts on that? How you're going to find that right optimization level?

+ +

CHRIS: Not as specific to truly honing in on whatever the correct number is. The thing that I've been doing is I...this will sound complicated, but I wait until the last minute but a specific version of the last minute. So at most, I start working on it an hour and a half before the meeting. And these are, again, not particularly large presentations, and it's a recurring sort of thing. So it's sort of engineering talking about the work that we've done recently and trying to find the right level of detail and whatnot, so giving myself a smaller time window.

+ +

I think that's enough time to tell the story and to find a meaningful way to tell the story and grab the screenshots and all of that, but it's constrained so that I don't over-optimize, over-edit, overthink. I'm using Deckset, which is a presentation tool that starts from a Markdown file. So it's just a Markdown file that I'm editing. That's great; that works really well. I do not twiddle with fonts. There's one theme that I use. It is white background with black text. That's it.

+ +

And I think I've given myself deep permission to be the CTO that has a white background with black text and no transitions. I don't even go into presentation mode for it. I'm literally showing the UI of Deckset, and then just hitting the arrow to move between them. But the Chrome and the drop-down menu at the top is still visible because I want to see people's faces as I'm presenting. And I haven't figured out how to do that correctly on my computer. So I'm just presenting the window of Deckset.

+ +

And I'm like, I have given myself permission to do all of those things, and that has been super helpful, actually. So that's a version of me negotiating what this means. Where I do invest the effort is trying to enumerate all of the things and then understand what is the story that I'm telling around the things and how do I get the message right for the collective audience? So, for a developer team, I would say much more nuanced technical things, for marketing folks, it would be at this end of the spectrum.

+ +

I do lean on the old idea of, like, let us talk about it in the mindset of the user, so it's very much user-centric, but then some of the things that we're doing are important but invisible to the users. They're part of how we broadly build the platform that we need to, but they're completely invisible to users. And so, how do I then tell that story still with ideally a user-centric point of view? So that's where I do invest the time, and I give myself complete freedom to just grab screenshots, put black text on a white background, and then talk over it.

+ +

STEPH: I love it. Because you made this comparison earlier, so now I'm thinking of a comparison of like TDD-driven presentations where it's like, what's the end goal? What's the assertion? What's the outcome that I want? And then backfilling from there. Or, in your case, you're talking about what's the story that I need to tell? What's the takeaway that I want people to have? So then you start there, and then you figure out what's the supplemental information that you need to provide to then get there.

+ +

And the fact that you don't twiddle with fonts and all that stuff, I think you're already really on your way [chuckles] in terms of finding that right optimization of I need to present a clear and helpful message but not sink too much time into this

+ +

CHRIS: Black text on a white background is very clear. So...

+ +

STEPH: [laughs] If there are any designers listening to this, they might just be cringing to this conversation right now. [laughs]

+ +

CHRIS: I actually wonder about what the...I know that dark mode is a thing that lots of folks care about. I'm thinking about the accessibility affordance of it now. I'm actually thinking through it now that I said it somewhat flippantly. I actually don't know what I'm talking about, but it was easy, and it wasn't a choice that I allowed myself to think about. So there we are.

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: In my personal world, so Tim and I are moving. We're on the move. We are transitioning from South Carolina to North Carolina. So I think I may have shared a bit of this news, but Tim has acquired his first software developer job, which is just phenomenal. It is in North Carolina. He does need to be there in person for it. So we are currently selling our South Carolina house and then moving.

+ +

It's not too far. It's like three and a half hours away to where we're moving in North Carolina because we're already pretty far in North and South Carolina. So yeah, there's always another box that needs to be packed. And there's always just something else that you forget, another thing that you want to take to Goodwill or try to give to a neighbor. It's a good way to purge. I will definitely say that every time you move, it's a good time to get rid of things.

+ +

CHRIS: That is a very cup half-full point of view on it, but yeah, it feels true.

+ +

STEPH: [laughs] It's true. I'm a very cup half-full person. For more technical news, for more client stuff that I've been working on, so I think the last time we chatted, I was sharing that we had this mysterious CI slowdown where we were going from CI builds taking around 25 minutes to spiking to 35, sometimes 45 minutes, and I have an update there. So we found out some really great things, and we have gotten it back down to probably more about 23 minutes is where the CI is running currently.

+ +

As for the actual who done it, like what caused this specific slowdown, we got to a point where we were like, we're doing so much investigative work to understand exactly what caused this that it felt less helpful because at the end of the day, we really just wanted to address the issue. And so solving the mystery of exactly what caused this started to feel less and less meaningful because we're like, well, we want to improve this anyways.

+ +

So even if we found that one line or something that happened that caused this, we want a bigger solution to this type of problem because then this could happen again like, someone else maybe adds one line or something happens, and things get thrown off balance, and then suddenly, we have a slowdown, and that just takes too long to investigate.

+ +

So I don't have a concrete who done it answer for the slowdown. But we've learned a couple of things; one of the things that we learned is we're using parallel_tests to then split our tests across all of the CPUs that are then running the RSpec test. And we realized that we weren't actually splitting tests based on runtime data.

+ +

So there are a couple of ways that parallel_tests will let you divvy up your test, and two of those ways one is file size. So you can split the files based on the size of the file, or you can use info from the runtime log. So then parallel_tests can be a little bit more intelligent about like, well, I know how long these files take, so I'm going to split it based on that versus just the size of the file.

+ +

And we realized that we were defaulting and using the file size instead of the runtime even though we all thought we were using runtime. And the reason for this took a bit of source code diving because looking at the README for parallel_tests; it looked like as long as we're passing in a file to the runtime log path, then parallel_tests is going to use that runtime data. But then there's some sneaky-sneaky in there that I'll actually link to in the show notes in case anybody's interested.

+ +

But if you are setting a particular flag and don't pass in another flag, then parallel_tests is going to be like, cool, I'm going to portion out your test based on file size instead of the runtime. So we fixed that, or we updated that, and that has had a significant improvement for the test being split out more evenly. So we didn't have a CPU that was taking 25 minutes while the next CPU was only taking like 17 minutes. And parallel_tests also provides some really helpful data that because we have that runtime log file, we could tell how long each CPU is running and how they're getting split.

+ +

So the past couple of weeks, it's heavy measure, measure, measure, take all the data, create lots of graphs, understand what's happening, and then look for ways to then fix it. So figuring out how these files or how the tests were being distributed across, we had a number of graphs that were just showing us what's actually happening. So then we could track the improvement, so that was really nice. It was the measure twice and change something once [laughs], and then we got to see the benefit from it.

+ +

For scaling the CI, so we are looking on adding more machines to then process tests. That has been really interesting because we're at the point where we are adding more machines, but if we add more machines, we're not going to speed up how quickly our CI processes everything. Because we are splitting tests based on file size and not by examples, we're always going to have this effect of a tentpole. So if we have a file that takes 10 minutes, that's the fastest we're ever going to get.

+ +

So Joël and I are in discussions right now of where we still really want to understand what's the fastest we can achieve just by adding another machine or two versus are we at the point that, okay, scaling horizontally and adding more machines has been helpful, but we have reached the breaking point where we actually need to divvy out the tests at a smaller scale and have a queue approach? So then that way, we can really harness the power of then we don't have one file that takes 10 minutes, and we don't have to care either.

+ +

So if somebody adds a test to a file and suddenly a file goes from 12 minutes to like...well, hopefully, they added more than one test. [laughs] But let's say it goes from 10 minutes to 15 minutes; we don't want to have to manage that and understand that there's a tentpole. We just want to be able to divvy out all the examples and then have a queue approach.

+ +

That's probably going to be MVP two of this, but we're still waiting that out. But it's just been really interesting to realize that scaling horizontally really only takes you so far. Like, we've added one machine, maybe one more, so then we'll have three total. And then it's like, okay, that's great, but now we need to actually address this other bigger problem.

+ +

CHRIS: I know we've talked about this in previous episodes, but I'm super interested to hear as you progress into the queue approach because that's something that's been top of mind for me for a while. I don't know if we've talked about it before specifically, but Knapsack Pro is the one thing that I'm available as a service that does this. Do you have other tools that you're looking at for that, or is this still in the exploratory phase?

+ +

STEPH: Knapsack is still a top contender. There's also RSpec Queue; that's another one that we have in mind. Unfortunately, I really wish parallel_tests let us do this, but parallel_tests just doesn't quite offer that feature. And someone in the team, I think, even reached out to the maintainer of parallel_tests, and they were like, "Yep, you're totally right. We're actually more focused in making sure that this works for everybody versus has specific features." And they gave a really nice thoughtful response, which we appreciated, so at least we could confirm that parallel_tests won't do exactly the thing that we need. So yeah, RSpec Queue, Knapsack, I think those are the top two that I'm familiar with.

+ +

CHRIS: Gotcha. I don't know if I've seen RSpec Queue before. I'm intrigued. So actually, an interesting thing happened. While I was away on vacation, one of the folks who just joined the team as one of their first steps joining the team, noticed that our CircleCI config wasn't actually taking advantage of the parallelism that we had configured; that's on me. I turned on parallelism and then never did anything with it, which is a complete waste.

+ +

And so I was super happy to come back and saw that CI, which had been creeping up to six or seven minutes, had suddenly dropped back down to two to three minutes sort of thing. I was like, this is amazing. But now I'm at the point where our RSpec suite is spreading across the different, I think, it's like four different cores that we have available, but it's not doing it as efficiently as we would like. So I'm like, oh, okay, can we dial it up to 11?

+ +

But I'm intrigued; I've only looked very much in passing at RSpec Queue literally now that you've mentioned it. But Knapsack Pro exists as a different service. And so, as far as I understand, the agent that's running is going to communicate and say, "Give me another test. Give me another test." But there needs to be some external process running and managing that queue. Does RSpec Queue do that? Somebody owns the queue, right? Who owns it? Do you understand how that works?

+ +

STEPH: So I was definitely familiar with this. If you'd asked me a couple of weeks ago, when I was diving heavily into the queue work before then, we transitioned more into focusing on then adding new machines; I was very up to speed on this. So I may get a couple of things wrong, but my understanding is that RSpec Queue, you're going to manage your own queue. So you bring in the gem and then use something like Redis, so then you are in charge of that.

+ +

And with Knapsack, then you are using their service to manage that queue. And then they have found ways to optimize around what if you can't reach their API or something; their service is down? And making sure that that doesn't impact your CI so then you can't still run your test just because you can't reach their queue somewhere. So that's my current understanding, RSpec Queue you own it, Knapsack they're going to own it.

+ +

CHRIS: Gotcha. That makes sense. That about maps to what I was expecting, and so I wonder if I could use RSpec Queue. Now I'm going to have to go research that. But it's always nice to have new things to look at on this to go at ludicrous speed. That's what I'm going for. I want to get to ludicrous speed for our CI.

+ +

STEPH: I like that name. I haven't heard of that speed. I feel like I have. I feel like you've dropped that before, [laughs] like you've used that.

+ +

CHRIS: I don't know; quite possibly, I have. It's a Spaceball’s reference. It's a throwback to days of old.

+ +

STEPH: Well, then we may be investigating RSpec Queue together. Because yeah, Joël's and I goal for this week has been very much to figure out what's our boundaries with TeamCity? What are our boundaries with horizontal scaling? And I think we're both getting to that conclusion of like, okay, this has been good, it's helpful, but we really need to look into the queue stuff if we really want to see significant progress.

+ +

Also, some of the stuff we're doing because we're pushing on it, we are manually splitting files. So if there's a file that has created this tentpole that's taking 10 minutes, but we know ideally most of the other files only take six minutes, then we are splitting that file, so then we have two spec files that are associated with the same class. And then using that as a way to say, okay, what would this look like? Let's say if this were better balanced.

+ +

And that's also been pushing us in the direction of like, okay, this is fun, this is informative, but it's not sustainable. We don't want to have to keep worrying about splitting these files and doing this manually and pushing us towards that queue-based approach.

+ +

MIDROLL AD:

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with Mongo DB, SQL, Oracle and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30 day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial head to studio3t dot com forward slash free. That's studio dot com forward slash free.

+ +

But shifting gears just a bit, we have a listener question. So this person wrote in, "I have listened and loved your podcast for many years dreaming of getting a job with people half as thoughtful and intentional as you, and finally it happened. I have my first junior dev job, and my co-workers and bosses are all super awesome. Up until now, I've been flying solo.

+ +

And in my new job, I've been finding it very unsettling to resolve merge conflicts. As careful as I am to comb through the conflict and contact the other developer if needed, I feel like I am covering my eyes and crossing my fingers whenever I select the resolve conflict button. Is there some type of process or checklist I could rely on? Is it normal to have such a high fear factor with a merge conflict? Any advice or maybe just a bit of been there felt that way...?"

+ +

All right. So one, that's fabulous, congratulations on the new job. That's very exciting. I think I've voiced this many times, getting your first junior dev job is so hard, and so I'm so excited when it works out for people, and they get there. And then, for the merge conflict, I have thoughts. Chris, do you want to start? Shall I start? How are you feeling?

+ +

CHRIS: Why don't you start? Well, actually, I'm going to add some pre-commentary, and then I think you should lead into our actual answer. But first, I just want to say a deep thank you to this listener for sending in the question. Again, we really love getting these questions. And also, thank you for the very kind words.

+ +

To be clear, listener, if you're going to send in a question, you don't have to say very kind words, but they are really wonderful to hear and especially to hear if we had any part in helping this person feel more comfortable getting into that first dev role and having an idea of what maybe a good version of that could look like.

+ +

Additionally, I really love the shape of this question because it gets into the people stuff and the tech stuff, so I'm super excited about this question. Actually, both Steph you and I responded very quickly to this one. And so it really did catch our attention because I think it crosses that boundary in an interesting way that I think is sort of The Bike Shed space in the world. But to that end, you did reply first in our email chain. So I think you should start, and then I'll follow on after that.

+ +

STEPH: I should also check with you. Wait, so you don't have a filter on your email that's like kind words only to The Bike Shed, and then you filter out anything that's negative?

+ +

CHRIS: I have a sentiment analysis, and if it's even neutral, it gets sent straight to the trash, only purely positive. No, constructive feedback is welcome too. We would love to hear that. Well, love is a strong word. We would accept it into our inboxes and then deal with it, but yeah.

+ +

STEPH: [laughs] It will be tolerated. Must require at least three hearts in all emails; just kidding. [laughs]

+ +

CHRIS: Are you kidding? I'm counting them now, and I see a lot of hearts in our emails.

+ +

[laughter]

+ +

STEPH: Merge conflicts. So is it normal to have such a high fear factor with a merge conflict? I'm going to say absolutely. Resolving a merge conflict can be really tricky and confusing. And I think; frankly, it's something that comes with just time and practice where then you start to feel more confident.

+ +

As you're resolving these, you're going to feel more comfortable with understanding what's in the branch and the code changes that you're pulling in versus something that you need to keep on your side. So I think over time, that fear will subside. But I do think it's totally normal for that to be a very scary thing that then takes practice to become accustomed to it.

+ +

As for if there is some type of process or checklist, I don't know of a particular checklist, but I do have a couple of ideas. So one of the things that I do is I will often push my code to whatever management system I'm using. So if I'm using GitHub, then I'm going to push up my branch because then, at least that way, someone has a copy of my work.

+ +

So if I do something and I completely botch it locally, I know I can always reset to whatever it is that I pushed up to GitHub, so then that way, I have more freedom to make mistakes and then reset from there. So that is one idea is just put it somewhere that you know is safe, so that way you now have this comfortable sandbox to then make mistakes.

+ +

The other one is run the test. So hopefully, the application that you're working with has tests that you can trust; if not, that could be another conversation. But if they do have tests, then you can run those, and then hopefully, that would let you know that if you have left something in, like maybe you left a syntax error, or maybe you removed some code that you shouldn't have because you weren't sure, then those tests are going to fail, and they'll let you know that something went wrong.

+ +

And you can run those while you're still in the middle of that merge conflict as long as you've addressed like...well, no, if you haven't addressed syntax errors, that's still a time that you can run it, and it's going to let you know that you haven't caught all of the issues yet. So you don't have to wait till you're done to then go ahead and run that.

+ +

A couple of other ideas, practice. So go ahead and create your own merge conflicts on purpose. So this is something that I think is really helpful because it will teach you, one, what causes a merge conflict? Because now you have to figure out how to create one, and then it will help you become comfortable because you're in a completely safe place where you have made up the issue, and now you're having to resolve that, so it'll help you become more confident in reading that merge conflict message.

+ +

And then last but certainly not least, grab a buddy so if you are just feeling super nervous. Anytime I'm doing something that I just feel a little nervous about, then I just ask someone like, "Hey, would you look over my shoulder? Would you pair with me while I do this?" And I have found that's incredibly helpful because it eases some of my fear. I've got someone else that is also looking through this with me. But I also find it really helpful because then it encourages that person to be like, hey, if they're ever in a spot that they need to pair, I want them to know that they can also reach out to me and have that same buddy system.

+ +

I guess that's my checklist. That's the one I would create. How about you, Chris? What do you think?

+ +

CHRIS: Well, first, I just want to say that basically everything you said I 100% agree with, and purposely I think was great that you actually replied to the email first and that you're saying those things first because I think everything that you said is true and is foundational. And it's sort of the approach that I would definitely recommend taking as well.

+ +

My answer, then adding on to that, has to do with how I've approached learning about this space in my own career. To name it, to answer the core question, is it reasonable to be scared of this? Yes, Git is confusing. Git is deeply confusing. I absolutely love Git. I have spent a lot of time trying to understand it, and in understanding it, I've come to love it. But it's only through deep effort that I've gotten to that place. And actually, the interface, the way that we work with Git on a day-to-day basis, particularly the command line is rough.

+ +

I'm going to say, what does Git checkout do? Well, it does just about everything, it turns out. That command just does all of the stuff, and that's too much. It's, frankly, the UI for Git, specifically the command-line user interface; the commands that we run to manipulate the Git history are not super intuitive. But it turns out if you pop open the hood, the object model underneath the core way that Git stores your code is actually very simple. I find it's very easy to understand, but I, unfortunately, have found that I can't understand it without dropping down to that level.

+ +

And so, in my own adventures, I kind of went deep on this topic a couple of years ago, and I created a Vim plugin because obviously, that's the best way to encapsulate your knowledge about Git, and so I created a plugin called Vim Conflicted. I don't necessarily recommend the plugin. It's fine if you want to use it. I don't do a great job of maintaining my plugins at this point, to be honest. But there was a weekend where I was trying to understand the world of Git and merge conflicts in particular, and it was really sort of fighting me.

+ +

And as I started to understand it better, there's a little diagram that I drew on the README that I think is probably the most interesting artifact from it. But it's this idea that there are actually four files, four versions of a given file involved in any merge conflict. And that realization shifted my thinking a good amount. And then as I started to think about that, I was like, oh, okay, and then I want to see this version of it, and this version of it, and this combination, and the diff between these two, and that was super helpful for me.

+ +

More generally, I also made a course on Upcase about Git as I tried to understand it better. And there are two particular videos from the middle of the course named the Git Object Model and Object Model Operations. And again, those two videos deal with popping the hood on Git, looking inside it, and what actually is happening to your code as you perform different Git operations.

+ +

One of the wonderful things about Git is it is immutable. So you're never going to destroy your Git history if you've committed. So one of the rules that I have is just always be committing, never worry about committing. If you've committed, you can always get back to that version. You would have to try very hard to destroy committed code in Git. It's the things that you do when you haven't yet committed the code that are dangerous.

+ +

So commit the code, like you said, Steph, push that up to GitHub, so you have a backup of it. You will have a backup locally as well, and that's a thing that you can come to be more comfortable with. But then, from there, there's actually a lot of room to experiment and play around because there's a ton of safety in the way that Git stores the code. You do have to know how to get at it, and that's the unfortunate and tricky part.

+ +

But I think, again, to sort of summarize, yes, this is confusing. Your feelings are absolutely valid and totally grounded, but it is also knowable, is what I would say. And so, hopefully, there are a couple of breadcrumbs that we've laid there in how you might go about learning about it. But yeah, find a buddy, watch a video or two, and give it a try. This is definitely a thing that you can get there but totally reasonable that your first approximation is this is confusing because it sure is.

+ +

STEPH: I often forget that Git has that local copy of my code, so I'm so glad you mentioned that. And then yeah, I saw when you linked to Vim Conflicted. The diagrams are great. I had not seen these before. So yeah, I highly recommend folks take a look at those because I found those very valuable.

+ +

CHRIS: In that case, it's a white background, but I allowed myself to use some colors in the little images to help differentiate the different pieces. And it's an animated diagram, so it's really a high bar for me. [laughs]

+ +

STEPH: So now the question is, did you go too far? Have you over-optimized? [laughs]

+ +

CHRIS: I'm going to be honest; it was a weird weekend.

+ +

STEPH: [laughs] Well, I don't think you've over-optimized. I do think it's wonderful. And I think this is definitely a reference that I'll keep in mind for folks whenever they're learning about merge conflicts or just want to get more knowledgeable about them. I think these diagrams are fabulous.

+ +

CHRIS: Well, thanks. Yeah, I hope...they frankly were a labor of love, and the course is three and a half hours of me rambling about Git, so hopefully, it's useful to folks. If anything, it was super useful to me because my understanding of Git was deeply crystallized in making that course. But I do hope that it's useful to other folks. And particularly those two videos that I highlighted, I think are the ones that have been most impactful for me in terms of how I think about working with Git and getting comfortable with it.

+ +

STEPH: Do you still receive emails every now and then from people, or maybe they are tweets from people that are like, "Hey, I watched one of your videos and found it really helpful." I feel like I still see that every now and then where people are just commenting on like, they watched some of the content that you created for Upcase a while back, and I think that's really cool. I'm curious if you still see that.

+ +

CHRIS: I do, yeah, from time to time. It is absolutely wonderful whenever I hear that. Again, listener, do not feel the need to send me anything, but it is nice when I get them.

+ +

STEPH: It does seem like I'm fishing for compliments now. [laughs]

+ +

CHRIS: It does seem like that. So I want to be clear that's not what's going on here. But it is nice because I do actually forget that they're out there. But a lot of the stuff that I produced for Upcase, in particular, I tried to do more timeless stuff, so like the Vim content was really about how Vim works in a deep way.

+ +

And the tmux course and the Upcase course...or the tmux course, the Git course. I look back at them, and a couple of little syntactic things have changed. But I'm still like, yeah, I agree with me from six years ago or whatever it was. Oh, that's a weird number to say, and I think is honest. It's fine. I'll just be over here. [laughs]

+ +

STEPH: [laughs] That's helpful to hear, though, because that's always one of my fears in creating content. It's like, I don't know, it's okay if it's more opinionated and I change my mind and disagree with my past self. But it's more like, yeah, keeping up with is this still accurate? Is this still reflective of the times? And then having to keep that stuff updated. Anywho, that's a whole big thing, content creation.

+ +

CHRIS: Content creation, but there's a parallel to it that many folks will not be creating content, and I think that's a very fine and good way to go about progressing on the internet. But there's a parallel to it in learning that I think is useful. I, at this point, will typically lean in if there is something in the SQL layer that is fighting me. I have never found effort spent trying to better understand the structured query language to be wasted time.

+ +

Similarly, Git is one of those tools that is just so core to the workflow that it felt very worth it to me to spend a little bit of extra time to get to a deeper level of comfort with it, and I have not regretted one minute of that. Vim and tmux are pretty similar because they're such core tools for me.

+ +

But React, I would not call myself a deep expert of React. I follow some of the changes that are happening but not as deeply, and I'm not as worried about it. And if I'm like, I don't know how to do this thing, should I spend two hours learning about it or not? With frameworks and tools that have not been part of my toolset for as long, I will spend less time on them.

+ +

And I think that the courses that I produced on Upcase mirror that. They're the things that I'm like; I feel very true about these things versus other stuff. Maybe it was in a weekly iteration episode or something like that. But that very much mirrors how I think about learning as well. What are the things that I'm going to continually invest in versus what are the things that I’ll sort of keep an eye on from a distance but not necessarily invest as much time in?

+ +

STEPH: There's a particular article that you're making me think of as we're talking about content creation and, as you mentioned, finding the things that you always find value in investing in. There's a wonderful blog post that was recently posted on the thoughtbot blog by Matheus Richard, and it's called The Opportunity Will Find You.

+ +

And it made me think a lot about what you're talking about, find the things that you're excited about, find the things that you think are a good investment and just go ahead and lean into it. And it's okay if maybe that's not the thing that you're using currently at your work, but if it's something that gets you excited, then go ahead and pursue that.

+ +

So in this article, for example, Matheus uses the example of learning Rust, and that's something that he's very excited about and wants to learn more about. And then there's another one where he started looking into crafting interpreters. And then that has actually led to then some fruitful work around creating custom RuboCops because then he had more knowledge around how the code is being interpreted so then he could write custom RuboCops.

+ +

So yeah, plus-one to finding the things that give you energy and joy and leaning into that and investing in it. And if you share it with the world, that's fabulous, and if you don't, then keep it for yourself and enjoy it, whatever makes you happy. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris is back from vacation and gives hiring and onboarding updates.

+ +

Steph has an update about the CI slowdown and scaling CI.

+ +

They tackle a listener question regarding having some fear around potential merge conflicts.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

This episode is brought to you by Studio 3T. Try Studio 3T's full suite of features for 30 days, no payment details needed.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Golden roads are golden.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Oh, I also have a new intro that I want to try out. This is thanks to Irmela from Twitter, where it's good morning and hooray; today is Bike Shed day. They technically said Tuesday, but we don't record on Tuesdays. So today is Bike Shed day, so happy Bike Shed day. And hey, Chris, what's new in your world?

+ +

CHRIS: What is new in my world? Yeah, I loved when I saw that tweet come out. It really warmed my heart. So Tuesday, in theory, is Bike Shed day, but for you and I, Friday is Bike Shed day. It's confusing breaking the fourth wall, as I so often do. But yeah, what's new in my world? I'm back from vacation, which is the thing that I did. For listeners, well, I have been absent the previous week related to vacation and all those sorts of things.

+ +

But I did what we're going to describe as a not smart thing. It wasn't intentional. The world just kind of conspired in this way. But I had two separate vacation islands that existed in my mind, and then they both kind of congealed, but as they did that, they moved towards each other, but they didn't connect.

+ +

And so what I ended up with was two weeks back to back where I was out on Thursday and Friday of one week, and then I was back for Monday and Tuesday. And then I was out for Wednesday, Thursday, Friday of the following week. Protip: that's a terrible idea. It's just not enough time to sort of catch up.

+ +

The whole of it was like the ramp-up to vacation and then the noise of vacation, then getting back and being like, oh, there are so many emails. Let me try and catch up on them. But also, on the very positive side, we had a new hire join the team, and so most of my focus on the days that I was in the office was around getting that new person comfortable on the team, onboarding, spending as much time as possible with them.

+ +

And so, all total, it was an adventure. And again, I would strongly recommend against this. The world just kind of conspired, and suddenly these three different forces in my life came together. And this was just the shape of things. But yeah, I went on vacation, and it was great. The vacation part was great.

+ +

STEPH: I will take your advice. So next time I have like two segments of PTO, I'm just going to stitch them together and just go ahead and take that whole intermittent time off.

+ +

CHRIS: That probably would have been better. Again, someone new joining the team, it was very important to me to get some time with them early on, and so I opted not to do that. But yeah, the attempt to catch up in between was a completely lost effort, I would say. But I think I'm mostly caught up now, having been back in the office for about a week, so yeah.

+ +

But let's see, what else has been up in my world? It's actually been a while since you and I have chatted based on the various timing and schedules and the nonsense vacation schedule that I had that you so kindly accommodated across a couple of weeks. Let's see, hiring and onboarding; the hiring went really well. We talked about that a bunch of weeks back. But now we're in the onboarding phase. And so next week will be the first week that all four of us on the engineering team are in the office together for the full week. I'm super excited to experience that.

+ +

We've had different portions of it, with me being on vacation and other folks being on vacation. But now, for the first time, we're really going to feel what it’s like as this team. And we're going to have our first retro as a group and all those sorts of things, so I'm very excited to do that. And thus far, all of the interactions that we've had have been really wonderful as a team. And so now it'll be the first time we're just bringing all of those various pieces together.

+ +

STEPH: I just have to clarify; you said all of y'all in the office together. Do you still mean remotely?

+ +

CHRIS: Oh, yes, yes, I just mean not on vacation, all present and accounted for on the internet. Remote is another interesting facet of what we're doing here and trying to figure out how to navigate that, particularly where there are some folks that are closer and can potentially get together in the city, that sort of thing, and then folks that are truly remote and making sure that we're...I'm very much of the opinion if we have anyone that's remote, we are remote team, and we must embrace async communication and really lean into that.

+ +

And I think the benefits of async communication as its own consideration are so worth it. And it's one of those things that's hard to do. It requires careful, intentional thought. It requires more purposeful communication. But I think there are a lot of good things that fall out of that. It's similar to TDD in that way in my mind, like, it's not easy. It's actually quite difficult. But all the effort that I put into trying to learn how to do that has made me a better developer, I think, on all the various fronts.

+ +

And I think similarly, async communication I believe in as a tool to force just better communication. And so I'm a big believer in it, and I've found a ton of benefit in remote that I'm also a big believer in that now. I, like everyone else, was forced into it as the world was, but I've really come to enjoy it a lot. And so yeah, so, no, not physically in the office, to answer your very short question with a long rambling aside.

+ +

STEPH: [laughs] I like that comparison. I hadn't thought about it in that way but comparing that thoughtfulness and helpfulness of async communication and then also to TDD, where it's not easy, but the payoff is so worth it, the upfront cost of it. That is something that at thoughtbot, we've had conversations around where there are folks that really value...they want to be around people. They get energy from people, and so they want that option to be able to rent a WeWork space and maybe get together with a colleague once or twice a week, and that was supported by thoughtbot.

+ +

But we also wanted to express well, if you are together, do treat everything still as a remote work environment. So let's say if you and your colleagues are on a project, but then there's a third person on that project that's remote, you still need to act like everything's remote to make sure that everyone else is still getting to participate and hear everything and be part of the conversation. So just keeping that in mind that yes, we want to support you doing your best work, and if that's around people, that's wonderful. But we are still remote-first, and communication needs to be in that fashion.

+ +

Well, that's super exciting that you'll have all of the team together. That sounds like it will be wonderful to hear about and then also retros and meetings, and yeah, it sounds like you've got a fun week ahead.

+ +

CHRIS: Indeed. I'm super excited to see what sort of new things come out of the new voices on the team and practices that each of the individuals have experienced at other companies that we can now fold together. The work that we've done so far has been very much inspired by thoughtbot ideas, and approaches, and workflows, and processes because that's what I brought to the table. But I'm super excited to bring in more voices and see what of that 100% stays on versus does anything change? Do we get entirely new things? So yeah, very excited about all of that.

+ +

But to revisit a topic that we've talked about in the past, this week is catching up from vacation, so there's a certain amount that will constrain my work. But this was definitely another week of I did not do much coding. I'm trying to think if I did any coding this week. It's possible that the answer is no. The fact that I don't even know the answer to that is an interesting one. I still have in my mind the desire to get back to it, and I think I will. But there's so much other stuff to do.

+ +

Recently, this week, there's been a lot of vendor selection and contract negotiation, which is an interesting facet of the work, but just trying to figure out, oh, we need platforms to do X, Y, and Z. And it turns out they're wildly costly and have long sales cycles. And how do you go through that, and how do you make sure that we're getting the right thing? And so that's been a big part of my work. Hiring and onboarding, again, has been a big part of it.

+ +

There's also some amount of communicating back to the broader team - what are we doing? What is the product organization or the engineering team delivering? And so I'm okay at presentations, I think. I'm comfortable with giving presentations. The thing that I struggle with is finding the optimization point in preparation. I will, of my own accord, over-prepare. And that may sound a little bit like, oh, what's my greatest weakness? That I care too much.

+ +

But I mean it sincerely as like, I would love to find that right amount of like, it's like an hour of preparation for a 15-minute presentation to the team. That's the right ratio. And I just hit that on the head, and it's great. But whenever I know that I need to give a larger presentation, it will distract me. And it's work that can expand to fill whatever time you give it, and so trying to thread that needle is a tricky one for me.

+ +

STEPH: Yeah, I'm with you. Presentations, for me, they're one of those things that it's very stressful, anxiety-inducing; all the prep feels distracting from some of the other work that I want to do. Or maybe I'm excited about the presentation, and that is the work that I want to do. But it's not until it's done that then I'm like, oh, that was fun. That went well. This was great.

+ +

It's not until after that then I feel good about it. So the lead-up to it is very stressful. And so if you can optimize that to say, well, I know exactly what this group needs, where I can cut corners, where I have to go into details, that sounds incredibly valuable.

+ +

I'm curious, so this is probably a bad idea, but it's the only way I really know how to find those boundaries is you got to experiment and tweak a little bit and let yourself fail a little bit or just be very explicit with folks about this is what the presentation is, if you expected something else, let me know. Or here's what I've got, have someone to bounce ideas off of.

+ +

But there's such a nicety if you can find that I'm going to try failing just a little bit and get some feedback. Or maybe it's not failing at all, but you are testing that boundary to find out did this work, or should I put more effort into this? I'm curious, do you have thoughts on that? How you're going to find that right optimization level?

+ +

CHRIS: Not as specific to truly honing in on whatever the correct number is. The thing that I've been doing is I...this will sound complicated, but I wait until the last minute but a specific version of the last minute. So at most, I start working on it an hour and a half before the meeting. And these are, again, not particularly large presentations, and it's a recurring sort of thing. So it's sort of engineering talking about the work that we've done recently and trying to find the right level of detail and whatnot, so giving myself a smaller time window.

+ +

I think that's enough time to tell the story and to find a meaningful way to tell the story and grab the screenshots and all of that, but it's constrained so that I don't over-optimize, over-edit, overthink. I'm using Deckset, which is a presentation tool that starts from a Markdown file. So it's just a Markdown file that I'm editing. That's great; that works really well. I do not twiddle with fonts. There's one theme that I use. It is white background with black text. That's it.

+ +

And I think I've given myself deep permission to be the CTO that has a white background with black text and no transitions. I don't even go into presentation mode for it. I'm literally showing the UI of Deckset, and then just hitting the arrow to move between them. But the Chrome and the drop-down menu at the top is still visible because I want to see people's faces as I'm presenting. And I haven't figured out how to do that correctly on my computer. So I'm just presenting the window of Deckset.

+ +

And I'm like, I have given myself permission to do all of those things, and that has been super helpful, actually. So that's a version of me negotiating what this means. Where I do invest the effort is trying to enumerate all of the things and then understand what is the story that I'm telling around the things and how do I get the message right for the collective audience? So, for a developer team, I would say much more nuanced technical things, for marketing folks, it would be at this end of the spectrum.

+ +

I do lean on the old idea of, like, let us talk about it in the mindset of the user, so it's very much user-centric, but then some of the things that we're doing are important but invisible to the users. They're part of how we broadly build the platform that we need to, but they're completely invisible to users. And so, how do I then tell that story still with ideally a user-centric point of view? So that's where I do invest the time, and I give myself complete freedom to just grab screenshots, put black text on a white background, and then talk over it.

+ +

STEPH: I love it. Because you made this comparison earlier, so now I'm thinking of a comparison of like TDD-driven presentations where it's like, what's the end goal? What's the assertion? What's the outcome that I want? And then backfilling from there. Or, in your case, you're talking about what's the story that I need to tell? What's the takeaway that I want people to have? So then you start there, and then you figure out what's the supplemental information that you need to provide to then get there.

+ +

And the fact that you don't twiddle with fonts and all that stuff, I think you're already really on your way [chuckles] in terms of finding that right optimization of I need to present a clear and helpful message but not sink too much time into this

+ +

CHRIS: Black text on a white background is very clear. So...

+ +

STEPH: [laughs] If there are any designers listening to this, they might just be cringing to this conversation right now. [laughs]

+ +

CHRIS: I actually wonder about what the...I know that dark mode is a thing that lots of folks care about. I'm thinking about the accessibility affordance of it now. I'm actually thinking through it now that I said it somewhat flippantly. I actually don't know what I'm talking about, but it was easy, and it wasn't a choice that I allowed myself to think about. So there we are.

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: In my personal world, so Tim and I are moving. We're on the move. We are transitioning from South Carolina to North Carolina. So I think I may have shared a bit of this news, but Tim has acquired his first software developer job, which is just phenomenal. It is in North Carolina. He does need to be there in person for it. So we are currently selling our South Carolina house and then moving.

+ +

It's not too far. It's like three and a half hours away to where we're moving in North Carolina because we're already pretty far in North and South Carolina. So yeah, there's always another box that needs to be packed. And there's always just something else that you forget, another thing that you want to take to Goodwill or try to give to a neighbor. It's a good way to purge. I will definitely say that every time you move, it's a good time to get rid of things.

+ +

CHRIS: That is a very cup half-full point of view on it, but yeah, it feels true.

+ +

STEPH: [laughs] It's true. I'm a very cup half-full person. For more technical news, for more client stuff that I've been working on, so I think the last time we chatted, I was sharing that we had this mysterious CI slowdown where we were going from CI builds taking around 25 minutes to spiking to 35, sometimes 45 minutes, and I have an update there. So we found out some really great things, and we have gotten it back down to probably more about 23 minutes is where the CI is running currently.

+ +

As for the actual who done it, like what caused this specific slowdown, we got to a point where we were like, we're doing so much investigative work to understand exactly what caused this that it felt less helpful because at the end of the day, we really just wanted to address the issue. And so solving the mystery of exactly what caused this started to feel less and less meaningful because we're like, well, we want to improve this anyways.

+ +

So even if we found that one line or something that happened that caused this, we want a bigger solution to this type of problem because then this could happen again like, someone else maybe adds one line or something happens, and things get thrown off balance, and then suddenly, we have a slowdown, and that just takes too long to investigate.

+ +

So I don't have a concrete who done it answer for the slowdown. But we've learned a couple of things; one of the things that we learned is we're using parallel_tests to then split our tests across all of the CPUs that are then running the RSpec test. And we realized that we weren't actually splitting tests based on runtime data.

+ +

So there are a couple of ways that parallel_tests will let you divvy up your test, and two of those ways one is file size. So you can split the files based on the size of the file, or you can use info from the runtime log. So then parallel_tests can be a little bit more intelligent about like, well, I know how long these files take, so I'm going to split it based on that versus just the size of the file.

+ +

And we realized that we were defaulting and using the file size instead of the runtime even though we all thought we were using runtime. And the reason for this took a bit of source code diving because looking at the README for parallel_tests; it looked like as long as we're passing in a file to the runtime log path, then parallel_tests is going to use that runtime data. But then there's some sneaky-sneaky in there that I'll actually link to in the show notes in case anybody's interested.

+ +

But if you are setting a particular flag and don't pass in another flag, then parallel_tests is going to be like, cool, I'm going to portion out your test based on file size instead of the runtime. So we fixed that, or we updated that, and that has had a significant improvement for the test being split out more evenly. So we didn't have a CPU that was taking 25 minutes while the next CPU was only taking like 17 minutes. And parallel_tests also provides some really helpful data that because we have that runtime log file, we could tell how long each CPU is running and how they're getting split.

+ +

So the past couple of weeks, it's heavy measure, measure, measure, take all the data, create lots of graphs, understand what's happening, and then look for ways to then fix it. So figuring out how these files or how the tests were being distributed across, we had a number of graphs that were just showing us what's actually happening. So then we could track the improvement, so that was really nice. It was the measure twice and change something once [laughs], and then we got to see the benefit from it.

+ +

For scaling the CI, so we are looking on adding more machines to then process tests. That has been really interesting because we're at the point where we are adding more machines, but if we add more machines, we're not going to speed up how quickly our CI processes everything. Because we are splitting tests based on file size and not by examples, we're always going to have this effect of a tentpole. So if we have a file that takes 10 minutes, that's the fastest we're ever going to get.

+ +

So Joël and I are in discussions right now of where we still really want to understand what's the fastest we can achieve just by adding another machine or two versus are we at the point that, okay, scaling horizontally and adding more machines has been helpful, but we have reached the breaking point where we actually need to divvy out the tests at a smaller scale and have a queue approach? So then that way, we can really harness the power of then we don't have one file that takes 10 minutes, and we don't have to care either.

+ +

So if somebody adds a test to a file and suddenly a file goes from 12 minutes to like...well, hopefully, they added more than one test. [laughs] But let's say it goes from 10 minutes to 15 minutes; we don't want to have to manage that and understand that there's a tentpole. We just want to be able to divvy out all the examples and then have a queue approach.

+ +

That's probably going to be MVP two of this, but we're still waiting that out. But it's just been really interesting to realize that scaling horizontally really only takes you so far. Like, we've added one machine, maybe one more, so then we'll have three total. And then it's like, okay, that's great, but now we need to actually address this other bigger problem.

+ +

CHRIS: I know we've talked about this in previous episodes, but I'm super interested to hear as you progress into the queue approach because that's something that's been top of mind for me for a while. I don't know if we've talked about it before specifically, but Knapsack Pro is the one thing that I'm available as a service that does this. Do you have other tools that you're looking at for that, or is this still in the exploratory phase?

+ +

STEPH: Knapsack is still a top contender. There's also RSpec Queue; that's another one that we have in mind. Unfortunately, I really wish parallel_tests let us do this, but parallel_tests just doesn't quite offer that feature. And someone in the team, I think, even reached out to the maintainer of parallel_tests, and they were like, "Yep, you're totally right. We're actually more focused in making sure that this works for everybody versus has specific features." And they gave a really nice thoughtful response, which we appreciated, so at least we could confirm that parallel_tests won't do exactly the thing that we need. So yeah, RSpec Queue, Knapsack, I think those are the top two that I'm familiar with.

+ +

CHRIS: Gotcha. I don't know if I've seen RSpec Queue before. I'm intrigued. So actually, an interesting thing happened. While I was away on vacation, one of the folks who just joined the team as one of their first steps joining the team, noticed that our CircleCI config wasn't actually taking advantage of the parallelism that we had configured; that's on me. I turned on parallelism and then never did anything with it, which is a complete waste.

+ +

And so I was super happy to come back and saw that CI, which had been creeping up to six or seven minutes, had suddenly dropped back down to two to three minutes sort of thing. I was like, this is amazing. But now I'm at the point where our RSpec suite is spreading across the different, I think, it's like four different cores that we have available, but it's not doing it as efficiently as we would like. So I'm like, oh, okay, can we dial it up to 11?

+ +

But I'm intrigued; I've only looked very much in passing at RSpec Queue literally now that you've mentioned it. But Knapsack Pro exists as a different service. And so, as far as I understand, the agent that's running is going to communicate and say, "Give me another test. Give me another test." But there needs to be some external process running and managing that queue. Does RSpec Queue do that? Somebody owns the queue, right? Who owns it? Do you understand how that works?

+ +

STEPH: So I was definitely familiar with this. If you'd asked me a couple of weeks ago, when I was diving heavily into the queue work before then, we transitioned more into focusing on then adding new machines; I was very up to speed on this. So I may get a couple of things wrong, but my understanding is that RSpec Queue, you're going to manage your own queue. So you bring in the gem and then use something like Redis, so then you are in charge of that.

+ +

And with Knapsack, then you are using their service to manage that queue. And then they have found ways to optimize around what if you can't reach their API or something; their service is down? And making sure that that doesn't impact your CI so then you can't still run your test just because you can't reach their queue somewhere. So that's my current understanding, RSpec Queue you own it, Knapsack they're going to own it.

+ +

CHRIS: Gotcha. That makes sense. That about maps to what I was expecting, and so I wonder if I could use RSpec Queue. Now I'm going to have to go research that. But it's always nice to have new things to look at on this to go at ludicrous speed. That's what I'm going for. I want to get to ludicrous speed for our CI.

+ +

STEPH: I like that name. I haven't heard of that speed. I feel like I have. I feel like you've dropped that before, [laughs] like you've used that.

+ +

CHRIS: I don't know; quite possibly, I have. It's a Spaceball’s reference. It's a throwback to days of old.

+ +

STEPH: Well, then we may be investigating RSpec Queue together. Because yeah, Joël's and I goal for this week has been very much to figure out what's our boundaries with TeamCity? What are our boundaries with horizontal scaling? And I think we're both getting to that conclusion of like, okay, this has been good, it's helpful, but we really need to look into the queue stuff if we really want to see significant progress.

+ +

Also, some of the stuff we're doing because we're pushing on it, we are manually splitting files. So if there's a file that has created this tentpole that's taking 10 minutes, but we know ideally most of the other files only take six minutes, then we are splitting that file, so then we have two spec files that are associated with the same class. And then using that as a way to say, okay, what would this look like? Let's say if this were better balanced.

+ +

And that's also been pushing us in the direction of like, okay, this is fun, this is informative, but it's not sustainable. We don't want to have to keep worrying about splitting these files and doing this manually and pushing us towards that queue-based approach.

+ +

MIDROLL AD:

+ +

And now a quick break to hear from today's sponsor, Studio 3T.

+ +

When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy.

+ +

And now, there's Studio 3T Free, a free edition of Studio 3T which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with Mongo DB, SQL, Oracle and Sybase.

+ +

You can start today by downloading Studio 3T Free, which also includes a 30 day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial head to studio3t dot com forward slash free. That's studio dot com forward slash free.

+ +

But shifting gears just a bit, we have a listener question. So this person wrote in, "I have listened and loved your podcast for many years dreaming of getting a job with people half as thoughtful and intentional as you, and finally it happened. I have my first junior dev job, and my co-workers and bosses are all super awesome. Up until now, I've been flying solo.

+ +

And in my new job, I've been finding it very unsettling to resolve merge conflicts. As careful as I am to comb through the conflict and contact the other developer if needed, I feel like I am covering my eyes and crossing my fingers whenever I select the resolve conflict button. Is there some type of process or checklist I could rely on? Is it normal to have such a high fear factor with a merge conflict? Any advice or maybe just a bit of been there felt that way...?"

+ +

All right. So one, that's fabulous, congratulations on the new job. That's very exciting. I think I've voiced this many times, getting your first junior dev job is so hard, and so I'm so excited when it works out for people, and they get there. And then, for the merge conflict, I have thoughts. Chris, do you want to start? Shall I start? How are you feeling?

+ +

CHRIS: Why don't you start? Well, actually, I'm going to add some pre-commentary, and then I think you should lead into our actual answer. But first, I just want to say a deep thank you to this listener for sending in the question. Again, we really love getting these questions. And also, thank you for the very kind words.

+ +

To be clear, listener, if you're going to send in a question, you don't have to say very kind words, but they are really wonderful to hear and especially to hear if we had any part in helping this person feel more comfortable getting into that first dev role and having an idea of what maybe a good version of that could look like.

+ +

Additionally, I really love the shape of this question because it gets into the people stuff and the tech stuff, so I'm super excited about this question. Actually, both Steph you and I responded very quickly to this one. And so it really did catch our attention because I think it crosses that boundary in an interesting way that I think is sort of The Bike Shed space in the world. But to that end, you did reply first in our email chain. So I think you should start, and then I'll follow on after that.

+ +

STEPH: I should also check with you. Wait, so you don't have a filter on your email that's like kind words only to The Bike Shed, and then you filter out anything that's negative?

+ +

CHRIS: I have a sentiment analysis, and if it's even neutral, it gets sent straight to the trash, only purely positive. No, constructive feedback is welcome too. We would love to hear that. Well, love is a strong word. We would accept it into our inboxes and then deal with it, but yeah.

+ +

STEPH: [laughs] It will be tolerated. Must require at least three hearts in all emails; just kidding. [laughs]

+ +

CHRIS: Are you kidding? I'm counting them now, and I see a lot of hearts in our emails.

+ +

[laughter]

+ +

STEPH: Merge conflicts. So is it normal to have such a high fear factor with a merge conflict? I'm going to say absolutely. Resolving a merge conflict can be really tricky and confusing. And I think; frankly, it's something that comes with just time and practice where then you start to feel more confident.

+ +

As you're resolving these, you're going to feel more comfortable with understanding what's in the branch and the code changes that you're pulling in versus something that you need to keep on your side. So I think over time, that fear will subside. But I do think it's totally normal for that to be a very scary thing that then takes practice to become accustomed to it.

+ +

As for if there is some type of process or checklist, I don't know of a particular checklist, but I do have a couple of ideas. So one of the things that I do is I will often push my code to whatever management system I'm using. So if I'm using GitHub, then I'm going to push up my branch because then, at least that way, someone has a copy of my work.

+ +

So if I do something and I completely botch it locally, I know I can always reset to whatever it is that I pushed up to GitHub, so then that way, I have more freedom to make mistakes and then reset from there. So that is one idea is just put it somewhere that you know is safe, so that way you now have this comfortable sandbox to then make mistakes.

+ +

The other one is run the test. So hopefully, the application that you're working with has tests that you can trust; if not, that could be another conversation. But if they do have tests, then you can run those, and then hopefully, that would let you know that if you have left something in, like maybe you left a syntax error, or maybe you removed some code that you shouldn't have because you weren't sure, then those tests are going to fail, and they'll let you know that something went wrong.

+ +

And you can run those while you're still in the middle of that merge conflict as long as you've addressed like...well, no, if you haven't addressed syntax errors, that's still a time that you can run it, and it's going to let you know that you haven't caught all of the issues yet. So you don't have to wait till you're done to then go ahead and run that.

+ +

A couple of other ideas, practice. So go ahead and create your own merge conflicts on purpose. So this is something that I think is really helpful because it will teach you, one, what causes a merge conflict? Because now you have to figure out how to create one, and then it will help you become comfortable because you're in a completely safe place where you have made up the issue, and now you're having to resolve that, so it'll help you become more confident in reading that merge conflict message.

+ +

And then last but certainly not least, grab a buddy so if you are just feeling super nervous. Anytime I'm doing something that I just feel a little nervous about, then I just ask someone like, "Hey, would you look over my shoulder? Would you pair with me while I do this?" And I have found that's incredibly helpful because it eases some of my fear. I've got someone else that is also looking through this with me. But I also find it really helpful because then it encourages that person to be like, hey, if they're ever in a spot that they need to pair, I want them to know that they can also reach out to me and have that same buddy system.

+ +

I guess that's my checklist. That's the one I would create. How about you, Chris? What do you think?

+ +

CHRIS: Well, first, I just want to say that basically everything you said I 100% agree with, and purposely I think was great that you actually replied to the email first and that you're saying those things first because I think everything that you said is true and is foundational. And it's sort of the approach that I would definitely recommend taking as well.

+ +

My answer, then adding on to that, has to do with how I've approached learning about this space in my own career. To name it, to answer the core question, is it reasonable to be scared of this? Yes, Git is confusing. Git is deeply confusing. I absolutely love Git. I have spent a lot of time trying to understand it, and in understanding it, I've come to love it. But it's only through deep effort that I've gotten to that place. And actually, the interface, the way that we work with Git on a day-to-day basis, particularly the command line is rough.

+ +

I'm going to say, what does Git checkout do? Well, it does just about everything, it turns out. That command just does all of the stuff, and that's too much. It's, frankly, the UI for Git, specifically the command-line user interface; the commands that we run to manipulate the Git history are not super intuitive. But it turns out if you pop open the hood, the object model underneath the core way that Git stores your code is actually very simple. I find it's very easy to understand, but I, unfortunately, have found that I can't understand it without dropping down to that level.

+ +

And so, in my own adventures, I kind of went deep on this topic a couple of years ago, and I created a Vim plugin because obviously, that's the best way to encapsulate your knowledge about Git, and so I created a plugin called Vim Conflicted. I don't necessarily recommend the plugin. It's fine if you want to use it. I don't do a great job of maintaining my plugins at this point, to be honest. But there was a weekend where I was trying to understand the world of Git and merge conflicts in particular, and it was really sort of fighting me.

+ +

And as I started to understand it better, there's a little diagram that I drew on the README that I think is probably the most interesting artifact from it. But it's this idea that there are actually four files, four versions of a given file involved in any merge conflict. And that realization shifted my thinking a good amount. And then as I started to think about that, I was like, oh, okay, and then I want to see this version of it, and this version of it, and this combination, and the diff between these two, and that was super helpful for me.

+ +

More generally, I also made a course on Upcase about Git as I tried to understand it better. And there are two particular videos from the middle of the course named the Git Object Model and Object Model Operations. And again, those two videos deal with popping the hood on Git, looking inside it, and what actually is happening to your code as you perform different Git operations.

+ +

One of the wonderful things about Git is it is immutable. So you're never going to destroy your Git history if you've committed. So one of the rules that I have is just always be committing, never worry about committing. If you've committed, you can always get back to that version. You would have to try very hard to destroy committed code in Git. It's the things that you do when you haven't yet committed the code that are dangerous.

+ +

So commit the code, like you said, Steph, push that up to GitHub, so you have a backup of it. You will have a backup locally as well, and that's a thing that you can come to be more comfortable with. But then, from there, there's actually a lot of room to experiment and play around because there's a ton of safety in the way that Git stores the code. You do have to know how to get at it, and that's the unfortunate and tricky part.

+ +

But I think, again, to sort of summarize, yes, this is confusing. Your feelings are absolutely valid and totally grounded, but it is also knowable, is what I would say. And so, hopefully, there are a couple of breadcrumbs that we've laid there in how you might go about learning about it. But yeah, find a buddy, watch a video or two, and give it a try. This is definitely a thing that you can get there but totally reasonable that your first approximation is this is confusing because it sure is.

+ +

STEPH: I often forget that Git has that local copy of my code, so I'm so glad you mentioned that. And then yeah, I saw when you linked to Vim Conflicted. The diagrams are great. I had not seen these before. So yeah, I highly recommend folks take a look at those because I found those very valuable.

+ +

CHRIS: In that case, it's a white background, but I allowed myself to use some colors in the little images to help differentiate the different pieces. And it's an animated diagram, so it's really a high bar for me. [laughs]

+ +

STEPH: So now the question is, did you go too far? Have you over-optimized? [laughs]

+ +

CHRIS: I'm going to be honest; it was a weird weekend.

+ +

STEPH: [laughs] Well, I don't think you've over-optimized. I do think it's wonderful. And I think this is definitely a reference that I'll keep in mind for folks whenever they're learning about merge conflicts or just want to get more knowledgeable about them. I think these diagrams are fabulous.

+ +

CHRIS: Well, thanks. Yeah, I hope...they frankly were a labor of love, and the course is three and a half hours of me rambling about Git, so hopefully, it's useful to folks. If anything, it was super useful to me because my understanding of Git was deeply crystallized in making that course. But I do hope that it's useful to other folks. And particularly those two videos that I highlighted, I think are the ones that have been most impactful for me in terms of how I think about working with Git and getting comfortable with it.

+ +

STEPH: Do you still receive emails every now and then from people, or maybe they are tweets from people that are like, "Hey, I watched one of your videos and found it really helpful." I feel like I still see that every now and then where people are just commenting on like, they watched some of the content that you created for Upcase a while back, and I think that's really cool. I'm curious if you still see that.

+ +

CHRIS: I do, yeah, from time to time. It is absolutely wonderful whenever I hear that. Again, listener, do not feel the need to send me anything, but it is nice when I get them.

+ +

STEPH: It does seem like I'm fishing for compliments now. [laughs]

+ +

CHRIS: It does seem like that. So I want to be clear that's not what's going on here. But it is nice because I do actually forget that they're out there. But a lot of the stuff that I produced for Upcase, in particular, I tried to do more timeless stuff, so like the Vim content was really about how Vim works in a deep way.

+ +

And the tmux course and the Upcase course...or the tmux course, the Git course. I look back at them, and a couple of little syntactic things have changed. But I'm still like, yeah, I agree with me from six years ago or whatever it was. Oh, that's a weird number to say, and I think is honest. It's fine. I'll just be over here. [laughs]

+ +

STEPH: [laughs] That's helpful to hear, though, because that's always one of my fears in creating content. It's like, I don't know, it's okay if it's more opinionated and I change my mind and disagree with my past self. But it's more like, yeah, keeping up with is this still accurate? Is this still reflective of the times? And then having to keep that stuff updated. Anywho, that's a whole big thing, content creation.

+ +

CHRIS: Content creation, but there's a parallel to it that many folks will not be creating content, and I think that's a very fine and good way to go about progressing on the internet. But there's a parallel to it in learning that I think is useful. I, at this point, will typically lean in if there is something in the SQL layer that is fighting me. I have never found effort spent trying to better understand the structured query language to be wasted time.

+ +

Similarly, Git is one of those tools that is just so core to the workflow that it felt very worth it to me to spend a little bit of extra time to get to a deeper level of comfort with it, and I have not regretted one minute of that. Vim and tmux are pretty similar because they're such core tools for me.

+ +

But React, I would not call myself a deep expert of React. I follow some of the changes that are happening but not as deeply, and I'm not as worried about it. And if I'm like, I don't know how to do this thing, should I spend two hours learning about it or not? With frameworks and tools that have not been part of my toolset for as long, I will spend less time on them.

+ +

And I think that the courses that I produced on Upcase mirror that. They're the things that I'm like; I feel very true about these things versus other stuff. Maybe it was in a weekly iteration episode or something like that. But that very much mirrors how I think about learning as well. What are the things that I'm going to continually invest in versus what are the things that I’ll sort of keep an eye on from a distance but not necessarily invest as much time in?

+ +

STEPH: There's a particular article that you're making me think of as we're talking about content creation and, as you mentioned, finding the things that you always find value in investing in. There's a wonderful blog post that was recently posted on the thoughtbot blog by Matheus Richard, and it's called The Opportunity Will Find You.

+ +

And it made me think a lot about what you're talking about, find the things that you're excited about, find the things that you think are a good investment and just go ahead and lean into it. And it's okay if maybe that's not the thing that you're using currently at your work, but if it's something that gets you excited, then go ahead and pursue that.

+ +

So in this article, for example, Matheus uses the example of learning Rust, and that's something that he's very excited about and wants to learn more about. And then there's another one where he started looking into crafting interpreters. And then that has actually led to then some fruitful work around creating custom RuboCops because then he had more knowledge around how the code is being interpreted so then he could write custom RuboCops.

+ +

So yeah, plus-one to finding the things that give you energy and joy and leaning into that and investing in it. And if you share it with the world, that's fabulous, and if you don't, then keep it for yourself and enjoy it, whatever makes you happy. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+tU3j-BOO + + ]]> + + Chris Toomey + Steph Viccari + + + 331: Git Down + https://bikeshed.thoughtbot.com/331 + caa0ff47-aadd-476d-a335-9b1d129cc5df + Tue, 22 Mar 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph celebrates Utah's adoption day and Daylight Savings Time and troubleshoots a CI build time that had suddenly spiked for a client project using TeamCity. She also shares a minor update regarding the work that thoughtbot is doing to scale horizontally and add more machines quickly and efficiently to process more RSpec tests. + +Chris was alarmed by logs and unknown-unknowns and had some fun using Git down. Git bless his heart! + 29:28 + no + + + Steph celebrates Utah's adoption day and Daylight Savings Time and troubleshoots a CI build time that had suddenly spiked for a client project using TeamCity. She also shares a minor update regarding the work that thoughtbot is doing to scale horizontally and add more machines quickly and efficiently to process more RSpec tests. +Chris was alarmed by logs and unknown-unknowns and had some fun using Git down. Git bless his heart! +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +TeamCity (https://www.jetbrains.com/teamcity/) +lograge (https://github.com/roidrage/lograge) +Cleaning up local git branches deleted on a remote (https://www.erikschierboom.com/2020/02/17/cleaning-up-local-git-branches-deleted-on-a-remote/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. Today is Utah's adoption day. So officially, one year ago, we adopted Utah. He's about a year and a half years old now because we got him when he was around the six-month mark. So Utah, aka Raptor, which is the nickname that you gave him, and aka UD [spelling] the cutie is his other nickname...which I've forgotten, why do you call him Raptor? Why is that a name? +CHRIS: Because there's a Utah Raptor. +STEPH: A person? [laughs] +CHRIS: No, I think it was like the fossils were found in Utah. But the Utah Raptor is a type of dinosaur. And so when I heard Utah, my brain went to Raptor, and then I dropped the Utah sort of a Cockney rhyming slang sort of thing. Shout out to Matt Sumner real quick. But yeah, Raptor. +STEPH: Cool. Cool. Cool. I'm so glad I asked. Now I know. I just accepted it when you called him Raptor. I was like, sure, he can be a Raptor. [laughs] +CHRIS: I feel like that says a lot about me that you were just like, okay, why not? +STEPH: [laughs] +CHRIS: That's different and has no apparent connection to the actual name of the creature, but that's fine. I might be a nonsense person. +STEPH: Or me for accepting it. You share a lot of nonsense, and I accept a lot of nonsense. That might be our dynamic. [laughs] So it works out. +CHRIS: That just may be our dynamic. +STEPH: That's why I'm always so nice with the good idea, bad idea, or even terrible. [laughs] +CHRIS: You're like, it's all nonsense 100% of the time, but yeah. So Utah is one year into living with you folks. So that's lovely. +STEPH: Yeah, and he's growing up so well. Oh, and I've been training him for one of his latest tricks. I'm very excited because it seems to be really sinking in. So every night, we take him out for his final bathroom potty but then before we go to bed. And one night, for some reason, I started singing The Final Countdown. [singing] It's the final countdown. But I started singing it's the final potty instead. +So now, when it's time to go out for the bathroom late at night, I look at him, and I start singing. And I start singing [vocalization], and it's working. He's starting to recognize that when I started singing that tune, he's like, okay, and he gets up from his comfy spot, and we go outside. And it brings me a lot of joy. +CHRIS: That is perhaps the best use of Pavlovian conditioning that I've ever heard of. Also, I really appreciate that you both mentioned the final countdown but then said just in case anyone is unfamiliar with the tune, let me hum a few bars. Thank you for doing the service there. +STEPH: I have been singing so much this week. I don't know if Joël Quenneville, who I've been pairing with a lot, appreciates that. Sorry, Joël. But I have been singing so much. And I think that's post-vacation vibes. That's what vacation does for you. And it helps you get back into, you know, lots of singing or at least it does for me. +Let's see, what else is going on this week? So this is the week that we have DST in the USA, so Daylight Savings Time, aka summertime, where we advance our clocks so everybody...although this is going to be late. So at this point, by the time people are hearing this, you're going to have already dealt with all those bugs that have crept up. But those are creeping up this week, where people are starting to notice a lot of those flaky specs that aren't technically flaky. They're actually breaking for real reasons because they were tested in a way that shows that they're not considering that daytime boundary. +CHRIS: It's as if you spend some of your time fixing flaky specs that that's where your mind goes with DST. Because I'm going, to be honest, part of what you're doing right now is telling me that this is coming up, and I didn't know. I had forgotten about that, which is very exciting, except you lose an hour asleep for this one, right? Or is it that you gain? +STEPH: We're going forward. Yeah, it's fall back and then spring forward. That's how I remember it. +CHRIS: Worth it. I'll take the sunshine at night. +STEPH: Yeah, it's supposed to be so we have more sunshine during the daylight hours. That's the reasoning for the nonsense, the headaches. On some more technical news, when I came back from vacation, we noticed that the CI build time has suddenly spiked for the client project where previously we were averaging, I'd say, around 25-26 minutes. There's definitely a range there. But that seems to be pretty consistent. +And right now, builds are taking more about 35, sometimes upwards to 45 minutes. And so it's been a bit of who done it or what caused it adventure of figuring out why, what's causing the spike. And so Joël and I have been pairing heavily on that to investigate what's going on and learned a lot of features that TeamCity offers and just diving into this particular issue. +One thing that brought me joy is by looking through all the builds that are taking place on TeamCity. As I noticed, there are a number of builds that are using the RSpec selective testing that I added where if you only change a test to then we're only going to run those tests instead of the whole suite. And it was one of those changes where I thought, okay, maybe someone's going to get use out of this. Joël and I will probably get use out of this. But I'm actually seeing it about one every ten build something like that. And I'm just like, oh, this is awesome. +One, people are improving tests. That's amazing. And then two, that then they're benefiting especially while we have this spike going on. So that was a suggestion from you that I appreciate because that is paying dividends. And so that brought me a lot of joy while looking into this other issue, which we haven't resolved yet. We think it has something to do with how the tests are being balanced across all the different parallelized processes. And we think that there is an imbalance that has happened. And then that's what's really throwing things off. +So we can see that one particular process is taking around 26-27 minutes, but then the next process that's highest in time is only taking 17 minutes. So it's like, why is there suddenly ten more minutes that's being attributed to one process? And why is that not getting spread out? So still looking into that. That's the mystery for this week. But that's mostly what's going on in my world. What's up in your world? +CHRIS: What is up in my world? I'm going to say a quite alarming thing happened this week, which was we were investigating some changes, or we were investigating some behavior where the particular portion of the system ended up in the logs, just sort of combing through. And I happened to notice this one log line that...our logs tend to be somewhat verbose. They're JSON-structured log format. I've talked about the lograge setup that we use in the past, but there's a bunch. These are long lines of JSON-structured data. +But this line that caught my eye was not. It was just some text, and it said, "Unreported event: and then some other texts." And I was like, ah, what? Who didn't report which to when? I did some digging, eventually figured out that this was Sentry. Sentry was logging that it had not reported an event to us. But had we not randomly happened upon this in the logs, which is sort of a random thing to see, we would have missed this, which is scary. I mean, it was missed for a little while. And so Sentry was not reporting certain events. +We had made a change, particularly to Sentry's before_send configuration. So there's a way that you can do some amount of filtering client-side or client being, in this case, our Ruby app. So that's like the client-side of Sentry, and then there's their server backend. So that would, weirdly, that's the way the client-server work in this case. +But the idea is you can do some proactive filtering of being like, you know what? Rather than sending a ton of noise...because we know there's this one error that we can't stop for reasons. It's a JavaScript Chrome extension that's getting embedded in the app. That doesn't mean anything; that's just noise. Rather than even sending those over to Sentry, let's proactively filter them out. before_send is a function within the Sentry SDK that allows you to do this. +But it turns out if you raise an error in there, if you happen to have introduced something that doesn't cover all the possible edge cases, then Sentry will just not let you know and will log, interestingly, that they did not report the event. I'm going to throw it out there that I would love if Sentry were to say Sentry me...that's where I put something very bad happened, and you should look at it. +And they're just like, well, something pretty darn bad happened. We'll log it. Supposedly, my understanding is before_send can be used to filter out like PII or other things like that. And so their failure mode is quiet intentionally. That's my understanding as to maybe why this is true. I wish there were configuration that said, no, please fail as loudly as humanly possible. But that was terrifying. +STEPH: Yeah, absolutely. I'm going to piggyback on what you just said for a minute because I was also thinking earlier and related to the sudden spike in our CI builds where I was like, it would be really nice if there's...because I suspect there's one particular change that has caused this to happen. I don't know what it is yet, but that's just my suspicion. And it would be great if when that build ran, let's say that build went from an average of 25 minutes and suddenly we have a build that took 35 minutes if TeamCity had alerted us or if something more aggressive had to happen to say like, "Hey, your team..." or maybe it's just in the logs somewhere. +Okay, not in the logs somewhere more visible on the build where it's like, "Hey, your build took an extra 10 minutes compared to the average, just letting you know. I don't have a diagnosis for you, but we're just letting you know." So yeah, plus-one to getting those types of alerts out to people and notifying us when there's an average that's not being met or when things aren't getting logged like you'd expect them to. +CHRIS: As part of what we were doing in the logs...like how to get to that anomaly detection place is a really interesting question in my mind. And this is a case where we were in the logs, and we wanted to instrument more things. So we have a bunch of stuff right now that goes in. It's either a warn or error log level. And the error should be pretty rare because, ideally, those are going to Sentry instead, but we still want to keep an eye on them. +But we introduced a new search within log entries, which is what we're using for logging aggregation and searching. And the idea was to group all warn-level messages and to group it on the message string. So ideally, what this allows us to do is say, "Oh, we've seen 200 instances in the past two days of this new warning that we didn't see before." The difficulty is, as a human, I would see unhandled error blah as one bucket of warning, or I might want to see it that way. I might want to group it on part of the message. So it becomes really hard to find the signal in the noise on these, but at least it was a start. +We now have this little graph for both warning and error-level log messages that we can see are there any new anomalies that are occurring pretty regularly? But this, again, was just this weird edge case where we were lucky to catch it. But it was very scary that it was just throwing stuff away. So the universe might have been true that our error log did get a little quiet for a little while, which was nice, but it wasn't 100%. It wasn't like we were at 10 hours, an hour, and then we went to zero. It was like some, and then we went to a lower number because we were still getting some. We were only filtering out certain ones. +But yeah, it's how do you know at runtime that the system is doing the thing? This is increasingly the question that I have in my mind. But yeah, so that was the thing. We fixed it. It's fixed now. I also set up an alert in log entries to say, "If you ever see this particular phrase again unhandled or unreported," then please tell me about that post-haste. So we've got that now. +STEPH: That's perfect. That's what I was about to ask us if there's a way that you could add a filter or add a warning for that anomaly detection. So that sounds great. +CHRIS: I've got that now because this became a known-unknown, but there are still the unknown-unknowns, and there are so many of them. And I can't know them is my understanding of how they work. I would love to know them. I would love to pin them down and be like, "Hey, what are you doing here?" Someday maybe. But anyway, that was the thing in my world. [laughs] It was fun. It was a great little time. What else is up in your world? +STEPH: I feel like you can always judge the level of fun based on how high someone's voice goes. No, it was fun. It was great. It was fun. +[laughter] +CHRIS: I believe that is an accurate assessment, yes. +STEPH: I've caught myself doing that. I'm like, my voice is extra high, so I don't think I really mean that when I'm using the word fun. [laughs] +Mid-roll Ad +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +I do have a small update that I can share regarding the work that we're doing to be able to scale horizontally. So we want to be able to add more machines quickly and easily so we can then process more RSpec tests. And we have discovered with TeamCity that we're pushing forward on that particular path because they have something called a composite build. And with a composite build, it's essentially your parent or your supervisor build. And then, from there, you can create other subsequent builds. +So we can then say, all right, let's have multiple builds that then run the RSpec test, and then we can separate in that way. And right now, we're going about it in the hacky way because we just want a proof of concept. So we are saying specifically in this particular step, we want you to run spec models. And in this other process, we want you to run these particular tests just because we want to see how this works. And so far, the aggregation seemed great. +So when you look at that composite parent build, it's showing you how each of those builds are doing. It's also reporting back the failures. It's even de-duping them. Because initially, we set it up where we were running the full test suite in parallel on both of these builds, [laughs] not what we wanted, fixed that. But it did highlight that it was de-duping the test failures. So that part was nice. +So the UI seems great and seems quite very capable of doing this. Composite build seems to be the way that we can do this with TeamCity. But we're still diving into actually getting the metrics like, okay, how much is this actually going to speed us up? And what does this look like if we want to be able to scale up to say from 5 to 10 where we went from 5 machines to 10 machines? And that part doesn't feel graceful because then you have to go in and change the configuration and copy the configuration to then add a new build that then is going to process RSpec test. +So other services like Buildkite make it very easy. I can't remember if it's like literally a slider or if it's a number that you enter. But you can say, "This is how many processes that I want to run," in which it would be a lot nicer for that actual scaling. Versus TeamCity, it feels far more manual and intentional where you then have to duplicate and add those settings. But it's a really good first step because, as we'd highlighted before, there's a lot of risk in moving over from an existing infrastructure to something totally new. +So if we can have some wins with this approach and help out the team and reduce build time, then that gives us more grace period. So then we can assess, okay, do we really want to move over to Buildkite? What do we want to do next? What does this look like? And have further discussions. So that's a small update there. Next time I should have some more updates around actual data on how things are looking. +CHRIS: Oh, cool. Yeah, I appreciate the update and definitely interested to hear how this continues to play out. This is a large project that you're undertaking and all the facets and whatnot, so yeah, super interested to hear the continued journey of the test build time reduction. Let's see, other news in my world. I've been exploring something that I'm intrigued by the idea. Let's go with that. [chuckles] That's going to be my start. I always start with these lead-ins that build things up too much. +But I am finding a small tension in trying to just keep up with what the team is doing, which is a wonderful place to be. Our team is growing. We actually have someone new joining tomorrow, very exciting. But I'm trying to find the right version of I don't want to block things. I don't want all code review to have to go through me. But I do want to keep an eye on everything. I want to kind of know what we're doing collectively. +And ideally, mostly, that's me being like, yep, that makes sense. We're doing that. I remember that, cool. Wait, what's this? And rarely, occasionally, there'll be a point where I'm like, oh, I want to intervene here. I want to have a conversation. I want to rethink how we're building this. And so it's moving from a place of any sort of blocking synchronous review or the necessity for that to ad hoc post-review sort of thing. And so the way that I'm trying to poke around with this, of course, I'm writing some code to do it because of me. +So the two systems that we're using that seem most of interest are GitHub and Trello. And so it turns out GitHub has a wonderful search, and I can create a search that is parameterized like create a URL that jumps into a parameterized search saying, "Show me everything that was merged in the past X amount of time, " so I can say the past two days because I haven't checked it in two days. So I'll see all of the PRs that were merged, and some of them I'll have already reviewed. So I maybe could even filter further there. But for anything that I haven't seen, I'm like, oh, what was this? What was that? What was this other change? +Similarly, on Trello, there's a way via the API to get all of the card update actions. And then I can filter down to say whenever a card was moved, which in our system that means...we're doing Kanban-style, so a card being moved from this column to that column that tells me that someone is progressing forward with some work. And then I can further filter down because, again, I don't really want to be blocking on this. I'm most interested in what have we done or completed in the most recent timeframe. +And thus far, it's an interesting data set. And it's an interesting way to switch the problem around such that I'm not feeling...there was FOMO or organizational FOMO is perhaps how I would describe it of like, I want to try and keep an eye on stuff and make sure I'm responsive. But I'm now blocking, so I have to step away. But now I'm worried that I'm missing things. And so I'm trying to find that good middle spot. And this feels like an interesting exploration of that. +STEPH: I'm intrigued when you mentioned the card moving over, so then you can tell things are progressing. And then you're answering the question of what did we do in this particular chunk of time? When you move stuff over, is there a clear sweep of we have finished this sprint, and then you have the date of that sprint at the top, and so then you essentially have a column that represents all the work that was done in that sprint? Is that an approach that you're using? Because that's the one that immediately came to mind for me when you're wondering what was accomplished during this week or two-week period? +CHRIS: Interesting question. So we're not really doing sprints, or there are no real iterations. We're doing more of the I think Kanban is the way to describe it. But basically, we have a prioritized next up column. And then every day, I can say continuously, the work has the same shape, which is pick up the next most important thing, work on it, move it through the various columns. +I did introduce in Trello just the idea of, like, here's a month, so we can see by month what we're doing, but that's too low granularity in my mind. I want to review it a month at a time. The whole point of this in my mind is to see stuff as it's happening vaguely in real-time but not requiring me to constantly be monitoring everything. So it gives me an opportunity at the end of the day to be like, what happened today? What do we do? But yeah, so there's no real sprint that I would couple this to because we're not really doing sprints. +STEPH: Got it. Yeah, that gives me more context. I understand why you're then looking for ways as to how to answer that question of, like, what did we accomplish in this week or a particular time period? +CHRIS: And to name it, this is not an intention on my part to be like, I need to control everything. I need to make all the decisions. I very much want to empower the team. And in my mind, this is actually a mechanism to empower the team. I want to give them more freedom and then have the opportunity occasionally to check back in and be like, oh, actually, there was some context that was missing here the way we did this. Let's actually unwind that, do it this other way for these reasons. But it gives me the ability to potentially have that conversation after the fact. +We're trying very hard to have the tickets be as representative and complete, and well documented as possible. But that's very difficult to get to. And there are also things that I don't even know to mention. Again, I think the critical bit is this is not an attempt to make sure everything aligns with what I think; it's more I want to empower the team to move without me most of the time. And then, where there are things that potentially should have a small conversation or a redirection, then we have the ability to do that. And so, I'm trying to build that back into my workflow while basically loosening up my connection to the work in progress at any given point in time. +STEPH: So you just touched on a topic that's really interesting to me or a particular space. You're doing a very kind thing where you want tickets to have lots of context so that people feel confident when they're picking up what's the action item to be done. And for someone that's new, that's incredibly helpful, and I think more important since they are new to that world. +But in general, my spicy take of the moment is going to be as developers; that's part of our job. If we notice that context is missing or if we're not clear about the action item, is to think through what is it that I'm missing? Who do I reach out to? Who can I go to for help? How can I scope this work? All of that, to me, is very much part of our role. +And the idea that tickets always have to be perfectly curated, which I don't think you're saying, but you're just trying to be extra helpful. But if someone were to have that expectation, I think that expectation is wrong. And I do think it is part of our work that then we help make sure that tickets are well-scoped and well-defined and have those conversations with the people creating the tickets or creating them ourselves. +CHRIS: I love the clarification there, and I'm definitely in agreement with you. I don't know how picante of a take it is. I would be intrigued. Listeners, let us know. Are we breaking your mold of what things should be? But I do like the idea that it is a conversation so back and forth. And so the idea that as developers, there should just be this very clear list of things to do and you just kind of pick up a card and heads down, just get it done, I don't think that should be the mold. +But I do think; ideally, the why is the most important thing that I think should be in a card. So ideally, a card should have little in terms of technical implementation notes and should have more in terms of here's the goal that we're going for, here's the problem, or here's the thing that we're trying to solve. And then maybe a suggestion of like, I think it could be an X, Y, and Z, but I'm not sure. Or we want to be able to send transactional emails, but I don't know any more than that. +Our goal is to engage users. Like that last sentence, that last little bit of our goal is to engage users is a critical, critical data point, versus our goal is to solve for a regulatory and compliance issue. It's like, well, those are different. And they will lead to different solutions and different implementations and all that. +So yeah, I definitely share the idea that cards don't need to be perfectly specified. And if anything, I think I'm closer to that than it probably sounded like I was. But for that reason, it's totally possible in my mind, that work will be done in a way that after the fact, I'm like, "Oh, sorry, there was a misunderstanding here. Let's revisit this work." +And so, my goal is to try and stay connected and have a feedback mechanism at the end of the process. So when the work is done, be able to spot-check it rather than trying to have to watch it as it's happening or proactively define everything in excruciating detail such that exactly the right things happen all the time. So I'm moving to a place of ask forgiveness, not permission. That's the wrong analogy here. But that idea of like, we can clean it up after the fact, that's fine. And we don't need to try and prevent any sort of things, or at least that's what I'm exploring. +STEPH: Yeah, I love that you highlighted having the why. I adore that when that's on a card just because I then I want to know the goal because then that's going to help me ask questions and think about scoping versus if it's like a very specific implementation, then I feel so narrowly scoped that I don't feel as confident that I can be like, okay, I know why I'm doing this versus I just feel very directed to do a thing, and that's incredibly helpful. +I have also felt the pain that you're mentioning where it does feel like a ticket has all of the work clearly defined, and the goals, and the whys, and it can have everything there, but just something gets lost in the communication. And so someone implements something in a way that is how they interpreted the work versus it's not actually what the ticket or what the goal of the work was to be done. +So I appreciate that where you are looking for ways to tweak things to make sure that whoever is picking up that ticket will have the same interpretation that the author intended for them to have. And then if that does happen, and things get misaligned, then you chat and figure out ways to improve it. +I think that's the point that I was really thinking about, and my air quotes, "hot take," is that as developers, a big part of our job is communication, and then also sharing the knowledge that we have with other people. And so if someone is expecting that they can just always pick up work and never talk to someone, I don't know, maybe you're in the wrong business. [laughs] That's my hot take. +CHRIS: I, for one, like the hot take. It is nice and ever so slightly spicy. +STEPH: Thanks. Yeah, I just think communication is incredibly important. Earlier, you mentioned, I don't think we were on mic at the moment, but you mentioned something about a new Git alias. And I am very intrigued on hearing about what you've added, what it does, all the details. +CHRIS: All the details, that's probably too many, but some of the details I can certainly provide. So I have two new Git aliases; one is Git gone, which is probably the heart of the whole thing. And so the background of this is I found myself pushing the green merge button on GitHub more. We've introduced some branch protection stuff, which I've talked about in previous episodes. And I dream of the day that one of my good, good friends at GitHub will give me access to the merge queue beta. Please, please, I implore thee. But in the interim, still clicking the green merge button more often than not. +STEPH: Wait. I have to ask to help you in this dream. Are you forwarding these episodes to someone? You can just take a clip of you saying, "Please, please, please give me access," [chuckles] and just forwarding that or mentioning someone at GitHub or GitHub in general. +CHRIS: Just leaving voicemails for people with a Bike Shed section of me begging for access to the merge queue beta? +STEPH: Yeah. [laughs] +CHRIS: No, I'm not. But maybe I need to up my game. You're right. [laughs] Someday, I'll get there. And that will only exacerbate this issue that I'm feeling, which is again, I'm clicking the merge button. That's what's happening. And as a result, that means my local branch is now like it's done its job. You've served me well. And in the Marie Kondo sense, I need to hold you up, thank you for your service, and then let you go. But I obviously wanted to automate that. +So Git gone does that automation, and it was fun. So I found a blog post which we'll include in the show notes, that had most of the pieces here, but it was still fun to play with the shell pipeline in a way that I hadn't in a while. So it does a Git fetch and then git-for-each-ref with a particular structured format that references the upstream of the branch then uses awk to search for the word gone. +Because Git, if you print it out in this particular way using this format, it will say the local branch name and then the upstream. But if you've deleted the upstream, it will specifically say (gone) in brackets, so you can actually use that to filter them down. And then I pipe that to git branch-D so..well, xargs of course. I love a little shell pipeline. As an aside, these are fun little things to build up. So that is Git gone. +And then the other one that I have is Git down, which is what I use more. And Git down works on top of Git gone, so it's Git checkout main and and Git pull and and Git gone. But that means I get to type Git down into my terminal whenever a branch happens to get merged in the upstream land. [laughs] +STEPH: [laughs] Oh, that's adorable. I love it. I like the Git gone, and yeah, I like the Git down just for fun. You are inspiring me where I now really want a Git bless your heart that's like maybe a Git blame or a Git revert. [laughs] +CHRIS: I've definitely seen people do Git praise as an alias for Git blame. +STEPH: That's nice. +CHRIS: But Git bless your heart is...ooh, I love that. +STEPH: [laughs] I might have to add that just so I can type it, and then someone can say, "What are you doing?" [laughs] Cool, I love it. +CHRIS: Little things, little fun bits to add to your day and to automate and have a little fun while you're at it. So that's where I'm at. +STEPH: All about the communication and fun. That's what I'm here for and the singing. Let's not forget the singing. +CHRIS: And the singing, of course. +STEPH: [singing] On that note, shall we wrap up? +CHRIS: Let's shall. Oh. +STEPH: [laughs] +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Bye. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph celebrates Utah's adoption day and Daylight Savings Time and troubleshoots a CI build time that had suddenly spiked for a client project using TeamCity. She also shares a minor update regarding the work that thoughtbot is doing to scale horizontally and add more machines quickly and efficiently to process more RSpec tests.

+ +

Chris was alarmed by logs and unknown-unknowns and had some fun using Git down. Git bless his heart!

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Today is Utah's adoption day. So officially, one year ago, we adopted Utah. He's about a year and a half years old now because we got him when he was around the six-month mark. So Utah, aka Raptor, which is the nickname that you gave him, and aka UD [spelling] the cutie is his other nickname...which I've forgotten, why do you call him Raptor? Why is that a name?

+ +

CHRIS: Because there's a Utah Raptor.

+ +

STEPH: A person? [laughs]

+ +

CHRIS: No, I think it was like the fossils were found in Utah. But the Utah Raptor is a type of dinosaur. And so when I heard Utah, my brain went to Raptor, and then I dropped the Utah sort of a Cockney rhyming slang sort of thing. Shout out to Matt Sumner real quick. But yeah, Raptor.

+ +

STEPH: Cool. Cool. Cool. I'm so glad I asked. Now I know. I just accepted it when you called him Raptor. I was like, sure, he can be a Raptor. [laughs]

+ +

CHRIS: I feel like that says a lot about me that you were just like, okay, why not?

+ +

STEPH: [laughs]

+ +

CHRIS: That's different and has no apparent connection to the actual name of the creature, but that's fine. I might be a nonsense person.

+ +

STEPH: Or me for accepting it. You share a lot of nonsense, and I accept a lot of nonsense. That might be our dynamic. [laughs] So it works out.

+ +

CHRIS: That just may be our dynamic.

+ +

STEPH: That's why I'm always so nice with the good idea, bad idea, or even terrible. [laughs]

+ +

CHRIS: You're like, it's all nonsense 100% of the time, but yeah. So Utah is one year into living with you folks. So that's lovely.

+ +

STEPH: Yeah, and he's growing up so well. Oh, and I've been training him for one of his latest tricks. I'm very excited because it seems to be really sinking in. So every night, we take him out for his final bathroom potty but then before we go to bed. And one night, for some reason, I started singing The Final Countdown. [singing] It's the final countdown. But I started singing it's the final potty instead.

+ +

So now, when it's time to go out for the bathroom late at night, I look at him, and I start singing. And I start singing [vocalization], and it's working. He's starting to recognize that when I started singing that tune, he's like, okay, and he gets up from his comfy spot, and we go outside. And it brings me a lot of joy.

+ +

CHRIS: That is perhaps the best use of Pavlovian conditioning that I've ever heard of. Also, I really appreciate that you both mentioned the final countdown but then said just in case anyone is unfamiliar with the tune, let me hum a few bars. Thank you for doing the service there.

+ +

STEPH: I have been singing so much this week. I don't know if Joël Quenneville, who I've been pairing with a lot, appreciates that. Sorry, Joël. But I have been singing so much. And I think that's post-vacation vibes. That's what vacation does for you. And it helps you get back into, you know, lots of singing or at least it does for me.

+ +

Let's see, what else is going on this week? So this is the week that we have DST in the USA, so Daylight Savings Time, aka summertime, where we advance our clocks so everybody...although this is going to be late. So at this point, by the time people are hearing this, you're going to have already dealt with all those bugs that have crept up. But those are creeping up this week, where people are starting to notice a lot of those flaky specs that aren't technically flaky. They're actually breaking for real reasons because they were tested in a way that shows that they're not considering that daytime boundary.

+ +

CHRIS: It's as if you spend some of your time fixing flaky specs that that's where your mind goes with DST. Because I'm going, to be honest, part of what you're doing right now is telling me that this is coming up, and I didn't know. I had forgotten about that, which is very exciting, except you lose an hour asleep for this one, right? Or is it that you gain?

+ +

STEPH: We're going forward. Yeah, it's fall back and then spring forward. That's how I remember it.

+ +

CHRIS: Worth it. I'll take the sunshine at night.

+ +

STEPH: Yeah, it's supposed to be so we have more sunshine during the daylight hours. That's the reasoning for the nonsense, the headaches. On some more technical news, when I came back from vacation, we noticed that the CI build time has suddenly spiked for the client project where previously we were averaging, I'd say, around 25-26 minutes. There's definitely a range there. But that seems to be pretty consistent.

+ +

And right now, builds are taking more about 35, sometimes upwards to 45 minutes. And so it's been a bit of who done it or what caused it adventure of figuring out why, what's causing the spike. And so Joël and I have been pairing heavily on that to investigate what's going on and learned a lot of features that TeamCity offers and just diving into this particular issue.

+ +

One thing that brought me joy is by looking through all the builds that are taking place on TeamCity. As I noticed, there are a number of builds that are using the RSpec selective testing that I added where if you only change a test to then we're only going to run those tests instead of the whole suite. And it was one of those changes where I thought, okay, maybe someone's going to get use out of this. Joël and I will probably get use out of this. But I'm actually seeing it about one every ten build something like that. And I'm just like, oh, this is awesome.

+ +

One, people are improving tests. That's amazing. And then two, that then they're benefiting especially while we have this spike going on. So that was a suggestion from you that I appreciate because that is paying dividends. And so that brought me a lot of joy while looking into this other issue, which we haven't resolved yet. We think it has something to do with how the tests are being balanced across all the different parallelized processes. And we think that there is an imbalance that has happened. And then that's what's really throwing things off.

+ +

So we can see that one particular process is taking around 26-27 minutes, but then the next process that's highest in time is only taking 17 minutes. So it's like, why is there suddenly ten more minutes that's being attributed to one process? And why is that not getting spread out? So still looking into that. That's the mystery for this week. But that's mostly what's going on in my world. What's up in your world?

+ +

CHRIS: What is up in my world? I'm going to say a quite alarming thing happened this week, which was we were investigating some changes, or we were investigating some behavior where the particular portion of the system ended up in the logs, just sort of combing through. And I happened to notice this one log line that...our logs tend to be somewhat verbose. They're JSON-structured log format. I've talked about the lograge setup that we use in the past, but there's a bunch. These are long lines of JSON-structured data.

+ +

But this line that caught my eye was not. It was just some text, and it said, "Unreported event: and then some other texts." And I was like, ah, what? Who didn't report which to when? I did some digging, eventually figured out that this was Sentry. Sentry was logging that it had not reported an event to us. But had we not randomly happened upon this in the logs, which is sort of a random thing to see, we would have missed this, which is scary. I mean, it was missed for a little while. And so Sentry was not reporting certain events.

+ +

We had made a change, particularly to Sentry's before_send configuration. So there's a way that you can do some amount of filtering client-side or client being, in this case, our Ruby app. So that's like the client-side of Sentry, and then there's their server backend. So that would, weirdly, that's the way the client-server work in this case.

+ +

But the idea is you can do some proactive filtering of being like, you know what? Rather than sending a ton of noise...because we know there's this one error that we can't stop for reasons. It's a JavaScript Chrome extension that's getting embedded in the app. That doesn't mean anything; that's just noise. Rather than even sending those over to Sentry, let's proactively filter them out. before_send is a function within the Sentry SDK that allows you to do this.

+ +

But it turns out if you raise an error in there, if you happen to have introduced something that doesn't cover all the possible edge cases, then Sentry will just not let you know and will log, interestingly, that they did not report the event. I'm going to throw it out there that I would love if Sentry were to say Sentry me...that's where I put something very bad happened, and you should look at it.

+ +

And they're just like, well, something pretty darn bad happened. We'll log it. Supposedly, my understanding is before_send can be used to filter out like PII or other things like that. And so their failure mode is quiet intentionally. That's my understanding as to maybe why this is true. I wish there were configuration that said, no, please fail as loudly as humanly possible. But that was terrifying.

+ +

STEPH: Yeah, absolutely. I'm going to piggyback on what you just said for a minute because I was also thinking earlier and related to the sudden spike in our CI builds where I was like, it would be really nice if there's...because I suspect there's one particular change that has caused this to happen. I don't know what it is yet, but that's just my suspicion. And it would be great if when that build ran, let's say that build went from an average of 25 minutes and suddenly we have a build that took 35 minutes if TeamCity had alerted us or if something more aggressive had to happen to say like, "Hey, your team..." or maybe it's just in the logs somewhere.

+ +

Okay, not in the logs somewhere more visible on the build where it's like, "Hey, your build took an extra 10 minutes compared to the average, just letting you know. I don't have a diagnosis for you, but we're just letting you know." So yeah, plus-one to getting those types of alerts out to people and notifying us when there's an average that's not being met or when things aren't getting logged like you'd expect them to.

+ +

CHRIS: As part of what we were doing in the logs...like how to get to that anomaly detection place is a really interesting question in my mind. And this is a case where we were in the logs, and we wanted to instrument more things. So we have a bunch of stuff right now that goes in. It's either a warn or error log level. And the error should be pretty rare because, ideally, those are going to Sentry instead, but we still want to keep an eye on them.

+ +

But we introduced a new search within log entries, which is what we're using for logging aggregation and searching. And the idea was to group all warn-level messages and to group it on the message string. So ideally, what this allows us to do is say, "Oh, we've seen 200 instances in the past two days of this new warning that we didn't see before." The difficulty is, as a human, I would see unhandled error blah as one bucket of warning, or I might want to see it that way. I might want to group it on part of the message. So it becomes really hard to find the signal in the noise on these, but at least it was a start.

+ +

We now have this little graph for both warning and error-level log messages that we can see are there any new anomalies that are occurring pretty regularly? But this, again, was just this weird edge case where we were lucky to catch it. But it was very scary that it was just throwing stuff away. So the universe might have been true that our error log did get a little quiet for a little while, which was nice, but it wasn't 100%. It wasn't like we were at 10 hours, an hour, and then we went to zero. It was like some, and then we went to a lower number because we were still getting some. We were only filtering out certain ones.

+ +

But yeah, it's how do you know at runtime that the system is doing the thing? This is increasingly the question that I have in my mind. But yeah, so that was the thing. We fixed it. It's fixed now. I also set up an alert in log entries to say, "If you ever see this particular phrase again unhandled or unreported," then please tell me about that post-haste. So we've got that now.

+ +

STEPH: That's perfect. That's what I was about to ask us if there's a way that you could add a filter or add a warning for that anomaly detection. So that sounds great.

+ +

CHRIS: I've got that now because this became a known-unknown, but there are still the unknown-unknowns, and there are so many of them. And I can't know them is my understanding of how they work. I would love to know them. I would love to pin them down and be like, "Hey, what are you doing here?" Someday maybe. But anyway, that was the thing in my world. [laughs] It was fun. It was a great little time. What else is up in your world?

+ +

STEPH: I feel like you can always judge the level of fun based on how high someone's voice goes. No, it was fun. It was great. It was fun.

+ +

[laughter]

+ +

CHRIS: I believe that is an accurate assessment, yes.

+ +

STEPH: I've caught myself doing that. I'm like, my voice is extra high, so I don't think I really mean that when I'm using the word fun. [laughs]

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

I do have a small update that I can share regarding the work that we're doing to be able to scale horizontally. So we want to be able to add more machines quickly and easily so we can then process more RSpec tests. And we have discovered with TeamCity that we're pushing forward on that particular path because they have something called a composite build. And with a composite build, it's essentially your parent or your supervisor build. And then, from there, you can create other subsequent builds.

+ +

So we can then say, all right, let's have multiple builds that then run the RSpec test, and then we can separate in that way. And right now, we're going about it in the hacky way because we just want a proof of concept. So we are saying specifically in this particular step, we want you to run spec models. And in this other process, we want you to run these particular tests just because we want to see how this works. And so far, the aggregation seemed great.

+ +

So when you look at that composite parent build, it's showing you how each of those builds are doing. It's also reporting back the failures. It's even de-duping them. Because initially, we set it up where we were running the full test suite in parallel on both of these builds, [laughs] not what we wanted, fixed that. But it did highlight that it was de-duping the test failures. So that part was nice.

+ +

So the UI seems great and seems quite very capable of doing this. Composite build seems to be the way that we can do this with TeamCity. But we're still diving into actually getting the metrics like, okay, how much is this actually going to speed us up? And what does this look like if we want to be able to scale up to say from 5 to 10 where we went from 5 machines to 10 machines? And that part doesn't feel graceful because then you have to go in and change the configuration and copy the configuration to then add a new build that then is going to process RSpec test.

+ +

So other services like Buildkite make it very easy. I can't remember if it's like literally a slider or if it's a number that you enter. But you can say, "This is how many processes that I want to run," in which it would be a lot nicer for that actual scaling. Versus TeamCity, it feels far more manual and intentional where you then have to duplicate and add those settings. But it's a really good first step because, as we'd highlighted before, there's a lot of risk in moving over from an existing infrastructure to something totally new.

+ +

So if we can have some wins with this approach and help out the team and reduce build time, then that gives us more grace period. So then we can assess, okay, do we really want to move over to Buildkite? What do we want to do next? What does this look like? And have further discussions. So that's a small update there. Next time I should have some more updates around actual data on how things are looking.

+ +

CHRIS: Oh, cool. Yeah, I appreciate the update and definitely interested to hear how this continues to play out. This is a large project that you're undertaking and all the facets and whatnot, so yeah, super interested to hear the continued journey of the test build time reduction. Let's see, other news in my world. I've been exploring something that I'm intrigued by the idea. Let's go with that. [chuckles] That's going to be my start. I always start with these lead-ins that build things up too much.

+ +

But I am finding a small tension in trying to just keep up with what the team is doing, which is a wonderful place to be. Our team is growing. We actually have someone new joining tomorrow, very exciting. But I'm trying to find the right version of I don't want to block things. I don't want all code review to have to go through me. But I do want to keep an eye on everything. I want to kind of know what we're doing collectively.

+ +

And ideally, mostly, that's me being like, yep, that makes sense. We're doing that. I remember that, cool. Wait, what's this? And rarely, occasionally, there'll be a point where I'm like, oh, I want to intervene here. I want to have a conversation. I want to rethink how we're building this. And so it's moving from a place of any sort of blocking synchronous review or the necessity for that to ad hoc post-review sort of thing. And so the way that I'm trying to poke around with this, of course, I'm writing some code to do it because of me.

+ +

So the two systems that we're using that seem most of interest are GitHub and Trello. And so it turns out GitHub has a wonderful search, and I can create a search that is parameterized like create a URL that jumps into a parameterized search saying, "Show me everything that was merged in the past X amount of time, " so I can say the past two days because I haven't checked it in two days. So I'll see all of the PRs that were merged, and some of them I'll have already reviewed. So I maybe could even filter further there. But for anything that I haven't seen, I'm like, oh, what was this? What was that? What was this other change?

+ +

Similarly, on Trello, there's a way via the API to get all of the card update actions. And then I can filter down to say whenever a card was moved, which in our system that means...we're doing Kanban-style, so a card being moved from this column to that column that tells me that someone is progressing forward with some work. And then I can further filter down because, again, I don't really want to be blocking on this. I'm most interested in what have we done or completed in the most recent timeframe.

+ +

And thus far, it's an interesting data set. And it's an interesting way to switch the problem around such that I'm not feeling...there was FOMO or organizational FOMO is perhaps how I would describe it of like, I want to try and keep an eye on stuff and make sure I'm responsive. But I'm now blocking, so I have to step away. But now I'm worried that I'm missing things. And so I'm trying to find that good middle spot. And this feels like an interesting exploration of that.

+ +

STEPH: I'm intrigued when you mentioned the card moving over, so then you can tell things are progressing. And then you're answering the question of what did we do in this particular chunk of time? When you move stuff over, is there a clear sweep of we have finished this sprint, and then you have the date of that sprint at the top, and so then you essentially have a column that represents all the work that was done in that sprint? Is that an approach that you're using? Because that's the one that immediately came to mind for me when you're wondering what was accomplished during this week or two-week period?

+ +

CHRIS: Interesting question. So we're not really doing sprints, or there are no real iterations. We're doing more of the I think Kanban is the way to describe it. But basically, we have a prioritized next up column. And then every day, I can say continuously, the work has the same shape, which is pick up the next most important thing, work on it, move it through the various columns.

+ +

I did introduce in Trello just the idea of, like, here's a month, so we can see by month what we're doing, but that's too low granularity in my mind. I want to review it a month at a time. The whole point of this in my mind is to see stuff as it's happening vaguely in real-time but not requiring me to constantly be monitoring everything. So it gives me an opportunity at the end of the day to be like, what happened today? What do we do? But yeah, so there's no real sprint that I would couple this to because we're not really doing sprints.

+ +

STEPH: Got it. Yeah, that gives me more context. I understand why you're then looking for ways as to how to answer that question of, like, what did we accomplish in this week or a particular time period?

+ +

CHRIS: And to name it, this is not an intention on my part to be like, I need to control everything. I need to make all the decisions. I very much want to empower the team. And in my mind, this is actually a mechanism to empower the team. I want to give them more freedom and then have the opportunity occasionally to check back in and be like, oh, actually, there was some context that was missing here the way we did this. Let's actually unwind that, do it this other way for these reasons. But it gives me the ability to potentially have that conversation after the fact.

+ +

We're trying very hard to have the tickets be as representative and complete, and well documented as possible. But that's very difficult to get to. And there are also things that I don't even know to mention. Again, I think the critical bit is this is not an attempt to make sure everything aligns with what I think; it's more I want to empower the team to move without me most of the time. And then, where there are things that potentially should have a small conversation or a redirection, then we have the ability to do that. And so, I'm trying to build that back into my workflow while basically loosening up my connection to the work in progress at any given point in time.

+ +

STEPH: So you just touched on a topic that's really interesting to me or a particular space. You're doing a very kind thing where you want tickets to have lots of context so that people feel confident when they're picking up what's the action item to be done. And for someone that's new, that's incredibly helpful, and I think more important since they are new to that world.

+ +

But in general, my spicy take of the moment is going to be as developers; that's part of our job. If we notice that context is missing or if we're not clear about the action item, is to think through what is it that I'm missing? Who do I reach out to? Who can I go to for help? How can I scope this work? All of that, to me, is very much part of our role.

+ +

And the idea that tickets always have to be perfectly curated, which I don't think you're saying, but you're just trying to be extra helpful. But if someone were to have that expectation, I think that expectation is wrong. And I do think it is part of our work that then we help make sure that tickets are well-scoped and well-defined and have those conversations with the people creating the tickets or creating them ourselves.

+ +

CHRIS: I love the clarification there, and I'm definitely in agreement with you. I don't know how picante of a take it is. I would be intrigued. Listeners, let us know. Are we breaking your mold of what things should be? But I do like the idea that it is a conversation so back and forth. And so the idea that as developers, there should just be this very clear list of things to do and you just kind of pick up a card and heads down, just get it done, I don't think that should be the mold.

+ +

But I do think; ideally, the why is the most important thing that I think should be in a card. So ideally, a card should have little in terms of technical implementation notes and should have more in terms of here's the goal that we're going for, here's the problem, or here's the thing that we're trying to solve. And then maybe a suggestion of like, I think it could be an X, Y, and Z, but I'm not sure. Or we want to be able to send transactional emails, but I don't know any more than that.

+ +

Our goal is to engage users. Like that last sentence, that last little bit of our goal is to engage users is a critical, critical data point, versus our goal is to solve for a regulatory and compliance issue. It's like, well, those are different. And they will lead to different solutions and different implementations and all that.

+ +

So yeah, I definitely share the idea that cards don't need to be perfectly specified. And if anything, I think I'm closer to that than it probably sounded like I was. But for that reason, it's totally possible in my mind, that work will be done in a way that after the fact, I'm like, "Oh, sorry, there was a misunderstanding here. Let's revisit this work."

+ +

And so, my goal is to try and stay connected and have a feedback mechanism at the end of the process. So when the work is done, be able to spot-check it rather than trying to have to watch it as it's happening or proactively define everything in excruciating detail such that exactly the right things happen all the time. So I'm moving to a place of ask forgiveness, not permission. That's the wrong analogy here. But that idea of like, we can clean it up after the fact, that's fine. And we don't need to try and prevent any sort of things, or at least that's what I'm exploring.

+ +

STEPH: Yeah, I love that you highlighted having the why. I adore that when that's on a card just because I then I want to know the goal because then that's going to help me ask questions and think about scoping versus if it's like a very specific implementation, then I feel so narrowly scoped that I don't feel as confident that I can be like, okay, I know why I'm doing this versus I just feel very directed to do a thing, and that's incredibly helpful.

+ +

I have also felt the pain that you're mentioning where it does feel like a ticket has all of the work clearly defined, and the goals, and the whys, and it can have everything there, but just something gets lost in the communication. And so someone implements something in a way that is how they interpreted the work versus it's not actually what the ticket or what the goal of the work was to be done.

+ +

So I appreciate that where you are looking for ways to tweak things to make sure that whoever is picking up that ticket will have the same interpretation that the author intended for them to have. And then if that does happen, and things get misaligned, then you chat and figure out ways to improve it.

+ +

I think that's the point that I was really thinking about, and my air quotes, "hot take," is that as developers, a big part of our job is communication, and then also sharing the knowledge that we have with other people. And so if someone is expecting that they can just always pick up work and never talk to someone, I don't know, maybe you're in the wrong business. [laughs] That's my hot take.

+ +

CHRIS: I, for one, like the hot take. It is nice and ever so slightly spicy.

+ +

STEPH: Thanks. Yeah, I just think communication is incredibly important. Earlier, you mentioned, I don't think we were on mic at the moment, but you mentioned something about a new Git alias. And I am very intrigued on hearing about what you've added, what it does, all the details.

+ +

CHRIS: All the details, that's probably too many, but some of the details I can certainly provide. So I have two new Git aliases; one is Git gone, which is probably the heart of the whole thing. And so the background of this is I found myself pushing the green merge button on GitHub more. We've introduced some branch protection stuff, which I've talked about in previous episodes. And I dream of the day that one of my good, good friends at GitHub will give me access to the merge queue beta. Please, please, I implore thee. But in the interim, still clicking the green merge button more often than not.

+ +

STEPH: Wait. I have to ask to help you in this dream. Are you forwarding these episodes to someone? You can just take a clip of you saying, "Please, please, please give me access," [chuckles] and just forwarding that or mentioning someone at GitHub or GitHub in general.

+ +

CHRIS: Just leaving voicemails for people with a Bike Shed section of me begging for access to the merge queue beta?

+ +

STEPH: Yeah. [laughs]

+ +

CHRIS: No, I'm not. But maybe I need to up my game. You're right. [laughs] Someday, I'll get there. And that will only exacerbate this issue that I'm feeling, which is again, I'm clicking the merge button. That's what's happening. And as a result, that means my local branch is now like it's done its job. You've served me well. And in the Marie Kondo sense, I need to hold you up, thank you for your service, and then let you go. But I obviously wanted to automate that.

+ +

So Git gone does that automation, and it was fun. So I found a blog post which we'll include in the show notes, that had most of the pieces here, but it was still fun to play with the shell pipeline in a way that I hadn't in a while. So it does a Git fetch and then git-for-each-ref with a particular structured format that references the upstream of the branch then uses awk to search for the word gone.

+ +

Because Git, if you print it out in this particular way using this format, it will say the local branch name and then the upstream. But if you've deleted the upstream, it will specifically say (gone) in brackets, so you can actually use that to filter them down. And then I pipe that to git branch-D so..well, xargs of course. I love a little shell pipeline. As an aside, these are fun little things to build up. So that is Git gone.

+ +

And then the other one that I have is Git down, which is what I use more. And Git down works on top of Git gone, so it's Git checkout main and and Git pull and and Git gone. But that means I get to type Git down into my terminal whenever a branch happens to get merged in the upstream land. [laughs]

+ +

STEPH: [laughs] Oh, that's adorable. I love it. I like the Git gone, and yeah, I like the Git down just for fun. You are inspiring me where I now really want a Git bless your heart that's like maybe a Git blame or a Git revert. [laughs]

+ +

CHRIS: I've definitely seen people do Git praise as an alias for Git blame.

+ +

STEPH: That's nice.

+ +

CHRIS: But Git bless your heart is...ooh, I love that.

+ +

STEPH: [laughs] I might have to add that just so I can type it, and then someone can say, "What are you doing?" [laughs] Cool, I love it.

+ +

CHRIS: Little things, little fun bits to add to your day and to automate and have a little fun while you're at it. So that's where I'm at.

+ +

STEPH: All about the communication and fun. That's what I'm here for and the singing. Let's not forget the singing.

+ +

CHRIS: And the singing, of course.

+ +

STEPH: [singing] On that note, shall we wrap up?

+ +

CHRIS: Let's shall. Oh.

+ +

STEPH: [laughs]

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Bye.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph celebrates Utah's adoption day and Daylight Savings Time and troubleshoots a CI build time that had suddenly spiked for a client project using TeamCity. She also shares a minor update regarding the work that thoughtbot is doing to scale horizontally and add more machines quickly and efficiently to process more RSpec tests.

+ +

Chris was alarmed by logs and unknown-unknowns and had some fun using Git down. Git bless his heart!

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Today is Utah's adoption day. So officially, one year ago, we adopted Utah. He's about a year and a half years old now because we got him when he was around the six-month mark. So Utah, aka Raptor, which is the nickname that you gave him, and aka UD [spelling] the cutie is his other nickname...which I've forgotten, why do you call him Raptor? Why is that a name?

+ +

CHRIS: Because there's a Utah Raptor.

+ +

STEPH: A person? [laughs]

+ +

CHRIS: No, I think it was like the fossils were found in Utah. But the Utah Raptor is a type of dinosaur. And so when I heard Utah, my brain went to Raptor, and then I dropped the Utah sort of a Cockney rhyming slang sort of thing. Shout out to Matt Sumner real quick. But yeah, Raptor.

+ +

STEPH: Cool. Cool. Cool. I'm so glad I asked. Now I know. I just accepted it when you called him Raptor. I was like, sure, he can be a Raptor. [laughs]

+ +

CHRIS: I feel like that says a lot about me that you were just like, okay, why not?

+ +

STEPH: [laughs]

+ +

CHRIS: That's different and has no apparent connection to the actual name of the creature, but that's fine. I might be a nonsense person.

+ +

STEPH: Or me for accepting it. You share a lot of nonsense, and I accept a lot of nonsense. That might be our dynamic. [laughs] So it works out.

+ +

CHRIS: That just may be our dynamic.

+ +

STEPH: That's why I'm always so nice with the good idea, bad idea, or even terrible. [laughs]

+ +

CHRIS: You're like, it's all nonsense 100% of the time, but yeah. So Utah is one year into living with you folks. So that's lovely.

+ +

STEPH: Yeah, and he's growing up so well. Oh, and I've been training him for one of his latest tricks. I'm very excited because it seems to be really sinking in. So every night, we take him out for his final bathroom potty but then before we go to bed. And one night, for some reason, I started singing The Final Countdown. [singing] It's the final countdown. But I started singing it's the final potty instead.

+ +

So now, when it's time to go out for the bathroom late at night, I look at him, and I start singing. And I start singing [vocalization], and it's working. He's starting to recognize that when I started singing that tune, he's like, okay, and he gets up from his comfy spot, and we go outside. And it brings me a lot of joy.

+ +

CHRIS: That is perhaps the best use of Pavlovian conditioning that I've ever heard of. Also, I really appreciate that you both mentioned the final countdown but then said just in case anyone is unfamiliar with the tune, let me hum a few bars. Thank you for doing the service there.

+ +

STEPH: I have been singing so much this week. I don't know if Joël Quenneville, who I've been pairing with a lot, appreciates that. Sorry, Joël. But I have been singing so much. And I think that's post-vacation vibes. That's what vacation does for you. And it helps you get back into, you know, lots of singing or at least it does for me.

+ +

Let's see, what else is going on this week? So this is the week that we have DST in the USA, so Daylight Savings Time, aka summertime, where we advance our clocks so everybody...although this is going to be late. So at this point, by the time people are hearing this, you're going to have already dealt with all those bugs that have crept up. But those are creeping up this week, where people are starting to notice a lot of those flaky specs that aren't technically flaky. They're actually breaking for real reasons because they were tested in a way that shows that they're not considering that daytime boundary.

+ +

CHRIS: It's as if you spend some of your time fixing flaky specs that that's where your mind goes with DST. Because I'm going, to be honest, part of what you're doing right now is telling me that this is coming up, and I didn't know. I had forgotten about that, which is very exciting, except you lose an hour asleep for this one, right? Or is it that you gain?

+ +

STEPH: We're going forward. Yeah, it's fall back and then spring forward. That's how I remember it.

+ +

CHRIS: Worth it. I'll take the sunshine at night.

+ +

STEPH: Yeah, it's supposed to be so we have more sunshine during the daylight hours. That's the reasoning for the nonsense, the headaches. On some more technical news, when I came back from vacation, we noticed that the CI build time has suddenly spiked for the client project where previously we were averaging, I'd say, around 25-26 minutes. There's definitely a range there. But that seems to be pretty consistent.

+ +

And right now, builds are taking more about 35, sometimes upwards to 45 minutes. And so it's been a bit of who done it or what caused it adventure of figuring out why, what's causing the spike. And so Joël and I have been pairing heavily on that to investigate what's going on and learned a lot of features that TeamCity offers and just diving into this particular issue.

+ +

One thing that brought me joy is by looking through all the builds that are taking place on TeamCity. As I noticed, there are a number of builds that are using the RSpec selective testing that I added where if you only change a test to then we're only going to run those tests instead of the whole suite. And it was one of those changes where I thought, okay, maybe someone's going to get use out of this. Joël and I will probably get use out of this. But I'm actually seeing it about one every ten build something like that. And I'm just like, oh, this is awesome.

+ +

One, people are improving tests. That's amazing. And then two, that then they're benefiting especially while we have this spike going on. So that was a suggestion from you that I appreciate because that is paying dividends. And so that brought me a lot of joy while looking into this other issue, which we haven't resolved yet. We think it has something to do with how the tests are being balanced across all the different parallelized processes. And we think that there is an imbalance that has happened. And then that's what's really throwing things off.

+ +

So we can see that one particular process is taking around 26-27 minutes, but then the next process that's highest in time is only taking 17 minutes. So it's like, why is there suddenly ten more minutes that's being attributed to one process? And why is that not getting spread out? So still looking into that. That's the mystery for this week. But that's mostly what's going on in my world. What's up in your world?

+ +

CHRIS: What is up in my world? I'm going to say a quite alarming thing happened this week, which was we were investigating some changes, or we were investigating some behavior where the particular portion of the system ended up in the logs, just sort of combing through. And I happened to notice this one log line that...our logs tend to be somewhat verbose. They're JSON-structured log format. I've talked about the lograge setup that we use in the past, but there's a bunch. These are long lines of JSON-structured data.

+ +

But this line that caught my eye was not. It was just some text, and it said, "Unreported event: and then some other texts." And I was like, ah, what? Who didn't report which to when? I did some digging, eventually figured out that this was Sentry. Sentry was logging that it had not reported an event to us. But had we not randomly happened upon this in the logs, which is sort of a random thing to see, we would have missed this, which is scary. I mean, it was missed for a little while. And so Sentry was not reporting certain events.

+ +

We had made a change, particularly to Sentry's before_send configuration. So there's a way that you can do some amount of filtering client-side or client being, in this case, our Ruby app. So that's like the client-side of Sentry, and then there's their server backend. So that would, weirdly, that's the way the client-server work in this case.

+ +

But the idea is you can do some proactive filtering of being like, you know what? Rather than sending a ton of noise...because we know there's this one error that we can't stop for reasons. It's a JavaScript Chrome extension that's getting embedded in the app. That doesn't mean anything; that's just noise. Rather than even sending those over to Sentry, let's proactively filter them out. before_send is a function within the Sentry SDK that allows you to do this.

+ +

But it turns out if you raise an error in there, if you happen to have introduced something that doesn't cover all the possible edge cases, then Sentry will just not let you know and will log, interestingly, that they did not report the event. I'm going to throw it out there that I would love if Sentry were to say Sentry me...that's where I put something very bad happened, and you should look at it.

+ +

And they're just like, well, something pretty darn bad happened. We'll log it. Supposedly, my understanding is before_send can be used to filter out like PII or other things like that. And so their failure mode is quiet intentionally. That's my understanding as to maybe why this is true. I wish there were configuration that said, no, please fail as loudly as humanly possible. But that was terrifying.

+ +

STEPH: Yeah, absolutely. I'm going to piggyback on what you just said for a minute because I was also thinking earlier and related to the sudden spike in our CI builds where I was like, it would be really nice if there's...because I suspect there's one particular change that has caused this to happen. I don't know what it is yet, but that's just my suspicion. And it would be great if when that build ran, let's say that build went from an average of 25 minutes and suddenly we have a build that took 35 minutes if TeamCity had alerted us or if something more aggressive had to happen to say like, "Hey, your team..." or maybe it's just in the logs somewhere.

+ +

Okay, not in the logs somewhere more visible on the build where it's like, "Hey, your build took an extra 10 minutes compared to the average, just letting you know. I don't have a diagnosis for you, but we're just letting you know." So yeah, plus-one to getting those types of alerts out to people and notifying us when there's an average that's not being met or when things aren't getting logged like you'd expect them to.

+ +

CHRIS: As part of what we were doing in the logs...like how to get to that anomaly detection place is a really interesting question in my mind. And this is a case where we were in the logs, and we wanted to instrument more things. So we have a bunch of stuff right now that goes in. It's either a warn or error log level. And the error should be pretty rare because, ideally, those are going to Sentry instead, but we still want to keep an eye on them.

+ +

But we introduced a new search within log entries, which is what we're using for logging aggregation and searching. And the idea was to group all warn-level messages and to group it on the message string. So ideally, what this allows us to do is say, "Oh, we've seen 200 instances in the past two days of this new warning that we didn't see before." The difficulty is, as a human, I would see unhandled error blah as one bucket of warning, or I might want to see it that way. I might want to group it on part of the message. So it becomes really hard to find the signal in the noise on these, but at least it was a start.

+ +

We now have this little graph for both warning and error-level log messages that we can see are there any new anomalies that are occurring pretty regularly? But this, again, was just this weird edge case where we were lucky to catch it. But it was very scary that it was just throwing stuff away. So the universe might have been true that our error log did get a little quiet for a little while, which was nice, but it wasn't 100%. It wasn't like we were at 10 hours, an hour, and then we went to zero. It was like some, and then we went to a lower number because we were still getting some. We were only filtering out certain ones.

+ +

But yeah, it's how do you know at runtime that the system is doing the thing? This is increasingly the question that I have in my mind. But yeah, so that was the thing. We fixed it. It's fixed now. I also set up an alert in log entries to say, "If you ever see this particular phrase again unhandled or unreported," then please tell me about that post-haste. So we've got that now.

+ +

STEPH: That's perfect. That's what I was about to ask us if there's a way that you could add a filter or add a warning for that anomaly detection. So that sounds great.

+ +

CHRIS: I've got that now because this became a known-unknown, but there are still the unknown-unknowns, and there are so many of them. And I can't know them is my understanding of how they work. I would love to know them. I would love to pin them down and be like, "Hey, what are you doing here?" Someday maybe. But anyway, that was the thing in my world. [laughs] It was fun. It was a great little time. What else is up in your world?

+ +

STEPH: I feel like you can always judge the level of fun based on how high someone's voice goes. No, it was fun. It was great. It was fun.

+ +

[laughter]

+ +

CHRIS: I believe that is an accurate assessment, yes.

+ +

STEPH: I've caught myself doing that. I'm like, my voice is extra high, so I don't think I really mean that when I'm using the word fun. [laughs]

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

I do have a small update that I can share regarding the work that we're doing to be able to scale horizontally. So we want to be able to add more machines quickly and easily so we can then process more RSpec tests. And we have discovered with TeamCity that we're pushing forward on that particular path because they have something called a composite build. And with a composite build, it's essentially your parent or your supervisor build. And then, from there, you can create other subsequent builds.

+ +

So we can then say, all right, let's have multiple builds that then run the RSpec test, and then we can separate in that way. And right now, we're going about it in the hacky way because we just want a proof of concept. So we are saying specifically in this particular step, we want you to run spec models. And in this other process, we want you to run these particular tests just because we want to see how this works. And so far, the aggregation seemed great.

+ +

So when you look at that composite parent build, it's showing you how each of those builds are doing. It's also reporting back the failures. It's even de-duping them. Because initially, we set it up where we were running the full test suite in parallel on both of these builds, [laughs] not what we wanted, fixed that. But it did highlight that it was de-duping the test failures. So that part was nice.

+ +

So the UI seems great and seems quite very capable of doing this. Composite build seems to be the way that we can do this with TeamCity. But we're still diving into actually getting the metrics like, okay, how much is this actually going to speed us up? And what does this look like if we want to be able to scale up to say from 5 to 10 where we went from 5 machines to 10 machines? And that part doesn't feel graceful because then you have to go in and change the configuration and copy the configuration to then add a new build that then is going to process RSpec test.

+ +

So other services like Buildkite make it very easy. I can't remember if it's like literally a slider or if it's a number that you enter. But you can say, "This is how many processes that I want to run," in which it would be a lot nicer for that actual scaling. Versus TeamCity, it feels far more manual and intentional where you then have to duplicate and add those settings. But it's a really good first step because, as we'd highlighted before, there's a lot of risk in moving over from an existing infrastructure to something totally new.

+ +

So if we can have some wins with this approach and help out the team and reduce build time, then that gives us more grace period. So then we can assess, okay, do we really want to move over to Buildkite? What do we want to do next? What does this look like? And have further discussions. So that's a small update there. Next time I should have some more updates around actual data on how things are looking.

+ +

CHRIS: Oh, cool. Yeah, I appreciate the update and definitely interested to hear how this continues to play out. This is a large project that you're undertaking and all the facets and whatnot, so yeah, super interested to hear the continued journey of the test build time reduction. Let's see, other news in my world. I've been exploring something that I'm intrigued by the idea. Let's go with that. [chuckles] That's going to be my start. I always start with these lead-ins that build things up too much.

+ +

But I am finding a small tension in trying to just keep up with what the team is doing, which is a wonderful place to be. Our team is growing. We actually have someone new joining tomorrow, very exciting. But I'm trying to find the right version of I don't want to block things. I don't want all code review to have to go through me. But I do want to keep an eye on everything. I want to kind of know what we're doing collectively.

+ +

And ideally, mostly, that's me being like, yep, that makes sense. We're doing that. I remember that, cool. Wait, what's this? And rarely, occasionally, there'll be a point where I'm like, oh, I want to intervene here. I want to have a conversation. I want to rethink how we're building this. And so it's moving from a place of any sort of blocking synchronous review or the necessity for that to ad hoc post-review sort of thing. And so the way that I'm trying to poke around with this, of course, I'm writing some code to do it because of me.

+ +

So the two systems that we're using that seem most of interest are GitHub and Trello. And so it turns out GitHub has a wonderful search, and I can create a search that is parameterized like create a URL that jumps into a parameterized search saying, "Show me everything that was merged in the past X amount of time, " so I can say the past two days because I haven't checked it in two days. So I'll see all of the PRs that were merged, and some of them I'll have already reviewed. So I maybe could even filter further there. But for anything that I haven't seen, I'm like, oh, what was this? What was that? What was this other change?

+ +

Similarly, on Trello, there's a way via the API to get all of the card update actions. And then I can filter down to say whenever a card was moved, which in our system that means...we're doing Kanban-style, so a card being moved from this column to that column that tells me that someone is progressing forward with some work. And then I can further filter down because, again, I don't really want to be blocking on this. I'm most interested in what have we done or completed in the most recent timeframe.

+ +

And thus far, it's an interesting data set. And it's an interesting way to switch the problem around such that I'm not feeling...there was FOMO or organizational FOMO is perhaps how I would describe it of like, I want to try and keep an eye on stuff and make sure I'm responsive. But I'm now blocking, so I have to step away. But now I'm worried that I'm missing things. And so I'm trying to find that good middle spot. And this feels like an interesting exploration of that.

+ +

STEPH: I'm intrigued when you mentioned the card moving over, so then you can tell things are progressing. And then you're answering the question of what did we do in this particular chunk of time? When you move stuff over, is there a clear sweep of we have finished this sprint, and then you have the date of that sprint at the top, and so then you essentially have a column that represents all the work that was done in that sprint? Is that an approach that you're using? Because that's the one that immediately came to mind for me when you're wondering what was accomplished during this week or two-week period?

+ +

CHRIS: Interesting question. So we're not really doing sprints, or there are no real iterations. We're doing more of the I think Kanban is the way to describe it. But basically, we have a prioritized next up column. And then every day, I can say continuously, the work has the same shape, which is pick up the next most important thing, work on it, move it through the various columns.

+ +

I did introduce in Trello just the idea of, like, here's a month, so we can see by month what we're doing, but that's too low granularity in my mind. I want to review it a month at a time. The whole point of this in my mind is to see stuff as it's happening vaguely in real-time but not requiring me to constantly be monitoring everything. So it gives me an opportunity at the end of the day to be like, what happened today? What do we do? But yeah, so there's no real sprint that I would couple this to because we're not really doing sprints.

+ +

STEPH: Got it. Yeah, that gives me more context. I understand why you're then looking for ways as to how to answer that question of, like, what did we accomplish in this week or a particular time period?

+ +

CHRIS: And to name it, this is not an intention on my part to be like, I need to control everything. I need to make all the decisions. I very much want to empower the team. And in my mind, this is actually a mechanism to empower the team. I want to give them more freedom and then have the opportunity occasionally to check back in and be like, oh, actually, there was some context that was missing here the way we did this. Let's actually unwind that, do it this other way for these reasons. But it gives me the ability to potentially have that conversation after the fact.

+ +

We're trying very hard to have the tickets be as representative and complete, and well documented as possible. But that's very difficult to get to. And there are also things that I don't even know to mention. Again, I think the critical bit is this is not an attempt to make sure everything aligns with what I think; it's more I want to empower the team to move without me most of the time. And then, where there are things that potentially should have a small conversation or a redirection, then we have the ability to do that. And so, I'm trying to build that back into my workflow while basically loosening up my connection to the work in progress at any given point in time.

+ +

STEPH: So you just touched on a topic that's really interesting to me or a particular space. You're doing a very kind thing where you want tickets to have lots of context so that people feel confident when they're picking up what's the action item to be done. And for someone that's new, that's incredibly helpful, and I think more important since they are new to that world.

+ +

But in general, my spicy take of the moment is going to be as developers; that's part of our job. If we notice that context is missing or if we're not clear about the action item, is to think through what is it that I'm missing? Who do I reach out to? Who can I go to for help? How can I scope this work? All of that, to me, is very much part of our role.

+ +

And the idea that tickets always have to be perfectly curated, which I don't think you're saying, but you're just trying to be extra helpful. But if someone were to have that expectation, I think that expectation is wrong. And I do think it is part of our work that then we help make sure that tickets are well-scoped and well-defined and have those conversations with the people creating the tickets or creating them ourselves.

+ +

CHRIS: I love the clarification there, and I'm definitely in agreement with you. I don't know how picante of a take it is. I would be intrigued. Listeners, let us know. Are we breaking your mold of what things should be? But I do like the idea that it is a conversation so back and forth. And so the idea that as developers, there should just be this very clear list of things to do and you just kind of pick up a card and heads down, just get it done, I don't think that should be the mold.

+ +

But I do think; ideally, the why is the most important thing that I think should be in a card. So ideally, a card should have little in terms of technical implementation notes and should have more in terms of here's the goal that we're going for, here's the problem, or here's the thing that we're trying to solve. And then maybe a suggestion of like, I think it could be an X, Y, and Z, but I'm not sure. Or we want to be able to send transactional emails, but I don't know any more than that.

+ +

Our goal is to engage users. Like that last sentence, that last little bit of our goal is to engage users is a critical, critical data point, versus our goal is to solve for a regulatory and compliance issue. It's like, well, those are different. And they will lead to different solutions and different implementations and all that.

+ +

So yeah, I definitely share the idea that cards don't need to be perfectly specified. And if anything, I think I'm closer to that than it probably sounded like I was. But for that reason, it's totally possible in my mind, that work will be done in a way that after the fact, I'm like, "Oh, sorry, there was a misunderstanding here. Let's revisit this work."

+ +

And so, my goal is to try and stay connected and have a feedback mechanism at the end of the process. So when the work is done, be able to spot-check it rather than trying to have to watch it as it's happening or proactively define everything in excruciating detail such that exactly the right things happen all the time. So I'm moving to a place of ask forgiveness, not permission. That's the wrong analogy here. But that idea of like, we can clean it up after the fact, that's fine. And we don't need to try and prevent any sort of things, or at least that's what I'm exploring.

+ +

STEPH: Yeah, I love that you highlighted having the why. I adore that when that's on a card just because I then I want to know the goal because then that's going to help me ask questions and think about scoping versus if it's like a very specific implementation, then I feel so narrowly scoped that I don't feel as confident that I can be like, okay, I know why I'm doing this versus I just feel very directed to do a thing, and that's incredibly helpful.

+ +

I have also felt the pain that you're mentioning where it does feel like a ticket has all of the work clearly defined, and the goals, and the whys, and it can have everything there, but just something gets lost in the communication. And so someone implements something in a way that is how they interpreted the work versus it's not actually what the ticket or what the goal of the work was to be done.

+ +

So I appreciate that where you are looking for ways to tweak things to make sure that whoever is picking up that ticket will have the same interpretation that the author intended for them to have. And then if that does happen, and things get misaligned, then you chat and figure out ways to improve it.

+ +

I think that's the point that I was really thinking about, and my air quotes, "hot take," is that as developers, a big part of our job is communication, and then also sharing the knowledge that we have with other people. And so if someone is expecting that they can just always pick up work and never talk to someone, I don't know, maybe you're in the wrong business. [laughs] That's my hot take.

+ +

CHRIS: I, for one, like the hot take. It is nice and ever so slightly spicy.

+ +

STEPH: Thanks. Yeah, I just think communication is incredibly important. Earlier, you mentioned, I don't think we were on mic at the moment, but you mentioned something about a new Git alias. And I am very intrigued on hearing about what you've added, what it does, all the details.

+ +

CHRIS: All the details, that's probably too many, but some of the details I can certainly provide. So I have two new Git aliases; one is Git gone, which is probably the heart of the whole thing. And so the background of this is I found myself pushing the green merge button on GitHub more. We've introduced some branch protection stuff, which I've talked about in previous episodes. And I dream of the day that one of my good, good friends at GitHub will give me access to the merge queue beta. Please, please, I implore thee. But in the interim, still clicking the green merge button more often than not.

+ +

STEPH: Wait. I have to ask to help you in this dream. Are you forwarding these episodes to someone? You can just take a clip of you saying, "Please, please, please give me access," [chuckles] and just forwarding that or mentioning someone at GitHub or GitHub in general.

+ +

CHRIS: Just leaving voicemails for people with a Bike Shed section of me begging for access to the merge queue beta?

+ +

STEPH: Yeah. [laughs]

+ +

CHRIS: No, I'm not. But maybe I need to up my game. You're right. [laughs] Someday, I'll get there. And that will only exacerbate this issue that I'm feeling, which is again, I'm clicking the merge button. That's what's happening. And as a result, that means my local branch is now like it's done its job. You've served me well. And in the Marie Kondo sense, I need to hold you up, thank you for your service, and then let you go. But I obviously wanted to automate that.

+ +

So Git gone does that automation, and it was fun. So I found a blog post which we'll include in the show notes, that had most of the pieces here, but it was still fun to play with the shell pipeline in a way that I hadn't in a while. So it does a Git fetch and then git-for-each-ref with a particular structured format that references the upstream of the branch then uses awk to search for the word gone.

+ +

Because Git, if you print it out in this particular way using this format, it will say the local branch name and then the upstream. But if you've deleted the upstream, it will specifically say (gone) in brackets, so you can actually use that to filter them down. And then I pipe that to git branch-D so..well, xargs of course. I love a little shell pipeline. As an aside, these are fun little things to build up. So that is Git gone.

+ +

And then the other one that I have is Git down, which is what I use more. And Git down works on top of Git gone, so it's Git checkout main and and Git pull and and Git gone. But that means I get to type Git down into my terminal whenever a branch happens to get merged in the upstream land. [laughs]

+ +

STEPH: [laughs] Oh, that's adorable. I love it. I like the Git gone, and yeah, I like the Git down just for fun. You are inspiring me where I now really want a Git bless your heart that's like maybe a Git blame or a Git revert. [laughs]

+ +

CHRIS: I've definitely seen people do Git praise as an alias for Git blame.

+ +

STEPH: That's nice.

+ +

CHRIS: But Git bless your heart is...ooh, I love that.

+ +

STEPH: [laughs] I might have to add that just so I can type it, and then someone can say, "What are you doing?" [laughs] Cool, I love it.

+ +

CHRIS: Little things, little fun bits to add to your day and to automate and have a little fun while you're at it. So that's where I'm at.

+ +

STEPH: All about the communication and fun. That's what I'm here for and the singing. Let's not forget the singing.

+ +

CHRIS: And the singing, of course.

+ +

STEPH: [singing] On that note, shall we wrap up?

+ +

CHRIS: Let's shall. Oh.

+ +

STEPH: [laughs]

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Bye.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+kcg4IEDw + + ]]> + + Chris Toomey + Steph Viccari + + + 330: Bikeshed Baby + https://bikeshed.thoughtbot.com/330 + 282638df-584f-4f1f-828e-ddfa282682ce + Tue, 15 Mar 2022 00:15:00 -0400 + thoughtbot + + full + thoughtbot + BIG NEWS! Steph's expecting a baby boy! 🍼🎉 + +Aaaand unfortunately, the rest of the show isn't nearly as exciting. Chris talks about admin pagination using Pagy, and Steph wants to delete some code and has nervousness around that she's going to break something. + +They answer a listener question from Slash, who asks, "What are the first keyboard shortcuts you teach junior devs?" + 33:50 + no + + + BIG NEWS! Steph's expecting a baby boy! 🍼🎉 +Aaaand unfortunately, the rest of the show isn't nearly as exciting. Chris talks about admin pagination using Pagy, and Steph wants to delete some code and is nervous that she's going to break something. +They answer a listener question from Slash, who asks, "What are the first keyboard shortcuts you teach junior devs?" +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Pagy (https://github.com/ddnexus/pagy) +Upcase advanced queries (https://thoughtbot.com/upcase/advanced-activerecord-querying) +fzf (https://github.com/junegunn/fzf) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Let's go. Oh man, now all I can think of is the...but what's his face? The quarterback for The Patriots formerly. Oh my God, I can't remember his name. +CHRIS: Tom Brady? +STEPH: [laughs] Thank you. Tom Brady. I wanted to say Brad Pitt, but I'm like, that's not right. [laughs] +CHRIS: See, I thought of the musical...well, I think it's a musical, Encanto. Have you watched Encanto? +STEPH: Oh, I love Encanto. +CHRIS: It's so good. +STEPH: We Don't Talk About Bruno, no, no, no! +CHRIS: We Don't Talk About Bruno but...it was my wedding day. +STEPH: But also Luisa Song, that's actually a good one too. +CHRIS: Luisa Song that we have now listened to the soundtrack a lot of times, and we've only watched the movie twice, once ourselves and then once with our niece and nephew. That is the order it happened in as well, just to be clear. [laughs] But yeah, it's good, lots of slaptitude to all the music and the overall movie and really just fantastic work. Lin-Manuel Miranda does good stuff. +STEPH: Super good. I have to bring back closure to my Tom Brady confusion, though. +CHRIS: Yeah, what was that? [laughs] +STEPH: [laughs] Now when I say the let's go, I think it was the Hertz commercial where he said, "Let's go," and he was impatient. I don't know if you've seen it. But marketing works, and now it's in my brain, and I hate it. [laughs] +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? +CHRIS: What's new in my world? I got some stuff, some tech things, and whatnot to ramble about, but frankly, much less interesting. What's new in your world, Steph? +STEPH: I do have some news, and I have some exciting news. So Tim and I, we are expecting our first child, hooray! +CHRIS: Yay! +STEPH: [laughs] We found out over Christmas or around the holiday. So depending on when this airs, but I'm around 14-15 weeks long. And it's tough. Growing a little human is tough. And it's been quite an adventure. And thankfully, I've got some friends to lean on and talk to through the process. But yes, that's my big news. We're going to have our first child. And oh, we also found out recently the sex of the child, and we found out we're going to have a baby boy, which is very exciting. +CHRIS: Well, that is so wonderful. I'm so happy for you. And on behalf of the entire Bike Shed audience, I think it's very easy for me to carry forward their best wishes. But this is absolutely wonderful. And I hope you didn't mind me redirecting the questioning right back at you at the start of this episode because this seemed more important than any tech nonsense I'm going to ramble about. +STEPH: Well, and you've been in the know for quite some time. And so we've been keeping it hush-hush until it felt like the right time to share. And this feels like the right time to go ahead and share. So there might be some interesting episodes up ahead where I get to complain and talk about this some more on the mic [laughs] since I have been keeping it quiet, but now I can talk about it more publicly. +CHRIS: Absolutely. I think this has been decidedly missing from The Bike Shed content in the six, seven years that this show's been going. So yeah, let's sell some truths. +STEPH: Bike Shed baby, that'll be one of our topics for sure. [laughs] But yeah, that's some of my big, exciting news. I'm going to kick it back to you since you were so kind to let me lead. What's going on in your world? +CHRIS: Back to me. I'm going to talk about admin pagination. So it really felt wrong to me that I'll be like, let me talk about pagination for a while. Also, what's up? So that said, now that we have shared the wonderful, exciting news, I can talk about the mundane realities of pagination. So yeah, I'm going to try and tell this one in a story to make it more interesting. So we have an admin page. It lists out the users of our application, as is so often the case. +And we hit that wonderful place where the page became wildly unreliable because we had so many people sign up for the application; yay! Very exciting. I feel like it's a meaningful milestone to get to where we're like, oh yeah, I guess we have to add pagination to the admin. Unfortunately, I picked this one up as, just like, this should be a quick, easy thing. This will be fun. +Coding, you know, I've gone back and forth on individual weeks where I have space in my schedule for coding, and then sometimes I find it difficult. And I'm trying to not pick up larger, more critical pieces of work. But this one seemed like a perfect little pickup. I'm just going to grab this, and I'm just going to quickly bang out some pagination, and the admin team will be so excited. Everything's going to be wonderful. Smash cut to that did not work out so great. +So I tried to introduce pagination using the Pagy gem, which I had not used before, but it's good. It seemed useful. And in particular, I'd seen an example from another Inertia Rails application that was using Pagy, and I was like, oh, cool, I'll just crib what they're doing. Because basically, we need to both get the data for the users and then serialize down the pagination data, the metadata about pagination. What page are we on? How many pages are there? Is there a next page? Is there a previous page? All of that kind of stuff. We need to serialize that down to the front end, and then use that to build a little pagination UI. +So like, they're using Pagy, and it does seem to do a good job of yielding both of those pieces of data to me, so both the recordset that it's paginated down to and the metadata about pagination. But unfortunately, when I first tried to use it, I ran into a wall where our user page basically just lists out the user. At the top, it has a little search bar, so you can type in name, or email, or ID. And then there's a little drop-down for the account status. What's the status of this user? So we can filter down to active accounts or onboarding accounts or that sort of stuff. Running the search, everything went fine. +When I went to filter down, suddenly it broke, and that was sad. So I went and chased it down. Pagy was throwing an error that it couldn't work with the collection that it was working with. And the reason was our admin user query object was iterating over the objects in Ruby land to do the filtering, which was very sad. So it turned out that the admin user query object, when it needed to do that filtering based on status, it was actually iterating through all the records and filtering them out using select or reject, whichever side. I forget which way it was implemented. But either way, it was iterating through the entire collection. +And so, Pagy, like most pagination things, tries to use offset-based pagination and database queries. So OFFSET LIMIT, that combination of things allows you to move through a recordset pretty easily. This is setting aside the idea of cursor-based pagination, which I've never fully understood or implemented, but let's just stick with OFFSET and LIMIT because they're going to get us what we need in this particular case. But by virtue of the fact that we're actually working with that recordset, turning it into an array, getting all of the records, it was less efficient than it needed to be. But it also meant that we didn't have an ActiveRecord relation that we could do this with. +And so then began the adventure of like, okay, this should be easy. I'll just turn it into a database query, except the account status was implemented as a method spread across a few models that looked at a value and then returned something, and that's why it was doing this in-memory filtering. But this is a classic case of I just want to add pagination. It will be super easy. Never mind, let me undertake a fundamental refactoring to the entire application and unify the idea of account status across user and the background object and this other object. +And then once that giant refactoring PR lands and I deal with the fallout of how this broke analytics and other pages in the app...it was a good thing. It was necessary. That was a mess, and we knew that. Fixing that was a good thing to do not just for the pagination but for actually unifying all of those ideas. Then once I landed that refactoring PR, oh, it's so easy to put in the pagination. [laughs] Just like, oh yeah, just paginate. That'll be great. +STEPH: You got back to the happy place of where it was easy again. +CHRIS: Took me like a week and a half to do the refactoring PR, though, partly because I was in and out on it. I couldn't give it my full focus. But there was definitely a morning where I was like, oh yeah, I'm going to add pagination to the admin UI. And the admin team was like, that's fantastic. We're very excited. A week and a half later, I was like, I'm sorry, I finally got to it, though. It's really good, though, right? +STEPH: I changed a bunch of things that you can't tell that I changed, but I promise it's a lot better. So now I can actually implement the change that you want to see. Well, I'm glad you walked away with a win because I've definitely been in the space where I have entered the refactor world and walked away with an L and realized that it's something that either wasn't worth tackling at the time or was just too challenging. +CHRIS: Oh yeah, I've definitely had that. And I think if it were a different shape of refactoring that were necessary to support this, I probably would have backed away, but because it was fundamental data model cleanup that needed to happen under the hood, I was like, that feels right. We should be doing this anyway. I'm also a big believer in dealing with ActiveRecord relations. So for anyone that's not familiar with the way ActiveRecord works, query evaluation is lazy. And so you can say user.where first name, blah. And that returns an unevaluated query, the idea of a query in the future, AKA an ActiveRecord relation. +And you can keep chaining on to that and building new relation. So you can say .where this thing and then pass that return object to something else, which then chains on another thing .joins to something else and then filter on an aspect of that. But again, we're not going to evaluate the query until we need it, typically until we iterate through the records that are part of it. And so, this is one of those things that I have, over time, slowly worked on and refined. And this is a skill area that I continually find value in investing in. +Again, I'll reference the wonderful Advanced ActiveRecord Querying course on Upcase that Joe Ferris hosted, and then I got to be a participant in, and still, I'm learning bits from that one years later. But the idea of really understanding what we can do with the database layer and then how we can reflect that in the ActiveRecord query syntax. +And then ideally, I have this motto in my head, which is just stay in relation land for as long as you possibly can. The minute you type .to_a to coerce it into an array or something like that, you have perhaps solved the immediate problem that you have, but at what cost? I ask, at what cost? The answer is a very big cost. You can't do other cool stuff after that. +STEPH: I'm intrigued how you refactored it because when you're talking about having the status, in my mind, I was presuming that it was a database column on one of the models. But then you'd mentioned it's not and that it's scattered across. So how did you refactor that and so then you could stay in relation land? +CHRIS: Primarily, we pushed the logic. So, unfortunately, it was spread across a few different objects. That was one complicated thing. So the idea of a status was spread across a few different spots actually in a few different models. So one thing was just to unify them all into one enum on the canonical record that should really own this idea. And then, really, it was to push it down into the database. So that was part of the work. +We also recognized that we had done not a great job with the implementation of the enum and with the naming of the key and the value in that enum in terms of how it was implemented in Rails. So there was a bunch of confusion. There was basically just a bunch of places where we had been less intentional than we probably should have. So mostly, it was just pushing all of that together and down into the database. And then where the status changes at any point in the application, we're just updating that column in the database, and then everything else can just happily work with that value. +STEPH: Got it. Yeah, that sounds great. Thanks. +CHRIS: You're welcome. But yeah, it really was a case of like that PR to refactor was a bit of a slog, if we're being honest. It was not fun. I was scared I was going to break stuff. I had to be very intentional with it. But once I was on the other side, then I got to have a query object, which is a lot of fun. I love writing those. +And I got to build pagination in Inertia, which is also one of those things that I really love. This is a place where Inertia really shines. It's incredibly performant. It allows you to do all of this stuff but in a familiar Rails way but yet still have fancy UI on the front end and just an intersection of some of my favorite things. So the refactoring both paid off in terms of what we got in the application but also was just fun at the end. Well, not the refactoring; the thing that came after the refactoring was fun. +STEPH: Nice. Well, speaking of being nervous about breaking things, I am feeling very determined right now where I want to delete some code. And I have that nervousness around I'm going to break something. But I've spent enough time with this code to feel confident that it's not truly in use. But knowing the exact entry point for that code is part of the CI script process. So I don't have full control over the entry points. It's something that I'm having to coordinate with another team to verify, like, hey, I'm pretty sure it's a script that's never called and never used, or at least this particular path we're not passing these particular flags to the script. +And going through the code caused enough confusion for me that if I can simplify this and get rid of that code, I'd really like to. So I'm at that point where I'm feeling good. I'm going to issue a change that deletes the code. But there's definitely a part of me that's nervous because it's one of those like, somewhere someone could be running this script on their machine locally. Or they could be using it as part of a different build process that I'm not aware of, which worst-case, then we realize something breaks, and then we have to roll it back. +But it feels like one of those important I'm going to do it while I've got the context. Let's delete the code. Let's see what breaks. Someone mentioned to me earlier there's the idea of the screen test where you delete something, and then you just wait, and you see who starts screaming. [laughs] I was like, yeah, that's exactly what I want to do. I've done more validation upfront. I don't want anybody to scream. But that's essentially the metric that I'm then going to go off of once we do merge this in and see how it goes. +But it felt like one of those interesting conversations with myself and someone else that was then looking at it with me where we could easily leave it. We could just walk away. Because I saw this code while I was working on something else, and then I really needed to assess whether I needed to alter this code as well or whether I could leave it alone. And I've decided I could leave it alone for this reason. +So it's one of those moments of like, okay, well, I could just walk away. I've done the thing that I needed to do for my change. But it feels important to go ahead and follow-through that while I have all of this context. So let's just go ahead and delete it, so someone else doesn't have to build up all that context. +CHRIS: As you're describing this, I'm sort of thinking of my own career arc as a developer. And early on, I'd just be like, it's fine, we'll just change it now. Nothing will go wrong. And then, obviously, something goes wrong. And slowly, over time, I've built up enough battle wounds from that that I was like, you know what? I'm hesitant to change it. I'm a little scared. What if we break production? And so then, there was a period of a couple of years where I would probably be more hesitant to change things. +And then eventually I got to the place where I'd seen the cost of not changing the thing when you have the context and letting the less correct implementation or the incorrect domain modeling sit and grow and become worse over time, and then the deep pain that you can feel down the road. And so now I'm like yeah, no, we're probably going to feel some pain on this change. Somebody is going to yell, but we should do it, and that's it. And I like thinking about that arc of just brazen confidence to oh God; everything's terrible to a different type of confidence. Like, yeah, I know something is going to break. But sometimes you got to crack some eggs, you know. +STEPH: And it's one of those areas where if we do find out something breaks and someone reports like, "Oh, this is really critical, and you took this away from me," then that's great, at least now I've got validation we know where it's used. And then we can; I don't know, maybe somewhere document that somehow or at least we don't even have to document it. But we just at least know that this is a valid code path that needs to be supported, and then I'll feel better about that. +Versus in this world right now, I'm in the I don't think this is important, but I don't have solid proof that it's not important, but I'm not going to treat it important. And that feels like the worst place to be. I want to know if this is valid or not. So this will help push us in that direction. But yeah, I like that arc that you described. I can definitely relate to that. +CHRIS: I definitely share the hesitancy and the worry that like, man, is this going to silently break something that someone relies on? But if that's true, then that means our test suite is missing something. If this is a critical code path and I could just delete it, and the test suite is like, cool, that seems fine, then we have a gap in our code coverage. +And I don't mean code coverage in the percentage metric; I mean it in the an important thing is not enforced by the test suite. And so it's a complicated and messy way to find out what's missing from our test suite, but it is a way. Just remove it and see then what happens. And then we backfill in the test suite to say, "Oh gosh, we should have had that. Deleting that was bad." +STEPH: So I absolutely agree with what you're saying. This particular scenario is a little tricky because the entry point isn't a traditional user-driven action or something that I feel more concrete that I can test a user flow even if it had test coverage, which it doesn't right now. But even if it had test coverage, it would be part of our CI process then calls this script, and then we expect the script to behave and respond as expected. But even then, if we had that test, we could still have unused code. It could still be a path that just doesn't need to be supported. +I guess as I'm saying this, that could be true of a user flow as well. I just talked myself into that; cool. [laughs] Yeah, it's one of those even if we had tests that wouldn't give me the full confidence to know whether we have a valid path or not, that needs to be supported. So it feels a bit tricky in that regard. Because I am so used to then relying on my tests to help me know that yes, this is something that's important to the application or not. And in this case, I don't think that actually helps me. +I think honestly, at this point, it's talking to people who have built a lot of the infrastructure in their CI system to say, "Hey, can you help me track down? I've looked at all the places that I know to look. I even issued a change that raises." So if that script was getting called, then something in the CI infrastructure should have blown up to let me know. So I've taken all the incremental steps that I can to see if anything breaks. And so far, nothing's breaking yet, but we just won't know until it's gone. +Comparing this to previous situations, it does feel like one of those areas where if I was uncertain about if something is in use, that looking at the test is always helpful but then also having a product manager to go to because then that person can confirm yes, this is something that I'm certain that someone still uses, or we need to support. Or they can say, "You know what? Even if it is something that someone is using, we don't wish to support this feature anymore, and we'd like to get rid of it." It feels like I'm in that space. But there's not a clear product manager. +Now, for this one, there is someone very knowledgeable who helped build a lot of this system that I can go to. So in effect, they are acting as that person that can then let me know to say yes; even though we have code to support this path, I'm pretty sure we don't want to support it anymore, and we can get rid of it. So that's ultimately what's given me the confidence to move forward with the change. +Mid-roll Ad +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +Pivoting just a bit, we have a listener question. And this question comes from Slash. And they wrote in, "What are the first keyboard shortcuts you teach junior devs? What is so powerful that can explain to juniors why it's important to know them?" Yeah, all right. I have thoughts. Chris, do you want me to kick us off, or do you want to kick us off? +CHRIS: This is an interesting one because, for folks that have seen some of my internet movements, you will know that I am a fan of the keyboard and shortcuts there. And I like Vim; I like Tmux. I do not like things that require me to use my mouse. And so, my answer might be somewhat surprising, but I actually try to avoid this. I think the trap of productivity enhancements and whatnot can be, especially early on, a way to distract from the real work. +There's so much as a junior dev to learn and, especially if you're a web developer, and I'm imagining this is potentially like full-stack web dev. But even if you're a front-end developer, there's a just world of complexity that you have now opened up. You need to understand about HTTP, and CSS, and HTML, and JavaScript, and TypeScript, and there are so, so many things. And so if there's anything we can take off of our plates at that point, I think that's really useful. +So my very clear suggestion to folks that are new is just use VS Code seems like it's great. It's got a ton of stuff built-in. It's going to work well, and you can get really far with it. And there's a point in time that you will get to where you feel like maybe that tool is slowing you down, although my understanding is VS Code is a really impressive piece of technology. And so if you're not as deeply drawn to keyboard-only as I am, then VS Code you can keep growing within that. There are so many enhancements and customizations and whatnot that you can do there. +But it's weird that my answer is kind of like none or deflect the question and say, do these cutters around Ruby and Rails and JavaScript or whatever the language or framework or whatever it is that you're working in. But that's my first approximation. I probably have a more real set of answers. But I'm interested in your response to that or your thoughts on that, Steph. +STEPH: I love that. I think you make such a good point that you are entering a world where there's so much to learn that I don't think this is of high importance. It is something that you can cultivate over the years but not something that you need to focus on. And when you highlighted using VS Code instead of saying our de facto like Vim, which is something that you and I love, I thought about that because Tim, my husband, went through a coding bootcamp recently. And I don't know if I'd shared this, but he just got his first job as a junior dev. So that's incredibly exciting. +And when we were talking about editors to use, VS Code was one of my top ones. I just know it's well built; it's popular. It does a lot for you. And it's just that way; you can focus on everything else that you mentioned that junior devs are often having to focus on that then at that point, it really becomes all the shortcuts for you to learn. +It's just get to know your editor. Understand how to do the fuzzy search for files or a specific method. How do you split windows? How do you make it easy to toggle between running your testing code? But I do think it's important to become familiar with those shortcuts and commands so that way you feel very competent and productive in your editor. Whatever your editor is, just get to know those commands. +To go a bit broader with it, I do think there are some things that are really helpful to know. And I'm also working off the assumption that if you're a junior dev, you probably already know the basics. You know the copying and pasting, refreshing a page, and undoing a change. So some of the keyboard shortcuts or tooling that would be more helpful, in my opinion, is as learning your editor, learn some terminal shortcuts. So like pressing up to rerun the last command, I think that's probably one of the first things that if I don't see someone doing that, I would remind them or let them know that they can do. +I also think it's really awesome to have a command-line tool like fzf that lets you find and filter files or search through your command history because I use that all the time. So I'm constantly just searching through my command history in my terminal so I can rerun commands versus having to remember what to type. And then also, I mean, there are a couple of basic browser shortcuts, so navigating between tabs, opening new tabs. +And then the big one is Git. If you're using Git for your job, spend time with Git, and that doesn't really fall into the whole keyboard shortcuts. That's a whole different topic. So I'm totally cheating here. But I think it's important enough to focus on that over the keyboard shortcuts is get good at writing commit messages, amending changes, viewing a history, and how to rebase, things like that. +CHRIS: I think the list that you gave there is actually a really practical one of, like, learn how to move around within your editor and in between the files because that's going to be a thing that you're just constantly doing. And so I'm also a huge fan of fuzzy finding, so Ctrl+P in the Vim world or fzf that you listed as a more generic utility that has it. I know VS Code has a command palette where you can fuzzy search for files and different variations there. And that is such a nice way to work. +I don't actually want keyboard shortcuts, if we're being honest. This is maybe a somewhat heretical thing, but I want modes. I love Vim's modes, and there's a whole language there. I made a YouTube video a while back about it because I believe in it so strongly. But it's that idea of like, if I have to remember these arcane movements of my fingers, that's not fun for me. +I want the computer to learn me rather than me it. And so fuzzy finding anything, being able to type any substring of the things that you're matching against is such a powerful way to interact with stuff that's like, it's not me knowing the magic key command to do something; it's the computer understanding me a little bit better. +You also listed being able to run a test file or an individual test. I love that one. That is something that I use constantly. And so that's one that I think would be worth investing in because being able to get that iteration loop of make a change, run the test, make another change, run the test again. That's a really powerful one to refine. The other thing probably we're saying is take a look at your own workflow and look at what's somewhat painful and then Google, like, how do I get better at that? And the Internet will have things to say on that front. +I definitely agree with what you were saying about the command line. That's a place that is a little bit hostile to folks when they first show up. Like, what is this place, and why is it kind of mean? But it can be refined and honed, and tweaked. And so that's a place, again, fzf as a utility, there is a particular one. Again, not quite a keyboard shortcut, though. It's more of a utility; it's a command, a tool, I don't know. Pipeline some stuff; it'll be fun. +I will somewhat back out of what I said earlier, though, of I don't recommend that folks try and push on this too much early on. And the reason I'll say that is a while back, I taught a cohort of Metis, which was the bootcamp that thoughtbot was involved in many, many years ago. Uniformly in each cohort that I at least knew about, the instructor started with that ethos of like, okay, we're going to be up here and demoing things. We're using this thing called Vim. It's weird. Don't worry about it, though. You don't need to learn that. You shouldn't learn that. You should focus on the Rails and the Ruby and JavaScript that we're teaching you. That's the focus. +But essentially, without fail, the students were like, "Yeah, but that thing looks cool. Tell us more about that thing." And so they ended up, these are the folks who designed the course before I started teaching it, they ended up bringing that in as like this is a Friday show and tell sort of thing. All right, we're going to tell you about Vim because everybody keeps asking about it. +And then most of the students ended up using Vim because watching the way someone moves in Vim if you've not seen it and if you're not familiar with that, you're like, wow, you're just moving around the file like magic. It's amazing. And that was certainly my experience before I used Vim. And watching someone using, I'm just like, wow, okay, I want that though. That's the thing that I need. So there's this delicate line of like, I would recommend ignoring this. But I get that if you see that, you're like, I would be so much more efficient if I could use that, and it's true to a certain extent. +So yeah, my recommendation would be don't do that. But most folks that I've seen are like, I would like to get better at these tools, and I totally get that. And I've obviously spent a lot of my own personal time [laughs] getting there. So I feel like I'm a do as I say, not as I do, maybe sort of thing. [laughs] It's roughly the space that I'm coming from right now. And I don't love being in that space, but apparently, it's where I find myself in this moment. +STEPH: That feels like a nice thing to share, though, because that is something that you've really enjoyed and cultivating that craft, and then sharing that and creating videos and content around it. So that totally makes sense that you can say, like, this is something I enjoy, and I have found it productive and helpful. Maybe sometimes you negotiate how productive it is. +CHRIS: Jury is out. +STEPH: [laughs] You've enjoyed it. And so it's something that you've chosen to invest in, but you don't feel it's critical to anybody else and their career or their path that they should invest in it. It does make sense that from a teacher-student perspective that, you're going to want to emulate what your teacher is doing. +So in the past, when I've taught very beginner-friendly intro to web development classes, so I would say much earlier than a junior dev, I always made sure to use VS Code or whatever editor I was using with them because I wanted to mimic exactly what they were going to do and have that same environment versus showing them something completely different and then expect them to translate. So there could be some parallelisms there as well if you're working with a junior developer that you want to cater to an environment that they can work with and feel comfortable and grow with versus showing them all of the fancy trickery that you can do in your particular setup. +CHRIS: Another data point in Steph is a better person than me. +STEPH: Sure, I'll take it. [laughter] There was also an interesting part of the question about what's so powerful that can explain to juniors why it's so important to know these keyboard shortcuts? And the only thing I could come up with because, again, I don't think it's super important for junior devs to learn keyboard shortcuts...but for the stuff that we do think is important around becoming familiar with your editor, making your terminal more friendly, for that stuff, I think a lot of it comes down to..., or the best reason I can think of is for your health. +Because it's been known that there's an increased risk of RSI the more that you switch between your keyboard and your mouse. So if you can use more keyboard shortcuts and use less or place less strain on your wrist and fingers by having to switch from your mouse to your keyboard, then I think that's the best reason. I mean, sure, productivity and feeling like a wizard those are cool reasons, but your health is really the only important reason. I just realized I used an initialism, but I didn't provide the definition for it. So for anyone that's not familiar, RSI stands for Repetitive Stress Injury. +CHRIS: It's interesting that you highlight the health aspect and RSI in particular because it's not something that I think about, but I think is definitely a benefit that I've had and what I like about modal editing and what I like about Vim. I think I tend to think about it in a different way, or it's the same idea but rotated around 180 degrees or something where my ability to do something quickly is not important in and of itself. But my ability to stay in context when I've figured out the change that I need to make that matters to me immensely. +And so what you're talking about of like being able to move quickly between files, being able to run the tests, being able to determine if the change that I made was, in fact, the correct change I care immensely about that. Because typing is not the bottleneck is a phrase that gets thrown around, and I like that phrase because it's true. It's not about just being faster at the keyboard and being an elite hacker typing all day long. The hard part is the thinking. But once I've done that, I want to get that thought out of my head and into the code as quickly as possible, as directly as possible. +And having efficient tooling and the ability to work with that tooling and move between files and run the tests and all of that is critically important to me for that reason, not because any individual change needs to be made that quickly but because once I've done the hard part of the thinking, then I want to get it out of my head and into my hands and then into the editor. +So now I think I've completely contradicted myself, or I've just slowly moved around this question of like, I don't think you should. Well, maybe you should, you should definitely is, I think, the three different stances that I've taken. But I do kind of believe that that should be something that changes over time in your career. So maybe I've been consistent if you give me that lens. +STEPH: That's what's fun about these listener questions. They take us on journeys, and I love that answer. I love that it's more about the staying in context that then helps you feel so productive. It's not just a productivity goal that you're looking for. But it is more for your context that that way, if you know there's a change that you want to make and you don't feel held up by all these other little things that are then preventing you from getting whatever it is you're excited to get done, getting it done. +But speaking of shortcuts, there is one that I just learned recently that's probably a pretty common one, but I haven't used it. I happened to stumble upon it. So if you're in your browser, you can open up a new tab, Command+T; I'm on a Mac. So you can do Command+T and open a new tab. +But there have been many times where I've accidentally closed a tab, or I've had a couple open, and I clicked the little close on the wrong one, and I'm like, no. And then I have to figure out where I was or go back to my history. But there's a shortcut for that, and it is Command+Shift+T, and that will reopen the tab that you accidentally closed. Didn't know that, learned that today. I'm going to lock that one away because that should be helpful. +CHRIS: The best way to lock it away is to explain it to others. So now that you've done that, this one's yours forever. Whereas everyone else hearing it, you got to try it a few times before it'll be yours forever, but, Steph, you're good now. +STEPH: Or spin up your own podcast and then share your keyboard shortcuts so that you can lock it away. [laughs] +CHRIS: I've observed that to be the easiest way to instill any learnings deeply within my brain. +STEPH: On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + BIG NEWS! Steph's expecting a baby boy! 🍼🎉

+ +

Aaaand unfortunately, the rest of the show isn't nearly as exciting. Chris talks about admin pagination using Pagy, and Steph wants to delete some code and is nervous that she's going to break something.

+ +

They answer a listener question from Slash, who asks, "What are the first keyboard shortcuts you teach junior devs?"

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Let's go. Oh man, now all I can think of is the...but what's his face? The quarterback for The Patriots formerly. Oh my God, I can't remember his name.

+ +

CHRIS: Tom Brady?

+ +

STEPH: [laughs] Thank you. Tom Brady. I wanted to say Brad Pitt, but I'm like, that's not right. [laughs]

+ +

CHRIS: See, I thought of the musical...well, I think it's a musical, Encanto. Have you watched Encanto?

+ +

STEPH: Oh, I love Encanto.

+ +

CHRIS: It's so good.

+ +

STEPH: We Don't Talk About Bruno, no, no, no!

+ +

CHRIS: We Don't Talk About Bruno but...it was my wedding day.

+ +

STEPH: But also Luisa Song, that's actually a good one too.

+ +

CHRIS: Luisa Song that we have now listened to the soundtrack a lot of times, and we've only watched the movie twice, once ourselves and then once with our niece and nephew. That is the order it happened in as well, just to be clear. [laughs] But yeah, it's good, lots of slaptitude to all the music and the overall movie and really just fantastic work. Lin-Manuel Miranda does good stuff.

+ +

STEPH: Super good. I have to bring back closure to my Tom Brady confusion, though.

+ +

CHRIS: Yeah, what was that? [laughs]

+ +

STEPH: [laughs] Now when I say the let's go, I think it was the Hertz commercial where he said, "Let's go," and he was impatient. I don't know if you've seen it. But marketing works, and now it's in my brain, and I hate it. [laughs]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? I got some stuff, some tech things, and whatnot to ramble about, but frankly, much less interesting. What's new in your world, Steph?

+ +

STEPH: I do have some news, and I have some exciting news. So Tim and I, we are expecting our first child, hooray!

+ +

CHRIS: Yay!

+ +

STEPH: [laughs] We found out over Christmas or around the holiday. So depending on when this airs, but I'm around 14-15 weeks long. And it's tough. Growing a little human is tough. And it's been quite an adventure. And thankfully, I've got some friends to lean on and talk to through the process. But yes, that's my big news. We're going to have our first child. And oh, we also found out recently the sex of the child, and we found out we're going to have a baby boy, which is very exciting.

+ +

CHRIS: Well, that is so wonderful. I'm so happy for you. And on behalf of the entire Bike Shed audience, I think it's very easy for me to carry forward their best wishes. But this is absolutely wonderful. And I hope you didn't mind me redirecting the questioning right back at you at the start of this episode because this seemed more important than any tech nonsense I'm going to ramble about.

+ +

STEPH: Well, and you've been in the know for quite some time. And so we've been keeping it hush-hush until it felt like the right time to share. And this feels like the right time to go ahead and share. So there might be some interesting episodes up ahead where I get to complain and talk about this some more on the mic [laughs] since I have been keeping it quiet, but now I can talk about it more publicly.

+ +

CHRIS: Absolutely. I think this has been decidedly missing from The Bike Shed content in the six, seven years that this show's been going. So yeah, let's sell some truths.

+ +

STEPH: Bike Shed baby, that'll be one of our topics for sure. [laughs] But yeah, that's some of my big, exciting news. I'm going to kick it back to you since you were so kind to let me lead. What's going on in your world?

+ +

CHRIS: Back to me. I'm going to talk about admin pagination. So it really felt wrong to me that I'll be like, let me talk about pagination for a while. Also, what's up? So that said, now that we have shared the wonderful, exciting news, I can talk about the mundane realities of pagination. So yeah, I'm going to try and tell this one in a story to make it more interesting. So we have an admin page. It lists out the users of our application, as is so often the case.

+ +

And we hit that wonderful place where the page became wildly unreliable because we had so many people sign up for the application; yay! Very exciting. I feel like it's a meaningful milestone to get to where we're like, oh yeah, I guess we have to add pagination to the admin. Unfortunately, I picked this one up as, just like, this should be a quick, easy thing. This will be fun.

+ +

Coding, you know, I've gone back and forth on individual weeks where I have space in my schedule for coding, and then sometimes I find it difficult. And I'm trying to not pick up larger, more critical pieces of work. But this one seemed like a perfect little pickup. I'm just going to grab this, and I'm just going to quickly bang out some pagination, and the admin team will be so excited. Everything's going to be wonderful. Smash cut to that did not work out so great.

+ +

So I tried to introduce pagination using the Pagy gem, which I had not used before, but it's good. It seemed useful. And in particular, I'd seen an example from another Inertia Rails application that was using Pagy, and I was like, oh, cool, I'll just crib what they're doing. Because basically, we need to both get the data for the users and then serialize down the pagination data, the metadata about pagination. What page are we on? How many pages are there? Is there a next page? Is there a previous page? All of that kind of stuff. We need to serialize that down to the front end, and then use that to build a little pagination UI.

+ +

So like, they're using Pagy, and it does seem to do a good job of yielding both of those pieces of data to me, so both the recordset that it's paginated down to and the metadata about pagination. But unfortunately, when I first tried to use it, I ran into a wall where our user page basically just lists out the user. At the top, it has a little search bar, so you can type in name, or email, or ID. And then there's a little drop-down for the account status. What's the status of this user? So we can filter down to active accounts or onboarding accounts or that sort of stuff. Running the search, everything went fine.

+ +

When I went to filter down, suddenly it broke, and that was sad. So I went and chased it down. Pagy was throwing an error that it couldn't work with the collection that it was working with. And the reason was our admin user query object was iterating over the objects in Ruby land to do the filtering, which was very sad. So it turned out that the admin user query object, when it needed to do that filtering based on status, it was actually iterating through all the records and filtering them out using select or reject, whichever side. I forget which way it was implemented. But either way, it was iterating through the entire collection.

+ +

And so, Pagy, like most pagination things, tries to use offset-based pagination and database queries. So OFFSET LIMIT, that combination of things allows you to move through a recordset pretty easily. This is setting aside the idea of cursor-based pagination, which I've never fully understood or implemented, but let's just stick with OFFSET and LIMIT because they're going to get us what we need in this particular case. But by virtue of the fact that we're actually working with that recordset, turning it into an array, getting all of the records, it was less efficient than it needed to be. But it also meant that we didn't have an ActiveRecord relation that we could do this with.

+ +

And so then began the adventure of like, okay, this should be easy. I'll just turn it into a database query, except the account status was implemented as a method spread across a few models that looked at a value and then returned something, and that's why it was doing this in-memory filtering. But this is a classic case of I just want to add pagination. It will be super easy. Never mind, let me undertake a fundamental refactoring to the entire application and unify the idea of account status across user and the background object and this other object.

+ +

And then once that giant refactoring PR lands and I deal with the fallout of how this broke analytics and other pages in the app...it was a good thing. It was necessary. That was a mess, and we knew that. Fixing that was a good thing to do not just for the pagination but for actually unifying all of those ideas. Then once I landed that refactoring PR, oh, it's so easy to put in the pagination. [laughs] Just like, oh yeah, just paginate. That'll be great.

+ +

STEPH: You got back to the happy place of where it was easy again.

+ +

CHRIS: Took me like a week and a half to do the refactoring PR, though, partly because I was in and out on it. I couldn't give it my full focus. But there was definitely a morning where I was like, oh yeah, I'm going to add pagination to the admin UI. And the admin team was like, that's fantastic. We're very excited. A week and a half later, I was like, I'm sorry, I finally got to it, though. It's really good, though, right?

+ +

STEPH: I changed a bunch of things that you can't tell that I changed, but I promise it's a lot better. So now I can actually implement the change that you want to see. Well, I'm glad you walked away with a win because I've definitely been in the space where I have entered the refactor world and walked away with an L and realized that it's something that either wasn't worth tackling at the time or was just too challenging.

+ +

CHRIS: Oh yeah, I've definitely had that. And I think if it were a different shape of refactoring that were necessary to support this, I probably would have backed away, but because it was fundamental data model cleanup that needed to happen under the hood, I was like, that feels right. We should be doing this anyway. I'm also a big believer in dealing with ActiveRecord relations. So for anyone that's not familiar with the way ActiveRecord works, query evaluation is lazy. And so you can say user.where first name, blah. And that returns an unevaluated query, the idea of a query in the future, AKA an ActiveRecord relation.

+ +

And you can keep chaining on to that and building new relation. So you can say .where this thing and then pass that return object to something else, which then chains on another thing .joins to something else and then filter on an aspect of that. But again, we're not going to evaluate the query until we need it, typically until we iterate through the records that are part of it. And so, this is one of those things that I have, over time, slowly worked on and refined. And this is a skill area that I continually find value in investing in.

+ +

Again, I'll reference the wonderful Advanced ActiveRecord Querying course on Upcase that Joe Ferris hosted, and then I got to be a participant in, and still, I'm learning bits from that one years later. But the idea of really understanding what we can do with the database layer and then how we can reflect that in the ActiveRecord query syntax.

+ +

And then ideally, I have this motto in my head, which is just stay in relation land for as long as you possibly can. The minute you type .to_a to coerce it into an array or something like that, you have perhaps solved the immediate problem that you have, but at what cost? I ask, at what cost? The answer is a very big cost. You can't do other cool stuff after that.

+ +

STEPH: I'm intrigued how you refactored it because when you're talking about having the status, in my mind, I was presuming that it was a database column on one of the models. But then you'd mentioned it's not and that it's scattered across. So how did you refactor that and so then you could stay in relation land?

+ +

CHRIS: Primarily, we pushed the logic. So, unfortunately, it was spread across a few different objects. That was one complicated thing. So the idea of a status was spread across a few different spots actually in a few different models. So one thing was just to unify them all into one enum on the canonical record that should really own this idea. And then, really, it was to push it down into the database. So that was part of the work.

+ +

We also recognized that we had done not a great job with the implementation of the enum and with the naming of the key and the value in that enum in terms of how it was implemented in Rails. So there was a bunch of confusion. There was basically just a bunch of places where we had been less intentional than we probably should have. So mostly, it was just pushing all of that together and down into the database. And then where the status changes at any point in the application, we're just updating that column in the database, and then everything else can just happily work with that value.

+ +

STEPH: Got it. Yeah, that sounds great. Thanks.

+ +

CHRIS: You're welcome. But yeah, it really was a case of like that PR to refactor was a bit of a slog, if we're being honest. It was not fun. I was scared I was going to break stuff. I had to be very intentional with it. But once I was on the other side, then I got to have a query object, which is a lot of fun. I love writing those.

+ +

And I got to build pagination in Inertia, which is also one of those things that I really love. This is a place where Inertia really shines. It's incredibly performant. It allows you to do all of this stuff but in a familiar Rails way but yet still have fancy UI on the front end and just an intersection of some of my favorite things. So the refactoring both paid off in terms of what we got in the application but also was just fun at the end. Well, not the refactoring; the thing that came after the refactoring was fun.

+ +

STEPH: Nice. Well, speaking of being nervous about breaking things, I am feeling very determined right now where I want to delete some code. And I have that nervousness around I'm going to break something. But I've spent enough time with this code to feel confident that it's not truly in use. But knowing the exact entry point for that code is part of the CI script process. So I don't have full control over the entry points. It's something that I'm having to coordinate with another team to verify, like, hey, I'm pretty sure it's a script that's never called and never used, or at least this particular path we're not passing these particular flags to the script.

+ +

And going through the code caused enough confusion for me that if I can simplify this and get rid of that code, I'd really like to. So I'm at that point where I'm feeling good. I'm going to issue a change that deletes the code. But there's definitely a part of me that's nervous because it's one of those like, somewhere someone could be running this script on their machine locally. Or they could be using it as part of a different build process that I'm not aware of, which worst-case, then we realize something breaks, and then we have to roll it back.

+ +

But it feels like one of those important I'm going to do it while I've got the context. Let's delete the code. Let's see what breaks. Someone mentioned to me earlier there's the idea of the screen test where you delete something, and then you just wait, and you see who starts screaming. [laughs] I was like, yeah, that's exactly what I want to do. I've done more validation upfront. I don't want anybody to scream. But that's essentially the metric that I'm then going to go off of once we do merge this in and see how it goes.

+ +

But it felt like one of those interesting conversations with myself and someone else that was then looking at it with me where we could easily leave it. We could just walk away. Because I saw this code while I was working on something else, and then I really needed to assess whether I needed to alter this code as well or whether I could leave it alone. And I've decided I could leave it alone for this reason.

+ +

So it's one of those moments of like, okay, well, I could just walk away. I've done the thing that I needed to do for my change. But it feels important to go ahead and follow-through that while I have all of this context. So let's just go ahead and delete it, so someone else doesn't have to build up all that context.

+ +

CHRIS: As you're describing this, I'm sort of thinking of my own career arc as a developer. And early on, I'd just be like, it's fine, we'll just change it now. Nothing will go wrong. And then, obviously, something goes wrong. And slowly, over time, I've built up enough battle wounds from that that I was like, you know what? I'm hesitant to change it. I'm a little scared. What if we break production? And so then, there was a period of a couple of years where I would probably be more hesitant to change things.

+ +

And then eventually I got to the place where I'd seen the cost of not changing the thing when you have the context and letting the less correct implementation or the incorrect domain modeling sit and grow and become worse over time, and then the deep pain that you can feel down the road. And so now I'm like yeah, no, we're probably going to feel some pain on this change. Somebody is going to yell, but we should do it, and that's it. And I like thinking about that arc of just brazen confidence to oh God; everything's terrible to a different type of confidence. Like, yeah, I know something is going to break. But sometimes you got to crack some eggs, you know.

+ +

STEPH: And it's one of those areas where if we do find out something breaks and someone reports like, "Oh, this is really critical, and you took this away from me," then that's great, at least now I've got validation we know where it's used. And then we can; I don't know, maybe somewhere document that somehow or at least we don't even have to document it. But we just at least know that this is a valid code path that needs to be supported, and then I'll feel better about that.

+ +

Versus in this world right now, I'm in the I don't think this is important, but I don't have solid proof that it's not important, but I'm not going to treat it important. And that feels like the worst place to be. I want to know if this is valid or not. So this will help push us in that direction. But yeah, I like that arc that you described. I can definitely relate to that.

+ +

CHRIS: I definitely share the hesitancy and the worry that like, man, is this going to silently break something that someone relies on? But if that's true, then that means our test suite is missing something. If this is a critical code path and I could just delete it, and the test suite is like, cool, that seems fine, then we have a gap in our code coverage.

+ +

And I don't mean code coverage in the percentage metric; I mean it in the an important thing is not enforced by the test suite. And so it's a complicated and messy way to find out what's missing from our test suite, but it is a way. Just remove it and see then what happens. And then we backfill in the test suite to say, "Oh gosh, we should have had that. Deleting that was bad."

+ +

STEPH: So I absolutely agree with what you're saying. This particular scenario is a little tricky because the entry point isn't a traditional user-driven action or something that I feel more concrete that I can test a user flow even if it had test coverage, which it doesn't right now. But even if it had test coverage, it would be part of our CI process then calls this script, and then we expect the script to behave and respond as expected. But even then, if we had that test, we could still have unused code. It could still be a path that just doesn't need to be supported.

+ +

I guess as I'm saying this, that could be true of a user flow as well. I just talked myself into that; cool. [laughs] Yeah, it's one of those even if we had tests that wouldn't give me the full confidence to know whether we have a valid path or not, that needs to be supported. So it feels a bit tricky in that regard. Because I am so used to then relying on my tests to help me know that yes, this is something that's important to the application or not. And in this case, I don't think that actually helps me.

+ +

I think honestly, at this point, it's talking to people who have built a lot of the infrastructure in their CI system to say, "Hey, can you help me track down? I've looked at all the places that I know to look. I even issued a change that raises." So if that script was getting called, then something in the CI infrastructure should have blown up to let me know. So I've taken all the incremental steps that I can to see if anything breaks. And so far, nothing's breaking yet, but we just won't know until it's gone.

+ +

Comparing this to previous situations, it does feel like one of those areas where if I was uncertain about if something is in use, that looking at the test is always helpful but then also having a product manager to go to because then that person can confirm yes, this is something that I'm certain that someone still uses, or we need to support. Or they can say, "You know what? Even if it is something that someone is using, we don't wish to support this feature anymore, and we'd like to get rid of it." It feels like I'm in that space. But there's not a clear product manager.

+ +

Now, for this one, there is someone very knowledgeable who helped build a lot of this system that I can go to. So in effect, they are acting as that person that can then let me know to say yes; even though we have code to support this path, I'm pretty sure we don't want to support it anymore, and we can get rid of it. So that's ultimately what's given me the confidence to move forward with the change.

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

Pivoting just a bit, we have a listener question. And this question comes from Slash. And they wrote in, "What are the first keyboard shortcuts you teach junior devs? What is so powerful that can explain to juniors why it's important to know them?" Yeah, all right. I have thoughts. Chris, do you want me to kick us off, or do you want to kick us off?

+ +

CHRIS: This is an interesting one because, for folks that have seen some of my internet movements, you will know that I am a fan of the keyboard and shortcuts there. And I like Vim; I like Tmux. I do not like things that require me to use my mouse. And so, my answer might be somewhat surprising, but I actually try to avoid this. I think the trap of productivity enhancements and whatnot can be, especially early on, a way to distract from the real work.

+ +

There's so much as a junior dev to learn and, especially if you're a web developer, and I'm imagining this is potentially like full-stack web dev. But even if you're a front-end developer, there's a just world of complexity that you have now opened up. You need to understand about HTTP, and CSS, and HTML, and JavaScript, and TypeScript, and there are so, so many things. And so if there's anything we can take off of our plates at that point, I think that's really useful.

+ +

So my very clear suggestion to folks that are new is just use VS Code seems like it's great. It's got a ton of stuff built-in. It's going to work well, and you can get really far with it. And there's a point in time that you will get to where you feel like maybe that tool is slowing you down, although my understanding is VS Code is a really impressive piece of technology. And so if you're not as deeply drawn to keyboard-only as I am, then VS Code you can keep growing within that. There are so many enhancements and customizations and whatnot that you can do there.

+ +

But it's weird that my answer is kind of like none or deflect the question and say, do these cutters around Ruby and Rails and JavaScript or whatever the language or framework or whatever it is that you're working in. But that's my first approximation. I probably have a more real set of answers. But I'm interested in your response to that or your thoughts on that, Steph.

+ +

STEPH: I love that. I think you make such a good point that you are entering a world where there's so much to learn that I don't think this is of high importance. It is something that you can cultivate over the years but not something that you need to focus on. And when you highlighted using VS Code instead of saying our de facto like Vim, which is something that you and I love, I thought about that because Tim, my husband, went through a coding bootcamp recently. And I don't know if I'd shared this, but he just got his first job as a junior dev. So that's incredibly exciting.

+ +

And when we were talking about editors to use, VS Code was one of my top ones. I just know it's well built; it's popular. It does a lot for you. And it's just that way; you can focus on everything else that you mentioned that junior devs are often having to focus on that then at that point, it really becomes all the shortcuts for you to learn.

+ +

It's just get to know your editor. Understand how to do the fuzzy search for files or a specific method. How do you split windows? How do you make it easy to toggle between running your testing code? But I do think it's important to become familiar with those shortcuts and commands so that way you feel very competent and productive in your editor. Whatever your editor is, just get to know those commands.

+ +

To go a bit broader with it, I do think there are some things that are really helpful to know. And I'm also working off the assumption that if you're a junior dev, you probably already know the basics. You know the copying and pasting, refreshing a page, and undoing a change. So some of the keyboard shortcuts or tooling that would be more helpful, in my opinion, is as learning your editor, learn some terminal shortcuts. So like pressing up to rerun the last command, I think that's probably one of the first things that if I don't see someone doing that, I would remind them or let them know that they can do.

+ +

I also think it's really awesome to have a command-line tool like fzf that lets you find and filter files or search through your command history because I use that all the time. So I'm constantly just searching through my command history in my terminal so I can rerun commands versus having to remember what to type. And then also, I mean, there are a couple of basic browser shortcuts, so navigating between tabs, opening new tabs.

+ +

And then the big one is Git. If you're using Git for your job, spend time with Git, and that doesn't really fall into the whole keyboard shortcuts. That's a whole different topic. So I'm totally cheating here. But I think it's important enough to focus on that over the keyboard shortcuts is get good at writing commit messages, amending changes, viewing a history, and how to rebase, things like that.

+ +

CHRIS: I think the list that you gave there is actually a really practical one of, like, learn how to move around within your editor and in between the files because that's going to be a thing that you're just constantly doing. And so I'm also a huge fan of fuzzy finding, so Ctrl+P in the Vim world or fzf that you listed as a more generic utility that has it. I know VS Code has a command palette where you can fuzzy search for files and different variations there. And that is such a nice way to work.

+ +

I don't actually want keyboard shortcuts, if we're being honest. This is maybe a somewhat heretical thing, but I want modes. I love Vim's modes, and there's a whole language there. I made a YouTube video a while back about it because I believe in it so strongly. But it's that idea of like, if I have to remember these arcane movements of my fingers, that's not fun for me.

+ +

I want the computer to learn me rather than me it. And so fuzzy finding anything, being able to type any substring of the things that you're matching against is such a powerful way to interact with stuff that's like, it's not me knowing the magic key command to do something; it's the computer understanding me a little bit better.

+ +

You also listed being able to run a test file or an individual test. I love that one. That is something that I use constantly. And so that's one that I think would be worth investing in because being able to get that iteration loop of make a change, run the test, make another change, run the test again. That's a really powerful one to refine. The other thing probably we're saying is take a look at your own workflow and look at what's somewhat painful and then Google, like, how do I get better at that? And the Internet will have things to say on that front.

+ +

I definitely agree with what you were saying about the command line. That's a place that is a little bit hostile to folks when they first show up. Like, what is this place, and why is it kind of mean? But it can be refined and honed, and tweaked. And so that's a place, again, fzf as a utility, there is a particular one. Again, not quite a keyboard shortcut, though. It's more of a utility; it's a command, a tool, I don't know. Pipeline some stuff; it'll be fun.

+ +

I will somewhat back out of what I said earlier, though, of I don't recommend that folks try and push on this too much early on. And the reason I'll say that is a while back, I taught a cohort of Metis, which was the bootcamp that thoughtbot was involved in many, many years ago. Uniformly in each cohort that I at least knew about, the instructor started with that ethos of like, okay, we're going to be up here and demoing things. We're using this thing called Vim. It's weird. Don't worry about it, though. You don't need to learn that. You shouldn't learn that. You should focus on the Rails and the Ruby and JavaScript that we're teaching you. That's the focus.

+ +

But essentially, without fail, the students were like, "Yeah, but that thing looks cool. Tell us more about that thing." And so they ended up, these are the folks who designed the course before I started teaching it, they ended up bringing that in as like this is a Friday show and tell sort of thing. All right, we're going to tell you about Vim because everybody keeps asking about it.

+ +

And then most of the students ended up using Vim because watching the way someone moves in Vim if you've not seen it and if you're not familiar with that, you're like, wow, you're just moving around the file like magic. It's amazing. And that was certainly my experience before I used Vim. And watching someone using, I'm just like, wow, okay, I want that though. That's the thing that I need. So there's this delicate line of like, I would recommend ignoring this. But I get that if you see that, you're like, I would be so much more efficient if I could use that, and it's true to a certain extent.

+ +

So yeah, my recommendation would be don't do that. But most folks that I've seen are like, I would like to get better at these tools, and I totally get that. And I've obviously spent a lot of my own personal time [laughs] getting there. So I feel like I'm a do as I say, not as I do, maybe sort of thing. [laughs] It's roughly the space that I'm coming from right now. And I don't love being in that space, but apparently, it's where I find myself in this moment.

+ +

STEPH: That feels like a nice thing to share, though, because that is something that you've really enjoyed and cultivating that craft, and then sharing that and creating videos and content around it. So that totally makes sense that you can say, like, this is something I enjoy, and I have found it productive and helpful. Maybe sometimes you negotiate how productive it is.

+ +

CHRIS: Jury is out.

+ +

STEPH: [laughs] You've enjoyed it. And so it's something that you've chosen to invest in, but you don't feel it's critical to anybody else and their career or their path that they should invest in it. It does make sense that from a teacher-student perspective that, you're going to want to emulate what your teacher is doing.

+ +

So in the past, when I've taught very beginner-friendly intro to web development classes, so I would say much earlier than a junior dev, I always made sure to use VS Code or whatever editor I was using with them because I wanted to mimic exactly what they were going to do and have that same environment versus showing them something completely different and then expect them to translate. So there could be some parallelisms there as well if you're working with a junior developer that you want to cater to an environment that they can work with and feel comfortable and grow with versus showing them all of the fancy trickery that you can do in your particular setup.

+ +

CHRIS: Another data point in Steph is a better person than me.

+ +

STEPH: Sure, I'll take it. [laughter] There was also an interesting part of the question about what's so powerful that can explain to juniors why it's so important to know these keyboard shortcuts? And the only thing I could come up with because, again, I don't think it's super important for junior devs to learn keyboard shortcuts...but for the stuff that we do think is important around becoming familiar with your editor, making your terminal more friendly, for that stuff, I think a lot of it comes down to..., or the best reason I can think of is for your health.

+ +

Because it's been known that there's an increased risk of RSI the more that you switch between your keyboard and your mouse. So if you can use more keyboard shortcuts and use less or place less strain on your wrist and fingers by having to switch from your mouse to your keyboard, then I think that's the best reason. I mean, sure, productivity and feeling like a wizard those are cool reasons, but your health is really the only important reason. I just realized I used an initialism, but I didn't provide the definition for it. So for anyone that's not familiar, RSI stands for Repetitive Stress Injury.

+ +

CHRIS: It's interesting that you highlight the health aspect and RSI in particular because it's not something that I think about, but I think is definitely a benefit that I've had and what I like about modal editing and what I like about Vim. I think I tend to think about it in a different way, or it's the same idea but rotated around 180 degrees or something where my ability to do something quickly is not important in and of itself. But my ability to stay in context when I've figured out the change that I need to make that matters to me immensely.

+ +

And so what you're talking about of like being able to move quickly between files, being able to run the tests, being able to determine if the change that I made was, in fact, the correct change I care immensely about that. Because typing is not the bottleneck is a phrase that gets thrown around, and I like that phrase because it's true. It's not about just being faster at the keyboard and being an elite hacker typing all day long. The hard part is the thinking. But once I've done that, I want to get that thought out of my head and into the code as quickly as possible, as directly as possible.

+ +

And having efficient tooling and the ability to work with that tooling and move between files and run the tests and all of that is critically important to me for that reason, not because any individual change needs to be made that quickly but because once I've done the hard part of the thinking, then I want to get it out of my head and into my hands and then into the editor.

+ +

So now I think I've completely contradicted myself, or I've just slowly moved around this question of like, I don't think you should. Well, maybe you should, you should definitely is, I think, the three different stances that I've taken. But I do kind of believe that that should be something that changes over time in your career. So maybe I've been consistent if you give me that lens.

+ +

STEPH: That's what's fun about these listener questions. They take us on journeys, and I love that answer. I love that it's more about the staying in context that then helps you feel so productive. It's not just a productivity goal that you're looking for. But it is more for your context that that way, if you know there's a change that you want to make and you don't feel held up by all these other little things that are then preventing you from getting whatever it is you're excited to get done, getting it done.

+ +

But speaking of shortcuts, there is one that I just learned recently that's probably a pretty common one, but I haven't used it. I happened to stumble upon it. So if you're in your browser, you can open up a new tab, Command+T; I'm on a Mac. So you can do Command+T and open a new tab.

+ +

But there have been many times where I've accidentally closed a tab, or I've had a couple open, and I clicked the little close on the wrong one, and I'm like, no. And then I have to figure out where I was or go back to my history. But there's a shortcut for that, and it is Command+Shift+T, and that will reopen the tab that you accidentally closed. Didn't know that, learned that today. I'm going to lock that one away because that should be helpful.

+ +

CHRIS: The best way to lock it away is to explain it to others. So now that you've done that, this one's yours forever. Whereas everyone else hearing it, you got to try it a few times before it'll be yours forever, but, Steph, you're good now.

+ +

STEPH: Or spin up your own podcast and then share your keyboard shortcuts so that you can lock it away. [laughs]

+ +

CHRIS: I've observed that to be the easiest way to instill any learnings deeply within my brain.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + BIG NEWS! Steph's expecting a baby boy! 🍼🎉

+ +

Aaaand unfortunately, the rest of the show isn't nearly as exciting. Chris talks about admin pagination using Pagy, and Steph wants to delete some code and is nervous that she's going to break something.

+ +

They answer a listener question from Slash, who asks, "What are the first keyboard shortcuts you teach junior devs?"

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Let's go. Oh man, now all I can think of is the...but what's his face? The quarterback for The Patriots formerly. Oh my God, I can't remember his name.

+ +

CHRIS: Tom Brady?

+ +

STEPH: [laughs] Thank you. Tom Brady. I wanted to say Brad Pitt, but I'm like, that's not right. [laughs]

+ +

CHRIS: See, I thought of the musical...well, I think it's a musical, Encanto. Have you watched Encanto?

+ +

STEPH: Oh, I love Encanto.

+ +

CHRIS: It's so good.

+ +

STEPH: We Don't Talk About Bruno, no, no, no!

+ +

CHRIS: We Don't Talk About Bruno but...it was my wedding day.

+ +

STEPH: But also Luisa Song, that's actually a good one too.

+ +

CHRIS: Luisa Song that we have now listened to the soundtrack a lot of times, and we've only watched the movie twice, once ourselves and then once with our niece and nephew. That is the order it happened in as well, just to be clear. [laughs] But yeah, it's good, lots of slaptitude to all the music and the overall movie and really just fantastic work. Lin-Manuel Miranda does good stuff.

+ +

STEPH: Super good. I have to bring back closure to my Tom Brady confusion, though.

+ +

CHRIS: Yeah, what was that? [laughs]

+ +

STEPH: [laughs] Now when I say the let's go, I think it was the Hertz commercial where he said, "Let's go," and he was impatient. I don't know if you've seen it. But marketing works, and now it's in my brain, and I hate it. [laughs]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? I got some stuff, some tech things, and whatnot to ramble about, but frankly, much less interesting. What's new in your world, Steph?

+ +

STEPH: I do have some news, and I have some exciting news. So Tim and I, we are expecting our first child, hooray!

+ +

CHRIS: Yay!

+ +

STEPH: [laughs] We found out over Christmas or around the holiday. So depending on when this airs, but I'm around 14-15 weeks long. And it's tough. Growing a little human is tough. And it's been quite an adventure. And thankfully, I've got some friends to lean on and talk to through the process. But yes, that's my big news. We're going to have our first child. And oh, we also found out recently the sex of the child, and we found out we're going to have a baby boy, which is very exciting.

+ +

CHRIS: Well, that is so wonderful. I'm so happy for you. And on behalf of the entire Bike Shed audience, I think it's very easy for me to carry forward their best wishes. But this is absolutely wonderful. And I hope you didn't mind me redirecting the questioning right back at you at the start of this episode because this seemed more important than any tech nonsense I'm going to ramble about.

+ +

STEPH: Well, and you've been in the know for quite some time. And so we've been keeping it hush-hush until it felt like the right time to share. And this feels like the right time to go ahead and share. So there might be some interesting episodes up ahead where I get to complain and talk about this some more on the mic [laughs] since I have been keeping it quiet, but now I can talk about it more publicly.

+ +

CHRIS: Absolutely. I think this has been decidedly missing from The Bike Shed content in the six, seven years that this show's been going. So yeah, let's sell some truths.

+ +

STEPH: Bike Shed baby, that'll be one of our topics for sure. [laughs] But yeah, that's some of my big, exciting news. I'm going to kick it back to you since you were so kind to let me lead. What's going on in your world?

+ +

CHRIS: Back to me. I'm going to talk about admin pagination. So it really felt wrong to me that I'll be like, let me talk about pagination for a while. Also, what's up? So that said, now that we have shared the wonderful, exciting news, I can talk about the mundane realities of pagination. So yeah, I'm going to try and tell this one in a story to make it more interesting. So we have an admin page. It lists out the users of our application, as is so often the case.

+ +

And we hit that wonderful place where the page became wildly unreliable because we had so many people sign up for the application; yay! Very exciting. I feel like it's a meaningful milestone to get to where we're like, oh yeah, I guess we have to add pagination to the admin. Unfortunately, I picked this one up as, just like, this should be a quick, easy thing. This will be fun.

+ +

Coding, you know, I've gone back and forth on individual weeks where I have space in my schedule for coding, and then sometimes I find it difficult. And I'm trying to not pick up larger, more critical pieces of work. But this one seemed like a perfect little pickup. I'm just going to grab this, and I'm just going to quickly bang out some pagination, and the admin team will be so excited. Everything's going to be wonderful. Smash cut to that did not work out so great.

+ +

So I tried to introduce pagination using the Pagy gem, which I had not used before, but it's good. It seemed useful. And in particular, I'd seen an example from another Inertia Rails application that was using Pagy, and I was like, oh, cool, I'll just crib what they're doing. Because basically, we need to both get the data for the users and then serialize down the pagination data, the metadata about pagination. What page are we on? How many pages are there? Is there a next page? Is there a previous page? All of that kind of stuff. We need to serialize that down to the front end, and then use that to build a little pagination UI.

+ +

So like, they're using Pagy, and it does seem to do a good job of yielding both of those pieces of data to me, so both the recordset that it's paginated down to and the metadata about pagination. But unfortunately, when I first tried to use it, I ran into a wall where our user page basically just lists out the user. At the top, it has a little search bar, so you can type in name, or email, or ID. And then there's a little drop-down for the account status. What's the status of this user? So we can filter down to active accounts or onboarding accounts or that sort of stuff. Running the search, everything went fine.

+ +

When I went to filter down, suddenly it broke, and that was sad. So I went and chased it down. Pagy was throwing an error that it couldn't work with the collection that it was working with. And the reason was our admin user query object was iterating over the objects in Ruby land to do the filtering, which was very sad. So it turned out that the admin user query object, when it needed to do that filtering based on status, it was actually iterating through all the records and filtering them out using select or reject, whichever side. I forget which way it was implemented. But either way, it was iterating through the entire collection.

+ +

And so, Pagy, like most pagination things, tries to use offset-based pagination and database queries. So OFFSET LIMIT, that combination of things allows you to move through a recordset pretty easily. This is setting aside the idea of cursor-based pagination, which I've never fully understood or implemented, but let's just stick with OFFSET and LIMIT because they're going to get us what we need in this particular case. But by virtue of the fact that we're actually working with that recordset, turning it into an array, getting all of the records, it was less efficient than it needed to be. But it also meant that we didn't have an ActiveRecord relation that we could do this with.

+ +

And so then began the adventure of like, okay, this should be easy. I'll just turn it into a database query, except the account status was implemented as a method spread across a few models that looked at a value and then returned something, and that's why it was doing this in-memory filtering. But this is a classic case of I just want to add pagination. It will be super easy. Never mind, let me undertake a fundamental refactoring to the entire application and unify the idea of account status across user and the background object and this other object.

+ +

And then once that giant refactoring PR lands and I deal with the fallout of how this broke analytics and other pages in the app...it was a good thing. It was necessary. That was a mess, and we knew that. Fixing that was a good thing to do not just for the pagination but for actually unifying all of those ideas. Then once I landed that refactoring PR, oh, it's so easy to put in the pagination. [laughs] Just like, oh yeah, just paginate. That'll be great.

+ +

STEPH: You got back to the happy place of where it was easy again.

+ +

CHRIS: Took me like a week and a half to do the refactoring PR, though, partly because I was in and out on it. I couldn't give it my full focus. But there was definitely a morning where I was like, oh yeah, I'm going to add pagination to the admin UI. And the admin team was like, that's fantastic. We're very excited. A week and a half later, I was like, I'm sorry, I finally got to it, though. It's really good, though, right?

+ +

STEPH: I changed a bunch of things that you can't tell that I changed, but I promise it's a lot better. So now I can actually implement the change that you want to see. Well, I'm glad you walked away with a win because I've definitely been in the space where I have entered the refactor world and walked away with an L and realized that it's something that either wasn't worth tackling at the time or was just too challenging.

+ +

CHRIS: Oh yeah, I've definitely had that. And I think if it were a different shape of refactoring that were necessary to support this, I probably would have backed away, but because it was fundamental data model cleanup that needed to happen under the hood, I was like, that feels right. We should be doing this anyway. I'm also a big believer in dealing with ActiveRecord relations. So for anyone that's not familiar with the way ActiveRecord works, query evaluation is lazy. And so you can say user.where first name, blah. And that returns an unevaluated query, the idea of a query in the future, AKA an ActiveRecord relation.

+ +

And you can keep chaining on to that and building new relation. So you can say .where this thing and then pass that return object to something else, which then chains on another thing .joins to something else and then filter on an aspect of that. But again, we're not going to evaluate the query until we need it, typically until we iterate through the records that are part of it. And so, this is one of those things that I have, over time, slowly worked on and refined. And this is a skill area that I continually find value in investing in.

+ +

Again, I'll reference the wonderful Advanced ActiveRecord Querying course on Upcase that Joe Ferris hosted, and then I got to be a participant in, and still, I'm learning bits from that one years later. But the idea of really understanding what we can do with the database layer and then how we can reflect that in the ActiveRecord query syntax.

+ +

And then ideally, I have this motto in my head, which is just stay in relation land for as long as you possibly can. The minute you type .to_a to coerce it into an array or something like that, you have perhaps solved the immediate problem that you have, but at what cost? I ask, at what cost? The answer is a very big cost. You can't do other cool stuff after that.

+ +

STEPH: I'm intrigued how you refactored it because when you're talking about having the status, in my mind, I was presuming that it was a database column on one of the models. But then you'd mentioned it's not and that it's scattered across. So how did you refactor that and so then you could stay in relation land?

+ +

CHRIS: Primarily, we pushed the logic. So, unfortunately, it was spread across a few different objects. That was one complicated thing. So the idea of a status was spread across a few different spots actually in a few different models. So one thing was just to unify them all into one enum on the canonical record that should really own this idea. And then, really, it was to push it down into the database. So that was part of the work.

+ +

We also recognized that we had done not a great job with the implementation of the enum and with the naming of the key and the value in that enum in terms of how it was implemented in Rails. So there was a bunch of confusion. There was basically just a bunch of places where we had been less intentional than we probably should have. So mostly, it was just pushing all of that together and down into the database. And then where the status changes at any point in the application, we're just updating that column in the database, and then everything else can just happily work with that value.

+ +

STEPH: Got it. Yeah, that sounds great. Thanks.

+ +

CHRIS: You're welcome. But yeah, it really was a case of like that PR to refactor was a bit of a slog, if we're being honest. It was not fun. I was scared I was going to break stuff. I had to be very intentional with it. But once I was on the other side, then I got to have a query object, which is a lot of fun. I love writing those.

+ +

And I got to build pagination in Inertia, which is also one of those things that I really love. This is a place where Inertia really shines. It's incredibly performant. It allows you to do all of this stuff but in a familiar Rails way but yet still have fancy UI on the front end and just an intersection of some of my favorite things. So the refactoring both paid off in terms of what we got in the application but also was just fun at the end. Well, not the refactoring; the thing that came after the refactoring was fun.

+ +

STEPH: Nice. Well, speaking of being nervous about breaking things, I am feeling very determined right now where I want to delete some code. And I have that nervousness around I'm going to break something. But I've spent enough time with this code to feel confident that it's not truly in use. But knowing the exact entry point for that code is part of the CI script process. So I don't have full control over the entry points. It's something that I'm having to coordinate with another team to verify, like, hey, I'm pretty sure it's a script that's never called and never used, or at least this particular path we're not passing these particular flags to the script.

+ +

And going through the code caused enough confusion for me that if I can simplify this and get rid of that code, I'd really like to. So I'm at that point where I'm feeling good. I'm going to issue a change that deletes the code. But there's definitely a part of me that's nervous because it's one of those like, somewhere someone could be running this script on their machine locally. Or they could be using it as part of a different build process that I'm not aware of, which worst-case, then we realize something breaks, and then we have to roll it back.

+ +

But it feels like one of those important I'm going to do it while I've got the context. Let's delete the code. Let's see what breaks. Someone mentioned to me earlier there's the idea of the screen test where you delete something, and then you just wait, and you see who starts screaming. [laughs] I was like, yeah, that's exactly what I want to do. I've done more validation upfront. I don't want anybody to scream. But that's essentially the metric that I'm then going to go off of once we do merge this in and see how it goes.

+ +

But it felt like one of those interesting conversations with myself and someone else that was then looking at it with me where we could easily leave it. We could just walk away. Because I saw this code while I was working on something else, and then I really needed to assess whether I needed to alter this code as well or whether I could leave it alone. And I've decided I could leave it alone for this reason.

+ +

So it's one of those moments of like, okay, well, I could just walk away. I've done the thing that I needed to do for my change. But it feels important to go ahead and follow-through that while I have all of this context. So let's just go ahead and delete it, so someone else doesn't have to build up all that context.

+ +

CHRIS: As you're describing this, I'm sort of thinking of my own career arc as a developer. And early on, I'd just be like, it's fine, we'll just change it now. Nothing will go wrong. And then, obviously, something goes wrong. And slowly, over time, I've built up enough battle wounds from that that I was like, you know what? I'm hesitant to change it. I'm a little scared. What if we break production? And so then, there was a period of a couple of years where I would probably be more hesitant to change things.

+ +

And then eventually I got to the place where I'd seen the cost of not changing the thing when you have the context and letting the less correct implementation or the incorrect domain modeling sit and grow and become worse over time, and then the deep pain that you can feel down the road. And so now I'm like yeah, no, we're probably going to feel some pain on this change. Somebody is going to yell, but we should do it, and that's it. And I like thinking about that arc of just brazen confidence to oh God; everything's terrible to a different type of confidence. Like, yeah, I know something is going to break. But sometimes you got to crack some eggs, you know.

+ +

STEPH: And it's one of those areas where if we do find out something breaks and someone reports like, "Oh, this is really critical, and you took this away from me," then that's great, at least now I've got validation we know where it's used. And then we can; I don't know, maybe somewhere document that somehow or at least we don't even have to document it. But we just at least know that this is a valid code path that needs to be supported, and then I'll feel better about that.

+ +

Versus in this world right now, I'm in the I don't think this is important, but I don't have solid proof that it's not important, but I'm not going to treat it important. And that feels like the worst place to be. I want to know if this is valid or not. So this will help push us in that direction. But yeah, I like that arc that you described. I can definitely relate to that.

+ +

CHRIS: I definitely share the hesitancy and the worry that like, man, is this going to silently break something that someone relies on? But if that's true, then that means our test suite is missing something. If this is a critical code path and I could just delete it, and the test suite is like, cool, that seems fine, then we have a gap in our code coverage.

+ +

And I don't mean code coverage in the percentage metric; I mean it in the an important thing is not enforced by the test suite. And so it's a complicated and messy way to find out what's missing from our test suite, but it is a way. Just remove it and see then what happens. And then we backfill in the test suite to say, "Oh gosh, we should have had that. Deleting that was bad."

+ +

STEPH: So I absolutely agree with what you're saying. This particular scenario is a little tricky because the entry point isn't a traditional user-driven action or something that I feel more concrete that I can test a user flow even if it had test coverage, which it doesn't right now. But even if it had test coverage, it would be part of our CI process then calls this script, and then we expect the script to behave and respond as expected. But even then, if we had that test, we could still have unused code. It could still be a path that just doesn't need to be supported.

+ +

I guess as I'm saying this, that could be true of a user flow as well. I just talked myself into that; cool. [laughs] Yeah, it's one of those even if we had tests that wouldn't give me the full confidence to know whether we have a valid path or not, that needs to be supported. So it feels a bit tricky in that regard. Because I am so used to then relying on my tests to help me know that yes, this is something that's important to the application or not. And in this case, I don't think that actually helps me.

+ +

I think honestly, at this point, it's talking to people who have built a lot of the infrastructure in their CI system to say, "Hey, can you help me track down? I've looked at all the places that I know to look. I even issued a change that raises." So if that script was getting called, then something in the CI infrastructure should have blown up to let me know. So I've taken all the incremental steps that I can to see if anything breaks. And so far, nothing's breaking yet, but we just won't know until it's gone.

+ +

Comparing this to previous situations, it does feel like one of those areas where if I was uncertain about if something is in use, that looking at the test is always helpful but then also having a product manager to go to because then that person can confirm yes, this is something that I'm certain that someone still uses, or we need to support. Or they can say, "You know what? Even if it is something that someone is using, we don't wish to support this feature anymore, and we'd like to get rid of it." It feels like I'm in that space. But there's not a clear product manager.

+ +

Now, for this one, there is someone very knowledgeable who helped build a lot of this system that I can go to. So in effect, they are acting as that person that can then let me know to say yes; even though we have code to support this path, I'm pretty sure we don't want to support it anymore, and we can get rid of it. So that's ultimately what's given me the confidence to move forward with the change.

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

Pivoting just a bit, we have a listener question. And this question comes from Slash. And they wrote in, "What are the first keyboard shortcuts you teach junior devs? What is so powerful that can explain to juniors why it's important to know them?" Yeah, all right. I have thoughts. Chris, do you want me to kick us off, or do you want to kick us off?

+ +

CHRIS: This is an interesting one because, for folks that have seen some of my internet movements, you will know that I am a fan of the keyboard and shortcuts there. And I like Vim; I like Tmux. I do not like things that require me to use my mouse. And so, my answer might be somewhat surprising, but I actually try to avoid this. I think the trap of productivity enhancements and whatnot can be, especially early on, a way to distract from the real work.

+ +

There's so much as a junior dev to learn and, especially if you're a web developer, and I'm imagining this is potentially like full-stack web dev. But even if you're a front-end developer, there's a just world of complexity that you have now opened up. You need to understand about HTTP, and CSS, and HTML, and JavaScript, and TypeScript, and there are so, so many things. And so if there's anything we can take off of our plates at that point, I think that's really useful.

+ +

So my very clear suggestion to folks that are new is just use VS Code seems like it's great. It's got a ton of stuff built-in. It's going to work well, and you can get really far with it. And there's a point in time that you will get to where you feel like maybe that tool is slowing you down, although my understanding is VS Code is a really impressive piece of technology. And so if you're not as deeply drawn to keyboard-only as I am, then VS Code you can keep growing within that. There are so many enhancements and customizations and whatnot that you can do there.

+ +

But it's weird that my answer is kind of like none or deflect the question and say, do these cutters around Ruby and Rails and JavaScript or whatever the language or framework or whatever it is that you're working in. But that's my first approximation. I probably have a more real set of answers. But I'm interested in your response to that or your thoughts on that, Steph.

+ +

STEPH: I love that. I think you make such a good point that you are entering a world where there's so much to learn that I don't think this is of high importance. It is something that you can cultivate over the years but not something that you need to focus on. And when you highlighted using VS Code instead of saying our de facto like Vim, which is something that you and I love, I thought about that because Tim, my husband, went through a coding bootcamp recently. And I don't know if I'd shared this, but he just got his first job as a junior dev. So that's incredibly exciting.

+ +

And when we were talking about editors to use, VS Code was one of my top ones. I just know it's well built; it's popular. It does a lot for you. And it's just that way; you can focus on everything else that you mentioned that junior devs are often having to focus on that then at that point, it really becomes all the shortcuts for you to learn.

+ +

It's just get to know your editor. Understand how to do the fuzzy search for files or a specific method. How do you split windows? How do you make it easy to toggle between running your testing code? But I do think it's important to become familiar with those shortcuts and commands so that way you feel very competent and productive in your editor. Whatever your editor is, just get to know those commands.

+ +

To go a bit broader with it, I do think there are some things that are really helpful to know. And I'm also working off the assumption that if you're a junior dev, you probably already know the basics. You know the copying and pasting, refreshing a page, and undoing a change. So some of the keyboard shortcuts or tooling that would be more helpful, in my opinion, is as learning your editor, learn some terminal shortcuts. So like pressing up to rerun the last command, I think that's probably one of the first things that if I don't see someone doing that, I would remind them or let them know that they can do.

+ +

I also think it's really awesome to have a command-line tool like fzf that lets you find and filter files or search through your command history because I use that all the time. So I'm constantly just searching through my command history in my terminal so I can rerun commands versus having to remember what to type. And then also, I mean, there are a couple of basic browser shortcuts, so navigating between tabs, opening new tabs.

+ +

And then the big one is Git. If you're using Git for your job, spend time with Git, and that doesn't really fall into the whole keyboard shortcuts. That's a whole different topic. So I'm totally cheating here. But I think it's important enough to focus on that over the keyboard shortcuts is get good at writing commit messages, amending changes, viewing a history, and how to rebase, things like that.

+ +

CHRIS: I think the list that you gave there is actually a really practical one of, like, learn how to move around within your editor and in between the files because that's going to be a thing that you're just constantly doing. And so I'm also a huge fan of fuzzy finding, so Ctrl+P in the Vim world or fzf that you listed as a more generic utility that has it. I know VS Code has a command palette where you can fuzzy search for files and different variations there. And that is such a nice way to work.

+ +

I don't actually want keyboard shortcuts, if we're being honest. This is maybe a somewhat heretical thing, but I want modes. I love Vim's modes, and there's a whole language there. I made a YouTube video a while back about it because I believe in it so strongly. But it's that idea of like, if I have to remember these arcane movements of my fingers, that's not fun for me.

+ +

I want the computer to learn me rather than me it. And so fuzzy finding anything, being able to type any substring of the things that you're matching against is such a powerful way to interact with stuff that's like, it's not me knowing the magic key command to do something; it's the computer understanding me a little bit better.

+ +

You also listed being able to run a test file or an individual test. I love that one. That is something that I use constantly. And so that's one that I think would be worth investing in because being able to get that iteration loop of make a change, run the test, make another change, run the test again. That's a really powerful one to refine. The other thing probably we're saying is take a look at your own workflow and look at what's somewhat painful and then Google, like, how do I get better at that? And the Internet will have things to say on that front.

+ +

I definitely agree with what you were saying about the command line. That's a place that is a little bit hostile to folks when they first show up. Like, what is this place, and why is it kind of mean? But it can be refined and honed, and tweaked. And so that's a place, again, fzf as a utility, there is a particular one. Again, not quite a keyboard shortcut, though. It's more of a utility; it's a command, a tool, I don't know. Pipeline some stuff; it'll be fun.

+ +

I will somewhat back out of what I said earlier, though, of I don't recommend that folks try and push on this too much early on. And the reason I'll say that is a while back, I taught a cohort of Metis, which was the bootcamp that thoughtbot was involved in many, many years ago. Uniformly in each cohort that I at least knew about, the instructor started with that ethos of like, okay, we're going to be up here and demoing things. We're using this thing called Vim. It's weird. Don't worry about it, though. You don't need to learn that. You shouldn't learn that. You should focus on the Rails and the Ruby and JavaScript that we're teaching you. That's the focus.

+ +

But essentially, without fail, the students were like, "Yeah, but that thing looks cool. Tell us more about that thing." And so they ended up, these are the folks who designed the course before I started teaching it, they ended up bringing that in as like this is a Friday show and tell sort of thing. All right, we're going to tell you about Vim because everybody keeps asking about it.

+ +

And then most of the students ended up using Vim because watching the way someone moves in Vim if you've not seen it and if you're not familiar with that, you're like, wow, you're just moving around the file like magic. It's amazing. And that was certainly my experience before I used Vim. And watching someone using, I'm just like, wow, okay, I want that though. That's the thing that I need. So there's this delicate line of like, I would recommend ignoring this. But I get that if you see that, you're like, I would be so much more efficient if I could use that, and it's true to a certain extent.

+ +

So yeah, my recommendation would be don't do that. But most folks that I've seen are like, I would like to get better at these tools, and I totally get that. And I've obviously spent a lot of my own personal time [laughs] getting there. So I feel like I'm a do as I say, not as I do, maybe sort of thing. [laughs] It's roughly the space that I'm coming from right now. And I don't love being in that space, but apparently, it's where I find myself in this moment.

+ +

STEPH: That feels like a nice thing to share, though, because that is something that you've really enjoyed and cultivating that craft, and then sharing that and creating videos and content around it. So that totally makes sense that you can say, like, this is something I enjoy, and I have found it productive and helpful. Maybe sometimes you negotiate how productive it is.

+ +

CHRIS: Jury is out.

+ +

STEPH: [laughs] You've enjoyed it. And so it's something that you've chosen to invest in, but you don't feel it's critical to anybody else and their career or their path that they should invest in it. It does make sense that from a teacher-student perspective that, you're going to want to emulate what your teacher is doing.

+ +

So in the past, when I've taught very beginner-friendly intro to web development classes, so I would say much earlier than a junior dev, I always made sure to use VS Code or whatever editor I was using with them because I wanted to mimic exactly what they were going to do and have that same environment versus showing them something completely different and then expect them to translate. So there could be some parallelisms there as well if you're working with a junior developer that you want to cater to an environment that they can work with and feel comfortable and grow with versus showing them all of the fancy trickery that you can do in your particular setup.

+ +

CHRIS: Another data point in Steph is a better person than me.

+ +

STEPH: Sure, I'll take it. [laughter] There was also an interesting part of the question about what's so powerful that can explain to juniors why it's so important to know these keyboard shortcuts? And the only thing I could come up with because, again, I don't think it's super important for junior devs to learn keyboard shortcuts...but for the stuff that we do think is important around becoming familiar with your editor, making your terminal more friendly, for that stuff, I think a lot of it comes down to..., or the best reason I can think of is for your health.

+ +

Because it's been known that there's an increased risk of RSI the more that you switch between your keyboard and your mouse. So if you can use more keyboard shortcuts and use less or place less strain on your wrist and fingers by having to switch from your mouse to your keyboard, then I think that's the best reason. I mean, sure, productivity and feeling like a wizard those are cool reasons, but your health is really the only important reason. I just realized I used an initialism, but I didn't provide the definition for it. So for anyone that's not familiar, RSI stands for Repetitive Stress Injury.

+ +

CHRIS: It's interesting that you highlight the health aspect and RSI in particular because it's not something that I think about, but I think is definitely a benefit that I've had and what I like about modal editing and what I like about Vim. I think I tend to think about it in a different way, or it's the same idea but rotated around 180 degrees or something where my ability to do something quickly is not important in and of itself. But my ability to stay in context when I've figured out the change that I need to make that matters to me immensely.

+ +

And so what you're talking about of like being able to move quickly between files, being able to run the tests, being able to determine if the change that I made was, in fact, the correct change I care immensely about that. Because typing is not the bottleneck is a phrase that gets thrown around, and I like that phrase because it's true. It's not about just being faster at the keyboard and being an elite hacker typing all day long. The hard part is the thinking. But once I've done that, I want to get that thought out of my head and into the code as quickly as possible, as directly as possible.

+ +

And having efficient tooling and the ability to work with that tooling and move between files and run the tests and all of that is critically important to me for that reason, not because any individual change needs to be made that quickly but because once I've done the hard part of the thinking, then I want to get it out of my head and into my hands and then into the editor.

+ +

So now I think I've completely contradicted myself, or I've just slowly moved around this question of like, I don't think you should. Well, maybe you should, you should definitely is, I think, the three different stances that I've taken. But I do kind of believe that that should be something that changes over time in your career. So maybe I've been consistent if you give me that lens.

+ +

STEPH: That's what's fun about these listener questions. They take us on journeys, and I love that answer. I love that it's more about the staying in context that then helps you feel so productive. It's not just a productivity goal that you're looking for. But it is more for your context that that way, if you know there's a change that you want to make and you don't feel held up by all these other little things that are then preventing you from getting whatever it is you're excited to get done, getting it done.

+ +

But speaking of shortcuts, there is one that I just learned recently that's probably a pretty common one, but I haven't used it. I happened to stumble upon it. So if you're in your browser, you can open up a new tab, Command+T; I'm on a Mac. So you can do Command+T and open a new tab.

+ +

But there have been many times where I've accidentally closed a tab, or I've had a couple open, and I clicked the little close on the wrong one, and I'm like, no. And then I have to figure out where I was or go back to my history. But there's a shortcut for that, and it is Command+Shift+T, and that will reopen the tab that you accidentally closed. Didn't know that, learned that today. I'm going to lock that one away because that should be helpful.

+ +

CHRIS: The best way to lock it away is to explain it to others. So now that you've done that, this one's yours forever. Whereas everyone else hearing it, you got to try it a few times before it'll be yours forever, but, Steph, you're good now.

+ +

STEPH: Or spin up your own podcast and then share your keyboard shortcuts so that you can lock it away. [laughs]

+ +

CHRIS: I've observed that to be the easiest way to instill any learnings deeply within my brain.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+wBeKcxyQ + + ]]> + + Chris Toomey + Steph Viccari + + + 329: Fire Mode + https://bikeshed.thoughtbot.com/329 + cab8cb16-407c-43e1-8ddf-f36391e19df7 + Tue, 08 Mar 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph is excited to be headed on a retreat with her mom in the mountains, but before that, she details how she helped troubleshoot a production issue with her team and appreciated their process. She's also looking into tooling around spinning up more machines to process more RSpec tests. + +Chris had a developer start their new job at Sagewell and highlights how they involved the new person in rectifying potentially missing and/or confusing existing documentation. He also has a gripe, and that is accounts. Handling too many accounts. Additionally, he talks about triaging an error and how it was tough initially to understand if something was actually broken. And then it was even harder to understand what was broken. So he paired through it and used the power of putting two heads together. + 31:41 + no + + + Steph is excited to be headed on a retreat with her mom in the mountains, but before that, she details how she helped troubleshoot a production issue with her team and appreciated their process. She's also looking into tooling around spinning up more machines to process more RSpec tests. +Chris had a developer start their new job at Sagewell and highlights how they involved the new person in rectifying potentially missing and/or confusing existing documentation. He also has a gripe, and that is accounts. Handling too many accounts. Additionally, he talks about triaging an error and how it was tough initially to understand if something was actually broken. And then it was even harder to understand what was broken. So he paired through it and used the power of putting two heads together. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris, I am going on vacation next week, and I am so excited about that. It's going to be pretty much a week long. It's like a Tuesday through Friday ordeal. And it's a trip that I'm taking with my mom. So over the past year, she's gotten super serious about her health and nutrition and done a phenomenal job of being very focused on a plant-based diet, which is basically healthy vegan food is what that comes down to. +So there is a retreat that's taking place in the North Carolina Mountains that she's really excited about. I'm going to go with her. We're going to do lots of cooking, and hiking, and hanging out in the mountains, and it's going to be lovely. +CHRIS: Well, that does sound lovely. +STEPH: Yeah, it seems like a really perfect time to disconnect just because you're headed into the mountains. So all you should take with you are books and things that are not iPhones, and tablets, and computers, and screens. So I'm looking forward to that, just to be away from screens for the week. +On some more technical news, this past week, I helped troubleshoot a production issue, which was a bit novel for me because the work that Joël and I are doing with our current project it's all in the testing realm. And so it was probably around 10:00 o'clock at night my time, and I got a ping on Slack. And it looked like I was getting called in for a production issue. +And I was like, I have touched zero production code. [laughs] So I'm very intrigued how I could have broken production at this point. And so I looked into it, and it turned out that it wasn't necessarily related to a commit that I had authored, but it was for a commit that I had reviewed and then approved. And so their strategy is they create a new channel. They'd gotten a ticket that an error was occurring. +And then the site reliability team created a new Slack channel, and then they pinged everybody who either authored, reviewed, and approved that change to be like, hey, we think the issue is related to this commit. Our plan is we'd like to roll it back. But before we do, we just want to check in with folks who have more knowledge to help us confirm that, yes, this error message seems related. And I really liked that approach. +I really like the idea that it's not just the person who merged the commit that then gets pinged on it, but it's like everybody else who happened to look at this and review it come help us too. So we spent some time looking into it, confirmed that yes, indeed, it was related to that particular commit. And then their team did the wonderful thing of then rolling it back. So then, it was no longer an escalated issue. +And so then I asked, "What else can I do to help?" And they said, "Well, from here, it's no longer a production issue. So tomorrow, just follow up with the author and let them know and issue a fix for the bug, and then merge it like normal." So we're back in that normal pull-request flow, very calm. +And overall, I just appreciated their process. I like very much how they pulled more people in because I think some of the other people that were involved weren't online, which makes sense because it was really late. So that way, you just spread in case some other people really aren't available that then hopefully you'll get lucky and one of those three or four people are available to help you troubleshoot. +CHRIS: That does sound like a really nice and thoughtful and intentional bug response, communication, procedure, rollback, et cetera. All of that sounds like it worked very well and is nice to have. And it's the sort of thing that a larger organization ideally gets to, having these sorts of processes. Spoiler alert, later in the episode, I will talk about the other side of it of being a very young organization and trying to be like, wait, is this a bug? Is this not a bug? Should we roll back? What do we do? That's actually my topic de jour. +But what you're describing sounds like the calm even in the case that there is a fire sort of like, yep, we've got procedures. We have workflows. We have communication channels and ways that even the exceptional things can be handled in an ideally as calm as possible way. So that's awesome that that's what you got to experience there. +STEPH: Yeah, getting called in at 10:00 o'clock is never fun for anybody. But when it happens, because it's going to happen, then I appreciate the thoughtfulness and that process that they put behind it. So it all went fairly smoothly. And it was also one of those fun things where I haven't met...like this is a very big organization, so I hadn't met any of those people. +So when I got pinged on it, and then I hopped in, I was like, hi, I don't know anything about this process and what y'all are doing, but I am here. I'm here to help. Where can I look? What can I do? So it was also a fun endeavor in that regard to just be like, I don't know what I'm doing, but I am here to help. Please let me know how I can help. And it ended up working pretty well. So yeah, that's been a fun adventure for this week. How about you? What's new in your world? +CHRIS: What is new in my world? Well, we had a developer start this week, which has been really wonderful. Unfortunately, we had scheduled their first day to be Monday, which was Presidents' Day, and that's a holiday. So we got out in front of that one and figured it out. We're like, no, no, actually, feel free to start on Tuesday. We'll not be around on Monday, so you shouldn't be around on Monday. But then, on Tuesday, they started. +And we intentionally structured things such that we have a contractor that has been working with us for like seven or eight months now. So it's been a long time and been very formative as well the work with that contractor. So this is their last week, and thus, we very purposefully brought the new person on the team and that contractor together to maximize the amount of pairing and overlap that we have there just to try and as intentionally as possible grab whatever is in their head, get another point of view. +Because this new individual on the team will be able to work with myself and the other full-time developer on the team a bunch moving forward, so we want to maximize their overlap with the person who is on their way out. But otherwise, it's been great. We're a young organization, so the version of onboarding it's me running around setting up a lot of accounts, forgetting to set up other ones, getting pings in Slack, and then following up and setting up another account. Eventually, I hope that there are checklists and formalizations and, ideally, one-click SSO magic that makes all of that work. But for now, I'm happy to chase it down. +But really, we're just leveraging pairing as much as possible as the onboarding tool to make sure that where we don't have formalization, procedures, documentation, et cetera, as thoroughly built out as I would love to be at, we can shore that up with some time with other humans. +STEPH: That's awesome. It's always fun having someone new to join to highlight all the things you need to automate or at least have a checklist for to then help them onboard. But that's really exciting that you've got a new teammate. +CHRIS: Yeah, definitely very exciting. And they've been great. They've hit the ground running and a couple of pull requests already and just contributing very effectively within their first couple of days. So that's always wonderful to see. We are definitely taking this moment to document what is undocumented or update the README where it needs to be and start to make that checklist. We have another person who will be starting in about two weeks’ time. And so, ideally, that will be even a little bit more fleshed out of a process. So slowly, incrementally get a little bit better with each we add that we get there. +STEPH: How much do you involve the new person in creating that documentation? Is that something that you ask them to help build, or is it something you take ownership of? What's that balance? +CHRIS: It's interesting. So definitely some I want to be with that person because I think it can often be the easy first PR is an update to the README for like, oh, I tried to set up the app, and it did not work. For this reason, I have now updated the README, and now there's a pull request. And we get to experience that flow via the very low-stakes change of updating the README. So that's a definite one that I like to have. +The other is I'll typically ask for the individual to capture as much as possible. There's a very delicate line in my mind between empowering them and being like, yes, absolutely. We're young. We don't have everything documented. So feel free to make changes where that makes sense to you. But at the same time, I know that joining a new team can be complicated, can be intimidating in certain ways. You're not sure what's okay to change? What's not okay to change? That sort of thing. +So I simultaneously don't want to put the pressure on someone to be like, "Yeah, no, change anything you want. Literally, nothing is stable here. Nothing's glued to the ground. So feel free to pick up anything and throw it out the window." That feels too far in my mind. So I don't have an actual answer like, I'm ideally calibrated at this point. But it's sort of those two tensions that I'm holding in mind as I think about that. +STEPH: Well, I really like your answer. I like that balance because I think it's really nice to include the person in those changes and also just because they're going through it. So they happen to have that insight, and it's fresh. But I agree, when you're joining a job, you want some stability and confidence that the people that you are joining that team with are also working hard to make it a very positive onboarding experience. +And if you just were to push all of that responsibility on to them to be like, "Yeah, we know. We don't have this organized yet. So you tell us everything that we need to do," that would feel unkind to that new person. I think as a new person that I wouldn't fully enjoy that. I don't mind some of it, but I wouldn't want all of it. I'd have nervousness around ownership, around improving processes, and who that belongs with. +CHRIS: Sort of a classic case of it depends, or it's a little from Column A, a little from Column B, but definitely some, just hopefully not too much. +STEPH: The Goldilocks of onboarding, some onboarding responsibilities, but not all of them, just the right amount. [laughs] +CHRIS: Shifting gears slightly, though, I just want to gripe for a minute. I'm just going to gripe. This is not my normal mode, but I'm going to lean into it. +STEPH: Do it. +CHRIS: Accounts, just accounts. I have so many accounts now. There are so many across different systems, and I'm trying to do the good thing, which is let's stop using personal accounts for anything and only use organizational accounts for the things that are for work. And some organizations do a great job with this. +GitHub, I'm looking at you; really well done, super happy with the way that you folks have implemented accounts. You get that I am one human being that contains multitudes. I am my personal self; I am my work self. I am maybe even another version of work, and you get that. And you usually let me exist as all of those versions of myself and, man, do I appreciate that. +Heroku, you're okay. Like, it's all right. You treat the different facets of me as different accounts, but that's okay. You make it relatively easy to switch between. Although you do make me two-factor auth and re-login every single day, and I don't love that. So I don't know what's going on there, but fine. +Trello, aka Atlassian, I guess at this point, come on, what are we doing? What's going on here? So originally, I had started, and I had the one Trello account, and I had my personal boards. And then there was the Sagewell organizational account. And within that, there were some boards, and I would just bounce back and forth. +But I realized, no, I need to do the right thing. So I created a new Trello account. And now Atlassian just forces me to switch between them, and it loses the link that I'm going to often. It's a different login interstitial screen. And it constantly shows me that like, hey, you don't have access to this. Do you want to switch accounts? And I say yes. And then they take me to a screen where I can pick between two options, the one that I was that didn't have the ability to do it and another. +And as a developer, I know that the thing I'm about to say is not fair. But come on, folks, you could know the answer to this question. There are two, and one is the wrong answer, so the other one is probably the right answer. You don't need to autolog me into that; I get it. Just emphasize it because they almost look identical on the list. +I have now accidentally tried to request access with my secondary account to my other account, and I can't get out of that state. So now, one of the ways that I try and do this it shows me a list of them to pick. The other it says, "You have requested access. We're waiting to hear back." And I'm like, no. So anyway, that's a thing. +STEPH: So I know people can't see me. [laughs] So I'll narrate that I'm dying over here because I very much appreciate that we are positive people. We are very focused on bringing positive energy, but the descent into the amount of shade that you're throwing at different applications [laughter] just really made my day, and I feel that pain. +I have felt that pain with Atlassian and can relate. And we should have some gripe sessions. This feels healthy. This feels very...okay, well, I don't know for you. I'm the one that's laughing and getting joy out of this. I don't know if it's helpful for you, but it feels very cathartic to me. [laughs] +CHRIS: It is definitely somewhat cathartic. I think there's utility in having these sorts of conversations. And throwing shade at Atlassian, whatever, they're doing fine, so I'm not super worried about it. But generally, we try and keep things positive because I think that's, frankly, a more effective way to communicate. +But occasionally, it is useful to look at the things where I'm like; that is a pattern that I do not want to repeat. And I'm sure that there are complex organizational enterprise-y reasons that it has to be this way. But I can look at that and say never that. That experience as a user is like, wow, yeah, I just tripped over nine layers of your enterprise there just trying to do very simple day-to-day things for myself. So I want to avoid that. I've griped about that one login, not the company OneLogin. +But that one login page that I've experienced where I start to interact with the form, and suddenly some JWT handshake in the background happens, and I'm now logged in. And it just rips the page out from underneath me. That is unacceptable. That is not okay. And I really do think there's something worth occasionally looking at those and being like, well, not that. But anyway, I should probably stop my gripe session now. +STEPH: [laughs] Well, if I may join in, I have one that I'd like to share. Since we're on this -- +CHRIS: Throw it on the pile. What else we got? [laughs] +STEPH: [laughs] So there was some code. There was a piece of code that I was looking at that was very not friendly. It was difficult to understand. It took a while to parse through what are they actually doing? What records are they creating? Why did they choose this manner? Why are we iterating over these particular numbers? What's the outcome here? And I was pairing with Joël and was going back and forth having a conversation trying to be the detectives of why this code exists, and we finally got there. And we finally understood what it's doing and why. And I just lost it for a minute once we finally got there. [laughs] +I just thought the way this code is written, it does not improve readability, and it doesn't improve performance. All it did was make my life harder because it was very difficult to read. So all they did was become really clever with the code that they were writing and essentially drying it up, which I have such a beef with DRY because it has caused me pain. And so they essentially were drying up their code or introducing a way to make it just take up fewer lines that took up less vertical space. But overall, I was very grumpy about it. +And Joël was very kind about it and was like, "Well, this is the type of code I could see maybe why they did this." But you're right; it doesn't help with readability and performance. And he was helping balance out my grumpy goose moment. I've been having a lot this week; maybe it's just the week I'm in. I'm in more of a fiery mode this week [laughs] with some of the code that I'm seeing, and that was one of them. That was the please, please, please don't DRY up your code. If it doesn't improve readability or performance, there's just no need. There is no benefit. +CHRIS: Well, I definitely know that feeling. And I think I've probably, as a developer, gone through that arc where early on I was just trying to make stuff work, and then I learned how to be clever. And suddenly, being clever became a game that I could play. +And then, pretty early on, I realized I would come back to my own code from two weeks ago and be like, what the heck does this do? I have no idea. And that's when I was drawn to Ruby. That was one of the things. I'm like, oh, I can write code that looks so much like the clear words that I have in my head about the thing. I like that. And so much of my career has been spent in the let's make it obvious and revisitable. +I actually remember very clearly early on in my time at thoughtbot, I was working on something and was working on it with Joe Ferris, who is the CTO of thoughtbot and a very clever individual, and I mean that in the truly positive sense of the term, one of the most capable engineers I've ever worked with. He was describing an anecdote, but it was basically he'd put up a pull request. And someone replied, "Oh, that's clever." +And Joe's reaction was, "Oh, crap." Just taking that as not an insult but as someone saying, oh, that's clever in a positive way, and Joe hearing that in the negative form of I went too far here, or this is not obvious in its initial interpretation. That really stuck in my head from there, just his reaction to it immediately of that being not a good thing. And I was like, that is interesting. And all the more so over time, I've come to believe that clever is probably something to avoid in code. +STEPH: Yeah, agreed. I'm at the point that if I do see someone who's done something that I do think is clever in a positive way, I will still abstain from using that word clever because I do want to make sure they don't think that I'm saying in a bad way that this is clever, that it's not readable, and it's not friendly. So I totally avoid that word when I'm complimenting someone's code just to make sure there's no confusion. +CHRIS: It's one of those words that got away from us that we lost the definition of, and then we came back, yeah. +Mid-roll Ad +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: Let's see. In other news, you had mentioned this earlier, and then I had mentioned my side of it but errors in alerting and all of those sorts of things. They're an interesting question. We had a small situation over the weekend that turned out to be kind of real, kind of not real. But I happened to be away on vacation. I did have my computer with me because, at this point, we're early enough. And I'm like, I'm going to take my computer everywhere and just be ready in case it's necessary. +And in this case, I did get a ping. I looked into it and what was unfortunate is it wasn't immediately obvious if something was broken or not. And to a certain degree, that's always going to be kind of true. There's so much noise, so many requests hitting a web application. And how do you tell the good ones from the bad ones? And ideally, I could threshold around certain volumes of traffic, but even that's going to have spikes, and ebbs and flows and things like that. +So it was very hard initially to understand is something actually broken? And then all the more so to understand what was broken. Thankfully, it was tractable. It was solvable. And we've done, I think, some good work especially considering how early on we are and how we've instrumented things in Sentry, in particular, our usage of Sentry and also somewhat in the logs. +But again, I think I've talked about this before, but I'm feeling this tension around there's data. There's data just kind of like, what happened? And right now, we've got logs. That's one of the places that goes to Sentry if it gets escalated up to that level. And we sort of have a weird Venn diagram between logs and Sentry. And then we also have analytics as another thing and then eventually data science, and what do we want to try and learn? +And all of these kinds of want different facets of it's not the same data set. But I wonder, is there a superset of data that then we could filter and slice and cut up, do all those sorts of things? I think this is the dream of Honeycomb and platforms like that, but I'm not even certain if that's true. And so I'm in that awkward middle space is how I would describe it. +But in that particular case, I was able to resolve it. I did take away as an action it's probably time to start thinking about PagerDuty anomaly detection, that sort of thing. When does alerting happen? When do engineers actually get calls when not just during the normal nine-to-five of the workday? So I'll be investigating that in the coming weeks and see where we get to. But it's sort of the first thing that really pushed us in that direction. +The other thing I'll say is we have the idea of the point dev, which I've talked about on a couple of episodes. But the idea is for each week, one individual on the engineering team is in charge of the noise, for lack of a better term. They're looking at the error stream in Sentry. They're looking at any ad hoc requests that are coming from our admin team, et cetera, et cetera. And that's been really great. +But one thing that I've noticed is that dealing with the errors is particularly tricky and what we did in this particular case was just to pair on that. As an individual, it is really hard to sometimes to reproduce, sometimes to just understand these are the things you didn't expect in your code, and therefore they are, by definition, harder to understand, harder to think about. +And then sometimes you get to an understanding. You're like, ah, what do we do about that? Do we care? Do we not care? Is this just noise? Is this something we should solve? Is it something we should solve soon? Or is this something we can solve whenever we get to it in the backlog? And making that sort of determination is all the harder. +And so I'm increasingly of the mind that there should be some amount of time that is pairing on that error backlog to bring two heads together. I hadn't been thinking of it this way, but I've now come around to thinking this is a really great place for pairing because it's so hard for one individual to deal with that complexity to make the hard value judgments. And to do that, if each individual does that in a vacuum, then we have n different value systems at play that are hopefully very similar. +But if we start to pair up, then there's osmosis between those groupings. And ideally, we sort of coalesce towards a shared value structure around, like, what can we ignore? What should we snooze for a week? What should we put in the backlog? What should we prioritize and fix immediately? Because I think those are really hard things to otherwise...that's really hard to document, I would say. I would love to write up a page in the Wiki that says, "This is how you treat errors," except each error is a unique snowflake, and you just have to follow your values. +STEPH: I have been on teams where we've written up documentation that helps you triage an error because you're right; you can't write documentation around a specific error. But that I always found really helpful where it was like, here's all the links that you can look at, here are some recommendations. When we were working on an application that was falling over more often, there were some specific outlines around if you see this problem, then this is typically how you can solve it. And then we had to fix that at a larger scale, but it was a nice band-aid to get us through at that point. +I like the idea of pairing, especially as you mentioned; it's tricky. It's funny when you mentioned capturing those errors and putting them into the backlog because I like that idea that then you can prioritize and bring those into the sprint. It just made me feel a bit hesitant. If we don't work on it now, we're never going to work on it. But then that feels unfair to say because it really comes down to the team. +If you have a team that's going to be able to look at those errors and say, "Yes, we're going to bring them in and prioritize them," then that feels really good to then be able to say, "This is an error. Let's capture it. Let's provide some content around it. But it doesn't need to be addressed at this moment. It's still pretty low in terms of risk for users or at least low in impact for users." So yeah, I guess it just depends as long as the team feels good about being able to prioritize errors, which I feel confident that your team would be able to do. And if you can't, then y'all could reassess that plan. +CHRIS: That's why we definitely have that. We're revisiting the errors. They're part of the same backlog as everything else. So they're coming up in relative priority and getting worked on and getting resolved. But we're also shifting our thinking just a little bit to say, "We should take a little bit more time in the moment to try and resolve some of these where we can." I have the dream of there are just zero bugs ever. But that's hard, especially in different platforms. +And we're seeing a lot of mobile traffic and from different older Android versions and so weird JavaScript edge cases and things like that. Like, why does your runtime not have object? That feels like a thing every JavaScript runtime should have. But that's a joke. Every JavaScript runtime, I'm pretty sure, does have object but that sort of thing. It's like, whoa, this is weird and specific to this one device. Cool, those are fun. So yeah, giving a little bit more time to do those. +And again, so we definitely do have the document that describes here are the places to look and how to think about this category of error and this category of error. But at the end of the day, you get one that's just like, there's not a ton of detail in the error. It's hard to reproduce. It might be device-specific, et cetera. And so what do you do in that moment? And that's where we're trying to...I think pairing is a great way to share that thinking around the team. So overall, it's been great, though. I think everyone who has been involved has been like, "This was better than when I did it on my own," so cool. +STEPH: Awesome. That sounds great. +CHRIS: Yeah, I think so. This is one of those ever-evolving facets of how we work as a team and how we build the platform. So I will certainly report more in future episodes, but for now, happy with that. And yeah, what else is up in your world? +STEPH: Yeah. So we've been looking specifically into tooling around how we're going to spin up more machines to process more RSpec tests. So specifically, we have around 80,000 RSpec tests that we are processing, and we have one machine that is parallelizing those and takes around just for that portion of the build because then there are other tests and things that get run that brings it up to about a total of 30 minutes. +But for the RSpec portion, I think it's probably around 20-ish minutes to process those 80,000 tests. So we split that across four different containers, and then we run those tests. And so we'd really like to spin up more machines to then process because we've reached the point that we have given as much power to that one machine as possible. So now we're looking to add more machines. +And one of those solutions that we're looking at is using Buildkite, which is built with the idea that you can add these build steps so then you can more easily say, "All right, once we get to this particular build step, hey Buildkite, we'd like to run n number of machines to process all these tests." And that seems really nice. And it is something that we are interested in. It is actually what Shopify uses. They use Buildkite ci-queue, which is built for mini-tests, which is what they use, and Redis to then run all of their tests. +But we are using TeamCity, so we're not using Buildkite. And we would like to see if we can grow with our current CI infrastructure versus having to move to a new one. There's a lot of just risk involved in moving to a new one. And so we've been studying hard if TeamCity will let us do this. And so far, the answer has been no. +But just recently, we found somewhere in the docs that it looks like there is a chance that with TeamCity, we can inform TeamCity that, hey, even though we have just this one build step, instead of only giving us one agent or one provisioned machine to then run these tests, instead that we actually want to spin up a couple of machines to then process these and then aggregate the results back to this one step. So we're looking into that. +But I wanted to throw this out there in case anybody else is also using TeamCity and has already invested in this particular approach. I would love to hear about it because we are currently figuring out the capabilities and if this is something that we can stay with our current infrastructure or if we're really going to have to look for a new solution. +CHRIS: Well, I'm hopeful that someone out there can give you some input. I definitely get the idea that you're stuck, and stuck is maybe too strong of a word. But if TeamCity is not ideal, the idea of moving off it does feel exceedingly heavy and the riskiness that you talked about. That's, I think, a critical word here because I think it's easy to think of CI as like it's a very important thing. But that's absolutely critical as part of your deploy pipeline, I assume. +This is speaking generically about CI, and so it is, in fact, a critical piece of the infrastructure. If you've got a bug on production and suddenly CI is down, what do you do? I guess you can test locally and decide you're going to push past it, but then you have to circumvent it. And so I understand the intentional way that you're thinking about that and the risk associated. +I do wonder, though, if TeamCity has felt like not the right platform for a while and if there are considerations. Is there the possibility of both trying to improve the world that you have now, so it's not the big move off of it but then also in parallel start to work on an alternative implementation? This is perhaps not entirely fair, but it feels like a Rails application is this repository of code. And typically, CI is configured via a file. +And that's like, if you've got your teamcity.yaml or whatever it happens to be, could there also be a buildkite.yaml that is not on the critical path for deploying or anything like that? But it is a way to, frankly, somewhat inefficiently test on two different platforms but start to see if you can get the code moving on a different platform and be able to gradually build out and make that transition possible without it being one big swap over sort of thing, which eventually it would need to be. But just wondering, is that happening in parallel? Is that a possibility? +STEPH: I think the short answer is, I'm sure there is. There's a way to look at the existing system and then find ways that we can tweak it. But I also know that the team has already invested a lot into working with the current system and making it as efficient as possible. So I don't know if there's any true big impact but intermediary steps that we can take. We are definitely in that proof of concept world. So we're not going to move anything over for the rest of the team until we can really prove that something is working for a small subset and then start to expand from there. +But currently, our idea is to dig further in TeamCity, which I think also includes just a call to their team and say, "Hey, we'd love to talk to one of your engineers and see if the thing that we're trying to do if it's possible. Let us know if it's not and if we need to look elsewhere," which is intriguing to me because having a lot of tests isn't new. There are tons of companies that have lots of tests, and they want their CI test suite to be fast. +So a company that then has built software that helps Team execute these steps that then the ability to say, "Hey, I want more machines to process. I want to give you more money and to give us more machines, and we can process more things." I feel like that should be a thing. And I'm getting at the edges of my knowledge. This is why we're exploring all of this. But it has been surprising to me to realize that that doesn't seem as easy of a thing as I would have expected it to be. +There are also some other concerns around here where the client that we're working with if we're going to work with third-party vendors, then we have to get special approval to work with them. It's not just a hey, we can just go try it out. It's a lengthy contract process that we'd have to go through. So there are also some constraints that we have to keep in mind where we can't just work with anyone. We need to be careful to make sure that they're certified in a particular way. +So yes, I like your idea. I will definitely keep it in mind. But I don't know if there are any true intermediary steps yet other than the building out a proof of concept and then finding small ways that we could move over. Then I think that would be ideal for sure. And then hopefully, if there's anybody that's listening that has experience with TeamCity or Buildkite, that's the other tool that we're looking at using, let me know. I would love to chat about it and find out your experience. On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph is excited to be headed on a retreat with her mom in the mountains, but before that, she details how she helped troubleshoot a production issue with her team and appreciated their process. She's also looking into tooling around spinning up more machines to process more RSpec tests.

+ +

Chris had a developer start their new job at Sagewell and highlights how they involved the new person in rectifying potentially missing and/or confusing existing documentation. He also has a gripe, and that is accounts. Handling too many accounts. Additionally, he talks about triaging an error and how it was tough initially to understand if something was actually broken. And then it was even harder to understand what was broken. So he paired through it and used the power of putting two heads together.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris, I am going on vacation next week, and I am so excited about that. It's going to be pretty much a week long. It's like a Tuesday through Friday ordeal. And it's a trip that I'm taking with my mom. So over the past year, she's gotten super serious about her health and nutrition and done a phenomenal job of being very focused on a plant-based diet, which is basically healthy vegan food is what that comes down to.

+ +

So there is a retreat that's taking place in the North Carolina Mountains that she's really excited about. I'm going to go with her. We're going to do lots of cooking, and hiking, and hanging out in the mountains, and it's going to be lovely.

+ +

CHRIS: Well, that does sound lovely.

+ +

STEPH: Yeah, it seems like a really perfect time to disconnect just because you're headed into the mountains. So all you should take with you are books and things that are not iPhones, and tablets, and computers, and screens. So I'm looking forward to that, just to be away from screens for the week.

+ +

On some more technical news, this past week, I helped troubleshoot a production issue, which was a bit novel for me because the work that Joël and I are doing with our current project it's all in the testing realm. And so it was probably around 10:00 o'clock at night my time, and I got a ping on Slack. And it looked like I was getting called in for a production issue.

+ +

And I was like, I have touched zero production code. [laughs] So I'm very intrigued how I could have broken production at this point. And so I looked into it, and it turned out that it wasn't necessarily related to a commit that I had authored, but it was for a commit that I had reviewed and then approved. And so their strategy is they create a new channel. They'd gotten a ticket that an error was occurring.

+ +

And then the site reliability team created a new Slack channel, and then they pinged everybody who either authored, reviewed, and approved that change to be like, hey, we think the issue is related to this commit. Our plan is we'd like to roll it back. But before we do, we just want to check in with folks who have more knowledge to help us confirm that, yes, this error message seems related. And I really liked that approach.

+ +

I really like the idea that it's not just the person who merged the commit that then gets pinged on it, but it's like everybody else who happened to look at this and review it come help us too. So we spent some time looking into it, confirmed that yes, indeed, it was related to that particular commit. And then their team did the wonderful thing of then rolling it back. So then, it was no longer an escalated issue.

+ +

And so then I asked, "What else can I do to help?" And they said, "Well, from here, it's no longer a production issue. So tomorrow, just follow up with the author and let them know and issue a fix for the bug, and then merge it like normal." So we're back in that normal pull-request flow, very calm.

+ +

And overall, I just appreciated their process. I like very much how they pulled more people in because I think some of the other people that were involved weren't online, which makes sense because it was really late. So that way, you just spread in case some other people really aren't available that then hopefully you'll get lucky and one of those three or four people are available to help you troubleshoot.

+ +

CHRIS: That does sound like a really nice and thoughtful and intentional bug response, communication, procedure, rollback, et cetera. All of that sounds like it worked very well and is nice to have. And it's the sort of thing that a larger organization ideally gets to, having these sorts of processes. Spoiler alert, later in the episode, I will talk about the other side of it of being a very young organization and trying to be like, wait, is this a bug? Is this not a bug? Should we roll back? What do we do? That's actually my topic de jour.

+ +

But what you're describing sounds like the calm even in the case that there is a fire sort of like, yep, we've got procedures. We have workflows. We have communication channels and ways that even the exceptional things can be handled in an ideally as calm as possible way. So that's awesome that that's what you got to experience there.

+ +

STEPH: Yeah, getting called in at 10:00 o'clock is never fun for anybody. But when it happens, because it's going to happen, then I appreciate the thoughtfulness and that process that they put behind it. So it all went fairly smoothly. And it was also one of those fun things where I haven't met...like this is a very big organization, so I hadn't met any of those people.

+ +

So when I got pinged on it, and then I hopped in, I was like, hi, I don't know anything about this process and what y'all are doing, but I am here. I'm here to help. Where can I look? What can I do? So it was also a fun endeavor in that regard to just be like, I don't know what I'm doing, but I am here to help. Please let me know how I can help. And it ended up working pretty well. So yeah, that's been a fun adventure for this week. How about you? What's new in your world?

+ +

CHRIS: What is new in my world? Well, we had a developer start this week, which has been really wonderful. Unfortunately, we had scheduled their first day to be Monday, which was Presidents' Day, and that's a holiday. So we got out in front of that one and figured it out. We're like, no, no, actually, feel free to start on Tuesday. We'll not be around on Monday, so you shouldn't be around on Monday. But then, on Tuesday, they started.

+ +

And we intentionally structured things such that we have a contractor that has been working with us for like seven or eight months now. So it's been a long time and been very formative as well the work with that contractor. So this is their last week, and thus, we very purposefully brought the new person on the team and that contractor together to maximize the amount of pairing and overlap that we have there just to try and as intentionally as possible grab whatever is in their head, get another point of view.

+ +

Because this new individual on the team will be able to work with myself and the other full-time developer on the team a bunch moving forward, so we want to maximize their overlap with the person who is on their way out. But otherwise, it's been great. We're a young organization, so the version of onboarding it's me running around setting up a lot of accounts, forgetting to set up other ones, getting pings in Slack, and then following up and setting up another account. Eventually, I hope that there are checklists and formalizations and, ideally, one-click SSO magic that makes all of that work. But for now, I'm happy to chase it down.

+ +

But really, we're just leveraging pairing as much as possible as the onboarding tool to make sure that where we don't have formalization, procedures, documentation, et cetera, as thoroughly built out as I would love to be at, we can shore that up with some time with other humans.

+ +

STEPH: That's awesome. It's always fun having someone new to join to highlight all the things you need to automate or at least have a checklist for to then help them onboard. But that's really exciting that you've got a new teammate.

+ +

CHRIS: Yeah, definitely very exciting. And they've been great. They've hit the ground running and a couple of pull requests already and just contributing very effectively within their first couple of days. So that's always wonderful to see. We are definitely taking this moment to document what is undocumented or update the README where it needs to be and start to make that checklist. We have another person who will be starting in about two weeks’ time. And so, ideally, that will be even a little bit more fleshed out of a process. So slowly, incrementally get a little bit better with each we add that we get there.

+ +

STEPH: How much do you involve the new person in creating that documentation? Is that something that you ask them to help build, or is it something you take ownership of? What's that balance?

+ +

CHRIS: It's interesting. So definitely some I want to be with that person because I think it can often be the easy first PR is an update to the README for like, oh, I tried to set up the app, and it did not work. For this reason, I have now updated the README, and now there's a pull request. And we get to experience that flow via the very low-stakes change of updating the README. So that's a definite one that I like to have.

+ +

The other is I'll typically ask for the individual to capture as much as possible. There's a very delicate line in my mind between empowering them and being like, yes, absolutely. We're young. We don't have everything documented. So feel free to make changes where that makes sense to you. But at the same time, I know that joining a new team can be complicated, can be intimidating in certain ways. You're not sure what's okay to change? What's not okay to change? That sort of thing.

+ +

So I simultaneously don't want to put the pressure on someone to be like, "Yeah, no, change anything you want. Literally, nothing is stable here. Nothing's glued to the ground. So feel free to pick up anything and throw it out the window." That feels too far in my mind. So I don't have an actual answer like, I'm ideally calibrated at this point. But it's sort of those two tensions that I'm holding in mind as I think about that.

+ +

STEPH: Well, I really like your answer. I like that balance because I think it's really nice to include the person in those changes and also just because they're going through it. So they happen to have that insight, and it's fresh. But I agree, when you're joining a job, you want some stability and confidence that the people that you are joining that team with are also working hard to make it a very positive onboarding experience.

+ +

And if you just were to push all of that responsibility on to them to be like, "Yeah, we know. We don't have this organized yet. So you tell us everything that we need to do," that would feel unkind to that new person. I think as a new person that I wouldn't fully enjoy that. I don't mind some of it, but I wouldn't want all of it. I'd have nervousness around ownership, around improving processes, and who that belongs with.

+ +

CHRIS: Sort of a classic case of it depends, or it's a little from Column A, a little from Column B, but definitely some, just hopefully not too much.

+ +

STEPH: The Goldilocks of onboarding, some onboarding responsibilities, but not all of them, just the right amount. [laughs]

+ +

CHRIS: Shifting gears slightly, though, I just want to gripe for a minute. I'm just going to gripe. This is not my normal mode, but I'm going to lean into it.

+ +

STEPH: Do it.

+ +

CHRIS: Accounts, just accounts. I have so many accounts now. There are so many across different systems, and I'm trying to do the good thing, which is let's stop using personal accounts for anything and only use organizational accounts for the things that are for work. And some organizations do a great job with this.

+ +

GitHub, I'm looking at you; really well done, super happy with the way that you folks have implemented accounts. You get that I am one human being that contains multitudes. I am my personal self; I am my work self. I am maybe even another version of work, and you get that. And you usually let me exist as all of those versions of myself and, man, do I appreciate that.

+ +

Heroku, you're okay. Like, it's all right. You treat the different facets of me as different accounts, but that's okay. You make it relatively easy to switch between. Although you do make me two-factor auth and re-login every single day, and I don't love that. So I don't know what's going on there, but fine.

+ +

Trello, aka Atlassian, I guess at this point, come on, what are we doing? What's going on here? So originally, I had started, and I had the one Trello account, and I had my personal boards. And then there was the Sagewell organizational account. And within that, there were some boards, and I would just bounce back and forth.

+ +

But I realized, no, I need to do the right thing. So I created a new Trello account. And now Atlassian just forces me to switch between them, and it loses the link that I'm going to often. It's a different login interstitial screen. And it constantly shows me that like, hey, you don't have access to this. Do you want to switch accounts? And I say yes. And then they take me to a screen where I can pick between two options, the one that I was that didn't have the ability to do it and another.

+ +

And as a developer, I know that the thing I'm about to say is not fair. But come on, folks, you could know the answer to this question. There are two, and one is the wrong answer, so the other one is probably the right answer. You don't need to autolog me into that; I get it. Just emphasize it because they almost look identical on the list.

+ +

I have now accidentally tried to request access with my secondary account to my other account, and I can't get out of that state. So now, one of the ways that I try and do this it shows me a list of them to pick. The other it says, "You have requested access. We're waiting to hear back." And I'm like, no. So anyway, that's a thing.

+ +

STEPH: So I know people can't see me. [laughs] So I'll narrate that I'm dying over here because I very much appreciate that we are positive people. We are very focused on bringing positive energy, but the descent into the amount of shade that you're throwing at different applications [laughter] just really made my day, and I feel that pain.

+ +

I have felt that pain with Atlassian and can relate. And we should have some gripe sessions. This feels healthy. This feels very...okay, well, I don't know for you. I'm the one that's laughing and getting joy out of this. I don't know if it's helpful for you, but it feels very cathartic to me. [laughs]

+ +

CHRIS: It is definitely somewhat cathartic. I think there's utility in having these sorts of conversations. And throwing shade at Atlassian, whatever, they're doing fine, so I'm not super worried about it. But generally, we try and keep things positive because I think that's, frankly, a more effective way to communicate.

+ +

But occasionally, it is useful to look at the things where I'm like; that is a pattern that I do not want to repeat. And I'm sure that there are complex organizational enterprise-y reasons that it has to be this way. But I can look at that and say never that. That experience as a user is like, wow, yeah, I just tripped over nine layers of your enterprise there just trying to do very simple day-to-day things for myself. So I want to avoid that. I've griped about that one login, not the company OneLogin.

+ +

But that one login page that I've experienced where I start to interact with the form, and suddenly some JWT handshake in the background happens, and I'm now logged in. And it just rips the page out from underneath me. That is unacceptable. That is not okay. And I really do think there's something worth occasionally looking at those and being like, well, not that. But anyway, I should probably stop my gripe session now.

+ +

STEPH: [laughs] Well, if I may join in, I have one that I'd like to share. Since we're on this --

+ +

CHRIS: Throw it on the pile. What else we got? [laughs]

+ +

STEPH: [laughs] So there was some code. There was a piece of code that I was looking at that was very not friendly. It was difficult to understand. It took a while to parse through what are they actually doing? What records are they creating? Why did they choose this manner? Why are we iterating over these particular numbers? What's the outcome here? And I was pairing with Joël and was going back and forth having a conversation trying to be the detectives of why this code exists, and we finally got there. And we finally understood what it's doing and why. And I just lost it for a minute once we finally got there. [laughs]

+ +

I just thought the way this code is written, it does not improve readability, and it doesn't improve performance. All it did was make my life harder because it was very difficult to read. So all they did was become really clever with the code that they were writing and essentially drying it up, which I have such a beef with DRY because it has caused me pain. And so they essentially were drying up their code or introducing a way to make it just take up fewer lines that took up less vertical space. But overall, I was very grumpy about it.

+ +

And Joël was very kind about it and was like, "Well, this is the type of code I could see maybe why they did this." But you're right; it doesn't help with readability and performance. And he was helping balance out my grumpy goose moment. I've been having a lot this week; maybe it's just the week I'm in. I'm in more of a fiery mode this week [laughs] with some of the code that I'm seeing, and that was one of them. That was the please, please, please don't DRY up your code. If it doesn't improve readability or performance, there's just no need. There is no benefit.

+ +

CHRIS: Well, I definitely know that feeling. And I think I've probably, as a developer, gone through that arc where early on I was just trying to make stuff work, and then I learned how to be clever. And suddenly, being clever became a game that I could play.

+ +

And then, pretty early on, I realized I would come back to my own code from two weeks ago and be like, what the heck does this do? I have no idea. And that's when I was drawn to Ruby. That was one of the things. I'm like, oh, I can write code that looks so much like the clear words that I have in my head about the thing. I like that. And so much of my career has been spent in the let's make it obvious and revisitable.

+ +

I actually remember very clearly early on in my time at thoughtbot, I was working on something and was working on it with Joe Ferris, who is the CTO of thoughtbot and a very clever individual, and I mean that in the truly positive sense of the term, one of the most capable engineers I've ever worked with. He was describing an anecdote, but it was basically he'd put up a pull request. And someone replied, "Oh, that's clever."

+ +

And Joe's reaction was, "Oh, crap." Just taking that as not an insult but as someone saying, oh, that's clever in a positive way, and Joe hearing that in the negative form of I went too far here, or this is not obvious in its initial interpretation. That really stuck in my head from there, just his reaction to it immediately of that being not a good thing. And I was like, that is interesting. And all the more so over time, I've come to believe that clever is probably something to avoid in code.

+ +

STEPH: Yeah, agreed. I'm at the point that if I do see someone who's done something that I do think is clever in a positive way, I will still abstain from using that word clever because I do want to make sure they don't think that I'm saying in a bad way that this is clever, that it's not readable, and it's not friendly. So I totally avoid that word when I'm complimenting someone's code just to make sure there's no confusion.

+ +

CHRIS: It's one of those words that got away from us that we lost the definition of, and then we came back, yeah.

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: Let's see. In other news, you had mentioned this earlier, and then I had mentioned my side of it but errors in alerting and all of those sorts of things. They're an interesting question. We had a small situation over the weekend that turned out to be kind of real, kind of not real. But I happened to be away on vacation. I did have my computer with me because, at this point, we're early enough. And I'm like, I'm going to take my computer everywhere and just be ready in case it's necessary.

+ +

And in this case, I did get a ping. I looked into it and what was unfortunate is it wasn't immediately obvious if something was broken or not. And to a certain degree, that's always going to be kind of true. There's so much noise, so many requests hitting a web application. And how do you tell the good ones from the bad ones? And ideally, I could threshold around certain volumes of traffic, but even that's going to have spikes, and ebbs and flows and things like that.

+ +

So it was very hard initially to understand is something actually broken? And then all the more so to understand what was broken. Thankfully, it was tractable. It was solvable. And we've done, I think, some good work especially considering how early on we are and how we've instrumented things in Sentry, in particular, our usage of Sentry and also somewhat in the logs.

+ +

But again, I think I've talked about this before, but I'm feeling this tension around there's data. There's data just kind of like, what happened? And right now, we've got logs. That's one of the places that goes to Sentry if it gets escalated up to that level. And we sort of have a weird Venn diagram between logs and Sentry. And then we also have analytics as another thing and then eventually data science, and what do we want to try and learn?

+ +

And all of these kinds of want different facets of it's not the same data set. But I wonder, is there a superset of data that then we could filter and slice and cut up, do all those sorts of things? I think this is the dream of Honeycomb and platforms like that, but I'm not even certain if that's true. And so I'm in that awkward middle space is how I would describe it.

+ +

But in that particular case, I was able to resolve it. I did take away as an action it's probably time to start thinking about PagerDuty anomaly detection, that sort of thing. When does alerting happen? When do engineers actually get calls when not just during the normal nine-to-five of the workday? So I'll be investigating that in the coming weeks and see where we get to. But it's sort of the first thing that really pushed us in that direction.

+ +

The other thing I'll say is we have the idea of the point dev, which I've talked about on a couple of episodes. But the idea is for each week, one individual on the engineering team is in charge of the noise, for lack of a better term. They're looking at the error stream in Sentry. They're looking at any ad hoc requests that are coming from our admin team, et cetera, et cetera. And that's been really great.

+ +

But one thing that I've noticed is that dealing with the errors is particularly tricky and what we did in this particular case was just to pair on that. As an individual, it is really hard to sometimes to reproduce, sometimes to just understand these are the things you didn't expect in your code, and therefore they are, by definition, harder to understand, harder to think about.

+ +

And then sometimes you get to an understanding. You're like, ah, what do we do about that? Do we care? Do we not care? Is this just noise? Is this something we should solve? Is it something we should solve soon? Or is this something we can solve whenever we get to it in the backlog? And making that sort of determination is all the harder.

+ +

And so I'm increasingly of the mind that there should be some amount of time that is pairing on that error backlog to bring two heads together. I hadn't been thinking of it this way, but I've now come around to thinking this is a really great place for pairing because it's so hard for one individual to deal with that complexity to make the hard value judgments. And to do that, if each individual does that in a vacuum, then we have n different value systems at play that are hopefully very similar.

+ +

But if we start to pair up, then there's osmosis between those groupings. And ideally, we sort of coalesce towards a shared value structure around, like, what can we ignore? What should we snooze for a week? What should we put in the backlog? What should we prioritize and fix immediately? Because I think those are really hard things to otherwise...that's really hard to document, I would say. I would love to write up a page in the Wiki that says, "This is how you treat errors," except each error is a unique snowflake, and you just have to follow your values.

+ +

STEPH: I have been on teams where we've written up documentation that helps you triage an error because you're right; you can't write documentation around a specific error. But that I always found really helpful where it was like, here's all the links that you can look at, here are some recommendations. When we were working on an application that was falling over more often, there were some specific outlines around if you see this problem, then this is typically how you can solve it. And then we had to fix that at a larger scale, but it was a nice band-aid to get us through at that point.

+ +

I like the idea of pairing, especially as you mentioned; it's tricky. It's funny when you mentioned capturing those errors and putting them into the backlog because I like that idea that then you can prioritize and bring those into the sprint. It just made me feel a bit hesitant. If we don't work on it now, we're never going to work on it. But then that feels unfair to say because it really comes down to the team.

+ +

If you have a team that's going to be able to look at those errors and say, "Yes, we're going to bring them in and prioritize them," then that feels really good to then be able to say, "This is an error. Let's capture it. Let's provide some content around it. But it doesn't need to be addressed at this moment. It's still pretty low in terms of risk for users or at least low in impact for users." So yeah, I guess it just depends as long as the team feels good about being able to prioritize errors, which I feel confident that your team would be able to do. And if you can't, then y'all could reassess that plan.

+ +

CHRIS: That's why we definitely have that. We're revisiting the errors. They're part of the same backlog as everything else. So they're coming up in relative priority and getting worked on and getting resolved. But we're also shifting our thinking just a little bit to say, "We should take a little bit more time in the moment to try and resolve some of these where we can." I have the dream of there are just zero bugs ever. But that's hard, especially in different platforms.

+ +

And we're seeing a lot of mobile traffic and from different older Android versions and so weird JavaScript edge cases and things like that. Like, why does your runtime not have object? That feels like a thing every JavaScript runtime should have. But that's a joke. Every JavaScript runtime, I'm pretty sure, does have object but that sort of thing. It's like, whoa, this is weird and specific to this one device. Cool, those are fun. So yeah, giving a little bit more time to do those.

+ +

And again, so we definitely do have the document that describes here are the places to look and how to think about this category of error and this category of error. But at the end of the day, you get one that's just like, there's not a ton of detail in the error. It's hard to reproduce. It might be device-specific, et cetera. And so what do you do in that moment? And that's where we're trying to...I think pairing is a great way to share that thinking around the team. So overall, it's been great, though. I think everyone who has been involved has been like, "This was better than when I did it on my own," so cool.

+ +

STEPH: Awesome. That sounds great.

+ +

CHRIS: Yeah, I think so. This is one of those ever-evolving facets of how we work as a team and how we build the platform. So I will certainly report more in future episodes, but for now, happy with that. And yeah, what else is up in your world?

+ +

STEPH: Yeah. So we've been looking specifically into tooling around how we're going to spin up more machines to process more RSpec tests. So specifically, we have around 80,000 RSpec tests that we are processing, and we have one machine that is parallelizing those and takes around just for that portion of the build because then there are other tests and things that get run that brings it up to about a total of 30 minutes.

+ +

But for the RSpec portion, I think it's probably around 20-ish minutes to process those 80,000 tests. So we split that across four different containers, and then we run those tests. And so we'd really like to spin up more machines to then process because we've reached the point that we have given as much power to that one machine as possible. So now we're looking to add more machines.

+ +

And one of those solutions that we're looking at is using Buildkite, which is built with the idea that you can add these build steps so then you can more easily say, "All right, once we get to this particular build step, hey Buildkite, we'd like to run n number of machines to process all these tests." And that seems really nice. And it is something that we are interested in. It is actually what Shopify uses. They use Buildkite ci-queue, which is built for mini-tests, which is what they use, and Redis to then run all of their tests.

+ +

But we are using TeamCity, so we're not using Buildkite. And we would like to see if we can grow with our current CI infrastructure versus having to move to a new one. There's a lot of just risk involved in moving to a new one. And so we've been studying hard if TeamCity will let us do this. And so far, the answer has been no.

+ +

But just recently, we found somewhere in the docs that it looks like there is a chance that with TeamCity, we can inform TeamCity that, hey, even though we have just this one build step, instead of only giving us one agent or one provisioned machine to then run these tests, instead that we actually want to spin up a couple of machines to then process these and then aggregate the results back to this one step. So we're looking into that.

+ +

But I wanted to throw this out there in case anybody else is also using TeamCity and has already invested in this particular approach. I would love to hear about it because we are currently figuring out the capabilities and if this is something that we can stay with our current infrastructure or if we're really going to have to look for a new solution.

+ +

CHRIS: Well, I'm hopeful that someone out there can give you some input. I definitely get the idea that you're stuck, and stuck is maybe too strong of a word. But if TeamCity is not ideal, the idea of moving off it does feel exceedingly heavy and the riskiness that you talked about. That's, I think, a critical word here because I think it's easy to think of CI as like it's a very important thing. But that's absolutely critical as part of your deploy pipeline, I assume.

+ +

This is speaking generically about CI, and so it is, in fact, a critical piece of the infrastructure. If you've got a bug on production and suddenly CI is down, what do you do? I guess you can test locally and decide you're going to push past it, but then you have to circumvent it. And so I understand the intentional way that you're thinking about that and the risk associated.

+ +

I do wonder, though, if TeamCity has felt like not the right platform for a while and if there are considerations. Is there the possibility of both trying to improve the world that you have now, so it's not the big move off of it but then also in parallel start to work on an alternative implementation? This is perhaps not entirely fair, but it feels like a Rails application is this repository of code. And typically, CI is configured via a file.

+ +

And that's like, if you've got your teamcity.yaml or whatever it happens to be, could there also be a buildkite.yaml that is not on the critical path for deploying or anything like that? But it is a way to, frankly, somewhat inefficiently test on two different platforms but start to see if you can get the code moving on a different platform and be able to gradually build out and make that transition possible without it being one big swap over sort of thing, which eventually it would need to be. But just wondering, is that happening in parallel? Is that a possibility?

+ +

STEPH: I think the short answer is, I'm sure there is. There's a way to look at the existing system and then find ways that we can tweak it. But I also know that the team has already invested a lot into working with the current system and making it as efficient as possible. So I don't know if there's any true big impact but intermediary steps that we can take. We are definitely in that proof of concept world. So we're not going to move anything over for the rest of the team until we can really prove that something is working for a small subset and then start to expand from there.

+ +

But currently, our idea is to dig further in TeamCity, which I think also includes just a call to their team and say, "Hey, we'd love to talk to one of your engineers and see if the thing that we're trying to do if it's possible. Let us know if it's not and if we need to look elsewhere," which is intriguing to me because having a lot of tests isn't new. There are tons of companies that have lots of tests, and they want their CI test suite to be fast.

+ +

So a company that then has built software that helps Team execute these steps that then the ability to say, "Hey, I want more machines to process. I want to give you more money and to give us more machines, and we can process more things." I feel like that should be a thing. And I'm getting at the edges of my knowledge. This is why we're exploring all of this. But it has been surprising to me to realize that that doesn't seem as easy of a thing as I would have expected it to be.

+ +

There are also some other concerns around here where the client that we're working with if we're going to work with third-party vendors, then we have to get special approval to work with them. It's not just a hey, we can just go try it out. It's a lengthy contract process that we'd have to go through. So there are also some constraints that we have to keep in mind where we can't just work with anyone. We need to be careful to make sure that they're certified in a particular way.

+ +

So yes, I like your idea. I will definitely keep it in mind. But I don't know if there are any true intermediary steps yet other than the building out a proof of concept and then finding small ways that we could move over. Then I think that would be ideal for sure. And then hopefully, if there's anybody that's listening that has experience with TeamCity or Buildkite, that's the other tool that we're looking at using, let me know. I would love to chat about it and find out your experience. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph is excited to be headed on a retreat with her mom in the mountains, but before that, she details how she helped troubleshoot a production issue with her team and appreciated their process. She's also looking into tooling around spinning up more machines to process more RSpec tests.

+ +

Chris had a developer start their new job at Sagewell and highlights how they involved the new person in rectifying potentially missing and/or confusing existing documentation. He also has a gripe, and that is accounts. Handling too many accounts. Additionally, he talks about triaging an error and how it was tough initially to understand if something was actually broken. And then it was even harder to understand what was broken. So he paired through it and used the power of putting two heads together.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris, I am going on vacation next week, and I am so excited about that. It's going to be pretty much a week long. It's like a Tuesday through Friday ordeal. And it's a trip that I'm taking with my mom. So over the past year, she's gotten super serious about her health and nutrition and done a phenomenal job of being very focused on a plant-based diet, which is basically healthy vegan food is what that comes down to.

+ +

So there is a retreat that's taking place in the North Carolina Mountains that she's really excited about. I'm going to go with her. We're going to do lots of cooking, and hiking, and hanging out in the mountains, and it's going to be lovely.

+ +

CHRIS: Well, that does sound lovely.

+ +

STEPH: Yeah, it seems like a really perfect time to disconnect just because you're headed into the mountains. So all you should take with you are books and things that are not iPhones, and tablets, and computers, and screens. So I'm looking forward to that, just to be away from screens for the week.

+ +

On some more technical news, this past week, I helped troubleshoot a production issue, which was a bit novel for me because the work that Joël and I are doing with our current project it's all in the testing realm. And so it was probably around 10:00 o'clock at night my time, and I got a ping on Slack. And it looked like I was getting called in for a production issue.

+ +

And I was like, I have touched zero production code. [laughs] So I'm very intrigued how I could have broken production at this point. And so I looked into it, and it turned out that it wasn't necessarily related to a commit that I had authored, but it was for a commit that I had reviewed and then approved. And so their strategy is they create a new channel. They'd gotten a ticket that an error was occurring.

+ +

And then the site reliability team created a new Slack channel, and then they pinged everybody who either authored, reviewed, and approved that change to be like, hey, we think the issue is related to this commit. Our plan is we'd like to roll it back. But before we do, we just want to check in with folks who have more knowledge to help us confirm that, yes, this error message seems related. And I really liked that approach.

+ +

I really like the idea that it's not just the person who merged the commit that then gets pinged on it, but it's like everybody else who happened to look at this and review it come help us too. So we spent some time looking into it, confirmed that yes, indeed, it was related to that particular commit. And then their team did the wonderful thing of then rolling it back. So then, it was no longer an escalated issue.

+ +

And so then I asked, "What else can I do to help?" And they said, "Well, from here, it's no longer a production issue. So tomorrow, just follow up with the author and let them know and issue a fix for the bug, and then merge it like normal." So we're back in that normal pull-request flow, very calm.

+ +

And overall, I just appreciated their process. I like very much how they pulled more people in because I think some of the other people that were involved weren't online, which makes sense because it was really late. So that way, you just spread in case some other people really aren't available that then hopefully you'll get lucky and one of those three or four people are available to help you troubleshoot.

+ +

CHRIS: That does sound like a really nice and thoughtful and intentional bug response, communication, procedure, rollback, et cetera. All of that sounds like it worked very well and is nice to have. And it's the sort of thing that a larger organization ideally gets to, having these sorts of processes. Spoiler alert, later in the episode, I will talk about the other side of it of being a very young organization and trying to be like, wait, is this a bug? Is this not a bug? Should we roll back? What do we do? That's actually my topic de jour.

+ +

But what you're describing sounds like the calm even in the case that there is a fire sort of like, yep, we've got procedures. We have workflows. We have communication channels and ways that even the exceptional things can be handled in an ideally as calm as possible way. So that's awesome that that's what you got to experience there.

+ +

STEPH: Yeah, getting called in at 10:00 o'clock is never fun for anybody. But when it happens, because it's going to happen, then I appreciate the thoughtfulness and that process that they put behind it. So it all went fairly smoothly. And it was also one of those fun things where I haven't met...like this is a very big organization, so I hadn't met any of those people.

+ +

So when I got pinged on it, and then I hopped in, I was like, hi, I don't know anything about this process and what y'all are doing, but I am here. I'm here to help. Where can I look? What can I do? So it was also a fun endeavor in that regard to just be like, I don't know what I'm doing, but I am here to help. Please let me know how I can help. And it ended up working pretty well. So yeah, that's been a fun adventure for this week. How about you? What's new in your world?

+ +

CHRIS: What is new in my world? Well, we had a developer start this week, which has been really wonderful. Unfortunately, we had scheduled their first day to be Monday, which was Presidents' Day, and that's a holiday. So we got out in front of that one and figured it out. We're like, no, no, actually, feel free to start on Tuesday. We'll not be around on Monday, so you shouldn't be around on Monday. But then, on Tuesday, they started.

+ +

And we intentionally structured things such that we have a contractor that has been working with us for like seven or eight months now. So it's been a long time and been very formative as well the work with that contractor. So this is their last week, and thus, we very purposefully brought the new person on the team and that contractor together to maximize the amount of pairing and overlap that we have there just to try and as intentionally as possible grab whatever is in their head, get another point of view.

+ +

Because this new individual on the team will be able to work with myself and the other full-time developer on the team a bunch moving forward, so we want to maximize their overlap with the person who is on their way out. But otherwise, it's been great. We're a young organization, so the version of onboarding it's me running around setting up a lot of accounts, forgetting to set up other ones, getting pings in Slack, and then following up and setting up another account. Eventually, I hope that there are checklists and formalizations and, ideally, one-click SSO magic that makes all of that work. But for now, I'm happy to chase it down.

+ +

But really, we're just leveraging pairing as much as possible as the onboarding tool to make sure that where we don't have formalization, procedures, documentation, et cetera, as thoroughly built out as I would love to be at, we can shore that up with some time with other humans.

+ +

STEPH: That's awesome. It's always fun having someone new to join to highlight all the things you need to automate or at least have a checklist for to then help them onboard. But that's really exciting that you've got a new teammate.

+ +

CHRIS: Yeah, definitely very exciting. And they've been great. They've hit the ground running and a couple of pull requests already and just contributing very effectively within their first couple of days. So that's always wonderful to see. We are definitely taking this moment to document what is undocumented or update the README where it needs to be and start to make that checklist. We have another person who will be starting in about two weeks’ time. And so, ideally, that will be even a little bit more fleshed out of a process. So slowly, incrementally get a little bit better with each we add that we get there.

+ +

STEPH: How much do you involve the new person in creating that documentation? Is that something that you ask them to help build, or is it something you take ownership of? What's that balance?

+ +

CHRIS: It's interesting. So definitely some I want to be with that person because I think it can often be the easy first PR is an update to the README for like, oh, I tried to set up the app, and it did not work. For this reason, I have now updated the README, and now there's a pull request. And we get to experience that flow via the very low-stakes change of updating the README. So that's a definite one that I like to have.

+ +

The other is I'll typically ask for the individual to capture as much as possible. There's a very delicate line in my mind between empowering them and being like, yes, absolutely. We're young. We don't have everything documented. So feel free to make changes where that makes sense to you. But at the same time, I know that joining a new team can be complicated, can be intimidating in certain ways. You're not sure what's okay to change? What's not okay to change? That sort of thing.

+ +

So I simultaneously don't want to put the pressure on someone to be like, "Yeah, no, change anything you want. Literally, nothing is stable here. Nothing's glued to the ground. So feel free to pick up anything and throw it out the window." That feels too far in my mind. So I don't have an actual answer like, I'm ideally calibrated at this point. But it's sort of those two tensions that I'm holding in mind as I think about that.

+ +

STEPH: Well, I really like your answer. I like that balance because I think it's really nice to include the person in those changes and also just because they're going through it. So they happen to have that insight, and it's fresh. But I agree, when you're joining a job, you want some stability and confidence that the people that you are joining that team with are also working hard to make it a very positive onboarding experience.

+ +

And if you just were to push all of that responsibility on to them to be like, "Yeah, we know. We don't have this organized yet. So you tell us everything that we need to do," that would feel unkind to that new person. I think as a new person that I wouldn't fully enjoy that. I don't mind some of it, but I wouldn't want all of it. I'd have nervousness around ownership, around improving processes, and who that belongs with.

+ +

CHRIS: Sort of a classic case of it depends, or it's a little from Column A, a little from Column B, but definitely some, just hopefully not too much.

+ +

STEPH: The Goldilocks of onboarding, some onboarding responsibilities, but not all of them, just the right amount. [laughs]

+ +

CHRIS: Shifting gears slightly, though, I just want to gripe for a minute. I'm just going to gripe. This is not my normal mode, but I'm going to lean into it.

+ +

STEPH: Do it.

+ +

CHRIS: Accounts, just accounts. I have so many accounts now. There are so many across different systems, and I'm trying to do the good thing, which is let's stop using personal accounts for anything and only use organizational accounts for the things that are for work. And some organizations do a great job with this.

+ +

GitHub, I'm looking at you; really well done, super happy with the way that you folks have implemented accounts. You get that I am one human being that contains multitudes. I am my personal self; I am my work self. I am maybe even another version of work, and you get that. And you usually let me exist as all of those versions of myself and, man, do I appreciate that.

+ +

Heroku, you're okay. Like, it's all right. You treat the different facets of me as different accounts, but that's okay. You make it relatively easy to switch between. Although you do make me two-factor auth and re-login every single day, and I don't love that. So I don't know what's going on there, but fine.

+ +

Trello, aka Atlassian, I guess at this point, come on, what are we doing? What's going on here? So originally, I had started, and I had the one Trello account, and I had my personal boards. And then there was the Sagewell organizational account. And within that, there were some boards, and I would just bounce back and forth.

+ +

But I realized, no, I need to do the right thing. So I created a new Trello account. And now Atlassian just forces me to switch between them, and it loses the link that I'm going to often. It's a different login interstitial screen. And it constantly shows me that like, hey, you don't have access to this. Do you want to switch accounts? And I say yes. And then they take me to a screen where I can pick between two options, the one that I was that didn't have the ability to do it and another.

+ +

And as a developer, I know that the thing I'm about to say is not fair. But come on, folks, you could know the answer to this question. There are two, and one is the wrong answer, so the other one is probably the right answer. You don't need to autolog me into that; I get it. Just emphasize it because they almost look identical on the list.

+ +

I have now accidentally tried to request access with my secondary account to my other account, and I can't get out of that state. So now, one of the ways that I try and do this it shows me a list of them to pick. The other it says, "You have requested access. We're waiting to hear back." And I'm like, no. So anyway, that's a thing.

+ +

STEPH: So I know people can't see me. [laughs] So I'll narrate that I'm dying over here because I very much appreciate that we are positive people. We are very focused on bringing positive energy, but the descent into the amount of shade that you're throwing at different applications [laughter] just really made my day, and I feel that pain.

+ +

I have felt that pain with Atlassian and can relate. And we should have some gripe sessions. This feels healthy. This feels very...okay, well, I don't know for you. I'm the one that's laughing and getting joy out of this. I don't know if it's helpful for you, but it feels very cathartic to me. [laughs]

+ +

CHRIS: It is definitely somewhat cathartic. I think there's utility in having these sorts of conversations. And throwing shade at Atlassian, whatever, they're doing fine, so I'm not super worried about it. But generally, we try and keep things positive because I think that's, frankly, a more effective way to communicate.

+ +

But occasionally, it is useful to look at the things where I'm like; that is a pattern that I do not want to repeat. And I'm sure that there are complex organizational enterprise-y reasons that it has to be this way. But I can look at that and say never that. That experience as a user is like, wow, yeah, I just tripped over nine layers of your enterprise there just trying to do very simple day-to-day things for myself. So I want to avoid that. I've griped about that one login, not the company OneLogin.

+ +

But that one login page that I've experienced where I start to interact with the form, and suddenly some JWT handshake in the background happens, and I'm now logged in. And it just rips the page out from underneath me. That is unacceptable. That is not okay. And I really do think there's something worth occasionally looking at those and being like, well, not that. But anyway, I should probably stop my gripe session now.

+ +

STEPH: [laughs] Well, if I may join in, I have one that I'd like to share. Since we're on this --

+ +

CHRIS: Throw it on the pile. What else we got? [laughs]

+ +

STEPH: [laughs] So there was some code. There was a piece of code that I was looking at that was very not friendly. It was difficult to understand. It took a while to parse through what are they actually doing? What records are they creating? Why did they choose this manner? Why are we iterating over these particular numbers? What's the outcome here? And I was pairing with Joël and was going back and forth having a conversation trying to be the detectives of why this code exists, and we finally got there. And we finally understood what it's doing and why. And I just lost it for a minute once we finally got there. [laughs]

+ +

I just thought the way this code is written, it does not improve readability, and it doesn't improve performance. All it did was make my life harder because it was very difficult to read. So all they did was become really clever with the code that they were writing and essentially drying it up, which I have such a beef with DRY because it has caused me pain. And so they essentially were drying up their code or introducing a way to make it just take up fewer lines that took up less vertical space. But overall, I was very grumpy about it.

+ +

And Joël was very kind about it and was like, "Well, this is the type of code I could see maybe why they did this." But you're right; it doesn't help with readability and performance. And he was helping balance out my grumpy goose moment. I've been having a lot this week; maybe it's just the week I'm in. I'm in more of a fiery mode this week [laughs] with some of the code that I'm seeing, and that was one of them. That was the please, please, please don't DRY up your code. If it doesn't improve readability or performance, there's just no need. There is no benefit.

+ +

CHRIS: Well, I definitely know that feeling. And I think I've probably, as a developer, gone through that arc where early on I was just trying to make stuff work, and then I learned how to be clever. And suddenly, being clever became a game that I could play.

+ +

And then, pretty early on, I realized I would come back to my own code from two weeks ago and be like, what the heck does this do? I have no idea. And that's when I was drawn to Ruby. That was one of the things. I'm like, oh, I can write code that looks so much like the clear words that I have in my head about the thing. I like that. And so much of my career has been spent in the let's make it obvious and revisitable.

+ +

I actually remember very clearly early on in my time at thoughtbot, I was working on something and was working on it with Joe Ferris, who is the CTO of thoughtbot and a very clever individual, and I mean that in the truly positive sense of the term, one of the most capable engineers I've ever worked with. He was describing an anecdote, but it was basically he'd put up a pull request. And someone replied, "Oh, that's clever."

+ +

And Joe's reaction was, "Oh, crap." Just taking that as not an insult but as someone saying, oh, that's clever in a positive way, and Joe hearing that in the negative form of I went too far here, or this is not obvious in its initial interpretation. That really stuck in my head from there, just his reaction to it immediately of that being not a good thing. And I was like, that is interesting. And all the more so over time, I've come to believe that clever is probably something to avoid in code.

+ +

STEPH: Yeah, agreed. I'm at the point that if I do see someone who's done something that I do think is clever in a positive way, I will still abstain from using that word clever because I do want to make sure they don't think that I'm saying in a bad way that this is clever, that it's not readable, and it's not friendly. So I totally avoid that word when I'm complimenting someone's code just to make sure there's no confusion.

+ +

CHRIS: It's one of those words that got away from us that we lost the definition of, and then we came back, yeah.

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: Let's see. In other news, you had mentioned this earlier, and then I had mentioned my side of it but errors in alerting and all of those sorts of things. They're an interesting question. We had a small situation over the weekend that turned out to be kind of real, kind of not real. But I happened to be away on vacation. I did have my computer with me because, at this point, we're early enough. And I'm like, I'm going to take my computer everywhere and just be ready in case it's necessary.

+ +

And in this case, I did get a ping. I looked into it and what was unfortunate is it wasn't immediately obvious if something was broken or not. And to a certain degree, that's always going to be kind of true. There's so much noise, so many requests hitting a web application. And how do you tell the good ones from the bad ones? And ideally, I could threshold around certain volumes of traffic, but even that's going to have spikes, and ebbs and flows and things like that.

+ +

So it was very hard initially to understand is something actually broken? And then all the more so to understand what was broken. Thankfully, it was tractable. It was solvable. And we've done, I think, some good work especially considering how early on we are and how we've instrumented things in Sentry, in particular, our usage of Sentry and also somewhat in the logs.

+ +

But again, I think I've talked about this before, but I'm feeling this tension around there's data. There's data just kind of like, what happened? And right now, we've got logs. That's one of the places that goes to Sentry if it gets escalated up to that level. And we sort of have a weird Venn diagram between logs and Sentry. And then we also have analytics as another thing and then eventually data science, and what do we want to try and learn?

+ +

And all of these kinds of want different facets of it's not the same data set. But I wonder, is there a superset of data that then we could filter and slice and cut up, do all those sorts of things? I think this is the dream of Honeycomb and platforms like that, but I'm not even certain if that's true. And so I'm in that awkward middle space is how I would describe it.

+ +

But in that particular case, I was able to resolve it. I did take away as an action it's probably time to start thinking about PagerDuty anomaly detection, that sort of thing. When does alerting happen? When do engineers actually get calls when not just during the normal nine-to-five of the workday? So I'll be investigating that in the coming weeks and see where we get to. But it's sort of the first thing that really pushed us in that direction.

+ +

The other thing I'll say is we have the idea of the point dev, which I've talked about on a couple of episodes. But the idea is for each week, one individual on the engineering team is in charge of the noise, for lack of a better term. They're looking at the error stream in Sentry. They're looking at any ad hoc requests that are coming from our admin team, et cetera, et cetera. And that's been really great.

+ +

But one thing that I've noticed is that dealing with the errors is particularly tricky and what we did in this particular case was just to pair on that. As an individual, it is really hard to sometimes to reproduce, sometimes to just understand these are the things you didn't expect in your code, and therefore they are, by definition, harder to understand, harder to think about.

+ +

And then sometimes you get to an understanding. You're like, ah, what do we do about that? Do we care? Do we not care? Is this just noise? Is this something we should solve? Is it something we should solve soon? Or is this something we can solve whenever we get to it in the backlog? And making that sort of determination is all the harder.

+ +

And so I'm increasingly of the mind that there should be some amount of time that is pairing on that error backlog to bring two heads together. I hadn't been thinking of it this way, but I've now come around to thinking this is a really great place for pairing because it's so hard for one individual to deal with that complexity to make the hard value judgments. And to do that, if each individual does that in a vacuum, then we have n different value systems at play that are hopefully very similar.

+ +

But if we start to pair up, then there's osmosis between those groupings. And ideally, we sort of coalesce towards a shared value structure around, like, what can we ignore? What should we snooze for a week? What should we put in the backlog? What should we prioritize and fix immediately? Because I think those are really hard things to otherwise...that's really hard to document, I would say. I would love to write up a page in the Wiki that says, "This is how you treat errors," except each error is a unique snowflake, and you just have to follow your values.

+ +

STEPH: I have been on teams where we've written up documentation that helps you triage an error because you're right; you can't write documentation around a specific error. But that I always found really helpful where it was like, here's all the links that you can look at, here are some recommendations. When we were working on an application that was falling over more often, there were some specific outlines around if you see this problem, then this is typically how you can solve it. And then we had to fix that at a larger scale, but it was a nice band-aid to get us through at that point.

+ +

I like the idea of pairing, especially as you mentioned; it's tricky. It's funny when you mentioned capturing those errors and putting them into the backlog because I like that idea that then you can prioritize and bring those into the sprint. It just made me feel a bit hesitant. If we don't work on it now, we're never going to work on it. But then that feels unfair to say because it really comes down to the team.

+ +

If you have a team that's going to be able to look at those errors and say, "Yes, we're going to bring them in and prioritize them," then that feels really good to then be able to say, "This is an error. Let's capture it. Let's provide some content around it. But it doesn't need to be addressed at this moment. It's still pretty low in terms of risk for users or at least low in impact for users." So yeah, I guess it just depends as long as the team feels good about being able to prioritize errors, which I feel confident that your team would be able to do. And if you can't, then y'all could reassess that plan.

+ +

CHRIS: That's why we definitely have that. We're revisiting the errors. They're part of the same backlog as everything else. So they're coming up in relative priority and getting worked on and getting resolved. But we're also shifting our thinking just a little bit to say, "We should take a little bit more time in the moment to try and resolve some of these where we can." I have the dream of there are just zero bugs ever. But that's hard, especially in different platforms.

+ +

And we're seeing a lot of mobile traffic and from different older Android versions and so weird JavaScript edge cases and things like that. Like, why does your runtime not have object? That feels like a thing every JavaScript runtime should have. But that's a joke. Every JavaScript runtime, I'm pretty sure, does have object but that sort of thing. It's like, whoa, this is weird and specific to this one device. Cool, those are fun. So yeah, giving a little bit more time to do those.

+ +

And again, so we definitely do have the document that describes here are the places to look and how to think about this category of error and this category of error. But at the end of the day, you get one that's just like, there's not a ton of detail in the error. It's hard to reproduce. It might be device-specific, et cetera. And so what do you do in that moment? And that's where we're trying to...I think pairing is a great way to share that thinking around the team. So overall, it's been great, though. I think everyone who has been involved has been like, "This was better than when I did it on my own," so cool.

+ +

STEPH: Awesome. That sounds great.

+ +

CHRIS: Yeah, I think so. This is one of those ever-evolving facets of how we work as a team and how we build the platform. So I will certainly report more in future episodes, but for now, happy with that. And yeah, what else is up in your world?

+ +

STEPH: Yeah. So we've been looking specifically into tooling around how we're going to spin up more machines to process more RSpec tests. So specifically, we have around 80,000 RSpec tests that we are processing, and we have one machine that is parallelizing those and takes around just for that portion of the build because then there are other tests and things that get run that brings it up to about a total of 30 minutes.

+ +

But for the RSpec portion, I think it's probably around 20-ish minutes to process those 80,000 tests. So we split that across four different containers, and then we run those tests. And so we'd really like to spin up more machines to then process because we've reached the point that we have given as much power to that one machine as possible. So now we're looking to add more machines.

+ +

And one of those solutions that we're looking at is using Buildkite, which is built with the idea that you can add these build steps so then you can more easily say, "All right, once we get to this particular build step, hey Buildkite, we'd like to run n number of machines to process all these tests." And that seems really nice. And it is something that we are interested in. It is actually what Shopify uses. They use Buildkite ci-queue, which is built for mini-tests, which is what they use, and Redis to then run all of their tests.

+ +

But we are using TeamCity, so we're not using Buildkite. And we would like to see if we can grow with our current CI infrastructure versus having to move to a new one. There's a lot of just risk involved in moving to a new one. And so we've been studying hard if TeamCity will let us do this. And so far, the answer has been no.

+ +

But just recently, we found somewhere in the docs that it looks like there is a chance that with TeamCity, we can inform TeamCity that, hey, even though we have just this one build step, instead of only giving us one agent or one provisioned machine to then run these tests, instead that we actually want to spin up a couple of machines to then process these and then aggregate the results back to this one step. So we're looking into that.

+ +

But I wanted to throw this out there in case anybody else is also using TeamCity and has already invested in this particular approach. I would love to hear about it because we are currently figuring out the capabilities and if this is something that we can stay with our current infrastructure or if we're really going to have to look for a new solution.

+ +

CHRIS: Well, I'm hopeful that someone out there can give you some input. I definitely get the idea that you're stuck, and stuck is maybe too strong of a word. But if TeamCity is not ideal, the idea of moving off it does feel exceedingly heavy and the riskiness that you talked about. That's, I think, a critical word here because I think it's easy to think of CI as like it's a very important thing. But that's absolutely critical as part of your deploy pipeline, I assume.

+ +

This is speaking generically about CI, and so it is, in fact, a critical piece of the infrastructure. If you've got a bug on production and suddenly CI is down, what do you do? I guess you can test locally and decide you're going to push past it, but then you have to circumvent it. And so I understand the intentional way that you're thinking about that and the risk associated.

+ +

I do wonder, though, if TeamCity has felt like not the right platform for a while and if there are considerations. Is there the possibility of both trying to improve the world that you have now, so it's not the big move off of it but then also in parallel start to work on an alternative implementation? This is perhaps not entirely fair, but it feels like a Rails application is this repository of code. And typically, CI is configured via a file.

+ +

And that's like, if you've got your teamcity.yaml or whatever it happens to be, could there also be a buildkite.yaml that is not on the critical path for deploying or anything like that? But it is a way to, frankly, somewhat inefficiently test on two different platforms but start to see if you can get the code moving on a different platform and be able to gradually build out and make that transition possible without it being one big swap over sort of thing, which eventually it would need to be. But just wondering, is that happening in parallel? Is that a possibility?

+ +

STEPH: I think the short answer is, I'm sure there is. There's a way to look at the existing system and then find ways that we can tweak it. But I also know that the team has already invested a lot into working with the current system and making it as efficient as possible. So I don't know if there's any true big impact but intermediary steps that we can take. We are definitely in that proof of concept world. So we're not going to move anything over for the rest of the team until we can really prove that something is working for a small subset and then start to expand from there.

+ +

But currently, our idea is to dig further in TeamCity, which I think also includes just a call to their team and say, "Hey, we'd love to talk to one of your engineers and see if the thing that we're trying to do if it's possible. Let us know if it's not and if we need to look elsewhere," which is intriguing to me because having a lot of tests isn't new. There are tons of companies that have lots of tests, and they want their CI test suite to be fast.

+ +

So a company that then has built software that helps Team execute these steps that then the ability to say, "Hey, I want more machines to process. I want to give you more money and to give us more machines, and we can process more things." I feel like that should be a thing. And I'm getting at the edges of my knowledge. This is why we're exploring all of this. But it has been surprising to me to realize that that doesn't seem as easy of a thing as I would have expected it to be.

+ +

There are also some other concerns around here where the client that we're working with if we're going to work with third-party vendors, then we have to get special approval to work with them. It's not just a hey, we can just go try it out. It's a lengthy contract process that we'd have to go through. So there are also some constraints that we have to keep in mind where we can't just work with anyone. We need to be careful to make sure that they're certified in a particular way.

+ +

So yes, I like your idea. I will definitely keep it in mind. But I don't know if there are any true intermediary steps yet other than the building out a proof of concept and then finding small ways that we could move over. Then I think that would be ideal for sure. And then hopefully, if there's anybody that's listening that has experience with TeamCity or Buildkite, that's the other tool that we're looking at using, let me know. I would love to chat about it and find out your experience. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+REVuOcUo + + ]]> + + Chris Toomey + Steph Viccari + + + 328: Terrible Simplicity + https://bikeshed.thoughtbot.com/328 + 5f2a1c09-8a1a-442c-aae1-e5b6abdf0a66 + Tue, 01 Mar 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Chris is helping with efforts to introduce security, practices, and policies at Sagewell. Right now, they are refining the usage of 1Password to standardize passwords and secure information. He also shares (what he believes) is a terrible idea around fixing inconsistencies around symbols and strings. + +Steph shares an update around factories. + +Also, at Sagewell, Chris is helping to build mobile apps, one for iOS and one for Android, and is considering pursuing having them be all native. Good idea? Terrible idea? Chris and Steph riff on that a bit. + 52:36 + no + + + Chris is helping with efforts to introduce security, practices, and policies at Sagewell. Right now, they are refining the usage of 1Password to standardize passwords and secure information. He also shares (what he believes) is a terrible idea around fixing inconsistencies around symbols and strings. +Steph shares an update around factories. +Also, at Sagewell, Chris is helping to build mobile apps, one for iOS and one for Android, and is considering pursuing having them be all native. Good idea? Terrible idea? Chris and Steph riff on that a bit. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. +GitHub - alassek/activerecord-pg_enum (https://github.com/alassek/activerecord-pg_enum): Integrate PostgreSQL's enumerated types with the Rails enum feature +Feature #7792: Make symbols and strings the same thing (https://bugs.ruby-lang.org/issues/7792) - Ruby master - Ruby Issue Tracking System +RailsConf 2016 - Turbolinks 5: I Can’t Believe It’s Not Native! by Sam Stephenson (https://www.youtube.com/watch?v=SWEts0rlezA) +GitHub - hotwired/turbo-ios (https://github.com/hotwired/turbo-ios): iOS framework for making Turbo native apps +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Weird stuff happens when we sing, Steph. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? +CHRIS: Hello, Steph. What is new in my world? We are continuing with some of the efforts that we're doing to introduce security, and practices, and policies, and all those fun sorts of things at the organization. One of the things that this is pushing on is we are further refining our usage of 1Password at the company as a way to standardize passwords and secure information and how we store that, how we move it around, as well as integrating SSL, and all those other fun fancier things. +But I'm personally historically a LastPass user, and now I'm getting to experience 1Password. So now I'm a child of two worlds, and it's terrible, and I hate it. I hate every moment of this existence. So what I need to do is move over to 1Password, but now I'm in that space where I'm like, I can see the flaws of both systems. This is terrible. I don't like it. 1Password does seem to be great; I will say that. There's one really interesting thing about 1Password. I'm interested...you're a 1Password user, right? +STEPH: I'm not; I use LastPass. I'm also a child of two worlds because we use 1Password for thoughtbot stuff, but then I use LastPass for my stuff. +CHRIS: Gotcha. Okay, so you survive in the middle space. I'm slowly trying to move everything over because I think 1Password has a little bit more of what I'm going for. And I would like, frankly, to be in one cohesive, consistent space, although having two different accounts seems interesting. I definitely can handle it. But knowing which I'm in and how to save a password to one versus the other, it's a whole thing. +The one thing that I find really interesting though is 1Password has a feature where it will do two-factor, two-factor authentication. It will do that for you. Specifically, it's doing, as far as I can tell, the TOTP. I don't know what that acronym stands for, but it's the fancy type of two-factor, so not SMS, not text message-based, and not others like WebAuthn is a thing that I've heard of, which I don't know if that is distinct from YubiKey or hardware keys. So there's a bunch I'm trying to learn about this space a little bit more. +I'm very interested in the hardware keys because those seem cool. WebAuthn seems like a new standard. That sounds cool. Don't know anything about it, though. So mostly, I know about SMS, and I do not like that one. I do not want to use text messages because, as far as I understand it, they're not super secure. So that's not the space I want to be in. But the TOTP, the Google Authenticator, or Authy, or that space of password or two-factor code generation tools those seem good. +And 1Password has a feature where they're like, hey, yeah, sure, we'll have your password and your two-factor. And so they grab the QR code, which is typically the QR code is a way, as far as I understand it, to share the seed. And then, that seed is used by an algorithm to generate the current code value for a given point in time. So it takes like, given that seed and the current timestamp, we will generate you the relevant code, which can then be verified on the far side. But that seed only exists for one moment in time, et cetera, et cetera. +But I've always thought of it as this separate thing. The idea of having that all in one system is interesting and kind of scary to me. But as I think about it, I'm like, if 1Password or LastPass, in either case, gets compromised, we're all done. Like, this is over. We should throw in our cards, give away the internet. This whole experiment has failed is my sense. But it was very interesting because I had not seen this. I've always had these as separate systems. +So for me, I have had LastPass, and I have Authy on my phone for the two-factor. But it's frankly very clunky, and I don't like it. And the 1Password thing is fantastic where I say like, yeah, 1Password, fill in my password and username, and then also fill in my two-factor because you have it. This is great. But, and this is where I hesitate, and I don't know, I will say this: I trust that 1Password has thought about this deeply way more than I can and have come to a place of deep confidence that this is a fine and okay thing to do. But I'm still intrigued. What's going on here? +STEPH: That was a lot. I have so many thoughts. [laughs] +CHRIS: Sorry, that was a lot of words, a lot of ideas, a lot of space there. It's just where I'm at. +STEPH: People couldn't hear me, but I was laughing when you were talking about LastPass or if these accounts get hacked in. And I'm imagining someone who uses the combination of their cat's name and their birthday as their password and then like, aha, I win. [laughs] It's like, no, we just all lose. [laughs] But that amused me. +Going back, you talked about having it all in one place. And that actually doesn't surprise me that we're different in this area. Because you also like all of your email...you like one source of everything, which makes so much sense, but I'm different. And with these accounts, I like that I have the distinction between all of thoughtbot is in 1Password while all of mine is in LastPass because it's just a very clear delineation between those two accounts. And I'm sure both of these platforms have figured out a really good way to then separate those two. +But I just remembered there was someone at thoughtbot that accidentally...because they have everything in 1Password, they accidentally shared their personal vault with a client. And so they were just typing in Slack. They're like, "Oh, shit, oh shit, like, how do I undo this?" And we're all just watching like, "We don't know. But please let us know how it turns out." [laughs] It turned out fine. I think they actually realized they hadn't fully shared it but based on the UI they thought that they had. So it all turned out okay. So that just lives with me. I'm a little scared of that now now that I know that story. So watch out, friends. +CHRIS: Oh, wow. Well, now, yeah, I'm also now scared of that. I wasn't, but now I am. +STEPH: And I forgot the other thoughts now. Those were my two main thoughts based on the journey that you've shared. +CHRIS: Particular to the thing you were sharing there, yes, now I will have nightmares about it. But also, it feels manageable because they're both entirely different accounts, and then also within that, there are different vaults. So as I'm building up the password infrastructure at Sagewell, there's going to be different...like, the dev team will probably have one vault and then a shared vault for the dev team. And then other teams within the organization will have that. And so it feels like there are at least structures within the tool to manage that. +But mostly, my consideration is around the two-factor thing. And like, is this reasonable to do? And again, I'm sure 1Password has thought way harder than I have about it. And I trust that they're like, yeah, this seems fine that they're not just like, I don't know, it doesn't seem bad. They're like, no, no, definitively for information-theoretic reasons, this is fine. But it was surprising. +STEPH: That was it. The other comment that you made about two-factor auth that resonated with me because there was a point not that long ago where we have one of those, either New Relic or I forget which account it was, but it was with the systems. We really only needed one person to have access, but every now and then, someone else may need to access that account. And so we wanted to be able to store it in 1Password or LastPass somewhere like that. +But then the two-factor auth was a problem because then you had to coordinate with that other person to say, "Hey, I just need to check something. Would you let me in?" And because we could then leverage that feature, then we could just store all of it. And then that person could just go to 1Password or LastPass and then have access to all of it, and that was really nice. That was a very nice solution to I want to say it was a small problem but yet also very important for team happiness. So that was really nice. +CHRIS: The amount of times that I've been like, "I just tried to sign in to the shared account, and it says that it sent a two-factor request to somebody's phone, but it didn't tell me whose phone. And I'm not sure if we know who that person is or if that person's still around," that version of the story feels true. And so, the idea of being able to centralize two-factor seems great. It almost feels too good to be true, is perhaps where I'm at. I am putting on my tinfoil hat, and I'm saying, yeah, but oh man, security, though. +And again, I will 100% defer to 1Password on this. They've thought about it. But it's mostly I want to get to the place where I understand the thought process that they went through to decide that this is perfectly fine because they definitely did that work. I'm certain of that. I just want to read a white paper or something, and I haven't found it yet. [laughs] I'm like, let me get to that deep place of trust because that's what I want to be at with security tooling and those sorts of things. +STEPH: Yeah, I haven't looked for something like that, but that sounds...I'm kind of surprised that doesn't exist. +CHRIS: Oh, it quite possibly exists. I haven't done much of a search, frankly, at all. Mostly, I'm in the space of like, huh, that's weird and then moving on with my day. Because there's not a lot of free time to go search for the white papers on the internet. But yeah, so moving from 1Password or LastPass or 1Password, or maybe I'll just end up with both for a while. I really hope I don't end up in that space, although you're describing it as a positive, so maybe I will. +STEPH: I have found it helpful for me. When you find that white paper, because you are more likely the type of person to read that white paper than I am the type of person to read it, then I would love a summary. That would be much appreciated. +CHRIS: I'm so intrigued by the persona that you're describing of me of; like, you're the kind of person who would read a white paper. I'm like, well, I don't know if that feels true or if it's definitely true or definitely not true. But if I do happen to find it, and especially if I happen to read it, [laughs], I will share it with you and perhaps with the listeners as well. +Let's see, one other small thing. I have a bad idea. I don't want to share the bad idea with you. I want to more share it with the audience, and then I want the audience to tell me exactly how bad of an idea it is. +STEPH: [laughs] +CHRIS: Because I'm sure it's a bad idea. I'm just not sure how bad. +STEPH: I love that there's not even a scale of goodness here. It's just nope, this is terrible, but I don't know how terrible it is. [laughs] +CHRIS: What's fun is in the later parts of this episode, we're going to go into a segment of good idea, bad idea, sorry, good idea, terrible idea because I like that framing. No, this one is firmly bad idea, but how bad is the question. So we're working on the app, and we keep running into inconsistencies around symbols and strings. +As any Rubyist who has worked in the language for any amount of time, especially in a Rails app, you have experienced this unpleasantness. There are strings; there are symbols. They're often used somewhat interchangeably, and yet they're different. You’ll hit bugs. You'll hit edge cases. You'll hit nils that you didn't expect to be there because you tried to fetch a symbol. It, in fact, was a string, et cetera. +So, what if we just applied HashWithIndifferentAccess everywhere, just deep in the internals of the app or in the Ruby runtime? What if we were to just turn this on? My sense is this would be terrible for performance reasons. My understanding is that's why symbols exist is because they are a more performant mechanism. Strings are complicated within the object model of Ruby because they're mutable. These are things that I understand very loosely, as you can tell by the tone of voice that I'm using. But symbols and strings they're separate. They're separate for reasons, performance I believe to be the main reason. +But what if we were to just say, well, what if it could be like easy, though? That's what I want. Like, this is the promise of Ruby is that I want to express my code in a way that feels like the words I would use to describe to another human. That's the way I always think of Ruby is it's as close to the words I would use to describe the sort of business logic as possible. And yet these symbols versus strings thing it's just annoying, frankly. And again, I think very good reasons for it, I'm sure. +But what if we were to just do the silly thing and turn on HashWithIndifferentAccess for everything? I don't even know that that's fundamentally possible. I don't know that there's the relevant hook or the way to do that. But I would love that because we're using it somewhat regularly throughout our app right now, where we're getting data from one API. And in our test suite, it's one way, and in our code, it's the other way. And granted, that speaks to us being inconsistent in our usage. But overall, I would just love for this to not be a thing. +And so, how bad of an idea would it be? How much of a performance hit? That's my guess as to what it would be. Maybe there's actual fundamental correctness that would go wrong here. But my sense is by collapsing the space together; we would actually get more correct. I don't know. Anyway, how bad do you think of an idea this is? +STEPH: I was thinking through some of the bugs that you're running into. And I think you provided some nice insight around that around it's the fact that you're fetching data from API. So it's typically you're parsing. That's how you're getting the string and symbol differences is because when you're parsing JSON and then you have a mixed case of maybe you have a symbol, maybe you have a string, or maybe you're parsing it differently. Are there other places in the application where that's a concern? +CHRIS: I want to say one other place that we're running into it specifically is we're using a lot of enums, particularly ActiveRecord::PGEnum backed enums. So these are Postgres enums at the database level. And then, within our Rails models, we define them as enums. And the enum is typically defined within the model as a mapping of symbol to string. It could be symbol to symbol. I'm not even sure. I think this might be in terms of our implementation. +But you say like, it's an enum. The key is foobar with an underscore, and it's a symbol, and then the value is foobar, but it's a string. And maybe both the key and the value could be symbols; maybe that's a thing, maybe this is our fault. But certain times, when you're interacting with the value, it's a symbol. Certain times I find it to be a string. I feel like that's true. I don't think I'm making that up. [laughs] It's possible I'm making it up. +But that's another place where I feel that inconsistency or other values within the system that like as they go through certain type coercion layers, they'll start as a symbol, and then they get saved to the database, and then they get reflected back, and they come back as a string. And it's like, well, that's unfortunate. It was a symbol a minute ago, and now it's a string. And so our tests suddenly break in this way, or our code is inconsistent. And it's enough of a nuisance that I had the bad idea the other day. And so, I wanted to bring the bad idea to this space. +STEPH: I think you're right. I think the main reasoning for not having everything just be strings is for looking for that performance benefit. And so then using that HashWithIndifferentAccess then you'd have to loop over everything and then convert it. So I imagine, like you said, there would be a performance hit there. I don't know how bad of an idea it would be. +But when you said this, it brought up a memory because I remember someone proposing or the Ruby community talking about the fact, like, what if we didn't have strings? What if everything was just a symbol? Or can we just have one over the other? And there is a ruby-lang issue; it is 7792. And we shall also put it in the show notes and send it to you. [chuckles] And this person is proposing make symbols and strings the same thing. +And then some people call out specifically the idea of using HashWithIndifferentAccess and saying, yes, that works wonderfully, but then you are going to have a performance hit for it. So it sounds exactly like everything you're saying. I don't know the outcome. I mean, clearly, the outcome is we're not there. But it seems like a really good place to see the reasoning or different approaches that maybe people have tried in this space. +CHRIS: Ooh, I love that. I definitely want to read that and see what sort of deeper thinking folks have done on this. Because again, this feels like another one where definitely folks have thought about this, folks who know more about it and have chosen the current path that we're on for reasons. But I would be really intrigued if I could be like, yeah, I would just like it to be easy to start, and then have the performance optimization be something that I could opt into. Again, that's probably not tractable within the language. +Like, oh, we have a hot code path here that we want to actually have immutable symbols only. And that's the sort of thing if we've done this HashWithIndifferentAccess everywhere, you can't back out of it. And so, therefore, you're stuck in a performance low point. That feels like a bad case. And so maybe that's the reason is like, you will shoot yourself in the foot with this definitely. +But yeah, I'm intrigued. So I will definitely read what you're sharing here. And we'll include it in the show notes, of course. I'm probably not going to do this, just saying that out loud because it seems like a bad idea. I just want to know how bad of an idea. +STEPH: I do love it, for when I'm building a class that's working specifically closely with an API, I do reach for HashWithIndifferentAccess frequently. Because like you said, I just don't want to worry about it. I want to set it up top. It's one of the rare times that I actually will use something in an initializer where I'm like, hey, pass in the data. I'm just going to run it through this method. And then all the data from here on forward you can access it in either way. So the class doesn't have to care; a tester doesn't have to care. So I do feel your pain, or I at least will always reach for it whenever I'm building a class specifically around interactions with JSON. +CHRIS: So for a segment that I framed as how terrible of an idea this is, you're like, hmm, I don't know how terrible. That seems to be your take, which is interesting. +STEPH: Good point. Let me assess for a moment. I'm going to go just from skimming this issue, although I think partially this issue is talking about the fact that if you merge symbols and strings, it's like, hey, friend, you're going to break a ton of stuff and break a bunch of libraries, and these two things do serve a purpose. So this may not be exactly what you're looking for, but it has some interesting conversation on there. +But embedding it deep down in the app so that just happens naturally sounds like it's just a performance concern. So yeah, it comes down to what is the question? How big is the performance? So I feel like I can't say it's a terrible idea until I actually know what the performance hit is. +CHRIS: So a plausible question. That's where we're going to put this in the category of. [laughter] +STEPH: Plausibly terrible, but still worth researching. +CHRIS: Not obviously not terrible. But anyway, these are some of the ideas at the top of my head right now. That's a rough summary of my week. +Mid-roll Ad +Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. +All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. +So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. +That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. +So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. +STEPH: I have an update that I can share around factories because the last time we were chatting, I was sharing that strategy that we're pursuing where we're trying to minimize factories and then speed up the CI time by reducing the work that those factories are doing. So Joël Quenneville has done some phenomenal work and this past week, specifically improving factories. And he found one particular factory that he was digging into. +So some stats before the change. The factory was taking around two seconds, which I know on paper doesn't sound so bad, but it gets more interesting. So total database time is around 1,000 milliseconds. And 833 total database queries were being made, which includes reads, creates, and updates. So then after, Joël was diving into this looking mainly to reduce the number of database queries because that's such a big number. +So after the change, which took a lot of research on Joël's part, the factory is now taking around one second, so half of that time. The total database time is around 666 milliseconds. And the total database queries went from 833 down to 647, so a nice improvement there. But the real wonderful outcome of the story is not just those stats, but okay, so how did we impact CI? So we spent time working on this factory. And we have reduced, and we can see some of that in the stats. But how does that apply to the bigger picture? +And so Joël took the time of the last 20 successful builds, and based on those builds, we average 27 minutes and 37 seconds for each build. With the factory change that he made, that same test suite was now averaging 21 minutes and 33 seconds. So shaved off six minutes from the build time, which is about a 22% decrease in the build time which is just fabulous. So that was a really nice win from all the work that had been invested in improving that one factory. +CHRIS: That's a heck of a haircut there so glad to see that the efforts are paying off. +STEPH: Yeah, it was a really nice win to see that we had researched which factories we should pursue, and then we were methodical about that. And then Joël worked hard to improve this factory and saw such a large payoff. It's one of those areas where the team has already invested a lot of effort and hours into improving the test suite. And it's challenging when you have so many areas that you'd like to improve and 100-plus engineers also contributing to that same codebase. So how do you improve and keep up with it all at once? +They had spent about a year, so I think they were recognizing that yes, there are still a lot of areas to improve but also felt like small efforts wouldn't move the needle. So it was a nice data point to remind ourselves that we can still reduce the CI build time in a significant way. We just need to be very strategic about where we invest our time in those improvements. +There is also an interesting conversation that Joël and I were having because we have a daily sync with each other each day. We've now been embedded with a team with a client, which is wonderful, but before then, we were also chatting with each other. And we like to chat about code, so we've had lots of fun conversations around code. And one, in particular, this week, came up about how people view code differently. And there's even a tweet that Joël shared that I can link to in the show notes. +And there's one view that code is a liability, and if a line can't justify its existence, then it should be deleted. And then there's another view that code is an asset. If a line isn't causing any immediate issues, then why not keep it? And part of the reason that came up was while I was going through and reading pull requests, there was a particular change where someone was memoizing an expensive call, which was great, something that we wanted to do. +But then they were also memoizing a very fast operation in two other places where it was just like parsing some params something that, you know, superfast and only getting called in maybe two places. And it was one of those that just caught my attention to be like, hey, I love that you memoized this other call, but this one, I don't think we need the additional overhead or complexity of adding memoization. +And I found myself when I was writing that suggestion for the author that I was already looking for more than just to say, like, hey, this is more than we need. Because I've realized that often I take that stance of code is a liability. So if we don't need it, let's just get rid of it. But I've definitely run into other people where they're like, well, it's not hurting anything, so why can't I just leave it? And getting that kind of pushback on suggestions about removing code. +So it was a fun opportunity to think through okay, well, why is this memoization not just unnecessary, but how could it actually cause us problems? And what's the cost of keeping it in, not just the cost of removing it but also the cost of keeping it in? And that was fun to talk about. +CHRIS: I'm so glad you're bringing this particular conversation up because if we're being honest, I saw Joël tweeted about this. I saw it. I sent an email to myself linking to the tweet with the subject of the email being ahhhh, just A-H-H-H-H, which I believe was me being like, oh my God, we got to talk about this. I apparently didn't want to write all of those words, so I just wrote ahhhh. +But as a handful of asides, one, if you're not following Joël Quenneville on Twitter, @joelquen, that is a mistake, because Joël is one of the clearest, most concise, and effective thinkers about code that I've ever seen. The writing that Joël produces is absolutely fantastic. And having worked with Joël for forever, I still will look at his Twitter feed and be like, well, this is fantastic. You're saying amazing things that I have not heard you say. So, again, strongest recommendation I can make; please follow Joël on Twitter and also via the Giant Robots blog and all of those other places. +But in particular, I saw this one come through, and I was like, oh, man, we have to talk about this. So I actually have it up in my email app right now behind the scenes. [laughs] I was like, oh, I want to mention this to you, Steph. So I'm very excited that you're bringing it up in this moment. It is such an interesting thing. It's such an interesting case of like; I deeply believe both of these truths, and yet they do seem to be in contradiction. And so what do we do with that? +More generally, I feel like that's true of a lot of stuff in life, like, the ability to hold two competing ideas in your head and be able to know where one applies and where one doesn't. That is a critical thing to get to in life and to figure out how to do, and that's some of the hard work of thinking. But in particular, this one, the idea that code is a liability. You have a line of code...I'm going to read it precisely as Joël wrote it, "Code is a liability. If a line can't justify its existence, it should be deleted. Code is an asset. If a line isn't causing any immediate issues, why not keep it?" +And I think for me, if I were to try and interpret this, because I do believe both of those sides, I would apply one during code review. When code is coming into the application or when I'm writing code, do I need this? Do we need this? Is this necessary? Because it really should be necessary to come into the app. But then once something has made it in, especially the longer something's been in there, I think code sort of ages and matures. And so, the longer it's been part of the app and not causing an issue, the more I am liable to just leave it at rest. Just say, sure, or not at rest but as part of the runtime production code. +But these are two competing ideas, but I think they apply at different times in the conversation. And so I'm definitely on memoization. In particular, memoization is a form of caching. Caching I have run into a handful of caching bugs in my life, let me tell you. I'll probably run into a few more. So if we can avoid caching, let's do that. So that's a particular question around that thing. But again, that idea of like the point in time to have that conversation is during code review or initial authoring or when it's about to come into the app. +But if we've had some memoization in the app for forever and you're like, do we need this memoization? I don't know, but don't remove it because maybe it's very important at this point. Maybe it's one of the cornerstones holding up our application. So that's a bunch of thoughts about that. But also super glad that you brought this up because I was very excited about this particular tweet. +STEPH: Yeah, there's someone that said something very similar to what you just said around they agree with number one for all new code. And they agree with number two, where code is an asset for refactoring. And I thought, yep, that's a great way to look at it. And I hadn't really thought about that specific perspective. And so it was one of those moments. Because I do like when people will push back on something that I so firmly believe on, not that this person did. I was, frankly, having a conversation with myself based on previous conversations with other pull requests authors that I've had that it's not related to this particular pull request. +But in general, when people do push back on something that I do have such a firm belief in...and early eager optimization around memoization is something that I'm just like, I don't want to do it, especially for something that's so cheap and in such a fast execution and something that we're only calling twice. There's no benefit to it at that point. But then when someone says, "Well, but it's not hurting anything," then I appreciate that question because then it's more of not just pushback, but it's sort of well, tell me more. What is the pain that I'm introducing by keeping this in? +And then that can be a really nice conversation to have with someone around; like you just said, I've seen caching bugs, and this could be a caching bug, and they are painful to then triage. And so we've introduced this optimization, but it's actually just going to cause us debugging pain later. And we really didn't even get the reward from it in the first place. So I really like those conversations when I feel like there's a little bit of a challenge of where I'm like, oh, I hold this as a deep truth, and somebody doesn't, and I would like to have that conversation with them. +There are also some other fun conversations; one was around introducing a query object, which, as you know, we're both really big fans of. And then there was another great question because not everybody who works on this team is really familiar with Ruby and RSpec. They work in Scala, but then sometimes they hop over to the Ruby side. And so then they hop into the Ruby channels, and they're asking questions. And one of them was around the idea of introducing an RSpec Matcher. And they're like, "Am I doing this right? Is this how you would extract something to then improve your test? " +And so that was a really fun conversation around like, yes, you did it right. This is exactly how you write a Matcher. But let's talk about use cases because extracting something to an RSpec Matcher to me means it meets the most generalized sense of usefulness that you want the whole team to use this and that you're willing to put in the extra overhead to then introduce this essentially like new RSpec DSL for the rest of the team to use and then maintain that. So it is the most aggressive step that I take when I'm trying to introduce a helpful tool. +So then I shared my progression for when I'm extracting something for a test. And first, I will start with just a local method to that test because then it's scoped to just that test. And from there, then I will think about extracting to a shared helper. So maybe it's a module that can get included. But then its scope can still be confined to a couple of tests, but then we've also increased some of its observability. +So then other developers will notice it and be able to share with it. And then from there, if I'm like, oh, this is super generic, it is testing time, and it's something that everybody is going to benefit from, then I reach for something like an RSpec Matcher or introducing a custom RSpec Matcher. So lots of fun testing conversations this week. +CHRIS: That was a wonderful hierarchy. I like that a lot. I feel like that would make a good blog post. +STEPH: There are some things that I realize that I just think of inherently about that I realize that would be fun to share. I'm much better at podcasting than I am at blog posting. [laughs] +CHRIS: There's this friend I know, Joël Quenneville, very good at the blogging. He could probably help talk you through writing this up as a quick blog post. But you just described this heuristic hierarchy that you have. And you could probably provide quick examples of each, and I think encapsulate that knowledge. I, too, default to podcasting because it's easy for me to just say stuff here, and then it's there it is. +But what you just said also mirrors exactly what I would think of as sort of the hierarchy and the reasons you're like, I'm not sure I'd go all the way to an RSpec Matcher. That hesitation is meaningful and comes from experience that you've had. And again, that seems sort of a trade-off of like, well, why not? Is it hurting anyone? What's the cost here? You know that cost. You have that in your head. And so now if you can capture...I don't want to put work on your plate. But I think that would be a great blog post. I would be happy to read that blog post and share it with other folks. +STEPH: Cool, cool. Cool. So I totally hear you. So here's my hierarchy. Typically, I start with a podcast, and then I share it there. And then maybe it'll go to a tweet. And then once I'm like, okay, this is super generic, it can help everybody, then we've reached blog post status. +CHRIS: I love how tweet is higher in the hierarchy than a podcast for you. That somehow the throw away let me just have 140 characters or 280, or whatever we're at these days, that somehow that's next in your hierarchy. But I agree; I share that place in the world. +STEPH: Yeah, just writing is hard. Here I get to show up, and I say things. And then we have wonderful Mandy, who is then editing all of our words, so there's a safety net here. If it's just me and a keyboard, who knows what's going to happen? +CHRIS: Then you'll probably think about the switches that you're using on the keyboard. And do you need a new keyboard? Should it be silent? What do we do? +STEPH: I was thinking more how many exclamation marks do you use? That's always a question. +CHRIS: Not too many, not too few. It's a difficult question. +STEPH: [laughs] +Mid-roll Ad +Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: Pivoting just a bit, [laughs] what else is going on in your world? +CHRIS: What else is going on in my world? So we are building out a whole platform over here at Sagewell, and one of the things that we need to build is a mobile app or, frankly, two mobile apps, one for iOS and one for Android. And I'll be honest; I resisted this for a while. I am a big, big believer in the web as a platform like deeply in my heart of hearts. That's the place that I want to spend my time. That's the thing that I believe in. +And there are absolutely cases where truly native mobile apps shine, completely outshine what we can do on the web platform sometimes for reasons that are, I think, not great, limitations of the available mobile web platforms, et cetera, reasons that I'll slam my fist on the table or whatever it is. +But there are plenty of really great mobile experiences, offline, et cetera, that we just can't...offline is not even a great example. See, I can't even find a great example. There are definitely things, though, where truly native mobile apps are 100% superior. But again, I'm such a big fan of the web platform that that's what I wanted to do. I wanted to hold on to this dream of, like, what if we just make a really great web app and it's just great? +And then consistently, our backend is one singular thing. Our frontend is kind of one singular thing. And yeah, we got to deal with responsive design. But that's to me a much more tractable problem than fracturing our entire application architecture across a bunch of different platforms and having all of the logic of our domain splintered and especially depending on how you implement it. That's sort of a big question. +I've talked a ton about Inertia.js on this podcast, and that's because I believe it's a really great example as to how to pull some of the logic back to the server-side, which, in my experience, that's where I want the logic to be implemented, our deep domain logic. I just want that to be on my server in a Rails controller, or a Rails model, or a command object, or any of those sorts of things, query objects, all of these wonderful things but server-side that's centralized in one space. +Nonetheless, though, we had to build a mobile app. These are the truths of the world. Sometimes it just comes down to the expectation of your user base. And there are certain things that by building a mobile app we will get so, for instance, in our case, having biometric login, so fingerprint, or facial ID, or any of those sorts of things. Those are actually material security differences. They are actually, as far as I can tell, available on the web but not consistently on every browser, et cetera. So that's something that we can get by having our app as a native app. +Push notifications is another one that certain platforms, certain web platforms have dragged their feet on, Apple Safari. iOS Safari, specifically, I'm looking at you, but that's an example of something that by going the truly native route, we'll get that. Similarly, access to some of the lower-level things, cameras, et cetera, that is something that we'll get a better experience of. And again, you can hear in my voice I don't want to really seed it to the native platform, but it is true right now, at a minimum. +So we had a decision to make as to how we would implement these applications, and we went with an interesting route. So for anyone that's familiar with Turbolinks native, or I believe Turbo iOS is pretty similar. But I'm more familiar with Turbolinks native as there was a talk I Can't Believe It's Not Native I think is the name of the talk that was given a while back talking about the Turbolinks native architecture. +So basically, what's happening under the hood is let's still render these things server-side. Let's send down some HTML. In our case, it's a weird sort of hybrid of HTML and not HTML. But broadly, let's say that the server is rendering things. And our native application is going to then be a native shell that wraps around WebViews. But it does so in not just a single WebView sort of way. It's instead trying to find that optimum hybrid spot where let's do native things where they make sense. +So, for instance, we have introduced a tab bar at the bottom of our application that is a truly native UI. We similarly have push notifications, biometric login, et cetera. Those are features of the native platform that we're using. But then, for most of the screens, most of the screens that are just some text, maybe a button, maybe a form, et cetera, we are using the server-rendered code that we have. And so server-rendered, in our case, because we're Inertia, it's sort of a misnomer because technically it is being rendered on the client-side in the WebView. But, I don't know; we're now getting too nuanced and in the weeds for it. +But what we've opted for is to reuse the same views, controllers, et cetera. All of that is still being reused. Our iOS and our Android codebase at this point are wrappers around those WebView stacks. So it's not just a singular WebView; it's a stack of WebViews. So if you're doing swipe to navigate thing on iOS, that'll work...or Android. I think Android has an actual back button, though, within the applications. +But most importantly, we've introduced a tiny little bridge layer. So from our WebViews, we can communicate to the wrapping native context. And similarly, from our native context, we can send messages into our WebView. So we can have a button in our native UI. And when a user clicks that button, it will send a message to the WebView that it's wrapping around and vice versa. We can do push notifications. We can do all that sort of stuff. For any given view, like, say, the login view, we can say, "Hey, don't render the normal server-side thing. Instead, render this truly native, local Swift or Kotlin view that we want to use there." +So it's an interesting choice. I think it's something that I've certainly seen applications that are just like, let's take some HTML and wrap it in a WebView, and it'll be fine. And they don't make great apps. But I think this time it might just be a good idea. I actually do think that the approach that we're taking, at a minimum, is buying us a ton of simplicity in terms of having to duplicate what are somewhat nascent domain concepts across multiple platforms. +We're not entirely certain as to what our platform and what our business is going to be. So we'd love to non-enshrine that across three different platforms that are hard to update. Like the web, I can kind of change that every day. But iOS and Android because I have to go through review cycles, because I have to get them out to devices, because there are slow update cycles that individuals will use, I'm going to be stuck supporting whatever version of these applications are out there. +And so if more of that is the dynamic content that's driven by the server, frankly, I just feel way better about that, at least for now, at least for the point in time that we're at. But I kind of believe that this may be a really useful architecture for us long term. +That was a bunch of me rambling about the architecture. Let me pause there, thoughts, questions, comments, concerns? +STEPH: First, I really appreciate the thoughtful approach and explanation. Also, you highlighted the reasons that y'all are pursuing having a native app, and all of that makes a lot of sense. Because there is that user expectation of you told me about a service that then there must be an app that I can download because that's what I'm accustomed to using versus having to go to a browser and then having to then remember the URL of the site that I'm supposed to go to. So there's that convenience factor. +There's also the idea that some people go to the App Store and search for their solutions instead of going to a browser and searching for a service. So having that presence in the App Store can seem like a really huge win because then even if it maybe slowly pushes them back to use the website or as long as they get a decent experience, they've now at least been exposed to the idea of the service and that it's out there. +But then, as you pointed out, building a mobile native application is a lot of work. And then it becomes a question of like, well, are you going to hire people to work specifically on these platforms? And then, is it really worth that investment at this point? Or is it worth the approach that you're taking where you're going the more hybrid approach? I am curious; maybe this is something that you'll know. So as you are investing in this hybrid approach and you are starting to collect more users that are then using the app versus going to the browser, then what does that pivot look like, or how does that further investment look like? +If you realize that the UI isn't quite delivering the expectations that you want that if you'd actually built a native iOS or Android application, then what does that investment look like? Can you still reuse some of the work that you've done? Is it totally scrapping that work? I think that would be my biggest question around taking this first approach. Is it an all-in bet that we are now stuck to this? Or is there some salvageable pieces to then move this forward into native apps should we need to do that? +CHRIS: That's a heck of a question. Have you made a terrible decision or just like an iffy decision? I think that the framework that we're choosing or, frankly, building right now will actually be amenable to a potential transition entirely into the native world in the future. So again, one of the options that we have here is the ability to say, no; this facet of the application is entirely native. We're going to opt-in. +And so it actually happens at the navigation layer. So we can say, if a person transitions to the /user/signin route, instead of just rendering that WebView right in place, push a native Swift or Kotlin. Depending on the context that we're in or the platform that we're in, push the native view onto the stack and use that. And so we're able to, on a screen-by-screen basis, make a decision of no, we'd like to opt into native behavior here. +And so, if we did eventually see that the vast majority of the users of the platform are using it via the native app, we should probably continue to invest in that and push in that direction. I think we could do it in sort of a gradual style, and that is critically important to me. I don't want to make a big bet and then be like, oh no, we got to rewrite from the ground up. And there's no way to do that incrementally. It's going to be a whiz-bang Friday launch that everyone's going to hate. That's the thing I want to avoid most in the world. +And so I think what we found now is this seems great for right now because it allows us to avoid this complexity explosion of three different platforms and trying to keep them in sync and trying to keep them up to date. But it does, I think, give us an opportunity as we move forward to slowly sort of transition things over. We are, to state it, this isn't just like wrapping a WebView around things. We are building essentially a mini framework on both iOS and Android, or roughly Swift and Kotlin is what the actual languages are, to work with Inertia because inertia is the core technology that we're using. +Inertia, thankfully, has a nice little event system in there, so we can say, Inertia on navigate. And when a navigate event happens, we can hook into that and then connect it to whatever Swift or Kotlin runtime that we're building here. And there are a couple of different events that we can opt into. And so that's giving us the hooks that we need in the current architecture. +But longer-term, if we needed to, we could just, I think, slowly transition everything over to be truly native mobile, and then that would probably be backed by more traditional API endpoints and that sort of thing. I want to avoid that. That's my dream is to stay in this happy place where we're always going to need some web presence. And I would hate for those to be fractured distinct things. +I've worked with enough mobile apps that are wonderful native experiences, and yet I'm like, could you just give me the desktop view? Just scaled to...like, I'll even pinch and zoom because you're hiding data from me, and that makes me very, very sad. Please give me the buttons, and the text, and the content that you would give me on the web. And the fact that you're not is just breaking my heart right now. And, frankly, for our user base, consistency of experience is something that I think is really important. So that's another facet of the conversation that is really interesting to me of like; I don't want it to be different on each platform. +Certainly, a three-column layout doesn't work on an iOS app that is zoomed in 150%. But we can turn that into each column is just floated down and then otherwise have all the content in there. And I believe in that as sort of a fundamental truth of let's reshape the content but not fundamentally rethink it. I say that as something that I believed deeply. But as I said it out loud, I was like, yeah, but also, I don't know, make it work on the platform it's on. So I can see both sides. But I have had enough experiences personally where I'm sad about the app that I'm using. +STEPH: Yeah, I could also see an argument for both ways where you don't want it to be fundamentally different, but then also, you want it to fit the platform. And then there may be some advantages to the fact that there is a different platform, and you want to utilize that. I also agree with the not hiding of the data. I have felt that pain where I have an app, but I really want to go to my desktop, and I really want to use it there. But then on mobile, it's then hiding, and I realize it's hiding. And that inconsistency really frustrates the heck out of me. So I can understand that as well. +Overall, I really like this. You're taking a bet in a direction of we should have a mobile presence, and we should start attracting people through this new marketplace. But we want to reuse a lot of the logic that we already have before we go so far as then we're going to have to start building for each different platform. Because while I don't have a lot of experience in that area, the times that I have been part of teams that are building native apps, it's a big investment. +I mean, they hire people very focused on that; designers have to design for browser, for mobile, and then for native, and then everything has to stay in sync across. You have to think about how a feature is going to work across all three of those different views. And so it is certainly not something to go into lightly, which I think is exactly what you're describing is that you're looking for that in-between to how can we start working our way in this direction but yet also do it in a way that we're reusing a lot of the work that we have versus having to invest full sail into then building out these different platforms? +So I'm going to go with this is not a terrible idea. [chuckles] I'm excited to see how it feels once I can download this and check it out. I'm excited to then see how that feels from a UX perspective. But overall, everything you're saying really jives with me. It makes a lot of sense. I am curious, what about React Native? Is that something that you considered using? +CHRIS: Oh yeah, great question and definitely something that we considered. We're not using React on the backend, so that was actually a consideration when I was thinking about Svelte initially is I assumed we'd be building a React Native app eventually for the native platforms. But I talked myself into Svelte for the web, and that is not the reason that we're not using React Native for the native apps. But it is an interesting sort of constellation of technologies that we have now. +We're not using React Native because I'm clinging to this idea of what if we could have a singular experience? So React Native fundamentally you're building a native app that this is this bundle that you download that's got all of the UI and that front-end logic in that bundle that you download. And then when it wakes up, it makes some calls back to some APIs to get some data or to decide if I can do an action or to actually do an action, all those sorts of things. But you're building out a Rest or GraphQL or one of those APIs. +And with my explorations of Inertia, I found that what if I didn't need to do that? What if I could do a more traditional Rails CRUD-like experience but CRUD in a good way (I mean it in the very positive sense of the familiar architecture) and still give users a delightful experience but not have to build a distinct API where all of the or majority of the logic was on our client-side? So if I did that, then my web client would need to be that much smarter. And each of the iOS and Android clients would need to be that much smarter because that's fundamentally how these technologies work. +UI components they can give a higher fidelity experience, more native-like experience, but they tend to own a lot more of the smarts. And one of my core beliefs is however long I can get away with this, I want to keep as much intelligence on the server as possible and have my view layer be as minimal and as simple as possible. +So I think React Native is a really fantastic technology for that sort of work. But my goal was to avoid that sort of work entirely. What if we had a singular way that we had the logic exist on the server-side, and then we rendered pretty minimal view layers? Or, from a user experience, the view should do all this stuff and show all of the things that they want. But I want that view layer to be as naive as possible. And by naive, I mean in the positive sense of like, I want to be able to change this very rapidly. I want to be able to evolve it and iterate it. +And so this is more of a buy into I think the thing that Inertia gave me is valuable enough and if I can keep using that and reuse it, especially on these mobile platforms...now if we add a new fundamental part of our Sagewell platform, if we have that, it just exists on each of the iOS, the Android, and the web, and that's fantastic. And we're going to keep a really close eye on what experience that gives to the user. And is it still great? But presuming it is, the complexity savings there are so huge. +Our team is a team of web developers that is able to think about things holistically and singularly. We implement it once within our stack, and it just works. And if we can do that, that is worth a ton. We may not be able to do that forever. But for now, especially while we're figuring things out, while we're super early on as a company, I think that savings and complexity is worth a lot. So it'll be interesting to see how it plays out, and will certainly report back. But I'm a big believer in this little adventure we're on. +STEPH: Yeah, you said it perfectly there at the end; you're a team of web developers. And so as long as you can stick to that, then that's what's best for y'all and the team and the product. So that's wonderful. I have a short segue because I had a little bit of inspiration when we were talking about terrible ideas. I want to circle back to your other terrible idea because I have a terrible idea for your terrible idea about strings and symbols. +Okay, so my terrible idea is you're talking about using HashWithIndifferentAccess for everything. What if you had a class or method that then will first try to access via string and if that fails, access via symbol, and then if that fails, then it fails loudly? So you now have this let's try this, and then let's try the next thing. I have strong feelings about this as I'm saying it. +CHRIS: [laughs] +STEPH: But we're in the terrible idea segment, so I'm going to embrace it. This is my terrible idea. +CHRIS: HashWithIndifferentAccess with runtime exceptions. I think HashWithIndifferentAccess under the hood probably does what you're describing of, like checks one and then checks the other or checks has_key is probably the underlying implementation. I haven't actually looked at it. But some version of that makes sense. Falling back to the key error gets interesting. +I did see a different thing recently of a deep fetch, which is something that I want, to stop trying to make fetch happen, except I'm going to try and make fetch happen. We thought about this a bunch where we have these objects that we need to traverse into. So we use dig to get into the third layer of the object, but dig doesn't care. And it's just going to happily nil out whatever. So I'm like, no, dig but then right at the end, fetch, deep fetch. I saw somebody post this recently. So deep fetch is something I want to make happen. HashWithIndifferentAccess, which raises at the end also intriguing. +STEPH: So yes, but this will be a little different because this one, you don't have to do the transformation process upfront with HashWithIndifferentAccess where you have to pass the data first, and then it transforms it so then it can do these two different lookups or the fallback. This one, you're skipping the transformation process, and you're using your own custom method that then does that first check for a string or first check for a symbol and then default back to the other one and then fail loudly, yeah, if both of those fail. +CHRIS: Interesting, and I have to see what it looks like in practice. But I mean, broadly, I'm into something in this space. Let us find some simplicity. That is what I want. +STEPH: Let's find some terribleness and see which one feels not so terrible. [laughs] +CHRIS: Some terrible simplicity. Well, I like that idea. We'll see where we get to with it. But I think on that note, and we've said a bunch of stuff today, should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeee!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris is helping with efforts to introduce security, practices, and policies at Sagewell. Right now, they are refining the usage of 1Password to standardize passwords and secure information. He also shares (what he believes) is a terrible idea around fixing inconsistencies around symbols and strings.

+ +

Steph shares an update around factories.

+ +

Also, at Sagewell, Chris is helping to build mobile apps, one for iOS and one for Android, and is considering pursuing having them be all native. Good idea? Terrible idea? Chris and Steph riff on that a bit.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Weird stuff happens when we sing, Steph.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: Hello, Steph. What is new in my world? We are continuing with some of the efforts that we're doing to introduce security, and practices, and policies, and all those fun sorts of things at the organization. One of the things that this is pushing on is we are further refining our usage of 1Password at the company as a way to standardize passwords and secure information and how we store that, how we move it around, as well as integrating SSL, and all those other fun fancier things.

+ +

But I'm personally historically a LastPass user, and now I'm getting to experience 1Password. So now I'm a child of two worlds, and it's terrible, and I hate it. I hate every moment of this existence. So what I need to do is move over to 1Password, but now I'm in that space where I'm like, I can see the flaws of both systems. This is terrible. I don't like it. 1Password does seem to be great; I will say that. There's one really interesting thing about 1Password. I'm interested...you're a 1Password user, right?

+ +

STEPH: I'm not; I use LastPass. I'm also a child of two worlds because we use 1Password for thoughtbot stuff, but then I use LastPass for my stuff.

+ +

CHRIS: Gotcha. Okay, so you survive in the middle space. I'm slowly trying to move everything over because I think 1Password has a little bit more of what I'm going for. And I would like, frankly, to be in one cohesive, consistent space, although having two different accounts seems interesting. I definitely can handle it. But knowing which I'm in and how to save a password to one versus the other, it's a whole thing.

+ +

The one thing that I find really interesting though is 1Password has a feature where it will do two-factor, two-factor authentication. It will do that for you. Specifically, it's doing, as far as I can tell, the TOTP. I don't know what that acronym stands for, but it's the fancy type of two-factor, so not SMS, not text message-based, and not others like WebAuthn is a thing that I've heard of, which I don't know if that is distinct from YubiKey or hardware keys. So there's a bunch I'm trying to learn about this space a little bit more.

+ +

I'm very interested in the hardware keys because those seem cool. WebAuthn seems like a new standard. That sounds cool. Don't know anything about it, though. So mostly, I know about SMS, and I do not like that one. I do not want to use text messages because, as far as I understand it, they're not super secure. So that's not the space I want to be in. But the TOTP, the Google Authenticator, or Authy, or that space of password or two-factor code generation tools those seem good.

+ +

And 1Password has a feature where they're like, hey, yeah, sure, we'll have your password and your two-factor. And so they grab the QR code, which is typically the QR code is a way, as far as I understand it, to share the seed. And then, that seed is used by an algorithm to generate the current code value for a given point in time. So it takes like, given that seed and the current timestamp, we will generate you the relevant code, which can then be verified on the far side. But that seed only exists for one moment in time, et cetera, et cetera.

+ +

But I've always thought of it as this separate thing. The idea of having that all in one system is interesting and kind of scary to me. But as I think about it, I'm like, if 1Password or LastPass, in either case, gets compromised, we're all done. Like, this is over. We should throw in our cards, give away the internet. This whole experiment has failed is my sense. But it was very interesting because I had not seen this. I've always had these as separate systems.

+ +

So for me, I have had LastPass, and I have Authy on my phone for the two-factor. But it's frankly very clunky, and I don't like it. And the 1Password thing is fantastic where I say like, yeah, 1Password, fill in my password and username, and then also fill in my two-factor because you have it. This is great. But, and this is where I hesitate, and I don't know, I will say this: I trust that 1Password has thought about this deeply way more than I can and have come to a place of deep confidence that this is a fine and okay thing to do. But I'm still intrigued. What's going on here?

+ +

STEPH: That was a lot. I have so many thoughts. [laughs]

+ +

CHRIS: Sorry, that was a lot of words, a lot of ideas, a lot of space there. It's just where I'm at.

+ +

STEPH: People couldn't hear me, but I was laughing when you were talking about LastPass or if these accounts get hacked in. And I'm imagining someone who uses the combination of their cat's name and their birthday as their password and then like, aha, I win. [laughs] It's like, no, we just all lose. [laughs] But that amused me.

+ +

Going back, you talked about having it all in one place. And that actually doesn't surprise me that we're different in this area. Because you also like all of your email...you like one source of everything, which makes so much sense, but I'm different. And with these accounts, I like that I have the distinction between all of thoughtbot is in 1Password while all of mine is in LastPass because it's just a very clear delineation between those two accounts. And I'm sure both of these platforms have figured out a really good way to then separate those two.

+ +

But I just remembered there was someone at thoughtbot that accidentally...because they have everything in 1Password, they accidentally shared their personal vault with a client. And so they were just typing in Slack. They're like, "Oh, shit, oh shit, like, how do I undo this?" And we're all just watching like, "We don't know. But please let us know how it turns out." [laughs] It turned out fine. I think they actually realized they hadn't fully shared it but based on the UI they thought that they had. So it all turned out okay. So that just lives with me. I'm a little scared of that now now that I know that story. So watch out, friends.

+ +

CHRIS: Oh, wow. Well, now, yeah, I'm also now scared of that. I wasn't, but now I am.

+ +

STEPH: And I forgot the other thoughts now. Those were my two main thoughts based on the journey that you've shared.

+ +

CHRIS: Particular to the thing you were sharing there, yes, now I will have nightmares about it. But also, it feels manageable because they're both entirely different accounts, and then also within that, there are different vaults. So as I'm building up the password infrastructure at Sagewell, there's going to be different...like, the dev team will probably have one vault and then a shared vault for the dev team. And then other teams within the organization will have that. And so it feels like there are at least structures within the tool to manage that.

+ +

But mostly, my consideration is around the two-factor thing. And like, is this reasonable to do? And again, I'm sure 1Password has thought way harder than I have about it. And I trust that they're like, yeah, this seems fine that they're not just like, I don't know, it doesn't seem bad. They're like, no, no, definitively for information-theoretic reasons, this is fine. But it was surprising.

+ +

STEPH: That was it. The other comment that you made about two-factor auth that resonated with me because there was a point not that long ago where we have one of those, either New Relic or I forget which account it was, but it was with the systems. We really only needed one person to have access, but every now and then, someone else may need to access that account. And so we wanted to be able to store it in 1Password or LastPass somewhere like that.

+ +

But then the two-factor auth was a problem because then you had to coordinate with that other person to say, "Hey, I just need to check something. Would you let me in?" And because we could then leverage that feature, then we could just store all of it. And then that person could just go to 1Password or LastPass and then have access to all of it, and that was really nice. That was a very nice solution to I want to say it was a small problem but yet also very important for team happiness. So that was really nice.

+ +

CHRIS: The amount of times that I've been like, "I just tried to sign in to the shared account, and it says that it sent a two-factor request to somebody's phone, but it didn't tell me whose phone. And I'm not sure if we know who that person is or if that person's still around," that version of the story feels true. And so, the idea of being able to centralize two-factor seems great. It almost feels too good to be true, is perhaps where I'm at. I am putting on my tinfoil hat, and I'm saying, yeah, but oh man, security, though.

+ +

And again, I will 100% defer to 1Password on this. They've thought about it. But it's mostly I want to get to the place where I understand the thought process that they went through to decide that this is perfectly fine because they definitely did that work. I'm certain of that. I just want to read a white paper or something, and I haven't found it yet. [laughs] I'm like, let me get to that deep place of trust because that's what I want to be at with security tooling and those sorts of things.

+ +

STEPH: Yeah, I haven't looked for something like that, but that sounds...I'm kind of surprised that doesn't exist.

+ +

CHRIS: Oh, it quite possibly exists. I haven't done much of a search, frankly, at all. Mostly, I'm in the space of like, huh, that's weird and then moving on with my day. Because there's not a lot of free time to go search for the white papers on the internet. But yeah, so moving from 1Password or LastPass or 1Password, or maybe I'll just end up with both for a while. I really hope I don't end up in that space, although you're describing it as a positive, so maybe I will.

+ +

STEPH: I have found it helpful for me. When you find that white paper, because you are more likely the type of person to read that white paper than I am the type of person to read it, then I would love a summary. That would be much appreciated.

+ +

CHRIS: I'm so intrigued by the persona that you're describing of me of; like, you're the kind of person who would read a white paper. I'm like, well, I don't know if that feels true or if it's definitely true or definitely not true. But if I do happen to find it, and especially if I happen to read it, [laughs], I will share it with you and perhaps with the listeners as well.

+ +

Let's see, one other small thing. I have a bad idea. I don't want to share the bad idea with you. I want to more share it with the audience, and then I want the audience to tell me exactly how bad of an idea it is.

+ +

STEPH: [laughs]

+ +

CHRIS: Because I'm sure it's a bad idea. I'm just not sure how bad.

+ +

STEPH: I love that there's not even a scale of goodness here. It's just nope, this is terrible, but I don't know how terrible it is. [laughs]

+ +

CHRIS: What's fun is in the later parts of this episode, we're going to go into a segment of good idea, bad idea, sorry, good idea, terrible idea because I like that framing. No, this one is firmly bad idea, but how bad is the question. So we're working on the app, and we keep running into inconsistencies around symbols and strings.

+ +

As any Rubyist who has worked in the language for any amount of time, especially in a Rails app, you have experienced this unpleasantness. There are strings; there are symbols. They're often used somewhat interchangeably, and yet they're different. You’ll hit bugs. You'll hit edge cases. You'll hit nils that you didn't expect to be there because you tried to fetch a symbol. It, in fact, was a string, et cetera.

+ +

So, what if we just applied HashWithIndifferentAccess everywhere, just deep in the internals of the app or in the Ruby runtime? What if we were to just turn this on? My sense is this would be terrible for performance reasons. My understanding is that's why symbols exist is because they are a more performant mechanism. Strings are complicated within the object model of Ruby because they're mutable. These are things that I understand very loosely, as you can tell by the tone of voice that I'm using. But symbols and strings they're separate. They're separate for reasons, performance I believe to be the main reason.

+ +

But what if we were to just say, well, what if it could be like easy, though? That's what I want. Like, this is the promise of Ruby is that I want to express my code in a way that feels like the words I would use to describe to another human. That's the way I always think of Ruby is it's as close to the words I would use to describe the sort of business logic as possible. And yet these symbols versus strings thing it's just annoying, frankly. And again, I think very good reasons for it, I'm sure.

+ +

But what if we were to just do the silly thing and turn on HashWithIndifferentAccess for everything? I don't even know that that's fundamentally possible. I don't know that there's the relevant hook or the way to do that. But I would love that because we're using it somewhat regularly throughout our app right now, where we're getting data from one API. And in our test suite, it's one way, and in our code, it's the other way. And granted, that speaks to us being inconsistent in our usage. But overall, I would just love for this to not be a thing.

+ +

And so, how bad of an idea would it be? How much of a performance hit? That's my guess as to what it would be. Maybe there's actual fundamental correctness that would go wrong here. But my sense is by collapsing the space together; we would actually get more correct. I don't know. Anyway, how bad do you think of an idea this is?

+ +

STEPH: I was thinking through some of the bugs that you're running into. And I think you provided some nice insight around that around it's the fact that you're fetching data from API. So it's typically you're parsing. That's how you're getting the string and symbol differences is because when you're parsing JSON and then you have a mixed case of maybe you have a symbol, maybe you have a string, or maybe you're parsing it differently. Are there other places in the application where that's a concern?

+ +

CHRIS: I want to say one other place that we're running into it specifically is we're using a lot of enums, particularly ActiveRecord::PGEnum backed enums. So these are Postgres enums at the database level. And then, within our Rails models, we define them as enums. And the enum is typically defined within the model as a mapping of symbol to string. It could be symbol to symbol. I'm not even sure. I think this might be in terms of our implementation.

+ +

But you say like, it's an enum. The key is foobar with an underscore, and it's a symbol, and then the value is foobar, but it's a string. And maybe both the key and the value could be symbols; maybe that's a thing, maybe this is our fault. But certain times, when you're interacting with the value, it's a symbol. Certain times I find it to be a string. I feel like that's true. I don't think I'm making that up. [laughs] It's possible I'm making it up.

+ +

But that's another place where I feel that inconsistency or other values within the system that like as they go through certain type coercion layers, they'll start as a symbol, and then they get saved to the database, and then they get reflected back, and they come back as a string. And it's like, well, that's unfortunate. It was a symbol a minute ago, and now it's a string. And so our tests suddenly break in this way, or our code is inconsistent. And it's enough of a nuisance that I had the bad idea the other day. And so, I wanted to bring the bad idea to this space.

+ +

STEPH: I think you're right. I think the main reasoning for not having everything just be strings is for looking for that performance benefit. And so then using that HashWithIndifferentAccess then you'd have to loop over everything and then convert it. So I imagine, like you said, there would be a performance hit there. I don't know how bad of an idea it would be.

+ +

But when you said this, it brought up a memory because I remember someone proposing or the Ruby community talking about the fact, like, what if we didn't have strings? What if everything was just a symbol? Or can we just have one over the other? And there is a ruby-lang issue; it is 7792. And we shall also put it in the show notes and send it to you. [chuckles] And this person is proposing make symbols and strings the same thing.

+ +

And then some people call out specifically the idea of using HashWithIndifferentAccess and saying, yes, that works wonderfully, but then you are going to have a performance hit for it. So it sounds exactly like everything you're saying. I don't know the outcome. I mean, clearly, the outcome is we're not there. But it seems like a really good place to see the reasoning or different approaches that maybe people have tried in this space.

+ +

CHRIS: Ooh, I love that. I definitely want to read that and see what sort of deeper thinking folks have done on this. Because again, this feels like another one where definitely folks have thought about this, folks who know more about it and have chosen the current path that we're on for reasons. But I would be really intrigued if I could be like, yeah, I would just like it to be easy to start, and then have the performance optimization be something that I could opt into. Again, that's probably not tractable within the language.

+ +

Like, oh, we have a hot code path here that we want to actually have immutable symbols only. And that's the sort of thing if we've done this HashWithIndifferentAccess everywhere, you can't back out of it. And so, therefore, you're stuck in a performance low point. That feels like a bad case. And so maybe that's the reason is like, you will shoot yourself in the foot with this definitely.

+ +

But yeah, I'm intrigued. So I will definitely read what you're sharing here. And we'll include it in the show notes, of course. I'm probably not going to do this, just saying that out loud because it seems like a bad idea. I just want to know how bad of an idea.

+ +

STEPH: I do love it, for when I'm building a class that's working specifically closely with an API, I do reach for HashWithIndifferentAccess frequently. Because like you said, I just don't want to worry about it. I want to set it up top. It's one of the rare times that I actually will use something in an initializer where I'm like, hey, pass in the data. I'm just going to run it through this method. And then all the data from here on forward you can access it in either way. So the class doesn't have to care; a tester doesn't have to care. So I do feel your pain, or I at least will always reach for it whenever I'm building a class specifically around interactions with JSON.

+ +

CHRIS: So for a segment that I framed as how terrible of an idea this is, you're like, hmm, I don't know how terrible. That seems to be your take, which is interesting.

+ +

STEPH: Good point. Let me assess for a moment. I'm going to go just from skimming this issue, although I think partially this issue is talking about the fact that if you merge symbols and strings, it's like, hey, friend, you're going to break a ton of stuff and break a bunch of libraries, and these two things do serve a purpose. So this may not be exactly what you're looking for, but it has some interesting conversation on there.

+ +

But embedding it deep down in the app so that just happens naturally sounds like it's just a performance concern. So yeah, it comes down to what is the question? How big is the performance? So I feel like I can't say it's a terrible idea until I actually know what the performance hit is.

+ +

CHRIS: So a plausible question. That's where we're going to put this in the category of. [laughter]

+ +

STEPH: Plausibly terrible, but still worth researching.

+ +

CHRIS: Not obviously not terrible. But anyway, these are some of the ideas at the top of my head right now. That's a rough summary of my week.

+ +

Mid-roll Ad

+ +

Hey, friends, let's take a quick break to hear from today's sponsor, New Relic.

+ +

All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem.

+ +

So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy.

+ +

That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software.

+ +

So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed.

+ +

STEPH: I have an update that I can share around factories because the last time we were chatting, I was sharing that strategy that we're pursuing where we're trying to minimize factories and then speed up the CI time by reducing the work that those factories are doing. So Joël Quenneville has done some phenomenal work and this past week, specifically improving factories. And he found one particular factory that he was digging into.

+ +

So some stats before the change. The factory was taking around two seconds, which I know on paper doesn't sound so bad, but it gets more interesting. So total database time is around 1,000 milliseconds. And 833 total database queries were being made, which includes reads, creates, and updates. So then after, Joël was diving into this looking mainly to reduce the number of database queries because that's such a big number.

+ +

So after the change, which took a lot of research on Joël's part, the factory is now taking around one second, so half of that time. The total database time is around 666 milliseconds. And the total database queries went from 833 down to 647, so a nice improvement there. But the real wonderful outcome of the story is not just those stats, but okay, so how did we impact CI? So we spent time working on this factory. And we have reduced, and we can see some of that in the stats. But how does that apply to the bigger picture?

+ +

And so Joël took the time of the last 20 successful builds, and based on those builds, we average 27 minutes and 37 seconds for each build. With the factory change that he made, that same test suite was now averaging 21 minutes and 33 seconds. So shaved off six minutes from the build time, which is about a 22% decrease in the build time which is just fabulous. So that was a really nice win from all the work that had been invested in improving that one factory.

+ +

CHRIS: That's a heck of a haircut there so glad to see that the efforts are paying off.

+ +

STEPH: Yeah, it was a really nice win to see that we had researched which factories we should pursue, and then we were methodical about that. And then Joël worked hard to improve this factory and saw such a large payoff. It's one of those areas where the team has already invested a lot of effort and hours into improving the test suite. And it's challenging when you have so many areas that you'd like to improve and 100-plus engineers also contributing to that same codebase. So how do you improve and keep up with it all at once?

+ +

They had spent about a year, so I think they were recognizing that yes, there are still a lot of areas to improve but also felt like small efforts wouldn't move the needle. So it was a nice data point to remind ourselves that we can still reduce the CI build time in a significant way. We just need to be very strategic about where we invest our time in those improvements.

+ +

There is also an interesting conversation that Joël and I were having because we have a daily sync with each other each day. We've now been embedded with a team with a client, which is wonderful, but before then, we were also chatting with each other. And we like to chat about code, so we've had lots of fun conversations around code. And one, in particular, this week, came up about how people view code differently. And there's even a tweet that Joël shared that I can link to in the show notes.

+ +

And there's one view that code is a liability, and if a line can't justify its existence, then it should be deleted. And then there's another view that code is an asset. If a line isn't causing any immediate issues, then why not keep it? And part of the reason that came up was while I was going through and reading pull requests, there was a particular change where someone was memoizing an expensive call, which was great, something that we wanted to do.

+ +

But then they were also memoizing a very fast operation in two other places where it was just like parsing some params something that, you know, superfast and only getting called in maybe two places. And it was one of those that just caught my attention to be like, hey, I love that you memoized this other call, but this one, I don't think we need the additional overhead or complexity of adding memoization.

+ +

And I found myself when I was writing that suggestion for the author that I was already looking for more than just to say, like, hey, this is more than we need. Because I've realized that often I take that stance of code is a liability. So if we don't need it, let's just get rid of it. But I've definitely run into other people where they're like, well, it's not hurting anything, so why can't I just leave it? And getting that kind of pushback on suggestions about removing code.

+ +

So it was a fun opportunity to think through okay, well, why is this memoization not just unnecessary, but how could it actually cause us problems? And what's the cost of keeping it in, not just the cost of removing it but also the cost of keeping it in? And that was fun to talk about.

+ +

CHRIS: I'm so glad you're bringing this particular conversation up because if we're being honest, I saw Joël tweeted about this. I saw it. I sent an email to myself linking to the tweet with the subject of the email being ahhhh, just A-H-H-H-H, which I believe was me being like, oh my God, we got to talk about this. I apparently didn't want to write all of those words, so I just wrote ahhhh.

+ +

But as a handful of asides, one, if you're not following Joël Quenneville on Twitter, @joelquen, that is a mistake, because Joël is one of the clearest, most concise, and effective thinkers about code that I've ever seen. The writing that Joël produces is absolutely fantastic. And having worked with Joël for forever, I still will look at his Twitter feed and be like, well, this is fantastic. You're saying amazing things that I have not heard you say. So, again, strongest recommendation I can make; please follow Joël on Twitter and also via the Giant Robots blog and all of those other places.

+ +

But in particular, I saw this one come through, and I was like, oh, man, we have to talk about this. So I actually have it up in my email app right now behind the scenes. [laughs] I was like, oh, I want to mention this to you, Steph. So I'm very excited that you're bringing it up in this moment. It is such an interesting thing. It's such an interesting case of like; I deeply believe both of these truths, and yet they do seem to be in contradiction. And so what do we do with that?

+ +

More generally, I feel like that's true of a lot of stuff in life, like, the ability to hold two competing ideas in your head and be able to know where one applies and where one doesn't. That is a critical thing to get to in life and to figure out how to do, and that's some of the hard work of thinking. But in particular, this one, the idea that code is a liability. You have a line of code...I'm going to read it precisely as Joël wrote it, "Code is a liability. If a line can't justify its existence, it should be deleted. Code is an asset. If a line isn't causing any immediate issues, why not keep it?"

+ +

And I think for me, if I were to try and interpret this, because I do believe both of those sides, I would apply one during code review. When code is coming into the application or when I'm writing code, do I need this? Do we need this? Is this necessary? Because it really should be necessary to come into the app. But then once something has made it in, especially the longer something's been in there, I think code sort of ages and matures. And so, the longer it's been part of the app and not causing an issue, the more I am liable to just leave it at rest. Just say, sure, or not at rest but as part of the runtime production code.

+ +

But these are two competing ideas, but I think they apply at different times in the conversation. And so I'm definitely on memoization. In particular, memoization is a form of caching. Caching I have run into a handful of caching bugs in my life, let me tell you. I'll probably run into a few more. So if we can avoid caching, let's do that. So that's a particular question around that thing. But again, that idea of like the point in time to have that conversation is during code review or initial authoring or when it's about to come into the app.

+ +

But if we've had some memoization in the app for forever and you're like, do we need this memoization? I don't know, but don't remove it because maybe it's very important at this point. Maybe it's one of the cornerstones holding up our application. So that's a bunch of thoughts about that. But also super glad that you brought this up because I was very excited about this particular tweet.

+ +

STEPH: Yeah, there's someone that said something very similar to what you just said around they agree with number one for all new code. And they agree with number two, where code is an asset for refactoring. And I thought, yep, that's a great way to look at it. And I hadn't really thought about that specific perspective. And so it was one of those moments. Because I do like when people will push back on something that I so firmly believe on, not that this person did. I was, frankly, having a conversation with myself based on previous conversations with other pull requests authors that I've had that it's not related to this particular pull request.

+ +

But in general, when people do push back on something that I do have such a firm belief in...and early eager optimization around memoization is something that I'm just like, I don't want to do it, especially for something that's so cheap and in such a fast execution and something that we're only calling twice. There's no benefit to it at that point. But then when someone says, "Well, but it's not hurting anything," then I appreciate that question because then it's more of not just pushback, but it's sort of well, tell me more. What is the pain that I'm introducing by keeping this in?

+ +

And then that can be a really nice conversation to have with someone around; like you just said, I've seen caching bugs, and this could be a caching bug, and they are painful to then triage. And so we've introduced this optimization, but it's actually just going to cause us debugging pain later. And we really didn't even get the reward from it in the first place. So I really like those conversations when I feel like there's a little bit of a challenge of where I'm like, oh, I hold this as a deep truth, and somebody doesn't, and I would like to have that conversation with them.

+ +

There are also some other fun conversations; one was around introducing a query object, which, as you know, we're both really big fans of. And then there was another great question because not everybody who works on this team is really familiar with Ruby and RSpec. They work in Scala, but then sometimes they hop over to the Ruby side. And so then they hop into the Ruby channels, and they're asking questions. And one of them was around the idea of introducing an RSpec Matcher. And they're like, "Am I doing this right? Is this how you would extract something to then improve your test? "

+ +

And so that was a really fun conversation around like, yes, you did it right. This is exactly how you write a Matcher. But let's talk about use cases because extracting something to an RSpec Matcher to me means it meets the most generalized sense of usefulness that you want the whole team to use this and that you're willing to put in the extra overhead to then introduce this essentially like new RSpec DSL for the rest of the team to use and then maintain that. So it is the most aggressive step that I take when I'm trying to introduce a helpful tool.

+ +

So then I shared my progression for when I'm extracting something for a test. And first, I will start with just a local method to that test because then it's scoped to just that test. And from there, then I will think about extracting to a shared helper. So maybe it's a module that can get included. But then its scope can still be confined to a couple of tests, but then we've also increased some of its observability.

+ +

So then other developers will notice it and be able to share with it. And then from there, if I'm like, oh, this is super generic, it is testing time, and it's something that everybody is going to benefit from, then I reach for something like an RSpec Matcher or introducing a custom RSpec Matcher. So lots of fun testing conversations this week.

+ +

CHRIS: That was a wonderful hierarchy. I like that a lot. I feel like that would make a good blog post.

+ +

STEPH: There are some things that I realize that I just think of inherently about that I realize that would be fun to share. I'm much better at podcasting than I am at blog posting. [laughs]

+ +

CHRIS: There's this friend I know, Joël Quenneville, very good at the blogging. He could probably help talk you through writing this up as a quick blog post. But you just described this heuristic hierarchy that you have. And you could probably provide quick examples of each, and I think encapsulate that knowledge. I, too, default to podcasting because it's easy for me to just say stuff here, and then it's there it is.

+ +

But what you just said also mirrors exactly what I would think of as sort of the hierarchy and the reasons you're like, I'm not sure I'd go all the way to an RSpec Matcher. That hesitation is meaningful and comes from experience that you've had. And again, that seems sort of a trade-off of like, well, why not? Is it hurting anyone? What's the cost here? You know that cost. You have that in your head. And so now if you can capture...I don't want to put work on your plate. But I think that would be a great blog post. I would be happy to read that blog post and share it with other folks.

+ +

STEPH: Cool, cool. Cool. So I totally hear you. So here's my hierarchy. Typically, I start with a podcast, and then I share it there. And then maybe it'll go to a tweet. And then once I'm like, okay, this is super generic, it can help everybody, then we've reached blog post status.

+ +

CHRIS: I love how tweet is higher in the hierarchy than a podcast for you. That somehow the throw away let me just have 140 characters or 280, or whatever we're at these days, that somehow that's next in your hierarchy. But I agree; I share that place in the world.

+ +

STEPH: Yeah, just writing is hard. Here I get to show up, and I say things. And then we have wonderful Mandy, who is then editing all of our words, so there's a safety net here. If it's just me and a keyboard, who knows what's going to happen?

+ +

CHRIS: Then you'll probably think about the switches that you're using on the keyboard. And do you need a new keyboard? Should it be silent? What do we do?

+ +

STEPH: I was thinking more how many exclamation marks do you use? That's always a question.

+ +

CHRIS: Not too many, not too few. It's a difficult question.

+ +

STEPH: [laughs]

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Pivoting just a bit, [laughs] what else is going on in your world?

+ +

CHRIS: What else is going on in my world? So we are building out a whole platform over here at Sagewell, and one of the things that we need to build is a mobile app or, frankly, two mobile apps, one for iOS and one for Android. And I'll be honest; I resisted this for a while. I am a big, big believer in the web as a platform like deeply in my heart of hearts. That's the place that I want to spend my time. That's the thing that I believe in.

+ +

And there are absolutely cases where truly native mobile apps shine, completely outshine what we can do on the web platform sometimes for reasons that are, I think, not great, limitations of the available mobile web platforms, et cetera, reasons that I'll slam my fist on the table or whatever it is.

+ +

But there are plenty of really great mobile experiences, offline, et cetera, that we just can't...offline is not even a great example. See, I can't even find a great example. There are definitely things, though, where truly native mobile apps are 100% superior. But again, I'm such a big fan of the web platform that that's what I wanted to do. I wanted to hold on to this dream of, like, what if we just make a really great web app and it's just great?

+ +

And then consistently, our backend is one singular thing. Our frontend is kind of one singular thing. And yeah, we got to deal with responsive design. But that's to me a much more tractable problem than fracturing our entire application architecture across a bunch of different platforms and having all of the logic of our domain splintered and especially depending on how you implement it. That's sort of a big question.

+ +

I've talked a ton about Inertia.js on this podcast, and that's because I believe it's a really great example as to how to pull some of the logic back to the server-side, which, in my experience, that's where I want the logic to be implemented, our deep domain logic. I just want that to be on my server in a Rails controller, or a Rails model, or a command object, or any of those sorts of things, query objects, all of these wonderful things but server-side that's centralized in one space.

+ +

Nonetheless, though, we had to build a mobile app. These are the truths of the world. Sometimes it just comes down to the expectation of your user base. And there are certain things that by building a mobile app we will get so, for instance, in our case, having biometric login, so fingerprint, or facial ID, or any of those sorts of things. Those are actually material security differences. They are actually, as far as I can tell, available on the web but not consistently on every browser, et cetera. So that's something that we can get by having our app as a native app.

+ +

Push notifications is another one that certain platforms, certain web platforms have dragged their feet on, Apple Safari. iOS Safari, specifically, I'm looking at you, but that's an example of something that by going the truly native route, we'll get that. Similarly, access to some of the lower-level things, cameras, et cetera, that is something that we'll get a better experience of. And again, you can hear in my voice I don't want to really seed it to the native platform, but it is true right now, at a minimum.

+ +

So we had a decision to make as to how we would implement these applications, and we went with an interesting route. So for anyone that's familiar with Turbolinks native, or I believe Turbo iOS is pretty similar. But I'm more familiar with Turbolinks native as there was a talk I Can't Believe It's Not Native I think is the name of the talk that was given a while back talking about the Turbolinks native architecture.

+ +

So basically, what's happening under the hood is let's still render these things server-side. Let's send down some HTML. In our case, it's a weird sort of hybrid of HTML and not HTML. But broadly, let's say that the server is rendering things. And our native application is going to then be a native shell that wraps around WebViews. But it does so in not just a single WebView sort of way. It's instead trying to find that optimum hybrid spot where let's do native things where they make sense.

+ +

So, for instance, we have introduced a tab bar at the bottom of our application that is a truly native UI. We similarly have push notifications, biometric login, et cetera. Those are features of the native platform that we're using. But then, for most of the screens, most of the screens that are just some text, maybe a button, maybe a form, et cetera, we are using the server-rendered code that we have. And so server-rendered, in our case, because we're Inertia, it's sort of a misnomer because technically it is being rendered on the client-side in the WebView. But, I don't know; we're now getting too nuanced and in the weeds for it.

+ +

But what we've opted for is to reuse the same views, controllers, et cetera. All of that is still being reused. Our iOS and our Android codebase at this point are wrappers around those WebView stacks. So it's not just a singular WebView; it's a stack of WebViews. So if you're doing swipe to navigate thing on iOS, that'll work...or Android. I think Android has an actual back button, though, within the applications.

+ +

But most importantly, we've introduced a tiny little bridge layer. So from our WebViews, we can communicate to the wrapping native context. And similarly, from our native context, we can send messages into our WebView. So we can have a button in our native UI. And when a user clicks that button, it will send a message to the WebView that it's wrapping around and vice versa. We can do push notifications. We can do all that sort of stuff. For any given view, like, say, the login view, we can say, "Hey, don't render the normal server-side thing. Instead, render this truly native, local Swift or Kotlin view that we want to use there."

+ +

So it's an interesting choice. I think it's something that I've certainly seen applications that are just like, let's take some HTML and wrap it in a WebView, and it'll be fine. And they don't make great apps. But I think this time it might just be a good idea. I actually do think that the approach that we're taking, at a minimum, is buying us a ton of simplicity in terms of having to duplicate what are somewhat nascent domain concepts across multiple platforms.

+ +

We're not entirely certain as to what our platform and what our business is going to be. So we'd love to non-enshrine that across three different platforms that are hard to update. Like the web, I can kind of change that every day. But iOS and Android because I have to go through review cycles, because I have to get them out to devices, because there are slow update cycles that individuals will use, I'm going to be stuck supporting whatever version of these applications are out there.

+ +

And so if more of that is the dynamic content that's driven by the server, frankly, I just feel way better about that, at least for now, at least for the point in time that we're at. But I kind of believe that this may be a really useful architecture for us long term.

+ +

That was a bunch of me rambling about the architecture. Let me pause there, thoughts, questions, comments, concerns?

+ +

STEPH: First, I really appreciate the thoughtful approach and explanation. Also, you highlighted the reasons that y'all are pursuing having a native app, and all of that makes a lot of sense. Because there is that user expectation of you told me about a service that then there must be an app that I can download because that's what I'm accustomed to using versus having to go to a browser and then having to then remember the URL of the site that I'm supposed to go to. So there's that convenience factor.

+ +

There's also the idea that some people go to the App Store and search for their solutions instead of going to a browser and searching for a service. So having that presence in the App Store can seem like a really huge win because then even if it maybe slowly pushes them back to use the website or as long as they get a decent experience, they've now at least been exposed to the idea of the service and that it's out there.

+ +

But then, as you pointed out, building a mobile native application is a lot of work. And then it becomes a question of like, well, are you going to hire people to work specifically on these platforms? And then, is it really worth that investment at this point? Or is it worth the approach that you're taking where you're going the more hybrid approach? I am curious; maybe this is something that you'll know. So as you are investing in this hybrid approach and you are starting to collect more users that are then using the app versus going to the browser, then what does that pivot look like, or how does that further investment look like?

+ +

If you realize that the UI isn't quite delivering the expectations that you want that if you'd actually built a native iOS or Android application, then what does that investment look like? Can you still reuse some of the work that you've done? Is it totally scrapping that work? I think that would be my biggest question around taking this first approach. Is it an all-in bet that we are now stuck to this? Or is there some salvageable pieces to then move this forward into native apps should we need to do that?

+ +

CHRIS: That's a heck of a question. Have you made a terrible decision or just like an iffy decision? I think that the framework that we're choosing or, frankly, building right now will actually be amenable to a potential transition entirely into the native world in the future. So again, one of the options that we have here is the ability to say, no; this facet of the application is entirely native. We're going to opt-in.

+ +

And so it actually happens at the navigation layer. So we can say, if a person transitions to the /user/signin route, instead of just rendering that WebView right in place, push a native Swift or Kotlin. Depending on the context that we're in or the platform that we're in, push the native view onto the stack and use that. And so we're able to, on a screen-by-screen basis, make a decision of no, we'd like to opt into native behavior here.

+ +

And so, if we did eventually see that the vast majority of the users of the platform are using it via the native app, we should probably continue to invest in that and push in that direction. I think we could do it in sort of a gradual style, and that is critically important to me. I don't want to make a big bet and then be like, oh no, we got to rewrite from the ground up. And there's no way to do that incrementally. It's going to be a whiz-bang Friday launch that everyone's going to hate. That's the thing I want to avoid most in the world.

+ +

And so I think what we found now is this seems great for right now because it allows us to avoid this complexity explosion of three different platforms and trying to keep them in sync and trying to keep them up to date. But it does, I think, give us an opportunity as we move forward to slowly sort of transition things over. We are, to state it, this isn't just like wrapping a WebView around things. We are building essentially a mini framework on both iOS and Android, or roughly Swift and Kotlin is what the actual languages are, to work with Inertia because inertia is the core technology that we're using.

+ +

Inertia, thankfully, has a nice little event system in there, so we can say, Inertia on navigate. And when a navigate event happens, we can hook into that and then connect it to whatever Swift or Kotlin runtime that we're building here. And there are a couple of different events that we can opt into. And so that's giving us the hooks that we need in the current architecture.

+ +

But longer-term, if we needed to, we could just, I think, slowly transition everything over to be truly native mobile, and then that would probably be backed by more traditional API endpoints and that sort of thing. I want to avoid that. That's my dream is to stay in this happy place where we're always going to need some web presence. And I would hate for those to be fractured distinct things.

+ +

I've worked with enough mobile apps that are wonderful native experiences, and yet I'm like, could you just give me the desktop view? Just scaled to...like, I'll even pinch and zoom because you're hiding data from me, and that makes me very, very sad. Please give me the buttons, and the text, and the content that you would give me on the web. And the fact that you're not is just breaking my heart right now. And, frankly, for our user base, consistency of experience is something that I think is really important. So that's another facet of the conversation that is really interesting to me of like; I don't want it to be different on each platform.

+ +

Certainly, a three-column layout doesn't work on an iOS app that is zoomed in 150%. But we can turn that into each column is just floated down and then otherwise have all the content in there. And I believe in that as sort of a fundamental truth of let's reshape the content but not fundamentally rethink it. I say that as something that I believed deeply. But as I said it out loud, I was like, yeah, but also, I don't know, make it work on the platform it's on. So I can see both sides. But I have had enough experiences personally where I'm sad about the app that I'm using.

+ +

STEPH: Yeah, I could also see an argument for both ways where you don't want it to be fundamentally different, but then also, you want it to fit the platform. And then there may be some advantages to the fact that there is a different platform, and you want to utilize that. I also agree with the not hiding of the data. I have felt that pain where I have an app, but I really want to go to my desktop, and I really want to use it there. But then on mobile, it's then hiding, and I realize it's hiding. And that inconsistency really frustrates the heck out of me. So I can understand that as well.

+ +

Overall, I really like this. You're taking a bet in a direction of we should have a mobile presence, and we should start attracting people through this new marketplace. But we want to reuse a lot of the logic that we already have before we go so far as then we're going to have to start building for each different platform. Because while I don't have a lot of experience in that area, the times that I have been part of teams that are building native apps, it's a big investment.

+ +

I mean, they hire people very focused on that; designers have to design for browser, for mobile, and then for native, and then everything has to stay in sync across. You have to think about how a feature is going to work across all three of those different views. And so it is certainly not something to go into lightly, which I think is exactly what you're describing is that you're looking for that in-between to how can we start working our way in this direction but yet also do it in a way that we're reusing a lot of the work that we have versus having to invest full sail into then building out these different platforms?

+ +

So I'm going to go with this is not a terrible idea. [chuckles] I'm excited to see how it feels once I can download this and check it out. I'm excited to then see how that feels from a UX perspective. But overall, everything you're saying really jives with me. It makes a lot of sense. I am curious, what about React Native? Is that something that you considered using?

+ +

CHRIS: Oh yeah, great question and definitely something that we considered. We're not using React on the backend, so that was actually a consideration when I was thinking about Svelte initially is I assumed we'd be building a React Native app eventually for the native platforms. But I talked myself into Svelte for the web, and that is not the reason that we're not using React Native for the native apps. But it is an interesting sort of constellation of technologies that we have now.

+ +

We're not using React Native because I'm clinging to this idea of what if we could have a singular experience? So React Native fundamentally you're building a native app that this is this bundle that you download that's got all of the UI and that front-end logic in that bundle that you download. And then when it wakes up, it makes some calls back to some APIs to get some data or to decide if I can do an action or to actually do an action, all those sorts of things. But you're building out a Rest or GraphQL or one of those APIs.

+ +

And with my explorations of Inertia, I found that what if I didn't need to do that? What if I could do a more traditional Rails CRUD-like experience but CRUD in a good way (I mean it in the very positive sense of the familiar architecture) and still give users a delightful experience but not have to build a distinct API where all of the or majority of the logic was on our client-side? So if I did that, then my web client would need to be that much smarter. And each of the iOS and Android clients would need to be that much smarter because that's fundamentally how these technologies work.

+ +

UI components they can give a higher fidelity experience, more native-like experience, but they tend to own a lot more of the smarts. And one of my core beliefs is however long I can get away with this, I want to keep as much intelligence on the server as possible and have my view layer be as minimal and as simple as possible.

+ +

So I think React Native is a really fantastic technology for that sort of work. But my goal was to avoid that sort of work entirely. What if we had a singular way that we had the logic exist on the server-side, and then we rendered pretty minimal view layers? Or, from a user experience, the view should do all this stuff and show all of the things that they want. But I want that view layer to be as naive as possible. And by naive, I mean in the positive sense of like, I want to be able to change this very rapidly. I want to be able to evolve it and iterate it.

+ +

And so this is more of a buy into I think the thing that Inertia gave me is valuable enough and if I can keep using that and reuse it, especially on these mobile platforms...now if we add a new fundamental part of our Sagewell platform, if we have that, it just exists on each of the iOS, the Android, and the web, and that's fantastic. And we're going to keep a really close eye on what experience that gives to the user. And is it still great? But presuming it is, the complexity savings there are so huge.

+ +

Our team is a team of web developers that is able to think about things holistically and singularly. We implement it once within our stack, and it just works. And if we can do that, that is worth a ton. We may not be able to do that forever. But for now, especially while we're figuring things out, while we're super early on as a company, I think that savings and complexity is worth a lot. So it'll be interesting to see how it plays out, and will certainly report back. But I'm a big believer in this little adventure we're on.

+ +

STEPH: Yeah, you said it perfectly there at the end; you're a team of web developers. And so as long as you can stick to that, then that's what's best for y'all and the team and the product. So that's wonderful. I have a short segue because I had a little bit of inspiration when we were talking about terrible ideas. I want to circle back to your other terrible idea because I have a terrible idea for your terrible idea about strings and symbols.

+ +

Okay, so my terrible idea is you're talking about using HashWithIndifferentAccess for everything. What if you had a class or method that then will first try to access via string and if that fails, access via symbol, and then if that fails, then it fails loudly? So you now have this let's try this, and then let's try the next thing. I have strong feelings about this as I'm saying it.

+ +

CHRIS: [laughs]

+ +

STEPH: But we're in the terrible idea segment, so I'm going to embrace it. This is my terrible idea.

+ +

CHRIS: HashWithIndifferentAccess with runtime exceptions. I think HashWithIndifferentAccess under the hood probably does what you're describing of, like checks one and then checks the other or checks has_key is probably the underlying implementation. I haven't actually looked at it. But some version of that makes sense. Falling back to the key error gets interesting.

+ +

I did see a different thing recently of a deep fetch, which is something that I want, to stop trying to make fetch happen, except I'm going to try and make fetch happen. We thought about this a bunch where we have these objects that we need to traverse into. So we use dig to get into the third layer of the object, but dig doesn't care. And it's just going to happily nil out whatever. So I'm like, no, dig but then right at the end, fetch, deep fetch. I saw somebody post this recently. So deep fetch is something I want to make happen. HashWithIndifferentAccess, which raises at the end also intriguing.

+ +

STEPH: So yes, but this will be a little different because this one, you don't have to do the transformation process upfront with HashWithIndifferentAccess where you have to pass the data first, and then it transforms it so then it can do these two different lookups or the fallback. This one, you're skipping the transformation process, and you're using your own custom method that then does that first check for a string or first check for a symbol and then default back to the other one and then fail loudly, yeah, if both of those fail.

+ +

CHRIS: Interesting, and I have to see what it looks like in practice. But I mean, broadly, I'm into something in this space. Let us find some simplicity. That is what I want.

+ +

STEPH: Let's find some terribleness and see which one feels not so terrible. [laughs]

+ +

CHRIS: Some terrible simplicity. Well, I like that idea. We'll see where we get to with it. But I think on that note, and we've said a bunch of stuff today, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris is helping with efforts to introduce security, practices, and policies at Sagewell. Right now, they are refining the usage of 1Password to standardize passwords and secure information. He also shares (what he believes) is a terrible idea around fixing inconsistencies around symbols and strings.

+ +

Steph shares an update around factories.

+ +

Also, at Sagewell, Chris is helping to build mobile apps, one for iOS and one for Android, and is considering pursuing having them be all native. Good idea? Terrible idea? Chris and Steph riff on that a bit.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Weird stuff happens when we sing, Steph.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: Hello, Steph. What is new in my world? We are continuing with some of the efforts that we're doing to introduce security, and practices, and policies, and all those fun sorts of things at the organization. One of the things that this is pushing on is we are further refining our usage of 1Password at the company as a way to standardize passwords and secure information and how we store that, how we move it around, as well as integrating SSL, and all those other fun fancier things.

+ +

But I'm personally historically a LastPass user, and now I'm getting to experience 1Password. So now I'm a child of two worlds, and it's terrible, and I hate it. I hate every moment of this existence. So what I need to do is move over to 1Password, but now I'm in that space where I'm like, I can see the flaws of both systems. This is terrible. I don't like it. 1Password does seem to be great; I will say that. There's one really interesting thing about 1Password. I'm interested...you're a 1Password user, right?

+ +

STEPH: I'm not; I use LastPass. I'm also a child of two worlds because we use 1Password for thoughtbot stuff, but then I use LastPass for my stuff.

+ +

CHRIS: Gotcha. Okay, so you survive in the middle space. I'm slowly trying to move everything over because I think 1Password has a little bit more of what I'm going for. And I would like, frankly, to be in one cohesive, consistent space, although having two different accounts seems interesting. I definitely can handle it. But knowing which I'm in and how to save a password to one versus the other, it's a whole thing.

+ +

The one thing that I find really interesting though is 1Password has a feature where it will do two-factor, two-factor authentication. It will do that for you. Specifically, it's doing, as far as I can tell, the TOTP. I don't know what that acronym stands for, but it's the fancy type of two-factor, so not SMS, not text message-based, and not others like WebAuthn is a thing that I've heard of, which I don't know if that is distinct from YubiKey or hardware keys. So there's a bunch I'm trying to learn about this space a little bit more.

+ +

I'm very interested in the hardware keys because those seem cool. WebAuthn seems like a new standard. That sounds cool. Don't know anything about it, though. So mostly, I know about SMS, and I do not like that one. I do not want to use text messages because, as far as I understand it, they're not super secure. So that's not the space I want to be in. But the TOTP, the Google Authenticator, or Authy, or that space of password or two-factor code generation tools those seem good.

+ +

And 1Password has a feature where they're like, hey, yeah, sure, we'll have your password and your two-factor. And so they grab the QR code, which is typically the QR code is a way, as far as I understand it, to share the seed. And then, that seed is used by an algorithm to generate the current code value for a given point in time. So it takes like, given that seed and the current timestamp, we will generate you the relevant code, which can then be verified on the far side. But that seed only exists for one moment in time, et cetera, et cetera.

+ +

But I've always thought of it as this separate thing. The idea of having that all in one system is interesting and kind of scary to me. But as I think about it, I'm like, if 1Password or LastPass, in either case, gets compromised, we're all done. Like, this is over. We should throw in our cards, give away the internet. This whole experiment has failed is my sense. But it was very interesting because I had not seen this. I've always had these as separate systems.

+ +

So for me, I have had LastPass, and I have Authy on my phone for the two-factor. But it's frankly very clunky, and I don't like it. And the 1Password thing is fantastic where I say like, yeah, 1Password, fill in my password and username, and then also fill in my two-factor because you have it. This is great. But, and this is where I hesitate, and I don't know, I will say this: I trust that 1Password has thought about this deeply way more than I can and have come to a place of deep confidence that this is a fine and okay thing to do. But I'm still intrigued. What's going on here?

+ +

STEPH: That was a lot. I have so many thoughts. [laughs]

+ +

CHRIS: Sorry, that was a lot of words, a lot of ideas, a lot of space there. It's just where I'm at.

+ +

STEPH: People couldn't hear me, but I was laughing when you were talking about LastPass or if these accounts get hacked in. And I'm imagining someone who uses the combination of their cat's name and their birthday as their password and then like, aha, I win. [laughs] It's like, no, we just all lose. [laughs] But that amused me.

+ +

Going back, you talked about having it all in one place. And that actually doesn't surprise me that we're different in this area. Because you also like all of your email...you like one source of everything, which makes so much sense, but I'm different. And with these accounts, I like that I have the distinction between all of thoughtbot is in 1Password while all of mine is in LastPass because it's just a very clear delineation between those two accounts. And I'm sure both of these platforms have figured out a really good way to then separate those two.

+ +

But I just remembered there was someone at thoughtbot that accidentally...because they have everything in 1Password, they accidentally shared their personal vault with a client. And so they were just typing in Slack. They're like, "Oh, shit, oh shit, like, how do I undo this?" And we're all just watching like, "We don't know. But please let us know how it turns out." [laughs] It turned out fine. I think they actually realized they hadn't fully shared it but based on the UI they thought that they had. So it all turned out okay. So that just lives with me. I'm a little scared of that now now that I know that story. So watch out, friends.

+ +

CHRIS: Oh, wow. Well, now, yeah, I'm also now scared of that. I wasn't, but now I am.

+ +

STEPH: And I forgot the other thoughts now. Those were my two main thoughts based on the journey that you've shared.

+ +

CHRIS: Particular to the thing you were sharing there, yes, now I will have nightmares about it. But also, it feels manageable because they're both entirely different accounts, and then also within that, there are different vaults. So as I'm building up the password infrastructure at Sagewell, there's going to be different...like, the dev team will probably have one vault and then a shared vault for the dev team. And then other teams within the organization will have that. And so it feels like there are at least structures within the tool to manage that.

+ +

But mostly, my consideration is around the two-factor thing. And like, is this reasonable to do? And again, I'm sure 1Password has thought way harder than I have about it. And I trust that they're like, yeah, this seems fine that they're not just like, I don't know, it doesn't seem bad. They're like, no, no, definitively for information-theoretic reasons, this is fine. But it was surprising.

+ +

STEPH: That was it. The other comment that you made about two-factor auth that resonated with me because there was a point not that long ago where we have one of those, either New Relic or I forget which account it was, but it was with the systems. We really only needed one person to have access, but every now and then, someone else may need to access that account. And so we wanted to be able to store it in 1Password or LastPass somewhere like that.

+ +

But then the two-factor auth was a problem because then you had to coordinate with that other person to say, "Hey, I just need to check something. Would you let me in?" And because we could then leverage that feature, then we could just store all of it. And then that person could just go to 1Password or LastPass and then have access to all of it, and that was really nice. That was a very nice solution to I want to say it was a small problem but yet also very important for team happiness. So that was really nice.

+ +

CHRIS: The amount of times that I've been like, "I just tried to sign in to the shared account, and it says that it sent a two-factor request to somebody's phone, but it didn't tell me whose phone. And I'm not sure if we know who that person is or if that person's still around," that version of the story feels true. And so, the idea of being able to centralize two-factor seems great. It almost feels too good to be true, is perhaps where I'm at. I am putting on my tinfoil hat, and I'm saying, yeah, but oh man, security, though.

+ +

And again, I will 100% defer to 1Password on this. They've thought about it. But it's mostly I want to get to the place where I understand the thought process that they went through to decide that this is perfectly fine because they definitely did that work. I'm certain of that. I just want to read a white paper or something, and I haven't found it yet. [laughs] I'm like, let me get to that deep place of trust because that's what I want to be at with security tooling and those sorts of things.

+ +

STEPH: Yeah, I haven't looked for something like that, but that sounds...I'm kind of surprised that doesn't exist.

+ +

CHRIS: Oh, it quite possibly exists. I haven't done much of a search, frankly, at all. Mostly, I'm in the space of like, huh, that's weird and then moving on with my day. Because there's not a lot of free time to go search for the white papers on the internet. But yeah, so moving from 1Password or LastPass or 1Password, or maybe I'll just end up with both for a while. I really hope I don't end up in that space, although you're describing it as a positive, so maybe I will.

+ +

STEPH: I have found it helpful for me. When you find that white paper, because you are more likely the type of person to read that white paper than I am the type of person to read it, then I would love a summary. That would be much appreciated.

+ +

CHRIS: I'm so intrigued by the persona that you're describing of me of; like, you're the kind of person who would read a white paper. I'm like, well, I don't know if that feels true or if it's definitely true or definitely not true. But if I do happen to find it, and especially if I happen to read it, [laughs], I will share it with you and perhaps with the listeners as well.

+ +

Let's see, one other small thing. I have a bad idea. I don't want to share the bad idea with you. I want to more share it with the audience, and then I want the audience to tell me exactly how bad of an idea it is.

+ +

STEPH: [laughs]

+ +

CHRIS: Because I'm sure it's a bad idea. I'm just not sure how bad.

+ +

STEPH: I love that there's not even a scale of goodness here. It's just nope, this is terrible, but I don't know how terrible it is. [laughs]

+ +

CHRIS: What's fun is in the later parts of this episode, we're going to go into a segment of good idea, bad idea, sorry, good idea, terrible idea because I like that framing. No, this one is firmly bad idea, but how bad is the question. So we're working on the app, and we keep running into inconsistencies around symbols and strings.

+ +

As any Rubyist who has worked in the language for any amount of time, especially in a Rails app, you have experienced this unpleasantness. There are strings; there are symbols. They're often used somewhat interchangeably, and yet they're different. You’ll hit bugs. You'll hit edge cases. You'll hit nils that you didn't expect to be there because you tried to fetch a symbol. It, in fact, was a string, et cetera.

+ +

So, what if we just applied HashWithIndifferentAccess everywhere, just deep in the internals of the app or in the Ruby runtime? What if we were to just turn this on? My sense is this would be terrible for performance reasons. My understanding is that's why symbols exist is because they are a more performant mechanism. Strings are complicated within the object model of Ruby because they're mutable. These are things that I understand very loosely, as you can tell by the tone of voice that I'm using. But symbols and strings they're separate. They're separate for reasons, performance I believe to be the main reason.

+ +

But what if we were to just say, well, what if it could be like easy, though? That's what I want. Like, this is the promise of Ruby is that I want to express my code in a way that feels like the words I would use to describe to another human. That's the way I always think of Ruby is it's as close to the words I would use to describe the sort of business logic as possible. And yet these symbols versus strings thing it's just annoying, frankly. And again, I think very good reasons for it, I'm sure.

+ +

But what if we were to just do the silly thing and turn on HashWithIndifferentAccess for everything? I don't even know that that's fundamentally possible. I don't know that there's the relevant hook or the way to do that. But I would love that because we're using it somewhat regularly throughout our app right now, where we're getting data from one API. And in our test suite, it's one way, and in our code, it's the other way. And granted, that speaks to us being inconsistent in our usage. But overall, I would just love for this to not be a thing.

+ +

And so, how bad of an idea would it be? How much of a performance hit? That's my guess as to what it would be. Maybe there's actual fundamental correctness that would go wrong here. But my sense is by collapsing the space together; we would actually get more correct. I don't know. Anyway, how bad do you think of an idea this is?

+ +

STEPH: I was thinking through some of the bugs that you're running into. And I think you provided some nice insight around that around it's the fact that you're fetching data from API. So it's typically you're parsing. That's how you're getting the string and symbol differences is because when you're parsing JSON and then you have a mixed case of maybe you have a symbol, maybe you have a string, or maybe you're parsing it differently. Are there other places in the application where that's a concern?

+ +

CHRIS: I want to say one other place that we're running into it specifically is we're using a lot of enums, particularly ActiveRecord::PGEnum backed enums. So these are Postgres enums at the database level. And then, within our Rails models, we define them as enums. And the enum is typically defined within the model as a mapping of symbol to string. It could be symbol to symbol. I'm not even sure. I think this might be in terms of our implementation.

+ +

But you say like, it's an enum. The key is foobar with an underscore, and it's a symbol, and then the value is foobar, but it's a string. And maybe both the key and the value could be symbols; maybe that's a thing, maybe this is our fault. But certain times, when you're interacting with the value, it's a symbol. Certain times I find it to be a string. I feel like that's true. I don't think I'm making that up. [laughs] It's possible I'm making it up.

+ +

But that's another place where I feel that inconsistency or other values within the system that like as they go through certain type coercion layers, they'll start as a symbol, and then they get saved to the database, and then they get reflected back, and they come back as a string. And it's like, well, that's unfortunate. It was a symbol a minute ago, and now it's a string. And so our tests suddenly break in this way, or our code is inconsistent. And it's enough of a nuisance that I had the bad idea the other day. And so, I wanted to bring the bad idea to this space.

+ +

STEPH: I think you're right. I think the main reasoning for not having everything just be strings is for looking for that performance benefit. And so then using that HashWithIndifferentAccess then you'd have to loop over everything and then convert it. So I imagine, like you said, there would be a performance hit there. I don't know how bad of an idea it would be.

+ +

But when you said this, it brought up a memory because I remember someone proposing or the Ruby community talking about the fact, like, what if we didn't have strings? What if everything was just a symbol? Or can we just have one over the other? And there is a ruby-lang issue; it is 7792. And we shall also put it in the show notes and send it to you. [chuckles] And this person is proposing make symbols and strings the same thing.

+ +

And then some people call out specifically the idea of using HashWithIndifferentAccess and saying, yes, that works wonderfully, but then you are going to have a performance hit for it. So it sounds exactly like everything you're saying. I don't know the outcome. I mean, clearly, the outcome is we're not there. But it seems like a really good place to see the reasoning or different approaches that maybe people have tried in this space.

+ +

CHRIS: Ooh, I love that. I definitely want to read that and see what sort of deeper thinking folks have done on this. Because again, this feels like another one where definitely folks have thought about this, folks who know more about it and have chosen the current path that we're on for reasons. But I would be really intrigued if I could be like, yeah, I would just like it to be easy to start, and then have the performance optimization be something that I could opt into. Again, that's probably not tractable within the language.

+ +

Like, oh, we have a hot code path here that we want to actually have immutable symbols only. And that's the sort of thing if we've done this HashWithIndifferentAccess everywhere, you can't back out of it. And so, therefore, you're stuck in a performance low point. That feels like a bad case. And so maybe that's the reason is like, you will shoot yourself in the foot with this definitely.

+ +

But yeah, I'm intrigued. So I will definitely read what you're sharing here. And we'll include it in the show notes, of course. I'm probably not going to do this, just saying that out loud because it seems like a bad idea. I just want to know how bad of an idea.

+ +

STEPH: I do love it, for when I'm building a class that's working specifically closely with an API, I do reach for HashWithIndifferentAccess frequently. Because like you said, I just don't want to worry about it. I want to set it up top. It's one of the rare times that I actually will use something in an initializer where I'm like, hey, pass in the data. I'm just going to run it through this method. And then all the data from here on forward you can access it in either way. So the class doesn't have to care; a tester doesn't have to care. So I do feel your pain, or I at least will always reach for it whenever I'm building a class specifically around interactions with JSON.

+ +

CHRIS: So for a segment that I framed as how terrible of an idea this is, you're like, hmm, I don't know how terrible. That seems to be your take, which is interesting.

+ +

STEPH: Good point. Let me assess for a moment. I'm going to go just from skimming this issue, although I think partially this issue is talking about the fact that if you merge symbols and strings, it's like, hey, friend, you're going to break a ton of stuff and break a bunch of libraries, and these two things do serve a purpose. So this may not be exactly what you're looking for, but it has some interesting conversation on there.

+ +

But embedding it deep down in the app so that just happens naturally sounds like it's just a performance concern. So yeah, it comes down to what is the question? How big is the performance? So I feel like I can't say it's a terrible idea until I actually know what the performance hit is.

+ +

CHRIS: So a plausible question. That's where we're going to put this in the category of. [laughter]

+ +

STEPH: Plausibly terrible, but still worth researching.

+ +

CHRIS: Not obviously not terrible. But anyway, these are some of the ideas at the top of my head right now. That's a rough summary of my week.

+ +

Mid-roll Ad

+ +

Hey, friends, let's take a quick break to hear from today's sponsor, New Relic.

+ +

All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem.

+ +

So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy.

+ +

That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software.

+ +

So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed.

+ +

STEPH: I have an update that I can share around factories because the last time we were chatting, I was sharing that strategy that we're pursuing where we're trying to minimize factories and then speed up the CI time by reducing the work that those factories are doing. So Joël Quenneville has done some phenomenal work and this past week, specifically improving factories. And he found one particular factory that he was digging into.

+ +

So some stats before the change. The factory was taking around two seconds, which I know on paper doesn't sound so bad, but it gets more interesting. So total database time is around 1,000 milliseconds. And 833 total database queries were being made, which includes reads, creates, and updates. So then after, Joël was diving into this looking mainly to reduce the number of database queries because that's such a big number.

+ +

So after the change, which took a lot of research on Joël's part, the factory is now taking around one second, so half of that time. The total database time is around 666 milliseconds. And the total database queries went from 833 down to 647, so a nice improvement there. But the real wonderful outcome of the story is not just those stats, but okay, so how did we impact CI? So we spent time working on this factory. And we have reduced, and we can see some of that in the stats. But how does that apply to the bigger picture?

+ +

And so Joël took the time of the last 20 successful builds, and based on those builds, we average 27 minutes and 37 seconds for each build. With the factory change that he made, that same test suite was now averaging 21 minutes and 33 seconds. So shaved off six minutes from the build time, which is about a 22% decrease in the build time which is just fabulous. So that was a really nice win from all the work that had been invested in improving that one factory.

+ +

CHRIS: That's a heck of a haircut there so glad to see that the efforts are paying off.

+ +

STEPH: Yeah, it was a really nice win to see that we had researched which factories we should pursue, and then we were methodical about that. And then Joël worked hard to improve this factory and saw such a large payoff. It's one of those areas where the team has already invested a lot of effort and hours into improving the test suite. And it's challenging when you have so many areas that you'd like to improve and 100-plus engineers also contributing to that same codebase. So how do you improve and keep up with it all at once?

+ +

They had spent about a year, so I think they were recognizing that yes, there are still a lot of areas to improve but also felt like small efforts wouldn't move the needle. So it was a nice data point to remind ourselves that we can still reduce the CI build time in a significant way. We just need to be very strategic about where we invest our time in those improvements.

+ +

There is also an interesting conversation that Joël and I were having because we have a daily sync with each other each day. We've now been embedded with a team with a client, which is wonderful, but before then, we were also chatting with each other. And we like to chat about code, so we've had lots of fun conversations around code. And one, in particular, this week, came up about how people view code differently. And there's even a tweet that Joël shared that I can link to in the show notes.

+ +

And there's one view that code is a liability, and if a line can't justify its existence, then it should be deleted. And then there's another view that code is an asset. If a line isn't causing any immediate issues, then why not keep it? And part of the reason that came up was while I was going through and reading pull requests, there was a particular change where someone was memoizing an expensive call, which was great, something that we wanted to do.

+ +

But then they were also memoizing a very fast operation in two other places where it was just like parsing some params something that, you know, superfast and only getting called in maybe two places. And it was one of those that just caught my attention to be like, hey, I love that you memoized this other call, but this one, I don't think we need the additional overhead or complexity of adding memoization.

+ +

And I found myself when I was writing that suggestion for the author that I was already looking for more than just to say, like, hey, this is more than we need. Because I've realized that often I take that stance of code is a liability. So if we don't need it, let's just get rid of it. But I've definitely run into other people where they're like, well, it's not hurting anything, so why can't I just leave it? And getting that kind of pushback on suggestions about removing code.

+ +

So it was a fun opportunity to think through okay, well, why is this memoization not just unnecessary, but how could it actually cause us problems? And what's the cost of keeping it in, not just the cost of removing it but also the cost of keeping it in? And that was fun to talk about.

+ +

CHRIS: I'm so glad you're bringing this particular conversation up because if we're being honest, I saw Joël tweeted about this. I saw it. I sent an email to myself linking to the tweet with the subject of the email being ahhhh, just A-H-H-H-H, which I believe was me being like, oh my God, we got to talk about this. I apparently didn't want to write all of those words, so I just wrote ahhhh.

+ +

But as a handful of asides, one, if you're not following Joël Quenneville on Twitter, @joelquen, that is a mistake, because Joël is one of the clearest, most concise, and effective thinkers about code that I've ever seen. The writing that Joël produces is absolutely fantastic. And having worked with Joël for forever, I still will look at his Twitter feed and be like, well, this is fantastic. You're saying amazing things that I have not heard you say. So, again, strongest recommendation I can make; please follow Joël on Twitter and also via the Giant Robots blog and all of those other places.

+ +

But in particular, I saw this one come through, and I was like, oh, man, we have to talk about this. So I actually have it up in my email app right now behind the scenes. [laughs] I was like, oh, I want to mention this to you, Steph. So I'm very excited that you're bringing it up in this moment. It is such an interesting thing. It's such an interesting case of like; I deeply believe both of these truths, and yet they do seem to be in contradiction. And so what do we do with that?

+ +

More generally, I feel like that's true of a lot of stuff in life, like, the ability to hold two competing ideas in your head and be able to know where one applies and where one doesn't. That is a critical thing to get to in life and to figure out how to do, and that's some of the hard work of thinking. But in particular, this one, the idea that code is a liability. You have a line of code...I'm going to read it precisely as Joël wrote it, "Code is a liability. If a line can't justify its existence, it should be deleted. Code is an asset. If a line isn't causing any immediate issues, why not keep it?"

+ +

And I think for me, if I were to try and interpret this, because I do believe both of those sides, I would apply one during code review. When code is coming into the application or when I'm writing code, do I need this? Do we need this? Is this necessary? Because it really should be necessary to come into the app. But then once something has made it in, especially the longer something's been in there, I think code sort of ages and matures. And so, the longer it's been part of the app and not causing an issue, the more I am liable to just leave it at rest. Just say, sure, or not at rest but as part of the runtime production code.

+ +

But these are two competing ideas, but I think they apply at different times in the conversation. And so I'm definitely on memoization. In particular, memoization is a form of caching. Caching I have run into a handful of caching bugs in my life, let me tell you. I'll probably run into a few more. So if we can avoid caching, let's do that. So that's a particular question around that thing. But again, that idea of like the point in time to have that conversation is during code review or initial authoring or when it's about to come into the app.

+ +

But if we've had some memoization in the app for forever and you're like, do we need this memoization? I don't know, but don't remove it because maybe it's very important at this point. Maybe it's one of the cornerstones holding up our application. So that's a bunch of thoughts about that. But also super glad that you brought this up because I was very excited about this particular tweet.

+ +

STEPH: Yeah, there's someone that said something very similar to what you just said around they agree with number one for all new code. And they agree with number two, where code is an asset for refactoring. And I thought, yep, that's a great way to look at it. And I hadn't really thought about that specific perspective. And so it was one of those moments. Because I do like when people will push back on something that I so firmly believe on, not that this person did. I was, frankly, having a conversation with myself based on previous conversations with other pull requests authors that I've had that it's not related to this particular pull request.

+ +

But in general, when people do push back on something that I do have such a firm belief in...and early eager optimization around memoization is something that I'm just like, I don't want to do it, especially for something that's so cheap and in such a fast execution and something that we're only calling twice. There's no benefit to it at that point. But then when someone says, "Well, but it's not hurting anything," then I appreciate that question because then it's more of not just pushback, but it's sort of well, tell me more. What is the pain that I'm introducing by keeping this in?

+ +

And then that can be a really nice conversation to have with someone around; like you just said, I've seen caching bugs, and this could be a caching bug, and they are painful to then triage. And so we've introduced this optimization, but it's actually just going to cause us debugging pain later. And we really didn't even get the reward from it in the first place. So I really like those conversations when I feel like there's a little bit of a challenge of where I'm like, oh, I hold this as a deep truth, and somebody doesn't, and I would like to have that conversation with them.

+ +

There are also some other fun conversations; one was around introducing a query object, which, as you know, we're both really big fans of. And then there was another great question because not everybody who works on this team is really familiar with Ruby and RSpec. They work in Scala, but then sometimes they hop over to the Ruby side. And so then they hop into the Ruby channels, and they're asking questions. And one of them was around the idea of introducing an RSpec Matcher. And they're like, "Am I doing this right? Is this how you would extract something to then improve your test? "

+ +

And so that was a really fun conversation around like, yes, you did it right. This is exactly how you write a Matcher. But let's talk about use cases because extracting something to an RSpec Matcher to me means it meets the most generalized sense of usefulness that you want the whole team to use this and that you're willing to put in the extra overhead to then introduce this essentially like new RSpec DSL for the rest of the team to use and then maintain that. So it is the most aggressive step that I take when I'm trying to introduce a helpful tool.

+ +

So then I shared my progression for when I'm extracting something for a test. And first, I will start with just a local method to that test because then it's scoped to just that test. And from there, then I will think about extracting to a shared helper. So maybe it's a module that can get included. But then its scope can still be confined to a couple of tests, but then we've also increased some of its observability.

+ +

So then other developers will notice it and be able to share with it. And then from there, if I'm like, oh, this is super generic, it is testing time, and it's something that everybody is going to benefit from, then I reach for something like an RSpec Matcher or introducing a custom RSpec Matcher. So lots of fun testing conversations this week.

+ +

CHRIS: That was a wonderful hierarchy. I like that a lot. I feel like that would make a good blog post.

+ +

STEPH: There are some things that I realize that I just think of inherently about that I realize that would be fun to share. I'm much better at podcasting than I am at blog posting. [laughs]

+ +

CHRIS: There's this friend I know, Joël Quenneville, very good at the blogging. He could probably help talk you through writing this up as a quick blog post. But you just described this heuristic hierarchy that you have. And you could probably provide quick examples of each, and I think encapsulate that knowledge. I, too, default to podcasting because it's easy for me to just say stuff here, and then it's there it is.

+ +

But what you just said also mirrors exactly what I would think of as sort of the hierarchy and the reasons you're like, I'm not sure I'd go all the way to an RSpec Matcher. That hesitation is meaningful and comes from experience that you've had. And again, that seems sort of a trade-off of like, well, why not? Is it hurting anyone? What's the cost here? You know that cost. You have that in your head. And so now if you can capture...I don't want to put work on your plate. But I think that would be a great blog post. I would be happy to read that blog post and share it with other folks.

+ +

STEPH: Cool, cool. Cool. So I totally hear you. So here's my hierarchy. Typically, I start with a podcast, and then I share it there. And then maybe it'll go to a tweet. And then once I'm like, okay, this is super generic, it can help everybody, then we've reached blog post status.

+ +

CHRIS: I love how tweet is higher in the hierarchy than a podcast for you. That somehow the throw away let me just have 140 characters or 280, or whatever we're at these days, that somehow that's next in your hierarchy. But I agree; I share that place in the world.

+ +

STEPH: Yeah, just writing is hard. Here I get to show up, and I say things. And then we have wonderful Mandy, who is then editing all of our words, so there's a safety net here. If it's just me and a keyboard, who knows what's going to happen?

+ +

CHRIS: Then you'll probably think about the switches that you're using on the keyboard. And do you need a new keyboard? Should it be silent? What do we do?

+ +

STEPH: I was thinking more how many exclamation marks do you use? That's always a question.

+ +

CHRIS: Not too many, not too few. It's a difficult question.

+ +

STEPH: [laughs]

+ +

Mid-roll Ad

+ +

Hi, friends, and now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Pivoting just a bit, [laughs] what else is going on in your world?

+ +

CHRIS: What else is going on in my world? So we are building out a whole platform over here at Sagewell, and one of the things that we need to build is a mobile app or, frankly, two mobile apps, one for iOS and one for Android. And I'll be honest; I resisted this for a while. I am a big, big believer in the web as a platform like deeply in my heart of hearts. That's the place that I want to spend my time. That's the thing that I believe in.

+ +

And there are absolutely cases where truly native mobile apps shine, completely outshine what we can do on the web platform sometimes for reasons that are, I think, not great, limitations of the available mobile web platforms, et cetera, reasons that I'll slam my fist on the table or whatever it is.

+ +

But there are plenty of really great mobile experiences, offline, et cetera, that we just can't...offline is not even a great example. See, I can't even find a great example. There are definitely things, though, where truly native mobile apps are 100% superior. But again, I'm such a big fan of the web platform that that's what I wanted to do. I wanted to hold on to this dream of, like, what if we just make a really great web app and it's just great?

+ +

And then consistently, our backend is one singular thing. Our frontend is kind of one singular thing. And yeah, we got to deal with responsive design. But that's to me a much more tractable problem than fracturing our entire application architecture across a bunch of different platforms and having all of the logic of our domain splintered and especially depending on how you implement it. That's sort of a big question.

+ +

I've talked a ton about Inertia.js on this podcast, and that's because I believe it's a really great example as to how to pull some of the logic back to the server-side, which, in my experience, that's where I want the logic to be implemented, our deep domain logic. I just want that to be on my server in a Rails controller, or a Rails model, or a command object, or any of those sorts of things, query objects, all of these wonderful things but server-side that's centralized in one space.

+ +

Nonetheless, though, we had to build a mobile app. These are the truths of the world. Sometimes it just comes down to the expectation of your user base. And there are certain things that by building a mobile app we will get so, for instance, in our case, having biometric login, so fingerprint, or facial ID, or any of those sorts of things. Those are actually material security differences. They are actually, as far as I can tell, available on the web but not consistently on every browser, et cetera. So that's something that we can get by having our app as a native app.

+ +

Push notifications is another one that certain platforms, certain web platforms have dragged their feet on, Apple Safari. iOS Safari, specifically, I'm looking at you, but that's an example of something that by going the truly native route, we'll get that. Similarly, access to some of the lower-level things, cameras, et cetera, that is something that we'll get a better experience of. And again, you can hear in my voice I don't want to really seed it to the native platform, but it is true right now, at a minimum.

+ +

So we had a decision to make as to how we would implement these applications, and we went with an interesting route. So for anyone that's familiar with Turbolinks native, or I believe Turbo iOS is pretty similar. But I'm more familiar with Turbolinks native as there was a talk I Can't Believe It's Not Native I think is the name of the talk that was given a while back talking about the Turbolinks native architecture.

+ +

So basically, what's happening under the hood is let's still render these things server-side. Let's send down some HTML. In our case, it's a weird sort of hybrid of HTML and not HTML. But broadly, let's say that the server is rendering things. And our native application is going to then be a native shell that wraps around WebViews. But it does so in not just a single WebView sort of way. It's instead trying to find that optimum hybrid spot where let's do native things where they make sense.

+ +

So, for instance, we have introduced a tab bar at the bottom of our application that is a truly native UI. We similarly have push notifications, biometric login, et cetera. Those are features of the native platform that we're using. But then, for most of the screens, most of the screens that are just some text, maybe a button, maybe a form, et cetera, we are using the server-rendered code that we have. And so server-rendered, in our case, because we're Inertia, it's sort of a misnomer because technically it is being rendered on the client-side in the WebView. But, I don't know; we're now getting too nuanced and in the weeds for it.

+ +

But what we've opted for is to reuse the same views, controllers, et cetera. All of that is still being reused. Our iOS and our Android codebase at this point are wrappers around those WebView stacks. So it's not just a singular WebView; it's a stack of WebViews. So if you're doing swipe to navigate thing on iOS, that'll work...or Android. I think Android has an actual back button, though, within the applications.

+ +

But most importantly, we've introduced a tiny little bridge layer. So from our WebViews, we can communicate to the wrapping native context. And similarly, from our native context, we can send messages into our WebView. So we can have a button in our native UI. And when a user clicks that button, it will send a message to the WebView that it's wrapping around and vice versa. We can do push notifications. We can do all that sort of stuff. For any given view, like, say, the login view, we can say, "Hey, don't render the normal server-side thing. Instead, render this truly native, local Swift or Kotlin view that we want to use there."

+ +

So it's an interesting choice. I think it's something that I've certainly seen applications that are just like, let's take some HTML and wrap it in a WebView, and it'll be fine. And they don't make great apps. But I think this time it might just be a good idea. I actually do think that the approach that we're taking, at a minimum, is buying us a ton of simplicity in terms of having to duplicate what are somewhat nascent domain concepts across multiple platforms.

+ +

We're not entirely certain as to what our platform and what our business is going to be. So we'd love to non-enshrine that across three different platforms that are hard to update. Like the web, I can kind of change that every day. But iOS and Android because I have to go through review cycles, because I have to get them out to devices, because there are slow update cycles that individuals will use, I'm going to be stuck supporting whatever version of these applications are out there.

+ +

And so if more of that is the dynamic content that's driven by the server, frankly, I just feel way better about that, at least for now, at least for the point in time that we're at. But I kind of believe that this may be a really useful architecture for us long term.

+ +

That was a bunch of me rambling about the architecture. Let me pause there, thoughts, questions, comments, concerns?

+ +

STEPH: First, I really appreciate the thoughtful approach and explanation. Also, you highlighted the reasons that y'all are pursuing having a native app, and all of that makes a lot of sense. Because there is that user expectation of you told me about a service that then there must be an app that I can download because that's what I'm accustomed to using versus having to go to a browser and then having to then remember the URL of the site that I'm supposed to go to. So there's that convenience factor.

+ +

There's also the idea that some people go to the App Store and search for their solutions instead of going to a browser and searching for a service. So having that presence in the App Store can seem like a really huge win because then even if it maybe slowly pushes them back to use the website or as long as they get a decent experience, they've now at least been exposed to the idea of the service and that it's out there.

+ +

But then, as you pointed out, building a mobile native application is a lot of work. And then it becomes a question of like, well, are you going to hire people to work specifically on these platforms? And then, is it really worth that investment at this point? Or is it worth the approach that you're taking where you're going the more hybrid approach? I am curious; maybe this is something that you'll know. So as you are investing in this hybrid approach and you are starting to collect more users that are then using the app versus going to the browser, then what does that pivot look like, or how does that further investment look like?

+ +

If you realize that the UI isn't quite delivering the expectations that you want that if you'd actually built a native iOS or Android application, then what does that investment look like? Can you still reuse some of the work that you've done? Is it totally scrapping that work? I think that would be my biggest question around taking this first approach. Is it an all-in bet that we are now stuck to this? Or is there some salvageable pieces to then move this forward into native apps should we need to do that?

+ +

CHRIS: That's a heck of a question. Have you made a terrible decision or just like an iffy decision? I think that the framework that we're choosing or, frankly, building right now will actually be amenable to a potential transition entirely into the native world in the future. So again, one of the options that we have here is the ability to say, no; this facet of the application is entirely native. We're going to opt-in.

+ +

And so it actually happens at the navigation layer. So we can say, if a person transitions to the /user/signin route, instead of just rendering that WebView right in place, push a native Swift or Kotlin. Depending on the context that we're in or the platform that we're in, push the native view onto the stack and use that. And so we're able to, on a screen-by-screen basis, make a decision of no, we'd like to opt into native behavior here.

+ +

And so, if we did eventually see that the vast majority of the users of the platform are using it via the native app, we should probably continue to invest in that and push in that direction. I think we could do it in sort of a gradual style, and that is critically important to me. I don't want to make a big bet and then be like, oh no, we got to rewrite from the ground up. And there's no way to do that incrementally. It's going to be a whiz-bang Friday launch that everyone's going to hate. That's the thing I want to avoid most in the world.

+ +

And so I think what we found now is this seems great for right now because it allows us to avoid this complexity explosion of three different platforms and trying to keep them in sync and trying to keep them up to date. But it does, I think, give us an opportunity as we move forward to slowly sort of transition things over. We are, to state it, this isn't just like wrapping a WebView around things. We are building essentially a mini framework on both iOS and Android, or roughly Swift and Kotlin is what the actual languages are, to work with Inertia because inertia is the core technology that we're using.

+ +

Inertia, thankfully, has a nice little event system in there, so we can say, Inertia on navigate. And when a navigate event happens, we can hook into that and then connect it to whatever Swift or Kotlin runtime that we're building here. And there are a couple of different events that we can opt into. And so that's giving us the hooks that we need in the current architecture.

+ +

But longer-term, if we needed to, we could just, I think, slowly transition everything over to be truly native mobile, and then that would probably be backed by more traditional API endpoints and that sort of thing. I want to avoid that. That's my dream is to stay in this happy place where we're always going to need some web presence. And I would hate for those to be fractured distinct things.

+ +

I've worked with enough mobile apps that are wonderful native experiences, and yet I'm like, could you just give me the desktop view? Just scaled to...like, I'll even pinch and zoom because you're hiding data from me, and that makes me very, very sad. Please give me the buttons, and the text, and the content that you would give me on the web. And the fact that you're not is just breaking my heart right now. And, frankly, for our user base, consistency of experience is something that I think is really important. So that's another facet of the conversation that is really interesting to me of like; I don't want it to be different on each platform.

+ +

Certainly, a three-column layout doesn't work on an iOS app that is zoomed in 150%. But we can turn that into each column is just floated down and then otherwise have all the content in there. And I believe in that as sort of a fundamental truth of let's reshape the content but not fundamentally rethink it. I say that as something that I believed deeply. But as I said it out loud, I was like, yeah, but also, I don't know, make it work on the platform it's on. So I can see both sides. But I have had enough experiences personally where I'm sad about the app that I'm using.

+ +

STEPH: Yeah, I could also see an argument for both ways where you don't want it to be fundamentally different, but then also, you want it to fit the platform. And then there may be some advantages to the fact that there is a different platform, and you want to utilize that. I also agree with the not hiding of the data. I have felt that pain where I have an app, but I really want to go to my desktop, and I really want to use it there. But then on mobile, it's then hiding, and I realize it's hiding. And that inconsistency really frustrates the heck out of me. So I can understand that as well.

+ +

Overall, I really like this. You're taking a bet in a direction of we should have a mobile presence, and we should start attracting people through this new marketplace. But we want to reuse a lot of the logic that we already have before we go so far as then we're going to have to start building for each different platform. Because while I don't have a lot of experience in that area, the times that I have been part of teams that are building native apps, it's a big investment.

+ +

I mean, they hire people very focused on that; designers have to design for browser, for mobile, and then for native, and then everything has to stay in sync across. You have to think about how a feature is going to work across all three of those different views. And so it is certainly not something to go into lightly, which I think is exactly what you're describing is that you're looking for that in-between to how can we start working our way in this direction but yet also do it in a way that we're reusing a lot of the work that we have versus having to invest full sail into then building out these different platforms?

+ +

So I'm going to go with this is not a terrible idea. [chuckles] I'm excited to see how it feels once I can download this and check it out. I'm excited to then see how that feels from a UX perspective. But overall, everything you're saying really jives with me. It makes a lot of sense. I am curious, what about React Native? Is that something that you considered using?

+ +

CHRIS: Oh yeah, great question and definitely something that we considered. We're not using React on the backend, so that was actually a consideration when I was thinking about Svelte initially is I assumed we'd be building a React Native app eventually for the native platforms. But I talked myself into Svelte for the web, and that is not the reason that we're not using React Native for the native apps. But it is an interesting sort of constellation of technologies that we have now.

+ +

We're not using React Native because I'm clinging to this idea of what if we could have a singular experience? So React Native fundamentally you're building a native app that this is this bundle that you download that's got all of the UI and that front-end logic in that bundle that you download. And then when it wakes up, it makes some calls back to some APIs to get some data or to decide if I can do an action or to actually do an action, all those sorts of things. But you're building out a Rest or GraphQL or one of those APIs.

+ +

And with my explorations of Inertia, I found that what if I didn't need to do that? What if I could do a more traditional Rails CRUD-like experience but CRUD in a good way (I mean it in the very positive sense of the familiar architecture) and still give users a delightful experience but not have to build a distinct API where all of the or majority of the logic was on our client-side? So if I did that, then my web client would need to be that much smarter. And each of the iOS and Android clients would need to be that much smarter because that's fundamentally how these technologies work.

+ +

UI components they can give a higher fidelity experience, more native-like experience, but they tend to own a lot more of the smarts. And one of my core beliefs is however long I can get away with this, I want to keep as much intelligence on the server as possible and have my view layer be as minimal and as simple as possible.

+ +

So I think React Native is a really fantastic technology for that sort of work. But my goal was to avoid that sort of work entirely. What if we had a singular way that we had the logic exist on the server-side, and then we rendered pretty minimal view layers? Or, from a user experience, the view should do all this stuff and show all of the things that they want. But I want that view layer to be as naive as possible. And by naive, I mean in the positive sense of like, I want to be able to change this very rapidly. I want to be able to evolve it and iterate it.

+ +

And so this is more of a buy into I think the thing that Inertia gave me is valuable enough and if I can keep using that and reuse it, especially on these mobile platforms...now if we add a new fundamental part of our Sagewell platform, if we have that, it just exists on each of the iOS, the Android, and the web, and that's fantastic. And we're going to keep a really close eye on what experience that gives to the user. And is it still great? But presuming it is, the complexity savings there are so huge.

+ +

Our team is a team of web developers that is able to think about things holistically and singularly. We implement it once within our stack, and it just works. And if we can do that, that is worth a ton. We may not be able to do that forever. But for now, especially while we're figuring things out, while we're super early on as a company, I think that savings and complexity is worth a lot. So it'll be interesting to see how it plays out, and will certainly report back. But I'm a big believer in this little adventure we're on.

+ +

STEPH: Yeah, you said it perfectly there at the end; you're a team of web developers. And so as long as you can stick to that, then that's what's best for y'all and the team and the product. So that's wonderful. I have a short segue because I had a little bit of inspiration when we were talking about terrible ideas. I want to circle back to your other terrible idea because I have a terrible idea for your terrible idea about strings and symbols.

+ +

Okay, so my terrible idea is you're talking about using HashWithIndifferentAccess for everything. What if you had a class or method that then will first try to access via string and if that fails, access via symbol, and then if that fails, then it fails loudly? So you now have this let's try this, and then let's try the next thing. I have strong feelings about this as I'm saying it.

+ +

CHRIS: [laughs]

+ +

STEPH: But we're in the terrible idea segment, so I'm going to embrace it. This is my terrible idea.

+ +

CHRIS: HashWithIndifferentAccess with runtime exceptions. I think HashWithIndifferentAccess under the hood probably does what you're describing of, like checks one and then checks the other or checks has_key is probably the underlying implementation. I haven't actually looked at it. But some version of that makes sense. Falling back to the key error gets interesting.

+ +

I did see a different thing recently of a deep fetch, which is something that I want, to stop trying to make fetch happen, except I'm going to try and make fetch happen. We thought about this a bunch where we have these objects that we need to traverse into. So we use dig to get into the third layer of the object, but dig doesn't care. And it's just going to happily nil out whatever. So I'm like, no, dig but then right at the end, fetch, deep fetch. I saw somebody post this recently. So deep fetch is something I want to make happen. HashWithIndifferentAccess, which raises at the end also intriguing.

+ +

STEPH: So yes, but this will be a little different because this one, you don't have to do the transformation process upfront with HashWithIndifferentAccess where you have to pass the data first, and then it transforms it so then it can do these two different lookups or the fallback. This one, you're skipping the transformation process, and you're using your own custom method that then does that first check for a string or first check for a symbol and then default back to the other one and then fail loudly, yeah, if both of those fail.

+ +

CHRIS: Interesting, and I have to see what it looks like in practice. But I mean, broadly, I'm into something in this space. Let us find some simplicity. That is what I want.

+ +

STEPH: Let's find some terribleness and see which one feels not so terrible. [laughs]

+ +

CHRIS: Some terrible simplicity. Well, I like that idea. We'll see where we get to with it. But I think on that note, and we've said a bunch of stuff today, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+jUhoSwzj + + ]]> + + Chris Toomey + Steph Viccari + + + 327: Estimate Crafting + https://bikeshed.thoughtbot.com/327 + 12119a93-d6ff-4617-bf9f-c87c1aa69267 + Tue, 22 Feb 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph joins Chris in trying new things! For her, it's a new email client – the Newton email client – because she really wants to love her inbox. She also talks about implementing a suggestion from Chris on improving CI speed. + +Chris continues his search for the perfect to-do list app. (It's not going great.) But he has made hiring progress and is excited to move on to the next step: onboarding. + +Together they answer a listener question who asked for advice on crafting project estimates for clients. + 42:33 + no + + + Steph joins Chris in trying new things! For her, it's a new email client – the Newton email client – because she really wants to love her inbox. She also talks about implementing a suggestion from Chris on improving CI speed. +Chris continues his search for the perfect to-do list app. (It's not going great.) But he has made hiring progress and is excited to move on to the next step: onboarding. +Together they answer a listener question who asked for advice on crafting project estimates for clients. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. +Newton (https://newtonhq.com/) +Subscribe to Email Newsletters in Feedbin (https://feedbin.com/blog/2016/02/03/subscribe-to-email-newsletters-in-feedbin/) +GitHub - Shopify/packwerk (https://github.com/Shopify/packwerk) +Sunsama (https://sunsama.com/) +TickTick: To-do List, Tasks, Calendar, Reminder (https://ticktick.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: I am now recording. +STEPH: Me too. +CHRIS: [laughs] That's my recording voice. +STEPH: [laughs] +CHRIS: That's how you can tell. +STEPH: I just like how it sounds suspicious where we're like; I'm now recording, so be careful. [laughs] +CHRIS: This is now on the record. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hello. Happy, happy Friday. Oh, I have something that I'm excited or intrigued about. I don't know. Okay, I'm hyping it up. [laughs] But I'm realizing I'm also very skeptical of it. +CHRIS: This is the best sales pitch I've ever heard. I'm so excited to hear what this is. [laughs] +STEPH: I am trying a new email client; it is the Newton email client. And I so want to love my inbox. I want to check on it. I want to help it grow. Okay, that's the opposite. I want to help get through all the emails that come through, but I just want to love it. I want it to be a good space that I want to go to. And I just hate email so much. And it always feels like this chore that it's really hard for me to bring myself to do, but yet it's really important because a lot of good things come through email. +So this is my rambly way of saying I'm trying the Newton email client because I saw on Twitter from Andrew Mason, who has very similar feelings that I do about email, where we are just not fans of it. And we rarely check it and have declared email bankruptcy at several points in our life. And he's also one of the co-hosts for Remote Ruby. But I saw on Twitter that Andrew was talking about the Newton email client and how it actually made him feel that he enjoyed writing and looking through his inbox. And I was like, yeah, that's the sales pitch I need. So I'm giving it a go. It's been only a couple of days. +But one of the nice things I have noticed about it is it's very focused, and there's not much noise, and it actually feels like very minimal design where if you open up like a new email, so you're opening up a new draft, there's no much noise. You get to just focus, almost like you're writing a little blog post or journal post or something. It takes away a lot of the noise. +While in Gmail, it's going to open up a small window in the right, but then you still have the rest of the noise that feels distracting. So I like that very intentional like, hey, you're just doing one thing, just focus on this. And then also you can integrate other email accounts as well. So you can have one-stop shopping versus Gmail, then you have to click around and sign in, sign out, or visit different email accounts. So we'll see if it helps improve my email life, but that's something new I'm trying. +CHRIS: Very interesting. So you're fully on inbox zero life now. That's what I'm hearing. [laughs] +STEPH: Ah, hmm. I don't want to lie to you. [laughs] We have a good friendship. I won't start lying now. +CHRIS: I appreciate that. So you're halfway to inbox zero. You're not even entertaining that idea, right? This is just you want a better tool to do email. +STEPH: Exactly. Inbox zero is not incredibly important to me. But I do want to make sure that I know that I've seen everything important, and I know where to find things. And then making sure that I am responding to people in a timely manner. Those are more my goals. Inbox zero, if that supports it, then great, I'll work on it. But not necessarily that has to be the goal that I reach. +CHRIS: Gotcha. I'm not seeing Newton, but I'm intrigued. Particularly on mobile, I have the Gmail mobile app, and that has unified inbox, which I appreciate. But Gmail on the web does not, and I find that odd. And I've never found a mail app that I enjoy because I want some of the features of Gmail. I want to do Gmail snoozing because I still want that to be consistent and whatnot. And to be honest, that's the main way that I get to inbox zero. I just say future me will have more time. +I actually tweeted recently. It was a screenshot from my Saturday inbox, which I think was 15 emails that I'd snoozed from the previous week into Saturday morning. Because I'm like, Saturday morning me will have so much time, and energy, and coffee, and it'll be great. And then it became Saturday morning and, ooph, what a view. +STEPH: [laughs] Yeah, your snoozing tip has been life-changing for me because that's not something that I was using all that much. The two things are, one, schedule send so that way if I do have a sudden burst of energy and I want to write an email, but I want to make sure that person doesn't get notified until a decent time. Being able to schedule an email and snoozing is amazing. +I think Newton and Gmail have pretty much similar features. I was trying to do a comparison. I was like, is there something really snazzy that Newton does that Gmail doesn't already give me? But it looks like they all do about the same, having those important features like snoozing and then also being able to schedule emails. +So I think it really just comes down to a lot of the UI, and there may be some other stuff I'm missing since I'm new to it. But that's the main appeal for me right now is the focus and the look and feel of it. So then maybe I will find looking through my inbox a more zenful experience, I think is how I saw them advertise it. +CHRIS: Well, I definitely look forward to hearing more as you explore this space. I will say looping back to what you were just commenting on around deferred send, which is definitely something that I use, but you described one of the reasons that I use it. So the idea of wanting to be respectful of someone else and not send them an email on Sunday night because you happen to be working at that point. But you don't want to put that on their plate. I would say equal amounts; that's the reason I use scheduled send. +And then the other reason that I use scheduled send is please, for the love of God, I do not want another email back in my inbox. So I will reply to something such that now I'm done with that, but I will schedule send it for the next morning. Because tomorrow morning me can deal with whatever reply this generates. +There's some adage; I don't know if it's an adage, but the idea that every email that you send generates 1.1 emails in reply. So emails just have this weird way of multiplying. And so if you send one out there, you're probably going to get something back. And so often, if I'm trying to clear my inbox, I don't want to get another email in my inbox at that moment. So I will not actually send the reply. I will schedule it for a future time because I do not want to hear. I want no new inputs at this point. I'm trying to process them. So that's part of why I use deferred send. +STEPH: I had not thought of that, that yeah, that if you schedule it for tomorrow, you've really gamified this inbox zero because you're like, yeah, if you send something, then you might get an email back. But you're like, if I wait till tomorrow to send it, then I'm less likely to have another email, and then I've hit inbox zero, and I'm set for the day. I like it. It seems helpful. +CHRIS: Yeah, inbox zero sounds like an altruistic thing, but it is not. It's a way to force myself to have to make decisions, which is something that I want to get better at broadly. And that's part of the role that I have now. A lot of what I'm interested in exploring is just getting better at making decisions, being more decisive, being more action-oriented. Because I just have a tendency to make many, many spreadsheets and think about stuff for a while and take a long time to make a decision. But I don't get to do that, particularly now. +But broadly in life, that's probably not the right mode to be in. So inbox zero is another thing that forces me to deal with things rather than just be like, I don't know, I don't know, I don't know, and keep looking at the same thing over and over. So just more thoughts about inbox zero, but now I'll stop talking about it. +STEPH: I do like that, though. And you're totally right; it can be a very helpful constraint. And I think that's sometimes why I fight it because then I haven't curated my inbox enough that then when I go to it, there are so many interesting things that then I feel a little bit overwhelmed where I'm like, oh well, I want to read this, and I will look at that. And this seems interesting, and maybe I should be a part of this. +It feels like one of those like; you could be a part of these ten amazing things. Do you want to be a part of all of them? And given a person that it's hard for me to say no to or recognize that no, I'm just going to not do anything with this, that is hard for me and would be a good skill for me to hone in on and practice and make quick decisions and be very realistic. +Because I used to be subscribed to more newsletters, and then I finally had to stop subscribing to them because it had that same effect on me of that FOMO of like, I'm missing out on this great article or this great video. And I've become more honest with the fact that my Saturday morning self isn't going to want to read through a bunch of newsletters and videos about coding, that I'm going to want less screen time. So that is a really good constraint and helpful skill to cultivate for sure. +CHRIS: All right, I said it was done, but one more thing. I feel like I've mentioned this in the past, but Feedbin is the thing that I use for RSS. I still believe in RSS as a technology. But everyone's moved to newsletters these days that go via email. Feedbin gives you an email address that you can use to subscribe to newsletters, and then they do the job of converting that into an RSS feed. +So for me, I take something that was now a push into my inbox, and now I can pull whatever I want from that RSS feed. And on Saturday morning, if I'm feeling like, with a cup of coffee, I can enjoy some newsletter about all the new hot tips in Svelte land or whatever it is or not. But it's not clogging up my inbox. And with that, I think I'm actually done talking about inbox zero. [laughter] +STEPH: Yeah, that's a nice separation. We could keep going. I have full faith in us that we could keep going about this. But I'll share a slightly different update. I've been implementing a suggestion that you provided a couple of weeks back where we were talking about Rspec's selective test running and how some applications will speed up their test. +If you change one part of the codebase, then perhaps you only need to test this chunk of test. You don't actually need to run the full test suite. And that is complicated and seems hard to get right, and really requires understanding boundaries. But then also knowing Ruby, then how do you really identify? Do you really know where this method is being called and can identify all the tests that need to be run? +I think we'd mentioned before there's a really good article from Shopify where they have worked on this and created an open-source project called Packwerk. So we can link to that article in the show notes. But more specifically, you suggested, well, what if you just change a test file? That seems very low stakes and also has the benefit of creating a reward where if someone does see something that they can improve in a test, then that's a very quick feedback. Let me just get this change. It's going to be fast on CI. I can merge it right away and also saves time on CI. +So I've been working on implementing that change. And it's one of those the actual change is easy, like checking with Git to say, "Hey, what files have changed?" Does it have an _spec.rb at the end of it? Great. Does it not? Okay, we've changed some application files. So let's run the full test suite. That part's easy. Getting it integrated into the build system has been more complicated just because this team has done a lot of work around trying to improve and speed up their test. And there's a fair amount of complexity that's there. +So then figuring out a way to stitch my change into all the different build processes that take place has proven to be more difficult. But it's also been insightful just because it has now helped me really understand and forced me to learn, okay, what are all the different steps? What's important for each one? Where can I cut off the rest of the running of the test and instead just focus on running these tests? So in some ways, it's been challenging, but then on the positive side, it's been like, okay, well, this has taught me a lot about the existing system. +So at this moment, it is still a work in progress. I'll have more updates in the future. I am excited to see the rewards. I've gotten to the point where I just have a proof of concept where I've gotten pushed up, but it's not production-ready. But it's at least I just wanted the feedback that I'm in the right spot and that we're running just the right test. +And so far, it does seem like it's going to be a nice win, even if it's maybe not used by everybody because it's probably rare that someone is altering just a spec file. But for people who are looking specifically to improve the CI build time and working on tests, it will be very helpful to them. So yeah, I'm sure I'll have some more updates in the future. What's going on in your world? +CHRIS: Well, I definitely look forward to hearing more about that. However, we can improve CI speed; I'm super interested in that as a topic. +Mid-Roll Ad +Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. +So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. +That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. +So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. +CHRIS: Well, similar to your email adventures, I continue on my search for the perfect to-do list. It's not going great, if we're being honest. [laughs] To be clear, because I've mentioned this on a few different episodes, I'm not spending much time on this at all, some but not much. And so it's not really moving. +But there are two interesting things. I took a look at TickTick, which was one that I mentioned in the past, a tool for this. It seems good. It seems like an intersection between things, which is what I'm currently using, Todoist, which I've used in the past, and some other tools. So I think I'll probably explore that a little more. It seems like a good option. +Decidedly, the most interesting thing is a tool called Sunsama, which is different in some interesting ways but very interesting. So one thing to note about it is it's $20 a month, which is a lot of money for one of these tools because most of them are like, "We're $20 forever, and then it's free." And it's a surprisingly low-cost space. And so, they're definitely positioning themselves as a more costly entry. I would be fine with paying $20 a month for a tool if it really is like, no, cool, I feel great. I'm more productive. I'm happier when I'm not working, et cetera. +But what's interesting is they seem to do a let's reach out to all the places that tasks can live for you. So there's your inbox for email. There's your Trello board that you've got. There are GitHub issues. There's Slack. There are all these different sources of potential tasks. And they do a really good job of integrating with those other tools and then allowing you to pull that list into Sunsama and then make each day you have a list. And those items can be like, this is a reference to a Trello card on that board. This is a reference to a Slack conversation over there. +So I'm super intrigued by it. It's also got a very intentional plan your day mode, which I like because that's one of the things that I'm really looking for is at the end of the day, I want to clean everything up, make sense of all of the open items, and then reprioritize and set up for the next morning so that I can just hit the ground running. That said, I tried it, and it just didn't quite click. And I think it's one of those it takes some effort to understand how to use it. So I'm not sure that I'm going to get there. +But it is super interesting because that idea of our work lives in all of these different tools these days feels very true. And so, something that is trying to act as a hub between them to integrate them is very interesting to me. Again, I haven't really gotten anywhere on this. I'm kind of just reading blog posts, as it were. So I'll report back if that changes, but -- +STEPH: The search continues for the right to-do app. Yeah, that seems interesting. I don't know why I'm feeling hesitant towards it. I'm one of those individuals...you're right; there are so many tools. And the fact that they integrate with a lot of them seems really nice. +I'm at the point where I just grab links to stuff, and I'm like, hey, if this is my priority, I grab a link to a Trello ticket, and then I just copy that into my to-do. I guess I like that bit of work over having to integrate with a bunch of different platforms. Because once you get used to integrating...I don't know; I'm just rambling. But I wish you the best on this journey. I'm excited to hear more. [laughter] +CHRIS: Thank you. I will certainly report back. But yeah, nothing pointed to share at this point. But I do have something pointed to share on the hiring front, which is that we have hired some folks. +STEPH: Hooray! +CHRIS: Yay. So this has been a fun saga across a couple of different episodes. And in my mind, it feels like this much longer, more drawn out thing, but it's; actually, I think, come together relatively quickly, all things considering. We've got someone who's starting in a little over a week's time, and then someone else who's starting in, I think, two or three weeks after that. So that'll be great. Hopefully, we can transition into onboarding, which is a different whole approach. +But hiring as a distinct activity can scale back significantly. As we discussed last week, I want to be in the always be hiring mindset but in the more passive mode of having conversations with folks, staying connected. And if a great candidate comes along and it's the right time, then bring them on the team but not actually actively reaching out and all that sort of stuff, which will be great. Because it turns out that takes a lot of time and also a lot of energy for me. Having those first conversations, going into it very intentionally trying to communicate about something, and there's a tone of salesmanship to it that is not my natural resting state. +So I come away from each conversation being like, that was fun, but also, I'm drained now. Why am I so drained? So not having that be a thing that is filling up my calendar is great. And also super excited with the folks that'll be joining the team and to be able to now grow our little team and define the culture and the shape of the groups that we will be collectively. I'm excited for that work and what we can build together. So yeah, it's an exciting time. +STEPH: That's awesome. Congratulations. Because yeah, everything you're saying sounds like it's just been a lot of work. So that's very exciting. There's someone that I was chatting with earlier today where they were talking about the value and the importance of understanding what your natural skills are and the things that bring you energy. And so you're mentioning there are certain activities that you enjoy them, but they're also draining because perhaps they are on the outer boundary of what you might define as your own natural skill or the things that get you really excited. And I found that all very interesting. +It had me thinking about that today about where are the natural areas that I find that I get energy that are easier for me? And then making sure that I'm trying to prioritize my day so that I am more focused on the activities that just align with who I am and also that I'm engaged with and then also looking for ways to stretch. But they made the point that if you are always in a space where you are not using your natural talents, and you're always having to stretch, then that can be what leads to burnout. Versus if you're in that sweet spot, that zone of where you are using your natural skills, but then also stretching a bit. +And I think there are some assessments and things like that that will help you then determine what are my natural skills, and what do I like to do with my time? I just like that style of thinking and recognizing, like you said, like, hey, I did a thing. It was fun, but I'm drained. So now I know that this is something that requires more effort for me. Like hiring, that's one for me. +I really like interviewing. I like talking with people, but I'm so nervous for them because I know interviews suck. [laughs] I just have so much empathy for them where I'm like, this is going to be a hard day. We're going to make it as pleasant and positive as possible, but I know this is a hard day. And so I feel like I'm in it with them. And so afterwards, I feel that same relief of like whoo, okay, interview day is over. +CHRIS: I don't know that I quite achieve the same level that you do but in no way am I surprised that that is your experience of hiring. And just to name it, you're a wonderful human being that feels for the people on the other side of the hiring table. Like, oh my God, this must be so stressful for you. It's so kind of you to be in that space with folks. +But coming back to what you were saying a moment ago, that idea of, like, understanding where your strengths are and where they're areas that you're not quite as strong. And I think critically, the question of like which are the ones where I want to just kind of say no to? I'm like, that's fine. This is not going to be a competency of mine. And I'm going to just avoid that or find other people to work with that balance that out. So for me, sales is the thing that I don't think that's ever going to be my bag. I don't think I'm ever going to move in that direction, and that's totally fine. +Whereas decisiveness, which I was describing, is like, I think that's the thing I could get better at. That is one that I don't want to sleep on that. I don't want to say, "That'll be fine. I'll just have other people make the decision." No, I need to get better at making decisions, making decisions with less information or more rapidly, having a bias towards action. All those things I think will be deeply beneficial. So I'm trying to really lean into that. Whereas yeah, again, the sales stuff I'm like, yeah, and there's plenty of examples of this otherwise. +But I've also been coding a bit more this week, which has been lovely because the hiring stuff has ramped down. And that has freed me up amongst some other stuff that's been going on. And you know, I like to code, it turns out. It's fun. I just clack about on my cherry brown keys, and it's great. +STEPH: Do you remember when we first got introduced to mechanical keyboards, and we had co-ownership of one of the keyboards? And we literally had days of where it was like your turn to use the keyboard. And then it was my turn to use the keyboard. How long did we keep that up before we were finally like, we should just buy our own keyboards? +CHRIS: It was a while because we were working with a colleague who was trying out a Kinesis, I want to say, one of the split little bowl of keys. But yeah, we had a shared custody over a keyboard, and it was fantastic. I remember that very fondly. +STEPH: The days that it was my keyboard, I would go to the office and be like, oh, today is my day at the keyboard. This is great. This is going to be such a wonderful day. [laughs] And now I'm just spoiled. +CHRIS: It went on for a while, though. And this was something where we both obviously enjoy this keyboard. Why don't we just buy one of these keyboards? We totally could have done that. And yet, for some reason, both of us were like, no, but what if...I got to think about this. Again, decisiveness. [laughs] We come back to this topic of well; I had to really think about it. And then somebody got the 92-Key test or whatever it was in the office. And so I just went over and poked every one of those for a while. +STEPH: Exactly. It was option overload where we're like, well, okay, we're going to buy one, and then you open it up and search, and you're like, oh, you want options? We have options. Do you know about the blues, and the browns, and the colors, and these different options? Like, I don't know any of this language that you're talking about. I just want to clackety-clack. So yeah, it took time. We had to do our research. +CHRIS: And then I ended up on basic browns. So here we are. Let's see, popping back up the stack a couple of levels, hiring that went on for a while. Now it is less going on. Although to be clear, like I said, always be hiring. So if anyone out there in the world is hearing what I'm talking about with Sagewell or seeing any of the stuff that I'm putting on Twitter, which isn't much, I occasionally just post screenshots of my commit messages, which recently included better snakes as a commit message. [laughs] I have to dig into that or not. But we were just doing some snake case to camel case conversion. But the commit message was better snake, so here we are. +Anyway, if any of that sounds interesting, please do reach out. But I'm excited to transition back to focusing more on the work. On that note, actually, I'm going to call it interesting things that is happening right now organizationally is; we are working with an external security firm to help with some...they helped us out with a penetration test when we needed that. And then they have stayed on retainer and are helping with various different configurations, taking our AWS S3 buckets and making sure those are nice and secure, and all that kind of stuff. +But we've recently started to focus more on organizational security, specifically a bowl of acronyms. We've got SSO for single sign-on, MDM for something device management. I don't know what that first M is. I probably should learn it, but it's fine. That's why I've got help on this is I think they know what the acronym stands for. But so we're working on each of those. +And on the one hand, they're probably going to be kind of annoying, like having to go through the single sign-on. It's a whole thing, and it's harder to sign into stuff sometimes. I mean, ideally, it's actually easier. But in my experience, it adds some friction at some points. And then MDM means that there's now some profile manager on the computer. So I can say like, "Every computer must have full disk encryption or else you can't use it. And we need a passcode, and it must be this long and those sorts of things." So it's organizational controls that I think are good for us having a robust security setup throughout the organization. +But yeah, they're the sort of things that I think historically, I probably would have, as someone working in an organization, had been like, do we have to? Do we need these things? Couldn't I just do whatever? But now there's something about it that I really like. I'm trying to name it in my head, but I'm kind of like, I don't know. This feels like growing up as an organization. +And there's always weird corollary that I've been thinking about with the Rails app that we've been building, intimately familiar with just everything that's going into it. And I know the vast majority of lines of code. I haven't written them all, but I've had an eye on all of the different features that we're building in. +And it's hard to get out of that headspace where it feels like a bunch of pieces. It doesn't feel like a hole to me, even though it definitely is. But when does a bunch of boards that you nail together become a boat? To make a really weird analogy because that's what I do; it's a hobby of mine. But when does that transition happen? At some point, certainly. But that's harder for me to see on the code side. +And organizationally, somehow getting these things in place feels like the organization sort of an inflection point for us, a growth point, which is I'm really excited about it. Even though they're probably going to mean a ton of annoying nuisance work for me because I'm the person in charge of making sure it all gets rolled out. And anytime anyone locks themselves out of an account, I have to help with that. And so it's probably just putting a bunch of annoying work on my plate. And yet, I don't know; I'm kind of excited about it. +STEPH: I feel like that shows our roots in terms of how we approach projects that we work on where you mentioned do we need this? Do we need this yet? Because I feel that we're constantly as developers and consultants just we're trying to advise on the more simplified do we need this? Is this the right thing to spend the money on? How do we know? What are the metrics? What does success look like? And all those questions. +So I feel like the way you just phrased all of that just really shows that sort of mentality that you grew up with in terms of checking in, and yeah, it's cool. Like you said, you're at a growth point where then it's like, yes, we are at this point that I've asked myself all those questions, and we're here. This feels like the right next step. +CHRIS: I like the way you described it as that you grew up with, my formative growing years at thoughtbot. +Mid-roll Ad +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: Well, switching gears just a bit, we have a listener question for today, and this one comes from Stephanie. So not me, another Stephanie in the world. Hello, other Stephanie out there in the world. And they wrote in, "Hi, Steph and Chris, fellow software consultant here. And I'm wondering if you'd consider talking about how to craft a project estimate for a client on the pod. It's such an important aspect of consulting." Amen. I added the amen. +"And I feel like I'm very much impacted as a project team member when the estimate isn't accurate." Double amen. So true. [laughs] "Would appreciate any and all thoughts, especially since it might be part of my job in the future. Thanks." I just realized I put us in consultant church by adding all those amens, but here we are. [laughs] +CHRIS: I'm glad you clarified that they were additions by you and not part of the original question coming in. +STEPH: Sure. I don't want to speak on behalf of Stephanie. So I have some thoughts on the matter. I think there are a couple of different ways that we can talk about this particular question because I think there are different formats as to when you're estimating and who you're providing the estimate for. But I'm going to pause because I'd love to see what you think. How do you go about approaching crafting an estimate? +CHRIS: Sure. I'm happy to share some thoughts. And for a bit of context, this question came in to us, frankly, many months ago, but I did send an initial reply to Stephanie because I know that sometimes we take a little bit of time to get back to folks. So if ever you do send in a question, know that one of us will probably respond via email earlier, and then eventually, will make it on the show. And again, just to say, we do so appreciate when folks send in these questions. It's an interesting way to shape the conversation and a way to get topics that you're more interested in into the fold here. +But so the two main ideas that I shared in my initial reply were, first, is an estimate really necessary? I think that's a critical question because an estimate implies that this thing is knowable. And as many of us, probably all of us, have found out at some point in our lives as software developers, it's really hard to do software estimation, like wildly difficult. And not just the thing that we'll eventually get better at it, which you do, but there's just some chaos. There's some noise in this work that we do that makes it so, so difficult to get it right. +So pretty much always, I will ask, like, do we need to estimate here? What if, instead, we were to flip the whole question on its head and say, let's set a deadline. Let's say two months from now that's our deadline. And let's ruthlessly reprioritize every single week to make sure that we're building something that's meaningful, and we're getting there. +And obviously, we have to have some general idea of what we're doing. Is two months a meaningful amount of time to build a rocket to go to Mars? Probably not. But is it enough time to build an app that can allow users to sign in and manage a simple list of items? Yeah, we can definitely do that, and we can probably add a bunch of more features. +The other thing that I think is worth highlighting is there's a bunch of stuff that is table stakes and very easy to do. But I would, whenever doing estimation, emphasize unknowns. So, where are the external integrations with other systems? Where are the dependencies that rely on other folks to provide some inputs into this process that we can't be certain where there'll be? +In my experience, the places where estimates go awry are often these little intersection points that you're like, well, this will probably take a day, maybe two. And it turns out; actually, this can somehow balloon into a month. That's not a thing that feels comfortable saying in an estimation process, but it is definitely real. I've seen it happen so many times. +And so it's those unknowns. It's those little bits that I would emphasize as part of the process if you do need to do an estimate and say, all right, here's the boring stuff. I think we can do that pretty easily. But this part, I don't know, it could be a week, could be three months. And frame it in that way that there is this ambiguity there. Because if someone's asking you for an estimate and they're looking for like it is seven days and two hours exactly, it's like, well, that's not realistic. That's not how this thing works. Unfortunately, I wish it did. +But pushing back and changing the conversation is the thing that I have found valuable. I think there's some other really interesting stuff in here around the team dynamics that Stephanie is talking about. But I want to send this over to other Stephanie to see your thoughts because I'm super interested to hear what you have to say as well. +STEPH: Oh, I like how you hinted at the team dynamics. Yeah, that could be a fun one to circle back to. So I love how you called out highlighting the unknowns. There are a couple of ways that this comes to mind for me. So there's the idea of the weekly or the bi-weekly estimates that we make as developers and designers. So let's say we as a team are getting together to focus on a chunk of work and decide what we can and can't get through. And that feels one of those the more you get to practice it more frequently; you get to ask a bunch of questions. And that feels like a good rehearsal and exercise of how to go through estimates. +And I know you and I have pretty similar strong feelings around how those estimates are then treated by the company. They should really just be used for the team to talk through the complexities in the work to be done versus used to communicate outwardly as to this is when it's definitely going to ship. So there's that more immediate practice of providing estimates. And then there's the idea for more of a consultancy or a company, and someone is coming to you, so thoughtbot being a great example of then how do we work with teams that are looking to come to us and gain an estimate for getting a certain feature implemented? +So actually, I went to the source on this one. I went to Josh Clayton, who does a lot of the conversations for the Boost team when it comes to talking with clients and about the potential work that they would like to be done. And mostly our work is often teams will hire us. They have specific goals in mind, but they're really looking to hire ongoing development and services. So they really want to add to their existing staff. And then it's going to be an ongoing relationship versus a hey, we need you to quote us for how long it's going to take to implement this particular feature. +And on that note, we don't do fixed-bid work. So we don't say it's X dollars for specific features. But on the realistic side, customers are often capped by a budget. And so that estimate is very important to them because it could be a difference between it's a go versus a no go. So if you have larger companies that are like, "Yep, we want to engage with thoughtbot. We really just want additional development power and design services," that's great. +For those that are smaller, it could be an individual product owner, and they need to say, "I really want this feature, but I only have this much money. And frankly, if I can't ship it by this time, I'm not going to do it because it's not worth the investment to my company." And then, in those cases, those are the ones that we're going to spend more time with them to talk about what does the fallback plan look like? And what's our opportunity for simplifying the features? +And Josh, in particular, referenced this as systems thinking. So he will go through the idea of drawing out the set of steps, understanding the complexity of the different screens. So what are the validations? What are the external dependencies? What is owned by us and what isn't? What is the likelihood that we're going to get permission to simplify or remove complexity? And even then, when we start to provide some estimates, it's going to be in weeks. It's not in hours; it's not in days. It's going to be in a slightly larger time frame. +And then we're also going to spend more time in the discovery phase to say, okay, well, we know you need to fix this particular issue, or you need to integrate with this particular service. So we're going to need to ask a lot more questions about your codebase. What problems have you already run into? Have you tried to do this before? Do we have experience doing this? Is this something that we can lean on and ask someone in the team? And, say, how long do you think it would take for us to work on this? +And that's knowledge that isn't privy to everybody. It depends on where you're at in your career as to like, oh yeah, I've done this like five times before, and I know exactly how this stuff can fall apart. I know where the complexity lies. So I think that's why estimation is so difficult is just because it does often pull from that existing experience. And so, if you don't have that experience for a particular set of work, of course, it's going to be hard to estimate because you just don't know. So that was a very broad scope of as day-to-day developer and designers; I feel like we're constantly getting practice and estimating and communicating the progress of our work. +And then on the larger scope of if you are a consultant who's then looking to give estimates to clients, then understanding what other need can you sell them? Just ongoing development services. Or, if they are a smaller team and very focused, then what legwork can you do ahead of time to de-risk the project? And then understand how much control you're going to have to be able to simplify as you learn more as you go. Because you're going to, you're going to uncover some things, and you're going to learn some things. And what's that collaboration going to look like? +I do have one more concrete example I can provide around some of the smaller projects that we take on. So when we are helping someone that's, say, getting a new product out to market, then we do have a more deliberate three, four-phase approach where we first focus on discovery, and ideation, and validation. And then, we move on to iteration and then launching. +And I really like how you said about providing a deadline because then that helps us scope aggressively as to what is the minimum thing that we can get out into the world that will be valuable? And then there's usually some post-launch support as well. But that's often how we will structure those smaller, more specific engagements. +CHRIS: I think one of the critical things that you highlighted in there is that thoughtbot doesn't do fixed-bid work. So we're going to do these 20 features, and it's going to take four months. thoughtbot does not do that, and frankly, that's a privilege to be able to take that position and say, "No, no, no," we're not going to work that way. But it is, I think, a trade-off. It's not just something that thoughtbot does to be like, listen, that doesn't sound fun. So I'm not going to do that. It's a trade-off. +Not doing that comes in concert with saying, "But weekly, we're going to talk about the work that we have done and the work that remains and constantly, ruthlessly, reprioritize and re-decide what we're doing." And it's that engagement, the idea that you can have a body of work, look at it and say, "Yeah, that'll take about six months," and then go away for six months, and then come back with the finished software. +Our strong belief is that that's not the way good software gets built. But instead, it's a very engaged team where the product owner and the development team are in constant communication about each of the features that are being developed. And then again, ideally, on a weekly cadence, coming up for air and saying, "How are we doing? Are we moving in the right direction? Are we getting towards the goals? If not, do we need to simplify? Do we need to change things?" +And similarly, as I mentioned deadlines, I feel like deadlines is probably a word that many people think of as very bad because deadlines often come with also a fixed scope, but that can't happen. That's two constraints, and you can't have them fighting that way. But a deadline can be super useful as a way to say we're going to put something out there in the future and say we're heading towards that moment. And let's, again, cut scope. Let's change what we're building, et cetera. +But critically, not say, "We got a deadline and a fixed scope. We're going to do that." And so it's, again, just ways to gently shift the conversation around and say, what if we were to look at this from a different angle? Because just having a pile of work and saying, "That'll take six months," I've never seen that play out. +STEPH: Yeah, to me, deadline is a bad word when the deadline is set by a team that's not doing the work. So if you have leadership or if you have someone else that is setting this deadline and then just passing that down to someone else to then fulfill, regardless of the feedback or how things are going, then yeah, then it can be a nasty thing, which I think is a little bit of in that question that you picked up on that you highlighted where there could be some interesting team dynamics that Stephanie called out, highlighting that I'm very much impacted as a project team member when the estimate isn't accurate. +And I'm making some assumptions here because I don't actually know the exact situation that Stephanie is experiencing. But it sounds like someone else externally is setting these team estimates. And so then you're handed this deadline, and then stuff goes wrong, but you're still pressured to meet this deadline. And I've certainly been part of projects that are like that. +And then that is one of the number one things that then often comes up in a retro or like, we don't have control over these deadlines, or we don't know why these deadlines are being set. And then people are working extra hours and working nights and weekends to then meet this arbitrary deadline that none of us signed up for, and that's just not fair to treat deadlines in that way. +So full-heartedly agree that deadlines can be a very positive thing, but they need to be set by the people doing the work. And then there has to be discussions and updates about how is this going? Do we have control to simplify this? We thought we could do this with this particular external provider. It turns out that that's a nightmare. Is there another provider we can go with? Can we ship this incrementally? Like some features, you can't. They may have to go out wholesale. But is there a small chunk of this that we can deliver that is then a success that leadership and others can brag about? And then we can keep working on the rest of it. +So it's always identifying what are the smallest wins, and how do we get there and getting buy-in from the team? Going back to something that you said earlier around, it is a privilege, where so as thoughtbot, we don't do fixed-bid work. And that is a nice thing for us to be able to focus on. But for people who do need to do fixed bid work and are relying on that, I think that often requires more legwork. And maybe that becomes part of your estimate. I'm just making up how I might approach this if I were trying to do fixed bid work. +But there's a discovery phase that's very important. So maybe the first part of your estimate is I need to really understand the feature and see the different screens and know what materials we do or don't have. What does the codebase look like? Do I feel like this is a codebase that I can work quickly in? And is it going to be hindersome for me? But answering a lot of those questions to then help me paint a picture of, like, okay, this is a feature that I've implemented before, so I feel pretty confident that I could do this in a month. +And then also communicating that this is my estimate but just know it's an estimate. And I will continue to update you each day as to how things are going or each week as to how things are going, and things may adjust. And we can always talk about ways about simplifying this. But I think that's how I would go about it is; frankly, it's going to require more legwork for me to feel more confident as to then telling someone as to how long I think the work will take. +I think that's a nice, broad scope of the different types of estimate work to be done with the general idea of if you can avoid estimates and go for more frequent updates, then that's wonderful. But then, if you are forced into a corner where you need to provide an update, then just do as much research and honesty as possible and then still include the frequent updates. +CHRIS: Yeah, that I think summarizes it quite well. +STEPH: As a side note, it's been a lot of fun to feel like I'm referring to myself as a third person as Stephanie is working through this problem. So that's been novel. But yeah, thank you, Stephanie, for the great question. I hope that was helpful. On that note, Shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeee!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph joins Chris in trying new things! For her, it's a new email client – the Newton email client – because she really wants to love her inbox. She also talks about implementing a suggestion from Chris on improving CI speed.

+ +

Chris continues his search for the perfect to-do list app. (It's not going great.) But he has made hiring progress and is excited to move on to the next step: onboarding.

+ +

Together they answer a listener question who asked for advice on crafting project estimates for clients.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: I am now recording.

+ +

STEPH: Me too.

+ +

CHRIS: [laughs] That's my recording voice.

+ +

STEPH: [laughs]

+ +

CHRIS: That's how you can tell.

+ +

STEPH: I just like how it sounds suspicious where we're like; I'm now recording, so be careful. [laughs]

+ +

CHRIS: This is now on the record.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hello. Happy, happy Friday. Oh, I have something that I'm excited or intrigued about. I don't know. Okay, I'm hyping it up. [laughs] But I'm realizing I'm also very skeptical of it.

+ +

CHRIS: This is the best sales pitch I've ever heard. I'm so excited to hear what this is. [laughs]

+ +

STEPH: I am trying a new email client; it is the Newton email client. And I so want to love my inbox. I want to check on it. I want to help it grow. Okay, that's the opposite. I want to help get through all the emails that come through, but I just want to love it. I want it to be a good space that I want to go to. And I just hate email so much. And it always feels like this chore that it's really hard for me to bring myself to do, but yet it's really important because a lot of good things come through email.

+ +

So this is my rambly way of saying I'm trying the Newton email client because I saw on Twitter from Andrew Mason, who has very similar feelings that I do about email, where we are just not fans of it. And we rarely check it and have declared email bankruptcy at several points in our life. And he's also one of the co-hosts for Remote Ruby. But I saw on Twitter that Andrew was talking about the Newton email client and how it actually made him feel that he enjoyed writing and looking through his inbox. And I was like, yeah, that's the sales pitch I need. So I'm giving it a go. It's been only a couple of days.

+ +

But one of the nice things I have noticed about it is it's very focused, and there's not much noise, and it actually feels like very minimal design where if you open up like a new email, so you're opening up a new draft, there's no much noise. You get to just focus, almost like you're writing a little blog post or journal post or something. It takes away a lot of the noise.

+ +

While in Gmail, it's going to open up a small window in the right, but then you still have the rest of the noise that feels distracting. So I like that very intentional like, hey, you're just doing one thing, just focus on this. And then also you can integrate other email accounts as well. So you can have one-stop shopping versus Gmail, then you have to click around and sign in, sign out, or visit different email accounts. So we'll see if it helps improve my email life, but that's something new I'm trying.

+ +

CHRIS: Very interesting. So you're fully on inbox zero life now. That's what I'm hearing. [laughs]

+ +

STEPH: Ah, hmm. I don't want to lie to you. [laughs] We have a good friendship. I won't start lying now.

+ +

CHRIS: I appreciate that. So you're halfway to inbox zero. You're not even entertaining that idea, right? This is just you want a better tool to do email.

+ +

STEPH: Exactly. Inbox zero is not incredibly important to me. But I do want to make sure that I know that I've seen everything important, and I know where to find things. And then making sure that I am responding to people in a timely manner. Those are more my goals. Inbox zero, if that supports it, then great, I'll work on it. But not necessarily that has to be the goal that I reach.

+ +

CHRIS: Gotcha. I'm not seeing Newton, but I'm intrigued. Particularly on mobile, I have the Gmail mobile app, and that has unified inbox, which I appreciate. But Gmail on the web does not, and I find that odd. And I've never found a mail app that I enjoy because I want some of the features of Gmail. I want to do Gmail snoozing because I still want that to be consistent and whatnot. And to be honest, that's the main way that I get to inbox zero. I just say future me will have more time.

+ +

I actually tweeted recently. It was a screenshot from my Saturday inbox, which I think was 15 emails that I'd snoozed from the previous week into Saturday morning. Because I'm like, Saturday morning me will have so much time, and energy, and coffee, and it'll be great. And then it became Saturday morning and, ooph, what a view.

+ +

STEPH: [laughs] Yeah, your snoozing tip has been life-changing for me because that's not something that I was using all that much. The two things are, one, schedule send so that way if I do have a sudden burst of energy and I want to write an email, but I want to make sure that person doesn't get notified until a decent time. Being able to schedule an email and snoozing is amazing.

+ +

I think Newton and Gmail have pretty much similar features. I was trying to do a comparison. I was like, is there something really snazzy that Newton does that Gmail doesn't already give me? But it looks like they all do about the same, having those important features like snoozing and then also being able to schedule emails.

+ +

So I think it really just comes down to a lot of the UI, and there may be some other stuff I'm missing since I'm new to it. But that's the main appeal for me right now is the focus and the look and feel of it. So then maybe I will find looking through my inbox a more zenful experience, I think is how I saw them advertise it.

+ +

CHRIS: Well, I definitely look forward to hearing more as you explore this space. I will say looping back to what you were just commenting on around deferred send, which is definitely something that I use, but you described one of the reasons that I use it. So the idea of wanting to be respectful of someone else and not send them an email on Sunday night because you happen to be working at that point. But you don't want to put that on their plate. I would say equal amounts; that's the reason I use scheduled send.

+ +

And then the other reason that I use scheduled send is please, for the love of God, I do not want another email back in my inbox. So I will reply to something such that now I'm done with that, but I will schedule send it for the next morning. Because tomorrow morning me can deal with whatever reply this generates.

+ +

There's some adage; I don't know if it's an adage, but the idea that every email that you send generates 1.1 emails in reply. So emails just have this weird way of multiplying. And so if you send one out there, you're probably going to get something back. And so often, if I'm trying to clear my inbox, I don't want to get another email in my inbox at that moment. So I will not actually send the reply. I will schedule it for a future time because I do not want to hear. I want no new inputs at this point. I'm trying to process them. So that's part of why I use deferred send.

+ +

STEPH: I had not thought of that, that yeah, that if you schedule it for tomorrow, you've really gamified this inbox zero because you're like, yeah, if you send something, then you might get an email back. But you're like, if I wait till tomorrow to send it, then I'm less likely to have another email, and then I've hit inbox zero, and I'm set for the day. I like it. It seems helpful.

+ +

CHRIS: Yeah, inbox zero sounds like an altruistic thing, but it is not. It's a way to force myself to have to make decisions, which is something that I want to get better at broadly. And that's part of the role that I have now. A lot of what I'm interested in exploring is just getting better at making decisions, being more decisive, being more action-oriented. Because I just have a tendency to make many, many spreadsheets and think about stuff for a while and take a long time to make a decision. But I don't get to do that, particularly now.

+ +

But broadly in life, that's probably not the right mode to be in. So inbox zero is another thing that forces me to deal with things rather than just be like, I don't know, I don't know, I don't know, and keep looking at the same thing over and over. So just more thoughts about inbox zero, but now I'll stop talking about it.

+ +

STEPH: I do like that, though. And you're totally right; it can be a very helpful constraint. And I think that's sometimes why I fight it because then I haven't curated my inbox enough that then when I go to it, there are so many interesting things that then I feel a little bit overwhelmed where I'm like, oh well, I want to read this, and I will look at that. And this seems interesting, and maybe I should be a part of this.

+ +

It feels like one of those like; you could be a part of these ten amazing things. Do you want to be a part of all of them? And given a person that it's hard for me to say no to or recognize that no, I'm just going to not do anything with this, that is hard for me and would be a good skill for me to hone in on and practice and make quick decisions and be very realistic.

+ +

Because I used to be subscribed to more newsletters, and then I finally had to stop subscribing to them because it had that same effect on me of that FOMO of like, I'm missing out on this great article or this great video. And I've become more honest with the fact that my Saturday morning self isn't going to want to read through a bunch of newsletters and videos about coding, that I'm going to want less screen time. So that is a really good constraint and helpful skill to cultivate for sure.

+ +

CHRIS: All right, I said it was done, but one more thing. I feel like I've mentioned this in the past, but Feedbin is the thing that I use for RSS. I still believe in RSS as a technology. But everyone's moved to newsletters these days that go via email. Feedbin gives you an email address that you can use to subscribe to newsletters, and then they do the job of converting that into an RSS feed.

+ +

So for me, I take something that was now a push into my inbox, and now I can pull whatever I want from that RSS feed. And on Saturday morning, if I'm feeling like, with a cup of coffee, I can enjoy some newsletter about all the new hot tips in Svelte land or whatever it is or not. But it's not clogging up my inbox. And with that, I think I'm actually done talking about inbox zero. [laughter]

+ +

STEPH: Yeah, that's a nice separation. We could keep going. I have full faith in us that we could keep going about this. But I'll share a slightly different update. I've been implementing a suggestion that you provided a couple of weeks back where we were talking about Rspec's selective test running and how some applications will speed up their test.

+ +

If you change one part of the codebase, then perhaps you only need to test this chunk of test. You don't actually need to run the full test suite. And that is complicated and seems hard to get right, and really requires understanding boundaries. But then also knowing Ruby, then how do you really identify? Do you really know where this method is being called and can identify all the tests that need to be run?

+ +

I think we'd mentioned before there's a really good article from Shopify where they have worked on this and created an open-source project called Packwerk. So we can link to that article in the show notes. But more specifically, you suggested, well, what if you just change a test file? That seems very low stakes and also has the benefit of creating a reward where if someone does see something that they can improve in a test, then that's a very quick feedback. Let me just get this change. It's going to be fast on CI. I can merge it right away and also saves time on CI.

+ +

So I've been working on implementing that change. And it's one of those the actual change is easy, like checking with Git to say, "Hey, what files have changed?" Does it have an _spec.rb at the end of it? Great. Does it not? Okay, we've changed some application files. So let's run the full test suite. That part's easy. Getting it integrated into the build system has been more complicated just because this team has done a lot of work around trying to improve and speed up their test. And there's a fair amount of complexity that's there.

+ +

So then figuring out a way to stitch my change into all the different build processes that take place has proven to be more difficult. But it's also been insightful just because it has now helped me really understand and forced me to learn, okay, what are all the different steps? What's important for each one? Where can I cut off the rest of the running of the test and instead just focus on running these tests? So in some ways, it's been challenging, but then on the positive side, it's been like, okay, well, this has taught me a lot about the existing system.

+ +

So at this moment, it is still a work in progress. I'll have more updates in the future. I am excited to see the rewards. I've gotten to the point where I just have a proof of concept where I've gotten pushed up, but it's not production-ready. But it's at least I just wanted the feedback that I'm in the right spot and that we're running just the right test.

+ +

And so far, it does seem like it's going to be a nice win, even if it's maybe not used by everybody because it's probably rare that someone is altering just a spec file. But for people who are looking specifically to improve the CI build time and working on tests, it will be very helpful to them. So yeah, I'm sure I'll have some more updates in the future. What's going on in your world?

+ +

CHRIS: Well, I definitely look forward to hearing more about that. However, we can improve CI speed; I'm super interested in that as a topic.

+ +

Mid-Roll Ad

+ +

Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem.

+ +

So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy.

+ +

That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software.

+ +

So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed.

+ +

CHRIS: Well, similar to your email adventures, I continue on my search for the perfect to-do list. It's not going great, if we're being honest. [laughs] To be clear, because I've mentioned this on a few different episodes, I'm not spending much time on this at all, some but not much. And so it's not really moving.

+ +

But there are two interesting things. I took a look at TickTick, which was one that I mentioned in the past, a tool for this. It seems good. It seems like an intersection between things, which is what I'm currently using, Todoist, which I've used in the past, and some other tools. So I think I'll probably explore that a little more. It seems like a good option.

+ +

Decidedly, the most interesting thing is a tool called Sunsama, which is different in some interesting ways but very interesting. So one thing to note about it is it's $20 a month, which is a lot of money for one of these tools because most of them are like, "We're $20 forever, and then it's free." And it's a surprisingly low-cost space. And so, they're definitely positioning themselves as a more costly entry. I would be fine with paying $20 a month for a tool if it really is like, no, cool, I feel great. I'm more productive. I'm happier when I'm not working, et cetera.

+ +

But what's interesting is they seem to do a let's reach out to all the places that tasks can live for you. So there's your inbox for email. There's your Trello board that you've got. There are GitHub issues. There's Slack. There are all these different sources of potential tasks. And they do a really good job of integrating with those other tools and then allowing you to pull that list into Sunsama and then make each day you have a list. And those items can be like, this is a reference to a Trello card on that board. This is a reference to a Slack conversation over there.

+ +

So I'm super intrigued by it. It's also got a very intentional plan your day mode, which I like because that's one of the things that I'm really looking for is at the end of the day, I want to clean everything up, make sense of all of the open items, and then reprioritize and set up for the next morning so that I can just hit the ground running. That said, I tried it, and it just didn't quite click. And I think it's one of those it takes some effort to understand how to use it. So I'm not sure that I'm going to get there.

+ +

But it is super interesting because that idea of our work lives in all of these different tools these days feels very true. And so, something that is trying to act as a hub between them to integrate them is very interesting to me. Again, I haven't really gotten anywhere on this. I'm kind of just reading blog posts, as it were. So I'll report back if that changes, but --

+ +

STEPH: The search continues for the right to-do app. Yeah, that seems interesting. I don't know why I'm feeling hesitant towards it. I'm one of those individuals...you're right; there are so many tools. And the fact that they integrate with a lot of them seems really nice.

+ +

I'm at the point where I just grab links to stuff, and I'm like, hey, if this is my priority, I grab a link to a Trello ticket, and then I just copy that into my to-do. I guess I like that bit of work over having to integrate with a bunch of different platforms. Because once you get used to integrating...I don't know; I'm just rambling. But I wish you the best on this journey. I'm excited to hear more. [laughter]

+ +

CHRIS: Thank you. I will certainly report back. But yeah, nothing pointed to share at this point. But I do have something pointed to share on the hiring front, which is that we have hired some folks.

+ +

STEPH: Hooray!

+ +

CHRIS: Yay. So this has been a fun saga across a couple of different episodes. And in my mind, it feels like this much longer, more drawn out thing, but it's; actually, I think, come together relatively quickly, all things considering. We've got someone who's starting in a little over a week's time, and then someone else who's starting in, I think, two or three weeks after that. So that'll be great. Hopefully, we can transition into onboarding, which is a different whole approach.

+ +

But hiring as a distinct activity can scale back significantly. As we discussed last week, I want to be in the always be hiring mindset but in the more passive mode of having conversations with folks, staying connected. And if a great candidate comes along and it's the right time, then bring them on the team but not actually actively reaching out and all that sort of stuff, which will be great. Because it turns out that takes a lot of time and also a lot of energy for me. Having those first conversations, going into it very intentionally trying to communicate about something, and there's a tone of salesmanship to it that is not my natural resting state.

+ +

So I come away from each conversation being like, that was fun, but also, I'm drained now. Why am I so drained? So not having that be a thing that is filling up my calendar is great. And also super excited with the folks that'll be joining the team and to be able to now grow our little team and define the culture and the shape of the groups that we will be collectively. I'm excited for that work and what we can build together. So yeah, it's an exciting time.

+ +

STEPH: That's awesome. Congratulations. Because yeah, everything you're saying sounds like it's just been a lot of work. So that's very exciting. There's someone that I was chatting with earlier today where they were talking about the value and the importance of understanding what your natural skills are and the things that bring you energy. And so you're mentioning there are certain activities that you enjoy them, but they're also draining because perhaps they are on the outer boundary of what you might define as your own natural skill or the things that get you really excited. And I found that all very interesting.

+ +

It had me thinking about that today about where are the natural areas that I find that I get energy that are easier for me? And then making sure that I'm trying to prioritize my day so that I am more focused on the activities that just align with who I am and also that I'm engaged with and then also looking for ways to stretch. But they made the point that if you are always in a space where you are not using your natural talents, and you're always having to stretch, then that can be what leads to burnout. Versus if you're in that sweet spot, that zone of where you are using your natural skills, but then also stretching a bit.

+ +

And I think there are some assessments and things like that that will help you then determine what are my natural skills, and what do I like to do with my time? I just like that style of thinking and recognizing, like you said, like, hey, I did a thing. It was fun, but I'm drained. So now I know that this is something that requires more effort for me. Like hiring, that's one for me.

+ +

I really like interviewing. I like talking with people, but I'm so nervous for them because I know interviews suck. [laughs] I just have so much empathy for them where I'm like, this is going to be a hard day. We're going to make it as pleasant and positive as possible, but I know this is a hard day. And so I feel like I'm in it with them. And so afterwards, I feel that same relief of like whoo, okay, interview day is over.

+ +

CHRIS: I don't know that I quite achieve the same level that you do but in no way am I surprised that that is your experience of hiring. And just to name it, you're a wonderful human being that feels for the people on the other side of the hiring table. Like, oh my God, this must be so stressful for you. It's so kind of you to be in that space with folks.

+ +

But coming back to what you were saying a moment ago, that idea of, like, understanding where your strengths are and where they're areas that you're not quite as strong. And I think critically, the question of like which are the ones where I want to just kind of say no to? I'm like, that's fine. This is not going to be a competency of mine. And I'm going to just avoid that or find other people to work with that balance that out. So for me, sales is the thing that I don't think that's ever going to be my bag. I don't think I'm ever going to move in that direction, and that's totally fine.

+ +

Whereas decisiveness, which I was describing, is like, I think that's the thing I could get better at. That is one that I don't want to sleep on that. I don't want to say, "That'll be fine. I'll just have other people make the decision." No, I need to get better at making decisions, making decisions with less information or more rapidly, having a bias towards action. All those things I think will be deeply beneficial. So I'm trying to really lean into that. Whereas yeah, again, the sales stuff I'm like, yeah, and there's plenty of examples of this otherwise.

+ +

But I've also been coding a bit more this week, which has been lovely because the hiring stuff has ramped down. And that has freed me up amongst some other stuff that's been going on. And you know, I like to code, it turns out. It's fun. I just clack about on my cherry brown keys, and it's great.

+ +

STEPH: Do you remember when we first got introduced to mechanical keyboards, and we had co-ownership of one of the keyboards? And we literally had days of where it was like your turn to use the keyboard. And then it was my turn to use the keyboard. How long did we keep that up before we were finally like, we should just buy our own keyboards?

+ +

CHRIS: It was a while because we were working with a colleague who was trying out a Kinesis, I want to say, one of the split little bowl of keys. But yeah, we had a shared custody over a keyboard, and it was fantastic. I remember that very fondly.

+ +

STEPH: The days that it was my keyboard, I would go to the office and be like, oh, today is my day at the keyboard. This is great. This is going to be such a wonderful day. [laughs] And now I'm just spoiled.

+ +

CHRIS: It went on for a while, though. And this was something where we both obviously enjoy this keyboard. Why don't we just buy one of these keyboards? We totally could have done that. And yet, for some reason, both of us were like, no, but what if...I got to think about this. Again, decisiveness. [laughs] We come back to this topic of well; I had to really think about it. And then somebody got the 92-Key test or whatever it was in the office. And so I just went over and poked every one of those for a while.

+ +

STEPH: Exactly. It was option overload where we're like, well, okay, we're going to buy one, and then you open it up and search, and you're like, oh, you want options? We have options. Do you know about the blues, and the browns, and the colors, and these different options? Like, I don't know any of this language that you're talking about. I just want to clackety-clack. So yeah, it took time. We had to do our research.

+ +

CHRIS: And then I ended up on basic browns. So here we are. Let's see, popping back up the stack a couple of levels, hiring that went on for a while. Now it is less going on. Although to be clear, like I said, always be hiring. So if anyone out there in the world is hearing what I'm talking about with Sagewell or seeing any of the stuff that I'm putting on Twitter, which isn't much, I occasionally just post screenshots of my commit messages, which recently included better snakes as a commit message. [laughs] I have to dig into that or not. But we were just doing some snake case to camel case conversion. But the commit message was better snake, so here we are.

+ +

Anyway, if any of that sounds interesting, please do reach out. But I'm excited to transition back to focusing more on the work. On that note, actually, I'm going to call it interesting things that is happening right now organizationally is; we are working with an external security firm to help with some...they helped us out with a penetration test when we needed that. And then they have stayed on retainer and are helping with various different configurations, taking our AWS S3 buckets and making sure those are nice and secure, and all that kind of stuff.

+ +

But we've recently started to focus more on organizational security, specifically a bowl of acronyms. We've got SSO for single sign-on, MDM for something device management. I don't know what that first M is. I probably should learn it, but it's fine. That's why I've got help on this is I think they know what the acronym stands for. But so we're working on each of those.

+ +

And on the one hand, they're probably going to be kind of annoying, like having to go through the single sign-on. It's a whole thing, and it's harder to sign into stuff sometimes. I mean, ideally, it's actually easier. But in my experience, it adds some friction at some points. And then MDM means that there's now some profile manager on the computer. So I can say like, "Every computer must have full disk encryption or else you can't use it. And we need a passcode, and it must be this long and those sorts of things." So it's organizational controls that I think are good for us having a robust security setup throughout the organization.

+ +

But yeah, they're the sort of things that I think historically, I probably would have, as someone working in an organization, had been like, do we have to? Do we need these things? Couldn't I just do whatever? But now there's something about it that I really like. I'm trying to name it in my head, but I'm kind of like, I don't know. This feels like growing up as an organization.

+ +

And there's always weird corollary that I've been thinking about with the Rails app that we've been building, intimately familiar with just everything that's going into it. And I know the vast majority of lines of code. I haven't written them all, but I've had an eye on all of the different features that we're building in.

+ +

And it's hard to get out of that headspace where it feels like a bunch of pieces. It doesn't feel like a hole to me, even though it definitely is. But when does a bunch of boards that you nail together become a boat? To make a really weird analogy because that's what I do; it's a hobby of mine. But when does that transition happen? At some point, certainly. But that's harder for me to see on the code side.

+ +

And organizationally, somehow getting these things in place feels like the organization sort of an inflection point for us, a growth point, which is I'm really excited about it. Even though they're probably going to mean a ton of annoying nuisance work for me because I'm the person in charge of making sure it all gets rolled out. And anytime anyone locks themselves out of an account, I have to help with that. And so it's probably just putting a bunch of annoying work on my plate. And yet, I don't know; I'm kind of excited about it.

+ +

STEPH: I feel like that shows our roots in terms of how we approach projects that we work on where you mentioned do we need this? Do we need this yet? Because I feel that we're constantly as developers and consultants just we're trying to advise on the more simplified do we need this? Is this the right thing to spend the money on? How do we know? What are the metrics? What does success look like? And all those questions.

+ +

So I feel like the way you just phrased all of that just really shows that sort of mentality that you grew up with in terms of checking in, and yeah, it's cool. Like you said, you're at a growth point where then it's like, yes, we are at this point that I've asked myself all those questions, and we're here. This feels like the right next step.

+ +

CHRIS: I like the way you described it as that you grew up with, my formative growing years at thoughtbot.

+ +

Mid-roll Ad

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Well, switching gears just a bit, we have a listener question for today, and this one comes from Stephanie. So not me, another Stephanie in the world. Hello, other Stephanie out there in the world. And they wrote in, "Hi, Steph and Chris, fellow software consultant here. And I'm wondering if you'd consider talking about how to craft a project estimate for a client on the pod. It's such an important aspect of consulting." Amen. I added the amen.

+ +

"And I feel like I'm very much impacted as a project team member when the estimate isn't accurate." Double amen. So true. [laughs] "Would appreciate any and all thoughts, especially since it might be part of my job in the future. Thanks." I just realized I put us in consultant church by adding all those amens, but here we are. [laughs]

+ +

CHRIS: I'm glad you clarified that they were additions by you and not part of the original question coming in.

+ +

STEPH: Sure. I don't want to speak on behalf of Stephanie. So I have some thoughts on the matter. I think there are a couple of different ways that we can talk about this particular question because I think there are different formats as to when you're estimating and who you're providing the estimate for. But I'm going to pause because I'd love to see what you think. How do you go about approaching crafting an estimate?

+ +

CHRIS: Sure. I'm happy to share some thoughts. And for a bit of context, this question came in to us, frankly, many months ago, but I did send an initial reply to Stephanie because I know that sometimes we take a little bit of time to get back to folks. So if ever you do send in a question, know that one of us will probably respond via email earlier, and then eventually, will make it on the show. And again, just to say, we do so appreciate when folks send in these questions. It's an interesting way to shape the conversation and a way to get topics that you're more interested in into the fold here.

+ +

But so the two main ideas that I shared in my initial reply were, first, is an estimate really necessary? I think that's a critical question because an estimate implies that this thing is knowable. And as many of us, probably all of us, have found out at some point in our lives as software developers, it's really hard to do software estimation, like wildly difficult. And not just the thing that we'll eventually get better at it, which you do, but there's just some chaos. There's some noise in this work that we do that makes it so, so difficult to get it right.

+ +

So pretty much always, I will ask, like, do we need to estimate here? What if, instead, we were to flip the whole question on its head and say, let's set a deadline. Let's say two months from now that's our deadline. And let's ruthlessly reprioritize every single week to make sure that we're building something that's meaningful, and we're getting there.

+ +

And obviously, we have to have some general idea of what we're doing. Is two months a meaningful amount of time to build a rocket to go to Mars? Probably not. But is it enough time to build an app that can allow users to sign in and manage a simple list of items? Yeah, we can definitely do that, and we can probably add a bunch of more features.

+ +

The other thing that I think is worth highlighting is there's a bunch of stuff that is table stakes and very easy to do. But I would, whenever doing estimation, emphasize unknowns. So, where are the external integrations with other systems? Where are the dependencies that rely on other folks to provide some inputs into this process that we can't be certain where there'll be?

+ +

In my experience, the places where estimates go awry are often these little intersection points that you're like, well, this will probably take a day, maybe two. And it turns out; actually, this can somehow balloon into a month. That's not a thing that feels comfortable saying in an estimation process, but it is definitely real. I've seen it happen so many times.

+ +

And so it's those unknowns. It's those little bits that I would emphasize as part of the process if you do need to do an estimate and say, all right, here's the boring stuff. I think we can do that pretty easily. But this part, I don't know, it could be a week, could be three months. And frame it in that way that there is this ambiguity there. Because if someone's asking you for an estimate and they're looking for like it is seven days and two hours exactly, it's like, well, that's not realistic. That's not how this thing works. Unfortunately, I wish it did.

+ +

But pushing back and changing the conversation is the thing that I have found valuable. I think there's some other really interesting stuff in here around the team dynamics that Stephanie is talking about. But I want to send this over to other Stephanie to see your thoughts because I'm super interested to hear what you have to say as well.

+ +

STEPH: Oh, I like how you hinted at the team dynamics. Yeah, that could be a fun one to circle back to. So I love how you called out highlighting the unknowns. There are a couple of ways that this comes to mind for me. So there's the idea of the weekly or the bi-weekly estimates that we make as developers and designers. So let's say we as a team are getting together to focus on a chunk of work and decide what we can and can't get through. And that feels one of those the more you get to practice it more frequently; you get to ask a bunch of questions. And that feels like a good rehearsal and exercise of how to go through estimates.

+ +

And I know you and I have pretty similar strong feelings around how those estimates are then treated by the company. They should really just be used for the team to talk through the complexities in the work to be done versus used to communicate outwardly as to this is when it's definitely going to ship. So there's that more immediate practice of providing estimates. And then there's the idea for more of a consultancy or a company, and someone is coming to you, so thoughtbot being a great example of then how do we work with teams that are looking to come to us and gain an estimate for getting a certain feature implemented?

+ +

So actually, I went to the source on this one. I went to Josh Clayton, who does a lot of the conversations for the Boost team when it comes to talking with clients and about the potential work that they would like to be done. And mostly our work is often teams will hire us. They have specific goals in mind, but they're really looking to hire ongoing development and services. So they really want to add to their existing staff. And then it's going to be an ongoing relationship versus a hey, we need you to quote us for how long it's going to take to implement this particular feature.

+ +

And on that note, we don't do fixed-bid work. So we don't say it's X dollars for specific features. But on the realistic side, customers are often capped by a budget. And so that estimate is very important to them because it could be a difference between it's a go versus a no go. So if you have larger companies that are like, "Yep, we want to engage with thoughtbot. We really just want additional development power and design services," that's great.

+ +

For those that are smaller, it could be an individual product owner, and they need to say, "I really want this feature, but I only have this much money. And frankly, if I can't ship it by this time, I'm not going to do it because it's not worth the investment to my company." And then, in those cases, those are the ones that we're going to spend more time with them to talk about what does the fallback plan look like? And what's our opportunity for simplifying the features?

+ +

And Josh, in particular, referenced this as systems thinking. So he will go through the idea of drawing out the set of steps, understanding the complexity of the different screens. So what are the validations? What are the external dependencies? What is owned by us and what isn't? What is the likelihood that we're going to get permission to simplify or remove complexity? And even then, when we start to provide some estimates, it's going to be in weeks. It's not in hours; it's not in days. It's going to be in a slightly larger time frame.

+ +

And then we're also going to spend more time in the discovery phase to say, okay, well, we know you need to fix this particular issue, or you need to integrate with this particular service. So we're going to need to ask a lot more questions about your codebase. What problems have you already run into? Have you tried to do this before? Do we have experience doing this? Is this something that we can lean on and ask someone in the team? And, say, how long do you think it would take for us to work on this?

+ +

And that's knowledge that isn't privy to everybody. It depends on where you're at in your career as to like, oh yeah, I've done this like five times before, and I know exactly how this stuff can fall apart. I know where the complexity lies. So I think that's why estimation is so difficult is just because it does often pull from that existing experience. And so, if you don't have that experience for a particular set of work, of course, it's going to be hard to estimate because you just don't know. So that was a very broad scope of as day-to-day developer and designers; I feel like we're constantly getting practice and estimating and communicating the progress of our work.

+ +

And then on the larger scope of if you are a consultant who's then looking to give estimates to clients, then understanding what other need can you sell them? Just ongoing development services. Or, if they are a smaller team and very focused, then what legwork can you do ahead of time to de-risk the project? And then understand how much control you're going to have to be able to simplify as you learn more as you go. Because you're going to, you're going to uncover some things, and you're going to learn some things. And what's that collaboration going to look like?

+ +

I do have one more concrete example I can provide around some of the smaller projects that we take on. So when we are helping someone that's, say, getting a new product out to market, then we do have a more deliberate three, four-phase approach where we first focus on discovery, and ideation, and validation. And then, we move on to iteration and then launching.

+ +

And I really like how you said about providing a deadline because then that helps us scope aggressively as to what is the minimum thing that we can get out into the world that will be valuable? And then there's usually some post-launch support as well. But that's often how we will structure those smaller, more specific engagements.

+ +

CHRIS: I think one of the critical things that you highlighted in there is that thoughtbot doesn't do fixed-bid work. So we're going to do these 20 features, and it's going to take four months. thoughtbot does not do that, and frankly, that's a privilege to be able to take that position and say, "No, no, no," we're not going to work that way. But it is, I think, a trade-off. It's not just something that thoughtbot does to be like, listen, that doesn't sound fun. So I'm not going to do that. It's a trade-off.

+ +

Not doing that comes in concert with saying, "But weekly, we're going to talk about the work that we have done and the work that remains and constantly, ruthlessly, reprioritize and re-decide what we're doing." And it's that engagement, the idea that you can have a body of work, look at it and say, "Yeah, that'll take about six months," and then go away for six months, and then come back with the finished software.

+ +

Our strong belief is that that's not the way good software gets built. But instead, it's a very engaged team where the product owner and the development team are in constant communication about each of the features that are being developed. And then again, ideally, on a weekly cadence, coming up for air and saying, "How are we doing? Are we moving in the right direction? Are we getting towards the goals? If not, do we need to simplify? Do we need to change things?"

+ +

And similarly, as I mentioned deadlines, I feel like deadlines is probably a word that many people think of as very bad because deadlines often come with also a fixed scope, but that can't happen. That's two constraints, and you can't have them fighting that way. But a deadline can be super useful as a way to say we're going to put something out there in the future and say we're heading towards that moment. And let's, again, cut scope. Let's change what we're building, et cetera.

+ +

But critically, not say, "We got a deadline and a fixed scope. We're going to do that." And so it's, again, just ways to gently shift the conversation around and say, what if we were to look at this from a different angle? Because just having a pile of work and saying, "That'll take six months," I've never seen that play out.

+ +

STEPH: Yeah, to me, deadline is a bad word when the deadline is set by a team that's not doing the work. So if you have leadership or if you have someone else that is setting this deadline and then just passing that down to someone else to then fulfill, regardless of the feedback or how things are going, then yeah, then it can be a nasty thing, which I think is a little bit of in that question that you picked up on that you highlighted where there could be some interesting team dynamics that Stephanie called out, highlighting that I'm very much impacted as a project team member when the estimate isn't accurate.

+ +

And I'm making some assumptions here because I don't actually know the exact situation that Stephanie is experiencing. But it sounds like someone else externally is setting these team estimates. And so then you're handed this deadline, and then stuff goes wrong, but you're still pressured to meet this deadline. And I've certainly been part of projects that are like that.

+ +

And then that is one of the number one things that then often comes up in a retro or like, we don't have control over these deadlines, or we don't know why these deadlines are being set. And then people are working extra hours and working nights and weekends to then meet this arbitrary deadline that none of us signed up for, and that's just not fair to treat deadlines in that way.

+ +

So full-heartedly agree that deadlines can be a very positive thing, but they need to be set by the people doing the work. And then there has to be discussions and updates about how is this going? Do we have control to simplify this? We thought we could do this with this particular external provider. It turns out that that's a nightmare. Is there another provider we can go with? Can we ship this incrementally? Like some features, you can't. They may have to go out wholesale. But is there a small chunk of this that we can deliver that is then a success that leadership and others can brag about? And then we can keep working on the rest of it.

+ +

So it's always identifying what are the smallest wins, and how do we get there and getting buy-in from the team? Going back to something that you said earlier around, it is a privilege, where so as thoughtbot, we don't do fixed-bid work. And that is a nice thing for us to be able to focus on. But for people who do need to do fixed bid work and are relying on that, I think that often requires more legwork. And maybe that becomes part of your estimate. I'm just making up how I might approach this if I were trying to do fixed bid work.

+ +

But there's a discovery phase that's very important. So maybe the first part of your estimate is I need to really understand the feature and see the different screens and know what materials we do or don't have. What does the codebase look like? Do I feel like this is a codebase that I can work quickly in? And is it going to be hindersome for me? But answering a lot of those questions to then help me paint a picture of, like, okay, this is a feature that I've implemented before, so I feel pretty confident that I could do this in a month.

+ +

And then also communicating that this is my estimate but just know it's an estimate. And I will continue to update you each day as to how things are going or each week as to how things are going, and things may adjust. And we can always talk about ways about simplifying this. But I think that's how I would go about it is; frankly, it's going to require more legwork for me to feel more confident as to then telling someone as to how long I think the work will take.

+ +

I think that's a nice, broad scope of the different types of estimate work to be done with the general idea of if you can avoid estimates and go for more frequent updates, then that's wonderful. But then, if you are forced into a corner where you need to provide an update, then just do as much research and honesty as possible and then still include the frequent updates.

+ +

CHRIS: Yeah, that I think summarizes it quite well.

+ +

STEPH: As a side note, it's been a lot of fun to feel like I'm referring to myself as a third person as Stephanie is working through this problem. So that's been novel. But yeah, thank you, Stephanie, for the great question. I hope that was helpful. On that note, Shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph joins Chris in trying new things! For her, it's a new email client – the Newton email client – because she really wants to love her inbox. She also talks about implementing a suggestion from Chris on improving CI speed.

+ +

Chris continues his search for the perfect to-do list app. (It's not going great.) But he has made hiring progress and is excited to move on to the next step: onboarding.

+ +

Together they answer a listener question who asked for advice on crafting project estimates for clients.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: I am now recording.

+ +

STEPH: Me too.

+ +

CHRIS: [laughs] That's my recording voice.

+ +

STEPH: [laughs]

+ +

CHRIS: That's how you can tell.

+ +

STEPH: I just like how it sounds suspicious where we're like; I'm now recording, so be careful. [laughs]

+ +

CHRIS: This is now on the record.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hello. Happy, happy Friday. Oh, I have something that I'm excited or intrigued about. I don't know. Okay, I'm hyping it up. [laughs] But I'm realizing I'm also very skeptical of it.

+ +

CHRIS: This is the best sales pitch I've ever heard. I'm so excited to hear what this is. [laughs]

+ +

STEPH: I am trying a new email client; it is the Newton email client. And I so want to love my inbox. I want to check on it. I want to help it grow. Okay, that's the opposite. I want to help get through all the emails that come through, but I just want to love it. I want it to be a good space that I want to go to. And I just hate email so much. And it always feels like this chore that it's really hard for me to bring myself to do, but yet it's really important because a lot of good things come through email.

+ +

So this is my rambly way of saying I'm trying the Newton email client because I saw on Twitter from Andrew Mason, who has very similar feelings that I do about email, where we are just not fans of it. And we rarely check it and have declared email bankruptcy at several points in our life. And he's also one of the co-hosts for Remote Ruby. But I saw on Twitter that Andrew was talking about the Newton email client and how it actually made him feel that he enjoyed writing and looking through his inbox. And I was like, yeah, that's the sales pitch I need. So I'm giving it a go. It's been only a couple of days.

+ +

But one of the nice things I have noticed about it is it's very focused, and there's not much noise, and it actually feels like very minimal design where if you open up like a new email, so you're opening up a new draft, there's no much noise. You get to just focus, almost like you're writing a little blog post or journal post or something. It takes away a lot of the noise.

+ +

While in Gmail, it's going to open up a small window in the right, but then you still have the rest of the noise that feels distracting. So I like that very intentional like, hey, you're just doing one thing, just focus on this. And then also you can integrate other email accounts as well. So you can have one-stop shopping versus Gmail, then you have to click around and sign in, sign out, or visit different email accounts. So we'll see if it helps improve my email life, but that's something new I'm trying.

+ +

CHRIS: Very interesting. So you're fully on inbox zero life now. That's what I'm hearing. [laughs]

+ +

STEPH: Ah, hmm. I don't want to lie to you. [laughs] We have a good friendship. I won't start lying now.

+ +

CHRIS: I appreciate that. So you're halfway to inbox zero. You're not even entertaining that idea, right? This is just you want a better tool to do email.

+ +

STEPH: Exactly. Inbox zero is not incredibly important to me. But I do want to make sure that I know that I've seen everything important, and I know where to find things. And then making sure that I am responding to people in a timely manner. Those are more my goals. Inbox zero, if that supports it, then great, I'll work on it. But not necessarily that has to be the goal that I reach.

+ +

CHRIS: Gotcha. I'm not seeing Newton, but I'm intrigued. Particularly on mobile, I have the Gmail mobile app, and that has unified inbox, which I appreciate. But Gmail on the web does not, and I find that odd. And I've never found a mail app that I enjoy because I want some of the features of Gmail. I want to do Gmail snoozing because I still want that to be consistent and whatnot. And to be honest, that's the main way that I get to inbox zero. I just say future me will have more time.

+ +

I actually tweeted recently. It was a screenshot from my Saturday inbox, which I think was 15 emails that I'd snoozed from the previous week into Saturday morning. Because I'm like, Saturday morning me will have so much time, and energy, and coffee, and it'll be great. And then it became Saturday morning and, ooph, what a view.

+ +

STEPH: [laughs] Yeah, your snoozing tip has been life-changing for me because that's not something that I was using all that much. The two things are, one, schedule send so that way if I do have a sudden burst of energy and I want to write an email, but I want to make sure that person doesn't get notified until a decent time. Being able to schedule an email and snoozing is amazing.

+ +

I think Newton and Gmail have pretty much similar features. I was trying to do a comparison. I was like, is there something really snazzy that Newton does that Gmail doesn't already give me? But it looks like they all do about the same, having those important features like snoozing and then also being able to schedule emails.

+ +

So I think it really just comes down to a lot of the UI, and there may be some other stuff I'm missing since I'm new to it. But that's the main appeal for me right now is the focus and the look and feel of it. So then maybe I will find looking through my inbox a more zenful experience, I think is how I saw them advertise it.

+ +

CHRIS: Well, I definitely look forward to hearing more as you explore this space. I will say looping back to what you were just commenting on around deferred send, which is definitely something that I use, but you described one of the reasons that I use it. So the idea of wanting to be respectful of someone else and not send them an email on Sunday night because you happen to be working at that point. But you don't want to put that on their plate. I would say equal amounts; that's the reason I use scheduled send.

+ +

And then the other reason that I use scheduled send is please, for the love of God, I do not want another email back in my inbox. So I will reply to something such that now I'm done with that, but I will schedule send it for the next morning. Because tomorrow morning me can deal with whatever reply this generates.

+ +

There's some adage; I don't know if it's an adage, but the idea that every email that you send generates 1.1 emails in reply. So emails just have this weird way of multiplying. And so if you send one out there, you're probably going to get something back. And so often, if I'm trying to clear my inbox, I don't want to get another email in my inbox at that moment. So I will not actually send the reply. I will schedule it for a future time because I do not want to hear. I want no new inputs at this point. I'm trying to process them. So that's part of why I use deferred send.

+ +

STEPH: I had not thought of that, that yeah, that if you schedule it for tomorrow, you've really gamified this inbox zero because you're like, yeah, if you send something, then you might get an email back. But you're like, if I wait till tomorrow to send it, then I'm less likely to have another email, and then I've hit inbox zero, and I'm set for the day. I like it. It seems helpful.

+ +

CHRIS: Yeah, inbox zero sounds like an altruistic thing, but it is not. It's a way to force myself to have to make decisions, which is something that I want to get better at broadly. And that's part of the role that I have now. A lot of what I'm interested in exploring is just getting better at making decisions, being more decisive, being more action-oriented. Because I just have a tendency to make many, many spreadsheets and think about stuff for a while and take a long time to make a decision. But I don't get to do that, particularly now.

+ +

But broadly in life, that's probably not the right mode to be in. So inbox zero is another thing that forces me to deal with things rather than just be like, I don't know, I don't know, I don't know, and keep looking at the same thing over and over. So just more thoughts about inbox zero, but now I'll stop talking about it.

+ +

STEPH: I do like that, though. And you're totally right; it can be a very helpful constraint. And I think that's sometimes why I fight it because then I haven't curated my inbox enough that then when I go to it, there are so many interesting things that then I feel a little bit overwhelmed where I'm like, oh well, I want to read this, and I will look at that. And this seems interesting, and maybe I should be a part of this.

+ +

It feels like one of those like; you could be a part of these ten amazing things. Do you want to be a part of all of them? And given a person that it's hard for me to say no to or recognize that no, I'm just going to not do anything with this, that is hard for me and would be a good skill for me to hone in on and practice and make quick decisions and be very realistic.

+ +

Because I used to be subscribed to more newsletters, and then I finally had to stop subscribing to them because it had that same effect on me of that FOMO of like, I'm missing out on this great article or this great video. And I've become more honest with the fact that my Saturday morning self isn't going to want to read through a bunch of newsletters and videos about coding, that I'm going to want less screen time. So that is a really good constraint and helpful skill to cultivate for sure.

+ +

CHRIS: All right, I said it was done, but one more thing. I feel like I've mentioned this in the past, but Feedbin is the thing that I use for RSS. I still believe in RSS as a technology. But everyone's moved to newsletters these days that go via email. Feedbin gives you an email address that you can use to subscribe to newsletters, and then they do the job of converting that into an RSS feed.

+ +

So for me, I take something that was now a push into my inbox, and now I can pull whatever I want from that RSS feed. And on Saturday morning, if I'm feeling like, with a cup of coffee, I can enjoy some newsletter about all the new hot tips in Svelte land or whatever it is or not. But it's not clogging up my inbox. And with that, I think I'm actually done talking about inbox zero. [laughter]

+ +

STEPH: Yeah, that's a nice separation. We could keep going. I have full faith in us that we could keep going about this. But I'll share a slightly different update. I've been implementing a suggestion that you provided a couple of weeks back where we were talking about Rspec's selective test running and how some applications will speed up their test.

+ +

If you change one part of the codebase, then perhaps you only need to test this chunk of test. You don't actually need to run the full test suite. And that is complicated and seems hard to get right, and really requires understanding boundaries. But then also knowing Ruby, then how do you really identify? Do you really know where this method is being called and can identify all the tests that need to be run?

+ +

I think we'd mentioned before there's a really good article from Shopify where they have worked on this and created an open-source project called Packwerk. So we can link to that article in the show notes. But more specifically, you suggested, well, what if you just change a test file? That seems very low stakes and also has the benefit of creating a reward where if someone does see something that they can improve in a test, then that's a very quick feedback. Let me just get this change. It's going to be fast on CI. I can merge it right away and also saves time on CI.

+ +

So I've been working on implementing that change. And it's one of those the actual change is easy, like checking with Git to say, "Hey, what files have changed?" Does it have an _spec.rb at the end of it? Great. Does it not? Okay, we've changed some application files. So let's run the full test suite. That part's easy. Getting it integrated into the build system has been more complicated just because this team has done a lot of work around trying to improve and speed up their test. And there's a fair amount of complexity that's there.

+ +

So then figuring out a way to stitch my change into all the different build processes that take place has proven to be more difficult. But it's also been insightful just because it has now helped me really understand and forced me to learn, okay, what are all the different steps? What's important for each one? Where can I cut off the rest of the running of the test and instead just focus on running these tests? So in some ways, it's been challenging, but then on the positive side, it's been like, okay, well, this has taught me a lot about the existing system.

+ +

So at this moment, it is still a work in progress. I'll have more updates in the future. I am excited to see the rewards. I've gotten to the point where I just have a proof of concept where I've gotten pushed up, but it's not production-ready. But it's at least I just wanted the feedback that I'm in the right spot and that we're running just the right test.

+ +

And so far, it does seem like it's going to be a nice win, even if it's maybe not used by everybody because it's probably rare that someone is altering just a spec file. But for people who are looking specifically to improve the CI build time and working on tests, it will be very helpful to them. So yeah, I'm sure I'll have some more updates in the future. What's going on in your world?

+ +

CHRIS: Well, I definitely look forward to hearing more about that. However, we can improve CI speed; I'm super interested in that as a topic.

+ +

Mid-Roll Ad

+ +

Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem.

+ +

So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy.

+ +

That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software.

+ +

So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed.

+ +

CHRIS: Well, similar to your email adventures, I continue on my search for the perfect to-do list. It's not going great, if we're being honest. [laughs] To be clear, because I've mentioned this on a few different episodes, I'm not spending much time on this at all, some but not much. And so it's not really moving.

+ +

But there are two interesting things. I took a look at TickTick, which was one that I mentioned in the past, a tool for this. It seems good. It seems like an intersection between things, which is what I'm currently using, Todoist, which I've used in the past, and some other tools. So I think I'll probably explore that a little more. It seems like a good option.

+ +

Decidedly, the most interesting thing is a tool called Sunsama, which is different in some interesting ways but very interesting. So one thing to note about it is it's $20 a month, which is a lot of money for one of these tools because most of them are like, "We're $20 forever, and then it's free." And it's a surprisingly low-cost space. And so, they're definitely positioning themselves as a more costly entry. I would be fine with paying $20 a month for a tool if it really is like, no, cool, I feel great. I'm more productive. I'm happier when I'm not working, et cetera.

+ +

But what's interesting is they seem to do a let's reach out to all the places that tasks can live for you. So there's your inbox for email. There's your Trello board that you've got. There are GitHub issues. There's Slack. There are all these different sources of potential tasks. And they do a really good job of integrating with those other tools and then allowing you to pull that list into Sunsama and then make each day you have a list. And those items can be like, this is a reference to a Trello card on that board. This is a reference to a Slack conversation over there.

+ +

So I'm super intrigued by it. It's also got a very intentional plan your day mode, which I like because that's one of the things that I'm really looking for is at the end of the day, I want to clean everything up, make sense of all of the open items, and then reprioritize and set up for the next morning so that I can just hit the ground running. That said, I tried it, and it just didn't quite click. And I think it's one of those it takes some effort to understand how to use it. So I'm not sure that I'm going to get there.

+ +

But it is super interesting because that idea of our work lives in all of these different tools these days feels very true. And so, something that is trying to act as a hub between them to integrate them is very interesting to me. Again, I haven't really gotten anywhere on this. I'm kind of just reading blog posts, as it were. So I'll report back if that changes, but --

+ +

STEPH: The search continues for the right to-do app. Yeah, that seems interesting. I don't know why I'm feeling hesitant towards it. I'm one of those individuals...you're right; there are so many tools. And the fact that they integrate with a lot of them seems really nice.

+ +

I'm at the point where I just grab links to stuff, and I'm like, hey, if this is my priority, I grab a link to a Trello ticket, and then I just copy that into my to-do. I guess I like that bit of work over having to integrate with a bunch of different platforms. Because once you get used to integrating...I don't know; I'm just rambling. But I wish you the best on this journey. I'm excited to hear more. [laughter]

+ +

CHRIS: Thank you. I will certainly report back. But yeah, nothing pointed to share at this point. But I do have something pointed to share on the hiring front, which is that we have hired some folks.

+ +

STEPH: Hooray!

+ +

CHRIS: Yay. So this has been a fun saga across a couple of different episodes. And in my mind, it feels like this much longer, more drawn out thing, but it's; actually, I think, come together relatively quickly, all things considering. We've got someone who's starting in a little over a week's time, and then someone else who's starting in, I think, two or three weeks after that. So that'll be great. Hopefully, we can transition into onboarding, which is a different whole approach.

+ +

But hiring as a distinct activity can scale back significantly. As we discussed last week, I want to be in the always be hiring mindset but in the more passive mode of having conversations with folks, staying connected. And if a great candidate comes along and it's the right time, then bring them on the team but not actually actively reaching out and all that sort of stuff, which will be great. Because it turns out that takes a lot of time and also a lot of energy for me. Having those first conversations, going into it very intentionally trying to communicate about something, and there's a tone of salesmanship to it that is not my natural resting state.

+ +

So I come away from each conversation being like, that was fun, but also, I'm drained now. Why am I so drained? So not having that be a thing that is filling up my calendar is great. And also super excited with the folks that'll be joining the team and to be able to now grow our little team and define the culture and the shape of the groups that we will be collectively. I'm excited for that work and what we can build together. So yeah, it's an exciting time.

+ +

STEPH: That's awesome. Congratulations. Because yeah, everything you're saying sounds like it's just been a lot of work. So that's very exciting. There's someone that I was chatting with earlier today where they were talking about the value and the importance of understanding what your natural skills are and the things that bring you energy. And so you're mentioning there are certain activities that you enjoy them, but they're also draining because perhaps they are on the outer boundary of what you might define as your own natural skill or the things that get you really excited. And I found that all very interesting.

+ +

It had me thinking about that today about where are the natural areas that I find that I get energy that are easier for me? And then making sure that I'm trying to prioritize my day so that I am more focused on the activities that just align with who I am and also that I'm engaged with and then also looking for ways to stretch. But they made the point that if you are always in a space where you are not using your natural talents, and you're always having to stretch, then that can be what leads to burnout. Versus if you're in that sweet spot, that zone of where you are using your natural skills, but then also stretching a bit.

+ +

And I think there are some assessments and things like that that will help you then determine what are my natural skills, and what do I like to do with my time? I just like that style of thinking and recognizing, like you said, like, hey, I did a thing. It was fun, but I'm drained. So now I know that this is something that requires more effort for me. Like hiring, that's one for me.

+ +

I really like interviewing. I like talking with people, but I'm so nervous for them because I know interviews suck. [laughs] I just have so much empathy for them where I'm like, this is going to be a hard day. We're going to make it as pleasant and positive as possible, but I know this is a hard day. And so I feel like I'm in it with them. And so afterwards, I feel that same relief of like whoo, okay, interview day is over.

+ +

CHRIS: I don't know that I quite achieve the same level that you do but in no way am I surprised that that is your experience of hiring. And just to name it, you're a wonderful human being that feels for the people on the other side of the hiring table. Like, oh my God, this must be so stressful for you. It's so kind of you to be in that space with folks.

+ +

But coming back to what you were saying a moment ago, that idea of, like, understanding where your strengths are and where they're areas that you're not quite as strong. And I think critically, the question of like which are the ones where I want to just kind of say no to? I'm like, that's fine. This is not going to be a competency of mine. And I'm going to just avoid that or find other people to work with that balance that out. So for me, sales is the thing that I don't think that's ever going to be my bag. I don't think I'm ever going to move in that direction, and that's totally fine.

+ +

Whereas decisiveness, which I was describing, is like, I think that's the thing I could get better at. That is one that I don't want to sleep on that. I don't want to say, "That'll be fine. I'll just have other people make the decision." No, I need to get better at making decisions, making decisions with less information or more rapidly, having a bias towards action. All those things I think will be deeply beneficial. So I'm trying to really lean into that. Whereas yeah, again, the sales stuff I'm like, yeah, and there's plenty of examples of this otherwise.

+ +

But I've also been coding a bit more this week, which has been lovely because the hiring stuff has ramped down. And that has freed me up amongst some other stuff that's been going on. And you know, I like to code, it turns out. It's fun. I just clack about on my cherry brown keys, and it's great.

+ +

STEPH: Do you remember when we first got introduced to mechanical keyboards, and we had co-ownership of one of the keyboards? And we literally had days of where it was like your turn to use the keyboard. And then it was my turn to use the keyboard. How long did we keep that up before we were finally like, we should just buy our own keyboards?

+ +

CHRIS: It was a while because we were working with a colleague who was trying out a Kinesis, I want to say, one of the split little bowl of keys. But yeah, we had a shared custody over a keyboard, and it was fantastic. I remember that very fondly.

+ +

STEPH: The days that it was my keyboard, I would go to the office and be like, oh, today is my day at the keyboard. This is great. This is going to be such a wonderful day. [laughs] And now I'm just spoiled.

+ +

CHRIS: It went on for a while, though. And this was something where we both obviously enjoy this keyboard. Why don't we just buy one of these keyboards? We totally could have done that. And yet, for some reason, both of us were like, no, but what if...I got to think about this. Again, decisiveness. [laughs] We come back to this topic of well; I had to really think about it. And then somebody got the 92-Key test or whatever it was in the office. And so I just went over and poked every one of those for a while.

+ +

STEPH: Exactly. It was option overload where we're like, well, okay, we're going to buy one, and then you open it up and search, and you're like, oh, you want options? We have options. Do you know about the blues, and the browns, and the colors, and these different options? Like, I don't know any of this language that you're talking about. I just want to clackety-clack. So yeah, it took time. We had to do our research.

+ +

CHRIS: And then I ended up on basic browns. So here we are. Let's see, popping back up the stack a couple of levels, hiring that went on for a while. Now it is less going on. Although to be clear, like I said, always be hiring. So if anyone out there in the world is hearing what I'm talking about with Sagewell or seeing any of the stuff that I'm putting on Twitter, which isn't much, I occasionally just post screenshots of my commit messages, which recently included better snakes as a commit message. [laughs] I have to dig into that or not. But we were just doing some snake case to camel case conversion. But the commit message was better snake, so here we are.

+ +

Anyway, if any of that sounds interesting, please do reach out. But I'm excited to transition back to focusing more on the work. On that note, actually, I'm going to call it interesting things that is happening right now organizationally is; we are working with an external security firm to help with some...they helped us out with a penetration test when we needed that. And then they have stayed on retainer and are helping with various different configurations, taking our AWS S3 buckets and making sure those are nice and secure, and all that kind of stuff.

+ +

But we've recently started to focus more on organizational security, specifically a bowl of acronyms. We've got SSO for single sign-on, MDM for something device management. I don't know what that first M is. I probably should learn it, but it's fine. That's why I've got help on this is I think they know what the acronym stands for. But so we're working on each of those.

+ +

And on the one hand, they're probably going to be kind of annoying, like having to go through the single sign-on. It's a whole thing, and it's harder to sign into stuff sometimes. I mean, ideally, it's actually easier. But in my experience, it adds some friction at some points. And then MDM means that there's now some profile manager on the computer. So I can say like, "Every computer must have full disk encryption or else you can't use it. And we need a passcode, and it must be this long and those sorts of things." So it's organizational controls that I think are good for us having a robust security setup throughout the organization.

+ +

But yeah, they're the sort of things that I think historically, I probably would have, as someone working in an organization, had been like, do we have to? Do we need these things? Couldn't I just do whatever? But now there's something about it that I really like. I'm trying to name it in my head, but I'm kind of like, I don't know. This feels like growing up as an organization.

+ +

And there's always weird corollary that I've been thinking about with the Rails app that we've been building, intimately familiar with just everything that's going into it. And I know the vast majority of lines of code. I haven't written them all, but I've had an eye on all of the different features that we're building in.

+ +

And it's hard to get out of that headspace where it feels like a bunch of pieces. It doesn't feel like a hole to me, even though it definitely is. But when does a bunch of boards that you nail together become a boat? To make a really weird analogy because that's what I do; it's a hobby of mine. But when does that transition happen? At some point, certainly. But that's harder for me to see on the code side.

+ +

And organizationally, somehow getting these things in place feels like the organization sort of an inflection point for us, a growth point, which is I'm really excited about it. Even though they're probably going to mean a ton of annoying nuisance work for me because I'm the person in charge of making sure it all gets rolled out. And anytime anyone locks themselves out of an account, I have to help with that. And so it's probably just putting a bunch of annoying work on my plate. And yet, I don't know; I'm kind of excited about it.

+ +

STEPH: I feel like that shows our roots in terms of how we approach projects that we work on where you mentioned do we need this? Do we need this yet? Because I feel that we're constantly as developers and consultants just we're trying to advise on the more simplified do we need this? Is this the right thing to spend the money on? How do we know? What are the metrics? What does success look like? And all those questions.

+ +

So I feel like the way you just phrased all of that just really shows that sort of mentality that you grew up with in terms of checking in, and yeah, it's cool. Like you said, you're at a growth point where then it's like, yes, we are at this point that I've asked myself all those questions, and we're here. This feels like the right next step.

+ +

CHRIS: I like the way you described it as that you grew up with, my formative growing years at thoughtbot.

+ +

Mid-roll Ad

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Well, switching gears just a bit, we have a listener question for today, and this one comes from Stephanie. So not me, another Stephanie in the world. Hello, other Stephanie out there in the world. And they wrote in, "Hi, Steph and Chris, fellow software consultant here. And I'm wondering if you'd consider talking about how to craft a project estimate for a client on the pod. It's such an important aspect of consulting." Amen. I added the amen.

+ +

"And I feel like I'm very much impacted as a project team member when the estimate isn't accurate." Double amen. So true. [laughs] "Would appreciate any and all thoughts, especially since it might be part of my job in the future. Thanks." I just realized I put us in consultant church by adding all those amens, but here we are. [laughs]

+ +

CHRIS: I'm glad you clarified that they were additions by you and not part of the original question coming in.

+ +

STEPH: Sure. I don't want to speak on behalf of Stephanie. So I have some thoughts on the matter. I think there are a couple of different ways that we can talk about this particular question because I think there are different formats as to when you're estimating and who you're providing the estimate for. But I'm going to pause because I'd love to see what you think. How do you go about approaching crafting an estimate?

+ +

CHRIS: Sure. I'm happy to share some thoughts. And for a bit of context, this question came in to us, frankly, many months ago, but I did send an initial reply to Stephanie because I know that sometimes we take a little bit of time to get back to folks. So if ever you do send in a question, know that one of us will probably respond via email earlier, and then eventually, will make it on the show. And again, just to say, we do so appreciate when folks send in these questions. It's an interesting way to shape the conversation and a way to get topics that you're more interested in into the fold here.

+ +

But so the two main ideas that I shared in my initial reply were, first, is an estimate really necessary? I think that's a critical question because an estimate implies that this thing is knowable. And as many of us, probably all of us, have found out at some point in our lives as software developers, it's really hard to do software estimation, like wildly difficult. And not just the thing that we'll eventually get better at it, which you do, but there's just some chaos. There's some noise in this work that we do that makes it so, so difficult to get it right.

+ +

So pretty much always, I will ask, like, do we need to estimate here? What if, instead, we were to flip the whole question on its head and say, let's set a deadline. Let's say two months from now that's our deadline. And let's ruthlessly reprioritize every single week to make sure that we're building something that's meaningful, and we're getting there.

+ +

And obviously, we have to have some general idea of what we're doing. Is two months a meaningful amount of time to build a rocket to go to Mars? Probably not. But is it enough time to build an app that can allow users to sign in and manage a simple list of items? Yeah, we can definitely do that, and we can probably add a bunch of more features.

+ +

The other thing that I think is worth highlighting is there's a bunch of stuff that is table stakes and very easy to do. But I would, whenever doing estimation, emphasize unknowns. So, where are the external integrations with other systems? Where are the dependencies that rely on other folks to provide some inputs into this process that we can't be certain where there'll be?

+ +

In my experience, the places where estimates go awry are often these little intersection points that you're like, well, this will probably take a day, maybe two. And it turns out; actually, this can somehow balloon into a month. That's not a thing that feels comfortable saying in an estimation process, but it is definitely real. I've seen it happen so many times.

+ +

And so it's those unknowns. It's those little bits that I would emphasize as part of the process if you do need to do an estimate and say, all right, here's the boring stuff. I think we can do that pretty easily. But this part, I don't know, it could be a week, could be three months. And frame it in that way that there is this ambiguity there. Because if someone's asking you for an estimate and they're looking for like it is seven days and two hours exactly, it's like, well, that's not realistic. That's not how this thing works. Unfortunately, I wish it did.

+ +

But pushing back and changing the conversation is the thing that I have found valuable. I think there's some other really interesting stuff in here around the team dynamics that Stephanie is talking about. But I want to send this over to other Stephanie to see your thoughts because I'm super interested to hear what you have to say as well.

+ +

STEPH: Oh, I like how you hinted at the team dynamics. Yeah, that could be a fun one to circle back to. So I love how you called out highlighting the unknowns. There are a couple of ways that this comes to mind for me. So there's the idea of the weekly or the bi-weekly estimates that we make as developers and designers. So let's say we as a team are getting together to focus on a chunk of work and decide what we can and can't get through. And that feels one of those the more you get to practice it more frequently; you get to ask a bunch of questions. And that feels like a good rehearsal and exercise of how to go through estimates.

+ +

And I know you and I have pretty similar strong feelings around how those estimates are then treated by the company. They should really just be used for the team to talk through the complexities in the work to be done versus used to communicate outwardly as to this is when it's definitely going to ship. So there's that more immediate practice of providing estimates. And then there's the idea for more of a consultancy or a company, and someone is coming to you, so thoughtbot being a great example of then how do we work with teams that are looking to come to us and gain an estimate for getting a certain feature implemented?

+ +

So actually, I went to the source on this one. I went to Josh Clayton, who does a lot of the conversations for the Boost team when it comes to talking with clients and about the potential work that they would like to be done. And mostly our work is often teams will hire us. They have specific goals in mind, but they're really looking to hire ongoing development and services. So they really want to add to their existing staff. And then it's going to be an ongoing relationship versus a hey, we need you to quote us for how long it's going to take to implement this particular feature.

+ +

And on that note, we don't do fixed-bid work. So we don't say it's X dollars for specific features. But on the realistic side, customers are often capped by a budget. And so that estimate is very important to them because it could be a difference between it's a go versus a no go. So if you have larger companies that are like, "Yep, we want to engage with thoughtbot. We really just want additional development power and design services," that's great.

+ +

For those that are smaller, it could be an individual product owner, and they need to say, "I really want this feature, but I only have this much money. And frankly, if I can't ship it by this time, I'm not going to do it because it's not worth the investment to my company." And then, in those cases, those are the ones that we're going to spend more time with them to talk about what does the fallback plan look like? And what's our opportunity for simplifying the features?

+ +

And Josh, in particular, referenced this as systems thinking. So he will go through the idea of drawing out the set of steps, understanding the complexity of the different screens. So what are the validations? What are the external dependencies? What is owned by us and what isn't? What is the likelihood that we're going to get permission to simplify or remove complexity? And even then, when we start to provide some estimates, it's going to be in weeks. It's not in hours; it's not in days. It's going to be in a slightly larger time frame.

+ +

And then we're also going to spend more time in the discovery phase to say, okay, well, we know you need to fix this particular issue, or you need to integrate with this particular service. So we're going to need to ask a lot more questions about your codebase. What problems have you already run into? Have you tried to do this before? Do we have experience doing this? Is this something that we can lean on and ask someone in the team? And, say, how long do you think it would take for us to work on this?

+ +

And that's knowledge that isn't privy to everybody. It depends on where you're at in your career as to like, oh yeah, I've done this like five times before, and I know exactly how this stuff can fall apart. I know where the complexity lies. So I think that's why estimation is so difficult is just because it does often pull from that existing experience. And so, if you don't have that experience for a particular set of work, of course, it's going to be hard to estimate because you just don't know. So that was a very broad scope of as day-to-day developer and designers; I feel like we're constantly getting practice and estimating and communicating the progress of our work.

+ +

And then on the larger scope of if you are a consultant who's then looking to give estimates to clients, then understanding what other need can you sell them? Just ongoing development services. Or, if they are a smaller team and very focused, then what legwork can you do ahead of time to de-risk the project? And then understand how much control you're going to have to be able to simplify as you learn more as you go. Because you're going to, you're going to uncover some things, and you're going to learn some things. And what's that collaboration going to look like?

+ +

I do have one more concrete example I can provide around some of the smaller projects that we take on. So when we are helping someone that's, say, getting a new product out to market, then we do have a more deliberate three, four-phase approach where we first focus on discovery, and ideation, and validation. And then, we move on to iteration and then launching.

+ +

And I really like how you said about providing a deadline because then that helps us scope aggressively as to what is the minimum thing that we can get out into the world that will be valuable? And then there's usually some post-launch support as well. But that's often how we will structure those smaller, more specific engagements.

+ +

CHRIS: I think one of the critical things that you highlighted in there is that thoughtbot doesn't do fixed-bid work. So we're going to do these 20 features, and it's going to take four months. thoughtbot does not do that, and frankly, that's a privilege to be able to take that position and say, "No, no, no," we're not going to work that way. But it is, I think, a trade-off. It's not just something that thoughtbot does to be like, listen, that doesn't sound fun. So I'm not going to do that. It's a trade-off.

+ +

Not doing that comes in concert with saying, "But weekly, we're going to talk about the work that we have done and the work that remains and constantly, ruthlessly, reprioritize and re-decide what we're doing." And it's that engagement, the idea that you can have a body of work, look at it and say, "Yeah, that'll take about six months," and then go away for six months, and then come back with the finished software.

+ +

Our strong belief is that that's not the way good software gets built. But instead, it's a very engaged team where the product owner and the development team are in constant communication about each of the features that are being developed. And then again, ideally, on a weekly cadence, coming up for air and saying, "How are we doing? Are we moving in the right direction? Are we getting towards the goals? If not, do we need to simplify? Do we need to change things?"

+ +

And similarly, as I mentioned deadlines, I feel like deadlines is probably a word that many people think of as very bad because deadlines often come with also a fixed scope, but that can't happen. That's two constraints, and you can't have them fighting that way. But a deadline can be super useful as a way to say we're going to put something out there in the future and say we're heading towards that moment. And let's, again, cut scope. Let's change what we're building, et cetera.

+ +

But critically, not say, "We got a deadline and a fixed scope. We're going to do that." And so it's, again, just ways to gently shift the conversation around and say, what if we were to look at this from a different angle? Because just having a pile of work and saying, "That'll take six months," I've never seen that play out.

+ +

STEPH: Yeah, to me, deadline is a bad word when the deadline is set by a team that's not doing the work. So if you have leadership or if you have someone else that is setting this deadline and then just passing that down to someone else to then fulfill, regardless of the feedback or how things are going, then yeah, then it can be a nasty thing, which I think is a little bit of in that question that you picked up on that you highlighted where there could be some interesting team dynamics that Stephanie called out, highlighting that I'm very much impacted as a project team member when the estimate isn't accurate.

+ +

And I'm making some assumptions here because I don't actually know the exact situation that Stephanie is experiencing. But it sounds like someone else externally is setting these team estimates. And so then you're handed this deadline, and then stuff goes wrong, but you're still pressured to meet this deadline. And I've certainly been part of projects that are like that.

+ +

And then that is one of the number one things that then often comes up in a retro or like, we don't have control over these deadlines, or we don't know why these deadlines are being set. And then people are working extra hours and working nights and weekends to then meet this arbitrary deadline that none of us signed up for, and that's just not fair to treat deadlines in that way.

+ +

So full-heartedly agree that deadlines can be a very positive thing, but they need to be set by the people doing the work. And then there has to be discussions and updates about how is this going? Do we have control to simplify this? We thought we could do this with this particular external provider. It turns out that that's a nightmare. Is there another provider we can go with? Can we ship this incrementally? Like some features, you can't. They may have to go out wholesale. But is there a small chunk of this that we can deliver that is then a success that leadership and others can brag about? And then we can keep working on the rest of it.

+ +

So it's always identifying what are the smallest wins, and how do we get there and getting buy-in from the team? Going back to something that you said earlier around, it is a privilege, where so as thoughtbot, we don't do fixed-bid work. And that is a nice thing for us to be able to focus on. But for people who do need to do fixed bid work and are relying on that, I think that often requires more legwork. And maybe that becomes part of your estimate. I'm just making up how I might approach this if I were trying to do fixed bid work.

+ +

But there's a discovery phase that's very important. So maybe the first part of your estimate is I need to really understand the feature and see the different screens and know what materials we do or don't have. What does the codebase look like? Do I feel like this is a codebase that I can work quickly in? And is it going to be hindersome for me? But answering a lot of those questions to then help me paint a picture of, like, okay, this is a feature that I've implemented before, so I feel pretty confident that I could do this in a month.

+ +

And then also communicating that this is my estimate but just know it's an estimate. And I will continue to update you each day as to how things are going or each week as to how things are going, and things may adjust. And we can always talk about ways about simplifying this. But I think that's how I would go about it is; frankly, it's going to require more legwork for me to feel more confident as to then telling someone as to how long I think the work will take.

+ +

I think that's a nice, broad scope of the different types of estimate work to be done with the general idea of if you can avoid estimates and go for more frequent updates, then that's wonderful. But then, if you are forced into a corner where you need to provide an update, then just do as much research and honesty as possible and then still include the frequent updates.

+ +

CHRIS: Yeah, that I think summarizes it quite well.

+ +

STEPH: As a side note, it's been a lot of fun to feel like I'm referring to myself as a third person as Stephanie is working through this problem. So that's been novel. But yeah, thank you, Stephanie, for the great question. I hope that was helpful. On that note, Shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+LTa_yARL + + ]]> + + Chris Toomey + Steph Viccari + + + 326: Dongle Life + https://bikeshed.thoughtbot.com/326 + b438e700-3d61-4137-9d1a-f02f40dab85b + Tue, 15 Feb 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Chris is making hiring progress and loves asdf and M1 laptops. Steph is anticipating the arrival of one dongle to rule them all and talks about moving away from having a lot of Bluetooth connections. + +Two other big things on Steph's mind are education around factories because they're v important and shared examples and how they can be overused. She and Chris agree that it is better to tell stories in tests instead. + 41:02 + no + + + Chris is making hiring progress and loves asdf and M1 laptops. Steph is anticipating the arrival of one dongle to rule them all and talks about moving away from having a lot of Bluetooth connections. +Two other big things on Steph's mind are education around factories because they're v important and shared examples and how they can be overused. She and Chris agree that it is better to tell stories in tests instead. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. +GitHub - asdf-vm/asdf: Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more (https://github.com/asdf-vm/asdf) +Factories Should be the Bare Minimum (https://thoughtbot.com/blog/factories-should-be-the-bare-minimum) +Mystery Guest (https://thoughtbot.com/blog/mystery-guest) +GitHub - varvet/pundit: Minimal authorization through OO design and pure Ruby classes (https://github.com/varvet/pundit) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed. [laughs] +CHRIS: Hello, and I'm singing, and I love singing. +STEPH: It's Buddy the Elf; what's your favorite color? [laughter] For reals, here we go. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris. What's new in your world? +CHRIS: My world continues to be focused on hiring as a pretty core aspect of things. We have happily had one offer extended and accepted, so that's great. We've got a person who will be joining the team in a couple of weeks. That's very exciting. And we're continuing in conversations with some other folks. +So I look forward to the place where I can be on the other side of this and have that team and be growing the team and not having to focus because hiring takes a lot of effort. It is something that I believe should be done as well as possible and intentionally as possible and then just outreach and all that. So yeah, I'll be fine with being on the other side of that. But it's going well, so that is nice. +STEPH: That's awesome that you're making progress. Once you have hired your team, will you then add to the agenda to hire someone to help with hiring? +CHRIS: I don't actually know if the organization, if the whole company has someone who's focused on hiring. I think that can make sense. Working through recruiters and things like that is something that I've seen in the past. I've seen it work for certain organizations. +I've also been on the receiving end of plenty of obviously copy and pasted very generic "Hey, person, I saw that you do lots of Java and other enterprise code software. Would you like to come work with us?" I'm like, none of those are true, and I do not want to go work with you. But thanks, I still appreciate the outreach. [laughs] So I am intrigued to see how we think about it. +More generally, this is something that you and I have talked about offline but the idea that you kind of always want to be hiring. We do have specific roles that we've identified that the budget has space for. But more generally, ideally, we're going to need to hire more people down the road, and that will happen at a particular point. But having those conversations, starting to talk to people, now planting the idea of like, hey, you're great, and I would love to work with you someday and just keeping those lines of communication open. +Networking is perhaps what the people call it. I don't know; I've never felt super comfortable with that word, but I think it's that and being friendly and staying connected with people whose work I respect and would love to work with more. So that's part of what I will come out of this with is yeah, let's always be hiring in a certain sense. +STEPH: I'm glad you expanded on it because I was just thinking I have specific ideas as to what always be hiring means to me and what those activities would include. So I was curious what it means to you. And I agree, I think it's a lot of networking. It's a lot of taking chats and social chats with folks and just talking about the company and finding out where they're at. And then one day, if it works out that then they want to make a shift, then you've already got that relationship that started, and they're already potentially interested in your team. +I guess some of the other big stuff that comes to mind, too, is like thoughtbot we have the blog. I feel like that's always really helpful too. Like when you help somebody, when you publish information that then helps them in their career, I feel like that will then draw people towards you as well. +CHRIS: Yeah, the thoughtbot blog and basically everything that thoughtbot does, the podcast here, or Upcase, or all those things were so incredibly helpful in the hiring. But I also know they're hard to spin up, is what I would say. The thoughtbot blog has I don't even know how many hundreds of thousands of hours maybe. It's weird to try and put a number to it. +But I've written a handful of posts for it, and I'm not great at writing them. They take me way longer than they should, but they took many hours. And then I had wonderful peer review by other developers at thoughtbot. And so, the amount of effort that goes into the thoughtbot blog absolutely produces wonderful benefits. But it's not free by any means, and similarly, the podcasts or Upcase or any of those sort of things. +Similarly, the one that's actually most interesting that I see a lot of organizations go for initially and then often walk back is open source. Like, oh, we have this internal library that we built to do something. What we'll do is we'll just package it up and share it with the world, and then it'll be great. +And the maintenance burden and support necessity of an open-source project is so high. I've actually historically gotten into the mode of suggesting...when I was working with clients, they would start to mention this and be like, "Oh yeah, we think we'll open source this thing, and it'll be great." I'm like, "Are you sure, though? Do you definitely want to?" +There's definitely a difference between open sourcing and just putting an idea out there is one thing that I would say. Can you just write a blog post that has code snippets but not reusable code that you have to maintain that people, unfortunately, I think unfairly expect responsiveness and maintenance over time? And what if you stopped using that technology? What if you stop using this thing, but your name is still attached to it? And people have expectations of what that looks like. +Or people come in and say, "Hey, this is great, but I want to change it in this way." And you're like, "Yeah, but that actually doesn't work for us. That's not how we use it. But we would be on the hook to maintain that code if we accept your pull request." And so, as wonderful as open source is, I tend to be on the more conservative end of the spectrum of like, are you definitely sure you want to open source this? Is there another way that you can share this with the world? Can it be a conference talk, or a blog post, or something like that? But it is an interesting one. +STEPH: Yeah, I've been a part of several teams that have started with that; let's start an engineering blog. And their hearts are totally in the right place, and I understand why they want to do it. But like you just said, there's a cost to that. And if you don't have something like thoughtbot has like an investment day or a time for engineers to then be able to contribute to that blog, then either they're just not because they're not going to have their downtime to be able to do that. And it is hard to write and publish and be happy with what you're going to publish with the world. +I really like what you're talking about in terms of the maintenance burden because I can't remember if it was an Upcase conversation or if there was something...but I was early on at thoughtbot and had a similar thought of why can't we just open source it? Why can't we make it public? And there was a very big thoughtful discussion around well, we have to have all these considerations in place. Who's going to maintain it? +Just like FactoryBot is a really big internal project at thoughtbot. And there's typically a rotation of folks who will then take ownership and then onboard other people who are interested in it and curate the issues. And it's very important work, but you have to allocate time for it. All of that to say, I totally agree. There's a big burden that goes with it. +CHRIS: Yeah, it's interesting that this has been an evolving thought in my head, and it makes me sad is another thing I'll say about it. I wish it were easier to just put code out there in the world and have the expectations properly calibrated for like, hey, I did this thing. Here's a code sample. It worked for me. +Actually, I found dropping something in a Gist...a Gist just has a point-in-time connotation to it that I like. Like, if I see a code sample in a Gist, I'm like, I have no expectation that that person is going to do anything or respond to anything I have to say. But this is great because I now have this sample code that helps me get a little bit further. +And I may have to vendor that code or take it on myself, and I now own it. It's not this person's responsibility. But the minute you have a repo with a README that says stuff and like, here are the installation instructions, the expectations just flip in a way that I don't think is...at least I become cautious around. And that does make me sad, though. +STEPH: Yeah, it feels like you went from offering an example to I'm offering a product. And so then as soon as people feel like, oh, you're giving me something as a product that you maintain, then I'm going to have higher expectations of it should work how I expected it to work. I'm going to ask questions. And yeah, you make a lot of good points. +CHRIS: Would you like to pay me $0 for me to build software for you? That sounds fun. +STEPH: [laughs] +CHRIS: And open source is such a wonderful thing. And so I'm interested in...like, I follow a lot of folks who are in the open-source world and have found ways to make it make sense financially or otherwise or organizationally. Open Collective and things like that is one option or OpenCore and then paid pro models and things like that like Sidekiq as an example. Sidekiq just celebrated ten years with some wild numbers in terms of the revenue, and it's like, yeah, that's fantastic. This is a cornerstone piece of software in the Ruby and Rails community. And also, Mike Perham had a great outcome from it. I think that's a win. +So maybe blogging, maybe, but not sure. Probably not open source is my suggestion, at least for me. But one thing that I am interested in that hasn't been an option in my mind for a long time, but I'd love to get back to is conferences and going there, especially with a small team from an organization. The three developers we go, and we hang out at a conference and the company has a space there. And there's room to have conversations and meet people. That is one that I would love to continue in a way of making sure that our name is in people's minds as a place that they could work in this world. +It is interesting, though, that it gets scoped a little bit like we are definitely a Rails shop. But that's not all that we are, or that's not the complete totality of our technical identity, so it becomes interesting. But I think it's probably the most representative. And I definitely see the Ruby and Rails community is having a good product-centric mindset that is definitely the sort of thing that I want in the teams that I'm building. +STEPH: Yeah, I think that's an awesome idea because it's a way that you could focus on creating content. It'll likely have a big impact. But then you can also replay that content, but it's not the commitment of a blog or a commitment of open source. +CHRIS: But yeah, so hiring has been, I would say, most of what I've been doing. One other thing that was fun this week, so I have my new laptop that I've had now for a couple of months, I'd say. And just this week, we had a very frustrating issue where Heroku stopped deploying our application. Just one day, it was like, nah, it doesn't work anymore. And I was like, well, that's less cool than I want it to be. +And so one of the developers on the team dug into it, and it turned out Node-sass was the answer, which we're not even using is extra unpleasant. It's just part of Sprockets and Webpack or something like that. There's some downstream dependency sequence. We're using Tailwind and PostCSS. So we don't even need Node-sass. I think maybe PostCSS does. +But anyway, turns out Heroku had switched to using version 16 of Node just without telling us. We were previously on 14, and then Node-sass didn't build on that. There was just this weird dependency chain that stopped working one day. And we weren't pinning the Node version within our application. So one of the developers figured this out, pinned us back to version 14 something of Node, and that was fine. But then my computer got confused because the versions were out of sync. +Anyway, asdf is great. That's the first thing I'm going to say. So I use asdf to manage the versions of Ruby, and Node, and Yarn, and Elm, and basically everything else that I use. And I love that it's all under one hood, so asdf, wonderful. Also, my laptop, wonderful. I really love the M1 fancy laptop. But what was fun was I had to install the new Node version. +And this was the first time in the three months I've had this computer that I've heard the fans come on. Finally, I asked it to do something hard enough that it was like, whoa, whoa, whoa, I'm going to need some backup here. And so the fans finally kicked in. So I don't know what's going on installing Node, but good for everyone involved, [laughter] impressive to make such aggressive use of all of the hardware in my computer. +STEPH: Yeah, I love asdf. I miss it right now because I'm on my client machine, and we're not using asdf. Instead, we are using Chruby, C-H Ruby to manage Ruby versions. asdf is awesome. That's fun. It's the first time that the fans kicked on. I'm intrigued with my machine. I haven't really paid attention to it when the fans kick on except the one time where I had like a Ruby process that was running away, and I had to figure out what was going on there. Because then all the CPU was just being dedicated to Ruby even when I wasn't using Ruby. But since then, I haven't heard the fans. It's been very, very quiet. It's lovely. I like when it's quiet. +CHRIS: Oh, it's been great. It was interesting because it was this weird noise that I'd forgotten about. +STEPH: [laughs] +CHRIS: My previous computer was so old that this was happening regularly whenever my backup process would run. Apparently, that is a very computationally intensive activity. So I would hear the fans kick in, immediately go find the backup process and say pause for 60 minutes or whatever it was. Just like, leave me alone. Stop it. The computer is getting too hot. You need to calm down. But now, with the new computer, there was nothing I could do to make it happen. And then finally it happened, and I was like, oh yeah, I guess this computer has fans. That's neat. But yeah, so things that are great, asdf and the M1 laptops. +STEPH: Nice. Yeah, you're one of the few individuals I know that's using one of the M1 chip. So it's been reassuring to hear how well it's going because I did not opt in to that new-new. I opted in to the give me something stable and steady that I know so that way I don't have to fuss with it because I can then fuss with all the other things that I need to fuss about. +CHRIS: So much fussing to do. +STEPH: Lots of fussing. Fussing and cussing is what I do over here. +CHRIS: [laughs] +Mid-roll ad +Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. +So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. +That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. +So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's New Relic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. +CHRIS: Well, speaking of, what have you been fussing and cussing about this week, Steph? +STEPH: So this is more in the pranting area, which is our portmanteau for praise and rant, where I'm super excited. I have a delivery coming from Amazon today. So I'm that person that keeps checking and waiting for it to show up. But I'm finally going to have one dongle to rule them all. +I have a very messy approach right now [laughs] where I have all the dongles and have to plug everything in. And you know what? Normally it's fine. It's fine because I do it once, and I don't have to mess with it that much. But because I now have my thoughtbot laptop and I have a client laptop, and I needed to be able to switch back and forth, it is just too much. And I was realizing how many dongles I'm having to use. So I have one dongle to rule them all. It's showing up today. It's a very exciting day. +CHRIS: I'm very excited for you. I recently made a similar switch when I got this new laptop. I was like, you know what? I'm going to look into it because power can come over USB-C and whatnot. And I was like, all right, it's finally time. I want to be able to just click in. And it's one of those things that feels trivial, or at least in my mind, I'm like, this doesn't feel like it'll make that big of a difference. +But it makes it so much easier to disconnect my laptop, go somewhere else, and then come back. And I noticed myself doing that more, which I think is a positive thing. Otherwise, I'm just anchored to my desk. I'm like, I don't want to unplug everything and then have to replug it. That's like a whole thing. But now that it's not, I am more mobile, more flexible in where I'm working from, and I found benefits from that. So I'm a fan. I'm very happy that this is going to show up for you [laughs] and really change the way you're working. +STEPH: Well, I've started moving away from a lot of Bluetooth connections as well because my keyboard will support Bluetooth, my headphones support Bluetooth. And I liked the idea of being wireless. But then, especially from switching laptops back and forth and then having to reconnect and all of it, it was just too tedious to go back and forth. +And yeah, I'm with you where I didn't want to have to leave my desk and unplug everything and then bring it back where I'm playing, you know, like the game Operation where you had to reach in and then you had to grab different little bones? If you don't know the game Operation, that sounds really weird. But it felt like a game of Operation where then I was having to find all the dongles and connect them and plug them all in. And yeah, so it's going to be wonderful. +CHRIS: Even knowing the game Operation, that still sounds kind of weird. +STEPH: [laughs] +CHRIS: But I really love that there are people out there listening that are like, what are they talking about? +STEPH: What weird childhood did you have? +CHRIS: Yeah, I'm definitely Team Wired-Almost-Everything. The only thing that I have that's wireless is my headphones. And it only works kind of, and I have to trick them sometimes. And the worst thing is occasionally my computer will have control, whatever, they're connected. So I'm listening to music on my computer and then suddenly, my phone will just steal it. It's like, what are you doing? No. +Or, randomly, my headphones will be sitting away from me, and they'll just connect. And I'll be in the middle of a call on something else. Like, I'm here talking to you, and suddenly my headphones are like, hey, we wanted to join the party. It's like no, absolutely not, [laughs] not at this moment, under no circumstances. So I don't really believe in Bluetooth as a technology. I'm very much a fan, particularly with things like keyboards and whatnot. Bluetooth I've yet to be convinced that it is a sound technology. +STEPH: I have the headphones where they try to be very smart, and they are pretty smart where they will block out sound. But then, if I am talking, then it will put me in more of an auditory space where then I can more easily hear, and it won't filter out sound as aggressively. But I've noticed a problem. And it's when I'm watching anything that's funny that then I'm laughing. +So every time I laugh, my headphones think I'm talking to someone, and then it will switch over to where it's trying to let me hear more sounds out in the universe. And then it kicks back on because it's like, okay, she's done talking. It's a very jarring experience. [laughs] And I haven't figured out how to turn that setting off. It's like, oh, I just can't watch funny stuff with my headphones right now, which is also problematic with pairing because I tend to laugh a lot with pairing. It's a thing. I'm working on it. The struggles of Shteph. +CHRIS: Well, at a minimum, it sounds like your dongle life is going to be improving very soon, and that's exciting. +STEPH: Dongle life, it'll be single dongle life. That's it. [singing] All the single dongles, all the single dongles. Put your adapters up. [laughter] On a different note, talking about some of the work that I've been doing this past week with Joël Quenneville on our client work, is that we have been looking for ways that we still want to build up CI time. We’ve talked about the fact that we're working on some of that horizontal scaling. And I don't have an update there. +But the other update I have is where we want to be very strategic about where we invest our time because improving the test is not trivial work. A lot of the low-hanging fruit has already been done, so triaging a flaky test can be very difficult, and it can take us a while. So we just want to make sure and verify that before we invest a lot of time into a portion of the test that then we know what the outcome is going to be. Are we improving developers' lives by this much? And how do we measure that? Are we reducing the CI build time, and how do we know that? +And one of the areas that I really wanted to focus on is FactoryBot because there are a lot of factories. The factories tend to do a ton. So they are calling out to the database and building a lot of associations. And that's something that the team knows about as well is that there are just so many SQL queries that get executed in tests. And it would be great if we could reduce the number of SQL queries that are going out. +And FactoryBot includes some ActiveSupport notifications, which means you can subscribe to factories being run which then gives you access to details like which factories are being used? What build strategy is used? Are you calling build build_stubbed or create? And the factory’s execution time. +So then the idea of this is that if we can harness a lot of the data that we can collect from FactoryBot, then can we ask questions around what's our slowest factory? How long does it take, and how many places is it being called? Because then ideally, we can calculate to say, okay, if this factory takes this long and it's used in this number of places, then we can have a formula to figure out how many minutes of our test suite is spent just on executing that factory. +And then if we can reduce the time of that factory, let's say by half, then we know how much time we're shaving off of our CI build. And then we have this more concrete verified okay; this is worth our investment. We want to pursue this, even if the factory may take us a full day to improve because it does so much. And it's just gnarly. So it's going to take some time to really refactor it into a more simplified state. So, in theory, this sounds really, really great, and it was a lot of thanks to Josh Clayton, who was the one that advocated saying that we could use the ActiveSupport notifications to find a lot of this data. +And so Josh and I paired on this for a bit to look into can we answer some of those other questions as well? And we were testing it on a small side project that he had, which was great because the other codebase is very big, and feedback is just a lot slower. So we wanted to first prototype it and have a proof of concept in a very quick space and just to be able to look through the data and make sure the assumptions that we had and the value would be there. So we applied that first, and that was going really well. +And then Joël Quenneville took that strategy and then applied it to all the specs in the spec models directory and ran it for the much larger client codebase and got some really great results. And we also used a low fidelity approach where we wanted to be able to see which factories were the most popular. So how often are they getting called? And the average execution time. So that way, we could then quickly look at this scatter plot, and then we could see, okay, who's in the far upper right quadrant? Because those are the factories that are causing the most pain. +But we started looking into a graphing library and what are we going to pull in. And Josh had the great idea. He's like, "I wonder if Google Sheets has a scatter plot. Can we export this to CSV data and then copy it from the terminal and import it into Google Sheets?" And it turns out that you can. So then we grabbed it and put it in Google Sheets and then just converted it into a scatter plot, which was really nice because then we didn't have to incorporate any chart library or any graphics or anything. We could just plop it into Google Sheets and then easily share it. +So we now have this list thanks to Joël because he ran it through the spec models directory of all the factories that are getting called. And it's really interesting. And there's one, in particular, that is high on the list. And it was actually one of the first ones that we worked with when we were troubleshooting a test that took us a while when we first joined the project. And the average time for this factory is four seconds, and it gets called over 500 times. It's like 527 times. So then if we multiply that, so if we say, all right, it takes about 4 seconds times 527 and then divide it for 60 for minutes, that's 35 minutes, 35 minutes for that factory. +Now, granted, these are getting parallelized across different processes. But still, if you divide that up across four processes, that's a non-trivial amount of time. So I think this is going to be really helpful and really interesting data that we can then use to drive our decisions to say, okay, we want to take this factory and let's say even if we can cut it into half, let's say if we bring it from 4 seconds to 2 seconds, it'll go from 35 minutes to 17 and a half. +CHRIS: Oh wow, I love the methodical approach. I love that actually having a number you're like; this is how much pain or the cost of this right now. And so we've identified that this is this high-level thing. I love the intentional starting with, like, let's measure it. Let's understand where the most bang for the buck is. +In particular, the graph that you're describing reminds me of one I haven't actually worked with it much. But Code Climate has a graph that they use, which is it's churn versus complexity. So it's like, you may have a very complex piece of your code, but someone wrote it once, and it just sits in the corner. And you know what? It quietly does its job. And yes, it's very complex, but nobody needs to touch it. So it's not a big deal. +And then you have stuff that changes constantly, but it's super simple, so that's fine too. Your UsersController is probably going to change a bunch; that's fine. But the stuff that is constantly changing and very complex that's the magic quadrant that, like, pay a lot of attention to that. And similarly, which are the ones that are being used a lot and take a while? That's the magic quadrant. I'm intrigued now. I want to search for more magic quadrants that deserve attention. But for now, that sounds like a lot of fun. +So now, what's the approach that you're going to take? I imagine you need to alias that factory and have it exist because some tests will rely on certain details of it. This is my guess. So let me see if this is the way that you're thinking about it, alias the factory, so you have a representation that does all the stuff that the current one does. But then you have a new one that is much more pared down. +And then, on a test by test basis, you start switching it over and trying to move things to the lower weight, the slimmer version of the factory. But I would think you would want to do a gradual process if there are 520-ish usages. Because otherwise, just changing that factory out from under all the tests, I imagine you'd break some tests if you just were like, what if it did less? +STEPH: Yeah, I like that idea of the incremental approach. And that all sounds great, especially the alias because you're right; we want to change it incrementally and not all of them at once. But then essentially implement, one, because I want to see what does the pared-down factory look like? What is the basic factory that we can get away with? And then how long does it take for that factory to execute? Because then that will help confirm, can we really get it down to two seconds? Or is this just a factory that's always going to take three and a half seconds, and then it's not really that much of a payoff? Maybe we should look for a different factory to investigate. +And then also understanding from the test are people reaching for this factory all the time because it builds up the world and all of these tests need the full world? Or are people just reaching for this because it does the one or two things that they need, and we can get away with a much slimmer factory? So right now, it's in the space of understanding why are people reaching for this? What are the tests they actually need? And yeah, how can we do it incrementally? +At one point, we may even be able to try to programmatically switch it out. Maybe we just find 50 tests that are using this once we have the slimmed-down version and we replace...50 is probably too big. But if we replace X number of tests with this factory, how many of them fail? Maybe 10% of them passed. Cool, let's just take those 10% as a win and issue those as a PR. So that could be a strategy as well just to find if there's any that are super easy to change. All we had to do is literally change the name of the factory. +The other big part that's on my mind is education around factories. I think a lot of people on the team understand that factories are very important. They can be very helpful. They can also be very cumbersome. But it feels like a good opportunity to say, "Hey, we are specifically working on these factories. Here's the reasoning that led us to work on these factories. +When you're in the space of factories, please be mindful about what are you reaching for? Is there a slimmed-down factory that you can reach for? Maybe you can implement your own slimmed-down factory if one doesn't already exist." So I like the idea of coupling it with also just broader awareness because we are but two people. So I would love for more people to be part of the changes. +CHRIS: Unsurprisingly, there are some wonderful blog posts on the thoughtbot blog that speak to this topic. One that I'm a fan of is Factories Should be the Bare Minimum. This was written by Matt Sumner. And it describes basically that idea of factories shouldn't build the worlds. They should give you the pieces that you can use to build the world but not build the world entirely. And so I'm a big believer in that, having your factories be as minimal as possible. They should be valid, but that's about it. +And then I will often reach for extracted helper methods and keeping those as locally scoped as possible often in the spec file, or if not, maybe they're sharing spec support. But being intentional with where we reach for them and not having everyone use the same thing that just slowly gets added to. And it's like, do I actually need everything that's in there? +The other thing that's interesting is the idea of having a factory that does a ton is, in my mind, sort of in direct contradiction to what I believe factories exist for which is when I think of factories, they're useful to fill in the rest of the details such that you don't have mystery guests in your test. +But you can explicitly say build me a user who has an email that looks like this because, in this test, I care about the email, but I don't care about the rest of the details. I don't care about their name. I don't care about their password, or the roles, or any of the other details. Just let the factory deal with that because it's not important to the test. But I want to make sure that the relevant detail is present and specified within the spec. +If you have a factory that builds everything in the world, that's like build a user and then grabs the first action from the project that that user has, because I know that they do because they use the big factory, that is just in direct contradiction to what we want factories to do. We want tests to tell their story. We want to avoid mystery guests. Factories are a great way to do that while still remaining concise. But if your factories just build the world, then there are some mystery guests in the world, I can assure you. +STEPH: Yeah, I agree where factories have served as an abstraction for what I think is important to the test. But then there becomes this moment of where someone thinks, well, I need to build up these records, but I don't really need to reference them directly. I just have some coupled code that's going to rely on these. And so I don't explicitly need them, but they need to be there. So I'm going to extract it away, and a factory feels like a good place for me to extract that too. +And I would take the very hard opposite approach where if you have coupled code and you have these dependencies that aren't necessarily explicitly used in the test, but they are required for the test, I'd rather see a painful test setup than have all of that extracted away from me. Because then if I do need to triage or troubleshoot that test, it's going to take a lot of just mental overhead to work through what do I actually need here and why? So I'd rather see that painful test set up then have it moved somewhere else. +But I think a lot of people take the opposite approach of where if I abstracted away, my test looks prettier. And I'm like, yeah, but maybe to you in the moment, but it's going to cause me a lot of pain further down the road when I have to work with this. So show me all the crap that you had to do upfront. Just let me know. [laughs] I'd rather the test be honest with me. +And then it's a really nice jumping-off point because you can see a test that does all of this. And instead of blaming the test and thinking it's the test's fault, you recognize this test has a lot of complicated setup, and it's probably because of the code and how the code was written. And we should look at refactoring the code, not at how can we make our tests look prettier? +CHRIS: Unsurprisingly, I agree with 100% of that. Someday we'll find things other than Pop-Tarts and IPAs that we disagree on. But today is not that day. [laughs] Once again, today is not that day. +Mid-roll Ad +Hi, friends. And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, and memory bloat. +Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. +And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: Well, here's one more that maybe you'll agree with, maybe you won't. We'll see. I'll try not to lead you in either direction, but shared examples. If I'm going to rant for a little bit, shared examples are in that space of where they just get used so heavily, and they abstract away important information about the test. And it makes the test so succinct that I don't actually know what the test is doing. +And I've seen a number of places where a shared example has been extracted, and it is only used within that test file once, maybe twice. And I'm just like, friends, too much abstraction. Please keep it close. [laughs] We don't need to move it away. We want our test to be friendly and just full of context, which is what I mean when I say friendly. I want full of context is what I'm looking for, well-named variables. And I won't be able to read the test and see what's happening. +So my little complaint for today would also be about shared examples and how they can be overused. And they do have a really neat purpose. They can be helpful for if you're testing maybe a controller action and you want to say you're extracting that authentication, making sure that a controller always has authentication and then that is getting included. Sure, that feels very helpful. But that's really one of the few cases I can think of where a shared example comes into play. +And if you are testing code over and over throughout different parts of your codebase, there's probably a part of your codebase there that needs to then be pulled out into a class and test that class in isolation. And then you don't need to retest it throughout all of your other classes. Have I already ranted about shared examples? I can't recall at this point if I have or not. [laughs] +CHRIS: I don't think we have talked about shared examples before. And I appreciate you not leading the witness here. But I think I'm in agreement with you, particularly the way you refined it there at the end because that controller example is the one rare case where I might reach for it. But in general, I think this is one of those things that I saw early on in my career. I was like, oh, cool; this is a way to clean stuff up and DRY and all those wonderful things. And then I've definitely felt the pain of just overuse of shared examples and ways to pull details out of tests. But it's like, I want to see the details. +And I think broadly, that's the theme that you and I are very aligned on is like, no, no, no, tell me the story in tests. I am much less interested in having these concise tests that have a single line, and it's like, expect foo to have bar. And it's like, why? Because...oh, there's a let and then a subject, and it's a shared...oh okay. Now that I can put it together, I can tell the story, but I cannot look at this test and see a story. I want to see a story, friends. So yes, I'm totally in alignment, especially with the slight caveat at the end of like, there are cases where it's useful. +Similarly, I've used let. I definitely have not even that long ago. And I stand by the usage, but it was very rare. It's very rare, and it is something that I'll look at and be like, am I sure? Definitely, is this the right thing, or did I do something wrong? Because if I find myself leaning towards let, it's like there's something that I don't think is important to the story of this test that still needs to happen. Why is that? What's going on here? Something feels off about that. And similarly, with the shared examples, it's like, is there not a different way to extract this such that I can test it in a way that I have confidence in, and then we're good? +I occasionally will talk myself into using shared examples or something like it where I'm like, oh, but it's really important that everything in the app has that authentication layer put in. And so, I should definitely have this very easily reusable test that can ensure that I have it. But there's a tautology there of well, if I write the test, then I'm definitely thinking about the implementation. But if I forget the implementation, I might also forget the test. And so, it actually doesn't provide any real safety. +And in those cases, that's a rare case where I would reach for some weird metaprogramming thing that's like, controllers must do the thing. And we say that in application control and then everything inherited from that will raise if it doesn't implement the authentication layer. Something like weird code that says, "You shall not pass. You must, in fact, implement the authentication layer." Rather than saying, "Oh, we'll just make it really easy to test it so that we always test and, therefore, always use the necessary authentication layer." But yeah, that's a hard one to describe in the radio. So I don't know if that came through clearly. But that's sort of my headspace on this. +STEPH: Yeah, and all of that makes sense. I'm trying to think of a good example. And it's been a while since I've used Pundit, but I feel like Pundit may have a really good example of this where it's very easy to document to say, hey, all of these controllers need to make sure that they call out to this class or that there's authentication. I can't remember the exact code and how that works. But I feel like Pundit has a really good example of that behavior. +CHRIS: I think they do. It's something where I think it's a configuration level thing, but you say, "Hey, Pundit, we should definitely authorize any access to models." And so Pundit then has a before action, or it's an around filter one of those. But it will raise an unauthorized error, I want to say. Like, you did not do the authorization dance in this. And that's a great example of like, I like that it is loud and annoying and in your face. +And it is not possible for me to forget it because we configured it throughout all controllers. And so it's that sort of thing that I would probably reach for even though that code gets complicated and messy, and actions at a distance. But it's worth that trade-off in my mind to have, like, I don't want to forget to do the authorization stuff. Permissions matter. +STEPH: That was a really nice pre-emptive approach as well. Because in most cases that we're describing, it's the I'm going to write a controller, and then I need to add this test to verify and prove that yes, I didn't forget the authentication stuff versus upfront, you're setting in a configuration to say, "Hey, please remind me to do the configuration or the authentication step that I don't miss this." So that's also a really, really nice approach. +CHRIS: Yeah, the same version of me that's going to forget to write the test is going to forget to write the implementation. So I don't want to trust that version of me to save that version of me. I'm equally untrustworthy in those situations. +STEPH: You want to trust the version of you that's going to get yelled at by the code if you don't do it. +CHRIS: Yep, I'm going to trust the version of me that was like, I don't trust any future version of me. I will yell at myself if I have not done the necessary things. +STEPH: [laughs] +CHRIS: To be clear, this is like a life philosophy of mine. I don't try to remember things because I forget stuff a lot. It just happens. And so if I need to take something out the door with me, it goes in front of the door but extra critically, and this is the subtle line. Because plenty of people do that trick where you put a thing in front of the door because then you can't leave without it. There's no way to forget it. But by virtue of that, you cannot put something in front of the door until it is time to use it. +Like, if ever you have to go and be like, oh, I don't need it now, though, so I'm going to move it out of the way, open the door, and then leave. No, no, no, because then you've broken the magic of the thing in front of the door must leave with you. So it's a very subtle line. I will play games with myself. I'll be like, I am forgetful. I will not remember this. I do not trust future me, so I'm going to play a trick on them. But you got to calibrate it just right. +STEPH: That's really funny because I totally [laughs] didn't think about it until now how you described it. But I have definitely done that where I set a rule for myself, but then I'll break it. And then, of course, everything all of it collapses. There is a time when Tim, my husband, was going through a developer bootcamp. And as he was learning the whole world and everything that's out there, he would ask me all these questions. And he's like, "Do you know this?" And I'd be like, "No." He's like, "Do you know that?" I was like, "No." +He was like, "I thought you knew this stuff." He's like, "I thought this was your job." And I was like, "Yeah, I'm really good at finding it and Googling it. But I work really hard to not store this in short-term memory because I'm filling it up with other stuff. So I work really hard to be able to find this stuff and track it and Google it." +But now, there's a lot of stuff that I try very hard to not hold on to until I need it. But that was a funny moment where he seemed very upset that I didn't know stuff. And I was like, "Well, welcome to web development. There is too much to know. You're going to have to have a really good catalog system." +CHRIS: Also, just so we're clear, it's going to change by next Thursday, so don't hang on to anything like it's just true forever. +STEPH: [laughs] +CHRIS: SQL will probably be around. That's about it. That's the one thing that I'm really confident in. +STEPH: Yeah, that feels fair. Get really good at understanding HTTP forms, SQL, all that feels like some really good groundwork. +CHRIS: There are some foundations. We should have a foundations episode where we talk about what we think the foundations are, the stuff that we bet won't be different in 10 years. But everything else is going to change by next Thursday, specifically. +STEPH: Yeah, I like the idea of foundations. I'd be intrigued to see what we talk about and what happens there because I feel like that's going to be very representative of already what we talk about. We often will sprinkle in some new-new, especially thanks to a lot of the adventures that you go on. But I feel like a lot of the stuff that we talk about we always bring it back to the foundation because we do want the experiences that we're having to be applicable to everyone else as well. So yeah, that would be interesting to see what comes out of that. +On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeee!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris is making hiring progress and loves asdf and M1 laptops. Steph is anticipating the arrival of one dongle to rule them all and talks about moving away from having a lot of Bluetooth connections.

+ +

Two other big things on Steph's mind are education around factories because they're v important and shared examples and how they can be overused. She and Chris agree that it is better to tell stories in tests instead.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed. [laughs]

+ +

CHRIS: Hello, and I'm singing, and I love singing.

+ +

STEPH: It's Buddy the Elf; what's your favorite color? [laughter] For reals, here we go.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris. What's new in your world?

+ +

CHRIS: My world continues to be focused on hiring as a pretty core aspect of things. We have happily had one offer extended and accepted, so that's great. We've got a person who will be joining the team in a couple of weeks. That's very exciting. And we're continuing in conversations with some other folks.

+ +

So I look forward to the place where I can be on the other side of this and have that team and be growing the team and not having to focus because hiring takes a lot of effort. It is something that I believe should be done as well as possible and intentionally as possible and then just outreach and all that. So yeah, I'll be fine with being on the other side of that. But it's going well, so that is nice.

+ +

STEPH: That's awesome that you're making progress. Once you have hired your team, will you then add to the agenda to hire someone to help with hiring?

+ +

CHRIS: I don't actually know if the organization, if the whole company has someone who's focused on hiring. I think that can make sense. Working through recruiters and things like that is something that I've seen in the past. I've seen it work for certain organizations.

+ +

I've also been on the receiving end of plenty of obviously copy and pasted very generic "Hey, person, I saw that you do lots of Java and other enterprise code software. Would you like to come work with us?" I'm like, none of those are true, and I do not want to go work with you. But thanks, I still appreciate the outreach. [laughs] So I am intrigued to see how we think about it.

+ +

More generally, this is something that you and I have talked about offline but the idea that you kind of always want to be hiring. We do have specific roles that we've identified that the budget has space for. But more generally, ideally, we're going to need to hire more people down the road, and that will happen at a particular point. But having those conversations, starting to talk to people, now planting the idea of like, hey, you're great, and I would love to work with you someday and just keeping those lines of communication open.

+ +

Networking is perhaps what the people call it. I don't know; I've never felt super comfortable with that word, but I think it's that and being friendly and staying connected with people whose work I respect and would love to work with more. So that's part of what I will come out of this with is yeah, let's always be hiring in a certain sense.

+ +

STEPH: I'm glad you expanded on it because I was just thinking I have specific ideas as to what always be hiring means to me and what those activities would include. So I was curious what it means to you. And I agree, I think it's a lot of networking. It's a lot of taking chats and social chats with folks and just talking about the company and finding out where they're at. And then one day, if it works out that then they want to make a shift, then you've already got that relationship that started, and they're already potentially interested in your team.

+ +

I guess some of the other big stuff that comes to mind, too, is like thoughtbot we have the blog. I feel like that's always really helpful too. Like when you help somebody, when you publish information that then helps them in their career, I feel like that will then draw people towards you as well.

+ +

CHRIS: Yeah, the thoughtbot blog and basically everything that thoughtbot does, the podcast here, or Upcase, or all those things were so incredibly helpful in the hiring. But I also know they're hard to spin up, is what I would say. The thoughtbot blog has I don't even know how many hundreds of thousands of hours maybe. It's weird to try and put a number to it.

+ +

But I've written a handful of posts for it, and I'm not great at writing them. They take me way longer than they should, but they took many hours. And then I had wonderful peer review by other developers at thoughtbot. And so, the amount of effort that goes into the thoughtbot blog absolutely produces wonderful benefits. But it's not free by any means, and similarly, the podcasts or Upcase or any of those sort of things.

+ +

Similarly, the one that's actually most interesting that I see a lot of organizations go for initially and then often walk back is open source. Like, oh, we have this internal library that we built to do something. What we'll do is we'll just package it up and share it with the world, and then it'll be great.

+ +

And the maintenance burden and support necessity of an open-source project is so high. I've actually historically gotten into the mode of suggesting...when I was working with clients, they would start to mention this and be like, "Oh yeah, we think we'll open source this thing, and it'll be great." I'm like, "Are you sure, though? Do you definitely want to?"

+ +

There's definitely a difference between open sourcing and just putting an idea out there is one thing that I would say. Can you just write a blog post that has code snippets but not reusable code that you have to maintain that people, unfortunately, I think unfairly expect responsiveness and maintenance over time? And what if you stopped using that technology? What if you stop using this thing, but your name is still attached to it? And people have expectations of what that looks like.

+ +

Or people come in and say, "Hey, this is great, but I want to change it in this way." And you're like, "Yeah, but that actually doesn't work for us. That's not how we use it. But we would be on the hook to maintain that code if we accept your pull request." And so, as wonderful as open source is, I tend to be on the more conservative end of the spectrum of like, are you definitely sure you want to open source this? Is there another way that you can share this with the world? Can it be a conference talk, or a blog post, or something like that? But it is an interesting one.

+ +

STEPH: Yeah, I've been a part of several teams that have started with that; let's start an engineering blog. And their hearts are totally in the right place, and I understand why they want to do it. But like you just said, there's a cost to that. And if you don't have something like thoughtbot has like an investment day or a time for engineers to then be able to contribute to that blog, then either they're just not because they're not going to have their downtime to be able to do that. And it is hard to write and publish and be happy with what you're going to publish with the world.

+ +

I really like what you're talking about in terms of the maintenance burden because I can't remember if it was an Upcase conversation or if there was something...but I was early on at thoughtbot and had a similar thought of why can't we just open source it? Why can't we make it public? And there was a very big thoughtful discussion around well, we have to have all these considerations in place. Who's going to maintain it?

+ +

Just like FactoryBot is a really big internal project at thoughtbot. And there's typically a rotation of folks who will then take ownership and then onboard other people who are interested in it and curate the issues. And it's very important work, but you have to allocate time for it. All of that to say, I totally agree. There's a big burden that goes with it.

+ +

CHRIS: Yeah, it's interesting that this has been an evolving thought in my head, and it makes me sad is another thing I'll say about it. I wish it were easier to just put code out there in the world and have the expectations properly calibrated for like, hey, I did this thing. Here's a code sample. It worked for me.

+ +

Actually, I found dropping something in a Gist...a Gist just has a point-in-time connotation to it that I like. Like, if I see a code sample in a Gist, I'm like, I have no expectation that that person is going to do anything or respond to anything I have to say. But this is great because I now have this sample code that helps me get a little bit further.

+ +

And I may have to vendor that code or take it on myself, and I now own it. It's not this person's responsibility. But the minute you have a repo with a README that says stuff and like, here are the installation instructions, the expectations just flip in a way that I don't think is...at least I become cautious around. And that does make me sad, though.

+ +

STEPH: Yeah, it feels like you went from offering an example to I'm offering a product. And so then as soon as people feel like, oh, you're giving me something as a product that you maintain, then I'm going to have higher expectations of it should work how I expected it to work. I'm going to ask questions. And yeah, you make a lot of good points.

+ +

CHRIS: Would you like to pay me $0 for me to build software for you? That sounds fun.

+ +

STEPH: [laughs]

+ +

CHRIS: And open source is such a wonderful thing. And so I'm interested in...like, I follow a lot of folks who are in the open-source world and have found ways to make it make sense financially or otherwise or organizationally. Open Collective and things like that is one option or OpenCore and then paid pro models and things like that like Sidekiq as an example. Sidekiq just celebrated ten years with some wild numbers in terms of the revenue, and it's like, yeah, that's fantastic. This is a cornerstone piece of software in the Ruby and Rails community. And also, Mike Perham had a great outcome from it. I think that's a win.

+ +

So maybe blogging, maybe, but not sure. Probably not open source is my suggestion, at least for me. But one thing that I am interested in that hasn't been an option in my mind for a long time, but I'd love to get back to is conferences and going there, especially with a small team from an organization. The three developers we go, and we hang out at a conference and the company has a space there. And there's room to have conversations and meet people. That is one that I would love to continue in a way of making sure that our name is in people's minds as a place that they could work in this world.

+ +

It is interesting, though, that it gets scoped a little bit like we are definitely a Rails shop. But that's not all that we are, or that's not the complete totality of our technical identity, so it becomes interesting. But I think it's probably the most representative. And I definitely see the Ruby and Rails community is having a good product-centric mindset that is definitely the sort of thing that I want in the teams that I'm building.

+ +

STEPH: Yeah, I think that's an awesome idea because it's a way that you could focus on creating content. It'll likely have a big impact. But then you can also replay that content, but it's not the commitment of a blog or a commitment of open source.

+ +

CHRIS: But yeah, so hiring has been, I would say, most of what I've been doing. One other thing that was fun this week, so I have my new laptop that I've had now for a couple of months, I'd say. And just this week, we had a very frustrating issue where Heroku stopped deploying our application. Just one day, it was like, nah, it doesn't work anymore. And I was like, well, that's less cool than I want it to be.

+ +

And so one of the developers on the team dug into it, and it turned out Node-sass was the answer, which we're not even using is extra unpleasant. It's just part of Sprockets and Webpack or something like that. There's some downstream dependency sequence. We're using Tailwind and PostCSS. So we don't even need Node-sass. I think maybe PostCSS does.

+ +

But anyway, turns out Heroku had switched to using version 16 of Node just without telling us. We were previously on 14, and then Node-sass didn't build on that. There was just this weird dependency chain that stopped working one day. And we weren't pinning the Node version within our application. So one of the developers figured this out, pinned us back to version 14 something of Node, and that was fine. But then my computer got confused because the versions were out of sync.

+ +

Anyway, asdf is great. That's the first thing I'm going to say. So I use asdf to manage the versions of Ruby, and Node, and Yarn, and Elm, and basically everything else that I use. And I love that it's all under one hood, so asdf, wonderful. Also, my laptop, wonderful. I really love the M1 fancy laptop. But what was fun was I had to install the new Node version.

+ +

And this was the first time in the three months I've had this computer that I've heard the fans come on. Finally, I asked it to do something hard enough that it was like, whoa, whoa, whoa, I'm going to need some backup here. And so the fans finally kicked in. So I don't know what's going on installing Node, but good for everyone involved, [laughter] impressive to make such aggressive use of all of the hardware in my computer.

+ +

STEPH: Yeah, I love asdf. I miss it right now because I'm on my client machine, and we're not using asdf. Instead, we are using Chruby, C-H Ruby to manage Ruby versions. asdf is awesome. That's fun. It's the first time that the fans kicked on. I'm intrigued with my machine. I haven't really paid attention to it when the fans kick on except the one time where I had like a Ruby process that was running away, and I had to figure out what was going on there. Because then all the CPU was just being dedicated to Ruby even when I wasn't using Ruby. But since then, I haven't heard the fans. It's been very, very quiet. It's lovely. I like when it's quiet.

+ +

CHRIS: Oh, it's been great. It was interesting because it was this weird noise that I'd forgotten about.

+ +

STEPH: [laughs]

+ +

CHRIS: My previous computer was so old that this was happening regularly whenever my backup process would run. Apparently, that is a very computationally intensive activity. So I would hear the fans kick in, immediately go find the backup process and say pause for 60 minutes or whatever it was. Just like, leave me alone. Stop it. The computer is getting too hot. You need to calm down. But now, with the new computer, there was nothing I could do to make it happen. And then finally it happened, and I was like, oh yeah, I guess this computer has fans. That's neat. But yeah, so things that are great, asdf and the M1 laptops.

+ +

STEPH: Nice. Yeah, you're one of the few individuals I know that's using one of the M1 chip. So it's been reassuring to hear how well it's going because I did not opt in to that new-new. I opted in to the give me something stable and steady that I know so that way I don't have to fuss with it because I can then fuss with all the other things that I need to fuss about.

+ +

CHRIS: So much fussing to do.

+ +

STEPH: Lots of fussing. Fussing and cussing is what I do over here.

+ +

CHRIS: [laughs]

+ +

Mid-roll ad

+ +

Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem.

+ +

So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy.

+ +

That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software.

+ +

So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's New Relic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed.

+ +

CHRIS: Well, speaking of, what have you been fussing and cussing about this week, Steph?

+ +

STEPH: So this is more in the pranting area, which is our portmanteau for praise and rant, where I'm super excited. I have a delivery coming from Amazon today. So I'm that person that keeps checking and waiting for it to show up. But I'm finally going to have one dongle to rule them all.

+ +

I have a very messy approach right now [laughs] where I have all the dongles and have to plug everything in. And you know what? Normally it's fine. It's fine because I do it once, and I don't have to mess with it that much. But because I now have my thoughtbot laptop and I have a client laptop, and I needed to be able to switch back and forth, it is just too much. And I was realizing how many dongles I'm having to use. So I have one dongle to rule them all. It's showing up today. It's a very exciting day.

+ +

CHRIS: I'm very excited for you. I recently made a similar switch when I got this new laptop. I was like, you know what? I'm going to look into it because power can come over USB-C and whatnot. And I was like, all right, it's finally time. I want to be able to just click in. And it's one of those things that feels trivial, or at least in my mind, I'm like, this doesn't feel like it'll make that big of a difference.

+ +

But it makes it so much easier to disconnect my laptop, go somewhere else, and then come back. And I noticed myself doing that more, which I think is a positive thing. Otherwise, I'm just anchored to my desk. I'm like, I don't want to unplug everything and then have to replug it. That's like a whole thing. But now that it's not, I am more mobile, more flexible in where I'm working from, and I found benefits from that. So I'm a fan. I'm very happy that this is going to show up for you [laughs] and really change the way you're working.

+ +

STEPH: Well, I've started moving away from a lot of Bluetooth connections as well because my keyboard will support Bluetooth, my headphones support Bluetooth. And I liked the idea of being wireless. But then, especially from switching laptops back and forth and then having to reconnect and all of it, it was just too tedious to go back and forth.

+ +

And yeah, I'm with you where I didn't want to have to leave my desk and unplug everything and then bring it back where I'm playing, you know, like the game Operation where you had to reach in and then you had to grab different little bones? If you don't know the game Operation, that sounds really weird. But it felt like a game of Operation where then I was having to find all the dongles and connect them and plug them all in. And yeah, so it's going to be wonderful.

+ +

CHRIS: Even knowing the game Operation, that still sounds kind of weird.

+ +

STEPH: [laughs]

+ +

CHRIS: But I really love that there are people out there listening that are like, what are they talking about?

+ +

STEPH: What weird childhood did you have?

+ +

CHRIS: Yeah, I'm definitely Team Wired-Almost-Everything. The only thing that I have that's wireless is my headphones. And it only works kind of, and I have to trick them sometimes. And the worst thing is occasionally my computer will have control, whatever, they're connected. So I'm listening to music on my computer and then suddenly, my phone will just steal it. It's like, what are you doing? No.

+ +

Or, randomly, my headphones will be sitting away from me, and they'll just connect. And I'll be in the middle of a call on something else. Like, I'm here talking to you, and suddenly my headphones are like, hey, we wanted to join the party. It's like no, absolutely not, [laughs] not at this moment, under no circumstances. So I don't really believe in Bluetooth as a technology. I'm very much a fan, particularly with things like keyboards and whatnot. Bluetooth I've yet to be convinced that it is a sound technology.

+ +

STEPH: I have the headphones where they try to be very smart, and they are pretty smart where they will block out sound. But then, if I am talking, then it will put me in more of an auditory space where then I can more easily hear, and it won't filter out sound as aggressively. But I've noticed a problem. And it's when I'm watching anything that's funny that then I'm laughing.

+ +

So every time I laugh, my headphones think I'm talking to someone, and then it will switch over to where it's trying to let me hear more sounds out in the universe. And then it kicks back on because it's like, okay, she's done talking. It's a very jarring experience. [laughs] And I haven't figured out how to turn that setting off. It's like, oh, I just can't watch funny stuff with my headphones right now, which is also problematic with pairing because I tend to laugh a lot with pairing. It's a thing. I'm working on it. The struggles of Shteph.

+ +

CHRIS: Well, at a minimum, it sounds like your dongle life is going to be improving very soon, and that's exciting.

+ +

STEPH: Dongle life, it'll be single dongle life. That's it. [singing] All the single dongles, all the single dongles. Put your adapters up. [laughter] On a different note, talking about some of the work that I've been doing this past week with Joël Quenneville on our client work, is that we have been looking for ways that we still want to build up CI time. We’ve talked about the fact that we're working on some of that horizontal scaling. And I don't have an update there.

+ +

But the other update I have is where we want to be very strategic about where we invest our time because improving the test is not trivial work. A lot of the low-hanging fruit has already been done, so triaging a flaky test can be very difficult, and it can take us a while. So we just want to make sure and verify that before we invest a lot of time into a portion of the test that then we know what the outcome is going to be. Are we improving developers' lives by this much? And how do we measure that? Are we reducing the CI build time, and how do we know that?

+ +

And one of the areas that I really wanted to focus on is FactoryBot because there are a lot of factories. The factories tend to do a ton. So they are calling out to the database and building a lot of associations. And that's something that the team knows about as well is that there are just so many SQL queries that get executed in tests. And it would be great if we could reduce the number of SQL queries that are going out.

+ +

And FactoryBot includes some ActiveSupport notifications, which means you can subscribe to factories being run which then gives you access to details like which factories are being used? What build strategy is used? Are you calling build build_stubbed or create? And the factory’s execution time.

+ +

So then the idea of this is that if we can harness a lot of the data that we can collect from FactoryBot, then can we ask questions around what's our slowest factory? How long does it take, and how many places is it being called? Because then ideally, we can calculate to say, okay, if this factory takes this long and it's used in this number of places, then we can have a formula to figure out how many minutes of our test suite is spent just on executing that factory.

+ +

And then if we can reduce the time of that factory, let's say by half, then we know how much time we're shaving off of our CI build. And then we have this more concrete verified okay; this is worth our investment. We want to pursue this, even if the factory may take us a full day to improve because it does so much. And it's just gnarly. So it's going to take some time to really refactor it into a more simplified state. So, in theory, this sounds really, really great, and it was a lot of thanks to Josh Clayton, who was the one that advocated saying that we could use the ActiveSupport notifications to find a lot of this data.

+ +

And so Josh and I paired on this for a bit to look into can we answer some of those other questions as well? And we were testing it on a small side project that he had, which was great because the other codebase is very big, and feedback is just a lot slower. So we wanted to first prototype it and have a proof of concept in a very quick space and just to be able to look through the data and make sure the assumptions that we had and the value would be there. So we applied that first, and that was going really well.

+ +

And then Joël Quenneville took that strategy and then applied it to all the specs in the spec models directory and ran it for the much larger client codebase and got some really great results. And we also used a low fidelity approach where we wanted to be able to see which factories were the most popular. So how often are they getting called? And the average execution time. So that way, we could then quickly look at this scatter plot, and then we could see, okay, who's in the far upper right quadrant? Because those are the factories that are causing the most pain.

+ +

But we started looking into a graphing library and what are we going to pull in. And Josh had the great idea. He's like, "I wonder if Google Sheets has a scatter plot. Can we export this to CSV data and then copy it from the terminal and import it into Google Sheets?" And it turns out that you can. So then we grabbed it and put it in Google Sheets and then just converted it into a scatter plot, which was really nice because then we didn't have to incorporate any chart library or any graphics or anything. We could just plop it into Google Sheets and then easily share it.

+ +

So we now have this list thanks to Joël because he ran it through the spec models directory of all the factories that are getting called. And it's really interesting. And there's one, in particular, that is high on the list. And it was actually one of the first ones that we worked with when we were troubleshooting a test that took us a while when we first joined the project. And the average time for this factory is four seconds, and it gets called over 500 times. It's like 527 times. So then if we multiply that, so if we say, all right, it takes about 4 seconds times 527 and then divide it for 60 for minutes, that's 35 minutes, 35 minutes for that factory.

+ +

Now, granted, these are getting parallelized across different processes. But still, if you divide that up across four processes, that's a non-trivial amount of time. So I think this is going to be really helpful and really interesting data that we can then use to drive our decisions to say, okay, we want to take this factory and let's say even if we can cut it into half, let's say if we bring it from 4 seconds to 2 seconds, it'll go from 35 minutes to 17 and a half.

+ +

CHRIS: Oh wow, I love the methodical approach. I love that actually having a number you're like; this is how much pain or the cost of this right now. And so we've identified that this is this high-level thing. I love the intentional starting with, like, let's measure it. Let's understand where the most bang for the buck is.

+ +

In particular, the graph that you're describing reminds me of one I haven't actually worked with it much. But Code Climate has a graph that they use, which is it's churn versus complexity. So it's like, you may have a very complex piece of your code, but someone wrote it once, and it just sits in the corner. And you know what? It quietly does its job. And yes, it's very complex, but nobody needs to touch it. So it's not a big deal.

+ +

And then you have stuff that changes constantly, but it's super simple, so that's fine too. Your UsersController is probably going to change a bunch; that's fine. But the stuff that is constantly changing and very complex that's the magic quadrant that, like, pay a lot of attention to that. And similarly, which are the ones that are being used a lot and take a while? That's the magic quadrant. I'm intrigued now. I want to search for more magic quadrants that deserve attention. But for now, that sounds like a lot of fun.

+ +

So now, what's the approach that you're going to take? I imagine you need to alias that factory and have it exist because some tests will rely on certain details of it. This is my guess. So let me see if this is the way that you're thinking about it, alias the factory, so you have a representation that does all the stuff that the current one does. But then you have a new one that is much more pared down.

+ +

And then, on a test by test basis, you start switching it over and trying to move things to the lower weight, the slimmer version of the factory. But I would think you would want to do a gradual process if there are 520-ish usages. Because otherwise, just changing that factory out from under all the tests, I imagine you'd break some tests if you just were like, what if it did less?

+ +

STEPH: Yeah, I like that idea of the incremental approach. And that all sounds great, especially the alias because you're right; we want to change it incrementally and not all of them at once. But then essentially implement, one, because I want to see what does the pared-down factory look like? What is the basic factory that we can get away with? And then how long does it take for that factory to execute? Because then that will help confirm, can we really get it down to two seconds? Or is this just a factory that's always going to take three and a half seconds, and then it's not really that much of a payoff? Maybe we should look for a different factory to investigate.

+ +

And then also understanding from the test are people reaching for this factory all the time because it builds up the world and all of these tests need the full world? Or are people just reaching for this because it does the one or two things that they need, and we can get away with a much slimmer factory? So right now, it's in the space of understanding why are people reaching for this? What are the tests they actually need? And yeah, how can we do it incrementally?

+ +

At one point, we may even be able to try to programmatically switch it out. Maybe we just find 50 tests that are using this once we have the slimmed-down version and we replace...50 is probably too big. But if we replace X number of tests with this factory, how many of them fail? Maybe 10% of them passed. Cool, let's just take those 10% as a win and issue those as a PR. So that could be a strategy as well just to find if there's any that are super easy to change. All we had to do is literally change the name of the factory.

+ +

The other big part that's on my mind is education around factories. I think a lot of people on the team understand that factories are very important. They can be very helpful. They can also be very cumbersome. But it feels like a good opportunity to say, "Hey, we are specifically working on these factories. Here's the reasoning that led us to work on these factories.

+ +

When you're in the space of factories, please be mindful about what are you reaching for? Is there a slimmed-down factory that you can reach for? Maybe you can implement your own slimmed-down factory if one doesn't already exist." So I like the idea of coupling it with also just broader awareness because we are but two people. So I would love for more people to be part of the changes.

+ +

CHRIS: Unsurprisingly, there are some wonderful blog posts on the thoughtbot blog that speak to this topic. One that I'm a fan of is Factories Should be the Bare Minimum. This was written by Matt Sumner. And it describes basically that idea of factories shouldn't build the worlds. They should give you the pieces that you can use to build the world but not build the world entirely. And so I'm a big believer in that, having your factories be as minimal as possible. They should be valid, but that's about it.

+And then I will often reach for extracted helper methods and keeping those as locally scoped as possible often in the spec file, or if not, maybe they're sharing spec support. But being intentional with where we reach for them and not having everyone use the same thing that just slowly gets added to. And it's like, do I actually need everything that's in there?

+ +

The other thing that's interesting is the idea of having a factory that does a ton is, in my mind, sort of in direct contradiction to what I believe factories exist for which is when I think of factories, they're useful to fill in the rest of the details such that you don't have mystery guests in your test.

+ +

But you can explicitly say build me a user who has an email that looks like this because, in this test, I care about the email, but I don't care about the rest of the details. I don't care about their name. I don't care about their password, or the roles, or any of the other details. Just let the factory deal with that because it's not important to the test. But I want to make sure that the relevant detail is present and specified within the spec.

+ +

If you have a factory that builds everything in the world, that's like build a user and then grabs the first action from the project that that user has, because I know that they do because they use the big factory, that is just in direct contradiction to what we want factories to do. We want tests to tell their story. We want to avoid mystery guests. Factories are a great way to do that while still remaining concise. But if your factories just build the world, then there are some mystery guests in the world, I can assure you.

+ +

STEPH: Yeah, I agree where factories have served as an abstraction for what I think is important to the test. But then there becomes this moment of where someone thinks, well, I need to build up these records, but I don't really need to reference them directly. I just have some coupled code that's going to rely on these. And so I don't explicitly need them, but they need to be there. So I'm going to extract it away, and a factory feels like a good place for me to extract that too.

+ +

And I would take the very hard opposite approach where if you have coupled code and you have these dependencies that aren't necessarily explicitly used in the test, but they are required for the test, I'd rather see a painful test setup than have all of that extracted away from me. Because then if I do need to triage or troubleshoot that test, it's going to take a lot of just mental overhead to work through what do I actually need here and why? So I'd rather see that painful test set up then have it moved somewhere else.

+ +

But I think a lot of people take the opposite approach of where if I abstracted away, my test looks prettier. And I'm like, yeah, but maybe to you in the moment, but it's going to cause me a lot of pain further down the road when I have to work with this. So show me all the crap that you had to do upfront. Just let me know. [laughs] I'd rather the test be honest with me.

+ +

And then it's a really nice jumping-off point because you can see a test that does all of this. And instead of blaming the test and thinking it's the test's fault, you recognize this test has a lot of complicated setup, and it's probably because of the code and how the code was written. And we should look at refactoring the code, not at how can we make our tests look prettier?

+ +

CHRIS: Unsurprisingly, I agree with 100% of that. Someday we'll find things other than Pop-Tarts and IPAs that we disagree on. But today is not that day. [laughs] Once again, today is not that day.

+ +

Mid-roll Ad

+ +

Hi, friends. And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Well, here's one more that maybe you'll agree with, maybe you won't. We'll see. I'll try not to lead you in either direction, but shared examples. If I'm going to rant for a little bit, shared examples are in that space of where they just get used so heavily, and they abstract away important information about the test. And it makes the test so succinct that I don't actually know what the test is doing.

+ +

And I've seen a number of places where a shared example has been extracted, and it is only used within that test file once, maybe twice. And I'm just like, friends, too much abstraction. Please keep it close. [laughs] We don't need to move it away. We want our test to be friendly and just full of context, which is what I mean when I say friendly. I want full of context is what I'm looking for, well-named variables. And I won't be able to read the test and see what's happening.

+ +

So my little complaint for today would also be about shared examples and how they can be overused. And they do have a really neat purpose. They can be helpful for if you're testing maybe a controller action and you want to say you're extracting that authentication, making sure that a controller always has authentication and then that is getting included. Sure, that feels very helpful. But that's really one of the few cases I can think of where a shared example comes into play.

+ +

And if you are testing code over and over throughout different parts of your codebase, there's probably a part of your codebase there that needs to then be pulled out into a class and test that class in isolation. And then you don't need to retest it throughout all of your other classes. Have I already ranted about shared examples? I can't recall at this point if I have or not. [laughs]

+ +

CHRIS: I don't think we have talked about shared examples before. And I appreciate you not leading the witness here. But I think I'm in agreement with you, particularly the way you refined it there at the end because that controller example is the one rare case where I might reach for it. But in general, I think this is one of those things that I saw early on in my career. I was like, oh, cool; this is a way to clean stuff up and DRY and all those wonderful things. And then I've definitely felt the pain of just overuse of shared examples and ways to pull details out of tests. But it's like, I want to see the details.

+ +

And I think broadly, that's the theme that you and I are very aligned on is like, no, no, no, tell me the story in tests. I am much less interested in having these concise tests that have a single line, and it's like, expect foo to have bar. And it's like, why? Because...oh, there's a let and then a subject, and it's a shared...oh okay. Now that I can put it together, I can tell the story, but I cannot look at this test and see a story. I want to see a story, friends. So yes, I'm totally in alignment, especially with the slight caveat at the end of like, there are cases where it's useful.

+ +

Similarly, I've used let. I definitely have not even that long ago. And I stand by the usage, but it was very rare. It's very rare, and it is something that I'll look at and be like, am I sure? Definitely, is this the right thing, or did I do something wrong? Because if I find myself leaning towards let, it's like there's something that I don't think is important to the story of this test that still needs to happen. Why is that? What's going on here? Something feels off about that. And similarly, with the shared examples, it's like, is there not a different way to extract this such that I can test it in a way that I have confidence in, and then we're good?

+ +

I occasionally will talk myself into using shared examples or something like it where I'm like, oh, but it's really important that everything in the app has that authentication layer put in. And so, I should definitely have this very easily reusable test that can ensure that I have it. But there's a tautology there of well, if I write the test, then I'm definitely thinking about the implementation. But if I forget the implementation, I might also forget the test. And so, it actually doesn't provide any real safety.

+ +

And in those cases, that's a rare case where I would reach for some weird metaprogramming thing that's like, controllers must do the thing. And we say that in application control and then everything inherited from that will raise if it doesn't implement the authentication layer. Something like weird code that says, "You shall not pass. You must, in fact, implement the authentication layer." Rather than saying, "Oh, we'll just make it really easy to test it so that we always test and, therefore, always use the necessary authentication layer." But yeah, that's a hard one to describe in the radio. So I don't know if that came through clearly. But that's sort of my headspace on this.

+ +

STEPH: Yeah, and all of that makes sense. I'm trying to think of a good example. And it's been a while since I've used Pundit, but I feel like Pundit may have a really good example of this where it's very easy to document to say, hey, all of these controllers need to make sure that they call out to this class or that there's authentication. I can't remember the exact code and how that works. But I feel like Pundit has a really good example of that behavior.

+ +

CHRIS: I think they do. It's something where I think it's a configuration level thing, but you say, "Hey, Pundit, we should definitely authorize any access to models." And so Pundit then has a before action, or it's an around filter one of those. But it will raise an unauthorized error, I want to say. Like, you did not do the authorization dance in this. And that's a great example of like, I like that it is loud and annoying and in your face.

+ +

And it is not possible for me to forget it because we configured it throughout all controllers. And so it's that sort of thing that I would probably reach for even though that code gets complicated and messy, and actions at a distance. But it's worth that trade-off in my mind to have, like, I don't want to forget to do the authorization stuff. Permissions matter.

+ +

STEPH: That was a really nice pre-emptive approach as well. Because in most cases that we're describing, it's the I'm going to write a controller, and then I need to add this test to verify and prove that yes, I didn't forget the authentication stuff versus upfront, you're setting in a configuration to say, "Hey, please remind me to do the configuration or the authentication step that I don't miss this." So that's also a really, really nice approach.

+ +

CHRIS: Yeah, the same version of me that's going to forget to write the test is going to forget to write the implementation. So I don't want to trust that version of me to save that version of me. I'm equally untrustworthy in those situations.

+ +

STEPH: You want to trust the version of you that's going to get yelled at by the code if you don't do it.

+ +

CHRIS: Yep, I'm going to trust the version of me that was like, I don't trust any future version of me. I will yell at myself if I have not done the necessary things.

+ +

STEPH: [laughs]

+ +

CHRIS: To be clear, this is like a life philosophy of mine. I don't try to remember things because I forget stuff a lot. It just happens. And so if I need to take something out the door with me, it goes in front of the door but extra critically, and this is the subtle line. Because plenty of people do that trick where you put a thing in front of the door because then you can't leave without it. There's no way to forget it. But by virtue of that, you cannot put something in front of the door until it is time to use it.

+ +

Like, if ever you have to go and be like, oh, I don't need it now, though, so I'm going to move it out of the way, open the door, and then leave. No, no, no, because then you've broken the magic of the thing in front of the door must leave with you. So it's a very subtle line. I will play games with myself. I'll be like, I am forgetful. I will not remember this. I do not trust future me, so I'm going to play a trick on them. But you got to calibrate it just right.

+ +

STEPH: That's really funny because I totally [laughs] didn't think about it until now how you described it. But I have definitely done that where I set a rule for myself, but then I'll break it. And then, of course, everything all of it collapses. There is a time when Tim, my husband, was going through a developer bootcamp. And as he was learning the whole world and everything that's out there, he would ask me all these questions. And he's like, "Do you know this?" And I'd be like, "No." He's like, "Do you know that?" I was like, "No."

+ +

He was like, "I thought you knew this stuff." He's like, "I thought this was your job." And I was like, "Yeah, I'm really good at finding it and Googling it. But I work really hard to not store this in short-term memory because I'm filling it up with other stuff. So I work really hard to be able to find this stuff and track it and Google it."

+ +

But now, there's a lot of stuff that I try very hard to not hold on to until I need it. But that was a funny moment where he seemed very upset that I didn't know stuff. And I was like, "Well, welcome to web development. There is too much to know. You're going to have to have a really good catalog system."

+ +

CHRIS: Also, just so we're clear, it's going to change by next Thursday, so don't hang on to anything like it's just true forever.

+ +

STEPH: [laughs]

+ +

CHRIS: SQL will probably be around. That's about it. That's the one thing that I'm really confident in.

+ +

STEPH: Yeah, that feels fair. Get really good at understanding HTTP forms, SQL, all that feels like some really good groundwork.

+ +

CHRIS: There are some foundations. We should have a foundations episode where we talk about what we think the foundations are, the stuff that we bet won't be different in 10 years. But everything else is going to change by next Thursday, specifically.

+ +

STEPH: Yeah, I like the idea of foundations. I'd be intrigued to see what we talk about and what happens there because I feel like that's going to be very representative of already what we talk about. We often will sprinkle in some new-new, especially thanks to a lot of the adventures that you go on. But I feel like a lot of the stuff that we talk about we always bring it back to the foundation because we do want the experiences that we're having to be applicable to everyone else as well. So yeah, that would be interesting to see what comes out of that.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris is making hiring progress and loves asdf and M1 laptops. Steph is anticipating the arrival of one dongle to rule them all and talks about moving away from having a lot of Bluetooth connections.

+ +

Two other big things on Steph's mind are education around factories because they're v important and shared examples and how they can be overused. She and Chris agree that it is better to tell stories in tests instead.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed. [laughs]

+ +

CHRIS: Hello, and I'm singing, and I love singing.

+ +

STEPH: It's Buddy the Elf; what's your favorite color? [laughter] For reals, here we go.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris. What's new in your world?

+ +

CHRIS: My world continues to be focused on hiring as a pretty core aspect of things. We have happily had one offer extended and accepted, so that's great. We've got a person who will be joining the team in a couple of weeks. That's very exciting. And we're continuing in conversations with some other folks.

+ +

So I look forward to the place where I can be on the other side of this and have that team and be growing the team and not having to focus because hiring takes a lot of effort. It is something that I believe should be done as well as possible and intentionally as possible and then just outreach and all that. So yeah, I'll be fine with being on the other side of that. But it's going well, so that is nice.

+ +

STEPH: That's awesome that you're making progress. Once you have hired your team, will you then add to the agenda to hire someone to help with hiring?

+ +

CHRIS: I don't actually know if the organization, if the whole company has someone who's focused on hiring. I think that can make sense. Working through recruiters and things like that is something that I've seen in the past. I've seen it work for certain organizations.

+ +

I've also been on the receiving end of plenty of obviously copy and pasted very generic "Hey, person, I saw that you do lots of Java and other enterprise code software. Would you like to come work with us?" I'm like, none of those are true, and I do not want to go work with you. But thanks, I still appreciate the outreach. [laughs] So I am intrigued to see how we think about it.

+ +

More generally, this is something that you and I have talked about offline but the idea that you kind of always want to be hiring. We do have specific roles that we've identified that the budget has space for. But more generally, ideally, we're going to need to hire more people down the road, and that will happen at a particular point. But having those conversations, starting to talk to people, now planting the idea of like, hey, you're great, and I would love to work with you someday and just keeping those lines of communication open.

+ +

Networking is perhaps what the people call it. I don't know; I've never felt super comfortable with that word, but I think it's that and being friendly and staying connected with people whose work I respect and would love to work with more. So that's part of what I will come out of this with is yeah, let's always be hiring in a certain sense.

+ +

STEPH: I'm glad you expanded on it because I was just thinking I have specific ideas as to what always be hiring means to me and what those activities would include. So I was curious what it means to you. And I agree, I think it's a lot of networking. It's a lot of taking chats and social chats with folks and just talking about the company and finding out where they're at. And then one day, if it works out that then they want to make a shift, then you've already got that relationship that started, and they're already potentially interested in your team.

+ +

I guess some of the other big stuff that comes to mind, too, is like thoughtbot we have the blog. I feel like that's always really helpful too. Like when you help somebody, when you publish information that then helps them in their career, I feel like that will then draw people towards you as well.

+ +

CHRIS: Yeah, the thoughtbot blog and basically everything that thoughtbot does, the podcast here, or Upcase, or all those things were so incredibly helpful in the hiring. But I also know they're hard to spin up, is what I would say. The thoughtbot blog has I don't even know how many hundreds of thousands of hours maybe. It's weird to try and put a number to it.

+ +

But I've written a handful of posts for it, and I'm not great at writing them. They take me way longer than they should, but they took many hours. And then I had wonderful peer review by other developers at thoughtbot. And so, the amount of effort that goes into the thoughtbot blog absolutely produces wonderful benefits. But it's not free by any means, and similarly, the podcasts or Upcase or any of those sort of things.

+ +

Similarly, the one that's actually most interesting that I see a lot of organizations go for initially and then often walk back is open source. Like, oh, we have this internal library that we built to do something. What we'll do is we'll just package it up and share it with the world, and then it'll be great.

+ +

And the maintenance burden and support necessity of an open-source project is so high. I've actually historically gotten into the mode of suggesting...when I was working with clients, they would start to mention this and be like, "Oh yeah, we think we'll open source this thing, and it'll be great." I'm like, "Are you sure, though? Do you definitely want to?"

+ +

There's definitely a difference between open sourcing and just putting an idea out there is one thing that I would say. Can you just write a blog post that has code snippets but not reusable code that you have to maintain that people, unfortunately, I think unfairly expect responsiveness and maintenance over time? And what if you stopped using that technology? What if you stop using this thing, but your name is still attached to it? And people have expectations of what that looks like.

+ +

Or people come in and say, "Hey, this is great, but I want to change it in this way." And you're like, "Yeah, but that actually doesn't work for us. That's not how we use it. But we would be on the hook to maintain that code if we accept your pull request." And so, as wonderful as open source is, I tend to be on the more conservative end of the spectrum of like, are you definitely sure you want to open source this? Is there another way that you can share this with the world? Can it be a conference talk, or a blog post, or something like that? But it is an interesting one.

+ +

STEPH: Yeah, I've been a part of several teams that have started with that; let's start an engineering blog. And their hearts are totally in the right place, and I understand why they want to do it. But like you just said, there's a cost to that. And if you don't have something like thoughtbot has like an investment day or a time for engineers to then be able to contribute to that blog, then either they're just not because they're not going to have their downtime to be able to do that. And it is hard to write and publish and be happy with what you're going to publish with the world.

+ +

I really like what you're talking about in terms of the maintenance burden because I can't remember if it was an Upcase conversation or if there was something...but I was early on at thoughtbot and had a similar thought of why can't we just open source it? Why can't we make it public? And there was a very big thoughtful discussion around well, we have to have all these considerations in place. Who's going to maintain it?

+ +

Just like FactoryBot is a really big internal project at thoughtbot. And there's typically a rotation of folks who will then take ownership and then onboard other people who are interested in it and curate the issues. And it's very important work, but you have to allocate time for it. All of that to say, I totally agree. There's a big burden that goes with it.

+ +

CHRIS: Yeah, it's interesting that this has been an evolving thought in my head, and it makes me sad is another thing I'll say about it. I wish it were easier to just put code out there in the world and have the expectations properly calibrated for like, hey, I did this thing. Here's a code sample. It worked for me.

+ +

Actually, I found dropping something in a Gist...a Gist just has a point-in-time connotation to it that I like. Like, if I see a code sample in a Gist, I'm like, I have no expectation that that person is going to do anything or respond to anything I have to say. But this is great because I now have this sample code that helps me get a little bit further.

+ +

And I may have to vendor that code or take it on myself, and I now own it. It's not this person's responsibility. But the minute you have a repo with a README that says stuff and like, here are the installation instructions, the expectations just flip in a way that I don't think is...at least I become cautious around. And that does make me sad, though.

+ +

STEPH: Yeah, it feels like you went from offering an example to I'm offering a product. And so then as soon as people feel like, oh, you're giving me something as a product that you maintain, then I'm going to have higher expectations of it should work how I expected it to work. I'm going to ask questions. And yeah, you make a lot of good points.

+ +

CHRIS: Would you like to pay me $0 for me to build software for you? That sounds fun.

+ +

STEPH: [laughs]

+ +

CHRIS: And open source is such a wonderful thing. And so I'm interested in...like, I follow a lot of folks who are in the open-source world and have found ways to make it make sense financially or otherwise or organizationally. Open Collective and things like that is one option or OpenCore and then paid pro models and things like that like Sidekiq as an example. Sidekiq just celebrated ten years with some wild numbers in terms of the revenue, and it's like, yeah, that's fantastic. This is a cornerstone piece of software in the Ruby and Rails community. And also, Mike Perham had a great outcome from it. I think that's a win.

+ +

So maybe blogging, maybe, but not sure. Probably not open source is my suggestion, at least for me. But one thing that I am interested in that hasn't been an option in my mind for a long time, but I'd love to get back to is conferences and going there, especially with a small team from an organization. The three developers we go, and we hang out at a conference and the company has a space there. And there's room to have conversations and meet people. That is one that I would love to continue in a way of making sure that our name is in people's minds as a place that they could work in this world.

+ +

It is interesting, though, that it gets scoped a little bit like we are definitely a Rails shop. But that's not all that we are, or that's not the complete totality of our technical identity, so it becomes interesting. But I think it's probably the most representative. And I definitely see the Ruby and Rails community is having a good product-centric mindset that is definitely the sort of thing that I want in the teams that I'm building.

+ +

STEPH: Yeah, I think that's an awesome idea because it's a way that you could focus on creating content. It'll likely have a big impact. But then you can also replay that content, but it's not the commitment of a blog or a commitment of open source.

+ +

CHRIS: But yeah, so hiring has been, I would say, most of what I've been doing. One other thing that was fun this week, so I have my new laptop that I've had now for a couple of months, I'd say. And just this week, we had a very frustrating issue where Heroku stopped deploying our application. Just one day, it was like, nah, it doesn't work anymore. And I was like, well, that's less cool than I want it to be.

+ +

And so one of the developers on the team dug into it, and it turned out Node-sass was the answer, which we're not even using is extra unpleasant. It's just part of Sprockets and Webpack or something like that. There's some downstream dependency sequence. We're using Tailwind and PostCSS. So we don't even need Node-sass. I think maybe PostCSS does.

+ +

But anyway, turns out Heroku had switched to using version 16 of Node just without telling us. We were previously on 14, and then Node-sass didn't build on that. There was just this weird dependency chain that stopped working one day. And we weren't pinning the Node version within our application. So one of the developers figured this out, pinned us back to version 14 something of Node, and that was fine. But then my computer got confused because the versions were out of sync.

+ +

Anyway, asdf is great. That's the first thing I'm going to say. So I use asdf to manage the versions of Ruby, and Node, and Yarn, and Elm, and basically everything else that I use. And I love that it's all under one hood, so asdf, wonderful. Also, my laptop, wonderful. I really love the M1 fancy laptop. But what was fun was I had to install the new Node version.

+ +

And this was the first time in the three months I've had this computer that I've heard the fans come on. Finally, I asked it to do something hard enough that it was like, whoa, whoa, whoa, I'm going to need some backup here. And so the fans finally kicked in. So I don't know what's going on installing Node, but good for everyone involved, [laughter] impressive to make such aggressive use of all of the hardware in my computer.

+ +

STEPH: Yeah, I love asdf. I miss it right now because I'm on my client machine, and we're not using asdf. Instead, we are using Chruby, C-H Ruby to manage Ruby versions. asdf is awesome. That's fun. It's the first time that the fans kicked on. I'm intrigued with my machine. I haven't really paid attention to it when the fans kick on except the one time where I had like a Ruby process that was running away, and I had to figure out what was going on there. Because then all the CPU was just being dedicated to Ruby even when I wasn't using Ruby. But since then, I haven't heard the fans. It's been very, very quiet. It's lovely. I like when it's quiet.

+ +

CHRIS: Oh, it's been great. It was interesting because it was this weird noise that I'd forgotten about.

+ +

STEPH: [laughs]

+ +

CHRIS: My previous computer was so old that this was happening regularly whenever my backup process would run. Apparently, that is a very computationally intensive activity. So I would hear the fans kick in, immediately go find the backup process and say pause for 60 minutes or whatever it was. Just like, leave me alone. Stop it. The computer is getting too hot. You need to calm down. But now, with the new computer, there was nothing I could do to make it happen. And then finally it happened, and I was like, oh yeah, I guess this computer has fans. That's neat. But yeah, so things that are great, asdf and the M1 laptops.

+ +

STEPH: Nice. Yeah, you're one of the few individuals I know that's using one of the M1 chip. So it's been reassuring to hear how well it's going because I did not opt in to that new-new. I opted in to the give me something stable and steady that I know so that way I don't have to fuss with it because I can then fuss with all the other things that I need to fuss about.

+ +

CHRIS: So much fussing to do.

+ +

STEPH: Lots of fussing. Fussing and cussing is what I do over here.

+ +

CHRIS: [laughs]

+ +

Mid-roll ad

+ +

Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem.

+ +

So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy.

+ +

That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software.

+ +

So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's New Relic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed.

+ +

CHRIS: Well, speaking of, what have you been fussing and cussing about this week, Steph?

+ +

STEPH: So this is more in the pranting area, which is our portmanteau for praise and rant, where I'm super excited. I have a delivery coming from Amazon today. So I'm that person that keeps checking and waiting for it to show up. But I'm finally going to have one dongle to rule them all.

+ +

I have a very messy approach right now [laughs] where I have all the dongles and have to plug everything in. And you know what? Normally it's fine. It's fine because I do it once, and I don't have to mess with it that much. But because I now have my thoughtbot laptop and I have a client laptop, and I needed to be able to switch back and forth, it is just too much. And I was realizing how many dongles I'm having to use. So I have one dongle to rule them all. It's showing up today. It's a very exciting day.

+ +

CHRIS: I'm very excited for you. I recently made a similar switch when I got this new laptop. I was like, you know what? I'm going to look into it because power can come over USB-C and whatnot. And I was like, all right, it's finally time. I want to be able to just click in. And it's one of those things that feels trivial, or at least in my mind, I'm like, this doesn't feel like it'll make that big of a difference.

+ +

But it makes it so much easier to disconnect my laptop, go somewhere else, and then come back. And I noticed myself doing that more, which I think is a positive thing. Otherwise, I'm just anchored to my desk. I'm like, I don't want to unplug everything and then have to replug it. That's like a whole thing. But now that it's not, I am more mobile, more flexible in where I'm working from, and I found benefits from that. So I'm a fan. I'm very happy that this is going to show up for you [laughs] and really change the way you're working.

+ +

STEPH: Well, I've started moving away from a lot of Bluetooth connections as well because my keyboard will support Bluetooth, my headphones support Bluetooth. And I liked the idea of being wireless. But then, especially from switching laptops back and forth and then having to reconnect and all of it, it was just too tedious to go back and forth.

+ +

And yeah, I'm with you where I didn't want to have to leave my desk and unplug everything and then bring it back where I'm playing, you know, like the game Operation where you had to reach in and then you had to grab different little bones? If you don't know the game Operation, that sounds really weird. But it felt like a game of Operation where then I was having to find all the dongles and connect them and plug them all in. And yeah, so it's going to be wonderful.

+ +

CHRIS: Even knowing the game Operation, that still sounds kind of weird.

+ +

STEPH: [laughs]

+ +

CHRIS: But I really love that there are people out there listening that are like, what are they talking about?

+ +

STEPH: What weird childhood did you have?

+ +

CHRIS: Yeah, I'm definitely Team Wired-Almost-Everything. The only thing that I have that's wireless is my headphones. And it only works kind of, and I have to trick them sometimes. And the worst thing is occasionally my computer will have control, whatever, they're connected. So I'm listening to music on my computer and then suddenly, my phone will just steal it. It's like, what are you doing? No.

+ +

Or, randomly, my headphones will be sitting away from me, and they'll just connect. And I'll be in the middle of a call on something else. Like, I'm here talking to you, and suddenly my headphones are like, hey, we wanted to join the party. It's like no, absolutely not, [laughs] not at this moment, under no circumstances. So I don't really believe in Bluetooth as a technology. I'm very much a fan, particularly with things like keyboards and whatnot. Bluetooth I've yet to be convinced that it is a sound technology.

+ +

STEPH: I have the headphones where they try to be very smart, and they are pretty smart where they will block out sound. But then, if I am talking, then it will put me in more of an auditory space where then I can more easily hear, and it won't filter out sound as aggressively. But I've noticed a problem. And it's when I'm watching anything that's funny that then I'm laughing.

+ +

So every time I laugh, my headphones think I'm talking to someone, and then it will switch over to where it's trying to let me hear more sounds out in the universe. And then it kicks back on because it's like, okay, she's done talking. It's a very jarring experience. [laughs] And I haven't figured out how to turn that setting off. It's like, oh, I just can't watch funny stuff with my headphones right now, which is also problematic with pairing because I tend to laugh a lot with pairing. It's a thing. I'm working on it. The struggles of Shteph.

+ +

CHRIS: Well, at a minimum, it sounds like your dongle life is going to be improving very soon, and that's exciting.

+ +

STEPH: Dongle life, it'll be single dongle life. That's it. [singing] All the single dongles, all the single dongles. Put your adapters up. [laughter] On a different note, talking about some of the work that I've been doing this past week with Joël Quenneville on our client work, is that we have been looking for ways that we still want to build up CI time. We’ve talked about the fact that we're working on some of that horizontal scaling. And I don't have an update there.

+ +

But the other update I have is where we want to be very strategic about where we invest our time because improving the test is not trivial work. A lot of the low-hanging fruit has already been done, so triaging a flaky test can be very difficult, and it can take us a while. So we just want to make sure and verify that before we invest a lot of time into a portion of the test that then we know what the outcome is going to be. Are we improving developers' lives by this much? And how do we measure that? Are we reducing the CI build time, and how do we know that?

+ +

And one of the areas that I really wanted to focus on is FactoryBot because there are a lot of factories. The factories tend to do a ton. So they are calling out to the database and building a lot of associations. And that's something that the team knows about as well is that there are just so many SQL queries that get executed in tests. And it would be great if we could reduce the number of SQL queries that are going out.

+ +

And FactoryBot includes some ActiveSupport notifications, which means you can subscribe to factories being run which then gives you access to details like which factories are being used? What build strategy is used? Are you calling build build_stubbed or create? And the factory’s execution time.

+ +

So then the idea of this is that if we can harness a lot of the data that we can collect from FactoryBot, then can we ask questions around what's our slowest factory? How long does it take, and how many places is it being called? Because then ideally, we can calculate to say, okay, if this factory takes this long and it's used in this number of places, then we can have a formula to figure out how many minutes of our test suite is spent just on executing that factory.

+ +

And then if we can reduce the time of that factory, let's say by half, then we know how much time we're shaving off of our CI build. And then we have this more concrete verified okay; this is worth our investment. We want to pursue this, even if the factory may take us a full day to improve because it does so much. And it's just gnarly. So it's going to take some time to really refactor it into a more simplified state. So, in theory, this sounds really, really great, and it was a lot of thanks to Josh Clayton, who was the one that advocated saying that we could use the ActiveSupport notifications to find a lot of this data.

+ +

And so Josh and I paired on this for a bit to look into can we answer some of those other questions as well? And we were testing it on a small side project that he had, which was great because the other codebase is very big, and feedback is just a lot slower. So we wanted to first prototype it and have a proof of concept in a very quick space and just to be able to look through the data and make sure the assumptions that we had and the value would be there. So we applied that first, and that was going really well.

+ +

And then Joël Quenneville took that strategy and then applied it to all the specs in the spec models directory and ran it for the much larger client codebase and got some really great results. And we also used a low fidelity approach where we wanted to be able to see which factories were the most popular. So how often are they getting called? And the average execution time. So that way, we could then quickly look at this scatter plot, and then we could see, okay, who's in the far upper right quadrant? Because those are the factories that are causing the most pain.

+ +

But we started looking into a graphing library and what are we going to pull in. And Josh had the great idea. He's like, "I wonder if Google Sheets has a scatter plot. Can we export this to CSV data and then copy it from the terminal and import it into Google Sheets?" And it turns out that you can. So then we grabbed it and put it in Google Sheets and then just converted it into a scatter plot, which was really nice because then we didn't have to incorporate any chart library or any graphics or anything. We could just plop it into Google Sheets and then easily share it.

+ +

So we now have this list thanks to Joël because he ran it through the spec models directory of all the factories that are getting called. And it's really interesting. And there's one, in particular, that is high on the list. And it was actually one of the first ones that we worked with when we were troubleshooting a test that took us a while when we first joined the project. And the average time for this factory is four seconds, and it gets called over 500 times. It's like 527 times. So then if we multiply that, so if we say, all right, it takes about 4 seconds times 527 and then divide it for 60 for minutes, that's 35 minutes, 35 minutes for that factory.

+ +

Now, granted, these are getting parallelized across different processes. But still, if you divide that up across four processes, that's a non-trivial amount of time. So I think this is going to be really helpful and really interesting data that we can then use to drive our decisions to say, okay, we want to take this factory and let's say even if we can cut it into half, let's say if we bring it from 4 seconds to 2 seconds, it'll go from 35 minutes to 17 and a half.

+ +

CHRIS: Oh wow, I love the methodical approach. I love that actually having a number you're like; this is how much pain or the cost of this right now. And so we've identified that this is this high-level thing. I love the intentional starting with, like, let's measure it. Let's understand where the most bang for the buck is.

+ +

In particular, the graph that you're describing reminds me of one I haven't actually worked with it much. But Code Climate has a graph that they use, which is it's churn versus complexity. So it's like, you may have a very complex piece of your code, but someone wrote it once, and it just sits in the corner. And you know what? It quietly does its job. And yes, it's very complex, but nobody needs to touch it. So it's not a big deal.

+ +

And then you have stuff that changes constantly, but it's super simple, so that's fine too. Your UsersController is probably going to change a bunch; that's fine. But the stuff that is constantly changing and very complex that's the magic quadrant that, like, pay a lot of attention to that. And similarly, which are the ones that are being used a lot and take a while? That's the magic quadrant. I'm intrigued now. I want to search for more magic quadrants that deserve attention. But for now, that sounds like a lot of fun.

+ +

So now, what's the approach that you're going to take? I imagine you need to alias that factory and have it exist because some tests will rely on certain details of it. This is my guess. So let me see if this is the way that you're thinking about it, alias the factory, so you have a representation that does all the stuff that the current one does. But then you have a new one that is much more pared down.

+ +

And then, on a test by test basis, you start switching it over and trying to move things to the lower weight, the slimmer version of the factory. But I would think you would want to do a gradual process if there are 520-ish usages. Because otherwise, just changing that factory out from under all the tests, I imagine you'd break some tests if you just were like, what if it did less?

+ +

STEPH: Yeah, I like that idea of the incremental approach. And that all sounds great, especially the alias because you're right; we want to change it incrementally and not all of them at once. But then essentially implement, one, because I want to see what does the pared-down factory look like? What is the basic factory that we can get away with? And then how long does it take for that factory to execute? Because then that will help confirm, can we really get it down to two seconds? Or is this just a factory that's always going to take three and a half seconds, and then it's not really that much of a payoff? Maybe we should look for a different factory to investigate.

+ +

And then also understanding from the test are people reaching for this factory all the time because it builds up the world and all of these tests need the full world? Or are people just reaching for this because it does the one or two things that they need, and we can get away with a much slimmer factory? So right now, it's in the space of understanding why are people reaching for this? What are the tests they actually need? And yeah, how can we do it incrementally?

+ +

At one point, we may even be able to try to programmatically switch it out. Maybe we just find 50 tests that are using this once we have the slimmed-down version and we replace...50 is probably too big. But if we replace X number of tests with this factory, how many of them fail? Maybe 10% of them passed. Cool, let's just take those 10% as a win and issue those as a PR. So that could be a strategy as well just to find if there's any that are super easy to change. All we had to do is literally change the name of the factory.

+ +

The other big part that's on my mind is education around factories. I think a lot of people on the team understand that factories are very important. They can be very helpful. They can also be very cumbersome. But it feels like a good opportunity to say, "Hey, we are specifically working on these factories. Here's the reasoning that led us to work on these factories.

+ +

When you're in the space of factories, please be mindful about what are you reaching for? Is there a slimmed-down factory that you can reach for? Maybe you can implement your own slimmed-down factory if one doesn't already exist." So I like the idea of coupling it with also just broader awareness because we are but two people. So I would love for more people to be part of the changes.

+ +

CHRIS: Unsurprisingly, there are some wonderful blog posts on the thoughtbot blog that speak to this topic. One that I'm a fan of is Factories Should be the Bare Minimum. This was written by Matt Sumner. And it describes basically that idea of factories shouldn't build the worlds. They should give you the pieces that you can use to build the world but not build the world entirely. And so I'm a big believer in that, having your factories be as minimal as possible. They should be valid, but that's about it.

+And then I will often reach for extracted helper methods and keeping those as locally scoped as possible often in the spec file, or if not, maybe they're sharing spec support. But being intentional with where we reach for them and not having everyone use the same thing that just slowly gets added to. And it's like, do I actually need everything that's in there?

+ +

The other thing that's interesting is the idea of having a factory that does a ton is, in my mind, sort of in direct contradiction to what I believe factories exist for which is when I think of factories, they're useful to fill in the rest of the details such that you don't have mystery guests in your test.

+ +

But you can explicitly say build me a user who has an email that looks like this because, in this test, I care about the email, but I don't care about the rest of the details. I don't care about their name. I don't care about their password, or the roles, or any of the other details. Just let the factory deal with that because it's not important to the test. But I want to make sure that the relevant detail is present and specified within the spec.

+ +

If you have a factory that builds everything in the world, that's like build a user and then grabs the first action from the project that that user has, because I know that they do because they use the big factory, that is just in direct contradiction to what we want factories to do. We want tests to tell their story. We want to avoid mystery guests. Factories are a great way to do that while still remaining concise. But if your factories just build the world, then there are some mystery guests in the world, I can assure you.

+ +

STEPH: Yeah, I agree where factories have served as an abstraction for what I think is important to the test. But then there becomes this moment of where someone thinks, well, I need to build up these records, but I don't really need to reference them directly. I just have some coupled code that's going to rely on these. And so I don't explicitly need them, but they need to be there. So I'm going to extract it away, and a factory feels like a good place for me to extract that too.

+ +

And I would take the very hard opposite approach where if you have coupled code and you have these dependencies that aren't necessarily explicitly used in the test, but they are required for the test, I'd rather see a painful test setup than have all of that extracted away from me. Because then if I do need to triage or troubleshoot that test, it's going to take a lot of just mental overhead to work through what do I actually need here and why? So I'd rather see that painful test set up then have it moved somewhere else.

+ +

But I think a lot of people take the opposite approach of where if I abstracted away, my test looks prettier. And I'm like, yeah, but maybe to you in the moment, but it's going to cause me a lot of pain further down the road when I have to work with this. So show me all the crap that you had to do upfront. Just let me know. [laughs] I'd rather the test be honest with me.

+ +

And then it's a really nice jumping-off point because you can see a test that does all of this. And instead of blaming the test and thinking it's the test's fault, you recognize this test has a lot of complicated setup, and it's probably because of the code and how the code was written. And we should look at refactoring the code, not at how can we make our tests look prettier?

+ +

CHRIS: Unsurprisingly, I agree with 100% of that. Someday we'll find things other than Pop-Tarts and IPAs that we disagree on. But today is not that day. [laughs] Once again, today is not that day.

+ +

Mid-roll Ad

+ +

Hi, friends. And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, and memory bloat.

+ +

Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend.

+ +

And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Well, here's one more that maybe you'll agree with, maybe you won't. We'll see. I'll try not to lead you in either direction, but shared examples. If I'm going to rant for a little bit, shared examples are in that space of where they just get used so heavily, and they abstract away important information about the test. And it makes the test so succinct that I don't actually know what the test is doing.

+ +

And I've seen a number of places where a shared example has been extracted, and it is only used within that test file once, maybe twice. And I'm just like, friends, too much abstraction. Please keep it close. [laughs] We don't need to move it away. We want our test to be friendly and just full of context, which is what I mean when I say friendly. I want full of context is what I'm looking for, well-named variables. And I won't be able to read the test and see what's happening.

+ +

So my little complaint for today would also be about shared examples and how they can be overused. And they do have a really neat purpose. They can be helpful for if you're testing maybe a controller action and you want to say you're extracting that authentication, making sure that a controller always has authentication and then that is getting included. Sure, that feels very helpful. But that's really one of the few cases I can think of where a shared example comes into play.

+ +

And if you are testing code over and over throughout different parts of your codebase, there's probably a part of your codebase there that needs to then be pulled out into a class and test that class in isolation. And then you don't need to retest it throughout all of your other classes. Have I already ranted about shared examples? I can't recall at this point if I have or not. [laughs]

+ +

CHRIS: I don't think we have talked about shared examples before. And I appreciate you not leading the witness here. But I think I'm in agreement with you, particularly the way you refined it there at the end because that controller example is the one rare case where I might reach for it. But in general, I think this is one of those things that I saw early on in my career. I was like, oh, cool; this is a way to clean stuff up and DRY and all those wonderful things. And then I've definitely felt the pain of just overuse of shared examples and ways to pull details out of tests. But it's like, I want to see the details.

+ +

And I think broadly, that's the theme that you and I are very aligned on is like, no, no, no, tell me the story in tests. I am much less interested in having these concise tests that have a single line, and it's like, expect foo to have bar. And it's like, why? Because...oh, there's a let and then a subject, and it's a shared...oh okay. Now that I can put it together, I can tell the story, but I cannot look at this test and see a story. I want to see a story, friends. So yes, I'm totally in alignment, especially with the slight caveat at the end of like, there are cases where it's useful.

+ +

Similarly, I've used let. I definitely have not even that long ago. And I stand by the usage, but it was very rare. It's very rare, and it is something that I'll look at and be like, am I sure? Definitely, is this the right thing, or did I do something wrong? Because if I find myself leaning towards let, it's like there's something that I don't think is important to the story of this test that still needs to happen. Why is that? What's going on here? Something feels off about that. And similarly, with the shared examples, it's like, is there not a different way to extract this such that I can test it in a way that I have confidence in, and then we're good?

+ +

I occasionally will talk myself into using shared examples or something like it where I'm like, oh, but it's really important that everything in the app has that authentication layer put in. And so, I should definitely have this very easily reusable test that can ensure that I have it. But there's a tautology there of well, if I write the test, then I'm definitely thinking about the implementation. But if I forget the implementation, I might also forget the test. And so, it actually doesn't provide any real safety.

+ +

And in those cases, that's a rare case where I would reach for some weird metaprogramming thing that's like, controllers must do the thing. And we say that in application control and then everything inherited from that will raise if it doesn't implement the authentication layer. Something like weird code that says, "You shall not pass. You must, in fact, implement the authentication layer." Rather than saying, "Oh, we'll just make it really easy to test it so that we always test and, therefore, always use the necessary authentication layer." But yeah, that's a hard one to describe in the radio. So I don't know if that came through clearly. But that's sort of my headspace on this.

+ +

STEPH: Yeah, and all of that makes sense. I'm trying to think of a good example. And it's been a while since I've used Pundit, but I feel like Pundit may have a really good example of this where it's very easy to document to say, hey, all of these controllers need to make sure that they call out to this class or that there's authentication. I can't remember the exact code and how that works. But I feel like Pundit has a really good example of that behavior.

+ +

CHRIS: I think they do. It's something where I think it's a configuration level thing, but you say, "Hey, Pundit, we should definitely authorize any access to models." And so Pundit then has a before action, or it's an around filter one of those. But it will raise an unauthorized error, I want to say. Like, you did not do the authorization dance in this. And that's a great example of like, I like that it is loud and annoying and in your face.

+ +

And it is not possible for me to forget it because we configured it throughout all controllers. And so it's that sort of thing that I would probably reach for even though that code gets complicated and messy, and actions at a distance. But it's worth that trade-off in my mind to have, like, I don't want to forget to do the authorization stuff. Permissions matter.

+ +

STEPH: That was a really nice pre-emptive approach as well. Because in most cases that we're describing, it's the I'm going to write a controller, and then I need to add this test to verify and prove that yes, I didn't forget the authentication stuff versus upfront, you're setting in a configuration to say, "Hey, please remind me to do the configuration or the authentication step that I don't miss this." So that's also a really, really nice approach.

+ +

CHRIS: Yeah, the same version of me that's going to forget to write the test is going to forget to write the implementation. So I don't want to trust that version of me to save that version of me. I'm equally untrustworthy in those situations.

+ +

STEPH: You want to trust the version of you that's going to get yelled at by the code if you don't do it.

+ +

CHRIS: Yep, I'm going to trust the version of me that was like, I don't trust any future version of me. I will yell at myself if I have not done the necessary things.

+ +

STEPH: [laughs]

+ +

CHRIS: To be clear, this is like a life philosophy of mine. I don't try to remember things because I forget stuff a lot. It just happens. And so if I need to take something out the door with me, it goes in front of the door but extra critically, and this is the subtle line. Because plenty of people do that trick where you put a thing in front of the door because then you can't leave without it. There's no way to forget it. But by virtue of that, you cannot put something in front of the door until it is time to use it.

+ +

Like, if ever you have to go and be like, oh, I don't need it now, though, so I'm going to move it out of the way, open the door, and then leave. No, no, no, because then you've broken the magic of the thing in front of the door must leave with you. So it's a very subtle line. I will play games with myself. I'll be like, I am forgetful. I will not remember this. I do not trust future me, so I'm going to play a trick on them. But you got to calibrate it just right.

+ +

STEPH: That's really funny because I totally [laughs] didn't think about it until now how you described it. But I have definitely done that where I set a rule for myself, but then I'll break it. And then, of course, everything all of it collapses. There is a time when Tim, my husband, was going through a developer bootcamp. And as he was learning the whole world and everything that's out there, he would ask me all these questions. And he's like, "Do you know this?" And I'd be like, "No." He's like, "Do you know that?" I was like, "No."

+ +

He was like, "I thought you knew this stuff." He's like, "I thought this was your job." And I was like, "Yeah, I'm really good at finding it and Googling it. But I work really hard to not store this in short-term memory because I'm filling it up with other stuff. So I work really hard to be able to find this stuff and track it and Google it."

+ +

But now, there's a lot of stuff that I try very hard to not hold on to until I need it. But that was a funny moment where he seemed very upset that I didn't know stuff. And I was like, "Well, welcome to web development. There is too much to know. You're going to have to have a really good catalog system."

+ +

CHRIS: Also, just so we're clear, it's going to change by next Thursday, so don't hang on to anything like it's just true forever.

+ +

STEPH: [laughs]

+ +

CHRIS: SQL will probably be around. That's about it. That's the one thing that I'm really confident in.

+ +

STEPH: Yeah, that feels fair. Get really good at understanding HTTP forms, SQL, all that feels like some really good groundwork.

+ +

CHRIS: There are some foundations. We should have a foundations episode where we talk about what we think the foundations are, the stuff that we bet won't be different in 10 years. But everything else is going to change by next Thursday, specifically.

+ +

STEPH: Yeah, I like the idea of foundations. I'd be intrigued to see what we talk about and what happens there because I feel like that's going to be very representative of already what we talk about. We often will sprinkle in some new-new, especially thanks to a lot of the adventures that you go on. But I feel like a lot of the stuff that we talk about we always bring it back to the foundation because we do want the experiences that we're having to be applicable to everyone else as well. So yeah, that would be interesting to see what comes out of that.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+hrijxHis + + ]]> + + Chris Toomey + Steph Viccari + + + 325: Pranting + https://bikeshed.thoughtbot.com/325 + 38e7c4b0-f0a7-4a75-9152-1c9f8300d6ad + Tue, 08 Feb 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph is super excited about changing her schedule to dedicate a full day to focus on being a great team lead. Chris talks about his continued adventures in the world of hiring. + +Together they answer a listener question about what they consider a “large” table in a database and how they review schema changes. + 35:12 + no + + + Steph is super excited about changing her schedule to dedicate a full day to focus on being a great team lead. Chris talks about his continued adventures in the world of hiring. +Together they answer a listener question about what they consider a “large” table in a database and how they review schema changes. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. +ClickHouse (https://github.com/ClickHouse/ClickHouse) +Timescale (https://www.timescale.com/) +InfluxDB (https://www.influxdata.com/) +ddl-partitioning (https://www.postgresql.org/docs/current/ddl-partitioning.html) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: I just feel like every time I listen to Celine Dion, there are lots of dramatic hand gestures that have to go with it. +CHRIS: Yep, definitely that. I'm strong team Power of Love. +STEPH: Ooh, yeah, yeah, that's a good one. +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. Oh, I have some exciting news. I am changing up my schedule. It is going to start next week, where as a team lead at thoughtbot, we have been working on finding ways that we can have more time to invest into the team and team-specific initiatives. And most of us spend four days billing on client work, and then we have investment day, which is delightful. +But we're finding as team leads, that's really not enough time to then have the impact that we want in terms of supporting our team and then also having time for mentorship and all the other things that go along with being a team lead and one on ones. So we have been incrementally working towards reducing billing. +So team leads only bill three days a week, and then they have an additional day to really focus on being a great team lead. And I start that new schedule, that new-new schedule next week, and I couldn't be more excited. I think it's going to be wonderful. +I do think there are some challenges that go with it in terms of really balancing, at least this is from the others who have gone before me where they then find it a bit harder in terms of client expectations of saying, "Well, I was billing four days, and I had a larger impact on the codebase and the team. Now I'm dropping to three days. I still need to stay within that constraint. And I want to keep the client team happy." So that seems to be a thing. But I will find out next week how it goes. +CHRIS: Well, I'm very excited for you. That sounds wonderful, frankly. The balancing of the client expectations and then there's sort of now three slices to your work, which there always were, but now you have it delineated in an interesting way. Do you have specific plans for the team lead? So let's say now, nominally, there's one day a week that is dedicated to team lead time. Do you have ideas of what that looks like? Are you planning to pair with your team? Is it longer one on ones? I don't want to seed the question too much with potential answers. So what are you thinking about there? +STEPH: [laughs] Ideas are great. And yes, so I think number one is structure. So right now, one on ones and any support that I need to provide others is more ad hoc, or at least the one on ones those are not ad hoc; they are structured. But they are spread out throughout the week, and then I just context switch between client work and then checking in with others. +Now I can stagger everything on a Thursday or whichever day is going to be my really focused team lead day. So that way, I have all the one on ones on that day. And then yes, I can have more time to pair. So I can say, hey, let's just schedule every other week where you and I hang out, and we pair for an hour, and it can be on their client work. It can be on anything that they'd like to work on. Or, if there's a particular topic they'd like to talk about, we can pair on consulting issues or discussions. +But yes, ultimately, I'd love to do more pairing and then structure one on ones to a specific day and essentially, just really protect that time. Because right now, it feels that client initiatives and work always come first, and then team lead comes second. And I'm excited to balance that more so they have equal priority. +CHRIS: Yeah, that sounds great. I'm super intrigued to see what specific structures fall out of it and how you're experiencing it. I'll be interested to hear how investment time changes for you as a result of this because I remember when I started in the management role, four days a week billing, and then one day a week of investment time. But the investment time then basically went to one on ones and other things like that. +And when I switched to a three-day week, I was able to reclaim some amount of investment time. And it was interesting having that open back up and have that be a consideration. Because definitely one on ones and things like that I think firmly fit within the idea of investment time or investing in the organization and whatnot. But still, there's the like; I'm going to go explore a new framework or something like that that also certainly fits within investment time. So I'll be interested to hear if you find that changes in sort of a specific way. +STEPH: Yeah, I'm really interested in that as well. Because right now, as you mentioned, my investment activities are really focused more around the team and other folks and then Bike Shed. Bike Shed is a really big investment time activity. So I've noticed since becoming a co-host for the show, I talk a lot about code, but I don't necessarily contribute to open-source projects or other internal projects at the rate that I used to. It's now more focused about here and being a co-host and talking about all the things, and that requires some prep for me. +So I'm also interested to see if this will shift my investment time a bit where I do find a little more time to code and then explore just things that I'm interested in. But in the experiment of doing something new, it's always important to then have a way to measure is this a good change? Is this a bad change? So we have been checking in with team leads to say, "Hey, we've changed your schedule to where you're billing one day less. How's that going for you?" Because there's the assumption that this will be great, but you really have to check in with folks to find out. +So Edward Loveall has been sending out a helpful survey and checking in to say, "Hey, how are you feeling about your client work? How are you feeling about your team lead responsibilities? How are you feeling about investment time?" So then you can track your own growth and see is this really helping me? Is this really going in the right direction, or am I just more stressed about everything now? So that's helpful that we are also just looking back to make sure that this is supporting the initiatives that we said it would support. +But that's some of the newness in my world. What's going on in your world? +CHRIS: What's going on in my world? Continued adventures in the world of hiring. So we've got a couple of people in the pipeline now. We've got some folks in the technical interview phase, which we're structuring our technical interview very much inspired by the thoughtbot interview. So it's a pairing session as well as some code review, which is great because I think it's really representative of the actual work that we do. +I believe strongly in not having an interview that is trivia or anything of that sort of thing. I want to see folks at their best as opposed to finding the rough edges. Because I think it's critical to have an interview that really represents the work that we're doing and then also gives candidates an opportunity to show themselves at their best as opposed to trying to hunt out gaps in knowledge or things like that because I think it's easier to shore up a gap of knowledge. But I really want to know what is this person like when they're firing on all cylinders? +So, so far, that's going great. But hiring is a complicated long game. So it will probably be a thing that I'm talking about for some weeks to come. And if anyone out there is listening and is potentially interested in a new adventure, I would love to chat with you. Sagewell Financial is hiring. And it's a wonderful Rails codebase and lots of new opportunities, et cetera, et cetera. +STEPH: As someone that has worked with you, I can absolutely vouch that you are amazing to work with. And I can only imagine the codebase must be...everything we've talked about is really interesting and stellar. So yeah, I love that you're talking about this. I think it's awesome and a great opportunity for folks to get to join Sagewell. +CHRIS: Oh, thanks, Steph. That's very kind of you. But in other unrelated to hiring news, one of the things that I talked about in last week's episode was my search for a new to-do list or a new application to use. And I listed some of the ones that I've been exploring. We got more feedback about that particular segment than any other by like 2X. And there's something to be said there. Maybe the show is just living up to its name. +But so many people are reaching out like, "Oh, have you looked at this one?" And to be clear, I very much appreciate all of the feedback that folks have given. And actually, it has given me a few new things to look at or ways to think about this question. But mostly, I find it very funny that even though we've dabbled in topics like agile, and is it good or bad? Or other contentious ideas [laughs] like that, somehow this idea of what to-do list application should I use by far the most engagement we've seen with our audience. +STEPH: I think it makes sense. Everybody has an opinion. Like you said, we're living up to our name, which is great. Was that great? I don't know. [laughter] +CHRIS: It's something, I'll say that. +STEPH: It's something. But yeah, everybody has felt this pain. They get it. It resonated. But since we do have some people that shared their strategies and their thoughts, did that sway you at all? Are you still going to keep with what you have, or are you going to explore new things? +CHRIS: I consider this project open. I have a project in Things, which is the current to-do list application that I'm using to explore the landscape. But it's basically like, I want to timebox it, find a version that works for me. And right now, I moved to Things, and it's fine. I'm more intrigued by the jobs to be done aspect of it. So as opposed to a particular piece of software and the features that it has or doesn't have, I really want to think about the habits and workflows that I want to make easier and more repeatable. +So particularly, each day, I want to wrap up by cleaning everything up. I like my inbox zero, as you probably know, so doing a little bit of that, and then planning the next day. So I want to have a tool that supports that idea of I want to queue up what I'm going to do in the morning so that tomorrow morning when I start back up, I have a very clear list of things to do. And I can just dive in with what I find to be some of my best thinking time early in the morning. +Similarly, I want to be able to review on a regular basis and know if things are getting stale or overdue. So there are a couple of different workflows that I'm really focusing on. And it's unfortunate because then I look at each piece of software, and I'm like, well, you kind of support this but not totally. So I'm more in a collecting phase right now. I'm thinking about the workflows that I want to have and then finding the different tools and comparing them across those. +But the one thing that I have done at this point is I wrote a little Siri shortcut I think is the name for it. They're called Shortcuts is the name of the application, but if I try and Google that, Google doesn't really know what I'm talking about. They think I'm talking about my phone, but I'm not talking about my phone. I'm talking about my actual computer, but it's little workflow automation stuff on OS X. +And so I have a shortcut now that prompts me for the amount of time, and it defaults to 45 minutes. And then, it will turn on Do Not Disturb for 45 minutes, minimize Slack, because I can't be trusted, and turn on a particular Spotify playlist. +And then there's a little menu bar application that...I wrote a tiny bit of AppleScript; I found it on the internet and actually read it, that finds the top task in my to-do list and puts it in the menu bar. And so now I have all of that. I push a magic button, and I say, "Yes, so I would like to work for 45 minutes on the thing that is at the top of my to-do list.” And then all of the noise of the world goes away for 45 minutes or however long I say. +STEPH: I think you just created the next new hot to-do app. [laughs] This sounds like something that I need and love, especially when you're like, it autoplays a playlist for you and shuts down the world and then has you focus. Yeah, I like this. I think this also rings a bell. I feel like Momentum, or something also has similar prompts. But this sounds delightful. +CHRIS: If we're being honest, it's an absolute hodgepodge of a kludge. You have some weird shell scripts and some AppleScripts. And I had to install a weird command-line utility for Spotify to make it happen. But it was one of those like; I'm spent at the end of the day. I just want to tweak on some piece of code. And this was a perfect, productive distraction, is how I would describe it. And when I've used that, I've been very happy. I know the days that I actually lean into that mode of working are better days. +The days where I allow myself to be distracted by Slack throughout the day, although I'm responsive to certain questions, things are not moving as well as they should. And so, I'm trying to be really intentional with having more of these Do Not Disturb sessions throughout the day. I feel bad saying that. I shouldn't because we all should be in agreement that this is the way that we work. But even saying that, I'm like, I'm not that special. I should be reachable, right? [laughs] But I should take even just a short 45-minute break to focus on the work that I actually need to do. It's a struggle. +STEPH: I have struggled with that where I used to always feel such an urgent need that I had to respond to someone as soon as they messaged me. But over time, I've learned that one, things typically aren't as urgent as I will feel that they are. And then two, if you have that type of environment where people aren't expected to just immediately reply to stuff, then you learn to write things in a way that says, "Hey, when you see this, and here's context, and here are the things that I'm looking for. And here's an easy way for you to give feedback." +It just improves the overall communication. I could go on a rant about this. I think we've actually ranted about this before in a very positive way. [laughs] Yes, I think that's great that you are fighting the good fight and turning off the world for 45 minutes to focus on a task. +CHRIS: What's a positive rant? I feel like there's got to be a word for that. [laughs] But I'm trying to try and come up with that. A celebration isn't...is this one of those gaps in language where we don't have a word for a positive rant? +STEPH: Oh, this is going to bother me. [laughs] There's got to be something for a positive rant. +CHRIS: Well, I'm sure German has...some Scandinavian language or German has a more specific version of when one goes off on a rant for many hours about things that they love and are joyous about in the world or something like that. But maybe English is just lacking this, or maybe this is a market opportunity. And we can coin the word, and then it's ours. +STEPH: I think it's just praise or accolades, although that doesn't feel strong enough. Rant feels like such an emotional word that I agree praise doesn't feel strong enough. +CHRIS: It's also spacious. You don't just rant, and it's one word. It's not just like one swear that you yell in the word. No, it's this long rambling thing, and I want that but positive. Maybe it's just called The Bike Shed [laughter] because I think that might be what we do. +STEPH: I love that. I'm trying to smash it together, and all that I can come up with is prant, so that leads with a P. +CHRIS: Yeah, I went there real quick. [laughter] Portmanteau is where I spend most of my time. But prant is just not enough. Okay, we're going to take this offline. I think we should come up with a word. This is our market opportunity. I don't know that we'll make a lot off of this, but we'll have a word then. +STEPH: It's okay. Free things are good. Oh my goodness, this is going to be so trivial and silly. But I've been playing Wordle as the rest of the world has. If you're not playing Wordle, check it out. [laughs] It's delightful. And it's free. But I started playing without really researching who created it and didn't have all of the details behind it. +And then it was earlier this week I found out that the creator of Wordle is Josh Wardle. And that just blew my mind and made me so happy that it just had that alliteration and similarity. And I just hadn't put it together until that moment. And it was just this wonderful, happy bubble of a moment where I was like, oh, that's delightful. [laughs] And I'm pretty sure I texted some people who were like, "Yeah, yeah, we know that." [laughs] +CHRIS: Yes, that was a wonderful positive rant or prant as it were there. And Wordle really is just such a delightful phenomenon that popped out of nowhere and is given away for free by the kindness of Josh Wardle. So yeah, wonderful things on the internet. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: We have a listener question this week. Once again, just as a reminder, everyone, we love getting these listener questions. Feel free to send them into hosts@bikeshed.fm or ping Steph or I on Twitter or any number of different ways. There's, I think, a form that you can go to the website, lots of different ways to ask us your questions. But again, we really love them. They let us have more pointed topics to talk about, such as today's topic, which is "What do you consider a quote, unquote, "large table" in a database?" Which is an interesting question, I think. +And so, let me read the question here. "Hey, Steph and Chris, I’ve listened to you (and most of your predecessors) for a while now. I've really been enjoying the conversational style about your actual development struggles." Thank you so much. This comes from Matt, by the way. +"Anyway, something Chris said in Episode 301 triggered a thought for me around large tables and databases and handling them for development tasks. What do you consider a quote, "large table" in a database? What questions/considerations come to mind when you're doing PR work that has a database interaction in it? We recently needed to delete a lot of rows out of a large table, and the team has a lot of discussion around how to handle it without impacting our production users. Curious on your thoughts. Thanks." +So, Steph, what do you think? What's a large database table in your mind? +STEPH: So I don't have a scientific answer for that, but I can give you my gut instinct. So typically, if there's a table that has a million or more records, I'll refer to that table as a large table. And then, if a table has around half a million records, then I start to be more cautious about data changes and how I'm rolling out schema changes. So that's my very loose; this is my feeling of when we're getting into large territory. How about you? Do you have more of a concrete answer? +CHRIS: I don't. And I think it would actually, in a lot of cases, be defined based on the database system that we're working with and, frankly, the RAM available on that system. There are two different sides of it; one is on the right side, like, how quickly are we inserting data into this table? And how quickly is it growing? Is probably a better question. Maybe there's a ton of data in it, but it's not growing that quickly. And so, we don't need to worry about any runaway characteristics. +The other side of it is how easily can we read from it? And that is the one that's going to be RAM-constrained. Where can we maintain an index efficiently? Can we query effectively and use RAM and whatnot? So a million starts to become an interesting number, probably. But I've worked on plenty of databases where hundreds of millions of rows existed, and we've got efficient indices in place and enough RAM that the database just happily works with that, and there are no problems. +So really, it's a question of like, if we start thinking about having to need to delete data, then that's a large table. If we have one table that is wildly larger than the others in the system, then that is something that I'll keep an eye on. I want to make sure, like, how's that table doing? How's the special table doing? +And often, there is one or two special tables similar to the idea of god objects within a system where these are the one or two classes that have just method after method after method after method. Similarly, there are one or two database tables that often have the lion's share of the data within the system. And so those are the ones that I'm really focused on. +And especially as we get closer to the RAM limit, there's this drop-off that I've seen happen where a system is like, it's fine. We got 250 gigs of RAM; there's no problem. And our database is only 100 gigs. And then a couple of weeks later, suddenly, had a bunch of new users sign up, and suddenly, your data and your indices no longer fit in memory. And now we're paging to disk, and suddenly the performance characteristics of your system just tank. And so it's that sort of thing. Watching growth rates is perhaps more important than the absolute size of any individual table. So yeah, those are some loose thoughts. +STEPH: I like how you used the word interesting. I think that's a nice replacement for the word large. When we get around a million records, things start getting more interesting in how we're rolling out schema changes. And then there's also you touched on usage, which aligns well with I often don't think so much about how many records that we have in a table. +But what's the usage of that table? How many queries or transactions are being executed against that table? Is this a very popular table like the users table? And will running a migration that renders that table inaccessible for a couple of seconds will that be problematic, or is this a table that we write to a lot, but we don't read from very often? +And even if it runs a couple of seconds, it's not likely to have an impact on people using the application. So that's one area I tend to think about first is what's the popularity of this table? And how cautious do I need to be in making sure that we don't block other people from accessing this data? +I also really like how Matt asked the question about what considerations come to mind when you're doing PR work that has a database interaction? That's one of those areas that, honestly, I lean pretty heavily on Strong Migrations to remind me how I can rewrite a migration to avoid or to transfer a blocking operation to a non-blocking operation. +So a really good example is setting a NOT NULL constraint on an existing column. I know that it can be very blocking if you try to do that by default when you first run it, and I will look it up every time. I will check Strong Migrations and say, "Hey, I know you've got some really great docs that will walk me through about adding a check constraint instead," and then making sure that I can then add this new column. +So going forward, for inserts and updates will apply the default, but it doesn't validate all the existing data. It's also a really good reminder, that particular example, is start with stricter constraints because it's a lot easier to remove a constraint than to add one later. So that's one consideration that comes to mind. +I also think the fail fast and fail loudly applies nicely here. So if I'm looking at a PR that is making a schema change, then I want to validate that the application has low timeout values so that way if a migration does take more than 30 seconds to run, then the migration will timeout. And then that will alert the developer to say, "Hey, do you need to think of a new approach or see if there's a way to improve this?" Versus if that migration didn't timeout, then that timeout is going to become user-facing as they start to experience problems with the site. +And then also looking for more performant methods so using findnbatches, update all, delete all, just checking for the more performant ways that we can update large sets of data. Those are, I think, the top things that I really look for. How about you? +CHRIS: Yeah, I think very similar to everything you just said. And broadly, there's a point in time that happens frankly pretty early on in the growth of an application and the data set behind it where you need to start behaving differently with regard to migrations. There's a small period of time where I can just get away with anything. +I actually really love the part before we have any actual users where I'm like, oh, we need to change this fundamentally. I'm just going to drop the table and rebuild it because it's easier than trying to think about how to migrate this data. But so quickly, you get into a place where it's like, nope, sorry, can't do that have to treat this as realistic. +So a bunch of the strategies that you're describing, like indexes concurrently, is one of the things that I'll reach for often because that allows me to decouple the timing there and not...again, the migration timeout that you're talking about is absolutely something that I want to have. Migration should go through quickly, and if they can't, then we need a different approach. Maybe we need to introduce the new column right to that one in parallel to the existing column, and then eventually do a switchover. It's definitely more work and involves a couple of deploys to get that done, but that's the unfortunate reality that we have to move to. +I will say one of the things we talked about is like, if we hit that timeout, then we're going to stop that migration. This is a critical feature that I rely on deeply at Postgres, which is that schema migrations or DDL transformations; if I'm saying that correctly, I'm not sure I am, but throwing an acronym out there, it'll be fun. This is actually one feature of Postgres that I really rely on. +My understanding is that Postgres has this; MySQL does not, but I may be off. I know that Postgres has transactional DDL transformation, so schema migration sort of things. I'm adding a column; I'm removing a column, et cetera. Those inherently happen within a transaction, and that's wonderful because if they do timeout, we want to be in a consistent state. +The worst thing I can possibly imagine is being like, we got halfway through, but then we failed, or we lost connection, and so it's half migrated. It's like, oh God, I want to trust my database deeply. That's sort of one of the fundamental things that I have. And I've, over time, pushed more and more into the database and saying let's have check constraints. Let's have null true and all of these sorts of things so that the data in my database can be deeply trustworthy. +The idea that a schema migration could go awry, and suddenly we've got like, well, half of the rows have these extra columns. What does that even mean? How do you live in that world? So I love this feature of Postgres. I really rely on it. I feel very bad whenever I have to disable it. I think there are some enum-related things that require disabling DDL transactions. And whenever I type that in a migration, I'm like, I don't like this. I'm not happy about this, but it's the world we live in for now. +STEPH: If we're sharing our truths, yeah, adding an index concurrently also you have to remove that DDL transaction and disable it. For a previous project that I was working on, we often ran into that timeout where we'd run a migration, and then it would timeout. And we would then just specify and be like, "Hey, for this migration, I'm going to bump you up to a minute. I'm just going to make it longer." +And that felt questionable at times, but I at least appreciate the explicitness of it where you're making that decision to say, nope, I think this is fine. It’s not going to impact anybody, or we're going to run it in off-hours. I do want to extend this to a minute, and then make sure you do reset it, so it doesn't affect it globally from there on out. +But that's something that you can do, and I have done before, which I feel is important. You still want to know some of your outs in case you do need something like that just to fix things in a moment but then at least be intentional for when you're using it and then communicate to the team like, "Hey, I'm doing this and let me know if you have concerns about it." +For this specific scenario that Matt provided about we recently needed to delete a lot of old rows out of a large table, and the team had a lot of discussion about how to handle this without impacting production users; I happened to have a really nice conversation with Steve Polito, a fellow thoughtboter, about this particular question. And he had a very thoughtful response that I hadn't considered where he suggested starting with deleting the data for a small set of records. +So, for example, if you're working with a users table, you could scope the data deletion to only inactive users and then use a feature flag to disable any interactions that would be affected by that data loss, run that change to delete the data for those inactive users, and then check for unexpected errors or side effects. +So then that way, you have this moment to pause to say, "Hey, did we forget something? Is there something about this application that's still relying on that data that we forgot about? We've only done it for a small amount of users, so we're in a safer space." So then, at that point, you can either repeat those steps for another batch of records or use that feedback to then drop the column with confidence. And that was an approach that I hadn't considered, but I really liked that idea. +CHRIS: Yeah, it's a nice, I'd say methodical approach to what can be a very complex and difficult to wrangle task. I will say I haven't actually explored this too much, but I've always had in the back of my mind, like, if we're deleting data from the application, ideally, we're saying this data is no longer needed. +But I wonder if using table partitioning is an alternative that can be useful in these cases. What if we're able to figure out the correct partitioning? It's often time series sort of stuff. What if we're able to lean into that and say, "Let's partition this by year." And then yeah, we don't use the old data anymore, but it lives in a separate partition. And therefore, I think Postgres is able to do reasonable things with that. +And again, like disk space, we can have a lot more storage on disk, but RAM is really going to be the constraining factor of how much of the index fits in memory. And again, I haven't pushed on this. But I think that's an alternative approach that can be really interesting. But if we do have time-series data, in particular, Postgres is wonderful. But it's not necessarily honed exactly to that use case. +And so, there are a couple of tools that I've kept an eye on right now: ClickHouse, Timescale, and InfluxDB being the three of them. And I think most if not all of them are based on Postgres, but then they build on top of it. And they add some deeper understandings of time series data and how to optimize querying and storing, and all of that. And so, is that an alternative that allows us to still stay in this world but then have a different approach and alleviate some of the burdens that might come with this heavy data that we have? +STEPH: Yeah, all those sound interesting. I haven't heard of some of those. This is why I love chatting with you. You always bring interesting perspectives that I had not considered before, like the partitioning. Just to clarify, partitioning the data is a way of keeping that data, but then it's not indexed. So that way, your system isn't spending as much time making sure that data is easily readable. But then that way, you don't actually delete it, so then it's there should you wish to be like, oh, I wish I hadn't gotten rid of that data. +CHRIS: I think so. I'll be honest; I don't deeply understand it. But I think you basically can say given a giant projects table within your system; we actually may have that logically grouped by user sort of thing. And so we can shard and partition and say, there are ten different buckets of these. And if we optimize it well such that all of the things that are logically together actually live together on disk, then it allows Postgres to be much more efficient. +Similarly, with time-series data, then you can say, use this sort of windowing where it's each month, we get a new bucket. And then it's much easier to query across just that bucket because it's already sort of partitioned down in that way. +But I'll be honest; I'm now speaking well past my actual knowledge. I've never actually worked with it. But it's one of those things that I have in the back of my mind. Like if all of my other tools fail me and if I cannot solve these performance problems in a Postgres system with indexes, and tuning, and other things like that, then I will look to partitioning. So I look forward to that day when the data problems are so massive that I need to table partition. +STEPH: Got it. Like they say, it's a good problem to have. While adding to the list of tools, there's one that I discovered recently; it's called Safe PG Migrations. And it's very similar to Strong Migrations, where Strong Migrations will warn you and say, "Hey, this is not safe. There are other ways to write this migration." Safe PG Migrations take some more aggressive approach and will rewrite your migration to be a safer version. And I don't know how I feel about it. I love it, and I hate it. [laughs] +It's one of those the magic is there, and that could be phenomenal. But I get squeamish when things want to rewrite something as important as my migrations. But on the other hand, it is like a really nice default for the team because it's more than a warning. So that way, if you're trying to put something more strict in place for people to follow, then this would be a good way to do that. +CHRIS: I'm very intrigued by that as a tool because if it were obvious, then Postgres would do it. The team behind Postgres does absolutely amazing work. And so if I tell them, "This is the change I want to make to the system," and they're like, "Cool, we're going to do that super inefficiently," and someone else is like, "No, no, no, I can trick it." Postgres is good at tricking itself, is my stance. +So I'd be intrigued as to what secret knowledge they have or what are their caveats where Postgres has to handle every possible edge case. And therefore, it's slower because of pessimistic concerns that it has. But this tool says, "No, no, as long as you're not doing this very terrible thing, you're fine. And we'll rewrite it to a safer, faster version." But I'm just kind of intrigued, like, why do you think you're better than Postgres? +STEPH: [laughs] Why do you think you're better? Well, I do you have an example I can provide. It's one that they have on their README. And this one highlights that if you're adding a column to an existing table and that you're adding a default value and no constraint, then they show you how it's rewritten where they set explicitly the lock timeout, and then they will add the column. +And then they will set the default value but not in a way that it's going to do a table scan where it's going to add it for all the existing records; it's going to be for new records. And then they, let's see, they also update the users in batches to then set a default value, and then they will reset the statement timeout because it looks like they are...yeah, because initially, they change it, so they're resetting it to an original value. And then, they set the column Null constraint. I know I just said a lot of things reading from their README. +But they have a good example here that kind of highlights that this is how they rewrite it. So I do find that more reassuring as long as I can then see how it was rewritten, and then I can validate it and confirm it with what I think is appropriate. Then I still have full control. Then it's more of a hey, we rewrote this thing for you. Feel free to review it and then change it as you see fit. As long as I have that final authority, then that makes me feel better about this. +CHRIS: Got it. That makes sense. And the thing that you're describing, I think, is a semantically different thing than the first migration where it's like, do this thing. And they're like, well, okay, you could. But if instead, you did X, Y, and Z, then it would go way faster and be way easier. That makes a lot of sense. And it feels like shared knowledge wrapped up into a tool which I'm always a fan of that. +STEPH: Yeah, in general, when I think about general strategies for schema changes, there are really three areas that come to mind or three strategies that come to mind. The first one is that we take incremental steps to avoid blocking reads and writes to the table, which then allows you to deploy during business hours or off business hours. That often means just more manual steps that you have to take to make sure that it's safe. And then the other one is scheduling downtime to run a migration. That is a very real option, something that you can do. Or have a fancy setup that utilizes followers for seamless migrations and upgrades. +I feel like that's like the three big buckets that you can fit your strategy within. And it just depends on the needs of your application and users as to which one of those you're ready for or which strategy you need to use. What do you think? Are there any other big buckets that I left out of that list? +CHRIS: No, I think we covered a bunch there. Hopefully, that was useful. Hopefully, it, I don't know, maybe introduced folks to some new ideas or ways to think about this sort of work. And yeah, with that, shall we wrap up? +STEPH: Yeah, I've still got my Wordle to play for the day. So let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +ALL: Byeeeeeeeeeee!!! +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph is super excited about changing her schedule to dedicate a full day to focus on being a great team lead. Chris talks about his continued adventures in the world of hiring.

+ +

Together they answer a listener question about what they consider a “large” table in a database and how they review schema changes.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: I just feel like every time I listen to Celine Dion, there are lots of dramatic hand gestures that have to go with it.

+ +

CHRIS: Yep, definitely that. I'm strong team Power of Love.

+ +

STEPH: Ooh, yeah, yeah, that's a good one.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Oh, I have some exciting news. I am changing up my schedule. It is going to start next week, where as a team lead at thoughtbot, we have been working on finding ways that we can have more time to invest into the team and team-specific initiatives. And most of us spend four days billing on client work, and then we have investment day, which is delightful.

+ +

But we're finding as team leads, that's really not enough time to then have the impact that we want in terms of supporting our team and then also having time for mentorship and all the other things that go along with being a team lead and one on ones. So we have been incrementally working towards reducing billing.

+ +

So team leads only bill three days a week, and then they have an additional day to really focus on being a great team lead. And I start that new schedule, that new-new schedule next week, and I couldn't be more excited. I think it's going to be wonderful.

+ +

I do think there are some challenges that go with it in terms of really balancing, at least this is from the others who have gone before me where they then find it a bit harder in terms of client expectations of saying, "Well, I was billing four days, and I had a larger impact on the codebase and the team. Now I'm dropping to three days. I still need to stay within that constraint. And I want to keep the client team happy." So that seems to be a thing. But I will find out next week how it goes.

+ +

CHRIS: Well, I'm very excited for you. That sounds wonderful, frankly. The balancing of the client expectations and then there's sort of now three slices to your work, which there always were, but now you have it delineated in an interesting way. Do you have specific plans for the team lead? So let's say now, nominally, there's one day a week that is dedicated to team lead time. Do you have ideas of what that looks like? Are you planning to pair with your team? Is it longer one on ones? I don't want to seed the question too much with potential answers. So what are you thinking about there?

+ +

STEPH: [laughs] Ideas are great. And yes, so I think number one is structure. So right now, one on ones and any support that I need to provide others is more ad hoc, or at least the one on ones those are not ad hoc; they are structured. But they are spread out throughout the week, and then I just context switch between client work and then checking in with others.

+ +

Now I can stagger everything on a Thursday or whichever day is going to be my really focused team lead day. So that way, I have all the one on ones on that day. And then yes, I can have more time to pair. So I can say, hey, let's just schedule every other week where you and I hang out, and we pair for an hour, and it can be on their client work. It can be on anything that they'd like to work on. Or, if there's a particular topic they'd like to talk about, we can pair on consulting issues or discussions.

+ +

But yes, ultimately, I'd love to do more pairing and then structure one on ones to a specific day and essentially, just really protect that time. Because right now, it feels that client initiatives and work always come first, and then team lead comes second. And I'm excited to balance that more so they have equal priority.

+ +

CHRIS: Yeah, that sounds great. I'm super intrigued to see what specific structures fall out of it and how you're experiencing it. I'll be interested to hear how investment time changes for you as a result of this because I remember when I started in the management role, four days a week billing, and then one day a week of investment time. But the investment time then basically went to one on ones and other things like that.

+ +

And when I switched to a three-day week, I was able to reclaim some amount of investment time. And it was interesting having that open back up and have that be a consideration. Because definitely one on ones and things like that I think firmly fit within the idea of investment time or investing in the organization and whatnot. But still, there's the like; I'm going to go explore a new framework or something like that that also certainly fits within investment time. So I'll be interested to hear if you find that changes in sort of a specific way.

+ +

STEPH: Yeah, I'm really interested in that as well. Because right now, as you mentioned, my investment activities are really focused more around the team and other folks and then Bike Shed. Bike Shed is a really big investment time activity. So I've noticed since becoming a co-host for the show, I talk a lot about code, but I don't necessarily contribute to open-source projects or other internal projects at the rate that I used to. It's now more focused about here and being a co-host and talking about all the things, and that requires some prep for me.

+ +

So I'm also interested to see if this will shift my investment time a bit where I do find a little more time to code and then explore just things that I'm interested in. But in the experiment of doing something new, it's always important to then have a way to measure is this a good change? Is this a bad change? So we have been checking in with team leads to say, "Hey, we've changed your schedule to where you're billing one day less. How's that going for you?" Because there's the assumption that this will be great, but you really have to check in with folks to find out.

+ +

So Edward Loveall has been sending out a helpful survey and checking in to say, "Hey, how are you feeling about your client work? How are you feeling about your team lead responsibilities? How are you feeling about investment time?" So then you can track your own growth and see is this really helping me? Is this really going in the right direction, or am I just more stressed about everything now? So that's helpful that we are also just looking back to make sure that this is supporting the initiatives that we said it would support.

+ +

But that's some of the newness in my world. What's going on in your world?

+ +

CHRIS: What's going on in my world? Continued adventures in the world of hiring. So we've got a couple of people in the pipeline now. We've got some folks in the technical interview phase, which we're structuring our technical interview very much inspired by the thoughtbot interview. So it's a pairing session as well as some code review, which is great because I think it's really representative of the actual work that we do.

+ +

I believe strongly in not having an interview that is trivia or anything of that sort of thing. I want to see folks at their best as opposed to finding the rough edges. Because I think it's critical to have an interview that really represents the work that we're doing and then also gives candidates an opportunity to show themselves at their best as opposed to trying to hunt out gaps in knowledge or things like that because I think it's easier to shore up a gap of knowledge. But I really want to know what is this person like when they're firing on all cylinders?

+ +

So, so far, that's going great. But hiring is a complicated long game. So it will probably be a thing that I'm talking about for some weeks to come. And if anyone out there is listening and is potentially interested in a new adventure, I would love to chat with you. Sagewell Financial is hiring. And it's a wonderful Rails codebase and lots of new opportunities, et cetera, et cetera.

+ +

STEPH: As someone that has worked with you, I can absolutely vouch that you are amazing to work with. And I can only imagine the codebase must be...everything we've talked about is really interesting and stellar. So yeah, I love that you're talking about this. I think it's awesome and a great opportunity for folks to get to join Sagewell.

+ +

CHRIS: Oh, thanks, Steph. That's very kind of you. But in other unrelated to hiring news, one of the things that I talked about in last week's episode was my search for a new to-do list or a new application to use. And I listed some of the ones that I've been exploring. We got more feedback about that particular segment than any other by like 2X. And there's something to be said there. Maybe the show is just living up to its name.

+ +

But so many people are reaching out like, "Oh, have you looked at this one?" And to be clear, I very much appreciate all of the feedback that folks have given. And actually, it has given me a few new things to look at or ways to think about this question. But mostly, I find it very funny that even though we've dabbled in topics like agile, and is it good or bad? Or other contentious ideas [laughs] like that, somehow this idea of what to-do list application should I use by far the most engagement we've seen with our audience.

+ +

STEPH: I think it makes sense. Everybody has an opinion. Like you said, we're living up to our name, which is great. Was that great? I don't know. [laughter]

+ +

CHRIS: It's something, I'll say that.

+ +

STEPH: It's something. But yeah, everybody has felt this pain. They get it. It resonated. But since we do have some people that shared their strategies and their thoughts, did that sway you at all? Are you still going to keep with what you have, or are you going to explore new things?

+ +

CHRIS: I consider this project open. I have a project in Things, which is the current to-do list application that I'm using to explore the landscape. But it's basically like, I want to timebox it, find a version that works for me. And right now, I moved to Things, and it's fine. I'm more intrigued by the jobs to be done aspect of it. So as opposed to a particular piece of software and the features that it has or doesn't have, I really want to think about the habits and workflows that I want to make easier and more repeatable.

+ +

So particularly, each day, I want to wrap up by cleaning everything up. I like my inbox zero, as you probably know, so doing a little bit of that, and then planning the next day. So I want to have a tool that supports that idea of I want to queue up what I'm going to do in the morning so that tomorrow morning when I start back up, I have a very clear list of things to do. And I can just dive in with what I find to be some of my best thinking time early in the morning.

+ +

Similarly, I want to be able to review on a regular basis and know if things are getting stale or overdue. So there are a couple of different workflows that I'm really focusing on. And it's unfortunate because then I look at each piece of software, and I'm like, well, you kind of support this but not totally. So I'm more in a collecting phase right now. I'm thinking about the workflows that I want to have and then finding the different tools and comparing them across those.

+ +

But the one thing that I have done at this point is I wrote a little Siri shortcut I think is the name for it. They're called Shortcuts is the name of the application, but if I try and Google that, Google doesn't really know what I'm talking about. They think I'm talking about my phone, but I'm not talking about my phone. I'm talking about my actual computer, but it's little workflow automation stuff on OS X.

+ +

And so I have a shortcut now that prompts me for the amount of time, and it defaults to 45 minutes. And then, it will turn on Do Not Disturb for 45 minutes, minimize Slack, because I can't be trusted, and turn on a particular Spotify playlist.

+ +

And then there's a little menu bar application that...I wrote a tiny bit of AppleScript; I found it on the internet and actually read it, that finds the top task in my to-do list and puts it in the menu bar. And so now I have all of that. I push a magic button, and I say, "Yes, so I would like to work for 45 minutes on the thing that is at the top of my to-do list.” And then all of the noise of the world goes away for 45 minutes or however long I say.

+ +

STEPH: I think you just created the next new hot to-do app. [laughs] This sounds like something that I need and love, especially when you're like, it autoplays a playlist for you and shuts down the world and then has you focus. Yeah, I like this. I think this also rings a bell. I feel like Momentum, or something also has similar prompts. But this sounds delightful.

+ +

CHRIS: If we're being honest, it's an absolute hodgepodge of a kludge. You have some weird shell scripts and some AppleScripts. And I had to install a weird command-line utility for Spotify to make it happen. But it was one of those like; I'm spent at the end of the day. I just want to tweak on some piece of code. And this was a perfect, productive distraction, is how I would describe it. And when I've used that, I've been very happy. I know the days that I actually lean into that mode of working are better days.

+ +

The days where I allow myself to be distracted by Slack throughout the day, although I'm responsive to certain questions, things are not moving as well as they should. And so, I'm trying to be really intentional with having more of these Do Not Disturb sessions throughout the day. I feel bad saying that. I shouldn't because we all should be in agreement that this is the way that we work. But even saying that, I'm like, I'm not that special. I should be reachable, right? [laughs] But I should take even just a short 45-minute break to focus on the work that I actually need to do. It's a struggle.

+ +

STEPH: I have struggled with that where I used to always feel such an urgent need that I had to respond to someone as soon as they messaged me. But over time, I've learned that one, things typically aren't as urgent as I will feel that they are. And then two, if you have that type of environment where people aren't expected to just immediately reply to stuff, then you learn to write things in a way that says, "Hey, when you see this, and here's context, and here are the things that I'm looking for. And here's an easy way for you to give feedback."

+ +

It just improves the overall communication. I could go on a rant about this. I think we've actually ranted about this before in a very positive way. [laughs] Yes, I think that's great that you are fighting the good fight and turning off the world for 45 minutes to focus on a task.

+ +

CHRIS: What's a positive rant? I feel like there's got to be a word for that. [laughs] But I'm trying to try and come up with that. A celebration isn't...is this one of those gaps in language where we don't have a word for a positive rant?

+ +

STEPH: Oh, this is going to bother me. [laughs] There's got to be something for a positive rant.

+ +

CHRIS: Well, I'm sure German has...some Scandinavian language or German has a more specific version of when one goes off on a rant for many hours about things that they love and are joyous about in the world or something like that. But maybe English is just lacking this, or maybe this is a market opportunity. And we can coin the word, and then it's ours.

+ +

STEPH: I think it's just praise or accolades, although that doesn't feel strong enough. Rant feels like such an emotional word that I agree praise doesn't feel strong enough.

+ +

CHRIS: It's also spacious. You don't just rant, and it's one word. It's not just like one swear that you yell in the word. No, it's this long rambling thing, and I want that but positive. Maybe it's just called The Bike Shed [laughter] because I think that might be what we do.

+ +

STEPH: I love that. I'm trying to smash it together, and all that I can come up with is prant, so that leads with a P.

+ +

CHRIS: Yeah, I went there real quick. [laughter] Portmanteau is where I spend most of my time. But prant is just not enough. Okay, we're going to take this offline. I think we should come up with a word. This is our market opportunity. I don't know that we'll make a lot off of this, but we'll have a word then.

+ +

STEPH: It's okay. Free things are good. Oh my goodness, this is going to be so trivial and silly. But I've been playing Wordle as the rest of the world has. If you're not playing Wordle, check it out. [laughs] It's delightful. And it's free. But I started playing without really researching who created it and didn't have all of the details behind it.

+ +

And then it was earlier this week I found out that the creator of Wordle is Josh Wardle. And that just blew my mind and made me so happy that it just had that alliteration and similarity. And I just hadn't put it together until that moment. And it was just this wonderful, happy bubble of a moment where I was like, oh, that's delightful. [laughs] And I'm pretty sure I texted some people who were like, "Yeah, yeah, we know that." [laughs]

+ +

CHRIS: Yes, that was a wonderful positive rant or prant as it were there. And Wordle really is just such a delightful phenomenon that popped out of nowhere and is given away for free by the kindness of Josh Wardle. So yeah, wonderful things on the internet.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: We have a listener question this week. Once again, just as a reminder, everyone, we love getting these listener questions. Feel free to send them into hosts@bikeshed.fm or ping Steph or I on Twitter or any number of different ways. There's, I think, a form that you can go to the website, lots of different ways to ask us your questions. But again, we really love them. They let us have more pointed topics to talk about, such as today's topic, which is "What do you consider a quote, unquote, "large table" in a database?" Which is an interesting question, I think.

+ +

And so, let me read the question here. "Hey, Steph and Chris, I’ve listened to you (and most of your predecessors) for a while now. I've really been enjoying the conversational style about your actual development struggles." Thank you so much. This comes from Matt, by the way.

+ +

"Anyway, something Chris said in Episode 301 triggered a thought for me around large tables and databases and handling them for development tasks. What do you consider a quote, "large table" in a database? What questions/considerations come to mind when you're doing PR work that has a database interaction in it? We recently needed to delete a lot of rows out of a large table, and the team has a lot of discussion around how to handle it without impacting our production users. Curious on your thoughts. Thanks."

+ +

So, Steph, what do you think? What's a large database table in your mind?

+ +

STEPH: So I don't have a scientific answer for that, but I can give you my gut instinct. So typically, if there's a table that has a million or more records, I'll refer to that table as a large table. And then, if a table has around half a million records, then I start to be more cautious about data changes and how I'm rolling out schema changes. So that's my very loose; this is my feeling of when we're getting into large territory. How about you? Do you have more of a concrete answer?

+ +

CHRIS: I don't. And I think it would actually, in a lot of cases, be defined based on the database system that we're working with and, frankly, the RAM available on that system. There are two different sides of it; one is on the right side, like, how quickly are we inserting data into this table? And how quickly is it growing? Is probably a better question. Maybe there's a ton of data in it, but it's not growing that quickly. And so, we don't need to worry about any runaway characteristics.

+ +

The other side of it is how easily can we read from it? And that is the one that's going to be RAM-constrained. Where can we maintain an index efficiently? Can we query effectively and use RAM and whatnot? So a million starts to become an interesting number, probably. But I've worked on plenty of databases where hundreds of millions of rows existed, and we've got efficient indices in place and enough RAM that the database just happily works with that, and there are no problems.

+ +

So really, it's a question of like, if we start thinking about having to need to delete data, then that's a large table. If we have one table that is wildly larger than the others in the system, then that is something that I'll keep an eye on. I want to make sure, like, how's that table doing? How's the special table doing?

+ +

And often, there is one or two special tables similar to the idea of god objects within a system where these are the one or two classes that have just method after method after method after method. Similarly, there are one or two database tables that often have the lion's share of the data within the system. And so those are the ones that I'm really focused on.

+ +

And especially as we get closer to the RAM limit, there's this drop-off that I've seen happen where a system is like, it's fine. We got 250 gigs of RAM; there's no problem. And our database is only 100 gigs. And then a couple of weeks later, suddenly, had a bunch of new users sign up, and suddenly, your data and your indices no longer fit in memory. And now we're paging to disk, and suddenly the performance characteristics of your system just tank. And so it's that sort of thing. Watching growth rates is perhaps more important than the absolute size of any individual table. So yeah, those are some loose thoughts.

+ +

STEPH: I like how you used the word interesting. I think that's a nice replacement for the word large. When we get around a million records, things start getting more interesting in how we're rolling out schema changes. And then there's also you touched on usage, which aligns well with I often don't think so much about how many records that we have in a table.

+ +

But what's the usage of that table? How many queries or transactions are being executed against that table? Is this a very popular table like the users table? And will running a migration that renders that table inaccessible for a couple of seconds will that be problematic, or is this a table that we write to a lot, but we don't read from very often?

+ +

And even if it runs a couple of seconds, it's not likely to have an impact on people using the application. So that's one area I tend to think about first is what's the popularity of this table? And how cautious do I need to be in making sure that we don't block other people from accessing this data?

+ +

I also really like how Matt asked the question about what considerations come to mind when you're doing PR work that has a database interaction? That's one of those areas that, honestly, I lean pretty heavily on Strong Migrations to remind me how I can rewrite a migration to avoid or to transfer a blocking operation to a non-blocking operation.

+ +

So a really good example is setting a NOT NULL constraint on an existing column. I know that it can be very blocking if you try to do that by default when you first run it, and I will look it up every time. I will check Strong Migrations and say, "Hey, I know you've got some really great docs that will walk me through about adding a check constraint instead," and then making sure that I can then add this new column.

+ +

So going forward, for inserts and updates will apply the default, but it doesn't validate all the existing data. It's also a really good reminder, that particular example, is start with stricter constraints because it's a lot easier to remove a constraint than to add one later. So that's one consideration that comes to mind.

+ +

I also think the fail fast and fail loudly applies nicely here. So if I'm looking at a PR that is making a schema change, then I want to validate that the application has low timeout values so that way if a migration does take more than 30 seconds to run, then the migration will timeout. And then that will alert the developer to say, "Hey, do you need to think of a new approach or see if there's a way to improve this?" Versus if that migration didn't timeout, then that timeout is going to become user-facing as they start to experience problems with the site.

+ +

And then also looking for more performant methods so using find_n_batches, update all, delete all, just checking for the more performant ways that we can update large sets of data. Those are, I think, the top things that I really look for. How about you?

+ +

CHRIS: Yeah, I think very similar to everything you just said. And broadly, there's a point in time that happens frankly pretty early on in the growth of an application and the data set behind it where you need to start behaving differently with regard to migrations. There's a small period of time where I can just get away with anything.

+ +

I actually really love the part before we have any actual users where I'm like, oh, we need to change this fundamentally. I'm just going to drop the table and rebuild it because it's easier than trying to think about how to migrate this data. But so quickly, you get into a place where it's like, nope, sorry, can't do that have to treat this as realistic.

+ +

So a bunch of the strategies that you're describing, like indexes concurrently, is one of the things that I'll reach for often because that allows me to decouple the timing there and not...again, the migration timeout that you're talking about is absolutely something that I want to have. Migration should go through quickly, and if they can't, then we need a different approach. Maybe we need to introduce the new column right to that one in parallel to the existing column, and then eventually do a switchover. It's definitely more work and involves a couple of deploys to get that done, but that's the unfortunate reality that we have to move to.

+ +

I will say one of the things we talked about is like, if we hit that timeout, then we're going to stop that migration. This is a critical feature that I rely on deeply at Postgres, which is that schema migrations or DDL transformations; if I'm saying that correctly, I'm not sure I am, but throwing an acronym out there, it'll be fun. This is actually one feature of Postgres that I really rely on.

+ +

My understanding is that Postgres has this; MySQL does not, but I may be off. I know that Postgres has transactional DDL transformation, so schema migration sort of things. I'm adding a column; I'm removing a column, et cetera. Those inherently happen within a transaction, and that's wonderful because if they do timeout, we want to be in a consistent state.

+ +

The worst thing I can possibly imagine is being like, we got halfway through, but then we failed, or we lost connection, and so it's half migrated. It's like, oh God, I want to trust my database deeply. That's sort of one of the fundamental things that I have. And I've, over time, pushed more and more into the database and saying let's have check constraints. Let's have null true and all of these sorts of things so that the data in my database can be deeply trustworthy.

+ +

The idea that a schema migration could go awry, and suddenly we've got like, well, half of the rows have these extra columns. What does that even mean? How do you live in that world? So I love this feature of Postgres. I really rely on it. I feel very bad whenever I have to disable it. I think there are some enum-related things that require disabling DDL transactions. And whenever I type that in a migration, I'm like, I don't like this. I'm not happy about this, but it's the world we live in for now.

+ +

STEPH: If we're sharing our truths, yeah, adding an index concurrently also you have to remove that DDL transaction and disable it. For a previous project that I was working on, we often ran into that timeout where we'd run a migration, and then it would timeout. And we would then just specify and be like, "Hey, for this migration, I'm going to bump you up to a minute. I'm just going to make it longer."

+ +

And that felt questionable at times, but I at least appreciate the explicitness of it where you're making that decision to say, nope, I think this is fine. It’s not going to impact anybody, or we're going to run it in off-hours. I do want to extend this to a minute, and then make sure you do reset it, so it doesn't affect it globally from there on out.

+ +

But that's something that you can do, and I have done before, which I feel is important. You still want to know some of your outs in case you do need something like that just to fix things in a moment but then at least be intentional for when you're using it and then communicate to the team like, "Hey, I'm doing this and let me know if you have concerns about it."

+ +

For this specific scenario that Matt provided about we recently needed to delete a lot of old rows out of a large table, and the team had a lot of discussion about how to handle this without impacting production users; I happened to have a really nice conversation with Steve Polito, a fellow thoughtboter, about this particular question. And he had a very thoughtful response that I hadn't considered where he suggested starting with deleting the data for a small set of records.

+ +

So, for example, if you're working with a users table, you could scope the data deletion to only inactive users and then use a feature flag to disable any interactions that would be affected by that data loss, run that change to delete the data for those inactive users, and then check for unexpected errors or side effects.

+ +

So then that way, you have this moment to pause to say, "Hey, did we forget something? Is there something about this application that's still relying on that data that we forgot about? We've only done it for a small amount of users, so we're in a safer space." So then, at that point, you can either repeat those steps for another batch of records or use that feedback to then drop the column with confidence. And that was an approach that I hadn't considered, but I really liked that idea.

+ +

CHRIS: Yeah, it's a nice, I'd say methodical approach to what can be a very complex and difficult to wrangle task. I will say I haven't actually explored this too much, but I've always had in the back of my mind, like, if we're deleting data from the application, ideally, we're saying this data is no longer needed.

+ +

But I wonder if using table partitioning is an alternative that can be useful in these cases. What if we're able to figure out the correct partitioning? It's often time series sort of stuff. What if we're able to lean into that and say, "Let's partition this by year." And then yeah, we don't use the old data anymore, but it lives in a separate partition. And therefore, I think Postgres is able to do reasonable things with that.

+ +

And again, like disk space, we can have a lot more storage on disk, but RAM is really going to be the constraining factor of how much of the index fits in memory. And again, I haven't pushed on this. But I think that's an alternative approach that can be really interesting. But if we do have time-series data, in particular, Postgres is wonderful. But it's not necessarily honed exactly to that use case.

+ +

And so, there are a couple of tools that I've kept an eye on right now: ClickHouse, Timescale, and InfluxDB being the three of them. And I think most if not all of them are based on Postgres, but then they build on top of it. And they add some deeper understandings of time series data and how to optimize querying and storing, and all of that. And so, is that an alternative that allows us to still stay in this world but then have a different approach and alleviate some of the burdens that might come with this heavy data that we have?

+ +

STEPH: Yeah, all those sound interesting. I haven't heard of some of those. This is why I love chatting with you. You always bring interesting perspectives that I had not considered before, like the partitioning. Just to clarify, partitioning the data is a way of keeping that data, but then it's not indexed. So that way, your system isn't spending as much time making sure that data is easily readable. But then that way, you don't actually delete it, so then it's there should you wish to be like, oh, I wish I hadn't gotten rid of that data.

+ +

CHRIS: I think so. I'll be honest; I don't deeply understand it. But I think you basically can say given a giant projects table within your system; we actually may have that logically grouped by user sort of thing. And so we can shard and partition and say, there are ten different buckets of these. And if we optimize it well such that all of the things that are logically together actually live together on disk, then it allows Postgres to be much more efficient.

+ +

Similarly, with time-series data, then you can say, use this sort of windowing where it's each month, we get a new bucket. And then it's much easier to query across just that bucket because it's already sort of partitioned down in that way.

+ +

But I'll be honest; I'm now speaking well past my actual knowledge. I've never actually worked with it. But it's one of those things that I have in the back of my mind. Like if all of my other tools fail me and if I cannot solve these performance problems in a Postgres system with indexes, and tuning, and other things like that, then I will look to partitioning. So I look forward to that day when the data problems are so massive that I need to table partition.

+ +

STEPH: Got it. Like they say, it's a good problem to have. While adding to the list of tools, there's one that I discovered recently; it's called Safe PG Migrations. And it's very similar to Strong Migrations, where Strong Migrations will warn you and say, "Hey, this is not safe. There are other ways to write this migration." Safe PG Migrations take some more aggressive approach and will rewrite your migration to be a safer version. And I don't know how I feel about it. I love it, and I hate it. [laughs]

+ +

It's one of those the magic is there, and that could be phenomenal. But I get squeamish when things want to rewrite something as important as my migrations. But on the other hand, it is like a really nice default for the team because it's more than a warning. So that way, if you're trying to put something more strict in place for people to follow, then this would be a good way to do that.

+ +

CHRIS: I'm very intrigued by that as a tool because if it were obvious, then Postgres would do it. The team behind Postgres does absolutely amazing work. And so if I tell them, "This is the change I want to make to the system," and they're like, "Cool, we're going to do that super inefficiently," and someone else is like, "No, no, no, I can trick it." Postgres is good at tricking itself, is my stance.

+ +

So I'd be intrigued as to what secret knowledge they have or what are their caveats where Postgres has to handle every possible edge case. And therefore, it's slower because of pessimistic concerns that it has. But this tool says, "No, no, as long as you're not doing this very terrible thing, you're fine. And we'll rewrite it to a safer, faster version." But I'm just kind of intrigued, like, why do you think you're better than Postgres?

+ +

STEPH: [laughs] Why do you think you're better? Well, I do you have an example I can provide. It's one that they have on their README. And this one highlights that if you're adding a column to an existing table and that you're adding a default value and no constraint, then they show you how it's rewritten where they set explicitly the lock timeout, and then they will add the column.

+ +

And then they will set the default value but not in a way that it's going to do a table scan where it's going to add it for all the existing records; it's going to be for new records. And then they, let's see, they also update the users in batches to then set a default value, and then they will reset the statement timeout because it looks like they are...yeah, because initially, they change it, so they're resetting it to an original value. And then, they set the column Null constraint. I know I just said a lot of things reading from their README.

+ +

But they have a good example here that kind of highlights that this is how they rewrite it. So I do find that more reassuring as long as I can then see how it was rewritten, and then I can validate it and confirm it with what I think is appropriate. Then I still have full control. Then it's more of a hey, we rewrote this thing for you. Feel free to review it and then change it as you see fit. As long as I have that final authority, then that makes me feel better about this.

+ +

CHRIS: Got it. That makes sense. And the thing that you're describing, I think, is a semantically different thing than the first migration where it's like, do this thing. And they're like, well, okay, you could. But if instead, you did X, Y, and Z, then it would go way faster and be way easier. That makes a lot of sense. And it feels like shared knowledge wrapped up into a tool which I'm always a fan of that.

+ +

STEPH: Yeah, in general, when I think about general strategies for schema changes, there are really three areas that come to mind or three strategies that come to mind. The first one is that we take incremental steps to avoid blocking reads and writes to the table, which then allows you to deploy during business hours or off business hours. That often means just more manual steps that you have to take to make sure that it's safe. And then the other one is scheduling downtime to run a migration. That is a very real option, something that you can do. Or have a fancy setup that utilizes followers for seamless migrations and upgrades.

+ +

I feel like that's like the three big buckets that you can fit your strategy within. And it just depends on the needs of your application and users as to which one of those you're ready for or which strategy you need to use. What do you think? Are there any other big buckets that I left out of that list?

+ +

CHRIS: No, I think we covered a bunch there. Hopefully, that was useful. Hopefully, it, I don't know, maybe introduced folks to some new ideas or ways to think about this sort of work. And yeah, with that, shall we wrap up?

+ +

STEPH: Yeah, I've still got my Wordle to play for the day. So let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph is super excited about changing her schedule to dedicate a full day to focus on being a great team lead. Chris talks about his continued adventures in the world of hiring.

+ +

Together they answer a listener question about what they consider a “large” table in a database and how they review schema changes.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +

Services down? New Relic offers full stack visibility with 16 different monitoring products in a single platform.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: I just feel like every time I listen to Celine Dion, there are lots of dramatic hand gestures that have to go with it.

+ +

CHRIS: Yep, definitely that. I'm strong team Power of Love.

+ +

STEPH: Ooh, yeah, yeah, that's a good one.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Oh, I have some exciting news. I am changing up my schedule. It is going to start next week, where as a team lead at thoughtbot, we have been working on finding ways that we can have more time to invest into the team and team-specific initiatives. And most of us spend four days billing on client work, and then we have investment day, which is delightful.

+ +

But we're finding as team leads, that's really not enough time to then have the impact that we want in terms of supporting our team and then also having time for mentorship and all the other things that go along with being a team lead and one on ones. So we have been incrementally working towards reducing billing.

+ +

So team leads only bill three days a week, and then they have an additional day to really focus on being a great team lead. And I start that new schedule, that new-new schedule next week, and I couldn't be more excited. I think it's going to be wonderful.

+ +

I do think there are some challenges that go with it in terms of really balancing, at least this is from the others who have gone before me where they then find it a bit harder in terms of client expectations of saying, "Well, I was billing four days, and I had a larger impact on the codebase and the team. Now I'm dropping to three days. I still need to stay within that constraint. And I want to keep the client team happy." So that seems to be a thing. But I will find out next week how it goes.

+ +

CHRIS: Well, I'm very excited for you. That sounds wonderful, frankly. The balancing of the client expectations and then there's sort of now three slices to your work, which there always were, but now you have it delineated in an interesting way. Do you have specific plans for the team lead? So let's say now, nominally, there's one day a week that is dedicated to team lead time. Do you have ideas of what that looks like? Are you planning to pair with your team? Is it longer one on ones? I don't want to seed the question too much with potential answers. So what are you thinking about there?

+ +

STEPH: [laughs] Ideas are great. And yes, so I think number one is structure. So right now, one on ones and any support that I need to provide others is more ad hoc, or at least the one on ones those are not ad hoc; they are structured. But they are spread out throughout the week, and then I just context switch between client work and then checking in with others.

+ +

Now I can stagger everything on a Thursday or whichever day is going to be my really focused team lead day. So that way, I have all the one on ones on that day. And then yes, I can have more time to pair. So I can say, hey, let's just schedule every other week where you and I hang out, and we pair for an hour, and it can be on their client work. It can be on anything that they'd like to work on. Or, if there's a particular topic they'd like to talk about, we can pair on consulting issues or discussions.

+ +

But yes, ultimately, I'd love to do more pairing and then structure one on ones to a specific day and essentially, just really protect that time. Because right now, it feels that client initiatives and work always come first, and then team lead comes second. And I'm excited to balance that more so they have equal priority.

+ +

CHRIS: Yeah, that sounds great. I'm super intrigued to see what specific structures fall out of it and how you're experiencing it. I'll be interested to hear how investment time changes for you as a result of this because I remember when I started in the management role, four days a week billing, and then one day a week of investment time. But the investment time then basically went to one on ones and other things like that.

+ +

And when I switched to a three-day week, I was able to reclaim some amount of investment time. And it was interesting having that open back up and have that be a consideration. Because definitely one on ones and things like that I think firmly fit within the idea of investment time or investing in the organization and whatnot. But still, there's the like; I'm going to go explore a new framework or something like that that also certainly fits within investment time. So I'll be interested to hear if you find that changes in sort of a specific way.

+ +

STEPH: Yeah, I'm really interested in that as well. Because right now, as you mentioned, my investment activities are really focused more around the team and other folks and then Bike Shed. Bike Shed is a really big investment time activity. So I've noticed since becoming a co-host for the show, I talk a lot about code, but I don't necessarily contribute to open-source projects or other internal projects at the rate that I used to. It's now more focused about here and being a co-host and talking about all the things, and that requires some prep for me.

+ +

So I'm also interested to see if this will shift my investment time a bit where I do find a little more time to code and then explore just things that I'm interested in. But in the experiment of doing something new, it's always important to then have a way to measure is this a good change? Is this a bad change? So we have been checking in with team leads to say, "Hey, we've changed your schedule to where you're billing one day less. How's that going for you?" Because there's the assumption that this will be great, but you really have to check in with folks to find out.

+ +

So Edward Loveall has been sending out a helpful survey and checking in to say, "Hey, how are you feeling about your client work? How are you feeling about your team lead responsibilities? How are you feeling about investment time?" So then you can track your own growth and see is this really helping me? Is this really going in the right direction, or am I just more stressed about everything now? So that's helpful that we are also just looking back to make sure that this is supporting the initiatives that we said it would support.

+ +

But that's some of the newness in my world. What's going on in your world?

+ +

CHRIS: What's going on in my world? Continued adventures in the world of hiring. So we've got a couple of people in the pipeline now. We've got some folks in the technical interview phase, which we're structuring our technical interview very much inspired by the thoughtbot interview. So it's a pairing session as well as some code review, which is great because I think it's really representative of the actual work that we do.

+ +

I believe strongly in not having an interview that is trivia or anything of that sort of thing. I want to see folks at their best as opposed to finding the rough edges. Because I think it's critical to have an interview that really represents the work that we're doing and then also gives candidates an opportunity to show themselves at their best as opposed to trying to hunt out gaps in knowledge or things like that because I think it's easier to shore up a gap of knowledge. But I really want to know what is this person like when they're firing on all cylinders?

+ +

So, so far, that's going great. But hiring is a complicated long game. So it will probably be a thing that I'm talking about for some weeks to come. And if anyone out there is listening and is potentially interested in a new adventure, I would love to chat with you. Sagewell Financial is hiring. And it's a wonderful Rails codebase and lots of new opportunities, et cetera, et cetera.

+ +

STEPH: As someone that has worked with you, I can absolutely vouch that you are amazing to work with. And I can only imagine the codebase must be...everything we've talked about is really interesting and stellar. So yeah, I love that you're talking about this. I think it's awesome and a great opportunity for folks to get to join Sagewell.

+ +

CHRIS: Oh, thanks, Steph. That's very kind of you. But in other unrelated to hiring news, one of the things that I talked about in last week's episode was my search for a new to-do list or a new application to use. And I listed some of the ones that I've been exploring. We got more feedback about that particular segment than any other by like 2X. And there's something to be said there. Maybe the show is just living up to its name.

+ +

But so many people are reaching out like, "Oh, have you looked at this one?" And to be clear, I very much appreciate all of the feedback that folks have given. And actually, it has given me a few new things to look at or ways to think about this question. But mostly, I find it very funny that even though we've dabbled in topics like agile, and is it good or bad? Or other contentious ideas [laughs] like that, somehow this idea of what to-do list application should I use by far the most engagement we've seen with our audience.

+ +

STEPH: I think it makes sense. Everybody has an opinion. Like you said, we're living up to our name, which is great. Was that great? I don't know. [laughter]

+ +

CHRIS: It's something, I'll say that.

+ +

STEPH: It's something. But yeah, everybody has felt this pain. They get it. It resonated. But since we do have some people that shared their strategies and their thoughts, did that sway you at all? Are you still going to keep with what you have, or are you going to explore new things?

+ +

CHRIS: I consider this project open. I have a project in Things, which is the current to-do list application that I'm using to explore the landscape. But it's basically like, I want to timebox it, find a version that works for me. And right now, I moved to Things, and it's fine. I'm more intrigued by the jobs to be done aspect of it. So as opposed to a particular piece of software and the features that it has or doesn't have, I really want to think about the habits and workflows that I want to make easier and more repeatable.

+ +

So particularly, each day, I want to wrap up by cleaning everything up. I like my inbox zero, as you probably know, so doing a little bit of that, and then planning the next day. So I want to have a tool that supports that idea of I want to queue up what I'm going to do in the morning so that tomorrow morning when I start back up, I have a very clear list of things to do. And I can just dive in with what I find to be some of my best thinking time early in the morning.

+ +

Similarly, I want to be able to review on a regular basis and know if things are getting stale or overdue. So there are a couple of different workflows that I'm really focusing on. And it's unfortunate because then I look at each piece of software, and I'm like, well, you kind of support this but not totally. So I'm more in a collecting phase right now. I'm thinking about the workflows that I want to have and then finding the different tools and comparing them across those.

+ +

But the one thing that I have done at this point is I wrote a little Siri shortcut I think is the name for it. They're called Shortcuts is the name of the application, but if I try and Google that, Google doesn't really know what I'm talking about. They think I'm talking about my phone, but I'm not talking about my phone. I'm talking about my actual computer, but it's little workflow automation stuff on OS X.

+ +

And so I have a shortcut now that prompts me for the amount of time, and it defaults to 45 minutes. And then, it will turn on Do Not Disturb for 45 minutes, minimize Slack, because I can't be trusted, and turn on a particular Spotify playlist.

+ +

And then there's a little menu bar application that...I wrote a tiny bit of AppleScript; I found it on the internet and actually read it, that finds the top task in my to-do list and puts it in the menu bar. And so now I have all of that. I push a magic button, and I say, "Yes, so I would like to work for 45 minutes on the thing that is at the top of my to-do list.” And then all of the noise of the world goes away for 45 minutes or however long I say.

+ +

STEPH: I think you just created the next new hot to-do app. [laughs] This sounds like something that I need and love, especially when you're like, it autoplays a playlist for you and shuts down the world and then has you focus. Yeah, I like this. I think this also rings a bell. I feel like Momentum, or something also has similar prompts. But this sounds delightful.

+ +

CHRIS: If we're being honest, it's an absolute hodgepodge of a kludge. You have some weird shell scripts and some AppleScripts. And I had to install a weird command-line utility for Spotify to make it happen. But it was one of those like; I'm spent at the end of the day. I just want to tweak on some piece of code. And this was a perfect, productive distraction, is how I would describe it. And when I've used that, I've been very happy. I know the days that I actually lean into that mode of working are better days.

+ +

The days where I allow myself to be distracted by Slack throughout the day, although I'm responsive to certain questions, things are not moving as well as they should. And so, I'm trying to be really intentional with having more of these Do Not Disturb sessions throughout the day. I feel bad saying that. I shouldn't because we all should be in agreement that this is the way that we work. But even saying that, I'm like, I'm not that special. I should be reachable, right? [laughs] But I should take even just a short 45-minute break to focus on the work that I actually need to do. It's a struggle.

+ +

STEPH: I have struggled with that where I used to always feel such an urgent need that I had to respond to someone as soon as they messaged me. But over time, I've learned that one, things typically aren't as urgent as I will feel that they are. And then two, if you have that type of environment where people aren't expected to just immediately reply to stuff, then you learn to write things in a way that says, "Hey, when you see this, and here's context, and here are the things that I'm looking for. And here's an easy way for you to give feedback."

+ +

It just improves the overall communication. I could go on a rant about this. I think we've actually ranted about this before in a very positive way. [laughs] Yes, I think that's great that you are fighting the good fight and turning off the world for 45 minutes to focus on a task.

+ +

CHRIS: What's a positive rant? I feel like there's got to be a word for that. [laughs] But I'm trying to try and come up with that. A celebration isn't...is this one of those gaps in language where we don't have a word for a positive rant?

+ +

STEPH: Oh, this is going to bother me. [laughs] There's got to be something for a positive rant.

+ +

CHRIS: Well, I'm sure German has...some Scandinavian language or German has a more specific version of when one goes off on a rant for many hours about things that they love and are joyous about in the world or something like that. But maybe English is just lacking this, or maybe this is a market opportunity. And we can coin the word, and then it's ours.

+ +

STEPH: I think it's just praise or accolades, although that doesn't feel strong enough. Rant feels like such an emotional word that I agree praise doesn't feel strong enough.

+ +

CHRIS: It's also spacious. You don't just rant, and it's one word. It's not just like one swear that you yell in the word. No, it's this long rambling thing, and I want that but positive. Maybe it's just called The Bike Shed [laughter] because I think that might be what we do.

+ +

STEPH: I love that. I'm trying to smash it together, and all that I can come up with is prant, so that leads with a P.

+ +

CHRIS: Yeah, I went there real quick. [laughter] Portmanteau is where I spend most of my time. But prant is just not enough. Okay, we're going to take this offline. I think we should come up with a word. This is our market opportunity. I don't know that we'll make a lot off of this, but we'll have a word then.

+ +

STEPH: It's okay. Free things are good. Oh my goodness, this is going to be so trivial and silly. But I've been playing Wordle as the rest of the world has. If you're not playing Wordle, check it out. [laughs] It's delightful. And it's free. But I started playing without really researching who created it and didn't have all of the details behind it.

+ +

And then it was earlier this week I found out that the creator of Wordle is Josh Wardle. And that just blew my mind and made me so happy that it just had that alliteration and similarity. And I just hadn't put it together until that moment. And it was just this wonderful, happy bubble of a moment where I was like, oh, that's delightful. [laughs] And I'm pretty sure I texted some people who were like, "Yeah, yeah, we know that." [laughs]

+ +

CHRIS: Yes, that was a wonderful positive rant or prant as it were there. And Wordle really is just such a delightful phenomenon that popped out of nowhere and is given away for free by the kindness of Josh Wardle. So yeah, wonderful things on the internet.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: We have a listener question this week. Once again, just as a reminder, everyone, we love getting these listener questions. Feel free to send them into hosts@bikeshed.fm or ping Steph or I on Twitter or any number of different ways. There's, I think, a form that you can go to the website, lots of different ways to ask us your questions. But again, we really love them. They let us have more pointed topics to talk about, such as today's topic, which is "What do you consider a quote, unquote, "large table" in a database?" Which is an interesting question, I think.

+ +

And so, let me read the question here. "Hey, Steph and Chris, I’ve listened to you (and most of your predecessors) for a while now. I've really been enjoying the conversational style about your actual development struggles." Thank you so much. This comes from Matt, by the way.

+ +

"Anyway, something Chris said in Episode 301 triggered a thought for me around large tables and databases and handling them for development tasks. What do you consider a quote, "large table" in a database? What questions/considerations come to mind when you're doing PR work that has a database interaction in it? We recently needed to delete a lot of rows out of a large table, and the team has a lot of discussion around how to handle it without impacting our production users. Curious on your thoughts. Thanks."

+ +

So, Steph, what do you think? What's a large database table in your mind?

+ +

STEPH: So I don't have a scientific answer for that, but I can give you my gut instinct. So typically, if there's a table that has a million or more records, I'll refer to that table as a large table. And then, if a table has around half a million records, then I start to be more cautious about data changes and how I'm rolling out schema changes. So that's my very loose; this is my feeling of when we're getting into large territory. How about you? Do you have more of a concrete answer?

+ +

CHRIS: I don't. And I think it would actually, in a lot of cases, be defined based on the database system that we're working with and, frankly, the RAM available on that system. There are two different sides of it; one is on the right side, like, how quickly are we inserting data into this table? And how quickly is it growing? Is probably a better question. Maybe there's a ton of data in it, but it's not growing that quickly. And so, we don't need to worry about any runaway characteristics.

+ +

The other side of it is how easily can we read from it? And that is the one that's going to be RAM-constrained. Where can we maintain an index efficiently? Can we query effectively and use RAM and whatnot? So a million starts to become an interesting number, probably. But I've worked on plenty of databases where hundreds of millions of rows existed, and we've got efficient indices in place and enough RAM that the database just happily works with that, and there are no problems.

+ +

So really, it's a question of like, if we start thinking about having to need to delete data, then that's a large table. If we have one table that is wildly larger than the others in the system, then that is something that I'll keep an eye on. I want to make sure, like, how's that table doing? How's the special table doing?

+ +

And often, there is one or two special tables similar to the idea of god objects within a system where these are the one or two classes that have just method after method after method after method. Similarly, there are one or two database tables that often have the lion's share of the data within the system. And so those are the ones that I'm really focused on.

+ +

And especially as we get closer to the RAM limit, there's this drop-off that I've seen happen where a system is like, it's fine. We got 250 gigs of RAM; there's no problem. And our database is only 100 gigs. And then a couple of weeks later, suddenly, had a bunch of new users sign up, and suddenly, your data and your indices no longer fit in memory. And now we're paging to disk, and suddenly the performance characteristics of your system just tank. And so it's that sort of thing. Watching growth rates is perhaps more important than the absolute size of any individual table. So yeah, those are some loose thoughts.

+ +

STEPH: I like how you used the word interesting. I think that's a nice replacement for the word large. When we get around a million records, things start getting more interesting in how we're rolling out schema changes. And then there's also you touched on usage, which aligns well with I often don't think so much about how many records that we have in a table.

+ +

But what's the usage of that table? How many queries or transactions are being executed against that table? Is this a very popular table like the users table? And will running a migration that renders that table inaccessible for a couple of seconds will that be problematic, or is this a table that we write to a lot, but we don't read from very often?

+ +

And even if it runs a couple of seconds, it's not likely to have an impact on people using the application. So that's one area I tend to think about first is what's the popularity of this table? And how cautious do I need to be in making sure that we don't block other people from accessing this data?

+ +

I also really like how Matt asked the question about what considerations come to mind when you're doing PR work that has a database interaction? That's one of those areas that, honestly, I lean pretty heavily on Strong Migrations to remind me how I can rewrite a migration to avoid or to transfer a blocking operation to a non-blocking operation.

+ +

So a really good example is setting a NOT NULL constraint on an existing column. I know that it can be very blocking if you try to do that by default when you first run it, and I will look it up every time. I will check Strong Migrations and say, "Hey, I know you've got some really great docs that will walk me through about adding a check constraint instead," and then making sure that I can then add this new column.

+ +

So going forward, for inserts and updates will apply the default, but it doesn't validate all the existing data. It's also a really good reminder, that particular example, is start with stricter constraints because it's a lot easier to remove a constraint than to add one later. So that's one consideration that comes to mind.

+ +

I also think the fail fast and fail loudly applies nicely here. So if I'm looking at a PR that is making a schema change, then I want to validate that the application has low timeout values so that way if a migration does take more than 30 seconds to run, then the migration will timeout. And then that will alert the developer to say, "Hey, do you need to think of a new approach or see if there's a way to improve this?" Versus if that migration didn't timeout, then that timeout is going to become user-facing as they start to experience problems with the site.

+ +

And then also looking for more performant methods so using find_n_batches, update all, delete all, just checking for the more performant ways that we can update large sets of data. Those are, I think, the top things that I really look for. How about you?

+ +

CHRIS: Yeah, I think very similar to everything you just said. And broadly, there's a point in time that happens frankly pretty early on in the growth of an application and the data set behind it where you need to start behaving differently with regard to migrations. There's a small period of time where I can just get away with anything.

+ +

I actually really love the part before we have any actual users where I'm like, oh, we need to change this fundamentally. I'm just going to drop the table and rebuild it because it's easier than trying to think about how to migrate this data. But so quickly, you get into a place where it's like, nope, sorry, can't do that have to treat this as realistic.

+ +

So a bunch of the strategies that you're describing, like indexes concurrently, is one of the things that I'll reach for often because that allows me to decouple the timing there and not...again, the migration timeout that you're talking about is absolutely something that I want to have. Migration should go through quickly, and if they can't, then we need a different approach. Maybe we need to introduce the new column right to that one in parallel to the existing column, and then eventually do a switchover. It's definitely more work and involves a couple of deploys to get that done, but that's the unfortunate reality that we have to move to.

+ +

I will say one of the things we talked about is like, if we hit that timeout, then we're going to stop that migration. This is a critical feature that I rely on deeply at Postgres, which is that schema migrations or DDL transformations; if I'm saying that correctly, I'm not sure I am, but throwing an acronym out there, it'll be fun. This is actually one feature of Postgres that I really rely on.

+ +

My understanding is that Postgres has this; MySQL does not, but I may be off. I know that Postgres has transactional DDL transformation, so schema migration sort of things. I'm adding a column; I'm removing a column, et cetera. Those inherently happen within a transaction, and that's wonderful because if they do timeout, we want to be in a consistent state.

+ +

The worst thing I can possibly imagine is being like, we got halfway through, but then we failed, or we lost connection, and so it's half migrated. It's like, oh God, I want to trust my database deeply. That's sort of one of the fundamental things that I have. And I've, over time, pushed more and more into the database and saying let's have check constraints. Let's have null true and all of these sorts of things so that the data in my database can be deeply trustworthy.

+ +

The idea that a schema migration could go awry, and suddenly we've got like, well, half of the rows have these extra columns. What does that even mean? How do you live in that world? So I love this feature of Postgres. I really rely on it. I feel very bad whenever I have to disable it. I think there are some enum-related things that require disabling DDL transactions. And whenever I type that in a migration, I'm like, I don't like this. I'm not happy about this, but it's the world we live in for now.

+ +

STEPH: If we're sharing our truths, yeah, adding an index concurrently also you have to remove that DDL transaction and disable it. For a previous project that I was working on, we often ran into that timeout where we'd run a migration, and then it would timeout. And we would then just specify and be like, "Hey, for this migration, I'm going to bump you up to a minute. I'm just going to make it longer."

+ +

And that felt questionable at times, but I at least appreciate the explicitness of it where you're making that decision to say, nope, I think this is fine. It’s not going to impact anybody, or we're going to run it in off-hours. I do want to extend this to a minute, and then make sure you do reset it, so it doesn't affect it globally from there on out.

+ +

But that's something that you can do, and I have done before, which I feel is important. You still want to know some of your outs in case you do need something like that just to fix things in a moment but then at least be intentional for when you're using it and then communicate to the team like, "Hey, I'm doing this and let me know if you have concerns about it."

+ +

For this specific scenario that Matt provided about we recently needed to delete a lot of old rows out of a large table, and the team had a lot of discussion about how to handle this without impacting production users; I happened to have a really nice conversation with Steve Polito, a fellow thoughtboter, about this particular question. And he had a very thoughtful response that I hadn't considered where he suggested starting with deleting the data for a small set of records.

+ +

So, for example, if you're working with a users table, you could scope the data deletion to only inactive users and then use a feature flag to disable any interactions that would be affected by that data loss, run that change to delete the data for those inactive users, and then check for unexpected errors or side effects.

+ +

So then that way, you have this moment to pause to say, "Hey, did we forget something? Is there something about this application that's still relying on that data that we forgot about? We've only done it for a small amount of users, so we're in a safer space." So then, at that point, you can either repeat those steps for another batch of records or use that feedback to then drop the column with confidence. And that was an approach that I hadn't considered, but I really liked that idea.

+ +

CHRIS: Yeah, it's a nice, I'd say methodical approach to what can be a very complex and difficult to wrangle task. I will say I haven't actually explored this too much, but I've always had in the back of my mind, like, if we're deleting data from the application, ideally, we're saying this data is no longer needed.

+ +

But I wonder if using table partitioning is an alternative that can be useful in these cases. What if we're able to figure out the correct partitioning? It's often time series sort of stuff. What if we're able to lean into that and say, "Let's partition this by year." And then yeah, we don't use the old data anymore, but it lives in a separate partition. And therefore, I think Postgres is able to do reasonable things with that.

+ +

And again, like disk space, we can have a lot more storage on disk, but RAM is really going to be the constraining factor of how much of the index fits in memory. And again, I haven't pushed on this. But I think that's an alternative approach that can be really interesting. But if we do have time-series data, in particular, Postgres is wonderful. But it's not necessarily honed exactly to that use case.

+ +

And so, there are a couple of tools that I've kept an eye on right now: ClickHouse, Timescale, and InfluxDB being the three of them. And I think most if not all of them are based on Postgres, but then they build on top of it. And they add some deeper understandings of time series data and how to optimize querying and storing, and all of that. And so, is that an alternative that allows us to still stay in this world but then have a different approach and alleviate some of the burdens that might come with this heavy data that we have?

+ +

STEPH: Yeah, all those sound interesting. I haven't heard of some of those. This is why I love chatting with you. You always bring interesting perspectives that I had not considered before, like the partitioning. Just to clarify, partitioning the data is a way of keeping that data, but then it's not indexed. So that way, your system isn't spending as much time making sure that data is easily readable. But then that way, you don't actually delete it, so then it's there should you wish to be like, oh, I wish I hadn't gotten rid of that data.

+ +

CHRIS: I think so. I'll be honest; I don't deeply understand it. But I think you basically can say given a giant projects table within your system; we actually may have that logically grouped by user sort of thing. And so we can shard and partition and say, there are ten different buckets of these. And if we optimize it well such that all of the things that are logically together actually live together on disk, then it allows Postgres to be much more efficient.

+ +

Similarly, with time-series data, then you can say, use this sort of windowing where it's each month, we get a new bucket. And then it's much easier to query across just that bucket because it's already sort of partitioned down in that way.

+ +

But I'll be honest; I'm now speaking well past my actual knowledge. I've never actually worked with it. But it's one of those things that I have in the back of my mind. Like if all of my other tools fail me and if I cannot solve these performance problems in a Postgres system with indexes, and tuning, and other things like that, then I will look to partitioning. So I look forward to that day when the data problems are so massive that I need to table partition.

+ +

STEPH: Got it. Like they say, it's a good problem to have. While adding to the list of tools, there's one that I discovered recently; it's called Safe PG Migrations. And it's very similar to Strong Migrations, where Strong Migrations will warn you and say, "Hey, this is not safe. There are other ways to write this migration." Safe PG Migrations take some more aggressive approach and will rewrite your migration to be a safer version. And I don't know how I feel about it. I love it, and I hate it. [laughs]

+ +

It's one of those the magic is there, and that could be phenomenal. But I get squeamish when things want to rewrite something as important as my migrations. But on the other hand, it is like a really nice default for the team because it's more than a warning. So that way, if you're trying to put something more strict in place for people to follow, then this would be a good way to do that.

+ +

CHRIS: I'm very intrigued by that as a tool because if it were obvious, then Postgres would do it. The team behind Postgres does absolutely amazing work. And so if I tell them, "This is the change I want to make to the system," and they're like, "Cool, we're going to do that super inefficiently," and someone else is like, "No, no, no, I can trick it." Postgres is good at tricking itself, is my stance.

+ +

So I'd be intrigued as to what secret knowledge they have or what are their caveats where Postgres has to handle every possible edge case. And therefore, it's slower because of pessimistic concerns that it has. But this tool says, "No, no, as long as you're not doing this very terrible thing, you're fine. And we'll rewrite it to a safer, faster version." But I'm just kind of intrigued, like, why do you think you're better than Postgres?

+ +

STEPH: [laughs] Why do you think you're better? Well, I do you have an example I can provide. It's one that they have on their README. And this one highlights that if you're adding a column to an existing table and that you're adding a default value and no constraint, then they show you how it's rewritten where they set explicitly the lock timeout, and then they will add the column.

+ +

And then they will set the default value but not in a way that it's going to do a table scan where it's going to add it for all the existing records; it's going to be for new records. And then they, let's see, they also update the users in batches to then set a default value, and then they will reset the statement timeout because it looks like they are...yeah, because initially, they change it, so they're resetting it to an original value. And then, they set the column Null constraint. I know I just said a lot of things reading from their README.

+ +

But they have a good example here that kind of highlights that this is how they rewrite it. So I do find that more reassuring as long as I can then see how it was rewritten, and then I can validate it and confirm it with what I think is appropriate. Then I still have full control. Then it's more of a hey, we rewrote this thing for you. Feel free to review it and then change it as you see fit. As long as I have that final authority, then that makes me feel better about this.

+ +

CHRIS: Got it. That makes sense. And the thing that you're describing, I think, is a semantically different thing than the first migration where it's like, do this thing. And they're like, well, okay, you could. But if instead, you did X, Y, and Z, then it would go way faster and be way easier. That makes a lot of sense. And it feels like shared knowledge wrapped up into a tool which I'm always a fan of that.

+ +

STEPH: Yeah, in general, when I think about general strategies for schema changes, there are really three areas that come to mind or three strategies that come to mind. The first one is that we take incremental steps to avoid blocking reads and writes to the table, which then allows you to deploy during business hours or off business hours. That often means just more manual steps that you have to take to make sure that it's safe. And then the other one is scheduling downtime to run a migration. That is a very real option, something that you can do. Or have a fancy setup that utilizes followers for seamless migrations and upgrades.

+ +

I feel like that's like the three big buckets that you can fit your strategy within. And it just depends on the needs of your application and users as to which one of those you're ready for or which strategy you need to use. What do you think? Are there any other big buckets that I left out of that list?

+ +

CHRIS: No, I think we covered a bunch there. Hopefully, that was useful. Hopefully, it, I don't know, maybe introduced folks to some new ideas or ways to think about this sort of work. And yeah, with that, shall we wrap up?

+ +

STEPH: Yeah, I've still got my Wordle to play for the day. So let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

ALL: Byeeeeeeeeeee!!!

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MRrJLxD3 + + ]]> + + Chris Toomey + Steph Viccari + + + 324: Coding Time! + https://bikeshed.thoughtbot.com/324 + 2b6b1f1d-8d32-48e5-8d72-ae8293671e90 + Tue, 01 Feb 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Chris updates us on his new window manager of choice, Moom, and tells us what's good with it. He's also giving yet another task manager a go: OmniFocus. (Sorry Things.) Steph talks about defining test classes in RSpec and readdresses flaky tests to improve CI build time. + +Chris is worried about productivity. He's still not coding as much as he'd like to be. Steph lends an ear, and together, they discuss potential ways Chris could gain back a little bit of coding time at work. + 41:23 + no + + + Chris updates us on his new window manager of choice, Moom, and tells us what's good with it. He's also giving yet another task manager a go: OmniFocus. (Sorry Things.) Steph talks about defining test classes in RSpec and readdresses flaky tests to improve CI build time. +Chris is worried about productivity. He's still not coding as much as he'd like to be. Steph lends an ear, and together, they discuss potential ways Chris could gain back a little bit of coding time at work. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Moom (https://apps.apple.com/us/app/moom/id419330170?mt=12) +OmniFocus (https://apps.apple.com/us/app/omnifocus-3/id1346190318) +Is It Worth the Time? (https://xkcd.com/1205/) +Knapsack Pro (https://knapsackpro.com/) +Shopify Monolith (https://shopify.engineering/shopify-monolith) +Sacrificial Test Classes (https://blog.bitwrangler.com/2016/11/10/sacrificial-test-classes.html) +rspecq (https://github.com/skroutz/rspecq) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, what's new in your world? +CHRIS: What's new in my world? Well, hey, Steph. Oh, I have an update on a thing that I think I talked about a while back or at least asked on Twitter. But I've been looking for a window manager for forever. And in that way that I sort of overcorrected a while back, I think where I'm no longer allowed to do anything related to productivity or dev tools. I was just forbidden because it was a time sink. I'm slowly trying to correct back and be like, you know what? I regularly think about how it would be nice to have a better window manager. +So previously, I had used Divvy, D-I-V-V-Y, which is fine. It did an okay job, but it just didn't have quite the level of control that I wanted, or maybe I didn't investigate it enough. But it felt like it was lacking. So I did a little bit of research. A bunch of people recommended different things. There was Spectacle; there was Rectangle. There was a whole bunch of other things that I'm forgetting now because I have settled on Moom, M-O-O-M. Those are fun words. +STEPH: I feel like you keep bringing interesting words [laughs] because last time, it was Things where you're tracking all the things. And now we have Moom to track the space. All right. +CHRIS: If this is my legacy as a podcaster, then I feel like I will have done well just, you know, weird sounds mostly that's what he's going for. But yes, I've been using Moom now for…[laughs] God, it's just ridiculous to say, but here we are. +STEPH: [laughs] +CHRIS: I've been using it. I've been enjoying it. In particular, the thing that I liked about it...a bunch of the other ones that I looked at were like, oh, we've got all these different configurations. And you can move things any which way, and you can have any number of hotkeys. And I was like, wait, wait, wait, say more right now. You want to take over my global namespace of hotkeys and just clutter it with 19 different things? You know that that is a limited space that I'm working with here. +And so Moom, somewhat uniquely, at least in the ones that I experienced, was what I would describe as a modal window manager. So much like Vim is modal where you start out in normal mode, and you're moving around and you kind of bounce and search and all of that, and then you enter insert mode. And in insert mode, keys do different things. And then in command mode...it's got all these different modes. And so there are lots of different namespaces for hotkeys. It's one of the things that makes Vim so powerful. +Moom is similar in that there's one global activation hotkey. And then, within that, I can have a whole namespace of hotkeys. So like M will put something in the middle of my screen now. F will put something full-screen. And I don't need to remember weird multikey combinations for that. There's just the one to get started, and then I've configured it such that the tab will bounce to a secondary display and sort of rotate through them. +M and F and Q and P I've got it physically laid out on the keyboard. So it looks like my screen. Q being on the left side will push something to the left side, P to the right side. And I'm very happy with that. I don't need a lot out of this tool. I don't need very complex management or scripting or any of that, which are very nice features that exist in the other ones. But that combination, the one hotkey to rule them all, and then the sub hotkeys within it, and the ability to mostly move between the screens and then put stuff where I want it is great. I'm very happy. +STEPH: I think I've figured it out. So Moom, I think it's a combination of move and zoom, and that's how they got Moom. +CHRIS: You're probably right. +STEPH: That does sound really nice. I'm a Spectacle fan. And I have enjoyed it and just stuck with it because I haven't felt a need to change from it. And it's really nice where I use my arrow keys for which direction I want to go. So that has been easy for me to recall. But that sounds really nice, all the things that you're describing with Moom. +CHRIS: Does spectacle have the like, is it some Command Option Control and then left or right or up or down? Or is it you type something, and then you type left, right, up, down? +STEPH: I have to actually touch my keyboard to answer that question because I have the muscle memory, which is an interesting thing that my muscles knows it, but my brain has to really think about it. So I think it's like the Option Command, and then yeah, then use the arrow keys. +CHRIS: Gotcha. That's roughly what I had when I was using Divvy previously, but I found just enough of a limitation there. And so Moom has been great as another tool. But I think Spectacle has a lot more features in terms of scripting and other fancier stuff that you can do, which is both super intriguing and, again, sort of the thing that I'm not allowed to do. [laughs] So I went with, like, this tool seems fine and has the one feature that I really want. +That said, you brought up Things, which is the to-do list app that I've been looking at. I've been using it for a week now. It's great. I'm enjoying having a more structured way to say, like, here's what I'm doing today. Here's what I'm doing tomorrow. It's been wonderful. But I'm already looking at OmniFocus as a better version. +STEPH: [laughs] +CHRIS: Because I think there's some stuff that I don't love, and yes, I can hear my own voice in the back of my head that's like, always chasing that next thing. But I haven't actually made the effort to switch over or even tried. I've used OmniFocus in the past. But anyway, I'll let you know if I do make additional moves there. +STEPH: Yeah, I'm enjoying this journey. Keep me up to date on it. I've heard of OmniFocus, but I know nothing about it. But I feel like I've heard good things. So I like this journey you're going on where you just keep switching and trying new things. That's fun for me [laughs], and there's chasing productivity. So I'm into it; I'm here for it. +CHRIS: If I just invest enough hours to save a handful of minutes down the road, then I will have...oh no, wait, that's not how this goes. There's, of course, an xkcd about this which we can include in the show notes. But I'm trying to be very intentional with it. I waited for many years before I allowed myself to reinvestigate the world of to-do lists. And I'm hopefully going to keep it to just a couple of weeks of nonsense and then back to a few years of stable. That's the dream. +But yeah, that's some of the smaller things that are up in my world. I have another topic that I want to chat about. But I'd love to hear what's new in your world? +STEPH: Yeah, I have some interesting bits that I can talk about with the project that I'm working on. But more concretely, I have something that's been on my mind that I don't think that I've talked about here on the show, but I think would be fun to talk about because I just happened to run into it this week while working on some code. +And it's the idea of defining test classes in RSpec so as you are testing part of your code, but then you want to create just like a fake class, something that you can use as a substitute for real application code. And so it's a really nice way that then you can have this replica behavior, but then maybe it's just one particular method or some behavior that you need to use in the class but then doesn't actually go to the real code. That's wonderful. That's great. +One thing that I've learned is that with RSpec is when you are introducing a test class, so let's say if you have your RSpec describe and then either a string or it's the name of a class, and then you have a block so do, and then within that block is where you write your test. If you create a temporary class, say, like I have my class test class, and then I have some behavior, that gets defined in the global namespace. It's not scoped to that particular RSpec example. And the reason for that it's not specific to RSpec. RSpec is not the one that's doing this; it's actually Ruby behavior. +So for Ruby, when you're defining within a block like that, if you're defining a constant, if you're defining another class inside of a block, it's going to use the outer namespace as its namespace. So if you had a top-level class that you were defining, but if you define a class as a block, and then inside of that block you define a constant, that constant is then defined in the object namespace instead of within that particular class that you have written. And so that's why RSpec has this behavior. +Because someone brought up a really great question about this on RSpec::Core asking about it, and they're like, yeah, that's actually how Ruby works. And so we're not going to change RSpec's behavior since that is how Ruby has decided to handle this. And the part where this becomes important is when you define a test class within an RSpec example. +While it may be unlikely that someone is going to use that exact same name for their test class that they're going to create in their RSpec example, if they were to use that same name, then you're going to have a collision between the two. One of them's going to win, and you're probably going to end up with some really weird test failures because it's going to get confusing as to which class is being used, and they may not match up with each other. +So one way around this, and this is going to be one of the rare times that I suggest this, but let. Let is scoped to an RSpec example. And so you could define a class inside of a let, and then that will scope it to the example. There are probably some other approaches as well, but that's the one that I'm most familiar with to ensure that when you define that class or constant, it's not getting defined in the global namespace and ensuring that none of the other tests have access to it. +CHRIS: Well, this is certainly interesting. I'm pretty sure I've been operating under the opposite assumption for the entirety of my career. This is good to know. I feel like I probably have had tests that failed because of this. And then I learned this truth, and then I subsequently forgot it. I don't know if you know this, but if you define a method within just a helper method that you extract in RSpec, are those also on the global namespace? +I don't define classes in RSpec blocks that often. It's pretty rare. Like if I have a controller concern sort of thing that I want to test, I might say random controller and inject the thing there or some other abstracted piece. That is the only case I can think of where I have a fake model or a fake controller or something like that for test purposes. But it doesn't come up that often. I do extract a heck ton of local helper methods. And I'm wondering now, are those all in the shared global namespace? +STEPH: I'm pretty sure they're not. And I'm getting on the edges of my knowledge here, but I think it has to do with the fact of when you're defining a constant. So if you're defining a class versus an actual constant, that will get into the global namespace because it's using the outer scoping. But in my experience, I'm pretty sure that's not true for the method just because I remember one time I did some funky stuff with RSpec. And I remember seeing that I couldn't access those methods from another example. +CHRIS: I like the honesty. And you're like, to be clear, I was doing something weird, but I learned that day. Okay, that's good because at least that part maps to my understanding. So methods may be safe, but classes get shared. Very interesting. +STEPH: And it's something that I rarely think about or had worried about just because if I'm defining a fake test class, I often will put it somewhere that's intended to be more global. So I'll stuff it somewhere in like spec support. So then other people can see, hey, I've already mimicked this behavior. So if you need to use the same thing, just go ahead and use this. It's not often that I am adding that class directly to the RSpec example group. +So I think I've been fortunate where I haven't actually run into that conflict for that reason. But this came up while giving an RSpec course. And while we were just in a very small, tiny codebase and replicating some examples, someone in the class was like, "Hey, by the way, do you know that that's in the global namespace?" And I was like, "No, friend. Tell me more." So thanks to that person, they're the ones that actually enlightened me about how it's going into that namespace and how it can actually pollute your testing namespace. +There's a really good article that's written by Ken Mayer. And we'll be sure to include a link in the show notes that talks about it and also provides the let example as a way to work around this. And also links to the GitHub discussion on RSpec::Core, where they talk about this behavior and why things are the way that they are. +Circling back to some of the more general project-y things that I alluded to earlier, I've shared a bit about the project that I'm working on. But just to recap it, it is focused on helping a very large team that has a large number of tests, around 85,000. And they are looking to address flaky tests that they have and overall really improve their CI build time. So right now, it takes about 30 minutes for the build to take place. But they also have flaky tests, and then that slows things down. And so, the re-verify rate has been painful for them. +There's been some really great work that has improved that, particularly there is a, I think we've talked about this before, but where they're re-verifying certain flaky tests, which isn't great because they're still flaky tests, but at least they're not preventing people from moving forward and shipping code. +But some of the bigger stuff that is just on my mind is when you have a very large team and a very large application, by large team, I'm talking about 100 developers, and they are all contributing to this codebase. And there are around 85,000 tests, and that has grown substantially in the last 12 months. And so, if you think about the trajectory of the addition of those tests, it is just going to continue to grow. So there's a concern there of even if we address flaky tests and we improve things, there's an architecture concern of how do we really reduce the CI build time? +And so there's that aspect, and then there's also the aspect of then well, how do we still work to improve the tests and the codebase as well as we go across all of these disparate teams? And right now, there is a bit of a culture where engineers don't feel empowered where they can necessarily address all of the flaky tests or things that they run into. And so there is a bit of a mindset of I'm stuck on this, or this test failed, or it's flaky, or I don't understand it. So I'm just going mute it, or I'm going to hand it off to someone else to work on it. +So there are three big areas that are on my mind. The first one is architecture. You can throw architecture at it. There's also the code quality that's a concern. And then how do you improve the code quality in a way that you're improving it fast enough that then you've got 100 other developers that are also contributing to it at the same time? And then individual IC empowerment where then people feel like, hey, I ran into a slow test or a flaky test, and I feel like I can triage this, and I can make changes. +For the architecture piece, we're still in the infancy stages of how to approach this and the strategy that we're using. But one of the ideas that has come up is how do we reduce tentpoles? And the tentpole is like when you're running your test and, let's say that it's parallelized, all of the various tests. But there is one process that takes like 20 minutes, and then the other process is completed in 5 minutes as a drastic example. +And overall, you could have reduced your time if you had managed to split that 120-minute process across all the other workers who are then available for that work. So there are some tentpoles that are taking place. And that could be one first step in reducing the CI build time. +There are also discussions around how to scale horizontally. Right now, we don't think that's something we can do with the service that we're using to run the test. But it's something that maybe we need to manually look into is then how do we build a queue of all these tests and not where we just split test by a file, which is typically how the Parallelize gem does it. +But you could actually split up tests within a file. So if you had a particularly large file, that doesn't necessarily matter. But then building a queue of all these tests so then as each test finishes, a worker can just grab that next test. And then also you can easily scale up and scale down workers. As I'm saying that, that feels big, that's a lot to invest in. But that as an idea is how can we essentially then scale the architecture? So even as we continue to invest in the tests, in the system, and they continue to grow, our architecture can keep up with it. +CHRIS: That last bit there is super interesting to me. It's something that I've looked into and haven't pursued yet. We're currently running on CircleCI with our test suite. And I don't even know that we pushed on parallelization because we're early enough on that. And we turned off bcrypt recently, which super-duper helps with the speed up. But overall, the test suite time is fine, is where I would put it. +It had crept up, though, to a place where it was starting to be painful, is how I would describe it. And I think it's very easy for that to just continue growing and suddenly, it's 20 and 25 minutes. And then, depending on your merge strategy and all of that, it can be all the more complicated, and this gets in the way of deploys. And so, I think it is a super important thing to keep an eye on. I know Charity Majors pushes really hard for 15 minutes from merge to deploy to production. And so if your CI suite takes 25 minutes, then already you're stuck. +As an aside, I just once more want to say out into the ether, CircleCI or any other CI platform, if you would allow me to say yes, we've already tested this Git hash, this Git SHA, or the working tree, ideally, because that's also deterministic, I would love that feature. I would love to not have to rebuild the same code when it gets merged into main, just saying once more out into the world. Also, GitHub, if you want to put me on the merge queue beta, I would love that if anybody out there is listening. [laughs] +STEPH: I like how this has become a special requests hotline for all the things [laughs] that you're hoping to get a part of or features you'd like to see added. +CHRIS: Hello, internet. I have some requests. +STEPH: [laughs] +CHRIS: I would love to see those things, but in the world where those don't exist. The particular thing that you're talking sort of a test queue, is something that I've seen. So Knapsack is a...what's the word? It's a tool; it's a service. It's a combination of things. But it does that essentially where it starts up a local build agent. And then it basically says like, all right, give me all of the tests that you need to run, and then I will feed them back to each of the individual agents that there's one agent running per parallelized process. +And so say you've got five of them. The first one says, "Hey, give me a test," and runs it. And the second one says, "Give me a test," and et cetera. And so, the queue manager on the other side is in charge of that orchestration. And it means that they basically all finish in identical time, with one being an outlier, whichever one happens to be the longest. +But it's only going to be however long your longest test is is basically that outlier versus what you're describing of like, well, if we split it by file, we can end up with more naive things where there's a bunch of feature specs on one of them, and it skews by two minutes. We obviously don't want that. So Knapsack, in particular, is a tool that I've looked at, but generally, I'm very interested in that as a solution to how do we maximally take advantage of parallelization there? +STEPH: Interesting. I have not heard of Knapsack. There is one that sounds similar. It's called RSpec Queue. And it does some really interesting work where it will split the individual test, so it won't do it by file. It will also look at historical data to then try to be intelligent about how it's going to split it and find the longer running test. And I believe it uses Redis to then keep track of the test set up in run and things that still need to be run. That is a gem that the team is looking into using as well. +I don't know how that works if that can integrate with the current platform as we're using TeamCity to run tests. I don't know if that's something that can integrate with TeamCity, if it's a replacement. I don't have all of the knowledge about RSpec Queue yet. But it seems to do a number of the things that we're interested in. So even if we can't use the gem, then maybe it's something that we can still imitate. +CHRIS: The other thing that I'm surprised we haven't said yet is this is one of the places where people would often reach for microservices. I feel like we have to have the microservice conversation at this moment. Microservices can actually be a great solution to organizational problems. As a team scales, it does become really hard to manage a large group of developers. And so microservices introduces a very fixed boundary that then draws nice lines that you can have around things. And so, the individual build time for a portion of your application can be much more manageable by virtue of that. +But it has this huge cost of technical complexity and overhead and et cetera, et cetera, all of the reasons that we may not want to go that route. And so interestingly, I was just looking at Shopify's Deconstructing the Monolith blog post, which I think at this point, they've skewed a little bit more into the microservices. Shopify is huge, one of the largest Rails apps out there. And so looking at them and being like, oh, what are they doing? It's an interesting sort of plot a course and to see how long they waited before they even started thinking about the much deeper things and even exploring microservices. +But in this blog post, they talk about a different approach where they stuck with sort of a monolith. But then they started to introduce Rails engines and clear encapsulation within the large codebase such that then you can actually start to say, well, we don't need to run all the tests every time because if we're making a change within this section of the application, then we just need to run those tests. +I've also heard of organizations having some logic that can determine based on the code change; we know the associated test files that we should run. I'm scared of that is how I would describe it. I want to trust my test suite. I want to be able to deploy on a Friday and say if tests are green, it's going out to production. That's great. And I worry about that sort of thing. That's hard to get right. That feels like caching, right? And that's one of those things that we historically get wrong a lot. +But nonetheless, that is an approach that large organizations I've heard having good success with. So some way to determine what's the affected code and what tests do we need to rerun and et cetera. And that can really drastically reduce down the scope of each CI build. But those are some larger things that I have not had to reach for on any of the applications I've worked with. I've taken different approaches, different ways to reduce the time or otherwise Parallelizer et cetera. But it's interesting for when you get to a certain scale. +STEPH: Yeah, it's funny that you bring up that idea because that came up in conversation with some of the other developers as well, was the idea of, like, what if we could just not run all the tests? You changed one file, and you don't need to run everything. And I immediately was like, that sounds very cool and super hard to be able to get right. +And a lot of this code is extremely coupled, which then moves to the code quality area. So I suspect a lot of the test times could be improved by creating smaller objects because right now, a lot of the tests will load the entire world because they have to. They have to test everything. And so that is creating a ton of data, and then taking a long time to run versus if we were able to split out that code into smaller objects and test in unit tests, then that would also help speed up. But that's also hard to do. +Where do you look first? We do have some great data, thanks to RSpec. RSpec is letting us know how long each test file takes to run, and then we are capturing that data. So I can go look at which files and say, oh, this file takes 10 minutes to run. Let's look at that file first versus some of the other ones that are performing better. But that is a battle that will take a long time to win. And it's something that takes consistency and then also encouraging others to join that battle. So while it's very important, it doesn't address the concern of tests growing rapidly and then being able to support that. +Something that you said in a previous episode also was on my mind in talking about building processes in a way that encouraged people that they can make small, quick changes. And I think that's really important. So if we can build out the architecture to help scale this so then the tests were running in say 15 minutes, then if someone saw a test and they wanted to make a small refactor, they saw a factory.create, and they're like, oh, that could be a FactoryBot.build_stubbed instead and issue that into a pull request or change request and get that merged. +I don't know if people feel as comfortable doing that right now because it takes them 30 minutes or longer to run the test. But that idea of how do we get a structure in place where people can make tiny, little improvements and do that as a whole, as a team, to then work on the code quality concerns? +CHRIS: That last little bit is so interesting where you're saying, like, oh, we have a FactoryBot.create, FactoryBot.Build, but it has the overhead of having to go through the 30-minute test suite. But coming back to the thing we were talking about before, what if we didn't have to run all the tests? Although I find it very hard to tell, given a code change in actual production code, what tests do I need to run? When I'm just changing a test, I'm pretty sure I know which test I need to run in order to determine if that test still runs correctly. +So that feels is there an optimization that can happen there? Which is I've only made test changes; therefore only run the changed tests. And then that's an encouragement to say, like; this is a part of our codebase that we are trying to improve on. Let's optimize the iteration speed there. You'd have to figure out how to write that. And so it's probably much like my productivity adventures, maybe not a good investment. +Although given that this is such an organizational concern, maybe that is the thing that's worth spending an afternoon on and seeing if it could happen. Because if you can speed that process up, get more [inaudible 23:46] and more iteration in fixing the tests, that feels like it could be a win. +STEPH: I think that's a really good idea. I think we could certainly tell that if a file's changed, that it's only a test file that has changed. And then I've heard very good things from the other developers that TeamCity has a wonderful API to work with. And so there's a way that we could then tell TeamCity to say, hey,...or it may not even be a TeamCity command. It may just be somewhere in the universe we have to say, "Hey, RSpec, only run this test," or "TeamCity, we're only going to feed you this one RSpec test to run, so user agent but only run this particular test." +So I really like that idea. I think that's really intriguing. And I'll bring it up with the team because that would be a huge win, especially as Joël and I are really focused more on tests. That would just improve our lives. So selfishly, I'm excited about that idea because we are touching less of the application code and more focused on improving the test at this point. +CHRIS: I mean, if right now you're getting, say, 5 or 10 pull requests through a day which frankly feels like a high bar on this, if suddenly that's 10 to 20, that's material right there. +STEPH: Yeah, I don't know how large of an impact it would have for the rest of the team because I don't know how often they're only making changes to a test file, but it still feels like a nice optimization to have. Cool. Well, thanks. I appreciate that idea. +CHRIS: My pleasure. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: What else is going on in my world? I continue to not code a ton which is interesting and probably makes sense for right now. But to share a small anecdote from this week, we had retro, and I ended up attending retro ever so slightly late. I was doing a hiring interview, which is super exciting. Again, for anyone that's out there, we are hiring at Sagewell Financial. And I would love to chat with you if that sounds interesting. But so I was having a wonderful hiring conversation that ran a little bit long. +So I was a little bit late to retro, and I arrived, say like eight minutes in, and someone was expressing a concern. And the concern was, I very sincerely know this to be true, but they were saying in the most positive way. But they were like, "It'd be great if Chris could code more," and not in the judgmental like, Chris, why are you not getting as much done? Not in that way at all, very much in the it would be great if Chris had more time, if there wasn't as much pulling my attention in different directions. +But then it kind of went into this interesting direction. So we then go back through and address the concerns and talk as a group about how we resolve them. But this one was like, my name was in the concern, again, in a very positive way, in a very supportive way. And we had a wonderful conversation, and there were really great ideas that were passed around. But man, did I feel weird having my name in a retro item. [laughs] +STEPH: So one thing I've learned is that you do a really good job when you are giving presentations and being in the spotlight. But I don't think you actually love it. You love sharing content and things that you have learned. But I could see how being a focal point, especially if there's a concern or something that could have a negative connotation, that would feel squeamish. It would make me feel squeamish. +CHRIS: I hadn't thought about it in that way. But as you say it, also, this conversation is a meta version of that. Like, let's talk about me talking about me. I don't want to be the center of attention. But I love technology or process. I love talking about the work. That's great. And so I'm happy to do that. I'm happy to stand in front of a room and talk about it. But yeah, when it's about me, that's weird. And so now I'm going to move...well, no, I'm not going to move on [laughs] because this is the topic right now. +But so there's a bunch of things that we have been trying to introduce. And I think this is a useful part of the conversation more broadly and less about me. So one of the things that I think I mentioned in a previous episode was the introduction of point-dev, which is each week, we rotate through a person. And that person is in charge of triaging the errors, making sure that nothing is stuck in Sidekiq, responding to any support requests, et cetera, et cetera. But they're meant to be the frontline such that everyone else can be heads down and really focus on the work. +And what was interesting of the three developers that are working on the project, I am point-dev this week. So I was like, yes, that's awesome this week because I'm the person on the frontline. That has not helped me, but in the future, it will. And then one of the other developers mentioned that they feel like it's really useful but also feel like it's been noisy. And we realized the previous week was their week on point-dev. But the other developer was like, "Yeah, it's been great. I haven't had to think about anything." And so they have been off of that rotation for two weeks now. They'll be taking it over next week. +But it is doing exactly its job of providing that attention coverage so that they can keep their focus on the code, and that's really wonderful. So I'll be honest, when we started talking about it, there was a tiny voice in my head that was like, is this a failure mode? Should we be dealing with the noise rather than having a process to address it in the moment? Should we be dealing with the root cause rather than the symptoms? And I still think that's a good point of view. But we found so much value from this. +And as I've mentioned it, many people are like, oh yeah, we have that. It's great. I've heard enough positive things. So I've backed away from that. But there was a voice in my head that was like, are we failing right now? But yeah, so point-dev has been really wonderful. And next week, I will have to...well, frankly, the next two weeks, I'm off of point-dev appointments, so I'm very excited about that. +I've been doing some of the product management or sort of the tech side of the product management and helping to triage cards and make sure that there's very clear work lined up for the engineering team when they're ready to do that. I'm trying to back away from that just a little bit. +And one of the things that we did there was introduced an inbox column in our Trello board. You know how I love a good inbox. You know how I love to get to inbox zero. But that is a good way for me, for anyone now in the organization, which I don't want everyone to have to learn our processes, but just saying, "This is the place that you put requests, and we will deal with them. I assure you of that." +It has been great because that means I don't need to be quite as responsive in Slack. I can just gently redirect people, "Hey, if you don't mind, please put this in Slack in the inbox column, and that'll be great." That thing, though, that gentle pushback in Slack is one of the things that I've struggled with. +And this was one of the more personal aspects of the conversation that happened in retro was me being, like, if we're being honest, I tried to do that. But it's not my favorite thing to do in the world. Whenever someone asks me something, I want to be helpful. I don't want to seem rude or brisk or like I'm too busy for you, et cetera, et cetera. +So I will often respond to the question or do the thing that they're asking and then say, "In the future, if you could go to this other place." And ideally, I'm slowly moving forward and being like, "No, no, no, please go to the other place. We've talked about this a few times." But it is an interesting example of one of the specific aspects of my personality coming through in this. But that introduction of an inbox has been great. Love me a good inbox, as I said. +And then, more generally, we just tried to talk through what are the things that I'm doing? Do I need to own all of those uniquely? And some of them the answer we decided was yes but some of them we decided no. And we started to sort of distribute the work there or some of the meetings or different aspects of it. And so overall, it was a really great conversation but also very weird for me. +STEPH: Yeah, because then you wonder, am I not doing the right thing? Am I not spending my time the right way? But then hopefully, that meeting helped reinforce that yes, you are spending your time the right way and that you're doing a lot of productive things. There are just too many productive things for you to do, and so you have to prioritize those aggressively. I like all the things that you just highlighted. +There's one in particular, the last one that you mentioned about finding things that you can hand off to others. And I love that for a couple of reasons. It came up in a recent conversation that I was having with some other thoughtbot developers around when someone's on a project, typically someone just falls into being the point person. They just happen to be the person that the client talks to and ask questions and goes through the most. And that's something that is okay. But we want to make sure that that's not a bad thing, that everybody is treated equally, that everybody is given equal opportunities and room to grow. +And so, in my mind, whenever someone is that point person, or you have fallen into that role, it is your job to then pull other people up. So if you have been given the responsibility of running a particular meeting each week, then go ahead and do it once or twice, so you can demo it and show it to someone else as to how you do this. But then tag somebody else and say, "Hey, I'm going to let you or ask you to run this next time." So then that person can experience it. They can demo their style, and then it continues on to have more people. +So I really like that you are highlighting it's not just beneficial for you to then distribute those tasks, but it's empowering for everybody else on the team as well. I'm curious, so what was the final outcome? It sounds like there are some really good things in place, and you're transitioning, handing some things off. But I can't imagine that things have gotten...all of your priorities are still there. So do you think you'll actually code more, or what's the outcome for next week? +CHRIS: Short term, maybe probably not, if we're being honest, but trending in that direction. So one of the things that's going on right now is hiring. That is just an activity that takes a lot of time. And I care a lot about doing that well, both for the organization and then for individuals on the other side. +I want to be respectful of their time and communicate in reasonable timelines and not leave people without an answer or follow up or those sorts of things. It probably makes sense for that to sit with me as the starting contact. And then from there, folks that are continuing on in our hiring process they're going to talk to many other members of the team, and that won't just be me. +But there are a lot of first conversations that I'm having. And so right now, my schedule has a bunch of that, which is fine and good. And that will hopefully, at some point, we'll hire some great people. And then we'll be on the other side of that. And that piece of the work that I have right now goes away. +Some of the other outcomes that we named there were a couple of action items. And so I think those will help, but they're sort of we got to work towards that. One is transitioning a meeting, but it's a biweekly meeting. And I'm not going to just not attend the next one. So it'll be me and one of the other developers attending to transition ownership of that meeting moving forward. And then from there, so like, two weeks from now, I will not have that consideration on my calendar. And that's like one 30-minute block that I get back or, depending on how you think about it, one block that that 30-minute broke up. +I do want to touch back just on something that you're saying there. I think you're being very kind to me in saying like, no, but you've got so many things, and so it's hard to do that. I think that's true, but that's kind of the work overall, and my version of that is one thing. But everyone sort of has, as a team, we have a version of like, how are we being most productive? Are we making sure we're doing the most important things? And so it was interesting in the moment, but I think it was a very good conversation. +And I want to make sure that both we as a team and then me as an individual, wherever that happens to be the case, are open to these sort of constructive things. Like, frankly, to do the work to figure out how to get work off my plate that hasn't felt like the most important thing. It felt like close to the most important thing, but then there were all the other things that I had to do. So I wasn't doing the work to figure out how to not do the work. It is a complicated sentence that I just said. +But this was a case where retro, I think, very usefully highlighted that this was a good thing for us collectively to put effort into such that we can be more productive moving forward. It happened to be slightly more focused on me rather than the entirety of the team. But broadly, that kind of thinking is why I'm a huge fan of retro. I think it's a great place to take a step back think about how we're doing the work rather than just being in the work day-to-day. +STEPH: So if I'm internalizing what you said correctly, let me know if not, but it sounds like you're in one of those places, and I've witnessed this with other people and myself where someone is overwhelmed. They have a lot to do, and they're very focused in that grind and in that moment of doing all the things that they have to do. And it's very hard to then say, "I'm in the weeds right now. And then I also have to figure out how to get out of the weeds." And that's a very different skill and mental space to be able to do that. +Because often, when you're just in that mode, all you can focus on is a bit on survival at that time. And then it may take other people to notice to say, "Hey, you're in the weeds. We need to figure out a way to help you not live there and to find ways to distribute some of the work." +Does that sound like a fair assessment? Because I think I say all that because I've just seen people in that position. And then they think back, like, oh, I should have offloaded stuff earlier. And it's like, yeah, true, totally. And it often takes a retro or someone else coming to you and saying, "Hey, I've noticed...I looked at your calendar today; how can I help?" [laughs] +CHRIS: I think that's probably the right calibration. And mostly, my emphasis was just I want to make sure that broadly, any team that I'm on has the space for this sort of conversation. And that thing that you're saying exactly that phrasing of like, "Hey, I saw your calendar. How are you doing? How's that going, though? Are you feeling okay? [laughs] You can't sleep and whatnot." That can be a really useful thing to have and to have organizational norms about what are our expectations of how many meetings someone should have in a week. And where do we start to think about different things? +You did use the phrase overwhelmed. I want to say that I'm like 101% whelmed. So I'm just ever so slightly overwhelmed, but it is like I'm in the weeds. I need to figure out how to clear some of the weeds so that then I can get out of it. And it was a great conversation that came from that. +STEPH: That's awesome. I'm glad you got a good team that, frankly, felt comfortable bringing it up, and then that you could lean on them for ways to talk about how you could code some more and talk about priorities and where you want to focus your time. +CHRIS: It will be an interesting thing. As the team grows, I don't expect this to get easier. We talked about this a number of weeks back. And I think for a while; hopefully, we clear a little bit of dust here, and then I get back to being a little bit more on the code, and that's going to happen for a while. But as I think about the longer sort of the future of the company, this is something I'm going to have to revisit a handful of times. +And it's a really interesting question that I'm still struggling with internally. And where do I want to be versus what will be needed and whatnot? So it'll be interesting to see how it evolves. But for now, I think I can gain back a little bit of coding time, a little bit of maker time versus manager time, as Paul Graham's essay goes. And yeah, I think that'll be good. +STEPH: Yeah, I like how you're already looking forward to the fact that it will probably fluctuate because, yeah, right now, you are sort of paying a tax. You are building up to then where you can have more people on the team. And then that may give you back some of your time where then you can code because you can outsource some of the work to them. But then, as the team grows, so are other responsibilities. And traditionally, being in a CTO role and most CTOs I know will code here and there because they want to, and they enjoy it, but it is not their full-time job. +So I think you're really wise to have already noticed that and start thinking about how that's going to trend in the future. And it sounds like you might need to figure out how to throw some architecture at it. So then you can scale horizontally, and then you can just have more time to do all the things. Yeah, that's right. [laughs] +CHRIS: You're suggesting microservices, right? That's how my job becomes easy? +STEPH: Yeah. Well, I'm thinking more like RSpec Queue, but we'll have RSpec Chris or some version of that. +CHRIS: Chris Queue. +STEPH: Chris Queue. [laughs] +CHRIS: And then I just paralyze my human, and then it'll be great. +STEPH: Yeah, that's always worked out well in the movies. Whenever somebody clones themselves, that goes super well. +CHRIS: Multiplicity is a fantastic piece of cinema, and I stand by that. +STEPH: I haven't seen it, but I feel like it doesn't end well for the main character. +CHRIS: I feel like every time I mention a movie, you haven't seen it. I feel like we need to do a movie marathon at some point just to catch up so that we've got shared analogies. But yeah, it's a fun movie. It's fine. It turns out fine in the end. But there are some humorous adventures that happen in the middle. Cloning maybe [laughs] isn't the most direct option to solve productivity problems. +STEPH: [laughs] Yeah, I think I've got Labyrinth, Hackers, and Multiplicity now on the watch list. And I appreciate the fact that you know that I'm not likely to watch them, although out of the three, Hackers will probably happen. +CHRIS: All right, what if I were to get a bunch of Pop-Tarts, non-frosted? +STEPH: Ooh. +CHRIS: Does that change -- +STEPH: Wait, are you going to send them to me? Because if you just have them, that's no good. [laughter] +CHRIS: Eat Pop-Tarts on a video call and be like, "Look at this movie. It's great." [laughter] +STEPH: All right, bribery definitely works for me. [laughs] +CHRIS: Okay, so got it, noted. And based on the nature of the conversation that we have devolved into here, I think we've probably reached a good point. What do you think? Should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeeee!!!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris updates us on his new window manager of choice, Moom, and tells us what's good with it. He's also giving yet another task manager a go: OmniFocus. (Sorry Things.) Steph talks about defining test classes in RSpec and readdresses flaky tests to improve CI build time.

+ +

Chris is worried about productivity. He's still not coding as much as he'd like to be. Steph lends an ear, and together, they discuss potential ways Chris could gain back a little bit of coding time at work.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Well, hey, Steph. Oh, I have an update on a thing that I think I talked about a while back or at least asked on Twitter. But I've been looking for a window manager for forever. And in that way that I sort of overcorrected a while back, I think where I'm no longer allowed to do anything related to productivity or dev tools. I was just forbidden because it was a time sink. I'm slowly trying to correct back and be like, you know what? I regularly think about how it would be nice to have a better window manager.

+ +

So previously, I had used Divvy, D-I-V-V-Y, which is fine. It did an okay job, but it just didn't have quite the level of control that I wanted, or maybe I didn't investigate it enough. But it felt like it was lacking. So I did a little bit of research. A bunch of people recommended different things. There was Spectacle; there was Rectangle. There was a whole bunch of other things that I'm forgetting now because I have settled on Moom, M-O-O-M. Those are fun words.

+ +

STEPH: I feel like you keep bringing interesting words [laughs] because last time, it was Things where you're tracking all the things. And now we have Moom to track the space. All right.

+ +

CHRIS: If this is my legacy as a podcaster, then I feel like I will have done well just, you know, weird sounds mostly that's what he's going for. But yes, I've been using Moom now for…[laughs] God, it's just ridiculous to say, but here we are.

+ +

STEPH: [laughs]

+ +

CHRIS: I've been using it. I've been enjoying it. In particular, the thing that I liked about it...a bunch of the other ones that I looked at were like, oh, we've got all these different configurations. And you can move things any which way, and you can have any number of hotkeys. And I was like, wait, wait, wait, say more right now. You want to take over my global namespace of hotkeys and just clutter it with 19 different things? You know that that is a limited space that I'm working with here.

+ +

And so Moom, somewhat uniquely, at least in the ones that I experienced, was what I would describe as a modal window manager. So much like Vim is modal where you start out in normal mode, and you're moving around and you kind of bounce and search and all of that, and then you enter insert mode. And in insert mode, keys do different things. And then in command mode...it's got all these different modes. And so there are lots of different namespaces for hotkeys. It's one of the things that makes Vim so powerful.

+ +

Moom is similar in that there's one global activation hotkey. And then, within that, I can have a whole namespace of hotkeys. So like M will put something in the middle of my screen now. F will put something full-screen. And I don't need to remember weird multikey combinations for that. There's just the one to get started, and then I've configured it such that the tab will bounce to a secondary display and sort of rotate through them.

+ +

M and F and Q and P I've got it physically laid out on the keyboard. So it looks like my screen. Q being on the left side will push something to the left side, P to the right side. And I'm very happy with that. I don't need a lot out of this tool. I don't need very complex management or scripting or any of that, which are very nice features that exist in the other ones. But that combination, the one hotkey to rule them all, and then the sub hotkeys within it, and the ability to mostly move between the screens and then put stuff where I want it is great. I'm very happy.

+ +

STEPH: I think I've figured it out. So Moom, I think it's a combination of move and zoom, and that's how they got Moom.

+ +

CHRIS: You're probably right.

+ +

STEPH: That does sound really nice. I'm a Spectacle fan. And I have enjoyed it and just stuck with it because I haven't felt a need to change from it. And it's really nice where I use my arrow keys for which direction I want to go. So that has been easy for me to recall. But that sounds really nice, all the things that you're describing with Moom.

+ +

CHRIS: Does spectacle have the like, is it some Command Option Control and then left or right or up or down? Or is it you type something, and then you type left, right, up, down?

+ +

STEPH: I have to actually touch my keyboard to answer that question because I have the muscle memory, which is an interesting thing that my muscles knows it, but my brain has to really think about it. So I think it's like the Option Command, and then yeah, then use the arrow keys.

+ +

CHRIS: Gotcha. That's roughly what I had when I was using Divvy previously, but I found just enough of a limitation there. And so Moom has been great as another tool. But I think Spectacle has a lot more features in terms of scripting and other fancier stuff that you can do, which is both super intriguing and, again, sort of the thing that I'm not allowed to do. [laughs] So I went with, like, this tool seems fine and has the one feature that I really want.

+ +

That said, you brought up Things, which is the to-do list app that I've been looking at. I've been using it for a week now. It's great. I'm enjoying having a more structured way to say, like, here's what I'm doing today. Here's what I'm doing tomorrow. It's been wonderful. But I'm already looking at OmniFocus as a better version.

+ +

STEPH: [laughs]

+ +

CHRIS: Because I think there's some stuff that I don't love, and yes, I can hear my own voice in the back of my head that's like, always chasing that next thing. But I haven't actually made the effort to switch over or even tried. I've used OmniFocus in the past. But anyway, I'll let you know if I do make additional moves there.

+ +

STEPH: Yeah, I'm enjoying this journey. Keep me up to date on it. I've heard of OmniFocus, but I know nothing about it. But I feel like I've heard good things. So I like this journey you're going on where you just keep switching and trying new things. That's fun for me [laughs], and there's chasing productivity. So I'm into it; I'm here for it.

+ +

CHRIS: If I just invest enough hours to save a handful of minutes down the road, then I will have...oh no, wait, that's not how this goes. There's, of course, an xkcd about this which we can include in the show notes. But I'm trying to be very intentional with it. I waited for many years before I allowed myself to reinvestigate the world of to-do lists. And I'm hopefully going to keep it to just a couple of weeks of nonsense and then back to a few years of stable. That's the dream.

+ +

But yeah, that's some of the smaller things that are up in my world. I have another topic that I want to chat about. But I'd love to hear what's new in your world?

+ +

STEPH: Yeah, I have some interesting bits that I can talk about with the project that I'm working on. But more concretely, I have something that's been on my mind that I don't think that I've talked about here on the show, but I think would be fun to talk about because I just happened to run into it this week while working on some code.

+ +

And it's the idea of defining test classes in RSpec so as you are testing part of your code, but then you want to create just like a fake class, something that you can use as a substitute for real application code. And so it's a really nice way that then you can have this replica behavior, but then maybe it's just one particular method or some behavior that you need to use in the class but then doesn't actually go to the real code. That's wonderful. That's great.

+ +

One thing that I've learned is that with RSpec is when you are introducing a test class, so let's say if you have your RSpec describe and then either a string or it's the name of a class, and then you have a block so do, and then within that block is where you write your test. If you create a temporary class, say, like I have my class test class, and then I have some behavior, that gets defined in the global namespace. It's not scoped to that particular RSpec example. And the reason for that it's not specific to RSpec. RSpec is not the one that's doing this; it's actually Ruby behavior.

+ +

So for Ruby, when you're defining within a block like that, if you're defining a constant, if you're defining another class inside of a block, it's going to use the outer namespace as its namespace. So if you had a top-level class that you were defining, but if you define a class as a block, and then inside of that block you define a constant, that constant is then defined in the object namespace instead of within that particular class that you have written. And so that's why RSpec has this behavior.

+ +

Because someone brought up a really great question about this on RSpec::Core asking about it, and they're like, yeah, that's actually how Ruby works. And so we're not going to change RSpec's behavior since that is how Ruby has decided to handle this. And the part where this becomes important is when you define a test class within an RSpec example.

+ +

While it may be unlikely that someone is going to use that exact same name for their test class that they're going to create in their RSpec example, if they were to use that same name, then you're going to have a collision between the two. One of them's going to win, and you're probably going to end up with some really weird test failures because it's going to get confusing as to which class is being used, and they may not match up with each other.

+ +

So one way around this, and this is going to be one of the rare times that I suggest this, but let. Let is scoped to an RSpec example. And so you could define a class inside of a let, and then that will scope it to the example. There are probably some other approaches as well, but that's the one that I'm most familiar with to ensure that when you define that class or constant, it's not getting defined in the global namespace and ensuring that none of the other tests have access to it.

+ +

CHRIS: Well, this is certainly interesting. I'm pretty sure I've been operating under the opposite assumption for the entirety of my career. This is good to know. I feel like I probably have had tests that failed because of this. And then I learned this truth, and then I subsequently forgot it. I don't know if you know this, but if you define a method within just a helper method that you extract in RSpec, are those also on the global namespace?

+ +

I don't define classes in RSpec blocks that often. It's pretty rare. Like if I have a controller concern sort of thing that I want to test, I might say random controller and inject the thing there or some other abstracted piece. That is the only case I can think of where I have a fake model or a fake controller or something like that for test purposes. But it doesn't come up that often. I do extract a heck ton of local helper methods. And I'm wondering now, are those all in the shared global namespace?

+ +

STEPH: I'm pretty sure they're not. And I'm getting on the edges of my knowledge here, but I think it has to do with the fact of when you're defining a constant. So if you're defining a class versus an actual constant, that will get into the global namespace because it's using the outer scoping. But in my experience, I'm pretty sure that's not true for the method just because I remember one time I did some funky stuff with RSpec. And I remember seeing that I couldn't access those methods from another example.

+ +

CHRIS: I like the honesty. And you're like, to be clear, I was doing something weird, but I learned that day. Okay, that's good because at least that part maps to my understanding. So methods may be safe, but classes get shared. Very interesting.

+ +

STEPH: And it's something that I rarely think about or had worried about just because if I'm defining a fake test class, I often will put it somewhere that's intended to be more global. So I'll stuff it somewhere in like spec support. So then other people can see, hey, I've already mimicked this behavior. So if you need to use the same thing, just go ahead and use this. It's not often that I am adding that class directly to the RSpec example group.

+ +

So I think I've been fortunate where I haven't actually run into that conflict for that reason. But this came up while giving an RSpec course. And while we were just in a very small, tiny codebase and replicating some examples, someone in the class was like, "Hey, by the way, do you know that that's in the global namespace?" And I was like, "No, friend. Tell me more." So thanks to that person, they're the ones that actually enlightened me about how it's going into that namespace and how it can actually pollute your testing namespace.

+ +

There's a really good article that's written by Ken Mayer. And we'll be sure to include a link in the show notes that talks about it and also provides the let example as a way to work around this. And also links to the GitHub discussion on RSpec::Core, where they talk about this behavior and why things are the way that they are.

+ +

Circling back to some of the more general project-y things that I alluded to earlier, I've shared a bit about the project that I'm working on. But just to recap it, it is focused on helping a very large team that has a large number of tests, around 85,000. And they are looking to address flaky tests that they have and overall really improve their CI build time. So right now, it takes about 30 minutes for the build to take place. But they also have flaky tests, and then that slows things down. And so, the re-verify rate has been painful for them.

+ +

There's been some really great work that has improved that, particularly there is a, I think we've talked about this before, but where they're re-verifying certain flaky tests, which isn't great because they're still flaky tests, but at least they're not preventing people from moving forward and shipping code.

+ +

But some of the bigger stuff that is just on my mind is when you have a very large team and a very large application, by large team, I'm talking about 100 developers, and they are all contributing to this codebase. And there are around 85,000 tests, and that has grown substantially in the last 12 months. And so, if you think about the trajectory of the addition of those tests, it is just going to continue to grow. So there's a concern there of even if we address flaky tests and we improve things, there's an architecture concern of how do we really reduce the CI build time?

+ +

And so there's that aspect, and then there's also the aspect of then well, how do we still work to improve the tests and the codebase as well as we go across all of these disparate teams? And right now, there is a bit of a culture where engineers don't feel empowered where they can necessarily address all of the flaky tests or things that they run into. And so there is a bit of a mindset of I'm stuck on this, or this test failed, or it's flaky, or I don't understand it. So I'm just going mute it, or I'm going to hand it off to someone else to work on it.

+ +

So there are three big areas that are on my mind. The first one is architecture. You can throw architecture at it. There's also the code quality that's a concern. And then how do you improve the code quality in a way that you're improving it fast enough that then you've got 100 other developers that are also contributing to it at the same time? And then individual IC empowerment where then people feel like, hey, I ran into a slow test or a flaky test, and I feel like I can triage this, and I can make changes.

+ +

For the architecture piece, we're still in the infancy stages of how to approach this and the strategy that we're using. But one of the ideas that has come up is how do we reduce tentpoles? And the tentpole is like when you're running your test and, let's say that it's parallelized, all of the various tests. But there is one process that takes like 20 minutes, and then the other process is completed in 5 minutes as a drastic example.

+ +

And overall, you could have reduced your time if you had managed to split that 120-minute process across all the other workers who are then available for that work. So there are some tentpoles that are taking place. And that could be one first step in reducing the CI build time.

+ +

There are also discussions around how to scale horizontally. Right now, we don't think that's something we can do with the service that we're using to run the test. But it's something that maybe we need to manually look into is then how do we build a queue of all these tests and not where we just split test by a file, which is typically how the Parallelize gem does it.

+ +

But you could actually split up tests within a file. So if you had a particularly large file, that doesn't necessarily matter. But then building a queue of all these tests so then as each test finishes, a worker can just grab that next test. And then also you can easily scale up and scale down workers. As I'm saying that, that feels big, that's a lot to invest in. But that as an idea is how can we essentially then scale the architecture? So even as we continue to invest in the tests, in the system, and they continue to grow, our architecture can keep up with it.

+ +

CHRIS: That last bit there is super interesting to me. It's something that I've looked into and haven't pursued yet. We're currently running on CircleCI with our test suite. And I don't even know that we pushed on parallelization because we're early enough on that. And we turned off bcrypt recently, which super-duper helps with the speed up. But overall, the test suite time is fine, is where I would put it.

+ +

It had crept up, though, to a place where it was starting to be painful, is how I would describe it. And I think it's very easy for that to just continue growing and suddenly, it's 20 and 25 minutes. And then, depending on your merge strategy and all of that, it can be all the more complicated, and this gets in the way of deploys. And so, I think it is a super important thing to keep an eye on. I know Charity Majors pushes really hard for 15 minutes from merge to deploy to production. And so if your CI suite takes 25 minutes, then already you're stuck.

+ +

As an aside, I just once more want to say out into the ether, CircleCI or any other CI platform, if you would allow me to say yes, we've already tested this Git hash, this Git SHA, or the working tree, ideally, because that's also deterministic, I would love that feature. I would love to not have to rebuild the same code when it gets merged into main, just saying once more out into the world. Also, GitHub, if you want to put me on the merge queue beta, I would love that if anybody out there is listening. [laughs]

+ +

STEPH: I like how this has become a special requests hotline for all the things [laughs] that you're hoping to get a part of or features you'd like to see added.

+ +

CHRIS: Hello, internet. I have some requests.

+ +

STEPH: [laughs]

+ +

CHRIS: I would love to see those things, but in the world where those don't exist. The particular thing that you're talking sort of a test queue, is something that I've seen. So Knapsack is a...what's the word? It's a tool; it's a service. It's a combination of things. But it does that essentially where it starts up a local build agent. And then it basically says like, all right, give me all of the tests that you need to run, and then I will feed them back to each of the individual agents that there's one agent running per parallelized process.

+ +

And so say you've got five of them. The first one says, "Hey, give me a test," and runs it. And the second one says, "Give me a test," and et cetera. And so, the queue manager on the other side is in charge of that orchestration. And it means that they basically all finish in identical time, with one being an outlier, whichever one happens to be the longest.

+ +

But it's only going to be however long your longest test is is basically that outlier versus what you're describing of like, well, if we split it by file, we can end up with more naive things where there's a bunch of feature specs on one of them, and it skews by two minutes. We obviously don't want that. So Knapsack, in particular, is a tool that I've looked at, but generally, I'm very interested in that as a solution to how do we maximally take advantage of parallelization there?

+ +

STEPH: Interesting. I have not heard of Knapsack. There is one that sounds similar. It's called RSpec Queue. And it does some really interesting work where it will split the individual test, so it won't do it by file. It will also look at historical data to then try to be intelligent about how it's going to split it and find the longer running test. And I believe it uses Redis to then keep track of the test set up in run and things that still need to be run. That is a gem that the team is looking into using as well.

+ +

I don't know how that works if that can integrate with the current platform as we're using TeamCity to run tests. I don't know if that's something that can integrate with TeamCity, if it's a replacement. I don't have all of the knowledge about RSpec Queue yet. But it seems to do a number of the things that we're interested in. So even if we can't use the gem, then maybe it's something that we can still imitate.

+ +

CHRIS: The other thing that I'm surprised we haven't said yet is this is one of the places where people would often reach for microservices. I feel like we have to have the microservice conversation at this moment. Microservices can actually be a great solution to organizational problems. As a team scales, it does become really hard to manage a large group of developers. And so microservices introduces a very fixed boundary that then draws nice lines that you can have around things. And so, the individual build time for a portion of your application can be much more manageable by virtue of that.

+ +

But it has this huge cost of technical complexity and overhead and et cetera, et cetera, all of the reasons that we may not want to go that route. And so interestingly, I was just looking at Shopify's Deconstructing the Monolith blog post, which I think at this point, they've skewed a little bit more into the microservices. Shopify is huge, one of the largest Rails apps out there. And so looking at them and being like, oh, what are they doing? It's an interesting sort of plot a course and to see how long they waited before they even started thinking about the much deeper things and even exploring microservices.

+ +

But in this blog post, they talk about a different approach where they stuck with sort of a monolith. But then they started to introduce Rails engines and clear encapsulation within the large codebase such that then you can actually start to say, well, we don't need to run all the tests every time because if we're making a change within this section of the application, then we just need to run those tests.

+ +

I've also heard of organizations having some logic that can determine based on the code change; we know the associated test files that we should run. I'm scared of that is how I would describe it. I want to trust my test suite. I want to be able to deploy on a Friday and say if tests are green, it's going out to production. That's great. And I worry about that sort of thing. That's hard to get right. That feels like caching, right? And that's one of those things that we historically get wrong a lot.

+ +

But nonetheless, that is an approach that large organizations I've heard having good success with. So some way to determine what's the affected code and what tests do we need to rerun and et cetera. And that can really drastically reduce down the scope of each CI build. But those are some larger things that I have not had to reach for on any of the applications I've worked with. I've taken different approaches, different ways to reduce the time or otherwise Parallelizer et cetera. But it's interesting for when you get to a certain scale.

+ +

STEPH: Yeah, it's funny that you bring up that idea because that came up in conversation with some of the other developers as well, was the idea of, like, what if we could just not run all the tests? You changed one file, and you don't need to run everything. And I immediately was like, that sounds very cool and super hard to be able to get right.

+ +

And a lot of this code is extremely coupled, which then moves to the code quality area. So I suspect a lot of the test times could be improved by creating smaller objects because right now, a lot of the tests will load the entire world because they have to. They have to test everything. And so that is creating a ton of data, and then taking a long time to run versus if we were able to split out that code into smaller objects and test in unit tests, then that would also help speed up. But that's also hard to do.

+ +

Where do you look first? We do have some great data, thanks to RSpec. RSpec is letting us know how long each test file takes to run, and then we are capturing that data. So I can go look at which files and say, oh, this file takes 10 minutes to run. Let's look at that file first versus some of the other ones that are performing better. But that is a battle that will take a long time to win. And it's something that takes consistency and then also encouraging others to join that battle. So while it's very important, it doesn't address the concern of tests growing rapidly and then being able to support that.

+ +

Something that you said in a previous episode also was on my mind in talking about building processes in a way that encouraged people that they can make small, quick changes. And I think that's really important. So if we can build out the architecture to help scale this so then the tests were running in say 15 minutes, then if someone saw a test and they wanted to make a small refactor, they saw a factory.create, and they're like, oh, that could be a FactoryBot.build_stubbed instead and issue that into a pull request or change request and get that merged.

+ +

I don't know if people feel as comfortable doing that right now because it takes them 30 minutes or longer to run the test. But that idea of how do we get a structure in place where people can make tiny, little improvements and do that as a whole, as a team, to then work on the code quality concerns?

+ +

CHRIS: That last little bit is so interesting where you're saying, like, oh, we have a FactoryBot.create, FactoryBot.Build, but it has the overhead of having to go through the 30-minute test suite. But coming back to the thing we were talking about before, what if we didn't have to run all the tests? Although I find it very hard to tell, given a code change in actual production code, what tests do I need to run? When I'm just changing a test, I'm pretty sure I know which test I need to run in order to determine if that test still runs correctly.

+ +

So that feels is there an optimization that can happen there? Which is I've only made test changes; therefore only run the changed tests. And then that's an encouragement to say, like; this is a part of our codebase that we are trying to improve on. Let's optimize the iteration speed there. You'd have to figure out how to write that. And so it's probably much like my productivity adventures, maybe not a good investment.

+ +

Although given that this is such an organizational concern, maybe that is the thing that's worth spending an afternoon on and seeing if it could happen. Because if you can speed that process up, get more [inaudible 23:46] and more iteration in fixing the tests, that feels like it could be a win.

+ +

STEPH: I think that's a really good idea. I think we could certainly tell that if a file's changed, that it's only a test file that has changed. And then I've heard very good things from the other developers that TeamCity has a wonderful API to work with. And so there's a way that we could then tell TeamCity to say, hey,...or it may not even be a TeamCity command. It may just be somewhere in the universe we have to say, "Hey, RSpec, only run this test," or "TeamCity, we're only going to feed you this one RSpec test to run, so user agent but only run this particular test."

+ +

So I really like that idea. I think that's really intriguing. And I'll bring it up with the team because that would be a huge win, especially as Joël and I are really focused more on tests. That would just improve our lives. So selfishly, I'm excited about that idea because we are touching less of the application code and more focused on improving the test at this point.

+ +

CHRIS: I mean, if right now you're getting, say, 5 or 10 pull requests through a day which frankly feels like a high bar on this, if suddenly that's 10 to 20, that's material right there.

+ +

STEPH: Yeah, I don't know how large of an impact it would have for the rest of the team because I don't know how often they're only making changes to a test file, but it still feels like a nice optimization to have. Cool. Well, thanks. I appreciate that idea.

+ +

CHRIS: My pleasure.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: What else is going on in my world? I continue to not code a ton which is interesting and probably makes sense for right now. But to share a small anecdote from this week, we had retro, and I ended up attending retro ever so slightly late. I was doing a hiring interview, which is super exciting. Again, for anyone that's out there, we are hiring at Sagewell Financial. And I would love to chat with you if that sounds interesting. But so I was having a wonderful hiring conversation that ran a little bit long.

+ +

So I was a little bit late to retro, and I arrived, say like eight minutes in, and someone was expressing a concern. And the concern was, I very sincerely know this to be true, but they were saying in the most positive way. But they were like, "It'd be great if Chris could code more," and not in the judgmental like, Chris, why are you not getting as much done? Not in that way at all, very much in the it would be great if Chris had more time, if there wasn't as much pulling my attention in different directions.

+ +

But then it kind of went into this interesting direction. So we then go back through and address the concerns and talk as a group about how we resolve them. But this one was like, my name was in the concern, again, in a very positive way, in a very supportive way. And we had a wonderful conversation, and there were really great ideas that were passed around. But man, did I feel weird having my name in a retro item. [laughs]

+ +

STEPH: So one thing I've learned is that you do a really good job when you are giving presentations and being in the spotlight. But I don't think you actually love it. You love sharing content and things that you have learned. But I could see how being a focal point, especially if there's a concern or something that could have a negative connotation, that would feel squeamish. It would make me feel squeamish.

+ +

CHRIS: I hadn't thought about it in that way. But as you say it, also, this conversation is a meta version of that. Like, let's talk about me talking about me. I don't want to be the center of attention. But I love technology or process. I love talking about the work. That's great. And so I'm happy to do that. I'm happy to stand in front of a room and talk about it. But yeah, when it's about me, that's weird. And so now I'm going to move...well, no, I'm not going to move on [laughs] because this is the topic right now.

+ +

But so there's a bunch of things that we have been trying to introduce. And I think this is a useful part of the conversation more broadly and less about me. So one of the things that I think I mentioned in a previous episode was the introduction of point-dev, which is each week, we rotate through a person. And that person is in charge of triaging the errors, making sure that nothing is stuck in Sidekiq, responding to any support requests, et cetera, et cetera. But they're meant to be the frontline such that everyone else can be heads down and really focus on the work.

+ +

And what was interesting of the three developers that are working on the project, I am point-dev this week. So I was like, yes, that's awesome this week because I'm the person on the frontline. That has not helped me, but in the future, it will. And then one of the other developers mentioned that they feel like it's really useful but also feel like it's been noisy. And we realized the previous week was their week on point-dev. But the other developer was like, "Yeah, it's been great. I haven't had to think about anything." And so they have been off of that rotation for two weeks now. They'll be taking it over next week.

+ +

But it is doing exactly its job of providing that attention coverage so that they can keep their focus on the code, and that's really wonderful. So I'll be honest, when we started talking about it, there was a tiny voice in my head that was like, is this a failure mode? Should we be dealing with the noise rather than having a process to address it in the moment? Should we be dealing with the root cause rather than the symptoms? And I still think that's a good point of view. But we found so much value from this.

+ +

And as I've mentioned it, many people are like, oh yeah, we have that. It's great. I've heard enough positive things. So I've backed away from that. But there was a voice in my head that was like, are we failing right now? But yeah, so point-dev has been really wonderful. And next week, I will have to...well, frankly, the next two weeks, I'm off of point-dev appointments, so I'm very excited about that.

+ +

I've been doing some of the product management or sort of the tech side of the product management and helping to triage cards and make sure that there's very clear work lined up for the engineering team when they're ready to do that. I'm trying to back away from that just a little bit.

+ +

And one of the things that we did there was introduced an inbox column in our Trello board. You know how I love a good inbox. You know how I love to get to inbox zero. But that is a good way for me, for anyone now in the organization, which I don't want everyone to have to learn our processes, but just saying, "This is the place that you put requests, and we will deal with them. I assure you of that."

+ +

It has been great because that means I don't need to be quite as responsive in Slack. I can just gently redirect people, "Hey, if you don't mind, please put this in Slack in the inbox column, and that'll be great." That thing, though, that gentle pushback in Slack is one of the things that I've struggled with.

+ +

And this was one of the more personal aspects of the conversation that happened in retro was me being, like, if we're being honest, I tried to do that. But it's not my favorite thing to do in the world. Whenever someone asks me something, I want to be helpful. I don't want to seem rude or brisk or like I'm too busy for you, et cetera, et cetera.

+ +

So I will often respond to the question or do the thing that they're asking and then say, "In the future, if you could go to this other place." And ideally, I'm slowly moving forward and being like, "No, no, no, please go to the other place. We've talked about this a few times." But it is an interesting example of one of the specific aspects of my personality coming through in this. But that introduction of an inbox has been great. Love me a good inbox, as I said.

+ +

And then, more generally, we just tried to talk through what are the things that I'm doing? Do I need to own all of those uniquely? And some of them the answer we decided was yes but some of them we decided no. And we started to sort of distribute the work there or some of the meetings or different aspects of it. And so overall, it was a really great conversation but also very weird for me.

+ +

STEPH: Yeah, because then you wonder, am I not doing the right thing? Am I not spending my time the right way? But then hopefully, that meeting helped reinforce that yes, you are spending your time the right way and that you're doing a lot of productive things. There are just too many productive things for you to do, and so you have to prioritize those aggressively. I like all the things that you just highlighted.

+ +

There's one in particular, the last one that you mentioned about finding things that you can hand off to others. And I love that for a couple of reasons. It came up in a recent conversation that I was having with some other thoughtbot developers around when someone's on a project, typically someone just falls into being the point person. They just happen to be the person that the client talks to and ask questions and goes through the most. And that's something that is okay. But we want to make sure that that's not a bad thing, that everybody is treated equally, that everybody is given equal opportunities and room to grow.

+ +

And so, in my mind, whenever someone is that point person, or you have fallen into that role, it is your job to then pull other people up. So if you have been given the responsibility of running a particular meeting each week, then go ahead and do it once or twice, so you can demo it and show it to someone else as to how you do this. But then tag somebody else and say, "Hey, I'm going to let you or ask you to run this next time." So then that person can experience it. They can demo their style, and then it continues on to have more people.

+ +

So I really like that you are highlighting it's not just beneficial for you to then distribute those tasks, but it's empowering for everybody else on the team as well. I'm curious, so what was the final outcome? It sounds like there are some really good things in place, and you're transitioning, handing some things off. But I can't imagine that things have gotten...all of your priorities are still there. So do you think you'll actually code more, or what's the outcome for next week?

+ +

CHRIS: Short term, maybe probably not, if we're being honest, but trending in that direction. So one of the things that's going on right now is hiring. That is just an activity that takes a lot of time. And I care a lot about doing that well, both for the organization and then for individuals on the other side.

+ +

I want to be respectful of their time and communicate in reasonable timelines and not leave people without an answer or follow up or those sorts of things. It probably makes sense for that to sit with me as the starting contact. And then from there, folks that are continuing on in our hiring process they're going to talk to many other members of the team, and that won't just be me.

+ +

But there are a lot of first conversations that I'm having. And so right now, my schedule has a bunch of that, which is fine and good. And that will hopefully, at some point, we'll hire some great people. And then we'll be on the other side of that. And that piece of the work that I have right now goes away.

+ +

Some of the other outcomes that we named there were a couple of action items. And so I think those will help, but they're sort of we got to work towards that. One is transitioning a meeting, but it's a biweekly meeting. And I'm not going to just not attend the next one. So it'll be me and one of the other developers attending to transition ownership of that meeting moving forward. And then from there, so like, two weeks from now, I will not have that consideration on my calendar. And that's like one 30-minute block that I get back or, depending on how you think about it, one block that that 30-minute broke up.

+ +

I do want to touch back just on something that you're saying there. I think you're being very kind to me in saying like, no, but you've got so many things, and so it's hard to do that. I think that's true, but that's kind of the work overall, and my version of that is one thing. But everyone sort of has, as a team, we have a version of like, how are we being most productive? Are we making sure we're doing the most important things? And so it was interesting in the moment, but I think it was a very good conversation.

+ +

And I want to make sure that both we as a team and then me as an individual, wherever that happens to be the case, are open to these sort of constructive things. Like, frankly, to do the work to figure out how to get work off my plate that hasn't felt like the most important thing. It felt like close to the most important thing, but then there were all the other things that I had to do. So I wasn't doing the work to figure out how to not do the work. It is a complicated sentence that I just said.

+ +

But this was a case where retro, I think, very usefully highlighted that this was a good thing for us collectively to put effort into such that we can be more productive moving forward. It happened to be slightly more focused on me rather than the entirety of the team. But broadly, that kind of thinking is why I'm a huge fan of retro. I think it's a great place to take a step back think about how we're doing the work rather than just being in the work day-to-day.

+ +

STEPH: So if I'm internalizing what you said correctly, let me know if not, but it sounds like you're in one of those places, and I've witnessed this with other people and myself where someone is overwhelmed. They have a lot to do, and they're very focused in that grind and in that moment of doing all the things that they have to do. And it's very hard to then say, "I'm in the weeds right now. And then I also have to figure out how to get out of the weeds." And that's a very different skill and mental space to be able to do that.

+ +

Because often, when you're just in that mode, all you can focus on is a bit on survival at that time. And then it may take other people to notice to say, "Hey, you're in the weeds. We need to figure out a way to help you not live there and to find ways to distribute some of the work."

+ +

Does that sound like a fair assessment? Because I think I say all that because I've just seen people in that position. And then they think back, like, oh, I should have offloaded stuff earlier. And it's like, yeah, true, totally. And it often takes a retro or someone else coming to you and saying, "Hey, I've noticed...I looked at your calendar today; how can I help?" [laughs]

+ +

CHRIS: I think that's probably the right calibration. And mostly, my emphasis was just I want to make sure that broadly, any team that I'm on has the space for this sort of conversation. And that thing that you're saying exactly that phrasing of like, "Hey, I saw your calendar. How are you doing? How's that going, though? Are you feeling okay? [laughs] You can't sleep and whatnot." That can be a really useful thing to have and to have organizational norms about what are our expectations of how many meetings someone should have in a week. And where do we start to think about different things?

+ +

You did use the phrase overwhelmed. I want to say that I'm like 101% whelmed. So I'm just ever so slightly overwhelmed, but it is like I'm in the weeds. I need to figure out how to clear some of the weeds so that then I can get out of it. And it was a great conversation that came from that.

+ +

STEPH: That's awesome. I'm glad you got a good team that, frankly, felt comfortable bringing it up, and then that you could lean on them for ways to talk about how you could code some more and talk about priorities and where you want to focus your time.

+ +

CHRIS: It will be an interesting thing. As the team grows, I don't expect this to get easier. We talked about this a number of weeks back. And I think for a while; hopefully, we clear a little bit of dust here, and then I get back to being a little bit more on the code, and that's going to happen for a while. But as I think about the longer sort of the future of the company, this is something I'm going to have to revisit a handful of times.

+ +

And it's a really interesting question that I'm still struggling with internally. And where do I want to be versus what will be needed and whatnot? So it'll be interesting to see how it evolves. But for now, I think I can gain back a little bit of coding time, a little bit of maker time versus manager time, as Paul Graham's essay goes. And yeah, I think that'll be good.

+ +

STEPH: Yeah, I like how you're already looking forward to the fact that it will probably fluctuate because, yeah, right now, you are sort of paying a tax. You are building up to then where you can have more people on the team. And then that may give you back some of your time where then you can code because you can outsource some of the work to them. But then, as the team grows, so are other responsibilities. And traditionally, being in a CTO role and most CTOs I know will code here and there because they want to, and they enjoy it, but it is not their full-time job.

+ +

So I think you're really wise to have already noticed that and start thinking about how that's going to trend in the future. And it sounds like you might need to figure out how to throw some architecture at it. So then you can scale horizontally, and then you can just have more time to do all the things. Yeah, that's right. [laughs]

+ +

CHRIS: You're suggesting microservices, right? That's how my job becomes easy?

+ +

STEPH: Yeah. Well, I'm thinking more like RSpec Queue, but we'll have RSpec Chris or some version of that.

+ +

CHRIS: Chris Queue.

+ +

STEPH: Chris Queue. [laughs]

+ +

CHRIS: And then I just paralyze my human, and then it'll be great.

+ +

STEPH: Yeah, that's always worked out well in the movies. Whenever somebody clones themselves, that goes super well.

+ +

CHRIS: Multiplicity is a fantastic piece of cinema, and I stand by that.

+ +

STEPH: I haven't seen it, but I feel like it doesn't end well for the main character.

+ +

CHRIS: I feel like every time I mention a movie, you haven't seen it. I feel like we need to do a movie marathon at some point just to catch up so that we've got shared analogies. But yeah, it's a fun movie. It's fine. It turns out fine in the end. But there are some humorous adventures that happen in the middle. Cloning maybe [laughs] isn't the most direct option to solve productivity problems.

+ +

STEPH: [laughs] Yeah, I think I've got Labyrinth, Hackers, and Multiplicity now on the watch list. And I appreciate the fact that you know that I'm not likely to watch them, although out of the three, Hackers will probably happen.

+ +

CHRIS: All right, what if I were to get a bunch of Pop-Tarts, non-frosted?

+ +

STEPH: Ooh.

+ +

CHRIS: Does that change --

+ +

STEPH: Wait, are you going to send them to me? Because if you just have them, that's no good. [laughter]

+ +

CHRIS: Eat Pop-Tarts on a video call and be like, "Look at this movie. It's great." [laughter]

+ +

STEPH: All right, bribery definitely works for me. [laughs]

+ +

CHRIS: Okay, so got it, noted. And based on the nature of the conversation that we have devolved into here, I think we've probably reached a good point. What do you think? Should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!!!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris updates us on his new window manager of choice, Moom, and tells us what's good with it. He's also giving yet another task manager a go: OmniFocus. (Sorry Things.) Steph talks about defining test classes in RSpec and readdresses flaky tests to improve CI build time.

+ +

Chris is worried about productivity. He's still not coding as much as he'd like to be. Steph lends an ear, and together, they discuss potential ways Chris could gain back a little bit of coding time at work.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Well, hey, Steph. Oh, I have an update on a thing that I think I talked about a while back or at least asked on Twitter. But I've been looking for a window manager for forever. And in that way that I sort of overcorrected a while back, I think where I'm no longer allowed to do anything related to productivity or dev tools. I was just forbidden because it was a time sink. I'm slowly trying to correct back and be like, you know what? I regularly think about how it would be nice to have a better window manager.

+ +

So previously, I had used Divvy, D-I-V-V-Y, which is fine. It did an okay job, but it just didn't have quite the level of control that I wanted, or maybe I didn't investigate it enough. But it felt like it was lacking. So I did a little bit of research. A bunch of people recommended different things. There was Spectacle; there was Rectangle. There was a whole bunch of other things that I'm forgetting now because I have settled on Moom, M-O-O-M. Those are fun words.

+ +

STEPH: I feel like you keep bringing interesting words [laughs] because last time, it was Things where you're tracking all the things. And now we have Moom to track the space. All right.

+ +

CHRIS: If this is my legacy as a podcaster, then I feel like I will have done well just, you know, weird sounds mostly that's what he's going for. But yes, I've been using Moom now for…[laughs] God, it's just ridiculous to say, but here we are.

+ +

STEPH: [laughs]

+ +

CHRIS: I've been using it. I've been enjoying it. In particular, the thing that I liked about it...a bunch of the other ones that I looked at were like, oh, we've got all these different configurations. And you can move things any which way, and you can have any number of hotkeys. And I was like, wait, wait, wait, say more right now. You want to take over my global namespace of hotkeys and just clutter it with 19 different things? You know that that is a limited space that I'm working with here.

+ +

And so Moom, somewhat uniquely, at least in the ones that I experienced, was what I would describe as a modal window manager. So much like Vim is modal where you start out in normal mode, and you're moving around and you kind of bounce and search and all of that, and then you enter insert mode. And in insert mode, keys do different things. And then in command mode...it's got all these different modes. And so there are lots of different namespaces for hotkeys. It's one of the things that makes Vim so powerful.

+ +

Moom is similar in that there's one global activation hotkey. And then, within that, I can have a whole namespace of hotkeys. So like M will put something in the middle of my screen now. F will put something full-screen. And I don't need to remember weird multikey combinations for that. There's just the one to get started, and then I've configured it such that the tab will bounce to a secondary display and sort of rotate through them.

+ +

M and F and Q and P I've got it physically laid out on the keyboard. So it looks like my screen. Q being on the left side will push something to the left side, P to the right side. And I'm very happy with that. I don't need a lot out of this tool. I don't need very complex management or scripting or any of that, which are very nice features that exist in the other ones. But that combination, the one hotkey to rule them all, and then the sub hotkeys within it, and the ability to mostly move between the screens and then put stuff where I want it is great. I'm very happy.

+ +

STEPH: I think I've figured it out. So Moom, I think it's a combination of move and zoom, and that's how they got Moom.

+ +

CHRIS: You're probably right.

+ +

STEPH: That does sound really nice. I'm a Spectacle fan. And I have enjoyed it and just stuck with it because I haven't felt a need to change from it. And it's really nice where I use my arrow keys for which direction I want to go. So that has been easy for me to recall. But that sounds really nice, all the things that you're describing with Moom.

+ +

CHRIS: Does spectacle have the like, is it some Command Option Control and then left or right or up or down? Or is it you type something, and then you type left, right, up, down?

+ +

STEPH: I have to actually touch my keyboard to answer that question because I have the muscle memory, which is an interesting thing that my muscles knows it, but my brain has to really think about it. So I think it's like the Option Command, and then yeah, then use the arrow keys.

+ +

CHRIS: Gotcha. That's roughly what I had when I was using Divvy previously, but I found just enough of a limitation there. And so Moom has been great as another tool. But I think Spectacle has a lot more features in terms of scripting and other fancier stuff that you can do, which is both super intriguing and, again, sort of the thing that I'm not allowed to do. [laughs] So I went with, like, this tool seems fine and has the one feature that I really want.

+ +

That said, you brought up Things, which is the to-do list app that I've been looking at. I've been using it for a week now. It's great. I'm enjoying having a more structured way to say, like, here's what I'm doing today. Here's what I'm doing tomorrow. It's been wonderful. But I'm already looking at OmniFocus as a better version.

+ +

STEPH: [laughs]

+ +

CHRIS: Because I think there's some stuff that I don't love, and yes, I can hear my own voice in the back of my head that's like, always chasing that next thing. But I haven't actually made the effort to switch over or even tried. I've used OmniFocus in the past. But anyway, I'll let you know if I do make additional moves there.

+ +

STEPH: Yeah, I'm enjoying this journey. Keep me up to date on it. I've heard of OmniFocus, but I know nothing about it. But I feel like I've heard good things. So I like this journey you're going on where you just keep switching and trying new things. That's fun for me [laughs], and there's chasing productivity. So I'm into it; I'm here for it.

+ +

CHRIS: If I just invest enough hours to save a handful of minutes down the road, then I will have...oh no, wait, that's not how this goes. There's, of course, an xkcd about this which we can include in the show notes. But I'm trying to be very intentional with it. I waited for many years before I allowed myself to reinvestigate the world of to-do lists. And I'm hopefully going to keep it to just a couple of weeks of nonsense and then back to a few years of stable. That's the dream.

+ +

But yeah, that's some of the smaller things that are up in my world. I have another topic that I want to chat about. But I'd love to hear what's new in your world?

+ +

STEPH: Yeah, I have some interesting bits that I can talk about with the project that I'm working on. But more concretely, I have something that's been on my mind that I don't think that I've talked about here on the show, but I think would be fun to talk about because I just happened to run into it this week while working on some code.

+ +

And it's the idea of defining test classes in RSpec so as you are testing part of your code, but then you want to create just like a fake class, something that you can use as a substitute for real application code. And so it's a really nice way that then you can have this replica behavior, but then maybe it's just one particular method or some behavior that you need to use in the class but then doesn't actually go to the real code. That's wonderful. That's great.

+ +

One thing that I've learned is that with RSpec is when you are introducing a test class, so let's say if you have your RSpec describe and then either a string or it's the name of a class, and then you have a block so do, and then within that block is where you write your test. If you create a temporary class, say, like I have my class test class, and then I have some behavior, that gets defined in the global namespace. It's not scoped to that particular RSpec example. And the reason for that it's not specific to RSpec. RSpec is not the one that's doing this; it's actually Ruby behavior.

+ +

So for Ruby, when you're defining within a block like that, if you're defining a constant, if you're defining another class inside of a block, it's going to use the outer namespace as its namespace. So if you had a top-level class that you were defining, but if you define a class as a block, and then inside of that block you define a constant, that constant is then defined in the object namespace instead of within that particular class that you have written. And so that's why RSpec has this behavior.

+ +

Because someone brought up a really great question about this on RSpec::Core asking about it, and they're like, yeah, that's actually how Ruby works. And so we're not going to change RSpec's behavior since that is how Ruby has decided to handle this. And the part where this becomes important is when you define a test class within an RSpec example.

+ +

While it may be unlikely that someone is going to use that exact same name for their test class that they're going to create in their RSpec example, if they were to use that same name, then you're going to have a collision between the two. One of them's going to win, and you're probably going to end up with some really weird test failures because it's going to get confusing as to which class is being used, and they may not match up with each other.

+ +

So one way around this, and this is going to be one of the rare times that I suggest this, but let. Let is scoped to an RSpec example. And so you could define a class inside of a let, and then that will scope it to the example. There are probably some other approaches as well, but that's the one that I'm most familiar with to ensure that when you define that class or constant, it's not getting defined in the global namespace and ensuring that none of the other tests have access to it.

+ +

CHRIS: Well, this is certainly interesting. I'm pretty sure I've been operating under the opposite assumption for the entirety of my career. This is good to know. I feel like I probably have had tests that failed because of this. And then I learned this truth, and then I subsequently forgot it. I don't know if you know this, but if you define a method within just a helper method that you extract in RSpec, are those also on the global namespace?

+ +

I don't define classes in RSpec blocks that often. It's pretty rare. Like if I have a controller concern sort of thing that I want to test, I might say random controller and inject the thing there or some other abstracted piece. That is the only case I can think of where I have a fake model or a fake controller or something like that for test purposes. But it doesn't come up that often. I do extract a heck ton of local helper methods. And I'm wondering now, are those all in the shared global namespace?

+ +

STEPH: I'm pretty sure they're not. And I'm getting on the edges of my knowledge here, but I think it has to do with the fact of when you're defining a constant. So if you're defining a class versus an actual constant, that will get into the global namespace because it's using the outer scoping. But in my experience, I'm pretty sure that's not true for the method just because I remember one time I did some funky stuff with RSpec. And I remember seeing that I couldn't access those methods from another example.

+ +

CHRIS: I like the honesty. And you're like, to be clear, I was doing something weird, but I learned that day. Okay, that's good because at least that part maps to my understanding. So methods may be safe, but classes get shared. Very interesting.

+ +

STEPH: And it's something that I rarely think about or had worried about just because if I'm defining a fake test class, I often will put it somewhere that's intended to be more global. So I'll stuff it somewhere in like spec support. So then other people can see, hey, I've already mimicked this behavior. So if you need to use the same thing, just go ahead and use this. It's not often that I am adding that class directly to the RSpec example group.

+ +

So I think I've been fortunate where I haven't actually run into that conflict for that reason. But this came up while giving an RSpec course. And while we were just in a very small, tiny codebase and replicating some examples, someone in the class was like, "Hey, by the way, do you know that that's in the global namespace?" And I was like, "No, friend. Tell me more." So thanks to that person, they're the ones that actually enlightened me about how it's going into that namespace and how it can actually pollute your testing namespace.

+ +

There's a really good article that's written by Ken Mayer. And we'll be sure to include a link in the show notes that talks about it and also provides the let example as a way to work around this. And also links to the GitHub discussion on RSpec::Core, where they talk about this behavior and why things are the way that they are.

+ +

Circling back to some of the more general project-y things that I alluded to earlier, I've shared a bit about the project that I'm working on. But just to recap it, it is focused on helping a very large team that has a large number of tests, around 85,000. And they are looking to address flaky tests that they have and overall really improve their CI build time. So right now, it takes about 30 minutes for the build to take place. But they also have flaky tests, and then that slows things down. And so, the re-verify rate has been painful for them.

+ +

There's been some really great work that has improved that, particularly there is a, I think we've talked about this before, but where they're re-verifying certain flaky tests, which isn't great because they're still flaky tests, but at least they're not preventing people from moving forward and shipping code.

+ +

But some of the bigger stuff that is just on my mind is when you have a very large team and a very large application, by large team, I'm talking about 100 developers, and they are all contributing to this codebase. And there are around 85,000 tests, and that has grown substantially in the last 12 months. And so, if you think about the trajectory of the addition of those tests, it is just going to continue to grow. So there's a concern there of even if we address flaky tests and we improve things, there's an architecture concern of how do we really reduce the CI build time?

+ +

And so there's that aspect, and then there's also the aspect of then well, how do we still work to improve the tests and the codebase as well as we go across all of these disparate teams? And right now, there is a bit of a culture where engineers don't feel empowered where they can necessarily address all of the flaky tests or things that they run into. And so there is a bit of a mindset of I'm stuck on this, or this test failed, or it's flaky, or I don't understand it. So I'm just going mute it, or I'm going to hand it off to someone else to work on it.

+ +

So there are three big areas that are on my mind. The first one is architecture. You can throw architecture at it. There's also the code quality that's a concern. And then how do you improve the code quality in a way that you're improving it fast enough that then you've got 100 other developers that are also contributing to it at the same time? And then individual IC empowerment where then people feel like, hey, I ran into a slow test or a flaky test, and I feel like I can triage this, and I can make changes.

+ +

For the architecture piece, we're still in the infancy stages of how to approach this and the strategy that we're using. But one of the ideas that has come up is how do we reduce tentpoles? And the tentpole is like when you're running your test and, let's say that it's parallelized, all of the various tests. But there is one process that takes like 20 minutes, and then the other process is completed in 5 minutes as a drastic example.

+ +

And overall, you could have reduced your time if you had managed to split that 120-minute process across all the other workers who are then available for that work. So there are some tentpoles that are taking place. And that could be one first step in reducing the CI build time.

+ +

There are also discussions around how to scale horizontally. Right now, we don't think that's something we can do with the service that we're using to run the test. But it's something that maybe we need to manually look into is then how do we build a queue of all these tests and not where we just split test by a file, which is typically how the Parallelize gem does it.

+ +

But you could actually split up tests within a file. So if you had a particularly large file, that doesn't necessarily matter. But then building a queue of all these tests so then as each test finishes, a worker can just grab that next test. And then also you can easily scale up and scale down workers. As I'm saying that, that feels big, that's a lot to invest in. But that as an idea is how can we essentially then scale the architecture? So even as we continue to invest in the tests, in the system, and they continue to grow, our architecture can keep up with it.

+ +

CHRIS: That last bit there is super interesting to me. It's something that I've looked into and haven't pursued yet. We're currently running on CircleCI with our test suite. And I don't even know that we pushed on parallelization because we're early enough on that. And we turned off bcrypt recently, which super-duper helps with the speed up. But overall, the test suite time is fine, is where I would put it.

+ +

It had crept up, though, to a place where it was starting to be painful, is how I would describe it. And I think it's very easy for that to just continue growing and suddenly, it's 20 and 25 minutes. And then, depending on your merge strategy and all of that, it can be all the more complicated, and this gets in the way of deploys. And so, I think it is a super important thing to keep an eye on. I know Charity Majors pushes really hard for 15 minutes from merge to deploy to production. And so if your CI suite takes 25 minutes, then already you're stuck.

+ +

As an aside, I just once more want to say out into the ether, CircleCI or any other CI platform, if you would allow me to say yes, we've already tested this Git hash, this Git SHA, or the working tree, ideally, because that's also deterministic, I would love that feature. I would love to not have to rebuild the same code when it gets merged into main, just saying once more out into the world. Also, GitHub, if you want to put me on the merge queue beta, I would love that if anybody out there is listening. [laughs]

+ +

STEPH: I like how this has become a special requests hotline for all the things [laughs] that you're hoping to get a part of or features you'd like to see added.

+ +

CHRIS: Hello, internet. I have some requests.

+ +

STEPH: [laughs]

+ +

CHRIS: I would love to see those things, but in the world where those don't exist. The particular thing that you're talking sort of a test queue, is something that I've seen. So Knapsack is a...what's the word? It's a tool; it's a service. It's a combination of things. But it does that essentially where it starts up a local build agent. And then it basically says like, all right, give me all of the tests that you need to run, and then I will feed them back to each of the individual agents that there's one agent running per parallelized process.

+ +

And so say you've got five of them. The first one says, "Hey, give me a test," and runs it. And the second one says, "Give me a test," and et cetera. And so, the queue manager on the other side is in charge of that orchestration. And it means that they basically all finish in identical time, with one being an outlier, whichever one happens to be the longest.

+ +

But it's only going to be however long your longest test is is basically that outlier versus what you're describing of like, well, if we split it by file, we can end up with more naive things where there's a bunch of feature specs on one of them, and it skews by two minutes. We obviously don't want that. So Knapsack, in particular, is a tool that I've looked at, but generally, I'm very interested in that as a solution to how do we maximally take advantage of parallelization there?

+ +

STEPH: Interesting. I have not heard of Knapsack. There is one that sounds similar. It's called RSpec Queue. And it does some really interesting work where it will split the individual test, so it won't do it by file. It will also look at historical data to then try to be intelligent about how it's going to split it and find the longer running test. And I believe it uses Redis to then keep track of the test set up in run and things that still need to be run. That is a gem that the team is looking into using as well.

+ +

I don't know how that works if that can integrate with the current platform as we're using TeamCity to run tests. I don't know if that's something that can integrate with TeamCity, if it's a replacement. I don't have all of the knowledge about RSpec Queue yet. But it seems to do a number of the things that we're interested in. So even if we can't use the gem, then maybe it's something that we can still imitate.

+ +

CHRIS: The other thing that I'm surprised we haven't said yet is this is one of the places where people would often reach for microservices. I feel like we have to have the microservice conversation at this moment. Microservices can actually be a great solution to organizational problems. As a team scales, it does become really hard to manage a large group of developers. And so microservices introduces a very fixed boundary that then draws nice lines that you can have around things. And so, the individual build time for a portion of your application can be much more manageable by virtue of that.

+ +

But it has this huge cost of technical complexity and overhead and et cetera, et cetera, all of the reasons that we may not want to go that route. And so interestingly, I was just looking at Shopify's Deconstructing the Monolith blog post, which I think at this point, they've skewed a little bit more into the microservices. Shopify is huge, one of the largest Rails apps out there. And so looking at them and being like, oh, what are they doing? It's an interesting sort of plot a course and to see how long they waited before they even started thinking about the much deeper things and even exploring microservices.

+ +

But in this blog post, they talk about a different approach where they stuck with sort of a monolith. But then they started to introduce Rails engines and clear encapsulation within the large codebase such that then you can actually start to say, well, we don't need to run all the tests every time because if we're making a change within this section of the application, then we just need to run those tests.

+ +

I've also heard of organizations having some logic that can determine based on the code change; we know the associated test files that we should run. I'm scared of that is how I would describe it. I want to trust my test suite. I want to be able to deploy on a Friday and say if tests are green, it's going out to production. That's great. And I worry about that sort of thing. That's hard to get right. That feels like caching, right? And that's one of those things that we historically get wrong a lot.

+ +

But nonetheless, that is an approach that large organizations I've heard having good success with. So some way to determine what's the affected code and what tests do we need to rerun and et cetera. And that can really drastically reduce down the scope of each CI build. But those are some larger things that I have not had to reach for on any of the applications I've worked with. I've taken different approaches, different ways to reduce the time or otherwise Parallelizer et cetera. But it's interesting for when you get to a certain scale.

+ +

STEPH: Yeah, it's funny that you bring up that idea because that came up in conversation with some of the other developers as well, was the idea of, like, what if we could just not run all the tests? You changed one file, and you don't need to run everything. And I immediately was like, that sounds very cool and super hard to be able to get right.

+ +

And a lot of this code is extremely coupled, which then moves to the code quality area. So I suspect a lot of the test times could be improved by creating smaller objects because right now, a lot of the tests will load the entire world because they have to. They have to test everything. And so that is creating a ton of data, and then taking a long time to run versus if we were able to split out that code into smaller objects and test in unit tests, then that would also help speed up. But that's also hard to do.

+ +

Where do you look first? We do have some great data, thanks to RSpec. RSpec is letting us know how long each test file takes to run, and then we are capturing that data. So I can go look at which files and say, oh, this file takes 10 minutes to run. Let's look at that file first versus some of the other ones that are performing better. But that is a battle that will take a long time to win. And it's something that takes consistency and then also encouraging others to join that battle. So while it's very important, it doesn't address the concern of tests growing rapidly and then being able to support that.

+ +

Something that you said in a previous episode also was on my mind in talking about building processes in a way that encouraged people that they can make small, quick changes. And I think that's really important. So if we can build out the architecture to help scale this so then the tests were running in say 15 minutes, then if someone saw a test and they wanted to make a small refactor, they saw a factory.create, and they're like, oh, that could be a FactoryBot.build_stubbed instead and issue that into a pull request or change request and get that merged.

+ +

I don't know if people feel as comfortable doing that right now because it takes them 30 minutes or longer to run the test. But that idea of how do we get a structure in place where people can make tiny, little improvements and do that as a whole, as a team, to then work on the code quality concerns?

+ +

CHRIS: That last little bit is so interesting where you're saying, like, oh, we have a FactoryBot.create, FactoryBot.Build, but it has the overhead of having to go through the 30-minute test suite. But coming back to the thing we were talking about before, what if we didn't have to run all the tests? Although I find it very hard to tell, given a code change in actual production code, what tests do I need to run? When I'm just changing a test, I'm pretty sure I know which test I need to run in order to determine if that test still runs correctly.

+ +

So that feels is there an optimization that can happen there? Which is I've only made test changes; therefore only run the changed tests. And then that's an encouragement to say, like; this is a part of our codebase that we are trying to improve on. Let's optimize the iteration speed there. You'd have to figure out how to write that. And so it's probably much like my productivity adventures, maybe not a good investment.

+ +

Although given that this is such an organizational concern, maybe that is the thing that's worth spending an afternoon on and seeing if it could happen. Because if you can speed that process up, get more [inaudible 23:46] and more iteration in fixing the tests, that feels like it could be a win.

+ +

STEPH: I think that's a really good idea. I think we could certainly tell that if a file's changed, that it's only a test file that has changed. And then I've heard very good things from the other developers that TeamCity has a wonderful API to work with. And so there's a way that we could then tell TeamCity to say, hey,...or it may not even be a TeamCity command. It may just be somewhere in the universe we have to say, "Hey, RSpec, only run this test," or "TeamCity, we're only going to feed you this one RSpec test to run, so user agent but only run this particular test."

+ +

So I really like that idea. I think that's really intriguing. And I'll bring it up with the team because that would be a huge win, especially as Joël and I are really focused more on tests. That would just improve our lives. So selfishly, I'm excited about that idea because we are touching less of the application code and more focused on improving the test at this point.

+ +

CHRIS: I mean, if right now you're getting, say, 5 or 10 pull requests through a day which frankly feels like a high bar on this, if suddenly that's 10 to 20, that's material right there.

+ +

STEPH: Yeah, I don't know how large of an impact it would have for the rest of the team because I don't know how often they're only making changes to a test file, but it still feels like a nice optimization to have. Cool. Well, thanks. I appreciate that idea.

+ +

CHRIS: My pleasure.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: What else is going on in my world? I continue to not code a ton which is interesting and probably makes sense for right now. But to share a small anecdote from this week, we had retro, and I ended up attending retro ever so slightly late. I was doing a hiring interview, which is super exciting. Again, for anyone that's out there, we are hiring at Sagewell Financial. And I would love to chat with you if that sounds interesting. But so I was having a wonderful hiring conversation that ran a little bit long.

+ +

So I was a little bit late to retro, and I arrived, say like eight minutes in, and someone was expressing a concern. And the concern was, I very sincerely know this to be true, but they were saying in the most positive way. But they were like, "It'd be great if Chris could code more," and not in the judgmental like, Chris, why are you not getting as much done? Not in that way at all, very much in the it would be great if Chris had more time, if there wasn't as much pulling my attention in different directions.

+ +

But then it kind of went into this interesting direction. So we then go back through and address the concerns and talk as a group about how we resolve them. But this one was like, my name was in the concern, again, in a very positive way, in a very supportive way. And we had a wonderful conversation, and there were really great ideas that were passed around. But man, did I feel weird having my name in a retro item. [laughs]

+ +

STEPH: So one thing I've learned is that you do a really good job when you are giving presentations and being in the spotlight. But I don't think you actually love it. You love sharing content and things that you have learned. But I could see how being a focal point, especially if there's a concern or something that could have a negative connotation, that would feel squeamish. It would make me feel squeamish.

+ +

CHRIS: I hadn't thought about it in that way. But as you say it, also, this conversation is a meta version of that. Like, let's talk about me talking about me. I don't want to be the center of attention. But I love technology or process. I love talking about the work. That's great. And so I'm happy to do that. I'm happy to stand in front of a room and talk about it. But yeah, when it's about me, that's weird. And so now I'm going to move...well, no, I'm not going to move on [laughs] because this is the topic right now.

+ +

But so there's a bunch of things that we have been trying to introduce. And I think this is a useful part of the conversation more broadly and less about me. So one of the things that I think I mentioned in a previous episode was the introduction of point-dev, which is each week, we rotate through a person. And that person is in charge of triaging the errors, making sure that nothing is stuck in Sidekiq, responding to any support requests, et cetera, et cetera. But they're meant to be the frontline such that everyone else can be heads down and really focus on the work.

+ +

And what was interesting of the three developers that are working on the project, I am point-dev this week. So I was like, yes, that's awesome this week because I'm the person on the frontline. That has not helped me, but in the future, it will. And then one of the other developers mentioned that they feel like it's really useful but also feel like it's been noisy. And we realized the previous week was their week on point-dev. But the other developer was like, "Yeah, it's been great. I haven't had to think about anything." And so they have been off of that rotation for two weeks now. They'll be taking it over next week.

+ +

But it is doing exactly its job of providing that attention coverage so that they can keep their focus on the code, and that's really wonderful. So I'll be honest, when we started talking about it, there was a tiny voice in my head that was like, is this a failure mode? Should we be dealing with the noise rather than having a process to address it in the moment? Should we be dealing with the root cause rather than the symptoms? And I still think that's a good point of view. But we found so much value from this.

+ +

And as I've mentioned it, many people are like, oh yeah, we have that. It's great. I've heard enough positive things. So I've backed away from that. But there was a voice in my head that was like, are we failing right now? But yeah, so point-dev has been really wonderful. And next week, I will have to...well, frankly, the next two weeks, I'm off of point-dev appointments, so I'm very excited about that.

+ +

I've been doing some of the product management or sort of the tech side of the product management and helping to triage cards and make sure that there's very clear work lined up for the engineering team when they're ready to do that. I'm trying to back away from that just a little bit.

+ +

And one of the things that we did there was introduced an inbox column in our Trello board. You know how I love a good inbox. You know how I love to get to inbox zero. But that is a good way for me, for anyone now in the organization, which I don't want everyone to have to learn our processes, but just saying, "This is the place that you put requests, and we will deal with them. I assure you of that."

+ +

It has been great because that means I don't need to be quite as responsive in Slack. I can just gently redirect people, "Hey, if you don't mind, please put this in Slack in the inbox column, and that'll be great." That thing, though, that gentle pushback in Slack is one of the things that I've struggled with.

+ +

And this was one of the more personal aspects of the conversation that happened in retro was me being, like, if we're being honest, I tried to do that. But it's not my favorite thing to do in the world. Whenever someone asks me something, I want to be helpful. I don't want to seem rude or brisk or like I'm too busy for you, et cetera, et cetera.

+ +

So I will often respond to the question or do the thing that they're asking and then say, "In the future, if you could go to this other place." And ideally, I'm slowly moving forward and being like, "No, no, no, please go to the other place. We've talked about this a few times." But it is an interesting example of one of the specific aspects of my personality coming through in this. But that introduction of an inbox has been great. Love me a good inbox, as I said.

+ +

And then, more generally, we just tried to talk through what are the things that I'm doing? Do I need to own all of those uniquely? And some of them the answer we decided was yes but some of them we decided no. And we started to sort of distribute the work there or some of the meetings or different aspects of it. And so overall, it was a really great conversation but also very weird for me.

+ +

STEPH: Yeah, because then you wonder, am I not doing the right thing? Am I not spending my time the right way? But then hopefully, that meeting helped reinforce that yes, you are spending your time the right way and that you're doing a lot of productive things. There are just too many productive things for you to do, and so you have to prioritize those aggressively. I like all the things that you just highlighted.

+ +

There's one in particular, the last one that you mentioned about finding things that you can hand off to others. And I love that for a couple of reasons. It came up in a recent conversation that I was having with some other thoughtbot developers around when someone's on a project, typically someone just falls into being the point person. They just happen to be the person that the client talks to and ask questions and goes through the most. And that's something that is okay. But we want to make sure that that's not a bad thing, that everybody is treated equally, that everybody is given equal opportunities and room to grow.

+ +

And so, in my mind, whenever someone is that point person, or you have fallen into that role, it is your job to then pull other people up. So if you have been given the responsibility of running a particular meeting each week, then go ahead and do it once or twice, so you can demo it and show it to someone else as to how you do this. But then tag somebody else and say, "Hey, I'm going to let you or ask you to run this next time." So then that person can experience it. They can demo their style, and then it continues on to have more people.

+ +

So I really like that you are highlighting it's not just beneficial for you to then distribute those tasks, but it's empowering for everybody else on the team as well. I'm curious, so what was the final outcome? It sounds like there are some really good things in place, and you're transitioning, handing some things off. But I can't imagine that things have gotten...all of your priorities are still there. So do you think you'll actually code more, or what's the outcome for next week?

+ +

CHRIS: Short term, maybe probably not, if we're being honest, but trending in that direction. So one of the things that's going on right now is hiring. That is just an activity that takes a lot of time. And I care a lot about doing that well, both for the organization and then for individuals on the other side.

+ +

I want to be respectful of their time and communicate in reasonable timelines and not leave people without an answer or follow up or those sorts of things. It probably makes sense for that to sit with me as the starting contact. And then from there, folks that are continuing on in our hiring process they're going to talk to many other members of the team, and that won't just be me.

+ +

But there are a lot of first conversations that I'm having. And so right now, my schedule has a bunch of that, which is fine and good. And that will hopefully, at some point, we'll hire some great people. And then we'll be on the other side of that. And that piece of the work that I have right now goes away.

+ +

Some of the other outcomes that we named there were a couple of action items. And so I think those will help, but they're sort of we got to work towards that. One is transitioning a meeting, but it's a biweekly meeting. And I'm not going to just not attend the next one. So it'll be me and one of the other developers attending to transition ownership of that meeting moving forward. And then from there, so like, two weeks from now, I will not have that consideration on my calendar. And that's like one 30-minute block that I get back or, depending on how you think about it, one block that that 30-minute broke up.

+ +

I do want to touch back just on something that you're saying there. I think you're being very kind to me in saying like, no, but you've got so many things, and so it's hard to do that. I think that's true, but that's kind of the work overall, and my version of that is one thing. But everyone sort of has, as a team, we have a version of like, how are we being most productive? Are we making sure we're doing the most important things? And so it was interesting in the moment, but I think it was a very good conversation.

+ +

And I want to make sure that both we as a team and then me as an individual, wherever that happens to be the case, are open to these sort of constructive things. Like, frankly, to do the work to figure out how to get work off my plate that hasn't felt like the most important thing. It felt like close to the most important thing, but then there were all the other things that I had to do. So I wasn't doing the work to figure out how to not do the work. It is a complicated sentence that I just said.

+ +

But this was a case where retro, I think, very usefully highlighted that this was a good thing for us collectively to put effort into such that we can be more productive moving forward. It happened to be slightly more focused on me rather than the entirety of the team. But broadly, that kind of thinking is why I'm a huge fan of retro. I think it's a great place to take a step back think about how we're doing the work rather than just being in the work day-to-day.

+ +

STEPH: So if I'm internalizing what you said correctly, let me know if not, but it sounds like you're in one of those places, and I've witnessed this with other people and myself where someone is overwhelmed. They have a lot to do, and they're very focused in that grind and in that moment of doing all the things that they have to do. And it's very hard to then say, "I'm in the weeds right now. And then I also have to figure out how to get out of the weeds." And that's a very different skill and mental space to be able to do that.

+ +

Because often, when you're just in that mode, all you can focus on is a bit on survival at that time. And then it may take other people to notice to say, "Hey, you're in the weeds. We need to figure out a way to help you not live there and to find ways to distribute some of the work."

+ +

Does that sound like a fair assessment? Because I think I say all that because I've just seen people in that position. And then they think back, like, oh, I should have offloaded stuff earlier. And it's like, yeah, true, totally. And it often takes a retro or someone else coming to you and saying, "Hey, I've noticed...I looked at your calendar today; how can I help?" [laughs]

+ +

CHRIS: I think that's probably the right calibration. And mostly, my emphasis was just I want to make sure that broadly, any team that I'm on has the space for this sort of conversation. And that thing that you're saying exactly that phrasing of like, "Hey, I saw your calendar. How are you doing? How's that going, though? Are you feeling okay? [laughs] You can't sleep and whatnot." That can be a really useful thing to have and to have organizational norms about what are our expectations of how many meetings someone should have in a week. And where do we start to think about different things?

+ +

You did use the phrase overwhelmed. I want to say that I'm like 101% whelmed. So I'm just ever so slightly overwhelmed, but it is like I'm in the weeds. I need to figure out how to clear some of the weeds so that then I can get out of it. And it was a great conversation that came from that.

+ +

STEPH: That's awesome. I'm glad you got a good team that, frankly, felt comfortable bringing it up, and then that you could lean on them for ways to talk about how you could code some more and talk about priorities and where you want to focus your time.

+ +

CHRIS: It will be an interesting thing. As the team grows, I don't expect this to get easier. We talked about this a number of weeks back. And I think for a while; hopefully, we clear a little bit of dust here, and then I get back to being a little bit more on the code, and that's going to happen for a while. But as I think about the longer sort of the future of the company, this is something I'm going to have to revisit a handful of times.

+ +

And it's a really interesting question that I'm still struggling with internally. And where do I want to be versus what will be needed and whatnot? So it'll be interesting to see how it evolves. But for now, I think I can gain back a little bit of coding time, a little bit of maker time versus manager time, as Paul Graham's essay goes. And yeah, I think that'll be good.

+ +

STEPH: Yeah, I like how you're already looking forward to the fact that it will probably fluctuate because, yeah, right now, you are sort of paying a tax. You are building up to then where you can have more people on the team. And then that may give you back some of your time where then you can code because you can outsource some of the work to them. But then, as the team grows, so are other responsibilities. And traditionally, being in a CTO role and most CTOs I know will code here and there because they want to, and they enjoy it, but it is not their full-time job.

+ +

So I think you're really wise to have already noticed that and start thinking about how that's going to trend in the future. And it sounds like you might need to figure out how to throw some architecture at it. So then you can scale horizontally, and then you can just have more time to do all the things. Yeah, that's right. [laughs]

+ +

CHRIS: You're suggesting microservices, right? That's how my job becomes easy?

+ +

STEPH: Yeah. Well, I'm thinking more like RSpec Queue, but we'll have RSpec Chris or some version of that.

+ +

CHRIS: Chris Queue.

+ +

STEPH: Chris Queue. [laughs]

+ +

CHRIS: And then I just paralyze my human, and then it'll be great.

+ +

STEPH: Yeah, that's always worked out well in the movies. Whenever somebody clones themselves, that goes super well.

+ +

CHRIS: Multiplicity is a fantastic piece of cinema, and I stand by that.

+ +

STEPH: I haven't seen it, but I feel like it doesn't end well for the main character.

+ +

CHRIS: I feel like every time I mention a movie, you haven't seen it. I feel like we need to do a movie marathon at some point just to catch up so that we've got shared analogies. But yeah, it's a fun movie. It's fine. It turns out fine in the end. But there are some humorous adventures that happen in the middle. Cloning maybe [laughs] isn't the most direct option to solve productivity problems.

+ +

STEPH: [laughs] Yeah, I think I've got Labyrinth, Hackers, and Multiplicity now on the watch list. And I appreciate the fact that you know that I'm not likely to watch them, although out of the three, Hackers will probably happen.

+ +

CHRIS: All right, what if I were to get a bunch of Pop-Tarts, non-frosted?

+ +

STEPH: Ooh.

+ +

CHRIS: Does that change --

+ +

STEPH: Wait, are you going to send them to me? Because if you just have them, that's no good. [laughter]

+ +

CHRIS: Eat Pop-Tarts on a video call and be like, "Look at this movie. It's great." [laughter]

+ +

STEPH: All right, bribery definitely works for me. [laughs]

+ +

CHRIS: Okay, so got it, noted. And based on the nature of the conversation that we have devolved into here, I think we've probably reached a good point. What do you think? Should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!!!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+W2KKDc8P + + ]]> + + Chris Toomey + Steph Viccari + + + 323: Doing Things + https://bikeshed.thoughtbot.com/323 + 48f06631-0b1d-4890-be46-cd8be31652a5 + Tue, 25 Jan 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph talks about winter storms and thoughts on name pronunciation features. Chris talks about writing a query to add a new display of data in an admin panel and making a guest appearance on the Svelte Radio Podcast. + +Finally, Chris decided that his productivity to-do list system was failing him. So he's on the search now for something new. He asks Steph what she uses and if she's happy with it. How do you, dear Listener, keep track of all your stuff in the world? + 45:43 + no + + + Steph talks about winter storms and thoughts on name pronunciation features. Chris talks about writing a query to add a new display of data in an admin panel and making a guest appearance on the Svelte Radio Podcast. +Finally, Chris decided that his productivity to-do list system was failing him. So he's on the search now for something new. He asks Steph what she uses and if she's happy with it. How do you, dear Listener, keep track of all your stuff in the world? +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Upcase advanced Active Record (https://thoughtbot.com/upcase/advanced-activerecord-querying) +Svelte Radio (https://www.svelteradio.com/episodes/chris-toomey-talks-svelte-rails-and-banking) +Things (https://culturedcode.com/things/) +Todoist (https://todoist.com/) +MeetingBar (https://meetingbar.onrender.com/) +SavvyCal (https://savvycal.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. We have Winter Storm Izzy headed our way. It's arriving in South Carolina early tomorrow morning. So that's kind of exciting just because it's South Carolina. We rarely see snow. In fact, I looked it up because I was curious because I've seen it every now and then. But I looked up the greatest cumulative snowfall in 1 season, and it was 19 inches in the winter of 1971. I was trying to add an old-timey voice there. I don't know if I was successful. +CHRIS: Does 1971 deserve a full old-timey voice? +STEPH: Apparently. +CHRIS: I feel like people from 1971 would be like, "We were just people in the 70s." Like, what do you... +STEPH: [laughs] +CHRIS: Wait. Nineteen inches, is that what you said? +STEPH: 19 inches. That was total for the season. +CHRIS: Yeah, we can bang that out in an afternoon up here in the North. So yeah, okay. You were here for the terrible, terrible winter, right? +STEPH: Oh, Snowmageddon? Yes. +CHRIS: Yeah, that was something, oof. +STEPH: I don't remember how many inches. Was it like 100 inches in a month or something wild like that? I've forgotten the facts. +CHRIS: I, too forget the facts. I remember the anecdotal piece of data, the anecdata as it were where we shoveled our driveway, and then another storm came, we shoveled our driveway. And then finally, I was living in an apartment, and it was time to shovel the driveway again. But the pile of snow on the lawn was too big. So we had to shovel the pile of snow further up the lawn to make room for the snow that we were shoveling out of the driveway. +But I also remember that being a really nice bonding moment, and I met more of the people living in the...it was a house that had been converted into six apartments. So I actually met some of the people from the house for the first time. And then we hung out a little bit more in the day. So I actually have weirdly fond memories of that time. But to be clear, that was too much snow. I will officially go on record saying too much snow. No, thank you again. +STEPH: It was a lot of snow. I think it broke Boston for a while. I remember I don't think I went to...I worked remotely for two weeks because they were just like, "Yeah, don't even try to come into the office. Don't worry about it." So it felt like my first dabbling into understanding quarantine [laughs] except at least with less complicated reasons, just with lots of snow. We also went snowboarding in Charlestown, where we were living. And that was fun because there are some really great hills, and there was so much snow that that was delightful. +But I'm not expecting Snowmageddon in South Carolina, although people may act like it and rush out and get their milk and bread. But hopefully, we'll get a couple of inches because that'll be lovely. I don't know that Utah has ever seen the snow. So this will be fun. +CHRIS: Oh, that'll definitely be fun. I imagine you've got like even if you do get some amount of accumulation, a day later the sun will just be like, "I'm back. I got this," and clear it up, and you won't have any lingering. The year of Snowmageddon, if I remember correctly, the final pile of snow left in July, the shared one that the city had collected. So you'll probably do better than that turnaround time. [laughs] +STEPH: Yeah, it's perfect. It's very ephemeral. It snows, it's beautiful. It's there for a couple of hours, and then poof, it's gone. And then you're back to probably 70-degree weather typically what’s here, [laughs] which I have no complaints. There's a reason that I like living here. +But in some other news, I have something that I'm really excited about that I want to share. So there's something that you and I work really hard to do correctly, and it's pronouncing someone's name. So whenever there is either a guest on the show, or we are referencing someone, we will often pause, and then we will look for videos. We'll look for an audio clip, something where that person says their name. And then we will do our best to then say it correctly. Although I probably put a Southern twang on a lot of people's names, so sorry about that. But that's really important to say someone's name correctly. +And one of thoughtbot's projects is called Hub, which is something that we use internally for all of our project staffing and then also for profiles and team information; there’s a new feature that Matheus Richard, another thoughtboter, implemented that I am just so excited about. And now that I have it, I just think I don't know how I lived without this. And I want it everywhere. +So Matheus has added the feature where you can upload an audio file with your name pronunciation. So you can go to someone's profile, and you can click on the little audio button and hear them pronounce their name. And then a number of people have taken it a bit further where they will provide, say, the American or English pronunciation of their name. And then they will provide their specific pronunciation; maybe it's Greek, maybe it's Spanish, and it's just phenomenal. And I love it so much. And I can't wait for just more platforms to have something like this. So really big shout out to Matheus Richard for that phenomenal feature. +CHRIS: Oh, that is awesome. Yeah, we definitely do pause pretty regularly to go scan through YouTube or try and find an example. And often, people just start into talks, or they'll only say their first name. We're like, oh, okay, keep searching, keep searching. We'll find it. And apologies to anyone whose name we still got wrong regardless of our efforts. +But it's making this a paramount idea similar to people putting their pronouns in their name. Like, okay, this is a thing that we should get into the habit of because the easier we make this, the more common that we make this. And names absolutely matter, and getting the pronunciation right really matters. And especially if it can be an easier thing, that's really wonderful. I hope Twitter and other platforms just adopt this; just take this entirely and make it easy because it should be. +STEPH: That's what I was thinking; if Twitter had this, and then I was thinking if Slack had this, that would be a wonderful place to be able to just see someone's profile because we can see lots of other helpful context about them. So yeah, it's wonderful. +I want to hear more people how they pronounce their names. Because I'll always ask somebody, but it would just be really nice to then be able to revisit or check-in before you talk to that person, and then you can just say their name. That would be delightful. +CHRIS: I do feel like creating it for my name would be interesting. I actually had someone this week say my name and then say, "Oh, is that how you pronounce it?" And I stopped for a minute, and I was like, "Yes. I'm really intrigued what other options you were considering, though. I would like to spend a minute and just...because I always thought there was really only the one approach, but I would love to know. Let's just explore the space here," but yes. +STEPH: [laughs] You ask them, "What else you got? What other variations can I hear?" +CHRIS: [laughs] I would like three variations on my desk by tomorrow so that I can understand what I'm missing out on, frankly. There's a theme or an idea that I've seen bouncing around on Twitter now of people saying, "Yeah, I really just want to apply, get hired, work for one day, make this one change to a platform, and immediately put in my resignation." +And I could see this like, "All right, I'm just going to go. I'm going to get hired by Twitter. This is it. This is all I'm doing," which really trivializes the amount of effort that would go into it for a platform like Twitter. I can't even imagine what engineering looks like in Twitter and how all the pieces come together. I'm imagining some amount of microservices there, and that's just my guess. But yeah, that idea of just like, this is my drive-by feature. I show up; I work for a week, I quit. And there we go; now we have it. +STEPH: Well, we are consultants. Maybe we'll get hired for all these different companies, and that will be our drive-by feature. We'll add it to their boards and be like, "Don't you want this? Don't you need this?" And then they'll say, "Yes." [chuckles] +CHRIS: I am intrigued because I can't imagine this hasn't come up in conversations at Twitter. And so, what are the trade-off considerations that they're making, or what are the reasons not to do this? I don't have any good answers there. I'm just asking the question because, for an organization their size, someone must have had this idea. Yeah, I wonder. +STEPH: Yeah, there's; also, I'm sure malicious things that then you have to consider as to then how people...because, at the end of the day, it's just an audio file. So it could be anything that you want it to be. So it starts to get complicated when you think about ways that people could abuse a feature. +On that peppy note, what's going on in your world? +CHRIS: I had a fun bit of coding that I got to do recently, which, more and more, my days don't involve as much coding. And so when I have a little bit of time, especially for a nice, self-contained little piece of code that I get to write, that's enjoyable. And so I was writing a query. I wanted to add a new display of data in our admin panel. +And I was trying to write a query, and I got to build a nice query object in Ruby, which I always enjoy. That's not a real thing, just in case anyone's hearing that and thinking like, wait, what's a query object? Just a class that takes in a relation and returns relation but encapsulates more complex query logic. It's one of my favorite types of ways to extract logic from ActiveRecord models, that sort of thing. +So I was building this query object, and specifically, what I wanted to do here is I'm going to simplify down the data model. And I'm going to say that we have users and reservations in the system. This may sound familiar to you, Steph, as your go-to example [laughs] from the past. We have users, and we have reservations in the system. So a user has many reservations. And reservations can be they have a timestamp or maybe an enum column. But basically, they have the idea of potentially being upcoming, so in the future. +And so what I wanted to do was I wanted to find all users in the system who have less than two upcoming reservations. Now, the critical detail here is that zero is a number less than two. So I wanted to know any users that have no upcoming reservations or one upcoming reservation. Those were the two like, technically, that's it. But say it was even less than three, that's fine as well. But I need to account for zero. +And so I rolled up my sleeves, started writing the query, and ActiveRecord has some really nice features for this where I can merge different scopes that are on the reservation.upcoming is a scope that I have on that model that determines if a reservation is upcoming because maybe there's more complex logic there. So that's encapsulated over there. +But what I tried initially was users.leftjoinsreservations .groupbyusers.id havingcountofreservations. So that was what I got to. And thankfully, I wrote a bunch of tests for this, which is one of the wonderful things about extracting the query object. It was very easy to isolate this thing: write a bunch of tests that execute it with given data. +And interestingly, I found that it worked properly for users with a bunch of upcoming reservations. They were not returned by the query objects which they shouldn't, and users with one upcoming reservation. But users with zero upcoming reservations were being filtered out. And that was a surprise. +STEPH: Is it because the way you were joining and looking where the reservation had to match to a user, so you weren't getting where users didn't have a reservation? +CHRIS: It was related to that. So there's a subtlety to LEFT JOINS. So a JOIN is going to say like, users and reservations. But in that case, if there is a user without reservations, I know they're going to be filtered out of this query. So it's like, oh, I know what to do. LEFT JOINS, I got this. So LEFT JOINS says, "Give me all of the users and then in the query space that I'm building up here, join them to their reservations." So even a user with no reservations is now part of the recordset that is being considered for this query. +But when I added the filter of reservations.upcoming, I tried to merge that in using ActiveRecord's .merge syntax on a query or on a relation, as it were. That would not work because it turns out when you're using the LEFT JOINS...and as I'm saying this, I'm going to start saying, like, here's definitively what's true. I probably still don't entirely understand this, but trying to do the WHERE clause on the outer query did not work. And I had to move that filtering logic into the LEFT JOINS. +So the definition of the JOINS was now I had to actually handwrite that portion of the SQL and say, LEFT OUTER JOIN users on and then, you know, the users.id=reservations.userid and reservations. whatever the logic there for an upcoming reservation. So reservations.completed is null or reservations.date>date.current or whatever logic there. But I had to include that logic in the definition of the LEFT OUTER JOIN, which is not a thing that I think I've done before. So it was part of the definition of the JOIN rather than part of the larger query that we were operating on. +STEPH: Yeah, that's interesting. I don't think I would have caught that myself. And luckily, you had the test to then point out to you. +CHRIS: Yeah, definitely the tests made me feel much more confident when I eventually narrowed down and started to understand it and was able to make the change in the code. I was also quite happy with the way I was able to structure it. So, suddenly, I had to handwrite a little bit of SQL. And what was nice is many, many, many years ago, I recorded a wonderful course on Upcase with Joe Ferris, CTO of thoughtbot, on Advanced ActiveRecord Querying. And I'm still years later digesting everything that Joe said in that course. It's really an amazing piece of content. +But one of the things that I learned is Joe shows a bunch of examples throughout that course of ways that where you need to, you can drop down to raw SQL within an ActiveRecord relation. But you don't need to completely throw it out and write the entire query by hand. You can just say, in this case, all I had to handwrite was the JOINS logic for that LEFT JOINS. But the rest of it was still using normal ActiveRecord query logic. And the .having was scoped on its own, and all of those sort of things. So it was a nice balance of still staying mostly within the ActiveRecord query Builder syntax and then dropping down to a lower level where I needed it. +STEPH: I love that you mentioned that video because I have seen it, and it is so good. In fact, I now want to go back and rewatch it since you've mentioned it just because I remember I always learn something every time that I do watch it. On a side note, the way that you represented and described query objects was so lovely. +I know you, and I have talked about query objects before because we adore them. But I feel like you just gave a really good mini class and overview of like, this is what a query object is, and this is what it does. And this is why they're great because you can test them. +CHRIS: Cool. I'm going to be honest; I have no idea what I said. But I'm glad it was good. [laughs] +STEPH: It was. It was really good. If anyone has questions about query objects, that'll be a good reference. +CHRIS: Well, thank you so much for the kind words there. And for the ActiveRecord querying trail, really, I was just along for the ride on that one, to be clear. I did write a bunch of notes after the fact, which I've found incredibly useful because the videos are great. But having the notes to be able to reference...past me spent a lot of time trying really hard to understand what Joe had said so that I could write it down. And I'm very glad that I invested that time and effort so that I can revisit it more easily. +But yeah, that was just a fun little bit of code that I got to write and a new thing that I've learned in the world of SQL, which is one of those topics that every little investment of effort I find to be really valuable. The more comfortable I feel, the more that I can express in SQL. +It's one of those investments that I'm like, yep, glad I did that. Whereas there are other things like, yeah, I learned years ago how to do X. I've completely forgotten it. It's gone from my head. I'm never going to use it again, or the world has changed. But SQL is one of those topics where I appreciate all of the investment I've put in and always find it valuable to invest a bit more in my knowledge there. +STEPH: Yeah, absolutely same. Just to troll Regexs for a little bit, they're powerful, but they're the thing that I will never commit to learning. I refuse to do it. [laughs] I will always look it up when I need to. But Postgres or SQL, on the other hand, is always incredibly valuable. And I'm always happy to learn something new and invest in that area of my skills. +CHRIS: Yep, SQL and Postgres are great things. But let's see. In other news, actually, I had the pleasure of joining the Svelte Radio Podcast for an episode this week. They invited me on as a guest. And we got to chat about Svelte, and then I accidentally took the conversation in the direction of inertia as I always do. +And then I talked a little bit more about Sagewell, the company that I'm building, and all sorts of things in the world. But that was really fun, and I really enjoyed that. And I believe it will be live by the time this episode goes live. So we will certainly include a link to that episode in our show notes here. +STEPH: That's awesome. I haven't listened to the Svelte Podcast before. So I'm excited to hear your episode and all the good things that you said on it. I'm also just less familiar with them. Who runs the Svelte Podcast, and what's the name of the show? +CHRIS: The show is called Svelte Radio. It's hosted by Antony, Shawn, and Kevin, who are three Svelters from the community. Svelte is a really interesting group where the Svelte society is, as far as I can tell, a community organization that is seemingly well-supported by the core team and embraced as the natural center point of the community. And then Svelte Radio is an extension of that. +And it's a wonderful podcast. Each week, they talk about various things. So there are news episodes, and then they have guests on from time to time. Recently, having Rich Harris on to talk about the future of Svelte, Rich Harris being the creator of Svelte. +Interestingly, if you search for Svelte Radio, they are the second Google result because the first Google result is the tutorial docs on how to use Svelte with radio buttons. But then the second one is Svelte Radio, the podcast, [laughs], which is an interesting thing. Good on Svelte's documentation for having such strong SEO. +STEPH: I was just thinking there's something delightful about that where the first hit is for documentation that's a very helpful; here’s how you use this. That's kind of lovely. Well, that's really cool. I'm really looking forward to hearing more about Svelte and listening to you be on the show. +CHRIS: Yeah, they actually had some very kind things to say about The Bike Shed and, frankly, you as well and our co-hosting that we do here. So that was always nice to hear. +STEPH: That's very kind of them. And it never fails to amaze me how nice podcasters are. Everyone that I've met in this community that's a fellow podcaster they're just all such wonderful, nice, kind people, and I just appreciate the heck out of them. +CHRIS: Yeah, podcasts are great. The internet is doing its job; that’s my strong belief there. But let's see. In other news, I actually have more of a question here, sort of a question and an observation. My work has started to take a slightly different shape than it has historically. Often, I'm a developer working on a team, picking up something off the top of the Trello board or whatever we're using for project management, working on that thing, pushing it through to acceptance. But all of the work or the vast majority of the work is encapsulated in this one shared planning context. +But now, enough of my work is starting to spill out in different directions. Like right now, I'm pushing on hiring. That's a task that largely lives with me that doesn't live on the shared Trello board. Certainly, the rest of the team will be involved at some point. But for now, there's that that's really mine. And there are other pieces of work that are starting to take that shape. +So I recognize, or at least I decided that my productivity to-do lists system was failing me. So I'm on the search now for something new, but I'm intrigued. What do you use? Are you happy with what you have for to-do lists? How do you keep track of stuff in the world? +STEPH: Oh goodness. I'm now going to overanalyze everything that I do and how I keep track of the things that I do. [chuckles] So currently, I have two things that I used to track, and that is...okay, I'm going to expand. I have three to-do lists that I use to track. [laughs] +Todoist is where I add most things of where whatever I just think of, and I want to capture it Todoist is usually where it goes. Because then it's very easy for me to then go back to that list and prioritize or just simply delete stuff. If I haven't gotten to it in a while, I'm like, fine, let it go. Move on. +And then the other place I've started using just because it's been helpful in terms of linking to stuff is Basecamp. So we use Basecamp at thoughtbot, and we use it for a number of internal projects. But I have created my own project thanks to some advice from Mike Burns, a fellow thoughtboter, because he created his own and uses that to manage a lot of his to-dos and tasks that he has. And then that way, it's already one-stop shopping since you're in Basecamp a lot throughout the day or at least where you're going to visit some of the tasks that you need to work on. So that has been helpful just because it's very simple and easy to reference. +And then calendar, I just live by my calendar. So if something is of the utmost importance...I realize I'm going in this in terms of order of importance. If something is critical, it's on my calendar. That's where it goes. Because I know I have not only put it somewhere that I am guaranteed to see it, but I have carved out time for it too. That's my three-tier system. [laughs] +CHRIS: I like it. That sounds great, not overly complicated but plenty going on there. And it sounds like it's working for you, sounds like you're happy with that. +STEPH: It has worked really well. I'm still evaluating the Basecamp, but so far, it has been helpful. It does help me separate between fun to-do items which go in Todoist and maybe just some other work stuff. But if it's really work-focused, then it's going in Basecamp right now. So there's a little helpful separation there between what's going on in my life versus then things I need to prioritize for work. What are the things that you're currently using, and where are you feeling they're falling down or not being as helpful as you'd like them to be? +CHRIS: My current exploration, I'm starting to look for a new to-do list-type things. Specifically, I've been using Trello for a long time for probably a couple of years now. And that was a purposeful choice to move away from some of the more structured systems because I found they weren't providing as much value. I was constantly bouncing between different clients and moving into different systems. +And so much of the work was centrally organized there that the little bit of stuff that I had personally to keep track of was easy enough to manage within a Trello board. And then slowly, my Trello board morphed into like 10 Trello boards for different topics. So I have one that's like this is research. These are things that I want to look into. And so I can have sort of a structure and prioritization within that context in my world. +And then there's one for fitness and one for cooking. I'm trying to think which else...experiments, as I'm thinking about I want to try this new thing in the world. I have a board for that. So I have a bunch of those that allow me to keep things that aren't as actionable, that are more sort of explorations. But then they each have their own structure. And that I found to be really useful and I think I'll hold on to. +But my core to-do board has started failing me, has started being just not quite enough. And then, more so, I wanted a distinct thing for work for a professional context. So I was like, all right, let me go back to the drawing board and see what's out there. And I did a quick scan of Todoist and Things, respectively. And I've settled on Things for right now. It just matches a little bit more to my mental model. +Todoist really pushes on the idea of due dates or dates as a singular idea associated with most things. Almost everything should have a date. And I kind of philosophically disagree with that. Whereas Things has this interesting idea of there is the idea of a due date, but it's de-emphasized in their UI because not everything has a due date; most things don't. +But Things has a separate idea of a scheduled date or an intent date. Like yeah, I think I'll work on that on Wednesday. It's not due on Wednesday; that's just when I want to work on it. It can have a separate due date. Like, maybe it's due Friday. +STEPH: Is the name of the application that you're saying is it Things? Is that the name of it? +CHRIS: Yeah, it is. +STEPH: I haven't heard this one. You kept saying Things. I was like, wait, is he being vague? But I realized you're being specific. [laughs] +CHRIS: It's one of the few things that...yeah, one of the few things that I think is not great about Things. It's from a company Cultured Code, and the application is called Things. And that is all I will say on that topic. Different names maybe would have been better, but they seem to have carved out enough of an attention space. +Enough people know of it that if you search for Things and to-do list, it will very quickly pop up. But yeah, that's a pretty ambiguous name. They maybe could have done a different one there. But the design of the application is really nice. It's on my desktop. And now I have it on my phone as well, and they sync between them and all the stuff. +So there's never going to be a perfect system. I'm certain of that. I've at least talked myself out of trying to build my own because, man, have I fallen into that trap before. Oh goodness, so many times. +STEPH: I'm very proud of you. +CHRIS: Thank you. I'm trying. +STEPH: But yeah, it'll be interesting to see how it evolves. I continue to struggle with there are these things that come to mind, and I want to capture them during the day. But some of them are just stories I'm telling myself, which would probably be best captured in a journal tool. And then there are notes that I might want to keep on remote work and how people think about that. +And so I'm starting to think about Obsidian or a note-taking system for that. And then I've got this Trello board concoction. And now I've got a to-do...and suddenly I'm like, well, that's too many things. And so I'm trying to not overthink it. I'm trying to not underthink it. I'm trying to just find that perfect amount of thinking. That's what I'm aiming for. I'm not sure I'm going to hit it directly, [laughs], but that's what I'm aiming for. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: Some of the topics that you mentioned earlier did stand out to me when you're talking about recipes and working out some other topics. Those are things for me that I often just put in notes. So I liked the word that you used for stories that you're telling yourself or things that you're interested in. Is that something that...I don't put it in Todoist or put it somewhere because I don't really have an action item. It's more like, yeah, this recipe looks awesome and one day...so I'm going to stash it somewhere so I can find it. +I'm currently using Notion. I used Bear before. It is beautiful. I really liked Bear, but I needed a little bit more structure, and Notion gave me that structure. And so I will just dump it in Notion. And then it's very searchable, so I can always find whatever recipe or whatever thought that was as long as I try to add buzzwords to my own notes. Like, what would have Stephanie searched for looking for this? So I will try to include some of those words just so I can easily find it. +CHRIS: I love you're defining yourself as a Stephanie. For a random Stephanie walking through the woods, what search terms? How can I SEO arbitrage a Stephanie? +STEPH: What would she look for? +CHRIS: Who knows? +STEPH: That Stephanie, she's sneaky. You never know. +CHRIS: You never can tell. Obsidian is the one that I'm looking at now. But I'm currently using Apple Notes. And it's really nice to be able to search directly into a note very quickly. I have that both via Alfred and then on my phone. And I'm finding a lot of utility in that, particularly for notes, for things I want to talk to someone about. +But now there are seven different things, and how are they connected? And where is something? And to the question of where would a future Christopher look for this, let's make sure I put it in that place. But I don't know what that dude's going to be up to. He's a weird guy. He might look in a completely random place. So I'm trying to outsmart him, and oof, good luck, me. +STEPH: [laughs] I have heard of Obsidian, but I don't recall much about it. So I'd have to look into it. I do feel your pain around Todoist and where it really encourages you to set a date. Because there are often things where I'm like, I saw something I want to read. And I know there are tons of tools. +There are so many tools and videos and things that people could watch if they really want to invest in this workflow. But right now, I've told myself no, and so I use Todoist. And I see something I want to read, and so I just link to it. And I don't have a particular date that I want to read it. I'm like, this looks cool, and so then I add it to a reading list. But that also, I guess, could be something for notes. +More and more, I'm trying to shove things into notes, so it feels less like a task and more of a I'm curious, or I'm interested in things that have piqued my interest. Let me go back and look at that list to see if there's something I want to pull from today or I need inspiration. That's what my notes often are; they're typically inspiration for something that I have seen and really liked, or maybe it's a bug that I looked into, and I want to recall how that happened or what was the process. +But yeah, my notes are typically a source of inspiration. So I try to dump most things in there. I don't know if that's particularly helpful for your task, though, because it sounds like you're looking for a way to manage the things that you actually need to do versus just capturing all of your thoughts. +CHRIS: Honestly, part of it is having a good system for those like, oh, I'd like to read this sometime. Ideally, for me, that doesn't go into my whatever to-do list system. But if my brain doesn't trust that I'll ever read it or if I feel like I'm putting it into a black hole, then my brain is just like, hey, you should really read that thing. Are you thinking about that? You should think about that and just brings it up. +And so having a system externalized that I trust such that then the to-do list can be as focused as possible. It's a sort of an arms race back and forth battle type thing of like, I've definitely done the loop of like, all right, I want to capture everything. I want to have perfect, lossless, productivity system, and that is not possible. And so then I overcorrect back the other way. I'm like, whatever, nothing matters. I'll just let everything fall away. And then I'm like, well, then my brain tries to remind me of stuff or tries to remember more. +And there's a book, Getting Things Done, which is one of the more common things recommended in the productivity world. And that informs a bunch of my thinking around this, the idea of capturing everything that's in your head so that you can get it out of your head. And in the moment, be focused and in the moment and not having to try and remember. And so that's the ideal that I'm searching for. But it's difficult to build that and make that work. +STEPH: It seems the answer is there's no perfect system. It's always finding what works for you. And I feel like it's always going to change from hopefully not month to month because that would be tedious. But it may change year to year depending on how you're prioritizing things and the types of things that you need to remember or that you need to accumulate somewhere. So I feel like it's always this evolving, iterative process of changing where we're storing this. +But I feel like where you store the notes and inspiration, that's something that, ideally, you want to make sure that you can always continue to keep forward. So even if you do change systems, that's something that's usually on my mind. It's like, well, if I use this system to store all of my thoughts, what if I want to move to something else? How stuck am I to this particular platform? And can I still have ownership of the things that I have added here? +But overall, yeah, I'd be intrigued to see what other people think if they have a particular system that works for them, or they have suggestions. But overall, it seems to be whatever caters best to your personality and your workflow. That's why there are so many of these. There are so many thoughts, so many videos, so many styles. +CHRIS: Yeah, I think a critical part of what you just said that feels very true to me is this is something that will change over time as well. Life comes in seasons, and my work may look a certain way, or my life may look a certain way, and then next year, it may be wildly different. And so, finding something that is good enough for right now and then moving forward with that and being open to revisiting it. And yeah, that feels true. So I'm in an explore phase right now. I'll report back if I have any major breakthroughs. But yeah, we'll see how it goes. +STEPH: I will say I think the main tool that I have really leaned into, while some of the others will change over time, is my calendar. There are certain things I've let go. My inbox is always going to be messy. My to-do list is always going to be messy. But my calendar that is where things really go to make sure that they happen. And I will even add tasks there as well. +So I feel like the calendar will always stick with me because I can trust that as the one source of like, these are the things that have to happen. Everything else I can check for during that day or figure it out as I go. Or if something gets dropped or bounces to the next day, it's okay. +CHRIS: Yeah, the calendar is definitely a core truth in my world. Whatever the calendar says, that is true. And I'm actually a...I hope I'm not annoying to anyone. But I'm very pointed in saying, "This recurring meeting that we have if we keep just canceling it the day before every time, let's get this off our calendars. Let's make sure our calendars are telling the truth because I trust that thing very much." +And two apps that I'm using right now that I've found really useful in the calendar world are MeetingBar, which I've talked about before. But it's a little menu bar application that shows the next meeting that's upcoming. And then I can click on it and see the list of them and easily join any video call associated, just a nice thing to keep the next thing on my calendar very top of mind, super useful, really love that. That's just open source and easy to run with. +The other that I've been spending more and more time with lately is SavvyCal. SavvyCal is similar to Calendly. It's a tool for sharing a link to allow someone to schedule something on your calendar. And, man, it is an impressive piece of technology. I've been leaning into some of the fancier features of it of late. And it has an amazing amount of control, and I think a really well-designed sort of information architecture as well. It took me a little while to figure out how to do everything I wanted to do in it. +But I wanted to be able to define a calendar link thing that I could share with someone that really constraints in the way that I wanted. Like, oh, don't let them schedule tomorrow, and make sure there's this much buffer between meetings. And don't let this calendar link schedule too many things on my calendar because I need to control my day, and give me some focus blocks. And they're not actually on my calendar, but please recognize that. And it basically supports all of these different ways of thinking and does an incredible job with it. +As an aside, SavvyCal is created by Derrick Reimer, who is the co-host of The Art of Product Podcast, which is co other hosted by Ben Orenstein, former thoughtboter, creator of Upcase, and a handful of other things. So small world and all of that. But yeah, really fantastic piece of technology that I've been loving lately. +STEPH: That's really cool. I have not heard of SavvyCal. I've used Calendly and used that a fair amount. And that is so awesome where you can just send it to people, and they can pick time on a calendar and do all the features that you'd mentioned. So it's good to know that there's SavvyCal as well. +Well, pivoting just a bit, we have a listener question that I'm really excited to dig into. This question comes from fellow thoughtboter, Steve Polito. And Steve writes in that, "Hey, Bike Shed, I've got a question for you. I find it difficult to know if there's an existing method in a large class or a class that includes many concerns. How can I avoid writing redundant methods when working on a large project?" +And Steve provided a really nice just contrived example where he's defined a class user that inherits from ApplicationRecord. And then comments, "Lots of methods making it really hard to scan this giant class. And then there's a method called formatted name. So it takes first name, adds a space, and then adds the user's last name. And then there are a lot more methods in between. +And then, way down, there's another method called full name that does the exact same thing. Just to provide a nice example of how can you find a method that has existing logic that you want and avoid implementing essentially the same method and the same class?" +So as someone who has worked on some legacy systems this year, I feel that pain. I feel the pain of where you have a really giant class, and that class may also include other modules. So then you have your range of all the methods that you may be looking through gets really widened. And you are looking for particular logic that you feel like may exist in the system, but you really just don't know. +So I don't know if I have a concrete method for how you can find duplicate logic and avoid writing that other method. But some of the things that I do is I will initially go to the test. So if there's some logic that I'm looking for and I think it's in this class or I have a suspicion, I will first look to see what has test coverage. And I find that is just easier to skim where I can find, and I'll use grep, and search and just look for anything. +In this particular case, let's use first name as our example. So I'm looking for anything that's going to collaborate with first name. Some of the other things that I'll do is I'll try to think of a business case where that logic is used. So, where are we displaying the user's full name? And if I can go to that page and see what's already in use, that may give me a hint to do we already have this logic? Is there something there that I should reuse, or is it something new that I'm implementing? +And then if I really want to get fancy about it, for some reason that I really want to see all the methods that are listed, but I'm trying to get rid of some of the noise in the file, then I could programmatically scan through all the available methods by doing something like class.instance methods and passing in false. So we don't include the methods that are from superclasses, which can be very helpful. So that way, you're just seeing what scoped to that class. +But then, let's say if you do have a class that is inheriting from other modules, then you may want to include those methods in your search. So to get fancier, you could look at that class' ancestor chain and then collect the classes or models that are custom to your application, and then look at those instance methods. And then you could sort them alphabetically. +But you're still really relying on is there a method name that looks very similar to what I would call this method? So I don't know that that's a really efficient way. But if I just feel like there's probably already something in this space and I'm just looking for a clue or some name that's going to hint that something already exists, that's one way I could do it. +To throw another wrench in there, I just remembered there are also private methods, and private methods don't get returned from instance methods. I think it's private instance methods is a method that you'd have to call to then include those in your search results as well. So outside of some deeper static analysis, this seems like a hard problem. This seems like something that would be challenging to solve. +And then I guess the other one is I ask a friend. So I will often lean on if there's someone else at the team that's been there longer than me is I will just ask in Slack and say, "Hey, I want to do a thing. I'm worried this already exists, or I think it already exists. Does anybody have any clues or ideas as to where this might live?" +I know I just ran through a giant list of ideas there. But I'm really curious, what are your thoughts? If you have a messier codebase and you're worried that you are reimplementing logic that already exists, but you're trying to make sure you don't duplicate that logic, how do you avoid that? +CHRIS: Well, the first thing I want to say is that I find it really interesting that I think you and I came at this from different directions. My answer, which I'll come to in a minute, is more of the I'm not actually sure that this is that easy to avoid, and maybe that's not the biggest problem in the world. And then I have some thoughts downstream from that. +But the list that you just gave was fantastic. That was a tour de force of how to understand and explore a codebase and try and answer this very hard question of like, does this logic already exist somewhere else? So I basically just agree with everything you said. And again, I'm deeply impressed with the range of options that you offer there for trying to figure this out. +That said, sometimes codebases just get really large. And this is going to happen. I think the specific mention of concerns as sort of a way that this problem can manifest feels true. Having the user object and being like, oh man, our user object is getting pretty big. Let's pull something out into a concern as just a way to clean it up. That actually adds a layer of indirection that makes it harder to understand the totality of what's going on in this thing. +And so personally, I tend to avoid concerns for that reason or at least at the model layer, especially where it's just a we got 1,000 methods here. Let's pull 200 of them into a file and maybe group them somewhat logically. That tends to not solve the problem in my mind. I found that it just basically adds a layer of indirection without much additional value. +I will say in this particular case, the thing that we're talking about presenting the full name or the formatted name feels almost like a presentational concern. So I might ask myself, is there a presenter object, something that wraps around a user and encapsulates this? And then we as a team know that that sort of presentational or formatting logic lives in the presentation format or layer. Maybe I'm not entirely convinced of that as an answer. But it's just sort of where can we find organizational lines to draw within our codebases? +I talked about query objects earlier. That's one case of this is behavior that I'll often see in classes as, say, a scope or something like that that I will extract out into a query object because it allows me to encapsulate it and break it out a little bit more but still have most of the nice pieces that I would want. +So are there different organizational patterns that are useful? I think it's very easy to start drawing arbitrary lines within our codebases and say, "These are services." And it's like, what does that mean? That doesn't mean anything. App Services, that's not a thing, so maybe don't do that. But maybe there are formatters, queries, commands, those feel like...or presenters, queries, commands. Maybe those are organizational structures that can be useful. +But switching to the other side of it, the first thing that came to mind is like, this is going to happen. As a codebase grows, this is absolutely going to happen. And so I would ask rather than how can I, as the developer, avoid doing this in the first place...which I think is a good question to ask. And again, everything you listed, Steph, is great. And I think a wonderful list of ways that you can actually try to avoid this. +But let's assume it is going to happen. So then, what do we do downstream from that? One answer that comes to mind is code review. Code review is not perfect. But this is the sort of thing that often in code review I will be like, oh, I actually wrote a method that's similar to this. Can you take a look at that and see can we use only one of these or something like that? So I've definitely seen code review be a line of defense on this front. +But again, stuff is still going to sneak through. And someday, you'll find it down the road. And that's the point in time that I think is most interesting. When you find this, can you fix it easily? Do you have both process-wise and infrastructure-wise the ability to do a very small PR that just removes the duplicate method, removes the usage of it, and consolidates on the one? +It's like, oh, I found it. Here's a 10-line PR that just removes that method, changes the usage. And now we're good. And that can go through code review and CI very quickly. And we have a team culture that allows us to make those tiny changes on the regular to get them out to production as quick as possible so that we know that this is a good code change, all of that. +I found there are teams that I've worked on where that process is much slower. And therefore, I will try and roll a change like that up into a bigger PR because I know that's the only way that it's really going to get through. Versus I've been on teams that have very high throughput is probably the best way to describe it. And on those teams, I find that the codebase tends to be in a healthier shape because it just naturally falls out of having a system that allows us to make changes rapidly with high trust, get them out into the world, et cetera. +STEPH: This is that bug or inconsistency that's going to show up where on one page you have the user's full name. And then on another page, you have the user's full name, but maybe the last name is not capitalized, or there's just something that's slightly different. And then that's when you realize that you have two implementations of essentially the same logic that have differed just enough. +I like how you pointed out that this is one of those things that as a codebase grows, it's probably going to happen, and that's fine. It's one of those if you do have duplicate logic, over time, based on your team's processes, you'll be able to then identify when it does happen, and then look for those preventative patterns for then how you organize your code. +How quickly can you make that change? Can you just issue a PR that then removes one of them? But then look for ways to say, how are we going to help our future selves recognize that if we're looking for a user's full name, where's a good place to look for that? And then what's a good domain space or naming that we can give to then help future searchers be able to find it? +I also really like your code review example because it does feel like one of those things that, yes, we want to catch it if we can, and we can leverage the team. But then also, it's not the end of the world if some of these methods do get duplicated. +There's one other thing that came to mind that it's not really going to help prevent duplicate methods, but it will help you identify unused code. So it's the Unused tooling that you can run on your codebase. And that's something that would be wonderful to run on your codebase every so often. +So that way, if someone has added...let's say there was a method that was full name but is not in use. It didn't have test coverage; that's why you didn't find it initially. And so you've introduced your own formatted name. And then, if you run unused at some point, then you'll hopefully catch some of those duplicate methods as long as they're not both in use. +CHRIS: I think one more thing that I didn't quite say in my earlier portion about this. But in order to do that, to use Unuse or to have these sort of small pull requests that are going through, you have to have test coverage that is sufficient that you are confident you're not going to break the app. Because the day that you do like, oh, there's a typo here; let me fix it real quick. Or there's this method I'm pretty sure it's not used; let me rip it out. +And then you deploy to production, and suddenly the error system is blowing up because, in fact, it was used but sneakily in a way that you didn't think of, and your test coverage didn't catch that. Then you don't have trust in the system, and everything slows down as a result of that. And so I would argue for fixing the root problem there, which is the lack of test coverage rather than the symptom, which is, oh, I made this change, it broke something. Therefore, I won't make small changes anymore. +STEPH: Definitely. Yeah, that's a great point. +CHRIS: So yeah, I don't have any answer. [laughs] My answers are like, I don't know, it's going to happen, but there's a lot of stuff organizationally that we can do. And granted, you gave a wonderful list of ways to actually avoid this. So I think the combination of our answers really it's a nice spectrum of thoughts on this topic. +STEPH: I agree. I feel like we covered a very nice range all the way from trying to identify and then how to prevent it or how to help future people be able to identify where that logic lives and find it more easily. Also, at the end of the day, I like the how big of a problem is this? And it is one of those sure; we want to avoid it. +But I liked how you captured that at the beginning where you're like, it's okay. Like, this is going to happen but then have the processes around it to then avoid or be able to undo some of that duplicate work. But otherwise, if it happens, don't sweat it; just look for ways to then prevent it from happening in the future. +On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeee!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph talks about winter storms and thoughts on name pronunciation features. Chris talks about writing a query to add a new display of data in an admin panel and making a guest appearance on the Svelte Radio Podcast.

+ +

Finally, Chris decided that his productivity to-do list system was failing him. So he's on the search now for something new. He asks Steph what she uses and if she's happy with it. How do you, dear Listener, keep track of all your stuff in the world?

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. We have Winter Storm Izzy headed our way. It's arriving in South Carolina early tomorrow morning. So that's kind of exciting just because it's South Carolina. We rarely see snow. In fact, I looked it up because I was curious because I've seen it every now and then. But I looked up the greatest cumulative snowfall in 1 season, and it was 19 inches in the winter of 1971. I was trying to add an old-timey voice there. I don't know if I was successful.

+ +

CHRIS: Does 1971 deserve a full old-timey voice?

+ +

STEPH: Apparently.

+ +

CHRIS: I feel like people from 1971 would be like, "We were just people in the 70s." Like, what do you...

+ +

STEPH: [laughs]

+ +

CHRIS: Wait. Nineteen inches, is that what you said?

+ +

STEPH: 19 inches. That was total for the season.

+ +

CHRIS: Yeah, we can bang that out in an afternoon up here in the North. So yeah, okay. You were here for the terrible, terrible winter, right?

+ +

STEPH: Oh, Snowmageddon? Yes.

+ +

CHRIS: Yeah, that was something, oof.

+ +

STEPH: I don't remember how many inches. Was it like 100 inches in a month or something wild like that? I've forgotten the facts.

+ +

CHRIS: I, too forget the facts. I remember the anecdotal piece of data, the anecdata as it were where we shoveled our driveway, and then another storm came, we shoveled our driveway. And then finally, I was living in an apartment, and it was time to shovel the driveway again. But the pile of snow on the lawn was too big. So we had to shovel the pile of snow further up the lawn to make room for the snow that we were shoveling out of the driveway.

+ +

But I also remember that being a really nice bonding moment, and I met more of the people living in the...it was a house that had been converted into six apartments. So I actually met some of the people from the house for the first time. And then we hung out a little bit more in the day. So I actually have weirdly fond memories of that time. But to be clear, that was too much snow. I will officially go on record saying too much snow. No, thank you again.

+ +

STEPH: It was a lot of snow. I think it broke Boston for a while. I remember I don't think I went to...I worked remotely for two weeks because they were just like, "Yeah, don't even try to come into the office. Don't worry about it." So it felt like my first dabbling into understanding quarantine [laughs] except at least with less complicated reasons, just with lots of snow. We also went snowboarding in Charlestown, where we were living. And that was fun because there are some really great hills, and there was so much snow that that was delightful.

+ +

But I'm not expecting Snowmageddon in South Carolina, although people may act like it and rush out and get their milk and bread. But hopefully, we'll get a couple of inches because that'll be lovely. I don't know that Utah has ever seen the snow. So this will be fun.

+ +

CHRIS: Oh, that'll definitely be fun. I imagine you've got like even if you do get some amount of accumulation, a day later the sun will just be like, "I'm back. I got this," and clear it up, and you won't have any lingering. The year of Snowmageddon, if I remember correctly, the final pile of snow left in July, the shared one that the city had collected. So you'll probably do better than that turnaround time. [laughs]

+ +

STEPH: Yeah, it's perfect. It's very ephemeral. It snows, it's beautiful. It's there for a couple of hours, and then poof, it's gone. And then you're back to probably 70-degree weather typically what’s here, [laughs] which I have no complaints. There's a reason that I like living here.

+ +

But in some other news, I have something that I'm really excited about that I want to share. So there's something that you and I work really hard to do correctly, and it's pronouncing someone's name. So whenever there is either a guest on the show, or we are referencing someone, we will often pause, and then we will look for videos. We'll look for an audio clip, something where that person says their name. And then we will do our best to then say it correctly. Although I probably put a Southern twang on a lot of people's names, so sorry about that. But that's really important to say someone's name correctly.

+ +

And one of thoughtbot's projects is called Hub, which is something that we use internally for all of our project staffing and then also for profiles and team information; there’s a new feature that Matheus Richard, another thoughtboter, implemented that I am just so excited about. And now that I have it, I just think I don't know how I lived without this. And I want it everywhere.

+ +

So Matheus has added the feature where you can upload an audio file with your name pronunciation. So you can go to someone's profile, and you can click on the little audio button and hear them pronounce their name. And then a number of people have taken it a bit further where they will provide, say, the American or English pronunciation of their name. And then they will provide their specific pronunciation; maybe it's Greek, maybe it's Spanish, and it's just phenomenal. And I love it so much. And I can't wait for just more platforms to have something like this. So really big shout out to Matheus Richard for that phenomenal feature.

+ +

CHRIS: Oh, that is awesome. Yeah, we definitely do pause pretty regularly to go scan through YouTube or try and find an example. And often, people just start into talks, or they'll only say their first name. We're like, oh, okay, keep searching, keep searching. We'll find it. And apologies to anyone whose name we still got wrong regardless of our efforts.

+ +

But it's making this a paramount idea similar to people putting their pronouns in their name. Like, okay, this is a thing that we should get into the habit of because the easier we make this, the more common that we make this. And names absolutely matter, and getting the pronunciation right really matters. And especially if it can be an easier thing, that's really wonderful. I hope Twitter and other platforms just adopt this; just take this entirely and make it easy because it should be.

+ +

STEPH: That's what I was thinking; if Twitter had this, and then I was thinking if Slack had this, that would be a wonderful place to be able to just see someone's profile because we can see lots of other helpful context about them. So yeah, it's wonderful.

+ +

I want to hear more people how they pronounce their names. Because I'll always ask somebody, but it would just be really nice to then be able to revisit or check-in before you talk to that person, and then you can just say their name. That would be delightful.

+ +

CHRIS: I do feel like creating it for my name would be interesting. I actually had someone this week say my name and then say, "Oh, is that how you pronounce it?" And I stopped for a minute, and I was like, "Yes. I'm really intrigued what other options you were considering, though. I would like to spend a minute and just...because I always thought there was really only the one approach, but I would love to know. Let's just explore the space here," but yes.

+ +

STEPH: [laughs] You ask them, "What else you got? What other variations can I hear?"

+ +

CHRIS: [laughs] I would like three variations on my desk by tomorrow so that I can understand what I'm missing out on, frankly. There's a theme or an idea that I've seen bouncing around on Twitter now of people saying, "Yeah, I really just want to apply, get hired, work for one day, make this one change to a platform, and immediately put in my resignation."

+ +

And I could see this like, "All right, I'm just going to go. I'm going to get hired by Twitter. This is it. This is all I'm doing," which really trivializes the amount of effort that would go into it for a platform like Twitter. I can't even imagine what engineering looks like in Twitter and how all the pieces come together. I'm imagining some amount of microservices there, and that's just my guess. But yeah, that idea of just like, this is my drive-by feature. I show up; I work for a week, I quit. And there we go; now we have it.

+ +

STEPH: Well, we are consultants. Maybe we'll get hired for all these different companies, and that will be our drive-by feature. We'll add it to their boards and be like, "Don't you want this? Don't you need this?" And then they'll say, "Yes." [chuckles]

+ +

CHRIS: I am intrigued because I can't imagine this hasn't come up in conversations at Twitter. And so, what are the trade-off considerations that they're making, or what are the reasons not to do this? I don't have any good answers there. I'm just asking the question because, for an organization their size, someone must have had this idea. Yeah, I wonder.

+ +

STEPH: Yeah, there's; also, I'm sure malicious things that then you have to consider as to then how people...because, at the end of the day, it's just an audio file. So it could be anything that you want it to be. So it starts to get complicated when you think about ways that people could abuse a feature.

+ +

On that peppy note, what's going on in your world?

+ +

CHRIS: I had a fun bit of coding that I got to do recently, which, more and more, my days don't involve as much coding. And so when I have a little bit of time, especially for a nice, self-contained little piece of code that I get to write, that's enjoyable. And so I was writing a query. I wanted to add a new display of data in our admin panel.

+ +

And I was trying to write a query, and I got to build a nice query object in Ruby, which I always enjoy. That's not a real thing, just in case anyone's hearing that and thinking like, wait, what's a query object? Just a class that takes in a relation and returns relation but encapsulates more complex query logic. It's one of my favorite types of ways to extract logic from ActiveRecord models, that sort of thing.

+ +

So I was building this query object, and specifically, what I wanted to do here is I'm going to simplify down the data model. And I'm going to say that we have users and reservations in the system. This may sound familiar to you, Steph, as your go-to example [laughs] from the past. We have users, and we have reservations in the system. So a user has many reservations. And reservations can be they have a timestamp or maybe an enum column. But basically, they have the idea of potentially being upcoming, so in the future.

+ +

And so what I wanted to do was I wanted to find all users in the system who have less than two upcoming reservations. Now, the critical detail here is that zero is a number less than two. So I wanted to know any users that have no upcoming reservations or one upcoming reservation. Those were the two like, technically, that's it. But say it was even less than three, that's fine as well. But I need to account for zero.

+ +

And so I rolled up my sleeves, started writing the query, and ActiveRecord has some really nice features for this where I can merge different scopes that are on the reservation.upcoming is a scope that I have on that model that determines if a reservation is upcoming because maybe there's more complex logic there. So that's encapsulated over there.

+ +

But what I tried initially was users.leftjoinsreservations .groupbyusers.id havingcountofreservations. So that was what I got to. And thankfully, I wrote a bunch of tests for this, which is one of the wonderful things about extracting the query object. It was very easy to isolate this thing: write a bunch of tests that execute it with given data.

+ +

And interestingly, I found that it worked properly for users with a bunch of upcoming reservations. They were not returned by the query objects which they shouldn't, and users with one upcoming reservation. But users with zero upcoming reservations were being filtered out. And that was a surprise.

+ +

STEPH: Is it because the way you were joining and looking where the reservation had to match to a user, so you weren't getting where users didn't have a reservation?

+ +

CHRIS: It was related to that. So there's a subtlety to LEFT JOINS. So a JOIN is going to say like, users and reservations. But in that case, if there is a user without reservations, I know they're going to be filtered out of this query. So it's like, oh, I know what to do. LEFT JOINS, I got this. So LEFT JOINS says, "Give me all of the users and then in the query space that I'm building up here, join them to their reservations." So even a user with no reservations is now part of the recordset that is being considered for this query.

+ +

But when I added the filter of reservations.upcoming, I tried to merge that in using ActiveRecord's .merge syntax on a query or on a relation, as it were. That would not work because it turns out when you're using the LEFT JOINS...and as I'm saying this, I'm going to start saying, like, here's definitively what's true. I probably still don't entirely understand this, but trying to do the WHERE clause on the outer query did not work. And I had to move that filtering logic into the LEFT JOINS.

+ +

So the definition of the JOINS was now I had to actually handwrite that portion of the SQL and say, LEFT OUTER JOIN users on and then, you know, the users.id=reservations.userid and reservations. whatever the logic there for an upcoming reservation. So reservations.completed is null or reservations.date>date.current or whatever logic there. But I had to include that logic in the definition of the LEFT OUTER JOIN, which is not a thing that I think I've done before. So it was part of the definition of the JOIN rather than part of the larger query that we were operating on.

+ +

STEPH: Yeah, that's interesting. I don't think I would have caught that myself. And luckily, you had the test to then point out to you.

+ +

CHRIS: Yeah, definitely the tests made me feel much more confident when I eventually narrowed down and started to understand it and was able to make the change in the code. I was also quite happy with the way I was able to structure it. So, suddenly, I had to handwrite a little bit of SQL. And what was nice is many, many, many years ago, I recorded a wonderful course on Upcase with Joe Ferris, CTO of thoughtbot, on Advanced ActiveRecord Querying. And I'm still years later digesting everything that Joe said in that course. It's really an amazing piece of content.

+ +

But one of the things that I learned is Joe shows a bunch of examples throughout that course of ways that where you need to, you can drop down to raw SQL within an ActiveRecord relation. But you don't need to completely throw it out and write the entire query by hand. You can just say, in this case, all I had to handwrite was the JOINS logic for that LEFT JOINS. But the rest of it was still using normal ActiveRecord query logic. And the .having was scoped on its own, and all of those sort of things. So it was a nice balance of still staying mostly within the ActiveRecord query Builder syntax and then dropping down to a lower level where I needed it.

+ +

STEPH: I love that you mentioned that video because I have seen it, and it is so good. In fact, I now want to go back and rewatch it since you've mentioned it just because I remember I always learn something every time that I do watch it. On a side note, the way that you represented and described query objects was so lovely.

+ +

I know you, and I have talked about query objects before because we adore them. But I feel like you just gave a really good mini class and overview of like, this is what a query object is, and this is what it does. And this is why they're great because you can test them.

+ +

CHRIS: Cool. I'm going to be honest; I have no idea what I said. But I'm glad it was good. [laughs]

+ +

STEPH: It was. It was really good. If anyone has questions about query objects, that'll be a good reference.

+ +

CHRIS: Well, thank you so much for the kind words there. And for the ActiveRecord querying trail, really, I was just along for the ride on that one, to be clear. I did write a bunch of notes after the fact, which I've found incredibly useful because the videos are great. But having the notes to be able to reference...past me spent a lot of time trying really hard to understand what Joe had said so that I could write it down. And I'm very glad that I invested that time and effort so that I can revisit it more easily.

+ +

But yeah, that was just a fun little bit of code that I got to write and a new thing that I've learned in the world of SQL, which is one of those topics that every little investment of effort I find to be really valuable. The more comfortable I feel, the more that I can express in SQL.

+ +

It's one of those investments that I'm like, yep, glad I did that. Whereas there are other things like, yeah, I learned years ago how to do X. I've completely forgotten it. It's gone from my head. I'm never going to use it again, or the world has changed. But SQL is one of those topics where I appreciate all of the investment I've put in and always find it valuable to invest a bit more in my knowledge there.

+ +

STEPH: Yeah, absolutely same. Just to troll Regexs for a little bit, they're powerful, but they're the thing that I will never commit to learning. I refuse to do it. [laughs] I will always look it up when I need to. But Postgres or SQL, on the other hand, is always incredibly valuable. And I'm always happy to learn something new and invest in that area of my skills.

+ +

CHRIS: Yep, SQL and Postgres are great things. But let's see. In other news, actually, I had the pleasure of joining the Svelte Radio Podcast for an episode this week. They invited me on as a guest. And we got to chat about Svelte, and then I accidentally took the conversation in the direction of inertia as I always do.

+ +

And then I talked a little bit more about Sagewell, the company that I'm building, and all sorts of things in the world. But that was really fun, and I really enjoyed that. And I believe it will be live by the time this episode goes live. So we will certainly include a link to that episode in our show notes here.

+ +

STEPH: That's awesome. I haven't listened to the Svelte Podcast before. So I'm excited to hear your episode and all the good things that you said on it. I'm also just less familiar with them. Who runs the Svelte Podcast, and what's the name of the show?

+ +

CHRIS: The show is called Svelte Radio. It's hosted by Antony, Shawn, and Kevin, who are three Svelters from the community. Svelte is a really interesting group where the Svelte society is, as far as I can tell, a community organization that is seemingly well-supported by the core team and embraced as the natural center point of the community. And then Svelte Radio is an extension of that.

+ +

And it's a wonderful podcast. Each week, they talk about various things. So there are news episodes, and then they have guests on from time to time. Recently, having Rich Harris on to talk about the future of Svelte, Rich Harris being the creator of Svelte.

+ +

Interestingly, if you search for Svelte Radio, they are the second Google result because the first Google result is the tutorial docs on how to use Svelte with radio buttons. But then the second one is Svelte Radio, the podcast, [laughs], which is an interesting thing. Good on Svelte's documentation for having such strong SEO.

+ +

STEPH: I was just thinking there's something delightful about that where the first hit is for documentation that's a very helpful; here’s how you use this. That's kind of lovely. Well, that's really cool. I'm really looking forward to hearing more about Svelte and listening to you be on the show.

+ +

CHRIS: Yeah, they actually had some very kind things to say about The Bike Shed and, frankly, you as well and our co-hosting that we do here. So that was always nice to hear.

+ +

STEPH: That's very kind of them. And it never fails to amaze me how nice podcasters are. Everyone that I've met in this community that's a fellow podcaster they're just all such wonderful, nice, kind people, and I just appreciate the heck out of them.

+ +

CHRIS: Yeah, podcasts are great. The internet is doing its job; that’s my strong belief there. But let's see. In other news, I actually have more of a question here, sort of a question and an observation. My work has started to take a slightly different shape than it has historically. Often, I'm a developer working on a team, picking up something off the top of the Trello board or whatever we're using for project management, working on that thing, pushing it through to acceptance. But all of the work or the vast majority of the work is encapsulated in this one shared planning context.

+ +

But now, enough of my work is starting to spill out in different directions. Like right now, I'm pushing on hiring. That's a task that largely lives with me that doesn't live on the shared Trello board. Certainly, the rest of the team will be involved at some point. But for now, there's that that's really mine. And there are other pieces of work that are starting to take that shape.

+ +

So I recognize, or at least I decided that my productivity to-do lists system was failing me. So I'm on the search now for something new, but I'm intrigued. What do you use? Are you happy with what you have for to-do lists? How do you keep track of stuff in the world?

+ +

STEPH: Oh goodness. I'm now going to overanalyze everything that I do and how I keep track of the things that I do. [chuckles] So currently, I have two things that I used to track, and that is...okay, I'm going to expand. I have three to-do lists that I use to track. [laughs]

+ +

Todoist is where I add most things of where whatever I just think of, and I want to capture it Todoist is usually where it goes. Because then it's very easy for me to then go back to that list and prioritize or just simply delete stuff. If I haven't gotten to it in a while, I'm like, fine, let it go. Move on.

+ +

And then the other place I've started using just because it's been helpful in terms of linking to stuff is Basecamp. So we use Basecamp at thoughtbot, and we use it for a number of internal projects. But I have created my own project thanks to some advice from Mike Burns, a fellow thoughtboter, because he created his own and uses that to manage a lot of his to-dos and tasks that he has. And then that way, it's already one-stop shopping since you're in Basecamp a lot throughout the day or at least where you're going to visit some of the tasks that you need to work on. So that has been helpful just because it's very simple and easy to reference.

+ +

And then calendar, I just live by my calendar. So if something is of the utmost importance...I realize I'm going in this in terms of order of importance. If something is critical, it's on my calendar. That's where it goes. Because I know I have not only put it somewhere that I am guaranteed to see it, but I have carved out time for it too. That's my three-tier system. [laughs]

+ +

CHRIS: I like it. That sounds great, not overly complicated but plenty going on there. And it sounds like it's working for you, sounds like you're happy with that.

+ +

STEPH: It has worked really well. I'm still evaluating the Basecamp, but so far, it has been helpful. It does help me separate between fun to-do items which go in Todoist and maybe just some other work stuff. But if it's really work-focused, then it's going in Basecamp right now. So there's a little helpful separation there between what's going on in my life versus then things I need to prioritize for work. What are the things that you're currently using, and where are you feeling they're falling down or not being as helpful as you'd like them to be?

+ +

CHRIS: My current exploration, I'm starting to look for a new to-do list-type things. Specifically, I've been using Trello for a long time for probably a couple of years now. And that was a purposeful choice to move away from some of the more structured systems because I found they weren't providing as much value. I was constantly bouncing between different clients and moving into different systems.

+ +

And so much of the work was centrally organized there that the little bit of stuff that I had personally to keep track of was easy enough to manage within a Trello board. And then slowly, my Trello board morphed into like 10 Trello boards for different topics. So I have one that's like this is research. These are things that I want to look into. And so I can have sort of a structure and prioritization within that context in my world.

+ +

And then there's one for fitness and one for cooking. I'm trying to think which else...experiments, as I'm thinking about I want to try this new thing in the world. I have a board for that. So I have a bunch of those that allow me to keep things that aren't as actionable, that are more sort of explorations. But then they each have their own structure. And that I found to be really useful and I think I'll hold on to.

+ +

But my core to-do board has started failing me, has started being just not quite enough. And then, more so, I wanted a distinct thing for work for a professional context. So I was like, all right, let me go back to the drawing board and see what's out there. And I did a quick scan of Todoist and Things, respectively. And I've settled on Things for right now. It just matches a little bit more to my mental model.

+ +

Todoist really pushes on the idea of due dates or dates as a singular idea associated with most things. Almost everything should have a date. And I kind of philosophically disagree with that. Whereas Things has this interesting idea of there is the idea of a due date, but it's de-emphasized in their UI because not everything has a due date; most things don't.

+ +

But Things has a separate idea of a scheduled date or an intent date. Like yeah, I think I'll work on that on Wednesday. It's not due on Wednesday; that's just when I want to work on it. It can have a separate due date. Like, maybe it's due Friday.

+ +

STEPH: Is the name of the application that you're saying is it Things? Is that the name of it?

+ +

CHRIS: Yeah, it is.

+ +

STEPH: I haven't heard this one. You kept saying Things. I was like, wait, is he being vague? But I realized you're being specific. [laughs]

+ +

CHRIS: It's one of the few things that...yeah, one of the few things that I think is not great about Things. It's from a company Cultured Code, and the application is called Things. And that is all I will say on that topic. Different names maybe would have been better, but they seem to have carved out enough of an attention space.

+ +

Enough people know of it that if you search for Things and to-do list, it will very quickly pop up. But yeah, that's a pretty ambiguous name. They maybe could have done a different one there. But the design of the application is really nice. It's on my desktop. And now I have it on my phone as well, and they sync between them and all the stuff.

+ +

So there's never going to be a perfect system. I'm certain of that. I've at least talked myself out of trying to build my own because, man, have I fallen into that trap before. Oh goodness, so many times.

+ +

STEPH: I'm very proud of you.

+ +

CHRIS: Thank you. I'm trying.

+ +

STEPH: But yeah, it'll be interesting to see how it evolves. I continue to struggle with there are these things that come to mind, and I want to capture them during the day. But some of them are just stories I'm telling myself, which would probably be best captured in a journal tool. And then there are notes that I might want to keep on remote work and how people think about that.

+ +

And so I'm starting to think about Obsidian or a note-taking system for that. And then I've got this Trello board concoction. And now I've got a to-do...and suddenly I'm like, well, that's too many things. And so I'm trying to not overthink it. I'm trying to not underthink it. I'm trying to just find that perfect amount of thinking. That's what I'm aiming for. I'm not sure I'm going to hit it directly, [laughs], but that's what I'm aiming for.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Some of the topics that you mentioned earlier did stand out to me when you're talking about recipes and working out some other topics. Those are things for me that I often just put in notes. So I liked the word that you used for stories that you're telling yourself or things that you're interested in. Is that something that...I don't put it in Todoist or put it somewhere because I don't really have an action item. It's more like, yeah, this recipe looks awesome and one day...so I'm going to stash it somewhere so I can find it.

+ +

I'm currently using Notion. I used Bear before. It is beautiful. I really liked Bear, but I needed a little bit more structure, and Notion gave me that structure. And so I will just dump it in Notion. And then it's very searchable, so I can always find whatever recipe or whatever thought that was as long as I try to add buzzwords to my own notes. Like, what would have Stephanie searched for looking for this? So I will try to include some of those words just so I can easily find it.

+ +

CHRIS: I love you're defining yourself as a Stephanie. For a random Stephanie walking through the woods, what search terms? How can I SEO arbitrage a Stephanie?

+ +

STEPH: What would she look for?

+ +

CHRIS: Who knows?

+ +

STEPH: That Stephanie, she's sneaky. You never know.

+ +

CHRIS: You never can tell. Obsidian is the one that I'm looking at now. But I'm currently using Apple Notes. And it's really nice to be able to search directly into a note very quickly. I have that both via Alfred and then on my phone. And I'm finding a lot of utility in that, particularly for notes, for things I want to talk to someone about.

+ +

But now there are seven different things, and how are they connected? And where is something? And to the question of where would a future Christopher look for this, let's make sure I put it in that place. But I don't know what that dude's going to be up to. He's a weird guy. He might look in a completely random place. So I'm trying to outsmart him, and oof, good luck, me.

+ +

STEPH: [laughs] I have heard of Obsidian, but I don't recall much about it. So I'd have to look into it. I do feel your pain around Todoist and where it really encourages you to set a date. Because there are often things where I'm like, I saw something I want to read. And I know there are tons of tools.

+ +

There are so many tools and videos and things that people could watch if they really want to invest in this workflow. But right now, I've told myself no, and so I use Todoist. And I see something I want to read, and so I just link to it. And I don't have a particular date that I want to read it. I'm like, this looks cool, and so then I add it to a reading list. But that also, I guess, could be something for notes.

+ +

More and more, I'm trying to shove things into notes, so it feels less like a task and more of a I'm curious, or I'm interested in things that have piqued my interest. Let me go back and look at that list to see if there's something I want to pull from today or I need inspiration. That's what my notes often are; they're typically inspiration for something that I have seen and really liked, or maybe it's a bug that I looked into, and I want to recall how that happened or what was the process.

+ +

But yeah, my notes are typically a source of inspiration. So I try to dump most things in there. I don't know if that's particularly helpful for your task, though, because it sounds like you're looking for a way to manage the things that you actually need to do versus just capturing all of your thoughts.

+ +

CHRIS: Honestly, part of it is having a good system for those like, oh, I'd like to read this sometime. Ideally, for me, that doesn't go into my whatever to-do list system. But if my brain doesn't trust that I'll ever read it or if I feel like I'm putting it into a black hole, then my brain is just like, hey, you should really read that thing. Are you thinking about that? You should think about that and just brings it up.

+ +

And so having a system externalized that I trust such that then the to-do list can be as focused as possible. It's a sort of an arms race back and forth battle type thing of like, I've definitely done the loop of like, all right, I want to capture everything. I want to have perfect, lossless, productivity system, and that is not possible. And so then I overcorrect back the other way. I'm like, whatever, nothing matters. I'll just let everything fall away. And then I'm like, well, then my brain tries to remind me of stuff or tries to remember more.

+ +

And there's a book, Getting Things Done, which is one of the more common things recommended in the productivity world. And that informs a bunch of my thinking around this, the idea of capturing everything that's in your head so that you can get it out of your head. And in the moment, be focused and in the moment and not having to try and remember. And so that's the ideal that I'm searching for. But it's difficult to build that and make that work.

+ +

STEPH: It seems the answer is there's no perfect system. It's always finding what works for you. And I feel like it's always going to change from hopefully not month to month because that would be tedious. But it may change year to year depending on how you're prioritizing things and the types of things that you need to remember or that you need to accumulate somewhere. So I feel like it's always this evolving, iterative process of changing where we're storing this.

+ +

But I feel like where you store the notes and inspiration, that's something that, ideally, you want to make sure that you can always continue to keep forward. So even if you do change systems, that's something that's usually on my mind. It's like, well, if I use this system to store all of my thoughts, what if I want to move to something else? How stuck am I to this particular platform? And can I still have ownership of the things that I have added here?

+ +

But overall, yeah, I'd be intrigued to see what other people think if they have a particular system that works for them, or they have suggestions. But overall, it seems to be whatever caters best to your personality and your workflow. That's why there are so many of these. There are so many thoughts, so many videos, so many styles.

+ +

CHRIS: Yeah, I think a critical part of what you just said that feels very true to me is this is something that will change over time as well. Life comes in seasons, and my work may look a certain way, or my life may look a certain way, and then next year, it may be wildly different. And so, finding something that is good enough for right now and then moving forward with that and being open to revisiting it. And yeah, that feels true. So I'm in an explore phase right now. I'll report back if I have any major breakthroughs. But yeah, we'll see how it goes.

+ +

STEPH: I will say I think the main tool that I have really leaned into, while some of the others will change over time, is my calendar. There are certain things I've let go. My inbox is always going to be messy. My to-do list is always going to be messy. But my calendar that is where things really go to make sure that they happen. And I will even add tasks there as well.

+ +

So I feel like the calendar will always stick with me because I can trust that as the one source of like, these are the things that have to happen. Everything else I can check for during that day or figure it out as I go. Or if something gets dropped or bounces to the next day, it's okay.

+ +

CHRIS: Yeah, the calendar is definitely a core truth in my world. Whatever the calendar says, that is true. And I'm actually a...I hope I'm not annoying to anyone. But I'm very pointed in saying, "This recurring meeting that we have if we keep just canceling it the day before every time, let's get this off our calendars. Let's make sure our calendars are telling the truth because I trust that thing very much."

+ +

And two apps that I'm using right now that I've found really useful in the calendar world are MeetingBar, which I've talked about before. But it's a little menu bar application that shows the next meeting that's upcoming. And then I can click on it and see the list of them and easily join any video call associated, just a nice thing to keep the next thing on my calendar very top of mind, super useful, really love that. That's just open source and easy to run with.

+ +

The other that I've been spending more and more time with lately is SavvyCal. SavvyCal is similar to Calendly. It's a tool for sharing a link to allow someone to schedule something on your calendar. And, man, it is an impressive piece of technology. I've been leaning into some of the fancier features of it of late. And it has an amazing amount of control, and I think a really well-designed sort of information architecture as well. It took me a little while to figure out how to do everything I wanted to do in it.

+ +

But I wanted to be able to define a calendar link thing that I could share with someone that really constraints in the way that I wanted. Like, oh, don't let them schedule tomorrow, and make sure there's this much buffer between meetings. And don't let this calendar link schedule too many things on my calendar because I need to control my day, and give me some focus blocks. And they're not actually on my calendar, but please recognize that. And it basically supports all of these different ways of thinking and does an incredible job with it.

+ +

As an aside, SavvyCal is created by Derrick Reimer, who is the co-host of The Art of Product Podcast, which is co other hosted by Ben Orenstein, former thoughtboter, creator of Upcase, and a handful of other things. So small world and all of that. But yeah, really fantastic piece of technology that I've been loving lately.

+ +

STEPH: That's really cool. I have not heard of SavvyCal. I've used Calendly and used that a fair amount. And that is so awesome where you can just send it to people, and they can pick time on a calendar and do all the features that you'd mentioned. So it's good to know that there's SavvyCal as well.

+ +

Well, pivoting just a bit, we have a listener question that I'm really excited to dig into. This question comes from fellow thoughtboter, Steve Polito. And Steve writes in that, "Hey, Bike Shed, I've got a question for you. I find it difficult to know if there's an existing method in a large class or a class that includes many concerns. How can I avoid writing redundant methods when working on a large project?"

+ +

And Steve provided a really nice just contrived example where he's defined a class user that inherits from ApplicationRecord. And then comments, "Lots of methods making it really hard to scan this giant class. And then there's a method called formatted name. So it takes first name, adds a space, and then adds the user's last name. And then there are a lot more methods in between.

+ +

And then, way down, there's another method called full name that does the exact same thing. Just to provide a nice example of how can you find a method that has existing logic that you want and avoid implementing essentially the same method and the same class?"

+ +

So as someone who has worked on some legacy systems this year, I feel that pain. I feel the pain of where you have a really giant class, and that class may also include other modules. So then you have your range of all the methods that you may be looking through gets really widened. And you are looking for particular logic that you feel like may exist in the system, but you really just don't know.

+ +

So I don't know if I have a concrete method for how you can find duplicate logic and avoid writing that other method. But some of the things that I do is I will initially go to the test. So if there's some logic that I'm looking for and I think it's in this class or I have a suspicion, I will first look to see what has test coverage. And I find that is just easier to skim where I can find, and I'll use grep, and search and just look for anything.

+ +

In this particular case, let's use first name as our example. So I'm looking for anything that's going to collaborate with first name. Some of the other things that I'll do is I'll try to think of a business case where that logic is used. So, where are we displaying the user's full name? And if I can go to that page and see what's already in use, that may give me a hint to do we already have this logic? Is there something there that I should reuse, or is it something new that I'm implementing?

+ +

And then if I really want to get fancy about it, for some reason that I really want to see all the methods that are listed, but I'm trying to get rid of some of the noise in the file, then I could programmatically scan through all the available methods by doing something like class.instance methods and passing in false. So we don't include the methods that are from superclasses, which can be very helpful. So that way, you're just seeing what scoped to that class.

+ +

But then, let's say if you do have a class that is inheriting from other modules, then you may want to include those methods in your search. So to get fancier, you could look at that class' ancestor chain and then collect the classes or models that are custom to your application, and then look at those instance methods. And then you could sort them alphabetically.

+ +

But you're still really relying on is there a method name that looks very similar to what I would call this method? So I don't know that that's a really efficient way. But if I just feel like there's probably already something in this space and I'm just looking for a clue or some name that's going to hint that something already exists, that's one way I could do it.

+ +

To throw another wrench in there, I just remembered there are also private methods, and private methods don't get returned from instance methods. I think it's private instance methods is a method that you'd have to call to then include those in your search results as well. So outside of some deeper static analysis, this seems like a hard problem. This seems like something that would be challenging to solve.

+ +

And then I guess the other one is I ask a friend. So I will often lean on if there's someone else at the team that's been there longer than me is I will just ask in Slack and say, "Hey, I want to do a thing. I'm worried this already exists, or I think it already exists. Does anybody have any clues or ideas as to where this might live?"

+ +

I know I just ran through a giant list of ideas there. But I'm really curious, what are your thoughts? If you have a messier codebase and you're worried that you are reimplementing logic that already exists, but you're trying to make sure you don't duplicate that logic, how do you avoid that?

+ +

CHRIS: Well, the first thing I want to say is that I find it really interesting that I think you and I came at this from different directions. My answer, which I'll come to in a minute, is more of the I'm not actually sure that this is that easy to avoid, and maybe that's not the biggest problem in the world. And then I have some thoughts downstream from that.

+ +

But the list that you just gave was fantastic. That was a tour de force of how to understand and explore a codebase and try and answer this very hard question of like, does this logic already exist somewhere else? So I basically just agree with everything you said. And again, I'm deeply impressed with the range of options that you offer there for trying to figure this out.

+ +

That said, sometimes codebases just get really large. And this is going to happen. I think the specific mention of concerns as sort of a way that this problem can manifest feels true. Having the user object and being like, oh man, our user object is getting pretty big. Let's pull something out into a concern as just a way to clean it up. That actually adds a layer of indirection that makes it harder to understand the totality of what's going on in this thing.

+ +

And so personally, I tend to avoid concerns for that reason or at least at the model layer, especially where it's just a we got 1,000 methods here. Let's pull 200 of them into a file and maybe group them somewhat logically. That tends to not solve the problem in my mind. I found that it just basically adds a layer of indirection without much additional value.

+ +

I will say in this particular case, the thing that we're talking about presenting the full name or the formatted name feels almost like a presentational concern. So I might ask myself, is there a presenter object, something that wraps around a user and encapsulates this? And then we as a team know that that sort of presentational or formatting logic lives in the presentation format or layer. Maybe I'm not entirely convinced of that as an answer. But it's just sort of where can we find organizational lines to draw within our codebases?

+ +

I talked about query objects earlier. That's one case of this is behavior that I'll often see in classes as, say, a scope or something like that that I will extract out into a query object because it allows me to encapsulate it and break it out a little bit more but still have most of the nice pieces that I would want.

+ +

So are there different organizational patterns that are useful? I think it's very easy to start drawing arbitrary lines within our codebases and say, "These are services." And it's like, what does that mean? That doesn't mean anything. App Services, that's not a thing, so maybe don't do that. But maybe there are formatters, queries, commands, those feel like...or presenters, queries, commands. Maybe those are organizational structures that can be useful.

+ +

But switching to the other side of it, the first thing that came to mind is like, this is going to happen. As a codebase grows, this is absolutely going to happen. And so I would ask rather than how can I, as the developer, avoid doing this in the first place...which I think is a good question to ask. And again, everything you listed, Steph, is great. And I think a wonderful list of ways that you can actually try to avoid this.

+ +

But let's assume it is going to happen. So then, what do we do downstream from that? One answer that comes to mind is code review. Code review is not perfect. But this is the sort of thing that often in code review I will be like, oh, I actually wrote a method that's similar to this. Can you take a look at that and see can we use only one of these or something like that? So I've definitely seen code review be a line of defense on this front.

+ +

But again, stuff is still going to sneak through. And someday, you'll find it down the road. And that's the point in time that I think is most interesting. When you find this, can you fix it easily? Do you have both process-wise and infrastructure-wise the ability to do a very small PR that just removes the duplicate method, removes the usage of it, and consolidates on the one?

+ +

It's like, oh, I found it. Here's a 10-line PR that just removes that method, changes the usage. And now we're good. And that can go through code review and CI very quickly. And we have a team culture that allows us to make those tiny changes on the regular to get them out to production as quick as possible so that we know that this is a good code change, all of that.

+ +

I found there are teams that I've worked on where that process is much slower. And therefore, I will try and roll a change like that up into a bigger PR because I know that's the only way that it's really going to get through. Versus I've been on teams that have very high throughput is probably the best way to describe it. And on those teams, I find that the codebase tends to be in a healthier shape because it just naturally falls out of having a system that allows us to make changes rapidly with high trust, get them out into the world, et cetera.

+ +

STEPH: This is that bug or inconsistency that's going to show up where on one page you have the user's full name. And then on another page, you have the user's full name, but maybe the last name is not capitalized, or there's just something that's slightly different. And then that's when you realize that you have two implementations of essentially the same logic that have differed just enough.

+ +

I like how you pointed out that this is one of those things that as a codebase grows, it's probably going to happen, and that's fine. It's one of those if you do have duplicate logic, over time, based on your team's processes, you'll be able to then identify when it does happen, and then look for those preventative patterns for then how you organize your code.

+ +

How quickly can you make that change? Can you just issue a PR that then removes one of them? But then look for ways to say, how are we going to help our future selves recognize that if we're looking for a user's full name, where's a good place to look for that? And then what's a good domain space or naming that we can give to then help future searchers be able to find it?

+ +

I also really like your code review example because it does feel like one of those things that, yes, we want to catch it if we can, and we can leverage the team. But then also, it's not the end of the world if some of these methods do get duplicated.

+ +

There's one other thing that came to mind that it's not really going to help prevent duplicate methods, but it will help you identify unused code. So it's the Unused tooling that you can run on your codebase. And that's something that would be wonderful to run on your codebase every so often.

+ +

So that way, if someone has added...let's say there was a method that was full name but is not in use. It didn't have test coverage; that's why you didn't find it initially. And so you've introduced your own formatted name. And then, if you run unused at some point, then you'll hopefully catch some of those duplicate methods as long as they're not both in use.

+ +

CHRIS: I think one more thing that I didn't quite say in my earlier portion about this. But in order to do that, to use Unuse or to have these sort of small pull requests that are going through, you have to have test coverage that is sufficient that you are confident you're not going to break the app. Because the day that you do like, oh, there's a typo here; let me fix it real quick. Or there's this method I'm pretty sure it's not used; let me rip it out.

+ +

And then you deploy to production, and suddenly the error system is blowing up because, in fact, it was used but sneakily in a way that you didn't think of, and your test coverage didn't catch that. Then you don't have trust in the system, and everything slows down as a result of that. And so I would argue for fixing the root problem there, which is the lack of test coverage rather than the symptom, which is, oh, I made this change, it broke something. Therefore, I won't make small changes anymore.

+ +

STEPH: Definitely. Yeah, that's a great point.

+ +

CHRIS: So yeah, I don't have any answer. [laughs] My answers are like, I don't know, it's going to happen, but there's a lot of stuff organizationally that we can do. And granted, you gave a wonderful list of ways to actually avoid this. So I think the combination of our answers really it's a nice spectrum of thoughts on this topic.

+ +

STEPH: I agree. I feel like we covered a very nice range all the way from trying to identify and then how to prevent it or how to help future people be able to identify where that logic lives and find it more easily. Also, at the end of the day, I like the how big of a problem is this? And it is one of those sure; we want to avoid it.

+ +

But I liked how you captured that at the beginning where you're like, it's okay. Like, this is going to happen but then have the processes around it to then avoid or be able to undo some of that duplicate work. But otherwise, if it happens, don't sweat it; just look for ways to then prevent it from happening in the future.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph talks about winter storms and thoughts on name pronunciation features. Chris talks about writing a query to add a new display of data in an admin panel and making a guest appearance on the Svelte Radio Podcast.

+ +

Finally, Chris decided that his productivity to-do list system was failing him. So he's on the search now for something new. He asks Steph what she uses and if she's happy with it. How do you, dear Listener, keep track of all your stuff in the world?

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. We have Winter Storm Izzy headed our way. It's arriving in South Carolina early tomorrow morning. So that's kind of exciting just because it's South Carolina. We rarely see snow. In fact, I looked it up because I was curious because I've seen it every now and then. But I looked up the greatest cumulative snowfall in 1 season, and it was 19 inches in the winter of 1971. I was trying to add an old-timey voice there. I don't know if I was successful.

+ +

CHRIS: Does 1971 deserve a full old-timey voice?

+ +

STEPH: Apparently.

+ +

CHRIS: I feel like people from 1971 would be like, "We were just people in the 70s." Like, what do you...

+ +

STEPH: [laughs]

+ +

CHRIS: Wait. Nineteen inches, is that what you said?

+ +

STEPH: 19 inches. That was total for the season.

+ +

CHRIS: Yeah, we can bang that out in an afternoon up here in the North. So yeah, okay. You were here for the terrible, terrible winter, right?

+ +

STEPH: Oh, Snowmageddon? Yes.

+ +

CHRIS: Yeah, that was something, oof.

+ +

STEPH: I don't remember how many inches. Was it like 100 inches in a month or something wild like that? I've forgotten the facts.

+ +

CHRIS: I, too forget the facts. I remember the anecdotal piece of data, the anecdata as it were where we shoveled our driveway, and then another storm came, we shoveled our driveway. And then finally, I was living in an apartment, and it was time to shovel the driveway again. But the pile of snow on the lawn was too big. So we had to shovel the pile of snow further up the lawn to make room for the snow that we were shoveling out of the driveway.

+ +

But I also remember that being a really nice bonding moment, and I met more of the people living in the...it was a house that had been converted into six apartments. So I actually met some of the people from the house for the first time. And then we hung out a little bit more in the day. So I actually have weirdly fond memories of that time. But to be clear, that was too much snow. I will officially go on record saying too much snow. No, thank you again.

+ +

STEPH: It was a lot of snow. I think it broke Boston for a while. I remember I don't think I went to...I worked remotely for two weeks because they were just like, "Yeah, don't even try to come into the office. Don't worry about it." So it felt like my first dabbling into understanding quarantine [laughs] except at least with less complicated reasons, just with lots of snow. We also went snowboarding in Charlestown, where we were living. And that was fun because there are some really great hills, and there was so much snow that that was delightful.

+ +

But I'm not expecting Snowmageddon in South Carolina, although people may act like it and rush out and get their milk and bread. But hopefully, we'll get a couple of inches because that'll be lovely. I don't know that Utah has ever seen the snow. So this will be fun.

+ +

CHRIS: Oh, that'll definitely be fun. I imagine you've got like even if you do get some amount of accumulation, a day later the sun will just be like, "I'm back. I got this," and clear it up, and you won't have any lingering. The year of Snowmageddon, if I remember correctly, the final pile of snow left in July, the shared one that the city had collected. So you'll probably do better than that turnaround time. [laughs]

+ +

STEPH: Yeah, it's perfect. It's very ephemeral. It snows, it's beautiful. It's there for a couple of hours, and then poof, it's gone. And then you're back to probably 70-degree weather typically what’s here, [laughs] which I have no complaints. There's a reason that I like living here.

+ +

But in some other news, I have something that I'm really excited about that I want to share. So there's something that you and I work really hard to do correctly, and it's pronouncing someone's name. So whenever there is either a guest on the show, or we are referencing someone, we will often pause, and then we will look for videos. We'll look for an audio clip, something where that person says their name. And then we will do our best to then say it correctly. Although I probably put a Southern twang on a lot of people's names, so sorry about that. But that's really important to say someone's name correctly.

+ +

And one of thoughtbot's projects is called Hub, which is something that we use internally for all of our project staffing and then also for profiles and team information; there’s a new feature that Matheus Richard, another thoughtboter, implemented that I am just so excited about. And now that I have it, I just think I don't know how I lived without this. And I want it everywhere.

+ +

So Matheus has added the feature where you can upload an audio file with your name pronunciation. So you can go to someone's profile, and you can click on the little audio button and hear them pronounce their name. And then a number of people have taken it a bit further where they will provide, say, the American or English pronunciation of their name. And then they will provide their specific pronunciation; maybe it's Greek, maybe it's Spanish, and it's just phenomenal. And I love it so much. And I can't wait for just more platforms to have something like this. So really big shout out to Matheus Richard for that phenomenal feature.

+ +

CHRIS: Oh, that is awesome. Yeah, we definitely do pause pretty regularly to go scan through YouTube or try and find an example. And often, people just start into talks, or they'll only say their first name. We're like, oh, okay, keep searching, keep searching. We'll find it. And apologies to anyone whose name we still got wrong regardless of our efforts.

+ +

But it's making this a paramount idea similar to people putting their pronouns in their name. Like, okay, this is a thing that we should get into the habit of because the easier we make this, the more common that we make this. And names absolutely matter, and getting the pronunciation right really matters. And especially if it can be an easier thing, that's really wonderful. I hope Twitter and other platforms just adopt this; just take this entirely and make it easy because it should be.

+ +

STEPH: That's what I was thinking; if Twitter had this, and then I was thinking if Slack had this, that would be a wonderful place to be able to just see someone's profile because we can see lots of other helpful context about them. So yeah, it's wonderful.

+ +

I want to hear more people how they pronounce their names. Because I'll always ask somebody, but it would just be really nice to then be able to revisit or check-in before you talk to that person, and then you can just say their name. That would be delightful.

+ +

CHRIS: I do feel like creating it for my name would be interesting. I actually had someone this week say my name and then say, "Oh, is that how you pronounce it?" And I stopped for a minute, and I was like, "Yes. I'm really intrigued what other options you were considering, though. I would like to spend a minute and just...because I always thought there was really only the one approach, but I would love to know. Let's just explore the space here," but yes.

+ +

STEPH: [laughs] You ask them, "What else you got? What other variations can I hear?"

+ +

CHRIS: [laughs] I would like three variations on my desk by tomorrow so that I can understand what I'm missing out on, frankly. There's a theme or an idea that I've seen bouncing around on Twitter now of people saying, "Yeah, I really just want to apply, get hired, work for one day, make this one change to a platform, and immediately put in my resignation."

+ +

And I could see this like, "All right, I'm just going to go. I'm going to get hired by Twitter. This is it. This is all I'm doing," which really trivializes the amount of effort that would go into it for a platform like Twitter. I can't even imagine what engineering looks like in Twitter and how all the pieces come together. I'm imagining some amount of microservices there, and that's just my guess. But yeah, that idea of just like, this is my drive-by feature. I show up; I work for a week, I quit. And there we go; now we have it.

+ +

STEPH: Well, we are consultants. Maybe we'll get hired for all these different companies, and that will be our drive-by feature. We'll add it to their boards and be like, "Don't you want this? Don't you need this?" And then they'll say, "Yes." [chuckles]

+ +

CHRIS: I am intrigued because I can't imagine this hasn't come up in conversations at Twitter. And so, what are the trade-off considerations that they're making, or what are the reasons not to do this? I don't have any good answers there. I'm just asking the question because, for an organization their size, someone must have had this idea. Yeah, I wonder.

+ +

STEPH: Yeah, there's; also, I'm sure malicious things that then you have to consider as to then how people...because, at the end of the day, it's just an audio file. So it could be anything that you want it to be. So it starts to get complicated when you think about ways that people could abuse a feature.

+ +

On that peppy note, what's going on in your world?

+ +

CHRIS: I had a fun bit of coding that I got to do recently, which, more and more, my days don't involve as much coding. And so when I have a little bit of time, especially for a nice, self-contained little piece of code that I get to write, that's enjoyable. And so I was writing a query. I wanted to add a new display of data in our admin panel.

+ +

And I was trying to write a query, and I got to build a nice query object in Ruby, which I always enjoy. That's not a real thing, just in case anyone's hearing that and thinking like, wait, what's a query object? Just a class that takes in a relation and returns relation but encapsulates more complex query logic. It's one of my favorite types of ways to extract logic from ActiveRecord models, that sort of thing.

+ +

So I was building this query object, and specifically, what I wanted to do here is I'm going to simplify down the data model. And I'm going to say that we have users and reservations in the system. This may sound familiar to you, Steph, as your go-to example [laughs] from the past. We have users, and we have reservations in the system. So a user has many reservations. And reservations can be they have a timestamp or maybe an enum column. But basically, they have the idea of potentially being upcoming, so in the future.

+ +

And so what I wanted to do was I wanted to find all users in the system who have less than two upcoming reservations. Now, the critical detail here is that zero is a number less than two. So I wanted to know any users that have no upcoming reservations or one upcoming reservation. Those were the two like, technically, that's it. But say it was even less than three, that's fine as well. But I need to account for zero.

+ +

And so I rolled up my sleeves, started writing the query, and ActiveRecord has some really nice features for this where I can merge different scopes that are on the reservation.upcoming is a scope that I have on that model that determines if a reservation is upcoming because maybe there's more complex logic there. So that's encapsulated over there.

+ +

But what I tried initially was users.leftjoinsreservations .groupbyusers.id havingcountofreservations. So that was what I got to. And thankfully, I wrote a bunch of tests for this, which is one of the wonderful things about extracting the query object. It was very easy to isolate this thing: write a bunch of tests that execute it with given data.

+ +

And interestingly, I found that it worked properly for users with a bunch of upcoming reservations. They were not returned by the query objects which they shouldn't, and users with one upcoming reservation. But users with zero upcoming reservations were being filtered out. And that was a surprise.

+ +

STEPH: Is it because the way you were joining and looking where the reservation had to match to a user, so you weren't getting where users didn't have a reservation?

+ +

CHRIS: It was related to that. So there's a subtlety to LEFT JOINS. So a JOIN is going to say like, users and reservations. But in that case, if there is a user without reservations, I know they're going to be filtered out of this query. So it's like, oh, I know what to do. LEFT JOINS, I got this. So LEFT JOINS says, "Give me all of the users and then in the query space that I'm building up here, join them to their reservations." So even a user with no reservations is now part of the recordset that is being considered for this query.

+ +

But when I added the filter of reservations.upcoming, I tried to merge that in using ActiveRecord's .merge syntax on a query or on a relation, as it were. That would not work because it turns out when you're using the LEFT JOINS...and as I'm saying this, I'm going to start saying, like, here's definitively what's true. I probably still don't entirely understand this, but trying to do the WHERE clause on the outer query did not work. And I had to move that filtering logic into the LEFT JOINS.

+ +

So the definition of the JOINS was now I had to actually handwrite that portion of the SQL and say, LEFT OUTER JOIN users on and then, you know, the users.id=reservations.userid and reservations. whatever the logic there for an upcoming reservation. So reservations.completed is null or reservations.date>date.current or whatever logic there. But I had to include that logic in the definition of the LEFT OUTER JOIN, which is not a thing that I think I've done before. So it was part of the definition of the JOIN rather than part of the larger query that we were operating on.

+ +

STEPH: Yeah, that's interesting. I don't think I would have caught that myself. And luckily, you had the test to then point out to you.

+ +

CHRIS: Yeah, definitely the tests made me feel much more confident when I eventually narrowed down and started to understand it and was able to make the change in the code. I was also quite happy with the way I was able to structure it. So, suddenly, I had to handwrite a little bit of SQL. And what was nice is many, many, many years ago, I recorded a wonderful course on Upcase with Joe Ferris, CTO of thoughtbot, on Advanced ActiveRecord Querying. And I'm still years later digesting everything that Joe said in that course. It's really an amazing piece of content.

+ +

But one of the things that I learned is Joe shows a bunch of examples throughout that course of ways that where you need to, you can drop down to raw SQL within an ActiveRecord relation. But you don't need to completely throw it out and write the entire query by hand. You can just say, in this case, all I had to handwrite was the JOINS logic for that LEFT JOINS. But the rest of it was still using normal ActiveRecord query logic. And the .having was scoped on its own, and all of those sort of things. So it was a nice balance of still staying mostly within the ActiveRecord query Builder syntax and then dropping down to a lower level where I needed it.

+ +

STEPH: I love that you mentioned that video because I have seen it, and it is so good. In fact, I now want to go back and rewatch it since you've mentioned it just because I remember I always learn something every time that I do watch it. On a side note, the way that you represented and described query objects was so lovely.

+ +

I know you, and I have talked about query objects before because we adore them. But I feel like you just gave a really good mini class and overview of like, this is what a query object is, and this is what it does. And this is why they're great because you can test them.

+ +

CHRIS: Cool. I'm going to be honest; I have no idea what I said. But I'm glad it was good. [laughs]

+ +

STEPH: It was. It was really good. If anyone has questions about query objects, that'll be a good reference.

+ +

CHRIS: Well, thank you so much for the kind words there. And for the ActiveRecord querying trail, really, I was just along for the ride on that one, to be clear. I did write a bunch of notes after the fact, which I've found incredibly useful because the videos are great. But having the notes to be able to reference...past me spent a lot of time trying really hard to understand what Joe had said so that I could write it down. And I'm very glad that I invested that time and effort so that I can revisit it more easily.

+ +

But yeah, that was just a fun little bit of code that I got to write and a new thing that I've learned in the world of SQL, which is one of those topics that every little investment of effort I find to be really valuable. The more comfortable I feel, the more that I can express in SQL.

+ +

It's one of those investments that I'm like, yep, glad I did that. Whereas there are other things like, yeah, I learned years ago how to do X. I've completely forgotten it. It's gone from my head. I'm never going to use it again, or the world has changed. But SQL is one of those topics where I appreciate all of the investment I've put in and always find it valuable to invest a bit more in my knowledge there.

+ +

STEPH: Yeah, absolutely same. Just to troll Regexs for a little bit, they're powerful, but they're the thing that I will never commit to learning. I refuse to do it. [laughs] I will always look it up when I need to. But Postgres or SQL, on the other hand, is always incredibly valuable. And I'm always happy to learn something new and invest in that area of my skills.

+ +

CHRIS: Yep, SQL and Postgres are great things. But let's see. In other news, actually, I had the pleasure of joining the Svelte Radio Podcast for an episode this week. They invited me on as a guest. And we got to chat about Svelte, and then I accidentally took the conversation in the direction of inertia as I always do.

+ +

And then I talked a little bit more about Sagewell, the company that I'm building, and all sorts of things in the world. But that was really fun, and I really enjoyed that. And I believe it will be live by the time this episode goes live. So we will certainly include a link to that episode in our show notes here.

+ +

STEPH: That's awesome. I haven't listened to the Svelte Podcast before. So I'm excited to hear your episode and all the good things that you said on it. I'm also just less familiar with them. Who runs the Svelte Podcast, and what's the name of the show?

+ +

CHRIS: The show is called Svelte Radio. It's hosted by Antony, Shawn, and Kevin, who are three Svelters from the community. Svelte is a really interesting group where the Svelte society is, as far as I can tell, a community organization that is seemingly well-supported by the core team and embraced as the natural center point of the community. And then Svelte Radio is an extension of that.

+ +

And it's a wonderful podcast. Each week, they talk about various things. So there are news episodes, and then they have guests on from time to time. Recently, having Rich Harris on to talk about the future of Svelte, Rich Harris being the creator of Svelte.

+ +

Interestingly, if you search for Svelte Radio, they are the second Google result because the first Google result is the tutorial docs on how to use Svelte with radio buttons. But then the second one is Svelte Radio, the podcast, [laughs], which is an interesting thing. Good on Svelte's documentation for having such strong SEO.

+ +

STEPH: I was just thinking there's something delightful about that where the first hit is for documentation that's a very helpful; here’s how you use this. That's kind of lovely. Well, that's really cool. I'm really looking forward to hearing more about Svelte and listening to you be on the show.

+ +

CHRIS: Yeah, they actually had some very kind things to say about The Bike Shed and, frankly, you as well and our co-hosting that we do here. So that was always nice to hear.

+ +

STEPH: That's very kind of them. And it never fails to amaze me how nice podcasters are. Everyone that I've met in this community that's a fellow podcaster they're just all such wonderful, nice, kind people, and I just appreciate the heck out of them.

+ +

CHRIS: Yeah, podcasts are great. The internet is doing its job; that’s my strong belief there. But let's see. In other news, I actually have more of a question here, sort of a question and an observation. My work has started to take a slightly different shape than it has historically. Often, I'm a developer working on a team, picking up something off the top of the Trello board or whatever we're using for project management, working on that thing, pushing it through to acceptance. But all of the work or the vast majority of the work is encapsulated in this one shared planning context.

+ +

But now, enough of my work is starting to spill out in different directions. Like right now, I'm pushing on hiring. That's a task that largely lives with me that doesn't live on the shared Trello board. Certainly, the rest of the team will be involved at some point. But for now, there's that that's really mine. And there are other pieces of work that are starting to take that shape.

+ +

So I recognize, or at least I decided that my productivity to-do lists system was failing me. So I'm on the search now for something new, but I'm intrigued. What do you use? Are you happy with what you have for to-do lists? How do you keep track of stuff in the world?

+ +

STEPH: Oh goodness. I'm now going to overanalyze everything that I do and how I keep track of the things that I do. [chuckles] So currently, I have two things that I used to track, and that is...okay, I'm going to expand. I have three to-do lists that I use to track. [laughs]

+ +

Todoist is where I add most things of where whatever I just think of, and I want to capture it Todoist is usually where it goes. Because then it's very easy for me to then go back to that list and prioritize or just simply delete stuff. If I haven't gotten to it in a while, I'm like, fine, let it go. Move on.

+ +

And then the other place I've started using just because it's been helpful in terms of linking to stuff is Basecamp. So we use Basecamp at thoughtbot, and we use it for a number of internal projects. But I have created my own project thanks to some advice from Mike Burns, a fellow thoughtboter, because he created his own and uses that to manage a lot of his to-dos and tasks that he has. And then that way, it's already one-stop shopping since you're in Basecamp a lot throughout the day or at least where you're going to visit some of the tasks that you need to work on. So that has been helpful just because it's very simple and easy to reference.

+ +

And then calendar, I just live by my calendar. So if something is of the utmost importance...I realize I'm going in this in terms of order of importance. If something is critical, it's on my calendar. That's where it goes. Because I know I have not only put it somewhere that I am guaranteed to see it, but I have carved out time for it too. That's my three-tier system. [laughs]

+ +

CHRIS: I like it. That sounds great, not overly complicated but plenty going on there. And it sounds like it's working for you, sounds like you're happy with that.

+ +

STEPH: It has worked really well. I'm still evaluating the Basecamp, but so far, it has been helpful. It does help me separate between fun to-do items which go in Todoist and maybe just some other work stuff. But if it's really work-focused, then it's going in Basecamp right now. So there's a little helpful separation there between what's going on in my life versus then things I need to prioritize for work. What are the things that you're currently using, and where are you feeling they're falling down or not being as helpful as you'd like them to be?

+ +

CHRIS: My current exploration, I'm starting to look for a new to-do list-type things. Specifically, I've been using Trello for a long time for probably a couple of years now. And that was a purposeful choice to move away from some of the more structured systems because I found they weren't providing as much value. I was constantly bouncing between different clients and moving into different systems.

+ +

And so much of the work was centrally organized there that the little bit of stuff that I had personally to keep track of was easy enough to manage within a Trello board. And then slowly, my Trello board morphed into like 10 Trello boards for different topics. So I have one that's like this is research. These are things that I want to look into. And so I can have sort of a structure and prioritization within that context in my world.

+ +

And then there's one for fitness and one for cooking. I'm trying to think which else...experiments, as I'm thinking about I want to try this new thing in the world. I have a board for that. So I have a bunch of those that allow me to keep things that aren't as actionable, that are more sort of explorations. But then they each have their own structure. And that I found to be really useful and I think I'll hold on to.

+ +

But my core to-do board has started failing me, has started being just not quite enough. And then, more so, I wanted a distinct thing for work for a professional context. So I was like, all right, let me go back to the drawing board and see what's out there. And I did a quick scan of Todoist and Things, respectively. And I've settled on Things for right now. It just matches a little bit more to my mental model.

+ +

Todoist really pushes on the idea of due dates or dates as a singular idea associated with most things. Almost everything should have a date. And I kind of philosophically disagree with that. Whereas Things has this interesting idea of there is the idea of a due date, but it's de-emphasized in their UI because not everything has a due date; most things don't.

+ +

But Things has a separate idea of a scheduled date or an intent date. Like yeah, I think I'll work on that on Wednesday. It's not due on Wednesday; that's just when I want to work on it. It can have a separate due date. Like, maybe it's due Friday.

+ +

STEPH: Is the name of the application that you're saying is it Things? Is that the name of it?

+ +

CHRIS: Yeah, it is.

+ +

STEPH: I haven't heard this one. You kept saying Things. I was like, wait, is he being vague? But I realized you're being specific. [laughs]

+ +

CHRIS: It's one of the few things that...yeah, one of the few things that I think is not great about Things. It's from a company Cultured Code, and the application is called Things. And that is all I will say on that topic. Different names maybe would have been better, but they seem to have carved out enough of an attention space.

+ +

Enough people know of it that if you search for Things and to-do list, it will very quickly pop up. But yeah, that's a pretty ambiguous name. They maybe could have done a different one there. But the design of the application is really nice. It's on my desktop. And now I have it on my phone as well, and they sync between them and all the stuff.

+ +

So there's never going to be a perfect system. I'm certain of that. I've at least talked myself out of trying to build my own because, man, have I fallen into that trap before. Oh goodness, so many times.

+ +

STEPH: I'm very proud of you.

+ +

CHRIS: Thank you. I'm trying.

+ +

STEPH: But yeah, it'll be interesting to see how it evolves. I continue to struggle with there are these things that come to mind, and I want to capture them during the day. But some of them are just stories I'm telling myself, which would probably be best captured in a journal tool. And then there are notes that I might want to keep on remote work and how people think about that.

+ +

And so I'm starting to think about Obsidian or a note-taking system for that. And then I've got this Trello board concoction. And now I've got a to-do...and suddenly I'm like, well, that's too many things. And so I'm trying to not overthink it. I'm trying to not underthink it. I'm trying to just find that perfect amount of thinking. That's what I'm aiming for. I'm not sure I'm going to hit it directly, [laughs], but that's what I'm aiming for.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Some of the topics that you mentioned earlier did stand out to me when you're talking about recipes and working out some other topics. Those are things for me that I often just put in notes. So I liked the word that you used for stories that you're telling yourself or things that you're interested in. Is that something that...I don't put it in Todoist or put it somewhere because I don't really have an action item. It's more like, yeah, this recipe looks awesome and one day...so I'm going to stash it somewhere so I can find it.

+ +

I'm currently using Notion. I used Bear before. It is beautiful. I really liked Bear, but I needed a little bit more structure, and Notion gave me that structure. And so I will just dump it in Notion. And then it's very searchable, so I can always find whatever recipe or whatever thought that was as long as I try to add buzzwords to my own notes. Like, what would have Stephanie searched for looking for this? So I will try to include some of those words just so I can easily find it.

+ +

CHRIS: I love you're defining yourself as a Stephanie. For a random Stephanie walking through the woods, what search terms? How can I SEO arbitrage a Stephanie?

+ +

STEPH: What would she look for?

+ +

CHRIS: Who knows?

+ +

STEPH: That Stephanie, she's sneaky. You never know.

+ +

CHRIS: You never can tell. Obsidian is the one that I'm looking at now. But I'm currently using Apple Notes. And it's really nice to be able to search directly into a note very quickly. I have that both via Alfred and then on my phone. And I'm finding a lot of utility in that, particularly for notes, for things I want to talk to someone about.

+ +

But now there are seven different things, and how are they connected? And where is something? And to the question of where would a future Christopher look for this, let's make sure I put it in that place. But I don't know what that dude's going to be up to. He's a weird guy. He might look in a completely random place. So I'm trying to outsmart him, and oof, good luck, me.

+ +

STEPH: [laughs] I have heard of Obsidian, but I don't recall much about it. So I'd have to look into it. I do feel your pain around Todoist and where it really encourages you to set a date. Because there are often things where I'm like, I saw something I want to read. And I know there are tons of tools.

+ +

There are so many tools and videos and things that people could watch if they really want to invest in this workflow. But right now, I've told myself no, and so I use Todoist. And I see something I want to read, and so I just link to it. And I don't have a particular date that I want to read it. I'm like, this looks cool, and so then I add it to a reading list. But that also, I guess, could be something for notes.

+ +

More and more, I'm trying to shove things into notes, so it feels less like a task and more of a I'm curious, or I'm interested in things that have piqued my interest. Let me go back and look at that list to see if there's something I want to pull from today or I need inspiration. That's what my notes often are; they're typically inspiration for something that I have seen and really liked, or maybe it's a bug that I looked into, and I want to recall how that happened or what was the process.

+ +

But yeah, my notes are typically a source of inspiration. So I try to dump most things in there. I don't know if that's particularly helpful for your task, though, because it sounds like you're looking for a way to manage the things that you actually need to do versus just capturing all of your thoughts.

+ +

CHRIS: Honestly, part of it is having a good system for those like, oh, I'd like to read this sometime. Ideally, for me, that doesn't go into my whatever to-do list system. But if my brain doesn't trust that I'll ever read it or if I feel like I'm putting it into a black hole, then my brain is just like, hey, you should really read that thing. Are you thinking about that? You should think about that and just brings it up.

+ +

And so having a system externalized that I trust such that then the to-do list can be as focused as possible. It's a sort of an arms race back and forth battle type thing of like, I've definitely done the loop of like, all right, I want to capture everything. I want to have perfect, lossless, productivity system, and that is not possible. And so then I overcorrect back the other way. I'm like, whatever, nothing matters. I'll just let everything fall away. And then I'm like, well, then my brain tries to remind me of stuff or tries to remember more.

+ +

And there's a book, Getting Things Done, which is one of the more common things recommended in the productivity world. And that informs a bunch of my thinking around this, the idea of capturing everything that's in your head so that you can get it out of your head. And in the moment, be focused and in the moment and not having to try and remember. And so that's the ideal that I'm searching for. But it's difficult to build that and make that work.

+ +

STEPH: It seems the answer is there's no perfect system. It's always finding what works for you. And I feel like it's always going to change from hopefully not month to month because that would be tedious. But it may change year to year depending on how you're prioritizing things and the types of things that you need to remember or that you need to accumulate somewhere. So I feel like it's always this evolving, iterative process of changing where we're storing this.

+ +

But I feel like where you store the notes and inspiration, that's something that, ideally, you want to make sure that you can always continue to keep forward. So even if you do change systems, that's something that's usually on my mind. It's like, well, if I use this system to store all of my thoughts, what if I want to move to something else? How stuck am I to this particular platform? And can I still have ownership of the things that I have added here?

+ +

But overall, yeah, I'd be intrigued to see what other people think if they have a particular system that works for them, or they have suggestions. But overall, it seems to be whatever caters best to your personality and your workflow. That's why there are so many of these. There are so many thoughts, so many videos, so many styles.

+ +

CHRIS: Yeah, I think a critical part of what you just said that feels very true to me is this is something that will change over time as well. Life comes in seasons, and my work may look a certain way, or my life may look a certain way, and then next year, it may be wildly different. And so, finding something that is good enough for right now and then moving forward with that and being open to revisiting it. And yeah, that feels true. So I'm in an explore phase right now. I'll report back if I have any major breakthroughs. But yeah, we'll see how it goes.

+ +

STEPH: I will say I think the main tool that I have really leaned into, while some of the others will change over time, is my calendar. There are certain things I've let go. My inbox is always going to be messy. My to-do list is always going to be messy. But my calendar that is where things really go to make sure that they happen. And I will even add tasks there as well.

+ +

So I feel like the calendar will always stick with me because I can trust that as the one source of like, these are the things that have to happen. Everything else I can check for during that day or figure it out as I go. Or if something gets dropped or bounces to the next day, it's okay.

+ +

CHRIS: Yeah, the calendar is definitely a core truth in my world. Whatever the calendar says, that is true. And I'm actually a...I hope I'm not annoying to anyone. But I'm very pointed in saying, "This recurring meeting that we have if we keep just canceling it the day before every time, let's get this off our calendars. Let's make sure our calendars are telling the truth because I trust that thing very much."

+ +

And two apps that I'm using right now that I've found really useful in the calendar world are MeetingBar, which I've talked about before. But it's a little menu bar application that shows the next meeting that's upcoming. And then I can click on it and see the list of them and easily join any video call associated, just a nice thing to keep the next thing on my calendar very top of mind, super useful, really love that. That's just open source and easy to run with.

+ +

The other that I've been spending more and more time with lately is SavvyCal. SavvyCal is similar to Calendly. It's a tool for sharing a link to allow someone to schedule something on your calendar. And, man, it is an impressive piece of technology. I've been leaning into some of the fancier features of it of late. And it has an amazing amount of control, and I think a really well-designed sort of information architecture as well. It took me a little while to figure out how to do everything I wanted to do in it.

+ +

But I wanted to be able to define a calendar link thing that I could share with someone that really constraints in the way that I wanted. Like, oh, don't let them schedule tomorrow, and make sure there's this much buffer between meetings. And don't let this calendar link schedule too many things on my calendar because I need to control my day, and give me some focus blocks. And they're not actually on my calendar, but please recognize that. And it basically supports all of these different ways of thinking and does an incredible job with it.

+ +

As an aside, SavvyCal is created by Derrick Reimer, who is the co-host of The Art of Product Podcast, which is co other hosted by Ben Orenstein, former thoughtboter, creator of Upcase, and a handful of other things. So small world and all of that. But yeah, really fantastic piece of technology that I've been loving lately.

+ +

STEPH: That's really cool. I have not heard of SavvyCal. I've used Calendly and used that a fair amount. And that is so awesome where you can just send it to people, and they can pick time on a calendar and do all the features that you'd mentioned. So it's good to know that there's SavvyCal as well.

+ +

Well, pivoting just a bit, we have a listener question that I'm really excited to dig into. This question comes from fellow thoughtboter, Steve Polito. And Steve writes in that, "Hey, Bike Shed, I've got a question for you. I find it difficult to know if there's an existing method in a large class or a class that includes many concerns. How can I avoid writing redundant methods when working on a large project?"

+ +

And Steve provided a really nice just contrived example where he's defined a class user that inherits from ApplicationRecord. And then comments, "Lots of methods making it really hard to scan this giant class. And then there's a method called formatted name. So it takes first name, adds a space, and then adds the user's last name. And then there are a lot more methods in between.

+ +

And then, way down, there's another method called full name that does the exact same thing. Just to provide a nice example of how can you find a method that has existing logic that you want and avoid implementing essentially the same method and the same class?"

+ +

So as someone who has worked on some legacy systems this year, I feel that pain. I feel the pain of where you have a really giant class, and that class may also include other modules. So then you have your range of all the methods that you may be looking through gets really widened. And you are looking for particular logic that you feel like may exist in the system, but you really just don't know.

+ +

So I don't know if I have a concrete method for how you can find duplicate logic and avoid writing that other method. But some of the things that I do is I will initially go to the test. So if there's some logic that I'm looking for and I think it's in this class or I have a suspicion, I will first look to see what has test coverage. And I find that is just easier to skim where I can find, and I'll use grep, and search and just look for anything.

+ +

In this particular case, let's use first name as our example. So I'm looking for anything that's going to collaborate with first name. Some of the other things that I'll do is I'll try to think of a business case where that logic is used. So, where are we displaying the user's full name? And if I can go to that page and see what's already in use, that may give me a hint to do we already have this logic? Is there something there that I should reuse, or is it something new that I'm implementing?

+ +

And then if I really want to get fancy about it, for some reason that I really want to see all the methods that are listed, but I'm trying to get rid of some of the noise in the file, then I could programmatically scan through all the available methods by doing something like class.instance methods and passing in false. So we don't include the methods that are from superclasses, which can be very helpful. So that way, you're just seeing what scoped to that class.

+ +

But then, let's say if you do have a class that is inheriting from other modules, then you may want to include those methods in your search. So to get fancier, you could look at that class' ancestor chain and then collect the classes or models that are custom to your application, and then look at those instance methods. And then you could sort them alphabetically.

+ +

But you're still really relying on is there a method name that looks very similar to what I would call this method? So I don't know that that's a really efficient way. But if I just feel like there's probably already something in this space and I'm just looking for a clue or some name that's going to hint that something already exists, that's one way I could do it.

+ +

To throw another wrench in there, I just remembered there are also private methods, and private methods don't get returned from instance methods. I think it's private instance methods is a method that you'd have to call to then include those in your search results as well. So outside of some deeper static analysis, this seems like a hard problem. This seems like something that would be challenging to solve.

+ +

And then I guess the other one is I ask a friend. So I will often lean on if there's someone else at the team that's been there longer than me is I will just ask in Slack and say, "Hey, I want to do a thing. I'm worried this already exists, or I think it already exists. Does anybody have any clues or ideas as to where this might live?"

+ +

I know I just ran through a giant list of ideas there. But I'm really curious, what are your thoughts? If you have a messier codebase and you're worried that you are reimplementing logic that already exists, but you're trying to make sure you don't duplicate that logic, how do you avoid that?

+ +

CHRIS: Well, the first thing I want to say is that I find it really interesting that I think you and I came at this from different directions. My answer, which I'll come to in a minute, is more of the I'm not actually sure that this is that easy to avoid, and maybe that's not the biggest problem in the world. And then I have some thoughts downstream from that.

+ +

But the list that you just gave was fantastic. That was a tour de force of how to understand and explore a codebase and try and answer this very hard question of like, does this logic already exist somewhere else? So I basically just agree with everything you said. And again, I'm deeply impressed with the range of options that you offer there for trying to figure this out.

+ +

That said, sometimes codebases just get really large. And this is going to happen. I think the specific mention of concerns as sort of a way that this problem can manifest feels true. Having the user object and being like, oh man, our user object is getting pretty big. Let's pull something out into a concern as just a way to clean it up. That actually adds a layer of indirection that makes it harder to understand the totality of what's going on in this thing.

+ +

And so personally, I tend to avoid concerns for that reason or at least at the model layer, especially where it's just a we got 1,000 methods here. Let's pull 200 of them into a file and maybe group them somewhat logically. That tends to not solve the problem in my mind. I found that it just basically adds a layer of indirection without much additional value.

+ +

I will say in this particular case, the thing that we're talking about presenting the full name or the formatted name feels almost like a presentational concern. So I might ask myself, is there a presenter object, something that wraps around a user and encapsulates this? And then we as a team know that that sort of presentational or formatting logic lives in the presentation format or layer. Maybe I'm not entirely convinced of that as an answer. But it's just sort of where can we find organizational lines to draw within our codebases?

+ +

I talked about query objects earlier. That's one case of this is behavior that I'll often see in classes as, say, a scope or something like that that I will extract out into a query object because it allows me to encapsulate it and break it out a little bit more but still have most of the nice pieces that I would want.

+ +

So are there different organizational patterns that are useful? I think it's very easy to start drawing arbitrary lines within our codebases and say, "These are services." And it's like, what does that mean? That doesn't mean anything. App Services, that's not a thing, so maybe don't do that. But maybe there are formatters, queries, commands, those feel like...or presenters, queries, commands. Maybe those are organizational structures that can be useful.

+ +

But switching to the other side of it, the first thing that came to mind is like, this is going to happen. As a codebase grows, this is absolutely going to happen. And so I would ask rather than how can I, as the developer, avoid doing this in the first place...which I think is a good question to ask. And again, everything you listed, Steph, is great. And I think a wonderful list of ways that you can actually try to avoid this.

+ +

But let's assume it is going to happen. So then, what do we do downstream from that? One answer that comes to mind is code review. Code review is not perfect. But this is the sort of thing that often in code review I will be like, oh, I actually wrote a method that's similar to this. Can you take a look at that and see can we use only one of these or something like that? So I've definitely seen code review be a line of defense on this front.

+ +

But again, stuff is still going to sneak through. And someday, you'll find it down the road. And that's the point in time that I think is most interesting. When you find this, can you fix it easily? Do you have both process-wise and infrastructure-wise the ability to do a very small PR that just removes the duplicate method, removes the usage of it, and consolidates on the one?

+ +

It's like, oh, I found it. Here's a 10-line PR that just removes that method, changes the usage. And now we're good. And that can go through code review and CI very quickly. And we have a team culture that allows us to make those tiny changes on the regular to get them out to production as quick as possible so that we know that this is a good code change, all of that.

+ +

I found there are teams that I've worked on where that process is much slower. And therefore, I will try and roll a change like that up into a bigger PR because I know that's the only way that it's really going to get through. Versus I've been on teams that have very high throughput is probably the best way to describe it. And on those teams, I find that the codebase tends to be in a healthier shape because it just naturally falls out of having a system that allows us to make changes rapidly with high trust, get them out into the world, et cetera.

+ +

STEPH: This is that bug or inconsistency that's going to show up where on one page you have the user's full name. And then on another page, you have the user's full name, but maybe the last name is not capitalized, or there's just something that's slightly different. And then that's when you realize that you have two implementations of essentially the same logic that have differed just enough.

+ +

I like how you pointed out that this is one of those things that as a codebase grows, it's probably going to happen, and that's fine. It's one of those if you do have duplicate logic, over time, based on your team's processes, you'll be able to then identify when it does happen, and then look for those preventative patterns for then how you organize your code.

+ +

How quickly can you make that change? Can you just issue a PR that then removes one of them? But then look for ways to say, how are we going to help our future selves recognize that if we're looking for a user's full name, where's a good place to look for that? And then what's a good domain space or naming that we can give to then help future searchers be able to find it?

+ +

I also really like your code review example because it does feel like one of those things that, yes, we want to catch it if we can, and we can leverage the team. But then also, it's not the end of the world if some of these methods do get duplicated.

+ +

There's one other thing that came to mind that it's not really going to help prevent duplicate methods, but it will help you identify unused code. So it's the Unused tooling that you can run on your codebase. And that's something that would be wonderful to run on your codebase every so often.

+ +

So that way, if someone has added...let's say there was a method that was full name but is not in use. It didn't have test coverage; that's why you didn't find it initially. And so you've introduced your own formatted name. And then, if you run unused at some point, then you'll hopefully catch some of those duplicate methods as long as they're not both in use.

+ +

CHRIS: I think one more thing that I didn't quite say in my earlier portion about this. But in order to do that, to use Unuse or to have these sort of small pull requests that are going through, you have to have test coverage that is sufficient that you are confident you're not going to break the app. Because the day that you do like, oh, there's a typo here; let me fix it real quick. Or there's this method I'm pretty sure it's not used; let me rip it out.

+ +

And then you deploy to production, and suddenly the error system is blowing up because, in fact, it was used but sneakily in a way that you didn't think of, and your test coverage didn't catch that. Then you don't have trust in the system, and everything slows down as a result of that. And so I would argue for fixing the root problem there, which is the lack of test coverage rather than the symptom, which is, oh, I made this change, it broke something. Therefore, I won't make small changes anymore.

+ +

STEPH: Definitely. Yeah, that's a great point.

+ +

CHRIS: So yeah, I don't have any answer. [laughs] My answers are like, I don't know, it's going to happen, but there's a lot of stuff organizationally that we can do. And granted, you gave a wonderful list of ways to actually avoid this. So I think the combination of our answers really it's a nice spectrum of thoughts on this topic.

+ +

STEPH: I agree. I feel like we covered a very nice range all the way from trying to identify and then how to prevent it or how to help future people be able to identify where that logic lives and find it more easily. Also, at the end of the day, I like the how big of a problem is this? And it is one of those sure; we want to avoid it.

+ +

But I liked how you captured that at the beginning where you're like, it's okay. Like, this is going to happen but then have the processes around it to then avoid or be able to undo some of that duplicate work. But otherwise, if it happens, don't sweat it; just look for ways to then prevent it from happening in the future.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+6tBeUoIr + + ]]> + + Chris Toomey + Steph Viccari + + + 322: Toxic Traits + https://bikeshed.thoughtbot.com/322 + fdbf97c9-0c37-477b-950e-b1eb355bdd2e + Tue, 18 Jan 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Happy New Year (for real)! Chris and Steph both took some end-of-year time off to rest and recharge. + +Steph talks about some books she enjoyed, recipes she tried, and trail-walking adventures with her dog, Utah. Chris' company is now in a good position to actually start hiring within the engineering team. He's excited about that and will probably delve into more around the hiring process in the coming weeks. + +Since they aren't really big on New Year's Eve resolutions, Steph and Chris answer a listener question regarding toxic traits inspired by the listener question related to large pull requests and reflect on their own. + 35:21 + no + + + Happy New Year (for real)! Chris and Steph both took some end-of-year time off to rest and recharge. +Steph talks about some books she enjoyed, recipes she tried, and trail-walking adventures with her dog, Utah. Chris' company is now in a good position to actually start hiring within the engineering team. He's excited about that and will probably delve into more around the hiring process in the coming weeks. +Since they aren't really big on New Year's Eve resolutions, Steph and Chris answer a listener question regarding toxic traits inspired by the listener question related to large pull requests and reflect on their own. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +The Midnight Library by Matt Haig (http://www.matthaig.com/books/midnight-library/) +Tim Urban on Twitter (https://twitter.com/waitbutwhy/status/1367871165319049221) +How to Stop Time by Matt Haig (http://www.matthaig.com/how-to-stop-time/) +Do the Next Right Thing (https://daverupert.com/2020/09/do-the-next-right-thing/) +Debugging Why Your Specs Have Slowed Down (https://thoughtbot.com/blog/debugging-why-your-specs-have-slowed-down) +test-prof (https://github.com/test-prof/test-prof) +Tests Oddly Slow Might Be Bcrypt (https://collectiveidea.com/blog/archives/2012/11/12/tests-oddly-slow-might-be-bcrypt) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? +CHRIS: What's new in my world? Well, spoiler, we actually may have lied in a previous episode when we said, "Hey, happy New Year," because, for us, it was not actually the new year. But this, in fact, is the first episode of the new year that we're recording, that you're hearing. Anyway, this is enough breaking the fourth wall. Sorry, listener. +STEPH: [laughs] +CHRIS: Inside baseball, yadda, yadda. I'm doing great. First week back. I took some amount of vacation over the holidays, which was great, recharging, all those sorts of things. But now we're hitting the ground running. +And I'm actually really enjoying just getting back into the flow of things and, frankly, trying to ramp everything up, which we can probably talk about more in a moment. But how about you? How's your new year kicking off? +STEPH: I like how much we plan the episodes around when it's going to release, and we're very thoughtful about this is going to be released for the new year or around Christmas time, and happy holidays to everybody. And then we get back, and we're like, yeah, yeah, yeah, we can totally drop the facade. [laughs] We're finally back from vacation. And this is us, and this is real. +CHRIS: Date math is so hard. It just drains me entirely to even try and figure out when episodes are going to actually land. And then when we get here, also, you know, I want to talk about the fact that there was vacation and things, and the realities of the work, and the ebb and flow of life. So here we are. +STEPH: Same. Yeah, I love it. Because I'm in a similar spot where I took two weeks off, which was phenomenal. That's actually sticking to one of the things we talked about, for one of the things I'm looking to do is where I take just more time off. And so having the two weeks was wonderful. +It was also really helpful because the client team that I'm working with also shut down around the end of the year. So they took ten days off as well. So I was like, well, that's a really good sign of encouragement that I should also just shut down since I can. So it's been delightful. +And I have very little tech stuff to share because I've just been doing lots of other fun things and reading fiction, and catching up with friends and family, and trying out new recipes. That's been pretty much my last two weeks. Oh, and walks with Utah. His training is going so well where we're starting to walk off-leash on trails. And that's been awesome. +CHRIS: Wow, that's a big upgrade right there. +STEPH: Yeah, we're still working on that moving perimeter so he knows how far he can go. Before then, he needs to stop and check on me. But he's getting pretty good where he'll bolt ahead, but then he'll stop, and he'll look at me, and then he'll wait till I catch up. And then he'll bolt ahead again. It's really fun. +CHRIS: I like that that's the version of it that we're going for. This is not like you're going to walk alongside me on the trail; it's you're obviously going to run some distance out. As long as you check back in once every 20 feet, we're good; that’s fine. +Any particularly good books, or recipes, or talks with friends to go with that category? But that one's probably a little more specific to you. +STEPH: [laughs] Yes. There are two really good books that I read over the holidays. They're both by the same author. So I get a lot of books from my mom. She'll often pick up a book, and once she's done with it, she'll drop it off to me or vice versa. +So the one that she shared with me is called The Midnight Library. It's written by Matt Haig, H-A-I-G. And it's a very interesting story. It's a bit sad where it's about a woman who decides that she no longer wants to live. And then, when she moves in that direction to go ahead and end her life, she ends up in this library. +And in the library, every time she has made a different decision or made a decision in life, then there is a new book written about what that life is like. So then she has an opportunity to go explore all of these lives and see if there's a better life out there for her. It is really interesting. I highly recommend it. +CHRIS: Wow. I mean, that started with, I'm going to be honest, a very heavy premise. But then the idea that's super interesting. I would, actually...I think I might read that. I tend to just read sci-fi. This is broadly in the space, but that is super interesting. +There's an image that comes to mind actually as you described that. It's from Tim Urban, who's also known as Wait But Why. I think he posts under that both on Twitter, and then I think he has a blog or something to that effect. +But the image is basically like, all of the timelines that you could have followed in your life. And everybody thinks about like, from this moment today. Man, I think about all of the different versions of me that could exist today. But we don't think about the same thing moving forward in time. Like, what are all the possibilities in front of me? +And what you're describing of this person walking around in a library and each book represents a different fork in the road from moving forward is such an interesting idea. And I think a positive reframing of any form of regret or looking back and being like, what if I had gone the other way? It's like, yeah, but forward in time, though. I'm very intrigued by this book. +STEPH: Yeah, it's really good. It definitely has a strong It's a Wonderful Life vibe. Have you ever watched that movie? +CHRIS: Yes, I have. +STEPH: So there's a lot of that idea of regret. And what if I had lived differently and then getting to explore? But in it's A Wonderful Life, he just explores the one version. And in the book, she's exploring many versions. +So it's really neat to be like, well, what if I'd pursued this when I was younger, had done this differently? Or what if I got coffee instead of tea? There are even small, little choices that then might impact you being a different person at a point in time. +The other book that I read is by the same author because I enjoyed Midnight Library so much that I happened to see one of his other books. So I picked it up. And it's called How to Stop Time. And it's about an individual who essentially lives a very long time. +And there are several people in the world that are like this, but he lives for centuries. But he doesn't age, or he ages incredibly slowly, at a rate that where say that he's 100 years old, but he'll still look 16 years old. And it's very good. It's very interesting. +It's a bit more sad and melancholy than I typically like to read. So that one's good. But I will add that even though I described the first one, it has a sad premise; I found The Midnight Library a little more interesting and uplifting versus the other one I found a bit more sad. +CHRIS: All right. Excellent additional notes in the reading list here. So you can opt like, do you want a little bit more somber, or do you want to go a little more uplifting? Yeah, It's a Wonderful Life path being like, starts in a complicated place but don't worry, we'll get you there in the end. +STEPH: But I've learned I have to be careful with the books that I pick up because I will absorb the emotions that are going on in that book. And it will legit affect me through the week or as I'm reading that book. So I have to be careful of the books that I'm reading. [laughs] Is that weird? Do you have the same thing happen for when you're reading books? +CHRIS: It's interesting. I don't think of it with books as much. But I do think of it with TV shows. And so my wife and I have been very intentional when we've watched certain television shows to be like, we're going to need something to cut the intensity of this show. +And the most pointed example we had was we were watching Breaking Bad, which is one of the greatest television shows of all time but also just incredibly heavy and dark at times, kind of throughout. And so we would watch an episode of Breaking Bad. And then, as a palate cleanser, we would watch an episode of Malcolm in the Middle. +And so we saw the same actor but in very different facets of his performance arc and just really softened things and allowed us to, frankly, go to bed after that be able to sleep and whatnot but less so with reading. So I find it interesting that I have that distinction there. +STEPH: Yeah, that is interesting. Although I definitely feel that with movies and shows as well. Or if I watch something heavy, I'm like, great, what's on Disney? [laughs] I need to wash away some of that so I can watch something happy and go to sleep. +You also asked about recipes because I mentioned that's something I've been doing as well. There's a lot of plant-based books that I've picked up because that's really my favorite type of thing to make. So that's been a lot of fun. So yeah, a lot of cooking, a lot of reading. How about you? What else is going on in your world? +CHRIS: Well, actually, it's a super exciting time for Sagewell Financial, the company that I've joined. We are closing our seed financing round, which the whole world of venture capital is a novel thing that I'm still not super involved in that part of the process. But it has been really interesting to watch it progress, and evolve, and take shape. But at this point, we are closing our seed round. Things have gone really well. +And so we're in a position to actually start hiring, which is a whole thing to do, in particular, within the engineering group. We're hiring, I think, throughout the company, but my focus now will be bringing a few folks into the engineering team. And yeah, just trying to do that and do that well, do that intentionally, especially for the size of the team that we have now, the sort of work that we're doing, et cetera, et cetera. +But if anyone out there is listening, we are looking for great folks to join the team. We are Ruby on Rails, Inertia, TypeScript. If you've listened to the show anytime recently, you've heard me talk about the tech stack plenty. +But I think we're trying to do something very meaningful and help seniors manage finance, which is a complicated and, frankly, very underserved space. So it's work that I deeply believe in, and I think we're doing a good job at it. And I hope to do even a better job over time. So if that's at all interesting, definitely reach out to me. +But probably in the coming weeks, you'll hear me talk more and more about hiring and technical interviews and all of those sorts of things. I got to ramp myself back up on that entire world, which is really one of those things that you should always be doing is the thought that I have in my head. Now that I'm in a position to be hiring, I wish I'd been half-hiring for the past three months, but I'll figure it out. It'll be fine. +STEPH: That's such a big undertaking. Everything you're saying resonates, but also, it's like that's a lot of hard work. So if you're not in that state of really being ramped up for hiring, I understand why that would be on the backburner. And yeah, I'm excited to hear more. +I've gotten to hear some more of the product details about Sagewell, but I don't think we've really talked about those features here on the show. So I would love it if we brought some more of the feature work and talked about specifically what the application does. +I am intrigued speaking of how much energy goes into hiring. Where are you at in terms of how much...like, are there any particular job boards that you're going for? Or what's your current approach to hiring? +CHRIS: Oh, that's a great question. I have tweeted once into the world. I have a draft of a LinkedIn post. This is very much I'm figuring out as I go. It's sort of the nature of a startup as we have so many different things to do. +And frankly, even finding the time to start thinking about hiring means I'm taking time away from building features and growing out other aspects. So it's definitely a necessary thing that we're doing at this point in time. +But basically, everything we're doing is just in time compiling and figuring out what are the things that are semi-urgent right now? And to be honest, I like that energy overall. I've always had in the back of my mind that I like this sort of work and this space, especially if you can do it intentionally. +It shouldn't feel like everything's on fire all the time, but it should feel like a lot of constraints that force you to make decisions quickly, which, if we're being honest, I think that's something that is not my strongest suit. So it's something that I'm excited to grow that muscle as part of this work. +But so, with that in mind, at this point, my goal is to just start getting the word out there into the world that we are looking to hire and get people interested and then, from there, build out what's the interview process going to look like? I will let you know when we get there; I will. I will figure that out. +But it's not something that I've...I haven't actually very intentionally thought about all of this. Because if I were to do that, it would delay the amount of time until I actually say into the world, "Hey, we're hiring." So I very purposely was like, I just need to say this into the world and then continue doing the next steps in that process. +I'm prone to the perfect is the enemy of the good just trying to like, I want to have a complete plan and a 27-step checklist, and a Gantt chart, and a burndown. And before I take any first action and really trying to push back, I'm going to be like, no, no, just do something, just take a step in the right direction. +There's actually a blog post that comes to mind, which is by Dave Rupert, who is a former guest on this podcast. It was wonderful getting to interview him. But he wrote a blog post. The title of it is Do the Next Right, which is a line from a song in the movie Frozen 2, I believe. He is like, all right, stick with me here. And I know this is a movie for kids, maybe. But also, this is a very meaningful song. +And he framed it in a way that actually was surprisingly impactful to me. And it's that idea that I'm holding on to of you can't do it all, and you can't do it perfectly. Just do the next right thing. That's what you're going to do. So we'll link to that blog post in the show notes. But that's kind of where I'm at. +STEPH: I love that. I'm looking forward to reading that because that has been huge for me. I used to be held back by that idea of perfection. But then I realized other people were getting more work done more quickly. And so I was like, huh, maybe there's something to this just doing the next thing versus waiting for perfection that is really the right path. +So, how do folks reach out to you? Should they reach out to you on Twitter or email? What's best for you? +CHRIS: Oh yeah, Twitter. This is all probably going to be said at the end of the show as well. But Twitter @christoomey. ctoomey.com is my blog. I'm on GitHub. I make it very easy to contact me because I haven't regretted that up to this point in my life. +So basically, anywhere you find me on the internet, you will be able to email me or DM me or any of the things. I'm going to see how long I can hold on to that. I want to hold on to that forever. I want just a very open-door policy. So that's where I'm at right now, but any of those starting points. +And bikeshed.fm website will somehow link to me in any of the various forums, and they're all kind of linked to each other, so any of those are fine. I will happily take inquiries via any of the channels. +STEPH: Cool. Well, I'm excited to hear about how it goes. +CHRIS: Me too, frankly. But in a very small bit of little tech news or tech happenings from my holiday time, this was actually just before I started to go on break for the holidays. I had noticed that the test suite was getting very slow, like very, very slow but on my machine. +It was getting a little bit slow on CI, but the normal amount where we just keep adding new things. And we're adding a lot of feature specs because we want to have that holistic coverage over the whole application, and we can, so for now, we're doing that. But our spec suite had gotten up to six-ish minutes on CI and had a couple of other things. We have some linting and some TypeScript and things like that. +But on my machine, it was very slow. So I hadn't run the full spec suite in a long time. But I knew that running any individual spec took surprising amounts of time. And in the back of my head, I was like; I guess I hadn't configured Spring. That seems weird. I probably would have done that, but whatever. +And I'd never pushed on it more until one day I ran the specs. I ran one model spec, and it took 30 seconds or something like that. And I was like, well, that's absurd. And so I started to look into it. I did some scanning around the internet. +There was a wonderful post on the Giant Robots blog about how to look through things from Mike Wenger, a wonderful former thoughtboter. Unfortunately, none of the tips in there were anything meaningful for me. Everything was as I expected it to be. So I set it down. +And there were a couple of times that this happened to me where I'd be like, this is frustrating. I need to look into this a little bit more, but it was never worth investing more time. But I mentioned it in passing to one of the other developers on the team. And as a holiday gift to me, this person discovered the solution. +So let me describe a little bit more of what we've got working on here. On CI, which in theory is less powerful than my new, fancy M1 MacBook, on CI, we take about six minutes for the test suite. On my computer, it was taking 28 minutes and 30 seconds. So that's what we're working with. The factories are all doing normal things. We're not creating way too many database records or anything like that. So any thoughts, anything that you would inspect here? +STEPH: Ooh, you've already listed a number of good things that I would check. +CHRIS: Yeah, I took all the easy ones off the list. So this is a hard question at this point. To be clear, I had no ideas. +STEPH: Could you tell if there's a difference if it's like the boot-up time versus the actual test running? +CHRIS: Did that check; it is not the boot-up time. It is something that is happening in the process of running an individual spec. +STEPH: No, I'm drawing a blank. I can't think of what else I would check from there. +CHRIS: It's basically where I was at. Let me give you one additional piece of data, see if it does anything for you. I noticed that it happened basically whenever executing any factory. So I'd watch the logs. And if I create this record, it would do roughly what I expect it to. +It would create the record and maybe one or two associated records because that's how Factory Bot works. But it wasn't creating a giant cascade or waterfall of records under the hood. If we create a product, the product should have an associated user. So we'll see a product and a user insert. But for some reason, that line create whatever database record was very, very slow. +STEPH: Yeah, it's a good point, looking at factories because that's something I've noticed in triaging other tests is that I will often check to see how many records are created at a certain point because I've noticed there's a test where I think only one record is created, but I'll see 20. And that's an interesting artifact. But you're not running into that. But it sounds like there's more either some callback or transaction or something that's getting hung up and causing things to be slow. +CHRIS: I love those ideas. I didn't even know those were sort of ideas in the back of my head. I didn't know how to even try and chase that down. There was nothing in the logs. I couldn't see anything. And again, I just kept giving up. But again, this other developer on the team found the answer. But at this point, I'll just share the answer because I think we've run out of the good bits of the trivia. +It turns out bcrypt was the answer. So password-hashing was incredibly slow on my machine. What was interesting is I mentioned this to the other developer because they also have an M1. But there are three of us working on the project. The third developer does not have the M1 architecture. So that was an interesting thing. I was like, I feel like this maybe is a thing because we're both experiencing this, but the other developer isn't. +So it turns out bcrypt is wildly slow on the M1 architecture, which is sort of interesting as an artifact of like, what is password hashing, and how does it work? And in normal setups, I think the way it works is Devise will say by default, "We're going to do 12 runs of bcrypt." So like take the password, put it into the hashing algorithm, take the output, put it back into the hashing algorithm, and do that loop 12 times or whatever. +In test mode, it often will configure it to just run once, but it will still use the password hashing. Turns out even that was too slow for us. So we in test mode enabled it so that the password hashing algorithm was just the password. Don't do anything. Just return it directly. Turn off bcrypt; it's too painful for us. But it was very interesting to see that that was the case. +STEPH: Yeah, I don't like that answer. [laughs] I'm not a fan. That is interesting and tricky. And I feel like the only way I would have found that...I'm curious how they found it because I feel like at that point, I would have started outputting something to figure out, okay, where is the slow process? What's the thing that's taking so long to return? +And if I can't see tailing the test logs, then I would start just using a PUT statement to figure out what's taking a long time? And start trying to troubleshoot from there. So I'm curious, do you know how they identified that was the core issue? +CHRIS: Yes, actually. I'm looking back at the pull requests right now. And I'm mentioning that this was related to the M1 architecture, but I don't think that's actually true because the blog post that they're linking to is Collective Idea blog post: Tests Oddly Slow? Might be bcrypt. And then there's a related Rails issue. +They used TestProf, which is a process that you can run that will examine, I think the stack trace and say where are we spending the most time? And from that, they were able to see it looks like it's at the point where we're doing bcrypt. And so that's the answer. +As an aside, my test suite went from 28 minutes and 30 seconds to 1 minute and 30 seconds with this magical speed up. +STEPH: Nice. That's a great idea, TestProf. I don't know if I've used that tool. It rings a bell. But that's an awesome sales pitch for using TestProf. +CHRIS: Similarly, I don't think I'd ever use it before. But it truly was this wonderful holiday gift. Because the minute I switched over to this branch, I was like, oh my God, the tests are so fast. I have one of those fancy, new fast computers, [laughs] and now they're so fast. +STEPH: Wait, you had to switch to a branch? I figured it was something that you had to do special on your machine. So I'm intrigued how they fixed it for you, and then you switched to a branch and saw the speed increase. +CHRIS: So they opened a pull request. And that pull request had the change in the code. So it was a code-level configuration to say, "Hey, Devise, when you do the password hashing thing, maybe just don't, maybe be easy for a moment," [laughter] but only in the test configuration. So all I had to do was check out the branch, and then that configuration was part of the Rails helper setup, and then we were good to go from there. +I added an extra let me be terrified about this because the idea of not hashing passwords in production is terrifying. So let me raise...I put a couple of different guards against like, this should only ever run in test. I know it's in the spec support directory, so it shouldn't. Let me just add some other guards here just to superduper make sure we still hash passwords in production. +STEPH: Devise has a bcrypt chill mode. Good to know. [laughs] And I like all the guards you put in place too. +CHRIS: Yeah, it was really frankly such a relief to get that back to normal, is how I would describe it. But yeah, that's a fun little testing, and password hashing, and little adventure that I get to go on. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: So I have something that I've been wanting to ask you, and it's not tech-related. But we can make this personal and work however we want to tackle it. But there is a previous episode where we read a listener question from Brian about their self-diagnosed toxic trait being large pull requests. And Brian was being playful with the use of the term toxic trait. But it got me thinking, it's like, well, what is my toxic trait? +And it seems like a fun twist on you, and I aren't really big on New Year's Eve resolutions. And in fact, I think you and I are more like if we're interested in achieving a goal, we'd rather focus on building a habit versus this specific, ambiguous we're going to publish ten blogs this year. But rather, I'd rather sit down and write for 15 minutes each day. +And it seemed like a fun twist instead of thinking about what are my toxic traits, personal, at work? Large pull request is a really fun example. So I'll let you choose. I can go first, or you can go first, but I'm excited to hear your thoughts on this one. +CHRIS: I think I've been talking too much. So let's have you go first at this point/ also, I want a few more seconds to think about my toxic trait. +STEPH: [laughs] All right, I have a couple. So that's an interesting point start there [laughs], but here we are. So I was even bold because I asked other people. Because I'm like, well, if I'm going to be fully self-aware, I can't just...I might lie to myself. So I'm going to have to ask some other people. So I asked other folks. +And my personal toxic trait is I am tardy. I am that person who I love to show up 5, 10, 15 minutes late. It's who I am. I don't find it a problem, but it often bothers other people. So that is my informed toxic trait. That might be a strong term for it. But that's the one that gives people the most grief. +CHRIS: Interesting. I do find the framing of I don't find my own tardiness to be a problem as a really interesting sort of lens on it. But okay, it's okay. +STEPH: I see it as long as I'm getting really good quality time with someone; if I'm five minutes late, I'm five minutes late. I think the voice going high means I'm a little defensive. [laughs] +CHRIS: But at least you're self-aware about all of these aspects. [laughs] That's critical. +STEPH: I am self-aware, and most of the people in my life are also self-aware, although I do correct that behavior for work. That feels more important that I be on time for everything because I don't want anyone to feel that I am not valuing their time. But when it comes to friends and family, they thankfully accept me for who I am. +But then, on the work note, I started thinking about toxic traits there. And the one I came up with is that I'm a pretty empathetic person. And there's something that I learned that's called toxic empathy. And it's when you let people's emotions hijack your own emotions, or you'll prioritize someone else's physical or mental health over your own. So, for example, it could be letting another person's anxiety and stress keep you from getting your current tasks and responsibilities done. +And there's a really funny tweet that I saw where someone says, "Hey, can I vent to you about something?" And the first person telling it from their perspective they're crying in the middle of a breakdown. And they're like, "Yeah, sure, what's up?" And I felt seen by that tweet. I was like, yeah; this seems like something I would do. [laughs] +So over time, as something I'm aware of about myself, I've learned to set more boundaries and only keep relationships where equal support is given to both individuals. +And this circles back to the book anecdote that I shared where I had to be careful about the books that I read because they can really affect my mood based on how the characters are doing in that book. So yeah, that's mine. I have one other one that I want to talk about. But I'm going to pause there so you can go. +CHRIS: Okay, fun. [laughs] This is fun. And it is a challenging mental exercise. But it is also, I don't know, vulnerable, and you have to look inside and all that. I think I poked at one earlier on as we were talking, but the idea of perfect is the enemy of the good. And I don't mean this in the terrible like; what’s your worst trait in a job interview? And you're like, "I'm a perfectionist." I don't mean it in that way. +I mean, I have at times struggled to make progress because so much of me wants to build the complete plan, and then very meticulously worked through in exactly the order that I define, sort of like a waterfall versus agile sort of thing. +And it is an ongoing very intentional body of work for me to try and break myself off those habits to try and accept what's the best thing that I can do? How can I move forward? How can I identify things that I will regret later versus things that are probably fine? They're little messes that I can clean up, that sort of thing. +And even that construing it as like there's a good choice and a bad choice, and I'm trying to find the perfect choice. It's like almost nothing in the world actually falls into that shape. So perfect is the enemy of the good is a really useful phrase that I've held onto that helps me. +And it's like, aiming for that perfection will cause you to miss the good that is available. And so, trying to be very intentional with that is the work that I'm doing. But that I think is a toxic trait that I have. +STEPH: I really like what you just said about being able to identify regrets. That feels huge. If you can look at a moment and say, "I really want to get all this done. I will regret if I don't do this, but the rest of it can wait," that feels really significant. +So the other one that I wanted to talk about is actually one that I feel like I've overcome. So this one makes me happy because I feel like I'm in a much better space with it, but it's negative self-talk. And it's essentially just how you treat yourself when you make a mistake. Or what's your internal dialogue throughout the day? +And I used to be harsh on myself. If I made a mistake, I was upset, I was annoyed with myself, and I wouldn't have a kind voice. And I don't know if I've shared this with you. But over time, I've gotten much better at that. +And what has really helped me with it is instead of talking to myself in an unkind voice, I talk to myself how someone who loves me will talk to me. I'm not going to talk to a friend in a really terrible, mean voice, and I wouldn't expect them to talk to me. +So I channel someone that I know is very positive and supportive of me. And I will frame it in that context. So then, when I make a mistake, it's not a big deal. And I just will say kind things to myself or laugh about it and move through it. +And I found that has been very helpful and also funny and maybe a little embarrassing at times because when pairing, I will talk out loud to myself. And so I'll do something silly, and I'll laugh. I'm like, "Oh, Stephanie," that was silly. And the other person hears me say that. [laughs] So it's a little entertainment for them too, I suppose. +CHRIS: Having observed it, it is charming. +STEPH: It's something that I've noticed that a lot of people do, and we don't talk about a lot. I mean, there's imposter syndrome. People will talk about that. But we don't often talk about how critical we are of ourselves. +It's something that I will talk to people who I highly admire and just think they're incredibly good at what they do. And then when they give me a glimpse into how they think about themselves at times or how they will berate themselves for something they have done or because they didn't sit down for that 15 minutes and write per day, then it really highlights. +And I hope that if we talk about this more, the fact that people tend to have such a negative inner critical voice, that maybe we can encourage people to start filtering that voice to a more kind voice and more supportive voice, and not have this unhelpful energy that's holding us back from really enjoying our work and being our best self. +CHRIS: That's so interesting to hear you say all of that for one of your traits because it's very similar to the last one for myself, which is I find that I do not feel safe unless (This is going to sound perhaps boastful, and I definitely do not mean it as boastful.) but unless I'm perfect. I guess the standard that I hold myself to versus the standard that I hold others to are wildly different. +Of course, for other people, yes, bugs will get into the code, or they may misunderstand something, or they may miss communicate something, or they may forget something. But if I do that, I feel unsafe, which is a thing that I've slowly come to recognize. I'm like, well, that shouldn't be true because that's definitely not how I feel about other people. That's not a reasonable standard to hold. +But that needing to be perfectly secured on all fronts and have just this very defensible like, yeah, I did the work, and it's great, and that's all that's true in the world. That's not reasonable. I'm never going to achieve that. And so, for a long time, there have been moments where I just don't feel great as a result of this, as a result of the standard that I'm trying to hold myself to. +But very similarly, I have brought voices into my head. In my case, I've actually identified a board of directors which are random actual people from my world but then also celebrities or fake people, and I will have conversations with them in my head. And that is a true thing about me that I'm now saying on the internet, here we are. +STEPH: [laughs] +CHRIS: And I'm going to throw it out there. It is fantastic. It is one of my favorite things that I have in my world. As a pointed example of a time that I did this, I was running a race at one point, which I occasionally will run road races. I am not good at it at all. +But I was running this particular race. It was a five-mile January race a couple of years back. And I was getting towards the end, and I was just going way faster than I normally do. I was at the four-mile mark, and I was well ahead of pace. +I was like, what is this? I was on track to get a personal record. I was like, this is exciting. But I didn't know if I could finish. And so I started to consult the board of directors and just check in with them and see what they would think about this. +And I got weirdly emotional, and it was weirdly real is the thing that was very interesting, not like I actually believed that these people were running with me or anything of that nature. But the emotions and the feelings that I was able to build up in that moment were so real and so powerful and useful to me that it was just like, oh, okay, yeah, that's a neat trick. I'm going to hold on to that one. +And it has been continuously useful moving forward from that of like, yeah, I can just have random conversations with anyone and find useful things in that and then use that to feel better about how I'm working. +STEPH: I so love this idea. And I'm now thinking about who to put on my board of directors. [laughs] +CHRIS: I'm telling you, everybody should have one. As I'm saying this, there is definitely a portion of me that is very self-conscious that I'm saying this on the internet because this is probably one of the weirdest things that I do. +STEPH: [laughs] +CHRIS: But it is so valuable. And it's one of those like; I like getting over that hump of like, well, this is an odd little habit that I have, but the utility that I get from it and the value is great. So highly recommend it. +It's a fun game of who gets to go on your board. You can change it out every year. And it is interesting because the more formed picture that you have of the individual, the more you can have a real conversation with them, and that's fun. +STEPH: So, as I'm working on forming a board of directors, how do you separate? Is it based on one person is running work and one is finance? How does each person have a role? +CHRIS: So there are no rules in this game. [laughs] This is a ridiculous thing that I do. But I find value in it's sort of vaguely the same collection of individuals. Some of them are truly archetypal, even fictitious characters. As long as I can have a picture in my head of them and say, "What would they say in a situation?" +If you're considering, say, moving jobs? What would Arnold Schwarzenegger have to say about that? And you'd be surprised the minute you ask it in your head; your brain is surprisingly good at these things. And it's like, let me paint The Terminator yelling at you to get the new job. +STEPH: [laughs] +CHRIS: Not get to the chopper, but get the new job. And it's surprisingly effective. And so I don't have a compartmentalized like, this is my work crew, this is my life crew. It's a nonsense collection of fake people in my head that I get to talk to. I'm saying this on the internet; here we are. [laughs] +STEPH: That makes sense to me, though, because as you're describing that situation, I do something similar, but I've just never thought about it in these concrete terms where I have someone in mind, and it's a real person in my life who are my confidence person. +They're the one that I know they are very confident. They're going to push for the best deal for themselves. They're going to look out for themselves. They're going to look out for me. They're going to support me. I have that person. And so, even if I can't talk to them in reality, then I will still channel that energy. +And then I have someone else who's like my kind filter, and they're the person that's going to be very supportive. And you make mistakes, and it's not a big deal, and you learn, and you move on. And so I have those different...and in my mind, I just saw them as coaches. +Instead of board of directors, I just see them as different things that I don't see as strong in my character. And so I have these coaches in those particular areas that then I will pull energy from to then bolster myself in a particular way or skill. +This was fun. I'm so glad we talked about this because that is very insightful to you, and for me as well, and to myself. +CHRIS: Yeah, we went deep on this episode. +STEPH: No tech but lots of deep personal insight. +CHRIS: I talked a little bit about bcrypt. [laughs] You can't stop me from talking about tech for an entire episode. But then I also talked about my board of directors and the conversations I have with myself, so I feel like I rounded it out pretty good. +STEPH: It's a very round episode. +CHRIS: Yeah, I agree. And with that roundedness, should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeee!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Happy New Year (for real)! Chris and Steph both took some end-of-year time off to rest and recharge.

+ +

Steph talks about some books she enjoyed, recipes she tried, and trail-walking adventures with her dog, Utah. Chris' company is now in a good position to actually start hiring within the engineering team. He's excited about that and will probably delve into more around the hiring process in the coming weeks.

+ +

Since they aren't really big on New Year's Eve resolutions, Steph and Chris answer a listener question regarding toxic traits inspired by the listener question related to large pull requests and reflect on their own.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Well, spoiler, we actually may have lied in a previous episode when we said, "Hey, happy New Year," because, for us, it was not actually the new year. But this, in fact, is the first episode of the new year that we're recording, that you're hearing. Anyway, this is enough breaking the fourth wall. Sorry, listener.

+ +

STEPH: [laughs]

+ +

CHRIS: Inside baseball, yadda, yadda. I'm doing great. First week back. I took some amount of vacation over the holidays, which was great, recharging, all those sorts of things. But now we're hitting the ground running.

+ +

And I'm actually really enjoying just getting back into the flow of things and, frankly, trying to ramp everything up, which we can probably talk about more in a moment. But how about you? How's your new year kicking off?

+ +

STEPH: I like how much we plan the episodes around when it's going to release, and we're very thoughtful about this is going to be released for the new year or around Christmas time, and happy holidays to everybody. And then we get back, and we're like, yeah, yeah, yeah, we can totally drop the facade. [laughs] We're finally back from vacation. And this is us, and this is real.

+ +

CHRIS: Date math is so hard. It just drains me entirely to even try and figure out when episodes are going to actually land. And then when we get here, also, you know, I want to talk about the fact that there was vacation and things, and the realities of the work, and the ebb and flow of life. So here we are.

+ +

STEPH: Same. Yeah, I love it. Because I'm in a similar spot where I took two weeks off, which was phenomenal. That's actually sticking to one of the things we talked about, for one of the things I'm looking to do is where I take just more time off. And so having the two weeks was wonderful.

+ +

It was also really helpful because the client team that I'm working with also shut down around the end of the year. So they took ten days off as well. So I was like, well, that's a really good sign of encouragement that I should also just shut down since I can. So it's been delightful.

+ +

And I have very little tech stuff to share because I've just been doing lots of other fun things and reading fiction, and catching up with friends and family, and trying out new recipes. That's been pretty much my last two weeks. Oh, and walks with Utah. His training is going so well where we're starting to walk off-leash on trails. And that's been awesome.

+ +

CHRIS: Wow, that's a big upgrade right there.

+ +

STEPH: Yeah, we're still working on that moving perimeter so he knows how far he can go. Before then, he needs to stop and check on me. But he's getting pretty good where he'll bolt ahead, but then he'll stop, and he'll look at me, and then he'll wait till I catch up. And then he'll bolt ahead again. It's really fun.

+ +

CHRIS: I like that that's the version of it that we're going for. This is not like you're going to walk alongside me on the trail; it's you're obviously going to run some distance out. As long as you check back in once every 20 feet, we're good; that’s fine.

+ +

Any particularly good books, or recipes, or talks with friends to go with that category? But that one's probably a little more specific to you.

+ +

STEPH: [laughs] Yes. There are two really good books that I read over the holidays. They're both by the same author. So I get a lot of books from my mom. She'll often pick up a book, and once she's done with it, she'll drop it off to me or vice versa.

+ +

So the one that she shared with me is called The Midnight Library. It's written by Matt Haig, H-A-I-G. And it's a very interesting story. It's a bit sad where it's about a woman who decides that she no longer wants to live. And then, when she moves in that direction to go ahead and end her life, she ends up in this library.

+ +

And in the library, every time she has made a different decision or made a decision in life, then there is a new book written about what that life is like. So then she has an opportunity to go explore all of these lives and see if there's a better life out there for her. It is really interesting. I highly recommend it.

+ +

CHRIS: Wow. I mean, that started with, I'm going to be honest, a very heavy premise. But then the idea that's super interesting. I would, actually...I think I might read that. I tend to just read sci-fi. This is broadly in the space, but that is super interesting.

+ +

There's an image that comes to mind actually as you described that. It's from Tim Urban, who's also known as Wait But Why. I think he posts under that both on Twitter, and then I think he has a blog or something to that effect.

+ +

But the image is basically like, all of the timelines that you could have followed in your life. And everybody thinks about like, from this moment today. Man, I think about all of the different versions of me that could exist today. But we don't think about the same thing moving forward in time. Like, what are all the possibilities in front of me?

+ +

And what you're describing of this person walking around in a library and each book represents a different fork in the road from moving forward is such an interesting idea. And I think a positive reframing of any form of regret or looking back and being like, what if I had gone the other way? It's like, yeah, but forward in time, though. I'm very intrigued by this book.

+ +

STEPH: Yeah, it's really good. It definitely has a strong It's a Wonderful Life vibe. Have you ever watched that movie?

+ +

CHRIS: Yes, I have.

+ +

STEPH: So there's a lot of that idea of regret. And what if I had lived differently and then getting to explore? But in it's A Wonderful Life, he just explores the one version. And in the book, she's exploring many versions.

+ +

So it's really neat to be like, well, what if I'd pursued this when I was younger, had done this differently? Or what if I got coffee instead of tea? There are even small, little choices that then might impact you being a different person at a point in time.

+ +

The other book that I read is by the same author because I enjoyed Midnight Library so much that I happened to see one of his other books. So I picked it up. And it's called How to Stop Time. And it's about an individual who essentially lives a very long time.

+ +

And there are several people in the world that are like this, but he lives for centuries. But he doesn't age, or he ages incredibly slowly, at a rate that where say that he's 100 years old, but he'll still look 16 years old. And it's very good. It's very interesting.

+ +

It's a bit more sad and melancholy than I typically like to read. So that one's good. But I will add that even though I described the first one, it has a sad premise; I found The Midnight Library a little more interesting and uplifting versus the other one I found a bit more sad.

+ +

CHRIS: All right. Excellent additional notes in the reading list here. So you can opt like, do you want a little bit more somber, or do you want to go a little more uplifting? Yeah, It's a Wonderful Life path being like, starts in a complicated place but don't worry, we'll get you there in the end.

+ +

STEPH: But I've learned I have to be careful with the books that I pick up because I will absorb the emotions that are going on in that book. And it will legit affect me through the week or as I'm reading that book. So I have to be careful of the books that I'm reading. [laughs] Is that weird? Do you have the same thing happen for when you're reading books?

+ +

CHRIS: It's interesting. I don't think of it with books as much. But I do think of it with TV shows. And so my wife and I have been very intentional when we've watched certain television shows to be like, we're going to need something to cut the intensity of this show.

+ +

And the most pointed example we had was we were watching Breaking Bad, which is one of the greatest television shows of all time but also just incredibly heavy and dark at times, kind of throughout. And so we would watch an episode of Breaking Bad. And then, as a palate cleanser, we would watch an episode of Malcolm in the Middle.

+ +

And so we saw the same actor but in very different facets of his performance arc and just really softened things and allowed us to, frankly, go to bed after that be able to sleep and whatnot but less so with reading. So I find it interesting that I have that distinction there.

+ +

STEPH: Yeah, that is interesting. Although I definitely feel that with movies and shows as well. Or if I watch something heavy, I'm like, great, what's on Disney? [laughs] I need to wash away some of that so I can watch something happy and go to sleep.

+ +

You also asked about recipes because I mentioned that's something I've been doing as well. There's a lot of plant-based books that I've picked up because that's really my favorite type of thing to make. So that's been a lot of fun. So yeah, a lot of cooking, a lot of reading. How about you? What else is going on in your world?

+ +

CHRIS: Well, actually, it's a super exciting time for Sagewell Financial, the company that I've joined. We are closing our seed financing round, which the whole world of venture capital is a novel thing that I'm still not super involved in that part of the process. But it has been really interesting to watch it progress, and evolve, and take shape. But at this point, we are closing our seed round. Things have gone really well.

+ +

And so we're in a position to actually start hiring, which is a whole thing to do, in particular, within the engineering group. We're hiring, I think, throughout the company, but my focus now will be bringing a few folks into the engineering team. And yeah, just trying to do that and do that well, do that intentionally, especially for the size of the team that we have now, the sort of work that we're doing, et cetera, et cetera.

+ +

But if anyone out there is listening, we are looking for great folks to join the team. We are Ruby on Rails, Inertia, TypeScript. If you've listened to the show anytime recently, you've heard me talk about the tech stack plenty.

+ +

But I think we're trying to do something very meaningful and help seniors manage finance, which is a complicated and, frankly, very underserved space. So it's work that I deeply believe in, and I think we're doing a good job at it. And I hope to do even a better job over time. So if that's at all interesting, definitely reach out to me.

+ +

But probably in the coming weeks, you'll hear me talk more and more about hiring and technical interviews and all of those sorts of things. I got to ramp myself back up on that entire world, which is really one of those things that you should always be doing is the thought that I have in my head. Now that I'm in a position to be hiring, I wish I'd been half-hiring for the past three months, but I'll figure it out. It'll be fine.

+ +

STEPH: That's such a big undertaking. Everything you're saying resonates, but also, it's like that's a lot of hard work. So if you're not in that state of really being ramped up for hiring, I understand why that would be on the backburner. And yeah, I'm excited to hear more.

+ +

I've gotten to hear some more of the product details about Sagewell, but I don't think we've really talked about those features here on the show. So I would love it if we brought some more of the feature work and talked about specifically what the application does.

+ +

I am intrigued speaking of how much energy goes into hiring. Where are you at in terms of how much...like, are there any particular job boards that you're going for? Or what's your current approach to hiring?

+ +

CHRIS: Oh, that's a great question. I have tweeted once into the world. I have a draft of a LinkedIn post. This is very much I'm figuring out as I go. It's sort of the nature of a startup as we have so many different things to do.

+ +

And frankly, even finding the time to start thinking about hiring means I'm taking time away from building features and growing out other aspects. So it's definitely a necessary thing that we're doing at this point in time.

+ +

But basically, everything we're doing is just in time compiling and figuring out what are the things that are semi-urgent right now? And to be honest, I like that energy overall. I've always had in the back of my mind that I like this sort of work and this space, especially if you can do it intentionally.

+ +

It shouldn't feel like everything's on fire all the time, but it should feel like a lot of constraints that force you to make decisions quickly, which, if we're being honest, I think that's something that is not my strongest suit. So it's something that I'm excited to grow that muscle as part of this work.

+ +

But so, with that in mind, at this point, my goal is to just start getting the word out there into the world that we are looking to hire and get people interested and then, from there, build out what's the interview process going to look like? I will let you know when we get there; I will. I will figure that out.

+ +

But it's not something that I've...I haven't actually very intentionally thought about all of this. Because if I were to do that, it would delay the amount of time until I actually say into the world, "Hey, we're hiring." So I very purposely was like, I just need to say this into the world and then continue doing the next steps in that process.

+ +

I'm prone to the perfect is the enemy of the good just trying to like, I want to have a complete plan and a 27-step checklist, and a Gantt chart, and a burndown. And before I take any first action and really trying to push back, I'm going to be like, no, no, just do something, just take a step in the right direction.

+ +

There's actually a blog post that comes to mind, which is by Dave Rupert, who is a former guest on this podcast. It was wonderful getting to interview him. But he wrote a blog post. The title of it is Do the Next Right, which is a line from a song in the movie Frozen 2, I believe. He is like, all right, stick with me here. And I know this is a movie for kids, maybe. But also, this is a very meaningful song.

+ +

And he framed it in a way that actually was surprisingly impactful to me. And it's that idea that I'm holding on to of you can't do it all, and you can't do it perfectly. Just do the next right thing. That's what you're going to do. So we'll link to that blog post in the show notes. But that's kind of where I'm at.

+ +

STEPH: I love that. I'm looking forward to reading that because that has been huge for me. I used to be held back by that idea of perfection. But then I realized other people were getting more work done more quickly. And so I was like, huh, maybe there's something to this just doing the next thing versus waiting for perfection that is really the right path.

+ +

So, how do folks reach out to you? Should they reach out to you on Twitter or email? What's best for you?

+ +

CHRIS: Oh yeah, Twitter. This is all probably going to be said at the end of the show as well. But Twitter @christoomey. ctoomey.com is my blog. I'm on GitHub. I make it very easy to contact me because I haven't regretted that up to this point in my life.

+ +

So basically, anywhere you find me on the internet, you will be able to email me or DM me or any of the things. I'm going to see how long I can hold on to that. I want to hold on to that forever. I want just a very open-door policy. So that's where I'm at right now, but any of those starting points.

+ +

And bikeshed.fm website will somehow link to me in any of the various forums, and they're all kind of linked to each other, so any of those are fine. I will happily take inquiries via any of the channels.

+ +

STEPH: Cool. Well, I'm excited to hear about how it goes.

+ +

CHRIS: Me too, frankly. But in a very small bit of little tech news or tech happenings from my holiday time, this was actually just before I started to go on break for the holidays. I had noticed that the test suite was getting very slow, like very, very slow but on my machine.

+ +

It was getting a little bit slow on CI, but the normal amount where we just keep adding new things. And we're adding a lot of feature specs because we want to have that holistic coverage over the whole application, and we can, so for now, we're doing that. But our spec suite had gotten up to six-ish minutes on CI and had a couple of other things. We have some linting and some TypeScript and things like that.

+ +

But on my machine, it was very slow. So I hadn't run the full spec suite in a long time. But I knew that running any individual spec took surprising amounts of time. And in the back of my head, I was like; I guess I hadn't configured Spring. That seems weird. I probably would have done that, but whatever.

+ +

And I'd never pushed on it more until one day I ran the specs. I ran one model spec, and it took 30 seconds or something like that. And I was like, well, that's absurd. And so I started to look into it. I did some scanning around the internet.

+ +

There was a wonderful post on the Giant Robots blog about how to look through things from Mike Wenger, a wonderful former thoughtboter. Unfortunately, none of the tips in there were anything meaningful for me. Everything was as I expected it to be. So I set it down.

+ +

And there were a couple of times that this happened to me where I'd be like, this is frustrating. I need to look into this a little bit more, but it was never worth investing more time. But I mentioned it in passing to one of the other developers on the team. And as a holiday gift to me, this person discovered the solution.

+ +

So let me describe a little bit more of what we've got working on here. On CI, which in theory is less powerful than my new, fancy M1 MacBook, on CI, we take about six minutes for the test suite. On my computer, it was taking 28 minutes and 30 seconds. So that's what we're working with. The factories are all doing normal things. We're not creating way too many database records or anything like that. So any thoughts, anything that you would inspect here?

+ +

STEPH: Ooh, you've already listed a number of good things that I would check.

+ +

CHRIS: Yeah, I took all the easy ones off the list. So this is a hard question at this point. To be clear, I had no ideas.

+ +

STEPH: Could you tell if there's a difference if it's like the boot-up time versus the actual test running?

+ +

CHRIS: Did that check; it is not the boot-up time. It is something that is happening in the process of running an individual spec.

+ +

STEPH: No, I'm drawing a blank. I can't think of what else I would check from there.

+ +

CHRIS: It's basically where I was at. Let me give you one additional piece of data, see if it does anything for you. I noticed that it happened basically whenever executing any factory. So I'd watch the logs. And if I create this record, it would do roughly what I expect it to.

+ +

It would create the record and maybe one or two associated records because that's how Factory Bot works. But it wasn't creating a giant cascade or waterfall of records under the hood. If we create a product, the product should have an associated user. So we'll see a product and a user insert. But for some reason, that line create whatever database record was very, very slow.

+ +

STEPH: Yeah, it's a good point, looking at factories because that's something I've noticed in triaging other tests is that I will often check to see how many records are created at a certain point because I've noticed there's a test where I think only one record is created, but I'll see 20. And that's an interesting artifact. But you're not running into that. But it sounds like there's more either some callback or transaction or something that's getting hung up and causing things to be slow.

+ +

CHRIS: I love those ideas. I didn't even know those were sort of ideas in the back of my head. I didn't know how to even try and chase that down. There was nothing in the logs. I couldn't see anything. And again, I just kept giving up. But again, this other developer on the team found the answer. But at this point, I'll just share the answer because I think we've run out of the good bits of the trivia.

+ +

It turns out bcrypt was the answer. So password-hashing was incredibly slow on my machine. What was interesting is I mentioned this to the other developer because they also have an M1. But there are three of us working on the project. The third developer does not have the M1 architecture. So that was an interesting thing. I was like, I feel like this maybe is a thing because we're both experiencing this, but the other developer isn't.

+ +

So it turns out bcrypt is wildly slow on the M1 architecture, which is sort of interesting as an artifact of like, what is password hashing, and how does it work? And in normal setups, I think the way it works is Devise will say by default, "We're going to do 12 runs of bcrypt." So like take the password, put it into the hashing algorithm, take the output, put it back into the hashing algorithm, and do that loop 12 times or whatever.

+ +

In test mode, it often will configure it to just run once, but it will still use the password hashing. Turns out even that was too slow for us. So we in test mode enabled it so that the password hashing algorithm was just the password. Don't do anything. Just return it directly. Turn off bcrypt; it's too painful for us. But it was very interesting to see that that was the case.

+ +

STEPH: Yeah, I don't like that answer. [laughs] I'm not a fan. That is interesting and tricky. And I feel like the only way I would have found that...I'm curious how they found it because I feel like at that point, I would have started outputting something to figure out, okay, where is the slow process? What's the thing that's taking so long to return?

+ +

And if I can't see tailing the test logs, then I would start just using a PUT statement to figure out what's taking a long time? And start trying to troubleshoot from there. So I'm curious, do you know how they identified that was the core issue?

+ +

CHRIS: Yes, actually. I'm looking back at the pull requests right now. And I'm mentioning that this was related to the M1 architecture, but I don't think that's actually true because the blog post that they're linking to is Collective Idea blog post: Tests Oddly Slow? Might be bcrypt. And then there's a related Rails issue.

+ +

They used TestProf, which is a process that you can run that will examine, I think the stack trace and say where are we spending the most time? And from that, they were able to see it looks like it's at the point where we're doing bcrypt. And so that's the answer.

+ +

As an aside, my test suite went from 28 minutes and 30 seconds to 1 minute and 30 seconds with this magical speed up.

+ +

STEPH: Nice. That's a great idea, TestProf. I don't know if I've used that tool. It rings a bell. But that's an awesome sales pitch for using TestProf.

+ +

CHRIS: Similarly, I don't think I'd ever use it before. But it truly was this wonderful holiday gift. Because the minute I switched over to this branch, I was like, oh my God, the tests are so fast. I have one of those fancy, new fast computers, [laughs] and now they're so fast.

+ +

STEPH: Wait, you had to switch to a branch? I figured it was something that you had to do special on your machine. So I'm intrigued how they fixed it for you, and then you switched to a branch and saw the speed increase.

+ +

CHRIS: So they opened a pull request. And that pull request had the change in the code. So it was a code-level configuration to say, "Hey, Devise, when you do the password hashing thing, maybe just don't, maybe be easy for a moment," [laughter] but only in the test configuration. So all I had to do was check out the branch, and then that configuration was part of the Rails helper setup, and then we were good to go from there.

+ +

I added an extra let me be terrified about this because the idea of not hashing passwords in production is terrifying. So let me raise...I put a couple of different guards against like, this should only ever run in test. I know it's in the spec support directory, so it shouldn't. Let me just add some other guards here just to superduper make sure we still hash passwords in production.

+ +

STEPH: Devise has a bcrypt chill mode. Good to know. [laughs] And I like all the guards you put in place too.

+ +

CHRIS: Yeah, it was really frankly such a relief to get that back to normal, is how I would describe it. But yeah, that's a fun little testing, and password hashing, and little adventure that I get to go on.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So I have something that I've been wanting to ask you, and it's not tech-related. But we can make this personal and work however we want to tackle it. But there is a previous episode where we read a listener question from Brian about their self-diagnosed toxic trait being large pull requests. And Brian was being playful with the use of the term toxic trait. But it got me thinking, it's like, well, what is my toxic trait?

+ +

And it seems like a fun twist on you, and I aren't really big on New Year's Eve resolutions. And in fact, I think you and I are more like if we're interested in achieving a goal, we'd rather focus on building a habit versus this specific, ambiguous we're going to publish ten blogs this year. But rather, I'd rather sit down and write for 15 minutes each day.

+ +

And it seemed like a fun twist instead of thinking about what are my toxic traits, personal, at work? Large pull request is a really fun example. So I'll let you choose. I can go first, or you can go first, but I'm excited to hear your thoughts on this one.

+ +

CHRIS: I think I've been talking too much. So let's have you go first at this point/ also, I want a few more seconds to think about my toxic trait.

+ +

STEPH: [laughs] All right, I have a couple. So that's an interesting point start there [laughs], but here we are. So I was even bold because I asked other people. Because I'm like, well, if I'm going to be fully self-aware, I can't just...I might lie to myself. So I'm going to have to ask some other people. So I asked other folks.

+ +

And my personal toxic trait is I am tardy. I am that person who I love to show up 5, 10, 15 minutes late. It's who I am. I don't find it a problem, but it often bothers other people. So that is my informed toxic trait. That might be a strong term for it. But that's the one that gives people the most grief.

+ +

CHRIS: Interesting. I do find the framing of I don't find my own tardiness to be a problem as a really interesting sort of lens on it. But okay, it's okay.

+ +

STEPH: I see it as long as I'm getting really good quality time with someone; if I'm five minutes late, I'm five minutes late. I think the voice going high means I'm a little defensive. [laughs]

+ +

CHRIS: But at least you're self-aware about all of these aspects. [laughs] That's critical.

+ +

STEPH: I am self-aware, and most of the people in my life are also self-aware, although I do correct that behavior for work. That feels more important that I be on time for everything because I don't want anyone to feel that I am not valuing their time. But when it comes to friends and family, they thankfully accept me for who I am.

+ +

But then, on the work note, I started thinking about toxic traits there. And the one I came up with is that I'm a pretty empathetic person. And there's something that I learned that's called toxic empathy. And it's when you let people's emotions hijack your own emotions, or you'll prioritize someone else's physical or mental health over your own. So, for example, it could be letting another person's anxiety and stress keep you from getting your current tasks and responsibilities done.

+ +

And there's a really funny tweet that I saw where someone says, "Hey, can I vent to you about something?" And the first person telling it from their perspective they're crying in the middle of a breakdown. And they're like, "Yeah, sure, what's up?" And I felt seen by that tweet. I was like, yeah; this seems like something I would do. [laughs]

+ +

So over time, as something I'm aware of about myself, I've learned to set more boundaries and only keep relationships where equal support is given to both individuals.

+ +

And this circles back to the book anecdote that I shared where I had to be careful about the books that I read because they can really affect my mood based on how the characters are doing in that book. So yeah, that's mine. I have one other one that I want to talk about. But I'm going to pause there so you can go.

+ +

CHRIS: Okay, fun. [laughs] This is fun. And it is a challenging mental exercise. But it is also, I don't know, vulnerable, and you have to look inside and all that. I think I poked at one earlier on as we were talking, but the idea of perfect is the enemy of the good. And I don't mean this in the terrible like; what’s your worst trait in a job interview? And you're like, "I'm a perfectionist." I don't mean it in that way.

+ +

I mean, I have at times struggled to make progress because so much of me wants to build the complete plan, and then very meticulously worked through in exactly the order that I define, sort of like a waterfall versus agile sort of thing.

+ +

And it is an ongoing very intentional body of work for me to try and break myself off those habits to try and accept what's the best thing that I can do? How can I move forward? How can I identify things that I will regret later versus things that are probably fine? They're little messes that I can clean up, that sort of thing.

+ +

And even that construing it as like there's a good choice and a bad choice, and I'm trying to find the perfect choice. It's like almost nothing in the world actually falls into that shape. So perfect is the enemy of the good is a really useful phrase that I've held onto that helps me.

+ +

And it's like, aiming for that perfection will cause you to miss the good that is available. And so, trying to be very intentional with that is the work that I'm doing. But that I think is a toxic trait that I have.

+ +

STEPH: I really like what you just said about being able to identify regrets. That feels huge. If you can look at a moment and say, "I really want to get all this done. I will regret if I don't do this, but the rest of it can wait," that feels really significant.

+ +

So the other one that I wanted to talk about is actually one that I feel like I've overcome. So this one makes me happy because I feel like I'm in a much better space with it, but it's negative self-talk. And it's essentially just how you treat yourself when you make a mistake. Or what's your internal dialogue throughout the day?

+ +

And I used to be harsh on myself. If I made a mistake, I was upset, I was annoyed with myself, and I wouldn't have a kind voice. And I don't know if I've shared this with you. But over time, I've gotten much better at that.

+ +

And what has really helped me with it is instead of talking to myself in an unkind voice, I talk to myself how someone who loves me will talk to me. I'm not going to talk to a friend in a really terrible, mean voice, and I wouldn't expect them to talk to me.

+ +

So I channel someone that I know is very positive and supportive of me. And I will frame it in that context. So then, when I make a mistake, it's not a big deal. And I just will say kind things to myself or laugh about it and move through it.

+ +

And I found that has been very helpful and also funny and maybe a little embarrassing at times because when pairing, I will talk out loud to myself. And so I'll do something silly, and I'll laugh. I'm like, "Oh, Stephanie," that was silly. And the other person hears me say that. [laughs] So it's a little entertainment for them too, I suppose.

+ +

CHRIS: Having observed it, it is charming.

+ +

STEPH: It's something that I've noticed that a lot of people do, and we don't talk about a lot. I mean, there's imposter syndrome. People will talk about that. But we don't often talk about how critical we are of ourselves.

+ +

It's something that I will talk to people who I highly admire and just think they're incredibly good at what they do. And then when they give me a glimpse into how they think about themselves at times or how they will berate themselves for something they have done or because they didn't sit down for that 15 minutes and write per day, then it really highlights.

+ +

And I hope that if we talk about this more, the fact that people tend to have such a negative inner critical voice, that maybe we can encourage people to start filtering that voice to a more kind voice and more supportive voice, and not have this unhelpful energy that's holding us back from really enjoying our work and being our best self.

+ +

CHRIS: That's so interesting to hear you say all of that for one of your traits because it's very similar to the last one for myself, which is I find that I do not feel safe unless (This is going to sound perhaps boastful, and I definitely do not mean it as boastful.) but unless I'm perfect. I guess the standard that I hold myself to versus the standard that I hold others to are wildly different.

+ +

Of course, for other people, yes, bugs will get into the code, or they may misunderstand something, or they may miss communicate something, or they may forget something. But if I do that, I feel unsafe, which is a thing that I've slowly come to recognize. I'm like, well, that shouldn't be true because that's definitely not how I feel about other people. That's not a reasonable standard to hold.

+ +

But that needing to be perfectly secured on all fronts and have just this very defensible like, yeah, I did the work, and it's great, and that's all that's true in the world. That's not reasonable. I'm never going to achieve that. And so, for a long time, there have been moments where I just don't feel great as a result of this, as a result of the standard that I'm trying to hold myself to.

+ +

But very similarly, I have brought voices into my head. In my case, I've actually identified a board of directors which are random actual people from my world but then also celebrities or fake people, and I will have conversations with them in my head. And that is a true thing about me that I'm now saying on the internet, here we are.

+ +

STEPH: [laughs]

+ +

CHRIS: And I'm going to throw it out there. It is fantastic. It is one of my favorite things that I have in my world. As a pointed example of a time that I did this, I was running a race at one point, which I occasionally will run road races. I am not good at it at all.

+ +

But I was running this particular race. It was a five-mile January race a couple of years back. And I was getting towards the end, and I was just going way faster than I normally do. I was at the four-mile mark, and I was well ahead of pace.

+ +

I was like, what is this? I was on track to get a personal record. I was like, this is exciting. But I didn't know if I could finish. And so I started to consult the board of directors and just check in with them and see what they would think about this.

+ +

And I got weirdly emotional, and it was weirdly real is the thing that was very interesting, not like I actually believed that these people were running with me or anything of that nature. But the emotions and the feelings that I was able to build up in that moment were so real and so powerful and useful to me that it was just like, oh, okay, yeah, that's a neat trick. I'm going to hold on to that one.

+ +

And it has been continuously useful moving forward from that of like, yeah, I can just have random conversations with anyone and find useful things in that and then use that to feel better about how I'm working.

+ +

STEPH: I so love this idea. And I'm now thinking about who to put on my board of directors. [laughs]

+ +

CHRIS: I'm telling you, everybody should have one. As I'm saying this, there is definitely a portion of me that is very self-conscious that I'm saying this on the internet because this is probably one of the weirdest things that I do.

+ +

STEPH: [laughs]

+ +

CHRIS: But it is so valuable. And it's one of those like; I like getting over that hump of like, well, this is an odd little habit that I have, but the utility that I get from it and the value is great. So highly recommend it.

+ +

It's a fun game of who gets to go on your board. You can change it out every year. And it is interesting because the more formed picture that you have of the individual, the more you can have a real conversation with them, and that's fun.

+ +

STEPH: So, as I'm working on forming a board of directors, how do you separate? Is it based on one person is running work and one is finance? How does each person have a role?

+ +

CHRIS: So there are no rules in this game. [laughs] This is a ridiculous thing that I do. But I find value in it's sort of vaguely the same collection of individuals. Some of them are truly archetypal, even fictitious characters. As long as I can have a picture in my head of them and say, "What would they say in a situation?"

+ +

If you're considering, say, moving jobs? What would Arnold Schwarzenegger have to say about that? And you'd be surprised the minute you ask it in your head; your brain is surprisingly good at these things. And it's like, let me paint The Terminator yelling at you to get the new job.

+ +

STEPH: [laughs]

+ +

CHRIS: Not get to the chopper, but get the new job. And it's surprisingly effective. And so I don't have a compartmentalized like, this is my work crew, this is my life crew. It's a nonsense collection of fake people in my head that I get to talk to. I'm saying this on the internet; here we are. [laughs]

+ +

STEPH: That makes sense to me, though, because as you're describing that situation, I do something similar, but I've just never thought about it in these concrete terms where I have someone in mind, and it's a real person in my life who are my confidence person.

+ +

They're the one that I know they are very confident. They're going to push for the best deal for themselves. They're going to look out for themselves. They're going to look out for me. They're going to support me. I have that person. And so, even if I can't talk to them in reality, then I will still channel that energy.

+ +

And then I have someone else who's like my kind filter, and they're the person that's going to be very supportive. And you make mistakes, and it's not a big deal, and you learn, and you move on. And so I have those different...and in my mind, I just saw them as coaches.

+ +

Instead of board of directors, I just see them as different things that I don't see as strong in my character. And so I have these coaches in those particular areas that then I will pull energy from to then bolster myself in a particular way or skill.

+ +

This was fun. I'm so glad we talked about this because that is very insightful to you, and for me as well, and to myself.

+ +

CHRIS: Yeah, we went deep on this episode.

+ +

STEPH: No tech but lots of deep personal insight.

+ +

CHRIS: I talked a little bit about bcrypt. [laughs] You can't stop me from talking about tech for an entire episode. But then I also talked about my board of directors and the conversations I have with myself, so I feel like I rounded it out pretty good.

+ +

STEPH: It's a very round episode.

+ +

CHRIS: Yeah, I agree. And with that roundedness, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Happy New Year (for real)! Chris and Steph both took some end-of-year time off to rest and recharge.

+ +

Steph talks about some books she enjoyed, recipes she tried, and trail-walking adventures with her dog, Utah. Chris' company is now in a good position to actually start hiring within the engineering team. He's excited about that and will probably delve into more around the hiring process in the coming weeks.

+ +

Since they aren't really big on New Year's Eve resolutions, Steph and Chris answer a listener question regarding toxic traits inspired by the listener question related to large pull requests and reflect on their own.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Well, spoiler, we actually may have lied in a previous episode when we said, "Hey, happy New Year," because, for us, it was not actually the new year. But this, in fact, is the first episode of the new year that we're recording, that you're hearing. Anyway, this is enough breaking the fourth wall. Sorry, listener.

+ +

STEPH: [laughs]

+ +

CHRIS: Inside baseball, yadda, yadda. I'm doing great. First week back. I took some amount of vacation over the holidays, which was great, recharging, all those sorts of things. But now we're hitting the ground running.

+ +

And I'm actually really enjoying just getting back into the flow of things and, frankly, trying to ramp everything up, which we can probably talk about more in a moment. But how about you? How's your new year kicking off?

+ +

STEPH: I like how much we plan the episodes around when it's going to release, and we're very thoughtful about this is going to be released for the new year or around Christmas time, and happy holidays to everybody. And then we get back, and we're like, yeah, yeah, yeah, we can totally drop the facade. [laughs] We're finally back from vacation. And this is us, and this is real.

+ +

CHRIS: Date math is so hard. It just drains me entirely to even try and figure out when episodes are going to actually land. And then when we get here, also, you know, I want to talk about the fact that there was vacation and things, and the realities of the work, and the ebb and flow of life. So here we are.

+ +

STEPH: Same. Yeah, I love it. Because I'm in a similar spot where I took two weeks off, which was phenomenal. That's actually sticking to one of the things we talked about, for one of the things I'm looking to do is where I take just more time off. And so having the two weeks was wonderful.

+ +

It was also really helpful because the client team that I'm working with also shut down around the end of the year. So they took ten days off as well. So I was like, well, that's a really good sign of encouragement that I should also just shut down since I can. So it's been delightful.

+ +

And I have very little tech stuff to share because I've just been doing lots of other fun things and reading fiction, and catching up with friends and family, and trying out new recipes. That's been pretty much my last two weeks. Oh, and walks with Utah. His training is going so well where we're starting to walk off-leash on trails. And that's been awesome.

+ +

CHRIS: Wow, that's a big upgrade right there.

+ +

STEPH: Yeah, we're still working on that moving perimeter so he knows how far he can go. Before then, he needs to stop and check on me. But he's getting pretty good where he'll bolt ahead, but then he'll stop, and he'll look at me, and then he'll wait till I catch up. And then he'll bolt ahead again. It's really fun.

+ +

CHRIS: I like that that's the version of it that we're going for. This is not like you're going to walk alongside me on the trail; it's you're obviously going to run some distance out. As long as you check back in once every 20 feet, we're good; that’s fine.

+ +

Any particularly good books, or recipes, or talks with friends to go with that category? But that one's probably a little more specific to you.

+ +

STEPH: [laughs] Yes. There are two really good books that I read over the holidays. They're both by the same author. So I get a lot of books from my mom. She'll often pick up a book, and once she's done with it, she'll drop it off to me or vice versa.

+ +

So the one that she shared with me is called The Midnight Library. It's written by Matt Haig, H-A-I-G. And it's a very interesting story. It's a bit sad where it's about a woman who decides that she no longer wants to live. And then, when she moves in that direction to go ahead and end her life, she ends up in this library.

+ +

And in the library, every time she has made a different decision or made a decision in life, then there is a new book written about what that life is like. So then she has an opportunity to go explore all of these lives and see if there's a better life out there for her. It is really interesting. I highly recommend it.

+ +

CHRIS: Wow. I mean, that started with, I'm going to be honest, a very heavy premise. But then the idea that's super interesting. I would, actually...I think I might read that. I tend to just read sci-fi. This is broadly in the space, but that is super interesting.

+ +

There's an image that comes to mind actually as you described that. It's from Tim Urban, who's also known as Wait But Why. I think he posts under that both on Twitter, and then I think he has a blog or something to that effect.

+ +

But the image is basically like, all of the timelines that you could have followed in your life. And everybody thinks about like, from this moment today. Man, I think about all of the different versions of me that could exist today. But we don't think about the same thing moving forward in time. Like, what are all the possibilities in front of me?

+ +

And what you're describing of this person walking around in a library and each book represents a different fork in the road from moving forward is such an interesting idea. And I think a positive reframing of any form of regret or looking back and being like, what if I had gone the other way? It's like, yeah, but forward in time, though. I'm very intrigued by this book.

+ +

STEPH: Yeah, it's really good. It definitely has a strong It's a Wonderful Life vibe. Have you ever watched that movie?

+ +

CHRIS: Yes, I have.

+ +

STEPH: So there's a lot of that idea of regret. And what if I had lived differently and then getting to explore? But in it's A Wonderful Life, he just explores the one version. And in the book, she's exploring many versions.

+ +

So it's really neat to be like, well, what if I'd pursued this when I was younger, had done this differently? Or what if I got coffee instead of tea? There are even small, little choices that then might impact you being a different person at a point in time.

+ +

The other book that I read is by the same author because I enjoyed Midnight Library so much that I happened to see one of his other books. So I picked it up. And it's called How to Stop Time. And it's about an individual who essentially lives a very long time.

+ +

And there are several people in the world that are like this, but he lives for centuries. But he doesn't age, or he ages incredibly slowly, at a rate that where say that he's 100 years old, but he'll still look 16 years old. And it's very good. It's very interesting.

+ +

It's a bit more sad and melancholy than I typically like to read. So that one's good. But I will add that even though I described the first one, it has a sad premise; I found The Midnight Library a little more interesting and uplifting versus the other one I found a bit more sad.

+ +

CHRIS: All right. Excellent additional notes in the reading list here. So you can opt like, do you want a little bit more somber, or do you want to go a little more uplifting? Yeah, It's a Wonderful Life path being like, starts in a complicated place but don't worry, we'll get you there in the end.

+ +

STEPH: But I've learned I have to be careful with the books that I pick up because I will absorb the emotions that are going on in that book. And it will legit affect me through the week or as I'm reading that book. So I have to be careful of the books that I'm reading. [laughs] Is that weird? Do you have the same thing happen for when you're reading books?

+ +

CHRIS: It's interesting. I don't think of it with books as much. But I do think of it with TV shows. And so my wife and I have been very intentional when we've watched certain television shows to be like, we're going to need something to cut the intensity of this show.

+ +

And the most pointed example we had was we were watching Breaking Bad, which is one of the greatest television shows of all time but also just incredibly heavy and dark at times, kind of throughout. And so we would watch an episode of Breaking Bad. And then, as a palate cleanser, we would watch an episode of Malcolm in the Middle.

+ +

And so we saw the same actor but in very different facets of his performance arc and just really softened things and allowed us to, frankly, go to bed after that be able to sleep and whatnot but less so with reading. So I find it interesting that I have that distinction there.

+ +

STEPH: Yeah, that is interesting. Although I definitely feel that with movies and shows as well. Or if I watch something heavy, I'm like, great, what's on Disney? [laughs] I need to wash away some of that so I can watch something happy and go to sleep.

+ +

You also asked about recipes because I mentioned that's something I've been doing as well. There's a lot of plant-based books that I've picked up because that's really my favorite type of thing to make. So that's been a lot of fun. So yeah, a lot of cooking, a lot of reading. How about you? What else is going on in your world?

+ +

CHRIS: Well, actually, it's a super exciting time for Sagewell Financial, the company that I've joined. We are closing our seed financing round, which the whole world of venture capital is a novel thing that I'm still not super involved in that part of the process. But it has been really interesting to watch it progress, and evolve, and take shape. But at this point, we are closing our seed round. Things have gone really well.

+ +

And so we're in a position to actually start hiring, which is a whole thing to do, in particular, within the engineering group. We're hiring, I think, throughout the company, but my focus now will be bringing a few folks into the engineering team. And yeah, just trying to do that and do that well, do that intentionally, especially for the size of the team that we have now, the sort of work that we're doing, et cetera, et cetera.

+ +

But if anyone out there is listening, we are looking for great folks to join the team. We are Ruby on Rails, Inertia, TypeScript. If you've listened to the show anytime recently, you've heard me talk about the tech stack plenty.

+ +

But I think we're trying to do something very meaningful and help seniors manage finance, which is a complicated and, frankly, very underserved space. So it's work that I deeply believe in, and I think we're doing a good job at it. And I hope to do even a better job over time. So if that's at all interesting, definitely reach out to me.

+ +

But probably in the coming weeks, you'll hear me talk more and more about hiring and technical interviews and all of those sorts of things. I got to ramp myself back up on that entire world, which is really one of those things that you should always be doing is the thought that I have in my head. Now that I'm in a position to be hiring, I wish I'd been half-hiring for the past three months, but I'll figure it out. It'll be fine.

+ +

STEPH: That's such a big undertaking. Everything you're saying resonates, but also, it's like that's a lot of hard work. So if you're not in that state of really being ramped up for hiring, I understand why that would be on the backburner. And yeah, I'm excited to hear more.

+ +

I've gotten to hear some more of the product details about Sagewell, but I don't think we've really talked about those features here on the show. So I would love it if we brought some more of the feature work and talked about specifically what the application does.

+ +

I am intrigued speaking of how much energy goes into hiring. Where are you at in terms of how much...like, are there any particular job boards that you're going for? Or what's your current approach to hiring?

+ +

CHRIS: Oh, that's a great question. I have tweeted once into the world. I have a draft of a LinkedIn post. This is very much I'm figuring out as I go. It's sort of the nature of a startup as we have so many different things to do.

+ +

And frankly, even finding the time to start thinking about hiring means I'm taking time away from building features and growing out other aspects. So it's definitely a necessary thing that we're doing at this point in time.

+ +

But basically, everything we're doing is just in time compiling and figuring out what are the things that are semi-urgent right now? And to be honest, I like that energy overall. I've always had in the back of my mind that I like this sort of work and this space, especially if you can do it intentionally.

+ +

It shouldn't feel like everything's on fire all the time, but it should feel like a lot of constraints that force you to make decisions quickly, which, if we're being honest, I think that's something that is not my strongest suit. So it's something that I'm excited to grow that muscle as part of this work.

+ +

But so, with that in mind, at this point, my goal is to just start getting the word out there into the world that we are looking to hire and get people interested and then, from there, build out what's the interview process going to look like? I will let you know when we get there; I will. I will figure that out.

+ +

But it's not something that I've...I haven't actually very intentionally thought about all of this. Because if I were to do that, it would delay the amount of time until I actually say into the world, "Hey, we're hiring." So I very purposely was like, I just need to say this into the world and then continue doing the next steps in that process.

+ +

I'm prone to the perfect is the enemy of the good just trying to like, I want to have a complete plan and a 27-step checklist, and a Gantt chart, and a burndown. And before I take any first action and really trying to push back, I'm going to be like, no, no, just do something, just take a step in the right direction.

+ +

There's actually a blog post that comes to mind, which is by Dave Rupert, who is a former guest on this podcast. It was wonderful getting to interview him. But he wrote a blog post. The title of it is Do the Next Right, which is a line from a song in the movie Frozen 2, I believe. He is like, all right, stick with me here. And I know this is a movie for kids, maybe. But also, this is a very meaningful song.

+ +

And he framed it in a way that actually was surprisingly impactful to me. And it's that idea that I'm holding on to of you can't do it all, and you can't do it perfectly. Just do the next right thing. That's what you're going to do. So we'll link to that blog post in the show notes. But that's kind of where I'm at.

+ +

STEPH: I love that. I'm looking forward to reading that because that has been huge for me. I used to be held back by that idea of perfection. But then I realized other people were getting more work done more quickly. And so I was like, huh, maybe there's something to this just doing the next thing versus waiting for perfection that is really the right path.

+ +

So, how do folks reach out to you? Should they reach out to you on Twitter or email? What's best for you?

+ +

CHRIS: Oh yeah, Twitter. This is all probably going to be said at the end of the show as well. But Twitter @christoomey. ctoomey.com is my blog. I'm on GitHub. I make it very easy to contact me because I haven't regretted that up to this point in my life.

+ +

So basically, anywhere you find me on the internet, you will be able to email me or DM me or any of the things. I'm going to see how long I can hold on to that. I want to hold on to that forever. I want just a very open-door policy. So that's where I'm at right now, but any of those starting points.

+ +

And bikeshed.fm website will somehow link to me in any of the various forums, and they're all kind of linked to each other, so any of those are fine. I will happily take inquiries via any of the channels.

+ +

STEPH: Cool. Well, I'm excited to hear about how it goes.

+ +

CHRIS: Me too, frankly. But in a very small bit of little tech news or tech happenings from my holiday time, this was actually just before I started to go on break for the holidays. I had noticed that the test suite was getting very slow, like very, very slow but on my machine.

+ +

It was getting a little bit slow on CI, but the normal amount where we just keep adding new things. And we're adding a lot of feature specs because we want to have that holistic coverage over the whole application, and we can, so for now, we're doing that. But our spec suite had gotten up to six-ish minutes on CI and had a couple of other things. We have some linting and some TypeScript and things like that.

+ +

But on my machine, it was very slow. So I hadn't run the full spec suite in a long time. But I knew that running any individual spec took surprising amounts of time. And in the back of my head, I was like; I guess I hadn't configured Spring. That seems weird. I probably would have done that, but whatever.

+ +

And I'd never pushed on it more until one day I ran the specs. I ran one model spec, and it took 30 seconds or something like that. And I was like, well, that's absurd. And so I started to look into it. I did some scanning around the internet.

+ +

There was a wonderful post on the Giant Robots blog about how to look through things from Mike Wenger, a wonderful former thoughtboter. Unfortunately, none of the tips in there were anything meaningful for me. Everything was as I expected it to be. So I set it down.

+ +

And there were a couple of times that this happened to me where I'd be like, this is frustrating. I need to look into this a little bit more, but it was never worth investing more time. But I mentioned it in passing to one of the other developers on the team. And as a holiday gift to me, this person discovered the solution.

+ +

So let me describe a little bit more of what we've got working on here. On CI, which in theory is less powerful than my new, fancy M1 MacBook, on CI, we take about six minutes for the test suite. On my computer, it was taking 28 minutes and 30 seconds. So that's what we're working with. The factories are all doing normal things. We're not creating way too many database records or anything like that. So any thoughts, anything that you would inspect here?

+ +

STEPH: Ooh, you've already listed a number of good things that I would check.

+ +

CHRIS: Yeah, I took all the easy ones off the list. So this is a hard question at this point. To be clear, I had no ideas.

+ +

STEPH: Could you tell if there's a difference if it's like the boot-up time versus the actual test running?

+ +

CHRIS: Did that check; it is not the boot-up time. It is something that is happening in the process of running an individual spec.

+ +

STEPH: No, I'm drawing a blank. I can't think of what else I would check from there.

+ +

CHRIS: It's basically where I was at. Let me give you one additional piece of data, see if it does anything for you. I noticed that it happened basically whenever executing any factory. So I'd watch the logs. And if I create this record, it would do roughly what I expect it to.

+ +

It would create the record and maybe one or two associated records because that's how Factory Bot works. But it wasn't creating a giant cascade or waterfall of records under the hood. If we create a product, the product should have an associated user. So we'll see a product and a user insert. But for some reason, that line create whatever database record was very, very slow.

+ +

STEPH: Yeah, it's a good point, looking at factories because that's something I've noticed in triaging other tests is that I will often check to see how many records are created at a certain point because I've noticed there's a test where I think only one record is created, but I'll see 20. And that's an interesting artifact. But you're not running into that. But it sounds like there's more either some callback or transaction or something that's getting hung up and causing things to be slow.

+ +

CHRIS: I love those ideas. I didn't even know those were sort of ideas in the back of my head. I didn't know how to even try and chase that down. There was nothing in the logs. I couldn't see anything. And again, I just kept giving up. But again, this other developer on the team found the answer. But at this point, I'll just share the answer because I think we've run out of the good bits of the trivia.

+ +

It turns out bcrypt was the answer. So password-hashing was incredibly slow on my machine. What was interesting is I mentioned this to the other developer because they also have an M1. But there are three of us working on the project. The third developer does not have the M1 architecture. So that was an interesting thing. I was like, I feel like this maybe is a thing because we're both experiencing this, but the other developer isn't.

+ +

So it turns out bcrypt is wildly slow on the M1 architecture, which is sort of interesting as an artifact of like, what is password hashing, and how does it work? And in normal setups, I think the way it works is Devise will say by default, "We're going to do 12 runs of bcrypt." So like take the password, put it into the hashing algorithm, take the output, put it back into the hashing algorithm, and do that loop 12 times or whatever.

+ +

In test mode, it often will configure it to just run once, but it will still use the password hashing. Turns out even that was too slow for us. So we in test mode enabled it so that the password hashing algorithm was just the password. Don't do anything. Just return it directly. Turn off bcrypt; it's too painful for us. But it was very interesting to see that that was the case.

+ +

STEPH: Yeah, I don't like that answer. [laughs] I'm not a fan. That is interesting and tricky. And I feel like the only way I would have found that...I'm curious how they found it because I feel like at that point, I would have started outputting something to figure out, okay, where is the slow process? What's the thing that's taking so long to return?

+ +

And if I can't see tailing the test logs, then I would start just using a PUT statement to figure out what's taking a long time? And start trying to troubleshoot from there. So I'm curious, do you know how they identified that was the core issue?

+ +

CHRIS: Yes, actually. I'm looking back at the pull requests right now. And I'm mentioning that this was related to the M1 architecture, but I don't think that's actually true because the blog post that they're linking to is Collective Idea blog post: Tests Oddly Slow? Might be bcrypt. And then there's a related Rails issue.

+ +

They used TestProf, which is a process that you can run that will examine, I think the stack trace and say where are we spending the most time? And from that, they were able to see it looks like it's at the point where we're doing bcrypt. And so that's the answer.

+ +

As an aside, my test suite went from 28 minutes and 30 seconds to 1 minute and 30 seconds with this magical speed up.

+ +

STEPH: Nice. That's a great idea, TestProf. I don't know if I've used that tool. It rings a bell. But that's an awesome sales pitch for using TestProf.

+ +

CHRIS: Similarly, I don't think I'd ever use it before. But it truly was this wonderful holiday gift. Because the minute I switched over to this branch, I was like, oh my God, the tests are so fast. I have one of those fancy, new fast computers, [laughs] and now they're so fast.

+ +

STEPH: Wait, you had to switch to a branch? I figured it was something that you had to do special on your machine. So I'm intrigued how they fixed it for you, and then you switched to a branch and saw the speed increase.

+ +

CHRIS: So they opened a pull request. And that pull request had the change in the code. So it was a code-level configuration to say, "Hey, Devise, when you do the password hashing thing, maybe just don't, maybe be easy for a moment," [laughter] but only in the test configuration. So all I had to do was check out the branch, and then that configuration was part of the Rails helper setup, and then we were good to go from there.

+ +

I added an extra let me be terrified about this because the idea of not hashing passwords in production is terrifying. So let me raise...I put a couple of different guards against like, this should only ever run in test. I know it's in the spec support directory, so it shouldn't. Let me just add some other guards here just to superduper make sure we still hash passwords in production.

+ +

STEPH: Devise has a bcrypt chill mode. Good to know. [laughs] And I like all the guards you put in place too.

+ +

CHRIS: Yeah, it was really frankly such a relief to get that back to normal, is how I would describe it. But yeah, that's a fun little testing, and password hashing, and little adventure that I get to go on.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So I have something that I've been wanting to ask you, and it's not tech-related. But we can make this personal and work however we want to tackle it. But there is a previous episode where we read a listener question from Brian about their self-diagnosed toxic trait being large pull requests. And Brian was being playful with the use of the term toxic trait. But it got me thinking, it's like, well, what is my toxic trait?

+ +

And it seems like a fun twist on you, and I aren't really big on New Year's Eve resolutions. And in fact, I think you and I are more like if we're interested in achieving a goal, we'd rather focus on building a habit versus this specific, ambiguous we're going to publish ten blogs this year. But rather, I'd rather sit down and write for 15 minutes each day.

+ +

And it seemed like a fun twist instead of thinking about what are my toxic traits, personal, at work? Large pull request is a really fun example. So I'll let you choose. I can go first, or you can go first, but I'm excited to hear your thoughts on this one.

+ +

CHRIS: I think I've been talking too much. So let's have you go first at this point/ also, I want a few more seconds to think about my toxic trait.

+ +

STEPH: [laughs] All right, I have a couple. So that's an interesting point start there [laughs], but here we are. So I was even bold because I asked other people. Because I'm like, well, if I'm going to be fully self-aware, I can't just...I might lie to myself. So I'm going to have to ask some other people. So I asked other folks.

+ +

And my personal toxic trait is I am tardy. I am that person who I love to show up 5, 10, 15 minutes late. It's who I am. I don't find it a problem, but it often bothers other people. So that is my informed toxic trait. That might be a strong term for it. But that's the one that gives people the most grief.

+ +

CHRIS: Interesting. I do find the framing of I don't find my own tardiness to be a problem as a really interesting sort of lens on it. But okay, it's okay.

+ +

STEPH: I see it as long as I'm getting really good quality time with someone; if I'm five minutes late, I'm five minutes late. I think the voice going high means I'm a little defensive. [laughs]

+ +

CHRIS: But at least you're self-aware about all of these aspects. [laughs] That's critical.

+ +

STEPH: I am self-aware, and most of the people in my life are also self-aware, although I do correct that behavior for work. That feels more important that I be on time for everything because I don't want anyone to feel that I am not valuing their time. But when it comes to friends and family, they thankfully accept me for who I am.

+ +

But then, on the work note, I started thinking about toxic traits there. And the one I came up with is that I'm a pretty empathetic person. And there's something that I learned that's called toxic empathy. And it's when you let people's emotions hijack your own emotions, or you'll prioritize someone else's physical or mental health over your own. So, for example, it could be letting another person's anxiety and stress keep you from getting your current tasks and responsibilities done.

+ +

And there's a really funny tweet that I saw where someone says, "Hey, can I vent to you about something?" And the first person telling it from their perspective they're crying in the middle of a breakdown. And they're like, "Yeah, sure, what's up?" And I felt seen by that tweet. I was like, yeah; this seems like something I would do. [laughs]

+ +

So over time, as something I'm aware of about myself, I've learned to set more boundaries and only keep relationships where equal support is given to both individuals.

+ +

And this circles back to the book anecdote that I shared where I had to be careful about the books that I read because they can really affect my mood based on how the characters are doing in that book. So yeah, that's mine. I have one other one that I want to talk about. But I'm going to pause there so you can go.

+ +

CHRIS: Okay, fun. [laughs] This is fun. And it is a challenging mental exercise. But it is also, I don't know, vulnerable, and you have to look inside and all that. I think I poked at one earlier on as we were talking, but the idea of perfect is the enemy of the good. And I don't mean this in the terrible like; what’s your worst trait in a job interview? And you're like, "I'm a perfectionist." I don't mean it in that way.

+ +

I mean, I have at times struggled to make progress because so much of me wants to build the complete plan, and then very meticulously worked through in exactly the order that I define, sort of like a waterfall versus agile sort of thing.

+ +

And it is an ongoing very intentional body of work for me to try and break myself off those habits to try and accept what's the best thing that I can do? How can I move forward? How can I identify things that I will regret later versus things that are probably fine? They're little messes that I can clean up, that sort of thing.

+ +

And even that construing it as like there's a good choice and a bad choice, and I'm trying to find the perfect choice. It's like almost nothing in the world actually falls into that shape. So perfect is the enemy of the good is a really useful phrase that I've held onto that helps me.

+ +

And it's like, aiming for that perfection will cause you to miss the good that is available. And so, trying to be very intentional with that is the work that I'm doing. But that I think is a toxic trait that I have.

+ +

STEPH: I really like what you just said about being able to identify regrets. That feels huge. If you can look at a moment and say, "I really want to get all this done. I will regret if I don't do this, but the rest of it can wait," that feels really significant.

+ +

So the other one that I wanted to talk about is actually one that I feel like I've overcome. So this one makes me happy because I feel like I'm in a much better space with it, but it's negative self-talk. And it's essentially just how you treat yourself when you make a mistake. Or what's your internal dialogue throughout the day?

+ +

And I used to be harsh on myself. If I made a mistake, I was upset, I was annoyed with myself, and I wouldn't have a kind voice. And I don't know if I've shared this with you. But over time, I've gotten much better at that.

+ +

And what has really helped me with it is instead of talking to myself in an unkind voice, I talk to myself how someone who loves me will talk to me. I'm not going to talk to a friend in a really terrible, mean voice, and I wouldn't expect them to talk to me.

+ +

So I channel someone that I know is very positive and supportive of me. And I will frame it in that context. So then, when I make a mistake, it's not a big deal. And I just will say kind things to myself or laugh about it and move through it.

+ +

And I found that has been very helpful and also funny and maybe a little embarrassing at times because when pairing, I will talk out loud to myself. And so I'll do something silly, and I'll laugh. I'm like, "Oh, Stephanie," that was silly. And the other person hears me say that. [laughs] So it's a little entertainment for them too, I suppose.

+ +

CHRIS: Having observed it, it is charming.

+ +

STEPH: It's something that I've noticed that a lot of people do, and we don't talk about a lot. I mean, there's imposter syndrome. People will talk about that. But we don't often talk about how critical we are of ourselves.

+ +

It's something that I will talk to people who I highly admire and just think they're incredibly good at what they do. And then when they give me a glimpse into how they think about themselves at times or how they will berate themselves for something they have done or because they didn't sit down for that 15 minutes and write per day, then it really highlights.

+ +

And I hope that if we talk about this more, the fact that people tend to have such a negative inner critical voice, that maybe we can encourage people to start filtering that voice to a more kind voice and more supportive voice, and not have this unhelpful energy that's holding us back from really enjoying our work and being our best self.

+ +

CHRIS: That's so interesting to hear you say all of that for one of your traits because it's very similar to the last one for myself, which is I find that I do not feel safe unless (This is going to sound perhaps boastful, and I definitely do not mean it as boastful.) but unless I'm perfect. I guess the standard that I hold myself to versus the standard that I hold others to are wildly different.

+ +

Of course, for other people, yes, bugs will get into the code, or they may misunderstand something, or they may miss communicate something, or they may forget something. But if I do that, I feel unsafe, which is a thing that I've slowly come to recognize. I'm like, well, that shouldn't be true because that's definitely not how I feel about other people. That's not a reasonable standard to hold.

+ +

But that needing to be perfectly secured on all fronts and have just this very defensible like, yeah, I did the work, and it's great, and that's all that's true in the world. That's not reasonable. I'm never going to achieve that. And so, for a long time, there have been moments where I just don't feel great as a result of this, as a result of the standard that I'm trying to hold myself to.

+ +

But very similarly, I have brought voices into my head. In my case, I've actually identified a board of directors which are random actual people from my world but then also celebrities or fake people, and I will have conversations with them in my head. And that is a true thing about me that I'm now saying on the internet, here we are.

+ +

STEPH: [laughs]

+ +

CHRIS: And I'm going to throw it out there. It is fantastic. It is one of my favorite things that I have in my world. As a pointed example of a time that I did this, I was running a race at one point, which I occasionally will run road races. I am not good at it at all.

+ +

But I was running this particular race. It was a five-mile January race a couple of years back. And I was getting towards the end, and I was just going way faster than I normally do. I was at the four-mile mark, and I was well ahead of pace.

+ +

I was like, what is this? I was on track to get a personal record. I was like, this is exciting. But I didn't know if I could finish. And so I started to consult the board of directors and just check in with them and see what they would think about this.

+ +

And I got weirdly emotional, and it was weirdly real is the thing that was very interesting, not like I actually believed that these people were running with me or anything of that nature. But the emotions and the feelings that I was able to build up in that moment were so real and so powerful and useful to me that it was just like, oh, okay, yeah, that's a neat trick. I'm going to hold on to that one.

+ +

And it has been continuously useful moving forward from that of like, yeah, I can just have random conversations with anyone and find useful things in that and then use that to feel better about how I'm working.

+ +

STEPH: I so love this idea. And I'm now thinking about who to put on my board of directors. [laughs]

+ +

CHRIS: I'm telling you, everybody should have one. As I'm saying this, there is definitely a portion of me that is very self-conscious that I'm saying this on the internet because this is probably one of the weirdest things that I do.

+ +

STEPH: [laughs]

+ +

CHRIS: But it is so valuable. And it's one of those like; I like getting over that hump of like, well, this is an odd little habit that I have, but the utility that I get from it and the value is great. So highly recommend it.

+ +

It's a fun game of who gets to go on your board. You can change it out every year. And it is interesting because the more formed picture that you have of the individual, the more you can have a real conversation with them, and that's fun.

+ +

STEPH: So, as I'm working on forming a board of directors, how do you separate? Is it based on one person is running work and one is finance? How does each person have a role?

+ +

CHRIS: So there are no rules in this game. [laughs] This is a ridiculous thing that I do. But I find value in it's sort of vaguely the same collection of individuals. Some of them are truly archetypal, even fictitious characters. As long as I can have a picture in my head of them and say, "What would they say in a situation?"

+ +

If you're considering, say, moving jobs? What would Arnold Schwarzenegger have to say about that? And you'd be surprised the minute you ask it in your head; your brain is surprisingly good at these things. And it's like, let me paint The Terminator yelling at you to get the new job.

+ +

STEPH: [laughs]

+ +

CHRIS: Not get to the chopper, but get the new job. And it's surprisingly effective. And so I don't have a compartmentalized like, this is my work crew, this is my life crew. It's a nonsense collection of fake people in my head that I get to talk to. I'm saying this on the internet; here we are. [laughs]

+ +

STEPH: That makes sense to me, though, because as you're describing that situation, I do something similar, but I've just never thought about it in these concrete terms where I have someone in mind, and it's a real person in my life who are my confidence person.

+ +

They're the one that I know they are very confident. They're going to push for the best deal for themselves. They're going to look out for themselves. They're going to look out for me. They're going to support me. I have that person. And so, even if I can't talk to them in reality, then I will still channel that energy.

+ +

And then I have someone else who's like my kind filter, and they're the person that's going to be very supportive. And you make mistakes, and it's not a big deal, and you learn, and you move on. And so I have those different...and in my mind, I just saw them as coaches.

+ +

Instead of board of directors, I just see them as different things that I don't see as strong in my character. And so I have these coaches in those particular areas that then I will pull energy from to then bolster myself in a particular way or skill.

+ +

This was fun. I'm so glad we talked about this because that is very insightful to you, and for me as well, and to myself.

+ +

CHRIS: Yeah, we went deep on this episode.

+ +

STEPH: No tech but lots of deep personal insight.

+ +

CHRIS: I talked a little bit about bcrypt. [laughs] You can't stop me from talking about tech for an entire episode. But then I also talked about my board of directors and the conversations I have with myself, so I feel like I rounded it out pretty good.

+ +

STEPH: It's a very round episode.

+ +

CHRIS: Yeah, I agree. And with that roundedness, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+f0ZQpOMW + + ]]> + + Chris Toomey + Steph Viccari + + + 321: Leaving Breadcrumbs + https://bikeshed.thoughtbot.com/321 + 34b41a56-1678-4da7-be49-3ef2911ec831 + Tue, 11 Jan 2022 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph tells a cute story about escape artist huskies, and on a technical note, shares a journey in regards to class variables and modules inheritance. + +Chris talks about how he's starting to pursue analytics and one of the things that he's struggling with that he's always historically struggled with is the idea of historical data. He's also noticed a lack of formalization of certain things and is working with his team to remedy that. + 40:20 + no + + + Steph tells a cute story about escape artist huskies, and on a technical note, shares a journey in regards to class variables and modules inheritance. +Chris talks about how he's starting to pursue analytics and one of the things that he's struggling with that he's always historically struggled with is the idea of historical data. He's also noticed a lack of formalization of certain things and is working with his team to remedy that. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Mike Burns: How to Skim a Pull Request (https://thoughtbot.com/blog/a-smelly-list) +RSpec Documentation (https://rspec.info/documentation/) +Don't Let the Internet Dupe You, Event Sourcing is Hard (https://chriskiehl.com/article/event-sourcing-is-hard) +Datomic (https://www.datomic.com/) +timefora_boolean (https://github.com/calebhearth/time_for_a_boolean) +Sentry (https://sentry.io/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, it's an entirely new year. What is new in your new year? +STEPH: Well, the year is off to an interesting start because we helped rescue a husky. +CHRIS: Rescue as in now this is your dog or rescue as in the dog was trapped in a well, and another dog told you about the dog being trapped in a well, and then you helped the trapped? [laughs] Which of those situations are we working with? +STEPH: [laughs] I'm really wishing it was the second version [laughs] where there's a dog that tells me about another dog trapped in a well. No, this is a third version where there was a husky that was wandering around the gym that we go to. And so Tim, my husband, called and said that "There's this husky, and he's super sweet, but he seems very lost." And our gym is located near a major road, and so we were worried that he was going to wander about and get hit. +So I hopped into our car and took a crate and a leash, and he hopped right in. Clearly, he belonged to somebody; he'd just escaped. So he hops right in, and then we bring him home. But I put him in the backyard because I want to keep him separate from our dog, Utah, just because I don't know this dog, and I want to keep him safe. And I go back inside to grab a few things. I come back out, and the husky is gone. And I'm like, well, shit. [laughs] Now I'm starting to understand why this husky is missing or why this husky seemed lost. +So then I started looking for the husky, and Tim comes home. He's helping me look for the husky. And it was one of those awful moments where we live near...it's not a major road, but people tend to speed on it. And the husky and I happen to see each other across the road. And so the husky was like, oh, human friend and starts coming across the road towards me. And there's this large SUV that's also coming from the other direction. I'm like, oh, this is it. This is my nightmare. This is becoming real. This dog is about to get hit. +Thankfully, the driver saw the husky and stopped in time, so everything was fine. And the husky just finished trotting across the road to me, brought him in, kept him in the kennel in the garage. We didn't have any backyard adventures after that. The husky then thanked us by howling most of the night. [laughs] So this poor husky has had an adventure. We've had an adventure. +And then, around 4:30 in the morning, I go out because I'm checking on the husky and going to let him out. And I'm scrolling on the app called Nextdoor. And I see that someone posted a picture of this exact husky that's like, "Please help me find my dog." And I was like, yes. Because we were going to have to take him to a county shelter or at least go see if he had a chip so then we could return him. But thankfully, we found the owner. I found out the husky's name is Sebastian. And then we had him for a few more hours, and then we had a wonderful husky and human reunion. +CHRIS: That story had everything. It had ups; it had downs; it had huskies. It had escape artist huskies, in fact. I have...this is only through Reddit because that's how people learn about things in the world, but huskies are a rather vocal dog breed. So when you say the dog was howling, huskies have a particular way of almost singing, and it kind of sounds like yelling rather than more traditional dog sounds. Was that the experience you had? +STEPH: Luckily, it wasn't too bad. His howling was more just; he didn't want to be in the crate. He seems like an indoor dog. So he's like, what am I doing outside in the garage? I should be indoors. And so he wasn't too loud. It was more he was just bemoaning his situation. +But our dog Utah could hear him upset in the garage. And so that was also getting Utah upset because he didn't understand why there was a dog so close. And that was what led to the sleepless night because we couldn't get both of them to calm down. Because then, as soon as one of them calm down, the other one would get the other one riled. +CHRIS: As it so often happens. +STEPH: I'm so grateful that it turned out to be a happy story, though. That part was wonderful. And if we see the husky again, now we know his name is Sebastian and that he'll just come home with us. [chuckles] And we'll know how to return him since he seems to be an escape artist. +CHRIS: And we were best friends forever. +STEPH: On a more technical note, I have quite the journey to share in regards to class variables and modules inheritance. But before I dive in, I'm curious, what's new in your world? +CHRIS: Oh. Well, I'm excited to dig into that story. But I've got two smaller things in my world this week that are top of mind. I don't really have answers on them. I have more questions. One is we're starting to pursue analytics. We want to try and understand our system a little bit better. What is the experience of our users? How are they coming into the system? What are they doing? How long does it take them to do the things that we want them to do? All those sorts of questions you want to be able to answer about your application. +And one of the things that I'm struggling with that I've always historically struggled with is the idea of historical data. So data changes over time, and often we actually want to know about those transition points. We want to know about the different states that a user or any record in the system has been in. And I'm finding myself feeling the same pain that I felt many times and starting to think again about the relevant options out there in the world. +To give a slightly more pointed example of what we're dealing with, users come in, and then there are a few steps for them to actually sign up for the application. And so their user record or their application, if you will, will go through a couple of different states. So they can be basically approved directly, and now they're an active user of the system, that's one option. +But they can also end up in a state where they're pending review. And then eventually, depending on the outcome of that review, whether it's manual or someone intervenes or what have you, then eventually they can transition to either being denied or being accepted. And then they'll again be an active user. And so there's a question now of how many of the users that end up in that pending state end up transitioning into active. +And as I looked at the database, I was like, I do not have this information right now. I know their current state. And the logs could tell me all of this. We don't have proper log archiving right now. And I also don't have a system for, like, let me pull down gigabytes of logs and try and sift through that to understand the answer, especially for something domain level like this. +But this is one specific example that represents a category of things in my mind. The stuff that I've looked at in this space otherwise is Event Sourcing. So the idea that rather than having a discrete representation of the state of your application, you store every event as an individual log, essentially of like user did X, thing happened, Y occurred. And then, at any given point, you need to know about the state of your system; you just reduce all of those events through some magical reducer that produces the current state. +I also very recently read an article called Event sourcing is Hard. So I have that in my head as a counterpoint. This seems like a thing that is non-trivial to do, makes sense for a certain scale. But of course, like anything else, it has its trade-offs. +Another thing that I've looked at and never really pursued mostly because it's in a different ecosystem, is Datomic, D-A-T-O-M-I-C, which I think I've mentioned before. But it's a database that actually stores data in this historical format. And so you can ask for the current value, but then you can also ask for what are all the states that this user has been in? And what are the timestamps of those changes? +One small thing that we do have that I really like...so this is one example of us; I think leaning into wanting to have more information, higher fidelity information, is often we want to know something like was this ticket paid? Did someone pay for this ticket? And so paid is a BooleanProperty on this ticket record within our system. So the ticket can be held for a little while and eventually gets paid. And now, yes, it has been paid for. It is good. You can use it. But often, we want to know not just that it's paid but when it was paid. +And so there's a gem that we are using on the project called timeforaboolean by former thoughtboter, Caleb Hearth. And it does a wonderful job of basically instead of storing a Boolean value in the database, you store a timestamp. But then the Boolean can be inferred. If there is a value, if there's a timestamp for that record in the database, then there are a bunch of helper methods that get introduced that say, like, paid? That's now a method that I can ask, and it will tell us that. But we can also find the paidat, paid_at value. +And so we have this higher fidelity data when we need it, but we can also collapse it down to the simpler representation. Because most often, all we need to know is, have they paid for it? Cool, then they're good. They can come into the concert, that sort of thing. But yeah, this is a broader question that I don't have a great answer to. I think Postgres and Rails and just the nature of how we approach these applications pushes us in a certain direction. +Another thing I'm exploring is downstream analytic systems. What if I send a bunch of events to them, and they act as a half-event sourcing type thing? But yeah, this is going to be, I think, an open question for me for a while. +STEPH: Yeah, you said a lot of really good options. When you're talking about in our ecosystem, we get pushed in one direction or the other that makes me think of the projects that I've been on. Typically, what they'll reach for first is something like a Papertrail. So then, that way, they can check for the historical versions of an object and how it was changed and see who changed it. That's one way to track the logs. I like the idea that if you can outsource it and send all of those events to a logging system and then essentially ask for that data back as you need it. +You made me think of a recent project as well where we needed to track the state. So it was a patient matching system. And we really needed to know when a patient match was created or disconnected and then who did that and perhaps for what reason. And to ensure that we had as much information as possible, we took that opportunity to just create a record for it. +So we had a patient match record or...I forgot the name of the other one where we created where a patient did not have a match. But we were creating a record every time someone did that. Granted, probably that’s not going to happen nearly as often as someone paying for an event or the situations that you're describing. +This was ideally infrequently that someone was going to unmatch a patient because it meant that our system had matched people that shouldn't be matched, and then a human had intervened. But yeah, it's interesting the space that you're in. And you listed all the good things that I would have thought of. +CHRIS: I think you listed Papertrail, which is one that I hadn't actually thought of yet for this particular instance. This only came up earlier today also. So this is new in my head that I'm really being pushed in this direction. But I think Papertrail could be a good solution for where we're at. But it is one of those where you often don't know the thing you want to know. +And I'm terrified of losing data of like; I had the data. I knew it at one point in time, but now I can't reknow it in the future because I didn't write it down. That's one of the things that I just don't want to happen in the world. And so finding those ways of like, how can we architect a system so that we can do the normal, straightforward, boring things most of the time but then when we need to expand out the analytics dimension of the system that we're working on...and trying to thread that needle and find the ideal optimization on both sides is a tricky one. +But yeah, I'll definitely take another look at Papertrail and see if that...at a minimum, I think that's a good solution for where we're at now. And then this is going to be a thought that's going to roll around in the back of my head for a while. So if I come up with anything else, perhaps a grander solution, I'll certainly bring that back to The Bike Shed. But yeah, what else is up in your world? I want to hear the story of the class variables. +STEPH: Well, it is quite a journey. So I hope you're ready. Specifically, I was pairing with Joël, who was working on fixing a test that had been marked as being skipped for a while. We weren't really sure why. We figured maybe because it's flaky. But then, as Joël had restored that test, he realized it was actually failing consistently. +So it was a test that was failing for a reason folks maybe didn't understand, but they decided to cancel or to skip that test. But they didn't actually want to get rid of it because it seemed like a pretty important test based on the description. So Joël saw it and got excited because it seemed very relevant to some of the work he was already doing. So then, he is now investigating why this test is failing consistently. +So in this story, we have four main characters: we have a class, two modules, and a class variable. So enter the class stage left. All right, so this class defines a class variable which I have to say is not something I work with very much in Ruby. So class variables kind of felt a bit novel and diving back into like, oh yeah, these are a thing. +So the class defines a class variable that's called cache and assigns this variable to an instance of a cache. So then this class includes two modules who we'll call Module A and Module B. And we'll enter them stage right. And both of these models look to see if cache is already set. And if it's not, they also set the cache class variable. +So with that information, in our test, we don't want to exercise the real cache just because then if other tests are reading from that cache, which is proving to be a source of flakiness for these tests, then they are overriding each other's expectations, and it's causing some of the tests to flake. +So instead, we want to use a fake cache, just like an in-memory cache. So the test and its setup is already overriding. It's setting that class variable to say, hey, I want you to be a fake cache, just be in-memory. However, while executing that test, one of the modules is checking to see if that cache is set, which is being set in our test setup. +So test setup sets the value. We're running the test but then in the module, the model checks to see if it's set, and it’s suddenly nil instead of using the cache that we had set. So now it's defaulting back to say, "Oh, it's unset. So let me go back and set it to the real cache," which is exactly what we're trying to avoid. +So then the question became, if we're setting the class variable in our class, why is it being populated in one of the modules but it's not being populated in the other module? So one of them has it set to the in-memory cache, but the other one does not. +So I'm going to gloss over some of the details because this stuff is pretty tangling. But essentially, when the test is running, and it's loading the class, and we are overriding that class variable, it's getting shared with one of the modules because as soon as one of the models does set that class variable, there's a bidirectional link that gets set between the parent class which is the module in this case, and the class itself. +And as soon as that module sets the class variable, then they're going to talk to each other, and they're going to reference the same value. However, this only seems to happen for one of the parents. You can't do this for both. So if you have two parents that are trying to share a class variable with the same class, that doesn't work. So that's a particular bug that we were running into. +I do have some good news because if anybody is very nervous about the situation that I'm describing, I feel you. The good news is that in Ruby 3, they actually warn when this is happening and have introduced an error. So you don't have this inheritance confusion that can come out of the fact that these parent classes are also trying to share a class variable with this child class. +So in Ruby 3, if you are writing a class variable in that class but then you try to overwrite that class variable in the parent of that class or by the module that's being included, then an error is going to be raised. So it's going to warn you if you're creating this bidirectional link between those two class variables and that you shouldn't be overriding the child's ownership of that class variable. +Instead, if you're going to use class variables, which, one, is not my cup of tea, but if you're going to use class variables, it should be defined in the parent class, and then it can be shared downstream in the inheritance versus trying to go upstream and then having your ancestors essentially override some of those class variables. +So all of that is to say we were on a very interesting journey of understanding how class variables work, how the inheritance works, how that bidirectional link is getting established, and then how Ruby 3 comes in to warn us if something funky is happening. +CHRIS: Oh, that is interesting. And I'm now going to catalog that as a piece of information that my brain will retain for roughly the amount of time that we are recording this podcast and then immediately forget. +STEPH: As you should. [laughs] +CHRIS: It's one of the reasons that I try to avoid inheritance. And I try to avoid class variables as much as possible because of this category of problem, a very subtle bug that you have to try and really hone in. And you have to be very smart to debug this sort of thing. I don't want to be that smart. I want to code in a way that I can be less smart on any given Thursday. That's my goal in life. +I will ask one other question, though. So there's just a cache that this class and pair of modules are hanging around with, and then you want to swap it out for in-memory. This sounds remarkably like the Rails cache. Is this cache distinct special? Could it not just be backed by rails.cache, THE cache within the rails context, which can be backed by Memcached, or Redis, or in-memory when you're in tests, or the NullStore, which I think is the default in development is probably how that goes? +Is there a particular reason? Is this a special cache? Is there additional behavior that this cache has beyond the normal thing? Or is it just like, at some point, someone's like, oh, I need a cache. I'm just going to use a class variable, that'll be easy, which it definitely is, but then you run into complexities. +And caches are one of those hard things to get right. So it's one where I would immediately be like, whoa, whoa, I would love to not make up our own cache here. So I'm wondering, is there a distinct reason, or is it just this happened, and here we are? +STEPH: So I think we are using a custom cache that we are pointing to. So it is another service. It's not a Rails cache or an abstraction that we can point to and use. It is a different cache that we are using. And I'm trying to think back to the exact code. But there is a method that essentially checks to say, hey, should I use the real cache? Should I use the in-memory cache? +And that is something that we've explored to find a way to make this more global for the test suite because we really want to control this for all the tests. Because it's very easy to not realize in the test that you should avoid using that shared global cache. And so that way, the tests don't interact with each other but instead always use an individualized cache for each test to make sure that it is self-sufficient and independent. But we haven't gotten that far yet in figuring out how we can take a more global approach with this. +CHRIS: Gotcha. So I don't know the details. I assume there are reasons here. But just to play this out, if we find ourselves saying we have a reason to have a distinct cache, to have a special cache over here, but it's a cache...and caches fundamentally, that word always will raise my attention. It will be like, okay, this is a place that bugs will come and aggregate. And we need a distinct one that has special behavior as an external service, or that is just something like in... +There's a wonderful blog post that Mike Burns wrote at one point that was about...I think it was something like things that will make me look at your pull request in more detail. And I really loved it because it did capsulate all of these like, yeah, there are good reasons to do everything on this list. But if you do any of them, I will look at your pull requests and be like, oh, that's interesting. Why are we doing that, though? Do we have to do that? Are you sure? Are you triple sure we have to do that? +And this is definitely one of those things where caches automatically catch my attention. Even if we're using the built-in cache, I'm like, do we need to? Is that a definite thing? And then all the more so when we're using a custom bespoke one. Again, I assume that there are reasons that there's something special that's going on here. Perhaps the caching behavior is distinct from just it's Redis, and we throw data. And if it falls out the backside, that's fine. Maybe you need entirely different behavior here. But it is something that I would poke at a bunch. +STEPH: Yeah, you're asking a lot of good questions. I will have to go back and look at some of the code because we spent enough time in Ruby specifics that I didn't pay as much attention to the cache. Because right now, as we are working on these tests, we're trying to fix just the test without changing the application code, one, because that feels like a safer space. And if the test is flaky, we're just trying to change the test first. +But some of these tests we're starting to realize I'm not sure we can fix the test without also changing some of the application code, or the way that we do have to fix the test is really an incentive to back up and say maybe now's the time that we look at some of the application code. Because another question that comes to mind is why use a class variable, and does this need to be shared by the class and the modules? +And there's a part of me that suspects that maybe some of this logic was extracted to a module, but then it wasn't cleaned up in the other places. And so that's why we still have a reference. And it's essentially then being shared and set and unset and reset in those different places. So I think you ask some good questions, and I have some more questions of my own when we have time to revisit that portion of the test and application. +As another example of some of the tests that I've been working on, one of the tests that I...because we have a list, we can usually tell some of the tests that are flaky. So one of the ones that I was investigating was a similar issue where there was a shared resource, and someone had tried to mock it out. So they had taken the time to say, hey, I don't actually want to use that real resource that's over there; instead, I want to just return the scanned value. +But instead, they'd accidentally stubbed out a class-level method instead of the instance-level method. And so it was running, but it wasn't actually stubbing anything else since that's the method that's not getting called. So that was just an oversight for that test. So I fixed that test. But I noticed that we were using allow any instance of, so then I did take the time to go through that file and change and move away from the use of allow any instance of. +And for folks that are less familiar with allow any instance of, RSpec has some really great docs that talk about how it's very helpful for dealing with legacy code. But essentially, it is a code smell that you're using; allow any instance of because you are saying that my test is or my code is so complex that I can't really mock out the specific instances that I want to and then return specific behavior. So instead, I'm having to use this more global approach to say, hey, any instance of this method, I want you to mock it out versus this very specific instance that I know that I'm working with. +But we can include a link in the show notes because there's a nice write-up that talks about some of the reasons that allow any instance of is not recommended. So that's been kind of fun. There's been a little bit of joy to get to refactor away from that and actually stub out a specific instance. +Part of the work, too, that I'm noticing as Joël and I are going through these tests is leaving breadcrumbs for other developers as well because they have a very large team. And they're very junior friendly, which is just incredible. I love that so much about this company. And because they do hire a lot of juniors, then it is a tough codebase. It's a fairly old codebase. +So as these juniors are coming in, they're seeing a lot of these patterns. And they're propagating these old patterns that aren't necessarily the best patterns to propagate. But they're doing their best, and then they are reusing what they're seeing. So part of the work as we are revising these tests, my hope is that people will see some of these newer patterns and use those instead of following some of the older patterns. +CHRIS: I can only imagine that you're writing borderline novels in your pull request descriptions and commit messages there. I do wonder, is there an index of those that you're collecting? So there's like, here's the test remediation examples list, and you're slowly adding to them. This was a weird one with a class variable. And this was a weird one that had flakiness due to waiting or asynchronous behavior. And gathering examples of those, but specifically from the codebase. +I could see that being a really useful artifact because I happily traverse through git blame all the time. But I don't know that that's always a thing. And frankly, I have to work for it sometimes. So if there is that list of here are pull requests that specifically did X, Y, and Z, I think that could be super useful. +STEPH: Yeah, that's a great idea. And yes, they have some shared team documentation that speaks to specifically flaky tests because they're aware that this is a problem. They are working together to address this. And they have documentation that states ways to avoid flaky tests. If you encounter a flaky test, here are some of the ways that you can triage to find out what's wrong. +So as Joël and I have been finding good examples, then we've been contributing to that document. And they also have team meetings. So our plan is to attend some of those meetings and be like, "Hey, this is just some of the stuff that we've seen this week, some of the things that we improved and changed," and share the progress that we're making. +Since everyone is aware that there are these developers that are working hard to improve the test suite, but then share that information with the rest of the team so they too can feel...one, they can just see the changes that are taking place. But they too can also benefit and apply those strategies themselves when they see a flaky test. +Oh, but you did just remind me of a thing. So one of the tests that I was going through...I'm very intentionally going through and making the smallest change possible. So I will do the gross, ugly fix whatever it is to get something to pass, and then I will commit it. And then I'll think about okay, well, how can I make this better? So essentially, I have the fix, whether it's pretty or not. And then, after that, I start to have other commits that make it prettier. +And so, I had a pull request that had four commits that told the story that I was very happy about and progressed along in a more positive direction. And I issued that, and I discovered that Gerrit, when it sees four commits, it split all of them into their own change request. +And so, instead of having what I thought would be this nice story, now got split across these four change requests. And I thought, well, that's less helpful. So I ended up squashing two of them, but I still kept three of them because they stood alone, and each told a story. But that's something that I've learned about Gerrit. +CHRIS: Always so interesting how our tools shape our work. +STEPH: And it made me think back to the listener who asked the question about ensuring that CI runs for each commit. Well, here you go, Gerrit. [chuckles] Gerrit does it for you. It ensures that every commit gets split into its own change request. +CHRIS: I mean, as you said earlier, not my cup of tea but... [laughs] +STEPH: Yeah, I'm still lukewarm. I'm still discovering Gerrit and how we get along. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +What else is going on in your world? +CHRIS: In my world, we keep adding new users to the system. We keep doing more stuff. These are all wonderful things, the direction you certainly want to be heading. But as we're doing that, I've recognized that we had a lack of process and a lack of formalization of certain things. +And a lot of the noise of the work was just coming to me because I was the person that everybody knew. I can ask a question; Chris will know the answer, et cetera. And then there were things that we needed to keep an eye on. But because it was everyone's job, it was no one's job. So we've introduced the idea of a point person on the engineering team. So this is a role that will rotate each week. I think you and I have worked on a handful of projects that had something similar to this. +There was a team that we worked with that had an ad hoc list, which were just little tasks that needed to be done by developers. So there was one person who would run with that. I've heard it called captain before, the sprint captain. We're not really doing sprints. So for various reasons, that title didn't work for me. But point person is what I went with here. +And so the idea is rather than having product management or anyone else in the organization just individually reaching out to developers, we want to try and choke that off, have a single point of communication. And so just today, I introduced into Slack, a group, but it's a group of one person. So @pointdev is technically the handle for this person. It’s a group in Slack. And each week, we'll rotate who the members of that team are. And technically, you could add multiple, but the idea is this is just one person. So we'll rotate the person. +And what ends up happening is if anyone...say the product manager says, "@pointdev, what's the status on..." blah, blah, blah, that will notify the person who is the point person that week. So that's a nice feature in Slack so that we can condense it down and say rather than asking individuals, ask this alias. We're introducing one layer of abstraction in our communication tools, much like we do in our software. +So I'm drafting now the list of like, here's all the stuff that I think this person...because we're trying to push all of the quote, unquote, "other work" the non-product feature development work into this person's purview for a given week. So it's monitor Sentry for any new errors as they come up, triage them, and figure out what we want to do. +Ideally, and this is perhaps aspirational, I would like to keep inbox zero in Sentry. I know how you feel about that more generally and perhaps even more specifically within the world of errors, but that's my dream. We're going to see how it goes. +STEPH: I don't know if people know I am the opposite of inbox zero. This is the life that I'm living. +CHRIS: What about with errors, though? What about something like Sentry? +STEPH: I want to say that I would be a better human with my email. But I'm going, to be honest [laughs] and say that I would probably have the same approach where I am not an inbox zero person. I've come to terms with it. I used to really strive and think I needed to change. But I have reached a point of comfort with this is who I am. There are many like us, so shout out to all y'all. +CHRIS: Oh yeah, by far the more common approach, I think. So specifically with the errors, I struggle a bit with it because what ends up happening is we are implicitly ignoring the errors. And if we're doing that, I would rather just sit around and have a conversation and be like, let's just explicitly ignore them. There's a button in the UI. We can ignore them. +If this is not a real error, we can add it to the list of things that we do not report on. We can ignore that error. We can ignore it for a week and add a card to Trello that has a due date that says, "Hey, we got to work on this." But let's take that implicit indifference to that particular error mode of our application and make it explicit. +Let's draw that line in the sand such that when I see a new error pop up, I'm like, oh, that seems like something I should do something about. I really want high signal-to-noise when I'm seeing errors coming. And so I'm willing to work for that. But it is a trade-off, and it does take effort. +And it's noisy, especially browser extensions, and whatnot, just fighting the page. Facebook showed up one day. I don't know how Facebook got in there. Someone was browsing our website from within Facebook's browser, which I didn't know was a thing, but they had their own thing. And it fires a bunch of events, and Sentry was just like, let me slurp all of those up. Those seem fun. That was noisy. So we had to turn those off, but we explicitly turned them off. +STEPH: I do like the approach that you're taking where it's one person, and then it's a rotating shift because I think that makes it more reasonable for someone's who's like, hey, this is going to be noisy for a week. And then you're going to look through these emails and check all these errors, and then either silence them because you don't think that they're interesting or mute them for now. Or if you're going to convert it into a ticket, set a due date, whatever the triage approach is going to be. +But that feels more achievable versus inbox zero for life is just exhausting. But I feel like if you're doing it rotating week by week, that seems like a nice approach and also easier to keep it at inbox zero because that way, you are keeping up with all the errors. Because I agree; otherwise, what's the point of tracking all the errors if you're just going to ignore them? +CHRIS: Yeah, definitely the rotating, I think, is critical. I think the other thing that's been critical specifically on the error front is we've had now a handful of meetings where we triage the backlog together, the backlog of errors. So like, what all is coming into Sentry? What's going on? And we go through the process of determining is this a real thing? Should we fix this? Should we ignore it? +And we do that together so that it becomes not just one person's intuition about whether or not this is important or not or what the source of it might be but a shared intuition such that now any one of us, when it's our week, can ideally represent the team in that way and be like, never mind, never tell us about this again because it's very easy to silence things in Sentry that you would actually like to know about when they become real. But right now, we have this edge case that is an ignorable version. So trying to get there that's been fun. +But yeah, once again, Sentry, that's one of the things on this person's list. There are ad hoc support tickets for our operations team. So anything that needs to happen on a user's behalf that currently needs a developer to console, let's funnel all of those to this one individual, respond to any new questions. So this is where that Slack handle will be useful. +Check for any stuck jobs in Sidekiq. So is there anything that's been retrying for a while? Because it probably shouldn't. Maybe one or two retries is cool, but past that, something has gone wrong. And we should either get in there and fix it or just kill that job because it's never going to succeed, which is quite often the case but go in there and keep an eye on those and then look for anything. +We're starting to use due dates within Trello, which is currently our project management system. We'll see. Someday we're definitely going to grow out of that. But for now, it's good enough and checking for anything that's overdue or coming up in the next week in terms of due dates and just making sure that we're being responsive to that. +And so, I really like the idea of having this be a named set of things and a singular focus for one individual. Because again, that idea of like, if it's everybody's job, it's nobody's job. Or if it's nobody's job, then it's my job, and I don't want it to exclusively be my job. [chuckles] So I'm trying to make it not exclusively my job and to share the knowledge about it and make sure that these are skills that we all have and ideas and et cetera. But also, I would be fine to answer fewer questions in Slack each day. +STEPH: I have to admit, as soon as you were telling me that you had established this role, I was quietly congratulating you on helping delegate some of these responsibilities to the team. Because like you said, you are then the person that takes on all these tasks. +CHRIS: There's a laziness to that. Like, it's easy for me to just answer the questions. It's harder for me to put up a wall and say, "No, no, we have a process for this." And quite possibly, what's going to happen behind the scenes is that questions are going to come in to whoever is this point person. They're not going to know the answer. They're going to reach out to me, and then that conversation is still going to happen. But even by doing that now, now that person will see that answer, will understand the thinking or the background, the context that I have. +And so it's that weird thing of like, it would be so much easier for me to just answer one question. But to answer all the questions, well, I can't do that. And so I'm working to try and do more of the delegation to try and hand things off when they're in a known state and to identify this sort of stuff so that the team broadly can be stronger and better able to support everyone else in the organization. So that's the dream. We'll see how it goes. +STEPH: Yeah, I love that approach. I'm also thinking how interesting this role is because I'm imagining a mix between someone who is like the front point person at like an ER. So like, things are coming in, and they're in a tragic state and need help and need to be diagnosed. +But at the same time, you mentioned they're going around. They're checking Sidekiq. They're looking at some email errors. So they're also that night shift guard that's walking around with a flashlight just poking in each room. So it seems like a very stressful and low-key role all at the same time, all mixed up into one week. That person probably needs a beer at the end of the week. +CHRIS: There is a version of the story in my head that is...I wouldn't say this feels like a failure mode, but I would rather this not have to exist at all. I would rather things to be calmly humming along and not require a dedicated person each week to deal with the noise. I don't think that's realistic, certainly not as early on as we are in our organization. But I do wonder, is this a crutch? Is this something that we should be paying more attention to? +And I know in teams that you and I have worked with in the past that has been a recognition of like, this is a crutch. But it's a costly crutch. Like, we're taking an entire...in our case, it's not requiring the entirety of a developer's week. They're able to do this pretty easily and then still get a bunch...like, 75% of their time is still feature work. But we're just choking down who's the person that will be responding to questions when they pop up so that fewer individuals are interrupted? +But I have seen organizations where this definitely filled an entire week and spilled out more than. And then there was the recognition of that and the addition of another person that comes along and tries to fix stuff along the way as opposed to just responding. And so I want to make sure this isn't a band-aid but is, in fact, a necessary layer that we then try and shore up, you know, we should have fewer errors. That feels true. Okay, cool. Let's fix the bugs in the app. +And these ad hoc things that an admin needs to have done can that be a button in the UI? Can they actually self-serve in those cases? And we're slowly moving towards those. Ideally, fewer jobs get stuck in Sidekiq. And so, my hope is that this isn't a job that gets harder and harder over time. It's a job that potentially, if we're being honest, probably stays about this hard. I don't think it's ever going to be just like, nope, nobody needs to do anything. The app just runs, and it's great. And it never has bugs. +But that is a question in my mind as I start to embrace this thing of like one person is dedicated for a week to this. And if right now it's only 25% of their time, okay, that's probably fine. But if suddenly it's 50% of their time or 75% or 100% of their time for that whole week, that becomes too high of a bar in my mind. And I want to keep a close eye on it and make sure it's not trending in that direction. And I will be one of the people on the rotation. So I'll get to be in the trenches. +STEPH: I appreciate all the thoughtfulness that you're putting into it. And I'm thinking back on a project where we had a similar rotation because we had an issue Slack channel. And so anytime there was an issue, then it would get posted in there. And before, it was going out to everyone, or there was one particular person that was always picking it up and then trying to delegate it to others as they needed to. But then we started a similar rotation. +And one of the key benefits that I found from that is it signaled to the team, hey, this person might get pulled away. They can pick another ticket or two, but we need to give them lower priority tickets because there's a chance that they're going to get pulled away to work on something else. And that's okay, and we're going to plan for it. +Versus without this role in mind, then you had people all taking on high priority tickets, but then someone had to be the one that's like, well, I'm going to punt on my high priority and feel stressed about the fact that I've got this other thing to deal with. But then, I didn't actually do the work that I planned for. +So I feel like you're helping introduce calmness into the week, even if it is a stressful role. But then there's the goal that this becomes less of a stressful role, and if you see it trending in the opposite direction, then that's something to investigate. +But I also feel like triage and communication is such an important part of being a developer that it also feels very relevant upskilling for the whole team to go through. So there's also that benefit of where this approach also empowers the rest of the team to also experiences, build empathy, look for additional fixes, and then also build these important skills. +Overall, I really applaud your thoughtfulness. And I think it's a really good idea. And it will be interesting to see which direction that this role trends if it gets easier or if it's getting harder over time. +CHRIS: Well, thanks. I appreciate that. And I'll certainly report back as we develop this but hopefully, it stays about where it is. That feels right. And I think I'll probably...that's one of those things that I will monitor. And if I feel it moving in the wrong direction, then step in and try and get it back to this space because this feels like a maintainable reasonable amount. +And we shouldn't be fixing every bug and adding every button to the UI. That's just actually not how it works, unfortunately, would love to. That's not true. You shouldn't have every button in the UI. That's so many buttons. But broadly, I hope we can maintain roughly this, and I think identifying it and laying it out now I'm feeling good about having that structure. So yeah, we'll see how it goes. Will report back. But again, thank you for the kind words. +With that tour of a bunch of different things, should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeee!!!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph tells a cute story about escape artist huskies, and on a technical note, shares a journey in regards to class variables and modules inheritance.

+ +

Chris talks about how he's starting to pursue analytics and one of the things that he's struggling with that he's always historically struggled with is the idea of historical data. He's also noticed a lack of formalization of certain things and is working with his team to remedy that.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, it's an entirely new year. What is new in your new year?

+ +

STEPH: Well, the year is off to an interesting start because we helped rescue a husky.

+ +

CHRIS: Rescue as in now this is your dog or rescue as in the dog was trapped in a well, and another dog told you about the dog being trapped in a well, and then you helped the trapped? [laughs] Which of those situations are we working with?

+ +

STEPH: [laughs] I'm really wishing it was the second version [laughs] where there's a dog that tells me about another dog trapped in a well. No, this is a third version where there was a husky that was wandering around the gym that we go to. And so Tim, my husband, called and said that "There's this husky, and he's super sweet, but he seems very lost." And our gym is located near a major road, and so we were worried that he was going to wander about and get hit.

+ +

So I hopped into our car and took a crate and a leash, and he hopped right in. Clearly, he belonged to somebody; he'd just escaped. So he hops right in, and then we bring him home. But I put him in the backyard because I want to keep him separate from our dog, Utah, just because I don't know this dog, and I want to keep him safe. And I go back inside to grab a few things. I come back out, and the husky is gone. And I'm like, well, shit. [laughs] Now I'm starting to understand why this husky is missing or why this husky seemed lost.

+ +

So then I started looking for the husky, and Tim comes home. He's helping me look for the husky. And it was one of those awful moments where we live near...it's not a major road, but people tend to speed on it. And the husky and I happen to see each other across the road. And so the husky was like, oh, human friend and starts coming across the road towards me. And there's this large SUV that's also coming from the other direction. I'm like, oh, this is it. This is my nightmare. This is becoming real. This dog is about to get hit.

+ +

Thankfully, the driver saw the husky and stopped in time, so everything was fine. And the husky just finished trotting across the road to me, brought him in, kept him in the kennel in the garage. We didn't have any backyard adventures after that. The husky then thanked us by howling most of the night. [laughs] So this poor husky has had an adventure. We've had an adventure.

+ +

And then, around 4:30 in the morning, I go out because I'm checking on the husky and going to let him out. And I'm scrolling on the app called Nextdoor. And I see that someone posted a picture of this exact husky that's like, "Please help me find my dog." And I was like, yes. Because we were going to have to take him to a county shelter or at least go see if he had a chip so then we could return him. But thankfully, we found the owner. I found out the husky's name is Sebastian. And then we had him for a few more hours, and then we had a wonderful husky and human reunion.

+ +

CHRIS: That story had everything. It had ups; it had downs; it had huskies. It had escape artist huskies, in fact. I have...this is only through Reddit because that's how people learn about things in the world, but huskies are a rather vocal dog breed. So when you say the dog was howling, huskies have a particular way of almost singing, and it kind of sounds like yelling rather than more traditional dog sounds. Was that the experience you had?

+ +

STEPH: Luckily, it wasn't too bad. His howling was more just; he didn't want to be in the crate. He seems like an indoor dog. So he's like, what am I doing outside in the garage? I should be indoors. And so he wasn't too loud. It was more he was just bemoaning his situation.

+ +

But our dog Utah could hear him upset in the garage. And so that was also getting Utah upset because he didn't understand why there was a dog so close. And that was what led to the sleepless night because we couldn't get both of them to calm down. Because then, as soon as one of them calm down, the other one would get the other one riled.

+ +

CHRIS: As it so often happens.

+ +

STEPH: I'm so grateful that it turned out to be a happy story, though. That part was wonderful. And if we see the husky again, now we know his name is Sebastian and that he'll just come home with us. [chuckles] And we'll know how to return him since he seems to be an escape artist.

+ +

CHRIS: And we were best friends forever.

+ +

STEPH: On a more technical note, I have quite the journey to share in regards to class variables and modules inheritance. But before I dive in, I'm curious, what's new in your world?

+ +

CHRIS: Oh. Well, I'm excited to dig into that story. But I've got two smaller things in my world this week that are top of mind. I don't really have answers on them. I have more questions. One is we're starting to pursue analytics. We want to try and understand our system a little bit better. What is the experience of our users? How are they coming into the system? What are they doing? How long does it take them to do the things that we want them to do? All those sorts of questions you want to be able to answer about your application.

+ +

And one of the things that I'm struggling with that I've always historically struggled with is the idea of historical data. So data changes over time, and often we actually want to know about those transition points. We want to know about the different states that a user or any record in the system has been in. And I'm finding myself feeling the same pain that I felt many times and starting to think again about the relevant options out there in the world.

+ +

To give a slightly more pointed example of what we're dealing with, users come in, and then there are a few steps for them to actually sign up for the application. And so their user record or their application, if you will, will go through a couple of different states. So they can be basically approved directly, and now they're an active user of the system, that's one option.

+ +

But they can also end up in a state where they're pending review. And then eventually, depending on the outcome of that review, whether it's manual or someone intervenes or what have you, then eventually they can transition to either being denied or being accepted. And then they'll again be an active user. And so there's a question now of how many of the users that end up in that pending state end up transitioning into active.

+ +

And as I looked at the database, I was like, I do not have this information right now. I know their current state. And the logs could tell me all of this. We don't have proper log archiving right now. And I also don't have a system for, like, let me pull down gigabytes of logs and try and sift through that to understand the answer, especially for something domain level like this.

+ +

But this is one specific example that represents a category of things in my mind. The stuff that I've looked at in this space otherwise is Event Sourcing. So the idea that rather than having a discrete representation of the state of your application, you store every event as an individual log, essentially of like user did X, thing happened, Y occurred. And then, at any given point, you need to know about the state of your system; you just reduce all of those events through some magical reducer that produces the current state.

+ +

I also very recently read an article called Event sourcing is Hard. So I have that in my head as a counterpoint. This seems like a thing that is non-trivial to do, makes sense for a certain scale. But of course, like anything else, it has its trade-offs.

+ +

Another thing that I've looked at and never really pursued mostly because it's in a different ecosystem, is Datomic, D-A-T-O-M-I-C, which I think I've mentioned before. But it's a database that actually stores data in this historical format. And so you can ask for the current value, but then you can also ask for what are all the states that this user has been in? And what are the timestamps of those changes?

+ +

One small thing that we do have that I really like...so this is one example of us; I think leaning into wanting to have more information, higher fidelity information, is often we want to know something like was this ticket paid? Did someone pay for this ticket? And so paid is a BooleanProperty on this ticket record within our system. So the ticket can be held for a little while and eventually gets paid. And now, yes, it has been paid for. It is good. You can use it. But often, we want to know not just that it's paid but when it was paid.

+ +

And so there's a gem that we are using on the project called time_for_a_boolean by former thoughtboter, Caleb Hearth. And it does a wonderful job of basically instead of storing a Boolean value in the database, you store a timestamp. But then the Boolean can be inferred. If there is a value, if there's a timestamp for that record in the database, then there are a bunch of helper methods that get introduced that say, like, paid? That's now a method that I can ask, and it will tell us that. But we can also find the paid_at, paid_at value.

+ +

And so we have this higher fidelity data when we need it, but we can also collapse it down to the simpler representation. Because most often, all we need to know is, have they paid for it? Cool, then they're good. They can come into the concert, that sort of thing. But yeah, this is a broader question that I don't have a great answer to. I think Postgres and Rails and just the nature of how we approach these applications pushes us in a certain direction.

+ +

Another thing I'm exploring is downstream analytic systems. What if I send a bunch of events to them, and they act as a half-event sourcing type thing? But yeah, this is going to be, I think, an open question for me for a while.

+ +

STEPH: Yeah, you said a lot of really good options. When you're talking about in our ecosystem, we get pushed in one direction or the other that makes me think of the projects that I've been on. Typically, what they'll reach for first is something like a Papertrail. So then, that way, they can check for the historical versions of an object and how it was changed and see who changed it. That's one way to track the logs. I like the idea that if you can outsource it and send all of those events to a logging system and then essentially ask for that data back as you need it.

+ +

You made me think of a recent project as well where we needed to track the state. So it was a patient matching system. And we really needed to know when a patient match was created or disconnected and then who did that and perhaps for what reason. And to ensure that we had as much information as possible, we took that opportunity to just create a record for it.

+ +

So we had a patient match record or...I forgot the name of the other one where we created where a patient did not have a match. But we were creating a record every time someone did that. Granted, probably that’s not going to happen nearly as often as someone paying for an event or the situations that you're describing.

+ +

This was ideally infrequently that someone was going to unmatch a patient because it meant that our system had matched people that shouldn't be matched, and then a human had intervened. But yeah, it's interesting the space that you're in. And you listed all the good things that I would have thought of.

+ +

CHRIS: I think you listed Papertrail, which is one that I hadn't actually thought of yet for this particular instance. This only came up earlier today also. So this is new in my head that I'm really being pushed in this direction. But I think Papertrail could be a good solution for where we're at. But it is one of those where you often don't know the thing you want to know.

+ +

And I'm terrified of losing data of like; I had the data. I knew it at one point in time, but now I can't reknow it in the future because I didn't write it down. That's one of the things that I just don't want to happen in the world. And so finding those ways of like, how can we architect a system so that we can do the normal, straightforward, boring things most of the time but then when we need to expand out the analytics dimension of the system that we're working on...and trying to thread that needle and find the ideal optimization on both sides is a tricky one.

+ +

But yeah, I'll definitely take another look at Papertrail and see if that...at a minimum, I think that's a good solution for where we're at now. And then this is going to be a thought that's going to roll around in the back of my head for a while. So if I come up with anything else, perhaps a grander solution, I'll certainly bring that back to The Bike Shed. But yeah, what else is up in your world? I want to hear the story of the class variables.

+ +

STEPH: Well, it is quite a journey. So I hope you're ready. Specifically, I was pairing with Joël, who was working on fixing a test that had been marked as being skipped for a while. We weren't really sure why. We figured maybe because it's flaky. But then, as Joël had restored that test, he realized it was actually failing consistently.

+ +

So it was a test that was failing for a reason folks maybe didn't understand, but they decided to cancel or to skip that test. But they didn't actually want to get rid of it because it seemed like a pretty important test based on the description. So Joël saw it and got excited because it seemed very relevant to some of the work he was already doing. So then, he is now investigating why this test is failing consistently.

+ +

So in this story, we have four main characters: we have a class, two modules, and a class variable. So enter the class stage left. All right, so this class defines a class variable which I have to say is not something I work with very much in Ruby. So class variables kind of felt a bit novel and diving back into like, oh yeah, these are a thing.

+ +

So the class defines a class variable that's called cache and assigns this variable to an instance of a cache. So then this class includes two modules who we'll call Module A and Module B. And we'll enter them stage right. And both of these models look to see if cache is already set. And if it's not, they also set the cache class variable.

+ +

So with that information, in our test, we don't want to exercise the real cache just because then if other tests are reading from that cache, which is proving to be a source of flakiness for these tests, then they are overriding each other's expectations, and it's causing some of the tests to flake.

+ +

So instead, we want to use a fake cache, just like an in-memory cache. So the test and its setup is already overriding. It's setting that class variable to say, hey, I want you to be a fake cache, just be in-memory. However, while executing that test, one of the modules is checking to see if that cache is set, which is being set in our test setup.

+ +

So test setup sets the value. We're running the test but then in the module, the model checks to see if it's set, and it’s suddenly nil instead of using the cache that we had set. So now it's defaulting back to say, "Oh, it's unset. So let me go back and set it to the real cache," which is exactly what we're trying to avoid.

+ +

So then the question became, if we're setting the class variable in our class, why is it being populated in one of the modules but it's not being populated in the other module? So one of them has it set to the in-memory cache, but the other one does not.

+ +

So I'm going to gloss over some of the details because this stuff is pretty tangling. But essentially, when the test is running, and it's loading the class, and we are overriding that class variable, it's getting shared with one of the modules because as soon as one of the models does set that class variable, there's a bidirectional link that gets set between the parent class which is the module in this case, and the class itself.

+ +

And as soon as that module sets the class variable, then they're going to talk to each other, and they're going to reference the same value. However, this only seems to happen for one of the parents. You can't do this for both. So if you have two parents that are trying to share a class variable with the same class, that doesn't work. So that's a particular bug that we were running into.

+ +

I do have some good news because if anybody is very nervous about the situation that I'm describing, I feel you. The good news is that in Ruby 3, they actually warn when this is happening and have introduced an error. So you don't have this inheritance confusion that can come out of the fact that these parent classes are also trying to share a class variable with this child class.

+ +

So in Ruby 3, if you are writing a class variable in that class but then you try to overwrite that class variable in the parent of that class or by the module that's being included, then an error is going to be raised. So it's going to warn you if you're creating this bidirectional link between those two class variables and that you shouldn't be overriding the child's ownership of that class variable.

+ +

Instead, if you're going to use class variables, which, one, is not my cup of tea, but if you're going to use class variables, it should be defined in the parent class, and then it can be shared downstream in the inheritance versus trying to go upstream and then having your ancestors essentially override some of those class variables.

+ +

So all of that is to say we were on a very interesting journey of understanding how class variables work, how the inheritance works, how that bidirectional link is getting established, and then how Ruby 3 comes in to warn us if something funky is happening.

+ +

CHRIS: Oh, that is interesting. And I'm now going to catalog that as a piece of information that my brain will retain for roughly the amount of time that we are recording this podcast and then immediately forget.

+ +

STEPH: As you should. [laughs]

+ +

CHRIS: It's one of the reasons that I try to avoid inheritance. And I try to avoid class variables as much as possible because of this category of problem, a very subtle bug that you have to try and really hone in. And you have to be very smart to debug this sort of thing. I don't want to be that smart. I want to code in a way that I can be less smart on any given Thursday. That's my goal in life.

+ +

I will ask one other question, though. So there's just a cache that this class and pair of modules are hanging around with, and then you want to swap it out for in-memory. This sounds remarkably like the Rails cache. Is this cache distinct special? Could it not just be backed by rails.cache, THE cache within the rails context, which can be backed by Memcached, or Redis, or in-memory when you're in tests, or the NullStore, which I think is the default in development is probably how that goes?

+ +

Is there a particular reason? Is this a special cache? Is there additional behavior that this cache has beyond the normal thing? Or is it just like, at some point, someone's like, oh, I need a cache. I'm just going to use a class variable, that'll be easy, which it definitely is, but then you run into complexities.

+ +

And caches are one of those hard things to get right. So it's one where I would immediately be like, whoa, whoa, I would love to not make up our own cache here. So I'm wondering, is there a distinct reason, or is it just this happened, and here we are?

+ +

STEPH: So I think we are using a custom cache that we are pointing to. So it is another service. It's not a Rails cache or an abstraction that we can point to and use. It is a different cache that we are using. And I'm trying to think back to the exact code. But there is a method that essentially checks to say, hey, should I use the real cache? Should I use the in-memory cache?

+ +

And that is something that we've explored to find a way to make this more global for the test suite because we really want to control this for all the tests. Because it's very easy to not realize in the test that you should avoid using that shared global cache. And so that way, the tests don't interact with each other but instead always use an individualized cache for each test to make sure that it is self-sufficient and independent. But we haven't gotten that far yet in figuring out how we can take a more global approach with this.

+ +

CHRIS: Gotcha. So I don't know the details. I assume there are reasons here. But just to play this out, if we find ourselves saying we have a reason to have a distinct cache, to have a special cache over here, but it's a cache...and caches fundamentally, that word always will raise my attention. It will be like, okay, this is a place that bugs will come and aggregate. And we need a distinct one that has special behavior as an external service, or that is just something like in...

+ +

There's a wonderful blog post that Mike Burns wrote at one point that was about...I think it was something like things that will make me look at your pull request in more detail. And I really loved it because it did capsulate all of these like, yeah, there are good reasons to do everything on this list. But if you do any of them, I will look at your pull requests and be like, oh, that's interesting. Why are we doing that, though? Do we have to do that? Are you sure? Are you triple sure we have to do that?

+ +

And this is definitely one of those things where caches automatically catch my attention. Even if we're using the built-in cache, I'm like, do we need to? Is that a definite thing? And then all the more so when we're using a custom bespoke one. Again, I assume that there are reasons that there's something special that's going on here. Perhaps the caching behavior is distinct from just it's Redis, and we throw data. And if it falls out the backside, that's fine. Maybe you need entirely different behavior here. But it is something that I would poke at a bunch.

+ +

STEPH: Yeah, you're asking a lot of good questions. I will have to go back and look at some of the code because we spent enough time in Ruby specifics that I didn't pay as much attention to the cache. Because right now, as we are working on these tests, we're trying to fix just the test without changing the application code, one, because that feels like a safer space. And if the test is flaky, we're just trying to change the test first.

+ +

But some of these tests we're starting to realize I'm not sure we can fix the test without also changing some of the application code, or the way that we do have to fix the test is really an incentive to back up and say maybe now's the time that we look at some of the application code. Because another question that comes to mind is why use a class variable, and does this need to be shared by the class and the modules?

+ +

And there's a part of me that suspects that maybe some of this logic was extracted to a module, but then it wasn't cleaned up in the other places. And so that's why we still have a reference. And it's essentially then being shared and set and unset and reset in those different places. So I think you ask some good questions, and I have some more questions of my own when we have time to revisit that portion of the test and application.

+ +

As another example of some of the tests that I've been working on, one of the tests that I...because we have a list, we can usually tell some of the tests that are flaky. So one of the ones that I was investigating was a similar issue where there was a shared resource, and someone had tried to mock it out. So they had taken the time to say, hey, I don't actually want to use that real resource that's over there; instead, I want to just return the scanned value.

+ +

But instead, they'd accidentally stubbed out a class-level method instead of the instance-level method. And so it was running, but it wasn't actually stubbing anything else since that's the method that's not getting called. So that was just an oversight for that test. So I fixed that test. But I noticed that we were using allow any instance of, so then I did take the time to go through that file and change and move away from the use of allow any instance of.

+ +

And for folks that are less familiar with allow any instance of, RSpec has some really great docs that talk about how it's very helpful for dealing with legacy code. But essentially, it is a code smell that you're using; allow any instance of because you are saying that my test is or my code is so complex that I can't really mock out the specific instances that I want to and then return specific behavior. So instead, I'm having to use this more global approach to say, hey, any instance of this method, I want you to mock it out versus this very specific instance that I know that I'm working with.

+ +

But we can include a link in the show notes because there's a nice write-up that talks about some of the reasons that allow any instance of is not recommended. So that's been kind of fun. There's been a little bit of joy to get to refactor away from that and actually stub out a specific instance.

+ +

Part of the work, too, that I'm noticing as Joël and I are going through these tests is leaving breadcrumbs for other developers as well because they have a very large team. And they're very junior friendly, which is just incredible. I love that so much about this company. And because they do hire a lot of juniors, then it is a tough codebase. It's a fairly old codebase.

+ +

So as these juniors are coming in, they're seeing a lot of these patterns. And they're propagating these old patterns that aren't necessarily the best patterns to propagate. But they're doing their best, and then they are reusing what they're seeing. So part of the work as we are revising these tests, my hope is that people will see some of these newer patterns and use those instead of following some of the older patterns.

+ +

CHRIS: I can only imagine that you're writing borderline novels in your pull request descriptions and commit messages there. I do wonder, is there an index of those that you're collecting? So there's like, here's the test remediation examples list, and you're slowly adding to them. This was a weird one with a class variable. And this was a weird one that had flakiness due to waiting or asynchronous behavior. And gathering examples of those, but specifically from the codebase.

+ +

I could see that being a really useful artifact because I happily traverse through git blame all the time. But I don't know that that's always a thing. And frankly, I have to work for it sometimes. So if there is that list of here are pull requests that specifically did X, Y, and Z, I think that could be super useful.

+ +

STEPH: Yeah, that's a great idea. And yes, they have some shared team documentation that speaks to specifically flaky tests because they're aware that this is a problem. They are working together to address this. And they have documentation that states ways to avoid flaky tests. If you encounter a flaky test, here are some of the ways that you can triage to find out what's wrong.

+ +

So as Joël and I have been finding good examples, then we've been contributing to that document. And they also have team meetings. So our plan is to attend some of those meetings and be like, "Hey, this is just some of the stuff that we've seen this week, some of the things that we improved and changed," and share the progress that we're making.

+ +

Since everyone is aware that there are these developers that are working hard to improve the test suite, but then share that information with the rest of the team so they too can feel...one, they can just see the changes that are taking place. But they too can also benefit and apply those strategies themselves when they see a flaky test.

+ +

Oh, but you did just remind me of a thing. So one of the tests that I was going through...I'm very intentionally going through and making the smallest change possible. So I will do the gross, ugly fix whatever it is to get something to pass, and then I will commit it. And then I'll think about okay, well, how can I make this better? So essentially, I have the fix, whether it's pretty or not. And then, after that, I start to have other commits that make it prettier.

+ +

And so, I had a pull request that had four commits that told the story that I was very happy about and progressed along in a more positive direction. And I issued that, and I discovered that Gerrit, when it sees four commits, it split all of them into their own change request.

+ +

And so, instead of having what I thought would be this nice story, now got split across these four change requests. And I thought, well, that's less helpful. So I ended up squashing two of them, but I still kept three of them because they stood alone, and each told a story. But that's something that I've learned about Gerrit.

+ +

CHRIS: Always so interesting how our tools shape our work.

+ +

STEPH: And it made me think back to the listener who asked the question about ensuring that CI runs for each commit. Well, here you go, Gerrit. [chuckles] Gerrit does it for you. It ensures that every commit gets split into its own change request.

+ +

CHRIS: I mean, as you said earlier, not my cup of tea but... [laughs]

+ +

STEPH: Yeah, I'm still lukewarm. I'm still discovering Gerrit and how we get along.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

What else is going on in your world?

+ +

CHRIS: In my world, we keep adding new users to the system. We keep doing more stuff. These are all wonderful things, the direction you certainly want to be heading. But as we're doing that, I've recognized that we had a lack of process and a lack of formalization of certain things.

+ +

And a lot of the noise of the work was just coming to me because I was the person that everybody knew. I can ask a question; Chris will know the answer, et cetera. And then there were things that we needed to keep an eye on. But because it was everyone's job, it was no one's job. So we've introduced the idea of a point person on the engineering team. So this is a role that will rotate each week. I think you and I have worked on a handful of projects that had something similar to this.

+ +

There was a team that we worked with that had an ad hoc list, which were just little tasks that needed to be done by developers. So there was one person who would run with that. I've heard it called captain before, the sprint captain. We're not really doing sprints. So for various reasons, that title didn't work for me. But point person is what I went with here.

+ +

And so the idea is rather than having product management or anyone else in the organization just individually reaching out to developers, we want to try and choke that off, have a single point of communication. And so just today, I introduced into Slack, a group, but it's a group of one person. So @pointdev is technically the handle for this person. It’s a group in Slack. And each week, we'll rotate who the members of that team are. And technically, you could add multiple, but the idea is this is just one person. So we'll rotate the person.

+ +

And what ends up happening is if anyone...say the product manager says, "@pointdev, what's the status on..." blah, blah, blah, that will notify the person who is the point person that week. So that's a nice feature in Slack so that we can condense it down and say rather than asking individuals, ask this alias. We're introducing one layer of abstraction in our communication tools, much like we do in our software.

+ +

So I'm drafting now the list of like, here's all the stuff that I think this person...because we're trying to push all of the quote, unquote, "other work" the non-product feature development work into this person's purview for a given week. So it's monitor Sentry for any new errors as they come up, triage them, and figure out what we want to do.

+ +

Ideally, and this is perhaps aspirational, I would like to keep inbox zero in Sentry. I know how you feel about that more generally and perhaps even more specifically within the world of errors, but that's my dream. We're going to see how it goes.

+ +

STEPH: I don't know if people know I am the opposite of inbox zero. This is the life that I'm living.

+ +

CHRIS: What about with errors, though? What about something like Sentry?

+ +

STEPH: I want to say that I would be a better human with my email. But I'm going, to be honest [laughs] and say that I would probably have the same approach where I am not an inbox zero person. I've come to terms with it. I used to really strive and think I needed to change. But I have reached a point of comfort with this is who I am. There are many like us, so shout out to all y'all.

+ +

CHRIS: Oh yeah, by far the more common approach, I think. So specifically with the errors, I struggle a bit with it because what ends up happening is we are implicitly ignoring the errors. And if we're doing that, I would rather just sit around and have a conversation and be like, let's just explicitly ignore them. There's a button in the UI. We can ignore them.

+ +

If this is not a real error, we can add it to the list of things that we do not report on. We can ignore that error. We can ignore it for a week and add a card to Trello that has a due date that says, "Hey, we got to work on this." But let's take that implicit indifference to that particular error mode of our application and make it explicit.

+ +

Let's draw that line in the sand such that when I see a new error pop up, I'm like, oh, that seems like something I should do something about. I really want high signal-to-noise when I'm seeing errors coming. And so I'm willing to work for that. But it is a trade-off, and it does take effort.

+ +

And it's noisy, especially browser extensions, and whatnot, just fighting the page. Facebook showed up one day. I don't know how Facebook got in there. Someone was browsing our website from within Facebook's browser, which I didn't know was a thing, but they had their own thing. And it fires a bunch of events, and Sentry was just like, let me slurp all of those up. Those seem fun. That was noisy. So we had to turn those off, but we explicitly turned them off.

+ +

STEPH: I do like the approach that you're taking where it's one person, and then it's a rotating shift because I think that makes it more reasonable for someone's who's like, hey, this is going to be noisy for a week. And then you're going to look through these emails and check all these errors, and then either silence them because you don't think that they're interesting or mute them for now. Or if you're going to convert it into a ticket, set a due date, whatever the triage approach is going to be.

+ +

But that feels more achievable versus inbox zero for life is just exhausting. But I feel like if you're doing it rotating week by week, that seems like a nice approach and also easier to keep it at inbox zero because that way, you are keeping up with all the errors. Because I agree; otherwise, what's the point of tracking all the errors if you're just going to ignore them?

+ +

CHRIS: Yeah, definitely the rotating, I think, is critical. I think the other thing that's been critical specifically on the error front is we've had now a handful of meetings where we triage the backlog together, the backlog of errors. So like, what all is coming into Sentry? What's going on? And we go through the process of determining is this a real thing? Should we fix this? Should we ignore it?

+ +

And we do that together so that it becomes not just one person's intuition about whether or not this is important or not or what the source of it might be but a shared intuition such that now any one of us, when it's our week, can ideally represent the team in that way and be like, never mind, never tell us about this again because it's very easy to silence things in Sentry that you would actually like to know about when they become real. But right now, we have this edge case that is an ignorable version. So trying to get there that's been fun.

+ +

But yeah, once again, Sentry, that's one of the things on this person's list. There are ad hoc support tickets for our operations team. So anything that needs to happen on a user's behalf that currently needs a developer to console, let's funnel all of those to this one individual, respond to any new questions. So this is where that Slack handle will be useful.

+ +

Check for any stuck jobs in Sidekiq. So is there anything that's been retrying for a while? Because it probably shouldn't. Maybe one or two retries is cool, but past that, something has gone wrong. And we should either get in there and fix it or just kill that job because it's never going to succeed, which is quite often the case but go in there and keep an eye on those and then look for anything.

+ +

We're starting to use due dates within Trello, which is currently our project management system. We'll see. Someday we're definitely going to grow out of that. But for now, it's good enough and checking for anything that's overdue or coming up in the next week in terms of due dates and just making sure that we're being responsive to that.

+ +

And so, I really like the idea of having this be a named set of things and a singular focus for one individual. Because again, that idea of like, if it's everybody's job, it's nobody's job. Or if it's nobody's job, then it's my job, and I don't want it to exclusively be my job. [chuckles] So I'm trying to make it not exclusively my job and to share the knowledge about it and make sure that these are skills that we all have and ideas and et cetera. But also, I would be fine to answer fewer questions in Slack each day.

+ +

STEPH: I have to admit, as soon as you were telling me that you had established this role, I was quietly congratulating you on helping delegate some of these responsibilities to the team. Because like you said, you are then the person that takes on all these tasks.

+ +

CHRIS: There's a laziness to that. Like, it's easy for me to just answer the questions. It's harder for me to put up a wall and say, "No, no, we have a process for this." And quite possibly, what's going to happen behind the scenes is that questions are going to come in to whoever is this point person. They're not going to know the answer. They're going to reach out to me, and then that conversation is still going to happen. But even by doing that now, now that person will see that answer, will understand the thinking or the background, the context that I have.

+ +

And so it's that weird thing of like, it would be so much easier for me to just answer one question. But to answer all the questions, well, I can't do that. And so I'm working to try and do more of the delegation to try and hand things off when they're in a known state and to identify this sort of stuff so that the team broadly can be stronger and better able to support everyone else in the organization. So that's the dream. We'll see how it goes.

+ +

STEPH: Yeah, I love that approach. I'm also thinking how interesting this role is because I'm imagining a mix between someone who is like the front point person at like an ER. So like, things are coming in, and they're in a tragic state and need help and need to be diagnosed.

+ +

But at the same time, you mentioned they're going around. They're checking Sidekiq. They're looking at some email errors. So they're also that night shift guard that's walking around with a flashlight just poking in each room. So it seems like a very stressful and low-key role all at the same time, all mixed up into one week. That person probably needs a beer at the end of the week.

+ +

CHRIS: There is a version of the story in my head that is...I wouldn't say this feels like a failure mode, but I would rather this not have to exist at all. I would rather things to be calmly humming along and not require a dedicated person each week to deal with the noise. I don't think that's realistic, certainly not as early on as we are in our organization. But I do wonder, is this a crutch? Is this something that we should be paying more attention to?

+ +

And I know in teams that you and I have worked with in the past that has been a recognition of like, this is a crutch. But it's a costly crutch. Like, we're taking an entire...in our case, it's not requiring the entirety of a developer's week. They're able to do this pretty easily and then still get a bunch...like, 75% of their time is still feature work. But we're just choking down who's the person that will be responding to questions when they pop up so that fewer individuals are interrupted?

+ +

But I have seen organizations where this definitely filled an entire week and spilled out more than. And then there was the recognition of that and the addition of another person that comes along and tries to fix stuff along the way as opposed to just responding. And so I want to make sure this isn't a band-aid but is, in fact, a necessary layer that we then try and shore up, you know, we should have fewer errors. That feels true. Okay, cool. Let's fix the bugs in the app.

+ +

And these ad hoc things that an admin needs to have done can that be a button in the UI? Can they actually self-serve in those cases? And we're slowly moving towards those. Ideally, fewer jobs get stuck in Sidekiq. And so, my hope is that this isn't a job that gets harder and harder over time. It's a job that potentially, if we're being honest, probably stays about this hard. I don't think it's ever going to be just like, nope, nobody needs to do anything. The app just runs, and it's great. And it never has bugs.

+ +

But that is a question in my mind as I start to embrace this thing of like one person is dedicated for a week to this. And if right now it's only 25% of their time, okay, that's probably fine. But if suddenly it's 50% of their time or 75% or 100% of their time for that whole week, that becomes too high of a bar in my mind. And I want to keep a close eye on it and make sure it's not trending in that direction. And I will be one of the people on the rotation. So I'll get to be in the trenches.

+ +

STEPH: I appreciate all the thoughtfulness that you're putting into it. And I'm thinking back on a project where we had a similar rotation because we had an issue Slack channel. And so anytime there was an issue, then it would get posted in there. And before, it was going out to everyone, or there was one particular person that was always picking it up and then trying to delegate it to others as they needed to. But then we started a similar rotation.

+ +

And one of the key benefits that I found from that is it signaled to the team, hey, this person might get pulled away. They can pick another ticket or two, but we need to give them lower priority tickets because there's a chance that they're going to get pulled away to work on something else. And that's okay, and we're going to plan for it.

+ +

Versus without this role in mind, then you had people all taking on high priority tickets, but then someone had to be the one that's like, well, I'm going to punt on my high priority and feel stressed about the fact that I've got this other thing to deal with. But then, I didn't actually do the work that I planned for.

+ +

So I feel like you're helping introduce calmness into the week, even if it is a stressful role. But then there's the goal that this becomes less of a stressful role, and if you see it trending in the opposite direction, then that's something to investigate.

+ +

But I also feel like triage and communication is such an important part of being a developer that it also feels very relevant upskilling for the whole team to go through. So there's also that benefit of where this approach also empowers the rest of the team to also experiences, build empathy, look for additional fixes, and then also build these important skills.

+ +

Overall, I really applaud your thoughtfulness. And I think it's a really good idea. And it will be interesting to see which direction that this role trends if it gets easier or if it's getting harder over time.

+ +

CHRIS: Well, thanks. I appreciate that. And I'll certainly report back as we develop this but hopefully, it stays about where it is. That feels right. And I think I'll probably...that's one of those things that I will monitor. And if I feel it moving in the wrong direction, then step in and try and get it back to this space because this feels like a maintainable reasonable amount.

+ +

And we shouldn't be fixing every bug and adding every button to the UI. That's just actually not how it works, unfortunately, would love to. That's not true. You shouldn't have every button in the UI. That's so many buttons. But broadly, I hope we can maintain roughly this, and I think identifying it and laying it out now I'm feeling good about having that structure. So yeah, we'll see how it goes. Will report back. But again, thank you for the kind words.

+ +

With that tour of a bunch of different things, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeee!!!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph tells a cute story about escape artist huskies, and on a technical note, shares a journey in regards to class variables and modules inheritance.

+ +

Chris talks about how he's starting to pursue analytics and one of the things that he's struggling with that he's always historically struggled with is the idea of historical data. He's also noticed a lack of formalization of certain things and is working with his team to remedy that.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, it's an entirely new year. What is new in your new year?

+ +

STEPH: Well, the year is off to an interesting start because we helped rescue a husky.

+ +

CHRIS: Rescue as in now this is your dog or rescue as in the dog was trapped in a well, and another dog told you about the dog being trapped in a well, and then you helped the trapped? [laughs] Which of those situations are we working with?

+ +

STEPH: [laughs] I'm really wishing it was the second version [laughs] where there's a dog that tells me about another dog trapped in a well. No, this is a third version where there was a husky that was wandering around the gym that we go to. And so Tim, my husband, called and said that "There's this husky, and he's super sweet, but he seems very lost." And our gym is located near a major road, and so we were worried that he was going to wander about and get hit.

+ +

So I hopped into our car and took a crate and a leash, and he hopped right in. Clearly, he belonged to somebody; he'd just escaped. So he hops right in, and then we bring him home. But I put him in the backyard because I want to keep him separate from our dog, Utah, just because I don't know this dog, and I want to keep him safe. And I go back inside to grab a few things. I come back out, and the husky is gone. And I'm like, well, shit. [laughs] Now I'm starting to understand why this husky is missing or why this husky seemed lost.

+ +

So then I started looking for the husky, and Tim comes home. He's helping me look for the husky. And it was one of those awful moments where we live near...it's not a major road, but people tend to speed on it. And the husky and I happen to see each other across the road. And so the husky was like, oh, human friend and starts coming across the road towards me. And there's this large SUV that's also coming from the other direction. I'm like, oh, this is it. This is my nightmare. This is becoming real. This dog is about to get hit.

+ +

Thankfully, the driver saw the husky and stopped in time, so everything was fine. And the husky just finished trotting across the road to me, brought him in, kept him in the kennel in the garage. We didn't have any backyard adventures after that. The husky then thanked us by howling most of the night. [laughs] So this poor husky has had an adventure. We've had an adventure.

+ +

And then, around 4:30 in the morning, I go out because I'm checking on the husky and going to let him out. And I'm scrolling on the app called Nextdoor. And I see that someone posted a picture of this exact husky that's like, "Please help me find my dog." And I was like, yes. Because we were going to have to take him to a county shelter or at least go see if he had a chip so then we could return him. But thankfully, we found the owner. I found out the husky's name is Sebastian. And then we had him for a few more hours, and then we had a wonderful husky and human reunion.

+ +

CHRIS: That story had everything. It had ups; it had downs; it had huskies. It had escape artist huskies, in fact. I have...this is only through Reddit because that's how people learn about things in the world, but huskies are a rather vocal dog breed. So when you say the dog was howling, huskies have a particular way of almost singing, and it kind of sounds like yelling rather than more traditional dog sounds. Was that the experience you had?

+ +

STEPH: Luckily, it wasn't too bad. His howling was more just; he didn't want to be in the crate. He seems like an indoor dog. So he's like, what am I doing outside in the garage? I should be indoors. And so he wasn't too loud. It was more he was just bemoaning his situation.

+ +

But our dog Utah could hear him upset in the garage. And so that was also getting Utah upset because he didn't understand why there was a dog so close. And that was what led to the sleepless night because we couldn't get both of them to calm down. Because then, as soon as one of them calm down, the other one would get the other one riled.

+ +

CHRIS: As it so often happens.

+ +

STEPH: I'm so grateful that it turned out to be a happy story, though. That part was wonderful. And if we see the husky again, now we know his name is Sebastian and that he'll just come home with us. [chuckles] And we'll know how to return him since he seems to be an escape artist.

+ +

CHRIS: And we were best friends forever.

+ +

STEPH: On a more technical note, I have quite the journey to share in regards to class variables and modules inheritance. But before I dive in, I'm curious, what's new in your world?

+ +

CHRIS: Oh. Well, I'm excited to dig into that story. But I've got two smaller things in my world this week that are top of mind. I don't really have answers on them. I have more questions. One is we're starting to pursue analytics. We want to try and understand our system a little bit better. What is the experience of our users? How are they coming into the system? What are they doing? How long does it take them to do the things that we want them to do? All those sorts of questions you want to be able to answer about your application.

+ +

And one of the things that I'm struggling with that I've always historically struggled with is the idea of historical data. So data changes over time, and often we actually want to know about those transition points. We want to know about the different states that a user or any record in the system has been in. And I'm finding myself feeling the same pain that I felt many times and starting to think again about the relevant options out there in the world.

+ +

To give a slightly more pointed example of what we're dealing with, users come in, and then there are a few steps for them to actually sign up for the application. And so their user record or their application, if you will, will go through a couple of different states. So they can be basically approved directly, and now they're an active user of the system, that's one option.

+ +

But they can also end up in a state where they're pending review. And then eventually, depending on the outcome of that review, whether it's manual or someone intervenes or what have you, then eventually they can transition to either being denied or being accepted. And then they'll again be an active user. And so there's a question now of how many of the users that end up in that pending state end up transitioning into active.

+ +

And as I looked at the database, I was like, I do not have this information right now. I know their current state. And the logs could tell me all of this. We don't have proper log archiving right now. And I also don't have a system for, like, let me pull down gigabytes of logs and try and sift through that to understand the answer, especially for something domain level like this.

+ +

But this is one specific example that represents a category of things in my mind. The stuff that I've looked at in this space otherwise is Event Sourcing. So the idea that rather than having a discrete representation of the state of your application, you store every event as an individual log, essentially of like user did X, thing happened, Y occurred. And then, at any given point, you need to know about the state of your system; you just reduce all of those events through some magical reducer that produces the current state.

+ +

I also very recently read an article called Event sourcing is Hard. So I have that in my head as a counterpoint. This seems like a thing that is non-trivial to do, makes sense for a certain scale. But of course, like anything else, it has its trade-offs.

+ +

Another thing that I've looked at and never really pursued mostly because it's in a different ecosystem, is Datomic, D-A-T-O-M-I-C, which I think I've mentioned before. But it's a database that actually stores data in this historical format. And so you can ask for the current value, but then you can also ask for what are all the states that this user has been in? And what are the timestamps of those changes?

+ +

One small thing that we do have that I really like...so this is one example of us; I think leaning into wanting to have more information, higher fidelity information, is often we want to know something like was this ticket paid? Did someone pay for this ticket? And so paid is a BooleanProperty on this ticket record within our system. So the ticket can be held for a little while and eventually gets paid. And now, yes, it has been paid for. It is good. You can use it. But often, we want to know not just that it's paid but when it was paid.

+ +

And so there's a gem that we are using on the project called time_for_a_boolean by former thoughtboter, Caleb Hearth. And it does a wonderful job of basically instead of storing a Boolean value in the database, you store a timestamp. But then the Boolean can be inferred. If there is a value, if there's a timestamp for that record in the database, then there are a bunch of helper methods that get introduced that say, like, paid? That's now a method that I can ask, and it will tell us that. But we can also find the paid_at, paid_at value.

+ +

And so we have this higher fidelity data when we need it, but we can also collapse it down to the simpler representation. Because most often, all we need to know is, have they paid for it? Cool, then they're good. They can come into the concert, that sort of thing. But yeah, this is a broader question that I don't have a great answer to. I think Postgres and Rails and just the nature of how we approach these applications pushes us in a certain direction.

+ +

Another thing I'm exploring is downstream analytic systems. What if I send a bunch of events to them, and they act as a half-event sourcing type thing? But yeah, this is going to be, I think, an open question for me for a while.

+ +

STEPH: Yeah, you said a lot of really good options. When you're talking about in our ecosystem, we get pushed in one direction or the other that makes me think of the projects that I've been on. Typically, what they'll reach for first is something like a Papertrail. So then, that way, they can check for the historical versions of an object and how it was changed and see who changed it. That's one way to track the logs. I like the idea that if you can outsource it and send all of those events to a logging system and then essentially ask for that data back as you need it.

+ +

You made me think of a recent project as well where we needed to track the state. So it was a patient matching system. And we really needed to know when a patient match was created or disconnected and then who did that and perhaps for what reason. And to ensure that we had as much information as possible, we took that opportunity to just create a record for it.

+ +

So we had a patient match record or...I forgot the name of the other one where we created where a patient did not have a match. But we were creating a record every time someone did that. Granted, probably that’s not going to happen nearly as often as someone paying for an event or the situations that you're describing.

+ +

This was ideally infrequently that someone was going to unmatch a patient because it meant that our system had matched people that shouldn't be matched, and then a human had intervened. But yeah, it's interesting the space that you're in. And you listed all the good things that I would have thought of.

+ +

CHRIS: I think you listed Papertrail, which is one that I hadn't actually thought of yet for this particular instance. This only came up earlier today also. So this is new in my head that I'm really being pushed in this direction. But I think Papertrail could be a good solution for where we're at. But it is one of those where you often don't know the thing you want to know.

+ +

And I'm terrified of losing data of like; I had the data. I knew it at one point in time, but now I can't reknow it in the future because I didn't write it down. That's one of the things that I just don't want to happen in the world. And so finding those ways of like, how can we architect a system so that we can do the normal, straightforward, boring things most of the time but then when we need to expand out the analytics dimension of the system that we're working on...and trying to thread that needle and find the ideal optimization on both sides is a tricky one.

+ +

But yeah, I'll definitely take another look at Papertrail and see if that...at a minimum, I think that's a good solution for where we're at now. And then this is going to be a thought that's going to roll around in the back of my head for a while. So if I come up with anything else, perhaps a grander solution, I'll certainly bring that back to The Bike Shed. But yeah, what else is up in your world? I want to hear the story of the class variables.

+ +

STEPH: Well, it is quite a journey. So I hope you're ready. Specifically, I was pairing with Joël, who was working on fixing a test that had been marked as being skipped for a while. We weren't really sure why. We figured maybe because it's flaky. But then, as Joël had restored that test, he realized it was actually failing consistently.

+ +

So it was a test that was failing for a reason folks maybe didn't understand, but they decided to cancel or to skip that test. But they didn't actually want to get rid of it because it seemed like a pretty important test based on the description. So Joël saw it and got excited because it seemed very relevant to some of the work he was already doing. So then, he is now investigating why this test is failing consistently.

+ +

So in this story, we have four main characters: we have a class, two modules, and a class variable. So enter the class stage left. All right, so this class defines a class variable which I have to say is not something I work with very much in Ruby. So class variables kind of felt a bit novel and diving back into like, oh yeah, these are a thing.

+ +

So the class defines a class variable that's called cache and assigns this variable to an instance of a cache. So then this class includes two modules who we'll call Module A and Module B. And we'll enter them stage right. And both of these models look to see if cache is already set. And if it's not, they also set the cache class variable.

+ +

So with that information, in our test, we don't want to exercise the real cache just because then if other tests are reading from that cache, which is proving to be a source of flakiness for these tests, then they are overriding each other's expectations, and it's causing some of the tests to flake.

+ +

So instead, we want to use a fake cache, just like an in-memory cache. So the test and its setup is already overriding. It's setting that class variable to say, hey, I want you to be a fake cache, just be in-memory. However, while executing that test, one of the modules is checking to see if that cache is set, which is being set in our test setup.

+ +

So test setup sets the value. We're running the test but then in the module, the model checks to see if it's set, and it’s suddenly nil instead of using the cache that we had set. So now it's defaulting back to say, "Oh, it's unset. So let me go back and set it to the real cache," which is exactly what we're trying to avoid.

+ +

So then the question became, if we're setting the class variable in our class, why is it being populated in one of the modules but it's not being populated in the other module? So one of them has it set to the in-memory cache, but the other one does not.

+ +

So I'm going to gloss over some of the details because this stuff is pretty tangling. But essentially, when the test is running, and it's loading the class, and we are overriding that class variable, it's getting shared with one of the modules because as soon as one of the models does set that class variable, there's a bidirectional link that gets set between the parent class which is the module in this case, and the class itself.

+ +

And as soon as that module sets the class variable, then they're going to talk to each other, and they're going to reference the same value. However, this only seems to happen for one of the parents. You can't do this for both. So if you have two parents that are trying to share a class variable with the same class, that doesn't work. So that's a particular bug that we were running into.

+ +

I do have some good news because if anybody is very nervous about the situation that I'm describing, I feel you. The good news is that in Ruby 3, they actually warn when this is happening and have introduced an error. So you don't have this inheritance confusion that can come out of the fact that these parent classes are also trying to share a class variable with this child class.

+ +

So in Ruby 3, if you are writing a class variable in that class but then you try to overwrite that class variable in the parent of that class or by the module that's being included, then an error is going to be raised. So it's going to warn you if you're creating this bidirectional link between those two class variables and that you shouldn't be overriding the child's ownership of that class variable.

+ +

Instead, if you're going to use class variables, which, one, is not my cup of tea, but if you're going to use class variables, it should be defined in the parent class, and then it can be shared downstream in the inheritance versus trying to go upstream and then having your ancestors essentially override some of those class variables.

+ +

So all of that is to say we were on a very interesting journey of understanding how class variables work, how the inheritance works, how that bidirectional link is getting established, and then how Ruby 3 comes in to warn us if something funky is happening.

+ +

CHRIS: Oh, that is interesting. And I'm now going to catalog that as a piece of information that my brain will retain for roughly the amount of time that we are recording this podcast and then immediately forget.

+ +

STEPH: As you should. [laughs]

+ +

CHRIS: It's one of the reasons that I try to avoid inheritance. And I try to avoid class variables as much as possible because of this category of problem, a very subtle bug that you have to try and really hone in. And you have to be very smart to debug this sort of thing. I don't want to be that smart. I want to code in a way that I can be less smart on any given Thursday. That's my goal in life.

+ +

I will ask one other question, though. So there's just a cache that this class and pair of modules are hanging around with, and then you want to swap it out for in-memory. This sounds remarkably like the Rails cache. Is this cache distinct special? Could it not just be backed by rails.cache, THE cache within the rails context, which can be backed by Memcached, or Redis, or in-memory when you're in tests, or the NullStore, which I think is the default in development is probably how that goes?

+ +

Is there a particular reason? Is this a special cache? Is there additional behavior that this cache has beyond the normal thing? Or is it just like, at some point, someone's like, oh, I need a cache. I'm just going to use a class variable, that'll be easy, which it definitely is, but then you run into complexities.

+ +

And caches are one of those hard things to get right. So it's one where I would immediately be like, whoa, whoa, I would love to not make up our own cache here. So I'm wondering, is there a distinct reason, or is it just this happened, and here we are?

+ +

STEPH: So I think we are using a custom cache that we are pointing to. So it is another service. It's not a Rails cache or an abstraction that we can point to and use. It is a different cache that we are using. And I'm trying to think back to the exact code. But there is a method that essentially checks to say, hey, should I use the real cache? Should I use the in-memory cache?

+ +

And that is something that we've explored to find a way to make this more global for the test suite because we really want to control this for all the tests. Because it's very easy to not realize in the test that you should avoid using that shared global cache. And so that way, the tests don't interact with each other but instead always use an individualized cache for each test to make sure that it is self-sufficient and independent. But we haven't gotten that far yet in figuring out how we can take a more global approach with this.

+ +

CHRIS: Gotcha. So I don't know the details. I assume there are reasons here. But just to play this out, if we find ourselves saying we have a reason to have a distinct cache, to have a special cache over here, but it's a cache...and caches fundamentally, that word always will raise my attention. It will be like, okay, this is a place that bugs will come and aggregate. And we need a distinct one that has special behavior as an external service, or that is just something like in...

+ +

There's a wonderful blog post that Mike Burns wrote at one point that was about...I think it was something like things that will make me look at your pull request in more detail. And I really loved it because it did capsulate all of these like, yeah, there are good reasons to do everything on this list. But if you do any of them, I will look at your pull requests and be like, oh, that's interesting. Why are we doing that, though? Do we have to do that? Are you sure? Are you triple sure we have to do that?

+ +

And this is definitely one of those things where caches automatically catch my attention. Even if we're using the built-in cache, I'm like, do we need to? Is that a definite thing? And then all the more so when we're using a custom bespoke one. Again, I assume that there are reasons that there's something special that's going on here. Perhaps the caching behavior is distinct from just it's Redis, and we throw data. And if it falls out the backside, that's fine. Maybe you need entirely different behavior here. But it is something that I would poke at a bunch.

+ +

STEPH: Yeah, you're asking a lot of good questions. I will have to go back and look at some of the code because we spent enough time in Ruby specifics that I didn't pay as much attention to the cache. Because right now, as we are working on these tests, we're trying to fix just the test without changing the application code, one, because that feels like a safer space. And if the test is flaky, we're just trying to change the test first.

+ +

But some of these tests we're starting to realize I'm not sure we can fix the test without also changing some of the application code, or the way that we do have to fix the test is really an incentive to back up and say maybe now's the time that we look at some of the application code. Because another question that comes to mind is why use a class variable, and does this need to be shared by the class and the modules?

+ +

And there's a part of me that suspects that maybe some of this logic was extracted to a module, but then it wasn't cleaned up in the other places. And so that's why we still have a reference. And it's essentially then being shared and set and unset and reset in those different places. So I think you ask some good questions, and I have some more questions of my own when we have time to revisit that portion of the test and application.

+ +

As another example of some of the tests that I've been working on, one of the tests that I...because we have a list, we can usually tell some of the tests that are flaky. So one of the ones that I was investigating was a similar issue where there was a shared resource, and someone had tried to mock it out. So they had taken the time to say, hey, I don't actually want to use that real resource that's over there; instead, I want to just return the scanned value.

+ +

But instead, they'd accidentally stubbed out a class-level method instead of the instance-level method. And so it was running, but it wasn't actually stubbing anything else since that's the method that's not getting called. So that was just an oversight for that test. So I fixed that test. But I noticed that we were using allow any instance of, so then I did take the time to go through that file and change and move away from the use of allow any instance of.

+ +

And for folks that are less familiar with allow any instance of, RSpec has some really great docs that talk about how it's very helpful for dealing with legacy code. But essentially, it is a code smell that you're using; allow any instance of because you are saying that my test is or my code is so complex that I can't really mock out the specific instances that I want to and then return specific behavior. So instead, I'm having to use this more global approach to say, hey, any instance of this method, I want you to mock it out versus this very specific instance that I know that I'm working with.

+ +

But we can include a link in the show notes because there's a nice write-up that talks about some of the reasons that allow any instance of is not recommended. So that's been kind of fun. There's been a little bit of joy to get to refactor away from that and actually stub out a specific instance.

+ +

Part of the work, too, that I'm noticing as Joël and I are going through these tests is leaving breadcrumbs for other developers as well because they have a very large team. And they're very junior friendly, which is just incredible. I love that so much about this company. And because they do hire a lot of juniors, then it is a tough codebase. It's a fairly old codebase.

+ +

So as these juniors are coming in, they're seeing a lot of these patterns. And they're propagating these old patterns that aren't necessarily the best patterns to propagate. But they're doing their best, and then they are reusing what they're seeing. So part of the work as we are revising these tests, my hope is that people will see some of these newer patterns and use those instead of following some of the older patterns.

+ +

CHRIS: I can only imagine that you're writing borderline novels in your pull request descriptions and commit messages there. I do wonder, is there an index of those that you're collecting? So there's like, here's the test remediation examples list, and you're slowly adding to them. This was a weird one with a class variable. And this was a weird one that had flakiness due to waiting or asynchronous behavior. And gathering examples of those, but specifically from the codebase.

+ +

I could see that being a really useful artifact because I happily traverse through git blame all the time. But I don't know that that's always a thing. And frankly, I have to work for it sometimes. So if there is that list of here are pull requests that specifically did X, Y, and Z, I think that could be super useful.

+ +

STEPH: Yeah, that's a great idea. And yes, they have some shared team documentation that speaks to specifically flaky tests because they're aware that this is a problem. They are working together to address this. And they have documentation that states ways to avoid flaky tests. If you encounter a flaky test, here are some of the ways that you can triage to find out what's wrong.

+ +

So as Joël and I have been finding good examples, then we've been contributing to that document. And they also have team meetings. So our plan is to attend some of those meetings and be like, "Hey, this is just some of the stuff that we've seen this week, some of the things that we improved and changed," and share the progress that we're making.

+ +

Since everyone is aware that there are these developers that are working hard to improve the test suite, but then share that information with the rest of the team so they too can feel...one, they can just see the changes that are taking place. But they too can also benefit and apply those strategies themselves when they see a flaky test.

+ +

Oh, but you did just remind me of a thing. So one of the tests that I was going through...I'm very intentionally going through and making the smallest change possible. So I will do the gross, ugly fix whatever it is to get something to pass, and then I will commit it. And then I'll think about okay, well, how can I make this better? So essentially, I have the fix, whether it's pretty or not. And then, after that, I start to have other commits that make it prettier.

+ +

And so, I had a pull request that had four commits that told the story that I was very happy about and progressed along in a more positive direction. And I issued that, and I discovered that Gerrit, when it sees four commits, it split all of them into their own change request.

+ +

And so, instead of having what I thought would be this nice story, now got split across these four change requests. And I thought, well, that's less helpful. So I ended up squashing two of them, but I still kept three of them because they stood alone, and each told a story. But that's something that I've learned about Gerrit.

+ +

CHRIS: Always so interesting how our tools shape our work.

+ +

STEPH: And it made me think back to the listener who asked the question about ensuring that CI runs for each commit. Well, here you go, Gerrit. [chuckles] Gerrit does it for you. It ensures that every commit gets split into its own change request.

+ +

CHRIS: I mean, as you said earlier, not my cup of tea but... [laughs]

+ +

STEPH: Yeah, I'm still lukewarm. I'm still discovering Gerrit and how we get along.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

What else is going on in your world?

+ +

CHRIS: In my world, we keep adding new users to the system. We keep doing more stuff. These are all wonderful things, the direction you certainly want to be heading. But as we're doing that, I've recognized that we had a lack of process and a lack of formalization of certain things.

+ +

And a lot of the noise of the work was just coming to me because I was the person that everybody knew. I can ask a question; Chris will know the answer, et cetera. And then there were things that we needed to keep an eye on. But because it was everyone's job, it was no one's job. So we've introduced the idea of a point person on the engineering team. So this is a role that will rotate each week. I think you and I have worked on a handful of projects that had something similar to this.

+ +

There was a team that we worked with that had an ad hoc list, which were just little tasks that needed to be done by developers. So there was one person who would run with that. I've heard it called captain before, the sprint captain. We're not really doing sprints. So for various reasons, that title didn't work for me. But point person is what I went with here.

+ +

And so the idea is rather than having product management or anyone else in the organization just individually reaching out to developers, we want to try and choke that off, have a single point of communication. And so just today, I introduced into Slack, a group, but it's a group of one person. So @pointdev is technically the handle for this person. It’s a group in Slack. And each week, we'll rotate who the members of that team are. And technically, you could add multiple, but the idea is this is just one person. So we'll rotate the person.

+ +

And what ends up happening is if anyone...say the product manager says, "@pointdev, what's the status on..." blah, blah, blah, that will notify the person who is the point person that week. So that's a nice feature in Slack so that we can condense it down and say rather than asking individuals, ask this alias. We're introducing one layer of abstraction in our communication tools, much like we do in our software.

+ +

So I'm drafting now the list of like, here's all the stuff that I think this person...because we're trying to push all of the quote, unquote, "other work" the non-product feature development work into this person's purview for a given week. So it's monitor Sentry for any new errors as they come up, triage them, and figure out what we want to do.

+ +

Ideally, and this is perhaps aspirational, I would like to keep inbox zero in Sentry. I know how you feel about that more generally and perhaps even more specifically within the world of errors, but that's my dream. We're going to see how it goes.

+ +

STEPH: I don't know if people know I am the opposite of inbox zero. This is the life that I'm living.

+ +

CHRIS: What about with errors, though? What about something like Sentry?

+ +

STEPH: I want to say that I would be a better human with my email. But I'm going, to be honest [laughs] and say that I would probably have the same approach where I am not an inbox zero person. I've come to terms with it. I used to really strive and think I needed to change. But I have reached a point of comfort with this is who I am. There are many like us, so shout out to all y'all.

+ +

CHRIS: Oh yeah, by far the more common approach, I think. So specifically with the errors, I struggle a bit with it because what ends up happening is we are implicitly ignoring the errors. And if we're doing that, I would rather just sit around and have a conversation and be like, let's just explicitly ignore them. There's a button in the UI. We can ignore them.

+ +

If this is not a real error, we can add it to the list of things that we do not report on. We can ignore that error. We can ignore it for a week and add a card to Trello that has a due date that says, "Hey, we got to work on this." But let's take that implicit indifference to that particular error mode of our application and make it explicit.

+ +

Let's draw that line in the sand such that when I see a new error pop up, I'm like, oh, that seems like something I should do something about. I really want high signal-to-noise when I'm seeing errors coming. And so I'm willing to work for that. But it is a trade-off, and it does take effort.

+ +

And it's noisy, especially browser extensions, and whatnot, just fighting the page. Facebook showed up one day. I don't know how Facebook got in there. Someone was browsing our website from within Facebook's browser, which I didn't know was a thing, but they had their own thing. And it fires a bunch of events, and Sentry was just like, let me slurp all of those up. Those seem fun. That was noisy. So we had to turn those off, but we explicitly turned them off.

+ +

STEPH: I do like the approach that you're taking where it's one person, and then it's a rotating shift because I think that makes it more reasonable for someone's who's like, hey, this is going to be noisy for a week. And then you're going to look through these emails and check all these errors, and then either silence them because you don't think that they're interesting or mute them for now. Or if you're going to convert it into a ticket, set a due date, whatever the triage approach is going to be.

+ +

But that feels more achievable versus inbox zero for life is just exhausting. But I feel like if you're doing it rotating week by week, that seems like a nice approach and also easier to keep it at inbox zero because that way, you are keeping up with all the errors. Because I agree; otherwise, what's the point of tracking all the errors if you're just going to ignore them?

+ +

CHRIS: Yeah, definitely the rotating, I think, is critical. I think the other thing that's been critical specifically on the error front is we've had now a handful of meetings where we triage the backlog together, the backlog of errors. So like, what all is coming into Sentry? What's going on? And we go through the process of determining is this a real thing? Should we fix this? Should we ignore it?

+ +

And we do that together so that it becomes not just one person's intuition about whether or not this is important or not or what the source of it might be but a shared intuition such that now any one of us, when it's our week, can ideally represent the team in that way and be like, never mind, never tell us about this again because it's very easy to silence things in Sentry that you would actually like to know about when they become real. But right now, we have this edge case that is an ignorable version. So trying to get there that's been fun.

+ +

But yeah, once again, Sentry, that's one of the things on this person's list. There are ad hoc support tickets for our operations team. So anything that needs to happen on a user's behalf that currently needs a developer to console, let's funnel all of those to this one individual, respond to any new questions. So this is where that Slack handle will be useful.

+ +

Check for any stuck jobs in Sidekiq. So is there anything that's been retrying for a while? Because it probably shouldn't. Maybe one or two retries is cool, but past that, something has gone wrong. And we should either get in there and fix it or just kill that job because it's never going to succeed, which is quite often the case but go in there and keep an eye on those and then look for anything.

+ +

We're starting to use due dates within Trello, which is currently our project management system. We'll see. Someday we're definitely going to grow out of that. But for now, it's good enough and checking for anything that's overdue or coming up in the next week in terms of due dates and just making sure that we're being responsive to that.

+ +

And so, I really like the idea of having this be a named set of things and a singular focus for one individual. Because again, that idea of like, if it's everybody's job, it's nobody's job. Or if it's nobody's job, then it's my job, and I don't want it to exclusively be my job. [chuckles] So I'm trying to make it not exclusively my job and to share the knowledge about it and make sure that these are skills that we all have and ideas and et cetera. But also, I would be fine to answer fewer questions in Slack each day.

+ +

STEPH: I have to admit, as soon as you were telling me that you had established this role, I was quietly congratulating you on helping delegate some of these responsibilities to the team. Because like you said, you are then the person that takes on all these tasks.

+ +

CHRIS: There's a laziness to that. Like, it's easy for me to just answer the questions. It's harder for me to put up a wall and say, "No, no, we have a process for this." And quite possibly, what's going to happen behind the scenes is that questions are going to come in to whoever is this point person. They're not going to know the answer. They're going to reach out to me, and then that conversation is still going to happen. But even by doing that now, now that person will see that answer, will understand the thinking or the background, the context that I have.

+ +

And so it's that weird thing of like, it would be so much easier for me to just answer one question. But to answer all the questions, well, I can't do that. And so I'm working to try and do more of the delegation to try and hand things off when they're in a known state and to identify this sort of stuff so that the team broadly can be stronger and better able to support everyone else in the organization. So that's the dream. We'll see how it goes.

+ +

STEPH: Yeah, I love that approach. I'm also thinking how interesting this role is because I'm imagining a mix between someone who is like the front point person at like an ER. So like, things are coming in, and they're in a tragic state and need help and need to be diagnosed.

+ +

But at the same time, you mentioned they're going around. They're checking Sidekiq. They're looking at some email errors. So they're also that night shift guard that's walking around with a flashlight just poking in each room. So it seems like a very stressful and low-key role all at the same time, all mixed up into one week. That person probably needs a beer at the end of the week.

+ +

CHRIS: There is a version of the story in my head that is...I wouldn't say this feels like a failure mode, but I would rather this not have to exist at all. I would rather things to be calmly humming along and not require a dedicated person each week to deal with the noise. I don't think that's realistic, certainly not as early on as we are in our organization. But I do wonder, is this a crutch? Is this something that we should be paying more attention to?

+ +

And I know in teams that you and I have worked with in the past that has been a recognition of like, this is a crutch. But it's a costly crutch. Like, we're taking an entire...in our case, it's not requiring the entirety of a developer's week. They're able to do this pretty easily and then still get a bunch...like, 75% of their time is still feature work. But we're just choking down who's the person that will be responding to questions when they pop up so that fewer individuals are interrupted?

+ +

But I have seen organizations where this definitely filled an entire week and spilled out more than. And then there was the recognition of that and the addition of another person that comes along and tries to fix stuff along the way as opposed to just responding. And so I want to make sure this isn't a band-aid but is, in fact, a necessary layer that we then try and shore up, you know, we should have fewer errors. That feels true. Okay, cool. Let's fix the bugs in the app.

+ +

And these ad hoc things that an admin needs to have done can that be a button in the UI? Can they actually self-serve in those cases? And we're slowly moving towards those. Ideally, fewer jobs get stuck in Sidekiq. And so, my hope is that this isn't a job that gets harder and harder over time. It's a job that potentially, if we're being honest, probably stays about this hard. I don't think it's ever going to be just like, nope, nobody needs to do anything. The app just runs, and it's great. And it never has bugs.

+ +

But that is a question in my mind as I start to embrace this thing of like one person is dedicated for a week to this. And if right now it's only 25% of their time, okay, that's probably fine. But if suddenly it's 50% of their time or 75% or 100% of their time for that whole week, that becomes too high of a bar in my mind. And I want to keep a close eye on it and make sure it's not trending in that direction. And I will be one of the people on the rotation. So I'll get to be in the trenches.

+ +

STEPH: I appreciate all the thoughtfulness that you're putting into it. And I'm thinking back on a project where we had a similar rotation because we had an issue Slack channel. And so anytime there was an issue, then it would get posted in there. And before, it was going out to everyone, or there was one particular person that was always picking it up and then trying to delegate it to others as they needed to. But then we started a similar rotation.

+ +

And one of the key benefits that I found from that is it signaled to the team, hey, this person might get pulled away. They can pick another ticket or two, but we need to give them lower priority tickets because there's a chance that they're going to get pulled away to work on something else. And that's okay, and we're going to plan for it.

+ +

Versus without this role in mind, then you had people all taking on high priority tickets, but then someone had to be the one that's like, well, I'm going to punt on my high priority and feel stressed about the fact that I've got this other thing to deal with. But then, I didn't actually do the work that I planned for.

+ +

So I feel like you're helping introduce calmness into the week, even if it is a stressful role. But then there's the goal that this becomes less of a stressful role, and if you see it trending in the opposite direction, then that's something to investigate.

+ +

But I also feel like triage and communication is such an important part of being a developer that it also feels very relevant upskilling for the whole team to go through. So there's also that benefit of where this approach also empowers the rest of the team to also experiences, build empathy, look for additional fixes, and then also build these important skills.

+ +

Overall, I really applaud your thoughtfulness. And I think it's a really good idea. And it will be interesting to see which direction that this role trends if it gets easier or if it's getting harder over time.

+ +

CHRIS: Well, thanks. I appreciate that. And I'll certainly report back as we develop this but hopefully, it stays about where it is. That feels right. And I think I'll probably...that's one of those things that I will monitor. And if I feel it moving in the wrong direction, then step in and try and get it back to this space because this feels like a maintainable reasonable amount.

+ +

And we shouldn't be fixing every bug and adding every button to the UI. That's just actually not how it works, unfortunately, would love to. That's not true. You shouldn't have every button in the UI. That's so many buttons. But broadly, I hope we can maintain roughly this, and I think identifying it and laying it out now I'm feeling good about having that structure. So yeah, we'll see how it goes. Will report back. But again, thank you for the kind words.

+ +

With that tour of a bunch of different things, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeee!!!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+0RKfOA7m + + ]]> + + Chris Toomey + Steph Viccari + + + 320: Remember The Fun: 2021 Recap + https://bikeshed.thoughtbot.com/320 + 4ccdde34-6cf0-4c9c-b547-29df8ea6d61c + Tue, 21 Dec 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph and Chris recap their favorite things of 2019 and 2020 and share their 2021 list. Happy Holidays, y'all! + 34:02 + no + + + Steph and Chris recap their favorite things of 2019 and 2020 and share their 2021 list. Happy Holidays, y'all! +Steph: +* Feature flags and calm deploys +* Creating observable systems +* Debugging +* Working in seasons +* Don't forget the fun +“The longer I’m in the software game, the more I want things to be calm” - Steph +Chris: +* Pushing logic back to the server +* Svelte (https://svelte.dev/) +* Remote work (but maybe hybrid!) +* Vim +* Joining a startup as CTO +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Listen to episodes from 2020 and 2019 👇 +Episode 274 - Top 10 of 2020 (https://www.bikeshed.fm/274) +Episode 273: Retro on Top 10 of 2019 (https://www.bikeshed.fm/273) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Are we taking off the next few weeks? +CHRIS: According to Steph's schedule I think we are. +STEPH: You know, that's Steph and her schedules. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? +CHRIS: Well, this will be our last episode for 2021. So that's new collectively in all of our worlds, I think, which is exciting. We'll be taking off the next few weeks for the holidays. But as has become tradition, I think it is time for you and I to review some top 10 lists from last year or two top 5 lists, and then maybe you share some new favorite things. How does that sound? +STEPH: Yeah, I'm excited. I love that we take this time to reflect about what we enjoyed about the past year and share our top things. It's like Oprah's list. You know Oprah has her list of favorite things, and we have our list of favorite things. +CHRIS: It is almost exactly like Oprah. +STEPH: It feels a bit blasphemous to compare our list to Oprah's list but here we are. [laughs] +CHRIS: I tried to give the hyperbolic sarcasm there to be like, and let us be respectful of...but yes. +STEPH: Good. You got it. [laughs] So to prep for sharing our new list of favorite things, do you want to start by going through the list of favorite things from last year? +CHRIS: Sure. And just as a reminder, if anyone does want to listen to the episode and hear a bit more detail about our thinking on these, we covered this in Episode 274. But for me, the 5 items that I covered last year were Tailwind CSS. So the utility-first CSS framework which I continue to love and use on every project that I possibly can. +Remote work, that was a relatively new and novel thing for me at that point. Similarly, I have continued on with that and if anything, leaned into it all the more. +Next up is Svelte. Svelte is a JavaScript framework that I have grown to love even more over the past year. Spoiler alert, that may show up later in the episode. +Next up, we had Postgres, PostgreSQL, the database engine that is wonderful, and I had spent a lot of time with last year. Frankly, I haven't spent as much time with it this year but it’s still something that's near and dear to my heart. +And the last was Inertia.js, a framework that although it's got js in the name, it's both server-side and client-side and binds it together and gives a wonderful experience. I believe I've talked enough about that throughout the rest of this year that perhaps you've heard me mention it in a previous episode, listener. +But yeah, that was my top 5 for 2020. What about you, Steph? +STEPH: All right, so the things that I had from last year are one-on-ones. I don't remember exactly what I said about them, but I am still a fan. I still very much enjoy them. I learned a ton from them either participating or leading them. +Rails, also still a fan. Async communication, yes, love it. It really helps more people be involved in the conversation when it's async communication. feature flags, also still a fan. And Elixir and Phoenix is on the list also, still a fan although frankly, haven't done as much with it. +CHRIS: So, Steph, I have a question for you. Actually in preparing for this episode, I re-listened to Episode 274, which had our top 10 list for 2020. And then I also listened to 273, which was the previous episode which had our retrospective on the list from 2019. So at this point, I've now reviewed all of these lists, which is now 10 items, and 10 items for each of us. +And what was interesting to me, at least from my side, and especially as I was preparing for this year, is stuff's mostly stayed the same. I kind of still like most of the items on the list. And certainly, nothing has changed in a deep way where I'm like, you know, I used to really like this, but I don't like it at all anymore. So I'm wondering, is that the same for you? Is there anything that you've changed your mind on amongst this set of items? +STEPH: Looking at the list, I still really like everything on the list. So there's nothing that I've changed my mind about significantly. I'm realizing as we're creating this list each year, it's likely a list that I'm going to continue to grow and add to instead of subtract from. +Most of the stuff, I guess because we have a full year by the time we get to this point, I feel pretty good that this is something that I like in the world versus something that may be more of a month to month experiment that then I'd change my mind on. So everything on the list still rings true for me. And I have some new stuff that I'm going to add to that list. +CHRIS: Ooh, new stuff, exciting. Yes, this is what we're here for. So, Steph, let's dive in. What do you got? +STEPH: So in preparation for this episode, I started thinking through all the different ideas that I wanted to add to my list and all the topics I'm excited about. And I started to wonder what are the things that we really said? What can data tell us about these episodes versus just trying to think through my feelings of the past 12 months? Because it's very easy that I forget things that were important to me at the moment. So I started wondering, what data could I collect from the different episodes? +And now that we have transcripts that started back in I think around May of this year, I built a small little Ruby program to perform a word frequency analysis and generate a very low version of a word cloud. But I wanted to find what are some of the top things that we said? And it came out rather poetic. And I tried to ignore some of the small words just prepositions, and a, and the, and things like that were that were less interesting. +So here I've got a couple of different lists, a couple of different facts that we can explore. So here are the top 10 words that we said. So there's code, great, write, feature, question, idea, interesting, love, no, and laughs. +CHRIS: Laughs is in parentheses or brackets to say this is where they're laughing? +STEPH: Exactly. +CHRIS: Wow. A, that feels true. B, that's just delightful. And I'm so glad that you did this. For anyone listening at home, this is a complete surprise to me too. So I'm really enjoying going on this ride. But yeah, that feels like a representative list. +STEPH: There's another poetic one because then I started looking at some of the episodes individually as I was building this out to handle all the episodes. This is over 28 episodes. And so I pulled a specific episode with Joël Quenneville where we talked a lot about debugging. +And so the top words from that episode are debugging, people, think, don't, love, time, bug. And it's fun no matter how you hear that or read that you get something new out of it each time. And now I'm really into this word frequency art or whatever it is that we're going to call it. +CHRIS: That's fantastic that I want a little bumper sticker of that amongst the bumper stickers that I've claimed I want from things we say on the show. I want that one with Joël's face on it right there. That seems like a perfect item. +STEPH: So I also tried to figure out how many times we said it depends. And that one got a little trickier, and I was also surprised. But according to the data, we've said it depends around 10 times. And I feel like that's low. +CHRIS: That feels very low, huh. +STEPH: It does. I agree. That one feels a bit low. And so those were the fun, more poetic like, what are the top things that we said? And then I started looking for more what are the technical things that we talked about, some of the different frameworks or languages? So I started looking specifically for those. So over these 28 episodes, we said Rails 200 times, which is a lot. [laughs] +CHRIS: Good job, Rails. Way to show up on the leaderboard. +STEPH: And then next in that list data, some form of test, tests, or testing. We said around 230 times database. Ruby's next on the list at 140, then Sidekiq, retro. Monitoring is a big one. JavaScript, agile, REST. React, React is at 52. I was intrigued that React was spoken as much because I know I haven't worked in React in a long time. So I'm going to give you credit for that one. Manager, Svelte, Svelte, and Inertia are both around 45, 40 times that they were spoken. Python, Postgres, Rust, Elixir, Elm, Vim, and tmux. +CHRIS: Wow. I like that list. +STEPH: One other fun data point is that we said the word hard 20 times more than the word easy. +CHRIS: That feels fitting. +STEPH: It does, right? +CHRIS: I love this work, but it's not easy. +STEPH: Yeah, I appreciated that. I was like, that's true. +CHRIS: [chuckles] +STEPH: So that was some fun with words and frequency analysis, and it was neat. So I'm excited to do this for more episodes and to do it per episode because it highlights some interesting themes for the episode. +So pulling just from the data, then I'd say the top things from my list are Rails, data, testing, Ruby, Sidekiq, and retro. Those are the top things. But I'm still going to be creative with it and add to the list the things that I want to include on there. +So the first one this one is a bit of a repeat, so that's why I'm going to bring it upfront. But it's feature flags and calm deploys. That is something I am still a big fan of that I really appreciate. It can lead to some slightly increased tedious workflows depending on how diligent you are in feature flagging your work and keeping new work behind that gate so then you can turn it on when you want to. Also, the data supports it. We said flag like 67 times over 28 episodes. And I'm betting that was coupled with feature flags. So I feel pretty good about that one. +CHRIS: I think half of them were probably flag football is my guess if I remember what we talked about. +STEPH: We do play a lot of flag football, uh-huh. +CHRIS: It's interesting that you're leading with that. So one of the other items that I pulled out as I was reviewing the previous episodes was a quote that you made that resonated deeply with me in that moment and all the more so now. And everything I think about software probably falls a little bit under this bucket, which is...this is the quote from you, "The longer I'm in the software game, the more I want things to be calm." +And I think my response in the moment, which is why this was primed in my head, was I want a bumper sticker of that. I want it on a t-shirt or get a tattoo of it. [laughs] And I stand by those words because that's a beautiful sentiment and definitely, for me, speaks to a lot of the work that I want to do and how I think about what I put importance on. +STEPH: Thanks. Yeah, I find it makes a really big difference in terms of the quality of the work and then also, the happiness of the team. How about you, what's first on your list? +CHRIS: First on my list this year is going to be...it's a little bit of an abstract concept. So we'll see how well I can define it in a small amount of time. But the phrase in my mind is pushing logic back to the server. Over the past many years, let's call it like a decade or so, I've seen this gradual shift where more and more logic is being implemented client-side. And client-side can mean a bunch of things. It can mean a JavaScript client that gets downloaded and then runs. It has lots of smarts in it and knows about all the business logic but also iOS apps, Android apps, et cetera. +And every context that I've worked on that I felt the pain of now we've got our business logic distributed across all these different systems. I've seen some really interesting approaches to try and bundle up the logic and use it in a shared library. Perhaps in JavaScript, I've even seen some other approaches where this is a bundled C++ library that we somehow embed in every context that we want to run. And that's where the business logic is. But fundamentally, I felt a ton of pain from that. +And I've always had this idea in the back of my head that wherever possible, I like to pull logic back to the server because the server is this safe space with all the knowledge that I want in the world. And I can have secret environment variables, and I can add the database. And I can combine different sets of data very easily. And I can have the logic implemented in a single place. And that's wonderful. +And more and more, I've started to pursue this. Some of my work with GraphQL was an attempt to get this because a REST API is just like, here's a bunch of data. Combine it how you will. Have fun, front end. Whereas the GraphQL API starts to be more about the relationships between the data and the connections. And you can ask more interesting questions of a GraphQL API in my mind and ideally then push some of that logic back to the server because the GraphQL API encodes it in relationships and whatnot. +But probably the thing that has helped me the most on this is Inertia.js which was on my list last year. It remains something that, if anything, I tripled down on my enjoyment of Inertia.js. But it allows me to continue building my logic such that it's on the server-side. +And I don't need to implement a client that knows hey when a user adds an item to their cart, I also need to update that little icon in the top-right corner. I don't even need to think about that because Inertia uses the traditional request-response lifecycle, but then handles it in a smart, forward-thinking possibly animated way. And I'm just very happy with that and all of the explorations that I've had around pushing logic back to the server. +And actually, as I explore this even a little bit more, at my company, we're now starting to explore building native mobile apps. And we're trying to figure out what that means for us as I try and cling desperately to this idea of pushing logic back to the server. So that'll be a topic that I would love to chat with you more about in future episodes. But I think I found a way to, as I said, cling to this idea of pushing logic back to the server. So yeah, that is item number 1 for me. +STEPH: I'm very excited for those future conversations. You reminded me of something that I've heard from someone else at thoughtbot. I believe it's Stephen Lindbergh that said this. He was giving a presentation talking about forms. And one of the things he said was, "Stop using client-side form validations." And that's a bit of a blanket statement. And there are always some caveats with those statements. But when he said that, I thought, yeah, that sounds great because you have to validate it on the back end anyways. Let me rephrase that, you should validate it on the back end. A lot of applications don't. +CHRIS: I would go with have to just some opt to not despite the fact that they definitely have to. +STEPH: That's true. I just wanted to fuss at the people who aren't doing it. [laughs] +CHRIS: Steph's getting to fussing. +STEPH: And I just really liked what he said because I understand why people started adding more client-side validations because then they think well, this creates a better experience for the user. We can give them faster feedback. +But if you get to the point that you're actually hindering their experience...like if you've been filling out a form and it's telling you that you're incorrect, and it's because you haven't met the specific regex they're looking for, that annoying behavior that you see on forms that's often a result that I see from client-side form validations. +Also, if you're at the point that you're using form validations to drive the user to do the next thing, there's a good chance that form is too big. And there's an opportunity to break that up into a smaller workflow. So that way, you're not using validations to essentially coerce or force a user into a particular path and use more helpful ways to help guide them through that process. +So I'm very excited for our future conversations about pushing more things to the server. And side note, stop using client-side form validations or just reduce it. Dial it down. Don't dial it up, dial it down. +CHRIS: Oh yeah. That is such a great example of this theme. And again, hopefully, we'll chat more about this in future episodes. But yeah, so that's item number 1 for me. What is item number 2 on your list? +STEPH: So this one I really want to say thanks to you because I feel like you've brought a lot of topics and conversation about this particular idea to the show. And that has really resonated with me and influenced me as I've joined different projects that either have observable systems. And then that has been really helpful as then we are jumping into the project and debugging and then contributing to that system or where they're lacking that observability. And that just makes work and life so much harder. +So thank you to you and everyone else that has contributed in having conversations about observable systems on the show. Specifically, I'm thinking of the episode with Charity Majors where she talks about observable systems. And so that is number 2 on my list. +CHRIS: Oh yeah. I do love some observability. It's one of those ideas that once you get it in your head, you can't shake it. You can't unsee that you can't see what's going on in your runtime system. +I will say the app that we're building, the core Rails application, we've instrumented it heavily because we're trying to get in early on the observability game. But now we can see everything. And we've yet to really get to that deep understanding of like, that's just noise. We don't need to care about it. So let's silence those. Let's dial these up. These should go piped into Slack and how to sort of triage that. +So right now, it is a bit noisy in our world. I'd rather that than the silence, than the crickets of I don't know, something happened. There is a form validation, but it seems fine. It's happened a lot since the last deploy, but that seems fine. I'm trying to avoid that kind of stuff. But as a result, sort of the rough edges of the early times in observability, but yeah, huge fan of that. Glad that that made it onto your list. +For number 2 for me, this is a recurring theme from last year, but I've doubled if not tripled down on it. So this will be Svelte, Svelte the JavaScript framework that is just so fantastic. The more time I spend with it, the happier I am that I've leaned into it. I took I would say a tiny bit of a gamble in choosing it for the view layer for the application that we're building. It's not as popular. It doesn't have nearly as much community, mindshare, shared libraries, et cetera, et cetera. +But A, because we're working with Inertia, Svelte occupies a smaller portion of our application architecture. So that made me feel more comfortable with that decision. And I liked a lot of the fundamentals that I saw on the Svelte community. And over the past year, I've just seen each of those get reinforced. Svelte wonderfully leads with accessibility as a primary concern. +And one of the things that I see is although there are fewer packages out there in the Svelte ecosystem, the ones that there are very often like, and of course, we thought about accessibility, and screen readers, and keyboard navigation, and all of that. And so you don't even need to worry about that. It's like, thank you. That is wonderful. +Likewise, SvelteKit is a project that came out. I believe it was released, and I think it's 1.0 now or at least it's on its way to 1.0 now. And it's starting to get real usage. And that's a Next.js-like framework that takes your Svelte application and allows you to build it, run it, compile it. You can use it for packages. You can use it for apps. Wonderful stuff in there. And it's a great answer to how do I actually build a Svelte app or a Svelte package? +Likewise, Rich Harris recently moved to Vercel. Vercel is one of the big names in this world of we're building fancy applications on the internet. And so that's a huge vote of confidence for the framework. And now Rich Harris the creator of Svelte will be working on it full time. So it's just a bunch of signals that are pointing at although it's still definitely not nearly as popular as even Vue or certainly not React, Svelte is a wonderful choice. And I have enjoyed every minute that I've worked with it. +STEPH: I like how you're doubling or tripling down on Svelte. I've heard so many wonderful things about it. I feel like I should be a pro at Svelte at this point from everything that you have shared and brought to the show. But I'm still looking for that opportunity to get to test it out. So I'm excited to hear more about it next year. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days, no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +So third on my list, this one is more...it's something that I'm toying around with. I don't really have any concrete answers around how it's going to look but something that I'm interested in exploring further. Based on earlier this year, I took a month's sabbatical and that was phenomenal. I felt like this incredible reset, and then I came back more energized and interested in my work. And also, I got to explore other facets of life that I just normally didn't have time for. +So number 3 on my list is the idea of working in seasons where you are focused and work really hard on a project. And then let's say you take a couple of weeks off in between, and then you go on to your next thing. But I like this idea of chunking my work time because I found I'm very much a person that I'm on or I'm off. And it's very hard to create that balance between those two parts of myself. +And this may be a nice way to do it to say, I'm committed. I'm doing this for six months. But then I know I'm going to book a vacation, and I'm going to take a solid two weeks off or maybe even a solid three if that's something that my work and time allows. But I'm very interested in that idea. +I think it came from a conversation with someone else about academia life and how that is an approach they take where they work in those seasons where they work for the academic year, but then they take a summer off, and then they go back to work. And I very much like that idea and that approach to work. +CHRIS: This is such an interesting topic in my mind. I grew up both of my parents were teachers. So for the entirety of my life, I got summer vacation and my friends got summer vacation, and my parents got summer vacation. So clearly, everyone in the world got summer vacation. This is just a true thing about the universe. +And then spoiler alert, I learned the truth; it is different out there. So that took some getting used to. And then I have done an absolutely terrible job of this. This is an idea of like, I believe in this idea, the phrase that you used of living in seasons. It makes so much sense to me and seems like such a useful way to be. But I have at most taken two weeks off at any given point in my working career since I graduated college, and that was for my wedding. And that was it. +And between jobs, one time I left work like 15 minutes early on Friday, and then I started the next job on Monday. That was one of them. And then I did take a week off between my most recent job switch, just a whole week. Well, actually, that's not true because we recorded The Bike Shed in the middle of it, and I took a bunch of meetings to be ready to start. I'm terrible at this. Even though it's an idea that I believe in, that I want, I have never pursued this in a deep way. And it's something that I would really love to do. But yeah, I've not really done it. +So you mentioned academia and so there's the natural cadence to a year. But there are also sabbaticals. That's a thing that exists in the world. It's an idea that's already out there. Once every seven years, you get to take six months off just to go on an adventure. That sounds fantastic. I would like that, please. So I got to make that work in the world somehow, probably not for a couple of weeks, though, because I'm in an early-stage startup at this point. And so I probably got to hang out for a little while and get some stuff done. +STEPH: I like how you pointed out that sabbaticals exist; those are a thing. You also mentioned that a lot of times, maybe there's seven years or five years is what I've seen at companies before you get a month off. And while that is wonderful and much appreciated, I am interested in finding a way to include sabbaticals or at least those breaks more often in my life. Because I know I'm someone that I'm going to be focused on, and I'm going to work hard. And rather than just continue to do that and then one day burn myself out, find ways that I can have more of a structured this is when I'm on. This is what I do. It's what I'm interested in. I'm excited about this. +But now that I'm done with this after six months, let me go take a solid two, three weeks off to reset, recharge, find some other hobbies, and then come back to this. And I think that will make for a much longer and happier career. So I haven't worked out the details, but it is something that's on my mind. So that is why it is my number 3. What's your number 3? +CHRIS: My number 3 is perhaps in a similar space. And again, this is another one that was on my list last year, but I've leaned into it all the more, and that's remote, working remotely, working from home, et cetera. I have embraced it all the more this year. +The new company that I've joined we are a remote-first company. And so that is the mode that we're going to be working in. And that was something that I certainly pushed for because I feel like it is meaningful across the board. And if you're intentional about it from the beginning and think about things like async communication, and how do we handle this, that's all the more meaningful. +But also as vaccines and things like that have become available in the world, last year, remote was just the thing that we did. And this year, it was more of a choice and also was offset by the occasional in-person meeting. So the other folks that are in the company currently are co-located around Boston as well. +So we've had a number of days where we'll go downtown meet at a WeWork or some other shared co-working space. And we can have the occasional bit of in-person time. But we try and be very intentional with that. We try and make sure that when we're going to do that we have an agenda, even if that agenda is just connecting and socialization, which I think is deeply important. And that is incredibly hard to do just over Skype or Zoom or any of those tools. +But then the vast majority of the time I get to not have a commute. I get to work out more easily. I can cook dinner more easily. I can go for a longer walk with my dog. All of these things are just options now that are so, so meaningful and allow me to have a slightly calmer cadence to my life which is a thing that I want both in the work and in the life. +So I'm all for remote and perhaps tinged with a little bit of hybrid in person, kind of figure out how to get that right optimization. But yeah, big fan and will be continuing to do it with the caveat, and this is something we talked about the previous time we talked about it. This makes a lot of sense for a certain point in your career. I still wonder about how to make this work for folks that are newer to the industry. Junior developers joining a team being remote feels like it would be very complicated. So at a minimum, needing to be incredibly intentional around that. But also, is that even the right answer in that case? I don't know. +STEPH: I have feelings about that one. But I'm going to punt for now for another episode because I think that's a really great topic to dive into. And yeah, we should talk about that more. +CHRIS: I look forward to that conversation. But yeah, remote, that is my number 3. And with that, I will send it back to you for your number 4. +STEPH: I love that one. I'm a big fan of remote work. All right, for number 4 it's debugging. So I feel like we've had a number of conversations. Joël Quenneville has been on the show to talk about debugging and debugging not just for the art of it and the necessity of it but really building concrete skills around how to debug and then finding ways to share that information with others is really powerful. +And I feel like it's something that a lot of people just pick up on the job as you go, which is great. But it'd be great if we could create shortcuts for people. So then that way, they can have that information sooner rather than just waiting for a painful experience and then happen to pick up new tools for debugging. So debugging is a big one for me. +I also think that's representative of the type of projects that I've been on this year where a lot of them have been more triage-focused and how important debugging skills are in that moment, which I'm sure is also why observable systems is on the list. So for my number 4 is debugging. And we'll link to Joël's episode about debugging because it's delightful. +CHRIS: Debugging, one of the most pointed examples of alchemy in our work is the intersection of art and science and craft and all of that. And yes, debugging, what a fun topic. +But for my number 4, this is a return from two years ago, and this is Vim. I finally feel like Vim is starting to catch up, the promise of the language servers and VS Code, and the way that it works. I guess I've said this every year. I know. I'm aware. +STEPH: I'm laughing because I thought for a moment you're going to be like, I finally feel like it's working for me. [laughter] +CHRIS: I finally learned how to quit Vim. I've just had one instance of Vim open for the last 13 years because I didn't know how to quit it. But that has been fine. And then I finally learned how to quit it. No. Vim is finally catching up. +The Neovim just came out with a new version that's got tons of deep integrations VS Code-like features. Thanks to the wonderful work of the VS Code team and the respective language servers from all the different communities. The promise of the editor ecosystem rising tide lifts all ships is coming true, I think. +And even right now, I haven't even jumped to that new Neovim version. But the version of Vim that I'm working on with the current config is great. It works. It does the thing. And that's awesome. And it's only going to get better from here I think. +So 2022 is the year of Vim on the desktop. That is my strong bet. That's a joke about Linux in case anyone doesn't get it. It's not a good one. But it is a joke about Linux. So that's my number 4. Back to you, Steph, for your number 5. +STEPH: [laughs] And this is another count for our laughs in parens for next year's frequency count. Well, I guess it is still this year. +CHRIS: I absolutely love that that made it onto the list of top 10 things just [laughs] laughter off to the side. +STEPH: All right. So for my final, number 5 is don't forget the fun. And I say this because while work can be very interesting and fulfilling, I have found for myself this year that I also really needed some downtime to just play, to just experiment. And initially, sometimes I was worried where I felt like a lot of the work I was doing often wasn't building, but it was more correcting or fixing systems. +And I started to lose some of the joy that I had around coding. And I started to worry about am I losing the interest, the spark that I have for this career? And while I'm very fortunate to enjoy my career, I have become accustomed to the fact that I really like what I do. And so when I felt that starting to fade, it was a concern for me. +But then I started picking up just some little fun things like one of them is Advent of Code which is created by Eric Wastl. And during the month of December, a new programming challenge is released each day, and there's a leaderboard and you can be as competitive as you like. You can use any programming language that you like because then you essentially solve the problems and then provide the answer. And then Advent of Code will let you know whether you have the correct or wrong answer for that exercise. +And that sparked some joy, and it reminded me, oh, I really do enjoy this. I like a lot about this. But I have been so heavily invested in triaging that I was missing some of the fun that comes from just building something. And so that is my number 5 is don't forget the fun. +CHRIS: I'm so glad you added that to the list because this podcast is depressingly serious at times. And I'm glad that we now have this on a list formally so that we can remember to not take things too seriously. But more seriously, [laughter] I do think that's a wonderful item. And we do have the possibility of really loving the work that we do. +I find this work to be very fun. And there are different versions of it. And there are different companies and ways that it can go. But for me, this is something that I love to do that I find so much fun in but can get mired down in the details. And so being intentional and saying, "This should be fun. If it's not, what's going on?" That's at least something to look at. And where can I find the fun? And how can I revisit that? So I really enjoy that that is the final item that you're capping your list off with, in fact. +So for me, the way that I've thought about this list as we've composed it over each of the years is what are the major themes? And for me, probably the biggest theme is that I have joined an early-stage startup, and I've joined on as CTO. So it's a very different role. It's a very different type of interaction. I'm not sure I've ever said the company's name before on this show because I'm a terrible salesman. The company is Sagewell Financial. And so we are trying to do something very ambitious. +And the role that I'm in is a very interesting one. It's composed of pieces that have always been part of my work. There have been bits of mentoring, and hiring, and architecting, but then also doing the individual contributor work and all of those different pieces, and those will all be present but to varying degrees. +And the amount of ownership I have over the thing is very different than the long history of consulting that I've done. And so I'm really excited to lean into that and to explore that and to find out what it feels like to code less because I think that's just kind of a given. It's already started to happen even this early on in the project, and I know it's probably only going to continue, which is an interesting one relative to your "Remember the fun." I find coding very fun. So that'll be an interesting one to see how it plays out. +But I also find all of the other aspects of managing and guiding the technical portion of an organization really interesting. So I'm super excited to continue pushing on that, to go on that adventure. But yeah, it's very different. Or it's every single dial on all of those different measures is just turned up to 11 now is what it is. And I'm like, okay, cool, strap in. Let's go for a ride. This will be fun. +STEPH: I really enjoyed those discussions about how your role has shifted and the different responsibilities that you're taking on as I have often felt that tension between managing and then coding. And I enjoy both, but then making time for both, and then which ones do you grow in? Because I'm still always growing and striving to be a better manager and a team lead. But then I also want to continue to grow and be a better individual contributor. And focusing in those two areas or trying to grow in both directions is hard. +So then I often have to pick one to focus on. Maybe it's for a day, maybe it's for a week, maybe it's for a month. And I'm like, hey, for a month, I want to grow in this particular manager skill. But then that way, I feel like I have this more achievable goal. So all that is to say I really like your number 5. And I'm really looking forward to more conversations about how it's going and all the different things that you learned from being a CTO. +CHRIS: Well, I think on that wonderful note, we should probably wrap up this episode and wrap up this wonderful year of The Bike Shed. As always, Steph, it's been such a pleasure getting to chat with you on these weekly tech talk and nonsense adventures that we go on. +STEPH: Likewise. This has been so much fun. And when I mentioned earlier about having sparks of joy, Bike Shed is always one of those. I love these conversations that we have. It's been a wonderful year. +CHRIS: Cool. Well, I will see you in 2022. +STEPH: On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph and Chris recap their favorite things of 2019 and 2020 and share their 2021 list. Happy Holidays, y'all!

+ +

Steph:

+ +
    +
  • Feature flags and calm deploys
    • +
  • Creating observable systems
    • +
  • Debugging
    • +
  • Working in seasons
    • +
  • Don't forget the fun
    • +
+ +
+

“The longer I’m in the software game, the more I want things to be calm” - Steph

+
+ +

Chris:

+ +
    +
  • Pushing logic back to the server
    • +
  • Svelte
    • +
  • Remote work (but maybe hybrid!)
    • +
  • Vim
    • +
  • Joining a startup as CTO
    • +
+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Listen to episodes from 2020 and 2019 👇

+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Are we taking off the next few weeks?

+ +

CHRIS: According to Steph's schedule I think we are.

+ +

STEPH: You know, that's Steph and her schedules.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: Well, this will be our last episode for 2021. So that's new collectively in all of our worlds, I think, which is exciting. We'll be taking off the next few weeks for the holidays. But as has become tradition, I think it is time for you and I to review some top 10 lists from last year or two top 5 lists, and then maybe you share some new favorite things. How does that sound?

+ +

STEPH: Yeah, I'm excited. I love that we take this time to reflect about what we enjoyed about the past year and share our top things. It's like Oprah's list. You know Oprah has her list of favorite things, and we have our list of favorite things.

+ +

CHRIS: It is almost exactly like Oprah.

+ +

STEPH: It feels a bit blasphemous to compare our list to Oprah's list but here we are. [laughs]

+ +

CHRIS: I tried to give the hyperbolic sarcasm there to be like, and let us be respectful of...but yes.

+ +

STEPH: Good. You got it. [laughs] So to prep for sharing our new list of favorite things, do you want to start by going through the list of favorite things from last year?

+ +

CHRIS: Sure. And just as a reminder, if anyone does want to listen to the episode and hear a bit more detail about our thinking on these, we covered this in Episode 274. But for me, the 5 items that I covered last year were Tailwind CSS. So the utility-first CSS framework which I continue to love and use on every project that I possibly can.

+ +

Remote work, that was a relatively new and novel thing for me at that point. Similarly, I have continued on with that and if anything, leaned into it all the more.

+ +

Next up is Svelte. Svelte is a JavaScript framework that I have grown to love even more over the past year. Spoiler alert, that may show up later in the episode.

+ +

Next up, we had Postgres, PostgreSQL, the database engine that is wonderful, and I had spent a lot of time with last year. Frankly, I haven't spent as much time with it this year but it’s still something that's near and dear to my heart.

+ +

And the last was Inertia.js, a framework that although it's got js in the name, it's both server-side and client-side and binds it together and gives a wonderful experience. I believe I've talked enough about that throughout the rest of this year that perhaps you've heard me mention it in a previous episode, listener.

+ +

But yeah, that was my top 5 for 2020. What about you, Steph?

+ +

STEPH: All right, so the things that I had from last year are one-on-ones. I don't remember exactly what I said about them, but I am still a fan. I still very much enjoy them. I learned a ton from them either participating or leading them.

+ +

Rails, also still a fan. Async communication, yes, love it. It really helps more people be involved in the conversation when it's async communication. feature flags, also still a fan. And Elixir and Phoenix is on the list also, still a fan although frankly, haven't done as much with it.

+ +

CHRIS: So, Steph, I have a question for you. Actually in preparing for this episode, I re-listened to Episode 274, which had our top 10 list for 2020. And then I also listened to 273, which was the previous episode which had our retrospective on the list from 2019. So at this point, I've now reviewed all of these lists, which is now 10 items, and 10 items for each of us.

+ +

And what was interesting to me, at least from my side, and especially as I was preparing for this year, is stuff's mostly stayed the same. I kind of still like most of the items on the list. And certainly, nothing has changed in a deep way where I'm like, you know, I used to really like this, but I don't like it at all anymore. So I'm wondering, is that the same for you? Is there anything that you've changed your mind on amongst this set of items?

+ +

STEPH: Looking at the list, I still really like everything on the list. So there's nothing that I've changed my mind about significantly. I'm realizing as we're creating this list each year, it's likely a list that I'm going to continue to grow and add to instead of subtract from.

+ +

Most of the stuff, I guess because we have a full year by the time we get to this point, I feel pretty good that this is something that I like in the world versus something that may be more of a month to month experiment that then I'd change my mind on. So everything on the list still rings true for me. And I have some new stuff that I'm going to add to that list.

+ +

CHRIS: Ooh, new stuff, exciting. Yes, this is what we're here for. So, Steph, let's dive in. What do you got?

+ +

STEPH: So in preparation for this episode, I started thinking through all the different ideas that I wanted to add to my list and all the topics I'm excited about. And I started to wonder what are the things that we really said? What can data tell us about these episodes versus just trying to think through my feelings of the past 12 months? Because it's very easy that I forget things that were important to me at the moment. So I started wondering, what data could I collect from the different episodes?

+ +

And now that we have transcripts that started back in I think around May of this year, I built a small little Ruby program to perform a word frequency analysis and generate a very low version of a word cloud. But I wanted to find what are some of the top things that we said? And it came out rather poetic. And I tried to ignore some of the small words just prepositions, and a, and the, and things like that were that were less interesting.

+ +

So here I've got a couple of different lists, a couple of different facts that we can explore. So here are the top 10 words that we said. So there's code, great, write, feature, question, idea, interesting, love, no, and laughs.

+ +

CHRIS: Laughs is in parentheses or brackets to say this is where they're laughing?

+ +

STEPH: Exactly.

+ +

CHRIS: Wow. A, that feels true. B, that's just delightful. And I'm so glad that you did this. For anyone listening at home, this is a complete surprise to me too. So I'm really enjoying going on this ride. But yeah, that feels like a representative list.

+ +

STEPH: There's another poetic one because then I started looking at some of the episodes individually as I was building this out to handle all the episodes. This is over 28 episodes. And so I pulled a specific episode with Joël Quenneville where we talked a lot about debugging.

+ +

And so the top words from that episode are debugging, people, think, don't, love, time, bug. And it's fun no matter how you hear that or read that you get something new out of it each time. And now I'm really into this word frequency art or whatever it is that we're going to call it.

+ +

CHRIS: That's fantastic that I want a little bumper sticker of that amongst the bumper stickers that I've claimed I want from things we say on the show. I want that one with Joël's face on it right there. That seems like a perfect item.

+ +

STEPH: So I also tried to figure out how many times we said it depends. And that one got a little trickier, and I was also surprised. But according to the data, we've said it depends around 10 times. And I feel like that's low.

+ +

CHRIS: That feels very low, huh.

+ +

STEPH: It does. I agree. That one feels a bit low. And so those were the fun, more poetic like, what are the top things that we said? And then I started looking for more what are the technical things that we talked about, some of the different frameworks or languages? So I started looking specifically for those. So over these 28 episodes, we said Rails 200 times, which is a lot. [laughs]

+ +

CHRIS: Good job, Rails. Way to show up on the leaderboard.

+ +

STEPH: And then next in that list data, some form of test, tests, or testing. We said around 230 times database. Ruby's next on the list at 140, then Sidekiq, retro. Monitoring is a big one. JavaScript, agile, REST. React, React is at 52. I was intrigued that React was spoken as much because I know I haven't worked in React in a long time. So I'm going to give you credit for that one. Manager, Svelte, Svelte, and Inertia are both around 45, 40 times that they were spoken. Python, Postgres, Rust, Elixir, Elm, Vim, and tmux.

+ +

CHRIS: Wow. I like that list.

+ +

STEPH: One other fun data point is that we said the word hard 20 times more than the word easy.

+ +

CHRIS: That feels fitting.

+ +

STEPH: It does, right?

+ +

CHRIS: I love this work, but it's not easy.

+ +

STEPH: Yeah, I appreciated that. I was like, that's true.

+ +

CHRIS: [chuckles]

+ +

STEPH: So that was some fun with words and frequency analysis, and it was neat. So I'm excited to do this for more episodes and to do it per episode because it highlights some interesting themes for the episode.

+ +

So pulling just from the data, then I'd say the top things from my list are Rails, data, testing, Ruby, Sidekiq, and retro. Those are the top things. But I'm still going to be creative with it and add to the list the things that I want to include on there.

+ +

So the first one this one is a bit of a repeat, so that's why I'm going to bring it upfront. But it's feature flags and calm deploys. That is something I am still a big fan of that I really appreciate. It can lead to some slightly increased tedious workflows depending on how diligent you are in feature flagging your work and keeping new work behind that gate so then you can turn it on when you want to. Also, the data supports it. We said flag like 67 times over 28 episodes. And I'm betting that was coupled with feature flags. So I feel pretty good about that one.

+ +

CHRIS: I think half of them were probably flag football is my guess if I remember what we talked about.

+ +

STEPH: We do play a lot of flag football, uh-huh.

+ +

CHRIS: It's interesting that you're leading with that. So one of the other items that I pulled out as I was reviewing the previous episodes was a quote that you made that resonated deeply with me in that moment and all the more so now. And everything I think about software probably falls a little bit under this bucket, which is...this is the quote from you, "The longer I'm in the software game, the more I want things to be calm."

+ +

And I think my response in the moment, which is why this was primed in my head, was I want a bumper sticker of that. I want it on a t-shirt or get a tattoo of it. [laughs] And I stand by those words because that's a beautiful sentiment and definitely, for me, speaks to a lot of the work that I want to do and how I think about what I put importance on.

+ +

STEPH: Thanks. Yeah, I find it makes a really big difference in terms of the quality of the work and then also, the happiness of the team. How about you, what's first on your list?

+ +

CHRIS: First on my list this year is going to be...it's a little bit of an abstract concept. So we'll see how well I can define it in a small amount of time. But the phrase in my mind is pushing logic back to the server. Over the past many years, let's call it like a decade or so, I've seen this gradual shift where more and more logic is being implemented client-side. And client-side can mean a bunch of things. It can mean a JavaScript client that gets downloaded and then runs. It has lots of smarts in it and knows about all the business logic but also iOS apps, Android apps, et cetera.

+ +

And every context that I've worked on that I felt the pain of now we've got our business logic distributed across all these different systems. I've seen some really interesting approaches to try and bundle up the logic and use it in a shared library. Perhaps in JavaScript, I've even seen some other approaches where this is a bundled C++ library that we somehow embed in every context that we want to run. And that's where the business logic is. But fundamentally, I felt a ton of pain from that.

+ +

And I've always had this idea in the back of my head that wherever possible, I like to pull logic back to the server because the server is this safe space with all the knowledge that I want in the world. And I can have secret environment variables, and I can add the database. And I can combine different sets of data very easily. And I can have the logic implemented in a single place. And that's wonderful.

+ +

And more and more, I've started to pursue this. Some of my work with GraphQL was an attempt to get this because a REST API is just like, here's a bunch of data. Combine it how you will. Have fun, front end. Whereas the GraphQL API starts to be more about the relationships between the data and the connections. And you can ask more interesting questions of a GraphQL API in my mind and ideally then push some of that logic back to the server because the GraphQL API encodes it in relationships and whatnot.

+ +

But probably the thing that has helped me the most on this is Inertia.js which was on my list last year. It remains something that, if anything, I tripled down on my enjoyment of Inertia.js. But it allows me to continue building my logic such that it's on the server-side.

+ +

And I don't need to implement a client that knows hey when a user adds an item to their cart, I also need to update that little icon in the top-right corner. I don't even need to think about that because Inertia uses the traditional request-response lifecycle, but then handles it in a smart, forward-thinking possibly animated way. And I'm just very happy with that and all of the explorations that I've had around pushing logic back to the server.

+ +

And actually, as I explore this even a little bit more, at my company, we're now starting to explore building native mobile apps. And we're trying to figure out what that means for us as I try and cling desperately to this idea of pushing logic back to the server. So that'll be a topic that I would love to chat with you more about in future episodes. But I think I found a way to, as I said, cling to this idea of pushing logic back to the server. So yeah, that is item number 1 for me.

+ +

STEPH: I'm very excited for those future conversations. You reminded me of something that I've heard from someone else at thoughtbot. I believe it's Stephen Lindbergh that said this. He was giving a presentation talking about forms. And one of the things he said was, "Stop using client-side form validations." And that's a bit of a blanket statement. And there are always some caveats with those statements. But when he said that, I thought, yeah, that sounds great because you have to validate it on the back end anyways. Let me rephrase that, you should validate it on the back end. A lot of applications don't.

+ +

CHRIS: I would go with have to just some opt to not despite the fact that they definitely have to.

+ +

STEPH: That's true. I just wanted to fuss at the people who aren't doing it. [laughs]

+ +

CHRIS: Steph's getting to fussing.

+ +

STEPH: And I just really liked what he said because I understand why people started adding more client-side validations because then they think well, this creates a better experience for the user. We can give them faster feedback.

+ +

But if you get to the point that you're actually hindering their experience...like if you've been filling out a form and it's telling you that you're incorrect, and it's because you haven't met the specific regex they're looking for, that annoying behavior that you see on forms that's often a result that I see from client-side form validations.

+ +

Also, if you're at the point that you're using form validations to drive the user to do the next thing, there's a good chance that form is too big. And there's an opportunity to break that up into a smaller workflow. So that way, you're not using validations to essentially coerce or force a user into a particular path and use more helpful ways to help guide them through that process.

+ +

So I'm very excited for our future conversations about pushing more things to the server. And side note, stop using client-side form validations or just reduce it. Dial it down. Don't dial it up, dial it down.

+ +

CHRIS: Oh yeah. That is such a great example of this theme. And again, hopefully, we'll chat more about this in future episodes. But yeah, so that's item number 1 for me. What is item number 2 on your list?

+ +

STEPH: So this one I really want to say thanks to you because I feel like you've brought a lot of topics and conversation about this particular idea to the show. And that has really resonated with me and influenced me as I've joined different projects that either have observable systems. And then that has been really helpful as then we are jumping into the project and debugging and then contributing to that system or where they're lacking that observability. And that just makes work and life so much harder.

+ +

So thank you to you and everyone else that has contributed in having conversations about observable systems on the show. Specifically, I'm thinking of the episode with Charity Majors where she talks about observable systems. And so that is number 2 on my list.

+ +

CHRIS: Oh yeah. I do love some observability. It's one of those ideas that once you get it in your head, you can't shake it. You can't unsee that you can't see what's going on in your runtime system.

+ +

I will say the app that we're building, the core Rails application, we've instrumented it heavily because we're trying to get in early on the observability game. But now we can see everything. And we've yet to really get to that deep understanding of like, that's just noise. We don't need to care about it. So let's silence those. Let's dial these up. These should go piped into Slack and how to sort of triage that.

+ +

So right now, it is a bit noisy in our world. I'd rather that than the silence, than the crickets of I don't know, something happened. There is a form validation, but it seems fine. It's happened a lot since the last deploy, but that seems fine. I'm trying to avoid that kind of stuff. But as a result, sort of the rough edges of the early times in observability, but yeah, huge fan of that. Glad that that made it onto your list.

+ +

For number 2 for me, this is a recurring theme from last year, but I've doubled if not tripled down on it. So this will be Svelte, Svelte the JavaScript framework that is just so fantastic. The more time I spend with it, the happier I am that I've leaned into it. I took I would say a tiny bit of a gamble in choosing it for the view layer for the application that we're building. It's not as popular. It doesn't have nearly as much community, mindshare, shared libraries, et cetera, et cetera.

+ +

But A, because we're working with Inertia, Svelte occupies a smaller portion of our application architecture. So that made me feel more comfortable with that decision. And I liked a lot of the fundamentals that I saw on the Svelte community. And over the past year, I've just seen each of those get reinforced. Svelte wonderfully leads with accessibility as a primary concern.

+ +

And one of the things that I see is although there are fewer packages out there in the Svelte ecosystem, the ones that there are very often like, and of course, we thought about accessibility, and screen readers, and keyboard navigation, and all of that. And so you don't even need to worry about that. It's like, thank you. That is wonderful.

+ +

Likewise, SvelteKit is a project that came out. I believe it was released, and I think it's 1.0 now or at least it's on its way to 1.0 now. And it's starting to get real usage. And that's a Next.js-like framework that takes your Svelte application and allows you to build it, run it, compile it. You can use it for packages. You can use it for apps. Wonderful stuff in there. And it's a great answer to how do I actually build a Svelte app or a Svelte package?

+ +

Likewise, Rich Harris recently moved to Vercel. Vercel is one of the big names in this world of we're building fancy applications on the internet. And so that's a huge vote of confidence for the framework. And now Rich Harris the creator of Svelte will be working on it full time. So it's just a bunch of signals that are pointing at although it's still definitely not nearly as popular as even Vue or certainly not React, Svelte is a wonderful choice. And I have enjoyed every minute that I've worked with it.

+ +

STEPH: I like how you're doubling or tripling down on Svelte. I've heard so many wonderful things about it. I feel like I should be a pro at Svelte at this point from everything that you have shared and brought to the show. But I'm still looking for that opportunity to get to test it out. So I'm excited to hear more about it next year.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days, no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

So third on my list, this one is more...it's something that I'm toying around with. I don't really have any concrete answers around how it's going to look but something that I'm interested in exploring further. Based on earlier this year, I took a month's sabbatical and that was phenomenal. I felt like this incredible reset, and then I came back more energized and interested in my work. And also, I got to explore other facets of life that I just normally didn't have time for.

+ +

So number 3 on my list is the idea of working in seasons where you are focused and work really hard on a project. And then let's say you take a couple of weeks off in between, and then you go on to your next thing. But I like this idea of chunking my work time because I found I'm very much a person that I'm on or I'm off. And it's very hard to create that balance between those two parts of myself.

+ +

And this may be a nice way to do it to say, I'm committed. I'm doing this for six months. But then I know I'm going to book a vacation, and I'm going to take a solid two weeks off or maybe even a solid three if that's something that my work and time allows. But I'm very interested in that idea.

+ +

I think it came from a conversation with someone else about academia life and how that is an approach they take where they work in those seasons where they work for the academic year, but then they take a summer off, and then they go back to work. And I very much like that idea and that approach to work.

+ +

CHRIS: This is such an interesting topic in my mind. I grew up both of my parents were teachers. So for the entirety of my life, I got summer vacation and my friends got summer vacation, and my parents got summer vacation. So clearly, everyone in the world got summer vacation. This is just a true thing about the universe.

+ +

And then spoiler alert, I learned the truth; it is different out there. So that took some getting used to. And then I have done an absolutely terrible job of this. This is an idea of like, I believe in this idea, the phrase that you used of living in seasons. It makes so much sense to me and seems like such a useful way to be. But I have at most taken two weeks off at any given point in my working career since I graduated college, and that was for my wedding. And that was it.

+ +

And between jobs, one time I left work like 15 minutes early on Friday, and then I started the next job on Monday. That was one of them. And then I did take a week off between my most recent job switch, just a whole week. Well, actually, that's not true because we recorded The Bike Shed in the middle of it, and I took a bunch of meetings to be ready to start. I'm terrible at this. Even though it's an idea that I believe in, that I want, I have never pursued this in a deep way. And it's something that I would really love to do. But yeah, I've not really done it.

+ +

So you mentioned academia and so there's the natural cadence to a year. But there are also sabbaticals. That's a thing that exists in the world. It's an idea that's already out there. Once every seven years, you get to take six months off just to go on an adventure. That sounds fantastic. I would like that, please. So I got to make that work in the world somehow, probably not for a couple of weeks, though, because I'm in an early-stage startup at this point. And so I probably got to hang out for a little while and get some stuff done.

+ +

STEPH: I like how you pointed out that sabbaticals exist; those are a thing. You also mentioned that a lot of times, maybe there's seven years or five years is what I've seen at companies before you get a month off. And while that is wonderful and much appreciated, I am interested in finding a way to include sabbaticals or at least those breaks more often in my life. Because I know I'm someone that I'm going to be focused on, and I'm going to work hard. And rather than just continue to do that and then one day burn myself out, find ways that I can have more of a structured this is when I'm on. This is what I do. It's what I'm interested in. I'm excited about this.

+ +

But now that I'm done with this after six months, let me go take a solid two, three weeks off to reset, recharge, find some other hobbies, and then come back to this. And I think that will make for a much longer and happier career. So I haven't worked out the details, but it is something that's on my mind. So that is why it is my number 3. What's your number 3?

+ +

CHRIS: My number 3 is perhaps in a similar space. And again, this is another one that was on my list last year, but I've leaned into it all the more, and that's remote, working remotely, working from home, et cetera. I have embraced it all the more this year.

+ +

The new company that I've joined we are a remote-first company. And so that is the mode that we're going to be working in. And that was something that I certainly pushed for because I feel like it is meaningful across the board. And if you're intentional about it from the beginning and think about things like async communication, and how do we handle this, that's all the more meaningful.

+ +

But also as vaccines and things like that have become available in the world, last year, remote was just the thing that we did. And this year, it was more of a choice and also was offset by the occasional in-person meeting. So the other folks that are in the company currently are co-located around Boston as well.

+ +

So we've had a number of days where we'll go downtown meet at a WeWork or some other shared co-working space. And we can have the occasional bit of in-person time. But we try and be very intentional with that. We try and make sure that when we're going to do that we have an agenda, even if that agenda is just connecting and socialization, which I think is deeply important. And that is incredibly hard to do just over Skype or Zoom or any of those tools.

+ +

But then the vast majority of the time I get to not have a commute. I get to work out more easily. I can cook dinner more easily. I can go for a longer walk with my dog. All of these things are just options now that are so, so meaningful and allow me to have a slightly calmer cadence to my life which is a thing that I want both in the work and in the life.

+ +

So I'm all for remote and perhaps tinged with a little bit of hybrid in person, kind of figure out how to get that right optimization. But yeah, big fan and will be continuing to do it with the caveat, and this is something we talked about the previous time we talked about it. This makes a lot of sense for a certain point in your career. I still wonder about how to make this work for folks that are newer to the industry. Junior developers joining a team being remote feels like it would be very complicated. So at a minimum, needing to be incredibly intentional around that. But also, is that even the right answer in that case? I don't know.

+ +

STEPH: I have feelings about that one. But I'm going to punt for now for another episode because I think that's a really great topic to dive into. And yeah, we should talk about that more.

+ +

CHRIS: I look forward to that conversation. But yeah, remote, that is my number 3. And with that, I will send it back to you for your number 4.

+ +

STEPH: I love that one. I'm a big fan of remote work. All right, for number 4 it's debugging. So I feel like we've had a number of conversations. Joël Quenneville has been on the show to talk about debugging and debugging not just for the art of it and the necessity of it but really building concrete skills around how to debug and then finding ways to share that information with others is really powerful.

+ +

And I feel like it's something that a lot of people just pick up on the job as you go, which is great. But it'd be great if we could create shortcuts for people. So then that way, they can have that information sooner rather than just waiting for a painful experience and then happen to pick up new tools for debugging. So debugging is a big one for me.

+ +

I also think that's representative of the type of projects that I've been on this year where a lot of them have been more triage-focused and how important debugging skills are in that moment, which I'm sure is also why observable systems is on the list. So for my number 4 is debugging. And we'll link to Joël's episode about debugging because it's delightful.

+ +

CHRIS: Debugging, one of the most pointed examples of alchemy in our work is the intersection of art and science and craft and all of that. And yes, debugging, what a fun topic.

+ +

But for my number 4, this is a return from two years ago, and this is Vim. I finally feel like Vim is starting to catch up, the promise of the language servers and VS Code, and the way that it works. I guess I've said this every year. I know. I'm aware.

+ +

STEPH: I'm laughing because I thought for a moment you're going to be like, I finally feel like it's working for me. [laughter]

+ +

CHRIS: I finally learned how to quit Vim. I've just had one instance of Vim open for the last 13 years because I didn't know how to quit it. But that has been fine. And then I finally learned how to quit it. No. Vim is finally catching up.

+ +

The Neovim just came out with a new version that's got tons of deep integrations VS Code-like features. Thanks to the wonderful work of the VS Code team and the respective language servers from all the different communities. The promise of the editor ecosystem rising tide lifts all ships is coming true, I think.

+ +

And even right now, I haven't even jumped to that new Neovim version. But the version of Vim that I'm working on with the current config is great. It works. It does the thing. And that's awesome. And it's only going to get better from here I think.

+ +

So 2022 is the year of Vim on the desktop. That is my strong bet. That's a joke about Linux in case anyone doesn't get it. It's not a good one. But it is a joke about Linux. So that's my number 4. Back to you, Steph, for your number 5.

+ +

STEPH: [laughs] And this is another count for our laughs in parens for next year's frequency count. Well, I guess it is still this year.

+ +

CHRIS: I absolutely love that that made it onto the list of top 10 things just [laughs] laughter off to the side.

+ +

STEPH: All right. So for my final, number 5 is don't forget the fun. And I say this because while work can be very interesting and fulfilling, I have found for myself this year that I also really needed some downtime to just play, to just experiment. And initially, sometimes I was worried where I felt like a lot of the work I was doing often wasn't building, but it was more correcting or fixing systems.

+ +

And I started to lose some of the joy that I had around coding. And I started to worry about am I losing the interest, the spark that I have for this career? And while I'm very fortunate to enjoy my career, I have become accustomed to the fact that I really like what I do. And so when I felt that starting to fade, it was a concern for me.

+ +

But then I started picking up just some little fun things like one of them is Advent of Code which is created by Eric Wastl. And during the month of December, a new programming challenge is released each day, and there's a leaderboard and you can be as competitive as you like. You can use any programming language that you like because then you essentially solve the problems and then provide the answer. And then Advent of Code will let you know whether you have the correct or wrong answer for that exercise.

+ +

And that sparked some joy, and it reminded me, oh, I really do enjoy this. I like a lot about this. But I have been so heavily invested in triaging that I was missing some of the fun that comes from just building something. And so that is my number 5 is don't forget the fun.

+ +

CHRIS: I'm so glad you added that to the list because this podcast is depressingly serious at times. And I'm glad that we now have this on a list formally so that we can remember to not take things too seriously. But more seriously, [laughter] I do think that's a wonderful item. And we do have the possibility of really loving the work that we do.

+ +

I find this work to be very fun. And there are different versions of it. And there are different companies and ways that it can go. But for me, this is something that I love to do that I find so much fun in but can get mired down in the details. And so being intentional and saying, "This should be fun. If it's not, what's going on?" That's at least something to look at. And where can I find the fun? And how can I revisit that? So I really enjoy that that is the final item that you're capping your list off with, in fact.

+ +

So for me, the way that I've thought about this list as we've composed it over each of the years is what are the major themes? And for me, probably the biggest theme is that I have joined an early-stage startup, and I've joined on as CTO. So it's a very different role. It's a very different type of interaction. I'm not sure I've ever said the company's name before on this show because I'm a terrible salesman. The company is Sagewell Financial. And so we are trying to do something very ambitious.

+ +

And the role that I'm in is a very interesting one. It's composed of pieces that have always been part of my work. There have been bits of mentoring, and hiring, and architecting, but then also doing the individual contributor work and all of those different pieces, and those will all be present but to varying degrees.

+ +

And the amount of ownership I have over the thing is very different than the long history of consulting that I've done. And so I'm really excited to lean into that and to explore that and to find out what it feels like to code less because I think that's just kind of a given. It's already started to happen even this early on in the project, and I know it's probably only going to continue, which is an interesting one relative to your "Remember the fun." I find coding very fun. So that'll be an interesting one to see how it plays out.

+ +

But I also find all of the other aspects of managing and guiding the technical portion of an organization really interesting. So I'm super excited to continue pushing on that, to go on that adventure. But yeah, it's very different. Or it's every single dial on all of those different measures is just turned up to 11 now is what it is. And I'm like, okay, cool, strap in. Let's go for a ride. This will be fun.

+ +

STEPH: I really enjoyed those discussions about how your role has shifted and the different responsibilities that you're taking on as I have often felt that tension between managing and then coding. And I enjoy both, but then making time for both, and then which ones do you grow in? Because I'm still always growing and striving to be a better manager and a team lead. But then I also want to continue to grow and be a better individual contributor. And focusing in those two areas or trying to grow in both directions is hard.

+ +

So then I often have to pick one to focus on. Maybe it's for a day, maybe it's for a week, maybe it's for a month. And I'm like, hey, for a month, I want to grow in this particular manager skill. But then that way, I feel like I have this more achievable goal. So all that is to say I really like your number 5. And I'm really looking forward to more conversations about how it's going and all the different things that you learned from being a CTO.

+ +

CHRIS: Well, I think on that wonderful note, we should probably wrap up this episode and wrap up this wonderful year of The Bike Shed. As always, Steph, it's been such a pleasure getting to chat with you on these weekly tech talk and nonsense adventures that we go on.

+ +

STEPH: Likewise. This has been so much fun. And when I mentioned earlier about having sparks of joy, Bike Shed is always one of those. I love these conversations that we have. It's been a wonderful year.

+ +

CHRIS: Cool. Well, I will see you in 2022.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph and Chris recap their favorite things of 2019 and 2020 and share their 2021 list. Happy Holidays, y'all!

+ +

Steph:

+ +
    +
  • Feature flags and calm deploys
    • +
  • Creating observable systems
    • +
  • Debugging
    • +
  • Working in seasons
    • +
  • Don't forget the fun
    • +
+ +
+

“The longer I’m in the software game, the more I want things to be calm” - Steph

+
+ +

Chris:

+ +
    +
  • Pushing logic back to the server
    • +
  • Svelte
    • +
  • Remote work (but maybe hybrid!)
    • +
  • Vim
    • +
  • Joining a startup as CTO
    • +
+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ +

Listen to episodes from 2020 and 2019 👇

+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Are we taking off the next few weeks?

+ +

CHRIS: According to Steph's schedule I think we are.

+ +

STEPH: You know, that's Steph and her schedules.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: Well, this will be our last episode for 2021. So that's new collectively in all of our worlds, I think, which is exciting. We'll be taking off the next few weeks for the holidays. But as has become tradition, I think it is time for you and I to review some top 10 lists from last year or two top 5 lists, and then maybe you share some new favorite things. How does that sound?

+ +

STEPH: Yeah, I'm excited. I love that we take this time to reflect about what we enjoyed about the past year and share our top things. It's like Oprah's list. You know Oprah has her list of favorite things, and we have our list of favorite things.

+ +

CHRIS: It is almost exactly like Oprah.

+ +

STEPH: It feels a bit blasphemous to compare our list to Oprah's list but here we are. [laughs]

+ +

CHRIS: I tried to give the hyperbolic sarcasm there to be like, and let us be respectful of...but yes.

+ +

STEPH: Good. You got it. [laughs] So to prep for sharing our new list of favorite things, do you want to start by going through the list of favorite things from last year?

+ +

CHRIS: Sure. And just as a reminder, if anyone does want to listen to the episode and hear a bit more detail about our thinking on these, we covered this in Episode 274. But for me, the 5 items that I covered last year were Tailwind CSS. So the utility-first CSS framework which I continue to love and use on every project that I possibly can.

+ +

Remote work, that was a relatively new and novel thing for me at that point. Similarly, I have continued on with that and if anything, leaned into it all the more.

+ +

Next up is Svelte. Svelte is a JavaScript framework that I have grown to love even more over the past year. Spoiler alert, that may show up later in the episode.

+ +

Next up, we had Postgres, PostgreSQL, the database engine that is wonderful, and I had spent a lot of time with last year. Frankly, I haven't spent as much time with it this year but it’s still something that's near and dear to my heart.

+ +

And the last was Inertia.js, a framework that although it's got js in the name, it's both server-side and client-side and binds it together and gives a wonderful experience. I believe I've talked enough about that throughout the rest of this year that perhaps you've heard me mention it in a previous episode, listener.

+ +

But yeah, that was my top 5 for 2020. What about you, Steph?

+ +

STEPH: All right, so the things that I had from last year are one-on-ones. I don't remember exactly what I said about them, but I am still a fan. I still very much enjoy them. I learned a ton from them either participating or leading them.

+ +

Rails, also still a fan. Async communication, yes, love it. It really helps more people be involved in the conversation when it's async communication. feature flags, also still a fan. And Elixir and Phoenix is on the list also, still a fan although frankly, haven't done as much with it.

+ +

CHRIS: So, Steph, I have a question for you. Actually in preparing for this episode, I re-listened to Episode 274, which had our top 10 list for 2020. And then I also listened to 273, which was the previous episode which had our retrospective on the list from 2019. So at this point, I've now reviewed all of these lists, which is now 10 items, and 10 items for each of us.

+ +

And what was interesting to me, at least from my side, and especially as I was preparing for this year, is stuff's mostly stayed the same. I kind of still like most of the items on the list. And certainly, nothing has changed in a deep way where I'm like, you know, I used to really like this, but I don't like it at all anymore. So I'm wondering, is that the same for you? Is there anything that you've changed your mind on amongst this set of items?

+ +

STEPH: Looking at the list, I still really like everything on the list. So there's nothing that I've changed my mind about significantly. I'm realizing as we're creating this list each year, it's likely a list that I'm going to continue to grow and add to instead of subtract from.

+ +

Most of the stuff, I guess because we have a full year by the time we get to this point, I feel pretty good that this is something that I like in the world versus something that may be more of a month to month experiment that then I'd change my mind on. So everything on the list still rings true for me. And I have some new stuff that I'm going to add to that list.

+ +

CHRIS: Ooh, new stuff, exciting. Yes, this is what we're here for. So, Steph, let's dive in. What do you got?

+ +

STEPH: So in preparation for this episode, I started thinking through all the different ideas that I wanted to add to my list and all the topics I'm excited about. And I started to wonder what are the things that we really said? What can data tell us about these episodes versus just trying to think through my feelings of the past 12 months? Because it's very easy that I forget things that were important to me at the moment. So I started wondering, what data could I collect from the different episodes?

+ +

And now that we have transcripts that started back in I think around May of this year, I built a small little Ruby program to perform a word frequency analysis and generate a very low version of a word cloud. But I wanted to find what are some of the top things that we said? And it came out rather poetic. And I tried to ignore some of the small words just prepositions, and a, and the, and things like that were that were less interesting.

+ +

So here I've got a couple of different lists, a couple of different facts that we can explore. So here are the top 10 words that we said. So there's code, great, write, feature, question, idea, interesting, love, no, and laughs.

+ +

CHRIS: Laughs is in parentheses or brackets to say this is where they're laughing?

+ +

STEPH: Exactly.

+ +

CHRIS: Wow. A, that feels true. B, that's just delightful. And I'm so glad that you did this. For anyone listening at home, this is a complete surprise to me too. So I'm really enjoying going on this ride. But yeah, that feels like a representative list.

+ +

STEPH: There's another poetic one because then I started looking at some of the episodes individually as I was building this out to handle all the episodes. This is over 28 episodes. And so I pulled a specific episode with Joël Quenneville where we talked a lot about debugging.

+ +

And so the top words from that episode are debugging, people, think, don't, love, time, bug. And it's fun no matter how you hear that or read that you get something new out of it each time. And now I'm really into this word frequency art or whatever it is that we're going to call it.

+ +

CHRIS: That's fantastic that I want a little bumper sticker of that amongst the bumper stickers that I've claimed I want from things we say on the show. I want that one with Joël's face on it right there. That seems like a perfect item.

+ +

STEPH: So I also tried to figure out how many times we said it depends. And that one got a little trickier, and I was also surprised. But according to the data, we've said it depends around 10 times. And I feel like that's low.

+ +

CHRIS: That feels very low, huh.

+ +

STEPH: It does. I agree. That one feels a bit low. And so those were the fun, more poetic like, what are the top things that we said? And then I started looking for more what are the technical things that we talked about, some of the different frameworks or languages? So I started looking specifically for those. So over these 28 episodes, we said Rails 200 times, which is a lot. [laughs]

+ +

CHRIS: Good job, Rails. Way to show up on the leaderboard.

+ +

STEPH: And then next in that list data, some form of test, tests, or testing. We said around 230 times database. Ruby's next on the list at 140, then Sidekiq, retro. Monitoring is a big one. JavaScript, agile, REST. React, React is at 52. I was intrigued that React was spoken as much because I know I haven't worked in React in a long time. So I'm going to give you credit for that one. Manager, Svelte, Svelte, and Inertia are both around 45, 40 times that they were spoken. Python, Postgres, Rust, Elixir, Elm, Vim, and tmux.

+ +

CHRIS: Wow. I like that list.

+ +

STEPH: One other fun data point is that we said the word hard 20 times more than the word easy.

+ +

CHRIS: That feels fitting.

+ +

STEPH: It does, right?

+ +

CHRIS: I love this work, but it's not easy.

+ +

STEPH: Yeah, I appreciated that. I was like, that's true.

+ +

CHRIS: [chuckles]

+ +

STEPH: So that was some fun with words and frequency analysis, and it was neat. So I'm excited to do this for more episodes and to do it per episode because it highlights some interesting themes for the episode.

+ +

So pulling just from the data, then I'd say the top things from my list are Rails, data, testing, Ruby, Sidekiq, and retro. Those are the top things. But I'm still going to be creative with it and add to the list the things that I want to include on there.

+ +

So the first one this one is a bit of a repeat, so that's why I'm going to bring it upfront. But it's feature flags and calm deploys. That is something I am still a big fan of that I really appreciate. It can lead to some slightly increased tedious workflows depending on how diligent you are in feature flagging your work and keeping new work behind that gate so then you can turn it on when you want to. Also, the data supports it. We said flag like 67 times over 28 episodes. And I'm betting that was coupled with feature flags. So I feel pretty good about that one.

+ +

CHRIS: I think half of them were probably flag football is my guess if I remember what we talked about.

+ +

STEPH: We do play a lot of flag football, uh-huh.

+ +

CHRIS: It's interesting that you're leading with that. So one of the other items that I pulled out as I was reviewing the previous episodes was a quote that you made that resonated deeply with me in that moment and all the more so now. And everything I think about software probably falls a little bit under this bucket, which is...this is the quote from you, "The longer I'm in the software game, the more I want things to be calm."

+ +

And I think my response in the moment, which is why this was primed in my head, was I want a bumper sticker of that. I want it on a t-shirt or get a tattoo of it. [laughs] And I stand by those words because that's a beautiful sentiment and definitely, for me, speaks to a lot of the work that I want to do and how I think about what I put importance on.

+ +

STEPH: Thanks. Yeah, I find it makes a really big difference in terms of the quality of the work and then also, the happiness of the team. How about you, what's first on your list?

+ +

CHRIS: First on my list this year is going to be...it's a little bit of an abstract concept. So we'll see how well I can define it in a small amount of time. But the phrase in my mind is pushing logic back to the server. Over the past many years, let's call it like a decade or so, I've seen this gradual shift where more and more logic is being implemented client-side. And client-side can mean a bunch of things. It can mean a JavaScript client that gets downloaded and then runs. It has lots of smarts in it and knows about all the business logic but also iOS apps, Android apps, et cetera.

+ +

And every context that I've worked on that I felt the pain of now we've got our business logic distributed across all these different systems. I've seen some really interesting approaches to try and bundle up the logic and use it in a shared library. Perhaps in JavaScript, I've even seen some other approaches where this is a bundled C++ library that we somehow embed in every context that we want to run. And that's where the business logic is. But fundamentally, I felt a ton of pain from that.

+ +

And I've always had this idea in the back of my head that wherever possible, I like to pull logic back to the server because the server is this safe space with all the knowledge that I want in the world. And I can have secret environment variables, and I can add the database. And I can combine different sets of data very easily. And I can have the logic implemented in a single place. And that's wonderful.

+ +

And more and more, I've started to pursue this. Some of my work with GraphQL was an attempt to get this because a REST API is just like, here's a bunch of data. Combine it how you will. Have fun, front end. Whereas the GraphQL API starts to be more about the relationships between the data and the connections. And you can ask more interesting questions of a GraphQL API in my mind and ideally then push some of that logic back to the server because the GraphQL API encodes it in relationships and whatnot.

+ +

But probably the thing that has helped me the most on this is Inertia.js which was on my list last year. It remains something that, if anything, I tripled down on my enjoyment of Inertia.js. But it allows me to continue building my logic such that it's on the server-side.

+ +

And I don't need to implement a client that knows hey when a user adds an item to their cart, I also need to update that little icon in the top-right corner. I don't even need to think about that because Inertia uses the traditional request-response lifecycle, but then handles it in a smart, forward-thinking possibly animated way. And I'm just very happy with that and all of the explorations that I've had around pushing logic back to the server.

+ +

And actually, as I explore this even a little bit more, at my company, we're now starting to explore building native mobile apps. And we're trying to figure out what that means for us as I try and cling desperately to this idea of pushing logic back to the server. So that'll be a topic that I would love to chat with you more about in future episodes. But I think I found a way to, as I said, cling to this idea of pushing logic back to the server. So yeah, that is item number 1 for me.

+ +

STEPH: I'm very excited for those future conversations. You reminded me of something that I've heard from someone else at thoughtbot. I believe it's Stephen Lindbergh that said this. He was giving a presentation talking about forms. And one of the things he said was, "Stop using client-side form validations." And that's a bit of a blanket statement. And there are always some caveats with those statements. But when he said that, I thought, yeah, that sounds great because you have to validate it on the back end anyways. Let me rephrase that, you should validate it on the back end. A lot of applications don't.

+ +

CHRIS: I would go with have to just some opt to not despite the fact that they definitely have to.

+ +

STEPH: That's true. I just wanted to fuss at the people who aren't doing it. [laughs]

+ +

CHRIS: Steph's getting to fussing.

+ +

STEPH: And I just really liked what he said because I understand why people started adding more client-side validations because then they think well, this creates a better experience for the user. We can give them faster feedback.

+ +

But if you get to the point that you're actually hindering their experience...like if you've been filling out a form and it's telling you that you're incorrect, and it's because you haven't met the specific regex they're looking for, that annoying behavior that you see on forms that's often a result that I see from client-side form validations.

+ +

Also, if you're at the point that you're using form validations to drive the user to do the next thing, there's a good chance that form is too big. And there's an opportunity to break that up into a smaller workflow. So that way, you're not using validations to essentially coerce or force a user into a particular path and use more helpful ways to help guide them through that process.

+ +

So I'm very excited for our future conversations about pushing more things to the server. And side note, stop using client-side form validations or just reduce it. Dial it down. Don't dial it up, dial it down.

+ +

CHRIS: Oh yeah. That is such a great example of this theme. And again, hopefully, we'll chat more about this in future episodes. But yeah, so that's item number 1 for me. What is item number 2 on your list?

+ +

STEPH: So this one I really want to say thanks to you because I feel like you've brought a lot of topics and conversation about this particular idea to the show. And that has really resonated with me and influenced me as I've joined different projects that either have observable systems. And then that has been really helpful as then we are jumping into the project and debugging and then contributing to that system or where they're lacking that observability. And that just makes work and life so much harder.

+ +

So thank you to you and everyone else that has contributed in having conversations about observable systems on the show. Specifically, I'm thinking of the episode with Charity Majors where she talks about observable systems. And so that is number 2 on my list.

+ +

CHRIS: Oh yeah. I do love some observability. It's one of those ideas that once you get it in your head, you can't shake it. You can't unsee that you can't see what's going on in your runtime system.

+ +

I will say the app that we're building, the core Rails application, we've instrumented it heavily because we're trying to get in early on the observability game. But now we can see everything. And we've yet to really get to that deep understanding of like, that's just noise. We don't need to care about it. So let's silence those. Let's dial these up. These should go piped into Slack and how to sort of triage that.

+ +

So right now, it is a bit noisy in our world. I'd rather that than the silence, than the crickets of I don't know, something happened. There is a form validation, but it seems fine. It's happened a lot since the last deploy, but that seems fine. I'm trying to avoid that kind of stuff. But as a result, sort of the rough edges of the early times in observability, but yeah, huge fan of that. Glad that that made it onto your list.

+ +

For number 2 for me, this is a recurring theme from last year, but I've doubled if not tripled down on it. So this will be Svelte, Svelte the JavaScript framework that is just so fantastic. The more time I spend with it, the happier I am that I've leaned into it. I took I would say a tiny bit of a gamble in choosing it for the view layer for the application that we're building. It's not as popular. It doesn't have nearly as much community, mindshare, shared libraries, et cetera, et cetera.

+ +

But A, because we're working with Inertia, Svelte occupies a smaller portion of our application architecture. So that made me feel more comfortable with that decision. And I liked a lot of the fundamentals that I saw on the Svelte community. And over the past year, I've just seen each of those get reinforced. Svelte wonderfully leads with accessibility as a primary concern.

+ +

And one of the things that I see is although there are fewer packages out there in the Svelte ecosystem, the ones that there are very often like, and of course, we thought about accessibility, and screen readers, and keyboard navigation, and all of that. And so you don't even need to worry about that. It's like, thank you. That is wonderful.

+ +

Likewise, SvelteKit is a project that came out. I believe it was released, and I think it's 1.0 now or at least it's on its way to 1.0 now. And it's starting to get real usage. And that's a Next.js-like framework that takes your Svelte application and allows you to build it, run it, compile it. You can use it for packages. You can use it for apps. Wonderful stuff in there. And it's a great answer to how do I actually build a Svelte app or a Svelte package?

+ +

Likewise, Rich Harris recently moved to Vercel. Vercel is one of the big names in this world of we're building fancy applications on the internet. And so that's a huge vote of confidence for the framework. And now Rich Harris the creator of Svelte will be working on it full time. So it's just a bunch of signals that are pointing at although it's still definitely not nearly as popular as even Vue or certainly not React, Svelte is a wonderful choice. And I have enjoyed every minute that I've worked with it.

+ +

STEPH: I like how you're doubling or tripling down on Svelte. I've heard so many wonderful things about it. I feel like I should be a pro at Svelte at this point from everything that you have shared and brought to the show. But I'm still looking for that opportunity to get to test it out. So I'm excited to hear more about it next year.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days, no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

So third on my list, this one is more...it's something that I'm toying around with. I don't really have any concrete answers around how it's going to look but something that I'm interested in exploring further. Based on earlier this year, I took a month's sabbatical and that was phenomenal. I felt like this incredible reset, and then I came back more energized and interested in my work. And also, I got to explore other facets of life that I just normally didn't have time for.

+ +

So number 3 on my list is the idea of working in seasons where you are focused and work really hard on a project. And then let's say you take a couple of weeks off in between, and then you go on to your next thing. But I like this idea of chunking my work time because I found I'm very much a person that I'm on or I'm off. And it's very hard to create that balance between those two parts of myself.

+ +

And this may be a nice way to do it to say, I'm committed. I'm doing this for six months. But then I know I'm going to book a vacation, and I'm going to take a solid two weeks off or maybe even a solid three if that's something that my work and time allows. But I'm very interested in that idea.

+ +

I think it came from a conversation with someone else about academia life and how that is an approach they take where they work in those seasons where they work for the academic year, but then they take a summer off, and then they go back to work. And I very much like that idea and that approach to work.

+ +

CHRIS: This is such an interesting topic in my mind. I grew up both of my parents were teachers. So for the entirety of my life, I got summer vacation and my friends got summer vacation, and my parents got summer vacation. So clearly, everyone in the world got summer vacation. This is just a true thing about the universe.

+ +

And then spoiler alert, I learned the truth; it is different out there. So that took some getting used to. And then I have done an absolutely terrible job of this. This is an idea of like, I believe in this idea, the phrase that you used of living in seasons. It makes so much sense to me and seems like such a useful way to be. But I have at most taken two weeks off at any given point in my working career since I graduated college, and that was for my wedding. And that was it.

+ +

And between jobs, one time I left work like 15 minutes early on Friday, and then I started the next job on Monday. That was one of them. And then I did take a week off between my most recent job switch, just a whole week. Well, actually, that's not true because we recorded The Bike Shed in the middle of it, and I took a bunch of meetings to be ready to start. I'm terrible at this. Even though it's an idea that I believe in, that I want, I have never pursued this in a deep way. And it's something that I would really love to do. But yeah, I've not really done it.

+ +

So you mentioned academia and so there's the natural cadence to a year. But there are also sabbaticals. That's a thing that exists in the world. It's an idea that's already out there. Once every seven years, you get to take six months off just to go on an adventure. That sounds fantastic. I would like that, please. So I got to make that work in the world somehow, probably not for a couple of weeks, though, because I'm in an early-stage startup at this point. And so I probably got to hang out for a little while and get some stuff done.

+ +

STEPH: I like how you pointed out that sabbaticals exist; those are a thing. You also mentioned that a lot of times, maybe there's seven years or five years is what I've seen at companies before you get a month off. And while that is wonderful and much appreciated, I am interested in finding a way to include sabbaticals or at least those breaks more often in my life. Because I know I'm someone that I'm going to be focused on, and I'm going to work hard. And rather than just continue to do that and then one day burn myself out, find ways that I can have more of a structured this is when I'm on. This is what I do. It's what I'm interested in. I'm excited about this.

+ +

But now that I'm done with this after six months, let me go take a solid two, three weeks off to reset, recharge, find some other hobbies, and then come back to this. And I think that will make for a much longer and happier career. So I haven't worked out the details, but it is something that's on my mind. So that is why it is my number 3. What's your number 3?

+ +

CHRIS: My number 3 is perhaps in a similar space. And again, this is another one that was on my list last year, but I've leaned into it all the more, and that's remote, working remotely, working from home, et cetera. I have embraced it all the more this year.

+ +

The new company that I've joined we are a remote-first company. And so that is the mode that we're going to be working in. And that was something that I certainly pushed for because I feel like it is meaningful across the board. And if you're intentional about it from the beginning and think about things like async communication, and how do we handle this, that's all the more meaningful.

+ +

But also as vaccines and things like that have become available in the world, last year, remote was just the thing that we did. And this year, it was more of a choice and also was offset by the occasional in-person meeting. So the other folks that are in the company currently are co-located around Boston as well.

+ +

So we've had a number of days where we'll go downtown meet at a WeWork or some other shared co-working space. And we can have the occasional bit of in-person time. But we try and be very intentional with that. We try and make sure that when we're going to do that we have an agenda, even if that agenda is just connecting and socialization, which I think is deeply important. And that is incredibly hard to do just over Skype or Zoom or any of those tools.

+ +

But then the vast majority of the time I get to not have a commute. I get to work out more easily. I can cook dinner more easily. I can go for a longer walk with my dog. All of these things are just options now that are so, so meaningful and allow me to have a slightly calmer cadence to my life which is a thing that I want both in the work and in the life.

+ +

So I'm all for remote and perhaps tinged with a little bit of hybrid in person, kind of figure out how to get that right optimization. But yeah, big fan and will be continuing to do it with the caveat, and this is something we talked about the previous time we talked about it. This makes a lot of sense for a certain point in your career. I still wonder about how to make this work for folks that are newer to the industry. Junior developers joining a team being remote feels like it would be very complicated. So at a minimum, needing to be incredibly intentional around that. But also, is that even the right answer in that case? I don't know.

+ +

STEPH: I have feelings about that one. But I'm going to punt for now for another episode because I think that's a really great topic to dive into. And yeah, we should talk about that more.

+ +

CHRIS: I look forward to that conversation. But yeah, remote, that is my number 3. And with that, I will send it back to you for your number 4.

+ +

STEPH: I love that one. I'm a big fan of remote work. All right, for number 4 it's debugging. So I feel like we've had a number of conversations. Joël Quenneville has been on the show to talk about debugging and debugging not just for the art of it and the necessity of it but really building concrete skills around how to debug and then finding ways to share that information with others is really powerful.

+ +

And I feel like it's something that a lot of people just pick up on the job as you go, which is great. But it'd be great if we could create shortcuts for people. So then that way, they can have that information sooner rather than just waiting for a painful experience and then happen to pick up new tools for debugging. So debugging is a big one for me.

+ +

I also think that's representative of the type of projects that I've been on this year where a lot of them have been more triage-focused and how important debugging skills are in that moment, which I'm sure is also why observable systems is on the list. So for my number 4 is debugging. And we'll link to Joël's episode about debugging because it's delightful.

+ +

CHRIS: Debugging, one of the most pointed examples of alchemy in our work is the intersection of art and science and craft and all of that. And yes, debugging, what a fun topic.

+ +

But for my number 4, this is a return from two years ago, and this is Vim. I finally feel like Vim is starting to catch up, the promise of the language servers and VS Code, and the way that it works. I guess I've said this every year. I know. I'm aware.

+ +

STEPH: I'm laughing because I thought for a moment you're going to be like, I finally feel like it's working for me. [laughter]

+ +

CHRIS: I finally learned how to quit Vim. I've just had one instance of Vim open for the last 13 years because I didn't know how to quit it. But that has been fine. And then I finally learned how to quit it. No. Vim is finally catching up.

+ +

The Neovim just came out with a new version that's got tons of deep integrations VS Code-like features. Thanks to the wonderful work of the VS Code team and the respective language servers from all the different communities. The promise of the editor ecosystem rising tide lifts all ships is coming true, I think.

+ +

And even right now, I haven't even jumped to that new Neovim version. But the version of Vim that I'm working on with the current config is great. It works. It does the thing. And that's awesome. And it's only going to get better from here I think.

+ +

So 2022 is the year of Vim on the desktop. That is my strong bet. That's a joke about Linux in case anyone doesn't get it. It's not a good one. But it is a joke about Linux. So that's my number 4. Back to you, Steph, for your number 5.

+ +

STEPH: [laughs] And this is another count for our laughs in parens for next year's frequency count. Well, I guess it is still this year.

+ +

CHRIS: I absolutely love that that made it onto the list of top 10 things just [laughs] laughter off to the side.

+ +

STEPH: All right. So for my final, number 5 is don't forget the fun. And I say this because while work can be very interesting and fulfilling, I have found for myself this year that I also really needed some downtime to just play, to just experiment. And initially, sometimes I was worried where I felt like a lot of the work I was doing often wasn't building, but it was more correcting or fixing systems.

+ +

And I started to lose some of the joy that I had around coding. And I started to worry about am I losing the interest, the spark that I have for this career? And while I'm very fortunate to enjoy my career, I have become accustomed to the fact that I really like what I do. And so when I felt that starting to fade, it was a concern for me.

+ +

But then I started picking up just some little fun things like one of them is Advent of Code which is created by Eric Wastl. And during the month of December, a new programming challenge is released each day, and there's a leaderboard and you can be as competitive as you like. You can use any programming language that you like because then you essentially solve the problems and then provide the answer. And then Advent of Code will let you know whether you have the correct or wrong answer for that exercise.

+ +

And that sparked some joy, and it reminded me, oh, I really do enjoy this. I like a lot about this. But I have been so heavily invested in triaging that I was missing some of the fun that comes from just building something. And so that is my number 5 is don't forget the fun.

+ +

CHRIS: I'm so glad you added that to the list because this podcast is depressingly serious at times. And I'm glad that we now have this on a list formally so that we can remember to not take things too seriously. But more seriously, [laughter] I do think that's a wonderful item. And we do have the possibility of really loving the work that we do.

+ +

I find this work to be very fun. And there are different versions of it. And there are different companies and ways that it can go. But for me, this is something that I love to do that I find so much fun in but can get mired down in the details. And so being intentional and saying, "This should be fun. If it's not, what's going on?" That's at least something to look at. And where can I find the fun? And how can I revisit that? So I really enjoy that that is the final item that you're capping your list off with, in fact.

+ +

So for me, the way that I've thought about this list as we've composed it over each of the years is what are the major themes? And for me, probably the biggest theme is that I have joined an early-stage startup, and I've joined on as CTO. So it's a very different role. It's a very different type of interaction. I'm not sure I've ever said the company's name before on this show because I'm a terrible salesman. The company is Sagewell Financial. And so we are trying to do something very ambitious.

+ +

And the role that I'm in is a very interesting one. It's composed of pieces that have always been part of my work. There have been bits of mentoring, and hiring, and architecting, but then also doing the individual contributor work and all of those different pieces, and those will all be present but to varying degrees.

+ +

And the amount of ownership I have over the thing is very different than the long history of consulting that I've done. And so I'm really excited to lean into that and to explore that and to find out what it feels like to code less because I think that's just kind of a given. It's already started to happen even this early on in the project, and I know it's probably only going to continue, which is an interesting one relative to your "Remember the fun." I find coding very fun. So that'll be an interesting one to see how it plays out.

+ +

But I also find all of the other aspects of managing and guiding the technical portion of an organization really interesting. So I'm super excited to continue pushing on that, to go on that adventure. But yeah, it's very different. Or it's every single dial on all of those different measures is just turned up to 11 now is what it is. And I'm like, okay, cool, strap in. Let's go for a ride. This will be fun.

+ +

STEPH: I really enjoyed those discussions about how your role has shifted and the different responsibilities that you're taking on as I have often felt that tension between managing and then coding. And I enjoy both, but then making time for both, and then which ones do you grow in? Because I'm still always growing and striving to be a better manager and a team lead. But then I also want to continue to grow and be a better individual contributor. And focusing in those two areas or trying to grow in both directions is hard.

+ +

So then I often have to pick one to focus on. Maybe it's for a day, maybe it's for a week, maybe it's for a month. And I'm like, hey, for a month, I want to grow in this particular manager skill. But then that way, I feel like I have this more achievable goal. So all that is to say I really like your number 5. And I'm really looking forward to more conversations about how it's going and all the different things that you learned from being a CTO.

+ +

CHRIS: Well, I think on that wonderful note, we should probably wrap up this episode and wrap up this wonderful year of The Bike Shed. As always, Steph, it's been such a pleasure getting to chat with you on these weekly tech talk and nonsense adventures that we go on.

+ +

STEPH: Likewise. This has been so much fun. And when I mentioned earlier about having sparks of joy, Bike Shed is always one of those. I love these conversations that we have. It's been a wonderful year.

+ +

CHRIS: Cool. Well, I will see you in 2022.

+ +

STEPH: On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NcNYpZW4 + + ]]> + + Chris Toomey + Steph Viccari + + + 319: Wins & Losses + https://bikeshed.thoughtbot.com/319 + e16eebd6-d2d4-4ec8-bc88-3a07b946d205 + Tue, 14 Dec 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph started a new project and shares details about the new tools she's using, including working on a remote dev environment. Chris shares a journey with Lograge and Rails flash messages as he strives to capture user-facing errors. + +They also discuss "silencing" flaky tests, using Graphviz to visualize data dependencies, and porting Devise views to use Inertia and Svelte. It's also interesting how different their paths have been this year! + 35:20 + no + + Steph started a new project and shares details about the new tools she's using, including working on a remote dev environment. Chris shares a journey with Lograge and Rails flash messages as he strives to capture user-facing errors. +They also discuss "silencing" flaky tests, using Graphviz to visualize data dependencies, and porting Devise views to use Inertia and Svelte. It's also interesting how different their paths have been this year! +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Joel Quenneville (https://twitter.com/joelquen) +GitHub - roidrage/lograge: An attempt to tame Rails' default policy to log everything (https://github.com/roidrage/lograge) +Graphviz (https://graphviz.org/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: Tech talk nonsense and songs, that's what people come to The Bike Shed for, variations on the Jurassic Park theme song, you know, normal stuff. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. Let's see. So I've started a new project. So frankly, there's a ton of new stuff in my world. And I've been on the project for about a week and a half now. I started over the holiday, and it's been going really well. Still in that whole early stage with getting to know the application, the codebase, the processes, the team, all the dynamics. +It's a large company. So I'm working with a small group of individuals, but there are about over 100 developers that work at this company. And they do have a lot of documentation, which has been very helpful. But there's a lot to learn in terms of setup and processes, specifically. +So they have provided a laptop that I'm using to access their codebase. So I'm using their laptop. And then, I am also using a dev machine, a remote dev machine, that they have set up for me. So I need to be on their VPN and SSH into that dev machine. So that's novel as well. +CHRIS: Ooh, I'm very intrigued by that bit, not that they gave you a laptop bit but the dev machine. This is in the cloud sort of thing? What is this? I'm very intrigued. +STEPH: I don't know if I have concrete answers for you. But yes, for me to be able to access their codebase, I have to go into the dev machine. And then that's where then I can do my normal development work. +CHRIS: So is this like an EC2 instance or something like that that you're SSH-ing into, and then you can run processes on it? Or is it closer to the GitHub dev containers thing that they just released? Or are you running with your local Vim? Is it a remote Vim? Are you using Vim? Is it VS Code? I have so many questions. +STEPH: [laughs] I think it's more like the first version, although I don't know the backbone of it. I don't know specifically if it's an EC2 instance or exactly how it's being hosted and how I have access to it. But I did have to set everything up on it. +So they started the dev machine up for me. Their DevOps team started an environment where then I could access, and then I did need to cultivate it to my own habits. So I had to install several things. I had to install Brew and Vim and also the tmux and all those configurations that I'd really like to have. +They do have a really nice Confluence document that walks you through how to set up a connection between VS Code and the remote environment. So then that way, you can really just hang out in VS Code all day. And initially, I was like, okay, I could do this. And immediately, I was like, no, I love Vim. I'm going back to it even if I have to spend the 20, 30 minutes setting it up. +I'm so comfortable with Vim and tmux that I stuck to my roots, and I didn't branch out into VS Code. But I think VS Code is one of the more popular tools that they're using. So that way, it feels more local versus having to work in a remote machine. I think I answered some of your questions. I don't think I answered all of them. +CHRIS: Yes. I think you did answer all the questions. But just for clarification, the Vim and tmux and whatnot setup is that you're running SSH, and then on the remote machine, you are using Vim and tmux? Or is it a local Vim that is doing…I think Vim has some remote editing capabilities but not anywhere near what VS Code can do. +STEPH: It's the first setup. So I am SSH-ed in. And then I have Vim and tmux running on that remote machine. +CHRIS: Gotcha. Novel. +STEPH: Yeah, it's a thing. It's working. So that's good. And it feels cozy. I feel like I'm at home. I feel like I can be productive. So that's great as well. Some of the other tools that I'm also new to, so they use Zeus, which is used to then speed up the booting of your application. And you can also use it for speeding up test runs. So very similar to Spring, which I think we've had some discussions about Spring and who loves it and who doesn't. [laughs] +CHRIS: I don't know. I'm not...[chuckles] I feel like I remember Zeus. But Zeus is like three iterations ago of this preloader thing. I'm intrigued by that. I thought Spring had fully supplanted it in the Rails ecosystem but maybe not. +STEPH: So this company has been around for a very long time. So there are a number of tools that I think they're using because that was the tool to use the day when they got started. And then it just hasn't been a need to move on to one of the newer tools to use Spring. So at least that's my current explanation for why we're using Zeus. And also, Zeus works most of the time. I'm frankly still getting comfortable with it. [laughs] I still have gripes about Spring too. +CHRIS: 60% of the time, they work most of the time. +STEPH: [laughs] So, Zeus is another new tool that I'm adding to my tool belt during this engagement. Another new tool that I'm using is Gerrit. And so they use Gerrit…it is used for managing their Git repositories. It is used for code reviews. And being as accustomed and familiar with GitHub as I am, that one has been a little tricky to then navigate and change the whole UI that I'm used to when it comes to pushing up code, reviewing code, asking for feedback on changes. +And at one point, I was reviewing a change request for someone else. And there's a button on there where I was adding comments, but they were in draft mode. And I'm trying to figure out how to get them out of draft mode so that they're actually submitted, and the other person could see it. And I saw a submit button. I was like, cool. So I hit the submit button. And then it said something in red text about ready to be merged into main. [laughs] I was like, oh, no, I mean, maybe, but that's not what I meant to do. +So I had to reach out to that person and be like, "Hey, I'm new to Gerrit. I don't know what I did. I hit a button. I hope everything's fine. Here's my review. Best of luck. [laughs] I think everything is fine. Nothing dramatic came out of it. But I had my own little dramatic moment. +CHRIS: Wow, that is a bunch of new stuff. It's interesting. On the one hand, I totally understand projects get started, and there's a certain set of tools that are current at that point, and so then you're using them. And then, over time, it takes a very active effort to try and keep up with the new current, that new-new as we call it. +But the trade-off there is really interesting because, at any given time, it never feels like the right investment to pursue the new thing to just upgrade for upgrading sake. But then the counterpoint is the cost to someone like you coming onto the project. And it's like, it's a bunch of new stuff. It's kind of old stuff. It's new for me, but it is old, and less documented, and less familiar. And it's also certainly less compatible with other things that are going on, almost certainly. +And so, how to stay on top of those updates is always the thing that's really intriguing to me. I say as someone who started a project recently, and I have not thought about upgrading anything at this point. And we have bundler-audit I want to say is the one thing that we have in there. So if there's a CVE for a gem, then security-wise, we will be upgrading those. But otherwise, I haven't thought about upgrading our Ruby version or anything. And I think we're on 2.6 or something like that, which is a couple back at this point. And so it's something that's in the back of my mind. +I feel like I should have a formal answer to this. Like, company-wide, how do we think about the process of upgrading? And Dependabot and things like that answers some of it, but that doesn't tell me when to upgrade Ruby, I don't think. It could. That would be annoying. I don't want that. But it's one of those many things that depends and is subtle. And you have to decide where you put the trade-offs and whatnot. So just an interesting thing. And to observe you now going into this project building and being like, there's a bunch of new stuff. +STEPH: I think it really takes passion or pain. Those are the two things that then prompt us to upgrade. Either it's pain, and you need to change it to get rid of that, or it's passion. So you're really excited about the next version of Ruby or the next version of Rails. And I think that's fine. I think that's fine that those are often our drivers. But yeah, that is interesting. I hadn't really thought about that in terms of there's often no real strict process around when we upgrade except those are then the natural human catalyst. +CHRIS: I think you're right that those are the catalysts. But I think quite often those cannot be sufficient to push us to do the work. And so what do you do in the absence of that? It's not really painful. And I'm not really passionate about it. But I probably should do it is the 80% of the time middle space that we live in. And so yeah, I don't have an answer to it. I'm more observing the question. But like so many other things, I feel like often we just exist in that awkward middle and got to find a way through, so how like life. +STEPH: I was having a conversation with someone earlier a bit about these life cycles that we live in. Specifically, we were talking about consulting and how changing from project to project is so daunting. Because you go from I'm accustomed to this project, I'm accustomed to the team. And then all of a sudden you jump into this new project and with all these new things it can be really interesting. +But then there's also this feeling of like, wait, I used to be smart, and I knew everything that was going on. And the team knew me, and I knew all the team processes, and I felt good. And now I'm in this totally new space, and I have to relearn, and I have to reprove myself and relearn all the company politics. +And there's always that initial jumping from a sure space over to a very new space that always makes me then question and be like, yeah, I can do this, right? I can do this. And then I have to keep letting that voice build until about two weeks in. And I'm like, oh okay, I'm back in a good spot. I said two weeks; it's probably more like four. +But there's still that grace period of a new project where you're leveling up on all the things and learning the new team. And as daunting as it is; apparently, it's what I like. Apparently, I like that roller coaster ride that comes from jumping from one project to the next. So on that note of a bit of novel insight into myself, what's new in your world? +CHRIS: What is new in my world? Let's see. I think I've got two updates, two anecdotes to share. One, I lost the battle, one I won the battle. So we'll go with the lost battle first because that seems fun. So we have Lograge on this application, which Lograge, for anyone that's not familiar, is a library that helps with producing more structured and more complete log lines from a Rails application. +You can tell it to do JSON log lines, which is useful for many of the tools that will receive your logs. And then with it, you can say grab me the controller name and the params but sanitized and this and that. And so, you aggregate a bunch more data than would traditionally be in the logs. In general, I've just found it to be a much better foundation. I find the logs to be more readable, and more informative, more useful, all those lovely things. +But slowly, I've been looking at what's the other stuff that I want to have in here? What else would be nice to know? So one example is we use Inertia on this project. And Inertia has a particular way in which errors get mapped back to the front end. And it's an interesting little trick that involves the session, but that's sort of an aside. Basically, this is something that the user will see that I would love to know about. So how many users are hitting their head against the wall? +Because typically, whenever these errors happen, that means this is a flash message or something like that we're going to show to the user. So we were able to add that into our log lines. Now we can see those. We can aggregate on them. We can do counts. We can do alerting and monitoring, all those kinds of fun things. So cool. That was great. That worked well. +I then specifically…I mentioned the flash a second ago, but that's actually not…the Inertia messages will not show up in the flash. They end up in forms inline on certain inputs or whatnot. But we do also use the flash message pretty regularly as a way to communicate to the user success or failure or what have you. And I really wanted to get those into the logs. And I tried very hard, and I failed. I gave up. I threw in the towel. I raised the white flag. +So the nature of the flash, which is something that knew in the back of my mind but I had never really experienced as pointedly as this, is the flash is a magic value within the Rails ecosystem that can be written to and then once read clears itself. That's the nature of how the flash is supposed to work. And it persists across requests. So it's doing some fun stuff there, which I assume is tunneling through the session or maybe putting it into a cookie. I'm not actually sure. +But there's some way that you post to an endpoint, and then you get redirected to the show page. And on the show page, we actually display that flash value. But the flash is set on the controller endpoint that is handling the POST request. So this value spans across two request-response life cycles, which is interesting. +And so the manner in which that works is Rails is managing that on our behalf. We write to it on the one side. And then, when we do the subsequent requests, if there's a value in the flash, we show it to the user, which is why occasionally you'll see those weird things where that flash message shouldn't show up. But it's like a sticky value that was left in the system that didn't get cleared via one thing or another. +But I really wanted to put those into the logs. Like, what are we saying to the user is the thing I want to know. This is that question of like, what's my system doing at runtime? I understand what it's doing. I can read the code and understand what should happen. But what actually happened? Are users seeing this flash message way more than they should? That's a question I want to be able to answer. +And I have lost the battle. I cannot find a way to read the flash value, put it into my loglines, but then also have it persist through. The first attempt I did, I was able to get it into my loglines, but then it didn't show to the user, which is a bad outcome. Because now I've read the value, Rails clears it, cool, that's fine. +There is a flash.keep method. And that I thought would do the thing I wanted, which is like, oh, I want to read this value. I want to tap this value, I want to observe it, I want to peek at it. And I thought this keep method would do the thing that I wanted. It did not. It just caused the flash to be persistent. So now, anywhere I went had the same flash message for forever, which was not the behavior that I was looking for. +I then tried, like, all right, just for exploration purposes, what if I reach inside and read the instance variables of the flash objects? Also did not work. Everything I tried did not work. And it had these fun failure modes that just made me very sad. Thankfully, we had feature specs that told me about this failure mode because I would not have known about it otherwise. This was not obvious to me on first implementation. But yeah, I lost, and I feel sad. +And then I did the thing that we do, which is I searched Google, and there's nothing. I cannot find…This is one of those cases where like, I can't be the first person who wants to know what's in the flash. I can't be breaking new ground here. And yet I couldn't find anything on the internet. So that's where I'm at. +STEPH: That's interesting. Yeah, I'm trying to think…I think I'm one of those people. I don't think I've ever tried to peek into the flash and see what's there ahead of time. And it makes me wonder if it's partially…so we can't peek into the flash. You've exhausted several examples or tries there. +When you're setting the value of the flash, it makes me wonder if there's an order of operations that you have to pursue. So before you set the flash, you know what messages that you're going to share. So you send that off to the logs, but then also share that to the flash. So instead of writing the message directly to the flash and then having to check the flash, if you just stored that value elsewhere and shared it to the logs first. Is that a reasonable approach? +CHRIS: It definitely could work. But that was in the space of this is getting weird enough. I thought about things like that, but I didn't want to do anything weird. And part of the benefit that I get from using Lograge is rather than having multiple lines for each request…so a request came in and rendered this partial and did this thing. It gets constructed such that there's a single logline, which is one big JSON object that contains all of the data about that request. +And I really liked that structure because then everything's correlated like, oh, did we 404, or did we 302? And what was the message that we said to the user? And what were the params? It's all there in one line. I found that to be really useful. So I wanted to do that. I could just separately log it. But then I'm also worried of there is a statefulness there. Because again, the flash is written on one side and read on the…it's like a Hail Mary to ourselves between requests. Look at me with a sports reference. +And so, I didn't want to try anything out of the ordinary. I really just wanted to find a way to just like; I just want to read this value but not like Heisenberg uncertainty principle observing changes in the system. I found myself in that space, and I was like, can't there be a way that I can just flash.peek? And I just want to take a quick look. I don't want to mess with anything. You do your normal thing, flash. Just let me know. And I do not have an answer for it yet. +And for now, this is one of those nice to have, not an absolute requirement. So I wasn't yet in the position of okay, fine, let's do some out-of-the-box ideas here. So I'm still in the in the box phase, I would say, but who knows? Maybe down the road, I'll be like; I would really love to know what the flash message was for that request because this user is seeing stuff that we do not understand. And that information would tell us the answer. So we're not there yet. But I was surprised by how thoroughly I was defeated by Rails and the flash message on this adventure. +STEPH: I am equally surprised. I wouldn't have thought that particular achievement would have or is proving to be that hard or, frankly, not doable. So yeah, I'm intrigued to see if anybody has thoughts on it or if you do find a different solution because Lograge is one that I haven't used. But I would be surprised if other people haven't had a similar request of like; I want to be able to store what's in the flash message. Because like you said, that seems super helpful. +CHRIS: Well, certainly, if I do figure anything out, then I will share that with the world. But yes, part of this is putting it out there into the universe. And if the universe happens to send me back an answer, I will happily accept that. But yeah, again, I had two stories, and that was the one where I lost. I'm going to send it back over to you because I'm interested in anything else that's up in your world. And later, I'll tell the story of a victory. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: I have a victory that I can share as well, and I'm excited to hear about yours. So to share a bit more context about the project that I'm on, we are focused very heavily on improving their test suite, not only the time that it takes to run the test suite but predominantly addressing a lot of the flaky tests that they have. Because that is a huge pain point for the team and often leads to the team having to rerun tests. +And so, there are a couple of areas that we're very excited to make some contributions. The first part is that we are just looking at those flaky tests to figure out what is going on and how can we address these? And one of the nice things, one of the tools that they're using TeamCity is the tooling that they're using to run their automated test suite. +And TeamCity will let you mute tests, so then that way, if you do encounter a flaky test, you can mute it. So then, at least it's not impacting other people. I say this with some asterisks that go along with it because, for people who can't see, Chris is making a very interesting face. I think you have thoughts on this. +And the other thing that they will show is a flip rate for the flaky tests, which is really nice, too, because then you can see which tests are flaky the most. So then that helps us prioritize which ones we want to look into. All right, I'm going to pause so you can respond to that comment I made about muting tests. +CHRIS: I'm intrigued. I talked in a recent episode about adding RSpec::Retry. So the idea of flakiness being a thing that exists and trying to decide how much engineering effort to apply to fixing it. But the idea of muting it and especially muting it in the UI, not in the test suite or not having that be something that's committed, there's something about that that caught my attention, and thus apparently, my eyebrows raised. You saw that. [laughs] +But I don't actually know how I feel about it. This is such a complicated, murky area that I wish I had a stronger set of beliefs around. It was interesting when we talked about the RSpec::Retry thing. I think you rightly pushed back on me, and you were like, that's interesting, maybe don't do that. And I was like, that's a fair point. [laughs] And so now hearing you're in the quagmire of flaky tests, and yeah, it's an interesting space. +STEPH: Well, I think my hard belief is that muting tests is a thing that we shouldn't do. It's going to lead to more problems, and you're not really addressing the issue that you have. It is a temporary solution to a much bigger problem that you have. And so it is a tool that you can use to then buy you some more time. +And so that is the space that this team is in where they have used this particular tool to buy them more time and to be able to keep shipping changes while realizing that they do still need to address these underlying issues. So it is a tricky space to be in where essentially, you've gotten to the point that you do have these muted tests. It is a way to help you keep going forward, but you are going to have to come back to it at some point. +And so that's the space that I'm in right now joining the team is that we have been brought in to help some of their engineers specifically address this issue while ideally letting the rest of the team continue to focus on shipping changes while we address the test. Although I really think there's going to be two angles that we've talked about in how we're going to help this particular codebase. +One of them is that we are going to address a flaky test. But the other one is empowering people that they feel like they have the time and the knowledge that they can address a flaky test and also not contribute more flaky tests to the codebase. But I appreciate that you called me on that a bit because we've had those conversations around when we should actually address something versus muted, all the interesting trade-offs that come along with that conversation. +So this particular flaky test that we addressed earlier this week is specific to hard coding primary IDs. The short version is that it's bad, don't do it. The longer version is that they were having a test that was failing intermittently because it would pass the first two runs, but then it would start to fail for all future runs. +And the reason it would pass for the first two runs is because when they were setting the ID for a record that the test setup is creating, they were looking for existing records and saying, "Hey, what's your latest ID?" And then I'm going to guess the next ID. I'm going to add one to that to figure out what the next ID should be. +Some additional context, when the tests boot up, there's some data that's being created before the test run. So then that's why they're checking to see, okay, what records already exist? And then let's add one to that. The reason that fails sometimes is because then once the tests have run, the Postgres IDs aren't being reset, so they're using a truncate approach. So then, when the test runs once or twice, that works. But then, at some point, there's a collision between those IDs where they tried to guess the next ID, but then Postgres is also on that same ID, and it ends up failing. +There are also some callbacks. There's some trickery afoot. It took a little while [chuckles] to work through these tests to understand why they're failing. But the short version is that we thought we had to restructure the data in a way that no longer required us to guess what the next primary key should be for a record. +We could actually use Factory Bot to generate that record, and then ask Postgres, okay, what ID did you assign? And we're going to pass that in. And that part was really challenging when you're in a new codebase, and you are learning the domain knowledge and exactly how data should be structured. So that was one challenge of it. +The other part was that a lot of the data relies on each other. So then figuring out the right hierarchy in which we could create the data. So we didn't have a circular reference at some point. It took some time. And Joël Quenneville, who's on the project with me, used a tool that I found very helpful. It's called Dataviz. He went through and documented the let statements, the data that's being created, and then it generated a nice tree structure that shows you okay; these are your dependencies. This is the test setup that you're using. +And then from there, just by changing a few lines in that particular file that used to generate that Dataviz tree, he would move it around. And we could simulate what we were already mentally trying to construct in our head. So as programmers, we're already thinking, okay, I know this record needs that data. And that data needs that data before I can build this. But this actually turned it into a concrete visualization where we could see it. +And I was really struggling. And he was like, "Hey, I got it into a visual form that we can look at. And there's a circular reference. That's why this keeps happening and why we're not making progress." So then, using that, we were able to then reformat some of the dependencies, look at the graph, see that we didn't have that circular reference anymore. And then we could implement that in code. +And it really helped me to be able to walk through that visual aspect because then I could say, okay, this is all the stuff that I'm trying to mentally hold on to, but instead, I can just look at this and know it's going to work. I don't have a circular reference. It also helped concretely show why the previous efforts were failing and why we kept running into some issues. +So I'm really interested now in Dataviz because I found it very helpful in this particular case. And I'm very intrigued to see if I can apply this to more tests that I'm trying to fix and to see if I can start out with here's the current structure. Here's where I'm trying to go. And then essentially build that graph first before I start changing the code around. I would love to have that optimization. And I feel like it would speed up the process. +CHRIS: It was funny as you started to say that I had observed some tweets going out into the world recently. And I was like, this is Joël. This is definitely Joël talking about these things. As an aside, for anyone who doesn't follow Joël Quenneville on Twitter, @joelquen, I would highly recommend it. We can include a link to Joël's Twitter in the show notes. Joël is one of the clearest thinkers and communicators about programming that I have ever worked with. +And in particular, what you're describing of the data visualization is something that I think he does incredibly well. Often he'll make blog posts, but they'll include just simple little visualizations, little images, or diagrams, or flowcharts that just so concretely encapsulate an idea and express it so much better than text ever could. +And so, in so many ways, I look to Joël's writing, both on Twitter, in the blog, in many places. And I just appreciate so much what he puts out there and the manner in which he does it. So I was by no means surprised when you said, "Oh, and I'm working with Joël on this project." I was like, yes, I bet you are. That sounds true, and in particular, some of the conversations about flaky tests and determinism and all of that. +So yeah, the visualization stuff is also particularly interesting in taking a system that it's very hard to hold all of this in our heads. But that visualization, the tree and/or graph thing at play, having that in a picture and being like, oh, look, there's a cycle now. There we go. Can't have those. That's not okay. That's a really interesting solution that's just very cool to hear about and presumably led to a good outcome where you were able to break that cycle. And now you're happy and deterministic in your tests. +STEPH: Yeah, it's one of those approaches where I wonder if it was helpful afterwards and how can I make it helpful beforehand? Because it felt like a confirmation of the pain in the process that we had been through. And I'm eager to see if now I can apply it ahead of time and save myself some of that pain. That's where I get really excited. But yes, it was a successful outcome. And we have fixed that particular flaky test. But I'm very excited to hear about your victory from the week. +CHRIS: It's a shared victory. It was a team victory, just to be clear. But we are working in a system that is using Inertia. Inertia.js is a project that I've talked about a number of times on the show. I'm a huge fan of it. It is the core architecture of how we're building our application. +But as a very brief revisiting of what it is, on the server-side, we have Rails, and Rails is acting in a pretty traditional way. We do not have an API. And on the front end, we have Svelte, which is a JavaScript view layer framework. Inertia sits between them and binds the traditional Rails MVC architecture and the Svelte front end. +So again, there's no API in the traditional sense of this is a REST endpoint, and we hit it, and we get some data, and then the front end holds on to that in a store. None of that is going on. Inertia does a wonderful job of marrying these two concepts and allowing us to use familiar programming techniques on the server-side but then also have a more future-friendly front end. +Animations and transitions and things like that are now totally possible while not throwing away the entirety of our programming model that we've had in Rails server-side applications. That's all well and good. Almost all of the UI in our application is rendered via Inertia and Svelte. That's great. We love it. +The one caveat is Devise. So we have Devise on this project, and Devise comes with a lot of views built-in. And we have both an admin and a user model. So we have sign in and sign up, and confirm registration, and forgot password and all of these different views and flows and things that Devise just gives you out of the box. And being an early-stage startup, it was not a good time to revisit any of that or to try and build it from scratch or any of that. We just wanted to build on the good known trusted foundation that Devise gives us. +But the trade-off there is that now all of our Devise logic lives in this uncanny valley. It's the only stuff that is in ERB views. Our styling, thankfully, we're using Tailwind, and so we are able to have some consistency between the styling. +But recently, we redesigned the flash messages on the client-side in our Svelte pages. But on the server-side, they are a little on the Devise-side because Devise is the only pages that are being rendered truly server-side. They look a little different. And this is a pain that we felt, that inconsistency or that mismatch between the Devise views. And then the rest of the application is a pain that we felt but one that we consistently were like, I don't think it's worth the effort to try and change this. +Finally, this week, we've been doing a lot of work on our user onboarding funnel. So the initial signup flow going through it's a progressive form screen where you go in between different pages. And a majority of it is implemented in the Inertia and Svelte side of things. And it's very nice and very fun to work with. But the signup form, the user signup form, is in Devise, and it's a traditional Rails server-rendered post, and then all the normal stuff happens. +We finally decided to bite the bullet this week and see how painful it would be to port that over to Inertia and Svelte. And spoiler, it was awesome. It was very straightforward, and coming out of it, immediately, the page was largely the same. The server-side code was largely the same. +But now we had things like when you submit this form, if there's a validation error, we don't clear out your passwords because we're staying on that page on the client-side. We're taking advantage of the way Inertia's error flow works. That's a subtlety of how Inertia works. That's probably more detail than we want to get into here, but it's an awesome thing that works and is great. +And so immediately, this page just got better. We got inline errors for each of the fields. We were able to very easily add a library called Mailcheck, which I've talked about on an episode a while back. But this is a thing where if you have a typo in your email address, we can say, "Hey, you have a typo in your email address. And if you click this link where we suggest the alternative, we'll just replace it inline." +That would have been really awkward to wire up in our Devise view. It would have been some jQuery-esque script tag at the bottom of the view page that doesn't stop…We don't have jQuery actually at this point. We wouldn't have jQuery. And we could certainly, but it would only be for that view. And it would be weird and different in a fundamentally different programming model. It was trivial to do in the Inertia and Svelte world once we had made that port over. +This was always my hope. This was the dream that I had in mind. And it speaks to the architecture of Inertia. And Inertia is a really great abstraction that is very minimally leaky. I won't say it has zero leaks because no abstraction does. But this was my hope is I think the server-side should mostly stay the same. And I think the client-side, we just take an ERB template, turn it into a Svelte template, and we're good to go. And that has largely been the case. +But suddenly, this page is so much more. There are subtle animations as things come in. And there are just lots of nice features that were trivial to add now and that fit with the rest of the programming model that we have throughout it. So that was awesome. +STEPH: That is awesome. I love these styles of updates where there's like, oh, I had a loss this week. But I also had this really great win because that feels just so representative of a typical week. So I love this back and forth. +CHRIS: It's also that sequence is how the week went. So the loss happened earlier in the week, and then the win happened later in the week, which is how I would prefer it because now I'm going into the weekend with a win. Like, cool, I'll take it. Had it gone in the other direction, I would have been like, oh man, Rails beat me. But I guess it's the weekend now. I'll forget about it for a little while. +STEPH: Yeah, that definitely helps to end on a positive note. +CHRIS: But yeah, I don't think too much more to say about that beyond it was both really nice to get the added functionality to get the better, more user-friendly behavior in this view that naturally falls out of this programming model. But also to have that reinforcement of my belief in Inertia as a good architecture. +Not only did we get some really nice stuff out of doing this port, but it was also pretty straightforward because Inertia sits so comfortably between the pieces. And that's a story that I really like. I want more of that in my programming world, where to change this thing requires changing everything in our app. Oh no, this is sad. No, this was a great example of we were able to very minimally change things and get a much better experience out of it. So once again, I am very pro Inertia.js +STEPH: It's interesting to me how different our paths have been this year where I have been working on applications that are brought on thoughtbot to then help out with some of the concerns that they have, either their application is going down, or they have a test suite that they need to improve, or there's a lot of triage that's involved. +And so it makes me very excited to hear that, when you are building stuff, and it's going really well and how awesome that is. Because then I feel like most of my world has definitely been more in the triage space, which is a very interesting and fun space to be. But it brings me a lot of joy to hear about wins from let's build new stuff and hearing it be built from the ground up and how well that's going. +CHRIS: Well, I'm definitely happy to provide that. But also, I want to be realistic and be like, I’m just writing next year's legacy code right now, let's be honest. I'm very happy with where we're at in this moment. But I also know how early I am in the project that I'm working on. +And I'm burdened with the knowledge that I'm certain one decision that I'm making of the many that are being made I will deeply regret a year from now. I just know that that's true, and I can't let it slow me down. I got to just keep making decisions and do stuff. But I know that there's going to be one. I know that a year from now, I'm going to be like, why did we choose that option? But it's sort of the game. +STEPH: [singing] We'll just know that there's something strange and your code won't change. Who are you gonna call? thoughtboters! +CHRIS: Well, yes. I will definitely be calling you when I find myself in the uncertain times of legacy code of my own creation. So I look forward to that, frankly. But that's a problem for a year; I don't know, maybe two years from now. Who knows? But for now, what do you think? Let's wrap up. +STEPH: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it really helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter, and I'm @christoomey. +STEPH: And I'm @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeee!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph started a new project and shares details about the new tools she's using, including working on a remote dev environment. Chris shares a journey with Lograge and Rails flash messages as he strives to capture user-facing errors.

+ +

They also discuss "silencing" flaky tests, using Graphviz to visualize data dependencies, and porting Devise views to use Inertia and Svelte. It's also interesting how different their paths have been this year!

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Tech talk nonsense and songs, that's what people come to The Bike Shed for, variations on the Jurassic Park theme song, you know, normal stuff.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Let's see. So I've started a new project. So frankly, there's a ton of new stuff in my world. And I've been on the project for about a week and a half now. I started over the holiday, and it's been going really well. Still in that whole early stage with getting to know the application, the codebase, the processes, the team, all the dynamics.

+ +

It's a large company. So I'm working with a small group of individuals, but there are about over 100 developers that work at this company. And they do have a lot of documentation, which has been very helpful. But there's a lot to learn in terms of setup and processes, specifically.

+ +

So they have provided a laptop that I'm using to access their codebase. So I'm using their laptop. And then, I am also using a dev machine, a remote dev machine, that they have set up for me. So I need to be on their VPN and SSH into that dev machine. So that's novel as well.

+ +

CHRIS: Ooh, I'm very intrigued by that bit, not that they gave you a laptop bit but the dev machine. This is in the cloud sort of thing? What is this? I'm very intrigued.

+ +

STEPH: I don't know if I have concrete answers for you. But yes, for me to be able to access their codebase, I have to go into the dev machine. And then that's where then I can do my normal development work.

+ +

CHRIS: So is this like an EC2 instance or something like that that you're SSH-ing into, and then you can run processes on it? Or is it closer to the GitHub dev containers thing that they just released? Or are you running with your local Vim? Is it a remote Vim? Are you using Vim? Is it VS Code? I have so many questions.

+ +

STEPH: [laughs] I think it's more like the first version, although I don't know the backbone of it. I don't know specifically if it's an EC2 instance or exactly how it's being hosted and how I have access to it. But I did have to set everything up on it.

+ +

So they started the dev machine up for me. Their DevOps team started an environment where then I could access, and then I did need to cultivate it to my own habits. So I had to install several things. I had to install Brew and Vim and also the tmux and all those configurations that I'd really like to have.

+ +

They do have a really nice Confluence document that walks you through how to set up a connection between VS Code and the remote environment. So then that way, you can really just hang out in VS Code all day. And initially, I was like, okay, I could do this. And immediately, I was like, no, I love Vim. I'm going back to it even if I have to spend the 20, 30 minutes setting it up.

+ +

I'm so comfortable with Vim and tmux that I stuck to my roots, and I didn't branch out into VS Code. But I think VS Code is one of the more popular tools that they're using. So that way, it feels more local versus having to work in a remote machine. I think I answered some of your questions. I don't think I answered all of them.

+ +

CHRIS: Yes. I think you did answer all the questions. But just for clarification, the Vim and tmux and whatnot setup is that you're running SSH, and then on the remote machine, you are using Vim and tmux? Or is it a local Vim that is doing…I think Vim has some remote editing capabilities but not anywhere near what VS Code can do.

+ +

STEPH: It's the first setup. So I am SSH-ed in. And then I have Vim and tmux running on that remote machine.

+ +

CHRIS: Gotcha. Novel.

+ +

STEPH: Yeah, it's a thing. It's working. So that's good. And it feels cozy. I feel like I'm at home. I feel like I can be productive. So that's great as well. Some of the other tools that I'm also new to, so they use Zeus, which is used to then speed up the booting of your application. And you can also use it for speeding up test runs. So very similar to Spring, which I think we've had some discussions about Spring and who loves it and who doesn't. [laughs]

+ +

CHRIS: I don't know. I'm not...[chuckles] I feel like I remember Zeus. But Zeus is like three iterations ago of this preloader thing. I'm intrigued by that. I thought Spring had fully supplanted it in the Rails ecosystem but maybe not.

+ +

STEPH: So this company has been around for a very long time. So there are a number of tools that I think they're using because that was the tool to use the day when they got started. And then it just hasn't been a need to move on to one of the newer tools to use Spring. So at least that's my current explanation for why we're using Zeus. And also, Zeus works most of the time. I'm frankly still getting comfortable with it. [laughs] I still have gripes about Spring too.

+ +

CHRIS: 60% of the time, they work most of the time.

+ +

STEPH: [laughs] So, Zeus is another new tool that I'm adding to my tool belt during this engagement. Another new tool that I'm using is Gerrit. And so they use Gerrit…it is used for managing their Git repositories. It is used for code reviews. And being as accustomed and familiar with GitHub as I am, that one has been a little tricky to then navigate and change the whole UI that I'm used to when it comes to pushing up code, reviewing code, asking for feedback on changes.

+ +

And at one point, I was reviewing a change request for someone else. And there's a button on there where I was adding comments, but they were in draft mode. And I'm trying to figure out how to get them out of draft mode so that they're actually submitted, and the other person could see it. And I saw a submit button. I was like, cool. So I hit the submit button. And then it said something in red text about ready to be merged into main. [laughs] I was like, oh, no, I mean, maybe, but that's not what I meant to do.

+ +

So I had to reach out to that person and be like, "Hey, I'm new to Gerrit. I don't know what I did. I hit a button. I hope everything's fine. Here's my review. Best of luck. [laughs] I think everything is fine. Nothing dramatic came out of it. But I had my own little dramatic moment.

+ +

CHRIS: Wow, that is a bunch of new stuff. It's interesting. On the one hand, I totally understand projects get started, and there's a certain set of tools that are current at that point, and so then you're using them. And then, over time, it takes a very active effort to try and keep up with the new current, that new-new as we call it.

+ +

But the trade-off there is really interesting because, at any given time, it never feels like the right investment to pursue the new thing to just upgrade for upgrading sake. But then the counterpoint is the cost to someone like you coming onto the project. And it's like, it's a bunch of new stuff. It's kind of old stuff. It's new for me, but it is old, and less documented, and less familiar. And it's also certainly less compatible with other things that are going on, almost certainly.

+ +

And so, how to stay on top of those updates is always the thing that's really intriguing to me. I say as someone who started a project recently, and I have not thought about upgrading anything at this point. And we have bundler-audit I want to say is the one thing that we have in there. So if there's a CVE for a gem, then security-wise, we will be upgrading those. But otherwise, I haven't thought about upgrading our Ruby version or anything. And I think we're on 2.6 or something like that, which is a couple back at this point. And so it's something that's in the back of my mind.

+ +

I feel like I should have a formal answer to this. Like, company-wide, how do we think about the process of upgrading? And Dependabot and things like that answers some of it, but that doesn't tell me when to upgrade Ruby, I don't think. It could. That would be annoying. I don't want that. But it's one of those many things that depends and is subtle. And you have to decide where you put the trade-offs and whatnot. So just an interesting thing. And to observe you now going into this project building and being like, there's a bunch of new stuff.

+ +

STEPH: I think it really takes passion or pain. Those are the two things that then prompt us to upgrade. Either it's pain, and you need to change it to get rid of that, or it's passion. So you're really excited about the next version of Ruby or the next version of Rails. And I think that's fine. I think that's fine that those are often our drivers. But yeah, that is interesting. I hadn't really thought about that in terms of there's often no real strict process around when we upgrade except those are then the natural human catalyst.

+ +

CHRIS: I think you're right that those are the catalysts. But I think quite often those cannot be sufficient to push us to do the work. And so what do you do in the absence of that? It's not really painful. And I'm not really passionate about it. But I probably should do it is the 80% of the time middle space that we live in. And so yeah, I don't have an answer to it. I'm more observing the question. But like so many other things, I feel like often we just exist in that awkward middle and got to find a way through, so how like life.

+ +

STEPH: I was having a conversation with someone earlier a bit about these life cycles that we live in. Specifically, we were talking about consulting and how changing from project to project is so daunting. Because you go from I'm accustomed to this project, I'm accustomed to the team. And then all of a sudden you jump into this new project and with all these new things it can be really interesting.

+ +

But then there's also this feeling of like, wait, I used to be smart, and I knew everything that was going on. And the team knew me, and I knew all the team processes, and I felt good. And now I'm in this totally new space, and I have to relearn, and I have to reprove myself and relearn all the company politics.

+ +

And there's always that initial jumping from a sure space over to a very new space that always makes me then question and be like, yeah, I can do this, right? I can do this. And then I have to keep letting that voice build until about two weeks in. And I'm like, oh okay, I'm back in a good spot. I said two weeks; it's probably more like four.

+ +

But there's still that grace period of a new project where you're leveling up on all the things and learning the new team. And as daunting as it is; apparently, it's what I like. Apparently, I like that roller coaster ride that comes from jumping from one project to the next. So on that note of a bit of novel insight into myself, what's new in your world?

+ +

CHRIS: What is new in my world? Let's see. I think I've got two updates, two anecdotes to share. One, I lost the battle, one I won the battle. So we'll go with the lost battle first because that seems fun. So we have Lograge on this application, which Lograge, for anyone that's not familiar, is a library that helps with producing more structured and more complete log lines from a Rails application.

+ +

You can tell it to do JSON log lines, which is useful for many of the tools that will receive your logs. And then with it, you can say grab me the controller name and the params but sanitized and this and that. And so, you aggregate a bunch more data than would traditionally be in the logs. In general, I've just found it to be a much better foundation. I find the logs to be more readable, and more informative, more useful, all those lovely things.

+ +

But slowly, I've been looking at what's the other stuff that I want to have in here? What else would be nice to know? So one example is we use Inertia on this project. And Inertia has a particular way in which errors get mapped back to the front end. And it's an interesting little trick that involves the session, but that's sort of an aside. Basically, this is something that the user will see that I would love to know about. So how many users are hitting their head against the wall?

+ +

Because typically, whenever these errors happen, that means this is a flash message or something like that we're going to show to the user. So we were able to add that into our log lines. Now we can see those. We can aggregate on them. We can do counts. We can do alerting and monitoring, all those kinds of fun things. So cool. That was great. That worked well.

+ +

I then specifically…I mentioned the flash a second ago, but that's actually not…the Inertia messages will not show up in the flash. They end up in forms inline on certain inputs or whatnot. But we do also use the flash message pretty regularly as a way to communicate to the user success or failure or what have you. And I really wanted to get those into the logs. And I tried very hard, and I failed. I gave up. I threw in the towel. I raised the white flag.

+ +

So the nature of the flash, which is something that knew in the back of my mind but I had never really experienced as pointedly as this, is the flash is a magic value within the Rails ecosystem that can be written to and then once read clears itself. That's the nature of how the flash is supposed to work. And it persists across requests. So it's doing some fun stuff there, which I assume is tunneling through the session or maybe putting it into a cookie. I'm not actually sure.

+ +

But there's some way that you post to an endpoint, and then you get redirected to the show page. And on the show page, we actually display that flash value. But the flash is set on the controller endpoint that is handling the POST request. So this value spans across two request-response life cycles, which is interesting.

+ +

And so the manner in which that works is Rails is managing that on our behalf. We write to it on the one side. And then, when we do the subsequent requests, if there's a value in the flash, we show it to the user, which is why occasionally you'll see those weird things where that flash message shouldn't show up. But it's like a sticky value that was left in the system that didn't get cleared via one thing or another.

+ +

But I really wanted to put those into the logs. Like, what are we saying to the user is the thing I want to know. This is that question of like, what's my system doing at runtime? I understand what it's doing. I can read the code and understand what should happen. But what actually happened? Are users seeing this flash message way more than they should? That's a question I want to be able to answer.

+ +

And I have lost the battle. I cannot find a way to read the flash value, put it into my loglines, but then also have it persist through. The first attempt I did, I was able to get it into my loglines, but then it didn't show to the user, which is a bad outcome. Because now I've read the value, Rails clears it, cool, that's fine.

+ +

There is a flash.keep method. And that I thought would do the thing I wanted, which is like, oh, I want to read this value. I want to tap this value, I want to observe it, I want to peek at it. And I thought this keep method would do the thing that I wanted. It did not. It just caused the flash to be persistent. So now, anywhere I went had the same flash message for forever, which was not the behavior that I was looking for.

+ +

I then tried, like, all right, just for exploration purposes, what if I reach inside and read the instance variables of the flash objects? Also did not work. Everything I tried did not work. And it had these fun failure modes that just made me very sad. Thankfully, we had feature specs that told me about this failure mode because I would not have known about it otherwise. This was not obvious to me on first implementation. But yeah, I lost, and I feel sad.

+ +

And then I did the thing that we do, which is I searched Google, and there's nothing. I cannot find…This is one of those cases where like, I can't be the first person who wants to know what's in the flash. I can't be breaking new ground here. And yet I couldn't find anything on the internet. So that's where I'm at.

+ +

STEPH: That's interesting. Yeah, I'm trying to think…I think I'm one of those people. I don't think I've ever tried to peek into the flash and see what's there ahead of time. And it makes me wonder if it's partially…so we can't peek into the flash. You've exhausted several examples or tries there.

+ +

When you're setting the value of the flash, it makes me wonder if there's an order of operations that you have to pursue. So before you set the flash, you know what messages that you're going to share. So you send that off to the logs, but then also share that to the flash. So instead of writing the message directly to the flash and then having to check the flash, if you just stored that value elsewhere and shared it to the logs first. Is that a reasonable approach?

+ +

CHRIS: It definitely could work. But that was in the space of this is getting weird enough. I thought about things like that, but I didn't want to do anything weird. And part of the benefit that I get from using Lograge is rather than having multiple lines for each request…so a request came in and rendered this partial and did this thing. It gets constructed such that there's a single logline, which is one big JSON object that contains all of the data about that request.

+ +

And I really liked that structure because then everything's correlated like, oh, did we 404, or did we 302? And what was the message that we said to the user? And what were the params? It's all there in one line. I found that to be really useful. So I wanted to do that. I could just separately log it. But then I'm also worried of there is a statefulness there. Because again, the flash is written on one side and read on the…it's like a Hail Mary to ourselves between requests. Look at me with a sports reference.

+ +

And so, I didn't want to try anything out of the ordinary. I really just wanted to find a way to just like; I just want to read this value but not like Heisenberg uncertainty principle observing changes in the system. I found myself in that space, and I was like, can't there be a way that I can just flash.peek? And I just want to take a quick look. I don't want to mess with anything. You do your normal thing, flash. Just let me know. And I do not have an answer for it yet.

+ +

And for now, this is one of those nice to have, not an absolute requirement. So I wasn't yet in the position of okay, fine, let's do some out-of-the-box ideas here. So I'm still in the in the box phase, I would say, but who knows? Maybe down the road, I'll be like; I would really love to know what the flash message was for that request because this user is seeing stuff that we do not understand. And that information would tell us the answer. So we're not there yet. But I was surprised by how thoroughly I was defeated by Rails and the flash message on this adventure.

+ +

STEPH: I am equally surprised. I wouldn't have thought that particular achievement would have or is proving to be that hard or, frankly, not doable. So yeah, I'm intrigued to see if anybody has thoughts on it or if you do find a different solution because Lograge is one that I haven't used. But I would be surprised if other people haven't had a similar request of like; I want to be able to store what's in the flash message. Because like you said, that seems super helpful.

+ +

CHRIS: Well, certainly, if I do figure anything out, then I will share that with the world. But yes, part of this is putting it out there into the universe. And if the universe happens to send me back an answer, I will happily accept that. But yeah, again, I had two stories, and that was the one where I lost. I'm going to send it back over to you because I'm interested in anything else that's up in your world. And later, I'll tell the story of a victory.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: I have a victory that I can share as well, and I'm excited to hear about yours. So to share a bit more context about the project that I'm on, we are focused very heavily on improving their test suite, not only the time that it takes to run the test suite but predominantly addressing a lot of the flaky tests that they have. Because that is a huge pain point for the team and often leads to the team having to rerun tests.

+ +

And so, there are a couple of areas that we're very excited to make some contributions. The first part is that we are just looking at those flaky tests to figure out what is going on and how can we address these? And one of the nice things, one of the tools that they're using TeamCity is the tooling that they're using to run their automated test suite.

+ +

And TeamCity will let you mute tests, so then that way, if you do encounter a flaky test, you can mute it. So then, at least it's not impacting other people. I say this with some asterisks that go along with it because, for people who can't see, Chris is making a very interesting face. I think you have thoughts on this.

+ +

And the other thing that they will show is a flip rate for the flaky tests, which is really nice, too, because then you can see which tests are flaky the most. So then that helps us prioritize which ones we want to look into. All right, I'm going to pause so you can respond to that comment I made about muting tests.

+ +

CHRIS: I'm intrigued. I talked in a recent episode about adding RSpec::Retry. So the idea of flakiness being a thing that exists and trying to decide how much engineering effort to apply to fixing it. But the idea of muting it and especially muting it in the UI, not in the test suite or not having that be something that's committed, there's something about that that caught my attention, and thus apparently, my eyebrows raised. You saw that. [laughs]

+ +

But I don't actually know how I feel about it. This is such a complicated, murky area that I wish I had a stronger set of beliefs around. It was interesting when we talked about the RSpec::Retry thing. I think you rightly pushed back on me, and you were like, that's interesting, maybe don't do that. And I was like, that's a fair point. [laughs] And so now hearing you're in the quagmire of flaky tests, and yeah, it's an interesting space.

+ +

STEPH: Well, I think my hard belief is that muting tests is a thing that we shouldn't do. It's going to lead to more problems, and you're not really addressing the issue that you have. It is a temporary solution to a much bigger problem that you have. And so it is a tool that you can use to then buy you some more time.

+ +

And so that is the space that this team is in where they have used this particular tool to buy them more time and to be able to keep shipping changes while realizing that they do still need to address these underlying issues. So it is a tricky space to be in where essentially, you've gotten to the point that you do have these muted tests. It is a way to help you keep going forward, but you are going to have to come back to it at some point.

+ +

And so that's the space that I'm in right now joining the team is that we have been brought in to help some of their engineers specifically address this issue while ideally letting the rest of the team continue to focus on shipping changes while we address the test. Although I really think there's going to be two angles that we've talked about in how we're going to help this particular codebase.

+ +

One of them is that we are going to address a flaky test. But the other one is empowering people that they feel like they have the time and the knowledge that they can address a flaky test and also not contribute more flaky tests to the codebase. But I appreciate that you called me on that a bit because we've had those conversations around when we should actually address something versus muted, all the interesting trade-offs that come along with that conversation.

+ +

So this particular flaky test that we addressed earlier this week is specific to hard coding primary IDs. The short version is that it's bad, don't do it. The longer version is that they were having a test that was failing intermittently because it would pass the first two runs, but then it would start to fail for all future runs.

+ +

And the reason it would pass for the first two runs is because when they were setting the ID for a record that the test setup is creating, they were looking for existing records and saying, "Hey, what's your latest ID?" And then I'm going to guess the next ID. I'm going to add one to that to figure out what the next ID should be.

+ +

Some additional context, when the tests boot up, there's some data that's being created before the test run. So then that's why they're checking to see, okay, what records already exist? And then let's add one to that. The reason that fails sometimes is because then once the tests have run, the Postgres IDs aren't being reset, so they're using a truncate approach. So then, when the test runs once or twice, that works. But then, at some point, there's a collision between those IDs where they tried to guess the next ID, but then Postgres is also on that same ID, and it ends up failing.

+ +

There are also some callbacks. There's some trickery afoot. It took a little while [chuckles] to work through these tests to understand why they're failing. But the short version is that we thought we had to restructure the data in a way that no longer required us to guess what the next primary key should be for a record.

+ +

We could actually use Factory Bot to generate that record, and then ask Postgres, okay, what ID did you assign? And we're going to pass that in. And that part was really challenging when you're in a new codebase, and you are learning the domain knowledge and exactly how data should be structured. So that was one challenge of it.

+ +

The other part was that a lot of the data relies on each other. So then figuring out the right hierarchy in which we could create the data. So we didn't have a circular reference at some point. It took some time. And Joël Quenneville, who's on the project with me, used a tool that I found very helpful. It's called Dataviz. He went through and documented the let statements, the data that's being created, and then it generated a nice tree structure that shows you okay; these are your dependencies. This is the test setup that you're using.

+ +

And then from there, just by changing a few lines in that particular file that used to generate that Dataviz tree, he would move it around. And we could simulate what we were already mentally trying to construct in our head. So as programmers, we're already thinking, okay, I know this record needs that data. And that data needs that data before I can build this. But this actually turned it into a concrete visualization where we could see it.

+ +

And I was really struggling. And he was like, "Hey, I got it into a visual form that we can look at. And there's a circular reference. That's why this keeps happening and why we're not making progress." So then, using that, we were able to then reformat some of the dependencies, look at the graph, see that we didn't have that circular reference anymore. And then we could implement that in code.

+ +

And it really helped me to be able to walk through that visual aspect because then I could say, okay, this is all the stuff that I'm trying to mentally hold on to, but instead, I can just look at this and know it's going to work. I don't have a circular reference. It also helped concretely show why the previous efforts were failing and why we kept running into some issues.

+ +

So I'm really interested now in Dataviz because I found it very helpful in this particular case. And I'm very intrigued to see if I can apply this to more tests that I'm trying to fix and to see if I can start out with here's the current structure. Here's where I'm trying to go. And then essentially build that graph first before I start changing the code around. I would love to have that optimization. And I feel like it would speed up the process.

+ +

CHRIS: It was funny as you started to say that I had observed some tweets going out into the world recently. And I was like, this is Joël. This is definitely Joël talking about these things. As an aside, for anyone who doesn't follow Joël Quenneville on Twitter, @joelquen, I would highly recommend it. We can include a link to Joël's Twitter in the show notes. Joël is one of the clearest thinkers and communicators about programming that I have ever worked with.

+ +

And in particular, what you're describing of the data visualization is something that I think he does incredibly well. Often he'll make blog posts, but they'll include just simple little visualizations, little images, or diagrams, or flowcharts that just so concretely encapsulate an idea and express it so much better than text ever could.

+ +

And so, in so many ways, I look to Joël's writing, both on Twitter, in the blog, in many places. And I just appreciate so much what he puts out there and the manner in which he does it. So I was by no means surprised when you said, "Oh, and I'm working with Joël on this project." I was like, yes, I bet you are. That sounds true, and in particular, some of the conversations about flaky tests and determinism and all of that.

+ +

So yeah, the visualization stuff is also particularly interesting in taking a system that it's very hard to hold all of this in our heads. But that visualization, the tree and/or graph thing at play, having that in a picture and being like, oh, look, there's a cycle now. There we go. Can't have those. That's not okay. That's a really interesting solution that's just very cool to hear about and presumably led to a good outcome where you were able to break that cycle. And now you're happy and deterministic in your tests.

+ +

STEPH: Yeah, it's one of those approaches where I wonder if it was helpful afterwards and how can I make it helpful beforehand? Because it felt like a confirmation of the pain in the process that we had been through. And I'm eager to see if now I can apply it ahead of time and save myself some of that pain. That's where I get really excited. But yes, it was a successful outcome. And we have fixed that particular flaky test. But I'm very excited to hear about your victory from the week.

+ +

CHRIS: It's a shared victory. It was a team victory, just to be clear. But we are working in a system that is using Inertia. Inertia.js is a project that I've talked about a number of times on the show. I'm a huge fan of it. It is the core architecture of how we're building our application.

+ +

But as a very brief revisiting of what it is, on the server-side, we have Rails, and Rails is acting in a pretty traditional way. We do not have an API. And on the front end, we have Svelte, which is a JavaScript view layer framework. Inertia sits between them and binds the traditional Rails MVC architecture and the Svelte front end.

+ +

So again, there's no API in the traditional sense of this is a REST endpoint, and we hit it, and we get some data, and then the front end holds on to that in a store. None of that is going on. Inertia does a wonderful job of marrying these two concepts and allowing us to use familiar programming techniques on the server-side but then also have a more future-friendly front end.

+ +

Animations and transitions and things like that are now totally possible while not throwing away the entirety of our programming model that we've had in Rails server-side applications. That's all well and good. Almost all of the UI in our application is rendered via Inertia and Svelte. That's great. We love it.

+ +

The one caveat is Devise. So we have Devise on this project, and Devise comes with a lot of views built-in. And we have both an admin and a user model. So we have sign in and sign up, and confirm registration, and forgot password and all of these different views and flows and things that Devise just gives you out of the box. And being an early-stage startup, it was not a good time to revisit any of that or to try and build it from scratch or any of that. We just wanted to build on the good known trusted foundation that Devise gives us.

+ +

But the trade-off there is that now all of our Devise logic lives in this uncanny valley. It's the only stuff that is in ERB views. Our styling, thankfully, we're using Tailwind, and so we are able to have some consistency between the styling.

+ +

But recently, we redesigned the flash messages on the client-side in our Svelte pages. But on the server-side, they are a little on the Devise-side because Devise is the only pages that are being rendered truly server-side. They look a little different. And this is a pain that we felt, that inconsistency or that mismatch between the Devise views. And then the rest of the application is a pain that we felt but one that we consistently were like, I don't think it's worth the effort to try and change this.

+ +

Finally, this week, we've been doing a lot of work on our user onboarding funnel. So the initial signup flow going through it's a progressive form screen where you go in between different pages. And a majority of it is implemented in the Inertia and Svelte side of things. And it's very nice and very fun to work with. But the signup form, the user signup form, is in Devise, and it's a traditional Rails server-rendered post, and then all the normal stuff happens.

+ +

We finally decided to bite the bullet this week and see how painful it would be to port that over to Inertia and Svelte. And spoiler, it was awesome. It was very straightforward, and coming out of it, immediately, the page was largely the same. The server-side code was largely the same.

+ +

But now we had things like when you submit this form, if there's a validation error, we don't clear out your passwords because we're staying on that page on the client-side. We're taking advantage of the way Inertia's error flow works. That's a subtlety of how Inertia works. That's probably more detail than we want to get into here, but it's an awesome thing that works and is great.

+ +

And so immediately, this page just got better. We got inline errors for each of the fields. We were able to very easily add a library called Mailcheck, which I've talked about on an episode a while back. But this is a thing where if you have a typo in your email address, we can say, "Hey, you have a typo in your email address. And if you click this link where we suggest the alternative, we'll just replace it inline."

+ +

That would have been really awkward to wire up in our Devise view. It would have been some jQuery-esque script tag at the bottom of the view page that doesn't stop…We don't have jQuery actually at this point. We wouldn't have jQuery. And we could certainly, but it would only be for that view. And it would be weird and different in a fundamentally different programming model. It was trivial to do in the Inertia and Svelte world once we had made that port over.

+ +

This was always my hope. This was the dream that I had in mind. And it speaks to the architecture of Inertia. And Inertia is a really great abstraction that is very minimally leaky. I won't say it has zero leaks because no abstraction does. But this was my hope is I think the server-side should mostly stay the same. And I think the client-side, we just take an ERB template, turn it into a Svelte template, and we're good to go. And that has largely been the case.

+ +

But suddenly, this page is so much more. There are subtle animations as things come in. And there are just lots of nice features that were trivial to add now and that fit with the rest of the programming model that we have throughout it. So that was awesome.

+ +

STEPH: That is awesome. I love these styles of updates where there's like, oh, I had a loss this week. But I also had this really great win because that feels just so representative of a typical week. So I love this back and forth.

+ +

CHRIS: It's also that sequence is how the week went. So the loss happened earlier in the week, and then the win happened later in the week, which is how I would prefer it because now I'm going into the weekend with a win. Like, cool, I'll take it. Had it gone in the other direction, I would have been like, oh man, Rails beat me. But I guess it's the weekend now. I'll forget about it for a little while.

+ +

STEPH: Yeah, that definitely helps to end on a positive note.

+ +

CHRIS: But yeah, I don't think too much more to say about that beyond it was both really nice to get the added functionality to get the better, more user-friendly behavior in this view that naturally falls out of this programming model. But also to have that reinforcement of my belief in Inertia as a good architecture.

+ +

Not only did we get some really nice stuff out of doing this port, but it was also pretty straightforward because Inertia sits so comfortably between the pieces. And that's a story that I really like. I want more of that in my programming world, where to change this thing requires changing everything in our app. Oh no, this is sad. No, this was a great example of we were able to very minimally change things and get a much better experience out of it. So once again, I am very pro Inertia.js

+ +

STEPH: It's interesting to me how different our paths have been this year where I have been working on applications that are brought on thoughtbot to then help out with some of the concerns that they have, either their application is going down, or they have a test suite that they need to improve, or there's a lot of triage that's involved.

+ +

And so it makes me very excited to hear that, when you are building stuff, and it's going really well and how awesome that is. Because then I feel like most of my world has definitely been more in the triage space, which is a very interesting and fun space to be. But it brings me a lot of joy to hear about wins from let's build new stuff and hearing it be built from the ground up and how well that's going.

+ +

CHRIS: Well, I'm definitely happy to provide that. But also, I want to be realistic and be like, I’m just writing next year's legacy code right now, let's be honest. I'm very happy with where we're at in this moment. But I also know how early I am in the project that I'm working on.

+ +

And I'm burdened with the knowledge that I'm certain one decision that I'm making of the many that are being made I will deeply regret a year from now. I just know that that's true, and I can't let it slow me down. I got to just keep making decisions and do stuff. But I know that there's going to be one. I know that a year from now, I'm going to be like, why did we choose that option? But it's sort of the game.

+ +

STEPH: [singing] We'll just know that there's something strange and your code won't change. Who are you gonna call? thoughtboters!

+ +

CHRIS: Well, yes. I will definitely be calling you when I find myself in the uncertain times of legacy code of my own creation. So I look forward to that, frankly. But that's a problem for a year; I don't know, maybe two years from now. Who knows? But for now, what do you think? Let's wrap up.

+ +

STEPH: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it really helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter, and I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph started a new project and shares details about the new tools she's using, including working on a remote dev environment. Chris shares a journey with Lograge and Rails flash messages as he strives to capture user-facing errors.

+ +

They also discuss "silencing" flaky tests, using Graphviz to visualize data dependencies, and porting Devise views to use Inertia and Svelte. It's also interesting how different their paths have been this year!

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: Tech talk nonsense and songs, that's what people come to The Bike Shed for, variations on the Jurassic Park theme song, you know, normal stuff.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Let's see. So I've started a new project. So frankly, there's a ton of new stuff in my world. And I've been on the project for about a week and a half now. I started over the holiday, and it's been going really well. Still in that whole early stage with getting to know the application, the codebase, the processes, the team, all the dynamics.

+ +

It's a large company. So I'm working with a small group of individuals, but there are about over 100 developers that work at this company. And they do have a lot of documentation, which has been very helpful. But there's a lot to learn in terms of setup and processes, specifically.

+ +

So they have provided a laptop that I'm using to access their codebase. So I'm using their laptop. And then, I am also using a dev machine, a remote dev machine, that they have set up for me. So I need to be on their VPN and SSH into that dev machine. So that's novel as well.

+ +

CHRIS: Ooh, I'm very intrigued by that bit, not that they gave you a laptop bit but the dev machine. This is in the cloud sort of thing? What is this? I'm very intrigued.

+ +

STEPH: I don't know if I have concrete answers for you. But yes, for me to be able to access their codebase, I have to go into the dev machine. And then that's where then I can do my normal development work.

+ +

CHRIS: So is this like an EC2 instance or something like that that you're SSH-ing into, and then you can run processes on it? Or is it closer to the GitHub dev containers thing that they just released? Or are you running with your local Vim? Is it a remote Vim? Are you using Vim? Is it VS Code? I have so many questions.

+ +

STEPH: [laughs] I think it's more like the first version, although I don't know the backbone of it. I don't know specifically if it's an EC2 instance or exactly how it's being hosted and how I have access to it. But I did have to set everything up on it.

+ +

So they started the dev machine up for me. Their DevOps team started an environment where then I could access, and then I did need to cultivate it to my own habits. So I had to install several things. I had to install Brew and Vim and also the tmux and all those configurations that I'd really like to have.

+ +

They do have a really nice Confluence document that walks you through how to set up a connection between VS Code and the remote environment. So then that way, you can really just hang out in VS Code all day. And initially, I was like, okay, I could do this. And immediately, I was like, no, I love Vim. I'm going back to it even if I have to spend the 20, 30 minutes setting it up.

+ +

I'm so comfortable with Vim and tmux that I stuck to my roots, and I didn't branch out into VS Code. But I think VS Code is one of the more popular tools that they're using. So that way, it feels more local versus having to work in a remote machine. I think I answered some of your questions. I don't think I answered all of them.

+ +

CHRIS: Yes. I think you did answer all the questions. But just for clarification, the Vim and tmux and whatnot setup is that you're running SSH, and then on the remote machine, you are using Vim and tmux? Or is it a local Vim that is doing…I think Vim has some remote editing capabilities but not anywhere near what VS Code can do.

+ +

STEPH: It's the first setup. So I am SSH-ed in. And then I have Vim and tmux running on that remote machine.

+ +

CHRIS: Gotcha. Novel.

+ +

STEPH: Yeah, it's a thing. It's working. So that's good. And it feels cozy. I feel like I'm at home. I feel like I can be productive. So that's great as well. Some of the other tools that I'm also new to, so they use Zeus, which is used to then speed up the booting of your application. And you can also use it for speeding up test runs. So very similar to Spring, which I think we've had some discussions about Spring and who loves it and who doesn't. [laughs]

+ +

CHRIS: I don't know. I'm not...[chuckles] I feel like I remember Zeus. But Zeus is like three iterations ago of this preloader thing. I'm intrigued by that. I thought Spring had fully supplanted it in the Rails ecosystem but maybe not.

+ +

STEPH: So this company has been around for a very long time. So there are a number of tools that I think they're using because that was the tool to use the day when they got started. And then it just hasn't been a need to move on to one of the newer tools to use Spring. So at least that's my current explanation for why we're using Zeus. And also, Zeus works most of the time. I'm frankly still getting comfortable with it. [laughs] I still have gripes about Spring too.

+ +

CHRIS: 60% of the time, they work most of the time.

+ +

STEPH: [laughs] So, Zeus is another new tool that I'm adding to my tool belt during this engagement. Another new tool that I'm using is Gerrit. And so they use Gerrit…it is used for managing their Git repositories. It is used for code reviews. And being as accustomed and familiar with GitHub as I am, that one has been a little tricky to then navigate and change the whole UI that I'm used to when it comes to pushing up code, reviewing code, asking for feedback on changes.

+ +

And at one point, I was reviewing a change request for someone else. And there's a button on there where I was adding comments, but they were in draft mode. And I'm trying to figure out how to get them out of draft mode so that they're actually submitted, and the other person could see it. And I saw a submit button. I was like, cool. So I hit the submit button. And then it said something in red text about ready to be merged into main. [laughs] I was like, oh, no, I mean, maybe, but that's not what I meant to do.

+ +

So I had to reach out to that person and be like, "Hey, I'm new to Gerrit. I don't know what I did. I hit a button. I hope everything's fine. Here's my review. Best of luck. [laughs] I think everything is fine. Nothing dramatic came out of it. But I had my own little dramatic moment.

+ +

CHRIS: Wow, that is a bunch of new stuff. It's interesting. On the one hand, I totally understand projects get started, and there's a certain set of tools that are current at that point, and so then you're using them. And then, over time, it takes a very active effort to try and keep up with the new current, that new-new as we call it.

+ +

But the trade-off there is really interesting because, at any given time, it never feels like the right investment to pursue the new thing to just upgrade for upgrading sake. But then the counterpoint is the cost to someone like you coming onto the project. And it's like, it's a bunch of new stuff. It's kind of old stuff. It's new for me, but it is old, and less documented, and less familiar. And it's also certainly less compatible with other things that are going on, almost certainly.

+ +

And so, how to stay on top of those updates is always the thing that's really intriguing to me. I say as someone who started a project recently, and I have not thought about upgrading anything at this point. And we have bundler-audit I want to say is the one thing that we have in there. So if there's a CVE for a gem, then security-wise, we will be upgrading those. But otherwise, I haven't thought about upgrading our Ruby version or anything. And I think we're on 2.6 or something like that, which is a couple back at this point. And so it's something that's in the back of my mind.

+ +

I feel like I should have a formal answer to this. Like, company-wide, how do we think about the process of upgrading? And Dependabot and things like that answers some of it, but that doesn't tell me when to upgrade Ruby, I don't think. It could. That would be annoying. I don't want that. But it's one of those many things that depends and is subtle. And you have to decide where you put the trade-offs and whatnot. So just an interesting thing. And to observe you now going into this project building and being like, there's a bunch of new stuff.

+ +

STEPH: I think it really takes passion or pain. Those are the two things that then prompt us to upgrade. Either it's pain, and you need to change it to get rid of that, or it's passion. So you're really excited about the next version of Ruby or the next version of Rails. And I think that's fine. I think that's fine that those are often our drivers. But yeah, that is interesting. I hadn't really thought about that in terms of there's often no real strict process around when we upgrade except those are then the natural human catalyst.

+ +

CHRIS: I think you're right that those are the catalysts. But I think quite often those cannot be sufficient to push us to do the work. And so what do you do in the absence of that? It's not really painful. And I'm not really passionate about it. But I probably should do it is the 80% of the time middle space that we live in. And so yeah, I don't have an answer to it. I'm more observing the question. But like so many other things, I feel like often we just exist in that awkward middle and got to find a way through, so how like life.

+ +

STEPH: I was having a conversation with someone earlier a bit about these life cycles that we live in. Specifically, we were talking about consulting and how changing from project to project is so daunting. Because you go from I'm accustomed to this project, I'm accustomed to the team. And then all of a sudden you jump into this new project and with all these new things it can be really interesting.

+ +

But then there's also this feeling of like, wait, I used to be smart, and I knew everything that was going on. And the team knew me, and I knew all the team processes, and I felt good. And now I'm in this totally new space, and I have to relearn, and I have to reprove myself and relearn all the company politics.

+ +

And there's always that initial jumping from a sure space over to a very new space that always makes me then question and be like, yeah, I can do this, right? I can do this. And then I have to keep letting that voice build until about two weeks in. And I'm like, oh okay, I'm back in a good spot. I said two weeks; it's probably more like four.

+ +

But there's still that grace period of a new project where you're leveling up on all the things and learning the new team. And as daunting as it is; apparently, it's what I like. Apparently, I like that roller coaster ride that comes from jumping from one project to the next. So on that note of a bit of novel insight into myself, what's new in your world?

+ +

CHRIS: What is new in my world? Let's see. I think I've got two updates, two anecdotes to share. One, I lost the battle, one I won the battle. So we'll go with the lost battle first because that seems fun. So we have Lograge on this application, which Lograge, for anyone that's not familiar, is a library that helps with producing more structured and more complete log lines from a Rails application.

+ +

You can tell it to do JSON log lines, which is useful for many of the tools that will receive your logs. And then with it, you can say grab me the controller name and the params but sanitized and this and that. And so, you aggregate a bunch more data than would traditionally be in the logs. In general, I've just found it to be a much better foundation. I find the logs to be more readable, and more informative, more useful, all those lovely things.

+ +

But slowly, I've been looking at what's the other stuff that I want to have in here? What else would be nice to know? So one example is we use Inertia on this project. And Inertia has a particular way in which errors get mapped back to the front end. And it's an interesting little trick that involves the session, but that's sort of an aside. Basically, this is something that the user will see that I would love to know about. So how many users are hitting their head against the wall?

+ +

Because typically, whenever these errors happen, that means this is a flash message or something like that we're going to show to the user. So we were able to add that into our log lines. Now we can see those. We can aggregate on them. We can do counts. We can do alerting and monitoring, all those kinds of fun things. So cool. That was great. That worked well.

+ +

I then specifically…I mentioned the flash a second ago, but that's actually not…the Inertia messages will not show up in the flash. They end up in forms inline on certain inputs or whatnot. But we do also use the flash message pretty regularly as a way to communicate to the user success or failure or what have you. And I really wanted to get those into the logs. And I tried very hard, and I failed. I gave up. I threw in the towel. I raised the white flag.

+ +

So the nature of the flash, which is something that knew in the back of my mind but I had never really experienced as pointedly as this, is the flash is a magic value within the Rails ecosystem that can be written to and then once read clears itself. That's the nature of how the flash is supposed to work. And it persists across requests. So it's doing some fun stuff there, which I assume is tunneling through the session or maybe putting it into a cookie. I'm not actually sure.

+ +

But there's some way that you post to an endpoint, and then you get redirected to the show page. And on the show page, we actually display that flash value. But the flash is set on the controller endpoint that is handling the POST request. So this value spans across two request-response life cycles, which is interesting.

+ +

And so the manner in which that works is Rails is managing that on our behalf. We write to it on the one side. And then, when we do the subsequent requests, if there's a value in the flash, we show it to the user, which is why occasionally you'll see those weird things where that flash message shouldn't show up. But it's like a sticky value that was left in the system that didn't get cleared via one thing or another.

+ +

But I really wanted to put those into the logs. Like, what are we saying to the user is the thing I want to know. This is that question of like, what's my system doing at runtime? I understand what it's doing. I can read the code and understand what should happen. But what actually happened? Are users seeing this flash message way more than they should? That's a question I want to be able to answer.

+ +

And I have lost the battle. I cannot find a way to read the flash value, put it into my loglines, but then also have it persist through. The first attempt I did, I was able to get it into my loglines, but then it didn't show to the user, which is a bad outcome. Because now I've read the value, Rails clears it, cool, that's fine.

+ +

There is a flash.keep method. And that I thought would do the thing I wanted, which is like, oh, I want to read this value. I want to tap this value, I want to observe it, I want to peek at it. And I thought this keep method would do the thing that I wanted. It did not. It just caused the flash to be persistent. So now, anywhere I went had the same flash message for forever, which was not the behavior that I was looking for.

+ +

I then tried, like, all right, just for exploration purposes, what if I reach inside and read the instance variables of the flash objects? Also did not work. Everything I tried did not work. And it had these fun failure modes that just made me very sad. Thankfully, we had feature specs that told me about this failure mode because I would not have known about it otherwise. This was not obvious to me on first implementation. But yeah, I lost, and I feel sad.

+ +

And then I did the thing that we do, which is I searched Google, and there's nothing. I cannot find…This is one of those cases where like, I can't be the first person who wants to know what's in the flash. I can't be breaking new ground here. And yet I couldn't find anything on the internet. So that's where I'm at.

+ +

STEPH: That's interesting. Yeah, I'm trying to think…I think I'm one of those people. I don't think I've ever tried to peek into the flash and see what's there ahead of time. And it makes me wonder if it's partially…so we can't peek into the flash. You've exhausted several examples or tries there.

+ +

When you're setting the value of the flash, it makes me wonder if there's an order of operations that you have to pursue. So before you set the flash, you know what messages that you're going to share. So you send that off to the logs, but then also share that to the flash. So instead of writing the message directly to the flash and then having to check the flash, if you just stored that value elsewhere and shared it to the logs first. Is that a reasonable approach?

+ +

CHRIS: It definitely could work. But that was in the space of this is getting weird enough. I thought about things like that, but I didn't want to do anything weird. And part of the benefit that I get from using Lograge is rather than having multiple lines for each request…so a request came in and rendered this partial and did this thing. It gets constructed such that there's a single logline, which is one big JSON object that contains all of the data about that request.

+ +

And I really liked that structure because then everything's correlated like, oh, did we 404, or did we 302? And what was the message that we said to the user? And what were the params? It's all there in one line. I found that to be really useful. So I wanted to do that. I could just separately log it. But then I'm also worried of there is a statefulness there. Because again, the flash is written on one side and read on the…it's like a Hail Mary to ourselves between requests. Look at me with a sports reference.

+ +

And so, I didn't want to try anything out of the ordinary. I really just wanted to find a way to just like; I just want to read this value but not like Heisenberg uncertainty principle observing changes in the system. I found myself in that space, and I was like, can't there be a way that I can just flash.peek? And I just want to take a quick look. I don't want to mess with anything. You do your normal thing, flash. Just let me know. And I do not have an answer for it yet.

+ +

And for now, this is one of those nice to have, not an absolute requirement. So I wasn't yet in the position of okay, fine, let's do some out-of-the-box ideas here. So I'm still in the in the box phase, I would say, but who knows? Maybe down the road, I'll be like; I would really love to know what the flash message was for that request because this user is seeing stuff that we do not understand. And that information would tell us the answer. So we're not there yet. But I was surprised by how thoroughly I was defeated by Rails and the flash message on this adventure.

+ +

STEPH: I am equally surprised. I wouldn't have thought that particular achievement would have or is proving to be that hard or, frankly, not doable. So yeah, I'm intrigued to see if anybody has thoughts on it or if you do find a different solution because Lograge is one that I haven't used. But I would be surprised if other people haven't had a similar request of like; I want to be able to store what's in the flash message. Because like you said, that seems super helpful.

+ +

CHRIS: Well, certainly, if I do figure anything out, then I will share that with the world. But yes, part of this is putting it out there into the universe. And if the universe happens to send me back an answer, I will happily accept that. But yeah, again, I had two stories, and that was the one where I lost. I'm going to send it back over to you because I'm interested in anything else that's up in your world. And later, I'll tell the story of a victory.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: I have a victory that I can share as well, and I'm excited to hear about yours. So to share a bit more context about the project that I'm on, we are focused very heavily on improving their test suite, not only the time that it takes to run the test suite but predominantly addressing a lot of the flaky tests that they have. Because that is a huge pain point for the team and often leads to the team having to rerun tests.

+ +

And so, there are a couple of areas that we're very excited to make some contributions. The first part is that we are just looking at those flaky tests to figure out what is going on and how can we address these? And one of the nice things, one of the tools that they're using TeamCity is the tooling that they're using to run their automated test suite.

+ +

And TeamCity will let you mute tests, so then that way, if you do encounter a flaky test, you can mute it. So then, at least it's not impacting other people. I say this with some asterisks that go along with it because, for people who can't see, Chris is making a very interesting face. I think you have thoughts on this.

+ +

And the other thing that they will show is a flip rate for the flaky tests, which is really nice, too, because then you can see which tests are flaky the most. So then that helps us prioritize which ones we want to look into. All right, I'm going to pause so you can respond to that comment I made about muting tests.

+ +

CHRIS: I'm intrigued. I talked in a recent episode about adding RSpec::Retry. So the idea of flakiness being a thing that exists and trying to decide how much engineering effort to apply to fixing it. But the idea of muting it and especially muting it in the UI, not in the test suite or not having that be something that's committed, there's something about that that caught my attention, and thus apparently, my eyebrows raised. You saw that. [laughs]

+ +

But I don't actually know how I feel about it. This is such a complicated, murky area that I wish I had a stronger set of beliefs around. It was interesting when we talked about the RSpec::Retry thing. I think you rightly pushed back on me, and you were like, that's interesting, maybe don't do that. And I was like, that's a fair point. [laughs] And so now hearing you're in the quagmire of flaky tests, and yeah, it's an interesting space.

+ +

STEPH: Well, I think my hard belief is that muting tests is a thing that we shouldn't do. It's going to lead to more problems, and you're not really addressing the issue that you have. It is a temporary solution to a much bigger problem that you have. And so it is a tool that you can use to then buy you some more time.

+ +

And so that is the space that this team is in where they have used this particular tool to buy them more time and to be able to keep shipping changes while realizing that they do still need to address these underlying issues. So it is a tricky space to be in where essentially, you've gotten to the point that you do have these muted tests. It is a way to help you keep going forward, but you are going to have to come back to it at some point.

+ +

And so that's the space that I'm in right now joining the team is that we have been brought in to help some of their engineers specifically address this issue while ideally letting the rest of the team continue to focus on shipping changes while we address the test. Although I really think there's going to be two angles that we've talked about in how we're going to help this particular codebase.

+ +

One of them is that we are going to address a flaky test. But the other one is empowering people that they feel like they have the time and the knowledge that they can address a flaky test and also not contribute more flaky tests to the codebase. But I appreciate that you called me on that a bit because we've had those conversations around when we should actually address something versus muted, all the interesting trade-offs that come along with that conversation.

+ +

So this particular flaky test that we addressed earlier this week is specific to hard coding primary IDs. The short version is that it's bad, don't do it. The longer version is that they were having a test that was failing intermittently because it would pass the first two runs, but then it would start to fail for all future runs.

+ +

And the reason it would pass for the first two runs is because when they were setting the ID for a record that the test setup is creating, they were looking for existing records and saying, "Hey, what's your latest ID?" And then I'm going to guess the next ID. I'm going to add one to that to figure out what the next ID should be.

+ +

Some additional context, when the tests boot up, there's some data that's being created before the test run. So then that's why they're checking to see, okay, what records already exist? And then let's add one to that. The reason that fails sometimes is because then once the tests have run, the Postgres IDs aren't being reset, so they're using a truncate approach. So then, when the test runs once or twice, that works. But then, at some point, there's a collision between those IDs where they tried to guess the next ID, but then Postgres is also on that same ID, and it ends up failing.

+ +

There are also some callbacks. There's some trickery afoot. It took a little while [chuckles] to work through these tests to understand why they're failing. But the short version is that we thought we had to restructure the data in a way that no longer required us to guess what the next primary key should be for a record.

+ +

We could actually use Factory Bot to generate that record, and then ask Postgres, okay, what ID did you assign? And we're going to pass that in. And that part was really challenging when you're in a new codebase, and you are learning the domain knowledge and exactly how data should be structured. So that was one challenge of it.

+ +

The other part was that a lot of the data relies on each other. So then figuring out the right hierarchy in which we could create the data. So we didn't have a circular reference at some point. It took some time. And Joël Quenneville, who's on the project with me, used a tool that I found very helpful. It's called Dataviz. He went through and documented the let statements, the data that's being created, and then it generated a nice tree structure that shows you okay; these are your dependencies. This is the test setup that you're using.

+ +

And then from there, just by changing a few lines in that particular file that used to generate that Dataviz tree, he would move it around. And we could simulate what we were already mentally trying to construct in our head. So as programmers, we're already thinking, okay, I know this record needs that data. And that data needs that data before I can build this. But this actually turned it into a concrete visualization where we could see it.

+ +

And I was really struggling. And he was like, "Hey, I got it into a visual form that we can look at. And there's a circular reference. That's why this keeps happening and why we're not making progress." So then, using that, we were able to then reformat some of the dependencies, look at the graph, see that we didn't have that circular reference anymore. And then we could implement that in code.

+ +

And it really helped me to be able to walk through that visual aspect because then I could say, okay, this is all the stuff that I'm trying to mentally hold on to, but instead, I can just look at this and know it's going to work. I don't have a circular reference. It also helped concretely show why the previous efforts were failing and why we kept running into some issues.

+ +

So I'm really interested now in Dataviz because I found it very helpful in this particular case. And I'm very intrigued to see if I can apply this to more tests that I'm trying to fix and to see if I can start out with here's the current structure. Here's where I'm trying to go. And then essentially build that graph first before I start changing the code around. I would love to have that optimization. And I feel like it would speed up the process.

+ +

CHRIS: It was funny as you started to say that I had observed some tweets going out into the world recently. And I was like, this is Joël. This is definitely Joël talking about these things. As an aside, for anyone who doesn't follow Joël Quenneville on Twitter, @joelquen, I would highly recommend it. We can include a link to Joël's Twitter in the show notes. Joël is one of the clearest thinkers and communicators about programming that I have ever worked with.

+ +

And in particular, what you're describing of the data visualization is something that I think he does incredibly well. Often he'll make blog posts, but they'll include just simple little visualizations, little images, or diagrams, or flowcharts that just so concretely encapsulate an idea and express it so much better than text ever could.

+ +

And so, in so many ways, I look to Joël's writing, both on Twitter, in the blog, in many places. And I just appreciate so much what he puts out there and the manner in which he does it. So I was by no means surprised when you said, "Oh, and I'm working with Joël on this project." I was like, yes, I bet you are. That sounds true, and in particular, some of the conversations about flaky tests and determinism and all of that.

+ +

So yeah, the visualization stuff is also particularly interesting in taking a system that it's very hard to hold all of this in our heads. But that visualization, the tree and/or graph thing at play, having that in a picture and being like, oh, look, there's a cycle now. There we go. Can't have those. That's not okay. That's a really interesting solution that's just very cool to hear about and presumably led to a good outcome where you were able to break that cycle. And now you're happy and deterministic in your tests.

+ +

STEPH: Yeah, it's one of those approaches where I wonder if it was helpful afterwards and how can I make it helpful beforehand? Because it felt like a confirmation of the pain in the process that we had been through. And I'm eager to see if now I can apply it ahead of time and save myself some of that pain. That's where I get really excited. But yes, it was a successful outcome. And we have fixed that particular flaky test. But I'm very excited to hear about your victory from the week.

+ +

CHRIS: It's a shared victory. It was a team victory, just to be clear. But we are working in a system that is using Inertia. Inertia.js is a project that I've talked about a number of times on the show. I'm a huge fan of it. It is the core architecture of how we're building our application.

+ +

But as a very brief revisiting of what it is, on the server-side, we have Rails, and Rails is acting in a pretty traditional way. We do not have an API. And on the front end, we have Svelte, which is a JavaScript view layer framework. Inertia sits between them and binds the traditional Rails MVC architecture and the Svelte front end.

+ +

So again, there's no API in the traditional sense of this is a REST endpoint, and we hit it, and we get some data, and then the front end holds on to that in a store. None of that is going on. Inertia does a wonderful job of marrying these two concepts and allowing us to use familiar programming techniques on the server-side but then also have a more future-friendly front end.

+ +

Animations and transitions and things like that are now totally possible while not throwing away the entirety of our programming model that we've had in Rails server-side applications. That's all well and good. Almost all of the UI in our application is rendered via Inertia and Svelte. That's great. We love it.

+ +

The one caveat is Devise. So we have Devise on this project, and Devise comes with a lot of views built-in. And we have both an admin and a user model. So we have sign in and sign up, and confirm registration, and forgot password and all of these different views and flows and things that Devise just gives you out of the box. And being an early-stage startup, it was not a good time to revisit any of that or to try and build it from scratch or any of that. We just wanted to build on the good known trusted foundation that Devise gives us.

+ +

But the trade-off there is that now all of our Devise logic lives in this uncanny valley. It's the only stuff that is in ERB views. Our styling, thankfully, we're using Tailwind, and so we are able to have some consistency between the styling.

+ +

But recently, we redesigned the flash messages on the client-side in our Svelte pages. But on the server-side, they are a little on the Devise-side because Devise is the only pages that are being rendered truly server-side. They look a little different. And this is a pain that we felt, that inconsistency or that mismatch between the Devise views. And then the rest of the application is a pain that we felt but one that we consistently were like, I don't think it's worth the effort to try and change this.

+ +

Finally, this week, we've been doing a lot of work on our user onboarding funnel. So the initial signup flow going through it's a progressive form screen where you go in between different pages. And a majority of it is implemented in the Inertia and Svelte side of things. And it's very nice and very fun to work with. But the signup form, the user signup form, is in Devise, and it's a traditional Rails server-rendered post, and then all the normal stuff happens.

+ +

We finally decided to bite the bullet this week and see how painful it would be to port that over to Inertia and Svelte. And spoiler, it was awesome. It was very straightforward, and coming out of it, immediately, the page was largely the same. The server-side code was largely the same.

+ +

But now we had things like when you submit this form, if there's a validation error, we don't clear out your passwords because we're staying on that page on the client-side. We're taking advantage of the way Inertia's error flow works. That's a subtlety of how Inertia works. That's probably more detail than we want to get into here, but it's an awesome thing that works and is great.

+ +

And so immediately, this page just got better. We got inline errors for each of the fields. We were able to very easily add a library called Mailcheck, which I've talked about on an episode a while back. But this is a thing where if you have a typo in your email address, we can say, "Hey, you have a typo in your email address. And if you click this link where we suggest the alternative, we'll just replace it inline."

+ +

That would have been really awkward to wire up in our Devise view. It would have been some jQuery-esque script tag at the bottom of the view page that doesn't stop…We don't have jQuery actually at this point. We wouldn't have jQuery. And we could certainly, but it would only be for that view. And it would be weird and different in a fundamentally different programming model. It was trivial to do in the Inertia and Svelte world once we had made that port over.

+ +

This was always my hope. This was the dream that I had in mind. And it speaks to the architecture of Inertia. And Inertia is a really great abstraction that is very minimally leaky. I won't say it has zero leaks because no abstraction does. But this was my hope is I think the server-side should mostly stay the same. And I think the client-side, we just take an ERB template, turn it into a Svelte template, and we're good to go. And that has largely been the case.

+ +

But suddenly, this page is so much more. There are subtle animations as things come in. And there are just lots of nice features that were trivial to add now and that fit with the rest of the programming model that we have throughout it. So that was awesome.

+ +

STEPH: That is awesome. I love these styles of updates where there's like, oh, I had a loss this week. But I also had this really great win because that feels just so representative of a typical week. So I love this back and forth.

+ +

CHRIS: It's also that sequence is how the week went. So the loss happened earlier in the week, and then the win happened later in the week, which is how I would prefer it because now I'm going into the weekend with a win. Like, cool, I'll take it. Had it gone in the other direction, I would have been like, oh man, Rails beat me. But I guess it's the weekend now. I'll forget about it for a little while.

+ +

STEPH: Yeah, that definitely helps to end on a positive note.

+ +

CHRIS: But yeah, I don't think too much more to say about that beyond it was both really nice to get the added functionality to get the better, more user-friendly behavior in this view that naturally falls out of this programming model. But also to have that reinforcement of my belief in Inertia as a good architecture.

+ +

Not only did we get some really nice stuff out of doing this port, but it was also pretty straightforward because Inertia sits so comfortably between the pieces. And that's a story that I really like. I want more of that in my programming world, where to change this thing requires changing everything in our app. Oh no, this is sad. No, this was a great example of we were able to very minimally change things and get a much better experience out of it. So once again, I am very pro Inertia.js

+ +

STEPH: It's interesting to me how different our paths have been this year where I have been working on applications that are brought on thoughtbot to then help out with some of the concerns that they have, either their application is going down, or they have a test suite that they need to improve, or there's a lot of triage that's involved.

+ +

And so it makes me very excited to hear that, when you are building stuff, and it's going really well and how awesome that is. Because then I feel like most of my world has definitely been more in the triage space, which is a very interesting and fun space to be. But it brings me a lot of joy to hear about wins from let's build new stuff and hearing it be built from the ground up and how well that's going.

+ +

CHRIS: Well, I'm definitely happy to provide that. But also, I want to be realistic and be like, I’m just writing next year's legacy code right now, let's be honest. I'm very happy with where we're at in this moment. But I also know how early I am in the project that I'm working on.

+ +

And I'm burdened with the knowledge that I'm certain one decision that I'm making of the many that are being made I will deeply regret a year from now. I just know that that's true, and I can't let it slow me down. I got to just keep making decisions and do stuff. But I know that there's going to be one. I know that a year from now, I'm going to be like, why did we choose that option? But it's sort of the game.

+ +

STEPH: [singing] We'll just know that there's something strange and your code won't change. Who are you gonna call? thoughtboters!

+ +

CHRIS: Well, yes. I will definitely be calling you when I find myself in the uncertain times of legacy code of my own creation. So I look forward to that, frankly. But that's a problem for a year; I don't know, maybe two years from now. Who knows? But for now, what do you think? Let's wrap up.

+ +

STEPH: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it really helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter, and I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NEwUw-0_ + + ]]> + + Chris Toomey + Steph Viccari + + + 318: Successful Skills with Edward Loveall + https://bikeshed.thoughtbot.com/318 + 5ba23253-fc0e-4d5b-b249-9533b057c99f + Tue, 07 Dec 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Fellow thoughtboter Edward Loveall joins Steph to cohost and talk about alternative frontends and his own that he created: scribe.rip: an alternative frontend to Medium, learning about what it's like to be a manager/non-IC, and helps answer a listener question re: how do you think about empathy in your work? + 44:05 + no + + + Fellow thoughtboter Edward Loveall joins Steph to cohost and talk about alternative frontends and his own that he created: scribe.rip: an alternative frontend to Medium, learning about what it's like to be a manager/non-IC, and helps answer a listener question re: how do you think about empathy in your work? +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Empathy Online: Edward Loveall (https://thoughtbot.com/blog/empathy-online) +Scribe (https://scribe.rip/) +GitHub - mendel5/alternative-front-ends: Overview of alternative open source front-ends for popular internet platforms (e.g. YouTube, Twitter, etc.) (https://github.com/mendel5/alternative-front-ends) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And this week, Chris is taking a quick break. But while he's away, we have a guest on today's show. Today's guest is fellow thoughtboter, and wonderful friend, and British accent enthusiast Edward Loveall. +EDWARD: Oh, hello, Steph. It is lovely to meet...No; this is not my real accent. Anyway, hi, friends. [chuckles] +STEPH: [laughs] Hello, British Edward. I am so excited to be chatting with you today. Are you going to maintain that accent throughout the whole episode? +EDWARD: No. There's no way I could do that. I need a lot more professional actor training to be able to maintain quality of that level, I think. +STEPH: That's fair. I won't hold you to that standard. I was reflecting on preparation for this chat. I've been thinking about all the fun that we've had together, the time that we have worked together at thoughtbot, all the remote coffee walks that we have gone on together as we've talked through consulting challenges or coding challenges. And I realized that we have never worked on a project together, which is wild to me. +EDWARD: Huh. Yeah, I think you're right. That is wild. Because I've been here three and a half years, and you've been here even longer than me. So in three and a half years of overlap, we've never done that. +STEPH: And yet we've still always found ways to hang out. +EDWARD: We make it a priority, you know. +STEPH: I think we need to...we might have to bribe somebody for us to get on a project together. +EDWARD: I'm pretty sure we know the person to bribe. +STEPH: We do. +EDWARD: We can go talk to our boss and make that happen. One thing we've both done in our career here at thoughtbot, too, is we have gone from individual contributor to being a manager, which is a cool transition. +STEPH: That's a really good point. That is fun that we have embarked on that journey together. I was very much encouraged to become a team lead, and that was very helpful. Because I'm the type of person where I'm not sure I would have put myself up for that role. I'm very thankful that others encouraged me to do so because I really love it. There are certainly challenges with being a team lead. But overall, I have very much enjoyed the role. +Just to provide some context for being a team lead a thoughtbot, because I feel like those management roles tend to differ from company to company as to the level of responsibilities that you have. So for us in particular, it's really focused on leading a team of developers, usually two to three developers, and conducting regular one-on-ones to ensure that they are fulfilled and are successful in their projects and their growth at thoughtbot. And then helping them become senior developers if they're not already and essentially coaching them through difficult development and consulting scenarios. +EDWARD: Yeah, there is still an expectation that you are an individual contributor in some form on client projects. It is not just a management position. +STEPH: Yeah, that's a good point. For me, that context switching is often what makes it challenging but yet also helps me still feel that I can coach somebody and that I can have one-on-ones because I am still in the trenches. I'm still contributing to client projects. And so, it really helps me still stay in touch with the work that's being done and the struggles that people will face. Let me say again I am positive I wouldn't have pursued this path if I lost my IC status. I really like that part of the role. That's really a split. How about you? +EDWARD: Yeah, and I still do. We've been experimenting. So thoughtbot generally does four days a week on many projects. So we do four days a week with our client, and then we do one day a week as investment. And team leads, at least on the team that we are on, have been experimenting with just doing three days a week on a client, one day dedicated towards team lead, and then one day for investment. I like that split so far. +We're still seeing how it goes, still pretty early on in that experiment. But I've enjoyed continuing to be in the trenches, as it were, and working sometimes with the people that report to me so that we can really grow in the same way. There's a lot of context shared there. And that's been really wonderful. +STEPH: Yeah, I have some specific questions I'd love to ask you about that shift in schedule. Because in some of our meetings, there has been discussion about that ability to context switch between I'm only billing three days now instead of my typical four. And I now have more time to focus on team lead priorities, but then that also means I lose a day with client work. And so there's that battle going back and forth between focusing on client work and also focusing on team lead work. So I'm going to leave that as just a teaser because I want to come back to that. +But I'd really love to circle back to earlier in the year when you were thinking about becoming a team lead and correct me if I'm wrong, but I think you were pretty hesitant about it. And you were still deciding if it was something you wanted to do. Do you recall what helped you make up your mind as to which path you wanted to take and why you chose this one? +EDWARD: Yeah, that's a great question. I did also get some encouragement, a pretty light encouragement from a previous co-worker. And that was helpful, but I turned it down initially. Someone asked, "Hey, are you interested in this?" And I said, "Nope, definitely not." And, I don't know, a year-ish later, I then ended up applying. +And I think what happened in the intervening year was that I started to naturally do some of the work of a team lead primarily, checking in with people and talking with them, pairing with them on things more regularly. So I felt as if I was already doing some of the work, not exactly running a one-on-one, not getting people promoted necessarily. But I cared about the people I was working with and wanted to see them grow and be happy and thrive. That realization helped me think, oh yeah, I'm just kind of doing this. And I should maybe apply for this role. +STEPH: Wow, that resonates so much. I've heard that from other folks, too, as they have progressed into team lead or other management roles is it was often they already felt like they had started doing some of the work, or there was some natural inclination to start taking over those activities. And so then it felt right to then actually acquire that title and take on those responsibilities officially. +Well, how's it been going? You had almost a year now. So you had some of those hesitations at the beginning. How's it been? What do you think of being a team lead? +EDWARD: Yeah, I'm really enjoying it. It is a challenge like you said. But that's every job, right? Every job should be a bit of a stretch. So I did come into it with some natural inclinations of wanting to talk to people and check in with them. But there are all these other pieces that I wasn't good at. One thing that has been really challenging is instead of completing things myself, being that individual contributor, is trying to coach and sponsor people to do something that I would do. +And I think the hardest part about that is they may not be as far along in their career as you are. And so it is hard to watch someone struggle in the way that you used to struggle without saying, "Oh, here, let me just do that for you.” And I think what I started to realize is that the efforts that I'm putting in I can really be a force multiplier and end up effecting more change than what I could do by myself. +Like, if you think about it, I have four reports right now, and they're all really smart and talented people. But let's just say they were half as good as I was. That is definitely not true but just go with the numbers here for a second. If I could teach them to do what I do, even if they were half as fast as me, because there are four of them, they can get two times the work done. +The math adds up in a way where if I can unblock those people, help them just get to the next one little step, do whatever it is that they need, they're going to do way more than I could by myself. And really wrapping your head around that and the advantages there is so hard but so rewarding once you figure it out and get it going. +STEPH: Do you feel like anybody told you that up front going into taking on some more management responsibilities? Or is that something you learned as you went? +EDWARD: I definitely learned that as I went. I got some great advice from Josh Clayton, who we work with, and he's been a manager for a long time. And that's a lot of how he thinks about it. And he encouraged me to do things like pairing with everybody on the team or running little workshops to teach, to fill in knowledge gaps for people asking questions, instead of giving answers, to help them find their own answer. And that's all been really, really helpful. +STEPH: Yeah, that's one of the things that I have valued very much about our culture. I've seen some other companies struggle with is that when someone does get elevated into a management role that they still need support. They still need to be coached. And they also need room to make mistakes and grow. +And at thoughtbot, I feel that we have been very supported and where there's someone that I can still get mentoring and coaching from. And I can learn to be a manager on the job versus I'm not just put in a position where I'm going to fail or just put there without the expectation that I still need to grow as a manager and as a person as well. So that has helped me out tremendously as well. +You highlighted the idea of pairing more with others and then asking more questions around providing answers. And as you're learning those skills or as you've acquired those skills for being a team lead at thoughtbot, have you found those skills also transition well to client work? +EDWARD: Yeah, they do. There's a lot of overlap, especially around gaining trust with somebody. I'm gaining trust in one-on-ones, but I'm also gaining trust with my client or helping my client understand something. This gets a little more into the client-side of it. But a lot of times in client work, I'm looking to bridge a gap. I understand something because of my consulting experience, and they want my knowledge and consulting experience. But it's hard to just go in and say, "Do X or do Y." +And in the same way, with somebody who's reporting to me or who we're having a one-on-one, it's not usually very helpful to just say, "Do this, do that." You want to help them understand the why and bridge that knowledge gap to get to where you want them to be and where you think they should be. Those really do go hand in hand, and I have used a lot of the same skills. +Giving feedback also has been a huge thing to share. It's really, really hard to give critical feedback to somebody. It's very easy for them to shut down and not take the feedback, which is the opposite of what you're trying to do. And the same can be with clients. Like, they've gotten to where they've gotten to because of whatever they've done in the past, and trying to show them why what some of the things they're doing is maybe not ideal is really tricky without triggering that flight or fight response. So yeah, there are lots and lots of crossover to answer your question. [chuckles] +STEPH: I get so excited when clients that have brought on thoughtboters recognize that we are there temporarily, that we bring an outsider perspective. And they will set up essentially reoccurring; maybe it's weekly, maybe it's monthly to say, "Hey, give us feedback. Let us know what are you seeing? What do you think about the team? What do you think about our processes? What would you like to change?" +And I don't mean just in a retro setting that you're having with the team, but it may be meeting with leadership of that company to give them that feedback directly. And that's awesome. It's rare because, I mean, that takes confidence on their part to be able to say, "Hey, give us all of your feedback, constructive, positive, whatever it may be." But I feel like they get so much value out of doing that where they really get to leverage the fact that they have brought in these external members. And they get to hear from them as to how things are going and insights that they may be missing or not hearing from their people otherwise. +EDWARD: Agreed. +STEPH: Circling back to the manager IC path for a moment, I have a question for you because I often find myself asking this question to me or sometimes other people asking this question. But how do I know which path to follow? How should I explore do I want to be a manager? Do I want to continue and invest in my individual contributor skills and really lean into that path? Have you found any resources that have really helped you or ways that you coach others through that scenario? +EDWARD: I probably don't have a very interesting answer just because I'm going to mostly repeat what I think I said. But I think it's still so relevant and valid, which is, do you find yourself doing some of the work that a manager does? And it doesn't necessarily have to be the thing that I did, which was reaching out to people and checking up on them and seeing how they're doing. It could be that you really, really like running big team meetings or something like that. You just get a kick out of doing that kind of work. Or maybe you really enjoy working less on yourself and more on the group around you. That could also point to more of a technical leader. It doesn't have to be a person leader. +So I think I would look for where you find yourself wanting to effect change and figuring out if that fits into a manager role or not. And I've had people tell me they definitely do not want to be a manager, and they know that for sure and people that are on the fence. And I think that's another useful thing is to ask your manager what they do as the job and see if that's interesting. See if any of those things spark joy for you, as it were. +STEPH: I love the approach of just flat out asking your manager or someone that you see where perhaps you would like their role and saying, "Hey, what's your day like? What do you do? And can I be part of more of your day just to see if I would be interested in this type of work? Essentially, can I shadow some of the meetings that you're in?" I really like that idea. +And I think in the past, I would have been more hesitant about this approach. And it certainly depends on your company's culture. But there's a part of me that's like, just try it out. Like, if someone is encouraging you to go for a management role or to go for maybe it's a stronger individual contributor role, maybe it's being a principal engineer or something else, but if there's someone that's already there encouraging you or if it's just yourself and you are your own cheerleader, then go for it. Try it out. See if you like it. Take some notes. See if what you thought the job was going to be like actually matches reality. Because then, at the end of the day, you can always decide to change your path. +And if you are at a company that supports that type of experimentation, then you can step back to your current role if you decide that you don't like it. Or you might find that there's a really nice mix in there. But I feel like, with time, I'm getting a bit more bold with strategies in terms of just trying things out, even when it comes for technical challenges as well. Like if there's something that you're really nervous about or there's some big technical problem or something that the team is working on, and you're really skittish and nervous about it, just go ahead and say, "I'll do it, or I'd love to work with somebody on it," and then try it out and take some notes, see how it goes. +EDWARD: You could be really sneaky too. You can say to a colleague, "Hey. You want to get lunch?" And like you turn that into a secret one-on-one. Or you offer to run the retro board during retro, or you step up for doing a bunch of pull requests that week or something like that. You can try these little test things without even having to let somebody know or committing to anything publicly or even privately. Just really internally to yourself, you can try to take some of those steps. +STEPH: I like the sneaky success ladder. People won't talk about that one as much. [laughs] That's how I definitely found out that I didn't want to do sales. There was someone that I was talking to that was interested in working with thoughtbot, and Josh Clayton was very supportive of like, "Do you want to come along and be part of the conversation?" I was like, "Yeah, sure." And so I went along, and it was fun. But I definitely walked away like, yep, I don't want to be part of sales. I really like everything else minus this part. [laughs] +EDWARD: Yeah, it's good to know. It's good to know. +STEPH: Circling back just a bit to something you said earlier, you had mentioned that as you were becoming a team lead, you realized that helping others be successful at their job was really then what led to you feeling successful as well and that you could be a force multiplier. And you'd mentioned that a lot of that work comes down to bridging knowledge gaps. +And I'm really curious because this is something that we're always working on at thoughtbot. We are looking to identify what skills people would really like to learn. How can we help people learn those skills? And I'd love to know more. How do you go about this? How are you helping people bridge those knowledge gaps? +EDWARD: Yeah, so that is a doozy of a question. I have a couple of different answers. First is something I talked about before, building trust. And there's a bunch of different ways to do that. And I see trust as the foundation of almost everything in consulting. If you don't have that trust, it's really hard to deliver feedback like we talked about. It's hard to bridge that knowledge gap. Because effectively, nobody knows who you are, and what you're doing, what's going on, why you are coming to talk to them. It's really strange. And we can come back to how to build trust. +But once you've built that trust, I approach bridging that knowledge gap in a couple of different ways. One is asking questions instead of giving answers. The goal behind this is I want them to think about their goals. And that will often help lead them to some answer to bridge that gap that we have. I have some idea. They have another idea. If I can ask the right open-ended question, they will walk themselves across and get to where I want. Now, that doesn't always work. +Another strategy I've found is outlining a bunch of different possible solutions and their pros and cons. That has done two things. One, it helps them understand where I'm coming from, what my goals are in relation to what they're trying to do. And another one is that actually tends to gain a lot of trust. In the meantime, you're showing your expertise. You're showing that you're really considering all their problems. +Because almost every solution has trade-offs, there's very rarely a silver bullet. And so it's really helpful to say, "Well, here's the pros, here's the cons. Here's where I think you should go, but you know your business better than I do. And I've outlined all the things here. So whichever way you want to go forward on this, let's do that. And let me help you get there." +Joël and I, a colleague that we both cherish dearly, we did that on a project recently, and it was really, really successful. We put a lot of work in and helped them get to a really difficult architecture decision. And it could have gone one of, I think, four different ways. And we were sort of vying for one. They were vying for another. And we found a couple more in the middle, and I believe we went more towards the middle. And we were both pretty happy with how that turned out. +STEPH: I really, really like how that approach gives someone so much autonomy, and they're part of that decision. So you're not just saying, "Hey, you need to do this," and then just following through with it. But instead, it's saying, "I think I've heard everything. I think I understand the different problems that we're facing. Here are my suggestions, but you still have more context. What do you think, or which option would you like to pursue? I really like that option." +EDWARD: Yeah, because you're always writing this line as a consultant of like, they did bring you in for your skills and expertise and theory. But you really want to level them up so that they can make the right choices because that ultimately is...like, their success is your success as a consultant. That's the job in a lot of ways. +And so yeah, giving them the tools they need to make the right decision is so often the job. And I think that can get lost in the shuffle of, oh no, we have to meet these sprint goals. Or I got to get this ticket done or this bug fixed or something. And stepping back to get them to a better place is another goal that you can get to down the line. It's not to say shipping tickets is bad [laughs] or getting the sprint goals is bad. It's just another facet. Have you had any aha moments in consulting? +STEPH: Oh my gosh, I have had so many aha moments. I think most of them, for good or for worse, are here on The Bike Shed, or at least they've been shared here on The Bike Shed. [laughs] +EDWARD: Yeah, you should write a book of them all. +STEPH: Could we just grab the...I'm lazy. Can we grab the transcripts? We'll just turn that into a book. +EDWARD: [laughs] Yeah, just put it all together, call it The Bike Shed Diaries. +STEPH: Yeah. Oh, I like it. Okay, all right, that'll be next week's task. We'll publish The Bike Shed Diaries. [laughter] Specifically, in terms of bridging aha moments for helping someone bridge knowledge gaps or even for myself is I will often focus on what skills do you need today to make your job easier? What challenges are you facing? And also, what skills would you like to have six months from now? So that way, you are meeting the needs and the requirements that you really need today to fulfill your job. +But then also six months out, we're still looking towards the future. Maybe that's also more job requirements related, or maybe it's just for personal growth, or the areas that you're really excited about. You really want to contribute to an Elixir, open-source project, or something more specific that contributes to your fulfillment. +So when it comes to knowledge gaps, those are often the questions that I'm asking are, what do you need this week to make your job easier and to make your life easier? And then where would you like to be in terms of what skills would you like to have six months from now or what concepts? It may even be too lofty to say what skills because that could be huge to say that I want a whole new skill to be able to work in a language. So maybe it's something that's more specific of like, I'd really like to understand forms a bit better six months from now, or I'd really like to feel a little more confident with SQL, or maybe you'd like to take a look at Arel, things like that. +And then set those targets and then check in to say, "How's it going? How do you plan to learn these skills? Would you like help learning these skills? What are some resources?" Because I am not always the person that can help someone acquire that knowledge. So in that role, I'm often a facilitator where I will say, "Cool, you want this. You're interested in this particular skill. I don't know that skill. But I do know someone else who's really good at this. So let's get you all connected, and then you can work together on this." +EDWARD: And to dovetail a little bit with that manager individual contributor piece we were talking about before, that's another piece we didn't really talk about, which sounds like sponsoring. It's not just you doing the thing for your report or even coaching them necessarily. It's how can I get my report into a situation where they can exercise that skill or connect them with somebody who can help them with that thing? I'm still working on that one, honestly. That's a really, really difficult one. That's not something that comes naturally. +STEPH: When you say that's the part that's still challenging for you, is it the connecting of one person to someone else to learn a skill? I'm curious to hear more about which part of that is challenging for you. +EDWARD: I think I don't always think of sponsorship as a tool that I can lean on. It just doesn't come to mind as naturally. I think the very natural thing to do is mentor first, which is like, here's what you should do. It's kind of giving somebody a fish. Coaching then is more like teaching them how to fish. And then I don't know if we're going to extend this analogy farther. Sponsoring is like you're going to open up your own fishing teaching school or something. [laughs] And that just doesn't always occur to me. +I don't necessarily think like, oh yeah, like my friend over here could totally teach you about this technical skill that you're trying to learn or set you up to speak at a conference or something like that. It's a much different level of being a manager that I'm just not used to yet. I'm getting better at it. But it doesn't come naturally. +STEPH: Yeah, that's a very powerful form of managing someone as well because then you are helping that person go beyond their current bubble of who is their manager in their team and then helping them shine in other circles. And that's incredible and also something that I am always working on getting better at. +EDWARD: Let's get better at it together. +STEPH: We can do it. Also, when you mentioned opening a fishing school, I definitely pictured fish in a school in front of a chalkboard and someone's writing on that board and little fish in their school seats learning. +EDWARD: [laughs] A little Finding Nemo action. +STEPH: You got it. [laughs] You know your fishing school. You got to learn to stay away from those hooks. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: So pivoting just a bit on a slightly more technical note, you've been working on a side project called scribe.rip R-I-P. And I've heard a bit about it, but I would love to hear more. Could you tell me more about that project that you're working on? +EDWARD: Yeah, sure. So Scribe is what I would call an alternative frontend. And specifically, it is an alternative frontend for medium.com. The goal of the project is to give people a tool to read the Medium articles, not on medium.com, which might sound like a strange goal. [laughs] I'm happy to go into a little bit of a lie there. But that is the tool. And yeah, the domain is scribe.rip, mostly because that was a cheap domain. [laughs] So I got it and put my project there. +STEPH: I like that phrasing that you're using, alternative frontends because I think when you had first mentioned that, when I'd heard that in other conversations, I was like, oh, what is that? And I didn't know what it meant. But now, when you put it into some context, that makes all sense. I am intrigued. Why would someone be interested in using an alternative frontend versus, say like, there's an article on Medium; I'll just read it there. What might inspire me to want to use Scribe instead? +EDWARD: Definitely. There's a bunch of different reasons. The alternative frontends cover a pretty broad ground. But I'd say the most common reasons that someone might want to use one are privacy if they're worried about the main service, whatever that might be. Let's say Medium, in this case, is doing something with their user data that they'd rather they not do, potentially a better experience on that service. If you don't like the way Medium's articles look, you might want to see them in a different way. It can also be a way to vote with your actions, saying that this is the kind of web that I want to see if you don't like in general what a platform is doing. +And if you think a platform is potentially even harmful, it can be a way to say I don't want to support that platform, but sometimes I find myself needing to interact with it in some way. The alternative frontends can be a tool for that. On the very cynical angle, you can also go to you don't want to see ads. And sometimes, these are ad-supported platforms. Alternative frontends can get rid of those ads. And so that's another way too. I'm conflicted more about that one. We can dive into that. +But those are the most common reasons I've seen that people want to use alternative frontends. And to be clear, Scribe is not the only alternative frontend out there. There are frontends for YouTube, for Twitter, for Instagram, for Reddit. There's a huge list of a bunch of them, but those are some popular ones. +STEPH: Oh, that's really cool. I've never used any of those before. Will be sure to include some links in the show notes so people can check those out. And you listed some really interesting reasons for why folks might want to use an alternative frontend. I'm curious, to make this possible, though, does it mean that the service that is hosting that content do they have an open API into which then you can pull that content? How is an alternative frontend possible? +EDWARD: It is possible through APIs almost always. In some form or another, the APIs aren't necessarily open. One interesting side effect to many of the JavaScript rendered apps is that they often talk to some API in the background. And that can often be used to get the content in a more computer-friendly way. And so, with Medium, in particular, they don't really have an open API. So I ended up trying to figure out their API in the background that they're using to fetch articles and was able to get the content and display it in a different way. +STEPH: So everything you're describing sounds really interesting. I feel like I do have to ask the question, is it okay that these alternative frontends are taking content and are essentially rendering content but then not using the original service in which the content was published? How do you feel about that aspect? +EDWARD: Yeah, it's a really interesting question. There's a bit of a moral argument here, and I think everybody has to make that call for themselves. I think every platform if it gets large enough, is going to have people that don't want it to exist for some reason. I think, in some ways, providing alternative frontends is a bit of a release valve for that platform. Not to say that the alternative frontend explicitly helps that platform, but I imagine it gives people literally an alternative to then use instead and can make a peaceful, neutral ground in a way. So instead of being forced to use only the official platform, you can now use it at least in a limited fashion outside of that, which may alleviate whatever concerns you have and therefore keep everybody happy. +And I think honestly, in the long run and in practice, most platforms will not particularly notice the impact of these alternative frontends. Overall, we're talking very, very small potatoes. YouTube is not going after Invidious, the alternative frontend for YouTube, because it's probably a drop in the bucket. Nitter is not getting cease and desist from Twitter. Instagram is not sending a cease and desist to Bibliogram. These are some of these alternative frontends. And I think that's just because it's okay. They don't mind. It's so small. And it's giving people what they want in a way that is not harmful enough for it to really matter in the long run for them. +STEPH: Interesting. Because yeah, as you'd mentioned earlier, I think most people are going to continue to use that main service because that's what they see advertised. And it's more well-known, and it's frankly easier to go to. But then for folks who do want a little bit more control over their experience and they still want to access someone's content. So it is interesting. +You still want to ensure that the person who created that content always gets recognition and ownership of the content that they have. And in this case, that very much still applies. If I wrote an article on, say, Medium, but then I'm using Scribe to be able to read that content, it's still known who wrote the article. But this way, you are perhaps opting out of something else that service is doing, maybe if they have some type of tracking or something that you're not comfortable with. But you still want to be able to appreciate that person's content, even though they're perhaps only able to publish on Medium for right now. Or they're still looking for more ways to publish their content for folks who would like alternative ways to consume their information. Yeah, it's an interesting spot. +EDWARD: Right. And some ways that I think Scribe can provide a slightly better experience are trying to highlight the author more than the platform. The only time it says Scribe on the website is on the homepage. If you go into an actual article, I don't put branding or anything like that. Because I think I really want people to have their work speak for the author, not for the platform, and that's really important to me personally. And that might not be important to you, and that's okay. +Maybe you use scribe because it supports dark mode or something like that, and that's totally fine too. I don't mind at all. There are many aspects on which an alternative frontend can provide for people that the official platform doesn't. In some ways, it's augmenting their features, but in some ways, it's just giving people a bit more choice. And I think that's important. +STEPH: I have found since you'd mentioned the side project, that I've started using it more to read content. And I have found it helpful because it really silences all the noise because a lot of services want you to see ads, and they do want you to click on more articles that are related to the thing that you're reading. And so, I do appreciate the simplicity that it brings to the content. So then I can really just focus on that one article that someone has written. Overall, it seems like a really neat project. +EDWARD: Yeah, thanks. I'm glad you enjoyed it. +STEPH: Pivoting just a bit, I would love to go on a slight adventure and answer a listener question with you. What do you think? +EDWARD: Yeah, let's do it. +STEPH: All right. So this listener question focuses on empathy in your work, and this person writes in, "I'm curious how you all think about and notice empathy from yourselves and others around you. Empathy is so helpful and critical for making and maintaining healthy, productive relationships. I've noticed that the way you frame your client engagements, empathy sounds to be at the heart of them. For myself, I've noticed I'm better at it in certain contexts and certain times and with specific personalities, more so than others. More concretely, how do you stay empathetic with your clients and with cross-functional teams like product or design or even yourself? Can you teach or increase your empathy? And if so, what have you found successful in these situations? +So, Edward, this seems really on topic for some of the things that we were discussing earlier. So I'm going to hand it over to you first and get some of your thoughts. +EDWARD: This is a really great question. There's a lot to unpack. And one question they asked was, can you teach or increase your empathy, and if so, what have you found successful in what situations? I have found that being vulnerable both publicly and being empathetic publicly is a really useful tool. +A lot of teams don't communicate very publicly; it's a lot of stuff in private messages. Being vulnerable publicly in a big team channel can really open the door to letting other people be vulnerable and see what other people are doing, understand what people are feeling. And that's really at the heart of empathy is understanding someone else's point of view. +I've also found that starting small, like, just do it with your close co-worker. Maybe try to effect just change with them. And then once you've gotten them on board, broaden it to two other people, and then two more people, and then two more people, because it's really hard to take that leap of faith and be vulnerable by yourself. So I totally get that. +And also trying to take this on really early in someone's career or someone's tenure at a job. Offer to help new people to your team. Work with them, so they just start off with a very empathetic experience. And that can grow into a more empathetic team as a whole. Encourage team members to update documentation on their first day because they're learning so much in those first few days. Once they've learned it, the only reason they want to document it is because they have empathy for that next person. And so, just like setting that baseline and that boundary, I think is super helpful. What do you think? +STEPH: Yeah, I think those are some great examples. I really love that one way to acquire more empathy is to go on a journey with someone else. So if you have someone new that's joining the team, be their onboarding buddy. Go through that journey with them so you can understand what they're going through, what challenges they are facing. And that will boost the knowledge that you have and will likely also boost then the empathy that you have for people that are new to the team or for future onboarding buddies if you realize that there are some processes that really need to be smoothed out. +I also think it's worth highlighting that I don't think empathy is a single skill. I think it's a number of things. It can be the ability to feel someone else's emotions, so you can understand what someone else is feeling at that moment. It could be reasoning about another person's perspective, or it could be just, frankly, wanting to help. So I think there are a number of ways that we can demonstrate empathy to someone else. And it's going to depend on the situation as to which one of those skills is going to be helpful. +For how you stay empathetic with clients, that one is a really interesting one just because the way we work with clients; we do get to go on that journey with them. We are with them in making decisions around priority and technical decisions and what pain points they are feeling. So I think going, as you described earlier, going on that journey with someone is what helps us stay empathetic with our clients. And I think that's true for cross-functional teams. +So if you are working with someone that's maybe on customer support or on the design team, it could be grabbing lunch with them and saying, "Hey, what's your day like? What challenges are you facing?" Maybe it's your company has rotations where you actually are part of the customer service team for a day. So you get to respond to tickets and have more of an understanding. +I'm realizing there's a theme here. I feel like a lot of it comes down to stepping into someone else's shoes and seeing the world from their perspective and not just seeing it but experiencing the world from their perspective. +EDWARD: Yeah. And another way to do that...because that can also take a lot of time. It's a hard ask potentially to say, "I'm going to go be a customer service rep for a day," if your job is also, I'm going to be a programmer and ship features or fix bugs. That's hard to do. And I think there are ways to do that, to experience what someone else is experiencing by trying to take on not necessarily the role of the other person but just trying to support the other person in their role. +So, for example, we see teams become really siloed where the product is solely responsible for writing tickets, development is solely responsible for understanding what makes the code work or fixing a bug, and design is only responsible for user interactions. I found it really, really helpful to try to approach design and say, "What's the goal here with this user interaction?" I don't know. I'm not a designer. +And so, how can I ask them and again bridge my own knowledge gap? Because that can really help you get to that point and help them understand maybe what you're going for and say, "I wasn't going implement it like that because I thought X, Y, and Z." And they go like, "Oh, I see what you're saying." And then now you're making those barriers…or maybe when you're working with products, they're like, "I see what you're trying to do here. But in my experience, I've seen websites like this. How do you feel about that?" +And it's not to say that you're just trying to steamroll over them. It's that you're trying to share your experience and get on the same page and trying to get them on your page so that you're all making the decision together, not just handing it back and forth across the wall. +STEPH: Yeah, and that was really well said where I think the more that you do collaborate with others and the more that you make decisions with others, the more context you're going to have for why someone else is making a decision, what challenges they're facing. And so again, it comes down to having more information about what that person is going through to then help you be able to be empathetic because I don't think this is a skill you can just turn on. If you don't know anything about somebody, you don't know anything about what they're going through. Being empathetic is going to be incredibly hard. +And in this question, they mentioned that they're better at it in some contexts, at certain times with certain personalities. And I think that makes sense because anyone that's more like you, I think you're going to find it easier to be more empathetic. And anyone that has had similar situations, ones that you can relate to, you're going to naturally be more empathetic to. +Also, timing is important. Maybe it's the end of the day, and you have already used up your empathy bucket, and you have nothing left to give. And that's just something to be aware of. You may have reached that threshold. And with practice, maybe that bucket will get bigger, and you will have more empathy to give throughout the day. But just be aware when you've also hit that threshold, and maybe you don't have any more to give in that moment. But I do think it's very much a skill that you build with a lot of practice. +EDWARD: Yeah, it's absolutely a muscle. You're totally right. You are trying to do it, and the first time you do, it will be very hard. You will be very drained. And you need to recognize that that's okay. You can step away and come back the next day, and it will get a little better. But that's a wonderful point. +STEPH: There is a really nice example that you have captured in a thoughtbot blog post that will be sure to link to in the show notes that highlights how difficult it can be to communicate the tone of voice and even how impactful that can be for someone who is reading that message that you have sent, and they don't understand that tone of voice. +EDWARD: Yeah, that post was very focused on trying to bring in emotion to a more or less emotionless conversation, which is often text. It's very hard to understand when someone is being sarcastic or angry or bubbly or whatever. Just even silly things like adding emojis can really help in that process of bringing in more emotion and getting that tone across. +And I'd say finally to this person who asked the question that the fact that you're thinking about it is already an empathetic thing. Just the fact that you want to get better at this shows that you're already empathetic, and that's really great to hear. +STEPH: Yeah, I think that's a really great observation, and I think that's a perfect note for us to end on. So thank you so much to the person that shared this question with us. It is a very interesting question. And I applaud you for being so thoughtful about how to be empathetic with everyone around you. +Edward, thank you again for being a guest on the show. For those that are interested in following more of your work or checking out your alternative frontend, where can they find out more about the life of Edward Loveall? +EDWARD: You can find the alternative frontend called Scribe; it’s scribe.rip. You can find me at edwardloveall.com. And I have links to various social media or email if you want to email me or whatever. And yeah, it's been a pleasure. Thanks for having me, Steph. +STEPH: Thanks so much. On that note, shall we wrap up? +EDWARD: Let's wrap up. Ta-ta, Stephanie. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Fellow thoughtboter Edward Loveall joins Steph to cohost and talk about alternative frontends and his own that he created: scribe.rip: an alternative frontend to Medium, learning about what it's like to be a manager/non-IC, and helps answer a listener question re: how do you think about empathy in your work?

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And this week, Chris is taking a quick break. But while he's away, we have a guest on today's show. Today's guest is fellow thoughtboter, and wonderful friend, and British accent enthusiast Edward Loveall.

+ +

EDWARD: Oh, hello, Steph. It is lovely to meet...No; this is not my real accent. Anyway, hi, friends. [chuckles]

+ +

STEPH: [laughs] Hello, British Edward. I am so excited to be chatting with you today. Are you going to maintain that accent throughout the whole episode?

+ +

EDWARD: No. There's no way I could do that. I need a lot more professional actor training to be able to maintain quality of that level, I think.

+ +

STEPH: That's fair. I won't hold you to that standard. I was reflecting on preparation for this chat. I've been thinking about all the fun that we've had together, the time that we have worked together at thoughtbot, all the remote coffee walks that we have gone on together as we've talked through consulting challenges or coding challenges. And I realized that we have never worked on a project together, which is wild to me.

+ +

EDWARD: Huh. Yeah, I think you're right. That is wild. Because I've been here three and a half years, and you've been here even longer than me. So in three and a half years of overlap, we've never done that.

+ +

STEPH: And yet we've still always found ways to hang out.

+ +

EDWARD: We make it a priority, you know.

+ +

STEPH: I think we need to...we might have to bribe somebody for us to get on a project together.

+ +

EDWARD: I'm pretty sure we know the person to bribe.

+ +

STEPH: We do.

+ +

EDWARD: We can go talk to our boss and make that happen. One thing we've both done in our career here at thoughtbot, too, is we have gone from individual contributor to being a manager, which is a cool transition.

+ +

STEPH: That's a really good point. That is fun that we have embarked on that journey together. I was very much encouraged to become a team lead, and that was very helpful. Because I'm the type of person where I'm not sure I would have put myself up for that role. I'm very thankful that others encouraged me to do so because I really love it. There are certainly challenges with being a team lead. But overall, I have very much enjoyed the role.

+ +

Just to provide some context for being a team lead a thoughtbot, because I feel like those management roles tend to differ from company to company as to the level of responsibilities that you have. So for us in particular, it's really focused on leading a team of developers, usually two to three developers, and conducting regular one-on-ones to ensure that they are fulfilled and are successful in their projects and their growth at thoughtbot. And then helping them become senior developers if they're not already and essentially coaching them through difficult development and consulting scenarios.

+ +

EDWARD: Yeah, there is still an expectation that you are an individual contributor in some form on client projects. It is not just a management position.

+ +

STEPH: Yeah, that's a good point. For me, that context switching is often what makes it challenging but yet also helps me still feel that I can coach somebody and that I can have one-on-ones because I am still in the trenches. I'm still contributing to client projects. And so, it really helps me still stay in touch with the work that's being done and the struggles that people will face. Let me say again I am positive I wouldn't have pursued this path if I lost my IC status. I really like that part of the role. That's really a split. How about you?

+ +

EDWARD: Yeah, and I still do. We've been experimenting. So thoughtbot generally does four days a week on many projects. So we do four days a week with our client, and then we do one day a week as investment. And team leads, at least on the team that we are on, have been experimenting with just doing three days a week on a client, one day dedicated towards team lead, and then one day for investment. I like that split so far.

+ +

We're still seeing how it goes, still pretty early on in that experiment. But I've enjoyed continuing to be in the trenches, as it were, and working sometimes with the people that report to me so that we can really grow in the same way. There's a lot of context shared there. And that's been really wonderful.

+ +

STEPH: Yeah, I have some specific questions I'd love to ask you about that shift in schedule. Because in some of our meetings, there has been discussion about that ability to context switch between I'm only billing three days now instead of my typical four. And I now have more time to focus on team lead priorities, but then that also means I lose a day with client work. And so there's that battle going back and forth between focusing on client work and also focusing on team lead work. So I'm going to leave that as just a teaser because I want to come back to that.

+ +

But I'd really love to circle back to earlier in the year when you were thinking about becoming a team lead and correct me if I'm wrong, but I think you were pretty hesitant about it. And you were still deciding if it was something you wanted to do. Do you recall what helped you make up your mind as to which path you wanted to take and why you chose this one?

+ +

EDWARD: Yeah, that's a great question. I did also get some encouragement, a pretty light encouragement from a previous co-worker. And that was helpful, but I turned it down initially. Someone asked, "Hey, are you interested in this?" And I said, "Nope, definitely not." And, I don't know, a year-ish later, I then ended up applying.

+ +

And I think what happened in the intervening year was that I started to naturally do some of the work of a team lead primarily, checking in with people and talking with them, pairing with them on things more regularly. So I felt as if I was already doing some of the work, not exactly running a one-on-one, not getting people promoted necessarily. But I cared about the people I was working with and wanted to see them grow and be happy and thrive. That realization helped me think, oh yeah, I'm just kind of doing this. And I should maybe apply for this role.

+ +

STEPH: Wow, that resonates so much. I've heard that from other folks, too, as they have progressed into team lead or other management roles is it was often they already felt like they had started doing some of the work, or there was some natural inclination to start taking over those activities. And so then it felt right to then actually acquire that title and take on those responsibilities officially.

+ +

Well, how's it been going? You had almost a year now. So you had some of those hesitations at the beginning. How's it been? What do you think of being a team lead?

+ +

EDWARD: Yeah, I'm really enjoying it. It is a challenge like you said. But that's every job, right? Every job should be a bit of a stretch. So I did come into it with some natural inclinations of wanting to talk to people and check in with them. But there are all these other pieces that I wasn't good at. One thing that has been really challenging is instead of completing things myself, being that individual contributor, is trying to coach and sponsor people to do something that I would do.

+ +

And I think the hardest part about that is they may not be as far along in their career as you are. And so it is hard to watch someone struggle in the way that you used to struggle without saying, "Oh, here, let me just do that for you.” And I think what I started to realize is that the efforts that I'm putting in I can really be a force multiplier and end up effecting more change than what I could do by myself.

+ +

Like, if you think about it, I have four reports right now, and they're all really smart and talented people. But let's just say they were half as good as I was. That is definitely not true but just go with the numbers here for a second. If I could teach them to do what I do, even if they were half as fast as me, because there are four of them, they can get two times the work done.

+ +

The math adds up in a way where if I can unblock those people, help them just get to the next one little step, do whatever it is that they need, they're going to do way more than I could by myself. And really wrapping your head around that and the advantages there is so hard but so rewarding once you figure it out and get it going.

+ +

STEPH: Do you feel like anybody told you that up front going into taking on some more management responsibilities? Or is that something you learned as you went?

+ +

EDWARD: I definitely learned that as I went. I got some great advice from Josh Clayton, who we work with, and he's been a manager for a long time. And that's a lot of how he thinks about it. And he encouraged me to do things like pairing with everybody on the team or running little workshops to teach, to fill in knowledge gaps for people asking questions, instead of giving answers, to help them find their own answer. And that's all been really, really helpful.

+ +

STEPH: Yeah, that's one of the things that I have valued very much about our culture. I've seen some other companies struggle with is that when someone does get elevated into a management role that they still need support. They still need to be coached. And they also need room to make mistakes and grow.

+ +

And at thoughtbot, I feel that we have been very supported and where there's someone that I can still get mentoring and coaching from. And I can learn to be a manager on the job versus I'm not just put in a position where I'm going to fail or just put there without the expectation that I still need to grow as a manager and as a person as well. So that has helped me out tremendously as well.

+ +

You highlighted the idea of pairing more with others and then asking more questions around providing answers. And as you're learning those skills or as you've acquired those skills for being a team lead at thoughtbot, have you found those skills also transition well to client work?

+ +

EDWARD: Yeah, they do. There's a lot of overlap, especially around gaining trust with somebody. I'm gaining trust in one-on-ones, but I'm also gaining trust with my client or helping my client understand something. This gets a little more into the client-side of it. But a lot of times in client work, I'm looking to bridge a gap. I understand something because of my consulting experience, and they want my knowledge and consulting experience. But it's hard to just go in and say, "Do X or do Y."

+ +

And in the same way, with somebody who's reporting to me or who we're having a one-on-one, it's not usually very helpful to just say, "Do this, do that." You want to help them understand the why and bridge that knowledge gap to get to where you want them to be and where you think they should be. Those really do go hand in hand, and I have used a lot of the same skills.

+ +

Giving feedback also has been a huge thing to share. It's really, really hard to give critical feedback to somebody. It's very easy for them to shut down and not take the feedback, which is the opposite of what you're trying to do. And the same can be with clients. Like, they've gotten to where they've gotten to because of whatever they've done in the past, and trying to show them why what some of the things they're doing is maybe not ideal is really tricky without triggering that flight or fight response. So yeah, there are lots and lots of crossover to answer your question. [chuckles]

+ +

STEPH: I get so excited when clients that have brought on thoughtboters recognize that we are there temporarily, that we bring an outsider perspective. And they will set up essentially reoccurring; maybe it's weekly, maybe it's monthly to say, "Hey, give us feedback. Let us know what are you seeing? What do you think about the team? What do you think about our processes? What would you like to change?"

+ +

And I don't mean just in a retro setting that you're having with the team, but it may be meeting with leadership of that company to give them that feedback directly. And that's awesome. It's rare because, I mean, that takes confidence on their part to be able to say, "Hey, give us all of your feedback, constructive, positive, whatever it may be." But I feel like they get so much value out of doing that where they really get to leverage the fact that they have brought in these external members. And they get to hear from them as to how things are going and insights that they may be missing or not hearing from their people otherwise.

+ +

EDWARD: Agreed.

+ +

STEPH: Circling back to the manager IC path for a moment, I have a question for you because I often find myself asking this question to me or sometimes other people asking this question. But how do I know which path to follow? How should I explore do I want to be a manager? Do I want to continue and invest in my individual contributor skills and really lean into that path? Have you found any resources that have really helped you or ways that you coach others through that scenario?

+ +

EDWARD: I probably don't have a very interesting answer just because I'm going to mostly repeat what I think I said. But I think it's still so relevant and valid, which is, do you find yourself doing some of the work that a manager does? And it doesn't necessarily have to be the thing that I did, which was reaching out to people and checking up on them and seeing how they're doing. It could be that you really, really like running big team meetings or something like that. You just get a kick out of doing that kind of work. Or maybe you really enjoy working less on yourself and more on the group around you. That could also point to more of a technical leader. It doesn't have to be a person leader.

+ +

So I think I would look for where you find yourself wanting to effect change and figuring out if that fits into a manager role or not. And I've had people tell me they definitely do not want to be a manager, and they know that for sure and people that are on the fence. And I think that's another useful thing is to ask your manager what they do as the job and see if that's interesting. See if any of those things spark joy for you, as it were.

+ +

STEPH: I love the approach of just flat out asking your manager or someone that you see where perhaps you would like their role and saying, "Hey, what's your day like? What do you do? And can I be part of more of your day just to see if I would be interested in this type of work? Essentially, can I shadow some of the meetings that you're in?" I really like that idea.

+ +

And I think in the past, I would have been more hesitant about this approach. And it certainly depends on your company's culture. But there's a part of me that's like, just try it out. Like, if someone is encouraging you to go for a management role or to go for maybe it's a stronger individual contributor role, maybe it's being a principal engineer or something else, but if there's someone that's already there encouraging you or if it's just yourself and you are your own cheerleader, then go for it. Try it out. See if you like it. Take some notes. See if what you thought the job was going to be like actually matches reality. Because then, at the end of the day, you can always decide to change your path.

+ +

And if you are at a company that supports that type of experimentation, then you can step back to your current role if you decide that you don't like it. Or you might find that there's a really nice mix in there. But I feel like, with time, I'm getting a bit more bold with strategies in terms of just trying things out, even when it comes for technical challenges as well. Like if there's something that you're really nervous about or there's some big technical problem or something that the team is working on, and you're really skittish and nervous about it, just go ahead and say, "I'll do it, or I'd love to work with somebody on it," and then try it out and take some notes, see how it goes.

+ +

EDWARD: You could be really sneaky too. You can say to a colleague, "Hey. You want to get lunch?" And like you turn that into a secret one-on-one. Or you offer to run the retro board during retro, or you step up for doing a bunch of pull requests that week or something like that. You can try these little test things without even having to let somebody know or committing to anything publicly or even privately. Just really internally to yourself, you can try to take some of those steps.

+ +

STEPH: I like the sneaky success ladder. People won't talk about that one as much. [laughs] That's how I definitely found out that I didn't want to do sales. There was someone that I was talking to that was interested in working with thoughtbot, and Josh Clayton was very supportive of like, "Do you want to come along and be part of the conversation?" I was like, "Yeah, sure." And so I went along, and it was fun. But I definitely walked away like, yep, I don't want to be part of sales. I really like everything else minus this part. [laughs]

+ +

EDWARD: Yeah, it's good to know. It's good to know.

+ +

STEPH: Circling back just a bit to something you said earlier, you had mentioned that as you were becoming a team lead, you realized that helping others be successful at their job was really then what led to you feeling successful as well and that you could be a force multiplier. And you'd mentioned that a lot of that work comes down to bridging knowledge gaps.

+ +

And I'm really curious because this is something that we're always working on at thoughtbot. We are looking to identify what skills people would really like to learn. How can we help people learn those skills? And I'd love to know more. How do you go about this? How are you helping people bridge those knowledge gaps?

+ +

EDWARD: Yeah, so that is a doozy of a question. I have a couple of different answers. First is something I talked about before, building trust. And there's a bunch of different ways to do that. And I see trust as the foundation of almost everything in consulting. If you don't have that trust, it's really hard to deliver feedback like we talked about. It's hard to bridge that knowledge gap. Because effectively, nobody knows who you are, and what you're doing, what's going on, why you are coming to talk to them. It's really strange. And we can come back to how to build trust.

+ +

But once you've built that trust, I approach bridging that knowledge gap in a couple of different ways. One is asking questions instead of giving answers. The goal behind this is I want them to think about their goals. And that will often help lead them to some answer to bridge that gap that we have. I have some idea. They have another idea. If I can ask the right open-ended question, they will walk themselves across and get to where I want. Now, that doesn't always work.

+ +

Another strategy I've found is outlining a bunch of different possible solutions and their pros and cons. That has done two things. One, it helps them understand where I'm coming from, what my goals are in relation to what they're trying to do. And another one is that actually tends to gain a lot of trust. In the meantime, you're showing your expertise. You're showing that you're really considering all their problems.

+ +

Because almost every solution has trade-offs, there's very rarely a silver bullet. And so it's really helpful to say, "Well, here's the pros, here's the cons. Here's where I think you should go, but you know your business better than I do. And I've outlined all the things here. So whichever way you want to go forward on this, let's do that. And let me help you get there."

+ +

Joël and I, a colleague that we both cherish dearly, we did that on a project recently, and it was really, really successful. We put a lot of work in and helped them get to a really difficult architecture decision. And it could have gone one of, I think, four different ways. And we were sort of vying for one. They were vying for another. And we found a couple more in the middle, and I believe we went more towards the middle. And we were both pretty happy with how that turned out.

+ +

STEPH: I really, really like how that approach gives someone so much autonomy, and they're part of that decision. So you're not just saying, "Hey, you need to do this," and then just following through with it. But instead, it's saying, "I think I've heard everything. I think I understand the different problems that we're facing. Here are my suggestions, but you still have more context. What do you think, or which option would you like to pursue? I really like that option."

+ +

EDWARD: Yeah, because you're always writing this line as a consultant of like, they did bring you in for your skills and expertise and theory. But you really want to level them up so that they can make the right choices because that ultimately is...like, their success is your success as a consultant. That's the job in a lot of ways.

+ +

And so yeah, giving them the tools they need to make the right decision is so often the job. And I think that can get lost in the shuffle of, oh no, we have to meet these sprint goals. Or I got to get this ticket done or this bug fixed or something. And stepping back to get them to a better place is another goal that you can get to down the line. It's not to say shipping tickets is bad [laughs] or getting the sprint goals is bad. It's just another facet. Have you had any aha moments in consulting?

+ +

STEPH: Oh my gosh, I have had so many aha moments. I think most of them, for good or for worse, are here on The Bike Shed, or at least they've been shared here on The Bike Shed. [laughs]

+ +

EDWARD: Yeah, you should write a book of them all.

+ +

STEPH: Could we just grab the...I'm lazy. Can we grab the transcripts? We'll just turn that into a book.

+ +

EDWARD: [laughs] Yeah, just put it all together, call it The Bike Shed Diaries.

+ +

STEPH: Yeah. Oh, I like it. Okay, all right, that'll be next week's task. We'll publish The Bike Shed Diaries. [laughter] Specifically, in terms of bridging aha moments for helping someone bridge knowledge gaps or even for myself is I will often focus on what skills do you need today to make your job easier? What challenges are you facing? And also, what skills would you like to have six months from now? So that way, you are meeting the needs and the requirements that you really need today to fulfill your job.

+ +

But then also six months out, we're still looking towards the future. Maybe that's also more job requirements related, or maybe it's just for personal growth, or the areas that you're really excited about. You really want to contribute to an Elixir, open-source project, or something more specific that contributes to your fulfillment.
+So when it comes to knowledge gaps, those are often the questions that I'm asking are, what do you need this week to make your job easier and to make your life easier? And then where would you like to be in terms of what skills would you like to have six months from now or what concepts? It may even be too lofty to say what skills because that could be huge to say that I want a whole new skill to be able to work in a language. So maybe it's something that's more specific of like, I'd really like to understand forms a bit better six months from now, or I'd really like to feel a little more confident with SQL, or maybe you'd like to take a look at Arel, things like that.

+ +

And then set those targets and then check in to say, "How's it going? How do you plan to learn these skills? Would you like help learning these skills? What are some resources?" Because I am not always the person that can help someone acquire that knowledge. So in that role, I'm often a facilitator where I will say, "Cool, you want this. You're interested in this particular skill. I don't know that skill. But I do know someone else who's really good at this. So let's get you all connected, and then you can work together on this."

+ +

EDWARD: And to dovetail a little bit with that manager individual contributor piece we were talking about before, that's another piece we didn't really talk about, which sounds like sponsoring. It's not just you doing the thing for your report or even coaching them necessarily. It's how can I get my report into a situation where they can exercise that skill or connect them with somebody who can help them with that thing? I'm still working on that one, honestly. That's a really, really difficult one. That's not something that comes naturally.

+ +

STEPH: When you say that's the part that's still challenging for you, is it the connecting of one person to someone else to learn a skill? I'm curious to hear more about which part of that is challenging for you.

+ +

EDWARD: I think I don't always think of sponsorship as a tool that I can lean on. It just doesn't come to mind as naturally. I think the very natural thing to do is mentor first, which is like, here's what you should do. It's kind of giving somebody a fish. Coaching then is more like teaching them how to fish. And then I don't know if we're going to extend this analogy farther. Sponsoring is like you're going to open up your own fishing teaching school or something. [laughs] And that just doesn't always occur to me.

+ +

I don't necessarily think like, oh yeah, like my friend over here could totally teach you about this technical skill that you're trying to learn or set you up to speak at a conference or something like that. It's a much different level of being a manager that I'm just not used to yet. I'm getting better at it. But it doesn't come naturally.

+ +

STEPH: Yeah, that's a very powerful form of managing someone as well because then you are helping that person go beyond their current bubble of who is their manager in their team and then helping them shine in other circles. And that's incredible and also something that I am always working on getting better at.

+ +

EDWARD: Let's get better at it together.

+ +

STEPH: We can do it. Also, when you mentioned opening a fishing school, I definitely pictured fish in a school in front of a chalkboard and someone's writing on that board and little fish in their school seats learning.

+ +

EDWARD: [laughs] A little Finding Nemo action.

+ +

STEPH: You got it. [laughs] You know your fishing school. You got to learn to stay away from those hooks.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So pivoting just a bit on a slightly more technical note, you've been working on a side project called scribe.rip R-I-P. And I've heard a bit about it, but I would love to hear more. Could you tell me more about that project that you're working on?
+EDWARD: Yeah, sure. So Scribe is what I would call an alternative frontend. And specifically, it is an alternative frontend for medium.com. The goal of the project is to give people a tool to read the Medium articles, not on medium.com, which might sound like a strange goal. [laughs] I'm happy to go into a little bit of a lie there. But that is the tool. And yeah, the domain is scribe.rip, mostly because that was a cheap domain. [laughs] So I got it and put my project there.

+ +

STEPH: I like that phrasing that you're using, alternative frontends because I think when you had first mentioned that, when I'd heard that in other conversations, I was like, oh, what is that? And I didn't know what it meant. But now, when you put it into some context, that makes all sense. I am intrigued. Why would someone be interested in using an alternative frontend versus, say like, there's an article on Medium; I'll just read it there. What might inspire me to want to use Scribe instead?

+ +

EDWARD: Definitely. There's a bunch of different reasons. The alternative frontends cover a pretty broad ground. But I'd say the most common reasons that someone might want to use one are privacy if they're worried about the main service, whatever that might be. Let's say Medium, in this case, is doing something with their user data that they'd rather they not do, potentially a better experience on that service. If you don't like the way Medium's articles look, you might want to see them in a different way. It can also be a way to vote with your actions, saying that this is the kind of web that I want to see if you don't like in general what a platform is doing.

+ +

And if you think a platform is potentially even harmful, it can be a way to say I don't want to support that platform, but sometimes I find myself needing to interact with it in some way. The alternative frontends can be a tool for that. On the very cynical angle, you can also go to you don't want to see ads. And sometimes, these are ad-supported platforms. Alternative frontends can get rid of those ads. And so that's another way too. I'm conflicted more about that one. We can dive into that.

+ +

But those are the most common reasons I've seen that people want to use alternative frontends. And to be clear, Scribe is not the only alternative frontend out there. There are frontends for YouTube, for Twitter, for Instagram, for Reddit. There's a huge list of a bunch of them, but those are some popular ones.

+ +

STEPH: Oh, that's really cool. I've never used any of those before. Will be sure to include some links in the show notes so people can check those out. And you listed some really interesting reasons for why folks might want to use an alternative frontend. I'm curious, to make this possible, though, does it mean that the service that is hosting that content do they have an open API into which then you can pull that content? How is an alternative frontend possible?

+ +

EDWARD: It is possible through APIs almost always. In some form or another, the APIs aren't necessarily open. One interesting side effect to many of the JavaScript rendered apps is that they often talk to some API in the background. And that can often be used to get the content in a more computer-friendly way. And so, with Medium, in particular, they don't really have an open API. So I ended up trying to figure out their API in the background that they're using to fetch articles and was able to get the content and display it in a different way.

+ +

STEPH: So everything you're describing sounds really interesting. I feel like I do have to ask the question, is it okay that these alternative frontends are taking content and are essentially rendering content but then not using the original service in which the content was published? How do you feel about that aspect?

+ +

EDWARD: Yeah, it's a really interesting question. There's a bit of a moral argument here, and I think everybody has to make that call for themselves. I think every platform if it gets large enough, is going to have people that don't want it to exist for some reason. I think, in some ways, providing alternative frontends is a bit of a release valve for that platform. Not to say that the alternative frontend explicitly helps that platform, but I imagine it gives people literally an alternative to then use instead and can make a peaceful, neutral ground in a way. So instead of being forced to use only the official platform, you can now use it at least in a limited fashion outside of that, which may alleviate whatever concerns you have and therefore keep everybody happy.

+ +

And I think honestly, in the long run and in practice, most platforms will not particularly notice the impact of these alternative frontends. Overall, we're talking very, very small potatoes. YouTube is not going after Invidious, the alternative frontend for YouTube, because it's probably a drop in the bucket. Nitter is not getting cease and desist from Twitter. Instagram is not sending a cease and desist to Bibliogram. These are some of these alternative frontends. And I think that's just because it's okay. They don't mind. It's so small. And it's giving people what they want in a way that is not harmful enough for it to really matter in the long run for them.

+ +

STEPH: Interesting. Because yeah, as you'd mentioned earlier, I think most people are going to continue to use that main service because that's what they see advertised. And it's more well-known, and it's frankly easier to go to. But then for folks who do want a little bit more control over their experience and they still want to access someone's content. So it is interesting.

+ +

You still want to ensure that the person who created that content always gets recognition and ownership of the content that they have. And in this case, that very much still applies. If I wrote an article on, say, Medium, but then I'm using Scribe to be able to read that content, it's still known who wrote the article. But this way, you are perhaps opting out of something else that service is doing, maybe if they have some type of tracking or something that you're not comfortable with. But you still want to be able to appreciate that person's content, even though they're perhaps only able to publish on Medium for right now. Or they're still looking for more ways to publish their content for folks who would like alternative ways to consume their information. Yeah, it's an interesting spot.

+ +

EDWARD: Right. And some ways that I think Scribe can provide a slightly better experience are trying to highlight the author more than the platform. The only time it says Scribe on the website is on the homepage. If you go into an actual article, I don't put branding or anything like that. Because I think I really want people to have their work speak for the author, not for the platform, and that's really important to me personally. And that might not be important to you, and that's okay.

+ +

Maybe you use scribe because it supports dark mode or something like that, and that's totally fine too. I don't mind at all. There are many aspects on which an alternative frontend can provide for people that the official platform doesn't. In some ways, it's augmenting their features, but in some ways, it's just giving people a bit more choice. And I think that's important.

+ +

STEPH: I have found since you'd mentioned the side project, that I've started using it more to read content. And I have found it helpful because it really silences all the noise because a lot of services want you to see ads, and they do want you to click on more articles that are related to the thing that you're reading. And so, I do appreciate the simplicity that it brings to the content. So then I can really just focus on that one article that someone has written. Overall, it seems like a really neat project.

+ +

EDWARD: Yeah, thanks. I'm glad you enjoyed it.

+ +

STEPH: Pivoting just a bit, I would love to go on a slight adventure and answer a listener question with you. What do you think?

+ +

EDWARD: Yeah, let's do it.

+ +

STEPH: All right. So this listener question focuses on empathy in your work, and this person writes in, "I'm curious how you all think about and notice empathy from yourselves and others around you. Empathy is so helpful and critical for making and maintaining healthy, productive relationships. I've noticed that the way you frame your client engagements, empathy sounds to be at the heart of them. For myself, I've noticed I'm better at it in certain contexts and certain times and with specific personalities, more so than others. More concretely, how do you stay empathetic with your clients and with cross-functional teams like product or design or even yourself? Can you teach or increase your empathy? And if so, what have you found successful in these situations?

+ +

So, Edward, this seems really on topic for some of the things that we were discussing earlier. So I'm going to hand it over to you first and get some of your thoughts.

+ +

EDWARD: This is a really great question. There's a lot to unpack. And one question they asked was, can you teach or increase your empathy, and if so, what have you found successful in what situations? I have found that being vulnerable both publicly and being empathetic publicly is a really useful tool.

+ +

A lot of teams don't communicate very publicly; it's a lot of stuff in private messages. Being vulnerable publicly in a big team channel can really open the door to letting other people be vulnerable and see what other people are doing, understand what people are feeling. And that's really at the heart of empathy is understanding someone else's point of view.

+ +

I've also found that starting small, like, just do it with your close co-worker. Maybe try to effect just change with them. And then once you've gotten them on board, broaden it to two other people, and then two more people, and then two more people, because it's really hard to take that leap of faith and be vulnerable by yourself. So I totally get that.

+ +

And also trying to take this on really early in someone's career or someone's tenure at a job. Offer to help new people to your team. Work with them, so they just start off with a very empathetic experience. And that can grow into a more empathetic team as a whole. Encourage team members to update documentation on their first day because they're learning so much in those first few days. Once they've learned it, the only reason they want to document it is because they have empathy for that next person. And so, just like setting that baseline and that boundary, I think is super helpful. What do you think?

+ +

STEPH: Yeah, I think those are some great examples. I really love that one way to acquire more empathy is to go on a journey with someone else. So if you have someone new that's joining the team, be their onboarding buddy. Go through that journey with them so you can understand what they're going through, what challenges they are facing. And that will boost the knowledge that you have and will likely also boost then the empathy that you have for people that are new to the team or for future onboarding buddies if you realize that there are some processes that really need to be smoothed out.

+ +

I also think it's worth highlighting that I don't think empathy is a single skill. I think it's a number of things. It can be the ability to feel someone else's emotions, so you can understand what someone else is feeling at that moment. It could be reasoning about another person's perspective, or it could be just, frankly, wanting to help. So I think there are a number of ways that we can demonstrate empathy to someone else. And it's going to depend on the situation as to which one of those skills is going to be helpful.

+ +

For how you stay empathetic with clients, that one is a really interesting one just because the way we work with clients; we do get to go on that journey with them. We are with them in making decisions around priority and technical decisions and what pain points they are feeling. So I think going, as you described earlier, going on that journey with someone is what helps us stay empathetic with our clients. And I think that's true for cross-functional teams.

+ +

So if you are working with someone that's maybe on customer support or on the design team, it could be grabbing lunch with them and saying, "Hey, what's your day like? What challenges are you facing?" Maybe it's your company has rotations where you actually are part of the customer service team for a day. So you get to respond to tickets and have more of an understanding.

+ +

I'm realizing there's a theme here. I feel like a lot of it comes down to stepping into someone else's shoes and seeing the world from their perspective and not just seeing it but experiencing the world from their perspective.

+ +

EDWARD: Yeah. And another way to do that...because that can also take a lot of time. It's a hard ask potentially to say, "I'm going to go be a customer service rep for a day," if your job is also, I'm going to be a programmer and ship features or fix bugs. That's hard to do. And I think there are ways to do that, to experience what someone else is experiencing by trying to take on not necessarily the role of the other person but just trying to support the other person in their role.

+ +

So, for example, we see teams become really siloed where the product is solely responsible for writing tickets, development is solely responsible for understanding what makes the code work or fixing a bug, and design is only responsible for user interactions. I found it really, really helpful to try to approach design and say, "What's the goal here with this user interaction?" I don't know. I'm not a designer.

+ +

And so, how can I ask them and again bridge my own knowledge gap? Because that can really help you get to that point and help them understand maybe what you're going for and say, "I wasn't going implement it like that because I thought X, Y, and Z." And they go like, "Oh, I see what you're saying." And then now you're making those barriers…or maybe when you're working with products, they're like, "I see what you're trying to do here. But in my experience, I've seen websites like this. How do you feel about that?"

+ +

And it's not to say that you're just trying to steamroll over them. It's that you're trying to share your experience and get on the same page and trying to get them on your page so that you're all making the decision together, not just handing it back and forth across the wall.

+ +

STEPH: Yeah, and that was really well said where I think the more that you do collaborate with others and the more that you make decisions with others, the more context you're going to have for why someone else is making a decision, what challenges they're facing. And so again, it comes down to having more information about what that person is going through to then help you be able to be empathetic because I don't think this is a skill you can just turn on. If you don't know anything about somebody, you don't know anything about what they're going through. Being empathetic is going to be incredibly hard.

+ +

And in this question, they mentioned that they're better at it in some contexts, at certain times with certain personalities. And I think that makes sense because anyone that's more like you, I think you're going to find it easier to be more empathetic. And anyone that has had similar situations, ones that you can relate to, you're going to naturally be more empathetic to.

+ +

Also, timing is important. Maybe it's the end of the day, and you have already used up your empathy bucket, and you have nothing left to give. And that's just something to be aware of. You may have reached that threshold. And with practice, maybe that bucket will get bigger, and you will have more empathy to give throughout the day. But just be aware when you've also hit that threshold, and maybe you don't have any more to give in that moment. But I do think it's very much a skill that you build with a lot of practice.

+ +

EDWARD: Yeah, it's absolutely a muscle. You're totally right. You are trying to do it, and the first time you do, it will be very hard. You will be very drained. And you need to recognize that that's okay. You can step away and come back the next day, and it will get a little better. But that's a wonderful point.

+ +

STEPH: There is a really nice example that you have captured in a thoughtbot blog post that will be sure to link to in the show notes that highlights how difficult it can be to communicate the tone of voice and even how impactful that can be for someone who is reading that message that you have sent, and they don't understand that tone of voice.

+ +

EDWARD: Yeah, that post was very focused on trying to bring in emotion to a more or less emotionless conversation, which is often text. It's very hard to understand when someone is being sarcastic or angry or bubbly or whatever. Just even silly things like adding emojis can really help in that process of bringing in more emotion and getting that tone across.

+ +

And I'd say finally to this person who asked the question that the fact that you're thinking about it is already an empathetic thing. Just the fact that you want to get better at this shows that you're already empathetic, and that's really great to hear.

+ +

STEPH: Yeah, I think that's a really great observation, and I think that's a perfect note for us to end on. So thank you so much to the person that shared this question with us. It is a very interesting question. And I applaud you for being so thoughtful about how to be empathetic with everyone around you.

+ +

Edward, thank you again for being a guest on the show. For those that are interested in following more of your work or checking out your alternative frontend, where can they find out more about the life of Edward Loveall?

+ +

EDWARD: You can find the alternative frontend called Scribe; it’s scribe.rip. You can find me at edwardloveall.com. And I have links to various social media or email if you want to email me or whatever. And yeah, it's been a pleasure. Thanks for having me, Steph.

+ +

STEPH: Thanks so much. On that note, shall we wrap up?

+ +

EDWARD: Let's wrap up. Ta-ta, Stephanie.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Fellow thoughtboter Edward Loveall joins Steph to cohost and talk about alternative frontends and his own that he created: scribe.rip: an alternative frontend to Medium, learning about what it's like to be a manager/non-IC, and helps answer a listener question re: how do you think about empathy in your work?

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And this week, Chris is taking a quick break. But while he's away, we have a guest on today's show. Today's guest is fellow thoughtboter, and wonderful friend, and British accent enthusiast Edward Loveall.

+ +

EDWARD: Oh, hello, Steph. It is lovely to meet...No; this is not my real accent. Anyway, hi, friends. [chuckles]

+ +

STEPH: [laughs] Hello, British Edward. I am so excited to be chatting with you today. Are you going to maintain that accent throughout the whole episode?

+ +

EDWARD: No. There's no way I could do that. I need a lot more professional actor training to be able to maintain quality of that level, I think.

+ +

STEPH: That's fair. I won't hold you to that standard. I was reflecting on preparation for this chat. I've been thinking about all the fun that we've had together, the time that we have worked together at thoughtbot, all the remote coffee walks that we have gone on together as we've talked through consulting challenges or coding challenges. And I realized that we have never worked on a project together, which is wild to me.

+ +

EDWARD: Huh. Yeah, I think you're right. That is wild. Because I've been here three and a half years, and you've been here even longer than me. So in three and a half years of overlap, we've never done that.

+ +

STEPH: And yet we've still always found ways to hang out.

+ +

EDWARD: We make it a priority, you know.

+ +

STEPH: I think we need to...we might have to bribe somebody for us to get on a project together.

+ +

EDWARD: I'm pretty sure we know the person to bribe.

+ +

STEPH: We do.

+ +

EDWARD: We can go talk to our boss and make that happen. One thing we've both done in our career here at thoughtbot, too, is we have gone from individual contributor to being a manager, which is a cool transition.

+ +

STEPH: That's a really good point. That is fun that we have embarked on that journey together. I was very much encouraged to become a team lead, and that was very helpful. Because I'm the type of person where I'm not sure I would have put myself up for that role. I'm very thankful that others encouraged me to do so because I really love it. There are certainly challenges with being a team lead. But overall, I have very much enjoyed the role.

+ +

Just to provide some context for being a team lead a thoughtbot, because I feel like those management roles tend to differ from company to company as to the level of responsibilities that you have. So for us in particular, it's really focused on leading a team of developers, usually two to three developers, and conducting regular one-on-ones to ensure that they are fulfilled and are successful in their projects and their growth at thoughtbot. And then helping them become senior developers if they're not already and essentially coaching them through difficult development and consulting scenarios.

+ +

EDWARD: Yeah, there is still an expectation that you are an individual contributor in some form on client projects. It is not just a management position.

+ +

STEPH: Yeah, that's a good point. For me, that context switching is often what makes it challenging but yet also helps me still feel that I can coach somebody and that I can have one-on-ones because I am still in the trenches. I'm still contributing to client projects. And so, it really helps me still stay in touch with the work that's being done and the struggles that people will face. Let me say again I am positive I wouldn't have pursued this path if I lost my IC status. I really like that part of the role. That's really a split. How about you?

+ +

EDWARD: Yeah, and I still do. We've been experimenting. So thoughtbot generally does four days a week on many projects. So we do four days a week with our client, and then we do one day a week as investment. And team leads, at least on the team that we are on, have been experimenting with just doing three days a week on a client, one day dedicated towards team lead, and then one day for investment. I like that split so far.

+ +

We're still seeing how it goes, still pretty early on in that experiment. But I've enjoyed continuing to be in the trenches, as it were, and working sometimes with the people that report to me so that we can really grow in the same way. There's a lot of context shared there. And that's been really wonderful.

+ +

STEPH: Yeah, I have some specific questions I'd love to ask you about that shift in schedule. Because in some of our meetings, there has been discussion about that ability to context switch between I'm only billing three days now instead of my typical four. And I now have more time to focus on team lead priorities, but then that also means I lose a day with client work. And so there's that battle going back and forth between focusing on client work and also focusing on team lead work. So I'm going to leave that as just a teaser because I want to come back to that.

+ +

But I'd really love to circle back to earlier in the year when you were thinking about becoming a team lead and correct me if I'm wrong, but I think you were pretty hesitant about it. And you were still deciding if it was something you wanted to do. Do you recall what helped you make up your mind as to which path you wanted to take and why you chose this one?

+ +

EDWARD: Yeah, that's a great question. I did also get some encouragement, a pretty light encouragement from a previous co-worker. And that was helpful, but I turned it down initially. Someone asked, "Hey, are you interested in this?" And I said, "Nope, definitely not." And, I don't know, a year-ish later, I then ended up applying.

+ +

And I think what happened in the intervening year was that I started to naturally do some of the work of a team lead primarily, checking in with people and talking with them, pairing with them on things more regularly. So I felt as if I was already doing some of the work, not exactly running a one-on-one, not getting people promoted necessarily. But I cared about the people I was working with and wanted to see them grow and be happy and thrive. That realization helped me think, oh yeah, I'm just kind of doing this. And I should maybe apply for this role.

+ +

STEPH: Wow, that resonates so much. I've heard that from other folks, too, as they have progressed into team lead or other management roles is it was often they already felt like they had started doing some of the work, or there was some natural inclination to start taking over those activities. And so then it felt right to then actually acquire that title and take on those responsibilities officially.

+ +

Well, how's it been going? You had almost a year now. So you had some of those hesitations at the beginning. How's it been? What do you think of being a team lead?

+ +

EDWARD: Yeah, I'm really enjoying it. It is a challenge like you said. But that's every job, right? Every job should be a bit of a stretch. So I did come into it with some natural inclinations of wanting to talk to people and check in with them. But there are all these other pieces that I wasn't good at. One thing that has been really challenging is instead of completing things myself, being that individual contributor, is trying to coach and sponsor people to do something that I would do.

+ +

And I think the hardest part about that is they may not be as far along in their career as you are. And so it is hard to watch someone struggle in the way that you used to struggle without saying, "Oh, here, let me just do that for you.” And I think what I started to realize is that the efforts that I'm putting in I can really be a force multiplier and end up effecting more change than what I could do by myself.

+ +

Like, if you think about it, I have four reports right now, and they're all really smart and talented people. But let's just say they were half as good as I was. That is definitely not true but just go with the numbers here for a second. If I could teach them to do what I do, even if they were half as fast as me, because there are four of them, they can get two times the work done.

+ +

The math adds up in a way where if I can unblock those people, help them just get to the next one little step, do whatever it is that they need, they're going to do way more than I could by myself. And really wrapping your head around that and the advantages there is so hard but so rewarding once you figure it out and get it going.

+ +

STEPH: Do you feel like anybody told you that up front going into taking on some more management responsibilities? Or is that something you learned as you went?

+ +

EDWARD: I definitely learned that as I went. I got some great advice from Josh Clayton, who we work with, and he's been a manager for a long time. And that's a lot of how he thinks about it. And he encouraged me to do things like pairing with everybody on the team or running little workshops to teach, to fill in knowledge gaps for people asking questions, instead of giving answers, to help them find their own answer. And that's all been really, really helpful.

+ +

STEPH: Yeah, that's one of the things that I have valued very much about our culture. I've seen some other companies struggle with is that when someone does get elevated into a management role that they still need support. They still need to be coached. And they also need room to make mistakes and grow.

+ +

And at thoughtbot, I feel that we have been very supported and where there's someone that I can still get mentoring and coaching from. And I can learn to be a manager on the job versus I'm not just put in a position where I'm going to fail or just put there without the expectation that I still need to grow as a manager and as a person as well. So that has helped me out tremendously as well.

+ +

You highlighted the idea of pairing more with others and then asking more questions around providing answers. And as you're learning those skills or as you've acquired those skills for being a team lead at thoughtbot, have you found those skills also transition well to client work?

+ +

EDWARD: Yeah, they do. There's a lot of overlap, especially around gaining trust with somebody. I'm gaining trust in one-on-ones, but I'm also gaining trust with my client or helping my client understand something. This gets a little more into the client-side of it. But a lot of times in client work, I'm looking to bridge a gap. I understand something because of my consulting experience, and they want my knowledge and consulting experience. But it's hard to just go in and say, "Do X or do Y."

+ +

And in the same way, with somebody who's reporting to me or who we're having a one-on-one, it's not usually very helpful to just say, "Do this, do that." You want to help them understand the why and bridge that knowledge gap to get to where you want them to be and where you think they should be. Those really do go hand in hand, and I have used a lot of the same skills.

+ +

Giving feedback also has been a huge thing to share. It's really, really hard to give critical feedback to somebody. It's very easy for them to shut down and not take the feedback, which is the opposite of what you're trying to do. And the same can be with clients. Like, they've gotten to where they've gotten to because of whatever they've done in the past, and trying to show them why what some of the things they're doing is maybe not ideal is really tricky without triggering that flight or fight response. So yeah, there are lots and lots of crossover to answer your question. [chuckles]

+ +

STEPH: I get so excited when clients that have brought on thoughtboters recognize that we are there temporarily, that we bring an outsider perspective. And they will set up essentially reoccurring; maybe it's weekly, maybe it's monthly to say, "Hey, give us feedback. Let us know what are you seeing? What do you think about the team? What do you think about our processes? What would you like to change?"

+ +

And I don't mean just in a retro setting that you're having with the team, but it may be meeting with leadership of that company to give them that feedback directly. And that's awesome. It's rare because, I mean, that takes confidence on their part to be able to say, "Hey, give us all of your feedback, constructive, positive, whatever it may be." But I feel like they get so much value out of doing that where they really get to leverage the fact that they have brought in these external members. And they get to hear from them as to how things are going and insights that they may be missing or not hearing from their people otherwise.

+ +

EDWARD: Agreed.

+ +

STEPH: Circling back to the manager IC path for a moment, I have a question for you because I often find myself asking this question to me or sometimes other people asking this question. But how do I know which path to follow? How should I explore do I want to be a manager? Do I want to continue and invest in my individual contributor skills and really lean into that path? Have you found any resources that have really helped you or ways that you coach others through that scenario?

+ +

EDWARD: I probably don't have a very interesting answer just because I'm going to mostly repeat what I think I said. But I think it's still so relevant and valid, which is, do you find yourself doing some of the work that a manager does? And it doesn't necessarily have to be the thing that I did, which was reaching out to people and checking up on them and seeing how they're doing. It could be that you really, really like running big team meetings or something like that. You just get a kick out of doing that kind of work. Or maybe you really enjoy working less on yourself and more on the group around you. That could also point to more of a technical leader. It doesn't have to be a person leader.

+ +

So I think I would look for where you find yourself wanting to effect change and figuring out if that fits into a manager role or not. And I've had people tell me they definitely do not want to be a manager, and they know that for sure and people that are on the fence. And I think that's another useful thing is to ask your manager what they do as the job and see if that's interesting. See if any of those things spark joy for you, as it were.

+ +

STEPH: I love the approach of just flat out asking your manager or someone that you see where perhaps you would like their role and saying, "Hey, what's your day like? What do you do? And can I be part of more of your day just to see if I would be interested in this type of work? Essentially, can I shadow some of the meetings that you're in?" I really like that idea.

+ +

And I think in the past, I would have been more hesitant about this approach. And it certainly depends on your company's culture. But there's a part of me that's like, just try it out. Like, if someone is encouraging you to go for a management role or to go for maybe it's a stronger individual contributor role, maybe it's being a principal engineer or something else, but if there's someone that's already there encouraging you or if it's just yourself and you are your own cheerleader, then go for it. Try it out. See if you like it. Take some notes. See if what you thought the job was going to be like actually matches reality. Because then, at the end of the day, you can always decide to change your path.

+ +

And if you are at a company that supports that type of experimentation, then you can step back to your current role if you decide that you don't like it. Or you might find that there's a really nice mix in there. But I feel like, with time, I'm getting a bit more bold with strategies in terms of just trying things out, even when it comes for technical challenges as well. Like if there's something that you're really nervous about or there's some big technical problem or something that the team is working on, and you're really skittish and nervous about it, just go ahead and say, "I'll do it, or I'd love to work with somebody on it," and then try it out and take some notes, see how it goes.

+ +

EDWARD: You could be really sneaky too. You can say to a colleague, "Hey. You want to get lunch?" And like you turn that into a secret one-on-one. Or you offer to run the retro board during retro, or you step up for doing a bunch of pull requests that week or something like that. You can try these little test things without even having to let somebody know or committing to anything publicly or even privately. Just really internally to yourself, you can try to take some of those steps.

+ +

STEPH: I like the sneaky success ladder. People won't talk about that one as much. [laughs] That's how I definitely found out that I didn't want to do sales. There was someone that I was talking to that was interested in working with thoughtbot, and Josh Clayton was very supportive of like, "Do you want to come along and be part of the conversation?" I was like, "Yeah, sure." And so I went along, and it was fun. But I definitely walked away like, yep, I don't want to be part of sales. I really like everything else minus this part. [laughs]

+ +

EDWARD: Yeah, it's good to know. It's good to know.

+ +

STEPH: Circling back just a bit to something you said earlier, you had mentioned that as you were becoming a team lead, you realized that helping others be successful at their job was really then what led to you feeling successful as well and that you could be a force multiplier. And you'd mentioned that a lot of that work comes down to bridging knowledge gaps.

+ +

And I'm really curious because this is something that we're always working on at thoughtbot. We are looking to identify what skills people would really like to learn. How can we help people learn those skills? And I'd love to know more. How do you go about this? How are you helping people bridge those knowledge gaps?

+ +

EDWARD: Yeah, so that is a doozy of a question. I have a couple of different answers. First is something I talked about before, building trust. And there's a bunch of different ways to do that. And I see trust as the foundation of almost everything in consulting. If you don't have that trust, it's really hard to deliver feedback like we talked about. It's hard to bridge that knowledge gap. Because effectively, nobody knows who you are, and what you're doing, what's going on, why you are coming to talk to them. It's really strange. And we can come back to how to build trust.

+ +

But once you've built that trust, I approach bridging that knowledge gap in a couple of different ways. One is asking questions instead of giving answers. The goal behind this is I want them to think about their goals. And that will often help lead them to some answer to bridge that gap that we have. I have some idea. They have another idea. If I can ask the right open-ended question, they will walk themselves across and get to where I want. Now, that doesn't always work.

+ +

Another strategy I've found is outlining a bunch of different possible solutions and their pros and cons. That has done two things. One, it helps them understand where I'm coming from, what my goals are in relation to what they're trying to do. And another one is that actually tends to gain a lot of trust. In the meantime, you're showing your expertise. You're showing that you're really considering all their problems.

+ +

Because almost every solution has trade-offs, there's very rarely a silver bullet. And so it's really helpful to say, "Well, here's the pros, here's the cons. Here's where I think you should go, but you know your business better than I do. And I've outlined all the things here. So whichever way you want to go forward on this, let's do that. And let me help you get there."

+ +

Joël and I, a colleague that we both cherish dearly, we did that on a project recently, and it was really, really successful. We put a lot of work in and helped them get to a really difficult architecture decision. And it could have gone one of, I think, four different ways. And we were sort of vying for one. They were vying for another. And we found a couple more in the middle, and I believe we went more towards the middle. And we were both pretty happy with how that turned out.

+ +

STEPH: I really, really like how that approach gives someone so much autonomy, and they're part of that decision. So you're not just saying, "Hey, you need to do this," and then just following through with it. But instead, it's saying, "I think I've heard everything. I think I understand the different problems that we're facing. Here are my suggestions, but you still have more context. What do you think, or which option would you like to pursue? I really like that option."

+ +

EDWARD: Yeah, because you're always writing this line as a consultant of like, they did bring you in for your skills and expertise and theory. But you really want to level them up so that they can make the right choices because that ultimately is...like, their success is your success as a consultant. That's the job in a lot of ways.

+ +

And so yeah, giving them the tools they need to make the right decision is so often the job. And I think that can get lost in the shuffle of, oh no, we have to meet these sprint goals. Or I got to get this ticket done or this bug fixed or something. And stepping back to get them to a better place is another goal that you can get to down the line. It's not to say shipping tickets is bad [laughs] or getting the sprint goals is bad. It's just another facet. Have you had any aha moments in consulting?

+ +

STEPH: Oh my gosh, I have had so many aha moments. I think most of them, for good or for worse, are here on The Bike Shed, or at least they've been shared here on The Bike Shed. [laughs]

+ +

EDWARD: Yeah, you should write a book of them all.

+ +

STEPH: Could we just grab the...I'm lazy. Can we grab the transcripts? We'll just turn that into a book.

+ +

EDWARD: [laughs] Yeah, just put it all together, call it The Bike Shed Diaries.

+ +

STEPH: Yeah. Oh, I like it. Okay, all right, that'll be next week's task. We'll publish The Bike Shed Diaries. [laughter] Specifically, in terms of bridging aha moments for helping someone bridge knowledge gaps or even for myself is I will often focus on what skills do you need today to make your job easier? What challenges are you facing? And also, what skills would you like to have six months from now? So that way, you are meeting the needs and the requirements that you really need today to fulfill your job.

+ +

But then also six months out, we're still looking towards the future. Maybe that's also more job requirements related, or maybe it's just for personal growth, or the areas that you're really excited about. You really want to contribute to an Elixir, open-source project, or something more specific that contributes to your fulfillment.
+So when it comes to knowledge gaps, those are often the questions that I'm asking are, what do you need this week to make your job easier and to make your life easier? And then where would you like to be in terms of what skills would you like to have six months from now or what concepts? It may even be too lofty to say what skills because that could be huge to say that I want a whole new skill to be able to work in a language. So maybe it's something that's more specific of like, I'd really like to understand forms a bit better six months from now, or I'd really like to feel a little more confident with SQL, or maybe you'd like to take a look at Arel, things like that.

+ +

And then set those targets and then check in to say, "How's it going? How do you plan to learn these skills? Would you like help learning these skills? What are some resources?" Because I am not always the person that can help someone acquire that knowledge. So in that role, I'm often a facilitator where I will say, "Cool, you want this. You're interested in this particular skill. I don't know that skill. But I do know someone else who's really good at this. So let's get you all connected, and then you can work together on this."

+ +

EDWARD: And to dovetail a little bit with that manager individual contributor piece we were talking about before, that's another piece we didn't really talk about, which sounds like sponsoring. It's not just you doing the thing for your report or even coaching them necessarily. It's how can I get my report into a situation where they can exercise that skill or connect them with somebody who can help them with that thing? I'm still working on that one, honestly. That's a really, really difficult one. That's not something that comes naturally.

+ +

STEPH: When you say that's the part that's still challenging for you, is it the connecting of one person to someone else to learn a skill? I'm curious to hear more about which part of that is challenging for you.

+ +

EDWARD: I think I don't always think of sponsorship as a tool that I can lean on. It just doesn't come to mind as naturally. I think the very natural thing to do is mentor first, which is like, here's what you should do. It's kind of giving somebody a fish. Coaching then is more like teaching them how to fish. And then I don't know if we're going to extend this analogy farther. Sponsoring is like you're going to open up your own fishing teaching school or something. [laughs] And that just doesn't always occur to me.

+ +

I don't necessarily think like, oh yeah, like my friend over here could totally teach you about this technical skill that you're trying to learn or set you up to speak at a conference or something like that. It's a much different level of being a manager that I'm just not used to yet. I'm getting better at it. But it doesn't come naturally.

+ +

STEPH: Yeah, that's a very powerful form of managing someone as well because then you are helping that person go beyond their current bubble of who is their manager in their team and then helping them shine in other circles. And that's incredible and also something that I am always working on getting better at.

+ +

EDWARD: Let's get better at it together.

+ +

STEPH: We can do it. Also, when you mentioned opening a fishing school, I definitely pictured fish in a school in front of a chalkboard and someone's writing on that board and little fish in their school seats learning.

+ +

EDWARD: [laughs] A little Finding Nemo action.

+ +

STEPH: You got it. [laughs] You know your fishing school. You got to learn to stay away from those hooks.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So pivoting just a bit on a slightly more technical note, you've been working on a side project called scribe.rip R-I-P. And I've heard a bit about it, but I would love to hear more. Could you tell me more about that project that you're working on?
+EDWARD: Yeah, sure. So Scribe is what I would call an alternative frontend. And specifically, it is an alternative frontend for medium.com. The goal of the project is to give people a tool to read the Medium articles, not on medium.com, which might sound like a strange goal. [laughs] I'm happy to go into a little bit of a lie there. But that is the tool. And yeah, the domain is scribe.rip, mostly because that was a cheap domain. [laughs] So I got it and put my project there.

+ +

STEPH: I like that phrasing that you're using, alternative frontends because I think when you had first mentioned that, when I'd heard that in other conversations, I was like, oh, what is that? And I didn't know what it meant. But now, when you put it into some context, that makes all sense. I am intrigued. Why would someone be interested in using an alternative frontend versus, say like, there's an article on Medium; I'll just read it there. What might inspire me to want to use Scribe instead?

+ +

EDWARD: Definitely. There's a bunch of different reasons. The alternative frontends cover a pretty broad ground. But I'd say the most common reasons that someone might want to use one are privacy if they're worried about the main service, whatever that might be. Let's say Medium, in this case, is doing something with their user data that they'd rather they not do, potentially a better experience on that service. If you don't like the way Medium's articles look, you might want to see them in a different way. It can also be a way to vote with your actions, saying that this is the kind of web that I want to see if you don't like in general what a platform is doing.

+ +

And if you think a platform is potentially even harmful, it can be a way to say I don't want to support that platform, but sometimes I find myself needing to interact with it in some way. The alternative frontends can be a tool for that. On the very cynical angle, you can also go to you don't want to see ads. And sometimes, these are ad-supported platforms. Alternative frontends can get rid of those ads. And so that's another way too. I'm conflicted more about that one. We can dive into that.

+ +

But those are the most common reasons I've seen that people want to use alternative frontends. And to be clear, Scribe is not the only alternative frontend out there. There are frontends for YouTube, for Twitter, for Instagram, for Reddit. There's a huge list of a bunch of them, but those are some popular ones.

+ +

STEPH: Oh, that's really cool. I've never used any of those before. Will be sure to include some links in the show notes so people can check those out. And you listed some really interesting reasons for why folks might want to use an alternative frontend. I'm curious, to make this possible, though, does it mean that the service that is hosting that content do they have an open API into which then you can pull that content? How is an alternative frontend possible?

+ +

EDWARD: It is possible through APIs almost always. In some form or another, the APIs aren't necessarily open. One interesting side effect to many of the JavaScript rendered apps is that they often talk to some API in the background. And that can often be used to get the content in a more computer-friendly way. And so, with Medium, in particular, they don't really have an open API. So I ended up trying to figure out their API in the background that they're using to fetch articles and was able to get the content and display it in a different way.

+ +

STEPH: So everything you're describing sounds really interesting. I feel like I do have to ask the question, is it okay that these alternative frontends are taking content and are essentially rendering content but then not using the original service in which the content was published? How do you feel about that aspect?

+ +

EDWARD: Yeah, it's a really interesting question. There's a bit of a moral argument here, and I think everybody has to make that call for themselves. I think every platform if it gets large enough, is going to have people that don't want it to exist for some reason. I think, in some ways, providing alternative frontends is a bit of a release valve for that platform. Not to say that the alternative frontend explicitly helps that platform, but I imagine it gives people literally an alternative to then use instead and can make a peaceful, neutral ground in a way. So instead of being forced to use only the official platform, you can now use it at least in a limited fashion outside of that, which may alleviate whatever concerns you have and therefore keep everybody happy.

+ +

And I think honestly, in the long run and in practice, most platforms will not particularly notice the impact of these alternative frontends. Overall, we're talking very, very small potatoes. YouTube is not going after Invidious, the alternative frontend for YouTube, because it's probably a drop in the bucket. Nitter is not getting cease and desist from Twitter. Instagram is not sending a cease and desist to Bibliogram. These are some of these alternative frontends. And I think that's just because it's okay. They don't mind. It's so small. And it's giving people what they want in a way that is not harmful enough for it to really matter in the long run for them.

+ +

STEPH: Interesting. Because yeah, as you'd mentioned earlier, I think most people are going to continue to use that main service because that's what they see advertised. And it's more well-known, and it's frankly easier to go to. But then for folks who do want a little bit more control over their experience and they still want to access someone's content. So it is interesting.

+ +

You still want to ensure that the person who created that content always gets recognition and ownership of the content that they have. And in this case, that very much still applies. If I wrote an article on, say, Medium, but then I'm using Scribe to be able to read that content, it's still known who wrote the article. But this way, you are perhaps opting out of something else that service is doing, maybe if they have some type of tracking or something that you're not comfortable with. But you still want to be able to appreciate that person's content, even though they're perhaps only able to publish on Medium for right now. Or they're still looking for more ways to publish their content for folks who would like alternative ways to consume their information. Yeah, it's an interesting spot.

+ +

EDWARD: Right. And some ways that I think Scribe can provide a slightly better experience are trying to highlight the author more than the platform. The only time it says Scribe on the website is on the homepage. If you go into an actual article, I don't put branding or anything like that. Because I think I really want people to have their work speak for the author, not for the platform, and that's really important to me personally. And that might not be important to you, and that's okay.

+ +

Maybe you use scribe because it supports dark mode or something like that, and that's totally fine too. I don't mind at all. There are many aspects on which an alternative frontend can provide for people that the official platform doesn't. In some ways, it's augmenting their features, but in some ways, it's just giving people a bit more choice. And I think that's important.

+ +

STEPH: I have found since you'd mentioned the side project, that I've started using it more to read content. And I have found it helpful because it really silences all the noise because a lot of services want you to see ads, and they do want you to click on more articles that are related to the thing that you're reading. And so, I do appreciate the simplicity that it brings to the content. So then I can really just focus on that one article that someone has written. Overall, it seems like a really neat project.

+ +

EDWARD: Yeah, thanks. I'm glad you enjoyed it.

+ +

STEPH: Pivoting just a bit, I would love to go on a slight adventure and answer a listener question with you. What do you think?

+ +

EDWARD: Yeah, let's do it.

+ +

STEPH: All right. So this listener question focuses on empathy in your work, and this person writes in, "I'm curious how you all think about and notice empathy from yourselves and others around you. Empathy is so helpful and critical for making and maintaining healthy, productive relationships. I've noticed that the way you frame your client engagements, empathy sounds to be at the heart of them. For myself, I've noticed I'm better at it in certain contexts and certain times and with specific personalities, more so than others. More concretely, how do you stay empathetic with your clients and with cross-functional teams like product or design or even yourself? Can you teach or increase your empathy? And if so, what have you found successful in these situations?

+ +

So, Edward, this seems really on topic for some of the things that we were discussing earlier. So I'm going to hand it over to you first and get some of your thoughts.

+ +

EDWARD: This is a really great question. There's a lot to unpack. And one question they asked was, can you teach or increase your empathy, and if so, what have you found successful in what situations? I have found that being vulnerable both publicly and being empathetic publicly is a really useful tool.

+ +

A lot of teams don't communicate very publicly; it's a lot of stuff in private messages. Being vulnerable publicly in a big team channel can really open the door to letting other people be vulnerable and see what other people are doing, understand what people are feeling. And that's really at the heart of empathy is understanding someone else's point of view.

+ +

I've also found that starting small, like, just do it with your close co-worker. Maybe try to effect just change with them. And then once you've gotten them on board, broaden it to two other people, and then two more people, and then two more people, because it's really hard to take that leap of faith and be vulnerable by yourself. So I totally get that.

+ +

And also trying to take this on really early in someone's career or someone's tenure at a job. Offer to help new people to your team. Work with them, so they just start off with a very empathetic experience. And that can grow into a more empathetic team as a whole. Encourage team members to update documentation on their first day because they're learning so much in those first few days. Once they've learned it, the only reason they want to document it is because they have empathy for that next person. And so, just like setting that baseline and that boundary, I think is super helpful. What do you think?

+ +

STEPH: Yeah, I think those are some great examples. I really love that one way to acquire more empathy is to go on a journey with someone else. So if you have someone new that's joining the team, be their onboarding buddy. Go through that journey with them so you can understand what they're going through, what challenges they are facing. And that will boost the knowledge that you have and will likely also boost then the empathy that you have for people that are new to the team or for future onboarding buddies if you realize that there are some processes that really need to be smoothed out.

+ +

I also think it's worth highlighting that I don't think empathy is a single skill. I think it's a number of things. It can be the ability to feel someone else's emotions, so you can understand what someone else is feeling at that moment. It could be reasoning about another person's perspective, or it could be just, frankly, wanting to help. So I think there are a number of ways that we can demonstrate empathy to someone else. And it's going to depend on the situation as to which one of those skills is going to be helpful.

+ +

For how you stay empathetic with clients, that one is a really interesting one just because the way we work with clients; we do get to go on that journey with them. We are with them in making decisions around priority and technical decisions and what pain points they are feeling. So I think going, as you described earlier, going on that journey with someone is what helps us stay empathetic with our clients. And I think that's true for cross-functional teams.

+ +

So if you are working with someone that's maybe on customer support or on the design team, it could be grabbing lunch with them and saying, "Hey, what's your day like? What challenges are you facing?" Maybe it's your company has rotations where you actually are part of the customer service team for a day. So you get to respond to tickets and have more of an understanding.

+ +

I'm realizing there's a theme here. I feel like a lot of it comes down to stepping into someone else's shoes and seeing the world from their perspective and not just seeing it but experiencing the world from their perspective.

+ +

EDWARD: Yeah. And another way to do that...because that can also take a lot of time. It's a hard ask potentially to say, "I'm going to go be a customer service rep for a day," if your job is also, I'm going to be a programmer and ship features or fix bugs. That's hard to do. And I think there are ways to do that, to experience what someone else is experiencing by trying to take on not necessarily the role of the other person but just trying to support the other person in their role.

+ +

So, for example, we see teams become really siloed where the product is solely responsible for writing tickets, development is solely responsible for understanding what makes the code work or fixing a bug, and design is only responsible for user interactions. I found it really, really helpful to try to approach design and say, "What's the goal here with this user interaction?" I don't know. I'm not a designer.

+ +

And so, how can I ask them and again bridge my own knowledge gap? Because that can really help you get to that point and help them understand maybe what you're going for and say, "I wasn't going implement it like that because I thought X, Y, and Z." And they go like, "Oh, I see what you're saying." And then now you're making those barriers…or maybe when you're working with products, they're like, "I see what you're trying to do here. But in my experience, I've seen websites like this. How do you feel about that?"

+ +

And it's not to say that you're just trying to steamroll over them. It's that you're trying to share your experience and get on the same page and trying to get them on your page so that you're all making the decision together, not just handing it back and forth across the wall.

+ +

STEPH: Yeah, and that was really well said where I think the more that you do collaborate with others and the more that you make decisions with others, the more context you're going to have for why someone else is making a decision, what challenges they're facing. And so again, it comes down to having more information about what that person is going through to then help you be able to be empathetic because I don't think this is a skill you can just turn on. If you don't know anything about somebody, you don't know anything about what they're going through. Being empathetic is going to be incredibly hard.

+ +

And in this question, they mentioned that they're better at it in some contexts, at certain times with certain personalities. And I think that makes sense because anyone that's more like you, I think you're going to find it easier to be more empathetic. And anyone that has had similar situations, ones that you can relate to, you're going to naturally be more empathetic to.

+ +

Also, timing is important. Maybe it's the end of the day, and you have already used up your empathy bucket, and you have nothing left to give. And that's just something to be aware of. You may have reached that threshold. And with practice, maybe that bucket will get bigger, and you will have more empathy to give throughout the day. But just be aware when you've also hit that threshold, and maybe you don't have any more to give in that moment. But I do think it's very much a skill that you build with a lot of practice.

+ +

EDWARD: Yeah, it's absolutely a muscle. You're totally right. You are trying to do it, and the first time you do, it will be very hard. You will be very drained. And you need to recognize that that's okay. You can step away and come back the next day, and it will get a little better. But that's a wonderful point.

+ +

STEPH: There is a really nice example that you have captured in a thoughtbot blog post that will be sure to link to in the show notes that highlights how difficult it can be to communicate the tone of voice and even how impactful that can be for someone who is reading that message that you have sent, and they don't understand that tone of voice.

+ +

EDWARD: Yeah, that post was very focused on trying to bring in emotion to a more or less emotionless conversation, which is often text. It's very hard to understand when someone is being sarcastic or angry or bubbly or whatever. Just even silly things like adding emojis can really help in that process of bringing in more emotion and getting that tone across.

+ +

And I'd say finally to this person who asked the question that the fact that you're thinking about it is already an empathetic thing. Just the fact that you want to get better at this shows that you're already empathetic, and that's really great to hear.

+ +

STEPH: Yeah, I think that's a really great observation, and I think that's a perfect note for us to end on. So thank you so much to the person that shared this question with us. It is a very interesting question. And I applaud you for being so thoughtful about how to be empathetic with everyone around you.

+ +

Edward, thank you again for being a guest on the show. For those that are interested in following more of your work or checking out your alternative frontend, where can they find out more about the life of Edward Loveall?

+ +

EDWARD: You can find the alternative frontend called Scribe; it’s scribe.rip. You can find me at edwardloveall.com. And I have links to various social media or email if you want to email me or whatever. And yeah, it's been a pleasure. Thanks for having me, Steph.

+ +

STEPH: Thanks so much. On that note, shall we wrap up?

+ +

EDWARD: Let's wrap up. Ta-ta, Stephanie.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-15OoTd9 + + ]]> + + Steph Viccari + + + 317: Burn The Ships! + https://bikeshed.thoughtbot.com/317 + a0356168-869b-49d3-832a-8eb0a9c4baf0 + Tue, 30 Nov 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph gives an update about RSpec focus and how she often forgets to remove the focus feature from tests. She figured out two solutions: one using Rubocop, and the other from a Twitter user, suggesting using a GitHub gist. She also suggests that if you're one of those people who misses being in an office environment, you check out soundofcolleagues.com for ambient office noise selection. + +Chris has been struggling to actually do any coding and is adjusting to doing more product management and shares some strategies that have been helping him. + +They answer a listener question about dealing with large pull requests and how it's hard to recognize a good seam to break them up when you are in the thick of one. + 41:41 + no + + + Steph gives an update about RSpec focus and how she often forgets to remove the focus feature from tests. She figured out two solutions: one using Rubocop, and the other from a Twitter user, suggesting using a GitHub gist. She also suggests that if you're one of those people who misses being in an office environment, you check out soundofcolleagues.com for ambient office noise selection. +Chris has been struggling to actually do any coding and is adjusting to doing more product management and shares some strategies that have been helping him. +They answer a listener question about dealing with large pull requests and how it's hard to recognize a good seam to break them up when you are in the thick of one. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +Twitter note re: rspec-retry (https://twitter.com/jasonrudolph/status/1458416077726158852) +soundofcolleagues.com (https://soundofcolleagues.com) +mailcheck (https://github.com/mailcheck/mailcheck) +Inertia.js (https://inertiajs.com/) +Svelte (https://svelte.dev/) +devise (https://github.com/heartcombo/devise) +clearance (https://github.com/thoughtbot/clearance) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: One day, I'll grow up. It's fine. I look forward to that day. But today, I don't think it's that day. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. Well, in some fun news, Utah started his professional training as of this morning, which I'm very excited about. Because we've been working with him to work on being good with walking on a leash, FYI, he's not, [laughs] and also being good about not jumping on people. And essentially, being a really good roommate. And he started training today, and we are using an e-collar, which initially I was really hesitant about because I don't want it to hurt him in any way. But now that I have felt the e-collar myself and we've had a first day with it, it's going super well. I'm very excited for where this is headed. +CHRIS: That's very exciting. When does he start paying rent? +STEPH: Ooh. I'll have to check with him, or I guess I have set those boundaries. That's my job. +CHRIS: I just figured that's a core part of being a good roommate. But maybe we've got baby steps or doggy steps to get there. But that's exciting. I'm glad [laughs] that the first day of training is going well. +STEPH: Yeah, it's going great. And the place that we're going to the trainer they have horses, and mules, and goats. And so now I have a very cute video of him trying to play with a goat, and the goat was having none of it. But it's still all very cute. +In tech-related news, I have an update for when you and I were recently chatting about the RSpec focus and how I mentioned that I often forget to remove the focus feature from tests. And so then that goes up to a PR, and I have to rely on a kind human to let me know, and then I remove it. Or worst-case scenario, it gets merged into the main branch. And for anyone that's not on Twitter, I just wanted to share an update because I also shared something there. +But the resolution for what I was looking for there's already a rule that's written into Rubocop, but it's specifically written in the Rubocop RSpec codebase. And with that rule, you can essentially just say, hey, let me know anytime that a test is using the focus metadata, and then make sure to let me know and fail. +And then if you don't want to actually include all of Rubocop into your project because Rubocop is pretty opinionated, you can still add Rubocop to your project, but you can specifically add Rubocop RSpec, and then you can say, hey, all other rules disabled by default, but then you can enable that specific rule. So then, that way, you will catch all of your focus tests. +There's also another approach that someone on Twitter shared with us recently from Marz Drel. And Marz shared specifically a really nice simple GitHub Gist that documents or exemplifies that you can add an environment variable that checks to say, hey, if we're in CI mode, then add a before hook. And then that before hook will look for any examples that are using that focus metadata, and then it's going to raise. And then if we're not in CI mode, then don't do anything, don't raise, and carry on. And that's just a really nice simple addition if someone didn't want to pull in Rubocop into their project. +CHRIS: Both of those definitely sound like great options. I don't think we have Rubocop on the current project that I'm working on. But I think the RSpec focus thing, the metadata one, seems like it'll work great. More generally, I just want to thank folks out there who listen to the show and then write back in like, "Hey, this is probably what you want." +There was a similar thread that someone shared around the RSpec::Retry stuff that I was talking about recently and the failure mode there and trying to get that into the Junit Reporter. And so they had some suggestions around that. Jason Rudolph on Twitter reached out, sharing just his initial exploration and thoughts on how it might be possible to extend the XML reports that are generated and capture a flaky test in that way. So that's really interesting. +And again, just really love that folks are listening to the things that we say and then even adding on to them and continuing the conversation. So thanks to everybody for sharing those things. +STEPH: Yeah, it's incredibly helpful. And then one other fun thing that I'd love to share, and I found this out from someone else at thoughtbot because they had shared it recently. But it's a neat website called soundofcolleagues.com. And I know you've got your laptop in front of you. So if you'll go visit it, it'll be neat to see as we're talking through it. For anyone else that wants to pull it up, too, we'll include a link in the show notes. +But it's a neat project that someone started where you can bump up the sounds that you would normally hear in an office. So maybe you want to bump up background noise of people or an open window. There's one specifically for printers and a coffee machine, and keyboards are on there as well. [laughs] I have discovered I am partial open window and partial rain, although rain is just always my go-to. I like the sound of rain for when I'm working. +CHRIS: Gentle rain is definitely nice white noise in general. I've seen this for coffee shops, but I haven't seen the particular one. Also, yes, I definitely know how to spell the word colleague on the first of three tries. Definitely didn't have to rely on Google for that one. But yeah, nice site there. I enjoy that. +STEPH: I tried the keyboard option that's on there because I was like, oh yeah, I'm totally going to be into this. This is going to be my jam. I don't think it is because I realized that I'm very biased. I like the sound of my own keyboard. So I had to shush the other one and just listen to the rain and the open window. But that's some of the fun things that are going on in my world today. What's new in your world? +CHRIS: I'm just now spending a moment with the keyboard sound. It's a very muted keyboard. I want a little more clackety. +STEPH: A little more clackety? +CHRIS: I was assuming it would be too much clackety, and that would be the problem. But it sounds more mushy. Maybe we can pipe in some of the sound here [laughs] at this point. Or we can link to these sounds, and everyone can dial up the keyboards to 100. But I, too, am partial to the sounds of my own keyboard. +But what's new in my world? This past week and I think probably even a little bit more of the prior week, I’ve been noticing that I've been struggling to actually do any coding, which has been interesting to observe. And again, trying to observe it, not necessarily judge it, although if that's not the thing that we want to be doing, then try and improve that. But mostly trying to observe what's going on, what is taking my time. A lot of it is product management type work. So I am spending a good amount of time trying to gather the different voices and understand what is the work to be done, and then shape that into the backlog and make sure that that's clear and ready for the team to pick up. +And then, thankfully, the other two developers that are working on the project are fantastically prolific. So they're often very quickly working through the work that has been set up in front of them. And so I'm trying to then be proactive and respond to the code. But there's almost a cycle to it where I'm just staying out in front of them, but they're catching up with everything that's going on. So it's something that I'm trying again to be intentional about, name, share some of that back up with the group. If there are things that I'm doing that I don't uniquely need to be doing, then let's share as much of that knowledge as possible. +But one thing that I will say is the product management, shaping the backlog work is exhausting. I am astonished by just how drained I am at the end of the day. And I'm like, I don't even really feel like I did anything. I didn't write any code, but I am just completely spent. And there really is something to when the work is clear, just doing the work, I can actually find energizing. And it's fun, and I can get in flow state. And sometimes, I'll be drained in a certain way. +But the work of taking a bunch of different slack threads, and communications, and meetings, and synthesizing that down, and then determining what the work needs to look like moving forward, and providing enough clarity but then not over constraining and not providing too much clarity. And there are so many micro-decisions that are being made in there. And I'm just spent at the end of the day, and I have so much...I've always had a lot of respect for product managers and folks that are existing in that interstitial space and trying to make sense of the noise, especially of a growing company, but all the more so this week as I've been feeling some of that myself. +STEPH: I totally agree. I have felt that having a strong product manager really makes or breaks a project for me where even though having technical leadership is really nice, I'd prefer someone that's really strong at the product knowledge and then helping direct where the product is headed. That is incredibly helpful. Like you mentioned, the work is exhausting. +There's someone that joined the thoughtbot team fairly recently, and I was chatting with them about what type of projects they would be interested in working on. And one of their responses was, "I'd love to work on a project with a strong product manager because I have been doing that a fair amount for recent years. And I would love to get back to just focusing on coding." And so I think they enjoyed some of the work, but they just recognize it's exhausting. And I'd really like to just get back to writing code for a while. +CHRIS: Yeah, I'm definitely in that space. And I think there's a ton of value to spending a little bit of time, like having any developer at some point in their career spend a little bit of time managing the backlog, and you will learn a bunch from that. But I'm also in the space of I would love to just turn on some music and code for a while. That sounds fun. There's a lot of work to be done right now. I'd love to just be in there doing the work. But sometimes, out of necessity, the defining of the work is the thing that's important. +And so, I think I've been correctly assessing the most important thing. And that that has consistently for a while now been the defining and responding to the work that's in process as opposed to doing it myself. But, man, I really hope I get to dive back into the code sometime and use my clackety keyboard to its fullest extent. +STEPH: Have you found any particular strategies that really help you with the product management work? +CHRIS: I will say that I think this is a competency. This is a skillset and a career path that...again, I've been at plenty of organizations that I don't think respected the role as much as it should be. But it's an incredibly hard role and multidisciplinary communication at the core of it. And so I don't think I'm great at it is the thing that I'll say. So everything that follows is just to be clear; I’m not saying that I'm great at this, but I have been doing some of it. So here are some thoughts that I have. +I think a lot of it is in reaction to where I felt like the work was clear. So I have a sense of what it looks like when I can go to the backlog, trust that it is in a roughly solid priority order, pick up a piece of work and immediately go to work on it. And understand what are the end-user implications of this piece of work? Where would I start on it like, how technically? What's a rough approach that I would have? And getting that level of specificity just right. So it's not overconstrained, but it's not under constrained. So having experienced that on the developer side, I try and then use that to shape some of the guidance that I'm putting into, say, the Trello tickets that I'm writing up here. +We recently introduced Trello epics, which is I want to say like an add-on. And that allows us just the tiniest bit of product management, like one level up. So instead of just having cards and a list that is like, here's the work to be done, we now have an epics list that is separate to it, and it links between a card and its associated epics. So it's like project and action within that project. +And just that little touch of structure there has been really, really useful to help look at like, okay, what are the big pieces that we're trying to move? And then how do they break down into the smaller pieces? So a tiny, tiny bit of fanciness in our product management tool, not Jira-like not going in that direction yet for as long as I cannot. But that little bit of structure. +And then thinking about what has been useful to me as I pick up tickets. And then, as always, trying to just always be cognizant of what is the user's experience here? What problem am I trying to solve for them? What is their experience going to be? How will they know how to work with this feature? And just always asking that and then framing the work to be done in the context of that. +STEPH: I like how you're adamant about a little bit of fanciness but not all the way to Jira-like. I also like how you highlighted end-users. All of that, I think, is awesome when developers are able to expand their role to experience all the other facets of building software. +CHRIS: Yeah, definitely. I think that whole list of all of the different facets of where our work interacts with different groups. The more empathy or, the more experience that you can have there, the better that you'll be able to understand how to communicate there, how to express things in terms, et cetera, et cetera. So a huge fan of all of those ideas. I am ready to just get back in the code for a few minutes, though. But for now, for as long as necessary, I'll do some of this work. But I am trying to find my way to other things. +In terms of actual feature work that we're working on, one of the things that we're doing right now is restructuring our onboarding. So when a user comes and signs up to the website and then subsequently has to fill out a handful of other forms, there's actually an external system that we've been working with that houses some of the core data of our application. And they have a hosted application form. So we can send the user over to them, and the user fills out the rest of the application on this other system's site. And then they get redirected back to us. And everything's got nice DNS entries for a particular subdomain and whatnot. So it looks roughly consistent. There's some branding. But it's still someone else's UI, essentially. +And we were feeling enough pain from that experience. We were like; you know what? It's time. We're going to bring this back in-house. We're going to do all the forms ourselves. We're going to do a nice progressive little progress bar. You can see all the steps as you're going through onboarding. We're just going to own that more because that's a core part of the experience that we're building here. So biting the bullet, deciding to do that. +But there's an interesting edge case that we run into, which is we are using Devise for authentication. Totally makes sense. We're in Rails context; there we go. It's the thing to use. But Devise exists in truly the Rails world. So like HTML ERB templates, the controllers have certain expectations as to what's going on. So thus far, we've just let that exist in that world and everything else we're building in Inertia and Svelte. But we're just now starting to feel enough of the pain, and that Devise exists in this other context. And for a while, we just kept saying, "You know what? It's not worth the effort to port it over. It's fine." +Because we're using Tailwind, we have a consistent design language that we can use across them. That said, the components are drifting a little bit. And it's like, oh, this one's got a rounded corner like this, and that one's got this color. And we don't have the disabled style. But it is nice that it's not completely distinct. But we have finally decided it is time. We need to port this thing over because we feel like the onboarding and authentication type flows; they’re actually a big part of the user experience or at least the first run user experience when someone's signing up to our site. So we want to own that a little bit more. +One of the things that I ran into as I was trying to introduce Mailcheck, which is a library that I've talked about, I think in a previous episode...but basically, you can have it observe a field and if someone types in like, user@gmaip.com, you can like, did you mean gmail.com? And then go from there. And I think there's more subtlety. They can maybe even look up MX records and things like that. But basically validate an email address heuristically and offer the nice, very friendly to a user, "Hey, did you mean this instead?" So not a full validation that says, "No, you cannot put your email address," because maybe you have a weird one that sounds like Gmail but isn't. But that's a little bit trickier to implement both on the Devise side and then in any other place that we have an email input. +And so what we want to do is port over to Inertia and Svelte, and then everything's in our nice, happy context with all our components and all the other work that we're doing. And it really does just highlight how much I've come to enjoy working with Inertia and Svelte. They are fantastic technologies. And now I just want absolutely everything to be in them. So we're finally going to bite the bullet, and I think port those over a little bit after we get the current batch of work done. But soon, soon, that's the goal. +STEPH: I'm having a bit of déjà vu where I feel like there was a project that you were working on that was using Devise, and then removing Devise and replacing it with something else was a challenge. Does that ring a bell? +CHRIS: Yes, that is accurate. So I had a project that I worked on where we had both Devise and Clearance was actually what was going on. There were basically two different applications that existed; one was using Clearance, the later one used Devise. But then we folded those two applications back together. And by virtue of that, I tried to unify the authentication schemes, and it was like, nope, not going to happen. And then we didn't. +STEPH: And then we didn't. [laughs] I like that ending. +CHRIS: Well, sometimes you don't. [laughs] +STEPH: Yeah, I love that ending because it reflects reality. Sometimes that just happens. In fact, I'm going to segue for just a moment because you're reminding me that there's something I don't think I've shared with you yet. On my previous project, there was a particular feature. It was a big feature that someone had picked up and worked on. +And at one point, we were essentially playing hot potato with this feature because we hadn't gotten it to the point that it was merged. There was too much that was happening in that pull request, although then we ended up merging it. But then we found lots of bugs. And it was just one of those features that we couldn't really get across the finish line. There was always something else that was wrong with it or needed to be done or needed to be considered. +And we'd reach that point where Chad Pytel, who is on the project, was like, "We're either going to finish this, or we're going to throw it away." And I felt a little guilty saying this, and I was like, "I vote we throw it away. I have lots of concerns about this. We are essentially reimplementing another complex workflow. But now, we are implementing it pretty differently in another portion of the application. It's going to be hard to manage. The cost of adding this and maintaining this is a really high concern." And so he talked with the rest of the team and came back, and he's like, "Yep, we're going to throw it away." And so then he issued a PR, and we removed it. +And it was one of those moments of like; this isn't great because then we have invested hours into this, and now we are taking it away. But it also felt really good that that's always an option. And that was the better option because it was either we're going to continue sinking more time into this, or we can stop it now. And then we can move on to more important work. +CHRIS: Sunk costs and all that. +STEPH: Yeah. I feel like it's so rare when that really happens because then we just feel dedicated to like, well, we're going to make this valuable to somebody. We're going to keep this. And in this case, we just threw it away. It's very nice. +CHRIS: There's a similar anecdote that I remember. Actually, I think it's happened more than once. But very particularly, we were working on a system. And this was with our friend, Matt Sumner, a friend of the show, as well been on a few times. And Matt was working on the project. And we got to a point where we had two competing implementations of a given workflow, and we were opting to go with the new one. +But there were folks that were saying, "Let's keep the code around for the old one." And Matt was like, "Absolutely not. If we do that, we might go...no, this will be bad. Then we have to maintain that code. We need to burn the ships," as he said. And he actually named the pull request burn the ships where he just removed all the code. And I was like, I like your style, man. You made a decision here. We collectively made a decision. And then this is a classic Matt Sumner move. But he did the thing that we said we were going to do. And he just held that line. And I really appreciated it. +And it's a voice that I have in the back of my head often now, which is just like, no, burn the ships. If we need it, it'll be in Git history. We can recover it. But it's going to need to be handled in the interim. We don't want to have to support that code right now and for however long until we actually decide to remove it from the codebase. So let's get rid of it. And if we really need it, well, then we'll resurrect it, but for now, burn the ships. And I like that. +STEPH: I like that too. I think it's one of those areas where it takes experience to feel that pain too. If you're pretty new to writing code, you're going to think, well, we can keep it around. There's no harm. And so it often has to be that sage, that person who's been around long enough and felt some pain from making that decision in prior centuries or years. And he's like, "No, we're not going to do this." The WE collective of developers who have experienced the pain from this understand that that's not a good choice. And so we're going to burn the ships instead. But it is one of those that if you're newer, you won't think that way. And I think that's totally reasonable that you wouldn't think that immediately. +CHRIS: I think that tacit knowledge that oh, I've gone through this before, and I've experienced the pain, and now let me tell you about that. And let me try and share that with you because there's always the cost-benefit trade-off. Because if that code stays in the codebase, then we know it works because we've kept it around for that whole time. And so there's a nicety to that, but there's a cost, that maintenance cost. And being able to express that well and being able to say, "I've been here, and let me tell you a tale," but do it in a way that doesn't sound overly condescending or explainy or things like that. I think that's a very subtle skill and a very important one, and frankly, really hard one to get right. +I'm not sure I always hit the mark on that where I'm just like, "No, can't do it. It's bad." I think it's very easy to end up in a space where you're just like, "No, it's bad." And they're like, "But why?" And you're like, "Because it's bad. Trust me." It's like, well, I feel like you do need to be able to explain the stories, the experiences that you've had in the past, the anecdotes that you've heard, the blog posts that you've read that have really informed your thinking. But I think that is a big part of what it means to continue on in this profession and be able to do the work and make those subtle trade-offs, and the it depends because, at the end of the day, it all depends. +STEPH: Or you just issue a pull request and title it burn the ships. [laughs] +CHRIS: Burn the ships. Indeed, that is, in fact an option. And actually, while we're on the topic of pull requests, this might be a perfect segue into a listener question that we have. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: As always, thanks to everyone who sends in listener questions. We so appreciate getting them. They help direct the conversation and give us something to chat about. So this question comes in from Bryan Robles. And Bryan writes in about large pull requests. And Bryan writes in with, "My toxic trait is large pull requests. Any tips on when you get into a place where you're fixing or refactoring something, and it ends up cascading to many more changes than you want it to? I sometimes can go back and break it up. But it's hard to recognize a good seam when you're in the thick of it." So, Steph, what do you think? Large pull requests and finding yourself in them after [laughs] certain amounts of time. +STEPH: Yeah, speaking of that knowledge that often comes from experience, this is something that I'm certainly always striving to get better at. I think it does take practice. There are some things that I do that I can share. And I categorize them really into a before, and I guess midway. So there's the before I set sail and set off to deeper waters list that I will think through as I'm starting a new task, and then there's the I'm lost at sea. And then, I need to figure out how I'm going to organize this change. +So in the first category, when I'm first starting off a task, I consider what sort of changes need to be made, and are there any obvious roadblocks? So an obvious roadblock may be changing or updating a model that has one relationship, and I need to change it to has many relationships. Or perhaps there's a part of the application that is untested. And before I make any changes, I need to document that existing behavior. And that really falls neatly within Kent Beck's advice where he said, "First make the change easy (warning: this might be hard) and then make the easy change." +So I try to think upfront what are some of the small, incremental changes that I can make first that will then make the final change easy? And then I separate that mentally into PRs. Or I may separate it into tickets, whatever is going to help me stay organized and communicate how I'm breaking up that work. +And then the other thing that I'll do is I'll consider what's my MVP? So what's my minimum viable pull request? What set of changes include just enough changes to be helpful to users or to other developers? Which, by the way, is also a helpful mindset to have when you're breaking down work into tickets. So, as an example, let's say that I need to fix some bad data that's causing a site to error. So my first step could be to write a task to fix the bad data. And then, step two, prevent bad data from being created. And then probably step three, I need to rerun the task to fix data that was created during step two. But I can think through each of those steps and separate them into different pull requests. +And then there may also be the question of well, how small is too small? Like you're saying, what's a minimum viable pull request? How do I know if I am not delivering value? And that one gets a little trickier and vague. But ultimately, I will think, does it pass CI? Is this change deployable? And then I do have to define what value I'm delivering. And I think that's a common area that folks struggle because we'll think of delivering value as delivering a whole new feature or adding complete test coverage for an untested interface. +But delivering value doesn't have to represent that end goal. It may be that you added one test for an untested interface. And that's still delivering really great value to your team, same for delivering a feature to a user. You may be able to speak with that wonderful product manager and find what's the smallest bit of value that you can deliver instead of the whole feature set? I think the smallest PR I can think of that I've issued is either fixing a typo or removing a focus metadata from an RSpec test. So that's my starting point. That's the before I set sail. Those are some of the things I think about. I have more for the I'm lost at sea. But what are your thoughts? +CHRIS: First, that was a great summary that you gave. So I totally agree with everything that you just said. I think part of the question I would have...So Bryan wrote this in and described this as his toxic trait. So he's identifying this as something that seemingly consistently plagues him. +So I would ask, is there a way that you can introduce something? Like, are there natural breaks in your day? And can you ask the question at those breaks? Like, hey, I've been working on a thing for a little while. Is there a version that I could...like, could I close off a body of work at this moment? When you break for lunch, if you go grab coffee in the morning, when you're leaving at the end of the day, use those natural breakpoints. +I'm not sure exactly what you mean when you say large pull requests. But if those are spanning multiple days, in my mind, if anything starts to span more than a day, I will start to ask that question to myself. And that's a reflex that I built up over time by feeling the pain of large pull requests and putting it up, and feeling apologetic. And then having my colleagues gently, professionally kindly ask me to break it down into smaller pieces. And me saying, "I really don't want it. All right, fine, fine, fine, I'll do it." And then I do it. +And it's one of those things that I never want to do in the first place, but I'm always happy to have done after the fact. But it is work. And so, if I can get better at pulling that thinking and pulling that question earlier in the process, that I think is really useful. Similarly, I will try to, again, as friendly as I can; if I notice someone mentioning the same body of work at stand up for a few days, I might gently ask, "Hey, is there a way that we can find a shippable version of a portion of that of a subset? Can we put it up behind a feature flag and get something out there just to try and keep the PR small, et cetera?" And so gently nudge in that direction. +And then I think the other side of that is being very okay with one character PRs. Like, that's it. We changed one character. It turns out we need to pluralize that word, or we need one-line changes are great. That's fine. And more pull requests, in my mind, are better than fewer, larger pull requests. And so really embracing that and having that be part of the core conversation and demonstrating that throughout the team is a way to share this idea. So that's perhaps more in the process or person point of view on this as opposed to the technical, but that's part of the consideration that I would have. I am interested, and I'll bounce back to, Steph, what you were saying of now that you're out at sea, what do you do? +STEPH: So I need to react positively to some of the things that you just said because you made me think of two things. One of them is I've never had someone say, "Hey, Steph, that PR is too small. Could you add some more changes to it? Could you do some more work?" I have had people say, "Hey, that PR was hard to review." But even then, sometimes getting that feedback from folks is hard because nobody really wants to say, "I had a hard time reviewing your PR." That's something that, over time, you may become really comfortable saying to someone. +But I think initially, people don't want to say, "Hey, that was hard to review," or "There were a lot of changes in that. Would you break it down?" Because that's a lot of complex emotions and discussion to have there. But yeah, I just figured I'd share that I have never had someone complain that a PR is too small, and I've issued a single character change. +And then I love, love how much you asked the question of what's the problem we're trying to solve? And so there's this ambiguous idea of a large PR. But what does that mean? What are the pain points? What are we actually looking to change about our behavior? And then how is that going to impact or benefit the team or benefit ourselves? And so, going back to the question of how do we measure this? How do I know I'm starting to break up my changes in a helpful way? We may need to circle back to that because I don't have answers to it. But I just really like asking that question. +As for the I'm lost at sea part, or maybe you're not lost at sea, but you've caught too many fish, and the fish warden is going to fuss at you if you bring too many fish back to dock. I don't think this is a real nautical example. But here we are. +CHRIS: Was that the fish warden? +STEPH: Yeah, the fish warden. You know, the fish warden. [laughs] +CHRIS: Sure, I do, yeah. Yeah, I know about that, well-versed in fish law. +STEPH: [laughs] Got to know your fish law. If we're going to talk about pull requests, you got to introduce fish law. But I'm actually going to quote Joël Quenneville, a fellow thoughtboter, because they shared a thoughtful thread on Twitter that talks a lot about breaking up your changes and how to break up your pull requests and your commits. And I'll be sure to include a link in the show notes because it's really worth reading as there's a lot of knowledge in that thread. +But one of the things that Joël says is get comfortable with Git, and it makes a world of difference. In particular, you want to get really good at git add --patch, git reset, and git rebase interactive. And that is so true for me. Once I have gotten really good at using those commands, then I feel like I can break up anything. +Because often when I am helping someone break something up, it's often they want to, but they're like, "I don't know how. And this is going to take so much of my time. It doesn't feel efficient and the right thing to do." And they're probably right. If you don't know how to break it up, then it may take you too long. And maybe it's not worth it at that point. +But if you can ask a friend, and they can help walk you through this process, or if you can learn on your own, that's going to be a game-changer because you will start to think about how can I separate these commits? And I can reorder them, and then issue separate PRs, or just keep them in separate commits, whatever process you're looking to improve. +In fact, there's a really great course on Upcase called Mastering Git written by someone who is co-host of this podcast. And it has a lot of great videos and tutorials that will help you get really good at these Git commands and then will help you split up your commits. +CHRIS: Oh yeah, I did do that. Warning: it's like three and a half hours long. But it is broken up into, I believe, 10 or 11 videos. So you can find just the ones that you want. There's a couple in the middle that I think are particularly useful talking about the object model of Git. Git is weird, unfortunately. And so I spent a bunch of time in that course. Also, thank you for the kind words, Steph. [laughs] +But I spent a bunch of time in that course trying to make Git less weird or understandable. If you look under the hood, it starts to make more sense. But if you really want to get comfortable with manipulating Git history, which I think is a really useful skill for this conversation that we're having, that's the only way I found to do it, just memorizing the steps. +It's always going to feel a little bit foreign. But once you understand the stuff under the hood, that's a really useful thing for being able to manipulate and tease apart a pull request and break it into different things, and port things from one branch to another, and all those fun activities. Yeah, man, that was a bunch of years ago too. I wonder what I look like in it. Huh. +STEPH: I really liked that episode, the one you just mentioned, the Git Object Model. Now that you've mentioned it, I remember watching it, and it's very interesting. So yeah, thank you for making all this helpful content for folks. There's also a blog post that we can include in the show notes as well that is a really nice overview of using git interactive, and rebase, and squash and amend those types of behaviors as well. So will be sure to include both so folks can check those out. +And then to round things out, one of the other things that I will do is I will ask a friend. I will ask someone for help. So we've talked about some of these behaviors, or some of these processes that we have are really built up from experience and practice. And you can watch a lot of helpful content, and you can read blog posts. But sometimes, it really just takes time to get good at it. I know, as I'd mentioned earlier, I am always still looking to improve this particular skill because I think it's so valuable. +And one of the ways I do that is I will just phone a friend. And I'll say, "Hey, can we chat for a bit? I would like to show you my changes. I want to hear from you if you see something in here that's valuable that you think can be shipped independently, so that way we can get it delivered faster." Or it may be a change that's just like a test improvement or something. And we can go ahead and get that immediately released to the team, and it will benefit them. +Or you may want to do this at the start of a ticket. If I am new to a project or when I am new to a project, I will often ask someone to break down a ticket with me if I'm feeling a little bit uncertain. Or just say, "Hey, do you see any clean lines of division here? I feel like there's a lot in this ticket. You're more familiar with the codebase. What would you ship? How would you ship this incrementally?" and have someone else walk through the process with you. +CHRIS: Yep, the phone a friend and/or, as always, pairing is a wonderful tool in these sorts of situations. The one other thing that comes to mind for me is part of the question was about sometimes it's difficult to find a clear parting line within a larger body of work, within a larger change. And that can definitely be true. +I think there are certain standouts of like is this a refactoring that can be shipped separately? Is this a test change that would be useful on its own? Is there a model change that we could break out and have just that go out? So there's a bunch of mechanical questions that we can ask and say; here’s categories of things that might fit that bill. +But to flip this to the other side, the question was asked by Bryan very much as an I struggle with this thing. This is my toxic trait is the phrase that he used, which I thought was really interesting. And that can be true. This can be something that if you're consistently and uniquely within the team producing these giant PRs and then folks find that difficult to review, then I think that is absolutely something to work on. +But if this is something that is happening between members like, other members of the team are also finding that they keep ending up with PRs that are bigger than they expected and taking longer and harder to review, there is a question of is the codebase actually in a shape that makes it harder to do small changes? There's the phrase shotgun surgery, which refers to a codebase that is so entangled and coupled that any change requires modifying ten files just to make one small alteration. +And I think that's a worthwhile question to step back and ask, actually, is it not me? Is it actually the codebase? It could be both certainly. But there is a version of your codebase is coupled in a way that means that any even small, tiny change requires touching so many different places in the code. And if that's true, that's at least worth naming and worth highlighting and maybe talking about in retro and saying, hey, this feels like it's true. So maybe we start to get intentional about refactoring, and breaking out, and starting to add those dividing lines within the code such that hopefully, down the road, small changes can, in fact, be small changes. So that is the one last thing that I would consider here. +Also, anecdotally, this is just a thing that came to mind. As I've worked with strongly-typed languages, systems that have a compiler, and have a type system, and the ability for the compiler to keep an eye on the whole codebase, I've noticed that it's very easy to do this sort of thing where I just start with one small data model change, and then the compiler is like, oh, you got to go fix it here, and here, and here, and here. +And I found that because the compiler is your friend and will just point you to all the places you need to make the change, it is very easy to just keep going because some of that mechanical work is happening on your behalf. And it's a wonderful facet of typed languages and of having a compiler and being able to have that conversation with the compiler. +But I found that for me, it is much easier to end up in this mode where I'm like, oh no, this PR is way too large. When I'm working in a system that has types, that has a compiler, that frankly makes it a little bit easier to chase down all the places you need to make a change. So that's also a consideration. It's not necessarily a good or a bad thing, just something that I've observed that feels like it's adjacent to this conversation. But yeah, I think those are my thoughts. +STEPH: Yeah, those are great points. I've certainly worked on projects where that felt very true where it's a small change, but it would cascade throughout the project. And all the changes were necessary. It wasn't something that I could split into smaller PRs. So checking if it is the codebase that's really making it hard to have small PRS is a really great idea. +CHRIS: Who'd have thunk such a little question could get us rambling for so long? Oh, wait, I would have thunk that. +STEPH: And so far, reflecting on the things that we've talked about so far, I think I've talked a good game of where I'm saying, "Oh, I identify the seams upfront, and then I organize and create different tickets." And that is very much not the case. That's the really ideal outcome. But often, I am in the thick of things where like you just said...and it's this moment of, oh, I've done a lot in this PR. And how can I break this up? And that does take time. And it becomes a conversation of trade-off, which is why those Git skills really come in handy because then it will lower the cost of then splitting things out for others. +But for people that are struggling with creating smaller PRs, I do think it's very fair to ask your team for help. I think it's also fair that if you issued a large pull request and folks have already reviewed it, and it's gotten approved, and someone makes a comment like, "Oh, this would be great as two PRs instead of one," to say, "Awesome, thank you for letting me know. I will take that forward with me, but I'm not going to do it for this PR." +I wouldn't recommend making that a habit. But just know that that is something that you can say to someone to say, "I think this one is good to go at this point. But I will keep that in mind for future PRs. And I may even reach out to you for help if I feel like I'm having trouble splitting up a PR." And bring that person into your progress and use them as an accountability buddy. They can be someone that helps you down that path towards smaller PRs. +CHRIS: Yeah, I definitely agree with that, although it becomes a very subtle line. Saying, "Thank you, but no thank you," in a pull request or to feedback is delicate. It's difficult. That's a whole thing. But I agree there have been times where I have either been the one making that decision or suggesting that or being like, "We probably should have broken this up. But we're far enough along now. Let's get this merged. And then we'll iterate on it after the fact." +One last thing, actually. I thought I was done, but I have one more thing, which is I feel like there's a strong parallel between test-driven development and this question in that, often, I hear folks saying, "I don't know how to write tests upfront. I don't know how to do that. I know after the fact I can write tests, and I can add them after." And that can definitely be true. It can become more obvious after you've written the code how you could then write a test that would constrain that behavior that would interact with the system. +But I think the useful thing that you can do there is take a moment and pause there and say, "Okay, now that I have written the test, what would it look like if I had written this in the first place?" Or if you really want to go for it, throw away the code, try again. Start with the test first and then rebuild it. That's maybe a little much. +But that thing of taking these moments of maybe you don't know upfront how to break the work into smaller pieces, but then you get to the end, and you have that conversation with someone. And they highlight where some parting lines would be, or you figure it out after the fact. Stay there in that moment. Meditate on it a bit and try and internalize that knowledge because that's how moving forward, you might know how to do this in the future. So take those moments, whether it be with TDD or with pull requests, or breaking up a ticket into smaller tickets, anything like that. And spend a moment there and try and internalize that knowledge so that you have it proactively moving forward. +STEPH: You know how Slack has status? I really like the idea of there being a status that's meditating on...and you can fill it in. And the example that you just provided, meditating on splitting up a pull request or meditating on how to write a test first, [laughs] I think that would be delightful. +CHRIS: I, too, think that would be delightful. But with that long, adventurous answer to what seemed like a simple question, and they always do, but here we are, shall we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph gives an update about RSpec focus and how she often forgets to remove the focus feature from tests. She figured out two solutions: one using Rubocop, and the other from a Twitter user, suggesting using a GitHub gist. She also suggests that if you're one of those people who misses being in an office environment, you check out soundofcolleagues.com for ambient office noise selection.

+ +

Chris has been struggling to actually do any coding and is adjusting to doing more product management and shares some strategies that have been helping him.

+ +

They answer a listener question about dealing with large pull requests and how it's hard to recognize a good seam to break them up when you are in the thick of one.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: One day, I'll grow up. It's fine. I look forward to that day. But today, I don't think it's that day.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Well, in some fun news, Utah started his professional training as of this morning, which I'm very excited about. Because we've been working with him to work on being good with walking on a leash, FYI, he's not, [laughs] and also being good about not jumping on people. And essentially, being a really good roommate. And he started training today, and we are using an e-collar, which initially I was really hesitant about because I don't want it to hurt him in any way. But now that I have felt the e-collar myself and we've had a first day with it, it's going super well. I'm very excited for where this is headed.

+ +

CHRIS: That's very exciting. When does he start paying rent?

+ +

STEPH: Ooh. I'll have to check with him, or I guess I have set those boundaries. That's my job.

+ +

CHRIS: I just figured that's a core part of being a good roommate. But maybe we've got baby steps or doggy steps to get there. But that's exciting. I'm glad [laughs] that the first day of training is going well.

+ +

STEPH: Yeah, it's going great. And the place that we're going to the trainer they have horses, and mules, and goats. And so now I have a very cute video of him trying to play with a goat, and the goat was having none of it. But it's still all very cute.

+ +

In tech-related news, I have an update for when you and I were recently chatting about the RSpec focus and how I mentioned that I often forget to remove the focus feature from tests. And so then that goes up to a PR, and I have to rely on a kind human to let me know, and then I remove it. Or worst-case scenario, it gets merged into the main branch. And for anyone that's not on Twitter, I just wanted to share an update because I also shared something there.

+ +

But the resolution for what I was looking for there's already a rule that's written into Rubocop, but it's specifically written in the Rubocop RSpec codebase. And with that rule, you can essentially just say, hey, let me know anytime that a test is using the focus metadata, and then make sure to let me know and fail.

+ +

And then if you don't want to actually include all of Rubocop into your project because Rubocop is pretty opinionated, you can still add Rubocop to your project, but you can specifically add Rubocop RSpec, and then you can say, hey, all other rules disabled by default, but then you can enable that specific rule. So then, that way, you will catch all of your focus tests.

+ +

There's also another approach that someone on Twitter shared with us recently from Marz Drel. And Marz shared specifically a really nice simple GitHub Gist that documents or exemplifies that you can add an environment variable that checks to say, hey, if we're in CI mode, then add a before hook. And then that before hook will look for any examples that are using that focus metadata, and then it's going to raise. And then if we're not in CI mode, then don't do anything, don't raise, and carry on. And that's just a really nice simple addition if someone didn't want to pull in Rubocop into their project.

+ +

CHRIS: Both of those definitely sound like great options. I don't think we have Rubocop on the current project that I'm working on. But I think the RSpec focus thing, the metadata one, seems like it'll work great. More generally, I just want to thank folks out there who listen to the show and then write back in like, "Hey, this is probably what you want."

+ +

There was a similar thread that someone shared around the RSpec::Retry stuff that I was talking about recently and the failure mode there and trying to get that into the Junit Reporter. And so they had some suggestions around that. Jason Rudolph on Twitter reached out, sharing just his initial exploration and thoughts on how it might be possible to extend the XML reports that are generated and capture a flaky test in that way. So that's really interesting.

+ +

And again, just really love that folks are listening to the things that we say and then even adding on to them and continuing the conversation. So thanks to everybody for sharing those things.

+ +

STEPH: Yeah, it's incredibly helpful. And then one other fun thing that I'd love to share, and I found this out from someone else at thoughtbot because they had shared it recently. But it's a neat website called soundofcolleagues.com. And I know you've got your laptop in front of you. So if you'll go visit it, it'll be neat to see as we're talking through it. For anyone else that wants to pull it up, too, we'll include a link in the show notes.

+ +

But it's a neat project that someone started where you can bump up the sounds that you would normally hear in an office. So maybe you want to bump up background noise of people or an open window. There's one specifically for printers and a coffee machine, and keyboards are on there as well. [laughs] I have discovered I am partial open window and partial rain, although rain is just always my go-to. I like the sound of rain for when I'm working.

+ +

CHRIS: Gentle rain is definitely nice white noise in general. I've seen this for coffee shops, but I haven't seen the particular one. Also, yes, I definitely know how to spell the word colleague on the first of three tries. Definitely didn't have to rely on Google for that one. But yeah, nice site there. I enjoy that.

+ +

STEPH: I tried the keyboard option that's on there because I was like, oh yeah, I'm totally going to be into this. This is going to be my jam. I don't think it is because I realized that I'm very biased. I like the sound of my own keyboard. So I had to shush the other one and just listen to the rain and the open window. But that's some of the fun things that are going on in my world today. What's new in your world?

+ +

CHRIS: I'm just now spending a moment with the keyboard sound. It's a very muted keyboard. I want a little more clackety.

+ +

STEPH: A little more clackety?

+ +

CHRIS: I was assuming it would be too much clackety, and that would be the problem. But it sounds more mushy. Maybe we can pipe in some of the sound here [laughs] at this point. Or we can link to these sounds, and everyone can dial up the keyboards to 100. But I, too, am partial to the sounds of my own keyboard.

+ +

But what's new in my world? This past week and I think probably even a little bit more of the prior week, I’ve been noticing that I've been struggling to actually do any coding, which has been interesting to observe. And again, trying to observe it, not necessarily judge it, although if that's not the thing that we want to be doing, then try and improve that. But mostly trying to observe what's going on, what is taking my time. A lot of it is product management type work. So I am spending a good amount of time trying to gather the different voices and understand what is the work to be done, and then shape that into the backlog and make sure that that's clear and ready for the team to pick up.

+ +

And then, thankfully, the other two developers that are working on the project are fantastically prolific. So they're often very quickly working through the work that has been set up in front of them. And so I'm trying to then be proactive and respond to the code. But there's almost a cycle to it where I'm just staying out in front of them, but they're catching up with everything that's going on. So it's something that I'm trying again to be intentional about, name, share some of that back up with the group. If there are things that I'm doing that I don't uniquely need to be doing, then let's share as much of that knowledge as possible.

+ +

But one thing that I will say is the product management, shaping the backlog work is exhausting. I am astonished by just how drained I am at the end of the day. And I'm like, I don't even really feel like I did anything. I didn't write any code, but I am just completely spent. And there really is something to when the work is clear, just doing the work, I can actually find energizing. And it's fun, and I can get in flow state. And sometimes, I'll be drained in a certain way.

+ +

But the work of taking a bunch of different slack threads, and communications, and meetings, and synthesizing that down, and then determining what the work needs to look like moving forward, and providing enough clarity but then not over constraining and not providing too much clarity. And there are so many micro-decisions that are being made in there. And I'm just spent at the end of the day, and I have so much...I've always had a lot of respect for product managers and folks that are existing in that interstitial space and trying to make sense of the noise, especially of a growing company, but all the more so this week as I've been feeling some of that myself.

+ +

STEPH: I totally agree. I have felt that having a strong product manager really makes or breaks a project for me where even though having technical leadership is really nice, I'd prefer someone that's really strong at the product knowledge and then helping direct where the product is headed. That is incredibly helpful. Like you mentioned, the work is exhausting.

+ +

There's someone that joined the thoughtbot team fairly recently, and I was chatting with them about what type of projects they would be interested in working on. And one of their responses was, "I'd love to work on a project with a strong product manager because I have been doing that a fair amount for recent years. And I would love to get back to just focusing on coding." And so I think they enjoyed some of the work, but they just recognize it's exhausting. And I'd really like to just get back to writing code for a while.

+ +

CHRIS: Yeah, I'm definitely in that space. And I think there's a ton of value to spending a little bit of time, like having any developer at some point in their career spend a little bit of time managing the backlog, and you will learn a bunch from that. But I'm also in the space of I would love to just turn on some music and code for a while. That sounds fun. There's a lot of work to be done right now. I'd love to just be in there doing the work. But sometimes, out of necessity, the defining of the work is the thing that's important.

+ +

And so, I think I've been correctly assessing the most important thing. And that that has consistently for a while now been the defining and responding to the work that's in process as opposed to doing it myself. But, man, I really hope I get to dive back into the code sometime and use my clackety keyboard to its fullest extent.

+ +

STEPH: Have you found any particular strategies that really help you with the product management work?

+ +

CHRIS: I will say that I think this is a competency. This is a skillset and a career path that...again, I've been at plenty of organizations that I don't think respected the role as much as it should be. But it's an incredibly hard role and multidisciplinary communication at the core of it. And so I don't think I'm great at it is the thing that I'll say. So everything that follows is just to be clear; I’m not saying that I'm great at this, but I have been doing some of it. So here are some thoughts that I have.

+ +

I think a lot of it is in reaction to where I felt like the work was clear. So I have a sense of what it looks like when I can go to the backlog, trust that it is in a roughly solid priority order, pick up a piece of work and immediately go to work on it. And understand what are the end-user implications of this piece of work? Where would I start on it like, how technically? What's a rough approach that I would have? And getting that level of specificity just right. So it's not overconstrained, but it's not under constrained. So having experienced that on the developer side, I try and then use that to shape some of the guidance that I'm putting into, say, the Trello tickets that I'm writing up here.

+ +

We recently introduced Trello epics, which is I want to say like an add-on. And that allows us just the tiniest bit of product management, like one level up. So instead of just having cards and a list that is like, here's the work to be done, we now have an epics list that is separate to it, and it links between a card and its associated epics. So it's like project and action within that project.

+ +

And just that little touch of structure there has been really, really useful to help look at like, okay, what are the big pieces that we're trying to move? And then how do they break down into the smaller pieces? So a tiny, tiny bit of fanciness in our product management tool, not Jira-like not going in that direction yet for as long as I cannot. But that little bit of structure.

+ +

And then thinking about what has been useful to me as I pick up tickets. And then, as always, trying to just always be cognizant of what is the user's experience here? What problem am I trying to solve for them? What is their experience going to be? How will they know how to work with this feature? And just always asking that and then framing the work to be done in the context of that.

+ +

STEPH: I like how you're adamant about a little bit of fanciness but not all the way to Jira-like. I also like how you highlighted end-users. All of that, I think, is awesome when developers are able to expand their role to experience all the other facets of building software.

+ +

CHRIS: Yeah, definitely. I think that whole list of all of the different facets of where our work interacts with different groups. The more empathy or, the more experience that you can have there, the better that you'll be able to understand how to communicate there, how to express things in terms, et cetera, et cetera. So a huge fan of all of those ideas. I am ready to just get back in the code for a few minutes, though. But for now, for as long as necessary, I'll do some of this work. But I am trying to find my way to other things.

+ +

In terms of actual feature work that we're working on, one of the things that we're doing right now is restructuring our onboarding. So when a user comes and signs up to the website and then subsequently has to fill out a handful of other forms, there's actually an external system that we've been working with that houses some of the core data of our application. And they have a hosted application form. So we can send the user over to them, and the user fills out the rest of the application on this other system's site. And then they get redirected back to us. And everything's got nice DNS entries for a particular subdomain and whatnot. So it looks roughly consistent. There's some branding. But it's still someone else's UI, essentially.

+ +

And we were feeling enough pain from that experience. We were like; you know what? It's time. We're going to bring this back in-house. We're going to do all the forms ourselves. We're going to do a nice progressive little progress bar. You can see all the steps as you're going through onboarding. We're just going to own that more because that's a core part of the experience that we're building here. So biting the bullet, deciding to do that.

+ +

But there's an interesting edge case that we run into, which is we are using Devise for authentication. Totally makes sense. We're in Rails context; there we go. It's the thing to use. But Devise exists in truly the Rails world. So like HTML ERB templates, the controllers have certain expectations as to what's going on. So thus far, we've just let that exist in that world and everything else we're building in Inertia and Svelte. But we're just now starting to feel enough of the pain, and that Devise exists in this other context. And for a while, we just kept saying, "You know what? It's not worth the effort to port it over. It's fine."

+ +

Because we're using Tailwind, we have a consistent design language that we can use across them. That said, the components are drifting a little bit. And it's like, oh, this one's got a rounded corner like this, and that one's got this color. And we don't have the disabled style. But it is nice that it's not completely distinct. But we have finally decided it is time. We need to port this thing over because we feel like the onboarding and authentication type flows; they’re actually a big part of the user experience or at least the first run user experience when someone's signing up to our site. So we want to own that a little bit more.

+ +

One of the things that I ran into as I was trying to introduce Mailcheck, which is a library that I've talked about, I think in a previous episode...but basically, you can have it observe a field and if someone types in like, user@gmaip.com, you can like, did you mean gmail.com? And then go from there. And I think there's more subtlety. They can maybe even look up MX records and things like that. But basically validate an email address heuristically and offer the nice, very friendly to a user, "Hey, did you mean this instead?" So not a full validation that says, "No, you cannot put your email address," because maybe you have a weird one that sounds like Gmail but isn't. But that's a little bit trickier to implement both on the Devise side and then in any other place that we have an email input.

+ +

And so what we want to do is port over to Inertia and Svelte, and then everything's in our nice, happy context with all our components and all the other work that we're doing. And it really does just highlight how much I've come to enjoy working with Inertia and Svelte. They are fantastic technologies. And now I just want absolutely everything to be in them. So we're finally going to bite the bullet, and I think port those over a little bit after we get the current batch of work done. But soon, soon, that's the goal.

+ +

STEPH: I'm having a bit of déjà vu where I feel like there was a project that you were working on that was using Devise, and then removing Devise and replacing it with something else was a challenge. Does that ring a bell?

+ +

CHRIS: Yes, that is accurate. So I had a project that I worked on where we had both Devise and Clearance was actually what was going on. There were basically two different applications that existed; one was using Clearance, the later one used Devise. But then we folded those two applications back together. And by virtue of that, I tried to unify the authentication schemes, and it was like, nope, not going to happen. And then we didn't.

+ +

STEPH: And then we didn't. [laughs] I like that ending.

+ +

CHRIS: Well, sometimes you don't. [laughs]

+ +

STEPH: Yeah, I love that ending because it reflects reality. Sometimes that just happens. In fact, I'm going to segue for just a moment because you're reminding me that there's something I don't think I've shared with you yet. On my previous project, there was a particular feature. It was a big feature that someone had picked up and worked on.

+ +

And at one point, we were essentially playing hot potato with this feature because we hadn't gotten it to the point that it was merged. There was too much that was happening in that pull request, although then we ended up merging it. But then we found lots of bugs. And it was just one of those features that we couldn't really get across the finish line. There was always something else that was wrong with it or needed to be done or needed to be considered.

+ +

And we'd reach that point where Chad Pytel, who is on the project, was like, "We're either going to finish this, or we're going to throw it away." And I felt a little guilty saying this, and I was like, "I vote we throw it away. I have lots of concerns about this. We are essentially reimplementing another complex workflow. But now, we are implementing it pretty differently in another portion of the application. It's going to be hard to manage. The cost of adding this and maintaining this is a really high concern." And so he talked with the rest of the team and came back, and he's like, "Yep, we're going to throw it away." And so then he issued a PR, and we removed it.

+ +

And it was one of those moments of like; this isn't great because then we have invested hours into this, and now we are taking it away. But it also felt really good that that's always an option. And that was the better option because it was either we're going to continue sinking more time into this, or we can stop it now. And then we can move on to more important work.

+ +

CHRIS: Sunk costs and all that.

+ +

STEPH: Yeah. I feel like it's so rare when that really happens because then we just feel dedicated to like, well, we're going to make this valuable to somebody. We're going to keep this. And in this case, we just threw it away. It's very nice.

+ +

CHRIS: There's a similar anecdote that I remember. Actually, I think it's happened more than once. But very particularly, we were working on a system. And this was with our friend, Matt Sumner, a friend of the show, as well been on a few times. And Matt was working on the project. And we got to a point where we had two competing implementations of a given workflow, and we were opting to go with the new one.

+ +

But there were folks that were saying, "Let's keep the code around for the old one." And Matt was like, "Absolutely not. If we do that, we might go...no, this will be bad. Then we have to maintain that code. We need to burn the ships," as he said. And he actually named the pull request burn the ships where he just removed all the code. And I was like, I like your style, man. You made a decision here. We collectively made a decision. And then this is a classic Matt Sumner move. But he did the thing that we said we were going to do. And he just held that line. And I really appreciated it.

+ +

And it's a voice that I have in the back of my head often now, which is just like, no, burn the ships. If we need it, it'll be in Git history. We can recover it. But it's going to need to be handled in the interim. We don't want to have to support that code right now and for however long until we actually decide to remove it from the codebase. So let's get rid of it. And if we really need it, well, then we'll resurrect it, but for now, burn the ships. And I like that.

+ +

STEPH: I like that too. I think it's one of those areas where it takes experience to feel that pain too. If you're pretty new to writing code, you're going to think, well, we can keep it around. There's no harm. And so it often has to be that sage, that person who's been around long enough and felt some pain from making that decision in prior centuries or years. And he's like, "No, we're not going to do this." The WE collective of developers who have experienced the pain from this understand that that's not a good choice. And so we're going to burn the ships instead. But it is one of those that if you're newer, you won't think that way. And I think that's totally reasonable that you wouldn't think that immediately.

+ +

CHRIS: I think that tacit knowledge that oh, I've gone through this before, and I've experienced the pain, and now let me tell you about that. And let me try and share that with you because there's always the cost-benefit trade-off. Because if that code stays in the codebase, then we know it works because we've kept it around for that whole time. And so there's a nicety to that, but there's a cost, that maintenance cost. And being able to express that well and being able to say, "I've been here, and let me tell you a tale," but do it in a way that doesn't sound overly condescending or explainy or things like that. I think that's a very subtle skill and a very important one, and frankly, really hard one to get right.

+ +

I'm not sure I always hit the mark on that where I'm just like, "No, can't do it. It's bad." I think it's very easy to end up in a space where you're just like, "No, it's bad." And they're like, "But why?" And you're like, "Because it's bad. Trust me." It's like, well, I feel like you do need to be able to explain the stories, the experiences that you've had in the past, the anecdotes that you've heard, the blog posts that you've read that have really informed your thinking. But I think that is a big part of what it means to continue on in this profession and be able to do the work and make those subtle trade-offs, and the it depends because, at the end of the day, it all depends.

+ +

STEPH: Or you just issue a pull request and title it burn the ships. [laughs]

+ +

CHRIS: Burn the ships. Indeed, that is, in fact an option. And actually, while we're on the topic of pull requests, this might be a perfect segue into a listener question that we have.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: As always, thanks to everyone who sends in listener questions. We so appreciate getting them. They help direct the conversation and give us something to chat about. So this question comes in from Bryan Robles. And Bryan writes in about large pull requests. And Bryan writes in with, "My toxic trait is large pull requests. Any tips on when you get into a place where you're fixing or refactoring something, and it ends up cascading to many more changes than you want it to? I sometimes can go back and break it up. But it's hard to recognize a good seam when you're in the thick of it." So, Steph, what do you think? Large pull requests and finding yourself in them after [laughs] certain amounts of time.

+ +

STEPH: Yeah, speaking of that knowledge that often comes from experience, this is something that I'm certainly always striving to get better at. I think it does take practice. There are some things that I do that I can share. And I categorize them really into a before, and I guess midway. So there's the before I set sail and set off to deeper waters list that I will think through as I'm starting a new task, and then there's the I'm lost at sea. And then, I need to figure out how I'm going to organize this change.

+ +

So in the first category, when I'm first starting off a task, I consider what sort of changes need to be made, and are there any obvious roadblocks? So an obvious roadblock may be changing or updating a model that has one relationship, and I need to change it to has many relationships. Or perhaps there's a part of the application that is untested. And before I make any changes, I need to document that existing behavior. And that really falls neatly within Kent Beck's advice where he said, "First make the change easy (warning: this might be hard) and then make the easy change."

+ +

So I try to think upfront what are some of the small, incremental changes that I can make first that will then make the final change easy? And then I separate that mentally into PRs. Or I may separate it into tickets, whatever is going to help me stay organized and communicate how I'm breaking up that work.

+ +

And then the other thing that I'll do is I'll consider what's my MVP? So what's my minimum viable pull request? What set of changes include just enough changes to be helpful to users or to other developers? Which, by the way, is also a helpful mindset to have when you're breaking down work into tickets. So, as an example, let's say that I need to fix some bad data that's causing a site to error. So my first step could be to write a task to fix the bad data. And then, step two, prevent bad data from being created. And then probably step three, I need to rerun the task to fix data that was created during step two. But I can think through each of those steps and separate them into different pull requests.

+ +

And then there may also be the question of well, how small is too small? Like you're saying, what's a minimum viable pull request? How do I know if I am not delivering value? And that one gets a little trickier and vague. But ultimately, I will think, does it pass CI? Is this change deployable? And then I do have to define what value I'm delivering. And I think that's a common area that folks struggle because we'll think of delivering value as delivering a whole new feature or adding complete test coverage for an untested interface.

+ +

But delivering value doesn't have to represent that end goal. It may be that you added one test for an untested interface. And that's still delivering really great value to your team, same for delivering a feature to a user. You may be able to speak with that wonderful product manager and find what's the smallest bit of value that you can deliver instead of the whole feature set? I think the smallest PR I can think of that I've issued is either fixing a typo or removing a focus metadata from an RSpec test. So that's my starting point. That's the before I set sail. Those are some of the things I think about. I have more for the I'm lost at sea. But what are your thoughts?

+ +

CHRIS: First, that was a great summary that you gave. So I totally agree with everything that you just said. I think part of the question I would have...So Bryan wrote this in and described this as his toxic trait. So he's identifying this as something that seemingly consistently plagues him.

+ +

So I would ask, is there a way that you can introduce something? Like, are there natural breaks in your day? And can you ask the question at those breaks? Like, hey, I've been working on a thing for a little while. Is there a version that I could...like, could I close off a body of work at this moment? When you break for lunch, if you go grab coffee in the morning, when you're leaving at the end of the day, use those natural breakpoints.

+ +

I'm not sure exactly what you mean when you say large pull requests. But if those are spanning multiple days, in my mind, if anything starts to span more than a day, I will start to ask that question to myself. And that's a reflex that I built up over time by feeling the pain of large pull requests and putting it up, and feeling apologetic. And then having my colleagues gently, professionally kindly ask me to break it down into smaller pieces. And me saying, "I really don't want it. All right, fine, fine, fine, I'll do it." And then I do it.

+ +

And it's one of those things that I never want to do in the first place, but I'm always happy to have done after the fact. But it is work. And so, if I can get better at pulling that thinking and pulling that question earlier in the process, that I think is really useful. Similarly, I will try to, again, as friendly as I can; if I notice someone mentioning the same body of work at stand up for a few days, I might gently ask, "Hey, is there a way that we can find a shippable version of a portion of that of a subset? Can we put it up behind a feature flag and get something out there just to try and keep the PR small, et cetera?" And so gently nudge in that direction.

+ +

And then I think the other side of that is being very okay with one character PRs. Like, that's it. We changed one character. It turns out we need to pluralize that word, or we need one-line changes are great. That's fine. And more pull requests, in my mind, are better than fewer, larger pull requests. And so really embracing that and having that be part of the core conversation and demonstrating that throughout the team is a way to share this idea. So that's perhaps more in the process or person point of view on this as opposed to the technical, but that's part of the consideration that I would have. I am interested, and I'll bounce back to, Steph, what you were saying of now that you're out at sea, what do you do?

+ +

STEPH: So I need to react positively to some of the things that you just said because you made me think of two things. One of them is I've never had someone say, "Hey, Steph, that PR is too small. Could you add some more changes to it? Could you do some more work?" I have had people say, "Hey, that PR was hard to review." But even then, sometimes getting that feedback from folks is hard because nobody really wants to say, "I had a hard time reviewing your PR." That's something that, over time, you may become really comfortable saying to someone.

+ +

But I think initially, people don't want to say, "Hey, that was hard to review," or "There were a lot of changes in that. Would you break it down?" Because that's a lot of complex emotions and discussion to have there. But yeah, I just figured I'd share that I have never had someone complain that a PR is too small, and I've issued a single character change.

+ +

And then I love, love how much you asked the question of what's the problem we're trying to solve? And so there's this ambiguous idea of a large PR. But what does that mean? What are the pain points? What are we actually looking to change about our behavior? And then how is that going to impact or benefit the team or benefit ourselves? And so, going back to the question of how do we measure this? How do I know I'm starting to break up my changes in a helpful way? We may need to circle back to that because I don't have answers to it. But I just really like asking that question.

+ +

As for the I'm lost at sea part, or maybe you're not lost at sea, but you've caught too many fish, and the fish warden is going to fuss at you if you bring too many fish back to dock. I don't think this is a real nautical example. But here we are.

+ +

CHRIS: Was that the fish warden?

+ +

STEPH: Yeah, the fish warden. You know, the fish warden. [laughs]

+ +

CHRIS: Sure, I do, yeah. Yeah, I know about that, well-versed in fish law.

+ +

STEPH: [laughs] Got to know your fish law. If we're going to talk about pull requests, you got to introduce fish law. But I'm actually going to quote Joël Quenneville, a fellow thoughtboter, because they shared a thoughtful thread on Twitter that talks a lot about breaking up your changes and how to break up your pull requests and your commits. And I'll be sure to include a link in the show notes because it's really worth reading as there's a lot of knowledge in that thread.

+ +

But one of the things that Joël says is get comfortable with Git, and it makes a world of difference. In particular, you want to get really good at git add --patch, git reset, and git rebase interactive. And that is so true for me. Once I have gotten really good at using those commands, then I feel like I can break up anything.

+ +

Because often when I am helping someone break something up, it's often they want to, but they're like, "I don't know how. And this is going to take so much of my time. It doesn't feel efficient and the right thing to do." And they're probably right. If you don't know how to break it up, then it may take you too long. And maybe it's not worth it at that point.

+ +

But if you can ask a friend, and they can help walk you through this process, or if you can learn on your own, that's going to be a game-changer because you will start to think about how can I separate these commits? And I can reorder them, and then issue separate PRs, or just keep them in separate commits, whatever process you're looking to improve.

+ +

In fact, there's a really great course on Upcase called Mastering Git written by someone who is co-host of this podcast. And it has a lot of great videos and tutorials that will help you get really good at these Git commands and then will help you split up your commits.

+ +

CHRIS: Oh yeah, I did do that. Warning: it's like three and a half hours long. But it is broken up into, I believe, 10 or 11 videos. So you can find just the ones that you want. There's a couple in the middle that I think are particularly useful talking about the object model of Git. Git is weird, unfortunately. And so I spent a bunch of time in that course. Also, thank you for the kind words, Steph. [laughs]

+ +

But I spent a bunch of time in that course trying to make Git less weird or understandable. If you look under the hood, it starts to make more sense. But if you really want to get comfortable with manipulating Git history, which I think is a really useful skill for this conversation that we're having, that's the only way I found to do it, just memorizing the steps.

+ +

It's always going to feel a little bit foreign. But once you understand the stuff under the hood, that's a really useful thing for being able to manipulate and tease apart a pull request and break it into different things, and port things from one branch to another, and all those fun activities. Yeah, man, that was a bunch of years ago too. I wonder what I look like in it. Huh.

+ +

STEPH: I really liked that episode, the one you just mentioned, the Git Object Model. Now that you've mentioned it, I remember watching it, and it's very interesting. So yeah, thank you for making all this helpful content for folks. There's also a blog post that we can include in the show notes as well that is a really nice overview of using git interactive, and rebase, and squash and amend those types of behaviors as well. So will be sure to include both so folks can check those out.

+ +

And then to round things out, one of the other things that I will do is I will ask a friend. I will ask someone for help. So we've talked about some of these behaviors, or some of these processes that we have are really built up from experience and practice. And you can watch a lot of helpful content, and you can read blog posts. But sometimes, it really just takes time to get good at it. I know, as I'd mentioned earlier, I am always still looking to improve this particular skill because I think it's so valuable.

+ +

And one of the ways I do that is I will just phone a friend. And I'll say, "Hey, can we chat for a bit? I would like to show you my changes. I want to hear from you if you see something in here that's valuable that you think can be shipped independently, so that way we can get it delivered faster." Or it may be a change that's just like a test improvement or something. And we can go ahead and get that immediately released to the team, and it will benefit them.

+ +

Or you may want to do this at the start of a ticket. If I am new to a project or when I am new to a project, I will often ask someone to break down a ticket with me if I'm feeling a little bit uncertain. Or just say, "Hey, do you see any clean lines of division here? I feel like there's a lot in this ticket. You're more familiar with the codebase. What would you ship? How would you ship this incrementally?" and have someone else walk through the process with you.

+ +

CHRIS: Yep, the phone a friend and/or, as always, pairing is a wonderful tool in these sorts of situations. The one other thing that comes to mind for me is part of the question was about sometimes it's difficult to find a clear parting line within a larger body of work, within a larger change. And that can definitely be true.

+ +

I think there are certain standouts of like is this a refactoring that can be shipped separately? Is this a test change that would be useful on its own? Is there a model change that we could break out and have just that go out? So there's a bunch of mechanical questions that we can ask and say; here’s categories of things that might fit that bill.

+ +

But to flip this to the other side, the question was asked by Bryan very much as an I struggle with this thing. This is my toxic trait is the phrase that he used, which I thought was really interesting. And that can be true. This can be something that if you're consistently and uniquely within the team producing these giant PRs and then folks find that difficult to review, then I think that is absolutely something to work on.

+ +

But if this is something that is happening between members like, other members of the team are also finding that they keep ending up with PRs that are bigger than they expected and taking longer and harder to review, there is a question of is the codebase actually in a shape that makes it harder to do small changes? There's the phrase shotgun surgery, which refers to a codebase that is so entangled and coupled that any change requires modifying ten files just to make one small alteration.

+ +

And I think that's a worthwhile question to step back and ask, actually, is it not me? Is it actually the codebase? It could be both certainly. But there is a version of your codebase is coupled in a way that means that any even small, tiny change requires touching so many different places in the code. And if that's true, that's at least worth naming and worth highlighting and maybe talking about in retro and saying, hey, this feels like it's true. So maybe we start to get intentional about refactoring, and breaking out, and starting to add those dividing lines within the code such that hopefully, down the road, small changes can, in fact, be small changes. So that is the one last thing that I would consider here.

+ +

Also, anecdotally, this is just a thing that came to mind. As I've worked with strongly-typed languages, systems that have a compiler, and have a type system, and the ability for the compiler to keep an eye on the whole codebase, I've noticed that it's very easy to do this sort of thing where I just start with one small data model change, and then the compiler is like, oh, you got to go fix it here, and here, and here, and here.

+ +

And I found that because the compiler is your friend and will just point you to all the places you need to make the change, it is very easy to just keep going because some of that mechanical work is happening on your behalf. And it's a wonderful facet of typed languages and of having a compiler and being able to have that conversation with the compiler.

+ +

But I found that for me, it is much easier to end up in this mode where I'm like, oh no, this PR is way too large. When I'm working in a system that has types, that has a compiler, that frankly makes it a little bit easier to chase down all the places you need to make a change. So that's also a consideration. It's not necessarily a good or a bad thing, just something that I've observed that feels like it's adjacent to this conversation. But yeah, I think those are my thoughts.

+ +

STEPH: Yeah, those are great points. I've certainly worked on projects where that felt very true where it's a small change, but it would cascade throughout the project. And all the changes were necessary. It wasn't something that I could split into smaller PRs. So checking if it is the codebase that's really making it hard to have small PRS is a really great idea.

+ +

CHRIS: Who'd have thunk such a little question could get us rambling for so long? Oh, wait, I would have thunk that.

+ +

STEPH: And so far, reflecting on the things that we've talked about so far, I think I've talked a good game of where I'm saying, "Oh, I identify the seams upfront, and then I organize and create different tickets." And that is very much not the case. That's the really ideal outcome. But often, I am in the thick of things where like you just said...and it's this moment of, oh, I've done a lot in this PR. And how can I break this up? And that does take time. And it becomes a conversation of trade-off, which is why those Git skills really come in handy because then it will lower the cost of then splitting things out for others.

+ +

But for people that are struggling with creating smaller PRs, I do think it's very fair to ask your team for help. I think it's also fair that if you issued a large pull request and folks have already reviewed it, and it's gotten approved, and someone makes a comment like, "Oh, this would be great as two PRs instead of one," to say, "Awesome, thank you for letting me know. I will take that forward with me, but I'm not going to do it for this PR."

+ +

I wouldn't recommend making that a habit. But just know that that is something that you can say to someone to say, "I think this one is good to go at this point. But I will keep that in mind for future PRs. And I may even reach out to you for help if I feel like I'm having trouble splitting up a PR." And bring that person into your progress and use them as an accountability buddy. They can be someone that helps you down that path towards smaller PRs.

+ +

CHRIS: Yeah, I definitely agree with that, although it becomes a very subtle line. Saying, "Thank you, but no thank you," in a pull request or to feedback is delicate. It's difficult. That's a whole thing. But I agree there have been times where I have either been the one making that decision or suggesting that or being like, "We probably should have broken this up. But we're far enough along now. Let's get this merged. And then we'll iterate on it after the fact."

+ +

One last thing, actually. I thought I was done, but I have one more thing, which is I feel like there's a strong parallel between test-driven development and this question in that, often, I hear folks saying, "I don't know how to write tests upfront. I don't know how to do that. I know after the fact I can write tests, and I can add them after." And that can definitely be true. It can become more obvious after you've written the code how you could then write a test that would constrain that behavior that would interact with the system.

+ +

But I think the useful thing that you can do there is take a moment and pause there and say, "Okay, now that I have written the test, what would it look like if I had written this in the first place?" Or if you really want to go for it, throw away the code, try again. Start with the test first and then rebuild it. That's maybe a little much.

+ +

But that thing of taking these moments of maybe you don't know upfront how to break the work into smaller pieces, but then you get to the end, and you have that conversation with someone. And they highlight where some parting lines would be, or you figure it out after the fact. Stay there in that moment. Meditate on it a bit and try and internalize that knowledge because that's how moving forward, you might know how to do this in the future. So take those moments, whether it be with TDD or with pull requests, or breaking up a ticket into smaller tickets, anything like that. And spend a moment there and try and internalize that knowledge so that you have it proactively moving forward.

+ +

STEPH: You know how Slack has status? I really like the idea of there being a status that's meditating on...and you can fill it in. And the example that you just provided, meditating on splitting up a pull request or meditating on how to write a test first, [laughs] I think that would be delightful.

+ +

CHRIS: I, too, think that would be delightful. But with that long, adventurous answer to what seemed like a simple question, and they always do, but here we are, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Steph gives an update about RSpec focus and how she often forgets to remove the focus feature from tests. She figured out two solutions: one using Rubocop, and the other from a Twitter user, suggesting using a GitHub gist. She also suggests that if you're one of those people who misses being in an office environment, you check out soundofcolleagues.com for ambient office noise selection.

+ +

Chris has been struggling to actually do any coding and is adjusting to doing more product management and shares some strategies that have been helping him.

+ +

They answer a listener question about dealing with large pull requests and how it's hard to recognize a good seam to break them up when you are in the thick of one.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: One day, I'll grow up. It's fine. I look forward to that day. But today, I don't think it's that day.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Well, in some fun news, Utah started his professional training as of this morning, which I'm very excited about. Because we've been working with him to work on being good with walking on a leash, FYI, he's not, [laughs] and also being good about not jumping on people. And essentially, being a really good roommate. And he started training today, and we are using an e-collar, which initially I was really hesitant about because I don't want it to hurt him in any way. But now that I have felt the e-collar myself and we've had a first day with it, it's going super well. I'm very excited for where this is headed.

+ +

CHRIS: That's very exciting. When does he start paying rent?

+ +

STEPH: Ooh. I'll have to check with him, or I guess I have set those boundaries. That's my job.

+ +

CHRIS: I just figured that's a core part of being a good roommate. But maybe we've got baby steps or doggy steps to get there. But that's exciting. I'm glad [laughs] that the first day of training is going well.

+ +

STEPH: Yeah, it's going great. And the place that we're going to the trainer they have horses, and mules, and goats. And so now I have a very cute video of him trying to play with a goat, and the goat was having none of it. But it's still all very cute.

+ +

In tech-related news, I have an update for when you and I were recently chatting about the RSpec focus and how I mentioned that I often forget to remove the focus feature from tests. And so then that goes up to a PR, and I have to rely on a kind human to let me know, and then I remove it. Or worst-case scenario, it gets merged into the main branch. And for anyone that's not on Twitter, I just wanted to share an update because I also shared something there.

+ +

But the resolution for what I was looking for there's already a rule that's written into Rubocop, but it's specifically written in the Rubocop RSpec codebase. And with that rule, you can essentially just say, hey, let me know anytime that a test is using the focus metadata, and then make sure to let me know and fail.

+ +

And then if you don't want to actually include all of Rubocop into your project because Rubocop is pretty opinionated, you can still add Rubocop to your project, but you can specifically add Rubocop RSpec, and then you can say, hey, all other rules disabled by default, but then you can enable that specific rule. So then, that way, you will catch all of your focus tests.

+ +

There's also another approach that someone on Twitter shared with us recently from Marz Drel. And Marz shared specifically a really nice simple GitHub Gist that documents or exemplifies that you can add an environment variable that checks to say, hey, if we're in CI mode, then add a before hook. And then that before hook will look for any examples that are using that focus metadata, and then it's going to raise. And then if we're not in CI mode, then don't do anything, don't raise, and carry on. And that's just a really nice simple addition if someone didn't want to pull in Rubocop into their project.

+ +

CHRIS: Both of those definitely sound like great options. I don't think we have Rubocop on the current project that I'm working on. But I think the RSpec focus thing, the metadata one, seems like it'll work great. More generally, I just want to thank folks out there who listen to the show and then write back in like, "Hey, this is probably what you want."

+ +

There was a similar thread that someone shared around the RSpec::Retry stuff that I was talking about recently and the failure mode there and trying to get that into the Junit Reporter. And so they had some suggestions around that. Jason Rudolph on Twitter reached out, sharing just his initial exploration and thoughts on how it might be possible to extend the XML reports that are generated and capture a flaky test in that way. So that's really interesting.

+ +

And again, just really love that folks are listening to the things that we say and then even adding on to them and continuing the conversation. So thanks to everybody for sharing those things.

+ +

STEPH: Yeah, it's incredibly helpful. And then one other fun thing that I'd love to share, and I found this out from someone else at thoughtbot because they had shared it recently. But it's a neat website called soundofcolleagues.com. And I know you've got your laptop in front of you. So if you'll go visit it, it'll be neat to see as we're talking through it. For anyone else that wants to pull it up, too, we'll include a link in the show notes.

+ +

But it's a neat project that someone started where you can bump up the sounds that you would normally hear in an office. So maybe you want to bump up background noise of people or an open window. There's one specifically for printers and a coffee machine, and keyboards are on there as well. [laughs] I have discovered I am partial open window and partial rain, although rain is just always my go-to. I like the sound of rain for when I'm working.

+ +

CHRIS: Gentle rain is definitely nice white noise in general. I've seen this for coffee shops, but I haven't seen the particular one. Also, yes, I definitely know how to spell the word colleague on the first of three tries. Definitely didn't have to rely on Google for that one. But yeah, nice site there. I enjoy that.

+ +

STEPH: I tried the keyboard option that's on there because I was like, oh yeah, I'm totally going to be into this. This is going to be my jam. I don't think it is because I realized that I'm very biased. I like the sound of my own keyboard. So I had to shush the other one and just listen to the rain and the open window. But that's some of the fun things that are going on in my world today. What's new in your world?

+ +

CHRIS: I'm just now spending a moment with the keyboard sound. It's a very muted keyboard. I want a little more clackety.

+ +

STEPH: A little more clackety?

+ +

CHRIS: I was assuming it would be too much clackety, and that would be the problem. But it sounds more mushy. Maybe we can pipe in some of the sound here [laughs] at this point. Or we can link to these sounds, and everyone can dial up the keyboards to 100. But I, too, am partial to the sounds of my own keyboard.

+ +

But what's new in my world? This past week and I think probably even a little bit more of the prior week, I’ve been noticing that I've been struggling to actually do any coding, which has been interesting to observe. And again, trying to observe it, not necessarily judge it, although if that's not the thing that we want to be doing, then try and improve that. But mostly trying to observe what's going on, what is taking my time. A lot of it is product management type work. So I am spending a good amount of time trying to gather the different voices and understand what is the work to be done, and then shape that into the backlog and make sure that that's clear and ready for the team to pick up.

+ +

And then, thankfully, the other two developers that are working on the project are fantastically prolific. So they're often very quickly working through the work that has been set up in front of them. And so I'm trying to then be proactive and respond to the code. But there's almost a cycle to it where I'm just staying out in front of them, but they're catching up with everything that's going on. So it's something that I'm trying again to be intentional about, name, share some of that back up with the group. If there are things that I'm doing that I don't uniquely need to be doing, then let's share as much of that knowledge as possible.

+ +

But one thing that I will say is the product management, shaping the backlog work is exhausting. I am astonished by just how drained I am at the end of the day. And I'm like, I don't even really feel like I did anything. I didn't write any code, but I am just completely spent. And there really is something to when the work is clear, just doing the work, I can actually find energizing. And it's fun, and I can get in flow state. And sometimes, I'll be drained in a certain way.

+ +

But the work of taking a bunch of different slack threads, and communications, and meetings, and synthesizing that down, and then determining what the work needs to look like moving forward, and providing enough clarity but then not over constraining and not providing too much clarity. And there are so many micro-decisions that are being made in there. And I'm just spent at the end of the day, and I have so much...I've always had a lot of respect for product managers and folks that are existing in that interstitial space and trying to make sense of the noise, especially of a growing company, but all the more so this week as I've been feeling some of that myself.

+ +

STEPH: I totally agree. I have felt that having a strong product manager really makes or breaks a project for me where even though having technical leadership is really nice, I'd prefer someone that's really strong at the product knowledge and then helping direct where the product is headed. That is incredibly helpful. Like you mentioned, the work is exhausting.

+ +

There's someone that joined the thoughtbot team fairly recently, and I was chatting with them about what type of projects they would be interested in working on. And one of their responses was, "I'd love to work on a project with a strong product manager because I have been doing that a fair amount for recent years. And I would love to get back to just focusing on coding." And so I think they enjoyed some of the work, but they just recognize it's exhausting. And I'd really like to just get back to writing code for a while.

+ +

CHRIS: Yeah, I'm definitely in that space. And I think there's a ton of value to spending a little bit of time, like having any developer at some point in their career spend a little bit of time managing the backlog, and you will learn a bunch from that. But I'm also in the space of I would love to just turn on some music and code for a while. That sounds fun. There's a lot of work to be done right now. I'd love to just be in there doing the work. But sometimes, out of necessity, the defining of the work is the thing that's important.

+ +

And so, I think I've been correctly assessing the most important thing. And that that has consistently for a while now been the defining and responding to the work that's in process as opposed to doing it myself. But, man, I really hope I get to dive back into the code sometime and use my clackety keyboard to its fullest extent.

+ +

STEPH: Have you found any particular strategies that really help you with the product management work?

+ +

CHRIS: I will say that I think this is a competency. This is a skillset and a career path that...again, I've been at plenty of organizations that I don't think respected the role as much as it should be. But it's an incredibly hard role and multidisciplinary communication at the core of it. And so I don't think I'm great at it is the thing that I'll say. So everything that follows is just to be clear; I’m not saying that I'm great at this, but I have been doing some of it. So here are some thoughts that I have.

+ +

I think a lot of it is in reaction to where I felt like the work was clear. So I have a sense of what it looks like when I can go to the backlog, trust that it is in a roughly solid priority order, pick up a piece of work and immediately go to work on it. And understand what are the end-user implications of this piece of work? Where would I start on it like, how technically? What's a rough approach that I would have? And getting that level of specificity just right. So it's not overconstrained, but it's not under constrained. So having experienced that on the developer side, I try and then use that to shape some of the guidance that I'm putting into, say, the Trello tickets that I'm writing up here.

+ +

We recently introduced Trello epics, which is I want to say like an add-on. And that allows us just the tiniest bit of product management, like one level up. So instead of just having cards and a list that is like, here's the work to be done, we now have an epics list that is separate to it, and it links between a card and its associated epics. So it's like project and action within that project.

+ +

And just that little touch of structure there has been really, really useful to help look at like, okay, what are the big pieces that we're trying to move? And then how do they break down into the smaller pieces? So a tiny, tiny bit of fanciness in our product management tool, not Jira-like not going in that direction yet for as long as I cannot. But that little bit of structure.

+ +

And then thinking about what has been useful to me as I pick up tickets. And then, as always, trying to just always be cognizant of what is the user's experience here? What problem am I trying to solve for them? What is their experience going to be? How will they know how to work with this feature? And just always asking that and then framing the work to be done in the context of that.

+ +

STEPH: I like how you're adamant about a little bit of fanciness but not all the way to Jira-like. I also like how you highlighted end-users. All of that, I think, is awesome when developers are able to expand their role to experience all the other facets of building software.

+ +

CHRIS: Yeah, definitely. I think that whole list of all of the different facets of where our work interacts with different groups. The more empathy or, the more experience that you can have there, the better that you'll be able to understand how to communicate there, how to express things in terms, et cetera, et cetera. So a huge fan of all of those ideas. I am ready to just get back in the code for a few minutes, though. But for now, for as long as necessary, I'll do some of this work. But I am trying to find my way to other things.

+ +

In terms of actual feature work that we're working on, one of the things that we're doing right now is restructuring our onboarding. So when a user comes and signs up to the website and then subsequently has to fill out a handful of other forms, there's actually an external system that we've been working with that houses some of the core data of our application. And they have a hosted application form. So we can send the user over to them, and the user fills out the rest of the application on this other system's site. And then they get redirected back to us. And everything's got nice DNS entries for a particular subdomain and whatnot. So it looks roughly consistent. There's some branding. But it's still someone else's UI, essentially.

+ +

And we were feeling enough pain from that experience. We were like; you know what? It's time. We're going to bring this back in-house. We're going to do all the forms ourselves. We're going to do a nice progressive little progress bar. You can see all the steps as you're going through onboarding. We're just going to own that more because that's a core part of the experience that we're building here. So biting the bullet, deciding to do that.

+ +

But there's an interesting edge case that we run into, which is we are using Devise for authentication. Totally makes sense. We're in Rails context; there we go. It's the thing to use. But Devise exists in truly the Rails world. So like HTML ERB templates, the controllers have certain expectations as to what's going on. So thus far, we've just let that exist in that world and everything else we're building in Inertia and Svelte. But we're just now starting to feel enough of the pain, and that Devise exists in this other context. And for a while, we just kept saying, "You know what? It's not worth the effort to port it over. It's fine."

+ +

Because we're using Tailwind, we have a consistent design language that we can use across them. That said, the components are drifting a little bit. And it's like, oh, this one's got a rounded corner like this, and that one's got this color. And we don't have the disabled style. But it is nice that it's not completely distinct. But we have finally decided it is time. We need to port this thing over because we feel like the onboarding and authentication type flows; they’re actually a big part of the user experience or at least the first run user experience when someone's signing up to our site. So we want to own that a little bit more.

+ +

One of the things that I ran into as I was trying to introduce Mailcheck, which is a library that I've talked about, I think in a previous episode...but basically, you can have it observe a field and if someone types in like, user@gmaip.com, you can like, did you mean gmail.com? And then go from there. And I think there's more subtlety. They can maybe even look up MX records and things like that. But basically validate an email address heuristically and offer the nice, very friendly to a user, "Hey, did you mean this instead?" So not a full validation that says, "No, you cannot put your email address," because maybe you have a weird one that sounds like Gmail but isn't. But that's a little bit trickier to implement both on the Devise side and then in any other place that we have an email input.

+ +

And so what we want to do is port over to Inertia and Svelte, and then everything's in our nice, happy context with all our components and all the other work that we're doing. And it really does just highlight how much I've come to enjoy working with Inertia and Svelte. They are fantastic technologies. And now I just want absolutely everything to be in them. So we're finally going to bite the bullet, and I think port those over a little bit after we get the current batch of work done. But soon, soon, that's the goal.

+ +

STEPH: I'm having a bit of déjà vu where I feel like there was a project that you were working on that was using Devise, and then removing Devise and replacing it with something else was a challenge. Does that ring a bell?

+ +

CHRIS: Yes, that is accurate. So I had a project that I worked on where we had both Devise and Clearance was actually what was going on. There were basically two different applications that existed; one was using Clearance, the later one used Devise. But then we folded those two applications back together. And by virtue of that, I tried to unify the authentication schemes, and it was like, nope, not going to happen. And then we didn't.

+ +

STEPH: And then we didn't. [laughs] I like that ending.

+ +

CHRIS: Well, sometimes you don't. [laughs]

+ +

STEPH: Yeah, I love that ending because it reflects reality. Sometimes that just happens. In fact, I'm going to segue for just a moment because you're reminding me that there's something I don't think I've shared with you yet. On my previous project, there was a particular feature. It was a big feature that someone had picked up and worked on.

+ +

And at one point, we were essentially playing hot potato with this feature because we hadn't gotten it to the point that it was merged. There was too much that was happening in that pull request, although then we ended up merging it. But then we found lots of bugs. And it was just one of those features that we couldn't really get across the finish line. There was always something else that was wrong with it or needed to be done or needed to be considered.

+ +

And we'd reach that point where Chad Pytel, who is on the project, was like, "We're either going to finish this, or we're going to throw it away." And I felt a little guilty saying this, and I was like, "I vote we throw it away. I have lots of concerns about this. We are essentially reimplementing another complex workflow. But now, we are implementing it pretty differently in another portion of the application. It's going to be hard to manage. The cost of adding this and maintaining this is a really high concern." And so he talked with the rest of the team and came back, and he's like, "Yep, we're going to throw it away." And so then he issued a PR, and we removed it.

+ +

And it was one of those moments of like; this isn't great because then we have invested hours into this, and now we are taking it away. But it also felt really good that that's always an option. And that was the better option because it was either we're going to continue sinking more time into this, or we can stop it now. And then we can move on to more important work.

+ +

CHRIS: Sunk costs and all that.

+ +

STEPH: Yeah. I feel like it's so rare when that really happens because then we just feel dedicated to like, well, we're going to make this valuable to somebody. We're going to keep this. And in this case, we just threw it away. It's very nice.

+ +

CHRIS: There's a similar anecdote that I remember. Actually, I think it's happened more than once. But very particularly, we were working on a system. And this was with our friend, Matt Sumner, a friend of the show, as well been on a few times. And Matt was working on the project. And we got to a point where we had two competing implementations of a given workflow, and we were opting to go with the new one.

+ +

But there were folks that were saying, "Let's keep the code around for the old one." And Matt was like, "Absolutely not. If we do that, we might go...no, this will be bad. Then we have to maintain that code. We need to burn the ships," as he said. And he actually named the pull request burn the ships where he just removed all the code. And I was like, I like your style, man. You made a decision here. We collectively made a decision. And then this is a classic Matt Sumner move. But he did the thing that we said we were going to do. And he just held that line. And I really appreciated it.

+ +

And it's a voice that I have in the back of my head often now, which is just like, no, burn the ships. If we need it, it'll be in Git history. We can recover it. But it's going to need to be handled in the interim. We don't want to have to support that code right now and for however long until we actually decide to remove it from the codebase. So let's get rid of it. And if we really need it, well, then we'll resurrect it, but for now, burn the ships. And I like that.

+ +

STEPH: I like that too. I think it's one of those areas where it takes experience to feel that pain too. If you're pretty new to writing code, you're going to think, well, we can keep it around. There's no harm. And so it often has to be that sage, that person who's been around long enough and felt some pain from making that decision in prior centuries or years. And he's like, "No, we're not going to do this." The WE collective of developers who have experienced the pain from this understand that that's not a good choice. And so we're going to burn the ships instead. But it is one of those that if you're newer, you won't think that way. And I think that's totally reasonable that you wouldn't think that immediately.

+ +

CHRIS: I think that tacit knowledge that oh, I've gone through this before, and I've experienced the pain, and now let me tell you about that. And let me try and share that with you because there's always the cost-benefit trade-off. Because if that code stays in the codebase, then we know it works because we've kept it around for that whole time. And so there's a nicety to that, but there's a cost, that maintenance cost. And being able to express that well and being able to say, "I've been here, and let me tell you a tale," but do it in a way that doesn't sound overly condescending or explainy or things like that. I think that's a very subtle skill and a very important one, and frankly, really hard one to get right.

+ +

I'm not sure I always hit the mark on that where I'm just like, "No, can't do it. It's bad." I think it's very easy to end up in a space where you're just like, "No, it's bad." And they're like, "But why?" And you're like, "Because it's bad. Trust me." It's like, well, I feel like you do need to be able to explain the stories, the experiences that you've had in the past, the anecdotes that you've heard, the blog posts that you've read that have really informed your thinking. But I think that is a big part of what it means to continue on in this profession and be able to do the work and make those subtle trade-offs, and the it depends because, at the end of the day, it all depends.

+ +

STEPH: Or you just issue a pull request and title it burn the ships. [laughs]

+ +

CHRIS: Burn the ships. Indeed, that is, in fact an option. And actually, while we're on the topic of pull requests, this might be a perfect segue into a listener question that we have.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: As always, thanks to everyone who sends in listener questions. We so appreciate getting them. They help direct the conversation and give us something to chat about. So this question comes in from Bryan Robles. And Bryan writes in about large pull requests. And Bryan writes in with, "My toxic trait is large pull requests. Any tips on when you get into a place where you're fixing or refactoring something, and it ends up cascading to many more changes than you want it to? I sometimes can go back and break it up. But it's hard to recognize a good seam when you're in the thick of it." So, Steph, what do you think? Large pull requests and finding yourself in them after [laughs] certain amounts of time.

+ +

STEPH: Yeah, speaking of that knowledge that often comes from experience, this is something that I'm certainly always striving to get better at. I think it does take practice. There are some things that I do that I can share. And I categorize them really into a before, and I guess midway. So there's the before I set sail and set off to deeper waters list that I will think through as I'm starting a new task, and then there's the I'm lost at sea. And then, I need to figure out how I'm going to organize this change.

+ +

So in the first category, when I'm first starting off a task, I consider what sort of changes need to be made, and are there any obvious roadblocks? So an obvious roadblock may be changing or updating a model that has one relationship, and I need to change it to has many relationships. Or perhaps there's a part of the application that is untested. And before I make any changes, I need to document that existing behavior. And that really falls neatly within Kent Beck's advice where he said, "First make the change easy (warning: this might be hard) and then make the easy change."

+ +

So I try to think upfront what are some of the small, incremental changes that I can make first that will then make the final change easy? And then I separate that mentally into PRs. Or I may separate it into tickets, whatever is going to help me stay organized and communicate how I'm breaking up that work.

+ +

And then the other thing that I'll do is I'll consider what's my MVP? So what's my minimum viable pull request? What set of changes include just enough changes to be helpful to users or to other developers? Which, by the way, is also a helpful mindset to have when you're breaking down work into tickets. So, as an example, let's say that I need to fix some bad data that's causing a site to error. So my first step could be to write a task to fix the bad data. And then, step two, prevent bad data from being created. And then probably step three, I need to rerun the task to fix data that was created during step two. But I can think through each of those steps and separate them into different pull requests.

+ +

And then there may also be the question of well, how small is too small? Like you're saying, what's a minimum viable pull request? How do I know if I am not delivering value? And that one gets a little trickier and vague. But ultimately, I will think, does it pass CI? Is this change deployable? And then I do have to define what value I'm delivering. And I think that's a common area that folks struggle because we'll think of delivering value as delivering a whole new feature or adding complete test coverage for an untested interface.

+ +

But delivering value doesn't have to represent that end goal. It may be that you added one test for an untested interface. And that's still delivering really great value to your team, same for delivering a feature to a user. You may be able to speak with that wonderful product manager and find what's the smallest bit of value that you can deliver instead of the whole feature set? I think the smallest PR I can think of that I've issued is either fixing a typo or removing a focus metadata from an RSpec test. So that's my starting point. That's the before I set sail. Those are some of the things I think about. I have more for the I'm lost at sea. But what are your thoughts?

+ +

CHRIS: First, that was a great summary that you gave. So I totally agree with everything that you just said. I think part of the question I would have...So Bryan wrote this in and described this as his toxic trait. So he's identifying this as something that seemingly consistently plagues him.

+ +

So I would ask, is there a way that you can introduce something? Like, are there natural breaks in your day? And can you ask the question at those breaks? Like, hey, I've been working on a thing for a little while. Is there a version that I could...like, could I close off a body of work at this moment? When you break for lunch, if you go grab coffee in the morning, when you're leaving at the end of the day, use those natural breakpoints.

+ +

I'm not sure exactly what you mean when you say large pull requests. But if those are spanning multiple days, in my mind, if anything starts to span more than a day, I will start to ask that question to myself. And that's a reflex that I built up over time by feeling the pain of large pull requests and putting it up, and feeling apologetic. And then having my colleagues gently, professionally kindly ask me to break it down into smaller pieces. And me saying, "I really don't want it. All right, fine, fine, fine, I'll do it." And then I do it.

+ +

And it's one of those things that I never want to do in the first place, but I'm always happy to have done after the fact. But it is work. And so, if I can get better at pulling that thinking and pulling that question earlier in the process, that I think is really useful. Similarly, I will try to, again, as friendly as I can; if I notice someone mentioning the same body of work at stand up for a few days, I might gently ask, "Hey, is there a way that we can find a shippable version of a portion of that of a subset? Can we put it up behind a feature flag and get something out there just to try and keep the PR small, et cetera?" And so gently nudge in that direction.

+ +

And then I think the other side of that is being very okay with one character PRs. Like, that's it. We changed one character. It turns out we need to pluralize that word, or we need one-line changes are great. That's fine. And more pull requests, in my mind, are better than fewer, larger pull requests. And so really embracing that and having that be part of the core conversation and demonstrating that throughout the team is a way to share this idea. So that's perhaps more in the process or person point of view on this as opposed to the technical, but that's part of the consideration that I would have. I am interested, and I'll bounce back to, Steph, what you were saying of now that you're out at sea, what do you do?

+ +

STEPH: So I need to react positively to some of the things that you just said because you made me think of two things. One of them is I've never had someone say, "Hey, Steph, that PR is too small. Could you add some more changes to it? Could you do some more work?" I have had people say, "Hey, that PR was hard to review." But even then, sometimes getting that feedback from folks is hard because nobody really wants to say, "I had a hard time reviewing your PR." That's something that, over time, you may become really comfortable saying to someone.

+ +

But I think initially, people don't want to say, "Hey, that was hard to review," or "There were a lot of changes in that. Would you break it down?" Because that's a lot of complex emotions and discussion to have there. But yeah, I just figured I'd share that I have never had someone complain that a PR is too small, and I've issued a single character change.

+ +

And then I love, love how much you asked the question of what's the problem we're trying to solve? And so there's this ambiguous idea of a large PR. But what does that mean? What are the pain points? What are we actually looking to change about our behavior? And then how is that going to impact or benefit the team or benefit ourselves? And so, going back to the question of how do we measure this? How do I know I'm starting to break up my changes in a helpful way? We may need to circle back to that because I don't have answers to it. But I just really like asking that question.

+ +

As for the I'm lost at sea part, or maybe you're not lost at sea, but you've caught too many fish, and the fish warden is going to fuss at you if you bring too many fish back to dock. I don't think this is a real nautical example. But here we are.

+ +

CHRIS: Was that the fish warden?

+ +

STEPH: Yeah, the fish warden. You know, the fish warden. [laughs]

+ +

CHRIS: Sure, I do, yeah. Yeah, I know about that, well-versed in fish law.

+ +

STEPH: [laughs] Got to know your fish law. If we're going to talk about pull requests, you got to introduce fish law. But I'm actually going to quote Joël Quenneville, a fellow thoughtboter, because they shared a thoughtful thread on Twitter that talks a lot about breaking up your changes and how to break up your pull requests and your commits. And I'll be sure to include a link in the show notes because it's really worth reading as there's a lot of knowledge in that thread.

+ +

But one of the things that Joël says is get comfortable with Git, and it makes a world of difference. In particular, you want to get really good at git add --patch, git reset, and git rebase interactive. And that is so true for me. Once I have gotten really good at using those commands, then I feel like I can break up anything.

+ +

Because often when I am helping someone break something up, it's often they want to, but they're like, "I don't know how. And this is going to take so much of my time. It doesn't feel efficient and the right thing to do." And they're probably right. If you don't know how to break it up, then it may take you too long. And maybe it's not worth it at that point.

+ +

But if you can ask a friend, and they can help walk you through this process, or if you can learn on your own, that's going to be a game-changer because you will start to think about how can I separate these commits? And I can reorder them, and then issue separate PRs, or just keep them in separate commits, whatever process you're looking to improve.

+ +

In fact, there's a really great course on Upcase called Mastering Git written by someone who is co-host of this podcast. And it has a lot of great videos and tutorials that will help you get really good at these Git commands and then will help you split up your commits.

+ +

CHRIS: Oh yeah, I did do that. Warning: it's like three and a half hours long. But it is broken up into, I believe, 10 or 11 videos. So you can find just the ones that you want. There's a couple in the middle that I think are particularly useful talking about the object model of Git. Git is weird, unfortunately. And so I spent a bunch of time in that course. Also, thank you for the kind words, Steph. [laughs]

+ +

But I spent a bunch of time in that course trying to make Git less weird or understandable. If you look under the hood, it starts to make more sense. But if you really want to get comfortable with manipulating Git history, which I think is a really useful skill for this conversation that we're having, that's the only way I found to do it, just memorizing the steps.

+ +

It's always going to feel a little bit foreign. But once you understand the stuff under the hood, that's a really useful thing for being able to manipulate and tease apart a pull request and break it into different things, and port things from one branch to another, and all those fun activities. Yeah, man, that was a bunch of years ago too. I wonder what I look like in it. Huh.

+ +

STEPH: I really liked that episode, the one you just mentioned, the Git Object Model. Now that you've mentioned it, I remember watching it, and it's very interesting. So yeah, thank you for making all this helpful content for folks. There's also a blog post that we can include in the show notes as well that is a really nice overview of using git interactive, and rebase, and squash and amend those types of behaviors as well. So will be sure to include both so folks can check those out.

+ +

And then to round things out, one of the other things that I will do is I will ask a friend. I will ask someone for help. So we've talked about some of these behaviors, or some of these processes that we have are really built up from experience and practice. And you can watch a lot of helpful content, and you can read blog posts. But sometimes, it really just takes time to get good at it. I know, as I'd mentioned earlier, I am always still looking to improve this particular skill because I think it's so valuable.

+ +

And one of the ways I do that is I will just phone a friend. And I'll say, "Hey, can we chat for a bit? I would like to show you my changes. I want to hear from you if you see something in here that's valuable that you think can be shipped independently, so that way we can get it delivered faster." Or it may be a change that's just like a test improvement or something. And we can go ahead and get that immediately released to the team, and it will benefit them.

+ +

Or you may want to do this at the start of a ticket. If I am new to a project or when I am new to a project, I will often ask someone to break down a ticket with me if I'm feeling a little bit uncertain. Or just say, "Hey, do you see any clean lines of division here? I feel like there's a lot in this ticket. You're more familiar with the codebase. What would you ship? How would you ship this incrementally?" and have someone else walk through the process with you.

+ +

CHRIS: Yep, the phone a friend and/or, as always, pairing is a wonderful tool in these sorts of situations. The one other thing that comes to mind for me is part of the question was about sometimes it's difficult to find a clear parting line within a larger body of work, within a larger change. And that can definitely be true.

+ +

I think there are certain standouts of like is this a refactoring that can be shipped separately? Is this a test change that would be useful on its own? Is there a model change that we could break out and have just that go out? So there's a bunch of mechanical questions that we can ask and say; here’s categories of things that might fit that bill.

+ +

But to flip this to the other side, the question was asked by Bryan very much as an I struggle with this thing. This is my toxic trait is the phrase that he used, which I thought was really interesting. And that can be true. This can be something that if you're consistently and uniquely within the team producing these giant PRs and then folks find that difficult to review, then I think that is absolutely something to work on.

+ +

But if this is something that is happening between members like, other members of the team are also finding that they keep ending up with PRs that are bigger than they expected and taking longer and harder to review, there is a question of is the codebase actually in a shape that makes it harder to do small changes? There's the phrase shotgun surgery, which refers to a codebase that is so entangled and coupled that any change requires modifying ten files just to make one small alteration.

+ +

And I think that's a worthwhile question to step back and ask, actually, is it not me? Is it actually the codebase? It could be both certainly. But there is a version of your codebase is coupled in a way that means that any even small, tiny change requires touching so many different places in the code. And if that's true, that's at least worth naming and worth highlighting and maybe talking about in retro and saying, hey, this feels like it's true. So maybe we start to get intentional about refactoring, and breaking out, and starting to add those dividing lines within the code such that hopefully, down the road, small changes can, in fact, be small changes. So that is the one last thing that I would consider here.

+ +

Also, anecdotally, this is just a thing that came to mind. As I've worked with strongly-typed languages, systems that have a compiler, and have a type system, and the ability for the compiler to keep an eye on the whole codebase, I've noticed that it's very easy to do this sort of thing where I just start with one small data model change, and then the compiler is like, oh, you got to go fix it here, and here, and here, and here.

+ +

And I found that because the compiler is your friend and will just point you to all the places you need to make the change, it is very easy to just keep going because some of that mechanical work is happening on your behalf. And it's a wonderful facet of typed languages and of having a compiler and being able to have that conversation with the compiler.

+ +

But I found that for me, it is much easier to end up in this mode where I'm like, oh no, this PR is way too large. When I'm working in a system that has types, that has a compiler, that frankly makes it a little bit easier to chase down all the places you need to make a change. So that's also a consideration. It's not necessarily a good or a bad thing, just something that I've observed that feels like it's adjacent to this conversation. But yeah, I think those are my thoughts.

+ +

STEPH: Yeah, those are great points. I've certainly worked on projects where that felt very true where it's a small change, but it would cascade throughout the project. And all the changes were necessary. It wasn't something that I could split into smaller PRs. So checking if it is the codebase that's really making it hard to have small PRS is a really great idea.

+ +

CHRIS: Who'd have thunk such a little question could get us rambling for so long? Oh, wait, I would have thunk that.

+ +

STEPH: And so far, reflecting on the things that we've talked about so far, I think I've talked a good game of where I'm saying, "Oh, I identify the seams upfront, and then I organize and create different tickets." And that is very much not the case. That's the really ideal outcome. But often, I am in the thick of things where like you just said...and it's this moment of, oh, I've done a lot in this PR. And how can I break this up? And that does take time. And it becomes a conversation of trade-off, which is why those Git skills really come in handy because then it will lower the cost of then splitting things out for others.

+ +

But for people that are struggling with creating smaller PRs, I do think it's very fair to ask your team for help. I think it's also fair that if you issued a large pull request and folks have already reviewed it, and it's gotten approved, and someone makes a comment like, "Oh, this would be great as two PRs instead of one," to say, "Awesome, thank you for letting me know. I will take that forward with me, but I'm not going to do it for this PR."

+ +

I wouldn't recommend making that a habit. But just know that that is something that you can say to someone to say, "I think this one is good to go at this point. But I will keep that in mind for future PRs. And I may even reach out to you for help if I feel like I'm having trouble splitting up a PR." And bring that person into your progress and use them as an accountability buddy. They can be someone that helps you down that path towards smaller PRs.

+ +

CHRIS: Yeah, I definitely agree with that, although it becomes a very subtle line. Saying, "Thank you, but no thank you," in a pull request or to feedback is delicate. It's difficult. That's a whole thing. But I agree there have been times where I have either been the one making that decision or suggesting that or being like, "We probably should have broken this up. But we're far enough along now. Let's get this merged. And then we'll iterate on it after the fact."

+ +

One last thing, actually. I thought I was done, but I have one more thing, which is I feel like there's a strong parallel between test-driven development and this question in that, often, I hear folks saying, "I don't know how to write tests upfront. I don't know how to do that. I know after the fact I can write tests, and I can add them after." And that can definitely be true. It can become more obvious after you've written the code how you could then write a test that would constrain that behavior that would interact with the system.

+ +

But I think the useful thing that you can do there is take a moment and pause there and say, "Okay, now that I have written the test, what would it look like if I had written this in the first place?" Or if you really want to go for it, throw away the code, try again. Start with the test first and then rebuild it. That's maybe a little much.

+ +

But that thing of taking these moments of maybe you don't know upfront how to break the work into smaller pieces, but then you get to the end, and you have that conversation with someone. And they highlight where some parting lines would be, or you figure it out after the fact. Stay there in that moment. Meditate on it a bit and try and internalize that knowledge because that's how moving forward, you might know how to do this in the future. So take those moments, whether it be with TDD or with pull requests, or breaking up a ticket into smaller tickets, anything like that. And spend a moment there and try and internalize that knowledge so that you have it proactively moving forward.

+ +

STEPH: You know how Slack has status? I really like the idea of there being a status that's meditating on...and you can fill it in. And the example that you just provided, meditating on splitting up a pull request or meditating on how to write a test first, [laughs] I think that would be delightful.

+ +

CHRIS: I, too, think that would be delightful. But with that long, adventurous answer to what seemed like a simple question, and they always do, but here we are, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ap2r9ijx + + ]]> + + Chris Toomey + Steph Viccari + + + 316: Constrain and Refactor + https://bikeshed.thoughtbot.com/316 + 932d9f15-407b-4d21-98ac-0408b0143678 + Tue, 16 Nov 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Chris finally got his new computer! 🎉 🎉 🎉 He gives his initial review. He's also super excited that GitHub announced a beta for pull requests merge queue, and even more excited that multiple people who listen to this show very kindly pointed that out to him on Twitter! + +Steph discovered something that is quite niche, but she's excited to tinker with it more, called CookLang. It's a markup language that's designed for cooking and recipe management so you can store recipes and text files and there's no database required; making it easy to have control over recipes versus storing them in a separate application. + +Then they answer a listener question about refactoring murky legacy code. + 39:33 + no + + + Chris finally got his new computer! 🎉 🎉 🎉 He gives his initial review. He's also super excited that GitHub announced a beta for pull requests merge queue, and even more excited that multiple people who listen to this show very kindly pointed that out to him on Twitter! +Steph discovered something that is quite niche, but she's excited to tinker with it more, called CookLang. It's a markup language that's designed for cooking and recipe management so you can store recipes and text files and there's no database required; making it easy to have control over recipes versus storing them in a separate application. +Then they answer a listener question about refactoring murky legacy code. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +CookLang (https://cooklang.org/) – Recipe Markup Language +Pull Request Merge Queue Limited Beta (https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/) | GitHub Changelog +After_party (https://github.com/theSteveMitchell/after_party) - Automated post-deploy tasks for Ruby/Rails +Therapeutic Refactoring by Katrina Owen (https://www.youtube.com/watch?v=J4dlF0kcThQ) +Unused (https://unused.codes/) - Identify unused code in Rails, Phoenix, and other types of applications. +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? +CHRIS: What's new in my world? Well, we've talked about it before, but it has finally happened. I finally got a new computer. +STEPH: Yay, yay. +CHRIS: Five years in the making. I held out, I waited. The new computer is fantastic. I'm in that transition phase of trying to set everything up and get it all...the particular thing holding me back is actually this recording and some dongles. I need to live that USB-C life now. Everything needs new connections and whatnot, particularly my external monitor. +STEPH: I'm now realizing how old your current laptop is. +CHRIS: [laughs] Did I just date myself? Yes. +STEPH: You did. You just dated it with a USB-C. I thought you were still on the USB-C life. +CHRIS: I'm pretty sure it's a 2016. I'm currently recording on a 2016 MacBook Pro. But yeah, I'm very excited with the new one. The shape of them is weird. I did not expect this because I've seen the 13-inch MacBook Pros that have the touch bar and other things that I didn't really want. But the shape of that laptop was more familiar to me. And this one, I don't know, it's weirder and rounder and bulkier in ways that I didn't expect. And it's heavier than I expected. I got the 14-inch, as an aside. I went with a slightly smaller version assuming that my 16-inch with a giant bezel, because it's from the past, would have a similar amount of screen real estate to a 14-inch with no bezels or with the screen going almost out to the edges. +As an aside, the notch in the top of the computer screen is ridiculous. I've dealt with it on the phone for a while now. I accepted that I live in the land of notches. But somehow, it's way, way worse on the computer like when I take my terminal full screen most of the time, and so stuff just gets lost. I don’t know, I got to deal with this or not, maybe I can just not care. But it is covering things that I want to read. And I'm like, well, this is annoying. +But yeah, beyond the notch, everything else is great. It's a nice form factor. It seems to have great battery life. It's very fast. It goes very fast. It also has...there's more RAM in it. There's more hard drive space and whatnot, so a bunch of the things that I use. Often as we start this recording I'm like, oh no, I wonder if I have enough hard drive space for the recording we're about to do, which I should probably be past that at this point in my life. Well, now I think I am, except I haven't yet ported my recording setup. +Nonetheless, I'm very excited. And particularly, a lot of the development workflow tasks like starting up the dev server of the project that I'm on just moves a lot more quickly. It's a lot snappier, and everything is just speedier. The fans don't really turn on. It doesn't get too hot even when I'm doing challenging things, downloading everything from the internet and compiling from source code. It's like, yeah, cool; I can do that. That seems like a thing that's well within my wheelhouse. And I'm like, cool, computer, good job. Glad to have you on the team. +STEPH: So I learned something about you recently because hey, we were hanging out in person recently since I was in Boston for a week. That was amazing. And I learned that we have a similar thing where we both like to start our machines from scratch, and slowly (or at least correct me as I'm going through this), we bring things over. But it's not an immediate just port everything from my current laptop over to my new laptop. And I'm fascinated because I thought I was the only one with this sickness. But it turns out that you, my friend, also have this in your life. +CHRIS: Well, yes, you are correct. That is the thing that is true. And also, to reiterate, it was really lovely seeing you in the human world as opposed to just in a Skype window as we so often do. But yes, I start fresh every time. But to be clear, it's been more than five years since the last time I did this. So I feel like I can make a bit of an event of it each time I do it. So I'm fine with that. But I do like starting from fresh reinstalling everything rather than trying to copy over an image of the system. +I felt a little bit shamed by the operating system because there's the like, welcome to your new Mac. What's your language? What's your WiFi? What do you want to migrate over? And I'm like, nothing. But there wasn't a button for no, thank you. [chuckles] There were buttons that were like...there were two different options, but neither of them were no. And I'm just staring at it, and I'm like, but I would like to not though. I would like to just start fresh. +STEPH: [laughs] +CHRIS: And I got it from here. I appreciate the effort. Turns out they were hiding it in the bottom left corner, but it wasn't a button. It was like link text, but it was barely emphasized. And on the right were where all the action buttons for every previous step and subsequent step were. So this was like no one would ever want to do this. So we're just going to hide the option over in the corner. +Yes, I very much like starting fresh. I like to get the chance to shed some of the mistakes of the past and only bring forward the things that are bringing me joy in the modern-day, so here we are. A lot of stuff doesn't work, by the way. [laughter] I brought over my dotfiles, and things did not work super great. Or I opened an application, and it's like, oh, that hasn't worked for years, and I'm like, I was living in the past. All right, this is fine. I'll update my workflow. It'll be okay. +STEPH: I like how you said make an event of it because I haven't really found the right words for it, but that's perfect. I have a fresh laptop, and it's an event, and I want to spend that time setting it up and shutting the mistakes of the past. [laughs] That too, that also resonates. +CHRIS: Yep. It's really about the mistakes of the past. I don't want to live there anymore. I want to move on from them. But overall, yeah, it's going well. I think I'll be able to work with it. I'm actually unfortunately limited in that I can't connect it to my monitor right now or to the keyboard that I have and whatnot. So I can't quite integrate it into my home office setup. I can use the laptop itself, and it's working fine. I've got my current project running on it. +So I was able to install Ruby and figure out how do I trick it into using the Homebrew things versus the M1 things versus which architecture and yadda yadda yadda? That actually went better than I expected. I thought it was going to have more issues there, but stuff just kind of worked. And I had to find one weird Stack Overflow and copied and pasted as one does when you're setting up new computers or all the time as a programmer. And then yeah, we're off to the races. But yeah, unfortunately, right now, the limitation is a physical cable. I need a couple of new cables. So I'm excited to get those in the near term. +STEPH: Yeah, that'll be nice to have it set up and feel like you can fully transition to the new setup. +CHRIS: But in slightly other news, so computer is great, very happy about that. Perhaps I’m even more excited that GitHub has announced a beta for pull requests merge queue, and even more so excited that multiple people who listen to this show very kindly pointed that out to me on Twitter. And I was like, this is the dream. I just rant about stuff on a podcast, and then people tell me when the world has solved the problem that I complained about. This is so great. +But it's a public beta, but you go on an invite list and whatnot. So I'm on that list right now. And I'm trying to just mention it as much as possible, especially near any friends I know that happen to work at GitHub; just be like, "Hey, if you happen to know how to find that list...and I will give wonderful feedback. I will be an active member of this beta." But I would really love to get to try out that feature. So I'm excited. +We'll include show note links to the blog post announcing this new feature. So I'm really excited that it is built into the platform and will sort of be there. And I'm hopeful that GitHub has done a great job. This is actually a really interesting feature in my mind. It's one of those things like, oh, it's pretty straightforward. You just make a queue, and then you merge things. It's like, oh yeah, but what about all the ways it can go wrong? It's a great I think iceberg feature where the simple, happy path is wonderful. +And then there are so many different failure modes like, oh, what do you do when the PR fails to rebase? Or should you proactively rebuild the sequence of them? Do you stack them up and start preemptively rebuilding the other PRs that are next in line in the queue after that? But what if then it fails? And et cetera, et cetera. There's lots of fun stuff that can go wrong. So I trust that GitHub will do a wonderful implementation. I would love to get to try that, but currently, I've yet to get in. +STEPH: Have they shared how to get access to the limited beta? Is it just random selection, or can you specifically request? It sounds like you can't, based on what you're saying, but I'm curious. +CHRIS: There is a waitlist. Particularly, they had me put the repo that I was interested in, so like, I would like to be in the beta. And this repo, in particular, is the one that I would like to put into the beta. So I've submitted that, but now I'm just in a list. I don't know where in the list I am. I have no visibility into that. So again, I'm just saying things out into the void and seeing if the universe then reflects anything back at me, and by that, I mean people that work at GitHub. Hi, friends. +STEPH: I totally believe that if you speak things into the universe, the universe will give that back to you, or that's probably not true. So here's hoping that you get into the beta list. +CHRIS: Here's hoping. One other tiny thing I have been using Afterparty a bunch lately, which is a gem that you have recommended to me, I believe, in a previous episode not that long ago. But we started doing feature flags. Feature flags are great. We're using Flipper. It's wonderful. But Flipper stores...the way we've configured it, we're storing them in the database. And so, when we get to the point where we want to fully release a feature, we dial-up so that everyone has access to it. So at this point, the feature flag system is still running, but everyone is getting access to that feature. And so then there's a code change that removes any references to the feature flag, any checks for it. +And subsequently, we want to then clean up after ourselves. Afterparty has been fantastic. I'm really happy with the way that that works and that we can just include the Afterparty data migration associated with that, delete the record from the database, and then everything consistently works together. This does poke at the edge, though, of how Heroku does deployments and the fact that there is that latency where it will basically restart with the new code, needs to run all migration steps, et cetera, et cetera. And then it's running on the new code, which is great. That's what I want in this case. But it does have a cost, and I would love to figure out true blue-green deployments sometime in my usage of Heroku such that we can have zero downtime deployments is actually the way to phrase it. +Using Afterparty for this, I think, is leveraging the idea that it's not a big deal. It'll be fine. Because if we had zero downtime deployments, I think temporarily, we would be in a space where feature flag has been deleted; therefore, no one is in the feature. Therefore, no one would see it for that weird second. I'm safe from that. But it's this weird trade-off that I have in my mind of I want blue-green deployments, but I'm appreciating that I don't have them right now and that there is a consistent...and I think that's the reason that Heroku makes the choice that they do. But, man, everything's complicated. Why can't stuff just be simple? +STEPH: Everything is complicated. So I'm thinking back through to now my previous client's setup since I'm about to transition to a new project. And we have AWS. We have rolling deploys, so we don't have that specific downtime. We are using Afterparty. So I think based on everything that you're saying that yes, there's a slight period of where we are rolling out a feature flag or potentially dropping it, and that could put some users into a weird state if they're active and then the code suddenly changes. I'm thinking through out loud and singing it because apparently, that is what I do. We haven't run into any issues with that. But I am now trying to think through of when someone might end up in a weird state because of that. +CHRIS: You almost certainly won't run into any issues because we're talking about a matter of seconds where the code is in an inconsistent state. But the same thing applies to migrations like database migrations where if you're doing rolling deployments and the database migration hasn't happened yet, but there's new code that's running that expects that database state, then you're in this subtly inconsistent mode. +And I think if you really want to adopt this idea of rolling deployments or zero downtime deployments, you have to separate data changes from the code that uses that data change such that both versions of the code when the migration goes out are fine. And then later, you deploy the code that uses the migration, but then that's like a whole bunch of more steps. And you got to think about it, and you have to probably put in some pull request review step to check on it. And so again, it's just complicated. +STEPH: So that's one of the reasons we did change our feature flag implementation was because we realized it was a pain. Because anytime that we wanted to drop feature flags, we first issued a PR that removed any references in the code to that feature flag, let that deploy. And then we'd issue a separate pull request that went out in a different deploy that went and dropped that column. So that way, we didn't have any situations where maybe ActiveRecord has cached to that column, and then there's code that's looking for it, but then it's not actually there. And then you run into that funkiness and complicated behavior. +So we were at a point where removing a feature flag required two PRs and two deploys, and that was awful. So we switched up how we were handling feature flags specifically so we could avoid that and started storing them in JSON files because we took the more bespoke approach to feature flags versus using Flipper. +CHRIS: Bespoke artisanal feature flags. +STEPH: I don't know that I'd recommend it. It's working. It's been a journey, and there are things working well about it. But it's definitely still in that space where it's like, I'm a little uncomfortable of like, how far should we go in this bespoke world and at what point we should reconsider and use something like Flipper. I would say stay tuned, but I'm not on that project anymore. So I'll just never know. [laughs] Sounds like a devious laugh. I will know probably from some friends that are on the project, but I won't be there for it. [laughs] +CHRIS: Cool. Well, yeah, I think that sums up things in my world. What's new in your world? +STEPH: I have discovered something that's quite niche, but I'm excited to tinker with it more. It's called CookLang. And it's a markup language that's designed for cooking and recipe management. So you can store recipes and text files, and there's no database that's required. So it's easy to have control over your recipes versus storing them in a separate application, which is currently how I store my recipes. Which for the record, I'm happy to pay for software. I am very appreciative of when people make my life easier. And so I very much enjoy that. But I also still love the it's mine, and I can just have it stored somewhere in the cloud, and I'll never lose it. And I don't have to worry about renewing memberships to keep access to something. So there's a part of me that is very drawn to the idea that I can just have everything in the text file. I can store it anywhere that I want. +And then, for this particular CookLang markup language, it lets you define certain qualities of your recipe. So you can define the ingredients, the quantity, cookware, timers. It'll help you create shopping lists, and you can set metadata. So maybe you want to include the total prep time or the type of meal, or the number of people that the recipe serves. And they also have an iOS app that is in beta. So speaking of beta, this one is closed at the moment because they've had a pretty overwhelming positive response or interest. So they have shut it down for now in terms of accepting new people to the beta; at least, that's my current understanding. +But the iOS app does look like it'll be really nice. It's going to read from your files; I think stored in iTunes. But I'm just excited for all of this. It looks very interesting. And it looks like something that's just fun to play with. So I haven't moved anything over to start really investing and creating these .cook files that you use for the cook language. But it all seems very cute, very niche, and something I'm totally into. +CHRIS: I have not seen this, but it looks absolutely fantastic. I'm just reading the brief syntax snippet that they have at the top and the way that they're inferring semantic meaning from plain text recipes. And then you can generate a shopping list, super cool. You can just be like; I’m going to cook these things from my recipes. And then they'll tell you the shopping list, and it's grouped. +And this feels like what software should be in my mind. This doesn't feel like we're going too far with it, which is very easy to do. But it's like, no, no, we've annotated just a little bit of semantic meaning on top of something. And then with that, we can do wonderful things. Look at all the good stuff that falls out of it. We can have an iOS app. We can generate shopping lists. It's great. But it's also minimal and contained, and not locked in a proprietary format. And this is fantastic. +STEPH: There's also the nice part where they've already started highlighting that people can just store their recipes on GitHub. And then you can just fork recipes, or you can import everybody else's recipes. And I love that. I want more open-source recipes, although frankly, there are tons of just free amount of work and recipes that people have on the internet. But I love this because then I could skip all the ads that go with it. And I can just grab the stuff that I care about. +CHRIS: You mean you don't want to hear the person's life story before every single recipe. You don't want to hear about the walk that they took along the river when they were thinking about seasonal gourds, and then they decided to make a particular -- [laughs] +STEPH: [chuckles] I would normally...previous Stephanie would have been snarky about that in regards to all of that backstory that's given for a recipe. But then I saw somewhere maybe a friend was telling me about someone who had asked, "Why do y'all do this? Why are you putting so much information? Why can't I just have the recipe?" And they're like, "Well, frankly, Google's going to rank us a lot higher if we give you this whole backstory and if we look like there's more content to this page than just a recipe." And I'm like, dang. Okay, so it's Google that I have to be snarky about because they're doing their best in terms of trying to get you the recipe that you care about and make it very searchable. +CHRIS: Oh, yes. Absolutely. It's both a self-imposed problem. But also, I don't think Google's doing anything wrong here either. Google's part of their algorithm is they penalize duplicate content. And so there's what they view as the canonical source, the thing that's telling the truth. And then recipes look very much the same because they are kind of the same most of the time. This is how you make bread. This is also how you make bread. Two people now have almost identically the same content on the internet. And Google will penalize one that it determines to be copying essentially, which I think is a good thing broadly. +I've seen so many Stack Overflow...I want to say clones, but they're not even that. They're just literally taking the content and then republishing it entirely new. And that is a very bad thing that happens constantly and takes away from creators and whatnot. And so, in a way, Google's trying to do the right thing here, I think. But it leads to really just so much summary about recipes. It's one of those weird...is this a tragedy of the commons? I don't know. I've never quite understood that one. But I think it might be. +STEPH: Yeah, I don't know. That's my off-mic answer. [laughs] +CHRIS: That's fine. Someone on the internet will tell me whether or not this is a tragedy of the commons. But either way, I do not blame the recipe authors. I do not blame Google? You'll note the question in my voice. But I think I stand by that. I'm not sure who to blame. Maybe it's us. But here we are. [laughs] +STEPH: Yes, I like that final takeaway of let's not blame the people that are trying to give us wonderful, helpful content. Circling back a bit to some of the code that is powering CookLang or some of the interesting bits about CookLang, for anyone that's interested, you can also visit the GitHub repos they have. I believe everything is open source. There's a particular repo called spec. And you can view the issues, and you can see all the conversations around how should we annotate an ingredient? Or should we have comments in the language? And how should we handle this type of metadata? +And I find that interesting because I haven't really participated in any of the language crafting forums for Ruby or some of the other languages that I use. So it's neat to watch how some of this is being done in public to say, hey, we're just making this new markup language, and we're not really sure how we want to annotate everything. So what do people think? What's working for you? What's not? And I'm enjoying that conversation and reading along. +CHRIS: It really is such an interesting microcosm of an example of a language, an ecosystem, a community, a specification, and all of the stuff that is true of all of the other languages that we use more generally. But I'm looking down here, and there's the parser implementation. There's a Swift canonical parser. But then Rust, somebody is rewriting this in Rust because, of course, they are. But you know what? It's going to parse your recipe so fast, and it's going to be great. [laughter] But it does have the shape of everything that I've seen from other programming language conversations. And how do we evolve the language, and what syntax do we accept versus what do we not? And this is so interesting. +STEPH: Yeah, it's really neat. I'm really into it, and I'm really enjoying it thus far. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: So, changing gears just a bit, we have a listener question that frankly is a doozy of a listener question. It's a bit long, but I feel like all of the content in here is important. And I feel like most people are going to be able to relate to this scenario that the question is describing. So this question comes from Michael Kopinsky and Ben Rosenbach from Philadelphia. And they write in, "There's one area of our codebase which has a lot of skeletons." I'm already empathizing. "The UI is error-prone jQuery soup, and the UX doesn't entirely make sense. Test coverage is close to non-existent. And the expected behavior isn't clear and has lots of edge cases. +We've thought over the years of how we can redo it, but it's never a priority. Redoing it would be a huge lift, and...it works usually. We get bug reports occasionally, which inevitably get closed as won't fix workaround provided. But a few months ago, we received a bug report, and I decided to start cleaning things up. I opened a merge request with a set of factors extracting some behavior into a service object, making explicit some things that were implicit and adding test." Side note, that's some hero work. I appreciate that right there. "It's gone through a few cycles of code review and pairing each time suggesting additional cleanups to do, requesting additional test coverage and that sort of thing. But the more we do, the more we discover that needs to be done. +So at this point, the merge request has been open for about eight weeks. I've paired with two other developers for probably 12 hours. The user is impatient, and we're tired of this darn thing and want it to go away. But it feels so bad. It really is severely lacking in test coverage. And the expected behaviors still aren't clearly defined. And it just doesn't meet the normal quality standards that we try to hold ourselves to. We could sit for another 8 to 40 hours and write more tests or documentation, but we're so drained from this whole thing. +So overall, we're really struggling to balance two things. We want to get things out the door, have short-lived PRs, and focus on incremental improvement. However, we still don't have defined requirements of how the feature is supposed to work across all permutations. And we can't write proper tests until expected behavior is defined more clearly. It feels like that's a baseline requirement before being able to merge or refactor. We'd love to hear any thoughts. Sincerely, Michael and Ben." Ooh, friend, there is so much we can dive into here. Would you like me to get started, or would you like to start? +CHRIS: Yeah, I've got a handful of thoughts because, as you highlighted, this is all of the stuff. This is the murky pile of complexity that writing code and delivering value in an organization is made up of. I'm going to start at a random place and then just start saying things because I think there is not a singular answer to this is an important starting line. We're not going to say, oh, if you just did X, then it would be fine. Obviously, this is a number of different complexities and situations, both person or both interpersonal human, and then code, and et cetera, et cetera. +So one of the things that actually came in the latter part of what you were reading there is we do not have defined requirements as to how this feature is supposed to work across all permutations of how it can be used. And that one is really interesting to me because right now, I wonder if there's something that can be done there. So often, you have code that does some stuff but also could do other stuff. And it's not clear if it's actually intended to do that other stuff or if that's just something that falls out of overly permissive like, we'll take any data you throw at us, and then we'll do some stuff. Typically, we don't actually want that. We want a more constrained system that's doing something. So that particular part was really interesting. Some of the conversations about testing were really interesting. +I think one of the things I would do is I would really ask, is this worth the effort? This code is kind of doing its thing. It's been around for a while. It's business-critical, but nobody really understands. It's like, is there a version of just leaving it at rest? Probably not. I typically would not do that. But it is a question that I think is worth asking because it can be really hard to make these changes on an under-defined system written in legacy technologies and whatnot, especially ones that we don't necessarily have as much...like, I haven't worked in jQuery for a while. So I wouldn't be quite as good at that. I wouldn't be able to understand that code as intuitively. That might be similar for this team. +So is there a version of just letting it lie? That is the first question I would ask. Presuming that's not the case, then I think I start to look at what is the attack that I would take to approach this. And I would definitely start with, hopefully, some small but meaningful introductions of test coverage but as a standalone thing. It's not part of the big change of a pull request. It's merely trying to lock in the code as it exists. +Again, I think I've referenced this talk perhaps more than any other, but Katrina Owens'Therapeutic refactoring is a really wonderful story and talk and really talks through this idea in a great way, but also it's just fun watch. But in it, Katrina talks about her approach to a similar thing where she was like, there's some code, and nobody really knows what it does. So I'm going to try and lock it down. And the first thing that she does is wraps test coverage around this code. So at least whatever it's doing now, we've constrained it a little bit. And actually, via the testing that she does, she ends up using that as a mechanism to sort of what does this system do? And finds a way to exercise the system and determine what its behavior actually is because nobody really knows that at this point. +So I would start with the testing. And then I would ask the question of we don't really know what it does across all permutations. Is there a way to actually constrain that? And say, let's actually lock some stuff down. Let's add a tiny bit of code that looks at the inputs being requested or coming into this code path or whatever it is but actually explicitly delineates what we think is the expected inputs and rejects or at least logs things that are surprising and that are like, we don't think it should do any of this. And then suddenly, if you see that showing up in the logs, you're like, I guess it does need to do that. Now we have a better idea of what is the actual target that we're trying to hit. +But really, both of those in my mind are ways to try and constrain the problem to try and add a little bit of support before tackling the hard work of the refactor because, just to be clear, you're probably going to break it in the refactor. I've broken every single system like this that I've tried to refactor without question. And there's a certain amount of organizational trust that you need to have. And it just gets to be a very complex time. And so anything that I can do to provide some guide rails, some support, something to help me in that time is something that I'm going to start with before I even go near the refactor itself. So those are some thoughts scattered around throughout the question. What do you think, Steph? What comes top of mind for you as you hear this question? +STEPH: I think those are great thoughts. And to expand on what you're talking about determining the expected behavior, that's also one of the bits that jumped out to me. And I love that you asked the question, can we leave it at rest? It sounds like yes, but there are some user concerns that come through or some bug reports. And then the team has to collectively say, "Yes, we are going to put someone through a difficult time to either do maybe a gross fix or implementation." And then we're making this area of the codebase feel worse and more accepting of different flows and adding to the number of flows that we have. Or we document it as won't fix and then provide a workaround. +So I really like that you said, "Can we leave it at rest?" Because I think that helps a team make a decision together as to like, what is the understanding of this part of the codebase functionality? How important is it to the business? If we decide that it's not that important to the business, then it's frankly not worth anybody's time working on it even if it feels really bad and you know there's this gross code over here, and you really want to go work on it. But if it's not important to the business, then it just shouldn't be done. And it needs to be left alone until the business decides this is important to our functionality. We do want to prioritize this work, and we're going to work on it together. And I still think there are a couple of nuanced strategies even from there. +So if you're looking for the more incremental improvements of we can't totally let this lie...we do have to improve it. But we're also not willing to invest in an overhaul situation. So some of the incremental improvements would be, as you'd mentioned, adding some test coverage to it to at least start to lock in the behavior that's already there and establish a baseline of understanding and then document that behavior. I've also found that really helps for context switching. So if you go in and you just document one part of that system as something that it does, then it frees you up. You can add something. You can issue a smaller merge request. You can get that merged because you're just adding test coverage. So it's not going to break anything. You're not making code changes. But then you can nearly let that go. And you can jump to something else that the team or the business has decided that's more important. +Some other areas that I've used in the past for working in these types of legacy or just bug-prone areas is to look for flows that are no longer in use. So if there's something that stands out to me as like, I'm pretty sure users aren't using this, or this code just looks unused. Maybe it's running a tool like Unused, which we can link to in the show notes, and see if there's truly something that's unused that you can just immediately remove. Or maybe it's logging a message to Rollbar or something similar. So that way, you know this is actually being used, but you can have it log whenever that's being run. Let that live for a month and then go back and check to see if that flow is ever executed. +As for the larger overhaul approach, that really has to be a team effort. So this has to be one of those moments of like the company decides this is important. And there may be smaller wins you can look for, but I do think it's going to require at least a developer or the product manager to be invested and ideally a designer as well. And then some small steps there may be looking for reducing responsibility of that feature. So maybe it's this really verbose long form that's complicated. And maybe you can collect some of that information somewhere else in the app. So you can start to chip away at some of the responsibilities in that portion of the application. +Or maybe you have a mini design sprint. You may realize this is a very important part of your application. We should really have this be a better experience for users. And let's really take a hard look at what this does and start to document. And that's the bigger like we're going to rebuild this, or the whole team is going to focus on this and improve this portion of the application. So that was in response to some of the lovely things that you said that you made me think of. +The other thing that really jumped out to me is this merge request that's sitting because this person, Michael or Ben, they've already done some really hard work where they have decided to add test coverage. They've cleaned up some things. And I can certainly relate to you issue a pull request and someone...because you've started cleaning up a space, people are like, "Oh, what about that cobweb? And then you missed a spot. What about over here?" And so, how do you make progress when you're in that state? And I would say move the goal line and merge the pull request. +So your goal line sounds like right now is trying to address everything which doesn't feel humanly possible. So instead, move the goal line. Figure out okay, I just want to add these couple of tests, or I just want to add this refactor to a function or something that documents this part of the system. And if people are nervous about merging the current merge request because it has gotten so big and people have made so many small requests, is to then break it up into smaller, more focused PR. So then it makes it easier for people to say, "Yes, that does improve the state of this codebase. Please merge it." +And I will often prefix my PRs with that. I'll say, "Dear reviewer, this PR is intended to improve the state of the world. It does not improve everything because I can't, but this is the goal of this." So that way, people go in with the mindset of they'll realize they're still going to see some cruft. But this is still leading us towards a better place. And unless there are strong concerns about the changes made in that specific PR, any other requests need to be noted and then can be captured somewhere else, but we're not going to address it right now in this PR. +CHRIS: I agree so very much with all of the things you just said. For anyone at home who cannot see us on the Skype call that we're on, I was just aggressively nodding my head the entire time Steph was saying all of that. [chuckles] You touched on I think all of the additional points that I would want to make specific to this merge request is out there in the world and whatnot. +The one other tiny bit that I would add to it is I have definitely been the person, and then I've also been on the other side of it where people get attached to the code that they've written. "But I've already written the merge request." And you're like, "Yeah, but can you break it up?" And they're like, "Yeah, but it already is a thing. And I did a bunch of work. And now I'm emotionally invested in this pile of work getting across the finish line and breaking it apart..." We can get caught up in our code. +And this is a really great example of this thing just got away from you. This is too big of a refactor. It's too much of a risk. And so again, I have struggled with this personally where I'm like, I'm so proud of this pile of work that I just made. And people are like, "Yeah, but that's a big pile of work there." I'm like, "You're right. You're right. I should break this up. I will break this up." But I can feel that resistance in myself to doing that, what feels like extra work, what feels like almost undoing of work. It's like, "No, no, no. I think it's ready." I'll be like, "I don't know, I'm not convinced. Can we break it apart?" And that's almost always the right decision. But it can be painful. +And so, just knowing that and having that in the back of your head as a thing that my brain will tell me the opposite. My brain will be like, no, no, go with it. It's great. We're proud of this. But being open to the idea that breaking things up is good, smaller pieces are good, et cetera, et cetera, can be a useful psychological aspect of this conversation because,, of course, there's one more facet. There are so many facets to this question. +STEPH: I like that anecdote about that you haven't regretted breaking things up because I also relate to that where there's that initial like, I've already done this much work. And now you're asking me to do more work. And it's going to have the same outcome where it's still going to be the same code. It's still going to be the same set of changes, but you're asking me to break it up into smaller changes. And I just feel exhausted from this work already. And I don't want to have to break this up. So I understand and relate to that initial resistance. +But I also really like the idea that all of these changes and everything going into the codebase is managed by a team. So we really want there to be a level of comfort from the team that this is what's going in. And as the author of the changes, I am far more comfortable with everything that's about to get merged in because I've spent so much time with it. So for me, whenever I do feel that initial resistance, I have to ask myself, well, what's the value? Will this make it easier for folks to review? Maybe it will show some areas that I didn't add test coverage because it felt like it was already getting so large. And so I started to negotiate with myself as to like, well, maybe I don't need to test that because this is already getting so big. And I don't want to add more to it. +So I really think through what's the value of if I break it up? And will it make the team more confident in this change? And ultimately if it does, then to me, that's always a resounding yes. So it's just going through what's the value versus what's my initial oh, this is a waste of my time to oh no, this is a good use of my time because it really benefits everyone else. +Circling back to something else that was said in the question was the message that we're just so drained from the whole thing. And I really don't want to take that for granted because that's really important. And it sounds like someone has taken their own time and hopefully company time to work on this. But it's not a team initiative. So this does feel like one of those areas where it feels like the team needs to prioritize whether this gets worked on or not. And it's okay if the team says, "Yes, this is important, but six months from now because we need a break from it." But as long as it's something that the team worked on together to say this is important, or it's not, I feel like that's an important part. And also to recognize that we don't have to fix all of this right now. That's really important for the company to buy into it. +I have two small things that I want to add, sort of the what not to do because we've been talking about some things that we would do. And so one thing that I definitely wouldn't do is avoid having one person going off and trying to fix this part of the codebase. Don't have one person, either a designer, developer, just a single soul who's like, I can fix this, and tackle it, and define all the things, and improve it. That's going to go poorly. Don't do that. +And then also, I would avoid refactoring just to refactor, which I think goes a little bit against Therapeutic Refactoring, which is a talk that I absolutely love. But if we're really invested in proving this part of the codebase, then I think it is very helpful and important to have a fixed user deliverable goal driving your refactor because that's also going to help shape and influence your PRs and encourage the team to take the time to review those PRs and get them merged. +So there's a nice coupling there where you want something driving that goal. Granted, it could be different for different teams. Therapeutic Refactoring may work wonderfully. But I've just seen so many people sink a lot of time into something, get very frustrated, then nothing gets shipped. So I would favor leaning more until we have this very focused thing that we're going to deliver, whether it's adding a test or two tests. Have a goal in mind when you start that refactor. +CHRIS: Again, I find myself nodding aggressively with everything that you're saying. And in addition, I really like the subtlety that you're bringing to one of my favorite talks. I've mentioned many times that this is one of my favorite talks. But I think you've added a really interesting like, yeah, but also, in the way that everything depends, it also depends. And I think you framed that really well that refactoring for refactoring sake can be fun and therapeutic, and cathartic for an individual. But we have to make sure it's part of the overall work that we're doing. +And you've now, I think, really well captured the human side of this work that is captured in what is such a complicated, nuanced question that I think also does such a good job of just highlighting the work. This is what it looks like. This is a particular almost perfect storm of the work, but that happens. But each little piece of this that we've talked about is this is the day-to-day of software development interestingly. I always thought it was just going to be writing for loops. I haven't written a for loop in years. I don't even know how to write a for loop. But this stuff is what I do every day. [laughter] +STEPH: The most challenging part for me in software I realized is when a problem has escalated to the point where it's like, I can't just write code to fix this. I need to go to the team. I need to get buy-in. And that's where I start to realize this is where software to me really gets hard because then I need other people to contribute and to get their opinions. And it turns out way better for it. But yes, that is definitely the intersection for me where I can write code up to a certain point to then I really need people to help make really great software and fix some of the underlying issues that we're facing. +On that note, Michael and Ben, thank you so much for writing this in to us. I'm very interested to hear how this turns out for your team. And thank you so much. I wish you the best of luck. On that note, Shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris finally got his new computer! 🎉 🎉 🎉 He gives his initial review. He's also super excited that GitHub announced a beta for pull requests merge queue, and even more excited that multiple people who listen to this show very kindly pointed that out to him on Twitter!

+ +

Steph discovered something that is quite niche, but she's excited to tinker with it more, called CookLang. It's a markup language that's designed for cooking and recipe management so you can store recipes and text files and there's no database required; making it easy to have control over recipes versus storing them in a separate application.

+ +

Then they answer a listener question about refactoring murky legacy code.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Well, we've talked about it before, but it has finally happened. I finally got a new computer.

+ +

STEPH: Yay, yay.

+ +

CHRIS: Five years in the making. I held out, I waited. The new computer is fantastic. I'm in that transition phase of trying to set everything up and get it all...the particular thing holding me back is actually this recording and some dongles. I need to live that USB-C life now. Everything needs new connections and whatnot, particularly my external monitor.

+ +

STEPH: I'm now realizing how old your current laptop is.

+ +

CHRIS: [laughs] Did I just date myself? Yes.

+ +

STEPH: You did. You just dated it with a USB-C. I thought you were still on the USB-C life.

+ +

CHRIS: I'm pretty sure it's a 2016. I'm currently recording on a 2016 MacBook Pro. But yeah, I'm very excited with the new one. The shape of them is weird. I did not expect this because I've seen the 13-inch MacBook Pros that have the touch bar and other things that I didn't really want. But the shape of that laptop was more familiar to me. And this one, I don't know, it's weirder and rounder and bulkier in ways that I didn't expect. And it's heavier than I expected. I got the 14-inch, as an aside. I went with a slightly smaller version assuming that my 16-inch with a giant bezel, because it's from the past, would have a similar amount of screen real estate to a 14-inch with no bezels or with the screen going almost out to the edges.

+ +

As an aside, the notch in the top of the computer screen is ridiculous. I've dealt with it on the phone for a while now. I accepted that I live in the land of notches. But somehow, it's way, way worse on the computer like when I take my terminal full screen most of the time, and so stuff just gets lost. I don’t know, I got to deal with this or not, maybe I can just not care. But it is covering things that I want to read. And I'm like, well, this is annoying.

+ +

But yeah, beyond the notch, everything else is great. It's a nice form factor. It seems to have great battery life. It's very fast. It goes very fast. It also has...there's more RAM in it. There's more hard drive space and whatnot, so a bunch of the things that I use. Often as we start this recording I'm like, oh no, I wonder if I have enough hard drive space for the recording we're about to do, which I should probably be past that at this point in my life. Well, now I think I am, except I haven't yet ported my recording setup.

+ +

Nonetheless, I'm very excited. And particularly, a lot of the development workflow tasks like starting up the dev server of the project that I'm on just moves a lot more quickly. It's a lot snappier, and everything is just speedier. The fans don't really turn on. It doesn't get too hot even when I'm doing challenging things, downloading everything from the internet and compiling from source code. It's like, yeah, cool; I can do that. That seems like a thing that's well within my wheelhouse. And I'm like, cool, computer, good job. Glad to have you on the team.

+ +

STEPH: So I learned something about you recently because hey, we were hanging out in person recently since I was in Boston for a week. That was amazing. And I learned that we have a similar thing where we both like to start our machines from scratch, and slowly (or at least correct me as I'm going through this), we bring things over. But it's not an immediate just port everything from my current laptop over to my new laptop. And I'm fascinated because I thought I was the only one with this sickness. But it turns out that you, my friend, also have this in your life.

+ +

CHRIS: Well, yes, you are correct. That is the thing that is true. And also, to reiterate, it was really lovely seeing you in the human world as opposed to just in a Skype window as we so often do. But yes, I start fresh every time. But to be clear, it's been more than five years since the last time I did this. So I feel like I can make a bit of an event of it each time I do it. So I'm fine with that. But I do like starting from fresh reinstalling everything rather than trying to copy over an image of the system.

+ +

I felt a little bit shamed by the operating system because there's the like, welcome to your new Mac. What's your language? What's your WiFi? What do you want to migrate over? And I'm like, nothing. But there wasn't a button for no, thank you. [chuckles] There were buttons that were like...there were two different options, but neither of them were no. And I'm just staring at it, and I'm like, but I would like to not though. I would like to just start fresh.

+ +

STEPH: [laughs]

+ +

CHRIS: And I got it from here. I appreciate the effort. Turns out they were hiding it in the bottom left corner, but it wasn't a button. It was like link text, but it was barely emphasized. And on the right were where all the action buttons for every previous step and subsequent step were. So this was like no one would ever want to do this. So we're just going to hide the option over in the corner.

+ +

Yes, I very much like starting fresh. I like to get the chance to shed some of the mistakes of the past and only bring forward the things that are bringing me joy in the modern-day, so here we are. A lot of stuff doesn't work, by the way. [laughter] I brought over my dotfiles, and things did not work super great. Or I opened an application, and it's like, oh, that hasn't worked for years, and I'm like, I was living in the past. All right, this is fine. I'll update my workflow. It'll be okay.

+ +

STEPH: I like how you said make an event of it because I haven't really found the right words for it, but that's perfect. I have a fresh laptop, and it's an event, and I want to spend that time setting it up and shutting the mistakes of the past. [laughs] That too, that also resonates.

+ +

CHRIS: Yep. It's really about the mistakes of the past. I don't want to live there anymore. I want to move on from them. But overall, yeah, it's going well. I think I'll be able to work with it. I'm actually unfortunately limited in that I can't connect it to my monitor right now or to the keyboard that I have and whatnot. So I can't quite integrate it into my home office setup. I can use the laptop itself, and it's working fine. I've got my current project running on it.

+ +

So I was able to install Ruby and figure out how do I trick it into using the Homebrew things versus the M1 things versus which architecture and yadda yadda yadda? That actually went better than I expected. I thought it was going to have more issues there, but stuff just kind of worked. And I had to find one weird Stack Overflow and copied and pasted as one does when you're setting up new computers or all the time as a programmer. And then yeah, we're off to the races. But yeah, unfortunately, right now, the limitation is a physical cable. I need a couple of new cables. So I'm excited to get those in the near term.

+ +

STEPH: Yeah, that'll be nice to have it set up and feel like you can fully transition to the new setup.

+ +

CHRIS: But in slightly other news, so computer is great, very happy about that. Perhaps I’m even more excited that GitHub has announced a beta for pull requests merge queue, and even more so excited that multiple people who listen to this show very kindly pointed that out to me on Twitter. And I was like, this is the dream. I just rant about stuff on a podcast, and then people tell me when the world has solved the problem that I complained about. This is so great.

+ +

But it's a public beta, but you go on an invite list and whatnot. So I'm on that list right now. And I'm trying to just mention it as much as possible, especially near any friends I know that happen to work at GitHub; just be like, "Hey, if you happen to know how to find that list...and I will give wonderful feedback. I will be an active member of this beta." But I would really love to get to try out that feature. So I'm excited.

+ +

We'll include show note links to the blog post announcing this new feature. So I'm really excited that it is built into the platform and will sort of be there. And I'm hopeful that GitHub has done a great job. This is actually a really interesting feature in my mind. It's one of those things like, oh, it's pretty straightforward. You just make a queue, and then you merge things. It's like, oh yeah, but what about all the ways it can go wrong? It's a great I think iceberg feature where the simple, happy path is wonderful.

+ +

And then there are so many different failure modes like, oh, what do you do when the PR fails to rebase? Or should you proactively rebuild the sequence of them? Do you stack them up and start preemptively rebuilding the other PRs that are next in line in the queue after that? But what if then it fails? And et cetera, et cetera. There's lots of fun stuff that can go wrong. So I trust that GitHub will do a wonderful implementation. I would love to get to try that, but currently, I've yet to get in.

+ +

STEPH: Have they shared how to get access to the limited beta? Is it just random selection, or can you specifically request? It sounds like you can't, based on what you're saying, but I'm curious.

+ +

CHRIS: There is a waitlist. Particularly, they had me put the repo that I was interested in, so like, I would like to be in the beta. And this repo, in particular, is the one that I would like to put into the beta. So I've submitted that, but now I'm just in a list. I don't know where in the list I am. I have no visibility into that. So again, I'm just saying things out into the void and seeing if the universe then reflects anything back at me, and by that, I mean people that work at GitHub. Hi, friends.

+ +

STEPH: I totally believe that if you speak things into the universe, the universe will give that back to you, or that's probably not true. So here's hoping that you get into the beta list.

+ +

CHRIS: Here's hoping. One other tiny thing I have been using Afterparty a bunch lately, which is a gem that you have recommended to me, I believe, in a previous episode not that long ago. But we started doing feature flags. Feature flags are great. We're using Flipper. It's wonderful. But Flipper stores...the way we've configured it, we're storing them in the database. And so, when we get to the point where we want to fully release a feature, we dial-up so that everyone has access to it. So at this point, the feature flag system is still running, but everyone is getting access to that feature. And so then there's a code change that removes any references to the feature flag, any checks for it.

+ +

And subsequently, we want to then clean up after ourselves. Afterparty has been fantastic. I'm really happy with the way that that works and that we can just include the Afterparty data migration associated with that, delete the record from the database, and then everything consistently works together. This does poke at the edge, though, of how Heroku does deployments and the fact that there is that latency where it will basically restart with the new code, needs to run all migration steps, et cetera, et cetera. And then it's running on the new code, which is great. That's what I want in this case. But it does have a cost, and I would love to figure out true blue-green deployments sometime in my usage of Heroku such that we can have zero downtime deployments is actually the way to phrase it.

+ +

Using Afterparty for this, I think, is leveraging the idea that it's not a big deal. It'll be fine. Because if we had zero downtime deployments, I think temporarily, we would be in a space where feature flag has been deleted; therefore, no one is in the feature. Therefore, no one would see it for that weird second. I'm safe from that. But it's this weird trade-off that I have in my mind of I want blue-green deployments, but I'm appreciating that I don't have them right now and that there is a consistent...and I think that's the reason that Heroku makes the choice that they do. But, man, everything's complicated. Why can't stuff just be simple?

+ +

STEPH: Everything is complicated. So I'm thinking back through to now my previous client's setup since I'm about to transition to a new project. And we have AWS. We have rolling deploys, so we don't have that specific downtime. We are using Afterparty. So I think based on everything that you're saying that yes, there's a slight period of where we are rolling out a feature flag or potentially dropping it, and that could put some users into a weird state if they're active and then the code suddenly changes. I'm thinking through out loud and singing it because apparently, that is what I do. We haven't run into any issues with that. But I am now trying to think through of when someone might end up in a weird state because of that.

+ +

CHRIS: You almost certainly won't run into any issues because we're talking about a matter of seconds where the code is in an inconsistent state. But the same thing applies to migrations like database migrations where if you're doing rolling deployments and the database migration hasn't happened yet, but there's new code that's running that expects that database state, then you're in this subtly inconsistent mode.

+ +

And I think if you really want to adopt this idea of rolling deployments or zero downtime deployments, you have to separate data changes from the code that uses that data change such that both versions of the code when the migration goes out are fine. And then later, you deploy the code that uses the migration, but then that's like a whole bunch of more steps. And you got to think about it, and you have to probably put in some pull request review step to check on it. And so again, it's just complicated.

+ +

STEPH: So that's one of the reasons we did change our feature flag implementation was because we realized it was a pain. Because anytime that we wanted to drop feature flags, we first issued a PR that removed any references in the code to that feature flag, let that deploy. And then we'd issue a separate pull request that went out in a different deploy that went and dropped that column. So that way, we didn't have any situations where maybe ActiveRecord has cached to that column, and then there's code that's looking for it, but then it's not actually there. And then you run into that funkiness and complicated behavior.

+ +

So we were at a point where removing a feature flag required two PRs and two deploys, and that was awful. So we switched up how we were handling feature flags specifically so we could avoid that and started storing them in JSON files because we took the more bespoke approach to feature flags versus using Flipper.

+ +

CHRIS: Bespoke artisanal feature flags.

+ +

STEPH: I don't know that I'd recommend it. It's working. It's been a journey, and there are things working well about it. But it's definitely still in that space where it's like, I'm a little uncomfortable of like, how far should we go in this bespoke world and at what point we should reconsider and use something like Flipper. I would say stay tuned, but I'm not on that project anymore. So I'll just never know. [laughs] Sounds like a devious laugh. I will know probably from some friends that are on the project, but I won't be there for it. [laughs]

+ +

CHRIS: Cool. Well, yeah, I think that sums up things in my world. What's new in your world?

+ +

STEPH: I have discovered something that's quite niche, but I'm excited to tinker with it more. It's called CookLang. And it's a markup language that's designed for cooking and recipe management. So you can store recipes and text files, and there's no database that's required. So it's easy to have control over your recipes versus storing them in a separate application, which is currently how I store my recipes. Which for the record, I'm happy to pay for software. I am very appreciative of when people make my life easier. And so I very much enjoy that. But I also still love the it's mine, and I can just have it stored somewhere in the cloud, and I'll never lose it. And I don't have to worry about renewing memberships to keep access to something. So there's a part of me that is very drawn to the idea that I can just have everything in the text file. I can store it anywhere that I want.

+ +

And then, for this particular CookLang markup language, it lets you define certain qualities of your recipe. So you can define the ingredients, the quantity, cookware, timers. It'll help you create shopping lists, and you can set metadata. So maybe you want to include the total prep time or the type of meal, or the number of people that the recipe serves. And they also have an iOS app that is in beta. So speaking of beta, this one is closed at the moment because they've had a pretty overwhelming positive response or interest. So they have shut it down for now in terms of accepting new people to the beta; at least, that's my current understanding.

+ +

But the iOS app does look like it'll be really nice. It's going to read from your files; I think stored in iTunes. But I'm just excited for all of this. It looks very interesting. And it looks like something that's just fun to play with. So I haven't moved anything over to start really investing and creating these .cook files that you use for the cook language. But it all seems very cute, very niche, and something I'm totally into.

+ +

CHRIS: I have not seen this, but it looks absolutely fantastic. I'm just reading the brief syntax snippet that they have at the top and the way that they're inferring semantic meaning from plain text recipes. And then you can generate a shopping list, super cool. You can just be like; I’m going to cook these things from my recipes. And then they'll tell you the shopping list, and it's grouped.

+ +

And this feels like what software should be in my mind. This doesn't feel like we're going too far with it, which is very easy to do. But it's like, no, no, we've annotated just a little bit of semantic meaning on top of something. And then with that, we can do wonderful things. Look at all the good stuff that falls out of it. We can have an iOS app. We can generate shopping lists. It's great. But it's also minimal and contained, and not locked in a proprietary format. And this is fantastic.

+ +

STEPH: There's also the nice part where they've already started highlighting that people can just store their recipes on GitHub. And then you can just fork recipes, or you can import everybody else's recipes. And I love that. I want more open-source recipes, although frankly, there are tons of just free amount of work and recipes that people have on the internet. But I love this because then I could skip all the ads that go with it. And I can just grab the stuff that I care about.

+ +

CHRIS: You mean you don't want to hear the person's life story before every single recipe. You don't want to hear about the walk that they took along the river when they were thinking about seasonal gourds, and then they decided to make a particular -- [laughs]

+ +

STEPH: [chuckles] I would normally...previous Stephanie would have been snarky about that in regards to all of that backstory that's given for a recipe. But then I saw somewhere maybe a friend was telling me about someone who had asked, "Why do y'all do this? Why are you putting so much information? Why can't I just have the recipe?" And they're like, "Well, frankly, Google's going to rank us a lot higher if we give you this whole backstory and if we look like there's more content to this page than just a recipe." And I'm like, dang. Okay, so it's Google that I have to be snarky about because they're doing their best in terms of trying to get you the recipe that you care about and make it very searchable.

+ +

CHRIS: Oh, yes. Absolutely. It's both a self-imposed problem. But also, I don't think Google's doing anything wrong here either. Google's part of their algorithm is they penalize duplicate content. And so there's what they view as the canonical source, the thing that's telling the truth. And then recipes look very much the same because they are kind of the same most of the time. This is how you make bread. This is also how you make bread. Two people now have almost identically the same content on the internet. And Google will penalize one that it determines to be copying essentially, which I think is a good thing broadly.

+ +

I've seen so many Stack Overflow...I want to say clones, but they're not even that. They're just literally taking the content and then republishing it entirely new. And that is a very bad thing that happens constantly and takes away from creators and whatnot. And so, in a way, Google's trying to do the right thing here, I think. But it leads to really just so much summary about recipes. It's one of those weird...is this a tragedy of the commons? I don't know. I've never quite understood that one. But I think it might be.

+ +

STEPH: Yeah, I don't know. That's my off-mic answer. [laughs]

+ +

CHRIS: That's fine. Someone on the internet will tell me whether or not this is a tragedy of the commons. But either way, I do not blame the recipe authors. I do not blame Google? You'll note the question in my voice. But I think I stand by that. I'm not sure who to blame. Maybe it's us. But here we are. [laughs]

+ +

STEPH: Yes, I like that final takeaway of let's not blame the people that are trying to give us wonderful, helpful content. Circling back a bit to some of the code that is powering CookLang or some of the interesting bits about CookLang, for anyone that's interested, you can also visit the GitHub repos they have. I believe everything is open source. There's a particular repo called spec. And you can view the issues, and you can see all the conversations around how should we annotate an ingredient? Or should we have comments in the language? And how should we handle this type of metadata?

+ +

And I find that interesting because I haven't really participated in any of the language crafting forums for Ruby or some of the other languages that I use. So it's neat to watch how some of this is being done in public to say, hey, we're just making this new markup language, and we're not really sure how we want to annotate everything. So what do people think? What's working for you? What's not? And I'm enjoying that conversation and reading along.

+ +

CHRIS: It really is such an interesting microcosm of an example of a language, an ecosystem, a community, a specification, and all of the stuff that is true of all of the other languages that we use more generally. But I'm looking down here, and there's the parser implementation. There's a Swift canonical parser. But then Rust, somebody is rewriting this in Rust because, of course, they are. But you know what? It's going to parse your recipe so fast, and it's going to be great. [laughter] But it does have the shape of everything that I've seen from other programming language conversations. And how do we evolve the language, and what syntax do we accept versus what do we not? And this is so interesting.

+ +

STEPH: Yeah, it's really neat. I'm really into it, and I'm really enjoying it thus far.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So, changing gears just a bit, we have a listener question that frankly is a doozy of a listener question. It's a bit long, but I feel like all of the content in here is important. And I feel like most people are going to be able to relate to this scenario that the question is describing. So this question comes from Michael Kopinsky and Ben Rosenbach from Philadelphia. And they write in, "There's one area of our codebase which has a lot of skeletons." I'm already empathizing. "The UI is error-prone jQuery soup, and the UX doesn't entirely make sense. Test coverage is close to non-existent. And the expected behavior isn't clear and has lots of edge cases.

+ +

We've thought over the years of how we can redo it, but it's never a priority. Redoing it would be a huge lift, and...it works usually. We get bug reports occasionally, which inevitably get closed as won't fix workaround provided. But a few months ago, we received a bug report, and I decided to start cleaning things up. I opened a merge request with a set of factors extracting some behavior into a service object, making explicit some things that were implicit and adding test." Side note, that's some hero work. I appreciate that right there. "It's gone through a few cycles of code review and pairing each time suggesting additional cleanups to do, requesting additional test coverage and that sort of thing. But the more we do, the more we discover that needs to be done.

+ +

So at this point, the merge request has been open for about eight weeks. I've paired with two other developers for probably 12 hours. The user is impatient, and we're tired of this darn thing and want it to go away. But it feels so bad. It really is severely lacking in test coverage. And the expected behaviors still aren't clearly defined. And it just doesn't meet the normal quality standards that we try to hold ourselves to. We could sit for another 8 to 40 hours and write more tests or documentation, but we're so drained from this whole thing.

+ +

So overall, we're really struggling to balance two things. We want to get things out the door, have short-lived PRs, and focus on incremental improvement. However, we still don't have defined requirements of how the feature is supposed to work across all permutations. And we can't write proper tests until expected behavior is defined more clearly. It feels like that's a baseline requirement before being able to merge or refactor. We'd love to hear any thoughts. Sincerely, Michael and Ben." Ooh, friend, there is so much we can dive into here. Would you like me to get started, or would you like to start?

+ +

CHRIS: Yeah, I've got a handful of thoughts because, as you highlighted, this is all of the stuff. This is the murky pile of complexity that writing code and delivering value in an organization is made up of. I'm going to start at a random place and then just start saying things because I think there is not a singular answer to this is an important starting line. We're not going to say, oh, if you just did X, then it would be fine. Obviously, this is a number of different complexities and situations, both person or both interpersonal human, and then code, and et cetera, et cetera.

+ +

So one of the things that actually came in the latter part of what you were reading there is we do not have defined requirements as to how this feature is supposed to work across all permutations of how it can be used. And that one is really interesting to me because right now, I wonder if there's something that can be done there. So often, you have code that does some stuff but also could do other stuff. And it's not clear if it's actually intended to do that other stuff or if that's just something that falls out of overly permissive like, we'll take any data you throw at us, and then we'll do some stuff. Typically, we don't actually want that. We want a more constrained system that's doing something. So that particular part was really interesting. Some of the conversations about testing were really interesting.

+ +

I think one of the things I would do is I would really ask, is this worth the effort? This code is kind of doing its thing. It's been around for a while. It's business-critical, but nobody really understands. It's like, is there a version of just leaving it at rest? Probably not. I typically would not do that. But it is a question that I think is worth asking because it can be really hard to make these changes on an under-defined system written in legacy technologies and whatnot, especially ones that we don't necessarily have as much...like, I haven't worked in jQuery for a while. So I wouldn't be quite as good at that. I wouldn't be able to understand that code as intuitively. That might be similar for this team.

+ +

So is there a version of just letting it lie? That is the first question I would ask. Presuming that's not the case, then I think I start to look at what is the attack that I would take to approach this. And I would definitely start with, hopefully, some small but meaningful introductions of test coverage but as a standalone thing. It's not part of the big change of a pull request. It's merely trying to lock in the code as it exists.

+ +

Again, I think I've referenced this talk perhaps more than any other, but Katrina Owens'Therapeutic refactoring is a really wonderful story and talk and really talks through this idea in a great way, but also it's just fun watch. But in it, Katrina talks about her approach to a similar thing where she was like, there's some code, and nobody really knows what it does. So I'm going to try and lock it down. And the first thing that she does is wraps test coverage around this code. So at least whatever it's doing now, we've constrained it a little bit. And actually, via the testing that she does, she ends up using that as a mechanism to sort of what does this system do? And finds a way to exercise the system and determine what its behavior actually is because nobody really knows that at this point.

+ +

So I would start with the testing. And then I would ask the question of we don't really know what it does across all permutations. Is there a way to actually constrain that? And say, let's actually lock some stuff down. Let's add a tiny bit of code that looks at the inputs being requested or coming into this code path or whatever it is but actually explicitly delineates what we think is the expected inputs and rejects or at least logs things that are surprising and that are like, we don't think it should do any of this. And then suddenly, if you see that showing up in the logs, you're like, I guess it does need to do that. Now we have a better idea of what is the actual target that we're trying to hit.

+ +

But really, both of those in my mind are ways to try and constrain the problem to try and add a little bit of support before tackling the hard work of the refactor because, just to be clear, you're probably going to break it in the refactor. I've broken every single system like this that I've tried to refactor without question. And there's a certain amount of organizational trust that you need to have. And it just gets to be a very complex time. And so anything that I can do to provide some guide rails, some support, something to help me in that time is something that I'm going to start with before I even go near the refactor itself. So those are some thoughts scattered around throughout the question. What do you think, Steph? What comes top of mind for you as you hear this question?

+ +

STEPH: I think those are great thoughts. And to expand on what you're talking about determining the expected behavior, that's also one of the bits that jumped out to me. And I love that you asked the question, can we leave it at rest? It sounds like yes, but there are some user concerns that come through or some bug reports. And then the team has to collectively say, "Yes, we are going to put someone through a difficult time to either do maybe a gross fix or implementation." And then we're making this area of the codebase feel worse and more accepting of different flows and adding to the number of flows that we have. Or we document it as won't fix and then provide a workaround.

+ +

So I really like that you said, "Can we leave it at rest?" Because I think that helps a team make a decision together as to like, what is the understanding of this part of the codebase functionality? How important is it to the business? If we decide that it's not that important to the business, then it's frankly not worth anybody's time working on it even if it feels really bad and you know there's this gross code over here, and you really want to go work on it. But if it's not important to the business, then it just shouldn't be done. And it needs to be left alone until the business decides this is important to our functionality. We do want to prioritize this work, and we're going to work on it together. And I still think there are a couple of nuanced strategies even from there.

+ +

So if you're looking for the more incremental improvements of we can't totally let this lie...we do have to improve it. But we're also not willing to invest in an overhaul situation. So some of the incremental improvements would be, as you'd mentioned, adding some test coverage to it to at least start to lock in the behavior that's already there and establish a baseline of understanding and then document that behavior. I've also found that really helps for context switching. So if you go in and you just document one part of that system as something that it does, then it frees you up. You can add something. You can issue a smaller merge request. You can get that merged because you're just adding test coverage. So it's not going to break anything. You're not making code changes. But then you can nearly let that go. And you can jump to something else that the team or the business has decided that's more important.

+ +

Some other areas that I've used in the past for working in these types of legacy or just bug-prone areas is to look for flows that are no longer in use. So if there's something that stands out to me as like, I'm pretty sure users aren't using this, or this code just looks unused. Maybe it's running a tool like Unused, which we can link to in the show notes, and see if there's truly something that's unused that you can just immediately remove. Or maybe it's logging a message to Rollbar or something similar. So that way, you know this is actually being used, but you can have it log whenever that's being run. Let that live for a month and then go back and check to see if that flow is ever executed.

+ +

As for the larger overhaul approach, that really has to be a team effort. So this has to be one of those moments of like the company decides this is important. And there may be smaller wins you can look for, but I do think it's going to require at least a developer or the product manager to be invested and ideally a designer as well. And then some small steps there may be looking for reducing responsibility of that feature. So maybe it's this really verbose long form that's complicated. And maybe you can collect some of that information somewhere else in the app. So you can start to chip away at some of the responsibilities in that portion of the application.

+ +

Or maybe you have a mini design sprint. You may realize this is a very important part of your application. We should really have this be a better experience for users. And let's really take a hard look at what this does and start to document. And that's the bigger like we're going to rebuild this, or the whole team is going to focus on this and improve this portion of the application. So that was in response to some of the lovely things that you said that you made me think of.

+ +

The other thing that really jumped out to me is this merge request that's sitting because this person, Michael or Ben, they've already done some really hard work where they have decided to add test coverage. They've cleaned up some things. And I can certainly relate to you issue a pull request and someone...because you've started cleaning up a space, people are like, "Oh, what about that cobweb? And then you missed a spot. What about over here?" And so, how do you make progress when you're in that state? And I would say move the goal line and merge the pull request.

+ +

So your goal line sounds like right now is trying to address everything which doesn't feel humanly possible. So instead, move the goal line. Figure out okay, I just want to add these couple of tests, or I just want to add this refactor to a function or something that documents this part of the system. And if people are nervous about merging the current merge request because it has gotten so big and people have made so many small requests, is to then break it up into smaller, more focused PR. So then it makes it easier for people to say, "Yes, that does improve the state of this codebase. Please merge it."

+ +

And I will often prefix my PRs with that. I'll say, "Dear reviewer, this PR is intended to improve the state of the world. It does not improve everything because I can't, but this is the goal of this." So that way, people go in with the mindset of they'll realize they're still going to see some cruft. But this is still leading us towards a better place. And unless there are strong concerns about the changes made in that specific PR, any other requests need to be noted and then can be captured somewhere else, but we're not going to address it right now in this PR.

+ +

CHRIS: I agree so very much with all of the things you just said. For anyone at home who cannot see us on the Skype call that we're on, I was just aggressively nodding my head the entire time Steph was saying all of that. [chuckles] You touched on I think all of the additional points that I would want to make specific to this merge request is out there in the world and whatnot.

+ +

The one other tiny bit that I would add to it is I have definitely been the person, and then I've also been on the other side of it where people get attached to the code that they've written. "But I've already written the merge request." And you're like, "Yeah, but can you break it up?" And they're like, "Yeah, but it already is a thing. And I did a bunch of work. And now I'm emotionally invested in this pile of work getting across the finish line and breaking it apart..." We can get caught up in our code.

+ +

And this is a really great example of this thing just got away from you. This is too big of a refactor. It's too much of a risk. And so again, I have struggled with this personally where I'm like, I'm so proud of this pile of work that I just made. And people are like, "Yeah, but that's a big pile of work there." I'm like, "You're right. You're right. I should break this up. I will break this up." But I can feel that resistance in myself to doing that, what feels like extra work, what feels like almost undoing of work. It's like, "No, no, no. I think it's ready." I'll be like, "I don't know, I'm not convinced. Can we break it apart?" And that's almost always the right decision. But it can be painful.

+ +

And so, just knowing that and having that in the back of your head as a thing that my brain will tell me the opposite. My brain will be like, no, no, go with it. It's great. We're proud of this. But being open to the idea that breaking things up is good, smaller pieces are good, et cetera, et cetera, can be a useful psychological aspect of this conversation because,, of course, there's one more facet. There are so many facets to this question.

+ +

STEPH: I like that anecdote about that you haven't regretted breaking things up because I also relate to that where there's that initial like, I've already done this much work. And now you're asking me to do more work. And it's going to have the same outcome where it's still going to be the same code. It's still going to be the same set of changes, but you're asking me to break it up into smaller changes. And I just feel exhausted from this work already. And I don't want to have to break this up. So I understand and relate to that initial resistance.

+ +

But I also really like the idea that all of these changes and everything going into the codebase is managed by a team. So we really want there to be a level of comfort from the team that this is what's going in. And as the author of the changes, I am far more comfortable with everything that's about to get merged in because I've spent so much time with it. So for me, whenever I do feel that initial resistance, I have to ask myself, well, what's the value? Will this make it easier for folks to review? Maybe it will show some areas that I didn't add test coverage because it felt like it was already getting so large. And so I started to negotiate with myself as to like, well, maybe I don't need to test that because this is already getting so big. And I don't want to add more to it.

+ +

So I really think through what's the value of if I break it up? And will it make the team more confident in this change? And ultimately if it does, then to me, that's always a resounding yes. So it's just going through what's the value versus what's my initial oh, this is a waste of my time to oh no, this is a good use of my time because it really benefits everyone else.

+ +

Circling back to something else that was said in the question was the message that we're just so drained from the whole thing. And I really don't want to take that for granted because that's really important. And it sounds like someone has taken their own time and hopefully company time to work on this. But it's not a team initiative. So this does feel like one of those areas where it feels like the team needs to prioritize whether this gets worked on or not. And it's okay if the team says, "Yes, this is important, but six months from now because we need a break from it." But as long as it's something that the team worked on together to say this is important, or it's not, I feel like that's an important part. And also to recognize that we don't have to fix all of this right now. That's really important for the company to buy into it.

+ +

I have two small things that I want to add, sort of the what not to do because we've been talking about some things that we would do. And so one thing that I definitely wouldn't do is avoid having one person going off and trying to fix this part of the codebase. Don't have one person, either a designer, developer, just a single soul who's like, I can fix this, and tackle it, and define all the things, and improve it. That's going to go poorly. Don't do that.

+ +

And then also, I would avoid refactoring just to refactor, which I think goes a little bit against Therapeutic Refactoring, which is a talk that I absolutely love. But if we're really invested in proving this part of the codebase, then I think it is very helpful and important to have a fixed user deliverable goal driving your refactor because that's also going to help shape and influence your PRs and encourage the team to take the time to review those PRs and get them merged.

+ +

So there's a nice coupling there where you want something driving that goal. Granted, it could be different for different teams. Therapeutic Refactoring may work wonderfully. But I've just seen so many people sink a lot of time into something, get very frustrated, then nothing gets shipped. So I would favor leaning more until we have this very focused thing that we're going to deliver, whether it's adding a test or two tests. Have a goal in mind when you start that refactor.

+ +

CHRIS: Again, I find myself nodding aggressively with everything that you're saying. And in addition, I really like the subtlety that you're bringing to one of my favorite talks. I've mentioned many times that this is one of my favorite talks. But I think you've added a really interesting like, yeah, but also, in the way that everything depends, it also depends. And I think you framed that really well that refactoring for refactoring sake can be fun and therapeutic, and cathartic for an individual. But we have to make sure it's part of the overall work that we're doing.

+ +

And you've now, I think, really well captured the human side of this work that is captured in what is such a complicated, nuanced question that I think also does such a good job of just highlighting the work. This is what it looks like. This is a particular almost perfect storm of the work, but that happens. But each little piece of this that we've talked about is this is the day-to-day of software development interestingly. I always thought it was just going to be writing for loops. I haven't written a for loop in years. I don't even know how to write a for loop. But this stuff is what I do every day. [laughter]

+ +

STEPH: The most challenging part for me in software I realized is when a problem has escalated to the point where it's like, I can't just write code to fix this. I need to go to the team. I need to get buy-in. And that's where I start to realize this is where software to me really gets hard because then I need other people to contribute and to get their opinions. And it turns out way better for it. But yes, that is definitely the intersection for me where I can write code up to a certain point to then I really need people to help make really great software and fix some of the underlying issues that we're facing.

+ +

On that note, Michael and Ben, thank you so much for writing this in to us. I'm very interested to hear how this turns out for your team. And thank you so much. I wish you the best of luck. On that note, Shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris finally got his new computer! 🎉 🎉 🎉 He gives his initial review. He's also super excited that GitHub announced a beta for pull requests merge queue, and even more excited that multiple people who listen to this show very kindly pointed that out to him on Twitter!

+ +

Steph discovered something that is quite niche, but she's excited to tinker with it more, called CookLang. It's a markup language that's designed for cooking and recipe management so you can store recipes and text files and there's no database required; making it easy to have control over recipes versus storing them in a separate application.

+ +

Then they answer a listener question about refactoring murky legacy code.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: What's new in my world? Well, we've talked about it before, but it has finally happened. I finally got a new computer.

+ +

STEPH: Yay, yay.

+ +

CHRIS: Five years in the making. I held out, I waited. The new computer is fantastic. I'm in that transition phase of trying to set everything up and get it all...the particular thing holding me back is actually this recording and some dongles. I need to live that USB-C life now. Everything needs new connections and whatnot, particularly my external monitor.

+ +

STEPH: I'm now realizing how old your current laptop is.

+ +

CHRIS: [laughs] Did I just date myself? Yes.

+ +

STEPH: You did. You just dated it with a USB-C. I thought you were still on the USB-C life.

+ +

CHRIS: I'm pretty sure it's a 2016. I'm currently recording on a 2016 MacBook Pro. But yeah, I'm very excited with the new one. The shape of them is weird. I did not expect this because I've seen the 13-inch MacBook Pros that have the touch bar and other things that I didn't really want. But the shape of that laptop was more familiar to me. And this one, I don't know, it's weirder and rounder and bulkier in ways that I didn't expect. And it's heavier than I expected. I got the 14-inch, as an aside. I went with a slightly smaller version assuming that my 16-inch with a giant bezel, because it's from the past, would have a similar amount of screen real estate to a 14-inch with no bezels or with the screen going almost out to the edges.

+ +

As an aside, the notch in the top of the computer screen is ridiculous. I've dealt with it on the phone for a while now. I accepted that I live in the land of notches. But somehow, it's way, way worse on the computer like when I take my terminal full screen most of the time, and so stuff just gets lost. I don’t know, I got to deal with this or not, maybe I can just not care. But it is covering things that I want to read. And I'm like, well, this is annoying.

+ +

But yeah, beyond the notch, everything else is great. It's a nice form factor. It seems to have great battery life. It's very fast. It goes very fast. It also has...there's more RAM in it. There's more hard drive space and whatnot, so a bunch of the things that I use. Often as we start this recording I'm like, oh no, I wonder if I have enough hard drive space for the recording we're about to do, which I should probably be past that at this point in my life. Well, now I think I am, except I haven't yet ported my recording setup.

+ +

Nonetheless, I'm very excited. And particularly, a lot of the development workflow tasks like starting up the dev server of the project that I'm on just moves a lot more quickly. It's a lot snappier, and everything is just speedier. The fans don't really turn on. It doesn't get too hot even when I'm doing challenging things, downloading everything from the internet and compiling from source code. It's like, yeah, cool; I can do that. That seems like a thing that's well within my wheelhouse. And I'm like, cool, computer, good job. Glad to have you on the team.

+ +

STEPH: So I learned something about you recently because hey, we were hanging out in person recently since I was in Boston for a week. That was amazing. And I learned that we have a similar thing where we both like to start our machines from scratch, and slowly (or at least correct me as I'm going through this), we bring things over. But it's not an immediate just port everything from my current laptop over to my new laptop. And I'm fascinated because I thought I was the only one with this sickness. But it turns out that you, my friend, also have this in your life.

+ +

CHRIS: Well, yes, you are correct. That is the thing that is true. And also, to reiterate, it was really lovely seeing you in the human world as opposed to just in a Skype window as we so often do. But yes, I start fresh every time. But to be clear, it's been more than five years since the last time I did this. So I feel like I can make a bit of an event of it each time I do it. So I'm fine with that. But I do like starting from fresh reinstalling everything rather than trying to copy over an image of the system.

+ +

I felt a little bit shamed by the operating system because there's the like, welcome to your new Mac. What's your language? What's your WiFi? What do you want to migrate over? And I'm like, nothing. But there wasn't a button for no, thank you. [chuckles] There were buttons that were like...there were two different options, but neither of them were no. And I'm just staring at it, and I'm like, but I would like to not though. I would like to just start fresh.

+ +

STEPH: [laughs]

+ +

CHRIS: And I got it from here. I appreciate the effort. Turns out they were hiding it in the bottom left corner, but it wasn't a button. It was like link text, but it was barely emphasized. And on the right were where all the action buttons for every previous step and subsequent step were. So this was like no one would ever want to do this. So we're just going to hide the option over in the corner.

+ +

Yes, I very much like starting fresh. I like to get the chance to shed some of the mistakes of the past and only bring forward the things that are bringing me joy in the modern-day, so here we are. A lot of stuff doesn't work, by the way. [laughter] I brought over my dotfiles, and things did not work super great. Or I opened an application, and it's like, oh, that hasn't worked for years, and I'm like, I was living in the past. All right, this is fine. I'll update my workflow. It'll be okay.

+ +

STEPH: I like how you said make an event of it because I haven't really found the right words for it, but that's perfect. I have a fresh laptop, and it's an event, and I want to spend that time setting it up and shutting the mistakes of the past. [laughs] That too, that also resonates.

+ +

CHRIS: Yep. It's really about the mistakes of the past. I don't want to live there anymore. I want to move on from them. But overall, yeah, it's going well. I think I'll be able to work with it. I'm actually unfortunately limited in that I can't connect it to my monitor right now or to the keyboard that I have and whatnot. So I can't quite integrate it into my home office setup. I can use the laptop itself, and it's working fine. I've got my current project running on it.

+ +

So I was able to install Ruby and figure out how do I trick it into using the Homebrew things versus the M1 things versus which architecture and yadda yadda yadda? That actually went better than I expected. I thought it was going to have more issues there, but stuff just kind of worked. And I had to find one weird Stack Overflow and copied and pasted as one does when you're setting up new computers or all the time as a programmer. And then yeah, we're off to the races. But yeah, unfortunately, right now, the limitation is a physical cable. I need a couple of new cables. So I'm excited to get those in the near term.

+ +

STEPH: Yeah, that'll be nice to have it set up and feel like you can fully transition to the new setup.

+ +

CHRIS: But in slightly other news, so computer is great, very happy about that. Perhaps I’m even more excited that GitHub has announced a beta for pull requests merge queue, and even more so excited that multiple people who listen to this show very kindly pointed that out to me on Twitter. And I was like, this is the dream. I just rant about stuff on a podcast, and then people tell me when the world has solved the problem that I complained about. This is so great.

+ +

But it's a public beta, but you go on an invite list and whatnot. So I'm on that list right now. And I'm trying to just mention it as much as possible, especially near any friends I know that happen to work at GitHub; just be like, "Hey, if you happen to know how to find that list...and I will give wonderful feedback. I will be an active member of this beta." But I would really love to get to try out that feature. So I'm excited.

+ +

We'll include show note links to the blog post announcing this new feature. So I'm really excited that it is built into the platform and will sort of be there. And I'm hopeful that GitHub has done a great job. This is actually a really interesting feature in my mind. It's one of those things like, oh, it's pretty straightforward. You just make a queue, and then you merge things. It's like, oh yeah, but what about all the ways it can go wrong? It's a great I think iceberg feature where the simple, happy path is wonderful.

+ +

And then there are so many different failure modes like, oh, what do you do when the PR fails to rebase? Or should you proactively rebuild the sequence of them? Do you stack them up and start preemptively rebuilding the other PRs that are next in line in the queue after that? But what if then it fails? And et cetera, et cetera. There's lots of fun stuff that can go wrong. So I trust that GitHub will do a wonderful implementation. I would love to get to try that, but currently, I've yet to get in.

+ +

STEPH: Have they shared how to get access to the limited beta? Is it just random selection, or can you specifically request? It sounds like you can't, based on what you're saying, but I'm curious.

+ +

CHRIS: There is a waitlist. Particularly, they had me put the repo that I was interested in, so like, I would like to be in the beta. And this repo, in particular, is the one that I would like to put into the beta. So I've submitted that, but now I'm just in a list. I don't know where in the list I am. I have no visibility into that. So again, I'm just saying things out into the void and seeing if the universe then reflects anything back at me, and by that, I mean people that work at GitHub. Hi, friends.

+ +

STEPH: I totally believe that if you speak things into the universe, the universe will give that back to you, or that's probably not true. So here's hoping that you get into the beta list.

+ +

CHRIS: Here's hoping. One other tiny thing I have been using Afterparty a bunch lately, which is a gem that you have recommended to me, I believe, in a previous episode not that long ago. But we started doing feature flags. Feature flags are great. We're using Flipper. It's wonderful. But Flipper stores...the way we've configured it, we're storing them in the database. And so, when we get to the point where we want to fully release a feature, we dial-up so that everyone has access to it. So at this point, the feature flag system is still running, but everyone is getting access to that feature. And so then there's a code change that removes any references to the feature flag, any checks for it.

+ +

And subsequently, we want to then clean up after ourselves. Afterparty has been fantastic. I'm really happy with the way that that works and that we can just include the Afterparty data migration associated with that, delete the record from the database, and then everything consistently works together. This does poke at the edge, though, of how Heroku does deployments and the fact that there is that latency where it will basically restart with the new code, needs to run all migration steps, et cetera, et cetera. And then it's running on the new code, which is great. That's what I want in this case. But it does have a cost, and I would love to figure out true blue-green deployments sometime in my usage of Heroku such that we can have zero downtime deployments is actually the way to phrase it.

+ +

Using Afterparty for this, I think, is leveraging the idea that it's not a big deal. It'll be fine. Because if we had zero downtime deployments, I think temporarily, we would be in a space where feature flag has been deleted; therefore, no one is in the feature. Therefore, no one would see it for that weird second. I'm safe from that. But it's this weird trade-off that I have in my mind of I want blue-green deployments, but I'm appreciating that I don't have them right now and that there is a consistent...and I think that's the reason that Heroku makes the choice that they do. But, man, everything's complicated. Why can't stuff just be simple?

+ +

STEPH: Everything is complicated. So I'm thinking back through to now my previous client's setup since I'm about to transition to a new project. And we have AWS. We have rolling deploys, so we don't have that specific downtime. We are using Afterparty. So I think based on everything that you're saying that yes, there's a slight period of where we are rolling out a feature flag or potentially dropping it, and that could put some users into a weird state if they're active and then the code suddenly changes. I'm thinking through out loud and singing it because apparently, that is what I do. We haven't run into any issues with that. But I am now trying to think through of when someone might end up in a weird state because of that.

+ +

CHRIS: You almost certainly won't run into any issues because we're talking about a matter of seconds where the code is in an inconsistent state. But the same thing applies to migrations like database migrations where if you're doing rolling deployments and the database migration hasn't happened yet, but there's new code that's running that expects that database state, then you're in this subtly inconsistent mode.

+ +

And I think if you really want to adopt this idea of rolling deployments or zero downtime deployments, you have to separate data changes from the code that uses that data change such that both versions of the code when the migration goes out are fine. And then later, you deploy the code that uses the migration, but then that's like a whole bunch of more steps. And you got to think about it, and you have to probably put in some pull request review step to check on it. And so again, it's just complicated.

+ +

STEPH: So that's one of the reasons we did change our feature flag implementation was because we realized it was a pain. Because anytime that we wanted to drop feature flags, we first issued a PR that removed any references in the code to that feature flag, let that deploy. And then we'd issue a separate pull request that went out in a different deploy that went and dropped that column. So that way, we didn't have any situations where maybe ActiveRecord has cached to that column, and then there's code that's looking for it, but then it's not actually there. And then you run into that funkiness and complicated behavior.

+ +

So we were at a point where removing a feature flag required two PRs and two deploys, and that was awful. So we switched up how we were handling feature flags specifically so we could avoid that and started storing them in JSON files because we took the more bespoke approach to feature flags versus using Flipper.

+ +

CHRIS: Bespoke artisanal feature flags.

+ +

STEPH: I don't know that I'd recommend it. It's working. It's been a journey, and there are things working well about it. But it's definitely still in that space where it's like, I'm a little uncomfortable of like, how far should we go in this bespoke world and at what point we should reconsider and use something like Flipper. I would say stay tuned, but I'm not on that project anymore. So I'll just never know. [laughs] Sounds like a devious laugh. I will know probably from some friends that are on the project, but I won't be there for it. [laughs]

+ +

CHRIS: Cool. Well, yeah, I think that sums up things in my world. What's new in your world?

+ +

STEPH: I have discovered something that's quite niche, but I'm excited to tinker with it more. It's called CookLang. And it's a markup language that's designed for cooking and recipe management. So you can store recipes and text files, and there's no database that's required. So it's easy to have control over your recipes versus storing them in a separate application, which is currently how I store my recipes. Which for the record, I'm happy to pay for software. I am very appreciative of when people make my life easier. And so I very much enjoy that. But I also still love the it's mine, and I can just have it stored somewhere in the cloud, and I'll never lose it. And I don't have to worry about renewing memberships to keep access to something. So there's a part of me that is very drawn to the idea that I can just have everything in the text file. I can store it anywhere that I want.

+ +

And then, for this particular CookLang markup language, it lets you define certain qualities of your recipe. So you can define the ingredients, the quantity, cookware, timers. It'll help you create shopping lists, and you can set metadata. So maybe you want to include the total prep time or the type of meal, or the number of people that the recipe serves. And they also have an iOS app that is in beta. So speaking of beta, this one is closed at the moment because they've had a pretty overwhelming positive response or interest. So they have shut it down for now in terms of accepting new people to the beta; at least, that's my current understanding.

+ +

But the iOS app does look like it'll be really nice. It's going to read from your files; I think stored in iTunes. But I'm just excited for all of this. It looks very interesting. And it looks like something that's just fun to play with. So I haven't moved anything over to start really investing and creating these .cook files that you use for the cook language. But it all seems very cute, very niche, and something I'm totally into.

+ +

CHRIS: I have not seen this, but it looks absolutely fantastic. I'm just reading the brief syntax snippet that they have at the top and the way that they're inferring semantic meaning from plain text recipes. And then you can generate a shopping list, super cool. You can just be like; I’m going to cook these things from my recipes. And then they'll tell you the shopping list, and it's grouped.

+ +

And this feels like what software should be in my mind. This doesn't feel like we're going too far with it, which is very easy to do. But it's like, no, no, we've annotated just a little bit of semantic meaning on top of something. And then with that, we can do wonderful things. Look at all the good stuff that falls out of it. We can have an iOS app. We can generate shopping lists. It's great. But it's also minimal and contained, and not locked in a proprietary format. And this is fantastic.

+ +

STEPH: There's also the nice part where they've already started highlighting that people can just store their recipes on GitHub. And then you can just fork recipes, or you can import everybody else's recipes. And I love that. I want more open-source recipes, although frankly, there are tons of just free amount of work and recipes that people have on the internet. But I love this because then I could skip all the ads that go with it. And I can just grab the stuff that I care about.

+ +

CHRIS: You mean you don't want to hear the person's life story before every single recipe. You don't want to hear about the walk that they took along the river when they were thinking about seasonal gourds, and then they decided to make a particular -- [laughs]

+ +

STEPH: [chuckles] I would normally...previous Stephanie would have been snarky about that in regards to all of that backstory that's given for a recipe. But then I saw somewhere maybe a friend was telling me about someone who had asked, "Why do y'all do this? Why are you putting so much information? Why can't I just have the recipe?" And they're like, "Well, frankly, Google's going to rank us a lot higher if we give you this whole backstory and if we look like there's more content to this page than just a recipe." And I'm like, dang. Okay, so it's Google that I have to be snarky about because they're doing their best in terms of trying to get you the recipe that you care about and make it very searchable.

+ +

CHRIS: Oh, yes. Absolutely. It's both a self-imposed problem. But also, I don't think Google's doing anything wrong here either. Google's part of their algorithm is they penalize duplicate content. And so there's what they view as the canonical source, the thing that's telling the truth. And then recipes look very much the same because they are kind of the same most of the time. This is how you make bread. This is also how you make bread. Two people now have almost identically the same content on the internet. And Google will penalize one that it determines to be copying essentially, which I think is a good thing broadly.

+ +

I've seen so many Stack Overflow...I want to say clones, but they're not even that. They're just literally taking the content and then republishing it entirely new. And that is a very bad thing that happens constantly and takes away from creators and whatnot. And so, in a way, Google's trying to do the right thing here, I think. But it leads to really just so much summary about recipes. It's one of those weird...is this a tragedy of the commons? I don't know. I've never quite understood that one. But I think it might be.

+ +

STEPH: Yeah, I don't know. That's my off-mic answer. [laughs]

+ +

CHRIS: That's fine. Someone on the internet will tell me whether or not this is a tragedy of the commons. But either way, I do not blame the recipe authors. I do not blame Google? You'll note the question in my voice. But I think I stand by that. I'm not sure who to blame. Maybe it's us. But here we are. [laughs]

+ +

STEPH: Yes, I like that final takeaway of let's not blame the people that are trying to give us wonderful, helpful content. Circling back a bit to some of the code that is powering CookLang or some of the interesting bits about CookLang, for anyone that's interested, you can also visit the GitHub repos they have. I believe everything is open source. There's a particular repo called spec. And you can view the issues, and you can see all the conversations around how should we annotate an ingredient? Or should we have comments in the language? And how should we handle this type of metadata?

+ +

And I find that interesting because I haven't really participated in any of the language crafting forums for Ruby or some of the other languages that I use. So it's neat to watch how some of this is being done in public to say, hey, we're just making this new markup language, and we're not really sure how we want to annotate everything. So what do people think? What's working for you? What's not? And I'm enjoying that conversation and reading along.

+ +

CHRIS: It really is such an interesting microcosm of an example of a language, an ecosystem, a community, a specification, and all of the stuff that is true of all of the other languages that we use more generally. But I'm looking down here, and there's the parser implementation. There's a Swift canonical parser. But then Rust, somebody is rewriting this in Rust because, of course, they are. But you know what? It's going to parse your recipe so fast, and it's going to be great. [laughter] But it does have the shape of everything that I've seen from other programming language conversations. And how do we evolve the language, and what syntax do we accept versus what do we not? And this is so interesting.

+ +

STEPH: Yeah, it's really neat. I'm really into it, and I'm really enjoying it thus far.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So, changing gears just a bit, we have a listener question that frankly is a doozy of a listener question. It's a bit long, but I feel like all of the content in here is important. And I feel like most people are going to be able to relate to this scenario that the question is describing. So this question comes from Michael Kopinsky and Ben Rosenbach from Philadelphia. And they write in, "There's one area of our codebase which has a lot of skeletons." I'm already empathizing. "The UI is error-prone jQuery soup, and the UX doesn't entirely make sense. Test coverage is close to non-existent. And the expected behavior isn't clear and has lots of edge cases.

+ +

We've thought over the years of how we can redo it, but it's never a priority. Redoing it would be a huge lift, and...it works usually. We get bug reports occasionally, which inevitably get closed as won't fix workaround provided. But a few months ago, we received a bug report, and I decided to start cleaning things up. I opened a merge request with a set of factors extracting some behavior into a service object, making explicit some things that were implicit and adding test." Side note, that's some hero work. I appreciate that right there. "It's gone through a few cycles of code review and pairing each time suggesting additional cleanups to do, requesting additional test coverage and that sort of thing. But the more we do, the more we discover that needs to be done.

+ +

So at this point, the merge request has been open for about eight weeks. I've paired with two other developers for probably 12 hours. The user is impatient, and we're tired of this darn thing and want it to go away. But it feels so bad. It really is severely lacking in test coverage. And the expected behaviors still aren't clearly defined. And it just doesn't meet the normal quality standards that we try to hold ourselves to. We could sit for another 8 to 40 hours and write more tests or documentation, but we're so drained from this whole thing.

+ +

So overall, we're really struggling to balance two things. We want to get things out the door, have short-lived PRs, and focus on incremental improvement. However, we still don't have defined requirements of how the feature is supposed to work across all permutations. And we can't write proper tests until expected behavior is defined more clearly. It feels like that's a baseline requirement before being able to merge or refactor. We'd love to hear any thoughts. Sincerely, Michael and Ben." Ooh, friend, there is so much we can dive into here. Would you like me to get started, or would you like to start?

+ +

CHRIS: Yeah, I've got a handful of thoughts because, as you highlighted, this is all of the stuff. This is the murky pile of complexity that writing code and delivering value in an organization is made up of. I'm going to start at a random place and then just start saying things because I think there is not a singular answer to this is an important starting line. We're not going to say, oh, if you just did X, then it would be fine. Obviously, this is a number of different complexities and situations, both person or both interpersonal human, and then code, and et cetera, et cetera.

+ +

So one of the things that actually came in the latter part of what you were reading there is we do not have defined requirements as to how this feature is supposed to work across all permutations of how it can be used. And that one is really interesting to me because right now, I wonder if there's something that can be done there. So often, you have code that does some stuff but also could do other stuff. And it's not clear if it's actually intended to do that other stuff or if that's just something that falls out of overly permissive like, we'll take any data you throw at us, and then we'll do some stuff. Typically, we don't actually want that. We want a more constrained system that's doing something. So that particular part was really interesting. Some of the conversations about testing were really interesting.

+ +

I think one of the things I would do is I would really ask, is this worth the effort? This code is kind of doing its thing. It's been around for a while. It's business-critical, but nobody really understands. It's like, is there a version of just leaving it at rest? Probably not. I typically would not do that. But it is a question that I think is worth asking because it can be really hard to make these changes on an under-defined system written in legacy technologies and whatnot, especially ones that we don't necessarily have as much...like, I haven't worked in jQuery for a while. So I wouldn't be quite as good at that. I wouldn't be able to understand that code as intuitively. That might be similar for this team.

+ +

So is there a version of just letting it lie? That is the first question I would ask. Presuming that's not the case, then I think I start to look at what is the attack that I would take to approach this. And I would definitely start with, hopefully, some small but meaningful introductions of test coverage but as a standalone thing. It's not part of the big change of a pull request. It's merely trying to lock in the code as it exists.

+ +

Again, I think I've referenced this talk perhaps more than any other, but Katrina Owens'Therapeutic refactoring is a really wonderful story and talk and really talks through this idea in a great way, but also it's just fun watch. But in it, Katrina talks about her approach to a similar thing where she was like, there's some code, and nobody really knows what it does. So I'm going to try and lock it down. And the first thing that she does is wraps test coverage around this code. So at least whatever it's doing now, we've constrained it a little bit. And actually, via the testing that she does, she ends up using that as a mechanism to sort of what does this system do? And finds a way to exercise the system and determine what its behavior actually is because nobody really knows that at this point.

+ +

So I would start with the testing. And then I would ask the question of we don't really know what it does across all permutations. Is there a way to actually constrain that? And say, let's actually lock some stuff down. Let's add a tiny bit of code that looks at the inputs being requested or coming into this code path or whatever it is but actually explicitly delineates what we think is the expected inputs and rejects or at least logs things that are surprising and that are like, we don't think it should do any of this. And then suddenly, if you see that showing up in the logs, you're like, I guess it does need to do that. Now we have a better idea of what is the actual target that we're trying to hit.

+ +

But really, both of those in my mind are ways to try and constrain the problem to try and add a little bit of support before tackling the hard work of the refactor because, just to be clear, you're probably going to break it in the refactor. I've broken every single system like this that I've tried to refactor without question. And there's a certain amount of organizational trust that you need to have. And it just gets to be a very complex time. And so anything that I can do to provide some guide rails, some support, something to help me in that time is something that I'm going to start with before I even go near the refactor itself. So those are some thoughts scattered around throughout the question. What do you think, Steph? What comes top of mind for you as you hear this question?

+ +

STEPH: I think those are great thoughts. And to expand on what you're talking about determining the expected behavior, that's also one of the bits that jumped out to me. And I love that you asked the question, can we leave it at rest? It sounds like yes, but there are some user concerns that come through or some bug reports. And then the team has to collectively say, "Yes, we are going to put someone through a difficult time to either do maybe a gross fix or implementation." And then we're making this area of the codebase feel worse and more accepting of different flows and adding to the number of flows that we have. Or we document it as won't fix and then provide a workaround.

+ +

So I really like that you said, "Can we leave it at rest?" Because I think that helps a team make a decision together as to like, what is the understanding of this part of the codebase functionality? How important is it to the business? If we decide that it's not that important to the business, then it's frankly not worth anybody's time working on it even if it feels really bad and you know there's this gross code over here, and you really want to go work on it. But if it's not important to the business, then it just shouldn't be done. And it needs to be left alone until the business decides this is important to our functionality. We do want to prioritize this work, and we're going to work on it together. And I still think there are a couple of nuanced strategies even from there.

+ +

So if you're looking for the more incremental improvements of we can't totally let this lie...we do have to improve it. But we're also not willing to invest in an overhaul situation. So some of the incremental improvements would be, as you'd mentioned, adding some test coverage to it to at least start to lock in the behavior that's already there and establish a baseline of understanding and then document that behavior. I've also found that really helps for context switching. So if you go in and you just document one part of that system as something that it does, then it frees you up. You can add something. You can issue a smaller merge request. You can get that merged because you're just adding test coverage. So it's not going to break anything. You're not making code changes. But then you can nearly let that go. And you can jump to something else that the team or the business has decided that's more important.

+ +

Some other areas that I've used in the past for working in these types of legacy or just bug-prone areas is to look for flows that are no longer in use. So if there's something that stands out to me as like, I'm pretty sure users aren't using this, or this code just looks unused. Maybe it's running a tool like Unused, which we can link to in the show notes, and see if there's truly something that's unused that you can just immediately remove. Or maybe it's logging a message to Rollbar or something similar. So that way, you know this is actually being used, but you can have it log whenever that's being run. Let that live for a month and then go back and check to see if that flow is ever executed.

+ +

As for the larger overhaul approach, that really has to be a team effort. So this has to be one of those moments of like the company decides this is important. And there may be smaller wins you can look for, but I do think it's going to require at least a developer or the product manager to be invested and ideally a designer as well. And then some small steps there may be looking for reducing responsibility of that feature. So maybe it's this really verbose long form that's complicated. And maybe you can collect some of that information somewhere else in the app. So you can start to chip away at some of the responsibilities in that portion of the application.

+ +

Or maybe you have a mini design sprint. You may realize this is a very important part of your application. We should really have this be a better experience for users. And let's really take a hard look at what this does and start to document. And that's the bigger like we're going to rebuild this, or the whole team is going to focus on this and improve this portion of the application. So that was in response to some of the lovely things that you said that you made me think of.

+ +

The other thing that really jumped out to me is this merge request that's sitting because this person, Michael or Ben, they've already done some really hard work where they have decided to add test coverage. They've cleaned up some things. And I can certainly relate to you issue a pull request and someone...because you've started cleaning up a space, people are like, "Oh, what about that cobweb? And then you missed a spot. What about over here?" And so, how do you make progress when you're in that state? And I would say move the goal line and merge the pull request.

+ +

So your goal line sounds like right now is trying to address everything which doesn't feel humanly possible. So instead, move the goal line. Figure out okay, I just want to add these couple of tests, or I just want to add this refactor to a function or something that documents this part of the system. And if people are nervous about merging the current merge request because it has gotten so big and people have made so many small requests, is to then break it up into smaller, more focused PR. So then it makes it easier for people to say, "Yes, that does improve the state of this codebase. Please merge it."

+ +

And I will often prefix my PRs with that. I'll say, "Dear reviewer, this PR is intended to improve the state of the world. It does not improve everything because I can't, but this is the goal of this." So that way, people go in with the mindset of they'll realize they're still going to see some cruft. But this is still leading us towards a better place. And unless there are strong concerns about the changes made in that specific PR, any other requests need to be noted and then can be captured somewhere else, but we're not going to address it right now in this PR.

+ +

CHRIS: I agree so very much with all of the things you just said. For anyone at home who cannot see us on the Skype call that we're on, I was just aggressively nodding my head the entire time Steph was saying all of that. [chuckles] You touched on I think all of the additional points that I would want to make specific to this merge request is out there in the world and whatnot.

+ +

The one other tiny bit that I would add to it is I have definitely been the person, and then I've also been on the other side of it where people get attached to the code that they've written. "But I've already written the merge request." And you're like, "Yeah, but can you break it up?" And they're like, "Yeah, but it already is a thing. And I did a bunch of work. And now I'm emotionally invested in this pile of work getting across the finish line and breaking it apart..." We can get caught up in our code.

+ +

And this is a really great example of this thing just got away from you. This is too big of a refactor. It's too much of a risk. And so again, I have struggled with this personally where I'm like, I'm so proud of this pile of work that I just made. And people are like, "Yeah, but that's a big pile of work there." I'm like, "You're right. You're right. I should break this up. I will break this up." But I can feel that resistance in myself to doing that, what feels like extra work, what feels like almost undoing of work. It's like, "No, no, no. I think it's ready." I'll be like, "I don't know, I'm not convinced. Can we break it apart?" And that's almost always the right decision. But it can be painful.

+ +

And so, just knowing that and having that in the back of your head as a thing that my brain will tell me the opposite. My brain will be like, no, no, go with it. It's great. We're proud of this. But being open to the idea that breaking things up is good, smaller pieces are good, et cetera, et cetera, can be a useful psychological aspect of this conversation because,, of course, there's one more facet. There are so many facets to this question.

+ +

STEPH: I like that anecdote about that you haven't regretted breaking things up because I also relate to that where there's that initial like, I've already done this much work. And now you're asking me to do more work. And it's going to have the same outcome where it's still going to be the same code. It's still going to be the same set of changes, but you're asking me to break it up into smaller changes. And I just feel exhausted from this work already. And I don't want to have to break this up. So I understand and relate to that initial resistance.

+ +

But I also really like the idea that all of these changes and everything going into the codebase is managed by a team. So we really want there to be a level of comfort from the team that this is what's going in. And as the author of the changes, I am far more comfortable with everything that's about to get merged in because I've spent so much time with it. So for me, whenever I do feel that initial resistance, I have to ask myself, well, what's the value? Will this make it easier for folks to review? Maybe it will show some areas that I didn't add test coverage because it felt like it was already getting so large. And so I started to negotiate with myself as to like, well, maybe I don't need to test that because this is already getting so big. And I don't want to add more to it.

+ +

So I really think through what's the value of if I break it up? And will it make the team more confident in this change? And ultimately if it does, then to me, that's always a resounding yes. So it's just going through what's the value versus what's my initial oh, this is a waste of my time to oh no, this is a good use of my time because it really benefits everyone else.

+ +

Circling back to something else that was said in the question was the message that we're just so drained from the whole thing. And I really don't want to take that for granted because that's really important. And it sounds like someone has taken their own time and hopefully company time to work on this. But it's not a team initiative. So this does feel like one of those areas where it feels like the team needs to prioritize whether this gets worked on or not. And it's okay if the team says, "Yes, this is important, but six months from now because we need a break from it." But as long as it's something that the team worked on together to say this is important, or it's not, I feel like that's an important part. And also to recognize that we don't have to fix all of this right now. That's really important for the company to buy into it.

+ +

I have two small things that I want to add, sort of the what not to do because we've been talking about some things that we would do. And so one thing that I definitely wouldn't do is avoid having one person going off and trying to fix this part of the codebase. Don't have one person, either a designer, developer, just a single soul who's like, I can fix this, and tackle it, and define all the things, and improve it. That's going to go poorly. Don't do that.

+ +

And then also, I would avoid refactoring just to refactor, which I think goes a little bit against Therapeutic Refactoring, which is a talk that I absolutely love. But if we're really invested in proving this part of the codebase, then I think it is very helpful and important to have a fixed user deliverable goal driving your refactor because that's also going to help shape and influence your PRs and encourage the team to take the time to review those PRs and get them merged.

+ +

So there's a nice coupling there where you want something driving that goal. Granted, it could be different for different teams. Therapeutic Refactoring may work wonderfully. But I've just seen so many people sink a lot of time into something, get very frustrated, then nothing gets shipped. So I would favor leaning more until we have this very focused thing that we're going to deliver, whether it's adding a test or two tests. Have a goal in mind when you start that refactor.

+ +

CHRIS: Again, I find myself nodding aggressively with everything that you're saying. And in addition, I really like the subtlety that you're bringing to one of my favorite talks. I've mentioned many times that this is one of my favorite talks. But I think you've added a really interesting like, yeah, but also, in the way that everything depends, it also depends. And I think you framed that really well that refactoring for refactoring sake can be fun and therapeutic, and cathartic for an individual. But we have to make sure it's part of the overall work that we're doing.

+ +

And you've now, I think, really well captured the human side of this work that is captured in what is such a complicated, nuanced question that I think also does such a good job of just highlighting the work. This is what it looks like. This is a particular almost perfect storm of the work, but that happens. But each little piece of this that we've talked about is this is the day-to-day of software development interestingly. I always thought it was just going to be writing for loops. I haven't written a for loop in years. I don't even know how to write a for loop. But this stuff is what I do every day. [laughter]

+ +

STEPH: The most challenging part for me in software I realized is when a problem has escalated to the point where it's like, I can't just write code to fix this. I need to go to the team. I need to get buy-in. And that's where I start to realize this is where software to me really gets hard because then I need other people to contribute and to get their opinions. And it turns out way better for it. But yes, that is definitely the intersection for me where I can write code up to a certain point to then I really need people to help make really great software and fix some of the underlying issues that we're facing.

+ +

On that note, Michael and Ben, thank you so much for writing this in to us. I'm very interested to hear how this turns out for your team. And thank you so much. I wish you the best of luck. On that note, Shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+x9fmoKGs + + ]]> + + Chris Toomey + Steph Viccari + + + 315: Emotions Are A Pendulum + https://bikeshed.thoughtbot.com/315 + 4e9777d9-c20c-46f5-b3b2-ff1a9312b554 + Tue, 09 Nov 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request. + 41:23 + no + + + Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +rspec-retry (https://github.com/NoRedInk/rspec-retry) +Cassidy Williams - It Depends - GitHub Universe 2021 (https://www.youtube.com/watch?v=aMWh2uLO9OM) +Say No To More Process (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) +StandardRB (https://github.com/testdouble/standard) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +CHRIS: My new computer is due on the fourth. I'm so close. +STEPH: On the fourth? +CHRIS: On the fourth. +STEPH: That's so exciting. +CHRIS: And I'm very excited. But no, I don't want to upgrade any software on this computer anymore. Never again shall I update a piece of software on this computer. +STEPH: [laughs] +CHRIS: This is its final state. And then I will take its soul and move it into the new computer, and we'll go from there. [chuckles] +STEPH: Take its soul. [laughs] +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we learn along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. Let's see. It's been kind of a busy week. It's been a busy family week. Utah, my dog, hasn't been feeling well as you know because you and I have chatted off-mic about that a bit. So he is still recovering from something, I don't know what. He's still on most days his normal captain chaos self, but then other days, he's not feeling well. So I'm just keeping a close eye on him. And then I also got some other family illnesses going on. So it has been a busy family week for sure. +On the more technical project side, I am wrapping up my current project. So I have one more week, and then I will shift into a new project, which I'm very excited about. And you and I have chatted about this several times. So there's always just that interesting phase where you're trying to wrap up and hand things off and then accomplish last-minute wishlist items for a project before then you start with a new one. So I am currently in that phase. +CHRIS: How long were you on this project for? +STEPH: It'll be a total of I think eight months. +CHRIS: Eight months, that's healthy. That's a bunch. It's always interesting to be on a project for that long but then not longer. There were plenty of three and four-month projects that I did. And you can definitely get a large body of work done. You can look back at it and proudly stare at the code that you have written. But that length of time is always interesting to me because you end up really...for me, when I've had projects that went that long but then not longer, I always found that to be an interesting breaking point. How are you feeling moving on from it? Are you ready for something new? Are you sad to be moving on? Do you feel attached to things? +STEPH: It's always a mix. I'm definitely attached to the team, and then there are always lots of things that I'd still love to work on with that team. But then, I am also excited to start something new. That's why I love this role of consulting because then I get to hop around and see new projects and challenges and work with new people. I'm thinking seven to eight months might be a sweet spot for me in terms of the length of a project. Because I find that first month with a project, I'm really still ramping up, I'm getting comfortable, I'm getting in the groove, and I'm contributing within a short amount of time. But I still feel like that first month; I’m getting really comfortable with this new environment that I'm in. And so then I have that first month. +And then, at six months, I have more of heads-down time. And I get to really focus and work with a team. And then there's that transition period, and it's nice to know when that's coming up for several weeks, so then I have a couple of weeks to then start working on that transition phase. So eight months might be perfect because then it's like a month for onboarding, ramping up, getting comfortable. And then six months of focus, and then another month of just focusing on what needs to be transitioned so then I can transition off the team. +CHRIS: All right. Well, now we've defined it - eight months is the perfect length of a project. +STEPH: That's one of the things I like about the Boost team is because we typically have longer engagements. So that was one of the reasons when we were splitting up the teams in thoughtbot that I chose the Boost team because I was like, yeah, I like the six-month-plus project. +Speaking of that wishlist, there are little things that I've wanted to make improvements on but haven't really had time to do. There's one that's currently on my mind that I figured I'd share with you in case you have thoughts on it. But I am a big proponent of using the RSpec focus filter for when running tests. So that way, I can just prefix a context it block or describe block with F, and then RSpec I can just run all the tests. But RSpec will only run the tests that I've prefixed with that F focus command., and I love it. +But we are running into some challenges with it because right now, there's nothing that catches that in a pull request. So if you commit that focus filter on some of your tests, and then that gets pushed up, if someone doesn't notice it while reviewing your pull request, then that gets merged into main. And all of the tests are still green, but it's only a subset of the tests that are actually running. And so it's been on my mind that I'd love something that's going to notice that, that's going to catch it, something that is not just us humans doing our best but something that's automated that's going to notice it for us. And I have some thoughts. But I'm curious, have you run into something like this? Do you have a way that you avoid things like that from sneaking into the main branch? +CHRIS: Interestingly, I have not run into this particular problem with RSpec, and that's because of the way that I run RSpec tests. I almost never use the focus functionality where you actually change the code file to say, instead of it, it is now fit to focus that it. +I tend to lean into the functionality where RSpec you can pass it the line number just say, file: and then line number. And RSpec will automatically figure out which either spec or context block or entire file. And also, I have Vim stuff that allows me to do that very easily from the file. It's very rare that I would want to run more than one file. +So basically, with that, I have all of the flexibility I need. And it doesn't require any changes to the file. So that's almost always how I'm working in that mode. I really love that. And it makes me so sad when I go to JavaScript test runners because they don't have that. +That said, I've definitely felt a very similar thing with ESLint and ESLint yelling at me for having a console.log. And I'm like, ESLint, I'm working here. I got to debug some stuff, so if you could just calm down for a minute. And what I would like is a differentiation between these are checks that should only run in CI but definitely need to run in CI. And so I think an equivalent would be there's probably a RuboCop rule that says disallow fit or disallow any of the focus versions for RSpec. But I only want those to run in CI. +And this has been a pain point that I felt a bunch of times. And it's never been painful enough that I put in the effort to fix it. But I really dislike particularly that version of I'm in my editor, and I almost always want there to be no warnings within the editor. I love that TypeScript or ESLint, or other things can run within the editor and tell me what's going on. But I want them to be contextually aware. And that's the dream I've yet to get there. +STEPH: I like the idea of ESLint having a work mode where you're like, back off, I am in work mode right now. [chuckles] I understand that I won't commit this. +CHRIS: I'm working here. [laughter] +STEPH: And I like the idea of a RuboCop. So that's where my mind went initially is like, well, maybe there's a custom cop, or maybe there's an existing one, and I just haven't noticed it yet. But so I'm adding a rule that says, hey, if you do see an fcontext, fdescribe, ffit, something like that, please fail. Please let us know, so we don't merge this in. So that's on my wishlist, not my to-don't list. That one is on my to-do list. +CHRIS: I'm also intrigued, though, because the particular failure mode that you're describing is you take what is an entire spec suite, and instead, you focus down to one context block within a given file. So previously, there were 700 specs that ran, and now there are 12. And that's actually something that I would love for Circle or whatever platform you're running your tests on to be like, hey, just as a note, you had been slowly creeping up and had hit a high watermark of roughly 700 specs. And then today, we're down to 12. So either you did some aggressive grooming, or something's wrong. But a heuristic analysis of like, I know sometimes people delete specs, and that's a thing that's okay but probably not this many. So maybe something went wrong there. +STEPH: I feel like we're turning CI into this friend at the bar that's like, "Hey, you've had a couple of drinks. I just wanted to check in with you to make sure that you're good." [laughs] +CHRIS: Yes. +STEPH: "You've had 100 tests that were running and now only 50. Hey, friend, how are you? What's going on?" +CHRIS: "This doesn't sound like you. You're normally a little more level-headed." [laughs] And that's the CI that is my friend that keeps me honest. It's like, "Wait, you promised never to overspend anymore, and yet you're overspending." I'm like, "Thank you, CI. You're right; I did say I want the test to pass." +STEPH: [laughs] I love it. I'll keep you posted if I figure something out; if I either turn CI into that friend, that lets me know when my behavior has changed in a concerning way, and an intervention is needed. Or, more likely, I will see if there's a RuboCop or some other process that I can apply that will check for this, which I imagine will be fast. I mean, we're very mindful about ensuring our test suite doesn't slow down as we're running it. But I'm just thinking about this out loud. If we add that additional cop, I imagine that will be fast. So I don't think that's too much of an overhead to add to our CI process. +CHRIS: If you've already got RuboCop in there, I'm guessing the incremental cost of one additional cop is very small. But yeah, it is interesting. That general thing of I want CI to go fast; I definitely feel that feel. And we're slowly creeping up on the project I'm working on. I think we're at about somewhere between five to six minutes, but we've gotten there pretty quickly where not that long ago; it was only three minutes. +We're adding a lot of features specs, and so they are definitely accruing slowdowns in our CI. And they're worth it; I think, because they're so valuable. And they test the whole integration of everything, but it's a thing that I'm very closely watching. And I have a long list of things that I might pursue when I decide it's time for CI to get a haircut, as it were. +STEPH: I have a very hot tip for a way to speed up your test, and that is to check if any of your tests have a very long sleep in them. That came up recently [chuckles] this week where someone was working in a test and found some relic that had been added a while back that then wasn't caught. And I think it was a sleep 30. And they were like, "Hey, I just sped up our test by 30 seconds." I was like, ooh, we should grep now to see if there's anything else like that. [laughs] +CHRIS: Oh, I love the sentence we should grep now. [laughter] The correct response to this is to grep immediately. I thought you were going to go with the pro tip of you can just focus down to one context block. And then the specs will run so much faster because you're ignoring most of them, but we don't want to do that. The sleep, though, that's a pro tip. And that does feel like a thing that there could be a cop for, like, never sleep more than...frankly, let's try not to sleep at all but also, add a sleep in our specs. We can sleep in life; it's important, but anyway. [chuckles] +STEPH: [laughs] That was the second hot tip, and you got it. +CHRIS: Lots of hot tips. Well, I'm going to put this in the category of good idea, terrible idea. I won't call it a hot tip. It's a thing we're trying. So much as we have tried to build a spec suite that is consistent and deterministic and tells us only the truth, feature specs, even in our best efforts, still end up flaking from time to time. We'll have feature specs that fail, and then eventually, on a subsequent rerun, they will pass. And I am of the mindset that A, we should try and look into those and see if there is a real cause to it. But sometimes, just the machinery of feature specs, there's so much going on there. We've got the additional overhead of we're running it within a JavaScript context. There's just so much there that...let me say what I did, and then we can talk more about the context. +So there's a gem called RSpec::Retry. It comes from the wonderful folks over at NoRedInk, a well-known Elm shop for anyone out there in the Elm world. But RSpec::Retry does basically what it says in the name. If the spec fails, you can annotate specs. In our case, we've only enabled this for the feature specs. And you can tell it to retry, and you can say, "Retry up to this many times," and et cetera, et cetera. So I have enabled this for our feature specs. And I've only enabled it on CI. That's an important distinction. This does not run locally. +So if you run a feature spec and it fails locally, that's a good chance for us to intervene and look at whether or not there's some flakiness there. But on CI, I particularly don't want the case where we have a pull request, everything's great, and we merge that pull request, and then the subsequent rebuild, which again, as a note, I would rather that Circle not rebuild it because we've already built that one. But that is another topic that I have talked about in the past, and we'll probably talk about it again in the future. +But setting that aside, Circle will rebuild on the main branch when we merge in, and sometimes we'll see failures there. And that's where it's most painful. Like, this is now the deploy queue. This is trying to get this out into whatever environment we're deploying to. And it is very sad when that fails. And I have to go in and manually say, hey, rebuild. I know that this works because it just worked in the pull request, and it's the same commit hash. So I know deterministically for reasons that this should work. And then it does work on a rebuild. +So we introduced RSpec::Retry. We have wrapped it around our feature specs. And so now I believe we have three possible retries. So if it fails once, it'll try it again, and then it'll try it a third time. So far, we've seen each time that it has had to step in; it will pass on the subsequent run. But I don't know; there was some very gentle pushback or concerns; let’s call them when I introduced this pull request from another developer on the team, saying, "I don't know, though, I feel like this is something that we should solve at the root layer. The failures are a symptom of flaky tests, or inconsistency or et cetera, and so I'd rather not do this." And I said, "Yeah, I know. But I'm going to merge it," and then I merged it. +We had a better conversation about that. I didn't just broadly overrule. But I said, "I get it, but I don't see the obvious place to shore this up. I don't see where we're doing weird inconsistent things in our code. This is just, I think, inherent complexity of feature specs." So I did it, but yeah, good idea, terrible idea. What do you think, Steph? Maybe terrible is too strong of a word. Good idea, mediocre idea. +STEPH: I like the original branding. I like the good idea, terrible idea. Although you're right, that terrible is a very strong branding. So I am biased right now, so I'm going to lead in answering your question by stating that because our current project has that problem as well where we have these flaky tests. And it's one of those that, yes, we need to look at them. And we have fixed a large number of them, but there are still more of them. +And it becomes a question of are we actually doing something wrong here that then we need to fix? Or, like you said, is it just the nature of these features-specs? Some of them are going to occasionally fail. What reasonable improvements can we make to address this at the root cause? I'm interested enough that I haven't heard of RSpec::Retry that I want to check it out because when you add that, you annotate a test. When a test fails, does it run the entire build, or will it rerun just that test? Do you happen to know? +CHRIS: Just the test. So it's configured as in a round block on the feature specs. And so you tell it like, for any feature spec, it's like config.include for feature specs RSpec::Retry or whatever. So it's just going to rerun the one feature spec that failed when and if that happens. So it's very, very precise as well in that sense where when we have a failure merging into the main branch, I have to rebuild the whole thing. So that's five or six minutes plus whatever latency for me to notice it, et cetera, whereas this is two more seconds in our CI runtime. So that's great. But again, the question is, am I hiding? Am I dealing with the symptoms and not the root cause, et cetera? +STEPH: Is there a report that's provided at the end that does show these are the tests that failed and we had to rerun them? +CHRIS: I believe no-ish. You can configure it to output, but it's just going to be outputting to standard out, I believe. So along with the sea of green dots, you'll see had to retry this one. So it is visible, but it's not aggregated. And the particular thing is there's the JUnit reporter that we're using. So the XML common format for this is how long our tests took to run, and these ones passed and failed. +So Circle, as a particular example, has platform-level insights for that kind of stuff. And they can tell you these are your tests that fail most commonly. These are the tests that take the longest run, et cetera. I would love to get it integrated into that such that retried and then surface this to Circle. Circle could then surface it to us. But right now, I don't believe that's happening. So it is truly I will not see it unless I actively go search for it. To be truly honest, I'm probably not doing that. +STEPH: Yeah, that's a good, fair, honest answer. You mentioned earlier that if you want a test to retry, you have to annotate the test. Does that mean that you get to highlight specific tests that you're marking those to say, "Hey, I know that these are flaky. I'm okay with that. Please retry them." Or does it apply to all of them? +CHRIS: I think there are different ways that you can configure it. You could go the granular route of we know this is a flaky spec, so we're going to only put the retry logic around it. And that would be a normal RSpec annotation sort of tagging the spec, I think, is the terminology there. But we've configured it globally for all feature specs. So in a spec support file, we just say config.include Rspec::Retry where type is a feature. And so every feature spec now has the possibility to retry. If they pass on the first pass, which is the hope most of the time, then they will not be tried. But if they don't, if they fail, then they'll be retried up to three times or up to two additional times, I think is the total. +STEPH: Okay, cool. That's helpful. So then I think I have my answer. I really think it's a good idea to automate retrying tests that we have identified that are flaky. We've tried to address the root, and our resolution was this is fine. This happens sometimes. We don't have a great way to improve this, and we want to keep the test. So we're going to highlight that this test we want to retry. And then I'm going to say it’s not a great idea to turn it on for all of them just because then I have that same fear about you're now hiding any flaky tests that get introduced into the system. And nobody reasonably is going to go and read through to see which tests are going to get retried, so that part makes me nervous. +CHRIS: I like it. I think it's a balanced and reasonable set of good and terrible idea. Ooh, it's perfect. I don't think we've had a balanced answer on that yet. +STEPH: I don't think so. +CHRIS: This is a new outcome for this segment. I agree. Ideally, in my mind, it would be getting into that XML format, the output from the tests, so that we now have this artifact, we can see which ones are flaky and eventually apply effort there. What you're saying feels totally right of we should be more particular and granular. But at the same time, the failure mode and the thing that I'm trying, I want to keep deploys going. And I only want to stop deploys if something's really broken. +And if a spec retries, then I'm fine with it is where I've landed, particularly because we haven't had any real solutions where there was anything weird in our code. Like, there's just flakiness sometimes. As I say it, I feel like I'm just giving up. [laughs] And I can hear this tone of stuff's just hard sometimes, and so I've taken the easy way out. And I guess that's where I'm at right now. But I think what you're saying is a good, balanced answer here. I like it. I don't know if I'm going to do anything about it, but...[laughter] +STEPH: Well, going back to when I was saying that I'm biased, our team is feeling this pain because we have flaky tests. And we're creating tickets, and we're trying to do all the right things. We create a ticket. We have that. So it's public. So people know it's been acknowledged. If someone's working on it, we let the team know; hey, I'm working on this. So we're not duplicating efforts. And so, we are trying to address all of them. But then some of them don't feel like a great investment of our time trying to improve. +So that's what I really do like about the RSpec::Retry is then you can still have a resolution. Because it's either right now your resolution is to fix it or to change the code, so then maybe you can test it in a different way. There's not really a good medium step there. And so the retry feels like an additional good outcome to add to your tool bag to say, hey, I've triaged this, and this feels reasonable that we want to retry this. +But then there's also that concern of we don't want to hide all of these flaky tests from ourselves in case we have done it and there is an opportunity for us to improve it. So I think that's what I do really like about it because right now, for us, when a test fails, we have to rerun the entire build, and that's painful. So if tests are taking about 20 minutes right now, then one spec fails, and then you have to wait another 20 minutes. +CHRIS: I would have turned this on years ago with a 20-minute build time. [chuckles] +STEPH: [laughs] Yeah, you're not wrong. But also, I didn't actually know about RSpec::Retry until today. So that may be something that we introduce into our application or something that I bring up to the team to see if it's something that we want to add. But it is interesting that initial sort of ooh kind of feeling that the team will give you introducing because it feels bad. It feels wrong to be like, hey, we're just going to let these flaky tests live on, and we're going to automate retrying them to at least speed us up. And it's just a very interesting conversation around where we want to invest our time and between the risk and pay off. +And I had a similar experience this week where I had that conversation, but this one was more with myself where I was working through a particular issue where we have a state in the application where something weird was done in the past that led us to a weird state. And so someone raised a very good question where it's like, well, if what you're saying is technically an impossible state, we should make it impossible, like at the database layer. And I love that phrase. And yet, there was a part of me that was like, yes, but also doing that is not a trivial investment. And we're here because of a very weird thing that happened before. +It felt one of those interesting, like, do we want to pursue the more aggressive, like, let's make this impossible for the future? Or do we want to address it for now and see if it comes back up, and then we can invest more time in it? And I had a hard time walking myself through that because my initial response was, well, yeah, totally, we should make it impossible. But then I walked through all the steps that it would take to make that happen, and it was not very trivial. +And so it was one of those; it felt like the change that we ended up with was still an improvement. It was going to prevent users from seeing an error. It was still going to communicate that this state is an odd state for the application to be in. But it didn't go as far as to then add in all of the safety measures. And I felt good about it. But I had to convince myself to feel good about it. +CHRIS: What you're describing there, the whole thought sequence, really feels like the encapsulation of it depends. And that being part of the journey of learning how to do software development and what it means. And you actually shared a wonderful video with me yesterday, and it was Cassidy Williams at GitHub Universe. And it was her talking to her younger self, and just it depends, and it was so true. So we will include a link to that in the show note because that was a wonderful thing for you to share. And it really does encapsulate this thing. And from the outside, before I started doing software development, I'm like, it's cool. I'm going to learn how to sling code and fix the stuff and hack, and it'll be great, and obvious, and correct, and knowable. And now I'm like, oh man, squishy nonsense. That's all it is. +STEPH: [laughs] +CHRIS: Fun squishy, and I like it. It's so good. But it depends. Exactly that one where you're like, I know that there's a way to get to correctness here but is it worth the effort? And looping back to...I'm surprised at the stance that I've taken where I'm just like, yeah, I'm putting in RSpec::Retry. This feels like the right thing. I feel good about this decision. And so I've tried to poke at it a tiny bit. +And I think what matters to me deeply in a list of priorities is number one correctness. I care deeply that our system behaves correctly as intended and that we are able to verify that. I want to know if the system is not behaving correctly. And that's what we've talked about, like, if the test suite is green, I want to be able to deploy. I want to feel confident in that. +Flaky specs exist in this interesting space where if there is a real underlying issue, if we've architected our system in a way that causes this flakiness and that a user may ever experience that, then that is a broken system. That is an incorrect system, and I want to resolve that. But that's not the case with what we're experiencing. We're happy with the architecture of our system. And when we're resolving it, we're not even really resolving them. We're just rerunning manually at this point. We're just like, oh, that spec flaked. And there's nothing to do here because sometimes that just happens. So we're re-running manually. And so my belief is if I see all green, if the specs all pass, I know that I can deploy to production. +And so if occasionally a spec is going to flake and retrying it will make it pass (and I know that pass doesn't mean oh, this time it happened to pass; it's that is the correct outcome) and we have a false negative before, then I'm happy to instrument the system in a way that hides that from me because, at this point, it does feel like noise. I'm not doing anything else with the failures when we were looking at them more pointedly. I'm not resolving those flaky specs. There are no changes that we've made to the underlying system. And they don't represent a failure mode or an incorrectness that an end-user might see. So I honestly want to paper over and hide it from myself. And that's why I've chosen this. But you can see I need to defend my actions here because I feel weird. I feel a little off about this. But as I talk through it, that is the hierarchy. I care about correctness. +And then, the next thing I care about is maintaining the deployment pipeline. I want that to be as quick and as efficient as possible. And I've talked a bunch about explorations into the world of observability and trying to figure out how to do continuous deployment because I think that really encourages overall better engineering outcomes. And so first is correctness. Second is velocity. And flaky specs impact velocity heavily, but they don't actually impact correctness in the particular mode that we're experiencing them here. They definitely can. But in this case, as I look at the code, I'm like, nah, that was just noise in the system. That was just too much complexity stacked up in trying to run a feature spec that simulates a browser and a user clicking in JavaScript and all this stuff and the things. But again, [laughs] here I am. I am very defensive about this apparently. +STEPH: Well, I can certainly relate because I was defending my answer to myself earlier. And it is really interesting what you're pointing out. I like how you appreciate correctness and then velocity, that those are the two things that you're going after. And flaky tests often don't highlight an incorrect system. It is highlighting that maybe our code or our tests are not as performant as we would like them to be, but the behavior is correct. So I think that's a really important thing to recognize. +The part where I get squishy is where we have encountered on this project some flaky tests that did highlight that we had incorrect behavior, and there's only been maybe one or two. It was rare that it happened, but it at least has happened once or twice where it highlighted something to us that when tests were run...I think there's a whole lot of context. I won't get into it. But essentially, when tests were being run in a particular way that made them look like a flaky test, it was actually telling us something truthful about the system, that something was behaving in a way that we didn't want it to behave. So that's why I still like that triage that you have to go through. +But I also agree that if you're trying to get out at a deploy, you don't want to have to deal with flaky tests. There's a time to eat your vegetables, and I don't know if it's when you've got a deploy that needs to go out. That might not be the right time to be like, oh, we've got a flaky test. We should really address this. It's like, yes; you should note to yourself, hey, have a couple of vegetables tomorrow, make a ticket, and address that flaky test but not right now. That's not the time. So I think you've struck a good balance. But I also do like the idea of annotating specific tests instead of just retrying all of them, so you don't hide anything from yourself. +CHRIS: Yeah. And now that I'm saying it and now that I'm circling back around, what I'm saying is true of everything we've done so far. But it is possible that now this new mode that the system behaves in where it will essentially hide flaky specs on CI means that any new flaky regressions, as it were, will be hidden from us. +And thus far, almost all or I think all of the flakiness that we've seen has basically been related to timeouts. So a different way to solve this would potentially be to up the Capybara wait time. So there are occasionally times where the system's churning through, and the various layers of the feature specs just take a little bit longer. And so they miss...I forget what it is, but it's like two seconds right now or something like that. And I can just bump that up and say it's 10 seconds. And that's a mode that if eventually, the system ends in the state that we want, I'm happy to wait a little longer to see that, and that's fine. +But there are...to name some of the ways that flaky tests can actually highlight truly incorrect things; race conditions are a pretty common one where this behaves fine most of the time. But if the background job happens to succeed before the subsequent request happens, then you'll go to the page. That's a thing that a real user may experience, and in fact, it might even be more likely in production because production has differential performance characteristics on your background jobs versus your actual application. And so that's the sort of thing that would definitely be worth keeping in mind. +Additionally, if there are order issues within your spec suite if the randomize...I think actually RSpec::Retry wouldn't fix this, though, because it's going to retry within the same order. So that's a case that I think would be still highlighted. It would fail three times and then move on. But those we should definitely deal with. That's a test-related thing. But the first one, race conditions, that's totally a thing. They come up all the time. And I think I've potentially hidden that from myself now. And so, I might need to lock back what I said earlier because I feel like it's been true thus far that that has not been the failure mode, but it could be moving forward. And so I really want to find out if we got flaky specs. I don't know; I feel like I've said enough about this. So I'm going to stop saying anything new. [laughs] Do you have any other thoughts on this topic? +STEPH: Our emotions are a pendulum. We swing hard one way, and then we have to wait till we come back and settle in the middle. But there's that initial passion play where you're really frustrated by something, and then you swing, and you settle back towards something that's a little more neutral. +CHRIS: I don't trust anyone who pretends like their opinions never change. It doesn't feel like a good way to be. +STEPH: Oh, I hope that...Do people say that? I hope that's not true. I hope we are all changing our opinions as we get more information. +CHRIS: Me too. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: Well, shifting only ever so slightly because it turns out it's a very related question, but we have a listener question. As always, thank you so much to everyone who sends in listener questions. We really appreciate them. And today's question comes from Mikhail, and he writes in, "Regarding the discussion in Episode 311 on requiring commits merged to be tested, I have a question on how you view multi commit PRs. Do you think all the commits in a PR should be tested or only the last one? If you test all commits in a PR, do you have any good tips on setups for that? Would you want all commits to pass all tests? For one, it helps a lot when using Git bisect. It is also a question of keeping the history clean and understandable. +As a background on the project I currently work on, we have the opinion that all commits should be tested and working. We have now decided on single commit PRs only since this is the only way that we can currently get the setup reasonably on our CI. I would like to sometimes make PRs with more than one commit since I want to make commits as small as possible. In order to do that, we would have to find a way to make sure all commits in the PR are tested. There seems to be some hacky ways to accomplish this, but there is not much talk about it. Also, we are strict in requiring a linear history in all our projects. Kind regards, Mikhail." So, Steph, what do you think? +STEPH: I remember reading this question when it came in. And I have an experience this week that is relevant to this mainly because I had seen this question, and I was thinking about it. And off the cuff, I haven't really thought about this. I haven't been very concerned about ensuring every single commit passes because I want to ensure that, ultimately, the final commit that I have is going in. +But I also rarely have more than one commit in a PR. So that's often my default mode. There are a couple of times that I'll have two, maybe three commits, but I think that's pretty rare for me. I'll typically have just one commit. So I haven't thought about this heavily. And it's not something that frankly I've been concerned about or that I've run into issues with. +From their perspective about using Git bisect, I could see how that could be troublesome, like if you're looking at a commit and you realize there's a particular commit that's already merged and that fails. The other area that I could think of where this could be problematic is if you're trying to roll back to a specific commit. And if you accidentally roll back to a commit that is technically broken, but you didn't know that because it was not the final commit as was getting tested on CI, that could happen. I haven't seen that happen. I haven't experienced it. So while that does seem like a legitimate concern, it's also one that I frankly just haven't had. +But because I read this question from this person earlier this week, I actually thought about it when I was crafting a PR that had several commits in it, which is kind of unusual for me since I'm usually one or two commits in a PR. But for this one, I had several because we use standard RB in our project to handle all the formatting. And right now, we have one of those standard to-do files because we added it to the project. But there are still a number of manual fixes that need to be applied. +So we just have this list of files that still need to be formatted. And as someone touches that file, we will format it, and then we'll take it out of that to-do list. So then standard RB will include it as it's linting all of our files. And I decided to do that for all of our spec files. Because I was like, well, this was the safest chunk of files to format that will require the least amount of review from folks. So I just want to address all of them in one go. But I separated the more interesting changes into different commits just to make others aware of, like, hey, this is something standard RB wants. +And it was interesting enough that I thought I would point it out. So my first commit removed all the files from that to-do list, but then my other commits are the ones that made actual changes to some of those files that needed to be corrected. So technically, one or two of my middle commits didn't pass the standard RB linting. But because CI was only running that final commit, it didn't notice that. +And I thought about this question, and so I intentionally went back and made sure each of those commits were correct at that point in time. And I feel good about that. But I still don't feel the need to add more process around ensuring each commit is going to be green. I think I would lean more in favor of let's keep our PR small to one or two commits. But I don't know; it’s something I haven't really run into. It's an interesting question. How about you? What are your experiences, or what are your thoughts on this, Chris? +CHRIS: When this question came through, I thought it was such an interesting example of considering the cost of process changes. And to once again reference one of our favorite blog posts by German Velasco, the Say No to More Process post, which we will, of course, link in the show notes. This is such a great example of there was likely a small amount of pain that was felt at one point where someone tried to run git bisect. They ran into a troublesome commit, and they were like, oh no, this happened. We need to add processes, add automation, add control to make sure this never happens again. +Personally, I run git bisect very rarely. When I do, it's always a heroic moment just to get it started and to even know which is the good and which is the bad. It's always a thing anyway. So it would be sad if I ran into one of these commits. But I think this is a pretty rare outcome. I think in the particular case that you're talking about, there's probably a way to actually tease that apart. I think it sounds like you fixed those commits knowing this, maybe because you just put it in your head. But the idea that the process that this team is working on has been changed such that they only now allow single commit PRs feels like too much process in my mind. I think I'm probably 80%, maybe 90% of the time; it’s only a single commit in a PR for me. +But occasionally, I really value having the ability to break it out into discrete steps, like these are all logically grouped in one changeset that I want to send through. But they're discrete steps that I want to break apart so that the team can more easily review it so that we have granular separation, and I can highlight this as a reference. That's often something that I'll do is I want this commit to standalone because I want it to be referenced later on. I don't want to just fold it into the broader context in which it happened, but it's pretty rare. And so to say that we can't do that feels like we're adding process where it may not be worth it, where the cost of that process change is too high relative to the value that we're getting, which is speculatively being able to run git bisect and not hit something problematic in the future. +There's also the more purist, dogmatic view of well, all commits should be passing, of course. Yeah, I totally agree with that. But what's it worth to you? How much are you willing to spend to achieve that goal? I care deeply about the correctness of my system but only the current correctness. I don't care about historical correctness as much, some. I think I'm diminishing this more than I mean to. But really back to that core question of yes, this thing has value, but is it worth the cost that we have to pay in terms of process, in terms of automation and maintenance of that automation over time, et cetera or whatever the outcome is? Is it worth that cost? And in this case, for me, this would not be worth the cost. And I would not want to adopt a workflow that says we can only ever have single commit PRs, or all commits must be run on CI or any of those variants. +STEPH: This is an interesting situation where I very much agree with everything you're saying. But I actually feel like what Mikhail wants in this world; I want it too. I think it's correct in the way that I do want all the commits to pass, and I do want to know that. And I think since I do fall into the default, like you mentioned, 80%, 90% of my PRs are one commit. I just already have that. And the fact that they're enforcing that with their team is interesting. And I'm trying to think through why that feels cumbersome to enforce that. +And I'm with you where I'll maybe have a refactor commit or something that goes before. And it's like, well, what's wrong with splitting that out into a separate PR? What's the pain point of that? And I think the pain point is the fact that one, you have two PRs that are stacked on each other. So you have the first one that you need to get reviewed, and then the second one; there’s that bit of having to hop between the two if there's some shared context that someone can't just easily review in one pull request. +But then there's also, as we just mentioned, there's CI that has to run. And so now it's running on both of them, even though maybe that's a good thing because it's running on both commits. I like the idea that every commit is tested, and every commit is green. But I actually feel like it's some of our other processes that make it cumbersome and hard to get there. And if CI did run on every commit, I think it would be ideal, but then we are increasing our CI time by running it on every commit. +And then it comes down to essentially what you said, what's the risk? So if we do merge in a commit that doesn't work or has something that's failing about it but then the next commit after that fixes it, what's the risk that we're going to roll back to that one specific commit that was broken? If that's a high risk for you and your team, then adding this process is probably the really wise thing to do because you want to make sure the app doesn't go down for users. That's incredibly important. If that's not a high risk for your team, then I wouldn't add the process. +CHRIS: Yeah, I totally agree. And to clarify my stances, for me, this change, this process change would not be worth the trade-off. I love the idea. I love the goal of it. But it is not worth the process change, and that's partly because I haven't particularly felt the pain. CI is not an inexhaustible resource I have learned. I'm actually somewhat proud our very small team that is working on the project that we're working on; we just recently ran out of our CI budget, and Circle was like, "Hey, we got to charge you more." And I was like, "Cool, do that." But it was like, there is cost both in terms of the time, clock time, and each PR running and all of those. We have to consider all of these different things. +And hopefully, we did a useful job of framing the conversation, because as always, it depends, but it depends on what. And in this case, there's a good outcome that we want to get to, but there's an associated cost. And for any individual team, how you weigh the positive of the outcome versus how you weigh the cost will alter the decision that you make. But that's I think, critically, the thing that we have to consider. +I've also noticed I've seen this conversation play out within teams where one individual may acutely feel the pain, and therefore they're anchored in that side. And the cost is irrelevant to them because they're like, I feel this pain so acutely, but other people on the team aren't working in that part of the codebase or aren't dealing with bug triage in the same way that that other developer is. And so, even within a team, there may be different levels of how you measure that. And being able to have meaningful conversations around that and productively come to a group decision and own that and move forward with that is the hard work but the important work that we have to do. +STEPH: Yeah. I think that's a great summary; it depends. On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: My new computer is due on the fourth. I'm so close.

+ +

STEPH: On the fourth?

+ +

CHRIS: On the fourth.

+ +

STEPH: That's so exciting.

+ +

CHRIS: And I'm very excited. But no, I don't want to upgrade any software on this computer anymore. Never again shall I update a piece of software on this computer.

+ +

STEPH: [laughs]

+ +

CHRIS: This is its final state. And then I will take its soul and move it into the new computer, and we'll go from there. [chuckles]

+ +

STEPH: Take its soul. [laughs]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we learn along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Let's see. It's been kind of a busy week. It's been a busy family week. Utah, my dog, hasn't been feeling well as you know because you and I have chatted off-mic about that a bit. So he is still recovering from something, I don't know what. He's still on most days his normal captain chaos self, but then other days, he's not feeling well. So I'm just keeping a close eye on him. And then I also got some other family illnesses going on. So it has been a busy family week for sure.

+ +

On the more technical project side, I am wrapping up my current project. So I have one more week, and then I will shift into a new project, which I'm very excited about. And you and I have chatted about this several times. So there's always just that interesting phase where you're trying to wrap up and hand things off and then accomplish last-minute wishlist items for a project before then you start with a new one. So I am currently in that phase.

+ +

CHRIS: How long were you on this project for?

+ +

STEPH: It'll be a total of I think eight months.

+ +

CHRIS: Eight months, that's healthy. That's a bunch. It's always interesting to be on a project for that long but then not longer. There were plenty of three and four-month projects that I did. And you can definitely get a large body of work done. You can look back at it and proudly stare at the code that you have written. But that length of time is always interesting to me because you end up really...for me, when I've had projects that went that long but then not longer, I always found that to be an interesting breaking point. How are you feeling moving on from it? Are you ready for something new? Are you sad to be moving on? Do you feel attached to things?

+ +

STEPH: It's always a mix. I'm definitely attached to the team, and then there are always lots of things that I'd still love to work on with that team. But then, I am also excited to start something new. That's why I love this role of consulting because then I get to hop around and see new projects and challenges and work with new people. I'm thinking seven to eight months might be a sweet spot for me in terms of the length of a project. Because I find that first month with a project, I'm really still ramping up, I'm getting comfortable, I'm getting in the groove, and I'm contributing within a short amount of time. But I still feel like that first month; I’m getting really comfortable with this new environment that I'm in. And so then I have that first month.

+ +

And then, at six months, I have more of heads-down time. And I get to really focus and work with a team. And then there's that transition period, and it's nice to know when that's coming up for several weeks, so then I have a couple of weeks to then start working on that transition phase. So eight months might be perfect because then it's like a month for onboarding, ramping up, getting comfortable. And then six months of focus, and then another month of just focusing on what needs to be transitioned so then I can transition off the team.

+ +

CHRIS: All right. Well, now we've defined it - eight months is the perfect length of a project.

+ +

STEPH: That's one of the things I like about the Boost team is because we typically have longer engagements. So that was one of the reasons when we were splitting up the teams in thoughtbot that I chose the Boost team because I was like, yeah, I like the six-month-plus project.

+ +

Speaking of that wishlist, there are little things that I've wanted to make improvements on but haven't really had time to do. There's one that's currently on my mind that I figured I'd share with you in case you have thoughts on it. But I am a big proponent of using the RSpec focus filter for when running tests. So that way, I can just prefix a context it block or describe block with F, and then RSpec I can just run all the tests. But RSpec will only run the tests that I've prefixed with that F focus command., and I love it.

+ +

But we are running into some challenges with it because right now, there's nothing that catches that in a pull request. So if you commit that focus filter on some of your tests, and then that gets pushed up, if someone doesn't notice it while reviewing your pull request, then that gets merged into main. And all of the tests are still green, but it's only a subset of the tests that are actually running. And so it's been on my mind that I'd love something that's going to notice that, that's going to catch it, something that is not just us humans doing our best but something that's automated that's going to notice it for us. And I have some thoughts. But I'm curious, have you run into something like this? Do you have a way that you avoid things like that from sneaking into the main branch?

+ +

CHRIS: Interestingly, I have not run into this particular problem with RSpec, and that's because of the way that I run RSpec tests. I almost never use the focus functionality where you actually change the code file to say, instead of it, it is now fit to focus that it.

+ +

I tend to lean into the functionality where RSpec you can pass it the line number just say, file: and then line number. And RSpec will automatically figure out which either spec or context block or entire file. And also, I have Vim stuff that allows me to do that very easily from the file. It's very rare that I would want to run more than one file.

+ +

So basically, with that, I have all of the flexibility I need. And it doesn't require any changes to the file. So that's almost always how I'm working in that mode. I really love that. And it makes me so sad when I go to JavaScript test runners because they don't have that.

+ +

That said, I've definitely felt a very similar thing with ESLint and ESLint yelling at me for having a console.log. And I'm like, ESLint, I'm working here. I got to debug some stuff, so if you could just calm down for a minute. And what I would like is a differentiation between these are checks that should only run in CI but definitely need to run in CI. And so I think an equivalent would be there's probably a RuboCop rule that says disallow fit or disallow any of the focus versions for RSpec. But I only want those to run in CI.

+ +

And this has been a pain point that I felt a bunch of times. And it's never been painful enough that I put in the effort to fix it. But I really dislike particularly that version of I'm in my editor, and I almost always want there to be no warnings within the editor. I love that TypeScript or ESLint, or other things can run within the editor and tell me what's going on. But I want them to be contextually aware. And that's the dream I've yet to get there.

+ +

STEPH: I like the idea of ESLint having a work mode where you're like, back off, I am in work mode right now. [chuckles] I understand that I won't commit this.

+ +

CHRIS: I'm working here. [laughter]

+ +

STEPH: And I like the idea of a RuboCop. So that's where my mind went initially is like, well, maybe there's a custom cop, or maybe there's an existing one, and I just haven't noticed it yet. But so I'm adding a rule that says, hey, if you do see an fcontext, fdescribe, ffit, something like that, please fail. Please let us know, so we don't merge this in. So that's on my wishlist, not my to-don't list. That one is on my to-do list.

+ +

CHRIS: I'm also intrigued, though, because the particular failure mode that you're describing is you take what is an entire spec suite, and instead, you focus down to one context block within a given file. So previously, there were 700 specs that ran, and now there are 12. And that's actually something that I would love for Circle or whatever platform you're running your tests on to be like, hey, just as a note, you had been slowly creeping up and had hit a high watermark of roughly 700 specs. And then today, we're down to 12. So either you did some aggressive grooming, or something's wrong. But a heuristic analysis of like, I know sometimes people delete specs, and that's a thing that's okay but probably not this many. So maybe something went wrong there.

+ +

STEPH: I feel like we're turning CI into this friend at the bar that's like, "Hey, you've had a couple of drinks. I just wanted to check in with you to make sure that you're good." [laughs]

+ +

CHRIS: Yes.

+ +

STEPH: "You've had 100 tests that were running and now only 50. Hey, friend, how are you? What's going on?"

+ +

CHRIS: "This doesn't sound like you. You're normally a little more level-headed." [laughs] And that's the CI that is my friend that keeps me honest. It's like, "Wait, you promised never to overspend anymore, and yet you're overspending." I'm like, "Thank you, CI. You're right; I did say I want the test to pass."

+ +

STEPH: [laughs] I love it. I'll keep you posted if I figure something out; if I either turn CI into that friend, that lets me know when my behavior has changed in a concerning way, and an intervention is needed. Or, more likely, I will see if there's a RuboCop or some other process that I can apply that will check for this, which I imagine will be fast. I mean, we're very mindful about ensuring our test suite doesn't slow down as we're running it. But I'm just thinking about this out loud. If we add that additional cop, I imagine that will be fast. So I don't think that's too much of an overhead to add to our CI process.

+ +

CHRIS: If you've already got RuboCop in there, I'm guessing the incremental cost of one additional cop is very small. But yeah, it is interesting. That general thing of I want CI to go fast; I definitely feel that feel. And we're slowly creeping up on the project I'm working on. I think we're at about somewhere between five to six minutes, but we've gotten there pretty quickly where not that long ago; it was only three minutes.

+ +

We're adding a lot of features specs, and so they are definitely accruing slowdowns in our CI. And they're worth it; I think, because they're so valuable. And they test the whole integration of everything, but it's a thing that I'm very closely watching. And I have a long list of things that I might pursue when I decide it's time for CI to get a haircut, as it were.

+ +

STEPH: I have a very hot tip for a way to speed up your test, and that is to check if any of your tests have a very long sleep in them. That came up recently [chuckles] this week where someone was working in a test and found some relic that had been added a while back that then wasn't caught. And I think it was a sleep 30. And they were like, "Hey, I just sped up our test by 30 seconds." I was like, ooh, we should grep now to see if there's anything else like that. [laughs]

+ +

CHRIS: Oh, I love the sentence we should grep now. [laughter] The correct response to this is to grep immediately. I thought you were going to go with the pro tip of you can just focus down to one context block. And then the specs will run so much faster because you're ignoring most of them, but we don't want to do that. The sleep, though, that's a pro tip. And that does feel like a thing that there could be a cop for, like, never sleep more than...frankly, let's try not to sleep at all but also, add a sleep in our specs. We can sleep in life; it's important, but anyway. [chuckles]

+ +

STEPH: [laughs] That was the second hot tip, and you got it.

+ +

CHRIS: Lots of hot tips. Well, I'm going to put this in the category of good idea, terrible idea. I won't call it a hot tip. It's a thing we're trying. So much as we have tried to build a spec suite that is consistent and deterministic and tells us only the truth, feature specs, even in our best efforts, still end up flaking from time to time. We'll have feature specs that fail, and then eventually, on a subsequent rerun, they will pass. And I am of the mindset that A, we should try and look into those and see if there is a real cause to it. But sometimes, just the machinery of feature specs, there's so much going on there. We've got the additional overhead of we're running it within a JavaScript context. There's just so much there that...let me say what I did, and then we can talk more about the context.

+ +

So there's a gem called RSpec::Retry. It comes from the wonderful folks over at NoRedInk, a well-known Elm shop for anyone out there in the Elm world. But RSpec::Retry does basically what it says in the name. If the spec fails, you can annotate specs. In our case, we've only enabled this for the feature specs. And you can tell it to retry, and you can say, "Retry up to this many times," and et cetera, et cetera. So I have enabled this for our feature specs. And I've only enabled it on CI. That's an important distinction. This does not run locally.

+ +

So if you run a feature spec and it fails locally, that's a good chance for us to intervene and look at whether or not there's some flakiness there. But on CI, I particularly don't want the case where we have a pull request, everything's great, and we merge that pull request, and then the subsequent rebuild, which again, as a note, I would rather that Circle not rebuild it because we've already built that one. But that is another topic that I have talked about in the past, and we'll probably talk about it again in the future.

+ +

But setting that aside, Circle will rebuild on the main branch when we merge in, and sometimes we'll see failures there. And that's where it's most painful. Like, this is now the deploy queue. This is trying to get this out into whatever environment we're deploying to. And it is very sad when that fails. And I have to go in and manually say, hey, rebuild. I know that this works because it just worked in the pull request, and it's the same commit hash. So I know deterministically for reasons that this should work. And then it does work on a rebuild.

+ +

So we introduced RSpec::Retry. We have wrapped it around our feature specs. And so now I believe we have three possible retries. So if it fails once, it'll try it again, and then it'll try it a third time. So far, we've seen each time that it has had to step in; it will pass on the subsequent run. But I don't know; there was some very gentle pushback or concerns; let’s call them when I introduced this pull request from another developer on the team, saying, "I don't know, though, I feel like this is something that we should solve at the root layer. The failures are a symptom of flaky tests, or inconsistency or et cetera, and so I'd rather not do this." And I said, "Yeah, I know. But I'm going to merge it," and then I merged it.

+ +

We had a better conversation about that. I didn't just broadly overrule. But I said, "I get it, but I don't see the obvious place to shore this up. I don't see where we're doing weird inconsistent things in our code. This is just, I think, inherent complexity of feature specs." So I did it, but yeah, good idea, terrible idea. What do you think, Steph? Maybe terrible is too strong of a word. Good idea, mediocre idea.

+ +

STEPH: I like the original branding. I like the good idea, terrible idea. Although you're right, that terrible is a very strong branding. So I am biased right now, so I'm going to lead in answering your question by stating that because our current project has that problem as well where we have these flaky tests. And it's one of those that, yes, we need to look at them. And we have fixed a large number of them, but there are still more of them.

+ +

And it becomes a question of are we actually doing something wrong here that then we need to fix? Or, like you said, is it just the nature of these features-specs? Some of them are going to occasionally fail. What reasonable improvements can we make to address this at the root cause? I'm interested enough that I haven't heard of RSpec::Retry that I want to check it out because when you add that, you annotate a test. When a test fails, does it run the entire build, or will it rerun just that test? Do you happen to know?

+ +

CHRIS: Just the test. So it's configured as in a round block on the feature specs. And so you tell it like, for any feature spec, it's like config.include for feature specs RSpec::Retry or whatever. So it's just going to rerun the one feature spec that failed when and if that happens. So it's very, very precise as well in that sense where when we have a failure merging into the main branch, I have to rebuild the whole thing. So that's five or six minutes plus whatever latency for me to notice it, et cetera, whereas this is two more seconds in our CI runtime. So that's great. But again, the question is, am I hiding? Am I dealing with the symptoms and not the root cause, et cetera?

+ +

STEPH: Is there a report that's provided at the end that does show these are the tests that failed and we had to rerun them?

+ +

CHRIS: I believe no-ish. You can configure it to output, but it's just going to be outputting to standard out, I believe. So along with the sea of green dots, you'll see had to retry this one. So it is visible, but it's not aggregated. And the particular thing is there's the JUnit reporter that we're using. So the XML common format for this is how long our tests took to run, and these ones passed and failed.

+ +

So Circle, as a particular example, has platform-level insights for that kind of stuff. And they can tell you these are your tests that fail most commonly. These are the tests that take the longest run, et cetera. I would love to get it integrated into that such that retried and then surface this to Circle. Circle could then surface it to us. But right now, I don't believe that's happening. So it is truly I will not see it unless I actively go search for it. To be truly honest, I'm probably not doing that.

+ +

STEPH: Yeah, that's a good, fair, honest answer. You mentioned earlier that if you want a test to retry, you have to annotate the test. Does that mean that you get to highlight specific tests that you're marking those to say, "Hey, I know that these are flaky. I'm okay with that. Please retry them." Or does it apply to all of them?

+ +

CHRIS: I think there are different ways that you can configure it. You could go the granular route of we know this is a flaky spec, so we're going to only put the retry logic around it. And that would be a normal RSpec annotation sort of tagging the spec, I think, is the terminology there. But we've configured it globally for all feature specs. So in a spec support file, we just say config.include Rspec::Retry where type is a feature. And so every feature spec now has the possibility to retry. If they pass on the first pass, which is the hope most of the time, then they will not be tried. But if they don't, if they fail, then they'll be retried up to three times or up to two additional times, I think is the total.

+ +

STEPH: Okay, cool. That's helpful. So then I think I have my answer. I really think it's a good idea to automate retrying tests that we have identified that are flaky. We've tried to address the root, and our resolution was this is fine. This happens sometimes. We don't have a great way to improve this, and we want to keep the test. So we're going to highlight that this test we want to retry. And then I'm going to say it’s not a great idea to turn it on for all of them just because then I have that same fear about you're now hiding any flaky tests that get introduced into the system. And nobody reasonably is going to go and read through to see which tests are going to get retried, so that part makes me nervous.

+ +

CHRIS: I like it. I think it's a balanced and reasonable set of good and terrible idea. Ooh, it's perfect. I don't think we've had a balanced answer on that yet.

+ +

STEPH: I don't think so.

+ +

CHRIS: This is a new outcome for this segment. I agree. Ideally, in my mind, it would be getting into that XML format, the output from the tests, so that we now have this artifact, we can see which ones are flaky and eventually apply effort there. What you're saying feels totally right of we should be more particular and granular. But at the same time, the failure mode and the thing that I'm trying, I want to keep deploys going. And I only want to stop deploys if something's really broken.

+ +

And if a spec retries, then I'm fine with it is where I've landed, particularly because we haven't had any real solutions where there was anything weird in our code. Like, there's just flakiness sometimes. As I say it, I feel like I'm just giving up. [laughs] And I can hear this tone of stuff's just hard sometimes, and so I've taken the easy way out. And I guess that's where I'm at right now. But I think what you're saying is a good, balanced answer here. I like it. I don't know if I'm going to do anything about it, but...[laughter]

+ +

STEPH: Well, going back to when I was saying that I'm biased, our team is feeling this pain because we have flaky tests. And we're creating tickets, and we're trying to do all the right things. We create a ticket. We have that. So it's public. So people know it's been acknowledged. If someone's working on it, we let the team know; hey, I'm working on this. So we're not duplicating efforts. And so, we are trying to address all of them. But then some of them don't feel like a great investment of our time trying to improve.

+ +

So that's what I really do like about the RSpec::Retry is then you can still have a resolution. Because it's either right now your resolution is to fix it or to change the code, so then maybe you can test it in a different way. There's not really a good medium step there. And so the retry feels like an additional good outcome to add to your tool bag to say, hey, I've triaged this, and this feels reasonable that we want to retry this.

+ +

But then there's also that concern of we don't want to hide all of these flaky tests from ourselves in case we have done it and there is an opportunity for us to improve it. So I think that's what I do really like about it because right now, for us, when a test fails, we have to rerun the entire build, and that's painful. So if tests are taking about 20 minutes right now, then one spec fails, and then you have to wait another 20 minutes.

+ +

CHRIS: I would have turned this on years ago with a 20-minute build time. [chuckles]

+ +

STEPH: [laughs] Yeah, you're not wrong. But also, I didn't actually know about RSpec::Retry until today. So that may be something that we introduce into our application or something that I bring up to the team to see if it's something that we want to add. But it is interesting that initial sort of ooh kind of feeling that the team will give you introducing because it feels bad. It feels wrong to be like, hey, we're just going to let these flaky tests live on, and we're going to automate retrying them to at least speed us up. And it's just a very interesting conversation around where we want to invest our time and between the risk and pay off.

+ +

And I had a similar experience this week where I had that conversation, but this one was more with myself where I was working through a particular issue where we have a state in the application where something weird was done in the past that led us to a weird state. And so someone raised a very good question where it's like, well, if what you're saying is technically an impossible state, we should make it impossible, like at the database layer. And I love that phrase. And yet, there was a part of me that was like, yes, but also doing that is not a trivial investment. And we're here because of a very weird thing that happened before.

+ +

It felt one of those interesting, like, do we want to pursue the more aggressive, like, let's make this impossible for the future? Or do we want to address it for now and see if it comes back up, and then we can invest more time in it? And I had a hard time walking myself through that because my initial response was, well, yeah, totally, we should make it impossible. But then I walked through all the steps that it would take to make that happen, and it was not very trivial.

+ +

And so it was one of those; it felt like the change that we ended up with was still an improvement. It was going to prevent users from seeing an error. It was still going to communicate that this state is an odd state for the application to be in. But it didn't go as far as to then add in all of the safety measures. And I felt good about it. But I had to convince myself to feel good about it.

+ +

CHRIS: What you're describing there, the whole thought sequence, really feels like the encapsulation of it depends. And that being part of the journey of learning how to do software development and what it means. And you actually shared a wonderful video with me yesterday, and it was Cassidy Williams at GitHub Universe. And it was her talking to her younger self, and just it depends, and it was so true. So we will include a link to that in the show note because that was a wonderful thing for you to share. And it really does encapsulate this thing. And from the outside, before I started doing software development, I'm like, it's cool. I'm going to learn how to sling code and fix the stuff and hack, and it'll be great, and obvious, and correct, and knowable. And now I'm like, oh man, squishy nonsense. That's all it is.

+ +

STEPH: [laughs]

+ +

CHRIS: Fun squishy, and I like it. It's so good. But it depends. Exactly that one where you're like, I know that there's a way to get to correctness here but is it worth the effort? And looping back to...I'm surprised at the stance that I've taken where I'm just like, yeah, I'm putting in RSpec::Retry. This feels like the right thing. I feel good about this decision. And so I've tried to poke at it a tiny bit.

+ +

And I think what matters to me deeply in a list of priorities is number one correctness. I care deeply that our system behaves correctly as intended and that we are able to verify that. I want to know if the system is not behaving correctly. And that's what we've talked about, like, if the test suite is green, I want to be able to deploy. I want to feel confident in that.

+ +

Flaky specs exist in this interesting space where if there is a real underlying issue, if we've architected our system in a way that causes this flakiness and that a user may ever experience that, then that is a broken system. That is an incorrect system, and I want to resolve that. But that's not the case with what we're experiencing. We're happy with the architecture of our system. And when we're resolving it, we're not even really resolving them. We're just rerunning manually at this point. We're just like, oh, that spec flaked. And there's nothing to do here because sometimes that just happens. So we're re-running manually. And so my belief is if I see all green, if the specs all pass, I know that I can deploy to production.

+ +

And so if occasionally a spec is going to flake and retrying it will make it pass (and I know that pass doesn't mean oh, this time it happened to pass; it's that is the correct outcome) and we have a false negative before, then I'm happy to instrument the system in a way that hides that from me because, at this point, it does feel like noise. I'm not doing anything else with the failures when we were looking at them more pointedly. I'm not resolving those flaky specs. There are no changes that we've made to the underlying system. And they don't represent a failure mode or an incorrectness that an end-user might see. So I honestly want to paper over and hide it from myself. And that's why I've chosen this. But you can see I need to defend my actions here because I feel weird. I feel a little off about this. But as I talk through it, that is the hierarchy. I care about correctness.

+ +

And then, the next thing I care about is maintaining the deployment pipeline. I want that to be as quick and as efficient as possible. And I've talked a bunch about explorations into the world of observability and trying to figure out how to do continuous deployment because I think that really encourages overall better engineering outcomes. And so first is correctness. Second is velocity. And flaky specs impact velocity heavily, but they don't actually impact correctness in the particular mode that we're experiencing them here. They definitely can. But in this case, as I look at the code, I'm like, nah, that was just noise in the system. That was just too much complexity stacked up in trying to run a feature spec that simulates a browser and a user clicking in JavaScript and all this stuff and the things. But again, [laughs] here I am. I am very defensive about this apparently.

+ +

STEPH: Well, I can certainly relate because I was defending my answer to myself earlier. And it is really interesting what you're pointing out. I like how you appreciate correctness and then velocity, that those are the two things that you're going after. And flaky tests often don't highlight an incorrect system. It is highlighting that maybe our code or our tests are not as performant as we would like them to be, but the behavior is correct. So I think that's a really important thing to recognize.

+ +

The part where I get squishy is where we have encountered on this project some flaky tests that did highlight that we had incorrect behavior, and there's only been maybe one or two. It was rare that it happened, but it at least has happened once or twice where it highlighted something to us that when tests were run...I think there's a whole lot of context. I won't get into it. But essentially, when tests were being run in a particular way that made them look like a flaky test, it was actually telling us something truthful about the system, that something was behaving in a way that we didn't want it to behave. So that's why I still like that triage that you have to go through.

+ +

But I also agree that if you're trying to get out at a deploy, you don't want to have to deal with flaky tests. There's a time to eat your vegetables, and I don't know if it's when you've got a deploy that needs to go out. That might not be the right time to be like, oh, we've got a flaky test. We should really address this. It's like, yes; you should note to yourself, hey, have a couple of vegetables tomorrow, make a ticket, and address that flaky test but not right now. That's not the time. So I think you've struck a good balance. But I also do like the idea of annotating specific tests instead of just retrying all of them, so you don't hide anything from yourself.

+ +

CHRIS: Yeah. And now that I'm saying it and now that I'm circling back around, what I'm saying is true of everything we've done so far. But it is possible that now this new mode that the system behaves in where it will essentially hide flaky specs on CI means that any new flaky regressions, as it were, will be hidden from us.

+ +

And thus far, almost all or I think all of the flakiness that we've seen has basically been related to timeouts. So a different way to solve this would potentially be to up the Capybara wait time. So there are occasionally times where the system's churning through, and the various layers of the feature specs just take a little bit longer. And so they miss...I forget what it is, but it's like two seconds right now or something like that. And I can just bump that up and say it's 10 seconds. And that's a mode that if eventually, the system ends in the state that we want, I'm happy to wait a little longer to see that, and that's fine.

+ +

But there are...to name some of the ways that flaky tests can actually highlight truly incorrect things; race conditions are a pretty common one where this behaves fine most of the time. But if the background job happens to succeed before the subsequent request happens, then you'll go to the page. That's a thing that a real user may experience, and in fact, it might even be more likely in production because production has differential performance characteristics on your background jobs versus your actual application. And so that's the sort of thing that would definitely be worth keeping in mind.

+ +

Additionally, if there are order issues within your spec suite if the randomize...I think actually RSpec::Retry wouldn't fix this, though, because it's going to retry within the same order. So that's a case that I think would be still highlighted. It would fail three times and then move on. But those we should definitely deal with. That's a test-related thing. But the first one, race conditions, that's totally a thing. They come up all the time. And I think I've potentially hidden that from myself now. And so, I might need to lock back what I said earlier because I feel like it's been true thus far that that has not been the failure mode, but it could be moving forward. And so I really want to find out if we got flaky specs. I don't know; I feel like I've said enough about this. So I'm going to stop saying anything new. [laughs] Do you have any other thoughts on this topic?

+ +

STEPH: Our emotions are a pendulum. We swing hard one way, and then we have to wait till we come back and settle in the middle. But there's that initial passion play where you're really frustrated by something, and then you swing, and you settle back towards something that's a little more neutral.

+ +

CHRIS: I don't trust anyone who pretends like their opinions never change. It doesn't feel like a good way to be.

+ +

STEPH: Oh, I hope that...Do people say that? I hope that's not true. I hope we are all changing our opinions as we get more information.

+ +

CHRIS: Me too.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: Well, shifting only ever so slightly because it turns out it's a very related question, but we have a listener question. As always, thank you so much to everyone who sends in listener questions. We really appreciate them. And today's question comes from Mikhail, and he writes in, "Regarding the discussion in Episode 311 on requiring commits merged to be tested, I have a question on how you view multi commit PRs. Do you think all the commits in a PR should be tested or only the last one? If you test all commits in a PR, do you have any good tips on setups for that? Would you want all commits to pass all tests? For one, it helps a lot when using Git bisect. It is also a question of keeping the history clean and understandable.

+ +

As a background on the project I currently work on, we have the opinion that all commits should be tested and working. We have now decided on single commit PRs only since this is the only way that we can currently get the setup reasonably on our CI. I would like to sometimes make PRs with more than one commit since I want to make commits as small as possible. In order to do that, we would have to find a way to make sure all commits in the PR are tested. There seems to be some hacky ways to accomplish this, but there is not much talk about it. Also, we are strict in requiring a linear history in all our projects. Kind regards, Mikhail." So, Steph, what do you think?

+ +

STEPH: I remember reading this question when it came in. And I have an experience this week that is relevant to this mainly because I had seen this question, and I was thinking about it. And off the cuff, I haven't really thought about this. I haven't been very concerned about ensuring every single commit passes because I want to ensure that, ultimately, the final commit that I have is going in.

+ +

But I also rarely have more than one commit in a PR. So that's often my default mode. There are a couple of times that I'll have two, maybe three commits, but I think that's pretty rare for me. I'll typically have just one commit. So I haven't thought about this heavily. And it's not something that frankly I've been concerned about or that I've run into issues with.

+ +

From their perspective about using Git bisect, I could see how that could be troublesome, like if you're looking at a commit and you realize there's a particular commit that's already merged and that fails. The other area that I could think of where this could be problematic is if you're trying to roll back to a specific commit. And if you accidentally roll back to a commit that is technically broken, but you didn't know that because it was not the final commit as was getting tested on CI, that could happen. I haven't seen that happen. I haven't experienced it. So while that does seem like a legitimate concern, it's also one that I frankly just haven't had.

+ +

But because I read this question from this person earlier this week, I actually thought about it when I was crafting a PR that had several commits in it, which is kind of unusual for me since I'm usually one or two commits in a PR. But for this one, I had several because we use standard RB in our project to handle all the formatting. And right now, we have one of those standard to-do files because we added it to the project. But there are still a number of manual fixes that need to be applied.

+ +

So we just have this list of files that still need to be formatted. And as someone touches that file, we will format it, and then we'll take it out of that to-do list. So then standard RB will include it as it's linting all of our files. And I decided to do that for all of our spec files. Because I was like, well, this was the safest chunk of files to format that will require the least amount of review from folks. So I just want to address all of them in one go. But I separated the more interesting changes into different commits just to make others aware of, like, hey, this is something standard RB wants.

+ +

And it was interesting enough that I thought I would point it out. So my first commit removed all the files from that to-do list, but then my other commits are the ones that made actual changes to some of those files that needed to be corrected. So technically, one or two of my middle commits didn't pass the standard RB linting. But because CI was only running that final commit, it didn't notice that.

+ +

And I thought about this question, and so I intentionally went back and made sure each of those commits were correct at that point in time. And I feel good about that. But I still don't feel the need to add more process around ensuring each commit is going to be green. I think I would lean more in favor of let's keep our PR small to one or two commits. But I don't know; it’s something I haven't really run into. It's an interesting question. How about you? What are your experiences, or what are your thoughts on this, Chris?

+ +

CHRIS: When this question came through, I thought it was such an interesting example of considering the cost of process changes. And to once again reference one of our favorite blog posts by German Velasco, the Say No to More Process post, which we will, of course, link in the show notes. This is such a great example of there was likely a small amount of pain that was felt at one point where someone tried to run git bisect. They ran into a troublesome commit, and they were like, oh no, this happened. We need to add processes, add automation, add control to make sure this never happens again.

+ +

Personally, I run git bisect very rarely. When I do, it's always a heroic moment just to get it started and to even know which is the good and which is the bad. It's always a thing anyway. So it would be sad if I ran into one of these commits. But I think this is a pretty rare outcome. I think in the particular case that you're talking about, there's probably a way to actually tease that apart. I think it sounds like you fixed those commits knowing this, maybe because you just put it in your head. But the idea that the process that this team is working on has been changed such that they only now allow single commit PRs feels like too much process in my mind. I think I'm probably 80%, maybe 90% of the time; it’s only a single commit in a PR for me.

+ +

But occasionally, I really value having the ability to break it out into discrete steps, like these are all logically grouped in one changeset that I want to send through. But they're discrete steps that I want to break apart so that the team can more easily review it so that we have granular separation, and I can highlight this as a reference. That's often something that I'll do is I want this commit to standalone because I want it to be referenced later on. I don't want to just fold it into the broader context in which it happened, but it's pretty rare. And so to say that we can't do that feels like we're adding process where it may not be worth it, where the cost of that process change is too high relative to the value that we're getting, which is speculatively being able to run git bisect and not hit something problematic in the future.

+ +

There's also the more purist, dogmatic view of well, all commits should be passing, of course. Yeah, I totally agree with that. But what's it worth to you? How much are you willing to spend to achieve that goal? I care deeply about the correctness of my system but only the current correctness. I don't care about historical correctness as much, some. I think I'm diminishing this more than I mean to. But really back to that core question of yes, this thing has value, but is it worth the cost that we have to pay in terms of process, in terms of automation and maintenance of that automation over time, et cetera or whatever the outcome is? Is it worth that cost? And in this case, for me, this would not be worth the cost. And I would not want to adopt a workflow that says we can only ever have single commit PRs, or all commits must be run on CI or any of those variants.

+ +

STEPH: This is an interesting situation where I very much agree with everything you're saying. But I actually feel like what Mikhail wants in this world; I want it too. I think it's correct in the way that I do want all the commits to pass, and I do want to know that. And I think since I do fall into the default, like you mentioned, 80%, 90% of my PRs are one commit. I just already have that. And the fact that they're enforcing that with their team is interesting. And I'm trying to think through why that feels cumbersome to enforce that.

+ +

And I'm with you where I'll maybe have a refactor commit or something that goes before. And it's like, well, what's wrong with splitting that out into a separate PR? What's the pain point of that? And I think the pain point is the fact that one, you have two PRs that are stacked on each other. So you have the first one that you need to get reviewed, and then the second one; there’s that bit of having to hop between the two if there's some shared context that someone can't just easily review in one pull request.

+ +

But then there's also, as we just mentioned, there's CI that has to run. And so now it's running on both of them, even though maybe that's a good thing because it's running on both commits. I like the idea that every commit is tested, and every commit is green. But I actually feel like it's some of our other processes that make it cumbersome and hard to get there. And if CI did run on every commit, I think it would be ideal, but then we are increasing our CI time by running it on every commit.

+ +

And then it comes down to essentially what you said, what's the risk? So if we do merge in a commit that doesn't work or has something that's failing about it but then the next commit after that fixes it, what's the risk that we're going to roll back to that one specific commit that was broken? If that's a high risk for you and your team, then adding this process is probably the really wise thing to do because you want to make sure the app doesn't go down for users. That's incredibly important. If that's not a high risk for your team, then I wouldn't add the process.

+ +

CHRIS: Yeah, I totally agree. And to clarify my stances, for me, this change, this process change would not be worth the trade-off. I love the idea. I love the goal of it. But it is not worth the process change, and that's partly because I haven't particularly felt the pain. CI is not an inexhaustible resource I have learned. I'm actually somewhat proud our very small team that is working on the project that we're working on; we just recently ran out of our CI budget, and Circle was like, "Hey, we got to charge you more." And I was like, "Cool, do that." But it was like, there is cost both in terms of the time, clock time, and each PR running and all of those. We have to consider all of these different things.

+ +

And hopefully, we did a useful job of framing the conversation, because as always, it depends, but it depends on what. And in this case, there's a good outcome that we want to get to, but there's an associated cost. And for any individual team, how you weigh the positive of the outcome versus how you weigh the cost will alter the decision that you make. But that's I think, critically, the thing that we have to consider.

+ +

I've also noticed I've seen this conversation play out within teams where one individual may acutely feel the pain, and therefore they're anchored in that side. And the cost is irrelevant to them because they're like, I feel this pain so acutely, but other people on the team aren't working in that part of the codebase or aren't dealing with bug triage in the same way that that other developer is. And so, even within a team, there may be different levels of how you measure that. And being able to have meaningful conversations around that and productively come to a group decision and own that and move forward with that is the hard work but the important work that we have to do.

+ +

STEPH: Yeah. I think that's a great summary; it depends. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +

Transcript:

+ +

CHRIS: My new computer is due on the fourth. I'm so close.

+ +

STEPH: On the fourth?

+ +

CHRIS: On the fourth.

+ +

STEPH: That's so exciting.

+ +

CHRIS: And I'm very excited. But no, I don't want to upgrade any software on this computer anymore. Never again shall I update a piece of software on this computer.

+ +

STEPH: [laughs]

+ +

CHRIS: This is its final state. And then I will take its soul and move it into the new computer, and we'll go from there. [chuckles]

+ +

STEPH: Take its soul. [laughs]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we learn along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. Let's see. It's been kind of a busy week. It's been a busy family week. Utah, my dog, hasn't been feeling well as you know because you and I have chatted off-mic about that a bit. So he is still recovering from something, I don't know what. He's still on most days his normal captain chaos self, but then other days, he's not feeling well. So I'm just keeping a close eye on him. And then I also got some other family illnesses going on. So it has been a busy family week for sure.

+ +

On the more technical project side, I am wrapping up my current project. So I have one more week, and then I will shift into a new project, which I'm very excited about. And you and I have chatted about this several times. So there's always just that interesting phase where you're trying to wrap up and hand things off and then accomplish last-minute wishlist items for a project before then you start with a new one. So I am currently in that phase.

+ +

CHRIS: How long were you on this project for?

+ +

STEPH: It'll be a total of I think eight months.

+ +

CHRIS: Eight months, that's healthy. That's a bunch. It's always interesting to be on a project for that long but then not longer. There were plenty of three and four-month projects that I did. And you can definitely get a large body of work done. You can look back at it and proudly stare at the code that you have written. But that length of time is always interesting to me because you end up really...for me, when I've had projects that went that long but then not longer, I always found that to be an interesting breaking point. How are you feeling moving on from it? Are you ready for something new? Are you sad to be moving on? Do you feel attached to things?

+ +

STEPH: It's always a mix. I'm definitely attached to the team, and then there are always lots of things that I'd still love to work on with that team. But then, I am also excited to start something new. That's why I love this role of consulting because then I get to hop around and see new projects and challenges and work with new people. I'm thinking seven to eight months might be a sweet spot for me in terms of the length of a project. Because I find that first month with a project, I'm really still ramping up, I'm getting comfortable, I'm getting in the groove, and I'm contributing within a short amount of time. But I still feel like that first month; I’m getting really comfortable with this new environment that I'm in. And so then I have that first month.

+ +

And then, at six months, I have more of heads-down time. And I get to really focus and work with a team. And then there's that transition period, and it's nice to know when that's coming up for several weeks, so then I have a couple of weeks to then start working on that transition phase. So eight months might be perfect because then it's like a month for onboarding, ramping up, getting comfortable. And then six months of focus, and then another month of just focusing on what needs to be transitioned so then I can transition off the team.

+ +

CHRIS: All right. Well, now we've defined it - eight months is the perfect length of a project.

+ +

STEPH: That's one of the things I like about the Boost team is because we typically have longer engagements. So that was one of the reasons when we were splitting up the teams in thoughtbot that I chose the Boost team because I was like, yeah, I like the six-month-plus project.

+ +

Speaking of that wishlist, there are little things that I've wanted to make improvements on but haven't really had time to do. There's one that's currently on my mind that I figured I'd share with you in case you have thoughts on it. But I am a big proponent of using the RSpec focus filter for when running tests. So that way, I can just prefix a context it block or describe block with F, and then RSpec I can just run all the tests. But RSpec will only run the tests that I've prefixed with that F focus command., and I love it.

+ +

But we are running into some challenges with it because right now, there's nothing that catches that in a pull request. So if you commit that focus filter on some of your tests, and then that gets pushed up, if someone doesn't notice it while reviewing your pull request, then that gets merged into main. And all of the tests are still green, but it's only a subset of the tests that are actually running. And so it's been on my mind that I'd love something that's going to notice that, that's going to catch it, something that is not just us humans doing our best but something that's automated that's going to notice it for us. And I have some thoughts. But I'm curious, have you run into something like this? Do you have a way that you avoid things like that from sneaking into the main branch?

+ +

CHRIS: Interestingly, I have not run into this particular problem with RSpec, and that's because of the way that I run RSpec tests. I almost never use the focus functionality where you actually change the code file to say, instead of it, it is now fit to focus that it.

+ +

I tend to lean into the functionality where RSpec you can pass it the line number just say, file: and then line number. And RSpec will automatically figure out which either spec or context block or entire file. And also, I have Vim stuff that allows me to do that very easily from the file. It's very rare that I would want to run more than one file.

+ +

So basically, with that, I have all of the flexibility I need. And it doesn't require any changes to the file. So that's almost always how I'm working in that mode. I really love that. And it makes me so sad when I go to JavaScript test runners because they don't have that.

+ +

That said, I've definitely felt a very similar thing with ESLint and ESLint yelling at me for having a console.log. And I'm like, ESLint, I'm working here. I got to debug some stuff, so if you could just calm down for a minute. And what I would like is a differentiation between these are checks that should only run in CI but definitely need to run in CI. And so I think an equivalent would be there's probably a RuboCop rule that says disallow fit or disallow any of the focus versions for RSpec. But I only want those to run in CI.

+ +

And this has been a pain point that I felt a bunch of times. And it's never been painful enough that I put in the effort to fix it. But I really dislike particularly that version of I'm in my editor, and I almost always want there to be no warnings within the editor. I love that TypeScript or ESLint, or other things can run within the editor and tell me what's going on. But I want them to be contextually aware. And that's the dream I've yet to get there.

+ +

STEPH: I like the idea of ESLint having a work mode where you're like, back off, I am in work mode right now. [chuckles] I understand that I won't commit this.

+ +

CHRIS: I'm working here. [laughter]

+ +

STEPH: And I like the idea of a RuboCop. So that's where my mind went initially is like, well, maybe there's a custom cop, or maybe there's an existing one, and I just haven't noticed it yet. But so I'm adding a rule that says, hey, if you do see an fcontext, fdescribe, ffit, something like that, please fail. Please let us know, so we don't merge this in. So that's on my wishlist, not my to-don't list. That one is on my to-do list.

+ +

CHRIS: I'm also intrigued, though, because the particular failure mode that you're describing is you take what is an entire spec suite, and instead, you focus down to one context block within a given file. So previously, there were 700 specs that ran, and now there are 12. And that's actually something that I would love for Circle or whatever platform you're running your tests on to be like, hey, just as a note, you had been slowly creeping up and had hit a high watermark of roughly 700 specs. And then today, we're down to 12. So either you did some aggressive grooming, or something's wrong. But a heuristic analysis of like, I know sometimes people delete specs, and that's a thing that's okay but probably not this many. So maybe something went wrong there.

+ +

STEPH: I feel like we're turning CI into this friend at the bar that's like, "Hey, you've had a couple of drinks. I just wanted to check in with you to make sure that you're good." [laughs]

+ +

CHRIS: Yes.

+ +

STEPH: "You've had 100 tests that were running and now only 50. Hey, friend, how are you? What's going on?"

+ +

CHRIS: "This doesn't sound like you. You're normally a little more level-headed." [laughs] And that's the CI that is my friend that keeps me honest. It's like, "Wait, you promised never to overspend anymore, and yet you're overspending." I'm like, "Thank you, CI. You're right; I did say I want the test to pass."

+ +

STEPH: [laughs] I love it. I'll keep you posted if I figure something out; if I either turn CI into that friend, that lets me know when my behavior has changed in a concerning way, and an intervention is needed. Or, more likely, I will see if there's a RuboCop or some other process that I can apply that will check for this, which I imagine will be fast. I mean, we're very mindful about ensuring our test suite doesn't slow down as we're running it. But I'm just thinking about this out loud. If we add that additional cop, I imagine that will be fast. So I don't think that's too much of an overhead to add to our CI process.

+ +

CHRIS: If you've already got RuboCop in there, I'm guessing the incremental cost of one additional cop is very small. But yeah, it is interesting. That general thing of I want CI to go fast; I definitely feel that feel. And we're slowly creeping up on the project I'm working on. I think we're at about somewhere between five to six minutes, but we've gotten there pretty quickly where not that long ago; it was only three minutes.

+ +

We're adding a lot of features specs, and so they are definitely accruing slowdowns in our CI. And they're worth it; I think, because they're so valuable. And they test the whole integration of everything, but it's a thing that I'm very closely watching. And I have a long list of things that I might pursue when I decide it's time for CI to get a haircut, as it were.

+ +

STEPH: I have a very hot tip for a way to speed up your test, and that is to check if any of your tests have a very long sleep in them. That came up recently [chuckles] this week where someone was working in a test and found some relic that had been added a while back that then wasn't caught. And I think it was a sleep 30. And they were like, "Hey, I just sped up our test by 30 seconds." I was like, ooh, we should grep now to see if there's anything else like that. [laughs]

+ +

CHRIS: Oh, I love the sentence we should grep now. [laughter] The correct response to this is to grep immediately. I thought you were going to go with the pro tip of you can just focus down to one context block. And then the specs will run so much faster because you're ignoring most of them, but we don't want to do that. The sleep, though, that's a pro tip. And that does feel like a thing that there could be a cop for, like, never sleep more than...frankly, let's try not to sleep at all but also, add a sleep in our specs. We can sleep in life; it's important, but anyway. [chuckles]

+ +

STEPH: [laughs] That was the second hot tip, and you got it.

+ +

CHRIS: Lots of hot tips. Well, I'm going to put this in the category of good idea, terrible idea. I won't call it a hot tip. It's a thing we're trying. So much as we have tried to build a spec suite that is consistent and deterministic and tells us only the truth, feature specs, even in our best efforts, still end up flaking from time to time. We'll have feature specs that fail, and then eventually, on a subsequent rerun, they will pass. And I am of the mindset that A, we should try and look into those and see if there is a real cause to it. But sometimes, just the machinery of feature specs, there's so much going on there. We've got the additional overhead of we're running it within a JavaScript context. There's just so much there that...let me say what I did, and then we can talk more about the context.

+ +

So there's a gem called RSpec::Retry. It comes from the wonderful folks over at NoRedInk, a well-known Elm shop for anyone out there in the Elm world. But RSpec::Retry does basically what it says in the name. If the spec fails, you can annotate specs. In our case, we've only enabled this for the feature specs. And you can tell it to retry, and you can say, "Retry up to this many times," and et cetera, et cetera. So I have enabled this for our feature specs. And I've only enabled it on CI. That's an important distinction. This does not run locally.

+ +

So if you run a feature spec and it fails locally, that's a good chance for us to intervene and look at whether or not there's some flakiness there. But on CI, I particularly don't want the case where we have a pull request, everything's great, and we merge that pull request, and then the subsequent rebuild, which again, as a note, I would rather that Circle not rebuild it because we've already built that one. But that is another topic that I have talked about in the past, and we'll probably talk about it again in the future.

+ +

But setting that aside, Circle will rebuild on the main branch when we merge in, and sometimes we'll see failures there. And that's where it's most painful. Like, this is now the deploy queue. This is trying to get this out into whatever environment we're deploying to. And it is very sad when that fails. And I have to go in and manually say, hey, rebuild. I know that this works because it just worked in the pull request, and it's the same commit hash. So I know deterministically for reasons that this should work. And then it does work on a rebuild.

+ +

So we introduced RSpec::Retry. We have wrapped it around our feature specs. And so now I believe we have three possible retries. So if it fails once, it'll try it again, and then it'll try it a third time. So far, we've seen each time that it has had to step in; it will pass on the subsequent run. But I don't know; there was some very gentle pushback or concerns; let’s call them when I introduced this pull request from another developer on the team, saying, "I don't know, though, I feel like this is something that we should solve at the root layer. The failures are a symptom of flaky tests, or inconsistency or et cetera, and so I'd rather not do this." And I said, "Yeah, I know. But I'm going to merge it," and then I merged it.

+ +

We had a better conversation about that. I didn't just broadly overrule. But I said, "I get it, but I don't see the obvious place to shore this up. I don't see where we're doing weird inconsistent things in our code. This is just, I think, inherent complexity of feature specs." So I did it, but yeah, good idea, terrible idea. What do you think, Steph? Maybe terrible is too strong of a word. Good idea, mediocre idea.

+ +

STEPH: I like the original branding. I like the good idea, terrible idea. Although you're right, that terrible is a very strong branding. So I am biased right now, so I'm going to lead in answering your question by stating that because our current project has that problem as well where we have these flaky tests. And it's one of those that, yes, we need to look at them. And we have fixed a large number of them, but there are still more of them.

+ +

And it becomes a question of are we actually doing something wrong here that then we need to fix? Or, like you said, is it just the nature of these features-specs? Some of them are going to occasionally fail. What reasonable improvements can we make to address this at the root cause? I'm interested enough that I haven't heard of RSpec::Retry that I want to check it out because when you add that, you annotate a test. When a test fails, does it run the entire build, or will it rerun just that test? Do you happen to know?

+ +

CHRIS: Just the test. So it's configured as in a round block on the feature specs. And so you tell it like, for any feature spec, it's like config.include for feature specs RSpec::Retry or whatever. So it's just going to rerun the one feature spec that failed when and if that happens. So it's very, very precise as well in that sense where when we have a failure merging into the main branch, I have to rebuild the whole thing. So that's five or six minutes plus whatever latency for me to notice it, et cetera, whereas this is two more seconds in our CI runtime. So that's great. But again, the question is, am I hiding? Am I dealing with the symptoms and not the root cause, et cetera?

+ +

STEPH: Is there a report that's provided at the end that does show these are the tests that failed and we had to rerun them?

+ +

CHRIS: I believe no-ish. You can configure it to output, but it's just going to be outputting to standard out, I believe. So along with the sea of green dots, you'll see had to retry this one. So it is visible, but it's not aggregated. And the particular thing is there's the JUnit reporter that we're using. So the XML common format for this is how long our tests took to run, and these ones passed and failed.

+ +

So Circle, as a particular example, has platform-level insights for that kind of stuff. And they can tell you these are your tests that fail most commonly. These are the tests that take the longest run, et cetera. I would love to get it integrated into that such that retried and then surface this to Circle. Circle could then surface it to us. But right now, I don't believe that's happening. So it is truly I will not see it unless I actively go search for it. To be truly honest, I'm probably not doing that.

+ +

STEPH: Yeah, that's a good, fair, honest answer. You mentioned earlier that if you want a test to retry, you have to annotate the test. Does that mean that you get to highlight specific tests that you're marking those to say, "Hey, I know that these are flaky. I'm okay with that. Please retry them." Or does it apply to all of them?

+ +

CHRIS: I think there are different ways that you can configure it. You could go the granular route of we know this is a flaky spec, so we're going to only put the retry logic around it. And that would be a normal RSpec annotation sort of tagging the spec, I think, is the terminology there. But we've configured it globally for all feature specs. So in a spec support file, we just say config.include Rspec::Retry where type is a feature. And so every feature spec now has the possibility to retry. If they pass on the first pass, which is the hope most of the time, then they will not be tried. But if they don't, if they fail, then they'll be retried up to three times or up to two additional times, I think is the total.

+ +

STEPH: Okay, cool. That's helpful. So then I think I have my answer. I really think it's a good idea to automate retrying tests that we have identified that are flaky. We've tried to address the root, and our resolution was this is fine. This happens sometimes. We don't have a great way to improve this, and we want to keep the test. So we're going to highlight that this test we want to retry. And then I'm going to say it’s not a great idea to turn it on for all of them just because then I have that same fear about you're now hiding any flaky tests that get introduced into the system. And nobody reasonably is going to go and read through to see which tests are going to get retried, so that part makes me nervous.

+ +

CHRIS: I like it. I think it's a balanced and reasonable set of good and terrible idea. Ooh, it's perfect. I don't think we've had a balanced answer on that yet.

+ +

STEPH: I don't think so.

+ +

CHRIS: This is a new outcome for this segment. I agree. Ideally, in my mind, it would be getting into that XML format, the output from the tests, so that we now have this artifact, we can see which ones are flaky and eventually apply effort there. What you're saying feels totally right of we should be more particular and granular. But at the same time, the failure mode and the thing that I'm trying, I want to keep deploys going. And I only want to stop deploys if something's really broken.

+ +

And if a spec retries, then I'm fine with it is where I've landed, particularly because we haven't had any real solutions where there was anything weird in our code. Like, there's just flakiness sometimes. As I say it, I feel like I'm just giving up. [laughs] And I can hear this tone of stuff's just hard sometimes, and so I've taken the easy way out. And I guess that's where I'm at right now. But I think what you're saying is a good, balanced answer here. I like it. I don't know if I'm going to do anything about it, but...[laughter]

+ +

STEPH: Well, going back to when I was saying that I'm biased, our team is feeling this pain because we have flaky tests. And we're creating tickets, and we're trying to do all the right things. We create a ticket. We have that. So it's public. So people know it's been acknowledged. If someone's working on it, we let the team know; hey, I'm working on this. So we're not duplicating efforts. And so, we are trying to address all of them. But then some of them don't feel like a great investment of our time trying to improve.

+ +

So that's what I really do like about the RSpec::Retry is then you can still have a resolution. Because it's either right now your resolution is to fix it or to change the code, so then maybe you can test it in a different way. There's not really a good medium step there. And so the retry feels like an additional good outcome to add to your tool bag to say, hey, I've triaged this, and this feels reasonable that we want to retry this.

+ +

But then there's also that concern of we don't want to hide all of these flaky tests from ourselves in case we have done it and there is an opportunity for us to improve it. So I think that's what I do really like about it because right now, for us, when a test fails, we have to rerun the entire build, and that's painful. So if tests are taking about 20 minutes right now, then one spec fails, and then you have to wait another 20 minutes.

+ +

CHRIS: I would have turned this on years ago with a 20-minute build time. [chuckles]

+ +

STEPH: [laughs] Yeah, you're not wrong. But also, I didn't actually know about RSpec::Retry until today. So that may be something that we introduce into our application or something that I bring up to the team to see if it's something that we want to add. But it is interesting that initial sort of ooh kind of feeling that the team will give you introducing because it feels bad. It feels wrong to be like, hey, we're just going to let these flaky tests live on, and we're going to automate retrying them to at least speed us up. And it's just a very interesting conversation around where we want to invest our time and between the risk and pay off.

+ +

And I had a similar experience this week where I had that conversation, but this one was more with myself where I was working through a particular issue where we have a state in the application where something weird was done in the past that led us to a weird state. And so someone raised a very good question where it's like, well, if what you're saying is technically an impossible state, we should make it impossible, like at the database layer. And I love that phrase. And yet, there was a part of me that was like, yes, but also doing that is not a trivial investment. And we're here because of a very weird thing that happened before.

+ +

It felt one of those interesting, like, do we want to pursue the more aggressive, like, let's make this impossible for the future? Or do we want to address it for now and see if it comes back up, and then we can invest more time in it? And I had a hard time walking myself through that because my initial response was, well, yeah, totally, we should make it impossible. But then I walked through all the steps that it would take to make that happen, and it was not very trivial.

+ +

And so it was one of those; it felt like the change that we ended up with was still an improvement. It was going to prevent users from seeing an error. It was still going to communicate that this state is an odd state for the application to be in. But it didn't go as far as to then add in all of the safety measures. And I felt good about it. But I had to convince myself to feel good about it.

+ +

CHRIS: What you're describing there, the whole thought sequence, really feels like the encapsulation of it depends. And that being part of the journey of learning how to do software development and what it means. And you actually shared a wonderful video with me yesterday, and it was Cassidy Williams at GitHub Universe. And it was her talking to her younger self, and just it depends, and it was so true. So we will include a link to that in the show note because that was a wonderful thing for you to share. And it really does encapsulate this thing. And from the outside, before I started doing software development, I'm like, it's cool. I'm going to learn how to sling code and fix the stuff and hack, and it'll be great, and obvious, and correct, and knowable. And now I'm like, oh man, squishy nonsense. That's all it is.

+ +

STEPH: [laughs]

+ +

CHRIS: Fun squishy, and I like it. It's so good. But it depends. Exactly that one where you're like, I know that there's a way to get to correctness here but is it worth the effort? And looping back to...I'm surprised at the stance that I've taken where I'm just like, yeah, I'm putting in RSpec::Retry. This feels like the right thing. I feel good about this decision. And so I've tried to poke at it a tiny bit.

+ +

And I think what matters to me deeply in a list of priorities is number one correctness. I care deeply that our system behaves correctly as intended and that we are able to verify that. I want to know if the system is not behaving correctly. And that's what we've talked about, like, if the test suite is green, I want to be able to deploy. I want to feel confident in that.

+ +

Flaky specs exist in this interesting space where if there is a real underlying issue, if we've architected our system in a way that causes this flakiness and that a user may ever experience that, then that is a broken system. That is an incorrect system, and I want to resolve that. But that's not the case with what we're experiencing. We're happy with the architecture of our system. And when we're resolving it, we're not even really resolving them. We're just rerunning manually at this point. We're just like, oh, that spec flaked. And there's nothing to do here because sometimes that just happens. So we're re-running manually. And so my belief is if I see all green, if the specs all pass, I know that I can deploy to production.

+ +

And so if occasionally a spec is going to flake and retrying it will make it pass (and I know that pass doesn't mean oh, this time it happened to pass; it's that is the correct outcome) and we have a false negative before, then I'm happy to instrument the system in a way that hides that from me because, at this point, it does feel like noise. I'm not doing anything else with the failures when we were looking at them more pointedly. I'm not resolving those flaky specs. There are no changes that we've made to the underlying system. And they don't represent a failure mode or an incorrectness that an end-user might see. So I honestly want to paper over and hide it from myself. And that's why I've chosen this. But you can see I need to defend my actions here because I feel weird. I feel a little off about this. But as I talk through it, that is the hierarchy. I care about correctness.

+ +

And then, the next thing I care about is maintaining the deployment pipeline. I want that to be as quick and as efficient as possible. And I've talked a bunch about explorations into the world of observability and trying to figure out how to do continuous deployment because I think that really encourages overall better engineering outcomes. And so first is correctness. Second is velocity. And flaky specs impact velocity heavily, but they don't actually impact correctness in the particular mode that we're experiencing them here. They definitely can. But in this case, as I look at the code, I'm like, nah, that was just noise in the system. That was just too much complexity stacked up in trying to run a feature spec that simulates a browser and a user clicking in JavaScript and all this stuff and the things. But again, [laughs] here I am. I am very defensive about this apparently.

+ +

STEPH: Well, I can certainly relate because I was defending my answer to myself earlier. And it is really interesting what you're pointing out. I like how you appreciate correctness and then velocity, that those are the two things that you're going after. And flaky tests often don't highlight an incorrect system. It is highlighting that maybe our code or our tests are not as performant as we would like them to be, but the behavior is correct. So I think that's a really important thing to recognize.

+ +

The part where I get squishy is where we have encountered on this project some flaky tests that did highlight that we had incorrect behavior, and there's only been maybe one or two. It was rare that it happened, but it at least has happened once or twice where it highlighted something to us that when tests were run...I think there's a whole lot of context. I won't get into it. But essentially, when tests were being run in a particular way that made them look like a flaky test, it was actually telling us something truthful about the system, that something was behaving in a way that we didn't want it to behave. So that's why I still like that triage that you have to go through.

+ +

But I also agree that if you're trying to get out at a deploy, you don't want to have to deal with flaky tests. There's a time to eat your vegetables, and I don't know if it's when you've got a deploy that needs to go out. That might not be the right time to be like, oh, we've got a flaky test. We should really address this. It's like, yes; you should note to yourself, hey, have a couple of vegetables tomorrow, make a ticket, and address that flaky test but not right now. That's not the time. So I think you've struck a good balance. But I also do like the idea of annotating specific tests instead of just retrying all of them, so you don't hide anything from yourself.

+ +

CHRIS: Yeah. And now that I'm saying it and now that I'm circling back around, what I'm saying is true of everything we've done so far. But it is possible that now this new mode that the system behaves in where it will essentially hide flaky specs on CI means that any new flaky regressions, as it were, will be hidden from us.

+ +

And thus far, almost all or I think all of the flakiness that we've seen has basically been related to timeouts. So a different way to solve this would potentially be to up the Capybara wait time. So there are occasionally times where the system's churning through, and the various layers of the feature specs just take a little bit longer. And so they miss...I forget what it is, but it's like two seconds right now or something like that. And I can just bump that up and say it's 10 seconds. And that's a mode that if eventually, the system ends in the state that we want, I'm happy to wait a little longer to see that, and that's fine.

+ +

But there are...to name some of the ways that flaky tests can actually highlight truly incorrect things; race conditions are a pretty common one where this behaves fine most of the time. But if the background job happens to succeed before the subsequent request happens, then you'll go to the page. That's a thing that a real user may experience, and in fact, it might even be more likely in production because production has differential performance characteristics on your background jobs versus your actual application. And so that's the sort of thing that would definitely be worth keeping in mind.

+ +

Additionally, if there are order issues within your spec suite if the randomize...I think actually RSpec::Retry wouldn't fix this, though, because it's going to retry within the same order. So that's a case that I think would be still highlighted. It would fail three times and then move on. But those we should definitely deal with. That's a test-related thing. But the first one, race conditions, that's totally a thing. They come up all the time. And I think I've potentially hidden that from myself now. And so, I might need to lock back what I said earlier because I feel like it's been true thus far that that has not been the failure mode, but it could be moving forward. And so I really want to find out if we got flaky specs. I don't know; I feel like I've said enough about this. So I'm going to stop saying anything new. [laughs] Do you have any other thoughts on this topic?

+ +

STEPH: Our emotions are a pendulum. We swing hard one way, and then we have to wait till we come back and settle in the middle. But there's that initial passion play where you're really frustrated by something, and then you swing, and you settle back towards something that's a little more neutral.

+ +

CHRIS: I don't trust anyone who pretends like their opinions never change. It doesn't feel like a good way to be.

+ +

STEPH: Oh, I hope that...Do people say that? I hope that's not true. I hope we are all changing our opinions as we get more information.

+ +

CHRIS: Me too.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: Well, shifting only ever so slightly because it turns out it's a very related question, but we have a listener question. As always, thank you so much to everyone who sends in listener questions. We really appreciate them. And today's question comes from Mikhail, and he writes in, "Regarding the discussion in Episode 311 on requiring commits merged to be tested, I have a question on how you view multi commit PRs. Do you think all the commits in a PR should be tested or only the last one? If you test all commits in a PR, do you have any good tips on setups for that? Would you want all commits to pass all tests? For one, it helps a lot when using Git bisect. It is also a question of keeping the history clean and understandable.

+ +

As a background on the project I currently work on, we have the opinion that all commits should be tested and working. We have now decided on single commit PRs only since this is the only way that we can currently get the setup reasonably on our CI. I would like to sometimes make PRs with more than one commit since I want to make commits as small as possible. In order to do that, we would have to find a way to make sure all commits in the PR are tested. There seems to be some hacky ways to accomplish this, but there is not much talk about it. Also, we are strict in requiring a linear history in all our projects. Kind regards, Mikhail." So, Steph, what do you think?

+ +

STEPH: I remember reading this question when it came in. And I have an experience this week that is relevant to this mainly because I had seen this question, and I was thinking about it. And off the cuff, I haven't really thought about this. I haven't been very concerned about ensuring every single commit passes because I want to ensure that, ultimately, the final commit that I have is going in.

+ +

But I also rarely have more than one commit in a PR. So that's often my default mode. There are a couple of times that I'll have two, maybe three commits, but I think that's pretty rare for me. I'll typically have just one commit. So I haven't thought about this heavily. And it's not something that frankly I've been concerned about or that I've run into issues with.

+ +

From their perspective about using Git bisect, I could see how that could be troublesome, like if you're looking at a commit and you realize there's a particular commit that's already merged and that fails. The other area that I could think of where this could be problematic is if you're trying to roll back to a specific commit. And if you accidentally roll back to a commit that is technically broken, but you didn't know that because it was not the final commit as was getting tested on CI, that could happen. I haven't seen that happen. I haven't experienced it. So while that does seem like a legitimate concern, it's also one that I frankly just haven't had.

+ +

But because I read this question from this person earlier this week, I actually thought about it when I was crafting a PR that had several commits in it, which is kind of unusual for me since I'm usually one or two commits in a PR. But for this one, I had several because we use standard RB in our project to handle all the formatting. And right now, we have one of those standard to-do files because we added it to the project. But there are still a number of manual fixes that need to be applied.

+ +

So we just have this list of files that still need to be formatted. And as someone touches that file, we will format it, and then we'll take it out of that to-do list. So then standard RB will include it as it's linting all of our files. And I decided to do that for all of our spec files. Because I was like, well, this was the safest chunk of files to format that will require the least amount of review from folks. So I just want to address all of them in one go. But I separated the more interesting changes into different commits just to make others aware of, like, hey, this is something standard RB wants.

+ +

And it was interesting enough that I thought I would point it out. So my first commit removed all the files from that to-do list, but then my other commits are the ones that made actual changes to some of those files that needed to be corrected. So technically, one or two of my middle commits didn't pass the standard RB linting. But because CI was only running that final commit, it didn't notice that.

+ +

And I thought about this question, and so I intentionally went back and made sure each of those commits were correct at that point in time. And I feel good about that. But I still don't feel the need to add more process around ensuring each commit is going to be green. I think I would lean more in favor of let's keep our PR small to one or two commits. But I don't know; it’s something I haven't really run into. It's an interesting question. How about you? What are your experiences, or what are your thoughts on this, Chris?

+ +

CHRIS: When this question came through, I thought it was such an interesting example of considering the cost of process changes. And to once again reference one of our favorite blog posts by German Velasco, the Say No to More Process post, which we will, of course, link in the show notes. This is such a great example of there was likely a small amount of pain that was felt at one point where someone tried to run git bisect. They ran into a troublesome commit, and they were like, oh no, this happened. We need to add processes, add automation, add control to make sure this never happens again.

+ +

Personally, I run git bisect very rarely. When I do, it's always a heroic moment just to get it started and to even know which is the good and which is the bad. It's always a thing anyway. So it would be sad if I ran into one of these commits. But I think this is a pretty rare outcome. I think in the particular case that you're talking about, there's probably a way to actually tease that apart. I think it sounds like you fixed those commits knowing this, maybe because you just put it in your head. But the idea that the process that this team is working on has been changed such that they only now allow single commit PRs feels like too much process in my mind. I think I'm probably 80%, maybe 90% of the time; it’s only a single commit in a PR for me.

+ +

But occasionally, I really value having the ability to break it out into discrete steps, like these are all logically grouped in one changeset that I want to send through. But they're discrete steps that I want to break apart so that the team can more easily review it so that we have granular separation, and I can highlight this as a reference. That's often something that I'll do is I want this commit to standalone because I want it to be referenced later on. I don't want to just fold it into the broader context in which it happened, but it's pretty rare. And so to say that we can't do that feels like we're adding process where it may not be worth it, where the cost of that process change is too high relative to the value that we're getting, which is speculatively being able to run git bisect and not hit something problematic in the future.

+ +

There's also the more purist, dogmatic view of well, all commits should be passing, of course. Yeah, I totally agree with that. But what's it worth to you? How much are you willing to spend to achieve that goal? I care deeply about the correctness of my system but only the current correctness. I don't care about historical correctness as much, some. I think I'm diminishing this more than I mean to. But really back to that core question of yes, this thing has value, but is it worth the cost that we have to pay in terms of process, in terms of automation and maintenance of that automation over time, et cetera or whatever the outcome is? Is it worth that cost? And in this case, for me, this would not be worth the cost. And I would not want to adopt a workflow that says we can only ever have single commit PRs, or all commits must be run on CI or any of those variants.

+ +

STEPH: This is an interesting situation where I very much agree with everything you're saying. But I actually feel like what Mikhail wants in this world; I want it too. I think it's correct in the way that I do want all the commits to pass, and I do want to know that. And I think since I do fall into the default, like you mentioned, 80%, 90% of my PRs are one commit. I just already have that. And the fact that they're enforcing that with their team is interesting. And I'm trying to think through why that feels cumbersome to enforce that.

+ +

And I'm with you where I'll maybe have a refactor commit or something that goes before. And it's like, well, what's wrong with splitting that out into a separate PR? What's the pain point of that? And I think the pain point is the fact that one, you have two PRs that are stacked on each other. So you have the first one that you need to get reviewed, and then the second one; there’s that bit of having to hop between the two if there's some shared context that someone can't just easily review in one pull request.

+ +

But then there's also, as we just mentioned, there's CI that has to run. And so now it's running on both of them, even though maybe that's a good thing because it's running on both commits. I like the idea that every commit is tested, and every commit is green. But I actually feel like it's some of our other processes that make it cumbersome and hard to get there. And if CI did run on every commit, I think it would be ideal, but then we are increasing our CI time by running it on every commit.

+ +

And then it comes down to essentially what you said, what's the risk? So if we do merge in a commit that doesn't work or has something that's failing about it but then the next commit after that fixes it, what's the risk that we're going to roll back to that one specific commit that was broken? If that's a high risk for you and your team, then adding this process is probably the really wise thing to do because you want to make sure the app doesn't go down for users. That's incredibly important. If that's not a high risk for your team, then I wouldn't add the process.

+ +

CHRIS: Yeah, I totally agree. And to clarify my stances, for me, this change, this process change would not be worth the trade-off. I love the idea. I love the goal of it. But it is not worth the process change, and that's partly because I haven't particularly felt the pain. CI is not an inexhaustible resource I have learned. I'm actually somewhat proud our very small team that is working on the project that we're working on; we just recently ran out of our CI budget, and Circle was like, "Hey, we got to charge you more." And I was like, "Cool, do that." But it was like, there is cost both in terms of the time, clock time, and each PR running and all of those. We have to consider all of these different things.

+ +

And hopefully, we did a useful job of framing the conversation, because as always, it depends, but it depends on what. And in this case, there's a good outcome that we want to get to, but there's an associated cost. And for any individual team, how you weigh the positive of the outcome versus how you weigh the cost will alter the decision that you make. But that's I think, critically, the thing that we have to consider.

+ +

I've also noticed I've seen this conversation play out within teams where one individual may acutely feel the pain, and therefore they're anchored in that side. And the cost is irrelevant to them because they're like, I feel this pain so acutely, but other people on the team aren't working in that part of the codebase or aren't dealing with bug triage in the same way that that other developer is. And so, even within a team, there may be different levels of how you measure that. And being able to have meaningful conversations around that and productively come to a group decision and own that and move forward with that is the hard work but the important work that we have to do.

+ +

STEPH: Yeah. I think that's a great summary; it depends. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+6WgE1Y3h + + ]]> + + Chris Toomey + Steph Viccari + + + 314: Communication, Testing, and Accountability + https://bikeshed.thoughtbot.com/314 + 2fa4b078-cd4e-4b8c-8140-85b79fe1c1d5 + Tue, 26 Oct 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris regains several of his developer merit badges and embarks on a perilous CSRF (Cross-Site Request Forgery) adventure. Steph shares highlights from Plucky, a management training course, including ways we can "click" and "break apart" from our current role, and how to have hard conversations. + +They also discuss how software development processes change at different team sizes, processes that break down as teams grow, and processes that are resilient at any team size. + 40:55 + no + + + Chris regains several of his developer merit badges and embarks on a perilous CSRF (Cross-Site Request Forgery) adventure. Steph shares highlights from Plucky, a management training course, including ways we can "click" and "break apart" from our current role, and how to have hard conversations. +They also discuss how software development processes change at different team sizes, processes that break down as teams grow, and processes that are resilient at any team size. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +The Nightmare Before Christmas - What's This (https://youtu.be/QLvvkTbHjHI) +Giant Robots Smashing into other Giant Robots - Plucky with Jen Dary (https://www.giantrobots.fm/search?utf8=%E2%9C%93&term=plucky) +Plucky (https://www.beplucky.com/) +Services are Not a Silver Bullet (https://thoughtbot.com/blog/services-are-not-a-silver-bullet) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! +Transcript: +STEPH: Boom. I'm recording. Magic is happening. [singing] What's this? What's this? It's a Bike Shed episode. What's this? What's this? +CHRIS: You did that on the mic. [laughter] So you just started recording too, so it's not like you're like, "Oh, I forgot I was recording." +STEPH: Oh, I didn't have a finishing line that rhymes with shed. +CHRIS: Head, dead, bread, spread. +STEPH: [singing] Is TDD dead? I don't know. [laughs] +CHRIS: Cool. I liked it. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? +CHRIS: What's new? I had a fun experience over the past week or two of regaining some of my developer merit badges, which is always enjoyable. So one was I had to configure AWS, specifically S3 and IAM such that I could upload files to an S3 bucket, which seems like one of those things that a developer should be able to do, and it's just not that hard. And, man, I failed so many times, and I stared at the screen. And the ARNs I think that's another acronym that I had to try and figure out what it means and fight against. Anyway, I got there. So that's one merit badge earned. I really hope [laughs] I correctly and securely configured access to an S3 bucket such that we could upload files in our Rails app. Cool, neat. +Moving on, the next merit badge that I went for was restoring the sea of green dots. Our RSpec output had gathered some noise. There was a whole bunch of noise across a variety of things. There were some dev tools that were dumping some stuff in there. And there was something related to apparition, which is the...I want to say it's the Capybara feature spec driver that we're using now, which sits on top of ChromeDriver or something like that. I don't really understand the details, but it was complaining about something. And I found a fix, and then I fixed it and whatnot. But it was one of those. I did this on a Saturday because I was just like, you know what? This will be cathartic and healing. And then I got to the sea of green dots, and I was so happy to get to it. +STEPH: This is me...I'm giving you a round of applause. +CHRIS: Well, thank you. Arguable whether it delivered any real value to users, but again, this was Saturday effort, so I was allowed to indulge my fastidious caretaker of the code role. +STEPH: Sorry, before we move on to more serious, can we pause to talk about developer merit badges? I really, really want cute felt badges that we can...I mean, I can't design them. I don't have the talent. But I think between us and other folks, we could design amazing merit badges, and then people could collect those. I'm very much in love with that idea. +CHRIS: I love the idea. I am now certain that if we were to really pursue this, that we would fall into the deepest of bike sheds as we try and define well; what are all the merit badges? And what are the different levels? +STEPH: [laughs] +CHRIS: And how many do you need to collect before you can get to what are the different...There are just so many different taxonomies that we could introduce, and, oh man, I could spend a couple of weeks on that. +STEPH: [laughs] It has a very strong Pokémon vibe too of you got to catch them all. +CHRIS: Absolutely. +STEPH: Okay. All right. We won't digress into bikeshedding merit badges, but I'm still very, very interested in that idea. +CHRIS: Indeed. If anyone out there in the listener space wants to just make these, that would be great. This is the way that I avoid bikeshedding now is I just say I'm not allowed to make these decisions or even think about it. But if these happened into the world, I would be happy about that. +STEPH: Oh, I just remembered we do have something similar at thoughtbot. They're not physical where you can hold them, but I think we've talked about turning them into physical badges. But we have our internal tool hub that we used to track our schedules. And one of the fun Ralphapalooza events that we had, a team came up with the idea of introducing badges in the tool hub, so then you could award people badges. You could give people badges. And it's very cute. So they could probably help us with the taxonomy. They've probably already figured out a number of badges we could get started with. +CHRIS: And of course, this is where my brain went initially to like, oh, what would the taxonomy be? But I think that's how this goes bad. And if we just keep it in the this is cute and fun, and what are all the possible merit badges, but they're all equal, and the points are made up anyway, and then it's just a fun thing, then I'm like, I'm super into this. Let's do that. Have you used a regular expression to parse HTML? Congratulations, you get a merit badge. Have you not used regular expressions to parse HTML? You get a different merit badge. [chuckles] +STEPH: [laughs] I feel very positive that I could be chief of cute and fun. I could manage that department. +CHRIS: Yes, that feels like definitely a role that you could really excel at. But shifting around ever so slightly, I did run into a fun bug this week. And it was a mystery tour of, I'm going to say, sadness and then eventual learning and understanding, and I think we've come to a better place. But I want to tell a story, take us on a quick tour of the adventure that I went through. +So we recently saw a handful of exceptions come through in our exception monitoring service and then piped into Slack, where we see those around CSRF token expiry. So this occasionally happens in a Rails app. The CSRF token that was on the page gets rotated. And therefore, when someone...if they have an older version of the page open and they try and submit a form or something like that, then CSRF protection is going to kick in. And you do get some false negatives there or some cases where like, nope, this is actually a fine user, this is not hacking, this is nothing bad. It's just that that user had a tab open or something like that. +I'll be honest; I want to understand better the timeline of expiry and how Rails expires those and whatnot. But it's one of those things; it’s deep enough in Rails that I trust that they are doing a very reasonable thing. And I think the failures that we're seeing that's part of the game. And so, mostly, we wanted to add a nicer handling around that. So thankfully, Inertia actually has a really wonderful page in their docs about handling Cross-Site Request Forgery expiration token, this whole thing. This is a particular failure mode that your app might have. And so it's nice to be able to provide a nicer user experience. +And so what we ended up doing is if we catch that exception, we have a rescue_from in our application controller that will instead of having this be a 500 and just a full, like, something went wrong error page, we instead respond in an Inertia-like way to basically show a flash message that says, "This page has expired. Please refresh the page to continue." And if the user just refreshes the page, then they will get a new CSRF token. And from there, everything is going to be fine. So it's not ideal. But it is, I think, both secure and now a nicer user experience. +STEPH: Yeah, that sounds really nice. When they refresh the page, do they lose all that form data? I'm curious how painful of a flow that is for the user. +CHRIS: Currently, yes. Inertia actually has a really nice feature for remembering form data. If you've ever been on GitHub and you're filling in a box, and then you go away to a different tab, and you come back, and it's still there, and you're happy about that, it's that sort of thing. So we could configure that. At this point, we don't have...most of our forms are pretty small. So this is not something that we opted to do proactive management around. But that is definitely something that we could add but not something that's default or anything like that. +STEPH: Cool. Yeah, that makes sense. I was just curious because yeah, either small form doesn't really matter, or also, this may be just a small enough error that only a handful of people are experiencing it that it's also just not that big of a deal. +CHRIS: Yes, this definitely should be an edge case. And we've also recently been working on functionality to log folks out after a period of inactivity, which would also, I think, obviate this in a different way. So all total, this shouldn't be a big deal. And this was basically a quick, little snippet of code that we thought we could just drop in, and everything would be great because it shouldn't happen much. +But then I was testing out a different feature on staging, and everything I tried to do was popping up this little alert flash message that was like, "Hey, your page is expired." And I was like, that seems bad. And then I realized literally every action, any non-GET request, was getting this response that the CSRF token didn't match. And I was like, well, this seems bad. Luckily, it was only on staging and hadn't made it to production. +But it had made it to staging, which meant it had gotten through CI, which was very concerning because we have a pretty robust set of feature specs at this point. We built up a bunch of fakes for all of the external data systems that we're interacting with. And we're really putting the app through its paces and trying to do so in a very production-like way. And so I was like, this is such a deep fundamental breakage. I don't know what's going on here. And so I started to investigate. +And it turns out that in a recent commit, I had started using Axios, which is a little wrapper around the Fetch API. They may not actually use the Fetch API under the hood, but it allows you to have a nicer interface to make XHRs. And we implicitly had that in our package already by virtue of Inertia. Inertia uses it under the hood, but I wanted to make it explicit because now I was using it directly. So I figured that's cool. I will yarn add Axios, and then I will continue on with my day. And I worked on my feature and everything was great. And then I pushed it up into a pull request, and everything was great, and CI passed. And I got it onto staging, and everything was very sad. +So then I started on the adventure of like, what is going on here? It turns out that somewhere between version 0.21.1 of Axios and 0.23.0, which there's a bunch of things about those version numbers that make me uncomfortable but here we are, somehow the behavior where you can configure the XSRF header name, which is what they're calling it on their side, the configuration stopped working. And so our override that says this is what our CSRF or XSRF token should be called when it's sent back up to the server in a header that was getting lost. And so they were falling back to their default name, Axios was. And, therefore, Rails was like, "There's no CSRF token here. So this is going to be a no for me. I'm going to reject all of the requests." +So the fix was relatively easy to roll back and to pin the version of Axios to the previous version that we had been using. I didn't actually intend to upgrade it. I just intended to make it an explicit dependency. But by doing that, I accidentally upgraded it. I don't love that there was this pretty deep breakage in that. I haven't done the good work of trying to open an issue. I still want to scan through and see if there is an open issue or a conversation around this before I start making any noise. But I think if I don't find anything, this is the sort of thing that should be reported because I can't imagine I'm the only one running into this. +Likewise, I was very sad that my test suite did not find this. Turns out in Rails, CSRF protection is just turned off in test mode, which may be overall makes sense. But for feature specs, in particular, I definitely want to have it. And so, it was nice that I was able to find the relevant configuration. And we introduced an RSpec configuration that says, "If it's a feature spec, save off the existing configuration and enable CSRF. And then after the spec, go back to whatever the previous was." +So now all feature specs run with CSRF. And I did make sure to push up that as a singular change to CI, and CI was very unhappy with me. Many, many features-specs failed, which was good. That was what we were going for. They failed for the right reason because things were fundamentally broken. And then, I was able to update the package-lock or the package.json on the yarn lock, pin the version, fix everything. +But man, there was this period of like, oh man, the app is broken in such a fundamental way. Users just can't do stuff anymore. They can view anything, but they couldn't change any data. And it just snuck through CI. And that feeling is the worst feeling. We had, at this point, built up a lot of trust in our test suite. It was really telling us when stuff was wrong, and if it was green, I felt very good merging. And suddenly, this just really shook me to my core on that front. +STEPH: I love these journeys that you take us on. I mean, they're painful for you, and I am sorry to hear that. But I love these journeys that you take us on. [chuckles] +CHRIS: I usually only take us on them when I've figured out the answer. And I'm like, all right, here's where we're at. It was rough for a little while, but now we are happy. And thankfully, the one configuration of saying, hey, Rails, also, please include this as part of our production like, configuration for test mode. So I feel better that moving forward, this breakage won't happen again. +STEPH: We should add that as another merit badge for telling a bug story. All right, I'm taking off my hat of chief of fun and cuteness. So this may not be terribly relevant to all the things that you just shared. But I am curious where you mentioned that with Axios because you'd specified the name of the token, and then that overriding behavior is what then broke. And so then that's what led to this whole adventure that you went on. I'm curious, why did y'all customize the name of that token? +CHRIS: A, this is a great question. B, I'm not super sure. C, I think the reason is because we were trying to align to Rails. So we have a little middleware on the Rails side that will serialize the CSRF token into a cookie. And then that cookie value gets read by Axios and sent back up as a header on the request. So this is the way that with Inertia CSRF just kind of works and is good. And it's different than Rails' normal. We put a hidden input into any form. And so Rails holistically knows about both sides of that, and everything works fine. But now I have to manually round trip the CSRF token. +And Axio's default configuration is a header name X-XSRF-TOKEN, and we needed X-CSRF-TOKEN because that's what Rails is looking for. I probably could have configured it the other way on the Rails side. But one way or another, I had to get Rails and Axios to come to an agreement, to meet at a table, and to agree to collectively protect the app. And so I had to mediate that discussion, and that's what ended us here. +STEPH: A meeting of the minds. [chuckles] Cool, cool, cool. Yeah, that makes sense. I was just curious because then that would have changed the whole journey. But yeah, that is super interesting. And I definitely resonate with the idea of when you've really invested in your test suite, and you trust it that then when it doesn't catch something that obviously breaks the application, then that feels like something worth prioritizing and digging into and then figuring out how to bring back that parity. +I don't know that I've turned on enable CSRF for feature spec. So I'm also very interested in looking at that configuration and considering if I need that for any of my future client projects if that's something that I need to remember for the future because that's very niche but good to know about. +CHRIS: I feel like this only really comes up if you're working in the...it's called the odd middle ground that Inertia ends up occupying. If you're in a traditional Rails app that is generating HTML server-side, forms are generated. They got the CSRF token inlined there in a hidden input. And then when you post that form, it's coming back up. The names automatically are going to match. You don't need to worry about it. And it's probably fine to not have it included in test mode. +And if you're at the other end of the spectrum and you've got API interaction, and that's the way you're doing everything, then you have a different auth mechanism and cookies, and whatnot just don't apply in the same way. And so it won't really matter on that side but for a different reason. And it's only because we're in this interesting middle ground, which, again, I really love. And it's the thing that I love about Inertia. But this is a rare case where it's like, oh, we do have to bring the two sides to meet in the middle. And this is a case where, unfortunately, due to a very subtle breakage on a minor release of...a package that we're using silently broke so, yeah. +But yeah, thankfully, everything is back to working. And again, we've been able to enhance the test suite in that little way that I feel confident again because this won't sneak in another time. We have coverage around this. We're good to go. So while I was very scared when this initially happened, I feel better now. I'm happy to go into the weekend feeling better about this. But that's my story. What's new in your world? +STEPH: So I feel like I've been having one of those weeks where I have less code adventures. In fact, it's one of those days where I went to thoughtbot's daily sync...because we often have our client daily syncs, but then we still have a thoughtbot sync as well. And I went to the group, and I was like, I get to write code today. It's going to be a great day. All the other things I'm doing are also interesting, but I get particularly excited when I get some maker's time and get to write some code. +So I feel like I've had less coding adventures recently and more hiring and process-related adventures. And specifically, I just completed the Plucky Manager Training, which is a program that's founded and led by Jen Dary, who was recently on thoughbot's podcast, The Giant Robots Smashing Into Other Giant Robots. I'll be sure to include a link in the show notes for anyone that's interested. +CHRIS: I believe this was the third time she was on. It's at least the second, possibly the third. And all of them are great listens, just as an aside, so we should include links to all of them. +STEPH: Yes, I think she's one of the rare guests that has been on the show three times. And I think I've only listened to the first couple minutes of that episode. But I think they talk about the fact that this is her third episode, which is really, really cool. And I'm still frankly synthesizing all the information and the ideas that I've collected from the course. +But I do have a few quick takes that I'm interested in sharing with you. So the first one is my cohort...we were the Panda Cohort, so go, Pandas. And some of the things that we talked about were…, and I think that this may have been the first day. So it was three days, and it was three hours for those three days. And they're spread out over a couple of weeks, which is really nice because then you show up for those three hours of the class, but then you leave with some ideas and some things to experiment with. You get a week to then try out an experiment and then come back to class next time and talk about this is how it went; it went to wonderful, or it went terrible. And you get to share that with others and work through it. +And in the first class, we talked about coaching versus managing, which I found just a helpful definition to review. So managing is more direct, and telling someone what to do while coaching is encouraging someone to determine their own path and find their own solution. And I find that as a team lead at thoughtbot, I'm very often more in that coaching space than I am in that managing space. I think it's frankly pretty rare that I actually need to put on a manager's hat. And I often feel like I'm wearing my coaching hat instead. +And some of the other things we talked about one of them is what is work? Which is a fun question to ask. And Jen had an analogy for this speaking about imagine that you have a plastic Easter egg. So it's got two sides, and side one is all the skills and desires and things that you're fulfilled by. And side two is a company that needs those skills. And it's great when those line up and click together, like when you take a job or get a promotion. Have you ever played...do you know what I'm talking about? Those little plastic Easter eggs. Have you ever played with those as a kid? +CHRIS: Yes, certainly. +STEPH: [laughs] I realize I just launched into that analogy. [chuckles] And then Jen goes on to say that's totally normal for then those sides to unclick. And Jen continues to say that it's totally normal for them to unclick. So maybe the company changes direction, the company is acquired. You've fallen out of love with something that you do about your job, or you have kids, and that has changed the things that you are fulfilled by and what you're looking for. And that's not necessarily bad. So it can be like, hey, you are working on x now, and you're not fulfilled by that anymore. But then another company comes along and says, "Hey, we're working on this, and you are fulfilled by that." So then another click happens. +And essentially, it's a nice analogy to represent someone's career path and the ways that we are going to shift and re-prioritize what we're interested in. But it's also a really nice way to help it feel less personal because both sides are allowed to change. The company can change. You, as an employee, can change. And then you can look for that next click that is going to match up with a company that meets your skills and things that help you feel fulfilled. +One of the other topics that we talked about are hard conversations, which I love that we dug into this one because that's certainly one that I struggle with or...I mean, we all get that feeling if you have to confront someone if you have to have that uncomfortable discussion with someone. It is a very hard thing to do. And so we had some very honest conversations around what is a hard conversation? What does that represent? And essentially, they represent that there is stalled progress and something can be improved. +So Jen likens a hard conversation to a tool. It's something that you can use to then help something move forward again if something feels stalled or if there's something that needs to change. And during those hard conversations, you may not get to the resolution that you're looking for. So you may be looking for a specific outcome. But you also have another person that needs time to respond and to take in everything that you have said and process that information. +So when you have a hard conversation, you may actually only move forward an inch. So if you had a lofty goal of we're going to talk and then we're going to have this hard conversation, and we're going to get to this space...But instead, you actually just make incremental progress. Like, okay, at least this person is now aware of this concern. That might be your win for the hard conversation versus actually tackling; how are we going to address it? I just want them to be aware of this concern. +And it's a very vulnerable conversation, and they often take time before you can get to that ideal resolution. But essentially, the idea is get in the game, start the conversation, and then have follow-up conversations for that hard conversation. And I really appreciated that framing because I often will think of hard conversations of oh, we have to have this hard conversation and get to this specific outcome. But if you shift the goal line to be like, no, I really just need to at least make this person aware of a concern, that makes it a lot more approachable. And then also probably yields more fruitful outcomes because that gives the other person time to think about what you've shared to also come to the table with their own ideas and then work together to then get to that ideal resolution. +CHRIS: I like that framing a lot. I can definitely see the case where you, as someone who has recognized something that needs to change (perhaps you're a manager),lineup you've now thought about that a good bit; you've observed it, but the individual that you're bringing that to this may be novel. This may be a surprise for them. And so if you come into that interaction both about to share this information but then also trying to resolve it and trying to get to I need you to internalize it, and I need you to fundamentally change your behavior as a result of this conversation we're going to have, that's quite possibly not a realistic outcome. And if you're trying for that, it might inherently lead to just a bad outcome because that individual is not in a position to do that. But they are potentially ready to hear it. And so you can just achieve step one and then later have step two. So I like that a lot. +STEPH: Yeah, in general, I found the course incredibly helpful, very insightful. It was also really nice to hear from other managers that are facing similar problems or perhaps novel problems and then getting to weigh in and help each other. So it's a wonderful course. I'll be sure to include a link in the show notes for anyone that is interested. And I'll probably come back with some more insights from the class because it's really...we just wrapped up. So I'm sure I still have some ideas that will percolate over time, and I want to come back and share those with the group. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: Pivoting just a bit, we have a listener question that I'm excited to dive into. This question comes from the one and only, the Edward Loveall, fellow thoughtboter. And Edward wrote in, "How does the process of software development change at different team sizes? What's a process that breaks down soon after the team starts growing? What's a process that is resilient at all sizes? And by process, I mean anything that involves other people including organizing tasks, code review, deployment, or anything else that isn't you alone writing code in a vacuum." +I'm really excited about this question because I think there's a lot here. And there's actually one part that I'm struggling with a bit, so I'm curious to see what you think, Chris, about it. But I'm going to start off with saying that I think there are a number of management processes that definitely break down as a team grows. But in the spirit of Edward's question, I'm going to focus more on the software development process and how those might need to change and what starts to break as your team grows. +So starting off with processes that break after the team starts growing, this one, frankly, what really starts to break is not a process specifically, but it's the lack of process that really starts to become visible and painful. So, how do we track work? Before, maybe the product manager or someone would just send you a message and say, "Hey, can you work on this?" or "Hey, can you fix this thing?" And how does code need to be reviewed before being merged? Does it need to be reviewed? Are people just merging as they get stuff done? How are deploys performed? Oh, we have a super urgent production fix that needs to go out, and the only person that knows how to deploy is out sick today? Cool. That's the type of process that I think that really breaks down, or at least you start to notice when the team starts to grow. What are your thoughts? +CHRIS: I definitely feel that first one very strongly. We're feeling it right now on the team, which is still very small. There are only three developers working on the project, and then we have a product manager. And each week, we're slowly iterating, and tweaking, and honing, and trying to introduce just enough process in terms of how we define the work to be done, communicate the status of it, all of that fun stuff. +We started with Trello. And we just had a board with some columns, and then we had more columns, and then we got rid of a few of them. And then we recently added a Power-Up to the Trello board, which allows for epics. So there are cards which are epics which tie to sub cards. And I'm staring at it, and I'm like, how long until we're Jira? How long can I hold out here and not be Jira? +But it does feel like we're slowly iterating towards a more useful process for this team rather than process for process' sake, which I feel like is a really useful distinction. There's also a question of like, what can be known or what can be adequately measured and whatnot versus what can't be? So we've talked many a time on the show about estimation and velocity and trying to track that and the pitfalls inherent with that. And so there's, in my mind, two different camps. There's the process we want to avoid. And again, to reference German Velasco's wonderful blog post, Say No To More Process. +And I really feel like there is a tendency often when things go wrong to then try and paper over that with process. Oh, this team didn't use the design system. So we need to write ESLint rules to make sure you can't import from the directories that aren't the thing. And it's like, we can do that, and I've definitely done that. And I will do that again in the future. But I always have the lens of do we need this? Is it worth the trade-off, the cost, the overhead, the complexity that it's bringing in? +But definitely, organizing and communicating tasks is one of the ones that becomes really difficult. The more people that are working on something, the more you need probably more than one person staying out in front of them and trying to define the next bit of work that needs to be done after that. +Code review feels like it probably should stay similar, with the exception that I lose the ability to review all code at some point. Right now, I'm trying to review every single PR that goes through or close to it. At some point, I'm just going to have to give up on that. But for now, that's my goal. But fundamentally, code review, I think, will hopefully take the same shape. +Deployment, similarly, like, I've talked about the merge queue thing. I want to get a little bit of process in there but not too much. There is definitely some necessity for change. But I definitely want to resist the urge to change everything and to just say, like, slowly over time; we’re going to have to be a big Byzantine organization with lots of rules and standard operating procedures and all of that. +I've heard anecdotally, and I don't know if this is true, so maybe someone out there on the internet can correct me if I'm wrong, but my understanding is that at Google, they’re pretty tight in terms of what languages and frameworks can be used and what processes, and workflows, and build tools and all of that whereas Facebook, as a counterpoint, is relatively lax. Obviously, React is used very heavily on the core web application. But there's some flexibility in terms of different languages and frameworks and things for sub-projects or small individual teams having a little bit more autonomy. And I think that's a really interesting thing of are you one large, cohesive, organized company or do you try to act like a bunch of small disparate but roughly connected teams that share good ideas but can work independently? And that changes how I would think about this question. +STEPH: I really like how you're describing the addition of process. It sounds like a just-in-time process. So as you're learning that something needs to be added, then that's when you look for answers. And then you sprinkle on a bit of process that everyone agrees that feels very helpful within also the right to review and see if that still makes sense for the team. +There's one additional area where I think the lack of process really shines through in addition to the number of ways that you've mentioned is also onboarding. So if you have a very small team and you are onboarding, it's likely that...Chris, you can let me know if I'm wrong, but when someone's joining the team, there's probably a good chance that they get to pair with you at some point, or they even get welcomed by you to the team. And then, they get an overview of the product and the codebase. And there's probably this really nice session where they get to ask you questions, and then they have that onboarding session. Does that sound about right? +CHRIS: Yes. But I would go so far as to say it's not just a day or a session, but it's probably a couple of days. So yes, and. +STEPH: That's even better. And with some of the smaller teams that I've seen, that onboarding process is where they are pairing with that lead person on the team. And that's going well until suddenly that lead person can't pair with everybody. And nobody has really thought about how to streamline that onboarding or how to coach or teach someone else to be a really good onboarding pair. +And I have strong feelings about this area because we often focus so much on hiring, but then we drop the ball when it comes to onboarding that new, wonderful colleague that we've worked so hard to recruit. And at the end of that day, someone's going to reach out to them and say, "Hey, how was your first day?" And it makes a big difference for that person's retention as to how those first couple of days ago. +So I think onboarding is another really important part that when you're a smaller team, you probably don't need much process because you have more of that personable onboarding experience. But as the team grows, there needs to be more of a process to help other teammates join the team. +CHRIS: It's interesting. I think I totally agree with you that over time, there is a necessity to be more intentional and to have a little bit more structure in the process. And I don't think you're saying this, but I just want to make sure we are saying the thing that I think we believe, which is that shouldn't replace the human that helps you onboard. +Like, I still like the idea that everybody gets a pair for some amount of time when they start at a new company. And you're working together on a feature, or you're working together on bug fixes. You're shipping to production as soon as possible. But you're not doing that based on some guides in a wiki. You're doing that with another human that's helping you. There should also be guides, and a wiki, and documentation, and formalization as the organization grows but not in place of having another person that you get to talk to. +STEPH: We're just going to send you a little yellow rubber duck and then with a little Post-It note that says, "Good luck [laughs] with your onboarding process." Definitely. I agree with everything you said. It does not replace that human element where there's someone that's helping you onboard. I just see that onboarding is one of those things that gets forgotten, or we often point someone to a README which I do think is great because then it is battle-testing our README. But then there still needs to be someone that is readily there to say, "Hey, how's it going? What are you struggling with? Can I pair with you?" There still has to be that human element that is helping guide you through the process. +And I think smaller teams may forget that they actually need to assign somebody to you to make sure that you have someone that you know. Like, hey, this is who I can reach out to with all my questions. Because they're probably not going to be comfortable posting in the company channel at that point or a larger communication to say, "Hey, I'm stuck on something." +CHRIS: There's one other area that comes to mind, or I guess it's more of an anecdote that I have heard, but it speaks back to GitHub's early, early days. And they were somewhat famous for being very flat in terms of the organization and very self-organized, and everybody's figuring it out, and you're working on the thing that's most important in your mind. And for a long time, this was a celebrated facet of the company and a thing that they talked about rather publicly. +And then I think there was this collective recognition, and maybe they reached a tipping point where that just didn't work anymore. Or maybe it actually hadn't been working for a bit, and there was just the collective realization of that. But it was interesting to watch from the outside as GitHub added more formalization, more structure, more managers, and hierarchy, and career ladders, and things of that nature. And I think there's a way to do all of those things in a complicated, overloaded, heavy way. +But I think a different version of it is...like, you were using the word coaching earlier. Having formal structures within your organization to encourage people on their career path, to help them grow, to have structure around that, I think is a really difficult thing to get right. But I think it is critical, and I think just not having it can't be the answer past a certain probably pretty small size. So that is an interesting one where I think you do need to introduce some process and formalization around how you think about the group of people and how they work together within your organization. +STEPH: I agree. I think where some folks may see a lack of hierarchy; others feel a lack of support. And adding levels of management should really be focused on the outcome is that we're helping people feel supported. So even getting feedback as you're adding those different levels of management, like, hey, did we make your life better? Did we make your life worse? I think that's a great question for management to ask as they're exploring a less flat structure. +CHRIS: So, Steph, I have a question for you now on a variant of this topic. In general, we seem to be fans of having a codebase. Probably a Rails app that’s got a database behind it, and that's where you put the data. Everybody commits to that same repository. It's all kind of one collected thing. And often, organizations grow to a certain size, and they're like, this is untenable. We cannot have this many people working on this same codebase. So we shall do the logical thing, which is we will break it up into small pieces. And those pieces will communicate over HTTP, and it will be great because then our teams can be separate from each other and can manage their little piece of the world. What do you think about that? Is there truth there? Is it not true at all? What do you think? +STEPH: All right, so your team is getting too big, and to the point that you feel like you need to split it out so then you can have small teams, and they can all work independently on different parts and services of the codebase. I don't love the idea. I'm trying to think through because I feel like there's a lot of nuance here. But I don't love the idea that that's the driving force as to why are we making the change? +And that is often a question that comes to mind whenever we are making a big change, either architecture or process-related is like, what's driving this? And then how are we going to measure it? And if we are driving it just because we have a large team, let's talk more. Why are people blocked? Why can't people work together? What's preventing people from being able to contribute to the same codebase? Are people blocked for a long time because they're having to wait on someone else to complete that work? I have a lot of questions that I don't know if I can fully answer your question. But my instinct is to say let's not break up the architecture just because our team grew in size. +CHRIS: Yeah, I think I definitely agree with that. There's probably a breaking point where it's just too many individuals, and there'll be too much contention. But I think resisting that or at least naming that as like, okay, that's what we're saying but is that really what's true? Or are we actually feeling that this system is so deeply coupled that there's no way to change some small piece of the code without impacting other parts of it? +Like, is the CSS completely untenable because we're just using global class names, and it's leaking everywhere? Okay, do we need a different solution there? And then it's actually fine. We don't need to have different services that have their own different style sheets. We just need a different approach to CSS. That's a particularly easy one to go for because there's inherently a global namespace there. But the same thing is true in a lot of different contexts. So services are a way to break things apart and enforce those boundaries. But if inherently coupling is your problem, then you're just going to be coupled over HTTP, and I think it's going to be difficult. +There's a wonderful blog post by Josh Clayton, which I think does a better job than I'm doing in this moment of highlighting some of the questions I would want to ask. The blog post is titled Services are Not a Silver Bullet. And so Josh goes through and enumerates a bunch of the different versions of the story that he's heard throughout the years of well, we need to go to services because x, because our test suite is slow because pull requests are constantly having merge conflicts and whatnot, because the code is very deeply coupled and any change here affects everything else. And a fix over here broke something over there. This is no good. And so he does a really good job of presenting alternatives or at least questions that you can ask to say, like, is this the problem, or is this a symptom? And we need to address the more underlying cause. +And so I think there is a point where you just can't have 1,000 people trying to commit to the same Rails codebase. That feels like it's maybe too big. But it takes a while to get to 1,000 people. And there will be times where extracting a service makes sense or integrating with an external service that exists. Like, I've talked about Stripe before as my canonical like, yeah, it's actually deeply intertwined with the data model, but they're just dealing with such a distinct complexity set over there. And they have such expertise on that that I'm happy to accept the overhead of the fact that that service lives outside of my core application, and I need to deal with synchronizing state and all of that. I will take on that complexity, but it's not worth it for everything, and it's not a silver bullet. Again, to reference the name of Josh’s blog post there, Services are Not a Silver Bullet. +And so, coming back to Edward's original question, I would say that having a monolithic codebase works for a really long time, but there is probably a breaking point somewhere well along, but fight it for as long as you can. I think. +STEPH: I really like how you touched on coupling because it really helps ask those questions to get to the heart of what are the pain points that you are feeling? And it is less of a decision that is based on people and process but more if you're going to split out a portion of your architecture. It is in response to an actual business need and a business value versus some other pain points that you're trying to fix. +A particular example might be like maybe you have a portion of your application that really just needs to spend a lot of time crunching data. And it's really not as specific to your application; it's something that can happen on its own. And then it's beneficial to move that outside so it can scale and relate it to the work that it needs to perform versus keeping it in-house with the application. +I do want to circle back to another question that Edward included which is what's a process that is resilient at all sizes? And the ones that really come to mind for me...and these are a bit amorphous intentionally because it will look different for each company. But three areas that are very resilient at all sizes, whether you are 1 to 2 employees versus you've got hundreds or thousands it's communication, testing, and accountability. +So communication, where are we headed, and how do we know what we're working on? For testing, it's how do we test our changes? Do we write tests? Do we use QA? Do we have a staging environment? What does that look like? What's our parity between staging and production? And then how do we know what's in progress, and how do we know when it's done? Those are three core areas that, regardless of your team size,,I think are very crucial to the team success. What do you think? What are some of the processes that are resilient at all sizes? +CHRIS: I actually really like the list that you just provided. That is a wonderful trifecta, and I think it will take you very far, so probably not much to add from me. But I guess on that note, should we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris regains several of his developer merit badges and embarks on a perilous CSRF (Cross-Site Request Forgery) adventure. Steph shares highlights from Plucky, a management training course, including ways we can "click" and "break apart" from our current role, and how to have hard conversations.

+ +

They also discuss how software development processes change at different team sizes, processes that break down as teams grow, and processes that are resilient at any team size.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +
+ +

Transcript:

+ +

STEPH: Boom. I'm recording. Magic is happening. [singing] What's this? What's this? It's a Bike Shed episode. What's this? What's this?

+ +

CHRIS: You did that on the mic. [laughter] So you just started recording too, so it's not like you're like, "Oh, I forgot I was recording."

+ +

STEPH: Oh, I didn't have a finishing line that rhymes with shed.

+ +

CHRIS: Head, dead, bread, spread.

+ +

STEPH: [singing] Is TDD dead? I don't know. [laughs]

+ +

CHRIS: Cool. I liked it.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: What's new? I had a fun experience over the past week or two of regaining some of my developer merit badges, which is always enjoyable. So one was I had to configure AWS, specifically S3 and IAM such that I could upload files to an S3 bucket, which seems like one of those things that a developer should be able to do, and it's just not that hard. And, man, I failed so many times, and I stared at the screen. And the ARNs I think that's another acronym that I had to try and figure out what it means and fight against. Anyway, I got there. So that's one merit badge earned. I really hope [laughs] I correctly and securely configured access to an S3 bucket such that we could upload files in our Rails app. Cool, neat.

+ +

Moving on, the next merit badge that I went for was restoring the sea of green dots. Our RSpec output had gathered some noise. There was a whole bunch of noise across a variety of things. There were some dev tools that were dumping some stuff in there. And there was something related to apparition, which is the...I want to say it's the Capybara feature spec driver that we're using now, which sits on top of ChromeDriver or something like that. I don't really understand the details, but it was complaining about something. And I found a fix, and then I fixed it and whatnot. But it was one of those. I did this on a Saturday because I was just like, you know what? This will be cathartic and healing. And then I got to the sea of green dots, and I was so happy to get to it.

+ +

STEPH: This is me...I'm giving you a round of applause.

+ +

CHRIS: Well, thank you. Arguable whether it delivered any real value to users, but again, this was Saturday effort, so I was allowed to indulge my fastidious caretaker of the code role.

+ +

STEPH: Sorry, before we move on to more serious, can we pause to talk about developer merit badges? I really, really want cute felt badges that we can...I mean, I can't design them. I don't have the talent. But I think between us and other folks, we could design amazing merit badges, and then people could collect those. I'm very much in love with that idea.

+ +

CHRIS: I love the idea. I am now certain that if we were to really pursue this, that we would fall into the deepest of bike sheds as we try and define well; what are all the merit badges? And what are the different levels?

+ +

STEPH: [laughs]

+ +

CHRIS: And how many do you need to collect before you can get to what are the different...There are just so many different taxonomies that we could introduce, and, oh man, I could spend a couple of weeks on that.

+ +

STEPH: [laughs] It has a very strong Pokémon vibe too of you got to catch them all.

+ +

CHRIS: Absolutely.

+ +

STEPH: Okay. All right. We won't digress into bikeshedding merit badges, but I'm still very, very interested in that idea.

+ +

CHRIS: Indeed. If anyone out there in the listener space wants to just make these, that would be great. This is the way that I avoid bikeshedding now is I just say I'm not allowed to make these decisions or even think about it. But if these happened into the world, I would be happy about that.

+ +

STEPH: Oh, I just remembered we do have something similar at thoughtbot. They're not physical where you can hold them, but I think we've talked about turning them into physical badges. But we have our internal tool hub that we used to track our schedules. And one of the fun Ralphapalooza events that we had, a team came up with the idea of introducing badges in the tool hub, so then you could award people badges. You could give people badges. And it's very cute. So they could probably help us with the taxonomy. They've probably already figured out a number of badges we could get started with.

+ +

CHRIS: And of course, this is where my brain went initially to like, oh, what would the taxonomy be? But I think that's how this goes bad. And if we just keep it in the this is cute and fun, and what are all the possible merit badges, but they're all equal, and the points are made up anyway, and then it's just a fun thing, then I'm like, I'm super into this. Let's do that. Have you used a regular expression to parse HTML? Congratulations, you get a merit badge. Have you not used regular expressions to parse HTML? You get a different merit badge. [chuckles]

+ +

STEPH: [laughs] I feel very positive that I could be chief of cute and fun. I could manage that department.

+ +

CHRIS: Yes, that feels like definitely a role that you could really excel at. But shifting around ever so slightly, I did run into a fun bug this week. And it was a mystery tour of, I'm going to say, sadness and then eventual learning and understanding, and I think we've come to a better place. But I want to tell a story, take us on a quick tour of the adventure that I went through.

+ +

So we recently saw a handful of exceptions come through in our exception monitoring service and then piped into Slack, where we see those around CSRF token expiry. So this occasionally happens in a Rails app. The CSRF token that was on the page gets rotated. And therefore, when someone...if they have an older version of the page open and they try and submit a form or something like that, then CSRF protection is going to kick in. And you do get some false negatives there or some cases where like, nope, this is actually a fine user, this is not hacking, this is nothing bad. It's just that that user had a tab open or something like that.

+ +

I'll be honest; I want to understand better the timeline of expiry and how Rails expires those and whatnot. But it's one of those things; it’s deep enough in Rails that I trust that they are doing a very reasonable thing. And I think the failures that we're seeing that's part of the game. And so, mostly, we wanted to add a nicer handling around that. So thankfully, Inertia actually has a really wonderful page in their docs about handling Cross-Site Request Forgery expiration token, this whole thing. This is a particular failure mode that your app might have. And so it's nice to be able to provide a nicer user experience.

+ +

And so what we ended up doing is if we catch that exception, we have a rescue_from in our application controller that will instead of having this be a 500 and just a full, like, something went wrong error page, we instead respond in an Inertia-like way to basically show a flash message that says, "This page has expired. Please refresh the page to continue." And if the user just refreshes the page, then they will get a new CSRF token. And from there, everything is going to be fine. So it's not ideal. But it is, I think, both secure and now a nicer user experience.

+ +

STEPH: Yeah, that sounds really nice. When they refresh the page, do they lose all that form data? I'm curious how painful of a flow that is for the user.

+ +

CHRIS: Currently, yes. Inertia actually has a really nice feature for remembering form data. If you've ever been on GitHub and you're filling in a box, and then you go away to a different tab, and you come back, and it's still there, and you're happy about that, it's that sort of thing. So we could configure that. At this point, we don't have...most of our forms are pretty small. So this is not something that we opted to do proactive management around. But that is definitely something that we could add but not something that's default or anything like that.

+ +

STEPH: Cool. Yeah, that makes sense. I was just curious because yeah, either small form doesn't really matter, or also, this may be just a small enough error that only a handful of people are experiencing it that it's also just not that big of a deal.

+ +

CHRIS: Yes, this definitely should be an edge case. And we've also recently been working on functionality to log folks out after a period of inactivity, which would also, I think, obviate this in a different way. So all total, this shouldn't be a big deal. And this was basically a quick, little snippet of code that we thought we could just drop in, and everything would be great because it shouldn't happen much.

+ +

But then I was testing out a different feature on staging, and everything I tried to do was popping up this little alert flash message that was like, "Hey, your page is expired." And I was like, that seems bad. And then I realized literally every action, any non-GET request, was getting this response that the CSRF token didn't match. And I was like, well, this seems bad. Luckily, it was only on staging and hadn't made it to production.

+ +

But it had made it to staging, which meant it had gotten through CI, which was very concerning because we have a pretty robust set of feature specs at this point. We built up a bunch of fakes for all of the external data systems that we're interacting with. And we're really putting the app through its paces and trying to do so in a very production-like way. And so I was like, this is such a deep fundamental breakage. I don't know what's going on here. And so I started to investigate.

+ +

And it turns out that in a recent commit, I had started using Axios, which is a little wrapper around the Fetch API. They may not actually use the Fetch API under the hood, but it allows you to have a nicer interface to make XHRs. And we implicitly had that in our package already by virtue of Inertia. Inertia uses it under the hood, but I wanted to make it explicit because now I was using it directly. So I figured that's cool. I will yarn add Axios, and then I will continue on with my day. And I worked on my feature and everything was great. And then I pushed it up into a pull request, and everything was great, and CI passed. And I got it onto staging, and everything was very sad.

+ +

So then I started on the adventure of like, what is going on here? It turns out that somewhere between version 0.21.1 of Axios and 0.23.0, which there's a bunch of things about those version numbers that make me uncomfortable but here we are, somehow the behavior where you can configure the XSRF header name, which is what they're calling it on their side, the configuration stopped working. And so our override that says this is what our CSRF or XSRF token should be called when it's sent back up to the server in a header that was getting lost. And so they were falling back to their default name, Axios was. And, therefore, Rails was like, "There's no CSRF token here. So this is going to be a no for me. I'm going to reject all of the requests."

+ +

So the fix was relatively easy to roll back and to pin the version of Axios to the previous version that we had been using. I didn't actually intend to upgrade it. I just intended to make it an explicit dependency. But by doing that, I accidentally upgraded it. I don't love that there was this pretty deep breakage in that. I haven't done the good work of trying to open an issue. I still want to scan through and see if there is an open issue or a conversation around this before I start making any noise. But I think if I don't find anything, this is the sort of thing that should be reported because I can't imagine I'm the only one running into this.

+ +

Likewise, I was very sad that my test suite did not find this. Turns out in Rails, CSRF protection is just turned off in test mode, which may be overall makes sense. But for feature specs, in particular, I definitely want to have it. And so, it was nice that I was able to find the relevant configuration. And we introduced an RSpec configuration that says, "If it's a feature spec, save off the existing configuration and enable CSRF. And then after the spec, go back to whatever the previous was."

+ +

So now all feature specs run with CSRF. And I did make sure to push up that as a singular change to CI, and CI was very unhappy with me. Many, many features-specs failed, which was good. That was what we were going for. They failed for the right reason because things were fundamentally broken. And then, I was able to update the package-lock or the package.json on the yarn lock, pin the version, fix everything.

+ +

But man, there was this period of like, oh man, the app is broken in such a fundamental way. Users just can't do stuff anymore. They can view anything, but they couldn't change any data. And it just snuck through CI. And that feeling is the worst feeling. We had, at this point, built up a lot of trust in our test suite. It was really telling us when stuff was wrong, and if it was green, I felt very good merging. And suddenly, this just really shook me to my core on that front.

+ +

STEPH: I love these journeys that you take us on. I mean, they're painful for you, and I am sorry to hear that. But I love these journeys that you take us on. [chuckles]

+ +

CHRIS: I usually only take us on them when I've figured out the answer. And I'm like, all right, here's where we're at. It was rough for a little while, but now we are happy. And thankfully, the one configuration of saying, hey, Rails, also, please include this as part of our production like, configuration for test mode. So I feel better that moving forward, this breakage won't happen again.

+ +

STEPH: We should add that as another merit badge for telling a bug story. All right, I'm taking off my hat of chief of fun and cuteness. So this may not be terribly relevant to all the things that you just shared. But I am curious where you mentioned that with Axios because you'd specified the name of the token, and then that overriding behavior is what then broke. And so then that's what led to this whole adventure that you went on. I'm curious, why did y'all customize the name of that token?

+ +

CHRIS: A, this is a great question. B, I'm not super sure. C, I think the reason is because we were trying to align to Rails. So we have a little middleware on the Rails side that will serialize the CSRF token into a cookie. And then that cookie value gets read by Axios and sent back up as a header on the request. So this is the way that with Inertia CSRF just kind of works and is good. And it's different than Rails' normal. We put a hidden input into any form. And so Rails holistically knows about both sides of that, and everything works fine. But now I have to manually round trip the CSRF token.

+ +

And Axio's default configuration is a header name X-XSRF-TOKEN, and we needed X-CSRF-TOKEN because that's what Rails is looking for. I probably could have configured it the other way on the Rails side. But one way or another, I had to get Rails and Axios to come to an agreement, to meet at a table, and to agree to collectively protect the app. And so I had to mediate that discussion, and that's what ended us here.

+ +

STEPH: A meeting of the minds. [chuckles] Cool, cool, cool. Yeah, that makes sense. I was just curious because then that would have changed the whole journey. But yeah, that is super interesting. And I definitely resonate with the idea of when you've really invested in your test suite, and you trust it that then when it doesn't catch something that obviously breaks the application, then that feels like something worth prioritizing and digging into and then figuring out how to bring back that parity.

+ +

I don't know that I've turned on enable CSRF for feature spec. So I'm also very interested in looking at that configuration and considering if I need that for any of my future client projects if that's something that I need to remember for the future because that's very niche but good to know about.

+ +

CHRIS: I feel like this only really comes up if you're working in the...it's called the odd middle ground that Inertia ends up occupying. If you're in a traditional Rails app that is generating HTML server-side, forms are generated. They got the CSRF token inlined there in a hidden input. And then when you post that form, it's coming back up. The names automatically are going to match. You don't need to worry about it. And it's probably fine to not have it included in test mode.

+ +

And if you're at the other end of the spectrum and you've got API interaction, and that's the way you're doing everything, then you have a different auth mechanism and cookies, and whatnot just don't apply in the same way. And so it won't really matter on that side but for a different reason. And it's only because we're in this interesting middle ground, which, again, I really love. And it's the thing that I love about Inertia. But this is a rare case where it's like, oh, we do have to bring the two sides to meet in the middle. And this is a case where, unfortunately, due to a very subtle breakage on a minor release of...a package that we're using silently broke so, yeah.

+ +

But yeah, thankfully, everything is back to working. And again, we've been able to enhance the test suite in that little way that I feel confident again because this won't sneak in another time. We have coverage around this. We're good to go. So while I was very scared when this initially happened, I feel better now. I'm happy to go into the weekend feeling better about this. But that's my story. What's new in your world?

+ +

STEPH: So I feel like I've been having one of those weeks where I have less code adventures. In fact, it's one of those days where I went to thoughtbot's daily sync...because we often have our client daily syncs, but then we still have a thoughtbot sync as well. And I went to the group, and I was like, I get to write code today. It's going to be a great day. All the other things I'm doing are also interesting, but I get particularly excited when I get some maker's time and get to write some code.

+ +

So I feel like I've had less coding adventures recently and more hiring and process-related adventures. And specifically, I just completed the Plucky Manager Training, which is a program that's founded and led by Jen Dary, who was recently on thoughbot's podcast, The Giant Robots Smashing Into Other Giant Robots. I'll be sure to include a link in the show notes for anyone that's interested.

+ +

CHRIS: I believe this was the third time she was on. It's at least the second, possibly the third. And all of them are great listens, just as an aside, so we should include links to all of them.

+ +

STEPH: Yes, I think she's one of the rare guests that has been on the show three times. And I think I've only listened to the first couple minutes of that episode. But I think they talk about the fact that this is her third episode, which is really, really cool. And I'm still frankly synthesizing all the information and the ideas that I've collected from the course.

+ +

But I do have a few quick takes that I'm interested in sharing with you. So the first one is my cohort...we were the Panda Cohort, so go, Pandas. And some of the things that we talked about were…, and I think that this may have been the first day. So it was three days, and it was three hours for those three days. And they're spread out over a couple of weeks, which is really nice because then you show up for those three hours of the class, but then you leave with some ideas and some things to experiment with. You get a week to then try out an experiment and then come back to class next time and talk about this is how it went; it went to wonderful, or it went terrible. And you get to share that with others and work through it.

+ +

And in the first class, we talked about coaching versus managing, which I found just a helpful definition to review. So managing is more direct, and telling someone what to do while coaching is encouraging someone to determine their own path and find their own solution. And I find that as a team lead at thoughtbot, I'm very often more in that coaching space than I am in that managing space. I think it's frankly pretty rare that I actually need to put on a manager's hat. And I often feel like I'm wearing my coaching hat instead.

+ +

And some of the other things we talked about one of them is what is work? Which is a fun question to ask. And Jen had an analogy for this speaking about imagine that you have a plastic Easter egg. So it's got two sides, and side one is all the skills and desires and things that you're fulfilled by. And side two is a company that needs those skills. And it's great when those line up and click together, like when you take a job or get a promotion. Have you ever played...do you know what I'm talking about? Those little plastic Easter eggs. Have you ever played with those as a kid?

+ +

CHRIS: Yes, certainly.

+ +

STEPH: [laughs] I realize I just launched into that analogy. [chuckles] And then Jen goes on to say that's totally normal for then those sides to unclick. And Jen continues to say that it's totally normal for them to unclick. So maybe the company changes direction, the company is acquired. You've fallen out of love with something that you do about your job, or you have kids, and that has changed the things that you are fulfilled by and what you're looking for. And that's not necessarily bad. So it can be like, hey, you are working on x now, and you're not fulfilled by that anymore. But then another company comes along and says, "Hey, we're working on this, and you are fulfilled by that." So then another click happens.

+ +

And essentially, it's a nice analogy to represent someone's career path and the ways that we are going to shift and re-prioritize what we're interested in. But it's also a really nice way to help it feel less personal because both sides are allowed to change. The company can change. You, as an employee, can change. And then you can look for that next click that is going to match up with a company that meets your skills and things that help you feel fulfilled.

+ +

One of the other topics that we talked about are hard conversations, which I love that we dug into this one because that's certainly one that I struggle with or...I mean, we all get that feeling if you have to confront someone if you have to have that uncomfortable discussion with someone. It is a very hard thing to do. And so we had some very honest conversations around what is a hard conversation? What does that represent? And essentially, they represent that there is stalled progress and something can be improved.

+ +

So Jen likens a hard conversation to a tool. It's something that you can use to then help something move forward again if something feels stalled or if there's something that needs to change. And during those hard conversations, you may not get to the resolution that you're looking for. So you may be looking for a specific outcome. But you also have another person that needs time to respond and to take in everything that you have said and process that information.

+ +

So when you have a hard conversation, you may actually only move forward an inch. So if you had a lofty goal of we're going to talk and then we're going to have this hard conversation, and we're going to get to this space...But instead, you actually just make incremental progress. Like, okay, at least this person is now aware of this concern. That might be your win for the hard conversation versus actually tackling; how are we going to address it? I just want them to be aware of this concern.

+ +

And it's a very vulnerable conversation, and they often take time before you can get to that ideal resolution. But essentially, the idea is get in the game, start the conversation, and then have follow-up conversations for that hard conversation. And I really appreciated that framing because I often will think of hard conversations of oh, we have to have this hard conversation and get to this specific outcome. But if you shift the goal line to be like, no, I really just need to at least make this person aware of a concern, that makes it a lot more approachable. And then also probably yields more fruitful outcomes because that gives the other person time to think about what you've shared to also come to the table with their own ideas and then work together to then get to that ideal resolution.

+ +

CHRIS: I like that framing a lot. I can definitely see the case where you, as someone who has recognized something that needs to change (perhaps you're a manager),lineup you've now thought about that a good bit; you've observed it, but the individual that you're bringing that to this may be novel. This may be a surprise for them. And so if you come into that interaction both about to share this information but then also trying to resolve it and trying to get to I need you to internalize it, and I need you to fundamentally change your behavior as a result of this conversation we're going to have, that's quite possibly not a realistic outcome. And if you're trying for that, it might inherently lead to just a bad outcome because that individual is not in a position to do that. But they are potentially ready to hear it. And so you can just achieve step one and then later have step two. So I like that a lot.

+ +

STEPH: Yeah, in general, I found the course incredibly helpful, very insightful. It was also really nice to hear from other managers that are facing similar problems or perhaps novel problems and then getting to weigh in and help each other. So it's a wonderful course. I'll be sure to include a link in the show notes for anyone that is interested. And I'll probably come back with some more insights from the class because it's really...we just wrapped up. So I'm sure I still have some ideas that will percolate over time, and I want to come back and share those with the group.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Pivoting just a bit, we have a listener question that I'm excited to dive into. This question comes from the one and only, the Edward Loveall, fellow thoughtboter. And Edward wrote in, "How does the process of software development change at different team sizes? What's a process that breaks down soon after the team starts growing? What's a process that is resilient at all sizes? And by process, I mean anything that involves other people including organizing tasks, code review, deployment, or anything else that isn't you alone writing code in a vacuum."

+ +

I'm really excited about this question because I think there's a lot here. And there's actually one part that I'm struggling with a bit, so I'm curious to see what you think, Chris, about it. But I'm going to start off with saying that I think there are a number of management processes that definitely break down as a team grows. But in the spirit of Edward's question, I'm going to focus more on the software development process and how those might need to change and what starts to break as your team grows.

+ +

So starting off with processes that break after the team starts growing, this one, frankly, what really starts to break is not a process specifically, but it's the lack of process that really starts to become visible and painful. So, how do we track work? Before, maybe the product manager or someone would just send you a message and say, "Hey, can you work on this?" or "Hey, can you fix this thing?" And how does code need to be reviewed before being merged? Does it need to be reviewed? Are people just merging as they get stuff done? How are deploys performed? Oh, we have a super urgent production fix that needs to go out, and the only person that knows how to deploy is out sick today? Cool. That's the type of process that I think that really breaks down, or at least you start to notice when the team starts to grow. What are your thoughts?

+ +

CHRIS: I definitely feel that first one very strongly. We're feeling it right now on the team, which is still very small. There are only three developers working on the project, and then we have a product manager. And each week, we're slowly iterating, and tweaking, and honing, and trying to introduce just enough process in terms of how we define the work to be done, communicate the status of it, all of that fun stuff.

+ +

We started with Trello. And we just had a board with some columns, and then we had more columns, and then we got rid of a few of them. And then we recently added a Power-Up to the Trello board, which allows for epics. So there are cards which are epics which tie to sub cards. And I'm staring at it, and I'm like, how long until we're Jira? How long can I hold out here and not be Jira?

+ +

But it does feel like we're slowly iterating towards a more useful process for this team rather than process for process' sake, which I feel like is a really useful distinction. There's also a question of like, what can be known or what can be adequately measured and whatnot versus what can't be? So we've talked many a time on the show about estimation and velocity and trying to track that and the pitfalls inherent with that. And so there's, in my mind, two different camps. There's the process we want to avoid. And again, to reference German Velasco's wonderful blog post, Say No To More Process.

+ +

And I really feel like there is a tendency often when things go wrong to then try and paper over that with process. Oh, this team didn't use the design system. So we need to write ESLint rules to make sure you can't import from the directories that aren't the thing. And it's like, we can do that, and I've definitely done that. And I will do that again in the future. But I always have the lens of do we need this? Is it worth the trade-off, the cost, the overhead, the complexity that it's bringing in?

+ +

But definitely, organizing and communicating tasks is one of the ones that becomes really difficult. The more people that are working on something, the more you need probably more than one person staying out in front of them and trying to define the next bit of work that needs to be done after that.

+ +

Code review feels like it probably should stay similar, with the exception that I lose the ability to review all code at some point. Right now, I'm trying to review every single PR that goes through or close to it. At some point, I'm just going to have to give up on that. But for now, that's my goal. But fundamentally, code review, I think, will hopefully take the same shape.

+ +

Deployment, similarly, like, I've talked about the merge queue thing. I want to get a little bit of process in there but not too much. There is definitely some necessity for change. But I definitely want to resist the urge to change everything and to just say, like, slowly over time; we’re going to have to be a big Byzantine organization with lots of rules and standard operating procedures and all of that.

+ +

I've heard anecdotally, and I don't know if this is true, so maybe someone out there on the internet can correct me if I'm wrong, but my understanding is that at Google, they’re pretty tight in terms of what languages and frameworks can be used and what processes, and workflows, and build tools and all of that whereas Facebook, as a counterpoint, is relatively lax. Obviously, React is used very heavily on the core web application. But there's some flexibility in terms of different languages and frameworks and things for sub-projects or small individual teams having a little bit more autonomy. And I think that's a really interesting thing of are you one large, cohesive, organized company or do you try to act like a bunch of small disparate but roughly connected teams that share good ideas but can work independently? And that changes how I would think about this question.

+ +

STEPH: I really like how you're describing the addition of process. It sounds like a just-in-time process. So as you're learning that something needs to be added, then that's when you look for answers. And then you sprinkle on a bit of process that everyone agrees that feels very helpful within also the right to review and see if that still makes sense for the team.

+ +

There's one additional area where I think the lack of process really shines through in addition to the number of ways that you've mentioned is also onboarding. So if you have a very small team and you are onboarding, it's likely that...Chris, you can let me know if I'm wrong, but when someone's joining the team, there's probably a good chance that they get to pair with you at some point, or they even get welcomed by you to the team. And then, they get an overview of the product and the codebase. And there's probably this really nice session where they get to ask you questions, and then they have that onboarding session. Does that sound about right?

+ +

CHRIS: Yes. But I would go so far as to say it's not just a day or a session, but it's probably a couple of days. So yes, and.

+ +

STEPH: That's even better. And with some of the smaller teams that I've seen, that onboarding process is where they are pairing with that lead person on the team. And that's going well until suddenly that lead person can't pair with everybody. And nobody has really thought about how to streamline that onboarding or how to coach or teach someone else to be a really good onboarding pair.

+ +

And I have strong feelings about this area because we often focus so much on hiring, but then we drop the ball when it comes to onboarding that new, wonderful colleague that we've worked so hard to recruit. And at the end of that day, someone's going to reach out to them and say, "Hey, how was your first day?" And it makes a big difference for that person's retention as to how those first couple of days ago.

+ +

So I think onboarding is another really important part that when you're a smaller team, you probably don't need much process because you have more of that personable onboarding experience. But as the team grows, there needs to be more of a process to help other teammates join the team.

+ +

CHRIS: It's interesting. I think I totally agree with you that over time, there is a necessity to be more intentional and to have a little bit more structure in the process. And I don't think you're saying this, but I just want to make sure we are saying the thing that I think we believe, which is that shouldn't replace the human that helps you onboard.

+ +

Like, I still like the idea that everybody gets a pair for some amount of time when they start at a new company. And you're working together on a feature, or you're working together on bug fixes. You're shipping to production as soon as possible. But you're not doing that based on some guides in a wiki. You're doing that with another human that's helping you. There should also be guides, and a wiki, and documentation, and formalization as the organization grows but not in place of having another person that you get to talk to.

+ +

STEPH: We're just going to send you a little yellow rubber duck and then with a little Post-It note that says, "Good luck [laughs] with your onboarding process." Definitely. I agree with everything you said. It does not replace that human element where there's someone that's helping you onboard. I just see that onboarding is one of those things that gets forgotten, or we often point someone to a README which I do think is great because then it is battle-testing our README. But then there still needs to be someone that is readily there to say, "Hey, how's it going? What are you struggling with? Can I pair with you?" There still has to be that human element that is helping guide you through the process.

+ +

And I think smaller teams may forget that they actually need to assign somebody to you to make sure that you have someone that you know. Like, hey, this is who I can reach out to with all my questions. Because they're probably not going to be comfortable posting in the company channel at that point or a larger communication to say, "Hey, I'm stuck on something."

+ +

CHRIS: There's one other area that comes to mind, or I guess it's more of an anecdote that I have heard, but it speaks back to GitHub's early, early days. And they were somewhat famous for being very flat in terms of the organization and very self-organized, and everybody's figuring it out, and you're working on the thing that's most important in your mind. And for a long time, this was a celebrated facet of the company and a thing that they talked about rather publicly.

+ +

And then I think there was this collective recognition, and maybe they reached a tipping point where that just didn't work anymore. Or maybe it actually hadn't been working for a bit, and there was just the collective realization of that. But it was interesting to watch from the outside as GitHub added more formalization, more structure, more managers, and hierarchy, and career ladders, and things of that nature. And I think there's a way to do all of those things in a complicated, overloaded, heavy way.

+ +

But I think a different version of it is...like, you were using the word coaching earlier. Having formal structures within your organization to encourage people on their career path, to help them grow, to have structure around that, I think is a really difficult thing to get right. But I think it is critical, and I think just not having it can't be the answer past a certain probably pretty small size. So that is an interesting one where I think you do need to introduce some process and formalization around how you think about the group of people and how they work together within your organization.

+ +

STEPH: I agree. I think where some folks may see a lack of hierarchy; others feel a lack of support. And adding levels of management should really be focused on the outcome is that we're helping people feel supported. So even getting feedback as you're adding those different levels of management, like, hey, did we make your life better? Did we make your life worse? I think that's a great question for management to ask as they're exploring a less flat structure.

+ +

CHRIS: So, Steph, I have a question for you now on a variant of this topic. In general, we seem to be fans of having a codebase. Probably a Rails app that’s got a database behind it, and that's where you put the data. Everybody commits to that same repository. It's all kind of one collected thing. And often, organizations grow to a certain size, and they're like, this is untenable. We cannot have this many people working on this same codebase. So we shall do the logical thing, which is we will break it up into small pieces. And those pieces will communicate over HTTP, and it will be great because then our teams can be separate from each other and can manage their little piece of the world. What do you think about that? Is there truth there? Is it not true at all? What do you think?

+ +

STEPH: All right, so your team is getting too big, and to the point that you feel like you need to split it out so then you can have small teams, and they can all work independently on different parts and services of the codebase. I don't love the idea. I'm trying to think through because I feel like there's a lot of nuance here. But I don't love the idea that that's the driving force as to why are we making the change?

+ +

And that is often a question that comes to mind whenever we are making a big change, either architecture or process-related is like, what's driving this? And then how are we going to measure it? And if we are driving it just because we have a large team, let's talk more. Why are people blocked? Why can't people work together? What's preventing people from being able to contribute to the same codebase? Are people blocked for a long time because they're having to wait on someone else to complete that work? I have a lot of questions that I don't know if I can fully answer your question. But my instinct is to say let's not break up the architecture just because our team grew in size.

+ +

CHRIS: Yeah, I think I definitely agree with that. There's probably a breaking point where it's just too many individuals, and there'll be too much contention. But I think resisting that or at least naming that as like, okay, that's what we're saying but is that really what's true? Or are we actually feeling that this system is so deeply coupled that there's no way to change some small piece of the code without impacting other parts of it?

+ +

Like, is the CSS completely untenable because we're just using global class names, and it's leaking everywhere? Okay, do we need a different solution there? And then it's actually fine. We don't need to have different services that have their own different style sheets. We just need a different approach to CSS. That's a particularly easy one to go for because there's inherently a global namespace there. But the same thing is true in a lot of different contexts. So services are a way to break things apart and enforce those boundaries. But if inherently coupling is your problem, then you're just going to be coupled over HTTP, and I think it's going to be difficult.

+ +

There's a wonderful blog post by Josh Clayton, which I think does a better job than I'm doing in this moment of highlighting some of the questions I would want to ask. The blog post is titled Services are Not a Silver Bullet. And so Josh goes through and enumerates a bunch of the different versions of the story that he's heard throughout the years of well, we need to go to services because x, because our test suite is slow because pull requests are constantly having merge conflicts and whatnot, because the code is very deeply coupled and any change here affects everything else. And a fix over here broke something over there. This is no good. And so he does a really good job of presenting alternatives or at least questions that you can ask to say, like, is this the problem, or is this a symptom? And we need to address the more underlying cause.

+ +

And so I think there is a point where you just can't have 1,000 people trying to commit to the same Rails codebase. That feels like it's maybe too big. But it takes a while to get to 1,000 people. And there will be times where extracting a service makes sense or integrating with an external service that exists. Like, I've talked about Stripe before as my canonical like, yeah, it's actually deeply intertwined with the data model, but they're just dealing with such a distinct complexity set over there. And they have such expertise on that that I'm happy to accept the overhead of the fact that that service lives outside of my core application, and I need to deal with synchronizing state and all of that. I will take on that complexity, but it's not worth it for everything, and it's not a silver bullet. Again, to reference the name of Josh’s blog post there, Services are Not a Silver Bullet.

+ +

And so, coming back to Edward's original question, I would say that having a monolithic codebase works for a really long time, but there is probably a breaking point somewhere well along, but fight it for as long as you can. I think.

+ +

STEPH: I really like how you touched on coupling because it really helps ask those questions to get to the heart of what are the pain points that you are feeling? And it is less of a decision that is based on people and process but more if you're going to split out a portion of your architecture. It is in response to an actual business need and a business value versus some other pain points that you're trying to fix.

+ +

A particular example might be like maybe you have a portion of your application that really just needs to spend a lot of time crunching data. And it's really not as specific to your application; it's something that can happen on its own. And then it's beneficial to move that outside so it can scale and relate it to the work that it needs to perform versus keeping it in-house with the application.

+ +

I do want to circle back to another question that Edward included which is what's a process that is resilient at all sizes? And the ones that really come to mind for me...and these are a bit amorphous intentionally because it will look different for each company. But three areas that are very resilient at all sizes, whether you are 1 to 2 employees versus you've got hundreds or thousands it's communication, testing, and accountability.

+ +

So communication, where are we headed, and how do we know what we're working on? For testing, it's how do we test our changes? Do we write tests? Do we use QA? Do we have a staging environment? What does that look like? What's our parity between staging and production? And then how do we know what's in progress, and how do we know when it's done? Those are three core areas that, regardless of your team size,,I think are very crucial to the team success. What do you think? What are some of the processes that are resilient at all sizes?

+ +

CHRIS: I actually really like the list that you just provided. That is a wonderful trifecta, and I think it will take you very far, so probably not much to add from me. But I guess on that note, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris regains several of his developer merit badges and embarks on a perilous CSRF (Cross-Site Request Forgery) adventure. Steph shares highlights from Plucky, a management training course, including ways we can "click" and "break apart" from our current role, and how to have hard conversations.

+ +

They also discuss how software development processes change at different team sizes, processes that break down as teams grow, and processes that are resilient at any team size.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.

+ +
+ + + +
+ +

Become a Sponsor of The Bike Shed!

+ +
+ +

Transcript:

+ +

STEPH: Boom. I'm recording. Magic is happening. [singing] What's this? What's this? It's a Bike Shed episode. What's this? What's this?

+ +

CHRIS: You did that on the mic. [laughter] So you just started recording too, so it's not like you're like, "Oh, I forgot I was recording."

+ +

STEPH: Oh, I didn't have a finishing line that rhymes with shed.

+ +

CHRIS: Head, dead, bread, spread.

+ +

STEPH: [singing] Is TDD dead? I don't know. [laughs]

+ +

CHRIS: Cool. I liked it.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: What's new? I had a fun experience over the past week or two of regaining some of my developer merit badges, which is always enjoyable. So one was I had to configure AWS, specifically S3 and IAM such that I could upload files to an S3 bucket, which seems like one of those things that a developer should be able to do, and it's just not that hard. And, man, I failed so many times, and I stared at the screen. And the ARNs I think that's another acronym that I had to try and figure out what it means and fight against. Anyway, I got there. So that's one merit badge earned. I really hope [laughs] I correctly and securely configured access to an S3 bucket such that we could upload files in our Rails app. Cool, neat.

+ +

Moving on, the next merit badge that I went for was restoring the sea of green dots. Our RSpec output had gathered some noise. There was a whole bunch of noise across a variety of things. There were some dev tools that were dumping some stuff in there. And there was something related to apparition, which is the...I want to say it's the Capybara feature spec driver that we're using now, which sits on top of ChromeDriver or something like that. I don't really understand the details, but it was complaining about something. And I found a fix, and then I fixed it and whatnot. But it was one of those. I did this on a Saturday because I was just like, you know what? This will be cathartic and healing. And then I got to the sea of green dots, and I was so happy to get to it.

+ +

STEPH: This is me...I'm giving you a round of applause.

+ +

CHRIS: Well, thank you. Arguable whether it delivered any real value to users, but again, this was Saturday effort, so I was allowed to indulge my fastidious caretaker of the code role.

+ +

STEPH: Sorry, before we move on to more serious, can we pause to talk about developer merit badges? I really, really want cute felt badges that we can...I mean, I can't design them. I don't have the talent. But I think between us and other folks, we could design amazing merit badges, and then people could collect those. I'm very much in love with that idea.

+ +

CHRIS: I love the idea. I am now certain that if we were to really pursue this, that we would fall into the deepest of bike sheds as we try and define well; what are all the merit badges? And what are the different levels?

+ +

STEPH: [laughs]

+ +

CHRIS: And how many do you need to collect before you can get to what are the different...There are just so many different taxonomies that we could introduce, and, oh man, I could spend a couple of weeks on that.

+ +

STEPH: [laughs] It has a very strong Pokémon vibe too of you got to catch them all.

+ +

CHRIS: Absolutely.

+ +

STEPH: Okay. All right. We won't digress into bikeshedding merit badges, but I'm still very, very interested in that idea.

+ +

CHRIS: Indeed. If anyone out there in the listener space wants to just make these, that would be great. This is the way that I avoid bikeshedding now is I just say I'm not allowed to make these decisions or even think about it. But if these happened into the world, I would be happy about that.

+ +

STEPH: Oh, I just remembered we do have something similar at thoughtbot. They're not physical where you can hold them, but I think we've talked about turning them into physical badges. But we have our internal tool hub that we used to track our schedules. And one of the fun Ralphapalooza events that we had, a team came up with the idea of introducing badges in the tool hub, so then you could award people badges. You could give people badges. And it's very cute. So they could probably help us with the taxonomy. They've probably already figured out a number of badges we could get started with.

+ +

CHRIS: And of course, this is where my brain went initially to like, oh, what would the taxonomy be? But I think that's how this goes bad. And if we just keep it in the this is cute and fun, and what are all the possible merit badges, but they're all equal, and the points are made up anyway, and then it's just a fun thing, then I'm like, I'm super into this. Let's do that. Have you used a regular expression to parse HTML? Congratulations, you get a merit badge. Have you not used regular expressions to parse HTML? You get a different merit badge. [chuckles]

+ +

STEPH: [laughs] I feel very positive that I could be chief of cute and fun. I could manage that department.

+ +

CHRIS: Yes, that feels like definitely a role that you could really excel at. But shifting around ever so slightly, I did run into a fun bug this week. And it was a mystery tour of, I'm going to say, sadness and then eventual learning and understanding, and I think we've come to a better place. But I want to tell a story, take us on a quick tour of the adventure that I went through.

+ +

So we recently saw a handful of exceptions come through in our exception monitoring service and then piped into Slack, where we see those around CSRF token expiry. So this occasionally happens in a Rails app. The CSRF token that was on the page gets rotated. And therefore, when someone...if they have an older version of the page open and they try and submit a form or something like that, then CSRF protection is going to kick in. And you do get some false negatives there or some cases where like, nope, this is actually a fine user, this is not hacking, this is nothing bad. It's just that that user had a tab open or something like that.

+ +

I'll be honest; I want to understand better the timeline of expiry and how Rails expires those and whatnot. But it's one of those things; it’s deep enough in Rails that I trust that they are doing a very reasonable thing. And I think the failures that we're seeing that's part of the game. And so, mostly, we wanted to add a nicer handling around that. So thankfully, Inertia actually has a really wonderful page in their docs about handling Cross-Site Request Forgery expiration token, this whole thing. This is a particular failure mode that your app might have. And so it's nice to be able to provide a nicer user experience.

+ +

And so what we ended up doing is if we catch that exception, we have a rescue_from in our application controller that will instead of having this be a 500 and just a full, like, something went wrong error page, we instead respond in an Inertia-like way to basically show a flash message that says, "This page has expired. Please refresh the page to continue." And if the user just refreshes the page, then they will get a new CSRF token. And from there, everything is going to be fine. So it's not ideal. But it is, I think, both secure and now a nicer user experience.

+ +

STEPH: Yeah, that sounds really nice. When they refresh the page, do they lose all that form data? I'm curious how painful of a flow that is for the user.

+ +

CHRIS: Currently, yes. Inertia actually has a really nice feature for remembering form data. If you've ever been on GitHub and you're filling in a box, and then you go away to a different tab, and you come back, and it's still there, and you're happy about that, it's that sort of thing. So we could configure that. At this point, we don't have...most of our forms are pretty small. So this is not something that we opted to do proactive management around. But that is definitely something that we could add but not something that's default or anything like that.

+ +

STEPH: Cool. Yeah, that makes sense. I was just curious because yeah, either small form doesn't really matter, or also, this may be just a small enough error that only a handful of people are experiencing it that it's also just not that big of a deal.

+ +

CHRIS: Yes, this definitely should be an edge case. And we've also recently been working on functionality to log folks out after a period of inactivity, which would also, I think, obviate this in a different way. So all total, this shouldn't be a big deal. And this was basically a quick, little snippet of code that we thought we could just drop in, and everything would be great because it shouldn't happen much.

+ +

But then I was testing out a different feature on staging, and everything I tried to do was popping up this little alert flash message that was like, "Hey, your page is expired." And I was like, that seems bad. And then I realized literally every action, any non-GET request, was getting this response that the CSRF token didn't match. And I was like, well, this seems bad. Luckily, it was only on staging and hadn't made it to production.

+ +

But it had made it to staging, which meant it had gotten through CI, which was very concerning because we have a pretty robust set of feature specs at this point. We built up a bunch of fakes for all of the external data systems that we're interacting with. And we're really putting the app through its paces and trying to do so in a very production-like way. And so I was like, this is such a deep fundamental breakage. I don't know what's going on here. And so I started to investigate.

+ +

And it turns out that in a recent commit, I had started using Axios, which is a little wrapper around the Fetch API. They may not actually use the Fetch API under the hood, but it allows you to have a nicer interface to make XHRs. And we implicitly had that in our package already by virtue of Inertia. Inertia uses it under the hood, but I wanted to make it explicit because now I was using it directly. So I figured that's cool. I will yarn add Axios, and then I will continue on with my day. And I worked on my feature and everything was great. And then I pushed it up into a pull request, and everything was great, and CI passed. And I got it onto staging, and everything was very sad.

+ +

So then I started on the adventure of like, what is going on here? It turns out that somewhere between version 0.21.1 of Axios and 0.23.0, which there's a bunch of things about those version numbers that make me uncomfortable but here we are, somehow the behavior where you can configure the XSRF header name, which is what they're calling it on their side, the configuration stopped working. And so our override that says this is what our CSRF or XSRF token should be called when it's sent back up to the server in a header that was getting lost. And so they were falling back to their default name, Axios was. And, therefore, Rails was like, "There's no CSRF token here. So this is going to be a no for me. I'm going to reject all of the requests."

+ +

So the fix was relatively easy to roll back and to pin the version of Axios to the previous version that we had been using. I didn't actually intend to upgrade it. I just intended to make it an explicit dependency. But by doing that, I accidentally upgraded it. I don't love that there was this pretty deep breakage in that. I haven't done the good work of trying to open an issue. I still want to scan through and see if there is an open issue or a conversation around this before I start making any noise. But I think if I don't find anything, this is the sort of thing that should be reported because I can't imagine I'm the only one running into this.

+ +

Likewise, I was very sad that my test suite did not find this. Turns out in Rails, CSRF protection is just turned off in test mode, which may be overall makes sense. But for feature specs, in particular, I definitely want to have it. And so, it was nice that I was able to find the relevant configuration. And we introduced an RSpec configuration that says, "If it's a feature spec, save off the existing configuration and enable CSRF. And then after the spec, go back to whatever the previous was."

+ +

So now all feature specs run with CSRF. And I did make sure to push up that as a singular change to CI, and CI was very unhappy with me. Many, many features-specs failed, which was good. That was what we were going for. They failed for the right reason because things were fundamentally broken. And then, I was able to update the package-lock or the package.json on the yarn lock, pin the version, fix everything.

+ +

But man, there was this period of like, oh man, the app is broken in such a fundamental way. Users just can't do stuff anymore. They can view anything, but they couldn't change any data. And it just snuck through CI. And that feeling is the worst feeling. We had, at this point, built up a lot of trust in our test suite. It was really telling us when stuff was wrong, and if it was green, I felt very good merging. And suddenly, this just really shook me to my core on that front.

+ +

STEPH: I love these journeys that you take us on. I mean, they're painful for you, and I am sorry to hear that. But I love these journeys that you take us on. [chuckles]

+ +

CHRIS: I usually only take us on them when I've figured out the answer. And I'm like, all right, here's where we're at. It was rough for a little while, but now we are happy. And thankfully, the one configuration of saying, hey, Rails, also, please include this as part of our production like, configuration for test mode. So I feel better that moving forward, this breakage won't happen again.

+ +

STEPH: We should add that as another merit badge for telling a bug story. All right, I'm taking off my hat of chief of fun and cuteness. So this may not be terribly relevant to all the things that you just shared. But I am curious where you mentioned that with Axios because you'd specified the name of the token, and then that overriding behavior is what then broke. And so then that's what led to this whole adventure that you went on. I'm curious, why did y'all customize the name of that token?

+ +

CHRIS: A, this is a great question. B, I'm not super sure. C, I think the reason is because we were trying to align to Rails. So we have a little middleware on the Rails side that will serialize the CSRF token into a cookie. And then that cookie value gets read by Axios and sent back up as a header on the request. So this is the way that with Inertia CSRF just kind of works and is good. And it's different than Rails' normal. We put a hidden input into any form. And so Rails holistically knows about both sides of that, and everything works fine. But now I have to manually round trip the CSRF token.

+ +

And Axio's default configuration is a header name X-XSRF-TOKEN, and we needed X-CSRF-TOKEN because that's what Rails is looking for. I probably could have configured it the other way on the Rails side. But one way or another, I had to get Rails and Axios to come to an agreement, to meet at a table, and to agree to collectively protect the app. And so I had to mediate that discussion, and that's what ended us here.

+ +

STEPH: A meeting of the minds. [chuckles] Cool, cool, cool. Yeah, that makes sense. I was just curious because then that would have changed the whole journey. But yeah, that is super interesting. And I definitely resonate with the idea of when you've really invested in your test suite, and you trust it that then when it doesn't catch something that obviously breaks the application, then that feels like something worth prioritizing and digging into and then figuring out how to bring back that parity.

+ +

I don't know that I've turned on enable CSRF for feature spec. So I'm also very interested in looking at that configuration and considering if I need that for any of my future client projects if that's something that I need to remember for the future because that's very niche but good to know about.

+ +

CHRIS: I feel like this only really comes up if you're working in the...it's called the odd middle ground that Inertia ends up occupying. If you're in a traditional Rails app that is generating HTML server-side, forms are generated. They got the CSRF token inlined there in a hidden input. And then when you post that form, it's coming back up. The names automatically are going to match. You don't need to worry about it. And it's probably fine to not have it included in test mode.

+ +

And if you're at the other end of the spectrum and you've got API interaction, and that's the way you're doing everything, then you have a different auth mechanism and cookies, and whatnot just don't apply in the same way. And so it won't really matter on that side but for a different reason. And it's only because we're in this interesting middle ground, which, again, I really love. And it's the thing that I love about Inertia. But this is a rare case where it's like, oh, we do have to bring the two sides to meet in the middle. And this is a case where, unfortunately, due to a very subtle breakage on a minor release of...a package that we're using silently broke so, yeah.

+ +

But yeah, thankfully, everything is back to working. And again, we've been able to enhance the test suite in that little way that I feel confident again because this won't sneak in another time. We have coverage around this. We're good to go. So while I was very scared when this initially happened, I feel better now. I'm happy to go into the weekend feeling better about this. But that's my story. What's new in your world?

+ +

STEPH: So I feel like I've been having one of those weeks where I have less code adventures. In fact, it's one of those days where I went to thoughtbot's daily sync...because we often have our client daily syncs, but then we still have a thoughtbot sync as well. And I went to the group, and I was like, I get to write code today. It's going to be a great day. All the other things I'm doing are also interesting, but I get particularly excited when I get some maker's time and get to write some code.

+ +

So I feel like I've had less coding adventures recently and more hiring and process-related adventures. And specifically, I just completed the Plucky Manager Training, which is a program that's founded and led by Jen Dary, who was recently on thoughbot's podcast, The Giant Robots Smashing Into Other Giant Robots. I'll be sure to include a link in the show notes for anyone that's interested.

+ +

CHRIS: I believe this was the third time she was on. It's at least the second, possibly the third. And all of them are great listens, just as an aside, so we should include links to all of them.

+ +

STEPH: Yes, I think she's one of the rare guests that has been on the show three times. And I think I've only listened to the first couple minutes of that episode. But I think they talk about the fact that this is her third episode, which is really, really cool. And I'm still frankly synthesizing all the information and the ideas that I've collected from the course.

+ +

But I do have a few quick takes that I'm interested in sharing with you. So the first one is my cohort...we were the Panda Cohort, so go, Pandas. And some of the things that we talked about were…, and I think that this may have been the first day. So it was three days, and it was three hours for those three days. And they're spread out over a couple of weeks, which is really nice because then you show up for those three hours of the class, but then you leave with some ideas and some things to experiment with. You get a week to then try out an experiment and then come back to class next time and talk about this is how it went; it went to wonderful, or it went terrible. And you get to share that with others and work through it.

+ +

And in the first class, we talked about coaching versus managing, which I found just a helpful definition to review. So managing is more direct, and telling someone what to do while coaching is encouraging someone to determine their own path and find their own solution. And I find that as a team lead at thoughtbot, I'm very often more in that coaching space than I am in that managing space. I think it's frankly pretty rare that I actually need to put on a manager's hat. And I often feel like I'm wearing my coaching hat instead.

+ +

And some of the other things we talked about one of them is what is work? Which is a fun question to ask. And Jen had an analogy for this speaking about imagine that you have a plastic Easter egg. So it's got two sides, and side one is all the skills and desires and things that you're fulfilled by. And side two is a company that needs those skills. And it's great when those line up and click together, like when you take a job or get a promotion. Have you ever played...do you know what I'm talking about? Those little plastic Easter eggs. Have you ever played with those as a kid?

+ +

CHRIS: Yes, certainly.

+ +

STEPH: [laughs] I realize I just launched into that analogy. [chuckles] And then Jen goes on to say that's totally normal for then those sides to unclick. And Jen continues to say that it's totally normal for them to unclick. So maybe the company changes direction, the company is acquired. You've fallen out of love with something that you do about your job, or you have kids, and that has changed the things that you are fulfilled by and what you're looking for. And that's not necessarily bad. So it can be like, hey, you are working on x now, and you're not fulfilled by that anymore. But then another company comes along and says, "Hey, we're working on this, and you are fulfilled by that." So then another click happens.

+ +

And essentially, it's a nice analogy to represent someone's career path and the ways that we are going to shift and re-prioritize what we're interested in. But it's also a really nice way to help it feel less personal because both sides are allowed to change. The company can change. You, as an employee, can change. And then you can look for that next click that is going to match up with a company that meets your skills and things that help you feel fulfilled.

+ +

One of the other topics that we talked about are hard conversations, which I love that we dug into this one because that's certainly one that I struggle with or...I mean, we all get that feeling if you have to confront someone if you have to have that uncomfortable discussion with someone. It is a very hard thing to do. And so we had some very honest conversations around what is a hard conversation? What does that represent? And essentially, they represent that there is stalled progress and something can be improved.

+ +

So Jen likens a hard conversation to a tool. It's something that you can use to then help something move forward again if something feels stalled or if there's something that needs to change. And during those hard conversations, you may not get to the resolution that you're looking for. So you may be looking for a specific outcome. But you also have another person that needs time to respond and to take in everything that you have said and process that information.

+ +

So when you have a hard conversation, you may actually only move forward an inch. So if you had a lofty goal of we're going to talk and then we're going to have this hard conversation, and we're going to get to this space...But instead, you actually just make incremental progress. Like, okay, at least this person is now aware of this concern. That might be your win for the hard conversation versus actually tackling; how are we going to address it? I just want them to be aware of this concern.

+ +

And it's a very vulnerable conversation, and they often take time before you can get to that ideal resolution. But essentially, the idea is get in the game, start the conversation, and then have follow-up conversations for that hard conversation. And I really appreciated that framing because I often will think of hard conversations of oh, we have to have this hard conversation and get to this specific outcome. But if you shift the goal line to be like, no, I really just need to at least make this person aware of a concern, that makes it a lot more approachable. And then also probably yields more fruitful outcomes because that gives the other person time to think about what you've shared to also come to the table with their own ideas and then work together to then get to that ideal resolution.

+ +

CHRIS: I like that framing a lot. I can definitely see the case where you, as someone who has recognized something that needs to change (perhaps you're a manager),lineup you've now thought about that a good bit; you've observed it, but the individual that you're bringing that to this may be novel. This may be a surprise for them. And so if you come into that interaction both about to share this information but then also trying to resolve it and trying to get to I need you to internalize it, and I need you to fundamentally change your behavior as a result of this conversation we're going to have, that's quite possibly not a realistic outcome. And if you're trying for that, it might inherently lead to just a bad outcome because that individual is not in a position to do that. But they are potentially ready to hear it. And so you can just achieve step one and then later have step two. So I like that a lot.

+ +

STEPH: Yeah, in general, I found the course incredibly helpful, very insightful. It was also really nice to hear from other managers that are facing similar problems or perhaps novel problems and then getting to weigh in and help each other. So it's a wonderful course. I'll be sure to include a link in the show notes for anyone that is interested. And I'll probably come back with some more insights from the class because it's really...we just wrapped up. So I'm sure I still have some ideas that will percolate over time, and I want to come back and share those with the group.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Pivoting just a bit, we have a listener question that I'm excited to dive into. This question comes from the one and only, the Edward Loveall, fellow thoughtboter. And Edward wrote in, "How does the process of software development change at different team sizes? What's a process that breaks down soon after the team starts growing? What's a process that is resilient at all sizes? And by process, I mean anything that involves other people including organizing tasks, code review, deployment, or anything else that isn't you alone writing code in a vacuum."

+ +

I'm really excited about this question because I think there's a lot here. And there's actually one part that I'm struggling with a bit, so I'm curious to see what you think, Chris, about it. But I'm going to start off with saying that I think there are a number of management processes that definitely break down as a team grows. But in the spirit of Edward's question, I'm going to focus more on the software development process and how those might need to change and what starts to break as your team grows.

+ +

So starting off with processes that break after the team starts growing, this one, frankly, what really starts to break is not a process specifically, but it's the lack of process that really starts to become visible and painful. So, how do we track work? Before, maybe the product manager or someone would just send you a message and say, "Hey, can you work on this?" or "Hey, can you fix this thing?" And how does code need to be reviewed before being merged? Does it need to be reviewed? Are people just merging as they get stuff done? How are deploys performed? Oh, we have a super urgent production fix that needs to go out, and the only person that knows how to deploy is out sick today? Cool. That's the type of process that I think that really breaks down, or at least you start to notice when the team starts to grow. What are your thoughts?

+ +

CHRIS: I definitely feel that first one very strongly. We're feeling it right now on the team, which is still very small. There are only three developers working on the project, and then we have a product manager. And each week, we're slowly iterating, and tweaking, and honing, and trying to introduce just enough process in terms of how we define the work to be done, communicate the status of it, all of that fun stuff.

+ +

We started with Trello. And we just had a board with some columns, and then we had more columns, and then we got rid of a few of them. And then we recently added a Power-Up to the Trello board, which allows for epics. So there are cards which are epics which tie to sub cards. And I'm staring at it, and I'm like, how long until we're Jira? How long can I hold out here and not be Jira?

+ +

But it does feel like we're slowly iterating towards a more useful process for this team rather than process for process' sake, which I feel like is a really useful distinction. There's also a question of like, what can be known or what can be adequately measured and whatnot versus what can't be? So we've talked many a time on the show about estimation and velocity and trying to track that and the pitfalls inherent with that. And so there's, in my mind, two different camps. There's the process we want to avoid. And again, to reference German Velasco's wonderful blog post, Say No To More Process.

+ +

And I really feel like there is a tendency often when things go wrong to then try and paper over that with process. Oh, this team didn't use the design system. So we need to write ESLint rules to make sure you can't import from the directories that aren't the thing. And it's like, we can do that, and I've definitely done that. And I will do that again in the future. But I always have the lens of do we need this? Is it worth the trade-off, the cost, the overhead, the complexity that it's bringing in?

+ +

But definitely, organizing and communicating tasks is one of the ones that becomes really difficult. The more people that are working on something, the more you need probably more than one person staying out in front of them and trying to define the next bit of work that needs to be done after that.

+ +

Code review feels like it probably should stay similar, with the exception that I lose the ability to review all code at some point. Right now, I'm trying to review every single PR that goes through or close to it. At some point, I'm just going to have to give up on that. But for now, that's my goal. But fundamentally, code review, I think, will hopefully take the same shape.

+ +

Deployment, similarly, like, I've talked about the merge queue thing. I want to get a little bit of process in there but not too much. There is definitely some necessity for change. But I definitely want to resist the urge to change everything and to just say, like, slowly over time; we’re going to have to be a big Byzantine organization with lots of rules and standard operating procedures and all of that.

+ +

I've heard anecdotally, and I don't know if this is true, so maybe someone out there on the internet can correct me if I'm wrong, but my understanding is that at Google, they’re pretty tight in terms of what languages and frameworks can be used and what processes, and workflows, and build tools and all of that whereas Facebook, as a counterpoint, is relatively lax. Obviously, React is used very heavily on the core web application. But there's some flexibility in terms of different languages and frameworks and things for sub-projects or small individual teams having a little bit more autonomy. And I think that's a really interesting thing of are you one large, cohesive, organized company or do you try to act like a bunch of small disparate but roughly connected teams that share good ideas but can work independently? And that changes how I would think about this question.

+ +

STEPH: I really like how you're describing the addition of process. It sounds like a just-in-time process. So as you're learning that something needs to be added, then that's when you look for answers. And then you sprinkle on a bit of process that everyone agrees that feels very helpful within also the right to review and see if that still makes sense for the team.

+ +

There's one additional area where I think the lack of process really shines through in addition to the number of ways that you've mentioned is also onboarding. So if you have a very small team and you are onboarding, it's likely that...Chris, you can let me know if I'm wrong, but when someone's joining the team, there's probably a good chance that they get to pair with you at some point, or they even get welcomed by you to the team. And then, they get an overview of the product and the codebase. And there's probably this really nice session where they get to ask you questions, and then they have that onboarding session. Does that sound about right?

+ +

CHRIS: Yes. But I would go so far as to say it's not just a day or a session, but it's probably a couple of days. So yes, and.

+ +

STEPH: That's even better. And with some of the smaller teams that I've seen, that onboarding process is where they are pairing with that lead person on the team. And that's going well until suddenly that lead person can't pair with everybody. And nobody has really thought about how to streamline that onboarding or how to coach or teach someone else to be a really good onboarding pair.

+ +

And I have strong feelings about this area because we often focus so much on hiring, but then we drop the ball when it comes to onboarding that new, wonderful colleague that we've worked so hard to recruit. And at the end of that day, someone's going to reach out to them and say, "Hey, how was your first day?" And it makes a big difference for that person's retention as to how those first couple of days ago.

+ +

So I think onboarding is another really important part that when you're a smaller team, you probably don't need much process because you have more of that personable onboarding experience. But as the team grows, there needs to be more of a process to help other teammates join the team.

+ +

CHRIS: It's interesting. I think I totally agree with you that over time, there is a necessity to be more intentional and to have a little bit more structure in the process. And I don't think you're saying this, but I just want to make sure we are saying the thing that I think we believe, which is that shouldn't replace the human that helps you onboard.

+ +

Like, I still like the idea that everybody gets a pair for some amount of time when they start at a new company. And you're working together on a feature, or you're working together on bug fixes. You're shipping to production as soon as possible. But you're not doing that based on some guides in a wiki. You're doing that with another human that's helping you. There should also be guides, and a wiki, and documentation, and formalization as the organization grows but not in place of having another person that you get to talk to.

+ +

STEPH: We're just going to send you a little yellow rubber duck and then with a little Post-It note that says, "Good luck [laughs] with your onboarding process." Definitely. I agree with everything you said. It does not replace that human element where there's someone that's helping you onboard. I just see that onboarding is one of those things that gets forgotten, or we often point someone to a README which I do think is great because then it is battle-testing our README. But then there still needs to be someone that is readily there to say, "Hey, how's it going? What are you struggling with? Can I pair with you?" There still has to be that human element that is helping guide you through the process.

+ +

And I think smaller teams may forget that they actually need to assign somebody to you to make sure that you have someone that you know. Like, hey, this is who I can reach out to with all my questions. Because they're probably not going to be comfortable posting in the company channel at that point or a larger communication to say, "Hey, I'm stuck on something."

+ +

CHRIS: There's one other area that comes to mind, or I guess it's more of an anecdote that I have heard, but it speaks back to GitHub's early, early days. And they were somewhat famous for being very flat in terms of the organization and very self-organized, and everybody's figuring it out, and you're working on the thing that's most important in your mind. And for a long time, this was a celebrated facet of the company and a thing that they talked about rather publicly.

+ +

And then I think there was this collective recognition, and maybe they reached a tipping point where that just didn't work anymore. Or maybe it actually hadn't been working for a bit, and there was just the collective realization of that. But it was interesting to watch from the outside as GitHub added more formalization, more structure, more managers, and hierarchy, and career ladders, and things of that nature. And I think there's a way to do all of those things in a complicated, overloaded, heavy way.

+ +

But I think a different version of it is...like, you were using the word coaching earlier. Having formal structures within your organization to encourage people on their career path, to help them grow, to have structure around that, I think is a really difficult thing to get right. But I think it is critical, and I think just not having it can't be the answer past a certain probably pretty small size. So that is an interesting one where I think you do need to introduce some process and formalization around how you think about the group of people and how they work together within your organization.

+ +

STEPH: I agree. I think where some folks may see a lack of hierarchy; others feel a lack of support. And adding levels of management should really be focused on the outcome is that we're helping people feel supported. So even getting feedback as you're adding those different levels of management, like, hey, did we make your life better? Did we make your life worse? I think that's a great question for management to ask as they're exploring a less flat structure.

+ +

CHRIS: So, Steph, I have a question for you now on a variant of this topic. In general, we seem to be fans of having a codebase. Probably a Rails app that’s got a database behind it, and that's where you put the data. Everybody commits to that same repository. It's all kind of one collected thing. And often, organizations grow to a certain size, and they're like, this is untenable. We cannot have this many people working on this same codebase. So we shall do the logical thing, which is we will break it up into small pieces. And those pieces will communicate over HTTP, and it will be great because then our teams can be separate from each other and can manage their little piece of the world. What do you think about that? Is there truth there? Is it not true at all? What do you think?

+ +

STEPH: All right, so your team is getting too big, and to the point that you feel like you need to split it out so then you can have small teams, and they can all work independently on different parts and services of the codebase. I don't love the idea. I'm trying to think through because I feel like there's a lot of nuance here. But I don't love the idea that that's the driving force as to why are we making the change?

+ +

And that is often a question that comes to mind whenever we are making a big change, either architecture or process-related is like, what's driving this? And then how are we going to measure it? And if we are driving it just because we have a large team, let's talk more. Why are people blocked? Why can't people work together? What's preventing people from being able to contribute to the same codebase? Are people blocked for a long time because they're having to wait on someone else to complete that work? I have a lot of questions that I don't know if I can fully answer your question. But my instinct is to say let's not break up the architecture just because our team grew in size.

+ +

CHRIS: Yeah, I think I definitely agree with that. There's probably a breaking point where it's just too many individuals, and there'll be too much contention. But I think resisting that or at least naming that as like, okay, that's what we're saying but is that really what's true? Or are we actually feeling that this system is so deeply coupled that there's no way to change some small piece of the code without impacting other parts of it?

+ +

Like, is the CSS completely untenable because we're just using global class names, and it's leaking everywhere? Okay, do we need a different solution there? And then it's actually fine. We don't need to have different services that have their own different style sheets. We just need a different approach to CSS. That's a particularly easy one to go for because there's inherently a global namespace there. But the same thing is true in a lot of different contexts. So services are a way to break things apart and enforce those boundaries. But if inherently coupling is your problem, then you're just going to be coupled over HTTP, and I think it's going to be difficult.

+ +

There's a wonderful blog post by Josh Clayton, which I think does a better job than I'm doing in this moment of highlighting some of the questions I would want to ask. The blog post is titled Services are Not a Silver Bullet. And so Josh goes through and enumerates a bunch of the different versions of the story that he's heard throughout the years of well, we need to go to services because x, because our test suite is slow because pull requests are constantly having merge conflicts and whatnot, because the code is very deeply coupled and any change here affects everything else. And a fix over here broke something over there. This is no good. And so he does a really good job of presenting alternatives or at least questions that you can ask to say, like, is this the problem, or is this a symptom? And we need to address the more underlying cause.

+ +

And so I think there is a point where you just can't have 1,000 people trying to commit to the same Rails codebase. That feels like it's maybe too big. But it takes a while to get to 1,000 people. And there will be times where extracting a service makes sense or integrating with an external service that exists. Like, I've talked about Stripe before as my canonical like, yeah, it's actually deeply intertwined with the data model, but they're just dealing with such a distinct complexity set over there. And they have such expertise on that that I'm happy to accept the overhead of the fact that that service lives outside of my core application, and I need to deal with synchronizing state and all of that. I will take on that complexity, but it's not worth it for everything, and it's not a silver bullet. Again, to reference the name of Josh’s blog post there, Services are Not a Silver Bullet.

+ +

And so, coming back to Edward's original question, I would say that having a monolithic codebase works for a really long time, but there is probably a breaking point somewhere well along, but fight it for as long as you can. I think.

+ +

STEPH: I really like how you touched on coupling because it really helps ask those questions to get to the heart of what are the pain points that you are feeling? And it is less of a decision that is based on people and process but more if you're going to split out a portion of your architecture. It is in response to an actual business need and a business value versus some other pain points that you're trying to fix.

+ +

A particular example might be like maybe you have a portion of your application that really just needs to spend a lot of time crunching data. And it's really not as specific to your application; it's something that can happen on its own. And then it's beneficial to move that outside so it can scale and relate it to the work that it needs to perform versus keeping it in-house with the application.

+ +

I do want to circle back to another question that Edward included which is what's a process that is resilient at all sizes? And the ones that really come to mind for me...and these are a bit amorphous intentionally because it will look different for each company. But three areas that are very resilient at all sizes, whether you are 1 to 2 employees versus you've got hundreds or thousands it's communication, testing, and accountability.

+ +

So communication, where are we headed, and how do we know what we're working on? For testing, it's how do we test our changes? Do we write tests? Do we use QA? Do we have a staging environment? What does that look like? What's our parity between staging and production? And then how do we know what's in progress, and how do we know when it's done? Those are three core areas that, regardless of your team size,,I think are very crucial to the team success. What do you think? What are some of the processes that are resilient at all sizes?

+ +

CHRIS: I actually really like the list that you just provided. That is a wonderful trifecta, and I think it will take you very far, so probably not much to add from me. But I guess on that note, should we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+0tC_zKYf + + ]]> + + Chris Toomey + Steph Viccari + + + 313: Forty-Seven Percent + https://bikeshed.thoughtbot.com/313 + 9eb62c4c-a056-4f91-beba-c007eadc80a4 + Tue, 19 Oct 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph talks about binging a few Things Worth Learning podcast episodes and particularly enjoyed an episode that featured one of thoughtbot's design directors, Sameera Kapila. Sam shared her expertise about management and inclusion, and Steph shares her favorite parts. + +Chris shares the story of a surprising error and the resulting journey through database transactions and Sidekiq that eventually resolved the issue. He also shares some follow up on the broken build and the merging process changes they introduced (spoiler, the process changes have been rolled back). + 42:05 + no + + + Steph talks about binging a few Things Worth Learning podcast episodes and particularly enjoyed an episode that featured one of thoughtbot's design directors, Sameera Kapila. Sam shared her expertise about management and inclusion, and Steph shares her favorite parts. +Chris shares the story of a surprising error and the resulting journey through database transactions and Sidekiq that eventually resolved the issue. He also shares some follow up on the broken build and the merging process changes they introduced (spoiler, the process changes have been rolled back). +Leading Inclusively, with Sameera Kapila - Things Worth Learning Podcast (https://www.youtube.com/watch?v=eiV6_3pZFc0) +How to Skim a Pull Request (https://thoughtbot.com/blog/a-smelly-list) +Isolator (https://github.com/palkan/isolator) +aftercommiteverywhere (https://github.com/Envek/after_commit_everywhere) +timefora_boolean (https://github.com/calebhearth/time_for_a_boolean) +Transcript: +STEPH: Oh man, I'm about to stop eating my pop-tart. I'll put it away. It's within distance. I'm going to eat it. +CHRIS: Your high-fat content unfrosted pop-tart. +STEPH: You know, surprise Sunday twist: it has icing on it. +CHRIS: Steph, who even are you? +STEPH: [laughs] +CHRIS: There are a few canonical anchor facts that one knows about other people, and when one of those... +STEPH: I like to keep everyone, including myself, on their toes. +CHRIS: Or you've just secretly accepted that the icing adds another textural flavor adventure component. It's just better with icing. +STEPH: All right, all right, all right. There's a complicated answer to this. And the complicated [chuckles] answer to this is that the more organic ingredients that I recognize when reading about pop-tarts are by a particular company, and they all have frosting on them. And the more generic pop-tarts that don't have frosting on them, I don't know how to pronounce a lot of those ingredients. So I'm like, no, but okay, I still eat them. But I prefer the ingredients I can pronounce. So I either go with the ingredients I can't pronounce or have a little bit of frosting on my pop-tart. And I'm going with the non-cancer route for today. +CHRIS: For today, in this moment, and accepting the frosting. Okay, all right. Well, that is complicated. [laughs] It's tricky out there. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey, Chris. So the weather, I'm going to talk about the weather for a little bit. [chuckles] It's been almost non-stop rain for the past several days, which is fine. I'm sure it's great for plant life. But it's really hard on my dog Utah because then we can't go outside for our normal walks and playtime. Although he is my four-legged water baby because he absolutely loves water, and puddles, and playing in the rain. So he's very fine with going outside and playing for a long time. But then I have to essentially give him a full-on bath before I want to bring him back in. +So not wanting to have to give him a bath each time, in the spirit of improvising, we started finding more indoor games to play. And I've started teaching him to play hide and seek. And he's not great at it mainly because he will only stay until I'm out of eyesight, and then he will come and find me. And so I have to be really, really fast at finding a hiding spot to like dash around a corner or hide behind the door. But I think he enjoys it because he will find me and then he seems very excited. And we go back, and we play again. And so I just have to work on teaching him to wait a bit longer so I can find better hiding spots. +CHRIS: When you said that, at first, I was like, how did you teach him to hide? But I realize he's only playing the seek part of the game, and you're only playing the hide part of the game. +STEPH: [laughs] +CHRIS: I'm just so used to you exchange roles back and forth. First, you hide, then you seek, and then you switch it up. That would be a lot to get your dog to be like, now I'm going to secretly hide. +STEPH: [laughs] I'd be very impressed. Yes, we have very distinct roles in this game. I am the one that always counts and hides. But he's a very good seeker. So that's been fun. We just got to work on getting a little better at it. +But on a more tech-related note, one of the design directors at thoughtbot, Sameera Kapila, who also goes by Sam, was a guest on the podcast Things Worth Learning, which is hosted by Matt Stauffer. And Matt is also the host of The Five-Minute Geek Show and The Laravel Podcast. And in the show Things Worth Learning, Matt meets with individuals that are excited to share something that they're deeply passionate about; maybe it's tech, maybe it's not. And I've binged a couple of those episodes. +And I really like how you can choose between the podcast format or the YouTube format. So then you can really watch the conversation unfold, which I know you and I a couple of times have thought it would be fun if people could see us because there are so many facial emotions and gestures that go along with conversations. So it was really delightful. +And speaking of delightful, Sam shared her expertise about management and inclusion. And I definitely recommend listening to the episode because I can't share everything that Sam shared. But a couple of the topics that Sam mentioned that I really enjoyed and would love to chat about, so the first one is about helping someone, in this case, someone that you manage that comes to you with a concern. +So there's often a presumption that just because someone comes to you with a concern or an issue that they've experienced at work, that they're the ones that will also want to work to address that concern, and that's often not true. It can be true; maybe that person wants to be involved. But they're often coming to you in the leadership or management role to say, "Hey, I've had this issue," and they really want help with that instead of walking away with homework for it. Because then that trains people to essentially be in this mindset of well, if I bring up this concern, then I'm going to be the one that has to address it, even if I'm the one that's most negatively impacted by this. And addressing this concern could be actively harmful to me. +And she shared a really great real-world example from her own experience where her and another co-worker had noticed a concern about the hiring process. And her and that co-worker got together, and they talked about the concerns. They even rehearsed for the meeting because they were trained by the tech industry to say, "Hey, if you bring up a concern, you're going to be responsible for addressing and then resolving that concern." +And so they had that meeting with the person in leadership. And they were pretty nervous about how it was going to go. And that person in leadership said to them, "Thank you both so much for sharing that. That must have been such a burden. And this is my responsibility to fix. And here are what my next steps are." And that was amazing because it allowed Sam and the other person to go back to client work. And they also received follow-up conversations about how that issue was being addressed. So there was even that feedback loop as to how things were going to change. +And I have a personal example that...I really resonated with the example that Sam provided because I remember there are different teams that I've been a part of, where often I was one of the few women engineers on the team. And so we often have conversations about how do we get more women engineers into the company? And they're wonderful conversations. +But there's a part of me that always felt resentful about, like, why am I here? Why am I the one fixing this? I understand I have some more insight and expertise, and experience in this area. But I was also frustrated by the fact that I was the one that was in that meeting often with other women, and it felt like our responsibility to fix this. And I used to feel bad about feeling resentful towards that. Because I was like, shouldn't I want to help other people? And I do. But Sam's example really helped remind me and clarify that yes, just because there's a concern doesn't necessarily mean you should be the one to address it. And it really takes everybody involved, or it takes leadership to step up and address that concern. +CHRIS: Oh, that's really interesting the way Sam is framing that and describing the situation of not having any problem that you bring in be now your work to solve. Like, oh, I found the issue, and now we've got to go do this. But the idea that you can bring something to light and then be able to walk away from it. +And the particular thing that you were saying that if your interaction is always that when you reference something when you bring in a concern that then your manager works with you to figure out how you can solve it, then you get this mental block of like, well, do I even want to say anything? Because I don't want to try and deal with big, amorphous unclear issues. So maybe I just won't even say anything. +And so this as a way to make sure that there's room for all of the conversation is a really interesting framing that I hadn't really thought about, frankly, but it's very interesting. I haven't seen this interview either. So I'm definitely excited to give this a look because Sam is wonderful. And the topic that you're describing here sounds fantastic as well. +STEPH: Yeah. There was an important moment for me where...one of my managers is Matt Sumner, who's been on the show. And when Matt was my manager, at one point, we were having a one on one, and we would often go for walks for our one on one. And I mentioned something about "I have this concern, or I have this problem, but I don't really know how to fix it. So I'm not sure I'm ready to talk about it." And Matt, in his delightful way, was like, "We can still talk about it. You don't have to have an answer or a solution." I'm like, "Yeah, but I feel like I should be able to fix it. Like, if you have a concern, or if you have something that you want to gripe about, then you should come to the table with solutions for it." And Matt was like, "No, you don't need to do that at all. We can totally gripe about stuff or talk about concerns and then either figure out the solutions together or go to other people for ideas." +And that was really important to me because, like you'd mentioned, otherwise, it felt like this mental block where then it feels like you can't air out some of the things that you're worried about or have concerns about because then you think you're the only one responsible. And you may not be able to come up with the best solution. You may need other people to then help you strategize and come up with ideas. And I just love, love, love that part of Sam's discussion. +And oh, there was one other part about the conversation. Well, there are lots of parts that were amazing. But another one in particular that blew my mind is about Comic Sans, the font, the font that everyone loves to hate. [chuckles] And I learned that it's one of the most legible fonts for kids. And it's one of the more accessible fonts for people with dyslexia. And it's actually recommended...I think there are still more academic studies that need to be done to really classify fonts that are best for people that have dyslexia. +But Comic Sans is recommended by The British Dyslexia Association and the Dyslexia Association of Ireland. And there are some other really great posts that talk about the benefits of using a font like Comic Sans because the typeface has long ascenders and descenders and generous letter spacing and asymmetrical lowercase b and d to then help distinguish those letters. And I just thought that was so cool. This font that everybody wants to rip apart because it seems whimsical, unprofessional gets overused. There are lots of reasons, I suppose. [laughs] But there's a really big benefit to it, and it can help others. And I just found that very whimsical in itself. +CHRIS: I love the idea that there are multiple levels of knowing about Comic Sans. First, you're just like, I don't even know the name, but it's that comic book-looking font. And then obviously, the next step is to be like Comic Sans? How could you ever use that? It's an atrocity. And then it's like, but actually, Comic Sans has some things going for it. And it is a really interesting consideration and something that you wouldn't necessarily think of. But then once you learn it, you're like, okay. Man, I wonder how many other things in the world have this interesting shape to them? Hmm. +STEPH: Do you know the history behind Comic Sans? +CHRIS: I do not. +STEPH: I read about it fairly recently, but I'm probably going to botch some of the details. But I believe it was designed or created by Vincent Connare. And it was created for Microsoft. And Vincent was working on a project where I think there was a dog that was essentially going to have these bubbles that would then show you different parts of the application and walk you through the different features. And the dog had a very comic book feel to the character. +And so then Vincent designed a font to go along with that comic book character, this dog and came up with Comic Sans. I don't think the dog actually launched with that particular font. But since the font was still developed, it was released as part of the available fonts. And there we go, there is the birth of Comic Sans. And then it just received so much love and ire all throughout history. [chuckles] +CHRIS: There's something that you said there that I want to loop back on when you were talking about chatting with Matt Sumner and saying, "Here's this thing, but I don't know how to solve it. So I don't even want to bring it up." I really liked the framing that you gave and the fact that Matt was like, "No, no, we can still talk about it. We can at least explore this thing, have a conversation." I think that's really wonderful. +There's a very similar thing that I experience a lot when doing code review, particularly when I'm in more of a leadership role within a team, which is I often want to highlight something that feels a little bit off to me in the code, but I may not have a specific solution. Like, I may see a variable name, or I may see a controller action that feels like it's the wrong shape or something. And I'll often name it but explicitly say, "I actually don't have a better idea here. So feel free to continue on with this, but I want to name it. So in case that sparks something in you, if you were also feeling some incongruousness, maybe it's worth you spending another minute to think about it, but I want to make sure my comment isn't blocking or otherwise making you feel uncomfortable." +If I just come to you and I'm like, "This feels wrong," and that's all I say, that to me is unacceptable code review. Because now I want all of my code review feedback to be very actionable, it’s either here's the thing that I feel strongly I think we should definitely change this. If you disagree, let's have a conversation. But yeah, this one definitely needs to change. Here's the thing that, like, I don't know, maybe we could break this into two lines and split it up. But if you don't like that, that's fine. Do whatever. And so then it's I've given the person my thoughts but given them clarity and a free rein to do whatever they want with that information. +And then there are ones where I'm like, I don't even know what I think we should do here, but I think something. But if you don't have any ideas...like, I don't have any ideas specifically. If you don't have any ideas, it's fine. We'll continue on with this and maybe revisit it down the road. But I want to make sure each of those different tiers is actionable for the other person, and I'm not just giving them homework or something to be sad about because that would be bad code review. +STEPH: I'm just imagining a PR comment that says, "I don't know what we should do here. But I don't think this is it," [laughs] and that just creating sadness. That's so interesting to me because I have flip-flopped with that opinion in regards to there are times that I very much resonate and do what you just said where I will point out to someone where I'm like, "I'm not sure why, but I just have concerns about this. And I don't know if you also ran into anything that was weird about this and would like to talk about it. I don't have any really great ideas, so I think this is good for now. And we should keep moving forward, so we're not blocked on it," but just wanted to, as you mentioned, highlight it in case it sparks something for the other person or for someone else that's reviewing the code. +And then there are other times where I'll look at something, and I'm like, "Yeah, it's not great. There's something that feels brittle or potentially maybe hard to maintain or things like that. But I don't have a better idea." And I don't comment on it because I'm like, I don't want to distract that person or block them. And I do think it's good enough, and I don't have anything to add to the conversation, so I just leave it out. So it's interesting to me where is that line of when I feel like it's important enough to comment to then potentially spark some conversation versus just letting it go so then I don't add any distraction to their work? +CHRIS: I think it's when the spidey-sense gets past 47%. It's a very specific number. I do the same thing where there's something, and I'm like, you know what? I can't even clearly express what about this makes me feel something off, and so I won't even comment on it, and I agree. And then there are things that trip past some magical line in the sand. And I'm like, you know what? I think I'm going to say something here, but I don't even have a recommendation. And then there's a whole spectrum of the nature of code review and, again, 47% being the specific number. +STEPH: There's actually a thoughtbot blog post that correlates nicely to that concept of spidey sense. It's written by Mike Burns, and it's titled How to Skim a Pull Request. But essentially, grabbing from one of the lines here is where Mike presents an unexplained, incomplete, and arbitrarily grouped list of keywords that will cause us thoughtboters to read your code with more care and suspicion. [laughs] That feels perfectly aligned with that idea of spidey sense, spidey-sense 101. I'll be sure to include a link in the show notes. Or, you know, 40%. +CHRIS: I think it was 47%. It's a very precise number. [chuckles] +STEPH: Very precise nonsensical number. Got it. [laughs] +CHRIS: If I'm making up fake statistics, I'm not going to have them round to an even 10. [laughter] +STEPH: Makes it seem more legit somehow. +CHRIS: Exactly. +STEPH: But that's really the novelties that I wanted to chat about. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: What's new in your world? +CHRIS: I have some follow up on a recent topic that we talked about. So we had a kerfuffle which I described where we had a branch that got merged and the rebase some stuff got out of hand. And so we introduced some process, the protected branch configuration within GitHub that required the branches to be up-to-date before they can be merged and CI to be passing. And everybody was happy. It was like, this is great. +Turns out it was never turned on. That's actually the day I was like, man; this is really straightforward. There's been no annoyance here. And then I got to the point where it was like; this seems weird because we just merged a lot of things in rapid succession. +I went and checked, and it turns out what I thought was the name of the branch protection rule in GitHub's UI is, in fact, a regular expression pattern. It might not be a full regular expression but like a wildcard pattern for the branch name to match to, and so it's specific. +I created this rule, and in small, gray text underneath, it said, "This applies to zero branches." I missed that the first time but then the second time going back, I was like, oh, I actually wanted it to apply to more than zero branches. So I went back in and changed that. It's a great example of very subtle UI that just slipped past me. +STEPH: I was going to say in your defense, the very subtle gray font to say, "This applies to zero," feels tricky. +CHRIS: That...also, going through the work of creating this thing and if that results in zero branches that would match, maybe that's the thing to emphasize on creation. I would love that. Because in my case, I was trying very specifically to target an existing branch. There is the ability to say, "Oh, any bugfix-* named branch," if you're using branch naming strategies like that, you can use this for that sort of thing. So it may be that currently, there are no branches with that name. But in my case, I was just like, please, main, anytime anything is happening on main, that is what we want to do. I just needed to put the word main there. But anyway, once I actually turned it on, insufferable, absolutely not, cannot survive in this world. +We have a relatively small team. There are three of us, and not everyone is even full-time, and my time is pulled in a lot of different directions. So I'm actually not pushing as much code as I might otherwise. Even with that, nope, absolutely not. Our CI is like; I don't know, five-ish minutes per run. Turns out, especially Monday mornings, we have a volley of things that will have been reviewed and trickled in through Friday afternoon. And then there's a bunch of work we want to land Monday morning. And then, just at any point, it turns out, yes, this was untenable. So we have turned it off. +I would like to revisit this down the road and introduce the MergeQueue functionality, so the idea of being able to say, "Yeah, you just name when you want something to go in, and then the system will manage the annoying finicky work there." But for now, I had to give up on my dream of everything running on CI, on a feature branch, before it gets merged. +STEPH: Ooph, that phrase, "I had to give up on my dream," that breaks my heart for you. [laughs] +CHRIS: I may be going a little bit fanciful with my language but, like, a little. +STEPH: [laughs] +CHRIS: I liked this thing. I want to exist in that world. But it is not feasible given the current state of the world. And that will only get worse over time, is my expectation. So I get to revisit this when I have the time to more thoroughly figure a thing out. But for now, I don't know, merge whatever; it will be fun. +STEPH: There's a small part of me that feels a little reassured that it was a terrible time, although I hate that it was a terrible time. But I have felt that pain on so many other projects where I am constantly waiting, and I'm constantly checking to be like, can I merge? Can I merge? Can I merge? And then I can merge, but then someone beats me to it. And I'm like, oh, then I got to restart. And I got to wait, and I'm constantly checking. So that feels like it helps validate my experience. [chuckles] +I am excited for that MergeQueue. I would be super excited to try that out and hear about how it goes just because that seems more like the dream where you can just say, hey, I want this PR to go whenever it can go. Just take care of it. I want it to be rebased, whatever the flow is, and have it be merged, so I don't ever have to check on it again. +CHRIS: But once we configured this, there was a new thing that appeared in the GitHub UI, which was auto-merge. And so that was a button where I could say like, "Hey, merge this whenever CI passes," which was a nice upgrade, but it didn't have the additional logic of and rebase as necessary. Or the more subtle logic of like, you don't actually want to rebase where you have five different branches that are all trying to merge, and they keep rebasing. You want to have the idea of a queue, and so you get in line. And you rebase when it's your turn, and then you run the CI. And you try and be as smart as possible about that. +If anyone at GitHub is listening, I would love if you all threw this into your platform, and then you could ping Slack if anything went wrong. But otherwise, there are, like I said, existing tools. At some point, I will probably, I don't know, over a long weekend or something like that, sit down with a large cup of coffee and explore these. But today is not that day. +STEPH: I'm excited to hear about that day. +CHRIS: So that is a tale of woe and sadness. But luckily, I get to balance it out with a tale of happiness and good outcomes. So that's good. The happiness and good outcome story does start with trouble, as they always do. So we had a bug that occurred in the application where something was supposed to have happened. And then there was an email that needed to go out to tell the user that this thing had happened. And the bug popped up within AppSignal and said something was nil that shouldn't have been nil. +Particularly, we're using a gem called Time For a Boolean, which is by Caleb Hearth. And he's a former thoughtboter and maintains this wonderful gem that instead of having a Boolean for like, is this thing approved, or is it paid? Or is it processed? You use a timestamp. And then this gem gives you nice Boolean-like methods on top of that timestamp. Because it turns out, very often just having the Boolean of like, this was paid, it turns out you really want to know when it was paid. That would be a really useful piece of information. And so, while you're still in Postgres land, it's nice to be able to reach for this and have the affordances of the Boolean-like interface but also have the timestamp where available. +So anyway, the email was trying to process but that timestamp...let's pretend that it was paid as the one that matters here so paid at was nil, which was very concerning. Because this was the email that's like, hey, that thing was processed. Or let's say it was processed, actually, because that's closer to what it was. Hey, this thing was processed, and here's an email notification to tell you that. But the process timestamp was nil. I was like, oh no. Oh no. And so when I saw this pop up, I was like, this is very bad. Everything is very bad. Oh goodness. +Turns out what had happened was...because I very quickly chased after this, looked in the background job queue, looked in Sidekiq's UI, and the job was gone. So it had been processed. I was like, wait a minute, how? How did this fix itself? Like, that's not the kind of bug that resolves itself, except, in this case, it was. This was an interaction that I'd run into many times before. Sidekiq was immediately processing the job. But the job was being enqueued from within the context of a database transaction. And the database transaction had not been committed yet. But Sidekiq was already off to the races trying to process. +So the record that was being worked on, the database record, had local changes within the context of that transaction, but that hadn't been committed. Sidekiq then reads that record from the database, but it's now out of sync because that tiny bit of Sidekiq is apparently very fast off to the races immediately. And so there's just this tiny little bit of time that can occur. And this is also a fun one where this isn't going to happen every time. It's only going to happen sometimes. Like, if the queue had a couple of other things in it, Sidekiq probably would have not gotten to this until the database transaction had fully closed. +So the failure mode here is super annoying. But the solution is pretty easy. You just have to make sure that you enqueue outside of the database transaction. But I'm going to be honest, that's difficult to always do right. +STEPH: That's a gnarly bug or something to investigate that I don't think I have run into before. Could you talk a little bit more about enqueueing the job outside the database transaction? +CHRIS: Sure. And I think I've talked about this on a previous episode a while back because I have run into this one a few times. But I think it is sufficiently rare; like, you need almost a perfect storm because the database transaction is going to close very quickly. Sidekiq needs to be all that much more speedy in picking up the job in order for this to happen. +But basically, the idea is within some processing logic that we have in our system; we find a record, we do some work. And then we need to update that record to assign this timestamp or whatever it is. And then we also want to inform the user, so we're going to enqueue a job to send the email notification. But for all of the database work, we are wrapping it in a transaction because we want it to either succeed or fail atomically. So there are three different records that we need to update. We want all of them to be updated or none of them to be updated. So, therefore, we wrap it in a transaction. +And the way we had written, this was to also enqueue the job from within the transaction. That wasn't something we were actively intentionally doing because those are different systems. It doesn't really mean anything. But we were still within the block of ApplicationRecord.transaction do. We're now inside of that block. We're doing all of the record updates. And then the last piece of work that we want to think about is enqueueing the job to send the email. +The problem is if we're still within that database transaction if it's yet to be committed, then when Sidekiq picks up that job to run it, it will see the prior state of the world. And it's only if the Sidekiq job waits a little bit that then the database transaction will have been committed. The record is now updated and available to be read by Sidekiq in the correct updated state. +And so there's this tiny little bit of inconsistency that can happen. It's basically because Sidekiq is going out to Redis, which is a distinct system. It doesn't have any knowledge of the database transaction at play. That's why I sometimes consider using a Postgres-backed background job system because then actually the job can be as part of the database transaction. +STEPH: Cool. That's helpful. That makes a lot of sense the way you explained the whole you're actually enqueueing the job from inside that transaction. I'm curious, that prompts another question. In the case where you mentioned you're using a transaction because you want to make sure that if something fails to update so, everything gets updated together, in the event that something does fail to update because you were previously enqueueing that job from the transaction, does that mean that the update could have failed but that email would still have gone out? +CHRIS: That does not. And the reason for that is because we're within dry-monad world. And so dry-monad will implicitly capture the ActiveRecord rollback, which I think is an exception that gets raised or somehow...But basically, if that database transaction fails for any reason and ends up getting rolled back, then dry-monads will not continue processing through the rest of the sequential operation. And so, therefore, even if we move the enqueuing of the email outside of the database transaction, the sequential nature of that processing and the dry-monad stuff that we have in play will handle that. And I think that would more generally be true because I think Rails raises an exception on rollback. Not certain there. But I know in our case, we're fine on that. And we have actually explicitly checked7 for that sort of thing. +STEPH: So I meant a slightly different question because that makes sense to me everything that you just said where if it's outside of the transaction, then that sequential order won't fire because of that ActiveRecord migration error. But when you have the enqueuing inside of the transaction because then that's going to be inside of the sequential order, maybe before the rollback error gets raised. Does that make sense? +CHRIS: Yes. I think what you're asking is basically like, do we make sure to not send the job if the rest of the stuff didn't succeed? +STEPH: I'm just wondering from a transaction perspective, actually. If you have a transaction wrapped block and then you have in there, like, update this record, send email, end block, let's say update...well, I guess it's going raise because you've got probably like an update bank. Okay, so then yeah, you won't get to the next line. Got it. Got it. Got it. I just had to walk myself through that because I forgot that you probably...I have to visualize [laughs] as to what that code probably looks like. All right, that answered my question. +CHRIS: Okay. So back up to the top level then, this is the problem that we have. And looking through the codebase, we actually have it in a bunch of different places. So the solution in any one of those cases is to just take the line of code where we're saying enqueue UserMailer.deliver_later take that line of code, move it outside of the database transaction, and make sure it only happens if the database transaction succeeds. That's very easy to do in one case. +But my concern was this is a very easy failure mode to end up in. And this is a very easy incorrect version of the code to write. As far as I can tell, we never want to write the code where this is happening inside of the transaction because it has this failure mode. But how do we enforce that? That was the thing that came to mind. So I immediately did a quick look of like, is there a RuboCop thing I can do here or something? +And I actually found something even more specific, which was so exciting to find. It's a gem called Isolator. And its job is to detect non-atomic interactions within database transactions. And so it's fantastic. I was like, wait, really? Is this going to do the thing? And so I just installed the gem, configured it where I wanted, and then ran the test suite. And it showed me every place throughout the app right now where we were doing this pattern of behavior like enqueueing work from within a database transaction, which was great. +STEPH: Ooh, that's really nifty. I kind of want to install that and just run it on my current client's codebase and see what I find. +CHRIS: This feels like something like strong migrations where it's like, yeah, this is great. I kind of want to have this as part of my core toolset now. This one feels even perhaps slightly more so because sometimes I look at strong migrations, and I'm like, no, no, no, strong migrations, I get why you would say that, but for reasons, this is actually fine. And they have configurations within it to say, like, no, this is okay. Isolator feels like it's always telling me something I want to know. So this, very quickly, I'm like, I think this might be part of my toolset moving forward on every single app forever. +And actually, there's another gem that I used. It's made by the same team. So this is from the folks over at Evil Martians, which is another Rails consultancy out there in the world. And the Isolator gem is one thing that they've produced. And then I think the same author of it who is an Evil Martian's employee created the aftercommiteverywhere gem. +So aftercommit is one of Rails' ActiveRecord callbacks. But in this case, it allows you to use it everywhere, as the name implies. And so rather than actually having to take that line of code out of the database transaction block, which is naturally where we would write it because that's how we think about the code and how we want to express it, you can just use this aftercommit method, wrap the call in that, so it's after_commit, and then a block. So either braces or do..end. That enqueueing of the email now just gets wrapped in that. And so what that does is it says, "Defer this until after the transaction commits. If the transaction does not commit, if we roll it back, then don't run it." +And what was nice is the actual code change when I finally submitted all of this was add the gem to the gem file. And then everywhere that we're doing the wrong thing, which running the test suite told me, I just went in, and I wrapped that line in after_commit and a block. And it was such a nice, clean...like, I didn't have to move the code around or actually shift the lines, which was my first attempt at this. I was able to just annotate each of those lines and say, "You're special, you're special, you're special," And then I'm done. And again, the first gem told me every case where I needed to do that. It's like, well, this is a wonderful little outcome here. +STEPH: That's really nice, yeah, how you can make the changes and then, like you said, re-run the test or re-run that gem, and it lets you know what else still needs to be updated. I'm intrigued where you mentioned you didn't have to move any lines, though. Maybe I just need to look at the gem and see it, but I'm still envisioning that you have your transaction do block. And then you're doing some things; you're updating records, and then you have your end. And then after that, it's when you want to enqueue the email. And with this after_commit, you actually added that method call inside of the transaction but then wrapped the call to Sidekiq to send the email inside of that block. +CHRIS: Correct. Yeah. So it's basically like saying, "Here's almost an anonymous function." If you think about a Ruby block in that nomenclature, you're saying, like, here's some work to do when and if the transaction succeeds. And so it meant that I was able to keep the code in the way that we as humans would talk about it but deal with the murky details, and edge cases of database transactions, and Sidekiq, and whatnot. Sort of just handle it by saying like...it almost feels like an annotation or a decoration or something like that. But it was this, in my mind, almost like a perfect melding of I don't want to think about this. Oh, cool. Okay, here's a quick, easy way to deal with it but to not have to fundamentally change how I write the code. +STEPH: Interesting. So I like all the things you're saying. I'll be honest, I'm not totally sold, and I'm trying to think of why. I think the benefits...one, as you mentioned, it's something you don't have to think about or at least signals to others that hey, maybe you should think about this to the extent that you use after_commit. And so that way, you don't have these asynchronous events taking place inside the transaction. So I like that visibility and communication to the rest of the team. Putting it inside of the transaction feels interesting. I don't know why; I feel a little weird about this. [laughs] I'm bringing my true self. +CHRIS: That's fair. So if we're being honest, I solved this first by finding the Isolator gem. Well, I solved it first by just doing it manually. I went through the app, and I found all the places. And I was like, you know what? I'm worried that the next person authoring code like this, it's so easy to fall into this trap. Like, this is such a subtle little thing that our brains are not thinking about. And so I had first fixed it, and so I had a diff that involved moving lots of lines of code, every instance of this moved from being in the database transaction out of it. And that was fine. I was fine with that as a solution. But it was a little bit noisy because I was moving a bunch of lines. +So then I brought in the Isolator gem. I actually reset that, and I went back to before I had made the fix, ran the test just to make sure Isolator was actually finding every instance. They did; that was great. So I was like, all right, cool. This is better because now I have this thing that will tell anyone when this happens. So I'm very happy about that. Because frankly, this is some hard-earned knowledge that I had to read Sidekiq and remember how database transactions work and convince myself of what was going on here and finally come to what I believe the solution is. +And now Isolator is just like, cool, that's encapsulated. And it gives a very nice failure message in the test suite. So it's like, excellent. I really like this. But still looking at it, the diff, the amount of code that I had to change, it's like, well, naturally, this is how we want to write this code, but for reasons, we can't. And it's appeasing the computer more than it's appeasing the reader or the author of the code. +And so then I happen to be reading through the Isolator gem's README, and they mention the aftercommiteverywhere gem. And I was like, oh, that's interesting. So one more time, I reset. And then I really tried fixing it with after_commit. And the look of the diff there felt nice to me because the lines got a little more on them, but they didn't move. And so it's like, this is how we naturally would have authored it, and now it works correctly. And I liked that. +But I understand your hesitation because you're like, but the thing is, it's wrong. And so you've made the wrong not wrong anymore, but you didn't...and so I get your hesitation. I still like the fancy version. +STEPH: Yeah, I think you just helped me figure out my grumpiness with it or why I'm not totally sold on it. And it was in regards to adding a dependency to avoid a noisy diff is the oversimplified version that I was processing or the reason that I was a bit grumpy about adding this other gem for that. But then you also just brought a lot of other really good reasons. +One thing that you said that I do really like is adding tools that help us author code in a more natural style, the way that we want to highlight this process, and how this application does work, and how this business logic flows. So given in that light, that makes me feel better about it. But yeah, I think that was my initial grumpiness. I was like, it’ll be a noisy diff. It's okay. +CHRIS: I think I definitely share your hesitation, or you're like, hmm, that's an interesting reason to bring more code into the application. But at the same time, I think the counterpoint that comes to mind for me is we're using Ruby because of its expressiveness; at least, that's why I'm using Ruby. I really want the code that I write to be as close as possible to the thing that I would say to another human about like, oh okay, when a user signs up for the application, we need to create a record in our system, and then we need to send them an email. And then we need to do this other thing. And so, the closer that our code is to those words that I would use to describe to another human, the happier I am. +And I will put in some pretty significant effort to hold that line as long as the code can also be correct. And so, the Isolator gem here does a great job of enforcing that correctness. And then after_commit allows me to still maintain that expressiveness and not have to think about the murky details as much or not have to reshape my code to match the murky realities of different persistence engines. +But I do agree. I think it's a good thing to look at and ask, like, is it worth it? Are you sure? And in this case, I will say, "Yeah, I think so," but with that amount of certainty in my voice, [chuckles] which is not a ton. +STEPH: I think this is going back to my days of working with dependency bot PRs where every time there was an upgrade for a gem, I always ask, what do you do here? [chuckles] Do we need to upgrade you? Can we just remove you from the codebase? So I'm fairly...I don't know, resistant is a strong word. I'm skeptical of when we're adding stuff in, and I just want to question the value that it's adding. +But I want to circle back to something that you said, and that is hard-earned knowledge. And that part I understand so much where when you have gone through a fair amount of work to uncover an issue, and then you want to make sure that others don't have to go through that. This is a really nice way to highlight; hey, there's something that's tricky about computers and software here, and we need to watch out for that. And I want to help you lookout for that. Versus this is just inherit information where this needs to happen outside or after that transaction. And so that makes a really nice entry point where someone can look to say, "Why did we add this gem?" And then there's a commit message that goes with it that explains this is why we use this after_commit gem because we're specifically looking to avoid this type of bug. And I love that. +CHRIS: Yeah, I think more lines of git commit message than diff on this one. So yeah, I wrote a short novel describing all of the features, describing the different pieces that are coming together. And then it's actually a +28 -6 diff. So it's a very small code change. But yeah, lots of story captured there. +STEPH: And if you had just moved the lines, you could still have that commit message. But it's not likely that someone's going to look up that git commit change or that message that went along with it because they're not going to know to blame that one. But if they look at that particular edition of after_commit, they're more likely to find that historical context. So long story short, I think you have walked me through my initial grumpiness and provided some really good ways to avoid that really tricky failure mode for other developers. +CHRIS: Well, thank you. I'm getting Steph's seal of approval starting from grumpy places. [laughs] I feel good. All right. +STEPH: I'll have some special Stephanie's approval stickers designed and printed for you. +CHRIS: I hope you're not joking because I very much want a yellow heart that says, "Steph-approved." +STEPH: [laughs] +CHRIS: And I can put it on PRs, and I can put it on the wall. [laughs] +STEPH: Well, now I have to find a sticker designer and make a...well, it's just a yellow heart. I can probably handle this. I'm going to use Comic Sans. That will be the approved part. [laughs] Yellow hearts and Comic Sans for everybody. +CHRIS: Well, with that absolutely fantastic call back to earlier parts of the episode, shall we wrap up? +STEPH: Let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph talks about binging a few Things Worth Learning podcast episodes and particularly enjoyed an episode that featured one of thoughtbot's design directors, Sameera Kapila. Sam shared her expertise about management and inclusion, and Steph shares her favorite parts.

+ +

Chris shares the story of a surprising error and the resulting journey through database transactions and Sidekiq that eventually resolved the issue. He also shares some follow up on the broken build and the merging process changes they introduced (spoiler, the process changes have been rolled back).

+ + + +

Transcript:

+ +

STEPH: Oh man, I'm about to stop eating my pop-tart. I'll put it away. It's within distance. I'm going to eat it.

+ +

CHRIS: Your high-fat content unfrosted pop-tart.

+ +

STEPH: You know, surprise Sunday twist: it has icing on it.

+ +

CHRIS: Steph, who even are you?

+ +

STEPH: [laughs]

+ +

CHRIS: There are a few canonical anchor facts that one knows about other people, and when one of those...

+ +

STEPH: I like to keep everyone, including myself, on their toes.

+ +

CHRIS: Or you've just secretly accepted that the icing adds another textural flavor adventure component. It's just better with icing.

+ +

STEPH: All right, all right, all right. There's a complicated answer to this. And the complicated [chuckles] answer to this is that the more organic ingredients that I recognize when reading about pop-tarts are by a particular company, and they all have frosting on them. And the more generic pop-tarts that don't have frosting on them, I don't know how to pronounce a lot of those ingredients. So I'm like, no, but okay, I still eat them. But I prefer the ingredients I can pronounce. So I either go with the ingredients I can't pronounce or have a little bit of frosting on my pop-tart. And I'm going with the non-cancer route for today.

+ +

CHRIS: For today, in this moment, and accepting the frosting. Okay, all right. Well, that is complicated. [laughs] It's tricky out there.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So the weather, I'm going to talk about the weather for a little bit. [chuckles] It's been almost non-stop rain for the past several days, which is fine. I'm sure it's great for plant life. But it's really hard on my dog Utah because then we can't go outside for our normal walks and playtime. Although he is my four-legged water baby because he absolutely loves water, and puddles, and playing in the rain. So he's very fine with going outside and playing for a long time. But then I have to essentially give him a full-on bath before I want to bring him back in.

+ +

So not wanting to have to give him a bath each time, in the spirit of improvising, we started finding more indoor games to play. And I've started teaching him to play hide and seek. And he's not great at it mainly because he will only stay until I'm out of eyesight, and then he will come and find me. And so I have to be really, really fast at finding a hiding spot to like dash around a corner or hide behind the door. But I think he enjoys it because he will find me and then he seems very excited. And we go back, and we play again. And so I just have to work on teaching him to wait a bit longer so I can find better hiding spots.

+ +

CHRIS: When you said that, at first, I was like, how did you teach him to hide? But I realize he's only playing the seek part of the game, and you're only playing the hide part of the game.

+ +

STEPH: [laughs]

+ +

CHRIS: I'm just so used to you exchange roles back and forth. First, you hide, then you seek, and then you switch it up. That would be a lot to get your dog to be like, now I'm going to secretly hide.

+ +

STEPH: [laughs] I'd be very impressed. Yes, we have very distinct roles in this game. I am the one that always counts and hides. But he's a very good seeker. So that's been fun. We just got to work on getting a little better at it.

+ +

But on a more tech-related note, one of the design directors at thoughtbot, Sameera Kapila, who also goes by Sam, was a guest on the podcast Things Worth Learning, which is hosted by Matt Stauffer. And Matt is also the host of The Five-Minute Geek Show and The Laravel Podcast. And in the show Things Worth Learning, Matt meets with individuals that are excited to share something that they're deeply passionate about; maybe it's tech, maybe it's not. And I've binged a couple of those episodes.

+ +

And I really like how you can choose between the podcast format or the YouTube format. So then you can really watch the conversation unfold, which I know you and I a couple of times have thought it would be fun if people could see us because there are so many facial emotions and gestures that go along with conversations. So it was really delightful.

+ +

And speaking of delightful, Sam shared her expertise about management and inclusion. And I definitely recommend listening to the episode because I can't share everything that Sam shared. But a couple of the topics that Sam mentioned that I really enjoyed and would love to chat about, so the first one is about helping someone, in this case, someone that you manage that comes to you with a concern.

+ +

So there's often a presumption that just because someone comes to you with a concern or an issue that they've experienced at work, that they're the ones that will also want to work to address that concern, and that's often not true. It can be true; maybe that person wants to be involved. But they're often coming to you in the leadership or management role to say, "Hey, I've had this issue," and they really want help with that instead of walking away with homework for it. Because then that trains people to essentially be in this mindset of well, if I bring up this concern, then I'm going to be the one that has to address it, even if I'm the one that's most negatively impacted by this. And addressing this concern could be actively harmful to me.

+ +

And she shared a really great real-world example from her own experience where her and another co-worker had noticed a concern about the hiring process. And her and that co-worker got together, and they talked about the concerns. They even rehearsed for the meeting because they were trained by the tech industry to say, "Hey, if you bring up a concern, you're going to be responsible for addressing and then resolving that concern."

+ +

And so they had that meeting with the person in leadership. And they were pretty nervous about how it was going to go. And that person in leadership said to them, "Thank you both so much for sharing that. That must have been such a burden. And this is my responsibility to fix. And here are what my next steps are." And that was amazing because it allowed Sam and the other person to go back to client work. And they also received follow-up conversations about how that issue was being addressed. So there was even that feedback loop as to how things were going to change.

+ +

And I have a personal example that...I really resonated with the example that Sam provided because I remember there are different teams that I've been a part of, where often I was one of the few women engineers on the team. And so we often have conversations about how do we get more women engineers into the company? And they're wonderful conversations.

+ +

But there's a part of me that always felt resentful about, like, why am I here? Why am I the one fixing this? I understand I have some more insight and expertise, and experience in this area. But I was also frustrated by the fact that I was the one that was in that meeting often with other women, and it felt like our responsibility to fix this. And I used to feel bad about feeling resentful towards that. Because I was like, shouldn't I want to help other people? And I do. But Sam's example really helped remind me and clarify that yes, just because there's a concern doesn't necessarily mean you should be the one to address it. And it really takes everybody involved, or it takes leadership to step up and address that concern.

+ +

CHRIS: Oh, that's really interesting the way Sam is framing that and describing the situation of not having any problem that you bring in be now your work to solve. Like, oh, I found the issue, and now we've got to go do this. But the idea that you can bring something to light and then be able to walk away from it.

+ +

And the particular thing that you were saying that if your interaction is always that when you reference something when you bring in a concern that then your manager works with you to figure out how you can solve it, then you get this mental block of like, well, do I even want to say anything? Because I don't want to try and deal with big, amorphous unclear issues. So maybe I just won't even say anything.

+ +

And so this as a way to make sure that there's room for all of the conversation is a really interesting framing that I hadn't really thought about, frankly, but it's very interesting. I haven't seen this interview either. So I'm definitely excited to give this a look because Sam is wonderful. And the topic that you're describing here sounds fantastic as well.

+ +

STEPH: Yeah. There was an important moment for me where...one of my managers is Matt Sumner, who's been on the show. And when Matt was my manager, at one point, we were having a one on one, and we would often go for walks for our one on one. And I mentioned something about "I have this concern, or I have this problem, but I don't really know how to fix it. So I'm not sure I'm ready to talk about it." And Matt, in his delightful way, was like, "We can still talk about it. You don't have to have an answer or a solution." I'm like, "Yeah, but I feel like I should be able to fix it. Like, if you have a concern, or if you have something that you want to gripe about, then you should come to the table with solutions for it." And Matt was like, "No, you don't need to do that at all. We can totally gripe about stuff or talk about concerns and then either figure out the solutions together or go to other people for ideas."

+ +

And that was really important to me because, like you'd mentioned, otherwise, it felt like this mental block where then it feels like you can't air out some of the things that you're worried about or have concerns about because then you think you're the only one responsible. And you may not be able to come up with the best solution. You may need other people to then help you strategize and come up with ideas. And I just love, love, love that part of Sam's discussion.

+ +

And oh, there was one other part about the conversation. Well, there are lots of parts that were amazing. But another one in particular that blew my mind is about Comic Sans, the font, the font that everyone loves to hate. [chuckles] And I learned that it's one of the most legible fonts for kids. And it's one of the more accessible fonts for people with dyslexia. And it's actually recommended...I think there are still more academic studies that need to be done to really classify fonts that are best for people that have dyslexia.

+ +

But Comic Sans is recommended by The British Dyslexia Association and the Dyslexia Association of Ireland. And there are some other really great posts that talk about the benefits of using a font like Comic Sans because the typeface has long ascenders and descenders and generous letter spacing and asymmetrical lowercase b and d to then help distinguish those letters. And I just thought that was so cool. This font that everybody wants to rip apart because it seems whimsical, unprofessional gets overused. There are lots of reasons, I suppose. [laughs] But there's a really big benefit to it, and it can help others. And I just found that very whimsical in itself.

+ +

CHRIS: I love the idea that there are multiple levels of knowing about Comic Sans. First, you're just like, I don't even know the name, but it's that comic book-looking font. And then obviously, the next step is to be like Comic Sans? How could you ever use that? It's an atrocity. And then it's like, but actually, Comic Sans has some things going for it. And it is a really interesting consideration and something that you wouldn't necessarily think of. But then once you learn it, you're like, okay. Man, I wonder how many other things in the world have this interesting shape to them? Hmm.

+ +

STEPH: Do you know the history behind Comic Sans?

+ +

CHRIS: I do not.

+ +

STEPH: I read about it fairly recently, but I'm probably going to botch some of the details. But I believe it was designed or created by Vincent Connare. And it was created for Microsoft. And Vincent was working on a project where I think there was a dog that was essentially going to have these bubbles that would then show you different parts of the application and walk you through the different features. And the dog had a very comic book feel to the character.

+ +

And so then Vincent designed a font to go along with that comic book character, this dog and came up with Comic Sans. I don't think the dog actually launched with that particular font. But since the font was still developed, it was released as part of the available fonts. And there we go, there is the birth of Comic Sans. And then it just received so much love and ire all throughout history. [chuckles]

+ +

CHRIS: There's something that you said there that I want to loop back on when you were talking about chatting with Matt Sumner and saying, "Here's this thing, but I don't know how to solve it. So I don't even want to bring it up." I really liked the framing that you gave and the fact that Matt was like, "No, no, we can still talk about it. We can at least explore this thing, have a conversation." I think that's really wonderful.

+ +

There's a very similar thing that I experience a lot when doing code review, particularly when I'm in more of a leadership role within a team, which is I often want to highlight something that feels a little bit off to me in the code, but I may not have a specific solution. Like, I may see a variable name, or I may see a controller action that feels like it's the wrong shape or something. And I'll often name it but explicitly say, "I actually don't have a better idea here. So feel free to continue on with this, but I want to name it. So in case that sparks something in you, if you were also feeling some incongruousness, maybe it's worth you spending another minute to think about it, but I want to make sure my comment isn't blocking or otherwise making you feel uncomfortable."

+ +

If I just come to you and I'm like, "This feels wrong," and that's all I say, that to me is unacceptable code review. Because now I want all of my code review feedback to be very actionable, it’s either here's the thing that I feel strongly I think we should definitely change this. If you disagree, let's have a conversation. But yeah, this one definitely needs to change. Here's the thing that, like, I don't know, maybe we could break this into two lines and split it up. But if you don't like that, that's fine. Do whatever. And so then it's I've given the person my thoughts but given them clarity and a free rein to do whatever they want with that information.

+ +

And then there are ones where I'm like, I don't even know what I think we should do here, but I think something. But if you don't have any ideas...like, I don't have any ideas specifically. If you don't have any ideas, it's fine. We'll continue on with this and maybe revisit it down the road. But I want to make sure each of those different tiers is actionable for the other person, and I'm not just giving them homework or something to be sad about because that would be bad code review.

+ +

STEPH: I'm just imagining a PR comment that says, "I don't know what we should do here. But I don't think this is it," [laughs] and that just creating sadness. That's so interesting to me because I have flip-flopped with that opinion in regards to there are times that I very much resonate and do what you just said where I will point out to someone where I'm like, "I'm not sure why, but I just have concerns about this. And I don't know if you also ran into anything that was weird about this and would like to talk about it. I don't have any really great ideas, so I think this is good for now. And we should keep moving forward, so we're not blocked on it," but just wanted to, as you mentioned, highlight it in case it sparks something for the other person or for someone else that's reviewing the code.

+ +

And then there are other times where I'll look at something, and I'm like, "Yeah, it's not great. There's something that feels brittle or potentially maybe hard to maintain or things like that. But I don't have a better idea." And I don't comment on it because I'm like, I don't want to distract that person or block them. And I do think it's good enough, and I don't have anything to add to the conversation, so I just leave it out. So it's interesting to me where is that line of when I feel like it's important enough to comment to then potentially spark some conversation versus just letting it go so then I don't add any distraction to their work?

+ +

CHRIS: I think it's when the spidey-sense gets past 47%. It's a very specific number. I do the same thing where there's something, and I'm like, you know what? I can't even clearly express what about this makes me feel something off, and so I won't even comment on it, and I agree. And then there are things that trip past some magical line in the sand. And I'm like, you know what? I think I'm going to say something here, but I don't even have a recommendation. And then there's a whole spectrum of the nature of code review and, again, 47% being the specific number.

+ +

STEPH: There's actually a thoughtbot blog post that correlates nicely to that concept of spidey sense. It's written by Mike Burns, and it's titled How to Skim a Pull Request. But essentially, grabbing from one of the lines here is where Mike presents an unexplained, incomplete, and arbitrarily grouped list of keywords that will cause us thoughtboters to read your code with more care and suspicion. [laughs] That feels perfectly aligned with that idea of spidey sense, spidey-sense 101. I'll be sure to include a link in the show notes. Or, you know, 40%.

+ +

CHRIS: I think it was 47%. It's a very precise number. [chuckles]

+ +

STEPH: Very precise nonsensical number. Got it. [laughs]

+ +

CHRIS: If I'm making up fake statistics, I'm not going to have them round to an even 10. [laughter]

+ +

STEPH: Makes it seem more legit somehow.

+ +

CHRIS: Exactly.

+ +

STEPH: But that's really the novelties that I wanted to chat about.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: What's new in your world?

+ +

CHRIS: I have some follow up on a recent topic that we talked about. So we had a kerfuffle which I described where we had a branch that got merged and the rebase some stuff got out of hand. And so we introduced some process, the protected branch configuration within GitHub that required the branches to be up-to-date before they can be merged and CI to be passing. And everybody was happy. It was like, this is great.

+ +

Turns out it was never turned on. That's actually the day I was like, man; this is really straightforward. There's been no annoyance here. And then I got to the point where it was like; this seems weird because we just merged a lot of things in rapid succession.

+ +

I went and checked, and it turns out what I thought was the name of the branch protection rule in GitHub's UI is, in fact, a regular expression pattern. It might not be a full regular expression but like a wildcard pattern for the branch name to match to, and so it's specific.

+ +

I created this rule, and in small, gray text underneath, it said, "This applies to zero branches." I missed that the first time but then the second time going back, I was like, oh, I actually wanted it to apply to more than zero branches. So I went back in and changed that. It's a great example of very subtle UI that just slipped past me.

+ +

STEPH: I was going to say in your defense, the very subtle gray font to say, "This applies to zero," feels tricky.

+ +

CHRIS: That...also, going through the work of creating this thing and if that results in zero branches that would match, maybe that's the thing to emphasize on creation. I would love that. Because in my case, I was trying very specifically to target an existing branch. There is the ability to say, "Oh, any bugfix-* named branch," if you're using branch naming strategies like that, you can use this for that sort of thing. So it may be that currently, there are no branches with that name. But in my case, I was just like, please, main, anytime anything is happening on main, that is what we want to do. I just needed to put the word main there. But anyway, once I actually turned it on, insufferable, absolutely not, cannot survive in this world.

+ +

We have a relatively small team. There are three of us, and not everyone is even full-time, and my time is pulled in a lot of different directions. So I'm actually not pushing as much code as I might otherwise. Even with that, nope, absolutely not. Our CI is like; I don't know, five-ish minutes per run. Turns out, especially Monday mornings, we have a volley of things that will have been reviewed and trickled in through Friday afternoon. And then there's a bunch of work we want to land Monday morning. And then, just at any point, it turns out, yes, this was untenable. So we have turned it off.

+ +

I would like to revisit this down the road and introduce the MergeQueue functionality, so the idea of being able to say, "Yeah, you just name when you want something to go in, and then the system will manage the annoying finicky work there." But for now, I had to give up on my dream of everything running on CI, on a feature branch, before it gets merged.

+ +

STEPH: Ooph, that phrase, "I had to give up on my dream," that breaks my heart for you. [laughs]

+ +

CHRIS: I may be going a little bit fanciful with my language but, like, a little.

+ +

STEPH: [laughs]

+ +

CHRIS: I liked this thing. I want to exist in that world. But it is not feasible given the current state of the world. And that will only get worse over time, is my expectation. So I get to revisit this when I have the time to more thoroughly figure a thing out. But for now, I don't know, merge whatever; it will be fun.

+ +

STEPH: There's a small part of me that feels a little reassured that it was a terrible time, although I hate that it was a terrible time. But I have felt that pain on so many other projects where I am constantly waiting, and I'm constantly checking to be like, can I merge? Can I merge? Can I merge? And then I can merge, but then someone beats me to it. And I'm like, oh, then I got to restart. And I got to wait, and I'm constantly checking. So that feels like it helps validate my experience. [chuckles]

+ +

I am excited for that MergeQueue. I would be super excited to try that out and hear about how it goes just because that seems more like the dream where you can just say, hey, I want this PR to go whenever it can go. Just take care of it. I want it to be rebased, whatever the flow is, and have it be merged, so I don't ever have to check on it again.

+ +

CHRIS: But once we configured this, there was a new thing that appeared in the GitHub UI, which was auto-merge. And so that was a button where I could say like, "Hey, merge this whenever CI passes," which was a nice upgrade, but it didn't have the additional logic of and rebase as necessary. Or the more subtle logic of like, you don't actually want to rebase where you have five different branches that are all trying to merge, and they keep rebasing. You want to have the idea of a queue, and so you get in line. And you rebase when it's your turn, and then you run the CI. And you try and be as smart as possible about that.

+ +

If anyone at GitHub is listening, I would love if you all threw this into your platform, and then you could ping Slack if anything went wrong. But otherwise, there are, like I said, existing tools. At some point, I will probably, I don't know, over a long weekend or something like that, sit down with a large cup of coffee and explore these. But today is not that day.

+ +

STEPH: I'm excited to hear about that day.

+ +

CHRIS: So that is a tale of woe and sadness. But luckily, I get to balance it out with a tale of happiness and good outcomes. So that's good. The happiness and good outcome story does start with trouble, as they always do. So we had a bug that occurred in the application where something was supposed to have happened. And then there was an email that needed to go out to tell the user that this thing had happened. And the bug popped up within AppSignal and said something was nil that shouldn't have been nil.

+ +

Particularly, we're using a gem called Time For a Boolean, which is by Caleb Hearth. And he's a former thoughtboter and maintains this wonderful gem that instead of having a Boolean for like, is this thing approved, or is it paid? Or is it processed? You use a timestamp. And then this gem gives you nice Boolean-like methods on top of that timestamp. Because it turns out, very often just having the Boolean of like, this was paid, it turns out you really want to know when it was paid. That would be a really useful piece of information. And so, while you're still in Postgres land, it's nice to be able to reach for this and have the affordances of the Boolean-like interface but also have the timestamp where available.

+ +

So anyway, the email was trying to process but that timestamp...let's pretend that it was paid as the one that matters here so paid at was nil, which was very concerning. Because this was the email that's like, hey, that thing was processed. Or let's say it was processed, actually, because that's closer to what it was. Hey, this thing was processed, and here's an email notification to tell you that. But the process timestamp was nil. I was like, oh no. Oh no. And so when I saw this pop up, I was like, this is very bad. Everything is very bad. Oh goodness.

+ +

Turns out what had happened was...because I very quickly chased after this, looked in the background job queue, looked in Sidekiq's UI, and the job was gone. So it had been processed. I was like, wait a minute, how? How did this fix itself? Like, that's not the kind of bug that resolves itself, except, in this case, it was. This was an interaction that I'd run into many times before. Sidekiq was immediately processing the job. But the job was being enqueued from within the context of a database transaction. And the database transaction had not been committed yet. But Sidekiq was already off to the races trying to process.

+ +

So the record that was being worked on, the database record, had local changes within the context of that transaction, but that hadn't been committed. Sidekiq then reads that record from the database, but it's now out of sync because that tiny bit of Sidekiq is apparently very fast off to the races immediately. And so there's just this tiny little bit of time that can occur. And this is also a fun one where this isn't going to happen every time. It's only going to happen sometimes. Like, if the queue had a couple of other things in it, Sidekiq probably would have not gotten to this until the database transaction had fully closed.

+ +

So the failure mode here is super annoying. But the solution is pretty easy. You just have to make sure that you enqueue outside of the database transaction. But I'm going to be honest, that's difficult to always do right.

+ +

STEPH: That's a gnarly bug or something to investigate that I don't think I have run into before. Could you talk a little bit more about enqueueing the job outside the database transaction?

+ +

CHRIS: Sure. And I think I've talked about this on a previous episode a while back because I have run into this one a few times. But I think it is sufficiently rare; like, you need almost a perfect storm because the database transaction is going to close very quickly. Sidekiq needs to be all that much more speedy in picking up the job in order for this to happen.

+ +

But basically, the idea is within some processing logic that we have in our system; we find a record, we do some work. And then we need to update that record to assign this timestamp or whatever it is. And then we also want to inform the user, so we're going to enqueue a job to send the email notification. But for all of the database work, we are wrapping it in a transaction because we want it to either succeed or fail atomically. So there are three different records that we need to update. We want all of them to be updated or none of them to be updated. So, therefore, we wrap it in a transaction.

+ +

And the way we had written, this was to also enqueue the job from within the transaction. That wasn't something we were actively intentionally doing because those are different systems. It doesn't really mean anything. But we were still within the block of ApplicationRecord.transaction do. We're now inside of that block. We're doing all of the record updates. And then the last piece of work that we want to think about is enqueueing the job to send the email.

+ +

The problem is if we're still within that database transaction if it's yet to be committed, then when Sidekiq picks up that job to run it, it will see the prior state of the world. And it's only if the Sidekiq job waits a little bit that then the database transaction will have been committed. The record is now updated and available to be read by Sidekiq in the correct updated state.

+ +

And so there's this tiny little bit of inconsistency that can happen. It's basically because Sidekiq is going out to Redis, which is a distinct system. It doesn't have any knowledge of the database transaction at play. That's why I sometimes consider using a Postgres-backed background job system because then actually the job can be as part of the database transaction.

+ +

STEPH: Cool. That's helpful. That makes a lot of sense the way you explained the whole you're actually enqueueing the job from inside that transaction. I'm curious, that prompts another question. In the case where you mentioned you're using a transaction because you want to make sure that if something fails to update so, everything gets updated together, in the event that something does fail to update because you were previously enqueueing that job from the transaction, does that mean that the update could have failed but that email would still have gone out?

+ +

CHRIS: That does not. And the reason for that is because we're within dry-monad world. And so dry-monad will implicitly capture the ActiveRecord rollback, which I think is an exception that gets raised or somehow...But basically, if that database transaction fails for any reason and ends up getting rolled back, then dry-monads will not continue processing through the rest of the sequential operation. And so, therefore, even if we move the enqueuing of the email outside of the database transaction, the sequential nature of that processing and the dry-monad stuff that we have in play will handle that. And I think that would more generally be true because I think Rails raises an exception on rollback. Not certain there. But I know in our case, we're fine on that. And we have actually explicitly checked7 for that sort of thing.

+ +

STEPH: So I meant a slightly different question because that makes sense to me everything that you just said where if it's outside of the transaction, then that sequential order won't fire because of that ActiveRecord migration error. But when you have the enqueuing inside of the transaction because then that's going to be inside of the sequential order, maybe before the rollback error gets raised. Does that make sense?

+ +

CHRIS: Yes. I think what you're asking is basically like, do we make sure to not send the job if the rest of the stuff didn't succeed?

+ +

STEPH: I'm just wondering from a transaction perspective, actually. If you have a transaction wrapped block and then you have in there, like, update this record, send email, end block, let's say update...well, I guess it's going raise because you've got probably like an update bank. Okay, so then yeah, you won't get to the next line. Got it. Got it. Got it. I just had to walk myself through that because I forgot that you probably...I have to visualize [laughs] as to what that code probably looks like. All right, that answered my question.

+ +

CHRIS: Okay. So back up to the top level then, this is the problem that we have. And looking through the codebase, we actually have it in a bunch of different places. So the solution in any one of those cases is to just take the line of code where we're saying enqueue UserMailer.deliver_later take that line of code, move it outside of the database transaction, and make sure it only happens if the database transaction succeeds. That's very easy to do in one case.

+ +

But my concern was this is a very easy failure mode to end up in. And this is a very easy incorrect version of the code to write. As far as I can tell, we never want to write the code where this is happening inside of the transaction because it has this failure mode. But how do we enforce that? That was the thing that came to mind. So I immediately did a quick look of like, is there a RuboCop thing I can do here or something?

+ +

And I actually found something even more specific, which was so exciting to find. It's a gem called Isolator. And its job is to detect non-atomic interactions within database transactions. And so it's fantastic. I was like, wait, really? Is this going to do the thing? And so I just installed the gem, configured it where I wanted, and then ran the test suite. And it showed me every place throughout the app right now where we were doing this pattern of behavior like enqueueing work from within a database transaction, which was great.

+ +

STEPH: Ooh, that's really nifty. I kind of want to install that and just run it on my current client's codebase and see what I find.

+ +

CHRIS: This feels like something like strong migrations where it's like, yeah, this is great. I kind of want to have this as part of my core toolset now. This one feels even perhaps slightly more so because sometimes I look at strong migrations, and I'm like, no, no, no, strong migrations, I get why you would say that, but for reasons, this is actually fine. And they have configurations within it to say, like, no, this is okay. Isolator feels like it's always telling me something I want to know. So this, very quickly, I'm like, I think this might be part of my toolset moving forward on every single app forever.

+ +

And actually, there's another gem that I used. It's made by the same team. So this is from the folks over at Evil Martians, which is another Rails consultancy out there in the world. And the Isolator gem is one thing that they've produced. And then I think the same author of it who is an Evil Martian's employee created the after_commit_everywhere gem.

+ +

So after_commit is one of Rails' ActiveRecord callbacks. But in this case, it allows you to use it everywhere, as the name implies. And so rather than actually having to take that line of code out of the database transaction block, which is naturally where we would write it because that's how we think about the code and how we want to express it, you can just use this after_commit method, wrap the call in that, so it's after_commit, and then a block. So either braces or do..end. That enqueueing of the email now just gets wrapped in that. And so what that does is it says, "Defer this until after the transaction commits. If the transaction does not commit, if we roll it back, then don't run it."

+ +

And what was nice is the actual code change when I finally submitted all of this was add the gem to the gem file. And then everywhere that we're doing the wrong thing, which running the test suite told me, I just went in, and I wrapped that line in after_commit and a block. And it was such a nice, clean...like, I didn't have to move the code around or actually shift the lines, which was my first attempt at this. I was able to just annotate each of those lines and say, "You're special, you're special, you're special," And then I'm done. And again, the first gem told me every case where I needed to do that. It's like, well, this is a wonderful little outcome here.

+ +

STEPH: That's really nice, yeah, how you can make the changes and then, like you said, re-run the test or re-run that gem, and it lets you know what else still needs to be updated. I'm intrigued where you mentioned you didn't have to move any lines, though. Maybe I just need to look at the gem and see it, but I'm still envisioning that you have your transaction do block. And then you're doing some things; you're updating records, and then you have your end. And then after that, it's when you want to enqueue the email. And with this after_commit, you actually added that method call inside of the transaction but then wrapped the call to Sidekiq to send the email inside of that block.

+ +

CHRIS: Correct. Yeah. So it's basically like saying, "Here's almost an anonymous function." If you think about a Ruby block in that nomenclature, you're saying, like, here's some work to do when and if the transaction succeeds. And so it meant that I was able to keep the code in the way that we as humans would talk about it but deal with the murky details, and edge cases of database transactions, and Sidekiq, and whatnot. Sort of just handle it by saying like...it almost feels like an annotation or a decoration or something like that. But it was this, in my mind, almost like a perfect melding of I don't want to think about this. Oh, cool. Okay, here's a quick, easy way to deal with it but to not have to fundamentally change how I write the code.

+ +

STEPH: Interesting. So I like all the things you're saying. I'll be honest, I'm not totally sold, and I'm trying to think of why. I think the benefits...one, as you mentioned, it's something you don't have to think about or at least signals to others that hey, maybe you should think about this to the extent that you use after_commit. And so that way, you don't have these asynchronous events taking place inside the transaction. So I like that visibility and communication to the rest of the team. Putting it inside of the transaction feels interesting. I don't know why; I feel a little weird about this. [laughs] I'm bringing my true self.

+ +

CHRIS: That's fair. So if we're being honest, I solved this first by finding the Isolator gem. Well, I solved it first by just doing it manually. I went through the app, and I found all the places. And I was like, you know what? I'm worried that the next person authoring code like this, it's so easy to fall into this trap. Like, this is such a subtle little thing that our brains are not thinking about. And so I had first fixed it, and so I had a diff that involved moving lots of lines of code, every instance of this moved from being in the database transaction out of it. And that was fine. I was fine with that as a solution. But it was a little bit noisy because I was moving a bunch of lines.

+ +

So then I brought in the Isolator gem. I actually reset that, and I went back to before I had made the fix, ran the test just to make sure Isolator was actually finding every instance. They did; that was great. So I was like, all right, cool. This is better because now I have this thing that will tell anyone when this happens. So I'm very happy about that. Because frankly, this is some hard-earned knowledge that I had to read Sidekiq and remember how database transactions work and convince myself of what was going on here and finally come to what I believe the solution is.

+ +

And now Isolator is just like, cool, that's encapsulated. And it gives a very nice failure message in the test suite. So it's like, excellent. I really like this. But still looking at it, the diff, the amount of code that I had to change, it's like, well, naturally, this is how we want to write this code, but for reasons, we can't. And it's appeasing the computer more than it's appeasing the reader or the author of the code.

+ +

And so then I happen to be reading through the Isolator gem's README, and they mention the after_commit_everywhere gem. And I was like, oh, that's interesting. So one more time, I reset. And then I really tried fixing it with after_commit. And the look of the diff there felt nice to me because the lines got a little more on them, but they didn't move. And so it's like, this is how we naturally would have authored it, and now it works correctly. And I liked that.

+ +

But I understand your hesitation because you're like, but the thing is, it's wrong. And so you've made the wrong not wrong anymore, but you didn't...and so I get your hesitation. I still like the fancy version.

+ +

STEPH: Yeah, I think you just helped me figure out my grumpiness with it or why I'm not totally sold on it. And it was in regards to adding a dependency to avoid a noisy diff is the oversimplified version that I was processing or the reason that I was a bit grumpy about adding this other gem for that. But then you also just brought a lot of other really good reasons.

+ +

One thing that you said that I do really like is adding tools that help us author code in a more natural style, the way that we want to highlight this process, and how this application does work, and how this business logic flows. So given in that light, that makes me feel better about it. But yeah, I think that was my initial grumpiness. I was like, it’ll be a noisy diff. It's okay.

+ +

CHRIS: I think I definitely share your hesitation, or you're like, hmm, that's an interesting reason to bring more code into the application. But at the same time, I think the counterpoint that comes to mind for me is we're using Ruby because of its expressiveness; at least, that's why I'm using Ruby. I really want the code that I write to be as close as possible to the thing that I would say to another human about like, oh okay, when a user signs up for the application, we need to create a record in our system, and then we need to send them an email. And then we need to do this other thing. And so, the closer that our code is to those words that I would use to describe to another human, the happier I am.

+ +

And I will put in some pretty significant effort to hold that line as long as the code can also be correct. And so, the Isolator gem here does a great job of enforcing that correctness. And then after_commit allows me to still maintain that expressiveness and not have to think about the murky details as much or not have to reshape my code to match the murky realities of different persistence engines.

+ +

But I do agree. I think it's a good thing to look at and ask, like, is it worth it? Are you sure? And in this case, I will say, "Yeah, I think so," but with that amount of certainty in my voice, [chuckles] which is not a ton.

+ +

STEPH: I think this is going back to my days of working with dependency bot PRs where every time there was an upgrade for a gem, I always ask, what do you do here? [chuckles] Do we need to upgrade you? Can we just remove you from the codebase? So I'm fairly...I don't know, resistant is a strong word. I'm skeptical of when we're adding stuff in, and I just want to question the value that it's adding.

+ +

But I want to circle back to something that you said, and that is hard-earned knowledge. And that part I understand so much where when you have gone through a fair amount of work to uncover an issue, and then you want to make sure that others don't have to go through that. This is a really nice way to highlight; hey, there's something that's tricky about computers and software here, and we need to watch out for that. And I want to help you lookout for that. Versus this is just inherit information where this needs to happen outside or after that transaction. And so that makes a really nice entry point where someone can look to say, "Why did we add this gem?" And then there's a commit message that goes with it that explains this is why we use this after_commit gem because we're specifically looking to avoid this type of bug. And I love that.

+ +

CHRIS: Yeah, I think more lines of git commit message than diff on this one. So yeah, I wrote a short novel describing all of the features, describing the different pieces that are coming together. And then it's actually a +28 -6 diff. So it's a very small code change. But yeah, lots of story captured there.

+ +

STEPH: And if you had just moved the lines, you could still have that commit message. But it's not likely that someone's going to look up that git commit change or that message that went along with it because they're not going to know to blame that one. But if they look at that particular edition of after_commit, they're more likely to find that historical context. So long story short, I think you have walked me through my initial grumpiness and provided some really good ways to avoid that really tricky failure mode for other developers.

+ +

CHRIS: Well, thank you. I'm getting Steph's seal of approval starting from grumpy places. [laughs] I feel good. All right.

+ +

STEPH: I'll have some special Stephanie's approval stickers designed and printed for you.

+ +

CHRIS: I hope you're not joking because I very much want a yellow heart that says, "Steph-approved."

+ +

STEPH: [laughs]

+ +

CHRIS: And I can put it on PRs, and I can put it on the wall. [laughs]

+ +

STEPH: Well, now I have to find a sticker designer and make a...well, it's just a yellow heart. I can probably handle this. I'm going to use Comic Sans. That will be the approved part. [laughs] Yellow hearts and Comic Sans for everybody.

+ +

CHRIS: Well, with that absolutely fantastic call back to earlier parts of the episode, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph talks about binging a few Things Worth Learning podcast episodes and particularly enjoyed an episode that featured one of thoughtbot's design directors, Sameera Kapila. Sam shared her expertise about management and inclusion, and Steph shares her favorite parts.

+ +

Chris shares the story of a surprising error and the resulting journey through database transactions and Sidekiq that eventually resolved the issue. He also shares some follow up on the broken build and the merging process changes they introduced (spoiler, the process changes have been rolled back).

+ + + +

Transcript:

+ +

STEPH: Oh man, I'm about to stop eating my pop-tart. I'll put it away. It's within distance. I'm going to eat it.

+ +

CHRIS: Your high-fat content unfrosted pop-tart.

+ +

STEPH: You know, surprise Sunday twist: it has icing on it.

+ +

CHRIS: Steph, who even are you?

+ +

STEPH: [laughs]

+ +

CHRIS: There are a few canonical anchor facts that one knows about other people, and when one of those...

+ +

STEPH: I like to keep everyone, including myself, on their toes.

+ +

CHRIS: Or you've just secretly accepted that the icing adds another textural flavor adventure component. It's just better with icing.

+ +

STEPH: All right, all right, all right. There's a complicated answer to this. And the complicated [chuckles] answer to this is that the more organic ingredients that I recognize when reading about pop-tarts are by a particular company, and they all have frosting on them. And the more generic pop-tarts that don't have frosting on them, I don't know how to pronounce a lot of those ingredients. So I'm like, no, but okay, I still eat them. But I prefer the ingredients I can pronounce. So I either go with the ingredients I can't pronounce or have a little bit of frosting on my pop-tart. And I'm going with the non-cancer route for today.

+ +

CHRIS: For today, in this moment, and accepting the frosting. Okay, all right. Well, that is complicated. [laughs] It's tricky out there.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey, Chris. So the weather, I'm going to talk about the weather for a little bit. [chuckles] It's been almost non-stop rain for the past several days, which is fine. I'm sure it's great for plant life. But it's really hard on my dog Utah because then we can't go outside for our normal walks and playtime. Although he is my four-legged water baby because he absolutely loves water, and puddles, and playing in the rain. So he's very fine with going outside and playing for a long time. But then I have to essentially give him a full-on bath before I want to bring him back in.

+ +

So not wanting to have to give him a bath each time, in the spirit of improvising, we started finding more indoor games to play. And I've started teaching him to play hide and seek. And he's not great at it mainly because he will only stay until I'm out of eyesight, and then he will come and find me. And so I have to be really, really fast at finding a hiding spot to like dash around a corner or hide behind the door. But I think he enjoys it because he will find me and then he seems very excited. And we go back, and we play again. And so I just have to work on teaching him to wait a bit longer so I can find better hiding spots.

+ +

CHRIS: When you said that, at first, I was like, how did you teach him to hide? But I realize he's only playing the seek part of the game, and you're only playing the hide part of the game.

+ +

STEPH: [laughs]

+ +

CHRIS: I'm just so used to you exchange roles back and forth. First, you hide, then you seek, and then you switch it up. That would be a lot to get your dog to be like, now I'm going to secretly hide.

+ +

STEPH: [laughs] I'd be very impressed. Yes, we have very distinct roles in this game. I am the one that always counts and hides. But he's a very good seeker. So that's been fun. We just got to work on getting a little better at it.

+ +

But on a more tech-related note, one of the design directors at thoughtbot, Sameera Kapila, who also goes by Sam, was a guest on the podcast Things Worth Learning, which is hosted by Matt Stauffer. And Matt is also the host of The Five-Minute Geek Show and The Laravel Podcast. And in the show Things Worth Learning, Matt meets with individuals that are excited to share something that they're deeply passionate about; maybe it's tech, maybe it's not. And I've binged a couple of those episodes.

+ +

And I really like how you can choose between the podcast format or the YouTube format. So then you can really watch the conversation unfold, which I know you and I a couple of times have thought it would be fun if people could see us because there are so many facial emotions and gestures that go along with conversations. So it was really delightful.

+ +

And speaking of delightful, Sam shared her expertise about management and inclusion. And I definitely recommend listening to the episode because I can't share everything that Sam shared. But a couple of the topics that Sam mentioned that I really enjoyed and would love to chat about, so the first one is about helping someone, in this case, someone that you manage that comes to you with a concern.

+ +

So there's often a presumption that just because someone comes to you with a concern or an issue that they've experienced at work, that they're the ones that will also want to work to address that concern, and that's often not true. It can be true; maybe that person wants to be involved. But they're often coming to you in the leadership or management role to say, "Hey, I've had this issue," and they really want help with that instead of walking away with homework for it. Because then that trains people to essentially be in this mindset of well, if I bring up this concern, then I'm going to be the one that has to address it, even if I'm the one that's most negatively impacted by this. And addressing this concern could be actively harmful to me.

+ +

And she shared a really great real-world example from her own experience where her and another co-worker had noticed a concern about the hiring process. And her and that co-worker got together, and they talked about the concerns. They even rehearsed for the meeting because they were trained by the tech industry to say, "Hey, if you bring up a concern, you're going to be responsible for addressing and then resolving that concern."

+ +

And so they had that meeting with the person in leadership. And they were pretty nervous about how it was going to go. And that person in leadership said to them, "Thank you both so much for sharing that. That must have been such a burden. And this is my responsibility to fix. And here are what my next steps are." And that was amazing because it allowed Sam and the other person to go back to client work. And they also received follow-up conversations about how that issue was being addressed. So there was even that feedback loop as to how things were going to change.

+ +

And I have a personal example that...I really resonated with the example that Sam provided because I remember there are different teams that I've been a part of, where often I was one of the few women engineers on the team. And so we often have conversations about how do we get more women engineers into the company? And they're wonderful conversations.

+ +

But there's a part of me that always felt resentful about, like, why am I here? Why am I the one fixing this? I understand I have some more insight and expertise, and experience in this area. But I was also frustrated by the fact that I was the one that was in that meeting often with other women, and it felt like our responsibility to fix this. And I used to feel bad about feeling resentful towards that. Because I was like, shouldn't I want to help other people? And I do. But Sam's example really helped remind me and clarify that yes, just because there's a concern doesn't necessarily mean you should be the one to address it. And it really takes everybody involved, or it takes leadership to step up and address that concern.

+ +

CHRIS: Oh, that's really interesting the way Sam is framing that and describing the situation of not having any problem that you bring in be now your work to solve. Like, oh, I found the issue, and now we've got to go do this. But the idea that you can bring something to light and then be able to walk away from it.

+ +

And the particular thing that you were saying that if your interaction is always that when you reference something when you bring in a concern that then your manager works with you to figure out how you can solve it, then you get this mental block of like, well, do I even want to say anything? Because I don't want to try and deal with big, amorphous unclear issues. So maybe I just won't even say anything.

+ +

And so this as a way to make sure that there's room for all of the conversation is a really interesting framing that I hadn't really thought about, frankly, but it's very interesting. I haven't seen this interview either. So I'm definitely excited to give this a look because Sam is wonderful. And the topic that you're describing here sounds fantastic as well.

+ +

STEPH: Yeah. There was an important moment for me where...one of my managers is Matt Sumner, who's been on the show. And when Matt was my manager, at one point, we were having a one on one, and we would often go for walks for our one on one. And I mentioned something about "I have this concern, or I have this problem, but I don't really know how to fix it. So I'm not sure I'm ready to talk about it." And Matt, in his delightful way, was like, "We can still talk about it. You don't have to have an answer or a solution." I'm like, "Yeah, but I feel like I should be able to fix it. Like, if you have a concern, or if you have something that you want to gripe about, then you should come to the table with solutions for it." And Matt was like, "No, you don't need to do that at all. We can totally gripe about stuff or talk about concerns and then either figure out the solutions together or go to other people for ideas."

+ +

And that was really important to me because, like you'd mentioned, otherwise, it felt like this mental block where then it feels like you can't air out some of the things that you're worried about or have concerns about because then you think you're the only one responsible. And you may not be able to come up with the best solution. You may need other people to then help you strategize and come up with ideas. And I just love, love, love that part of Sam's discussion.

+ +

And oh, there was one other part about the conversation. Well, there are lots of parts that were amazing. But another one in particular that blew my mind is about Comic Sans, the font, the font that everyone loves to hate. [chuckles] And I learned that it's one of the most legible fonts for kids. And it's one of the more accessible fonts for people with dyslexia. And it's actually recommended...I think there are still more academic studies that need to be done to really classify fonts that are best for people that have dyslexia.

+ +

But Comic Sans is recommended by The British Dyslexia Association and the Dyslexia Association of Ireland. And there are some other really great posts that talk about the benefits of using a font like Comic Sans because the typeface has long ascenders and descenders and generous letter spacing and asymmetrical lowercase b and d to then help distinguish those letters. And I just thought that was so cool. This font that everybody wants to rip apart because it seems whimsical, unprofessional gets overused. There are lots of reasons, I suppose. [laughs] But there's a really big benefit to it, and it can help others. And I just found that very whimsical in itself.

+ +

CHRIS: I love the idea that there are multiple levels of knowing about Comic Sans. First, you're just like, I don't even know the name, but it's that comic book-looking font. And then obviously, the next step is to be like Comic Sans? How could you ever use that? It's an atrocity. And then it's like, but actually, Comic Sans has some things going for it. And it is a really interesting consideration and something that you wouldn't necessarily think of. But then once you learn it, you're like, okay. Man, I wonder how many other things in the world have this interesting shape to them? Hmm.

+ +

STEPH: Do you know the history behind Comic Sans?

+ +

CHRIS: I do not.

+ +

STEPH: I read about it fairly recently, but I'm probably going to botch some of the details. But I believe it was designed or created by Vincent Connare. And it was created for Microsoft. And Vincent was working on a project where I think there was a dog that was essentially going to have these bubbles that would then show you different parts of the application and walk you through the different features. And the dog had a very comic book feel to the character.

+ +

And so then Vincent designed a font to go along with that comic book character, this dog and came up with Comic Sans. I don't think the dog actually launched with that particular font. But since the font was still developed, it was released as part of the available fonts. And there we go, there is the birth of Comic Sans. And then it just received so much love and ire all throughout history. [chuckles]

+ +

CHRIS: There's something that you said there that I want to loop back on when you were talking about chatting with Matt Sumner and saying, "Here's this thing, but I don't know how to solve it. So I don't even want to bring it up." I really liked the framing that you gave and the fact that Matt was like, "No, no, we can still talk about it. We can at least explore this thing, have a conversation." I think that's really wonderful.

+ +

There's a very similar thing that I experience a lot when doing code review, particularly when I'm in more of a leadership role within a team, which is I often want to highlight something that feels a little bit off to me in the code, but I may not have a specific solution. Like, I may see a variable name, or I may see a controller action that feels like it's the wrong shape or something. And I'll often name it but explicitly say, "I actually don't have a better idea here. So feel free to continue on with this, but I want to name it. So in case that sparks something in you, if you were also feeling some incongruousness, maybe it's worth you spending another minute to think about it, but I want to make sure my comment isn't blocking or otherwise making you feel uncomfortable."

+ +

If I just come to you and I'm like, "This feels wrong," and that's all I say, that to me is unacceptable code review. Because now I want all of my code review feedback to be very actionable, it’s either here's the thing that I feel strongly I think we should definitely change this. If you disagree, let's have a conversation. But yeah, this one definitely needs to change. Here's the thing that, like, I don't know, maybe we could break this into two lines and split it up. But if you don't like that, that's fine. Do whatever. And so then it's I've given the person my thoughts but given them clarity and a free rein to do whatever they want with that information.

+ +

And then there are ones where I'm like, I don't even know what I think we should do here, but I think something. But if you don't have any ideas...like, I don't have any ideas specifically. If you don't have any ideas, it's fine. We'll continue on with this and maybe revisit it down the road. But I want to make sure each of those different tiers is actionable for the other person, and I'm not just giving them homework or something to be sad about because that would be bad code review.

+ +

STEPH: I'm just imagining a PR comment that says, "I don't know what we should do here. But I don't think this is it," [laughs] and that just creating sadness. That's so interesting to me because I have flip-flopped with that opinion in regards to there are times that I very much resonate and do what you just said where I will point out to someone where I'm like, "I'm not sure why, but I just have concerns about this. And I don't know if you also ran into anything that was weird about this and would like to talk about it. I don't have any really great ideas, so I think this is good for now. And we should keep moving forward, so we're not blocked on it," but just wanted to, as you mentioned, highlight it in case it sparks something for the other person or for someone else that's reviewing the code.

+ +

And then there are other times where I'll look at something, and I'm like, "Yeah, it's not great. There's something that feels brittle or potentially maybe hard to maintain or things like that. But I don't have a better idea." And I don't comment on it because I'm like, I don't want to distract that person or block them. And I do think it's good enough, and I don't have anything to add to the conversation, so I just leave it out. So it's interesting to me where is that line of when I feel like it's important enough to comment to then potentially spark some conversation versus just letting it go so then I don't add any distraction to their work?

+ +

CHRIS: I think it's when the spidey-sense gets past 47%. It's a very specific number. I do the same thing where there's something, and I'm like, you know what? I can't even clearly express what about this makes me feel something off, and so I won't even comment on it, and I agree. And then there are things that trip past some magical line in the sand. And I'm like, you know what? I think I'm going to say something here, but I don't even have a recommendation. And then there's a whole spectrum of the nature of code review and, again, 47% being the specific number.

+ +

STEPH: There's actually a thoughtbot blog post that correlates nicely to that concept of spidey sense. It's written by Mike Burns, and it's titled How to Skim a Pull Request. But essentially, grabbing from one of the lines here is where Mike presents an unexplained, incomplete, and arbitrarily grouped list of keywords that will cause us thoughtboters to read your code with more care and suspicion. [laughs] That feels perfectly aligned with that idea of spidey sense, spidey-sense 101. I'll be sure to include a link in the show notes. Or, you know, 40%.

+ +

CHRIS: I think it was 47%. It's a very precise number. [chuckles]

+ +

STEPH: Very precise nonsensical number. Got it. [laughs]

+ +

CHRIS: If I'm making up fake statistics, I'm not going to have them round to an even 10. [laughter]

+ +

STEPH: Makes it seem more legit somehow.

+ +

CHRIS: Exactly.

+ +

STEPH: But that's really the novelties that I wanted to chat about.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: What's new in your world?

+ +

CHRIS: I have some follow up on a recent topic that we talked about. So we had a kerfuffle which I described where we had a branch that got merged and the rebase some stuff got out of hand. And so we introduced some process, the protected branch configuration within GitHub that required the branches to be up-to-date before they can be merged and CI to be passing. And everybody was happy. It was like, this is great.

+ +

Turns out it was never turned on. That's actually the day I was like, man; this is really straightforward. There's been no annoyance here. And then I got to the point where it was like; this seems weird because we just merged a lot of things in rapid succession.

+ +

I went and checked, and it turns out what I thought was the name of the branch protection rule in GitHub's UI is, in fact, a regular expression pattern. It might not be a full regular expression but like a wildcard pattern for the branch name to match to, and so it's specific.

+ +

I created this rule, and in small, gray text underneath, it said, "This applies to zero branches." I missed that the first time but then the second time going back, I was like, oh, I actually wanted it to apply to more than zero branches. So I went back in and changed that. It's a great example of very subtle UI that just slipped past me.

+ +

STEPH: I was going to say in your defense, the very subtle gray font to say, "This applies to zero," feels tricky.

+ +

CHRIS: That...also, going through the work of creating this thing and if that results in zero branches that would match, maybe that's the thing to emphasize on creation. I would love that. Because in my case, I was trying very specifically to target an existing branch. There is the ability to say, "Oh, any bugfix-* named branch," if you're using branch naming strategies like that, you can use this for that sort of thing. So it may be that currently, there are no branches with that name. But in my case, I was just like, please, main, anytime anything is happening on main, that is what we want to do. I just needed to put the word main there. But anyway, once I actually turned it on, insufferable, absolutely not, cannot survive in this world.

+ +

We have a relatively small team. There are three of us, and not everyone is even full-time, and my time is pulled in a lot of different directions. So I'm actually not pushing as much code as I might otherwise. Even with that, nope, absolutely not. Our CI is like; I don't know, five-ish minutes per run. Turns out, especially Monday mornings, we have a volley of things that will have been reviewed and trickled in through Friday afternoon. And then there's a bunch of work we want to land Monday morning. And then, just at any point, it turns out, yes, this was untenable. So we have turned it off.

+ +

I would like to revisit this down the road and introduce the MergeQueue functionality, so the idea of being able to say, "Yeah, you just name when you want something to go in, and then the system will manage the annoying finicky work there." But for now, I had to give up on my dream of everything running on CI, on a feature branch, before it gets merged.

+ +

STEPH: Ooph, that phrase, "I had to give up on my dream," that breaks my heart for you. [laughs]

+ +

CHRIS: I may be going a little bit fanciful with my language but, like, a little.

+ +

STEPH: [laughs]

+ +

CHRIS: I liked this thing. I want to exist in that world. But it is not feasible given the current state of the world. And that will only get worse over time, is my expectation. So I get to revisit this when I have the time to more thoroughly figure a thing out. But for now, I don't know, merge whatever; it will be fun.

+ +

STEPH: There's a small part of me that feels a little reassured that it was a terrible time, although I hate that it was a terrible time. But I have felt that pain on so many other projects where I am constantly waiting, and I'm constantly checking to be like, can I merge? Can I merge? Can I merge? And then I can merge, but then someone beats me to it. And I'm like, oh, then I got to restart. And I got to wait, and I'm constantly checking. So that feels like it helps validate my experience. [chuckles]

+ +

I am excited for that MergeQueue. I would be super excited to try that out and hear about how it goes just because that seems more like the dream where you can just say, hey, I want this PR to go whenever it can go. Just take care of it. I want it to be rebased, whatever the flow is, and have it be merged, so I don't ever have to check on it again.

+ +

CHRIS: But once we configured this, there was a new thing that appeared in the GitHub UI, which was auto-merge. And so that was a button where I could say like, "Hey, merge this whenever CI passes," which was a nice upgrade, but it didn't have the additional logic of and rebase as necessary. Or the more subtle logic of like, you don't actually want to rebase where you have five different branches that are all trying to merge, and they keep rebasing. You want to have the idea of a queue, and so you get in line. And you rebase when it's your turn, and then you run the CI. And you try and be as smart as possible about that.

+ +

If anyone at GitHub is listening, I would love if you all threw this into your platform, and then you could ping Slack if anything went wrong. But otherwise, there are, like I said, existing tools. At some point, I will probably, I don't know, over a long weekend or something like that, sit down with a large cup of coffee and explore these. But today is not that day.

+ +

STEPH: I'm excited to hear about that day.

+ +

CHRIS: So that is a tale of woe and sadness. But luckily, I get to balance it out with a tale of happiness and good outcomes. So that's good. The happiness and good outcome story does start with trouble, as they always do. So we had a bug that occurred in the application where something was supposed to have happened. And then there was an email that needed to go out to tell the user that this thing had happened. And the bug popped up within AppSignal and said something was nil that shouldn't have been nil.

+ +

Particularly, we're using a gem called Time For a Boolean, which is by Caleb Hearth. And he's a former thoughtboter and maintains this wonderful gem that instead of having a Boolean for like, is this thing approved, or is it paid? Or is it processed? You use a timestamp. And then this gem gives you nice Boolean-like methods on top of that timestamp. Because it turns out, very often just having the Boolean of like, this was paid, it turns out you really want to know when it was paid. That would be a really useful piece of information. And so, while you're still in Postgres land, it's nice to be able to reach for this and have the affordances of the Boolean-like interface but also have the timestamp where available.

+ +

So anyway, the email was trying to process but that timestamp...let's pretend that it was paid as the one that matters here so paid at was nil, which was very concerning. Because this was the email that's like, hey, that thing was processed. Or let's say it was processed, actually, because that's closer to what it was. Hey, this thing was processed, and here's an email notification to tell you that. But the process timestamp was nil. I was like, oh no. Oh no. And so when I saw this pop up, I was like, this is very bad. Everything is very bad. Oh goodness.

+ +

Turns out what had happened was...because I very quickly chased after this, looked in the background job queue, looked in Sidekiq's UI, and the job was gone. So it had been processed. I was like, wait a minute, how? How did this fix itself? Like, that's not the kind of bug that resolves itself, except, in this case, it was. This was an interaction that I'd run into many times before. Sidekiq was immediately processing the job. But the job was being enqueued from within the context of a database transaction. And the database transaction had not been committed yet. But Sidekiq was already off to the races trying to process.

+ +

So the record that was being worked on, the database record, had local changes within the context of that transaction, but that hadn't been committed. Sidekiq then reads that record from the database, but it's now out of sync because that tiny bit of Sidekiq is apparently very fast off to the races immediately. And so there's just this tiny little bit of time that can occur. And this is also a fun one where this isn't going to happen every time. It's only going to happen sometimes. Like, if the queue had a couple of other things in it, Sidekiq probably would have not gotten to this until the database transaction had fully closed.

+ +

So the failure mode here is super annoying. But the solution is pretty easy. You just have to make sure that you enqueue outside of the database transaction. But I'm going to be honest, that's difficult to always do right.

+ +

STEPH: That's a gnarly bug or something to investigate that I don't think I have run into before. Could you talk a little bit more about enqueueing the job outside the database transaction?

+ +

CHRIS: Sure. And I think I've talked about this on a previous episode a while back because I have run into this one a few times. But I think it is sufficiently rare; like, you need almost a perfect storm because the database transaction is going to close very quickly. Sidekiq needs to be all that much more speedy in picking up the job in order for this to happen.

+ +

But basically, the idea is within some processing logic that we have in our system; we find a record, we do some work. And then we need to update that record to assign this timestamp or whatever it is. And then we also want to inform the user, so we're going to enqueue a job to send the email notification. But for all of the database work, we are wrapping it in a transaction because we want it to either succeed or fail atomically. So there are three different records that we need to update. We want all of them to be updated or none of them to be updated. So, therefore, we wrap it in a transaction.

+ +

And the way we had written, this was to also enqueue the job from within the transaction. That wasn't something we were actively intentionally doing because those are different systems. It doesn't really mean anything. But we were still within the block of ApplicationRecord.transaction do. We're now inside of that block. We're doing all of the record updates. And then the last piece of work that we want to think about is enqueueing the job to send the email.

+ +

The problem is if we're still within that database transaction if it's yet to be committed, then when Sidekiq picks up that job to run it, it will see the prior state of the world. And it's only if the Sidekiq job waits a little bit that then the database transaction will have been committed. The record is now updated and available to be read by Sidekiq in the correct updated state.

+ +

And so there's this tiny little bit of inconsistency that can happen. It's basically because Sidekiq is going out to Redis, which is a distinct system. It doesn't have any knowledge of the database transaction at play. That's why I sometimes consider using a Postgres-backed background job system because then actually the job can be as part of the database transaction.

+ +

STEPH: Cool. That's helpful. That makes a lot of sense the way you explained the whole you're actually enqueueing the job from inside that transaction. I'm curious, that prompts another question. In the case where you mentioned you're using a transaction because you want to make sure that if something fails to update so, everything gets updated together, in the event that something does fail to update because you were previously enqueueing that job from the transaction, does that mean that the update could have failed but that email would still have gone out?

+ +

CHRIS: That does not. And the reason for that is because we're within dry-monad world. And so dry-monad will implicitly capture the ActiveRecord rollback, which I think is an exception that gets raised or somehow...But basically, if that database transaction fails for any reason and ends up getting rolled back, then dry-monads will not continue processing through the rest of the sequential operation. And so, therefore, even if we move the enqueuing of the email outside of the database transaction, the sequential nature of that processing and the dry-monad stuff that we have in play will handle that. And I think that would more generally be true because I think Rails raises an exception on rollback. Not certain there. But I know in our case, we're fine on that. And we have actually explicitly checked7 for that sort of thing.

+ +

STEPH: So I meant a slightly different question because that makes sense to me everything that you just said where if it's outside of the transaction, then that sequential order won't fire because of that ActiveRecord migration error. But when you have the enqueuing inside of the transaction because then that's going to be inside of the sequential order, maybe before the rollback error gets raised. Does that make sense?

+ +

CHRIS: Yes. I think what you're asking is basically like, do we make sure to not send the job if the rest of the stuff didn't succeed?

+ +

STEPH: I'm just wondering from a transaction perspective, actually. If you have a transaction wrapped block and then you have in there, like, update this record, send email, end block, let's say update...well, I guess it's going raise because you've got probably like an update bank. Okay, so then yeah, you won't get to the next line. Got it. Got it. Got it. I just had to walk myself through that because I forgot that you probably...I have to visualize [laughs] as to what that code probably looks like. All right, that answered my question.

+ +

CHRIS: Okay. So back up to the top level then, this is the problem that we have. And looking through the codebase, we actually have it in a bunch of different places. So the solution in any one of those cases is to just take the line of code where we're saying enqueue UserMailer.deliver_later take that line of code, move it outside of the database transaction, and make sure it only happens if the database transaction succeeds. That's very easy to do in one case.

+ +

But my concern was this is a very easy failure mode to end up in. And this is a very easy incorrect version of the code to write. As far as I can tell, we never want to write the code where this is happening inside of the transaction because it has this failure mode. But how do we enforce that? That was the thing that came to mind. So I immediately did a quick look of like, is there a RuboCop thing I can do here or something?

+ +

And I actually found something even more specific, which was so exciting to find. It's a gem called Isolator. And its job is to detect non-atomic interactions within database transactions. And so it's fantastic. I was like, wait, really? Is this going to do the thing? And so I just installed the gem, configured it where I wanted, and then ran the test suite. And it showed me every place throughout the app right now where we were doing this pattern of behavior like enqueueing work from within a database transaction, which was great.

+ +

STEPH: Ooh, that's really nifty. I kind of want to install that and just run it on my current client's codebase and see what I find.

+ +

CHRIS: This feels like something like strong migrations where it's like, yeah, this is great. I kind of want to have this as part of my core toolset now. This one feels even perhaps slightly more so because sometimes I look at strong migrations, and I'm like, no, no, no, strong migrations, I get why you would say that, but for reasons, this is actually fine. And they have configurations within it to say, like, no, this is okay. Isolator feels like it's always telling me something I want to know. So this, very quickly, I'm like, I think this might be part of my toolset moving forward on every single app forever.

+ +

And actually, there's another gem that I used. It's made by the same team. So this is from the folks over at Evil Martians, which is another Rails consultancy out there in the world. And the Isolator gem is one thing that they've produced. And then I think the same author of it who is an Evil Martian's employee created the after_commit_everywhere gem.

+ +

So after_commit is one of Rails' ActiveRecord callbacks. But in this case, it allows you to use it everywhere, as the name implies. And so rather than actually having to take that line of code out of the database transaction block, which is naturally where we would write it because that's how we think about the code and how we want to express it, you can just use this after_commit method, wrap the call in that, so it's after_commit, and then a block. So either braces or do..end. That enqueueing of the email now just gets wrapped in that. And so what that does is it says, "Defer this until after the transaction commits. If the transaction does not commit, if we roll it back, then don't run it."

+ +

And what was nice is the actual code change when I finally submitted all of this was add the gem to the gem file. And then everywhere that we're doing the wrong thing, which running the test suite told me, I just went in, and I wrapped that line in after_commit and a block. And it was such a nice, clean...like, I didn't have to move the code around or actually shift the lines, which was my first attempt at this. I was able to just annotate each of those lines and say, "You're special, you're special, you're special," And then I'm done. And again, the first gem told me every case where I needed to do that. It's like, well, this is a wonderful little outcome here.

+ +

STEPH: That's really nice, yeah, how you can make the changes and then, like you said, re-run the test or re-run that gem, and it lets you know what else still needs to be updated. I'm intrigued where you mentioned you didn't have to move any lines, though. Maybe I just need to look at the gem and see it, but I'm still envisioning that you have your transaction do block. And then you're doing some things; you're updating records, and then you have your end. And then after that, it's when you want to enqueue the email. And with this after_commit, you actually added that method call inside of the transaction but then wrapped the call to Sidekiq to send the email inside of that block.

+ +

CHRIS: Correct. Yeah. So it's basically like saying, "Here's almost an anonymous function." If you think about a Ruby block in that nomenclature, you're saying, like, here's some work to do when and if the transaction succeeds. And so it meant that I was able to keep the code in the way that we as humans would talk about it but deal with the murky details, and edge cases of database transactions, and Sidekiq, and whatnot. Sort of just handle it by saying like...it almost feels like an annotation or a decoration or something like that. But it was this, in my mind, almost like a perfect melding of I don't want to think about this. Oh, cool. Okay, here's a quick, easy way to deal with it but to not have to fundamentally change how I write the code.

+ +

STEPH: Interesting. So I like all the things you're saying. I'll be honest, I'm not totally sold, and I'm trying to think of why. I think the benefits...one, as you mentioned, it's something you don't have to think about or at least signals to others that hey, maybe you should think about this to the extent that you use after_commit. And so that way, you don't have these asynchronous events taking place inside the transaction. So I like that visibility and communication to the rest of the team. Putting it inside of the transaction feels interesting. I don't know why; I feel a little weird about this. [laughs] I'm bringing my true self.

+ +

CHRIS: That's fair. So if we're being honest, I solved this first by finding the Isolator gem. Well, I solved it first by just doing it manually. I went through the app, and I found all the places. And I was like, you know what? I'm worried that the next person authoring code like this, it's so easy to fall into this trap. Like, this is such a subtle little thing that our brains are not thinking about. And so I had first fixed it, and so I had a diff that involved moving lots of lines of code, every instance of this moved from being in the database transaction out of it. And that was fine. I was fine with that as a solution. But it was a little bit noisy because I was moving a bunch of lines.

+ +

So then I brought in the Isolator gem. I actually reset that, and I went back to before I had made the fix, ran the test just to make sure Isolator was actually finding every instance. They did; that was great. So I was like, all right, cool. This is better because now I have this thing that will tell anyone when this happens. So I'm very happy about that. Because frankly, this is some hard-earned knowledge that I had to read Sidekiq and remember how database transactions work and convince myself of what was going on here and finally come to what I believe the solution is.

+ +

And now Isolator is just like, cool, that's encapsulated. And it gives a very nice failure message in the test suite. So it's like, excellent. I really like this. But still looking at it, the diff, the amount of code that I had to change, it's like, well, naturally, this is how we want to write this code, but for reasons, we can't. And it's appeasing the computer more than it's appeasing the reader or the author of the code.

+ +

And so then I happen to be reading through the Isolator gem's README, and they mention the after_commit_everywhere gem. And I was like, oh, that's interesting. So one more time, I reset. And then I really tried fixing it with after_commit. And the look of the diff there felt nice to me because the lines got a little more on them, but they didn't move. And so it's like, this is how we naturally would have authored it, and now it works correctly. And I liked that.

+ +

But I understand your hesitation because you're like, but the thing is, it's wrong. And so you've made the wrong not wrong anymore, but you didn't...and so I get your hesitation. I still like the fancy version.

+ +

STEPH: Yeah, I think you just helped me figure out my grumpiness with it or why I'm not totally sold on it. And it was in regards to adding a dependency to avoid a noisy diff is the oversimplified version that I was processing or the reason that I was a bit grumpy about adding this other gem for that. But then you also just brought a lot of other really good reasons.

+ +

One thing that you said that I do really like is adding tools that help us author code in a more natural style, the way that we want to highlight this process, and how this application does work, and how this business logic flows. So given in that light, that makes me feel better about it. But yeah, I think that was my initial grumpiness. I was like, it’ll be a noisy diff. It's okay.

+ +

CHRIS: I think I definitely share your hesitation, or you're like, hmm, that's an interesting reason to bring more code into the application. But at the same time, I think the counterpoint that comes to mind for me is we're using Ruby because of its expressiveness; at least, that's why I'm using Ruby. I really want the code that I write to be as close as possible to the thing that I would say to another human about like, oh okay, when a user signs up for the application, we need to create a record in our system, and then we need to send them an email. And then we need to do this other thing. And so, the closer that our code is to those words that I would use to describe to another human, the happier I am.

+ +

And I will put in some pretty significant effort to hold that line as long as the code can also be correct. And so, the Isolator gem here does a great job of enforcing that correctness. And then after_commit allows me to still maintain that expressiveness and not have to think about the murky details as much or not have to reshape my code to match the murky realities of different persistence engines.

+ +

But I do agree. I think it's a good thing to look at and ask, like, is it worth it? Are you sure? And in this case, I will say, "Yeah, I think so," but with that amount of certainty in my voice, [chuckles] which is not a ton.

+ +

STEPH: I think this is going back to my days of working with dependency bot PRs where every time there was an upgrade for a gem, I always ask, what do you do here? [chuckles] Do we need to upgrade you? Can we just remove you from the codebase? So I'm fairly...I don't know, resistant is a strong word. I'm skeptical of when we're adding stuff in, and I just want to question the value that it's adding.

+ +

But I want to circle back to something that you said, and that is hard-earned knowledge. And that part I understand so much where when you have gone through a fair amount of work to uncover an issue, and then you want to make sure that others don't have to go through that. This is a really nice way to highlight; hey, there's something that's tricky about computers and software here, and we need to watch out for that. And I want to help you lookout for that. Versus this is just inherit information where this needs to happen outside or after that transaction. And so that makes a really nice entry point where someone can look to say, "Why did we add this gem?" And then there's a commit message that goes with it that explains this is why we use this after_commit gem because we're specifically looking to avoid this type of bug. And I love that.

+ +

CHRIS: Yeah, I think more lines of git commit message than diff on this one. So yeah, I wrote a short novel describing all of the features, describing the different pieces that are coming together. And then it's actually a +28 -6 diff. So it's a very small code change. But yeah, lots of story captured there.

+ +

STEPH: And if you had just moved the lines, you could still have that commit message. But it's not likely that someone's going to look up that git commit change or that message that went along with it because they're not going to know to blame that one. But if they look at that particular edition of after_commit, they're more likely to find that historical context. So long story short, I think you have walked me through my initial grumpiness and provided some really good ways to avoid that really tricky failure mode for other developers.

+ +

CHRIS: Well, thank you. I'm getting Steph's seal of approval starting from grumpy places. [laughs] I feel good. All right.

+ +

STEPH: I'll have some special Stephanie's approval stickers designed and printed for you.

+ +

CHRIS: I hope you're not joking because I very much want a yellow heart that says, "Steph-approved."

+ +

STEPH: [laughs]

+ +

CHRIS: And I can put it on PRs, and I can put it on the wall. [laughs]

+ +

STEPH: Well, now I have to find a sticker designer and make a...well, it's just a yellow heart. I can probably handle this. I'm going to use Comic Sans. That will be the approved part. [laughs] Yellow hearts and Comic Sans for everybody.

+ +

CHRIS: Well, with that absolutely fantastic call back to earlier parts of the episode, shall we wrap up?

+ +

STEPH: Let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+QpmMHX6Q + + ]]> + + Chris Toomey + Steph Viccari + + + 312: Spooky Stories + https://bikeshed.thoughtbot.com/312 + bd395661-a136-43c9-a216-981c488c9a13 + Tue, 12 Oct 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris evaluates the pros and cons between using Sidekiq or Active Job with Sidekiq. He sees exceptions everywhere. + +Steph talks about an SSL error that she encountered recently. It's officially spooky season, y'all! + 38:50 + no + + + Chris evaluates the pros and cons between using Sidekiq or Active Job with Sidekiq. He sees exceptions everywhere. +Steph talks about an SSL error that she encountered recently. It's officially spooky season, y'all! +sidekiq-symbols (https://github.com/aprescott/sidekiq-symbols) +Transcript: +CHRIS: Additional radiation just makes Spider-Man more powerful. +STEPH: [laughs] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? +CHRIS: Fall is in the air. It's one of those, like, came out of nowhere. I knew it was coming. I knew it was going to happen. But now it's time for pumpkin beer and pumpkin spice lattes, and exclusively watching the movie Hocus Pocus for the next month or so or some variation of those themes. But unrelated to that, I did a thing that I do once, let's call it every year or so, where I had to make the evaluation between Sidekiq or Active Job with Sidekiq, as the actual implementation as the background job engine that is running. And I just keep running through this same cycle. +To highlight it, Active Job is the background job system within Rails. It is a nice abstraction that allows you to connect to any of a number of them, so I think Delayed Job is one. Sidekiq is one. Resque is probably another. I'm sure there's a bunch of others. But historically, I've almost always used Sidekiq. Every project I've worked on has used Sidekiq. But the question is do you use Active Job with the adapter set to Sidekiq and then you're sort of living in both worlds, or do you lean in entirely and you use Sidekiq? And so that would mean that your jobs are defined to include Sidekiq::Worker because that's the actual thing that provides the magic as opposed to inheriting from Application Job. And then do you accept all of the trade-offs therein? And every time I go back and forth. And I'm like, well, but I want this feature, but I don't want that feature. But I want these things. So I've made a decision, but I want to talk ever so briefly through the decision points that were part of it. Have you done this back and forth? Are you familiar with the annoying choice that exists here? +STEPH: It's been a while since I've had the opportunity to make that choice. I'm usually joining projects where that decision has already been made. So I can't think of a recent time that I've thought through it. And my current project is using that combination of where we are using Active Job and Sidekiq. +CHRIS: So I think there's even a middle ground there where that was the configuration that I'd set up on the project that I'm working on. But you can exist in both worlds. And you can selectively opt for certain background jobs to be fully Sidekiq. And if you do that, then instead of saying, "Performlater," You say, "Performasync." And there are a couple of other configurations. It gives you access to the full Sidekiq API. And you can do things like hey, Sidekiq, here's the maximum number of retries or a handful of other things. But then you have to trade away a bunch of the niceties that Active Job gives. +So as an example, one thing that Active Job provides that's really nice is the use of GlobalID. So GlobalID is a feature that they added to Rails a while back. And it's a way to uniquely identify a given record within your system such that when you say performlater, you can say, InvitationMailer.performlater and then pass it a user record so like an instance of a user model. And what will happen in the background is that gets serialized, but instead of serializing the whole user object because we don't actually want that, it will do the GlobalID magic. And so it'll turn into, I think it's GID:// so almost like a URL. But then it'll be, I think, your application name/model name down the road. And the Perform method actually gets invoked via the background system. Then you will just get handed that user record back, but it's not the same instance of the user record. It sort of freezes and thaws it. It's really nice. It's a wonderful little feature. Sidekiq wants nothing to do with that. +STEPH: I'm so glad that you highlighted that feature because that was on my mind; I think this week where I was reviewing...somebody had made the comment where they were concerned about passing a record to a job and saying how that wouldn't play nicely with Sidekiq. And in the back of my mind, I'm like, yeah, that's right. But then I was also I'm pretty sure this got addressed, though. And I couldn't recall specifically if it was a Sidekiq enhancement or if it was a Rails enhancement. So you just cleared something up for me that I had not had time to confirm myself. So thanks. +CHRIS: Well, to be clear, this works if you are using Active Job with Sidekiq as the adapter, but not if you are using a true Sidekiq worker. So if you opt-out of the Active Job flow, then you have to say, "Perform_async," and if you pass it a record, that's not going to work out particularly nicely. +The other similar thing is that Sidekiq does not allow the use of keyword args, which, I'm going, to be honest, I really like keyword arguments, especially for background jobs or shuttling data through your system. And there's almost a lazy evaluation. I want some nicety to make sure that when I am putting something into a background job that I'm actually using the correct call signature, essentially passing the correct data in the correct shape. Am I passing a record, or am I passing the ID? Am I passing a list of options or a single option? Those sort of trade-offs that are really easy to subtly get wrong. +I came around on this one because I realized although Active Job does support keyword arguments, the way it does that is it just has a JSON serialization format for them. So a keyword argument turns into a positional array with an associated hash that allows for the lookup or whatever. Basically, again, they handle the details. You get to use keyword args, which is great, with the exception that when you're actually calling performlater, that method performlater is a method missing type magic method. So it does not actually check the keyword arguments at that point. You're basically just passing an options hash as opposed to true keyword arguments that would error because they don't match up. And so when I figured that out, I was like, oh, never mind. This doesn't actually do the thing that I care about. It's a little bit nicer in terms of the signature of the method when you're defining your background job itself, but it doesn't actually do any logical checking. It doesn't give me any safety or robustness within my system. So I don't care about that. +I did find a project called sidekiq-symbols, which does some things under the hood to how Sidekiq serializes and deserializes jobs, which I think gives largely the same behavior as Active Job. So I can now define my Sidekiq jobs with keyword arguments. Things will work. I can't use GlobalID. That's still out. But that's fine. I can do a little helper method that basically does the same thing as GlobalID or at least close approximation. But sidekiq-symbols lets me have keyword arg-like signatures in my methods; basically, it is. But again, it doesn't actually do any check-in when I'm enqueueing a job, and I am sad about that. +STEPH: Yeah, that's another interesting distinction. And I'm unsurprisingly with you that I would favor having keyword args and having that additional safety in place. Okay, so I've been keeping track. And so far, it sounds like we have two points because I'm doing a little scorecard here between Active Job and Sidekiq. And we have two points in favor of Active Job because they offer a GlobalID, which then allows us to pass in a record, and then it takes care of the serialization for us. And then also, keyword args, which I agree with you that's a really nice feature to have in place as well. So I'm curious, so it sounded like you're leaning towards Active Job, but I don't want to spoil the ending. +CHRIS: Yes, I could see why that's what you would be taking away from the conversation thus far. So again, just to reiterate, Active Job and Sidekiq with this sidekiq-symbols extension they both support keyword args, kind of. They support defining your job with keyword args and then enqueueing a job passing something that looks like keyword args. But it ends up...nobody's actually checking anything, so it's mostly like a syntactic nicety as opposed to any sort of correctness, which is still nicer, but it's not the thing that I actually want. Either way, nobody supports it, so it is not available to me. Therefore, it is not a consideration point. +The GlobalID thing is nice, but it is really, again, it's a nicety more than anything. I have gone, and I'm leaning in the direction of full Sidekiq and Sidekiq everywhere as opposed to Active Job in most cases, but then Sidekiq when we need it. And that's because Sidekiq just has a lot more power and a lot more functionality. So, in particular, Sidekiq has a feature which allows you to say...it's a block that you put at the top of your Sidekiq job that says retries exhausted or something. I think Sidekiq retries exhausted is the actual full name of that at that point, which is really unfortunate in my mind, but anyway, I'll deal. At that point, you know that Sidekiq has exhausted all of the retries, and you can treat it as failed. +I'm going, to be honest, I went on a quest to find a way to say, hey, I'm going to put some work into the background. It's really important for me to know if this work succeeds or if it fails. It's very easy to know if it succeeds because that just happens in-line in the method. But we can have an exception raised at basically any point; Sidekiq does a great job of catching those, of retrying, of having fundamental mechanisms there. But this is the best that I can get for this job failed. And so Active Job, as far as I can tell, does not have anything for this in order to say, yep, we are done. We are not going to keep working on this. This work has failed. It is dead. +Dead is; actually, I think the more correct term for where we're at because failed is a temporary state, and then you retry after a failure. Whereas dead is, this has gone through all of its retries, and it will never be run again. Therefore, we should treat this as not having run. And in my case, the thing that I want to do is inform the user that this operation that we were trying to do on their behalf has not succeeded, will not succeed. And please reach out or otherwise deal with the fact that we were unable to do the thing that they asked us to do. That feels like a really important thing for me to be able to do, to be able to communicate back to my users. +This is one of those situations where I'm looking at the available options, and I'm like, I feel like I can't be the only one who wants to know when something goes wrong. This feels like a thing that's important. But this is the best example that I've found, the Sidekiq retries exhausted block. And unfortunately, when I'm using it, it gets yielded the Sidekiq JSON blob deserialized, so it's like Ruby hash. But it's still like this blob of data. It's not the same data that gets passed into perform. And so, as a result, when I want to look up the record that was associated with it, I have to do this nested dig into the available hash of data. And it just feels like this is not a well-paved path. This is not something that is a deeply thought about or recommended use case. But again, I don't feel like I'm doing something weird here. Am I doing something weird, Steph, wanting to tell my users when I was unable to do the thing they asked me to do? [chuckles] +STEPH: That feels like a very rhetorical question. [laughs] +CHRIS: It does. I apologize. I'm leading the witness. But in your sincere heart of hearts, what do you think? +STEPH: No, that certainly doesn't sound weird. I'm actually thinking back to some of the jobs that cause me stress in regards to knowing when they failed and then having that communication of knowing that we've exhausted all the retries. And, of course, knowing when those retries are exhausted is incredibly helpful. +I am intrigued, though,, because you're highlighting that Active Job doesn't have the same option around setting the retry. And I'm trying to recall exactly how it's set. But I feel like I have set the retry count for Active Job. And maybe, as you mentioned before, that's because it's an abstraction, or I'm not sure if Active Job actually has that native support. So I feel a little confused there where I think my default instinct would have been Active Job does have that retry capability. But it sounds like you've discovered otherwise. +CHRIS: I'm not actually sure what Active Jobs core retry logic or option looks like. So fundamentally, as far as I understand it, Active Job is an abstraction. And under the hood, you're always connecting an adapter. So it's either going to be Sidekiq, or Resque, or Delayed Job, or other. And each of those systems, whichever system you have as the adapter, is the one that's actually going to be managing retries. And so I know Sidekiq happens to have as a default 25 retries. And that spans, I think it's a two-week exponential back off. And Sidekiq has some very robust logic that they have implemented as the way retries exist within Sidekiq. I'm not sure what that would look like if you're trying to express it abstractly because it is slightly different. +I know there was some good work that was done on Sidekiq to allow the Sidekiq options that's a method at the top level of the job, even if it's an Active Job job to express the retries. So that may be what you've seen, or there may be truly an abstraction that exists within Active Job, and then each adapter needs to know how to handle retries. But frankly, the what can Sidekiq do that Active Job can't? There's a whole bunch of stuff around limiting when you would retry limiting, enqueuing a job if there already exists one, when and how do those records get locked. There's a whole bunch of stuff. +Sidekiq has a lot of power under the hood. And so if we want to be leaning into that, that's why I'm leaning towards let's just be Sidekiq all the time. Let's become Sidekiq experts. Let's accept that as a deep architectural decision within the app as opposed to just relying on the abstraction. Because fundamentally, if we're just using Active Job, we're not going to have access to the full power of Sidekiq or whatever the underlying system is, so sort of that decision that I'm making, but I don't know specifically around the retries. +STEPH: Okay, thanks. That's really helpful. It's been a while since I've had to make this decision. I'm really enjoying you sharing your adventure because I'm trying to think what's the risk? If you don't use Active Job, what are the trade-offs? And you'd mentioned some of them around the GlobalID and keyword args, which are some niceties. But overall, if you don't go with the abstraction, if you lean into Sidekiq, the risk is then you want to migrate to a different enqueuing service. And something that we talk about is mitigating that risk, so then you can swap it out. That's also something I have never done or encountered where we've had to make that change. And it feels like a very low risk in my mind. +CHRIS: Sidekiq feels like the thing you would migrate to, not a thing you would migrate from. It feels like it is the most powerful. And if anything, I expect at some point we'll be upgrading to Sidekiq pro or enterprise or whatever the higher versions that you pay for, but you get more features there. So in that sense, that is the calculation. That's the risk trade-off in my mind is that we're leaning into this technology and coupling ourselves more closely to it. +But I don't see that as one that will reassess in the same way that people talk about Active Record and it being an ORM. And it's like, oh, we're abstracting the database underneath, and I'm like, no, I'm not. I'm always using Postgres. Please do not take Postgres. I'm not going to switch over to MySQL next week. That's totally fine if you start on MySQL. It's unlikely you're going to port over to Postgres. We may port to an entirely…like it's a Cassandra column store with a Kafka queue, I don't know, something weird down the road. But it's not going to be swapping out Postgres for MySQL or vice versa. Like you said, that's probably not a change that's going to happen. But that I think is the consideration. +The other consideration I have in my mind is Active Job is the abstraction that exists within Rails. And so I can treat it as the lowest common denominator, and folks joining the project, it's nice to have that familiarity. So perform_later is the method on the Active Job jobs, and it has a certain shape to it. People may be familiar with that. Mailers will automatically use Active Job just implicitly under the hood. And so there's a familiarity, a discoverability. It's just kind of up the middle choice. And so if I can stick with that, I think there's a nicety there. But in this case, I think I'm choosing I would like the power and consistency on the Sidekiq side, and so I'm leaning into that. +STEPH: Yeah, that makes a lot of sense to me. And I liked the other example you provided around things that were not likely to swap out and Postgres, MySQL, your database being one of them. And in favor of an example that I do have for something that...I do enjoy wrapping. It's not something that I adhere to strictly, but I do enjoy it when I have the space to make this choice. So I do enjoy wrapping HTTPClients, not just because then I can swap it out for a different HTTPClient, which frankly, that's also rare that I do that. Once I choose an HTTPClient, I'm probably pretty happy, and I don't need to swap it out. +But I really like being able to extend to the API specifically if they don't handle error responses in a way that I would like to or if they raise, and then I want to change the API to have a more thoughtful interface and where I don't have to rescue those errors. But instead, I can interact with this object that then represents an error state. So that was just one example that came to mind for things that I do enjoy having an abstraction around and not just so I can swap it out because that feels like a very low risk, but more frankly, so I can extend the API. +CHRIS: I definitely share the I almost always wrap APIs, or I try and hide whatever the implementation detail whether it be HTTPParty, or Faraday or whatever it is that I'm using and trying to hide that deeply within the system. And then I have whatever API client that we define. And that's what we're interacting with. It's interesting that you bring up errors and exceptions there because that's the one other thing that has caused me this...what I'm describing now seems perhaps like, oh, here's just a list of pros and cons, a simple decision was made, and there we are. +This represents some real soul searching on my part, if we will. And one of the last things that I ran into that was just so frustrating is that Sidekiq is explicitly built around the idea of exceptions; Sidekiq retries if there is an exception raised in the job, otherwise, it treats it as success, and that's it. That is the entirety of it. That is the story. But if you raise an exception in a job, then you can't test that job because now it's raising an exception. You can't test retries or this retry exhausted block that I'm trying to lean into. I'm like, I want to put that in a feature spec and say, oh, this job goes in the background, but it's in a failure state, and therefore, the user sees the failure message. Sorry, I can't do that because the only way to actually fail a job is via an exception. +And I've actually gone to some links in this application to try to introduce more structured data flow. I've talked a bunch about the command objects and the dry-monads and all those things. And I've really loved them where I've gotten to use them. But then I run into one of these edge cases where Sidekiq is like, no, no, no, you can't do that. And so now I have parts of my system that very purposefully return data as opposed to raising an exception. And I just have to turn around and directly raise that failure as an exception, and it just feels less expressive. +I actually just ran into the identical thing with Pundit. They have a little bit better control over it; I can choose whether or not I want the raising version or not. But I see exceptions everywhere, and I want a little more discrete data flow. [chuckles] That is my dream. So anyway, I chose Sidekiq is the summary here. And slowly, we're going to migrate entirely to Sidekiq. And I'm going to be totally fine with it. And I'm done griping now. +STEPH: This is your own little October Halloween movie, that I see exceptions everywhere. +CHRIS: They're so spooky. +STEPH: [laughs] That's cool about Pundit. I'm not sure I knew that, that you get to essentially turn on or off that exception flow behavior. On one hand, I'm like, that's nice. You get the option. On the other hand, I'm like, well, let's just not do it. Let's just never raise on people. But at least they give people options; that seems really cool. +CHRIS: They do give the option. I think you can choose different strategies there. And also, if we're being honest, I'm newer to Pundit. And I used a different thing, which was to get the Policy Object and ask it a question. I wanted to ask, is this enabled or not? Can a user do this or not? That should not raise an exception. I'm just asking a question. We're just being real chill about this. I just want to know some information. Let's flow some data through our system. We don't need exceptions for that. +STEPH: Why are you yelling at me? I just have a question. [laughs] +CHRIS: Yeah. I figured out how to be easy on that front. Sidekiq apparently has no be easy mode, but that's fine. You know what? We're going to make it work, and it's going to be fine. But it is interesting deciding which of these facets of the system that I'm building do I really care about? Which are the ones where I'm like, whatever, just pick something, and we'll move forward, it's not a big deal? Versus, we're actually going to be doing a lot of work in the background. This is the thing that I care about deeply. I want to know about failure and success. I want to really understand that and have a robust answer to what our architecture looks like there. +Similarly, Pundit for authorization. I believe that authorization will be a critical aspect of our system. It's typically a pretty important thing. But for us, I think we're going to have different types of users who can log in and see different subsets of data and having a consistent and concrete way that we have chosen to implement that we are able to test, that we're able to verify. I think that's another core competency within the app. But you only get to have so many of those. You can only be really good at a couple of things. And so I'm in that place where I'm like, which are our top five when I say are the things that I care a lot about? And then which are the things where I'm like, I don't know, whatever, just run with it? +STEPH: Just a little bit ago, I came so close to singing because you said the I want to know phrase again. And that, I'm realizing, [laughs] is a trigger for me and a song where I want to sing. I held it back this time. +CHRIS: It's smart. You got to learn anytime you sing on mic that is part of the permanent record. +STEPH: Edward Loveall at thoughtbot, since I sang in a recent episode, did the delightful thing where then he grabbed that clip of where you talk a little bit, and then I sing and then encouraged everyone to go listen to it. And in which I responded, like, I would highly recommend that you save your ears and don't listen to it. But yes, singing on the mic is a thing. I do it from time to time. I can't hold it back. +CHRIS: We all do. But since it doesn't seem that you're going to sing in this moment, I think I can probably wrap up my Odyssey of choosing between Sidekiq and Active Job. I hope those details were useful to anyone other than me. It was an adventure, so I figured I'd share it. But yeah, that about wraps it up on my side. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: So, I would love to talk about an SSL error that I encountered recently. So one of the important processes in our application is sending data to another system. And while sending data to that other system, we started seeing the following error that the read "Certificate verify failed." And then in parens, it states, "Unable to get local issuer certificate." So upon seeing that error, I initially thought, okay, something is wrong with their SSL certificate or their SSL configuration. And that's not something that I have control over and can fix. So we should reach out and let them know to take a look at their SSL config. +But it turns out that their team already knew about the issue. They had recently updated or renewed their SSL cert, and they saw our messages were no longer being processed, and they were reaching out to us for help. So at that point, I'm still pretty sure that it's related to something on their end, and it's not something that I can really fix on our end. But we can help them troubleshoot. Maybe there's a workaround that we can add to still get messages processing while they're looking into their SSL config. It seemed like they still just needed help. So it was something that was still worth diving into. +So going back to the first error, I want to talk a little bit about it because I realized that I understand SSL just enough, just the surface to get by as a developer. But then, every time that I run into a specific error with it, then I really have to refresh my understanding as to what could be wrong, so then I can troubleshoot more effectively. +So for anyone that could use a refresher on that certificate verification process, when your browser or your server is connecting to a site that uses SSL, then your browser server, whichever one you're using, is going to download that site certificate and verify a couple of things. So it's going to check does the certificate contain the domain name of the website? So essentially, you gave us a certificate. Is this your certificate? Does it match the site that we're connecting to? Is this cert issued by a trusted certificate authority? So did someone that we trust give you this certificate? And is the cert still valid, or has it expired? So that part is pretty straightforward. +The second part, "Unable to get local issuer certificate," so that's the part I was less certain about. And I took this to mean that they had passed two of those three checks that their cert included the site's name, and it had not expired. But for some reason, we aren't able to determine if their cert was issued by someone that we should trust. +So following that journey, my next question was, so what are they giving us? So this is a tool that I don't get to use very often, but I reached for OpenSSL and, specifically, the s_client command, which connects to a specified domain and prints all certificates in the certificate chain. You may already know this, but the certificate chain is basically a fancy way of saying, show me all the certificates necessary to prove your site certificate was authorized by a trusted certificate authority. +CHRIS: I did not know that. +STEPH: Okay, I honestly didn't either. [laughs] +CHRIS: I liked that you thought I would, though. So thank you, but no. [chuckles] +STEPH: Yeah, it's one of those areas of SSL where I know just enough. But that was something that was new to me. I thought there was a site certificate, and I didn't realize that there is this chain of certificates that has to be honored. +So going back and looking through that output of the certificate chain, that's what highlighted to me that their server was giving us their certificate and saying, hey, you should trust our site certificate. It's legit because it was authorized by, let's say, XYZ certificate. And so if it were a proper certificate chain, then they would give us that XYZ cert. And essentially, we can use this chain of certificates to get back to a trusted authority that then everybody knows that we can trust. However, they weren't actually giving us a reference certificate; they were giving us something else. So essentially, they were saying, "Hey, look at our certificate and look at this very trustworthy reference that we have." But they're actually failing to give us that reference. +So to bring it all home, we can download that intermediate certificate that they reference; that is something that is publicly accessible. That's why we're able to then verify each certificate that's provided in that chain. We could go and download that intermediate certificate from that certificate authority. We could combine that with their site-specific certificate, include that in our request to their system, and then complete the certificate chain. And boom, we're back in business. But it was quite a journey. +CHRIS: That is quite the journey. And yeah, I definitely knew very little of that, although everything you're saying makes sense. And I have a bunch of cubbyholes in my brain for SSL knowledge. And the words you said all fit into the spaces that I have in my brain, but I didn't know a bunch of those pieces. So thank you for sharing that. +SSL and cryptography, more generally or password hashing or things like that, occupy this special place in my brain where I'm both really interested in them. And I will occasionally research them. If I see a blog article, I'll be like, oh yeah, I want to read more about this password hashing. And what's a Salt? And what's a Pepper? And what are we doing there? And what is BCrypt versus SCrypt? What are all these things? This is cool. And almost the arms race on the two sides of how do we demonstrate trust in a secure manner on the internet? +But at the same time, I am not allowed to do anything with this information. I outsource this as much as humanly possible because it's one of those things that you just should not do yourself and SSL perhaps even more so. So I have configured aspects of my password hashing. But I 100% just lean on the fact that Let's Encrypt exists in the world. And prior to that, it was a little more work. But frankly, earlier on in my career, I wasn't dealing with the SSL parts of things. But I'm so grateful to Let's Encrypt as a project that exists. +And now, on almost every platform that I work with, there's just a checkbox for please do the SSL work for me, make it good, make it work, and then I will be happy. And I'm so glad that that organization exists and really pushed the envelope also. I forget what it was, but it was only like three years ago where SSL was not actually nearly as common as it is now. And now it is pervasive and everywhere. And all of the sites have it, and so that is a wonderful thing. But I don't actually know much. I know that I should have it. I must have it. I should force it. That's true. So I push that out… +STEPH: Hello. +CHRIS: Are you trying to get me to sing? [chuckles] +STEPH: [laughs] No, but I did want to know if you get the reference, the Salt-N-Pepa. +CHRIS: Push It Real Good the song? Yeah, okay. +STEPH: Yeah, you got it. [chuckles] +CHRIS: I will just say the lyrics. I shall not sing the lyrics. I would say that, though, that yes, yes, they do that. +STEPH: Thank you for acknowledging my very terrible reference. Circling back just a little bit too in regards to...I'm with you; this is a world that is not one that I am very deeply technical in and something that I learned a fair amount while troubleshooting this particular SSL error. And it was very interesting. But there's also that concern where it's like, that was interesting. And we worked around the issue, but this also feels very fragile. +So we still haven't fixed it on their end where they are sending the wrong certificate. So then that's why we had to do more investigative work, and then download the certificate that they meant to send us, and then send back a complete certificate chain so that we don't have this error anymore. But should they change anything about their certificate, should they renew anything like that, then suddenly, we're going to break again. And then, the next developer is going to have to go through the same journey. And this wasn't a light journey. This was a good half-day journey to figure out what was going on and to spend the time, and then to also get that fix out to production. So it's a meaningful task that I don't want anyone else to have to go through. +But we are relying on someone else updating their configuration. So, on one hand, we're in a good spot until they are able to update. But on the other hand, I wrote a heck of a commit message for the next person just describing like, friend, just grab some coffee if we're going to chat. It's a very small code change, but you need to know the scoop. So should you need to replicate this because they've changed something, or if this happens…because we work with a number of systems that we send data to. So if someone else should run into a similar issue, they will understand some of the troubleshooting techniques that I used and be able to look up that chain and find out if there's a missing cert or something else they need to provide. So it feels like a win, but I'm also nervous for future selves, future developers. +So there's another approach that I haven't mentioned yet, but it was often a top recommendation for when dealing with SSL errors. And specifically, it was turning off SSL verification. And I saw that, and I was like, well, that won't work. I'm definitely sending sensitive, important data. And I need to verify that who I'm sending this to is really the person that I want to send this data to. So that was not an option for me. But it made me very nervous how often that was an approach that people would recommend and be like, oh, it's okay, just turn off SSL. You'll be fine. Like, don't worry about it. +CHRIS: I feel like this so perfectly fits into the...some of our work is finding the information and connecting the pieces together and making it work. But some of it is that heuristic sense, that voice in the back of your head that is like, wait, I'm sorry, what? You want me to just turn off the security perimeter and hope that the velociraptors won't come in? That doesn't seem like it's going to end well. I get that that's an easy option that we have available to us right now and will solve the immediate problem but then let's play this out. There are four or five Jurassic Park movies now that tell the story of that. So let's be careful. +STEPH: It always ends super well, though, right? Like, it's totally fine. [laughs] +CHRIS: [laughs] Exclusively. Although it's funny that you mentioned OpenSSL no verify because just this past week, I used that very same configuration. I think it was okay in my case; I’m pretty sure. But it is interesting because when I saw it, I was like, oh no, can't do that. Certainly not that. Don't turn off the security feature. That's the wrong way to deal with the issue. +But in the particular case that I'm working with, I'm using Redis, Heroku Redis, in particular, in a Heroku configuration. And the nature of how Heroku configures the Redis instances and the connectivity to our app into our dyno...I forget why. I read an article. They wrote it; Heroku wrote it. I trust them; they’re good. I've outsourced my trust to people that I do trust. The trust chain actually maps really well to the certificate trust chain. I trust that Heroku has taken security deeply seriously. And for some reason, their configuration of Redis requires that I turn on OpenSSL no verify mode. So I'm using this now both in Sidekiq, and then we're using our Redis instance for our Rails cache as well. +So in both cases, I said, "It's fine. Don't worry about it." I used the Don't worry about it configuration. And I didn't love it but I think it's okay. And partly, I'm trying to say this into the internet radio right now just in case anyone's listening who's like, no, no, no, you can't do that. That's bad. So I'm willing to be deeply wrong on the internet in favor of someone telling me and then I get to get out in front of it. But I think it's fine. Pretty sure it's fine. It should be fine. +STEPH: I love love love that you gave a very visual example of velociraptors, and then you're like, oh, but I turned it off. [laughs] So I'm going to start sending you a velociraptor gif each day. +CHRIS: I hope you do. I hope the internet holds you accountable to that. +STEPH: [laughs] +CHRIS: And I really look forward to [laughs] moving forward because that's a great way to start the day. Well, it doesn't need to start the day, but I look forward to them. +STEPH: [laughs] I am really intrigued because I'm with you. Like you said, there are certain entities that are in our trust chain where it's like, hey, you are running this for us, and so I do have faith and trust in you that you wouldn't steer me wrong and provide a bad recommendation. Someone on Stack Overflow telling me to turn off SSL verify uh; that’s not my trust chain. Heroku or someone else telling me I'm going to take it a little more seriously. And so I'm also interested in hearing from...what'd you say? You're speaking into the internet phone. [laughs] What'd you say? +CHRIS: I think I said internet radio. But yeah, in a way. I mean, we're recording over Skype right now. So in a manner of speaking, we're on the internet phone to make our internet radio show. +STEPH: [laughs] Oh goodness, the internet radio. I'm also intrigued to hear if other people are like, oh, no, no, no. Yeah, that sounds like an interesting scenario. Because I would think you'd still want your connection to...you said it's for Redis. So you still want that connection to be verified. But then if Redis itself can't have a specific...yeah, we're testing the boundaries of my SSL knowledge here as to how the heck you would even establish that SSL connection or the verification process. +CHRIS: Me too. And it also exists in an interesting space where Heroku is rather clear in their documentation about this. And it was a surprising claim when I saw it. And so, I don't expect them to be flippant about a thing that is important. Like, if they're like, "No, no, no, it is okay. You can turn off the security thing, don't worry." I trust that they're not just like, oh, we didn't think about it too much. But we figured why not? It's not a big deal. I'm sure that they have thought about it deeply because it is an important thing. +And so in a weird way, my trust of them and the severity of what this thing represents, I'm like, oh yeah, I super trust that because you're not going to get a major thing wrong. You might get a minor, small, subtle thing wrong. But this is a pretty major configuration change. As I say it, I'm now getting more worried. I'm now like, I feel fine about this. This doesn't seem like a problem at all. But then I keep saying stuff, and I'm like, oh no. That's why I love having a podcast; I find out things about myself as I talk into a microphone to you. +STEPH: We come here to share our deep, dark developer secrets. +Chris: Spooky developer therapy. +STEPH: But just to clarify, even though you've turned off the SSL verify, you're still connecting over SSL. +CHRIS: Yes, I believe that's the case. And if I'm remembering, I think the nature of how this works is they're using a self-signed certificate because of shared infrastructure or something, something that made sense when I read it. But it was the idea that they are doing a self-signed certificate. Therefore, to what you were talking about earlier, there isn't the certificate authority in the chain of those because it's self-signed. And so, they are not a trusted certificate authority. Therefore, that certificate that they have generated would not be trusted. But it does still allow for the SSL handshake and then communication to happen over SSL. It's just that fundamental question of trust. I'm saying, in this case, for reasons, it's okay. Trust me that I trust them. We're good. Which, again, I don't feel great about, but I think yes, it is still SSL, but it is a self-signed certificate. So we have to make this configuration change. +STEPH: Yeah, all of that makes sense. And it certainly sounds like you have been very thoughtful about that change and put in some investigative work. So on that note, I have a very unrelated bad joke for you. +CHRIS: I'm very excited. +STEPH: All right, here we go. All right, so what do you call an alligator wearing a vest? +CHRIS: I don't know. What do you call an alligator wearing a vest? +STEPH: An investigator. +[laughter] +On that note, shall we wrap up? +CHRIS: Oh, let's wrap up. We should also include a link in the show notes to the episode where you told the joke about the elephant hiding in the trees because that's one of my favorite jokes. You slayed me with that one. [laughs] But on that note, yes, let us wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,,as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeee!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris evaluates the pros and cons between using Sidekiq or Active Job with Sidekiq. He sees exceptions everywhere.

+ +

Steph talks about an SSL error that she encountered recently. It's officially spooky season, y'all!

+ + + +

Transcript:

+ +

CHRIS: Additional radiation just makes Spider-Man more powerful.

+ +

STEPH: [laughs] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: Fall is in the air. It's one of those, like, came out of nowhere. I knew it was coming. I knew it was going to happen. But now it's time for pumpkin beer and pumpkin spice lattes, and exclusively watching the movie Hocus Pocus for the next month or so or some variation of those themes. But unrelated to that, I did a thing that I do once, let's call it every year or so, where I had to make the evaluation between Sidekiq or Active Job with Sidekiq, as the actual implementation as the background job engine that is running. And I just keep running through this same cycle.

+ +

To highlight it, Active Job is the background job system within Rails. It is a nice abstraction that allows you to connect to any of a number of them, so I think Delayed Job is one. Sidekiq is one. Resque is probably another. I'm sure there's a bunch of others. But historically, I've almost always used Sidekiq. Every project I've worked on has used Sidekiq. But the question is do you use Active Job with the adapter set to Sidekiq and then you're sort of living in both worlds, or do you lean in entirely and you use Sidekiq? And so that would mean that your jobs are defined to include Sidekiq::Worker because that's the actual thing that provides the magic as opposed to inheriting from Application Job. And then do you accept all of the trade-offs therein? And every time I go back and forth. And I'm like, well, but I want this feature, but I don't want that feature. But I want these things. So I've made a decision, but I want to talk ever so briefly through the decision points that were part of it. Have you done this back and forth? Are you familiar with the annoying choice that exists here?

+ +

STEPH: It's been a while since I've had the opportunity to make that choice. I'm usually joining projects where that decision has already been made. So I can't think of a recent time that I've thought through it. And my current project is using that combination of where we are using Active Job and Sidekiq.

+ +

CHRIS: So I think there's even a middle ground there where that was the configuration that I'd set up on the project that I'm working on. But you can exist in both worlds. And you can selectively opt for certain background jobs to be fully Sidekiq. And if you do that, then instead of saying, "Perform_later," You say, "Perform_async." And there are a couple of other configurations. It gives you access to the full Sidekiq API. And you can do things like hey, Sidekiq, here's the maximum number of retries or a handful of other things. But then you have to trade away a bunch of the niceties that Active Job gives.

+ +

So as an example, one thing that Active Job provides that's really nice is the use of GlobalID. So GlobalID is a feature that they added to Rails a while back. And it's a way to uniquely identify a given record within your system such that when you say perform_later, you can say, InvitationMailer.perform_later and then pass it a user record so like an instance of a user model. And what will happen in the background is that gets serialized, but instead of serializing the whole user object because we don't actually want that, it will do the GlobalID magic. And so it'll turn into, I think it's GID:// so almost like a URL. But then it'll be, I think, your application name/model name down the road. And the Perform method actually gets invoked via the background system. Then you will just get handed that user record back, but it's not the same instance of the user record. It sort of freezes and thaws it. It's really nice. It's a wonderful little feature. Sidekiq wants nothing to do with that.

+ +

STEPH: I'm so glad that you highlighted that feature because that was on my mind; I think this week where I was reviewing...somebody had made the comment where they were concerned about passing a record to a job and saying how that wouldn't play nicely with Sidekiq. And in the back of my mind, I'm like, yeah, that's right. But then I was also I'm pretty sure this got addressed, though. And I couldn't recall specifically if it was a Sidekiq enhancement or if it was a Rails enhancement. So you just cleared something up for me that I had not had time to confirm myself. So thanks.

+ +

CHRIS: Well, to be clear, this works if you are using Active Job with Sidekiq as the adapter, but not if you are using a true Sidekiq worker. So if you opt-out of the Active Job flow, then you have to say, "Perform_async," and if you pass it a record, that's not going to work out particularly nicely.

+ +

The other similar thing is that Sidekiq does not allow the use of keyword args, which, I'm going, to be honest, I really like keyword arguments, especially for background jobs or shuttling data through your system. And there's almost a lazy evaluation. I want some nicety to make sure that when I am putting something into a background job that I'm actually using the correct call signature, essentially passing the correct data in the correct shape. Am I passing a record, or am I passing the ID? Am I passing a list of options or a single option? Those sort of trade-offs that are really easy to subtly get wrong.

+ +

I came around on this one because I realized although Active Job does support keyword arguments, the way it does that is it just has a JSON serialization format for them. So a keyword argument turns into a positional array with an associated hash that allows for the lookup or whatever. Basically, again, they handle the details. You get to use keyword args, which is great, with the exception that when you're actually calling perform_later, that method perform_later is a method missing type magic method. So it does not actually check the keyword arguments at that point. You're basically just passing an options hash as opposed to true keyword arguments that would error because they don't match up. And so when I figured that out, I was like, oh, never mind. This doesn't actually do the thing that I care about. It's a little bit nicer in terms of the signature of the method when you're defining your background job itself, but it doesn't actually do any logical checking. It doesn't give me any safety or robustness within my system. So I don't care about that.

+ +

I did find a project called sidekiq-symbols, which does some things under the hood to how Sidekiq serializes and deserializes jobs, which I think gives largely the same behavior as Active Job. So I can now define my Sidekiq jobs with keyword arguments. Things will work. I can't use GlobalID. That's still out. But that's fine. I can do a little helper method that basically does the same thing as GlobalID or at least close approximation. But sidekiq-symbols lets me have keyword arg-like signatures in my methods; basically, it is. But again, it doesn't actually do any check-in when I'm enqueueing a job, and I am sad about that.

+ +

STEPH: Yeah, that's another interesting distinction. And I'm unsurprisingly with you that I would favor having keyword args and having that additional safety in place. Okay, so I've been keeping track. And so far, it sounds like we have two points because I'm doing a little scorecard here between Active Job and Sidekiq. And we have two points in favor of Active Job because they offer a GlobalID, which then allows us to pass in a record, and then it takes care of the serialization for us. And then also, keyword args, which I agree with you that's a really nice feature to have in place as well. So I'm curious, so it sounded like you're leaning towards Active Job, but I don't want to spoil the ending.

+ +

CHRIS: Yes, I could see why that's what you would be taking away from the conversation thus far. So again, just to reiterate, Active Job and Sidekiq with this sidekiq-symbols extension they both support keyword args, kind of. They support defining your job with keyword args and then enqueueing a job passing something that looks like keyword args. But it ends up...nobody's actually checking anything, so it's mostly like a syntactic nicety as opposed to any sort of correctness, which is still nicer, but it's not the thing that I actually want. Either way, nobody supports it, so it is not available to me. Therefore, it is not a consideration point.

+ +

The GlobalID thing is nice, but it is really, again, it's a nicety more than anything. I have gone, and I'm leaning in the direction of full Sidekiq and Sidekiq everywhere as opposed to Active Job in most cases, but then Sidekiq when we need it. And that's because Sidekiq just has a lot more power and a lot more functionality. So, in particular, Sidekiq has a feature which allows you to say...it's a block that you put at the top of your Sidekiq job that says retries exhausted or something. I think Sidekiq retries exhausted is the actual full name of that at that point, which is really unfortunate in my mind, but anyway, I'll deal. At that point, you know that Sidekiq has exhausted all of the retries, and you can treat it as failed.

+ +

I'm going, to be honest, I went on a quest to find a way to say, hey, I'm going to put some work into the background. It's really important for me to know if this work succeeds or if it fails. It's very easy to know if it succeeds because that just happens in-line in the method. But we can have an exception raised at basically any point; Sidekiq does a great job of catching those, of retrying, of having fundamental mechanisms there. But this is the best that I can get for this job failed. And so Active Job, as far as I can tell, does not have anything for this in order to say, yep, we are done. We are not going to keep working on this. This work has failed. It is dead.

+ +

Dead is; actually, I think the more correct term for where we're at because failed is a temporary state, and then you retry after a failure. Whereas dead is, this has gone through all of its retries, and it will never be run again. Therefore, we should treat this as not having run. And in my case, the thing that I want to do is inform the user that this operation that we were trying to do on their behalf has not succeeded, will not succeed. And please reach out or otherwise deal with the fact that we were unable to do the thing that they asked us to do. That feels like a really important thing for me to be able to do, to be able to communicate back to my users.

+ +

This is one of those situations where I'm looking at the available options, and I'm like, I feel like I can't be the only one who wants to know when something goes wrong. This feels like a thing that's important. But this is the best example that I've found, the Sidekiq retries exhausted block. And unfortunately, when I'm using it, it gets yielded the Sidekiq JSON blob deserialized, so it's like Ruby hash. But it's still like this blob of data. It's not the same data that gets passed into perform. And so, as a result, when I want to look up the record that was associated with it, I have to do this nested dig into the available hash of data. And it just feels like this is not a well-paved path. This is not something that is a deeply thought about or recommended use case. But again, I don't feel like I'm doing something weird here. Am I doing something weird, Steph, wanting to tell my users when I was unable to do the thing they asked me to do? [chuckles]

+ +

STEPH: That feels like a very rhetorical question. [laughs]

+ +

CHRIS: It does. I apologize. I'm leading the witness. But in your sincere heart of hearts, what do you think?

+ +

STEPH: No, that certainly doesn't sound weird. I'm actually thinking back to some of the jobs that cause me stress in regards to knowing when they failed and then having that communication of knowing that we've exhausted all the retries. And, of course, knowing when those retries are exhausted is incredibly helpful.

+ +

I am intrigued, though,, because you're highlighting that Active Job doesn't have the same option around setting the retry. And I'm trying to recall exactly how it's set. But I feel like I have set the retry count for Active Job. And maybe, as you mentioned before, that's because it's an abstraction, or I'm not sure if Active Job actually has that native support. So I feel a little confused there where I think my default instinct would have been Active Job does have that retry capability. But it sounds like you've discovered otherwise.

+ +

CHRIS: I'm not actually sure what Active Jobs core retry logic or option looks like. So fundamentally, as far as I understand it, Active Job is an abstraction. And under the hood, you're always connecting an adapter. So it's either going to be Sidekiq, or Resque, or Delayed Job, or other. And each of those systems, whichever system you have as the adapter, is the one that's actually going to be managing retries. And so I know Sidekiq happens to have as a default 25 retries. And that spans, I think it's a two-week exponential back off. And Sidekiq has some very robust logic that they have implemented as the way retries exist within Sidekiq. I'm not sure what that would look like if you're trying to express it abstractly because it is slightly different.

+ +

I know there was some good work that was done on Sidekiq to allow the Sidekiq options that's a method at the top level of the job, even if it's an Active Job job to express the retries. So that may be what you've seen, or there may be truly an abstraction that exists within Active Job, and then each adapter needs to know how to handle retries. But frankly, the what can Sidekiq do that Active Job can't? There's a whole bunch of stuff around limiting when you would retry limiting, enqueuing a job if there already exists one, when and how do those records get locked. There's a whole bunch of stuff.

+ +

Sidekiq has a lot of power under the hood. And so if we want to be leaning into that, that's why I'm leaning towards let's just be Sidekiq all the time. Let's become Sidekiq experts. Let's accept that as a deep architectural decision within the app as opposed to just relying on the abstraction. Because fundamentally, if we're just using Active Job, we're not going to have access to the full power of Sidekiq or whatever the underlying system is, so sort of that decision that I'm making, but I don't know specifically around the retries.

+ +

STEPH: Okay, thanks. That's really helpful. It's been a while since I've had to make this decision. I'm really enjoying you sharing your adventure because I'm trying to think what's the risk? If you don't use Active Job, what are the trade-offs? And you'd mentioned some of them around the GlobalID and keyword args, which are some niceties. But overall, if you don't go with the abstraction, if you lean into Sidekiq, the risk is then you want to migrate to a different enqueuing service. And something that we talk about is mitigating that risk, so then you can swap it out. That's also something I have never done or encountered where we've had to make that change. And it feels like a very low risk in my mind.

+ +

CHRIS: Sidekiq feels like the thing you would migrate to, not a thing you would migrate from. It feels like it is the most powerful. And if anything, I expect at some point we'll be upgrading to Sidekiq pro or enterprise or whatever the higher versions that you pay for, but you get more features there. So in that sense, that is the calculation. That's the risk trade-off in my mind is that we're leaning into this technology and coupling ourselves more closely to it.

+ +

But I don't see that as one that will reassess in the same way that people talk about Active Record and it being an ORM. And it's like, oh, we're abstracting the database underneath, and I'm like, no, I'm not. I'm always using Postgres. Please do not take Postgres. I'm not going to switch over to MySQL next week. That's totally fine if you start on MySQL. It's unlikely you're going to port over to Postgres. We may port to an entirely…like it's a Cassandra column store with a Kafka queue, I don't know, something weird down the road. But it's not going to be swapping out Postgres for MySQL or vice versa. Like you said, that's probably not a change that's going to happen. But that I think is the consideration.

+ +

The other consideration I have in my mind is Active Job is the abstraction that exists within Rails. And so I can treat it as the lowest common denominator, and folks joining the project, it's nice to have that familiarity. So perform_later is the method on the Active Job jobs, and it has a certain shape to it. People may be familiar with that. Mailers will automatically use Active Job just implicitly under the hood. And so there's a familiarity, a discoverability. It's just kind of up the middle choice. And so if I can stick with that, I think there's a nicety there. But in this case, I think I'm choosing I would like the power and consistency on the Sidekiq side, and so I'm leaning into that.

+ +

STEPH: Yeah, that makes a lot of sense to me. And I liked the other example you provided around things that were not likely to swap out and Postgres, MySQL, your database being one of them. And in favor of an example that I do have for something that...I do enjoy wrapping. It's not something that I adhere to strictly, but I do enjoy it when I have the space to make this choice. So I do enjoy wrapping HTTPClients, not just because then I can swap it out for a different HTTPClient, which frankly, that's also rare that I do that. Once I choose an HTTPClient, I'm probably pretty happy, and I don't need to swap it out.

+ +

But I really like being able to extend to the API specifically if they don't handle error responses in a way that I would like to or if they raise, and then I want to change the API to have a more thoughtful interface and where I don't have to rescue those errors. But instead, I can interact with this object that then represents an error state. So that was just one example that came to mind for things that I do enjoy having an abstraction around and not just so I can swap it out because that feels like a very low risk, but more frankly, so I can extend the API.

+ +

CHRIS: I definitely share the I almost always wrap APIs, or I try and hide whatever the implementation detail whether it be HTTPParty, or Faraday or whatever it is that I'm using and trying to hide that deeply within the system. And then I have whatever API client that we define. And that's what we're interacting with. It's interesting that you bring up errors and exceptions there because that's the one other thing that has caused me this...what I'm describing now seems perhaps like, oh, here's just a list of pros and cons, a simple decision was made, and there we are.

+ +

This represents some real soul searching on my part, if we will. And one of the last things that I ran into that was just so frustrating is that Sidekiq is explicitly built around the idea of exceptions; Sidekiq retries if there is an exception raised in the job, otherwise, it treats it as success, and that's it. That is the entirety of it. That is the story. But if you raise an exception in a job, then you can't test that job because now it's raising an exception. You can't test retries or this retry exhausted block that I'm trying to lean into. I'm like, I want to put that in a feature spec and say, oh, this job goes in the background, but it's in a failure state, and therefore, the user sees the failure message. Sorry, I can't do that because the only way to actually fail a job is via an exception.

+ +

And I've actually gone to some links in this application to try to introduce more structured data flow. I've talked a bunch about the command objects and the dry-monads and all those things. And I've really loved them where I've gotten to use them. But then I run into one of these edge cases where Sidekiq is like, no, no, no, you can't do that. And so now I have parts of my system that very purposefully return data as opposed to raising an exception. And I just have to turn around and directly raise that failure as an exception, and it just feels less expressive.

+ +

I actually just ran into the identical thing with Pundit. They have a little bit better control over it; I can choose whether or not I want the raising version or not. But I see exceptions everywhere, and I want a little more discrete data flow. [chuckles] That is my dream. So anyway, I chose Sidekiq is the summary here. And slowly, we're going to migrate entirely to Sidekiq. And I'm going to be totally fine with it. And I'm done griping now.

+ +

STEPH: This is your own little October Halloween movie, that I see exceptions everywhere.

+ +

CHRIS: They're so spooky.

+ +

STEPH: [laughs] That's cool about Pundit. I'm not sure I knew that, that you get to essentially turn on or off that exception flow behavior. On one hand, I'm like, that's nice. You get the option. On the other hand, I'm like, well, let's just not do it. Let's just never raise on people. But at least they give people options; that seems really cool.

+ +

CHRIS: They do give the option. I think you can choose different strategies there. And also, if we're being honest, I'm newer to Pundit. And I used a different thing, which was to get the Policy Object and ask it a question. I wanted to ask, is this enabled or not? Can a user do this or not? That should not raise an exception. I'm just asking a question. We're just being real chill about this. I just want to know some information. Let's flow some data through our system. We don't need exceptions for that.

+ +

STEPH: Why are you yelling at me? I just have a question. [laughs]

+ +

CHRIS: Yeah. I figured out how to be easy on that front. Sidekiq apparently has no be easy mode, but that's fine. You know what? We're going to make it work, and it's going to be fine. But it is interesting deciding which of these facets of the system that I'm building do I really care about? Which are the ones where I'm like, whatever, just pick something, and we'll move forward, it's not a big deal? Versus, we're actually going to be doing a lot of work in the background. This is the thing that I care about deeply. I want to know about failure and success. I want to really understand that and have a robust answer to what our architecture looks like there.

+ +

Similarly, Pundit for authorization. I believe that authorization will be a critical aspect of our system. It's typically a pretty important thing. But for us, I think we're going to have different types of users who can log in and see different subsets of data and having a consistent and concrete way that we have chosen to implement that we are able to test, that we're able to verify. I think that's another core competency within the app. But you only get to have so many of those. You can only be really good at a couple of things. And so I'm in that place where I'm like, which are our top five when I say are the things that I care a lot about? And then which are the things where I'm like, I don't know, whatever, just run with it?

+ +

STEPH: Just a little bit ago, I came so close to singing because you said the I want to know phrase again. And that, I'm realizing, [laughs] is a trigger for me and a song where I want to sing. I held it back this time.

+ +

CHRIS: It's smart. You got to learn anytime you sing on mic that is part of the permanent record.

+ +

STEPH: Edward Loveall at thoughtbot, since I sang in a recent episode, did the delightful thing where then he grabbed that clip of where you talk a little bit, and then I sing and then encouraged everyone to go listen to it. And in which I responded, like, I would highly recommend that you save your ears and don't listen to it. But yes, singing on the mic is a thing. I do it from time to time. I can't hold it back.

+ +

CHRIS: We all do. But since it doesn't seem that you're going to sing in this moment, I think I can probably wrap up my Odyssey of choosing between Sidekiq and Active Job. I hope those details were useful to anyone other than me. It was an adventure, so I figured I'd share it. But yeah, that about wraps it up on my side.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So, I would love to talk about an SSL error that I encountered recently. So one of the important processes in our application is sending data to another system. And while sending data to that other system, we started seeing the following error that the read "Certificate verify failed." And then in parens, it states, "Unable to get local issuer certificate." So upon seeing that error, I initially thought, okay, something is wrong with their SSL certificate or their SSL configuration. And that's not something that I have control over and can fix. So we should reach out and let them know to take a look at their SSL config.

+ +

But it turns out that their team already knew about the issue. They had recently updated or renewed their SSL cert, and they saw our messages were no longer being processed, and they were reaching out to us for help. So at that point, I'm still pretty sure that it's related to something on their end, and it's not something that I can really fix on our end. But we can help them troubleshoot. Maybe there's a workaround that we can add to still get messages processing while they're looking into their SSL config. It seemed like they still just needed help. So it was something that was still worth diving into.

+ +

So going back to the first error, I want to talk a little bit about it because I realized that I understand SSL just enough, just the surface to get by as a developer. But then, every time that I run into a specific error with it, then I really have to refresh my understanding as to what could be wrong, so then I can troubleshoot more effectively.

+ +

So for anyone that could use a refresher on that certificate verification process, when your browser or your server is connecting to a site that uses SSL, then your browser server, whichever one you're using, is going to download that site certificate and verify a couple of things. So it's going to check does the certificate contain the domain name of the website? So essentially, you gave us a certificate. Is this your certificate? Does it match the site that we're connecting to? Is this cert issued by a trusted certificate authority? So did someone that we trust give you this certificate? And is the cert still valid, or has it expired? So that part is pretty straightforward.

+ +

The second part, "Unable to get local issuer certificate," so that's the part I was less certain about. And I took this to mean that they had passed two of those three checks that their cert included the site's name, and it had not expired. But for some reason, we aren't able to determine if their cert was issued by someone that we should trust.

+ +

So following that journey, my next question was, so what are they giving us? So this is a tool that I don't get to use very often, but I reached for OpenSSL and, specifically, the s_client command, which connects to a specified domain and prints all certificates in the certificate chain. You may already know this, but the certificate chain is basically a fancy way of saying, show me all the certificates necessary to prove your site certificate was authorized by a trusted certificate authority.

+ +

CHRIS: I did not know that.

+ +

STEPH: Okay, I honestly didn't either. [laughs]

+ +

CHRIS: I liked that you thought I would, though. So thank you, but no. [chuckles]

+ +

STEPH: Yeah, it's one of those areas of SSL where I know just enough. But that was something that was new to me. I thought there was a site certificate, and I didn't realize that there is this chain of certificates that has to be honored.

+ +

So going back and looking through that output of the certificate chain, that's what highlighted to me that their server was giving us their certificate and saying, hey, you should trust our site certificate. It's legit because it was authorized by, let's say, XYZ certificate. And so if it were a proper certificate chain, then they would give us that XYZ cert. And essentially, we can use this chain of certificates to get back to a trusted authority that then everybody knows that we can trust. However, they weren't actually giving us a reference certificate; they were giving us something else. So essentially, they were saying, "Hey, look at our certificate and look at this very trustworthy reference that we have." But they're actually failing to give us that reference.

+ +

So to bring it all home, we can download that intermediate certificate that they reference; that is something that is publicly accessible. That's why we're able to then verify each certificate that's provided in that chain. We could go and download that intermediate certificate from that certificate authority. We could combine that with their site-specific certificate, include that in our request to their system, and then complete the certificate chain. And boom, we're back in business. But it was quite a journey.

+ +

CHRIS: That is quite the journey. And yeah, I definitely knew very little of that, although everything you're saying makes sense. And I have a bunch of cubbyholes in my brain for SSL knowledge. And the words you said all fit into the spaces that I have in my brain, but I didn't know a bunch of those pieces. So thank you for sharing that.

+ +

SSL and cryptography, more generally or password hashing or things like that, occupy this special place in my brain where I'm both really interested in them. And I will occasionally research them. If I see a blog article, I'll be like, oh yeah, I want to read more about this password hashing. And what's a Salt? And what's a Pepper? And what are we doing there? And what is BCrypt versus SCrypt? What are all these things? This is cool. And almost the arms race on the two sides of how do we demonstrate trust in a secure manner on the internet?

+ +

But at the same time, I am not allowed to do anything with this information. I outsource this as much as humanly possible because it's one of those things that you just should not do yourself and SSL perhaps even more so. So I have configured aspects of my password hashing. But I 100% just lean on the fact that Let's Encrypt exists in the world. And prior to that, it was a little more work. But frankly, earlier on in my career, I wasn't dealing with the SSL parts of things. But I'm so grateful to Let's Encrypt as a project that exists.

+ +

And now, on almost every platform that I work with, there's just a checkbox for please do the SSL work for me, make it good, make it work, and then I will be happy. And I'm so glad that that organization exists and really pushed the envelope also. I forget what it was, but it was only like three years ago where SSL was not actually nearly as common as it is now. And now it is pervasive and everywhere. And all of the sites have it, and so that is a wonderful thing. But I don't actually know much. I know that I should have it. I must have it. I should force it. That's true. So I push that out…

+ +

STEPH: Hello.

+ +

CHRIS: Are you trying to get me to sing? [chuckles]

+ +

STEPH: [laughs] No, but I did want to know if you get the reference, the Salt-N-Pepa.

+ +

CHRIS: Push It Real Good the song? Yeah, okay.

+ +

STEPH: Yeah, you got it. [chuckles]

+ +

CHRIS: I will just say the lyrics. I shall not sing the lyrics. I would say that, though, that yes, yes, they do that.

+ +

STEPH: Thank you for acknowledging my very terrible reference. Circling back just a little bit too in regards to...I'm with you; this is a world that is not one that I am very deeply technical in and something that I learned a fair amount while troubleshooting this particular SSL error. And it was very interesting. But there's also that concern where it's like, that was interesting. And we worked around the issue, but this also feels very fragile.

+ +

So we still haven't fixed it on their end where they are sending the wrong certificate. So then that's why we had to do more investigative work, and then download the certificate that they meant to send us, and then send back a complete certificate chain so that we don't have this error anymore. But should they change anything about their certificate, should they renew anything like that, then suddenly, we're going to break again. And then, the next developer is going to have to go through the same journey. And this wasn't a light journey. This was a good half-day journey to figure out what was going on and to spend the time, and then to also get that fix out to production. So it's a meaningful task that I don't want anyone else to have to go through.

+ +

But we are relying on someone else updating their configuration. So, on one hand, we're in a good spot until they are able to update. But on the other hand, I wrote a heck of a commit message for the next person just describing like, friend, just grab some coffee if we're going to chat. It's a very small code change, but you need to know the scoop. So should you need to replicate this because they've changed something, or if this happens…because we work with a number of systems that we send data to. So if someone else should run into a similar issue, they will understand some of the troubleshooting techniques that I used and be able to look up that chain and find out if there's a missing cert or something else they need to provide. So it feels like a win, but I'm also nervous for future selves, future developers.

+ +

So there's another approach that I haven't mentioned yet, but it was often a top recommendation for when dealing with SSL errors. And specifically, it was turning off SSL verification. And I saw that, and I was like, well, that won't work. I'm definitely sending sensitive, important data. And I need to verify that who I'm sending this to is really the person that I want to send this data to. So that was not an option for me. But it made me very nervous how often that was an approach that people would recommend and be like, oh, it's okay, just turn off SSL. You'll be fine. Like, don't worry about it.

+ +

CHRIS: I feel like this so perfectly fits into the...some of our work is finding the information and connecting the pieces together and making it work. But some of it is that heuristic sense, that voice in the back of your head that is like, wait, I'm sorry, what? You want me to just turn off the security perimeter and hope that the velociraptors won't come in? That doesn't seem like it's going to end well. I get that that's an easy option that we have available to us right now and will solve the immediate problem but then let's play this out. There are four or five Jurassic Park movies now that tell the story of that. So let's be careful.

+ +

STEPH: It always ends super well, though, right? Like, it's totally fine. [laughs]

+ +

CHRIS: [laughs] Exclusively. Although it's funny that you mentioned OpenSSL no verify because just this past week, I used that very same configuration. I think it was okay in my case; I’m pretty sure. But it is interesting because when I saw it, I was like, oh no, can't do that. Certainly not that. Don't turn off the security feature. That's the wrong way to deal with the issue.

+ +

But in the particular case that I'm working with, I'm using Redis, Heroku Redis, in particular, in a Heroku configuration. And the nature of how Heroku configures the Redis instances and the connectivity to our app into our dyno...I forget why. I read an article. They wrote it; Heroku wrote it. I trust them; they’re good. I've outsourced my trust to people that I do trust. The trust chain actually maps really well to the certificate trust chain. I trust that Heroku has taken security deeply seriously. And for some reason, their configuration of Redis requires that I turn on OpenSSL no verify mode. So I'm using this now both in Sidekiq, and then we're using our Redis instance for our Rails cache as well.

+ +

So in both cases, I said, "It's fine. Don't worry about it." I used the Don't worry about it configuration. And I didn't love it but I think it's okay. And partly, I'm trying to say this into the internet radio right now just in case anyone's listening who's like, no, no, no, you can't do that. That's bad. So I'm willing to be deeply wrong on the internet in favor of someone telling me and then I get to get out in front of it. But I think it's fine. Pretty sure it's fine. It should be fine.

+ +

STEPH: I love love love that you gave a very visual example of velociraptors, and then you're like, oh, but I turned it off. [laughs] So I'm going to start sending you a velociraptor gif each day.

+ +

CHRIS: I hope you do. I hope the internet holds you accountable to that.

+ +

STEPH: [laughs]

+ +

CHRIS: And I really look forward to [laughs] moving forward because that's a great way to start the day. Well, it doesn't need to start the day, but I look forward to them.

+ +

STEPH: [laughs] I am really intrigued because I'm with you. Like you said, there are certain entities that are in our trust chain where it's like, hey, you are running this for us, and so I do have faith and trust in you that you wouldn't steer me wrong and provide a bad recommendation. Someone on Stack Overflow telling me to turn off SSL verify uh; that’s not my trust chain. Heroku or someone else telling me I'm going to take it a little more seriously. And so I'm also interested in hearing from...what'd you say? You're speaking into the internet phone. [laughs] What'd you say?

+ +

CHRIS: I think I said internet radio. But yeah, in a way. I mean, we're recording over Skype right now. So in a manner of speaking, we're on the internet phone to make our internet radio show.

+ +

STEPH: [laughs] Oh goodness, the internet radio. I'm also intrigued to hear if other people are like, oh, no, no, no. Yeah, that sounds like an interesting scenario. Because I would think you'd still want your connection to...you said it's for Redis. So you still want that connection to be verified. But then if Redis itself can't have a specific...yeah, we're testing the boundaries of my SSL knowledge here as to how the heck you would even establish that SSL connection or the verification process.

+ +

CHRIS: Me too. And it also exists in an interesting space where Heroku is rather clear in their documentation about this. And it was a surprising claim when I saw it. And so, I don't expect them to be flippant about a thing that is important. Like, if they're like, "No, no, no, it is okay. You can turn off the security thing, don't worry." I trust that they're not just like, oh, we didn't think about it too much. But we figured why not? It's not a big deal. I'm sure that they have thought about it deeply because it is an important thing.

+ +

And so in a weird way, my trust of them and the severity of what this thing represents, I'm like, oh yeah, I super trust that because you're not going to get a major thing wrong. You might get a minor, small, subtle thing wrong. But this is a pretty major configuration change. As I say it, I'm now getting more worried. I'm now like, I feel fine about this. This doesn't seem like a problem at all. But then I keep saying stuff, and I'm like, oh no. That's why I love having a podcast; I find out things about myself as I talk into a microphone to you.

+ +

STEPH: We come here to share our deep, dark developer secrets.

+ +

Chris: Spooky developer therapy.

+ +

STEPH: But just to clarify, even though you've turned off the SSL verify, you're still connecting over SSL.

+ +

CHRIS: Yes, I believe that's the case. And if I'm remembering, I think the nature of how this works is they're using a self-signed certificate because of shared infrastructure or something, something that made sense when I read it. But it was the idea that they are doing a self-signed certificate. Therefore, to what you were talking about earlier, there isn't the certificate authority in the chain of those because it's self-signed. And so, they are not a trusted certificate authority. Therefore, that certificate that they have generated would not be trusted. But it does still allow for the SSL handshake and then communication to happen over SSL. It's just that fundamental question of trust. I'm saying, in this case, for reasons, it's okay. Trust me that I trust them. We're good. Which, again, I don't feel great about, but I think yes, it is still SSL, but it is a self-signed certificate. So we have to make this configuration change.

+ +

STEPH: Yeah, all of that makes sense. And it certainly sounds like you have been very thoughtful about that change and put in some investigative work. So on that note, I have a very unrelated bad joke for you.

+ +

CHRIS: I'm very excited.

+ +

STEPH: All right, here we go. All right, so what do you call an alligator wearing a vest?

+ +

CHRIS: I don't know. What do you call an alligator wearing a vest?

+ +

STEPH: An investigator.

+ +

[laughter]

+ +

On that note, shall we wrap up?

+ +

CHRIS: Oh, let's wrap up. We should also include a link in the show notes to the episode where you told the joke about the elephant hiding in the trees because that's one of my favorite jokes. You slayed me with that one. [laughs] But on that note, yes, let us wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,,as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Chris evaluates the pros and cons between using Sidekiq or Active Job with Sidekiq. He sees exceptions everywhere.

+ +

Steph talks about an SSL error that she encountered recently. It's officially spooky season, y'all!

+ + + +

Transcript:

+ +

CHRIS: Additional radiation just makes Spider-Man more powerful.

+ +

STEPH: [laughs] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: Fall is in the air. It's one of those, like, came out of nowhere. I knew it was coming. I knew it was going to happen. But now it's time for pumpkin beer and pumpkin spice lattes, and exclusively watching the movie Hocus Pocus for the next month or so or some variation of those themes. But unrelated to that, I did a thing that I do once, let's call it every year or so, where I had to make the evaluation between Sidekiq or Active Job with Sidekiq, as the actual implementation as the background job engine that is running. And I just keep running through this same cycle.

+ +

To highlight it, Active Job is the background job system within Rails. It is a nice abstraction that allows you to connect to any of a number of them, so I think Delayed Job is one. Sidekiq is one. Resque is probably another. I'm sure there's a bunch of others. But historically, I've almost always used Sidekiq. Every project I've worked on has used Sidekiq. But the question is do you use Active Job with the adapter set to Sidekiq and then you're sort of living in both worlds, or do you lean in entirely and you use Sidekiq? And so that would mean that your jobs are defined to include Sidekiq::Worker because that's the actual thing that provides the magic as opposed to inheriting from Application Job. And then do you accept all of the trade-offs therein? And every time I go back and forth. And I'm like, well, but I want this feature, but I don't want that feature. But I want these things. So I've made a decision, but I want to talk ever so briefly through the decision points that were part of it. Have you done this back and forth? Are you familiar with the annoying choice that exists here?

+ +

STEPH: It's been a while since I've had the opportunity to make that choice. I'm usually joining projects where that decision has already been made. So I can't think of a recent time that I've thought through it. And my current project is using that combination of where we are using Active Job and Sidekiq.

+ +

CHRIS: So I think there's even a middle ground there where that was the configuration that I'd set up on the project that I'm working on. But you can exist in both worlds. And you can selectively opt for certain background jobs to be fully Sidekiq. And if you do that, then instead of saying, "Perform_later," You say, "Perform_async." And there are a couple of other configurations. It gives you access to the full Sidekiq API. And you can do things like hey, Sidekiq, here's the maximum number of retries or a handful of other things. But then you have to trade away a bunch of the niceties that Active Job gives.

+ +

So as an example, one thing that Active Job provides that's really nice is the use of GlobalID. So GlobalID is a feature that they added to Rails a while back. And it's a way to uniquely identify a given record within your system such that when you say perform_later, you can say, InvitationMailer.perform_later and then pass it a user record so like an instance of a user model. And what will happen in the background is that gets serialized, but instead of serializing the whole user object because we don't actually want that, it will do the GlobalID magic. And so it'll turn into, I think it's GID:// so almost like a URL. But then it'll be, I think, your application name/model name down the road. And the Perform method actually gets invoked via the background system. Then you will just get handed that user record back, but it's not the same instance of the user record. It sort of freezes and thaws it. It's really nice. It's a wonderful little feature. Sidekiq wants nothing to do with that.

+ +

STEPH: I'm so glad that you highlighted that feature because that was on my mind; I think this week where I was reviewing...somebody had made the comment where they were concerned about passing a record to a job and saying how that wouldn't play nicely with Sidekiq. And in the back of my mind, I'm like, yeah, that's right. But then I was also I'm pretty sure this got addressed, though. And I couldn't recall specifically if it was a Sidekiq enhancement or if it was a Rails enhancement. So you just cleared something up for me that I had not had time to confirm myself. So thanks.

+ +

CHRIS: Well, to be clear, this works if you are using Active Job with Sidekiq as the adapter, but not if you are using a true Sidekiq worker. So if you opt-out of the Active Job flow, then you have to say, "Perform_async," and if you pass it a record, that's not going to work out particularly nicely.

+ +

The other similar thing is that Sidekiq does not allow the use of keyword args, which, I'm going, to be honest, I really like keyword arguments, especially for background jobs or shuttling data through your system. And there's almost a lazy evaluation. I want some nicety to make sure that when I am putting something into a background job that I'm actually using the correct call signature, essentially passing the correct data in the correct shape. Am I passing a record, or am I passing the ID? Am I passing a list of options or a single option? Those sort of trade-offs that are really easy to subtly get wrong.

+ +

I came around on this one because I realized although Active Job does support keyword arguments, the way it does that is it just has a JSON serialization format for them. So a keyword argument turns into a positional array with an associated hash that allows for the lookup or whatever. Basically, again, they handle the details. You get to use keyword args, which is great, with the exception that when you're actually calling perform_later, that method perform_later is a method missing type magic method. So it does not actually check the keyword arguments at that point. You're basically just passing an options hash as opposed to true keyword arguments that would error because they don't match up. And so when I figured that out, I was like, oh, never mind. This doesn't actually do the thing that I care about. It's a little bit nicer in terms of the signature of the method when you're defining your background job itself, but it doesn't actually do any logical checking. It doesn't give me any safety or robustness within my system. So I don't care about that.

+ +

I did find a project called sidekiq-symbols, which does some things under the hood to how Sidekiq serializes and deserializes jobs, which I think gives largely the same behavior as Active Job. So I can now define my Sidekiq jobs with keyword arguments. Things will work. I can't use GlobalID. That's still out. But that's fine. I can do a little helper method that basically does the same thing as GlobalID or at least close approximation. But sidekiq-symbols lets me have keyword arg-like signatures in my methods; basically, it is. But again, it doesn't actually do any check-in when I'm enqueueing a job, and I am sad about that.

+ +

STEPH: Yeah, that's another interesting distinction. And I'm unsurprisingly with you that I would favor having keyword args and having that additional safety in place. Okay, so I've been keeping track. And so far, it sounds like we have two points because I'm doing a little scorecard here between Active Job and Sidekiq. And we have two points in favor of Active Job because they offer a GlobalID, which then allows us to pass in a record, and then it takes care of the serialization for us. And then also, keyword args, which I agree with you that's a really nice feature to have in place as well. So I'm curious, so it sounded like you're leaning towards Active Job, but I don't want to spoil the ending.

+ +

CHRIS: Yes, I could see why that's what you would be taking away from the conversation thus far. So again, just to reiterate, Active Job and Sidekiq with this sidekiq-symbols extension they both support keyword args, kind of. They support defining your job with keyword args and then enqueueing a job passing something that looks like keyword args. But it ends up...nobody's actually checking anything, so it's mostly like a syntactic nicety as opposed to any sort of correctness, which is still nicer, but it's not the thing that I actually want. Either way, nobody supports it, so it is not available to me. Therefore, it is not a consideration point.

+ +

The GlobalID thing is nice, but it is really, again, it's a nicety more than anything. I have gone, and I'm leaning in the direction of full Sidekiq and Sidekiq everywhere as opposed to Active Job in most cases, but then Sidekiq when we need it. And that's because Sidekiq just has a lot more power and a lot more functionality. So, in particular, Sidekiq has a feature which allows you to say...it's a block that you put at the top of your Sidekiq job that says retries exhausted or something. I think Sidekiq retries exhausted is the actual full name of that at that point, which is really unfortunate in my mind, but anyway, I'll deal. At that point, you know that Sidekiq has exhausted all of the retries, and you can treat it as failed.

+ +

I'm going, to be honest, I went on a quest to find a way to say, hey, I'm going to put some work into the background. It's really important for me to know if this work succeeds or if it fails. It's very easy to know if it succeeds because that just happens in-line in the method. But we can have an exception raised at basically any point; Sidekiq does a great job of catching those, of retrying, of having fundamental mechanisms there. But this is the best that I can get for this job failed. And so Active Job, as far as I can tell, does not have anything for this in order to say, yep, we are done. We are not going to keep working on this. This work has failed. It is dead.

+ +

Dead is; actually, I think the more correct term for where we're at because failed is a temporary state, and then you retry after a failure. Whereas dead is, this has gone through all of its retries, and it will never be run again. Therefore, we should treat this as not having run. And in my case, the thing that I want to do is inform the user that this operation that we were trying to do on their behalf has not succeeded, will not succeed. And please reach out or otherwise deal with the fact that we were unable to do the thing that they asked us to do. That feels like a really important thing for me to be able to do, to be able to communicate back to my users.

+ +

This is one of those situations where I'm looking at the available options, and I'm like, I feel like I can't be the only one who wants to know when something goes wrong. This feels like a thing that's important. But this is the best example that I've found, the Sidekiq retries exhausted block. And unfortunately, when I'm using it, it gets yielded the Sidekiq JSON blob deserialized, so it's like Ruby hash. But it's still like this blob of data. It's not the same data that gets passed into perform. And so, as a result, when I want to look up the record that was associated with it, I have to do this nested dig into the available hash of data. And it just feels like this is not a well-paved path. This is not something that is a deeply thought about or recommended use case. But again, I don't feel like I'm doing something weird here. Am I doing something weird, Steph, wanting to tell my users when I was unable to do the thing they asked me to do? [chuckles]

+ +

STEPH: That feels like a very rhetorical question. [laughs]

+ +

CHRIS: It does. I apologize. I'm leading the witness. But in your sincere heart of hearts, what do you think?

+ +

STEPH: No, that certainly doesn't sound weird. I'm actually thinking back to some of the jobs that cause me stress in regards to knowing when they failed and then having that communication of knowing that we've exhausted all the retries. And, of course, knowing when those retries are exhausted is incredibly helpful.

+ +

I am intrigued, though,, because you're highlighting that Active Job doesn't have the same option around setting the retry. And I'm trying to recall exactly how it's set. But I feel like I have set the retry count for Active Job. And maybe, as you mentioned before, that's because it's an abstraction, or I'm not sure if Active Job actually has that native support. So I feel a little confused there where I think my default instinct would have been Active Job does have that retry capability. But it sounds like you've discovered otherwise.

+ +

CHRIS: I'm not actually sure what Active Jobs core retry logic or option looks like. So fundamentally, as far as I understand it, Active Job is an abstraction. And under the hood, you're always connecting an adapter. So it's either going to be Sidekiq, or Resque, or Delayed Job, or other. And each of those systems, whichever system you have as the adapter, is the one that's actually going to be managing retries. And so I know Sidekiq happens to have as a default 25 retries. And that spans, I think it's a two-week exponential back off. And Sidekiq has some very robust logic that they have implemented as the way retries exist within Sidekiq. I'm not sure what that would look like if you're trying to express it abstractly because it is slightly different.

+ +

I know there was some good work that was done on Sidekiq to allow the Sidekiq options that's a method at the top level of the job, even if it's an Active Job job to express the retries. So that may be what you've seen, or there may be truly an abstraction that exists within Active Job, and then each adapter needs to know how to handle retries. But frankly, the what can Sidekiq do that Active Job can't? There's a whole bunch of stuff around limiting when you would retry limiting, enqueuing a job if there already exists one, when and how do those records get locked. There's a whole bunch of stuff.

+ +

Sidekiq has a lot of power under the hood. And so if we want to be leaning into that, that's why I'm leaning towards let's just be Sidekiq all the time. Let's become Sidekiq experts. Let's accept that as a deep architectural decision within the app as opposed to just relying on the abstraction. Because fundamentally, if we're just using Active Job, we're not going to have access to the full power of Sidekiq or whatever the underlying system is, so sort of that decision that I'm making, but I don't know specifically around the retries.

+ +

STEPH: Okay, thanks. That's really helpful. It's been a while since I've had to make this decision. I'm really enjoying you sharing your adventure because I'm trying to think what's the risk? If you don't use Active Job, what are the trade-offs? And you'd mentioned some of them around the GlobalID and keyword args, which are some niceties. But overall, if you don't go with the abstraction, if you lean into Sidekiq, the risk is then you want to migrate to a different enqueuing service. And something that we talk about is mitigating that risk, so then you can swap it out. That's also something I have never done or encountered where we've had to make that change. And it feels like a very low risk in my mind.

+ +

CHRIS: Sidekiq feels like the thing you would migrate to, not a thing you would migrate from. It feels like it is the most powerful. And if anything, I expect at some point we'll be upgrading to Sidekiq pro or enterprise or whatever the higher versions that you pay for, but you get more features there. So in that sense, that is the calculation. That's the risk trade-off in my mind is that we're leaning into this technology and coupling ourselves more closely to it.

+ +

But I don't see that as one that will reassess in the same way that people talk about Active Record and it being an ORM. And it's like, oh, we're abstracting the database underneath, and I'm like, no, I'm not. I'm always using Postgres. Please do not take Postgres. I'm not going to switch over to MySQL next week. That's totally fine if you start on MySQL. It's unlikely you're going to port over to Postgres. We may port to an entirely…like it's a Cassandra column store with a Kafka queue, I don't know, something weird down the road. But it's not going to be swapping out Postgres for MySQL or vice versa. Like you said, that's probably not a change that's going to happen. But that I think is the consideration.

+ +

The other consideration I have in my mind is Active Job is the abstraction that exists within Rails. And so I can treat it as the lowest common denominator, and folks joining the project, it's nice to have that familiarity. So perform_later is the method on the Active Job jobs, and it has a certain shape to it. People may be familiar with that. Mailers will automatically use Active Job just implicitly under the hood. And so there's a familiarity, a discoverability. It's just kind of up the middle choice. And so if I can stick with that, I think there's a nicety there. But in this case, I think I'm choosing I would like the power and consistency on the Sidekiq side, and so I'm leaning into that.

+ +

STEPH: Yeah, that makes a lot of sense to me. And I liked the other example you provided around things that were not likely to swap out and Postgres, MySQL, your database being one of them. And in favor of an example that I do have for something that...I do enjoy wrapping. It's not something that I adhere to strictly, but I do enjoy it when I have the space to make this choice. So I do enjoy wrapping HTTPClients, not just because then I can swap it out for a different HTTPClient, which frankly, that's also rare that I do that. Once I choose an HTTPClient, I'm probably pretty happy, and I don't need to swap it out.

+ +

But I really like being able to extend to the API specifically if they don't handle error responses in a way that I would like to or if they raise, and then I want to change the API to have a more thoughtful interface and where I don't have to rescue those errors. But instead, I can interact with this object that then represents an error state. So that was just one example that came to mind for things that I do enjoy having an abstraction around and not just so I can swap it out because that feels like a very low risk, but more frankly, so I can extend the API.

+ +

CHRIS: I definitely share the I almost always wrap APIs, or I try and hide whatever the implementation detail whether it be HTTPParty, or Faraday or whatever it is that I'm using and trying to hide that deeply within the system. And then I have whatever API client that we define. And that's what we're interacting with. It's interesting that you bring up errors and exceptions there because that's the one other thing that has caused me this...what I'm describing now seems perhaps like, oh, here's just a list of pros and cons, a simple decision was made, and there we are.

+ +

This represents some real soul searching on my part, if we will. And one of the last things that I ran into that was just so frustrating is that Sidekiq is explicitly built around the idea of exceptions; Sidekiq retries if there is an exception raised in the job, otherwise, it treats it as success, and that's it. That is the entirety of it. That is the story. But if you raise an exception in a job, then you can't test that job because now it's raising an exception. You can't test retries or this retry exhausted block that I'm trying to lean into. I'm like, I want to put that in a feature spec and say, oh, this job goes in the background, but it's in a failure state, and therefore, the user sees the failure message. Sorry, I can't do that because the only way to actually fail a job is via an exception.

+ +

And I've actually gone to some links in this application to try to introduce more structured data flow. I've talked a bunch about the command objects and the dry-monads and all those things. And I've really loved them where I've gotten to use them. But then I run into one of these edge cases where Sidekiq is like, no, no, no, you can't do that. And so now I have parts of my system that very purposefully return data as opposed to raising an exception. And I just have to turn around and directly raise that failure as an exception, and it just feels less expressive.

+ +

I actually just ran into the identical thing with Pundit. They have a little bit better control over it; I can choose whether or not I want the raising version or not. But I see exceptions everywhere, and I want a little more discrete data flow. [chuckles] That is my dream. So anyway, I chose Sidekiq is the summary here. And slowly, we're going to migrate entirely to Sidekiq. And I'm going to be totally fine with it. And I'm done griping now.

+ +

STEPH: This is your own little October Halloween movie, that I see exceptions everywhere.

+ +

CHRIS: They're so spooky.

+ +

STEPH: [laughs] That's cool about Pundit. I'm not sure I knew that, that you get to essentially turn on or off that exception flow behavior. On one hand, I'm like, that's nice. You get the option. On the other hand, I'm like, well, let's just not do it. Let's just never raise on people. But at least they give people options; that seems really cool.

+ +

CHRIS: They do give the option. I think you can choose different strategies there. And also, if we're being honest, I'm newer to Pundit. And I used a different thing, which was to get the Policy Object and ask it a question. I wanted to ask, is this enabled or not? Can a user do this or not? That should not raise an exception. I'm just asking a question. We're just being real chill about this. I just want to know some information. Let's flow some data through our system. We don't need exceptions for that.

+ +

STEPH: Why are you yelling at me? I just have a question. [laughs]

+ +

CHRIS: Yeah. I figured out how to be easy on that front. Sidekiq apparently has no be easy mode, but that's fine. You know what? We're going to make it work, and it's going to be fine. But it is interesting deciding which of these facets of the system that I'm building do I really care about? Which are the ones where I'm like, whatever, just pick something, and we'll move forward, it's not a big deal? Versus, we're actually going to be doing a lot of work in the background. This is the thing that I care about deeply. I want to know about failure and success. I want to really understand that and have a robust answer to what our architecture looks like there.

+ +

Similarly, Pundit for authorization. I believe that authorization will be a critical aspect of our system. It's typically a pretty important thing. But for us, I think we're going to have different types of users who can log in and see different subsets of data and having a consistent and concrete way that we have chosen to implement that we are able to test, that we're able to verify. I think that's another core competency within the app. But you only get to have so many of those. You can only be really good at a couple of things. And so I'm in that place where I'm like, which are our top five when I say are the things that I care a lot about? And then which are the things where I'm like, I don't know, whatever, just run with it?

+ +

STEPH: Just a little bit ago, I came so close to singing because you said the I want to know phrase again. And that, I'm realizing, [laughs] is a trigger for me and a song where I want to sing. I held it back this time.

+ +

CHRIS: It's smart. You got to learn anytime you sing on mic that is part of the permanent record.

+ +

STEPH: Edward Loveall at thoughtbot, since I sang in a recent episode, did the delightful thing where then he grabbed that clip of where you talk a little bit, and then I sing and then encouraged everyone to go listen to it. And in which I responded, like, I would highly recommend that you save your ears and don't listen to it. But yes, singing on the mic is a thing. I do it from time to time. I can't hold it back.

+ +

CHRIS: We all do. But since it doesn't seem that you're going to sing in this moment, I think I can probably wrap up my Odyssey of choosing between Sidekiq and Active Job. I hope those details were useful to anyone other than me. It was an adventure, so I figured I'd share it. But yeah, that about wraps it up on my side.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: So, I would love to talk about an SSL error that I encountered recently. So one of the important processes in our application is sending data to another system. And while sending data to that other system, we started seeing the following error that the read "Certificate verify failed." And then in parens, it states, "Unable to get local issuer certificate." So upon seeing that error, I initially thought, okay, something is wrong with their SSL certificate or their SSL configuration. And that's not something that I have control over and can fix. So we should reach out and let them know to take a look at their SSL config.

+ +

But it turns out that their team already knew about the issue. They had recently updated or renewed their SSL cert, and they saw our messages were no longer being processed, and they were reaching out to us for help. So at that point, I'm still pretty sure that it's related to something on their end, and it's not something that I can really fix on our end. But we can help them troubleshoot. Maybe there's a workaround that we can add to still get messages processing while they're looking into their SSL config. It seemed like they still just needed help. So it was something that was still worth diving into.

+ +

So going back to the first error, I want to talk a little bit about it because I realized that I understand SSL just enough, just the surface to get by as a developer. But then, every time that I run into a specific error with it, then I really have to refresh my understanding as to what could be wrong, so then I can troubleshoot more effectively.

+ +

So for anyone that could use a refresher on that certificate verification process, when your browser or your server is connecting to a site that uses SSL, then your browser server, whichever one you're using, is going to download that site certificate and verify a couple of things. So it's going to check does the certificate contain the domain name of the website? So essentially, you gave us a certificate. Is this your certificate? Does it match the site that we're connecting to? Is this cert issued by a trusted certificate authority? So did someone that we trust give you this certificate? And is the cert still valid, or has it expired? So that part is pretty straightforward.

+ +

The second part, "Unable to get local issuer certificate," so that's the part I was less certain about. And I took this to mean that they had passed two of those three checks that their cert included the site's name, and it had not expired. But for some reason, we aren't able to determine if their cert was issued by someone that we should trust.

+ +

So following that journey, my next question was, so what are they giving us? So this is a tool that I don't get to use very often, but I reached for OpenSSL and, specifically, the s_client command, which connects to a specified domain and prints all certificates in the certificate chain. You may already know this, but the certificate chain is basically a fancy way of saying, show me all the certificates necessary to prove your site certificate was authorized by a trusted certificate authority.

+ +

CHRIS: I did not know that.

+ +

STEPH: Okay, I honestly didn't either. [laughs]

+ +

CHRIS: I liked that you thought I would, though. So thank you, but no. [chuckles]

+ +

STEPH: Yeah, it's one of those areas of SSL where I know just enough. But that was something that was new to me. I thought there was a site certificate, and I didn't realize that there is this chain of certificates that has to be honored.

+ +

So going back and looking through that output of the certificate chain, that's what highlighted to me that their server was giving us their certificate and saying, hey, you should trust our site certificate. It's legit because it was authorized by, let's say, XYZ certificate. And so if it were a proper certificate chain, then they would give us that XYZ cert. And essentially, we can use this chain of certificates to get back to a trusted authority that then everybody knows that we can trust. However, they weren't actually giving us a reference certificate; they were giving us something else. So essentially, they were saying, "Hey, look at our certificate and look at this very trustworthy reference that we have." But they're actually failing to give us that reference.

+ +

So to bring it all home, we can download that intermediate certificate that they reference; that is something that is publicly accessible. That's why we're able to then verify each certificate that's provided in that chain. We could go and download that intermediate certificate from that certificate authority. We could combine that with their site-specific certificate, include that in our request to their system, and then complete the certificate chain. And boom, we're back in business. But it was quite a journey.

+ +

CHRIS: That is quite the journey. And yeah, I definitely knew very little of that, although everything you're saying makes sense. And I have a bunch of cubbyholes in my brain for SSL knowledge. And the words you said all fit into the spaces that I have in my brain, but I didn't know a bunch of those pieces. So thank you for sharing that.

+ +

SSL and cryptography, more generally or password hashing or things like that, occupy this special place in my brain where I'm both really interested in them. And I will occasionally research them. If I see a blog article, I'll be like, oh yeah, I want to read more about this password hashing. And what's a Salt? And what's a Pepper? And what are we doing there? And what is BCrypt versus SCrypt? What are all these things? This is cool. And almost the arms race on the two sides of how do we demonstrate trust in a secure manner on the internet?

+ +

But at the same time, I am not allowed to do anything with this information. I outsource this as much as humanly possible because it's one of those things that you just should not do yourself and SSL perhaps even more so. So I have configured aspects of my password hashing. But I 100% just lean on the fact that Let's Encrypt exists in the world. And prior to that, it was a little more work. But frankly, earlier on in my career, I wasn't dealing with the SSL parts of things. But I'm so grateful to Let's Encrypt as a project that exists.

+ +

And now, on almost every platform that I work with, there's just a checkbox for please do the SSL work for me, make it good, make it work, and then I will be happy. And I'm so glad that that organization exists and really pushed the envelope also. I forget what it was, but it was only like three years ago where SSL was not actually nearly as common as it is now. And now it is pervasive and everywhere. And all of the sites have it, and so that is a wonderful thing. But I don't actually know much. I know that I should have it. I must have it. I should force it. That's true. So I push that out…

+ +

STEPH: Hello.

+ +

CHRIS: Are you trying to get me to sing? [chuckles]

+ +

STEPH: [laughs] No, but I did want to know if you get the reference, the Salt-N-Pepa.

+ +

CHRIS: Push It Real Good the song? Yeah, okay.

+ +

STEPH: Yeah, you got it. [chuckles]

+ +

CHRIS: I will just say the lyrics. I shall not sing the lyrics. I would say that, though, that yes, yes, they do that.

+ +

STEPH: Thank you for acknowledging my very terrible reference. Circling back just a little bit too in regards to...I'm with you; this is a world that is not one that I am very deeply technical in and something that I learned a fair amount while troubleshooting this particular SSL error. And it was very interesting. But there's also that concern where it's like, that was interesting. And we worked around the issue, but this also feels very fragile.

+ +

So we still haven't fixed it on their end where they are sending the wrong certificate. So then that's why we had to do more investigative work, and then download the certificate that they meant to send us, and then send back a complete certificate chain so that we don't have this error anymore. But should they change anything about their certificate, should they renew anything like that, then suddenly, we're going to break again. And then, the next developer is going to have to go through the same journey. And this wasn't a light journey. This was a good half-day journey to figure out what was going on and to spend the time, and then to also get that fix out to production. So it's a meaningful task that I don't want anyone else to have to go through.

+ +

But we are relying on someone else updating their configuration. So, on one hand, we're in a good spot until they are able to update. But on the other hand, I wrote a heck of a commit message for the next person just describing like, friend, just grab some coffee if we're going to chat. It's a very small code change, but you need to know the scoop. So should you need to replicate this because they've changed something, or if this happens…because we work with a number of systems that we send data to. So if someone else should run into a similar issue, they will understand some of the troubleshooting techniques that I used and be able to look up that chain and find out if there's a missing cert or something else they need to provide. So it feels like a win, but I'm also nervous for future selves, future developers.

+ +

So there's another approach that I haven't mentioned yet, but it was often a top recommendation for when dealing with SSL errors. And specifically, it was turning off SSL verification. And I saw that, and I was like, well, that won't work. I'm definitely sending sensitive, important data. And I need to verify that who I'm sending this to is really the person that I want to send this data to. So that was not an option for me. But it made me very nervous how often that was an approach that people would recommend and be like, oh, it's okay, just turn off SSL. You'll be fine. Like, don't worry about it.

+ +

CHRIS: I feel like this so perfectly fits into the...some of our work is finding the information and connecting the pieces together and making it work. But some of it is that heuristic sense, that voice in the back of your head that is like, wait, I'm sorry, what? You want me to just turn off the security perimeter and hope that the velociraptors won't come in? That doesn't seem like it's going to end well. I get that that's an easy option that we have available to us right now and will solve the immediate problem but then let's play this out. There are four or five Jurassic Park movies now that tell the story of that. So let's be careful.

+ +

STEPH: It always ends super well, though, right? Like, it's totally fine. [laughs]

+ +

CHRIS: [laughs] Exclusively. Although it's funny that you mentioned OpenSSL no verify because just this past week, I used that very same configuration. I think it was okay in my case; I’m pretty sure. But it is interesting because when I saw it, I was like, oh no, can't do that. Certainly not that. Don't turn off the security feature. That's the wrong way to deal with the issue.

+ +

But in the particular case that I'm working with, I'm using Redis, Heroku Redis, in particular, in a Heroku configuration. And the nature of how Heroku configures the Redis instances and the connectivity to our app into our dyno...I forget why. I read an article. They wrote it; Heroku wrote it. I trust them; they’re good. I've outsourced my trust to people that I do trust. The trust chain actually maps really well to the certificate trust chain. I trust that Heroku has taken security deeply seriously. And for some reason, their configuration of Redis requires that I turn on OpenSSL no verify mode. So I'm using this now both in Sidekiq, and then we're using our Redis instance for our Rails cache as well.

+ +

So in both cases, I said, "It's fine. Don't worry about it." I used the Don't worry about it configuration. And I didn't love it but I think it's okay. And partly, I'm trying to say this into the internet radio right now just in case anyone's listening who's like, no, no, no, you can't do that. That's bad. So I'm willing to be deeply wrong on the internet in favor of someone telling me and then I get to get out in front of it. But I think it's fine. Pretty sure it's fine. It should be fine.

+ +

STEPH: I love love love that you gave a very visual example of velociraptors, and then you're like, oh, but I turned it off. [laughs] So I'm going to start sending you a velociraptor gif each day.

+ +

CHRIS: I hope you do. I hope the internet holds you accountable to that.

+ +

STEPH: [laughs]

+ +

CHRIS: And I really look forward to [laughs] moving forward because that's a great way to start the day. Well, it doesn't need to start the day, but I look forward to them.

+ +

STEPH: [laughs] I am really intrigued because I'm with you. Like you said, there are certain entities that are in our trust chain where it's like, hey, you are running this for us, and so I do have faith and trust in you that you wouldn't steer me wrong and provide a bad recommendation. Someone on Stack Overflow telling me to turn off SSL verify uh; that’s not my trust chain. Heroku or someone else telling me I'm going to take it a little more seriously. And so I'm also interested in hearing from...what'd you say? You're speaking into the internet phone. [laughs] What'd you say?

+ +

CHRIS: I think I said internet radio. But yeah, in a way. I mean, we're recording over Skype right now. So in a manner of speaking, we're on the internet phone to make our internet radio show.

+ +

STEPH: [laughs] Oh goodness, the internet radio. I'm also intrigued to hear if other people are like, oh, no, no, no. Yeah, that sounds like an interesting scenario. Because I would think you'd still want your connection to...you said it's for Redis. So you still want that connection to be verified. But then if Redis itself can't have a specific...yeah, we're testing the boundaries of my SSL knowledge here as to how the heck you would even establish that SSL connection or the verification process.

+ +

CHRIS: Me too. And it also exists in an interesting space where Heroku is rather clear in their documentation about this. And it was a surprising claim when I saw it. And so, I don't expect them to be flippant about a thing that is important. Like, if they're like, "No, no, no, it is okay. You can turn off the security thing, don't worry." I trust that they're not just like, oh, we didn't think about it too much. But we figured why not? It's not a big deal. I'm sure that they have thought about it deeply because it is an important thing.

+ +

And so in a weird way, my trust of them and the severity of what this thing represents, I'm like, oh yeah, I super trust that because you're not going to get a major thing wrong. You might get a minor, small, subtle thing wrong. But this is a pretty major configuration change. As I say it, I'm now getting more worried. I'm now like, I feel fine about this. This doesn't seem like a problem at all. But then I keep saying stuff, and I'm like, oh no. That's why I love having a podcast; I find out things about myself as I talk into a microphone to you.

+ +

STEPH: We come here to share our deep, dark developer secrets.

+ +

Chris: Spooky developer therapy.

+ +

STEPH: But just to clarify, even though you've turned off the SSL verify, you're still connecting over SSL.

+ +

CHRIS: Yes, I believe that's the case. And if I'm remembering, I think the nature of how this works is they're using a self-signed certificate because of shared infrastructure or something, something that made sense when I read it. But it was the idea that they are doing a self-signed certificate. Therefore, to what you were talking about earlier, there isn't the certificate authority in the chain of those because it's self-signed. And so, they are not a trusted certificate authority. Therefore, that certificate that they have generated would not be trusted. But it does still allow for the SSL handshake and then communication to happen over SSL. It's just that fundamental question of trust. I'm saying, in this case, for reasons, it's okay. Trust me that I trust them. We're good. Which, again, I don't feel great about, but I think yes, it is still SSL, but it is a self-signed certificate. So we have to make this configuration change.

+ +

STEPH: Yeah, all of that makes sense. And it certainly sounds like you have been very thoughtful about that change and put in some investigative work. So on that note, I have a very unrelated bad joke for you.

+ +

CHRIS: I'm very excited.

+ +

STEPH: All right, here we go. All right, so what do you call an alligator wearing a vest?

+ +

CHRIS: I don't know. What do you call an alligator wearing a vest?

+ +

STEPH: An investigator.

+ +

[laughter]

+ +

On that note, shall we wrap up?

+ +

CHRIS: Oh, let's wrap up. We should also include a link in the show notes to the episode where you told the joke about the elephant hiding in the trees because that's one of my favorite jokes. You slayed me with that one. [laughs] But on that note, yes, let us wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,,as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+TqBJbyGb + + ]]> + + Chris Toomey + Steph Viccari + + + 311: Marketing Matters + https://bikeshed.thoughtbot.com/311 + a824cb19-9967-476d-a557-6f29b97bc369 + Tue, 05 Oct 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Longtime listener and friend of the show, Gio Lodi, released a book y'all should check out and Chris and Steph ruminate on a listener question about tension around marketing in open-source. + 37:37 + no + + + Longtime listener and friend of the show, Gio Lodi, released a book y'all should check out and Chris and Steph ruminate on a listener question about tension around marketing in open-source. +Say No To More Process, Say Yes To Trust by German Velasco (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) +Test-Driven Development in Swift with SwiftUI and Combine by Gio Lodi (https://tddinswift.com/) +Transcript: +CHRIS: Our golden roads. +STEPH: All right. I am also golden. +CHRIS: [vocalization] +STEPH: Oh, I haven't listened to that episode where I just broke out in song in the middle. Oh, you're about to add the [vocalization] [chuckles]. +CHRIS: I don't know why, though. Oh, golden roads, Golden Arches. +STEPH: Golden Arches, yeah. +CHRIS: Man, I did not know that my brain was doing that, but my brain definitely connected those without telling me about it. +STEPH: [laughs] +CHRIS: It's weird. People talk often about the theory that phones are listening, and then you get targeted ads based on what you said. But I'm almost certain it's actually the algorithms have figured out how to do the same intuitive leaps that your brain does. And so you'll smell something and not make the nine steps in between, but your brain will start singing a song from your childhood. And you're like, what is going on? Oh, right, because when I was watching Jurassic Park that one time, we were eating this type of chicken, and therefore when I smell paprika, Jurassic Park theme song. I got it, of course. +STEPH: [laughs] +CHRIS: And I think that's actually what's happening with the phones. That's my guess is that you went to a site, and the phones are like, cool, I got it, adjacent to that is this other thing, totally. Because I don't think the phones are listening. Occasionally, I think the phones are listening, but mostly, I don't think the phones are listening. +STEPH: I definitely think the phones are listening. +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey. So we have a bit of exciting news where we received an email from Gio Lodi, who is a listener of The Bike Shed. And Gio sent an email sharing with us some really exciting news that they have published a book on Test-Driven Development in Swift. And they acknowledge us in the acknowledgments of the book. Specifically, the acknowledgment says, "I also want to thank Chris Toomey and Steph Viccari, who keep sharing ideas on testing week after week on The Bike Shed Podcast." And that's just incredible. I'm so blown away, and I feel officially very famous. +CHRIS: This is how you know you're famous when you're in the acknowledgments of a book. But yeah, Gio is a longtime listener and friend of the show. He's written in many times and given us great tips, and pointers, and questions, and things. And I’ve so appreciated Gio’s voice in the community. And it's so wonderful, frankly, to hear that he has gotten value out of the show and us talking about testing. Because I always feel like I'm just regurgitating things that I've heard other people saying about testing and maybe one or two hard-learned truths that I've found. But it's really wonderful. And thank you so much, Gio. And best of luck for anyone out there who is doing Swift development and cares about testing or test-driven development, which I really think everybody should. Go check out that book. +STEPH: I must admit my Swift skills are incredibly rusty, really non-existent at this point. It's been so long since I've been in that world. But I went ahead and purchased a copy just because I think it's really cool. And I suspect there are a lot of testing conversations that, regardless of the specific code examples, still translate. At least, that's the goal that you and I have when we're having these testing conversations. Even if they're not specific to a language, we can still talk about testing paradigms and strategies. So I purchased a copy. I'm really looking forward to reading it. +And just to change things up a bit, we're going to start off with a listener question today. So this listener question comes from someone very close to the show. It comes from Thom Obarski. Hi, Thom. And Thom wrote in, "So I heard on a recent podcast I was editing some tension around marketing and open source. Specifically, a little perturbed at ReactJS that not only were people still dependent on a handful of big companies for their frameworks, but they also seem to be implying that the cachet of Facebook and having developer mindshare was not allowing smaller but potentially better solutions to shine through. In your opinion, how much does marketing play in the success of an open-source project framework rather than actually being the best tool for the job?" So a really thoughtful question. Thanks, Thom. Chris, I'm going to kick it over to you. What are your thoughts about this question? +CHRIS: Yeah, this is a super interesting one. And thank you so much, Thom, although I'm not sure that you're listening at this point. But we'll send you a note that we are replying to your question. And when I saw this one come through, it was interesting. I really love the kernel of the discussion here, but it is, again, very difficult to tease apart the bits. I think that the way the question was framed is like, oh, there's this bad thing that it's this big company that has this big name, and they're getting by on that. But really, there are these other great frameworks that exist, and they should get more of the mindshare. +And honestly, I'm not sure. I think marketing is a critically important aspect of the work that we do both in open source and, frankly, everywhere. And I'm going to clarify what I mean by that because I think it can take different shapes. But in terms of open-source, Facebook has poured a ton of energy and effort and, frankly, work into React as a framework. And they're also battle testing it on facebook.com, a giant website that gets tons of traffic, that sees various use cases, that has all permissions in there. They're really putting it through the wringer in that way. +And so there is a ton of value just in terms of this large organization working on and using this framework in the same way that GitHub and using Rails is a thing that is deeply valuable to us as a community. So I think having a large organization associated with something can actually be deeply valuable in terms of what it produces as an outcome for us as consumers of that open-source framework. +I think the other idea of sort of the meritocracy of the better framework should win out is, I don't know, it's like a Field of Dreams. Like, if you build it, they will come. It turns out I don't believe that that's actually true. And I think selling is a critical part of everything. And so if I think back to DHH's original video from so many years ago of like, I'm going to make a blog in 15 minutes; look at how much I'm not doing. That was a fantastic sales pitch for this new framework. And he was able to gain a ton of attention by virtue of making this really great sales pitch that sold on the merits of it. But that was marketing. He did the work of marketing there. +And I actually think about it in terms of a pull request. So I'm in a small organization. We're in a private repo. There's still marketing. There's still sales to be done there. I have to communicate to someone else the changes that I'm making, why it's valuable to the system, why they should support this change, this code coming into the codebase. And so I think that sort of communication is as critical to the whole conversation. And so the same thing happens at the level of open source. +I would love for the best framework to always win, but we also need large communities with Stack Overflow answers and community-supported plugins and things like that. And so it's a really difficult thing to treat marketing as just other, this different, separate thing when, in fact, I think they're all intertwined. And marketing is critically important, and having a giant organization behind something can actually have negative aspects. But I think overall; it really is useful in a lot of cases. Those are some initial thoughts. What do you think, Steph? +STEPH: Yeah, those are some great initial thoughts. I really agree with what you said. And I also like how you brought in the comparison of pull requests and how sales is still part of our job as developers, maybe not in the more traditional sense but in the way that we are marketing and communicating with the team. And circling back to what you were saying earlier about a bit how this is phrased, I think I typically agree that there's nothing nefarious that's afoot in regards to just because a larger company is sponsoring an open-source project or they are the ones responsible for it, I don't think there's anything necessarily bad about that. +And I agree with the other points that you made where it is helpful that these teams have essentially cultivated a framework or a project that is working for their team, that is helping their company, and then they have decided to open source it. And then, they have the time and energy that they can continue to invest in that project. And it is battle-tested because they are using it for their own projects as well. So it seems pretty natural that a lot of us then would gravitate towards these larger, more heavily supported projects and frameworks. Because then that's going to make our job easier and also give us more trust that we can turn to them when we do need help or have issues. +Or, like you mentioned, when we need to look up documentation, we know that that's going to be there versus some of the other smaller projects. They may also be wonderful projects. But if they are someone that's doing this in their spare time just on the weekends and yet I'm looking for something that I need to be incredibly reliable, then it probably makes sense for me to go with something that is supported by a team that's getting essentially paid to work on that project, at least that they're backed by a larger company. Versus if I'm going with a smaller project where someone is doing some wonderful work, but realistically, they're also doing it more on the weekends or in their spare time. So boiling it down, it’s similar to what you just said where marketing plays a very big part in open source, and the projects and frameworks that we adopt, and the things that we use. And I don't think that's necessarily a bad thing. +CHRIS: Yeah. I think, if anything, it's possibly a double-edged sword. Part of the question was around does React get to benefit just by the cachet of Facebook? But Facebook, as a larger organization sometimes that's a positive thing. Sometimes there's ire that is directed at Facebook as an organization. +And as a similar example, my experience with Google and Microsoft as large organizations, particularly backing open-source efforts, has almost sort of swapped over time, where originally, Microsoft there was almost nothing of Microsoft's open-source efforts that I was using. And I saw them as this very different shape of a company that I probably wouldn't be that interested in. And then they have deeply invested in things like GitHub, and VS Code, and TypeScript, and tons of projects that suddenly I'm like, oh, actually, a lot of what I use in the world is coming from Microsoft. That's really interesting. +And at the same time, Google has kind of gone in the opposite direction for me. And I've seen some of their movements switch from like, oh Google the underdog to now they're such a large company. And so the idea that the cachet, as the question phrase, of a company is just this uniformly positive thing and that it's perhaps an unfair benefit I don't see that as actually true. +But actually, as a more pointed example of this, I recently chose Svelte over React, and that was a conscious choice. And I went back and forth on it a few times, if we're being honest, because Svelte is a much smaller community. It does not have the large organizational backing that React or other frameworks do. And there was a certain marketing effort that was necessary to raise it into my visibility and then for me to be convinced that there is enough there, that there is a team that will maintain it, and that there are reasons to choose that and continue with it. And I've been very happy with it as a choice. +But I was very conscious in that choice that I'm choosing something that doesn't have that large organizational backing. Because there's a nicety there of like, I trust that Facebook will probably keep investing in React because it is the fundamental technology of the front end of their platform. So yeah, it's not going to go anywhere. But I made the choice of going with Svelte. So it's an example of where the large organization didn't win out in my particular case. So I think marketing is a part of the work, a part of the conversation. It's part of communication. And so I am less negative on it, I think, than the question perhaps was framed, but as always, it depends. +STEPH: Yeah, I'm trying to think of a scenario where I would be concerned about the fact that I'm using open source that's backed by a specific large company or corporation. And the main scenario I can think of is what happens when you conflict or if you have values that conflict with a company that is sponsoring that project? So if you are using an open-source project, but then the main community or the company that then works on that project does something that you really disagree with, then what do you do? How do you feel about that situation? Do you continue to use that open-source project? Do you try to use a different open-source project? +And I had that conversation frankly with myself recently, thinking through what to do in that situation and how to view it. And I realize this may not be how everybody views it, and it's not appropriate for all situations. But I do typically look at open-source projects as more than who they are backed by, but the community that's actively working on that project and who it benefits. So even if there is one particular group that is doing something that I don't agree with, that doesn't necessarily mean that wholesale I no longer want to be a part of this community. It just means that I still want to be a part, but I still want to share my concerns that I think a part of our community is going in a direction that I don't agree with or I don't think is a good direction. +That's, I guess, how I reason with myself; even if an open-source project is backed by someone that I don't agree with, either one, you can walk away. That seems very complicated, depending on your dependencies. Or two, you find ways to then push back on those values if you feel that the community is headed in a direction that you don't agree with. And that all depends on how comfortable you are and how much power you feel like you have in that situation to express your opinion. So it's a complicated space. +CHRIS: Yeah, that is a super subtle edge case of all of this. And I think I aligned with what you said of trying to view an open-source project as more generally the community that's behind it as opposed to even if there's a strong, singular organization behind it. But that said, that's definitely a part of it. And again, it's a double-edged sword. It's not just, oh, giant company; this is great. That giant company now has to consider this. +And I think in the case of Facebook and React, that is a wonderful hiring channel for them. Now all the people that use React anywhere are like, "Oh man, I could go work at Facebook on React? That's exciting." That's a thing that's a marketing tool from a hiring perspective for them. But it cuts both ways because suddenly, if the mindshare moves in a different direction, or if Facebook as an organization does something complicated, then React as a community can start to shift away. Maybe you don't move the current project off of it, but perhaps you don't start the next one with it. And so, there are trade-offs and considerations in all directions. And again, it depends. +STEPH: Yeah. I think overall, the thing that doesn't depend is marketing matters. It is a real part of the ecosystem, and it will influence our decisions. And so, just circling back to Thom's question, I think it does play a vital role in the choices that we make. +CHRIS: Way to stick the landing. +STEPH: Thanks. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: Changing topics just a bit, what's new in your world? +CHRIS: Well, we had what I would call a mini perfect storm this week. We broke the build but in a pretty solid way. And it was a little bit difficult to get it back under control. And it has pushed me ever so slightly forward in my desire to have a fully optimized CI and deploy pipeline. Mostly, I mean that in terms of ratcheting. I'm not actually going to do anything beyond a very small set of configurations. +But to describe the context, we use pull requests because that's the way that we communicate. We do code reviews, all that fun stuff. And so there was a particular branch that had a good amount of changes, and then something got merged. And this other pull request was approved. And that person then clicked the rebase and merge button, which I have configured the repository, so that merge commits are not allowed because I'm not interested in that malarkey in our history. But merge commits or rebase and merge. I like that that makes sense. +In this particular case, we ran into the very small, subtle edge case of if you click the rebase and merge button, GitHub is now producing a new commit that did not exist before, a new version of the code. So they're taking your changes, and they are rebasing them onto the current main branch. And then they're attempting to merge that in. And A, that was allowed. B, the CI configuration did not require that to be in a passing state. And so basically, in doing that rebase and merge, it produced an artifact in the build that made it fail. And then attempting to unwind that was very complicated. +So basically, the rebase produced...there were duplicate changes within a given file. So Git didn't see it as a conflict because the change was made in two different parts of the file, but those were conflicting changes. So Git was like, this seems like it's fine. I can merge this, no problem. But it turns out from a functional perspective; it did not work. The build failed. And so now our main branch was failing and then trying to unwind that it just was surprisingly difficult to unwind that. And it really highlighted the importance of keeping the main branch green, keeping the build always passing. And so, I configured a few things in response to this. There is a branch protection rule that you can enable. +And let me actually pull up the specific configuration that I set up. So I now have enabled require status checks to pass before merging, which, if we're being honest, I thought that was the default. It turns out it was not the default. So we are now requiring status checks to pass before merging. I'm fully aware of the awkward, painful like, oh no, the build is failing but also, we have a bug. We need to deploy this. We must get something merged in. +So hopefully, if and when that situation presents itself, I will turn this off or somehow otherwise work around it. But for now, I would prefer to have this as a yeah; this is definitely a configuration we want. So require status checks to pass before merging and then require branches to be up to date before merging. So the button that does the rebase and merge, I don't want that to actually do a rebase on GitHub. I want the branch to already be up to date. Basically, I only ever want fast-forward merges on our main branch. So all code should be ahead of main, and we are simply updating what main points at. We are not creating new code. That code has run on CI, that version of the code specifically. We are fully rebased and up to date on top of main, and that's how we're going. +STEPH: All of that is super interesting. I have a question about the workflow. I want to make sure I'm understanding it correctly. So let's say that I have issued a PR, and then someone else has merged into the main branch. So now my PR is behind me, and I don't have that latest commit. With the new configuration, can I still use the rebase and merge, or will I need to rebase locally and then push up my branch before I can merge into main but at least using the GitHub UI? +CHRIS: I believe that you would be forced to rebase locally, force push, and then CI would rebuild, and that's what it is. So I think that's what require branches to be up to date before merging means. So that's my hope. That is the intention here. I do realize that's complicated. So this requirement, which I like, because again, I really want the idea that no, no, no, we, the developers, are in charge of that final state. That final state should always run as part of a build of CI on our pull request/branch before going into main. So no code should be new. There should be no new commits that have never been tested before going into main. That's my strong belief. I want that world. I realize that's...I don't know. Maybe I'm getting pedantic, or I'm a micromanager of the Git history or whatever. I'm fine with any of those insults that people want to lob at me. That's fine. But that's what I feel. +That said, this is a nuisance. I'm fully aware of that. And so imagine the situation where we got a couple of different things that have been in flight. People have been working on different...say there are three pull requests that are all coming to completion at the same time. Then you start to go to merge something, and you realize, oh no, somebody else just merged. So you rebase, and then you wait for CI to build. And just as the CI is completing, somebody else merges something, and you're like, ah, come on. And so then you have to one more time rebase, push, wait for the build to be green. So I get that that is not an ideal situation. +Right now, our team is three developers. So there are a few enough of us that I feel like this is okay. We can manage this via human intervention and just deal with the occasional weight. But in the back of my mind, of course, I want to find a better solution to this. So what I've been exploring…there's a handful of different utilities that I'm looking at, but they are basically merged queues as an idea. So there are three that I'm looking at, or maybe just two, but there's mergify.io, which is a hosted solution that does this sort of thing. And then Shopify has a merge queue implementation that they're running. +So the idea with this is when you as a developer are ready to merge something, you add a label to it. And when you add that label, there's some GitHub Action or otherwise some workflow in the background that sees that this has happened and now adds it to a merge queue. So it knows all of the different things that might want to be merged. And this is especially important as the team grows so that you don't get that contention. You can just say, "Yes, I would like my changes to go out into production." And so, when you label it, it then goes into this merge queue. And the background system is now going to take care of any necessary rebases. It's going to sequence them, so it's not just constantly churning all of the branches. It's waiting because it knows the order that they're ideally going to go out in. +If CI fails for any of them because rebasing suddenly, you're in an inconsistent state; if your build fails, then it will kick you out of the merge queue. It will let you know. So it will send you a notification in some manner and say, "Hey, hey, hey, you got to come look at this again. You've been kicked out of the merge queue. You're not going to production." But ideally, it adds that layer of automation to, frankly, this nuisance of having to keep things up to date and always wanting code to be run on CI and on a pull request before it gets into main. Then the ideal version is when it does actually merge your code, it pings you in Slack or something like that to say, "Hey, your changes just went out to production." Because the other thing I'm hoping for is a continuous deployment. +STEPH: The idea of a merge queue sounds really interesting. I've never worked with a process like that. And one of the benefits I can see is if I know I'm ready for something to go like if I'm waiting on a green build and I'm like, hey, as soon as this is green, I'd really like for it to get merged. Then currently, I'm checking in on it, so I will restart the build. And then, every so often, I'm going back to say, "Okay, are you green? Are you green? Can I emerge?" But if I have a merge queue, I can say, "Hey, merge queue, when this is green, please go and merge it for me." If I'm understanding the behavior correctly, that sounds really nifty. +CHRIS: I think that's a distinct but useful aspect of this is the idea that when you as a developer decide this PR is ready to go, you don't need to wait for either the current build or any subsequent builds. If there are rebases that need to happen, you basically say, "I think this code's good to go. We've gotten the necessary approvals. We've got the buy-in and the teams into this code." So cool, I now market as good. And you can walk away from it, and you will be notified either if it fails to get merged or if it successfully gets merged and deployed. So yes, that dream of like, you don't have to sit there watching the pot boil anymore. +STEPH: Yeah, that sounds nice. I do have to ask you a question. And this is related to one of the blog posts that you and I love deeply and reference fairly frequently. And it's the one that's written by German Velasco about Say No to More Process, and Say Yes to Trust. And I'm wondering, based on the pain that you felt from this new commit, going into main and breaking the main build, how do you feel about that balance of we spent time investigating this issue, and it may or may not happen again, and we're also looking into these new processes to avoid this from happening? I'm curious what your thought process is there because it seems like it's a fair amount of work to invest in the new process, but maybe that's justified based on the pain that you felt from having to fix the build previously. +CHRIS: Oh, I love the question. I love the subtle pushback here. I love this frame of mind. I really love that blog post. German writes incredible blog posts. And this is one that I just keep coming back to. In this particular case, when this situation occurred, we had a very brief...well, it wasn't even that brief because actually unwinding the situation was surprisingly painful, and we had some changes that we really wanted to get out, but now the build was broken. And so that churn and slowdown of our build pipeline and of our ability to actually get changes out to production was enough pain that we're like, okay, cool. +And then the other thing is we actually all were in agreement that this is the way we want things to work anyway, that idea that things should be rebased and tested on CI as part of a pull request. And then we're essentially only doing fast-forward merges on the main branch, or we're fast forward merging main into this new change. That's the workflow that we wanted. So this configuration was really just adding a little bit of software control to the thing that we wanted. So it was an existing process in our minds. This is the thing we were trying to do. It's just kind of hard to keep up with, frankly. But it turns out GitHub can manage it for us and enforce the process that we wanted. So it wasn't a new process per se. It was new automation to help us hold ourselves to the process that we had chosen. +And again, it's minimally painful for the team given the size that we're at now, but I am looking out to the future. And to be clear, this is one of the many things that fall on the list of; man, I would love to have some time to do this, but this is obviously not a priority right now. So I'm not allowed to do this. This is explicitly on the not allowed to touch list, but someday. I'm very excited about this because this does fundamentally introduce some additional work in the pipeline, and I don't want that. +Like you said, is this process worth it for the very small set of times that it's going to have a bad outcome? But in my mind, the better version, that down the road version where we have a merge queue, is actually a better version overall, even with just a tiny team of three developers that are maybe never even conflicting in our merges, except for this one standout time that happens once every three months or whatever. This is still nicer. I want to just be able to label a pull request and walk away and have it do the thing that we have decided as a team that we want. So that's the dream. +STEPH: Oh, I love that phrasing, to label a pull request and be able to walk away. Going back to our marketing, that really sells that merge queue to me. [laughs] +Mid-roll Ad +And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. +With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. +The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. +CHRIS: To be clear, and this is to borrow on some of Charity Majors' comments around continuous deployment and whatnot, is a developer should stay very close to the code if they are merging it. Because if we're doing continuous deployment, that's going to go out to production. If anything's going to happen, I want that individual to be aware. So ideally, there's another set of optimizations that I need to make on top of this. So we've got the merge queue, and that'll be great. Really excited about that. +But if we're going to lean into this, I want to optimize our CI pipeline and our deployment pipeline as much as possible such that even in the worst case where there's three different builds that are fighting for contention and trying to get out, the longest any developer might go between labeling a pull request and saying, "This is good to go," and it getting out to production, again, even if they're contending with other PRs, is say 10, 15 minutes, something like that. +I want Slack to notify them and them to then re-engage and keep an eye on things, see if any errors pop up, anything like that that they might need to respond to. Because they're the one that's got the context on the code at that point, and that context is decaying. The minute you've just merged a pull request and you're walking away from that code, the next day, you're like, what did I work on? I don't remember that at all. That code doesn't exist anymore in my brain. And so,,, staying close to that context is incredibly important. +So there's a handful of optimizations that I've looked at in terms of the CircleCI build. I've talked about my not rebuilding when it actually gets fast-forward merged because we've already done that build on the pull request. I'm being somewhat pointed in saying this has to build on a pull request. So if it did just build on a pull request, let's not rebuild it on main because it's identically the same commit. CircleCI, I'm looking at you. Give me a config button for that, please. I would really love that config button. +But there are a couple of other things that I've looked at. There's RSpec::Retry from NoRedInk, which will allow for some retry semantics. Because it will be really frustrating if your build breaks and you fall out of the merge queue. So let's try a little bit of retry logic on there, particularly around feature specs, because that's where this might happen. +There's Knapsack Pro which is a really interesting thing that I've looked at, which does parallelization of your RSpec test suite. But it does it in a different way than say Circle does. It actually runs a build queue, and each test gets sent over, and they have build agents on their side. And it's an interesting approach. I'm intrigued. I think it could use some nice speed-ups. There's esbuild on the Heroku side so that our assets build so much more quickly. There are lots of things. I want to make it very fast. But again, this is on the not allowed to do it list. [laughs] +STEPH: I love how most of the world has a to-do list, and you have this not-allowed to-do list that you're adding items to. And I'm really curious what all is on the not allowed to touch lists or not allowed to-do list. [laughs] +CHRIS: I think this might be inherent to being a developer is like when I see a problem, I want to fix it. I want to optimize it. I want to tweak it. I want to make it so that that never happens again. But plenty of things...coming back to German's post of Say No to More Process, some things shouldn't be fixed, or the cost of fixing is so much higher than the cost of just letting it happen again and dealing with it manually at that moment. +And so I think my inherent nature as a developer there's a voice in my head that is like, fix everything that's broken. And I'm like, sorry. Sorry, brain, I do not have that kind of time. And so I have to be really choosy about where the time goes. And this extends to the team as well. We need to be intentional around what we're building. Actually, there's a feeling that I've been feeling more acutely than ever, but it's the idea of this trade-off or optimization between speed and getting features out into the world and laying the right fundamentals. We're still very early on in this project, and I want to make sure we're thinking about things intentionally. +I've been on so many projects where it's many years after it started and when I ask someone, "Hey, why do your background jobs work that way? That's a little weird." And they're like, "Yeah, that was just a thing that happened, and then it never changed. And then, we copied it and duplicated, and that pattern just got reinforced deeply within the app. And at this point, it would cost too much to change." I've seen that thing play out so many times at so many different organizations that I'm overwhelmed with that knowledge in the back of my head. And I'm like, okay, I got to get it just right. +But I can't take the time that is necessary to get it, quote, unquote, "Just right." I do not have that kind of time. I got to ship some features. And this tension is sort of the name of the game. It's the thing I've been doing for my entire career. But now, given the role that I have with a very early-stage startup, I've never felt it more acutely. I've never had to be equally as concerned with both sides of that. Both matter all the more now than they ever have before, and so I'm kind of existing in that space. +STEPH: I really like that phrasing of that space because that deeply resonates with me as well. And that not allowed to-do list I have a similar list. For me, it's just called a wishlist. And so it's a wishlist that I will revisit every so often, but honestly, most things on there don't get done. And then I'll clear it out every so often when I feel it's not likely that I'm going to get to it. And then I'll just start fresh. So I also have a similar this is what I would like to do if I had the time. +And I agree that there's this inclination to automate as well. As soon as we have to do something that felt painful once, then we feel like, oh, we should automate it. And that's a conversation that I often have with myself is at what point is the cost of automation worthwhile versus should we just do this manually until we get to that point? So I love those nuanced conversations around when is the right time to invest further in this, and what is the impact? And what is the cost of it? And what are the trade-offs? And making that decision isn't always clear. And so I think that's why I really enjoy these conversations because it's not a clear rubric as to like, this is when you invest, and this is when you don't. +But I do feel like being a consultant has helped me hone those skills because I am jumping around to different teams, and I'm recognizing they didn't do this thing. Maybe they didn't address this or invest in it, and it's working for them. There are some oddities. Like you said, maybe I'll ask, "Why is this? It seems a little funky. What's the history?" And they'll be like, "Yeah, it was built in a hurry, but it works. And so there hasn't been any churn. We don't have any issues with it, so we have just left it." And that has helped reinforce the idea that just because something could be improved doesn't mean it's worthwhile to improve it. +Circling back to your original quest where you are looking to improve the process for merging and ensuring that CI stays green, I do like that you highlighted the fact that we do need to just be able to override settings. So that's something that has happened recently this week for me and my client work where we have had PRs that didn't have a green build because we have some flaky tests that we are actively working on. But we recognize that they're flaky, and we don't want that to block us. I'm still shipping work. So I really appreciate the consideration where we want to optimize so that everyone has an easy merging experience. We know things are green. It's trustworthy. But then we also have the ability to still say, "No, I am confident that I know what I'm doing here, and I want to merge it anyways, but thank you for the warning." +CHRIS: And the constant pendulum swing of over-correcting in various directions I've experienced that. And as you said, in the back of my mind, I'm like, oh, I know that this setting I'm going to need a way to turn this setting off. So I want to make sure that, most importantly, I'm not the only one on the team who can turn that off because the day that I am away on vacation and the build is broken, and we have a critical bug that we need to fix, somebody else needs to be able to do that. So that's sort of the story in my head. +At the same time, though, I've worked on so many teams where they're like, oh yeah, the build has been broken for seven weeks. We have a ticket in the backlog to fix that. And it's like, no, the build has to not be broken for that long. And so I agree with what you were saying of consulting has so usefully helped me hone where I fall on these various spectrums. But I do worry that I'm just constantly over-correcting in one direction or the other. I'm never actually at an optimum. I am just constantly whatever the most recent thing was, which is really impacting my thinking on this. And I try to not do that, but it's hard. +STEPH: Oh yeah. I'm totally biased towards my most recent experiences, and whatever has caused me the most pain or success recently. I'm definitely skewed in that direction. +CHRIS: Yeah, I definitely have the recency bias, and I try to have a holistic view of all of the things I've seen. There's actually a particular one that I don't want to pat myself on the back for because it's not a good thing. But currently, our test suite, when it runs, there's just a bunch of noise. There's a bunch of other stuff that gets printed out, like a bunch of it. And I'm reminded of a tweet from Kevin Newton, a friend of the show, and I just pulled it up here. "Oh, the lengths I will go to avoid warnings in my terminal, especially in the middle of my green dots. Don't touch my dots." It's a beautiful beauty. He actually has a handful about the green dots. And I feel this feel. +When I run my test suite, I just want a sea of green dots. That's all I want to see. But right now, our test suite is just noise. It's so much noise. And I am very proud of...I feel like this is a growth moment for me where I've been like, you know what? That is not the thing to fix today. We can deal with some noise amongst the green dots for now. Someday, I'm just going to lose it, and I'm going to fix it, and it's going to come back to green dots. [chuckles] +STEPH: That sounds like such a wonderful children's book or Dr. Seuss. Oh, the importance of green dots or, oh, the places green dots will take you. +CHRIS: Don't touch my dots. [laughter] +STEPH: Okay. Maybe a slightly aggressive Dr. Seuss, but I still really like it. +CHRIS: A little more, yeah. +STEPH: On that note of our love of green dots, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeee!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Longtime listener and friend of the show, Gio Lodi, released a book y'all should check out and Chris and Steph ruminate on a listener question about tension around marketing in open-source.

+ + + +

Transcript:

+ +

CHRIS: Our golden roads.

+ +

STEPH: All right. I am also golden.

+ +

CHRIS: [vocalization]

+ +

STEPH: Oh, I haven't listened to that episode where I just broke out in song in the middle. Oh, you're about to add the [vocalization] [chuckles].

+ +

CHRIS: I don't know why, though. Oh, golden roads, Golden Arches.

+ +

STEPH: Golden Arches, yeah.

+ +

CHRIS: Man, I did not know that my brain was doing that, but my brain definitely connected those without telling me about it.

+ +

STEPH: [laughs]

+ +

CHRIS: It's weird. People talk often about the theory that phones are listening, and then you get targeted ads based on what you said. But I'm almost certain it's actually the algorithms have figured out how to do the same intuitive leaps that your brain does. And so you'll smell something and not make the nine steps in between, but your brain will start singing a song from your childhood. And you're like, what is going on? Oh, right, because when I was watching Jurassic Park that one time, we were eating this type of chicken, and therefore when I smell paprika, Jurassic Park theme song. I got it, of course.

+ +

STEPH: [laughs]

+ +

CHRIS: And I think that's actually what's happening with the phones. That's my guess is that you went to a site, and the phones are like, cool, I got it, adjacent to that is this other thing, totally. Because I don't think the phones are listening. Occasionally, I think the phones are listening, but mostly, I don't think the phones are listening.

+ +

STEPH: I definitely think the phones are listening.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey. So we have a bit of exciting news where we received an email from Gio Lodi, who is a listener of The Bike Shed. And Gio sent an email sharing with us some really exciting news that they have published a book on Test-Driven Development in Swift. And they acknowledge us in the acknowledgments of the book. Specifically, the acknowledgment says, "I also want to thank Chris Toomey and Steph Viccari, who keep sharing ideas on testing week after week on The Bike Shed Podcast." And that's just incredible. I'm so blown away, and I feel officially very famous.

+ +

CHRIS: This is how you know you're famous when you're in the acknowledgments of a book. But yeah, Gio is a longtime listener and friend of the show. He's written in many times and given us great tips, and pointers, and questions, and things. And I’ve so appreciated Gio’s voice in the community. And it's so wonderful, frankly, to hear that he has gotten value out of the show and us talking about testing. Because I always feel like I'm just regurgitating things that I've heard other people saying about testing and maybe one or two hard-learned truths that I've found. But it's really wonderful. And thank you so much, Gio. And best of luck for anyone out there who is doing Swift development and cares about testing or test-driven development, which I really think everybody should. Go check out that book.

+ +

STEPH: I must admit my Swift skills are incredibly rusty, really non-existent at this point. It's been so long since I've been in that world. But I went ahead and purchased a copy just because I think it's really cool. And I suspect there are a lot of testing conversations that, regardless of the specific code examples, still translate. At least, that's the goal that you and I have when we're having these testing conversations. Even if they're not specific to a language, we can still talk about testing paradigms and strategies. So I purchased a copy. I'm really looking forward to reading it.

+ +

And just to change things up a bit, we're going to start off with a listener question today. So this listener question comes from someone very close to the show. It comes from Thom Obarski. Hi, Thom. And Thom wrote in, "So I heard on a recent podcast I was editing some tension around marketing and open source. Specifically, a little perturbed at ReactJS that not only were people still dependent on a handful of big companies for their frameworks, but they also seem to be implying that the cachet of Facebook and having developer mindshare was not allowing smaller but potentially better solutions to shine through. In your opinion, how much does marketing play in the success of an open-source project framework rather than actually being the best tool for the job?" So a really thoughtful question. Thanks, Thom. Chris, I'm going to kick it over to you. What are your thoughts about this question?

+ +

CHRIS: Yeah, this is a super interesting one. And thank you so much, Thom, although I'm not sure that you're listening at this point. But we'll send you a note that we are replying to your question. And when I saw this one come through, it was interesting. I really love the kernel of the discussion here, but it is, again, very difficult to tease apart the bits. I think that the way the question was framed is like, oh, there's this bad thing that it's this big company that has this big name, and they're getting by on that. But really, there are these other great frameworks that exist, and they should get more of the mindshare.

+ +

And honestly, I'm not sure. I think marketing is a critically important aspect of the work that we do both in open source and, frankly, everywhere. And I'm going to clarify what I mean by that because I think it can take different shapes. But in terms of open-source, Facebook has poured a ton of energy and effort and, frankly, work into React as a framework. And they're also battle testing it on facebook.com, a giant website that gets tons of traffic, that sees various use cases, that has all permissions in there. They're really putting it through the wringer in that way.

+ +

And so there is a ton of value just in terms of this large organization working on and using this framework in the same way that GitHub and using Rails is a thing that is deeply valuable to us as a community. So I think having a large organization associated with something can actually be deeply valuable in terms of what it produces as an outcome for us as consumers of that open-source framework.

+ +

I think the other idea of sort of the meritocracy of the better framework should win out is, I don't know, it's like a Field of Dreams. Like, if you build it, they will come. It turns out I don't believe that that's actually true. And I think selling is a critical part of everything. And so if I think back to DHH's original video from so many years ago of like, I'm going to make a blog in 15 minutes; look at how much I'm not doing. That was a fantastic sales pitch for this new framework. And he was able to gain a ton of attention by virtue of making this really great sales pitch that sold on the merits of it. But that was marketing. He did the work of marketing there.

+ +

And I actually think about it in terms of a pull request. So I'm in a small organization. We're in a private repo. There's still marketing. There's still sales to be done there. I have to communicate to someone else the changes that I'm making, why it's valuable to the system, why they should support this change, this code coming into the codebase. And so I think that sort of communication is as critical to the whole conversation. And so the same thing happens at the level of open source.

+ +

I would love for the best framework to always win, but we also need large communities with Stack Overflow answers and community-supported plugins and things like that. And so it's a really difficult thing to treat marketing as just other, this different, separate thing when, in fact, I think they're all intertwined. And marketing is critically important, and having a giant organization behind something can actually have negative aspects. But I think overall; it really is useful in a lot of cases. Those are some initial thoughts. What do you think, Steph?

+ +

STEPH: Yeah, those are some great initial thoughts. I really agree with what you said. And I also like how you brought in the comparison of pull requests and how sales is still part of our job as developers, maybe not in the more traditional sense but in the way that we are marketing and communicating with the team. And circling back to what you were saying earlier about a bit how this is phrased, I think I typically agree that there's nothing nefarious that's afoot in regards to just because a larger company is sponsoring an open-source project or they are the ones responsible for it, I don't think there's anything necessarily bad about that.

+ +

And I agree with the other points that you made where it is helpful that these teams have essentially cultivated a framework or a project that is working for their team, that is helping their company, and then they have decided to open source it. And then, they have the time and energy that they can continue to invest in that project. And it is battle-tested because they are using it for their own projects as well. So it seems pretty natural that a lot of us then would gravitate towards these larger, more heavily supported projects and frameworks. Because then that's going to make our job easier and also give us more trust that we can turn to them when we do need help or have issues.

+ +

Or, like you mentioned, when we need to look up documentation, we know that that's going to be there versus some of the other smaller projects. They may also be wonderful projects. But if they are someone that's doing this in their spare time just on the weekends and yet I'm looking for something that I need to be incredibly reliable, then it probably makes sense for me to go with something that is supported by a team that's getting essentially paid to work on that project, at least that they're backed by a larger company. Versus if I'm going with a smaller project where someone is doing some wonderful work, but realistically, they're also doing it more on the weekends or in their spare time. So boiling it down, it’s similar to what you just said where marketing plays a very big part in open source, and the projects and frameworks that we adopt, and the things that we use. And I don't think that's necessarily a bad thing.

+ +

CHRIS: Yeah. I think, if anything, it's possibly a double-edged sword. Part of the question was around does React get to benefit just by the cachet of Facebook? But Facebook, as a larger organization sometimes that's a positive thing. Sometimes there's ire that is directed at Facebook as an organization.

+ +

And as a similar example, my experience with Google and Microsoft as large organizations, particularly backing open-source efforts, has almost sort of swapped over time, where originally, Microsoft there was almost nothing of Microsoft's open-source efforts that I was using. And I saw them as this very different shape of a company that I probably wouldn't be that interested in. And then they have deeply invested in things like GitHub, and VS Code, and TypeScript, and tons of projects that suddenly I'm like, oh, actually, a lot of what I use in the world is coming from Microsoft. That's really interesting.

+ +

And at the same time, Google has kind of gone in the opposite direction for me. And I've seen some of their movements switch from like, oh Google the underdog to now they're such a large company. And so the idea that the cachet, as the question phrase, of a company is just this uniformly positive thing and that it's perhaps an unfair benefit I don't see that as actually true.

+ +

But actually, as a more pointed example of this, I recently chose Svelte over React, and that was a conscious choice. And I went back and forth on it a few times, if we're being honest, because Svelte is a much smaller community. It does not have the large organizational backing that React or other frameworks do. And there was a certain marketing effort that was necessary to raise it into my visibility and then for me to be convinced that there is enough there, that there is a team that will maintain it, and that there are reasons to choose that and continue with it. And I've been very happy with it as a choice.

+ +

But I was very conscious in that choice that I'm choosing something that doesn't have that large organizational backing. Because there's a nicety there of like, I trust that Facebook will probably keep investing in React because it is the fundamental technology of the front end of their platform. So yeah, it's not going to go anywhere. But I made the choice of going with Svelte. So it's an example of where the large organization didn't win out in my particular case. So I think marketing is a part of the work, a part of the conversation. It's part of communication. And so I am less negative on it, I think, than the question perhaps was framed, but as always, it depends.

+ +

STEPH: Yeah, I'm trying to think of a scenario where I would be concerned about the fact that I'm using open source that's backed by a specific large company or corporation. And the main scenario I can think of is what happens when you conflict or if you have values that conflict with a company that is sponsoring that project? So if you are using an open-source project, but then the main community or the company that then works on that project does something that you really disagree with, then what do you do? How do you feel about that situation? Do you continue to use that open-source project? Do you try to use a different open-source project?

+ +

And I had that conversation frankly with myself recently, thinking through what to do in that situation and how to view it. And I realize this may not be how everybody views it, and it's not appropriate for all situations. But I do typically look at open-source projects as more than who they are backed by, but the community that's actively working on that project and who it benefits. So even if there is one particular group that is doing something that I don't agree with, that doesn't necessarily mean that wholesale I no longer want to be a part of this community. It just means that I still want to be a part, but I still want to share my concerns that I think a part of our community is going in a direction that I don't agree with or I don't think is a good direction.

+ +

That's, I guess, how I reason with myself; even if an open-source project is backed by someone that I don't agree with, either one, you can walk away. That seems very complicated, depending on your dependencies. Or two, you find ways to then push back on those values if you feel that the community is headed in a direction that you don't agree with. And that all depends on how comfortable you are and how much power you feel like you have in that situation to express your opinion. So it's a complicated space.

+ +

CHRIS: Yeah, that is a super subtle edge case of all of this. And I think I aligned with what you said of trying to view an open-source project as more generally the community that's behind it as opposed to even if there's a strong, singular organization behind it. But that said, that's definitely a part of it. And again, it's a double-edged sword. It's not just, oh, giant company; this is great. That giant company now has to consider this.

+ +

And I think in the case of Facebook and React, that is a wonderful hiring channel for them. Now all the people that use React anywhere are like, "Oh man, I could go work at Facebook on React? That's exciting." That's a thing that's a marketing tool from a hiring perspective for them. But it cuts both ways because suddenly, if the mindshare moves in a different direction, or if Facebook as an organization does something complicated, then React as a community can start to shift away. Maybe you don't move the current project off of it, but perhaps you don't start the next one with it. And so, there are trade-offs and considerations in all directions. And again, it depends.

+ +

STEPH: Yeah. I think overall, the thing that doesn't depend is marketing matters. It is a real part of the ecosystem, and it will influence our decisions. And so, just circling back to Thom's question, I think it does play a vital role in the choices that we make.

+ +

CHRIS: Way to stick the landing.

+ +

STEPH: Thanks.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Changing topics just a bit, what's new in your world?

+ +

CHRIS: Well, we had what I would call a mini perfect storm this week. We broke the build but in a pretty solid way. And it was a little bit difficult to get it back under control. And it has pushed me ever so slightly forward in my desire to have a fully optimized CI and deploy pipeline. Mostly, I mean that in terms of ratcheting. I'm not actually going to do anything beyond a very small set of configurations.

+ +

But to describe the context, we use pull requests because that's the way that we communicate. We do code reviews, all that fun stuff. And so there was a particular branch that had a good amount of changes, and then something got merged. And this other pull request was approved. And that person then clicked the rebase and merge button, which I have configured the repository, so that merge commits are not allowed because I'm not interested in that malarkey in our history. But merge commits or rebase and merge. I like that that makes sense.

+ +

In this particular case, we ran into the very small, subtle edge case of if you click the rebase and merge button, GitHub is now producing a new commit that did not exist before, a new version of the code. So they're taking your changes, and they are rebasing them onto the current main branch. And then they're attempting to merge that in. And A, that was allowed. B, the CI configuration did not require that to be in a passing state. And so basically, in doing that rebase and merge, it produced an artifact in the build that made it fail. And then attempting to unwind that was very complicated.

+ +

So basically, the rebase produced...there were duplicate changes within a given file. So Git didn't see it as a conflict because the change was made in two different parts of the file, but those were conflicting changes. So Git was like, this seems like it's fine. I can merge this, no problem. But it turns out from a functional perspective; it did not work. The build failed. And so now our main branch was failing and then trying to unwind that it just was surprisingly difficult to unwind that. And it really highlighted the importance of keeping the main branch green, keeping the build always passing. And so, I configured a few things in response to this. There is a branch protection rule that you can enable.

+ +

And let me actually pull up the specific configuration that I set up. So I now have enabled require status checks to pass before merging, which, if we're being honest, I thought that was the default. It turns out it was not the default. So we are now requiring status checks to pass before merging. I'm fully aware of the awkward, painful like, oh no, the build is failing but also, we have a bug. We need to deploy this. We must get something merged in.

+ +

So hopefully, if and when that situation presents itself, I will turn this off or somehow otherwise work around it. But for now, I would prefer to have this as a yeah; this is definitely a configuration we want. So require status checks to pass before merging and then require branches to be up to date before merging. So the button that does the rebase and merge, I don't want that to actually do a rebase on GitHub. I want the branch to already be up to date. Basically, I only ever want fast-forward merges on our main branch. So all code should be ahead of main, and we are simply updating what main points at. We are not creating new code. That code has run on CI, that version of the code specifically. We are fully rebased and up to date on top of main, and that's how we're going.

+ +

STEPH: All of that is super interesting. I have a question about the workflow. I want to make sure I'm understanding it correctly. So let's say that I have issued a PR, and then someone else has merged into the main branch. So now my PR is behind me, and I don't have that latest commit. With the new configuration, can I still use the rebase and merge, or will I need to rebase locally and then push up my branch before I can merge into main but at least using the GitHub UI?

+ +

CHRIS: I believe that you would be forced to rebase locally, force push, and then CI would rebuild, and that's what it is. So I think that's what require branches to be up to date before merging means. So that's my hope. That is the intention here. I do realize that's complicated. So this requirement, which I like, because again, I really want the idea that no, no, no, we, the developers, are in charge of that final state. That final state should always run as part of a build of CI on our pull request/branch before going into main. So no code should be new. There should be no new commits that have never been tested before going into main. That's my strong belief. I want that world. I realize that's...I don't know. Maybe I'm getting pedantic, or I'm a micromanager of the Git history or whatever. I'm fine with any of those insults that people want to lob at me. That's fine. But that's what I feel.

+ +

That said, this is a nuisance. I'm fully aware of that. And so imagine the situation where we got a couple of different things that have been in flight. People have been working on different...say there are three pull requests that are all coming to completion at the same time. Then you start to go to merge something, and you realize, oh no, somebody else just merged. So you rebase, and then you wait for CI to build. And just as the CI is completing, somebody else merges something, and you're like, ah, come on. And so then you have to one more time rebase, push, wait for the build to be green. So I get that that is not an ideal situation.

+ +

Right now, our team is three developers. So there are a few enough of us that I feel like this is okay. We can manage this via human intervention and just deal with the occasional weight. But in the back of my mind, of course, I want to find a better solution to this. So what I've been exploring…there's a handful of different utilities that I'm looking at, but they are basically merged queues as an idea. So there are three that I'm looking at, or maybe just two, but there's mergify.io, which is a hosted solution that does this sort of thing. And then Shopify has a merge queue implementation that they're running.

+ +

So the idea with this is when you as a developer are ready to merge something, you add a label to it. And when you add that label, there's some GitHub Action or otherwise some workflow in the background that sees that this has happened and now adds it to a merge queue. So it knows all of the different things that might want to be merged. And this is especially important as the team grows so that you don't get that contention. You can just say, "Yes, I would like my changes to go out into production." And so, when you label it, it then goes into this merge queue. And the background system is now going to take care of any necessary rebases. It's going to sequence them, so it's not just constantly churning all of the branches. It's waiting because it knows the order that they're ideally going to go out in.

+ +

If CI fails for any of them because rebasing suddenly, you're in an inconsistent state; if your build fails, then it will kick you out of the merge queue. It will let you know. So it will send you a notification in some manner and say, "Hey, hey, hey, you got to come look at this again. You've been kicked out of the merge queue. You're not going to production." But ideally, it adds that layer of automation to, frankly, this nuisance of having to keep things up to date and always wanting code to be run on CI and on a pull request before it gets into main. Then the ideal version is when it does actually merge your code, it pings you in Slack or something like that to say, "Hey, your changes just went out to production." Because the other thing I'm hoping for is a continuous deployment.

+ +

STEPH: The idea of a merge queue sounds really interesting. I've never worked with a process like that. And one of the benefits I can see is if I know I'm ready for something to go like if I'm waiting on a green build and I'm like, hey, as soon as this is green, I'd really like for it to get merged. Then currently, I'm checking in on it, so I will restart the build. And then, every so often, I'm going back to say, "Okay, are you green? Are you green? Can I emerge?" But if I have a merge queue, I can say, "Hey, merge queue, when this is green, please go and merge it for me." If I'm understanding the behavior correctly, that sounds really nifty.

+ +

CHRIS: I think that's a distinct but useful aspect of this is the idea that when you as a developer decide this PR is ready to go, you don't need to wait for either the current build or any subsequent builds. If there are rebases that need to happen, you basically say, "I think this code's good to go. We've gotten the necessary approvals. We've got the buy-in and the teams into this code." So cool, I now market as good. And you can walk away from it, and you will be notified either if it fails to get merged or if it successfully gets merged and deployed. So yes, that dream of like, you don't have to sit there watching the pot boil anymore.

+ +

STEPH: Yeah, that sounds nice. I do have to ask you a question. And this is related to one of the blog posts that you and I love deeply and reference fairly frequently. And it's the one that's written by German Velasco about Say No to More Process, and Say Yes to Trust. And I'm wondering, based on the pain that you felt from this new commit, going into main and breaking the main build, how do you feel about that balance of we spent time investigating this issue, and it may or may not happen again, and we're also looking into these new processes to avoid this from happening? I'm curious what your thought process is there because it seems like it's a fair amount of work to invest in the new process, but maybe that's justified based on the pain that you felt from having to fix the build previously.

+ +

CHRIS: Oh, I love the question. I love the subtle pushback here. I love this frame of mind. I really love that blog post. German writes incredible blog posts. And this is one that I just keep coming back to. In this particular case, when this situation occurred, we had a very brief...well, it wasn't even that brief because actually unwinding the situation was surprisingly painful, and we had some changes that we really wanted to get out, but now the build was broken. And so that churn and slowdown of our build pipeline and of our ability to actually get changes out to production was enough pain that we're like, okay, cool.

+ +

And then the other thing is we actually all were in agreement that this is the way we want things to work anyway, that idea that things should be rebased and tested on CI as part of a pull request. And then we're essentially only doing fast-forward merges on the main branch, or we're fast forward merging main into this new change. That's the workflow that we wanted. So this configuration was really just adding a little bit of software control to the thing that we wanted. So it was an existing process in our minds. This is the thing we were trying to do. It's just kind of hard to keep up with, frankly. But it turns out GitHub can manage it for us and enforce the process that we wanted. So it wasn't a new process per se. It was new automation to help us hold ourselves to the process that we had chosen.

+ +

And again, it's minimally painful for the team given the size that we're at now, but I am looking out to the future. And to be clear, this is one of the many things that fall on the list of; man, I would love to have some time to do this, but this is obviously not a priority right now. So I'm not allowed to do this. This is explicitly on the not allowed to touch list, but someday. I'm very excited about this because this does fundamentally introduce some additional work in the pipeline, and I don't want that.

+ +

Like you said, is this process worth it for the very small set of times that it's going to have a bad outcome? But in my mind, the better version, that down the road version where we have a merge queue, is actually a better version overall, even with just a tiny team of three developers that are maybe never even conflicting in our merges, except for this one standout time that happens once every three months or whatever. This is still nicer. I want to just be able to label a pull request and walk away and have it do the thing that we have decided as a team that we want. So that's the dream.

+ +

STEPH: Oh, I love that phrasing, to label a pull request and be able to walk away. Going back to our marketing, that really sells that merge queue to me. [laughs]

+ +

Mid-roll Ad

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city.

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

CHRIS: To be clear, and this is to borrow on some of Charity Majors' comments around continuous deployment and whatnot, is a developer should stay very close to the code if they are merging it. Because if we're doing continuous deployment, that's going to go out to production. If anything's going to happen, I want that individual to be aware. So ideally, there's another set of optimizations that I need to make on top of this. So we've got the merge queue, and that'll be great. Really excited about that.

+ +

But if we're going to lean into this, I want to optimize our CI pipeline and our deployment pipeline as much as possible such that even in the worst case where there's three different builds that are fighting for contention and trying to get out, the longest any developer might go between labeling a pull request and saying, "This is good to go," and it getting out to production, again, even if they're contending with other PRs, is say 10, 15 minutes, something like that.

+ +

I want Slack to notify them and them to then re-engage and keep an eye on things, see if any errors pop up, anything like that that they might need to respond to. Because they're the one that's got the context on the code at that point, and that context is decaying. The minute you've just merged a pull request and you're walking away from that code, the next day, you're like, what did I work on? I don't remember that at all. That code doesn't exist anymore in my brain. And so,,, staying close to that context is incredibly important.

+ +

So there's a handful of optimizations that I've looked at in terms of the CircleCI build. I've talked about my not rebuilding when it actually gets fast-forward merged because we've already done that build on the pull request. I'm being somewhat pointed in saying this has to build on a pull request. So if it did just build on a pull request, let's not rebuild it on main because it's identically the same commit. CircleCI, I'm looking at you. Give me a config button for that, please. I would really love that config button.

+ +

But there are a couple of other things that I've looked at. There's RSpec::Retry from NoRedInk, which will allow for some retry semantics. Because it will be really frustrating if your build breaks and you fall out of the merge queue. So let's try a little bit of retry logic on there, particularly around feature specs, because that's where this might happen.

+ +

There's Knapsack Pro which is a really interesting thing that I've looked at, which does parallelization of your RSpec test suite. But it does it in a different way than say Circle does. It actually runs a build queue, and each test gets sent over, and they have build agents on their side. And it's an interesting approach. I'm intrigued. I think it could use some nice speed-ups. There's esbuild on the Heroku side so that our assets build so much more quickly. There are lots of things. I want to make it very fast. But again, this is on the not allowed to do it list. [laughs]

+ +

STEPH: I love how most of the world has a to-do list, and you have this not-allowed to-do list that you're adding items to. And I'm really curious what all is on the not allowed to touch lists or not allowed to-do list. [laughs]

+ +

CHRIS: I think this might be inherent to being a developer is like when I see a problem, I want to fix it. I want to optimize it. I want to tweak it. I want to make it so that that never happens again. But plenty of things...coming back to German's post of Say No to More Process, some things shouldn't be fixed, or the cost of fixing is so much higher than the cost of just letting it happen again and dealing with it manually at that moment.

+ +

And so I think my inherent nature as a developer there's a voice in my head that is like, fix everything that's broken. And I'm like, sorry. Sorry, brain, I do not have that kind of time. And so I have to be really choosy about where the time goes. And this extends to the team as well. We need to be intentional around what we're building. Actually, there's a feeling that I've been feeling more acutely than ever, but it's the idea of this trade-off or optimization between speed and getting features out into the world and laying the right fundamentals. We're still very early on in this project, and I want to make sure we're thinking about things intentionally.

+ +

I've been on so many projects where it's many years after it started and when I ask someone, "Hey, why do your background jobs work that way? That's a little weird." And they're like, "Yeah, that was just a thing that happened, and then it never changed. And then, we copied it and duplicated, and that pattern just got reinforced deeply within the app. And at this point, it would cost too much to change." I've seen that thing play out so many times at so many different organizations that I'm overwhelmed with that knowledge in the back of my head. And I'm like, okay, I got to get it just right.

+ +

But I can't take the time that is necessary to get it, quote, unquote, "Just right." I do not have that kind of time. I got to ship some features. And this tension is sort of the name of the game. It's the thing I've been doing for my entire career. But now, given the role that I have with a very early-stage startup, I've never felt it more acutely. I've never had to be equally as concerned with both sides of that. Both matter all the more now than they ever have before, and so I'm kind of existing in that space.

+ +

STEPH: I really like that phrasing of that space because that deeply resonates with me as well. And that not allowed to-do list I have a similar list. For me, it's just called a wishlist. And so it's a wishlist that I will revisit every so often, but honestly, most things on there don't get done. And then I'll clear it out every so often when I feel it's not likely that I'm going to get to it. And then I'll just start fresh. So I also have a similar this is what I would like to do if I had the time.

+ +

And I agree that there's this inclination to automate as well. As soon as we have to do something that felt painful once, then we feel like, oh, we should automate it. And that's a conversation that I often have with myself is at what point is the cost of automation worthwhile versus should we just do this manually until we get to that point? So I love those nuanced conversations around when is the right time to invest further in this, and what is the impact? And what is the cost of it? And what are the trade-offs? And making that decision isn't always clear. And so I think that's why I really enjoy these conversations because it's not a clear rubric as to like, this is when you invest, and this is when you don't.

+ +

But I do feel like being a consultant has helped me hone those skills because I am jumping around to different teams, and I'm recognizing they didn't do this thing. Maybe they didn't address this or invest in it, and it's working for them. There are some oddities. Like you said, maybe I'll ask, "Why is this? It seems a little funky. What's the history?" And they'll be like, "Yeah, it was built in a hurry, but it works. And so there hasn't been any churn. We don't have any issues with it, so we have just left it." And that has helped reinforce the idea that just because something could be improved doesn't mean it's worthwhile to improve it.

+ +

Circling back to your original quest where you are looking to improve the process for merging and ensuring that CI stays green, I do like that you highlighted the fact that we do need to just be able to override settings. So that's something that has happened recently this week for me and my client work where we have had PRs that didn't have a green build because we have some flaky tests that we are actively working on. But we recognize that they're flaky, and we don't want that to block us. I'm still shipping work. So I really appreciate the consideration where we want to optimize so that everyone has an easy merging experience. We know things are green. It's trustworthy. But then we also have the ability to still say, "No, I am confident that I know what I'm doing here, and I want to merge it anyways, but thank you for the warning."

+ +

CHRIS: And the constant pendulum swing of over-correcting in various directions I've experienced that. And as you said, in the back of my mind, I'm like, oh, I know that this setting I'm going to need a way to turn this setting off. So I want to make sure that, most importantly, I'm not the only one on the team who can turn that off because the day that I am away on vacation and the build is broken, and we have a critical bug that we need to fix, somebody else needs to be able to do that. So that's sort of the story in my head.

+ +

At the same time, though, I've worked on so many teams where they're like, oh yeah, the build has been broken for seven weeks. We have a ticket in the backlog to fix that. And it's like, no, the build has to not be broken for that long. And so I agree with what you were saying of consulting has so usefully helped me hone where I fall on these various spectrums. But I do worry that I'm just constantly over-correcting in one direction or the other. I'm never actually at an optimum. I am just constantly whatever the most recent thing was, which is really impacting my thinking on this. And I try to not do that, but it's hard.

+ +

STEPH: Oh yeah. I'm totally biased towards my most recent experiences, and whatever has caused me the most pain or success recently. I'm definitely skewed in that direction.

+ +

CHRIS: Yeah, I definitely have the recency bias, and I try to have a holistic view of all of the things I've seen. There's actually a particular one that I don't want to pat myself on the back for because it's not a good thing. But currently, our test suite, when it runs, there's just a bunch of noise. There's a bunch of other stuff that gets printed out, like a bunch of it. And I'm reminded of a tweet from Kevin Newton, a friend of the show, and I just pulled it up here. "Oh, the lengths I will go to avoid warnings in my terminal, especially in the middle of my green dots. Don't touch my dots." It's a beautiful beauty. He actually has a handful about the green dots. And I feel this feel.

+ +

When I run my test suite, I just want a sea of green dots. That's all I want to see. But right now, our test suite is just noise. It's so much noise. And I am very proud of...I feel like this is a growth moment for me where I've been like, you know what? That is not the thing to fix today. We can deal with some noise amongst the green dots for now. Someday, I'm just going to lose it, and I'm going to fix it, and it's going to come back to green dots. [chuckles]

+ +

STEPH: That sounds like such a wonderful children's book or Dr. Seuss. Oh, the importance of green dots or, oh, the places green dots will take you.

+ +

CHRIS: Don't touch my dots. [laughter]

+ +

STEPH: Okay. Maybe a slightly aggressive Dr. Seuss, but I still really like it.

+ +

CHRIS: A little more, yeah.

+ +

STEPH: On that note of our love of green dots, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Longtime listener and friend of the show, Gio Lodi, released a book y'all should check out and Chris and Steph ruminate on a listener question about tension around marketing in open-source.

+ + + +

Transcript:

+ +

CHRIS: Our golden roads.

+ +

STEPH: All right. I am also golden.

+ +

CHRIS: [vocalization]

+ +

STEPH: Oh, I haven't listened to that episode where I just broke out in song in the middle. Oh, you're about to add the [vocalization] [chuckles].

+ +

CHRIS: I don't know why, though. Oh, golden roads, Golden Arches.

+ +

STEPH: Golden Arches, yeah.

+ +

CHRIS: Man, I did not know that my brain was doing that, but my brain definitely connected those without telling me about it.

+ +

STEPH: [laughs]

+ +

CHRIS: It's weird. People talk often about the theory that phones are listening, and then you get targeted ads based on what you said. But I'm almost certain it's actually the algorithms have figured out how to do the same intuitive leaps that your brain does. And so you'll smell something and not make the nine steps in between, but your brain will start singing a song from your childhood. And you're like, what is going on? Oh, right, because when I was watching Jurassic Park that one time, we were eating this type of chicken, and therefore when I smell paprika, Jurassic Park theme song. I got it, of course.

+ +

STEPH: [laughs]

+ +

CHRIS: And I think that's actually what's happening with the phones. That's my guess is that you went to a site, and the phones are like, cool, I got it, adjacent to that is this other thing, totally. Because I don't think the phones are listening. Occasionally, I think the phones are listening, but mostly, I don't think the phones are listening.

+ +

STEPH: I definitely think the phones are listening.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey. So we have a bit of exciting news where we received an email from Gio Lodi, who is a listener of The Bike Shed. And Gio sent an email sharing with us some really exciting news that they have published a book on Test-Driven Development in Swift. And they acknowledge us in the acknowledgments of the book. Specifically, the acknowledgment says, "I also want to thank Chris Toomey and Steph Viccari, who keep sharing ideas on testing week after week on The Bike Shed Podcast." And that's just incredible. I'm so blown away, and I feel officially very famous.

+ +

CHRIS: This is how you know you're famous when you're in the acknowledgments of a book. But yeah, Gio is a longtime listener and friend of the show. He's written in many times and given us great tips, and pointers, and questions, and things. And I’ve so appreciated Gio’s voice in the community. And it's so wonderful, frankly, to hear that he has gotten value out of the show and us talking about testing. Because I always feel like I'm just regurgitating things that I've heard other people saying about testing and maybe one or two hard-learned truths that I've found. But it's really wonderful. And thank you so much, Gio. And best of luck for anyone out there who is doing Swift development and cares about testing or test-driven development, which I really think everybody should. Go check out that book.

+ +

STEPH: I must admit my Swift skills are incredibly rusty, really non-existent at this point. It's been so long since I've been in that world. But I went ahead and purchased a copy just because I think it's really cool. And I suspect there are a lot of testing conversations that, regardless of the specific code examples, still translate. At least, that's the goal that you and I have when we're having these testing conversations. Even if they're not specific to a language, we can still talk about testing paradigms and strategies. So I purchased a copy. I'm really looking forward to reading it.

+ +

And just to change things up a bit, we're going to start off with a listener question today. So this listener question comes from someone very close to the show. It comes from Thom Obarski. Hi, Thom. And Thom wrote in, "So I heard on a recent podcast I was editing some tension around marketing and open source. Specifically, a little perturbed at ReactJS that not only were people still dependent on a handful of big companies for their frameworks, but they also seem to be implying that the cachet of Facebook and having developer mindshare was not allowing smaller but potentially better solutions to shine through. In your opinion, how much does marketing play in the success of an open-source project framework rather than actually being the best tool for the job?" So a really thoughtful question. Thanks, Thom. Chris, I'm going to kick it over to you. What are your thoughts about this question?

+ +

CHRIS: Yeah, this is a super interesting one. And thank you so much, Thom, although I'm not sure that you're listening at this point. But we'll send you a note that we are replying to your question. And when I saw this one come through, it was interesting. I really love the kernel of the discussion here, but it is, again, very difficult to tease apart the bits. I think that the way the question was framed is like, oh, there's this bad thing that it's this big company that has this big name, and they're getting by on that. But really, there are these other great frameworks that exist, and they should get more of the mindshare.

+ +

And honestly, I'm not sure. I think marketing is a critically important aspect of the work that we do both in open source and, frankly, everywhere. And I'm going to clarify what I mean by that because I think it can take different shapes. But in terms of open-source, Facebook has poured a ton of energy and effort and, frankly, work into React as a framework. And they're also battle testing it on facebook.com, a giant website that gets tons of traffic, that sees various use cases, that has all permissions in there. They're really putting it through the wringer in that way.

+ +

And so there is a ton of value just in terms of this large organization working on and using this framework in the same way that GitHub and using Rails is a thing that is deeply valuable to us as a community. So I think having a large organization associated with something can actually be deeply valuable in terms of what it produces as an outcome for us as consumers of that open-source framework.

+ +

I think the other idea of sort of the meritocracy of the better framework should win out is, I don't know, it's like a Field of Dreams. Like, if you build it, they will come. It turns out I don't believe that that's actually true. And I think selling is a critical part of everything. And so if I think back to DHH's original video from so many years ago of like, I'm going to make a blog in 15 minutes; look at how much I'm not doing. That was a fantastic sales pitch for this new framework. And he was able to gain a ton of attention by virtue of making this really great sales pitch that sold on the merits of it. But that was marketing. He did the work of marketing there.

+ +

And I actually think about it in terms of a pull request. So I'm in a small organization. We're in a private repo. There's still marketing. There's still sales to be done there. I have to communicate to someone else the changes that I'm making, why it's valuable to the system, why they should support this change, this code coming into the codebase. And so I think that sort of communication is as critical to the whole conversation. And so the same thing happens at the level of open source.

+ +

I would love for the best framework to always win, but we also need large communities with Stack Overflow answers and community-supported plugins and things like that. And so it's a really difficult thing to treat marketing as just other, this different, separate thing when, in fact, I think they're all intertwined. And marketing is critically important, and having a giant organization behind something can actually have negative aspects. But I think overall; it really is useful in a lot of cases. Those are some initial thoughts. What do you think, Steph?

+ +

STEPH: Yeah, those are some great initial thoughts. I really agree with what you said. And I also like how you brought in the comparison of pull requests and how sales is still part of our job as developers, maybe not in the more traditional sense but in the way that we are marketing and communicating with the team. And circling back to what you were saying earlier about a bit how this is phrased, I think I typically agree that there's nothing nefarious that's afoot in regards to just because a larger company is sponsoring an open-source project or they are the ones responsible for it, I don't think there's anything necessarily bad about that.

+ +

And I agree with the other points that you made where it is helpful that these teams have essentially cultivated a framework or a project that is working for their team, that is helping their company, and then they have decided to open source it. And then, they have the time and energy that they can continue to invest in that project. And it is battle-tested because they are using it for their own projects as well. So it seems pretty natural that a lot of us then would gravitate towards these larger, more heavily supported projects and frameworks. Because then that's going to make our job easier and also give us more trust that we can turn to them when we do need help or have issues.

+ +

Or, like you mentioned, when we need to look up documentation, we know that that's going to be there versus some of the other smaller projects. They may also be wonderful projects. But if they are someone that's doing this in their spare time just on the weekends and yet I'm looking for something that I need to be incredibly reliable, then it probably makes sense for me to go with something that is supported by a team that's getting essentially paid to work on that project, at least that they're backed by a larger company. Versus if I'm going with a smaller project where someone is doing some wonderful work, but realistically, they're also doing it more on the weekends or in their spare time. So boiling it down, it’s similar to what you just said where marketing plays a very big part in open source, and the projects and frameworks that we adopt, and the things that we use. And I don't think that's necessarily a bad thing.

+ +

CHRIS: Yeah. I think, if anything, it's possibly a double-edged sword. Part of the question was around does React get to benefit just by the cachet of Facebook? But Facebook, as a larger organization sometimes that's a positive thing. Sometimes there's ire that is directed at Facebook as an organization.

+ +

And as a similar example, my experience with Google and Microsoft as large organizations, particularly backing open-source efforts, has almost sort of swapped over time, where originally, Microsoft there was almost nothing of Microsoft's open-source efforts that I was using. And I saw them as this very different shape of a company that I probably wouldn't be that interested in. And then they have deeply invested in things like GitHub, and VS Code, and TypeScript, and tons of projects that suddenly I'm like, oh, actually, a lot of what I use in the world is coming from Microsoft. That's really interesting.

+ +

And at the same time, Google has kind of gone in the opposite direction for me. And I've seen some of their movements switch from like, oh Google the underdog to now they're such a large company. And so the idea that the cachet, as the question phrase, of a company is just this uniformly positive thing and that it's perhaps an unfair benefit I don't see that as actually true.

+ +

But actually, as a more pointed example of this, I recently chose Svelte over React, and that was a conscious choice. And I went back and forth on it a few times, if we're being honest, because Svelte is a much smaller community. It does not have the large organizational backing that React or other frameworks do. And there was a certain marketing effort that was necessary to raise it into my visibility and then for me to be convinced that there is enough there, that there is a team that will maintain it, and that there are reasons to choose that and continue with it. And I've been very happy with it as a choice.

+ +

But I was very conscious in that choice that I'm choosing something that doesn't have that large organizational backing. Because there's a nicety there of like, I trust that Facebook will probably keep investing in React because it is the fundamental technology of the front end of their platform. So yeah, it's not going to go anywhere. But I made the choice of going with Svelte. So it's an example of where the large organization didn't win out in my particular case. So I think marketing is a part of the work, a part of the conversation. It's part of communication. And so I am less negative on it, I think, than the question perhaps was framed, but as always, it depends.

+ +

STEPH: Yeah, I'm trying to think of a scenario where I would be concerned about the fact that I'm using open source that's backed by a specific large company or corporation. And the main scenario I can think of is what happens when you conflict or if you have values that conflict with a company that is sponsoring that project? So if you are using an open-source project, but then the main community or the company that then works on that project does something that you really disagree with, then what do you do? How do you feel about that situation? Do you continue to use that open-source project? Do you try to use a different open-source project?

+ +

And I had that conversation frankly with myself recently, thinking through what to do in that situation and how to view it. And I realize this may not be how everybody views it, and it's not appropriate for all situations. But I do typically look at open-source projects as more than who they are backed by, but the community that's actively working on that project and who it benefits. So even if there is one particular group that is doing something that I don't agree with, that doesn't necessarily mean that wholesale I no longer want to be a part of this community. It just means that I still want to be a part, but I still want to share my concerns that I think a part of our community is going in a direction that I don't agree with or I don't think is a good direction.

+ +

That's, I guess, how I reason with myself; even if an open-source project is backed by someone that I don't agree with, either one, you can walk away. That seems very complicated, depending on your dependencies. Or two, you find ways to then push back on those values if you feel that the community is headed in a direction that you don't agree with. And that all depends on how comfortable you are and how much power you feel like you have in that situation to express your opinion. So it's a complicated space.

+ +

CHRIS: Yeah, that is a super subtle edge case of all of this. And I think I aligned with what you said of trying to view an open-source project as more generally the community that's behind it as opposed to even if there's a strong, singular organization behind it. But that said, that's definitely a part of it. And again, it's a double-edged sword. It's not just, oh, giant company; this is great. That giant company now has to consider this.

+ +

And I think in the case of Facebook and React, that is a wonderful hiring channel for them. Now all the people that use React anywhere are like, "Oh man, I could go work at Facebook on React? That's exciting." That's a thing that's a marketing tool from a hiring perspective for them. But it cuts both ways because suddenly, if the mindshare moves in a different direction, or if Facebook as an organization does something complicated, then React as a community can start to shift away. Maybe you don't move the current project off of it, but perhaps you don't start the next one with it. And so, there are trade-offs and considerations in all directions. And again, it depends.

+ +

STEPH: Yeah. I think overall, the thing that doesn't depend is marketing matters. It is a real part of the ecosystem, and it will influence our decisions. And so, just circling back to Thom's question, I think it does play a vital role in the choices that we make.

+ +

CHRIS: Way to stick the landing.

+ +

STEPH: Thanks.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Changing topics just a bit, what's new in your world?

+ +

CHRIS: Well, we had what I would call a mini perfect storm this week. We broke the build but in a pretty solid way. And it was a little bit difficult to get it back under control. And it has pushed me ever so slightly forward in my desire to have a fully optimized CI and deploy pipeline. Mostly, I mean that in terms of ratcheting. I'm not actually going to do anything beyond a very small set of configurations.

+ +

But to describe the context, we use pull requests because that's the way that we communicate. We do code reviews, all that fun stuff. And so there was a particular branch that had a good amount of changes, and then something got merged. And this other pull request was approved. And that person then clicked the rebase and merge button, which I have configured the repository, so that merge commits are not allowed because I'm not interested in that malarkey in our history. But merge commits or rebase and merge. I like that that makes sense.

+ +

In this particular case, we ran into the very small, subtle edge case of if you click the rebase and merge button, GitHub is now producing a new commit that did not exist before, a new version of the code. So they're taking your changes, and they are rebasing them onto the current main branch. And then they're attempting to merge that in. And A, that was allowed. B, the CI configuration did not require that to be in a passing state. And so basically, in doing that rebase and merge, it produced an artifact in the build that made it fail. And then attempting to unwind that was very complicated.

+ +

So basically, the rebase produced...there were duplicate changes within a given file. So Git didn't see it as a conflict because the change was made in two different parts of the file, but those were conflicting changes. So Git was like, this seems like it's fine. I can merge this, no problem. But it turns out from a functional perspective; it did not work. The build failed. And so now our main branch was failing and then trying to unwind that it just was surprisingly difficult to unwind that. And it really highlighted the importance of keeping the main branch green, keeping the build always passing. And so, I configured a few things in response to this. There is a branch protection rule that you can enable.

+ +

And let me actually pull up the specific configuration that I set up. So I now have enabled require status checks to pass before merging, which, if we're being honest, I thought that was the default. It turns out it was not the default. So we are now requiring status checks to pass before merging. I'm fully aware of the awkward, painful like, oh no, the build is failing but also, we have a bug. We need to deploy this. We must get something merged in.

+ +

So hopefully, if and when that situation presents itself, I will turn this off or somehow otherwise work around it. But for now, I would prefer to have this as a yeah; this is definitely a configuration we want. So require status checks to pass before merging and then require branches to be up to date before merging. So the button that does the rebase and merge, I don't want that to actually do a rebase on GitHub. I want the branch to already be up to date. Basically, I only ever want fast-forward merges on our main branch. So all code should be ahead of main, and we are simply updating what main points at. We are not creating new code. That code has run on CI, that version of the code specifically. We are fully rebased and up to date on top of main, and that's how we're going.

+ +

STEPH: All of that is super interesting. I have a question about the workflow. I want to make sure I'm understanding it correctly. So let's say that I have issued a PR, and then someone else has merged into the main branch. So now my PR is behind me, and I don't have that latest commit. With the new configuration, can I still use the rebase and merge, or will I need to rebase locally and then push up my branch before I can merge into main but at least using the GitHub UI?

+ +

CHRIS: I believe that you would be forced to rebase locally, force push, and then CI would rebuild, and that's what it is. So I think that's what require branches to be up to date before merging means. So that's my hope. That is the intention here. I do realize that's complicated. So this requirement, which I like, because again, I really want the idea that no, no, no, we, the developers, are in charge of that final state. That final state should always run as part of a build of CI on our pull request/branch before going into main. So no code should be new. There should be no new commits that have never been tested before going into main. That's my strong belief. I want that world. I realize that's...I don't know. Maybe I'm getting pedantic, or I'm a micromanager of the Git history or whatever. I'm fine with any of those insults that people want to lob at me. That's fine. But that's what I feel.

+ +

That said, this is a nuisance. I'm fully aware of that. And so imagine the situation where we got a couple of different things that have been in flight. People have been working on different...say there are three pull requests that are all coming to completion at the same time. Then you start to go to merge something, and you realize, oh no, somebody else just merged. So you rebase, and then you wait for CI to build. And just as the CI is completing, somebody else merges something, and you're like, ah, come on. And so then you have to one more time rebase, push, wait for the build to be green. So I get that that is not an ideal situation.

+ +

Right now, our team is three developers. So there are a few enough of us that I feel like this is okay. We can manage this via human intervention and just deal with the occasional weight. But in the back of my mind, of course, I want to find a better solution to this. So what I've been exploring…there's a handful of different utilities that I'm looking at, but they are basically merged queues as an idea. So there are three that I'm looking at, or maybe just two, but there's mergify.io, which is a hosted solution that does this sort of thing. And then Shopify has a merge queue implementation that they're running.

+ +

So the idea with this is when you as a developer are ready to merge something, you add a label to it. And when you add that label, there's some GitHub Action or otherwise some workflow in the background that sees that this has happened and now adds it to a merge queue. So it knows all of the different things that might want to be merged. And this is especially important as the team grows so that you don't get that contention. You can just say, "Yes, I would like my changes to go out into production." And so, when you label it, it then goes into this merge queue. And the background system is now going to take care of any necessary rebases. It's going to sequence them, so it's not just constantly churning all of the branches. It's waiting because it knows the order that they're ideally going to go out in.

+ +

If CI fails for any of them because rebasing suddenly, you're in an inconsistent state; if your build fails, then it will kick you out of the merge queue. It will let you know. So it will send you a notification in some manner and say, "Hey, hey, hey, you got to come look at this again. You've been kicked out of the merge queue. You're not going to production." But ideally, it adds that layer of automation to, frankly, this nuisance of having to keep things up to date and always wanting code to be run on CI and on a pull request before it gets into main. Then the ideal version is when it does actually merge your code, it pings you in Slack or something like that to say, "Hey, your changes just went out to production." Because the other thing I'm hoping for is a continuous deployment.

+ +

STEPH: The idea of a merge queue sounds really interesting. I've never worked with a process like that. And one of the benefits I can see is if I know I'm ready for something to go like if I'm waiting on a green build and I'm like, hey, as soon as this is green, I'd really like for it to get merged. Then currently, I'm checking in on it, so I will restart the build. And then, every so often, I'm going back to say, "Okay, are you green? Are you green? Can I emerge?" But if I have a merge queue, I can say, "Hey, merge queue, when this is green, please go and merge it for me." If I'm understanding the behavior correctly, that sounds really nifty.

+ +

CHRIS: I think that's a distinct but useful aspect of this is the idea that when you as a developer decide this PR is ready to go, you don't need to wait for either the current build or any subsequent builds. If there are rebases that need to happen, you basically say, "I think this code's good to go. We've gotten the necessary approvals. We've got the buy-in and the teams into this code." So cool, I now market as good. And you can walk away from it, and you will be notified either if it fails to get merged or if it successfully gets merged and deployed. So yes, that dream of like, you don't have to sit there watching the pot boil anymore.

+ +

STEPH: Yeah, that sounds nice. I do have to ask you a question. And this is related to one of the blog posts that you and I love deeply and reference fairly frequently. And it's the one that's written by German Velasco about Say No to More Process, and Say Yes to Trust. And I'm wondering, based on the pain that you felt from this new commit, going into main and breaking the main build, how do you feel about that balance of we spent time investigating this issue, and it may or may not happen again, and we're also looking into these new processes to avoid this from happening? I'm curious what your thought process is there because it seems like it's a fair amount of work to invest in the new process, but maybe that's justified based on the pain that you felt from having to fix the build previously.

+ +

CHRIS: Oh, I love the question. I love the subtle pushback here. I love this frame of mind. I really love that blog post. German writes incredible blog posts. And this is one that I just keep coming back to. In this particular case, when this situation occurred, we had a very brief...well, it wasn't even that brief because actually unwinding the situation was surprisingly painful, and we had some changes that we really wanted to get out, but now the build was broken. And so that churn and slowdown of our build pipeline and of our ability to actually get changes out to production was enough pain that we're like, okay, cool.

+ +

And then the other thing is we actually all were in agreement that this is the way we want things to work anyway, that idea that things should be rebased and tested on CI as part of a pull request. And then we're essentially only doing fast-forward merges on the main branch, or we're fast forward merging main into this new change. That's the workflow that we wanted. So this configuration was really just adding a little bit of software control to the thing that we wanted. So it was an existing process in our minds. This is the thing we were trying to do. It's just kind of hard to keep up with, frankly. But it turns out GitHub can manage it for us and enforce the process that we wanted. So it wasn't a new process per se. It was new automation to help us hold ourselves to the process that we had chosen.

+ +

And again, it's minimally painful for the team given the size that we're at now, but I am looking out to the future. And to be clear, this is one of the many things that fall on the list of; man, I would love to have some time to do this, but this is obviously not a priority right now. So I'm not allowed to do this. This is explicitly on the not allowed to touch list, but someday. I'm very excited about this because this does fundamentally introduce some additional work in the pipeline, and I don't want that.

+ +

Like you said, is this process worth it for the very small set of times that it's going to have a bad outcome? But in my mind, the better version, that down the road version where we have a merge queue, is actually a better version overall, even with just a tiny team of three developers that are maybe never even conflicting in our merges, except for this one standout time that happens once every three months or whatever. This is still nicer. I want to just be able to label a pull request and walk away and have it do the thing that we have decided as a team that we want. So that's the dream.

+ +

STEPH: Oh, I love that phrasing, to label a pull request and be able to walk away. Going back to our marketing, that really sells that merge queue to me. [laughs]

+ +

Mid-roll Ad

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city.

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

CHRIS: To be clear, and this is to borrow on some of Charity Majors' comments around continuous deployment and whatnot, is a developer should stay very close to the code if they are merging it. Because if we're doing continuous deployment, that's going to go out to production. If anything's going to happen, I want that individual to be aware. So ideally, there's another set of optimizations that I need to make on top of this. So we've got the merge queue, and that'll be great. Really excited about that.

+ +

But if we're going to lean into this, I want to optimize our CI pipeline and our deployment pipeline as much as possible such that even in the worst case where there's three different builds that are fighting for contention and trying to get out, the longest any developer might go between labeling a pull request and saying, "This is good to go," and it getting out to production, again, even if they're contending with other PRs, is say 10, 15 minutes, something like that.

+ +

I want Slack to notify them and them to then re-engage and keep an eye on things, see if any errors pop up, anything like that that they might need to respond to. Because they're the one that's got the context on the code at that point, and that context is decaying. The minute you've just merged a pull request and you're walking away from that code, the next day, you're like, what did I work on? I don't remember that at all. That code doesn't exist anymore in my brain. And so,,, staying close to that context is incredibly important.

+ +

So there's a handful of optimizations that I've looked at in terms of the CircleCI build. I've talked about my not rebuilding when it actually gets fast-forward merged because we've already done that build on the pull request. I'm being somewhat pointed in saying this has to build on a pull request. So if it did just build on a pull request, let's not rebuild it on main because it's identically the same commit. CircleCI, I'm looking at you. Give me a config button for that, please. I would really love that config button.

+ +

But there are a couple of other things that I've looked at. There's RSpec::Retry from NoRedInk, which will allow for some retry semantics. Because it will be really frustrating if your build breaks and you fall out of the merge queue. So let's try a little bit of retry logic on there, particularly around feature specs, because that's where this might happen.

+ +

There's Knapsack Pro which is a really interesting thing that I've looked at, which does parallelization of your RSpec test suite. But it does it in a different way than say Circle does. It actually runs a build queue, and each test gets sent over, and they have build agents on their side. And it's an interesting approach. I'm intrigued. I think it could use some nice speed-ups. There's esbuild on the Heroku side so that our assets build so much more quickly. There are lots of things. I want to make it very fast. But again, this is on the not allowed to do it list. [laughs]

+ +

STEPH: I love how most of the world has a to-do list, and you have this not-allowed to-do list that you're adding items to. And I'm really curious what all is on the not allowed to touch lists or not allowed to-do list. [laughs]

+ +

CHRIS: I think this might be inherent to being a developer is like when I see a problem, I want to fix it. I want to optimize it. I want to tweak it. I want to make it so that that never happens again. But plenty of things...coming back to German's post of Say No to More Process, some things shouldn't be fixed, or the cost of fixing is so much higher than the cost of just letting it happen again and dealing with it manually at that moment.

+ +

And so I think my inherent nature as a developer there's a voice in my head that is like, fix everything that's broken. And I'm like, sorry. Sorry, brain, I do not have that kind of time. And so I have to be really choosy about where the time goes. And this extends to the team as well. We need to be intentional around what we're building. Actually, there's a feeling that I've been feeling more acutely than ever, but it's the idea of this trade-off or optimization between speed and getting features out into the world and laying the right fundamentals. We're still very early on in this project, and I want to make sure we're thinking about things intentionally.

+ +

I've been on so many projects where it's many years after it started and when I ask someone, "Hey, why do your background jobs work that way? That's a little weird." And they're like, "Yeah, that was just a thing that happened, and then it never changed. And then, we copied it and duplicated, and that pattern just got reinforced deeply within the app. And at this point, it would cost too much to change." I've seen that thing play out so many times at so many different organizations that I'm overwhelmed with that knowledge in the back of my head. And I'm like, okay, I got to get it just right.

+ +

But I can't take the time that is necessary to get it, quote, unquote, "Just right." I do not have that kind of time. I got to ship some features. And this tension is sort of the name of the game. It's the thing I've been doing for my entire career. But now, given the role that I have with a very early-stage startup, I've never felt it more acutely. I've never had to be equally as concerned with both sides of that. Both matter all the more now than they ever have before, and so I'm kind of existing in that space.

+ +

STEPH: I really like that phrasing of that space because that deeply resonates with me as well. And that not allowed to-do list I have a similar list. For me, it's just called a wishlist. And so it's a wishlist that I will revisit every so often, but honestly, most things on there don't get done. And then I'll clear it out every so often when I feel it's not likely that I'm going to get to it. And then I'll just start fresh. So I also have a similar this is what I would like to do if I had the time.

+ +

And I agree that there's this inclination to automate as well. As soon as we have to do something that felt painful once, then we feel like, oh, we should automate it. And that's a conversation that I often have with myself is at what point is the cost of automation worthwhile versus should we just do this manually until we get to that point? So I love those nuanced conversations around when is the right time to invest further in this, and what is the impact? And what is the cost of it? And what are the trade-offs? And making that decision isn't always clear. And so I think that's why I really enjoy these conversations because it's not a clear rubric as to like, this is when you invest, and this is when you don't.

+ +

But I do feel like being a consultant has helped me hone those skills because I am jumping around to different teams, and I'm recognizing they didn't do this thing. Maybe they didn't address this or invest in it, and it's working for them. There are some oddities. Like you said, maybe I'll ask, "Why is this? It seems a little funky. What's the history?" And they'll be like, "Yeah, it was built in a hurry, but it works. And so there hasn't been any churn. We don't have any issues with it, so we have just left it." And that has helped reinforce the idea that just because something could be improved doesn't mean it's worthwhile to improve it.

+ +

Circling back to your original quest where you are looking to improve the process for merging and ensuring that CI stays green, I do like that you highlighted the fact that we do need to just be able to override settings. So that's something that has happened recently this week for me and my client work where we have had PRs that didn't have a green build because we have some flaky tests that we are actively working on. But we recognize that they're flaky, and we don't want that to block us. I'm still shipping work. So I really appreciate the consideration where we want to optimize so that everyone has an easy merging experience. We know things are green. It's trustworthy. But then we also have the ability to still say, "No, I am confident that I know what I'm doing here, and I want to merge it anyways, but thank you for the warning."

+ +

CHRIS: And the constant pendulum swing of over-correcting in various directions I've experienced that. And as you said, in the back of my mind, I'm like, oh, I know that this setting I'm going to need a way to turn this setting off. So I want to make sure that, most importantly, I'm not the only one on the team who can turn that off because the day that I am away on vacation and the build is broken, and we have a critical bug that we need to fix, somebody else needs to be able to do that. So that's sort of the story in my head.

+ +

At the same time, though, I've worked on so many teams where they're like, oh yeah, the build has been broken for seven weeks. We have a ticket in the backlog to fix that. And it's like, no, the build has to not be broken for that long. And so I agree with what you were saying of consulting has so usefully helped me hone where I fall on these various spectrums. But I do worry that I'm just constantly over-correcting in one direction or the other. I'm never actually at an optimum. I am just constantly whatever the most recent thing was, which is really impacting my thinking on this. And I try to not do that, but it's hard.

+ +

STEPH: Oh yeah. I'm totally biased towards my most recent experiences, and whatever has caused me the most pain or success recently. I'm definitely skewed in that direction.

+ +

CHRIS: Yeah, I definitely have the recency bias, and I try to have a holistic view of all of the things I've seen. There's actually a particular one that I don't want to pat myself on the back for because it's not a good thing. But currently, our test suite, when it runs, there's just a bunch of noise. There's a bunch of other stuff that gets printed out, like a bunch of it. And I'm reminded of a tweet from Kevin Newton, a friend of the show, and I just pulled it up here. "Oh, the lengths I will go to avoid warnings in my terminal, especially in the middle of my green dots. Don't touch my dots." It's a beautiful beauty. He actually has a handful about the green dots. And I feel this feel.

+ +

When I run my test suite, I just want a sea of green dots. That's all I want to see. But right now, our test suite is just noise. It's so much noise. And I am very proud of...I feel like this is a growth moment for me where I've been like, you know what? That is not the thing to fix today. We can deal with some noise amongst the green dots for now. Someday, I'm just going to lose it, and I'm going to fix it, and it's going to come back to green dots. [chuckles]

+ +

STEPH: That sounds like such a wonderful children's book or Dr. Seuss. Oh, the importance of green dots or, oh, the places green dots will take you.

+ +

CHRIS: Don't touch my dots. [laughter]

+ +

STEPH: Okay. Maybe a slightly aggressive Dr. Seuss, but I still really like it.

+ +

CHRIS: A little more, yeah.

+ +

STEPH: On that note of our love of green dots, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+g6lRe2M- + + ]]> + + Chris Toomey + Steph Viccari + + + 310: Schedule Shut Down, Complete + https://bikeshed.thoughtbot.com/310 + 9cac62ea-5a6a-4c9e-b059-58cbf7632521 + Tue, 28 Sep 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris talks feature flags featuring Flipper (Say *that* 3x fast!), and Steph talks reducing stress by a) having a work shutdown ritual and b) the fact that thoughtbot is experimenting with half-day Fridays. (Fri-yay?) + + 39:16 + no + + Chris talks feature flags featuring Flipper (Say that 3x fast!), and Steph talks reducing stress by a) having a work shutdown ritual and b) the fact that thoughtbot is experimenting with half-day Fridays. (Fri-yay?) +Flipper (https://featureflags.io/2016/04/08/flipper-a-feature-flipper-feature-toggle-library/) +Drastically Reduce Stress with a Work Shutdown Ritual (https://www.calnewport.com/blog/2009/06/08/drastically-reduce-stress-with-a-work-shutdown-ritual/) +Iceland's Journey to a Short Working Week (https://autonomy.work/wp-content/uploads/2021/06/ICELAND_4DW.pdf) +Burnout: The Secret to Unlocking the Stress Cycle (https://www.burnoutbook.net/) +Transcript: +STEPH: Hey, do you know that we could have an in-person recording at the end of October? +CHRIS: I do. Yes, I'm planning. That is in the back of my head. I guess I hadn't said that to you yet. But I'm glad that we have separately had the same conversation, and we've got to figure that out, although I don't know how to do noise cancellation and whatnot in the room. [laughs] How do we...we'll have to figure it out. Like, put a blanket in between us but so that we can see across it, but it absorbs sound in the middle. It's weird. I don't know how to do stuff. Just thinking out loud here. +STEPH: We'll just be in the same place but still different rooms. So it'll feel no different. +[laughter] +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world? +CHRIS: Feature flags. Feature flags are an old favorite, but they have become new again in the application that I'm working on. We had a new feature that we were building out. But we assumed correctly that it would be nice to be able to break it apart into smaller pieces and sort of deliver it incrementally but not necessarily want to expose that to our end users. And so, we opted with that ticket to bring along the feature flag system. +So we've introduced Flipper, in particular, which is a wonderful gem; it does the job. We're using the ActiveRecord adapter. All that kind of makes sense, happy about that. And so now we have feature flags. But it was one of those mindset shifts where the minute we got feature flags, I was like, yes, okay, everything behind a feature flag. And we've been leaning into that more and more, and it really is so nice and so freeing, and so absolutely loving it so far. +STEPH: I'm intrigued. You said, "Everything behind a feature flag." Like, is it really everything or? Yeah, tell me more. +CHRIS: Not everything. But at this point, we're still very early on in this application, so there are fundamental facets of the platform, different areas of what users can do. And so the actual stuff that works and is wired up is pretty minimal, but we want to have a little more surface area built out in the app for demo purposes, for conversations that are happening, et cetera. +And so, we built out a bunch of new pages to represent functionality. And so there are sidebar links, and then the actual page itself, and routing, and all of the things that are associated with that, and so all of those have come in. I think there are five new top-level nav sections of the platform that are all introduced behind a feature flag right now. And then there's some new functionality within existing pages that we've put behind feature flags. So it's not truly every line of code, but it's basically the entry point to all new major features we're putting behind a feature flag. +STEPH: Okay, cool. I'm curious. How are you finding that in terms of does it feel manageable? Do you feel like anybody can go into the UI and then turn on feature flags for demos and feel confident that they know what they're turning on and off? +CHRIS: We haven't gotten to that self-serve place. At this point, the dev team is managing the feature flags. So on production, we have an internal group configured within Flipper. So we can say, "Ship this feature for all internal users so that we can do testing." So there is a handful of us that all have accounts on production. And then on staging, we have a couple of representative users that we've been just turning everything on for so that we know via staging we can act as that user and then see the application with all of the bells and whistles. +Down the road, I think we're going to get more intentional with it, particularly the idea of a demo account. That's something that we want to lean into. And for that user, we'll probably be turning on certain subsets of the feature flags. I think we'll get a little more granular in how we think about that. For now, we're not as detailed in it, but I think that is something that we want to expand as we move forward. +STEPH: Nice. Yeah, I was curious because feature flags came up in our recent retro with the client team because we've gotten to a point where our feature flags feel complex enough that it's becoming challenging and not just from the complexity of the feature flags but also from the UI perspective. Where it feels challenging for users to understand how to turn a feature on, exactly what that impacts, and making sure that then they're not changing developer-focused feature flags, so those are the feature flags that we're using to ship a change but then not turn it on until we're ready. It is user-facing, but it's something that should be managed more by developers as to when we turn it on or off. So I was curious to hear that's going for you because that's something that we are looking into. +And funnily enough, you asked me recently, "Why aren't y'all using Flipper?" And I didn't have a great answer for you. And that question came up again where we looked at each other, and we're like, okay, we know there was a really good reason we didn't use Flipper when we first had this discussion. But none of us can remember, or at least the people in that conversation couldn't remember. So now we're asking ourselves the question of we've made it this far. Is it time to bring in Flipper or another service? Because we're getting to the point that we're starting to build too much of our own feature flag system. +CHRIS: So did you uncover an answer, or are you all just agreeing that the question makes sense? +STEPH: Agreeing that the question makes sense. [laughs] +CHRIS: That's the first step on a long journey to switching from internal tooling to somebody else managing that for you. +STEPH: Yeah, because none of us could remember exactly. But it was funny because I was like, am I just forgetting something here when you asked me that? So I felt validated that others were like, "Oh yeah, I remember that conversation. But I too can't recall why we didn't want to use Flipper in the moment or a similar service." +CHRIS: I'll definitely be interested to hear if you do end up trying to migrate off to another system or find a different approach there or if you do stick with the current configuration that you have. Because those projects they're the sort of sneaky ones that it's like, oh, we've been actually relying on this for a while. It's a core part of our infrastructure, and how we do the work, and the process, and how we deploy. That's a lot. And so, to switch that out in-flight becomes really difficult. It's one of those things where the longer it goes on, the harder it is to make that change. But at some point, you sometimes make the decision to make it. So I will be very interested to hear if you do make that decision and then, if so, what that changeover process looks like. +STEPH: Yeah, totally. I'll be sure to keep you up to date as we make any progress or decisions around feature flags. +CHRIS: But yeah, your questions around management and communication of it that is a thing that's in the back of my mind. We're still early enough in our usage of it, and just broadly, how we're working, we haven't really felt that pain yet, but I expect it's coming very soon. And in particular, we have functionality now that is merged and is part of the codebase but isn't fully deployed or fully released rather. That's probably the correct word. We have not fully released this functionality, and we don't have a system right now for tracking that. +So I'm thinking right now we're using Trello for product management. I'm thinking we want another column that is not entirely done but is tracking the feature flags that are currently in flight and just use that as a place to gather communication. Do we feel like this is ready? Let's dial this up to 50%, or let's enable it for this beta group or whatever it is to sort of be able to communicate that. And then ideally, also as a way to track these are the ones that are active right now. You know what? We feel like this one's ready. So do the code change so that we no longer use the feature flag, and then we can actually turn it off. Currently, I feel like I can defer that for a little while, but it is something that's in the back of my mind. +And then, of course, I nerd sniped myself, and I was like, all right, how do I grep the codebase for all the feature flags that we're using? Okay. There are a couple of different patterns as to how we're using…You know what? I think I actually need an AST-based parser here, and I need to use the Visitor...You know what? Never mind. Stop it. Stop it. [laughs] It was one of those where I was like...I was doing this not during actual work hours. It was just a question in my mind, and then I started to poke at it. I was like, oh, this could be fun. And then I was like, no, no, no, stop it. You need to go read a book or something. Calm down. +STEPH: As part of the optimization around our feature flag system that we've created, we've added a few enhancements, which I think is also one of the reasons we're starting to question how far we want to go in this direction. One of them is we want a very easy way to track what's turned on and what's turned off for an environment. So we have a task that will easily check, or it prints out a really nice list of these are all your flags, and this is the state that they're in. And by using the system that we have, we have one file that represents...well, you mentioned migration because we're migrating from the old system to this new one. So it's still a little bit in that space of where we haven't fully moved over. So now, moving over to a third thing like Flipper will be even more interesting because of that. +But the current system, we have a file that lists all the feature flags and a really nice description that goes with it, which I know is supported by Flipper and other services as well. But having that one file does make it nice where you can just scan through there and see what's in use. I really think it's the UI and the challenges that the users are facing and understanding what a feature flag does, and which ones they should turn off, and which ones they shouldn't touch that that's the point where we started questioning okay, we need to improve the UI. +But to improve the UI, do we really want to fully embrace our current system and make those improvements, or is now that time that we should consider moving to something else? Because Flipper already has a really nice UI. I think there is a free tier and a paid tier with Flipper, and the paid tier has a UI that ships. +CHRIS: There's definitely a distinct thing, Flipper Cloud, which is their hosted enterprise-y solution, and that's the paid offering. But Flipper just the core gem there's also Flipper web, I want to say is what it is, or Flipper UI. And I think it's an engine that you mount within your Rails app and that displays a UI so that you can manage things, add groups and teams. So we're definitely using that. I've got my eye on Flipper Cloud, but I have some fundamental questions around I like to keep my data in the system, and so this is an external other thing. And what's the synchronization? I haven't really even looked into it like that. But I love that Flipper exists within our application. +One of the niceties that Flipper Cloud does have is an audit history, which I think is interesting just to understand over time who changed what for what reasons? It's got the ability to roll back and maintain versions and whatnot. So there are some things in it that definitely look very interesting to me. But for now, the open-source, free version of Flipper plus Flipper UI has been plenty for us. +STEPH: That's cool. I didn't know about the audit feature. +CHRIS: Yeah. It definitely feels like one of those niceties to have for a more enterprise offering. So I could see myself talking me into it at some point but not quite yet. On that note though, so feature flags we introduced a week and a half, something like that, ago, and we've been leaning into them more and more. But as part of that, or in the back of my mind, I've wanted to go to continuous deployment. +So we had our first official retro this week. The project is growing up. We're becoming a lot of things. We used retro to talk about continuous deployment, all of these things that feel very real. Just to highlight it, retro is super important. And the fact that we haven't had one until now is mainly because up till now, it’s been primarily myself and another developer. So we've been having essentially one-on-ones but not a more formal retro that involves others. +At this point, we now have myself and two other developers that are working on the project, as well as someone who's stepped into the role of product manager. So we now have communication collaboration. How are we doing the work? How are we shipping features and communicating about bugs and all of that? So now felt like the right time to start having that more formal process. So now, every two weeks, we're going to have a retro, and hopefully, through that, retro will do the magic that retro can do at its best which is help us get better at all the things that we're doing. +But yeah, one of the core things in this particular one was talking about moving to continuous deployment. And so I am super excited to get there because I think, much like test-driven development, it's one of those situations where continuous deployment puts a lot of pressure on the development process. Everything that is being merged needs to be ready to go out into production. And honestly, I love that as a constraint because that will change how you build things. It means that you need to be a little more cautious. You can put something behind a feature flag to protect it. You decouple the idea of merging and deploying from releasing. And I like that distinction. +I think that's a really meaningful distinction because it makes you think about what's the entry point to this feature within the codebase? And it's, I think, actually really nice to have fewer and more intentional entry points into various bits of functionality such that if you actually want to shut it off in production, you can do that. That's more straightforward. I think it encourages an intentional coupling, maybe not a perfect decoupling but an intentional coupling within the system. +So I'm very excited to explore it. I think feature flags are going to be critical for it, and I think also observability, and monitoring, and logging, and all those things. We need to get really good at them so that if anything does go wrong when we just merge and deploy, we want to know if anything goes wrong as quickly as possible. But overall, I'm super excited about all of the other niceties that fall out of it. +STEPH: [singing] I wanna know what's turned on, and I want you to show me. Is that the song you're singing to Flipper? [laughs] +CHRIS: [laughs] +STEPH: Sorry, friends. I just had to go there. +CHRIS: That was just in your head. You had that, and you needed to get it out. I appreciate it. [laughter] Again, I got Flipper UI, so that's not the question I'm asking. I think that's the question you have in your heart. +STEPH: [laughs] +Mid-roll Ad +And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. +With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. +The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. +STEPH: That's funny about the CI deployment adding pressure to the development process because you're absolutely right. But I see it as such a positive and improvement that I don't really think about the pressure that it's adding. And I just think, yes, this is awesome, and I want this to happen and if there are steps that we have to take in that direction. +It dawned on me that what you said is very true, but I've just never really thought about it from that perspective about the pressure. Because I think the thing that does add more pressure for me is figuring out what can I deploy, or do I need to cherry-pick commits? What does that look like? And going through that whole cycle and stress is more stressful to me than figuring out how do we get to continuous deployments and making sure that everything is in a safe space to be deployed? +CHRIS: That's the dream. I'm going to see if I can live it. I'll let you know how it goes. But yeah, that's a bit of what's up in my world. What else is going on in your world other than some lovely singing? +STEPH: Oh, there's always lots of singing. It's been an interesting week. It's been a mix of some hiring work. Specifically, we are helping our client team build their development team. So we have been helping them implement a hiring process. And then also going through technical interviews and then going through different stages of that interview process. And that's been really nice. I haven't done that specifically for a client team where I helped them build a hiring pipeline from scratch and then also conduct those interviews. +And one thing that stood out to me is that rotations are really important to me and specifically that we don't ask for volunteers. So as we were having candidates come through and then they were ready to schedule an interview, then we are reaching out to the rest of the development team and saying, "Hey, we have this person. They're going to be scheduled at this time. Who's available? Who's interested? I'm looking for volunteers." And that puts pressure on people, especially someone that may be more empathetic to feel the need to volunteer. So then you can end up having more people volunteer than others. +So we've established a rotation to make sure that doesn't happen, and people are assigned as it becomes their next turn to conduct an interview. So that's been a lot of fun to refine that process and essentially make it easier. So the rest of the development team doesn't have to think about the hiring. But it still has an easy way of just saying, "Hey," and tapping someone to say, "Hey, it's your turn to run an interview." +The other thing I've been working out is figuring out how to measure an experiment. So we at thoughtbot are running an experiment where we're looking to address some of the concerns around sustainability and people feeling burned out. And so we have introduced half-day Fridays, more specifically 3.5 Fridays, as our half-day Fridays just to help everybody be certain about what a half-day looks like. +And then also, you can choose your half-day. Everybody works different schedules. We're across different time zones, so just to make sure it's really clear for folks and that they understand that they don't need to work more than those hours, and then they should have that additional downtime. And that's been amazing. This is the second Friday of the experiment, and we're doing this for nine Fridays straight. +And one of the questions that came up was, well, how do we know we did a good thing? How do we know that we helped people in terms of sustainability or addressing some of the feelings that they're having around burnout? And so I've collaborated with a couple of other thoughtboters to think through of a way to measure it. It turns out helping someone measure their wellness is incredibly complex. And so we went for a fairly simple approach where we're using an anonymous survey with a number of questions. +And those questions aren't really meant to stand up to scientific scrutiny but more to figure out how the team is feeling at the time that they fill out the survey and then also to understand how the reduced weekly hours have impacted their schedule. And are people working extra hours to then accommodate the fact that we now have these half Fridays? So do you feel pressured that because you can't work a full day on Friday that you are now working an extra hour or two Monday through Thursday to accommodate that time off? So that survey just went out today. +And one of the really interesting parts (I just haven't had to create content for a survey in a while.) was making sure that I'm not introducing leading questions or phrasing things in a very positive or negative light since that is a bias that then people will pick up on. So instead of saying, "I find it easy to focus at work," and then having like a multiple choice of true, always, never, that kind of thing, instead rephrasing the question to be, "Are you able to focus during work hours?" And then you have a scale there. +Or instead of asking someone how much energy they have, maybe it's something like, "Do you experience fatigue during the day?" Or instead of asking someone, "Are you stressed at work?" because that can have a more negative connotation. It may lead someone to feel more negatively as they are assessing that question. Then you can say, "How do you feel when you're at work?" And then you can provide those answers of I'm stressed, slightly stressed, neutral, slightly relaxed, and relaxed. +So it generated some interesting conversations around the importance of how we phrase questions and how we collect feedback. And I really enjoyed that process, and I'm really looking forward to seeing what folks have to say. And we're going to have three surveys total. So we have one that's early on in the experiment since we're only two Fridays in. We'll have one middle experiment survey go out, and then we'll have one at the end once we're done. And then hopefully, everybody's responses will then help us understand how the experiment went and then make a decision going forward. +I'll be honest; I’m really hoping that this becomes a trend and something that we stick with. It is a professional goal of mine to slowly reduce the hours that I work each week or quickly; it doesn't have to be slowly. But I really like the four-day workweek. It's something that I haven't done, but I've been reading about it a fair amount lately. I feel like I've been seeing more studies conducted recently becoming published, and it's just very interesting to me. +I had some similar concerns of how am I still going to be productive? My to-do list hasn't changed, but my hours are changing. So how am I still going to get everything done? And does it make sense for me to still get paid the same amount of money if I'm only working four out of the five days? And I had lots of questions around that, and the studies have been very enlightening and very positive in the outcome of a reduced workweek, not just for the individuals but for the companies as well. +CHRIS: It's such an interesting space and exploration. The way that you're framing the survey sounds really great. It sounds like you're trying to be really intentional around the questions that you're asking and not being leading and whatnot. That said, it is one of the historically hard problems trying to quantify this and trying to actually boil it down. +And there are so many different axes even that you're measuring on. Is it just increased employee happiness? Is it retention that you're talking about? Is it overall revenue? There are so many different things, and it's very tricky. I'm super interested to hear the results when you get those. So you're doing what sounds like more of a qualitative study like, how are you feeling? As opposed to a more quantitative sort of thing, is that right? +STEPH: Yes, it's more in the realm of how are you feeling? And are you working extra hours, or are you truly taking the time off? +CHRIS: Yeah, I think it's really hard to take something like this and try and get it into the quantitative space, even though like, oh yeah, if we could have a number, if it used to be two and now it's four, fantastic. We've doubled whatever that measure is. I don't know what the unit would be on this arbitrary number I made up. But again, that's the hard thing and probably not feasible at all. And so it makes sense the approach that you're taking. But it's super difficult. So I'm very interested to hear how that goes. +More generally, the four-day workweek thing is such a nice idea. We should do that more. I'm trying to think how long I did that. So during the period that I was working freelance, I think there were probably at least five months where I did just a true four-day workweek. Fridays were my own. It was fantastic. Granted, I recorded the podcast with you. But that day was mine to shape as I wanted. +And I found it was a really nice decompression period having that for a number of weeks in a row. And just getting to take care of personal stuff that I hadn't been and just having that extra little bit of space and time. And it really was wonderful. Now I'm working full five days a week, and my Fridays aren't even investment days, so I don't know what I'm doing over here. +But I agree. I really like that idea, and I think it's a wonderful thing. And it's, I don't know, sort of the promise of this whole capitalism adventure we're supposed to go on, increasing productivity. And wasn't this the promise the whole time, everybody, so I am intrigued to see it being explored more, to see it being discussed. And what you're talking about of it's not just good for the employees, but it's also great for the companies. You're getting people that are more engaged on the days that they're working, which feels very true to me. +Like, on a great day, I can do some amazing work. On a terrible day, I can do mediocre to bad work. It is totally possible for me to do something that is actively detrimental. Like, I introduce a bug that is going to impact a bunch of customers. And the remediation of that is going to take many more hours. That is totally a realistic thing. I think we often think of productivity in terms of are you at zero or some amount more than zero? But there is definitely another side of that. And so the cost of being not at your best is extremely high in my mind. And so anything we can do to improve that. +STEPH: There's a recent study from a non-profit company called Autonomy that published some research called Going Public: Iceland's Journey to a Shorter Working Week. It's very interesting. And a number of people in my social circle have shared it. And that's one of the reasons that I came across it. And they commented in there that one of the reasons...I hope I'm getting this right, but we'll link to it in case I've gotten it a bit wrong. +But one of the reasons that Iceland was interested or open to this idea of moving workers to a shorter workweek is because they were struggling with productivity and where people were working a lot of hours, but it still felt like their productivity was dropping. So then Autonomy ran this study to help figure out are there ways to improve productivity? Will shortening a workweek actually lead to higher productivity? +And there was a statement in there that I really liked where it talks about the more hours that we work; we’re actually lowering our per hour productivity which rings so true for me. Because I am one of those individuals where I'm very stubborn, and so if I'm stuck on something, I will put so many hours into trying to figure it out. But at some point, I have to just walk away, and if I do, I will solve it that much faster. But if I just try to use hours as my way to chip away at a problem, then that's not going to solve it. And my ability to solve that problem takes exponentially more time than if I had just walked away and then come back to the problem fresh and engaged. +And some of the case studies I admired the way that they tackled the problem. They would essentially pay the company. So the company could reduce the hours for certain employees so then they could run the experiment. So if they reduced employees to say 32 hours but the company didn't actually want to stop working at 32 hours and they wanted to keep going, so then they brought in other people to work the remaining eight hours. Then as part of that study, they would pay the company to help them stay at their current level of productivity or current level of hours. This way, they could conduct the study. And I thought that was a really neat idea. +I do have lots of questions still around the approach itself because it is how do you reduce your to-do list, essentially? So just because you dropped to a four-day workweek. So essentially, you have to just say less stuff gets done. Or, as these case studies promise, they're saying you're actually going to be more productive. So you will still continue to get a lot of your work done. I'm curious about that. I'd like to track my own productivity and see if I feel similarly. +And then also, who is this for? Is this for everybody? Does everybody get to move to a four-day workweek? Is this for certain companies? Is it for certain jobs? Ideally, this is for everybody because there are so many health benefits to this, but I'm just intrigued as to who this is for, who it impacts, how can we make it available for everyone? And is the dream real that I can work four days a week and still feel as productive, if not more productive, and healthier, and happier as I do when working five days a week? +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: I remember there was an extended period where working remote was this unique benefit that some organizations had. They had adopted that mode. They were async, and remote, and all of these wonderful things. And it became this really interesting selling point for those companies. Now the pandemic obviously pushed public opinion and everything on that in a pretty significant way such that it's a much more common thing. And so, as a result, I think it's less of a differentiator now. It used to be a way to help with recruiting. +I wonder if there are organizations that are willing to take this, try it out, see that they are still close to as productive. But if it means that hiring is twice as easy, that is absolutely...especially if it is able to double your ability to hire, that is incredibly valuable or retention similarly. If you can increase retention or if you can make it easier to hire, the value of that is so, so high. +And it's interesting in my mind because there's sort of a gold rush on that. That's only true for as long as a four-day workweek is a unique benefit of working at the organization. If this is actually the direction that everything's going and eventually everyone's going to settle to that, then if you wait too long to get there, then you're going to miss all the benefits. You're going to miss that particular benefit of it. +And so I do wonder, would it be advantageous to organizations...I'm thinking about this now. Maybe this is the thing I have to do. But would it be advantageous to be that organization as early on as possible and try to get ahead of the curve and use that to hire more easily, retain more easily? Now that I say it all out loud, I'm sold. All right. I got to do this. +STEPH: Yeah, I think that's a great comparison of where people are going to start to look for those types of benefits. And so, if you are one of the early adopters and you have the four-day workweek or a reduced workweek in general, then people will gravitate towards that benefit. And it's something that people can use to really help with hiring and retention. And yeah, I love it. +You are CTO. So you have influence within your company that you could push for the four-day workweek if you think that's what you want to do. And I would be really intrigued to hear how that goes and how you feel if you...well, you've done it before where you've worked four days a week. So applying that to your current situation, how does that feel? +CHRIS: Now you're actually holding me accountable to the things that I randomly said in passing. But it's interesting. So we're so early stage, and there's so much small work to do. There's all…oh, got to set up a website. We've got to do this. We've got to build that integration. There's just kind of scrambling to be done. +And so there's a certain version in my mind that maybe we're in a period of time where additional hours are actually useful. There's a cost to them. Let's be clear about that. And so how long that will remain true, I'm not sure. I could see a point perhaps down the road where we achieve a little bit closer to steady-state maybe, who knows? It depends on how fast growth is and et cetera, a lot of other things. +So I'm not sure that I would actually lead with this experiment myself, given where the organization is at right now. But I could see an organization that's at a little bit more of a steady-state, that's growing more incrementally, that is trying to think really hard about things like hiring and retention. If those were bigger questions in my mind, then I think I would be considering this more pointedly. But for now, I'm like, I kind of just got to do a bunch of stuff. And so my brain is telling me a different story, but it is interesting. I want to interrogate that and be like, brain, why is that the story you have there, huh? Huh? +STEPH: I really appreciate what you're saying, though, because that makes sense to me. I understand when you are in that earlier stage, there's enough to do that that feels correct. Versus that added benefit of having a reduced workweek does benefit or could benefit larger companies who are looking to hire more heavily, or they're also concerned about retention or just helping their people address feelings of burnout. So I really appreciate that perspective because that also rings true. +So along this whole conversation around wellness and how we can help people work more sustainable hours, there's a particular book that I've read that I've been really excited to share and chat with you about. It's called Burnout: The Secret to Unlocking the Stress Cycle. It's written by two sisters, Emily and Amelia Nagoski. And they really talk through the impact that stress has on us and then ways to work through that. +And specifically, they talk about completing the stress cycle. And I found this incredibly useful for me because I have had weeks where I have just worked hard Monday through Friday. I've gotten to the end of my day Friday, and I'm like, great, I'm done. I've made it. I can just relax. And I walk away from work, and I can't relax. And I'm just like, I feel sick. I feel not good. +Like, I thought I would walk away from work, and I would just suddenly feel this halo of relaxation, and everything would be wonderful. But instead, I just feel a bit ill, and I've never understood that until I was reading their book about completing the stress cycle. Have you ever had moments like that? +CHRIS: It has definitely happened to me at various points, yes. +STEPH: That makes me feel better because I haven't really chatted about this with someone. So until I read this book and I was like, oh, maybe this is a thing, and it's not just me, and this is something that people are experiencing. So to speak more about completing the stress cycle, they really highlight that stress and feelings, capital F feelings, can cause physiological symptoms. And so it's not just something that we are mentally processing, but we are physically processing the stress that we feel. +And there's a really big difference between stressors and stress. So a stressor could be something like an unmeetable deadline. It could be family. It could be money concerns. It could be your morning commute, anything that increases your stress level. And during that, there's a very physical process that happens to your body anytime there's a perceived threat. And it's really helpful to us because it's frankly what triggers our fight, flight, or freeze response. And our bodies receive a rush of adrenaline and cortisol, which essentially, if we're using that flight response, that's going to help us run. And a number of the processes in our system will essentially go into a state of hibernation because everything in our body is very focused on helping us run or do the thing that we think is going to save our life in that moment. +The problem is our body doesn't know the difference between what's more of a mental threat versus what is a truly physical threat. So this is the difference between your stress and your stressors. So in more of a physical threat, if there's a lion that you are running from, that is the stressor, but then the stress is everything that you still feel after you have run from that lion. +So you encounter a lion, you run. You make it back to your group of people where you are safe, and you celebrate, and you dance, and you hug. And that is completing the stress cycle because you are essentially processing all of that stress. And you are telling your body in a body-focused language that I am safe now, and everything is fine. So you can move back, and anything that was in a hibernation state, all of that dump of adrenaline and cortisol can be worked out of your system, and everything can go back to a normal state. +Most of us aren't encountering lions, but we do encounter jerks in meetings or really stressful commutes. And whenever we have survived that meeting, or we've gotten through our commute to the other side, we don't have that moment of celebration where we really let our body know that hey, we've made it through that moment of stress, and we are away from that stressor, and we can actually process everything. +So if you're interested in this, the book's really great. It talks about ways that you can process that stress and how important it is to do so. Otherwise, it will literally build up in your system, and it can make you sick. And it will manifest in ways that will let us know that we haven't dealt with that stress. +And one of the top methods that they recommend is exercise and movement. That's a really great way to let your body know that you are no longer in an unsafe state, and your body can start to relax. There's also a lot of other great ways. Art is a really big one. It could be hugging someone. It could be calling someone that you love. There are a number of ways that you can process it. But I hadn't recognized how important it is that once you have removed yourself from a stressor, that doesn't necessarily just mean you're done, and you can relax. You actually have to go through that physical process, and then you can relax. +So I started incorporating that more into my day that when I'm done with work, I always find something to do, and it's typically to go for a walk, or it's go for a run. And I have found that now I really haven't felt that ill-feeling where I'm trying to relax, but I just feel sick. Saying that out loud, I feel like I'm a mess on Fridays. [chuckles] +CHRIS: I feel like you're human. It was interesting when you asked the question at the beginning. You were like, "Is this a thing that other people experience?" And my answer was certainly, yes; I have experienced this. I think there's something about me that I think is useful where I don't think I'm special at all on any axis whatsoever. And so whenever there's something that's going on, I'm like, I assume that this is just normal human behavior, which is useful because most of the time it is. +And this is the sort of thing where if I'm having a negative experience, I will look to the external world to be like, I'm sure other people have experienced this, and let me pull that in. And I've found that really useful for myself to just be like, I’m not special. There's nothing particularly special about me. So let me go look from the entirety of the internet where people have almost certainly talked about this. And I've not read the book that you're describing here, but it does sound like it does a great job of describing this. +There is a blog post that I found that has stayed in the back of my mind and informed a little bit of my day-to-day approach to this sort of thing which is a blog post by Cal Newport, who I think at this point we've mentioned him a handful of times on the show. But the title of the post is Drastically Reduce Stress with a Work Shutdown Ritual. And it's this very interesting little post where he talks about at the end of your day; you want to close the book on it. I think this is especially pointed now that many of us are working from home. For me, this is a new thing. And so, I've been very intentional with trying to put walks at the beginning and end of my day. +But in this particular blog post, he describes a routine that he does where he tidies things up and makes his list for the next day. And then he has a particular phrase that he says, which is "schedule shut down, complete." And it's a sort of nonsense phrase. It doesn't even quite make sense grammatically, but it's his phrase that he internalized, and somehow this became his almost mantra for the end of the day. +And now when he does it, that's like his all right, okay, turned off the brain, and now I can walk away. I know that I've said the phrase, and I only say the phrase when I have properly set things up. And so it's this weird structure that he's built in his mind. But it totally works to quiet those voices that are like, yeah, but what about…Do we think about…Do we complete…And he's got now this magic phrase that he can say. And so I've really loved that. +For myself, I haven't gotten quite to that level, but I've definitely built the here's how I wind down at the end of the day. Here's what I do with lists and what I do so that I can ideally walk away comfortably. Again, this is one of those situations where I sound like I know what I'm doing or have my act together. This is aspirational me. +Day-to-day me is a hot mess like everybody else. [laughs] And this is just what I...when I do this, I feel better. Most of the time, I don't do this because I forget it, or because I'm busy, or because I'm stressed, [chuckles], and so I don't do the thing that reduces stress, you know, human stuff. But I really enjoyed that post. +STEPH: I haven't heard that one. I like a lot of Cal Newport's work, but I haven't read that particular blog post. Yeah, I think the idea of completing the stress cycle has helped me tremendously because by giving it a name like completing the stress cycle has been really helpful for me because working out is important to me. It's something that I enjoy, but it's also one of those things that's easy to get bumped. It is part of my wellness routine. And so, if I'm really busy, then I will bump it from the list. And then it's something that then doesn't get addressed. +But recognizing that this is also important to my productivity, not to just this general idea of wellness, has really helped me recenter how important this is and to make sure that I recognize hey, it's been a stressful day. I need to get up and move. That is a very important part of my day. It is not just part of an exercise routine, but this is something that I need to do to close out my day to then make sure I have a great day tomorrow. +So bringing it back, it's been a week that's been filled with a lot of discussions around burnout and then ways that we can measure it and then also address it. And I've really enjoyed reading this book. So I'll be sure to drop a link in the show notes. On that note, shall we wrap up? +CHRIS: Schedule shut down, complete. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeeee!!! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris talks feature flags featuring Flipper (Say that 3x fast!), and Steph talks reducing stress by a) having a work shutdown ritual and b) the fact that thoughtbot is experimenting with half-day Fridays. (Fri-yay?)

+ + + +

Transcript:

+ +

STEPH: Hey, do you know that we could have an in-person recording at the end of October?

+ +

CHRIS: I do. Yes, I'm planning. That is in the back of my head. I guess I hadn't said that to you yet. But I'm glad that we have separately had the same conversation, and we've got to figure that out, although I don't know how to do noise cancellation and whatnot in the room. [laughs] How do we...we'll have to figure it out. Like, put a blanket in between us but so that we can see across it, but it absorbs sound in the middle. It's weird. I don't know how to do stuff. Just thinking out loud here.

+ +

STEPH: We'll just be in the same place but still different rooms. So it'll feel no different.

+ +

[laughter]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: Feature flags. Feature flags are an old favorite, but they have become new again in the application that I'm working on. We had a new feature that we were building out. But we assumed correctly that it would be nice to be able to break it apart into smaller pieces and sort of deliver it incrementally but not necessarily want to expose that to our end users. And so, we opted with that ticket to bring along the feature flag system.

+ +

So we've introduced Flipper, in particular, which is a wonderful gem; it does the job. We're using the ActiveRecord adapter. All that kind of makes sense, happy about that. And so now we have feature flags. But it was one of those mindset shifts where the minute we got feature flags, I was like, yes, okay, everything behind a feature flag. And we've been leaning into that more and more, and it really is so nice and so freeing, and so absolutely loving it so far.

+ +

STEPH: I'm intrigued. You said, "Everything behind a feature flag." Like, is it really everything or? Yeah, tell me more.

+ +

CHRIS: Not everything. But at this point, we're still very early on in this application, so there are fundamental facets of the platform, different areas of what users can do. And so the actual stuff that works and is wired up is pretty minimal, but we want to have a little more surface area built out in the app for demo purposes, for conversations that are happening, et cetera.

+ +

And so, we built out a bunch of new pages to represent functionality. And so there are sidebar links, and then the actual page itself, and routing, and all of the things that are associated with that, and so all of those have come in. I think there are five new top-level nav sections of the platform that are all introduced behind a feature flag right now. And then there's some new functionality within existing pages that we've put behind feature flags. So it's not truly every line of code, but it's basically the entry point to all new major features we're putting behind a feature flag.

+ +

STEPH: Okay, cool. I'm curious. How are you finding that in terms of does it feel manageable? Do you feel like anybody can go into the UI and then turn on feature flags for demos and feel confident that they know what they're turning on and off?

+ +

CHRIS: We haven't gotten to that self-serve place. At this point, the dev team is managing the feature flags. So on production, we have an internal group configured within Flipper. So we can say, "Ship this feature for all internal users so that we can do testing." So there is a handful of us that all have accounts on production. And then on staging, we have a couple of representative users that we've been just turning everything on for so that we know via staging we can act as that user and then see the application with all of the bells and whistles.

+ +

Down the road, I think we're going to get more intentional with it, particularly the idea of a demo account. That's something that we want to lean into. And for that user, we'll probably be turning on certain subsets of the feature flags. I think we'll get a little more granular in how we think about that. For now, we're not as detailed in it, but I think that is something that we want to expand as we move forward.

+ +

STEPH: Nice. Yeah, I was curious because feature flags came up in our recent retro with the client team because we've gotten to a point where our feature flags feel complex enough that it's becoming challenging and not just from the complexity of the feature flags but also from the UI perspective. Where it feels challenging for users to understand how to turn a feature on, exactly what that impacts, and making sure that then they're not changing developer-focused feature flags, so those are the feature flags that we're using to ship a change but then not turn it on until we're ready. It is user-facing, but it's something that should be managed more by developers as to when we turn it on or off. So I was curious to hear that's going for you because that's something that we are looking into.

+ +

And funnily enough, you asked me recently, "Why aren't y'all using Flipper?" And I didn't have a great answer for you. And that question came up again where we looked at each other, and we're like, okay, we know there was a really good reason we didn't use Flipper when we first had this discussion. But none of us can remember, or at least the people in that conversation couldn't remember. So now we're asking ourselves the question of we've made it this far. Is it time to bring in Flipper or another service? Because we're getting to the point that we're starting to build too much of our own feature flag system.

+ +

CHRIS: So did you uncover an answer, or are you all just agreeing that the question makes sense?

+ +

STEPH: Agreeing that the question makes sense. [laughs]

+ +

CHRIS: That's the first step on a long journey to switching from internal tooling to somebody else managing that for you.

+ +

STEPH: Yeah, because none of us could remember exactly. But it was funny because I was like, am I just forgetting something here when you asked me that? So I felt validated that others were like, "Oh yeah, I remember that conversation. But I too can't recall why we didn't want to use Flipper in the moment or a similar service."

+ +

CHRIS: I'll definitely be interested to hear if you do end up trying to migrate off to another system or find a different approach there or if you do stick with the current configuration that you have. Because those projects they're the sort of sneaky ones that it's like, oh, we've been actually relying on this for a while. It's a core part of our infrastructure, and how we do the work, and the process, and how we deploy. That's a lot. And so, to switch that out in-flight becomes really difficult. It's one of those things where the longer it goes on, the harder it is to make that change. But at some point, you sometimes make the decision to make it. So I will be very interested to hear if you do make that decision and then, if so, what that changeover process looks like.

+ +

STEPH: Yeah, totally. I'll be sure to keep you up to date as we make any progress or decisions around feature flags.

+ +

CHRIS: But yeah, your questions around management and communication of it that is a thing that's in the back of my mind. We're still early enough in our usage of it, and just broadly, how we're working, we haven't really felt that pain yet, but I expect it's coming very soon. And in particular, we have functionality now that is merged and is part of the codebase but isn't fully deployed or fully released rather. That's probably the correct word. We have not fully released this functionality, and we don't have a system right now for tracking that.

+ +

So I'm thinking right now we're using Trello for product management. I'm thinking we want another column that is not entirely done but is tracking the feature flags that are currently in flight and just use that as a place to gather communication. Do we feel like this is ready? Let's dial this up to 50%, or let's enable it for this beta group or whatever it is to sort of be able to communicate that. And then ideally, also as a way to track these are the ones that are active right now. You know what? We feel like this one's ready. So do the code change so that we no longer use the feature flag, and then we can actually turn it off. Currently, I feel like I can defer that for a little while, but it is something that's in the back of my mind.

+ +

And then, of course, I nerd sniped myself, and I was like, all right, how do I grep the codebase for all the feature flags that we're using? Okay. There are a couple of different patterns as to how we're using…You know what? I think I actually need an AST-based parser here, and I need to use the Visitor...You know what? Never mind. Stop it. Stop it. [laughs] It was one of those where I was like...I was doing this not during actual work hours. It was just a question in my mind, and then I started to poke at it. I was like, oh, this could be fun. And then I was like, no, no, no, stop it. You need to go read a book or something. Calm down.

+ +

STEPH: As part of the optimization around our feature flag system that we've created, we've added a few enhancements, which I think is also one of the reasons we're starting to question how far we want to go in this direction. One of them is we want a very easy way to track what's turned on and what's turned off for an environment. So we have a task that will easily check, or it prints out a really nice list of these are all your flags, and this is the state that they're in. And by using the system that we have, we have one file that represents...well, you mentioned migration because we're migrating from the old system to this new one. So it's still a little bit in that space of where we haven't fully moved over. So now, moving over to a third thing like Flipper will be even more interesting because of that.

+ +

But the current system, we have a file that lists all the feature flags and a really nice description that goes with it, which I know is supported by Flipper and other services as well. But having that one file does make it nice where you can just scan through there and see what's in use. I really think it's the UI and the challenges that the users are facing and understanding what a feature flag does, and which ones they should turn off, and which ones they shouldn't touch that that's the point where we started questioning okay, we need to improve the UI.

+ +

But to improve the UI, do we really want to fully embrace our current system and make those improvements, or is now that time that we should consider moving to something else? Because Flipper already has a really nice UI. I think there is a free tier and a paid tier with Flipper, and the paid tier has a UI that ships.

+ +

CHRIS: There's definitely a distinct thing, Flipper Cloud, which is their hosted enterprise-y solution, and that's the paid offering. But Flipper just the core gem there's also Flipper web, I want to say is what it is, or Flipper UI. And I think it's an engine that you mount within your Rails app and that displays a UI so that you can manage things, add groups and teams. So we're definitely using that. I've got my eye on Flipper Cloud, but I have some fundamental questions around I like to keep my data in the system, and so this is an external other thing. And what's the synchronization? I haven't really even looked into it like that. But I love that Flipper exists within our application.

+ +

One of the niceties that Flipper Cloud does have is an audit history, which I think is interesting just to understand over time who changed what for what reasons? It's got the ability to roll back and maintain versions and whatnot. So there are some things in it that definitely look very interesting to me. But for now, the open-source, free version of Flipper plus Flipper UI has been plenty for us.

+ +

STEPH: That's cool. I didn't know about the audit feature.

+ +

CHRIS: Yeah. It definitely feels like one of those niceties to have for a more enterprise offering. So I could see myself talking me into it at some point but not quite yet. On that note though, so feature flags we introduced a week and a half, something like that, ago, and we've been leaning into them more and more. But as part of that, or in the back of my mind, I've wanted to go to continuous deployment.

+ +

So we had our first official retro this week. The project is growing up. We're becoming a lot of things. We used retro to talk about continuous deployment, all of these things that feel very real. Just to highlight it, retro is super important. And the fact that we haven't had one until now is mainly because up till now, it’s been primarily myself and another developer. So we've been having essentially one-on-ones but not a more formal retro that involves others.

+ +

At this point, we now have myself and two other developers that are working on the project, as well as someone who's stepped into the role of product manager. So we now have communication collaboration. How are we doing the work? How are we shipping features and communicating about bugs and all of that? So now felt like the right time to start having that more formal process. So now, every two weeks, we're going to have a retro, and hopefully, through that, retro will do the magic that retro can do at its best which is help us get better at all the things that we're doing.

+ +

But yeah, one of the core things in this particular one was talking about moving to continuous deployment. And so I am super excited to get there because I think, much like test-driven development, it's one of those situations where continuous deployment puts a lot of pressure on the development process. Everything that is being merged needs to be ready to go out into production. And honestly, I love that as a constraint because that will change how you build things. It means that you need to be a little more cautious. You can put something behind a feature flag to protect it. You decouple the idea of merging and deploying from releasing. And I like that distinction.

+ +

I think that's a really meaningful distinction because it makes you think about what's the entry point to this feature within the codebase? And it's, I think, actually really nice to have fewer and more intentional entry points into various bits of functionality such that if you actually want to shut it off in production, you can do that. That's more straightforward. I think it encourages an intentional coupling, maybe not a perfect decoupling but an intentional coupling within the system.

+ +

So I'm very excited to explore it. I think feature flags are going to be critical for it, and I think also observability, and monitoring, and logging, and all those things. We need to get really good at them so that if anything does go wrong when we just merge and deploy, we want to know if anything goes wrong as quickly as possible. But overall, I'm super excited about all of the other niceties that fall out of it.

+ +

STEPH: [singing] I wanna know what's turned on, and I want you to show me. Is that the song you're singing to Flipper? [laughs]

+ +

CHRIS: [laughs]

+ +

STEPH: Sorry, friends. I just had to go there.

+ +

CHRIS: That was just in your head. You had that, and you needed to get it out. I appreciate it. [laughter] Again, I got Flipper UI, so that's not the question I'm asking. I think that's the question you have in your heart.

+ +

STEPH: [laughs]

+ +

Mid-roll Ad

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city.

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: That's funny about the CI deployment adding pressure to the development process because you're absolutely right. But I see it as such a positive and improvement that I don't really think about the pressure that it's adding. And I just think, yes, this is awesome, and I want this to happen and if there are steps that we have to take in that direction.

+ +

It dawned on me that what you said is very true, but I've just never really thought about it from that perspective about the pressure. Because I think the thing that does add more pressure for me is figuring out what can I deploy, or do I need to cherry-pick commits? What does that look like? And going through that whole cycle and stress is more stressful to me than figuring out how do we get to continuous deployments and making sure that everything is in a safe space to be deployed?

+ +

CHRIS: That's the dream. I'm going to see if I can live it. I'll let you know how it goes. But yeah, that's a bit of what's up in my world. What else is going on in your world other than some lovely singing?

+ +

STEPH: Oh, there's always lots of singing. It's been an interesting week. It's been a mix of some hiring work. Specifically, we are helping our client team build their development team. So we have been helping them implement a hiring process. And then also going through technical interviews and then going through different stages of that interview process. And that's been really nice. I haven't done that specifically for a client team where I helped them build a hiring pipeline from scratch and then also conduct those interviews.

+ +

And one thing that stood out to me is that rotations are really important to me and specifically that we don't ask for volunteers. So as we were having candidates come through and then they were ready to schedule an interview, then we are reaching out to the rest of the development team and saying, "Hey, we have this person. They're going to be scheduled at this time. Who's available? Who's interested? I'm looking for volunteers." And that puts pressure on people, especially someone that may be more empathetic to feel the need to volunteer. So then you can end up having more people volunteer than others.

+ +

So we've established a rotation to make sure that doesn't happen, and people are assigned as it becomes their next turn to conduct an interview. So that's been a lot of fun to refine that process and essentially make it easier. So the rest of the development team doesn't have to think about the hiring. But it still has an easy way of just saying, "Hey," and tapping someone to say, "Hey, it's your turn to run an interview."

+ +

The other thing I've been working out is figuring out how to measure an experiment. So we at thoughtbot are running an experiment where we're looking to address some of the concerns around sustainability and people feeling burned out. And so we have introduced half-day Fridays, more specifically 3.5 Fridays, as our half-day Fridays just to help everybody be certain about what a half-day looks like.

+ +

And then also, you can choose your half-day. Everybody works different schedules. We're across different time zones, so just to make sure it's really clear for folks and that they understand that they don't need to work more than those hours, and then they should have that additional downtime. And that's been amazing. This is the second Friday of the experiment, and we're doing this for nine Fridays straight.

+ +

And one of the questions that came up was, well, how do we know we did a good thing? How do we know that we helped people in terms of sustainability or addressing some of the feelings that they're having around burnout? And so I've collaborated with a couple of other thoughtboters to think through of a way to measure it. It turns out helping someone measure their wellness is incredibly complex. And so we went for a fairly simple approach where we're using an anonymous survey with a number of questions.

+ +

And those questions aren't really meant to stand up to scientific scrutiny but more to figure out how the team is feeling at the time that they fill out the survey and then also to understand how the reduced weekly hours have impacted their schedule. And are people working extra hours to then accommodate the fact that we now have these half Fridays? So do you feel pressured that because you can't work a full day on Friday that you are now working an extra hour or two Monday through Thursday to accommodate that time off? So that survey just went out today.

+ +

And one of the really interesting parts (I just haven't had to create content for a survey in a while.) was making sure that I'm not introducing leading questions or phrasing things in a very positive or negative light since that is a bias that then people will pick up on. So instead of saying, "I find it easy to focus at work," and then having like a multiple choice of true, always, never, that kind of thing, instead rephrasing the question to be, "Are you able to focus during work hours?" And then you have a scale there.

+ +

Or instead of asking someone how much energy they have, maybe it's something like, "Do you experience fatigue during the day?" Or instead of asking someone, "Are you stressed at work?" because that can have a more negative connotation. It may lead someone to feel more negatively as they are assessing that question. Then you can say, "How do you feel when you're at work?" And then you can provide those answers of I'm stressed, slightly stressed, neutral, slightly relaxed, and relaxed.

+ +

So it generated some interesting conversations around the importance of how we phrase questions and how we collect feedback. And I really enjoyed that process, and I'm really looking forward to seeing what folks have to say. And we're going to have three surveys total. So we have one that's early on in the experiment since we're only two Fridays in. We'll have one middle experiment survey go out, and then we'll have one at the end once we're done. And then hopefully, everybody's responses will then help us understand how the experiment went and then make a decision going forward.

+ +

I'll be honest; I’m really hoping that this becomes a trend and something that we stick with. It is a professional goal of mine to slowly reduce the hours that I work each week or quickly; it doesn't have to be slowly. But I really like the four-day workweek. It's something that I haven't done, but I've been reading about it a fair amount lately. I feel like I've been seeing more studies conducted recently becoming published, and it's just very interesting to me.

+ +

I had some similar concerns of how am I still going to be productive? My to-do list hasn't changed, but my hours are changing. So how am I still going to get everything done? And does it make sense for me to still get paid the same amount of money if I'm only working four out of the five days? And I had lots of questions around that, and the studies have been very enlightening and very positive in the outcome of a reduced workweek, not just for the individuals but for the companies as well.

+ +

CHRIS: It's such an interesting space and exploration. The way that you're framing the survey sounds really great. It sounds like you're trying to be really intentional around the questions that you're asking and not being leading and whatnot. That said, it is one of the historically hard problems trying to quantify this and trying to actually boil it down.

+ +

And there are so many different axes even that you're measuring on. Is it just increased employee happiness? Is it retention that you're talking about? Is it overall revenue? There are so many different things, and it's very tricky. I'm super interested to hear the results when you get those. So you're doing what sounds like more of a qualitative study like, how are you feeling? As opposed to a more quantitative sort of thing, is that right?

+ +

STEPH: Yes, it's more in the realm of how are you feeling? And are you working extra hours, or are you truly taking the time off?

+ +

CHRIS: Yeah, I think it's really hard to take something like this and try and get it into the quantitative space, even though like, oh yeah, if we could have a number, if it used to be two and now it's four, fantastic. We've doubled whatever that measure is. I don't know what the unit would be on this arbitrary number I made up. But again, that's the hard thing and probably not feasible at all. And so it makes sense the approach that you're taking. But it's super difficult. So I'm very interested to hear how that goes.

+ +

More generally, the four-day workweek thing is such a nice idea. We should do that more. I'm trying to think how long I did that. So during the period that I was working freelance, I think there were probably at least five months where I did just a true four-day workweek. Fridays were my own. It was fantastic. Granted, I recorded the podcast with you. But that day was mine to shape as I wanted.

+ +

And I found it was a really nice decompression period having that for a number of weeks in a row. And just getting to take care of personal stuff that I hadn't been and just having that extra little bit of space and time. And it really was wonderful. Now I'm working full five days a week, and my Fridays aren't even investment days, so I don't know what I'm doing over here.

+ +

But I agree. I really like that idea, and I think it's a wonderful thing. And it's, I don't know, sort of the promise of this whole capitalism adventure we're supposed to go on, increasing productivity. And wasn't this the promise the whole time, everybody, so I am intrigued to see it being explored more, to see it being discussed. And what you're talking about of it's not just good for the employees, but it's also great for the companies. You're getting people that are more engaged on the days that they're working, which feels very true to me.

+ +

Like, on a great day, I can do some amazing work. On a terrible day, I can do mediocre to bad work. It is totally possible for me to do something that is actively detrimental. Like, I introduce a bug that is going to impact a bunch of customers. And the remediation of that is going to take many more hours. That is totally a realistic thing. I think we often think of productivity in terms of are you at zero or some amount more than zero? But there is definitely another side of that. And so the cost of being not at your best is extremely high in my mind. And so anything we can do to improve that.

+ +

STEPH: There's a recent study from a non-profit company called Autonomy that published some research called Going Public: Iceland's Journey to a Shorter Working Week. It's very interesting. And a number of people in my social circle have shared it. And that's one of the reasons that I came across it. And they commented in there that one of the reasons...I hope I'm getting this right, but we'll link to it in case I've gotten it a bit wrong.

+ +

But one of the reasons that Iceland was interested or open to this idea of moving workers to a shorter workweek is because they were struggling with productivity and where people were working a lot of hours, but it still felt like their productivity was dropping. So then Autonomy ran this study to help figure out are there ways to improve productivity? Will shortening a workweek actually lead to higher productivity?

+ +

And there was a statement in there that I really liked where it talks about the more hours that we work; we’re actually lowering our per hour productivity which rings so true for me. Because I am one of those individuals where I'm very stubborn, and so if I'm stuck on something, I will put so many hours into trying to figure it out. But at some point, I have to just walk away, and if I do, I will solve it that much faster. But if I just try to use hours as my way to chip away at a problem, then that's not going to solve it. And my ability to solve that problem takes exponentially more time than if I had just walked away and then come back to the problem fresh and engaged.

+ +

And some of the case studies I admired the way that they tackled the problem. They would essentially pay the company. So the company could reduce the hours for certain employees so then they could run the experiment. So if they reduced employees to say 32 hours but the company didn't actually want to stop working at 32 hours and they wanted to keep going, so then they brought in other people to work the remaining eight hours. Then as part of that study, they would pay the company to help them stay at their current level of productivity or current level of hours. This way, they could conduct the study. And I thought that was a really neat idea.

+ +

I do have lots of questions still around the approach itself because it is how do you reduce your to-do list, essentially? So just because you dropped to a four-day workweek. So essentially, you have to just say less stuff gets done. Or, as these case studies promise, they're saying you're actually going to be more productive. So you will still continue to get a lot of your work done. I'm curious about that. I'd like to track my own productivity and see if I feel similarly.

+ +

And then also, who is this for? Is this for everybody? Does everybody get to move to a four-day workweek? Is this for certain companies? Is it for certain jobs? Ideally, this is for everybody because there are so many health benefits to this, but I'm just intrigued as to who this is for, who it impacts, how can we make it available for everyone? And is the dream real that I can work four days a week and still feel as productive, if not more productive, and healthier, and happier as I do when working five days a week?

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: I remember there was an extended period where working remote was this unique benefit that some organizations had. They had adopted that mode. They were async, and remote, and all of these wonderful things. And it became this really interesting selling point for those companies. Now the pandemic obviously pushed public opinion and everything on that in a pretty significant way such that it's a much more common thing. And so, as a result, I think it's less of a differentiator now. It used to be a way to help with recruiting.

+ +

I wonder if there are organizations that are willing to take this, try it out, see that they are still close to as productive. But if it means that hiring is twice as easy, that is absolutely...especially if it is able to double your ability to hire, that is incredibly valuable or retention similarly. If you can increase retention or if you can make it easier to hire, the value of that is so, so high.

+ +

And it's interesting in my mind because there's sort of a gold rush on that. That's only true for as long as a four-day workweek is a unique benefit of working at the organization. If this is actually the direction that everything's going and eventually everyone's going to settle to that, then if you wait too long to get there, then you're going to miss all the benefits. You're going to miss that particular benefit of it.

+ +

And so I do wonder, would it be advantageous to organizations...I'm thinking about this now. Maybe this is the thing I have to do. But would it be advantageous to be that organization as early on as possible and try to get ahead of the curve and use that to hire more easily, retain more easily? Now that I say it all out loud, I'm sold. All right. I got to do this.

+ +

STEPH: Yeah, I think that's a great comparison of where people are going to start to look for those types of benefits. And so, if you are one of the early adopters and you have the four-day workweek or a reduced workweek in general, then people will gravitate towards that benefit. And it's something that people can use to really help with hiring and retention. And yeah, I love it.

+ +

You are CTO. So you have influence within your company that you could push for the four-day workweek if you think that's what you want to do. And I would be really intrigued to hear how that goes and how you feel if you...well, you've done it before where you've worked four days a week. So applying that to your current situation, how does that feel?

+ +

CHRIS: Now you're actually holding me accountable to the things that I randomly said in passing. But it's interesting. So we're so early stage, and there's so much small work to do. There's all…oh, got to set up a website. We've got to do this. We've got to build that integration. There's just kind of scrambling to be done.

+ +

And so there's a certain version in my mind that maybe we're in a period of time where additional hours are actually useful. There's a cost to them. Let's be clear about that. And so how long that will remain true, I'm not sure. I could see a point perhaps down the road where we achieve a little bit closer to steady-state maybe, who knows? It depends on how fast growth is and et cetera, a lot of other things.

+ +

So I'm not sure that I would actually lead with this experiment myself, given where the organization is at right now. But I could see an organization that's at a little bit more of a steady-state, that's growing more incrementally, that is trying to think really hard about things like hiring and retention. If those were bigger questions in my mind, then I think I would be considering this more pointedly. But for now, I'm like, I kind of just got to do a bunch of stuff. And so my brain is telling me a different story, but it is interesting. I want to interrogate that and be like, brain, why is that the story you have there, huh? Huh?

+ +

STEPH: I really appreciate what you're saying, though, because that makes sense to me. I understand when you are in that earlier stage, there's enough to do that that feels correct. Versus that added benefit of having a reduced workweek does benefit or could benefit larger companies who are looking to hire more heavily, or they're also concerned about retention or just helping their people address feelings of burnout. So I really appreciate that perspective because that also rings true.

+ +

So along this whole conversation around wellness and how we can help people work more sustainable hours, there's a particular book that I've read that I've been really excited to share and chat with you about. It's called Burnout: The Secret to Unlocking the Stress Cycle. It's written by two sisters, Emily and Amelia Nagoski. And they really talk through the impact that stress has on us and then ways to work through that.

+ +

And specifically, they talk about completing the stress cycle. And I found this incredibly useful for me because I have had weeks where I have just worked hard Monday through Friday. I've gotten to the end of my day Friday, and I'm like, great, I'm done. I've made it. I can just relax. And I walk away from work, and I can't relax. And I'm just like, I feel sick. I feel not good.

+ +

Like, I thought I would walk away from work, and I would just suddenly feel this halo of relaxation, and everything would be wonderful. But instead, I just feel a bit ill, and I've never understood that until I was reading their book about completing the stress cycle. Have you ever had moments like that?

+ +

CHRIS: It has definitely happened to me at various points, yes.

+ +

STEPH: That makes me feel better because I haven't really chatted about this with someone. So until I read this book and I was like, oh, maybe this is a thing, and it's not just me, and this is something that people are experiencing. So to speak more about completing the stress cycle, they really highlight that stress and feelings, capital F feelings, can cause physiological symptoms. And so it's not just something that we are mentally processing, but we are physically processing the stress that we feel.

+ +

And there's a really big difference between stressors and stress. So a stressor could be something like an unmeetable deadline. It could be family. It could be money concerns. It could be your morning commute, anything that increases your stress level. And during that, there's a very physical process that happens to your body anytime there's a perceived threat. And it's really helpful to us because it's frankly what triggers our fight, flight, or freeze response. And our bodies receive a rush of adrenaline and cortisol, which essentially, if we're using that flight response, that's going to help us run. And a number of the processes in our system will essentially go into a state of hibernation because everything in our body is very focused on helping us run or do the thing that we think is going to save our life in that moment.

+ +

The problem is our body doesn't know the difference between what's more of a mental threat versus what is a truly physical threat. So this is the difference between your stress and your stressors. So in more of a physical threat, if there's a lion that you are running from, that is the stressor, but then the stress is everything that you still feel after you have run from that lion.

+ +

So you encounter a lion, you run. You make it back to your group of people where you are safe, and you celebrate, and you dance, and you hug. And that is completing the stress cycle because you are essentially processing all of that stress. And you are telling your body in a body-focused language that I am safe now, and everything is fine. So you can move back, and anything that was in a hibernation state, all of that dump of adrenaline and cortisol can be worked out of your system, and everything can go back to a normal state.

+ +

Most of us aren't encountering lions, but we do encounter jerks in meetings or really stressful commutes. And whenever we have survived that meeting, or we've gotten through our commute to the other side, we don't have that moment of celebration where we really let our body know that hey, we've made it through that moment of stress, and we are away from that stressor, and we can actually process everything.

+ +

So if you're interested in this, the book's really great. It talks about ways that you can process that stress and how important it is to do so. Otherwise, it will literally build up in your system, and it can make you sick. And it will manifest in ways that will let us know that we haven't dealt with that stress.

+ +

And one of the top methods that they recommend is exercise and movement. That's a really great way to let your body know that you are no longer in an unsafe state, and your body can start to relax. There's also a lot of other great ways. Art is a really big one. It could be hugging someone. It could be calling someone that you love. There are a number of ways that you can process it. But I hadn't recognized how important it is that once you have removed yourself from a stressor, that doesn't necessarily just mean you're done, and you can relax. You actually have to go through that physical process, and then you can relax.

+ +

So I started incorporating that more into my day that when I'm done with work, I always find something to do, and it's typically to go for a walk, or it's go for a run. And I have found that now I really haven't felt that ill-feeling where I'm trying to relax, but I just feel sick. Saying that out loud, I feel like I'm a mess on Fridays. [chuckles]

+ +

CHRIS: I feel like you're human. It was interesting when you asked the question at the beginning. You were like, "Is this a thing that other people experience?" And my answer was certainly, yes; I have experienced this. I think there's something about me that I think is useful where I don't think I'm special at all on any axis whatsoever. And so whenever there's something that's going on, I'm like, I assume that this is just normal human behavior, which is useful because most of the time it is.

+ +

And this is the sort of thing where if I'm having a negative experience, I will look to the external world to be like, I'm sure other people have experienced this, and let me pull that in. And I've found that really useful for myself to just be like, I’m not special. There's nothing particularly special about me. So let me go look from the entirety of the internet where people have almost certainly talked about this. And I've not read the book that you're describing here, but it does sound like it does a great job of describing this.

+ +

There is a blog post that I found that has stayed in the back of my mind and informed a little bit of my day-to-day approach to this sort of thing which is a blog post by Cal Newport, who I think at this point we've mentioned him a handful of times on the show. But the title of the post is Drastically Reduce Stress with a Work Shutdown Ritual. And it's this very interesting little post where he talks about at the end of your day; you want to close the book on it. I think this is especially pointed now that many of us are working from home. For me, this is a new thing. And so, I've been very intentional with trying to put walks at the beginning and end of my day.

+ +

But in this particular blog post, he describes a routine that he does where he tidies things up and makes his list for the next day. And then he has a particular phrase that he says, which is "schedule shut down, complete." And it's a sort of nonsense phrase. It doesn't even quite make sense grammatically, but it's his phrase that he internalized, and somehow this became his almost mantra for the end of the day.

+ +

And now when he does it, that's like his all right, okay, turned off the brain, and now I can walk away. I know that I've said the phrase, and I only say the phrase when I have properly set things up. And so it's this weird structure that he's built in his mind. But it totally works to quiet those voices that are like, yeah, but what about…Do we think about…Do we complete…And he's got now this magic phrase that he can say. And so I've really loved that.

+ +

For myself, I haven't gotten quite to that level, but I've definitely built the here's how I wind down at the end of the day. Here's what I do with lists and what I do so that I can ideally walk away comfortably. Again, this is one of those situations where I sound like I know what I'm doing or have my act together. This is aspirational me.

+ +

Day-to-day me is a hot mess like everybody else. [laughs] And this is just what I...when I do this, I feel better. Most of the time, I don't do this because I forget it, or because I'm busy, or because I'm stressed, [chuckles], and so I don't do the thing that reduces stress, you know, human stuff. But I really enjoyed that post.

+ +

STEPH: I haven't heard that one. I like a lot of Cal Newport's work, but I haven't read that particular blog post. Yeah, I think the idea of completing the stress cycle has helped me tremendously because by giving it a name like completing the stress cycle has been really helpful for me because working out is important to me. It's something that I enjoy, but it's also one of those things that's easy to get bumped. It is part of my wellness routine. And so, if I'm really busy, then I will bump it from the list. And then it's something that then doesn't get addressed.

+ +

But recognizing that this is also important to my productivity, not to just this general idea of wellness, has really helped me recenter how important this is and to make sure that I recognize hey, it's been a stressful day. I need to get up and move. That is a very important part of my day. It is not just part of an exercise routine, but this is something that I need to do to close out my day to then make sure I have a great day tomorrow.

+ +

So bringing it back, it's been a week that's been filled with a lot of discussions around burnout and then ways that we can measure it and then also address it. And I've really enjoyed reading this book. So I'll be sure to drop a link in the show notes. On that note, shall we wrap up?

+ +

CHRIS: Schedule shut down, complete. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Chris talks feature flags featuring Flipper (Say that 3x fast!), and Steph talks reducing stress by a) having a work shutdown ritual and b) the fact that thoughtbot is experimenting with half-day Fridays. (Fri-yay?)

+ + + +

Transcript:

+ +

STEPH: Hey, do you know that we could have an in-person recording at the end of October?

+ +

CHRIS: I do. Yes, I'm planning. That is in the back of my head. I guess I hadn't said that to you yet. But I'm glad that we have separately had the same conversation, and we've got to figure that out, although I don't know how to do noise cancellation and whatnot in the room. [laughs] How do we...we'll have to figure it out. Like, put a blanket in between us but so that we can see across it, but it absorbs sound in the middle. It's weird. I don't know how to do stuff. Just thinking out loud here.

+ +

STEPH: We'll just be in the same place but still different rooms. So it'll feel no different.

+ +

[laughter]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, what's new in your world?

+ +

CHRIS: Feature flags. Feature flags are an old favorite, but they have become new again in the application that I'm working on. We had a new feature that we were building out. But we assumed correctly that it would be nice to be able to break it apart into smaller pieces and sort of deliver it incrementally but not necessarily want to expose that to our end users. And so, we opted with that ticket to bring along the feature flag system.

+ +

So we've introduced Flipper, in particular, which is a wonderful gem; it does the job. We're using the ActiveRecord adapter. All that kind of makes sense, happy about that. And so now we have feature flags. But it was one of those mindset shifts where the minute we got feature flags, I was like, yes, okay, everything behind a feature flag. And we've been leaning into that more and more, and it really is so nice and so freeing, and so absolutely loving it so far.

+ +

STEPH: I'm intrigued. You said, "Everything behind a feature flag." Like, is it really everything or? Yeah, tell me more.

+ +

CHRIS: Not everything. But at this point, we're still very early on in this application, so there are fundamental facets of the platform, different areas of what users can do. And so the actual stuff that works and is wired up is pretty minimal, but we want to have a little more surface area built out in the app for demo purposes, for conversations that are happening, et cetera.

+ +

And so, we built out a bunch of new pages to represent functionality. And so there are sidebar links, and then the actual page itself, and routing, and all of the things that are associated with that, and so all of those have come in. I think there are five new top-level nav sections of the platform that are all introduced behind a feature flag right now. And then there's some new functionality within existing pages that we've put behind feature flags. So it's not truly every line of code, but it's basically the entry point to all new major features we're putting behind a feature flag.

+ +

STEPH: Okay, cool. I'm curious. How are you finding that in terms of does it feel manageable? Do you feel like anybody can go into the UI and then turn on feature flags for demos and feel confident that they know what they're turning on and off?

+ +

CHRIS: We haven't gotten to that self-serve place. At this point, the dev team is managing the feature flags. So on production, we have an internal group configured within Flipper. So we can say, "Ship this feature for all internal users so that we can do testing." So there is a handful of us that all have accounts on production. And then on staging, we have a couple of representative users that we've been just turning everything on for so that we know via staging we can act as that user and then see the application with all of the bells and whistles.

+ +

Down the road, I think we're going to get more intentional with it, particularly the idea of a demo account. That's something that we want to lean into. And for that user, we'll probably be turning on certain subsets of the feature flags. I think we'll get a little more granular in how we think about that. For now, we're not as detailed in it, but I think that is something that we want to expand as we move forward.

+ +

STEPH: Nice. Yeah, I was curious because feature flags came up in our recent retro with the client team because we've gotten to a point where our feature flags feel complex enough that it's becoming challenging and not just from the complexity of the feature flags but also from the UI perspective. Where it feels challenging for users to understand how to turn a feature on, exactly what that impacts, and making sure that then they're not changing developer-focused feature flags, so those are the feature flags that we're using to ship a change but then not turn it on until we're ready. It is user-facing, but it's something that should be managed more by developers as to when we turn it on or off. So I was curious to hear that's going for you because that's something that we are looking into.

+ +

And funnily enough, you asked me recently, "Why aren't y'all using Flipper?" And I didn't have a great answer for you. And that question came up again where we looked at each other, and we're like, okay, we know there was a really good reason we didn't use Flipper when we first had this discussion. But none of us can remember, or at least the people in that conversation couldn't remember. So now we're asking ourselves the question of we've made it this far. Is it time to bring in Flipper or another service? Because we're getting to the point that we're starting to build too much of our own feature flag system.

+ +

CHRIS: So did you uncover an answer, or are you all just agreeing that the question makes sense?

+ +

STEPH: Agreeing that the question makes sense. [laughs]

+ +

CHRIS: That's the first step on a long journey to switching from internal tooling to somebody else managing that for you.

+ +

STEPH: Yeah, because none of us could remember exactly. But it was funny because I was like, am I just forgetting something here when you asked me that? So I felt validated that others were like, "Oh yeah, I remember that conversation. But I too can't recall why we didn't want to use Flipper in the moment or a similar service."

+ +

CHRIS: I'll definitely be interested to hear if you do end up trying to migrate off to another system or find a different approach there or if you do stick with the current configuration that you have. Because those projects they're the sort of sneaky ones that it's like, oh, we've been actually relying on this for a while. It's a core part of our infrastructure, and how we do the work, and the process, and how we deploy. That's a lot. And so, to switch that out in-flight becomes really difficult. It's one of those things where the longer it goes on, the harder it is to make that change. But at some point, you sometimes make the decision to make it. So I will be very interested to hear if you do make that decision and then, if so, what that changeover process looks like.

+ +

STEPH: Yeah, totally. I'll be sure to keep you up to date as we make any progress or decisions around feature flags.

+ +

CHRIS: But yeah, your questions around management and communication of it that is a thing that's in the back of my mind. We're still early enough in our usage of it, and just broadly, how we're working, we haven't really felt that pain yet, but I expect it's coming very soon. And in particular, we have functionality now that is merged and is part of the codebase but isn't fully deployed or fully released rather. That's probably the correct word. We have not fully released this functionality, and we don't have a system right now for tracking that.

+ +

So I'm thinking right now we're using Trello for product management. I'm thinking we want another column that is not entirely done but is tracking the feature flags that are currently in flight and just use that as a place to gather communication. Do we feel like this is ready? Let's dial this up to 50%, or let's enable it for this beta group or whatever it is to sort of be able to communicate that. And then ideally, also as a way to track these are the ones that are active right now. You know what? We feel like this one's ready. So do the code change so that we no longer use the feature flag, and then we can actually turn it off. Currently, I feel like I can defer that for a little while, but it is something that's in the back of my mind.

+ +

And then, of course, I nerd sniped myself, and I was like, all right, how do I grep the codebase for all the feature flags that we're using? Okay. There are a couple of different patterns as to how we're using…You know what? I think I actually need an AST-based parser here, and I need to use the Visitor...You know what? Never mind. Stop it. Stop it. [laughs] It was one of those where I was like...I was doing this not during actual work hours. It was just a question in my mind, and then I started to poke at it. I was like, oh, this could be fun. And then I was like, no, no, no, stop it. You need to go read a book or something. Calm down.

+ +

STEPH: As part of the optimization around our feature flag system that we've created, we've added a few enhancements, which I think is also one of the reasons we're starting to question how far we want to go in this direction. One of them is we want a very easy way to track what's turned on and what's turned off for an environment. So we have a task that will easily check, or it prints out a really nice list of these are all your flags, and this is the state that they're in. And by using the system that we have, we have one file that represents...well, you mentioned migration because we're migrating from the old system to this new one. So it's still a little bit in that space of where we haven't fully moved over. So now, moving over to a third thing like Flipper will be even more interesting because of that.

+ +

But the current system, we have a file that lists all the feature flags and a really nice description that goes with it, which I know is supported by Flipper and other services as well. But having that one file does make it nice where you can just scan through there and see what's in use. I really think it's the UI and the challenges that the users are facing and understanding what a feature flag does, and which ones they should turn off, and which ones they shouldn't touch that that's the point where we started questioning okay, we need to improve the UI.

+ +

But to improve the UI, do we really want to fully embrace our current system and make those improvements, or is now that time that we should consider moving to something else? Because Flipper already has a really nice UI. I think there is a free tier and a paid tier with Flipper, and the paid tier has a UI that ships.

+ +

CHRIS: There's definitely a distinct thing, Flipper Cloud, which is their hosted enterprise-y solution, and that's the paid offering. But Flipper just the core gem there's also Flipper web, I want to say is what it is, or Flipper UI. And I think it's an engine that you mount within your Rails app and that displays a UI so that you can manage things, add groups and teams. So we're definitely using that. I've got my eye on Flipper Cloud, but I have some fundamental questions around I like to keep my data in the system, and so this is an external other thing. And what's the synchronization? I haven't really even looked into it like that. But I love that Flipper exists within our application.

+ +

One of the niceties that Flipper Cloud does have is an audit history, which I think is interesting just to understand over time who changed what for what reasons? It's got the ability to roll back and maintain versions and whatnot. So there are some things in it that definitely look very interesting to me. But for now, the open-source, free version of Flipper plus Flipper UI has been plenty for us.

+ +

STEPH: That's cool. I didn't know about the audit feature.

+ +

CHRIS: Yeah. It definitely feels like one of those niceties to have for a more enterprise offering. So I could see myself talking me into it at some point but not quite yet. On that note though, so feature flags we introduced a week and a half, something like that, ago, and we've been leaning into them more and more. But as part of that, or in the back of my mind, I've wanted to go to continuous deployment.

+ +

So we had our first official retro this week. The project is growing up. We're becoming a lot of things. We used retro to talk about continuous deployment, all of these things that feel very real. Just to highlight it, retro is super important. And the fact that we haven't had one until now is mainly because up till now, it’s been primarily myself and another developer. So we've been having essentially one-on-ones but not a more formal retro that involves others.

+ +

At this point, we now have myself and two other developers that are working on the project, as well as someone who's stepped into the role of product manager. So we now have communication collaboration. How are we doing the work? How are we shipping features and communicating about bugs and all of that? So now felt like the right time to start having that more formal process. So now, every two weeks, we're going to have a retro, and hopefully, through that, retro will do the magic that retro can do at its best which is help us get better at all the things that we're doing.

+ +

But yeah, one of the core things in this particular one was talking about moving to continuous deployment. And so I am super excited to get there because I think, much like test-driven development, it's one of those situations where continuous deployment puts a lot of pressure on the development process. Everything that is being merged needs to be ready to go out into production. And honestly, I love that as a constraint because that will change how you build things. It means that you need to be a little more cautious. You can put something behind a feature flag to protect it. You decouple the idea of merging and deploying from releasing. And I like that distinction.

+ +

I think that's a really meaningful distinction because it makes you think about what's the entry point to this feature within the codebase? And it's, I think, actually really nice to have fewer and more intentional entry points into various bits of functionality such that if you actually want to shut it off in production, you can do that. That's more straightforward. I think it encourages an intentional coupling, maybe not a perfect decoupling but an intentional coupling within the system.

+ +

So I'm very excited to explore it. I think feature flags are going to be critical for it, and I think also observability, and monitoring, and logging, and all those things. We need to get really good at them so that if anything does go wrong when we just merge and deploy, we want to know if anything goes wrong as quickly as possible. But overall, I'm super excited about all of the other niceties that fall out of it.

+ +

STEPH: [singing] I wanna know what's turned on, and I want you to show me. Is that the song you're singing to Flipper? [laughs]

+ +

CHRIS: [laughs]

+ +

STEPH: Sorry, friends. I just had to go there.

+ +

CHRIS: That was just in your head. You had that, and you needed to get it out. I appreciate it. [laughter] Again, I got Flipper UI, so that's not the question I'm asking. I think that's the question you have in your heart.

+ +

STEPH: [laughs]

+ +

Mid-roll Ad

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city.

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: That's funny about the CI deployment adding pressure to the development process because you're absolutely right. But I see it as such a positive and improvement that I don't really think about the pressure that it's adding. And I just think, yes, this is awesome, and I want this to happen and if there are steps that we have to take in that direction.

+ +

It dawned on me that what you said is very true, but I've just never really thought about it from that perspective about the pressure. Because I think the thing that does add more pressure for me is figuring out what can I deploy, or do I need to cherry-pick commits? What does that look like? And going through that whole cycle and stress is more stressful to me than figuring out how do we get to continuous deployments and making sure that everything is in a safe space to be deployed?

+ +

CHRIS: That's the dream. I'm going to see if I can live it. I'll let you know how it goes. But yeah, that's a bit of what's up in my world. What else is going on in your world other than some lovely singing?

+ +

STEPH: Oh, there's always lots of singing. It's been an interesting week. It's been a mix of some hiring work. Specifically, we are helping our client team build their development team. So we have been helping them implement a hiring process. And then also going through technical interviews and then going through different stages of that interview process. And that's been really nice. I haven't done that specifically for a client team where I helped them build a hiring pipeline from scratch and then also conduct those interviews.

+ +

And one thing that stood out to me is that rotations are really important to me and specifically that we don't ask for volunteers. So as we were having candidates come through and then they were ready to schedule an interview, then we are reaching out to the rest of the development team and saying, "Hey, we have this person. They're going to be scheduled at this time. Who's available? Who's interested? I'm looking for volunteers." And that puts pressure on people, especially someone that may be more empathetic to feel the need to volunteer. So then you can end up having more people volunteer than others.

+ +

So we've established a rotation to make sure that doesn't happen, and people are assigned as it becomes their next turn to conduct an interview. So that's been a lot of fun to refine that process and essentially make it easier. So the rest of the development team doesn't have to think about the hiring. But it still has an easy way of just saying, "Hey," and tapping someone to say, "Hey, it's your turn to run an interview."

+ +

The other thing I've been working out is figuring out how to measure an experiment. So we at thoughtbot are running an experiment where we're looking to address some of the concerns around sustainability and people feeling burned out. And so we have introduced half-day Fridays, more specifically 3.5 Fridays, as our half-day Fridays just to help everybody be certain about what a half-day looks like.

+ +

And then also, you can choose your half-day. Everybody works different schedules. We're across different time zones, so just to make sure it's really clear for folks and that they understand that they don't need to work more than those hours, and then they should have that additional downtime. And that's been amazing. This is the second Friday of the experiment, and we're doing this for nine Fridays straight.

+ +

And one of the questions that came up was, well, how do we know we did a good thing? How do we know that we helped people in terms of sustainability or addressing some of the feelings that they're having around burnout? And so I've collaborated with a couple of other thoughtboters to think through of a way to measure it. It turns out helping someone measure their wellness is incredibly complex. And so we went for a fairly simple approach where we're using an anonymous survey with a number of questions.

+ +

And those questions aren't really meant to stand up to scientific scrutiny but more to figure out how the team is feeling at the time that they fill out the survey and then also to understand how the reduced weekly hours have impacted their schedule. And are people working extra hours to then accommodate the fact that we now have these half Fridays? So do you feel pressured that because you can't work a full day on Friday that you are now working an extra hour or two Monday through Thursday to accommodate that time off? So that survey just went out today.

+ +

And one of the really interesting parts (I just haven't had to create content for a survey in a while.) was making sure that I'm not introducing leading questions or phrasing things in a very positive or negative light since that is a bias that then people will pick up on. So instead of saying, "I find it easy to focus at work," and then having like a multiple choice of true, always, never, that kind of thing, instead rephrasing the question to be, "Are you able to focus during work hours?" And then you have a scale there.

+ +

Or instead of asking someone how much energy they have, maybe it's something like, "Do you experience fatigue during the day?" Or instead of asking someone, "Are you stressed at work?" because that can have a more negative connotation. It may lead someone to feel more negatively as they are assessing that question. Then you can say, "How do you feel when you're at work?" And then you can provide those answers of I'm stressed, slightly stressed, neutral, slightly relaxed, and relaxed.

+ +

So it generated some interesting conversations around the importance of how we phrase questions and how we collect feedback. And I really enjoyed that process, and I'm really looking forward to seeing what folks have to say. And we're going to have three surveys total. So we have one that's early on in the experiment since we're only two Fridays in. We'll have one middle experiment survey go out, and then we'll have one at the end once we're done. And then hopefully, everybody's responses will then help us understand how the experiment went and then make a decision going forward.

+ +

I'll be honest; I’m really hoping that this becomes a trend and something that we stick with. It is a professional goal of mine to slowly reduce the hours that I work each week or quickly; it doesn't have to be slowly. But I really like the four-day workweek. It's something that I haven't done, but I've been reading about it a fair amount lately. I feel like I've been seeing more studies conducted recently becoming published, and it's just very interesting to me.

+ +

I had some similar concerns of how am I still going to be productive? My to-do list hasn't changed, but my hours are changing. So how am I still going to get everything done? And does it make sense for me to still get paid the same amount of money if I'm only working four out of the five days? And I had lots of questions around that, and the studies have been very enlightening and very positive in the outcome of a reduced workweek, not just for the individuals but for the companies as well.

+ +

CHRIS: It's such an interesting space and exploration. The way that you're framing the survey sounds really great. It sounds like you're trying to be really intentional around the questions that you're asking and not being leading and whatnot. That said, it is one of the historically hard problems trying to quantify this and trying to actually boil it down.

+ +

And there are so many different axes even that you're measuring on. Is it just increased employee happiness? Is it retention that you're talking about? Is it overall revenue? There are so many different things, and it's very tricky. I'm super interested to hear the results when you get those. So you're doing what sounds like more of a qualitative study like, how are you feeling? As opposed to a more quantitative sort of thing, is that right?

+ +

STEPH: Yes, it's more in the realm of how are you feeling? And are you working extra hours, or are you truly taking the time off?

+ +

CHRIS: Yeah, I think it's really hard to take something like this and try and get it into the quantitative space, even though like, oh yeah, if we could have a number, if it used to be two and now it's four, fantastic. We've doubled whatever that measure is. I don't know what the unit would be on this arbitrary number I made up. But again, that's the hard thing and probably not feasible at all. And so it makes sense the approach that you're taking. But it's super difficult. So I'm very interested to hear how that goes.

+ +

More generally, the four-day workweek thing is such a nice idea. We should do that more. I'm trying to think how long I did that. So during the period that I was working freelance, I think there were probably at least five months where I did just a true four-day workweek. Fridays were my own. It was fantastic. Granted, I recorded the podcast with you. But that day was mine to shape as I wanted.

+ +

And I found it was a really nice decompression period having that for a number of weeks in a row. And just getting to take care of personal stuff that I hadn't been and just having that extra little bit of space and time. And it really was wonderful. Now I'm working full five days a week, and my Fridays aren't even investment days, so I don't know what I'm doing over here.

+ +

But I agree. I really like that idea, and I think it's a wonderful thing. And it's, I don't know, sort of the promise of this whole capitalism adventure we're supposed to go on, increasing productivity. And wasn't this the promise the whole time, everybody, so I am intrigued to see it being explored more, to see it being discussed. And what you're talking about of it's not just good for the employees, but it's also great for the companies. You're getting people that are more engaged on the days that they're working, which feels very true to me.

+ +

Like, on a great day, I can do some amazing work. On a terrible day, I can do mediocre to bad work. It is totally possible for me to do something that is actively detrimental. Like, I introduce a bug that is going to impact a bunch of customers. And the remediation of that is going to take many more hours. That is totally a realistic thing. I think we often think of productivity in terms of are you at zero or some amount more than zero? But there is definitely another side of that. And so the cost of being not at your best is extremely high in my mind. And so anything we can do to improve that.

+ +

STEPH: There's a recent study from a non-profit company called Autonomy that published some research called Going Public: Iceland's Journey to a Shorter Working Week. It's very interesting. And a number of people in my social circle have shared it. And that's one of the reasons that I came across it. And they commented in there that one of the reasons...I hope I'm getting this right, but we'll link to it in case I've gotten it a bit wrong.

+ +

But one of the reasons that Iceland was interested or open to this idea of moving workers to a shorter workweek is because they were struggling with productivity and where people were working a lot of hours, but it still felt like their productivity was dropping. So then Autonomy ran this study to help figure out are there ways to improve productivity? Will shortening a workweek actually lead to higher productivity?

+ +

And there was a statement in there that I really liked where it talks about the more hours that we work; we’re actually lowering our per hour productivity which rings so true for me. Because I am one of those individuals where I'm very stubborn, and so if I'm stuck on something, I will put so many hours into trying to figure it out. But at some point, I have to just walk away, and if I do, I will solve it that much faster. But if I just try to use hours as my way to chip away at a problem, then that's not going to solve it. And my ability to solve that problem takes exponentially more time than if I had just walked away and then come back to the problem fresh and engaged.

+ +

And some of the case studies I admired the way that they tackled the problem. They would essentially pay the company. So the company could reduce the hours for certain employees so then they could run the experiment. So if they reduced employees to say 32 hours but the company didn't actually want to stop working at 32 hours and they wanted to keep going, so then they brought in other people to work the remaining eight hours. Then as part of that study, they would pay the company to help them stay at their current level of productivity or current level of hours. This way, they could conduct the study. And I thought that was a really neat idea.

+ +

I do have lots of questions still around the approach itself because it is how do you reduce your to-do list, essentially? So just because you dropped to a four-day workweek. So essentially, you have to just say less stuff gets done. Or, as these case studies promise, they're saying you're actually going to be more productive. So you will still continue to get a lot of your work done. I'm curious about that. I'd like to track my own productivity and see if I feel similarly.

+ +

And then also, who is this for? Is this for everybody? Does everybody get to move to a four-day workweek? Is this for certain companies? Is it for certain jobs? Ideally, this is for everybody because there are so many health benefits to this, but I'm just intrigued as to who this is for, who it impacts, how can we make it available for everyone? And is the dream real that I can work four days a week and still feel as productive, if not more productive, and healthier, and happier as I do when working five days a week?

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: I remember there was an extended period where working remote was this unique benefit that some organizations had. They had adopted that mode. They were async, and remote, and all of these wonderful things. And it became this really interesting selling point for those companies. Now the pandemic obviously pushed public opinion and everything on that in a pretty significant way such that it's a much more common thing. And so, as a result, I think it's less of a differentiator now. It used to be a way to help with recruiting.

+ +

I wonder if there are organizations that are willing to take this, try it out, see that they are still close to as productive. But if it means that hiring is twice as easy, that is absolutely...especially if it is able to double your ability to hire, that is incredibly valuable or retention similarly. If you can increase retention or if you can make it easier to hire, the value of that is so, so high.

+ +

And it's interesting in my mind because there's sort of a gold rush on that. That's only true for as long as a four-day workweek is a unique benefit of working at the organization. If this is actually the direction that everything's going and eventually everyone's going to settle to that, then if you wait too long to get there, then you're going to miss all the benefits. You're going to miss that particular benefit of it.

+ +

And so I do wonder, would it be advantageous to organizations...I'm thinking about this now. Maybe this is the thing I have to do. But would it be advantageous to be that organization as early on as possible and try to get ahead of the curve and use that to hire more easily, retain more easily? Now that I say it all out loud, I'm sold. All right. I got to do this.

+ +

STEPH: Yeah, I think that's a great comparison of where people are going to start to look for those types of benefits. And so, if you are one of the early adopters and you have the four-day workweek or a reduced workweek in general, then people will gravitate towards that benefit. And it's something that people can use to really help with hiring and retention. And yeah, I love it.

+ +

You are CTO. So you have influence within your company that you could push for the four-day workweek if you think that's what you want to do. And I would be really intrigued to hear how that goes and how you feel if you...well, you've done it before where you've worked four days a week. So applying that to your current situation, how does that feel?

+ +

CHRIS: Now you're actually holding me accountable to the things that I randomly said in passing. But it's interesting. So we're so early stage, and there's so much small work to do. There's all…oh, got to set up a website. We've got to do this. We've got to build that integration. There's just kind of scrambling to be done.

+ +

And so there's a certain version in my mind that maybe we're in a period of time where additional hours are actually useful. There's a cost to them. Let's be clear about that. And so how long that will remain true, I'm not sure. I could see a point perhaps down the road where we achieve a little bit closer to steady-state maybe, who knows? It depends on how fast growth is and et cetera, a lot of other things.

+ +

So I'm not sure that I would actually lead with this experiment myself, given where the organization is at right now. But I could see an organization that's at a little bit more of a steady-state, that's growing more incrementally, that is trying to think really hard about things like hiring and retention. If those were bigger questions in my mind, then I think I would be considering this more pointedly. But for now, I'm like, I kind of just got to do a bunch of stuff. And so my brain is telling me a different story, but it is interesting. I want to interrogate that and be like, brain, why is that the story you have there, huh? Huh?

+ +

STEPH: I really appreciate what you're saying, though, because that makes sense to me. I understand when you are in that earlier stage, there's enough to do that that feels correct. Versus that added benefit of having a reduced workweek does benefit or could benefit larger companies who are looking to hire more heavily, or they're also concerned about retention or just helping their people address feelings of burnout. So I really appreciate that perspective because that also rings true.

+ +

So along this whole conversation around wellness and how we can help people work more sustainable hours, there's a particular book that I've read that I've been really excited to share and chat with you about. It's called Burnout: The Secret to Unlocking the Stress Cycle. It's written by two sisters, Emily and Amelia Nagoski. And they really talk through the impact that stress has on us and then ways to work through that.

+ +

And specifically, they talk about completing the stress cycle. And I found this incredibly useful for me because I have had weeks where I have just worked hard Monday through Friday. I've gotten to the end of my day Friday, and I'm like, great, I'm done. I've made it. I can just relax. And I walk away from work, and I can't relax. And I'm just like, I feel sick. I feel not good.

+ +

Like, I thought I would walk away from work, and I would just suddenly feel this halo of relaxation, and everything would be wonderful. But instead, I just feel a bit ill, and I've never understood that until I was reading their book about completing the stress cycle. Have you ever had moments like that?

+ +

CHRIS: It has definitely happened to me at various points, yes.

+ +

STEPH: That makes me feel better because I haven't really chatted about this with someone. So until I read this book and I was like, oh, maybe this is a thing, and it's not just me, and this is something that people are experiencing. So to speak more about completing the stress cycle, they really highlight that stress and feelings, capital F feelings, can cause physiological symptoms. And so it's not just something that we are mentally processing, but we are physically processing the stress that we feel.

+ +

And there's a really big difference between stressors and stress. So a stressor could be something like an unmeetable deadline. It could be family. It could be money concerns. It could be your morning commute, anything that increases your stress level. And during that, there's a very physical process that happens to your body anytime there's a perceived threat. And it's really helpful to us because it's frankly what triggers our fight, flight, or freeze response. And our bodies receive a rush of adrenaline and cortisol, which essentially, if we're using that flight response, that's going to help us run. And a number of the processes in our system will essentially go into a state of hibernation because everything in our body is very focused on helping us run or do the thing that we think is going to save our life in that moment.

+ +

The problem is our body doesn't know the difference between what's more of a mental threat versus what is a truly physical threat. So this is the difference between your stress and your stressors. So in more of a physical threat, if there's a lion that you are running from, that is the stressor, but then the stress is everything that you still feel after you have run from that lion.

+ +

So you encounter a lion, you run. You make it back to your group of people where you are safe, and you celebrate, and you dance, and you hug. And that is completing the stress cycle because you are essentially processing all of that stress. And you are telling your body in a body-focused language that I am safe now, and everything is fine. So you can move back, and anything that was in a hibernation state, all of that dump of adrenaline and cortisol can be worked out of your system, and everything can go back to a normal state.

+ +

Most of us aren't encountering lions, but we do encounter jerks in meetings or really stressful commutes. And whenever we have survived that meeting, or we've gotten through our commute to the other side, we don't have that moment of celebration where we really let our body know that hey, we've made it through that moment of stress, and we are away from that stressor, and we can actually process everything.

+ +

So if you're interested in this, the book's really great. It talks about ways that you can process that stress and how important it is to do so. Otherwise, it will literally build up in your system, and it can make you sick. And it will manifest in ways that will let us know that we haven't dealt with that stress.

+ +

And one of the top methods that they recommend is exercise and movement. That's a really great way to let your body know that you are no longer in an unsafe state, and your body can start to relax. There's also a lot of other great ways. Art is a really big one. It could be hugging someone. It could be calling someone that you love. There are a number of ways that you can process it. But I hadn't recognized how important it is that once you have removed yourself from a stressor, that doesn't necessarily just mean you're done, and you can relax. You actually have to go through that physical process, and then you can relax.

+ +

So I started incorporating that more into my day that when I'm done with work, I always find something to do, and it's typically to go for a walk, or it's go for a run. And I have found that now I really haven't felt that ill-feeling where I'm trying to relax, but I just feel sick. Saying that out loud, I feel like I'm a mess on Fridays. [chuckles]

+ +

CHRIS: I feel like you're human. It was interesting when you asked the question at the beginning. You were like, "Is this a thing that other people experience?" And my answer was certainly, yes; I have experienced this. I think there's something about me that I think is useful where I don't think I'm special at all on any axis whatsoever. And so whenever there's something that's going on, I'm like, I assume that this is just normal human behavior, which is useful because most of the time it is.

+ +

And this is the sort of thing where if I'm having a negative experience, I will look to the external world to be like, I'm sure other people have experienced this, and let me pull that in. And I've found that really useful for myself to just be like, I’m not special. There's nothing particularly special about me. So let me go look from the entirety of the internet where people have almost certainly talked about this. And I've not read the book that you're describing here, but it does sound like it does a great job of describing this.

+ +

There is a blog post that I found that has stayed in the back of my mind and informed a little bit of my day-to-day approach to this sort of thing which is a blog post by Cal Newport, who I think at this point we've mentioned him a handful of times on the show. But the title of the post is Drastically Reduce Stress with a Work Shutdown Ritual. And it's this very interesting little post where he talks about at the end of your day; you want to close the book on it. I think this is especially pointed now that many of us are working from home. For me, this is a new thing. And so, I've been very intentional with trying to put walks at the beginning and end of my day.

+ +

But in this particular blog post, he describes a routine that he does where he tidies things up and makes his list for the next day. And then he has a particular phrase that he says, which is "schedule shut down, complete." And it's a sort of nonsense phrase. It doesn't even quite make sense grammatically, but it's his phrase that he internalized, and somehow this became his almost mantra for the end of the day.

+ +

And now when he does it, that's like his all right, okay, turned off the brain, and now I can walk away. I know that I've said the phrase, and I only say the phrase when I have properly set things up. And so it's this weird structure that he's built in his mind. But it totally works to quiet those voices that are like, yeah, but what about…Do we think about…Do we complete…And he's got now this magic phrase that he can say. And so I've really loved that.

+ +

For myself, I haven't gotten quite to that level, but I've definitely built the here's how I wind down at the end of the day. Here's what I do with lists and what I do so that I can ideally walk away comfortably. Again, this is one of those situations where I sound like I know what I'm doing or have my act together. This is aspirational me.

+ +

Day-to-day me is a hot mess like everybody else. [laughs] And this is just what I...when I do this, I feel better. Most of the time, I don't do this because I forget it, or because I'm busy, or because I'm stressed, [chuckles], and so I don't do the thing that reduces stress, you know, human stuff. But I really enjoyed that post.

+ +

STEPH: I haven't heard that one. I like a lot of Cal Newport's work, but I haven't read that particular blog post. Yeah, I think the idea of completing the stress cycle has helped me tremendously because by giving it a name like completing the stress cycle has been really helpful for me because working out is important to me. It's something that I enjoy, but it's also one of those things that's easy to get bumped. It is part of my wellness routine. And so, if I'm really busy, then I will bump it from the list. And then it's something that then doesn't get addressed.

+ +

But recognizing that this is also important to my productivity, not to just this general idea of wellness, has really helped me recenter how important this is and to make sure that I recognize hey, it's been a stressful day. I need to get up and move. That is a very important part of my day. It is not just part of an exercise routine, but this is something that I need to do to close out my day to then make sure I have a great day tomorrow.

+ +

So bringing it back, it's been a week that's been filled with a lot of discussions around burnout and then ways that we can measure it and then also address it. And I've really enjoyed reading this book. So I'll be sure to drop a link in the show notes. On that note, shall we wrap up?

+ +

CHRIS: Schedule shut down, complete. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!!!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+L6qAJKab + + ]]> + + Chris Toomey + Steph Viccari + + + 309: Naming the Change + https://bikeshed.thoughtbot.com/309 + 57b08748-a502-488f-a952-07a6d7a91f0b + Tue, 21 Sep 2021 12:00:00 -0400 + thoughtbot + + full + thoughtbot + Steph talks about a new GitHub feature and Twitter account (@RubyCards) she's really excited about and Chris talks about his new job as a CTO of a startup and shifting away from writing code regularly. + 35:28 + no + + + Steph talks about a new GitHub feature and Twitter account (@RubyCards (https://twitter.com/RubyCards)) she's really excited about and Chris talks about his new job as a CTO of a startup and shifting away from writing code regularly. +GitHub (https://docs.github.com/en/codespaces/developing-in-codespaces/web-based-editor) +RubyCards (https://twitter.com/RubyCards) +Resilient Management (https://resilient-management.com/) +The Manager's Path (https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897) +Transcript: +CHRIS: Oh God, my computer is so stupid slow. I need a new computer. +STEPH: Come on, little computer, you can do it. You know you could just buy a new one. You don't have to wait for the fancy-schmancy M1. +CHRIS: I want to wait for the fancy. I want it so bad. +STEPH: [laughs] +CHRIS: Do you know how long I've had this computer? And if I can hold out one more month, I want the fancy stuff. I've waited this long. Why would I give in now when I'm right on the cusp of victory? +STEPH: One more month. I'm going to send you...as a kid, did you ever make those construction… +CHRIS: Oh yeah. +STEPH: They look like chain links bow construction paper. So we would make those for a countdown to special days. I'm going to send you one that's all crumpled and folded in the mail. It would be delightful. And you'll be able to snip off a little chain each day as your countdown to your new fancy-schmancy. [laughs] +CHRIS: I love it. +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? +STEPH: Hey. Well, I just got back from vacation. So getting back to work is what's new in my world. And vacation is nice. I miss it already. But it's also nice to be back, and see everybody, and see what they've been up to. +CHRIS: I've heard wonderful things about vacation. +STEPH: Yeah. Have you had one recently? I know you've been quite busy. +CHRIS: I have. I think it's hard to tell, especially because everything just kind of blends together these days. But I think I took off a few days recently. I haven't had an extended vacation since much earlier on in the summer, I think. And so I think I'm due for one of those sometime in the not too distant future. But it's one of those things where you got to plan it. And you got to think ahead, and I haven't been doing that of late really with anything. So kind of living for the moment, but that's not how you take a vacation. So I got to rethink some strategies here. [chuckles] +STEPH: Yeah, I've been trying to schedule more vacation time just further out. Because then if I don't want to take it, like if I decide that I don't want the staycation or I don't need the day off, then I can just change my mind, and that's pretty easy to do. But I'm like you; if I don't plan it, then I don't feel like I have the energy to plan a vacation, and then it just doesn't happen. So I know that's one thing that I've been doing. +I've also been mentoring or coaching others, just checking in with them to say, "Hey, when's your next vacation? Have you scheduled any days off? Do you want to schedule a day off next month?" And saying that to other people has also been a very helpful reminder to me to do so. +CHRIS: Oh, I like that a lot as a recurring one-on-one question of, so what can you tell me about vacation? What do you got in the works there? Because that's the most important thing, [chuckles] which it kind of is. It's the way that we keep doing the work that we do. +STEPH: And I think so many people just haven't been taking a vacation. I mean, in 2020, we were all locked in and going through a pandemic, so then a lot of people weren't taking those breaks. And so part of it is just reminding people that even if you can't go somewhere, still please take some downtime and just know that you can step away from work and should step away from work. +But for us, we did go somewhere. So we went out to Seattle, which I've never...I've been out to the West Coast, but it's more like I've been out to L.A., Santa Monica. But this time, we went to the Northwest region. We went to Seattle, and we explored and did a lot of hiking and camping around the Northern Cascades and then Mount Rainier. And both of those are amazing. And I've never flown with camping gear, but that went really well. It worked out nice. We had an Airbnb every so often just for showers and having a roof over your head. That's really nice. But for most of the trip, we did a lot of camping and hiking. +CHRIS: That sounds like an awesome trip. +STEPH: Yeah, it was really cool. I'd love to go back to the Olympic National Park because there are just so many national parks that are around Seattle and in Washington that we couldn't begin to do it all. But Olympic National Park is still on my list. And I'm really grateful to have also seen the Northern Cascades and Mount Rainier. +But switching gears a bit, I have something that I'm really excited to share with you because I don't think you've seen it yet. I'm excited to find out if you have. But it's a new GitHub feature that came out, I think about a month ago, but there doesn't seem to have been much fanfare from GitHub about announcing this new feature. And I happened to find out through Twitter because someone else found it, and then they were really excited. And so now I think it's really gaining some more traction. But it still seems like one of those sneaky feature releases, but it's really cool. +So GitHub has added the ability to open up a web-based editor that allows you to view the source code for a repo, view it in syntax, highlighting, make a code change, and commit the change. And it's free for everybody. And there's a couple of ways to get there, but I'll pause there. Have you seen this yet? Have you interacted with it? +CHRIS: I think I've seen it and poked around ever so gently with it. I want to say this is GitHub Codespaces. Is that the name of this feature? +STEPH: Yep. That's it? +CHRIS: Yes. I poked around with it just a tiny bit, and I'm very excited about it. But it's very much in the like, huh, okay, cool; I’ll look at that someday down the road and figure out what I want to do with it. But have you actually dug into it particularly deeply? +STEPH: I used it to make a change for a personal project, just because I wanted to see the whole flow. So I went to a personal project, and there are two ways that you can open it up for anyone that hasn't seen this yet. So you can either press the period button that's on your keyboard, and that will open it up, or you can just alter the URL. So instead of github.com, replace that .com with .dev, and then that will also open up the browser. +And so I made a change to a personal project, and it worked really well, and it commits the change to main. And it was nice. It was easy. In my case, I was just making a change to make a change. I think I actually went to an older project where I was still using the underscore target to force users that when they clicked on a link that it opened a new tab, and I was like, perfect. This is a good thing to just change. And I could do it from my iPad. I didn't have to be at my computer. And it was really nifty. I was very impressed with it. +And they also mentioned that it's very easy to integrate your own VS Code settings and environment. I'm not a heavy VS Code user, so I haven't tried that. But I've heard really positive things about how easy it is to sync your settings between your local VS Code and then GitHub's editor. But overall, it was really easy to use. +CHRIS: That's super cool. My very limited understanding of it is like GitHub has had the ability to edit files and things like that for a while. But it was very much like a simple web editor where it's a big text box that happens to contain the code. And they've added some stuff for like browsing with syntax highlighting and even some context-aware show usage and things like that. But as far as I understand it, this is like a whole VS Code instance in the cloud that is running it. +And then I think what you're saying about you can have your VS Code settings in there, but even your project settings and the ability to run the tests, I'm not sure where the edges of it are. But my understanding with Codespaces it's like this is how your team can develop. Everyone gets one of these Codespaces. You're developing in the cloud. But it does VS Code remote sync type stuff. I'm very intrigued to see where it goes and that idea of...obviously, I like Vim. That's the thing that's probably known and true about me. So I will probably be one of the later adopters of this. +But the idea of being able to bottle up the development environment for your projects and have those settings, and the ability to run the test and all of that packaged up as part of the repository, and then allow people to run with that, especially in the cloud, and be able to carry that with them as they move around, that's really intriguing. And the idea of having this very easy on-ramp, especially for open-source projects and things like that. If you want people to be able to contribute easily but with the linting, and the configuration, and the settings, and all the stuff, well, now you can have that packaged up. And that is very interesting to me. +So I'm super intrigued to see where it goes. Again, I will probably be one of the later adopters of this platform for reasons. But I am super interested, and I continue to like...the work with VS Code is so interesting in the way it keeps expanding out and the language server stuff and now the Codespaces stuff. And it's super interesting developments across the board. +STEPH: Yeah, I'm with you. I don't actually see this replacing my current development that I do day-to-day, but it's more generally nice to have access. So if I needed to make a change and I don't have my laptop or if it's just something small and I don't want to have to go through…I guess essentially, if I don't have my laptop, but I wanted to make a change, then I could do this realistically from something that doesn't have my full local dev setup. +I don't know if you have the ability to run tests. I didn't explore that far as to whether you can actually have access to run those types of commands or processes. I did see some additional notes while reading through GitHub's documentation about this new editor. And they included some notes that talk about how the editor runs entirely in your browser's sandbox. So it doesn't actually clone the repo, but instead, it loads your code by invoking the services API directly from the browser. So then your work is saved in the browser's local storage until you commit it, and then you can persist your changes by then committing it back to the repo. +And because there's no associated compute, you won't be able to build and run your code or use the integrated terminal. Ah, I think that actually answers the question about running tests. So only a subset of extensions can run in the web will appear in the extensions panel and can be installed. So this does impose certain limitations for particular programming languages and full functionality, things that we may need like running tests. +CHRIS: Interesting. That now puts it back more on the uncanny valley for me where it's like, oh, it's just VS Code, except it can't do a bunch of the stuff. So yeah, I'll probably be hanging out in Vim for a while. But again, I'm super interested to see where they can push this and what the browser platform allows, and then how they're able to leverage that and so on and so forth. +STEPH: There is one flow that I was testing out because I was reading someone else mentioned that not only can you use this for looking at source code and then changing that source code but also for a pull request. And so I went to a pull request and changed the URL to dev. And I do have the ability to make changes, but I'm not quite sure if I could commit my changes and if that would go to the branch or how that would work. It wasn't obvious to me how I could save my changes. But it was obvious to me that I could make changes. [laughs] So that part feels weird to me, and I will have to test that out. But I'm going to wait until I have my own PR before I start fooling around [laughs] so I don't ruin somebody else's PR. +CHRIS: Ideally, the worst case is you just push commit to a branch, and commits are reversible. You can throw them away. You can reset, and you can do all sorts of stuff. But I agree with you that maybe I'll do this on my home turf first before I start messing around with somebody's PR. +STEPH: That way, someone doesn't reach out to me and say, "Steph, what is this commit that I have on my PR?" And I'm like, "Oh, I'm just testing." [laughs] But that's something that I was excited to talk about and share with you. What's new in your world? +CHRIS: Well, what's new in my world? I think we've talked about this a little bit, but to give a little bit of context on what's new in my world, I joined a startup. I am now engineer number one. I'm also CTO, a very fancy title, but again, I'm the team of one, so count it as you will. But we do have some consultants working with us. So there is a small team that I am managing, and very quickly, I found myself shifting away from the code or having to balance that trade-off of maker versus manager time. Like, how much of the time am I actually coding and shipping features versus managing and communicating, and trying to figure out the work to be done and triaging the backlog? And all of those sorts of things. +I've also just been coding less, and I think that's a trend that will almost certainly continue, and I'm intrigued by that. And that's a thing that I want to poke at just a little bit. And then I've also noticed that my work has become much more reactive than it used to be, where there are lots of things in Slack. And there's stuff that I'm kind of the only person that can do certain things because I have certain access levels and yadda yadda. And I want to make sure other folks aren't blocked. So I'm trying to be as responsive as possible in those moments. But I'm also struggling with that that trade-off between reactive versus proactive. +My ideal version I think of the work is gather all of the information, all of the different permutations, and what are all the features we want? And then I think about them holistically, and then I respond once solidly as opposed to little one-off interactions and things like that. So there are just a lot of subtle differences. And I think there are trends that will continue. And so I'm trying to just take a step back, observe them from a distance and say, "How do I feel about these?" +But probably most interesting to me is the moving away from code. Have you noticed that at all in your work? Or is that something you've thought about, something you'd be interested in, opposed to? How do you feel about that space in the coding world? +STEPH: That is a wonderful question. It's one that I have wrestled with for a while because I really love my current position. I love being a team lead because I feel like there's this wonderful balance between where I get to code a lot of the time, but then I also get to learn how to be a manager, and help those around me, and provide some coaching or mentoring or just help people find the resources that they need essentially. And I really like that balance. That feels like the right balance to me, where I still get to grow in both areas. +But then, as you'd mentioned, it still feels like one tries to take over the other with time. Like you find that more responsibilities are growing as CTO of the company. And so you feel more responsible to do more of the managerial task or unblocking others and taking on that role, and then that reduces your time for coding. +And I often find myself in that space where I think it's just how I'm wired. I'm very interested and empathetic towards how people are doing and how they're feeling. So I'm always looking for ways to support others and to help unblock them and make sure that they're having a very positive experience with our project. And so then that may mean I'm coding less because then I'm more focused on that. But then, it's still also a very valid part of my job to code. So finding the right balance between those is frankly hard. +To answer your other question, I don't think I want to give that up. I've considered for myself if I'm going to head towards more of a manager path, and I'm going to reserve the right to change my mind. But currently, I still like maintaining most of my individual contributor status with a dash of management sprinkled in there and then some responsibilities for making sure that the team is doing well and that people are enjoying their work. +Along that line, as I've been having conversations with others around, tell me more about your job as a manager, and what does that look like? What responsibilities do you have? How much coding do you still get to do? There have been a couple of books that have been recommended to me that really help someone define are you interested in management? Is that a place that you see yourself going? This is really an honest look at what it means to be a manager. The fact that a lot of your fulfilling work isn't necessarily work that you get to produce, but it's actually helping someone else produce that work and then getting to see them succeed. That is your new fulfillment or a big part of it. +So you are losing that closeness of being a maker,, but instead, you are empowering someone else to be the maker, and then that becomes your win. And that becomes an indication of your success. Versus as an individual contributor, it's really easy to see our wins in a different light: how many tickets have we addressed? How many PRs have we reviewed? That type of work. So there is an interesting dichotomy there, and I can't remember the books off the top of my head, but I will find them and I'll add a link to them in the show notes. +CHRIS: Yeah, definitely interested to see the book recommendations. And generally, yeah, everything you're saying makes sense to me. I think I'm somewhat on the adventure right now. I very much intentionally chose this, and I want to lean into it and explore this facet of the work and doing more of the management and leading a team. But I have to accept that that comes with letting go of some of the individual contributor parts. And I was coding a bit over the weekend. I was just rediscovering the flow of that. And I was like, oh yeah, I really like this. Huh, that's interesting. What am I going to do with that? But I think, again, it's an exploration. And there are facets of both sides that I really like. +And I've spent a lot of time deeper in the individual contributor side. And I've explored the manager side somewhat but not quite as much. And so this is very much about that I want to push on those edges and try and find what feels true to me. So the moving away from code and then moving more into management, I think I like that overall. Although I know there's the small amount in the back of my head that I'm like, I know there's a cost there. That is a trade-off. And so do I find more time in my evenings and weekends to do personal coding projects and things like that just to have that enjoyable work for myself? +The maker versus manager stuff is interesting, though, where my day is now split up into smaller pieces. And even if I'm not coding, there's still writing up docs, or there are things that still require structured blocks of time. And my day is now just sprinkled with other things. And so trying to find that heads down of I want to just do the work right now, and I want to think hard about something is just fundamentally harder to do with more meetings and things speckled throughout the day. So that's one that I think I just don't like overall. But it's sort of a trade-off inherent to the situation. +So I think there's also a version of trying to be intentional about that and saying, you know what? I need some heads-down time. And so Tuesday and Thursday afternoons those are going to be mine. I'm going to wall those off on my calendar and try and protect that time so that whatever necessary heads-down work that I need to do this week fits into those blocks of time and then fit the rest of things around that. But I think I have to make that intentional choice to do that. +Mid-roll Ad +And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. +With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. +The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. +STEPH: Your mention of having more meetings really resonates with me. And it also made me think of a recent episode of a new TV show I just started watching. Have you seen the TV show called Schmigadoon!? +CHRIS: I have indeed. +STEPH: Okay. We need to have a whole conversation about Schmigadoon! in an upcoming episode. I'm very excited about this show. It's delightful. [laughs] There's a particular line that Keegan-Michael Key says that I just love so much where he says that he became a surgeon because he wanted to help people without talking to people. And I was like, oh, that's a developer. [laughs] I'm the same way. And I really enjoyed that. Although I do like talking to people but still, it just made me think about when you're talking about more meetings and then increasing the amount of talking that needs to be done as you progress into more of a management role. +Also, circling back, I really like what you said earlier about you're noticing the changes that are happening. You're letting those changes happen, and then you're reflecting on how you feel about it. I really like that approach. Do you think that's working well for you? Does it feel too loose because then you don't feel in control enough of those changes? Or do you actually feel like that's a really good way to explore a new role and then find out if you like those changes? +CHRIS: Now that you are restating it back to me, I'm like, oh yeah, I guess that is a good way to do things. But to clarify, I'm not doing nothing with it. I am trying to proactively, where I can, structure my days and do things like that or recognize that right now, I'm probably not the right person to be moving code along. And so I'm saying okay, that is true. And I'm actively choosing to not pick up the bigger pieces of work or to pair with someone else so that they can then run with it but not having me being the person that owns it. So it's not completely letting it happen, but it is almost like meditation to invoke that idea of I'm observing that I'm having these thoughts, and I'm just going to let them go. And it's more about the thinking and the response to it. +So I'm trying to name the thing and be like, oh, this is interesting that this is happening. And I'm noticing an immediate visceral reaction to it where it's like, you're taking away my coding? And I'm like, well, hey, it's not them, it's you; you chose to do this. But let's just spend a minute there. That's okay. How do we feel about this? And so it's trying to not have it be a purely reactive response to it but have it be a more intentional, more thoughtful, and more observing, and then giving it a little bit of time to ruminate and then see a little bit more what I think. +And also, some of it is purposefully pushing myself out of my comfort zone. I think I'm happy, and I do a reasonable job when I'm the person moving the code along. But I also have really enjoyed being at the edge of an engineering team and working with sales or working with other groups and facilitating the work that's happening. And so, if I explore that a little bit more, what's that going to look like for me? +So this period of my career, I'm very intentionally trying to do stuff that I'm like, well, this is a little bit different for me, or this is stretching a little bit, but that is the goal. And I hope good things will come out of it across the board. But it may be that I find like, you know what? Actually, I really miss coding, and I need to find a way to restructure that. And I have seen examples of individuals who are even in CEO positions that are like, no, no, no, I still make some time to code. +Like Amir, the founder of Todoist talks regularly about the fact that he is a CEO who still codes. And that organization has a very particular approach to work. And they're very much about async remote, et cetera. So having these blocks of times and being intentional about how they work. So it's not surprising that he's been able to do that and a purposeful thing that he's structured. I don't think that will make sense for me immediately. But I could see a version down the road where I'm like, this is who I am. I need to get this thing back. But for now, I'm purposefully letting it happen and seeing how I feel from there. +Also, as I'm saying all of this, it sounds like I'm totally on top of this and really thinking it through. I'm like, no, no, no, this is in the moment. I'm noticing some stuff and being like, oh, okay, well, that's interesting. And some of it I intentionally chose. Again, intentionally chose to get out of my comfort zone. So I think I'm just actively out of my comfort zone right now and saying things about it. And then I think I'm telling the story of how I want to respond to it moving forward but not necessarily perfectly achieving that goal immediately. +STEPH: I think that's a nice representation of essentially how you and I have processed things. We've highlighted before that you and I...it's funny, I just made the joke about not talking to people, but it's how I actually process stuff. And the best is when I'm talking out loud to somebody else. And so it totally makes sense that as you were noticing this and reflecting on it, that then this is another way that you are then processing those changes and reflecting on it and thinking through is this a good change? Is it something that I'm going to enjoy? Or am I really going to miss my street coding creds? I need to get back to the editor. +CHRIS: I just need that precious flow state that comes from drinking some Mountain Dew and coding for hours. +STEPH: Do you drink Mountain Dew? +CHRIS: No, I gave it up years ago. +STEPH: [laughs] +CHRIS: I don't drink soda broadly. But if I'm going to drink soda, it's going to be Mountain Dew because if we're going to do it, let's do this thing. I'm pretty sure that stuff is like thermonuclear, but that's fine. +STEPH: [laughs] That's funny. I know we've had this conversation before also around Pop-Tarts where you're like, hey, if I'm going to have a Pop-Tart, I'm going to have the sugariest (Is that a word - sugariest?) Pop-Tart possible. +CHRIS: To be clear, that means it has icing on it because some people in the world, namely you, would prefer the ones without icing. Although we recently learned that the ones without icing have a higher fat and calorie content, so I don't know. The world's murky. I wish it were all just clear, and we could just work with it. But it turns out even Pop-Tarts icing versus not is not a simple question. +STEPH: It's a very simple question. You just need to be on the right side, which is the non-frosted side. [laughs] I can simplify this for you because fat is delicious. Fat trumps sugar; that’s my stance. That's my hot take. +CHRIS: I'm saying both, a little from column A, a little from column B. You got yourself a stew. +STEPH: [laughs] You got a fat sugar stew. +CHRIS: Yeah. That was in Arrested Development. All right, we're veering way off course now. [laughter] To bring it back, what you were highlighting of I'm definitely someone who thinks through stuff by talking out loud, and so it's been wonderful. I've learned so much about myself while talking to you on this podcast. I'll say something, and I'll be like, wait, I actually believe that thing I just said. This is fantastic. Now I can move forward with the knowledge that I've just gained for myself by talking about it on a podcast. So highly recommended: everybody should get a podcast. +STEPH: Plus one. I also have a very real, maybe silly, follow-up question for you as we are, like you just said, exploring the things that we believe or not. My question for you is part of the transition to management and moving away from coding. Isere some fear in the back of your mind where you're like, if I stopped coding, I'm going to lose this skill? +CHRIS: Honestly, no. And I feel kind of bad saying that because I feel like I should say, "Yeah, I feel like it'll fade away and whatnot." But I think I have an aptitude and an interest towards this work. And if I were to ignore it for two years, then frankly, I also know myself. And I'm still going to keep an eye on everything for a while. So I think I'll be aware of what's going on and maybe just haven't spent as much time with it. +But I think if I need to two years from now, I'm like, all right, I got to rebuild my coding muscle. I'll skip a couple of JavaScript frameworks, which will be nice, and I'll be on to the 15th iteration that's new now. But I hope that I could revisit that not trivially, not with no effort. It's the wonderful nature of coding. It's one of the things that I love about it so much is that there are blog posts and YouTube tutorials. And it's so individually discoverable that I'm not really worried about that aspect. +My concern, if anything, isn't so much that I'm going to lose my skills or not be able to code anymore; it’s that I really enjoy coding. It's a practice that I find very enjoyable. A workweek is enjoyable when it contains big blocks of me putting on my headphones, listening to music, and digging into a problem, and then coding and producing a solution. And those tiny little feedback loops of test-driven development or running something and then going to the browser and clicking around like that, there's a directness there that has always really worked well for me. +And so the more I'm abstracted away from that sort of thing, and the more of my work is I'm helping a team, and I'm directing strategy, or whatever it is, that just feels so indirect. And so I'm very interested to find out how I respond to that sort of thing. I've definitely enjoyed it in the past, and so that's why I'm intentionally leaning into it. +But I know that I'm giving up a part of the work that I really love, and giving up is too strong of a word as well. I'm going to find what shape makes sense moving forward. And I expect I'll still be pairing with the other developers on the team and helping to define architecture and things like that. So it's not like it's 100% gone. But for now, I think the world where most of my week was spent coding is no longer the case. And so just naming that and being intentional about it. And yeah, that's the game. +STEPH: Cool. Yeah, that makes a lot of sense. I was mainly interested in that question because that is a question that I've asked myself from time to time that I think I do have that worry that if I step away from coding for too long, then it won't be easy to jump back into. And I've talked myself out of that many times because I don't think it's true for all the reasons that you just said. But it is something that I have considered as like, well, if I take this leap of faith into this other direction, how easy is it for me to get back if I decide to change my mind and go back to being more of an individual contributor? +And one other thing that weighs on me as I'm splitting my time between two areas that I really want to grow…So I'm constantly trying to grow as a developer. I'm also trying to grow as a manager, and I don't want to do a bad job at either. I want to do a great job at both, and that's frankly not always possible. And at times, I have to make trade-offs with myself around okay, I'm going to focus a little heavier this day or this week on being a really great manager or focus a little bit more on being a developer and to pick and choose those topics. And then that sometimes means doing like B+ work in one area, and that's really hard for me. I'm an A-work person. So even downgrading to a B+ level of effort is challenging. But I have found that that's a really great space to be because then I'm doing well in both areas, not perfect, but doing well enough. And often, that's really what counts is that we're doing well enough and still pursuing growth in the areas that are important to us. +CHRIS: Yeah, I think that intentional switching back and forth between them is the space that I'm in. I expect my work will remain very technical, and I hope that that's true. And I think to a certain extent; I get to shape it and determine that. And so how much of it is strategy and planning and things like that? Versus how much of it is helping the team with architecture and defining processes as to how we code, and what are our standards, and what are our languages and frameworks and all of that? I expect I'm still going to be involved in the latter. And again, I think to a certain extent; I get to choose that. +So I am actually interested to see the shape that both naturally the organization needs out of the role that I'm in. But also, what sort of back pressure I can apply and be like, but this is how I want it to be. Is there room for that, or is there not? And it's all an experiment, and we're going to find out. But personally, for me, I'm going to keep reading Twitter and blog posts every day, and I'm probably going to code on the weekends and things. +So the idea of my coding muscle atrophying, I don't know, that one doesn't feel true. But we'll see what I have to say a year from now or after what that looks like. But I expect...this has been true of me for so long, even when I had an entirely different career that I was just reading blogs and other things all the time because this is a thing that deeply interests me. So we will see. +STEPH: Yeah, I'm excited to hear how it goes. And I think there's something to be said for the fact that you are also a CTO that's very close to the work that's being done. So being someone that is very involved in the technical decisions and the code that's being written but then also taking on more of the management responsibilities. And that feels more of a shift where you still have a lot of your coding skills. +And you are writing code day-to-day at least based on what you're saying, but then you are also acquiring a lot of these management skills to go along with it. Versus if someone were going into management and maybe they're at a really large company and then they are very far away from the development team. And they're focused on higher-level themes and discussions, at least that's my guess. But I'm very excited to hear more about your updates and how this experiment is going and to find out who is the true Chris? +CHRIS: Who's the true Chris? That feels complicated. I feel like I contain multitudes. But yeah, you know what? I'm excited to find out as well. Let's see what's going on there. But yeah, so that's a grand summary of the things that are going on in my head. And I expect these are topics that will be continuing to evolve for me. So I think we'll probably have more conversations like this in the future but also some tech stuff. Because like I said, I don't know, I can't stop. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: Yeah, that's actually the perfect segue as we were talking earlier about just ways that we're looking to grow as developers. And I saw something that I really enjoyed, and it's published by another thoughtboter. Their name is Matheus Richard. And Matheus runs a Twitter account that's called @RubyCards. And I don't recall the exact cadence, but every so often, Matheus will share a new snippet of either Ruby or Rails code and then will often present the information as a question. +So I'll give you an example, but the highlight is that it teaches you something, either about Ruby or Rails. Maybe you already knew it, maybe you didn't. But it's a really nice exercise to think through okay, I'm reading this code. What do I think it's going to return? And then respond to this poll and then see how other people did as well. Because once the poll closes, then Matheus shares the actual answer for the question. +So one example that I saw recently highlights Ruby's endless method definition, which was introduced in Ruby 3. So that would be something like def, and then let's say the method name is message. And then you have closing, but empty parenthes equals a string of "Hello, World." And so then the question is if you call that method message, what would that return? And then the poll often has options around; it would return "Hello World," or it's going to return a syntax error. It's going to return nil. And then it highlights, well, because of Ruby's endless method definition, this would return "Hello, World." +And then I also saw a new method that I hadn't used before that's defined in Ruby's Hash class that's called store. And so you can use it calling it on a Hash. So if you have your hash equals and then curly brackets, let's say foo is equal to an integer of zero, then you can call hash.store and then pass in two arguments. The first argument's going to be the key. The second argument is the value. And then, that would essentially be the same syntax that we use for assigning a value to a hash. But I just hadn't actually seen the method store before. +So there are fun snippets of Ruby or Rails code. A little bit of a brain teaser helps you think through how that code works, what it's going to execute, what it's going to return. And I really enjoy it. I'll be sure to include a link to it in the show notes so other people can check it out. +CHRIS: Oh, that sounds fun. I hadn't seen that, but I will definitely be following. That's the word on Twitter, right? You have subscribing, subscribe and follow, smash that like button, all of the things. I will do all of the things that we do here on the internet. But I do like that model of the question and answer, and it's slightly more engaging than just sharing the information. So yeah, super interested to see that. +STEPH: Yeah, I like the format of here's some code, and then we're going to ask you what does it return? So that way, you get a moment to think it through. Because if I read something and it just shows me the answer, my brain just doesn't absorb it. And I'm like, okay, that makes sense, and my brain quickly moves on. But if I actually have to think about it and then respond with my answer, then it'll likely stick with me a lot longer. At least we'll find out; that’s the dream. +On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,; maybe as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Steph talks about a new GitHub feature and Twitter account (@RubyCards) she's really excited about and Chris talks about his new job as a CTO of a startup and shifting away from writing code regularly.

+ + + +

Transcript:

+ +

CHRIS: Oh God, my computer is so stupid slow. I need a new computer.

+ +

STEPH: Come on, little computer, you can do it. You know you could just buy a new one. You don't have to wait for the fancy-schmancy M1.

+ +

CHRIS: I want to wait for the fancy. I want it so bad.

+ +

STEPH: [laughs]

+ +

CHRIS: Do you know how long I've had this computer? And if I can hold out one more month, I want the fancy stuff. I've waited this long. Why would I give in now when I'm right on the cusp of victory?

+ +

STEPH: One more month. I'm going to send you...as a kid, did you ever make those construction…

+ +

CHRIS: Oh yeah.

+ +

STEPH: They look like chain links bow construction paper. So we would make those for a countdown to special days. I'm going to send you one that's all crumpled and folded in the mail. It would be delightful. And you'll be able to snip off a little chain each day as your countdown to your new fancy-schmancy. [laughs]

+ +

CHRIS: I love it.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey. Well, I just got back from vacation. So getting back to work is what's new in my world. And vacation is nice. I miss it already. But it's also nice to be back, and see everybody, and see what they've been up to.

+ +

CHRIS: I've heard wonderful things about vacation.

+ +

STEPH: Yeah. Have you had one recently? I know you've been quite busy.

+ +

CHRIS: I have. I think it's hard to tell, especially because everything just kind of blends together these days. But I think I took off a few days recently. I haven't had an extended vacation since much earlier on in the summer, I think. And so I think I'm due for one of those sometime in the not too distant future. But it's one of those things where you got to plan it. And you got to think ahead, and I haven't been doing that of late really with anything. So kind of living for the moment, but that's not how you take a vacation. So I got to rethink some strategies here. [chuckles]

+ +

STEPH: Yeah, I've been trying to schedule more vacation time just further out. Because then if I don't want to take it, like if I decide that I don't want the staycation or I don't need the day off, then I can just change my mind, and that's pretty easy to do. But I'm like you; if I don't plan it, then I don't feel like I have the energy to plan a vacation, and then it just doesn't happen. So I know that's one thing that I've been doing.

+ +

I've also been mentoring or coaching others, just checking in with them to say, "Hey, when's your next vacation? Have you scheduled any days off? Do you want to schedule a day off next month?" And saying that to other people has also been a very helpful reminder to me to do so.

+ +

CHRIS: Oh, I like that a lot as a recurring one-on-one question of, so what can you tell me about vacation? What do you got in the works there? Because that's the most important thing, [chuckles] which it kind of is. It's the way that we keep doing the work that we do.

+ +

STEPH: And I think so many people just haven't been taking a vacation. I mean, in 2020, we were all locked in and going through a pandemic, so then a lot of people weren't taking those breaks. And so part of it is just reminding people that even if you can't go somewhere, still please take some downtime and just know that you can step away from work and should step away from work.

+ +

But for us, we did go somewhere. So we went out to Seattle, which I've never...I've been out to the West Coast, but it's more like I've been out to L.A., Santa Monica. But this time, we went to the Northwest region. We went to Seattle, and we explored and did a lot of hiking and camping around the Northern Cascades and then Mount Rainier. And both of those are amazing. And I've never flown with camping gear, but that went really well. It worked out nice. We had an Airbnb every so often just for showers and having a roof over your head. That's really nice. But for most of the trip, we did a lot of camping and hiking.

+ +

CHRIS: That sounds like an awesome trip.

+ +

STEPH: Yeah, it was really cool. I'd love to go back to the Olympic National Park because there are just so many national parks that are around Seattle and in Washington that we couldn't begin to do it all. But Olympic National Park is still on my list. And I'm really grateful to have also seen the Northern Cascades and Mount Rainier.

+ +

But switching gears a bit, I have something that I'm really excited to share with you because I don't think you've seen it yet. I'm excited to find out if you have. But it's a new GitHub feature that came out, I think about a month ago, but there doesn't seem to have been much fanfare from GitHub about announcing this new feature. And I happened to find out through Twitter because someone else found it, and then they were really excited. And so now I think it's really gaining some more traction. But it still seems like one of those sneaky feature releases, but it's really cool.

+ +

So GitHub has added the ability to open up a web-based editor that allows you to view the source code for a repo, view it in syntax, highlighting, make a code change, and commit the change. And it's free for everybody. And there's a couple of ways to get there, but I'll pause there. Have you seen this yet? Have you interacted with it?

+ +

CHRIS: I think I've seen it and poked around ever so gently with it. I want to say this is GitHub Codespaces. Is that the name of this feature?

+ +

STEPH: Yep. That's it?

+ +

CHRIS: Yes. I poked around with it just a tiny bit, and I'm very excited about it. But it's very much in the like, huh, okay, cool; I’ll look at that someday down the road and figure out what I want to do with it. But have you actually dug into it particularly deeply?

+ +

STEPH: I used it to make a change for a personal project, just because I wanted to see the whole flow. So I went to a personal project, and there are two ways that you can open it up for anyone that hasn't seen this yet. So you can either press the period button that's on your keyboard, and that will open it up, or you can just alter the URL. So instead of github.com, replace that .com with .dev, and then that will also open up the browser.

+ +

And so I made a change to a personal project, and it worked really well, and it commits the change to main. And it was nice. It was easy. In my case, I was just making a change to make a change. I think I actually went to an older project where I was still using the underscore target to force users that when they clicked on a link that it opened a new tab, and I was like, perfect. This is a good thing to just change. And I could do it from my iPad. I didn't have to be at my computer. And it was really nifty. I was very impressed with it.

+ +

And they also mentioned that it's very easy to integrate your own VS Code settings and environment. I'm not a heavy VS Code user, so I haven't tried that. But I've heard really positive things about how easy it is to sync your settings between your local VS Code and then GitHub's editor. But overall, it was really easy to use.

+ +

CHRIS: That's super cool. My very limited understanding of it is like GitHub has had the ability to edit files and things like that for a while. But it was very much like a simple web editor where it's a big text box that happens to contain the code. And they've added some stuff for like browsing with syntax highlighting and even some context-aware show usage and things like that. But as far as I understand it, this is like a whole VS Code instance in the cloud that is running it.

+ +

And then I think what you're saying about you can have your VS Code settings in there, but even your project settings and the ability to run the tests, I'm not sure where the edges of it are. But my understanding with Codespaces it's like this is how your team can develop. Everyone gets one of these Codespaces. You're developing in the cloud. But it does VS Code remote sync type stuff. I'm very intrigued to see where it goes and that idea of...obviously, I like Vim. That's the thing that's probably known and true about me. So I will probably be one of the later adopters of this.

+ +

But the idea of being able to bottle up the development environment for your projects and have those settings, and the ability to run the test and all of that packaged up as part of the repository, and then allow people to run with that, especially in the cloud, and be able to carry that with them as they move around, that's really intriguing. And the idea of having this very easy on-ramp, especially for open-source projects and things like that. If you want people to be able to contribute easily but with the linting, and the configuration, and the settings, and all the stuff, well, now you can have that packaged up. And that is very interesting to me.

+ +

So I'm super intrigued to see where it goes. Again, I will probably be one of the later adopters of this platform for reasons. But I am super interested, and I continue to like...the work with VS Code is so interesting in the way it keeps expanding out and the language server stuff and now the Codespaces stuff. And it's super interesting developments across the board.

+ +

STEPH: Yeah, I'm with you. I don't actually see this replacing my current development that I do day-to-day, but it's more generally nice to have access. So if I needed to make a change and I don't have my laptop or if it's just something small and I don't want to have to go through…I guess essentially, if I don't have my laptop, but I wanted to make a change, then I could do this realistically from something that doesn't have my full local dev setup.

+ +

I don't know if you have the ability to run tests. I didn't explore that far as to whether you can actually have access to run those types of commands or processes. I did see some additional notes while reading through GitHub's documentation about this new editor. And they included some notes that talk about how the editor runs entirely in your browser's sandbox. So it doesn't actually clone the repo, but instead, it loads your code by invoking the services API directly from the browser. So then your work is saved in the browser's local storage until you commit it, and then you can persist your changes by then committing it back to the repo.

+ +

And because there's no associated compute, you won't be able to build and run your code or use the integrated terminal. Ah, I think that actually answers the question about running tests. So only a subset of extensions can run in the web will appear in the extensions panel and can be installed. So this does impose certain limitations for particular programming languages and full functionality, things that we may need like running tests.

+ +

CHRIS: Interesting. That now puts it back more on the uncanny valley for me where it's like, oh, it's just VS Code, except it can't do a bunch of the stuff. So yeah, I'll probably be hanging out in Vim for a while. But again, I'm super interested to see where they can push this and what the browser platform allows, and then how they're able to leverage that and so on and so forth.

+ +

STEPH: There is one flow that I was testing out because I was reading someone else mentioned that not only can you use this for looking at source code and then changing that source code but also for a pull request. And so I went to a pull request and changed the URL to dev. And I do have the ability to make changes, but I'm not quite sure if I could commit my changes and if that would go to the branch or how that would work. It wasn't obvious to me how I could save my changes. But it was obvious to me that I could make changes. [laughs] So that part feels weird to me, and I will have to test that out. But I'm going to wait until I have my own PR before I start fooling around [laughs] so I don't ruin somebody else's PR.

+ +

CHRIS: Ideally, the worst case is you just push commit to a branch, and commits are reversible. You can throw them away. You can reset, and you can do all sorts of stuff. But I agree with you that maybe I'll do this on my home turf first before I start messing around with somebody's PR.

+ +

STEPH: That way, someone doesn't reach out to me and say, "Steph, what is this commit that I have on my PR?" And I'm like, "Oh, I'm just testing." [laughs] But that's something that I was excited to talk about and share with you. What's new in your world?

+ +

CHRIS: Well, what's new in my world? I think we've talked about this a little bit, but to give a little bit of context on what's new in my world, I joined a startup. I am now engineer number one. I'm also CTO, a very fancy title, but again, I'm the team of one, so count it as you will. But we do have some consultants working with us. So there is a small team that I am managing, and very quickly, I found myself shifting away from the code or having to balance that trade-off of maker versus manager time. Like, how much of the time am I actually coding and shipping features versus managing and communicating, and trying to figure out the work to be done and triaging the backlog? And all of those sorts of things.

+ +

I've also just been coding less, and I think that's a trend that will almost certainly continue, and I'm intrigued by that. And that's a thing that I want to poke at just a little bit. And then I've also noticed that my work has become much more reactive than it used to be, where there are lots of things in Slack. And there's stuff that I'm kind of the only person that can do certain things because I have certain access levels and yadda yadda. And I want to make sure other folks aren't blocked. So I'm trying to be as responsive as possible in those moments. But I'm also struggling with that that trade-off between reactive versus proactive.

+ +

My ideal version I think of the work is gather all of the information, all of the different permutations, and what are all the features we want? And then I think about them holistically, and then I respond once solidly as opposed to little one-off interactions and things like that. So there are just a lot of subtle differences. And I think there are trends that will continue. And so I'm trying to just take a step back, observe them from a distance and say, "How do I feel about these?"

+ +

But probably most interesting to me is the moving away from code. Have you noticed that at all in your work? Or is that something you've thought about, something you'd be interested in, opposed to? How do you feel about that space in the coding world?

+ +

STEPH: That is a wonderful question. It's one that I have wrestled with for a while because I really love my current position. I love being a team lead because I feel like there's this wonderful balance between where I get to code a lot of the time, but then I also get to learn how to be a manager, and help those around me, and provide some coaching or mentoring or just help people find the resources that they need essentially. And I really like that balance. That feels like the right balance to me, where I still get to grow in both areas.

+ +

But then, as you'd mentioned, it still feels like one tries to take over the other with time. Like you find that more responsibilities are growing as CTO of the company. And so you feel more responsible to do more of the managerial task or unblocking others and taking on that role, and then that reduces your time for coding.

+ +

And I often find myself in that space where I think it's just how I'm wired. I'm very interested and empathetic towards how people are doing and how they're feeling. So I'm always looking for ways to support others and to help unblock them and make sure that they're having a very positive experience with our project. And so then that may mean I'm coding less because then I'm more focused on that. But then, it's still also a very valid part of my job to code. So finding the right balance between those is frankly hard.

+ +

To answer your other question, I don't think I want to give that up. I've considered for myself if I'm going to head towards more of a manager path, and I'm going to reserve the right to change my mind. But currently, I still like maintaining most of my individual contributor status with a dash of management sprinkled in there and then some responsibilities for making sure that the team is doing well and that people are enjoying their work.

+ +

Along that line, as I've been having conversations with others around, tell me more about your job as a manager, and what does that look like? What responsibilities do you have? How much coding do you still get to do? There have been a couple of books that have been recommended to me that really help someone define are you interested in management? Is that a place that you see yourself going? This is really an honest look at what it means to be a manager. The fact that a lot of your fulfilling work isn't necessarily work that you get to produce, but it's actually helping someone else produce that work and then getting to see them succeed. That is your new fulfillment or a big part of it.

+ +

So you are losing that closeness of being a maker,, but instead, you are empowering someone else to be the maker, and then that becomes your win. And that becomes an indication of your success. Versus as an individual contributor, it's really easy to see our wins in a different light: how many tickets have we addressed? How many PRs have we reviewed? That type of work. So there is an interesting dichotomy there, and I can't remember the books off the top of my head, but I will find them and I'll add a link to them in the show notes.

+ +

CHRIS: Yeah, definitely interested to see the book recommendations. And generally, yeah, everything you're saying makes sense to me. I think I'm somewhat on the adventure right now. I very much intentionally chose this, and I want to lean into it and explore this facet of the work and doing more of the management and leading a team. But I have to accept that that comes with letting go of some of the individual contributor parts. And I was coding a bit over the weekend. I was just rediscovering the flow of that. And I was like, oh yeah, I really like this. Huh, that's interesting. What am I going to do with that? But I think, again, it's an exploration. And there are facets of both sides that I really like.

+ +

And I've spent a lot of time deeper in the individual contributor side. And I've explored the manager side somewhat but not quite as much. And so this is very much about that I want to push on those edges and try and find what feels true to me. So the moving away from code and then moving more into management, I think I like that overall. Although I know there's the small amount in the back of my head that I'm like, I know there's a cost there. That is a trade-off. And so do I find more time in my evenings and weekends to do personal coding projects and things like that just to have that enjoyable work for myself?

+ +

The maker versus manager stuff is interesting, though, where my day is now split up into smaller pieces. And even if I'm not coding, there's still writing up docs, or there are things that still require structured blocks of time. And my day is now just sprinkled with other things. And so trying to find that heads down of I want to just do the work right now, and I want to think hard about something is just fundamentally harder to do with more meetings and things speckled throughout the day. So that's one that I think I just don't like overall. But it's sort of a trade-off inherent to the situation.

+ +

So I think there's also a version of trying to be intentional about that and saying, you know what? I need some heads-down time. And so Tuesday and Thursday afternoons those are going to be mine. I'm going to wall those off on my calendar and try and protect that time so that whatever necessary heads-down work that I need to do this week fits into those blocks of time and then fit the rest of things around that. But I think I have to make that intentional choice to do that.

+ +

Mid-roll Ad

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city.

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: Your mention of having more meetings really resonates with me. And it also made me think of a recent episode of a new TV show I just started watching. Have you seen the TV show called Schmigadoon!?

+ +

CHRIS: I have indeed.

+ +

STEPH: Okay. We need to have a whole conversation about Schmigadoon! in an upcoming episode. I'm very excited about this show. It's delightful. [laughs] There's a particular line that Keegan-Michael Key says that I just love so much where he says that he became a surgeon because he wanted to help people without talking to people. And I was like, oh, that's a developer. [laughs] I'm the same way. And I really enjoyed that. Although I do like talking to people but still, it just made me think about when you're talking about more meetings and then increasing the amount of talking that needs to be done as you progress into more of a management role.

+ +

Also, circling back, I really like what you said earlier about you're noticing the changes that are happening. You're letting those changes happen, and then you're reflecting on how you feel about it. I really like that approach. Do you think that's working well for you? Does it feel too loose because then you don't feel in control enough of those changes? Or do you actually feel like that's a really good way to explore a new role and then find out if you like those changes?

+ +

CHRIS: Now that you are restating it back to me, I'm like, oh yeah, I guess that is a good way to do things. But to clarify, I'm not doing nothing with it. I am trying to proactively, where I can, structure my days and do things like that or recognize that right now, I'm probably not the right person to be moving code along. And so I'm saying okay, that is true. And I'm actively choosing to not pick up the bigger pieces of work or to pair with someone else so that they can then run with it but not having me being the person that owns it. So it's not completely letting it happen, but it is almost like meditation to invoke that idea of I'm observing that I'm having these thoughts, and I'm just going to let them go. And it's more about the thinking and the response to it.

+ +

So I'm trying to name the thing and be like, oh, this is interesting that this is happening. And I'm noticing an immediate visceral reaction to it where it's like, you're taking away my coding? And I'm like, well, hey, it's not them, it's you; you chose to do this. But let's just spend a minute there. That's okay. How do we feel about this? And so it's trying to not have it be a purely reactive response to it but have it be a more intentional, more thoughtful, and more observing, and then giving it a little bit of time to ruminate and then see a little bit more what I think.

+ +

And also, some of it is purposefully pushing myself out of my comfort zone. I think I'm happy, and I do a reasonable job when I'm the person moving the code along. But I also have really enjoyed being at the edge of an engineering team and working with sales or working with other groups and facilitating the work that's happening. And so, if I explore that a little bit more, what's that going to look like for me?

+ +

So this period of my career, I'm very intentionally trying to do stuff that I'm like, well, this is a little bit different for me, or this is stretching a little bit, but that is the goal. And I hope good things will come out of it across the board. But it may be that I find like, you know what? Actually, I really miss coding, and I need to find a way to restructure that. And I have seen examples of individuals who are even in CEO positions that are like, no, no, no, I still make some time to code.

+ +

Like Amir, the founder of Todoist talks regularly about the fact that he is a CEO who still codes. And that organization has a very particular approach to work. And they're very much about async remote, et cetera. So having these blocks of times and being intentional about how they work. So it's not surprising that he's been able to do that and a purposeful thing that he's structured. I don't think that will make sense for me immediately. But I could see a version down the road where I'm like, this is who I am. I need to get this thing back. But for now, I'm purposefully letting it happen and seeing how I feel from there.

+ +

Also, as I'm saying all of this, it sounds like I'm totally on top of this and really thinking it through. I'm like, no, no, no, this is in the moment. I'm noticing some stuff and being like, oh, okay, well, that's interesting. And some of it I intentionally chose. Again, intentionally chose to get out of my comfort zone. So I think I'm just actively out of my comfort zone right now and saying things about it. And then I think I'm telling the story of how I want to respond to it moving forward but not necessarily perfectly achieving that goal immediately.

+ +

STEPH: I think that's a nice representation of essentially how you and I have processed things. We've highlighted before that you and I...it's funny, I just made the joke about not talking to people, but it's how I actually process stuff. And the best is when I'm talking out loud to somebody else. And so it totally makes sense that as you were noticing this and reflecting on it, that then this is another way that you are then processing those changes and reflecting on it and thinking through is this a good change? Is it something that I'm going to enjoy? Or am I really going to miss my street coding creds? I need to get back to the editor.

+ +

CHRIS: I just need that precious flow state that comes from drinking some Mountain Dew and coding for hours.

+ +

STEPH: Do you drink Mountain Dew?

+ +

CHRIS: No, I gave it up years ago.

+ +

STEPH: [laughs]

+ +

CHRIS: I don't drink soda broadly. But if I'm going to drink soda, it's going to be Mountain Dew because if we're going to do it, let's do this thing. I'm pretty sure that stuff is like thermonuclear, but that's fine.

+ +

STEPH: [laughs] That's funny. I know we've had this conversation before also around Pop-Tarts where you're like, hey, if I'm going to have a Pop-Tart, I'm going to have the sugariest (Is that a word - sugariest?) Pop-Tart possible.

+ +

CHRIS: To be clear, that means it has icing on it because some people in the world, namely you, would prefer the ones without icing. Although we recently learned that the ones without icing have a higher fat and calorie content, so I don't know. The world's murky. I wish it were all just clear, and we could just work with it. But it turns out even Pop-Tarts icing versus not is not a simple question.

+ +

STEPH: It's a very simple question. You just need to be on the right side, which is the non-frosted side. [laughs] I can simplify this for you because fat is delicious. Fat trumps sugar; that’s my stance. That's my hot take.

+ +

CHRIS: I'm saying both, a little from column A, a little from column B. You got yourself a stew.

+ +

STEPH: [laughs] You got a fat sugar stew.

+ +

CHRIS: Yeah. That was in Arrested Development. All right, we're veering way off course now. [laughter] To bring it back, what you were highlighting of I'm definitely someone who thinks through stuff by talking out loud, and so it's been wonderful. I've learned so much about myself while talking to you on this podcast. I'll say something, and I'll be like, wait, I actually believe that thing I just said. This is fantastic. Now I can move forward with the knowledge that I've just gained for myself by talking about it on a podcast. So highly recommended: everybody should get a podcast.

+ +

STEPH: Plus one. I also have a very real, maybe silly, follow-up question for you as we are, like you just said, exploring the things that we believe or not. My question for you is part of the transition to management and moving away from coding. Isere some fear in the back of your mind where you're like, if I stopped coding, I'm going to lose this skill?

+ +

CHRIS: Honestly, no. And I feel kind of bad saying that because I feel like I should say, "Yeah, I feel like it'll fade away and whatnot." But I think I have an aptitude and an interest towards this work. And if I were to ignore it for two years, then frankly, I also know myself. And I'm still going to keep an eye on everything for a while. So I think I'll be aware of what's going on and maybe just haven't spent as much time with it.

+ +

But I think if I need to two years from now, I'm like, all right, I got to rebuild my coding muscle. I'll skip a couple of JavaScript frameworks, which will be nice, and I'll be on to the 15th iteration that's new now. But I hope that I could revisit that not trivially, not with no effort. It's the wonderful nature of coding. It's one of the things that I love about it so much is that there are blog posts and YouTube tutorials. And it's so individually discoverable that I'm not really worried about that aspect.

+ +

My concern, if anything, isn't so much that I'm going to lose my skills or not be able to code anymore; it’s that I really enjoy coding. It's a practice that I find very enjoyable. A workweek is enjoyable when it contains big blocks of me putting on my headphones, listening to music, and digging into a problem, and then coding and producing a solution. And those tiny little feedback loops of test-driven development or running something and then going to the browser and clicking around like that, there's a directness there that has always really worked well for me.

+ +

And so the more I'm abstracted away from that sort of thing, and the more of my work is I'm helping a team, and I'm directing strategy, or whatever it is, that just feels so indirect. And so I'm very interested to find out how I respond to that sort of thing. I've definitely enjoyed it in the past, and so that's why I'm intentionally leaning into it.

+ +

But I know that I'm giving up a part of the work that I really love, and giving up is too strong of a word as well. I'm going to find what shape makes sense moving forward. And I expect I'll still be pairing with the other developers on the team and helping to define architecture and things like that. So it's not like it's 100% gone. But for now, I think the world where most of my week was spent coding is no longer the case. And so just naming that and being intentional about it. And yeah, that's the game.

+ +

STEPH: Cool. Yeah, that makes a lot of sense. I was mainly interested in that question because that is a question that I've asked myself from time to time that I think I do have that worry that if I step away from coding for too long, then it won't be easy to jump back into. And I've talked myself out of that many times because I don't think it's true for all the reasons that you just said. But it is something that I have considered as like, well, if I take this leap of faith into this other direction, how easy is it for me to get back if I decide to change my mind and go back to being more of an individual contributor?

+ +

And one other thing that weighs on me as I'm splitting my time between two areas that I really want to grow…So I'm constantly trying to grow as a developer. I'm also trying to grow as a manager, and I don't want to do a bad job at either. I want to do a great job at both, and that's frankly not always possible. And at times, I have to make trade-offs with myself around okay, I'm going to focus a little heavier this day or this week on being a really great manager or focus a little bit more on being a developer and to pick and choose those topics. And then that sometimes means doing like B+ work in one area, and that's really hard for me. I'm an A-work person. So even downgrading to a B+ level of effort is challenging. But I have found that that's a really great space to be because then I'm doing well in both areas, not perfect, but doing well enough. And often, that's really what counts is that we're doing well enough and still pursuing growth in the areas that are important to us.

+ +

CHRIS: Yeah, I think that intentional switching back and forth between them is the space that I'm in. I expect my work will remain very technical, and I hope that that's true. And I think to a certain extent; I get to shape it and determine that. And so how much of it is strategy and planning and things like that? Versus how much of it is helping the team with architecture and defining processes as to how we code, and what are our standards, and what are our languages and frameworks and all of that? I expect I'm still going to be involved in the latter. And again, I think to a certain extent; I get to choose that.

+ +

So I am actually interested to see the shape that both naturally the organization needs out of the role that I'm in. But also, what sort of back pressure I can apply and be like, but this is how I want it to be. Is there room for that, or is there not? And it's all an experiment, and we're going to find out. But personally, for me, I'm going to keep reading Twitter and blog posts every day, and I'm probably going to code on the weekends and things.

+ +

So the idea of my coding muscle atrophying, I don't know, that one doesn't feel true. But we'll see what I have to say a year from now or after what that looks like. But I expect...this has been true of me for so long, even when I had an entirely different career that I was just reading blogs and other things all the time because this is a thing that deeply interests me. So we will see.

+ +

STEPH: Yeah, I'm excited to hear how it goes. And I think there's something to be said for the fact that you are also a CTO that's very close to the work that's being done. So being someone that is very involved in the technical decisions and the code that's being written but then also taking on more of the management responsibilities. And that feels more of a shift where you still have a lot of your coding skills.

+ +

And you are writing code day-to-day at least based on what you're saying, but then you are also acquiring a lot of these management skills to go along with it. Versus if someone were going into management and maybe they're at a really large company and then they are very far away from the development team. And they're focused on higher-level themes and discussions, at least that's my guess. But I'm very excited to hear more about your updates and how this experiment is going and to find out who is the true Chris?

+ +

CHRIS: Who's the true Chris? That feels complicated. I feel like I contain multitudes. But yeah, you know what? I'm excited to find out as well. Let's see what's going on there. But yeah, so that's a grand summary of the things that are going on in my head. And I expect these are topics that will be continuing to evolve for me. So I think we'll probably have more conversations like this in the future but also some tech stuff. Because like I said, I don't know, I can't stop.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Yeah, that's actually the perfect segue as we were talking earlier about just ways that we're looking to grow as developers. And I saw something that I really enjoyed, and it's published by another thoughtboter. Their name is Matheus Richard. And Matheus runs a Twitter account that's called @RubyCards. And I don't recall the exact cadence, but every so often, Matheus will share a new snippet of either Ruby or Rails code and then will often present the information as a question.

+ +

So I'll give you an example, but the highlight is that it teaches you something, either about Ruby or Rails. Maybe you already knew it, maybe you didn't. But it's a really nice exercise to think through okay, I'm reading this code. What do I think it's going to return? And then respond to this poll and then see how other people did as well. Because once the poll closes, then Matheus shares the actual answer for the question.

+ +

So one example that I saw recently highlights Ruby's endless method definition, which was introduced in Ruby 3. So that would be something like def, and then let's say the method name is message. And then you have closing, but empty parenthes equals a string of "Hello, World." And so then the question is if you call that method message, what would that return? And then the poll often has options around; it would return "Hello World," or it's going to return a syntax error. It's going to return nil. And then it highlights, well, because of Ruby's endless method definition, this would return "Hello, World."

+ +

And then I also saw a new method that I hadn't used before that's defined in Ruby's Hash class that's called store. And so you can use it calling it on a Hash. So if you have your hash equals and then curly brackets, let's say foo is equal to an integer of zero, then you can call hash.store and then pass in two arguments. The first argument's going to be the key. The second argument is the value. And then, that would essentially be the same syntax that we use for assigning a value to a hash. But I just hadn't actually seen the method store before.

+ +

So there are fun snippets of Ruby or Rails code. A little bit of a brain teaser helps you think through how that code works, what it's going to execute, what it's going to return. And I really enjoy it. I'll be sure to include a link to it in the show notes so other people can check it out.

+ +

CHRIS: Oh, that sounds fun. I hadn't seen that, but I will definitely be following. That's the word on Twitter, right? You have subscribing, subscribe and follow, smash that like button, all of the things. I will do all of the things that we do here on the internet. But I do like that model of the question and answer, and it's slightly more engaging than just sharing the information. So yeah, super interested to see that.

+ +

STEPH: Yeah, I like the format of here's some code, and then we're going to ask you what does it return? So that way, you get a moment to think it through. Because if I read something and it just shows me the answer, my brain just doesn't absorb it. And I'm like, okay, that makes sense, and my brain quickly moves on. But if I actually have to think about it and then respond with my answer, then it'll likely stick with me a lot longer. At least we'll find out; that’s the dream.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,; maybe as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + Steph talks about a new GitHub feature and Twitter account (@RubyCards) she's really excited about and Chris talks about his new job as a CTO of a startup and shifting away from writing code regularly.

+ + + +

Transcript:

+ +

CHRIS: Oh God, my computer is so stupid slow. I need a new computer.

+ +

STEPH: Come on, little computer, you can do it. You know you could just buy a new one. You don't have to wait for the fancy-schmancy M1.

+ +

CHRIS: I want to wait for the fancy. I want it so bad.

+ +

STEPH: [laughs]

+ +

CHRIS: Do you know how long I've had this computer? And if I can hold out one more month, I want the fancy stuff. I've waited this long. Why would I give in now when I'm right on the cusp of victory?

+ +

STEPH: One more month. I'm going to send you...as a kid, did you ever make those construction…

+ +

CHRIS: Oh yeah.

+ +

STEPH: They look like chain links bow construction paper. So we would make those for a countdown to special days. I'm going to send you one that's all crumpled and folded in the mail. It would be delightful. And you'll be able to snip off a little chain each day as your countdown to your new fancy-schmancy. [laughs]

+ +

CHRIS: I love it.

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world?

+ +

STEPH: Hey. Well, I just got back from vacation. So getting back to work is what's new in my world. And vacation is nice. I miss it already. But it's also nice to be back, and see everybody, and see what they've been up to.

+ +

CHRIS: I've heard wonderful things about vacation.

+ +

STEPH: Yeah. Have you had one recently? I know you've been quite busy.

+ +

CHRIS: I have. I think it's hard to tell, especially because everything just kind of blends together these days. But I think I took off a few days recently. I haven't had an extended vacation since much earlier on in the summer, I think. And so I think I'm due for one of those sometime in the not too distant future. But it's one of those things where you got to plan it. And you got to think ahead, and I haven't been doing that of late really with anything. So kind of living for the moment, but that's not how you take a vacation. So I got to rethink some strategies here. [chuckles]

+ +

STEPH: Yeah, I've been trying to schedule more vacation time just further out. Because then if I don't want to take it, like if I decide that I don't want the staycation or I don't need the day off, then I can just change my mind, and that's pretty easy to do. But I'm like you; if I don't plan it, then I don't feel like I have the energy to plan a vacation, and then it just doesn't happen. So I know that's one thing that I've been doing.

+ +

I've also been mentoring or coaching others, just checking in with them to say, "Hey, when's your next vacation? Have you scheduled any days off? Do you want to schedule a day off next month?" And saying that to other people has also been a very helpful reminder to me to do so.

+ +

CHRIS: Oh, I like that a lot as a recurring one-on-one question of, so what can you tell me about vacation? What do you got in the works there? Because that's the most important thing, [chuckles] which it kind of is. It's the way that we keep doing the work that we do.

+ +

STEPH: And I think so many people just haven't been taking a vacation. I mean, in 2020, we were all locked in and going through a pandemic, so then a lot of people weren't taking those breaks. And so part of it is just reminding people that even if you can't go somewhere, still please take some downtime and just know that you can step away from work and should step away from work.

+ +

But for us, we did go somewhere. So we went out to Seattle, which I've never...I've been out to the West Coast, but it's more like I've been out to L.A., Santa Monica. But this time, we went to the Northwest region. We went to Seattle, and we explored and did a lot of hiking and camping around the Northern Cascades and then Mount Rainier. And both of those are amazing. And I've never flown with camping gear, but that went really well. It worked out nice. We had an Airbnb every so often just for showers and having a roof over your head. That's really nice. But for most of the trip, we did a lot of camping and hiking.

+ +

CHRIS: That sounds like an awesome trip.

+ +

STEPH: Yeah, it was really cool. I'd love to go back to the Olympic National Park because there are just so many national parks that are around Seattle and in Washington that we couldn't begin to do it all. But Olympic National Park is still on my list. And I'm really grateful to have also seen the Northern Cascades and Mount Rainier.

+ +

But switching gears a bit, I have something that I'm really excited to share with you because I don't think you've seen it yet. I'm excited to find out if you have. But it's a new GitHub feature that came out, I think about a month ago, but there doesn't seem to have been much fanfare from GitHub about announcing this new feature. And I happened to find out through Twitter because someone else found it, and then they were really excited. And so now I think it's really gaining some more traction. But it still seems like one of those sneaky feature releases, but it's really cool.

+ +

So GitHub has added the ability to open up a web-based editor that allows you to view the source code for a repo, view it in syntax, highlighting, make a code change, and commit the change. And it's free for everybody. And there's a couple of ways to get there, but I'll pause there. Have you seen this yet? Have you interacted with it?

+ +

CHRIS: I think I've seen it and poked around ever so gently with it. I want to say this is GitHub Codespaces. Is that the name of this feature?

+ +

STEPH: Yep. That's it?

+ +

CHRIS: Yes. I poked around with it just a tiny bit, and I'm very excited about it. But it's very much in the like, huh, okay, cool; I’ll look at that someday down the road and figure out what I want to do with it. But have you actually dug into it particularly deeply?

+ +

STEPH: I used it to make a change for a personal project, just because I wanted to see the whole flow. So I went to a personal project, and there are two ways that you can open it up for anyone that hasn't seen this yet. So you can either press the period button that's on your keyboard, and that will open it up, or you can just alter the URL. So instead of github.com, replace that .com with .dev, and then that will also open up the browser.

+ +

And so I made a change to a personal project, and it worked really well, and it commits the change to main. And it was nice. It was easy. In my case, I was just making a change to make a change. I think I actually went to an older project where I was still using the underscore target to force users that when they clicked on a link that it opened a new tab, and I was like, perfect. This is a good thing to just change. And I could do it from my iPad. I didn't have to be at my computer. And it was really nifty. I was very impressed with it.

+ +

And they also mentioned that it's very easy to integrate your own VS Code settings and environment. I'm not a heavy VS Code user, so I haven't tried that. But I've heard really positive things about how easy it is to sync your settings between your local VS Code and then GitHub's editor. But overall, it was really easy to use.

+ +

CHRIS: That's super cool. My very limited understanding of it is like GitHub has had the ability to edit files and things like that for a while. But it was very much like a simple web editor where it's a big text box that happens to contain the code. And they've added some stuff for like browsing with syntax highlighting and even some context-aware show usage and things like that. But as far as I understand it, this is like a whole VS Code instance in the cloud that is running it.

+ +

And then I think what you're saying about you can have your VS Code settings in there, but even your project settings and the ability to run the tests, I'm not sure where the edges of it are. But my understanding with Codespaces it's like this is how your team can develop. Everyone gets one of these Codespaces. You're developing in the cloud. But it does VS Code remote sync type stuff. I'm very intrigued to see where it goes and that idea of...obviously, I like Vim. That's the thing that's probably known and true about me. So I will probably be one of the later adopters of this.

+ +

But the idea of being able to bottle up the development environment for your projects and have those settings, and the ability to run the test and all of that packaged up as part of the repository, and then allow people to run with that, especially in the cloud, and be able to carry that with them as they move around, that's really intriguing. And the idea of having this very easy on-ramp, especially for open-source projects and things like that. If you want people to be able to contribute easily but with the linting, and the configuration, and the settings, and all the stuff, well, now you can have that packaged up. And that is very interesting to me.

+ +

So I'm super intrigued to see where it goes. Again, I will probably be one of the later adopters of this platform for reasons. But I am super interested, and I continue to like...the work with VS Code is so interesting in the way it keeps expanding out and the language server stuff and now the Codespaces stuff. And it's super interesting developments across the board.

+ +

STEPH: Yeah, I'm with you. I don't actually see this replacing my current development that I do day-to-day, but it's more generally nice to have access. So if I needed to make a change and I don't have my laptop or if it's just something small and I don't want to have to go through…I guess essentially, if I don't have my laptop, but I wanted to make a change, then I could do this realistically from something that doesn't have my full local dev setup.

+ +

I don't know if you have the ability to run tests. I didn't explore that far as to whether you can actually have access to run those types of commands or processes. I did see some additional notes while reading through GitHub's documentation about this new editor. And they included some notes that talk about how the editor runs entirely in your browser's sandbox. So it doesn't actually clone the repo, but instead, it loads your code by invoking the services API directly from the browser. So then your work is saved in the browser's local storage until you commit it, and then you can persist your changes by then committing it back to the repo.

+ +

And because there's no associated compute, you won't be able to build and run your code or use the integrated terminal. Ah, I think that actually answers the question about running tests. So only a subset of extensions can run in the web will appear in the extensions panel and can be installed. So this does impose certain limitations for particular programming languages and full functionality, things that we may need like running tests.

+ +

CHRIS: Interesting. That now puts it back more on the uncanny valley for me where it's like, oh, it's just VS Code, except it can't do a bunch of the stuff. So yeah, I'll probably be hanging out in Vim for a while. But again, I'm super interested to see where they can push this and what the browser platform allows, and then how they're able to leverage that and so on and so forth.

+ +

STEPH: There is one flow that I was testing out because I was reading someone else mentioned that not only can you use this for looking at source code and then changing that source code but also for a pull request. And so I went to a pull request and changed the URL to dev. And I do have the ability to make changes, but I'm not quite sure if I could commit my changes and if that would go to the branch or how that would work. It wasn't obvious to me how I could save my changes. But it was obvious to me that I could make changes. [laughs] So that part feels weird to me, and I will have to test that out. But I'm going to wait until I have my own PR before I start fooling around [laughs] so I don't ruin somebody else's PR.

+ +

CHRIS: Ideally, the worst case is you just push commit to a branch, and commits are reversible. You can throw them away. You can reset, and you can do all sorts of stuff. But I agree with you that maybe I'll do this on my home turf first before I start messing around with somebody's PR.

+ +

STEPH: That way, someone doesn't reach out to me and say, "Steph, what is this commit that I have on my PR?" And I'm like, "Oh, I'm just testing." [laughs] But that's something that I was excited to talk about and share with you. What's new in your world?

+ +

CHRIS: Well, what's new in my world? I think we've talked about this a little bit, but to give a little bit of context on what's new in my world, I joined a startup. I am now engineer number one. I'm also CTO, a very fancy title, but again, I'm the team of one, so count it as you will. But we do have some consultants working with us. So there is a small team that I am managing, and very quickly, I found myself shifting away from the code or having to balance that trade-off of maker versus manager time. Like, how much of the time am I actually coding and shipping features versus managing and communicating, and trying to figure out the work to be done and triaging the backlog? And all of those sorts of things.

+ +

I've also just been coding less, and I think that's a trend that will almost certainly continue, and I'm intrigued by that. And that's a thing that I want to poke at just a little bit. And then I've also noticed that my work has become much more reactive than it used to be, where there are lots of things in Slack. And there's stuff that I'm kind of the only person that can do certain things because I have certain access levels and yadda yadda. And I want to make sure other folks aren't blocked. So I'm trying to be as responsive as possible in those moments. But I'm also struggling with that that trade-off between reactive versus proactive.

+ +

My ideal version I think of the work is gather all of the information, all of the different permutations, and what are all the features we want? And then I think about them holistically, and then I respond once solidly as opposed to little one-off interactions and things like that. So there are just a lot of subtle differences. And I think there are trends that will continue. And so I'm trying to just take a step back, observe them from a distance and say, "How do I feel about these?"

+ +

But probably most interesting to me is the moving away from code. Have you noticed that at all in your work? Or is that something you've thought about, something you'd be interested in, opposed to? How do you feel about that space in the coding world?

+ +

STEPH: That is a wonderful question. It's one that I have wrestled with for a while because I really love my current position. I love being a team lead because I feel like there's this wonderful balance between where I get to code a lot of the time, but then I also get to learn how to be a manager, and help those around me, and provide some coaching or mentoring or just help people find the resources that they need essentially. And I really like that balance. That feels like the right balance to me, where I still get to grow in both areas.

+ +

But then, as you'd mentioned, it still feels like one tries to take over the other with time. Like you find that more responsibilities are growing as CTO of the company. And so you feel more responsible to do more of the managerial task or unblocking others and taking on that role, and then that reduces your time for coding.

+ +

And I often find myself in that space where I think it's just how I'm wired. I'm very interested and empathetic towards how people are doing and how they're feeling. So I'm always looking for ways to support others and to help unblock them and make sure that they're having a very positive experience with our project. And so then that may mean I'm coding less because then I'm more focused on that. But then, it's still also a very valid part of my job to code. So finding the right balance between those is frankly hard.

+ +

To answer your other question, I don't think I want to give that up. I've considered for myself if I'm going to head towards more of a manager path, and I'm going to reserve the right to change my mind. But currently, I still like maintaining most of my individual contributor status with a dash of management sprinkled in there and then some responsibilities for making sure that the team is doing well and that people are enjoying their work.

+ +

Along that line, as I've been having conversations with others around, tell me more about your job as a manager, and what does that look like? What responsibilities do you have? How much coding do you still get to do? There have been a couple of books that have been recommended to me that really help someone define are you interested in management? Is that a place that you see yourself going? This is really an honest look at what it means to be a manager. The fact that a lot of your fulfilling work isn't necessarily work that you get to produce, but it's actually helping someone else produce that work and then getting to see them succeed. That is your new fulfillment or a big part of it.

+ +

So you are losing that closeness of being a maker,, but instead, you are empowering someone else to be the maker, and then that becomes your win. And that becomes an indication of your success. Versus as an individual contributor, it's really easy to see our wins in a different light: how many tickets have we addressed? How many PRs have we reviewed? That type of work. So there is an interesting dichotomy there, and I can't remember the books off the top of my head, but I will find them and I'll add a link to them in the show notes.

+ +

CHRIS: Yeah, definitely interested to see the book recommendations. And generally, yeah, everything you're saying makes sense to me. I think I'm somewhat on the adventure right now. I very much intentionally chose this, and I want to lean into it and explore this facet of the work and doing more of the management and leading a team. But I have to accept that that comes with letting go of some of the individual contributor parts. And I was coding a bit over the weekend. I was just rediscovering the flow of that. And I was like, oh yeah, I really like this. Huh, that's interesting. What am I going to do with that? But I think, again, it's an exploration. And there are facets of both sides that I really like.

+ +

And I've spent a lot of time deeper in the individual contributor side. And I've explored the manager side somewhat but not quite as much. And so this is very much about that I want to push on those edges and try and find what feels true to me. So the moving away from code and then moving more into management, I think I like that overall. Although I know there's the small amount in the back of my head that I'm like, I know there's a cost there. That is a trade-off. And so do I find more time in my evenings and weekends to do personal coding projects and things like that just to have that enjoyable work for myself?

+ +

The maker versus manager stuff is interesting, though, where my day is now split up into smaller pieces. And even if I'm not coding, there's still writing up docs, or there are things that still require structured blocks of time. And my day is now just sprinkled with other things. And so trying to find that heads down of I want to just do the work right now, and I want to think hard about something is just fundamentally harder to do with more meetings and things speckled throughout the day. So that's one that I think I just don't like overall. But it's sort of a trade-off inherent to the situation.

+ +

So I think there's also a version of trying to be intentional about that and saying, you know what? I need some heads-down time. And so Tuesday and Thursday afternoons those are going to be mine. I'm going to wall those off on my calendar and try and protect that time so that whatever necessary heads-down work that I need to do this week fits into those blocks of time and then fit the rest of things around that. But I think I have to make that intentional choice to do that.

+ +

Mid-roll Ad

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city.

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: Your mention of having more meetings really resonates with me. And it also made me think of a recent episode of a new TV show I just started watching. Have you seen the TV show called Schmigadoon!?

+ +

CHRIS: I have indeed.

+ +

STEPH: Okay. We need to have a whole conversation about Schmigadoon! in an upcoming episode. I'm very excited about this show. It's delightful. [laughs] There's a particular line that Keegan-Michael Key says that I just love so much where he says that he became a surgeon because he wanted to help people without talking to people. And I was like, oh, that's a developer. [laughs] I'm the same way. And I really enjoyed that. Although I do like talking to people but still, it just made me think about when you're talking about more meetings and then increasing the amount of talking that needs to be done as you progress into more of a management role.

+ +

Also, circling back, I really like what you said earlier about you're noticing the changes that are happening. You're letting those changes happen, and then you're reflecting on how you feel about it. I really like that approach. Do you think that's working well for you? Does it feel too loose because then you don't feel in control enough of those changes? Or do you actually feel like that's a really good way to explore a new role and then find out if you like those changes?

+ +

CHRIS: Now that you are restating it back to me, I'm like, oh yeah, I guess that is a good way to do things. But to clarify, I'm not doing nothing with it. I am trying to proactively, where I can, structure my days and do things like that or recognize that right now, I'm probably not the right person to be moving code along. And so I'm saying okay, that is true. And I'm actively choosing to not pick up the bigger pieces of work or to pair with someone else so that they can then run with it but not having me being the person that owns it. So it's not completely letting it happen, but it is almost like meditation to invoke that idea of I'm observing that I'm having these thoughts, and I'm just going to let them go. And it's more about the thinking and the response to it.

+ +

So I'm trying to name the thing and be like, oh, this is interesting that this is happening. And I'm noticing an immediate visceral reaction to it where it's like, you're taking away my coding? And I'm like, well, hey, it's not them, it's you; you chose to do this. But let's just spend a minute there. That's okay. How do we feel about this? And so it's trying to not have it be a purely reactive response to it but have it be a more intentional, more thoughtful, and more observing, and then giving it a little bit of time to ruminate and then see a little bit more what I think.

+ +

And also, some of it is purposefully pushing myself out of my comfort zone. I think I'm happy, and I do a reasonable job when I'm the person moving the code along. But I also have really enjoyed being at the edge of an engineering team and working with sales or working with other groups and facilitating the work that's happening. And so, if I explore that a little bit more, what's that going to look like for me?

+ +

So this period of my career, I'm very intentionally trying to do stuff that I'm like, well, this is a little bit different for me, or this is stretching a little bit, but that is the goal. And I hope good things will come out of it across the board. But it may be that I find like, you know what? Actually, I really miss coding, and I need to find a way to restructure that. And I have seen examples of individuals who are even in CEO positions that are like, no, no, no, I still make some time to code.

+ +

Like Amir, the founder of Todoist talks regularly about the fact that he is a CEO who still codes. And that organization has a very particular approach to work. And they're very much about async remote, et cetera. So having these blocks of times and being intentional about how they work. So it's not surprising that he's been able to do that and a purposeful thing that he's structured. I don't think that will make sense for me immediately. But I could see a version down the road where I'm like, this is who I am. I need to get this thing back. But for now, I'm purposefully letting it happen and seeing how I feel from there.

+ +

Also, as I'm saying all of this, it sounds like I'm totally on top of this and really thinking it through. I'm like, no, no, no, this is in the moment. I'm noticing some stuff and being like, oh, okay, well, that's interesting. And some of it I intentionally chose. Again, intentionally chose to get out of my comfort zone. So I think I'm just actively out of my comfort zone right now and saying things about it. And then I think I'm telling the story of how I want to respond to it moving forward but not necessarily perfectly achieving that goal immediately.

+ +

STEPH: I think that's a nice representation of essentially how you and I have processed things. We've highlighted before that you and I...it's funny, I just made the joke about not talking to people, but it's how I actually process stuff. And the best is when I'm talking out loud to somebody else. And so it totally makes sense that as you were noticing this and reflecting on it, that then this is another way that you are then processing those changes and reflecting on it and thinking through is this a good change? Is it something that I'm going to enjoy? Or am I really going to miss my street coding creds? I need to get back to the editor.

+ +

CHRIS: I just need that precious flow state that comes from drinking some Mountain Dew and coding for hours.

+ +

STEPH: Do you drink Mountain Dew?

+ +

CHRIS: No, I gave it up years ago.

+ +

STEPH: [laughs]

+ +

CHRIS: I don't drink soda broadly. But if I'm going to drink soda, it's going to be Mountain Dew because if we're going to do it, let's do this thing. I'm pretty sure that stuff is like thermonuclear, but that's fine.

+ +

STEPH: [laughs] That's funny. I know we've had this conversation before also around Pop-Tarts where you're like, hey, if I'm going to have a Pop-Tart, I'm going to have the sugariest (Is that a word - sugariest?) Pop-Tart possible.

+ +

CHRIS: To be clear, that means it has icing on it because some people in the world, namely you, would prefer the ones without icing. Although we recently learned that the ones without icing have a higher fat and calorie content, so I don't know. The world's murky. I wish it were all just clear, and we could just work with it. But it turns out even Pop-Tarts icing versus not is not a simple question.

+ +

STEPH: It's a very simple question. You just need to be on the right side, which is the non-frosted side. [laughs] I can simplify this for you because fat is delicious. Fat trumps sugar; that’s my stance. That's my hot take.

+ +

CHRIS: I'm saying both, a little from column A, a little from column B. You got yourself a stew.

+ +

STEPH: [laughs] You got a fat sugar stew.

+ +

CHRIS: Yeah. That was in Arrested Development. All right, we're veering way off course now. [laughter] To bring it back, what you were highlighting of I'm definitely someone who thinks through stuff by talking out loud, and so it's been wonderful. I've learned so much about myself while talking to you on this podcast. I'll say something, and I'll be like, wait, I actually believe that thing I just said. This is fantastic. Now I can move forward with the knowledge that I've just gained for myself by talking about it on a podcast. So highly recommended: everybody should get a podcast.

+ +

STEPH: Plus one. I also have a very real, maybe silly, follow-up question for you as we are, like you just said, exploring the things that we believe or not. My question for you is part of the transition to management and moving away from coding. Isere some fear in the back of your mind where you're like, if I stopped coding, I'm going to lose this skill?

+ +

CHRIS: Honestly, no. And I feel kind of bad saying that because I feel like I should say, "Yeah, I feel like it'll fade away and whatnot." But I think I have an aptitude and an interest towards this work. And if I were to ignore it for two years, then frankly, I also know myself. And I'm still going to keep an eye on everything for a while. So I think I'll be aware of what's going on and maybe just haven't spent as much time with it.

+ +

But I think if I need to two years from now, I'm like, all right, I got to rebuild my coding muscle. I'll skip a couple of JavaScript frameworks, which will be nice, and I'll be on to the 15th iteration that's new now. But I hope that I could revisit that not trivially, not with no effort. It's the wonderful nature of coding. It's one of the things that I love about it so much is that there are blog posts and YouTube tutorials. And it's so individually discoverable that I'm not really worried about that aspect.

+ +

My concern, if anything, isn't so much that I'm going to lose my skills or not be able to code anymore; it’s that I really enjoy coding. It's a practice that I find very enjoyable. A workweek is enjoyable when it contains big blocks of me putting on my headphones, listening to music, and digging into a problem, and then coding and producing a solution. And those tiny little feedback loops of test-driven development or running something and then going to the browser and clicking around like that, there's a directness there that has always really worked well for me.

+ +

And so the more I'm abstracted away from that sort of thing, and the more of my work is I'm helping a team, and I'm directing strategy, or whatever it is, that just feels so indirect. And so I'm very interested to find out how I respond to that sort of thing. I've definitely enjoyed it in the past, and so that's why I'm intentionally leaning into it.

+ +

But I know that I'm giving up a part of the work that I really love, and giving up is too strong of a word as well. I'm going to find what shape makes sense moving forward. And I expect I'll still be pairing with the other developers on the team and helping to define architecture and things like that. So it's not like it's 100% gone. But for now, I think the world where most of my week was spent coding is no longer the case. And so just naming that and being intentional about it. And yeah, that's the game.

+ +

STEPH: Cool. Yeah, that makes a lot of sense. I was mainly interested in that question because that is a question that I've asked myself from time to time that I think I do have that worry that if I step away from coding for too long, then it won't be easy to jump back into. And I've talked myself out of that many times because I don't think it's true for all the reasons that you just said. But it is something that I have considered as like, well, if I take this leap of faith into this other direction, how easy is it for me to get back if I decide to change my mind and go back to being more of an individual contributor?

+ +

And one other thing that weighs on me as I'm splitting my time between two areas that I really want to grow…So I'm constantly trying to grow as a developer. I'm also trying to grow as a manager, and I don't want to do a bad job at either. I want to do a great job at both, and that's frankly not always possible. And at times, I have to make trade-offs with myself around okay, I'm going to focus a little heavier this day or this week on being a really great manager or focus a little bit more on being a developer and to pick and choose those topics. And then that sometimes means doing like B+ work in one area, and that's really hard for me. I'm an A-work person. So even downgrading to a B+ level of effort is challenging. But I have found that that's a really great space to be because then I'm doing well in both areas, not perfect, but doing well enough. And often, that's really what counts is that we're doing well enough and still pursuing growth in the areas that are important to us.

+ +

CHRIS: Yeah, I think that intentional switching back and forth between them is the space that I'm in. I expect my work will remain very technical, and I hope that that's true. And I think to a certain extent; I get to shape it and determine that. And so how much of it is strategy and planning and things like that? Versus how much of it is helping the team with architecture and defining processes as to how we code, and what are our standards, and what are our languages and frameworks and all of that? I expect I'm still going to be involved in the latter. And again, I think to a certain extent; I get to choose that.

+ +

So I am actually interested to see the shape that both naturally the organization needs out of the role that I'm in. But also, what sort of back pressure I can apply and be like, but this is how I want it to be. Is there room for that, or is there not? And it's all an experiment, and we're going to find out. But personally, for me, I'm going to keep reading Twitter and blog posts every day, and I'm probably going to code on the weekends and things.

+ +

So the idea of my coding muscle atrophying, I don't know, that one doesn't feel true. But we'll see what I have to say a year from now or after what that looks like. But I expect...this has been true of me for so long, even when I had an entirely different career that I was just reading blogs and other things all the time because this is a thing that deeply interests me. So we will see.

+ +

STEPH: Yeah, I'm excited to hear how it goes. And I think there's something to be said for the fact that you are also a CTO that's very close to the work that's being done. So being someone that is very involved in the technical decisions and the code that's being written but then also taking on more of the management responsibilities. And that feels more of a shift where you still have a lot of your coding skills.

+ +

And you are writing code day-to-day at least based on what you're saying, but then you are also acquiring a lot of these management skills to go along with it. Versus if someone were going into management and maybe they're at a really large company and then they are very far away from the development team. And they're focused on higher-level themes and discussions, at least that's my guess. But I'm very excited to hear more about your updates and how this experiment is going and to find out who is the true Chris?

+ +

CHRIS: Who's the true Chris? That feels complicated. I feel like I contain multitudes. But yeah, you know what? I'm excited to find out as well. Let's see what's going on there. But yeah, so that's a grand summary of the things that are going on in my head. And I expect these are topics that will be continuing to evolve for me. So I think we'll probably have more conversations like this in the future but also some tech stuff. Because like I said, I don't know, I can't stop.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: Yeah, that's actually the perfect segue as we were talking earlier about just ways that we're looking to grow as developers. And I saw something that I really enjoyed, and it's published by another thoughtboter. Their name is Matheus Richard. And Matheus runs a Twitter account that's called @RubyCards. And I don't recall the exact cadence, but every so often, Matheus will share a new snippet of either Ruby or Rails code and then will often present the information as a question.

+ +

So I'll give you an example, but the highlight is that it teaches you something, either about Ruby or Rails. Maybe you already knew it, maybe you didn't. But it's a really nice exercise to think through okay, I'm reading this code. What do I think it's going to return? And then respond to this poll and then see how other people did as well. Because once the poll closes, then Matheus shares the actual answer for the question.

+ +

So one example that I saw recently highlights Ruby's endless method definition, which was introduced in Ruby 3. So that would be something like def, and then let's say the method name is message. And then you have closing, but empty parenthes equals a string of "Hello, World." And so then the question is if you call that method message, what would that return? And then the poll often has options around; it would return "Hello World," or it's going to return a syntax error. It's going to return nil. And then it highlights, well, because of Ruby's endless method definition, this would return "Hello, World."

+ +

And then I also saw a new method that I hadn't used before that's defined in Ruby's Hash class that's called store. And so you can use it calling it on a Hash. So if you have your hash equals and then curly brackets, let's say foo is equal to an integer of zero, then you can call hash.store and then pass in two arguments. The first argument's going to be the key. The second argument is the value. And then, that would essentially be the same syntax that we use for assigning a value to a hash. But I just hadn't actually seen the method store before.

+ +

So there are fun snippets of Ruby or Rails code. A little bit of a brain teaser helps you think through how that code works, what it's going to execute, what it's going to return. And I really enjoy it. I'll be sure to include a link to it in the show notes so other people can check it out.

+ +

CHRIS: Oh, that sounds fun. I hadn't seen that, but I will definitely be following. That's the word on Twitter, right? You have subscribing, subscribe and follow, smash that like button, all of the things. I will do all of the things that we do here on the internet. But I do like that model of the question and answer, and it's slightly more engaging than just sharing the information. So yeah, super interested to see that.

+ +

STEPH: Yeah, I like the format of here's some code, and then we're going to ask you what does it return? So that way, you get a moment to think it through. Because if I read something and it just shows me the answer, my brain just doesn't absorb it. And I'm like, okay, that makes sense, and my brain quickly moves on. But if I actually have to think about it and then respond with my answer, then it'll likely stick with me a lot longer. At least we'll find out; that’s the dream.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,; maybe as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+M4al1gbQ + + ]]> + + Chris Toomey + Steph Viccari + + + 308: That’s Picante + https://bikeshed.thoughtbot.com/308 + 17893053-6c6a-4b97-a79d-974cc2c69bd3 + Tue, 14 Sep 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + You know what really grinds Chris' gears? (Spoiler Alert: It's Single-Page Applications.) + +Steph needs some consulting help. So much to do, so little time. + 48:05 + no + + + You know what really grinds Chris' gears? (Spoiler Alert: It's Single-Page Applications.) +Steph needs some consulting help. So much to do, so little time. +Sarah Drasner tweet about shared element transitions (https://twitter.com/sarah_edo/status/1431282994581413893) +Article about Page Transitions API (https://developer.chrome.com/blog/shared-element-transitions-for-spas/) +Svelte Crossfade layout demo (https://svelte.dev/repl/a7af336f906c4caab3936972754e4d6f?version=3.23.2) +Svelte Crossfade tutorial page (https://svelte.dev/tutorial/deferred-transitions) (Note - click "Show Me" on the bottom left) +Transcript: +CHRIS: I have restarted my recording, and we are now recording. And we are off on the golden roads. Isn't software fun? +STEPH: Podcast battle. Here we go! +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been? +CHRIS: Happy Friday to you as well. My week's been good with the exception of right before we started this recording, I had one of those experiences. You know the thing where software is bad and software is just terrible overall? I had one of those. And very briefly to describe it, I started recording, but I could hear some feedback in my headphones. So I was like, oh no, is that feedback going to show up on the final recording? Which I really hope it doesn't. Spoiler alert - listener, if I sound off, sorry about that. But so I stopped recording and then I went to go listen to the file, and I have our audio software configured to record directly to the desktop. And it does that normally quite well. But for some reason, the file wasn't there. But I remember this recently because I ran into it another time. +For some reason, this is Finder failing me. So the thing that shows me the files in a graphical format, at least on my operating system. Although I think it also messes up in the terminal maybe. That feels like it shouldn't be true, but maybe it is. Anyway, I had to kill all Finder from the terminal to aggressively restart that process. And then suddenly, Finder was like, oh yeah, there's totally files there, absolutely. They were there the whole time. Why do you even ask? +And I know that state management is a hard problem, I am aware. I have felt this pain. I have been the person who has introduced some bugs related to it, but that's not where I want to experience it. Finder is one of those applications that I want to just implicitly trust, never question whether or not it's just sneakily telling me that there are files that are not there or vice versa. So anyway, software. +STEPH: I'm worried for your OS. I feel like there's a theme lately [chuckles] in the struggles of your computer. +CHRIS: On a related note, I had to turn off transparency in my terminal because it was making my computer get very hot. [chuckles] +STEPH: Oh no, you're not a hacker any more. +CHRIS: I'm not. [chuckles] I just have a weird screen that's just dark. And jellybeans is my color scheme, so there's that going on. That's in Vim specifically. Pure is my prompt. That's a lovely little prompt. But lots of Day-Glo colors on just a black background, not the cool hacker transparency. I have lost some street cred. +STEPH: What is your prompt? What did you say it is? +CHRIS: Pure. +STEPH: Pure, I don't know that one. +CHRIS: It is by Sindre Sorhus; I think is his name. That's his Twitter handle, GitHub name. He is a prolific open-source creator in the Node world, particularly. But he created this...I think it's a Bash and a Zsh prompt. It might be for others as well. It's got a bunch of features. It's pretty fast. It's minimal. It got me to stop messing around with my prompt, which was mostly what I was going for. And it has a nice benefit that occasionally now I'll be pairing with someone, and I'll be like, "Your prompt looks like my prompt. Everything is familiar. This is great." +STEPH: Well, if you get back in the waters of messing around with your prompts again, I'm using Starship. And I hadn't heard of Pure before, but I really like Starship. That's been my new favorite. +CHRIS: Wow. +STEPH: Wow. +CHRIS: I mean, on the one hand… +STEPH: You're welcome. [laughs] +CHRIS: On the one hand, thank you. On the other hand, again, let me lead in with the goal was to stop messing around with my prompt. So you're like, oh, cool. Here's another prompt for you, though. [chuckles] +STEPH: [laughs] But my goal is to nerd snipe you into trying more things because it's fun. +CHRIS: I don't know if you know this, but I am impervious to nerd sniping. +STEPH: [laughs] +CHRIS: So try as you might, I shall remain steady in my course of action. +STEPH: Are we playing two truths and a lie? Is that what we're doing today? [laughs] +CHRIS: Nah, just one lie. It's easier. Everybody wins one lie. +STEPH: [laughs] +CHRIS: But anyway, in other news, we're going to do a segment called this really grinds my gears. That's today's segment, which is much like when I do a good idea, terrible idea. But this is one that I'm sure I've talked about before. But there's been some stuff that I saw moving around on the internet as one does, and it got these ideas back into my head. And it's around the phrase single-page application. I am not a fan of that phrase or SPA as the initialism. Thank you, Edward Loveall, for teaching me the difference between an initialism and an acronym. I really hope I'm getting it right, by the way, [laughs] SPA as people call them these days. +I feel weird because of how much I care about this thing, how much I care about this idea, and how much whenever I hear this acronym, I get a little bit unhappy. And so there's a part of it that's I really do think our words shape our thinking. And I think single-page application has some deeply problematic ideas. Most notably, I think one of the most important things about building web applications is the URL. And those are different pages, at least in my head. I don't know of a different way to think about this. +But if you are not emphasizing the URL and the fact that the URL is a way to address different pages or resources within your application, then you are throwing away one of the greatest advancements that humankind has made, in my mind. I care a lot about URLs; it turns out. And it's not inherent to an SPA that you will not be thinking about URLs. But again, in that idea that our words shape our thinking, by calling it an SPA, by leaning into that idea, I think you are starting down a path that leads to bad outcomes. I'm going to pause there because I'm getting kind of ranty. I got more to say on the topic. But what do you think? +STEPH: Yeah, these are hot takes. I'm into it. I'm pretty sure that I know why URLs are so important to you and more of your feelings around why they're important. But would you dive in a bit deeper as to why you really cherish URLs, and why they're so important, and why they're one of the greatest advancements of humanity? +CHRIS: [laughs] It sounds lofty when you say it back to me, but yeah. It's interesting that as you put into a question, it is a little bit hard to name. So there are certain aspects that are somewhat obvious. I love the idea that I can bookmark or share a given resource or representation of a resource very simply. Like the URL, it's this known thing. We can put hyperlinks in a document. It's this shared way to communicate, frankly, very complex things. +And when I think of a URL, it's not just the domain and the path, but it's also any query parameters. So if you imagine faceted search on a website, you can be like, oh, filter down to these and only ones that are more than $10, and only ones that have a future start date and all those kinds of nuance. If you serialize that into the URL as part of the query param, then that even more nuanced view of this resource is shareable is bookmarkable is revisitable. +I end up making Alfred Workflows that take advantage of the fact that, like, oh, I can look at this URL scheme, and I can see where different parts are interpolated. And so I can navigate directly to any given thing so fast. And that's deeply valuable, and it just falls naturally out of the idea that we have URLs. And so to not deeply embrace that, to not really wrap your arms around it and give that idea a big hug feels weird to me. +STEPH: Yeah, I agree. I remember we've had this conversation in the past, and it really frustrates me when I can't share specific resources with folks because I don't know how to link to it. So then I can send you a link to the application itself to the top URL. But then I have to tell you how to find the information that I thought was really helpful. And that feels like a step backward. +CHRIS: Yeah. That ability to say, "Follow this link, and then it will be obvious," versus "Go to this page, click on this thing, click on the dropdown, click on this other thing." Like, that's just a fundamentally different experience. So one of the things that I saw that got me thinking about this was I saw folks referring to single-page applications but then contrasting them with MPAs, which are multiple-page applications. +STEPH: So the normal application? [laughs] +CHRIS: And I was like, whoa, whoa, everybody. You mean like a website or a web app? As much as I was angry at the first initialism, this second one's really getting me going. But it really does speak to what are we doing? What are we trying to build? And as with anything, you could treat this as a binary as just like there are two options. There are either websites which, yeah, those have got a bunch of URLs, and that's all the stuff. And then there are web apps, and they're different. And it's a bundle of JavaScript that comes down, boots up on the client, and then it's an app thing. And who cares about URLs? I think very few people would actually fall in that camp. +So I don't really believe that there is a dichotomy here. I think, as always, it's a continuum; it’s a spectrum. But leaning into the nomenclature of single-page application, I think pushes you more towards that latter end of the spectrum. I think there are other things that fall out of it. Like, I believe deeply in having the server know more, have more of the logic, own more of the logic, own more authorization and routing, and all of those things because really great stuff falls out of that. And that one has more of a trade-off, I'd say. +But I won't name any names, but there is a multiple billion-dollar company whose website I had to interact with recently. And you land on their page on their marketing site. And then, if you click log in, it navigates you to the application, so a separate domain or a separate subdomain, the application subdomain, and the login page there. And the login page renders, and then I go to fill in my username and password. Like, my mouse makes it all the way to click on the little box or whatever I'm doing if I'm using keyboard things. But I have enough time to actually start to interact with this page. +And then suddenly, it rips away, and it actually just renders the authenticated application because it turns out I was already logged in. But behind the scenes, they're doing some JWT dance around that they're checking; oh no, no, you're already logged in, so never mind. We don't need to show you the login page, but I was already on the login page. +And my feeling is this sort of brittle UI; this sort of inconsistency erodes my trust in that application, particularly when I'm on the login page. That is a page that matters. I don't believe that they're doing anything fundamentally insecure. But I do have the question in my head now. I'm like, wait, what's going on there, everybody? Is it fine? Was that okay? Or if you see something that you shouldn't see and then suddenly it's ripped away from you, if you see half of a layout that's rendered on a page and then suddenly you see, no, no, no, you actually don't have access to that page, that experience erodes my trust. +And so, I would rather wait for the server to fully resolve, determine what's going to happen, and then we get a response that is holistically consistent. You either have access, or you don't, that sort of thing. Give me a loading indicator; give me those sorts of things. I'm fine with that. But don't render half of a layout and then redirect me back away. +STEPH: I feel like that's one of the problems with knowing too much because most people are not going to pick up on a lot of the things that you're noticing and caring deeply about where they would just see like, oh, I was logged in and be like, huh, okay, that was a little weird, but I'm in and just continue on. Versus other folks who work very closely to this who may recognize and say, "That was weird." And the fact that you asked me to log in, but then I was already logged in, did you actually log me in correctly? What's happening? And then it makes you nervous. +CHRIS: Maybe. Probably. But I wonder…the way you just said that sounds like another dichotomy. And I would say it's probably more of a continuum of an average not terribly tech-savvy user would still have a feeling of huh, that was weird. And that's enough. That's a little tickle in the back of your brain. It's like, huh, that was weird. +And if that happens enough times or if you've seen someone who uses an application and uses it consistently, if that application is reasonably fast and somewhat intuitive and consistent, then they can move through it very quickly and very confidently. But if you have an app that half loads and then swaps you to another page and other things like that, it's very hard to move confidently through an application like that. I do think you're right in saying that I am over-indexed on this, and I probably care more than the average person, but I do care a lot. +I do think one of the reasons that I think this happens is mobile applications came along, and they showed us a different experience that can happen and also desktop apps for some amount of time this was true. But I think iOS apps, in particular really great ones, have super high fidelity interactions. And so you're like, you're looking at a list view, and then you click on the cell for that list view. And there's this animated transition where the title floats up to the top and grows just a little bit. And the icon that was in the corner moves up to the corner, and it gets a little bigger. And it's this animated transition to the detailed view for that item. And then if you go back, it sort of deanimates back down. +And that very consistent experience is kind of lovely when you get it right, but it's really, really hard. And people, I think, have tried to bring that to the web, but it's been such a struggle. And it necessitates client-side routing and some other things, or it's probably easiest to do if you have those sorts of technologies at play, but it's been a struggle. I can't think of an application that I think really pulls that off. And I think the trade-offs have been very costly. +On the one positive note, there was a tweet that I saw by Sarah Drasner that was talking about smooth and simple page transitions with the shared element transition API. So this is a new API that I think is hoping to bring some of this functionality to the web platform natively so that web applications can provide that higher fidelity experience. Exactly how it'll work whether or not it requires embracing more of the single-page application, client-side routing, et cetera, I'm not sure on that. But it is a glimmer of hope because I think this is one of the things that drives folks in this direction. And if we have a better answer to it, then maybe we can start to rethink the conversation. +STEPH: So I think you just said shared element transitions. I don't know what that is. Can you talk more about that? +CHRIS: I can try, or I can make a guess. So my understanding is that would be that sort of experience where you have a version of a certain piece of content on the page. And then, as you transition to a new page, that piece of content is still represented on the new page, but perhaps the font size is larger, or it's expanded, or the box around it has grown or something like that. And so on mobile, you'll often see that animate change. On the web, you'll often see the one page is just completely replaced with the other. And so it's a way to have continuity between, say, a detailed view, and then when you click on an item in it, that item sort of grows to become the new page. And now you're on the detail page from the list page prior. +There's actually a functionality in Svelte natively for this, which is really fancy; it's called crossfade. And so it allows you to say, "This item in the component hierarchy in the first state of the application is the same as this item in the second state of the application." And then, Svelte will take care of transitioning any of the properties that are necessary between those two. +So if you have a small circle that is green, and then in the next state of the application, it's a blue rectangle, it will interpolate between those two colors. It will interpolate the shape and grow and expand it. It will float it to its new location. There is a really great version of it in the Svelte tutorial showing a to-do list. And so it's got a list on the left, which is undone things, and a list on the right that is done things. And when you click on something to complete it, it will animate it, sort of fly across to the other list. And if you click on it to uncomplete, it will animate it and fly back. +And what's great is within Svelte because they have this crossfade as a native idea; all you need to say is like, "It was on this list, now it's on this list." And as long as it's identifiable, Svelte handles that crossfade and all the animations. So it's that kind of high-fidelity experience that I think we want. And that leads us to somewhat more complex applications, and I totally get that. I want those experiences as well. But I want to ask some questions, and I want to do away with the phrasing single-page application entirely. I don't want to say that anymore. I want to say URLs are one honking good idea. Let's have more of those. +And also, just to name it, Inertia is a framework that allows me to build using some of the newer technologies but not have to give up on URLs, give up on server-side logic as the primary thing. So I will continue to shout my deep affection for Inertia in this moment once again. +STEPH: Cool. Thanks. That was really helpful. That does sound really neat. So in the ideal world, we have URLs. We also have high fidelity and cool interactions and transitions on our pages. We don't have to give it a fancy name like single-page application or then multi-page application. I do wonder, with our grumpiness or our complaint about the URLs, is that fair to call it grumpy? +CHRIS: It's fair to call it grumpy, although you don’t need to loop yourself in with me. I'm the grump today. +STEPH: [laughs] +CHRIS: You're welcome to come along for the ride if you'd like. And I'm trying to find a positive way to talk about it. But yeah, it's my grumpytude. +STEPH: Well, I do feel similarly where I really value URLs, and I value the ability to bookmark and share, like you said earlier. And I do wonder if there is a way to still have that even if we don't have the URL. So one of the things that I do is I'll inspect the source code. And if I can find an ID that's for a particular header or section on the page, then I will link someone to a section of that page by then adding the ID into the URL, and that works. It's not always great because then I have to rely on that being there. But it's a fix, it's a workaround. +So I wonder if we could still have something like that, that as people are building content that can't be bookmarked or the URL doesn't change explicitly, or reference that content, to add more thoughtful bookmark links, essentially, or add an ID and then add a user-facing link that says, "Hey, if you want to link someone to this content, here you go." And under the hood, it's just an ID. But most people aren't going to know how to do that, so then you're helping people be able to reference content because we're used to URLs, so just thinking outside the box. I wonder if there are ways that we can still bookmark this content, share it with people. But it's okay if the URL isn't the only way that we can bookmark or reference that content. +CHRIS: It's interesting that you bring that up, so the anchor being the thing after the hash symbol in the URL. I actually use that a ton as well. I think I built a Chrome extension a while back to try what you're saying of I'll inspect the DOM. I did that enough times that I was like, what if the DOM were to just tell me if there were an ID here and I could click on a thing? Some people's blogs...I think the thoughtbot blog has this at this point. All headers are clickable. So they are hyperlinks that append that anchor to the URL. +So I wouldn't want to take that and use that functionality as our way to get back to URLs that are addressing resources because that's a way to then navigate even further, which I absolutely love, to a portion of the page. So thinking of Wikipedia, you're on an article, but it's a nice, long article. So you go down to the section, which is a third of the way down the page. And it's, again, a very big page, so you can link directly to that. And when someone opens that in their browser, the browsers know how to do this because it's part of the web platform, and it's wonderful. +So we've got domains, we've got paths, we've got anchors, we've got query params. I want to use them all. I want to embrace them. I want that to be top of mind. I want to really think about it and care about that as part of the interface to the application, even though most users like you said, are not thinking about the shape of a URL. But that addressability of content is a thing that even if people aren't thinking of it as a primary concern, I think they know it when they...it's one of those like, yeah, no, that app's great because I can bookmark anything, and I can get to anything, and I can share stuff with people. +And I do like the idea of making the ID-driven anchor deep links into a page more accessible to people because you and I would go into the DOM and slice it out. Your average web user may not be doing that, or that's much impossible to do on mobile, so yes, but only more so in my mind. [laughs] I don't want to take anchors and make them the way we do this. I want to just have all the URL stuff, please. +Mid-roll Ad +Now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. +With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. +If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. +STEPH: I have a confession from earlier when you were talking about the examples for those transitions. And you were describing where you take an action, and then the page does a certain motion to let you know that new content is coming onto the page and the old content is fading away. And I was like, oh, like a page reload? We're just reimplementing a page reload? [laughs] That's what we have? +CHRIS: You have a fancy, though. +STEPH: Fancy, okay. [laughs] But that felt a little sassy. And then you provided the other really great example with the to-do list. So what are some good examples of a SPA? Do you have any in mind? I think there are some use cases where...so Google Maps, that's the one that comes to mind for me where URLs feel less important. Are there other applications that fit that mold in your mind? +CHRIS: Well, so again, it's sort of getting at the nomenclature, and how much does the acronym actually inform what we're thinking about? But taking Google Maps as an example, or Trello is a pretty canonical one in my mind, most people say those are single-page applications. And they are probably in terms of what the tech actually is, but there are other pages in those apps. There's a settings page, and there's a search page, and there's this and that. And there's like the board list in Trello. +And so when we think about Trello, there is the board view where you're seeing the lists, and you can move cards, and you can drag and drop and do all the fancy stuff. That is a very rich client-side application that happens to be one page of the Trello web app and that one being higher fidelity, that one being more stateful. Stateful is probably the thing that I would care about more than anything. And so for that page, I would be fine with the portion of the JavaScript that comes down to the client being a larger payload, being more complex, and probably having some client-side state management for that. But fundamentally, I would not want to implement those as a true client-side application, as a true SPA. And I think client-side routing is really the definition point for me on this. +So with Trello, I would probably build that as an Inertia-type application. But that one page, the board page, I'd be like, yeah, sorry, this is not going to be the normal Inertia thing. I'm going to have to be hitting JSON endpoints that are specifically built for this page. I'm going to have a Redux store that's local. I'm going to lean into all of that complex state management and do that within the client-side app but not use client-side routing for actual page-level transitions, the same being true for Google Maps. The page where you're looking at the map, and you can do all sorts of stuff, that's a big application. But it is one page within the broader website, if you will. And so, I still wouldn't want client-side routing if I can avoid it because I think that is where I run into the most problems. +And that thing I was talking about where I was on the login page for a second, and then I wasn't; I do not like that thing. So if I can avoid that thing, which I have now found a way to avoid it, and I don't feel like I'm trading off on that, I feel like it's just a better experience but still reserving the right to this part of the application is so complex. This is our Wiziwig drag and drop graphical editor thing, cool. That's going to have Redux. That's going to have client-side state management, all that stuff. But at no point does single-page application feel like the right way to describe the thing that we're building because I still want to think about it as holistically part of the full web app. Like the Trello board view is part of the Trello web app. And I want it all to feel the same and move around the same. +STEPH: Yeah, that makes sense. And it's funny, as you were mentioning this, I pulled up Google Maps because I definitely only interact with that heavy JavaScript portion, same for Trello. And I wasn't even thinking about the fact that there are settings. By the way, Google Maps does a lot. I don't use hardly any of this. But you make a great point. There's a lot here that still doesn't need such heavy JavaScript interaction and doesn't really fit that mold of where it needs to be a single-page app or even needs to have that amount of interactivity. And frankly, you may want URLs to be able to go specifically to these pages. +CHRIS: That actually is an interesting, perhaps counterpoint to what I'm saying. So if you do have that complex part of one of your applications and you still want URL addressability, maybe you need client-side routing, and so that becomes a really difficult thing to answer in my mind. And I don't necessarily have a great answer for that. I'm also preemptively preparing myself for anyone on the internet that's listening to this and loves the idea of single-page applications and feels like I'm just building a straw man here, and none of what I'm saying is actually real and whatnot. +And although I try to...I think we generally try and stay in the positive space of like what's good on the internet. This is a rare case where I'm like, these are things that are not great. And so I think in this particular case, leaning into things that I don't like is the way to properly capture this. And giant JavaScript bundles where the entirety of the application logic comes down in 15-megabyte download, even if you're on 3G on a train; I don't like that. +I don't like if we have flashes of a layout that they can get ripped away b; it’secause it turns out we actually aren't authorized to view that page, that sort of thing. So there are certain experiences from an end client perspective that I really don't like, and that's mostly what I take issue with. Oh, also, I care deeply about URLs, and if you don't use the URL, then I'm going to be sad. Those are my things. +Hopefully, that list is perhaps a better summary of it than like...I don't want it to seem like I'm just coming after SPA as a phrase or a way of thinking because that's not as real of a conversation. But those particular things that I just highlighted don't feel great. And so I would rather build applications that don't have those going on. And so if there's a way to do that that still fits any other mold or is called whatever, but largely what I see called an SPA often has those sorts of edge cases. And I do not like those edge cases. +STEPH: Yeah, I like how you're breaking it down where it's less of this whole thing like I can't get on board with any of it. You are focusing on the things that you do have concerns with. So there can be just more interesting, productive conversations around those concerns versus someone feels like they have to defend their view of the world. +I have found that I think I'm a bit unique in this area where when people have a really differing opinion than mine, that gets me really excited because then I want to know. Because if I believe very strongly in something and I just think this is the way and then someone very strongly says like, "No, that's not," I'm like, "Oh yeah. Okay, we should talk because I'm interested in why you would have such a different opinion than mine." And so, I typically find those conversations really interesting. As long as everybody's coming forward to be productive and kind, then I really enjoy those conversations. +CHRIS: That is, I think, an interesting frame that you have there. But I think I'm similar, and hopefully, my reframing there puts it in the way that can be a productive conversation starter as opposed to a person griping on a podcast. But with that said, that's probably enough of me griping on a podcast. [chuckles] So what's up in your world, Steph? +STEPH: Oh, there are a couple of things going on. So I am in that pre-vacation chaotic zone where I'm just trying to get everything done. And I heard someone refer to it recently as going into a superman or superwoman mode where you're just trying to do all the things before you go, which is totally unreasonable. So that has been interesting. And the name of the game this week has been delegate, delegate, delegate, and it seems to be going fairly well. [chuckles] So I'm very excited for the downtime that I'm about to have. +And some other news, some personal news, Utah, my dog, turns one. I'm very excited. I'm pretty sure we'll have a dog birthday party and everything. It's going to be a thing. I'll share pictures on Twitter, I promise. +CHRIS: So he's basically out of the puppy phase then. +STEPH: Yeah, the definition for being a puppy seems to be if you're a year or younger, so he will not be an adult. Teenager? I don't know. [laughs] +CHRIS: What about according to your lived experience? +STEPH: He has calmed down a good bit. +CHRIS: Okay, that's good. +STEPH: He has gotten so much better. Back when we first got him, I swear I couldn't get 15 minutes of focus where he just needed all the attention. Or it was either constant playtime, or I had to put him in his kennel since we're using that. That was the only way I was really ever getting maker’s time. And now he will just lounge on the couch for like an hour or two at a time. It's glorious. And so he has definitely calmed down, and he is maturing, becoming such a big boy. +CHRIS: Well, that is wonderful. Astute listeners, if you go back to previous episodes over the past year, you can certainly find little bits of Utah sprinkled throughout, subtle sounds in the background. +STEPH: He is definitely an important part of the show. And in some other news, I have a question for you. I'm in need of some consulting help, and I would love to run something by you and get your thoughts. So specifically, the project that I'm working on, we are always in a state where there's too much to do. And even though we have a fairly large team, I want to say there's probably somewhere between 7 and 10 of us. And so, even though we have a fairly...for thoughtbot, that's a large team to have on one project. So even though there's a fair number of us, there's always too much to do. Everything always feels like it's urgent. I can't remember if I've told you this or not, but in fact, we had so many tickets marked as high priority that we had to introduce another status to then indicate they're really, really high, and that is called Picante. [chuckles] +CHRIS: Well, the first part of that is complicated; the actual word that you chose, though, fantastic. +STEPH: I think that was CTO Joe Ferris. I think he's the one that came up with Picante. So that's a thing that we have, and that really represents like, the app is down. So something major is happening. That's like a PagerDuty alert when we get to that status where people can't access a page or access the application. So there's always a lot to juggle, and it feels a lot like priority whiplash in terms that you are working on something that is important, but then you suddenly get dragged away to something else. And then you have to build context on it and get that done. And then you go back to the thing that you're working on. +And that's a really draining experience to constantly be in that mode where you're having to pivot from one type of work to the other. And so my question to you (And I'll be happy to fill in some details and answer questions.) is how do you calm things down? When you're in that state where everything feels so urgent and busy, and there's too much to do, how do you start to chip away at calming things down where then you feel like you're in a good state of making progress versus you feel like you're just always putting out fires or adding a band-aid to something? Yeah, that's where I’m at. What thoughts might you have, or what questions do you have? +CHRIS: Cool. I'm glad you brought an easy question that I can just very quickly answer, and we'll just run with that. It is frankly...what you're describing is a nuanced outcome of any number of possible inputs. And frankly, some of them may just be like; this is just the nature of the thing. Like, we could talk about adding more people to the project, but the mythical man-month and that idea that you can't just throw additional humans at the work and suddenly have that makes sense because now you have to coordinate between those humans. And there's that wonderful image of two people; there's one line of communication. Three people, suddenly there are a lot more lines of communication. Four people, wow. The exponential increase as you add new people to a network graph, that whole idea. +And so I think one of the first questions I would ask is, and again, this is probably not either/or. But if you would try and categorize it, is it just a question of there's just a ton of work to do and we're just not getting it done as quickly as we would want? Or is it that things are broken, that we're having to fix things, that there are constant tweaks and updates, that the system doesn't support the types of changes that we want, so any little thing that we want to do actually takes longer? Is it the system resisting, or is it just that there's too much to do? If you were to try and put it into one camp or the other. +STEPH: It is both, my friend. It is both of those camps. [chuckles] +CHRIS: Cool. That makes it way easier. +STEPH: Totally. [laughs] To add some more context to that, it is both where the system is resistant to change. So we are trying to make improvements as we go but then also being respectful of the fact if it is something that we need to move quickly on, it doesn't feel great where you never really get to go back and address the system in a way that feels like it's going to help you later. But then, frankly, it's one of those tools that we can use. So if we are in the state where there's too much to do, and the system is resisting us, we can continue to punt on that, and we can address things as we go. +But then, at some point, as we keep having work that has slowed down because we haven't addressed the underlying issues, then we can start to have that conversation around okay; we’ve done this twice now. This is the third time that this is going to take a lot longer than it should because we haven't really fixed this. Now we should talk about slowing things down so we can address this underlying issue first and then, from now on, pay the tax upfront. So from now on, it's going to be easier, but then we pay that tax now. So it is a helpful tool. It's something that we can essentially defer that tax to a later point. But then we just have to have those conversations later on when things are painful. Or it often leads to scope creep is another way that that creeps up. +So we take on a ticket that we think, okay, this is fairly straightforward; I don't think there's too much here. But then we're suddenly getting into the codebase, and we realize, oh, this is a lot more work. And suddenly, a ticket will become an epic, and you really have one ticket that's spiraled or grown into five or six tickets. And then suddenly, you have a person that's really leading like a mini project in terms of the scope of the work that they are doing. +So then that manifests in some interesting ways where then you have the person that feels a bit like a silo because they are the ones that are making all these big changes and working on this mini-project. And then there's the other one where there's a lot to do. There are a lot of customers, and there's a lot of customization for these customers. So then there are folks that are working really hard to keep the customers happy to give them what they need. And that's where we have too much to do. And we're prioritizing aggressively and trying to make sure that we're always working on the top priority. So like you said, it's super easy stuff. +CHRIS: Yeah. To say it sincerely and realistically, you're just playing the game on hard mode right now. I don't think there is any singular or even multiple easy answers to this. I think one question I would have particularly as you started to talk about that, there are multiple customers each with individualized needs, so that's one of many surface areas that I might look t say, "Can we sort of choke things off there?" +So I've often been in organizations where there is this constant cycle of the sales team is going out. They're demoing against an InVision mock. They're selling things that don't exist. They're making promises that are ungrounded and, frankly, technically infeasible or incredibly complicated, but it's part of the deal. They just sold it, and now we have to implement it as a team. I've been on teams where that was just a continuing theme. And so the engineering team was just like, "We can never catch up because the goalpost just keeps moving." +And so to whatever degree that might be true in this case, if there are ten different customers and each of them right now feels like they have an open line to make feature requests or other things like that, I would try to have the conversation of like, we've got to cut that off right now because we're struggling. We're not making the forward progress that we need to, and so we need to buy ourselves some time. And so that's one area that I would look at. +Another would be scope, anywhere that you can, go into an aggressive scope cutting mode. And so things like, well, we could build our own modal dialogue for this, but we could also use alert just like the JavaScript alert API. And what are all of the versions of that where we can say, "This is not going to be as nice, and as refined, and as fitting with the brand and feel and polish of the website. But ways that we can make an application that will be robust, that will work well on all of the devices that our users might be using but saves us a bunch of development time"? That's definitely something that I would look to. +What you described about refactoring is interesting. So I agree with we're not in a position where we can just gently refactor as we find any little mess. We have to be somewhat ruthless in our prioritization there. But like you said, when you get to that third time that a thing is working way harder, then take the time to do it. But really, like just every facet of the work, you just have to be a little better. If you're an individual developer and you're feeling stuck, raise your hand all the earlier because that being stuck, we don't have spare cycles right now. We need everybody to be working at maximum efficiency. And so if you've hit a wall, then raise your hand and grab somebody else, get a pair, rubber duck, whatever it is that will help you get unstuck. Because we're in a position where we need everybody moving as fast as they can. +But also to say all of those aren't free. Every one of those where you're just like, yeah, do it the best you can. Dial it up to 11 on every front. That's going to drain the team, and so we have to also be mindful of that. This can't be forever. And so maybe it is bringing some new people onto the team or trying to restructure things so that we can have smaller communication channels. So it's only four people working together on this portion of the application, and therefore their communication lines are a bit simpler. That's one way that we can maybe save a little bit. But yeah, none of these are free. And so, we also need to be mindful that we can't just try harder forever. [laughs] That's a way to burn out the team. But what you're describing is like the perfect storm of every facet of this is difficult, and there's no singular answer. +There's the theory of constraints (I think I'm saying that right.) where it's like, what's the part of our process that is introducing the most slowdowns? And so you go, and you tackle that. So if you imagine a website and the app is slow is the report that you're getting, and you're like, okay, what does that mean? And you instrument it, and you log some stuff out. And you're like, all right, turns out we have tons of N+1s. So frankly, everything else doesn't matter. I don't care if we've got a 3 megabyte JavaScript bundle right now; the 45 N+1s on the dashboard that's the thing that we need to tackle. So you start, and you focus on that. +And now you've removed that constraint. And suddenly, the three megabyte JavaScript bundle is the new thing that is the most complicated. So you're like, okay, cool, let's look into tree shaking or whatever it is, but you move from one focus to another. And so that's another thing that could come to play here is like, which part of this is introducing the most pain? Is it feature churn? Is it unrealistic sales expectations? Is it developers getting stuck? And find the first of those and tackle it. But yeah, this is hard. +STEPH: Yeah, it is. That's all really helpful, though. And then, I can share some of the things that we are experimenting with right now and then provide an update on how it's going. And one of the things that we're trying; I think it's similar to the theory of constraints. I'm not familiar with that, but based on the way you described it, I think they're related. +One of the things that we are trying is breaking the group into smaller teams because there are between 7 and 10 of us. And so, trying to jump from one issue to the next you may have to really level up on different portions of the application to be able to make an impact. And there are areas that we really need infrastructure improvements and then essentially paving the way for other people to be able to move more quickly. We do have to prioritize some of that work as well. +So if we break up into smaller teams, it addresses a couple of areas, or at least that's the goal is to address a couple of areas. One is we avoid having silos so that people aren't a bottleneck, or they're the only ones that are really running this mini-project and the only one that has context. Because then when that person realizes the scope has grown, bringing somebody on to help feels painful because then you're in an urgent state, but now you have to spend time leveling someone else up just so that they can help you, and that's tough. +So the goal is that by having smaller teams, we will reduce that from happening because at least everything that feels like a small project...and by feels like a small project, I mean if we have more than one ticket that's associated with the same theme, that's going to start hinting at maybe this is more than just one ticket itself, and it might actually belong to an epic. Or there's a theme here, and maybe we should have two people working on this. And breaking people into groups, then we can focus on some people are focused more on the day-to-day activity. Some people are focused on another important portion of the codebase as we have what may be extracted. I'm going to say this, but we're going to move on, maybe extracted into its own service. [laughs] I know that's a hot one for us, so I'm just going to say it. +CHRIS: I told you I can't be nerd sniped. This is fine. Let's continue on. [laughs] +STEPH: [laughs] And then a small group can also focus on some of those infrastructure improvements that I was alluding to. So smaller teams is something that we are trying. +We are also doing a really great job. I've been really happy and just proud of the team where folks are constantly reaching out to each other to say, "Hey, I'm done with my ticket. Who can I help?" So instead of immediately going to the backlog and grabbing the next thing. Because we recognize that because of this structure where some people are some silos, they have their own little mini backlog, which we are working to remove that to make sure everything is properly prioritized instead of getting assigned to one particular person. But we are reaching out to each other to say, "Hey, what can I do to help? What do you need to get done with your work before I go pick something else up?" +The other two things that come to mind is who's setting the deadlines? I think you touched on this one as well. It's just understanding why is it urgent? Does it need to be urgent? What is the deadline? Is this something that internally we are driving? Is this something that was communicated without talking to the rest of the team? Is this just a really demanding customer? Are they setting unrealistic expectations? But having more communication around what is the sense of urgency? What happens if we miss this deadline? What happens if we don't get to this for a week, a month? What does that look like? +And then also, my favorite are retros because then we can vote on what feels like the highest priority in terms of pain points or run these types of experiments like the smaller teams. So those are the current strategies that we have. And I'm very interested to see how they turn out because it is a tough way. Like you said, it's challenge mode, and it is going to burn people out. And it does make people feel fatigued when they have to jump from one priority to the next. So I'm very interested. It's a very interesting problem to me too. It just feels like something that I imagine a lot of teams may be facing. So I'm really excited if anybody else is facing a similar issue or has gone through a similar challenge mode; I’d love to hear how your team tackled it. +CHRIS: Yeah, I'm super interested to hear the outcome of those experiments. As a slightly pointed question there, is there any semi-formal version of tracking the experiments? And is it just retro to retro that you're using for feedback on that? I've often been on teams where we have retro. We come up with it, and we're like, oh, this is a pain point. All right, let's try this. And then two weeks later, we're like, oh, did anyone actually do that? And then we just forget. And it's one of those things that I've tried to come up with better ways to actually manage, make slightly more explicit the experiments, and then have a timeline, have an almost scientific process of what's the hypothesis? What's the procedure? What are the results? Write up an executive summary. How'd it go? +STEPH: We are currently using retro, but I like that idea of having something that's a bit more concrete. So we have action items. And typically, going through retro, I tend to revisit the action items first as a way to kick off retro. So then that highlights what did we do? What did we not do? What do we not want to do anymore? What needs to roll over to the current iteration? And I think that could be just a way that we chat about this. We try something new, and we see how it's going each week in retro. But I do like the idea of stating upfront this is what we're looking to achieve because I think that's not captured in the retro action item. We have the thing that we're doing, but we haven't captured this is what we hope to achieve by taking this experiment on. +Mid-roll Ad +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +STEPH: As for the other thing that you mentioned, I do have an idea for that because a former client that I worked with where we had experiments or things that we wanted to do, we were using Trello. And so we would often take those action items…or it was even more of a theme. It wasn't something that could be one-and-done. It was more of a daily reminder of, hey; we are trying this new thing. And so, we want to remind you each day to embrace this experiment and this practice. And so we would turn it into a Trello ticket, and then we would just leave it at the top of the board. So then, each day, as we were walking the board, it was a nice reminder to be like, hey, this is an ongoing experiment. Don't forget to do this. +CHRIS: I do like the idea of bringing it into a stand-up potentially as like that's just a recurring point that we all have. So we can sort of revisit it, keep it top of mind, and discard it at some point if it's not useful. And if we're saying we're doing a thing, then let's do the thing and see how it goes. So yeah, very interested to hear the outcomes of the experiment and also the meta experiment framework that you're going to build here. Very interested to hear more about that. +And just to say it again, this sounds like your perfect storm is not quite right because it doesn't sound like there's a ton of organizational dysfunction here. It sounds like this is just like, nah, it's hard. The code's not in perfect shape, but no code is. And there's just a lot of work to be done. And there are priorities because frankly, sometimes in the world, there are priorities, and you're sort of at the intersection of that. +And I've been in plenty of teams where it was hard because of humans. In fact, that's often the reason of we're sort of making up problems, or we're poorly communicating or things like that. But it sounds like you're in the like, nope, this is just hard. And so, in a way, it sounds like you're thinking about it like, I don't know, it's kind of the challenge that I signed up for. Like, if we can win this, then there's going to be some good learnings that come out of that, and we're going to be all the better. And so, I wish you all the best of luck on that and would love to hear more about it in the future. +STEPH: Thank you. And yeah, it has been such an interesting project with so many different challenges. And as you've mentioned, that is one area that is going really well where the people are wonderful. Everybody is doing their best and working hard. So that is not one of the competing challenges. And it is one of those; it’s hard. There are a lot of external factors that are influencing the priority of our work. And then also, some external areas that we don't have control over that are forcing some of those deadlines where customers need something and not because they're being fussy, but they are themselves reacting to external deadlines that they don't have control over. +So it is one of those where the people are great, and the challenges are just real, and we're working through them together. But it's also hard. But it's helpful chatting through all the different challenges with you. So I appreciate all of your thoughts on the matter. And I'll report some updates once I have some more information. +On that note, shall we wrap up? +CHRIS: Let's wrap up. +STEPH: The show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey. +STEPH: And I'm @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + You know what really grinds Chris' gears? (Spoiler Alert: It's Single-Page Applications.)

+ +

Steph needs some consulting help. So much to do, so little time.

+ + + +

Transcript:

+ +

CHRIS: I have restarted my recording, and we are now recording. And we are off on the golden roads. Isn't software fun?

+ +

STEPH: Podcast battle. Here we go!

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been?

+ +

CHRIS: Happy Friday to you as well. My week's been good with the exception of right before we started this recording, I had one of those experiences. You know the thing where software is bad and software is just terrible overall? I had one of those. And very briefly to describe it, I started recording, but I could hear some feedback in my headphones. So I was like, oh no, is that feedback going to show up on the final recording? Which I really hope it doesn't. Spoiler alert - listener, if I sound off, sorry about that. But so I stopped recording and then I went to go listen to the file, and I have our audio software configured to record directly to the desktop. And it does that normally quite well. But for some reason, the file wasn't there. But I remember this recently because I ran into it another time.

+ +

For some reason, this is Finder failing me. So the thing that shows me the files in a graphical format, at least on my operating system. Although I think it also messes up in the terminal maybe. That feels like it shouldn't be true, but maybe it is. Anyway, I had to kill all Finder from the terminal to aggressively restart that process. And then suddenly, Finder was like, oh yeah, there's totally files there, absolutely. They were there the whole time. Why do you even ask?

+ +

And I know that state management is a hard problem, I am aware. I have felt this pain. I have been the person who has introduced some bugs related to it, but that's not where I want to experience it. Finder is one of those applications that I want to just implicitly trust, never question whether or not it's just sneakily telling me that there are files that are not there or vice versa. So anyway, software.

+ +

STEPH: I'm worried for your OS. I feel like there's a theme lately [chuckles] in the struggles of your computer.

+ +

CHRIS: On a related note, I had to turn off transparency in my terminal because it was making my computer get very hot. [chuckles]

+ +

STEPH: Oh no, you're not a hacker any more.

+ +

CHRIS: I'm not. [chuckles] I just have a weird screen that's just dark. And jellybeans is my color scheme, so there's that going on. That's in Vim specifically. Pure is my prompt. That's a lovely little prompt. But lots of Day-Glo colors on just a black background, not the cool hacker transparency. I have lost some street cred.

+ +

STEPH: What is your prompt? What did you say it is?

+ +

CHRIS: Pure.

+ +

STEPH: Pure, I don't know that one.

+ +

CHRIS: It is by Sindre Sorhus; I think is his name. That's his Twitter handle, GitHub name. He is a prolific open-source creator in the Node world, particularly. But he created this...I think it's a Bash and a Zsh prompt. It might be for others as well. It's got a bunch of features. It's pretty fast. It's minimal. It got me to stop messing around with my prompt, which was mostly what I was going for. And it has a nice benefit that occasionally now I'll be pairing with someone, and I'll be like, "Your prompt looks like my prompt. Everything is familiar. This is great."

+ +

STEPH: Well, if you get back in the waters of messing around with your prompts again, I'm using Starship. And I hadn't heard of Pure before, but I really like Starship. That's been my new favorite.

+ +

CHRIS: Wow.

+ +

STEPH: Wow.

+ +

CHRIS: I mean, on the one hand…

+ +

STEPH: You're welcome. [laughs]

+ +

CHRIS: On the one hand, thank you. On the other hand, again, let me lead in with the goal was to stop messing around with my prompt. So you're like, oh, cool. Here's another prompt for you, though. [chuckles]

+ +

STEPH: [laughs] But my goal is to nerd snipe you into trying more things because it's fun.

+ +

CHRIS: I don't know if you know this, but I am impervious to nerd sniping.

+ +

STEPH: [laughs]

+ +

CHRIS: So try as you might, I shall remain steady in my course of action.

+ +

STEPH: Are we playing two truths and a lie? Is that what we're doing today? [laughs]

+ +

CHRIS: Nah, just one lie. It's easier. Everybody wins one lie.

+ +

STEPH: [laughs]

+ +

CHRIS: But anyway, in other news, we're going to do a segment called this really grinds my gears. That's today's segment, which is much like when I do a good idea, terrible idea. But this is one that I'm sure I've talked about before. But there's been some stuff that I saw moving around on the internet as one does, and it got these ideas back into my head. And it's around the phrase single-page application. I am not a fan of that phrase or SPA as the initialism. Thank you, Edward Loveall, for teaching me the difference between an initialism and an acronym. I really hope I'm getting it right, by the way, [laughs] SPA as people call them these days.

+ +

I feel weird because of how much I care about this thing, how much I care about this idea, and how much whenever I hear this acronym, I get a little bit unhappy. And so there's a part of it that's I really do think our words shape our thinking. And I think single-page application has some deeply problematic ideas. Most notably, I think one of the most important things about building web applications is the URL. And those are different pages, at least in my head. I don't know of a different way to think about this.

+ +

But if you are not emphasizing the URL and the fact that the URL is a way to address different pages or resources within your application, then you are throwing away one of the greatest advancements that humankind has made, in my mind. I care a lot about URLs; it turns out. And it's not inherent to an SPA that you will not be thinking about URLs. But again, in that idea that our words shape our thinking, by calling it an SPA, by leaning into that idea, I think you are starting down a path that leads to bad outcomes. I'm going to pause there because I'm getting kind of ranty. I got more to say on the topic. But what do you think?

+ +

STEPH: Yeah, these are hot takes. I'm into it. I'm pretty sure that I know why URLs are so important to you and more of your feelings around why they're important. But would you dive in a bit deeper as to why you really cherish URLs, and why they're so important, and why they're one of the greatest advancements of humanity?

+ +

CHRIS: [laughs] It sounds lofty when you say it back to me, but yeah. It's interesting that as you put into a question, it is a little bit hard to name. So there are certain aspects that are somewhat obvious. I love the idea that I can bookmark or share a given resource or representation of a resource very simply. Like the URL, it's this known thing. We can put hyperlinks in a document. It's this shared way to communicate, frankly, very complex things.

+ +

And when I think of a URL, it's not just the domain and the path, but it's also any query parameters. So if you imagine faceted search on a website, you can be like, oh, filter down to these and only ones that are more than $10, and only ones that have a future start date and all those kinds of nuance. If you serialize that into the URL as part of the query param, then that even more nuanced view of this resource is shareable is bookmarkable is revisitable.

+ +

I end up making Alfred Workflows that take advantage of the fact that, like, oh, I can look at this URL scheme, and I can see where different parts are interpolated. And so I can navigate directly to any given thing so fast. And that's deeply valuable, and it just falls naturally out of the idea that we have URLs. And so to not deeply embrace that, to not really wrap your arms around it and give that idea a big hug feels weird to me.

+ +

STEPH: Yeah, I agree. I remember we've had this conversation in the past, and it really frustrates me when I can't share specific resources with folks because I don't know how to link to it. So then I can send you a link to the application itself to the top URL. But then I have to tell you how to find the information that I thought was really helpful. And that feels like a step backward.

+ +

CHRIS: Yeah. That ability to say, "Follow this link, and then it will be obvious," versus "Go to this page, click on this thing, click on the dropdown, click on this other thing." Like, that's just a fundamentally different experience. So one of the things that I saw that got me thinking about this was I saw folks referring to single-page applications but then contrasting them with MPAs, which are multiple-page applications.

+ +

STEPH: So the normal application? [laughs]

+ +

CHRIS: And I was like, whoa, whoa, everybody. You mean like a website or a web app? As much as I was angry at the first initialism, this second one's really getting me going. But it really does speak to what are we doing? What are we trying to build? And as with anything, you could treat this as a binary as just like there are two options. There are either websites which, yeah, those have got a bunch of URLs, and that's all the stuff. And then there are web apps, and they're different. And it's a bundle of JavaScript that comes down, boots up on the client, and then it's an app thing. And who cares about URLs? I think very few people would actually fall in that camp.

+ +

So I don't really believe that there is a dichotomy here. I think, as always, it's a continuum; it’s a spectrum. But leaning into the nomenclature of single-page application, I think pushes you more towards that latter end of the spectrum. I think there are other things that fall out of it. Like, I believe deeply in having the server know more, have more of the logic, own more of the logic, own more authorization and routing, and all of those things because really great stuff falls out of that. And that one has more of a trade-off, I'd say.

+ +

But I won't name any names, but there is a multiple billion-dollar company whose website I had to interact with recently. And you land on their page on their marketing site. And then, if you click log in, it navigates you to the application, so a separate domain or a separate subdomain, the application subdomain, and the login page there. And the login page renders, and then I go to fill in my username and password. Like, my mouse makes it all the way to click on the little box or whatever I'm doing if I'm using keyboard things. But I have enough time to actually start to interact with this page.

+ +

And then suddenly, it rips away, and it actually just renders the authenticated application because it turns out I was already logged in. But behind the scenes, they're doing some JWT dance around that they're checking; oh no, no, you're already logged in, so never mind. We don't need to show you the login page, but I was already on the login page.

+ +

And my feeling is this sort of brittle UI; this sort of inconsistency erodes my trust in that application, particularly when I'm on the login page. That is a page that matters. I don't believe that they're doing anything fundamentally insecure. But I do have the question in my head now. I'm like, wait, what's going on there, everybody? Is it fine? Was that okay? Or if you see something that you shouldn't see and then suddenly it's ripped away from you, if you see half of a layout that's rendered on a page and then suddenly you see, no, no, no, you actually don't have access to that page, that experience erodes my trust.

+ +

And so, I would rather wait for the server to fully resolve, determine what's going to happen, and then we get a response that is holistically consistent. You either have access, or you don't, that sort of thing. Give me a loading indicator; give me those sorts of things. I'm fine with that. But don't render half of a layout and then redirect me back away.

+ +

STEPH: I feel like that's one of the problems with knowing too much because most people are not going to pick up on a lot of the things that you're noticing and caring deeply about where they would just see like, oh, I was logged in and be like, huh, okay, that was a little weird, but I'm in and just continue on. Versus other folks who work very closely to this who may recognize and say, "That was weird." And the fact that you asked me to log in, but then I was already logged in, did you actually log me in correctly? What's happening? And then it makes you nervous.

+ +

CHRIS: Maybe. Probably. But I wonder…the way you just said that sounds like another dichotomy. And I would say it's probably more of a continuum of an average not terribly tech-savvy user would still have a feeling of huh, that was weird. And that's enough. That's a little tickle in the back of your brain. It's like, huh, that was weird.

+ +

And if that happens enough times or if you've seen someone who uses an application and uses it consistently, if that application is reasonably fast and somewhat intuitive and consistent, then they can move through it very quickly and very confidently. But if you have an app that half loads and then swaps you to another page and other things like that, it's very hard to move confidently through an application like that. I do think you're right in saying that I am over-indexed on this, and I probably care more than the average person, but I do care a lot.

+ +

I do think one of the reasons that I think this happens is mobile applications came along, and they showed us a different experience that can happen and also desktop apps for some amount of time this was true. But I think iOS apps, in particular really great ones, have super high fidelity interactions. And so you're like, you're looking at a list view, and then you click on the cell for that list view. And there's this animated transition where the title floats up to the top and grows just a little bit. And the icon that was in the corner moves up to the corner, and it gets a little bigger. And it's this animated transition to the detailed view for that item. And then if you go back, it sort of deanimates back down.

+ +

And that very consistent experience is kind of lovely when you get it right, but it's really, really hard. And people, I think, have tried to bring that to the web, but it's been such a struggle. And it necessitates client-side routing and some other things, or it's probably easiest to do if you have those sorts of technologies at play, but it's been a struggle. I can't think of an application that I think really pulls that off. And I think the trade-offs have been very costly.

+ +

On the one positive note, there was a tweet that I saw by Sarah Drasner that was talking about smooth and simple page transitions with the shared element transition API. So this is a new API that I think is hoping to bring some of this functionality to the web platform natively so that web applications can provide that higher fidelity experience. Exactly how it'll work whether or not it requires embracing more of the single-page application, client-side routing, et cetera, I'm not sure on that. But it is a glimmer of hope because I think this is one of the things that drives folks in this direction. And if we have a better answer to it, then maybe we can start to rethink the conversation.

+ +

STEPH: So I think you just said shared element transitions. I don't know what that is. Can you talk more about that?

+ +

CHRIS: I can try, or I can make a guess. So my understanding is that would be that sort of experience where you have a version of a certain piece of content on the page. And then, as you transition to a new page, that piece of content is still represented on the new page, but perhaps the font size is larger, or it's expanded, or the box around it has grown or something like that. And so on mobile, you'll often see that animate change. On the web, you'll often see the one page is just completely replaced with the other. And so it's a way to have continuity between, say, a detailed view, and then when you click on an item in it, that item sort of grows to become the new page. And now you're on the detail page from the list page prior.

+ +

There's actually a functionality in Svelte natively for this, which is really fancy; it's called crossfade. And so it allows you to say, "This item in the component hierarchy in the first state of the application is the same as this item in the second state of the application." And then, Svelte will take care of transitioning any of the properties that are necessary between those two.

+ +

So if you have a small circle that is green, and then in the next state of the application, it's a blue rectangle, it will interpolate between those two colors. It will interpolate the shape and grow and expand it. It will float it to its new location. There is a really great version of it in the Svelte tutorial showing a to-do list. And so it's got a list on the left, which is undone things, and a list on the right that is done things. And when you click on something to complete it, it will animate it, sort of fly across to the other list. And if you click on it to uncomplete, it will animate it and fly back.

+ +

And what's great is within Svelte because they have this crossfade as a native idea; all you need to say is like, "It was on this list, now it's on this list." And as long as it's identifiable, Svelte handles that crossfade and all the animations. So it's that kind of high-fidelity experience that I think we want. And that leads us to somewhat more complex applications, and I totally get that. I want those experiences as well. But I want to ask some questions, and I want to do away with the phrasing single-page application entirely. I don't want to say that anymore. I want to say URLs are one honking good idea. Let's have more of those.

+ +

And also, just to name it, Inertia is a framework that allows me to build using some of the newer technologies but not have to give up on URLs, give up on server-side logic as the primary thing. So I will continue to shout my deep affection for Inertia in this moment once again.

+ +

STEPH: Cool. Thanks. That was really helpful. That does sound really neat. So in the ideal world, we have URLs. We also have high fidelity and cool interactions and transitions on our pages. We don't have to give it a fancy name like single-page application or then multi-page application. I do wonder, with our grumpiness or our complaint about the URLs, is that fair to call it grumpy?

+ +

CHRIS: It's fair to call it grumpy, although you don’t need to loop yourself in with me. I'm the grump today.

+ +

STEPH: [laughs]

+ +

CHRIS: You're welcome to come along for the ride if you'd like. And I'm trying to find a positive way to talk about it. But yeah, it's my grumpytude.

+ +

STEPH: Well, I do feel similarly where I really value URLs, and I value the ability to bookmark and share, like you said earlier. And I do wonder if there is a way to still have that even if we don't have the URL. So one of the things that I do is I'll inspect the source code. And if I can find an ID that's for a particular header or section on the page, then I will link someone to a section of that page by then adding the ID into the URL, and that works. It's not always great because then I have to rely on that being there. But it's a fix, it's a workaround.

+ +

So I wonder if we could still have something like that, that as people are building content that can't be bookmarked or the URL doesn't change explicitly, or reference that content, to add more thoughtful bookmark links, essentially, or add an ID and then add a user-facing link that says, "Hey, if you want to link someone to this content, here you go." And under the hood, it's just an ID. But most people aren't going to know how to do that, so then you're helping people be able to reference content because we're used to URLs, so just thinking outside the box. I wonder if there are ways that we can still bookmark this content, share it with people. But it's okay if the URL isn't the only way that we can bookmark or reference that content.

+ +

CHRIS: It's interesting that you bring that up, so the anchor being the thing after the hash symbol in the URL. I actually use that a ton as well. I think I built a Chrome extension a while back to try what you're saying of I'll inspect the DOM. I did that enough times that I was like, what if the DOM were to just tell me if there were an ID here and I could click on a thing? Some people's blogs...I think the thoughtbot blog has this at this point. All headers are clickable. So they are hyperlinks that append that anchor to the URL.

+ +

So I wouldn't want to take that and use that functionality as our way to get back to URLs that are addressing resources because that's a way to then navigate even further, which I absolutely love, to a portion of the page. So thinking of Wikipedia, you're on an article, but it's a nice, long article. So you go down to the section, which is a third of the way down the page. And it's, again, a very big page, so you can link directly to that. And when someone opens that in their browser, the browsers know how to do this because it's part of the web platform, and it's wonderful.

+ +

So we've got domains, we've got paths, we've got anchors, we've got query params. I want to use them all. I want to embrace them. I want that to be top of mind. I want to really think about it and care about that as part of the interface to the application, even though most users like you said, are not thinking about the shape of a URL. But that addressability of content is a thing that even if people aren't thinking of it as a primary concern, I think they know it when they...it's one of those like, yeah, no, that app's great because I can bookmark anything, and I can get to anything, and I can share stuff with people.

+ +

And I do like the idea of making the ID-driven anchor deep links into a page more accessible to people because you and I would go into the DOM and slice it out. Your average web user may not be doing that, or that's much impossible to do on mobile, so yes, but only more so in my mind. [laughs] I don't want to take anchors and make them the way we do this. I want to just have all the URL stuff, please.

+ +

Mid-roll Ad
+Now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end.

+ +

If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: I have a confession from earlier when you were talking about the examples for those transitions. And you were describing where you take an action, and then the page does a certain motion to let you know that new content is coming onto the page and the old content is fading away. And I was like, oh, like a page reload? We're just reimplementing a page reload? [laughs] That's what we have?

+ +

CHRIS: You have a fancy, though.

+ +

STEPH: Fancy, okay. [laughs] But that felt a little sassy. And then you provided the other really great example with the to-do list. So what are some good examples of a SPA? Do you have any in mind? I think there are some use cases where...so Google Maps, that's the one that comes to mind for me where URLs feel less important. Are there other applications that fit that mold in your mind?

+ +

CHRIS: Well, so again, it's sort of getting at the nomenclature, and how much does the acronym actually inform what we're thinking about? But taking Google Maps as an example, or Trello is a pretty canonical one in my mind, most people say those are single-page applications. And they are probably in terms of what the tech actually is, but there are other pages in those apps. There's a settings page, and there's a search page, and there's this and that. And there's like the board list in Trello.

+ +

And so when we think about Trello, there is the board view where you're seeing the lists, and you can move cards, and you can drag and drop and do all the fancy stuff. That is a very rich client-side application that happens to be one page of the Trello web app and that one being higher fidelity, that one being more stateful. Stateful is probably the thing that I would care about more than anything. And so for that page, I would be fine with the portion of the JavaScript that comes down to the client being a larger payload, being more complex, and probably having some client-side state management for that. But fundamentally, I would not want to implement those as a true client-side application, as a true SPA. And I think client-side routing is really the definition point for me on this.

+ +

So with Trello, I would probably build that as an Inertia-type application. But that one page, the board page, I'd be like, yeah, sorry, this is not going to be the normal Inertia thing. I'm going to have to be hitting JSON endpoints that are specifically built for this page. I'm going to have a Redux store that's local. I'm going to lean into all of that complex state management and do that within the client-side app but not use client-side routing for actual page-level transitions, the same being true for Google Maps. The page where you're looking at the map, and you can do all sorts of stuff, that's a big application. But it is one page within the broader website, if you will. And so, I still wouldn't want client-side routing if I can avoid it because I think that is where I run into the most problems.

+ +

And that thing I was talking about where I was on the login page for a second, and then I wasn't; I do not like that thing. So if I can avoid that thing, which I have now found a way to avoid it, and I don't feel like I'm trading off on that, I feel like it's just a better experience but still reserving the right to this part of the application is so complex. This is our Wiziwig drag and drop graphical editor thing, cool. That's going to have Redux. That's going to have client-side state management, all that stuff. But at no point does single-page application feel like the right way to describe the thing that we're building because I still want to think about it as holistically part of the full web app. Like the Trello board view is part of the Trello web app. And I want it all to feel the same and move around the same.

+ +

STEPH: Yeah, that makes sense. And it's funny, as you were mentioning this, I pulled up Google Maps because I definitely only interact with that heavy JavaScript portion, same for Trello. And I wasn't even thinking about the fact that there are settings. By the way, Google Maps does a lot. I don't use hardly any of this. But you make a great point. There's a lot here that still doesn't need such heavy JavaScript interaction and doesn't really fit that mold of where it needs to be a single-page app or even needs to have that amount of interactivity. And frankly, you may want URLs to be able to go specifically to these pages.

+ +

CHRIS: That actually is an interesting, perhaps counterpoint to what I'm saying. So if you do have that complex part of one of your applications and you still want URL addressability, maybe you need client-side routing, and so that becomes a really difficult thing to answer in my mind. And I don't necessarily have a great answer for that. I'm also preemptively preparing myself for anyone on the internet that's listening to this and loves the idea of single-page applications and feels like I'm just building a straw man here, and none of what I'm saying is actually real and whatnot.

+ +

And although I try to...I think we generally try and stay in the positive space of like what's good on the internet. This is a rare case where I'm like, these are things that are not great. And so I think in this particular case, leaning into things that I don't like is the way to properly capture this. And giant JavaScript bundles where the entirety of the application logic comes down in 15-megabyte download, even if you're on 3G on a train; I don't like that.

+ +

I don't like if we have flashes of a layout that they can get ripped away b; it’secause it turns out we actually aren't authorized to view that page, that sort of thing. So there are certain experiences from an end client perspective that I really don't like, and that's mostly what I take issue with. Oh, also, I care deeply about URLs, and if you don't use the URL, then I'm going to be sad. Those are my things.

+ +

Hopefully, that list is perhaps a better summary of it than like...I don't want it to seem like I'm just coming after SPA as a phrase or a way of thinking because that's not as real of a conversation. But those particular things that I just highlighted don't feel great. And so I would rather build applications that don't have those going on. And so if there's a way to do that that still fits any other mold or is called whatever, but largely what I see called an SPA often has those sorts of edge cases. And I do not like those edge cases.

+ +

STEPH: Yeah, I like how you're breaking it down where it's less of this whole thing like I can't get on board with any of it. You are focusing on the things that you do have concerns with. So there can be just more interesting, productive conversations around those concerns versus someone feels like they have to defend their view of the world.

+ +

I have found that I think I'm a bit unique in this area where when people have a really differing opinion than mine, that gets me really excited because then I want to know. Because if I believe very strongly in something and I just think this is the way and then someone very strongly says like, "No, that's not," I'm like, "Oh yeah. Okay, we should talk because I'm interested in why you would have such a different opinion than mine." And so, I typically find those conversations really interesting. As long as everybody's coming forward to be productive and kind, then I really enjoy those conversations.

+ +

CHRIS: That is, I think, an interesting frame that you have there. But I think I'm similar, and hopefully, my reframing there puts it in the way that can be a productive conversation starter as opposed to a person griping on a podcast. But with that said, that's probably enough of me griping on a podcast. [chuckles] So what's up in your world, Steph?

+ +

STEPH: Oh, there are a couple of things going on. So I am in that pre-vacation chaotic zone where I'm just trying to get everything done. And I heard someone refer to it recently as going into a superman or superwoman mode where you're just trying to do all the things before you go, which is totally unreasonable. So that has been interesting. And the name of the game this week has been delegate, delegate, delegate, and it seems to be going fairly well. [chuckles] So I'm very excited for the downtime that I'm about to have.

+ +

And some other news, some personal news, Utah, my dog, turns one. I'm very excited. I'm pretty sure we'll have a dog birthday party and everything. It's going to be a thing. I'll share pictures on Twitter, I promise.

+ +

CHRIS: So he's basically out of the puppy phase then.

+ +

STEPH: Yeah, the definition for being a puppy seems to be if you're a year or younger, so he will not be an adult. Teenager? I don't know. [laughs]

+ +

CHRIS: What about according to your lived experience?

+ +

STEPH: He has calmed down a good bit.

+ +

CHRIS: Okay, that's good.

+ +

STEPH: He has gotten so much better. Back when we first got him, I swear I couldn't get 15 minutes of focus where he just needed all the attention. Or it was either constant playtime, or I had to put him in his kennel since we're using that. That was the only way I was really ever getting maker’s time. And now he will just lounge on the couch for like an hour or two at a time. It's glorious. And so he has definitely calmed down, and he is maturing, becoming such a big boy.

+ +

CHRIS: Well, that is wonderful. Astute listeners, if you go back to previous episodes over the past year, you can certainly find little bits of Utah sprinkled throughout, subtle sounds in the background.

+ +

STEPH: He is definitely an important part of the show. And in some other news, I have a question for you. I'm in need of some consulting help, and I would love to run something by you and get your thoughts. So specifically, the project that I'm working on, we are always in a state where there's too much to do. And even though we have a fairly large team, I want to say there's probably somewhere between 7 and 10 of us. And so, even though we have a fairly...for thoughtbot, that's a large team to have on one project. So even though there's a fair number of us, there's always too much to do. Everything always feels like it's urgent. I can't remember if I've told you this or not, but in fact, we had so many tickets marked as high priority that we had to introduce another status to then indicate they're really, really high, and that is called Picante. [chuckles]

+ +

CHRIS: Well, the first part of that is complicated; the actual word that you chose, though, fantastic.

+ +

STEPH: I think that was CTO Joe Ferris. I think he's the one that came up with Picante. So that's a thing that we have, and that really represents like, the app is down. So something major is happening. That's like a PagerDuty alert when we get to that status where people can't access a page or access the application. So there's always a lot to juggle, and it feels a lot like priority whiplash in terms that you are working on something that is important, but then you suddenly get dragged away to something else. And then you have to build context on it and get that done. And then you go back to the thing that you're working on.

+ +

And that's a really draining experience to constantly be in that mode where you're having to pivot from one type of work to the other. And so my question to you (And I'll be happy to fill in some details and answer questions.) is how do you calm things down? When you're in that state where everything feels so urgent and busy, and there's too much to do, how do you start to chip away at calming things down where then you feel like you're in a good state of making progress versus you feel like you're just always putting out fires or adding a band-aid to something? Yeah, that's where I’m at. What thoughts might you have, or what questions do you have?

+ +

CHRIS: Cool. I'm glad you brought an easy question that I can just very quickly answer, and we'll just run with that. It is frankly...what you're describing is a nuanced outcome of any number of possible inputs. And frankly, some of them may just be like; this is just the nature of the thing. Like, we could talk about adding more people to the project, but the mythical man-month and that idea that you can't just throw additional humans at the work and suddenly have that makes sense because now you have to coordinate between those humans. And there's that wonderful image of two people; there's one line of communication. Three people, suddenly there are a lot more lines of communication. Four people, wow. The exponential increase as you add new people to a network graph, that whole idea.

+ +

And so I think one of the first questions I would ask is, and again, this is probably not either/or. But if you would try and categorize it, is it just a question of there's just a ton of work to do and we're just not getting it done as quickly as we would want? Or is it that things are broken, that we're having to fix things, that there are constant tweaks and updates, that the system doesn't support the types of changes that we want, so any little thing that we want to do actually takes longer? Is it the system resisting, or is it just that there's too much to do? If you were to try and put it into one camp or the other.

+ +

STEPH: It is both, my friend. It is both of those camps. [chuckles]

+ +

CHRIS: Cool. That makes it way easier.

+ +

STEPH: Totally. [laughs] To add some more context to that, it is both where the system is resistant to change. So we are trying to make improvements as we go but then also being respectful of the fact if it is something that we need to move quickly on, it doesn't feel great where you never really get to go back and address the system in a way that feels like it's going to help you later. But then, frankly, it's one of those tools that we can use. So if we are in the state where there's too much to do, and the system is resisting us, we can continue to punt on that, and we can address things as we go.

+ +

But then, at some point, as we keep having work that has slowed down because we haven't addressed the underlying issues, then we can start to have that conversation around okay; we’ve done this twice now. This is the third time that this is going to take a lot longer than it should because we haven't really fixed this. Now we should talk about slowing things down so we can address this underlying issue first and then, from now on, pay the tax upfront. So from now on, it's going to be easier, but then we pay that tax now. So it is a helpful tool. It's something that we can essentially defer that tax to a later point. But then we just have to have those conversations later on when things are painful. Or it often leads to scope creep is another way that that creeps up.

+ +

So we take on a ticket that we think, okay, this is fairly straightforward; I don't think there's too much here. But then we're suddenly getting into the codebase, and we realize, oh, this is a lot more work. And suddenly, a ticket will become an epic, and you really have one ticket that's spiraled or grown into five or six tickets. And then suddenly, you have a person that's really leading like a mini project in terms of the scope of the work that they are doing.

+ +

So then that manifests in some interesting ways where then you have the person that feels a bit like a silo because they are the ones that are making all these big changes and working on this mini-project. And then there's the other one where there's a lot to do. There are a lot of customers, and there's a lot of customization for these customers. So then there are folks that are working really hard to keep the customers happy to give them what they need. And that's where we have too much to do. And we're prioritizing aggressively and trying to make sure that we're always working on the top priority. So like you said, it's super easy stuff.

+ +

CHRIS: Yeah. To say it sincerely and realistically, you're just playing the game on hard mode right now. I don't think there is any singular or even multiple easy answers to this. I think one question I would have particularly as you started to talk about that, there are multiple customers each with individualized needs, so that's one of many surface areas that I might look t say, "Can we sort of choke things off there?"

+ +

So I've often been in organizations where there is this constant cycle of the sales team is going out. They're demoing against an InVision mock. They're selling things that don't exist. They're making promises that are ungrounded and, frankly, technically infeasible or incredibly complicated, but it's part of the deal. They just sold it, and now we have to implement it as a team. I've been on teams where that was just a continuing theme. And so the engineering team was just like, "We can never catch up because the goalpost just keeps moving."

+ +

And so to whatever degree that might be true in this case, if there are ten different customers and each of them right now feels like they have an open line to make feature requests or other things like that, I would try to have the conversation of like, we've got to cut that off right now because we're struggling. We're not making the forward progress that we need to, and so we need to buy ourselves some time. And so that's one area that I would look at.

+ +

Another would be scope, anywhere that you can, go into an aggressive scope cutting mode. And so things like, well, we could build our own modal dialogue for this, but we could also use alert just like the JavaScript alert API. And what are all of the versions of that where we can say, "This is not going to be as nice, and as refined, and as fitting with the brand and feel and polish of the website. But ways that we can make an application that will be robust, that will work well on all of the devices that our users might be using but saves us a bunch of development time"? That's definitely something that I would look to.

+ +

What you described about refactoring is interesting. So I agree with we're not in a position where we can just gently refactor as we find any little mess. We have to be somewhat ruthless in our prioritization there. But like you said, when you get to that third time that a thing is working way harder, then take the time to do it. But really, like just every facet of the work, you just have to be a little better. If you're an individual developer and you're feeling stuck, raise your hand all the earlier because that being stuck, we don't have spare cycles right now. We need everybody to be working at maximum efficiency. And so if you've hit a wall, then raise your hand and grab somebody else, get a pair, rubber duck, whatever it is that will help you get unstuck. Because we're in a position where we need everybody moving as fast as they can.

+ +

But also to say all of those aren't free. Every one of those where you're just like, yeah, do it the best you can. Dial it up to 11 on every front. That's going to drain the team, and so we have to also be mindful of that. This can't be forever. And so maybe it is bringing some new people onto the team or trying to restructure things so that we can have smaller communication channels. So it's only four people working together on this portion of the application, and therefore their communication lines are a bit simpler. That's one way that we can maybe save a little bit. But yeah, none of these are free. And so, we also need to be mindful that we can't just try harder forever. [laughs] That's a way to burn out the team. But what you're describing is like the perfect storm of every facet of this is difficult, and there's no singular answer.

+ +

There's the theory of constraints (I think I'm saying that right.) where it's like, what's the part of our process that is introducing the most slowdowns? And so you go, and you tackle that. So if you imagine a website and the app is slow is the report that you're getting, and you're like, okay, what does that mean? And you instrument it, and you log some stuff out. And you're like, all right, turns out we have tons of N+1s. So frankly, everything else doesn't matter. I don't care if we've got a 3 megabyte JavaScript bundle right now; the 45 N+1s on the dashboard that's the thing that we need to tackle. So you start, and you focus on that.

+ +

And now you've removed that constraint. And suddenly, the three megabyte JavaScript bundle is the new thing that is the most complicated. So you're like, okay, cool, let's look into tree shaking or whatever it is, but you move from one focus to another. And so that's another thing that could come to play here is like, which part of this is introducing the most pain? Is it feature churn? Is it unrealistic sales expectations? Is it developers getting stuck? And find the first of those and tackle it. But yeah, this is hard.

+ +

STEPH: Yeah, it is. That's all really helpful, though. And then, I can share some of the things that we are experimenting with right now and then provide an update on how it's going. And one of the things that we're trying; I think it's similar to the theory of constraints. I'm not familiar with that, but based on the way you described it, I think they're related.

+ +

One of the things that we are trying is breaking the group into smaller teams because there are between 7 and 10 of us. And so, trying to jump from one issue to the next you may have to really level up on different portions of the application to be able to make an impact. And there are areas that we really need infrastructure improvements and then essentially paving the way for other people to be able to move more quickly. We do have to prioritize some of that work as well.

+ +

So if we break up into smaller teams, it addresses a couple of areas, or at least that's the goal is to address a couple of areas. One is we avoid having silos so that people aren't a bottleneck, or they're the only ones that are really running this mini-project and the only one that has context. Because then when that person realizes the scope has grown, bringing somebody on to help feels painful because then you're in an urgent state, but now you have to spend time leveling someone else up just so that they can help you, and that's tough.

+ +

So the goal is that by having smaller teams, we will reduce that from happening because at least everything that feels like a small project...and by feels like a small project, I mean if we have more than one ticket that's associated with the same theme, that's going to start hinting at maybe this is more than just one ticket itself, and it might actually belong to an epic. Or there's a theme here, and maybe we should have two people working on this. And breaking people into groups, then we can focus on some people are focused more on the day-to-day activity. Some people are focused on another important portion of the codebase as we have what may be extracted. I'm going to say this, but we're going to move on, maybe extracted into its own service. [laughs] I know that's a hot one for us, so I'm just going to say it.

+ +

CHRIS: I told you I can't be nerd sniped. This is fine. Let's continue on. [laughs]

+ +

STEPH: [laughs] And then a small group can also focus on some of those infrastructure improvements that I was alluding to. So smaller teams is something that we are trying.

+ +

We are also doing a really great job. I've been really happy and just proud of the team where folks are constantly reaching out to each other to say, "Hey, I'm done with my ticket. Who can I help?" So instead of immediately going to the backlog and grabbing the next thing. Because we recognize that because of this structure where some people are some silos, they have their own little mini backlog, which we are working to remove that to make sure everything is properly prioritized instead of getting assigned to one particular person. But we are reaching out to each other to say, "Hey, what can I do to help? What do you need to get done with your work before I go pick something else up?"

+ +

The other two things that come to mind is who's setting the deadlines? I think you touched on this one as well. It's just understanding why is it urgent? Does it need to be urgent? What is the deadline? Is this something that internally we are driving? Is this something that was communicated without talking to the rest of the team? Is this just a really demanding customer? Are they setting unrealistic expectations? But having more communication around what is the sense of urgency? What happens if we miss this deadline? What happens if we don't get to this for a week, a month? What does that look like?

+ +

And then also, my favorite are retros because then we can vote on what feels like the highest priority in terms of pain points or run these types of experiments like the smaller teams. So those are the current strategies that we have. And I'm very interested to see how they turn out because it is a tough way. Like you said, it's challenge mode, and it is going to burn people out. And it does make people feel fatigued when they have to jump from one priority to the next. So I'm very interested. It's a very interesting problem to me too. It just feels like something that I imagine a lot of teams may be facing. So I'm really excited if anybody else is facing a similar issue or has gone through a similar challenge mode; I’d love to hear how your team tackled it.

+ +

CHRIS: Yeah, I'm super interested to hear the outcome of those experiments. As a slightly pointed question there, is there any semi-formal version of tracking the experiments? And is it just retro to retro that you're using for feedback on that? I've often been on teams where we have retro. We come up with it, and we're like, oh, this is a pain point. All right, let's try this. And then two weeks later, we're like, oh, did anyone actually do that? And then we just forget. And it's one of those things that I've tried to come up with better ways to actually manage, make slightly more explicit the experiments, and then have a timeline, have an almost scientific process of what's the hypothesis? What's the procedure? What are the results? Write up an executive summary. How'd it go?

+ +

STEPH: We are currently using retro, but I like that idea of having something that's a bit more concrete. So we have action items. And typically, going through retro, I tend to revisit the action items first as a way to kick off retro. So then that highlights what did we do? What did we not do? What do we not want to do anymore? What needs to roll over to the current iteration? And I think that could be just a way that we chat about this. We try something new, and we see how it's going each week in retro. But I do like the idea of stating upfront this is what we're looking to achieve because I think that's not captured in the retro action item. We have the thing that we're doing, but we haven't captured this is what we hope to achieve by taking this experiment on.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: As for the other thing that you mentioned, I do have an idea for that because a former client that I worked with where we had experiments or things that we wanted to do, we were using Trello. And so we would often take those action items…or it was even more of a theme. It wasn't something that could be one-and-done. It was more of a daily reminder of, hey; we are trying this new thing. And so, we want to remind you each day to embrace this experiment and this practice. And so we would turn it into a Trello ticket, and then we would just leave it at the top of the board. So then, each day, as we were walking the board, it was a nice reminder to be like, hey, this is an ongoing experiment. Don't forget to do this.

+ +

CHRIS: I do like the idea of bringing it into a stand-up potentially as like that's just a recurring point that we all have. So we can sort of revisit it, keep it top of mind, and discard it at some point if it's not useful. And if we're saying we're doing a thing, then let's do the thing and see how it goes. So yeah, very interested to hear the outcomes of the experiment and also the meta experiment framework that you're going to build here. Very interested to hear more about that.

+ +

And just to say it again, this sounds like your perfect storm is not quite right because it doesn't sound like there's a ton of organizational dysfunction here. It sounds like this is just like, nah, it's hard. The code's not in perfect shape, but no code is. And there's just a lot of work to be done. And there are priorities because frankly, sometimes in the world, there are priorities, and you're sort of at the intersection of that.

+ +

And I've been in plenty of teams where it was hard because of humans. In fact, that's often the reason of we're sort of making up problems, or we're poorly communicating or things like that. But it sounds like you're in the like, nope, this is just hard. And so, in a way, it sounds like you're thinking about it like, I don't know, it's kind of the challenge that I signed up for. Like, if we can win this, then there's going to be some good learnings that come out of that, and we're going to be all the better. And so, I wish you all the best of luck on that and would love to hear more about it in the future.

+ +

STEPH: Thank you. And yeah, it has been such an interesting project with so many different challenges. And as you've mentioned, that is one area that is going really well where the people are wonderful. Everybody is doing their best and working hard. So that is not one of the competing challenges. And it is one of those; it’s hard. There are a lot of external factors that are influencing the priority of our work. And then also, some external areas that we don't have control over that are forcing some of those deadlines where customers need something and not because they're being fussy, but they are themselves reacting to external deadlines that they don't have control over.

+ +

So it is one of those where the people are great, and the challenges are just real, and we're working through them together. But it's also hard. But it's helpful chatting through all the different challenges with you. So I appreciate all of your thoughts on the matter. And I'll report some updates once I have some more information.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + You know what really grinds Chris' gears? (Spoiler Alert: It's Single-Page Applications.)

+ +

Steph needs some consulting help. So much to do, so little time.

+ + + +

Transcript:

+ +

CHRIS: I have restarted my recording, and we are now recording. And we are off on the golden roads. Isn't software fun?

+ +

STEPH: Podcast battle. Here we go!

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been?

+ +

CHRIS: Happy Friday to you as well. My week's been good with the exception of right before we started this recording, I had one of those experiences. You know the thing where software is bad and software is just terrible overall? I had one of those. And very briefly to describe it, I started recording, but I could hear some feedback in my headphones. So I was like, oh no, is that feedback going to show up on the final recording? Which I really hope it doesn't. Spoiler alert - listener, if I sound off, sorry about that. But so I stopped recording and then I went to go listen to the file, and I have our audio software configured to record directly to the desktop. And it does that normally quite well. But for some reason, the file wasn't there. But I remember this recently because I ran into it another time.

+ +

For some reason, this is Finder failing me. So the thing that shows me the files in a graphical format, at least on my operating system. Although I think it also messes up in the terminal maybe. That feels like it shouldn't be true, but maybe it is. Anyway, I had to kill all Finder from the terminal to aggressively restart that process. And then suddenly, Finder was like, oh yeah, there's totally files there, absolutely. They were there the whole time. Why do you even ask?

+ +

And I know that state management is a hard problem, I am aware. I have felt this pain. I have been the person who has introduced some bugs related to it, but that's not where I want to experience it. Finder is one of those applications that I want to just implicitly trust, never question whether or not it's just sneakily telling me that there are files that are not there or vice versa. So anyway, software.

+ +

STEPH: I'm worried for your OS. I feel like there's a theme lately [chuckles] in the struggles of your computer.

+ +

CHRIS: On a related note, I had to turn off transparency in my terminal because it was making my computer get very hot. [chuckles]

+ +

STEPH: Oh no, you're not a hacker any more.

+ +

CHRIS: I'm not. [chuckles] I just have a weird screen that's just dark. And jellybeans is my color scheme, so there's that going on. That's in Vim specifically. Pure is my prompt. That's a lovely little prompt. But lots of Day-Glo colors on just a black background, not the cool hacker transparency. I have lost some street cred.

+ +

STEPH: What is your prompt? What did you say it is?

+ +

CHRIS: Pure.

+ +

STEPH: Pure, I don't know that one.

+ +

CHRIS: It is by Sindre Sorhus; I think is his name. That's his Twitter handle, GitHub name. He is a prolific open-source creator in the Node world, particularly. But he created this...I think it's a Bash and a Zsh prompt. It might be for others as well. It's got a bunch of features. It's pretty fast. It's minimal. It got me to stop messing around with my prompt, which was mostly what I was going for. And it has a nice benefit that occasionally now I'll be pairing with someone, and I'll be like, "Your prompt looks like my prompt. Everything is familiar. This is great."

+ +

STEPH: Well, if you get back in the waters of messing around with your prompts again, I'm using Starship. And I hadn't heard of Pure before, but I really like Starship. That's been my new favorite.

+ +

CHRIS: Wow.

+ +

STEPH: Wow.

+ +

CHRIS: I mean, on the one hand…

+ +

STEPH: You're welcome. [laughs]

+ +

CHRIS: On the one hand, thank you. On the other hand, again, let me lead in with the goal was to stop messing around with my prompt. So you're like, oh, cool. Here's another prompt for you, though. [chuckles]

+ +

STEPH: [laughs] But my goal is to nerd snipe you into trying more things because it's fun.

+ +

CHRIS: I don't know if you know this, but I am impervious to nerd sniping.

+ +

STEPH: [laughs]

+ +

CHRIS: So try as you might, I shall remain steady in my course of action.

+ +

STEPH: Are we playing two truths and a lie? Is that what we're doing today? [laughs]

+ +

CHRIS: Nah, just one lie. It's easier. Everybody wins one lie.

+ +

STEPH: [laughs]

+ +

CHRIS: But anyway, in other news, we're going to do a segment called this really grinds my gears. That's today's segment, which is much like when I do a good idea, terrible idea. But this is one that I'm sure I've talked about before. But there's been some stuff that I saw moving around on the internet as one does, and it got these ideas back into my head. And it's around the phrase single-page application. I am not a fan of that phrase or SPA as the initialism. Thank you, Edward Loveall, for teaching me the difference between an initialism and an acronym. I really hope I'm getting it right, by the way, [laughs] SPA as people call them these days.

+ +

I feel weird because of how much I care about this thing, how much I care about this idea, and how much whenever I hear this acronym, I get a little bit unhappy. And so there's a part of it that's I really do think our words shape our thinking. And I think single-page application has some deeply problematic ideas. Most notably, I think one of the most important things about building web applications is the URL. And those are different pages, at least in my head. I don't know of a different way to think about this.

+ +

But if you are not emphasizing the URL and the fact that the URL is a way to address different pages or resources within your application, then you are throwing away one of the greatest advancements that humankind has made, in my mind. I care a lot about URLs; it turns out. And it's not inherent to an SPA that you will not be thinking about URLs. But again, in that idea that our words shape our thinking, by calling it an SPA, by leaning into that idea, I think you are starting down a path that leads to bad outcomes. I'm going to pause there because I'm getting kind of ranty. I got more to say on the topic. But what do you think?

+ +

STEPH: Yeah, these are hot takes. I'm into it. I'm pretty sure that I know why URLs are so important to you and more of your feelings around why they're important. But would you dive in a bit deeper as to why you really cherish URLs, and why they're so important, and why they're one of the greatest advancements of humanity?

+ +

CHRIS: [laughs] It sounds lofty when you say it back to me, but yeah. It's interesting that as you put into a question, it is a little bit hard to name. So there are certain aspects that are somewhat obvious. I love the idea that I can bookmark or share a given resource or representation of a resource very simply. Like the URL, it's this known thing. We can put hyperlinks in a document. It's this shared way to communicate, frankly, very complex things.

+ +

And when I think of a URL, it's not just the domain and the path, but it's also any query parameters. So if you imagine faceted search on a website, you can be like, oh, filter down to these and only ones that are more than $10, and only ones that have a future start date and all those kinds of nuance. If you serialize that into the URL as part of the query param, then that even more nuanced view of this resource is shareable is bookmarkable is revisitable.

+ +

I end up making Alfred Workflows that take advantage of the fact that, like, oh, I can look at this URL scheme, and I can see where different parts are interpolated. And so I can navigate directly to any given thing so fast. And that's deeply valuable, and it just falls naturally out of the idea that we have URLs. And so to not deeply embrace that, to not really wrap your arms around it and give that idea a big hug feels weird to me.

+ +

STEPH: Yeah, I agree. I remember we've had this conversation in the past, and it really frustrates me when I can't share specific resources with folks because I don't know how to link to it. So then I can send you a link to the application itself to the top URL. But then I have to tell you how to find the information that I thought was really helpful. And that feels like a step backward.

+ +

CHRIS: Yeah. That ability to say, "Follow this link, and then it will be obvious," versus "Go to this page, click on this thing, click on the dropdown, click on this other thing." Like, that's just a fundamentally different experience. So one of the things that I saw that got me thinking about this was I saw folks referring to single-page applications but then contrasting them with MPAs, which are multiple-page applications.

+ +

STEPH: So the normal application? [laughs]

+ +

CHRIS: And I was like, whoa, whoa, everybody. You mean like a website or a web app? As much as I was angry at the first initialism, this second one's really getting me going. But it really does speak to what are we doing? What are we trying to build? And as with anything, you could treat this as a binary as just like there are two options. There are either websites which, yeah, those have got a bunch of URLs, and that's all the stuff. And then there are web apps, and they're different. And it's a bundle of JavaScript that comes down, boots up on the client, and then it's an app thing. And who cares about URLs? I think very few people would actually fall in that camp.

+ +

So I don't really believe that there is a dichotomy here. I think, as always, it's a continuum; it’s a spectrum. But leaning into the nomenclature of single-page application, I think pushes you more towards that latter end of the spectrum. I think there are other things that fall out of it. Like, I believe deeply in having the server know more, have more of the logic, own more of the logic, own more authorization and routing, and all of those things because really great stuff falls out of that. And that one has more of a trade-off, I'd say.

+ +

But I won't name any names, but there is a multiple billion-dollar company whose website I had to interact with recently. And you land on their page on their marketing site. And then, if you click log in, it navigates you to the application, so a separate domain or a separate subdomain, the application subdomain, and the login page there. And the login page renders, and then I go to fill in my username and password. Like, my mouse makes it all the way to click on the little box or whatever I'm doing if I'm using keyboard things. But I have enough time to actually start to interact with this page.

+ +

And then suddenly, it rips away, and it actually just renders the authenticated application because it turns out I was already logged in. But behind the scenes, they're doing some JWT dance around that they're checking; oh no, no, you're already logged in, so never mind. We don't need to show you the login page, but I was already on the login page.

+ +

And my feeling is this sort of brittle UI; this sort of inconsistency erodes my trust in that application, particularly when I'm on the login page. That is a page that matters. I don't believe that they're doing anything fundamentally insecure. But I do have the question in my head now. I'm like, wait, what's going on there, everybody? Is it fine? Was that okay? Or if you see something that you shouldn't see and then suddenly it's ripped away from you, if you see half of a layout that's rendered on a page and then suddenly you see, no, no, no, you actually don't have access to that page, that experience erodes my trust.

+ +

And so, I would rather wait for the server to fully resolve, determine what's going to happen, and then we get a response that is holistically consistent. You either have access, or you don't, that sort of thing. Give me a loading indicator; give me those sorts of things. I'm fine with that. But don't render half of a layout and then redirect me back away.

+ +

STEPH: I feel like that's one of the problems with knowing too much because most people are not going to pick up on a lot of the things that you're noticing and caring deeply about where they would just see like, oh, I was logged in and be like, huh, okay, that was a little weird, but I'm in and just continue on. Versus other folks who work very closely to this who may recognize and say, "That was weird." And the fact that you asked me to log in, but then I was already logged in, did you actually log me in correctly? What's happening? And then it makes you nervous.

+ +

CHRIS: Maybe. Probably. But I wonder…the way you just said that sounds like another dichotomy. And I would say it's probably more of a continuum of an average not terribly tech-savvy user would still have a feeling of huh, that was weird. And that's enough. That's a little tickle in the back of your brain. It's like, huh, that was weird.

+ +

And if that happens enough times or if you've seen someone who uses an application and uses it consistently, if that application is reasonably fast and somewhat intuitive and consistent, then they can move through it very quickly and very confidently. But if you have an app that half loads and then swaps you to another page and other things like that, it's very hard to move confidently through an application like that. I do think you're right in saying that I am over-indexed on this, and I probably care more than the average person, but I do care a lot.

+ +

I do think one of the reasons that I think this happens is mobile applications came along, and they showed us a different experience that can happen and also desktop apps for some amount of time this was true. But I think iOS apps, in particular really great ones, have super high fidelity interactions. And so you're like, you're looking at a list view, and then you click on the cell for that list view. And there's this animated transition where the title floats up to the top and grows just a little bit. And the icon that was in the corner moves up to the corner, and it gets a little bigger. And it's this animated transition to the detailed view for that item. And then if you go back, it sort of deanimates back down.

+ +

And that very consistent experience is kind of lovely when you get it right, but it's really, really hard. And people, I think, have tried to bring that to the web, but it's been such a struggle. And it necessitates client-side routing and some other things, or it's probably easiest to do if you have those sorts of technologies at play, but it's been a struggle. I can't think of an application that I think really pulls that off. And I think the trade-offs have been very costly.

+ +

On the one positive note, there was a tweet that I saw by Sarah Drasner that was talking about smooth and simple page transitions with the shared element transition API. So this is a new API that I think is hoping to bring some of this functionality to the web platform natively so that web applications can provide that higher fidelity experience. Exactly how it'll work whether or not it requires embracing more of the single-page application, client-side routing, et cetera, I'm not sure on that. But it is a glimmer of hope because I think this is one of the things that drives folks in this direction. And if we have a better answer to it, then maybe we can start to rethink the conversation.

+ +

STEPH: So I think you just said shared element transitions. I don't know what that is. Can you talk more about that?

+ +

CHRIS: I can try, or I can make a guess. So my understanding is that would be that sort of experience where you have a version of a certain piece of content on the page. And then, as you transition to a new page, that piece of content is still represented on the new page, but perhaps the font size is larger, or it's expanded, or the box around it has grown or something like that. And so on mobile, you'll often see that animate change. On the web, you'll often see the one page is just completely replaced with the other. And so it's a way to have continuity between, say, a detailed view, and then when you click on an item in it, that item sort of grows to become the new page. And now you're on the detail page from the list page prior.

+ +

There's actually a functionality in Svelte natively for this, which is really fancy; it's called crossfade. And so it allows you to say, "This item in the component hierarchy in the first state of the application is the same as this item in the second state of the application." And then, Svelte will take care of transitioning any of the properties that are necessary between those two.

+ +

So if you have a small circle that is green, and then in the next state of the application, it's a blue rectangle, it will interpolate between those two colors. It will interpolate the shape and grow and expand it. It will float it to its new location. There is a really great version of it in the Svelte tutorial showing a to-do list. And so it's got a list on the left, which is undone things, and a list on the right that is done things. And when you click on something to complete it, it will animate it, sort of fly across to the other list. And if you click on it to uncomplete, it will animate it and fly back.

+ +

And what's great is within Svelte because they have this crossfade as a native idea; all you need to say is like, "It was on this list, now it's on this list." And as long as it's identifiable, Svelte handles that crossfade and all the animations. So it's that kind of high-fidelity experience that I think we want. And that leads us to somewhat more complex applications, and I totally get that. I want those experiences as well. But I want to ask some questions, and I want to do away with the phrasing single-page application entirely. I don't want to say that anymore. I want to say URLs are one honking good idea. Let's have more of those.

+ +

And also, just to name it, Inertia is a framework that allows me to build using some of the newer technologies but not have to give up on URLs, give up on server-side logic as the primary thing. So I will continue to shout my deep affection for Inertia in this moment once again.

+ +

STEPH: Cool. Thanks. That was really helpful. That does sound really neat. So in the ideal world, we have URLs. We also have high fidelity and cool interactions and transitions on our pages. We don't have to give it a fancy name like single-page application or then multi-page application. I do wonder, with our grumpiness or our complaint about the URLs, is that fair to call it grumpy?

+ +

CHRIS: It's fair to call it grumpy, although you don’t need to loop yourself in with me. I'm the grump today.

+ +

STEPH: [laughs]

+ +

CHRIS: You're welcome to come along for the ride if you'd like. And I'm trying to find a positive way to talk about it. But yeah, it's my grumpytude.

+ +

STEPH: Well, I do feel similarly where I really value URLs, and I value the ability to bookmark and share, like you said earlier. And I do wonder if there is a way to still have that even if we don't have the URL. So one of the things that I do is I'll inspect the source code. And if I can find an ID that's for a particular header or section on the page, then I will link someone to a section of that page by then adding the ID into the URL, and that works. It's not always great because then I have to rely on that being there. But it's a fix, it's a workaround.

+ +

So I wonder if we could still have something like that, that as people are building content that can't be bookmarked or the URL doesn't change explicitly, or reference that content, to add more thoughtful bookmark links, essentially, or add an ID and then add a user-facing link that says, "Hey, if you want to link someone to this content, here you go." And under the hood, it's just an ID. But most people aren't going to know how to do that, so then you're helping people be able to reference content because we're used to URLs, so just thinking outside the box. I wonder if there are ways that we can still bookmark this content, share it with people. But it's okay if the URL isn't the only way that we can bookmark or reference that content.

+ +

CHRIS: It's interesting that you bring that up, so the anchor being the thing after the hash symbol in the URL. I actually use that a ton as well. I think I built a Chrome extension a while back to try what you're saying of I'll inspect the DOM. I did that enough times that I was like, what if the DOM were to just tell me if there were an ID here and I could click on a thing? Some people's blogs...I think the thoughtbot blog has this at this point. All headers are clickable. So they are hyperlinks that append that anchor to the URL.

+ +

So I wouldn't want to take that and use that functionality as our way to get back to URLs that are addressing resources because that's a way to then navigate even further, which I absolutely love, to a portion of the page. So thinking of Wikipedia, you're on an article, but it's a nice, long article. So you go down to the section, which is a third of the way down the page. And it's, again, a very big page, so you can link directly to that. And when someone opens that in their browser, the browsers know how to do this because it's part of the web platform, and it's wonderful.

+ +

So we've got domains, we've got paths, we've got anchors, we've got query params. I want to use them all. I want to embrace them. I want that to be top of mind. I want to really think about it and care about that as part of the interface to the application, even though most users like you said, are not thinking about the shape of a URL. But that addressability of content is a thing that even if people aren't thinking of it as a primary concern, I think they know it when they...it's one of those like, yeah, no, that app's great because I can bookmark anything, and I can get to anything, and I can share stuff with people.

+ +

And I do like the idea of making the ID-driven anchor deep links into a page more accessible to people because you and I would go into the DOM and slice it out. Your average web user may not be doing that, or that's much impossible to do on mobile, so yes, but only more so in my mind. [laughs] I don't want to take anchors and make them the way we do this. I want to just have all the URL stuff, please.

+ +

Mid-roll Ad
+Now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end.

+ +

If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: I have a confession from earlier when you were talking about the examples for those transitions. And you were describing where you take an action, and then the page does a certain motion to let you know that new content is coming onto the page and the old content is fading away. And I was like, oh, like a page reload? We're just reimplementing a page reload? [laughs] That's what we have?

+ +

CHRIS: You have a fancy, though.

+ +

STEPH: Fancy, okay. [laughs] But that felt a little sassy. And then you provided the other really great example with the to-do list. So what are some good examples of a SPA? Do you have any in mind? I think there are some use cases where...so Google Maps, that's the one that comes to mind for me where URLs feel less important. Are there other applications that fit that mold in your mind?

+ +

CHRIS: Well, so again, it's sort of getting at the nomenclature, and how much does the acronym actually inform what we're thinking about? But taking Google Maps as an example, or Trello is a pretty canonical one in my mind, most people say those are single-page applications. And they are probably in terms of what the tech actually is, but there are other pages in those apps. There's a settings page, and there's a search page, and there's this and that. And there's like the board list in Trello.

+ +

And so when we think about Trello, there is the board view where you're seeing the lists, and you can move cards, and you can drag and drop and do all the fancy stuff. That is a very rich client-side application that happens to be one page of the Trello web app and that one being higher fidelity, that one being more stateful. Stateful is probably the thing that I would care about more than anything. And so for that page, I would be fine with the portion of the JavaScript that comes down to the client being a larger payload, being more complex, and probably having some client-side state management for that. But fundamentally, I would not want to implement those as a true client-side application, as a true SPA. And I think client-side routing is really the definition point for me on this.

+ +

So with Trello, I would probably build that as an Inertia-type application. But that one page, the board page, I'd be like, yeah, sorry, this is not going to be the normal Inertia thing. I'm going to have to be hitting JSON endpoints that are specifically built for this page. I'm going to have a Redux store that's local. I'm going to lean into all of that complex state management and do that within the client-side app but not use client-side routing for actual page-level transitions, the same being true for Google Maps. The page where you're looking at the map, and you can do all sorts of stuff, that's a big application. But it is one page within the broader website, if you will. And so, I still wouldn't want client-side routing if I can avoid it because I think that is where I run into the most problems.

+ +

And that thing I was talking about where I was on the login page for a second, and then I wasn't; I do not like that thing. So if I can avoid that thing, which I have now found a way to avoid it, and I don't feel like I'm trading off on that, I feel like it's just a better experience but still reserving the right to this part of the application is so complex. This is our Wiziwig drag and drop graphical editor thing, cool. That's going to have Redux. That's going to have client-side state management, all that stuff. But at no point does single-page application feel like the right way to describe the thing that we're building because I still want to think about it as holistically part of the full web app. Like the Trello board view is part of the Trello web app. And I want it all to feel the same and move around the same.

+ +

STEPH: Yeah, that makes sense. And it's funny, as you were mentioning this, I pulled up Google Maps because I definitely only interact with that heavy JavaScript portion, same for Trello. And I wasn't even thinking about the fact that there are settings. By the way, Google Maps does a lot. I don't use hardly any of this. But you make a great point. There's a lot here that still doesn't need such heavy JavaScript interaction and doesn't really fit that mold of where it needs to be a single-page app or even needs to have that amount of interactivity. And frankly, you may want URLs to be able to go specifically to these pages.

+ +

CHRIS: That actually is an interesting, perhaps counterpoint to what I'm saying. So if you do have that complex part of one of your applications and you still want URL addressability, maybe you need client-side routing, and so that becomes a really difficult thing to answer in my mind. And I don't necessarily have a great answer for that. I'm also preemptively preparing myself for anyone on the internet that's listening to this and loves the idea of single-page applications and feels like I'm just building a straw man here, and none of what I'm saying is actually real and whatnot.

+ +

And although I try to...I think we generally try and stay in the positive space of like what's good on the internet. This is a rare case where I'm like, these are things that are not great. And so I think in this particular case, leaning into things that I don't like is the way to properly capture this. And giant JavaScript bundles where the entirety of the application logic comes down in 15-megabyte download, even if you're on 3G on a train; I don't like that.

+ +

I don't like if we have flashes of a layout that they can get ripped away b; it’secause it turns out we actually aren't authorized to view that page, that sort of thing. So there are certain experiences from an end client perspective that I really don't like, and that's mostly what I take issue with. Oh, also, I care deeply about URLs, and if you don't use the URL, then I'm going to be sad. Those are my things.

+ +

Hopefully, that list is perhaps a better summary of it than like...I don't want it to seem like I'm just coming after SPA as a phrase or a way of thinking because that's not as real of a conversation. But those particular things that I just highlighted don't feel great. And so I would rather build applications that don't have those going on. And so if there's a way to do that that still fits any other mold or is called whatever, but largely what I see called an SPA often has those sorts of edge cases. And I do not like those edge cases.

+ +

STEPH: Yeah, I like how you're breaking it down where it's less of this whole thing like I can't get on board with any of it. You are focusing on the things that you do have concerns with. So there can be just more interesting, productive conversations around those concerns versus someone feels like they have to defend their view of the world.

+ +

I have found that I think I'm a bit unique in this area where when people have a really differing opinion than mine, that gets me really excited because then I want to know. Because if I believe very strongly in something and I just think this is the way and then someone very strongly says like, "No, that's not," I'm like, "Oh yeah. Okay, we should talk because I'm interested in why you would have such a different opinion than mine." And so, I typically find those conversations really interesting. As long as everybody's coming forward to be productive and kind, then I really enjoy those conversations.

+ +

CHRIS: That is, I think, an interesting frame that you have there. But I think I'm similar, and hopefully, my reframing there puts it in the way that can be a productive conversation starter as opposed to a person griping on a podcast. But with that said, that's probably enough of me griping on a podcast. [chuckles] So what's up in your world, Steph?

+ +

STEPH: Oh, there are a couple of things going on. So I am in that pre-vacation chaotic zone where I'm just trying to get everything done. And I heard someone refer to it recently as going into a superman or superwoman mode where you're just trying to do all the things before you go, which is totally unreasonable. So that has been interesting. And the name of the game this week has been delegate, delegate, delegate, and it seems to be going fairly well. [chuckles] So I'm very excited for the downtime that I'm about to have.

+ +

And some other news, some personal news, Utah, my dog, turns one. I'm very excited. I'm pretty sure we'll have a dog birthday party and everything. It's going to be a thing. I'll share pictures on Twitter, I promise.

+ +

CHRIS: So he's basically out of the puppy phase then.

+ +

STEPH: Yeah, the definition for being a puppy seems to be if you're a year or younger, so he will not be an adult. Teenager? I don't know. [laughs]

+ +

CHRIS: What about according to your lived experience?

+ +

STEPH: He has calmed down a good bit.

+ +

CHRIS: Okay, that's good.

+ +

STEPH: He has gotten so much better. Back when we first got him, I swear I couldn't get 15 minutes of focus where he just needed all the attention. Or it was either constant playtime, or I had to put him in his kennel since we're using that. That was the only way I was really ever getting maker’s time. And now he will just lounge on the couch for like an hour or two at a time. It's glorious. And so he has definitely calmed down, and he is maturing, becoming such a big boy.

+ +

CHRIS: Well, that is wonderful. Astute listeners, if you go back to previous episodes over the past year, you can certainly find little bits of Utah sprinkled throughout, subtle sounds in the background.

+ +

STEPH: He is definitely an important part of the show. And in some other news, I have a question for you. I'm in need of some consulting help, and I would love to run something by you and get your thoughts. So specifically, the project that I'm working on, we are always in a state where there's too much to do. And even though we have a fairly large team, I want to say there's probably somewhere between 7 and 10 of us. And so, even though we have a fairly...for thoughtbot, that's a large team to have on one project. So even though there's a fair number of us, there's always too much to do. Everything always feels like it's urgent. I can't remember if I've told you this or not, but in fact, we had so many tickets marked as high priority that we had to introduce another status to then indicate they're really, really high, and that is called Picante. [chuckles]

+ +

CHRIS: Well, the first part of that is complicated; the actual word that you chose, though, fantastic.

+ +

STEPH: I think that was CTO Joe Ferris. I think he's the one that came up with Picante. So that's a thing that we have, and that really represents like, the app is down. So something major is happening. That's like a PagerDuty alert when we get to that status where people can't access a page or access the application. So there's always a lot to juggle, and it feels a lot like priority whiplash in terms that you are working on something that is important, but then you suddenly get dragged away to something else. And then you have to build context on it and get that done. And then you go back to the thing that you're working on.

+ +

And that's a really draining experience to constantly be in that mode where you're having to pivot from one type of work to the other. And so my question to you (And I'll be happy to fill in some details and answer questions.) is how do you calm things down? When you're in that state where everything feels so urgent and busy, and there's too much to do, how do you start to chip away at calming things down where then you feel like you're in a good state of making progress versus you feel like you're just always putting out fires or adding a band-aid to something? Yeah, that's where I’m at. What thoughts might you have, or what questions do you have?

+ +

CHRIS: Cool. I'm glad you brought an easy question that I can just very quickly answer, and we'll just run with that. It is frankly...what you're describing is a nuanced outcome of any number of possible inputs. And frankly, some of them may just be like; this is just the nature of the thing. Like, we could talk about adding more people to the project, but the mythical man-month and that idea that you can't just throw additional humans at the work and suddenly have that makes sense because now you have to coordinate between those humans. And there's that wonderful image of two people; there's one line of communication. Three people, suddenly there are a lot more lines of communication. Four people, wow. The exponential increase as you add new people to a network graph, that whole idea.

+ +

And so I think one of the first questions I would ask is, and again, this is probably not either/or. But if you would try and categorize it, is it just a question of there's just a ton of work to do and we're just not getting it done as quickly as we would want? Or is it that things are broken, that we're having to fix things, that there are constant tweaks and updates, that the system doesn't support the types of changes that we want, so any little thing that we want to do actually takes longer? Is it the system resisting, or is it just that there's too much to do? If you were to try and put it into one camp or the other.

+ +

STEPH: It is both, my friend. It is both of those camps. [chuckles]

+ +

CHRIS: Cool. That makes it way easier.

+ +

STEPH: Totally. [laughs] To add some more context to that, it is both where the system is resistant to change. So we are trying to make improvements as we go but then also being respectful of the fact if it is something that we need to move quickly on, it doesn't feel great where you never really get to go back and address the system in a way that feels like it's going to help you later. But then, frankly, it's one of those tools that we can use. So if we are in the state where there's too much to do, and the system is resisting us, we can continue to punt on that, and we can address things as we go.

+ +

But then, at some point, as we keep having work that has slowed down because we haven't addressed the underlying issues, then we can start to have that conversation around okay; we’ve done this twice now. This is the third time that this is going to take a lot longer than it should because we haven't really fixed this. Now we should talk about slowing things down so we can address this underlying issue first and then, from now on, pay the tax upfront. So from now on, it's going to be easier, but then we pay that tax now. So it is a helpful tool. It's something that we can essentially defer that tax to a later point. But then we just have to have those conversations later on when things are painful. Or it often leads to scope creep is another way that that creeps up.

+ +

So we take on a ticket that we think, okay, this is fairly straightforward; I don't think there's too much here. But then we're suddenly getting into the codebase, and we realize, oh, this is a lot more work. And suddenly, a ticket will become an epic, and you really have one ticket that's spiraled or grown into five or six tickets. And then suddenly, you have a person that's really leading like a mini project in terms of the scope of the work that they are doing.

+ +

So then that manifests in some interesting ways where then you have the person that feels a bit like a silo because they are the ones that are making all these big changes and working on this mini-project. And then there's the other one where there's a lot to do. There are a lot of customers, and there's a lot of customization for these customers. So then there are folks that are working really hard to keep the customers happy to give them what they need. And that's where we have too much to do. And we're prioritizing aggressively and trying to make sure that we're always working on the top priority. So like you said, it's super easy stuff.

+ +

CHRIS: Yeah. To say it sincerely and realistically, you're just playing the game on hard mode right now. I don't think there is any singular or even multiple easy answers to this. I think one question I would have particularly as you started to talk about that, there are multiple customers each with individualized needs, so that's one of many surface areas that I might look t say, "Can we sort of choke things off there?"

+ +

So I've often been in organizations where there is this constant cycle of the sales team is going out. They're demoing against an InVision mock. They're selling things that don't exist. They're making promises that are ungrounded and, frankly, technically infeasible or incredibly complicated, but it's part of the deal. They just sold it, and now we have to implement it as a team. I've been on teams where that was just a continuing theme. And so the engineering team was just like, "We can never catch up because the goalpost just keeps moving."

+ +

And so to whatever degree that might be true in this case, if there are ten different customers and each of them right now feels like they have an open line to make feature requests or other things like that, I would try to have the conversation of like, we've got to cut that off right now because we're struggling. We're not making the forward progress that we need to, and so we need to buy ourselves some time. And so that's one area that I would look at.

+ +

Another would be scope, anywhere that you can, go into an aggressive scope cutting mode. And so things like, well, we could build our own modal dialogue for this, but we could also use alert just like the JavaScript alert API. And what are all of the versions of that where we can say, "This is not going to be as nice, and as refined, and as fitting with the brand and feel and polish of the website. But ways that we can make an application that will be robust, that will work well on all of the devices that our users might be using but saves us a bunch of development time"? That's definitely something that I would look to.

+ +

What you described about refactoring is interesting. So I agree with we're not in a position where we can just gently refactor as we find any little mess. We have to be somewhat ruthless in our prioritization there. But like you said, when you get to that third time that a thing is working way harder, then take the time to do it. But really, like just every facet of the work, you just have to be a little better. If you're an individual developer and you're feeling stuck, raise your hand all the earlier because that being stuck, we don't have spare cycles right now. We need everybody to be working at maximum efficiency. And so if you've hit a wall, then raise your hand and grab somebody else, get a pair, rubber duck, whatever it is that will help you get unstuck. Because we're in a position where we need everybody moving as fast as they can.

+ +

But also to say all of those aren't free. Every one of those where you're just like, yeah, do it the best you can. Dial it up to 11 on every front. That's going to drain the team, and so we have to also be mindful of that. This can't be forever. And so maybe it is bringing some new people onto the team or trying to restructure things so that we can have smaller communication channels. So it's only four people working together on this portion of the application, and therefore their communication lines are a bit simpler. That's one way that we can maybe save a little bit. But yeah, none of these are free. And so, we also need to be mindful that we can't just try harder forever. [laughs] That's a way to burn out the team. But what you're describing is like the perfect storm of every facet of this is difficult, and there's no singular answer.

+ +

There's the theory of constraints (I think I'm saying that right.) where it's like, what's the part of our process that is introducing the most slowdowns? And so you go, and you tackle that. So if you imagine a website and the app is slow is the report that you're getting, and you're like, okay, what does that mean? And you instrument it, and you log some stuff out. And you're like, all right, turns out we have tons of N+1s. So frankly, everything else doesn't matter. I don't care if we've got a 3 megabyte JavaScript bundle right now; the 45 N+1s on the dashboard that's the thing that we need to tackle. So you start, and you focus on that.

+ +

And now you've removed that constraint. And suddenly, the three megabyte JavaScript bundle is the new thing that is the most complicated. So you're like, okay, cool, let's look into tree shaking or whatever it is, but you move from one focus to another. And so that's another thing that could come to play here is like, which part of this is introducing the most pain? Is it feature churn? Is it unrealistic sales expectations? Is it developers getting stuck? And find the first of those and tackle it. But yeah, this is hard.

+ +

STEPH: Yeah, it is. That's all really helpful, though. And then, I can share some of the things that we are experimenting with right now and then provide an update on how it's going. And one of the things that we're trying; I think it's similar to the theory of constraints. I'm not familiar with that, but based on the way you described it, I think they're related.

+ +

One of the things that we are trying is breaking the group into smaller teams because there are between 7 and 10 of us. And so, trying to jump from one issue to the next you may have to really level up on different portions of the application to be able to make an impact. And there are areas that we really need infrastructure improvements and then essentially paving the way for other people to be able to move more quickly. We do have to prioritize some of that work as well.

+ +

So if we break up into smaller teams, it addresses a couple of areas, or at least that's the goal is to address a couple of areas. One is we avoid having silos so that people aren't a bottleneck, or they're the only ones that are really running this mini-project and the only one that has context. Because then when that person realizes the scope has grown, bringing somebody on to help feels painful because then you're in an urgent state, but now you have to spend time leveling someone else up just so that they can help you, and that's tough.

+ +

So the goal is that by having smaller teams, we will reduce that from happening because at least everything that feels like a small project...and by feels like a small project, I mean if we have more than one ticket that's associated with the same theme, that's going to start hinting at maybe this is more than just one ticket itself, and it might actually belong to an epic. Or there's a theme here, and maybe we should have two people working on this. And breaking people into groups, then we can focus on some people are focused more on the day-to-day activity. Some people are focused on another important portion of the codebase as we have what may be extracted. I'm going to say this, but we're going to move on, maybe extracted into its own service. [laughs] I know that's a hot one for us, so I'm just going to say it.

+ +

CHRIS: I told you I can't be nerd sniped. This is fine. Let's continue on. [laughs]

+ +

STEPH: [laughs] And then a small group can also focus on some of those infrastructure improvements that I was alluding to. So smaller teams is something that we are trying.

+ +

We are also doing a really great job. I've been really happy and just proud of the team where folks are constantly reaching out to each other to say, "Hey, I'm done with my ticket. Who can I help?" So instead of immediately going to the backlog and grabbing the next thing. Because we recognize that because of this structure where some people are some silos, they have their own little mini backlog, which we are working to remove that to make sure everything is properly prioritized instead of getting assigned to one particular person. But we are reaching out to each other to say, "Hey, what can I do to help? What do you need to get done with your work before I go pick something else up?"

+ +

The other two things that come to mind is who's setting the deadlines? I think you touched on this one as well. It's just understanding why is it urgent? Does it need to be urgent? What is the deadline? Is this something that internally we are driving? Is this something that was communicated without talking to the rest of the team? Is this just a really demanding customer? Are they setting unrealistic expectations? But having more communication around what is the sense of urgency? What happens if we miss this deadline? What happens if we don't get to this for a week, a month? What does that look like?

+ +

And then also, my favorite are retros because then we can vote on what feels like the highest priority in terms of pain points or run these types of experiments like the smaller teams. So those are the current strategies that we have. And I'm very interested to see how they turn out because it is a tough way. Like you said, it's challenge mode, and it is going to burn people out. And it does make people feel fatigued when they have to jump from one priority to the next. So I'm very interested. It's a very interesting problem to me too. It just feels like something that I imagine a lot of teams may be facing. So I'm really excited if anybody else is facing a similar issue or has gone through a similar challenge mode; I’d love to hear how your team tackled it.

+ +

CHRIS: Yeah, I'm super interested to hear the outcome of those experiments. As a slightly pointed question there, is there any semi-formal version of tracking the experiments? And is it just retro to retro that you're using for feedback on that? I've often been on teams where we have retro. We come up with it, and we're like, oh, this is a pain point. All right, let's try this. And then two weeks later, we're like, oh, did anyone actually do that? And then we just forget. And it's one of those things that I've tried to come up with better ways to actually manage, make slightly more explicit the experiments, and then have a timeline, have an almost scientific process of what's the hypothesis? What's the procedure? What are the results? Write up an executive summary. How'd it go?

+ +

STEPH: We are currently using retro, but I like that idea of having something that's a bit more concrete. So we have action items. And typically, going through retro, I tend to revisit the action items first as a way to kick off retro. So then that highlights what did we do? What did we not do? What do we not want to do anymore? What needs to roll over to the current iteration? And I think that could be just a way that we chat about this. We try something new, and we see how it's going each week in retro. But I do like the idea of stating upfront this is what we're looking to achieve because I think that's not captured in the retro action item. We have the thing that we're doing, but we haven't captured this is what we hope to achieve by taking this experiment on.

+ +

Mid-roll Ad

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

STEPH: As for the other thing that you mentioned, I do have an idea for that because a former client that I worked with where we had experiments or things that we wanted to do, we were using Trello. And so we would often take those action items…or it was even more of a theme. It wasn't something that could be one-and-done. It was more of a daily reminder of, hey; we are trying this new thing. And so, we want to remind you each day to embrace this experiment and this practice. And so we would turn it into a Trello ticket, and then we would just leave it at the top of the board. So then, each day, as we were walking the board, it was a nice reminder to be like, hey, this is an ongoing experiment. Don't forget to do this.

+ +

CHRIS: I do like the idea of bringing it into a stand-up potentially as like that's just a recurring point that we all have. So we can sort of revisit it, keep it top of mind, and discard it at some point if it's not useful. And if we're saying we're doing a thing, then let's do the thing and see how it goes. So yeah, very interested to hear the outcomes of the experiment and also the meta experiment framework that you're going to build here. Very interested to hear more about that.

+ +

And just to say it again, this sounds like your perfect storm is not quite right because it doesn't sound like there's a ton of organizational dysfunction here. It sounds like this is just like, nah, it's hard. The code's not in perfect shape, but no code is. And there's just a lot of work to be done. And there are priorities because frankly, sometimes in the world, there are priorities, and you're sort of at the intersection of that.

+ +

And I've been in plenty of teams where it was hard because of humans. In fact, that's often the reason of we're sort of making up problems, or we're poorly communicating or things like that. But it sounds like you're in the like, nope, this is just hard. And so, in a way, it sounds like you're thinking about it like, I don't know, it's kind of the challenge that I signed up for. Like, if we can win this, then there's going to be some good learnings that come out of that, and we're going to be all the better. And so, I wish you all the best of luck on that and would love to hear more about it in the future.

+ +

STEPH: Thank you. And yeah, it has been such an interesting project with so many different challenges. And as you've mentioned, that is one area that is going really well where the people are wonderful. Everybody is doing their best and working hard. So that is not one of the competing challenges. And it is one of those; it’s hard. There are a lot of external factors that are influencing the priority of our work. And then also, some external areas that we don't have control over that are forcing some of those deadlines where customers need something and not because they're being fussy, but they are themselves reacting to external deadlines that they don't have control over.

+ +

So it is one of those where the people are great, and the challenges are just real, and we're working through them together. But it's also hard. But it's helpful chatting through all the different challenges with you. So I appreciate all of your thoughts on the matter. And I'll report some updates once I have some more information.

+ +

On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+HE4ugiN4 + + ]]> + + Chris Toomey + Steph Viccari + + + 307: Walking Contradictions + https://bikeshed.thoughtbot.com/307 + 5923ae6d-308a-433a-8235-8a4a4624bc3e + Tue, 07 Sep 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this episode, Chris talks about testing external services and dissects a tweet on refinements for Result. Steph talks about thoughbot's recent improvement to their feature flag system. + 36:56 + no + + + On this episode, Chris talks about testing external services and dissects a tweet on refinements for Result. Steph talks about thoughbot's recent improvement to their feature flag system. +Links: +refinements For Result (https://twitter.com/alassek/status/1430683412264857600) +Faking External Services in Tests with Adapters by German Velasco (https://thoughtbot.com/blog/faking-external-services-in-tests-with-adapters) +Testing Interaction with 3rd-party APIs (https://thoughtbot.com/upcase/videos/testing-interaction-with-3rd-party-apis) +Transcript: +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new with you? +STEPH: Hey, Chris. Well, today is Summit Day at thoughtbot, and it's the day where all the bots gather, and we hang out, and we chat, and we play games. And it's a lot of fun. We're actually taking more of a respite this year just because life has been taxing. And so we decided to give people more of the day off. So we still had some fun events, but most of it is everybody gets a chill day. Do something that brings you joy is the theme of the day. +But we had Lightning Talks, which is my favorite thing that we do on Summit Day because I realize that I just work with the coolest people, and they have such interesting things to talk about. And we had such a variety of topics. So one of them, Alex Chen taught us acronyms in K-pop. And Sam Kapila, our resident foodie, taught us about a variety of spices. And one of my favorite talks was by Akshith Yellapragada, and it's the top 10 best limo entrances by The Bachelor, and it was phenomenal. And I really want to share some stuff that I learned with you. +CHRIS: The Bachelor like the TV show? +STEPH: Yeah, like the TV show. Are you familiar with it? Have you seen it before? +CHRIS: I am familiar with it. I know it exists. I know that there's a spinoff, The Bachelorette. And I believe we have now exhausted my information on the matter. +STEPH: [laughs] That's fair. For anyone that hasn't seen the show, the show revolves around a single person. For the bachelor, it's a single bachelor who dates a number of people over several weeks, and then they narrow down the people. There are elimination rounds, and the whole goal is for them to find their true love. So each week, someone is eliminated, and I think the show ends with a marriage proposal. So it's a wild show. It's something. [chuckles] +And in Akshith's talk, I learned some really fun terminology. The first one is the Crown, and this is actually an important building block because we're going to get to the rest of the terminology that uses this word, so we got to start here. So the first one is the Crown, and this is the person that everyone's competing for. So they're the star of the show. They're the one that everybody is hoping to fall in love with or will fall in love with them so they get a marriage proposal. +So then the other stuff that I've learned is all about the entrance because again, we're talking about the top 10 best entrances. And one of them is the sidecar entrance. So this is where the player, because yes, this is totally a game, has someone assist them in meeting the crown. So it could be like a family member, maybe it's like your grandma. +And then there's TOT, T-O-T, which is short for Trick Or Treat. And this person exits the limo wearing a costume. So it's someone wearing a shark costume. There was someone wearing a sloth costume where they really dedicated to the role, and they climbed a tree and hung from a branch. I don't know for how long but for long enough to really vibe with the role. +And then there's the Kringle, and this person brings a prop or a present to the Crown. And there's the Grandy, and this player arrives in something other than a limo. So the example that Akshith provided is someone arrived in a motorized cupcake. +CHRIS: Was the cupcake edible? +STEPH: I don't think so, fair question. [laughs] +CHRIS: So really just like a go-kart that looked like a cupcake, not really a motorized cupcake, if I'm going to meet pedantic about the thing, [chuckles] which I think is my job. +STEPH: Yes, it is a motorized non-edible cupcake, but that seems like something a next player should do. They should really up the game, and they should bring an edible motorized cupcake. +CHRIS: Yeah, because you get the visual novelty, but then you layer on top of it that it's actually something that you can now eat, and it's a double win. +STEPH: Ooh, and then you're a Grandy, and you're a Kringle because you arrived in something other than a limo, and it's a present. +CHRIS: I love how you have so deeply internalized this now that you're like, ooh, okay. I can remix here. I'm going to bring together the pieces. Yeah, all right. Yeah, this all makes sense. +STEPH: Yeah, it was a lot of fun. Those are most of my notes for today. I have some tech stuff too, but this felt like the most important thing to start the show with. +CHRIS: We use the phrase tech talk and nonsense to describe the show often, but I think nonsense and tech talk is the correct orientation. +STEPH: [chuckles] +CHRIS: Correct in terms of importance and chronological order, and whatnot. But yeah. +STEPH: I love that we start with a bit of nonsense. So I do have some tech stuff. But first, before I share any of that, what's going on in your world? +CHRIS: I'm sure there's plenty of nonsense in my world, but at the top of my list is some tech stuff. So someone on Twitter, Adam Lassek, reached out and he suggested related to the conversation and the back and forth that I've been having with myself around some of the data structures within the app that I'm building…So I've talked about the dry-monads result object, and there's this success and failure. And I wanted to introduce this new method called bimap, but I wanted to do it in a reasonable way. So I wrapped, and then I wrapped, and I wrapped things. +As an aside, former colleague and friend of the show, Joel Oliveira, sent a wonderful tweet which was a reference to the SNL video where they make a taco and put it inside of a pizza and put it inside of a bag. And that was his joke about it, which I really liked. That was an excellent reference. But in this case, Adam Lassek reached out and suggested if I'm that squeamish about monkey patching, which I am, have I considered refinements? And so he sent an image of a code sample, which is so kind of him to send that much detail over, but it was interesting because I know of refinements in Ruby. I know of that as an alternative to monkey patching, a more refined way, but a safer way, a more controlled way to alter code, but I've not actually used them. +STEPH: I'm not familiar with refinements. What is that? +CHRIS: Refinements are a way...so similar to monkey patching, where you say like, I'm going to reopen this class or this module and define a new method or redefine a method or do something like that, a refinement is a way to do that in a scoped manner. So I'll be honest, I'm not super familiar with them. I think I came into Ruby at a time where the community was moving away from monkey patching. And the dogmatic swing of the pendulum was like, that's a bad thing to do. And so even the refinements were introduced, as far as I understand it, to be a more controlled way to do it. So it's not just like, hey, cool. This module is redefined now in your app in a magical way that's really hard to figure out and hard for folks to debug refinements. You have to explicitly opt into within a certain lexical scope. +I'll be honest; I know that at the headline level. I don't actually know the ramifications or where and when you can use them and how you can. But I know that that was the idea is refinements are a way to do monkey patching but in a more controlled, more understandable manner, and so the code sample that Adam shared does that. And it's very interesting. As I'm looking at it, I'm like, okay, that's cool because I think it'll be a little bit safer. +But at the end of the day, my concern wasn't safety in this case because I was introducing a method that would be new, that would be additive to the API of this module that I'm working with, and so that I think of as a relatively safe operation. My hesitation was more around how does someone figure it out if they're working with this? And particularly, the name of the method that I was introducing was bimap so, B-I-M-A-P. And if someone sees that in our codebase and is like, "Bimap, where is this coming from?" Well, this is one of those dry-monad result objects. And they go to the code, and they try and look it up in the docs, and they're just not going to find anything. +And I can imagine losing a lot of time to try and chase that down. There are ways to figure it out. There's the method in Ruby, which is a wonderful trick for chasing things down. Or if you grep the codebase, you'd find it. But I think I'm possibly over-indexed on worrying about that lost time, that moment. But I've lost that time so many times in my life where I'm like, I can't grep for this. I can't Google for this. And so I have so strongly moved in the direction of being like, everything should be grepable, everything should be googleable. Those are the two of the things that I believe about software. I think I believe a bunch of stuff. +STEPH: I think we have a full episode that talks about what we believe in software. +CHRIS: I believe we do. +STEPH: Cool. Thanks. Yeah, I have not heard of refinements. That sounds really interesting. I really like that bit about everything should be grepable, and everything should be googleable, googling everything. I kind of agree with that one. We live in a world where we're always doing bespoke things so that one feels a little bit harder that we're always going to be able to Google it. But then that encourages people to constantly publish the bespoke work that they're doing so then others can benefit from that work. But the grepable, I absolutely agree with that one. It's so frustrating where I see a method, but I cannot find its definition. And then having the ways to figure out where that method is defined to then find its definition is crucial. +CHRIS: Yeah, it's interesting. I definitely feel that way very strongly. And it's in such stark contrast to Rails. Rails is like, hey, don't worry. There's going to be a lot of methods. You don't need to worry about where they come from, or why they exist, or what they are, or what they do. Well, probably what they do. But all of the magic inflections on database tables,, and suddenly you have methods named after every column. That's both very magical and hard to grep for or impossible to grep for, but it also leaks the entire structure of your database into your application in a way that I've always felt a little bit complicated about. And so explicitness, grepability, those are things that I care about. +There's another one, delegates in Rails, that I sometimes pause around using especially when it's like delegates 19 methods to user prefix user. And so you end up with methods that are like username. And that's a delegation to the user object to get the name method off of it, but it creates the method user_name. And you're never going to be able to grep for that. And it saves like a little bit of code, definitely, but it saves this very obvious, very knowable code. So this one I actually shy away from using delegates in most cases, and I'll just write out the methods manually because sometimes I like to hear the clackety of my keyboard. There's a reason I have a clackety keyboard. +STEPH: You want to get your money's worth. You want to clackety as much as possible. Yeah, I'm also not a fan of delegates. This may be a lie, but I don't know that I've actually ever used it. I've worked with it, but I can't think of a time that I've implemented delegates. Maybe that's a lie, but I'm going to say it anyways because that feels true, at least in the last couple of years. +CHRIS: I feel like that could be true for the last couple of years. I would be surprised if you have never even added to a delegates line. Because that's the thing, you can just keep shoveling stuff into them as well. So I would put money on you having used it at some point and then just forgotten about it. But who knows, maybe not. +STEPH: This is where we play two truths and a lie and that one's my lie. [laughs] Yeah, that's also fair about adding to it because if that's already defined and it's easier to add to it, I don't know. Who knows what past Stephanie has done, probably some wild stuff. +CHRIS: It's unknowable at this point. It's lost to the sands of time. But looping back to the core thing of this refinement and the module, I think I'm leaning in the direction of doing that and unwinding my wrapping and wrapping layer thing. Because obviously, as I talked about...I think it was the previous episode or maybe two episodes ago. There was conceptual complexity to the additional wrapping layer. Even as I was fully in the context of working on that, I was still getting myself confused in either triple wrapping or then unwrapping too much or whatever. And these are the concerns with this type of code. So moving away from that feels better, having just a single layer of context wrapping around a given value. +And then the other thing it's actually just a lot less code, and it's less prone to error, I think. That's my hope. I have to look into exactly how refinements get used, but I noticed in a couple of places that sometimes we were wrapping with this local value object that gave us the bimap method, and sometimes we were forgetting to. And so, I could see that being a very subtle, easy way to introduce failures into the app that would be hard to catch just by looking at it. +So I think having a more global refinement...although I think that's sort of a contradiction, a global refinement because I think refinements are meant to be local. But anyway, I'm going to look into it because it's a much more concise code sample than what I have. Yeah, I'm going to poke at that a little bit. But it was an interesting exploration of some different things. And then it forced me to consider why am I so resistant to monkey patching at this point, especially in this particular case where I think it's okay-ish? +STEPH: That's a good question. Do you have any insights? I am also resistant to monkey patching. I feel that pain and also that timidness of diving into that space. But I'm curious, have you figured out any other reasons that you really prefer to avoid it? +CHRIS: I think this one falls into that sort of...what's the word? Like tribal knowledge of we've been burned by it in the past and therefore we build almost a...religious is too strong of a word but that sort of cultural belief. This is a thing that we do not do because of the bad things that we've experienced in the past. And there are a lot of things that fall into that experiential negative space. +So with monkey patching, things that I know we can run into is if I introduced this bimap method, but I introduce it subtly differently than the library will eventually, then they could eventually introduce it themselves. And suddenly, I have this fork of my code expects it to work this way, but you've now implemented it that way. I no longer can upgrade. This is a critical piece of infrastructure in my app. I've just painted myself into a corner by doing this. Whereas if I do this wrapping layer, that's my code. I own that. It's not going to be a problem in that same way. +There's also the subtlety, the grepability that sort of thing is a concern in my mind. Like, is this our code? Is this their code? Is this an engine? Being able to find code within a codebase, I think, is a critical thing. And so that's a part of the hesitation. I also know longer ago prototypes...I want to say Prototype JS was the name of the project, but it was one that was just like, yeah, JavaScript doesn't have enough stuff in the standard library. So we're just going to override everything and add all of these wonderful methods sort of in the way that Active Support does, which is an interesting comparison. +But the JavaScript community definitely moved away from Prototype. And now JavaScript is a language or the standard runtime that's available in most JavaScript engines. It has a lot of the methods, but there are conflicts, and stuff gets weird, and it's all complicated. But again, as I thought of it, Active Support is a complete contradiction to everything I'm saying. Active Support just adds whatever to anything, 2.days.ago. Why does the number 2 have a days method? Because it's great, that's why. But I'm just a walking contradiction, I guess. +STEPH: Everything you said really resonates with me. And I'm just trying to reason with myself like yes, Active Support uses a lot of this, a lot of metaprogramming, and adds everything it wants to. So why does that feel okay? And I wonder if it comes down to one is more almost like an agreed standard. It's built by a team, and it's maintained by a team, and then it's used by a large number of people, and then you get that feedback. Or maybe it's not even just a team, but it's a larger community versus if it's internal to your software team, maybe that doesn't feel like a big enough group or if it just needs...Rails is also documented. So maybe that's part of it, too, is if you are going to dive into that space, it's easy to discover, and it's well-documented as if you are building an open-source project that other people are going to use. Like, you designed for the intent of people to use this pattern that you've introduced, then perhaps that's when it starts to feel okay. , +But the experiences I have had is where people basically will add some dynamic programming or monkey patch an existing feature. And then that's very hard to find and has surprising results, or it gets outdated. So I guess it comes down to who are you designing for? Are you designing for more of an open-source community, or you're at least designing for the people behind you that are going to be using this? Or is this a one-off adventure that you have chosen for yourself and future developers to discover? [chuckles] +CHRIS: Yeah, I think that's a good summary, although I'm open to the fact that I exist in a state of contradiction. I'm also fine with that, to be clear. [chuckles] But I think what you said is true, and I think there is subtlety and nuance and reasons that it's okay in one context and less okay in others. And that idea of just like, I don't know, this is one of those things that I got in my head that I've done the thinking a long time ago to decide this is a thing I don't do. +So now, in order to override that, I would have to do so much thinking. I would have to be like, all right, well, my brain tells me, no, but I'm going to go reread everything about monkey patching right now to convince myself that it's okay or to fully get the context and the subtlety and the nuance. And so sometimes we have to rely on that heuristic knowledge of monkey patching, nope, don't do that. That's not a thing, but other stuff is fine. And well, Active Support is fine because it's Rails. But it is interesting to observe contradictions and be like, huh, look at me go. All right. Well, moving on. +STEPH: It's our lizard brain that's saying, "Hey, there's danger here." [laughs] +CHRIS: Exactly. +STEPH: I rather like living in a world of contradictions, or at least I find it that I'm drawn to them. And maybe that's also one of the things that I really like about consulting is because then I join all these different teams, and I hear all these different opinions. So as I'm forming these opinions around something like tests are great, I really like tests, and then someone's like, "I really hate tests." I'm like, "Cool. Let's talk. I want to understand why you don't like this thing that I think is wonderful because then I'm really interested." So I find that I'm often really drawn to contradictions as I like hearing opinions that are very different than mine and finding out why people have a different opinion than mine. +CHRIS: Yeah, the world is full of contradictions. So it's, I think, at least a useful way to exist in the world, to be open to them and to enjoy exploring them. But yeah, I'll update in future weeks if I do end up going the refinements route. I'll let you know if anything interesting falls out of that. +And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open source culture in an accessible and documented API. +With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city +The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. +STEPH: So we made a recent improvement to our feature flag system, which I'm really excited about, that we have found a way to improve that workflow because it felt really great that we're...well, okay, I should say that with a caveat. It felt really great that we're using feature flags to ensure that the main branch is always in a deployable state. But it did not feel great around how tedious it was becoming to add all of the feature flags specifically because each time we're adding a feature flag, we're having to add a migration. So we're having to run a migration, add the feature flag column, and then we can interact with that feature flag. And that part's okay. It was more removing that feature flag once we're done with it, that that part was starting to feel tedious because then that's becoming a two-deploy process. +So one change is to remove the code that's relying on that feature flag. And then the second deploy was to actually drop that column because we wanted it to be safe to make sure that the code wasn't trying to reference a database column that didn't exist anymore, which is what happened at one point at first when we weren't doing the two-deploy process. +So the improvement that Chris White came up with is where we're now using a Postgres JSONB column. And it's here that we actually have a feature flag YAML file. And we can have the name of the feature flag. We have a description of the purpose of the feature flag. And we have an enabled property on there, so then we can turn it on and off. The benefit of this is now we don't have to do that two-deploy process. And we also don't have to run a migration for when we're adding a new feature flag. So we can add it to the feature flag file, we can load it in, and then we can set that property to say, "Yes, this is enabled," or "No, it's not." And that has just simplified our feature flag process. +One tricky bit that I believe the team ran into is around enabling this with Active Admin because Active Admin was just relying on those database columns to then turn something on or off. But then we've added some methods that work well with Active Admin that then say, "Read from here when you're checking to see if something is enabled," or "Look at this list to see which feature flags can be turned on and off." So it's been a really nice improvement, and everybody on the team seems to be in favor of the ways that we've improved this. So it's been really nice. So I wanted to come back and bring an update on how we've simplified our feature flag system. +CHRIS: That definitely sounds like a nice improvement, the ability to just more regularly iterate around that or taking away the pain, any pain associated with using feature flags. Because they are such a nice thing to have, but there's that overhead. Then you start to have that voice in your head that's like, do I really need a feature flag for this? Could I just sneak this one in? And we always regret that. +I had a similar thing this week where I wrote some code. I didn't quite write as many tests as I should have. And it was wildly broken, just like all of the connection points through everything were broken. But then it pushed me in an interesting direction where I was like, well, what I'm going to do is write an integrated test. It was basically an event coming in from a webhook that then enqueued a job, which did a thing, which then spit out an email. But it was broken at like three layers, and I was very embarrassed, if we're being honest. But, I don't know, I was just having a low energy afternoon, and I did not write the test, which I know I'm supposed to do. +So similarly, any pain that we can take out of these things that we're supposed to do, any way that we can pave the happy path, I'm all about those. I'm intrigued because I think we've talked about this before, but it sounds like you guys have a very home-grown feature flag system. Is that true? +STEPH: We do. +CHRIS: Is there something about it that makes it unique to your situation, or was it just like that's what happened? Someone early on was like, "We need feature flags. I can just do the simplest thing that works," and then that's where you're at now or? +STEPH: You're asking a very good question. And I'm trying to recall what led us to the state that we're in because I feel like we had this same discussion several episodes back when we were introducing the home-grown feature flag system. And I was like, there are reasons, but I didn't really dive into those reasons because it felt very custom to the application. But now I've forgotten what those reasons were. So I think you ask a great question where it'd be worth revisiting to confirm that yes, there's a reason for this home-grown version versus using something like Flipper. +CHRIS: I'm glad I'm at least consistent over time in the questions that I ask and the heuristics that I have. This does feel like one of those things. It's not quite like crypto where I'd be like, we can never write our own crypto. But a feature flag system, I would be really intrigued if there are things that they are just workflows or functionality that you really need that are not supported by any of the existing solutions that are out there. I think audit trails is an interesting one. I think Flipper has a hosted product at this point that does that, but the local version wouldn't necessarily. So maybe that's a thing that you want to get. Again, I'd just be really interested. It sounds like the current state of the world that you have is enabled or disabled; just broadly, that's it. Those are the two states for any given flag. Is that true? +STEPH: It is. There's nothing complex with the flags in that nature. And then we use naming to indicate if something is more for beta, so if it's a change that we're making to the codebase, but it's a feature flag that we plan on removing, versus maybe it's a feature flag for enterprise customers. +CHRIS: Oh, interesting. I wouldn't think of using a feature flag in that context where it's going to be like a persistent, long-lived; this is conditional logic around some state or some property of the viewer. I think of feature flags as a way to gate code conditionally based on a point in time. And the reason I asked about the enabled-disabled basically like the Boolean state for your flags is when I've worked with feature flags in the past, I've liked having the ability to say, for this user or these users, or this group of users, which we've named this is our beta list…and it's the ten people that just really love the product and are happy to bump into some rough edges. And so we'll put things on for them first or even like percentages, so roll it out to 10% and then 50% and so on. And I think the larger an application and user base gets, the more that sort of thing starts to feel right. +STEPH: Yeah, we certainly have some complexity around where each customer can really specify which features that they want. And then the features also differ a bit for each customer. So we are in a world where we're pretty customized or configurable for different customers. And whether that's something that we could simplify, that would certainly be a good question or something to pursue. +But part of this also feels like our decision may have been based around what the system was already doing, and we're looking for ways to make slow improvements versus trying to redesign the whole thing. Because initially, the way we were customizing all of these different features for customers was in a YAML file. And that part was painful because then, anytime we wanted to make a change, it required a deploy. So the introduction of feature flags is really to get away from having to deploy to then make a small change like that. +But now that we're in the space that we can easily configure that change and do that on the fly and not have to issue a deploy, I think we're now in a good space to reassess. And the team may have some really good answers. Perhaps I'm just not recalling as to why we've chosen the more home-grown feature flags. But yeah, I'll visit that topic and report back. Because I've been coasting along on our new system and enjoying it, but you're asking some really good questions. +CHRIS: I mean, as an aside, if you're coasting along and really enjoying it, then maybe you don't need to ask any questions. It's still interesting. I would be intrigued to know. But if it's not causing you any pain, then you probably shouldn't change it. Because frankly, changing out the feature flag system is going to be non-trivial, I'm pretty sure. You could feature flag the feature flag system, and then you can transition from one to the other. You need a third feature flag system for that. But anyway, I digress. [chuckles] +STEPH: You referenced crypto earlier. So I think I like the feature flag, the feature flag system. We should have some crypto flags in there somewhere. I think that's a thing too. But I think the main goal if I'm looking into changing it would be, circling back to what we were talking about earlier, is discoverability, so having a home-grown feature flag system. How easy is it for…if nobody was around on the team and there was someone new working with it, how easy would it be for them to turn something on or off? And if that's easy, then that's great. Then I think we've got a great home-grown system. If that's challenging, then I definitely think it's worth reassessing. +And now a quick break to hear from today's sponsor, Scout APM. +Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. +Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. +See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. +CHRIS: One of the things that's been interesting working lately in the app that I'm building is thinking about testing. We have a number of interactions with third-party services. Frankly, a lot of the app is that at this point. We have a handful of different external data providers systems that we're interacting with, webhooks and flows and things like that. And so we had to make that decision that you always have to make in these sorts of situations which is, how are we going to test this? +And there's a wonderful blog post on the thoughtbot blog called Faking External Services in Tests with Adapters. It's by the one and only German Velasco. And it is a beautiful summary of the different approaches that you can take, but it really dials into one, which is the adapter pattern. There's also a weekly iteration episode on Upcase with Joël Quenneville, which discusses a little bit more of an exploration of the different options. There are sort of a handful of different options that we can consider your whereas the blog post by German talks specifically about the adapters approach. +But to talk about them briefly, there's one where you can go all the way outside your app, spin up a fake service. Typically, we would do this with Capybara Discoball, which is a wonderfully named project. But it allows you to spin up a little Sinatra app type thing such that your web application is still making quote, unquote "real HTTP requests." This external service is going to catch that and respond with whatever canned data or structured responses that you want. +But you still have the ability in that to, say, tell it to create data beforehand or be in a certain state or respond with certain data or have any stateful persistence. So if you create a record in that external system, and then later you query for it, that system can do that. But it has the complexities of now, your test suite is running different systems. And do you have thread-safety or all that kind of stuff? So that's a particularly complex end of the spectrum. At the lowest end would be stubbing and mocking. You just take whatever external clients you have, and you're mocking the API calls in them. That's the lowest end. And that's the one, especially for feature specs, those I try and avoid. Then there's a middle ground of like WebMock or VCR, those sort of things where you're saying whenever you see an HTTP request that looks like this, respond in this way. You record the cassettes, all that kind of stuff. +And then there's the one that we've settled on, which is the adapters. So the client that we've introduced in our local codebase to interact with any of these third-party systems internally has a class attribute, a cattr_accessor in the Rails parlance, I believe. And that allows us to switch out the backend. And so we have a real HTTP backend, and that's the one that actually runs in production and a test in-memory backend. And that in-memory backend can implement whatever logic. We're ending up with one of them almost recreating this external service, sort of re-coding some of their inconsistencies or oddities but also features and whatnot. +But it feels like it has struck just the right balance, and it allows our feature specs to be very rich, very real. We start up the world, and we say, "Hey, external service be in this state." And then I'm going to go visit the page. I'm going to see the data. But we are almost making real HTTP requests. It's very close. It's always an interesting choice to make here. I'm very happy with the one that we've made, but it's still not perfect. There are always going to be trade-offs between the different options here. But it's always interesting revisiting this and being like, which one am I going to choose today? +STEPH: I feel like my natural progression when testing external services; I always start with WebMock, and then I progress to using adapters. And then from there, I go to actually replacing the HTTP service that is receiving and then returning a response, like you mentioned to Capybara Discoball earlier. So I can certainly see what you like about the adapter pattern. You mentioned that you're coding some of the inconsistencies. That feels very real. I'm curious if you have an example of how you've had to manage that recently. +CHRIS: A specific example would be the external API responds with certain error codes or error structures. So it's an error. It has a status of a number and then a reason, or sometimes instead of a key that is reason; it’s the message. So it's like, oh, okay, I see that in this endpoint, you respond with reason, and then this endpoint you respond with message. So now, do I encode that into my fake? I guess I do. So my adapter now implements things like that. There are cases where it's inconsistency where I'm like, well, this is the way they behave. So I would like our test suite to exist in the context of that because then our app is getting exercise in a real way. +But in some cases, it's like little bits of logic validation that an external system might do if that's an important part of the flow. The app that we're building has a lot of forms and a lot of data validation and things like that. And so, we want to make sure that we have robust handling around that robust messaging to the user so that it's very clear what they need to do and how they need to respond to things. And so putting in little bits of that like, oh, that's how you format a phone number, okay, cool. Our fake will also format phone numbers in that way, things like that. +STEPH: Every time the topic of testing external services comes up, I really, really want VCR to be the answer. I really like the idea of being able to validate that...because you'd mentioned that we're programming the expected return from this other service. And it's very easy to get out of sync with those actual responses. And then we don't really have a great way to stay up to date other than we wait for production or staging environment to fail. And then we realize something has changed, and we have to go and update either our mock or our adapter. And maybe that doesn't happen often if you're working with an external service that is very good about broadcasting when they have a breaking change. +But if you're working with a less stable endpoint, then I always want VCR to really work. But it's just one of those areas where I'm like, yes, that's the thing that I want. I want this idea where I can rerun my tests in a way that they actually hit that service and record the response. But then I have felt pain [chuckles] from working with VCR and how it's configured, and how people have used it. It's one of those where I don't blame the library. I like the library. But the way people have implemented it and test I have felt a lot of pain from that. +CHRIS: Yeah, I definitely agree with that. It feels like it's nice if you can push the mocking all the way out to that layer. Because like right now, our codebase has code in it that is subtly changing the behavior for a test, and I don't like that. It's only the swapping out of the adapter, so it's a very minimal thing. And we try and push all logic away from that such that the test adapter is as similar as possible to the real production situation. But it's enough difference that I agree I would like if VCR would just like, I catch the HTTP requests, and I respond with the same thing and sometimes we can pass through. +I do think one of the fundamental limitations, or at least very hard to get right things, would be sequential requests. So I post to this endpoint in the external service, which creates some data. And then later, when I make a GET request to their endpoint, I should get back that data that I just created. That's, I guess, doable because you can have sequential requests, have cassettes that are first this request, then that request, then that request. And it knows that, like scope them to a given spec. But that feels extra difficult. And it does, again to your comment, the maintainers of that project do a wonderful job, but it's a really hard target to hit. +STEPH: Well, and one of the other hard requirements with using a tool like VCR is then that external service really needs that sandbox staging environment that you can use. So that way you can create this data, you can rerun your test. So they're actually going to hit this real environment. They're going to create this data and that not have any harmful effects. And then you can record fetching that data. So it requires a lot of pieces to fall into place for it to work well. But then I was just thinking as you're talking about adapters, I'm like, yeah, I love the adapter pattern. I've really enjoyed that one for testing as well. But then I immediately start to think, oh, well, what happens when it gets out of sync, and how do we know that it got out of sync? And I don't have a great answer to that. +CHRIS: Production blows up, obviously. +STEPH: Production blows up, and then we go update our adapter. That's very calm. [laughs] +CHRIS: It would be great if CI could more proactively catch that or...yeah, I agree. I would love if VCR would work because that facet of it is so attractive. But [chuckles] I've never gotten to walk exclusively the happy path with VCR. So here we are. This is a classic case of here's four options as to how we can think about this hard and important thing that we do in our codebases, and they all have trade-offs much like everything else in software. +STEPH: I'm going to add this to my developer bucket list to live in a world where I can easily validate if an external API has changed or not and then also have tests that know when something has broken before production does. +CHRIS: Ooph, dare to dream. I like it. +STEPH: I'm a dreamer. +CHRIS: I want to live in that world. Well, with that wonderful dream to take us out, should we wrap up? +STEPH: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey. +STEPH: And I'm @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeee. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + On this episode, Chris talks about testing external services and dissects a tweet on refinements for Result. Steph talks about thoughbot's recent improvement to their feature flag system.

+ +

Links:

+ + + +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new with you?

+ +

STEPH: Hey, Chris. Well, today is Summit Day at thoughtbot, and it's the day where all the bots gather, and we hang out, and we chat, and we play games. And it's a lot of fun. We're actually taking more of a respite this year just because life has been taxing. And so we decided to give people more of the day off. So we still had some fun events, but most of it is everybody gets a chill day. Do something that brings you joy is the theme of the day.

+ +

But we had Lightning Talks, which is my favorite thing that we do on Summit Day because I realize that I just work with the coolest people, and they have such interesting things to talk about. And we had such a variety of topics. So one of them, Alex Chen taught us acronyms in K-pop. And Sam Kapila, our resident foodie, taught us about a variety of spices. And one of my favorite talks was by Akshith Yellapragada, and it's the top 10 best limo entrances by The Bachelor, and it was phenomenal. And I really want to share some stuff that I learned with you.

+ +

CHRIS: The Bachelor like the TV show?

+ +

STEPH: Yeah, like the TV show. Are you familiar with it? Have you seen it before?

+ +

CHRIS: I am familiar with it. I know it exists. I know that there's a spinoff, The Bachelorette. And I believe we have now exhausted my information on the matter.

+ +

STEPH: [laughs] That's fair. For anyone that hasn't seen the show, the show revolves around a single person. For the bachelor, it's a single bachelor who dates a number of people over several weeks, and then they narrow down the people. There are elimination rounds, and the whole goal is for them to find their true love. So each week, someone is eliminated, and I think the show ends with a marriage proposal. So it's a wild show. It's something. [chuckles]

+ +

And in Akshith's talk, I learned some really fun terminology. The first one is the Crown, and this is actually an important building block because we're going to get to the rest of the terminology that uses this word, so we got to start here. So the first one is the Crown, and this is the person that everyone's competing for. So they're the star of the show. They're the one that everybody is hoping to fall in love with or will fall in love with them so they get a marriage proposal.

+ +

So then the other stuff that I've learned is all about the entrance because again, we're talking about the top 10 best entrances. And one of them is the sidecar entrance. So this is where the player, because yes, this is totally a game, has someone assist them in meeting the crown. So it could be like a family member, maybe it's like your grandma.

+ +

And then there's TOT, T-O-T, which is short for Trick Or Treat. And this person exits the limo wearing a costume. So it's someone wearing a shark costume. There was someone wearing a sloth costume where they really dedicated to the role, and they climbed a tree and hung from a branch. I don't know for how long but for long enough to really vibe with the role.

+ +

And then there's the Kringle, and this person brings a prop or a present to the Crown. And there's the Grandy, and this player arrives in something other than a limo. So the example that Akshith provided is someone arrived in a motorized cupcake.

+ +

CHRIS: Was the cupcake edible?

+ +

STEPH: I don't think so, fair question. [laughs]

+ +

CHRIS: So really just like a go-kart that looked like a cupcake, not really a motorized cupcake, if I'm going to meet pedantic about the thing, [chuckles] which I think is my job.

+ +

STEPH: Yes, it is a motorized non-edible cupcake, but that seems like something a next player should do. They should really up the game, and they should bring an edible motorized cupcake.

+ +

CHRIS: Yeah, because you get the visual novelty, but then you layer on top of it that it's actually something that you can now eat, and it's a double win.

+ +

STEPH: Ooh, and then you're a Grandy, and you're a Kringle because you arrived in something other than a limo, and it's a present.

+ +

CHRIS: I love how you have so deeply internalized this now that you're like, ooh, okay. I can remix here. I'm going to bring together the pieces. Yeah, all right. Yeah, this all makes sense.

+ +

STEPH: Yeah, it was a lot of fun. Those are most of my notes for today. I have some tech stuff too, but this felt like the most important thing to start the show with.

+ +

CHRIS: We use the phrase tech talk and nonsense to describe the show often, but I think nonsense and tech talk is the correct orientation.

+ +

STEPH: [chuckles]

+ +

CHRIS: Correct in terms of importance and chronological order, and whatnot. But yeah.

+ +

STEPH: I love that we start with a bit of nonsense. So I do have some tech stuff. But first, before I share any of that, what's going on in your world?

+ +

CHRIS: I'm sure there's plenty of nonsense in my world, but at the top of my list is some tech stuff. So someone on Twitter, Adam Lassek, reached out and he suggested related to the conversation and the back and forth that I've been having with myself around some of the data structures within the app that I'm building…So I've talked about the dry-monads result object, and there's this success and failure. And I wanted to introduce this new method called bimap, but I wanted to do it in a reasonable way. So I wrapped, and then I wrapped, and I wrapped things.

+ +

As an aside, former colleague and friend of the show, Joel Oliveira, sent a wonderful tweet which was a reference to the SNL video where they make a taco and put it inside of a pizza and put it inside of a bag. And that was his joke about it, which I really liked. That was an excellent reference. But in this case, Adam Lassek reached out and suggested if I'm that squeamish about monkey patching, which I am, have I considered refinements? And so he sent an image of a code sample, which is so kind of him to send that much detail over, but it was interesting because I know of refinements in Ruby. I know of that as an alternative to monkey patching, a more refined way, but a safer way, a more controlled way to alter code, but I've not actually used them.

+ +

STEPH: I'm not familiar with refinements. What is that?

+ +

CHRIS: Refinements are a way...so similar to monkey patching, where you say like, I'm going to reopen this class or this module and define a new method or redefine a method or do something like that, a refinement is a way to do that in a scoped manner. So I'll be honest, I'm not super familiar with them. I think I came into Ruby at a time where the community was moving away from monkey patching. And the dogmatic swing of the pendulum was like, that's a bad thing to do. And so even the refinements were introduced, as far as I understand it, to be a more controlled way to do it. So it's not just like, hey, cool. This module is redefined now in your app in a magical way that's really hard to figure out and hard for folks to debug refinements. You have to explicitly opt into within a certain lexical scope.

+ +

I'll be honest; I know that at the headline level. I don't actually know the ramifications or where and when you can use them and how you can. But I know that that was the idea is refinements are a way to do monkey patching but in a more controlled, more understandable manner, and so the code sample that Adam shared does that. And it's very interesting. As I'm looking at it, I'm like, okay, that's cool because I think it'll be a little bit safer.

+ +

But at the end of the day, my concern wasn't safety in this case because I was introducing a method that would be new, that would be additive to the API of this module that I'm working with, and so that I think of as a relatively safe operation. My hesitation was more around how does someone figure it out if they're working with this? And particularly, the name of the method that I was introducing was bimap so, B-I-M-A-P. And if someone sees that in our codebase and is like, "Bimap, where is this coming from?" Well, this is one of those dry-monad result objects. And they go to the code, and they try and look it up in the docs, and they're just not going to find anything.

+ +

And I can imagine losing a lot of time to try and chase that down. There are ways to figure it out. There's the method in Ruby, which is a wonderful trick for chasing things down. Or if you grep the codebase, you'd find it. But I think I'm possibly over-indexed on worrying about that lost time, that moment. But I've lost that time so many times in my life where I'm like, I can't grep for this. I can't Google for this. And so I have so strongly moved in the direction of being like, everything should be grepable, everything should be googleable. Those are the two of the things that I believe about software. I think I believe a bunch of stuff.

+ +

STEPH: I think we have a full episode that talks about what we believe in software.

+ +

CHRIS: I believe we do.

+ +

STEPH: Cool. Thanks. Yeah, I have not heard of refinements. That sounds really interesting. I really like that bit about everything should be grepable, and everything should be googleable, googling everything. I kind of agree with that one. We live in a world where we're always doing bespoke things so that one feels a little bit harder that we're always going to be able to Google it. But then that encourages people to constantly publish the bespoke work that they're doing so then others can benefit from that work. But the grepable, I absolutely agree with that one. It's so frustrating where I see a method, but I cannot find its definition. And then having the ways to figure out where that method is defined to then find its definition is crucial.

+ +

CHRIS: Yeah, it's interesting. I definitely feel that way very strongly. And it's in such stark contrast to Rails. Rails is like, hey, don't worry. There's going to be a lot of methods. You don't need to worry about where they come from, or why they exist, or what they are, or what they do. Well, probably what they do. But all of the magic inflections on database tables,, and suddenly you have methods named after every column. That's both very magical and hard to grep for or impossible to grep for, but it also leaks the entire structure of your database into your application in a way that I've always felt a little bit complicated about. And so explicitness, grepability, those are things that I care about.

+ +

There's another one, delegates in Rails, that I sometimes pause around using especially when it's like delegates 19 methods to user prefix user. And so you end up with methods that are like username. And that's a delegation to the user object to get the name method off of it, but it creates the method user_name. And you're never going to be able to grep for that. And it saves like a little bit of code, definitely, but it saves this very obvious, very knowable code. So this one I actually shy away from using delegates in most cases, and I'll just write out the methods manually because sometimes I like to hear the clackety of my keyboard. There's a reason I have a clackety keyboard.

+ +

STEPH: You want to get your money's worth. You want to clackety as much as possible. Yeah, I'm also not a fan of delegates. This may be a lie, but I don't know that I've actually ever used it. I've worked with it, but I can't think of a time that I've implemented delegates. Maybe that's a lie, but I'm going to say it anyways because that feels true, at least in the last couple of years.

+ +

CHRIS: I feel like that could be true for the last couple of years. I would be surprised if you have never even added to a delegates line. Because that's the thing, you can just keep shoveling stuff into them as well. So I would put money on you having used it at some point and then just forgotten about it. But who knows, maybe not.

+ +

STEPH: This is where we play two truths and a lie and that one's my lie. [laughs] Yeah, that's also fair about adding to it because if that's already defined and it's easier to add to it, I don't know. Who knows what past Stephanie has done, probably some wild stuff.

+ +

CHRIS: It's unknowable at this point. It's lost to the sands of time. But looping back to the core thing of this refinement and the module, I think I'm leaning in the direction of doing that and unwinding my wrapping and wrapping layer thing. Because obviously, as I talked about...I think it was the previous episode or maybe two episodes ago. There was conceptual complexity to the additional wrapping layer. Even as I was fully in the context of working on that, I was still getting myself confused in either triple wrapping or then unwrapping too much or whatever. And these are the concerns with this type of code. So moving away from that feels better, having just a single layer of context wrapping around a given value.

+ +

And then the other thing it's actually just a lot less code, and it's less prone to error, I think. That's my hope. I have to look into exactly how refinements get used, but I noticed in a couple of places that sometimes we were wrapping with this local value object that gave us the bimap method, and sometimes we were forgetting to. And so, I could see that being a very subtle, easy way to introduce failures into the app that would be hard to catch just by looking at it.

+ +

So I think having a more global refinement...although I think that's sort of a contradiction, a global refinement because I think refinements are meant to be local. But anyway, I'm going to look into it because it's a much more concise code sample than what I have. Yeah, I'm going to poke at that a little bit. But it was an interesting exploration of some different things. And then it forced me to consider why am I so resistant to monkey patching at this point, especially in this particular case where I think it's okay-ish?

+ +

STEPH: That's a good question. Do you have any insights? I am also resistant to monkey patching. I feel that pain and also that timidness of diving into that space. But I'm curious, have you figured out any other reasons that you really prefer to avoid it?

+ +

CHRIS: I think this one falls into that sort of...what's the word? Like tribal knowledge of we've been burned by it in the past and therefore we build almost a...religious is too strong of a word but that sort of cultural belief. This is a thing that we do not do because of the bad things that we've experienced in the past. And there are a lot of things that fall into that experiential negative space.

+ +

So with monkey patching, things that I know we can run into is if I introduced this bimap method, but I introduce it subtly differently than the library will eventually, then they could eventually introduce it themselves. And suddenly, I have this fork of my code expects it to work this way, but you've now implemented it that way. I no longer can upgrade. This is a critical piece of infrastructure in my app. I've just painted myself into a corner by doing this. Whereas if I do this wrapping layer, that's my code. I own that. It's not going to be a problem in that same way.

+ +

There's also the subtlety, the grepability that sort of thing is a concern in my mind. Like, is this our code? Is this their code? Is this an engine? Being able to find code within a codebase, I think, is a critical thing. And so that's a part of the hesitation. I also know longer ago prototypes...I want to say Prototype JS was the name of the project, but it was one that was just like, yeah, JavaScript doesn't have enough stuff in the standard library. So we're just going to override everything and add all of these wonderful methods sort of in the way that Active Support does, which is an interesting comparison.

+ +

But the JavaScript community definitely moved away from Prototype. And now JavaScript is a language or the standard runtime that's available in most JavaScript engines. It has a lot of the methods, but there are conflicts, and stuff gets weird, and it's all complicated. But again, as I thought of it, Active Support is a complete contradiction to everything I'm saying. Active Support just adds whatever to anything, 2.days.ago. Why does the number 2 have a days method? Because it's great, that's why. But I'm just a walking contradiction, I guess.

+ +

STEPH: Everything you said really resonates with me. And I'm just trying to reason with myself like yes, Active Support uses a lot of this, a lot of metaprogramming, and adds everything it wants to. So why does that feel okay? And I wonder if it comes down to one is more almost like an agreed standard. It's built by a team, and it's maintained by a team, and then it's used by a large number of people, and then you get that feedback. Or maybe it's not even just a team, but it's a larger community versus if it's internal to your software team, maybe that doesn't feel like a big enough group or if it just needs...Rails is also documented. So maybe that's part of it, too, is if you are going to dive into that space, it's easy to discover, and it's well-documented as if you are building an open-source project that other people are going to use. Like, you designed for the intent of people to use this pattern that you've introduced, then perhaps that's when it starts to feel okay. ,

+ +

But the experiences I have had is where people basically will add some dynamic programming or monkey patch an existing feature. And then that's very hard to find and has surprising results, or it gets outdated. So I guess it comes down to who are you designing for? Are you designing for more of an open-source community, or you're at least designing for the people behind you that are going to be using this? Or is this a one-off adventure that you have chosen for yourself and future developers to discover? [chuckles]

+ +

CHRIS: Yeah, I think that's a good summary, although I'm open to the fact that I exist in a state of contradiction. I'm also fine with that, to be clear. [chuckles] But I think what you said is true, and I think there is subtlety and nuance and reasons that it's okay in one context and less okay in others. And that idea of just like, I don't know, this is one of those things that I got in my head that I've done the thinking a long time ago to decide this is a thing I don't do.

+ +

So now, in order to override that, I would have to do so much thinking. I would have to be like, all right, well, my brain tells me, no, but I'm going to go reread everything about monkey patching right now to convince myself that it's okay or to fully get the context and the subtlety and the nuance. And so sometimes we have to rely on that heuristic knowledge of monkey patching, nope, don't do that. That's not a thing, but other stuff is fine. And well, Active Support is fine because it's Rails. But it is interesting to observe contradictions and be like, huh, look at me go. All right. Well, moving on.

+ +

STEPH: It's our lizard brain that's saying, "Hey, there's danger here." [laughs]

+ +

CHRIS: Exactly.

+ +

STEPH: I rather like living in a world of contradictions, or at least I find it that I'm drawn to them. And maybe that's also one of the things that I really like about consulting is because then I join all these different teams, and I hear all these different opinions. So as I'm forming these opinions around something like tests are great, I really like tests, and then someone's like, "I really hate tests." I'm like, "Cool. Let's talk. I want to understand why you don't like this thing that I think is wonderful because then I'm really interested." So I find that I'm often really drawn to contradictions as I like hearing opinions that are very different than mine and finding out why people have a different opinion than mine.

+ +

CHRIS: Yeah, the world is full of contradictions. So it's, I think, at least a useful way to exist in the world, to be open to them and to enjoy exploring them. But yeah, I'll update in future weeks if I do end up going the refinements route. I'll let you know if anything interesting falls out of that.

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: So we made a recent improvement to our feature flag system, which I'm really excited about, that we have found a way to improve that workflow because it felt really great that we're...well, okay, I should say that with a caveat. It felt really great that we're using feature flags to ensure that the main branch is always in a deployable state. But it did not feel great around how tedious it was becoming to add all of the feature flags specifically because each time we're adding a feature flag, we're having to add a migration. So we're having to run a migration, add the feature flag column, and then we can interact with that feature flag. And that part's okay. It was more removing that feature flag once we're done with it, that that part was starting to feel tedious because then that's becoming a two-deploy process.

+ +

So one change is to remove the code that's relying on that feature flag. And then the second deploy was to actually drop that column because we wanted it to be safe to make sure that the code wasn't trying to reference a database column that didn't exist anymore, which is what happened at one point at first when we weren't doing the two-deploy process.

+ +

So the improvement that Chris White came up with is where we're now using a Postgres JSONB column. And it's here that we actually have a feature flag YAML file. And we can have the name of the feature flag. We have a description of the purpose of the feature flag. And we have an enabled property on there, so then we can turn it on and off. The benefit of this is now we don't have to do that two-deploy process. And we also don't have to run a migration for when we're adding a new feature flag. So we can add it to the feature flag file, we can load it in, and then we can set that property to say, "Yes, this is enabled," or "No, it's not." And that has just simplified our feature flag process.

+ +

One tricky bit that I believe the team ran into is around enabling this with Active Admin because Active Admin was just relying on those database columns to then turn something on or off. But then we've added some methods that work well with Active Admin that then say, "Read from here when you're checking to see if something is enabled," or "Look at this list to see which feature flags can be turned on and off." So it's been a really nice improvement, and everybody on the team seems to be in favor of the ways that we've improved this. So it's been really nice. So I wanted to come back and bring an update on how we've simplified our feature flag system.

+ +

CHRIS: That definitely sounds like a nice improvement, the ability to just more regularly iterate around that or taking away the pain, any pain associated with using feature flags. Because they are such a nice thing to have, but there's that overhead. Then you start to have that voice in your head that's like, do I really need a feature flag for this? Could I just sneak this one in? And we always regret that.

+ +

I had a similar thing this week where I wrote some code. I didn't quite write as many tests as I should have. And it was wildly broken, just like all of the connection points through everything were broken. But then it pushed me in an interesting direction where I was like, well, what I'm going to do is write an integrated test. It was basically an event coming in from a webhook that then enqueued a job, which did a thing, which then spit out an email. But it was broken at like three layers, and I was very embarrassed, if we're being honest. But, I don't know, I was just having a low energy afternoon, and I did not write the test, which I know I'm supposed to do.

+ +

So similarly, any pain that we can take out of these things that we're supposed to do, any way that we can pave the happy path, I'm all about those. I'm intrigued because I think we've talked about this before, but it sounds like you guys have a very home-grown feature flag system. Is that true?

+ +

STEPH: We do.

+ +

CHRIS: Is there something about it that makes it unique to your situation, or was it just like that's what happened? Someone early on was like, "We need feature flags. I can just do the simplest thing that works," and then that's where you're at now or?

+ +

STEPH: You're asking a very good question. And I'm trying to recall what led us to the state that we're in because I feel like we had this same discussion several episodes back when we were introducing the home-grown feature flag system. And I was like, there are reasons, but I didn't really dive into those reasons because it felt very custom to the application. But now I've forgotten what those reasons were. So I think you ask a great question where it'd be worth revisiting to confirm that yes, there's a reason for this home-grown version versus using something like Flipper.

+ +

CHRIS: I'm glad I'm at least consistent over time in the questions that I ask and the heuristics that I have. This does feel like one of those things. It's not quite like crypto where I'd be like, we can never write our own crypto. But a feature flag system, I would be really intrigued if there are things that they are just workflows or functionality that you really need that are not supported by any of the existing solutions that are out there. I think audit trails is an interesting one. I think Flipper has a hosted product at this point that does that, but the local version wouldn't necessarily. So maybe that's a thing that you want to get. Again, I'd just be really interested. It sounds like the current state of the world that you have is enabled or disabled; just broadly, that's it. Those are the two states for any given flag. Is that true?

+ +

STEPH: It is. There's nothing complex with the flags in that nature. And then we use naming to indicate if something is more for beta, so if it's a change that we're making to the codebase, but it's a feature flag that we plan on removing, versus maybe it's a feature flag for enterprise customers.

+ +

CHRIS: Oh, interesting. I wouldn't think of using a feature flag in that context where it's going to be like a persistent, long-lived; this is conditional logic around some state or some property of the viewer. I think of feature flags as a way to gate code conditionally based on a point in time. And the reason I asked about the enabled-disabled basically like the Boolean state for your flags is when I've worked with feature flags in the past, I've liked having the ability to say, for this user or these users, or this group of users, which we've named this is our beta list…and it's the ten people that just really love the product and are happy to bump into some rough edges. And so we'll put things on for them first or even like percentages, so roll it out to 10% and then 50% and so on. And I think the larger an application and user base gets, the more that sort of thing starts to feel right.

+ +

STEPH: Yeah, we certainly have some complexity around where each customer can really specify which features that they want. And then the features also differ a bit for each customer. So we are in a world where we're pretty customized or configurable for different customers. And whether that's something that we could simplify, that would certainly be a good question or something to pursue.

+ +

But part of this also feels like our decision may have been based around what the system was already doing, and we're looking for ways to make slow improvements versus trying to redesign the whole thing. Because initially, the way we were customizing all of these different features for customers was in a YAML file. And that part was painful because then, anytime we wanted to make a change, it required a deploy. So the introduction of feature flags is really to get away from having to deploy to then make a small change like that.

+ +

But now that we're in the space that we can easily configure that change and do that on the fly and not have to issue a deploy, I think we're now in a good space to reassess. And the team may have some really good answers. Perhaps I'm just not recalling as to why we've chosen the more home-grown feature flags. But yeah, I'll visit that topic and report back. Because I've been coasting along on our new system and enjoying it, but you're asking some really good questions.

+ +

CHRIS: I mean, as an aside, if you're coasting along and really enjoying it, then maybe you don't need to ask any questions. It's still interesting. I would be intrigued to know. But if it's not causing you any pain, then you probably shouldn't change it. Because frankly, changing out the feature flag system is going to be non-trivial, I'm pretty sure. You could feature flag the feature flag system, and then you can transition from one to the other. You need a third feature flag system for that. But anyway, I digress. [chuckles]

+ +

STEPH: You referenced crypto earlier. So I think I like the feature flag, the feature flag system. We should have some crypto flags in there somewhere. I think that's a thing too. But I think the main goal if I'm looking into changing it would be, circling back to what we were talking about earlier, is discoverability, so having a home-grown feature flag system. How easy is it for…if nobody was around on the team and there was someone new working with it, how easy would it be for them to turn something on or off? And if that's easy, then that's great. Then I think we've got a great home-grown system. If that's challenging, then I definitely think it's worth reassessing.

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: One of the things that's been interesting working lately in the app that I'm building is thinking about testing. We have a number of interactions with third-party services. Frankly, a lot of the app is that at this point. We have a handful of different external data providers systems that we're interacting with, webhooks and flows and things like that. And so we had to make that decision that you always have to make in these sorts of situations which is, how are we going to test this?

+ +

And there's a wonderful blog post on the thoughtbot blog called Faking External Services in Tests with Adapters. It's by the one and only German Velasco. And it is a beautiful summary of the different approaches that you can take, but it really dials into one, which is the adapter pattern. There's also a weekly iteration episode on Upcase with Joël Quenneville, which discusses a little bit more of an exploration of the different options. There are sort of a handful of different options that we can consider your whereas the blog post by German talks specifically about the adapters approach.

+ +

But to talk about them briefly, there's one where you can go all the way outside your app, spin up a fake service. Typically, we would do this with Capybara Discoball, which is a wonderfully named project. But it allows you to spin up a little Sinatra app type thing such that your web application is still making quote, unquote "real HTTP requests." This external service is going to catch that and respond with whatever canned data or structured responses that you want.

+ +

But you still have the ability in that to, say, tell it to create data beforehand or be in a certain state or respond with certain data or have any stateful persistence. So if you create a record in that external system, and then later you query for it, that system can do that. But it has the complexities of now, your test suite is running different systems. And do you have thread-safety or all that kind of stuff? So that's a particularly complex end of the spectrum. At the lowest end would be stubbing and mocking. You just take whatever external clients you have, and you're mocking the API calls in them. That's the lowest end. And that's the one, especially for feature specs, those I try and avoid. Then there's a middle ground of like WebMock or VCR, those sort of things where you're saying whenever you see an HTTP request that looks like this, respond in this way. You record the cassettes, all that kind of stuff.

+ +

And then there's the one that we've settled on, which is the adapters. So the client that we've introduced in our local codebase to interact with any of these third-party systems internally has a class attribute, a cattr_accessor in the Rails parlance, I believe. And that allows us to switch out the backend. And so we have a real HTTP backend, and that's the one that actually runs in production and a test in-memory backend. And that in-memory backend can implement whatever logic. We're ending up with one of them almost recreating this external service, sort of re-coding some of their inconsistencies or oddities but also features and whatnot.

+ +

But it feels like it has struck just the right balance, and it allows our feature specs to be very rich, very real. We start up the world, and we say, "Hey, external service be in this state." And then I'm going to go visit the page. I'm going to see the data. But we are almost making real HTTP requests. It's very close. It's always an interesting choice to make here. I'm very happy with the one that we've made, but it's still not perfect. There are always going to be trade-offs between the different options here. But it's always interesting revisiting this and being like, which one am I going to choose today?

+ +

STEPH: I feel like my natural progression when testing external services; I always start with WebMock, and then I progress to using adapters. And then from there, I go to actually replacing the HTTP service that is receiving and then returning a response, like you mentioned to Capybara Discoball earlier. So I can certainly see what you like about the adapter pattern. You mentioned that you're coding some of the inconsistencies. That feels very real. I'm curious if you have an example of how you've had to manage that recently.

+ +

CHRIS: A specific example would be the external API responds with certain error codes or error structures. So it's an error. It has a status of a number and then a reason, or sometimes instead of a key that is reason; it’s the message. So it's like, oh, okay, I see that in this endpoint, you respond with reason, and then this endpoint you respond with message. So now, do I encode that into my fake? I guess I do. So my adapter now implements things like that. There are cases where it's inconsistency where I'm like, well, this is the way they behave. So I would like our test suite to exist in the context of that because then our app is getting exercise in a real way.

+ +

But in some cases, it's like little bits of logic validation that an external system might do if that's an important part of the flow. The app that we're building has a lot of forms and a lot of data validation and things like that. And so, we want to make sure that we have robust handling around that robust messaging to the user so that it's very clear what they need to do and how they need to respond to things. And so putting in little bits of that like, oh, that's how you format a phone number, okay, cool. Our fake will also format phone numbers in that way, things like that.

+ +

STEPH: Every time the topic of testing external services comes up, I really, really want VCR to be the answer. I really like the idea of being able to validate that...because you'd mentioned that we're programming the expected return from this other service. And it's very easy to get out of sync with those actual responses. And then we don't really have a great way to stay up to date other than we wait for production or staging environment to fail. And then we realize something has changed, and we have to go and update either our mock or our adapter. And maybe that doesn't happen often if you're working with an external service that is very good about broadcasting when they have a breaking change.

+ +

But if you're working with a less stable endpoint, then I always want VCR to really work. But it's just one of those areas where I'm like, yes, that's the thing that I want. I want this idea where I can rerun my tests in a way that they actually hit that service and record the response. But then I have felt pain [chuckles] from working with VCR and how it's configured, and how people have used it. It's one of those where I don't blame the library. I like the library. But the way people have implemented it and test I have felt a lot of pain from that.

+ +

CHRIS: Yeah, I definitely agree with that. It feels like it's nice if you can push the mocking all the way out to that layer. Because like right now, our codebase has code in it that is subtly changing the behavior for a test, and I don't like that. It's only the swapping out of the adapter, so it's a very minimal thing. And we try and push all logic away from that such that the test adapter is as similar as possible to the real production situation. But it's enough difference that I agree I would like if VCR would just like, I catch the HTTP requests, and I respond with the same thing and sometimes we can pass through.

+ +

I do think one of the fundamental limitations, or at least very hard to get right things, would be sequential requests. So I post to this endpoint in the external service, which creates some data. And then later, when I make a GET request to their endpoint, I should get back that data that I just created. That's, I guess, doable because you can have sequential requests, have cassettes that are first this request, then that request, then that request. And it knows that, like scope them to a given spec. But that feels extra difficult. And it does, again to your comment, the maintainers of that project do a wonderful job, but it's a really hard target to hit.

+ +

STEPH: Well, and one of the other hard requirements with using a tool like VCR is then that external service really needs that sandbox staging environment that you can use. So that way you can create this data, you can rerun your test. So they're actually going to hit this real environment. They're going to create this data and that not have any harmful effects. And then you can record fetching that data. So it requires a lot of pieces to fall into place for it to work well. But then I was just thinking as you're talking about adapters, I'm like, yeah, I love the adapter pattern. I've really enjoyed that one for testing as well. But then I immediately start to think, oh, well, what happens when it gets out of sync, and how do we know that it got out of sync? And I don't have a great answer to that.

+ +

CHRIS: Production blows up, obviously.

+ +

STEPH: Production blows up, and then we go update our adapter. That's very calm. [laughs]

+ +

CHRIS: It would be great if CI could more proactively catch that or...yeah, I agree. I would love if VCR would work because that facet of it is so attractive. But [chuckles] I've never gotten to walk exclusively the happy path with VCR. So here we are. This is a classic case of here's four options as to how we can think about this hard and important thing that we do in our codebases, and they all have trade-offs much like everything else in software.

+ +

STEPH: I'm going to add this to my developer bucket list to live in a world where I can easily validate if an external API has changed or not and then also have tests that know when something has broken before production does.

+ +

CHRIS: Ooph, dare to dream. I like it.

+ +

STEPH: I'm a dreamer.

+ +

CHRIS: I want to live in that world. Well, with that wonderful dream to take us out, should we wrap up?

+ +

STEPH: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + + On this episode, Chris talks about testing external services and dissects a tweet on refinements for Result. Steph talks about thoughbot's recent improvement to their feature flag system.

+ +

Links:

+ + + +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new with you?

+ +

STEPH: Hey, Chris. Well, today is Summit Day at thoughtbot, and it's the day where all the bots gather, and we hang out, and we chat, and we play games. And it's a lot of fun. We're actually taking more of a respite this year just because life has been taxing. And so we decided to give people more of the day off. So we still had some fun events, but most of it is everybody gets a chill day. Do something that brings you joy is the theme of the day.

+ +

But we had Lightning Talks, which is my favorite thing that we do on Summit Day because I realize that I just work with the coolest people, and they have such interesting things to talk about. And we had such a variety of topics. So one of them, Alex Chen taught us acronyms in K-pop. And Sam Kapila, our resident foodie, taught us about a variety of spices. And one of my favorite talks was by Akshith Yellapragada, and it's the top 10 best limo entrances by The Bachelor, and it was phenomenal. And I really want to share some stuff that I learned with you.

+ +

CHRIS: The Bachelor like the TV show?

+ +

STEPH: Yeah, like the TV show. Are you familiar with it? Have you seen it before?

+ +

CHRIS: I am familiar with it. I know it exists. I know that there's a spinoff, The Bachelorette. And I believe we have now exhausted my information on the matter.

+ +

STEPH: [laughs] That's fair. For anyone that hasn't seen the show, the show revolves around a single person. For the bachelor, it's a single bachelor who dates a number of people over several weeks, and then they narrow down the people. There are elimination rounds, and the whole goal is for them to find their true love. So each week, someone is eliminated, and I think the show ends with a marriage proposal. So it's a wild show. It's something. [chuckles]

+ +

And in Akshith's talk, I learned some really fun terminology. The first one is the Crown, and this is actually an important building block because we're going to get to the rest of the terminology that uses this word, so we got to start here. So the first one is the Crown, and this is the person that everyone's competing for. So they're the star of the show. They're the one that everybody is hoping to fall in love with or will fall in love with them so they get a marriage proposal.

+ +

So then the other stuff that I've learned is all about the entrance because again, we're talking about the top 10 best entrances. And one of them is the sidecar entrance. So this is where the player, because yes, this is totally a game, has someone assist them in meeting the crown. So it could be like a family member, maybe it's like your grandma.

+ +

And then there's TOT, T-O-T, which is short for Trick Or Treat. And this person exits the limo wearing a costume. So it's someone wearing a shark costume. There was someone wearing a sloth costume where they really dedicated to the role, and they climbed a tree and hung from a branch. I don't know for how long but for long enough to really vibe with the role.

+ +

And then there's the Kringle, and this person brings a prop or a present to the Crown. And there's the Grandy, and this player arrives in something other than a limo. So the example that Akshith provided is someone arrived in a motorized cupcake.

+ +

CHRIS: Was the cupcake edible?

+ +

STEPH: I don't think so, fair question. [laughs]

+ +

CHRIS: So really just like a go-kart that looked like a cupcake, not really a motorized cupcake, if I'm going to meet pedantic about the thing, [chuckles] which I think is my job.

+ +

STEPH: Yes, it is a motorized non-edible cupcake, but that seems like something a next player should do. They should really up the game, and they should bring an edible motorized cupcake.

+ +

CHRIS: Yeah, because you get the visual novelty, but then you layer on top of it that it's actually something that you can now eat, and it's a double win.

+ +

STEPH: Ooh, and then you're a Grandy, and you're a Kringle because you arrived in something other than a limo, and it's a present.

+ +

CHRIS: I love how you have so deeply internalized this now that you're like, ooh, okay. I can remix here. I'm going to bring together the pieces. Yeah, all right. Yeah, this all makes sense.

+ +

STEPH: Yeah, it was a lot of fun. Those are most of my notes for today. I have some tech stuff too, but this felt like the most important thing to start the show with.

+ +

CHRIS: We use the phrase tech talk and nonsense to describe the show often, but I think nonsense and tech talk is the correct orientation.

+ +

STEPH: [chuckles]

+ +

CHRIS: Correct in terms of importance and chronological order, and whatnot. But yeah.

+ +

STEPH: I love that we start with a bit of nonsense. So I do have some tech stuff. But first, before I share any of that, what's going on in your world?

+ +

CHRIS: I'm sure there's plenty of nonsense in my world, but at the top of my list is some tech stuff. So someone on Twitter, Adam Lassek, reached out and he suggested related to the conversation and the back and forth that I've been having with myself around some of the data structures within the app that I'm building…So I've talked about the dry-monads result object, and there's this success and failure. And I wanted to introduce this new method called bimap, but I wanted to do it in a reasonable way. So I wrapped, and then I wrapped, and I wrapped things.

+ +

As an aside, former colleague and friend of the show, Joel Oliveira, sent a wonderful tweet which was a reference to the SNL video where they make a taco and put it inside of a pizza and put it inside of a bag. And that was his joke about it, which I really liked. That was an excellent reference. But in this case, Adam Lassek reached out and suggested if I'm that squeamish about monkey patching, which I am, have I considered refinements? And so he sent an image of a code sample, which is so kind of him to send that much detail over, but it was interesting because I know of refinements in Ruby. I know of that as an alternative to monkey patching, a more refined way, but a safer way, a more controlled way to alter code, but I've not actually used them.

+ +

STEPH: I'm not familiar with refinements. What is that?

+ +

CHRIS: Refinements are a way...so similar to monkey patching, where you say like, I'm going to reopen this class or this module and define a new method or redefine a method or do something like that, a refinement is a way to do that in a scoped manner. So I'll be honest, I'm not super familiar with them. I think I came into Ruby at a time where the community was moving away from monkey patching. And the dogmatic swing of the pendulum was like, that's a bad thing to do. And so even the refinements were introduced, as far as I understand it, to be a more controlled way to do it. So it's not just like, hey, cool. This module is redefined now in your app in a magical way that's really hard to figure out and hard for folks to debug refinements. You have to explicitly opt into within a certain lexical scope.

+ +

I'll be honest; I know that at the headline level. I don't actually know the ramifications or where and when you can use them and how you can. But I know that that was the idea is refinements are a way to do monkey patching but in a more controlled, more understandable manner, and so the code sample that Adam shared does that. And it's very interesting. As I'm looking at it, I'm like, okay, that's cool because I think it'll be a little bit safer.

+ +

But at the end of the day, my concern wasn't safety in this case because I was introducing a method that would be new, that would be additive to the API of this module that I'm working with, and so that I think of as a relatively safe operation. My hesitation was more around how does someone figure it out if they're working with this? And particularly, the name of the method that I was introducing was bimap so, B-I-M-A-P. And if someone sees that in our codebase and is like, "Bimap, where is this coming from?" Well, this is one of those dry-monad result objects. And they go to the code, and they try and look it up in the docs, and they're just not going to find anything.

+ +

And I can imagine losing a lot of time to try and chase that down. There are ways to figure it out. There's the method in Ruby, which is a wonderful trick for chasing things down. Or if you grep the codebase, you'd find it. But I think I'm possibly over-indexed on worrying about that lost time, that moment. But I've lost that time so many times in my life where I'm like, I can't grep for this. I can't Google for this. And so I have so strongly moved in the direction of being like, everything should be grepable, everything should be googleable. Those are the two of the things that I believe about software. I think I believe a bunch of stuff.

+ +

STEPH: I think we have a full episode that talks about what we believe in software.

+ +

CHRIS: I believe we do.

+ +

STEPH: Cool. Thanks. Yeah, I have not heard of refinements. That sounds really interesting. I really like that bit about everything should be grepable, and everything should be googleable, googling everything. I kind of agree with that one. We live in a world where we're always doing bespoke things so that one feels a little bit harder that we're always going to be able to Google it. But then that encourages people to constantly publish the bespoke work that they're doing so then others can benefit from that work. But the grepable, I absolutely agree with that one. It's so frustrating where I see a method, but I cannot find its definition. And then having the ways to figure out where that method is defined to then find its definition is crucial.

+ +

CHRIS: Yeah, it's interesting. I definitely feel that way very strongly. And it's in such stark contrast to Rails. Rails is like, hey, don't worry. There's going to be a lot of methods. You don't need to worry about where they come from, or why they exist, or what they are, or what they do. Well, probably what they do. But all of the magic inflections on database tables,, and suddenly you have methods named after every column. That's both very magical and hard to grep for or impossible to grep for, but it also leaks the entire structure of your database into your application in a way that I've always felt a little bit complicated about. And so explicitness, grepability, those are things that I care about.

+ +

There's another one, delegates in Rails, that I sometimes pause around using especially when it's like delegates 19 methods to user prefix user. And so you end up with methods that are like username. And that's a delegation to the user object to get the name method off of it, but it creates the method user_name. And you're never going to be able to grep for that. And it saves like a little bit of code, definitely, but it saves this very obvious, very knowable code. So this one I actually shy away from using delegates in most cases, and I'll just write out the methods manually because sometimes I like to hear the clackety of my keyboard. There's a reason I have a clackety keyboard.

+ +

STEPH: You want to get your money's worth. You want to clackety as much as possible. Yeah, I'm also not a fan of delegates. This may be a lie, but I don't know that I've actually ever used it. I've worked with it, but I can't think of a time that I've implemented delegates. Maybe that's a lie, but I'm going to say it anyways because that feels true, at least in the last couple of years.

+ +

CHRIS: I feel like that could be true for the last couple of years. I would be surprised if you have never even added to a delegates line. Because that's the thing, you can just keep shoveling stuff into them as well. So I would put money on you having used it at some point and then just forgotten about it. But who knows, maybe not.

+ +

STEPH: This is where we play two truths and a lie and that one's my lie. [laughs] Yeah, that's also fair about adding to it because if that's already defined and it's easier to add to it, I don't know. Who knows what past Stephanie has done, probably some wild stuff.

+ +

CHRIS: It's unknowable at this point. It's lost to the sands of time. But looping back to the core thing of this refinement and the module, I think I'm leaning in the direction of doing that and unwinding my wrapping and wrapping layer thing. Because obviously, as I talked about...I think it was the previous episode or maybe two episodes ago. There was conceptual complexity to the additional wrapping layer. Even as I was fully in the context of working on that, I was still getting myself confused in either triple wrapping or then unwrapping too much or whatever. And these are the concerns with this type of code. So moving away from that feels better, having just a single layer of context wrapping around a given value.

+ +

And then the other thing it's actually just a lot less code, and it's less prone to error, I think. That's my hope. I have to look into exactly how refinements get used, but I noticed in a couple of places that sometimes we were wrapping with this local value object that gave us the bimap method, and sometimes we were forgetting to. And so, I could see that being a very subtle, easy way to introduce failures into the app that would be hard to catch just by looking at it.

+ +

So I think having a more global refinement...although I think that's sort of a contradiction, a global refinement because I think refinements are meant to be local. But anyway, I'm going to look into it because it's a much more concise code sample than what I have. Yeah, I'm going to poke at that a little bit. But it was an interesting exploration of some different things. And then it forced me to consider why am I so resistant to monkey patching at this point, especially in this particular case where I think it's okay-ish?

+ +

STEPH: That's a good question. Do you have any insights? I am also resistant to monkey patching. I feel that pain and also that timidness of diving into that space. But I'm curious, have you figured out any other reasons that you really prefer to avoid it?

+ +

CHRIS: I think this one falls into that sort of...what's the word? Like tribal knowledge of we've been burned by it in the past and therefore we build almost a...religious is too strong of a word but that sort of cultural belief. This is a thing that we do not do because of the bad things that we've experienced in the past. And there are a lot of things that fall into that experiential negative space.

+ +

So with monkey patching, things that I know we can run into is if I introduced this bimap method, but I introduce it subtly differently than the library will eventually, then they could eventually introduce it themselves. And suddenly, I have this fork of my code expects it to work this way, but you've now implemented it that way. I no longer can upgrade. This is a critical piece of infrastructure in my app. I've just painted myself into a corner by doing this. Whereas if I do this wrapping layer, that's my code. I own that. It's not going to be a problem in that same way.

+ +

There's also the subtlety, the grepability that sort of thing is a concern in my mind. Like, is this our code? Is this their code? Is this an engine? Being able to find code within a codebase, I think, is a critical thing. And so that's a part of the hesitation. I also know longer ago prototypes...I want to say Prototype JS was the name of the project, but it was one that was just like, yeah, JavaScript doesn't have enough stuff in the standard library. So we're just going to override everything and add all of these wonderful methods sort of in the way that Active Support does, which is an interesting comparison.

+ +

But the JavaScript community definitely moved away from Prototype. And now JavaScript is a language or the standard runtime that's available in most JavaScript engines. It has a lot of the methods, but there are conflicts, and stuff gets weird, and it's all complicated. But again, as I thought of it, Active Support is a complete contradiction to everything I'm saying. Active Support just adds whatever to anything, 2.days.ago. Why does the number 2 have a days method? Because it's great, that's why. But I'm just a walking contradiction, I guess.

+ +

STEPH: Everything you said really resonates with me. And I'm just trying to reason with myself like yes, Active Support uses a lot of this, a lot of metaprogramming, and adds everything it wants to. So why does that feel okay? And I wonder if it comes down to one is more almost like an agreed standard. It's built by a team, and it's maintained by a team, and then it's used by a large number of people, and then you get that feedback. Or maybe it's not even just a team, but it's a larger community versus if it's internal to your software team, maybe that doesn't feel like a big enough group or if it just needs...Rails is also documented. So maybe that's part of it, too, is if you are going to dive into that space, it's easy to discover, and it's well-documented as if you are building an open-source project that other people are going to use. Like, you designed for the intent of people to use this pattern that you've introduced, then perhaps that's when it starts to feel okay. ,

+ +

But the experiences I have had is where people basically will add some dynamic programming or monkey patch an existing feature. And then that's very hard to find and has surprising results, or it gets outdated. So I guess it comes down to who are you designing for? Are you designing for more of an open-source community, or you're at least designing for the people behind you that are going to be using this? Or is this a one-off adventure that you have chosen for yourself and future developers to discover? [chuckles]

+ +

CHRIS: Yeah, I think that's a good summary, although I'm open to the fact that I exist in a state of contradiction. I'm also fine with that, to be clear. [chuckles] But I think what you said is true, and I think there is subtlety and nuance and reasons that it's okay in one context and less okay in others. And that idea of just like, I don't know, this is one of those things that I got in my head that I've done the thinking a long time ago to decide this is a thing I don't do.

+ +

So now, in order to override that, I would have to do so much thinking. I would have to be like, all right, well, my brain tells me, no, but I'm going to go reread everything about monkey patching right now to convince myself that it's okay or to fully get the context and the subtlety and the nuance. And so sometimes we have to rely on that heuristic knowledge of monkey patching, nope, don't do that. That's not a thing, but other stuff is fine. And well, Active Support is fine because it's Rails. But it is interesting to observe contradictions and be like, huh, look at me go. All right. Well, moving on.

+ +

STEPH: It's our lizard brain that's saying, "Hey, there's danger here." [laughs]

+ +

CHRIS: Exactly.

+ +

STEPH: I rather like living in a world of contradictions, or at least I find it that I'm drawn to them. And maybe that's also one of the things that I really like about consulting is because then I join all these different teams, and I hear all these different opinions. So as I'm forming these opinions around something like tests are great, I really like tests, and then someone's like, "I really hate tests." I'm like, "Cool. Let's talk. I want to understand why you don't like this thing that I think is wonderful because then I'm really interested." So I find that I'm often really drawn to contradictions as I like hearing opinions that are very different than mine and finding out why people have a different opinion than mine.

+ +

CHRIS: Yeah, the world is full of contradictions. So it's, I think, at least a useful way to exist in the world, to be open to them and to enjoy exploring them. But yeah, I'll update in future weeks if I do end up going the refinements route. I'll let you know if anything interesting falls out of that.

+ +

And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open source culture in an accessible and documented API.

+ +

With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city

+ +

The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby.

+ +

STEPH: So we made a recent improvement to our feature flag system, which I'm really excited about, that we have found a way to improve that workflow because it felt really great that we're...well, okay, I should say that with a caveat. It felt really great that we're using feature flags to ensure that the main branch is always in a deployable state. But it did not feel great around how tedious it was becoming to add all of the feature flags specifically because each time we're adding a feature flag, we're having to add a migration. So we're having to run a migration, add the feature flag column, and then we can interact with that feature flag. And that part's okay. It was more removing that feature flag once we're done with it, that that part was starting to feel tedious because then that's becoming a two-deploy process.

+ +

So one change is to remove the code that's relying on that feature flag. And then the second deploy was to actually drop that column because we wanted it to be safe to make sure that the code wasn't trying to reference a database column that didn't exist anymore, which is what happened at one point at first when we weren't doing the two-deploy process.

+ +

So the improvement that Chris White came up with is where we're now using a Postgres JSONB column. And it's here that we actually have a feature flag YAML file. And we can have the name of the feature flag. We have a description of the purpose of the feature flag. And we have an enabled property on there, so then we can turn it on and off. The benefit of this is now we don't have to do that two-deploy process. And we also don't have to run a migration for when we're adding a new feature flag. So we can add it to the feature flag file, we can load it in, and then we can set that property to say, "Yes, this is enabled," or "No, it's not." And that has just simplified our feature flag process.

+ +

One tricky bit that I believe the team ran into is around enabling this with Active Admin because Active Admin was just relying on those database columns to then turn something on or off. But then we've added some methods that work well with Active Admin that then say, "Read from here when you're checking to see if something is enabled," or "Look at this list to see which feature flags can be turned on and off." So it's been a really nice improvement, and everybody on the team seems to be in favor of the ways that we've improved this. So it's been really nice. So I wanted to come back and bring an update on how we've simplified our feature flag system.

+ +

CHRIS: That definitely sounds like a nice improvement, the ability to just more regularly iterate around that or taking away the pain, any pain associated with using feature flags. Because they are such a nice thing to have, but there's that overhead. Then you start to have that voice in your head that's like, do I really need a feature flag for this? Could I just sneak this one in? And we always regret that.

+ +

I had a similar thing this week where I wrote some code. I didn't quite write as many tests as I should have. And it was wildly broken, just like all of the connection points through everything were broken. But then it pushed me in an interesting direction where I was like, well, what I'm going to do is write an integrated test. It was basically an event coming in from a webhook that then enqueued a job, which did a thing, which then spit out an email. But it was broken at like three layers, and I was very embarrassed, if we're being honest. But, I don't know, I was just having a low energy afternoon, and I did not write the test, which I know I'm supposed to do.

+ +

So similarly, any pain that we can take out of these things that we're supposed to do, any way that we can pave the happy path, I'm all about those. I'm intrigued because I think we've talked about this before, but it sounds like you guys have a very home-grown feature flag system. Is that true?

+ +

STEPH: We do.

+ +

CHRIS: Is there something about it that makes it unique to your situation, or was it just like that's what happened? Someone early on was like, "We need feature flags. I can just do the simplest thing that works," and then that's where you're at now or?

+ +

STEPH: You're asking a very good question. And I'm trying to recall what led us to the state that we're in because I feel like we had this same discussion several episodes back when we were introducing the home-grown feature flag system. And I was like, there are reasons, but I didn't really dive into those reasons because it felt very custom to the application. But now I've forgotten what those reasons were. So I think you ask a great question where it'd be worth revisiting to confirm that yes, there's a reason for this home-grown version versus using something like Flipper.

+ +

CHRIS: I'm glad I'm at least consistent over time in the questions that I ask and the heuristics that I have. This does feel like one of those things. It's not quite like crypto where I'd be like, we can never write our own crypto. But a feature flag system, I would be really intrigued if there are things that they are just workflows or functionality that you really need that are not supported by any of the existing solutions that are out there. I think audit trails is an interesting one. I think Flipper has a hosted product at this point that does that, but the local version wouldn't necessarily. So maybe that's a thing that you want to get. Again, I'd just be really interested. It sounds like the current state of the world that you have is enabled or disabled; just broadly, that's it. Those are the two states for any given flag. Is that true?

+ +

STEPH: It is. There's nothing complex with the flags in that nature. And then we use naming to indicate if something is more for beta, so if it's a change that we're making to the codebase, but it's a feature flag that we plan on removing, versus maybe it's a feature flag for enterprise customers.

+ +

CHRIS: Oh, interesting. I wouldn't think of using a feature flag in that context where it's going to be like a persistent, long-lived; this is conditional logic around some state or some property of the viewer. I think of feature flags as a way to gate code conditionally based on a point in time. And the reason I asked about the enabled-disabled basically like the Boolean state for your flags is when I've worked with feature flags in the past, I've liked having the ability to say, for this user or these users, or this group of users, which we've named this is our beta list…and it's the ten people that just really love the product and are happy to bump into some rough edges. And so we'll put things on for them first or even like percentages, so roll it out to 10% and then 50% and so on. And I think the larger an application and user base gets, the more that sort of thing starts to feel right.

+ +

STEPH: Yeah, we certainly have some complexity around where each customer can really specify which features that they want. And then the features also differ a bit for each customer. So we are in a world where we're pretty customized or configurable for different customers. And whether that's something that we could simplify, that would certainly be a good question or something to pursue.

+ +

But part of this also feels like our decision may have been based around what the system was already doing, and we're looking for ways to make slow improvements versus trying to redesign the whole thing. Because initially, the way we were customizing all of these different features for customers was in a YAML file. And that part was painful because then, anytime we wanted to make a change, it required a deploy. So the introduction of feature flags is really to get away from having to deploy to then make a small change like that.

+ +

But now that we're in the space that we can easily configure that change and do that on the fly and not have to issue a deploy, I think we're now in a good space to reassess. And the team may have some really good answers. Perhaps I'm just not recalling as to why we've chosen the more home-grown feature flags. But yeah, I'll visit that topic and report back. Because I've been coasting along on our new system and enjoying it, but you're asking some really good questions.

+ +

CHRIS: I mean, as an aside, if you're coasting along and really enjoying it, then maybe you don't need to ask any questions. It's still interesting. I would be intrigued to know. But if it's not causing you any pain, then you probably shouldn't change it. Because frankly, changing out the feature flag system is going to be non-trivial, I'm pretty sure. You could feature flag the feature flag system, and then you can transition from one to the other. You need a third feature flag system for that. But anyway, I digress. [chuckles]

+ +

STEPH: You referenced crypto earlier. So I think I like the feature flag, the feature flag system. We should have some crypto flags in there somewhere. I think that's a thing too. But I think the main goal if I'm looking into changing it would be, circling back to what we were talking about earlier, is discoverability, so having a home-grown feature flag system. How easy is it for…if nobody was around on the team and there was someone new working with it, how easy would it be for them to turn something on or off? And if that's easy, then that's great. Then I think we've got a great home-grown system. If that's challenging, then I definitely think it's worth reassessing.

+ +

And now a quick break to hear from today's sponsor, Scout APM.

+ +

Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more.

+ +

Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform.

+ +

See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed.

+ +

CHRIS: One of the things that's been interesting working lately in the app that I'm building is thinking about testing. We have a number of interactions with third-party services. Frankly, a lot of the app is that at this point. We have a handful of different external data providers systems that we're interacting with, webhooks and flows and things like that. And so we had to make that decision that you always have to make in these sorts of situations which is, how are we going to test this?

+ +

And there's a wonderful blog post on the thoughtbot blog called Faking External Services in Tests with Adapters. It's by the one and only German Velasco. And it is a beautiful summary of the different approaches that you can take, but it really dials into one, which is the adapter pattern. There's also a weekly iteration episode on Upcase with Joël Quenneville, which discusses a little bit more of an exploration of the different options. There are sort of a handful of different options that we can consider your whereas the blog post by German talks specifically about the adapters approach.

+ +

But to talk about them briefly, there's one where you can go all the way outside your app, spin up a fake service. Typically, we would do this with Capybara Discoball, which is a wonderfully named project. But it allows you to spin up a little Sinatra app type thing such that your web application is still making quote, unquote "real HTTP requests." This external service is going to catch that and respond with whatever canned data or structured responses that you want.

+ +

But you still have the ability in that to, say, tell it to create data beforehand or be in a certain state or respond with certain data or have any stateful persistence. So if you create a record in that external system, and then later you query for it, that system can do that. But it has the complexities of now, your test suite is running different systems. And do you have thread-safety or all that kind of stuff? So that's a particularly complex end of the spectrum. At the lowest end would be stubbing and mocking. You just take whatever external clients you have, and you're mocking the API calls in them. That's the lowest end. And that's the one, especially for feature specs, those I try and avoid. Then there's a middle ground of like WebMock or VCR, those sort of things where you're saying whenever you see an HTTP request that looks like this, respond in this way. You record the cassettes, all that kind of stuff.

+ +

And then there's the one that we've settled on, which is the adapters. So the client that we've introduced in our local codebase to interact with any of these third-party systems internally has a class attribute, a cattr_accessor in the Rails parlance, I believe. And that allows us to switch out the backend. And so we have a real HTTP backend, and that's the one that actually runs in production and a test in-memory backend. And that in-memory backend can implement whatever logic. We're ending up with one of them almost recreating this external service, sort of re-coding some of their inconsistencies or oddities but also features and whatnot.

+ +

But it feels like it has struck just the right balance, and it allows our feature specs to be very rich, very real. We start up the world, and we say, "Hey, external service be in this state." And then I'm going to go visit the page. I'm going to see the data. But we are almost making real HTTP requests. It's very close. It's always an interesting choice to make here. I'm very happy with the one that we've made, but it's still not perfect. There are always going to be trade-offs between the different options here. But it's always interesting revisiting this and being like, which one am I going to choose today?

+ +

STEPH: I feel like my natural progression when testing external services; I always start with WebMock, and then I progress to using adapters. And then from there, I go to actually replacing the HTTP service that is receiving and then returning a response, like you mentioned to Capybara Discoball earlier. So I can certainly see what you like about the adapter pattern. You mentioned that you're coding some of the inconsistencies. That feels very real. I'm curious if you have an example of how you've had to manage that recently.

+ +

CHRIS: A specific example would be the external API responds with certain error codes or error structures. So it's an error. It has a status of a number and then a reason, or sometimes instead of a key that is reason; it’s the message. So it's like, oh, okay, I see that in this endpoint, you respond with reason, and then this endpoint you respond with message. So now, do I encode that into my fake? I guess I do. So my adapter now implements things like that. There are cases where it's inconsistency where I'm like, well, this is the way they behave. So I would like our test suite to exist in the context of that because then our app is getting exercise in a real way.

+ +

But in some cases, it's like little bits of logic validation that an external system might do if that's an important part of the flow. The app that we're building has a lot of forms and a lot of data validation and things like that. And so, we want to make sure that we have robust handling around that robust messaging to the user so that it's very clear what they need to do and how they need to respond to things. And so putting in little bits of that like, oh, that's how you format a phone number, okay, cool. Our fake will also format phone numbers in that way, things like that.

+ +

STEPH: Every time the topic of testing external services comes up, I really, really want VCR to be the answer. I really like the idea of being able to validate that...because you'd mentioned that we're programming the expected return from this other service. And it's very easy to get out of sync with those actual responses. And then we don't really have a great way to stay up to date other than we wait for production or staging environment to fail. And then we realize something has changed, and we have to go and update either our mock or our adapter. And maybe that doesn't happen often if you're working with an external service that is very good about broadcasting when they have a breaking change.

+ +

But if you're working with a less stable endpoint, then I always want VCR to really work. But it's just one of those areas where I'm like, yes, that's the thing that I want. I want this idea where I can rerun my tests in a way that they actually hit that service and record the response. But then I have felt pain [chuckles] from working with VCR and how it's configured, and how people have used it. It's one of those where I don't blame the library. I like the library. But the way people have implemented it and test I have felt a lot of pain from that.

+ +

CHRIS: Yeah, I definitely agree with that. It feels like it's nice if you can push the mocking all the way out to that layer. Because like right now, our codebase has code in it that is subtly changing the behavior for a test, and I don't like that. It's only the swapping out of the adapter, so it's a very minimal thing. And we try and push all logic away from that such that the test adapter is as similar as possible to the real production situation. But it's enough difference that I agree I would like if VCR would just like, I catch the HTTP requests, and I respond with the same thing and sometimes we can pass through.

+ +

I do think one of the fundamental limitations, or at least very hard to get right things, would be sequential requests. So I post to this endpoint in the external service, which creates some data. And then later, when I make a GET request to their endpoint, I should get back that data that I just created. That's, I guess, doable because you can have sequential requests, have cassettes that are first this request, then that request, then that request. And it knows that, like scope them to a given spec. But that feels extra difficult. And it does, again to your comment, the maintainers of that project do a wonderful job, but it's a really hard target to hit.

+ +

STEPH: Well, and one of the other hard requirements with using a tool like VCR is then that external service really needs that sandbox staging environment that you can use. So that way you can create this data, you can rerun your test. So they're actually going to hit this real environment. They're going to create this data and that not have any harmful effects. And then you can record fetching that data. So it requires a lot of pieces to fall into place for it to work well. But then I was just thinking as you're talking about adapters, I'm like, yeah, I love the adapter pattern. I've really enjoyed that one for testing as well. But then I immediately start to think, oh, well, what happens when it gets out of sync, and how do we know that it got out of sync? And I don't have a great answer to that.

+ +

CHRIS: Production blows up, obviously.

+ +

STEPH: Production blows up, and then we go update our adapter. That's very calm. [laughs]

+ +

CHRIS: It would be great if CI could more proactively catch that or...yeah, I agree. I would love if VCR would work because that facet of it is so attractive. But [chuckles] I've never gotten to walk exclusively the happy path with VCR. So here we are. This is a classic case of here's four options as to how we can think about this hard and important thing that we do in our codebases, and they all have trade-offs much like everything else in software.

+ +

STEPH: I'm going to add this to my developer bucket list to live in a world where I can easily validate if an external API has changed or not and then also have tests that know when something has broken before production does.

+ +

CHRIS: Ooph, dare to dream. I like it.

+ +

STEPH: I'm a dreamer.

+ +

CHRIS: I want to live in that world. Well, with that wonderful dream to take us out, should we wrap up?

+ +

STEPH: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+G7Lenzt1 + + ]]> + + Chris Toomey + Steph Viccari + + + 306: If You Want To Go Far, Go Together + https://bikeshed.thoughtbot.com/306 + bac7b7a4-5803-40c2-8e80-e1d78ba8388a + Tue, 31 Aug 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + In this episode, Steph and Chris talk about things they've changed their minds about over the course of their careers as software developers. Steph talks about as it turns out, arm chair rests are good, feature flags and comments are also good, she's changed her mind about how teams structure the work that each person is doing at once, and believes strongly in representation in the field. + +Chris is not a fan up upgrading his operating system and when he first started out, he gravitated towards learning dynamic languages, and since then, much prefers functional languages, static typing or more broadly, static analysis. He also no longer believes in the 10x engineer, and also very much believes that URLs matter on the internet. So basically, don't call them single-page applications; call them client-side applications instead! + 45:14 + no + + + In this episode, Steph and Chris talk about things they've changed their minds about over the course of their careers as software developers. Steph talks about as it turns out, arm chair rests are good, feature flags and comments are also good, she's changed her mind about how teams structure the work that each person is doing at once, and believes strongly in representation in the field. +Chris is not a fan up upgrading his operating system and when he first started out, he gravitated towards learning dynamic languages, and since then, much prefers functional languages, static typing or more broadly, static analysis. He also no longer believes in the 10x engineer, and also very much believes that URLs matter on the internet. So basically, don't call them single-page applications; call them client-side applications instead! +Arq (https://www.arqbackup.com/) +Karabiner-Elements (https://karabiner-elements.pqrs.org/) +Kent C. Dodd’s Epic React Course (https://epicreact.dev/) +The Art of Code Comments by Sarah Drasner (https://www.youtube.com/watch?v=yhF7OmuIILc) +Gary Bernhardt: Functional Core, Imperative Shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) +Steph's Standing Desk - curved top - 55x28 (https://www.flexispot.com/electric-height-adjustable-desk-with-bamboo-top) +Transcript: +CHRIS: I still have dreams that I missed an entire semester of math class, and now it's time for the final. I don't know that I'm ever going to grow out of that. +STEPH: That's wild. +CHRIS: You don't experience that? It's a mixture of I'm in elementary school, but it's a college final. Like, the physical school that I'm in is my elementary school, but it's a calculus college course that I missed. And now it's time for the final, and I won't graduate college as a result. But it's also high school at the same time. Just every part of education sort of melded together into this nightmare scenario. Do you not experience that? I thought this was normal. +STEPH: [chuckles] Not in a very long time, not since I was in college. But I'm imagining this very cute, young Chris showing up with a backpack to the calculus final like, "Oh no." [laughs] +CHRIS: Yeah, pretty much, yeah. I really thought I would grow out of it at some point. But it shows...I think it manifests when I have anxiety about something else in the world, and then I have a math terror dream. +STEPH: That's your stress sign. That's your terror dream. +CHRIS: Apparently. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week going? +CHRIS: Oh, it's going fine. Yeah, I'll go with fine. I had to upgrade my operating system. Enough things had stopped working or seemed to be pestering me about it regularly, which normally I'm going to ignore that for as long as I can. That's sort of where I'm at in the world these days. Like, I don't want to upgrade because I don't know what's going to break and whatnot, but then things had broken already. +Text messages were no longer showing up on my computer. And it turns out that the primary way that I interact with text messages is by replying to them through my computer. I don't want to type on my phone, that's not a thing. I'm already grumpy enough about text messages, to begin with, that I will regularly respond switching to email, and then I'll go off from there. But yeah, they stopped working, it stopped connecting. +And then I got this really weird message from Apple when I tried to sign in. And I was like, I feel like I should at least try to upgrade to the new operating system, which I think has been out for a long time, and I've just been ignoring it. But then I had the added problem of I didn't have enough space on my computer to install it, which I tried once before. +So I downloaded the installer, but the installer downloader doesn't check whether or not you have enough space to do the install. So it's just like, hey, so you know how you didn't have enough space? Well, we took up the remainder of it, and now you can't do anything about it. And the installer is hidden somewhere in the computer. So at one point, it just went away, and then suddenly had a lot of space on my computer. But finally, I decided to bite the bullet. +I found a bunch of caches on my computer. So there was a cache for my backup utility, which is called Arq, A-R-Q, which was a lot of space. It was like 20 gigs or something like that. So it was like, sorry, you have no more cache. I'm pretty sure my computer's going to light on fire the next time it tries to do a backup because it has no cache to rely on, and it's got to try a lot harder, pull a lot more data down. I don't know what it does, but whatever. It's going to do that. +And then, I found the more general application caches on the computer. Spotify had like six gigs of cache. Well, what are you doing? Aren't you streaming from the internet? Stop it. That's not okay. That is not acceptable. Yarn had three gigs. I was like, what is everybody doing? And I busted all of these. I threw away everything, and my computer seems to be doing fine after the fact. So, were the caches even doing anything? I ask. +Anyway, so I upgraded, and then some stuff didn't work. And so then I had to find the versions to make stuff work. The particular one that stood out was Karabiner-Elements, which I used to make my mechanical keyboard do the right things for the function keys. That stopped working. And I tried to upgrade it to the newer version because I figured okay; they probably hopefully released a new version, but it failed in the upgrade process. +And it turns out the secret was I had to upgrade to an intermediate version. I was on 12.3, and I needed to go to 13.4. But in between, I had to go to 12.10. And if I went to 12.10, then the upgrade to 13...everything about it was everything that I hate about upgrading software. It's like, I just know it's working right now, and I feel like if I even just look at it wrong, this whole tower of software is going to fall over. +The worst thing, the thing that I have not been able to fix, is now I use iTerm as my terminal, my terminal emulator as it were. And I typically run with transparency mode on which some people look at and say, "Wow, that's a choice." And I say, "I kind of like it. I don't know; it makes me feel like a hacker or something." I don't know, whatever. [chuckles] Let me live my life. But for some reason, switching to Big Sur, the version of OS X that I'm on now, iTerm doesn't have transparency anymore. And I just haven't been bothered to fix it yet. +But, man, I got rambly. I clearly have some feelings about upgrading software. +STEPH: You have so many feelings. The fact that you kept going...People can't see me, but I'm just dying because of that whole story. [laughs] +CHRIS: I kind of felt like I had to get through it. I had to exorcise the demons, tell my tale, and then be done with it, which I think I'm at now. +STEPH: When I start laughing that hard, [laughs] I try to hide from the camera view because I want you to keep going for people to listen. +CHRIS: But what's fun is you bob and weave. You'll hide for a minute, and then you'll come back and be like, okay, I'm composed, never mind. And then you'll just fade off to the side again. So yeah, but I powered through. [laughs] +STEPH: Oh, all right, there is so much there. [laughs] Upgrading is the worst. I agree with that. That was actually something I ran into earlier this week. Well, it was a mix of where upgrading presented a problem and then upgrading something else resolved that problem. And so that was an adventure where I shared a tweet. I can link to it in the show notes as well. +But Ruby was just taking up 100%, a full core, just all the time, and I couldn't figure out why. I wasn't doing anything with Ruby. We weren't talking at the moment, but it was just turning up one of those 100% CPU or higher. And so then I did some searching. And I did find the resolution, which was to upgrade the Listen gem because there was something in the Listen gem that didn't fully support Big Sur. Is that the name of the thing that I am on? +CHRIS: That's the new one, yeah. I know because I've just upgraded to it. I have thoughts on the matter. [chuckles] +STEPH: Cool. [chuckles] Yeah, when I upgraded to Big Sur. But then someone had kindly marched in to fix it, then upgrading resolved that problem. And Ruby is back to a peaceful level as to the amount of process, the amount of CPU that it should be taking up. Transparency mode, I'm thumbs up on it. I like how you called that out, how that's a choice. And I'm with you on that choice, although I didn't realize that's broken. I guess I just hadn't...I guess I don't care deeply enough that I've tried to restore my transparency, but you're telling me to hold on. +CHRIS: We're going to get realer now in this moment. So I have a very old version of iTerm because it has a different way of going fullscreen than the default operating system level fullscreen. I really hate that it animates to fullscreen, and it doesn't quite fill the full screen. Like, it still had a border around it or something. So I have a very old version of iTerm that I've been running with forever, and I refuse to upgrade in any way as a result of I want to cling to this old version of things working. But as a result, I think I finally hit the end of the road on that. This is like years running now too. +I remember I kept it in a Dropbox folder so that each time I upgrade or get a new computer, I'm like, okay, good. I still have my old special version [chuckles] of iTerm. But I think that time is over and I got to find...I feel like there are new terminal emulators out there. It's like Alacritty and other stuff that people talk about. So maybe it's time for me to try and find something new as long as I can get that transparency because I want to feel like an uber lead hacksaw. +STEPH: You have such a brand of new-new that I'm now discovering that you are also a software hoarder, so you have both in your personality. [chuckles] +CHRIS: There was a period early on in my software career that was like, oh, I got to find all this stuff. I got to figure things out and configure it. And then I was like, wow, that's taking up a lot of my time, I should stop it. And I think since then, I haven't upgraded anything. If you go look at my .files, I don't know the last time I pushed to them, but it's been a while. I'm still doing things, of course, but not as much. I know the cost of it, and I know the cost of maintenance. +And really, this is an allegory for software overall. This isn't just about our local development environments, but entropy exists in software. Software does not exist at rest, and it will decay over time. And so the idea of we've worked with so many clients where they're like, yeah, we're on Ruby 1.8, and it's Rails 0.9. So okay, all right, well, we're going to have to deal with that, it turns out. We can't just keep ignoring that. So really, it's the same story played out but in my local hoarder cavern. +STEPH: There was a part of the saga, the story that you shared with the installer and that you don't have enough space, and it took up the rest of the space, and you can't do anything. I'm very nervous; what happened to your stuff, your space? How did that resolve? [chuckles] +CHRIS: I finally bit the bullet. And so I have a bunch of...I've tried a bunch of the different pieces of software that will visually analyze your disk space. So they crawl the whole directory starting from the very root of your computer, and it will be like, all right, applications has this much, and the library directory in your home directory has this much. Here are all of the different places that stuff might be hiding on your computer. And then you can visualize and be like, okay, that's where the most of it is. +Node modules, as an aside, we did not choose an efficient way to approach how to put code on my computer because Node modules take up a lot of space on my computer, but they're so spread out. Multiple times I've seen people share a version of rm -rf, and then it's some subshell that does find every Node modules directory underneath a code folder. So you can find every single Node module and just blow them away. That will regain you some space. But that was not the solution this time. +I've tried lots of piecemeal solutions over time. But eventually, the thing that got me there was just busting all of those caches. So I cleared the backup utility, Arq's cache. I cleared a bunch of them, Spotify Yarn, et cetera. And that cleared enough space for the installer to actually run. And then, once that was done, the installer program itself was no longer around, so I reclaimed that space. But it was this weird chicken and egg thing where I had to have enough space to complete the installation such that the installer could go away. +And now...actually, let me see what my hard drive looks like now. So somehow, according to the Macintosh hard drive info, I have 50 gigabytes of available space, which is really frustrating because there were a number of weeks where we went into a Bike Shed recording, and I was like, I have one gigabyte. I'm not safe right now because this audio is going to be more than that. And so I don't know how now I'm sitting at 50. I guess all those caches that I cleared and the installer being gone probably puts me in a good spot. +But anyway, I'm living in an upgraded, wonderful world. As an aside, Big Sur is ridiculously rounded and colorful and almost cartoonish. They're really leaning into the iOS vibes. And I'm not sure it's my personal aesthetic, but that's fine. I spend most of my time in the terminal anyway. But I think that's enough of me ranting about upgrading my operating system, which apparently I had a lot to say about. But what else is up in your world, Steph? +STEPH: I do appreciate the ranting, though. You're not often grumpy, and when you are, it's quite humorous. [laughs] I really enjoy the grumpiness. And it's often a painful process. So I appreciate all of that story. +Something that I really need to share with you and get off my chest is a couple; I don't know, x number of episodes back, you and I were talking about computer chairs. And I bragged about the fact that I have a computer chair that has no armrest, and I love it. I love my chairs like this, and it's wonderful. And I just think it's the best way to live. +And it turns out that that's bad because I happened to go see a massage therapist who's also very well-skilled in physical therapy and other areas. And they were talking to me about my desk setup. And I mentioned the fact that I get these typical headaches, and I have my chair, but there's no armrest. And they're like, "Oh, that would do it." I was like, "Why? I like my setup. What's wrong with it?" And they're like, "Well, if you don't have armrests, then your back is having to compensate and to hold up your arms and your shoulders all day. So while you're typing, you're using more muscles to then hold that. And then they eventually tighten and contract, and then that can cause headaches." +So in case, I have led anyone astray into having no armrest, they are apparently very important to not having headaches or having your back overworked to the point that you have headaches, which I'm a bit sad about. But on that front, I have ordered a new chair, and we'll see how it goes. I will have to assimilate into the world of chairs with armrests. +CHRIS: We welcome you with open armrests. [laughs] Sorry, I saw it, and then I went with it. Anyway, I'm realizing now I actually don't use the armrests on my chair per se. I actually end up putting my arms on the desk, which is probably not ideal either. I have a little wrist pad so that my wrists are brought up and so that I don't have the upward breaking of the wrist thing going on. I think that matters a lot. And then my arms are supported by the desk, but it is just right on the desk, and I wonder if that's worse. But I've never...I don't know, getting the armrests just right and then also having the wrist pad. +But I can't adjust my desk is probably the main problem. If I could bring my desk down a little bit, and if it were a thinner top, then I'd have more flexibility. The chair that I have is wonderful and has flexibility. The arms can go up and forward into the side and lumbar and this and that. And so I'm able to make the chair work to the desk. But I do wish I had more of an adjustable...ideally, like a stand-sit desk. But I haven't made that jump just yet. +STEPH: When you're ready to make that jump, I'm going to share with you where I bought my desk because I'm really happy with it. And it's also not nearly as expensive as most of the other desks that will go up and down. +CHRIS: Presumably, we can include it in the show notes as well so that we share it with everyone. +STEPH: Definitely, yeah. +CHRIS: Otherwise, that's just kind of mean. [laughs] You and I have a weird back channel that we talk about on the show, but they're not actually put in the show notes. +STEPH: We're not mean. We wouldn't do that. I love my desk. And it was from someone else. They're the ones that shared it with me, so I'm happy to pass it along because it has served me well. And yeah, I'm also not sure about how this is going to work with the chair and the armrest because I'm just worried they're going to be too wide, and they're not going to actually offer support. I have doubts. I have lots of doubts, but I'm willing to investigate. And we'll see how this goes because I would like for the headaches to stop. +CHRIS: Good luck on that front. That definitely seems like an indication of worth putting in some effort there. +STEPH: Agreed. I also have some other exciting news. Stephen Hanson at thoughtbot has organized a number of other thoughtboters to get together who are interested in really diving into leveling up, learning React, and specifically focusing on purchasing the Kent C. Dodd’s Epic React course. And it's for anyone that is comfortable writing code, whether you know React really well or if you're new to it. Everyone's welcome to join. +So we just kicked that off today where we're going to go through the course together and then meet every Friday. I think the cadence is probably three hours, three and a half hours every Friday, that then we're going to commit to working through the course together. +And I have to admit, I always nerd out a bit over how does someone build a course? Like, I'm really excited about the content as well, but I just want to know how did someone go about producing this content and then sharing it with everyone? And then what's their outline? How do they help people that are getting stuck because they can't be there in the same room? How do they record their videos? +So I'm really excited to see all the ways that Kent has crafted this workshop. And so far, there's so much content, but I'll have more to report as we really start to dive in. But I'm excited to revisit React because I haven't been in React land for at least a year and a half; it’s been a while. And so it's one of those areas that I know some bits, but a lot has also changed. And I would like to just revisit that world. So I'm really excited to dive into the course. +And so far, I really like the structure that Kent has taken with the curriculum where we're focusing first on what exactly is happening and all the effort that goes into if you wanted to actually write HTML and then layer on JavaScript on top of that. But then here's how React makes that easier for you. Here is how JSX makes it even easier on top of the React API. I really liked that. Here's some pain; feel a little bit of pain, let's get a little bit better. And then let's get even better on top of that. And that has been a really nice reminder and progression into the course. +CHRIS: I'm definitely a fan of the way you're describing it like, feel some pain, and then let's get better. But then, like, what's the hook? With any educational content, this is the sort of structure where there can be full education. But this is the thing that I feel very deeply about conference talks is my goal isn't to teach you everything if I'm giving a conference talk; it is just to get your attention just to say, "Here's the thing, here's why you might care." And starting from the problem, starting from the pain is always such a good way to do that. Because you know how this stuff is hard? What if I had an option that was easier? And then building from that totally makes sense. +I want to say that course, Kent's course was built in conjunction with the egghead team, egghead.io. And it's a distinctly branded course. But it was built on top of the framework in the platform that's there and all of that, and then some of the editing support. I don't know this for certain, but I think there was some teamwork there. +And I love just pushing forward the envelope of how we do educational content in the world of development because it is such an interesting world that has, frankly, such a need for ongoing development. The world is changing out from underneath us every two days. And therefore, having great educational content is so important. So yeah, definitely interested to hear how your experience goes both with the course and then also diving deeper into React. +Well, switching gears just a little bit, I had a topic that I wanted to dig into with you today. And so to give some context, the topic, the thing that we're going to be talking about today is what have we changed our mind about? So you and I have both done a little bit of thinking and tried to come up with some answers to this. The background, this was actually inspired by a tweet that I saw between Shawn Wang, aka "Swyx" on the internet, and Charity Majors, a recent guest here on this podcast. +And Charity is someone who is known for having strong opinions. But Shawn asked the question of what are some opinions that you've changed your mind about? And Charity actually had a wonderful list, which we'll link to her tweet thread where she shared some of her both technical and then also more personal ones, but really talking about the sort of evolution of thinking and the way someone's thoughts can change over time. +And I thought it was just such an interesting thing because, for most points in time, we experience someone's sort of snapshot of where are you at now? What do you believe to be true? But I think there's such an interesting story and sort of the arc there of what did you believe to be true that you don't anymore? What have you softened your beliefs on? What have you strengthened your beliefs on? So yeah, with that as the context, what have you changed your mind about, Steph? +STEPH: Yeah, this one really got me thinking, and I feel a little stumped on it. I have a few that I'm excited to share. But I'm very excited to hear your list to see if that also helps me reflect more on some of the things that I have changed my mind about. And I have found that there's only a couple maybe that I feel like I've really solidly changed my mind about. The others, I've either dialed up the strictness, or I've dialed it down. So the ones where I've really changed my mind about are feature flags and comments. Those are two of them. Well, there's a third one, but I'll get to that in a moment. +So starting with the first one, feature flags I was more in the camp where I very much appreciate feature flags, but I use them sparingly because then there is a tedious nature of introducing them and then having to clean them up, and then having to maintain two states of code. But now I've really seen the value of feature flags and how we can make sure that we have calm releases and ensuring that main is always in a deployable state. So feature flags is one for me. I'm very invested in having more of a robust feature flag system because I see the benefit to that. +The other one was comments. I used to be very rigid about comments are bad. We should never have comments in our code. They are just waiting to go out of date, and they're not going to be helpful. But I have since dialed down that strictness where I have certainly seen moments where comments do feel very helpful, and I can see how people use them. I still want to avoid them for the most part, but I am less strict now in regards to people who really find value in comments. I'm more open to that discussion. I want to understand what it is they find helpful about that comment, and if it is something that we can't capture with code or a test, where does that live? +CHRIS: Those are both interesting. Feature flags, for me, I think I actually was more strongly opposed in the beginning. Earlier on in my career, I saw them as added complexity, as noise. I often would encounter them left behind in a codebase. And so, I had this negative association with them. And I didn't see the value; I hadn't yet felt that pain. And over time, I've definitely shifted to where you're at where I'm like, I love feature flags. This is a critical tool in our toolset of how we actually…like you said, calm deploys, being able to always deploy main, making sure that we don't have long-running feature branches. There are so many benefits that come out of it that I'm now very strongly in favor of them. But it's interesting; I think I would say that I started in a more strongly opposed place. So that wasn't on my list, but it's an interesting one that you've brought up and probably one that I've moved more on. +Code comments, I think, actually started in my career being like, obviously, you comment your code. It's the thing that I read about and stuff. And slowly, over time, I think I've just dialed in on I don't think we should be doing that. There are, of course, going to be exceptions. +And actually, one of the things that I discovered about myself as I was trying to go through this exercise is there are very few things that I believe are black and white. If anything, that maybe is one of the things that I've leaned into over time. It's like, nothing is binary. Nothing is black and white. Everything is on a continuum or shades of gray. There are things that I believe a little more seriously. But there's almost nothing that I can be like, nope, absolutely I will not equivocate on this beyond how we interact with other humans and being reasonable, kind people. And in terms of software practices, not really. Comments, though, are one that I still am pretty strongly not going to lean into. So it's interesting that you're like, eh, I've kind of opened up to that one. +STEPH: There's a particular talk, The Art of Code Comments by Sarah Drasner, and that's the one that really shifted some of my opinions around comments, and then how we talk about them, and what benefits they can play. But I will admit, if I see a PR that has code comments, I still immediately have a negative reaction to that. And I want to have a conversation around why that comment was added and if we can remove it, and how we can remove it. But even with that negative perspective, I still find that I'm more open to that discussion versus before, where I would have been like, no, that's just unequivocally bad. +CHRIS: I do like that you always bring up that talk whenever we talk about comments. This is a great talk. And in the background, I just looked up Sarah's Twitter profile because every time you bring it up, then I mention that she has a still from the movie Labyrinth in her Twitter background, but she actually changed it. And so now that's not true anymore. It's now something from The Force Awakens. Well, it's actually a joke, but I'm still going to suggest that you watch the movie Labyrinth at some point. That's the thing that I feel actually kind of weird about. It's a weird movie. +STEPH: I'm going to take your suggestion, but not watch it. But thank you. [laughs] To share my truth today. +CHRIS: That's fair, that's fair. +STEPH: What are some of the things on your list? +CHRIS: Okay, I have a couple, some more on the technical. Let's lean into one of the technical ones. Early on, I started with dynamic languages. I think I started with Python primarily and a little bit of JavaScript. I eventually found my way to Ruby and felt very at home there. And then, I started to explore functional languages. And I started to lean into them really hard and felt that immutability and functional programming and true pure functional programming was the thing. It was the answer, and I just needed to figure out how to do it. And so I would say that is the belief that I have since changed my mind on and decided, you know what? Actually, it feels like a bit of a force fit. I have tried. And maybe for others, it is actually a really fantastic way to build software. But having worked with a number of other people in more functional contexts, I find that it is a bit of a force fit. It's a bit rough. +And in particular, of late, I've been working with Svelte as opposed to React, and React does sort of lean into the functional paradigm, especially with Hooks and all those sorts of things. And it's a little bit rough because it turns out UIs are these deeply mutable things. We're changing values or typing things in. There are actions that are changing the state over time, and having a system that just more directly models that feels very natural. +I still love functional programming for the more core of an application. So again, I reference this talk often, but Gary Bernhardt's Functional Core, Imperative Shell. Gary has really formed some of my thinkings on this. And now I've started to find the examples in the work that I'm doing of like, oh, okay, I see that pattern actually applied here. But much as I would love to use them, the functional languages I find just aren't quite landing for me. And additionally, the mutability, particularly in the front end right at the edge of the UI, is not quite as good of a fit. +STEPH: So I think that resonates with me although I do still get very excited about following more patterns that represent more immutable state just because I felt so much pain and found bugs from the fact that we have mutated state in surprising ways. I'm honestly not quite sure how I feel about it. I'm going to have to think on that one. That's a very interesting one that you've changed your mind on. +CHRIS: Yeah, similarly, my feelings are lukewarm, whereas before, they were stronger. I was like, oh, okay, I think I found something here. And then, in attempting to use it across a wide variety of applications, it just didn't quite feel right. I felt like I was swimming upstream sort of thing. +Actually, there is an interesting counterpoint. One thing that I have leaned into and definitely changed my mind on and embraced is static typing or, broadly, static analysis. But I think static typing being the most pointed version of that. Early on, like I said, I got my start in very dynamic languages in Ruby, and Python, and JavaScript. And so that dynamic duck typing runtime can be anything. We just make our systems respond to the messages, and all of that sounded great. +But it turns out I really love having a compiler that can tell me some truths about my program before it ever reaches runtime. And the idea that a typo can make it to production feels absurd at this point. And actually, as I'm working in Ruby, I'm like, man, I really got to go look at that whole Ruby typing thing we got going on. I don't know what the state of it is. I've looked at it in the past, and I need to revisit it soon. But like TypeScript, I've definitely embraced that very strongly. And I would not work without TypeScript in a JavaScript project at this point. +I've loved the work that I've done in Elm, although that also sort of blends into the functional stuff where it's like, it was a little bit noisy, though, I'll say that. But the type system and the fact that the compiler can give you so much rich information about your program, I would not trade that at this point. And I don't see myself going back on that front, which is an interesting place for me to be on of actually, I'm not that into the functional programming as the core way that I build my applications. +But I do like static typing. And I feel like functional programming and static typing actually go together incredibly well. And functional programming and, more imperative, whatever it is that I'm doing with my day-to-day life these days is a more interesting fit. But it is interesting to me to observe that sort of combination of opinions where I really like static typing, and having a compiler, and something that can tell me about my program before I get to runtime. But also saying that I don't quite want the functional programming thing, or at least not as the entire way that I modeled my application because I found it a bit difficult to work with. Because I think static typing or compilers and functional programming go really well together. +But I think generally, what I'm finding is a more middle ground dynamic optimization of a bunch of different things. And the answer is like, well, it depends which I guess if you've listened to the show before, you'll have heard those words said, so I guess it makes sense. +STEPH: Yeah. All of that makes sense to me. And I can see why you might have a favor for types or why that feels more valuable initially because that is giving us so much feedback right off the bat versus following a more functional paradigm is something that could feel like more of a force fit and doesn't provide that same immediate feedback. But it has a longer-term or a longer cycle of that reward system. So I can see why you might favor one over the other or why I myself would favor one over the other. +CHRIS: How do you feel about types? +STEPH: I'm a big fan, although I say that, but I work in Ruby. [laughs] I don't have them. But when I have worked with types, I very much enjoyed it because it makes me think more about the design of my code in a way that I don't as much with Ruby. And working with types has heavy influence than when I am working in Ruby and thinking about the design of my code. So I think working with types is a wonderful thing that, frankly, all of us should do as developers at some point because it is so influential. So I'm for types, but I'm not using types in my day-to-day. +Another thing that I have changed my mind about is how we structure the work that each person is doing. So I used to be more in the camp of everybody can work on their own very complicated piece of codebase, their own complicated feature. We can have a bunch of complicated things in the sprint, and everything will just be great; it’ll be fine. And we'll get a bunch of work done, and we'll ship it. And then we're an even more productive team. +And I very much disagree with that now where I have found where everybody is working in their own silo on a complicated feature has slowed down the progress of then being able to ship that feature. Because we often want to collaborate with someone, we need to collaborate with someone. Then the PR review process is tough if I really have no idea what you're working on, and I don't have a context that then when I look at your code, not only am I evaluating at the code level, but then I'm also trying to understand the feature and gain all of that context. And that's a heavy cost for me to have to pay to then pick all of that up and then for you to have to reintroduce me to what's happening. Or I might make the bigger mistake, and I may look at your code and just evaluate it from the code perspective but not really understand the feature, the value that's being delivered. And that doesn't feel useful. +And I have a recent example where that happened where someone was working on a very complicated feature that I didn't have any insight into. So then, when I was looking at the PR, it was easier for me to just look at the code and get feedback on that. But then it was probably a day or two later. It wasn't until then that I finally started asking, what are we building? Like, what purpose is this serving? And that opened up a much larger discussion where we realized what was being built didn't actually really deliver what we needed to deliver. So I no longer agree with the idea that everybody should be working on their own complicated features independently, and there should be some collaboration. And, you know, it's the buddy system; we all need a buddy. +CHRIS: Well, I like that one. I feel like I've shared similar ideas where it made sense. It was just the efficient thing to do, to split the work up and have everybody very independent. I also feel like earlier on in my career; I was more scared of Git conflicts and things like that or people interacting with the same parts of the code. And so in my mind, it made sense to really strongly separate like, oh, you shouldn't even be touching the controller for this. I'll handle the views, and you handle the controller; it'll be separate. And I care less about that now. And I think what you're saying of like, it's actually better if we have some shared context, and we understand what we're working on, and it's more of a collaborative process. Yeah, I like that one. I think I followed a similar arc, and I'm at a similar place now as well. +Interestingly, to go into another one of mine that I think you'll probably be most surprised by on my list is I think I used to believe in 10x engineers. I used to believe in the idea of that one developer just off in the corner fueled entirely by Mountain Dew that would just produce the perfect code. They would just solve it. Over the weekend, they would write the entire billing system, and it would be great. And I think it was predicated on the idea that the coding is the hard part, which I no longer believe. I think coding at its core is communication. It's taking this thing that we want to be true in the world and then communicating it to a computer but also ideally communicating it to our teammates, and to future versions of ourselves, such that we can revisit that code, we can maintain it over time, other people can add to or augment it. +And so the idea of this loner that can just do incredible volumes of work and have that be a good outcome that just doesn't make sense to me anymore. I've worked with incredibly talented developers, to be clear, folks that I was sort of in awe of. I've worked with people who have, I think, just truly photographic memories. They seem to remember every single bug that they've ever had and exactly where they can look it up. Or from the top of their head, they can just intuitively know, oh, this bug means this. Go look at this line of code. I'm like, how did you do that? How did you do that magic trick? And they're incredibly capable developers. But at the end of the day, the folks that I see being most impactful on a team are the folks that are able to communicate and collaborate most effectively and make the whole team more effective. +STEPH: Maybe it's the Mountain Dew; maybe that's actually the secret sauce here. That's what I'm missing from my life to take me into that status. +CHRIS: I'm now imagining Mountain Dew but in a more viscous form, like a barbecue sauce, but it's Mountain Dew flavored. That's the secret sauce because it's a very…anyway, moving on. [laughs] +STEPH: It's a terrible product. We should make it and sell it. +[laughter] +CHRIS: Career pivot, we now sell Mountain Dew sauce. +STEPH: [laughs] +CHRIS: But yeah, I do not believe in 10x engineers anymore. If anything, I believe that that is a huge warning sign if you have anyone that's behaving in something close to that space. +STEPH: Yeah, I'm super interested in that you've shared because I don't think...We've talked about 10xers, but we haven't talked about the fact that you used to think that they were more of a thing and that they existed. And now it's all I'm sorry, but it's all crap. [chuckles] That's super interesting to me. Do you remember what changed your mind? Do you remember that pivotal moment of where you were like, oh, maybe this is all bullshit? +CHRIS: I think it was just an amalgamation of experience over time. I've encountered people who fit the archetype. But if anything, I would say they're deeply problematic in teams. They're that individual who refuses to collaborate, who just goes off and heads down, writes a bunch of code, but then it doesn't integrate with the other pieces, or no one else knows how to use it, or they won't let anyone contribute to it. And yeah, I've seen that just be very, very problematic. +So the folks that most fit, I think the imagined version of this, actually end up, in my experience, leading things astray. And the folks that are actually most productive and really cause teams to improve in a drastic way behave very differently. They're much more collaborative; they’re much more engaged with the team. It's less about their individual contributions and it's more about building a system together, collaborating, communicating, engaging external stakeholders, et cetera, et cetera. It's all that stuff that matters. And so, it's very much in contrast to what the 10x engineer ethos is about. But there's no one day where suddenly this idea that I had in my head crumbled when I saw that behind the pile of Mountain Dew cans, there was nothing there. [laughs] +STEPH: It's all a mirage. [laughs] I do like what you just said around that there are very impressive people out there. And those impressive people often focus less on their individual contributions and more at a higher level around communication. And then they are the powerhouses that then is helping facilitate everybody else be their best and have high levels of individual contribution. Those are the ones that...I'm still not going to endorse a 10xer, but they are the ones who, to me, embody the idea of someone that is incredibly efficient and really good at their job. +CHRIS: There's an adage that comes to mind here that "If you want to go fast, go alone. If you want to go far, go together." And that does ring true to me. I think an individual can have their individual productivity be higher if they're working entirely on their own, if they understand every line of code because they wrote every single line of code if they know where every feature of the platform is integrated because they wrote the whole thing. But they're going to be fundamentally limited. And in order to do bigger, more complex things, fundamentally, we have to work as a team. And then the way you have to interact just fundamentally changes. +So I think it started from that, like, one person on their own I think can be individually more effective. But the minute you start to have a team, that one person acting on their own is actually dragging the team down because other people can't then work in that space, and that's a problem. +STEPH: I really like that adage that you just shared where, "If you want to go fast, go alone. If you want to go far, go together." And that touches on something else that I have really changed my mind about, and that's representation. And this is more specific to me. So when I joined engineering and became a web developer, and I joined a team, and I was the only female engineer on that team, my initial feelings were I am the only female engineer, and that is fine. We're all just a group of engineers. We're here to solve problems together. It really doesn't matter if there's anyone here on this team that's like me. It's fine if there's no one that I can see myself in that's in leadership because we're all just people, is what I was coming down to. And I've completely changed my mind and realized that that's not true. +And I've experienced this where I've worked on other engineering teams with female engineers, and it's fucking awesome, and it does make a difference. And then when I can see someone that I can see myself in, in a leadership position, that is also inspiring. So that is something that I went in where I think it was more of I was trying to shield myself from the idea that I am different from everybody else in this room, and that could be a problem. And instead, I just tried to neutralize it by saying it's not. +But I think representation is incredibly important. People are not just people. We all have very important social and racial, and cultural identities. And it's very important that we get to feel that we can express all of those identities and see people that represent those identities in spaces where we would like to go. That's a big one that I've changed my mind on. +CHRIS: Yeah, I certainly agree that representation certainly matters, and being able to bring your full authentic self to work and seeing others around you that reflect that. And frankly, having teams that are made up of people that represent the users of the software that we're building feels so critically important. And it's very interesting to hear about the arc that you've had on that where initially, you tried to downplay it, but then you found a little more truth in it. And so yeah, thank you for sharing. +STEPH: You're welcome. It feels good to say that, too, because that's something that I've admitted and realized on my own, that that is something that has changed and shifted. But it's nice to be able to share that here with you as we're going through the things that we've changed our mind about. What else is on your list? +CHRIS: Well, to round us off with one more very technical version because, of course, that's where I'm going to take us after a much deeper and more nuanced topic that you led us on, single-page applications. Broadly, I'm opposed to the name; that’s a side conversation. But, man, URLs matter on the internet. So don't call them single-page applications, but client-side applications or whatever. Broadly, the idea of a bundle of JavaScript, and so you send down an empty HTML document, and then you reference a bundle of JavaScript, which that thing boots up and it then makes a bunch of API requests to the backend, and then it starts to fill in the page. +I was convinced for a while that this is a reasonable and perhaps even necessary way to build software. We need APIs for our mobile apps anyway. So if we're doing that, then let's have that be the consistent way that we are accessing information. This is going to be fine; it's not a problem. And then eventually, we found some problems. So then we got GraphQL, and we tried to solve it that way. But overall…and I have spent a lot of time trying to make this thing work, trying to find a version of this that I'm happy with that I find the end outcome of the software to be as pleasant to work with from an end-user perspective as a server-driven application, and I can't find it. +And so, to be clear, I'm still doing client-rendered applications these days. But Inertia.js is the framework that I've leaned into that helps me bridge that gap. And the idea that the server owns routing, that the server owns statefulness, things like that, not having to think about client-side routing, not having to think about client-side state management, being able to use traditional auth mechanisms built into cookies, all of these familiar things that we've had. Leveraging the fact that the server is the more privileged in terms of the information it has access to, the more secure, the more powerful environment, all of these things feel right to me. And the nature of the application that I can build just feels more robust, more consistent, easier to evolve. +There were a lot of promises that I heard when we started building applications in these ways. And I just haven't seen an example or have not worked on an example, at least of an application that is built as a client-side bundle that boots up and does some stuff and had a good experience with that. So Inertia, as an aside, is my answer to this. And I continue to be extremely happy with that as a solution, as really a middle-ground solution. Because going all the way back to true HTML server-side rendering is limiting in other ways that I didn't like. But I find that Inertia really strikes an ideal balance in the middle there. +STEPH: I feel like I completely agree with everything you're saying. But I also feel like I have a developer secret to share where I really haven't worked on single-page applications, and I am okay with that. [laughs] +CHRIS: It's fine, skip it. Just go straight to Inertia. It's better. +STEPH: Cool, cool, cool. I am working on leveling up React, and then the plan is to go to Svelte and Inertia. So I'll just completely...I'll skip that. I'll skip that part of my career. +CHRIS: I actually want to back up just a little bit as I'm saying this because I really try to avoid being in a more negative space. And I think this space, this architecture for building applications, is complex, and there are things that will warrant it. So things like Google Maps, it makes sense to have a lot of Dynamic JavaScript and to be doing complex things on the client-side. Trello is another example of an application that that as a server-rendered thing, doesn't really make sense. And frankly, using a tool like Inertia wouldn't quite work there. That said, that is, in my mind, truly a single page within the broader application. So the Trello board page is a very, very complex stateful application, and I think modeling it as such makes sense. Google Maps, similar. But there's still the profile page, and the login page, and all of these other things. +I think routing is probably where it breaks down for me. I think client-side routing is the thing that I feel the most pain on. Because at the end of the day, the server still needs to know the answer. And if we do client-side routing, we end up with this duplication of logic across the client and the server-side. We end up with disagreements from time to time. We end up with the weird flashes of half-rendered layout, and then we go to the login page because we get an API response that is different. And so, I think that is probably the kernel of the thing that I struggle with. And, of course, it is possible to build great things using any of these technologies. +But I think my summary is I've really tried on that front, and I've just not been able to make the fidelity of application that I want using…primarily; I’d say it's client-side routing is the thing that I struggle with the most. +STEPH: Yeah, it sounds like you're saying there are very valid use cases for using a single-page app or following that structure. But we haven't really gotten there in terms of our web development expertise, where we've made that easier to maintain and easier to implement. And there's still enough pain points around it that even though it seems like a very valid idea and approach, it still feels painful enough that you actively avoid it until it feels like something that you have to then invest in at that point to then really deliver the user experience that you want to provide. +CHRIS: Yeah, I think that's an accurate summary. And I think adding on to that, I’m noticing it becoming more and more of the standard approach; this is the way we build applications, and I don't agree with that. That is probably the thing that is the kernel of what I don't believe in. I think actually server rendering is a great way to start, and then you can slowly augment or move more things into complex client-side behavior. But starting with this as the mode that we're building our applications just feels like a less stable foundation than I would want. So it's perhaps an architecture that you want to evolve to at some point as the complexity necessitates it, but I definitely wouldn't be starting there. Similar to service-oriented architecture, not going to start there. Client-side routing, I'm not going to start there. +STEPH: Ooph. I feel like I've been holding my breath this episode. I feel like this was a very interesting topic that has been challenging to reflect on what we believe and what we've changed our mind about. +CHRIS: I think it's perhaps more nuanced than a lot of our episodes where often we're saying this is what we did, and this is how we felt in the moment. And that can be very experiential and true. But this, yeah, we had to draw the line in the sand and say what do we believe? I similarly definitely feel more tension in this episode than other ones. But hopefully, it was useful. Hopefully, folks found some value in the things, and hearing our story, also, the idea that we have singular formed opinions. Hopefully, this episode has broken that idea in anyone's head. And we're all on a journey. +STEPH: I really like how this has prompted me to reflect on the things that I used to hold dear and really cherish or follow strictly to then reflect on what are things that I used to believe versus what I believe now? Because that transition often happens so seamlessly for me that I don't really stop to think about it to be like, oh, something just happened that is really changing how I approach things, how I build, how I work with teams. And I really like this reflection point to be like, oh, what did I used to believe, and what's different today? I'd like to keep this practice going and just try to track the things...I'll have to make a list of all the things I believe. That seems like an easy list. [laughs] +CHRIS: Just the easiest list to write. +STEPH: The easiest list to write. And then I'll just check in with it every so often, scratch stuff out, or update it with the things that have changed my mind about. This is the good idea, terrible idea where you go, "Stephanie, that's a terrible idea." [laughs] +CHRIS: I don't know, write it down on a list, and then look at it in six months and see if it sounds like a good idea, and then we'll be able to close the loop on the whole thing. But with that, should we wrap up? +STEPH: Let's wrap up. I've got a list to write. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshedor reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + In this episode, Steph and Chris talk about things they've changed their minds about over the course of their careers as software developers. Steph talks about as it turns out, arm chair rests are good, feature flags and comments are also good, she's changed her mind about how teams structure the work that each person is doing at once, and believes strongly in representation in the field.

+ +

Chris is not a fan up upgrading his operating system and when he first started out, he gravitated towards learning dynamic languages, and since then, much prefers functional languages, static typing or more broadly, static analysis. He also no longer believes in the 10x engineer, and also very much believes that URLs matter on the internet. So basically, don't call them single-page applications; call them client-side applications instead!

+ + + +

Transcript:

+ +

CHRIS: I still have dreams that I missed an entire semester of math class, and now it's time for the final. I don't know that I'm ever going to grow out of that.

+ +

STEPH: That's wild.

+ +

CHRIS: You don't experience that? It's a mixture of I'm in elementary school, but it's a college final. Like, the physical school that I'm in is my elementary school, but it's a calculus college course that I missed. And now it's time for the final, and I won't graduate college as a result. But it's also high school at the same time. Just every part of education sort of melded together into this nightmare scenario. Do you not experience that? I thought this was normal.

+ +

STEPH: [chuckles] Not in a very long time, not since I was in college. But I'm imagining this very cute, young Chris showing up with a backpack to the calculus final like, "Oh no." [laughs]

+ +

CHRIS: Yeah, pretty much, yeah. I really thought I would grow out of it at some point. But it shows...I think it manifests when I have anxiety about something else in the world, and then I have a math terror dream.

+ +

STEPH: That's your stress sign. That's your terror dream.

+ +

CHRIS: Apparently.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week going?

+ +

CHRIS: Oh, it's going fine. Yeah, I'll go with fine. I had to upgrade my operating system. Enough things had stopped working or seemed to be pestering me about it regularly, which normally I'm going to ignore that for as long as I can. That's sort of where I'm at in the world these days. Like, I don't want to upgrade because I don't know what's going to break and whatnot, but then things had broken already.

+ +

Text messages were no longer showing up on my computer. And it turns out that the primary way that I interact with text messages is by replying to them through my computer. I don't want to type on my phone, that's not a thing. I'm already grumpy enough about text messages, to begin with, that I will regularly respond switching to email, and then I'll go off from there. But yeah, they stopped working, it stopped connecting.

+ +

And then I got this really weird message from Apple when I tried to sign in. And I was like, I feel like I should at least try to upgrade to the new operating system, which I think has been out for a long time, and I've just been ignoring it. But then I had the added problem of I didn't have enough space on my computer to install it, which I tried once before.

+ +

So I downloaded the installer, but the installer downloader doesn't check whether or not you have enough space to do the install. So it's just like, hey, so you know how you didn't have enough space? Well, we took up the remainder of it, and now you can't do anything about it. And the installer is hidden somewhere in the computer. So at one point, it just went away, and then suddenly had a lot of space on my computer. But finally, I decided to bite the bullet.

+ +

I found a bunch of caches on my computer. So there was a cache for my backup utility, which is called Arq, A-R-Q, which was a lot of space. It was like 20 gigs or something like that. So it was like, sorry, you have no more cache. I'm pretty sure my computer's going to light on fire the next time it tries to do a backup because it has no cache to rely on, and it's got to try a lot harder, pull a lot more data down. I don't know what it does, but whatever. It's going to do that.

+ +

And then, I found the more general application caches on the computer. Spotify had like six gigs of cache. Well, what are you doing? Aren't you streaming from the internet? Stop it. That's not okay. That is not acceptable. Yarn had three gigs. I was like, what is everybody doing? And I busted all of these. I threw away everything, and my computer seems to be doing fine after the fact. So, were the caches even doing anything? I ask.

+ +

Anyway, so I upgraded, and then some stuff didn't work. And so then I had to find the versions to make stuff work. The particular one that stood out was Karabiner-Elements, which I used to make my mechanical keyboard do the right things for the function keys. That stopped working. And I tried to upgrade it to the newer version because I figured okay; they probably hopefully released a new version, but it failed in the upgrade process.

+ +

And it turns out the secret was I had to upgrade to an intermediate version. I was on 12.3, and I needed to go to 13.4. But in between, I had to go to 12.10. And if I went to 12.10, then the upgrade to 13...everything about it was everything that I hate about upgrading software. It's like, I just know it's working right now, and I feel like if I even just look at it wrong, this whole tower of software is going to fall over.

+ +

The worst thing, the thing that I have not been able to fix, is now I use iTerm as my terminal, my terminal emulator as it were. And I typically run with transparency mode on which some people look at and say, "Wow, that's a choice." And I say, "I kind of like it. I don't know; it makes me feel like a hacker or something." I don't know, whatever. [chuckles] Let me live my life. But for some reason, switching to Big Sur, the version of OS X that I'm on now, iTerm doesn't have transparency anymore. And I just haven't been bothered to fix it yet.

+ +

But, man, I got rambly. I clearly have some feelings about upgrading software.

+ +

STEPH: You have so many feelings. The fact that you kept going...People can't see me, but I'm just dying because of that whole story. [laughs]

+ +

CHRIS: I kind of felt like I had to get through it. I had to exorcise the demons, tell my tale, and then be done with it, which I think I'm at now.

+ +

STEPH: When I start laughing that hard, [laughs] I try to hide from the camera view because I want you to keep going for people to listen.

+ +

CHRIS: But what's fun is you bob and weave. You'll hide for a minute, and then you'll come back and be like, okay, I'm composed, never mind. And then you'll just fade off to the side again. So yeah, but I powered through. [laughs]

+ +

STEPH: Oh, all right, there is so much there. [laughs] Upgrading is the worst. I agree with that. That was actually something I ran into earlier this week. Well, it was a mix of where upgrading presented a problem and then upgrading something else resolved that problem. And so that was an adventure where I shared a tweet. I can link to it in the show notes as well.

+ +

But Ruby was just taking up 100%, a full core, just all the time, and I couldn't figure out why. I wasn't doing anything with Ruby. We weren't talking at the moment, but it was just turning up one of those 100% CPU or higher. And so then I did some searching. And I did find the resolution, which was to upgrade the Listen gem because there was something in the Listen gem that didn't fully support Big Sur. Is that the name of the thing that I am on?

+ +

CHRIS: That's the new one, yeah. I know because I've just upgraded to it. I have thoughts on the matter. [chuckles]

+ +

STEPH: Cool. [chuckles] Yeah, when I upgraded to Big Sur. But then someone had kindly marched in to fix it, then upgrading resolved that problem. And Ruby is back to a peaceful level as to the amount of process, the amount of CPU that it should be taking up. Transparency mode, I'm thumbs up on it. I like how you called that out, how that's a choice. And I'm with you on that choice, although I didn't realize that's broken. I guess I just hadn't...I guess I don't care deeply enough that I've tried to restore my transparency, but you're telling me to hold on.

+ +

CHRIS: We're going to get realer now in this moment. So I have a very old version of iTerm because it has a different way of going fullscreen than the default operating system level fullscreen. I really hate that it animates to fullscreen, and it doesn't quite fill the full screen. Like, it still had a border around it or something. So I have a very old version of iTerm that I've been running with forever, and I refuse to upgrade in any way as a result of I want to cling to this old version of things working. But as a result, I think I finally hit the end of the road on that. This is like years running now too.

+ +

I remember I kept it in a Dropbox folder so that each time I upgrade or get a new computer, I'm like, okay, good. I still have my old special version [chuckles] of iTerm. But I think that time is over and I got to find...I feel like there are new terminal emulators out there. It's like Alacritty and other stuff that people talk about. So maybe it's time for me to try and find something new as long as I can get that transparency because I want to feel like an uber lead hacksaw.

+ +

STEPH: You have such a brand of new-new that I'm now discovering that you are also a software hoarder, so you have both in your personality. [chuckles]

+ +

CHRIS: There was a period early on in my software career that was like, oh, I got to find all this stuff. I got to figure things out and configure it. And then I was like, wow, that's taking up a lot of my time, I should stop it. And I think since then, I haven't upgraded anything. If you go look at my .files, I don't know the last time I pushed to them, but it's been a while. I'm still doing things, of course, but not as much. I know the cost of it, and I know the cost of maintenance.

+ +

And really, this is an allegory for software overall. This isn't just about our local development environments, but entropy exists in software. Software does not exist at rest, and it will decay over time. And so the idea of we've worked with so many clients where they're like, yeah, we're on Ruby 1.8, and it's Rails 0.9. So okay, all right, well, we're going to have to deal with that, it turns out. We can't just keep ignoring that. So really, it's the same story played out but in my local hoarder cavern.

+ +

STEPH: There was a part of the saga, the story that you shared with the installer and that you don't have enough space, and it took up the rest of the space, and you can't do anything. I'm very nervous; what happened to your stuff, your space? How did that resolve? [chuckles]

+ +

CHRIS: I finally bit the bullet. And so I have a bunch of...I've tried a bunch of the different pieces of software that will visually analyze your disk space. So they crawl the whole directory starting from the very root of your computer, and it will be like, all right, applications has this much, and the library directory in your home directory has this much. Here are all of the different places that stuff might be hiding on your computer. And then you can visualize and be like, okay, that's where the most of it is.

+ +

Node modules, as an aside, we did not choose an efficient way to approach how to put code on my computer because Node modules take up a lot of space on my computer, but they're so spread out. Multiple times I've seen people share a version of rm -rf, and then it's some subshell that does find every Node modules directory underneath a code folder. So you can find every single Node module and just blow them away. That will regain you some space. But that was not the solution this time.

+ +

I've tried lots of piecemeal solutions over time. But eventually, the thing that got me there was just busting all of those caches. So I cleared the backup utility, Arq's cache. I cleared a bunch of them, Spotify Yarn, et cetera. And that cleared enough space for the installer to actually run. And then, once that was done, the installer program itself was no longer around, so I reclaimed that space. But it was this weird chicken and egg thing where I had to have enough space to complete the installation such that the installer could go away.

+ +

And now...actually, let me see what my hard drive looks like now. So somehow, according to the Macintosh hard drive info, I have 50 gigabytes of available space, which is really frustrating because there were a number of weeks where we went into a Bike Shed recording, and I was like, I have one gigabyte. I'm not safe right now because this audio is going to be more than that. And so I don't know how now I'm sitting at 50. I guess all those caches that I cleared and the installer being gone probably puts me in a good spot.

+ +

But anyway, I'm living in an upgraded, wonderful world. As an aside, Big Sur is ridiculously rounded and colorful and almost cartoonish. They're really leaning into the iOS vibes. And I'm not sure it's my personal aesthetic, but that's fine. I spend most of my time in the terminal anyway. But I think that's enough of me ranting about upgrading my operating system, which apparently I had a lot to say about. But what else is up in your world, Steph?

+ +

STEPH: I do appreciate the ranting, though. You're not often grumpy, and when you are, it's quite humorous. [laughs] I really enjoy the grumpiness. And it's often a painful process. So I appreciate all of that story.

+ +

Something that I really need to share with you and get off my chest is a couple; I don't know, x number of episodes back, you and I were talking about computer chairs. And I bragged about the fact that I have a computer chair that has no armrest, and I love it. I love my chairs like this, and it's wonderful. And I just think it's the best way to live.

+ +

And it turns out that that's bad because I happened to go see a massage therapist who's also very well-skilled in physical therapy and other areas. And they were talking to me about my desk setup. And I mentioned the fact that I get these typical headaches, and I have my chair, but there's no armrest. And they're like, "Oh, that would do it." I was like, "Why? I like my setup. What's wrong with it?" And they're like, "Well, if you don't have armrests, then your back is having to compensate and to hold up your arms and your shoulders all day. So while you're typing, you're using more muscles to then hold that. And then they eventually tighten and contract, and then that can cause headaches."

+ +

So in case, I have led anyone astray into having no armrest, they are apparently very important to not having headaches or having your back overworked to the point that you have headaches, which I'm a bit sad about. But on that front, I have ordered a new chair, and we'll see how it goes. I will have to assimilate into the world of chairs with armrests.

+ +

CHRIS: We welcome you with open armrests. [laughs] Sorry, I saw it, and then I went with it. Anyway, I'm realizing now I actually don't use the armrests on my chair per se. I actually end up putting my arms on the desk, which is probably not ideal either. I have a little wrist pad so that my wrists are brought up and so that I don't have the upward breaking of the wrist thing going on. I think that matters a lot. And then my arms are supported by the desk, but it is just right on the desk, and I wonder if that's worse. But I've never...I don't know, getting the armrests just right and then also having the wrist pad.

+ +

But I can't adjust my desk is probably the main problem. If I could bring my desk down a little bit, and if it were a thinner top, then I'd have more flexibility. The chair that I have is wonderful and has flexibility. The arms can go up and forward into the side and lumbar and this and that. And so I'm able to make the chair work to the desk. But I do wish I had more of an adjustable...ideally, like a stand-sit desk. But I haven't made that jump just yet.

+ +

STEPH: When you're ready to make that jump, I'm going to share with you where I bought my desk because I'm really happy with it. And it's also not nearly as expensive as most of the other desks that will go up and down.

+ +

CHRIS: Presumably, we can include it in the show notes as well so that we share it with everyone.

+ +

STEPH: Definitely, yeah.

+ +

CHRIS: Otherwise, that's just kind of mean. [laughs] You and I have a weird back channel that we talk about on the show, but they're not actually put in the show notes.

+ +

STEPH: We're not mean. We wouldn't do that. I love my desk. And it was from someone else. They're the ones that shared it with me, so I'm happy to pass it along because it has served me well. And yeah, I'm also not sure about how this is going to work with the chair and the armrest because I'm just worried they're going to be too wide, and they're not going to actually offer support. I have doubts. I have lots of doubts, but I'm willing to investigate. And we'll see how this goes because I would like for the headaches to stop.

+ +

CHRIS: Good luck on that front. That definitely seems like an indication of worth putting in some effort there.

+ +

STEPH: Agreed. I also have some other exciting news. Stephen Hanson at thoughtbot has organized a number of other thoughtboters to get together who are interested in really diving into leveling up, learning React, and specifically focusing on purchasing the Kent C. Dodd’s Epic React course. And it's for anyone that is comfortable writing code, whether you know React really well or if you're new to it. Everyone's welcome to join.

+ +

So we just kicked that off today where we're going to go through the course together and then meet every Friday. I think the cadence is probably three hours, three and a half hours every Friday, that then we're going to commit to working through the course together.

+ +

And I have to admit, I always nerd out a bit over how does someone build a course? Like, I'm really excited about the content as well, but I just want to know how did someone go about producing this content and then sharing it with everyone? And then what's their outline? How do they help people that are getting stuck because they can't be there in the same room? How do they record their videos?

+ +

So I'm really excited to see all the ways that Kent has crafted this workshop. And so far, there's so much content, but I'll have more to report as we really start to dive in. But I'm excited to revisit React because I haven't been in React land for at least a year and a half; it’s been a while. And so it's one of those areas that I know some bits, but a lot has also changed. And I would like to just revisit that world. So I'm really excited to dive into the course.

+ +

And so far, I really like the structure that Kent has taken with the curriculum where we're focusing first on what exactly is happening and all the effort that goes into if you wanted to actually write HTML and then layer on JavaScript on top of that. But then here's how React makes that easier for you. Here is how JSX makes it even easier on top of the React API. I really liked that. Here's some pain; feel a little bit of pain, let's get a little bit better. And then let's get even better on top of that. And that has been a really nice reminder and progression into the course.

+ +

CHRIS: I'm definitely a fan of the way you're describing it like, feel some pain, and then let's get better. But then, like, what's the hook? With any educational content, this is the sort of structure where there can be full education. But this is the thing that I feel very deeply about conference talks is my goal isn't to teach you everything if I'm giving a conference talk; it is just to get your attention just to say, "Here's the thing, here's why you might care." And starting from the problem, starting from the pain is always such a good way to do that. Because you know how this stuff is hard? What if I had an option that was easier? And then building from that totally makes sense.

+ +

I want to say that course, Kent's course was built in conjunction with the egghead team, egghead.io. And it's a distinctly branded course. But it was built on top of the framework in the platform that's there and all of that, and then some of the editing support. I don't know this for certain, but I think there was some teamwork there.

+ +

And I love just pushing forward the envelope of how we do educational content in the world of development because it is such an interesting world that has, frankly, such a need for ongoing development. The world is changing out from underneath us every two days. And therefore, having great educational content is so important. So yeah, definitely interested to hear how your experience goes both with the course and then also diving deeper into React.

+ +

Well, switching gears just a little bit, I had a topic that I wanted to dig into with you today. And so to give some context, the topic, the thing that we're going to be talking about today is what have we changed our mind about? So you and I have both done a little bit of thinking and tried to come up with some answers to this. The background, this was actually inspired by a tweet that I saw between Shawn Wang, aka "Swyx" on the internet, and Charity Majors, a recent guest here on this podcast.

+ +

And Charity is someone who is known for having strong opinions. But Shawn asked the question of what are some opinions that you've changed your mind about? And Charity actually had a wonderful list, which we'll link to her tweet thread where she shared some of her both technical and then also more personal ones, but really talking about the sort of evolution of thinking and the way someone's thoughts can change over time.

+ +

And I thought it was just such an interesting thing because, for most points in time, we experience someone's sort of snapshot of where are you at now? What do you believe to be true? But I think there's such an interesting story and sort of the arc there of what did you believe to be true that you don't anymore? What have you softened your beliefs on? What have you strengthened your beliefs on? So yeah, with that as the context, what have you changed your mind about, Steph?

+ +

STEPH: Yeah, this one really got me thinking, and I feel a little stumped on it. I have a few that I'm excited to share. But I'm very excited to hear your list to see if that also helps me reflect more on some of the things that I have changed my mind about. And I have found that there's only a couple maybe that I feel like I've really solidly changed my mind about. The others, I've either dialed up the strictness, or I've dialed it down. So the ones where I've really changed my mind about are feature flags and comments. Those are two of them. Well, there's a third one, but I'll get to that in a moment.

+ +

So starting with the first one, feature flags I was more in the camp where I very much appreciate feature flags, but I use them sparingly because then there is a tedious nature of introducing them and then having to clean them up, and then having to maintain two states of code. But now I've really seen the value of feature flags and how we can make sure that we have calm releases and ensuring that main is always in a deployable state. So feature flags is one for me. I'm very invested in having more of a robust feature flag system because I see the benefit to that.

+ +

The other one was comments. I used to be very rigid about comments are bad. We should never have comments in our code. They are just waiting to go out of date, and they're not going to be helpful. But I have since dialed down that strictness where I have certainly seen moments where comments do feel very helpful, and I can see how people use them. I still want to avoid them for the most part, but I am less strict now in regards to people who really find value in comments. I'm more open to that discussion. I want to understand what it is they find helpful about that comment, and if it is something that we can't capture with code or a test, where does that live?

+ +

CHRIS: Those are both interesting. Feature flags, for me, I think I actually was more strongly opposed in the beginning. Earlier on in my career, I saw them as added complexity, as noise. I often would encounter them left behind in a codebase. And so, I had this negative association with them. And I didn't see the value; I hadn't yet felt that pain. And over time, I've definitely shifted to where you're at where I'm like, I love feature flags. This is a critical tool in our toolset of how we actually…like you said, calm deploys, being able to always deploy main, making sure that we don't have long-running feature branches. There are so many benefits that come out of it that I'm now very strongly in favor of them. But it's interesting; I think I would say that I started in a more strongly opposed place. So that wasn't on my list, but it's an interesting one that you've brought up and probably one that I've moved more on.

+ +

Code comments, I think, actually started in my career being like, obviously, you comment your code. It's the thing that I read about and stuff. And slowly, over time, I think I've just dialed in on I don't think we should be doing that. There are, of course, going to be exceptions.

+ +

And actually, one of the things that I discovered about myself as I was trying to go through this exercise is there are very few things that I believe are black and white. If anything, that maybe is one of the things that I've leaned into over time. It's like, nothing is binary. Nothing is black and white. Everything is on a continuum or shades of gray. There are things that I believe a little more seriously. But there's almost nothing that I can be like, nope, absolutely I will not equivocate on this beyond how we interact with other humans and being reasonable, kind people. And in terms of software practices, not really. Comments, though, are one that I still am pretty strongly not going to lean into. So it's interesting that you're like, eh, I've kind of opened up to that one.

+ +

STEPH: There's a particular talk, The Art of Code Comments by Sarah Drasner, and that's the one that really shifted some of my opinions around comments, and then how we talk about them, and what benefits they can play. But I will admit, if I see a PR that has code comments, I still immediately have a negative reaction to that. And I want to have a conversation around why that comment was added and if we can remove it, and how we can remove it. But even with that negative perspective, I still find that I'm more open to that discussion versus before, where I would have been like, no, that's just unequivocally bad.

+ +

CHRIS: I do like that you always bring up that talk whenever we talk about comments. This is a great talk. And in the background, I just looked up Sarah's Twitter profile because every time you bring it up, then I mention that she has a still from the movie Labyrinth in her Twitter background, but she actually changed it. And so now that's not true anymore. It's now something from The Force Awakens. Well, it's actually a joke, but I'm still going to suggest that you watch the movie Labyrinth at some point. That's the thing that I feel actually kind of weird about. It's a weird movie.

+ +

STEPH: I'm going to take your suggestion, but not watch it. But thank you. [laughs] To share my truth today.

+ +

CHRIS: That's fair, that's fair.

+ +

STEPH: What are some of the things on your list?

+ +

CHRIS: Okay, I have a couple, some more on the technical. Let's lean into one of the technical ones. Early on, I started with dynamic languages. I think I started with Python primarily and a little bit of JavaScript. I eventually found my way to Ruby and felt very at home there. And then, I started to explore functional languages. And I started to lean into them really hard and felt that immutability and functional programming and true pure functional programming was the thing. It was the answer, and I just needed to figure out how to do it. And so I would say that is the belief that I have since changed my mind on and decided, you know what? Actually, it feels like a bit of a force fit. I have tried. And maybe for others, it is actually a really fantastic way to build software. But having worked with a number of other people in more functional contexts, I find that it is a bit of a force fit. It's a bit rough.

+ +

And in particular, of late, I've been working with Svelte as opposed to React, and React does sort of lean into the functional paradigm, especially with Hooks and all those sorts of things. And it's a little bit rough because it turns out UIs are these deeply mutable things. We're changing values or typing things in. There are actions that are changing the state over time, and having a system that just more directly models that feels very natural.

+ +

I still love functional programming for the more core of an application. So again, I reference this talk often, but Gary Bernhardt's Functional Core, Imperative Shell. Gary has really formed some of my thinkings on this. And now I've started to find the examples in the work that I'm doing of like, oh, okay, I see that pattern actually applied here. But much as I would love to use them, the functional languages I find just aren't quite landing for me. And additionally, the mutability, particularly in the front end right at the edge of the UI, is not quite as good of a fit.

+ +

STEPH: So I think that resonates with me although I do still get very excited about following more patterns that represent more immutable state just because I felt so much pain and found bugs from the fact that we have mutated state in surprising ways. I'm honestly not quite sure how I feel about it. I'm going to have to think on that one. That's a very interesting one that you've changed your mind on.

+ +

CHRIS: Yeah, similarly, my feelings are lukewarm, whereas before, they were stronger. I was like, oh, okay, I think I found something here. And then, in attempting to use it across a wide variety of applications, it just didn't quite feel right. I felt like I was swimming upstream sort of thing.

+ +

Actually, there is an interesting counterpoint. One thing that I have leaned into and definitely changed my mind on and embraced is static typing or, broadly, static analysis. But I think static typing being the most pointed version of that. Early on, like I said, I got my start in very dynamic languages in Ruby, and Python, and JavaScript. And so that dynamic duck typing runtime can be anything. We just make our systems respond to the messages, and all of that sounded great.

+ +

But it turns out I really love having a compiler that can tell me some truths about my program before it ever reaches runtime. And the idea that a typo can make it to production feels absurd at this point. And actually, as I'm working in Ruby, I'm like, man, I really got to go look at that whole Ruby typing thing we got going on. I don't know what the state of it is. I've looked at it in the past, and I need to revisit it soon. But like TypeScript, I've definitely embraced that very strongly. And I would not work without TypeScript in a JavaScript project at this point.

+ +

I've loved the work that I've done in Elm, although that also sort of blends into the functional stuff where it's like, it was a little bit noisy, though, I'll say that. But the type system and the fact that the compiler can give you so much rich information about your program, I would not trade that at this point. And I don't see myself going back on that front, which is an interesting place for me to be on of actually, I'm not that into the functional programming as the core way that I build my applications.

+ +

But I do like static typing. And I feel like functional programming and static typing actually go together incredibly well. And functional programming and, more imperative, whatever it is that I'm doing with my day-to-day life these days is a more interesting fit. But it is interesting to me to observe that sort of combination of opinions where I really like static typing, and having a compiler, and something that can tell me about my program before I get to runtime. But also saying that I don't quite want the functional programming thing, or at least not as the entire way that I modeled my application because I found it a bit difficult to work with. Because I think static typing or compilers and functional programming go really well together.

+ +

But I think generally, what I'm finding is a more middle ground dynamic optimization of a bunch of different things. And the answer is like, well, it depends which I guess if you've listened to the show before, you'll have heard those words said, so I guess it makes sense.

+ +

STEPH: Yeah. All of that makes sense to me. And I can see why you might have a favor for types or why that feels more valuable initially because that is giving us so much feedback right off the bat versus following a more functional paradigm is something that could feel like more of a force fit and doesn't provide that same immediate feedback. But it has a longer-term or a longer cycle of that reward system. So I can see why you might favor one over the other or why I myself would favor one over the other.

+ +

CHRIS: How do you feel about types?

+ +

STEPH: I'm a big fan, although I say that, but I work in Ruby. [laughs] I don't have them. But when I have worked with types, I very much enjoyed it because it makes me think more about the design of my code in a way that I don't as much with Ruby. And working with types has heavy influence than when I am working in Ruby and thinking about the design of my code. So I think working with types is a wonderful thing that, frankly, all of us should do as developers at some point because it is so influential. So I'm for types, but I'm not using types in my day-to-day.

+ +

Another thing that I have changed my mind about is how we structure the work that each person is doing. So I used to be more in the camp of everybody can work on their own very complicated piece of codebase, their own complicated feature. We can have a bunch of complicated things in the sprint, and everything will just be great; it’ll be fine. And we'll get a bunch of work done, and we'll ship it. And then we're an even more productive team.

+ +

And I very much disagree with that now where I have found where everybody is working in their own silo on a complicated feature has slowed down the progress of then being able to ship that feature. Because we often want to collaborate with someone, we need to collaborate with someone. Then the PR review process is tough if I really have no idea what you're working on, and I don't have a context that then when I look at your code, not only am I evaluating at the code level, but then I'm also trying to understand the feature and gain all of that context. And that's a heavy cost for me to have to pay to then pick all of that up and then for you to have to reintroduce me to what's happening. Or I might make the bigger mistake, and I may look at your code and just evaluate it from the code perspective but not really understand the feature, the value that's being delivered. And that doesn't feel useful.

+ +

And I have a recent example where that happened where someone was working on a very complicated feature that I didn't have any insight into. So then, when I was looking at the PR, it was easier for me to just look at the code and get feedback on that. But then it was probably a day or two later. It wasn't until then that I finally started asking, what are we building? Like, what purpose is this serving? And that opened up a much larger discussion where we realized what was being built didn't actually really deliver what we needed to deliver. So I no longer agree with the idea that everybody should be working on their own complicated features independently, and there should be some collaboration. And, you know, it's the buddy system; we all need a buddy.

+ +

CHRIS: Well, I like that one. I feel like I've shared similar ideas where it made sense. It was just the efficient thing to do, to split the work up and have everybody very independent. I also feel like earlier on in my career; I was more scared of Git conflicts and things like that or people interacting with the same parts of the code. And so in my mind, it made sense to really strongly separate like, oh, you shouldn't even be touching the controller for this. I'll handle the views, and you handle the controller; it'll be separate. And I care less about that now. And I think what you're saying of like, it's actually better if we have some shared context, and we understand what we're working on, and it's more of a collaborative process. Yeah, I like that one. I think I followed a similar arc, and I'm at a similar place now as well.

+ +

Interestingly, to go into another one of mine that I think you'll probably be most surprised by on my list is I think I used to believe in 10x engineers. I used to believe in the idea of that one developer just off in the corner fueled entirely by Mountain Dew that would just produce the perfect code. They would just solve it. Over the weekend, they would write the entire billing system, and it would be great. And I think it was predicated on the idea that the coding is the hard part, which I no longer believe. I think coding at its core is communication. It's taking this thing that we want to be true in the world and then communicating it to a computer but also ideally communicating it to our teammates, and to future versions of ourselves, such that we can revisit that code, we can maintain it over time, other people can add to or augment it.

+ +

And so the idea of this loner that can just do incredible volumes of work and have that be a good outcome that just doesn't make sense to me anymore. I've worked with incredibly talented developers, to be clear, folks that I was sort of in awe of. I've worked with people who have, I think, just truly photographic memories. They seem to remember every single bug that they've ever had and exactly where they can look it up. Or from the top of their head, they can just intuitively know, oh, this bug means this. Go look at this line of code. I'm like, how did you do that? How did you do that magic trick? And they're incredibly capable developers. But at the end of the day, the folks that I see being most impactful on a team are the folks that are able to communicate and collaborate most effectively and make the whole team more effective.

+ +

STEPH: Maybe it's the Mountain Dew; maybe that's actually the secret sauce here. That's what I'm missing from my life to take me into that status.

+ +

CHRIS: I'm now imagining Mountain Dew but in a more viscous form, like a barbecue sauce, but it's Mountain Dew flavored. That's the secret sauce because it's a very…anyway, moving on. [laughs]

+ +

STEPH: It's a terrible product. We should make it and sell it.

+ +

[laughter]

+ +

CHRIS: Career pivot, we now sell Mountain Dew sauce.

+ +

STEPH: [laughs]

+ +

CHRIS: But yeah, I do not believe in 10x engineers anymore. If anything, I believe that that is a huge warning sign if you have anyone that's behaving in something close to that space.

+ +

STEPH: Yeah, I'm super interested in that you've shared because I don't think...We've talked about 10xers, but we haven't talked about the fact that you used to think that they were more of a thing and that they existed. And now it's all I'm sorry, but it's all crap. [chuckles] That's super interesting to me. Do you remember what changed your mind? Do you remember that pivotal moment of where you were like, oh, maybe this is all bullshit?

+ +

CHRIS: I think it was just an amalgamation of experience over time. I've encountered people who fit the archetype. But if anything, I would say they're deeply problematic in teams. They're that individual who refuses to collaborate, who just goes off and heads down, writes a bunch of code, but then it doesn't integrate with the other pieces, or no one else knows how to use it, or they won't let anyone contribute to it. And yeah, I've seen that just be very, very problematic.

+ +

So the folks that most fit, I think the imagined version of this, actually end up, in my experience, leading things astray. And the folks that are actually most productive and really cause teams to improve in a drastic way behave very differently. They're much more collaborative; they’re much more engaged with the team. It's less about their individual contributions and it's more about building a system together, collaborating, communicating, engaging external stakeholders, et cetera, et cetera. It's all that stuff that matters. And so, it's very much in contrast to what the 10x engineer ethos is about. But there's no one day where suddenly this idea that I had in my head crumbled when I saw that behind the pile of Mountain Dew cans, there was nothing there. [laughs]

+ +

STEPH: It's all a mirage. [laughs] I do like what you just said around that there are very impressive people out there. And those impressive people often focus less on their individual contributions and more at a higher level around communication. And then they are the powerhouses that then is helping facilitate everybody else be their best and have high levels of individual contribution. Those are the ones that...I'm still not going to endorse a 10xer, but they are the ones who, to me, embody the idea of someone that is incredibly efficient and really good at their job.

+ +

CHRIS: There's an adage that comes to mind here that "If you want to go fast, go alone. If you want to go far, go together." And that does ring true to me. I think an individual can have their individual productivity be higher if they're working entirely on their own, if they understand every line of code because they wrote every single line of code if they know where every feature of the platform is integrated because they wrote the whole thing. But they're going to be fundamentally limited. And in order to do bigger, more complex things, fundamentally, we have to work as a team. And then the way you have to interact just fundamentally changes.

+ +

So I think it started from that, like, one person on their own I think can be individually more effective. But the minute you start to have a team, that one person acting on their own is actually dragging the team down because other people can't then work in that space, and that's a problem.

+ +

STEPH: I really like that adage that you just shared where, "If you want to go fast, go alone. If you want to go far, go together." And that touches on something else that I have really changed my mind about, and that's representation. And this is more specific to me. So when I joined engineering and became a web developer, and I joined a team, and I was the only female engineer on that team, my initial feelings were I am the only female engineer, and that is fine. We're all just a group of engineers. We're here to solve problems together. It really doesn't matter if there's anyone here on this team that's like me. It's fine if there's no one that I can see myself in that's in leadership because we're all just people, is what I was coming down to. And I've completely changed my mind and realized that that's not true.

+ +

And I've experienced this where I've worked on other engineering teams with female engineers, and it's fucking awesome, and it does make a difference. And then when I can see someone that I can see myself in, in a leadership position, that is also inspiring. So that is something that I went in where I think it was more of I was trying to shield myself from the idea that I am different from everybody else in this room, and that could be a problem. And instead, I just tried to neutralize it by saying it's not.

+ +

But I think representation is incredibly important. People are not just people. We all have very important social and racial, and cultural identities. And it's very important that we get to feel that we can express all of those identities and see people that represent those identities in spaces where we would like to go. That's a big one that I've changed my mind on.

+ +

CHRIS: Yeah, I certainly agree that representation certainly matters, and being able to bring your full authentic self to work and seeing others around you that reflect that. And frankly, having teams that are made up of people that represent the users of the software that we're building feels so critically important. And it's very interesting to hear about the arc that you've had on that where initially, you tried to downplay it, but then you found a little more truth in it. And so yeah, thank you for sharing.

+ +

STEPH: You're welcome. It feels good to say that, too, because that's something that I've admitted and realized on my own, that that is something that has changed and shifted. But it's nice to be able to share that here with you as we're going through the things that we've changed our mind about. What else is on your list?

+ +

CHRIS: Well, to round us off with one more very technical version because, of course, that's where I'm going to take us after a much deeper and more nuanced topic that you led us on, single-page applications. Broadly, I'm opposed to the name; that’s a side conversation. But, man, URLs matter on the internet. So don't call them single-page applications, but client-side applications or whatever. Broadly, the idea of a bundle of JavaScript, and so you send down an empty HTML document, and then you reference a bundle of JavaScript, which that thing boots up and it then makes a bunch of API requests to the backend, and then it starts to fill in the page.

+ +

I was convinced for a while that this is a reasonable and perhaps even necessary way to build software. We need APIs for our mobile apps anyway. So if we're doing that, then let's have that be the consistent way that we are accessing information. This is going to be fine; it's not a problem. And then eventually, we found some problems. So then we got GraphQL, and we tried to solve it that way. But overall…and I have spent a lot of time trying to make this thing work, trying to find a version of this that I'm happy with that I find the end outcome of the software to be as pleasant to work with from an end-user perspective as a server-driven application, and I can't find it.

+ +

And so, to be clear, I'm still doing client-rendered applications these days. But Inertia.js is the framework that I've leaned into that helps me bridge that gap. And the idea that the server owns routing, that the server owns statefulness, things like that, not having to think about client-side routing, not having to think about client-side state management, being able to use traditional auth mechanisms built into cookies, all of these familiar things that we've had. Leveraging the fact that the server is the more privileged in terms of the information it has access to, the more secure, the more powerful environment, all of these things feel right to me. And the nature of the application that I can build just feels more robust, more consistent, easier to evolve.

+ +

There were a lot of promises that I heard when we started building applications in these ways. And I just haven't seen an example or have not worked on an example, at least of an application that is built as a client-side bundle that boots up and does some stuff and had a good experience with that. So Inertia, as an aside, is my answer to this. And I continue to be extremely happy with that as a solution, as really a middle-ground solution. Because going all the way back to true HTML server-side rendering is limiting in other ways that I didn't like. But I find that Inertia really strikes an ideal balance in the middle there.

+ +

STEPH: I feel like I completely agree with everything you're saying. But I also feel like I have a developer secret to share where I really haven't worked on single-page applications, and I am okay with that. [laughs]

+ +

CHRIS: It's fine, skip it. Just go straight to Inertia. It's better.

+ +

STEPH: Cool, cool, cool. I am working on leveling up React, and then the plan is to go to Svelte and Inertia. So I'll just completely...I'll skip that. I'll skip that part of my career.

+ +

CHRIS: I actually want to back up just a little bit as I'm saying this because I really try to avoid being in a more negative space. And I think this space, this architecture for building applications, is complex, and there are things that will warrant it. So things like Google Maps, it makes sense to have a lot of Dynamic JavaScript and to be doing complex things on the client-side. Trello is another example of an application that that as a server-rendered thing, doesn't really make sense. And frankly, using a tool like Inertia wouldn't quite work there. That said, that is, in my mind, truly a single page within the broader application. So the Trello board page is a very, very complex stateful application, and I think modeling it as such makes sense. Google Maps, similar. But there's still the profile page, and the login page, and all of these other things.

+ +

I think routing is probably where it breaks down for me. I think client-side routing is the thing that I feel the most pain on. Because at the end of the day, the server still needs to know the answer. And if we do client-side routing, we end up with this duplication of logic across the client and the server-side. We end up with disagreements from time to time. We end up with the weird flashes of half-rendered layout, and then we go to the login page because we get an API response that is different. And so, I think that is probably the kernel of the thing that I struggle with. And, of course, it is possible to build great things using any of these technologies.

+ +

But I think my summary is I've really tried on that front, and I've just not been able to make the fidelity of application that I want using…primarily; I’d say it's client-side routing is the thing that I struggle with the most.

+ +

STEPH: Yeah, it sounds like you're saying there are very valid use cases for using a single-page app or following that structure. But we haven't really gotten there in terms of our web development expertise, where we've made that easier to maintain and easier to implement. And there's still enough pain points around it that even though it seems like a very valid idea and approach, it still feels painful enough that you actively avoid it until it feels like something that you have to then invest in at that point to then really deliver the user experience that you want to provide.

+ +

CHRIS: Yeah, I think that's an accurate summary. And I think adding on to that, I’m noticing it becoming more and more of the standard approach; this is the way we build applications, and I don't agree with that. That is probably the thing that is the kernel of what I don't believe in. I think actually server rendering is a great way to start, and then you can slowly augment or move more things into complex client-side behavior. But starting with this as the mode that we're building our applications just feels like a less stable foundation than I would want. So it's perhaps an architecture that you want to evolve to at some point as the complexity necessitates it, but I definitely wouldn't be starting there. Similar to service-oriented architecture, not going to start there. Client-side routing, I'm not going to start there.

+ +

STEPH: Ooph. I feel like I've been holding my breath this episode. I feel like this was a very interesting topic that has been challenging to reflect on what we believe and what we've changed our mind about.

+ +

CHRIS: I think it's perhaps more nuanced than a lot of our episodes where often we're saying this is what we did, and this is how we felt in the moment. And that can be very experiential and true. But this, yeah, we had to draw the line in the sand and say what do we believe? I similarly definitely feel more tension in this episode than other ones. But hopefully, it was useful. Hopefully, folks found some value in the things, and hearing our story, also, the idea that we have singular formed opinions. Hopefully, this episode has broken that idea in anyone's head. And we're all on a journey.

+ +

STEPH: I really like how this has prompted me to reflect on the things that I used to hold dear and really cherish or follow strictly to then reflect on what are things that I used to believe versus what I believe now? Because that transition often happens so seamlessly for me that I don't really stop to think about it to be like, oh, something just happened that is really changing how I approach things, how I build, how I work with teams. And I really like this reflection point to be like, oh, what did I used to believe, and what's different today? I'd like to keep this practice going and just try to track the things...I'll have to make a list of all the things I believe. That seems like an easy list. [laughs]

+ +

CHRIS: Just the easiest list to write.

+ +

STEPH: The easiest list to write. And then I'll just check in with it every so often, scratch stuff out, or update it with the things that have changed my mind about. This is the good idea, terrible idea where you go, "Stephanie, that's a terrible idea." [laughs]

+ +

CHRIS: I don't know, write it down on a list, and then look at it in six months and see if it sounds like a good idea, and then we'll be able to close the loop on the whole thing. But with that, should we wrap up?

+ +

STEPH: Let's wrap up. I've got a list to write.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshedor reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + In this episode, Steph and Chris talk about things they've changed their minds about over the course of their careers as software developers. Steph talks about as it turns out, arm chair rests are good, feature flags and comments are also good, she's changed her mind about how teams structure the work that each person is doing at once, and believes strongly in representation in the field.

+ +

Chris is not a fan up upgrading his operating system and when he first started out, he gravitated towards learning dynamic languages, and since then, much prefers functional languages, static typing or more broadly, static analysis. He also no longer believes in the 10x engineer, and also very much believes that URLs matter on the internet. So basically, don't call them single-page applications; call them client-side applications instead!

+ + + +

Transcript:

+ +

CHRIS: I still have dreams that I missed an entire semester of math class, and now it's time for the final. I don't know that I'm ever going to grow out of that.

+ +

STEPH: That's wild.

+ +

CHRIS: You don't experience that? It's a mixture of I'm in elementary school, but it's a college final. Like, the physical school that I'm in is my elementary school, but it's a calculus college course that I missed. And now it's time for the final, and I won't graduate college as a result. But it's also high school at the same time. Just every part of education sort of melded together into this nightmare scenario. Do you not experience that? I thought this was normal.

+ +

STEPH: [chuckles] Not in a very long time, not since I was in college. But I'm imagining this very cute, young Chris showing up with a backpack to the calculus final like, "Oh no." [laughs]

+ +

CHRIS: Yeah, pretty much, yeah. I really thought I would grow out of it at some point. But it shows...I think it manifests when I have anxiety about something else in the world, and then I have a math terror dream.

+ +

STEPH: That's your stress sign. That's your terror dream.

+ +

CHRIS: Apparently.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week going?

+ +

CHRIS: Oh, it's going fine. Yeah, I'll go with fine. I had to upgrade my operating system. Enough things had stopped working or seemed to be pestering me about it regularly, which normally I'm going to ignore that for as long as I can. That's sort of where I'm at in the world these days. Like, I don't want to upgrade because I don't know what's going to break and whatnot, but then things had broken already.

+ +

Text messages were no longer showing up on my computer. And it turns out that the primary way that I interact with text messages is by replying to them through my computer. I don't want to type on my phone, that's not a thing. I'm already grumpy enough about text messages, to begin with, that I will regularly respond switching to email, and then I'll go off from there. But yeah, they stopped working, it stopped connecting.

+ +

And then I got this really weird message from Apple when I tried to sign in. And I was like, I feel like I should at least try to upgrade to the new operating system, which I think has been out for a long time, and I've just been ignoring it. But then I had the added problem of I didn't have enough space on my computer to install it, which I tried once before.

+ +

So I downloaded the installer, but the installer downloader doesn't check whether or not you have enough space to do the install. So it's just like, hey, so you know how you didn't have enough space? Well, we took up the remainder of it, and now you can't do anything about it. And the installer is hidden somewhere in the computer. So at one point, it just went away, and then suddenly had a lot of space on my computer. But finally, I decided to bite the bullet.

+ +

I found a bunch of caches on my computer. So there was a cache for my backup utility, which is called Arq, A-R-Q, which was a lot of space. It was like 20 gigs or something like that. So it was like, sorry, you have no more cache. I'm pretty sure my computer's going to light on fire the next time it tries to do a backup because it has no cache to rely on, and it's got to try a lot harder, pull a lot more data down. I don't know what it does, but whatever. It's going to do that.

+ +

And then, I found the more general application caches on the computer. Spotify had like six gigs of cache. Well, what are you doing? Aren't you streaming from the internet? Stop it. That's not okay. That is not acceptable. Yarn had three gigs. I was like, what is everybody doing? And I busted all of these. I threw away everything, and my computer seems to be doing fine after the fact. So, were the caches even doing anything? I ask.

+ +

Anyway, so I upgraded, and then some stuff didn't work. And so then I had to find the versions to make stuff work. The particular one that stood out was Karabiner-Elements, which I used to make my mechanical keyboard do the right things for the function keys. That stopped working. And I tried to upgrade it to the newer version because I figured okay; they probably hopefully released a new version, but it failed in the upgrade process.

+ +

And it turns out the secret was I had to upgrade to an intermediate version. I was on 12.3, and I needed to go to 13.4. But in between, I had to go to 12.10. And if I went to 12.10, then the upgrade to 13...everything about it was everything that I hate about upgrading software. It's like, I just know it's working right now, and I feel like if I even just look at it wrong, this whole tower of software is going to fall over.

+ +

The worst thing, the thing that I have not been able to fix, is now I use iTerm as my terminal, my terminal emulator as it were. And I typically run with transparency mode on which some people look at and say, "Wow, that's a choice." And I say, "I kind of like it. I don't know; it makes me feel like a hacker or something." I don't know, whatever. [chuckles] Let me live my life. But for some reason, switching to Big Sur, the version of OS X that I'm on now, iTerm doesn't have transparency anymore. And I just haven't been bothered to fix it yet.

+ +

But, man, I got rambly. I clearly have some feelings about upgrading software.

+ +

STEPH: You have so many feelings. The fact that you kept going...People can't see me, but I'm just dying because of that whole story. [laughs]

+ +

CHRIS: I kind of felt like I had to get through it. I had to exorcise the demons, tell my tale, and then be done with it, which I think I'm at now.

+ +

STEPH: When I start laughing that hard, [laughs] I try to hide from the camera view because I want you to keep going for people to listen.

+ +

CHRIS: But what's fun is you bob and weave. You'll hide for a minute, and then you'll come back and be like, okay, I'm composed, never mind. And then you'll just fade off to the side again. So yeah, but I powered through. [laughs]

+ +

STEPH: Oh, all right, there is so much there. [laughs] Upgrading is the worst. I agree with that. That was actually something I ran into earlier this week. Well, it was a mix of where upgrading presented a problem and then upgrading something else resolved that problem. And so that was an adventure where I shared a tweet. I can link to it in the show notes as well.

+ +

But Ruby was just taking up 100%, a full core, just all the time, and I couldn't figure out why. I wasn't doing anything with Ruby. We weren't talking at the moment, but it was just turning up one of those 100% CPU or higher. And so then I did some searching. And I did find the resolution, which was to upgrade the Listen gem because there was something in the Listen gem that didn't fully support Big Sur. Is that the name of the thing that I am on?

+ +

CHRIS: That's the new one, yeah. I know because I've just upgraded to it. I have thoughts on the matter. [chuckles]

+ +

STEPH: Cool. [chuckles] Yeah, when I upgraded to Big Sur. But then someone had kindly marched in to fix it, then upgrading resolved that problem. And Ruby is back to a peaceful level as to the amount of process, the amount of CPU that it should be taking up. Transparency mode, I'm thumbs up on it. I like how you called that out, how that's a choice. And I'm with you on that choice, although I didn't realize that's broken. I guess I just hadn't...I guess I don't care deeply enough that I've tried to restore my transparency, but you're telling me to hold on.

+ +

CHRIS: We're going to get realer now in this moment. So I have a very old version of iTerm because it has a different way of going fullscreen than the default operating system level fullscreen. I really hate that it animates to fullscreen, and it doesn't quite fill the full screen. Like, it still had a border around it or something. So I have a very old version of iTerm that I've been running with forever, and I refuse to upgrade in any way as a result of I want to cling to this old version of things working. But as a result, I think I finally hit the end of the road on that. This is like years running now too.

+ +

I remember I kept it in a Dropbox folder so that each time I upgrade or get a new computer, I'm like, okay, good. I still have my old special version [chuckles] of iTerm. But I think that time is over and I got to find...I feel like there are new terminal emulators out there. It's like Alacritty and other stuff that people talk about. So maybe it's time for me to try and find something new as long as I can get that transparency because I want to feel like an uber lead hacksaw.

+ +

STEPH: You have such a brand of new-new that I'm now discovering that you are also a software hoarder, so you have both in your personality. [chuckles]

+ +

CHRIS: There was a period early on in my software career that was like, oh, I got to find all this stuff. I got to figure things out and configure it. And then I was like, wow, that's taking up a lot of my time, I should stop it. And I think since then, I haven't upgraded anything. If you go look at my .files, I don't know the last time I pushed to them, but it's been a while. I'm still doing things, of course, but not as much. I know the cost of it, and I know the cost of maintenance.

+ +

And really, this is an allegory for software overall. This isn't just about our local development environments, but entropy exists in software. Software does not exist at rest, and it will decay over time. And so the idea of we've worked with so many clients where they're like, yeah, we're on Ruby 1.8, and it's Rails 0.9. So okay, all right, well, we're going to have to deal with that, it turns out. We can't just keep ignoring that. So really, it's the same story played out but in my local hoarder cavern.

+ +

STEPH: There was a part of the saga, the story that you shared with the installer and that you don't have enough space, and it took up the rest of the space, and you can't do anything. I'm very nervous; what happened to your stuff, your space? How did that resolve? [chuckles]

+ +

CHRIS: I finally bit the bullet. And so I have a bunch of...I've tried a bunch of the different pieces of software that will visually analyze your disk space. So they crawl the whole directory starting from the very root of your computer, and it will be like, all right, applications has this much, and the library directory in your home directory has this much. Here are all of the different places that stuff might be hiding on your computer. And then you can visualize and be like, okay, that's where the most of it is.

+ +

Node modules, as an aside, we did not choose an efficient way to approach how to put code on my computer because Node modules take up a lot of space on my computer, but they're so spread out. Multiple times I've seen people share a version of rm -rf, and then it's some subshell that does find every Node modules directory underneath a code folder. So you can find every single Node module and just blow them away. That will regain you some space. But that was not the solution this time.

+ +

I've tried lots of piecemeal solutions over time. But eventually, the thing that got me there was just busting all of those caches. So I cleared the backup utility, Arq's cache. I cleared a bunch of them, Spotify Yarn, et cetera. And that cleared enough space for the installer to actually run. And then, once that was done, the installer program itself was no longer around, so I reclaimed that space. But it was this weird chicken and egg thing where I had to have enough space to complete the installation such that the installer could go away.

+ +

And now...actually, let me see what my hard drive looks like now. So somehow, according to the Macintosh hard drive info, I have 50 gigabytes of available space, which is really frustrating because there were a number of weeks where we went into a Bike Shed recording, and I was like, I have one gigabyte. I'm not safe right now because this audio is going to be more than that. And so I don't know how now I'm sitting at 50. I guess all those caches that I cleared and the installer being gone probably puts me in a good spot.

+ +

But anyway, I'm living in an upgraded, wonderful world. As an aside, Big Sur is ridiculously rounded and colorful and almost cartoonish. They're really leaning into the iOS vibes. And I'm not sure it's my personal aesthetic, but that's fine. I spend most of my time in the terminal anyway. But I think that's enough of me ranting about upgrading my operating system, which apparently I had a lot to say about. But what else is up in your world, Steph?

+ +

STEPH: I do appreciate the ranting, though. You're not often grumpy, and when you are, it's quite humorous. [laughs] I really enjoy the grumpiness. And it's often a painful process. So I appreciate all of that story.

+ +

Something that I really need to share with you and get off my chest is a couple; I don't know, x number of episodes back, you and I were talking about computer chairs. And I bragged about the fact that I have a computer chair that has no armrest, and I love it. I love my chairs like this, and it's wonderful. And I just think it's the best way to live.

+ +

And it turns out that that's bad because I happened to go see a massage therapist who's also very well-skilled in physical therapy and other areas. And they were talking to me about my desk setup. And I mentioned the fact that I get these typical headaches, and I have my chair, but there's no armrest. And they're like, "Oh, that would do it." I was like, "Why? I like my setup. What's wrong with it?" And they're like, "Well, if you don't have armrests, then your back is having to compensate and to hold up your arms and your shoulders all day. So while you're typing, you're using more muscles to then hold that. And then they eventually tighten and contract, and then that can cause headaches."

+ +

So in case, I have led anyone astray into having no armrest, they are apparently very important to not having headaches or having your back overworked to the point that you have headaches, which I'm a bit sad about. But on that front, I have ordered a new chair, and we'll see how it goes. I will have to assimilate into the world of chairs with armrests.

+ +

CHRIS: We welcome you with open armrests. [laughs] Sorry, I saw it, and then I went with it. Anyway, I'm realizing now I actually don't use the armrests on my chair per se. I actually end up putting my arms on the desk, which is probably not ideal either. I have a little wrist pad so that my wrists are brought up and so that I don't have the upward breaking of the wrist thing going on. I think that matters a lot. And then my arms are supported by the desk, but it is just right on the desk, and I wonder if that's worse. But I've never...I don't know, getting the armrests just right and then also having the wrist pad.

+ +

But I can't adjust my desk is probably the main problem. If I could bring my desk down a little bit, and if it were a thinner top, then I'd have more flexibility. The chair that I have is wonderful and has flexibility. The arms can go up and forward into the side and lumbar and this and that. And so I'm able to make the chair work to the desk. But I do wish I had more of an adjustable...ideally, like a stand-sit desk. But I haven't made that jump just yet.

+ +

STEPH: When you're ready to make that jump, I'm going to share with you where I bought my desk because I'm really happy with it. And it's also not nearly as expensive as most of the other desks that will go up and down.

+ +

CHRIS: Presumably, we can include it in the show notes as well so that we share it with everyone.

+ +

STEPH: Definitely, yeah.

+ +

CHRIS: Otherwise, that's just kind of mean. [laughs] You and I have a weird back channel that we talk about on the show, but they're not actually put in the show notes.

+ +

STEPH: We're not mean. We wouldn't do that. I love my desk. And it was from someone else. They're the ones that shared it with me, so I'm happy to pass it along because it has served me well. And yeah, I'm also not sure about how this is going to work with the chair and the armrest because I'm just worried they're going to be too wide, and they're not going to actually offer support. I have doubts. I have lots of doubts, but I'm willing to investigate. And we'll see how this goes because I would like for the headaches to stop.

+ +

CHRIS: Good luck on that front. That definitely seems like an indication of worth putting in some effort there.

+ +

STEPH: Agreed. I also have some other exciting news. Stephen Hanson at thoughtbot has organized a number of other thoughtboters to get together who are interested in really diving into leveling up, learning React, and specifically focusing on purchasing the Kent C. Dodd’s Epic React course. And it's for anyone that is comfortable writing code, whether you know React really well or if you're new to it. Everyone's welcome to join.

+ +

So we just kicked that off today where we're going to go through the course together and then meet every Friday. I think the cadence is probably three hours, three and a half hours every Friday, that then we're going to commit to working through the course together.

+ +

And I have to admit, I always nerd out a bit over how does someone build a course? Like, I'm really excited about the content as well, but I just want to know how did someone go about producing this content and then sharing it with everyone? And then what's their outline? How do they help people that are getting stuck because they can't be there in the same room? How do they record their videos?

+ +

So I'm really excited to see all the ways that Kent has crafted this workshop. And so far, there's so much content, but I'll have more to report as we really start to dive in. But I'm excited to revisit React because I haven't been in React land for at least a year and a half; it’s been a while. And so it's one of those areas that I know some bits, but a lot has also changed. And I would like to just revisit that world. So I'm really excited to dive into the course.

+ +

And so far, I really like the structure that Kent has taken with the curriculum where we're focusing first on what exactly is happening and all the effort that goes into if you wanted to actually write HTML and then layer on JavaScript on top of that. But then here's how React makes that easier for you. Here is how JSX makes it even easier on top of the React API. I really liked that. Here's some pain; feel a little bit of pain, let's get a little bit better. And then let's get even better on top of that. And that has been a really nice reminder and progression into the course.

+ +

CHRIS: I'm definitely a fan of the way you're describing it like, feel some pain, and then let's get better. But then, like, what's the hook? With any educational content, this is the sort of structure where there can be full education. But this is the thing that I feel very deeply about conference talks is my goal isn't to teach you everything if I'm giving a conference talk; it is just to get your attention just to say, "Here's the thing, here's why you might care." And starting from the problem, starting from the pain is always such a good way to do that. Because you know how this stuff is hard? What if I had an option that was easier? And then building from that totally makes sense.

+ +

I want to say that course, Kent's course was built in conjunction with the egghead team, egghead.io. And it's a distinctly branded course. But it was built on top of the framework in the platform that's there and all of that, and then some of the editing support. I don't know this for certain, but I think there was some teamwork there.

+ +

And I love just pushing forward the envelope of how we do educational content in the world of development because it is such an interesting world that has, frankly, such a need for ongoing development. The world is changing out from underneath us every two days. And therefore, having great educational content is so important. So yeah, definitely interested to hear how your experience goes both with the course and then also diving deeper into React.

+ +

Well, switching gears just a little bit, I had a topic that I wanted to dig into with you today. And so to give some context, the topic, the thing that we're going to be talking about today is what have we changed our mind about? So you and I have both done a little bit of thinking and tried to come up with some answers to this. The background, this was actually inspired by a tweet that I saw between Shawn Wang, aka "Swyx" on the internet, and Charity Majors, a recent guest here on this podcast.

+ +

And Charity is someone who is known for having strong opinions. But Shawn asked the question of what are some opinions that you've changed your mind about? And Charity actually had a wonderful list, which we'll link to her tweet thread where she shared some of her both technical and then also more personal ones, but really talking about the sort of evolution of thinking and the way someone's thoughts can change over time.

+ +

And I thought it was just such an interesting thing because, for most points in time, we experience someone's sort of snapshot of where are you at now? What do you believe to be true? But I think there's such an interesting story and sort of the arc there of what did you believe to be true that you don't anymore? What have you softened your beliefs on? What have you strengthened your beliefs on? So yeah, with that as the context, what have you changed your mind about, Steph?

+ +

STEPH: Yeah, this one really got me thinking, and I feel a little stumped on it. I have a few that I'm excited to share. But I'm very excited to hear your list to see if that also helps me reflect more on some of the things that I have changed my mind about. And I have found that there's only a couple maybe that I feel like I've really solidly changed my mind about. The others, I've either dialed up the strictness, or I've dialed it down. So the ones where I've really changed my mind about are feature flags and comments. Those are two of them. Well, there's a third one, but I'll get to that in a moment.

+ +

So starting with the first one, feature flags I was more in the camp where I very much appreciate feature flags, but I use them sparingly because then there is a tedious nature of introducing them and then having to clean them up, and then having to maintain two states of code. But now I've really seen the value of feature flags and how we can make sure that we have calm releases and ensuring that main is always in a deployable state. So feature flags is one for me. I'm very invested in having more of a robust feature flag system because I see the benefit to that.

+ +

The other one was comments. I used to be very rigid about comments are bad. We should never have comments in our code. They are just waiting to go out of date, and they're not going to be helpful. But I have since dialed down that strictness where I have certainly seen moments where comments do feel very helpful, and I can see how people use them. I still want to avoid them for the most part, but I am less strict now in regards to people who really find value in comments. I'm more open to that discussion. I want to understand what it is they find helpful about that comment, and if it is something that we can't capture with code or a test, where does that live?

+ +

CHRIS: Those are both interesting. Feature flags, for me, I think I actually was more strongly opposed in the beginning. Earlier on in my career, I saw them as added complexity, as noise. I often would encounter them left behind in a codebase. And so, I had this negative association with them. And I didn't see the value; I hadn't yet felt that pain. And over time, I've definitely shifted to where you're at where I'm like, I love feature flags. This is a critical tool in our toolset of how we actually…like you said, calm deploys, being able to always deploy main, making sure that we don't have long-running feature branches. There are so many benefits that come out of it that I'm now very strongly in favor of them. But it's interesting; I think I would say that I started in a more strongly opposed place. So that wasn't on my list, but it's an interesting one that you've brought up and probably one that I've moved more on.

+ +

Code comments, I think, actually started in my career being like, obviously, you comment your code. It's the thing that I read about and stuff. And slowly, over time, I think I've just dialed in on I don't think we should be doing that. There are, of course, going to be exceptions.

+ +

And actually, one of the things that I discovered about myself as I was trying to go through this exercise is there are very few things that I believe are black and white. If anything, that maybe is one of the things that I've leaned into over time. It's like, nothing is binary. Nothing is black and white. Everything is on a continuum or shades of gray. There are things that I believe a little more seriously. But there's almost nothing that I can be like, nope, absolutely I will not equivocate on this beyond how we interact with other humans and being reasonable, kind people. And in terms of software practices, not really. Comments, though, are one that I still am pretty strongly not going to lean into. So it's interesting that you're like, eh, I've kind of opened up to that one.

+ +

STEPH: There's a particular talk, The Art of Code Comments by Sarah Drasner, and that's the one that really shifted some of my opinions around comments, and then how we talk about them, and what benefits they can play. But I will admit, if I see a PR that has code comments, I still immediately have a negative reaction to that. And I want to have a conversation around why that comment was added and if we can remove it, and how we can remove it. But even with that negative perspective, I still find that I'm more open to that discussion versus before, where I would have been like, no, that's just unequivocally bad.

+ +

CHRIS: I do like that you always bring up that talk whenever we talk about comments. This is a great talk. And in the background, I just looked up Sarah's Twitter profile because every time you bring it up, then I mention that she has a still from the movie Labyrinth in her Twitter background, but she actually changed it. And so now that's not true anymore. It's now something from The Force Awakens. Well, it's actually a joke, but I'm still going to suggest that you watch the movie Labyrinth at some point. That's the thing that I feel actually kind of weird about. It's a weird movie.

+ +

STEPH: I'm going to take your suggestion, but not watch it. But thank you. [laughs] To share my truth today.

+ +

CHRIS: That's fair, that's fair.

+ +

STEPH: What are some of the things on your list?

+ +

CHRIS: Okay, I have a couple, some more on the technical. Let's lean into one of the technical ones. Early on, I started with dynamic languages. I think I started with Python primarily and a little bit of JavaScript. I eventually found my way to Ruby and felt very at home there. And then, I started to explore functional languages. And I started to lean into them really hard and felt that immutability and functional programming and true pure functional programming was the thing. It was the answer, and I just needed to figure out how to do it. And so I would say that is the belief that I have since changed my mind on and decided, you know what? Actually, it feels like a bit of a force fit. I have tried. And maybe for others, it is actually a really fantastic way to build software. But having worked with a number of other people in more functional contexts, I find that it is a bit of a force fit. It's a bit rough.

+ +

And in particular, of late, I've been working with Svelte as opposed to React, and React does sort of lean into the functional paradigm, especially with Hooks and all those sorts of things. And it's a little bit rough because it turns out UIs are these deeply mutable things. We're changing values or typing things in. There are actions that are changing the state over time, and having a system that just more directly models that feels very natural.

+ +

I still love functional programming for the more core of an application. So again, I reference this talk often, but Gary Bernhardt's Functional Core, Imperative Shell. Gary has really formed some of my thinkings on this. And now I've started to find the examples in the work that I'm doing of like, oh, okay, I see that pattern actually applied here. But much as I would love to use them, the functional languages I find just aren't quite landing for me. And additionally, the mutability, particularly in the front end right at the edge of the UI, is not quite as good of a fit.

+ +

STEPH: So I think that resonates with me although I do still get very excited about following more patterns that represent more immutable state just because I felt so much pain and found bugs from the fact that we have mutated state in surprising ways. I'm honestly not quite sure how I feel about it. I'm going to have to think on that one. That's a very interesting one that you've changed your mind on.

+ +

CHRIS: Yeah, similarly, my feelings are lukewarm, whereas before, they were stronger. I was like, oh, okay, I think I found something here. And then, in attempting to use it across a wide variety of applications, it just didn't quite feel right. I felt like I was swimming upstream sort of thing.

+ +

Actually, there is an interesting counterpoint. One thing that I have leaned into and definitely changed my mind on and embraced is static typing or, broadly, static analysis. But I think static typing being the most pointed version of that. Early on, like I said, I got my start in very dynamic languages in Ruby, and Python, and JavaScript. And so that dynamic duck typing runtime can be anything. We just make our systems respond to the messages, and all of that sounded great.

+ +

But it turns out I really love having a compiler that can tell me some truths about my program before it ever reaches runtime. And the idea that a typo can make it to production feels absurd at this point. And actually, as I'm working in Ruby, I'm like, man, I really got to go look at that whole Ruby typing thing we got going on. I don't know what the state of it is. I've looked at it in the past, and I need to revisit it soon. But like TypeScript, I've definitely embraced that very strongly. And I would not work without TypeScript in a JavaScript project at this point.

+ +

I've loved the work that I've done in Elm, although that also sort of blends into the functional stuff where it's like, it was a little bit noisy, though, I'll say that. But the type system and the fact that the compiler can give you so much rich information about your program, I would not trade that at this point. And I don't see myself going back on that front, which is an interesting place for me to be on of actually, I'm not that into the functional programming as the core way that I build my applications.

+ +

But I do like static typing. And I feel like functional programming and static typing actually go together incredibly well. And functional programming and, more imperative, whatever it is that I'm doing with my day-to-day life these days is a more interesting fit. But it is interesting to me to observe that sort of combination of opinions where I really like static typing, and having a compiler, and something that can tell me about my program before I get to runtime. But also saying that I don't quite want the functional programming thing, or at least not as the entire way that I modeled my application because I found it a bit difficult to work with. Because I think static typing or compilers and functional programming go really well together.

+ +

But I think generally, what I'm finding is a more middle ground dynamic optimization of a bunch of different things. And the answer is like, well, it depends which I guess if you've listened to the show before, you'll have heard those words said, so I guess it makes sense.

+ +

STEPH: Yeah. All of that makes sense to me. And I can see why you might have a favor for types or why that feels more valuable initially because that is giving us so much feedback right off the bat versus following a more functional paradigm is something that could feel like more of a force fit and doesn't provide that same immediate feedback. But it has a longer-term or a longer cycle of that reward system. So I can see why you might favor one over the other or why I myself would favor one over the other.

+ +

CHRIS: How do you feel about types?

+ +

STEPH: I'm a big fan, although I say that, but I work in Ruby. [laughs] I don't have them. But when I have worked with types, I very much enjoyed it because it makes me think more about the design of my code in a way that I don't as much with Ruby. And working with types has heavy influence than when I am working in Ruby and thinking about the design of my code. So I think working with types is a wonderful thing that, frankly, all of us should do as developers at some point because it is so influential. So I'm for types, but I'm not using types in my day-to-day.

+ +

Another thing that I have changed my mind about is how we structure the work that each person is doing. So I used to be more in the camp of everybody can work on their own very complicated piece of codebase, their own complicated feature. We can have a bunch of complicated things in the sprint, and everything will just be great; it’ll be fine. And we'll get a bunch of work done, and we'll ship it. And then we're an even more productive team.

+ +

And I very much disagree with that now where I have found where everybody is working in their own silo on a complicated feature has slowed down the progress of then being able to ship that feature. Because we often want to collaborate with someone, we need to collaborate with someone. Then the PR review process is tough if I really have no idea what you're working on, and I don't have a context that then when I look at your code, not only am I evaluating at the code level, but then I'm also trying to understand the feature and gain all of that context. And that's a heavy cost for me to have to pay to then pick all of that up and then for you to have to reintroduce me to what's happening. Or I might make the bigger mistake, and I may look at your code and just evaluate it from the code perspective but not really understand the feature, the value that's being delivered. And that doesn't feel useful.

+ +

And I have a recent example where that happened where someone was working on a very complicated feature that I didn't have any insight into. So then, when I was looking at the PR, it was easier for me to just look at the code and get feedback on that. But then it was probably a day or two later. It wasn't until then that I finally started asking, what are we building? Like, what purpose is this serving? And that opened up a much larger discussion where we realized what was being built didn't actually really deliver what we needed to deliver. So I no longer agree with the idea that everybody should be working on their own complicated features independently, and there should be some collaboration. And, you know, it's the buddy system; we all need a buddy.

+ +

CHRIS: Well, I like that one. I feel like I've shared similar ideas where it made sense. It was just the efficient thing to do, to split the work up and have everybody very independent. I also feel like earlier on in my career; I was more scared of Git conflicts and things like that or people interacting with the same parts of the code. And so in my mind, it made sense to really strongly separate like, oh, you shouldn't even be touching the controller for this. I'll handle the views, and you handle the controller; it'll be separate. And I care less about that now. And I think what you're saying of like, it's actually better if we have some shared context, and we understand what we're working on, and it's more of a collaborative process. Yeah, I like that one. I think I followed a similar arc, and I'm at a similar place now as well.

+ +

Interestingly, to go into another one of mine that I think you'll probably be most surprised by on my list is I think I used to believe in 10x engineers. I used to believe in the idea of that one developer just off in the corner fueled entirely by Mountain Dew that would just produce the perfect code. They would just solve it. Over the weekend, they would write the entire billing system, and it would be great. And I think it was predicated on the idea that the coding is the hard part, which I no longer believe. I think coding at its core is communication. It's taking this thing that we want to be true in the world and then communicating it to a computer but also ideally communicating it to our teammates, and to future versions of ourselves, such that we can revisit that code, we can maintain it over time, other people can add to or augment it.

+ +

And so the idea of this loner that can just do incredible volumes of work and have that be a good outcome that just doesn't make sense to me anymore. I've worked with incredibly talented developers, to be clear, folks that I was sort of in awe of. I've worked with people who have, I think, just truly photographic memories. They seem to remember every single bug that they've ever had and exactly where they can look it up. Or from the top of their head, they can just intuitively know, oh, this bug means this. Go look at this line of code. I'm like, how did you do that? How did you do that magic trick? And they're incredibly capable developers. But at the end of the day, the folks that I see being most impactful on a team are the folks that are able to communicate and collaborate most effectively and make the whole team more effective.

+ +

STEPH: Maybe it's the Mountain Dew; maybe that's actually the secret sauce here. That's what I'm missing from my life to take me into that status.

+ +

CHRIS: I'm now imagining Mountain Dew but in a more viscous form, like a barbecue sauce, but it's Mountain Dew flavored. That's the secret sauce because it's a very…anyway, moving on. [laughs]

+ +

STEPH: It's a terrible product. We should make it and sell it.

+ +

[laughter]

+ +

CHRIS: Career pivot, we now sell Mountain Dew sauce.

+ +

STEPH: [laughs]

+ +

CHRIS: But yeah, I do not believe in 10x engineers anymore. If anything, I believe that that is a huge warning sign if you have anyone that's behaving in something close to that space.

+ +

STEPH: Yeah, I'm super interested in that you've shared because I don't think...We've talked about 10xers, but we haven't talked about the fact that you used to think that they were more of a thing and that they existed. And now it's all I'm sorry, but it's all crap. [chuckles] That's super interesting to me. Do you remember what changed your mind? Do you remember that pivotal moment of where you were like, oh, maybe this is all bullshit?

+ +

CHRIS: I think it was just an amalgamation of experience over time. I've encountered people who fit the archetype. But if anything, I would say they're deeply problematic in teams. They're that individual who refuses to collaborate, who just goes off and heads down, writes a bunch of code, but then it doesn't integrate with the other pieces, or no one else knows how to use it, or they won't let anyone contribute to it. And yeah, I've seen that just be very, very problematic.

+ +

So the folks that most fit, I think the imagined version of this, actually end up, in my experience, leading things astray. And the folks that are actually most productive and really cause teams to improve in a drastic way behave very differently. They're much more collaborative; they’re much more engaged with the team. It's less about their individual contributions and it's more about building a system together, collaborating, communicating, engaging external stakeholders, et cetera, et cetera. It's all that stuff that matters. And so, it's very much in contrast to what the 10x engineer ethos is about. But there's no one day where suddenly this idea that I had in my head crumbled when I saw that behind the pile of Mountain Dew cans, there was nothing there. [laughs]

+ +

STEPH: It's all a mirage. [laughs] I do like what you just said around that there are very impressive people out there. And those impressive people often focus less on their individual contributions and more at a higher level around communication. And then they are the powerhouses that then is helping facilitate everybody else be their best and have high levels of individual contribution. Those are the ones that...I'm still not going to endorse a 10xer, but they are the ones who, to me, embody the idea of someone that is incredibly efficient and really good at their job.

+ +

CHRIS: There's an adage that comes to mind here that "If you want to go fast, go alone. If you want to go far, go together." And that does ring true to me. I think an individual can have their individual productivity be higher if they're working entirely on their own, if they understand every line of code because they wrote every single line of code if they know where every feature of the platform is integrated because they wrote the whole thing. But they're going to be fundamentally limited. And in order to do bigger, more complex things, fundamentally, we have to work as a team. And then the way you have to interact just fundamentally changes.

+ +

So I think it started from that, like, one person on their own I think can be individually more effective. But the minute you start to have a team, that one person acting on their own is actually dragging the team down because other people can't then work in that space, and that's a problem.

+ +

STEPH: I really like that adage that you just shared where, "If you want to go fast, go alone. If you want to go far, go together." And that touches on something else that I have really changed my mind about, and that's representation. And this is more specific to me. So when I joined engineering and became a web developer, and I joined a team, and I was the only female engineer on that team, my initial feelings were I am the only female engineer, and that is fine. We're all just a group of engineers. We're here to solve problems together. It really doesn't matter if there's anyone here on this team that's like me. It's fine if there's no one that I can see myself in that's in leadership because we're all just people, is what I was coming down to. And I've completely changed my mind and realized that that's not true.

+ +

And I've experienced this where I've worked on other engineering teams with female engineers, and it's fucking awesome, and it does make a difference. And then when I can see someone that I can see myself in, in a leadership position, that is also inspiring. So that is something that I went in where I think it was more of I was trying to shield myself from the idea that I am different from everybody else in this room, and that could be a problem. And instead, I just tried to neutralize it by saying it's not.

+ +

But I think representation is incredibly important. People are not just people. We all have very important social and racial, and cultural identities. And it's very important that we get to feel that we can express all of those identities and see people that represent those identities in spaces where we would like to go. That's a big one that I've changed my mind on.

+ +

CHRIS: Yeah, I certainly agree that representation certainly matters, and being able to bring your full authentic self to work and seeing others around you that reflect that. And frankly, having teams that are made up of people that represent the users of the software that we're building feels so critically important. And it's very interesting to hear about the arc that you've had on that where initially, you tried to downplay it, but then you found a little more truth in it. And so yeah, thank you for sharing.

+ +

STEPH: You're welcome. It feels good to say that, too, because that's something that I've admitted and realized on my own, that that is something that has changed and shifted. But it's nice to be able to share that here with you as we're going through the things that we've changed our mind about. What else is on your list?

+ +

CHRIS: Well, to round us off with one more very technical version because, of course, that's where I'm going to take us after a much deeper and more nuanced topic that you led us on, single-page applications. Broadly, I'm opposed to the name; that’s a side conversation. But, man, URLs matter on the internet. So don't call them single-page applications, but client-side applications or whatever. Broadly, the idea of a bundle of JavaScript, and so you send down an empty HTML document, and then you reference a bundle of JavaScript, which that thing boots up and it then makes a bunch of API requests to the backend, and then it starts to fill in the page.

+ +

I was convinced for a while that this is a reasonable and perhaps even necessary way to build software. We need APIs for our mobile apps anyway. So if we're doing that, then let's have that be the consistent way that we are accessing information. This is going to be fine; it's not a problem. And then eventually, we found some problems. So then we got GraphQL, and we tried to solve it that way. But overall…and I have spent a lot of time trying to make this thing work, trying to find a version of this that I'm happy with that I find the end outcome of the software to be as pleasant to work with from an end-user perspective as a server-driven application, and I can't find it.

+ +

And so, to be clear, I'm still doing client-rendered applications these days. But Inertia.js is the framework that I've leaned into that helps me bridge that gap. And the idea that the server owns routing, that the server owns statefulness, things like that, not having to think about client-side routing, not having to think about client-side state management, being able to use traditional auth mechanisms built into cookies, all of these familiar things that we've had. Leveraging the fact that the server is the more privileged in terms of the information it has access to, the more secure, the more powerful environment, all of these things feel right to me. And the nature of the application that I can build just feels more robust, more consistent, easier to evolve.

+ +

There were a lot of promises that I heard when we started building applications in these ways. And I just haven't seen an example or have not worked on an example, at least of an application that is built as a client-side bundle that boots up and does some stuff and had a good experience with that. So Inertia, as an aside, is my answer to this. And I continue to be extremely happy with that as a solution, as really a middle-ground solution. Because going all the way back to true HTML server-side rendering is limiting in other ways that I didn't like. But I find that Inertia really strikes an ideal balance in the middle there.

+ +

STEPH: I feel like I completely agree with everything you're saying. But I also feel like I have a developer secret to share where I really haven't worked on single-page applications, and I am okay with that. [laughs]

+ +

CHRIS: It's fine, skip it. Just go straight to Inertia. It's better.

+ +

STEPH: Cool, cool, cool. I am working on leveling up React, and then the plan is to go to Svelte and Inertia. So I'll just completely...I'll skip that. I'll skip that part of my career.

+ +

CHRIS: I actually want to back up just a little bit as I'm saying this because I really try to avoid being in a more negative space. And I think this space, this architecture for building applications, is complex, and there are things that will warrant it. So things like Google Maps, it makes sense to have a lot of Dynamic JavaScript and to be doing complex things on the client-side. Trello is another example of an application that that as a server-rendered thing, doesn't really make sense. And frankly, using a tool like Inertia wouldn't quite work there. That said, that is, in my mind, truly a single page within the broader application. So the Trello board page is a very, very complex stateful application, and I think modeling it as such makes sense. Google Maps, similar. But there's still the profile page, and the login page, and all of these other things.

+ +

I think routing is probably where it breaks down for me. I think client-side routing is the thing that I feel the most pain on. Because at the end of the day, the server still needs to know the answer. And if we do client-side routing, we end up with this duplication of logic across the client and the server-side. We end up with disagreements from time to time. We end up with the weird flashes of half-rendered layout, and then we go to the login page because we get an API response that is different. And so, I think that is probably the kernel of the thing that I struggle with. And, of course, it is possible to build great things using any of these technologies.

+ +

But I think my summary is I've really tried on that front, and I've just not been able to make the fidelity of application that I want using…primarily; I’d say it's client-side routing is the thing that I struggle with the most.

+ +

STEPH: Yeah, it sounds like you're saying there are very valid use cases for using a single-page app or following that structure. But we haven't really gotten there in terms of our web development expertise, where we've made that easier to maintain and easier to implement. And there's still enough pain points around it that even though it seems like a very valid idea and approach, it still feels painful enough that you actively avoid it until it feels like something that you have to then invest in at that point to then really deliver the user experience that you want to provide.

+ +

CHRIS: Yeah, I think that's an accurate summary. And I think adding on to that, I’m noticing it becoming more and more of the standard approach; this is the way we build applications, and I don't agree with that. That is probably the thing that is the kernel of what I don't believe in. I think actually server rendering is a great way to start, and then you can slowly augment or move more things into complex client-side behavior. But starting with this as the mode that we're building our applications just feels like a less stable foundation than I would want. So it's perhaps an architecture that you want to evolve to at some point as the complexity necessitates it, but I definitely wouldn't be starting there. Similar to service-oriented architecture, not going to start there. Client-side routing, I'm not going to start there.

+ +

STEPH: Ooph. I feel like I've been holding my breath this episode. I feel like this was a very interesting topic that has been challenging to reflect on what we believe and what we've changed our mind about.

+ +

CHRIS: I think it's perhaps more nuanced than a lot of our episodes where often we're saying this is what we did, and this is how we felt in the moment. And that can be very experiential and true. But this, yeah, we had to draw the line in the sand and say what do we believe? I similarly definitely feel more tension in this episode than other ones. But hopefully, it was useful. Hopefully, folks found some value in the things, and hearing our story, also, the idea that we have singular formed opinions. Hopefully, this episode has broken that idea in anyone's head. And we're all on a journey.

+ +

STEPH: I really like how this has prompted me to reflect on the things that I used to hold dear and really cherish or follow strictly to then reflect on what are things that I used to believe versus what I believe now? Because that transition often happens so seamlessly for me that I don't really stop to think about it to be like, oh, something just happened that is really changing how I approach things, how I build, how I work with teams. And I really like this reflection point to be like, oh, what did I used to believe, and what's different today? I'd like to keep this practice going and just try to track the things...I'll have to make a list of all the things I believe. That seems like an easy list. [laughs]

+ +

CHRIS: Just the easiest list to write.

+ +

STEPH: The easiest list to write. And then I'll just check in with it every so often, scratch stuff out, or update it with the things that have changed my mind about. This is the good idea, terrible idea where you go, "Stephanie, that's a terrible idea." [laughs]

+ +

CHRIS: I don't know, write it down on a list, and then look at it in six months and see if it sounds like a good idea, and then we'll be able to close the loop on the whole thing. But with that, should we wrap up?

+ +

STEPH: Let's wrap up. I've got a list to write.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshedor reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+CEQGKndP + + ]]> + + Chris Toomey + Steph Viccari + + + 305: Burnout & Bugs + https://bikeshed.thoughtbot.com/305 + 51334815-7a1b-4295-b0e4-915c4ad86e65 + Tue, 17 Aug 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + This week Chris talks about Bifunctor optics and introduces an app he's been liking recently called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX. + +Steph talks about her experience using New Relic Browser Stats to troubleshoot a slow page and burnout. Who's feeling it? (Raise your hand.) How do we identify it? What do we do about it? + 50:02 + no + + + This week Chris talks about Bifunctor optics and introduces an app he's been liking recently called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX. +Steph talks about her experience using New Relic Browser Stats to troubleshoot a slow page and burnout. Who's feeling it? (Raise your hand.) How do we identify it? What do we do about it? +Svelte Is Beloved! - Stack Overflow Survey (https://twitter.com/sveltesociety/status/1422372693827985409?s=21) +Bifunctors (https://stackoverflow.com/questions/41073862/what-are-bifunctors/41075765#41075765) +CleanShot X (https://cleanshot.com/) +Next.js Image (https://nextjs.org/docs/api-reference/next/image) +Transcript: +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. And we're off the rails already, everybody. It's going to be a good one. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going? +STEPH: Hey, Chris, it's going really well. We talked recently that I have a new laptop. So I have been migrating the things that I'm accustomed to over to my new laptop, but I also love that clean, fresh start. So as part of that fresh start, I was like, what if I use Safari? What if I just switch? I'm a Chrome user, for the record. I'm pretty sure you know that, but just to share that. I was like, well, what if I just switched and I try out Safari for a while? So that was the thing. +CHRIS: So I heard the words try and the phrase that was the thing, but I'm going to probe a little deeper. How'd that go? Was it good, great, not so great? +STEPH: Honestly, it was fine. I did enjoy being in a new environment to see how Safari handles bookmarks and then also the inspector. So it was novel to be in a different browser where I really don't spend much time in a different browser other than when I need to test this specific UI bug or things like that. +But the reason that I ended up migrating back to Chrome was frankly for Chrome profiles because I really like that I can have this clear separation now between my work life and my personal life, and then it also keeps me signed in. So my personal email versus my thoughtbot one versus before the Chrome profiles, which I'm not sure how recent of an addition that is where Chrome introduced that feature. But before, I just always had to be signed into both, and it was just all together in one spot. But now I really like that I can separate. And it's more intentional where I'm like, oh, I'm going into work mode, so I just want that profile versus I do need to hop over to my personal side for a while. So that was the thing that brought me back. +CHRIS: Interesting. I don't take advantage of that at all. I know of the feature, but it's never really called to me. And if anything, I do the opposite. So specifically, this doesn't work in the browser, but on my phone, I use the iOS Gmail client, and I use the unified inbox. So I just have everything come together. And I subscribe to the idea of, I don't know, it's all work and stuff. And hopefully, people aren't sending me a lot on the weekends, and I will defer and snooze and all of that. But that holistic view pulls me in. And so it's interesting that you're just on the other side of that. It totally makes sense. I actually think I'm wrong here. I think I'm doing the wrong, bad thing. But it's interesting just the way we're on the two sides of that. +STEPH: I can see the merits for your approach where it all goes to one place. So you have one place to go and triage, and I think that makes total sense. I haven't triaged my personal life well enough that I want it to come into my work life. And that's the one that needs the more immediate response typically. So I want to prioritize all of my work emails and focus on that and then have my personal ones more like, okay, I've got some time, and I want to check on this. But I don't want to blend those together. Because frankly, I need to do some more triage on the personal side if I'm just going to bring it all into one space. +CHRIS: Interesting. Yeah, I would almost view it from the other point of view of I want to protect my personal space, and this is obviously not what I do based on what I just said but protect my personal time so that when it's evenings or weekends or whatever, that I'm not seeing work emails in there. I do my best to snooze them and get them out of the way. But if they are coming in, maybe there's something I need to respond to or, I don't know, maybe it's FOMO in a certain way, FOMO but professional FOMO. I don't really know. It's interesting that that's the feature that brought you back. But overall, how was your experience using Safari? +I have heard loosely that now most of the browsers are evergreen; even Edge has really caught up and is now implementing features in a similar way. And so Chrome, Firefox, and Edge are very similar. And my understanding is Safari is the one that actually lags behind or even holds back web standards and implementations and things like that. So, did you find any rough edges of that sort, or was it otherwise just fine, and it was mostly the profile stuff that made you switch? +STEPH: It was honestly just fine. I also may have not used it long enough to run into any of those rough edges. But overall, it was just fine. It worked. I just got to that point where I've run into this situation before where I'm signed into my personal email, and then I'm signed into my work email. And then I'm going to Google Hangouts, and Google Hangouts gets confused, and it's like, which person are you? And then I have that moment of where I have to sign out of one, or sometimes it just gets complicated. And what I found with profiles is that that's just never an issue. I don't have to worry about it anymore. +So yeah, overall, Safari was fine. I wouldn't mind going back to using it. I just really like the profile feature. This was one of those moments where it helped me notice how much I really liked that feature because I had just opted into it a while back. But this was that moment where I was like, oh yeah, I really miss that. So I'm going to go back to it. +CHRIS: The thing you said a minute ago about which person am I? [chuckles] There's a deep philosophical underpinning there, but I've definitely struggled with that and trying to trick the browser into it. So Trello is the one that I'm struggling with that right now. I am one human in the world, I assure you. But GitHub gets this; GitHub plays the game correctly where I'm one human, but I have multiple internet identities. I am the work person. I am the open-source person. And I'm able to route notifications and things to the different inboxes based on the organization that they're part of, et cetera. And I really liked that, that GitHub seems to understand that I am a human that is multifaceted, whereas Trello does not. And so I use Trello in a professional context a lot, but it's my personal...like, I would have to create a distinct account on Trello. And I'm like, Trello, that's not true; I'm still one person. Just understand this Trello organization is a separate facet of my existence. Got on my soapbox on that part. +The other thing I want to say is I do feel bad about the fact that I'm just on Chrome. Because increasingly, Chrome has got so much of the market share, and it's becoming the new deeply dominant thing. And so I want to be the agent of change or like, no, we should use different browsers, and we should support them and make sure that we're testing against them and all of that. And then I'm just on Chrome all the time, and I feel bad about it. But it's one of those like; I have so much muscle memory and built-up knowledge around how to use Chrome. And I've just used it for so long now that the switching cost would be pretty high, I assume. I actually haven't even really tried, but I feel bad about it. I'm now saying two things which are I feel bad about it, and I've never even really tried. So I don't feel great in this moment, but these are my truths. +STEPH: [laughs] Well, I can plus-one your truths. Those resonate with me. Well, there's always stuff that I am trying that's new all the time. So I feel like I need some constant in my life until I'm ready for other things to be the constant in my life. And then I can muck around with which browser I'm using and change other things. And you have to be in that moment. You have to be ready for it. +So going back to a thing that you said a minute ago about separating your work life and your personal life, I very much like that framing, and that's a nice segue, frankly. And it's something that I've been thinking about where you and I often start with technical topics. But I have a very people-centric topic that I'd love to chat with you about today, and it is emphasis on burnout. And who's feeling it? How do we identify it? What do we do about it? +And that's been very much on my mind because I have noticed a lot of people around me, including myself; I just feel like we are more inclined to experience burnout right now or are going through it actively. And it feels even more important to have those conversations with each other and with ourselves to talk about what does it look like when we're burned out? How do we recognize when we're there? Because often, when we are burned out, it's not something that happens gradually, or at least it's not something that we notice happening gradually. It's like, okay, I'm fine. And then suddenly, okay, I'm burned out. And I'm at a place where then I can't really focus. I feel overwhelmed. I'm drained. +For anyone that is less familiar with burnout, one, hooray, and then two, burnout is a state of emotional, physical, and mental exhaustion that can be caused by excessive and prolonged stress. So then that's what leads to us feeling very overwhelmed, emotionally drained, unable to meet constant demands, or those are the things that are causing our burnout. +So I have been doing what I typically do when I'm thinking about a particular topic, and then I'm looking to gather knowledge and information is I try to go pretty wide where I start looking for podcasts, books, just people that are having similar conversations and trying to synthesize a lot of the information that they're sharing. And I have found some really good stuff. The question is now, what does one do once one has that content, and then how do you bring it back and help apply that content to yourself and then people that are around you? So I have some thoughts there, but before I go further, I'm curious, what's your experience with burnout? +CHRIS: I think for me, I've been somewhat lucky in that I don't think I've ever really got into an acute period of burnout, but I've definitely had periods where I just felt weighed down. And there are ebbs and flows of life, and of work, all of those things. There is something that I've been thinking about recently, which is the inherent nature of the work that we do where consistently we're working on something where we don't quite know how to do it, and we're struggling, and we're struggling. And finally, we figure out how to do the thing, how to trick the computer into doing what we want. And then the minute we do that, in trying to encode, ideally, we're automating that away. And we take that solved problem, and we just ship it off. And then, we pick up the next unsolved problem from the list. This isn't entirely true, but it feels like sometimes unspecificity in sort of I'm just working on things that are underdefined, underspecified, and I'm trying to solve little puzzles constantly. And, I don't know, I was feeling that recently of the nature of the work was burning me out. +And I think earlier on in my career; I definitely experienced this in a certain way. And then, in the middle of my career, there was this perfect inflection point of my skills and the level of tasks that I was going for. But then, the further I got into my career, the more I tend to take the weird underspecified stuff and anything that's relatively clear I'm giving to other folks on the team. I'm like, "Oh, here's this well-defined piece of work here. Can you go implement this admin page?" Whereas I am doing the investigate integrating with third-party platform XYZ that uses a SOAP API that isn't documented. I'm like, okay, cool. Let me roll up my sleeves and figure out what that means. And I noticed in my work that that was starting to weigh on me, and I was able to shake that off and shift around some of the tasks that I was doing. +But that was a particular form where the work itself was weighing on me. And I took a step back, and I was like, why do we do the things that we do as developers? Because there's something just fundamental like, you have to enjoy that nature of challenge and constantly escalating challenge to a certain degree, I think, to really like this work, but it can be a lot sometimes. So I feel like maybe that's a slight digression from the topic, but it was a thing that I was feeling in this space. And that's a little bit of my story. +STEPH: Well, the beautiful thing about that is it highlights everybody experiences burnout differently. So that could really be how someone is experiencing burnout where they're taking on all these very complicated, different tasks, and they're feeling just worn down by that and that they're not able to meet demand. And they get to that point where maybe they lose their interest in tech and coding because they have pressed too hard in one direction. And so then they need to take a step back. +As for me, I've been thinking back over the last couple of months because there was once or twice where you and I had, I think a conversation here on The Bike Shed where I shared that things were okay, but I didn't feel like my normal self. I was losing some of my interest and energy for technology and coding. And I'm very fortunate; I love what I do. So the fact that I wasn't feeling that interest was a really big sign to me that something's different; something feels off. And it does vary depending on the client that I'm working with. And I think feeling that burnout then was a mix of some of those client pressures that I was feeling and that I was working perhaps too many hours as I was very interested in that client's success. +And then the other stuff was more personal because we only have, to borrow from the spoon theory, we only have so many spoons to give. And so if you have a lot going on in your personal life as well, that's going to detract from the energy that you also have to give to work. Are you familiar with the spoon theory? +CHRIS: I am not. +STEPH: I recently heard about it, and I can't stop using it now because I really like it. But it essentially...and there's a really great article that we can link to so others can read about it because I'm not going to remember exactly who came up with this theory. But the idea is that each spoon represents a unit of energy. And let's say if you start each day with only ten units of energy and you use spoons to represent that, as someone needs energy from you, maybe it's work, maybe it's a personal commitment, maybe you're dealing with a chronic illness, then you are giving a spoon away to each of those. So at some point, you're going to run out of spoons. And you want to also be mindful of who you're giving these spoons to because you are giving that energy away. +CHRIS: I definitely liked the idea of we start each day with a certain amount of energy, and different things can pull from that pool and whatnot. I'm intrigued by spoons as the unit. It just feels like a weird...I got this little bag of spoons that I walk around with, [chuckles], and I give them out throughout the day. I guess it could be anything in there, you know, objects. But, I don't know, spoons are interesting to me. +STEPH: I think it's because this person who came up with the idea was literally having a conversation with their friend in a cafe. And so that was just something that was in front of them. And they're like, oh, I can use spoons to represent. Well, we'll have to double-check the article to make sure, but I think that's why spoons became the representation. +So circling back to once you're in burnout, what do you do with it? And that is one of my questions right now. And that's what I'm trying to synthesize a lot of information around. Because once you're in that state, I don't know of a lot of great ways to help other than take time off because, at that point, you're in a crisis state. And you need to step away, and you need to find out how you can recover from having entered this state of crisis. So that feels really important to identify ways that once someone is in that state, that then we can help them. And that feels good. We can advise someone to take PTO. I still don't feel great about it in terms that then, as a manager myself, I don't really know of other helpful ways to then help someone through that period. +So then I really started thinking about the fact that once someone is in that burnout stage, frankly, it's too late. We have let someone get to that point that now they are in that crisis instead of addressing it early on. So that is the other thing that's on my mind is one, how do we help people that are already in that crisis state? But then two, how do we start identifying that someone is starting to go in that direction? And then how do we help them tell us? How do we then triage those situations? How do we prevent them from getting to that burnout state? And that's where I've also found some really good content. +And specifically, there is a podcast that I've started listening to called The Burnout Show. They essentially share their experience with burnout, and what they did about it, how they recovered from it, and then how they continue to fight it because a lot of people then still go back to the workforce. So then, once you do find a way to recover, then how do you go back to work? And there have been some really great episodes. And I'll be sure to include a link for it in the show notes. +There's one particular episode with Grant Gurewitz, who is a guest on the show. And he speaks specifically to the strategy of Three Good Pockets. And this speaks to the idea that there are many things that we can't control in our day. It could be work, family, other commitments, but we can strive for Three Good Pockets of time where we focus on something that's just for us. This is time that's reserved for you and any activity that you find restorative or joyful. And each pocket can vary in size. So perhaps that first pocket is spent just reading a few pages from a book that you're enjoying, and then the next pocket of time is spent outside or calling a friend. +And Grant also has a great suggestion around if you're worried that you'll get sidetracked and not actually step away, which I felt called out for that one because that one's definitely me. I will have good intentions, but then I won't actually take the break that I set for myself. So Grant recommends creating a list of restorative activities so that way when it is time for that break when your calendar is reminding you, then you have a list of these activities to choose from. So it makes it easier to say, okay, then I can do this for a couple of minutes, and I can truly step away from work and step away from my screen. +But especially now, when so many of us when we're sharing our workspace with our restorative space, for everybody who is still working from home or working remotely, then creating those daily breaks are incredibly important to our wellbeing. And so, it has me thinking about what restorative activities can I add to my day? How can I encourage other people to add more restorative activities to their day? So I really appreciated that advice. +And I have noticed that the idea of burnout, but not so much burnout specifically, I've been thinking of it as recovery and balance is a theme for me. And it is something that I am purposely choosing as a theme right now where I want to research and understand more of how we handle these situations and continue to make progress not just for myself but also for my team. +CHRIS: I think finding that right cadence and structure and way to reinvest in yourself and ideally gain more spoons if that is at all possible or at least defend the spoons that you have, those all feel very meaningful. +I do have a question. I'm interested in your thoughts on this. I feel like we hear about burnout a lot in our industry. I get the sense maybe that it is a more common thing. Like, I hear so many developers talking about how their dream is just to give up tech and go get a cabin and just farm in the woods or something like that. And I wonder, is it a more pervasive thing in our industry? So that's one question. +Another is just an observation that we actually do work in a wonderfully...it's an amazing industry where being a developer, there are so many jobs out there. And I don't want to discredit anyone's efforts if they're earlier on and struggling with that. But broadly speaking, it is a developer's market trying to go out there and get jobs and extremely well-compensated, as a general rule. But does that come with this inherent burnout? And if so, which I'm not sure is true, I wonder if maybe we're just more vocal and maybe we actually share more in public. We have more blogs and podcasts and things like that. And that's just a common thing for developers, and so we hear the stories more often, whereas maybe in other industries, it is actually very common, but people are suffering in silence. +But also I do wonder, our industry is still so young. The work that we're doing is changing constantly, and that churn and that working in the unknown maybe there is an inherent nature. So that's a bunch of pontifications off the top of my head. And I have no idea what the answer to any of them is. But I am intrigued because it does feel like the shape of burnout as a concept in the developer world is perhaps a little overrepresented, or maybe it shows up more than I would expect. And, I don't know, is the work that hard? I don't know. But then I hear these stories constantly, and I definitely have felt it myself, so maybe. +STEPH: Yeah, maybe. Yes, I do think the work is that hard for the record. It's challenging work. I enjoy it, but it is challenging work between figuring out the tech but then also everything else that comes with that. +I don't have anything to back this up, but I suspect that a lot of other industries are also experiencing burnout. And I just happen to be more aware of it right now because I'm hearing it more from my friends and the people that I work with. And I suspect that's more directly related to we all just went through 2020, and probably a number of us were trying to forge ahead and get through that time. And so there may be a lot of us that are just now dealing with those consequences of where we just pushed ourselves through a very hard time. And now a lot of that is manifesting and surfacing around really identifying the damage that we may have done to ourselves by just prioritizing work and trying to put our head down and get the work done even though there was so much happening around us. +And I suspect that may be a contributing factor is that now people are really starting to recognize, like, oh, I feel this way. And maybe there's time for me to address it. Or frankly, it may not even be that there's time, but your body is just like, okay, I'm done. I made it through the past year or however many months, and I'm going to start shutting down on you. I've given you all the warning signs, but now we're here. We're at a breaking point. So I don't know about the other industries, but I do know the reason that it's more on my mind is because I'm just hearing it more from people, and they're just expressing it. And so, it has become more of a focal point for me, and I've experienced it myself more recently. +I'm sure I experienced this back early on in my career, but I took a strategy of well, I'm just a junior, and I just have to get through this. And I have to build experience. For the record, that is not a healthy mentality. I'm just being honest about where I was in my life. And so, I didn't really stop to think about it, but perhaps it is becoming more normalized where people are having more open, honest discussions about where they're at. And if other industries aren't talking about this, I would love for them to. +So to round that out a bit, this is something that is just very interesting to me. It's very top of mind. So I suspect I will be sharing a lot more content in future episodes that are just around this. How do we recover? And then how do we balance? How do we work hard without burning out? +CHRIS: Work hard, play hard; those are the two placards that you have. Well, I look forward to continued conversations on all of those topics because they are sort of that's the story that underpins all of the work that we do. So I'm very interested to chat more about that. +STEPH: Thanks. So what's going on in your world? How's your week been? +CHRIS: Oh, my week has been fine. My topics are going to be way more mundane and tech-focused. But let's see, a couple of things, so one is that Stack Overflow has their I think it's Annual Developer Survey. And this year, the results came out, and there was an interesting standout, which was that Svelte was the most beloved framework, which was very exciting to see. Granted, you always have to take these sorts of stats with a grain of salt. +But Svelte was 71% loved and 23% dreaded, which they give it as a ratio of how many people really love this thing versus how many people really hate this thing. And so Svelte, 23% of people who have used it are like, I hate that, but 71% loved, so that's a 48% net approval rating. Versus React which was 69% loved, 31% hated or dreaded as the word would be, so that's a 38% net approval. And then Vue, interestingly, was 64% loved, 36% dreaded for a 28% net approval rating. So, yeah, Svelte was decidedly winning in that. +But again, the big grain of salt there is looking at the usage stats. React has 40% usage. So of all the respondents, 40% of the people responding to the survey were like, yeah, I've done React professionally, which is a wildly high number for a JavaScript framework. Vue was at 19%, so roughly half of React's usage, which I'm actually impressed that Vue is that high. And Svelte came in at 3%, so it's definitely still in the early adopter strong fan phase. So it makes sense that they would have this outsized high rating. I'm actually surprised that Vue wasn't higher than React, given that. Because I feel like more people are cajoled into React versus Vue can be more of a choice. And I would have expected this to shape out a little bit differently, but yeah, that's the story. +STEPH: That's really cool. I liked how you described that as in the very early adopters’ strong fan base stage. +CHRIS: But nonetheless, the people that are using Svelte do seem to really like it; that’s coming through in these numbers. And that definitely is my experience. I love Svelte and would love to continue using it for as long as possible. But really, I want a lot of other people to start using it. I want to really grow the usage base so that there are more libraries, and frameworks, and blog posts, and just mindshare in that space because I really do believe there are some wonderful ideas in Svelte. And it's just so straightforward to implement things that I just want more people hanging out. So that's one quick thing. +Another quick thing is, I've been using a utility lately or a program called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX, and it is just fantastic. So I can capture a screenshot. I can capture a window. You can capture a GIF or a video. And then you can do little trims and annotations. And then it has this really nice feature where after you take a screenshot, it just hovers in the bottom corner of your screen and is easily accessible. So if you take a video, and then you want to upload it to a Trello card, it's just floating there waiting for you. You can actually dismiss it and push it down, but it's still peeking up from the bottom of your screen, and you can pull it back up, and you can have a couple of them. But it just really makes the whole workflow of grabbing screenshots or videos so easy. +And I cared deeply about that because now that I have this tool, I'm all the more inclined to grab a screenshot or a video with just about every piece of work that I do. So it's going into pull requests; it's going into Trello cards. And it's so nice to have a utility that just really makes that as easy as possible. +STEPH: I really liked how you mentioned that you can annotate because I often...I'm laughing as I'm thinking about this. When I am taking a video of something that I'm going to share with someone, I will use my mouse to indicate, oh, this is important. And so I circle around it and do silly things with my mouse to try to indicate but being able to annotate would be so much nicer. +I know there is another tool that you're really excited about that I can't remember off the top of my head right now. Do you know the name of the tool I'm thinking of? +CHRIS: Was it Loom? +STEPH: Yes, Loom, because I also used that for a little while, and I've really enjoyed it. So I'm curious, how does Loom and CleanShot X stack up? Is one replacing the other, or are they complementary tools? +CHRIS: Mostly complimentary. Loom is great because it hosts the videos, and you can also do audio capture, although I wonder if CleanShot has that as well. CleanShot also, I think, has a hosting thing. So I think there's a strong overlap in their functionality, but right now, I'm using both. And definitely for screenshots and things, CleanShot owns that end of it. And I think it's more likely that I could have CleanShot as the entire tool that I'm using. But I'm still using Loom for this is a walkthrough where I'm going to talk to you about a thing. I want to make it available at a URL that everyone can see rather than actually getting a GIF or MOV artifact file on my computer. So ever so slightly different, but I think of them, CleanShot X is probably the ideal one. But yeah, I'm still reaching for both. +So the one other thing I did want to talk about is I have been expanding our use of the dry-monads within the project that I'm working on. And I've done some things. I did some stuff, Steph, and I think it's good. +STEPH: Shtuff with Shteph. [chuckles] +CHRIS: Shtuff with Shteph, yeah. I'm definitely pushing the envelope of how much we're leaning on these concepts within the app, and I continue to question it. I'm really intrigued to see what happens when other folks come into the project, and they're like, "Why can't I just get the value? It should be a string. Why isn't it a string? Why is it a string that I have to do a ceremony and a dance to get at?" And I'm like, "Well, because everything can fail, you know, like life." +But what I have done here so dry-monads is the project that we're using, particularly their result type. So the result represents something that can either succeed or fail. And so we either have a success, which is this wrapper around the value that's successfully executed. So say we make an API call, we get back a response. If we get a 200 or maybe even a 300, then we get the data, and that's a success, or we get a failure and the error message. But fundamentally, we're modeling that in our system in a way that downstream from that, we have to basically determine if it was success or failure. So we're really encoding into the system; listen, pretty much everything can fail, so let's be careful with that. Let's be intentional and purposeful with it. +But there is an interesting thing where these objects have fmap as a method on them. So fmap is a way to transform that wrapped value, but fmap works specifically on the success case. So if you make an API request, you get back the data. Everything's great. You can call fmap, and it will yield into a block that data. You can transform that data in some way, and then it will rewrap it up as a success object. So you can operate on this thing as if it has been successful. But in the case that it's a failure, it will just ignore that transformation because you don't want to transform the failure. It's going to be a totally different shape of data. So you want to separate those. We're getting into functors and monads here. So I'm going to handwave a bunch. But fundamentally, that's the thing that we're going for here. +But we found ourselves really wanting to work with both sides. So we make this API request, and in the case that it succeeds, we actually want to transform and actually slice out a piece of data from the nested object that we get back. So that's one transformation that we want to apply on the success portion of the aisle. But then, we also want to transform the failure message. It turns out this backend is giving us very unfriendly error messages. So we want to take those and transform them into friendlier user-facing error messages. +So it turns out we want to map both sides. And so I went to dry-monads, and I was like, what do you got? I want to know about this in the world. And it turns out they did not have anything. So I started looking into it, and it turns out this is a concept in the world of functors, specifically. Or, more specifically, I reached out to a former colleague, Sid Raval, a former thoughtboter as well. And he likes the functional programming stuff, so I knew he was the right person to ask about this. And he pointed me at bifunctors. So I found myself in a new space and category theory which I never thought I would explore a category theory in this way, but here we were. +So a bifunctor basically is exactly what I was talking about where there are these two branches. In our case, it's either success or failure, but it allows you to operate on both sides, both branches. So the method or the function that gets applied there is bimap. So it's fmap which I don't know why it's f why that's typically what it's called. Success map would be a really great word in this context in my mind. So success map only deals with the success side, but bimap takes two different transformations, one for the successful outcome and one for the failure outcome. And it allows you to very directly talk about what you want to do with that. +To be clear, dry-monads has a function called Either or Either, depending on how you want to pronounce it. And that takes two Lambda proc-type things because it's Ruby, and functions are kind of weird in Ruby. But it yields you either the successful value or the failure value, but then it doesn't rewrap them. So it's meant to be the terminal. You use that in a controller when you're either redirect or render or whatever it is you want to do. What I wanted was something for mapping, so staying in the success object or the failure object but yeah, bimaps. So I introduced my own extra wrapping layer. This is where things go off the rails, I think. We now have our own internal result objects. +I thought about monkey patching for a while. I convinced myself monkey patching was a bad idea. Now that I've implemented as an extra layer of wrapping and I got the wrapping wrong like four times, or I kept recursively wrapping and re-wrapping, and there's a reason people aren't supposed to write these things themselves. But I think monkey patching may have been a better idea here, or maybe I should have never done any of this. We ended up with a stable working implementation and a nice test suite that covers it. But I introduced bimap and failmap as two different methods on our success object. And I did it by doubly wrapping the result objects. So we have our internal result, which wraps the dry-monad result. And I'm worried about that future situation where a junior developer comes on the team and is like, "I don't know what any of this is." +STEPH: I love the weekly progression of I've done some things, and let's talk about it. And then seeing this glimpse into your argument with yourself as to yes, but we need it, and we want it, and it's not something that's defined. So let's go ahead and implement it. You ended on a high there where you talked about the fact that it is nice to work with. It does the thing that you'd like it to do, and it's well tested; I love that part. +I'm deciding which thread to go with because there were a lot of interesting bits in everything that you shared. And I'm intrigued about the monkey patching as to why you think that could have been a better approach. Could you talk more about that one? +CHRIS: Sure. So I ended up having to introduce the secondary object that then wraps the result. And so if you poke at that even a tiny bit, you start to see this like Russian doll nesting of it's our result wrapping a result, wrapping a value. And it's a burrito with three different tortillas wrapped around it. And if you want to add guacamole, you got to unwrap all three burritos. I'm sorry, this is a terrible monad joke here. [laughs] +STEPH: For the record, if Taco Bell is not offering that, they should now, now that you've created that. [laughter] +CHRIS: There is one, but there's usually cheese in between the layers. They're not just extra layers of tortillas, so that's what I've got here. It's way too much tortilla, and that's sad. You don't want that. And it's confusing. You're like, wait, does this one have two or three layers of tortilla? So when I was working on it and when I was implementing our additional wrapping layer, I tricked myself multiple times. And my test suite was telling me that things were working, but I was testing incorrectly. And I was like, oh man; this is very subtle. And even though I'm deeply immersed in the context here, I'm still struggling with this. +So the question is, did I successfully encapsulate all of this? And now anyone downstream just gets to use it,, and everything will be fine. Am I the heroic programmer that made the perfect abstraction that no one's ever going to struggle against, or was that pain that I was feeling representative of the complexity of what I'm trying to do here, and maybe I got it wrong? +And so then the monkey patching side is we've got this one layer of wrapping. What if we just monkey patch the result such that it's got these new methods? I'm not adding an additional layer. I don't need to deal with double mapping through multiple layers, and I just get to deal with the context that I have. So I did an initial spike of an implementation that way, but I talked myself out of it because #monkeypatchingisbad, but I don't know. I don't know where I'm ending here. I am happy with where we're at, but I am aware that I may be sad down the road. +STEPH: I'm just dying over here [laughs] from everything you're saying. I have this image of you staring out the window thinking, am I the hero, or am I the villain? And figuring out who you are in this scenario with this abstraction that you've created. +CHRIS: To be clear, it's raining, and I have a nice rocks glass of scotch in my hand. And I'm just wistfully looking out the window trying to determine what's true. That's pretty accurate, actually. That's pretty much what's going on here. +STEPH: I think we're just going to need updates as it progresses along. +CHRIS: I will say overall this paradigm...so failures can happen at all levels. These command objects, which are the core of where this is coming in in the application, really represent the workflows of the app in a wonderful, testable, straightforward way. So I love that part. And if I have that, it implies that I have to have this other stuff. I don't think I can get away from that. +The other thing is I've always loved Gary Bernhardt's Functional Core, Imperative Shell, which is a conference talk that he gave a while back. I talked to Gary about it actually when he was on the show, and we can link to both that and the conference talk because they are fantastic. And I just love the way he thinks about software. But that was always a little bit abstract for me. Like, what does that actually look like, though, in say, a Rails architecture? And I didn't have a great answer. +And now this thing that I'm doing is the closest I think to that where the innards of the system are almost functional even though it's Ruby. We're leaning into that. And so we have these command objects that take in some data, and then they operate on it, and they yield out these results. Did it go well, or did it not? We've got the railway-oriented stuff, which again I'll link to. I link to now every third episode, apparently, but here we are. And that just models the reality of these programs in a really great way. +And then we've been trying to introduce some, not rules per se, but guidelines as to how we interact with these things. So inside of the core of the application, we're trying to be as functional as possible. We do transformations on these result objects, but that's it. And then it's only really in the controllers or the mailers that we are doing unwrap or deal with the actual nested value, but everything else is working on conceptual values or whatever it is…these result objects. And that's actually been really nice, and it's allowed us to have really nice error handling within the app. The logging is very straightforward. A lot of apps that I've worked on in the past, I've just silently thrown away many error cases or edge cases. And this is a really great way to sequence the work that needs to be done but never throw away data that you would want. And so far, I'm finding it to be really great. And I'm seeing very obvious ways to hook into it like, oh, this is where we need to find the user-facing error message versus this is where we figure out what we want to log. And so, in some ways, it's great, but I am still open to the idea that this was a terrible idea. I always remain open to that idea to be clear. [chuckles] +STEPH: I love how that's the feedback that you're always open to it. You're always trying something new, and then you're constantly going back to revisit; was this a good idea or a bad idea? +To go back just a little bit, I do absolutely love the priority and focus that you're giving to the failure state because I feel like that is an area that we, as developers we're very skittish of that failure state. And I realize I'm projecting here. So if you're listening, feel free to take that however you like; maybe it doesn't apply to you, maybe it does. But the failure state is like you said, it's life, it's important, and it's something that is going to happen. And it is something that we should make accommodations for. +And I find that we're often very hand-wavy with a failure state. So I love, love how much you always prioritize the failure state and make that something that people can work with and understand. Versus then when something goes wrong, then that's when we have to start to understand the failure state. I recognize there's a balance there because you're not going to know the failure state until you encounter it, but there are ways that we can still optimize to have observability into that failure state for when we do encounter that failure. +CHRIS: I've definitely seen that as an evolution in my own thinking, how much am I focused on how easily can I do the core thing, the happy path versus how robustly can I do all of the variations of what this app needs to do? What if the network's down? What do we do there? I do occasionally worry that I've overcorrected on that. And it's like, you know what? This thing that I'm worried about that I'm protecting against in the application is a 0.01% edge case. It's going to affect almost no users, and we're both putting time into trying to avoid it. But also, there's code complexity that comes from trying to handle all the different variants. And so there's definitely an optimization, and I feel like, at different points in my life, I've been undercorrected or overcorrected on that. +But I think if I were to describe the arc of my career, it is desperately searching for that optimal path and trying to find exactly the right amount of error handling to apply, and then yeah, then I'll be happy, then it'll be great. But it is like when I look at DHH's classic 15-minute I'm making a blog, look how much I'm not doing, I'm like, sure, sure, sure. Show me that in three years, though. What does the blog look like? How easily can I add a new feature? What happens when there's a bug in production, and a user reports it? Can I chase it down? Can I figure it? Can I fix it? These are the questions that I care about now, almost to the exclusion of what's the first run experience like? I almost don't care about that at this point. Because I spend my time…six months and on that's where the hard work is. And so the first couple of months where you're figuring things out, that's not the hard work of this thing. And so, I'm very strongly focused on those later periods of time. But again, I'm open to the idea that maybe I am overcorrected there. +STEPH: I think it does highlight more of a shift in our career. We're still building, but we have experienced the maintenance side as well, and we felt that pain. And so that has led to perhaps overcorrecting, or maybe it's the correct amount of correction. +But I do like how you highlighted there is always a cost to each side and those are usually the questions that I'm asking myself when I'm thinking about the failure mode and how much I want to optimize for the failure mode is how much does it cost when this fails? Who's it going to impact? And how much does it cost for me to make this more observable or to address this failure state? And then I try to find the balance between those two. Because you're right, it's not free to address that failure state. And so I may not want to fully optimize to handle that if it's going to be a very small percentage of users that actually are impacted by this failure state, or it seems very rare this is going to happen. But then still finding ways to know that if it does fail, then I can say, "Okay, I'll come back, and now it's worth the investment to improve this." +CHRIS: When you said earlier that this is really hard work that we do, I don't know that I believed you. What you just described sounds super easy. You just handle all the stuff, and you dynamically optimize for the needs at the point in time. And that seems easy. [laughs] +STEPH: Super easy, yeah. [laughs] Way to bring it back. Well, speaking about observability and failure states, that does lead nicely into a bug that I was working on this past week where there was a particular page that was loading very slowly. And it was something that we'd heard from users that then they let us know that this page was either taking a very long time to load or, frankly, it was just crashing. And then they were never getting to that page. So I happened to be the one that then picked up that ticket. And I went to reproduce the issue, and sure enough, when I clicked on this particular link and then started counting, it took about 14 seconds for that page to load, which is a very long time. And then also sometimes it was just crashing. +So the first place that I went was to our error tracking. So I went to New Relic to then look to see okay; maybe there's a slow query. There's something here that's creating this performance issue, but I couldn't find anything. And New Relic does a great job of breaking down all the different response times so I can see how long Postgres is taking, Redis, and Ruby. All of those looked very normal. I couldn't find anything that seemed alarming that was indicating that the page was struggling to load even though I could reproduce the problem. Because I was clicking on it several times thinking, okay, well, if I just do this a couple of times, New Relic's going to notice, and then I'll get to see something, a little breadcrumb that's going to lead me in the right direction. +And while I was waiting for New Relic to surface something helpful to me, I mentioned to another developer the issue that I was triaging. And they said, "Yeah, that page has been getting progressively slower, and we don't know why." And I thought, ooh, okay, I'm intrigued even more now as this is something that has been escalating over time, and now we've hit this threshold that we're working on it. +And I discovered that in New Relic, I can look specifically at Postgres, Redis, Ruby, all those different response times. But there's a browser monitoring tool that I had not used before. And it showed a lot of helpful information around first paint, First Contentful Paint, window load, all of those areas. So I started diving in and found session tracing, and it was there that then I saw New Relic was telling me, "Hey, you have a page that's taking about 14 to 15 seconds to load." And I thought, okay, I feel validated now that at least New Relic is recognizing this issue. I have seen this issue, but I still didn't know why it's occurring. +So the next tool that I used that I don't know if I've used before or it's just been a very long time; it felt fresh in the moment, but it's the Chrome DevTools, the performance tool. And so you can open that up in your inspector, and then you can go to the page that you want to track the performance. And then you can essentially say, "Hey, go ahead and start profiling and reload this page." And it has so many stats when it finally does load. It has CPU flames charts, which essentially it visualizes a collection of all the stack traces. It has a film strip, so you can actually see the rendering progress of your website along different time points. So if you wanted to go back to a specific time, you can see what did the webpage look like at this point? And then if you go a little further, okay, how much was loaded at this point? So there's a lot of interesting and a little overwhelming information that's there. +But the thing that did catch my attention is there's a chart. I don't actually know what this chart is called. It's not a pie chart because there's no center to it. So it looks like a donut chart, and it's broken down. And it shows you the loading times, scripting, rendering, painting, all of those different values. And the rendering time was taking 35 seconds. And I was like, ooh, okay, that is meaningful right there. So then further investigation, now that I knew what I was looking for, I wasn't looking for something more on the back end. I was looking for something more on the front end. And I didn't think it was necessarily JavaScript because we also have JavaScript on this page. So at least this was helping me get a little bit closer before then I went into the codebase to start seeing what's happening. +So once I knew it was a rendering issue, I went to look specifically at that view, and we have a form on that page that was generating an empty HTML select option for every record that's in the system. So let's say that you're ordering from a restaurant. On this page, there was a form where it had a list of all the restaurants, and, in our particular case, we had about 17,000 restaurants. So there were 17,000 empty HTML selection options, which could have some significant impact on the DOM and page load time. And that was the piece that was really leading to the performance, is the fact that we were rendering that empty select option. +So from there, it was then just triaging okay; we don't really need to render all of these restaurants. There are ways we can scope this down. And that way, we're only showing a little bit at a time versus creating all of these empty options. I should clarify they're empty because part of this form is you select from the first dropdown, and then it populates the other one, and it gives you more information. But the way that this form was implemented, it was actually trying to show all of them at once. But it didn't actually have the data yet, but it was doing like a restaurant.all type of count. And so then that's how we were getting that many empty options. +So it was a very interesting journey. It was very helpful to learn that New Relic has this browser monitoring tool. And I really appreciated their performance tool. And circling back to Chrome, Safari may have something similar. But I found Chrome's performance tool very helpful because then it helped me realize that it was the rendering. And so then I could really focus on the markup and the view versus knowing it wasn't more in the database layer. +CHRIS: I really love the description, almost like a mystery novel of these bugs when we encounter them. Because if you just get to the end and you're like, oh, I was rendering a select, and it had all of this, that loses so much of this story because again, the coding is not the hard part of the work that we do; it's the figuring out what needs to be done. And in this case, that journey that you went on to find the bug. I really like the point where you said, "And someone mentioned this page has just been getting progressively slower over time." I was like, ooh, that's interesting. Now we got a clue. Now we've got a lead, and we'll chase it down, and then finding the browser tools and all of that. +And also, as an aside, browsers are just such an immensely impressive piece of technology, everything that they do. And then you add the DevTools on top of them and magical stuff going on there. But yeah, also probably don't render 17,000 empty selects. [laughs] That seems like it will get you in trouble pretty quickly. But also very easy to get to and especially if there is this incremental, slow creep over time where it's like, oh, that page seems like it's a little slower. It's a little slower still, and it just keeps creeping up over time. But yes, I appreciate you taking us on that journey with you. +STEPH: Yeah, it was a fun discovery. And it made me realize that while we have alerting set up for some of our other queries, we don't have anything set up for the browser time. So that would be a good optimization on our side is to start alerting us before a page gets to the point that it's taking that long to load to notify us sooner. So we don't have to wait for a user to reach out to us, but we can triage sooner. +CHRIS: I also do love the idea of extending the metrics that we hold ourselves accountable to all the way through to the user, and so the First Contentful Paint and all of that. The one that I really love recently that has captured an idea that I struggled to put words to is the Cumulative Layout Shift. Are you familiar with this piece? +STEPH: Uh-uh. +CHRIS: So there's like, how quickly does the page render? That's the thing that we want to know. But a lot of applications these days, particularly single-page apps, render pretty quickly, but they render what ends up being a skeleton or a shell of the page. And then behind the scenes, there are like ten different AJAX requests happening. And as the data comes in, suddenly, a part of the screen will render. And they'll render a list of items that they just got back from the back end, but they're still waiting for the information to populate the header. And so if you look at that page, it's constantly shifting as it's loading and just feels, I don't know, flimsy in my mind. But I didn't have a good word, or I didn't have a metric or a number to attach to that. And then I learned about Cumulative Layout Shift, and I was like, oh, that's the one. Now you've mapped the thing that I was feeling. And I like when that happens. +STEPH: Is that the difference between the first paint and First Contentful paint? Is that similar? +CHRIS: I think it's more than that because there are not just two discrete events in this. It can be multiple. And so it's like, how many different times did the thing that's rendered on the screen move around? And so if images are loading, but you didn't have a proper image height and width set, that's another way that this can happen. Then initially, the browser is not going to reserve any space for that because it's like, I don't know how big this is. And then, when the image shows up, it now knows the intrinsic height and width of the image. So suddenly, your page is going to jump from that. You can get ahead of that by putting the height and width on your image, and that's great to do. And frameworks like Next.js have done some really amazing work of making that a build time step as opposed to something you have to do manually. +But then also, more generally, how do we handle this? React is doing some interesting work with Suspense, where you can aggregate together multiple different loading states into one collective thing. It's almost like promise.all, but for your page. I haven't followed that too closely, but I know that that's framework-level work that's happening over there. GraphQL does a really great job of allowing you to group queries together. So there's a solution on that side. But broadly, if you just render some HTML on the server and you send it to the front end, then you don't have this problem because you just have one ball of HTML. The browser is pretty good at rendering that in one pass versus if you have single-page applications that are making a handful of AJAX requests that will resolve in their own timelines and eventually paint to the screen. You get this different shape. And then the worst case of it in my mind is you render half the page. And then suddenly, one of the requests realizes the JWT has expired, and suddenly, you get thrashed over to the login page. Please don't give me that experience, developers, please. Please do something else that isn't that. That makes me sad in my heart. +STEPH: Prioritize the failure state. That's what I'm hearing. +CHRIS: Callbacks. +STEPH: Well, on that wonderful circular reference, shall we wrap up? +CHRIS: Wait, I thought circular references were bad...Never mind. Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed, or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeee. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + This week Chris talks about Bifunctor optics and introduces an app he's been liking recently called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX.

+ +

Steph talks about her experience using New Relic Browser Stats to troubleshoot a slow page and burnout. Who's feeling it? (Raise your hand.) How do we identify it? What do we do about it?

+ + + +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. And we're off the rails already, everybody. It's going to be a good one. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going?

+ +

STEPH: Hey, Chris, it's going really well. We talked recently that I have a new laptop. So I have been migrating the things that I'm accustomed to over to my new laptop, but I also love that clean, fresh start. So as part of that fresh start, I was like, what if I use Safari? What if I just switch? I'm a Chrome user, for the record. I'm pretty sure you know that, but just to share that. I was like, well, what if I just switched and I try out Safari for a while? So that was the thing.

+ +

CHRIS: So I heard the words try and the phrase that was the thing, but I'm going to probe a little deeper. How'd that go? Was it good, great, not so great?

+ +

STEPH: Honestly, it was fine. I did enjoy being in a new environment to see how Safari handles bookmarks and then also the inspector. So it was novel to be in a different browser where I really don't spend much time in a different browser other than when I need to test this specific UI bug or things like that.

+ +

But the reason that I ended up migrating back to Chrome was frankly for Chrome profiles because I really like that I can have this clear separation now between my work life and my personal life, and then it also keeps me signed in. So my personal email versus my thoughtbot one versus before the Chrome profiles, which I'm not sure how recent of an addition that is where Chrome introduced that feature. But before, I just always had to be signed into both, and it was just all together in one spot. But now I really like that I can separate. And it's more intentional where I'm like, oh, I'm going into work mode, so I just want that profile versus I do need to hop over to my personal side for a while. So that was the thing that brought me back.

+ +

CHRIS: Interesting. I don't take advantage of that at all. I know of the feature, but it's never really called to me. And if anything, I do the opposite. So specifically, this doesn't work in the browser, but on my phone, I use the iOS Gmail client, and I use the unified inbox. So I just have everything come together. And I subscribe to the idea of, I don't know, it's all work and stuff. And hopefully, people aren't sending me a lot on the weekends, and I will defer and snooze and all of that. But that holistic view pulls me in. And so it's interesting that you're just on the other side of that. It totally makes sense. I actually think I'm wrong here. I think I'm doing the wrong, bad thing. But it's interesting just the way we're on the two sides of that.

+ +

STEPH: I can see the merits for your approach where it all goes to one place. So you have one place to go and triage, and I think that makes total sense. I haven't triaged my personal life well enough that I want it to come into my work life. And that's the one that needs the more immediate response typically. So I want to prioritize all of my work emails and focus on that and then have my personal ones more like, okay, I've got some time, and I want to check on this. But I don't want to blend those together. Because frankly, I need to do some more triage on the personal side if I'm just going to bring it all into one space.

+ +

CHRIS: Interesting. Yeah, I would almost view it from the other point of view of I want to protect my personal space, and this is obviously not what I do based on what I just said but protect my personal time so that when it's evenings or weekends or whatever, that I'm not seeing work emails in there. I do my best to snooze them and get them out of the way. But if they are coming in, maybe there's something I need to respond to or, I don't know, maybe it's FOMO in a certain way, FOMO but professional FOMO. I don't really know. It's interesting that that's the feature that brought you back. But overall, how was your experience using Safari?

+ +

I have heard loosely that now most of the browsers are evergreen; even Edge has really caught up and is now implementing features in a similar way. And so Chrome, Firefox, and Edge are very similar. And my understanding is Safari is the one that actually lags behind or even holds back web standards and implementations and things like that. So, did you find any rough edges of that sort, or was it otherwise just fine, and it was mostly the profile stuff that made you switch?

+ +

STEPH: It was honestly just fine. I also may have not used it long enough to run into any of those rough edges. But overall, it was just fine. It worked. I just got to that point where I've run into this situation before where I'm signed into my personal email, and then I'm signed into my work email. And then I'm going to Google Hangouts, and Google Hangouts gets confused, and it's like, which person are you? And then I have that moment of where I have to sign out of one, or sometimes it just gets complicated. And what I found with profiles is that that's just never an issue. I don't have to worry about it anymore.

+ +

So yeah, overall, Safari was fine. I wouldn't mind going back to using it. I just really like the profile feature. This was one of those moments where it helped me notice how much I really liked that feature because I had just opted into it a while back. But this was that moment where I was like, oh yeah, I really miss that. So I'm going to go back to it.

+ +

CHRIS: The thing you said a minute ago about which person am I? [chuckles] There's a deep philosophical underpinning there, but I've definitely struggled with that and trying to trick the browser into it. So Trello is the one that I'm struggling with that right now. I am one human in the world, I assure you. But GitHub gets this; GitHub plays the game correctly where I'm one human, but I have multiple internet identities. I am the work person. I am the open-source person. And I'm able to route notifications and things to the different inboxes based on the organization that they're part of, et cetera. And I really liked that, that GitHub seems to understand that I am a human that is multifaceted, whereas Trello does not. And so I use Trello in a professional context a lot, but it's my personal...like, I would have to create a distinct account on Trello. And I'm like, Trello, that's not true; I'm still one person. Just understand this Trello organization is a separate facet of my existence. Got on my soapbox on that part.

+ +

The other thing I want to say is I do feel bad about the fact that I'm just on Chrome. Because increasingly, Chrome has got so much of the market share, and it's becoming the new deeply dominant thing. And so I want to be the agent of change or like, no, we should use different browsers, and we should support them and make sure that we're testing against them and all of that. And then I'm just on Chrome all the time, and I feel bad about it. But it's one of those like; I have so much muscle memory and built-up knowledge around how to use Chrome. And I've just used it for so long now that the switching cost would be pretty high, I assume. I actually haven't even really tried, but I feel bad about it. I'm now saying two things which are I feel bad about it, and I've never even really tried. So I don't feel great in this moment, but these are my truths.

+ +

STEPH: [laughs] Well, I can plus-one your truths. Those resonate with me. Well, there's always stuff that I am trying that's new all the time. So I feel like I need some constant in my life until I'm ready for other things to be the constant in my life. And then I can muck around with which browser I'm using and change other things. And you have to be in that moment. You have to be ready for it.

+ +

So going back to a thing that you said a minute ago about separating your work life and your personal life, I very much like that framing, and that's a nice segue, frankly. And it's something that I've been thinking about where you and I often start with technical topics. But I have a very people-centric topic that I'd love to chat with you about today, and it is emphasis on burnout. And who's feeling it? How do we identify it? What do we do about it?

+ +

And that's been very much on my mind because I have noticed a lot of people around me, including myself; I just feel like we are more inclined to experience burnout right now or are going through it actively. And it feels even more important to have those conversations with each other and with ourselves to talk about what does it look like when we're burned out? How do we recognize when we're there? Because often, when we are burned out, it's not something that happens gradually, or at least it's not something that we notice happening gradually. It's like, okay, I'm fine. And then suddenly, okay, I'm burned out. And I'm at a place where then I can't really focus. I feel overwhelmed. I'm drained.

+ +

For anyone that is less familiar with burnout, one, hooray, and then two, burnout is a state of emotional, physical, and mental exhaustion that can be caused by excessive and prolonged stress. So then that's what leads to us feeling very overwhelmed, emotionally drained, unable to meet constant demands, or those are the things that are causing our burnout.

+ +

So I have been doing what I typically do when I'm thinking about a particular topic, and then I'm looking to gather knowledge and information is I try to go pretty wide where I start looking for podcasts, books, just people that are having similar conversations and trying to synthesize a lot of the information that they're sharing. And I have found some really good stuff. The question is now, what does one do once one has that content, and then how do you bring it back and help apply that content to yourself and then people that are around you? So I have some thoughts there, but before I go further, I'm curious, what's your experience with burnout?

+ +

CHRIS: I think for me, I've been somewhat lucky in that I don't think I've ever really got into an acute period of burnout, but I've definitely had periods where I just felt weighed down. And there are ebbs and flows of life, and of work, all of those things. There is something that I've been thinking about recently, which is the inherent nature of the work that we do where consistently we're working on something where we don't quite know how to do it, and we're struggling, and we're struggling. And finally, we figure out how to do the thing, how to trick the computer into doing what we want. And then the minute we do that, in trying to encode, ideally, we're automating that away. And we take that solved problem, and we just ship it off. And then, we pick up the next unsolved problem from the list. This isn't entirely true, but it feels like sometimes unspecificity in sort of I'm just working on things that are underdefined, underspecified, and I'm trying to solve little puzzles constantly. And, I don't know, I was feeling that recently of the nature of the work was burning me out.

+ +

And I think earlier on in my career; I definitely experienced this in a certain way. And then, in the middle of my career, there was this perfect inflection point of my skills and the level of tasks that I was going for. But then, the further I got into my career, the more I tend to take the weird underspecified stuff and anything that's relatively clear I'm giving to other folks on the team. I'm like, "Oh, here's this well-defined piece of work here. Can you go implement this admin page?" Whereas I am doing the investigate integrating with third-party platform XYZ that uses a SOAP API that isn't documented. I'm like, okay, cool. Let me roll up my sleeves and figure out what that means. And I noticed in my work that that was starting to weigh on me, and I was able to shake that off and shift around some of the tasks that I was doing.

+ +

But that was a particular form where the work itself was weighing on me. And I took a step back, and I was like, why do we do the things that we do as developers? Because there's something just fundamental like, you have to enjoy that nature of challenge and constantly escalating challenge to a certain degree, I think, to really like this work, but it can be a lot sometimes. So I feel like maybe that's a slight digression from the topic, but it was a thing that I was feeling in this space. And that's a little bit of my story.

+ +

STEPH: Well, the beautiful thing about that is it highlights everybody experiences burnout differently. So that could really be how someone is experiencing burnout where they're taking on all these very complicated, different tasks, and they're feeling just worn down by that and that they're not able to meet demand. And they get to that point where maybe they lose their interest in tech and coding because they have pressed too hard in one direction. And so then they need to take a step back.

+ +

As for me, I've been thinking back over the last couple of months because there was once or twice where you and I had, I think a conversation here on The Bike Shed where I shared that things were okay, but I didn't feel like my normal self. I was losing some of my interest and energy for technology and coding. And I'm very fortunate; I love what I do. So the fact that I wasn't feeling that interest was a really big sign to me that something's different; something feels off. And it does vary depending on the client that I'm working with. And I think feeling that burnout then was a mix of some of those client pressures that I was feeling and that I was working perhaps too many hours as I was very interested in that client's success.

+ +

And then the other stuff was more personal because we only have, to borrow from the spoon theory, we only have so many spoons to give. And so if you have a lot going on in your personal life as well, that's going to detract from the energy that you also have to give to work. Are you familiar with the spoon theory?

+ +

CHRIS: I am not.

+ +

STEPH: I recently heard about it, and I can't stop using it now because I really like it. But it essentially...and there's a really great article that we can link to so others can read about it because I'm not going to remember exactly who came up with this theory. But the idea is that each spoon represents a unit of energy. And let's say if you start each day with only ten units of energy and you use spoons to represent that, as someone needs energy from you, maybe it's work, maybe it's a personal commitment, maybe you're dealing with a chronic illness, then you are giving a spoon away to each of those. So at some point, you're going to run out of spoons. And you want to also be mindful of who you're giving these spoons to because you are giving that energy away.

+ +

CHRIS: I definitely liked the idea of we start each day with a certain amount of energy, and different things can pull from that pool and whatnot. I'm intrigued by spoons as the unit. It just feels like a weird...I got this little bag of spoons that I walk around with, [chuckles], and I give them out throughout the day. I guess it could be anything in there, you know, objects. But, I don't know, spoons are interesting to me.

+ +

STEPH: I think it's because this person who came up with the idea was literally having a conversation with their friend in a cafe. And so that was just something that was in front of them. And they're like, oh, I can use spoons to represent. Well, we'll have to double-check the article to make sure, but I think that's why spoons became the representation.

+ +

So circling back to once you're in burnout, what do you do with it? And that is one of my questions right now. And that's what I'm trying to synthesize a lot of information around. Because once you're in that state, I don't know of a lot of great ways to help other than take time off because, at that point, you're in a crisis state. And you need to step away, and you need to find out how you can recover from having entered this state of crisis. So that feels really important to identify ways that once someone is in that state, that then we can help them. And that feels good. We can advise someone to take PTO. I still don't feel great about it in terms that then, as a manager myself, I don't really know of other helpful ways to then help someone through that period.

+ +

So then I really started thinking about the fact that once someone is in that burnout stage, frankly, it's too late. We have let someone get to that point that now they are in that crisis instead of addressing it early on. So that is the other thing that's on my mind is one, how do we help people that are already in that crisis state? But then two, how do we start identifying that someone is starting to go in that direction? And then how do we help them tell us? How do we then triage those situations? How do we prevent them from getting to that burnout state? And that's where I've also found some really good content.

+ +

And specifically, there is a podcast that I've started listening to called The Burnout Show. They essentially share their experience with burnout, and what they did about it, how they recovered from it, and then how they continue to fight it because a lot of people then still go back to the workforce. So then, once you do find a way to recover, then how do you go back to work? And there have been some really great episodes. And I'll be sure to include a link for it in the show notes.

+ +

There's one particular episode with Grant Gurewitz, who is a guest on the show. And he speaks specifically to the strategy of Three Good Pockets. And this speaks to the idea that there are many things that we can't control in our day. It could be work, family, other commitments, but we can strive for Three Good Pockets of time where we focus on something that's just for us. This is time that's reserved for you and any activity that you find restorative or joyful. And each pocket can vary in size. So perhaps that first pocket is spent just reading a few pages from a book that you're enjoying, and then the next pocket of time is spent outside or calling a friend.

+ +

And Grant also has a great suggestion around if you're worried that you'll get sidetracked and not actually step away, which I felt called out for that one because that one's definitely me. I will have good intentions, but then I won't actually take the break that I set for myself. So Grant recommends creating a list of restorative activities so that way when it is time for that break when your calendar is reminding you, then you have a list of these activities to choose from. So it makes it easier to say, okay, then I can do this for a couple of minutes, and I can truly step away from work and step away from my screen.

+ +

But especially now, when so many of us when we're sharing our workspace with our restorative space, for everybody who is still working from home or working remotely, then creating those daily breaks are incredibly important to our wellbeing. And so, it has me thinking about what restorative activities can I add to my day? How can I encourage other people to add more restorative activities to their day? So I really appreciated that advice.

+ +

And I have noticed that the idea of burnout, but not so much burnout specifically, I've been thinking of it as recovery and balance is a theme for me. And it is something that I am purposely choosing as a theme right now where I want to research and understand more of how we handle these situations and continue to make progress not just for myself but also for my team.

+ +

CHRIS: I think finding that right cadence and structure and way to reinvest in yourself and ideally gain more spoons if that is at all possible or at least defend the spoons that you have, those all feel very meaningful.

+ +

I do have a question. I'm interested in your thoughts on this. I feel like we hear about burnout a lot in our industry. I get the sense maybe that it is a more common thing. Like, I hear so many developers talking about how their dream is just to give up tech and go get a cabin and just farm in the woods or something like that. And I wonder, is it a more pervasive thing in our industry? So that's one question.

+ +

Another is just an observation that we actually do work in a wonderfully...it's an amazing industry where being a developer, there are so many jobs out there. And I don't want to discredit anyone's efforts if they're earlier on and struggling with that. But broadly speaking, it is a developer's market trying to go out there and get jobs and extremely well-compensated, as a general rule. But does that come with this inherent burnout? And if so, which I'm not sure is true, I wonder if maybe we're just more vocal and maybe we actually share more in public. We have more blogs and podcasts and things like that. And that's just a common thing for developers, and so we hear the stories more often, whereas maybe in other industries, it is actually very common, but people are suffering in silence.

+ +

But also I do wonder, our industry is still so young. The work that we're doing is changing constantly, and that churn and that working in the unknown maybe there is an inherent nature. So that's a bunch of pontifications off the top of my head. And I have no idea what the answer to any of them is. But I am intrigued because it does feel like the shape of burnout as a concept in the developer world is perhaps a little overrepresented, or maybe it shows up more than I would expect. And, I don't know, is the work that hard? I don't know. But then I hear these stories constantly, and I definitely have felt it myself, so maybe.

+ +

STEPH: Yeah, maybe. Yes, I do think the work is that hard for the record. It's challenging work. I enjoy it, but it is challenging work between figuring out the tech but then also everything else that comes with that.

+ +

I don't have anything to back this up, but I suspect that a lot of other industries are also experiencing burnout. And I just happen to be more aware of it right now because I'm hearing it more from my friends and the people that I work with. And I suspect that's more directly related to we all just went through 2020, and probably a number of us were trying to forge ahead and get through that time. And so there may be a lot of us that are just now dealing with those consequences of where we just pushed ourselves through a very hard time. And now a lot of that is manifesting and surfacing around really identifying the damage that we may have done to ourselves by just prioritizing work and trying to put our head down and get the work done even though there was so much happening around us.

+ +

And I suspect that may be a contributing factor is that now people are really starting to recognize, like, oh, I feel this way. And maybe there's time for me to address it. Or frankly, it may not even be that there's time, but your body is just like, okay, I'm done. I made it through the past year or however many months, and I'm going to start shutting down on you. I've given you all the warning signs, but now we're here. We're at a breaking point. So I don't know about the other industries, but I do know the reason that it's more on my mind is because I'm just hearing it more from people, and they're just expressing it. And so, it has become more of a focal point for me, and I've experienced it myself more recently.

+ +

I'm sure I experienced this back early on in my career, but I took a strategy of well, I'm just a junior, and I just have to get through this. And I have to build experience. For the record, that is not a healthy mentality. I'm just being honest about where I was in my life. And so, I didn't really stop to think about it, but perhaps it is becoming more normalized where people are having more open, honest discussions about where they're at. And if other industries aren't talking about this, I would love for them to.

+ +

So to round that out a bit, this is something that is just very interesting to me. It's very top of mind. So I suspect I will be sharing a lot more content in future episodes that are just around this. How do we recover? And then how do we balance? How do we work hard without burning out?

+ +

CHRIS: Work hard, play hard; those are the two placards that you have. Well, I look forward to continued conversations on all of those topics because they are sort of that's the story that underpins all of the work that we do. So I'm very interested to chat more about that.

+ +

STEPH: Thanks. So what's going on in your world? How's your week been?

+ +

CHRIS: Oh, my week has been fine. My topics are going to be way more mundane and tech-focused. But let's see, a couple of things, so one is that Stack Overflow has their I think it's Annual Developer Survey. And this year, the results came out, and there was an interesting standout, which was that Svelte was the most beloved framework, which was very exciting to see. Granted, you always have to take these sorts of stats with a grain of salt.

+ +

But Svelte was 71% loved and 23% dreaded, which they give it as a ratio of how many people really love this thing versus how many people really hate this thing. And so Svelte, 23% of people who have used it are like, I hate that, but 71% loved, so that's a 48% net approval rating. Versus React which was 69% loved, 31% hated or dreaded as the word would be, so that's a 38% net approval. And then Vue, interestingly, was 64% loved, 36% dreaded for a 28% net approval rating. So, yeah, Svelte was decidedly winning in that.

+ +

But again, the big grain of salt there is looking at the usage stats. React has 40% usage. So of all the respondents, 40% of the people responding to the survey were like, yeah, I've done React professionally, which is a wildly high number for a JavaScript framework. Vue was at 19%, so roughly half of React's usage, which I'm actually impressed that Vue is that high. And Svelte came in at 3%, so it's definitely still in the early adopter strong fan phase. So it makes sense that they would have this outsized high rating. I'm actually surprised that Vue wasn't higher than React, given that. Because I feel like more people are cajoled into React versus Vue can be more of a choice. And I would have expected this to shape out a little bit differently, but yeah, that's the story.

+ +

STEPH: That's really cool. I liked how you described that as in the very early adopters’ strong fan base stage.

+ +

CHRIS: But nonetheless, the people that are using Svelte do seem to really like it; that’s coming through in these numbers. And that definitely is my experience. I love Svelte and would love to continue using it for as long as possible. But really, I want a lot of other people to start using it. I want to really grow the usage base so that there are more libraries, and frameworks, and blog posts, and just mindshare in that space because I really do believe there are some wonderful ideas in Svelte. And it's just so straightforward to implement things that I just want more people hanging out. So that's one quick thing.

+ +

Another quick thing is, I've been using a utility lately or a program called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX, and it is just fantastic. So I can capture a screenshot. I can capture a window. You can capture a GIF or a video. And then you can do little trims and annotations. And then it has this really nice feature where after you take a screenshot, it just hovers in the bottom corner of your screen and is easily accessible. So if you take a video, and then you want to upload it to a Trello card, it's just floating there waiting for you. You can actually dismiss it and push it down, but it's still peeking up from the bottom of your screen, and you can pull it back up, and you can have a couple of them. But it just really makes the whole workflow of grabbing screenshots or videos so easy.

+ +

And I cared deeply about that because now that I have this tool, I'm all the more inclined to grab a screenshot or a video with just about every piece of work that I do. So it's going into pull requests; it's going into Trello cards. And it's so nice to have a utility that just really makes that as easy as possible.

+ +

STEPH: I really liked how you mentioned that you can annotate because I often...I'm laughing as I'm thinking about this. When I am taking a video of something that I'm going to share with someone, I will use my mouse to indicate, oh, this is important. And so I circle around it and do silly things with my mouse to try to indicate but being able to annotate would be so much nicer.

+ +

I know there is another tool that you're really excited about that I can't remember off the top of my head right now. Do you know the name of the tool I'm thinking of?

+ +

CHRIS: Was it Loom?

+ +

STEPH: Yes, Loom, because I also used that for a little while, and I've really enjoyed it. So I'm curious, how does Loom and CleanShot X stack up? Is one replacing the other, or are they complementary tools?

+ +

CHRIS: Mostly complimentary. Loom is great because it hosts the videos, and you can also do audio capture, although I wonder if CleanShot has that as well. CleanShot also, I think, has a hosting thing. So I think there's a strong overlap in their functionality, but right now, I'm using both. And definitely for screenshots and things, CleanShot owns that end of it. And I think it's more likely that I could have CleanShot as the entire tool that I'm using. But I'm still using Loom for this is a walkthrough where I'm going to talk to you about a thing. I want to make it available at a URL that everyone can see rather than actually getting a GIF or MOV artifact file on my computer. So ever so slightly different, but I think of them, CleanShot X is probably the ideal one. But yeah, I'm still reaching for both.

+ +

So the one other thing I did want to talk about is I have been expanding our use of the dry-monads within the project that I'm working on. And I've done some things. I did some stuff, Steph, and I think it's good.

+ +

STEPH: Shtuff with Shteph. [chuckles]

+ +

CHRIS: Shtuff with Shteph, yeah. I'm definitely pushing the envelope of how much we're leaning on these concepts within the app, and I continue to question it. I'm really intrigued to see what happens when other folks come into the project, and they're like, "Why can't I just get the value? It should be a string. Why isn't it a string? Why is it a string that I have to do a ceremony and a dance to get at?" And I'm like, "Well, because everything can fail, you know, like life."

+ +

But what I have done here so dry-monads is the project that we're using, particularly their result type. So the result represents something that can either succeed or fail. And so we either have a success, which is this wrapper around the value that's successfully executed. So say we make an API call, we get back a response. If we get a 200 or maybe even a 300, then we get the data, and that's a success, or we get a failure and the error message. But fundamentally, we're modeling that in our system in a way that downstream from that, we have to basically determine if it was success or failure. So we're really encoding into the system; listen, pretty much everything can fail, so let's be careful with that. Let's be intentional and purposeful with it.

+ +

But there is an interesting thing where these objects have fmap as a method on them. So fmap is a way to transform that wrapped value, but fmap works specifically on the success case. So if you make an API request, you get back the data. Everything's great. You can call fmap, and it will yield into a block that data. You can transform that data in some way, and then it will rewrap it up as a success object. So you can operate on this thing as if it has been successful. But in the case that it's a failure, it will just ignore that transformation because you don't want to transform the failure. It's going to be a totally different shape of data. So you want to separate those. We're getting into functors and monads here. So I'm going to handwave a bunch. But fundamentally, that's the thing that we're going for here.

+ +

But we found ourselves really wanting to work with both sides. So we make this API request, and in the case that it succeeds, we actually want to transform and actually slice out a piece of data from the nested object that we get back. So that's one transformation that we want to apply on the success portion of the aisle. But then, we also want to transform the failure message. It turns out this backend is giving us very unfriendly error messages. So we want to take those and transform them into friendlier user-facing error messages.

+ +

So it turns out we want to map both sides. And so I went to dry-monads, and I was like, what do you got? I want to know about this in the world. And it turns out they did not have anything. So I started looking into it, and it turns out this is a concept in the world of functors, specifically. Or, more specifically, I reached out to a former colleague, Sid Raval, a former thoughtboter as well. And he likes the functional programming stuff, so I knew he was the right person to ask about this. And he pointed me at bifunctors. So I found myself in a new space and category theory which I never thought I would explore a category theory in this way, but here we were.

+ +

So a bifunctor basically is exactly what I was talking about where there are these two branches. In our case, it's either success or failure, but it allows you to operate on both sides, both branches. So the method or the function that gets applied there is bimap. So it's fmap which I don't know why it's f why that's typically what it's called. Success map would be a really great word in this context in my mind. So success map only deals with the success side, but bimap takes two different transformations, one for the successful outcome and one for the failure outcome. And it allows you to very directly talk about what you want to do with that.

+ +

To be clear, dry-monads has a function called Either or Either, depending on how you want to pronounce it. And that takes two Lambda proc-type things because it's Ruby, and functions are kind of weird in Ruby. But it yields you either the successful value or the failure value, but then it doesn't rewrap them. So it's meant to be the terminal. You use that in a controller when you're either redirect or render or whatever it is you want to do. What I wanted was something for mapping, so staying in the success object or the failure object but yeah, bimaps. So I introduced my own extra wrapping layer. This is where things go off the rails, I think. We now have our own internal result objects.

+ +

I thought about monkey patching for a while. I convinced myself monkey patching was a bad idea. Now that I've implemented as an extra layer of wrapping and I got the wrapping wrong like four times, or I kept recursively wrapping and re-wrapping, and there's a reason people aren't supposed to write these things themselves. But I think monkey patching may have been a better idea here, or maybe I should have never done any of this. We ended up with a stable working implementation and a nice test suite that covers it. But I introduced bimap and failmap as two different methods on our success object. And I did it by doubly wrapping the result objects. So we have our internal result, which wraps the dry-monad result. And I'm worried about that future situation where a junior developer comes on the team and is like, "I don't know what any of this is."

+ +

STEPH: I love the weekly progression of I've done some things, and let's talk about it. And then seeing this glimpse into your argument with yourself as to yes, but we need it, and we want it, and it's not something that's defined. So let's go ahead and implement it. You ended on a high there where you talked about the fact that it is nice to work with. It does the thing that you'd like it to do, and it's well tested; I love that part.

+ +

I'm deciding which thread to go with because there were a lot of interesting bits in everything that you shared. And I'm intrigued about the monkey patching as to why you think that could have been a better approach. Could you talk more about that one?

+ +

CHRIS: Sure. So I ended up having to introduce the secondary object that then wraps the result. And so if you poke at that even a tiny bit, you start to see this like Russian doll nesting of it's our result wrapping a result, wrapping a value. And it's a burrito with three different tortillas wrapped around it. And if you want to add guacamole, you got to unwrap all three burritos. I'm sorry, this is a terrible monad joke here. [laughs]

+ +

STEPH: For the record, if Taco Bell is not offering that, they should now, now that you've created that. [laughter]

+ +

CHRIS: There is one, but there's usually cheese in between the layers. They're not just extra layers of tortillas, so that's what I've got here. It's way too much tortilla, and that's sad. You don't want that. And it's confusing. You're like, wait, does this one have two or three layers of tortilla? So when I was working on it and when I was implementing our additional wrapping layer, I tricked myself multiple times. And my test suite was telling me that things were working, but I was testing incorrectly. And I was like, oh man; this is very subtle. And even though I'm deeply immersed in the context here, I'm still struggling with this.

+ +

So the question is, did I successfully encapsulate all of this? And now anyone downstream just gets to use it,, and everything will be fine. Am I the heroic programmer that made the perfect abstraction that no one's ever going to struggle against, or was that pain that I was feeling representative of the complexity of what I'm trying to do here, and maybe I got it wrong?

+ +

And so then the monkey patching side is we've got this one layer of wrapping. What if we just monkey patch the result such that it's got these new methods? I'm not adding an additional layer. I don't need to deal with double mapping through multiple layers, and I just get to deal with the context that I have. So I did an initial spike of an implementation that way, but I talked myself out of it because #monkeypatchingisbad, but I don't know. I don't know where I'm ending here. I am happy with where we're at, but I am aware that I may be sad down the road.

+ +

STEPH: I'm just dying over here [laughs] from everything you're saying. I have this image of you staring out the window thinking, am I the hero, or am I the villain? And figuring out who you are in this scenario with this abstraction that you've created.

+ +

CHRIS: To be clear, it's raining, and I have a nice rocks glass of scotch in my hand. And I'm just wistfully looking out the window trying to determine what's true. That's pretty accurate, actually. That's pretty much what's going on here.

+ +

STEPH: I think we're just going to need updates as it progresses along.

+ +

CHRIS: I will say overall this paradigm...so failures can happen at all levels. These command objects, which are the core of where this is coming in in the application, really represent the workflows of the app in a wonderful, testable, straightforward way. So I love that part. And if I have that, it implies that I have to have this other stuff. I don't think I can get away from that.

+ +

The other thing is I've always loved Gary Bernhardt's Functional Core, Imperative Shell, which is a conference talk that he gave a while back. I talked to Gary about it actually when he was on the show, and we can link to both that and the conference talk because they are fantastic. And I just love the way he thinks about software. But that was always a little bit abstract for me. Like, what does that actually look like, though, in say, a Rails architecture? And I didn't have a great answer.

+ +

And now this thing that I'm doing is the closest I think to that where the innards of the system are almost functional even though it's Ruby. We're leaning into that. And so we have these command objects that take in some data, and then they operate on it, and they yield out these results. Did it go well, or did it not? We've got the railway-oriented stuff, which again I'll link to. I link to now every third episode, apparently, but here we are. And that just models the reality of these programs in a really great way.

+ +

And then we've been trying to introduce some, not rules per se, but guidelines as to how we interact with these things. So inside of the core of the application, we're trying to be as functional as possible. We do transformations on these result objects, but that's it. And then it's only really in the controllers or the mailers that we are doing unwrap or deal with the actual nested value, but everything else is working on conceptual values or whatever it is…these result objects. And that's actually been really nice, and it's allowed us to have really nice error handling within the app. The logging is very straightforward. A lot of apps that I've worked on in the past, I've just silently thrown away many error cases or edge cases. And this is a really great way to sequence the work that needs to be done but never throw away data that you would want. And so far, I'm finding it to be really great. And I'm seeing very obvious ways to hook into it like, oh, this is where we need to find the user-facing error message versus this is where we figure out what we want to log. And so, in some ways, it's great, but I am still open to the idea that this was a terrible idea. I always remain open to that idea to be clear. [chuckles]

+ +

STEPH: I love how that's the feedback that you're always open to it. You're always trying something new, and then you're constantly going back to revisit; was this a good idea or a bad idea?

+ +

To go back just a little bit, I do absolutely love the priority and focus that you're giving to the failure state because I feel like that is an area that we, as developers we're very skittish of that failure state. And I realize I'm projecting here. So if you're listening, feel free to take that however you like; maybe it doesn't apply to you, maybe it does. But the failure state is like you said, it's life, it's important, and it's something that is going to happen. And it is something that we should make accommodations for.

+ +

And I find that we're often very hand-wavy with a failure state. So I love, love how much you always prioritize the failure state and make that something that people can work with and understand. Versus then when something goes wrong, then that's when we have to start to understand the failure state. I recognize there's a balance there because you're not going to know the failure state until you encounter it, but there are ways that we can still optimize to have observability into that failure state for when we do encounter that failure.

+ +

CHRIS: I've definitely seen that as an evolution in my own thinking, how much am I focused on how easily can I do the core thing, the happy path versus how robustly can I do all of the variations of what this app needs to do? What if the network's down? What do we do there? I do occasionally worry that I've overcorrected on that. And it's like, you know what? This thing that I'm worried about that I'm protecting against in the application is a 0.01% edge case. It's going to affect almost no users, and we're both putting time into trying to avoid it. But also, there's code complexity that comes from trying to handle all the different variants. And so there's definitely an optimization, and I feel like, at different points in my life, I've been undercorrected or overcorrected on that.

+ +

But I think if I were to describe the arc of my career, it is desperately searching for that optimal path and trying to find exactly the right amount of error handling to apply, and then yeah, then I'll be happy, then it'll be great. But it is like when I look at DHH's classic 15-minute I'm making a blog, look how much I'm not doing, I'm like, sure, sure, sure. Show me that in three years, though. What does the blog look like? How easily can I add a new feature? What happens when there's a bug in production, and a user reports it? Can I chase it down? Can I figure it? Can I fix it? These are the questions that I care about now, almost to the exclusion of what's the first run experience like? I almost don't care about that at this point. Because I spend my time…six months and on that's where the hard work is. And so the first couple of months where you're figuring things out, that's not the hard work of this thing. And so, I'm very strongly focused on those later periods of time. But again, I'm open to the idea that maybe I am overcorrected there.

+ +

STEPH: I think it does highlight more of a shift in our career. We're still building, but we have experienced the maintenance side as well, and we felt that pain. And so that has led to perhaps overcorrecting, or maybe it's the correct amount of correction.

+ +

But I do like how you highlighted there is always a cost to each side and those are usually the questions that I'm asking myself when I'm thinking about the failure mode and how much I want to optimize for the failure mode is how much does it cost when this fails? Who's it going to impact? And how much does it cost for me to make this more observable or to address this failure state? And then I try to find the balance between those two. Because you're right, it's not free to address that failure state. And so I may not want to fully optimize to handle that if it's going to be a very small percentage of users that actually are impacted by this failure state, or it seems very rare this is going to happen. But then still finding ways to know that if it does fail, then I can say, "Okay, I'll come back, and now it's worth the investment to improve this."

+ +

CHRIS: When you said earlier that this is really hard work that we do, I don't know that I believed you. What you just described sounds super easy. You just handle all the stuff, and you dynamically optimize for the needs at the point in time. And that seems easy. [laughs]

+ +

STEPH: Super easy, yeah. [laughs] Way to bring it back. Well, speaking about observability and failure states, that does lead nicely into a bug that I was working on this past week where there was a particular page that was loading very slowly. And it was something that we'd heard from users that then they let us know that this page was either taking a very long time to load or, frankly, it was just crashing. And then they were never getting to that page. So I happened to be the one that then picked up that ticket. And I went to reproduce the issue, and sure enough, when I clicked on this particular link and then started counting, it took about 14 seconds for that page to load, which is a very long time. And then also sometimes it was just crashing.

+ +

So the first place that I went was to our error tracking. So I went to New Relic to then look to see okay; maybe there's a slow query. There's something here that's creating this performance issue, but I couldn't find anything. And New Relic does a great job of breaking down all the different response times so I can see how long Postgres is taking, Redis, and Ruby. All of those looked very normal. I couldn't find anything that seemed alarming that was indicating that the page was struggling to load even though I could reproduce the problem. Because I was clicking on it several times thinking, okay, well, if I just do this a couple of times, New Relic's going to notice, and then I'll get to see something, a little breadcrumb that's going to lead me in the right direction.

+ +

And while I was waiting for New Relic to surface something helpful to me, I mentioned to another developer the issue that I was triaging. And they said, "Yeah, that page has been getting progressively slower, and we don't know why." And I thought, ooh, okay, I'm intrigued even more now as this is something that has been escalating over time, and now we've hit this threshold that we're working on it.

+ +

And I discovered that in New Relic, I can look specifically at Postgres, Redis, Ruby, all those different response times. But there's a browser monitoring tool that I had not used before. And it showed a lot of helpful information around first paint, First Contentful Paint, window load, all of those areas. So I started diving in and found session tracing, and it was there that then I saw New Relic was telling me, "Hey, you have a page that's taking about 14 to 15 seconds to load." And I thought, okay, I feel validated now that at least New Relic is recognizing this issue. I have seen this issue, but I still didn't know why it's occurring.

+ +

So the next tool that I used that I don't know if I've used before or it's just been a very long time; it felt fresh in the moment, but it's the Chrome DevTools, the performance tool. And so you can open that up in your inspector, and then you can go to the page that you want to track the performance. And then you can essentially say, "Hey, go ahead and start profiling and reload this page." And it has so many stats when it finally does load. It has CPU flames charts, which essentially it visualizes a collection of all the stack traces. It has a film strip, so you can actually see the rendering progress of your website along different time points. So if you wanted to go back to a specific time, you can see what did the webpage look like at this point? And then if you go a little further, okay, how much was loaded at this point? So there's a lot of interesting and a little overwhelming information that's there.

+ +

But the thing that did catch my attention is there's a chart. I don't actually know what this chart is called. It's not a pie chart because there's no center to it. So it looks like a donut chart, and it's broken down. And it shows you the loading times, scripting, rendering, painting, all of those different values. And the rendering time was taking 35 seconds. And I was like, ooh, okay, that is meaningful right there. So then further investigation, now that I knew what I was looking for, I wasn't looking for something more on the back end. I was looking for something more on the front end. And I didn't think it was necessarily JavaScript because we also have JavaScript on this page. So at least this was helping me get a little bit closer before then I went into the codebase to start seeing what's happening.

+ +

So once I knew it was a rendering issue, I went to look specifically at that view, and we have a form on that page that was generating an empty HTML select option for every record that's in the system. So let's say that you're ordering from a restaurant. On this page, there was a form where it had a list of all the restaurants, and, in our particular case, we had about 17,000 restaurants. So there were 17,000 empty HTML selection options, which could have some significant impact on the DOM and page load time. And that was the piece that was really leading to the performance, is the fact that we were rendering that empty select option.

+ +

So from there, it was then just triaging okay; we don't really need to render all of these restaurants. There are ways we can scope this down. And that way, we're only showing a little bit at a time versus creating all of these empty options. I should clarify they're empty because part of this form is you select from the first dropdown, and then it populates the other one, and it gives you more information. But the way that this form was implemented, it was actually trying to show all of them at once. But it didn't actually have the data yet, but it was doing like a restaurant.all type of count. And so then that's how we were getting that many empty options.

+ +

So it was a very interesting journey. It was very helpful to learn that New Relic has this browser monitoring tool. And I really appreciated their performance tool. And circling back to Chrome, Safari may have something similar. But I found Chrome's performance tool very helpful because then it helped me realize that it was the rendering. And so then I could really focus on the markup and the view versus knowing it wasn't more in the database layer.

+ +

CHRIS: I really love the description, almost like a mystery novel of these bugs when we encounter them. Because if you just get to the end and you're like, oh, I was rendering a select, and it had all of this, that loses so much of this story because again, the coding is not the hard part of the work that we do; it's the figuring out what needs to be done. And in this case, that journey that you went on to find the bug. I really like the point where you said, "And someone mentioned this page has just been getting progressively slower over time." I was like, ooh, that's interesting. Now we got a clue. Now we've got a lead, and we'll chase it down, and then finding the browser tools and all of that.

+ +

And also, as an aside, browsers are just such an immensely impressive piece of technology, everything that they do. And then you add the DevTools on top of them and magical stuff going on there. But yeah, also probably don't render 17,000 empty selects. [laughs] That seems like it will get you in trouble pretty quickly. But also very easy to get to and especially if there is this incremental, slow creep over time where it's like, oh, that page seems like it's a little slower. It's a little slower still, and it just keeps creeping up over time. But yes, I appreciate you taking us on that journey with you.

+ +

STEPH: Yeah, it was a fun discovery. And it made me realize that while we have alerting set up for some of our other queries, we don't have anything set up for the browser time. So that would be a good optimization on our side is to start alerting us before a page gets to the point that it's taking that long to load to notify us sooner. So we don't have to wait for a user to reach out to us, but we can triage sooner.

+ +

CHRIS: I also do love the idea of extending the metrics that we hold ourselves accountable to all the way through to the user, and so the First Contentful Paint and all of that. The one that I really love recently that has captured an idea that I struggled to put words to is the Cumulative Layout Shift. Are you familiar with this piece?

+ +

STEPH: Uh-uh.

+ +

CHRIS: So there's like, how quickly does the page render? That's the thing that we want to know. But a lot of applications these days, particularly single-page apps, render pretty quickly, but they render what ends up being a skeleton or a shell of the page. And then behind the scenes, there are like ten different AJAX requests happening. And as the data comes in, suddenly, a part of the screen will render. And they'll render a list of items that they just got back from the back end, but they're still waiting for the information to populate the header. And so if you look at that page, it's constantly shifting as it's loading and just feels, I don't know, flimsy in my mind. But I didn't have a good word, or I didn't have a metric or a number to attach to that. And then I learned about Cumulative Layout Shift, and I was like, oh, that's the one. Now you've mapped the thing that I was feeling. And I like when that happens.

+ +

STEPH: Is that the difference between the first paint and First Contentful paint? Is that similar?

+ +

CHRIS: I think it's more than that because there are not just two discrete events in this. It can be multiple. And so it's like, how many different times did the thing that's rendered on the screen move around? And so if images are loading, but you didn't have a proper image height and width set, that's another way that this can happen. Then initially, the browser is not going to reserve any space for that because it's like, I don't know how big this is. And then, when the image shows up, it now knows the intrinsic height and width of the image. So suddenly, your page is going to jump from that. You can get ahead of that by putting the height and width on your image, and that's great to do. And frameworks like Next.js have done some really amazing work of making that a build time step as opposed to something you have to do manually.

+ +

But then also, more generally, how do we handle this? React is doing some interesting work with Suspense, where you can aggregate together multiple different loading states into one collective thing. It's almost like promise.all, but for your page. I haven't followed that too closely, but I know that that's framework-level work that's happening over there. GraphQL does a really great job of allowing you to group queries together. So there's a solution on that side. But broadly, if you just render some HTML on the server and you send it to the front end, then you don't have this problem because you just have one ball of HTML. The browser is pretty good at rendering that in one pass versus if you have single-page applications that are making a handful of AJAX requests that will resolve in their own timelines and eventually paint to the screen. You get this different shape. And then the worst case of it in my mind is you render half the page. And then suddenly, one of the requests realizes the JWT has expired, and suddenly, you get thrashed over to the login page. Please don't give me that experience, developers, please. Please do something else that isn't that. That makes me sad in my heart.

+ +

STEPH: Prioritize the failure state. That's what I'm hearing.

+ +

CHRIS: Callbacks.

+ +

STEPH: Well, on that wonderful circular reference, shall we wrap up?

+ +

CHRIS: Wait, I thought circular references were bad...Never mind. Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed, or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + This week Chris talks about Bifunctor optics and introduces an app he's been liking recently called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX.

+ +

Steph talks about her experience using New Relic Browser Stats to troubleshoot a slow page and burnout. Who's feeling it? (Raise your hand.) How do we identify it? What do we do about it?

+ + + +

Transcript:

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. And we're off the rails already, everybody. It's going to be a good one. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going?

+ +

STEPH: Hey, Chris, it's going really well. We talked recently that I have a new laptop. So I have been migrating the things that I'm accustomed to over to my new laptop, but I also love that clean, fresh start. So as part of that fresh start, I was like, what if I use Safari? What if I just switch? I'm a Chrome user, for the record. I'm pretty sure you know that, but just to share that. I was like, well, what if I just switched and I try out Safari for a while? So that was the thing.

+ +

CHRIS: So I heard the words try and the phrase that was the thing, but I'm going to probe a little deeper. How'd that go? Was it good, great, not so great?

+ +

STEPH: Honestly, it was fine. I did enjoy being in a new environment to see how Safari handles bookmarks and then also the inspector. So it was novel to be in a different browser where I really don't spend much time in a different browser other than when I need to test this specific UI bug or things like that.

+ +

But the reason that I ended up migrating back to Chrome was frankly for Chrome profiles because I really like that I can have this clear separation now between my work life and my personal life, and then it also keeps me signed in. So my personal email versus my thoughtbot one versus before the Chrome profiles, which I'm not sure how recent of an addition that is where Chrome introduced that feature. But before, I just always had to be signed into both, and it was just all together in one spot. But now I really like that I can separate. And it's more intentional where I'm like, oh, I'm going into work mode, so I just want that profile versus I do need to hop over to my personal side for a while. So that was the thing that brought me back.

+ +

CHRIS: Interesting. I don't take advantage of that at all. I know of the feature, but it's never really called to me. And if anything, I do the opposite. So specifically, this doesn't work in the browser, but on my phone, I use the iOS Gmail client, and I use the unified inbox. So I just have everything come together. And I subscribe to the idea of, I don't know, it's all work and stuff. And hopefully, people aren't sending me a lot on the weekends, and I will defer and snooze and all of that. But that holistic view pulls me in. And so it's interesting that you're just on the other side of that. It totally makes sense. I actually think I'm wrong here. I think I'm doing the wrong, bad thing. But it's interesting just the way we're on the two sides of that.

+ +

STEPH: I can see the merits for your approach where it all goes to one place. So you have one place to go and triage, and I think that makes total sense. I haven't triaged my personal life well enough that I want it to come into my work life. And that's the one that needs the more immediate response typically. So I want to prioritize all of my work emails and focus on that and then have my personal ones more like, okay, I've got some time, and I want to check on this. But I don't want to blend those together. Because frankly, I need to do some more triage on the personal side if I'm just going to bring it all into one space.

+ +

CHRIS: Interesting. Yeah, I would almost view it from the other point of view of I want to protect my personal space, and this is obviously not what I do based on what I just said but protect my personal time so that when it's evenings or weekends or whatever, that I'm not seeing work emails in there. I do my best to snooze them and get them out of the way. But if they are coming in, maybe there's something I need to respond to or, I don't know, maybe it's FOMO in a certain way, FOMO but professional FOMO. I don't really know. It's interesting that that's the feature that brought you back. But overall, how was your experience using Safari?

+ +

I have heard loosely that now most of the browsers are evergreen; even Edge has really caught up and is now implementing features in a similar way. And so Chrome, Firefox, and Edge are very similar. And my understanding is Safari is the one that actually lags behind or even holds back web standards and implementations and things like that. So, did you find any rough edges of that sort, or was it otherwise just fine, and it was mostly the profile stuff that made you switch?

+ +

STEPH: It was honestly just fine. I also may have not used it long enough to run into any of those rough edges. But overall, it was just fine. It worked. I just got to that point where I've run into this situation before where I'm signed into my personal email, and then I'm signed into my work email. And then I'm going to Google Hangouts, and Google Hangouts gets confused, and it's like, which person are you? And then I have that moment of where I have to sign out of one, or sometimes it just gets complicated. And what I found with profiles is that that's just never an issue. I don't have to worry about it anymore.

+ +

So yeah, overall, Safari was fine. I wouldn't mind going back to using it. I just really like the profile feature. This was one of those moments where it helped me notice how much I really liked that feature because I had just opted into it a while back. But this was that moment where I was like, oh yeah, I really miss that. So I'm going to go back to it.

+ +

CHRIS: The thing you said a minute ago about which person am I? [chuckles] There's a deep philosophical underpinning there, but I've definitely struggled with that and trying to trick the browser into it. So Trello is the one that I'm struggling with that right now. I am one human in the world, I assure you. But GitHub gets this; GitHub plays the game correctly where I'm one human, but I have multiple internet identities. I am the work person. I am the open-source person. And I'm able to route notifications and things to the different inboxes based on the organization that they're part of, et cetera. And I really liked that, that GitHub seems to understand that I am a human that is multifaceted, whereas Trello does not. And so I use Trello in a professional context a lot, but it's my personal...like, I would have to create a distinct account on Trello. And I'm like, Trello, that's not true; I'm still one person. Just understand this Trello organization is a separate facet of my existence. Got on my soapbox on that part.

+ +

The other thing I want to say is I do feel bad about the fact that I'm just on Chrome. Because increasingly, Chrome has got so much of the market share, and it's becoming the new deeply dominant thing. And so I want to be the agent of change or like, no, we should use different browsers, and we should support them and make sure that we're testing against them and all of that. And then I'm just on Chrome all the time, and I feel bad about it. But it's one of those like; I have so much muscle memory and built-up knowledge around how to use Chrome. And I've just used it for so long now that the switching cost would be pretty high, I assume. I actually haven't even really tried, but I feel bad about it. I'm now saying two things which are I feel bad about it, and I've never even really tried. So I don't feel great in this moment, but these are my truths.

+ +

STEPH: [laughs] Well, I can plus-one your truths. Those resonate with me. Well, there's always stuff that I am trying that's new all the time. So I feel like I need some constant in my life until I'm ready for other things to be the constant in my life. And then I can muck around with which browser I'm using and change other things. And you have to be in that moment. You have to be ready for it.

+ +

So going back to a thing that you said a minute ago about separating your work life and your personal life, I very much like that framing, and that's a nice segue, frankly. And it's something that I've been thinking about where you and I often start with technical topics. But I have a very people-centric topic that I'd love to chat with you about today, and it is emphasis on burnout. And who's feeling it? How do we identify it? What do we do about it?

+ +

And that's been very much on my mind because I have noticed a lot of people around me, including myself; I just feel like we are more inclined to experience burnout right now or are going through it actively. And it feels even more important to have those conversations with each other and with ourselves to talk about what does it look like when we're burned out? How do we recognize when we're there? Because often, when we are burned out, it's not something that happens gradually, or at least it's not something that we notice happening gradually. It's like, okay, I'm fine. And then suddenly, okay, I'm burned out. And I'm at a place where then I can't really focus. I feel overwhelmed. I'm drained.

+ +

For anyone that is less familiar with burnout, one, hooray, and then two, burnout is a state of emotional, physical, and mental exhaustion that can be caused by excessive and prolonged stress. So then that's what leads to us feeling very overwhelmed, emotionally drained, unable to meet constant demands, or those are the things that are causing our burnout.

+ +

So I have been doing what I typically do when I'm thinking about a particular topic, and then I'm looking to gather knowledge and information is I try to go pretty wide where I start looking for podcasts, books, just people that are having similar conversations and trying to synthesize a lot of the information that they're sharing. And I have found some really good stuff. The question is now, what does one do once one has that content, and then how do you bring it back and help apply that content to yourself and then people that are around you? So I have some thoughts there, but before I go further, I'm curious, what's your experience with burnout?

+ +

CHRIS: I think for me, I've been somewhat lucky in that I don't think I've ever really got into an acute period of burnout, but I've definitely had periods where I just felt weighed down. And there are ebbs and flows of life, and of work, all of those things. There is something that I've been thinking about recently, which is the inherent nature of the work that we do where consistently we're working on something where we don't quite know how to do it, and we're struggling, and we're struggling. And finally, we figure out how to do the thing, how to trick the computer into doing what we want. And then the minute we do that, in trying to encode, ideally, we're automating that away. And we take that solved problem, and we just ship it off. And then, we pick up the next unsolved problem from the list. This isn't entirely true, but it feels like sometimes unspecificity in sort of I'm just working on things that are underdefined, underspecified, and I'm trying to solve little puzzles constantly. And, I don't know, I was feeling that recently of the nature of the work was burning me out.

+ +

And I think earlier on in my career; I definitely experienced this in a certain way. And then, in the middle of my career, there was this perfect inflection point of my skills and the level of tasks that I was going for. But then, the further I got into my career, the more I tend to take the weird underspecified stuff and anything that's relatively clear I'm giving to other folks on the team. I'm like, "Oh, here's this well-defined piece of work here. Can you go implement this admin page?" Whereas I am doing the investigate integrating with third-party platform XYZ that uses a SOAP API that isn't documented. I'm like, okay, cool. Let me roll up my sleeves and figure out what that means. And I noticed in my work that that was starting to weigh on me, and I was able to shake that off and shift around some of the tasks that I was doing.

+ +

But that was a particular form where the work itself was weighing on me. And I took a step back, and I was like, why do we do the things that we do as developers? Because there's something just fundamental like, you have to enjoy that nature of challenge and constantly escalating challenge to a certain degree, I think, to really like this work, but it can be a lot sometimes. So I feel like maybe that's a slight digression from the topic, but it was a thing that I was feeling in this space. And that's a little bit of my story.

+ +

STEPH: Well, the beautiful thing about that is it highlights everybody experiences burnout differently. So that could really be how someone is experiencing burnout where they're taking on all these very complicated, different tasks, and they're feeling just worn down by that and that they're not able to meet demand. And they get to that point where maybe they lose their interest in tech and coding because they have pressed too hard in one direction. And so then they need to take a step back.

+ +

As for me, I've been thinking back over the last couple of months because there was once or twice where you and I had, I think a conversation here on The Bike Shed where I shared that things were okay, but I didn't feel like my normal self. I was losing some of my interest and energy for technology and coding. And I'm very fortunate; I love what I do. So the fact that I wasn't feeling that interest was a really big sign to me that something's different; something feels off. And it does vary depending on the client that I'm working with. And I think feeling that burnout then was a mix of some of those client pressures that I was feeling and that I was working perhaps too many hours as I was very interested in that client's success.

+ +

And then the other stuff was more personal because we only have, to borrow from the spoon theory, we only have so many spoons to give. And so if you have a lot going on in your personal life as well, that's going to detract from the energy that you also have to give to work. Are you familiar with the spoon theory?

+ +

CHRIS: I am not.

+ +

STEPH: I recently heard about it, and I can't stop using it now because I really like it. But it essentially...and there's a really great article that we can link to so others can read about it because I'm not going to remember exactly who came up with this theory. But the idea is that each spoon represents a unit of energy. And let's say if you start each day with only ten units of energy and you use spoons to represent that, as someone needs energy from you, maybe it's work, maybe it's a personal commitment, maybe you're dealing with a chronic illness, then you are giving a spoon away to each of those. So at some point, you're going to run out of spoons. And you want to also be mindful of who you're giving these spoons to because you are giving that energy away.

+ +

CHRIS: I definitely liked the idea of we start each day with a certain amount of energy, and different things can pull from that pool and whatnot. I'm intrigued by spoons as the unit. It just feels like a weird...I got this little bag of spoons that I walk around with, [chuckles], and I give them out throughout the day. I guess it could be anything in there, you know, objects. But, I don't know, spoons are interesting to me.

+ +

STEPH: I think it's because this person who came up with the idea was literally having a conversation with their friend in a cafe. And so that was just something that was in front of them. And they're like, oh, I can use spoons to represent. Well, we'll have to double-check the article to make sure, but I think that's why spoons became the representation.

+ +

So circling back to once you're in burnout, what do you do with it? And that is one of my questions right now. And that's what I'm trying to synthesize a lot of information around. Because once you're in that state, I don't know of a lot of great ways to help other than take time off because, at that point, you're in a crisis state. And you need to step away, and you need to find out how you can recover from having entered this state of crisis. So that feels really important to identify ways that once someone is in that state, that then we can help them. And that feels good. We can advise someone to take PTO. I still don't feel great about it in terms that then, as a manager myself, I don't really know of other helpful ways to then help someone through that period.

+ +

So then I really started thinking about the fact that once someone is in that burnout stage, frankly, it's too late. We have let someone get to that point that now they are in that crisis instead of addressing it early on. So that is the other thing that's on my mind is one, how do we help people that are already in that crisis state? But then two, how do we start identifying that someone is starting to go in that direction? And then how do we help them tell us? How do we then triage those situations? How do we prevent them from getting to that burnout state? And that's where I've also found some really good content.

+ +

And specifically, there is a podcast that I've started listening to called The Burnout Show. They essentially share their experience with burnout, and what they did about it, how they recovered from it, and then how they continue to fight it because a lot of people then still go back to the workforce. So then, once you do find a way to recover, then how do you go back to work? And there have been some really great episodes. And I'll be sure to include a link for it in the show notes.

+ +

There's one particular episode with Grant Gurewitz, who is a guest on the show. And he speaks specifically to the strategy of Three Good Pockets. And this speaks to the idea that there are many things that we can't control in our day. It could be work, family, other commitments, but we can strive for Three Good Pockets of time where we focus on something that's just for us. This is time that's reserved for you and any activity that you find restorative or joyful. And each pocket can vary in size. So perhaps that first pocket is spent just reading a few pages from a book that you're enjoying, and then the next pocket of time is spent outside or calling a friend.

+ +

And Grant also has a great suggestion around if you're worried that you'll get sidetracked and not actually step away, which I felt called out for that one because that one's definitely me. I will have good intentions, but then I won't actually take the break that I set for myself. So Grant recommends creating a list of restorative activities so that way when it is time for that break when your calendar is reminding you, then you have a list of these activities to choose from. So it makes it easier to say, okay, then I can do this for a couple of minutes, and I can truly step away from work and step away from my screen.

+ +

But especially now, when so many of us when we're sharing our workspace with our restorative space, for everybody who is still working from home or working remotely, then creating those daily breaks are incredibly important to our wellbeing. And so, it has me thinking about what restorative activities can I add to my day? How can I encourage other people to add more restorative activities to their day? So I really appreciated that advice.

+ +

And I have noticed that the idea of burnout, but not so much burnout specifically, I've been thinking of it as recovery and balance is a theme for me. And it is something that I am purposely choosing as a theme right now where I want to research and understand more of how we handle these situations and continue to make progress not just for myself but also for my team.

+ +

CHRIS: I think finding that right cadence and structure and way to reinvest in yourself and ideally gain more spoons if that is at all possible or at least defend the spoons that you have, those all feel very meaningful.

+ +

I do have a question. I'm interested in your thoughts on this. I feel like we hear about burnout a lot in our industry. I get the sense maybe that it is a more common thing. Like, I hear so many developers talking about how their dream is just to give up tech and go get a cabin and just farm in the woods or something like that. And I wonder, is it a more pervasive thing in our industry? So that's one question.

+ +

Another is just an observation that we actually do work in a wonderfully...it's an amazing industry where being a developer, there are so many jobs out there. And I don't want to discredit anyone's efforts if they're earlier on and struggling with that. But broadly speaking, it is a developer's market trying to go out there and get jobs and extremely well-compensated, as a general rule. But does that come with this inherent burnout? And if so, which I'm not sure is true, I wonder if maybe we're just more vocal and maybe we actually share more in public. We have more blogs and podcasts and things like that. And that's just a common thing for developers, and so we hear the stories more often, whereas maybe in other industries, it is actually very common, but people are suffering in silence.

+ +

But also I do wonder, our industry is still so young. The work that we're doing is changing constantly, and that churn and that working in the unknown maybe there is an inherent nature. So that's a bunch of pontifications off the top of my head. And I have no idea what the answer to any of them is. But I am intrigued because it does feel like the shape of burnout as a concept in the developer world is perhaps a little overrepresented, or maybe it shows up more than I would expect. And, I don't know, is the work that hard? I don't know. But then I hear these stories constantly, and I definitely have felt it myself, so maybe.

+ +

STEPH: Yeah, maybe. Yes, I do think the work is that hard for the record. It's challenging work. I enjoy it, but it is challenging work between figuring out the tech but then also everything else that comes with that.

+ +

I don't have anything to back this up, but I suspect that a lot of other industries are also experiencing burnout. And I just happen to be more aware of it right now because I'm hearing it more from my friends and the people that I work with. And I suspect that's more directly related to we all just went through 2020, and probably a number of us were trying to forge ahead and get through that time. And so there may be a lot of us that are just now dealing with those consequences of where we just pushed ourselves through a very hard time. And now a lot of that is manifesting and surfacing around really identifying the damage that we may have done to ourselves by just prioritizing work and trying to put our head down and get the work done even though there was so much happening around us.

+ +

And I suspect that may be a contributing factor is that now people are really starting to recognize, like, oh, I feel this way. And maybe there's time for me to address it. Or frankly, it may not even be that there's time, but your body is just like, okay, I'm done. I made it through the past year or however many months, and I'm going to start shutting down on you. I've given you all the warning signs, but now we're here. We're at a breaking point. So I don't know about the other industries, but I do know the reason that it's more on my mind is because I'm just hearing it more from people, and they're just expressing it. And so, it has become more of a focal point for me, and I've experienced it myself more recently.

+ +

I'm sure I experienced this back early on in my career, but I took a strategy of well, I'm just a junior, and I just have to get through this. And I have to build experience. For the record, that is not a healthy mentality. I'm just being honest about where I was in my life. And so, I didn't really stop to think about it, but perhaps it is becoming more normalized where people are having more open, honest discussions about where they're at. And if other industries aren't talking about this, I would love for them to.

+ +

So to round that out a bit, this is something that is just very interesting to me. It's very top of mind. So I suspect I will be sharing a lot more content in future episodes that are just around this. How do we recover? And then how do we balance? How do we work hard without burning out?

+ +

CHRIS: Work hard, play hard; those are the two placards that you have. Well, I look forward to continued conversations on all of those topics because they are sort of that's the story that underpins all of the work that we do. So I'm very interested to chat more about that.

+ +

STEPH: Thanks. So what's going on in your world? How's your week been?

+ +

CHRIS: Oh, my week has been fine. My topics are going to be way more mundane and tech-focused. But let's see, a couple of things, so one is that Stack Overflow has their I think it's Annual Developer Survey. And this year, the results came out, and there was an interesting standout, which was that Svelte was the most beloved framework, which was very exciting to see. Granted, you always have to take these sorts of stats with a grain of salt.

+ +

But Svelte was 71% loved and 23% dreaded, which they give it as a ratio of how many people really love this thing versus how many people really hate this thing. And so Svelte, 23% of people who have used it are like, I hate that, but 71% loved, so that's a 48% net approval rating. Versus React which was 69% loved, 31% hated or dreaded as the word would be, so that's a 38% net approval. And then Vue, interestingly, was 64% loved, 36% dreaded for a 28% net approval rating. So, yeah, Svelte was decidedly winning in that.

+ +

But again, the big grain of salt there is looking at the usage stats. React has 40% usage. So of all the respondents, 40% of the people responding to the survey were like, yeah, I've done React professionally, which is a wildly high number for a JavaScript framework. Vue was at 19%, so roughly half of React's usage, which I'm actually impressed that Vue is that high. And Svelte came in at 3%, so it's definitely still in the early adopter strong fan phase. So it makes sense that they would have this outsized high rating. I'm actually surprised that Vue wasn't higher than React, given that. Because I feel like more people are cajoled into React versus Vue can be more of a choice. And I would have expected this to shape out a little bit differently, but yeah, that's the story.

+ +

STEPH: That's really cool. I liked how you described that as in the very early adopters’ strong fan base stage.

+ +

CHRIS: But nonetheless, the people that are using Svelte do seem to really like it; that’s coming through in these numbers. And that definitely is my experience. I love Svelte and would love to continue using it for as long as possible. But really, I want a lot of other people to start using it. I want to really grow the usage base so that there are more libraries, and frameworks, and blog posts, and just mindshare in that space because I really do believe there are some wonderful ideas in Svelte. And it's just so straightforward to implement things that I just want more people hanging out. So that's one quick thing.

+ +

Another quick thing is, I've been using a utility lately or a program called CleanShot X, which is a replacement for the built-in screenshot utilities on OSX, and it is just fantastic. So I can capture a screenshot. I can capture a window. You can capture a GIF or a video. And then you can do little trims and annotations. And then it has this really nice feature where after you take a screenshot, it just hovers in the bottom corner of your screen and is easily accessible. So if you take a video, and then you want to upload it to a Trello card, it's just floating there waiting for you. You can actually dismiss it and push it down, but it's still peeking up from the bottom of your screen, and you can pull it back up, and you can have a couple of them. But it just really makes the whole workflow of grabbing screenshots or videos so easy.

+ +

And I cared deeply about that because now that I have this tool, I'm all the more inclined to grab a screenshot or a video with just about every piece of work that I do. So it's going into pull requests; it's going into Trello cards. And it's so nice to have a utility that just really makes that as easy as possible.

+ +

STEPH: I really liked how you mentioned that you can annotate because I often...I'm laughing as I'm thinking about this. When I am taking a video of something that I'm going to share with someone, I will use my mouse to indicate, oh, this is important. And so I circle around it and do silly things with my mouse to try to indicate but being able to annotate would be so much nicer.

+ +

I know there is another tool that you're really excited about that I can't remember off the top of my head right now. Do you know the name of the tool I'm thinking of?

+ +

CHRIS: Was it Loom?

+ +

STEPH: Yes, Loom, because I also used that for a little while, and I've really enjoyed it. So I'm curious, how does Loom and CleanShot X stack up? Is one replacing the other, or are they complementary tools?

+ +

CHRIS: Mostly complimentary. Loom is great because it hosts the videos, and you can also do audio capture, although I wonder if CleanShot has that as well. CleanShot also, I think, has a hosting thing. So I think there's a strong overlap in their functionality, but right now, I'm using both. And definitely for screenshots and things, CleanShot owns that end of it. And I think it's more likely that I could have CleanShot as the entire tool that I'm using. But I'm still using Loom for this is a walkthrough where I'm going to talk to you about a thing. I want to make it available at a URL that everyone can see rather than actually getting a GIF or MOV artifact file on my computer. So ever so slightly different, but I think of them, CleanShot X is probably the ideal one. But yeah, I'm still reaching for both.

+ +

So the one other thing I did want to talk about is I have been expanding our use of the dry-monads within the project that I'm working on. And I've done some things. I did some stuff, Steph, and I think it's good.

+ +

STEPH: Shtuff with Shteph. [chuckles]

+ +

CHRIS: Shtuff with Shteph, yeah. I'm definitely pushing the envelope of how much we're leaning on these concepts within the app, and I continue to question it. I'm really intrigued to see what happens when other folks come into the project, and they're like, "Why can't I just get the value? It should be a string. Why isn't it a string? Why is it a string that I have to do a ceremony and a dance to get at?" And I'm like, "Well, because everything can fail, you know, like life."

+ +

But what I have done here so dry-monads is the project that we're using, particularly their result type. So the result represents something that can either succeed or fail. And so we either have a success, which is this wrapper around the value that's successfully executed. So say we make an API call, we get back a response. If we get a 200 or maybe even a 300, then we get the data, and that's a success, or we get a failure and the error message. But fundamentally, we're modeling that in our system in a way that downstream from that, we have to basically determine if it was success or failure. So we're really encoding into the system; listen, pretty much everything can fail, so let's be careful with that. Let's be intentional and purposeful with it.

+ +

But there is an interesting thing where these objects have fmap as a method on them. So fmap is a way to transform that wrapped value, but fmap works specifically on the success case. So if you make an API request, you get back the data. Everything's great. You can call fmap, and it will yield into a block that data. You can transform that data in some way, and then it will rewrap it up as a success object. So you can operate on this thing as if it has been successful. But in the case that it's a failure, it will just ignore that transformation because you don't want to transform the failure. It's going to be a totally different shape of data. So you want to separate those. We're getting into functors and monads here. So I'm going to handwave a bunch. But fundamentally, that's the thing that we're going for here.

+ +

But we found ourselves really wanting to work with both sides. So we make this API request, and in the case that it succeeds, we actually want to transform and actually slice out a piece of data from the nested object that we get back. So that's one transformation that we want to apply on the success portion of the aisle. But then, we also want to transform the failure message. It turns out this backend is giving us very unfriendly error messages. So we want to take those and transform them into friendlier user-facing error messages.

+ +

So it turns out we want to map both sides. And so I went to dry-monads, and I was like, what do you got? I want to know about this in the world. And it turns out they did not have anything. So I started looking into it, and it turns out this is a concept in the world of functors, specifically. Or, more specifically, I reached out to a former colleague, Sid Raval, a former thoughtboter as well. And he likes the functional programming stuff, so I knew he was the right person to ask about this. And he pointed me at bifunctors. So I found myself in a new space and category theory which I never thought I would explore a category theory in this way, but here we were.

+ +

So a bifunctor basically is exactly what I was talking about where there are these two branches. In our case, it's either success or failure, but it allows you to operate on both sides, both branches. So the method or the function that gets applied there is bimap. So it's fmap which I don't know why it's f why that's typically what it's called. Success map would be a really great word in this context in my mind. So success map only deals with the success side, but bimap takes two different transformations, one for the successful outcome and one for the failure outcome. And it allows you to very directly talk about what you want to do with that.

+ +

To be clear, dry-monads has a function called Either or Either, depending on how you want to pronounce it. And that takes two Lambda proc-type things because it's Ruby, and functions are kind of weird in Ruby. But it yields you either the successful value or the failure value, but then it doesn't rewrap them. So it's meant to be the terminal. You use that in a controller when you're either redirect or render or whatever it is you want to do. What I wanted was something for mapping, so staying in the success object or the failure object but yeah, bimaps. So I introduced my own extra wrapping layer. This is where things go off the rails, I think. We now have our own internal result objects.

+ +

I thought about monkey patching for a while. I convinced myself monkey patching was a bad idea. Now that I've implemented as an extra layer of wrapping and I got the wrapping wrong like four times, or I kept recursively wrapping and re-wrapping, and there's a reason people aren't supposed to write these things themselves. But I think monkey patching may have been a better idea here, or maybe I should have never done any of this. We ended up with a stable working implementation and a nice test suite that covers it. But I introduced bimap and failmap as two different methods on our success object. And I did it by doubly wrapping the result objects. So we have our internal result, which wraps the dry-monad result. And I'm worried about that future situation where a junior developer comes on the team and is like, "I don't know what any of this is."

+ +

STEPH: I love the weekly progression of I've done some things, and let's talk about it. And then seeing this glimpse into your argument with yourself as to yes, but we need it, and we want it, and it's not something that's defined. So let's go ahead and implement it. You ended on a high there where you talked about the fact that it is nice to work with. It does the thing that you'd like it to do, and it's well tested; I love that part.

+ +

I'm deciding which thread to go with because there were a lot of interesting bits in everything that you shared. And I'm intrigued about the monkey patching as to why you think that could have been a better approach. Could you talk more about that one?

+ +

CHRIS: Sure. So I ended up having to introduce the secondary object that then wraps the result. And so if you poke at that even a tiny bit, you start to see this like Russian doll nesting of it's our result wrapping a result, wrapping a value. And it's a burrito with three different tortillas wrapped around it. And if you want to add guacamole, you got to unwrap all three burritos. I'm sorry, this is a terrible monad joke here. [laughs]

+ +

STEPH: For the record, if Taco Bell is not offering that, they should now, now that you've created that. [laughter]

+ +

CHRIS: There is one, but there's usually cheese in between the layers. They're not just extra layers of tortillas, so that's what I've got here. It's way too much tortilla, and that's sad. You don't want that. And it's confusing. You're like, wait, does this one have two or three layers of tortilla? So when I was working on it and when I was implementing our additional wrapping layer, I tricked myself multiple times. And my test suite was telling me that things were working, but I was testing incorrectly. And I was like, oh man; this is very subtle. And even though I'm deeply immersed in the context here, I'm still struggling with this.

+ +

So the question is, did I successfully encapsulate all of this? And now anyone downstream just gets to use it,, and everything will be fine. Am I the heroic programmer that made the perfect abstraction that no one's ever going to struggle against, or was that pain that I was feeling representative of the complexity of what I'm trying to do here, and maybe I got it wrong?

+ +

And so then the monkey patching side is we've got this one layer of wrapping. What if we just monkey patch the result such that it's got these new methods? I'm not adding an additional layer. I don't need to deal with double mapping through multiple layers, and I just get to deal with the context that I have. So I did an initial spike of an implementation that way, but I talked myself out of it because #monkeypatchingisbad, but I don't know. I don't know where I'm ending here. I am happy with where we're at, but I am aware that I may be sad down the road.

+ +

STEPH: I'm just dying over here [laughs] from everything you're saying. I have this image of you staring out the window thinking, am I the hero, or am I the villain? And figuring out who you are in this scenario with this abstraction that you've created.

+ +

CHRIS: To be clear, it's raining, and I have a nice rocks glass of scotch in my hand. And I'm just wistfully looking out the window trying to determine what's true. That's pretty accurate, actually. That's pretty much what's going on here.

+ +

STEPH: I think we're just going to need updates as it progresses along.

+ +

CHRIS: I will say overall this paradigm...so failures can happen at all levels. These command objects, which are the core of where this is coming in in the application, really represent the workflows of the app in a wonderful, testable, straightforward way. So I love that part. And if I have that, it implies that I have to have this other stuff. I don't think I can get away from that.

+ +

The other thing is I've always loved Gary Bernhardt's Functional Core, Imperative Shell, which is a conference talk that he gave a while back. I talked to Gary about it actually when he was on the show, and we can link to both that and the conference talk because they are fantastic. And I just love the way he thinks about software. But that was always a little bit abstract for me. Like, what does that actually look like, though, in say, a Rails architecture? And I didn't have a great answer.

+ +

And now this thing that I'm doing is the closest I think to that where the innards of the system are almost functional even though it's Ruby. We're leaning into that. And so we have these command objects that take in some data, and then they operate on it, and they yield out these results. Did it go well, or did it not? We've got the railway-oriented stuff, which again I'll link to. I link to now every third episode, apparently, but here we are. And that just models the reality of these programs in a really great way.

+ +

And then we've been trying to introduce some, not rules per se, but guidelines as to how we interact with these things. So inside of the core of the application, we're trying to be as functional as possible. We do transformations on these result objects, but that's it. And then it's only really in the controllers or the mailers that we are doing unwrap or deal with the actual nested value, but everything else is working on conceptual values or whatever it is…these result objects. And that's actually been really nice, and it's allowed us to have really nice error handling within the app. The logging is very straightforward. A lot of apps that I've worked on in the past, I've just silently thrown away many error cases or edge cases. And this is a really great way to sequence the work that needs to be done but never throw away data that you would want. And so far, I'm finding it to be really great. And I'm seeing very obvious ways to hook into it like, oh, this is where we need to find the user-facing error message versus this is where we figure out what we want to log. And so, in some ways, it's great, but I am still open to the idea that this was a terrible idea. I always remain open to that idea to be clear. [chuckles]

+ +

STEPH: I love how that's the feedback that you're always open to it. You're always trying something new, and then you're constantly going back to revisit; was this a good idea or a bad idea?

+ +

To go back just a little bit, I do absolutely love the priority and focus that you're giving to the failure state because I feel like that is an area that we, as developers we're very skittish of that failure state. And I realize I'm projecting here. So if you're listening, feel free to take that however you like; maybe it doesn't apply to you, maybe it does. But the failure state is like you said, it's life, it's important, and it's something that is going to happen. And it is something that we should make accommodations for.

+ +

And I find that we're often very hand-wavy with a failure state. So I love, love how much you always prioritize the failure state and make that something that people can work with and understand. Versus then when something goes wrong, then that's when we have to start to understand the failure state. I recognize there's a balance there because you're not going to know the failure state until you encounter it, but there are ways that we can still optimize to have observability into that failure state for when we do encounter that failure.

+ +

CHRIS: I've definitely seen that as an evolution in my own thinking, how much am I focused on how easily can I do the core thing, the happy path versus how robustly can I do all of the variations of what this app needs to do? What if the network's down? What do we do there? I do occasionally worry that I've overcorrected on that. And it's like, you know what? This thing that I'm worried about that I'm protecting against in the application is a 0.01% edge case. It's going to affect almost no users, and we're both putting time into trying to avoid it. But also, there's code complexity that comes from trying to handle all the different variants. And so there's definitely an optimization, and I feel like, at different points in my life, I've been undercorrected or overcorrected on that.

+ +

But I think if I were to describe the arc of my career, it is desperately searching for that optimal path and trying to find exactly the right amount of error handling to apply, and then yeah, then I'll be happy, then it'll be great. But it is like when I look at DHH's classic 15-minute I'm making a blog, look how much I'm not doing, I'm like, sure, sure, sure. Show me that in three years, though. What does the blog look like? How easily can I add a new feature? What happens when there's a bug in production, and a user reports it? Can I chase it down? Can I figure it? Can I fix it? These are the questions that I care about now, almost to the exclusion of what's the first run experience like? I almost don't care about that at this point. Because I spend my time…six months and on that's where the hard work is. And so the first couple of months where you're figuring things out, that's not the hard work of this thing. And so, I'm very strongly focused on those later periods of time. But again, I'm open to the idea that maybe I am overcorrected there.

+ +

STEPH: I think it does highlight more of a shift in our career. We're still building, but we have experienced the maintenance side as well, and we felt that pain. And so that has led to perhaps overcorrecting, or maybe it's the correct amount of correction.

+ +

But I do like how you highlighted there is always a cost to each side and those are usually the questions that I'm asking myself when I'm thinking about the failure mode and how much I want to optimize for the failure mode is how much does it cost when this fails? Who's it going to impact? And how much does it cost for me to make this more observable or to address this failure state? And then I try to find the balance between those two. Because you're right, it's not free to address that failure state. And so I may not want to fully optimize to handle that if it's going to be a very small percentage of users that actually are impacted by this failure state, or it seems very rare this is going to happen. But then still finding ways to know that if it does fail, then I can say, "Okay, I'll come back, and now it's worth the investment to improve this."

+ +

CHRIS: When you said earlier that this is really hard work that we do, I don't know that I believed you. What you just described sounds super easy. You just handle all the stuff, and you dynamically optimize for the needs at the point in time. And that seems easy. [laughs]

+ +

STEPH: Super easy, yeah. [laughs] Way to bring it back. Well, speaking about observability and failure states, that does lead nicely into a bug that I was working on this past week where there was a particular page that was loading very slowly. And it was something that we'd heard from users that then they let us know that this page was either taking a very long time to load or, frankly, it was just crashing. And then they were never getting to that page. So I happened to be the one that then picked up that ticket. And I went to reproduce the issue, and sure enough, when I clicked on this particular link and then started counting, it took about 14 seconds for that page to load, which is a very long time. And then also sometimes it was just crashing.

+ +

So the first place that I went was to our error tracking. So I went to New Relic to then look to see okay; maybe there's a slow query. There's something here that's creating this performance issue, but I couldn't find anything. And New Relic does a great job of breaking down all the different response times so I can see how long Postgres is taking, Redis, and Ruby. All of those looked very normal. I couldn't find anything that seemed alarming that was indicating that the page was struggling to load even though I could reproduce the problem. Because I was clicking on it several times thinking, okay, well, if I just do this a couple of times, New Relic's going to notice, and then I'll get to see something, a little breadcrumb that's going to lead me in the right direction.

+ +

And while I was waiting for New Relic to surface something helpful to me, I mentioned to another developer the issue that I was triaging. And they said, "Yeah, that page has been getting progressively slower, and we don't know why." And I thought, ooh, okay, I'm intrigued even more now as this is something that has been escalating over time, and now we've hit this threshold that we're working on it.

+ +

And I discovered that in New Relic, I can look specifically at Postgres, Redis, Ruby, all those different response times. But there's a browser monitoring tool that I had not used before. And it showed a lot of helpful information around first paint, First Contentful Paint, window load, all of those areas. So I started diving in and found session tracing, and it was there that then I saw New Relic was telling me, "Hey, you have a page that's taking about 14 to 15 seconds to load." And I thought, okay, I feel validated now that at least New Relic is recognizing this issue. I have seen this issue, but I still didn't know why it's occurring.

+ +

So the next tool that I used that I don't know if I've used before or it's just been a very long time; it felt fresh in the moment, but it's the Chrome DevTools, the performance tool. And so you can open that up in your inspector, and then you can go to the page that you want to track the performance. And then you can essentially say, "Hey, go ahead and start profiling and reload this page." And it has so many stats when it finally does load. It has CPU flames charts, which essentially it visualizes a collection of all the stack traces. It has a film strip, so you can actually see the rendering progress of your website along different time points. So if you wanted to go back to a specific time, you can see what did the webpage look like at this point? And then if you go a little further, okay, how much was loaded at this point? So there's a lot of interesting and a little overwhelming information that's there.

+ +

But the thing that did catch my attention is there's a chart. I don't actually know what this chart is called. It's not a pie chart because there's no center to it. So it looks like a donut chart, and it's broken down. And it shows you the loading times, scripting, rendering, painting, all of those different values. And the rendering time was taking 35 seconds. And I was like, ooh, okay, that is meaningful right there. So then further investigation, now that I knew what I was looking for, I wasn't looking for something more on the back end. I was looking for something more on the front end. And I didn't think it was necessarily JavaScript because we also have JavaScript on this page. So at least this was helping me get a little bit closer before then I went into the codebase to start seeing what's happening.

+ +

So once I knew it was a rendering issue, I went to look specifically at that view, and we have a form on that page that was generating an empty HTML select option for every record that's in the system. So let's say that you're ordering from a restaurant. On this page, there was a form where it had a list of all the restaurants, and, in our particular case, we had about 17,000 restaurants. So there were 17,000 empty HTML selection options, which could have some significant impact on the DOM and page load time. And that was the piece that was really leading to the performance, is the fact that we were rendering that empty select option.

+ +

So from there, it was then just triaging okay; we don't really need to render all of these restaurants. There are ways we can scope this down. And that way, we're only showing a little bit at a time versus creating all of these empty options. I should clarify they're empty because part of this form is you select from the first dropdown, and then it populates the other one, and it gives you more information. But the way that this form was implemented, it was actually trying to show all of them at once. But it didn't actually have the data yet, but it was doing like a restaurant.all type of count. And so then that's how we were getting that many empty options.

+ +

So it was a very interesting journey. It was very helpful to learn that New Relic has this browser monitoring tool. And I really appreciated their performance tool. And circling back to Chrome, Safari may have something similar. But I found Chrome's performance tool very helpful because then it helped me realize that it was the rendering. And so then I could really focus on the markup and the view versus knowing it wasn't more in the database layer.

+ +

CHRIS: I really love the description, almost like a mystery novel of these bugs when we encounter them. Because if you just get to the end and you're like, oh, I was rendering a select, and it had all of this, that loses so much of this story because again, the coding is not the hard part of the work that we do; it's the figuring out what needs to be done. And in this case, that journey that you went on to find the bug. I really like the point where you said, "And someone mentioned this page has just been getting progressively slower over time." I was like, ooh, that's interesting. Now we got a clue. Now we've got a lead, and we'll chase it down, and then finding the browser tools and all of that.

+ +

And also, as an aside, browsers are just such an immensely impressive piece of technology, everything that they do. And then you add the DevTools on top of them and magical stuff going on there. But yeah, also probably don't render 17,000 empty selects. [laughs] That seems like it will get you in trouble pretty quickly. But also very easy to get to and especially if there is this incremental, slow creep over time where it's like, oh, that page seems like it's a little slower. It's a little slower still, and it just keeps creeping up over time. But yes, I appreciate you taking us on that journey with you.

+ +

STEPH: Yeah, it was a fun discovery. And it made me realize that while we have alerting set up for some of our other queries, we don't have anything set up for the browser time. So that would be a good optimization on our side is to start alerting us before a page gets to the point that it's taking that long to load to notify us sooner. So we don't have to wait for a user to reach out to us, but we can triage sooner.

+ +

CHRIS: I also do love the idea of extending the metrics that we hold ourselves accountable to all the way through to the user, and so the First Contentful Paint and all of that. The one that I really love recently that has captured an idea that I struggled to put words to is the Cumulative Layout Shift. Are you familiar with this piece?

+ +

STEPH: Uh-uh.

+ +

CHRIS: So there's like, how quickly does the page render? That's the thing that we want to know. But a lot of applications these days, particularly single-page apps, render pretty quickly, but they render what ends up being a skeleton or a shell of the page. And then behind the scenes, there are like ten different AJAX requests happening. And as the data comes in, suddenly, a part of the screen will render. And they'll render a list of items that they just got back from the back end, but they're still waiting for the information to populate the header. And so if you look at that page, it's constantly shifting as it's loading and just feels, I don't know, flimsy in my mind. But I didn't have a good word, or I didn't have a metric or a number to attach to that. And then I learned about Cumulative Layout Shift, and I was like, oh, that's the one. Now you've mapped the thing that I was feeling. And I like when that happens.

+ +

STEPH: Is that the difference between the first paint and First Contentful paint? Is that similar?

+ +

CHRIS: I think it's more than that because there are not just two discrete events in this. It can be multiple. And so it's like, how many different times did the thing that's rendered on the screen move around? And so if images are loading, but you didn't have a proper image height and width set, that's another way that this can happen. Then initially, the browser is not going to reserve any space for that because it's like, I don't know how big this is. And then, when the image shows up, it now knows the intrinsic height and width of the image. So suddenly, your page is going to jump from that. You can get ahead of that by putting the height and width on your image, and that's great to do. And frameworks like Next.js have done some really amazing work of making that a build time step as opposed to something you have to do manually.

+ +

But then also, more generally, how do we handle this? React is doing some interesting work with Suspense, where you can aggregate together multiple different loading states into one collective thing. It's almost like promise.all, but for your page. I haven't followed that too closely, but I know that that's framework-level work that's happening over there. GraphQL does a really great job of allowing you to group queries together. So there's a solution on that side. But broadly, if you just render some HTML on the server and you send it to the front end, then you don't have this problem because you just have one ball of HTML. The browser is pretty good at rendering that in one pass versus if you have single-page applications that are making a handful of AJAX requests that will resolve in their own timelines and eventually paint to the screen. You get this different shape. And then the worst case of it in my mind is you render half the page. And then suddenly, one of the requests realizes the JWT has expired, and suddenly, you get thrashed over to the login page. Please don't give me that experience, developers, please. Please do something else that isn't that. That makes me sad in my heart.

+ +

STEPH: Prioritize the failure state. That's what I'm hearing.

+ +

CHRIS: Callbacks.

+ +

STEPH: Well, on that wonderful circular reference, shall we wrap up?

+ +

CHRIS: Wait, I thought circular references were bad...Never mind. Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed, or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+X5KbnRGU + + ]]> + + Chris Toomey + Steph Viccari + + + 304: MEGA Crossover Episode (The Bike Shed x Rails with Jason x Remote Ruby x Ruby on Rails Podcast) + https://bikeshed.thoughtbot.com/304 + 687d22c6-7a2b-40bb-80b0-ec83fe6387aa + Wed, 11 Aug 2021 08:00:00 -0400 + thoughtbot + + full + thoughtbot + This is the sweeps week episode, the epic crossover episode, the mega episode! We have a very special episode as Chris, and Steph teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! + +In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. They cover the origins of their shows, their experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. + 34:38 + no + + + This is the sweeps week episode, the epic crossover episode, the mega episode! We have a very special episode as Chris, and Steph teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! +In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. They cover the origins of their shows, their experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. +Remote Ruby (https://remoteruby.transistor.fm/) +Rails with Jason (https://www.codewithjason.com/rails-with-jason-podcast/) +Ruby on Rails podcast (https://5by5.tv/rubyonrails) +*Transcript: * +STEPH: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. This week we have a very special episode as Chris, and I teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. This episode was so much fun to record, and we have Brittany Martin to thank as she organized and moderated this special event. So without further ado, here is the mega Ruby episode. +BRITTANY: Welcome, everyone. We have a whopping seven podcast hosts recording today. So, listeners, you are in for a treat. This is the sweeps week episode, the epic crossover episode, the mega episode. We're going to need our editor to insert some epic sound effects right here. +Announcer: The mega episode. +BRITTANY: So let's go ahead and introduce the crew today. I am Brittany Martin from the Ruby on Rails Podcast. +CHRIS OLIVER: I'm Chris Oliver from Remote Ruby. +JASON CHARNES: I am Jason Charnes, also from Remote Ruby. +ANDREW: I am Andrew Mason, also from Remote Ruby. +STEPH: And I'm Stephanie Viccari from The Bike Shed. +CHRIS TOOMEY: I'm Chris Toomey from The Bike Shed. +JASON SWETT: And I'm Jason Swett from Rails with Jason +BRITTANY: Today, we're going to cover the origins of our shows, our experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. Now I know personally, I really enjoy the origin story behind Remote Ruby. So, Chris Oliver, could you kick us off with that? +CHRIS OLIVER: Yeah, we can go back maybe to the first time that Jason and I met, which was Jason emailed me out of the blue and was like, "Hey, are you going to be at RailsConf?" And I wasn't planning on it, but it was over in Kansas City, like four hours away from me. I was like, "No, I'm not going, but I'll meet you." So we went and drove over there and met and have been friends ever since. And Jason had the idea of doing an online meetup. And I'll let him explain where that started and turned into the Remote Ruby Podcast. +JASON CHARNES: I thought it would be a good idea. There weren't any online meetups. This was pre even the idea of shutting down the world for a pandemic. And maybe I was just too soon because I got Chris to speak at the first one, and we had 40, 50 people. I spoke at the next one, and there were 20. And by the third one, there were five of us. So it wasn't really a super sustainable thing for me to do. So Chris and I got together and said, "What if we tried podcasting?" Chris, you hadn't really done your own podcast at that point, had you? +CHRIS OLIVER: No, I don't think so. And you and I were just having calls every week or whatever just to hang out and chat. And we were like, why don't we just record that and publish that as a podcast? And here we are. +JASON CHARNES: Yeah. So we've been doing that. I think we started in 2018, so yeah, three years in June, and somehow people still keep listening to us talk but probably because we brought along our friend, Andrew. +ANDREW: Wow. Okay. No, that's not true. But yes, I was a guest on Remote Ruby before I joined as a host. And not to get into the details, but I was on another podcast, and something went down, and I no longer was on that podcast anymore. And Chris and Jason were like, "Do you want to come hang out with us?" And I was like, [chuckles] "Absolutely." So I started doing that, and at the same time, I also started The Ruby Blend with Nate Hopkins and Ron Cooke. And so we were doing that for a while until that had to tragically shut down. But I'm still here with Jason and Chris. I guess I should also mention that Jason Swett gave me my start in podcasting a month or two after I started full-time as a Rails developer on a now archived show called The Ruby Testing Podcast. +BRITTANY: Which is the perfect segue because Jason Swett was also my first opportunity to guest on a podcast. So I was already hosting, but I hadn't guested, which is kind of the opposite order. So, Jason, do you want to tell the origin of where Rails with Jason came from? +JASON SWETT: Sure. I'd been involved with podcasting since around 2016. I somehow ended up on the Ruby Rogues Podcast and was on there for maybe a year or so. And then, somehow, I got the idea that I could start my own podcast. And as an experiment, I started a podcast that I called The Ruby Testing Podcast, which I figured was sufficiently narrow that I could get some traction. And to my surprise, guests actually said yes to coming on the show. And also, to my surprise, people actually listened to the podcast. That gave me some confidence. So maybe a year later, I broadened, and I changed from The Ruby Testing Podcast to just Rails with Jason. And I have been doing that for something like two years. +BRITTANY: That's fantastic. I want to move to probably our most experienced podcast veteran, and that would be Chris Toomey. When I was learning how to code, I was listening to Giant Robots and then was excited for the transition that The Bike Shed took. Chris, I would love to hear the story of what it was like taking over a really popular podcast and really maintaining the drive behind it. +CHRIS TOOMEY: So, as you mentioned, I had done a little bit of podcasting. It was about a six-month run where I was a co-host on Giant Robots, which was the original podcast of thoughtbot. And that was more in the business and sort of how do we build a software company? So at that point, I was running Upcase, which was the subscription learning platform that thoughtbot had. So I was talking about the inner details of the business, and the marketing tests, and A/B tests and things like that that I was doing. And every week, I was sharing my MRR rather transparently in that thoughtbot way that we do. I did that for, like I said, about six months and then took a while off. +And in the background, thoughtbot had started up a new podcast called The Bike Shed, and that started October 31st of 2014. So The Bike Shed has been going for a long time now, and that was hosted by Derek Pryor and Sage Griffin. And they ran that for a number of years. I think it was about four years that the two of them worked collectively on that. But at some point, they both moved on from thoughtbot, and there was an opportunity for new hosts to step in. So I took over in August of 2018. So I've been doing this now for about three years. +And so, for that first year, I took the opportunity to do a tour around thoughtbot and talk with many different individuals from the company and a handful of people external to thoughtbot. But I knew that there were so many great voices and ideas and points of view within thoughtbot that I really wanted to spend some time getting to know more of them personally and then sharing that as much as I could with the existing audience that The Bike Shed had. But secretly, all along, I was looking for a person to hang out with all the more so, and Steph was the person that was a perfect choice for that. And so, for the past two years, Steph and I have been chatting. And I will send it over to Steph to share a little bit of her point of view on that transition. But from my point of view, it's been fantastic. +STEPH: I still remember exactly when we had the conversation. You were running The Bike Shed and doing an incredible job of just having weekly guests. And then you'd reached out to me and said, "Hey, would you be interested in doing an episode?" And I thought, "No, absolutely not. I can't podcast. I can't begin to do this." So you continued to convince me. And finally, you said something that resonated where you were like, "Well, we can just show up and record, and we don't have to publish. We can just see how it goes." I was like, that's a perfect safety net. I'm into that. So I showed up, and I think the first episode that you and I recorded ended up being titled What I Believe About Software. And it was a lot of fun. I realized I have a lot of things to say. And after that, I think it was another month or so. You continued interviewing more guests, but then you reached out to me and asked me if I wanted to be a co-host. And at that point, I was super jazzed about it, and it's been wonderful. It's been a roller coaster. I have learned a ton. +BRITTANY: I'm kind of seeing a pattern here where over the last three years, it seems like Remote Ruby came into place, Bike Shed transitioned. That's when I took over as host of the 5by5 Ruby on Rails Podcast. We're going to call it the golden era of the Ruby Podcasts. But for me, I probably have the longest-running podcast. It was started back in 2009 on the 5by5 Network, but it's gone through many different hosts. And so, I took over roughly about three and a half years ago as the main host from Kyle Daigle. And then, just a couple of weeks ago, as I announced on my podcast, we took the podcast independent. We are now just The Ruby on Rails Podcast. And I'm starting to change the model where I'm bringing in more co-hosts. So that way, I can get those regular updates that I really appreciate on all these podcasts we have featured on the show today. +I am curious. I want to talk about how we put together the episodes and plan out how everything's going to go down. I know for me, I'm currently a mix of interviews and co-host episodes. So I'd love to hear from Andrew. How do you plan out what Remote Ruby is going to be week to week? +ANDREW: This is an easy question because we don't at all. We don't plan. We do have some guests that come on, and sometimes, they may get their Zoom link the day of; who’s to say? But we really don't have a plan. We don't talk about what we're going to talk about beforehand. We all just kind of show up, and I think we have that kind of relationship and flow where it always just works. +JASON CHARNES: And I think part of that came from actually how Chris and I started the show because we were trying to make it as low stress as possible because we knew if we put a lot of pressure on it, we would stop doing it. Our first episodes were YouTube live links that we just shared out. And then in our next episodes, we were like, oh, we should start using some software to do this. And then eventually, we got an editor, but that same core of let's just keep it fun for better or for worse, I think, also affects our planning. +BRITTANY: I've been lucky in the sense that I have guests sit on all three of the episodes. And I do want to give a compliment to The Bike Shed because it is very well run and very well planned. So I want to kick it over to Steph as to how putting together a Bike Shed episode looks. +STEPH: Oh, thank you. That's wonderful to hear, by the way. That's wonderful feedback. So we predominantly use Trello to organize our thoughts. So we will have...and as we're capturing community questions that are coming in, so we will capture those on the board. And then, we will have a ticket that represents a particular episode. Usually, on the day of, we'll share some thoughts about, hey, these are the broad topics I'm interested in. And there's usually some hot takes in there, which is fun because the other person doesn't know exactly what's coming, and we can have real honest conversations on the mic. And then, every so often, we'll grab a beer, and we'll go through that list. And we'll chat through what sparks joy. What do we want to talk about? What would we like to respond to? And that's pretty much how we organize everything that we discuss. Chris, is there anything I've left out that you want to add? +CHRIS TOOMEY: I think that mostly covers it. We do occasionally have interviews just as a way to keep some variety and different things going on, but primarily it's the sort of what's new in your world? And I find that those episodes are the ones that I think are the most fun to record for Steph and I when it really feels like a sincere conversation. I've recently taken to a segment I call good idea, terrible idea where I'm like, "I'm actually considering this, Steph. What do you think?" And live on-air, I'm getting Steph's feedback, and generally, we're very aligned. But every once in a while, she's like, "That's a terrible idea. Don't do that." And I love those, and I love being able to share that because I think it's really easy to talk about, you know, here's a list of things that are true about software, but really, everything depends. And it's all the nuance. And so, being able to share some of our more pointed experiences and then share the conversation that we have over those is hopefully very valuable to the audience but definitely the thing that I enjoy the most. +BRITTANY: So kicking it over to Jason Swett, I really enjoy the interviews that you do. I'm curious, how do you select guests? +JASON SWETT: Well, thanks. Selecting guests is tough. I had Peter Cooper on the other day, and I was telling him that I feel like every guest that I get on the show is the last guest I'm ever going to be able to get on the show. But somehow, I keep finding more and more guests. Early on, it was relatively easy because I would just find book authors, or if somebody else does podcasting, then it's fairly obvious okay, you're the kind of person who does podcasts, so I'll invite you. +But it's a little bit tough because I don't want to invite people who aren't into podcasting and would be really thrown, although sometimes that happens. But let's see, sometimes I send an email out to my email list, and I'm like, "Hey, I'm looking for guests for my show." Sometimes I just tweet that I'm looking for guests. And sometimes I get some really interesting guests from surprising places. But at least in the start, it was looking for those authors and podcasters and the people who are known in the Ruby community. +BRITTANY: I know for me, I strive to have at least 50% of my interviews be with people who've never been on a podcast before. And so that usually involves the top of the episode they're dry heaving into a paper bag. And I'm explaining to them, don't worry, about halfway through the episode, you're not going to remember that you're recording anymore. It'll be fine. And you know what? It's always fine. And so, I do love hearing from a wide variety from the Ruby community just because it really proves just how big it is. So I'm curious, could you host the podcast that you are currently hosting now if you weren't actively working in Ruby? +ANDREW: I could because Chris is the one that has all the clout. I could sit back and make dumb jokes and memes during it. And as long as Chris is there, I think we'll be good. +JASON SWETT: Yeah, I think I could because a good majority of what we talk about on Rails with Jason actually has nothing to do with Rails, so that would probably actually work out. +STEPH: I think yes is the answer. While a lot of our conversations do focus around Ruby and Rails, we often use a lot of other languages and tools, and those are a lot of fun to talk about. So I think I would just talk about whatever new tool or language that I'm using. So I think yes, it would just take a slightly different form but would still be at its core the same where we're still talking about our daily experiments and adventures in web development. +BRITTANY: I agree with you, Steph. I will say that it seems like Chris Oliver and Chris Toomey have an endless well of things to talk about just based on what they do day-to-day. +CHRIS TOOMEY: I try and go on adventures and then share as much as I can. But to resonate with what Steph was saying there, we try to make the show more generally about software, and it happens to be that it's grounded in Ruby on Rails because the vast majority of the work that we do is in that. And I just recently started a new project. I was given the choice of I could pick any technology I want, and it remains the technology that makes sense to me to be the foundation of an application that I want to maintain for years and years and years. So, on the one hand, I think I could definitely talk about software more generally. I think I'm doing that most of the time. But at the other end of the spectrum, but it's always going to be based on Ruby because I haven't found a thing elsewhere in the world that is better than that. +CHRIS OLIVER: I completely agree with that. I probably have a little bit of a unique thing doing a screencast every week. A lot of those are based on I'm building some project, and I need to build some random feature like Stripe Checkout. And that's a good one to do a screencast on and implement in the project. And then, we can also talk about the decisions along the way on the podcast, which is kind of nice. +BRITTANY: Yeah, it feels like every week, Chris Oliver is like, yeah, I've created a new open-source library, and I'm fabulous. [laughs] Let me listen to this. +CHRIS OLIVER: Too many of them. I'm currently rewriting a lot of the Pay gem. And it's just one of those things where you make a bunch of decisions. And then, if you make an open-source project, people use it in all these different ways that you didn't intend yourself, and so you want to support that. But then you need to rearchitect things in it. It is a lot of learning as you go, which is always a lot of fun. So those I think are really good topics to talk about when you're building something like that. +I'm always amazed by how does the Rails core team make these decisions on what should be in the framework and what shouldn't? And what do they want to maintain, and how do they keep it flexible but yet have some sort of rule with how they allow things to be implemented and whatever? It is a very hard job to have. So I get my little taste of that with some open source but not on their level. +BRITTANY: I always thought that you had a good contrast to Jason Charnes because Jason works at Podia. And while you do get to work on a lot of really cool technologies, I feel like the stakes are much higher. So you can't just rip out StimulusReflex and put in something else just because it sounds cool that week. And I love how you talk through the pluses and minuses to making a big change within the Podia codebase. +JASON CHARNES: Yeah. I haven't really thought about that contrast before, but it's helpful for me even just to talk it out with two other people once a week, and luckily, pretty cool about me just coming on and talking about hey, these are the steps we took to get here. Yeah, it's a cool dynamic. +BRITTANY: Steph, have you ever had a client from thoughtbot say, "Hey, were you talking about me?" whenever you're talking about your current client? +STEPH: That is one of my fears at times that it will happen [chuckles] although we stay very positive on the show. That's something that's very important to us. There's enough negativity in the world. So we really want to focus on our positive experiences through the week. But there have been times where I'm speaking about some of the challenges or things that we are running into that yes, the engineering team is listening to the podcast, and they're like, "Oh, I heard you talk about this feature that we're working on or this particular challenge." And that's really cool because they get that behind-the-scenes peek to see how Chris and I are chatting about that. But yet they know enough, and they know which project that I'm on that they recognize exactly the technology and the feature that I'm trying to describe. So that has certainly happened, and it can be a lot of fun when it does. +BRITTANY: Andrew, how have things changed for you now that you're not working at CodeFund, which was very much like an open-source thing? People could see what you were actively working on. And now you're working for a company where it's closed source. And so, you might not be able to reveal as much as what you're working on at any given point. +ANDREW: It's different, but I don't think it's been an issue per se. I'm not like, oh crap, I let that slip, and I didn't mean to. That's not really an issue. I really cherish the time I had at CodeFund. When I think back on my experiences, that was my favorite time just because I was able to do that thing that a lot of people really want to do. I was working as an open-source developer. We were spiking StimulusReflex; that’s when we were building up StimulusReflex and trying to build up the community. I joined Ruby. We started the Ruby Blend, and things were going good before a dramatic turn. But in terms of the closed and open source, it hasn't been that big of a shift just because instead of talking about what I'm doing at work, like, I still talk about it, but I speak about it in more general terms. But I also then kind of freed up to talk a lot more about the dumb crap I do on the nights and weekends. +BRITTANY: So the majority of our podcasts either have the word Ruby or Rails in it, but I think we've all agreed that a lot of the topics that we're talking about are not specific to that community. But in a lot of ways, I feel that having podcasts in our community is how we're going to keep our community thriving. So I'm curious if anyone has any thoughts around...is there a way to market our podcasts so that other developers will listen to it? I get really excited when I get listener feedback saying, "Hey, I used to do Rails maybe ten years ago, but I've been listening to your podcast, and I really enjoy such and such episode." How can we make our podcasts accessible to the general software community as opposed to just Ruby? +CHRIS TOOMEY: One thing that stands out to me about Ruby and Rails is because it's full-stack, because of its foundations, it tends to be holistically about web development. And so, whereas I look at React projects or other JavaScript or different things that are going on, I see a more narrow focus in those frameworks. And with Ruby and Rails, what I love about it is that it's really about building software. It's about building products that are valuable, that deliver value to end-users. And so that being the core of it, that's the story that constantly brings me back to Ruby and Rails. And it's the story that I want to keep telling as much as possible. And it's the thing that keeps me engaged with this community. And so, I think podcasts are a great way to continue to literally tell those sorts of stories and really celebrate that aspect of Ruby and Rails and why it remains such a productive way to build software. +CHRIS OLIVER: I think related to that, one of the things that we should talk about more is the draw of Rails was look at what you can do with one person or two people. And I feel like we went down the JavaScript route, and now you need two teams of people, and you end up building bigger stuff. And Hotwire has kind of been like, hey, here's a reminder of what you can do with a very small team. And I think that resonates a lot with a lot of people building startups and trying to build side projects and everything. And that's one that is Rails-related. But there's a ton of people building Hotwire stuff in Laravel too. And they're all very similar. So I think at a certain point, yeah, we're talking about maybe Rails specifically, but you can apply all those things to different frameworks and just different tools. +STEPH: I'd like to add on and extend that because I wholeheartedly agree with what both Chris Toomey and Chris Oliver just said. And in addition, a lot of the conversations that we have on The Bike Shed are focused on Ruby and Rails, but then we will extract that particular concept to the point that it really doesn't matter which language that you're using or which framework that you're using. We're talking more about the high level. What's your process? What are you thinking as you're going through and implementing this? And based on more of our recent conversations, you'd think we're more of a Postgres podcast, how much we hype up Postgres, and the things that we can do at the database layer. So I think there are a lot of ways that we can start with a foundation of this is how we're doing it with Ruby and Rails, but then talk about it at a higher level where then it's really applicable for everybody. +JASON CHARNES: If talking about one technology defined your podcast, we might as well be a Laravel podcast because we talk about that framework more than we do Rails sometimes. [chuckles] +BRITTANY: So that begs the question: is there room for more Ruby and Rails podcasts outside of who's currently on this call? +JASON SWETT: I think so. And I mentioned that Peter Cooper was on our podcast a little bit ago. That's something he and I actually talked about in that episode. And I shared the anecdote about how in the new America's founding, Ben Franklin's brother or something like that wanted to start a newspaper. And somebody told him what a dumb idea that was because America already had a newspaper. And people might say, oh, there are already however many Rails podcasts. There are a small handful. But I think there could be ten more Rails podcasts or even more than that potentially because I think people have an appetite for help, and camaraderie, and stuff like that. And I don't think we've nearly bottomed out in terms of satisfying people's appetite for that stuff. +JASON CHARNES: Yeah, I agree with that because a lot of times, when I listen to podcasts, the more you get to know someone, that connection becomes what it's about for me. So, yeah, there's plenty of room. I mean, brand it as Ruby and tell me about your life as a developer I'll listen. +CHRIS TOOMEY: I'll also throw it out there that the way you framed the question is like, is there room for it? But one of the wonderful things about podcasting as a medium is it is distributed. It's not centralized. You can start up a podcast any day. And I will say, as someone who inherited a popular podcast or a sufficiently popular podcast and just got to run with that, it has been such a wonderful way to get my voice out there and provide opportunities that I want that for everyone. I want everyone to have this ability to speak about the way they think about software and then find like-minded people and be able to build even many communities within the larger community of Ruby on Rails. So beyond the question of, Is there room?” which I definitely think there is, I so wholeheartedly support anyone pursuing this for their own reason. +ANDREW: Yeah, I think to bring it all the way back, one thing that Chris, Jason, and I care a lot about is Ruby as a community. The community aspects of Ruby are very important to us. And we're actively trying to build that up and bring in new people and bringing people onto their first podcast. We say it all the time, like, hey, if you want to come on the show, let us know. We've had a few people even, you know, recognition in jobs from that. So to us, that is the payoff of doing the show. Maybe our show is the first time someone learns about Rails. And that to me is the possibility in the future. It's like, how can we market our shows that markets Ruby as well so that this meme of Ruby being dead finally goes away because it's not. I think it's growing. And I think the more and more we push as people who are public figures in this space that we want to bring more people on, that this is a space for everyone, I think that's just kind of the ethos that all of us have, and I think that's great. +BRITTANY: So I'm curious, on a lighter note, has anyone had the funny experience of realizing that you're not just podcasting into the ether and that what you're saying and what you're doing matters? For me, I have definitely been at conferences where people will run up and hug me just because they heard my voice, and they are like, "I didn't know what you looked like, but I have your voice memorized," and it just blew my mind. And I was like, "Thank you so much for being such a loyal listener." And it just proves that people are out there listening. +ANDREW: I tend to talk very openly about mental health. And I very often fail in public and talk about it. And I've had a lot of people message me and email me over the past three or four years and be like, "Hey, thank you for talking about this thing that's not actually about Ruby. It's not actually about coding, but it's just about being a developer." And those are the emails that make me feel the best. Like, someone who's out there like, "Yeah, I also feel like this. Thank you for speaking about it." +JASON SWETT: I had a surreal experience. I went to India in 2019 through RubyConf India. And this guy wanted to take a selfie with me because apparently, he considered me famous. So that was cool and pretty surprising because I definitely didn't consider myself famous. +STEPH: My favorite has been when we receive listener questions because it lets us know that people are listening and engaged in the conversation, and I essentially feel like they're part of the conversation. They will write in to us and share anecdotes, or they'll share answers to some of the questions that Chris and I will pose on the show. But every now and then, we will also get an email from someone that says, "Hey, just thanks for doing the show. I listen, and it's great," and that's all they share. And that, to me, is just the most wonderful thing that I could receive. +BRITTANY: Some of my favorite episodes from all of your shows is when we get an inside peek into what people are doing, like Andrew moving. Jason Charnes, you putting together a conference was actually some of my favorite episodes of yours, which was really early on, which proves that I'm a Remote Ruby OG. But I loved hearing the inside track as to what organizing a conference is because I think we need to get more content out there about how difficult but how rewarding it is. +JASON CHARNES: Yeah, I hadn't really thought about...that was around those times we hadn't done... It feels like it's been ages since we did Southeast Ruby, but Chris and I actually podcasted from the last Southeast Ruby we did. We just met in a room and recorded. But when I started that conference, I didn't have a lot to go on. So I'm more than glad to share because the reason I started is there were no Ruby conferences around me, plus I'm an open book. So for better or for worse, maybe that's good podcast material. +JASON SWETT: Side note, it's one of the most enjoyable conferences I've ever been to. +JASON CHARNES: Thank you. +BRITTANY: I completely agree. I miss the regional conferences. +JASON CHARNES: We lucked out because we were already planning on skipping 2020 because we were tired, and then COVID hit. I just sat on the couch one night and looked at Shannon (she helps me put on the conference), and I was like, "Wow, that would have been terrible. That would have come out of our own bank account, all that loss if we would have already booked somewhere." So phew, when it chills out, we'll try it again. +BRITTANY: So let's talk about legacies. I know that some of us have taken over from popular podcasts. Some of us have grown podcasts from the very beginning. So I'm curious, do you ever put any thought into the legacy of your podcast, whether or not you're going to stay with it to the end? Would you eventually pass it off? Do you think about whether or not it's your responsibility to the community to make sure that it keeps going? +JASON SWETT: I, for one, plan to have my consciousness uploaded to a supercomputer upon my death so that the Rails with Jason Podcast can continue on indefinitely. +JASON CHARNES: Did you recently watch Upload the TV show? +JASON SWETT: No, I've never heard of it. +JASON CHARNES: Oh, man. That's a whole nother conversation. +BRITTANY: Consider that homework, Jason. +JASON CHARNES: It's an interesting question because we started ours out of nothing. I wonder, is one of us going to get tired and just quit? I'd like to think that if one of us did, it would keep going because there are plenty of cool people who could hang out and talk Ruby on it. But it's interesting, something that's casually crossed my mind, but I think we're good. I think we're still doing it unless Chris and Andrew have a surprise for me today. +ANDREW: Surprise! [chuckles] I've thought about it a few times, specifically because I'm the youngest member of Remote Ruby. What if Jason and Chris just left, and they were like, "Oh, it's all yours now." Could I keep running it by myself? I think honestly, the answer is I would probably still do it just to have an excuse to talk to someone. I enjoy it. It's almost like a hobby at this point. I don't feel any obligation to create it. To me, it's really like an excuse to hang out with two friends, and other good stuff comes from that. But at the end of the day, I cherish that time just us hanging out a lot. +CHRIS OLIVER: Yeah. I think that's why we sometimes joke about it being a weekly therapy session where we are just hanging out and chatting about stuff. It's nice to be able to talk about programming things at a high level with people you don't work with that have totally different perspectives and stuff. So yeah, if Jason and Andrew dropped off, I would still try to have conversations with random people I know and keep it going just because it's enjoyable. I would hope that we would be able to keep it going and have other people on there. +BRITTANY: I'd love to hear from someone from The Bike Shed. +STEPH: I have thought about it. I've thought about it partially from the perspective that Chris Toomey brought up earlier in regards to being on a podcast is an incredible platform. You get to share your opinions, and people listen to you. And they know you, and it's really wonderful marketing. So I have thought about it from the perspective of I want other people to have access to this really wonderful podcast that we put on each week. So part of me is very aware of that and thinking about how more people can have similar exposures. +So a sort of a similar event occurred when Chris was moving on from thoughtbot and pursuing other interests. And at that moment, I just thought, oh my goodness, Chris brought me on as co-host, and now I'm here alone, and I don't know what I'm going to do. And I just panicked. I truly don't think I even considered other options. I was like, well, okay, it's over now. This was fun. And then it turned out where Chris was going to stay with the show. So things have just gone on swimmingly, and it's been wonderful. +But similar to what someone was saying earlier around when you start listening to a podcast, and you really develop that relationship and you go back to that podcast because you really enjoy hearing from those people and their adventures, it's very similar for me where The Bike Shed is very much the conversations and chats with Chris. So I think if we were to move on, it would be whenever Chris and I decided to move on and give the reins over to somebody else. I don't know if Chris fully agrees, so this will be interesting to find out. [chuckles] +CHRIS TOOMEY: I agree with that. Honestly, I'm honored to have continued on in the podcast after having moved on from thoughtbot because, in a very real way, the show is thoughtbot's channel to talk about things. I was at thoughtbot for seven years. I think I live and breathe that truth. And to me, that's what maybe has made sense for me to continue on. But I really do feel a responsibility to keep the show in good shape so that someday someone else gets to inherit this thing because I was so happy to get handed it. It was such a wonderful thing. And it has been such a joy to do for these past three years. +But at some point, I do presume that we will move on. And at that point, I do hope that other people pick up the mantle. And thankfully, thoughtbot as an organization, there is a group of individuals that I'm sure there will be someone wonderful that gets to step in, but I'm in no hurry to do that. And, Steph, I hope you're not either. So we'll continue the conversations for now, but I definitely do want to keep this thing alive if for no other reason than I got handed it. I don't feel like I could let it drop on the floor. That doesn't feel right. +BRITTANY: Well, I think on that warm, fuzzy feeling, we should wrap up. So let's go through everybody and just tell the listeners where they can listen to your podcasts and follow you. I am Brittany Martin, @BrittJMartin on Twitter. And you can listen to the Ruby on Rails Podcast at therubyonrailspodcast.com. +JASON CHARNES: So I'm Jason. We are Remote Ruby. I am @jmcharnes on Twitter. And I'll let the others tell you where you can find them. +ANDREW: You can find me everywhere @andrewmcodes. And if you email me, there's a really good chance you're never going to see a response because my email is a disaster. Please don't email me, but you can contact me anywhere else. +CHRIS OLIVER: I'm Chris Oliver, and you can find me on Twitter @excid3 or at Go Rails, and of course, gorails.com. And you can find the Remote Ruby podcast at remoteruby.com. +CHRIS TOOMEY: I am @christoomey on Twitter. The Bike Shed is @bikeshed on Twitter. We are at bikeshed.fm for a URL. I'm pretty sure www works, but I'm going to go check that real quick after because I want to make sure that's true. And yeah, that's me. And I'll send it over to Steph for her part. +STEPH: I am on Twitter @SViccari, and I post programming stuff, usually pictures of cute goats, cute dogs, that kind of content if you're into that. +JASON SWETT: For me, if you want to find my podcast, it's Rails with Jason. And if you search for Rails with Jason anywhere, you should be able to find it. And then my website, if you're interested in my blog and all that stuff, is codewithjason.com. +BRITTANY: Fantastic. Thank you, everyone, for being on this mega episode today. It was a lot of fun. We are going to be having a podcast panel at RubyConf; we’re excited to announce and some of us will be present. So stay tuned for details around that. And if you enjoyed this mega episode and want to see more mega episodes, please let us know on Twitter. +All: Bye. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + This is the sweeps week episode, the epic crossover episode, the mega episode! We have a very special episode as Chris, and Steph teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode!

+ +

In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. They cover the origins of their shows, their experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving.

+ + + +

*Transcript: *

+ +

STEPH: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. This week we have a very special episode as Chris, and I teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. This episode was so much fun to record, and we have Brittany Martin to thank as she organized and moderated this special event. So without further ado, here is the mega Ruby episode.

+ +

BRITTANY: Welcome, everyone. We have a whopping seven podcast hosts recording today. So, listeners, you are in for a treat. This is the sweeps week episode, the epic crossover episode, the mega episode. We're going to need our editor to insert some epic sound effects right here.

+ +

Announcer: The mega episode.

+ +

BRITTANY: So let's go ahead and introduce the crew today. I am Brittany Martin from the Ruby on Rails Podcast.

+ +

CHRIS OLIVER: I'm Chris Oliver from Remote Ruby.

+ +

JASON CHARNES: I am Jason Charnes, also from Remote Ruby.

+ +

ANDREW: I am Andrew Mason, also from Remote Ruby.

+ +

STEPH: And I'm Stephanie Viccari from The Bike Shed.

+ +

CHRIS TOOMEY: I'm Chris Toomey from The Bike Shed.

+ +

JASON SWETT: And I'm Jason Swett from Rails with Jason

+ +

BRITTANY: Today, we're going to cover the origins of our shows, our experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. Now I know personally, I really enjoy the origin story behind Remote Ruby. So, Chris Oliver, could you kick us off with that?

+ +

CHRIS OLIVER: Yeah, we can go back maybe to the first time that Jason and I met, which was Jason emailed me out of the blue and was like, "Hey, are you going to be at RailsConf?" And I wasn't planning on it, but it was over in Kansas City, like four hours away from me. I was like, "No, I'm not going, but I'll meet you." So we went and drove over there and met and have been friends ever since. And Jason had the idea of doing an online meetup. And I'll let him explain where that started and turned into the Remote Ruby Podcast.

+ +

JASON CHARNES: I thought it would be a good idea. There weren't any online meetups. This was pre even the idea of shutting down the world for a pandemic. And maybe I was just too soon because I got Chris to speak at the first one, and we had 40, 50 people. I spoke at the next one, and there were 20. And by the third one, there were five of us. So it wasn't really a super sustainable thing for me to do. So Chris and I got together and said, "What if we tried podcasting?" Chris, you hadn't really done your own podcast at that point, had you?

+ +

CHRIS OLIVER: No, I don't think so. And you and I were just having calls every week or whatever just to hang out and chat. And we were like, why don't we just record that and publish that as a podcast? And here we are.

+ +

JASON CHARNES: Yeah. So we've been doing that. I think we started in 2018, so yeah, three years in June, and somehow people still keep listening to us talk but probably because we brought along our friend, Andrew.

+ +

ANDREW: Wow. Okay. No, that's not true. But yes, I was a guest on Remote Ruby before I joined as a host. And not to get into the details, but I was on another podcast, and something went down, and I no longer was on that podcast anymore. And Chris and Jason were like, "Do you want to come hang out with us?" And I was like, [chuckles] "Absolutely." So I started doing that, and at the same time, I also started The Ruby Blend with Nate Hopkins and Ron Cooke. And so we were doing that for a while until that had to tragically shut down. But I'm still here with Jason and Chris. I guess I should also mention that Jason Swett gave me my start in podcasting a month or two after I started full-time as a Rails developer on a now archived show called The Ruby Testing Podcast.

+ +

BRITTANY: Which is the perfect segue because Jason Swett was also my first opportunity to guest on a podcast. So I was already hosting, but I hadn't guested, which is kind of the opposite order. So, Jason, do you want to tell the origin of where Rails with Jason came from?

+ +

JASON SWETT: Sure. I'd been involved with podcasting since around 2016. I somehow ended up on the Ruby Rogues Podcast and was on there for maybe a year or so. And then, somehow, I got the idea that I could start my own podcast. And as an experiment, I started a podcast that I called The Ruby Testing Podcast, which I figured was sufficiently narrow that I could get some traction. And to my surprise, guests actually said yes to coming on the show. And also, to my surprise, people actually listened to the podcast. That gave me some confidence. So maybe a year later, I broadened, and I changed from The Ruby Testing Podcast to just Rails with Jason. And I have been doing that for something like two years.

+ +

BRITTANY: That's fantastic. I want to move to probably our most experienced podcast veteran, and that would be Chris Toomey. When I was learning how to code, I was listening to Giant Robots and then was excited for the transition that The Bike Shed took. Chris, I would love to hear the story of what it was like taking over a really popular podcast and really maintaining the drive behind it.

+ +

CHRIS TOOMEY: So, as you mentioned, I had done a little bit of podcasting. It was about a six-month run where I was a co-host on Giant Robots, which was the original podcast of thoughtbot. And that was more in the business and sort of how do we build a software company? So at that point, I was running Upcase, which was the subscription learning platform that thoughtbot had. So I was talking about the inner details of the business, and the marketing tests, and A/B tests and things like that that I was doing. And every week, I was sharing my MRR rather transparently in that thoughtbot way that we do. I did that for, like I said, about six months and then took a while off.

+ +

And in the background, thoughtbot had started up a new podcast called The Bike Shed, and that started October 31st of 2014. So The Bike Shed has been going for a long time now, and that was hosted by Derek Pryor and Sage Griffin. And they ran that for a number of years. I think it was about four years that the two of them worked collectively on that. But at some point, they both moved on from thoughtbot, and there was an opportunity for new hosts to step in. So I took over in August of 2018. So I've been doing this now for about three years.

+ +

And so, for that first year, I took the opportunity to do a tour around thoughtbot and talk with many different individuals from the company and a handful of people external to thoughtbot. But I knew that there were so many great voices and ideas and points of view within thoughtbot that I really wanted to spend some time getting to know more of them personally and then sharing that as much as I could with the existing audience that The Bike Shed had. But secretly, all along, I was looking for a person to hang out with all the more so, and Steph was the person that was a perfect choice for that. And so, for the past two years, Steph and I have been chatting. And I will send it over to Steph to share a little bit of her point of view on that transition. But from my point of view, it's been fantastic.

+ +

STEPH: I still remember exactly when we had the conversation. You were running The Bike Shed and doing an incredible job of just having weekly guests. And then you'd reached out to me and said, "Hey, would you be interested in doing an episode?" And I thought, "No, absolutely not. I can't podcast. I can't begin to do this." So you continued to convince me. And finally, you said something that resonated where you were like, "Well, we can just show up and record, and we don't have to publish. We can just see how it goes." I was like, that's a perfect safety net. I'm into that. So I showed up, and I think the first episode that you and I recorded ended up being titled What I Believe About Software. And it was a lot of fun. I realized I have a lot of things to say. And after that, I think it was another month or so. You continued interviewing more guests, but then you reached out to me and asked me if I wanted to be a co-host. And at that point, I was super jazzed about it, and it's been wonderful. It's been a roller coaster. I have learned a ton.

+ +

BRITTANY: I'm kind of seeing a pattern here where over the last three years, it seems like Remote Ruby came into place, Bike Shed transitioned. That's when I took over as host of the 5by5 Ruby on Rails Podcast. We're going to call it the golden era of the Ruby Podcasts. But for me, I probably have the longest-running podcast. It was started back in 2009 on the 5by5 Network, but it's gone through many different hosts. And so, I took over roughly about three and a half years ago as the main host from Kyle Daigle. And then, just a couple of weeks ago, as I announced on my podcast, we took the podcast independent. We are now just The Ruby on Rails Podcast. And I'm starting to change the model where I'm bringing in more co-hosts. So that way, I can get those regular updates that I really appreciate on all these podcasts we have featured on the show today.

+ +

I am curious. I want to talk about how we put together the episodes and plan out how everything's going to go down. I know for me, I'm currently a mix of interviews and co-host episodes. So I'd love to hear from Andrew. How do you plan out what Remote Ruby is going to be week to week?

+ +

ANDREW: This is an easy question because we don't at all. We don't plan. We do have some guests that come on, and sometimes, they may get their Zoom link the day of; who’s to say? But we really don't have a plan. We don't talk about what we're going to talk about beforehand. We all just kind of show up, and I think we have that kind of relationship and flow where it always just works.

+ +

JASON CHARNES: And I think part of that came from actually how Chris and I started the show because we were trying to make it as low stress as possible because we knew if we put a lot of pressure on it, we would stop doing it. Our first episodes were YouTube live links that we just shared out. And then in our next episodes, we were like, oh, we should start using some software to do this. And then eventually, we got an editor, but that same core of let's just keep it fun for better or for worse, I think, also affects our planning.

+ +

BRITTANY: I've been lucky in the sense that I have guests sit on all three of the episodes. And I do want to give a compliment to The Bike Shed because it is very well run and very well planned. So I want to kick it over to Steph as to how putting together a Bike Shed episode looks.

+ +

STEPH: Oh, thank you. That's wonderful to hear, by the way. That's wonderful feedback. So we predominantly use Trello to organize our thoughts. So we will have...and as we're capturing community questions that are coming in, so we will capture those on the board. And then, we will have a ticket that represents a particular episode. Usually, on the day of, we'll share some thoughts about, hey, these are the broad topics I'm interested in. And there's usually some hot takes in there, which is fun because the other person doesn't know exactly what's coming, and we can have real honest conversations on the mic. And then, every so often, we'll grab a beer, and we'll go through that list. And we'll chat through what sparks joy. What do we want to talk about? What would we like to respond to? And that's pretty much how we organize everything that we discuss. Chris, is there anything I've left out that you want to add?

+ +

CHRIS TOOMEY: I think that mostly covers it. We do occasionally have interviews just as a way to keep some variety and different things going on, but primarily it's the sort of what's new in your world? And I find that those episodes are the ones that I think are the most fun to record for Steph and I when it really feels like a sincere conversation. I've recently taken to a segment I call good idea, terrible idea where I'm like, "I'm actually considering this, Steph. What do you think?" And live on-air, I'm getting Steph's feedback, and generally, we're very aligned. But every once in a while, she's like, "That's a terrible idea. Don't do that." And I love those, and I love being able to share that because I think it's really easy to talk about, you know, here's a list of things that are true about software, but really, everything depends. And it's all the nuance. And so, being able to share some of our more pointed experiences and then share the conversation that we have over those is hopefully very valuable to the audience but definitely the thing that I enjoy the most.

+ +

BRITTANY: So kicking it over to Jason Swett, I really enjoy the interviews that you do. I'm curious, how do you select guests?

+ +

JASON SWETT: Well, thanks. Selecting guests is tough. I had Peter Cooper on the other day, and I was telling him that I feel like every guest that I get on the show is the last guest I'm ever going to be able to get on the show. But somehow, I keep finding more and more guests. Early on, it was relatively easy because I would just find book authors, or if somebody else does podcasting, then it's fairly obvious okay, you're the kind of person who does podcasts, so I'll invite you.

+ +

But it's a little bit tough because I don't want to invite people who aren't into podcasting and would be really thrown, although sometimes that happens. But let's see, sometimes I send an email out to my email list, and I'm like, "Hey, I'm looking for guests for my show." Sometimes I just tweet that I'm looking for guests. And sometimes I get some really interesting guests from surprising places. But at least in the start, it was looking for those authors and podcasters and the people who are known in the Ruby community.

+ +

BRITTANY: I know for me, I strive to have at least 50% of my interviews be with people who've never been on a podcast before. And so that usually involves the top of the episode they're dry heaving into a paper bag. And I'm explaining to them, don't worry, about halfway through the episode, you're not going to remember that you're recording anymore. It'll be fine. And you know what? It's always fine. And so, I do love hearing from a wide variety from the Ruby community just because it really proves just how big it is. So I'm curious, could you host the podcast that you are currently hosting now if you weren't actively working in Ruby?

+ +

ANDREW: I could because Chris is the one that has all the clout. I could sit back and make dumb jokes and memes during it. And as long as Chris is there, I think we'll be good.

+ +

JASON SWETT: Yeah, I think I could because a good majority of what we talk about on Rails with Jason actually has nothing to do with Rails, so that would probably actually work out.

+ +

STEPH: I think yes is the answer. While a lot of our conversations do focus around Ruby and Rails, we often use a lot of other languages and tools, and those are a lot of fun to talk about. So I think I would just talk about whatever new tool or language that I'm using. So I think yes, it would just take a slightly different form but would still be at its core the same where we're still talking about our daily experiments and adventures in web development.

+ +

BRITTANY: I agree with you, Steph. I will say that it seems like Chris Oliver and Chris Toomey have an endless well of things to talk about just based on what they do day-to-day.

+ +

CHRIS TOOMEY: I try and go on adventures and then share as much as I can. But to resonate with what Steph was saying there, we try to make the show more generally about software, and it happens to be that it's grounded in Ruby on Rails because the vast majority of the work that we do is in that. And I just recently started a new project. I was given the choice of I could pick any technology I want, and it remains the technology that makes sense to me to be the foundation of an application that I want to maintain for years and years and years. So, on the one hand, I think I could definitely talk about software more generally. I think I'm doing that most of the time. But at the other end of the spectrum, but it's always going to be based on Ruby because I haven't found a thing elsewhere in the world that is better than that.

+ +

CHRIS OLIVER: I completely agree with that. I probably have a little bit of a unique thing doing a screencast every week. A lot of those are based on I'm building some project, and I need to build some random feature like Stripe Checkout. And that's a good one to do a screencast on and implement in the project. And then, we can also talk about the decisions along the way on the podcast, which is kind of nice.

+ +

BRITTANY: Yeah, it feels like every week, Chris Oliver is like, yeah, I've created a new open-source library, and I'm fabulous. [laughs] Let me listen to this.

+ +

CHRIS OLIVER: Too many of them. I'm currently rewriting a lot of the Pay gem. And it's just one of those things where you make a bunch of decisions. And then, if you make an open-source project, people use it in all these different ways that you didn't intend yourself, and so you want to support that. But then you need to rearchitect things in it. It is a lot of learning as you go, which is always a lot of fun. So those I think are really good topics to talk about when you're building something like that.

+ +

I'm always amazed by how does the Rails core team make these decisions on what should be in the framework and what shouldn't? And what do they want to maintain, and how do they keep it flexible but yet have some sort of rule with how they allow things to be implemented and whatever? It is a very hard job to have. So I get my little taste of that with some open source but not on their level.

+ +

BRITTANY: I always thought that you had a good contrast to Jason Charnes because Jason works at Podia. And while you do get to work on a lot of really cool technologies, I feel like the stakes are much higher. So you can't just rip out StimulusReflex and put in something else just because it sounds cool that week. And I love how you talk through the pluses and minuses to making a big change within the Podia codebase.

+ +

JASON CHARNES: Yeah. I haven't really thought about that contrast before, but it's helpful for me even just to talk it out with two other people once a week, and luckily, pretty cool about me just coming on and talking about hey, these are the steps we took to get here. Yeah, it's a cool dynamic.

+ +

BRITTANY: Steph, have you ever had a client from thoughtbot say, "Hey, were you talking about me?" whenever you're talking about your current client?

+ +

STEPH: That is one of my fears at times that it will happen [chuckles] although we stay very positive on the show. That's something that's very important to us. There's enough negativity in the world. So we really want to focus on our positive experiences through the week. But there have been times where I'm speaking about some of the challenges or things that we are running into that yes, the engineering team is listening to the podcast, and they're like, "Oh, I heard you talk about this feature that we're working on or this particular challenge." And that's really cool because they get that behind-the-scenes peek to see how Chris and I are chatting about that. But yet they know enough, and they know which project that I'm on that they recognize exactly the technology and the feature that I'm trying to describe. So that has certainly happened, and it can be a lot of fun when it does.

+ +

BRITTANY: Andrew, how have things changed for you now that you're not working at CodeFund, which was very much like an open-source thing? People could see what you were actively working on. And now you're working for a company where it's closed source. And so, you might not be able to reveal as much as what you're working on at any given point.

+ +

ANDREW: It's different, but I don't think it's been an issue per se. I'm not like, oh crap, I let that slip, and I didn't mean to. That's not really an issue. I really cherish the time I had at CodeFund. When I think back on my experiences, that was my favorite time just because I was able to do that thing that a lot of people really want to do. I was working as an open-source developer. We were spiking StimulusReflex; that’s when we were building up StimulusReflex and trying to build up the community. I joined Ruby. We started the Ruby Blend, and things were going good before a dramatic turn. But in terms of the closed and open source, it hasn't been that big of a shift just because instead of talking about what I'm doing at work, like, I still talk about it, but I speak about it in more general terms. But I also then kind of freed up to talk a lot more about the dumb crap I do on the nights and weekends.

+ +

BRITTANY: So the majority of our podcasts either have the word Ruby or Rails in it, but I think we've all agreed that a lot of the topics that we're talking about are not specific to that community. But in a lot of ways, I feel that having podcasts in our community is how we're going to keep our community thriving. So I'm curious if anyone has any thoughts around...is there a way to market our podcasts so that other developers will listen to it? I get really excited when I get listener feedback saying, "Hey, I used to do Rails maybe ten years ago, but I've been listening to your podcast, and I really enjoy such and such episode." How can we make our podcasts accessible to the general software community as opposed to just Ruby?

+ +

CHRIS TOOMEY: One thing that stands out to me about Ruby and Rails is because it's full-stack, because of its foundations, it tends to be holistically about web development. And so, whereas I look at React projects or other JavaScript or different things that are going on, I see a more narrow focus in those frameworks. And with Ruby and Rails, what I love about it is that it's really about building software. It's about building products that are valuable, that deliver value to end-users. And so that being the core of it, that's the story that constantly brings me back to Ruby and Rails. And it's the story that I want to keep telling as much as possible. And it's the thing that keeps me engaged with this community. And so, I think podcasts are a great way to continue to literally tell those sorts of stories and really celebrate that aspect of Ruby and Rails and why it remains such a productive way to build software.

+ +

CHRIS OLIVER: I think related to that, one of the things that we should talk about more is the draw of Rails was look at what you can do with one person or two people. And I feel like we went down the JavaScript route, and now you need two teams of people, and you end up building bigger stuff. And Hotwire has kind of been like, hey, here's a reminder of what you can do with a very small team. And I think that resonates a lot with a lot of people building startups and trying to build side projects and everything. And that's one that is Rails-related. But there's a ton of people building Hotwire stuff in Laravel too. And they're all very similar. So I think at a certain point, yeah, we're talking about maybe Rails specifically, but you can apply all those things to different frameworks and just different tools.

+ +

STEPH: I'd like to add on and extend that because I wholeheartedly agree with what both Chris Toomey and Chris Oliver just said. And in addition, a lot of the conversations that we have on The Bike Shed are focused on Ruby and Rails, but then we will extract that particular concept to the point that it really doesn't matter which language that you're using or which framework that you're using. We're talking more about the high level. What's your process? What are you thinking as you're going through and implementing this? And based on more of our recent conversations, you'd think we're more of a Postgres podcast, how much we hype up Postgres, and the things that we can do at the database layer. So I think there are a lot of ways that we can start with a foundation of this is how we're doing it with Ruby and Rails, but then talk about it at a higher level where then it's really applicable for everybody.

+ +

JASON CHARNES: If talking about one technology defined your podcast, we might as well be a Laravel podcast because we talk about that framework more than we do Rails sometimes. [chuckles]

+ +

BRITTANY: So that begs the question: is there room for more Ruby and Rails podcasts outside of who's currently on this call?

+ +

JASON SWETT: I think so. And I mentioned that Peter Cooper was on our podcast a little bit ago. That's something he and I actually talked about in that episode. And I shared the anecdote about how in the new America's founding, Ben Franklin's brother or something like that wanted to start a newspaper. And somebody told him what a dumb idea that was because America already had a newspaper. And people might say, oh, there are already however many Rails podcasts. There are a small handful. But I think there could be ten more Rails podcasts or even more than that potentially because I think people have an appetite for help, and camaraderie, and stuff like that. And I don't think we've nearly bottomed out in terms of satisfying people's appetite for that stuff.

+ +

JASON CHARNES: Yeah, I agree with that because a lot of times, when I listen to podcasts, the more you get to know someone, that connection becomes what it's about for me. So, yeah, there's plenty of room. I mean, brand it as Ruby and tell me about your life as a developer I'll listen.

+ +

CHRIS TOOMEY: I'll also throw it out there that the way you framed the question is like, is there room for it? But one of the wonderful things about podcasting as a medium is it is distributed. It's not centralized. You can start up a podcast any day. And I will say, as someone who inherited a popular podcast or a sufficiently popular podcast and just got to run with that, it has been such a wonderful way to get my voice out there and provide opportunities that I want that for everyone. I want everyone to have this ability to speak about the way they think about software and then find like-minded people and be able to build even many communities within the larger community of Ruby on Rails. So beyond the question of, Is there room?” which I definitely think there is, I so wholeheartedly support anyone pursuing this for their own reason.

+ +

ANDREW: Yeah, I think to bring it all the way back, one thing that Chris, Jason, and I care a lot about is Ruby as a community. The community aspects of Ruby are very important to us. And we're actively trying to build that up and bring in new people and bringing people onto their first podcast. We say it all the time, like, hey, if you want to come on the show, let us know. We've had a few people even, you know, recognition in jobs from that. So to us, that is the payoff of doing the show. Maybe our show is the first time someone learns about Rails. And that to me is the possibility in the future. It's like, how can we market our shows that markets Ruby as well so that this meme of Ruby being dead finally goes away because it's not. I think it's growing. And I think the more and more we push as people who are public figures in this space that we want to bring more people on, that this is a space for everyone, I think that's just kind of the ethos that all of us have, and I think that's great.

+ +

BRITTANY: So I'm curious, on a lighter note, has anyone had the funny experience of realizing that you're not just podcasting into the ether and that what you're saying and what you're doing matters? For me, I have definitely been at conferences where people will run up and hug me just because they heard my voice, and they are like, "I didn't know what you looked like, but I have your voice memorized," and it just blew my mind. And I was like, "Thank you so much for being such a loyal listener." And it just proves that people are out there listening.

+ +

ANDREW: I tend to talk very openly about mental health. And I very often fail in public and talk about it. And I've had a lot of people message me and email me over the past three or four years and be like, "Hey, thank you for talking about this thing that's not actually about Ruby. It's not actually about coding, but it's just about being a developer." And those are the emails that make me feel the best. Like, someone who's out there like, "Yeah, I also feel like this. Thank you for speaking about it."

+ +

JASON SWETT: I had a surreal experience. I went to India in 2019 through RubyConf India. And this guy wanted to take a selfie with me because apparently, he considered me famous. So that was cool and pretty surprising because I definitely didn't consider myself famous.

+ +

STEPH: My favorite has been when we receive listener questions because it lets us know that people are listening and engaged in the conversation, and I essentially feel like they're part of the conversation. They will write in to us and share anecdotes, or they'll share answers to some of the questions that Chris and I will pose on the show. But every now and then, we will also get an email from someone that says, "Hey, just thanks for doing the show. I listen, and it's great," and that's all they share. And that, to me, is just the most wonderful thing that I could receive.

+ +

BRITTANY: Some of my favorite episodes from all of your shows is when we get an inside peek into what people are doing, like Andrew moving. Jason Charnes, you putting together a conference was actually some of my favorite episodes of yours, which was really early on, which proves that I'm a Remote Ruby OG. But I loved hearing the inside track as to what organizing a conference is because I think we need to get more content out there about how difficult but how rewarding it is.

+ +

JASON CHARNES: Yeah, I hadn't really thought about...that was around those times we hadn't done... It feels like it's been ages since we did Southeast Ruby, but Chris and I actually podcasted from the last Southeast Ruby we did. We just met in a room and recorded. But when I started that conference, I didn't have a lot to go on. So I'm more than glad to share because the reason I started is there were no Ruby conferences around me, plus I'm an open book. So for better or for worse, maybe that's good podcast material.

+ +

JASON SWETT: Side note, it's one of the most enjoyable conferences I've ever been to.

+ +

JASON CHARNES: Thank you.

+ +

BRITTANY: I completely agree. I miss the regional conferences.

+ +

JASON CHARNES: We lucked out because we were already planning on skipping 2020 because we were tired, and then COVID hit. I just sat on the couch one night and looked at Shannon (she helps me put on the conference), and I was like, "Wow, that would have been terrible. That would have come out of our own bank account, all that loss if we would have already booked somewhere." So phew, when it chills out, we'll try it again.

+ +

BRITTANY: So let's talk about legacies. I know that some of us have taken over from popular podcasts. Some of us have grown podcasts from the very beginning. So I'm curious, do you ever put any thought into the legacy of your podcast, whether or not you're going to stay with it to the end? Would you eventually pass it off? Do you think about whether or not it's your responsibility to the community to make sure that it keeps going?

+ +

JASON SWETT: I, for one, plan to have my consciousness uploaded to a supercomputer upon my death so that the Rails with Jason Podcast can continue on indefinitely.

+ +

JASON CHARNES: Did you recently watch Upload the TV show?

+ +

JASON SWETT: No, I've never heard of it.

+ +

JASON CHARNES: Oh, man. That's a whole nother conversation.

+ +

BRITTANY: Consider that homework, Jason.

+ +

JASON CHARNES: It's an interesting question because we started ours out of nothing. I wonder, is one of us going to get tired and just quit? I'd like to think that if one of us did, it would keep going because there are plenty of cool people who could hang out and talk Ruby on it. But it's interesting, something that's casually crossed my mind, but I think we're good. I think we're still doing it unless Chris and Andrew have a surprise for me today.

+ +

ANDREW: Surprise! [chuckles] I've thought about it a few times, specifically because I'm the youngest member of Remote Ruby. What if Jason and Chris just left, and they were like, "Oh, it's all yours now." Could I keep running it by myself? I think honestly, the answer is I would probably still do it just to have an excuse to talk to someone. I enjoy it. It's almost like a hobby at this point. I don't feel any obligation to create it. To me, it's really like an excuse to hang out with two friends, and other good stuff comes from that. But at the end of the day, I cherish that time just us hanging out a lot.

+ +

CHRIS OLIVER: Yeah. I think that's why we sometimes joke about it being a weekly therapy session where we are just hanging out and chatting about stuff. It's nice to be able to talk about programming things at a high level with people you don't work with that have totally different perspectives and stuff. So yeah, if Jason and Andrew dropped off, I would still try to have conversations with random people I know and keep it going just because it's enjoyable. I would hope that we would be able to keep it going and have other people on there.

+ +

BRITTANY: I'd love to hear from someone from The Bike Shed.

+ +

STEPH: I have thought about it. I've thought about it partially from the perspective that Chris Toomey brought up earlier in regards to being on a podcast is an incredible platform. You get to share your opinions, and people listen to you. And they know you, and it's really wonderful marketing. So I have thought about it from the perspective of I want other people to have access to this really wonderful podcast that we put on each week. So part of me is very aware of that and thinking about how more people can have similar exposures.

+ +

So a sort of a similar event occurred when Chris was moving on from thoughtbot and pursuing other interests. And at that moment, I just thought, oh my goodness, Chris brought me on as co-host, and now I'm here alone, and I don't know what I'm going to do. And I just panicked. I truly don't think I even considered other options. I was like, well, okay, it's over now. This was fun. And then it turned out where Chris was going to stay with the show. So things have just gone on swimmingly, and it's been wonderful.

+ +

But similar to what someone was saying earlier around when you start listening to a podcast, and you really develop that relationship and you go back to that podcast because you really enjoy hearing from those people and their adventures, it's very similar for me where The Bike Shed is very much the conversations and chats with Chris. So I think if we were to move on, it would be whenever Chris and I decided to move on and give the reins over to somebody else. I don't know if Chris fully agrees, so this will be interesting to find out. [chuckles]

+ +

CHRIS TOOMEY: I agree with that. Honestly, I'm honored to have continued on in the podcast after having moved on from thoughtbot because, in a very real way, the show is thoughtbot's channel to talk about things. I was at thoughtbot for seven years. I think I live and breathe that truth. And to me, that's what maybe has made sense for me to continue on. But I really do feel a responsibility to keep the show in good shape so that someday someone else gets to inherit this thing because I was so happy to get handed it. It was such a wonderful thing. And it has been such a joy to do for these past three years.

+ +

But at some point, I do presume that we will move on. And at that point, I do hope that other people pick up the mantle. And thankfully, thoughtbot as an organization, there is a group of individuals that I'm sure there will be someone wonderful that gets to step in, but I'm in no hurry to do that. And, Steph, I hope you're not either. So we'll continue the conversations for now, but I definitely do want to keep this thing alive if for no other reason than I got handed it. I don't feel like I could let it drop on the floor. That doesn't feel right.

+ +

BRITTANY: Well, I think on that warm, fuzzy feeling, we should wrap up. So let's go through everybody and just tell the listeners where they can listen to your podcasts and follow you. I am Brittany Martin, @BrittJMartin on Twitter. And you can listen to the Ruby on Rails Podcast at therubyonrailspodcast.com.

+ +

JASON CHARNES: So I'm Jason. We are Remote Ruby. I am @jmcharnes on Twitter. And I'll let the others tell you where you can find them.

+ +

ANDREW: You can find me everywhere @andrewmcodes. And if you email me, there's a really good chance you're never going to see a response because my email is a disaster. Please don't email me, but you can contact me anywhere else.

+ +

CHRIS OLIVER: I'm Chris Oliver, and you can find me on Twitter @excid3 or at Go Rails, and of course, gorails.com. And you can find the Remote Ruby podcast at remoteruby.com.

+ +

CHRIS TOOMEY: I am @christoomey on Twitter. The Bike Shed is @bikeshed on Twitter. We are at bikeshed.fm for a URL. I'm pretty sure www works, but I'm going to go check that real quick after because I want to make sure that's true. And yeah, that's me. And I'll send it over to Steph for her part.

+ +

STEPH: I am on Twitter @SViccari, and I post programming stuff, usually pictures of cute goats, cute dogs, that kind of content if you're into that.

+ +

JASON SWETT: For me, if you want to find my podcast, it's Rails with Jason. And if you search for Rails with Jason anywhere, you should be able to find it. And then my website, if you're interested in my blog and all that stuff, is codewithjason.com.

+ +

BRITTANY: Fantastic. Thank you, everyone, for being on this mega episode today. It was a lot of fun. We are going to be having a podcast panel at RubyConf; we’re excited to announce and some of us will be present. So stay tuned for details around that. And if you enjoyed this mega episode and want to see more mega episodes, please let us know on Twitter.

+ +

All: Bye.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + This is the sweeps week episode, the epic crossover episode, the mega episode! We have a very special episode as Chris, and Steph teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode!

+ +

In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. They cover the origins of their shows, their experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving.

+ + + +

*Transcript: *

+ +

STEPH: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. This week we have a very special episode as Chris, and I teamed up with the hosts of three other podcasts to bring you one giant, mega Ruby episode! In this episode, you'll hear from the hosts of Remote Ruby, Rails with Jason, and Brittany Martin, the host of the Ruby on Rails podcast. This episode was so much fun to record, and we have Brittany Martin to thank as she organized and moderated this special event. So without further ado, here is the mega Ruby episode.

+ +

BRITTANY: Welcome, everyone. We have a whopping seven podcast hosts recording today. So, listeners, you are in for a treat. This is the sweeps week episode, the epic crossover episode, the mega episode. We're going to need our editor to insert some epic sound effects right here.

+ +

Announcer: The mega episode.

+ +

BRITTANY: So let's go ahead and introduce the crew today. I am Brittany Martin from the Ruby on Rails Podcast.

+ +

CHRIS OLIVER: I'm Chris Oliver from Remote Ruby.

+ +

JASON CHARNES: I am Jason Charnes, also from Remote Ruby.

+ +

ANDREW: I am Andrew Mason, also from Remote Ruby.

+ +

STEPH: And I'm Stephanie Viccari from The Bike Shed.

+ +

CHRIS TOOMEY: I'm Chris Toomey from The Bike Shed.

+ +

JASON SWETT: And I'm Jason Swett from Rails with Jason

+ +

BRITTANY: Today, we're going to cover the origins of our shows, our experiences as hosts, and why podcasting is so important in keeping the Ruby community thriving. Now I know personally, I really enjoy the origin story behind Remote Ruby. So, Chris Oliver, could you kick us off with that?

+ +

CHRIS OLIVER: Yeah, we can go back maybe to the first time that Jason and I met, which was Jason emailed me out of the blue and was like, "Hey, are you going to be at RailsConf?" And I wasn't planning on it, but it was over in Kansas City, like four hours away from me. I was like, "No, I'm not going, but I'll meet you." So we went and drove over there and met and have been friends ever since. And Jason had the idea of doing an online meetup. And I'll let him explain where that started and turned into the Remote Ruby Podcast.

+ +

JASON CHARNES: I thought it would be a good idea. There weren't any online meetups. This was pre even the idea of shutting down the world for a pandemic. And maybe I was just too soon because I got Chris to speak at the first one, and we had 40, 50 people. I spoke at the next one, and there were 20. And by the third one, there were five of us. So it wasn't really a super sustainable thing for me to do. So Chris and I got together and said, "What if we tried podcasting?" Chris, you hadn't really done your own podcast at that point, had you?

+ +

CHRIS OLIVER: No, I don't think so. And you and I were just having calls every week or whatever just to hang out and chat. And we were like, why don't we just record that and publish that as a podcast? And here we are.

+ +

JASON CHARNES: Yeah. So we've been doing that. I think we started in 2018, so yeah, three years in June, and somehow people still keep listening to us talk but probably because we brought along our friend, Andrew.

+ +

ANDREW: Wow. Okay. No, that's not true. But yes, I was a guest on Remote Ruby before I joined as a host. And not to get into the details, but I was on another podcast, and something went down, and I no longer was on that podcast anymore. And Chris and Jason were like, "Do you want to come hang out with us?" And I was like, [chuckles] "Absolutely." So I started doing that, and at the same time, I also started The Ruby Blend with Nate Hopkins and Ron Cooke. And so we were doing that for a while until that had to tragically shut down. But I'm still here with Jason and Chris. I guess I should also mention that Jason Swett gave me my start in podcasting a month or two after I started full-time as a Rails developer on a now archived show called The Ruby Testing Podcast.

+ +

BRITTANY: Which is the perfect segue because Jason Swett was also my first opportunity to guest on a podcast. So I was already hosting, but I hadn't guested, which is kind of the opposite order. So, Jason, do you want to tell the origin of where Rails with Jason came from?

+ +

JASON SWETT: Sure. I'd been involved with podcasting since around 2016. I somehow ended up on the Ruby Rogues Podcast and was on there for maybe a year or so. And then, somehow, I got the idea that I could start my own podcast. And as an experiment, I started a podcast that I called The Ruby Testing Podcast, which I figured was sufficiently narrow that I could get some traction. And to my surprise, guests actually said yes to coming on the show. And also, to my surprise, people actually listened to the podcast. That gave me some confidence. So maybe a year later, I broadened, and I changed from The Ruby Testing Podcast to just Rails with Jason. And I have been doing that for something like two years.

+ +

BRITTANY: That's fantastic. I want to move to probably our most experienced podcast veteran, and that would be Chris Toomey. When I was learning how to code, I was listening to Giant Robots and then was excited for the transition that The Bike Shed took. Chris, I would love to hear the story of what it was like taking over a really popular podcast and really maintaining the drive behind it.

+ +

CHRIS TOOMEY: So, as you mentioned, I had done a little bit of podcasting. It was about a six-month run where I was a co-host on Giant Robots, which was the original podcast of thoughtbot. And that was more in the business and sort of how do we build a software company? So at that point, I was running Upcase, which was the subscription learning platform that thoughtbot had. So I was talking about the inner details of the business, and the marketing tests, and A/B tests and things like that that I was doing. And every week, I was sharing my MRR rather transparently in that thoughtbot way that we do. I did that for, like I said, about six months and then took a while off.

+ +

And in the background, thoughtbot had started up a new podcast called The Bike Shed, and that started October 31st of 2014. So The Bike Shed has been going for a long time now, and that was hosted by Derek Pryor and Sage Griffin. And they ran that for a number of years. I think it was about four years that the two of them worked collectively on that. But at some point, they both moved on from thoughtbot, and there was an opportunity for new hosts to step in. So I took over in August of 2018. So I've been doing this now for about three years.

+ +

And so, for that first year, I took the opportunity to do a tour around thoughtbot and talk with many different individuals from the company and a handful of people external to thoughtbot. But I knew that there were so many great voices and ideas and points of view within thoughtbot that I really wanted to spend some time getting to know more of them personally and then sharing that as much as I could with the existing audience that The Bike Shed had. But secretly, all along, I was looking for a person to hang out with all the more so, and Steph was the person that was a perfect choice for that. And so, for the past two years, Steph and I have been chatting. And I will send it over to Steph to share a little bit of her point of view on that transition. But from my point of view, it's been fantastic.

+ +

STEPH: I still remember exactly when we had the conversation. You were running The Bike Shed and doing an incredible job of just having weekly guests. And then you'd reached out to me and said, "Hey, would you be interested in doing an episode?" And I thought, "No, absolutely not. I can't podcast. I can't begin to do this." So you continued to convince me. And finally, you said something that resonated where you were like, "Well, we can just show up and record, and we don't have to publish. We can just see how it goes." I was like, that's a perfect safety net. I'm into that. So I showed up, and I think the first episode that you and I recorded ended up being titled What I Believe About Software. And it was a lot of fun. I realized I have a lot of things to say. And after that, I think it was another month or so. You continued interviewing more guests, but then you reached out to me and asked me if I wanted to be a co-host. And at that point, I was super jazzed about it, and it's been wonderful. It's been a roller coaster. I have learned a ton.

+ +

BRITTANY: I'm kind of seeing a pattern here where over the last three years, it seems like Remote Ruby came into place, Bike Shed transitioned. That's when I took over as host of the 5by5 Ruby on Rails Podcast. We're going to call it the golden era of the Ruby Podcasts. But for me, I probably have the longest-running podcast. It was started back in 2009 on the 5by5 Network, but it's gone through many different hosts. And so, I took over roughly about three and a half years ago as the main host from Kyle Daigle. And then, just a couple of weeks ago, as I announced on my podcast, we took the podcast independent. We are now just The Ruby on Rails Podcast. And I'm starting to change the model where I'm bringing in more co-hosts. So that way, I can get those regular updates that I really appreciate on all these podcasts we have featured on the show today.

+ +

I am curious. I want to talk about how we put together the episodes and plan out how everything's going to go down. I know for me, I'm currently a mix of interviews and co-host episodes. So I'd love to hear from Andrew. How do you plan out what Remote Ruby is going to be week to week?

+ +

ANDREW: This is an easy question because we don't at all. We don't plan. We do have some guests that come on, and sometimes, they may get their Zoom link the day of; who’s to say? But we really don't have a plan. We don't talk about what we're going to talk about beforehand. We all just kind of show up, and I think we have that kind of relationship and flow where it always just works.

+ +

JASON CHARNES: And I think part of that came from actually how Chris and I started the show because we were trying to make it as low stress as possible because we knew if we put a lot of pressure on it, we would stop doing it. Our first episodes were YouTube live links that we just shared out. And then in our next episodes, we were like, oh, we should start using some software to do this. And then eventually, we got an editor, but that same core of let's just keep it fun for better or for worse, I think, also affects our planning.

+ +

BRITTANY: I've been lucky in the sense that I have guests sit on all three of the episodes. And I do want to give a compliment to The Bike Shed because it is very well run and very well planned. So I want to kick it over to Steph as to how putting together a Bike Shed episode looks.

+ +

STEPH: Oh, thank you. That's wonderful to hear, by the way. That's wonderful feedback. So we predominantly use Trello to organize our thoughts. So we will have...and as we're capturing community questions that are coming in, so we will capture those on the board. And then, we will have a ticket that represents a particular episode. Usually, on the day of, we'll share some thoughts about, hey, these are the broad topics I'm interested in. And there's usually some hot takes in there, which is fun because the other person doesn't know exactly what's coming, and we can have real honest conversations on the mic. And then, every so often, we'll grab a beer, and we'll go through that list. And we'll chat through what sparks joy. What do we want to talk about? What would we like to respond to? And that's pretty much how we organize everything that we discuss. Chris, is there anything I've left out that you want to add?

+ +

CHRIS TOOMEY: I think that mostly covers it. We do occasionally have interviews just as a way to keep some variety and different things going on, but primarily it's the sort of what's new in your world? And I find that those episodes are the ones that I think are the most fun to record for Steph and I when it really feels like a sincere conversation. I've recently taken to a segment I call good idea, terrible idea where I'm like, "I'm actually considering this, Steph. What do you think?" And live on-air, I'm getting Steph's feedback, and generally, we're very aligned. But every once in a while, she's like, "That's a terrible idea. Don't do that." And I love those, and I love being able to share that because I think it's really easy to talk about, you know, here's a list of things that are true about software, but really, everything depends. And it's all the nuance. And so, being able to share some of our more pointed experiences and then share the conversation that we have over those is hopefully very valuable to the audience but definitely the thing that I enjoy the most.

+ +

BRITTANY: So kicking it over to Jason Swett, I really enjoy the interviews that you do. I'm curious, how do you select guests?

+ +

JASON SWETT: Well, thanks. Selecting guests is tough. I had Peter Cooper on the other day, and I was telling him that I feel like every guest that I get on the show is the last guest I'm ever going to be able to get on the show. But somehow, I keep finding more and more guests. Early on, it was relatively easy because I would just find book authors, or if somebody else does podcasting, then it's fairly obvious okay, you're the kind of person who does podcasts, so I'll invite you.

+ +

But it's a little bit tough because I don't want to invite people who aren't into podcasting and would be really thrown, although sometimes that happens. But let's see, sometimes I send an email out to my email list, and I'm like, "Hey, I'm looking for guests for my show." Sometimes I just tweet that I'm looking for guests. And sometimes I get some really interesting guests from surprising places. But at least in the start, it was looking for those authors and podcasters and the people who are known in the Ruby community.

+ +

BRITTANY: I know for me, I strive to have at least 50% of my interviews be with people who've never been on a podcast before. And so that usually involves the top of the episode they're dry heaving into a paper bag. And I'm explaining to them, don't worry, about halfway through the episode, you're not going to remember that you're recording anymore. It'll be fine. And you know what? It's always fine. And so, I do love hearing from a wide variety from the Ruby community just because it really proves just how big it is. So I'm curious, could you host the podcast that you are currently hosting now if you weren't actively working in Ruby?

+ +

ANDREW: I could because Chris is the one that has all the clout. I could sit back and make dumb jokes and memes during it. And as long as Chris is there, I think we'll be good.

+ +

JASON SWETT: Yeah, I think I could because a good majority of what we talk about on Rails with Jason actually has nothing to do with Rails, so that would probably actually work out.

+ +

STEPH: I think yes is the answer. While a lot of our conversations do focus around Ruby and Rails, we often use a lot of other languages and tools, and those are a lot of fun to talk about. So I think I would just talk about whatever new tool or language that I'm using. So I think yes, it would just take a slightly different form but would still be at its core the same where we're still talking about our daily experiments and adventures in web development.

+ +

BRITTANY: I agree with you, Steph. I will say that it seems like Chris Oliver and Chris Toomey have an endless well of things to talk about just based on what they do day-to-day.

+ +

CHRIS TOOMEY: I try and go on adventures and then share as much as I can. But to resonate with what Steph was saying there, we try to make the show more generally about software, and it happens to be that it's grounded in Ruby on Rails because the vast majority of the work that we do is in that. And I just recently started a new project. I was given the choice of I could pick any technology I want, and it remains the technology that makes sense to me to be the foundation of an application that I want to maintain for years and years and years. So, on the one hand, I think I could definitely talk about software more generally. I think I'm doing that most of the time. But at the other end of the spectrum, but it's always going to be based on Ruby because I haven't found a thing elsewhere in the world that is better than that.

+ +

CHRIS OLIVER: I completely agree with that. I probably have a little bit of a unique thing doing a screencast every week. A lot of those are based on I'm building some project, and I need to build some random feature like Stripe Checkout. And that's a good one to do a screencast on and implement in the project. And then, we can also talk about the decisions along the way on the podcast, which is kind of nice.

+ +

BRITTANY: Yeah, it feels like every week, Chris Oliver is like, yeah, I've created a new open-source library, and I'm fabulous. [laughs] Let me listen to this.

+ +

CHRIS OLIVER: Too many of them. I'm currently rewriting a lot of the Pay gem. And it's just one of those things where you make a bunch of decisions. And then, if you make an open-source project, people use it in all these different ways that you didn't intend yourself, and so you want to support that. But then you need to rearchitect things in it. It is a lot of learning as you go, which is always a lot of fun. So those I think are really good topics to talk about when you're building something like that.

+ +

I'm always amazed by how does the Rails core team make these decisions on what should be in the framework and what shouldn't? And what do they want to maintain, and how do they keep it flexible but yet have some sort of rule with how they allow things to be implemented and whatever? It is a very hard job to have. So I get my little taste of that with some open source but not on their level.

+ +

BRITTANY: I always thought that you had a good contrast to Jason Charnes because Jason works at Podia. And while you do get to work on a lot of really cool technologies, I feel like the stakes are much higher. So you can't just rip out StimulusReflex and put in something else just because it sounds cool that week. And I love how you talk through the pluses and minuses to making a big change within the Podia codebase.

+ +

JASON CHARNES: Yeah. I haven't really thought about that contrast before, but it's helpful for me even just to talk it out with two other people once a week, and luckily, pretty cool about me just coming on and talking about hey, these are the steps we took to get here. Yeah, it's a cool dynamic.

+ +

BRITTANY: Steph, have you ever had a client from thoughtbot say, "Hey, were you talking about me?" whenever you're talking about your current client?

+ +

STEPH: That is one of my fears at times that it will happen [chuckles] although we stay very positive on the show. That's something that's very important to us. There's enough negativity in the world. So we really want to focus on our positive experiences through the week. But there have been times where I'm speaking about some of the challenges or things that we are running into that yes, the engineering team is listening to the podcast, and they're like, "Oh, I heard you talk about this feature that we're working on or this particular challenge." And that's really cool because they get that behind-the-scenes peek to see how Chris and I are chatting about that. But yet they know enough, and they know which project that I'm on that they recognize exactly the technology and the feature that I'm trying to describe. So that has certainly happened, and it can be a lot of fun when it does.

+ +

BRITTANY: Andrew, how have things changed for you now that you're not working at CodeFund, which was very much like an open-source thing? People could see what you were actively working on. And now you're working for a company where it's closed source. And so, you might not be able to reveal as much as what you're working on at any given point.

+ +

ANDREW: It's different, but I don't think it's been an issue per se. I'm not like, oh crap, I let that slip, and I didn't mean to. That's not really an issue. I really cherish the time I had at CodeFund. When I think back on my experiences, that was my favorite time just because I was able to do that thing that a lot of people really want to do. I was working as an open-source developer. We were spiking StimulusReflex; that’s when we were building up StimulusReflex and trying to build up the community. I joined Ruby. We started the Ruby Blend, and things were going good before a dramatic turn. But in terms of the closed and open source, it hasn't been that big of a shift just because instead of talking about what I'm doing at work, like, I still talk about it, but I speak about it in more general terms. But I also then kind of freed up to talk a lot more about the dumb crap I do on the nights and weekends.

+ +

BRITTANY: So the majority of our podcasts either have the word Ruby or Rails in it, but I think we've all agreed that a lot of the topics that we're talking about are not specific to that community. But in a lot of ways, I feel that having podcasts in our community is how we're going to keep our community thriving. So I'm curious if anyone has any thoughts around...is there a way to market our podcasts so that other developers will listen to it? I get really excited when I get listener feedback saying, "Hey, I used to do Rails maybe ten years ago, but I've been listening to your podcast, and I really enjoy such and such episode." How can we make our podcasts accessible to the general software community as opposed to just Ruby?

+ +

CHRIS TOOMEY: One thing that stands out to me about Ruby and Rails is because it's full-stack, because of its foundations, it tends to be holistically about web development. And so, whereas I look at React projects or other JavaScript or different things that are going on, I see a more narrow focus in those frameworks. And with Ruby and Rails, what I love about it is that it's really about building software. It's about building products that are valuable, that deliver value to end-users. And so that being the core of it, that's the story that constantly brings me back to Ruby and Rails. And it's the story that I want to keep telling as much as possible. And it's the thing that keeps me engaged with this community. And so, I think podcasts are a great way to continue to literally tell those sorts of stories and really celebrate that aspect of Ruby and Rails and why it remains such a productive way to build software.

+ +

CHRIS OLIVER: I think related to that, one of the things that we should talk about more is the draw of Rails was look at what you can do with one person or two people. And I feel like we went down the JavaScript route, and now you need two teams of people, and you end up building bigger stuff. And Hotwire has kind of been like, hey, here's a reminder of what you can do with a very small team. And I think that resonates a lot with a lot of people building startups and trying to build side projects and everything. And that's one that is Rails-related. But there's a ton of people building Hotwire stuff in Laravel too. And they're all very similar. So I think at a certain point, yeah, we're talking about maybe Rails specifically, but you can apply all those things to different frameworks and just different tools.

+ +

STEPH: I'd like to add on and extend that because I wholeheartedly agree with what both Chris Toomey and Chris Oliver just said. And in addition, a lot of the conversations that we have on The Bike Shed are focused on Ruby and Rails, but then we will extract that particular concept to the point that it really doesn't matter which language that you're using or which framework that you're using. We're talking more about the high level. What's your process? What are you thinking as you're going through and implementing this? And based on more of our recent conversations, you'd think we're more of a Postgres podcast, how much we hype up Postgres, and the things that we can do at the database layer. So I think there are a lot of ways that we can start with a foundation of this is how we're doing it with Ruby and Rails, but then talk about it at a higher level where then it's really applicable for everybody.

+ +

JASON CHARNES: If talking about one technology defined your podcast, we might as well be a Laravel podcast because we talk about that framework more than we do Rails sometimes. [chuckles]

+ +

BRITTANY: So that begs the question: is there room for more Ruby and Rails podcasts outside of who's currently on this call?

+ +

JASON SWETT: I think so. And I mentioned that Peter Cooper was on our podcast a little bit ago. That's something he and I actually talked about in that episode. And I shared the anecdote about how in the new America's founding, Ben Franklin's brother or something like that wanted to start a newspaper. And somebody told him what a dumb idea that was because America already had a newspaper. And people might say, oh, there are already however many Rails podcasts. There are a small handful. But I think there could be ten more Rails podcasts or even more than that potentially because I think people have an appetite for help, and camaraderie, and stuff like that. And I don't think we've nearly bottomed out in terms of satisfying people's appetite for that stuff.

+ +

JASON CHARNES: Yeah, I agree with that because a lot of times, when I listen to podcasts, the more you get to know someone, that connection becomes what it's about for me. So, yeah, there's plenty of room. I mean, brand it as Ruby and tell me about your life as a developer I'll listen.

+ +

CHRIS TOOMEY: I'll also throw it out there that the way you framed the question is like, is there room for it? But one of the wonderful things about podcasting as a medium is it is distributed. It's not centralized. You can start up a podcast any day. And I will say, as someone who inherited a popular podcast or a sufficiently popular podcast and just got to run with that, it has been such a wonderful way to get my voice out there and provide opportunities that I want that for everyone. I want everyone to have this ability to speak about the way they think about software and then find like-minded people and be able to build even many communities within the larger community of Ruby on Rails. So beyond the question of, Is there room?” which I definitely think there is, I so wholeheartedly support anyone pursuing this for their own reason.

+ +

ANDREW: Yeah, I think to bring it all the way back, one thing that Chris, Jason, and I care a lot about is Ruby as a community. The community aspects of Ruby are very important to us. And we're actively trying to build that up and bring in new people and bringing people onto their first podcast. We say it all the time, like, hey, if you want to come on the show, let us know. We've had a few people even, you know, recognition in jobs from that. So to us, that is the payoff of doing the show. Maybe our show is the first time someone learns about Rails. And that to me is the possibility in the future. It's like, how can we market our shows that markets Ruby as well so that this meme of Ruby being dead finally goes away because it's not. I think it's growing. And I think the more and more we push as people who are public figures in this space that we want to bring more people on, that this is a space for everyone, I think that's just kind of the ethos that all of us have, and I think that's great.

+ +

BRITTANY: So I'm curious, on a lighter note, has anyone had the funny experience of realizing that you're not just podcasting into the ether and that what you're saying and what you're doing matters? For me, I have definitely been at conferences where people will run up and hug me just because they heard my voice, and they are like, "I didn't know what you looked like, but I have your voice memorized," and it just blew my mind. And I was like, "Thank you so much for being such a loyal listener." And it just proves that people are out there listening.

+ +

ANDREW: I tend to talk very openly about mental health. And I very often fail in public and talk about it. And I've had a lot of people message me and email me over the past three or four years and be like, "Hey, thank you for talking about this thing that's not actually about Ruby. It's not actually about coding, but it's just about being a developer." And those are the emails that make me feel the best. Like, someone who's out there like, "Yeah, I also feel like this. Thank you for speaking about it."

+ +

JASON SWETT: I had a surreal experience. I went to India in 2019 through RubyConf India. And this guy wanted to take a selfie with me because apparently, he considered me famous. So that was cool and pretty surprising because I definitely didn't consider myself famous.

+ +

STEPH: My favorite has been when we receive listener questions because it lets us know that people are listening and engaged in the conversation, and I essentially feel like they're part of the conversation. They will write in to us and share anecdotes, or they'll share answers to some of the questions that Chris and I will pose on the show. But every now and then, we will also get an email from someone that says, "Hey, just thanks for doing the show. I listen, and it's great," and that's all they share. And that, to me, is just the most wonderful thing that I could receive.

+ +

BRITTANY: Some of my favorite episodes from all of your shows is when we get an inside peek into what people are doing, like Andrew moving. Jason Charnes, you putting together a conference was actually some of my favorite episodes of yours, which was really early on, which proves that I'm a Remote Ruby OG. But I loved hearing the inside track as to what organizing a conference is because I think we need to get more content out there about how difficult but how rewarding it is.

+ +

JASON CHARNES: Yeah, I hadn't really thought about...that was around those times we hadn't done... It feels like it's been ages since we did Southeast Ruby, but Chris and I actually podcasted from the last Southeast Ruby we did. We just met in a room and recorded. But when I started that conference, I didn't have a lot to go on. So I'm more than glad to share because the reason I started is there were no Ruby conferences around me, plus I'm an open book. So for better or for worse, maybe that's good podcast material.

+ +

JASON SWETT: Side note, it's one of the most enjoyable conferences I've ever been to.

+ +

JASON CHARNES: Thank you.

+ +

BRITTANY: I completely agree. I miss the regional conferences.

+ +

JASON CHARNES: We lucked out because we were already planning on skipping 2020 because we were tired, and then COVID hit. I just sat on the couch one night and looked at Shannon (she helps me put on the conference), and I was like, "Wow, that would have been terrible. That would have come out of our own bank account, all that loss if we would have already booked somewhere." So phew, when it chills out, we'll try it again.

+ +

BRITTANY: So let's talk about legacies. I know that some of us have taken over from popular podcasts. Some of us have grown podcasts from the very beginning. So I'm curious, do you ever put any thought into the legacy of your podcast, whether or not you're going to stay with it to the end? Would you eventually pass it off? Do you think about whether or not it's your responsibility to the community to make sure that it keeps going?

+ +

JASON SWETT: I, for one, plan to have my consciousness uploaded to a supercomputer upon my death so that the Rails with Jason Podcast can continue on indefinitely.

+ +

JASON CHARNES: Did you recently watch Upload the TV show?

+ +

JASON SWETT: No, I've never heard of it.

+ +

JASON CHARNES: Oh, man. That's a whole nother conversation.

+ +

BRITTANY: Consider that homework, Jason.

+ +

JASON CHARNES: It's an interesting question because we started ours out of nothing. I wonder, is one of us going to get tired and just quit? I'd like to think that if one of us did, it would keep going because there are plenty of cool people who could hang out and talk Ruby on it. But it's interesting, something that's casually crossed my mind, but I think we're good. I think we're still doing it unless Chris and Andrew have a surprise for me today.

+ +

ANDREW: Surprise! [chuckles] I've thought about it a few times, specifically because I'm the youngest member of Remote Ruby. What if Jason and Chris just left, and they were like, "Oh, it's all yours now." Could I keep running it by myself? I think honestly, the answer is I would probably still do it just to have an excuse to talk to someone. I enjoy it. It's almost like a hobby at this point. I don't feel any obligation to create it. To me, it's really like an excuse to hang out with two friends, and other good stuff comes from that. But at the end of the day, I cherish that time just us hanging out a lot.

+ +

CHRIS OLIVER: Yeah. I think that's why we sometimes joke about it being a weekly therapy session where we are just hanging out and chatting about stuff. It's nice to be able to talk about programming things at a high level with people you don't work with that have totally different perspectives and stuff. So yeah, if Jason and Andrew dropped off, I would still try to have conversations with random people I know and keep it going just because it's enjoyable. I would hope that we would be able to keep it going and have other people on there.

+ +

BRITTANY: I'd love to hear from someone from The Bike Shed.

+ +

STEPH: I have thought about it. I've thought about it partially from the perspective that Chris Toomey brought up earlier in regards to being on a podcast is an incredible platform. You get to share your opinions, and people listen to you. And they know you, and it's really wonderful marketing. So I have thought about it from the perspective of I want other people to have access to this really wonderful podcast that we put on each week. So part of me is very aware of that and thinking about how more people can have similar exposures.

+ +

So a sort of a similar event occurred when Chris was moving on from thoughtbot and pursuing other interests. And at that moment, I just thought, oh my goodness, Chris brought me on as co-host, and now I'm here alone, and I don't know what I'm going to do. And I just panicked. I truly don't think I even considered other options. I was like, well, okay, it's over now. This was fun. And then it turned out where Chris was going to stay with the show. So things have just gone on swimmingly, and it's been wonderful.

+ +

But similar to what someone was saying earlier around when you start listening to a podcast, and you really develop that relationship and you go back to that podcast because you really enjoy hearing from those people and their adventures, it's very similar for me where The Bike Shed is very much the conversations and chats with Chris. So I think if we were to move on, it would be whenever Chris and I decided to move on and give the reins over to somebody else. I don't know if Chris fully agrees, so this will be interesting to find out. [chuckles]

+ +

CHRIS TOOMEY: I agree with that. Honestly, I'm honored to have continued on in the podcast after having moved on from thoughtbot because, in a very real way, the show is thoughtbot's channel to talk about things. I was at thoughtbot for seven years. I think I live and breathe that truth. And to me, that's what maybe has made sense for me to continue on. But I really do feel a responsibility to keep the show in good shape so that someday someone else gets to inherit this thing because I was so happy to get handed it. It was such a wonderful thing. And it has been such a joy to do for these past three years.

+ +

But at some point, I do presume that we will move on. And at that point, I do hope that other people pick up the mantle. And thankfully, thoughtbot as an organization, there is a group of individuals that I'm sure there will be someone wonderful that gets to step in, but I'm in no hurry to do that. And, Steph, I hope you're not either. So we'll continue the conversations for now, but I definitely do want to keep this thing alive if for no other reason than I got handed it. I don't feel like I could let it drop on the floor. That doesn't feel right.

+ +

BRITTANY: Well, I think on that warm, fuzzy feeling, we should wrap up. So let's go through everybody and just tell the listeners where they can listen to your podcasts and follow you. I am Brittany Martin, @BrittJMartin on Twitter. And you can listen to the Ruby on Rails Podcast at therubyonrailspodcast.com.

+ +

JASON CHARNES: So I'm Jason. We are Remote Ruby. I am @jmcharnes on Twitter. And I'll let the others tell you where you can find them.

+ +

ANDREW: You can find me everywhere @andrewmcodes. And if you email me, there's a really good chance you're never going to see a response because my email is a disaster. Please don't email me, but you can contact me anywhere else.

+ +

CHRIS OLIVER: I'm Chris Oliver, and you can find me on Twitter @excid3 or at Go Rails, and of course, gorails.com. And you can find the Remote Ruby podcast at remoteruby.com.

+ +

CHRIS TOOMEY: I am @christoomey on Twitter. The Bike Shed is @bikeshed on Twitter. We are at bikeshed.fm for a URL. I'm pretty sure www works, but I'm going to go check that real quick after because I want to make sure that's true. And yeah, that's me. And I'll send it over to Steph for her part.

+ +

STEPH: I am on Twitter @SViccari, and I post programming stuff, usually pictures of cute goats, cute dogs, that kind of content if you're into that.

+ +

JASON SWETT: For me, if you want to find my podcast, it's Rails with Jason. And if you search for Rails with Jason anywhere, you should be able to find it. And then my website, if you're interested in my blog and all that stuff, is codewithjason.com.

+ +

BRITTANY: Fantastic. Thank you, everyone, for being on this mega episode today. It was a lot of fun. We are going to be having a podcast panel at RubyConf; we’re excited to announce and some of us will be present. So stay tuned for details around that. And if you enjoyed this mega episode and want to see more mega episodes, please let us know on Twitter.

+ +

All: Bye.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3EexctEx + + ]]> + + Chris Toomey + Steph Viccari + + + 303: Dear Mr. Grumpy Goose + https://bikeshed.thoughtbot.com/303 + ce500190-21d6-4083-a6c8-4ab0618c207a + Tue, 03 Aug 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris gives a DB sessions update and talks bifunctors & command objects. Steph shares the coolness of a gem she's been using called after_party, and excitedly gushes about her new laptop. (Chris is hoping to hold off on replacing his until the end of the year and then they can compare!) + +The two then answer a listener question on retrospectives and how they've seen productive ones run, while giving some of their own helpful opinions on dos and don'ts. They're talking to you, Grumpy Goose! + 45:45 + no + + + Chris gives a DB sessions update and talks bifunctors & command objects. Steph shares the coolness of a gem she's been using called after_party, and excitedly gushes about her new laptop. (Chris is hoping to hold off on replacing his until the end of the year and then they can compare!) +The two then answer a listener question on retrospectives and how they've seen productive ones run, while giving some of their own helpful opinions on dos and don'ts. They're talking to you, Grumpy Goose! +dry-monads gem (https://github.com/dry-rb/dry-monads) +attr_extras gem (https://github.com/barsoom/attr_extras) +after_party gem (https://github.com/theSteveMitchell/after_party) +What Went Well? - Bike Shed 123 (https://www.bikeshed.fm/132) +What I Believe About Software - Bike Shed 172 (https://www.bikeshed.fm/172) +Is Agile Over? - Bike Shed 299 (https://www.bikeshed.fm/299) +Running a Retrospective - Upcase (https://thoughtbot.com/upcase/videos/running-a-retrospective) +Transcript: +STEPH: Cool. +[laughter] +CHRIS: Good. No, I like what you did there. +STEPH: Yeah, I feel like we can get rambling on that one. +CHRIS: It's been great. This is what the Bike Shed is at its best. It's the two of us just rambling and being like, well, what about this? And if it's this, then that, then these, and it depends. And it's complicated and it's nuanced. And what about the humans? That's the story of The Bike Shed right there. [laughs] +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm CHRIS Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week? +CHRIS: My week has been good. I have some updates actually on some topics from previous episodes. One of the things that I can update on is the discussion around the cookie versus the database store. So I had posed this as a thing that I was going to be doing in the app for a handful of reasons. Most notably, I wanted the ability to invalidate sessions from the server-side, wanted to have a little more control over that. And so that's a dream that the database-backed session store can do. Eventually, I have to make that actually work in the way that I want. +But I was asking the question in that episode, which we can include a link to the specific episode, but I was asking the question of why don't we just do this all the time? The database-backed sessions seem better in all these ways. It's a lower overhead per request because you're just sending the session ID and the cookie instead of the whole payload of the session. You actually can have more data stored in it, a bunch of things that seemed really great. And then right after I introduced it, I figured out the thing. I figured out the secret. It's not a big issue, and we're going to stick with database session stores. But we have to be purposeful because it turns out they are essentially plain text in the database. +And so if there's anything that you are putting into the session like say a social security number or an authentication token or other things which naturally I might have done if it was in a cookie that lives on the user's browser and never actually lives on the server, persists on the server, that seems fine to me. But now these things are getting stored in the database and that really changes the calculus, especially because if I'm not purposeful, they'll just stick around for forever. So social security is probably the most pointed example of this. If you happen to have a form in the app that accepts a social security number and you want that to persist through some number of other steps, not actually going to store the social security number in the database because that's a thing that I have actively chosen not to do. I need to send it off to some other system, but I do need to hold onto it for a few minutes. The session is a perfect place to put that unless the session gets stored in my database. +STEPH: That's such a great point. I'm so glad you discovered that. And in our recent conversation, we were trying to think of the reasons why this isn't the default case. You may be headed in this direction, but this may also be timely, the fact that you're discovering this issue but also the fact that Rail 6.0 now has encrypted columns. Is that where you're headed with the fact that you can still keep session data in a database? +CHRIS: That is a great question, and it is an intriguing option. But it's not the one that I'm going with here. I think broadly, my hope is to completely avoid ever persisting this data in the database, this truly sensitive user-specific PII or PCI or social security numbers or any of these other fancy acronyms that get collected together under the umbrella of I probably don't want that on my server. For those, I'm just opting to push them back into a cookie. So I'm using particularly a...In rails, it's fun because they have a fluent interface where you can just chain together things, so it's cookies.signed.encrypted.whatever, and then you go from there. But I'm using signed, encrypted cookie, which is essentially what the session store views; the cookie session store uses itself. +So I'm basically reverting to the old session store behavior for specific values. So anything that is truly sensitive like that, I'm just saying, cool, that's actually just going to live in a cookie, and that will be it, but not leaning on the ability to encrypt the database sessions. There's just enough subtlety around that. There's so much volume of data if I do allow that sensitive data into the system that any failure, any exploit that happens, would be somewhat catastrophic. So, in my mind, this lowers the surface area and says, yeah, this data really never lives on the server. It comes with a request, and then it's gone after the fact. And that's the world I want to live in. +STEPH: Yeah, that's super interesting. You're also raising questions for me that I hadn't considered when we originally had this conversation where there's necessity or that you're looking to store form data or sensitive data in that session as well. So that makes a lot of sense to me that for that type of behavior, we're going to separate that from the idea of authentication and the user session and still use encrypted cookies for those details. So it only stays with the user's browser, but then the actual authentication of a user that part could still live in the database. +CHRIS: It is ending up being a weird Venn diagram of; this is data that I want to stick around but only sometimes and particular to the machine that the user is interacting with because the session is still associated with a cookie at the end of the day. So a user may have multiple sessions in the database-backed session version. It is somewhat interesting, and I'm going to see how it develops over time. But yeah, at a minimum, I have now found this edge case of like, ooh, okay, sensitive data, that's a thing, which is one of the reasons that I would reach for the session inherently. So it turns out, as always, it depends. Things are complicated. +STEPH: It's a nice update. I like when we have closure to a question like that, especially so quickly. +CHRIS: Love to provide that continuity. It's what I'm all about. But yeah, what's up in your world? +STEPH: What's up in my world? I am excited that I have a new laptop. So I have been using a MacBook Pro for about the last...it's lasted me for a while. I think I've had it for a good four, four, and a half years, but that's on the fritz. The keyboard, in particular, the keys are popping off, and that's something that I could go get fixed. But I'm at the point that I need a new laptop. So I have a brand new shiny laptop. And I had the option to either go with a 16-inch MacBook Pro or to go with one of the new, fancy laptops that has the M1 chip. And I was torn for a little while because having the M1 chip sounds really cool and novel, and there's a lot of speed improvements that come with that. +But I ended up going with just the 16-inch MacBook Pro; specifically, one, it's still very fast. It's very reliable. I can use this as my work machine and just know everything's going to work. That part feels really important to me. And then also the screen size is important. So any Mac laptop that is using the new M1 chip, I think they only go up to a 13-inch, right now, screen size. And I really want the 16-inch in case I am traveling, so I have that larger desktop. But I did do some research into the M1 just because I know about it. I know it's out there. I know it's hot. People are interested in it, but I didn't know a whole lot about it. So for anyone else that's like me and is curious about what the heck this M1 chip is, it's essentially Apple's foray into making their own processors. +So traditionally, their machines have used Intel CPUs and third-party graphic processors, and other parts. And this introduction of the M1 chip really represents Apple's switch to having their own internal architecture rather than relying on those third-party parts. And it also means that all those features that were sourced from other parties like the CPU and its security are now being combined into a single chip, which has also led to some performance improvements. And while I was reading about the M1, there's a lot to go through, but the thing that stood out to me was this idea of Apple's Neural Engine. And I thought, well, that sounds super fancy. What is that? Are you familiar with Apple's Neural Engine? Have you read about that? +CHRIS: I don't think I am. What all is that? +STEPH: Yeah, good question. That was a question I was asking myself just recently. So essentially, their neural engine it's a microprocessor that specializes in the acceleration of machine learning algorithms. So it's really similar to how a GPU will focus on accelerating graphics rendering. And their neural engine or neural engines in general then focus on accelerating neural network operations. And the inclusion of a neural engine isn't something that's new because Apple introduced this into iPhones and iPads back in 2017 to support their features like Face ID and emoji, searching for photos with dog pictures. Siri speech recognition is also one that's using this engine and other machine learning tasks. +But the sparkly stat that Apple is sharing with this new design is it's a 16-core design that can perform 11 trillion operations per second, which sounds very fancy, very fast. But it really got me thinking about how companies are working to improve, not just laptops but also our mobile devices to run machine learning software more efficiently, and then how that's just going to evolve and change all the different features that we use, and then how developers can integrate with this engine. I think currently, Apple hasn't shared much information about how this engine works, but I think they've exposed a few developer tools so people can still build features that will then use the power of this faster, improved neural engine. +CHRIS: Oh, that's super interesting. I have still not really delved into machine learning or artificial intelligence, or any of that stuff in any real way. But it's one of those things like the number of mentions is ticking up. And at some point, I'm like; I probably have to pay attention to this, don't I? I'm still in the not paying attention to it camp. So if I'm understanding, though, you just described this wonderful feature, but you opted for the machine that does not have all the fancy stuff. You did not... +STEPH: Exactly. [laughs] +CHRIS: Okay, yeah. +STEPH: Yes, it would have been nice. That would have been neat, but yeah, I needed a machine with a larger screen, all those good things. And that's still really fast, for the record. +CHRIS: Oh yeah. I'm desperately hoping to make it to the end of this year. This is going to be a bit of a rumor mill here, but my understanding is the expectation is that Apple is going to release a 14-inch MacBook Pro with the M1 and the return of MagSafe, and the removal of the touch bar. And that sounds like my dream machine right there. I want that piece of hardware. +I also seem to care a little bit less about the size of the laptop screen. I'm so often working at my desk with a large-format monitor that I'm connected to. And so, when I'm on the road, I want to optimize for portability when I'm traveling because I do it so rarely, and then I'm hopefully focusing on travel at that point. But we'll see if that remains true as the shape of my work changes and I start to not only work from home. And maybe I'll actually change my tune on that. But for now, that's my hope is to make it to that machine and then get one, and that it exists because right now, those are all rumors. +STEPH: Well, I totally support this goal of yours. So that way, you can have that new-new, and then you can report back on what it's like, and then we can compare. Because I'll have the other version, the Intel CPU, and then you'll have the M1 chip, and we can see how our lives are different. +CHRIS: You'll have the new, and I'll have the new-new, and that's how we'll categorize them. +STEPH: [laughs] But yeah, I'm very much looking forward. Having a new laptop is always just such a fun feeling. It's just a clean space that I get to rebuild. It's like going through and prioritizing; what are the things that still spark joy? And then I get to only port over the stuff that I still really use all the time and want to keep. So I'm looking forward to getting it set up. +CHRIS: I need to do that sometime soon. I'm like five years deep, at least on this machine. So I've been dragging along. Also, the hard drive is just completely full, and I regularly have to go through and delete things before we start recording because it turns out these audio recordings start as very large files. [chuckle] So it's almost a weekly thing where I'm just like, got to throw something out today. I don't know what. It's fine. I'm going to be fine. [laughter] I'm going to make it to the end of the year, and it's going to be great. +STEPH: What else is going on in your world? +CHRIS: Well, I wrote some fancy code, and I use fancy not necessarily as a good word. [chuckle] So I'm intrigued that the code could be described perhaps as clever or other words like that, which I think are very complicated words in the coding space. I tend to try and avoid this type of coding where I'm trying to introduce abstractions and clean things up, and remove duplication because I've been burned by that so many times in the past. But this time, I think maybe this time it'll work. +So, in particular, there are two different areas of the application. There were two sets of refactorings, but they really went together. One is we have the idea of command objects within the application that we're working on. So there are a lot of cases where we need to save something to the database and then communicate something to an external API. And then presuming the results of that is a successful response from them, then unpack some data, make sure it's in the right shape, and then save something else to the database. And ideally, wrap that all in a transaction and keep everything together and then return some data at the end of it. +So that whole sequential operation, I've been using dry-monads to model that. I've talked about this on a few previous episodes. I'm really enjoying it. The more I lean into it, the more I find that it is just a really great way to wrap up that very procedural code. But ideally, do it in almost a functional way so that we've got these sequential operations that feed into each other. There's the railway-oriented programming stuff, which is associated with this idea. +But there is a lot of boilerplate to these objects. So the way we've defined them is they have a class method called run that takes whatever the arguments are, and then it needs to pass those arguments into the initialize and then call run on the instance. So in order to define one of these objects, what we had been doing was def self.run and then all the arguments. And then inside of the body of that, it's new, and then pass forward all the arguments .run, and then define initialize to capture all of those and set all the instance variables, and then define the run method, which actually does stuff. Also need to define an Adder reader for all of those instance variables, which is a thing that I enjoy doing. So that's the interface I want, or that's the way that I want this class to work. I know other folks in the Ruby world feel differently. But that's the shape of the thing that I want, but that's a lot. +And there's also I regularly would find myself forgetting to duplicate something that we put into the class method run interface into the initialize method. And it was just like, this is all just wiring up and plumbing. There's also the binding of the dry-monads do notation for the run method as well as the inclusion of the results type within dry-monads. Type is a strong word, but that gives us the success or the failure objects that we can create. So ideally, all of these command objects either return a success object or return a failure object. It's one of the two. And that's one of the things that I really like about them. But yeah, so much plumbing. +So we define a base command, and the base command has the self.run method, the class method, and that method is defined very abstractly. So it's just args * keyword args. So we're capturing all of the arguments and then forwarding them on to new. So that way, I don't have to think about that interface. It basically just says, "Give me anything, and I'll forward it onto new." And the new or initialize is in charge of actually defining things. It also includes the result type. It includes the macro annotation for the run method, which is how dry-monads does its magic, that actually I had to include inline within the self.run, just because of the sequence of definition and the metaprogramming that's going on there. As I said, that sentence terrifies me a little bit, but hopefully, no one ever needs to look at this magic base class [chuckles] and figure anything out. So that was one part of it. That cleaned a lot of things up, so that meant I didn't have to write a ton of the wiring up code. +Then there was still the noise of actually defining all of the arguments to these classes. They often take a handful of arguments because that's their job is to grab a bunch of things and do some work with those things. So for that, I have brought Adder Extras, which is a gem that I've talked about probably in previous episodes, I think so. But this is the first time that I've really leaned into it and used it. And it gives some very high level what look like macros are just class methods. But the one that I'm using is Adder private initialize, and that you can then pass a variety of values too. And it will then say, okay, this method accepts a required keyword arg, a defaulted keyword arg, and a positional argument or something to that effect. But it's a very, very concise way to express that and then also get the private Adder readers, which again is the direction that I want to go with all of this. +So that’s a bunch of things that I have said. But all total, it cleaned up these command objects very nicely. And now, when you look at one of these command objects, all you see is the run method that does the work. And the plumbing and the wiring up behind the scenes should just happen. I am concerned about the day that someone forgets to inherit from the space command, and then it's like, why does nothing work? I thought command objects just worked in the system. But we're going to deal with that when we get there, which is hopefully a while down the road. +STEPH: I like how you're pushing at the boundaries of our comfort zone. I say our comfort zone because I imagine we feel similar. +CHRIS: It is. We definitely got a shared comfort zone. [laughter] +STEPH: Yeah, we have a shared comfort zone with inheritance, but you're pushing at that boundary of that comfort with inheritance because it is something that can be so painful. But you've identified an area where inheritance feels useful. And then it also sounds like a very meaningful...you're introducing this pattern and then trying to make it easier for others to follow this pattern. So it's a very intentional design decision of where we want to group these behaviors together and then make it very easy for other developers to then pick up this pattern and run with it, and then also work with these classes. So I am intrigued to hear how it goes and how others feel about the pattern as well. +I also wonder, this is one of those areas where it feels like this very intentional design decision. Is it something that you think in the base class would be worth highlighting? Like, hey, here are the things that we are using in this base class. This is the intention of this base class. I don't know if that's maybe a comment or if that's something that's documented in the README. I know; I see your eyebrows went up when I said comment. But it does feel like one of those areas where it's like, hey, we have introduced this new concept. We want you to follow along. Here are some helpful guidelines. +CHRIS: Those were mostly joking eyebrow raises because I have thought of that. I haven't actually gone to that level. But in the back of my mind, there's this pattern that we have within this application. Ideally, we're going to lean into it more and more so that A, we have a clear way that we do things within the app but also make that as understandable and discoverable as possible. I'm not sure if a comment in the class is the right thing or...so I'm deferring what I want to do on that for now because right now, it's myself and one other developer. We sort of developed this in tandem. So we were working together on it. We would pair in a bunch of the features. And what we have now is the crystallization of what we found useful. And we're both very comfortable with it. So there isn't the need to explain it. +I'm almost thinking about it as just-in-time educational content around this piece of our application. I don't actually trust that I would do a good job describing it in the abstract because I know it. Like, to me, this thing makes sense right now. But I've been on the other side of stuff where someone was like, "Hey, this totally makes sense." And I'm like, "I don't know any of the words you just said," and so I felt that pain being on the other side. You could say I'm just being lazy, but I do think this is a purposeful delaying of that where I want to wait until I actually have someone to teach this to. And at that moment, I want to see what that conversation looks like. And I'll try and explain it to the best of my ability, but I'm sure they're going to ask questions, and I'll be like, "Oh, wow. Yeah. I hadn't even thought of that. But now that you ask the question, totally let me explain this part that I was going to gloss over and forget to mention." +And so, ideally, that is what will happen down the road. And then from that, hopefully, some artifact becomes clear, whether it's a documentation page in the repo or a comment in the class if it's simple enough or maybe even it's a recording of a pairing session. And that's the artifact that we keep around that explains this piece of the application. So I definitely think a version of that makes sense, but I am not doing it yet. +STEPH: It's funny; you’re saying so many good things that I agree with. I love the just-in-time education; that part is fun. And yeah, there's a part of me that definitely still leans into the idea because we've talked about this in the past too, where we write down, in the moment, the things. Having that context when we're implementing it is really important and helpful. So even if it's not this grand explanation…which I really like what you said around having someone to explain it to or have that conversation with so that way you're documenting the useful bits, that part I like very much, but capturing the intent as soon as the change was introduced. So even if it is a very high level like, hey, we are using dry-monads and Adder Extras, even if it's just links to those things, that's something that I think I would still favor just to go ahead and start surfacing this is a pattern. This is a choice. And then, as you continue to work with the pattern, if you change your mind, it's still very easy to scrap that documentation. +So I think if it were me, I would still go ahead and document it. I think it's that piece about discoverability that's calling to me so strongly where that's where I want to then highlight the things that are in use. So even if there's not an explanation, people can find the resources very easily. Because you're right, you did say a lot of interesting bits in describing this pattern. And the fact that we're talking about it now also just deepens my suspicion that it would be nice to comment somewhere, and perhaps a repo is a perfect place for it and just get it out there, and then it can always be revisited later and improved. +CHRIS: Okay. I like that you are keeping me honest on this because I do think there's a certain amount that I'm just being lazy here and not wanting to do that because it is actually really hard to try and document something like this. Like, what are the important pieces versus what are the extraneous details that people don't actually need? +I do wonder, so the pull request that did this refactoring and introduced this base command object that does have the explanation captures the point in time and whatnot. And so I wonder, is there a version of tagging important pull requests that tell the story of the application? A lot of things are just going to be like; this is adding a feature. It's the same as the other 30 pull requests recently that added a new feature. But this one is special from an architecture perspective. And so let's tag this, let's add a label. I don't know what it is but something that allows for discoverability of the story of how this application became what it is today because anything else I worry will go out of date almost instantly. But this pull request is true fundamentally in that same way that we say commit messages should capture as much of that detail. +So I did do that writing for the pull requests/the commit message. And I wonder if maybe that's the best artifact for this moment but then the question of surfacing it and making it discoverable because otherwise, it's just lost in the sea of other pull requests. So I don't know. But I do like the slight push back that you're giving me here of like, yeah, but what if you did something though? And I'm like, yeah, that's fair. I should probably do something. +STEPH: Being able to pin those specific PRs that have significant architecture changes sounds really novel, but I'm going to take this opportunity for me to be lazy. And if I'm joining a project, I don't want to read through what has happened. I just want to know what's true now. And if I go back and look at those PRs, I won't know if all of that is still relevant and how it's changed. So it sounds neat from telling the story of how an application has evolved. I like that sort of developer lens, and what are the things that we have tried and then changed over the years? But from I am onboarding to this application, I just want to know what's true today? What are the things that you want me to follow? What are the patterns that are going to be really helpful for me to look at? And so then, I don't know if I would use it in that context. +And this may be one of those areas where I'm feeling overly skittish in response to the number of things that you said and the use of inheritance. Because I have felt so much pain of where I'm going up the tree to figure out what the heck is happening in the world and then to understand all of those pieces, and then swimming all the way back down to the class that I'm actually working in. So it could just be past experiences that are now influencing how I want to document or work with inheritance. It probably is. [chuckles] That's probably a big factor of it. It doesn't mean I disagree with it because those painful experiences are meaningful. [chuckles] +CHRIS: Yeah. I think the foundational thing...I tried to start this with the context of like; I did a thing. This is another example of good idea, terrible idea; my favorite segment on The Bike Shed. I stand by it. I think it was useful. It does use things that we have traditionally moved away from. I say we because, again, I think we have a shared approach to development at this point. But I think it's worth it. I hear everything that you're saying about the documentation, but I've been burned by that so many times where the documentation is like, here's what's true now. And you're like, no, there isn't even a class called that anymore, and no less does it work that way. And so, my inclination is not to go that way. +The solution that I have in mind is when someone is onboarding into the application, I don't expect there to be documentation and other things that I can hand them so that they can run. I expect to sit down with them and work with them. I'm going to pair with people when they join a team for a long time. There's a period where that's true, I think, and then you get to a certain size of an organization, and you're onboarding enough people regularly enough that that's a thing that you should get better at. +But for I think a surprisingly long time, my answer I'm more than happy for it to be, yeah, we're bringing someone new into the team. Let's sit down with them. Let's spend the time. Let's tell them what's true because I know currently, and I can give them an up-to-date version of that. And ideally, as part of that, then update the static documentation, the repo, the README, the other things based on the conversation that we have and recognize oh, that that link is very out of date. Let me change that one real quick. But I'm not expecting to have comprehensive documentation for that. I'm expecting to use real human interaction to fill that gap. +STEPH: Yeah, I really like that you're also calling out how fallible documentation is and how it has misled us so many times. I also love what you highlighted where when somebody new is joining the team, we are more than often going to sit with them and then explore the app together. And it just made me revisit that phrase that you used earlier about the just-in-time education. Because for this command object, you may join the project and not need to interact with this design pattern for your first couple of weeks, first couple months, who knows? +So then it comes back to the idea of how when someone is in the space of where using a command object feels like the right approach, then how do we introduce them to this pattern and then make sure that they have the tools that they need? And if someone is accessible to then sit down and go with them, that's great. But if someone is not accessible, then I still want them to have at least a few of the resources that they need to dive into some of the more complex things that are being included. So, yeah, it's a tricky one. I like this thought experiment. +CHRIS: But yeah, overall, I'm happy with it for now. I'm hopeful it will work out for us moving forward, and I'm hopeful that it will also be a sufficiently discoverable or teachable thing within the application. But again, I will certainly report back and see how that one plays out for us. But yeah, that's what's up in my world. What else is going on in your world? +STEPH: Something else that's up in my world is I have pulled in a tool that I've used in the past, and I really like it. So I'd really like to talk about it here for a bit because I just find it so useful. And now that I've added it to this new project, it's just really top of mind for me. So I found that when working on a project, there are often times where I want to run something right after a deploy has happened, and I want that to be automated. I can do it manually. I can hop in, but then perhaps if you're deploying across many environments or many systems, you don't want to have to do all that manual work, or you also just want the convenience of you can set it and forget it. And that way, you know something's going to happen. So perhaps it's something where you want to change some data, or if you want to enable a feature flag, then this is really helpful. +So the gem I've been using for this is called afterparty, where you can write automated deploy tasks that essentially behave very similar to migrations. So you can write a Rake task. It has a timestamp. You can implement the logic that you want to be run right after your code has deployed, and then afterparty itself, we'll check the timestamp. It will see if it has been run. If it's already been run, it won't run it again. Or if you like, you can set it up so that way, you can tell after_party to say, "Hey, after every deploy, I want you to run this particular task," but it's such a nice improvement to the workflow. +And the other thing that I really like about this that I feel is a bit contentious is separating changing data outside of migrations. So I am a big fan of migrations are focused on changing your schema itself. But if there's actual data that you need to change, I really like when that is separated outside of the migration. There are definitely times that I understand it's really nice to just do it all at once, and it's easier. But anytime it starts to get even a little complex, I immediately want to write tests for it. And I can't test my migration. But if I'm changing some meaningful data on production, I want tests to back it up to make sure that I'm scoping correctly, that the outcome is exactly what I expect. It also makes it easier for other people to review. And after_party gives me that functionality so then I can have my migration. +But then I'm like, oh yeah, but I still want to automate changing this data because that's often one of the complaints that I hear from people when I do ask them to separate into a Rake task, changing the data. They're like, "But I don't want to have to then follow up and then run this task later." And I'm like, that's cool. Afterparty has you, and you can automate it and not worry about it. So afterparty has been one of my favorite gems to add to applications. +CHRIS: That's interesting. There's a bunch of layers to everything that you just said. I think I've worked with after_party on a project. I think we were working together on that project, if I'm remembering correctly. I have no bad memories of it, which given the nature of the tool, makes me think it did its job very well because its whole point is just like, oh cool, now you can just do this thing, and you don't even really have to think about it. Because there are plenty of other times where I've had to orchestrate or do a deploy. And then I SSH tunnel into production, which is a bad idea, and then I'm running Rake tasks manually. And so, I think the fact that I don't have any pointed memories of this is a really good sign for a tool like this. So that's a weird vote in its corner for me. +You did say something that was interesting that I want to poke at a tiny bit which was you can't test migrations, and I think that's true. Like, I don't know of any way. And it feels like a thing that is sort of fundamentally deeply true. But I do wonder, is there any gem out there? Has anyone done a weird science experiment to figure out like, I would actually really like to be able to test my migrations? So I think the idea of having to pull data change out of migrations for the reasons that you said totally makes sense. +But there are often times where I want to convert from non-nullable to nullable. And in the process, I want to backfill with a given value or something to that effect. And I like to encapsulate that altogether such that if it fails or succeeds, it's transactionally consistent. And I do wonder, could I wrap a test around that? I don't know of a way, and I think it may actually be the Rails testing infrastructure is just like no, we prepare your schema for you in the background, so it's just up to date. And therefore, you don't even have a way to be in a state where the migration hasn't run. But it's an intriguing one. +STEPH: Yeah, that's probably a hard absolute that I said where you can't test it, and I'm sure there is a way to test it. How friendly or how easy that is to do, I'm really not sure of. It also feels like one of those areas where it feels like I'm testing this other service that I should trust fully, so then I'm not necessarily testing the migration itself. I'm testing some logic that I've added inside of the migration where I'm changing some data. And the example that you provided is perfect because that's one of those that I'm inclined to include in a migration. It's more like where we want specific users who have this value or in this category. And then, we want to migrate them from this data to the other data. And when we start getting complicated in our migrations, that's when I'm like, this is a bit much, and I'd really like a test that documents that we're doing this correctly. That's where I get squeamish about having data changes in migrations. But you do raise a good point. I don't know; I’ve never tried to test one. I've just always reached for this other approach, but that is more the pain point of if I could test this data change inside of migration, then that would work for me. That would solve my problem. +CHRIS: I wonder if an alternative approach would be to just introduce an object or a class that does this work. So like a command object as it were, to do a call back to earlier in the episode, that does that data transformation because it’s exactly what you're describing, for this subset of users do this. But if they're in this state, then do these things and create two new records for any user like this. That sort of stuff is really complicated. Definitely want to have some tests around it. But you're talking about a gem that allows you to extract it into a Rake task-like situation. But I wonder, could we just have a class for that? +And I used to be a big believer in your migration should live forever, and they should always be runnable from the beginning of time. I've given up on that belief. That's one of the things that I've been like; I don't know. It turns out I've never done that. It's not an important thing. Just DB schema load is going to be fine most of the time. It's great for the past ten migrations to be around just to tell a little bit of a story. But I'm not tied to migrations being runnable forever. So the idea of you introduce this class, it encapsulates that data transformation. You can test it because it's its own thing. It will still be run within the context of the transaction of the migration. And then you throw it away down the road along with the migration, and you do that migration roll-up thing. It's just a different thought there, although I do like the...well, I guess that would also run automatically, but that runs as part of the deploy as opposed to after the deploy, which is meaningfully different than what after_party does because there might be one of these migrations that takes a long, long time to run because you've got a ton of data. And you want to decouple it from the true deploy release sequence that happens and the time limits that are there. So I think I've now talked myself in three circles, and I'm going to stop. +STEPH: I like how you highlighted that part where it does decouple you from the deploy process where it's still automated; it runs afterwards. But say if it's something that doesn't need to hold up the deploy, you don't need to wait for this data to be migrated before the deploy can go out. Then that's a nice separation because then it can happen afterwards. Or if you do need it to happen part of the deploy, yeah, there's lots of interesting bits there. I feel like you and I could talk about it for a while. +But we have a listener question that I'm really excited for us to talk about. So I'm going to hard pivot over to our listener question. This question comes from Jonathan. And Jonathan wrote in, "Hey, gang, longtime listener, first-time emailer. I've heard you reference retrospectives a few times as part of your normal development practice. In my limited experience with them, I often find retrospectives don't feel productive because team members are reluctant to raise issues without seeming critical or blaming another team member. I would love to hear you describe how you typically run retrospectives to foster open discussion and make it a productive use of time. Bonus points," oh, I love bonus points "if either of you have experienced rescuing an existing team that was not having productive retrospectives. P.S. Thank you for ongoing participation in the Ruby and Rails communities. I look forward to seeing a new episode pop into my podcatcher each week." +All right, retrospectives. I love this question because I've definitely been part of teams that are really struggling to have a productive retro. So I think it would be helpful, as Jonathan highlighted, to go ahead and share how thoughtbot runs a retro. And then I'd also love to touch on some of the areas where I have seen teams really struggle to have a productive retro. So with the thoughtbot format, there are really two questions that we focus on. The first question is, what went well? And this starts the meeting on a positive note, which can help people get engaged before then we move on to heavier topics like concerns and issues. +When we run a retro, we ask each person these two questions. So that first question, we go around to the room, and we say, "Hey, what went well for your week or for your last two weeks?" And then we document all of those positive things that people say. The next question is, "What concerns do you have, or what are you worried about?"And the goal here is to highlight issues early, which then gives us the chance to address them as they come up rather than waiting till an issue has grown out of control. And it's usually during the concerns portion that I often see retrospectives fall apart. The reason for that is hearing someone describing a concern is often something that can stir up a lot of emotions. And I know for me, it certainly triggers my instinct to where I really want to dive into that issue, and then I want to solve it. +But by reacting to a specific issue and then trying to solve that issue, I'm interrupting that retrospective flow to then focus on that issue. And we may not get to a bunch of other important issues that people had. So that's often where I see retrospectives fall apart. And the way to fix that is to then have the team consensus that hey, this is a space where everybody gets to air concern. We're going to go around the room, so everybody has a chance to speak. We're going to document it, but then we're going to move on and then come back to this later. +So when do we talk about concerns? So once everybody's had a chance to share their concern and that's been documented, during that process, you're often upvoting other concerns. So someone may bring up a concern that I also have as well. So when it's my turn to speak, I'll say, "I'd like to plus-one that particular concern," and then maybe add my own or just plus-one some of the others. So then, by the time that everybody's had a chance to speak, you already have an idea on…whoever's taking notes or if it's being ideally shared so the whole team can see. You can already see the concerns that most of the team is identifying with or that are the more popular concerns. So then, as a team, you can say, "Hey, we're going to focus on the top two concerns because that's really the amount of time that we have," and that way, we're focusing on concerns that impact the majority of the team. So at that point, then we can start talking about those specific issues and how we'd like to address them. +And then out of that conversation is then the next part of the retro format, our action items. And then action items are where we can capture the things that we would like to try during our next iteration of work until our next retro. This is our experiment area. So then we can say, "Yes, we'd like to try something different, or we'd really like to monitor how this goes." +And then one other fun thing that I typically include in retros are housekeeping. So then we can talk about time off, team celebratory events, anything like that that's helpful to highlight to the team. +That's a quick overview of how typically I myself run a retro. Chris, do you have anything you'd like to add or anything that I've missed? +CHRIS: No. I think that that mirrors pretty well the best retros that I've been a part of. There are a couple of things that I think I would add or emphasize in that. So one is foundationally, with a retro, what are we doing? What's the goal? And the goal with a retro is to identify and evolve our process. So identify where there are any bottlenecks or things that aren't working, and then ideally change things over time. I've been on many teams where just the same issues get brought up over and over in retro, and nothing changes. And that will just completely deflate the team. And so, if that is happening, that's a fundamental thing that we need to fix. +And I can totally understand folks being like, "Retro is awful. We just sit down and say the same things, and then nothing ever changes." If that's happening, we have to fix that at a more fundamental level. That is going to be more than a retro’s worth of effort. But ideally, retro is now this structured space each week, each iteration, whatever it is where we are discussing what's going on and ideally, slowly, incrementally making the process slightly better. In my experience, it's something that I really love because I come to associate it with stuff is going to get better now. That's what retro means. If that's not the feeling you have, then I totally get why you wouldn't want retro. But I promise that that can be a reality. +And then to touch on some of the particular procedural points, everything you said definitely maps. And I've found that structure works really well, but there's a lot of subtle things in that structure that I think are important to highlight. So one, going around the room and actually asking everyone individually for their thoughts, I find to be so useful because it's very easy for one or two more vocal individuals to just dominate the conversation. So particularly by starting with what went well and then also by actually going around the room and requesting "Everyone reply to this question please," even if it's just like, "Yeah, you know what? It just felt like a good week." That's an answer we'll accept but ideally, a little more structure or a little more meat to it. But I find that to be really important. +Likewise, I have found that having a facilitator, so someone who is guiding the retro but not actually a part of it. They're not going to be saying what went well or what didn't go well. They are just directing the conversation and somewhat critical as you're going around and asking for concerns. They are the person whose job it is to prevent the team from starting to try and address the concern when it's first voiced. So ideally, we're just collecting the concerns. We're collecting the plus-ones so that we know which are the more prominent ones, and then we can focus on those. +And I think that idea of the plus-oneing of concerns and then really focusing on the ones that have more folks that are concerned about it feels really critical in my mind. So ideally, we are a team. We're working as a team, and if one person has this gripe that they really feel deeply, but nobody else really cares about it; ideally, we find a way to help that person not feel that way. But that's not necessarily where the team collectively should put all of their energy. So yeah, that's a bunch of little pieces. +Also, just as a note, we'll include these in the show notes, but there are a couple of previous episodes, so Episode 132: “What Went Well?” is a discussion between Derek and Sage, previous hosts of the show, talking about retros. Episode 172: “What I Believe About Software” was the first guest visit by a certain Steph Viccari. And so that is a wonderful episode in which we dug into retro because it's one of our favorite topics. Also, Episode 299: “Is Agile Over?” We definitely touched on...that was a pretty recent one, but we touched on retro. Then there's also a video on Upcase called “Running a Retrospective” that basically describes exactly this process and shows actually an example retro and running through it. So there are lots of other things that we can point out here. But again, I think fundamentally, what are we doing, and how are we doing it? If we can answer those questions well, retro is going to be great. If not, it's probably not going to be that great. +STEPH: I appreciate you calling out all of those important nuances because those nuances are what lead to then a retro feeling more productive. And to address Jonathan's other question around if people are feeling timid to bring up an issue because they don't want to blame anyone, then I think to address that one; specifically, you have to come to retro with a WE mindset. And I think HBO accidentally sending a test email is a really good example of that. Because in the Twitter thread, a bunch of other I presume developers were commenting and responding in support of the person that sent that out to say, "Hey, you discovered a missing safety net in the system," or the fact that it was fairly easy to make this mistake and send it out. So if you come to retro with this mindset of if a mistake was made, how can we as a team improve this so then it's less easy to make that mistake? Then you won't have the sense of we're blaming this on one person, but instead, we as a team are responsible for helping each other out. +CHRIS: It's interesting to have that conversation in the context of retro because I don't necessarily think of retro in exactly this way. But there is the idea of blameless postmortems, which come out of the Google Site Reliability Engineering; I think it's a book, maybe it's a website. We can include a link regardless. But that idea of blameless postmortems of collectively as a team, this thing made it out into the world, this bug, this problem. So we need to own that as a team, and we need to have a blameless conversation around that, just talking about what happened. And there are subtleties there. And that's a nuanced idea that needs to be evolved, but that is at least some writing that exists in the world that talks specifically to that part of it. That said, I wonder if a true postmortem, so a distinct meeting just dedicated to those more pointed issues, might be more relevant, and then retro is more of a shared overall conversation. But if there are smaller versions of that, then I think using that framing could be really helpful in retro. +STEPH: Yeah, I think you said that perfectly where there needs to be team ownership over all of the issues that are being discussed. And I think there is one other very tricky area to navigate with having a productive retro. And I don't know of a better way to say this. But you have a grumpy goose on your team. You have someone who doesn't like retros, and they're going to be negative, and they're going to be vocal. And that is a hard one. I have been there before. And I often approach that situation by speaking with them specifically around what are your concerns with retro? Are you willing to at least buy-in and give this new format a chance? But you essentially need them to buy in or have leadership buy-in so then they know to follow suit as well that this is a team process that we're going to improve and work on together. And if you don't like it, then that's what retro is for. So how we can make this a better, more productive meeting? But just showing up and being grumpy isn't helpful. And then helping people who have been burned by retros overcome that negative reaction to retros is something that takes time. +CHRIS: Oh yeah. The grumpy goose just affects everything on the team. But definitely retro is one where I've seen that particularly pointed. I think in those cases, the best luck I've ever had is to, like you said, have a separate conversation but have the conversation at a higher level. So the question isn't about do we have retro or do we have it in this shape? The question is, do we think we are operating at our best? Do we think everything is going perfectly? And almost never will the answer be "Yeah, this is great. We have no bugs. We're moving as fast as we possibly can. Everyone is happy. No one is burnt out." And so if we get to an agreement that is like, well, yeah, sure, there are things that we could improve, then I think that's a toehold that we can then build on and say, "Okay, so how do you want to go about that? +I am fine to explore a different approach than retro as a meeting to continually improving and evolving our process. I'd love to know what thoughts you have, Mr. Goose." But if they don't have an alternative, retro is the most effective structure that I've found for this continuous feedback loop around the process. I'm very happy to find an alternative, but I critically think we need something like that. And so if they're going to be pushing back on retro specifically, then I'll bump up to the higher level and say, "Okay, how do you want to be improving our process? Let's try something else, but let's make sure we are asking the question of how do we improve our process and is that succeeding?" And also, stop being so grumpy. Come on, what are you doing? +STEPH: [chuckles] I recognize that approach so much because then it really gets to the heart of the purpose of retro whether it's actually called retro or how we handle it is not significant, but the fact that we together as a team can get together and discuss how to improve. That's really the important thing that we're after. And retro just happens to be the format that I use and really enjoy. But like you said, it's always open to each team's interpretation. +On that note, Jonathan, I hope this quick overview of the thoughtbot retro has been helpful. And we will also include some other links that also highlight how thoughtbot runs retros and some other discussions that we've had about retrospectives. But on that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris gives a DB sessions update and talks bifunctors & command objects. Steph shares the coolness of a gem she's been using called after_party, and excitedly gushes about her new laptop. (Chris is hoping to hold off on replacing his until the end of the year and then they can compare!)

+ +

The two then answer a listener question on retrospectives and how they've seen productive ones run, while giving some of their own helpful opinions on dos and don'ts. They're talking to you, Grumpy Goose!

+ + + +

Transcript:

+ +

STEPH: Cool.

+ +

[laughter]

+ +

CHRIS: Good. No, I like what you did there.

+ +

STEPH: Yeah, I feel like we can get rambling on that one.

+ +

CHRIS: It's been great. This is what the Bike Shed is at its best. It's the two of us just rambling and being like, well, what about this? And if it's this, then that, then these, and it depends. And it's complicated and it's nuanced. And what about the humans? That's the story of The Bike Shed right there. [laughs]

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm CHRIS Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week?

+ +

CHRIS: My week has been good. I have some updates actually on some topics from previous episodes. One of the things that I can update on is the discussion around the cookie versus the database store. So I had posed this as a thing that I was going to be doing in the app for a handful of reasons. Most notably, I wanted the ability to invalidate sessions from the server-side, wanted to have a little more control over that. And so that's a dream that the database-backed session store can do. Eventually, I have to make that actually work in the way that I want.

+ +

But I was asking the question in that episode, which we can include a link to the specific episode, but I was asking the question of why don't we just do this all the time? The database-backed sessions seem better in all these ways. It's a lower overhead per request because you're just sending the session ID and the cookie instead of the whole payload of the session. You actually can have more data stored in it, a bunch of things that seemed really great. And then right after I introduced it, I figured out the thing. I figured out the secret. It's not a big issue, and we're going to stick with database session stores. But we have to be purposeful because it turns out they are essentially plain text in the database.

+ +

And so if there's anything that you are putting into the session like say a social security number or an authentication token or other things which naturally I might have done if it was in a cookie that lives on the user's browser and never actually lives on the server, persists on the server, that seems fine to me. But now these things are getting stored in the database and that really changes the calculus, especially because if I'm not purposeful, they'll just stick around for forever. So social security is probably the most pointed example of this. If you happen to have a form in the app that accepts a social security number and you want that to persist through some number of other steps, not actually going to store the social security number in the database because that's a thing that I have actively chosen not to do. I need to send it off to some other system, but I do need to hold onto it for a few minutes. The session is a perfect place to put that unless the session gets stored in my database.

+ +

STEPH: That's such a great point. I'm so glad you discovered that. And in our recent conversation, we were trying to think of the reasons why this isn't the default case. You may be headed in this direction, but this may also be timely, the fact that you're discovering this issue but also the fact that Rail 6.0 now has encrypted columns. Is that where you're headed with the fact that you can still keep session data in a database?

+ +

CHRIS: That is a great question, and it is an intriguing option. But it's not the one that I'm going with here. I think broadly, my hope is to completely avoid ever persisting this data in the database, this truly sensitive user-specific PII or PCI or social security numbers or any of these other fancy acronyms that get collected together under the umbrella of I probably don't want that on my server. For those, I'm just opting to push them back into a cookie. So I'm using particularly a...In rails, it's fun because they have a fluent interface where you can just chain together things, so it's cookies.signed.encrypted.whatever, and then you go from there. But I'm using signed, encrypted cookie, which is essentially what the session store views; the cookie session store uses itself.

+ +

So I'm basically reverting to the old session store behavior for specific values. So anything that is truly sensitive like that, I'm just saying, cool, that's actually just going to live in a cookie, and that will be it, but not leaning on the ability to encrypt the database sessions. There's just enough subtlety around that. There's so much volume of data if I do allow that sensitive data into the system that any failure, any exploit that happens, would be somewhat catastrophic. So, in my mind, this lowers the surface area and says, yeah, this data really never lives on the server. It comes with a request, and then it's gone after the fact. And that's the world I want to live in.

+ +

STEPH: Yeah, that's super interesting. You're also raising questions for me that I hadn't considered when we originally had this conversation where there's necessity or that you're looking to store form data or sensitive data in that session as well. So that makes a lot of sense to me that for that type of behavior, we're going to separate that from the idea of authentication and the user session and still use encrypted cookies for those details. So it only stays with the user's browser, but then the actual authentication of a user that part could still live in the database.

+ +

CHRIS: It is ending up being a weird Venn diagram of; this is data that I want to stick around but only sometimes and particular to the machine that the user is interacting with because the session is still associated with a cookie at the end of the day. So a user may have multiple sessions in the database-backed session version. It is somewhat interesting, and I'm going to see how it develops over time. But yeah, at a minimum, I have now found this edge case of like, ooh, okay, sensitive data, that's a thing, which is one of the reasons that I would reach for the session inherently. So it turns out, as always, it depends. Things are complicated.

+ +

STEPH: It's a nice update. I like when we have closure to a question like that, especially so quickly.

+ +

CHRIS: Love to provide that continuity. It's what I'm all about. But yeah, what's up in your world?

+ +

STEPH: What's up in my world? I am excited that I have a new laptop. So I have been using a MacBook Pro for about the last...it's lasted me for a while. I think I've had it for a good four, four, and a half years, but that's on the fritz. The keyboard, in particular, the keys are popping off, and that's something that I could go get fixed. But I'm at the point that I need a new laptop. So I have a brand new shiny laptop. And I had the option to either go with a 16-inch MacBook Pro or to go with one of the new, fancy laptops that has the M1 chip. And I was torn for a little while because having the M1 chip sounds really cool and novel, and there's a lot of speed improvements that come with that.

+ +

But I ended up going with just the 16-inch MacBook Pro; specifically, one, it's still very fast. It's very reliable. I can use this as my work machine and just know everything's going to work. That part feels really important to me. And then also the screen size is important. So any Mac laptop that is using the new M1 chip, I think they only go up to a 13-inch, right now, screen size. And I really want the 16-inch in case I am traveling, so I have that larger desktop. But I did do some research into the M1 just because I know about it. I know it's out there. I know it's hot. People are interested in it, but I didn't know a whole lot about it. So for anyone else that's like me and is curious about what the heck this M1 chip is, it's essentially Apple's foray into making their own processors.

+ +

So traditionally, their machines have used Intel CPUs and third-party graphic processors, and other parts. And this introduction of the M1 chip really represents Apple's switch to having their own internal architecture rather than relying on those third-party parts. And it also means that all those features that were sourced from other parties like the CPU and its security are now being combined into a single chip, which has also led to some performance improvements. And while I was reading about the M1, there's a lot to go through, but the thing that stood out to me was this idea of Apple's Neural Engine. And I thought, well, that sounds super fancy. What is that? Are you familiar with Apple's Neural Engine? Have you read about that?

+ +

CHRIS: I don't think I am. What all is that?

+ +

STEPH: Yeah, good question. That was a question I was asking myself just recently. So essentially, their neural engine it's a microprocessor that specializes in the acceleration of machine learning algorithms. So it's really similar to how a GPU will focus on accelerating graphics rendering. And their neural engine or neural engines in general then focus on accelerating neural network operations. And the inclusion of a neural engine isn't something that's new because Apple introduced this into iPhones and iPads back in 2017 to support their features like Face ID and emoji, searching for photos with dog pictures. Siri speech recognition is also one that's using this engine and other machine learning tasks.

+ +

But the sparkly stat that Apple is sharing with this new design is it's a 16-core design that can perform 11 trillion operations per second, which sounds very fancy, very fast. But it really got me thinking about how companies are working to improve, not just laptops but also our mobile devices to run machine learning software more efficiently, and then how that's just going to evolve and change all the different features that we use, and then how developers can integrate with this engine. I think currently, Apple hasn't shared much information about how this engine works, but I think they've exposed a few developer tools so people can still build features that will then use the power of this faster, improved neural engine.

+ +

CHRIS: Oh, that's super interesting. I have still not really delved into machine learning or artificial intelligence, or any of that stuff in any real way. But it's one of those things like the number of mentions is ticking up. And at some point, I'm like; I probably have to pay attention to this, don't I? I'm still in the not paying attention to it camp. So if I'm understanding, though, you just described this wonderful feature, but you opted for the machine that does not have all the fancy stuff. You did not...

+ +

STEPH: Exactly. [laughs]

+ +

CHRIS: Okay, yeah.

+ +

STEPH: Yes, it would have been nice. That would have been neat, but yeah, I needed a machine with a larger screen, all those good things. And that's still really fast, for the record.

+ +

CHRIS: Oh yeah. I'm desperately hoping to make it to the end of this year. This is going to be a bit of a rumor mill here, but my understanding is the expectation is that Apple is going to release a 14-inch MacBook Pro with the M1 and the return of MagSafe, and the removal of the touch bar. And that sounds like my dream machine right there. I want that piece of hardware.

+ +

I also seem to care a little bit less about the size of the laptop screen. I'm so often working at my desk with a large-format monitor that I'm connected to. And so, when I'm on the road, I want to optimize for portability when I'm traveling because I do it so rarely, and then I'm hopefully focusing on travel at that point. But we'll see if that remains true as the shape of my work changes and I start to not only work from home. And maybe I'll actually change my tune on that. But for now, that's my hope is to make it to that machine and then get one, and that it exists because right now, those are all rumors.

+ +

STEPH: Well, I totally support this goal of yours. So that way, you can have that new-new, and then you can report back on what it's like, and then we can compare. Because I'll have the other version, the Intel CPU, and then you'll have the M1 chip, and we can see how our lives are different.

+ +

CHRIS: You'll have the new, and I'll have the new-new, and that's how we'll categorize them.

+ +

STEPH: [laughs] But yeah, I'm very much looking forward. Having a new laptop is always just such a fun feeling. It's just a clean space that I get to rebuild. It's like going through and prioritizing; what are the things that still spark joy? And then I get to only port over the stuff that I still really use all the time and want to keep. So I'm looking forward to getting it set up.

+ +

CHRIS: I need to do that sometime soon. I'm like five years deep, at least on this machine. So I've been dragging along. Also, the hard drive is just completely full, and I regularly have to go through and delete things before we start recording because it turns out these audio recordings start as very large files. [chuckle] So it's almost a weekly thing where I'm just like, got to throw something out today. I don't know what. It's fine. I'm going to be fine. [laughter] I'm going to make it to the end of the year, and it's going to be great.

+ +

STEPH: What else is going on in your world?

+ +

CHRIS: Well, I wrote some fancy code, and I use fancy not necessarily as a good word. [chuckle] So I'm intrigued that the code could be described perhaps as clever or other words like that, which I think are very complicated words in the coding space. I tend to try and avoid this type of coding where I'm trying to introduce abstractions and clean things up, and remove duplication because I've been burned by that so many times in the past. But this time, I think maybe this time it'll work.

+ +

So, in particular, there are two different areas of the application. There were two sets of refactorings, but they really went together. One is we have the idea of command objects within the application that we're working on. So there are a lot of cases where we need to save something to the database and then communicate something to an external API. And then presuming the results of that is a successful response from them, then unpack some data, make sure it's in the right shape, and then save something else to the database. And ideally, wrap that all in a transaction and keep everything together and then return some data at the end of it.

+ +

So that whole sequential operation, I've been using dry-monads to model that. I've talked about this on a few previous episodes. I'm really enjoying it. The more I lean into it, the more I find that it is just a really great way to wrap up that very procedural code. But ideally, do it in almost a functional way so that we've got these sequential operations that feed into each other. There's the railway-oriented programming stuff, which is associated with this idea.

+ +

But there is a lot of boilerplate to these objects. So the way we've defined them is they have a class method called run that takes whatever the arguments are, and then it needs to pass those arguments into the initialize and then call run on the instance. So in order to define one of these objects, what we had been doing was def self.run and then all the arguments. And then inside of the body of that, it's new, and then pass forward all the arguments .run, and then define initialize to capture all of those and set all the instance variables, and then define the run method, which actually does stuff. Also need to define an Adder reader for all of those instance variables, which is a thing that I enjoy doing. So that's the interface I want, or that's the way that I want this class to work. I know other folks in the Ruby world feel differently. But that's the shape of the thing that I want, but that's a lot.

+ +

And there's also I regularly would find myself forgetting to duplicate something that we put into the class method run interface into the initialize method. And it was just like, this is all just wiring up and plumbing. There's also the binding of the dry-monads do notation for the run method as well as the inclusion of the results type within dry-monads. Type is a strong word, but that gives us the success or the failure objects that we can create. So ideally, all of these command objects either return a success object or return a failure object. It's one of the two. And that's one of the things that I really like about them. But yeah, so much plumbing.

+ +

So we define a base command, and the base command has the self.run method, the class method, and that method is defined very abstractly. So it's just args * keyword args. So we're capturing all of the arguments and then forwarding them on to new. So that way, I don't have to think about that interface. It basically just says, "Give me anything, and I'll forward it onto new." And the new or initialize is in charge of actually defining things. It also includes the result type. It includes the macro annotation for the run method, which is how dry-monads does its magic, that actually I had to include inline within the self.run, just because of the sequence of definition and the metaprogramming that's going on there. As I said, that sentence terrifies me a little bit, but hopefully, no one ever needs to look at this magic base class [chuckles] and figure anything out. So that was one part of it. That cleaned a lot of things up, so that meant I didn't have to write a ton of the wiring up code.

+ +

Then there was still the noise of actually defining all of the arguments to these classes. They often take a handful of arguments because that's their job is to grab a bunch of things and do some work with those things. So for that, I have brought Adder Extras, which is a gem that I've talked about probably in previous episodes, I think so. But this is the first time that I've really leaned into it and used it. And it gives some very high level what look like macros are just class methods. But the one that I'm using is Adder private initialize, and that you can then pass a variety of values too. And it will then say, okay, this method accepts a required keyword arg, a defaulted keyword arg, and a positional argument or something to that effect. But it's a very, very concise way to express that and then also get the private Adder readers, which again is the direction that I want to go with all of this.

+ +

So that’s a bunch of things that I have said. But all total, it cleaned up these command objects very nicely. And now, when you look at one of these command objects, all you see is the run method that does the work. And the plumbing and the wiring up behind the scenes should just happen. I am concerned about the day that someone forgets to inherit from the space command, and then it's like, why does nothing work? I thought command objects just worked in the system. But we're going to deal with that when we get there, which is hopefully a while down the road.

+ +

STEPH: I like how you're pushing at the boundaries of our comfort zone. I say our comfort zone because I imagine we feel similar.

+ +

CHRIS: It is. We definitely got a shared comfort zone. [laughter]

+ +

STEPH: Yeah, we have a shared comfort zone with inheritance, but you're pushing at that boundary of that comfort with inheritance because it is something that can be so painful. But you've identified an area where inheritance feels useful. And then it also sounds like a very meaningful...you're introducing this pattern and then trying to make it easier for others to follow this pattern. So it's a very intentional design decision of where we want to group these behaviors together and then make it very easy for other developers to then pick up this pattern and run with it, and then also work with these classes. So I am intrigued to hear how it goes and how others feel about the pattern as well.

+ +

I also wonder, this is one of those areas where it feels like this very intentional design decision. Is it something that you think in the base class would be worth highlighting? Like, hey, here are the things that we are using in this base class. This is the intention of this base class. I don't know if that's maybe a comment or if that's something that's documented in the README. I know; I see your eyebrows went up when I said comment. But it does feel like one of those areas where it's like, hey, we have introduced this new concept. We want you to follow along. Here are some helpful guidelines.

+ +

CHRIS: Those were mostly joking eyebrow raises because I have thought of that. I haven't actually gone to that level. But in the back of my mind, there's this pattern that we have within this application. Ideally, we're going to lean into it more and more so that A, we have a clear way that we do things within the app but also make that as understandable and discoverable as possible. I'm not sure if a comment in the class is the right thing or...so I'm deferring what I want to do on that for now because right now, it's myself and one other developer. We sort of developed this in tandem. So we were working together on it. We would pair in a bunch of the features. And what we have now is the crystallization of what we found useful. And we're both very comfortable with it. So there isn't the need to explain it.

+ +

I'm almost thinking about it as just-in-time educational content around this piece of our application. I don't actually trust that I would do a good job describing it in the abstract because I know it. Like, to me, this thing makes sense right now. But I've been on the other side of stuff where someone was like, "Hey, this totally makes sense." And I'm like, "I don't know any of the words you just said," and so I felt that pain being on the other side. You could say I'm just being lazy, but I do think this is a purposeful delaying of that where I want to wait until I actually have someone to teach this to. And at that moment, I want to see what that conversation looks like. And I'll try and explain it to the best of my ability, but I'm sure they're going to ask questions, and I'll be like, "Oh, wow. Yeah. I hadn't even thought of that. But now that you ask the question, totally let me explain this part that I was going to gloss over and forget to mention."

+ +

And so, ideally, that is what will happen down the road. And then from that, hopefully, some artifact becomes clear, whether it's a documentation page in the repo or a comment in the class if it's simple enough or maybe even it's a recording of a pairing session. And that's the artifact that we keep around that explains this piece of the application. So I definitely think a version of that makes sense, but I am not doing it yet.

+ +

STEPH: It's funny; you’re saying so many good things that I agree with. I love the just-in-time education; that part is fun. And yeah, there's a part of me that definitely still leans into the idea because we've talked about this in the past too, where we write down, in the moment, the things. Having that context when we're implementing it is really important and helpful. So even if it's not this grand explanation…which I really like what you said around having someone to explain it to or have that conversation with so that way you're documenting the useful bits, that part I like very much, but capturing the intent as soon as the change was introduced. So even if it is a very high level like, hey, we are using dry-monads and Adder Extras, even if it's just links to those things, that's something that I think I would still favor just to go ahead and start surfacing this is a pattern. This is a choice. And then, as you continue to work with the pattern, if you change your mind, it's still very easy to scrap that documentation.

+ +

So I think if it were me, I would still go ahead and document it. I think it's that piece about discoverability that's calling to me so strongly where that's where I want to then highlight the things that are in use. So even if there's not an explanation, people can find the resources very easily. Because you're right, you did say a lot of interesting bits in describing this pattern. And the fact that we're talking about it now also just deepens my suspicion that it would be nice to comment somewhere, and perhaps a repo is a perfect place for it and just get it out there, and then it can always be revisited later and improved.

+ +

CHRIS: Okay. I like that you are keeping me honest on this because I do think there's a certain amount that I'm just being lazy here and not wanting to do that because it is actually really hard to try and document something like this. Like, what are the important pieces versus what are the extraneous details that people don't actually need?

+ +

I do wonder, so the pull request that did this refactoring and introduced this base command object that does have the explanation captures the point in time and whatnot. And so I wonder, is there a version of tagging important pull requests that tell the story of the application? A lot of things are just going to be like; this is adding a feature. It's the same as the other 30 pull requests recently that added a new feature. But this one is special from an architecture perspective. And so let's tag this, let's add a label. I don't know what it is but something that allows for discoverability of the story of how this application became what it is today because anything else I worry will go out of date almost instantly. But this pull request is true fundamentally in that same way that we say commit messages should capture as much of that detail.

+ +

So I did do that writing for the pull requests/the commit message. And I wonder if maybe that's the best artifact for this moment but then the question of surfacing it and making it discoverable because otherwise, it's just lost in the sea of other pull requests. So I don't know. But I do like the slight push back that you're giving me here of like, yeah, but what if you did something though? And I'm like, yeah, that's fair. I should probably do something.

+ +

STEPH: Being able to pin those specific PRs that have significant architecture changes sounds really novel, but I'm going to take this opportunity for me to be lazy. And if I'm joining a project, I don't want to read through what has happened. I just want to know what's true now. And if I go back and look at those PRs, I won't know if all of that is still relevant and how it's changed. So it sounds neat from telling the story of how an application has evolved. I like that sort of developer lens, and what are the things that we have tried and then changed over the years? But from I am onboarding to this application, I just want to know what's true today? What are the things that you want me to follow? What are the patterns that are going to be really helpful for me to look at? And so then, I don't know if I would use it in that context.

+ +

And this may be one of those areas where I'm feeling overly skittish in response to the number of things that you said and the use of inheritance. Because I have felt so much pain of where I'm going up the tree to figure out what the heck is happening in the world and then to understand all of those pieces, and then swimming all the way back down to the class that I'm actually working in. So it could just be past experiences that are now influencing how I want to document or work with inheritance. It probably is. [chuckles] That's probably a big factor of it. It doesn't mean I disagree with it because those painful experiences are meaningful. [chuckles]

+ +

CHRIS: Yeah. I think the foundational thing...I tried to start this with the context of like; I did a thing. This is another example of good idea, terrible idea; my favorite segment on The Bike Shed. I stand by it. I think it was useful. It does use things that we have traditionally moved away from. I say we because, again, I think we have a shared approach to development at this point. But I think it's worth it. I hear everything that you're saying about the documentation, but I've been burned by that so many times where the documentation is like, here's what's true now. And you're like, no, there isn't even a class called that anymore, and no less does it work that way. And so, my inclination is not to go that way.

+ +

The solution that I have in mind is when someone is onboarding into the application, I don't expect there to be documentation and other things that I can hand them so that they can run. I expect to sit down with them and work with them. I'm going to pair with people when they join a team for a long time. There's a period where that's true, I think, and then you get to a certain size of an organization, and you're onboarding enough people regularly enough that that's a thing that you should get better at.

+ +

But for I think a surprisingly long time, my answer I'm more than happy for it to be, yeah, we're bringing someone new into the team. Let's sit down with them. Let's spend the time. Let's tell them what's true because I know currently, and I can give them an up-to-date version of that. And ideally, as part of that, then update the static documentation, the repo, the README, the other things based on the conversation that we have and recognize oh, that that link is very out of date. Let me change that one real quick. But I'm not expecting to have comprehensive documentation for that. I'm expecting to use real human interaction to fill that gap.

+ +

STEPH: Yeah, I really like that you're also calling out how fallible documentation is and how it has misled us so many times. I also love what you highlighted where when somebody new is joining the team, we are more than often going to sit with them and then explore the app together. And it just made me revisit that phrase that you used earlier about the just-in-time education. Because for this command object, you may join the project and not need to interact with this design pattern for your first couple of weeks, first couple months, who knows?

+ +

So then it comes back to the idea of how when someone is in the space of where using a command object feels like the right approach, then how do we introduce them to this pattern and then make sure that they have the tools that they need? And if someone is accessible to then sit down and go with them, that's great. But if someone is not accessible, then I still want them to have at least a few of the resources that they need to dive into some of the more complex things that are being included. So, yeah, it's a tricky one. I like this thought experiment.

+ +

CHRIS: But yeah, overall, I'm happy with it for now. I'm hopeful it will work out for us moving forward, and I'm hopeful that it will also be a sufficiently discoverable or teachable thing within the application. But again, I will certainly report back and see how that one plays out for us. But yeah, that's what's up in my world. What else is going on in your world?

+ +

STEPH: Something else that's up in my world is I have pulled in a tool that I've used in the past, and I really like it. So I'd really like to talk about it here for a bit because I just find it so useful. And now that I've added it to this new project, it's just really top of mind for me. So I found that when working on a project, there are often times where I want to run something right after a deploy has happened, and I want that to be automated. I can do it manually. I can hop in, but then perhaps if you're deploying across many environments or many systems, you don't want to have to do all that manual work, or you also just want the convenience of you can set it and forget it. And that way, you know something's going to happen. So perhaps it's something where you want to change some data, or if you want to enable a feature flag, then this is really helpful.

+ +

So the gem I've been using for this is called after_party, where you can write automated deploy tasks that essentially behave very similar to migrations. So you can write a Rake task. It has a timestamp. You can implement the logic that you want to be run right after your code has deployed, and then after_party itself, we'll check the timestamp. It will see if it has been run. If it's already been run, it won't run it again. Or if you like, you can set it up so that way, you can tell after_party to say, "Hey, after every deploy, I want you to run this particular task," but it's such a nice improvement to the workflow.

+ +

And the other thing that I really like about this that I feel is a bit contentious is separating changing data outside of migrations. So I am a big fan of migrations are focused on changing your schema itself. But if there's actual data that you need to change, I really like when that is separated outside of the migration. There are definitely times that I understand it's really nice to just do it all at once, and it's easier. But anytime it starts to get even a little complex, I immediately want to write tests for it. And I can't test my migration. But if I'm changing some meaningful data on production, I want tests to back it up to make sure that I'm scoping correctly, that the outcome is exactly what I expect. It also makes it easier for other people to review. And after_party gives me that functionality so then I can have my migration.

+ +

But then I'm like, oh yeah, but I still want to automate changing this data because that's often one of the complaints that I hear from people when I do ask them to separate into a Rake task, changing the data. They're like, "But I don't want to have to then follow up and then run this task later." And I'm like, that's cool. After_party has you, and you can automate it and not worry about it. So after_party has been one of my favorite gems to add to applications.

+ +

CHRIS: That's interesting. There's a bunch of layers to everything that you just said. I think I've worked with after_party on a project. I think we were working together on that project, if I'm remembering correctly. I have no bad memories of it, which given the nature of the tool, makes me think it did its job very well because its whole point is just like, oh cool, now you can just do this thing, and you don't even really have to think about it. Because there are plenty of other times where I've had to orchestrate or do a deploy. And then I SSH tunnel into production, which is a bad idea, and then I'm running Rake tasks manually. And so, I think the fact that I don't have any pointed memories of this is a really good sign for a tool like this. So that's a weird vote in its corner for me.

+ +

You did say something that was interesting that I want to poke at a tiny bit which was you can't test migrations, and I think that's true. Like, I don't know of any way. And it feels like a thing that is sort of fundamentally deeply true. But I do wonder, is there any gem out there? Has anyone done a weird science experiment to figure out like, I would actually really like to be able to test my migrations? So I think the idea of having to pull data change out of migrations for the reasons that you said totally makes sense.

+ +

But there are often times where I want to convert from non-nullable to nullable. And in the process, I want to backfill with a given value or something to that effect. And I like to encapsulate that altogether such that if it fails or succeeds, it's transactionally consistent. And I do wonder, could I wrap a test around that? I don't know of a way, and I think it may actually be the Rails testing infrastructure is just like no, we prepare your schema for you in the background, so it's just up to date. And therefore, you don't even have a way to be in a state where the migration hasn't run. But it's an intriguing one.

+ +

STEPH: Yeah, that's probably a hard absolute that I said where you can't test it, and I'm sure there is a way to test it. How friendly or how easy that is to do, I'm really not sure of. It also feels like one of those areas where it feels like I'm testing this other service that I should trust fully, so then I'm not necessarily testing the migration itself. I'm testing some logic that I've added inside of the migration where I'm changing some data. And the example that you provided is perfect because that's one of those that I'm inclined to include in a migration. It's more like where we want specific users who have this value or in this category. And then, we want to migrate them from this data to the other data. And when we start getting complicated in our migrations, that's when I'm like, this is a bit much, and I'd really like a test that documents that we're doing this correctly. That's where I get squeamish about having data changes in migrations. But you do raise a good point. I don't know; I’ve never tried to test one. I've just always reached for this other approach, but that is more the pain point of if I could test this data change inside of migration, then that would work for me. That would solve my problem.

+ +

CHRIS: I wonder if an alternative approach would be to just introduce an object or a class that does this work. So like a command object as it were, to do a call back to earlier in the episode, that does that data transformation because it’s exactly what you're describing, for this subset of users do this. But if they're in this state, then do these things and create two new records for any user like this. That sort of stuff is really complicated. Definitely want to have some tests around it. But you're talking about a gem that allows you to extract it into a Rake task-like situation. But I wonder, could we just have a class for that?

+ +

And I used to be a big believer in your migration should live forever, and they should always be runnable from the beginning of time. I've given up on that belief. That's one of the things that I've been like; I don't know. It turns out I've never done that. It's not an important thing. Just DB schema load is going to be fine most of the time. It's great for the past ten migrations to be around just to tell a little bit of a story. But I'm not tied to migrations being runnable forever. So the idea of you introduce this class, it encapsulates that data transformation. You can test it because it's its own thing. It will still be run within the context of the transaction of the migration. And then you throw it away down the road along with the migration, and you do that migration roll-up thing. It's just a different thought there, although I do like the...well, I guess that would also run automatically, but that runs as part of the deploy as opposed to after the deploy, which is meaningfully different than what after_party does because there might be one of these migrations that takes a long, long time to run because you've got a ton of data. And you want to decouple it from the true deploy release sequence that happens and the time limits that are there. So I think I've now talked myself in three circles, and I'm going to stop.

+ +

STEPH: I like how you highlighted that part where it does decouple you from the deploy process where it's still automated; it runs afterwards. But say if it's something that doesn't need to hold up the deploy, you don't need to wait for this data to be migrated before the deploy can go out. Then that's a nice separation because then it can happen afterwards. Or if you do need it to happen part of the deploy, yeah, there's lots of interesting bits there. I feel like you and I could talk about it for a while.

+ +

But we have a listener question that I'm really excited for us to talk about. So I'm going to hard pivot over to our listener question. This question comes from Jonathan. And Jonathan wrote in, "Hey, gang, longtime listener, first-time emailer. I've heard you reference retrospectives a few times as part of your normal development practice. In my limited experience with them, I often find retrospectives don't feel productive because team members are reluctant to raise issues without seeming critical or blaming another team member. I would love to hear you describe how you typically run retrospectives to foster open discussion and make it a productive use of time. Bonus points," oh, I love bonus points "if either of you have experienced rescuing an existing team that was not having productive retrospectives. P.S. Thank you for ongoing participation in the Ruby and Rails communities. I look forward to seeing a new episode pop into my podcatcher each week."

+ +

All right, retrospectives. I love this question because I've definitely been part of teams that are really struggling to have a productive retro. So I think it would be helpful, as Jonathan highlighted, to go ahead and share how thoughtbot runs a retro. And then I'd also love to touch on some of the areas where I have seen teams really struggle to have a productive retro. So with the thoughtbot format, there are really two questions that we focus on. The first question is, what went well? And this starts the meeting on a positive note, which can help people get engaged before then we move on to heavier topics like concerns and issues.

+ +

When we run a retro, we ask each person these two questions. So that first question, we go around to the room, and we say, "Hey, what went well for your week or for your last two weeks?" And then we document all of those positive things that people say. The next question is, "What concerns do you have, or what are you worried about?"And the goal here is to highlight issues early, which then gives us the chance to address them as they come up rather than waiting till an issue has grown out of control. And it's usually during the concerns portion that I often see retrospectives fall apart. The reason for that is hearing someone describing a concern is often something that can stir up a lot of emotions. And I know for me, it certainly triggers my instinct to where I really want to dive into that issue, and then I want to solve it.

+ +

But by reacting to a specific issue and then trying to solve that issue, I'm interrupting that retrospective flow to then focus on that issue. And we may not get to a bunch of other important issues that people had. So that's often where I see retrospectives fall apart. And the way to fix that is to then have the team consensus that hey, this is a space where everybody gets to air concern. We're going to go around the room, so everybody has a chance to speak. We're going to document it, but then we're going to move on and then come back to this later.

+ +

So when do we talk about concerns? So once everybody's had a chance to share their concern and that's been documented, during that process, you're often upvoting other concerns. So someone may bring up a concern that I also have as well. So when it's my turn to speak, I'll say, "I'd like to plus-one that particular concern," and then maybe add my own or just plus-one some of the others. So then, by the time that everybody's had a chance to speak, you already have an idea on…whoever's taking notes or if it's being ideally shared so the whole team can see. You can already see the concerns that most of the team is identifying with or that are the more popular concerns. So then, as a team, you can say, "Hey, we're going to focus on the top two concerns because that's really the amount of time that we have," and that way, we're focusing on concerns that impact the majority of the team. So at that point, then we can start talking about those specific issues and how we'd like to address them.

+ +

And then out of that conversation is then the next part of the retro format, our action items. And then action items are where we can capture the things that we would like to try during our next iteration of work until our next retro. This is our experiment area. So then we can say, "Yes, we'd like to try something different, or we'd really like to monitor how this goes."

+ +

And then one other fun thing that I typically include in retros are housekeeping. So then we can talk about time off, team celebratory events, anything like that that's helpful to highlight to the team.

+ +

That's a quick overview of how typically I myself run a retro. Chris, do you have anything you'd like to add or anything that I've missed?

+ +

CHRIS: No. I think that that mirrors pretty well the best retros that I've been a part of. There are a couple of things that I think I would add or emphasize in that. So one is foundationally, with a retro, what are we doing? What's the goal? And the goal with a retro is to identify and evolve our process. So identify where there are any bottlenecks or things that aren't working, and then ideally change things over time. I've been on many teams where just the same issues get brought up over and over in retro, and nothing changes. And that will just completely deflate the team. And so, if that is happening, that's a fundamental thing that we need to fix.

+ +

And I can totally understand folks being like, "Retro is awful. We just sit down and say the same things, and then nothing ever changes." If that's happening, we have to fix that at a more fundamental level. That is going to be more than a retro’s worth of effort. But ideally, retro is now this structured space each week, each iteration, whatever it is where we are discussing what's going on and ideally, slowly, incrementally making the process slightly better. In my experience, it's something that I really love because I come to associate it with stuff is going to get better now. That's what retro means. If that's not the feeling you have, then I totally get why you wouldn't want retro. But I promise that that can be a reality.

+ +

And then to touch on some of the particular procedural points, everything you said definitely maps. And I've found that structure works really well, but there's a lot of subtle things in that structure that I think are important to highlight. So one, going around the room and actually asking everyone individually for their thoughts, I find to be so useful because it's very easy for one or two more vocal individuals to just dominate the conversation. So particularly by starting with what went well and then also by actually going around the room and requesting "Everyone reply to this question please," even if it's just like, "Yeah, you know what? It just felt like a good week." That's an answer we'll accept but ideally, a little more structure or a little more meat to it. But I find that to be really important.

+ +

Likewise, I have found that having a facilitator, so someone who is guiding the retro but not actually a part of it. They're not going to be saying what went well or what didn't go well. They are just directing the conversation and somewhat critical as you're going around and asking for concerns. They are the person whose job it is to prevent the team from starting to try and address the concern when it's first voiced. So ideally, we're just collecting the concerns. We're collecting the plus-ones so that we know which are the more prominent ones, and then we can focus on those.

+ +

And I think that idea of the plus-oneing of concerns and then really focusing on the ones that have more folks that are concerned about it feels really critical in my mind. So ideally, we are a team. We're working as a team, and if one person has this gripe that they really feel deeply, but nobody else really cares about it; ideally, we find a way to help that person not feel that way. But that's not necessarily where the team collectively should put all of their energy. So yeah, that's a bunch of little pieces.

+ +

Also, just as a note, we'll include these in the show notes, but there are a couple of previous episodes, so Episode 132: “What Went Well?” is a discussion between Derek and Sage, previous hosts of the show, talking about retros. Episode 172: “What I Believe About Software” was the first guest visit by a certain Steph Viccari. And so that is a wonderful episode in which we dug into retro because it's one of our favorite topics. Also, Episode 299: “Is Agile Over?” We definitely touched on...that was a pretty recent one, but we touched on retro. Then there's also a video on Upcase called “Running a Retrospective” that basically describes exactly this process and shows actually an example retro and running through it. So there are lots of other things that we can point out here. But again, I think fundamentally, what are we doing, and how are we doing it? If we can answer those questions well, retro is going to be great. If not, it's probably not going to be that great.

+ +

STEPH: I appreciate you calling out all of those important nuances because those nuances are what lead to then a retro feeling more productive. And to address Jonathan's other question around if people are feeling timid to bring up an issue because they don't want to blame anyone, then I think to address that one; specifically, you have to come to retro with a WE mindset. And I think HBO accidentally sending a test email is a really good example of that. Because in the Twitter thread, a bunch of other I presume developers were commenting and responding in support of the person that sent that out to say, "Hey, you discovered a missing safety net in the system," or the fact that it was fairly easy to make this mistake and send it out. So if you come to retro with this mindset of if a mistake was made, how can we as a team improve this so then it's less easy to make that mistake? Then you won't have the sense of we're blaming this on one person, but instead, we as a team are responsible for helping each other out.

+ +

CHRIS: It's interesting to have that conversation in the context of retro because I don't necessarily think of retro in exactly this way. But there is the idea of blameless postmortems, which come out of the Google Site Reliability Engineering; I think it's a book, maybe it's a website. We can include a link regardless. But that idea of blameless postmortems of collectively as a team, this thing made it out into the world, this bug, this problem. So we need to own that as a team, and we need to have a blameless conversation around that, just talking about what happened. And there are subtleties there. And that's a nuanced idea that needs to be evolved, but that is at least some writing that exists in the world that talks specifically to that part of it. That said, I wonder if a true postmortem, so a distinct meeting just dedicated to those more pointed issues, might be more relevant, and then retro is more of a shared overall conversation. But if there are smaller versions of that, then I think using that framing could be really helpful in retro.

+ +

STEPH: Yeah, I think you said that perfectly where there needs to be team ownership over all of the issues that are being discussed. And I think there is one other very tricky area to navigate with having a productive retro. And I don't know of a better way to say this. But you have a grumpy goose on your team. You have someone who doesn't like retros, and they're going to be negative, and they're going to be vocal. And that is a hard one. I have been there before. And I often approach that situation by speaking with them specifically around what are your concerns with retro? Are you willing to at least buy-in and give this new format a chance? But you essentially need them to buy in or have leadership buy-in so then they know to follow suit as well that this is a team process that we're going to improve and work on together. And if you don't like it, then that's what retro is for. So how we can make this a better, more productive meeting? But just showing up and being grumpy isn't helpful. And then helping people who have been burned by retros overcome that negative reaction to retros is something that takes time.

+ +

CHRIS: Oh yeah. The grumpy goose just affects everything on the team. But definitely retro is one where I've seen that particularly pointed. I think in those cases, the best luck I've ever had is to, like you said, have a separate conversation but have the conversation at a higher level. So the question isn't about do we have retro or do we have it in this shape? The question is, do we think we are operating at our best? Do we think everything is going perfectly? And almost never will the answer be "Yeah, this is great. We have no bugs. We're moving as fast as we possibly can. Everyone is happy. No one is burnt out." And so if we get to an agreement that is like, well, yeah, sure, there are things that we could improve, then I think that's a toehold that we can then build on and say, "Okay, so how do you want to go about that?

+ +

I am fine to explore a different approach than retro as a meeting to continually improving and evolving our process. I'd love to know what thoughts you have, Mr. Goose." But if they don't have an alternative, retro is the most effective structure that I've found for this continuous feedback loop around the process. I'm very happy to find an alternative, but I critically think we need something like that. And so if they're going to be pushing back on retro specifically, then I'll bump up to the higher level and say, "Okay, how do you want to be improving our process? Let's try something else, but let's make sure we are asking the question of how do we improve our process and is that succeeding?" And also, stop being so grumpy. Come on, what are you doing?

+ +

STEPH: [chuckles] I recognize that approach so much because then it really gets to the heart of the purpose of retro whether it's actually called retro or how we handle it is not significant, but the fact that we together as a team can get together and discuss how to improve. That's really the important thing that we're after. And retro just happens to be the format that I use and really enjoy. But like you said, it's always open to each team's interpretation.

+ +

On that note, Jonathan, I hope this quick overview of the thoughtbot retro has been helpful. And we will also include some other links that also highlight how thoughtbot runs retros and some other discussions that we've had about retrospectives. But on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Chris gives a DB sessions update and talks bifunctors & command objects. Steph shares the coolness of a gem she's been using called after_party, and excitedly gushes about her new laptop. (Chris is hoping to hold off on replacing his until the end of the year and then they can compare!)

+ +

The two then answer a listener question on retrospectives and how they've seen productive ones run, while giving some of their own helpful opinions on dos and don'ts. They're talking to you, Grumpy Goose!

+ + + +

Transcript:

+ +

STEPH: Cool.

+ +

[laughter]

+ +

CHRIS: Good. No, I like what you did there.

+ +

STEPH: Yeah, I feel like we can get rambling on that one.

+ +

CHRIS: It's been great. This is what the Bike Shed is at its best. It's the two of us just rambling and being like, well, what about this? And if it's this, then that, then these, and it depends. And it's complicated and it's nuanced. And what about the humans? That's the story of The Bike Shed right there. [laughs]

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm CHRIS Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, how's your week?

+ +

CHRIS: My week has been good. I have some updates actually on some topics from previous episodes. One of the things that I can update on is the discussion around the cookie versus the database store. So I had posed this as a thing that I was going to be doing in the app for a handful of reasons. Most notably, I wanted the ability to invalidate sessions from the server-side, wanted to have a little more control over that. And so that's a dream that the database-backed session store can do. Eventually, I have to make that actually work in the way that I want.

+ +

But I was asking the question in that episode, which we can include a link to the specific episode, but I was asking the question of why don't we just do this all the time? The database-backed sessions seem better in all these ways. It's a lower overhead per request because you're just sending the session ID and the cookie instead of the whole payload of the session. You actually can have more data stored in it, a bunch of things that seemed really great. And then right after I introduced it, I figured out the thing. I figured out the secret. It's not a big issue, and we're going to stick with database session stores. But we have to be purposeful because it turns out they are essentially plain text in the database.

+ +

And so if there's anything that you are putting into the session like say a social security number or an authentication token or other things which naturally I might have done if it was in a cookie that lives on the user's browser and never actually lives on the server, persists on the server, that seems fine to me. But now these things are getting stored in the database and that really changes the calculus, especially because if I'm not purposeful, they'll just stick around for forever. So social security is probably the most pointed example of this. If you happen to have a form in the app that accepts a social security number and you want that to persist through some number of other steps, not actually going to store the social security number in the database because that's a thing that I have actively chosen not to do. I need to send it off to some other system, but I do need to hold onto it for a few minutes. The session is a perfect place to put that unless the session gets stored in my database.

+ +

STEPH: That's such a great point. I'm so glad you discovered that. And in our recent conversation, we were trying to think of the reasons why this isn't the default case. You may be headed in this direction, but this may also be timely, the fact that you're discovering this issue but also the fact that Rail 6.0 now has encrypted columns. Is that where you're headed with the fact that you can still keep session data in a database?

+ +

CHRIS: That is a great question, and it is an intriguing option. But it's not the one that I'm going with here. I think broadly, my hope is to completely avoid ever persisting this data in the database, this truly sensitive user-specific PII or PCI or social security numbers or any of these other fancy acronyms that get collected together under the umbrella of I probably don't want that on my server. For those, I'm just opting to push them back into a cookie. So I'm using particularly a...In rails, it's fun because they have a fluent interface where you can just chain together things, so it's cookies.signed.encrypted.whatever, and then you go from there. But I'm using signed, encrypted cookie, which is essentially what the session store views; the cookie session store uses itself.

+ +

So I'm basically reverting to the old session store behavior for specific values. So anything that is truly sensitive like that, I'm just saying, cool, that's actually just going to live in a cookie, and that will be it, but not leaning on the ability to encrypt the database sessions. There's just enough subtlety around that. There's so much volume of data if I do allow that sensitive data into the system that any failure, any exploit that happens, would be somewhat catastrophic. So, in my mind, this lowers the surface area and says, yeah, this data really never lives on the server. It comes with a request, and then it's gone after the fact. And that's the world I want to live in.

+ +

STEPH: Yeah, that's super interesting. You're also raising questions for me that I hadn't considered when we originally had this conversation where there's necessity or that you're looking to store form data or sensitive data in that session as well. So that makes a lot of sense to me that for that type of behavior, we're going to separate that from the idea of authentication and the user session and still use encrypted cookies for those details. So it only stays with the user's browser, but then the actual authentication of a user that part could still live in the database.

+ +

CHRIS: It is ending up being a weird Venn diagram of; this is data that I want to stick around but only sometimes and particular to the machine that the user is interacting with because the session is still associated with a cookie at the end of the day. So a user may have multiple sessions in the database-backed session version. It is somewhat interesting, and I'm going to see how it develops over time. But yeah, at a minimum, I have now found this edge case of like, ooh, okay, sensitive data, that's a thing, which is one of the reasons that I would reach for the session inherently. So it turns out, as always, it depends. Things are complicated.

+ +

STEPH: It's a nice update. I like when we have closure to a question like that, especially so quickly.

+ +

CHRIS: Love to provide that continuity. It's what I'm all about. But yeah, what's up in your world?

+ +

STEPH: What's up in my world? I am excited that I have a new laptop. So I have been using a MacBook Pro for about the last...it's lasted me for a while. I think I've had it for a good four, four, and a half years, but that's on the fritz. The keyboard, in particular, the keys are popping off, and that's something that I could go get fixed. But I'm at the point that I need a new laptop. So I have a brand new shiny laptop. And I had the option to either go with a 16-inch MacBook Pro or to go with one of the new, fancy laptops that has the M1 chip. And I was torn for a little while because having the M1 chip sounds really cool and novel, and there's a lot of speed improvements that come with that.

+ +

But I ended up going with just the 16-inch MacBook Pro; specifically, one, it's still very fast. It's very reliable. I can use this as my work machine and just know everything's going to work. That part feels really important to me. And then also the screen size is important. So any Mac laptop that is using the new M1 chip, I think they only go up to a 13-inch, right now, screen size. And I really want the 16-inch in case I am traveling, so I have that larger desktop. But I did do some research into the M1 just because I know about it. I know it's out there. I know it's hot. People are interested in it, but I didn't know a whole lot about it. So for anyone else that's like me and is curious about what the heck this M1 chip is, it's essentially Apple's foray into making their own processors.

+ +

So traditionally, their machines have used Intel CPUs and third-party graphic processors, and other parts. And this introduction of the M1 chip really represents Apple's switch to having their own internal architecture rather than relying on those third-party parts. And it also means that all those features that were sourced from other parties like the CPU and its security are now being combined into a single chip, which has also led to some performance improvements. And while I was reading about the M1, there's a lot to go through, but the thing that stood out to me was this idea of Apple's Neural Engine. And I thought, well, that sounds super fancy. What is that? Are you familiar with Apple's Neural Engine? Have you read about that?

+ +

CHRIS: I don't think I am. What all is that?

+ +

STEPH: Yeah, good question. That was a question I was asking myself just recently. So essentially, their neural engine it's a microprocessor that specializes in the acceleration of machine learning algorithms. So it's really similar to how a GPU will focus on accelerating graphics rendering. And their neural engine or neural engines in general then focus on accelerating neural network operations. And the inclusion of a neural engine isn't something that's new because Apple introduced this into iPhones and iPads back in 2017 to support their features like Face ID and emoji, searching for photos with dog pictures. Siri speech recognition is also one that's using this engine and other machine learning tasks.

+ +

But the sparkly stat that Apple is sharing with this new design is it's a 16-core design that can perform 11 trillion operations per second, which sounds very fancy, very fast. But it really got me thinking about how companies are working to improve, not just laptops but also our mobile devices to run machine learning software more efficiently, and then how that's just going to evolve and change all the different features that we use, and then how developers can integrate with this engine. I think currently, Apple hasn't shared much information about how this engine works, but I think they've exposed a few developer tools so people can still build features that will then use the power of this faster, improved neural engine.

+ +

CHRIS: Oh, that's super interesting. I have still not really delved into machine learning or artificial intelligence, or any of that stuff in any real way. But it's one of those things like the number of mentions is ticking up. And at some point, I'm like; I probably have to pay attention to this, don't I? I'm still in the not paying attention to it camp. So if I'm understanding, though, you just described this wonderful feature, but you opted for the machine that does not have all the fancy stuff. You did not...

+ +

STEPH: Exactly. [laughs]

+ +

CHRIS: Okay, yeah.

+ +

STEPH: Yes, it would have been nice. That would have been neat, but yeah, I needed a machine with a larger screen, all those good things. And that's still really fast, for the record.

+ +

CHRIS: Oh yeah. I'm desperately hoping to make it to the end of this year. This is going to be a bit of a rumor mill here, but my understanding is the expectation is that Apple is going to release a 14-inch MacBook Pro with the M1 and the return of MagSafe, and the removal of the touch bar. And that sounds like my dream machine right there. I want that piece of hardware.

+ +

I also seem to care a little bit less about the size of the laptop screen. I'm so often working at my desk with a large-format monitor that I'm connected to. And so, when I'm on the road, I want to optimize for portability when I'm traveling because I do it so rarely, and then I'm hopefully focusing on travel at that point. But we'll see if that remains true as the shape of my work changes and I start to not only work from home. And maybe I'll actually change my tune on that. But for now, that's my hope is to make it to that machine and then get one, and that it exists because right now, those are all rumors.

+ +

STEPH: Well, I totally support this goal of yours. So that way, you can have that new-new, and then you can report back on what it's like, and then we can compare. Because I'll have the other version, the Intel CPU, and then you'll have the M1 chip, and we can see how our lives are different.

+ +

CHRIS: You'll have the new, and I'll have the new-new, and that's how we'll categorize them.

+ +

STEPH: [laughs] But yeah, I'm very much looking forward. Having a new laptop is always just such a fun feeling. It's just a clean space that I get to rebuild. It's like going through and prioritizing; what are the things that still spark joy? And then I get to only port over the stuff that I still really use all the time and want to keep. So I'm looking forward to getting it set up.

+ +

CHRIS: I need to do that sometime soon. I'm like five years deep, at least on this machine. So I've been dragging along. Also, the hard drive is just completely full, and I regularly have to go through and delete things before we start recording because it turns out these audio recordings start as very large files. [chuckle] So it's almost a weekly thing where I'm just like, got to throw something out today. I don't know what. It's fine. I'm going to be fine. [laughter] I'm going to make it to the end of the year, and it's going to be great.

+ +

STEPH: What else is going on in your world?

+ +

CHRIS: Well, I wrote some fancy code, and I use fancy not necessarily as a good word. [chuckle] So I'm intrigued that the code could be described perhaps as clever or other words like that, which I think are very complicated words in the coding space. I tend to try and avoid this type of coding where I'm trying to introduce abstractions and clean things up, and remove duplication because I've been burned by that so many times in the past. But this time, I think maybe this time it'll work.

+ +

So, in particular, there are two different areas of the application. There were two sets of refactorings, but they really went together. One is we have the idea of command objects within the application that we're working on. So there are a lot of cases where we need to save something to the database and then communicate something to an external API. And then presuming the results of that is a successful response from them, then unpack some data, make sure it's in the right shape, and then save something else to the database. And ideally, wrap that all in a transaction and keep everything together and then return some data at the end of it.

+ +

So that whole sequential operation, I've been using dry-monads to model that. I've talked about this on a few previous episodes. I'm really enjoying it. The more I lean into it, the more I find that it is just a really great way to wrap up that very procedural code. But ideally, do it in almost a functional way so that we've got these sequential operations that feed into each other. There's the railway-oriented programming stuff, which is associated with this idea.

+ +

But there is a lot of boilerplate to these objects. So the way we've defined them is they have a class method called run that takes whatever the arguments are, and then it needs to pass those arguments into the initialize and then call run on the instance. So in order to define one of these objects, what we had been doing was def self.run and then all the arguments. And then inside of the body of that, it's new, and then pass forward all the arguments .run, and then define initialize to capture all of those and set all the instance variables, and then define the run method, which actually does stuff. Also need to define an Adder reader for all of those instance variables, which is a thing that I enjoy doing. So that's the interface I want, or that's the way that I want this class to work. I know other folks in the Ruby world feel differently. But that's the shape of the thing that I want, but that's a lot.

+ +

And there's also I regularly would find myself forgetting to duplicate something that we put into the class method run interface into the initialize method. And it was just like, this is all just wiring up and plumbing. There's also the binding of the dry-monads do notation for the run method as well as the inclusion of the results type within dry-monads. Type is a strong word, but that gives us the success or the failure objects that we can create. So ideally, all of these command objects either return a success object or return a failure object. It's one of the two. And that's one of the things that I really like about them. But yeah, so much plumbing.

+ +

So we define a base command, and the base command has the self.run method, the class method, and that method is defined very abstractly. So it's just args * keyword args. So we're capturing all of the arguments and then forwarding them on to new. So that way, I don't have to think about that interface. It basically just says, "Give me anything, and I'll forward it onto new." And the new or initialize is in charge of actually defining things. It also includes the result type. It includes the macro annotation for the run method, which is how dry-monads does its magic, that actually I had to include inline within the self.run, just because of the sequence of definition and the metaprogramming that's going on there. As I said, that sentence terrifies me a little bit, but hopefully, no one ever needs to look at this magic base class [chuckles] and figure anything out. So that was one part of it. That cleaned a lot of things up, so that meant I didn't have to write a ton of the wiring up code.

+ +

Then there was still the noise of actually defining all of the arguments to these classes. They often take a handful of arguments because that's their job is to grab a bunch of things and do some work with those things. So for that, I have brought Adder Extras, which is a gem that I've talked about probably in previous episodes, I think so. But this is the first time that I've really leaned into it and used it. And it gives some very high level what look like macros are just class methods. But the one that I'm using is Adder private initialize, and that you can then pass a variety of values too. And it will then say, okay, this method accepts a required keyword arg, a defaulted keyword arg, and a positional argument or something to that effect. But it's a very, very concise way to express that and then also get the private Adder readers, which again is the direction that I want to go with all of this.

+ +

So that’s a bunch of things that I have said. But all total, it cleaned up these command objects very nicely. And now, when you look at one of these command objects, all you see is the run method that does the work. And the plumbing and the wiring up behind the scenes should just happen. I am concerned about the day that someone forgets to inherit from the space command, and then it's like, why does nothing work? I thought command objects just worked in the system. But we're going to deal with that when we get there, which is hopefully a while down the road.

+ +

STEPH: I like how you're pushing at the boundaries of our comfort zone. I say our comfort zone because I imagine we feel similar.

+ +

CHRIS: It is. We definitely got a shared comfort zone. [laughter]

+ +

STEPH: Yeah, we have a shared comfort zone with inheritance, but you're pushing at that boundary of that comfort with inheritance because it is something that can be so painful. But you've identified an area where inheritance feels useful. And then it also sounds like a very meaningful...you're introducing this pattern and then trying to make it easier for others to follow this pattern. So it's a very intentional design decision of where we want to group these behaviors together and then make it very easy for other developers to then pick up this pattern and run with it, and then also work with these classes. So I am intrigued to hear how it goes and how others feel about the pattern as well.

+ +

I also wonder, this is one of those areas where it feels like this very intentional design decision. Is it something that you think in the base class would be worth highlighting? Like, hey, here are the things that we are using in this base class. This is the intention of this base class. I don't know if that's maybe a comment or if that's something that's documented in the README. I know; I see your eyebrows went up when I said comment. But it does feel like one of those areas where it's like, hey, we have introduced this new concept. We want you to follow along. Here are some helpful guidelines.

+ +

CHRIS: Those were mostly joking eyebrow raises because I have thought of that. I haven't actually gone to that level. But in the back of my mind, there's this pattern that we have within this application. Ideally, we're going to lean into it more and more so that A, we have a clear way that we do things within the app but also make that as understandable and discoverable as possible. I'm not sure if a comment in the class is the right thing or...so I'm deferring what I want to do on that for now because right now, it's myself and one other developer. We sort of developed this in tandem. So we were working together on it. We would pair in a bunch of the features. And what we have now is the crystallization of what we found useful. And we're both very comfortable with it. So there isn't the need to explain it.

+ +

I'm almost thinking about it as just-in-time educational content around this piece of our application. I don't actually trust that I would do a good job describing it in the abstract because I know it. Like, to me, this thing makes sense right now. But I've been on the other side of stuff where someone was like, "Hey, this totally makes sense." And I'm like, "I don't know any of the words you just said," and so I felt that pain being on the other side. You could say I'm just being lazy, but I do think this is a purposeful delaying of that where I want to wait until I actually have someone to teach this to. And at that moment, I want to see what that conversation looks like. And I'll try and explain it to the best of my ability, but I'm sure they're going to ask questions, and I'll be like, "Oh, wow. Yeah. I hadn't even thought of that. But now that you ask the question, totally let me explain this part that I was going to gloss over and forget to mention."

+ +

And so, ideally, that is what will happen down the road. And then from that, hopefully, some artifact becomes clear, whether it's a documentation page in the repo or a comment in the class if it's simple enough or maybe even it's a recording of a pairing session. And that's the artifact that we keep around that explains this piece of the application. So I definitely think a version of that makes sense, but I am not doing it yet.

+ +

STEPH: It's funny; you’re saying so many good things that I agree with. I love the just-in-time education; that part is fun. And yeah, there's a part of me that definitely still leans into the idea because we've talked about this in the past too, where we write down, in the moment, the things. Having that context when we're implementing it is really important and helpful. So even if it's not this grand explanation…which I really like what you said around having someone to explain it to or have that conversation with so that way you're documenting the useful bits, that part I like very much, but capturing the intent as soon as the change was introduced. So even if it is a very high level like, hey, we are using dry-monads and Adder Extras, even if it's just links to those things, that's something that I think I would still favor just to go ahead and start surfacing this is a pattern. This is a choice. And then, as you continue to work with the pattern, if you change your mind, it's still very easy to scrap that documentation.

+ +

So I think if it were me, I would still go ahead and document it. I think it's that piece about discoverability that's calling to me so strongly where that's where I want to then highlight the things that are in use. So even if there's not an explanation, people can find the resources very easily. Because you're right, you did say a lot of interesting bits in describing this pattern. And the fact that we're talking about it now also just deepens my suspicion that it would be nice to comment somewhere, and perhaps a repo is a perfect place for it and just get it out there, and then it can always be revisited later and improved.

+ +

CHRIS: Okay. I like that you are keeping me honest on this because I do think there's a certain amount that I'm just being lazy here and not wanting to do that because it is actually really hard to try and document something like this. Like, what are the important pieces versus what are the extraneous details that people don't actually need?

+ +

I do wonder, so the pull request that did this refactoring and introduced this base command object that does have the explanation captures the point in time and whatnot. And so I wonder, is there a version of tagging important pull requests that tell the story of the application? A lot of things are just going to be like; this is adding a feature. It's the same as the other 30 pull requests recently that added a new feature. But this one is special from an architecture perspective. And so let's tag this, let's add a label. I don't know what it is but something that allows for discoverability of the story of how this application became what it is today because anything else I worry will go out of date almost instantly. But this pull request is true fundamentally in that same way that we say commit messages should capture as much of that detail.

+ +

So I did do that writing for the pull requests/the commit message. And I wonder if maybe that's the best artifact for this moment but then the question of surfacing it and making it discoverable because otherwise, it's just lost in the sea of other pull requests. So I don't know. But I do like the slight push back that you're giving me here of like, yeah, but what if you did something though? And I'm like, yeah, that's fair. I should probably do something.

+ +

STEPH: Being able to pin those specific PRs that have significant architecture changes sounds really novel, but I'm going to take this opportunity for me to be lazy. And if I'm joining a project, I don't want to read through what has happened. I just want to know what's true now. And if I go back and look at those PRs, I won't know if all of that is still relevant and how it's changed. So it sounds neat from telling the story of how an application has evolved. I like that sort of developer lens, and what are the things that we have tried and then changed over the years? But from I am onboarding to this application, I just want to know what's true today? What are the things that you want me to follow? What are the patterns that are going to be really helpful for me to look at? And so then, I don't know if I would use it in that context.

+ +

And this may be one of those areas where I'm feeling overly skittish in response to the number of things that you said and the use of inheritance. Because I have felt so much pain of where I'm going up the tree to figure out what the heck is happening in the world and then to understand all of those pieces, and then swimming all the way back down to the class that I'm actually working in. So it could just be past experiences that are now influencing how I want to document or work with inheritance. It probably is. [chuckles] That's probably a big factor of it. It doesn't mean I disagree with it because those painful experiences are meaningful. [chuckles]

+ +

CHRIS: Yeah. I think the foundational thing...I tried to start this with the context of like; I did a thing. This is another example of good idea, terrible idea; my favorite segment on The Bike Shed. I stand by it. I think it was useful. It does use things that we have traditionally moved away from. I say we because, again, I think we have a shared approach to development at this point. But I think it's worth it. I hear everything that you're saying about the documentation, but I've been burned by that so many times where the documentation is like, here's what's true now. And you're like, no, there isn't even a class called that anymore, and no less does it work that way. And so, my inclination is not to go that way.

+ +

The solution that I have in mind is when someone is onboarding into the application, I don't expect there to be documentation and other things that I can hand them so that they can run. I expect to sit down with them and work with them. I'm going to pair with people when they join a team for a long time. There's a period where that's true, I think, and then you get to a certain size of an organization, and you're onboarding enough people regularly enough that that's a thing that you should get better at.

+ +

But for I think a surprisingly long time, my answer I'm more than happy for it to be, yeah, we're bringing someone new into the team. Let's sit down with them. Let's spend the time. Let's tell them what's true because I know currently, and I can give them an up-to-date version of that. And ideally, as part of that, then update the static documentation, the repo, the README, the other things based on the conversation that we have and recognize oh, that that link is very out of date. Let me change that one real quick. But I'm not expecting to have comprehensive documentation for that. I'm expecting to use real human interaction to fill that gap.

+ +

STEPH: Yeah, I really like that you're also calling out how fallible documentation is and how it has misled us so many times. I also love what you highlighted where when somebody new is joining the team, we are more than often going to sit with them and then explore the app together. And it just made me revisit that phrase that you used earlier about the just-in-time education. Because for this command object, you may join the project and not need to interact with this design pattern for your first couple of weeks, first couple months, who knows?

+ +

So then it comes back to the idea of how when someone is in the space of where using a command object feels like the right approach, then how do we introduce them to this pattern and then make sure that they have the tools that they need? And if someone is accessible to then sit down and go with them, that's great. But if someone is not accessible, then I still want them to have at least a few of the resources that they need to dive into some of the more complex things that are being included. So, yeah, it's a tricky one. I like this thought experiment.

+ +

CHRIS: But yeah, overall, I'm happy with it for now. I'm hopeful it will work out for us moving forward, and I'm hopeful that it will also be a sufficiently discoverable or teachable thing within the application. But again, I will certainly report back and see how that one plays out for us. But yeah, that's what's up in my world. What else is going on in your world?

+ +

STEPH: Something else that's up in my world is I have pulled in a tool that I've used in the past, and I really like it. So I'd really like to talk about it here for a bit because I just find it so useful. And now that I've added it to this new project, it's just really top of mind for me. So I found that when working on a project, there are often times where I want to run something right after a deploy has happened, and I want that to be automated. I can do it manually. I can hop in, but then perhaps if you're deploying across many environments or many systems, you don't want to have to do all that manual work, or you also just want the convenience of you can set it and forget it. And that way, you know something's going to happen. So perhaps it's something where you want to change some data, or if you want to enable a feature flag, then this is really helpful.

+ +

So the gem I've been using for this is called after_party, where you can write automated deploy tasks that essentially behave very similar to migrations. So you can write a Rake task. It has a timestamp. You can implement the logic that you want to be run right after your code has deployed, and then after_party itself, we'll check the timestamp. It will see if it has been run. If it's already been run, it won't run it again. Or if you like, you can set it up so that way, you can tell after_party to say, "Hey, after every deploy, I want you to run this particular task," but it's such a nice improvement to the workflow.

+ +

And the other thing that I really like about this that I feel is a bit contentious is separating changing data outside of migrations. So I am a big fan of migrations are focused on changing your schema itself. But if there's actual data that you need to change, I really like when that is separated outside of the migration. There are definitely times that I understand it's really nice to just do it all at once, and it's easier. But anytime it starts to get even a little complex, I immediately want to write tests for it. And I can't test my migration. But if I'm changing some meaningful data on production, I want tests to back it up to make sure that I'm scoping correctly, that the outcome is exactly what I expect. It also makes it easier for other people to review. And after_party gives me that functionality so then I can have my migration.

+ +

But then I'm like, oh yeah, but I still want to automate changing this data because that's often one of the complaints that I hear from people when I do ask them to separate into a Rake task, changing the data. They're like, "But I don't want to have to then follow up and then run this task later." And I'm like, that's cool. After_party has you, and you can automate it and not worry about it. So after_party has been one of my favorite gems to add to applications.

+ +

CHRIS: That's interesting. There's a bunch of layers to everything that you just said. I think I've worked with after_party on a project. I think we were working together on that project, if I'm remembering correctly. I have no bad memories of it, which given the nature of the tool, makes me think it did its job very well because its whole point is just like, oh cool, now you can just do this thing, and you don't even really have to think about it. Because there are plenty of other times where I've had to orchestrate or do a deploy. And then I SSH tunnel into production, which is a bad idea, and then I'm running Rake tasks manually. And so, I think the fact that I don't have any pointed memories of this is a really good sign for a tool like this. So that's a weird vote in its corner for me.

+ +

You did say something that was interesting that I want to poke at a tiny bit which was you can't test migrations, and I think that's true. Like, I don't know of any way. And it feels like a thing that is sort of fundamentally deeply true. But I do wonder, is there any gem out there? Has anyone done a weird science experiment to figure out like, I would actually really like to be able to test my migrations? So I think the idea of having to pull data change out of migrations for the reasons that you said totally makes sense.

+ +

But there are often times where I want to convert from non-nullable to nullable. And in the process, I want to backfill with a given value or something to that effect. And I like to encapsulate that altogether such that if it fails or succeeds, it's transactionally consistent. And I do wonder, could I wrap a test around that? I don't know of a way, and I think it may actually be the Rails testing infrastructure is just like no, we prepare your schema for you in the background, so it's just up to date. And therefore, you don't even have a way to be in a state where the migration hasn't run. But it's an intriguing one.

+ +

STEPH: Yeah, that's probably a hard absolute that I said where you can't test it, and I'm sure there is a way to test it. How friendly or how easy that is to do, I'm really not sure of. It also feels like one of those areas where it feels like I'm testing this other service that I should trust fully, so then I'm not necessarily testing the migration itself. I'm testing some logic that I've added inside of the migration where I'm changing some data. And the example that you provided is perfect because that's one of those that I'm inclined to include in a migration. It's more like where we want specific users who have this value or in this category. And then, we want to migrate them from this data to the other data. And when we start getting complicated in our migrations, that's when I'm like, this is a bit much, and I'd really like a test that documents that we're doing this correctly. That's where I get squeamish about having data changes in migrations. But you do raise a good point. I don't know; I’ve never tried to test one. I've just always reached for this other approach, but that is more the pain point of if I could test this data change inside of migration, then that would work for me. That would solve my problem.

+ +

CHRIS: I wonder if an alternative approach would be to just introduce an object or a class that does this work. So like a command object as it were, to do a call back to earlier in the episode, that does that data transformation because it’s exactly what you're describing, for this subset of users do this. But if they're in this state, then do these things and create two new records for any user like this. That sort of stuff is really complicated. Definitely want to have some tests around it. But you're talking about a gem that allows you to extract it into a Rake task-like situation. But I wonder, could we just have a class for that?

+ +

And I used to be a big believer in your migration should live forever, and they should always be runnable from the beginning of time. I've given up on that belief. That's one of the things that I've been like; I don't know. It turns out I've never done that. It's not an important thing. Just DB schema load is going to be fine most of the time. It's great for the past ten migrations to be around just to tell a little bit of a story. But I'm not tied to migrations being runnable forever. So the idea of you introduce this class, it encapsulates that data transformation. You can test it because it's its own thing. It will still be run within the context of the transaction of the migration. And then you throw it away down the road along with the migration, and you do that migration roll-up thing. It's just a different thought there, although I do like the...well, I guess that would also run automatically, but that runs as part of the deploy as opposed to after the deploy, which is meaningfully different than what after_party does because there might be one of these migrations that takes a long, long time to run because you've got a ton of data. And you want to decouple it from the true deploy release sequence that happens and the time limits that are there. So I think I've now talked myself in three circles, and I'm going to stop.

+ +

STEPH: I like how you highlighted that part where it does decouple you from the deploy process where it's still automated; it runs afterwards. But say if it's something that doesn't need to hold up the deploy, you don't need to wait for this data to be migrated before the deploy can go out. Then that's a nice separation because then it can happen afterwards. Or if you do need it to happen part of the deploy, yeah, there's lots of interesting bits there. I feel like you and I could talk about it for a while.

+ +

But we have a listener question that I'm really excited for us to talk about. So I'm going to hard pivot over to our listener question. This question comes from Jonathan. And Jonathan wrote in, "Hey, gang, longtime listener, first-time emailer. I've heard you reference retrospectives a few times as part of your normal development practice. In my limited experience with them, I often find retrospectives don't feel productive because team members are reluctant to raise issues without seeming critical or blaming another team member. I would love to hear you describe how you typically run retrospectives to foster open discussion and make it a productive use of time. Bonus points," oh, I love bonus points "if either of you have experienced rescuing an existing team that was not having productive retrospectives. P.S. Thank you for ongoing participation in the Ruby and Rails communities. I look forward to seeing a new episode pop into my podcatcher each week."

+ +

All right, retrospectives. I love this question because I've definitely been part of teams that are really struggling to have a productive retro. So I think it would be helpful, as Jonathan highlighted, to go ahead and share how thoughtbot runs a retro. And then I'd also love to touch on some of the areas where I have seen teams really struggle to have a productive retro. So with the thoughtbot format, there are really two questions that we focus on. The first question is, what went well? And this starts the meeting on a positive note, which can help people get engaged before then we move on to heavier topics like concerns and issues.

+ +

When we run a retro, we ask each person these two questions. So that first question, we go around to the room, and we say, "Hey, what went well for your week or for your last two weeks?" And then we document all of those positive things that people say. The next question is, "What concerns do you have, or what are you worried about?"And the goal here is to highlight issues early, which then gives us the chance to address them as they come up rather than waiting till an issue has grown out of control. And it's usually during the concerns portion that I often see retrospectives fall apart. The reason for that is hearing someone describing a concern is often something that can stir up a lot of emotions. And I know for me, it certainly triggers my instinct to where I really want to dive into that issue, and then I want to solve it.

+ +

But by reacting to a specific issue and then trying to solve that issue, I'm interrupting that retrospective flow to then focus on that issue. And we may not get to a bunch of other important issues that people had. So that's often where I see retrospectives fall apart. And the way to fix that is to then have the team consensus that hey, this is a space where everybody gets to air concern. We're going to go around the room, so everybody has a chance to speak. We're going to document it, but then we're going to move on and then come back to this later.

+ +

So when do we talk about concerns? So once everybody's had a chance to share their concern and that's been documented, during that process, you're often upvoting other concerns. So someone may bring up a concern that I also have as well. So when it's my turn to speak, I'll say, "I'd like to plus-one that particular concern," and then maybe add my own or just plus-one some of the others. So then, by the time that everybody's had a chance to speak, you already have an idea on…whoever's taking notes or if it's being ideally shared so the whole team can see. You can already see the concerns that most of the team is identifying with or that are the more popular concerns. So then, as a team, you can say, "Hey, we're going to focus on the top two concerns because that's really the amount of time that we have," and that way, we're focusing on concerns that impact the majority of the team. So at that point, then we can start talking about those specific issues and how we'd like to address them.

+ +

And then out of that conversation is then the next part of the retro format, our action items. And then action items are where we can capture the things that we would like to try during our next iteration of work until our next retro. This is our experiment area. So then we can say, "Yes, we'd like to try something different, or we'd really like to monitor how this goes."

+ +

And then one other fun thing that I typically include in retros are housekeeping. So then we can talk about time off, team celebratory events, anything like that that's helpful to highlight to the team.

+ +

That's a quick overview of how typically I myself run a retro. Chris, do you have anything you'd like to add or anything that I've missed?

+ +

CHRIS: No. I think that that mirrors pretty well the best retros that I've been a part of. There are a couple of things that I think I would add or emphasize in that. So one is foundationally, with a retro, what are we doing? What's the goal? And the goal with a retro is to identify and evolve our process. So identify where there are any bottlenecks or things that aren't working, and then ideally change things over time. I've been on many teams where just the same issues get brought up over and over in retro, and nothing changes. And that will just completely deflate the team. And so, if that is happening, that's a fundamental thing that we need to fix.

+ +

And I can totally understand folks being like, "Retro is awful. We just sit down and say the same things, and then nothing ever changes." If that's happening, we have to fix that at a more fundamental level. That is going to be more than a retro’s worth of effort. But ideally, retro is now this structured space each week, each iteration, whatever it is where we are discussing what's going on and ideally, slowly, incrementally making the process slightly better. In my experience, it's something that I really love because I come to associate it with stuff is going to get better now. That's what retro means. If that's not the feeling you have, then I totally get why you wouldn't want retro. But I promise that that can be a reality.

+ +

And then to touch on some of the particular procedural points, everything you said definitely maps. And I've found that structure works really well, but there's a lot of subtle things in that structure that I think are important to highlight. So one, going around the room and actually asking everyone individually for their thoughts, I find to be so useful because it's very easy for one or two more vocal individuals to just dominate the conversation. So particularly by starting with what went well and then also by actually going around the room and requesting "Everyone reply to this question please," even if it's just like, "Yeah, you know what? It just felt like a good week." That's an answer we'll accept but ideally, a little more structure or a little more meat to it. But I find that to be really important.

+ +

Likewise, I have found that having a facilitator, so someone who is guiding the retro but not actually a part of it. They're not going to be saying what went well or what didn't go well. They are just directing the conversation and somewhat critical as you're going around and asking for concerns. They are the person whose job it is to prevent the team from starting to try and address the concern when it's first voiced. So ideally, we're just collecting the concerns. We're collecting the plus-ones so that we know which are the more prominent ones, and then we can focus on those.

+ +

And I think that idea of the plus-oneing of concerns and then really focusing on the ones that have more folks that are concerned about it feels really critical in my mind. So ideally, we are a team. We're working as a team, and if one person has this gripe that they really feel deeply, but nobody else really cares about it; ideally, we find a way to help that person not feel that way. But that's not necessarily where the team collectively should put all of their energy. So yeah, that's a bunch of little pieces.

+ +

Also, just as a note, we'll include these in the show notes, but there are a couple of previous episodes, so Episode 132: “What Went Well?” is a discussion between Derek and Sage, previous hosts of the show, talking about retros. Episode 172: “What I Believe About Software” was the first guest visit by a certain Steph Viccari. And so that is a wonderful episode in which we dug into retro because it's one of our favorite topics. Also, Episode 299: “Is Agile Over?” We definitely touched on...that was a pretty recent one, but we touched on retro. Then there's also a video on Upcase called “Running a Retrospective” that basically describes exactly this process and shows actually an example retro and running through it. So there are lots of other things that we can point out here. But again, I think fundamentally, what are we doing, and how are we doing it? If we can answer those questions well, retro is going to be great. If not, it's probably not going to be that great.

+ +

STEPH: I appreciate you calling out all of those important nuances because those nuances are what lead to then a retro feeling more productive. And to address Jonathan's other question around if people are feeling timid to bring up an issue because they don't want to blame anyone, then I think to address that one; specifically, you have to come to retro with a WE mindset. And I think HBO accidentally sending a test email is a really good example of that. Because in the Twitter thread, a bunch of other I presume developers were commenting and responding in support of the person that sent that out to say, "Hey, you discovered a missing safety net in the system," or the fact that it was fairly easy to make this mistake and send it out. So if you come to retro with this mindset of if a mistake was made, how can we as a team improve this so then it's less easy to make that mistake? Then you won't have the sense of we're blaming this on one person, but instead, we as a team are responsible for helping each other out.

+ +

CHRIS: It's interesting to have that conversation in the context of retro because I don't necessarily think of retro in exactly this way. But there is the idea of blameless postmortems, which come out of the Google Site Reliability Engineering; I think it's a book, maybe it's a website. We can include a link regardless. But that idea of blameless postmortems of collectively as a team, this thing made it out into the world, this bug, this problem. So we need to own that as a team, and we need to have a blameless conversation around that, just talking about what happened. And there are subtleties there. And that's a nuanced idea that needs to be evolved, but that is at least some writing that exists in the world that talks specifically to that part of it. That said, I wonder if a true postmortem, so a distinct meeting just dedicated to those more pointed issues, might be more relevant, and then retro is more of a shared overall conversation. But if there are smaller versions of that, then I think using that framing could be really helpful in retro.

+ +

STEPH: Yeah, I think you said that perfectly where there needs to be team ownership over all of the issues that are being discussed. And I think there is one other very tricky area to navigate with having a productive retro. And I don't know of a better way to say this. But you have a grumpy goose on your team. You have someone who doesn't like retros, and they're going to be negative, and they're going to be vocal. And that is a hard one. I have been there before. And I often approach that situation by speaking with them specifically around what are your concerns with retro? Are you willing to at least buy-in and give this new format a chance? But you essentially need them to buy in or have leadership buy-in so then they know to follow suit as well that this is a team process that we're going to improve and work on together. And if you don't like it, then that's what retro is for. So how we can make this a better, more productive meeting? But just showing up and being grumpy isn't helpful. And then helping people who have been burned by retros overcome that negative reaction to retros is something that takes time.

+ +

CHRIS: Oh yeah. The grumpy goose just affects everything on the team. But definitely retro is one where I've seen that particularly pointed. I think in those cases, the best luck I've ever had is to, like you said, have a separate conversation but have the conversation at a higher level. So the question isn't about do we have retro or do we have it in this shape? The question is, do we think we are operating at our best? Do we think everything is going perfectly? And almost never will the answer be "Yeah, this is great. We have no bugs. We're moving as fast as we possibly can. Everyone is happy. No one is burnt out." And so if we get to an agreement that is like, well, yeah, sure, there are things that we could improve, then I think that's a toehold that we can then build on and say, "Okay, so how do you want to go about that?

+ +

I am fine to explore a different approach than retro as a meeting to continually improving and evolving our process. I'd love to know what thoughts you have, Mr. Goose." But if they don't have an alternative, retro is the most effective structure that I've found for this continuous feedback loop around the process. I'm very happy to find an alternative, but I critically think we need something like that. And so if they're going to be pushing back on retro specifically, then I'll bump up to the higher level and say, "Okay, how do you want to be improving our process? Let's try something else, but let's make sure we are asking the question of how do we improve our process and is that succeeding?" And also, stop being so grumpy. Come on, what are you doing?

+ +

STEPH: [chuckles] I recognize that approach so much because then it really gets to the heart of the purpose of retro whether it's actually called retro or how we handle it is not significant, but the fact that we together as a team can get together and discuss how to improve. That's really the important thing that we're after. And retro just happens to be the format that I use and really enjoy. But like you said, it's always open to each team's interpretation.

+ +

On that note, Jonathan, I hope this quick overview of the thoughtbot retro has been helpful. And we will also include some other links that also highlight how thoughtbot runs retros and some other discussions that we've had about retrospectives. But on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+p6Ju1iNW + + ]]> + + Chris Toomey + Steph Viccari + + + 302: Observability with Charity Majors + https://bikeshed.thoughtbot.com/302 + dae8d047-2e9b-4e2c-9b94-23a2ff5825d4 + Tue, 27 Jul 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Tune in as Co-founder and CTO of Honeycomb, an observability platform, Charity Majors joins Chris to drop some knowlege bombs such as: + +* Thinking of observability as being about the unknown unknowns: Allowing for high cardinality, high dimensionality, ad hoc queries at any point in time. +* Comparing instrumentation to a muscle: It's a habit that needs to be developed and fostered. +* Sincere continuous deployment: 15 minutes or bust. + +And bunches more, since y'all know you hear her name come up _at least_ once during every other episode! + 38:53 + yes + + + Tune in as Co-founder and CTO of Honeycomb, an observability platform, Charity Majors joins Chris to drop some knowlege bombs such as: +Thinking of observability as being about the unknown unknowns: Allowing for high cardinality, high dimensionality, ad hoc queries at any point in time. +Comparing instrumentation to a muscle: It's a habit that needs to be developed and fostered. +Sincere continuous deployment: 15 minutes or bust. +And bunches more, since y'all know you hear her name come up at least once during every other episode! + Honeycomb.io (https://www.honeycomb.io/) + o11ycast (https://www.heavybit.com/library/podcasts/o11ycast/) + Charity's blog (charity.wtf) (https://charity.wtf/) + Charity on twitter (https://twitter.com/mipsytipsy) + Charity's post on cost of not doing continuous deployment (https://charity.wtf/2021/02/19/how-much-is-your-fear-costing-you/) + Charity's post - The Engineer Manager Pendulum (https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/) +Transcript: +CHRIS: Hello, and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week Steph is taking a quick break, but while she's away, I was joined by a special guest, Charity Majors. Now, folks who've been listening to the show lately will know I've been mentioning one idea or another from Charity almost every episode these days. Charity's work spans from the deeply technical through to the deeply human. And across all of it, she brings such a wealth of experience in pragmatism while consistently providing grounded, actionable advice about how we can improve all aspects of our work. +And to give a bit more context for those who aren't as familiar with Charity's work, she is the co-founder and CTO of Honeycomb, which is an observability platform that we talk about more in the episode. Charity is also a prolific blogger, tweeter and speaker, and general leaver of digital breadcrumbs for the rest of us to hopefully follow. And Charity is also one of the hosts of the o11ycast podcast. That's observability, o11y podcast. And in fact, in the intro to the first o11ycast episode, Charity provides a beautiful summary of her approach to the varied work that we do. Quote, "I'm someone who's always been drawn to where the beautiful theory of computing meets the awkward, messy reality of actually trying to do things." And that quote rang so deeply true to me when I heard it and really encompassed what I see across the variety of work that Charity has shared with us. And frankly, I've been so impressed with the quality and quantity of wonderful content that Charity has shared over the years. I was really just thrilled to get the chance to sit down and talk with her directly. So without further ado, here's our conversation with Charity Majors. Thanks so much for joining us today, Charity. +CHARITY: Thanks for having me. It's great to be here. +CHRIS: As I've mentioned on many an episode, I've been following your work for a while now. And at this point, I would say that just about every Bike Shed episode has a reference to you and some piece of work that you have put out into the world, whether it be a tweet or a blog post, or a conference talk or something. So I'm so grateful for all the work that you put out into the world and for taking the time to chat with us today. +CHARITY: That's so exciting. Yay. I feel right at home here then. [chuckles] +CHRIS: Fantastic. Well, I want to dive in. I think it's sort of the core of some of the conversation that we'll be having, which is around instrumentation and observability, and observability as a newer, noveler form of how we think about this space. But to give a bit of context, I was hoping you might be able to give just the quick summary for anyone who might not be as familiar with observability as a concept and what that means now, and Honeycomb as a product and how it offers affordances around observability and pushes that envelope forward. +CHARITY: Yeah, I think of the observability as being about the unknown unknowns. For a long time, all of the complexity was really bound up in the app. You had the load balancer, you had the app, and the database. And all the complexity you could just attach to a debugger and step through it if you had to. But then we kind of blew up the app, the monolith, and now it's in services scattered to the winds, and you can't just trace it. And so observability is a way of passing that context along hop by hop so that you can actually slice and dice in real-time. And the hardest problem is not usually debugging the code. It's finding out wherein the system is the code that you need to debug. +And observability, if you accept my definition, which is it's about unknown unknowns, that you should be able to ask any question of your systems, understand any internal state just by observing it from the outside, well, then a lot of things proceed from that, in my opinion. Like, you need to be able to handle high cardinality, high dimensionality. You need to be able to string together a lot of these high cardinality dimensions. You need to... any kind of schema or indexing scheme in advance is verboten because you don't know what questions you're going to need to ask. And so there's a lot that flows from that definition; arbitrarily-wide structured data blobs is the source of truth, et cetera. But at its heart, it's just about the concepts, that our problems are getting harder and harder. We don't get paged to go, "Oh, that again? Oh, that again?" +CHRIS: [chuckles] +CHARITY: Ideally, we fix those things. But we still get paged. What the hell is this? It's about allowing engineers, empowering them in a reasonable amount of time to be in constant conversation with that code that's out there in the world because most problems honestly we never get paged about. They're too subtle until they snowball, and they pick up other problems. It's like a hairball under your couch until it gets so big and so impacting that it actually does alert someone. And then you just start picking up the rock and be like, oh God, what's that? Well, we've never understood this. And that's why ops has such a reputation for masochism. [chuckles] +CHRIS: Absolutely. There are so many little pieces in what you just said that really deeply resonate with me, although there is one facet of some of the way that you talk about observability that I find interesting. I'm someone who likes to cling to the perhaps unrealistic these days ideal of a monolith of what if we were to just keep everything in the same place and all the data lived together in one database, and I could have foreign keys, and consistencies, and asset compliance? +CHARITY: Which you should do for as long as you possibly can. You should never impose more complexity on yourself than you absolutely need to. And I would say that it's never not better to have observability than the older paradigms of monitoring and so forth. Some of Honeycomb's biggest and best customers still use monoliths. But they still find it really valuable to be able to apply the principles. I think that it's the microservices revolution, if you will, that forced this set of changes. It was inevitable. The steps that I started talking about, like, somebody would have because the older way just became untenable when you started adopting containerization and a lot of these things that made everything suddenly a high cardinality including the number of applications you have. But it's never not better to have high cardinality tools and to be able to instrument your code for spans and tracing. Tracing is still valuable even in the monolith. +CHRIS: Yeah. As I've observed and started to play around with Honeycomb, that's definitely what I've seen is I'm almost exclusively working in the context of monoliths and, like I said, clinging to them for as long as I possibly can, which isn't going to be forever. +CHARITY: It's true. [chuckles] +CHRIS: I recognize that truth, but already I see the value. And so Honeycomb is a platform that you've built that allows for this high cardinality, high dimensionality ad hoc queries at any point in time. And so the idea that I can come into the tool and say, "Huh, I've got a new novel problem today." I don't need to re-instrument my code. I can just ask a new question, and the system will responsively be able to answer that question, ideally. And that feels like it holds true in a monolith all the more so, like you said, in an SOA architecture. But even in my safe little playground of everything is in the same space, I still don't know how everything's working all the time if we're being honest. So being able to answer those questions feels meaningful. +CHARITY: Totally. I think that one way of thinking about the SOA or microservices is that it pushes a lot of what was in the operations realm into a realm of development, and suddenly you're responsible for a lot more of the operating of your services, things like retries and backoffs, and load distribution, and thundering herds, and all these things that ops traditionally took care of. Well, now you have to think about them. So you need some ops tools, too. What I like about...of course I like everything about Honeycomb because we designed it for this problem. But it speaks in the language of variables, and endpoints, and functions, and not in the low-level language of proc IPv6 timeouts and stuff where I feel like ops has also traditionally been the translation layer between software engineers and their actual code in production. And it's time to start giving software engineers those tools in their own language. +CHRIS: Yeah. I love that. And I'm very happy to have Honeycomb as part of an instrumentation stack, which actually shifts me to the next question, which as I look at Honeycomb, very quickly the first time I saw it, I was like, oh okay, this makes sense. I want this in the world. +CHARITY: Oh, I like you. [laughs] Not all people are like you. +CHRIS: It might have been my second or third look, but it was definitely...once I got it, I was like, oh yes, I absolutely want that. But now, the question that I have is I typically will have a collection of tools that exist in this space. And there's a weird Venn diagram overlap of well, there's logging, and there's error tracking, and there are APM performance tools, and there's metrics, dashboards. And my sense is that Honeycomb perhaps can or an observability tool more generally can subsume a bunch of those, but it's not clear to me exactly. I think I probably still want logging. I think I still want error tracking as a discreet service tool that I'm using but maybe not APM and maybe not metrics as a distinct thing. Maybe I can infer those from a tool like Honeycomb. But I'm wondering what's the current thought on that? +CHARITY: Well, part of what you're seeing is just observability tooling is very new, and we haven't had time to grow up. And here I'm like, officially, we play very nicely with all other vendors, and none of us would ever try to compete or take away from each other's faces. But I do think that ultimately, logging pretty much the only real use case for it is security stuff, the security archiving, just keep every log light. It's gotten cheap enough, but it's not actually useful for debugging or understanding your system, not really. It's useful for compliance. It's useful for proving that you did something in the past. Most logs are just a pile of trash, but they can be useful trash. And I understand people's emotional want to hold onto them for a while, and there's nothing wrong with that. There's nothing wrong with keeping some trash around for a while, while you make it...[laughs] Sorry, not to totally slam on logs, but they are trash. +CHRIS: I love the analogies that we're going for. [laughs] +CHARITY: But the thing about observability is I do think the kind of center of the world is these arbitrarily-wide structured data blobs from what you can infer logs, from which you can infer metrics, from which you can roll-up. So I do think that well metrics are the right first tool for understanding infrastructure. Like if you're Amazon and you're responsible for all this hardware and stuff, you should be asking yourself, is my service healthy? But if you're someone who's writing and shipping code on top of that service you care about, can my request complete? What is my user's experience? And that's observability's territory. So I think that ultimately, I do think metrics, logs, and traces all get subsumed under the observability umbrella and performance management, too, if the tools get built correctly. There will still be use cases. They will just get smaller, for logs, for standalone metrics tools. +Honeycomb just launched our metrics product. Metrics is like a 30-year-old piece of technology. Prometheus and Datadog are going to be the last best metrics tools ever built. We have wrung the water out of this laundry. [chuckles ] But we aren't trying to compete with that. What we are trying to do is give people an on-ramp into Honeycomb. They've got decades’ worth of stuff. They've been corralling metrics, structuring them. You rely on them. You don't want to give them up. So yeah, let's feed them in. Let's give them an overlay. And number two, the more interesting use case for me is when you're a software engineer who's writing and shipping code, you do care about did the memory usage just triple, or is the CPU completely buzzing after I shipped my last change? But there's really only like three or four of those metrics that you really care about as system metrics. The rest are mostly legacy. +CHRIS: I like the idea that aspirationally, Honeycomb is moving towards a place where given sufficient input data, given this arbitrarily-wide data blob with high cardinality, et cetera, that we can infer basically all of those others from it. But also speaking to also observability is somewhat new, and so we got to build a lot of product to get there and that idea that there is perhaps a space right now where you might be bringing together a few of these tools. But if there is a future world in which I can have one of these tools that just handles everything and tells me about my code and directs me to the line of code that I incorrectly instrumented, that would be wonderful. Happy to do the work in the interim to cobble it together from the pieces. +CHARITY: The place in the meantime that we're at where all of these big vendors are acquiring other vendors and trying to put together...they're like, we have three pillars. Coincidentally, we have three products to sell you. It's like, it's not good for the users because when you're...like, you're sitting in the middle here. You've got your metrics dashboard. It's telling you that there's a problem. Okay, if you can't slice and dice and figure out what it is, you have to jump over into logs and visually correlate based on the times and hope no timestamps are wrong and try and find the thing. And then, oh, okay, so you want to trace it. So you've got to copy over and try and find that in your tracing product and hope that that would get sampled in. It's not good. You can't follow the question from the beginning. I have a problem to the end. I have a solution and back. And it's not linear. You're going to be following a trail; then you're going to need to back up, then you're going to find another trail. And then you're going to want us to zoom out and see who else is impacted. And you really can't back your way into that with different products. You have to start with the arbitrarily-wide structured data blob. +What does confuse me is I know that New Relic is built on this. New Relic has these. And we almost didn't start Honeycomb because we were just like, edit data, and New Relic is going to figure it out. Here we are like six years later, and they still haven't fcking figured it out. [laughs] But like Datadog, they aren't based on that arbitrarily-wide structure, so they are really...and I know that they're trying to get...all of these big vendors are trying to get to where Honeycomb sits technically faster than we can grow up and become a business. +CHRIS: The race is on. +CHARITY: Yeah. It's fun. +CHRIS: One of the related things that I've seen you talk about a few times is the idea that instrumentation is a muscle. It's a habit that needs to be developed and fostered, and that rings very true to me. At the same time, a lot of my instrumentation work has been more in a reactive space. If we're being completely honest, something went wrong; we can't figure it out from the information that we have available, so then we go in, and we add a new logging line. We wrap the code in some way. And so I'm wondering if you can talk a little bit more about that. What does that look like in practice or perhaps some examples or something? But how can we tease that apart and understand that a little bit better? Because it sounds wonderful to me. +CHARITY: I think of instrumenting a lot like commenting your code. It's a way of thinking to the future and reverse engineering; what am I going to care about? What is someone else going to care about? And I really do think of commenting as just a less true version of instrumentation, honestly. It's you talking about what you think the code should be doing, but you've left production out of the loops. You don't know what the code is doing. [chuckles] But ideally, they're kind of the same muscle. It's why you're writing your code. You've just developed a monitoring thread almost in your brain. It's like, yeah, this is going to be valuable. Oh, this is going to be valuable. And so I do think that it's on vendors to make sure that we do as much for you as possible. And this, honestly, is the long winding journey to Honeycomb finding product-market fit, which took almost three and a half, four years. +And for a long time, I was like, it’s not magic. You have to understand your code. You have to blah, blah, blah, which is true. But also, we need to walk closer to the user. We need to make it easier. We need to do the beeline, which will initialize the event, pre-populate it with a bunch of stuff, create the framework so that all you have to do as a user is just printf now and then just stuff this in the blob, vendors making it as easy as possible, as automated as possible. We have more to do. We really should be pre-populating it with all of the language internals and all of the stuff about the environment. We'll just be glad to tap that well. But there's something that we can't do for you, which is understand what you're trying to do and what is important. +Honestly, here's a story from the past. The reason that New Relic was so big, they hit the ground, and they super hockey-sticked everything was because they dovetailed with the rise of Ruby and Rails because Ruby allows for so much fcking monkey patching. Every web app looks the same. You can just be like, we assume all this crap, and so we could make it just like magic for you. You just install this library. Boom, you're off to the races. Well, try as you might, I want to say a type language like Go, you can't do that stuff with. You can't make it as magical. You have to think a lot more about how you're structuring things for better or for worse, which is why their growth slowed because those languages just aren't so popular anymore. +So it's trade-offs all the way down. Yes, everybody should be an expert in forecasting the future and understanding all the subtle things that you don't know you're going to know, but you're super are going to want to know. But as you've discovered, most of your learning comes from being in the trenches, which is why it's so good for devs to be on call and be close to their code and be in this constant conversation with it because you develop a sixth sense. I can't tell you exactly why I know it's going to be a problem, but I'm just going to wrap it because I'm pretty sure it is. +CHRIS: There was a tiny bit that I was hoping that you would have some very specific like, oh, you just do X, Y, and Z. I kind of knew that wasn't going to be the answer, but it also represents something that I so appreciate about your thinking and the work that you put out into the world, which is it's realistic. Sometimes you're like, you know what? There's going to be some tacit knowledge involved here. You got to put in the work. You got to learn the thing, and that's just true sometimes. And so I appreciate your willingness to be like yeah, you know what you got to do? You got to do the work. And then after that, you'll know...and so there's sort of a virtuous cycle that can happen here. There is a feature, as far as I understand it, of Honeycomb, too if I can briefly hype up your products slightly but the idea that you can observe the series of questions that another developer asks. So if they were in a debugging session, you can see like, oh, they asked this, and then they asked this, and then they filtered on that. +CHARITY: It's like your Bash history but for debugging. [chuckles]. +CHRIS: I want this for everything. +CHARITY: Right? +CHRIS: Let's have a shared hive mind of the developers on a team, both in terms of our observability tool but also just kind of everything. +CHARITY: What did you do? +CHRIS: Yeah, what did you do, and why? What were you thinking? I saw you went down a road there, but then you stopped and backed up, and you went a different way. That's interesting to me. +CHARITY: This is why we keep trying to build things into the product that will incentivize people to write texts about what they're doing, whether it's retroactively applying tags or writing a breadcrumb to yourself. Why was this meaningful? As you're putting it in your bookmarks, why are you putting it in your bookmarks? Collaboration is just as much about collaborating with your past self and your future self as it is with the rest of your team. I don't remember why the fck I did that two years ago. I don't know. I don't know why I did that two months ago. But the more you can leave breadcrumbs for yourself and then surface that to the team, you're right; it’s transformational. +I wanted this so selfishly because I have never been that person on the team who loves graphs. I hate graphs. I don't think visually very well at all. I've been working with my friend, Ben Harts, off and on for like 10, 12 years now. He's always the person I've hired repeatedly. He's always the person who comes in and makes the graphs. And then I look over his shoulder, and I bookmark them. I can be up all night making the perfect dashboard. And then I'm like, great, mine. [chuckles] So there's room in the world for both of us. But the point is that not all of us should have to go through that effort. [chuckles] We should be able to learn from each other. Only one person should ever have to have to craft the perfect query, and then the rest of the team should be able to effortlessly piggyback on it. +CHRIS: Yeah, absolutely. And again, I want that but for everything. I dream of a future in which that's true. +CHARITY: And so much of debugging is this wandering path where you go down the wrong place, and you need to be able to zoom back to all right; where did I first know that I had a beat on it? +CHRIS: There's a corollary that I see to pair programming where one of the things that I find so valuable is, what Google query do you type in when you hit that wall? When you're like, oh, this isn't working as I'm thinking, and then you type something and I'm like, whoa, wait, I wouldn't have even thought to ask that question of the internet. +CHARITY: Oh, I love that. That's fantastic. +CHRIS: But now you've productized that, and I love that. So thank you for building that thing in the world. +CHARITY: Excellent. +CHRIS: Shifting gears slightly, one of the other themes that you really pushed for in the world is the idea of continuous deployment and not like yeah, you should ship your code pretty quickly after you merge it, but true, sincere continuous deployment. +CHARITY: 15 minutes or bust. +CHRIS: 15 minutes of bust, test in production. There are some really wonderful if we're being honest, scary themes that you talk about. I love the ideas that you're putting out there, but they're probably the things that I look at, and I'm like, ooh, that seems like a whole thing right there. +CHARITY: It assumes a lot. Let's put it that way. It assumes a lot. +CHRIS: It definitely does that. I desperately want to get to that world. I want to get to the place where there's that confidence. And similarly, there's a theme that you've talked about around Friday deploy freezes and why that's not a good thing. And the empathy for humans that part's good, but maybe we're applying it in the wrong way if we say we're not allowed to deploy code on Friday. Because it's like yeah, deploying code is terrifying and scary. No, let's solve that problem. But I wonder if you can talk a little bit about that. How do you get there? How do you get to the place where continuous deployment is a realistic outcome for you? +CHARITY: Yeah, that's a very good question. There are no easy answers, unfortunately. And the answer is always going to depend on where are you starting from? Are you starting from a clean slate? Are you starting...a lot of the advice that I give sounds like Looney Tunes to someone who's coming from enterprise because they're just like, "You don't understand the constraints that I am operating under." And I'm like, "Yeah, you're right. I'm not of your world. That probably shows." [chuckles] So I think the easiest way, though, is always when you're starting a new project that what you do on day one would be to set up your CI/CD and deploy it to prod before you've even started building. My favorite analogy to that is to like...you know the myth about Alexander the Great and his horse how when he was a little boy he would pick it up every day before he had breakfast? And so, by the time he was an adult, he could pick up his horse because he picked it up every day, and it was never hard. +When you start deploying that way, it's never hard. When you're just like, okay, anytime this gets above 10 minutes, we're going to put in a couple of hours of work, and it's never hard. It's just the easiest thing in the world. And everything's easier because you get to watch what you're doing and in real-time, and you develop that muscle of I’m merging it to main. I'm going to go look at it in a couple of minutes. And you don't feel done in your gut until you've looked at it. And that's doing it on easy mode. And you can do this in a hybrid way. Even if you have like, well, I'm paying for a deploy. Nobody is saying you have to sign up for a long, painful deploy process when you got to spin up a new project. And I've seen it gain momentum. If you start something that's clearly the new way, everybody sees how fast this team is executing. Everybody wants a piece of it. And so you start learning from the way that you are able to do it in your unique environment. You're the best evangelist to the rest of your team members because you know the subtleties. You know the problems. So that's the easy answer is start fresh. [laughs] +CHRIS: [laughs] That makes sense. I do, again, I appreciate the pragmatism or the realism of the way that you approach a lot of the topics. +CHARITY: Another answer, though, it's just that the engineering work involved in taking a deployed pipeline down from hours, days, to 15 minutes it's just engineering work. It is just labor. It can be done. The political problems are the hard ones. I mean, in the past, sometimes our deploy probably would get up to two or three hours, and we were just like, oh God, this is not…put in the work. You just start instrumenting your pipeline, and you start looking at where the tests are taking time. And it will pay dividends every bit of time that you pay down, which is why I really see these long…our own pipelines is it's a vacuum of engineering leadership that they've allowed it to happen because there's nothing fancy about it. You just put in some work. +CHRIS: Yeah, the solvability of the technical challenge feels very true, but what you're saying of it's people problems which again, that's always true of the tech stuff. +CHARITY: It is people problems, but I also hate it when people are just like, oh, it's people problems. That means mysterious and unsolvable. Now, most of the time, when you see this, it's a lack of collective confidence in themselves. They see this as being as just for the elite engineers, or only ex-Googlers are allowed to do this or something. Or they go to conferences, and they hear about it, and they're just like, God, I wish I was allowed to do that, or I wish we could do this. +But the thing is that engineers have more power than they realize. We build these companies. They wouldn't exist if it's not for us. We have all the power if we just choose to use it. I know that a lot of these people who I've talked to that were just like, "Oh, I wish we…" I'm like, "Have you ever lobbied for it?" And they're like, "No, I just know we could, or that's someone else's decision." I'm not going to promise you that you can get whatever you want. But I promise you that if you start speaking up if you start talking to your colleagues and being like, "Wouldn't it be nice?" And they start speaking up...if a quarter of the engineers want something in the company, it gets done. [chuckles] +CHRIS: That definitely feels true. And to the topic of actually lobbying for this and having the hard conversations internally and working on the people problems, you have done, I think, a really fantastic job of providing actual benchmarks in terms of timing and what does this look like as a practice and what are the multitasks? +CHARITY: It's so expensive. It's so costly to organizations. And it's the easy answer for any engineering leader to be like, "Well, we need to hire." That is the laziest answer in the world. You probably don't. You probably just need to fix your CI/CD system and then bask in the resources that you suddenly freed up. [chuckles] +CHRIS: You have a wonderful blog post that really I think does such a good job of highlighting the cost that you're talking about there, the human costs for every slowdown in your deploy process, it has this downstream ramification. And having that as sort of a piece, a bargaining chip in the conversation of here's a voice that is saying a very clear thing about this cost of not doing this work, which granted, it's always trade-offs. Everything is an optimization. But here is a way to actually measure the cost of not going with this approach. And again, I appreciate you're putting that out there in the world so that the rest of us can be like, "Look, on the internet, it says so." +CHARITY: [chuckles] Exactly. I'm happy to be the internet for you. But it's so true because other people in your business don't want you to suffer too, either. They don't want everything to get slow. They just aren't equipped to understand the cost of this slowness the way that engineers are. And I feel like sometimes this is...it's like we're always lamenting like, why does product get to own all the engineering cycles? Where aren't we allowed to do all this other stuff? I promise you're allowed to. You just have to make the case because the case is righteous and justified. But you have to explain to them the cost that it's incurring your organization in terms of your ability to execute and in terms of your ability to hire and retain people. You just have to explain those costs. And engineers are just like, "Well, we only say it once, right?" Well, that's not how you win arguments. You have to say it. You'll probably lose. And you say it again, and you'll probably lose. You say it a third. And you will win eventually because you control all of the creative labor of the technical organization. So just make the fcking case. [chuckles] I don't know. I make it sound simple; it’s not. +CHRIS: I love the sound bite of the cause is righteous, and that is the kernel of the thing here, which is like, just to be clear, this is a virtuous path that you were going down, battle for it, work towards it, absolutely. So I think a related topic here, so continuous deployment is one of those things that you want to get to and a practice that you want to evolve to. But in exploring some of your other work, one of the things that I was exposed to is the DORA metrics, which is not something that I hadn't seen before. But for anyone who's unfamiliar, the DORA metrics is a set of four key metrics to track developer and team productivity, so their deployment frequency, lead time for changes, change failure rate and the time to restore the service. And they are deeply interesting because frankly, I have for a long time felt like developer productivity was not really a quantifiable thing. +CHARITY: It's not, yeah. +CHRIS: Individual developer productivity I still feel like this is a bad thing. Don't do that. But team productivity these metrics actually are like oh, actually, as I look at those, those seem like the good ones. We should do that. I'm wondering, what does that look like in practice when you see that actually employed within an organization? What are the feedback loops, and how does this appear in the world? +CHARITY: Yeah. We all owe a huge debt of gratitude to Jez Humble, Gene Kim, and Nicole, who worked on this for years and got this out into the world, just putting some actual research behind the stories that we were telling ourselves about productivity. And people who haven't read Accelerate...a lot of people are always asking me, do we have any stories? Do you have any research? Do you have any proof or something? I just always point to the book Accelerate. That's where it all comes from. Yeah, it's true because it's such a noisy world. When you're an engineering org, and there's just so much going on, and there's so much stuff that bugs you personally, and some of the stuff that you have true beliefs about. And it's hard to just cut through the noise. +And I feel like that's the great gift of the DORA metrics. If you start focusing on one of them, you will lift your org out of poverty, and the others will get better too. And it provides just this wonderful focus point for teams that aren't sure where they stand or aren't sure how to get better because it can be so mystifying. When you're in the trenches, and you're just like, why does everything feel so hard? Why is it that we thought this would take two days, and here it is two months later, and we can't ship anything? And it feels like the more we ship, the farther behind we get. These are the beacon of hope. It's like, you pay attention to these, your lives will get better. You can dig yourself out of this ditch. +That's certainly been true for the teams that I've been on. And high-performing teams, I think we all have this idea in our heads that high-performing teams are ones where the great engineers join when in fact, those great engineers could join your team, and they wouldn't get any more done than you are. Because most of our productivity is defined not by the data structures and algorithms that you know but by these social-technical systems that we swim in every day, it’s the water around us. It's the friction involved in getting that code to production. If it takes the magical engineer from Google 24 hours to get their code changed out, well, they're not a member of a high-performing team either. +You mentioned earlier all these people are out there who haven't experienced a world like this don't live in a world like this. And in my experience, they often lack a lot of confidence because they don't think they're that good, or they don't think that they can have nice things. And the DORA metrics that's your ticket to a better life. It's like go to college and graduate because it kicks off these virtuous feedback loops, these cascading cycles of things getting better for everyone and people getting more excited and energized. And they just don't get burned out by shipping too much code. They get burned out by not being able to ship code. +And if you're a leader in any type of organization, and I don't just mean manager, I mean any type of senior engineer or manager or whatever, then it's part of your job to pay attention to these metrics, lobby for them, track them, track them on your own if you must, and try to make them better because every engineering team has two customers or two...whatever. I'm blanking on the word. But it's your customers and your engineering team. You're responsible to both of them. And I've never seen one of those sets deliriously happy and the other set miserable. They tend to rise and fall in tandem. +CHRIS: I'm just nodding along for anyone in the audience who can't see what my head's doing. But I love so much all of the things that you're saying and, again, the passion and conviction that you bring to this conversation because these are amorphous, hard to pin down ideas. But I appreciate the North Star that you're setting across all of these different things that as I'm reading, I'm like yeah, that sounds true. I want that. Those things are the things that I want. But interestingly, one of the other threads that I see weaving through a lot of your work is obviously we've talked a bunch about just deeply technical topics thus far, but also a lot of your work spans across to the interpersonal. And frankly, even dividing in that way is not representative of the world because it's a Venn diagram mishmash of some days it's technical, some days it's personal, some days it's both. But one of the things that you've talked about is the engineer manager pendulum which I find super interesting. I think every engineer at some point has that question, that internal oh, do I want to go engineer track or manager track? And this distinct idea or the idea that management is a promotion and any other movement would be different, and you have wonderful things to say about that. +The other thing that you've pointed out is that former managers can often make great engineers after the fact because of the earned empathy that they have now from looking at things from a slightly different angle. +CHARITY: Amazing engineers. +CHRIS: But I'd love to hear a little bit more of your thoughts on that because I think it's such an important space, and I've definitely previously operated under I'm an engineer, and then I guess I got to be a manager, and then I guess I don't know where I go from there, but it's this very linear path. And you shook that worldview of mine, and again, I appreciate that shaking. But yeah, I'd love to hear a little bit more about that. +CHARITY: The best people that I've ever worked with have been engineers who had been managers for a while and then went back to engineering, and it's not just empathy, although there's a lot of that too. It's also a deeper understanding of the business and the reason that we do things. So much of being a powerful engineer is choosing the right work to work on so that you get a lot done very efficiently and quickly, and you don't spend a lot of time just foundering, which you've mastered, and you know the basic technical principles. And how do you get better? A lot of it is just getting better at identifying what to do and what not to do because we have to not do so much more than we can ever do in order to move forward. +I wrote a blog post as a present for a friend of mine who was a director of engineering at the time, and he was suffering. He was just miserable, and he kept thinking about going back to engineering, just kind of dragging his...because he wasn't in an org where that was really celebrated or anything. When you've been there from the beginning, you built the organization; you’re like a senior director and everything. It feels like a long way to fall. And I wrote that post for him. And he did end up going on to be an engineer after that. And he was so much happier. But I think he was surprised at how he didn't fall at all. He actually probably had...I think the engineers had a higher opinion of him afterwards when he was one of them again. And he still had this vaunted voice because he could speak to how the system had been there since the beginning. And he basically got to look around and look out farther than the engineers who were heads down every day and go, "This is going to bite us. I'm going to take a small team. We're going to do this forward-looking security product." +I don't want to identify details, but that for me really just kind of cinched...It was like the more we can strip hierarchy out of these discussions; the healthier everyone's going to be because we're just monkey brains. And the monkey brain in our skull hates losing hierarchy, hates losing power or stance or anything. And I think that the thing that you learn after you've been a manager is a lot of it is just the wizard behind the curtain, the idea that you have more power as a manager. You have more of some types of power, and you have a lot less of other types. And you're just as constrained as the engineers but in other ways. And the path moving forward is not to dominate people or be above them but to combine your powers for good and self-sort to find a place that actually gives you the most joy. +CHRIS: It's a wonderful philosophy. And actually, a thing that you said in there really stuck out to me, which was you wrote that blog post as a gift to someone, and that is such a kind thing to do. And it also, again, reflects what I see in your work overall. You're really clearly leaving a trail of breadcrumbs behind you to help other folks that are traversing a similar path by questioning aspects of it. Or how do we do this well? Why is everyone sad, and why is it bad? And so again, I so appreciate all of that work that you've done. +CHARITY: I think that that comes from my lifetime in the trenches of operations. [chuckles] Ops is notorious for the pain that we bring upon ourselves and try to solve. But I would just like to add a pitch out there for other ops engineers of the world and our colleagues. I was fortunate enough to rise up through the ranks in organizations that really respected operations. We always felt we ruled the roost. We felt like we were way above all the other developers. We got to say what went into production and what didn't. And I feel like ultimately...if you have to have an imbalance of power, I think that's slightly healthier than the developers ruling the roost. Ultimately, there shouldn't necessarily be any imbalance of power. But I just want to pitch it; this whole no-ops thing really got my goat for a while there because operations is just the engineering workaround delivering value to users. I think the second wave of DevOps is now about okay, software engineers; it’s your turn. It's time to learn to write operable software. And so I just wanted to throw in my hat in the ring for all the ops people out there. You're just as good. You're just as good as anyone else. [chuckles] +CHRIS: I mean, it's sort of a theme that I've seen in your writing of everybody's doing good, important work and breaking down hierarchy and just collaboratively moving in the same directions and trying to choose the right North Stars to aim towards. And yeah, it's all fantastic. And so with that, I think we probably reached a perfect spot to wrap up. But Charity, if folks want to keep up with more of your work online, where are the best places to find you? +CHARITY: My blog post is at charity.wtf, and I'm @mipsytipsy on Twitter, and of course Honeycomb.io and our blog. +CHRIS: We will include links to all of that and many of the blog posts, and other podcasts interviews that you've been on, and a bunch of just various things that I collected as I was preparing for this episode because, again, you've produced such a wealth of information on the internet that I want to point as many folks as possible towards those things. But yeah, thank you so much for taking the time. +CHARITY: My pleasure. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,; you as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._ + + + Tune in as Co-founder and CTO of Honeycomb, an observability platform, Charity Majors joins Chris to drop some knowlege bombs such as:

+ +
    +
  • Thinking of observability as being about the unknown unknowns: Allowing for high cardinality, high dimensionality, ad hoc queries at any point in time.
    • +
  • Comparing instrumentation to a muscle: It's a habit that needs to be developed and fostered.
    • +
  • Sincere continuous deployment: 15 minutes or bust.
    • +
+ +

And bunches more, since y'all know you hear her name come up at least once during every other episode!

+ + + +

Transcript:

+ +

CHRIS: Hello, and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week Steph is taking a quick break, but while she's away, I was joined by a special guest, Charity Majors. Now, folks who've been listening to the show lately will know I've been mentioning one idea or another from Charity almost every episode these days. Charity's work spans from the deeply technical through to the deeply human. And across all of it, she brings such a wealth of experience in pragmatism while consistently providing grounded, actionable advice about how we can improve all aspects of our work.

+ +

And to give a bit more context for those who aren't as familiar with Charity's work, she is the co-founder and CTO of Honeycomb, which is an observability platform that we talk about more in the episode. Charity is also a prolific blogger, tweeter and speaker, and general leaver of digital breadcrumbs for the rest of us to hopefully follow. And Charity is also one of the hosts of the o11ycast podcast. That's observability, o11y podcast. And in fact, in the intro to the first o11ycast episode, Charity provides a beautiful summary of her approach to the varied work that we do. Quote, "I'm someone who's always been drawn to where the beautiful theory of computing meets the awkward, messy reality of actually trying to do things." And that quote rang so deeply true to me when I heard it and really encompassed what I see across the variety of work that Charity has shared with us. And frankly, I've been so impressed with the quality and quantity of wonderful content that Charity has shared over the years. I was really just thrilled to get the chance to sit down and talk with her directly. So without further ado, here's our conversation with Charity Majors. Thanks so much for joining us today, Charity.

+ +

CHARITY: Thanks for having me. It's great to be here.

+ +

CHRIS: As I've mentioned on many an episode, I've been following your work for a while now. And at this point, I would say that just about every Bike Shed episode has a reference to you and some piece of work that you have put out into the world, whether it be a tweet or a blog post, or a conference talk or something. So I'm so grateful for all the work that you put out into the world and for taking the time to chat with us today.

+ +

CHARITY: That's so exciting. Yay. I feel right at home here then. [chuckles]

+ +

CHRIS: Fantastic. Well, I want to dive in. I think it's sort of the core of some of the conversation that we'll be having, which is around instrumentation and observability, and observability as a newer, noveler form of how we think about this space. But to give a bit of context, I was hoping you might be able to give just the quick summary for anyone who might not be as familiar with observability as a concept and what that means now, and Honeycomb as a product and how it offers affordances around observability and pushes that envelope forward.

+ +

CHARITY: Yeah, I think of the observability as being about the unknown unknowns. For a long time, all of the complexity was really bound up in the app. You had the load balancer, you had the app, and the database. And all the complexity you could just attach to a debugger and step through it if you had to. But then we kind of blew up the app, the monolith, and now it's in services scattered to the winds, and you can't just trace it. And so observability is a way of passing that context along hop by hop so that you can actually slice and dice in real-time. And the hardest problem is not usually debugging the code. It's finding out wherein the system is the code that you need to debug.

+ +

And observability, if you accept my definition, which is it's about unknown unknowns, that you should be able to ask any question of your systems, understand any internal state just by observing it from the outside, well, then a lot of things proceed from that, in my opinion. Like, you need to be able to handle high cardinality, high dimensionality. You need to be able to string together a lot of these high cardinality dimensions. You need to... any kind of schema or indexing scheme in advance is verboten because you don't know what questions you're going to need to ask. And so there's a lot that flows from that definition; arbitrarily-wide structured data blobs is the source of truth, et cetera. But at its heart, it's just about the concepts, that our problems are getting harder and harder. We don't get paged to go, "Oh, that again? Oh, that again?"

+ +

CHRIS: [chuckles]

+ +

CHARITY: Ideally, we fix those things. But we still get paged. What the hell is this? It's about allowing engineers, empowering them in a reasonable amount of time to be in constant conversation with that code that's out there in the world because most problems honestly we never get paged about. They're too subtle until they snowball, and they pick up other problems. It's like a hairball under your couch until it gets so big and so impacting that it actually does alert someone. And then you just start picking up the rock and be like, oh God, what's that? Well, we've never understood this. And that's why ops has such a reputation for masochism. [chuckles]

+ +

CHRIS: Absolutely. There are so many little pieces in what you just said that really deeply resonate with me, although there is one facet of some of the way that you talk about observability that I find interesting. I'm someone who likes to cling to the perhaps unrealistic these days ideal of a monolith of what if we were to just keep everything in the same place and all the data lived together in one database, and I could have foreign keys, and consistencies, and asset compliance?

+ +

CHARITY: Which you should do for as long as you possibly can. You should never impose more complexity on yourself than you absolutely need to. And I would say that it's never not better to have observability than the older paradigms of monitoring and so forth. Some of Honeycomb's biggest and best customers still use monoliths. But they still find it really valuable to be able to apply the principles. I think that it's the microservices revolution, if you will, that forced this set of changes. It was inevitable. The steps that I started talking about, like, somebody would have because the older way just became untenable when you started adopting containerization and a lot of these things that made everything suddenly a high cardinality including the number of applications you have. But it's never not better to have high cardinality tools and to be able to instrument your code for spans and tracing. Tracing is still valuable even in the monolith.

+ +

CHRIS: Yeah. As I've observed and started to play around with Honeycomb, that's definitely what I've seen is I'm almost exclusively working in the context of monoliths and, like I said, clinging to them for as long as I possibly can, which isn't going to be forever.

+ +

CHARITY: It's true. [chuckles]

+ +

CHRIS: I recognize that truth, but already I see the value. And so Honeycomb is a platform that you've built that allows for this high cardinality, high dimensionality ad hoc queries at any point in time. And so the idea that I can come into the tool and say, "Huh, I've got a new novel problem today." I don't need to re-instrument my code. I can just ask a new question, and the system will responsively be able to answer that question, ideally. And that feels like it holds true in a monolith all the more so, like you said, in an SOA architecture. But even in my safe little playground of everything is in the same space, I still don't know how everything's working all the time if we're being honest. So being able to answer those questions feels meaningful.

+ +

CHARITY: Totally. I think that one way of thinking about the SOA or microservices is that it pushes a lot of what was in the operations realm into a realm of development, and suddenly you're responsible for a lot more of the operating of your services, things like retries and backoffs, and load distribution, and thundering herds, and all these things that ops traditionally took care of. Well, now you have to think about them. So you need some ops tools, too. What I like about...of course I like everything about Honeycomb because we designed it for this problem. But it speaks in the language of variables, and endpoints, and functions, and not in the low-level language of proc IPv6 timeouts and stuff where I feel like ops has also traditionally been the translation layer between software engineers and their actual code in production. And it's time to start giving software engineers those tools in their own language.

+ +

CHRIS: Yeah. I love that. And I'm very happy to have Honeycomb as part of an instrumentation stack, which actually shifts me to the next question, which as I look at Honeycomb, very quickly the first time I saw it, I was like, oh okay, this makes sense. I want this in the world.

+ +

CHARITY: Oh, I like you. [laughs] Not all people are like you.

+ +

CHRIS: It might have been my second or third look, but it was definitely...once I got it, I was like, oh yes, I absolutely want that. But now, the question that I have is I typically will have a collection of tools that exist in this space. And there's a weird Venn diagram overlap of well, there's logging, and there's error tracking, and there are APM performance tools, and there's metrics, dashboards. And my sense is that Honeycomb perhaps can or an observability tool more generally can subsume a bunch of those, but it's not clear to me exactly. I think I probably still want logging. I think I still want error tracking as a discreet service tool that I'm using but maybe not APM and maybe not metrics as a distinct thing. Maybe I can infer those from a tool like Honeycomb. But I'm wondering what's the current thought on that?

+ +

CHARITY: Well, part of what you're seeing is just observability tooling is very new, and we haven't had time to grow up. And here I'm like, officially, we play very nicely with all other vendors, and none of us would ever try to compete or take away from each other's faces. But I do think that ultimately, logging pretty much the only real use case for it is security stuff, the security archiving, just keep every log light. It's gotten cheap enough, but it's not actually useful for debugging or understanding your system, not really. It's useful for compliance. It's useful for proving that you did something in the past. Most logs are just a pile of trash, but they can be useful trash. And I understand people's emotional want to hold onto them for a while, and there's nothing wrong with that. There's nothing wrong with keeping some trash around for a while, while you make it...[laughs] Sorry, not to totally slam on logs, but they are trash.

+ +

CHRIS: I love the analogies that we're going for. [laughs]

+ +

CHARITY: But the thing about observability is I do think the kind of center of the world is these arbitrarily-wide structured data blobs from what you can infer logs, from which you can infer metrics, from which you can roll-up. So I do think that well metrics are the right first tool for understanding infrastructure. Like if you're Amazon and you're responsible for all this hardware and stuff, you should be asking yourself, is my service healthy? But if you're someone who's writing and shipping code on top of that service you care about, can my request complete? What is my user's experience? And that's observability's territory. So I think that ultimately, I do think metrics, logs, and traces all get subsumed under the observability umbrella and performance management, too, if the tools get built correctly. There will still be use cases. They will just get smaller, for logs, for standalone metrics tools.

+ +

Honeycomb just launched our metrics product. Metrics is like a 30-year-old piece of technology. Prometheus and Datadog are going to be the last best metrics tools ever built. We have wrung the water out of this laundry. [chuckles ] But we aren't trying to compete with that. What we are trying to do is give people an on-ramp into Honeycomb. They've got decades’ worth of stuff. They've been corralling metrics, structuring them. You rely on them. You don't want to give them up. So yeah, let's feed them in. Let's give them an overlay. And number two, the more interesting use case for me is when you're a software engineer who's writing and shipping code, you do care about did the memory usage just triple, or is the CPU completely buzzing after I shipped my last change? But there's really only like three or four of those metrics that you really care about as system metrics. The rest are mostly legacy.

+ +

CHRIS: I like the idea that aspirationally, Honeycomb is moving towards a place where given sufficient input data, given this arbitrarily-wide data blob with high cardinality, et cetera, that we can infer basically all of those others from it. But also speaking to also observability is somewhat new, and so we got to build a lot of product to get there and that idea that there is perhaps a space right now where you might be bringing together a few of these tools. But if there is a future world in which I can have one of these tools that just handles everything and tells me about my code and directs me to the line of code that I incorrectly instrumented, that would be wonderful. Happy to do the work in the interim to cobble it together from the pieces.

+ +

CHARITY: The place in the meantime that we're at where all of these big vendors are acquiring other vendors and trying to put together...they're like, we have three pillars. Coincidentally, we have three products to sell you. It's like, it's not good for the users because when you're...like, you're sitting in the middle here. You've got your metrics dashboard. It's telling you that there's a problem. Okay, if you can't slice and dice and figure out what it is, you have to jump over into logs and visually correlate based on the times and hope no timestamps are wrong and try and find the thing. And then, oh, okay, so you want to trace it. So you've got to copy over and try and find that in your tracing product and hope that that would get sampled in. It's not good. You can't follow the question from the beginning. I have a problem to the end. I have a solution and back. And it's not linear. You're going to be following a trail; then you're going to need to back up, then you're going to find another trail. And then you're going to want us to zoom out and see who else is impacted. And you really can't back your way into that with different products. You have to start with the arbitrarily-wide structured data blob.

+ +

What does confuse me is I know that New Relic is built on this. New Relic has these. And we almost didn't start Honeycomb because we were just like, edit data, and New Relic is going to figure it out. Here we are like six years later, and they still haven't fcking figured it out. [laughs] But like Datadog, they aren't based on that arbitrarily-wide structure, so they are really...and I know that they're trying to get...all of these big vendors are trying to get to where Honeycomb sits technically faster than we can grow up and become a business.

+ +

CHRIS: The race is on.

+ +

CHARITY: Yeah. It's fun.

+ +

CHRIS: One of the related things that I've seen you talk about a few times is the idea that instrumentation is a muscle. It's a habit that needs to be developed and fostered, and that rings very true to me. At the same time, a lot of my instrumentation work has been more in a reactive space. If we're being completely honest, something went wrong; we can't figure it out from the information that we have available, so then we go in, and we add a new logging line. We wrap the code in some way. And so I'm wondering if you can talk a little bit more about that. What does that look like in practice or perhaps some examples or something? But how can we tease that apart and understand that a little bit better? Because it sounds wonderful to me.

+ +

CHARITY: I think of instrumenting a lot like commenting your code. It's a way of thinking to the future and reverse engineering; what am I going to care about? What is someone else going to care about? And I really do think of commenting as just a less true version of instrumentation, honestly. It's you talking about what you think the code should be doing, but you've left production out of the loops. You don't know what the code is doing. [chuckles] But ideally, they're kind of the same muscle. It's why you're writing your code. You've just developed a monitoring thread almost in your brain. It's like, yeah, this is going to be valuable. Oh, this is going to be valuable. And so I do think that it's on vendors to make sure that we do as much for you as possible. And this, honestly, is the long winding journey to Honeycomb finding product-market fit, which took almost three and a half, four years.

+ +

And for a long time, I was like, it’s not magic. You have to understand your code. You have to blah, blah, blah, which is true. But also, we need to walk closer to the user. We need to make it easier. We need to do the beeline, which will initialize the event, pre-populate it with a bunch of stuff, create the framework so that all you have to do as a user is just printf now and then just stuff this in the blob, vendors making it as easy as possible, as automated as possible. We have more to do. We really should be pre-populating it with all of the language internals and all of the stuff about the environment. We'll just be glad to tap that well. But there's something that we can't do for you, which is understand what you're trying to do and what is important.

+ +

Honestly, here's a story from the past. The reason that New Relic was so big, they hit the ground, and they super hockey-sticked everything was because they dovetailed with the rise of Ruby and Rails because Ruby allows for so much fcking monkey patching. Every web app looks the same. You can just be like, we assume all this crap, and so we could make it just like magic for you. You just install this library. Boom, you're off to the races. Well, try as you might, I want to say a type language like Go, you can't do that stuff with. You can't make it as magical. You have to think a lot more about how you're structuring things for better or for worse, which is why their growth slowed because those languages just aren't so popular anymore.

+ +

So it's trade-offs all the way down. Yes, everybody should be an expert in forecasting the future and understanding all the subtle things that you don't know you're going to know, but you're super are going to want to know. But as you've discovered, most of your learning comes from being in the trenches, which is why it's so good for devs to be on call and be close to their code and be in this constant conversation with it because you develop a sixth sense. I can't tell you exactly why I know it's going to be a problem, but I'm just going to wrap it because I'm pretty sure it is.

+ +

CHRIS: There was a tiny bit that I was hoping that you would have some very specific like, oh, you just do X, Y, and Z. I kind of knew that wasn't going to be the answer, but it also represents something that I so appreciate about your thinking and the work that you put out into the world, which is it's realistic. Sometimes you're like, you know what? There's going to be some tacit knowledge involved here. You got to put in the work. You got to learn the thing, and that's just true sometimes. And so I appreciate your willingness to be like yeah, you know what you got to do? You got to do the work. And then after that, you'll know...and so there's sort of a virtuous cycle that can happen here. There is a feature, as far as I understand it, of Honeycomb, too if I can briefly hype up your products slightly but the idea that you can observe the series of questions that another developer asks. So if they were in a debugging session, you can see like, oh, they asked this, and then they asked this, and then they filtered on that.

+ +

CHARITY: It's like your Bash history but for debugging. [chuckles].

+ +

CHRIS: I want this for everything.

+ +

CHARITY: Right?

+ +

CHRIS: Let's have a shared hive mind of the developers on a team, both in terms of our observability tool but also just kind of everything.

+ +

CHARITY: What did you do?

+ +

CHRIS: Yeah, what did you do, and why? What were you thinking? I saw you went down a road there, but then you stopped and backed up, and you went a different way. That's interesting to me.

+ +

CHARITY: This is why we keep trying to build things into the product that will incentivize people to write texts about what they're doing, whether it's retroactively applying tags or writing a breadcrumb to yourself. Why was this meaningful? As you're putting it in your bookmarks, why are you putting it in your bookmarks? Collaboration is just as much about collaborating with your past self and your future self as it is with the rest of your team. I don't remember why the fck I did that two years ago. I don't know. I don't know why I did that two months ago. But the more you can leave breadcrumbs for yourself and then surface that to the team, you're right; it’s transformational.

+ +

I wanted this so selfishly because I have never been that person on the team who loves graphs. I hate graphs. I don't think visually very well at all. I've been working with my friend, Ben Harts, off and on for like 10, 12 years now. He's always the person I've hired repeatedly. He's always the person who comes in and makes the graphs. And then I look over his shoulder, and I bookmark them. I can be up all night making the perfect dashboard. And then I'm like, great, mine. [chuckles] So there's room in the world for both of us. But the point is that not all of us should have to go through that effort. [chuckles] We should be able to learn from each other. Only one person should ever have to have to craft the perfect query, and then the rest of the team should be able to effortlessly piggyback on it.

+ +

CHRIS: Yeah, absolutely. And again, I want that but for everything. I dream of a future in which that's true.

+ +

CHARITY: And so much of debugging is this wandering path where you go down the wrong place, and you need to be able to zoom back to all right; where did I first know that I had a beat on it?

+ +

CHRIS: There's a corollary that I see to pair programming where one of the things that I find so valuable is, what Google query do you type in when you hit that wall? When you're like, oh, this isn't working as I'm thinking, and then you type something and I'm like, whoa, wait, I wouldn't have even thought to ask that question of the internet.

+ +

CHARITY: Oh, I love that. That's fantastic.

+ +

CHRIS: But now you've productized that, and I love that. So thank you for building that thing in the world.

+ +

CHARITY: Excellent.

+ +

CHRIS: Shifting gears slightly, one of the other themes that you really pushed for in the world is the idea of continuous deployment and not like yeah, you should ship your code pretty quickly after you merge it, but true, sincere continuous deployment.

+ +

CHARITY: 15 minutes or bust.

+ +

CHRIS: 15 minutes of bust, test in production. There are some really wonderful if we're being honest, scary themes that you talk about. I love the ideas that you're putting out there, but they're probably the things that I look at, and I'm like, ooh, that seems like a whole thing right there.

+ +

CHARITY: It assumes a lot. Let's put it that way. It assumes a lot.

+ +

CHRIS: It definitely does that. I desperately want to get to that world. I want to get to the place where there's that confidence. And similarly, there's a theme that you've talked about around Friday deploy freezes and why that's not a good thing. And the empathy for humans that part's good, but maybe we're applying it in the wrong way if we say we're not allowed to deploy code on Friday. Because it's like yeah, deploying code is terrifying and scary. No, let's solve that problem. But I wonder if you can talk a little bit about that. How do you get there? How do you get to the place where continuous deployment is a realistic outcome for you?

+ +

CHARITY: Yeah, that's a very good question. There are no easy answers, unfortunately. And the answer is always going to depend on where are you starting from? Are you starting from a clean slate? Are you starting...a lot of the advice that I give sounds like Looney Tunes to someone who's coming from enterprise because they're just like, "You don't understand the constraints that I am operating under." And I'm like, "Yeah, you're right. I'm not of your world. That probably shows." [chuckles] So I think the easiest way, though, is always when you're starting a new project that what you do on day one would be to set up your CI/CD and deploy it to prod before you've even started building. My favorite analogy to that is to like...you know the myth about Alexander the Great and his horse how when he was a little boy he would pick it up every day before he had breakfast? And so, by the time he was an adult, he could pick up his horse because he picked it up every day, and it was never hard.

+ +

When you start deploying that way, it's never hard. When you're just like, okay, anytime this gets above 10 minutes, we're going to put in a couple of hours of work, and it's never hard. It's just the easiest thing in the world. And everything's easier because you get to watch what you're doing and in real-time, and you develop that muscle of I’m merging it to main. I'm going to go look at it in a couple of minutes. And you don't feel done in your gut until you've looked at it. And that's doing it on easy mode. And you can do this in a hybrid way. Even if you have like, well, I'm paying for a deploy. Nobody is saying you have to sign up for a long, painful deploy process when you got to spin up a new project. And I've seen it gain momentum. If you start something that's clearly the new way, everybody sees how fast this team is executing. Everybody wants a piece of it. And so you start learning from the way that you are able to do it in your unique environment. You're the best evangelist to the rest of your team members because you know the subtleties. You know the problems. So that's the easy answer is start fresh. [laughs]

+ +

CHRIS: [laughs] That makes sense. I do, again, I appreciate the pragmatism or the realism of the way that you approach a lot of the topics.

+ +

CHARITY: Another answer, though, it's just that the engineering work involved in taking a deployed pipeline down from hours, days, to 15 minutes it's just engineering work. It is just labor. It can be done. The political problems are the hard ones. I mean, in the past, sometimes our deploy probably would get up to two or three hours, and we were just like, oh God, this is not…put in the work. You just start instrumenting your pipeline, and you start looking at where the tests are taking time. And it will pay dividends every bit of time that you pay down, which is why I really see these long…our own pipelines is it's a vacuum of engineering leadership that they've allowed it to happen because there's nothing fancy about it. You just put in some work.

+ +

CHRIS: Yeah, the solvability of the technical challenge feels very true, but what you're saying of it's people problems which again, that's always true of the tech stuff.

+ +

CHARITY: It is people problems, but I also hate it when people are just like, oh, it's people problems. That means mysterious and unsolvable. Now, most of the time, when you see this, it's a lack of collective confidence in themselves. They see this as being as just for the elite engineers, or only ex-Googlers are allowed to do this or something. Or they go to conferences, and they hear about it, and they're just like, God, I wish I was allowed to do that, or I wish we could do this.

+ +

But the thing is that engineers have more power than they realize. We build these companies. They wouldn't exist if it's not for us. We have all the power if we just choose to use it. I know that a lot of these people who I've talked to that were just like, "Oh, I wish we…" I'm like, "Have you ever lobbied for it?" And they're like, "No, I just know we could, or that's someone else's decision." I'm not going to promise you that you can get whatever you want. But I promise you that if you start speaking up if you start talking to your colleagues and being like, "Wouldn't it be nice?" And they start speaking up...if a quarter of the engineers want something in the company, it gets done. [chuckles]

+ +

CHRIS: That definitely feels true. And to the topic of actually lobbying for this and having the hard conversations internally and working on the people problems, you have done, I think, a really fantastic job of providing actual benchmarks in terms of timing and what does this look like as a practice and what are the multitasks?

+ +

CHARITY: It's so expensive. It's so costly to organizations. And it's the easy answer for any engineering leader to be like, "Well, we need to hire." That is the laziest answer in the world. You probably don't. You probably just need to fix your CI/CD system and then bask in the resources that you suddenly freed up. [chuckles]

+ +

CHRIS: You have a wonderful blog post that really I think does such a good job of highlighting the cost that you're talking about there, the human costs for every slowdown in your deploy process, it has this downstream ramification. And having that as sort of a piece, a bargaining chip in the conversation of here's a voice that is saying a very clear thing about this cost of not doing this work, which granted, it's always trade-offs. Everything is an optimization. But here is a way to actually measure the cost of not going with this approach. And again, I appreciate you're putting that out there in the world so that the rest of us can be like, "Look, on the internet, it says so."

+ +

CHARITY: [chuckles] Exactly. I'm happy to be the internet for you. But it's so true because other people in your business don't want you to suffer too, either. They don't want everything to get slow. They just aren't equipped to understand the cost of this slowness the way that engineers are. And I feel like sometimes this is...it's like we're always lamenting like, why does product get to own all the engineering cycles? Where aren't we allowed to do all this other stuff? I promise you're allowed to. You just have to make the case because the case is righteous and justified. But you have to explain to them the cost that it's incurring your organization in terms of your ability to execute and in terms of your ability to hire and retain people. You just have to explain those costs. And engineers are just like, "Well, we only say it once, right?" Well, that's not how you win arguments. You have to say it. You'll probably lose. And you say it again, and you'll probably lose. You say it a third. And you will win eventually because you control all of the creative labor of the technical organization. So just make the fcking case. [chuckles] I don't know. I make it sound simple; it’s not.

+ +

CHRIS: I love the sound bite of the cause is righteous, and that is the kernel of the thing here, which is like, just to be clear, this is a virtuous path that you were going down, battle for it, work towards it, absolutely. So I think a related topic here, so continuous deployment is one of those things that you want to get to and a practice that you want to evolve to. But in exploring some of your other work, one of the things that I was exposed to is the DORA metrics, which is not something that I hadn't seen before. But for anyone who's unfamiliar, the DORA metrics is a set of four key metrics to track developer and team productivity, so their deployment frequency, lead time for changes, change failure rate and the time to restore the service. And they are deeply interesting because frankly, I have for a long time felt like developer productivity was not really a quantifiable thing.

+ +

CHARITY: It's not, yeah.

+ +

CHRIS: Individual developer productivity I still feel like this is a bad thing. Don't do that. But team productivity these metrics actually are like oh, actually, as I look at those, those seem like the good ones. We should do that. I'm wondering, what does that look like in practice when you see that actually employed within an organization? What are the feedback loops, and how does this appear in the world?

+ +

CHARITY: Yeah. We all owe a huge debt of gratitude to Jez Humble, Gene Kim, and Nicole, who worked on this for years and got this out into the world, just putting some actual research behind the stories that we were telling ourselves about productivity. And people who haven't read Accelerate...a lot of people are always asking me, do we have any stories? Do you have any research? Do you have any proof or something? I just always point to the book Accelerate. That's where it all comes from. Yeah, it's true because it's such a noisy world. When you're an engineering org, and there's just so much going on, and there's so much stuff that bugs you personally, and some of the stuff that you have true beliefs about. And it's hard to just cut through the noise.

+ +

And I feel like that's the great gift of the DORA metrics. If you start focusing on one of them, you will lift your org out of poverty, and the others will get better too. And it provides just this wonderful focus point for teams that aren't sure where they stand or aren't sure how to get better because it can be so mystifying. When you're in the trenches, and you're just like, why does everything feel so hard? Why is it that we thought this would take two days, and here it is two months later, and we can't ship anything? And it feels like the more we ship, the farther behind we get. These are the beacon of hope. It's like, you pay attention to these, your lives will get better. You can dig yourself out of this ditch.

+ +

That's certainly been true for the teams that I've been on. And high-performing teams, I think we all have this idea in our heads that high-performing teams are ones where the great engineers join when in fact, those great engineers could join your team, and they wouldn't get any more done than you are. Because most of our productivity is defined not by the data structures and algorithms that you know but by these social-technical systems that we swim in every day, it’s the water around us. It's the friction involved in getting that code to production. If it takes the magical engineer from Google 24 hours to get their code changed out, well, they're not a member of a high-performing team either.

+ +

You mentioned earlier all these people are out there who haven't experienced a world like this don't live in a world like this. And in my experience, they often lack a lot of confidence because they don't think they're that good, or they don't think that they can have nice things. And the DORA metrics that's your ticket to a better life. It's like go to college and graduate because it kicks off these virtuous feedback loops, these cascading cycles of things getting better for everyone and people getting more excited and energized. And they just don't get burned out by shipping too much code. They get burned out by not being able to ship code.

+ +

And if you're a leader in any type of organization, and I don't just mean manager, I mean any type of senior engineer or manager or whatever, then it's part of your job to pay attention to these metrics, lobby for them, track them, track them on your own if you must, and try to make them better because every engineering team has two customers or two...whatever. I'm blanking on the word. But it's your customers and your engineering team. You're responsible to both of them. And I've never seen one of those sets deliriously happy and the other set miserable. They tend to rise and fall in tandem.

+ +

CHRIS: I'm just nodding along for anyone in the audience who can't see what my head's doing. But I love so much all of the things that you're saying and, again, the passion and conviction that you bring to this conversation because these are amorphous, hard to pin down ideas. But I appreciate the North Star that you're setting across all of these different things that as I'm reading, I'm like yeah, that sounds true. I want that. Those things are the things that I want. But interestingly, one of the other threads that I see weaving through a lot of your work is obviously we've talked a bunch about just deeply technical topics thus far, but also a lot of your work spans across to the interpersonal. And frankly, even dividing in that way is not representative of the world because it's a Venn diagram mishmash of some days it's technical, some days it's personal, some days it's both. But one of the things that you've talked about is the engineer manager pendulum which I find super interesting. I think every engineer at some point has that question, that internal oh, do I want to go engineer track or manager track? And this distinct idea or the idea that management is a promotion and any other movement would be different, and you have wonderful things to say about that.

+ +

The other thing that you've pointed out is that former managers can often make great engineers after the fact because of the earned empathy that they have now from looking at things from a slightly different angle.

+ +

CHARITY: Amazing engineers.

+ +

CHRIS: But I'd love to hear a little bit more of your thoughts on that because I think it's such an important space, and I've definitely previously operated under I'm an engineer, and then I guess I got to be a manager, and then I guess I don't know where I go from there, but it's this very linear path. And you shook that worldview of mine, and again, I appreciate that shaking. But yeah, I'd love to hear a little bit more about that.

+ +

CHARITY: The best people that I've ever worked with have been engineers who had been managers for a while and then went back to engineering, and it's not just empathy, although there's a lot of that too. It's also a deeper understanding of the business and the reason that we do things. So much of being a powerful engineer is choosing the right work to work on so that you get a lot done very efficiently and quickly, and you don't spend a lot of time just foundering, which you've mastered, and you know the basic technical principles. And how do you get better? A lot of it is just getting better at identifying what to do and what not to do because we have to not do so much more than we can ever do in order to move forward.

+ +

I wrote a blog post as a present for a friend of mine who was a director of engineering at the time, and he was suffering. He was just miserable, and he kept thinking about going back to engineering, just kind of dragging his...because he wasn't in an org where that was really celebrated or anything. When you've been there from the beginning, you built the organization; you’re like a senior director and everything. It feels like a long way to fall. And I wrote that post for him. And he did end up going on to be an engineer after that. And he was so much happier. But I think he was surprised at how he didn't fall at all. He actually probably had...I think the engineers had a higher opinion of him afterwards when he was one of them again. And he still had this vaunted voice because he could speak to how the system had been there since the beginning. And he basically got to look around and look out farther than the engineers who were heads down every day and go, "This is going to bite us. I'm going to take a small team. We're going to do this forward-looking security product."

+ +

I don't want to identify details, but that for me really just kind of cinched...It was like the more we can strip hierarchy out of these discussions; the healthier everyone's going to be because we're just monkey brains. And the monkey brain in our skull hates losing hierarchy, hates losing power or stance or anything. And I think that the thing that you learn after you've been a manager is a lot of it is just the wizard behind the curtain, the idea that you have more power as a manager. You have more of some types of power, and you have a lot less of other types. And you're just as constrained as the engineers but in other ways. And the path moving forward is not to dominate people or be above them but to combine your powers for good and self-sort to find a place that actually gives you the most joy.

+ +

CHRIS: It's a wonderful philosophy. And actually, a thing that you said in there really stuck out to me, which was you wrote that blog post as a gift to someone, and that is such a kind thing to do. And it also, again, reflects what I see in your work overall. You're really clearly leaving a trail of breadcrumbs behind you to help other folks that are traversing a similar path by questioning aspects of it. Or how do we do this well? Why is everyone sad, and why is it bad? And so again, I so appreciate all of that work that you've done.

+ +

CHARITY: I think that that comes from my lifetime in the trenches of operations. [chuckles] Ops is notorious for the pain that we bring upon ourselves and try to solve. But I would just like to add a pitch out there for other ops engineers of the world and our colleagues. I was fortunate enough to rise up through the ranks in organizations that really respected operations. We always felt we ruled the roost. We felt like we were way above all the other developers. We got to say what went into production and what didn't. And I feel like ultimately...if you have to have an imbalance of power, I think that's slightly healthier than the developers ruling the roost. Ultimately, there shouldn't necessarily be any imbalance of power. But I just want to pitch it; this whole no-ops thing really got my goat for a while there because operations is just the engineering workaround delivering value to users. I think the second wave of DevOps is now about okay, software engineers; it’s your turn. It's time to learn to write operable software. And so I just wanted to throw in my hat in the ring for all the ops people out there. You're just as good. You're just as good as anyone else. [chuckles]

+ +

CHRIS: I mean, it's sort of a theme that I've seen in your writing of everybody's doing good, important work and breaking down hierarchy and just collaboratively moving in the same directions and trying to choose the right North Stars to aim towards. And yeah, it's all fantastic. And so with that, I think we probably reached a perfect spot to wrap up. But Charity, if folks want to keep up with more of your work online, where are the best places to find you?

+ +

CHARITY: My blog post is at charity.wtf, and I'm @mipsytipsy on Twitter, and of course Honeycomb.io and our blog.

+ +

CHRIS: We will include links to all of that and many of the blog posts, and other podcasts interviews that you've been on, and a bunch of just various things that I collected as I was preparing for this episode because, again, you've produced such a wealth of information on the internet that I want to point as many folks as possible towards those things. But yeah, thank you so much for taking the time.

+ +

CHARITY: My pleasure.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,; you as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

Support The Bike Shed

]]> + + + Tune in as Co-founder and CTO of Honeycomb, an observability platform, Charity Majors joins Chris to drop some knowlege bombs such as:

+ +
    +
  • Thinking of observability as being about the unknown unknowns: Allowing for high cardinality, high dimensionality, ad hoc queries at any point in time.
    • +
  • Comparing instrumentation to a muscle: It's a habit that needs to be developed and fostered.
    • +
  • Sincere continuous deployment: 15 minutes or bust.
    • +
+ +

And bunches more, since y'all know you hear her name come up at least once during every other episode!

+ + + +

Transcript:

+ +

CHRIS: Hello, and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week Steph is taking a quick break, but while she's away, I was joined by a special guest, Charity Majors. Now, folks who've been listening to the show lately will know I've been mentioning one idea or another from Charity almost every episode these days. Charity's work spans from the deeply technical through to the deeply human. And across all of it, she brings such a wealth of experience in pragmatism while consistently providing grounded, actionable advice about how we can improve all aspects of our work.

+ +

And to give a bit more context for those who aren't as familiar with Charity's work, she is the co-founder and CTO of Honeycomb, which is an observability platform that we talk about more in the episode. Charity is also a prolific blogger, tweeter and speaker, and general leaver of digital breadcrumbs for the rest of us to hopefully follow. And Charity is also one of the hosts of the o11ycast podcast. That's observability, o11y podcast. And in fact, in the intro to the first o11ycast episode, Charity provides a beautiful summary of her approach to the varied work that we do. Quote, "I'm someone who's always been drawn to where the beautiful theory of computing meets the awkward, messy reality of actually trying to do things." And that quote rang so deeply true to me when I heard it and really encompassed what I see across the variety of work that Charity has shared with us. And frankly, I've been so impressed with the quality and quantity of wonderful content that Charity has shared over the years. I was really just thrilled to get the chance to sit down and talk with her directly. So without further ado, here's our conversation with Charity Majors. Thanks so much for joining us today, Charity.

+ +

CHARITY: Thanks for having me. It's great to be here.

+ +

CHRIS: As I've mentioned on many an episode, I've been following your work for a while now. And at this point, I would say that just about every Bike Shed episode has a reference to you and some piece of work that you have put out into the world, whether it be a tweet or a blog post, or a conference talk or something. So I'm so grateful for all the work that you put out into the world and for taking the time to chat with us today.

+ +

CHARITY: That's so exciting. Yay. I feel right at home here then. [chuckles]

+ +

CHRIS: Fantastic. Well, I want to dive in. I think it's sort of the core of some of the conversation that we'll be having, which is around instrumentation and observability, and observability as a newer, noveler form of how we think about this space. But to give a bit of context, I was hoping you might be able to give just the quick summary for anyone who might not be as familiar with observability as a concept and what that means now, and Honeycomb as a product and how it offers affordances around observability and pushes that envelope forward.

+ +

CHARITY: Yeah, I think of the observability as being about the unknown unknowns. For a long time, all of the complexity was really bound up in the app. You had the load balancer, you had the app, and the database. And all the complexity you could just attach to a debugger and step through it if you had to. But then we kind of blew up the app, the monolith, and now it's in services scattered to the winds, and you can't just trace it. And so observability is a way of passing that context along hop by hop so that you can actually slice and dice in real-time. And the hardest problem is not usually debugging the code. It's finding out wherein the system is the code that you need to debug.

+ +

And observability, if you accept my definition, which is it's about unknown unknowns, that you should be able to ask any question of your systems, understand any internal state just by observing it from the outside, well, then a lot of things proceed from that, in my opinion. Like, you need to be able to handle high cardinality, high dimensionality. You need to be able to string together a lot of these high cardinality dimensions. You need to... any kind of schema or indexing scheme in advance is verboten because you don't know what questions you're going to need to ask. And so there's a lot that flows from that definition; arbitrarily-wide structured data blobs is the source of truth, et cetera. But at its heart, it's just about the concepts, that our problems are getting harder and harder. We don't get paged to go, "Oh, that again? Oh, that again?"

+ +

CHRIS: [chuckles]

+ +

CHARITY: Ideally, we fix those things. But we still get paged. What the hell is this? It's about allowing engineers, empowering them in a reasonable amount of time to be in constant conversation with that code that's out there in the world because most problems honestly we never get paged about. They're too subtle until they snowball, and they pick up other problems. It's like a hairball under your couch until it gets so big and so impacting that it actually does alert someone. And then you just start picking up the rock and be like, oh God, what's that? Well, we've never understood this. And that's why ops has such a reputation for masochism. [chuckles]

+ +

CHRIS: Absolutely. There are so many little pieces in what you just said that really deeply resonate with me, although there is one facet of some of the way that you talk about observability that I find interesting. I'm someone who likes to cling to the perhaps unrealistic these days ideal of a monolith of what if we were to just keep everything in the same place and all the data lived together in one database, and I could have foreign keys, and consistencies, and asset compliance?

+ +

CHARITY: Which you should do for as long as you possibly can. You should never impose more complexity on yourself than you absolutely need to. And I would say that it's never not better to have observability than the older paradigms of monitoring and so forth. Some of Honeycomb's biggest and best customers still use monoliths. But they still find it really valuable to be able to apply the principles. I think that it's the microservices revolution, if you will, that forced this set of changes. It was inevitable. The steps that I started talking about, like, somebody would have because the older way just became untenable when you started adopting containerization and a lot of these things that made everything suddenly a high cardinality including the number of applications you have. But it's never not better to have high cardinality tools and to be able to instrument your code for spans and tracing. Tracing is still valuable even in the monolith.

+ +

CHRIS: Yeah. As I've observed and started to play around with Honeycomb, that's definitely what I've seen is I'm almost exclusively working in the context of monoliths and, like I said, clinging to them for as long as I possibly can, which isn't going to be forever.

+ +

CHARITY: It's true. [chuckles]

+ +

CHRIS: I recognize that truth, but already I see the value. And so Honeycomb is a platform that you've built that allows for this high cardinality, high dimensionality ad hoc queries at any point in time. And so the idea that I can come into the tool and say, "Huh, I've got a new novel problem today." I don't need to re-instrument my code. I can just ask a new question, and the system will responsively be able to answer that question, ideally. And that feels like it holds true in a monolith all the more so, like you said, in an SOA architecture. But even in my safe little playground of everything is in the same space, I still don't know how everything's working all the time if we're being honest. So being able to answer those questions feels meaningful.

+ +

CHARITY: Totally. I think that one way of thinking about the SOA or microservices is that it pushes a lot of what was in the operations realm into a realm of development, and suddenly you're responsible for a lot more of the operating of your services, things like retries and backoffs, and load distribution, and thundering herds, and all these things that ops traditionally took care of. Well, now you have to think about them. So you need some ops tools, too. What I like about...of course I like everything about Honeycomb because we designed it for this problem. But it speaks in the language of variables, and endpoints, and functions, and not in the low-level language of proc IPv6 timeouts and stuff where I feel like ops has also traditionally been the translation layer between software engineers and their actual code in production. And it's time to start giving software engineers those tools in their own language.

+ +

CHRIS: Yeah. I love that. And I'm very happy to have Honeycomb as part of an instrumentation stack, which actually shifts me to the next question, which as I look at Honeycomb, very quickly the first time I saw it, I was like, oh okay, this makes sense. I want this in the world.

+ +

CHARITY: Oh, I like you. [laughs] Not all people are like you.

+ +

CHRIS: It might have been my second or third look, but it was definitely...once I got it, I was like, oh yes, I absolutely want that. But now, the question that I have is I typically will have a collection of tools that exist in this space. And there's a weird Venn diagram overlap of well, there's logging, and there's error tracking, and there are APM performance tools, and there's metrics, dashboards. And my sense is that Honeycomb perhaps can or an observability tool more generally can subsume a bunch of those, but it's not clear to me exactly. I think I probably still want logging. I think I still want error tracking as a discreet service tool that I'm using but maybe not APM and maybe not metrics as a distinct thing. Maybe I can infer those from a tool like Honeycomb. But I'm wondering what's the current thought on that?

+ +

CHARITY: Well, part of what you're seeing is just observability tooling is very new, and we haven't had time to grow up. And here I'm like, officially, we play very nicely with all other vendors, and none of us would ever try to compete or take away from each other's faces. But I do think that ultimately, logging pretty much the only real use case for it is security stuff, the security archiving, just keep every log light. It's gotten cheap enough, but it's not actually useful for debugging or understanding your system, not really. It's useful for compliance. It's useful for proving that you did something in the past. Most logs are just a pile of trash, but they can be useful trash. And I understand people's emotional want to hold onto them for a while, and there's nothing wrong with that. There's nothing wrong with keeping some trash around for a while, while you make it...[laughs] Sorry, not to totally slam on logs, but they are trash.

+ +

CHRIS: I love the analogies that we're going for. [laughs]

+ +

CHARITY: But the thing about observability is I do think the kind of center of the world is these arbitrarily-wide structured data blobs from what you can infer logs, from which you can infer metrics, from which you can roll-up. So I do think that well metrics are the right first tool for understanding infrastructure. Like if you're Amazon and you're responsible for all this hardware and stuff, you should be asking yourself, is my service healthy? But if you're someone who's writing and shipping code on top of that service you care about, can my request complete? What is my user's experience? And that's observability's territory. So I think that ultimately, I do think metrics, logs, and traces all get subsumed under the observability umbrella and performance management, too, if the tools get built correctly. There will still be use cases. They will just get smaller, for logs, for standalone metrics tools.

+ +

Honeycomb just launched our metrics product. Metrics is like a 30-year-old piece of technology. Prometheus and Datadog are going to be the last best metrics tools ever built. We have wrung the water out of this laundry. [chuckles ] But we aren't trying to compete with that. What we are trying to do is give people an on-ramp into Honeycomb. They've got decades’ worth of stuff. They've been corralling metrics, structuring them. You rely on them. You don't want to give them up. So yeah, let's feed them in. Let's give them an overlay. And number two, the more interesting use case for me is when you're a software engineer who's writing and shipping code, you do care about did the memory usage just triple, or is the CPU completely buzzing after I shipped my last change? But there's really only like three or four of those metrics that you really care about as system metrics. The rest are mostly legacy.

+ +

CHRIS: I like the idea that aspirationally, Honeycomb is moving towards a place where given sufficient input data, given this arbitrarily-wide data blob with high cardinality, et cetera, that we can infer basically all of those others from it. But also speaking to also observability is somewhat new, and so we got to build a lot of product to get there and that idea that there is perhaps a space right now where you might be bringing together a few of these tools. But if there is a future world in which I can have one of these tools that just handles everything and tells me about my code and directs me to the line of code that I incorrectly instrumented, that would be wonderful. Happy to do the work in the interim to cobble it together from the pieces.

+ +

CHARITY: The place in the meantime that we're at where all of these big vendors are acquiring other vendors and trying to put together...they're like, we have three pillars. Coincidentally, we have three products to sell you. It's like, it's not good for the users because when you're...like, you're sitting in the middle here. You've got your metrics dashboard. It's telling you that there's a problem. Okay, if you can't slice and dice and figure out what it is, you have to jump over into logs and visually correlate based on the times and hope no timestamps are wrong and try and find the thing. And then, oh, okay, so you want to trace it. So you've got to copy over and try and find that in your tracing product and hope that that would get sampled in. It's not good. You can't follow the question from the beginning. I have a problem to the end. I have a solution and back. And it's not linear. You're going to be following a trail; then you're going to need to back up, then you're going to find another trail. And then you're going to want us to zoom out and see who else is impacted. And you really can't back your way into that with different products. You have to start with the arbitrarily-wide structured data blob.

+ +

What does confuse me is I know that New Relic is built on this. New Relic has these. And we almost didn't start Honeycomb because we were just like, edit data, and New Relic is going to figure it out. Here we are like six years later, and they still haven't fcking figured it out. [laughs] But like Datadog, they aren't based on that arbitrarily-wide structure, so they are really...and I know that they're trying to get...all of these big vendors are trying to get to where Honeycomb sits technically faster than we can grow up and become a business.

+ +

CHRIS: The race is on.

+ +

CHARITY: Yeah. It's fun.

+ +

CHRIS: One of the related things that I've seen you talk about a few times is the idea that instrumentation is a muscle. It's a habit that needs to be developed and fostered, and that rings very true to me. At the same time, a lot of my instrumentation work has been more in a reactive space. If we're being completely honest, something went wrong; we can't figure it out from the information that we have available, so then we go in, and we add a new logging line. We wrap the code in some way. And so I'm wondering if you can talk a little bit more about that. What does that look like in practice or perhaps some examples or something? But how can we tease that apart and understand that a little bit better? Because it sounds wonderful to me.

+ +

CHARITY: I think of instrumenting a lot like commenting your code. It's a way of thinking to the future and reverse engineering; what am I going to care about? What is someone else going to care about? And I really do think of commenting as just a less true version of instrumentation, honestly. It's you talking about what you think the code should be doing, but you've left production out of the loops. You don't know what the code is doing. [chuckles] But ideally, they're kind of the same muscle. It's why you're writing your code. You've just developed a monitoring thread almost in your brain. It's like, yeah, this is going to be valuable. Oh, this is going to be valuable. And so I do think that it's on vendors to make sure that we do as much for you as possible. And this, honestly, is the long winding journey to Honeycomb finding product-market fit, which took almost three and a half, four years.

+ +

And for a long time, I was like, it’s not magic. You have to understand your code. You have to blah, blah, blah, which is true. But also, we need to walk closer to the user. We need to make it easier. We need to do the beeline, which will initialize the event, pre-populate it with a bunch of stuff, create the framework so that all you have to do as a user is just printf now and then just stuff this in the blob, vendors making it as easy as possible, as automated as possible. We have more to do. We really should be pre-populating it with all of the language internals and all of the stuff about the environment. We'll just be glad to tap that well. But there's something that we can't do for you, which is understand what you're trying to do and what is important.

+ +

Honestly, here's a story from the past. The reason that New Relic was so big, they hit the ground, and they super hockey-sticked everything was because they dovetailed with the rise of Ruby and Rails because Ruby allows for so much fcking monkey patching. Every web app looks the same. You can just be like, we assume all this crap, and so we could make it just like magic for you. You just install this library. Boom, you're off to the races. Well, try as you might, I want to say a type language like Go, you can't do that stuff with. You can't make it as magical. You have to think a lot more about how you're structuring things for better or for worse, which is why their growth slowed because those languages just aren't so popular anymore.

+ +

So it's trade-offs all the way down. Yes, everybody should be an expert in forecasting the future and understanding all the subtle things that you don't know you're going to know, but you're super are going to want to know. But as you've discovered, most of your learning comes from being in the trenches, which is why it's so good for devs to be on call and be close to their code and be in this constant conversation with it because you develop a sixth sense. I can't tell you exactly why I know it's going to be a problem, but I'm just going to wrap it because I'm pretty sure it is.

+ +

CHRIS: There was a tiny bit that I was hoping that you would have some very specific like, oh, you just do X, Y, and Z. I kind of knew that wasn't going to be the answer, but it also represents something that I so appreciate about your thinking and the work that you put out into the world, which is it's realistic. Sometimes you're like, you know what? There's going to be some tacit knowledge involved here. You got to put in the work. You got to learn the thing, and that's just true sometimes. And so I appreciate your willingness to be like yeah, you know what you got to do? You got to do the work. And then after that, you'll know...and so there's sort of a virtuous cycle that can happen here. There is a feature, as far as I understand it, of Honeycomb, too if I can briefly hype up your products slightly but the idea that you can observe the series of questions that another developer asks. So if they were in a debugging session, you can see like, oh, they asked this, and then they asked this, and then they filtered on that.

+ +

CHARITY: It's like your Bash history but for debugging. [chuckles].

+ +

CHRIS: I want this for everything.

+ +

CHARITY: Right?

+ +

CHRIS: Let's have a shared hive mind of the developers on a team, both in terms of our observability tool but also just kind of everything.

+ +

CHARITY: What did you do?

+ +

CHRIS: Yeah, what did you do, and why? What were you thinking? I saw you went down a road there, but then you stopped and backed up, and you went a different way. That's interesting to me.

+ +

CHARITY: This is why we keep trying to build things into the product that will incentivize people to write texts about what they're doing, whether it's retroactively applying tags or writing a breadcrumb to yourself. Why was this meaningful? As you're putting it in your bookmarks, why are you putting it in your bookmarks? Collaboration is just as much about collaborating with your past self and your future self as it is with the rest of your team. I don't remember why the fck I did that two years ago. I don't know. I don't know why I did that two months ago. But the more you can leave breadcrumbs for yourself and then surface that to the team, you're right; it’s transformational.

+ +

I wanted this so selfishly because I have never been that person on the team who loves graphs. I hate graphs. I don't think visually very well at all. I've been working with my friend, Ben Harts, off and on for like 10, 12 years now. He's always the person I've hired repeatedly. He's always the person who comes in and makes the graphs. And then I look over his shoulder, and I bookmark them. I can be up all night making the perfect dashboard. And then I'm like, great, mine. [chuckles] So there's room in the world for both of us. But the point is that not all of us should have to go through that effort. [chuckles] We should be able to learn from each other. Only one person should ever have to have to craft the perfect query, and then the rest of the team should be able to effortlessly piggyback on it.

+ +

CHRIS: Yeah, absolutely. And again, I want that but for everything. I dream of a future in which that's true.

+ +

CHARITY: And so much of debugging is this wandering path where you go down the wrong place, and you need to be able to zoom back to all right; where did I first know that I had a beat on it?

+ +

CHRIS: There's a corollary that I see to pair programming where one of the things that I find so valuable is, what Google query do you type in when you hit that wall? When you're like, oh, this isn't working as I'm thinking, and then you type something and I'm like, whoa, wait, I wouldn't have even thought to ask that question of the internet.

+ +

CHARITY: Oh, I love that. That's fantastic.

+ +

CHRIS: But now you've productized that, and I love that. So thank you for building that thing in the world.

+ +

CHARITY: Excellent.

+ +

CHRIS: Shifting gears slightly, one of the other themes that you really pushed for in the world is the idea of continuous deployment and not like yeah, you should ship your code pretty quickly after you merge it, but true, sincere continuous deployment.

+ +

CHARITY: 15 minutes or bust.

+ +

CHRIS: 15 minutes of bust, test in production. There are some really wonderful if we're being honest, scary themes that you talk about. I love the ideas that you're putting out there, but they're probably the things that I look at, and I'm like, ooh, that seems like a whole thing right there.

+ +

CHARITY: It assumes a lot. Let's put it that way. It assumes a lot.

+ +

CHRIS: It definitely does that. I desperately want to get to that world. I want to get to the place where there's that confidence. And similarly, there's a theme that you've talked about around Friday deploy freezes and why that's not a good thing. And the empathy for humans that part's good, but maybe we're applying it in the wrong way if we say we're not allowed to deploy code on Friday. Because it's like yeah, deploying code is terrifying and scary. No, let's solve that problem. But I wonder if you can talk a little bit about that. How do you get there? How do you get to the place where continuous deployment is a realistic outcome for you?

+ +

CHARITY: Yeah, that's a very good question. There are no easy answers, unfortunately. And the answer is always going to depend on where are you starting from? Are you starting from a clean slate? Are you starting...a lot of the advice that I give sounds like Looney Tunes to someone who's coming from enterprise because they're just like, "You don't understand the constraints that I am operating under." And I'm like, "Yeah, you're right. I'm not of your world. That probably shows." [chuckles] So I think the easiest way, though, is always when you're starting a new project that what you do on day one would be to set up your CI/CD and deploy it to prod before you've even started building. My favorite analogy to that is to like...you know the myth about Alexander the Great and his horse how when he was a little boy he would pick it up every day before he had breakfast? And so, by the time he was an adult, he could pick up his horse because he picked it up every day, and it was never hard.

+ +

When you start deploying that way, it's never hard. When you're just like, okay, anytime this gets above 10 minutes, we're going to put in a couple of hours of work, and it's never hard. It's just the easiest thing in the world. And everything's easier because you get to watch what you're doing and in real-time, and you develop that muscle of I’m merging it to main. I'm going to go look at it in a couple of minutes. And you don't feel done in your gut until you've looked at it. And that's doing it on easy mode. And you can do this in a hybrid way. Even if you have like, well, I'm paying for a deploy. Nobody is saying you have to sign up for a long, painful deploy process when you got to spin up a new project. And I've seen it gain momentum. If you start something that's clearly the new way, everybody sees how fast this team is executing. Everybody wants a piece of it. And so you start learning from the way that you are able to do it in your unique environment. You're the best evangelist to the rest of your team members because you know the subtleties. You know the problems. So that's the easy answer is start fresh. [laughs]

+ +

CHRIS: [laughs] That makes sense. I do, again, I appreciate the pragmatism or the realism of the way that you approach a lot of the topics.

+ +

CHARITY: Another answer, though, it's just that the engineering work involved in taking a deployed pipeline down from hours, days, to 15 minutes it's just engineering work. It is just labor. It can be done. The political problems are the hard ones. I mean, in the past, sometimes our deploy probably would get up to two or three hours, and we were just like, oh God, this is not…put in the work. You just start instrumenting your pipeline, and you start looking at where the tests are taking time. And it will pay dividends every bit of time that you pay down, which is why I really see these long…our own pipelines is it's a vacuum of engineering leadership that they've allowed it to happen because there's nothing fancy about it. You just put in some work.

+ +

CHRIS: Yeah, the solvability of the technical challenge feels very true, but what you're saying of it's people problems which again, that's always true of the tech stuff.

+ +

CHARITY: It is people problems, but I also hate it when people are just like, oh, it's people problems. That means mysterious and unsolvable. Now, most of the time, when you see this, it's a lack of collective confidence in themselves. They see this as being as just for the elite engineers, or only ex-Googlers are allowed to do this or something. Or they go to conferences, and they hear about it, and they're just like, God, I wish I was allowed to do that, or I wish we could do this.

+ +

But the thing is that engineers have more power than they realize. We build these companies. They wouldn't exist if it's not for us. We have all the power if we just choose to use it. I know that a lot of these people who I've talked to that were just like, "Oh, I wish we…" I'm like, "Have you ever lobbied for it?" And they're like, "No, I just know we could, or that's someone else's decision." I'm not going to promise you that you can get whatever you want. But I promise you that if you start speaking up if you start talking to your colleagues and being like, "Wouldn't it be nice?" And they start speaking up...if a quarter of the engineers want something in the company, it gets done. [chuckles]

+ +

CHRIS: That definitely feels true. And to the topic of actually lobbying for this and having the hard conversations internally and working on the people problems, you have done, I think, a really fantastic job of providing actual benchmarks in terms of timing and what does this look like as a practice and what are the multitasks?

+ +

CHARITY: It's so expensive. It's so costly to organizations. And it's the easy answer for any engineering leader to be like, "Well, we need to hire." That is the laziest answer in the world. You probably don't. You probably just need to fix your CI/CD system and then bask in the resources that you suddenly freed up. [chuckles]

+ +

CHRIS: You have a wonderful blog post that really I think does such a good job of highlighting the cost that you're talking about there, the human costs for every slowdown in your deploy process, it has this downstream ramification. And having that as sort of a piece, a bargaining chip in the conversation of here's a voice that is saying a very clear thing about this cost of not doing this work, which granted, it's always trade-offs. Everything is an optimization. But here is a way to actually measure the cost of not going with this approach. And again, I appreciate you're putting that out there in the world so that the rest of us can be like, "Look, on the internet, it says so."

+ +

CHARITY: [chuckles] Exactly. I'm happy to be the internet for you. But it's so true because other people in your business don't want you to suffer too, either. They don't want everything to get slow. They just aren't equipped to understand the cost of this slowness the way that engineers are. And I feel like sometimes this is...it's like we're always lamenting like, why does product get to own all the engineering cycles? Where aren't we allowed to do all this other stuff? I promise you're allowed to. You just have to make the case because the case is righteous and justified. But you have to explain to them the cost that it's incurring your organization in terms of your ability to execute and in terms of your ability to hire and retain people. You just have to explain those costs. And engineers are just like, "Well, we only say it once, right?" Well, that's not how you win arguments. You have to say it. You'll probably lose. And you say it again, and you'll probably lose. You say it a third. And you will win eventually because you control all of the creative labor of the technical organization. So just make the fcking case. [chuckles] I don't know. I make it sound simple; it’s not.

+ +

CHRIS: I love the sound bite of the cause is righteous, and that is the kernel of the thing here, which is like, just to be clear, this is a virtuous path that you were going down, battle for it, work towards it, absolutely. So I think a related topic here, so continuous deployment is one of those things that you want to get to and a practice that you want to evolve to. But in exploring some of your other work, one of the things that I was exposed to is the DORA metrics, which is not something that I hadn't seen before. But for anyone who's unfamiliar, the DORA metrics is a set of four key metrics to track developer and team productivity, so their deployment frequency, lead time for changes, change failure rate and the time to restore the service. And they are deeply interesting because frankly, I have for a long time felt like developer productivity was not really a quantifiable thing.

+ +

CHARITY: It's not, yeah.

+ +

CHRIS: Individual developer productivity I still feel like this is a bad thing. Don't do that. But team productivity these metrics actually are like oh, actually, as I look at those, those seem like the good ones. We should do that. I'm wondering, what does that look like in practice when you see that actually employed within an organization? What are the feedback loops, and how does this appear in the world?

+ +

CHARITY: Yeah. We all owe a huge debt of gratitude to Jez Humble, Gene Kim, and Nicole, who worked on this for years and got this out into the world, just putting some actual research behind the stories that we were telling ourselves about productivity. And people who haven't read Accelerate...a lot of people are always asking me, do we have any stories? Do you have any research? Do you have any proof or something? I just always point to the book Accelerate. That's where it all comes from. Yeah, it's true because it's such a noisy world. When you're an engineering org, and there's just so much going on, and there's so much stuff that bugs you personally, and some of the stuff that you have true beliefs about. And it's hard to just cut through the noise.

+ +

And I feel like that's the great gift of the DORA metrics. If you start focusing on one of them, you will lift your org out of poverty, and the others will get better too. And it provides just this wonderful focus point for teams that aren't sure where they stand or aren't sure how to get better because it can be so mystifying. When you're in the trenches, and you're just like, why does everything feel so hard? Why is it that we thought this would take two days, and here it is two months later, and we can't ship anything? And it feels like the more we ship, the farther behind we get. These are the beacon of hope. It's like, you pay attention to these, your lives will get better. You can dig yourself out of this ditch.

+ +

That's certainly been true for the teams that I've been on. And high-performing teams, I think we all have this idea in our heads that high-performing teams are ones where the great engineers join when in fact, those great engineers could join your team, and they wouldn't get any more done than you are. Because most of our productivity is defined not by the data structures and algorithms that you know but by these social-technical systems that we swim in every day, it’s the water around us. It's the friction involved in getting that code to production. If it takes the magical engineer from Google 24 hours to get their code changed out, well, they're not a member of a high-performing team either.

+ +

You mentioned earlier all these people are out there who haven't experienced a world like this don't live in a world like this. And in my experience, they often lack a lot of confidence because they don't think they're that good, or they don't think that they can have nice things. And the DORA metrics that's your ticket to a better life. It's like go to college and graduate because it kicks off these virtuous feedback loops, these cascading cycles of things getting better for everyone and people getting more excited and energized. And they just don't get burned out by shipping too much code. They get burned out by not being able to ship code.

+ +

And if you're a leader in any type of organization, and I don't just mean manager, I mean any type of senior engineer or manager or whatever, then it's part of your job to pay attention to these metrics, lobby for them, track them, track them on your own if you must, and try to make them better because every engineering team has two customers or two...whatever. I'm blanking on the word. But it's your customers and your engineering team. You're responsible to both of them. And I've never seen one of those sets deliriously happy and the other set miserable. They tend to rise and fall in tandem.

+ +

CHRIS: I'm just nodding along for anyone in the audience who can't see what my head's doing. But I love so much all of the things that you're saying and, again, the passion and conviction that you bring to this conversation because these are amorphous, hard to pin down ideas. But I appreciate the North Star that you're setting across all of these different things that as I'm reading, I'm like yeah, that sounds true. I want that. Those things are the things that I want. But interestingly, one of the other threads that I see weaving through a lot of your work is obviously we've talked a bunch about just deeply technical topics thus far, but also a lot of your work spans across to the interpersonal. And frankly, even dividing in that way is not representative of the world because it's a Venn diagram mishmash of some days it's technical, some days it's personal, some days it's both. But one of the things that you've talked about is the engineer manager pendulum which I find super interesting. I think every engineer at some point has that question, that internal oh, do I want to go engineer track or manager track? And this distinct idea or the idea that management is a promotion and any other movement would be different, and you have wonderful things to say about that.

+ +

The other thing that you've pointed out is that former managers can often make great engineers after the fact because of the earned empathy that they have now from looking at things from a slightly different angle.

+ +

CHARITY: Amazing engineers.

+ +

CHRIS: But I'd love to hear a little bit more of your thoughts on that because I think it's such an important space, and I've definitely previously operated under I'm an engineer, and then I guess I got to be a manager, and then I guess I don't know where I go from there, but it's this very linear path. And you shook that worldview of mine, and again, I appreciate that shaking. But yeah, I'd love to hear a little bit more about that.

+ +

CHARITY: The best people that I've ever worked with have been engineers who had been managers for a while and then went back to engineering, and it's not just empathy, although there's a lot of that too. It's also a deeper understanding of the business and the reason that we do things. So much of being a powerful engineer is choosing the right work to work on so that you get a lot done very efficiently and quickly, and you don't spend a lot of time just foundering, which you've mastered, and you know the basic technical principles. And how do you get better? A lot of it is just getting better at identifying what to do and what not to do because we have to not do so much more than we can ever do in order to move forward.

+ +

I wrote a blog post as a present for a friend of mine who was a director of engineering at the time, and he was suffering. He was just miserable, and he kept thinking about going back to engineering, just kind of dragging his...because he wasn't in an org where that was really celebrated or anything. When you've been there from the beginning, you built the organization; you’re like a senior director and everything. It feels like a long way to fall. And I wrote that post for him. And he did end up going on to be an engineer after that. And he was so much happier. But I think he was surprised at how he didn't fall at all. He actually probably had...I think the engineers had a higher opinion of him afterwards when he was one of them again. And he still had this vaunted voice because he could speak to how the system had been there since the beginning. And he basically got to look around and look out farther than the engineers who were heads down every day and go, "This is going to bite us. I'm going to take a small team. We're going to do this forward-looking security product."

+ +

I don't want to identify details, but that for me really just kind of cinched...It was like the more we can strip hierarchy out of these discussions; the healthier everyone's going to be because we're just monkey brains. And the monkey brain in our skull hates losing hierarchy, hates losing power or stance or anything. And I think that the thing that you learn after you've been a manager is a lot of it is just the wizard behind the curtain, the idea that you have more power as a manager. You have more of some types of power, and you have a lot less of other types. And you're just as constrained as the engineers but in other ways. And the path moving forward is not to dominate people or be above them but to combine your powers for good and self-sort to find a place that actually gives you the most joy.

+ +

CHRIS: It's a wonderful philosophy. And actually, a thing that you said in there really stuck out to me, which was you wrote that blog post as a gift to someone, and that is such a kind thing to do. And it also, again, reflects what I see in your work overall. You're really clearly leaving a trail of breadcrumbs behind you to help other folks that are traversing a similar path by questioning aspects of it. Or how do we do this well? Why is everyone sad, and why is it bad? And so again, I so appreciate all of that work that you've done.

+ +

CHARITY: I think that that comes from my lifetime in the trenches of operations. [chuckles] Ops is notorious for the pain that we bring upon ourselves and try to solve. But I would just like to add a pitch out there for other ops engineers of the world and our colleagues. I was fortunate enough to rise up through the ranks in organizations that really respected operations. We always felt we ruled the roost. We felt like we were way above all the other developers. We got to say what went into production and what didn't. And I feel like ultimately...if you have to have an imbalance of power, I think that's slightly healthier than the developers ruling the roost. Ultimately, there shouldn't necessarily be any imbalance of power. But I just want to pitch it; this whole no-ops thing really got my goat for a while there because operations is just the engineering workaround delivering value to users. I think the second wave of DevOps is now about okay, software engineers; it’s your turn. It's time to learn to write operable software. And so I just wanted to throw in my hat in the ring for all the ops people out there. You're just as good. You're just as good as anyone else. [chuckles]

+ +

CHRIS: I mean, it's sort of a theme that I've seen in your writing of everybody's doing good, important work and breaking down hierarchy and just collaboratively moving in the same directions and trying to choose the right North Stars to aim towards. And yeah, it's all fantastic. And so with that, I think we probably reached a perfect spot to wrap up. But Charity, if folks want to keep up with more of your work online, where are the best places to find you?

+ +

CHARITY: My blog post is at charity.wtf, and I'm @mipsytipsy on Twitter, and of course Honeycomb.io and our blog.

+ +

CHRIS: We will include links to all of that and many of the blog posts, and other podcasts interviews that you've been on, and a bunch of just various things that I collected as I was preparing for this episode because, again, you've produced such a wealth of information on the internet that I want to point as many folks as possible towards those things. But yeah, thank you so much for taking the time.

+ +

CHARITY: My pleasure.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes,; you as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+38RKer7j + + ]]> + + Chris Toomey + + + 301: Ants in the Cookie Store + https://bikeshed.thoughtbot.com/301 + 73606619-2829-4b38-b068-5d5922f7f85d + Tue, 20 Jul 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + What do you get when you mix a worm and a hammerhead shark? Also ants. Steph made some cool new discoveries in bug-land. She also talks about deploys versus releases and how her and her team has changed their deploy structure. Two words: feature flags. + +Chris talks about cookies: cookie sessions, cookie payloads, cookie footprints, cookie storing. Mmm cookies! The convo wraps up with lamenting over truthiness in code. Truthy or falsy? What's your call? + 42:17 + no + + + What do you get when you mix a worm and a hammerhead shark? Also ants. Steph made some cool new discoveries in bug-land. She also talks about deploys versus releases and how her and her team has changed their deploy structure. Two words: feature flags. +Chris talks about cookies: cookie sessions, cookie payloads, cookie footprints, cookie storing. Mmm cookies! The convo wraps up with lamenting over truthiness in code. Truthy or falsy? What's your call? +Flipper (https://www.flippercloud.io/) +Bike Shed - Ask a Question Form (https://docs.google.com/forms/d/e/1FAIpQLSdaFfPYoWmtV3IR3eQRjNz731GJ_a2X6CpZFxKjdPZeztGXKA/viewform) +Transcript: +STEPH: At the top of my notes for today, I have marauder ants and hammerhead worms. [laughs] +CHRIS: I'm sorry, what? I lost you there for...not lost you, but I stopped following. I...what? Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going? +STEPH: Hey, Chris, it's been a good week. It's been busy, lots has been happening. I learned about a new creature that's in our backyard. They're called hammerhead worms. Have you ever heard of those? +CHRIS: I've heard of hammerhead and worms, but not together. The combination is new and novel for me. +STEPH: Cool. Cool. So take a hammerhead shark and a worm and combine the two and then you have a hammerhead worm. And it rained really heavily here recently because there's a tropical storm that's making its way up the East Coast. And when I was outside on the porch, I noticed that there were these new worms or worms that I'd never seen before on the back porch. And so I had to Google them to understand because they had the interesting hammer-shaped head. And I found out that they're called hammerhead worms. They're toxic worms that prey on earthworms. And they're basically immortal because if you cut them into multiple pieces, each section can regenerate into a fully developed organism within a few weeks, which is bananas. And a lot of people online highly recommend that you should kill them because they are a toxic predator and they prey on earthworms, which you want in your garden and in your yard. But I didn't, but I learned about them. +CHRIS: Wow. That's got some layers there, toxic, intense worms that you can cut in half. And so does their central nervous system just spread throughout their whole body? Where's their brain? How does it...I don't have any real thoughts here. That's just a bunch of stuff, and it's awesome. Thank you for sharing. +STEPH: I will warn you. I wouldn't read about hammerhead worms right before bed. Otherwise, you might have some nightmares because the way that they do prey and consume earthworms or other creatures that they prey on is the stuff of horror movies, which I find happens so much in nature, but them especially they fall into that category. So just be aware if you're reading about hammerhead worms and how they consume their food. Now I feel like everybody's going to go read. But as long as you have that warning, I feel safe sending you in that direction. +CHRIS: Yeah, first thing in the morning on a very sunny morning, that is the time to do this research. +STEPH: Exactly. He got it. I also learned about marauder ants because apparently, this is the day that I'm having. I'm learning about all these creatures. But I won't go into that one, but they're really interesting. And this one's thanks to someone on Twitter who shared, specifically @Rainmaker1973 is their Twitter handle if you want to go see what they shared about marauder ants. So I'll just leave that one for those that are curious. I won't dive into that one because I don't want to take us in the direction of that we're all about worms and ants now. +CHRIS: Not all about worms and ants but definitely some. +STEPH: But in technical news, I've got some stuff to share, but I was so excited about worms and ants that now I have to figure out which is the thing that I want to share from the week. So there's a couple of interesting things that I'd love to chat about with you, one of them, in particular, is there's been some interesting conversations going on with my client team around deploys versus releases and how we have changed our deploy structure, and then how that has impacted the rest of the team as they are communicating to customers as to what features are available. And there have been some interesting conversations around how to migrate this process forward. +So to provide a bit of context, we were previously having very strict, rigid deploys. So we would plan our deploys typically every Tuesday. It was usually once a week. And then we would make sure that everything had been through QA, things had been reviewed and tested. And then we would have one of those more like grand deploys, things are going out. And then hey, if you need to get something into the deploy, let us know; we need to talk about it. So there was just more process and structure to that. And so deploy really mapped to the idea that if we are doing a deploy, then that means all these feature bug fixes are going out, and this is now the time that we can tell customers, "Hey, this new feature is available or this bug that you reported to us has now been fixed." We have since been moving towards a more continuous deployment structure where we're not quite there where we're doing continuous deploy, but we are deploying at least once a day, so it's a lot more frequent. +And so this has changed the way that we really map the idea of the work that's being done versus the work that's actually available to customers. Because as we are merging work into the main branch, and then let's say if I'm working on a feature and then I merge that into the main branch and then push it up staging, we have an overnight QA process. So then overnight QA, if they say, "Hey, there's something that's wrong with this feature. It didn't quite meet the required specs," then they can kick that ticket back to me, but that's not true for my code. We could do a revert and take my code out at that point. But at this point, it's in main, and main may have been deployed at that point. So there have been some interesting strategies around how can we safely continue to deploy while we know we often have a 24-hour wait period for QA and to get sign-off on this work? But we want to keep moving forward and then also communicate that just because the code has been deployed doesn't necessarily mean that it's available to customers. There's a lot there. So I'm going to pause and see if you have questions. +CHRIS: Well, first, I'm just super excited to talk about this. This is something that's been very much top of mind for me, and it's a direction that I want to be going more and more, so yeah, excited that you're pushing the boundaries on this. I am intrigued. I'm guessing feature flags is the answer about how you're decoupling that and how you're making it so that you've got that separation of deployment and actual availability of the feature. So, yeah, can you talk more about that? +STEPH: Definitely. And yes, you're right. We're using feature flags, so we'll use the same scenario. I'm working on a feature, and I want to be able to release it safely, so I'm going to wrap it in a feature flag. And I'll probably wrap it, and maybe it's like a beta feature flag, something to indicate that this is a feature that's going to be available to all, but we don't actually want to turn it on until we know that it's truly ready to be turned on. So then that way, it's hidden, but then we can still merge it into the main branch. We can still have a deploy even if my code hasn't gone through QA at that point, but we know it's still safe to deploy. And then, QA can go to a staging environment; they can test it. And if they say, "No," it's fine because nothing was churned in production. But then, if it gets approved, then we can turn it on, and then we'll have a follow-up to then remove that feature flag. +CHRIS: So some follow-on questions. I'm wondering about the architecture of the application. Is this like traditional Rails app rendering HTML on the server, or do you have any more advanced client-side stuff? And then I'm also wondering what you're using for the actual feature flagging, and those will probably inform each other. But what's the story on both of those fronts? +STEPH: It's a traditional Rails application. So we're not using any other client-side application. It is Rails and rendering HTML. As for feature flags, so we're not using something traditional. And by traditional, I mean I typically have reached for Flipper in the past for managing feature flags. We're using more of a hand-rolled approach because there's a lot of context there that I don't know is necessarily helpful. But to answer your question, we essentially do have feature flags as columns in the database, and we can just check if they are enabled or disabled. And then that also allows us to easily turn it on, turn it off as well since it's just a database update. +CHRIS: Okay, that makes sense. I think the nature of being a Rails application rendering HTML on the server like what you're doing totally makes sense in that context. I think it becomes a lot harder the more complex the architecture of your application is. So if you've got microservices, then suddenly you've probably got to synchronize across some of them, and that sounds like a whole thing. Or even if you have a client-side application, then suddenly you've got to serialize the feature flag stuff across the boundary or somehow expose that, which really does push the issue of we could just render stuff on the server and send it to the client and let that be good enough, then man, is stuff simpler. But unfortunately, that's not the case in a lot of situations. +I'm expecting to be introducing feature flags on the app that I'm working on pretty soon. And again, we've got...so it's a Rails server-side thing. So there's going to be plenty of feature flag logic on that side. And then I'll need to do something to serialize it across the boundary and get it onto the client-side without ballooning every payload and adding complexity, and lookups, and whatnot. I think it's doable. Inertia, again, being the core architecture of the application, I think will make this a little bit easier, but I am interested to see what I'm able to pull off and how happy I am with where I get to. +Another question that I have for you then are you testing the various flows? So given a Boolean feature flag, you now have two different possible paths for your code to go through. And then there may be even more than Boolean, or you may have feature flags that sort of interact with each other. And how much complexity are you trying to manage and represent in the test suite? +STEPH: Yeah, good question, and we are. So we're testing both flows, especially if it's a new feature, then we are testing when the flag is enabled or disabled. One that's been tricky for me is what about a bug fix? Is that something that should be feature flagged? And I think at the surface level, if you're presuming that it needs to go through QA before this is live on production, then the answer is yes, that then you have to feature flag a bug fix, which feels weird. But then the other consideration would be, well, it is a bug fix. And could we find another way to QA this faster or some other approach so that way we don't have to wrap it in a feature flag? And I don't have a great answer for that one because I can see arguments in favor of either approach. Although wrapping everything in a feature flag does feel tedious, it's something that I'm not accustomed to doing. And it's something that then becomes a process for the team to remind each other that, hey, is this wrapped in a feature flag? Or just being mindful of that as part of our process. And it prompted me to think back on the other projects that I've worked on and how did we manage that flow? How did we go from development to staging to QA and then out to production? +And one additional consideration with this flow is that we do have an overnight QA team. So in the past, when I've worked with teams, often product managers or even other developers, we would QA each other's work. So then it was a pretty fast turnaround that then you could get something up on staging. Someone could check it out and say, "Yes" or "No." But then I'm also pretty confident most of the teams that I've worked with we have had a distinct staging branch. So we would often merge work into a staging branch, and then deploy that work, and then get it tested. And then, if it passed everything, then we would essentially cherry-pick that work and move it over into production. +And I can see there's a lot of arguments against that, but then I have also experienced that and had a really positive experience where we could test everything and not have to worry about going out to production. We didn't have to wrap everything in feature flags, and it just felt really nice to know that everything in the main or production branch, whatever you call your production branch, that everything in there was deployable versus having to go the feature flag route, or the hey, did this go through QA? I don't know. Let me check. Can I include this? Should I cherry-pick some commits into our actual deployment to avoid stuff that hasn't gone through QA? I've been through that dance before too, and that one's not great. +CHRIS: I like the way you're framing the different sort of trade-offs that we have there in velocity or deployment speed and ease of iteration versus confidence as things are going out. I have worked with a staging branch before, and I personally did not find it to be valuable. It ended up adding this indirection. Folks had to know how to use Git in a pretty deep way to be comfortable with that just as a starting point. So it already introduced this hurdle of knowledge, and then beyond that, that idea that you have commits going in in a certain order on the staging branch. But then say we verify the functionality of the third commit in that list, and we want to cherry-pick it across to the main branch. Commits don't actually...you can't just take the thing that you had there. That commit existed in the context of all the others. There are subtleties of how history exists in Git. And I would worry about those edge cases where you're taking a piece of work out of the context of the rest of the commits that were around it or before it is, more importantly…that preceded it in the history on the staging branch, and you're now bringing it across to the main branch. Have you now lost something that was meaningful? +Ideally, you would get a conflict if it was really bad, but that's more of like a syntactic diff level thing. It's not a functionality-level thing. So personally, I may be overly cautious around this, but I really like as much as possible to have the very boring linear history in Git and do everything I can such that work happens on feature branches and then gets merged in as a fast forward into the main branch or rather the main branch is fast-forward marched into my feature branch such that I'm never working with code that I haven't fully worked with in an integrated way before. But again, even that, as I'm saying that, I have this topological map of Git in my head as I'm saying all of that, and it's complicated. And having any of that complexity leak out into the way we talk about the work is something that I worry about, but maybe I'm worried about a bunch of things that don't matter. Maybe a staging branch is actually fantastic. +STEPH: I think you make a lot of good points. Those are a lot of good concerns that come up with...it comes back to the idea that we want to mimic production as much as possible, and we don't want to lose that parity. So then, by having a staging branch, then it feels that we've lost that parity. There could be stuff that's in staging that's not in production. And so staging could be a little bit of this Wild West area, and then that doesn't fully represent then what's going to production. So I certainly understand and agree with those points that you're making. And to speak specifically to the Git challenges, I agree. It does require some more Git knowledge to be able to make that work. Specifically, I think how we handled it on a previous project is where we'd actually cherry-pick our commits into staging and then deploy that. But we always had the PR issued against main. So then merging into main was often a bit easier. +But then you're right; things could get out of sync. And the PR is issued against main, so then you still could run into those oddities where then if you are cherry-picking commits in the staging, but then you have your final draft that's going into main. And then what are the differences between those, and what did you lose along the way? And as I say all of that out loud, I definitely understand the Git concerns. And I don't know; I just feel like there's not a great answer then here, which is shocking to me. I've been doing this for a while, and yet here I am feeling like there's not a great answer to this very vital part of our workflow. And I'm surprised even though that we do have a delayed QA process that this still feels like a painful thing to figure out how do we have a continuous deployment workflow even though we do have that delayed QA process? +CHRIS: I think somewhat fundamentally your comment there of "I'm surprised that we don't have a good answer to this is," I'm not surprised, I guess, is my reaction. I don't want to go to the software is bad and broken, and we don't know anything end of the spectrum. But I don't feel like we have great answers to a lot of the things about development. I feel like software is more broken than it should be. It costs more to develop. It is difficult. It's hard to create, and maintain, and build over time. And that's just, to get lofty about it, that's what the entire focus of my career is, is trying to solve that problem. But it's a big, hard problem that I do not think is solved, unlike just about any of the fronts. I know how to put stuff in a database and take it back out. And even that, I'm like, oh yeah, but what if the database gets really big? Or what if the database...everything has complexities and edge cases. +STEPH: [laughs] +CHRIS: And we've joked a handful of times about the catchphrase of The Bike Shed being it depends, and that really feels true, though. I don't know that that's unique to this industry either. I feel like everything in the world is just more complicated the more you look at it, and there aren't clear, good, obvious answers to just about anything in the world, but that's the human condition. I got weirdly philosophical on this, so we should probably round this out. [laughs] +STEPH: Well, I can circle us back because I was providing context, and I went a bit into the deep end providing all of that context. So if I circle back to what I wanted to share with you around deploys and releases, there has been that interesting conversation. Now that we have the context, there has been that interesting conversation around originally; we had this very structured deploys, a deploy map to the fact that features were going out to the world. And now we have this concept of a deploy doesn't necessarily mean that's available to customers. It doesn't mean that the code is running. It is more a deploy represents that we have placed a commit. We have placed code on the server. But that doesn't mean that it is accessible to anyone because it's probably hidden behind a feature flag. +But from the perspective of the rest of the team that then is communicating these changes out to customers, they still really need to know, okay, when is something actually available to customers? And we kept using this terminology around deploy. And so Joël Quenneville, another thoughtboter who's on this project with me, has done a lot of great, thoughtful work around how can we help them know when something is truly available versus when something is deployed? Because right now, we're using Jira for our ticket issue tracking. And there's a particular screen in Jira that was showing what's being deployed. And from that screen, you can see the status of the ticket, and you would see stuff like in code review, in QA. So, of course, those looking at the tickets are like, hold up, you're deploying something that's in QA? That sounds really dangerous and risky. Why are you doing that? And then we'd have to explain, well, we're deploying it, but it's not actually live or accessible to anybody, but we want to get close to that continuous deploy cycle. +So we have shifted to using the terminology of a release. So a deploy is more for the we're putting the code on the server and then release really represents okay, we have now released these features and these bug fixes, and they're now available all with the goal just to make sure that our teams are working well together. But it's been such an interesting conversation around how tickets move, the fact that they can progress linear and then also get moved backwards. But in continuous deployment, things don't go backwards and then making those things align. Typically, things don't go backwards. Technically, yes. +CHRIS: History is a directed acyclic graph that only points forward. The arrow of time is very clear on this matter. Yeah, that really does add one more layer of like; what does it mean to actually be out there in the world? I do wonder if giving view-only visibility to the feature flag dashboard and only when it's fully green does someone think that that's deployed? But if you're putting feature flags around everything, there's complexity. And yeah, it's just one more layer to having to manage all of this. And it sounds like you've gotten to a good place, or at least you're evolving in a way that's enjoyable. But yeah, it's complicated. +STEPH: Yeah, it definitely feels like we're moving in the right direction and that this will be a better...I want to say workflow, but it really focuses more around vocabulary and some of the changes to our processes and how we surface tickets in Jira. But it's more focused on how we talk about the changes that are getting shipped and when they're available. So, yeah, that's my story. What's new in your world? +CHRIS: Well, I very much appreciate your story. In my world, I am in the thick of the MBP initial drive to get something into production, which is one of my favorite times, especially if everyone's in agreement about what exactly do we mean by MVP? Who are the users going to be? What's it going to look like? What's the bar that we're going to maintain? What features can we drop? What can't we drop? When there's a good collaborative sort of everyone rowing in the same direction set of conversations around that, I just love the energy of that time. So I'm happily in that space hacking away on features building as much as I can as quickly as I can. But as part of that, there are a lot of just initial decisions and things that I have to wire up and stuff that I have to change or configure. Thankfully, Rails makes a lot of that not the case. I can just go with what's there and be happy about that. +But there is one thing that I did decide to change just today. But it's interesting; I don't think I've actually ever made this change before. I'm sure I've worked on an app that had this configuration, but typically, a Rails app will store the session in a cookie. So there is a signed HTTP only encrypted. I think those are all the things, but it uses a cookie to store that. And the actual data of the session lives in the payload of that cookie. And so, each time there's a request-response lifecycle, the full payload of that cookie is going up and down from the server to the client and then back and forth with all of the requests. And there's a limit; I think it's 4k is the limit on the cookie session. +But there are some limitations to cookie sessions as far as I'm coming to understand them; one is the ability to do replay attacks. So if someone gets a hold of that cookie, then unless you rotate the secret key base, which will have some pretty wide-ranging effects on your application, that cookie can be reused in the future because it basically just has like, this is the user's ID. There you go. And there's no way to revoke that other than rotating the secret key base. Additionally, there are just costs of that payload of data, especially if you're putting a non-trivial amount of stuff. Like, if you're getting close to that 4K limit, then you have 4K of overhead, both on the request and the response of your HTTP requests. So especially in apps that are somewhat chatty and making a bunch of Ajax requests or doing different things, that's some weight that you should consider. +So all of those mixed together, more so on the security side, I decided to look into it. And I have now switched from a cookie store, and I went all the way to the ActiveRecord database store. So I skipped over...there's a middle option that you can do with Memcached or Redis. We do have Redis in this particular application. We don't have Memcached yet; we probably will at some point. But you can do a memory store, so do Redis and store the session there, but I opted to go all the way to the database. And my understanding of the benefits here are we have a smaller cookie footprint, so smaller overhead on all the requests because now we're only sending the session ID. And then that references the actual payload of data that's stored in the database. We do have the ability now to invalidate sessions, so we can just truncate that table if we just want to sign all the users out and reset the world, which can be useful at times. +We also have the ability...if there's any particular user that's like, "I left myself logged in somewhere," we can…well, I actually don't know how to do this now that I say that. I don't know how to log out a specific user because the sessions don't inherently have the user associated with them. You can have an unauthenticated session, which then transitions to be authenticated when someone signs in, and then the user ID gets installed in there. I would love to have these indexed to users such that I could invalidate and have a button on the admin dashboard that says, "Sign out all instances," and that will revoke all of the sessions or actually delete them from the database table now. I think I would have to add some extra instrumentation to do that. So anytime a user signs in via device, we annotate the session records so that it's got a user ID column and then index on that so that we can look them up efficiently. I think that's how that would work, but that's one of those things that I'm like; I think I should think very hard about this before I do it. It has security implications. It's not part of the default package. There's probably a reason for that. I'm going to do that another day. +But yeah, overall, it was a pretty easy upgrade. I think I'm happy with it. It feels like one of those things that it's not clear to me why this isn't the default sort of thing where SQLite is often the database that you use just because it's slightly easier to get up and running? But for any application that we're working on, we're like, no, no, no, we're going to go to Postgres for local development and for everything because obviously, that's what we want to do. And I'm wondering if this should be in that space, like yeah, of course, the session should go in the database. There are so many reasons that it's better that way. I'm wondering if there are some edge cases that I'm not thinking about, but overall it seems cool. Have you ever worked with an alternative to the cookie store? +STEPH: I'm thinking back to the recent projects that I've worked on. And it's been a while since I've mucked around with session work specifically. And the more recent projects that I've been on, we've used JWTs, or they're pronounced jots, I found out, which is really surprising. I don't know why, but that's a thing. +CHRIS: What? +STEPH: [laughs] +CHRIS: This doesn't feel true. +STEPH: It's JWT, but it's pronounced jot, J-O-T. +CHRIS: I think I'm just going to not do that. This is a trend I'm not going to get on board with. [chuckles] +STEPH: I don't even know if it's a trend. I'm not sure who decreed this into the world. +CHRIS: You're familiar with the great internet war around GIF versus JIF, right? I think there's room for different opinions. +STEPH: I mean, it's really not a war. There's a correct side. +CHRIS: We're on the same side, right? +STEPH: [laughs] And this is how The Bike Shed ended. No, this is perfect for The Bike Shed. What am I talking about? +CHRIS: This is perfect for The Bike Shed. I'm just going to need to hear you say the word real quick. [chuckles] +STEPH: Oh, it's GIF, absolutely, +CHRIS: Okay. All right, phew. Steph, I was worried, I was worried. Also, anyone out there that says JIF, it's fine. These things don't really matter. Although I am surprised when you have an acronym that gets turned into...I think it's an initialism, like jot versus JWT. I forget which is which. I think JWT would be the acronym. But jot, that's not even...I'm going to move on and say...[laughs] And so I think that JWTs, which is what I'm going to call them in this context, are, as far as I understand it, an orthogonal, different sort of thing. Like, you can put a JWT in the session, and the session can be stored in a cookie or in the database or wherever. You can also put JWTs...often, they are in local storage, which my understanding is that's a bad idea. That is a security vulnerability waiting to happen from cross-site scripting, I think, is the one that is coming to mind. But I think that's an independent thing where JWT is this signed assertion that you are someone. But it's coming often from an external system versus I'm using devise in this case on a Rails app and so devise is using the warden session, which is signing and encrypting and a bunch of stuff that I'm not thinking about. But it's not using JWTs at the end of the day. Jot, really, huh? +STEPH: [laughs] I like how that's the thing that stuck out to you. +CHRIS: Of course it is. +STEPH: But it's fair because it did the same to me too, so I had to share it. [laughs] +CHRIS: This is The Bike Shed, after all. [laughs] +STEPH: So, going back to your question, what you've done sounds very reasonable to me, especially because you wanted to address that possibility of a replay attack. So I like the idea. I'm also intrigued by why it's not the default. What's the reasoning there? And I'm trying to think of a reason that it wouldn't be the default. And I don't have a great answer off the top of my head. Granted, it's also been a while since I've been in this space. But yeah, everything that you've done sounds really reasonable. I like it. I also see how being able to sign out a specific user would be really neat. That seems like a really nice feature. I don't know how often that would get used, but that seems like a really nice thing to be able to do to identify a particular user if they submitted and, I don't know, if some scenario came up and someone was like, "Help, please sign me out," then to have that ability. So I'll be intrigued to hear how this advances if you still really like this approach or if you find that you need to change back to using Memcached or the cookie store. +CHRIS: Yeah, I'm in that space where as I'm looking at it, I'm like, I only see upside here. I guess there's a tiny bit of extra complexity. You have to watch that database table and set up a regular recurring job to sort of sweep old sessions that haven't been touched in a while because this is sort of like an append-only store. Every time someone signs in anew, they're getting a new session. So over time, this database table is just going to grow and grow and grow. But it's very easy to stay on top of that if you just set up a recurring job that's cleaning them. It's part of the ActiveRecord session store is the name of the gem. It's under the Rails namespace or the Rails GitHub organization. So that seems manageable. Maybe that's the one complexity is it has this sort of runaway trait to it that you have to stay on top of, whereas the cookie-based sessions don't. But yeah, I'm seeing a lot of upside for us, so I'm going to try it. I think it's going to be good. +I'm also unfortunately in that space where I think I see all the moving parts as to how I could implement the sign out a user in all of their sessions. But I'm worried that I'm tricking myself there. It's one of those things it's like this feels like it would be built in if it was that straightforward, or it could easily have subtle...it's like, don't invent your own crypto. Like, I think I know how crypto algorithms work. I can just write one real quick. No, don't do that, definitely don't do that. And this one, it seems clear enough, but it's still in the space of crypto security, et cetera, that I just don't want to mess with without really thoroughly convincing myself that I know what I'm talking about. So maybe six months from now, I will have talked myself into it. Or if anyone out there is listening and knows of a good founded, well-thought-out version of yeah, this is totally a thing that we do; here’s what it looks like; I would love to hear that. But otherwise, I'll probably just be happy with the ability to wipe everyone's session as necessary. If any one user leaves themselves logged in at a library and needs me to log them out, I'll just log out every user. That's fine. That's a good enough solution. +STEPH: Yeah. All of that makes sense. And also, the part that you highlighted around that there is that additional work of where then you have to make sure that you have a rake task that's running to then sign people out since there's that additional lift that you mentioned. But I'm excited to hear what folks have to say if they're using this approach and what they think about it. It is super interesting. +CHRIS: Well, yeah, I am very excited about this new development and the management of sessions. And I will let you know if I make any headway on the signing out a user sort of thing. But I think that covers that topic. As an aside, I just wanted to take a quick moment to ask folks out there; we are getting to the bottom of our listener question queue, and we absolutely love getting listener questions. They really help us find novel things to talk about that whenever we start talking about them, it turns out that we have a lot to say. So please do send in any questions that you have. You can send them to hosts@bikeshed.fm. That's an email option. You can tweet at us; we're @bikeshed, or either of us individually. I'm @christoomey. +STEPH: And I'm @SViccari. +CHRIS: And we also have a Google Form, which we will link in the show notes of this episode. So any of those versions send us questions. It can be about more tech stuff, more process stuff, more team-building, really anything across the spectrum. But we really do love getting the questions in, and definitely helps provide a little bit more structure to the show. So, with that aside, Steph, what else is going on in your world? +STEPH: Yeah, I love when we call from our listener questions, for the reason that you highlighted because it often exposes me to different ways of thinking in topics that I hadn't considered before. And you're right; we’re often very opinionated souls. [laughs] And along that note, so I have a question for you. The context is another developer, and I ran into a bug. And when we initially looked at the bug, it was one of those there's no way. There's no way the code is in this state. That does not make sense. And then, of course, it's one of those well, the computer says otherwise, so clearly we're wrong. We just can't see how the code is getting to this place. And what was happening is we were setting a value. We were parsing some JSON. We're looking for a value in that JSON, and we're using dig specifically in Ruby. So if it's the JSON or if it's a hash, and then we're doing dig, and then we're going two layers deep. So let's say we're going foo and then bar, and then dig; if it doesn't find those values, instead of erroring, it's just going to return nil. And then we have an or, and then we have a hard-coded string. +So it's like, hey, we want to set this attribute to this value. If it's the hash, then give us back that value; if not, it's going to be nil, and then give us this hard-coded string. What we were seeing in the actual data is that we were getting an empty string. And initially, it was one of those; how are we possibly getting an empty string when we gave you a hard-coded string to give us instead? And it's because empty strings are truthy. When we were performing the dig, it was finding both of those values, but that value was set to an empty string. And because that evaluates to truthy, we weren't getting the hard-coded string, and then we were setting it to an empty string, and then that caused some problems. So then my question to you is should we have truthiness in our code? +CHRIS: Oh wow. That's a big question. It's also each language I might have a slightly different version of my answer. Yeah, I'm going to have to go sort of across languages to answer. I think in Ruby, I have generally been happy with Ruby's somewhat conservative implementation of truthiness. Yeah, anything that isn't nil false...is that it? Are those the only falsy values? There's maybe one more, but zero is not a falsy value. Empty string is not a falsy value. They're truthy, to name it in the affirmative. And I like that Ruby has a more conservative view of what things are. And so it can have this other surprising edge. I will say that I do reach for present? in Rails, so present? Present with a question mark at the end, that method in Rails, which I pronounce as present, huh? +STEPH: Which is delightful, by the way. +CHRIS: Well, thank you. That method I reach for often or presence would be the variant in this case where you can presence or and then chain on the thing that you want, and that gets the value. It will basically do the thing that you want here. And so, I do find myself reaching for that, which does imply that maybe Ruby's default truthiness is not quite what I want. And I want a little more permissive truthiness, a little more like, no, empty strings are not truthy. Empty string is an empty value, so it is empty. But yeah, I think I can always convince myself of the other argument when I'm angrily fighting against a bug that I ran into, and I'm surprised by. Like, I've experienced this from both sides many times in my life. I will say in JavaScript, I am constantly surprised by the very, very permissive type coercion that happens where you compare a string and a number, and suddenly they're both strings, and they get smashed together. It's like, wait, how is that ever the thing that I would want? And so JavaScript's version feels like it is definitively foundationally wrong. +Ruby's feels like it's maybe a tiny bit conservative, but I like that as a default and then Rails building on top of that. I think I lean towards that most of the time. I will say at the other end of the spectrum, I've worked with Haskell, and Haskell has I want to say it's like a list of chr, like C-H-R list of characters as the canonical way to do strings. I may be mixing this up. It may be actually the string type, but then there's also a text type, and they're slightly different. Maybe it's UTF. I forget what the distinction was, but they both exist, and they are both often found in libraries and in code. And you end up having to constantly convert back and forth. And there are no subtle equivalents between them or any type coercion between them because it's Haskell, and there isn't really any of that. And this was early on. +I never got particularly far in Haskell, but I found that so painful and frustrating. It was just like, come on; they’re like strings. Please just do the thing. You know what I mean. And Haskell was like, "I do not. And I require you to be ridiculously specific about it." So that was sort of the high end for me of like nope, definitely not that JavaScript of like anything's anything and it's fine. That feels bad. So somewhere in the middle, Ruby feels like it's a happy in the middle. Maybe Rails is actually where I want to land, but I don't know that there is a good answer to this. I don't know that there's a language that's like, we got it. It's this very specific set of things. It's truthy, and these are falsy, and it's perfect every time. Like, I don't think that can happen. +STEPH: As an aside, I like how your Haskell voice had the slight air of pretension that really resonated with me. [laughs] +CHRIS: I don't know what you're talking about. That doesn't sound familiar to me at all. [laughs] +STEPH: I agree. I don't know that anyone has gotten this perfect. But then again, I also haven't tried all the languages that are out there, so I don't feel like that's really a fair statement for me to make either. Specific to the Ruby world, I do think Boolean coercions are a bit nice because then they do make certain checks easier. So if you are working with an if statement, you can say, "If this, and then do that, else, do this." And that feels like a pretty nice common idiomatic flow that we use in Ruby but then still feels like one of those areas that can really bite you. +So while having this conversation with some other thoughtboters, Mike Burns provided a succinct approach to this that I think I really like where he said that he likes the use of truthy and falsy for if statements, Booleans for the and statement, and only truthy falsy for Booleans, so no nulls. So Boolean should not have three states is what that last part is highlighting. It should be just true or false. And then if we're working with the double ampersand and in Ruby, that then if you have that type of conditional that you are conveying, then to use a strict Boolean, be more strict and use the methods that you were referring to earlier, like empty and explicitly checking is this an actual...like turn it into a Boolean instead of relying on that that truthy falsy of is it present? Is it an empty string? Does that count? But then, for the if statements, those can be a little more loose. +And actually, now that I'm saying it, that first part, I get it. It's convenient, but I still feel like bugs lie down that path. And so, I think I'm still in favor of being more explicit. If I really care if something is true or false, I want to call out explicitly. I expect this to be true or false versus relying on the fact that I know it will evaluate, although I'm sure I do it all the time, just because that's how you often write idiomatic Ruby. So I'm interested in watching my own behavior now to see how often I'm relying on that truthy, falsy behavior, and then see the areas that I can mitigate that just because yeah, that bug is fresh in my mind, and I'd like to prevent those bugs going forward. +CHRIS: I really liked that phrase of that bug is fresh. So that bug is going to own a little bit more mindshare than that old bug that's a bit stale in the back of my brain. I will say as you were talking about idiomatic Ruby, I think you're right that the sort of core or idiomatic way to do it would be if the user or whatever to see is the user here, or are they nil? Did we find one, or did we not? That sort of thing is commonly the way it would be done. I almost always write those as if users are not present? I will convert it into that because A, I'm writing Ruby, and I write Ruby because I want it to sound like the human words that I would say. And so I wouldn't say like, "If user," I would say, "If the user is present, then do the thing." And so I write the code to do that, but I also get the different semantics that present? Brings or blank? Is the counterpart, the other side of it. That seems to be the way that I write my code. That's idiomatic me, Ruby, and I don't know how strongly I hold that belief. But that is definitely how I write those, which I find interesting in contrast to what you were saying. +The other thing that came to mind as you were saying this is that particular one of an empty string. I kind of want to force empty strings to not be okay, particularly at the database level. So I'll often have null false on a string column, but then I'll find empty strings in there. And I'm like, well, that's not what I meant. I wanted stuff in there. Database, I want you to stop it if I was just putting in an empty string because you're supposed to be the gatekeeper that keeps me honest. And so I do wonder if there is a Postgres extension that we could have similar to the citexts, citext, which is case-insensitive text. So you can say, "Yeah, store this as it is, but whenever you compare it, compare case-insensitively," because an email is an email. Even if I capitalize the third letter, it doesn't make it a different email. I want a non-empty text as a column type that is both null false but also has a check constraint for an empty string and prevents that. +And then similarly, the three-state Boolean thing that you're talking about, I will always do null false on a Boolean column because it's a lie if I ever tell myself. I'm like, yeah, but this Boolean could be null, then you've got something else. Then you've got an ADT, which I also can't represent in my database, and that makes me sad. I guess I can enum those, but it's not quite the same because I can't have additional data attached. That's a separate feeling that I have about databases. I'm going down a rabbit hole here. I wish the database would prevent me from putting in empty strings into null, false string columns. I understand that I'm going to have to do some work on my side to make that happen, but that's the world I want to live in. +STEPH: I'm trying to think of a name for when you have a Boolean that's also a potential null value. What do you have? You have nullean at that point? +CHRIS: Quantum Boolean. +STEPH: Quantum Boolean. [laughs] +CHRIS: Spooky Boolean. +STEPH: The maybe Boolean? +CHRIS: Yeah. +STEPH: No, that's worse. [laughs] Yeah, I'm with you. And I like the idiomatic Ruby. I think that is something that I would like to do more of where I'm explicitly checking if user instead of just checking for that presence and allowing that to flow through doing the present check and verifying that yes, we do have a user versus allowing that nil to then evaluate to falsy. That's the type of code that I think I'd like to be more strict about writing. But then it's also interesting as I'm formulating these ideas. Is it one of those if I'm reviewing a PR and I see that someone else didn't do it, am I going to advise like, hey, let's actually check or turn this into a true Boolean versus just relying on the truthy and falsy behavior? And probably not. I don't think I'm there yet. And I think this is more in the space that I'm interested in pursuing and seeing how it benefits the code that I'm writing. But I don't think I'm at the state where then I would advocate, at least not loudly, on other PRs that we do it. If it is, it'd be like a small suggestion, but it wouldn't be something that I would necessarily expect someone else to do. +CHRIS: Yeah, definitely the same for me on that, although it's a multi-step plan here, a multi-year plan. First, we say it on a podcast, then we say it again on a podcast, then we change all the hearts and minds, then everyone writes the style, then we're all in agreement that this is the thing that we should do. And then it's reasonable to bring up in a pull request, or even then, I still wouldn't want it. Then it's like standard rb or somebody else's job. That's the level of pull request comment that I'm like, really? Come on. Come on. +STEPH: This is a grassroots movement for eradicating truthiness and falsyness. I think we're going to need a lot of help to get this going. [laughs] +CHRIS: Thankfully, there are the millions of listeners to this show that will carry this torch forward, I assume. +STEPH: Millions. Absolutely. +CHRIS: I'm rounding roughly a little. +STEPH: There are a couple, yeah. [laughs] I'd be far more nervous if I knew we had millions of people listening. +CHRIS: I kind of know that people listen. But at the same time, most of the time, I just entirely forget about that, and I feel like we're just having a conversation, which I think is good. But yeah, the idea that actual humans will listen to this in the future is a weird one that just doesn't do good things in my head. So I just let that go. And you and I are just having a chat, and it's great. +STEPH: Yeah. I'm with you. And just to reiterate what you were saying earlier, we love getting listener questions. So if there's anything that you'd like to send our way and have us to chat about or something you'd like to share with us, then please do so. On that note, shall we wrap up? +CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @bikeshed or reach me on Twitter @SViccari. +CHRIS: And I'm @christoomey. +STEPH: Or you can reach us at hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeeee. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._ + + + What do you get when you mix a worm and a hammerhead shark? Also ants. Steph made some cool new discoveries in bug-land. She also talks about deploys versus releases and how her and her team has changed their deploy structure. Two words: feature flags.

+ +

Chris talks about cookies: cookie sessions, cookie payloads, cookie footprints, cookie storing. Mmm cookies! The convo wraps up with lamenting over truthiness in code. Truthy or falsy? What's your call?

+ + + +

Transcript:

+ +

STEPH: At the top of my notes for today, I have marauder ants and hammerhead worms. [laughs]

+ +

CHRIS: I'm sorry, what? I lost you there for...not lost you, but I stopped following. I...what? Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going?

+ +

STEPH: Hey, Chris, it's been a good week. It's been busy, lots has been happening. I learned about a new creature that's in our backyard. They're called hammerhead worms. Have you ever heard of those?

+ +

CHRIS: I've heard of hammerhead and worms, but not together. The combination is new and novel for me.

+ +

STEPH: Cool. Cool. So take a hammerhead shark and a worm and combine the two and then you have a hammerhead worm. And it rained really heavily here recently because there's a tropical storm that's making its way up the East Coast. And when I was outside on the porch, I noticed that there were these new worms or worms that I'd never seen before on the back porch. And so I had to Google them to understand because they had the interesting hammer-shaped head. And I found out that they're called hammerhead worms. They're toxic worms that prey on earthworms. And they're basically immortal because if you cut them into multiple pieces, each section can regenerate into a fully developed organism within a few weeks, which is bananas. And a lot of people online highly recommend that you should kill them because they are a toxic predator and they prey on earthworms, which you want in your garden and in your yard. But I didn't, but I learned about them.

+ +

CHRIS: Wow. That's got some layers there, toxic, intense worms that you can cut in half. And so does their central nervous system just spread throughout their whole body? Where's their brain? How does it...I don't have any real thoughts here. That's just a bunch of stuff, and it's awesome. Thank you for sharing.

+ +

STEPH: I will warn you. I wouldn't read about hammerhead worms right before bed. Otherwise, you might have some nightmares because the way that they do prey and consume earthworms or other creatures that they prey on is the stuff of horror movies, which I find happens so much in nature, but them especially they fall into that category. So just be aware if you're reading about hammerhead worms and how they consume their food. Now I feel like everybody's going to go read. But as long as you have that warning, I feel safe sending you in that direction.

+ +

CHRIS: Yeah, first thing in the morning on a very sunny morning, that is the time to do this research.

+ +

STEPH: Exactly. He got it. I also learned about marauder ants because apparently, this is the day that I'm having. I'm learning about all these creatures. But I won't go into that one, but they're really interesting. And this one's thanks to someone on Twitter who shared, specifically @Rainmaker1973 is their Twitter handle if you want to go see what they shared about marauder ants. So I'll just leave that one for those that are curious. I won't dive into that one because I don't want to take us in the direction of that we're all about worms and ants now.

+ +

CHRIS: Not all about worms and ants but definitely some.

+ +

STEPH: But in technical news, I've got some stuff to share, but I was so excited about worms and ants that now I have to figure out which is the thing that I want to share from the week. So there's a couple of interesting things that I'd love to chat about with you, one of them, in particular, is there's been some interesting conversations going on with my client team around deploys versus releases and how we have changed our deploy structure, and then how that has impacted the rest of the team as they are communicating to customers as to what features are available. And there have been some interesting conversations around how to migrate this process forward.

+ +

So to provide a bit of context, we were previously having very strict, rigid deploys. So we would plan our deploys typically every Tuesday. It was usually once a week. And then we would make sure that everything had been through QA, things had been reviewed and tested. And then we would have one of those more like grand deploys, things are going out. And then hey, if you need to get something into the deploy, let us know; we need to talk about it. So there was just more process and structure to that. And so deploy really mapped to the idea that if we are doing a deploy, then that means all these feature bug fixes are going out, and this is now the time that we can tell customers, "Hey, this new feature is available or this bug that you reported to us has now been fixed." We have since been moving towards a more continuous deployment structure where we're not quite there where we're doing continuous deploy, but we are deploying at least once a day, so it's a lot more frequent.

+ +

And so this has changed the way that we really map the idea of the work that's being done versus the work that's actually available to customers. Because as we are merging work into the main branch, and then let's say if I'm working on a feature and then I merge that into the main branch and then push it up staging, we have an overnight QA process. So then overnight QA, if they say, "Hey, there's something that's wrong with this feature. It didn't quite meet the required specs," then they can kick that ticket back to me, but that's not true for my code. We could do a revert and take my code out at that point. But at this point, it's in main, and main may have been deployed at that point. So there have been some interesting strategies around how can we safely continue to deploy while we know we often have a 24-hour wait period for QA and to get sign-off on this work? But we want to keep moving forward and then also communicate that just because the code has been deployed doesn't necessarily mean that it's available to customers. There's a lot there. So I'm going to pause and see if you have questions.

+ +

CHRIS: Well, first, I'm just super excited to talk about this. This is something that's been very much top of mind for me, and it's a direction that I want to be going more and more, so yeah, excited that you're pushing the boundaries on this. I am intrigued. I'm guessing feature flags is the answer about how you're decoupling that and how you're making it so that you've got that separation of deployment and actual availability of the feature. So, yeah, can you talk more about that?

+ +

STEPH: Definitely. And yes, you're right. We're using feature flags, so we'll use the same scenario. I'm working on a feature, and I want to be able to release it safely, so I'm going to wrap it in a feature flag. And I'll probably wrap it, and maybe it's like a beta feature flag, something to indicate that this is a feature that's going to be available to all, but we don't actually want to turn it on until we know that it's truly ready to be turned on. So then that way, it's hidden, but then we can still merge it into the main branch. We can still have a deploy even if my code hasn't gone through QA at that point, but we know it's still safe to deploy. And then, QA can go to a staging environment; they can test it. And if they say, "No," it's fine because nothing was churned in production. But then, if it gets approved, then we can turn it on, and then we'll have a follow-up to then remove that feature flag.

+ +

CHRIS: So some follow-on questions. I'm wondering about the architecture of the application. Is this like traditional Rails app rendering HTML on the server, or do you have any more advanced client-side stuff? And then I'm also wondering what you're using for the actual feature flagging, and those will probably inform each other. But what's the story on both of those fronts?

+ +

STEPH: It's a traditional Rails application. So we're not using any other client-side application. It is Rails and rendering HTML. As for feature flags, so we're not using something traditional. And by traditional, I mean I typically have reached for Flipper in the past for managing feature flags. We're using more of a hand-rolled approach because there's a lot of context there that I don't know is necessarily helpful. But to answer your question, we essentially do have feature flags as columns in the database, and we can just check if they are enabled or disabled. And then that also allows us to easily turn it on, turn it off as well since it's just a database update.

+ +

CHRIS: Okay, that makes sense. I think the nature of being a Rails application rendering HTML on the server like what you're doing totally makes sense in that context. I think it becomes a lot harder the more complex the architecture of your application is. So if you've got microservices, then suddenly you've probably got to synchronize across some of them, and that sounds like a whole thing. Or even if you have a client-side application, then suddenly you've got to serialize the feature flag stuff across the boundary or somehow expose that, which really does push the issue of we could just render stuff on the server and send it to the client and let that be good enough, then man, is stuff simpler. But unfortunately, that's not the case in a lot of situations.

+ +

I'm expecting to be introducing feature flags on the app that I'm working on pretty soon. And again, we've got...so it's a Rails server-side thing. So there's going to be plenty of feature flag logic on that side. And then I'll need to do something to serialize it across the boundary and get it onto the client-side without ballooning every payload and adding complexity, and lookups, and whatnot. I think it's doable. Inertia, again, being the core architecture of the application, I think will make this a little bit easier, but I am interested to see what I'm able to pull off and how happy I am with where I get to.

+ +

Another question that I have for you then are you testing the various flows? So given a Boolean feature flag, you now have two different possible paths for your code to go through. And then there may be even more than Boolean, or you may have feature flags that sort of interact with each other. And how much complexity are you trying to manage and represent in the test suite?

+ +

STEPH: Yeah, good question, and we are. So we're testing both flows, especially if it's a new feature, then we are testing when the flag is enabled or disabled. One that's been tricky for me is what about a bug fix? Is that something that should be feature flagged? And I think at the surface level, if you're presuming that it needs to go through QA before this is live on production, then the answer is yes, that then you have to feature flag a bug fix, which feels weird. But then the other consideration would be, well, it is a bug fix. And could we find another way to QA this faster or some other approach so that way we don't have to wrap it in a feature flag? And I don't have a great answer for that one because I can see arguments in favor of either approach. Although wrapping everything in a feature flag does feel tedious, it's something that I'm not accustomed to doing. And it's something that then becomes a process for the team to remind each other that, hey, is this wrapped in a feature flag? Or just being mindful of that as part of our process. And it prompted me to think back on the other projects that I've worked on and how did we manage that flow? How did we go from development to staging to QA and then out to production?

+ +

And one additional consideration with this flow is that we do have an overnight QA team. So in the past, when I've worked with teams, often product managers or even other developers, we would QA each other's work. So then it was a pretty fast turnaround that then you could get something up on staging. Someone could check it out and say, "Yes" or "No." But then I'm also pretty confident most of the teams that I've worked with we have had a distinct staging branch. So we would often merge work into a staging branch, and then deploy that work, and then get it tested. And then, if it passed everything, then we would essentially cherry-pick that work and move it over into production.

+ +

And I can see there's a lot of arguments against that, but then I have also experienced that and had a really positive experience where we could test everything and not have to worry about going out to production. We didn't have to wrap everything in feature flags, and it just felt really nice to know that everything in the main or production branch, whatever you call your production branch, that everything in there was deployable versus having to go the feature flag route, or the hey, did this go through QA? I don't know. Let me check. Can I include this? Should I cherry-pick some commits into our actual deployment to avoid stuff that hasn't gone through QA? I've been through that dance before too, and that one's not great.

+ +

CHRIS: I like the way you're framing the different sort of trade-offs that we have there in velocity or deployment speed and ease of iteration versus confidence as things are going out. I have worked with a staging branch before, and I personally did not find it to be valuable. It ended up adding this indirection. Folks had to know how to use Git in a pretty deep way to be comfortable with that just as a starting point. So it already introduced this hurdle of knowledge, and then beyond that, that idea that you have commits going in in a certain order on the staging branch. But then say we verify the functionality of the third commit in that list, and we want to cherry-pick it across to the main branch. Commits don't actually...you can't just take the thing that you had there. That commit existed in the context of all the others. There are subtleties of how history exists in Git. And I would worry about those edge cases where you're taking a piece of work out of the context of the rest of the commits that were around it or before it is, more importantly…that preceded it in the history on the staging branch, and you're now bringing it across to the main branch. Have you now lost something that was meaningful?

+ +

Ideally, you would get a conflict if it was really bad, but that's more of like a syntactic diff level thing. It's not a functionality-level thing. So personally, I may be overly cautious around this, but I really like as much as possible to have the very boring linear history in Git and do everything I can such that work happens on feature branches and then gets merged in as a fast forward into the main branch or rather the main branch is fast-forward marched into my feature branch such that I'm never working with code that I haven't fully worked with in an integrated way before. But again, even that, as I'm saying that, I have this topological map of Git in my head as I'm saying all of that, and it's complicated. And having any of that complexity leak out into the way we talk about the work is something that I worry about, but maybe I'm worried about a bunch of things that don't matter. Maybe a staging branch is actually fantastic.

+ +

STEPH: I think you make a lot of good points. Those are a lot of good concerns that come up with...it comes back to the idea that we want to mimic production as much as possible, and we don't want to lose that parity. So then, by having a staging branch, then it feels that we've lost that parity. There could be stuff that's in staging that's not in production. And so staging could be a little bit of this Wild West area, and then that doesn't fully represent then what's going to production. So I certainly understand and agree with those points that you're making. And to speak specifically to the Git challenges, I agree. It does require some more Git knowledge to be able to make that work. Specifically, I think how we handled it on a previous project is where we'd actually cherry-pick our commits into staging and then deploy that. But we always had the PR issued against main. So then merging into main was often a bit easier.

+ +

But then you're right; things could get out of sync. And the PR is issued against main, so then you still could run into those oddities where then if you are cherry-picking commits in the staging, but then you have your final draft that's going into main. And then what are the differences between those, and what did you lose along the way? And as I say all of that out loud, I definitely understand the Git concerns. And I don't know; I just feel like there's not a great answer then here, which is shocking to me. I've been doing this for a while, and yet here I am feeling like there's not a great answer to this very vital part of our workflow. And I'm surprised even though that we do have a delayed QA process that this still feels like a painful thing to figure out how do we have a continuous deployment workflow even though we do have that delayed QA process?

+ +

CHRIS: I think somewhat fundamentally your comment there of "I'm surprised that we don't have a good answer to this is," I'm not surprised, I guess, is my reaction. I don't want to go to the software is bad and broken, and we don't know anything end of the spectrum. But I don't feel like we have great answers to a lot of the things about development. I feel like software is more broken than it should be. It costs more to develop. It is difficult. It's hard to create, and maintain, and build over time. And that's just, to get lofty about it, that's what the entire focus of my career is, is trying to solve that problem. But it's a big, hard problem that I do not think is solved, unlike just about any of the fronts. I know how to put stuff in a database and take it back out. And even that, I'm like, oh yeah, but what if the database gets really big? Or what if the database...everything has complexities and edge cases.

+ +

STEPH: [laughs]

+ +

CHRIS: And we've joked a handful of times about the catchphrase of The Bike Shed being it depends, and that really feels true, though. I don't know that that's unique to this industry either. I feel like everything in the world is just more complicated the more you look at it, and there aren't clear, good, obvious answers to just about anything in the world, but that's the human condition. I got weirdly philosophical on this, so we should probably round this out. [laughs]

+ +

STEPH: Well, I can circle us back because I was providing context, and I went a bit into the deep end providing all of that context. So if I circle back to what I wanted to share with you around deploys and releases, there has been that interesting conversation. Now that we have the context, there has been that interesting conversation around originally; we had this very structured deploys, a deploy map to the fact that features were going out to the world. And now we have this concept of a deploy doesn't necessarily mean that's available to customers. It doesn't mean that the code is running. It is more a deploy represents that we have placed a commit. We have placed code on the server. But that doesn't mean that it is accessible to anyone because it's probably hidden behind a feature flag.

+ +

But from the perspective of the rest of the team that then is communicating these changes out to customers, they still really need to know, okay, when is something actually available to customers? And we kept using this terminology around deploy. And so Joël Quenneville, another thoughtboter who's on this project with me, has done a lot of great, thoughtful work around how can we help them know when something is truly available versus when something is deployed? Because right now, we're using Jira for our ticket issue tracking. And there's a particular screen in Jira that was showing what's being deployed. And from that screen, you can see the status of the ticket, and you would see stuff like in code review, in QA. So, of course, those looking at the tickets are like, hold up, you're deploying something that's in QA? That sounds really dangerous and risky. Why are you doing that? And then we'd have to explain, well, we're deploying it, but it's not actually live or accessible to anybody, but we want to get close to that continuous deploy cycle.

+ +

So we have shifted to using the terminology of a release. So a deploy is more for the we're putting the code on the server and then release really represents okay, we have now released these features and these bug fixes, and they're now available all with the goal just to make sure that our teams are working well together. But it's been such an interesting conversation around how tickets move, the fact that they can progress linear and then also get moved backwards. But in continuous deployment, things don't go backwards and then making those things align. Typically, things don't go backwards. Technically, yes.

+ +

CHRIS: History is a directed acyclic graph that only points forward. The arrow of time is very clear on this matter. Yeah, that really does add one more layer of like; what does it mean to actually be out there in the world? I do wonder if giving view-only visibility to the feature flag dashboard and only when it's fully green does someone think that that's deployed? But if you're putting feature flags around everything, there's complexity. And yeah, it's just one more layer to having to manage all of this. And it sounds like you've gotten to a good place, or at least you're evolving in a way that's enjoyable. But yeah, it's complicated.

+ +

STEPH: Yeah, it definitely feels like we're moving in the right direction and that this will be a better...I want to say workflow, but it really focuses more around vocabulary and some of the changes to our processes and how we surface tickets in Jira. But it's more focused on how we talk about the changes that are getting shipped and when they're available. So, yeah, that's my story. What's new in your world?

+ +

CHRIS: Well, I very much appreciate your story. In my world, I am in the thick of the MBP initial drive to get something into production, which is one of my favorite times, especially if everyone's in agreement about what exactly do we mean by MVP? Who are the users going to be? What's it going to look like? What's the bar that we're going to maintain? What features can we drop? What can't we drop? When there's a good collaborative sort of everyone rowing in the same direction set of conversations around that, I just love the energy of that time. So I'm happily in that space hacking away on features building as much as I can as quickly as I can. But as part of that, there are a lot of just initial decisions and things that I have to wire up and stuff that I have to change or configure. Thankfully, Rails makes a lot of that not the case. I can just go with what's there and be happy about that.

+ +

But there is one thing that I did decide to change just today. But it's interesting; I don't think I've actually ever made this change before. I'm sure I've worked on an app that had this configuration, but typically, a Rails app will store the session in a cookie. So there is a signed HTTP only encrypted. I think those are all the things, but it uses a cookie to store that. And the actual data of the session lives in the payload of that cookie. And so, each time there's a request-response lifecycle, the full payload of that cookie is going up and down from the server to the client and then back and forth with all of the requests. And there's a limit; I think it's 4k is the limit on the cookie session.

+ +

But there are some limitations to cookie sessions as far as I'm coming to understand them; one is the ability to do replay attacks. So if someone gets a hold of that cookie, then unless you rotate the secret key base, which will have some pretty wide-ranging effects on your application, that cookie can be reused in the future because it basically just has like, this is the user's ID. There you go. And there's no way to revoke that other than rotating the secret key base. Additionally, there are just costs of that payload of data, especially if you're putting a non-trivial amount of stuff. Like, if you're getting close to that 4K limit, then you have 4K of overhead, both on the request and the response of your HTTP requests. So especially in apps that are somewhat chatty and making a bunch of Ajax requests or doing different things, that's some weight that you should consider.

+ +

So all of those mixed together, more so on the security side, I decided to look into it. And I have now switched from a cookie store, and I went all the way to the ActiveRecord database store. So I skipped over...there's a middle option that you can do with Memcached or Redis. We do have Redis in this particular application. We don't have Memcached yet; we probably will at some point. But you can do a memory store, so do Redis and store the session there, but I opted to go all the way to the database. And my understanding of the benefits here are we have a smaller cookie footprint, so smaller overhead on all the requests because now we're only sending the session ID. And then that references the actual payload of data that's stored in the database. We do have the ability now to invalidate sessions, so we can just truncate that table if we just want to sign all the users out and reset the world, which can be useful at times.

+ +

We also have the ability...if there's any particular user that's like, "I left myself logged in somewhere," we can…well, I actually don't know how to do this now that I say that. I don't know how to log out a specific user because the sessions don't inherently have the user associated with them. You can have an unauthenticated session, which then transitions to be authenticated when someone signs in, and then the user ID gets installed in there. I would love to have these indexed to users such that I could invalidate and have a button on the admin dashboard that says, "Sign out all instances," and that will revoke all of the sessions or actually delete them from the database table now. I think I would have to add some extra instrumentation to do that. So anytime a user signs in via device, we annotate the session records so that it's got a user ID column and then index on that so that we can look them up efficiently. I think that's how that would work, but that's one of those things that I'm like; I think I should think very hard about this before I do it. It has security implications. It's not part of the default package. There's probably a reason for that. I'm going to do that another day.

+ +

But yeah, overall, it was a pretty easy upgrade. I think I'm happy with it. It feels like one of those things that it's not clear to me why this isn't the default sort of thing where SQLite is often the database that you use just because it's slightly easier to get up and running? But for any application that we're working on, we're like, no, no, no, we're going to go to Postgres for local development and for everything because obviously, that's what we want to do. And I'm wondering if this should be in that space, like yeah, of course, the session should go in the database. There are so many reasons that it's better that way. I'm wondering if there are some edge cases that I'm not thinking about, but overall it seems cool. Have you ever worked with an alternative to the cookie store?

+ +

STEPH: I'm thinking back to the recent projects that I've worked on. And it's been a while since I've mucked around with session work specifically. And the more recent projects that I've been on, we've used JWTs, or they're pronounced jots, I found out, which is really surprising. I don't know why, but that's a thing.

+ +

CHRIS: What?

+ +

STEPH: [laughs]

+ +

CHRIS: This doesn't feel true.

+ +

STEPH: It's JWT, but it's pronounced jot, J-O-T.

+ +

CHRIS: I think I'm just going to not do that. This is a trend I'm not going to get on board with. [chuckles]

+ +

STEPH: I don't even know if it's a trend. I'm not sure who decreed this into the world.

+ +

CHRIS: You're familiar with the great internet war around GIF versus JIF, right? I think there's room for different opinions.

+ +

STEPH: I mean, it's really not a war. There's a correct side.

+ +

CHRIS: We're on the same side, right?

+ +

STEPH: [laughs] And this is how The Bike Shed ended. No, this is perfect for The Bike Shed. What am I talking about?

+ +

CHRIS: This is perfect for The Bike Shed. I'm just going to need to hear you say the word real quick. [chuckles]

+ +

STEPH: Oh, it's GIF, absolutely,

+ +

CHRIS: Okay. All right, phew. Steph, I was worried, I was worried. Also, anyone out there that says JIF, it's fine. These things don't really matter. Although I am surprised when you have an acronym that gets turned into...I think it's an initialism, like jot versus JWT. I forget which is which. I think JWT would be the acronym. But jot, that's not even...I'm going to move on and say...[laughs] And so I think that JWTs, which is what I'm going to call them in this context, are, as far as I understand it, an orthogonal, different sort of thing. Like, you can put a JWT in the session, and the session can be stored in a cookie or in the database or wherever. You can also put JWTs...often, they are in local storage, which my understanding is that's a bad idea. That is a security vulnerability waiting to happen from cross-site scripting, I think, is the one that is coming to mind. But I think that's an independent thing where JWT is this signed assertion that you are someone. But it's coming often from an external system versus I'm using devise in this case on a Rails app and so devise is using the warden session, which is signing and encrypting and a bunch of stuff that I'm not thinking about. But it's not using JWTs at the end of the day. Jot, really, huh?

+ +

STEPH: [laughs] I like how that's the thing that stuck out to you.

+ +

CHRIS: Of course it is.

+ +

STEPH: But it's fair because it did the same to me too, so I had to share it. [laughs]

+ +

CHRIS: This is The Bike Shed, after all. [laughs]

+ +

STEPH: So, going back to your question, what you've done sounds very reasonable to me, especially because you wanted to address that possibility of a replay attack. So I like the idea. I'm also intrigued by why it's not the default. What's the reasoning there? And I'm trying to think of a reason that it wouldn't be the default. And I don't have a great answer off the top of my head. Granted, it's also been a while since I've been in this space. But yeah, everything that you've done sounds really reasonable. I like it. I also see how being able to sign out a specific user would be really neat. That seems like a really nice feature. I don't know how often that would get used, but that seems like a really nice thing to be able to do to identify a particular user if they submitted and, I don't know, if some scenario came up and someone was like, "Help, please sign me out," then to have that ability. So I'll be intrigued to hear how this advances if you still really like this approach or if you find that you need to change back to using Memcached or the cookie store.

+ +

CHRIS: Yeah, I'm in that space where as I'm looking at it, I'm like, I only see upside here. I guess there's a tiny bit of extra complexity. You have to watch that database table and set up a regular recurring job to sort of sweep old sessions that haven't been touched in a while because this is sort of like an append-only store. Every time someone signs in anew, they're getting a new session. So over time, this database table is just going to grow and grow and grow. But it's very easy to stay on top of that if you just set up a recurring job that's cleaning them. It's part of the ActiveRecord session store is the name of the gem. It's under the Rails namespace or the Rails GitHub organization. So that seems manageable. Maybe that's the one complexity is it has this sort of runaway trait to it that you have to stay on top of, whereas the cookie-based sessions don't. But yeah, I'm seeing a lot of upside for us, so I'm going to try it. I think it's going to be good.

+ +

I'm also unfortunately in that space where I think I see all the moving parts as to how I could implement the sign out a user in all of their sessions. But I'm worried that I'm tricking myself there. It's one of those things it's like this feels like it would be built in if it was that straightforward, or it could easily have subtle...it's like, don't invent your own crypto. Like, I think I know how crypto algorithms work. I can just write one real quick. No, don't do that, definitely don't do that. And this one, it seems clear enough, but it's still in the space of crypto security, et cetera, that I just don't want to mess with without really thoroughly convincing myself that I know what I'm talking about. So maybe six months from now, I will have talked myself into it. Or if anyone out there is listening and knows of a good founded, well-thought-out version of yeah, this is totally a thing that we do; here’s what it looks like; I would love to hear that. But otherwise, I'll probably just be happy with the ability to wipe everyone's session as necessary. If any one user leaves themselves logged in at a library and needs me to log them out, I'll just log out every user. That's fine. That's a good enough solution.

+ +

STEPH: Yeah. All of that makes sense. And also, the part that you highlighted around that there is that additional work of where then you have to make sure that you have a rake task that's running to then sign people out since there's that additional lift that you mentioned. But I'm excited to hear what folks have to say if they're using this approach and what they think about it. It is super interesting.

+ +

CHRIS: Well, yeah, I am very excited about this new development and the management of sessions. And I will let you know if I make any headway on the signing out a user sort of thing. But I think that covers that topic. As an aside, I just wanted to take a quick moment to ask folks out there; we are getting to the bottom of our listener question queue, and we absolutely love getting listener questions. They really help us find novel things to talk about that whenever we start talking about them, it turns out that we have a lot to say. So please do send in any questions that you have. You can send them to hosts@bikeshed.fm. That's an email option. You can tweet at us; we're @bikeshed, or either of us individually. I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: And we also have a Google Form, which we will link in the show notes of this episode. So any of those versions send us questions. It can be about more tech stuff, more process stuff, more team-building, really anything across the spectrum. But we really do love getting the questions in, and definitely helps provide a little bit more structure to the show. So, with that aside, Steph, what else is going on in your world?

+ +

STEPH: Yeah, I love when we call from our listener questions, for the reason that you highlighted because it often exposes me to different ways of thinking in topics that I hadn't considered before. And you're right; we’re often very opinionated souls. [laughs] And along that note, so I have a question for you. The context is another developer, and I ran into a bug. And when we initially looked at the bug, it was one of those there's no way. There's no way the code is in this state. That does not make sense. And then, of course, it's one of those well, the computer says otherwise, so clearly we're wrong. We just can't see how the code is getting to this place. And what was happening is we were setting a value. We were parsing some JSON. We're looking for a value in that JSON, and we're using dig specifically in Ruby. So if it's the JSON or if it's a hash, and then we're doing dig, and then we're going two layers deep. So let's say we're going foo and then bar, and then dig; if it doesn't find those values, instead of erroring, it's just going to return nil. And then we have an or, and then we have a hard-coded string.

+ +

So it's like, hey, we want to set this attribute to this value. If it's the hash, then give us back that value; if not, it's going to be nil, and then give us this hard-coded string. What we were seeing in the actual data is that we were getting an empty string. And initially, it was one of those; how are we possibly getting an empty string when we gave you a hard-coded string to give us instead? And it's because empty strings are truthy. When we were performing the dig, it was finding both of those values, but that value was set to an empty string. And because that evaluates to truthy, we weren't getting the hard-coded string, and then we were setting it to an empty string, and then that caused some problems. So then my question to you is should we have truthiness in our code?

+ +

CHRIS: Oh wow. That's a big question. It's also each language I might have a slightly different version of my answer. Yeah, I'm going to have to go sort of across languages to answer. I think in Ruby, I have generally been happy with Ruby's somewhat conservative implementation of truthiness. Yeah, anything that isn't nil false...is that it? Are those the only falsy values? There's maybe one more, but zero is not a falsy value. Empty string is not a falsy value. They're truthy, to name it in the affirmative. And I like that Ruby has a more conservative view of what things are. And so it can have this other surprising edge. I will say that I do reach for present? in Rails, so present? Present with a question mark at the end, that method in Rails, which I pronounce as present, huh?

+ +

STEPH: Which is delightful, by the way.

+ +

CHRIS: Well, thank you. That method I reach for often or presence would be the variant in this case where you can presence or and then chain on the thing that you want, and that gets the value. It will basically do the thing that you want here. And so, I do find myself reaching for that, which does imply that maybe Ruby's default truthiness is not quite what I want. And I want a little more permissive truthiness, a little more like, no, empty strings are not truthy. Empty string is an empty value, so it is empty. But yeah, I think I can always convince myself of the other argument when I'm angrily fighting against a bug that I ran into, and I'm surprised by. Like, I've experienced this from both sides many times in my life. I will say in JavaScript, I am constantly surprised by the very, very permissive type coercion that happens where you compare a string and a number, and suddenly they're both strings, and they get smashed together. It's like, wait, how is that ever the thing that I would want? And so JavaScript's version feels like it is definitively foundationally wrong.

+ +

Ruby's feels like it's maybe a tiny bit conservative, but I like that as a default and then Rails building on top of that. I think I lean towards that most of the time. I will say at the other end of the spectrum, I've worked with Haskell, and Haskell has I want to say it's like a list of chr, like C-H-R list of characters as the canonical way to do strings. I may be mixing this up. It may be actually the string type, but then there's also a text type, and they're slightly different. Maybe it's UTF. I forget what the distinction was, but they both exist, and they are both often found in libraries and in code. And you end up having to constantly convert back and forth. And there are no subtle equivalents between them or any type coercion between them because it's Haskell, and there isn't really any of that. And this was early on.

+ +

I never got particularly far in Haskell, but I found that so painful and frustrating. It was just like, come on; they’re like strings. Please just do the thing. You know what I mean. And Haskell was like, "I do not. And I require you to be ridiculously specific about it." So that was sort of the high end for me of like nope, definitely not that JavaScript of like anything's anything and it's fine. That feels bad. So somewhere in the middle, Ruby feels like it's a happy in the middle. Maybe Rails is actually where I want to land, but I don't know that there is a good answer to this. I don't know that there's a language that's like, we got it. It's this very specific set of things. It's truthy, and these are falsy, and it's perfect every time. Like, I don't think that can happen.

+ +

STEPH: As an aside, I like how your Haskell voice had the slight air of pretension that really resonated with me. [laughs]

+ +

CHRIS: I don't know what you're talking about. That doesn't sound familiar to me at all. [laughs]

+ +

STEPH: I agree. I don't know that anyone has gotten this perfect. But then again, I also haven't tried all the languages that are out there, so I don't feel like that's really a fair statement for me to make either. Specific to the Ruby world, I do think Boolean coercions are a bit nice because then they do make certain checks easier. So if you are working with an if statement, you can say, "If this, and then do that, else, do this." And that feels like a pretty nice common idiomatic flow that we use in Ruby but then still feels like one of those areas that can really bite you.

+ +

So while having this conversation with some other thoughtboters, Mike Burns provided a succinct approach to this that I think I really like where he said that he likes the use of truthy and falsy for if statements, Booleans for the and statement, and only truthy falsy for Booleans, so no nulls. So Boolean should not have three states is what that last part is highlighting. It should be just true or false. And then if we're working with the double ampersand and in Ruby, that then if you have that type of conditional that you are conveying, then to use a strict Boolean, be more strict and use the methods that you were referring to earlier, like empty and explicitly checking is this an actual...like turn it into a Boolean instead of relying on that that truthy falsy of is it present? Is it an empty string? Does that count? But then, for the if statements, those can be a little more loose.

+ +

And actually, now that I'm saying it, that first part, I get it. It's convenient, but I still feel like bugs lie down that path. And so, I think I'm still in favor of being more explicit. If I really care if something is true or false, I want to call out explicitly. I expect this to be true or false versus relying on the fact that I know it will evaluate, although I'm sure I do it all the time, just because that's how you often write idiomatic Ruby. So I'm interested in watching my own behavior now to see how often I'm relying on that truthy, falsy behavior, and then see the areas that I can mitigate that just because yeah, that bug is fresh in my mind, and I'd like to prevent those bugs going forward.

+ +

CHRIS: I really liked that phrase of that bug is fresh. So that bug is going to own a little bit more mindshare than that old bug that's a bit stale in the back of my brain. I will say as you were talking about idiomatic Ruby, I think you're right that the sort of core or idiomatic way to do it would be if the user or whatever to see is the user here, or are they nil? Did we find one, or did we not? That sort of thing is commonly the way it would be done. I almost always write those as if users are not present? I will convert it into that because A, I'm writing Ruby, and I write Ruby because I want it to sound like the human words that I would say. And so I wouldn't say like, "If user," I would say, "If the user is present, then do the thing." And so I write the code to do that, but I also get the different semantics that present? Brings or blank? Is the counterpart, the other side of it. That seems to be the way that I write my code. That's idiomatic me, Ruby, and I don't know how strongly I hold that belief. But that is definitely how I write those, which I find interesting in contrast to what you were saying.

+ +

The other thing that came to mind as you were saying this is that particular one of an empty string. I kind of want to force empty strings to not be okay, particularly at the database level. So I'll often have null false on a string column, but then I'll find empty strings in there. And I'm like, well, that's not what I meant. I wanted stuff in there. Database, I want you to stop it if I was just putting in an empty string because you're supposed to be the gatekeeper that keeps me honest. And so I do wonder if there is a Postgres extension that we could have similar to the citexts, citext, which is case-insensitive text. So you can say, "Yeah, store this as it is, but whenever you compare it, compare case-insensitively," because an email is an email. Even if I capitalize the third letter, it doesn't make it a different email. I want a non-empty text as a column type that is both null false but also has a check constraint for an empty string and prevents that.

+ +

And then similarly, the three-state Boolean thing that you're talking about, I will always do null false on a Boolean column because it's a lie if I ever tell myself. I'm like, yeah, but this Boolean could be null, then you've got something else. Then you've got an ADT, which I also can't represent in my database, and that makes me sad. I guess I can enum those, but it's not quite the same because I can't have additional data attached. That's a separate feeling that I have about databases. I'm going down a rabbit hole here. I wish the database would prevent me from putting in empty strings into null, false string columns. I understand that I'm going to have to do some work on my side to make that happen, but that's the world I want to live in.

+ +

STEPH: I'm trying to think of a name for when you have a Boolean that's also a potential null value. What do you have? You have nullean at that point?

+ +

CHRIS: Quantum Boolean.

+ +

STEPH: Quantum Boolean. [laughs]

+ +

CHRIS: Spooky Boolean.

+ +

STEPH: The maybe Boolean?

+ +

CHRIS: Yeah.

+ +

STEPH: No, that's worse. [laughs] Yeah, I'm with you. And I like the idiomatic Ruby. I think that is something that I would like to do more of where I'm explicitly checking if user instead of just checking for that presence and allowing that to flow through doing the present check and verifying that yes, we do have a user versus allowing that nil to then evaluate to falsy. That's the type of code that I think I'd like to be more strict about writing. But then it's also interesting as I'm formulating these ideas. Is it one of those if I'm reviewing a PR and I see that someone else didn't do it, am I going to advise like, hey, let's actually check or turn this into a true Boolean versus just relying on the truthy and falsy behavior? And probably not. I don't think I'm there yet. And I think this is more in the space that I'm interested in pursuing and seeing how it benefits the code that I'm writing. But I don't think I'm at the state where then I would advocate, at least not loudly, on other PRs that we do it. If it is, it'd be like a small suggestion, but it wouldn't be something that I would necessarily expect someone else to do.

+ +

CHRIS: Yeah, definitely the same for me on that, although it's a multi-step plan here, a multi-year plan. First, we say it on a podcast, then we say it again on a podcast, then we change all the hearts and minds, then everyone writes the style, then we're all in agreement that this is the thing that we should do. And then it's reasonable to bring up in a pull request, or even then, I still wouldn't want it. Then it's like standard rb or somebody else's job. That's the level of pull request comment that I'm like, really? Come on. Come on.

+ +

STEPH: This is a grassroots movement for eradicating truthiness and falsyness. I think we're going to need a lot of help to get this going. [laughs]

+ +

CHRIS: Thankfully, there are the millions of listeners to this show that will carry this torch forward, I assume.

+ +

STEPH: Millions. Absolutely.

+ +

CHRIS: I'm rounding roughly a little.

+ +

STEPH: There are a couple, yeah. [laughs] I'd be far more nervous if I knew we had millions of people listening.

+ +

CHRIS: I kind of know that people listen. But at the same time, most of the time, I just entirely forget about that, and I feel like we're just having a conversation, which I think is good. But yeah, the idea that actual humans will listen to this in the future is a weird one that just doesn't do good things in my head. So I just let that go. And you and I are just having a chat, and it's great.

+ +

STEPH: Yeah. I'm with you. And just to reiterate what you were saying earlier, we love getting listener questions. So if there's anything that you'd like to send our way and have us to chat about or something you'd like to share with us, then please do so. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

Support The Bike Shed

]]> + + + What do you get when you mix a worm and a hammerhead shark? Also ants. Steph made some cool new discoveries in bug-land. She also talks about deploys versus releases and how her and her team has changed their deploy structure. Two words: feature flags.

+ +

Chris talks about cookies: cookie sessions, cookie payloads, cookie footprints, cookie storing. Mmm cookies! The convo wraps up with lamenting over truthiness in code. Truthy or falsy? What's your call?

+ + + +

Transcript:

+ +

STEPH: At the top of my notes for today, I have marauder ants and hammerhead worms. [laughs]

+ +

CHRIS: I'm sorry, what? I lost you there for...not lost you, but I stopped following. I...what? Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going?

+ +

STEPH: Hey, Chris, it's been a good week. It's been busy, lots has been happening. I learned about a new creature that's in our backyard. They're called hammerhead worms. Have you ever heard of those?

+ +

CHRIS: I've heard of hammerhead and worms, but not together. The combination is new and novel for me.

+ +

STEPH: Cool. Cool. So take a hammerhead shark and a worm and combine the two and then you have a hammerhead worm. And it rained really heavily here recently because there's a tropical storm that's making its way up the East Coast. And when I was outside on the porch, I noticed that there were these new worms or worms that I'd never seen before on the back porch. And so I had to Google them to understand because they had the interesting hammer-shaped head. And I found out that they're called hammerhead worms. They're toxic worms that prey on earthworms. And they're basically immortal because if you cut them into multiple pieces, each section can regenerate into a fully developed organism within a few weeks, which is bananas. And a lot of people online highly recommend that you should kill them because they are a toxic predator and they prey on earthworms, which you want in your garden and in your yard. But I didn't, but I learned about them.

+ +

CHRIS: Wow. That's got some layers there, toxic, intense worms that you can cut in half. And so does their central nervous system just spread throughout their whole body? Where's their brain? How does it...I don't have any real thoughts here. That's just a bunch of stuff, and it's awesome. Thank you for sharing.

+ +

STEPH: I will warn you. I wouldn't read about hammerhead worms right before bed. Otherwise, you might have some nightmares because the way that they do prey and consume earthworms or other creatures that they prey on is the stuff of horror movies, which I find happens so much in nature, but them especially they fall into that category. So just be aware if you're reading about hammerhead worms and how they consume their food. Now I feel like everybody's going to go read. But as long as you have that warning, I feel safe sending you in that direction.

+ +

CHRIS: Yeah, first thing in the morning on a very sunny morning, that is the time to do this research.

+ +

STEPH: Exactly. He got it. I also learned about marauder ants because apparently, this is the day that I'm having. I'm learning about all these creatures. But I won't go into that one, but they're really interesting. And this one's thanks to someone on Twitter who shared, specifically @Rainmaker1973 is their Twitter handle if you want to go see what they shared about marauder ants. So I'll just leave that one for those that are curious. I won't dive into that one because I don't want to take us in the direction of that we're all about worms and ants now.

+ +

CHRIS: Not all about worms and ants but definitely some.

+ +

STEPH: But in technical news, I've got some stuff to share, but I was so excited about worms and ants that now I have to figure out which is the thing that I want to share from the week. So there's a couple of interesting things that I'd love to chat about with you, one of them, in particular, is there's been some interesting conversations going on with my client team around deploys versus releases and how we have changed our deploy structure, and then how that has impacted the rest of the team as they are communicating to customers as to what features are available. And there have been some interesting conversations around how to migrate this process forward.

+ +

So to provide a bit of context, we were previously having very strict, rigid deploys. So we would plan our deploys typically every Tuesday. It was usually once a week. And then we would make sure that everything had been through QA, things had been reviewed and tested. And then we would have one of those more like grand deploys, things are going out. And then hey, if you need to get something into the deploy, let us know; we need to talk about it. So there was just more process and structure to that. And so deploy really mapped to the idea that if we are doing a deploy, then that means all these feature bug fixes are going out, and this is now the time that we can tell customers, "Hey, this new feature is available or this bug that you reported to us has now been fixed." We have since been moving towards a more continuous deployment structure where we're not quite there where we're doing continuous deploy, but we are deploying at least once a day, so it's a lot more frequent.

+ +

And so this has changed the way that we really map the idea of the work that's being done versus the work that's actually available to customers. Because as we are merging work into the main branch, and then let's say if I'm working on a feature and then I merge that into the main branch and then push it up staging, we have an overnight QA process. So then overnight QA, if they say, "Hey, there's something that's wrong with this feature. It didn't quite meet the required specs," then they can kick that ticket back to me, but that's not true for my code. We could do a revert and take my code out at that point. But at this point, it's in main, and main may have been deployed at that point. So there have been some interesting strategies around how can we safely continue to deploy while we know we often have a 24-hour wait period for QA and to get sign-off on this work? But we want to keep moving forward and then also communicate that just because the code has been deployed doesn't necessarily mean that it's available to customers. There's a lot there. So I'm going to pause and see if you have questions.

+ +

CHRIS: Well, first, I'm just super excited to talk about this. This is something that's been very much top of mind for me, and it's a direction that I want to be going more and more, so yeah, excited that you're pushing the boundaries on this. I am intrigued. I'm guessing feature flags is the answer about how you're decoupling that and how you're making it so that you've got that separation of deployment and actual availability of the feature. So, yeah, can you talk more about that?

+ +

STEPH: Definitely. And yes, you're right. We're using feature flags, so we'll use the same scenario. I'm working on a feature, and I want to be able to release it safely, so I'm going to wrap it in a feature flag. And I'll probably wrap it, and maybe it's like a beta feature flag, something to indicate that this is a feature that's going to be available to all, but we don't actually want to turn it on until we know that it's truly ready to be turned on. So then that way, it's hidden, but then we can still merge it into the main branch. We can still have a deploy even if my code hasn't gone through QA at that point, but we know it's still safe to deploy. And then, QA can go to a staging environment; they can test it. And if they say, "No," it's fine because nothing was churned in production. But then, if it gets approved, then we can turn it on, and then we'll have a follow-up to then remove that feature flag.

+ +

CHRIS: So some follow-on questions. I'm wondering about the architecture of the application. Is this like traditional Rails app rendering HTML on the server, or do you have any more advanced client-side stuff? And then I'm also wondering what you're using for the actual feature flagging, and those will probably inform each other. But what's the story on both of those fronts?

+ +

STEPH: It's a traditional Rails application. So we're not using any other client-side application. It is Rails and rendering HTML. As for feature flags, so we're not using something traditional. And by traditional, I mean I typically have reached for Flipper in the past for managing feature flags. We're using more of a hand-rolled approach because there's a lot of context there that I don't know is necessarily helpful. But to answer your question, we essentially do have feature flags as columns in the database, and we can just check if they are enabled or disabled. And then that also allows us to easily turn it on, turn it off as well since it's just a database update.

+ +

CHRIS: Okay, that makes sense. I think the nature of being a Rails application rendering HTML on the server like what you're doing totally makes sense in that context. I think it becomes a lot harder the more complex the architecture of your application is. So if you've got microservices, then suddenly you've probably got to synchronize across some of them, and that sounds like a whole thing. Or even if you have a client-side application, then suddenly you've got to serialize the feature flag stuff across the boundary or somehow expose that, which really does push the issue of we could just render stuff on the server and send it to the client and let that be good enough, then man, is stuff simpler. But unfortunately, that's not the case in a lot of situations.

+ +

I'm expecting to be introducing feature flags on the app that I'm working on pretty soon. And again, we've got...so it's a Rails server-side thing. So there's going to be plenty of feature flag logic on that side. And then I'll need to do something to serialize it across the boundary and get it onto the client-side without ballooning every payload and adding complexity, and lookups, and whatnot. I think it's doable. Inertia, again, being the core architecture of the application, I think will make this a little bit easier, but I am interested to see what I'm able to pull off and how happy I am with where I get to.

+ +

Another question that I have for you then are you testing the various flows? So given a Boolean feature flag, you now have two different possible paths for your code to go through. And then there may be even more than Boolean, or you may have feature flags that sort of interact with each other. And how much complexity are you trying to manage and represent in the test suite?

+ +

STEPH: Yeah, good question, and we are. So we're testing both flows, especially if it's a new feature, then we are testing when the flag is enabled or disabled. One that's been tricky for me is what about a bug fix? Is that something that should be feature flagged? And I think at the surface level, if you're presuming that it needs to go through QA before this is live on production, then the answer is yes, that then you have to feature flag a bug fix, which feels weird. But then the other consideration would be, well, it is a bug fix. And could we find another way to QA this faster or some other approach so that way we don't have to wrap it in a feature flag? And I don't have a great answer for that one because I can see arguments in favor of either approach. Although wrapping everything in a feature flag does feel tedious, it's something that I'm not accustomed to doing. And it's something that then becomes a process for the team to remind each other that, hey, is this wrapped in a feature flag? Or just being mindful of that as part of our process. And it prompted me to think back on the other projects that I've worked on and how did we manage that flow? How did we go from development to staging to QA and then out to production?

+ +

And one additional consideration with this flow is that we do have an overnight QA team. So in the past, when I've worked with teams, often product managers or even other developers, we would QA each other's work. So then it was a pretty fast turnaround that then you could get something up on staging. Someone could check it out and say, "Yes" or "No." But then I'm also pretty confident most of the teams that I've worked with we have had a distinct staging branch. So we would often merge work into a staging branch, and then deploy that work, and then get it tested. And then, if it passed everything, then we would essentially cherry-pick that work and move it over into production.

+ +

And I can see there's a lot of arguments against that, but then I have also experienced that and had a really positive experience where we could test everything and not have to worry about going out to production. We didn't have to wrap everything in feature flags, and it just felt really nice to know that everything in the main or production branch, whatever you call your production branch, that everything in there was deployable versus having to go the feature flag route, or the hey, did this go through QA? I don't know. Let me check. Can I include this? Should I cherry-pick some commits into our actual deployment to avoid stuff that hasn't gone through QA? I've been through that dance before too, and that one's not great.

+ +

CHRIS: I like the way you're framing the different sort of trade-offs that we have there in velocity or deployment speed and ease of iteration versus confidence as things are going out. I have worked with a staging branch before, and I personally did not find it to be valuable. It ended up adding this indirection. Folks had to know how to use Git in a pretty deep way to be comfortable with that just as a starting point. So it already introduced this hurdle of knowledge, and then beyond that, that idea that you have commits going in in a certain order on the staging branch. But then say we verify the functionality of the third commit in that list, and we want to cherry-pick it across to the main branch. Commits don't actually...you can't just take the thing that you had there. That commit existed in the context of all the others. There are subtleties of how history exists in Git. And I would worry about those edge cases where you're taking a piece of work out of the context of the rest of the commits that were around it or before it is, more importantly…that preceded it in the history on the staging branch, and you're now bringing it across to the main branch. Have you now lost something that was meaningful?

+ +

Ideally, you would get a conflict if it was really bad, but that's more of like a syntactic diff level thing. It's not a functionality-level thing. So personally, I may be overly cautious around this, but I really like as much as possible to have the very boring linear history in Git and do everything I can such that work happens on feature branches and then gets merged in as a fast forward into the main branch or rather the main branch is fast-forward marched into my feature branch such that I'm never working with code that I haven't fully worked with in an integrated way before. But again, even that, as I'm saying that, I have this topological map of Git in my head as I'm saying all of that, and it's complicated. And having any of that complexity leak out into the way we talk about the work is something that I worry about, but maybe I'm worried about a bunch of things that don't matter. Maybe a staging branch is actually fantastic.

+ +

STEPH: I think you make a lot of good points. Those are a lot of good concerns that come up with...it comes back to the idea that we want to mimic production as much as possible, and we don't want to lose that parity. So then, by having a staging branch, then it feels that we've lost that parity. There could be stuff that's in staging that's not in production. And so staging could be a little bit of this Wild West area, and then that doesn't fully represent then what's going to production. So I certainly understand and agree with those points that you're making. And to speak specifically to the Git challenges, I agree. It does require some more Git knowledge to be able to make that work. Specifically, I think how we handled it on a previous project is where we'd actually cherry-pick our commits into staging and then deploy that. But we always had the PR issued against main. So then merging into main was often a bit easier.

+ +

But then you're right; things could get out of sync. And the PR is issued against main, so then you still could run into those oddities where then if you are cherry-picking commits in the staging, but then you have your final draft that's going into main. And then what are the differences between those, and what did you lose along the way? And as I say all of that out loud, I definitely understand the Git concerns. And I don't know; I just feel like there's not a great answer then here, which is shocking to me. I've been doing this for a while, and yet here I am feeling like there's not a great answer to this very vital part of our workflow. And I'm surprised even though that we do have a delayed QA process that this still feels like a painful thing to figure out how do we have a continuous deployment workflow even though we do have that delayed QA process?

+ +

CHRIS: I think somewhat fundamentally your comment there of "I'm surprised that we don't have a good answer to this is," I'm not surprised, I guess, is my reaction. I don't want to go to the software is bad and broken, and we don't know anything end of the spectrum. But I don't feel like we have great answers to a lot of the things about development. I feel like software is more broken than it should be. It costs more to develop. It is difficult. It's hard to create, and maintain, and build over time. And that's just, to get lofty about it, that's what the entire focus of my career is, is trying to solve that problem. But it's a big, hard problem that I do not think is solved, unlike just about any of the fronts. I know how to put stuff in a database and take it back out. And even that, I'm like, oh yeah, but what if the database gets really big? Or what if the database...everything has complexities and edge cases.

+ +

STEPH: [laughs]

+ +

CHRIS: And we've joked a handful of times about the catchphrase of The Bike Shed being it depends, and that really feels true, though. I don't know that that's unique to this industry either. I feel like everything in the world is just more complicated the more you look at it, and there aren't clear, good, obvious answers to just about anything in the world, but that's the human condition. I got weirdly philosophical on this, so we should probably round this out. [laughs]

+ +

STEPH: Well, I can circle us back because I was providing context, and I went a bit into the deep end providing all of that context. So if I circle back to what I wanted to share with you around deploys and releases, there has been that interesting conversation. Now that we have the context, there has been that interesting conversation around originally; we had this very structured deploys, a deploy map to the fact that features were going out to the world. And now we have this concept of a deploy doesn't necessarily mean that's available to customers. It doesn't mean that the code is running. It is more a deploy represents that we have placed a commit. We have placed code on the server. But that doesn't mean that it is accessible to anyone because it's probably hidden behind a feature flag.

+ +

But from the perspective of the rest of the team that then is communicating these changes out to customers, they still really need to know, okay, when is something actually available to customers? And we kept using this terminology around deploy. And so Joël Quenneville, another thoughtboter who's on this project with me, has done a lot of great, thoughtful work around how can we help them know when something is truly available versus when something is deployed? Because right now, we're using Jira for our ticket issue tracking. And there's a particular screen in Jira that was showing what's being deployed. And from that screen, you can see the status of the ticket, and you would see stuff like in code review, in QA. So, of course, those looking at the tickets are like, hold up, you're deploying something that's in QA? That sounds really dangerous and risky. Why are you doing that? And then we'd have to explain, well, we're deploying it, but it's not actually live or accessible to anybody, but we want to get close to that continuous deploy cycle.

+ +

So we have shifted to using the terminology of a release. So a deploy is more for the we're putting the code on the server and then release really represents okay, we have now released these features and these bug fixes, and they're now available all with the goal just to make sure that our teams are working well together. But it's been such an interesting conversation around how tickets move, the fact that they can progress linear and then also get moved backwards. But in continuous deployment, things don't go backwards and then making those things align. Typically, things don't go backwards. Technically, yes.

+ +

CHRIS: History is a directed acyclic graph that only points forward. The arrow of time is very clear on this matter. Yeah, that really does add one more layer of like; what does it mean to actually be out there in the world? I do wonder if giving view-only visibility to the feature flag dashboard and only when it's fully green does someone think that that's deployed? But if you're putting feature flags around everything, there's complexity. And yeah, it's just one more layer to having to manage all of this. And it sounds like you've gotten to a good place, or at least you're evolving in a way that's enjoyable. But yeah, it's complicated.

+ +

STEPH: Yeah, it definitely feels like we're moving in the right direction and that this will be a better...I want to say workflow, but it really focuses more around vocabulary and some of the changes to our processes and how we surface tickets in Jira. But it's more focused on how we talk about the changes that are getting shipped and when they're available. So, yeah, that's my story. What's new in your world?

+ +

CHRIS: Well, I very much appreciate your story. In my world, I am in the thick of the MBP initial drive to get something into production, which is one of my favorite times, especially if everyone's in agreement about what exactly do we mean by MVP? Who are the users going to be? What's it going to look like? What's the bar that we're going to maintain? What features can we drop? What can't we drop? When there's a good collaborative sort of everyone rowing in the same direction set of conversations around that, I just love the energy of that time. So I'm happily in that space hacking away on features building as much as I can as quickly as I can. But as part of that, there are a lot of just initial decisions and things that I have to wire up and stuff that I have to change or configure. Thankfully, Rails makes a lot of that not the case. I can just go with what's there and be happy about that.

+ +

But there is one thing that I did decide to change just today. But it's interesting; I don't think I've actually ever made this change before. I'm sure I've worked on an app that had this configuration, but typically, a Rails app will store the session in a cookie. So there is a signed HTTP only encrypted. I think those are all the things, but it uses a cookie to store that. And the actual data of the session lives in the payload of that cookie. And so, each time there's a request-response lifecycle, the full payload of that cookie is going up and down from the server to the client and then back and forth with all of the requests. And there's a limit; I think it's 4k is the limit on the cookie session.

+ +

But there are some limitations to cookie sessions as far as I'm coming to understand them; one is the ability to do replay attacks. So if someone gets a hold of that cookie, then unless you rotate the secret key base, which will have some pretty wide-ranging effects on your application, that cookie can be reused in the future because it basically just has like, this is the user's ID. There you go. And there's no way to revoke that other than rotating the secret key base. Additionally, there are just costs of that payload of data, especially if you're putting a non-trivial amount of stuff. Like, if you're getting close to that 4K limit, then you have 4K of overhead, both on the request and the response of your HTTP requests. So especially in apps that are somewhat chatty and making a bunch of Ajax requests or doing different things, that's some weight that you should consider.

+ +

So all of those mixed together, more so on the security side, I decided to look into it. And I have now switched from a cookie store, and I went all the way to the ActiveRecord database store. So I skipped over...there's a middle option that you can do with Memcached or Redis. We do have Redis in this particular application. We don't have Memcached yet; we probably will at some point. But you can do a memory store, so do Redis and store the session there, but I opted to go all the way to the database. And my understanding of the benefits here are we have a smaller cookie footprint, so smaller overhead on all the requests because now we're only sending the session ID. And then that references the actual payload of data that's stored in the database. We do have the ability now to invalidate sessions, so we can just truncate that table if we just want to sign all the users out and reset the world, which can be useful at times.

+ +

We also have the ability...if there's any particular user that's like, "I left myself logged in somewhere," we can…well, I actually don't know how to do this now that I say that. I don't know how to log out a specific user because the sessions don't inherently have the user associated with them. You can have an unauthenticated session, which then transitions to be authenticated when someone signs in, and then the user ID gets installed in there. I would love to have these indexed to users such that I could invalidate and have a button on the admin dashboard that says, "Sign out all instances," and that will revoke all of the sessions or actually delete them from the database table now. I think I would have to add some extra instrumentation to do that. So anytime a user signs in via device, we annotate the session records so that it's got a user ID column and then index on that so that we can look them up efficiently. I think that's how that would work, but that's one of those things that I'm like; I think I should think very hard about this before I do it. It has security implications. It's not part of the default package. There's probably a reason for that. I'm going to do that another day.

+ +

But yeah, overall, it was a pretty easy upgrade. I think I'm happy with it. It feels like one of those things that it's not clear to me why this isn't the default sort of thing where SQLite is often the database that you use just because it's slightly easier to get up and running? But for any application that we're working on, we're like, no, no, no, we're going to go to Postgres for local development and for everything because obviously, that's what we want to do. And I'm wondering if this should be in that space, like yeah, of course, the session should go in the database. There are so many reasons that it's better that way. I'm wondering if there are some edge cases that I'm not thinking about, but overall it seems cool. Have you ever worked with an alternative to the cookie store?

+ +

STEPH: I'm thinking back to the recent projects that I've worked on. And it's been a while since I've mucked around with session work specifically. And the more recent projects that I've been on, we've used JWTs, or they're pronounced jots, I found out, which is really surprising. I don't know why, but that's a thing.

+ +

CHRIS: What?

+ +

STEPH: [laughs]

+ +

CHRIS: This doesn't feel true.

+ +

STEPH: It's JWT, but it's pronounced jot, J-O-T.

+ +

CHRIS: I think I'm just going to not do that. This is a trend I'm not going to get on board with. [chuckles]

+ +

STEPH: I don't even know if it's a trend. I'm not sure who decreed this into the world.

+ +

CHRIS: You're familiar with the great internet war around GIF versus JIF, right? I think there's room for different opinions.

+ +

STEPH: I mean, it's really not a war. There's a correct side.

+ +

CHRIS: We're on the same side, right?

+ +

STEPH: [laughs] And this is how The Bike Shed ended. No, this is perfect for The Bike Shed. What am I talking about?

+ +

CHRIS: This is perfect for The Bike Shed. I'm just going to need to hear you say the word real quick. [chuckles]

+ +

STEPH: Oh, it's GIF, absolutely,

+ +

CHRIS: Okay. All right, phew. Steph, I was worried, I was worried. Also, anyone out there that says JIF, it's fine. These things don't really matter. Although I am surprised when you have an acronym that gets turned into...I think it's an initialism, like jot versus JWT. I forget which is which. I think JWT would be the acronym. But jot, that's not even...I'm going to move on and say...[laughs] And so I think that JWTs, which is what I'm going to call them in this context, are, as far as I understand it, an orthogonal, different sort of thing. Like, you can put a JWT in the session, and the session can be stored in a cookie or in the database or wherever. You can also put JWTs...often, they are in local storage, which my understanding is that's a bad idea. That is a security vulnerability waiting to happen from cross-site scripting, I think, is the one that is coming to mind. But I think that's an independent thing where JWT is this signed assertion that you are someone. But it's coming often from an external system versus I'm using devise in this case on a Rails app and so devise is using the warden session, which is signing and encrypting and a bunch of stuff that I'm not thinking about. But it's not using JWTs at the end of the day. Jot, really, huh?

+ +

STEPH: [laughs] I like how that's the thing that stuck out to you.

+ +

CHRIS: Of course it is.

+ +

STEPH: But it's fair because it did the same to me too, so I had to share it. [laughs]

+ +

CHRIS: This is The Bike Shed, after all. [laughs]

+ +

STEPH: So, going back to your question, what you've done sounds very reasonable to me, especially because you wanted to address that possibility of a replay attack. So I like the idea. I'm also intrigued by why it's not the default. What's the reasoning there? And I'm trying to think of a reason that it wouldn't be the default. And I don't have a great answer off the top of my head. Granted, it's also been a while since I've been in this space. But yeah, everything that you've done sounds really reasonable. I like it. I also see how being able to sign out a specific user would be really neat. That seems like a really nice feature. I don't know how often that would get used, but that seems like a really nice thing to be able to do to identify a particular user if they submitted and, I don't know, if some scenario came up and someone was like, "Help, please sign me out," then to have that ability. So I'll be intrigued to hear how this advances if you still really like this approach or if you find that you need to change back to using Memcached or the cookie store.

+ +

CHRIS: Yeah, I'm in that space where as I'm looking at it, I'm like, I only see upside here. I guess there's a tiny bit of extra complexity. You have to watch that database table and set up a regular recurring job to sort of sweep old sessions that haven't been touched in a while because this is sort of like an append-only store. Every time someone signs in anew, they're getting a new session. So over time, this database table is just going to grow and grow and grow. But it's very easy to stay on top of that if you just set up a recurring job that's cleaning them. It's part of the ActiveRecord session store is the name of the gem. It's under the Rails namespace or the Rails GitHub organization. So that seems manageable. Maybe that's the one complexity is it has this sort of runaway trait to it that you have to stay on top of, whereas the cookie-based sessions don't. But yeah, I'm seeing a lot of upside for us, so I'm going to try it. I think it's going to be good.

+ +

I'm also unfortunately in that space where I think I see all the moving parts as to how I could implement the sign out a user in all of their sessions. But I'm worried that I'm tricking myself there. It's one of those things it's like this feels like it would be built in if it was that straightforward, or it could easily have subtle...it's like, don't invent your own crypto. Like, I think I know how crypto algorithms work. I can just write one real quick. No, don't do that, definitely don't do that. And this one, it seems clear enough, but it's still in the space of crypto security, et cetera, that I just don't want to mess with without really thoroughly convincing myself that I know what I'm talking about. So maybe six months from now, I will have talked myself into it. Or if anyone out there is listening and knows of a good founded, well-thought-out version of yeah, this is totally a thing that we do; here’s what it looks like; I would love to hear that. But otherwise, I'll probably just be happy with the ability to wipe everyone's session as necessary. If any one user leaves themselves logged in at a library and needs me to log them out, I'll just log out every user. That's fine. That's a good enough solution.

+ +

STEPH: Yeah. All of that makes sense. And also, the part that you highlighted around that there is that additional work of where then you have to make sure that you have a rake task that's running to then sign people out since there's that additional lift that you mentioned. But I'm excited to hear what folks have to say if they're using this approach and what they think about it. It is super interesting.

+ +

CHRIS: Well, yeah, I am very excited about this new development and the management of sessions. And I will let you know if I make any headway on the signing out a user sort of thing. But I think that covers that topic. As an aside, I just wanted to take a quick moment to ask folks out there; we are getting to the bottom of our listener question queue, and we absolutely love getting listener questions. They really help us find novel things to talk about that whenever we start talking about them, it turns out that we have a lot to say. So please do send in any questions that you have. You can send them to hosts@bikeshed.fm. That's an email option. You can tweet at us; we're @bikeshed, or either of us individually. I'm @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: And we also have a Google Form, which we will link in the show notes of this episode. So any of those versions send us questions. It can be about more tech stuff, more process stuff, more team-building, really anything across the spectrum. But we really do love getting the questions in, and definitely helps provide a little bit more structure to the show. So, with that aside, Steph, what else is going on in your world?

+ +

STEPH: Yeah, I love when we call from our listener questions, for the reason that you highlighted because it often exposes me to different ways of thinking in topics that I hadn't considered before. And you're right; we’re often very opinionated souls. [laughs] And along that note, so I have a question for you. The context is another developer, and I ran into a bug. And when we initially looked at the bug, it was one of those there's no way. There's no way the code is in this state. That does not make sense. And then, of course, it's one of those well, the computer says otherwise, so clearly we're wrong. We just can't see how the code is getting to this place. And what was happening is we were setting a value. We were parsing some JSON. We're looking for a value in that JSON, and we're using dig specifically in Ruby. So if it's the JSON or if it's a hash, and then we're doing dig, and then we're going two layers deep. So let's say we're going foo and then bar, and then dig; if it doesn't find those values, instead of erroring, it's just going to return nil. And then we have an or, and then we have a hard-coded string.

+ +

So it's like, hey, we want to set this attribute to this value. If it's the hash, then give us back that value; if not, it's going to be nil, and then give us this hard-coded string. What we were seeing in the actual data is that we were getting an empty string. And initially, it was one of those; how are we possibly getting an empty string when we gave you a hard-coded string to give us instead? And it's because empty strings are truthy. When we were performing the dig, it was finding both of those values, but that value was set to an empty string. And because that evaluates to truthy, we weren't getting the hard-coded string, and then we were setting it to an empty string, and then that caused some problems. So then my question to you is should we have truthiness in our code?

+ +

CHRIS: Oh wow. That's a big question. It's also each language I might have a slightly different version of my answer. Yeah, I'm going to have to go sort of across languages to answer. I think in Ruby, I have generally been happy with Ruby's somewhat conservative implementation of truthiness. Yeah, anything that isn't nil false...is that it? Are those the only falsy values? There's maybe one more, but zero is not a falsy value. Empty string is not a falsy value. They're truthy, to name it in the affirmative. And I like that Ruby has a more conservative view of what things are. And so it can have this other surprising edge. I will say that I do reach for present? in Rails, so present? Present with a question mark at the end, that method in Rails, which I pronounce as present, huh?

+ +

STEPH: Which is delightful, by the way.

+ +

CHRIS: Well, thank you. That method I reach for often or presence would be the variant in this case where you can presence or and then chain on the thing that you want, and that gets the value. It will basically do the thing that you want here. And so, I do find myself reaching for that, which does imply that maybe Ruby's default truthiness is not quite what I want. And I want a little more permissive truthiness, a little more like, no, empty strings are not truthy. Empty string is an empty value, so it is empty. But yeah, I think I can always convince myself of the other argument when I'm angrily fighting against a bug that I ran into, and I'm surprised by. Like, I've experienced this from both sides many times in my life. I will say in JavaScript, I am constantly surprised by the very, very permissive type coercion that happens where you compare a string and a number, and suddenly they're both strings, and they get smashed together. It's like, wait, how is that ever the thing that I would want? And so JavaScript's version feels like it is definitively foundationally wrong.

+ +

Ruby's feels like it's maybe a tiny bit conservative, but I like that as a default and then Rails building on top of that. I think I lean towards that most of the time. I will say at the other end of the spectrum, I've worked with Haskell, and Haskell has I want to say it's like a list of chr, like C-H-R list of characters as the canonical way to do strings. I may be mixing this up. It may be actually the string type, but then there's also a text type, and they're slightly different. Maybe it's UTF. I forget what the distinction was, but they both exist, and they are both often found in libraries and in code. And you end up having to constantly convert back and forth. And there are no subtle equivalents between them or any type coercion between them because it's Haskell, and there isn't really any of that. And this was early on.

+ +

I never got particularly far in Haskell, but I found that so painful and frustrating. It was just like, come on; they’re like strings. Please just do the thing. You know what I mean. And Haskell was like, "I do not. And I require you to be ridiculously specific about it." So that was sort of the high end for me of like nope, definitely not that JavaScript of like anything's anything and it's fine. That feels bad. So somewhere in the middle, Ruby feels like it's a happy in the middle. Maybe Rails is actually where I want to land, but I don't know that there is a good answer to this. I don't know that there's a language that's like, we got it. It's this very specific set of things. It's truthy, and these are falsy, and it's perfect every time. Like, I don't think that can happen.

+ +

STEPH: As an aside, I like how your Haskell voice had the slight air of pretension that really resonated with me. [laughs]

+ +

CHRIS: I don't know what you're talking about. That doesn't sound familiar to me at all. [laughs]

+ +

STEPH: I agree. I don't know that anyone has gotten this perfect. But then again, I also haven't tried all the languages that are out there, so I don't feel like that's really a fair statement for me to make either. Specific to the Ruby world, I do think Boolean coercions are a bit nice because then they do make certain checks easier. So if you are working with an if statement, you can say, "If this, and then do that, else, do this." And that feels like a pretty nice common idiomatic flow that we use in Ruby but then still feels like one of those areas that can really bite you.

+ +

So while having this conversation with some other thoughtboters, Mike Burns provided a succinct approach to this that I think I really like where he said that he likes the use of truthy and falsy for if statements, Booleans for the and statement, and only truthy falsy for Booleans, so no nulls. So Boolean should not have three states is what that last part is highlighting. It should be just true or false. And then if we're working with the double ampersand and in Ruby, that then if you have that type of conditional that you are conveying, then to use a strict Boolean, be more strict and use the methods that you were referring to earlier, like empty and explicitly checking is this an actual...like turn it into a Boolean instead of relying on that that truthy falsy of is it present? Is it an empty string? Does that count? But then, for the if statements, those can be a little more loose.

+ +

And actually, now that I'm saying it, that first part, I get it. It's convenient, but I still feel like bugs lie down that path. And so, I think I'm still in favor of being more explicit. If I really care if something is true or false, I want to call out explicitly. I expect this to be true or false versus relying on the fact that I know it will evaluate, although I'm sure I do it all the time, just because that's how you often write idiomatic Ruby. So I'm interested in watching my own behavior now to see how often I'm relying on that truthy, falsy behavior, and then see the areas that I can mitigate that just because yeah, that bug is fresh in my mind, and I'd like to prevent those bugs going forward.

+ +

CHRIS: I really liked that phrase of that bug is fresh. So that bug is going to own a little bit more mindshare than that old bug that's a bit stale in the back of my brain. I will say as you were talking about idiomatic Ruby, I think you're right that the sort of core or idiomatic way to do it would be if the user or whatever to see is the user here, or are they nil? Did we find one, or did we not? That sort of thing is commonly the way it would be done. I almost always write those as if users are not present? I will convert it into that because A, I'm writing Ruby, and I write Ruby because I want it to sound like the human words that I would say. And so I wouldn't say like, "If user," I would say, "If the user is present, then do the thing." And so I write the code to do that, but I also get the different semantics that present? Brings or blank? Is the counterpart, the other side of it. That seems to be the way that I write my code. That's idiomatic me, Ruby, and I don't know how strongly I hold that belief. But that is definitely how I write those, which I find interesting in contrast to what you were saying.

+ +

The other thing that came to mind as you were saying this is that particular one of an empty string. I kind of want to force empty strings to not be okay, particularly at the database level. So I'll often have null false on a string column, but then I'll find empty strings in there. And I'm like, well, that's not what I meant. I wanted stuff in there. Database, I want you to stop it if I was just putting in an empty string because you're supposed to be the gatekeeper that keeps me honest. And so I do wonder if there is a Postgres extension that we could have similar to the citexts, citext, which is case-insensitive text. So you can say, "Yeah, store this as it is, but whenever you compare it, compare case-insensitively," because an email is an email. Even if I capitalize the third letter, it doesn't make it a different email. I want a non-empty text as a column type that is both null false but also has a check constraint for an empty string and prevents that.

+ +

And then similarly, the three-state Boolean thing that you're talking about, I will always do null false on a Boolean column because it's a lie if I ever tell myself. I'm like, yeah, but this Boolean could be null, then you've got something else. Then you've got an ADT, which I also can't represent in my database, and that makes me sad. I guess I can enum those, but it's not quite the same because I can't have additional data attached. That's a separate feeling that I have about databases. I'm going down a rabbit hole here. I wish the database would prevent me from putting in empty strings into null, false string columns. I understand that I'm going to have to do some work on my side to make that happen, but that's the world I want to live in.

+ +

STEPH: I'm trying to think of a name for when you have a Boolean that's also a potential null value. What do you have? You have nullean at that point?

+ +

CHRIS: Quantum Boolean.

+ +

STEPH: Quantum Boolean. [laughs]

+ +

CHRIS: Spooky Boolean.

+ +

STEPH: The maybe Boolean?

+ +

CHRIS: Yeah.

+ +

STEPH: No, that's worse. [laughs] Yeah, I'm with you. And I like the idiomatic Ruby. I think that is something that I would like to do more of where I'm explicitly checking if user instead of just checking for that presence and allowing that to flow through doing the present check and verifying that yes, we do have a user versus allowing that nil to then evaluate to falsy. That's the type of code that I think I'd like to be more strict about writing. But then it's also interesting as I'm formulating these ideas. Is it one of those if I'm reviewing a PR and I see that someone else didn't do it, am I going to advise like, hey, let's actually check or turn this into a true Boolean versus just relying on the truthy and falsy behavior? And probably not. I don't think I'm there yet. And I think this is more in the space that I'm interested in pursuing and seeing how it benefits the code that I'm writing. But I don't think I'm at the state where then I would advocate, at least not loudly, on other PRs that we do it. If it is, it'd be like a small suggestion, but it wouldn't be something that I would necessarily expect someone else to do.

+ +

CHRIS: Yeah, definitely the same for me on that, although it's a multi-step plan here, a multi-year plan. First, we say it on a podcast, then we say it again on a podcast, then we change all the hearts and minds, then everyone writes the style, then we're all in agreement that this is the thing that we should do. And then it's reasonable to bring up in a pull request, or even then, I still wouldn't want it. Then it's like standard rb or somebody else's job. That's the level of pull request comment that I'm like, really? Come on. Come on.

+ +

STEPH: This is a grassroots movement for eradicating truthiness and falsyness. I think we're going to need a lot of help to get this going. [laughs]

+ +

CHRIS: Thankfully, there are the millions of listeners to this show that will carry this torch forward, I assume.

+ +

STEPH: Millions. Absolutely.

+ +

CHRIS: I'm rounding roughly a little.

+ +

STEPH: There are a couple, yeah. [laughs] I'd be far more nervous if I knew we had millions of people listening.

+ +

CHRIS: I kind of know that people listen. But at the same time, most of the time, I just entirely forget about that, and I feel like we're just having a conversation, which I think is good. But yeah, the idea that actual humans will listen to this in the future is a weird one that just doesn't do good things in my head. So I just let that go. And you and I are just having a chat, and it's great.

+ +

STEPH: Yeah. I'm with you. And just to reiterate what you were saying earlier, we love getting listener questions. So if there's anything that you'd like to send our way and have us to chat about or something you'd like to share with us, then please do so. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @bikeshed or reach me on Twitter @SViccari.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+5QVl1ySq + + ]]> + + Chris Toomey + Steph Viccari + + + 300: Mozzarella Sticks & Knowledge Silos + https://bikeshed.thoughtbot.com/300 + b1c8ac46-7212-466e-9090-6f94e16c1c0c + Tue, 13 Jul 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + The big "Three Oh Oh!" What a milestone for this podcast! Aside from celebrating that the show has made it this far, Chris gives some followup on some Inertia.js issues he had been having, and talks about open source licenses and legality and testing against external APIs. Steph has thoughts on mozzarella sticks and what makes good ones; particularly the cheese to bread ratio... + +They then, together, answer a listener question re: knowledge silos: + +Jan asked, "Our team (3 pairs) is currently working on two different projects due to that fact we are creating information silos. Now we are looking into ways how we can minimize those information silos. Do you have any ideas how we could achieve this?" With switching pairs they are unsure about it as it can be difficult for new pairs to get up to speed. + 45:08 + no + + + The big "Three Oh Oh!" What a milestone for this podcast! Aside from celebrating that the show has made it this far, Chris gives some followup on some Inertia.js issues he had been having, and talks about open source licenses and legality and testing against external APIs. Steph has thoughts on mozzarella sticks and what makes good ones; particularly the cheese to bread ratio... +They then, together, answer a listener question re: knowledge silos: +Jan asked, "Our team (3 pairs) is currently working on two different projects due to that fact we are creating information silos. Now we are looking into ways how we can minimize those information silos. Do you have any ideas how we could achieve this?" With switching pairs they are unsure about it as it can be difficult for new pairs to get up to speed. +inertia-rails thread safety (https://github.com/inertiajs/inertia-rails/pull/70) +Rails Cache-Control no-store fix (https://github.com/rails/rails/pull/40324) +Transcript: +STEPH: I have no shame. +CHRIS: That's important in this industry. +STEPH: [laughs] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we learned along the way. Hey, Chris. So today's an exciting day. It's a rather momentous day, at least in my world, because today is our 300th episode. +CHRIS: 300? That is incredible. +STEPH: That's an incredible amount of episodes. And it made me pause and reflect on how many episodes I have been a part of. And I've realized it's over 100. I think it's around 104 or something like that, and I can't believe it. Time flies when you're behind the mic. +CHRIS: Time does fly, yeah. So yeah, fully a third of these you've been involved in. I don't know what the number is. And I'm just so grateful to Derek Prior and Sage Griffin, who started this whole process. And then to Thom Obarski, who was the producer for so long, and Mandy Moore, who recently joined us and has been doing a wonderful job of carrying that forward and to you, Steph, because this has just been such a joy to work on. Yeah, it's just a joy to be on the show and to get to chat with you each week and share some things. And frankly, learn from folks writing in questions and sharing pointers with us, and it really is such a delight. And yeah, 300 is pretty momentous. +STEPH: The listener questions and feedback have undoubtedly been a highlight for me. That is one of the areas that I love the most. I love the questions. I also love when people provide helpful answers to us, and then they help us out in return and also, all the incredible guests that we've had on the show. It has been phenomenal. I'm also very thankful to have been part of this journey and appreciate everyone that has got us here today. I wonder what the fourth iteration of The Bike Shed looks like. I consider this the third iteration because the first iteration was Sage Griffin and Derek Prior. The second iteration was where you took over The Bike Shed, and then you were hosting a number of incredible guests on the show. And then the third iteration is the iteration that we're living, so I wonder what the fourth will look like. +CHRIS: Oh, that is an interesting question. Hopefully, you and I get to hang out for a good bit longer. But at some point, much like the Green Lantern, this will get passed on, and someone else will take up the mantle and tell some stories. But, yeah, hopefully, that's not too soon because I certainly enjoy hanging out with you. +STEPH: Oh, I agree. I certainly enjoy this, and I'm in no rush to leave The Bike Shed. But I think it's just fun thinking about the next people that will carry this journey forward. +CHRIS: And determine the color of The Shed. +STEPH: And determine. I mean, that is their right. As host and co-host, they get to determine the color of The Shed. +CHRIS: 300 episodes in, and we still haven't figured it out. So I guess we got to keep trying. +STEPH: Oh, I have. I already know what color it is. +CHRIS: Is it yellow? +STEPH: It's yellow. +CHRIS: Yeah. Okay. [laughs] +STEPH: I like how we said yellow at the same time, you know. [laughs] +CHRIS: I do, although I feel like it's wrong to have a color in mind, or at least I want to dig in and talk about it for a while just to be in keeping with the show, but... +STEPH: One must first argue before deciding and then argue again. But to not continue bikeshedding on The Bike Shed, what's new in your world? +CHRIS: My week has been good. Actually, I have two quick updates on various Inertia things that I've shared in previous weeks. So we can include a show notes link for the two different episodes where I talked about these respective things. But there was one weird issue that I ran into with Inertia where it could start clicking a button that would delete, was behaving weirdly and occasionally, intermittently; some of the responses would end up as a full HTML page response as opposed to the expected Inertia response. And there's a bunch of subtlety around this. I actually reported it as an issue to the Inertia team. And they very kindly pointed me to the HTTP semantics at place. So it's the difference between a 302 redirect and a 303 redirect. And so, in their code, they were correctly doing a 303. They were standards-compliant; everything was great. But for some reason, it was still misbehaving sort of randomly, and I could never pin it down. I ended up working around it and opting out of Inertia behavior for those endpoints. But my assumption was that something in my Rails Middleware Stack was behaving weirdly and occasionally overriding Inertia Rails' setting of the status. So Inertia Rails was saying, "303," which is a special version of redirect, and something else in the Rails Middleware Stack, was saying, "302, it will be fine." +Turns out, in retrospect, the Inertia Rails team has discovered that this was, in fact, a threading bug on their side. So it's not Inertia's fault. Inertia as a core concept and as a protocol was definitely doing the right thing. And the Inertia-Rails Middleware was attempting to do the right thing. But threads and concurrency got in the way, which I'll be honest, I don't deeply understand those concepts. So I was just like, oh okay, that sounds like a thing that could go wrong occasionally, which is exactly how I experienced it. But now they've made an update to the project, so that should be resolved in a deep way. But goes to show you threading and concurrency are really tricky to chase down. +STEPH: I appreciate that you're coming back to give us the conclusion to that issue because I remember talking about it, and you were still going off on a journey and finding out what's wrong, so that's super interesting. And yeah, threads and concurrency those are super easy, like cache invalidation and naming, that's right up there. +CHRIS: It's actually kind of funny. One of the issue threads where I wrote about it, someone followed up and asked if I'd come to any solution. And I said, "Oh, I've gone kind of this weird way, and I'm doing these things." But I shared a code sample, and I said, "Just to be clear, this is 100% about something Rails is doing and not Inertia, which remains a stellar project." And then, very shortly after that, someone from the Inertia-Rails team was like, "Ah, actually, I think it was us. Sorry about that, but we fixed it now." And I was like, "I still love you guys. This is great. You're doing a great job. [chuckles] You continue to push the envelope in a wonderful way." But it was a funny interaction where I was like, never shall I let the name be dragged through the mud. Whoops. Okay. Never mind. +STEPH: You're an excellent hype man for Inertia. +CHRIS: I try, I really try. I believe in it to my core. And actually, there's another one that this one's not really related to Inertia at all, although I've seen it discussed within the context of Inertia. And again, I think the Inertia team has done a really great job of responding and pointing to here are the HTTP semantics, and adhering to the standards, and the way that things should work. But this one has to do with the back button. When you're doing sequential forms or really any sort of form type thing, the browser will just pull from its back/forward cache, which is a local cache of the HTML of the page as it just had it. And I had come to the understanding that this was not something that I could workaround. This was not something that I could control. I had tried every combination of headers, at least I thought I had, in Rails to try and control this from the server-side because ideally, the server is the one who knows about when data is changing and things of that nature. The server should be able to inform the browser, "Hey, don't cache or store this page in any way, always revalidate it." +It turns out there was a bug in Rails that was improperly normalizing the Cache-Control header and always removing the no-store Cache-Control value. So there are like five different or a handful of possible values that can be set for that header for the Cache-Control header. And Rails has a bunch of internal logic that says, "Okay, if you've set this, then I'll put these two, but not that one." And they're just trying to manage it and do nice things on our behalf. But unfortunately, they were being a little overzealous in that normalization effort. And so they were dropping an important value, which is no-store. So now there's a PR opened in Rails, or I think it's actually been merged in at this point that will fix that and allow you to set that particular header value, which then should get the behavior of "Hey, browser, if I hit the back button, please go ask the server. Don't trust your local cache, “which is exactly what I want. +STEPH: Interesting. Wow. So that's two very helpful resolutions to some of those strange issues you were running into before. +CHRIS: Yeah, definitely. And actually, for that issue, in particular, it was a very kind Bike Shed listener; Alexei Vasiliev wrote in and shared some initial thoughts, pointed me in the direction of some things. In that case, I actually was like, "I don't think that's the case. I tried it." And he was like, "No, no, no, pretty sure." And he was definitely correct in this case and was very kind and gave me an example of code reproduction and all of those nice things. So I was able to chase this down and then eventually find the issue in Rails, which had been opened like eight days before. So I think for me, I just happened to run into a weird period of time where Rails was subtly broken around this behavior. And therefore, I determined that the world was broken when, in fact, it was just a tiny slice of Rails' history. But yes, thank you so much, Alexei, for writing in and pointing me in the right direction on that. +STEPH: The dream came true. We talk about some of our troubles and our strifes, and people respond and help us out. +CHRIS: That is the dream. But yeah, so those are some quick updates, not really about me, although tangentially, I got to go along for these rides, and it was fun. But what else is up in your world? +STEPH: Let's see. Well, I also have a small update that I can share. It's circling back to the conversation that we had talking about extracting an untrustworthy service to a new location. And at that time, I don't remember exactly the process I laid out. But at that time, it’s the idea that it is a bit untrustworthy, but we have some security in how this process works, and it is ideal that we move it to this other location. So let's just go ahead and move it wholesale, bugs and all to the new location. And then there, we will start to refine, and we'll start to improve the service. Well, the update is that we have realized that the untrustworthy service is untrustworthy enough that I'm actually working on improving it in its current place just to a certain extent that then it feels like we can move it to another location. There have been enough issues with it that it has taken my focus to continue patching those bugs and making sure everything is working appropriately. But now I'm in the space of where I'm like, goodness, I thought I knew this thing and now I'm realizing I don't. And so, I'm looking for ways to inform myself and the team when something isn't working when we think it is. +So to provide a bit of context, this service is sending a bunch of messages to other systems, and most of the time, that is working, but there are times that it's not. And when it's not working, it's silent about the fact that those messages aren't being sent, and it's very important that we send those messages. So what's been on my mind is looking for a way to then elevate myself and the team to say, "Hey, these are the number of messages that are being sent on average." And then suddenly, let's say it dropped by 50%, or maybe we typically send 98% successful messages, and we have a 2% failure rate, but suddenly we have a 50% failure rate, but looking for those metrics that I can capture and then alert the team if something is going wrong. +And one of the suggestions that was bubbled up by Chad Pytel, who's a developer, he's also founder and COO of thoughtbot, and we're working on the same project together. And he had highlighted that a previous project that he worked on used AWS specifically to leverage the idea of tracking how many successful messages are being sent, or perhaps in their particular project, it was focused on how many orders were being processed. That was important to know. And in our case, we could do a similar metric where we look to see are we still sending messages? Has the number dropped significantly lately so then we can be notified, and then we can escalate that to PagerDuty? So then we notify the team that something's going on. +I don't know the specific mechanics of how I'm going to implement that yet. So I will report back, but I'm excited to have something that's going to alert me for when things aren't working the way I expect versus waiting for then someone that's a customer to notice it and then get back to us. It's very in line with a number of the topics that you've brought to the show recently, talking about how we can measure more of the user's experience and be notified sooner versus waiting for a user to bump into an error and then they reach out and notify us. +CHRIS: I'm super interested to hear where you get with that because that's definitely an area that I've poked at but not dug into particularly deeply. I know there are a number of projects like StatsD is one of them. I think there are others in that space, but that's where you're sending metrics just out to some service, and then you can aggregate and graph. I've also done similar things with Papertrail; I want to say, where you can do a very specific search in the logs, and then within that, you can aggregate and graph and show things over time. So you can do a very simplified version of what you're describing to sort of visualize a rate of something over time. And then I think they might have some thresholding alerts. +But also, that's one of those super hard things to do because it turns out like Monday morning, a lot of emails get sent and then Friday afternoon, fewer, and then on the weekend, none. And so, there's going to be an inherent sort of fluctuation to the data. And so then what is normal? What does the baseline look like? And then how do you do anomalies around that? Because inherently, there's going to be noise in the data. And so is it a 10% band around the normal? And I'm just saying a lot of words now that I barely know the meaning of. But it's one of those things where it's like, oh yeah, just let me know if it's behaving abnormally. There's so much in that one little sentence. And it's one of the like; I love the fractal complexity of this space where every part of that sentence that I just said is like, oh, that's way more complicated than it sounds when you just say that word. So very interested to hear where you get with this. And this is also something that I'll probably be pushing on in my work in the near term. So maybe we can even compare notes, but as of now, I just have, I think, buzzword-level knowledge of it. +STEPH: Well, I love that phrasing fractal complexity because yes, that was also where my brain got hung up in starting to think about this process and like, well, what's normal? I don't actually know what normal looks like because I haven't been tracking this until now. So do I go back a week and say, "Okay, let's compare our average sent rate to in the past week and try to define normal in that timeframe?" And I think the answer, for now, is to do the smallest thing but also has the biggest impact, and that's to notify the team if messages just stop. That feels like the first, small step to take, and then we can fine-tune. Do we want to know if suddenly successful messages are being marked as a failure? We have an increase in failed messages versus successful messages. But I think the first iteration is just to know or to confirm that we are sending messages and send us an alert if suddenly we're not sending messages for...ooh, I just realized there's a complexity in that statement too. It's like, how long are we not sending messages for? Is it for an hour? Is it for a day? +CHRIS: I was going to ask. +[laughter] +STEPH: I just caught myself there. Yeah. I don't have an answer to that right now. I have to think about it, but there's an answer there. I will have to choose an answer. +CHRIS: You sure will. And then you'll probably have to tweak it over time. It's also one of those topics where false negatives and false positives are really easy to fall into where the system's alerting too often. And so people then start to ignore the alerts versus it's too cautious before it will send out an alert and, therefore, you're missing things and so finding that optimum level. It also might be different days of the week. Aah. [chuckles] +STEPH: Yeah, I think that's very true. It will be different for different days of the week. So I have a lot more to think about in regards to how we're going to report on this. But that still feels very much like something I want in the world because right now, it's a lot of spelunking and production consoles to find out what's going on with the data and making sure that it's going through. And that feels like the least favorable option as to the world that I want to live in. +Oh, on a completely unrelated topic, I saw an article that I'm very excited to read. And it's not related to technology at all, but it looks like a very delightful article that someone wrote and titled My 14-Hour Search for the End of TGI Friday's Endless Appetizers. And I haven't read it in-depth yet, but I just read the first bit, and it seems like it's going to be delightful. But I thought of you because we've had previous outtakes around mozzarella sticks. And you were very excited when you thought thoughtbot had mozzarella sticks, the actual fried kind versus just the healthier cheese stick kind. So this seems like a thing that you'd enjoy. +CHRIS: I feel like it may have even ended up in an episode, and we talked about mozzarella wedges and the ratio of surface area to volume. +STEPH: Yes. +CHRIS: I don't know if that made it into an episode or not, but we have definitely you and I discussed mozzarella sticks before. And I'm definitely intrigued by this article. I will add it to Instapaper immediately and then probably never read it again because Instapaper is where I put things to forget them. But maybe someday I'll sit down with a coffee and read things. +STEPH: I've heard you mention Instapaper before, and I've looked into it. And I don't know why, but it just hasn't stuck for me. So I always throw anything that I want to explore or something that is also critical for me to do. I use Todoist. I don't know if you're familiar with that app, but that's my go-to. +CHRIS: Well, I'm familiar with Todoist. I take a slight line between my to-do list, which I want to be as, I don't know, clean and tidy and only the things that I have to do versus for me, Instapaper is a list of when I get around to it when I've got those ten free minutes, which apparently don't exist in the world. But when I have them, this is the list of things that I can read. But I think I've heard this from a number of people of having a more integrated system that all the stuff's in the same place. I keep my to-dos in Trello, also as an aside, and I'm not super happy with that. How do you like Todoist? Is it bringing you joy? +STEPH: I really like Todoist. I find it is simple enough an interface that I'm not spending a lot of time customizing it or messing around with it. I can just go there and log the things that I want. I can create individual projects and spaces as well. So if I want to separate my personal to-do list from my work to-do list or if I have a project, that's a really nice feature as well. I think my only small complaint is if I'm writing a date or if I'm writing tomorrow, Todoist will try to do the smart thing and say, "Oh, I'm going to add a due date for you since you mentioned a date." And I'm like, no, no, no, I don't want a due date. I just want to mention the specific date because somehow it's relevant. And undoing that is sometimes a little tricky. But otherwise, I have found Todoist very helpful. I'm a big fan. Also, you and I are slightly different creatures in terms of how neat and tidy we keep our spaces. I think how we both manage our email inbox is a really good indicator of this where you are more organized than I am when it comes to emails. And so, our to-do list might be similar. I'd be interested to see if Todoist fits your needs or if it doesn't offer enough structure. +CHRIS: I almost certainly could make it work. And it's one of those things where I've actually settled on Trello, which is a very loose tool. And so I've been able to shape it sort of to what I want, but it doesn't really have that many true productivity-type features. It's just a loose board where I can drag around cards and move them through. And that's worked fine, or I've been able to talk myself into not trying to be as neat and tidy and intentional with my to-do list, which I think has been good overall. I've looked at Todoist in the past. And the thing that gives me pause sort of related to what you were talking about with the date things, but I get the idea, or I get the sense that Todoist really, from a fundamental philosophical approach, really wants things to have dates and to have priorities, and my thinking is not quite that. Like, there is a priority, but it's relative. So it's the order of things in a list, but it's not this is a one, and this is a two, and that's another two. I find that logic of like there are different tiers of importance doesn't really map to my world, nor do dates. Almost everything I do has no date, has no context. It's just like when I'm at the computer because that's the only place I ever am. So it's when I'm at the computer, it's all kind of important-ish. Nothing really has a date, but it should probably be done pretty soon. That sort of stuff doesn't quite map to what I see in Todoist. So I've always found a little bit of a mismatch between what I think I want and what Todoist, as far as I understand, provides. I know they added Kanban-type boards recently. So I think that might help with just visualizing workflow and being a little closer to Trello, which I'm familiar with. But I'm sort of on the search right now for another to-do list. +I like what you said about being able to separate the work and personal because that's definitely a thing that I would want, although there's always the added complexity of whatever tracking tool that we're using as a team at work and which things go into my list versus that list. And do I try and synchronize them in any way? And then I do what I do, which is I start to imagine this ridiculously complex, fully integrated, bi-directional sinking nonsense system where like, never mind. Stop it. Pen and paper, Trello. I don't know; you’ve lost your privileges, though. This is me talking to myself. I lose my privileges much like I'm not allowed to ever try Emacs. I have had a multi-year moratorium on exploring new productivity tools, but I think maybe, just maybe, now is the time to revisit that. +STEPH: If you ever disappear for a week or two, I'll know that you tried Emacs or something like that happened +CHRIS: [chuckles] My beard is three times longer when I come back, and I'm like, "All right. I figured some stuff out, though." +STEPH: I'm with you in regards to trying to bucket all of your to-do items as if it's a priority one, two, three. I am not good at that, and I'm always wrong. So I've also given up on that system. I would describe myself as a minimalist user. I'm using all the basic functionality. I'm not leveraging what a lot of stuff that Todoist probably can do for me. And so I have a very just flat list of things that I'd like to do. I do have a couple of projects because I do try to have that personal versus work, and maybe I have some other project that's on there as well. And then, in my mind, I try to avoid due dates unless it's really important. Although I say that if it's really important, it's going on my calendar too because I'm going to budget time for it or make sure that I don't forget it. But then each day then I go through that full list, and then I pick the things that need to be done that day or it's reasonable to get done that day, and then I kick everything to the next day. So that way, I'm always reevaluating a fresh list of what do I need to tackle? What's reasonable for today, and what can I punt on? And Josh Clayton said this to me before, and I really liked it in terms of punting on work because typically, when you're really busy, something's always going to drop. You're always going to push something to the next day. So then it's just figuring out what's going to bounce and what's going to break? So I'm always looking for what's going to break? And let's prioritize that for today to make sure it gets done. If it will bounce, then I'm going to kick it to the next day, and I can't see it until I'm going back through that full list again. +CHRIS: I really like that framing around you're going to have to drop things. That's just the nature of life. There's always more to do than there is time. So will it bounce, or will it break in that? And that framing around how to decide which things get moved out. Interestingly, I just looked up because I wanted to know does Todoist support snoozing things? Which is something that I use constantly in Trello and Gmail and basically everywhere else. I'm just like, nope, future me problem, future me problem, and I just keep pushing things into the future. But critically, I want them to be hidden until that time. And it sounds like Todoist; you can set a future due date, and then it'll show up in today. But again, that's sort of conflating how I think about productivity and whatnot. +Also, I found…this is a Reddit post that I'm looking at where I'm determining this. And there is the question, and then there's someone answered, but the answer is deleted. And then there's someone replying to that saying, "Wow, what a thoughtful response. Have you written this up anywhere else, like a blog post? You sound like an absolute pro." But the parent comment, which apparently was beautiful, and articulate, and well-written, has been deleted. And this is the sadness of the internet. So a really beautiful xkcd about the saddest thing you can see is you search for a question, and you find Stack Overflow from 10 years ago one person asking the question and no answers. And you've got one other person out there in the world who cares the same way you do, but you have no answers, and it's sad. But I'm just sad about the loss of information. +STEPH: That's so tragic, or that's a really pro troll move. And you leave a comment, and then below, you're like, “Wow, that was amazing. That was beautiful.” And then you delete your own previous comment. So then you're just tricking people into thinking there was an answer. +CHRIS: It does sound almost performative, especially the last line, "You sound like an absolute pro." So I could see that being the case. And you know what? I'm going to choose to believe that that's what it is because then I can sleep better at night. So thank you, Steph. +STEPH: Happy to help. +CHRIS: But I think we should probably move on to perhaps a listener question or something. But before we do that, I do want to ask if anyone out there has a to-do list that they're using and they love; I would love to hear about it. I think I'm familiar with most of them, but votes of confidence from the listeners of this show will certainly go a long way with me. Because I think you folks are all very smart people. I mean, you're listening here, so, obviously. +STEPH: Yes, obviously. This very deeply intellectual show about mozzarella sticks and the ratio of cheese to fried and what's the best. +CHRIS: It's an important question. +STEPH: It is an important question. I have strong feelings about it. That's why we've talked about it. [chuckles] +CHRIS: On this very serious show that we host. +STEPH: [chuckles] Yes, we have an awesome listener question that I'm really excited to dive into. But before we do, I have a quick git thing that I'd love to share. It's a tip that Dimitry, another thoughtboter, shared with me today that I think is just really nice and something that I have not used before. And it's specific to a workflow where if you need to grab a file from another branch or from another commit, and then if you want to bring it into your current branch. And there are a couple of ways to go about it. One of them is you can do git checkout main and then pass the file presuming the file that you want is in main and then you want to bring it to your current branch. And that will copy over the file to that exact location. +But if you wanted to grab a file that's on the main branch but then you want to port that file to a new location, then you can use git-show and do git show branch. So let's say you're bringing a file from main over to your current branch, so it would be git show main: and then pass to the file that you wish to copy, and then the greater than sign and the path to where you want that file to live. So you can grab that file and then stash it in a new location, and you can also do it for commits too. So if someone has pushed up a commit and you want to copy a particular file, say if you need to bring in some of their work into your branch, then you could also do git show commit, and then that colon, and then the path to the file. And then, if you wanted to move it to a new location, you can use that greater than sign and then the path to where you would like that file to live. So it's a nice combination of the git command of git show and then also shell redirection. So then, you can pipe that content from the file that you wish to copy over to the new location that you would like. And it's not something that I've reached for very often, but I find lately I've been in a mode where I'm trying harder and harder to stay within my terminal and not have to jump over to GitHub or to external UIs if I can. And so this just feels like a nice additional tool where then I can use this one more thing where I don't have to either...I guess it's small. I could check out main locally. But even with this way, I don't have to switch branches, grab something, and bring it over, or I don't have to go to GitHub and then look for something. It feels like a nice way that then I could grab that file locally and bring it over to my branch. +CHRIS: That's a nice combination of tips there. Like you said, a bunch of different pieces at play, but that is definitely a super useful thing. It's one of those that I've not gotten that into muscle memory yet or even close to muscle memory. Git is complicated in terms of the interface that it provides, at least at the command line. I've been trying to make sense of it all and then trying to find what are the useful workflows that I want to build? Because you can do anything, and you can do most things in five different ways. And so finding that set that you do want to know deeply but then also getting that committed into your hands, not even into your head, is the thing that I strive for. But that particular one is one that I struggle with every single time. So especially, I think you broke that down really nicely, so it makes sense. +There's a corollary in Fugitive for any Vim users out there. There's a Gread command, so it's capital G-re-a-d. And then after that, it takes some identifier, and I've never gotten the identifier right. But as you just described it, it's the same as the git show sequence. So it's a commit or a branch name, colon, and then the file path that you want. And then, in Vim, you can use % to reference the current file. So I've tried really hard to teach my brain Gread main :%, and somehow, my brain doesn't want to remember that ridiculous sequence of characters. So, only in this moment am I like, oh, it all kind of fits together. +STEPH: Oh, that's nice. I am a Vim Fugitive user, but I didn't know that one. And I'm with you; I rarely remember all these off the top of my head unless I've done them like a hundred times, and it finally starts to sink in. So I always have a cheat sheet, or since we were talking about tooling earlier, I use Notion to capture tidbits for myself. So this is a place where I would probably stash in a web development folder that I have. And it's just a tip to my future self as to like, hey, remember when you were trying to do that thing, and then you had to look it up and figure it out? Well, here's how you did it, so then I can revisit it in the future. +CHRIS: I thought a number of times about introducing a flashcard system to revisit these sorts of things. Gary Bernhardt, who I had on a while back now, is building a platform that does this essentially for TypeScript and regular expressions in JavaScript arrays and a bunch of different topics. But it's got built into it the idea of spaced repetition, so you review a thing and then three days later, you review it again and then seven days later, and then ten. And there's a particular sequence to it, but it helps you to really internalize that knowledge. I've never gotten to the level of going to that, but I like that idea of being purposeful and trying to commit some things to memory because having them at your hands and being able to stay, like you said, in the terminal and closer to the work and not having to break out of the context, I do find a lot of value in that. But it does take some effort to build that up. So I've never quite gotten to that flashcard system myself. +STEPH: Yeah, that's interesting. I think I have mixed feelings about it because, on one hand, it is nice to commit some things to memory. And on the other hand, I'm totally cool with having a way to organize stuff so I can easily search it and find it later and not use up memory space for something that I don't use that often that then I just can't commit it. So I could definitely see it being useful. But I'm also okay with just having a nice way to search for it. +But pivoting a bit and circling back to the listener question that you alluded to earlier, we have a listener question from Jen and Jen wrote in about knowledge silos across different projects. Specifically, Jen wrote in "Hello, Steph and Chris, first of all, I want to say that I love to listen to your podcast for multiple years now." That's awesome. Thank you, Jen. "I like how you both share things along your week and fill the discussion with so many useful things and findings. Our team, which consists of three pairs, is currently working on two different projects. And due to that fact, we are creating information silos. Now we are looking into ways into how we can minimize those information silos. And do you have any ideas for how we can achieve this? Some additional context, switching pairs we're unsure about as this will be difficult for the new person to get up to speed. And currently, we are thinking about having a mob review session. But of course, with those, you only get a limited overview." All right. Well, thank you, Jen, for the question. I'm excited for knowledge silos because, I'll be honest, I am guilty of this one right now. I am a bit of a knowledge silo on my current project if we're telling our truths here on the show today. +CHRIS: Steph, I thought I knew you. +STEPH: You know, I'm full of surprises. +CHRIS: Aren't we all at various times? This really does feel like one of those core things that I associate with you, though. So it is interesting. But it's so easy to fall into this space. I think without purposeful, intentional effort, this is the natural way things will trend. It's so much easier for the person who understands a portion of a system or an entire system to take on the next piece of work for that system. And I think we can probably offer some specific advice. But to talk about it more generally, Jen, I think you've found yourself in the pretty common position of there isn't a great answer here. There's going to have to be an investment of some amount of effort; some potentially decreased productivity for a period of time in order to get out of the situation that you're in. But that's just the name of the game. So if we name it as that, and we say that, then the question becomes how much effort do we need to put towards that, and what are the different ways that we can do it? +So to go through the two that you listed, mob review sessions, I think can be a great way to give an introduction to a project, but I think they'll very quickly taper off in my experience. So I think it's a great way, especially if you're going to do any more formal things after that; a mob review or even a mob overview of the system is a great way to introduce new folks into it. But then from there, I personally would think that if you are feeling pain around the knowledge silos or even if you're not, because frankly, knowledge silos can very quickly become a major problem, say if someone needs to...if someone happens to leave the company or if someone needs to take some time off, anything of that nature, this is one of those things that can be fine until it's not, and then it's not in a very serious way, and that's the wrong time to try and resolve it. So I would very much be in favor of more purposeful things. +As you described, switching pairs is an interesting one. I think that's a cost you're probably going to have to pay. I am interested; the way you're talking about it, it sounds like your teams are paired up consistently, so you're working exclusively in those pairs, which frankly is a really interesting thing. I think it was the previous episode where Steph and I talked about agile and particularly 100% pairing, and that's a pretty intense idea. It also does potentially lean towards this. Now, each of those groups of people, each of those pairs is collectively aware of the same subset of the application. But now, if you were to split that up and you have six individuals that pair in varying sets across the different projects, you have this sort of Venn diagram tapestry of knowledge of the different systems and the subsets and the features. And for that reason, I actually would probably question, at least if I'm correctly interpreting it, that you have three consistent pairs; maybe you shuffle that up. Maybe that's a practice that should be unwound. And now the pair should rotate on a daily basis or something to that effect. But overall, I think this is a cost you're going to have to pay but will pay off longer term. And it's definitely worth doing in my mind. But yeah, that's some high-level thoughts. What do you think, Steph? +STEPH: I agree with all of those sentiments very much. And as you're talking about the cost and investing in the team, I think that's very true and something that needs to be done. The fact that they're working in pairs is already reducing knowledge silos because you at least have another person. Because I have been part of teams where there's one person that is that knowledge silo. So at least here, we already have two people that are aware of how code works and then why code was implemented in a certain way. So then, to categorize how painful that knowledge silo is or how risky that knowledge silo is, I think there are really two ends of the spectrum. And on one side, there's that example that you alluded to a little bit ago about isolating one developer on a project for six months, and they have minimal code reviews. And then suddenly that person leaves, and that's the hardest silo to then rectify. And it will probably be a lesson that stings enough that hopefully it won't be repeated where someone gets that isolated and then others have to figure out what was going on while that person was working on something independently. +And then on the other side of that spectrum is you need to take some time to explore and understand a portion of the application that you haven't worked on before, or perhaps it's you need to understand how to work with an internal API. And stuff on that side of the spectrum feels more addressable with documentation and also mob reviews. And maybe there are also demos as well because a lot of the knowledge that goes into building a product may not be specific to the code, but it's more why was this done, and why was it built, and why did we go this way? And that feels more addressable with documentation, with commit messages, with those mob review sessions, and also with demos where then you can show the high-level functionality of a feature that's being implemented. So then, even if everyone else on the team doesn't have the technical knowledge as to how it was built, they'll have more of the user context, and the product context as this is a feature that we built, and this is why it's useful to the world. I find a lot of that knowledge is what's harder to capture because then you'll find a feature and wonder who uses this and how is it in use? And that stuff is harder to backtrack. +Circling back to something that Jen caught out in their question, highlighting that it takes time for someone to get up to speed. That's a really interesting one for me because it goes back to the idea of wanting to know well; what’s difficult? Not specifically what is difficult, but let's define difficult and what's a reasonable level of difficultness because onboarding to any applications or onto a new section of code is always going to take some time to process and understand. But what's an acceptable timeline in which someone can onboard and be productive? There's something that I've heard from someone at thoughtbot. I don't have the exact context to quote them directly. If I find it, then I'll be sure to add it to the show notes. And they shared that another company is measuring this difficulty of onboarding by they take the person's first starting date, and then they track to see when that person has merged in 10 PRs because they are looking to see how long it took for that person to get up and running to then feel comfortable, to then make some contributions. +Often, your first couple of PRs might be something that's less challenging. It might be something that's updating the README because you are going through that onboarding process. And that's a great time to then reevaluate how clear the instructions are. But by the time you get to the 10th PR, you've probably addressed something that's a bit meatier and impactful to the product. And then they use that as a metric to then calculate okay; how well are we doing? Is it a month? Is it six months until someone gets there? How complicated is the application is another way that you could look at that metric to say, "Well, if it takes people a very long time to get there, maybe it's because of the codebase versus processes." And I really like that thinking of we have knowledge silos; let’s think about where it's actually hurting us. And then, if we think it's specific to the onboarding process where that part is painful, then let's break down how we can measure how difficult it is, and then look for ways to improve it but then also track that improvement. +CHRIS: Well, I like that idea of trying to quantify and measure onboarding. I've heard a lot of organizations having like, "We want you to ship a PR on your first day," that's a meaningful thing. But obviously, that first one will probably be pretty small, and it's sort of getting that first one out of the way, if anything. But it's not truly representative of someone being able to comfortably work within the repo, but ten, that starts to feel like a real number. And I do like quantifying it. More generally, I'm intrigued. Metrics around developer productivity is such a difficult thing to pin down. And it can, I think, become really complicated, especially if you're looking at individuals and trying to say, "Well, you had four PRs, but you had two PRs," and comparing individuals. But I do really like the idea of more aggregate stats of on average; right now last month, we were doing 1.2 PRs per week per developer, and now we're down 2.7 PRs per week per developer, something like that, and seeing that looks like something that we might want to address. Are there fundamental things that are happening that are causing development to slow down? Are we doing bigger PRs, et cetera? And starting to look at that, but try and have a metric to keep an eye on that. So I'm super intrigued by that and then again, more specifically to the onboarding one that you were talking about there. +Actually, popping up a slightly higher level, though, I think both you and I sort of jumped into this conversation as, like, yes, knowledge silos got to fix those, that's a problem. And I do feel that way. This is a topic that I feel pretty strongly about and pretty clearly about that knowledge silos are the natural state that things fall to, and it's not a good thing, and we want to avoid it. But it is important to ask the question of who is deeming this to be a problem and for what reasons? And we had a good conversation two episodes back in response to a different listener question about consulting versus building product. And I feel like, with this, we can almost go up to the consulting level of this can be a problem, but it also maybe isn't. Or, who believes it's a problem? Is it management thinking, "Oh no, when that person went on vacation, suddenly everything ground to a halt? This is a problem, and we need to resolve that." Or is it the development team themselves saying, "Hey, we feel like we're a bit siloed here, and that's a problem we're recognizing," but they don't have buy-in from management. Or worst case management saying, "This is a problem, but you get no time to resolve it." As long as everyone's in agreement of the potential benefits and aligned to this is a thing that we would want to improve, and then also aligned to there will be a cost to resolving it, that it's not free to try and unwind this siloing of knowledge, then I think everything can be great. But any mismatch at sort of any level of that either on the cost or the benefit side can be problematic. And so getting to the point where you've had a clear conversation that defines this and gets everyone to come to an idea of yes, we think it's a problem, and yes, we want to put in the effort to resolve it, then I think you can move forward and tackle any number of different approaches. But I think you have to start from that conversation. +STEPH: I love asking that question of how has this manifested into a problem or a concern? Because you just highlighted a really great example where if it's only a concern because someone was on vacation and the team couldn't respond to a customer request or couldn't respond to an outage, then there are different ways to address that. So documentation may not be the best way to help out with that. That's probably a pairing session. So then someone can respond quickly to an outage versus you don't want to say, "Okay, here's a couple of pages of documentation," and then have that developer go on vacation again, and then there's an outage, and you're trying to read through those pages to figure out what's wrong. So figuring out the right approach based on the pain that's being felt feels like a really great way to go about this. Because frankly, breaking down a knowledge silo is always going to have a cost. So you want to make sure that you're being as cost-efficient as possible with your approach and then addressing the root concerns and making everybody's lives better. +Because I do think there's some knowledge silo that's appropriate. And I think silo may be the wrong word, but someone who is more skilled or an expert in the area or has more context for a particular area of the application. Because applications can get so large that not everyone's going to know everything and context switching between all of those can be really challenging. So I think it's very natural that you're going to have different people that you go to around a certain feature. If there is some lofty feature around search and you know a particular person that has worked on it for a while, then you go to them, and that feels like an appropriate level of knowledge that someone has obtained. And I wouldn't classify that as a silo at that point. But then if you do get to the point where that person went on vacation and then search broke, then you can start to revisit okay, maybe this person does have too much context, and then we can offload some of that context to someone else. +CHRIS: There was a phrase I used earlier of like a patchwork quilt, but I think that's not quite the right image. There's an image in my mind of little islands of color that are fully separated; that’s bad. And then there's a version of more like a Venn diagram overlap where each of the colors sort of bleeds into the other ones, and I think that's good. But then the perfect overlap where it's just one big blob of brown because all the colors are the same, that's bad. And I think that's what you're highlighting is like, you don't want to go to that. You don't need the perfect overlap of everyone having a complete shared knowledge set. I'm trying to make word pictures over internet radio. So it's probably not going great, but it's something to that. Like, there is an optimization here, and I think the way to find that is by starting from what are the pain points? What are we feeling that is less than optimal? And then coming up with solutions that directly address those pain points, not generically try and target like knowledge silos bad. And retros are a perfect way to do that. So if you listen to our previous episode where we talk about the virtues of retros and other agile philosophies...This is great. I feel really good about being able to reference previous episodes. I think we've talked about good stuff in the previous episodes. +STEPH: You've been on fire with this episode. I think you've referenced at least two, three episodes at this point. [chuckles] +CHRIS: Yeah. Wow. Well, I mean, we're at 300 now, so we've got plenty to go back to. +[laughter] +STEPH: We've got plenty of content to reference. I think you and I do have an advantage here based on our experience where we have had to join a number of projects. And then we know our time with that project is very determined, and we want to make sure that we don't take any knowledge with us. So something that you and I have acquired as a skill is seeking knowledge when we first join a project and asking a lot of questions around how the application works and then understanding more about the intent of different features, and then knowing where to dive into a codebase to then make fruitful contributions. And I think there's a similar approach that can be taken when trying to break down a knowledge silo is a person who is that silo may be in a spot where they're having trouble communicating all that information and then dispersing it to others. So then us, as their teammates, can go to them and try to ask those types of questions to then help ourselves level up and then recognize areas that don't feel documented. And maybe it's adding documentation, maybe it's adding tests, or maybe it's doing a demo, maybe it's recording something about the feature and then sharing that with the team. But then you can be an advocate for that person who is in a silo position to then help them share that knowledge because they may be too far down that path where they don't recognize what they know, and other people don't. I don't know if that's directly related to being a knowledge silo but just an additional way to approach helping breaking down when you recognize that a silo does exist and looking for ways to then help that person communicate and distribute their knowledge. +CHRIS: Yeah, I think you're describing a distinction between a push versus a pull. It could be incumbent upon the person who has the knowledge to try and push it out to the team. But often, they're going to be perhaps a more senior person. They've got code review to do. They've got other meetings, and planning, and things, and they just may not have the time. But is there a way that other team members can proactively pull that information from them and help them find the moments that will clarify that? So, yeah, broadly, as a team, let's rally around the desilofication of the whole adventure. +STEPH: That's exactly what I was going for is that push versus pull mentality and how we can break down the silo from both sides. So thank you, Jen, for that wonderful question. I hope we gave you some helpful ideas and suggestions around addressing a silo and then also identifying the pains that you're feeling so that way you can find the most cost-effective approach. But on that note, shall we wrap up? +CHRIS: Let's wrap up. +STEPH: The show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey. +STEPH: And I’m @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeeee! +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._ + + + The big "Three Oh Oh!" What a milestone for this podcast! Aside from celebrating that the show has made it this far, Chris gives some followup on some Inertia.js issues he had been having, and talks about open source licenses and legality and testing against external APIs. Steph has thoughts on mozzarella sticks and what makes good ones; particularly the cheese to bread ratio...

+ +

They then, together, answer a listener question re: knowledge silos:

+ +

Jan asked, "Our team (3 pairs) is currently working on two different projects due to that fact we are creating information silos. Now we are looking into ways how we can minimize those information silos. Do you have any ideas how we could achieve this?" With switching pairs they are unsure about it as it can be difficult for new pairs to get up to speed.

+ + + +

Transcript:

+ +

STEPH: I have no shame.

+ +

CHRIS: That's important in this industry.

+ +

STEPH: [laughs] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we learned along the way. Hey, Chris. So today's an exciting day. It's a rather momentous day, at least in my world, because today is our 300th episode.

+ +

CHRIS: 300? That is incredible.

+ +

STEPH: That's an incredible amount of episodes. And it made me pause and reflect on how many episodes I have been a part of. And I've realized it's over 100. I think it's around 104 or something like that, and I can't believe it. Time flies when you're behind the mic.

+ +

CHRIS: Time does fly, yeah. So yeah, fully a third of these you've been involved in. I don't know what the number is. And I'm just so grateful to Derek Prior and Sage Griffin, who started this whole process. And then to Thom Obarski, who was the producer for so long, and Mandy Moore, who recently joined us and has been doing a wonderful job of carrying that forward and to you, Steph, because this has just been such a joy to work on. Yeah, it's just a joy to be on the show and to get to chat with you each week and share some things. And frankly, learn from folks writing in questions and sharing pointers with us, and it really is such a delight. And yeah, 300 is pretty momentous.

+ +

STEPH: The listener questions and feedback have undoubtedly been a highlight for me. That is one of the areas that I love the most. I love the questions. I also love when people provide helpful answers to us, and then they help us out in return and also, all the incredible guests that we've had on the show. It has been phenomenal. I'm also very thankful to have been part of this journey and appreciate everyone that has got us here today. I wonder what the fourth iteration of The Bike Shed looks like. I consider this the third iteration because the first iteration was Sage Griffin and Derek Prior. The second iteration was where you took over The Bike Shed, and then you were hosting a number of incredible guests on the show. And then the third iteration is the iteration that we're living, so I wonder what the fourth will look like.

+ +

CHRIS: Oh, that is an interesting question. Hopefully, you and I get to hang out for a good bit longer. But at some point, much like the Green Lantern, this will get passed on, and someone else will take up the mantle and tell some stories. But, yeah, hopefully, that's not too soon because I certainly enjoy hanging out with you.

+ +

STEPH: Oh, I agree. I certainly enjoy this, and I'm in no rush to leave The Bike Shed. But I think it's just fun thinking about the next people that will carry this journey forward.

+ +

CHRIS: And determine the color of The Shed.

+ +

STEPH: And determine. I mean, that is their right. As host and co-host, they get to determine the color of The Shed.

+ +

CHRIS: 300 episodes in, and we still haven't figured it out. So I guess we got to keep trying.

+ +

STEPH: Oh, I have. I already know what color it is.

+ +

CHRIS: Is it yellow?

+ +

STEPH: It's yellow.

+ +

CHRIS: Yeah. Okay. [laughs]

+ +

STEPH: I like how we said yellow at the same time, you know. [laughs]

+ +

CHRIS: I do, although I feel like it's wrong to have a color in mind, or at least I want to dig in and talk about it for a while just to be in keeping with the show, but...

+ +

STEPH: One must first argue before deciding and then argue again. But to not continue bikeshedding on The Bike Shed, what's new in your world?

+ +

CHRIS: My week has been good. Actually, I have two quick updates on various Inertia things that I've shared in previous weeks. So we can include a show notes link for the two different episodes where I talked about these respective things. But there was one weird issue that I ran into with Inertia where it could start clicking a button that would delete, was behaving weirdly and occasionally, intermittently; some of the responses would end up as a full HTML page response as opposed to the expected Inertia response. And there's a bunch of subtlety around this. I actually reported it as an issue to the Inertia team. And they very kindly pointed me to the HTTP semantics at place. So it's the difference between a 302 redirect and a 303 redirect. And so, in their code, they were correctly doing a 303. They were standards-compliant; everything was great. But for some reason, it was still misbehaving sort of randomly, and I could never pin it down. I ended up working around it and opting out of Inertia behavior for those endpoints. But my assumption was that something in my Rails Middleware Stack was behaving weirdly and occasionally overriding Inertia Rails' setting of the status. So Inertia Rails was saying, "303," which is a special version of redirect, and something else in the Rails Middleware Stack, was saying, "302, it will be fine."

+ +

Turns out, in retrospect, the Inertia Rails team has discovered that this was, in fact, a threading bug on their side. So it's not Inertia's fault. Inertia as a core concept and as a protocol was definitely doing the right thing. And the Inertia-Rails Middleware was attempting to do the right thing. But threads and concurrency got in the way, which I'll be honest, I don't deeply understand those concepts. So I was just like, oh okay, that sounds like a thing that could go wrong occasionally, which is exactly how I experienced it. But now they've made an update to the project, so that should be resolved in a deep way. But goes to show you threading and concurrency are really tricky to chase down.

+ +

STEPH: I appreciate that you're coming back to give us the conclusion to that issue because I remember talking about it, and you were still going off on a journey and finding out what's wrong, so that's super interesting. And yeah, threads and concurrency those are super easy, like cache invalidation and naming, that's right up there.

+ +

CHRIS: It's actually kind of funny. One of the issue threads where I wrote about it, someone followed up and asked if I'd come to any solution. And I said, "Oh, I've gone kind of this weird way, and I'm doing these things." But I shared a code sample, and I said, "Just to be clear, this is 100% about something Rails is doing and not Inertia, which remains a stellar project." And then, very shortly after that, someone from the Inertia-Rails team was like, "Ah, actually, I think it was us. Sorry about that, but we fixed it now." And I was like, "I still love you guys. This is great. You're doing a great job. [chuckles] You continue to push the envelope in a wonderful way." But it was a funny interaction where I was like, never shall I let the name be dragged through the mud. Whoops. Okay. Never mind.

+ +

STEPH: You're an excellent hype man for Inertia.

+ +

CHRIS: I try, I really try. I believe in it to my core. And actually, there's another one that this one's not really related to Inertia at all, although I've seen it discussed within the context of Inertia. And again, I think the Inertia team has done a really great job of responding and pointing to here are the HTTP semantics, and adhering to the standards, and the way that things should work. But this one has to do with the back button. When you're doing sequential forms or really any sort of form type thing, the browser will just pull from its back/forward cache, which is a local cache of the HTML of the page as it just had it. And I had come to the understanding that this was not something that I could workaround. This was not something that I could control. I had tried every combination of headers, at least I thought I had, in Rails to try and control this from the server-side because ideally, the server is the one who knows about when data is changing and things of that nature. The server should be able to inform the browser, "Hey, don't cache or store this page in any way, always revalidate it."

+ +

It turns out there was a bug in Rails that was improperly normalizing the Cache-Control header and always removing the no-store Cache-Control value. So there are like five different or a handful of possible values that can be set for that header for the Cache-Control header. And Rails has a bunch of internal logic that says, "Okay, if you've set this, then I'll put these two, but not that one." And they're just trying to manage it and do nice things on our behalf. But unfortunately, they were being a little overzealous in that normalization effort. And so they were dropping an important value, which is no-store. So now there's a PR opened in Rails, or I think it's actually been merged in at this point that will fix that and allow you to set that particular header value, which then should get the behavior of "Hey, browser, if I hit the back button, please go ask the server. Don't trust your local cache, “which is exactly what I want.

+ +

STEPH: Interesting. Wow. So that's two very helpful resolutions to some of those strange issues you were running into before.

+ +

CHRIS: Yeah, definitely. And actually, for that issue, in particular, it was a very kind Bike Shed listener; Alexei Vasiliev wrote in and shared some initial thoughts, pointed me in the direction of some things. In that case, I actually was like, "I don't think that's the case. I tried it." And he was like, "No, no, no, pretty sure." And he was definitely correct in this case and was very kind and gave me an example of code reproduction and all of those nice things. So I was able to chase this down and then eventually find the issue in Rails, which had been opened like eight days before. So I think for me, I just happened to run into a weird period of time where Rails was subtly broken around this behavior. And therefore, I determined that the world was broken when, in fact, it was just a tiny slice of Rails' history. But yes, thank you so much, Alexei, for writing in and pointing me in the right direction on that.

+ +

STEPH: The dream came true. We talk about some of our troubles and our strifes, and people respond and help us out.

+ +

CHRIS: That is the dream. But yeah, so those are some quick updates, not really about me, although tangentially, I got to go along for these rides, and it was fun. But what else is up in your world?

+ +

STEPH: Let's see. Well, I also have a small update that I can share. It's circling back to the conversation that we had talking about extracting an untrustworthy service to a new location. And at that time, I don't remember exactly the process I laid out. But at that time, it’s the idea that it is a bit untrustworthy, but we have some security in how this process works, and it is ideal that we move it to this other location. So let's just go ahead and move it wholesale, bugs and all to the new location. And then there, we will start to refine, and we'll start to improve the service. Well, the update is that we have realized that the untrustworthy service is untrustworthy enough that I'm actually working on improving it in its current place just to a certain extent that then it feels like we can move it to another location. There have been enough issues with it that it has taken my focus to continue patching those bugs and making sure everything is working appropriately. But now I'm in the space of where I'm like, goodness, I thought I knew this thing and now I'm realizing I don't. And so, I'm looking for ways to inform myself and the team when something isn't working when we think it is.

+ +

So to provide a bit of context, this service is sending a bunch of messages to other systems, and most of the time, that is working, but there are times that it's not. And when it's not working, it's silent about the fact that those messages aren't being sent, and it's very important that we send those messages. So what's been on my mind is looking for a way to then elevate myself and the team to say, "Hey, these are the number of messages that are being sent on average." And then suddenly, let's say it dropped by 50%, or maybe we typically send 98% successful messages, and we have a 2% failure rate, but suddenly we have a 50% failure rate, but looking for those metrics that I can capture and then alert the team if something is going wrong.

+ +

And one of the suggestions that was bubbled up by Chad Pytel, who's a developer, he's also founder and COO of thoughtbot, and we're working on the same project together. And he had highlighted that a previous project that he worked on used AWS specifically to leverage the idea of tracking how many successful messages are being sent, or perhaps in their particular project, it was focused on how many orders were being processed. That was important to know. And in our case, we could do a similar metric where we look to see are we still sending messages? Has the number dropped significantly lately so then we can be notified, and then we can escalate that to PagerDuty? So then we notify the team that something's going on.

+ +

I don't know the specific mechanics of how I'm going to implement that yet. So I will report back, but I'm excited to have something that's going to alert me for when things aren't working the way I expect versus waiting for then someone that's a customer to notice it and then get back to us. It's very in line with a number of the topics that you've brought to the show recently, talking about how we can measure more of the user's experience and be notified sooner versus waiting for a user to bump into an error and then they reach out and notify us.

+ +

CHRIS: I'm super interested to hear where you get with that because that's definitely an area that I've poked at but not dug into particularly deeply. I know there are a number of projects like StatsD is one of them. I think there are others in that space, but that's where you're sending metrics just out to some service, and then you can aggregate and graph. I've also done similar things with Papertrail; I want to say, where you can do a very specific search in the logs, and then within that, you can aggregate and graph and show things over time. So you can do a very simplified version of what you're describing to sort of visualize a rate of something over time. And then I think they might have some thresholding alerts.

+ +

But also, that's one of those super hard things to do because it turns out like Monday morning, a lot of emails get sent and then Friday afternoon, fewer, and then on the weekend, none. And so, there's going to be an inherent sort of fluctuation to the data. And so then what is normal? What does the baseline look like? And then how do you do anomalies around that? Because inherently, there's going to be noise in the data. And so is it a 10% band around the normal? And I'm just saying a lot of words now that I barely know the meaning of. But it's one of those things where it's like, oh yeah, just let me know if it's behaving abnormally. There's so much in that one little sentence. And it's one of the like; I love the fractal complexity of this space where every part of that sentence that I just said is like, oh, that's way more complicated than it sounds when you just say that word. So very interested to hear where you get with this. And this is also something that I'll probably be pushing on in my work in the near term. So maybe we can even compare notes, but as of now, I just have, I think, buzzword-level knowledge of it.

+ +

STEPH: Well, I love that phrasing fractal complexity because yes, that was also where my brain got hung up in starting to think about this process and like, well, what's normal? I don't actually know what normal looks like because I haven't been tracking this until now. So do I go back a week and say, "Okay, let's compare our average sent rate to in the past week and try to define normal in that timeframe?" And I think the answer, for now, is to do the smallest thing but also has the biggest impact, and that's to notify the team if messages just stop. That feels like the first, small step to take, and then we can fine-tune. Do we want to know if suddenly successful messages are being marked as a failure? We have an increase in failed messages versus successful messages. But I think the first iteration is just to know or to confirm that we are sending messages and send us an alert if suddenly we're not sending messages for...ooh, I just realized there's a complexity in that statement too. It's like, how long are we not sending messages for? Is it for an hour? Is it for a day?

+ +

CHRIS: I was going to ask.

+ +

[laughter]

+ +

STEPH: I just caught myself there. Yeah. I don't have an answer to that right now. I have to think about it, but there's an answer there. I will have to choose an answer.

+ +

CHRIS: You sure will. And then you'll probably have to tweak it over time. It's also one of those topics where false negatives and false positives are really easy to fall into where the system's alerting too often. And so people then start to ignore the alerts versus it's too cautious before it will send out an alert and, therefore, you're missing things and so finding that optimum level. It also might be different days of the week. Aah. [chuckles]

+ +

STEPH: Yeah, I think that's very true. It will be different for different days of the week. So I have a lot more to think about in regards to how we're going to report on this. But that still feels very much like something I want in the world because right now, it's a lot of spelunking and production consoles to find out what's going on with the data and making sure that it's going through. And that feels like the least favorable option as to the world that I want to live in.

+ +

Oh, on a completely unrelated topic, I saw an article that I'm very excited to read. And it's not related to technology at all, but it looks like a very delightful article that someone wrote and titled My 14-Hour Search for the End of TGI Friday's Endless Appetizers. And I haven't read it in-depth yet, but I just read the first bit, and it seems like it's going to be delightful. But I thought of you because we've had previous outtakes around mozzarella sticks. And you were very excited when you thought thoughtbot had mozzarella sticks, the actual fried kind versus just the healthier cheese stick kind. So this seems like a thing that you'd enjoy.

+ +

CHRIS: I feel like it may have even ended up in an episode, and we talked about mozzarella wedges and the ratio of surface area to volume.

+ +

STEPH: Yes.

+ +

CHRIS: I don't know if that made it into an episode or not, but we have definitely you and I discussed mozzarella sticks before. And I'm definitely intrigued by this article. I will add it to Instapaper immediately and then probably never read it again because Instapaper is where I put things to forget them. But maybe someday I'll sit down with a coffee and read things.

+ +

STEPH: I've heard you mention Instapaper before, and I've looked into it. And I don't know why, but it just hasn't stuck for me. So I always throw anything that I want to explore or something that is also critical for me to do. I use Todoist. I don't know if you're familiar with that app, but that's my go-to.

+ +

CHRIS: Well, I'm familiar with Todoist. I take a slight line between my to-do list, which I want to be as, I don't know, clean and tidy and only the things that I have to do versus for me, Instapaper is a list of when I get around to it when I've got those ten free minutes, which apparently don't exist in the world. But when I have them, this is the list of things that I can read. But I think I've heard this from a number of people of having a more integrated system that all the stuff's in the same place. I keep my to-dos in Trello, also as an aside, and I'm not super happy with that. How do you like Todoist? Is it bringing you joy?

+ +

STEPH: I really like Todoist. I find it is simple enough an interface that I'm not spending a lot of time customizing it or messing around with it. I can just go there and log the things that I want. I can create individual projects and spaces as well. So if I want to separate my personal to-do list from my work to-do list or if I have a project, that's a really nice feature as well. I think my only small complaint is if I'm writing a date or if I'm writing tomorrow, Todoist will try to do the smart thing and say, "Oh, I'm going to add a due date for you since you mentioned a date." And I'm like, no, no, no, I don't want a due date. I just want to mention the specific date because somehow it's relevant. And undoing that is sometimes a little tricky. But otherwise, I have found Todoist very helpful. I'm a big fan. Also, you and I are slightly different creatures in terms of how neat and tidy we keep our spaces. I think how we both manage our email inbox is a really good indicator of this where you are more organized than I am when it comes to emails. And so, our to-do list might be similar. I'd be interested to see if Todoist fits your needs or if it doesn't offer enough structure.

+ +

CHRIS: I almost certainly could make it work. And it's one of those things where I've actually settled on Trello, which is a very loose tool. And so I've been able to shape it sort of to what I want, but it doesn't really have that many true productivity-type features. It's just a loose board where I can drag around cards and move them through. And that's worked fine, or I've been able to talk myself into not trying to be as neat and tidy and intentional with my to-do list, which I think has been good overall. I've looked at Todoist in the past. And the thing that gives me pause sort of related to what you were talking about with the date things, but I get the idea, or I get the sense that Todoist really, from a fundamental philosophical approach, really wants things to have dates and to have priorities, and my thinking is not quite that. Like, there is a priority, but it's relative. So it's the order of things in a list, but it's not this is a one, and this is a two, and that's another two. I find that logic of like there are different tiers of importance doesn't really map to my world, nor do dates. Almost everything I do has no date, has no context. It's just like when I'm at the computer because that's the only place I ever am. So it's when I'm at the computer, it's all kind of important-ish. Nothing really has a date, but it should probably be done pretty soon. That sort of stuff doesn't quite map to what I see in Todoist. So I've always found a little bit of a mismatch between what I think I want and what Todoist, as far as I understand, provides. I know they added Kanban-type boards recently. So I think that might help with just visualizing workflow and being a little closer to Trello, which I'm familiar with. But I'm sort of on the search right now for another to-do list.

+ +

I like what you said about being able to separate the work and personal because that's definitely a thing that I would want, although there's always the added complexity of whatever tracking tool that we're using as a team at work and which things go into my list versus that list. And do I try and synchronize them in any way? And then I do what I do, which is I start to imagine this ridiculously complex, fully integrated, bi-directional sinking nonsense system where like, never mind. Stop it. Pen and paper, Trello. I don't know; you’ve lost your privileges, though. This is me talking to myself. I lose my privileges much like I'm not allowed to ever try Emacs. I have had a multi-year moratorium on exploring new productivity tools, but I think maybe, just maybe, now is the time to revisit that.

+ +

STEPH: If you ever disappear for a week or two, I'll know that you tried Emacs or something like that happened

+ +

CHRIS: [chuckles] My beard is three times longer when I come back, and I'm like, "All right. I figured some stuff out, though."

+ +

STEPH: I'm with you in regards to trying to bucket all of your to-do items as if it's a priority one, two, three. I am not good at that, and I'm always wrong. So I've also given up on that system. I would describe myself as a minimalist user. I'm using all the basic functionality. I'm not leveraging what a lot of stuff that Todoist probably can do for me. And so I have a very just flat list of things that I'd like to do. I do have a couple of projects because I do try to have that personal versus work, and maybe I have some other project that's on there as well. And then, in my mind, I try to avoid due dates unless it's really important. Although I say that if it's really important, it's going on my calendar too because I'm going to budget time for it or make sure that I don't forget it. But then each day then I go through that full list, and then I pick the things that need to be done that day or it's reasonable to get done that day, and then I kick everything to the next day. So that way, I'm always reevaluating a fresh list of what do I need to tackle? What's reasonable for today, and what can I punt on? And Josh Clayton said this to me before, and I really liked it in terms of punting on work because typically, when you're really busy, something's always going to drop. You're always going to push something to the next day. So then it's just figuring out what's going to bounce and what's going to break? So I'm always looking for what's going to break? And let's prioritize that for today to make sure it gets done. If it will bounce, then I'm going to kick it to the next day, and I can't see it until I'm going back through that full list again.

+ +

CHRIS: I really like that framing around you're going to have to drop things. That's just the nature of life. There's always more to do than there is time. So will it bounce, or will it break in that? And that framing around how to decide which things get moved out. Interestingly, I just looked up because I wanted to know does Todoist support snoozing things? Which is something that I use constantly in Trello and Gmail and basically everywhere else. I'm just like, nope, future me problem, future me problem, and I just keep pushing things into the future. But critically, I want them to be hidden until that time. And it sounds like Todoist; you can set a future due date, and then it'll show up in today. But again, that's sort of conflating how I think about productivity and whatnot.

+ +

Also, I found…this is a Reddit post that I'm looking at where I'm determining this. And there is the question, and then there's someone answered, but the answer is deleted. And then there's someone replying to that saying, "Wow, what a thoughtful response. Have you written this up anywhere else, like a blog post? You sound like an absolute pro." But the parent comment, which apparently was beautiful, and articulate, and well-written, has been deleted. And this is the sadness of the internet. So a really beautiful xkcd about the saddest thing you can see is you search for a question, and you find Stack Overflow from 10 years ago one person asking the question and no answers. And you've got one other person out there in the world who cares the same way you do, but you have no answers, and it's sad. But I'm just sad about the loss of information.

+ +

STEPH: That's so tragic, or that's a really pro troll move. And you leave a comment, and then below, you're like, “Wow, that was amazing. That was beautiful.” And then you delete your own previous comment. So then you're just tricking people into thinking there was an answer.

+ +

CHRIS: It does sound almost performative, especially the last line, "You sound like an absolute pro." So I could see that being the case. And you know what? I'm going to choose to believe that that's what it is because then I can sleep better at night. So thank you, Steph.

+ +

STEPH: Happy to help.

+ +

CHRIS: But I think we should probably move on to perhaps a listener question or something. But before we do that, I do want to ask if anyone out there has a to-do list that they're using and they love; I would love to hear about it. I think I'm familiar with most of them, but votes of confidence from the listeners of this show will certainly go a long way with me. Because I think you folks are all very smart people. I mean, you're listening here, so, obviously.

+ +

STEPH: Yes, obviously. This very deeply intellectual show about mozzarella sticks and the ratio of cheese to fried and what's the best.

+ +

CHRIS: It's an important question.

+ +

STEPH: It is an important question. I have strong feelings about it. That's why we've talked about it. [chuckles]

+ +

CHRIS: On this very serious show that we host.

+ +

STEPH: [chuckles] Yes, we have an awesome listener question that I'm really excited to dive into. But before we do, I have a quick git thing that I'd love to share. It's a tip that Dimitry, another thoughtboter, shared with me today that I think is just really nice and something that I have not used before. And it's specific to a workflow where if you need to grab a file from another branch or from another commit, and then if you want to bring it into your current branch. And there are a couple of ways to go about it. One of them is you can do git checkout main and then pass the file presuming the file that you want is in main and then you want to bring it to your current branch. And that will copy over the file to that exact location.

+ +

But if you wanted to grab a file that's on the main branch but then you want to port that file to a new location, then you can use git-show and do git show branch. So let's say you're bringing a file from main over to your current branch, so it would be git show main: and then pass to the file that you wish to copy, and then the greater than sign and the path to where you want that file to live. So you can grab that file and then stash it in a new location, and you can also do it for commits too. So if someone has pushed up a commit and you want to copy a particular file, say if you need to bring in some of their work into your branch, then you could also do git show commit, and then that colon, and then the path to the file. And then, if you wanted to move it to a new location, you can use that greater than sign and then the path to where you would like that file to live. So it's a nice combination of the git command of git show and then also shell redirection. So then, you can pipe that content from the file that you wish to copy over to the new location that you would like. And it's not something that I've reached for very often, but I find lately I've been in a mode where I'm trying harder and harder to stay within my terminal and not have to jump over to GitHub or to external UIs if I can. And so this just feels like a nice additional tool where then I can use this one more thing where I don't have to either...I guess it's small. I could check out main locally. But even with this way, I don't have to switch branches, grab something, and bring it over, or I don't have to go to GitHub and then look for something. It feels like a nice way that then I could grab that file locally and bring it over to my branch.

+ +

CHRIS: That's a nice combination of tips there. Like you said, a bunch of different pieces at play, but that is definitely a super useful thing. It's one of those that I've not gotten that into muscle memory yet or even close to muscle memory. Git is complicated in terms of the interface that it provides, at least at the command line. I've been trying to make sense of it all and then trying to find what are the useful workflows that I want to build? Because you can do anything, and you can do most things in five different ways. And so finding that set that you do want to know deeply but then also getting that committed into your hands, not even into your head, is the thing that I strive for. But that particular one is one that I struggle with every single time. So especially, I think you broke that down really nicely, so it makes sense.

+ +

There's a corollary in Fugitive for any Vim users out there. There's a Gread command, so it's capital G-re-a-d. And then after that, it takes some identifier, and I've never gotten the identifier right. But as you just described it, it's the same as the git show sequence. So it's a commit or a branch name, colon, and then the file path that you want. And then, in Vim, you can use % to reference the current file. So I've tried really hard to teach my brain Gread main :%, and somehow, my brain doesn't want to remember that ridiculous sequence of characters. So, only in this moment am I like, oh, it all kind of fits together.

+ +

STEPH: Oh, that's nice. I am a Vim Fugitive user, but I didn't know that one. And I'm with you; I rarely remember all these off the top of my head unless I've done them like a hundred times, and it finally starts to sink in. So I always have a cheat sheet, or since we were talking about tooling earlier, I use Notion to capture tidbits for myself. So this is a place where I would probably stash in a web development folder that I have. And it's just a tip to my future self as to like, hey, remember when you were trying to do that thing, and then you had to look it up and figure it out? Well, here's how you did it, so then I can revisit it in the future.

+ +

CHRIS: I thought a number of times about introducing a flashcard system to revisit these sorts of things. Gary Bernhardt, who I had on a while back now, is building a platform that does this essentially for TypeScript and regular expressions in JavaScript arrays and a bunch of different topics. But it's got built into it the idea of spaced repetition, so you review a thing and then three days later, you review it again and then seven days later, and then ten. And there's a particular sequence to it, but it helps you to really internalize that knowledge. I've never gotten to the level of going to that, but I like that idea of being purposeful and trying to commit some things to memory because having them at your hands and being able to stay, like you said, in the terminal and closer to the work and not having to break out of the context, I do find a lot of value in that. But it does take some effort to build that up. So I've never quite gotten to that flashcard system myself.

+ +

STEPH: Yeah, that's interesting. I think I have mixed feelings about it because, on one hand, it is nice to commit some things to memory. And on the other hand, I'm totally cool with having a way to organize stuff so I can easily search it and find it later and not use up memory space for something that I don't use that often that then I just can't commit it. So I could definitely see it being useful. But I'm also okay with just having a nice way to search for it.

+ +

But pivoting a bit and circling back to the listener question that you alluded to earlier, we have a listener question from Jen and Jen wrote in about knowledge silos across different projects. Specifically, Jen wrote in "Hello, Steph and Chris, first of all, I want to say that I love to listen to your podcast for multiple years now." That's awesome. Thank you, Jen. "I like how you both share things along your week and fill the discussion with so many useful things and findings. Our team, which consists of three pairs, is currently working on two different projects. And due to that fact, we are creating information silos. Now we are looking into ways into how we can minimize those information silos. And do you have any ideas for how we can achieve this? Some additional context, switching pairs we're unsure about as this will be difficult for the new person to get up to speed. And currently, we are thinking about having a mob review session. But of course, with those, you only get a limited overview." All right. Well, thank you, Jen, for the question. I'm excited for knowledge silos because, I'll be honest, I am guilty of this one right now. I am a bit of a knowledge silo on my current project if we're telling our truths here on the show today.

+ +

CHRIS: Steph, I thought I knew you.

+ +

STEPH: You know, I'm full of surprises.

+ +

CHRIS: Aren't we all at various times? This really does feel like one of those core things that I associate with you, though. So it is interesting. But it's so easy to fall into this space. I think without purposeful, intentional effort, this is the natural way things will trend. It's so much easier for the person who understands a portion of a system or an entire system to take on the next piece of work for that system. And I think we can probably offer some specific advice. But to talk about it more generally, Jen, I think you've found yourself in the pretty common position of there isn't a great answer here. There's going to have to be an investment of some amount of effort; some potentially decreased productivity for a period of time in order to get out of the situation that you're in. But that's just the name of the game. So if we name it as that, and we say that, then the question becomes how much effort do we need to put towards that, and what are the different ways that we can do it?

+ +

So to go through the two that you listed, mob review sessions, I think can be a great way to give an introduction to a project, but I think they'll very quickly taper off in my experience. So I think it's a great way, especially if you're going to do any more formal things after that; a mob review or even a mob overview of the system is a great way to introduce new folks into it. But then from there, I personally would think that if you are feeling pain around the knowledge silos or even if you're not, because frankly, knowledge silos can very quickly become a major problem, say if someone needs to...if someone happens to leave the company or if someone needs to take some time off, anything of that nature, this is one of those things that can be fine until it's not, and then it's not in a very serious way, and that's the wrong time to try and resolve it. So I would very much be in favor of more purposeful things.

+ +

As you described, switching pairs is an interesting one. I think that's a cost you're probably going to have to pay. I am interested; the way you're talking about it, it sounds like your teams are paired up consistently, so you're working exclusively in those pairs, which frankly is a really interesting thing. I think it was the previous episode where Steph and I talked about agile and particularly 100% pairing, and that's a pretty intense idea. It also does potentially lean towards this. Now, each of those groups of people, each of those pairs is collectively aware of the same subset of the application. But now, if you were to split that up and you have six individuals that pair in varying sets across the different projects, you have this sort of Venn diagram tapestry of knowledge of the different systems and the subsets and the features. And for that reason, I actually would probably question, at least if I'm correctly interpreting it, that you have three consistent pairs; maybe you shuffle that up. Maybe that's a practice that should be unwound. And now the pair should rotate on a daily basis or something to that effect. But overall, I think this is a cost you're going to have to pay but will pay off longer term. And it's definitely worth doing in my mind. But yeah, that's some high-level thoughts. What do you think, Steph?

+ +

STEPH: I agree with all of those sentiments very much. And as you're talking about the cost and investing in the team, I think that's very true and something that needs to be done. The fact that they're working in pairs is already reducing knowledge silos because you at least have another person. Because I have been part of teams where there's one person that is that knowledge silo. So at least here, we already have two people that are aware of how code works and then why code was implemented in a certain way. So then, to categorize how painful that knowledge silo is or how risky that knowledge silo is, I think there are really two ends of the spectrum. And on one side, there's that example that you alluded to a little bit ago about isolating one developer on a project for six months, and they have minimal code reviews. And then suddenly that person leaves, and that's the hardest silo to then rectify. And it will probably be a lesson that stings enough that hopefully it won't be repeated where someone gets that isolated and then others have to figure out what was going on while that person was working on something independently.

+ +

And then on the other side of that spectrum is you need to take some time to explore and understand a portion of the application that you haven't worked on before, or perhaps it's you need to understand how to work with an internal API. And stuff on that side of the spectrum feels more addressable with documentation and also mob reviews. And maybe there are also demos as well because a lot of the knowledge that goes into building a product may not be specific to the code, but it's more why was this done, and why was it built, and why did we go this way? And that feels more addressable with documentation, with commit messages, with those mob review sessions, and also with demos where then you can show the high-level functionality of a feature that's being implemented. So then, even if everyone else on the team doesn't have the technical knowledge as to how it was built, they'll have more of the user context, and the product context as this is a feature that we built, and this is why it's useful to the world. I find a lot of that knowledge is what's harder to capture because then you'll find a feature and wonder who uses this and how is it in use? And that stuff is harder to backtrack.

+ +

Circling back to something that Jen caught out in their question, highlighting that it takes time for someone to get up to speed. That's a really interesting one for me because it goes back to the idea of wanting to know well; what’s difficult? Not specifically what is difficult, but let's define difficult and what's a reasonable level of difficultness because onboarding to any applications or onto a new section of code is always going to take some time to process and understand. But what's an acceptable timeline in which someone can onboard and be productive? There's something that I've heard from someone at thoughtbot. I don't have the exact context to quote them directly. If I find it, then I'll be sure to add it to the show notes. And they shared that another company is measuring this difficulty of onboarding by they take the person's first starting date, and then they track to see when that person has merged in 10 PRs because they are looking to see how long it took for that person to get up and running to then feel comfortable, to then make some contributions.

+ +

Often, your first couple of PRs might be something that's less challenging. It might be something that's updating the README because you are going through that onboarding process. And that's a great time to then reevaluate how clear the instructions are. But by the time you get to the 10th PR, you've probably addressed something that's a bit meatier and impactful to the product. And then they use that as a metric to then calculate okay; how well are we doing? Is it a month? Is it six months until someone gets there? How complicated is the application is another way that you could look at that metric to say, "Well, if it takes people a very long time to get there, maybe it's because of the codebase versus processes." And I really like that thinking of we have knowledge silos; let’s think about where it's actually hurting us. And then, if we think it's specific to the onboarding process where that part is painful, then let's break down how we can measure how difficult it is, and then look for ways to improve it but then also track that improvement.

+ +

CHRIS: Well, I like that idea of trying to quantify and measure onboarding. I've heard a lot of organizations having like, "We want you to ship a PR on your first day," that's a meaningful thing. But obviously, that first one will probably be pretty small, and it's sort of getting that first one out of the way, if anything. But it's not truly representative of someone being able to comfortably work within the repo, but ten, that starts to feel like a real number. And I do like quantifying it. More generally, I'm intrigued. Metrics around developer productivity is such a difficult thing to pin down. And it can, I think, become really complicated, especially if you're looking at individuals and trying to say, "Well, you had four PRs, but you had two PRs," and comparing individuals. But I do really like the idea of more aggregate stats of on average; right now last month, we were doing 1.2 PRs per week per developer, and now we're down 2.7 PRs per week per developer, something like that, and seeing that looks like something that we might want to address. Are there fundamental things that are happening that are causing development to slow down? Are we doing bigger PRs, et cetera? And starting to look at that, but try and have a metric to keep an eye on that. So I'm super intrigued by that and then again, more specifically to the onboarding one that you were talking about there.

+ +

Actually, popping up a slightly higher level, though, I think both you and I sort of jumped into this conversation as, like, yes, knowledge silos got to fix those, that's a problem. And I do feel that way. This is a topic that I feel pretty strongly about and pretty clearly about that knowledge silos are the natural state that things fall to, and it's not a good thing, and we want to avoid it. But it is important to ask the question of who is deeming this to be a problem and for what reasons? And we had a good conversation two episodes back in response to a different listener question about consulting versus building product. And I feel like, with this, we can almost go up to the consulting level of this can be a problem, but it also maybe isn't. Or, who believes it's a problem? Is it management thinking, "Oh no, when that person went on vacation, suddenly everything ground to a halt? This is a problem, and we need to resolve that." Or is it the development team themselves saying, "Hey, we feel like we're a bit siloed here, and that's a problem we're recognizing," but they don't have buy-in from management. Or worst case management saying, "This is a problem, but you get no time to resolve it." As long as everyone's in agreement of the potential benefits and aligned to this is a thing that we would want to improve, and then also aligned to there will be a cost to resolving it, that it's not free to try and unwind this siloing of knowledge, then I think everything can be great. But any mismatch at sort of any level of that either on the cost or the benefit side can be problematic. And so getting to the point where you've had a clear conversation that defines this and gets everyone to come to an idea of yes, we think it's a problem, and yes, we want to put in the effort to resolve it, then I think you can move forward and tackle any number of different approaches. But I think you have to start from that conversation.

+ +

STEPH: I love asking that question of how has this manifested into a problem or a concern? Because you just highlighted a really great example where if it's only a concern because someone was on vacation and the team couldn't respond to a customer request or couldn't respond to an outage, then there are different ways to address that. So documentation may not be the best way to help out with that. That's probably a pairing session. So then someone can respond quickly to an outage versus you don't want to say, "Okay, here's a couple of pages of documentation," and then have that developer go on vacation again, and then there's an outage, and you're trying to read through those pages to figure out what's wrong. So figuring out the right approach based on the pain that's being felt feels like a really great way to go about this. Because frankly, breaking down a knowledge silo is always going to have a cost. So you want to make sure that you're being as cost-efficient as possible with your approach and then addressing the root concerns and making everybody's lives better.

+ +

Because I do think there's some knowledge silo that's appropriate. And I think silo may be the wrong word, but someone who is more skilled or an expert in the area or has more context for a particular area of the application. Because applications can get so large that not everyone's going to know everything and context switching between all of those can be really challenging. So I think it's very natural that you're going to have different people that you go to around a certain feature. If there is some lofty feature around search and you know a particular person that has worked on it for a while, then you go to them, and that feels like an appropriate level of knowledge that someone has obtained. And I wouldn't classify that as a silo at that point. But then if you do get to the point where that person went on vacation and then search broke, then you can start to revisit okay, maybe this person does have too much context, and then we can offload some of that context to someone else.

+ +

CHRIS: There was a phrase I used earlier of like a patchwork quilt, but I think that's not quite the right image. There's an image in my mind of little islands of color that are fully separated; that’s bad. And then there's a version of more like a Venn diagram overlap where each of the colors sort of bleeds into the other ones, and I think that's good. But then the perfect overlap where it's just one big blob of brown because all the colors are the same, that's bad. And I think that's what you're highlighting is like, you don't want to go to that. You don't need the perfect overlap of everyone having a complete shared knowledge set. I'm trying to make word pictures over internet radio. So it's probably not going great, but it's something to that. Like, there is an optimization here, and I think the way to find that is by starting from what are the pain points? What are we feeling that is less than optimal? And then coming up with solutions that directly address those pain points, not generically try and target like knowledge silos bad. And retros are a perfect way to do that. So if you listen to our previous episode where we talk about the virtues of retros and other agile philosophies...This is great. I feel really good about being able to reference previous episodes. I think we've talked about good stuff in the previous episodes.

+ +

STEPH: You've been on fire with this episode. I think you've referenced at least two, three episodes at this point. [chuckles]

+ +

CHRIS: Yeah. Wow. Well, I mean, we're at 300 now, so we've got plenty to go back to.

+ +

[laughter]

+ +

STEPH: We've got plenty of content to reference. I think you and I do have an advantage here based on our experience where we have had to join a number of projects. And then we know our time with that project is very determined, and we want to make sure that we don't take any knowledge with us. So something that you and I have acquired as a skill is seeking knowledge when we first join a project and asking a lot of questions around how the application works and then understanding more about the intent of different features, and then knowing where to dive into a codebase to then make fruitful contributions. And I think there's a similar approach that can be taken when trying to break down a knowledge silo is a person who is that silo may be in a spot where they're having trouble communicating all that information and then dispersing it to others. So then us, as their teammates, can go to them and try to ask those types of questions to then help ourselves level up and then recognize areas that don't feel documented. And maybe it's adding documentation, maybe it's adding tests, or maybe it's doing a demo, maybe it's recording something about the feature and then sharing that with the team. But then you can be an advocate for that person who is in a silo position to then help them share that knowledge because they may be too far down that path where they don't recognize what they know, and other people don't. I don't know if that's directly related to being a knowledge silo but just an additional way to approach helping breaking down when you recognize that a silo does exist and looking for ways to then help that person communicate and distribute their knowledge.

+ +

CHRIS: Yeah, I think you're describing a distinction between a push versus a pull. It could be incumbent upon the person who has the knowledge to try and push it out to the team. But often, they're going to be perhaps a more senior person. They've got code review to do. They've got other meetings, and planning, and things, and they just may not have the time. But is there a way that other team members can proactively pull that information from them and help them find the moments that will clarify that? So, yeah, broadly, as a team, let's rally around the desilofication of the whole adventure.

+ +

STEPH: That's exactly what I was going for is that push versus pull mentality and how we can break down the silo from both sides. So thank you, Jen, for that wonderful question. I hope we gave you some helpful ideas and suggestions around addressing a silo and then also identifying the pains that you're feeling so that way you can find the most cost-effective approach. But on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

Support The Bike Shed

]]> + + + The big "Three Oh Oh!" What a milestone for this podcast! Aside from celebrating that the show has made it this far, Chris gives some followup on some Inertia.js issues he had been having, and talks about open source licenses and legality and testing against external APIs. Steph has thoughts on mozzarella sticks and what makes good ones; particularly the cheese to bread ratio...

+ +

They then, together, answer a listener question re: knowledge silos:

+ +

Jan asked, "Our team (3 pairs) is currently working on two different projects due to that fact we are creating information silos. Now we are looking into ways how we can minimize those information silos. Do you have any ideas how we could achieve this?" With switching pairs they are unsure about it as it can be difficult for new pairs to get up to speed.

+ + + +

Transcript:

+ +

STEPH: I have no shame.

+ +

CHRIS: That's important in this industry.

+ +

STEPH: [laughs] Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we learned along the way. Hey, Chris. So today's an exciting day. It's a rather momentous day, at least in my world, because today is our 300th episode.

+ +

CHRIS: 300? That is incredible.

+ +

STEPH: That's an incredible amount of episodes. And it made me pause and reflect on how many episodes I have been a part of. And I've realized it's over 100. I think it's around 104 or something like that, and I can't believe it. Time flies when you're behind the mic.

+ +

CHRIS: Time does fly, yeah. So yeah, fully a third of these you've been involved in. I don't know what the number is. And I'm just so grateful to Derek Prior and Sage Griffin, who started this whole process. And then to Thom Obarski, who was the producer for so long, and Mandy Moore, who recently joined us and has been doing a wonderful job of carrying that forward and to you, Steph, because this has just been such a joy to work on. Yeah, it's just a joy to be on the show and to get to chat with you each week and share some things. And frankly, learn from folks writing in questions and sharing pointers with us, and it really is such a delight. And yeah, 300 is pretty momentous.

+ +

STEPH: The listener questions and feedback have undoubtedly been a highlight for me. That is one of the areas that I love the most. I love the questions. I also love when people provide helpful answers to us, and then they help us out in return and also, all the incredible guests that we've had on the show. It has been phenomenal. I'm also very thankful to have been part of this journey and appreciate everyone that has got us here today. I wonder what the fourth iteration of The Bike Shed looks like. I consider this the third iteration because the first iteration was Sage Griffin and Derek Prior. The second iteration was where you took over The Bike Shed, and then you were hosting a number of incredible guests on the show. And then the third iteration is the iteration that we're living, so I wonder what the fourth will look like.

+ +

CHRIS: Oh, that is an interesting question. Hopefully, you and I get to hang out for a good bit longer. But at some point, much like the Green Lantern, this will get passed on, and someone else will take up the mantle and tell some stories. But, yeah, hopefully, that's not too soon because I certainly enjoy hanging out with you.

+ +

STEPH: Oh, I agree. I certainly enjoy this, and I'm in no rush to leave The Bike Shed. But I think it's just fun thinking about the next people that will carry this journey forward.

+ +

CHRIS: And determine the color of The Shed.

+ +

STEPH: And determine. I mean, that is their right. As host and co-host, they get to determine the color of The Shed.

+ +

CHRIS: 300 episodes in, and we still haven't figured it out. So I guess we got to keep trying.

+ +

STEPH: Oh, I have. I already know what color it is.

+ +

CHRIS: Is it yellow?

+ +

STEPH: It's yellow.

+ +

CHRIS: Yeah. Okay. [laughs]

+ +

STEPH: I like how we said yellow at the same time, you know. [laughs]

+ +

CHRIS: I do, although I feel like it's wrong to have a color in mind, or at least I want to dig in and talk about it for a while just to be in keeping with the show, but...

+ +

STEPH: One must first argue before deciding and then argue again. But to not continue bikeshedding on The Bike Shed, what's new in your world?

+ +

CHRIS: My week has been good. Actually, I have two quick updates on various Inertia things that I've shared in previous weeks. So we can include a show notes link for the two different episodes where I talked about these respective things. But there was one weird issue that I ran into with Inertia where it could start clicking a button that would delete, was behaving weirdly and occasionally, intermittently; some of the responses would end up as a full HTML page response as opposed to the expected Inertia response. And there's a bunch of subtlety around this. I actually reported it as an issue to the Inertia team. And they very kindly pointed me to the HTTP semantics at place. So it's the difference between a 302 redirect and a 303 redirect. And so, in their code, they were correctly doing a 303. They were standards-compliant; everything was great. But for some reason, it was still misbehaving sort of randomly, and I could never pin it down. I ended up working around it and opting out of Inertia behavior for those endpoints. But my assumption was that something in my Rails Middleware Stack was behaving weirdly and occasionally overriding Inertia Rails' setting of the status. So Inertia Rails was saying, "303," which is a special version of redirect, and something else in the Rails Middleware Stack, was saying, "302, it will be fine."

+ +

Turns out, in retrospect, the Inertia Rails team has discovered that this was, in fact, a threading bug on their side. So it's not Inertia's fault. Inertia as a core concept and as a protocol was definitely doing the right thing. And the Inertia-Rails Middleware was attempting to do the right thing. But threads and concurrency got in the way, which I'll be honest, I don't deeply understand those concepts. So I was just like, oh okay, that sounds like a thing that could go wrong occasionally, which is exactly how I experienced it. But now they've made an update to the project, so that should be resolved in a deep way. But goes to show you threading and concurrency are really tricky to chase down.

+ +

STEPH: I appreciate that you're coming back to give us the conclusion to that issue because I remember talking about it, and you were still going off on a journey and finding out what's wrong, so that's super interesting. And yeah, threads and concurrency those are super easy, like cache invalidation and naming, that's right up there.

+ +

CHRIS: It's actually kind of funny. One of the issue threads where I wrote about it, someone followed up and asked if I'd come to any solution. And I said, "Oh, I've gone kind of this weird way, and I'm doing these things." But I shared a code sample, and I said, "Just to be clear, this is 100% about something Rails is doing and not Inertia, which remains a stellar project." And then, very shortly after that, someone from the Inertia-Rails team was like, "Ah, actually, I think it was us. Sorry about that, but we fixed it now." And I was like, "I still love you guys. This is great. You're doing a great job. [chuckles] You continue to push the envelope in a wonderful way." But it was a funny interaction where I was like, never shall I let the name be dragged through the mud. Whoops. Okay. Never mind.

+ +

STEPH: You're an excellent hype man for Inertia.

+ +

CHRIS: I try, I really try. I believe in it to my core. And actually, there's another one that this one's not really related to Inertia at all, although I've seen it discussed within the context of Inertia. And again, I think the Inertia team has done a really great job of responding and pointing to here are the HTTP semantics, and adhering to the standards, and the way that things should work. But this one has to do with the back button. When you're doing sequential forms or really any sort of form type thing, the browser will just pull from its back/forward cache, which is a local cache of the HTML of the page as it just had it. And I had come to the understanding that this was not something that I could workaround. This was not something that I could control. I had tried every combination of headers, at least I thought I had, in Rails to try and control this from the server-side because ideally, the server is the one who knows about when data is changing and things of that nature. The server should be able to inform the browser, "Hey, don't cache or store this page in any way, always revalidate it."

+ +

It turns out there was a bug in Rails that was improperly normalizing the Cache-Control header and always removing the no-store Cache-Control value. So there are like five different or a handful of possible values that can be set for that header for the Cache-Control header. And Rails has a bunch of internal logic that says, "Okay, if you've set this, then I'll put these two, but not that one." And they're just trying to manage it and do nice things on our behalf. But unfortunately, they were being a little overzealous in that normalization effort. And so they were dropping an important value, which is no-store. So now there's a PR opened in Rails, or I think it's actually been merged in at this point that will fix that and allow you to set that particular header value, which then should get the behavior of "Hey, browser, if I hit the back button, please go ask the server. Don't trust your local cache, “which is exactly what I want.

+ +

STEPH: Interesting. Wow. So that's two very helpful resolutions to some of those strange issues you were running into before.

+ +

CHRIS: Yeah, definitely. And actually, for that issue, in particular, it was a very kind Bike Shed listener; Alexei Vasiliev wrote in and shared some initial thoughts, pointed me in the direction of some things. In that case, I actually was like, "I don't think that's the case. I tried it." And he was like, "No, no, no, pretty sure." And he was definitely correct in this case and was very kind and gave me an example of code reproduction and all of those nice things. So I was able to chase this down and then eventually find the issue in Rails, which had been opened like eight days before. So I think for me, I just happened to run into a weird period of time where Rails was subtly broken around this behavior. And therefore, I determined that the world was broken when, in fact, it was just a tiny slice of Rails' history. But yes, thank you so much, Alexei, for writing in and pointing me in the right direction on that.

+ +

STEPH: The dream came true. We talk about some of our troubles and our strifes, and people respond and help us out.

+ +

CHRIS: That is the dream. But yeah, so those are some quick updates, not really about me, although tangentially, I got to go along for these rides, and it was fun. But what else is up in your world?

+ +

STEPH: Let's see. Well, I also have a small update that I can share. It's circling back to the conversation that we had talking about extracting an untrustworthy service to a new location. And at that time, I don't remember exactly the process I laid out. But at that time, it’s the idea that it is a bit untrustworthy, but we have some security in how this process works, and it is ideal that we move it to this other location. So let's just go ahead and move it wholesale, bugs and all to the new location. And then there, we will start to refine, and we'll start to improve the service. Well, the update is that we have realized that the untrustworthy service is untrustworthy enough that I'm actually working on improving it in its current place just to a certain extent that then it feels like we can move it to another location. There have been enough issues with it that it has taken my focus to continue patching those bugs and making sure everything is working appropriately. But now I'm in the space of where I'm like, goodness, I thought I knew this thing and now I'm realizing I don't. And so, I'm looking for ways to inform myself and the team when something isn't working when we think it is.

+ +

So to provide a bit of context, this service is sending a bunch of messages to other systems, and most of the time, that is working, but there are times that it's not. And when it's not working, it's silent about the fact that those messages aren't being sent, and it's very important that we send those messages. So what's been on my mind is looking for a way to then elevate myself and the team to say, "Hey, these are the number of messages that are being sent on average." And then suddenly, let's say it dropped by 50%, or maybe we typically send 98% successful messages, and we have a 2% failure rate, but suddenly we have a 50% failure rate, but looking for those metrics that I can capture and then alert the team if something is going wrong.

+ +

And one of the suggestions that was bubbled up by Chad Pytel, who's a developer, he's also founder and COO of thoughtbot, and we're working on the same project together. And he had highlighted that a previous project that he worked on used AWS specifically to leverage the idea of tracking how many successful messages are being sent, or perhaps in their particular project, it was focused on how many orders were being processed. That was important to know. And in our case, we could do a similar metric where we look to see are we still sending messages? Has the number dropped significantly lately so then we can be notified, and then we can escalate that to PagerDuty? So then we notify the team that something's going on.

+ +

I don't know the specific mechanics of how I'm going to implement that yet. So I will report back, but I'm excited to have something that's going to alert me for when things aren't working the way I expect versus waiting for then someone that's a customer to notice it and then get back to us. It's very in line with a number of the topics that you've brought to the show recently, talking about how we can measure more of the user's experience and be notified sooner versus waiting for a user to bump into an error and then they reach out and notify us.

+ +

CHRIS: I'm super interested to hear where you get with that because that's definitely an area that I've poked at but not dug into particularly deeply. I know there are a number of projects like StatsD is one of them. I think there are others in that space, but that's where you're sending metrics just out to some service, and then you can aggregate and graph. I've also done similar things with Papertrail; I want to say, where you can do a very specific search in the logs, and then within that, you can aggregate and graph and show things over time. So you can do a very simplified version of what you're describing to sort of visualize a rate of something over time. And then I think they might have some thresholding alerts.

+ +

But also, that's one of those super hard things to do because it turns out like Monday morning, a lot of emails get sent and then Friday afternoon, fewer, and then on the weekend, none. And so, there's going to be an inherent sort of fluctuation to the data. And so then what is normal? What does the baseline look like? And then how do you do anomalies around that? Because inherently, there's going to be noise in the data. And so is it a 10% band around the normal? And I'm just saying a lot of words now that I barely know the meaning of. But it's one of those things where it's like, oh yeah, just let me know if it's behaving abnormally. There's so much in that one little sentence. And it's one of the like; I love the fractal complexity of this space where every part of that sentence that I just said is like, oh, that's way more complicated than it sounds when you just say that word. So very interested to hear where you get with this. And this is also something that I'll probably be pushing on in my work in the near term. So maybe we can even compare notes, but as of now, I just have, I think, buzzword-level knowledge of it.

+ +

STEPH: Well, I love that phrasing fractal complexity because yes, that was also where my brain got hung up in starting to think about this process and like, well, what's normal? I don't actually know what normal looks like because I haven't been tracking this until now. So do I go back a week and say, "Okay, let's compare our average sent rate to in the past week and try to define normal in that timeframe?" And I think the answer, for now, is to do the smallest thing but also has the biggest impact, and that's to notify the team if messages just stop. That feels like the first, small step to take, and then we can fine-tune. Do we want to know if suddenly successful messages are being marked as a failure? We have an increase in failed messages versus successful messages. But I think the first iteration is just to know or to confirm that we are sending messages and send us an alert if suddenly we're not sending messages for...ooh, I just realized there's a complexity in that statement too. It's like, how long are we not sending messages for? Is it for an hour? Is it for a day?

+ +

CHRIS: I was going to ask.

+ +

[laughter]

+ +

STEPH: I just caught myself there. Yeah. I don't have an answer to that right now. I have to think about it, but there's an answer there. I will have to choose an answer.

+ +

CHRIS: You sure will. And then you'll probably have to tweak it over time. It's also one of those topics where false negatives and false positives are really easy to fall into where the system's alerting too often. And so people then start to ignore the alerts versus it's too cautious before it will send out an alert and, therefore, you're missing things and so finding that optimum level. It also might be different days of the week. Aah. [chuckles]

+ +

STEPH: Yeah, I think that's very true. It will be different for different days of the week. So I have a lot more to think about in regards to how we're going to report on this. But that still feels very much like something I want in the world because right now, it's a lot of spelunking and production consoles to find out what's going on with the data and making sure that it's going through. And that feels like the least favorable option as to the world that I want to live in.

+ +

Oh, on a completely unrelated topic, I saw an article that I'm very excited to read. And it's not related to technology at all, but it looks like a very delightful article that someone wrote and titled My 14-Hour Search for the End of TGI Friday's Endless Appetizers. And I haven't read it in-depth yet, but I just read the first bit, and it seems like it's going to be delightful. But I thought of you because we've had previous outtakes around mozzarella sticks. And you were very excited when you thought thoughtbot had mozzarella sticks, the actual fried kind versus just the healthier cheese stick kind. So this seems like a thing that you'd enjoy.

+ +

CHRIS: I feel like it may have even ended up in an episode, and we talked about mozzarella wedges and the ratio of surface area to volume.

+ +

STEPH: Yes.

+ +

CHRIS: I don't know if that made it into an episode or not, but we have definitely you and I discussed mozzarella sticks before. And I'm definitely intrigued by this article. I will add it to Instapaper immediately and then probably never read it again because Instapaper is where I put things to forget them. But maybe someday I'll sit down with a coffee and read things.

+ +

STEPH: I've heard you mention Instapaper before, and I've looked into it. And I don't know why, but it just hasn't stuck for me. So I always throw anything that I want to explore or something that is also critical for me to do. I use Todoist. I don't know if you're familiar with that app, but that's my go-to.

+ +

CHRIS: Well, I'm familiar with Todoist. I take a slight line between my to-do list, which I want to be as, I don't know, clean and tidy and only the things that I have to do versus for me, Instapaper is a list of when I get around to it when I've got those ten free minutes, which apparently don't exist in the world. But when I have them, this is the list of things that I can read. But I think I've heard this from a number of people of having a more integrated system that all the stuff's in the same place. I keep my to-dos in Trello, also as an aside, and I'm not super happy with that. How do you like Todoist? Is it bringing you joy?

+ +

STEPH: I really like Todoist. I find it is simple enough an interface that I'm not spending a lot of time customizing it or messing around with it. I can just go there and log the things that I want. I can create individual projects and spaces as well. So if I want to separate my personal to-do list from my work to-do list or if I have a project, that's a really nice feature as well. I think my only small complaint is if I'm writing a date or if I'm writing tomorrow, Todoist will try to do the smart thing and say, "Oh, I'm going to add a due date for you since you mentioned a date." And I'm like, no, no, no, I don't want a due date. I just want to mention the specific date because somehow it's relevant. And undoing that is sometimes a little tricky. But otherwise, I have found Todoist very helpful. I'm a big fan. Also, you and I are slightly different creatures in terms of how neat and tidy we keep our spaces. I think how we both manage our email inbox is a really good indicator of this where you are more organized than I am when it comes to emails. And so, our to-do list might be similar. I'd be interested to see if Todoist fits your needs or if it doesn't offer enough structure.

+ +

CHRIS: I almost certainly could make it work. And it's one of those things where I've actually settled on Trello, which is a very loose tool. And so I've been able to shape it sort of to what I want, but it doesn't really have that many true productivity-type features. It's just a loose board where I can drag around cards and move them through. And that's worked fine, or I've been able to talk myself into not trying to be as neat and tidy and intentional with my to-do list, which I think has been good overall. I've looked at Todoist in the past. And the thing that gives me pause sort of related to what you were talking about with the date things, but I get the idea, or I get the sense that Todoist really, from a fundamental philosophical approach, really wants things to have dates and to have priorities, and my thinking is not quite that. Like, there is a priority, but it's relative. So it's the order of things in a list, but it's not this is a one, and this is a two, and that's another two. I find that logic of like there are different tiers of importance doesn't really map to my world, nor do dates. Almost everything I do has no date, has no context. It's just like when I'm at the computer because that's the only place I ever am. So it's when I'm at the computer, it's all kind of important-ish. Nothing really has a date, but it should probably be done pretty soon. That sort of stuff doesn't quite map to what I see in Todoist. So I've always found a little bit of a mismatch between what I think I want and what Todoist, as far as I understand, provides. I know they added Kanban-type boards recently. So I think that might help with just visualizing workflow and being a little closer to Trello, which I'm familiar with. But I'm sort of on the search right now for another to-do list.

+ +

I like what you said about being able to separate the work and personal because that's definitely a thing that I would want, although there's always the added complexity of whatever tracking tool that we're using as a team at work and which things go into my list versus that list. And do I try and synchronize them in any way? And then I do what I do, which is I start to imagine this ridiculously complex, fully integrated, bi-directional sinking nonsense system where like, never mind. Stop it. Pen and paper, Trello. I don't know; you’ve lost your privileges, though. This is me talking to myself. I lose my privileges much like I'm not allowed to ever try Emacs. I have had a multi-year moratorium on exploring new productivity tools, but I think maybe, just maybe, now is the time to revisit that.

+ +

STEPH: If you ever disappear for a week or two, I'll know that you tried Emacs or something like that happened

+ +

CHRIS: [chuckles] My beard is three times longer when I come back, and I'm like, "All right. I figured some stuff out, though."

+ +

STEPH: I'm with you in regards to trying to bucket all of your to-do items as if it's a priority one, two, three. I am not good at that, and I'm always wrong. So I've also given up on that system. I would describe myself as a minimalist user. I'm using all the basic functionality. I'm not leveraging what a lot of stuff that Todoist probably can do for me. And so I have a very just flat list of things that I'd like to do. I do have a couple of projects because I do try to have that personal versus work, and maybe I have some other project that's on there as well. And then, in my mind, I try to avoid due dates unless it's really important. Although I say that if it's really important, it's going on my calendar too because I'm going to budget time for it or make sure that I don't forget it. But then each day then I go through that full list, and then I pick the things that need to be done that day or it's reasonable to get done that day, and then I kick everything to the next day. So that way, I'm always reevaluating a fresh list of what do I need to tackle? What's reasonable for today, and what can I punt on? And Josh Clayton said this to me before, and I really liked it in terms of punting on work because typically, when you're really busy, something's always going to drop. You're always going to push something to the next day. So then it's just figuring out what's going to bounce and what's going to break? So I'm always looking for what's going to break? And let's prioritize that for today to make sure it gets done. If it will bounce, then I'm going to kick it to the next day, and I can't see it until I'm going back through that full list again.

+ +

CHRIS: I really like that framing around you're going to have to drop things. That's just the nature of life. There's always more to do than there is time. So will it bounce, or will it break in that? And that framing around how to decide which things get moved out. Interestingly, I just looked up because I wanted to know does Todoist support snoozing things? Which is something that I use constantly in Trello and Gmail and basically everywhere else. I'm just like, nope, future me problem, future me problem, and I just keep pushing things into the future. But critically, I want them to be hidden until that time. And it sounds like Todoist; you can set a future due date, and then it'll show up in today. But again, that's sort of conflating how I think about productivity and whatnot.

+ +

Also, I found…this is a Reddit post that I'm looking at where I'm determining this. And there is the question, and then there's someone answered, but the answer is deleted. And then there's someone replying to that saying, "Wow, what a thoughtful response. Have you written this up anywhere else, like a blog post? You sound like an absolute pro." But the parent comment, which apparently was beautiful, and articulate, and well-written, has been deleted. And this is the sadness of the internet. So a really beautiful xkcd about the saddest thing you can see is you search for a question, and you find Stack Overflow from 10 years ago one person asking the question and no answers. And you've got one other person out there in the world who cares the same way you do, but you have no answers, and it's sad. But I'm just sad about the loss of information.

+ +

STEPH: That's so tragic, or that's a really pro troll move. And you leave a comment, and then below, you're like, “Wow, that was amazing. That was beautiful.” And then you delete your own previous comment. So then you're just tricking people into thinking there was an answer.

+ +

CHRIS: It does sound almost performative, especially the last line, "You sound like an absolute pro." So I could see that being the case. And you know what? I'm going to choose to believe that that's what it is because then I can sleep better at night. So thank you, Steph.

+ +

STEPH: Happy to help.

+ +

CHRIS: But I think we should probably move on to perhaps a listener question or something. But before we do that, I do want to ask if anyone out there has a to-do list that they're using and they love; I would love to hear about it. I think I'm familiar with most of them, but votes of confidence from the listeners of this show will certainly go a long way with me. Because I think you folks are all very smart people. I mean, you're listening here, so, obviously.

+ +

STEPH: Yes, obviously. This very deeply intellectual show about mozzarella sticks and the ratio of cheese to fried and what's the best.

+ +

CHRIS: It's an important question.

+ +

STEPH: It is an important question. I have strong feelings about it. That's why we've talked about it. [chuckles]

+ +

CHRIS: On this very serious show that we host.

+ +

STEPH: [chuckles] Yes, we have an awesome listener question that I'm really excited to dive into. But before we do, I have a quick git thing that I'd love to share. It's a tip that Dimitry, another thoughtboter, shared with me today that I think is just really nice and something that I have not used before. And it's specific to a workflow where if you need to grab a file from another branch or from another commit, and then if you want to bring it into your current branch. And there are a couple of ways to go about it. One of them is you can do git checkout main and then pass the file presuming the file that you want is in main and then you want to bring it to your current branch. And that will copy over the file to that exact location.

+ +

But if you wanted to grab a file that's on the main branch but then you want to port that file to a new location, then you can use git-show and do git show branch. So let's say you're bringing a file from main over to your current branch, so it would be git show main: and then pass to the file that you wish to copy, and then the greater than sign and the path to where you want that file to live. So you can grab that file and then stash it in a new location, and you can also do it for commits too. So if someone has pushed up a commit and you want to copy a particular file, say if you need to bring in some of their work into your branch, then you could also do git show commit, and then that colon, and then the path to the file. And then, if you wanted to move it to a new location, you can use that greater than sign and then the path to where you would like that file to live. So it's a nice combination of the git command of git show and then also shell redirection. So then, you can pipe that content from the file that you wish to copy over to the new location that you would like. And it's not something that I've reached for very often, but I find lately I've been in a mode where I'm trying harder and harder to stay within my terminal and not have to jump over to GitHub or to external UIs if I can. And so this just feels like a nice additional tool where then I can use this one more thing where I don't have to either...I guess it's small. I could check out main locally. But even with this way, I don't have to switch branches, grab something, and bring it over, or I don't have to go to GitHub and then look for something. It feels like a nice way that then I could grab that file locally and bring it over to my branch.

+ +

CHRIS: That's a nice combination of tips there. Like you said, a bunch of different pieces at play, but that is definitely a super useful thing. It's one of those that I've not gotten that into muscle memory yet or even close to muscle memory. Git is complicated in terms of the interface that it provides, at least at the command line. I've been trying to make sense of it all and then trying to find what are the useful workflows that I want to build? Because you can do anything, and you can do most things in five different ways. And so finding that set that you do want to know deeply but then also getting that committed into your hands, not even into your head, is the thing that I strive for. But that particular one is one that I struggle with every single time. So especially, I think you broke that down really nicely, so it makes sense.

+ +

There's a corollary in Fugitive for any Vim users out there. There's a Gread command, so it's capital G-re-a-d. And then after that, it takes some identifier, and I've never gotten the identifier right. But as you just described it, it's the same as the git show sequence. So it's a commit or a branch name, colon, and then the file path that you want. And then, in Vim, you can use % to reference the current file. So I've tried really hard to teach my brain Gread main :%, and somehow, my brain doesn't want to remember that ridiculous sequence of characters. So, only in this moment am I like, oh, it all kind of fits together.

+ +

STEPH: Oh, that's nice. I am a Vim Fugitive user, but I didn't know that one. And I'm with you; I rarely remember all these off the top of my head unless I've done them like a hundred times, and it finally starts to sink in. So I always have a cheat sheet, or since we were talking about tooling earlier, I use Notion to capture tidbits for myself. So this is a place where I would probably stash in a web development folder that I have. And it's just a tip to my future self as to like, hey, remember when you were trying to do that thing, and then you had to look it up and figure it out? Well, here's how you did it, so then I can revisit it in the future.

+ +

CHRIS: I thought a number of times about introducing a flashcard system to revisit these sorts of things. Gary Bernhardt, who I had on a while back now, is building a platform that does this essentially for TypeScript and regular expressions in JavaScript arrays and a bunch of different topics. But it's got built into it the idea of spaced repetition, so you review a thing and then three days later, you review it again and then seven days later, and then ten. And there's a particular sequence to it, but it helps you to really internalize that knowledge. I've never gotten to the level of going to that, but I like that idea of being purposeful and trying to commit some things to memory because having them at your hands and being able to stay, like you said, in the terminal and closer to the work and not having to break out of the context, I do find a lot of value in that. But it does take some effort to build that up. So I've never quite gotten to that flashcard system myself.

+ +

STEPH: Yeah, that's interesting. I think I have mixed feelings about it because, on one hand, it is nice to commit some things to memory. And on the other hand, I'm totally cool with having a way to organize stuff so I can easily search it and find it later and not use up memory space for something that I don't use that often that then I just can't commit it. So I could definitely see it being useful. But I'm also okay with just having a nice way to search for it.

+ +

But pivoting a bit and circling back to the listener question that you alluded to earlier, we have a listener question from Jen and Jen wrote in about knowledge silos across different projects. Specifically, Jen wrote in "Hello, Steph and Chris, first of all, I want to say that I love to listen to your podcast for multiple years now." That's awesome. Thank you, Jen. "I like how you both share things along your week and fill the discussion with so many useful things and findings. Our team, which consists of three pairs, is currently working on two different projects. And due to that fact, we are creating information silos. Now we are looking into ways into how we can minimize those information silos. And do you have any ideas for how we can achieve this? Some additional context, switching pairs we're unsure about as this will be difficult for the new person to get up to speed. And currently, we are thinking about having a mob review session. But of course, with those, you only get a limited overview." All right. Well, thank you, Jen, for the question. I'm excited for knowledge silos because, I'll be honest, I am guilty of this one right now. I am a bit of a knowledge silo on my current project if we're telling our truths here on the show today.

+ +

CHRIS: Steph, I thought I knew you.

+ +

STEPH: You know, I'm full of surprises.

+ +

CHRIS: Aren't we all at various times? This really does feel like one of those core things that I associate with you, though. So it is interesting. But it's so easy to fall into this space. I think without purposeful, intentional effort, this is the natural way things will trend. It's so much easier for the person who understands a portion of a system or an entire system to take on the next piece of work for that system. And I think we can probably offer some specific advice. But to talk about it more generally, Jen, I think you've found yourself in the pretty common position of there isn't a great answer here. There's going to have to be an investment of some amount of effort; some potentially decreased productivity for a period of time in order to get out of the situation that you're in. But that's just the name of the game. So if we name it as that, and we say that, then the question becomes how much effort do we need to put towards that, and what are the different ways that we can do it?

+ +

So to go through the two that you listed, mob review sessions, I think can be a great way to give an introduction to a project, but I think they'll very quickly taper off in my experience. So I think it's a great way, especially if you're going to do any more formal things after that; a mob review or even a mob overview of the system is a great way to introduce new folks into it. But then from there, I personally would think that if you are feeling pain around the knowledge silos or even if you're not, because frankly, knowledge silos can very quickly become a major problem, say if someone needs to...if someone happens to leave the company or if someone needs to take some time off, anything of that nature, this is one of those things that can be fine until it's not, and then it's not in a very serious way, and that's the wrong time to try and resolve it. So I would very much be in favor of more purposeful things.

+ +

As you described, switching pairs is an interesting one. I think that's a cost you're probably going to have to pay. I am interested; the way you're talking about it, it sounds like your teams are paired up consistently, so you're working exclusively in those pairs, which frankly is a really interesting thing. I think it was the previous episode where Steph and I talked about agile and particularly 100% pairing, and that's a pretty intense idea. It also does potentially lean towards this. Now, each of those groups of people, each of those pairs is collectively aware of the same subset of the application. But now, if you were to split that up and you have six individuals that pair in varying sets across the different projects, you have this sort of Venn diagram tapestry of knowledge of the different systems and the subsets and the features. And for that reason, I actually would probably question, at least if I'm correctly interpreting it, that you have three consistent pairs; maybe you shuffle that up. Maybe that's a practice that should be unwound. And now the pair should rotate on a daily basis or something to that effect. But overall, I think this is a cost you're going to have to pay but will pay off longer term. And it's definitely worth doing in my mind. But yeah, that's some high-level thoughts. What do you think, Steph?

+ +

STEPH: I agree with all of those sentiments very much. And as you're talking about the cost and investing in the team, I think that's very true and something that needs to be done. The fact that they're working in pairs is already reducing knowledge silos because you at least have another person. Because I have been part of teams where there's one person that is that knowledge silo. So at least here, we already have two people that are aware of how code works and then why code was implemented in a certain way. So then, to categorize how painful that knowledge silo is or how risky that knowledge silo is, I think there are really two ends of the spectrum. And on one side, there's that example that you alluded to a little bit ago about isolating one developer on a project for six months, and they have minimal code reviews. And then suddenly that person leaves, and that's the hardest silo to then rectify. And it will probably be a lesson that stings enough that hopefully it won't be repeated where someone gets that isolated and then others have to figure out what was going on while that person was working on something independently.

+ +

And then on the other side of that spectrum is you need to take some time to explore and understand a portion of the application that you haven't worked on before, or perhaps it's you need to understand how to work with an internal API. And stuff on that side of the spectrum feels more addressable with documentation and also mob reviews. And maybe there are also demos as well because a lot of the knowledge that goes into building a product may not be specific to the code, but it's more why was this done, and why was it built, and why did we go this way? And that feels more addressable with documentation, with commit messages, with those mob review sessions, and also with demos where then you can show the high-level functionality of a feature that's being implemented. So then, even if everyone else on the team doesn't have the technical knowledge as to how it was built, they'll have more of the user context, and the product context as this is a feature that we built, and this is why it's useful to the world. I find a lot of that knowledge is what's harder to capture because then you'll find a feature and wonder who uses this and how is it in use? And that stuff is harder to backtrack.

+ +

Circling back to something that Jen caught out in their question, highlighting that it takes time for someone to get up to speed. That's a really interesting one for me because it goes back to the idea of wanting to know well; what’s difficult? Not specifically what is difficult, but let's define difficult and what's a reasonable level of difficultness because onboarding to any applications or onto a new section of code is always going to take some time to process and understand. But what's an acceptable timeline in which someone can onboard and be productive? There's something that I've heard from someone at thoughtbot. I don't have the exact context to quote them directly. If I find it, then I'll be sure to add it to the show notes. And they shared that another company is measuring this difficulty of onboarding by they take the person's first starting date, and then they track to see when that person has merged in 10 PRs because they are looking to see how long it took for that person to get up and running to then feel comfortable, to then make some contributions.

+ +

Often, your first couple of PRs might be something that's less challenging. It might be something that's updating the README because you are going through that onboarding process. And that's a great time to then reevaluate how clear the instructions are. But by the time you get to the 10th PR, you've probably addressed something that's a bit meatier and impactful to the product. And then they use that as a metric to then calculate okay; how well are we doing? Is it a month? Is it six months until someone gets there? How complicated is the application is another way that you could look at that metric to say, "Well, if it takes people a very long time to get there, maybe it's because of the codebase versus processes." And I really like that thinking of we have knowledge silos; let’s think about where it's actually hurting us. And then, if we think it's specific to the onboarding process where that part is painful, then let's break down how we can measure how difficult it is, and then look for ways to improve it but then also track that improvement.

+ +

CHRIS: Well, I like that idea of trying to quantify and measure onboarding. I've heard a lot of organizations having like, "We want you to ship a PR on your first day," that's a meaningful thing. But obviously, that first one will probably be pretty small, and it's sort of getting that first one out of the way, if anything. But it's not truly representative of someone being able to comfortably work within the repo, but ten, that starts to feel like a real number. And I do like quantifying it. More generally, I'm intrigued. Metrics around developer productivity is such a difficult thing to pin down. And it can, I think, become really complicated, especially if you're looking at individuals and trying to say, "Well, you had four PRs, but you had two PRs," and comparing individuals. But I do really like the idea of more aggregate stats of on average; right now last month, we were doing 1.2 PRs per week per developer, and now we're down 2.7 PRs per week per developer, something like that, and seeing that looks like something that we might want to address. Are there fundamental things that are happening that are causing development to slow down? Are we doing bigger PRs, et cetera? And starting to look at that, but try and have a metric to keep an eye on that. So I'm super intrigued by that and then again, more specifically to the onboarding one that you were talking about there.

+ +

Actually, popping up a slightly higher level, though, I think both you and I sort of jumped into this conversation as, like, yes, knowledge silos got to fix those, that's a problem. And I do feel that way. This is a topic that I feel pretty strongly about and pretty clearly about that knowledge silos are the natural state that things fall to, and it's not a good thing, and we want to avoid it. But it is important to ask the question of who is deeming this to be a problem and for what reasons? And we had a good conversation two episodes back in response to a different listener question about consulting versus building product. And I feel like, with this, we can almost go up to the consulting level of this can be a problem, but it also maybe isn't. Or, who believes it's a problem? Is it management thinking, "Oh no, when that person went on vacation, suddenly everything ground to a halt? This is a problem, and we need to resolve that." Or is it the development team themselves saying, "Hey, we feel like we're a bit siloed here, and that's a problem we're recognizing," but they don't have buy-in from management. Or worst case management saying, "This is a problem, but you get no time to resolve it." As long as everyone's in agreement of the potential benefits and aligned to this is a thing that we would want to improve, and then also aligned to there will be a cost to resolving it, that it's not free to try and unwind this siloing of knowledge, then I think everything can be great. But any mismatch at sort of any level of that either on the cost or the benefit side can be problematic. And so getting to the point where you've had a clear conversation that defines this and gets everyone to come to an idea of yes, we think it's a problem, and yes, we want to put in the effort to resolve it, then I think you can move forward and tackle any number of different approaches. But I think you have to start from that conversation.

+ +

STEPH: I love asking that question of how has this manifested into a problem or a concern? Because you just highlighted a really great example where if it's only a concern because someone was on vacation and the team couldn't respond to a customer request or couldn't respond to an outage, then there are different ways to address that. So documentation may not be the best way to help out with that. That's probably a pairing session. So then someone can respond quickly to an outage versus you don't want to say, "Okay, here's a couple of pages of documentation," and then have that developer go on vacation again, and then there's an outage, and you're trying to read through those pages to figure out what's wrong. So figuring out the right approach based on the pain that's being felt feels like a really great way to go about this. Because frankly, breaking down a knowledge silo is always going to have a cost. So you want to make sure that you're being as cost-efficient as possible with your approach and then addressing the root concerns and making everybody's lives better.

+ +

Because I do think there's some knowledge silo that's appropriate. And I think silo may be the wrong word, but someone who is more skilled or an expert in the area or has more context for a particular area of the application. Because applications can get so large that not everyone's going to know everything and context switching between all of those can be really challenging. So I think it's very natural that you're going to have different people that you go to around a certain feature. If there is some lofty feature around search and you know a particular person that has worked on it for a while, then you go to them, and that feels like an appropriate level of knowledge that someone has obtained. And I wouldn't classify that as a silo at that point. But then if you do get to the point where that person went on vacation and then search broke, then you can start to revisit okay, maybe this person does have too much context, and then we can offload some of that context to someone else.

+ +

CHRIS: There was a phrase I used earlier of like a patchwork quilt, but I think that's not quite the right image. There's an image in my mind of little islands of color that are fully separated; that’s bad. And then there's a version of more like a Venn diagram overlap where each of the colors sort of bleeds into the other ones, and I think that's good. But then the perfect overlap where it's just one big blob of brown because all the colors are the same, that's bad. And I think that's what you're highlighting is like, you don't want to go to that. You don't need the perfect overlap of everyone having a complete shared knowledge set. I'm trying to make word pictures over internet radio. So it's probably not going great, but it's something to that. Like, there is an optimization here, and I think the way to find that is by starting from what are the pain points? What are we feeling that is less than optimal? And then coming up with solutions that directly address those pain points, not generically try and target like knowledge silos bad. And retros are a perfect way to do that. So if you listen to our previous episode where we talk about the virtues of retros and other agile philosophies...This is great. I feel really good about being able to reference previous episodes. I think we've talked about good stuff in the previous episodes.

+ +

STEPH: You've been on fire with this episode. I think you've referenced at least two, three episodes at this point. [chuckles]

+ +

CHRIS: Yeah. Wow. Well, I mean, we're at 300 now, so we've got plenty to go back to.

+ +

[laughter]

+ +

STEPH: We've got plenty of content to reference. I think you and I do have an advantage here based on our experience where we have had to join a number of projects. And then we know our time with that project is very determined, and we want to make sure that we don't take any knowledge with us. So something that you and I have acquired as a skill is seeking knowledge when we first join a project and asking a lot of questions around how the application works and then understanding more about the intent of different features, and then knowing where to dive into a codebase to then make fruitful contributions. And I think there's a similar approach that can be taken when trying to break down a knowledge silo is a person who is that silo may be in a spot where they're having trouble communicating all that information and then dispersing it to others. So then us, as their teammates, can go to them and try to ask those types of questions to then help ourselves level up and then recognize areas that don't feel documented. And maybe it's adding documentation, maybe it's adding tests, or maybe it's doing a demo, maybe it's recording something about the feature and then sharing that with the team. But then you can be an advocate for that person who is in a silo position to then help them share that knowledge because they may be too far down that path where they don't recognize what they know, and other people don't. I don't know if that's directly related to being a knowledge silo but just an additional way to approach helping breaking down when you recognize that a silo does exist and looking for ways to then help that person communicate and distribute their knowledge.

+ +

CHRIS: Yeah, I think you're describing a distinction between a push versus a pull. It could be incumbent upon the person who has the knowledge to try and push it out to the team. But often, they're going to be perhaps a more senior person. They've got code review to do. They've got other meetings, and planning, and things, and they just may not have the time. But is there a way that other team members can proactively pull that information from them and help them find the moments that will clarify that? So, yeah, broadly, as a team, let's rally around the desilofication of the whole adventure.

+ +

STEPH: That's exactly what I was going for is that push versus pull mentality and how we can break down the silo from both sides. So thank you, Jen, for that wonderful question. I hope we gave you some helpful ideas and suggestions around addressing a silo and then also identifying the pains that you're feeling so that way you can find the most cost-effective approach. But on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeeee!

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success._

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+JefM7Kro + + ]]> + + Chris Toomey + Steph Viccari + + + 299: Is Agile Over? + https://bikeshed.thoughtbot.com/299 + 212fdd72-b241-4b93-8ba9-ef09bc8e947e + Tue, 06 Jul 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Let's talk about Agile! What is it, what do we like, we do we _not like_? + +In this episode, Steph and Chris discuss: + +* Broadly, are they fans? +* What makes this practice work well? +* What makes this practice work poorly? + +And also, hit specific topics and practices like Scrum, Kanban, and Extreme Programming. + 46:15 + no + + + Let's talk about Agile! What is it, what do we like, we do we not like? +In this episode, Steph and Chris discuss: +Broadly, are they fans? +What makes this practice work well? +What makes this practice work poorly? +And also, hit specific topics and practices like Scrum, Kanban, and Extreme Programming. +Twitter Poll re: Gotime Podcast - Is Agile's Time Over? (https://twitter.com/gotimefm/status/1388126124299878412?s=21) +The Mortifying Ordeal of Pairing All Day (https://www.simplermachines.com/the-mortifying-ordeal-of-pairing-all-day/) +The Real Story Behind Story Points (https://thoughtbot.com/blog/the-real-story-behind-story-points) +Agile Manifesto (https://agilemanifesto.org/) & Agile Manifesto -- Principles (https://agilemanifesto.org/principles.html) +Extreme Programming Introduction (http://www.extremeprogramming.org/index.html) +Extreme Programming Explained (https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/) +Ron Jeffries - What is Extreme Programming (https://ronjeffries.com/xprog/what-is-extreme-programming/) +Transcript: +CHRIS: I feel like we should try a couple of different byes just so we have sort of a smorgasbord of options, and then we can pick the best one. +STEPH: With countdowns, [laughter] because I do so well with countdowns. +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, I thought we would try maybe something a little bit different this week, a little bit more of a structured topic. In particular, I've been gathering little tidbits of information. I've been seeing conversations happen all around the topic of Agile, things that people like about Agile, things that people hate, mostly it's things that people hate about Agile. Lots of ire on the internet about Agile, but I think also some disagreement about what it actually means. And I think; generally, you and I are probably fans, so I want to talk about that. What parts do we like? What parts do we not like? What do we think Agile actually means or, at its best, maybe what it means? But yeah, let's start at the very top stuff. Steph, what do you think about Agile? +STEPH: I am generally a fan. I'm with you. And yeah, the internet being full of more negative remarks and ire, that sounds very true. But generally, I am very much a fan of Agile, and the very broad scope of this is how we work, and this is how we plan our work, and this is how we collaborate as a team, and then how we reflect on the work that we have completed. I can also pick apart some of the things I don't like about Agile, but in the broad umbrella definition, I'm a big fan. I've enjoyed that approach. Granted, I've also only ever used Agile. I haven't written software using a Waterfall style, at least not purposefully. And then if I have encountered a team that was using more of a Waterfall style, then we changed it quickly. I really only have known the more Agile approach to writing software. +CHRIS: I think that's largely true of me as well, where most of my work would fit somewhere under the umbrella of lowercase "a" agile, although I've tried variants of Scrum and Kanban and a bunch of other things that we'll probably chat about today. But I think in general, I find that things are most effective; things seem to move the most smoothly. And I think the software that we come out with is the best one. It's closest to those very simple ideals of Agile. And every layer of process that gets added on even though, like you, I've not done true Waterfall where it's like six months requirements gathering and then it gets handed off, and no one talks for a while. I've never done that. +STEPH: I have to interject because I actually think you have in a previous life when you were an engineer. You have done the more Waterfall. Like, you have to plan very far in advance. +CHRIS: I think this is one of those cases where people think "engineering" quote, unquote like mechanical engineering is one thing and it's actually...there is a little more structure, and there's a little more necessity of sequencing where you've got to figure out what you need to buy first because sometimes it takes a while to find the particular piece of metal that you need in the world. But it also has a lot of figuring out as you go and being like, well, we've got a bunch of stuff, and we're just going to figure it out. And also, this is something that as I was studying software while working as a mechanical engineer, I started to hear about this whole Agile thing, and I was like, huh, I wonder how I can bring more of that? Because I definitely saw cases where a more Waterfall-centric approach to engineering projects was leading to bad outcomes. It's like we decided upfront what we're going to do, and then we went away for six months, and we did it. And then we came back, and it turned out it was wrong. So that was solvable along the way. There were ways to build prototypes and things like that. So that is definitely a part of the mechanical engineering world. +Although I think there are some true constraints, but I think there are also some occasionally self-imposed constraints, but again, I see sort of the same thing in software. Anytime that we can shorten feedback loops, that's what I like. And I think that for me, that's the core of Agile. Specifically, to come to the Agile Manifesto, to start at the very top, the thing that kicked it all off is a very simple document that the first line of it is "We prioritize individuals and interactions over processes and tools." It's like, yeah, that seems like a great thing, having more regular conversations about the things that we're building rather than having those initial conversations. And everybody goes away for a while and tries to build that thing, and then they come back, and hopefully, the thing that they've produced actually solves the problem. But I think almost always there are some deviations like, oh, actually, it would have been better if it was like this or now that we're actually trying it in the field, it's fundamentally different. So in that way, I think there's actually a lot of commonality between mechanical engineering and software development. +STEPH: Okay, that makes sense. Yeah, I was thinking around the process of where you'd have to order stuff in advance versus for us; we can describe everything that we need as we need it unless we're having to procure some specific software or licensing. But otherwise, we don't have to wait on that shipment flow to then have our goods. And then, if we also mess something up, then we don't have to reorder more pieces. But I like how you started talking about that agile with lowercase "a" and then talking about the manifesto because I suspect most people are familiar with Agile, but it wouldn't hurt just to read off some of those top things about what Agile is so that way we're all on the same page together for this conversation. +So you already covered the first one that talks about individuals and interactions over processes and tools, and then the others are working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. And that's it; those are the aspects of Agile. And so then, circling back to what you were saying earlier where people are having more criticisms around Agile, it sounds that it's less about Agile, and it's often more about the implementation of these ideas and then how you're approaching them. Because, boy, do we have several ways to implement Agile. We have Scrum; we have Kanban; there’s Extreme Programming. Does that fall within the Agile umbrella? I think it does. +CHRIS: I believe so. And I think a lot of the things that people take issue with particularly come from Scrum and Extreme Programming. We're taken to their extremes. Yeah, it's right there in the name, so you should probably know that it's going to be a little out there. But taken to the extreme and especially where it becomes rigid and dogmatic, then it becomes a problem. But again, so we listed out now the four items that are the core of the manifesto. There is a separate part of the manifesto, which is the principles, which digs in a little bit deeper, but it's still very much in that same ethos. But I do want to highlight because there's a subtext to the Agile Manifesto that I really love, which is given there are things on the left and then things on the right when the Agile Manifesto was presented. And so it's like we like individuals and interactions, that's the thing on the left, over processes and tools. And so the subtext below it is that is while there is value in the items on the right, we value the items on the left more. And that's one of the things that I love about the Agile Manifesto is it's not this very rigid thing that says, "This is good, and that is bad," it is a statement of a preference of well, yeah, it's definitely good to have comprehensive documentation. That's a really nice thing to have, but it's incredibly difficult. And if we have to choose, we're going to choose working software. We're going to prioritize that well before we have comprehensive documentation. So I really love the juxtaposition, and the emphasis on it's not that one is good and one is bad of these two things that we're comparing but that we have a preference, and that we want to orient our work around the items on the left rather than the items on the right, which I think the items on the right are more traditional or were more traditional to the Waterfall approach. +STEPH: I like how you highlighted how those statements are presented to the reader. So then that way, as you mentioned, we still value what's on the right, but we favor more what's on the left. So one of the things that I saw recently was something that you shared with me in regards to where you're bringing up the idea of, like, hey, let's talk about Agile. And you shared with me a clip or a specific tweet that linked to a clip from the Go Time Podcast, which is a podcast that I hadn't listened to before. But I listened to that episode or at least part of it, and it's really delightful. I enjoyed listening to them very much. And they had Kris Brandow on the episode. And at the end of the episode...and they do something really fun where they ask the guests, "Do you have an unpopular opinion that you'd like to share?" And one thing that I like about their unpopular opinions is they often have polls afterwards, and they want to see was this truly an unpopular opinion? And if most people agree with you, then they actually consider it nope, he didn't win. I don't know if they use the word win if you didn't achieve the unpopular opinion. And in this instance, Kris shared the opinion that Agile is done and over with and that we should move on, which is a big thing to say. Everyone on the podcast reacted in a similar way that I would where it's like, well, how do we track things? And there are still things that we need to care about. But then also, there's a part of me that's just like, yes. I am not sure where Kris has heard it just yet when I heard that, but I'm already tuned in and very interested. +And one of the things that Kris said that also really resonated with me is he mentioned that "I've never worked on a team where Scrum specifically like sprint and story points functions well," and I absolutely agree. There are parts of Scrum, we can get to the specifics that I think are fine that I've certainly used in the past and that have worked. Story points resonate deeply. I very much agree that story points are something that I do not enjoy using, and I do not find that they really lead to building software. There's even a blog post that I published along with Matt Sumner, a former thoughtboter and guest on this show, where we talk specifically about story points and some of the concerns and issues that we have with using story points. +CHRIS: It was actually also the first episode where you came on as a guest to Bike Shed; that that was the topic that we dove into because it was so near and dear to our respective hearts. +STEPH: That's right. I forgot about that. So yeah, story points are certainly up there on my don't list. I feel like we're doing a fashion do and don't, but we're doing the Agile do and don't list. [laughs] +CHRIS: I kind of like that. Yeah, we should lean into that vibe. But yeah, continuing on with the poll there, it was interesting to see also, like you said, they tweeted out, and then there's the poll that comes after. And it was 64-ish percent of folks agreed that Agile's time is over and done with, and we need to move. Granted, it wasn't a huge sample size. It was like 85 people that took the poll but still, seeing both the statement and then also the general support from folks on the Twitter, it was interesting to see. So I do have the question of like, well, okay, if not, what else? And I share your sentiment of we should be able to ask questions and iterate. And nothing is so precious that it can't be replaced by something else that's better. So we always need to be trying to find the best ways to work. But again, I think there are still kernels of good stuff in the Agile. So I found this and I was like, oh, this is interesting. What's going on here? +STEPH: So I'd love to dive into some of the specifics around Agile to understand what are the bits and pieces that work for you and the bits and pieces that don't. So if we are taking our Agile approach and reviewing the things that do and don't work and changing that process, what are the things that you would keep, and what are the things that you would throw out? +CHRIS: Yeah, well, we can dig in, and we can bounce back and forth, I think, on this. But again, there are sort of a few different camps. So I collected together some of the lists of practices associated with some of the different approaches to Agile. So starting with Scrum, which I think perhaps is one of the most rigid, most structured, and perhaps most ire-deserving of the approaches to Agile, one of the first things is sprints or iterations, so the idea of starting...before you begin the work, you sit down, you define how much work you think you're going to take on. There's often an estimation process. Actually, we'll say that because that's maybe a separate idea, but even just broadly the idea of sprints and iterations, which often involve the idea of committing to a certain body of work. And that commitment is always handwavy and loose. No, no, no, we won't hold you to it, but then it's a constraint that's placed on the team. It's an expectation that's set, but it's wildly difficult to estimate software, as we all know. So sprints and iterations, personally, I am not a fan of. I really like a more continuous flow where we're constantly reprioritizing the work to be done. We're constantly measuring against what we built, what we think we need to get out there. How can we get something out in front of users as quickly as possible? But I've not found a ton of utility in the sprint or iteration workflow. But what do you think of that one? +STEPH: Yeah, I'm generally not a fan of sprints, and it has taken me a while to get there. And I feel like I can admit that openly because it is something that I feel like when I first started doing software development, sprints were life. It was how you planned everything. It was how you committed to work. It's how you measured your work. It's how you then looked back to see what you could and couldn't accomplish in two weeks’ time or maybe a week's time, depending on how long your sprint is. But over time, I have realized that I don't like the mentality of sprinting, and that may just be a nitpick on my part, but that is something that I don't enjoy because we write better software when we have breaks. And with the sprint methodology, there's really never that break unless you're going to plan that into your sprint. +And then there's the idea of the upfront commitment, as you'd mentioned, it's one of those, don't worry, we're not going to hold you to this, but can we all commit to this work? And it's one of those you just feel compelled to say, "Yes," to the person who's asking because then you feel like a jerk if you push back and you say, "Well, actually, I don't know if I can, so I'm going to commit to way less." And then that's the approach that I started taking of, well, I don't know. So I'm going to always commit to a little bit because I'd rather overachieve and then deliver more than come in under because I could work really hard, but I've over-committed and then still feel like I didn't reach my goals, and that's a rough feeling. So I found that I was already lowering my commitment there. So then, it felt more appropriate to be in line with that sort of continuous workflow instead of trying to commit to all these features or all these tickets that needed to get done. I think those are the two areas for sprint where it doesn't align with me and where it can work for teams. But I feel like there's always that underlining unhappiness that a lot of us just don't want to talk about because we don't know what else to do other than to keep sprinting. +CHRIS: Yeah, I think you said something about the specific, like nitpicking the word sprint, but I do think that's actually meaningful. It's The Bike Shed, after all; if we're not going to Bike Shed about some words, what are we doing here? But I do think that we're using that word...it's obviously the wrong word; this thing's a marathon. You can't have 26 2-week sprints back to back throughout a year. That's not going to work. That's not how humans work. But any amount that we let that thinking into our head, I think, is problematic. If I'm understanding correctly, it sounds like you've come to a place of comfort around committing to a smaller body of work and then ideally overdelivering. But in my experience, many developers, perhaps even most developers, don't feel comfortable. It's so difficult to say, "Yeah, I know that the login form should take a day. That's what I feel in my heart. But let's be honest, every other time we've done a form, it's taken a week. So I'm going to say a week." It's so hard to do that. And so I think continuously, we end up in a mode where we are failing to meet the collective commitment that we made, and that's demoralizing. That's going to constantly just be a drag on the team, even if they're fake, made-up deadlines that we're constantly setting, that we're constantly not hitting. Just doing that over and over, I think, is really detrimental to the morale of the team, to the cohesions, and the feelings of are we actually doing this work? So perhaps pedantic, but I definitely share all of that. +STEPH: I do want to highlight, as I mentioned earlier, I'm feeling more comfortable that I can under commit and then I can overdeliver, and that is hard. That is something that still in the moment, even today, is very hard for me to do. And it's like how you said, in my heart, I feel like this should take a day, and the heart lies. But on top of that, it's often it's also my ego that's driving me all the time. And with that, it feels like a competitive environment to me where someone's saying, "Hey, can you get this done?" And in the moment, that brings out my more competitive side where I want to say, "Yes, I can get all this done, and I can deliver all the things." When, in truth, that's often not how it's going to work out. +There is one thing I do like about sprints that I want to reflect on, or perhaps it's actually two. And one of them is that we are getting together every so often, and we're agreeing on the important work to be done. And I really like that planning process that is typically coupled with a sprint. So you get together, you review the work, you address any concerns or raise any concerns. And then you could say, "Yes, we all agree this feels like important work." And essentially, we're buying into the work that's getting done, and I really like that process. And then, as an extension of that, I really like how we often then pick themes. So as we are agreeing to the work, we're often grouping together work that makes sense where it's either the most cross-functional or collaborative. We're already going to be in that space together. We're aware of what everybody is working on. And those are the aspects that I really do like about sprint and some of the other styles, that more continuous workflow of where we're always pulling from a backlog. It feels more of a grab bag in terms of I don't really know what I'm going to get next. I don't know how this work has been reviewed or vetted. I haven't really gotten to talk to anybody, perhaps. I'm making some broad statements here. But I haven't really gotten to talk to anybody from the product side to understand this change. And I also don't really know what the rest of the team is working on, so I feel more disconnected from them. +CHRIS: Yeah, I definitely share that, the planning or the meeting where we discuss the work that's coming up and shape it a little bit; I love that. Although it's interesting within the context of Scrum, I think like truly to the letter Scrum; my understanding is there are very discrete meetings, and they each have a distinct purpose. And so there's the sprint planning meeting, there's a backlog grooming, there's a sprint review and the sprint retrospective. And each of those are these four distinct meetings that are happening once every two weeks or so or whatever your sprint cadence happens to be. And the splitting of those becomes interesting. And some of the practices in there, I think, are...I think you and I share not being interested in doing them or not finding them to be super valuable. But I think broadly having some version of hey, let's sit down and talk about the work before we have to do the work, definitely a fan of that. For me, it often can be let's collapse four of those meetings into one sort of thing and maybe have it more regularly or something to that effect. But actually, we'll touch on the rest of those. But if you're good with bouncing from sprint/iteration, I think we've covered that topic well. Let's move on to one that I think we can do pretty quickly because I'm pretty sure I know how we feel, but sprint planning/planning poker/estimation. How do you feel about this one, Steph? +STEPH: We grouped a couple of things in there. There's sprint planning, and then there's sprint poker, and those are different to me. +CHRIS: Yeah. So let's go specific to the planning poker as the most pointed version of it but also generally estimation and sizing of stories. +STEPH: Nope. Throw it out. I don't know how to play poker. Let's just get rid of it. [laughs] I was never a good poker player. +CHRIS: Playing poker can be fun, but planning poker...Well, so actually, to ask a slightly different question, I think in the past we've talked about keeping aspects of it, definitely not keeping the let's figure it out, let's hash it out. Let's get down to an exact point value, and then we know we can have 34 story points a week, and that's what we're going to do. But the version of using planning poker, using this numerical communication tool to see if we're aligned, that one I think we've talked about liking that. I have enjoyed that, but under the strict guidelines that we throw the numbers out. The numbers are only a communication tool. They get thrown out after the fact. We do not commit to a set amount of work or anything like that. We just use it to say, "I think it's an eight. I think it's a one. Oh, we should talk," just for that. That's when it's useful. +STEPH: I agree. Yeah, in my previous answer I was being flippant about it, but I do agree very much where I don't like the specificity of where you're trying to plan exactly what numbers are these. But I do find it very helpful for the reasons that you just said where the team agrees with the estimation around how long they expect something to take. Because then that is really great where you have someone who's never touched the codebase, and they're like, "I think it's a five or whatever system we're using here." It's an elephant...whatever scale you're using. And then someone else is like, "Well, I think it's a doughnut size." I'm making up silly stuff because it's more fun for me. And then those two people can talk and reconcile. So I do like discussing the estimation of work for that purpose but then not actually writing it down or maybe going with t-shirt sizes, something that's more simple, and then doesn't have anything with points, really. Anything with points can then be gamified and also brings out people's more competitive side. So, if you can make it something that's more fun, maybe around t-shirt sizes or a bunch of cute animals, various sizes, whatever works for your team. I'm trying to think of other fun measurements now [laughs] that we could use instead of t-shirt sizes. +CHRIS: There are the sizes of bottles of wine as you go past. So there's a regular bottle of wine, and then there's a magnum. And then it gets to weird names like a Nebuchadnezzar and other things. These are big performative champagne bottles. So I think we should use that kind of sizing because I think they also have a geometric progression type thing, not quite Fibonacci but something like that. So I'm going to make that push for Nebuchadnezzar as being my go-to [chuckles] sizing in story points. +STEPH: I have never heard of that, and I love it. That's great. +CHRIS: Okay. We'll find a relevant link to the wine bottle sizing, and we'll put that into the show notes. We will also, of course, include a link to your wonderful blog post. What's the story with story points that you wrote with Matt Sumner? Because I think that really does dial into this topic really well. And again, coming back to that core idea around Agile, while we see value in the item on the...which side is it? While we see potential value in story points, I have worked with countless teams who desperately wanted to make this thing work. So it would be great if we could quantify the work and then numerically understand the work that we had ahead of us and sequence things and talk about deadlines and whatnot. Man, that would be amazing. I would really love to do that. So with every other developer and every manager of a team of developers in the world, I have not seen it done. I am still looking for that day. When that day shows up, then I think this will be a wonderful practice. But unfortunately, my experience has been that this doesn't work, and trying to do it causes more harm than good. +STEPH: I agree that I certainly understand the reason that people want story points to work because it's very nice to then say, "We can calculate, and we can measure, and then we can have delivery dates." And that's really nice from a management perspective. But that does blend in nicely to the next topic, which I think fits nicely underneath the Agile umbrella, our daily syncs. Because that does bring us closer to that goal of where we can't give real valid updates on how something is going and provide a more real estimate as to when we think something is going to get delivered. That doesn't have the same effect of where we think we're able to plan and then promise delivery dates a week in advance because we're getting those updates in real-time, but they're going to be more reliable. And that is, we're so much more than where we try to over commit to work or if we try to say how much time something is going to take. And that is so much more valuable to have that reliable update and estimate versus trying to trick ourselves into thinking that we know when something is going to get delivered. +CHRIS: Yeah, I think the daily sync or sometimes called the daily Scrum, or standup, or otherwise morning meeting often in the morning, this is one that I see lots of folks really hate, and I'm personally a big fan of. This is one that I would definitely hold onto. But I think you have to be very, very purposeful with how you structure it. It really should be as short as possible. And there's one particular thing that I see very regularly in teams, which is almost a performative version of what I did yesterday. It's trying to demonstrate to the team that yes, I, in fact, did work yesterday. I was a valuable team member. Please don't let me go from the team. And I think that's the sort of thing that we should try and just get rid of. There are definitely times where what you did yesterday is relevant to the team, or you worked on something, and now you have a bunch of questions, and bringing that to the team is useful. But that version of everyone needs to prove that they did work yesterday or...it's the sort of thing like if anyone says that sort of thing, then everyone else is like if you don't say what you did yesterday, then it sounds like you did nothing because everyone else is saying what they did. +So you have to, I think, get a team buy-in to do this, say, "We're not going to talk about sort of bullet-list what we did yesterday. That's not going to get us anywhere as a team." But what's useful are those little magical moments of connection where I say, "Yep, I'm working on this. I'm going to implement it in this way." And someone's like, "Wait, wait, that way? Oh, we shouldn't implement it that way." And then ideally, what happens there is okay; let’s connect after this meeting. You've now made this connection, but you don't need to hold up the rest of the meeting for that. You can just say, "Cool, this connection has been made. That's an incredibly valuable little point in time, but now let's continue on with the flow of the meeting," so that it keeps that rapid pace. And so times where you're blocked, times where you have questions, times where you're just describing what you think you're going to be working on. So if anyone's like, "Oh wait, no, we needed to stop that work because we actually made a decision yesterday that impacts whether or not we actually wanted to build that feature at all." If you can head off incorrect work at the pass, there's so much potential value in that meeting that it is interruptive. And it does take up some time, but I find that it is so, so worth it if you're able to really keep it focused, keep it concise, and keep that end goal of those little connections. When those happen, they're so valuable. So I think it's really worth the input. +STEPH: I'm still smiling from where you said performative of what I did yesterday because that is something that took me a while to understand, one of the things that I did not like about the daily sync or daily meeting whenever your team gets together to talk about the work that's being done. And it was finally when I realized we're just going through a list of who has the longest list of the things that they accomplished yesterday. And again, it felt like it was bringing out more of that competitive mode in folks to talk about what they did, and it didn't feel very useful. Every now and then, maybe there was one thing that was interesting that someone did. But most of the time, it was always more helpful to hear what the person was working on that day for all the reasons that you just highlighted. +There is one practical concern that I have with these types of meetings or with these types of events. And it's where you'd mentioned where if we can keep it concise…and someone brings something up, and it starts to devolve into a conversation right there. So then whoever was up next is now waiting while that conversation is happening. And that part gets awkward because then there's usually one person who is then willing or no one frankly is willing to then say, "Hey, so sorry to interrupt, but let's actually table this discussion and let everybody else go, and then we'll come back to this." And if you have people on the team that have been there for a long time with that culture, then that will just work because everyone will keep each other in check. But otherwise, if you're starting that new process, or if you start to notice there's always that one person who's doing that awkward thing of trying to then set that culture of this is how we do our daily chat, and these are the things that then we wait for later, it's really hard. And I say that because I have often been that person that's in that space where then I encourage people to table a conversation. And it always just feels awkward to interrupt someone and ask them to please wait until everybody else has gone. +CHRIS: I share your hesitations around that, but it is very important. And it's that sort of ideally someone in a more senior position will model that behavior and model it in a positive, friendly way. Where I have done that often it's in the form of a question, so it's, "Actually, do you think maybe we could take this offline?" or something like that. Not a command, not taking over or shutting people down because it is somewhat interjective, and you're sort of correcting course. And so, being as friendly and empathetic in that moment as possible, but that's a hard note to strike. And again, if it's something that only one person is like the taskmaster, the Hermione Granger of the team who's trying to keep everyone focused and doing their homework sort of thing, nobody wants to be that. Well, Hermione did, but otherwise, nobody wants to be. +STEPH: I love all the Harry Potter-themed references that have been coming through in the last couple of episodes. And I agree it is something that's hard to help teams course-correct, but it's important, and it's very much something worth doing. I just recognized that I think that's why these roles get implemented, why there's this concept of a Scrum Master, and then why we designate these tasks to specific people because then you have someone who can do it. And then when they do interject, it feels more appropriate because that is their role, and that's one of the things that they're supposed to do versus putting it more on the social pressure of whoever is comfortable speaking up to then course-correct. So I do understand where that implementation of Agile has then tried to create those roles, which I've been on teams that have a Scrum Master. And my experience is it's often been a very positive experience because the person that is in that role is often very kind and caring about that team. And so they are a wonderful person to work with, but it's also one of those...I've also been on teams without them, and things have been fine. So I have mixed feelings about that one. It's one of those; it feels like an extra heavy process, but I've also been on teams, and it worked. +CHRIS: It's interesting the way you frame it, of the utility of that role. Like, having a role where we've now all bought into the idea that this person may take these actions say, "Hey, can we take that conversation offline?" and rather than one individual choosing to do that. I like that framing. I share what you're saying about the rest of the baggage that comes along with having this formal position, and often, that person is otherwise removed from the work. That can often be an aspect of Scrum. I think that gets complicated. But now I'm wondering can we make a software solution to do this? Because, of course, that's where my head goes. Can we have a standup bot that is listening and is like, "Hmm, it seems like you two people have been talking for the past two minutes. I'm just going to interject like my little bot self that I am and ask maybe take this conversation offline," in the way that we've sort of automated a lot of code formatting things, and that's been really wonderful, so that's not a part of PR review. Can we do the same for standup? I don't know. +STEPH: I think all the award ceremonies have these where they start to play the music, and that's your cue to move off stage. +CHRIS: Oh, I like it. +STEPH: I think that's it. [laughs] So you cue the music whenever someone has been going for quite some time. On a slightly separate note but still related to this, some conversations that have been bubbling up around me have been related specifically to this idea around stepping in to say, "Hey, I'll take on that thing that you need a volunteer for," or "Hey, I will help the team stay on track," will often fall on people with a specific personality and then they will often be the one that continues to do that. And so they will end up taking on additional work or taking on additional roles just because they may be in a more empathetic spot where they feel that's the kind, helpful thing to do. And so, we've been looking for more ways to make sure that those tasks are being distributed evenly across the team. So we're not just waiting on someone to say, "Who would volunteer for this?" And then typically being the same handful of people that are always speaking up and then volunteering for it. +And then trying to shift to more of a purposeful approach of having a queue of people and then cycling through that queue, and then if someone can't do it at a certain time, then we move on and then we just put them back in the queue. But this way, we don't have people that are typically just always taking on these responsibilities. And that's something that is a new consideration for me but one that I have found really helpful to be aware of and notice on your team who's the one that's always volunteering for these roles and checking in with them to see if they're comfortable with this, or if they're feeling compelled to volunteer for stuff because they may feel more inclined to speak up versus others are okay with staying quiet. But circling back to some of the Agile discussions earlier, you'd mentioned a handful of meetings and that you have some feelings about those meetings. What are those meetings that you have feelings about? +CHRIS: Yes, the meetings. So again, this is somewhat contextual to Scrum, but the structure of Scrum has a handful of meetings that sort of define the sprint. So you have some at the beginning, the middle, and the end. So there's sprint planning, there's backlog grooming, there's sprint review, which typically includes a demo for stakeholders, and then there's sprint retrospective. And these, as far as I understand it, are four distinct meetings and are intended to be kept distinct so that their purpose stays purified in each of those meetings. And I think my feelings would be that again; I don't really find a ton of value in the sprint structure or in the two-week cadence or things like that. And so I think it can make sense in those contexts to be like, we need to make sure we have space for these things. But in a more continuous context, I think the backlog grooming or, more generally, let's talk about the work that's coming up. Let's make sure that we're all unified in how we're thinking about that work, what we think matters, what's prioritized. I think that is an incredibly valuable meeting. I think sprint review and specifically demo for stakeholders I'm really intrigued by that one. I don't know that I feel like that needs to be a distinct meeting. And in fact, more and more these days, almost every feature I deliver has either screenshots or a screen recording of what that workflow looks like. So we're continuously demonstrating to the stakeholders what does this look like now that it's a real thing? What does an end-user see? What's that experience like? And in retrospect, I think we'll probably spend a minute on that one. I like retros; some people hate retros. Yeah, let's loop back to that. But of those, what are your thoughts? What do you like? What do you not like about those meetings? +STEPH: I think grooming is a very helpful meeting that can help a product manager and a technical team have discussions about the upcoming work. I don't necessarily think it needs to be the whole team. I think it can be a couple of engineers from the team; maybe those people rotate, maybe it's the team lead. And they get together with the product manager, and they essentially answer any technical questions about upcoming work. So then it can be refined. So then, as we get closer to that planning session, whatever we want to call it, then it feels more in a ready state for folks to react to and then have opinions on. So I do like grooming, but I wouldn't necessarily advocate that the whole team needs to be present for those. +For a demo, I'm with you; it really depends. I've worked on projects where the stakeholders are less close to GitHub and Slack and areas that we could demo some of the work that's being done, and maybe they weren't poking around on staging as much. So it was really helpful to then have a more formal demo to then show them the work that's being done. And then I've also worked on plenty of teams where a demo was something that we used as a fun internal event where we have all these different teams, and we get together. And then we get to show off all the great work that we have done across all the different products. So then us, as fellow teammates, can then celebrate what the other teams are working on. +Retros, you know I love retros. I think retros are a microcosm of your team's culture and process. And if your team is struggling to have a productive retro, your team is struggling. Because I think that is representative of your team's ability to get together, and reflect, share concerns, celebrate wins, agree on what's important, and run measured experiments. And if you're not having a retro, then I think you're not going to know how your team's doing until it's too late, and it's going to be harder to course-correct. +CHRIS: #HottakeswithSteph. I like it. I like the intensity that you came in with there, but I know retro is near and dear to your heart. So I'm unsurprised that that is the line that you've drawn. I definitely share all of those feelings, particularly around retro, because I think much like the daily sync, I've seen many people who are just like, "This is a bad meeting. It's useless. Nothing ever happens. I don't like it." And I'm often surprised by that because I've found so much value in it. Retro similarly is this magical meeting that can just regularly change the course of how we're working as a team. But I also have come into plenty of teams where it definitely did not have that shape, where it was basically a place that everyone sits down, and somewhat downtrodden restates their list of grievances, their airing of grievances, and then nothing changes. And much like the sprint iteration thing where you're constantly missing the commitments, and that's just going to wear a team down. I think if you constantly have retro and nothing changes and it's that same list of concerns, then that is going to be bad, but that, like you said, is not the reason not to do it. [chuckles] Oh, we just keep saying the same things in retro, so I don't think it's even that valuable. I would say that maybe we should change the things. But I've definitely been on plenty of teams where retro was just so valuable. And it's definitely one where I feel like having a facilitator, having someone who is in that particular seat trying to guide the conversation without necessarily being in the conversation, can be incredibly valuable. +There are also structures that I've seen work particularly well. We have a video on Upcase that we can link to. That's a format that I've found; it’s a very lightweight format, but it basically involves getting everyone's input on a positive note, on a more critical note, and then revisiting and sort of sorting and waiting, and then digging into topics that need a little bit more focus. But I think a lot of different formats can work as long as retro is a way for people to sincerely meet up, safely talk about the things that they are feeling about the work, and then ideally, some change comes about as a result of that. You mentioned having measured experiments, and I love that as a framing or like something that retro can do for us. +STEPH: I really do think that retros are so important because they're the health check of the team. As you'd mentioned, if people are having a very negative retro experience, which I understand, I've had very negative retro experiences as well, and I've walked away feeling like that was not a productive use of my time. But then that is our warning. That is our signal that's saying, "Something is not right, and something's not great, and we're not working together as we really want to be working together." And this retro is just that reminder that is right in our face, that is making this so uncomfortable and feel like a waste of our time because it is informing us that something needs to be improved upon. And we can feel like retros are not productive when we feel powerless to make that change. And that again is then another discussion to have with the team, to have with management, leadership, to talk about how do we get the power to then make the changes that we need to then have productive, happy retros? Because that's going to be a reflection that you have a happy, productive team. +CHRIS: Love it, love the framing, love the symmetry there between team happiness and retro happiness. So to summarize, I think we've gone through most of Scrum now. So just to...correct me if I'm wrong on any of these, but I believe sprints and iterations, nah, we'll leave it. Planning poker, definitely not. That doesn't seem good, although maybe just to bring up conversations, but not as an artifact that we save in any way. And then otherwise, daily sync, we're fans. Retro, definitely fans. Sprint review, backlog grooming, some version of those, a lightweight version of a bunch of the meetings seems may be good, but a couple of things definitely are going to leave on the cutting-room floor. Does that sound about right to you for Scrum specifically? We've got other topics to cover. +STEPH: Yep. All of that list sounds really good. +CHRIS: All right. So we've now found our refined version of Scrum, re-Scrum as we'll call it. But now there's a couple of other pieces...So Scrum is very focused on the ceremonies and the team activities, but there's another facet of the Agile umbrella, which is Extreme Programming, which that's a book. I believe Extreme Programming Explained is the name of the book. And there are various different links that we'll include to point at those. But there are two particular practices that stand out that I have heard some people love, some people do not. So we'll go into both of them. The first is pair programming. What do you think, Steph? Do you like pair programming? +STEPH: I do. I'm a huge fan. [laughs] Yes, I very much like pair programming, although it still has its limitations. I definitely want time on my own, and I can get exhausted from pair programming. It is a very vulnerable experience, too, where you have to share with someone: this is what I know, this is how I work, this is how I think. And I think that is incredibly challenging. I find that I am typically more productive when I'm pairing with someone or when I have the opportunity to pair with someone at least every couple of days. +CHRIS: Yep. I'm definitely a huge fan of pairing. Although I think specifically to Extreme Programming, I think the idea is 100% pairing. I think you already spoke to this, but pairing is exhausting. And the idea of 100% pairing is I can't really even imagine that; even 50% pairing feels like an incredibly high bar to hold for any extended period of time. There's a recent article that was going around the mortifying ordeal of pairing all day, which spoke of one person's experiences getting deeply burnt out just going through that process. And so, as valuable as pairing is, it's definitely a tool to be used not all the time. That feels like a lot. +STEPH: That's a lot of Stephanie singing because I tend to sing a lot whenever I'm stuck or thinking through things. So that's a lot of singing that I don't know if the world wants. +CHRIS: I mean, based on all of the various Bike Shed intros that involve you singing, I think the world wants it. That's maybe one person's take. But definitely, something that you said of there's a vulnerability to it. And so many pairing sessions I've either been the one saying this or someone else that I was pairing with has said this to me, but they're like, "I swear I know how to type, just now that someone's looking, my hands don't work." It's like you're in a dream, and your legs don't work. You're like, I know how to run, I swear. But for some reason, my legs are made of jelly right now. Or you can't remember a particular method, or there's just something that happens, and so getting over that hump, getting comfortable with it, I think it is a skill and something to become accustomed to. And so, again, being conscious of that when you start doing it is super important. +STEPH: I don't know if this is true because I only have access to people’s thoughts when I'm pairing with them, and then they're sharing their thoughts with me. But I do feel like people tend to beat themselves up more when they have someone watching because then you feel the need to say, "Oh, I normally can type, but because someone's watching..." which is so true; that definitely happens. But those moments are some of those really great moments to then reflect on the fact that just because someone's watching us doesn't mean that then we suddenly need to beat ourselves up. And I don't know how philosophical that I want to get with this, but I feel like there are so many opportunities while pair programming to then encourage other people around us to be kind to themselves. That is one of the things that I have really benefited from pair programming is learning to be more kind to myself. And even if I don't know exactly what's happening or what I'm doing and I may not be as confident with someone else, I can still be positive and kind. Just because you're in a vulnerable space doesn't mean that you then need to be unkind to yourself. +CHRIS: Yeah. I definitely agree with the idea of being kind to yourself also, where you can, be kind to someone else who you're pairing with, especially if they're finding that they're like, "Ah, suddenly my hands don't quite work." But I have pretty uniformly seen that a pairing session may start out that way. And then as everybody kind of just relaxes into it, suddenly you'll see someone just kind of flying around their editor. And you're like, wait, what just happened there? That was so fast. I don't even know. And so there's just this comfort level that sometimes it takes a little bit of time to ease into. But yeah, so pair programming, broadly yes. 100%, oh, that's going to be a no, no, thank you, not that. All right, so one other practice that comes from Extreme Programming, which is Test-Driven Development AKA TDD. What do you think about that one, Steph? +STEPH: I feel like you're giving me lay-up questions here. For anyone that's familiar with us, [laughs] I feel like this is an easy one. Test-Driven Development is a thing. It's a thing that I enjoy. I don't always write tests first, though, so I don't always follow TDD, but I am definitely a fan of tests. So, I guess in that light, it’s not so much that I adhere always to TDD. I don't feel the need that I have to write tests first, but I have found that with practice, that often helps me write code where I have tests then help me write out the logic for my code. So generally, yes, thumbs up on TDD, but I'm also not terribly strict about it where if you want to write some code first, write some code first. +CHRIS: Yeah, I think I'm definitely in the mode where I like testing. I like Test-Driven Development. I can't always pull it off, frankly. It's hard. It is hard to know how to write a test in advance of the implementation that you're going to write such that the test will correctly constrain the system that you're about to write. That takes a couple of levels of knowledge that if I'm writing a Rail’s controller action form sequence, I can probably TDD that because I've done it so many times. But if I'm doing something that's a little bit more new, novel, less familiar to me, then likely I won't be able to pull it off. TDD is like a fancy move that I don't always have available to me. But I consider that whenever I'm in that mode like that's not oh, it's fine to just write the thing before the test. Like, I want to be able to do TDD 100% of the time. I'm just not a good enough developer, frankly. And I don't know that I ever will be because I always want to be working a little bit past the edge of my comfort. So it's a delicate line of when I will not use TDD, but wherever I can, wherever I do have that level of knowledge of the system and the frameworks and whatnot built up, I find it is a vastly more effective way to work. It's not that I feel cool when I do it. It's like I feel much more effective. It helps me stay focused and on task and get the thing done. So it's very utilitarian in that way but also not something I can always pull off. +STEPH: So, circling back to when we first started chatting, you were asking about Agile and then my thoughts about it. And having this conversation with you, I'm realizing, or I think I was already aware, but it's helping me re-solidify I'm very much a fan of Agile. There are specific implementations of Agile that I don't find enjoyable, and I don't find helpful to writing software, and I don't find helpful from the project management side either. But broadly speaking, I'm still very much a fan of the approach that we use generally for Agile, where we want to work in small deliverable increments, and then we also want to have the ability to change any moment what is the most important thing to work on? To me, that is the heart of following the Agile process. And I don't think that's going anywhere. Like, I don't think Agile's going to disappear. But I wouldn't be surprised if we see another implementation of an Agile variety of the things that you and I just shared and the things that we like. And so, I feel like most teams that I work with follow Agile within their own unique bespoke version. And we don't have to give it names because everybody's going to have their own custom version where they decide which process works for them and which one doesn't work for them. And that's what retros are for so then you can figure out which process works for you. +CHRIS: Once more, Steph on the record about her love of retro. I think the core of Agile, the Manifesto, those core ideas about small iterations, delivering value, staying close to stakeholders, all of that feels deeply true to me. And I would be really surprised if a year from now or two years from now I was doing something that was wildly different from that. But then each of the layers of practices on top of that to varying degrees I like or don't like. And I wouldn't be surprised if aspects of that were swapped out down the road. But that core, that idea of this is how we think about building software. I like that thing; that seems like a good thing. So I'm going to hold on to Agile for a little bit longer personally. +STEPH: Same. I still see Agile in my future. On that note, shall we wrap up? +CHRIS: Let's wrap up. +STEPH: Show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. +STEPH: And I’m @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeeeeee. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Let's talk about Agile! What is it, what do we like, we do we not like?

+ +

In this episode, Steph and Chris discuss:

+ +
    +
  • Broadly, are they fans?
    • +
  • What makes this practice work well?
    • +
  • What makes this practice work poorly?
    • +
+ +

And also, hit specific topics and practices like Scrum, Kanban, and Extreme Programming.

+ + + +

Transcript:

+ +

CHRIS: I feel like we should try a couple of different byes just so we have sort of a smorgasbord of options, and then we can pick the best one.

+ +

STEPH: With countdowns, [laughter] because I do so well with countdowns.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, I thought we would try maybe something a little bit different this week, a little bit more of a structured topic. In particular, I've been gathering little tidbits of information. I've been seeing conversations happen all around the topic of Agile, things that people like about Agile, things that people hate, mostly it's things that people hate about Agile. Lots of ire on the internet about Agile, but I think also some disagreement about what it actually means. And I think; generally, you and I are probably fans, so I want to talk about that. What parts do we like? What parts do we not like? What do we think Agile actually means or, at its best, maybe what it means? But yeah, let's start at the very top stuff. Steph, what do you think about Agile?

+ +

STEPH: I am generally a fan. I'm with you. And yeah, the internet being full of more negative remarks and ire, that sounds very true. But generally, I am very much a fan of Agile, and the very broad scope of this is how we work, and this is how we plan our work, and this is how we collaborate as a team, and then how we reflect on the work that we have completed. I can also pick apart some of the things I don't like about Agile, but in the broad umbrella definition, I'm a big fan. I've enjoyed that approach. Granted, I've also only ever used Agile. I haven't written software using a Waterfall style, at least not purposefully. And then if I have encountered a team that was using more of a Waterfall style, then we changed it quickly. I really only have known the more Agile approach to writing software.

+ +

CHRIS: I think that's largely true of me as well, where most of my work would fit somewhere under the umbrella of lowercase "a" agile, although I've tried variants of Scrum and Kanban and a bunch of other things that we'll probably chat about today. But I think in general, I find that things are most effective; things seem to move the most smoothly. And I think the software that we come out with is the best one. It's closest to those very simple ideals of Agile. And every layer of process that gets added on even though, like you, I've not done true Waterfall where it's like six months requirements gathering and then it gets handed off, and no one talks for a while. I've never done that.

+ +

STEPH: I have to interject because I actually think you have in a previous life when you were an engineer. You have done the more Waterfall. Like, you have to plan very far in advance.

+ +

CHRIS: I think this is one of those cases where people think "engineering" quote, unquote like mechanical engineering is one thing and it's actually...there is a little more structure, and there's a little more necessity of sequencing where you've got to figure out what you need to buy first because sometimes it takes a while to find the particular piece of metal that you need in the world. But it also has a lot of figuring out as you go and being like, well, we've got a bunch of stuff, and we're just going to figure it out. And also, this is something that as I was studying software while working as a mechanical engineer, I started to hear about this whole Agile thing, and I was like, huh, I wonder how I can bring more of that? Because I definitely saw cases where a more Waterfall-centric approach to engineering projects was leading to bad outcomes. It's like we decided upfront what we're going to do, and then we went away for six months, and we did it. And then we came back, and it turned out it was wrong. So that was solvable along the way. There were ways to build prototypes and things like that. So that is definitely a part of the mechanical engineering world.

+ +

Although I think there are some true constraints, but I think there are also some occasionally self-imposed constraints, but again, I see sort of the same thing in software. Anytime that we can shorten feedback loops, that's what I like. And I think that for me, that's the core of Agile. Specifically, to come to the Agile Manifesto, to start at the very top, the thing that kicked it all off is a very simple document that the first line of it is "We prioritize individuals and interactions over processes and tools." It's like, yeah, that seems like a great thing, having more regular conversations about the things that we're building rather than having those initial conversations. And everybody goes away for a while and tries to build that thing, and then they come back, and hopefully, the thing that they've produced actually solves the problem. But I think almost always there are some deviations like, oh, actually, it would have been better if it was like this or now that we're actually trying it in the field, it's fundamentally different. So in that way, I think there's actually a lot of commonality between mechanical engineering and software development.

+ +

STEPH: Okay, that makes sense. Yeah, I was thinking around the process of where you'd have to order stuff in advance versus for us; we can describe everything that we need as we need it unless we're having to procure some specific software or licensing. But otherwise, we don't have to wait on that shipment flow to then have our goods. And then, if we also mess something up, then we don't have to reorder more pieces. But I like how you started talking about that agile with lowercase "a" and then talking about the manifesto because I suspect most people are familiar with Agile, but it wouldn't hurt just to read off some of those top things about what Agile is so that way we're all on the same page together for this conversation.

+ +

So you already covered the first one that talks about individuals and interactions over processes and tools, and then the others are working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. And that's it; those are the aspects of Agile. And so then, circling back to what you were saying earlier where people are having more criticisms around Agile, it sounds that it's less about Agile, and it's often more about the implementation of these ideas and then how you're approaching them. Because, boy, do we have several ways to implement Agile. We have Scrum; we have Kanban; there’s Extreme Programming. Does that fall within the Agile umbrella? I think it does.

+ +

CHRIS: I believe so. And I think a lot of the things that people take issue with particularly come from Scrum and Extreme Programming. We're taken to their extremes. Yeah, it's right there in the name, so you should probably know that it's going to be a little out there. But taken to the extreme and especially where it becomes rigid and dogmatic, then it becomes a problem. But again, so we listed out now the four items that are the core of the manifesto. There is a separate part of the manifesto, which is the principles, which digs in a little bit deeper, but it's still very much in that same ethos. But I do want to highlight because there's a subtext to the Agile Manifesto that I really love, which is given there are things on the left and then things on the right when the Agile Manifesto was presented. And so it's like we like individuals and interactions, that's the thing on the left, over processes and tools. And so the subtext below it is that is while there is value in the items on the right, we value the items on the left more. And that's one of the things that I love about the Agile Manifesto is it's not this very rigid thing that says, "This is good, and that is bad," it is a statement of a preference of well, yeah, it's definitely good to have comprehensive documentation. That's a really nice thing to have, but it's incredibly difficult. And if we have to choose, we're going to choose working software. We're going to prioritize that well before we have comprehensive documentation. So I really love the juxtaposition, and the emphasis on it's not that one is good and one is bad of these two things that we're comparing but that we have a preference, and that we want to orient our work around the items on the left rather than the items on the right, which I think the items on the right are more traditional or were more traditional to the Waterfall approach.

+ +

STEPH: I like how you highlighted how those statements are presented to the reader. So then that way, as you mentioned, we still value what's on the right, but we favor more what's on the left. So one of the things that I saw recently was something that you shared with me in regards to where you're bringing up the idea of, like, hey, let's talk about Agile. And you shared with me a clip or a specific tweet that linked to a clip from the Go Time Podcast, which is a podcast that I hadn't listened to before. But I listened to that episode or at least part of it, and it's really delightful. I enjoyed listening to them very much. And they had Kris Brandow on the episode. And at the end of the episode...and they do something really fun where they ask the guests, "Do you have an unpopular opinion that you'd like to share?" And one thing that I like about their unpopular opinions is they often have polls afterwards, and they want to see was this truly an unpopular opinion? And if most people agree with you, then they actually consider it nope, he didn't win. I don't know if they use the word win if you didn't achieve the unpopular opinion. And in this instance, Kris shared the opinion that Agile is done and over with and that we should move on, which is a big thing to say. Everyone on the podcast reacted in a similar way that I would where it's like, well, how do we track things? And there are still things that we need to care about. But then also, there's a part of me that's just like, yes. I am not sure where Kris has heard it just yet when I heard that, but I'm already tuned in and very interested.

+ +

And one of the things that Kris said that also really resonated with me is he mentioned that "I've never worked on a team where Scrum specifically like sprint and story points functions well," and I absolutely agree. There are parts of Scrum, we can get to the specifics that I think are fine that I've certainly used in the past and that have worked. Story points resonate deeply. I very much agree that story points are something that I do not enjoy using, and I do not find that they really lead to building software. There's even a blog post that I published along with Matt Sumner, a former thoughtboter and guest on this show, where we talk specifically about story points and some of the concerns and issues that we have with using story points.

+ +

CHRIS: It was actually also the first episode where you came on as a guest to Bike Shed; that that was the topic that we dove into because it was so near and dear to our respective hearts.

+ +

STEPH: That's right. I forgot about that. So yeah, story points are certainly up there on my don't list. I feel like we're doing a fashion do and don't, but we're doing the Agile do and don't list. [laughs]

+ +

CHRIS: I kind of like that. Yeah, we should lean into that vibe. But yeah, continuing on with the poll there, it was interesting to see also, like you said, they tweeted out, and then there's the poll that comes after. And it was 64-ish percent of folks agreed that Agile's time is over and done with, and we need to move. Granted, it wasn't a huge sample size. It was like 85 people that took the poll but still, seeing both the statement and then also the general support from folks on the Twitter, it was interesting to see. So I do have the question of like, well, okay, if not, what else? And I share your sentiment of we should be able to ask questions and iterate. And nothing is so precious that it can't be replaced by something else that's better. So we always need to be trying to find the best ways to work. But again, I think there are still kernels of good stuff in the Agile. So I found this and I was like, oh, this is interesting. What's going on here?

+ +

STEPH: So I'd love to dive into some of the specifics around Agile to understand what are the bits and pieces that work for you and the bits and pieces that don't. So if we are taking our Agile approach and reviewing the things that do and don't work and changing that process, what are the things that you would keep, and what are the things that you would throw out?

+ +

CHRIS: Yeah, well, we can dig in, and we can bounce back and forth, I think, on this. But again, there are sort of a few different camps. So I collected together some of the lists of practices associated with some of the different approaches to Agile. So starting with Scrum, which I think perhaps is one of the most rigid, most structured, and perhaps most ire-deserving of the approaches to Agile, one of the first things is sprints or iterations, so the idea of starting...before you begin the work, you sit down, you define how much work you think you're going to take on. There's often an estimation process. Actually, we'll say that because that's maybe a separate idea, but even just broadly the idea of sprints and iterations, which often involve the idea of committing to a certain body of work. And that commitment is always handwavy and loose. No, no, no, we won't hold you to it, but then it's a constraint that's placed on the team. It's an expectation that's set, but it's wildly difficult to estimate software, as we all know. So sprints and iterations, personally, I am not a fan of. I really like a more continuous flow where we're constantly reprioritizing the work to be done. We're constantly measuring against what we built, what we think we need to get out there. How can we get something out in front of users as quickly as possible? But I've not found a ton of utility in the sprint or iteration workflow. But what do you think of that one?

+ +

STEPH: Yeah, I'm generally not a fan of sprints, and it has taken me a while to get there. And I feel like I can admit that openly because it is something that I feel like when I first started doing software development, sprints were life. It was how you planned everything. It was how you committed to work. It's how you measured your work. It's how you then looked back to see what you could and couldn't accomplish in two weeks’ time or maybe a week's time, depending on how long your sprint is. But over time, I have realized that I don't like the mentality of sprinting, and that may just be a nitpick on my part, but that is something that I don't enjoy because we write better software when we have breaks. And with the sprint methodology, there's really never that break unless you're going to plan that into your sprint.

+ +

And then there's the idea of the upfront commitment, as you'd mentioned, it's one of those, don't worry, we're not going to hold you to this, but can we all commit to this work? And it's one of those you just feel compelled to say, "Yes," to the person who's asking because then you feel like a jerk if you push back and you say, "Well, actually, I don't know if I can, so I'm going to commit to way less." And then that's the approach that I started taking of, well, I don't know. So I'm going to always commit to a little bit because I'd rather overachieve and then deliver more than come in under because I could work really hard, but I've over-committed and then still feel like I didn't reach my goals, and that's a rough feeling. So I found that I was already lowering my commitment there. So then, it felt more appropriate to be in line with that sort of continuous workflow instead of trying to commit to all these features or all these tickets that needed to get done. I think those are the two areas for sprint where it doesn't align with me and where it can work for teams. But I feel like there's always that underlining unhappiness that a lot of us just don't want to talk about because we don't know what else to do other than to keep sprinting.

+ +

CHRIS: Yeah, I think you said something about the specific, like nitpicking the word sprint, but I do think that's actually meaningful. It's The Bike Shed, after all; if we're not going to Bike Shed about some words, what are we doing here? But I do think that we're using that word...it's obviously the wrong word; this thing's a marathon. You can't have 26 2-week sprints back to back throughout a year. That's not going to work. That's not how humans work. But any amount that we let that thinking into our head, I think, is problematic. If I'm understanding correctly, it sounds like you've come to a place of comfort around committing to a smaller body of work and then ideally overdelivering. But in my experience, many developers, perhaps even most developers, don't feel comfortable. It's so difficult to say, "Yeah, I know that the login form should take a day. That's what I feel in my heart. But let's be honest, every other time we've done a form, it's taken a week. So I'm going to say a week." It's so hard to do that. And so I think continuously, we end up in a mode where we are failing to meet the collective commitment that we made, and that's demoralizing. That's going to constantly just be a drag on the team, even if they're fake, made-up deadlines that we're constantly setting, that we're constantly not hitting. Just doing that over and over, I think, is really detrimental to the morale of the team, to the cohesions, and the feelings of are we actually doing this work? So perhaps pedantic, but I definitely share all of that.

+ +

STEPH: I do want to highlight, as I mentioned earlier, I'm feeling more comfortable that I can under commit and then I can overdeliver, and that is hard. That is something that still in the moment, even today, is very hard for me to do. And it's like how you said, in my heart, I feel like this should take a day, and the heart lies. But on top of that, it's often it's also my ego that's driving me all the time. And with that, it feels like a competitive environment to me where someone's saying, "Hey, can you get this done?" And in the moment, that brings out my more competitive side where I want to say, "Yes, I can get all this done, and I can deliver all the things." When, in truth, that's often not how it's going to work out.

+ +

There is one thing I do like about sprints that I want to reflect on, or perhaps it's actually two. And one of them is that we are getting together every so often, and we're agreeing on the important work to be done. And I really like that planning process that is typically coupled with a sprint. So you get together, you review the work, you address any concerns or raise any concerns. And then you could say, "Yes, we all agree this feels like important work." And essentially, we're buying into the work that's getting done, and I really like that process. And then, as an extension of that, I really like how we often then pick themes. So as we are agreeing to the work, we're often grouping together work that makes sense where it's either the most cross-functional or collaborative. We're already going to be in that space together. We're aware of what everybody is working on. And those are the aspects that I really do like about sprint and some of the other styles, that more continuous workflow of where we're always pulling from a backlog. It feels more of a grab bag in terms of I don't really know what I'm going to get next. I don't know how this work has been reviewed or vetted. I haven't really gotten to talk to anybody, perhaps. I'm making some broad statements here. But I haven't really gotten to talk to anybody from the product side to understand this change. And I also don't really know what the rest of the team is working on, so I feel more disconnected from them.

+ +

CHRIS: Yeah, I definitely share that, the planning or the meeting where we discuss the work that's coming up and shape it a little bit; I love that. Although it's interesting within the context of Scrum, I think like truly to the letter Scrum; my understanding is there are very discrete meetings, and they each have a distinct purpose. And so there's the sprint planning meeting, there's a backlog grooming, there's a sprint review and the sprint retrospective. And each of those are these four distinct meetings that are happening once every two weeks or so or whatever your sprint cadence happens to be. And the splitting of those becomes interesting. And some of the practices in there, I think, are...I think you and I share not being interested in doing them or not finding them to be super valuable. But I think broadly having some version of hey, let's sit down and talk about the work before we have to do the work, definitely a fan of that. For me, it often can be let's collapse four of those meetings into one sort of thing and maybe have it more regularly or something to that effect. But actually, we'll touch on the rest of those. But if you're good with bouncing from sprint/iteration, I think we've covered that topic well. Let's move on to one that I think we can do pretty quickly because I'm pretty sure I know how we feel, but sprint planning/planning poker/estimation. How do you feel about this one, Steph?

+ +

STEPH: We grouped a couple of things in there. There's sprint planning, and then there's sprint poker, and those are different to me.

+ +

CHRIS: Yeah. So let's go specific to the planning poker as the most pointed version of it but also generally estimation and sizing of stories.

+ +

STEPH: Nope. Throw it out. I don't know how to play poker. Let's just get rid of it. [laughs] I was never a good poker player.

+ +

CHRIS: Playing poker can be fun, but planning poker...Well, so actually, to ask a slightly different question, I think in the past we've talked about keeping aspects of it, definitely not keeping the let's figure it out, let's hash it out. Let's get down to an exact point value, and then we know we can have 34 story points a week, and that's what we're going to do. But the version of using planning poker, using this numerical communication tool to see if we're aligned, that one I think we've talked about liking that. I have enjoyed that, but under the strict guidelines that we throw the numbers out. The numbers are only a communication tool. They get thrown out after the fact. We do not commit to a set amount of work or anything like that. We just use it to say, "I think it's an eight. I think it's a one. Oh, we should talk," just for that. That's when it's useful.

+ +

STEPH: I agree. Yeah, in my previous answer I was being flippant about it, but I do agree very much where I don't like the specificity of where you're trying to plan exactly what numbers are these. But I do find it very helpful for the reasons that you just said where the team agrees with the estimation around how long they expect something to take. Because then that is really great where you have someone who's never touched the codebase, and they're like, "I think it's a five or whatever system we're using here." It's an elephant...whatever scale you're using. And then someone else is like, "Well, I think it's a doughnut size." I'm making up silly stuff because it's more fun for me. And then those two people can talk and reconcile. So I do like discussing the estimation of work for that purpose but then not actually writing it down or maybe going with t-shirt sizes, something that's more simple, and then doesn't have anything with points, really. Anything with points can then be gamified and also brings out people's more competitive side. So, if you can make it something that's more fun, maybe around t-shirt sizes or a bunch of cute animals, various sizes, whatever works for your team. I'm trying to think of other fun measurements now [laughs] that we could use instead of t-shirt sizes.

+ +

CHRIS: There are the sizes of bottles of wine as you go past. So there's a regular bottle of wine, and then there's a magnum. And then it gets to weird names like a Nebuchadnezzar and other things. These are big performative champagne bottles. So I think we should use that kind of sizing because I think they also have a geometric progression type thing, not quite Fibonacci but something like that. So I'm going to make that push for Nebuchadnezzar as being my go-to [chuckles] sizing in story points.

+ +

STEPH: I have never heard of that, and I love it. That's great.

+ +

CHRIS: Okay. We'll find a relevant link to the wine bottle sizing, and we'll put that into the show notes. We will also, of course, include a link to your wonderful blog post. What's the story with story points that you wrote with Matt Sumner? Because I think that really does dial into this topic really well. And again, coming back to that core idea around Agile, while we see value in the item on the...which side is it? While we see potential value in story points, I have worked with countless teams who desperately wanted to make this thing work. So it would be great if we could quantify the work and then numerically understand the work that we had ahead of us and sequence things and talk about deadlines and whatnot. Man, that would be amazing. I would really love to do that. So with every other developer and every manager of a team of developers in the world, I have not seen it done. I am still looking for that day. When that day shows up, then I think this will be a wonderful practice. But unfortunately, my experience has been that this doesn't work, and trying to do it causes more harm than good.

+ +

STEPH: I agree that I certainly understand the reason that people want story points to work because it's very nice to then say, "We can calculate, and we can measure, and then we can have delivery dates." And that's really nice from a management perspective. But that does blend in nicely to the next topic, which I think fits nicely underneath the Agile umbrella, our daily syncs. Because that does bring us closer to that goal of where we can't give real valid updates on how something is going and provide a more real estimate as to when we think something is going to get delivered. That doesn't have the same effect of where we think we're able to plan and then promise delivery dates a week in advance because we're getting those updates in real-time, but they're going to be more reliable. And that is, we're so much more than where we try to over commit to work or if we try to say how much time something is going to take. And that is so much more valuable to have that reliable update and estimate versus trying to trick ourselves into thinking that we know when something is going to get delivered.

+ +

CHRIS: Yeah, I think the daily sync or sometimes called the daily Scrum, or standup, or otherwise morning meeting often in the morning, this is one that I see lots of folks really hate, and I'm personally a big fan of. This is one that I would definitely hold onto. But I think you have to be very, very purposeful with how you structure it. It really should be as short as possible. And there's one particular thing that I see very regularly in teams, which is almost a performative version of what I did yesterday. It's trying to demonstrate to the team that yes, I, in fact, did work yesterday. I was a valuable team member. Please don't let me go from the team. And I think that's the sort of thing that we should try and just get rid of. There are definitely times where what you did yesterday is relevant to the team, or you worked on something, and now you have a bunch of questions, and bringing that to the team is useful. But that version of everyone needs to prove that they did work yesterday or...it's the sort of thing like if anyone says that sort of thing, then everyone else is like if you don't say what you did yesterday, then it sounds like you did nothing because everyone else is saying what they did.

+ +

So you have to, I think, get a team buy-in to do this, say, "We're not going to talk about sort of bullet-list what we did yesterday. That's not going to get us anywhere as a team." But what's useful are those little magical moments of connection where I say, "Yep, I'm working on this. I'm going to implement it in this way." And someone's like, "Wait, wait, that way? Oh, we shouldn't implement it that way." And then ideally, what happens there is okay; let’s connect after this meeting. You've now made this connection, but you don't need to hold up the rest of the meeting for that. You can just say, "Cool, this connection has been made. That's an incredibly valuable little point in time, but now let's continue on with the flow of the meeting," so that it keeps that rapid pace. And so times where you're blocked, times where you have questions, times where you're just describing what you think you're going to be working on. So if anyone's like, "Oh wait, no, we needed to stop that work because we actually made a decision yesterday that impacts whether or not we actually wanted to build that feature at all." If you can head off incorrect work at the pass, there's so much potential value in that meeting that it is interruptive. And it does take up some time, but I find that it is so, so worth it if you're able to really keep it focused, keep it concise, and keep that end goal of those little connections. When those happen, they're so valuable. So I think it's really worth the input.

+ +

STEPH: I'm still smiling from where you said performative of what I did yesterday because that is something that took me a while to understand, one of the things that I did not like about the daily sync or daily meeting whenever your team gets together to talk about the work that's being done. And it was finally when I realized we're just going through a list of who has the longest list of the things that they accomplished yesterday. And again, it felt like it was bringing out more of that competitive mode in folks to talk about what they did, and it didn't feel very useful. Every now and then, maybe there was one thing that was interesting that someone did. But most of the time, it was always more helpful to hear what the person was working on that day for all the reasons that you just highlighted.

+ +

There is one practical concern that I have with these types of meetings or with these types of events. And it's where you'd mentioned where if we can keep it concise…and someone brings something up, and it starts to devolve into a conversation right there. So then whoever was up next is now waiting while that conversation is happening. And that part gets awkward because then there's usually one person who is then willing or no one frankly is willing to then say, "Hey, so sorry to interrupt, but let's actually table this discussion and let everybody else go, and then we'll come back to this." And if you have people on the team that have been there for a long time with that culture, then that will just work because everyone will keep each other in check. But otherwise, if you're starting that new process, or if you start to notice there's always that one person who's doing that awkward thing of trying to then set that culture of this is how we do our daily chat, and these are the things that then we wait for later, it's really hard. And I say that because I have often been that person that's in that space where then I encourage people to table a conversation. And it always just feels awkward to interrupt someone and ask them to please wait until everybody else has gone.

+ +

CHRIS: I share your hesitations around that, but it is very important. And it's that sort of ideally someone in a more senior position will model that behavior and model it in a positive, friendly way. Where I have done that often it's in the form of a question, so it's, "Actually, do you think maybe we could take this offline?" or something like that. Not a command, not taking over or shutting people down because it is somewhat interjective, and you're sort of correcting course. And so, being as friendly and empathetic in that moment as possible, but that's a hard note to strike. And again, if it's something that only one person is like the taskmaster, the Hermione Granger of the team who's trying to keep everyone focused and doing their homework sort of thing, nobody wants to be that. Well, Hermione did, but otherwise, nobody wants to be.

+ +

STEPH: I love all the Harry Potter-themed references that have been coming through in the last couple of episodes. And I agree it is something that's hard to help teams course-correct, but it's important, and it's very much something worth doing. I just recognized that I think that's why these roles get implemented, why there's this concept of a Scrum Master, and then why we designate these tasks to specific people because then you have someone who can do it. And then when they do interject, it feels more appropriate because that is their role, and that's one of the things that they're supposed to do versus putting it more on the social pressure of whoever is comfortable speaking up to then course-correct. So I do understand where that implementation of Agile has then tried to create those roles, which I've been on teams that have a Scrum Master. And my experience is it's often been a very positive experience because the person that is in that role is often very kind and caring about that team. And so they are a wonderful person to work with, but it's also one of those...I've also been on teams without them, and things have been fine. So I have mixed feelings about that one. It's one of those; it feels like an extra heavy process, but I've also been on teams, and it worked.

+ +

CHRIS: It's interesting the way you frame it, of the utility of that role. Like, having a role where we've now all bought into the idea that this person may take these actions say, "Hey, can we take that conversation offline?" and rather than one individual choosing to do that. I like that framing. I share what you're saying about the rest of the baggage that comes along with having this formal position, and often, that person is otherwise removed from the work. That can often be an aspect of Scrum. I think that gets complicated. But now I'm wondering can we make a software solution to do this? Because, of course, that's where my head goes. Can we have a standup bot that is listening and is like, "Hmm, it seems like you two people have been talking for the past two minutes. I'm just going to interject like my little bot self that I am and ask maybe take this conversation offline," in the way that we've sort of automated a lot of code formatting things, and that's been really wonderful, so that's not a part of PR review. Can we do the same for standup? I don't know.

+ +

STEPH: I think all the award ceremonies have these where they start to play the music, and that's your cue to move off stage.

+ +

CHRIS: Oh, I like it.

+ +

STEPH: I think that's it. [laughs] So you cue the music whenever someone has been going for quite some time. On a slightly separate note but still related to this, some conversations that have been bubbling up around me have been related specifically to this idea around stepping in to say, "Hey, I'll take on that thing that you need a volunteer for," or "Hey, I will help the team stay on track," will often fall on people with a specific personality and then they will often be the one that continues to do that. And so they will end up taking on additional work or taking on additional roles just because they may be in a more empathetic spot where they feel that's the kind, helpful thing to do. And so, we've been looking for more ways to make sure that those tasks are being distributed evenly across the team. So we're not just waiting on someone to say, "Who would volunteer for this?" And then typically being the same handful of people that are always speaking up and then volunteering for it.

+ +

And then trying to shift to more of a purposeful approach of having a queue of people and then cycling through that queue, and then if someone can't do it at a certain time, then we move on and then we just put them back in the queue. But this way, we don't have people that are typically just always taking on these responsibilities. And that's something that is a new consideration for me but one that I have found really helpful to be aware of and notice on your team who's the one that's always volunteering for these roles and checking in with them to see if they're comfortable with this, or if they're feeling compelled to volunteer for stuff because they may feel more inclined to speak up versus others are okay with staying quiet. But circling back to some of the Agile discussions earlier, you'd mentioned a handful of meetings and that you have some feelings about those meetings. What are those meetings that you have feelings about?

+ +

CHRIS: Yes, the meetings. So again, this is somewhat contextual to Scrum, but the structure of Scrum has a handful of meetings that sort of define the sprint. So you have some at the beginning, the middle, and the end. So there's sprint planning, there's backlog grooming, there's sprint review, which typically includes a demo for stakeholders, and then there's sprint retrospective. And these, as far as I understand it, are four distinct meetings and are intended to be kept distinct so that their purpose stays purified in each of those meetings. And I think my feelings would be that again; I don't really find a ton of value in the sprint structure or in the two-week cadence or things like that. And so I think it can make sense in those contexts to be like, we need to make sure we have space for these things. But in a more continuous context, I think the backlog grooming or, more generally, let's talk about the work that's coming up. Let's make sure that we're all unified in how we're thinking about that work, what we think matters, what's prioritized. I think that is an incredibly valuable meeting. I think sprint review and specifically demo for stakeholders I'm really intrigued by that one. I don't know that I feel like that needs to be a distinct meeting. And in fact, more and more these days, almost every feature I deliver has either screenshots or a screen recording of what that workflow looks like. So we're continuously demonstrating to the stakeholders what does this look like now that it's a real thing? What does an end-user see? What's that experience like? And in retrospect, I think we'll probably spend a minute on that one. I like retros; some people hate retros. Yeah, let's loop back to that. But of those, what are your thoughts? What do you like? What do you not like about those meetings?

+ +

STEPH: I think grooming is a very helpful meeting that can help a product manager and a technical team have discussions about the upcoming work. I don't necessarily think it needs to be the whole team. I think it can be a couple of engineers from the team; maybe those people rotate, maybe it's the team lead. And they get together with the product manager, and they essentially answer any technical questions about upcoming work. So then it can be refined. So then, as we get closer to that planning session, whatever we want to call it, then it feels more in a ready state for folks to react to and then have opinions on. So I do like grooming, but I wouldn't necessarily advocate that the whole team needs to be present for those.

+ +

For a demo, I'm with you; it really depends. I've worked on projects where the stakeholders are less close to GitHub and Slack and areas that we could demo some of the work that's being done, and maybe they weren't poking around on staging as much. So it was really helpful to then have a more formal demo to then show them the work that's being done. And then I've also worked on plenty of teams where a demo was something that we used as a fun internal event where we have all these different teams, and we get together. And then we get to show off all the great work that we have done across all the different products. So then us, as fellow teammates, can then celebrate what the other teams are working on.

+ +

Retros, you know I love retros. I think retros are a microcosm of your team's culture and process. And if your team is struggling to have a productive retro, your team is struggling. Because I think that is representative of your team's ability to get together, and reflect, share concerns, celebrate wins, agree on what's important, and run measured experiments. And if you're not having a retro, then I think you're not going to know how your team's doing until it's too late, and it's going to be harder to course-correct.

+ +

CHRIS: #HottakeswithSteph. I like it. I like the intensity that you came in with there, but I know retro is near and dear to your heart. So I'm unsurprised that that is the line that you've drawn. I definitely share all of those feelings, particularly around retro, because I think much like the daily sync, I've seen many people who are just like, "This is a bad meeting. It's useless. Nothing ever happens. I don't like it." And I'm often surprised by that because I've found so much value in it. Retro similarly is this magical meeting that can just regularly change the course of how we're working as a team. But I also have come into plenty of teams where it definitely did not have that shape, where it was basically a place that everyone sits down, and somewhat downtrodden restates their list of grievances, their airing of grievances, and then nothing changes. And much like the sprint iteration thing where you're constantly missing the commitments, and that's just going to wear a team down. I think if you constantly have retro and nothing changes and it's that same list of concerns, then that is going to be bad, but that, like you said, is not the reason not to do it. [chuckles] Oh, we just keep saying the same things in retro, so I don't think it's even that valuable. I would say that maybe we should change the things. But I've definitely been on plenty of teams where retro was just so valuable. And it's definitely one where I feel like having a facilitator, having someone who is in that particular seat trying to guide the conversation without necessarily being in the conversation, can be incredibly valuable.

+ +

There are also structures that I've seen work particularly well. We have a video on Upcase that we can link to. That's a format that I've found; it’s a very lightweight format, but it basically involves getting everyone's input on a positive note, on a more critical note, and then revisiting and sort of sorting and waiting, and then digging into topics that need a little bit more focus. But I think a lot of different formats can work as long as retro is a way for people to sincerely meet up, safely talk about the things that they are feeling about the work, and then ideally, some change comes about as a result of that. You mentioned having measured experiments, and I love that as a framing or like something that retro can do for us.

+ +

STEPH: I really do think that retros are so important because they're the health check of the team. As you'd mentioned, if people are having a very negative retro experience, which I understand, I've had very negative retro experiences as well, and I've walked away feeling like that was not a productive use of my time. But then that is our warning. That is our signal that's saying, "Something is not right, and something's not great, and we're not working together as we really want to be working together." And this retro is just that reminder that is right in our face, that is making this so uncomfortable and feel like a waste of our time because it is informing us that something needs to be improved upon. And we can feel like retros are not productive when we feel powerless to make that change. And that again is then another discussion to have with the team, to have with management, leadership, to talk about how do we get the power to then make the changes that we need to then have productive, happy retros? Because that's going to be a reflection that you have a happy, productive team.

+ +

CHRIS: Love it, love the framing, love the symmetry there between team happiness and retro happiness. So to summarize, I think we've gone through most of Scrum now. So just to...correct me if I'm wrong on any of these, but I believe sprints and iterations, nah, we'll leave it. Planning poker, definitely not. That doesn't seem good, although maybe just to bring up conversations, but not as an artifact that we save in any way. And then otherwise, daily sync, we're fans. Retro, definitely fans. Sprint review, backlog grooming, some version of those, a lightweight version of a bunch of the meetings seems may be good, but a couple of things definitely are going to leave on the cutting-room floor. Does that sound about right to you for Scrum specifically? We've got other topics to cover.

+ +

STEPH: Yep. All of that list sounds really good.

+ +

CHRIS: All right. So we've now found our refined version of Scrum, re-Scrum as we'll call it. But now there's a couple of other pieces...So Scrum is very focused on the ceremonies and the team activities, but there's another facet of the Agile umbrella, which is Extreme Programming, which that's a book. I believe Extreme Programming Explained is the name of the book. And there are various different links that we'll include to point at those. But there are two particular practices that stand out that I have heard some people love, some people do not. So we'll go into both of them. The first is pair programming. What do you think, Steph? Do you like pair programming?

+ +

STEPH: I do. I'm a huge fan. [laughs] Yes, I very much like pair programming, although it still has its limitations. I definitely want time on my own, and I can get exhausted from pair programming. It is a very vulnerable experience, too, where you have to share with someone: this is what I know, this is how I work, this is how I think. And I think that is incredibly challenging. I find that I am typically more productive when I'm pairing with someone or when I have the opportunity to pair with someone at least every couple of days.

+ +

CHRIS: Yep. I'm definitely a huge fan of pairing. Although I think specifically to Extreme Programming, I think the idea is 100% pairing. I think you already spoke to this, but pairing is exhausting. And the idea of 100% pairing is I can't really even imagine that; even 50% pairing feels like an incredibly high bar to hold for any extended period of time. There's a recent article that was going around the mortifying ordeal of pairing all day, which spoke of one person's experiences getting deeply burnt out just going through that process. And so, as valuable as pairing is, it's definitely a tool to be used not all the time. That feels like a lot.

+ +

STEPH: That's a lot of Stephanie singing because I tend to sing a lot whenever I'm stuck or thinking through things. So that's a lot of singing that I don't know if the world wants.

+ +

CHRIS: I mean, based on all of the various Bike Shed intros that involve you singing, I think the world wants it. That's maybe one person's take. But definitely, something that you said of there's a vulnerability to it. And so many pairing sessions I've either been the one saying this or someone else that I was pairing with has said this to me, but they're like, "I swear I know how to type, just now that someone's looking, my hands don't work." It's like you're in a dream, and your legs don't work. You're like, I know how to run, I swear. But for some reason, my legs are made of jelly right now. Or you can't remember a particular method, or there's just something that happens, and so getting over that hump, getting comfortable with it, I think it is a skill and something to become accustomed to. And so, again, being conscious of that when you start doing it is super important.

+ +

STEPH: I don't know if this is true because I only have access to people’s thoughts when I'm pairing with them, and then they're sharing their thoughts with me. But I do feel like people tend to beat themselves up more when they have someone watching because then you feel the need to say, "Oh, I normally can type, but because someone's watching..." which is so true; that definitely happens. But those moments are some of those really great moments to then reflect on the fact that just because someone's watching us doesn't mean that then we suddenly need to beat ourselves up. And I don't know how philosophical that I want to get with this, but I feel like there are so many opportunities while pair programming to then encourage other people around us to be kind to themselves. That is one of the things that I have really benefited from pair programming is learning to be more kind to myself. And even if I don't know exactly what's happening or what I'm doing and I may not be as confident with someone else, I can still be positive and kind. Just because you're in a vulnerable space doesn't mean that you then need to be unkind to yourself.

+ +

CHRIS: Yeah. I definitely agree with the idea of being kind to yourself also, where you can, be kind to someone else who you're pairing with, especially if they're finding that they're like, "Ah, suddenly my hands don't quite work." But I have pretty uniformly seen that a pairing session may start out that way. And then as everybody kind of just relaxes into it, suddenly you'll see someone just kind of flying around their editor. And you're like, wait, what just happened there? That was so fast. I don't even know. And so there's just this comfort level that sometimes it takes a little bit of time to ease into. But yeah, so pair programming, broadly yes. 100%, oh, that's going to be a no, no, thank you, not that. All right, so one other practice that comes from Extreme Programming, which is Test-Driven Development AKA TDD. What do you think about that one, Steph?

+ +

STEPH: I feel like you're giving me lay-up questions here. For anyone that's familiar with us, [laughs] I feel like this is an easy one. Test-Driven Development is a thing. It's a thing that I enjoy. I don't always write tests first, though, so I don't always follow TDD, but I am definitely a fan of tests. So, I guess in that light, it’s not so much that I adhere always to TDD. I don't feel the need that I have to write tests first, but I have found that with practice, that often helps me write code where I have tests then help me write out the logic for my code. So generally, yes, thumbs up on TDD, but I'm also not terribly strict about it where if you want to write some code first, write some code first.

+ +

CHRIS: Yeah, I think I'm definitely in the mode where I like testing. I like Test-Driven Development. I can't always pull it off, frankly. It's hard. It is hard to know how to write a test in advance of the implementation that you're going to write such that the test will correctly constrain the system that you're about to write. That takes a couple of levels of knowledge that if I'm writing a Rail’s controller action form sequence, I can probably TDD that because I've done it so many times. But if I'm doing something that's a little bit more new, novel, less familiar to me, then likely I won't be able to pull it off. TDD is like a fancy move that I don't always have available to me. But I consider that whenever I'm in that mode like that's not oh, it's fine to just write the thing before the test. Like, I want to be able to do TDD 100% of the time. I'm just not a good enough developer, frankly. And I don't know that I ever will be because I always want to be working a little bit past the edge of my comfort. So it's a delicate line of when I will not use TDD, but wherever I can, wherever I do have that level of knowledge of the system and the frameworks and whatnot built up, I find it is a vastly more effective way to work. It's not that I feel cool when I do it. It's like I feel much more effective. It helps me stay focused and on task and get the thing done. So it's very utilitarian in that way but also not something I can always pull off.

+ +

STEPH: So, circling back to when we first started chatting, you were asking about Agile and then my thoughts about it. And having this conversation with you, I'm realizing, or I think I was already aware, but it's helping me re-solidify I'm very much a fan of Agile. There are specific implementations of Agile that I don't find enjoyable, and I don't find helpful to writing software, and I don't find helpful from the project management side either. But broadly speaking, I'm still very much a fan of the approach that we use generally for Agile, where we want to work in small deliverable increments, and then we also want to have the ability to change any moment what is the most important thing to work on? To me, that is the heart of following the Agile process. And I don't think that's going anywhere. Like, I don't think Agile's going to disappear. But I wouldn't be surprised if we see another implementation of an Agile variety of the things that you and I just shared and the things that we like. And so, I feel like most teams that I work with follow Agile within their own unique bespoke version. And we don't have to give it names because everybody's going to have their own custom version where they decide which process works for them and which one doesn't work for them. And that's what retros are for so then you can figure out which process works for you.

+ +

CHRIS: Once more, Steph on the record about her love of retro. I think the core of Agile, the Manifesto, those core ideas about small iterations, delivering value, staying close to stakeholders, all of that feels deeply true to me. And I would be really surprised if a year from now or two years from now I was doing something that was wildly different from that. But then each of the layers of practices on top of that to varying degrees I like or don't like. And I wouldn't be surprised if aspects of that were swapped out down the road. But that core, that idea of this is how we think about building software. I like that thing; that seems like a good thing. So I'm going to hold on to Agile for a little bit longer personally.

+ +

STEPH: Same. I still see Agile in my future. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: Show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Let's talk about Agile! What is it, what do we like, we do we not like?

+ +

In this episode, Steph and Chris discuss:

+ +
    +
  • Broadly, are they fans?
    • +
  • What makes this practice work well?
    • +
  • What makes this practice work poorly?
    • +
+ +

And also, hit specific topics and practices like Scrum, Kanban, and Extreme Programming.

+ + + +

Transcript:

+ +

CHRIS: I feel like we should try a couple of different byes just so we have sort of a smorgasbord of options, and then we can pick the best one.

+ +

STEPH: With countdowns, [laughter] because I do so well with countdowns.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, I thought we would try maybe something a little bit different this week, a little bit more of a structured topic. In particular, I've been gathering little tidbits of information. I've been seeing conversations happen all around the topic of Agile, things that people like about Agile, things that people hate, mostly it's things that people hate about Agile. Lots of ire on the internet about Agile, but I think also some disagreement about what it actually means. And I think; generally, you and I are probably fans, so I want to talk about that. What parts do we like? What parts do we not like? What do we think Agile actually means or, at its best, maybe what it means? But yeah, let's start at the very top stuff. Steph, what do you think about Agile?

+ +

STEPH: I am generally a fan. I'm with you. And yeah, the internet being full of more negative remarks and ire, that sounds very true. But generally, I am very much a fan of Agile, and the very broad scope of this is how we work, and this is how we plan our work, and this is how we collaborate as a team, and then how we reflect on the work that we have completed. I can also pick apart some of the things I don't like about Agile, but in the broad umbrella definition, I'm a big fan. I've enjoyed that approach. Granted, I've also only ever used Agile. I haven't written software using a Waterfall style, at least not purposefully. And then if I have encountered a team that was using more of a Waterfall style, then we changed it quickly. I really only have known the more Agile approach to writing software.

+ +

CHRIS: I think that's largely true of me as well, where most of my work would fit somewhere under the umbrella of lowercase "a" agile, although I've tried variants of Scrum and Kanban and a bunch of other things that we'll probably chat about today. But I think in general, I find that things are most effective; things seem to move the most smoothly. And I think the software that we come out with is the best one. It's closest to those very simple ideals of Agile. And every layer of process that gets added on even though, like you, I've not done true Waterfall where it's like six months requirements gathering and then it gets handed off, and no one talks for a while. I've never done that.

+ +

STEPH: I have to interject because I actually think you have in a previous life when you were an engineer. You have done the more Waterfall. Like, you have to plan very far in advance.

+ +

CHRIS: I think this is one of those cases where people think "engineering" quote, unquote like mechanical engineering is one thing and it's actually...there is a little more structure, and there's a little more necessity of sequencing where you've got to figure out what you need to buy first because sometimes it takes a while to find the particular piece of metal that you need in the world. But it also has a lot of figuring out as you go and being like, well, we've got a bunch of stuff, and we're just going to figure it out. And also, this is something that as I was studying software while working as a mechanical engineer, I started to hear about this whole Agile thing, and I was like, huh, I wonder how I can bring more of that? Because I definitely saw cases where a more Waterfall-centric approach to engineering projects was leading to bad outcomes. It's like we decided upfront what we're going to do, and then we went away for six months, and we did it. And then we came back, and it turned out it was wrong. So that was solvable along the way. There were ways to build prototypes and things like that. So that is definitely a part of the mechanical engineering world.

+ +

Although I think there are some true constraints, but I think there are also some occasionally self-imposed constraints, but again, I see sort of the same thing in software. Anytime that we can shorten feedback loops, that's what I like. And I think that for me, that's the core of Agile. Specifically, to come to the Agile Manifesto, to start at the very top, the thing that kicked it all off is a very simple document that the first line of it is "We prioritize individuals and interactions over processes and tools." It's like, yeah, that seems like a great thing, having more regular conversations about the things that we're building rather than having those initial conversations. And everybody goes away for a while and tries to build that thing, and then they come back, and hopefully, the thing that they've produced actually solves the problem. But I think almost always there are some deviations like, oh, actually, it would have been better if it was like this or now that we're actually trying it in the field, it's fundamentally different. So in that way, I think there's actually a lot of commonality between mechanical engineering and software development.

+ +

STEPH: Okay, that makes sense. Yeah, I was thinking around the process of where you'd have to order stuff in advance versus for us; we can describe everything that we need as we need it unless we're having to procure some specific software or licensing. But otherwise, we don't have to wait on that shipment flow to then have our goods. And then, if we also mess something up, then we don't have to reorder more pieces. But I like how you started talking about that agile with lowercase "a" and then talking about the manifesto because I suspect most people are familiar with Agile, but it wouldn't hurt just to read off some of those top things about what Agile is so that way we're all on the same page together for this conversation.

+ +

So you already covered the first one that talks about individuals and interactions over processes and tools, and then the others are working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. And that's it; those are the aspects of Agile. And so then, circling back to what you were saying earlier where people are having more criticisms around Agile, it sounds that it's less about Agile, and it's often more about the implementation of these ideas and then how you're approaching them. Because, boy, do we have several ways to implement Agile. We have Scrum; we have Kanban; there’s Extreme Programming. Does that fall within the Agile umbrella? I think it does.

+ +

CHRIS: I believe so. And I think a lot of the things that people take issue with particularly come from Scrum and Extreme Programming. We're taken to their extremes. Yeah, it's right there in the name, so you should probably know that it's going to be a little out there. But taken to the extreme and especially where it becomes rigid and dogmatic, then it becomes a problem. But again, so we listed out now the four items that are the core of the manifesto. There is a separate part of the manifesto, which is the principles, which digs in a little bit deeper, but it's still very much in that same ethos. But I do want to highlight because there's a subtext to the Agile Manifesto that I really love, which is given there are things on the left and then things on the right when the Agile Manifesto was presented. And so it's like we like individuals and interactions, that's the thing on the left, over processes and tools. And so the subtext below it is that is while there is value in the items on the right, we value the items on the left more. And that's one of the things that I love about the Agile Manifesto is it's not this very rigid thing that says, "This is good, and that is bad," it is a statement of a preference of well, yeah, it's definitely good to have comprehensive documentation. That's a really nice thing to have, but it's incredibly difficult. And if we have to choose, we're going to choose working software. We're going to prioritize that well before we have comprehensive documentation. So I really love the juxtaposition, and the emphasis on it's not that one is good and one is bad of these two things that we're comparing but that we have a preference, and that we want to orient our work around the items on the left rather than the items on the right, which I think the items on the right are more traditional or were more traditional to the Waterfall approach.

+ +

STEPH: I like how you highlighted how those statements are presented to the reader. So then that way, as you mentioned, we still value what's on the right, but we favor more what's on the left. So one of the things that I saw recently was something that you shared with me in regards to where you're bringing up the idea of, like, hey, let's talk about Agile. And you shared with me a clip or a specific tweet that linked to a clip from the Go Time Podcast, which is a podcast that I hadn't listened to before. But I listened to that episode or at least part of it, and it's really delightful. I enjoyed listening to them very much. And they had Kris Brandow on the episode. And at the end of the episode...and they do something really fun where they ask the guests, "Do you have an unpopular opinion that you'd like to share?" And one thing that I like about their unpopular opinions is they often have polls afterwards, and they want to see was this truly an unpopular opinion? And if most people agree with you, then they actually consider it nope, he didn't win. I don't know if they use the word win if you didn't achieve the unpopular opinion. And in this instance, Kris shared the opinion that Agile is done and over with and that we should move on, which is a big thing to say. Everyone on the podcast reacted in a similar way that I would where it's like, well, how do we track things? And there are still things that we need to care about. But then also, there's a part of me that's just like, yes. I am not sure where Kris has heard it just yet when I heard that, but I'm already tuned in and very interested.

+ +

And one of the things that Kris said that also really resonated with me is he mentioned that "I've never worked on a team where Scrum specifically like sprint and story points functions well," and I absolutely agree. There are parts of Scrum, we can get to the specifics that I think are fine that I've certainly used in the past and that have worked. Story points resonate deeply. I very much agree that story points are something that I do not enjoy using, and I do not find that they really lead to building software. There's even a blog post that I published along with Matt Sumner, a former thoughtboter and guest on this show, where we talk specifically about story points and some of the concerns and issues that we have with using story points.

+ +

CHRIS: It was actually also the first episode where you came on as a guest to Bike Shed; that that was the topic that we dove into because it was so near and dear to our respective hearts.

+ +

STEPH: That's right. I forgot about that. So yeah, story points are certainly up there on my don't list. I feel like we're doing a fashion do and don't, but we're doing the Agile do and don't list. [laughs]

+ +

CHRIS: I kind of like that. Yeah, we should lean into that vibe. But yeah, continuing on with the poll there, it was interesting to see also, like you said, they tweeted out, and then there's the poll that comes after. And it was 64-ish percent of folks agreed that Agile's time is over and done with, and we need to move. Granted, it wasn't a huge sample size. It was like 85 people that took the poll but still, seeing both the statement and then also the general support from folks on the Twitter, it was interesting to see. So I do have the question of like, well, okay, if not, what else? And I share your sentiment of we should be able to ask questions and iterate. And nothing is so precious that it can't be replaced by something else that's better. So we always need to be trying to find the best ways to work. But again, I think there are still kernels of good stuff in the Agile. So I found this and I was like, oh, this is interesting. What's going on here?

+ +

STEPH: So I'd love to dive into some of the specifics around Agile to understand what are the bits and pieces that work for you and the bits and pieces that don't. So if we are taking our Agile approach and reviewing the things that do and don't work and changing that process, what are the things that you would keep, and what are the things that you would throw out?

+ +

CHRIS: Yeah, well, we can dig in, and we can bounce back and forth, I think, on this. But again, there are sort of a few different camps. So I collected together some of the lists of practices associated with some of the different approaches to Agile. So starting with Scrum, which I think perhaps is one of the most rigid, most structured, and perhaps most ire-deserving of the approaches to Agile, one of the first things is sprints or iterations, so the idea of starting...before you begin the work, you sit down, you define how much work you think you're going to take on. There's often an estimation process. Actually, we'll say that because that's maybe a separate idea, but even just broadly the idea of sprints and iterations, which often involve the idea of committing to a certain body of work. And that commitment is always handwavy and loose. No, no, no, we won't hold you to it, but then it's a constraint that's placed on the team. It's an expectation that's set, but it's wildly difficult to estimate software, as we all know. So sprints and iterations, personally, I am not a fan of. I really like a more continuous flow where we're constantly reprioritizing the work to be done. We're constantly measuring against what we built, what we think we need to get out there. How can we get something out in front of users as quickly as possible? But I've not found a ton of utility in the sprint or iteration workflow. But what do you think of that one?

+ +

STEPH: Yeah, I'm generally not a fan of sprints, and it has taken me a while to get there. And I feel like I can admit that openly because it is something that I feel like when I first started doing software development, sprints were life. It was how you planned everything. It was how you committed to work. It's how you measured your work. It's how you then looked back to see what you could and couldn't accomplish in two weeks’ time or maybe a week's time, depending on how long your sprint is. But over time, I have realized that I don't like the mentality of sprinting, and that may just be a nitpick on my part, but that is something that I don't enjoy because we write better software when we have breaks. And with the sprint methodology, there's really never that break unless you're going to plan that into your sprint.

+ +

And then there's the idea of the upfront commitment, as you'd mentioned, it's one of those, don't worry, we're not going to hold you to this, but can we all commit to this work? And it's one of those you just feel compelled to say, "Yes," to the person who's asking because then you feel like a jerk if you push back and you say, "Well, actually, I don't know if I can, so I'm going to commit to way less." And then that's the approach that I started taking of, well, I don't know. So I'm going to always commit to a little bit because I'd rather overachieve and then deliver more than come in under because I could work really hard, but I've over-committed and then still feel like I didn't reach my goals, and that's a rough feeling. So I found that I was already lowering my commitment there. So then, it felt more appropriate to be in line with that sort of continuous workflow instead of trying to commit to all these features or all these tickets that needed to get done. I think those are the two areas for sprint where it doesn't align with me and where it can work for teams. But I feel like there's always that underlining unhappiness that a lot of us just don't want to talk about because we don't know what else to do other than to keep sprinting.

+ +

CHRIS: Yeah, I think you said something about the specific, like nitpicking the word sprint, but I do think that's actually meaningful. It's The Bike Shed, after all; if we're not going to Bike Shed about some words, what are we doing here? But I do think that we're using that word...it's obviously the wrong word; this thing's a marathon. You can't have 26 2-week sprints back to back throughout a year. That's not going to work. That's not how humans work. But any amount that we let that thinking into our head, I think, is problematic. If I'm understanding correctly, it sounds like you've come to a place of comfort around committing to a smaller body of work and then ideally overdelivering. But in my experience, many developers, perhaps even most developers, don't feel comfortable. It's so difficult to say, "Yeah, I know that the login form should take a day. That's what I feel in my heart. But let's be honest, every other time we've done a form, it's taken a week. So I'm going to say a week." It's so hard to do that. And so I think continuously, we end up in a mode where we are failing to meet the collective commitment that we made, and that's demoralizing. That's going to constantly just be a drag on the team, even if they're fake, made-up deadlines that we're constantly setting, that we're constantly not hitting. Just doing that over and over, I think, is really detrimental to the morale of the team, to the cohesions, and the feelings of are we actually doing this work? So perhaps pedantic, but I definitely share all of that.

+ +

STEPH: I do want to highlight, as I mentioned earlier, I'm feeling more comfortable that I can under commit and then I can overdeliver, and that is hard. That is something that still in the moment, even today, is very hard for me to do. And it's like how you said, in my heart, I feel like this should take a day, and the heart lies. But on top of that, it's often it's also my ego that's driving me all the time. And with that, it feels like a competitive environment to me where someone's saying, "Hey, can you get this done?" And in the moment, that brings out my more competitive side where I want to say, "Yes, I can get all this done, and I can deliver all the things." When, in truth, that's often not how it's going to work out.

+ +

There is one thing I do like about sprints that I want to reflect on, or perhaps it's actually two. And one of them is that we are getting together every so often, and we're agreeing on the important work to be done. And I really like that planning process that is typically coupled with a sprint. So you get together, you review the work, you address any concerns or raise any concerns. And then you could say, "Yes, we all agree this feels like important work." And essentially, we're buying into the work that's getting done, and I really like that process. And then, as an extension of that, I really like how we often then pick themes. So as we are agreeing to the work, we're often grouping together work that makes sense where it's either the most cross-functional or collaborative. We're already going to be in that space together. We're aware of what everybody is working on. And those are the aspects that I really do like about sprint and some of the other styles, that more continuous workflow of where we're always pulling from a backlog. It feels more of a grab bag in terms of I don't really know what I'm going to get next. I don't know how this work has been reviewed or vetted. I haven't really gotten to talk to anybody, perhaps. I'm making some broad statements here. But I haven't really gotten to talk to anybody from the product side to understand this change. And I also don't really know what the rest of the team is working on, so I feel more disconnected from them.

+ +

CHRIS: Yeah, I definitely share that, the planning or the meeting where we discuss the work that's coming up and shape it a little bit; I love that. Although it's interesting within the context of Scrum, I think like truly to the letter Scrum; my understanding is there are very discrete meetings, and they each have a distinct purpose. And so there's the sprint planning meeting, there's a backlog grooming, there's a sprint review and the sprint retrospective. And each of those are these four distinct meetings that are happening once every two weeks or so or whatever your sprint cadence happens to be. And the splitting of those becomes interesting. And some of the practices in there, I think, are...I think you and I share not being interested in doing them or not finding them to be super valuable. But I think broadly having some version of hey, let's sit down and talk about the work before we have to do the work, definitely a fan of that. For me, it often can be let's collapse four of those meetings into one sort of thing and maybe have it more regularly or something to that effect. But actually, we'll touch on the rest of those. But if you're good with bouncing from sprint/iteration, I think we've covered that topic well. Let's move on to one that I think we can do pretty quickly because I'm pretty sure I know how we feel, but sprint planning/planning poker/estimation. How do you feel about this one, Steph?

+ +

STEPH: We grouped a couple of things in there. There's sprint planning, and then there's sprint poker, and those are different to me.

+ +

CHRIS: Yeah. So let's go specific to the planning poker as the most pointed version of it but also generally estimation and sizing of stories.

+ +

STEPH: Nope. Throw it out. I don't know how to play poker. Let's just get rid of it. [laughs] I was never a good poker player.

+ +

CHRIS: Playing poker can be fun, but planning poker...Well, so actually, to ask a slightly different question, I think in the past we've talked about keeping aspects of it, definitely not keeping the let's figure it out, let's hash it out. Let's get down to an exact point value, and then we know we can have 34 story points a week, and that's what we're going to do. But the version of using planning poker, using this numerical communication tool to see if we're aligned, that one I think we've talked about liking that. I have enjoyed that, but under the strict guidelines that we throw the numbers out. The numbers are only a communication tool. They get thrown out after the fact. We do not commit to a set amount of work or anything like that. We just use it to say, "I think it's an eight. I think it's a one. Oh, we should talk," just for that. That's when it's useful.

+ +

STEPH: I agree. Yeah, in my previous answer I was being flippant about it, but I do agree very much where I don't like the specificity of where you're trying to plan exactly what numbers are these. But I do find it very helpful for the reasons that you just said where the team agrees with the estimation around how long they expect something to take. Because then that is really great where you have someone who's never touched the codebase, and they're like, "I think it's a five or whatever system we're using here." It's an elephant...whatever scale you're using. And then someone else is like, "Well, I think it's a doughnut size." I'm making up silly stuff because it's more fun for me. And then those two people can talk and reconcile. So I do like discussing the estimation of work for that purpose but then not actually writing it down or maybe going with t-shirt sizes, something that's more simple, and then doesn't have anything with points, really. Anything with points can then be gamified and also brings out people's more competitive side. So, if you can make it something that's more fun, maybe around t-shirt sizes or a bunch of cute animals, various sizes, whatever works for your team. I'm trying to think of other fun measurements now [laughs] that we could use instead of t-shirt sizes.

+ +

CHRIS: There are the sizes of bottles of wine as you go past. So there's a regular bottle of wine, and then there's a magnum. And then it gets to weird names like a Nebuchadnezzar and other things. These are big performative champagne bottles. So I think we should use that kind of sizing because I think they also have a geometric progression type thing, not quite Fibonacci but something like that. So I'm going to make that push for Nebuchadnezzar as being my go-to [chuckles] sizing in story points.

+ +

STEPH: I have never heard of that, and I love it. That's great.

+ +

CHRIS: Okay. We'll find a relevant link to the wine bottle sizing, and we'll put that into the show notes. We will also, of course, include a link to your wonderful blog post. What's the story with story points that you wrote with Matt Sumner? Because I think that really does dial into this topic really well. And again, coming back to that core idea around Agile, while we see value in the item on the...which side is it? While we see potential value in story points, I have worked with countless teams who desperately wanted to make this thing work. So it would be great if we could quantify the work and then numerically understand the work that we had ahead of us and sequence things and talk about deadlines and whatnot. Man, that would be amazing. I would really love to do that. So with every other developer and every manager of a team of developers in the world, I have not seen it done. I am still looking for that day. When that day shows up, then I think this will be a wonderful practice. But unfortunately, my experience has been that this doesn't work, and trying to do it causes more harm than good.

+ +

STEPH: I agree that I certainly understand the reason that people want story points to work because it's very nice to then say, "We can calculate, and we can measure, and then we can have delivery dates." And that's really nice from a management perspective. But that does blend in nicely to the next topic, which I think fits nicely underneath the Agile umbrella, our daily syncs. Because that does bring us closer to that goal of where we can't give real valid updates on how something is going and provide a more real estimate as to when we think something is going to get delivered. That doesn't have the same effect of where we think we're able to plan and then promise delivery dates a week in advance because we're getting those updates in real-time, but they're going to be more reliable. And that is, we're so much more than where we try to over commit to work or if we try to say how much time something is going to take. And that is so much more valuable to have that reliable update and estimate versus trying to trick ourselves into thinking that we know when something is going to get delivered.

+ +

CHRIS: Yeah, I think the daily sync or sometimes called the daily Scrum, or standup, or otherwise morning meeting often in the morning, this is one that I see lots of folks really hate, and I'm personally a big fan of. This is one that I would definitely hold onto. But I think you have to be very, very purposeful with how you structure it. It really should be as short as possible. And there's one particular thing that I see very regularly in teams, which is almost a performative version of what I did yesterday. It's trying to demonstrate to the team that yes, I, in fact, did work yesterday. I was a valuable team member. Please don't let me go from the team. And I think that's the sort of thing that we should try and just get rid of. There are definitely times where what you did yesterday is relevant to the team, or you worked on something, and now you have a bunch of questions, and bringing that to the team is useful. But that version of everyone needs to prove that they did work yesterday or...it's the sort of thing like if anyone says that sort of thing, then everyone else is like if you don't say what you did yesterday, then it sounds like you did nothing because everyone else is saying what they did.

+ +

So you have to, I think, get a team buy-in to do this, say, "We're not going to talk about sort of bullet-list what we did yesterday. That's not going to get us anywhere as a team." But what's useful are those little magical moments of connection where I say, "Yep, I'm working on this. I'm going to implement it in this way." And someone's like, "Wait, wait, that way? Oh, we shouldn't implement it that way." And then ideally, what happens there is okay; let’s connect after this meeting. You've now made this connection, but you don't need to hold up the rest of the meeting for that. You can just say, "Cool, this connection has been made. That's an incredibly valuable little point in time, but now let's continue on with the flow of the meeting," so that it keeps that rapid pace. And so times where you're blocked, times where you have questions, times where you're just describing what you think you're going to be working on. So if anyone's like, "Oh wait, no, we needed to stop that work because we actually made a decision yesterday that impacts whether or not we actually wanted to build that feature at all." If you can head off incorrect work at the pass, there's so much potential value in that meeting that it is interruptive. And it does take up some time, but I find that it is so, so worth it if you're able to really keep it focused, keep it concise, and keep that end goal of those little connections. When those happen, they're so valuable. So I think it's really worth the input.

+ +

STEPH: I'm still smiling from where you said performative of what I did yesterday because that is something that took me a while to understand, one of the things that I did not like about the daily sync or daily meeting whenever your team gets together to talk about the work that's being done. And it was finally when I realized we're just going through a list of who has the longest list of the things that they accomplished yesterday. And again, it felt like it was bringing out more of that competitive mode in folks to talk about what they did, and it didn't feel very useful. Every now and then, maybe there was one thing that was interesting that someone did. But most of the time, it was always more helpful to hear what the person was working on that day for all the reasons that you just highlighted.

+ +

There is one practical concern that I have with these types of meetings or with these types of events. And it's where you'd mentioned where if we can keep it concise…and someone brings something up, and it starts to devolve into a conversation right there. So then whoever was up next is now waiting while that conversation is happening. And that part gets awkward because then there's usually one person who is then willing or no one frankly is willing to then say, "Hey, so sorry to interrupt, but let's actually table this discussion and let everybody else go, and then we'll come back to this." And if you have people on the team that have been there for a long time with that culture, then that will just work because everyone will keep each other in check. But otherwise, if you're starting that new process, or if you start to notice there's always that one person who's doing that awkward thing of trying to then set that culture of this is how we do our daily chat, and these are the things that then we wait for later, it's really hard. And I say that because I have often been that person that's in that space where then I encourage people to table a conversation. And it always just feels awkward to interrupt someone and ask them to please wait until everybody else has gone.

+ +

CHRIS: I share your hesitations around that, but it is very important. And it's that sort of ideally someone in a more senior position will model that behavior and model it in a positive, friendly way. Where I have done that often it's in the form of a question, so it's, "Actually, do you think maybe we could take this offline?" or something like that. Not a command, not taking over or shutting people down because it is somewhat interjective, and you're sort of correcting course. And so, being as friendly and empathetic in that moment as possible, but that's a hard note to strike. And again, if it's something that only one person is like the taskmaster, the Hermione Granger of the team who's trying to keep everyone focused and doing their homework sort of thing, nobody wants to be that. Well, Hermione did, but otherwise, nobody wants to be.

+ +

STEPH: I love all the Harry Potter-themed references that have been coming through in the last couple of episodes. And I agree it is something that's hard to help teams course-correct, but it's important, and it's very much something worth doing. I just recognized that I think that's why these roles get implemented, why there's this concept of a Scrum Master, and then why we designate these tasks to specific people because then you have someone who can do it. And then when they do interject, it feels more appropriate because that is their role, and that's one of the things that they're supposed to do versus putting it more on the social pressure of whoever is comfortable speaking up to then course-correct. So I do understand where that implementation of Agile has then tried to create those roles, which I've been on teams that have a Scrum Master. And my experience is it's often been a very positive experience because the person that is in that role is often very kind and caring about that team. And so they are a wonderful person to work with, but it's also one of those...I've also been on teams without them, and things have been fine. So I have mixed feelings about that one. It's one of those; it feels like an extra heavy process, but I've also been on teams, and it worked.

+ +

CHRIS: It's interesting the way you frame it, of the utility of that role. Like, having a role where we've now all bought into the idea that this person may take these actions say, "Hey, can we take that conversation offline?" and rather than one individual choosing to do that. I like that framing. I share what you're saying about the rest of the baggage that comes along with having this formal position, and often, that person is otherwise removed from the work. That can often be an aspect of Scrum. I think that gets complicated. But now I'm wondering can we make a software solution to do this? Because, of course, that's where my head goes. Can we have a standup bot that is listening and is like, "Hmm, it seems like you two people have been talking for the past two minutes. I'm just going to interject like my little bot self that I am and ask maybe take this conversation offline," in the way that we've sort of automated a lot of code formatting things, and that's been really wonderful, so that's not a part of PR review. Can we do the same for standup? I don't know.

+ +

STEPH: I think all the award ceremonies have these where they start to play the music, and that's your cue to move off stage.

+ +

CHRIS: Oh, I like it.

+ +

STEPH: I think that's it. [laughs] So you cue the music whenever someone has been going for quite some time. On a slightly separate note but still related to this, some conversations that have been bubbling up around me have been related specifically to this idea around stepping in to say, "Hey, I'll take on that thing that you need a volunteer for," or "Hey, I will help the team stay on track," will often fall on people with a specific personality and then they will often be the one that continues to do that. And so they will end up taking on additional work or taking on additional roles just because they may be in a more empathetic spot where they feel that's the kind, helpful thing to do. And so, we've been looking for more ways to make sure that those tasks are being distributed evenly across the team. So we're not just waiting on someone to say, "Who would volunteer for this?" And then typically being the same handful of people that are always speaking up and then volunteering for it.

+ +

And then trying to shift to more of a purposeful approach of having a queue of people and then cycling through that queue, and then if someone can't do it at a certain time, then we move on and then we just put them back in the queue. But this way, we don't have people that are typically just always taking on these responsibilities. And that's something that is a new consideration for me but one that I have found really helpful to be aware of and notice on your team who's the one that's always volunteering for these roles and checking in with them to see if they're comfortable with this, or if they're feeling compelled to volunteer for stuff because they may feel more inclined to speak up versus others are okay with staying quiet. But circling back to some of the Agile discussions earlier, you'd mentioned a handful of meetings and that you have some feelings about those meetings. What are those meetings that you have feelings about?

+ +

CHRIS: Yes, the meetings. So again, this is somewhat contextual to Scrum, but the structure of Scrum has a handful of meetings that sort of define the sprint. So you have some at the beginning, the middle, and the end. So there's sprint planning, there's backlog grooming, there's sprint review, which typically includes a demo for stakeholders, and then there's sprint retrospective. And these, as far as I understand it, are four distinct meetings and are intended to be kept distinct so that their purpose stays purified in each of those meetings. And I think my feelings would be that again; I don't really find a ton of value in the sprint structure or in the two-week cadence or things like that. And so I think it can make sense in those contexts to be like, we need to make sure we have space for these things. But in a more continuous context, I think the backlog grooming or, more generally, let's talk about the work that's coming up. Let's make sure that we're all unified in how we're thinking about that work, what we think matters, what's prioritized. I think that is an incredibly valuable meeting. I think sprint review and specifically demo for stakeholders I'm really intrigued by that one. I don't know that I feel like that needs to be a distinct meeting. And in fact, more and more these days, almost every feature I deliver has either screenshots or a screen recording of what that workflow looks like. So we're continuously demonstrating to the stakeholders what does this look like now that it's a real thing? What does an end-user see? What's that experience like? And in retrospect, I think we'll probably spend a minute on that one. I like retros; some people hate retros. Yeah, let's loop back to that. But of those, what are your thoughts? What do you like? What do you not like about those meetings?

+ +

STEPH: I think grooming is a very helpful meeting that can help a product manager and a technical team have discussions about the upcoming work. I don't necessarily think it needs to be the whole team. I think it can be a couple of engineers from the team; maybe those people rotate, maybe it's the team lead. And they get together with the product manager, and they essentially answer any technical questions about upcoming work. So then it can be refined. So then, as we get closer to that planning session, whatever we want to call it, then it feels more in a ready state for folks to react to and then have opinions on. So I do like grooming, but I wouldn't necessarily advocate that the whole team needs to be present for those.

+ +

For a demo, I'm with you; it really depends. I've worked on projects where the stakeholders are less close to GitHub and Slack and areas that we could demo some of the work that's being done, and maybe they weren't poking around on staging as much. So it was really helpful to then have a more formal demo to then show them the work that's being done. And then I've also worked on plenty of teams where a demo was something that we used as a fun internal event where we have all these different teams, and we get together. And then we get to show off all the great work that we have done across all the different products. So then us, as fellow teammates, can then celebrate what the other teams are working on.

+ +

Retros, you know I love retros. I think retros are a microcosm of your team's culture and process. And if your team is struggling to have a productive retro, your team is struggling. Because I think that is representative of your team's ability to get together, and reflect, share concerns, celebrate wins, agree on what's important, and run measured experiments. And if you're not having a retro, then I think you're not going to know how your team's doing until it's too late, and it's going to be harder to course-correct.

+ +

CHRIS: #HottakeswithSteph. I like it. I like the intensity that you came in with there, but I know retro is near and dear to your heart. So I'm unsurprised that that is the line that you've drawn. I definitely share all of those feelings, particularly around retro, because I think much like the daily sync, I've seen many people who are just like, "This is a bad meeting. It's useless. Nothing ever happens. I don't like it." And I'm often surprised by that because I've found so much value in it. Retro similarly is this magical meeting that can just regularly change the course of how we're working as a team. But I also have come into plenty of teams where it definitely did not have that shape, where it was basically a place that everyone sits down, and somewhat downtrodden restates their list of grievances, their airing of grievances, and then nothing changes. And much like the sprint iteration thing where you're constantly missing the commitments, and that's just going to wear a team down. I think if you constantly have retro and nothing changes and it's that same list of concerns, then that is going to be bad, but that, like you said, is not the reason not to do it. [chuckles] Oh, we just keep saying the same things in retro, so I don't think it's even that valuable. I would say that maybe we should change the things. But I've definitely been on plenty of teams where retro was just so valuable. And it's definitely one where I feel like having a facilitator, having someone who is in that particular seat trying to guide the conversation without necessarily being in the conversation, can be incredibly valuable.

+ +

There are also structures that I've seen work particularly well. We have a video on Upcase that we can link to. That's a format that I've found; it’s a very lightweight format, but it basically involves getting everyone's input on a positive note, on a more critical note, and then revisiting and sort of sorting and waiting, and then digging into topics that need a little bit more focus. But I think a lot of different formats can work as long as retro is a way for people to sincerely meet up, safely talk about the things that they are feeling about the work, and then ideally, some change comes about as a result of that. You mentioned having measured experiments, and I love that as a framing or like something that retro can do for us.

+ +

STEPH: I really do think that retros are so important because they're the health check of the team. As you'd mentioned, if people are having a very negative retro experience, which I understand, I've had very negative retro experiences as well, and I've walked away feeling like that was not a productive use of my time. But then that is our warning. That is our signal that's saying, "Something is not right, and something's not great, and we're not working together as we really want to be working together." And this retro is just that reminder that is right in our face, that is making this so uncomfortable and feel like a waste of our time because it is informing us that something needs to be improved upon. And we can feel like retros are not productive when we feel powerless to make that change. And that again is then another discussion to have with the team, to have with management, leadership, to talk about how do we get the power to then make the changes that we need to then have productive, happy retros? Because that's going to be a reflection that you have a happy, productive team.

+ +

CHRIS: Love it, love the framing, love the symmetry there between team happiness and retro happiness. So to summarize, I think we've gone through most of Scrum now. So just to...correct me if I'm wrong on any of these, but I believe sprints and iterations, nah, we'll leave it. Planning poker, definitely not. That doesn't seem good, although maybe just to bring up conversations, but not as an artifact that we save in any way. And then otherwise, daily sync, we're fans. Retro, definitely fans. Sprint review, backlog grooming, some version of those, a lightweight version of a bunch of the meetings seems may be good, but a couple of things definitely are going to leave on the cutting-room floor. Does that sound about right to you for Scrum specifically? We've got other topics to cover.

+ +

STEPH: Yep. All of that list sounds really good.

+ +

CHRIS: All right. So we've now found our refined version of Scrum, re-Scrum as we'll call it. But now there's a couple of other pieces...So Scrum is very focused on the ceremonies and the team activities, but there's another facet of the Agile umbrella, which is Extreme Programming, which that's a book. I believe Extreme Programming Explained is the name of the book. And there are various different links that we'll include to point at those. But there are two particular practices that stand out that I have heard some people love, some people do not. So we'll go into both of them. The first is pair programming. What do you think, Steph? Do you like pair programming?

+ +

STEPH: I do. I'm a huge fan. [laughs] Yes, I very much like pair programming, although it still has its limitations. I definitely want time on my own, and I can get exhausted from pair programming. It is a very vulnerable experience, too, where you have to share with someone: this is what I know, this is how I work, this is how I think. And I think that is incredibly challenging. I find that I am typically more productive when I'm pairing with someone or when I have the opportunity to pair with someone at least every couple of days.

+ +

CHRIS: Yep. I'm definitely a huge fan of pairing. Although I think specifically to Extreme Programming, I think the idea is 100% pairing. I think you already spoke to this, but pairing is exhausting. And the idea of 100% pairing is I can't really even imagine that; even 50% pairing feels like an incredibly high bar to hold for any extended period of time. There's a recent article that was going around the mortifying ordeal of pairing all day, which spoke of one person's experiences getting deeply burnt out just going through that process. And so, as valuable as pairing is, it's definitely a tool to be used not all the time. That feels like a lot.

+ +

STEPH: That's a lot of Stephanie singing because I tend to sing a lot whenever I'm stuck or thinking through things. So that's a lot of singing that I don't know if the world wants.

+ +

CHRIS: I mean, based on all of the various Bike Shed intros that involve you singing, I think the world wants it. That's maybe one person's take. But definitely, something that you said of there's a vulnerability to it. And so many pairing sessions I've either been the one saying this or someone else that I was pairing with has said this to me, but they're like, "I swear I know how to type, just now that someone's looking, my hands don't work." It's like you're in a dream, and your legs don't work. You're like, I know how to run, I swear. But for some reason, my legs are made of jelly right now. Or you can't remember a particular method, or there's just something that happens, and so getting over that hump, getting comfortable with it, I think it is a skill and something to become accustomed to. And so, again, being conscious of that when you start doing it is super important.

+ +

STEPH: I don't know if this is true because I only have access to people’s thoughts when I'm pairing with them, and then they're sharing their thoughts with me. But I do feel like people tend to beat themselves up more when they have someone watching because then you feel the need to say, "Oh, I normally can type, but because someone's watching..." which is so true; that definitely happens. But those moments are some of those really great moments to then reflect on the fact that just because someone's watching us doesn't mean that then we suddenly need to beat ourselves up. And I don't know how philosophical that I want to get with this, but I feel like there are so many opportunities while pair programming to then encourage other people around us to be kind to themselves. That is one of the things that I have really benefited from pair programming is learning to be more kind to myself. And even if I don't know exactly what's happening or what I'm doing and I may not be as confident with someone else, I can still be positive and kind. Just because you're in a vulnerable space doesn't mean that you then need to be unkind to yourself.

+ +

CHRIS: Yeah. I definitely agree with the idea of being kind to yourself also, where you can, be kind to someone else who you're pairing with, especially if they're finding that they're like, "Ah, suddenly my hands don't quite work." But I have pretty uniformly seen that a pairing session may start out that way. And then as everybody kind of just relaxes into it, suddenly you'll see someone just kind of flying around their editor. And you're like, wait, what just happened there? That was so fast. I don't even know. And so there's just this comfort level that sometimes it takes a little bit of time to ease into. But yeah, so pair programming, broadly yes. 100%, oh, that's going to be a no, no, thank you, not that. All right, so one other practice that comes from Extreme Programming, which is Test-Driven Development AKA TDD. What do you think about that one, Steph?

+ +

STEPH: I feel like you're giving me lay-up questions here. For anyone that's familiar with us, [laughs] I feel like this is an easy one. Test-Driven Development is a thing. It's a thing that I enjoy. I don't always write tests first, though, so I don't always follow TDD, but I am definitely a fan of tests. So, I guess in that light, it’s not so much that I adhere always to TDD. I don't feel the need that I have to write tests first, but I have found that with practice, that often helps me write code where I have tests then help me write out the logic for my code. So generally, yes, thumbs up on TDD, but I'm also not terribly strict about it where if you want to write some code first, write some code first.

+ +

CHRIS: Yeah, I think I'm definitely in the mode where I like testing. I like Test-Driven Development. I can't always pull it off, frankly. It's hard. It is hard to know how to write a test in advance of the implementation that you're going to write such that the test will correctly constrain the system that you're about to write. That takes a couple of levels of knowledge that if I'm writing a Rail’s controller action form sequence, I can probably TDD that because I've done it so many times. But if I'm doing something that's a little bit more new, novel, less familiar to me, then likely I won't be able to pull it off. TDD is like a fancy move that I don't always have available to me. But I consider that whenever I'm in that mode like that's not oh, it's fine to just write the thing before the test. Like, I want to be able to do TDD 100% of the time. I'm just not a good enough developer, frankly. And I don't know that I ever will be because I always want to be working a little bit past the edge of my comfort. So it's a delicate line of when I will not use TDD, but wherever I can, wherever I do have that level of knowledge of the system and the frameworks and whatnot built up, I find it is a vastly more effective way to work. It's not that I feel cool when I do it. It's like I feel much more effective. It helps me stay focused and on task and get the thing done. So it's very utilitarian in that way but also not something I can always pull off.

+ +

STEPH: So, circling back to when we first started chatting, you were asking about Agile and then my thoughts about it. And having this conversation with you, I'm realizing, or I think I was already aware, but it's helping me re-solidify I'm very much a fan of Agile. There are specific implementations of Agile that I don't find enjoyable, and I don't find helpful to writing software, and I don't find helpful from the project management side either. But broadly speaking, I'm still very much a fan of the approach that we use generally for Agile, where we want to work in small deliverable increments, and then we also want to have the ability to change any moment what is the most important thing to work on? To me, that is the heart of following the Agile process. And I don't think that's going anywhere. Like, I don't think Agile's going to disappear. But I wouldn't be surprised if we see another implementation of an Agile variety of the things that you and I just shared and the things that we like. And so, I feel like most teams that I work with follow Agile within their own unique bespoke version. And we don't have to give it names because everybody's going to have their own custom version where they decide which process works for them and which one doesn't work for them. And that's what retros are for so then you can figure out which process works for you.

+ +

CHRIS: Once more, Steph on the record about her love of retro. I think the core of Agile, the Manifesto, those core ideas about small iterations, delivering value, staying close to stakeholders, all of that feels deeply true to me. And I would be really surprised if a year from now or two years from now I was doing something that was wildly different from that. But then each of the layers of practices on top of that to varying degrees I like or don't like. And I wouldn't be surprised if aspects of that were swapped out down the road. But that core, that idea of this is how we think about building software. I like that thing; that seems like a good thing. So I'm going to hold on to Agile for a little bit longer personally.

+ +

STEPH: Same. I still see Agile in my future. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: Show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+CnND1FJZ + + ]]> + + Chris Toomey + Steph Viccari + + + 298: Jawsification + https://bikeshed.thoughtbot.com/298 + 070d397b-5e00-4bfd-bb9e-4995599c4630 + Tue, 29 Jun 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris gives some small updates on working with Svelte. He really likes Svelte so far. Svelte's great. Modals are complicated. He also talks about using a little JavaScript library, called Quicklink. Steph talks about sending data to a third-party system and using feature flags to help deprecate some code. + +Finally, they both riff on a listener question on consulting. Said listener asked, "Do you think about your work as 'consulting first' or as 'building great software first and then good experiences for your clients will follow naturally?'" Find out their take and give us your own, here on this episode of 'The Bike Shed!' + 42:30 + no + + + Chris gives some small updates on working with Svelte. He really likes Svelte so far. Svelte's great. Modals are complicated. He also talks about using a little JavaScript library, called Quicklink. Steph talks about sending data to a third-party system and using feature flags to help deprecate some code. +Finally, they both riff on a listener question on consulting. Said listener asked, "Do you think about your work as 'consulting first' or as 'building great software first and then good experiences for your clients will follow naturally?'" Find out their take and give us your own, here on this episode of 'The Bike Shed!' +Bike Shed "Nate Berkopec" Episode (https://www.bikeshed.fm/296) +Svelte (https://svelte.dev/) +Quicklink (https://getquick.link/) +Boring Rails: Skip the bullshit and ship fast (https://boringrails.com/) +mtime (File) - APIdock (https://apidock.com/ruby/File/mtime/class) +Transcript: +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, happy Friday. How has your week been? +CHRIS: Happy Friday. My week's been great, yeah. I've been writing a lot of code, moving things around, planning some features, and all that fun stuff that goes into building an app, so I'm enjoying that process. I'm also halfway through listening to your recent episode with Nate Berkopec, which was absolutely delightful, well, at least the first half that I've listened to so far. I assume the rest will continue to be absolutely delightful, but it does remain to be seen. So I'll report back next week when I've listened to the whole thing. But yeah, that's great. And I'm glad that Nate got to come on, and we got to share a little bit of his story as well. +STEPH: I like how clear you are in terms of like, "The part that I've listened to so far is great, but I reserve judgment until I've heard the rest of it." [chuckles] But that's awesome. +CHRIS: The thing about being a developer is it has broken my brain such that I am overly specific all the time because I just argue with a computer all day. It's what I do. So then I start talking to humans, and I'm like, wait, I should probably behave differently now. And I got to unwind some of those computer fights. But anyway, and let's see, small updates working with Svelte, really like Svelte. I'm leaning into it more and more and embracing...I think I'm starting to understand the aspects of it that I really like. And one of the things that I really like about it is that it is somewhat underpowered. And what I mean by that is working on React applications, I find that I can do some fancy stuff, and I can express it really well in TypeScript. And I can really go for it and create some components that are wildly variable and configurable and can take in any combination of props and do all sorts of things. And I can slice out tiny, little components and do all of this. When I'm doing that, I enjoy it. +But in Svelte, I have a little bit less power in my control. Svelte is closer to HTML, CSS, and JavaScript fundamentally. So you can make components, and I really like that. You can bundle up the pieces of functionality and display and formatting, and all of that, but it's not quite as powerful. It's not quite as expressive. And I've actually found that to be a useful limitation, which is an interesting frame. It's not something that I thought I would say, but I'm finding that the code that I'm authoring in my editor is so much closer to the code that's actually going to be presented to the end-user. That is really useful in my mind. I find that to be really valuable. There are small things like in Svelte; you can actually say class equals when you're trying to define a class on an HTML element. It turns out I really like that one instead of having to say class name or similarly HTML for. There is a handful of them in React that you have to change the name of. So if you copy a snippet of HTML from the web, and then you dump it into your editor, if you're working in React, you have to change a bunch of stuff. It doesn't work right away. And it's a small thing, but I found that I really seem to care about it. But there's the “it's nice that it just works” version. But I feel like there's also an actually practical, meaningful edge of it is so much closer to the thing that's actually going to be in the browser, and I like that. +STEPH: I liked the phrasing that you used just a moment ago where you said, "Useful limitation." Since I haven't used Svelte myself, one of my understandings is that you like the fact that it is that low JS in terms that we are introducing this framework, but it's not as heavy-handed as React or another framework that you could retour. But then you also said you're running up to areas where you feel like you're missing some stuff from React, is what I'm hearing. Is there a particular feature, or do you have a concrete example to help me understand some of the stuff that you are really missing? +CHRIS: It's not so much that I feel like there are specific features missing, but as a pointed example, I am not able to pass in the DOM element that I would like the component to render as. That's a weird thing, but often, component libraries will do this. So you have a button component, but the button can render either as a literal HTML button element or an anchor element. And you can pass in as equals and then button as the string there. And in React, you can do that, and then you can actually do some type inference across it and say, "Okay, now the rest of the props that you can pass in are button props.” And if you pass in as equals a, so implying that you want it to be an anchor or a link, then it will constrain you to the link properties and say, "Oh, you must have a HREF now." That's really cool that you can do that. It's also super complicated, and the TypeScript representation of it, while it works, is very, very complicated and the types of errors that you get. The complexity of what you can build with React is really interesting. But I worry now that I've spent a good bit of time in Svelte, I worry if it's overpowered. I've worked on plenty of applications where the system as designed in React, all the set of different components is very, very complicated. And you sort of have to learn that system in order to be able to work in it, whereas in Svelte, you just start, and you're writing in HTML and CSS. And then, as you need more fancy stuff, you can slowly layer it in. And to be clear, Svelte definitely has plenty of power. +This past week, actually, we were working on a modal component, but we were really focused on accessibility, which is probably a good thing that you should do, but it turns out modals are very hard to get right. The dialogue component that should exist in HTML is not complete, and it's not a thing that we can rely on. So we have to do certain things ourselves. So the idea of focus trapping when the model pops up, we need to say, oh, okay, the focus should be trapped inside of here, so you can tab forward and back, but it's going to stay within that modal component. There's actually a way that you're supposed to portal it. So you move it outside of the documents so that you can make the rest of the document...I want to say aria-hidden is the property, but you're basically saying the entire rest of the document that's behind this modal component should be inert to a screen reader essentially or invisible to a screen reader while the modal is up. And doing all of those sorts of things is super complicated. After you close the modal, you're supposed to refocus the button that opened it, the triggering element, and that's a tricky one where you have to pass down a reference to something. And that was all very expressive, actually, very straightforward in Svelte in a way that I was really impressed by. So it definitely has all the power that you need but not any more than what you need. Or there is a small line of it's just right. +STEPH: So we should just scrap modals. That's one of the things that I'm hearing from you. So I just want to clarify because I do feel a little confused because in the beginning, it sounded like you were saying that Svelte is wonderful, but you do feel like you're missing a little bit of functionality there that you do receive with other frameworks like React. But then that last thing you said where “it's just right” sounds like it's the Goldilocks. So I'm a little confused as to exactly how you're feeling about Svelte in the moment. +CHRIS: Yeah. I'm probably not being as clear as I should. I am a big fan of Svelte, so as the first answer, a big fan of Svelte. I'm recognizing that, strictly speaking, it is somewhat less powerful than React. But I'm also trying to say, perhaps failing at saying, but trying to say that I like that, that I'm finding its constraints are useful. React can do a ton of stuff. You can represent a real impressive array of component functionality and have components that take 17 different props that covary in different ways, and it's very complicated. And I've worked on plenty of React applications where I just have to stare very hard at the component library for a while. And I'm like, ugh, I still don't know how this works. And it's this custom bespoke language where Svelte feels like it is much closer to the thing that we're actually doing, which is rendering HTML and CSS and JavaScript and whatnot, and I like that. I'm finding that very useful. I'm finding that lack of power not to be a hindrance but, in fact, to be useful. +STEPH: Hmm. Okay. I like that last part. Yeah, there are often times where I feel like the less powerful something is, even if it means a little extra work on my end but it's clear as to the work that's being done...I'm going to take it back a couple of years to when I was first learning Elixir because that's how I felt jumping from Ruby to Elixir and from Rails to Phoenix, where suddenly I felt like I had more clarity. There were some things that I had to do more on my own, but I felt more clarity as to what exactly was being done versus Ruby and Rails doing a lot on my behalf. So I can certainly relate to that. +CHRIS: Yeah, I think that captures it well, that the expressive power of React can perhaps lead to somewhat more confusing code, and the small handful of cases where I need to be slightly more verbose in Svelte I actually find really useful. Like, Svelte is making sure that I'm writing components that are clear and easy to work with, but it still has all of the power that I need, and I can do everything I want in it. And yeah, overall, just yeah, Svelte's great. Modals are complicated. And that's my story. But yeah, that's a little bit of what's up with me. What's going on in your world? +STEPH: Before we switch gears. I want to add on a little bit more to what you just said because something that I have noticed with me is that the longer that I've been a developer, the more I want that lower-level control and understanding as to what is happening. And it sounds like that is very much what you're saying that you're enjoying with Svelte is even if it does require a little more extra effort, that then at least I have that ability to exactly control what's happening versus if you're using higher-level obstructions, you're stuck with the API that's been designed for you. And that API works 98% of the time, that's wonderful but then that 2% of the time you're in trouble. So I've definitely noticed that trend, that over time, I want that lower-level control over everything that I'm working with and building, although not all the way to C, let's not go that far. +CHRIS: I mean, there's Assembly underneath C. We can keep going, and we can just manually manipulate transistors as well if we really want to get after it. [laughs] +STEPH: Next week on The Bike Shed. [laughs] +CHRIS: Much, much higher level of abstractions are interesting to me, but yeah, there is a sweet spot. Svelte seems like it's the one for me. +STEPH: Nice. So then switching back to what's new in my week, it's been a little bit of a weird week in terms of there's been a lot of focusing on sending data to a third-party system. So we had a lot of data that they needed in their system. So I have been focused on running a number of processes that are then sending that data over and then essentially babysitting processes, making sure everything is going smoothly. Also communicating with their team to understand okay, what's being received? Do we have any errors? Is there any sort of miscommunication between our systems, and that's why we're needing to resend this data to you? So it's been very different in terms that it wasn't a typical feature development week. It was more, hey, I sent you some data. What did you receive? And then let's fine-tune both of our systems on each end, which that part I always enjoy. As soon as I can get to that level of collaboration with someone, I very much enjoy that part because initially, it felt like a stressful task of like, hey, we've got this giant CSV. We need to process and send data. But then as soon as I have someone else to work with, then I'm like, yeah, okay, this is great. They can update their system. We can fine-tune ours as well in case there's something that's not communicating properly, and that part I really enjoy. I really enjoy collaborating with someone else so then we can both improve our systems together, so that part was a little different. +But the actual weird thing that I did this week is we have feature flags, and we are using those feature flags to help us sunset and deprecate some code. So we have a controller path that is pretty gnarly. It is one of the more dense, difficult areas of our codebase to understand. And so we are refactoring it and creating a new green space for it so we can start to pull in some of that behavior and then also refactor as we go. So we essentially have class version one, and we now have class version two, which is always something. And we want to be able to feature flag this because, with our deployment workflow, we need the ability one; we want to be able to switch back quickly. So that way, if something goes awry, we can switch back to the original code if we've made some misassumption in our V2 version. And then we want to leave that on for a while to make sure things are running smoothly, and then we can go back and actually remove that class. +But then the question came up is like, well, if we have these two files, how do we tell the team not to touch this particular file but only contribute or make a change to this other file? Because we have a sizeable team, and we work in different time zones. And there is a very reasonable answer that we communicate with the team that other folks are aware because they've seen the PR. There's a whole self-discipline of we review PRs and make sure stuff wasn't changed. All of that stuff is fine. It's reasonable. But I wanted to do something a little less reasonable [chuckles] that would still fail loudly in case someone changed a file. So the question was presented is there a way that we could fail loudly if someone changed this file? And there's a fun thing that we'll do at some of our daily syncs where someone will say, "That's a good idea. I have a bad idea." There's a fun thing that happens at our daily syncs where someone will often ask a question, and someone will provide an idea. And then someone else will say, "That's a good idea, but just to throw it out there, I have a bad idea. So let's just explore all of the ideas." And one of them was like, "Could we write a test around this? So if the file hash or something about that changed, then could we alert the team so then we know that this file changed and you're not supposed to change this file?" And essentially, having that discussion of like, well, then we're reimplementing Git because we're trying to track file changes. That seems like a bad idea but still a novel one to talk about for a few minutes. +The implementation that I landed on and then shared with a person that's working on this is you do have the ability with Ruby, the file class itself; you can open a particular file. And for this one, select class one, and then you can use the function mtime, which returns the modification time for a file. So you can check the last time that a file was changed. So I wrote a test that says that "This file was last altered at…" and I grabbed that file's last altered at time with mtime. And then, I compared that to a particular DateTime. And then that DateTime could be any DateTime in the future once we deploy this class version two, so we don't expect that file to be altered. So this test will always pass until someone changes that file. And then Ruby is going to say, "Oh, your time is now greater than that other time you said." And so it's going to fail, which actually works pretty well. It's not as ugly as I thought it was going to be. [chuckles] As to whether it's a good thing to add to the codebase, I don't know, but it was a fun thing to write. +CHRIS: I like it. I've definitely written things like that in the past, and I guess; therefore, I'm biased. [chuckles] I'm a fan of this sort of thing. But when you can take that group knowledge that is just shared in communication or via code review and you can capture it in the code, especially if you can do it in a stable, robust way…In particular, the first thing that comes to mind with that is like, well, are there going to be different representations of the timestamp on your system versus CI? Will that ever change over time? Like, Linux versus OS X or things like that. I actually have reached for Git in situations like this in the past. So, in particular, the one that I found myself doing a few times is trying to instrument code generation. So say we're working with Apollo, and we are generating the TypeScript types associated with a GraphQL request. I wanted to put something into CI to say, "If we haven't committed those changes," because we're supposed to be committing those files alongside, "then warn." And so the idea was take a snapshot of what things look like right now, run the command that does the code generation, and then check after that. +I've done different versions where it's like, hey, Git, is the working directory dirty at this point? That's a version. I've also done one recently where I got the checksum of the file but again, asking Git. Because you're totally right that a lot of this...this is what Git does, and we don't want to rewrite Git. But I did feel okay reaching out and being like, "Hey, Git, can you help me understand the word?" But I like these sorts of things, particularly if you can do it in a way that won't ever require someone turning it off. I don't know if you've worked on projects where ESLint is enabled, but every third line has an eslint-disable-next-line. And it's just like, well, we have a bunch of rules, but we ignore them in a lot of cases. And those sort of...the like trust scenario with an automated tool I think is so important. If it's ever giving you false positives, false negatives, whichever it is, then it immediately, I think, loses so much of its utility. But if you can do it in a way that is stable and robust, then I am a huge fan. +STEPH: Well, we'll see if the person decides to include it in their PR or not. But I do like that idea of where we can take away the idea that we're going to catch it if it changes in a PR because then we're just going to end up in a bad place that if we fix a bug in the class V1 but don't apply that to class V2, we're just going to be in a bad spot. And it's likely we'll forget about it when we go back to then delete class version one. There is something that you said that has reminded me of a very small change that I made to my process, but I feel like it had a big impact. And it's specific to working with feature flags, how often you'll have your tests where it's like if feature flag is on, this behavior should happen, if it's off, this behavior. And I often would wrap my test in the default path where the feature flag is off, and then I'd have my other if the feature flag is on; this is the behavior. But as we are migrating with the intent that this feature flag at some point in the near term future is going to always be on, so we know we're going to come back and remove all of the other code. I switched those two paths and treat the default happy path as the new if the feature flag is on; this is the new world. So then when folks are going back to say, "Okay, I just need to delete everything that represents when the feature flag is off," suddenly, it's just very easy to find that context to say, "Hey, feature flag is off and then boom, delete all of those tests." And that's been really nice. +CHRIS: I really like that lens of designing or coding for deleteability. How easy is it to just rip this thing out? It's one of the things that I love about Tailwind, or one of the purported facets of Tailwind that makes it really nice is when you're looking at a given template, you can just rip it out. You don't have to worry about it because there's no associated CSS that you need to think about because the CSS is sort of generated available, whatever you want to call it with Tailwind. But I really like that idea of making it easy to delete stuff. Because it's so easy to just have your codebase slowly grow over time and look at files and be like, "I don't know if we're using that, but better to be safe." Cool. I'm excited to hear if that does land in the codebase and how folks respond to it. What did you phrase the message as? So if there's a test failure, did you give a particular like a special RSpec formatted message to be like, "Hey, friend, you're not supposed to touch this file. I know you're well-intentioned, but…" or is it just like, "Failure, bad. Mtime is different." Which end of the spectrum are we on there? +STEPH: I love that you asked that question because I almost went down that path, and I was like, well, this should really have its own custom failure message because it's odd enough that I want to tell someone a little bit of a story when it fails. But I didn't because this was something that one; I just want to see if I could do. So I initially started looking at standard rb in RuboCop because at first, I was wondering if this was something I could solve via linting if it was something that RuboCop…if I could say, "Hey, RuboCop, if you notice that this file changed…" I didn't know if they had a hook into Git as they're looking for files to analyze. So I first leaned on RuboCop standard rb, which essentially then uses RuboCop under the hood, and I didn't find anything there. So then that's when I was like, okay, maybe Ruby has something, and that's when I found the file mtime. So at that point, once I'd gotten the test to pass, I'm like, you know, this is good. There's a very nice, friendly test description that goes along with if this fails; this is the reason why. But I do think that would be like cherry on the top addition to the test to have a very nice error message that goes along with this. So if I were the one that was adding this to the codebase, I would take a few more minutes to do that myself. It definitely felt like one of those moments where I had gone far enough into an experimental mode, and I felt like I had just reached that point where this is useful, and I want to share it with the person who's actually working on this. But then I pulled back going further because I'm like, I don't actually know if they want to use this and if they're going to implement it. So it felt like that right friendly balance of like, here's something that works. Feel free to use as is, make it better, don't use it, totally up to you. +CHRIS: Yeah, I think given that context, that's definitely I feel like a good line to draw, not like, “Here's fully completed code that you can now just drop in. I did all the work, but here it is.” Versus like, “Oh, here's a kernel of an idea if you want, run with it, but if not...”But yeah, [chuckles] if you went to the length of writing a nice paragraph summary message to the end-user, that feels like you're really taking over the show. So cool. Well, yeah, interested again to hear how that goes and hear if it does, in fact, stop. That's the other thing. It's like, if it never actually fails, then everybody was just fine with the human process. But I'm intrigued to see how many times it actually does stop unwanted modifications of the file. So that's an interesting measure to track. +STEPH: Yeah, that would be an interesting thing to track because if we do have it, then we may have less visibility into knowing if it failed because then someone will see it fail locally, but then we will have prevented it from getting to that PR state. It is one of those “did someone not change it because we added the test, or could we have skipped that process?” It feels like one of those nice safety measures, but that would be a fun thing to measure, I agree. +CHRIS: Yeah, especially if it's a small change; in this case, I think it's totally worth it. But now, as I said it, I didn't mean it to be more of a thing. But now that I think about the question, I wonder if all tests should fail at some point. Like, all tests have a cost, both in terms of development and then thinking about them in runtime and all of that. And a good test is one that eventually fails because you change the system in a way that broke some constraint. And so, therefore, I'm now asking the question, like, should every test fail at some point? Are tests that only ever pass actually not that useful? I don't think so. Now there's a story running in the back of my head that's like, I kind of want to look at the CI stats. And feature specs will occasionally fail for unrelated reasons. But unit-level tests that never break, that never fail and catch something that was broken…I don't know that I actually believe this, but I'm just intrigued. As I asked the question, I was like, huh, should all tests fail? Sort of like one hand clapping kind of thing, anyway. +STEPH: I like the question, or it's making me stop and think because my initial answer is yes, as long as it's failing for a meaningful reason, as long as it's not a flaky test or something along those lines. But otherwise, as you're working on the system and you're making changes, then I'm inclined to say that yes, every test should fail at some point. But I agree, if we're getting into existential test area, then I don't have concrete feelings about this yet. +CHRIS: Yeah, and I feel like it's one of those sorts of questions. So pivoting off of that ever so slightly to bring us to something much more practical, I have a tiny utility that I want to chat about. And then I think we have a listener question that we want to discuss. But the utility, I think I brought this up on a previous Bike Shed episode, but the tool it's a little JavaScript library, but it's called Quicklink. And so the heading is instant next-page navigations. And so the way it works is it's just a little snippet of JavaScript that you'll include from a CDN, or you can NPM install it or any number of ways. But it's a tiny, little one kilobyte JavaScript thing that basically what it does is it attaches to every link on the page whenever you use that link. So you click on it or if you're on mobile if you tap, or however you're interacting with it, if it's an internal link, so not external to your site and not going to a different domain, but if it's internal to your domain, what it's going to do is it's actually going to prefetch in the background as you hover on that link. So it's going to say, "Hover is a good indication of intent to follow this link. So we're going to prefetch it in the background." And then when the user actually subsequently clicks it, which is often a couple of 100 milliseconds later, that's often enough time actually for the page to load in the background. And then, when they click the link, it almost feels like instant navigation. There's a similar thing that happens based on when you tap and when the actual firing of the link happens on mobile. So there's another delay that they can take advantage of there that's not quite the same as hover. But overall, it just takes basically any webpage, any website, and makes it feel very much faster. And it's cheap, easy, just kind of works. I really like it. It's a very interesting little project. +STEPH: I'm fascinated by how that would feel as a user because if I'm hovering over a link, I'm thinking through my specific navigation habits. So if I'm going to a link, like, I don't hover very long. I don't think of myself as a hovering internet user. [laughs] I'm probably going to click on it right away. So I wonder if I would still feel that same speediness versus...yeah, I am interested in the metrics if they have something around like...I don't know why they would know this or have this, but like, most people hover for this long. And so then it speeds up their feeling of the page load. I'd be interested in that. +CHRIS: I like the idea that you're bracketing yourself into the quickest click of a link in the west. I'm looking around on their website, seeing they have a quote from NewEgg at the top, which is, "We implemented Quicklink and saw a 50% increase in conversions and 4x faster page transitions." So it sounds like I'm reading an ad for this now, which I'm not because it's a free project. So you can use it or not and pay the $0. They have a demo, and then they have a measure page. So I think you can actually get to...I think they're just talking about how to measure it. But I've definitely seen another page where you can click on a link, and it will tell you what was the difference between hover and active when you actually interacted with it. And it turns out the bounding box for a link is bigger than what you see. And you're often moving your mouse not entirely to the center, but you're not just getting to the edge of it and clicking. And so that period of time where you're moving your mouse onto the link, there's actually often a couple of hundred milliseconds, which is enough to really make a difference if you've got a speedy site. You can take what feels like a couple of hundred milliseconds and turn it into nothing. +STEPH: All I can think of right now is the image of a little mouse that's moving closer to a link with the Jaws' theme song playing. So it's ta-dum ta-dum. [vocalization] And this whole time, Quicklink is getting ready to then load as soon as the mouse reaches that perfect zone to then start loading. That's what I'm getting is Jaws and Quicklink. [laughs] +CHRIS: I like the...it's not personification, but it's jawsification that you're doing of this JavaScript library where it's like, I just imagine them hovering on the side really watching intently. But on the sites that I've used it, it does make a noticeable difference. I feel the difference even with very active clicking. +STEPH: That sounds really neat. I'll have to look into it. Maybe I think I'm the quickest click in the west. That's very hard to say. And it turns out that I'm actually quite slow, who knows? +CHRIS: You might just be average; that’s fine. +STEPH: No way. +CHRIS: Most people are, mathematically speaking at least. [laughter] +STEPH: Not possible. I'm certain that I'm special. I hope listeners get a kick out of my oddities, [laughs] my very honest self that's coming through on the mic today. +CHRIS: We're all a little special. But pivoting one more time… +STEPH: That means no one's special. [laughs] +CHRIS: Are you just doing the quote from Incredibles, or are you actually trying to say that? [laughs] +STEPH: I wasn't intentionally quoting The Incredibles, but I did just watch that movie recently, and you're totally right. I am quoting The Incredibles. +CHRIS: This is our second episode in a row then with a Pixar theme, which is always fun. But pivoting ever so slightly, I think our final pivot for the episode, we have a listener question today. So this question comes in from Matt Swanson, and he is asking about consulting first versus software first. So his question is, "One of the biggest turning points in my career was realizing that software consulting is, well, consulting. Do you think about your work as 'consulting first' or as building great software first and good experience for your clients will follow naturally?" So, Steph, what do you think? +STEPH: I liked this question because it really made me stop and think about the differences in how I approach my client work. So I will say that I do think it varies slightly for each client, but most of the time, I do think of my work as first building great software. And then, once I've had time to understand how the team works and then identify opportunities for improvement, then I'll put on my consultant blazer and start scheduling meetings. I'm just kidding. I don't like meetings, so I don't do that part. But I do find that most of my engagements are looking for initially a strong developer to help contribute to the team and mentor. And then, I find that a lot of my consulting skills can then start to shine once I have that opportunity to build trust and then share outsider views with the team and then coach them in other directions. So I do take the approach of building great software first. Although this question really made me pause and think about it because I do think of the consulting and building software as so tightly coupled. It's a little hard for me to define when am I switching from my developer hat over to more of my consulting hat. +CHRIS: Yeah, I think my initial reaction to the question was similar where I don't view these as two different modes that I'm fundamentally operating in. It's a continuum, or it's like a two by two grid thing, and I'm sort of moving around between the different spaces, but there's always a little bit of both. And I think if I were to answer the question directly, I would lean towards building great software. That's always the thing that I'm trying to do but often that requires some other more human-centric interactions. So having a difficult discussion around a feature and why we may not reach a deadline that we're going for or talking about ways in which the workflow is not necessarily going as well as it could, and we're ending up losing information along the way or different process things, all of that is a little bit removed from building great software. But at the same time, it's...actually, this is true of me now. I'm not technically a consultant anymore. I've stopped doing that, and I'm now full-time at an organization. And I'm not imagining my role changing fundamentally. I was consulting with them. I've now come on as a full-time employee, and I'm still viewing my work as very much the same thing. Maybe that's because I spent so long consulting that that's sort of the mode that I think of as how I work. But I think yeah, it's not necessarily two different modes. It's definitely a continuum that I'm operating across. +STEPH: Yeah, I think that's why for me, it often varies. I like that word that you're using around how it's a continuum and that you're constantly sliding back and forth between one mode and the other. And if I think back to earlier days when I was working specifically with product teams before then, I joined thoughtbot and trying to think, well, what are some of the differences? How would I define what is more of my consulting mode versus then the building great software mode? Although I think the latter does encompass the consulting skills. But thinking back to when I was working on a product team, I found...and this may also just be because I was new in my career. But I found that I often referred to whoever was more senior on the team to handle a lot of those more human-centric topics, as you phrased it earlier. So if there was some communication that we needed to share in regards to why we were delayed on implementing a feature, if we needed to run a retro, if there were some meetings that needed to be scheduled, it always felt something like, oh, this leader of the team is going to take care of that. I am more in the development role, so I will do my job but then defer a lot of that to them. +And then since joining thoughtbot with the way that we operate, I feel like I have more ownership in the process, and I want more ownership in the process. I want to be someone that is very aware of what are the specific goals that we're looking to reach? What are the deadlines? What's behind those deadlines that's encouraging us to push hard? And then also understanding how is the team functioning? What's something that we could do to improve the team's efficacy? Is the team happy? Are there areas there that we could improve? So I think for me, that is one of the core parts where I feel like I transitioned from being more focused on development to being more...you know, I don't have a great word for it. I often referred to it as being more of like a product owner. And since then, I feel like I have more ownership around the code that I'm working with and the team, and then the processes and the decisions for the product. But I actually don't have a great word that encompasses that sense of I want to be part of this and help make decisions and look out for everyone else that's around me. Does that resonate with you? Do you have any particular way that you would describe that or a word for it? +CHRIS: I don't have a specific word for it. In my mind, this is just how we build software. But I think that that speaks to the culture that we grew up in as software developers. It's so strongly in our minds to think this way. A thing that we've talked about in the past is encouraging software developers to observe the sales demo, to see what it looks like when we're talking to end-users, or, similarly, to sit on customer support calls or listen to user interviews or things like that. And the reason for that is we want...I believe strongly that developers will do better work if they understand the context of the end-user of the application. But I think fundamentally, that sort of loads things up in someone's mind that might encourage them to push back or to suggest a different way of working down the road, and I think that's a good thing. I think every software developer should have some amount of that going on. And so that idea that consulting is this other thing that you sometimes do I feel like that stuff fits under the umbrella of consulting and, therefore, I think it's just part of how we build good software, but maybe it's a nomenclature thing, and I'm just thinking about it wrong. +STEPH: Well, I want to pull at that thread a little bit because I was having that internal discussion with myself when I was thinking about this question is in regards to that being more aware of how the other teams are working to then help inform our decisions around the software that we're helping build, and implement advocating for a new process or advocating for how to build great software, is that consulting? I think you and I fall more into the camp of that's just how you build great software is; you have to be part of those decisions to be able to have more insights into the work that's being done. So I don't know if I could even really classify that as a consulting skill. +CHRIS: Yeah, that matches my thinking. There is a distinction between consultant and contractor that I'll sometimes push on a little bit where I see consultants as being perhaps a bit more strategic and not necessarily being handed the work to do. I see that perhaps more on the contractor end. It's like, "We need a website built. Here are the specs. Here's the design mock-up. Please build it," and that's that. Versus a consultant being like, "We need a website, but we're not even sure exactly what that means. Can you help us think about the features and prioritize? Do we need a mobile app or not?" And a consultant potentially working more in that space of helping to determine what is the work that we're even going to do. But again, that's a question of like, how do we build good software? We have to answer those questions, and maybe not everyone on the team is always answering those questions. But the more people feel empowered to and feel like they've got the context to be able to make those sorts of at least suggestions around those sort of decisions, I think the better. +STEPH: Yeah. I agree with the distinction in regards to being a consultant or a developer versus being a contractor because one definitely feels more removed from that decision or with that team collaboration process where you are more handed work, and then you implement that work, but you don't necessarily ask questions and be like, "Well, what are the benefits of adding this particular feature? Are we tracking to know that we've added the right thing?" those types of things that I would naturally include as part of my work. Versus if you're doing more of the contract work, then maybe you just implement and then don't ask those questions. Thinking back to then, what's different about being a consultant versus then doing development work…and I'm totally sidestepping all the financial stuff here. Like, if you're a consultant, then your world may be very different in terms of how you are acquiring jobs and then your marketing. So I am sidestepping that big conversation there but then focusing more on your day-to-day, how it may be different. +And the times that I do feel that I'm wearing more of my lower-casey consulting hat is where I am joining teams that have a very specific goal that they have brought thoughtbot on to help with. So maybe there is a particular certification that they want their software to achieve, or maybe they're looking to level up their team and a particular tech stack, maybe it's Rails, maybe it's testing. And that one feels more focused on I am here to help provide an outsider opinion, to help evaluate your team, to help you provide advice, to communicate more with leadership that's on the team so then they know how things are going. That feels more like a consulting engagement that is less focused on building great software. But I feel like that often still starts with we want that stuff, but we also still want great software. So I always feel like I'm in both, and I really can't be as effective at the consulting part without actually working with the team and understanding the struggles that they're going through. So I still feel like they fit very hand in hand, but I do find that there are certain engagements that do require more external communication versus the others are often more internal with the team that I'm helping build software with. +CHRIS: Well, I like that as a framing, the internal versus external communication and sort of the ratio of those. That's an interesting one. +STEPH: To me, that's really what then sort of differentiates the consulting versus the just focused on building great software is if I'm doing more external communication, I'm focused less on the building part of the software but more on the guidance part. +CHRIS: Yeah, I think that's a really good encapsulation or perhaps a way to differentiate the two ends of this. But I think both you and I probably feel that this just varies project to project. In some cases, we need more of what would fall into the consulting bucket, and other days, it's just nope, we got to go in. We got to implement. We got to build a bunch of features. We've got to get to the MVP launch and whatnot. And that often requires a little bit less on the consulting or the external communication side. But I think it's a case-by-case thing. And it's not that I think of myself as one or the other; it's I'll scale up or down as necessary based on the context of the situation. So I am both, I think. +STEPH: Two for one, consulting and building great software. [laughs] +CHRIS: One-stop shopping, everything you need. +STEPH: So, I do have a couple of examples that I can provide that may provide some insight as to how we view consulting a little differently than necessarily focusing on implementation. I feel that I'm still reaching for that separation between consulting and developing. So I'm going to focus on the external communication and the implementation. I feel like those are the two areas that are trying to be divided in this particular question. But I do have some examples from thoughtbot discussions around consulting. So every so often, we get together at thoughtbot, and we have these internal discussions where we talk about the different consulting challenges that we have faced. And it's a really nice time where we get together, and we may discuss ongoing active consulting challenges and questions that we have, or it may be scenarios that have happened in the past. And so then we present that scenario to groups, and then we break off into smaller groups, and then everybody has an opportunity to talk through how they would react, what advice they would give, how they would approach it. And I have found those sessions to be incredibly helpful, but I think it could be fun to share some of those examples. Folks can think about them as to how they would react to them. But I think this helps highlight why those consulting skills and then also building great software are so tightly coupled together. +So this first example focuses on building MVPs. So let's say that you're working with a client, and you've been focused on building an MVP, and the engagement is coming to a close in a few weeks. But the client is disappointed that there is a particular feature that they're really excited about that's not being included in the MVP, and they'd really like to know why that particular feature was cut. And they are worried that that will actually cause the business to fail if they don't have that feature in the MVP. So that's something that often comes up when we are focused on scoping MVPs to make sure that we are aligned with the client team to understand what is very important for the MVP and what can be a fast follow. And that can be a thorny one, especially if someone feels emotionally attached to a feature that is something that can be tricky to navigate. And how do you help the team reach a consensus that this feature really does need to be in the MVP, or it's okay that it doesn't need to go out now, and it can be in a future iteration? +And for another example, this one is more focused on communicating the progress of particular work and how it's going. So you can imagine this scenario coming from the client saying that they have been working with you for a few weeks and you've made good progress, but it feels like the last week things have stalled. And they don't understand why a particular feature is taking longer than expected to ship. And they haven't had any communication from the team regarding what's taking that feature a longer time to get out. So, again, these are just some scenarios that you can think through and imagine how then you would respond or handle each of these situations. But I think both of those are really great examples that focus on the more consulting aspect of our work and then when we need to have more external communication with teams, so then they feel confident that we are developing great software. +CHRIS: I think this is the first time that I've observed us giving homework to the listeners. But I think one thing that I'll highlight is we are talking about this in the context of consulting or being a consultant. But I think both of those examples that you gave, and more generally, most of these sort of conversations, actually apply pretty equally to working within an organization as an employee. You're still working on projects. You still have deadlines. You still need to ship things. You maybe aren't shipping as quickly as you need to; that maybe needs to get communicated to both internally within your team and externally within your larger organization. So yeah, I think these are broadly applicable, and I think, yeah, rolling them around in your head, let us know if you come up with any great solutions. +STEPH: And if folks are interested in these types of scenarios, then I'm happy to share some more of them. I could share them on Twitter or anywhere else that folks find helpful. But I really like that nuance where I feel like is a nuanced discussion between building some great software and then those consulting skills. So thanks, Matt, for submitting such a great question. +CHRIS: And as an aside, just to give a little more context on Matt, he runs a blog called the Boring Rails, which,, if you are not following it, it is a wonderful, straightforward summary of small, useful tidbits of information in the Rails world that are boring, but that's part of what we love about Rails. So I highly recommend that as well, and we'll include a link in the show notes. But yeah, thank you so much, Matt. And on that note, shall we wrap up? +STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. +STEPH: And I’m @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris gives some small updates on working with Svelte. He really likes Svelte so far. Svelte's great. Modals are complicated. He also talks about using a little JavaScript library, called Quicklink. Steph talks about sending data to a third-party system and using feature flags to help deprecate some code.

+ +

Finally, they both riff on a listener question on consulting. Said listener asked, "Do you think about your work as 'consulting first' or as 'building great software first and then good experiences for your clients will follow naturally?'" Find out their take and give us your own, here on this episode of 'The Bike Shed!'

+ + + +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, happy Friday. How has your week been?

+ +

CHRIS: Happy Friday. My week's been great, yeah. I've been writing a lot of code, moving things around, planning some features, and all that fun stuff that goes into building an app, so I'm enjoying that process. I'm also halfway through listening to your recent episode with Nate Berkopec, which was absolutely delightful, well, at least the first half that I've listened to so far. I assume the rest will continue to be absolutely delightful, but it does remain to be seen. So I'll report back next week when I've listened to the whole thing. But yeah, that's great. And I'm glad that Nate got to come on, and we got to share a little bit of his story as well.

+ +

STEPH: I like how clear you are in terms of like, "The part that I've listened to so far is great, but I reserve judgment until I've heard the rest of it." [chuckles] But that's awesome.

+ +

CHRIS: The thing about being a developer is it has broken my brain such that I am overly specific all the time because I just argue with a computer all day. It's what I do. So then I start talking to humans, and I'm like, wait, I should probably behave differently now. And I got to unwind some of those computer fights. But anyway, and let's see, small updates working with Svelte, really like Svelte. I'm leaning into it more and more and embracing...I think I'm starting to understand the aspects of it that I really like. And one of the things that I really like about it is that it is somewhat underpowered. And what I mean by that is working on React applications, I find that I can do some fancy stuff, and I can express it really well in TypeScript. And I can really go for it and create some components that are wildly variable and configurable and can take in any combination of props and do all sorts of things. And I can slice out tiny, little components and do all of this. When I'm doing that, I enjoy it.

+ +

But in Svelte, I have a little bit less power in my control. Svelte is closer to HTML, CSS, and JavaScript fundamentally. So you can make components, and I really like that. You can bundle up the pieces of functionality and display and formatting, and all of that, but it's not quite as powerful. It's not quite as expressive. And I've actually found that to be a useful limitation, which is an interesting frame. It's not something that I thought I would say, but I'm finding that the code that I'm authoring in my editor is so much closer to the code that's actually going to be presented to the end-user. That is really useful in my mind. I find that to be really valuable. There are small things like in Svelte; you can actually say class equals when you're trying to define a class on an HTML element. It turns out I really like that one instead of having to say class name or similarly HTML for. There is a handful of them in React that you have to change the name of. So if you copy a snippet of HTML from the web, and then you dump it into your editor, if you're working in React, you have to change a bunch of stuff. It doesn't work right away. And it's a small thing, but I found that I really seem to care about it. But there's the “it's nice that it just works” version. But I feel like there's also an actually practical, meaningful edge of it is so much closer to the thing that's actually going to be in the browser, and I like that.

+ +

STEPH: I liked the phrasing that you used just a moment ago where you said, "Useful limitation." Since I haven't used Svelte myself, one of my understandings is that you like the fact that it is that low JS in terms that we are introducing this framework, but it's not as heavy-handed as React or another framework that you could retour. But then you also said you're running up to areas where you feel like you're missing some stuff from React, is what I'm hearing. Is there a particular feature, or do you have a concrete example to help me understand some of the stuff that you are really missing?

+ +

CHRIS: It's not so much that I feel like there are specific features missing, but as a pointed example, I am not able to pass in the DOM element that I would like the component to render as. That's a weird thing, but often, component libraries will do this. So you have a button component, but the button can render either as a literal HTML button element or an anchor element. And you can pass in as equals and then button as the string there. And in React, you can do that, and then you can actually do some type inference across it and say, "Okay, now the rest of the props that you can pass in are button props.” And if you pass in as equals a, so implying that you want it to be an anchor or a link, then it will constrain you to the link properties and say, "Oh, you must have a HREF now." That's really cool that you can do that. It's also super complicated, and the TypeScript representation of it, while it works, is very, very complicated and the types of errors that you get. The complexity of what you can build with React is really interesting. But I worry now that I've spent a good bit of time in Svelte, I worry if it's overpowered. I've worked on plenty of applications where the system as designed in React, all the set of different components is very, very complicated. And you sort of have to learn that system in order to be able to work in it, whereas in Svelte, you just start, and you're writing in HTML and CSS. And then, as you need more fancy stuff, you can slowly layer it in. And to be clear, Svelte definitely has plenty of power.

+ +

This past week, actually, we were working on a modal component, but we were really focused on accessibility, which is probably a good thing that you should do, but it turns out modals are very hard to get right. The dialogue component that should exist in HTML is not complete, and it's not a thing that we can rely on. So we have to do certain things ourselves. So the idea of focus trapping when the model pops up, we need to say, oh, okay, the focus should be trapped inside of here, so you can tab forward and back, but it's going to stay within that modal component. There's actually a way that you're supposed to portal it. So you move it outside of the documents so that you can make the rest of the document...I want to say aria-hidden is the property, but you're basically saying the entire rest of the document that's behind this modal component should be inert to a screen reader essentially or invisible to a screen reader while the modal is up. And doing all of those sorts of things is super complicated. After you close the modal, you're supposed to refocus the button that opened it, the triggering element, and that's a tricky one where you have to pass down a reference to something. And that was all very expressive, actually, very straightforward in Svelte in a way that I was really impressed by. So it definitely has all the power that you need but not any more than what you need. Or there is a small line of it's just right.

+ +

STEPH: So we should just scrap modals. That's one of the things that I'm hearing from you. So I just want to clarify because I do feel a little confused because in the beginning, it sounded like you were saying that Svelte is wonderful, but you do feel like you're missing a little bit of functionality there that you do receive with other frameworks like React. But then that last thing you said where “it's just right” sounds like it's the Goldilocks. So I'm a little confused as to exactly how you're feeling about Svelte in the moment.

+ +

CHRIS: Yeah. I'm probably not being as clear as I should. I am a big fan of Svelte, so as the first answer, a big fan of Svelte. I'm recognizing that, strictly speaking, it is somewhat less powerful than React. But I'm also trying to say, perhaps failing at saying, but trying to say that I like that, that I'm finding its constraints are useful. React can do a ton of stuff. You can represent a real impressive array of component functionality and have components that take 17 different props that covary in different ways, and it's very complicated. And I've worked on plenty of React applications where I just have to stare very hard at the component library for a while. And I'm like, ugh, I still don't know how this works. And it's this custom bespoke language where Svelte feels like it is much closer to the thing that we're actually doing, which is rendering HTML and CSS and JavaScript and whatnot, and I like that. I'm finding that very useful. I'm finding that lack of power not to be a hindrance but, in fact, to be useful.

+ +

STEPH: Hmm. Okay. I like that last part. Yeah, there are often times where I feel like the less powerful something is, even if it means a little extra work on my end but it's clear as to the work that's being done...I'm going to take it back a couple of years to when I was first learning Elixir because that's how I felt jumping from Ruby to Elixir and from Rails to Phoenix, where suddenly I felt like I had more clarity. There were some things that I had to do more on my own, but I felt more clarity as to what exactly was being done versus Ruby and Rails doing a lot on my behalf. So I can certainly relate to that.

+ +

CHRIS: Yeah, I think that captures it well, that the expressive power of React can perhaps lead to somewhat more confusing code, and the small handful of cases where I need to be slightly more verbose in Svelte I actually find really useful. Like, Svelte is making sure that I'm writing components that are clear and easy to work with, but it still has all of the power that I need, and I can do everything I want in it. And yeah, overall, just yeah, Svelte's great. Modals are complicated. And that's my story. But yeah, that's a little bit of what's up with me. What's going on in your world?

+ +

STEPH: Before we switch gears. I want to add on a little bit more to what you just said because something that I have noticed with me is that the longer that I've been a developer, the more I want that lower-level control and understanding as to what is happening. And it sounds like that is very much what you're saying that you're enjoying with Svelte is even if it does require a little more extra effort, that then at least I have that ability to exactly control what's happening versus if you're using higher-level obstructions, you're stuck with the API that's been designed for you. And that API works 98% of the time, that's wonderful but then that 2% of the time you're in trouble. So I've definitely noticed that trend, that over time, I want that lower-level control over everything that I'm working with and building, although not all the way to C, let's not go that far.

+ +

CHRIS: I mean, there's Assembly underneath C. We can keep going, and we can just manually manipulate transistors as well if we really want to get after it. [laughs]

+ +

STEPH: Next week on The Bike Shed. [laughs]

+ +

CHRIS: Much, much higher level of abstractions are interesting to me, but yeah, there is a sweet spot. Svelte seems like it's the one for me.

+ +

STEPH: Nice. So then switching back to what's new in my week, it's been a little bit of a weird week in terms of there's been a lot of focusing on sending data to a third-party system. So we had a lot of data that they needed in their system. So I have been focused on running a number of processes that are then sending that data over and then essentially babysitting processes, making sure everything is going smoothly. Also communicating with their team to understand okay, what's being received? Do we have any errors? Is there any sort of miscommunication between our systems, and that's why we're needing to resend this data to you? So it's been very different in terms that it wasn't a typical feature development week. It was more, hey, I sent you some data. What did you receive? And then let's fine-tune both of our systems on each end, which that part I always enjoy. As soon as I can get to that level of collaboration with someone, I very much enjoy that part because initially, it felt like a stressful task of like, hey, we've got this giant CSV. We need to process and send data. But then as soon as I have someone else to work with, then I'm like, yeah, okay, this is great. They can update their system. We can fine-tune ours as well in case there's something that's not communicating properly, and that part I really enjoy. I really enjoy collaborating with someone else so then we can both improve our systems together, so that part was a little different.

+ +

But the actual weird thing that I did this week is we have feature flags, and we are using those feature flags to help us sunset and deprecate some code. So we have a controller path that is pretty gnarly. It is one of the more dense, difficult areas of our codebase to understand. And so we are refactoring it and creating a new green space for it so we can start to pull in some of that behavior and then also refactor as we go. So we essentially have class version one, and we now have class version two, which is always something. And we want to be able to feature flag this because, with our deployment workflow, we need the ability one; we want to be able to switch back quickly. So that way, if something goes awry, we can switch back to the original code if we've made some misassumption in our V2 version. And then we want to leave that on for a while to make sure things are running smoothly, and then we can go back and actually remove that class.

+ +

But then the question came up is like, well, if we have these two files, how do we tell the team not to touch this particular file but only contribute or make a change to this other file? Because we have a sizeable team, and we work in different time zones. And there is a very reasonable answer that we communicate with the team that other folks are aware because they've seen the PR. There's a whole self-discipline of we review PRs and make sure stuff wasn't changed. All of that stuff is fine. It's reasonable. But I wanted to do something a little less reasonable [chuckles] that would still fail loudly in case someone changed a file. So the question was presented is there a way that we could fail loudly if someone changed this file? And there's a fun thing that we'll do at some of our daily syncs where someone will say, "That's a good idea. I have a bad idea." There's a fun thing that happens at our daily syncs where someone will often ask a question, and someone will provide an idea. And then someone else will say, "That's a good idea, but just to throw it out there, I have a bad idea. So let's just explore all of the ideas." And one of them was like, "Could we write a test around this? So if the file hash or something about that changed, then could we alert the team so then we know that this file changed and you're not supposed to change this file?" And essentially, having that discussion of like, well, then we're reimplementing Git because we're trying to track file changes. That seems like a bad idea but still a novel one to talk about for a few minutes.

+ +

The implementation that I landed on and then shared with a person that's working on this is you do have the ability with Ruby, the file class itself; you can open a particular file. And for this one, select class one, and then you can use the function mtime, which returns the modification time for a file. So you can check the last time that a file was changed. So I wrote a test that says that "This file was last altered at…" and I grabbed that file's last altered at time with mtime. And then, I compared that to a particular DateTime. And then that DateTime could be any DateTime in the future once we deploy this class version two, so we don't expect that file to be altered. So this test will always pass until someone changes that file. And then Ruby is going to say, "Oh, your time is now greater than that other time you said." And so it's going to fail, which actually works pretty well. It's not as ugly as I thought it was going to be. [chuckles] As to whether it's a good thing to add to the codebase, I don't know, but it was a fun thing to write.

+ +

CHRIS: I like it. I've definitely written things like that in the past, and I guess; therefore, I'm biased. [chuckles] I'm a fan of this sort of thing. But when you can take that group knowledge that is just shared in communication or via code review and you can capture it in the code, especially if you can do it in a stable, robust way…In particular, the first thing that comes to mind with that is like, well, are there going to be different representations of the timestamp on your system versus CI? Will that ever change over time? Like, Linux versus OS X or things like that. I actually have reached for Git in situations like this in the past. So, in particular, the one that I found myself doing a few times is trying to instrument code generation. So say we're working with Apollo, and we are generating the TypeScript types associated with a GraphQL request. I wanted to put something into CI to say, "If we haven't committed those changes," because we're supposed to be committing those files alongside, "then warn." And so the idea was take a snapshot of what things look like right now, run the command that does the code generation, and then check after that.

+ +

I've done different versions where it's like, hey, Git, is the working directory dirty at this point? That's a version. I've also done one recently where I got the checksum of the file but again, asking Git. Because you're totally right that a lot of this...this is what Git does, and we don't want to rewrite Git. But I did feel okay reaching out and being like, "Hey, Git, can you help me understand the word?" But I like these sorts of things, particularly if you can do it in a way that won't ever require someone turning it off. I don't know if you've worked on projects where ESLint is enabled, but every third line has an eslint-disable-next-line. And it's just like, well, we have a bunch of rules, but we ignore them in a lot of cases. And those sort of...the like trust scenario with an automated tool I think is so important. If it's ever giving you false positives, false negatives, whichever it is, then it immediately, I think, loses so much of its utility. But if you can do it in a way that is stable and robust, then I am a huge fan.

+ +

STEPH: Well, we'll see if the person decides to include it in their PR or not. But I do like that idea of where we can take away the idea that we're going to catch it if it changes in a PR because then we're just going to end up in a bad place that if we fix a bug in the class V1 but don't apply that to class V2, we're just going to be in a bad spot. And it's likely we'll forget about it when we go back to then delete class version one. There is something that you said that has reminded me of a very small change that I made to my process, but I feel like it had a big impact. And it's specific to working with feature flags, how often you'll have your tests where it's like if feature flag is on, this behavior should happen, if it's off, this behavior. And I often would wrap my test in the default path where the feature flag is off, and then I'd have my other if the feature flag is on; this is the behavior. But as we are migrating with the intent that this feature flag at some point in the near term future is going to always be on, so we know we're going to come back and remove all of the other code. I switched those two paths and treat the default happy path as the new if the feature flag is on; this is the new world. So then when folks are going back to say, "Okay, I just need to delete everything that represents when the feature flag is off," suddenly, it's just very easy to find that context to say, "Hey, feature flag is off and then boom, delete all of those tests." And that's been really nice.

+ +

CHRIS: I really like that lens of designing or coding for deleteability. How easy is it to just rip this thing out? It's one of the things that I love about Tailwind, or one of the purported facets of Tailwind that makes it really nice is when you're looking at a given template, you can just rip it out. You don't have to worry about it because there's no associated CSS that you need to think about because the CSS is sort of generated available, whatever you want to call it with Tailwind. But I really like that idea of making it easy to delete stuff. Because it's so easy to just have your codebase slowly grow over time and look at files and be like, "I don't know if we're using that, but better to be safe." Cool. I'm excited to hear if that does land in the codebase and how folks respond to it. What did you phrase the message as? So if there's a test failure, did you give a particular like a special RSpec formatted message to be like, "Hey, friend, you're not supposed to touch this file. I know you're well-intentioned, but…" or is it just like, "Failure, bad. Mtime is different." Which end of the spectrum are we on there?

+ +

STEPH: I love that you asked that question because I almost went down that path, and I was like, well, this should really have its own custom failure message because it's odd enough that I want to tell someone a little bit of a story when it fails. But I didn't because this was something that one; I just want to see if I could do. So I initially started looking at standard rb in RuboCop because at first, I was wondering if this was something I could solve via linting if it was something that RuboCop…if I could say, "Hey, RuboCop, if you notice that this file changed…" I didn't know if they had a hook into Git as they're looking for files to analyze. So I first leaned on RuboCop standard rb, which essentially then uses RuboCop under the hood, and I didn't find anything there. So then that's when I was like, okay, maybe Ruby has something, and that's when I found the file mtime. So at that point, once I'd gotten the test to pass, I'm like, you know, this is good. There's a very nice, friendly test description that goes along with if this fails; this is the reason why. But I do think that would be like cherry on the top addition to the test to have a very nice error message that goes along with this. So if I were the one that was adding this to the codebase, I would take a few more minutes to do that myself. It definitely felt like one of those moments where I had gone far enough into an experimental mode, and I felt like I had just reached that point where this is useful, and I want to share it with the person who's actually working on this. But then I pulled back going further because I'm like, I don't actually know if they want to use this and if they're going to implement it. So it felt like that right friendly balance of like, here's something that works. Feel free to use as is, make it better, don't use it, totally up to you.

+ +

CHRIS: Yeah, I think given that context, that's definitely I feel like a good line to draw, not like, “Here's fully completed code that you can now just drop in. I did all the work, but here it is.” Versus like, “Oh, here's a kernel of an idea if you want, run with it, but if not...”But yeah, [chuckles] if you went to the length of writing a nice paragraph summary message to the end-user, that feels like you're really taking over the show. So cool. Well, yeah, interested again to hear how that goes and hear if it does, in fact, stop. That's the other thing. It's like, if it never actually fails, then everybody was just fine with the human process. But I'm intrigued to see how many times it actually does stop unwanted modifications of the file. So that's an interesting measure to track.

+ +

STEPH: Yeah, that would be an interesting thing to track because if we do have it, then we may have less visibility into knowing if it failed because then someone will see it fail locally, but then we will have prevented it from getting to that PR state. It is one of those “did someone not change it because we added the test, or could we have skipped that process?” It feels like one of those nice safety measures, but that would be a fun thing to measure, I agree.

+ +

CHRIS: Yeah, especially if it's a small change; in this case, I think it's totally worth it. But now, as I said it, I didn't mean it to be more of a thing. But now that I think about the question, I wonder if all tests should fail at some point. Like, all tests have a cost, both in terms of development and then thinking about them in runtime and all of that. And a good test is one that eventually fails because you change the system in a way that broke some constraint. And so, therefore, I'm now asking the question, like, should every test fail at some point? Are tests that only ever pass actually not that useful? I don't think so. Now there's a story running in the back of my head that's like, I kind of want to look at the CI stats. And feature specs will occasionally fail for unrelated reasons. But unit-level tests that never break, that never fail and catch something that was broken…I don't know that I actually believe this, but I'm just intrigued. As I asked the question, I was like, huh, should all tests fail? Sort of like one hand clapping kind of thing, anyway.

+ +

STEPH: I like the question, or it's making me stop and think because my initial answer is yes, as long as it's failing for a meaningful reason, as long as it's not a flaky test or something along those lines. But otherwise, as you're working on the system and you're making changes, then I'm inclined to say that yes, every test should fail at some point. But I agree, if we're getting into existential test area, then I don't have concrete feelings about this yet.

+ +

CHRIS: Yeah, and I feel like it's one of those sorts of questions. So pivoting off of that ever so slightly to bring us to something much more practical, I have a tiny utility that I want to chat about. And then I think we have a listener question that we want to discuss. But the utility, I think I brought this up on a previous Bike Shed episode, but the tool it's a little JavaScript library, but it's called Quicklink. And so the heading is instant next-page navigations. And so the way it works is it's just a little snippet of JavaScript that you'll include from a CDN, or you can NPM install it or any number of ways. But it's a tiny, little one kilobyte JavaScript thing that basically what it does is it attaches to every link on the page whenever you use that link. So you click on it or if you're on mobile if you tap, or however you're interacting with it, if it's an internal link, so not external to your site and not going to a different domain, but if it's internal to your domain, what it's going to do is it's actually going to prefetch in the background as you hover on that link. So it's going to say, "Hover is a good indication of intent to follow this link. So we're going to prefetch it in the background." And then when the user actually subsequently clicks it, which is often a couple of 100 milliseconds later, that's often enough time actually for the page to load in the background. And then, when they click the link, it almost feels like instant navigation. There's a similar thing that happens based on when you tap and when the actual firing of the link happens on mobile. So there's another delay that they can take advantage of there that's not quite the same as hover. But overall, it just takes basically any webpage, any website, and makes it feel very much faster. And it's cheap, easy, just kind of works. I really like it. It's a very interesting little project.

+ +

STEPH: I'm fascinated by how that would feel as a user because if I'm hovering over a link, I'm thinking through my specific navigation habits. So if I'm going to a link, like, I don't hover very long. I don't think of myself as a hovering internet user. [laughs] I'm probably going to click on it right away. So I wonder if I would still feel that same speediness versus...yeah, I am interested in the metrics if they have something around like...I don't know why they would know this or have this, but like, most people hover for this long. And so then it speeds up their feeling of the page load. I'd be interested in that.

+ +

CHRIS: I like the idea that you're bracketing yourself into the quickest click of a link in the west. I'm looking around on their website, seeing they have a quote from NewEgg at the top, which is, "We implemented Quicklink and saw a 50% increase in conversions and 4x faster page transitions." So it sounds like I'm reading an ad for this now, which I'm not because it's a free project. So you can use it or not and pay the $0. They have a demo, and then they have a measure page. So I think you can actually get to...I think they're just talking about how to measure it. But I've definitely seen another page where you can click on a link, and it will tell you what was the difference between hover and active when you actually interacted with it. And it turns out the bounding box for a link is bigger than what you see. And you're often moving your mouse not entirely to the center, but you're not just getting to the edge of it and clicking. And so that period of time where you're moving your mouse onto the link, there's actually often a couple of hundred milliseconds, which is enough to really make a difference if you've got a speedy site. You can take what feels like a couple of hundred milliseconds and turn it into nothing.

+ +

STEPH: All I can think of right now is the image of a little mouse that's moving closer to a link with the Jaws' theme song playing. So it's ta-dum ta-dum. [vocalization] And this whole time, Quicklink is getting ready to then load as soon as the mouse reaches that perfect zone to then start loading. That's what I'm getting is Jaws and Quicklink. [laughs]

+ +

CHRIS: I like the...it's not personification, but it's jawsification that you're doing of this JavaScript library where it's like, I just imagine them hovering on the side really watching intently. But on the sites that I've used it, it does make a noticeable difference. I feel the difference even with very active clicking.

+ +

STEPH: That sounds really neat. I'll have to look into it. Maybe I think I'm the quickest click in the west. That's very hard to say. And it turns out that I'm actually quite slow, who knows?

+ +

CHRIS: You might just be average; that’s fine.

+ +

STEPH: No way.

+ +

CHRIS: Most people are, mathematically speaking at least. [laughter]

+ +

STEPH: Not possible. I'm certain that I'm special. I hope listeners get a kick out of my oddities, [laughs] my very honest self that's coming through on the mic today.

+ +

CHRIS: We're all a little special. But pivoting one more time…

+ +

STEPH: That means no one's special. [laughs]

+ +

CHRIS: Are you just doing the quote from Incredibles, or are you actually trying to say that? [laughs]

+ +

STEPH: I wasn't intentionally quoting The Incredibles, but I did just watch that movie recently, and you're totally right. I am quoting The Incredibles.

+ +

CHRIS: This is our second episode in a row then with a Pixar theme, which is always fun. But pivoting ever so slightly, I think our final pivot for the episode, we have a listener question today. So this question comes in from Matt Swanson, and he is asking about consulting first versus software first. So his question is, "One of the biggest turning points in my career was realizing that software consulting is, well, consulting. Do you think about your work as 'consulting first' or as building great software first and good experience for your clients will follow naturally?" So, Steph, what do you think?

+ +

STEPH: I liked this question because it really made me stop and think about the differences in how I approach my client work. So I will say that I do think it varies slightly for each client, but most of the time, I do think of my work as first building great software. And then, once I've had time to understand how the team works and then identify opportunities for improvement, then I'll put on my consultant blazer and start scheduling meetings. I'm just kidding. I don't like meetings, so I don't do that part. But I do find that most of my engagements are looking for initially a strong developer to help contribute to the team and mentor. And then, I find that a lot of my consulting skills can then start to shine once I have that opportunity to build trust and then share outsider views with the team and then coach them in other directions. So I do take the approach of building great software first. Although this question really made me pause and think about it because I do think of the consulting and building software as so tightly coupled. It's a little hard for me to define when am I switching from my developer hat over to more of my consulting hat.

+ +

CHRIS: Yeah, I think my initial reaction to the question was similar where I don't view these as two different modes that I'm fundamentally operating in. It's a continuum, or it's like a two by two grid thing, and I'm sort of moving around between the different spaces, but there's always a little bit of both. And I think if I were to answer the question directly, I would lean towards building great software. That's always the thing that I'm trying to do but often that requires some other more human-centric interactions. So having a difficult discussion around a feature and why we may not reach a deadline that we're going for or talking about ways in which the workflow is not necessarily going as well as it could, and we're ending up losing information along the way or different process things, all of that is a little bit removed from building great software. But at the same time, it's...actually, this is true of me now. I'm not technically a consultant anymore. I've stopped doing that, and I'm now full-time at an organization. And I'm not imagining my role changing fundamentally. I was consulting with them. I've now come on as a full-time employee, and I'm still viewing my work as very much the same thing. Maybe that's because I spent so long consulting that that's sort of the mode that I think of as how I work. But I think yeah, it's not necessarily two different modes. It's definitely a continuum that I'm operating across.

+ +

STEPH: Yeah, I think that's why for me, it often varies. I like that word that you're using around how it's a continuum and that you're constantly sliding back and forth between one mode and the other. And if I think back to earlier days when I was working specifically with product teams before then, I joined thoughtbot and trying to think, well, what are some of the differences? How would I define what is more of my consulting mode versus then the building great software mode? Although I think the latter does encompass the consulting skills. But thinking back to when I was working on a product team, I found...and this may also just be because I was new in my career. But I found that I often referred to whoever was more senior on the team to handle a lot of those more human-centric topics, as you phrased it earlier. So if there was some communication that we needed to share in regards to why we were delayed on implementing a feature, if we needed to run a retro, if there were some meetings that needed to be scheduled, it always felt something like, oh, this leader of the team is going to take care of that. I am more in the development role, so I will do my job but then defer a lot of that to them.

+ +

And then since joining thoughtbot with the way that we operate, I feel like I have more ownership in the process, and I want more ownership in the process. I want to be someone that is very aware of what are the specific goals that we're looking to reach? What are the deadlines? What's behind those deadlines that's encouraging us to push hard? And then also understanding how is the team functioning? What's something that we could do to improve the team's efficacy? Is the team happy? Are there areas there that we could improve? So I think for me, that is one of the core parts where I feel like I transitioned from being more focused on development to being more...you know, I don't have a great word for it. I often referred to it as being more of like a product owner. And since then, I feel like I have more ownership around the code that I'm working with and the team, and then the processes and the decisions for the product. But I actually don't have a great word that encompasses that sense of I want to be part of this and help make decisions and look out for everyone else that's around me. Does that resonate with you? Do you have any particular way that you would describe that or a word for it?

+ +

CHRIS: I don't have a specific word for it. In my mind, this is just how we build software. But I think that that speaks to the culture that we grew up in as software developers. It's so strongly in our minds to think this way. A thing that we've talked about in the past is encouraging software developers to observe the sales demo, to see what it looks like when we're talking to end-users, or, similarly, to sit on customer support calls or listen to user interviews or things like that. And the reason for that is we want...I believe strongly that developers will do better work if they understand the context of the end-user of the application. But I think fundamentally, that sort of loads things up in someone's mind that might encourage them to push back or to suggest a different way of working down the road, and I think that's a good thing. I think every software developer should have some amount of that going on. And so that idea that consulting is this other thing that you sometimes do I feel like that stuff fits under the umbrella of consulting and, therefore, I think it's just part of how we build good software, but maybe it's a nomenclature thing, and I'm just thinking about it wrong.

+ +

STEPH: Well, I want to pull at that thread a little bit because I was having that internal discussion with myself when I was thinking about this question is in regards to that being more aware of how the other teams are working to then help inform our decisions around the software that we're helping build, and implement advocating for a new process or advocating for how to build great software, is that consulting? I think you and I fall more into the camp of that's just how you build great software is; you have to be part of those decisions to be able to have more insights into the work that's being done. So I don't know if I could even really classify that as a consulting skill.

+ +

CHRIS: Yeah, that matches my thinking. There is a distinction between consultant and contractor that I'll sometimes push on a little bit where I see consultants as being perhaps a bit more strategic and not necessarily being handed the work to do. I see that perhaps more on the contractor end. It's like, "We need a website built. Here are the specs. Here's the design mock-up. Please build it," and that's that. Versus a consultant being like, "We need a website, but we're not even sure exactly what that means. Can you help us think about the features and prioritize? Do we need a mobile app or not?" And a consultant potentially working more in that space of helping to determine what is the work that we're even going to do. But again, that's a question of like, how do we build good software? We have to answer those questions, and maybe not everyone on the team is always answering those questions. But the more people feel empowered to and feel like they've got the context to be able to make those sorts of at least suggestions around those sort of decisions, I think the better.

+ +

STEPH: Yeah. I agree with the distinction in regards to being a consultant or a developer versus being a contractor because one definitely feels more removed from that decision or with that team collaboration process where you are more handed work, and then you implement that work, but you don't necessarily ask questions and be like, "Well, what are the benefits of adding this particular feature? Are we tracking to know that we've added the right thing?" those types of things that I would naturally include as part of my work. Versus if you're doing more of the contract work, then maybe you just implement and then don't ask those questions. Thinking back to then, what's different about being a consultant versus then doing development work…and I'm totally sidestepping all the financial stuff here. Like, if you're a consultant, then your world may be very different in terms of how you are acquiring jobs and then your marketing. So I am sidestepping that big conversation there but then focusing more on your day-to-day, how it may be different.

+ +

And the times that I do feel that I'm wearing more of my lower-casey consulting hat is where I am joining teams that have a very specific goal that they have brought thoughtbot on to help with. So maybe there is a particular certification that they want their software to achieve, or maybe they're looking to level up their team and a particular tech stack, maybe it's Rails, maybe it's testing. And that one feels more focused on I am here to help provide an outsider opinion, to help evaluate your team, to help you provide advice, to communicate more with leadership that's on the team so then they know how things are going. That feels more like a consulting engagement that is less focused on building great software. But I feel like that often still starts with we want that stuff, but we also still want great software. So I always feel like I'm in both, and I really can't be as effective at the consulting part without actually working with the team and understanding the struggles that they're going through. So I still feel like they fit very hand in hand, but I do find that there are certain engagements that do require more external communication versus the others are often more internal with the team that I'm helping build software with.

+ +

CHRIS: Well, I like that as a framing, the internal versus external communication and sort of the ratio of those. That's an interesting one.

+ +

STEPH: To me, that's really what then sort of differentiates the consulting versus the just focused on building great software is if I'm doing more external communication, I'm focused less on the building part of the software but more on the guidance part.

+ +

CHRIS: Yeah, I think that's a really good encapsulation or perhaps a way to differentiate the two ends of this. But I think both you and I probably feel that this just varies project to project. In some cases, we need more of what would fall into the consulting bucket, and other days, it's just nope, we got to go in. We got to implement. We got to build a bunch of features. We've got to get to the MVP launch and whatnot. And that often requires a little bit less on the consulting or the external communication side. But I think it's a case-by-case thing. And it's not that I think of myself as one or the other; it's I'll scale up or down as necessary based on the context of the situation. So I am both, I think.

+ +

STEPH: Two for one, consulting and building great software. [laughs]

+ +

CHRIS: One-stop shopping, everything you need.

+ +

STEPH: So, I do have a couple of examples that I can provide that may provide some insight as to how we view consulting a little differently than necessarily focusing on implementation. I feel that I'm still reaching for that separation between consulting and developing. So I'm going to focus on the external communication and the implementation. I feel like those are the two areas that are trying to be divided in this particular question. But I do have some examples from thoughtbot discussions around consulting. So every so often, we get together at thoughtbot, and we have these internal discussions where we talk about the different consulting challenges that we have faced. And it's a really nice time where we get together, and we may discuss ongoing active consulting challenges and questions that we have, or it may be scenarios that have happened in the past. And so then we present that scenario to groups, and then we break off into smaller groups, and then everybody has an opportunity to talk through how they would react, what advice they would give, how they would approach it. And I have found those sessions to be incredibly helpful, but I think it could be fun to share some of those examples. Folks can think about them as to how they would react to them. But I think this helps highlight why those consulting skills and then also building great software are so tightly coupled together.

+ +

So this first example focuses on building MVPs. So let's say that you're working with a client, and you've been focused on building an MVP, and the engagement is coming to a close in a few weeks. But the client is disappointed that there is a particular feature that they're really excited about that's not being included in the MVP, and they'd really like to know why that particular feature was cut. And they are worried that that will actually cause the business to fail if they don't have that feature in the MVP. So that's something that often comes up when we are focused on scoping MVPs to make sure that we are aligned with the client team to understand what is very important for the MVP and what can be a fast follow. And that can be a thorny one, especially if someone feels emotionally attached to a feature that is something that can be tricky to navigate. And how do you help the team reach a consensus that this feature really does need to be in the MVP, or it's okay that it doesn't need to go out now, and it can be in a future iteration?

+ +

And for another example, this one is more focused on communicating the progress of particular work and how it's going. So you can imagine this scenario coming from the client saying that they have been working with you for a few weeks and you've made good progress, but it feels like the last week things have stalled. And they don't understand why a particular feature is taking longer than expected to ship. And they haven't had any communication from the team regarding what's taking that feature a longer time to get out. So, again, these are just some scenarios that you can think through and imagine how then you would respond or handle each of these situations. But I think both of those are really great examples that focus on the more consulting aspect of our work and then when we need to have more external communication with teams, so then they feel confident that we are developing great software.

+ +

CHRIS: I think this is the first time that I've observed us giving homework to the listeners. But I think one thing that I'll highlight is we are talking about this in the context of consulting or being a consultant. But I think both of those examples that you gave, and more generally, most of these sort of conversations, actually apply pretty equally to working within an organization as an employee. You're still working on projects. You still have deadlines. You still need to ship things. You maybe aren't shipping as quickly as you need to; that maybe needs to get communicated to both internally within your team and externally within your larger organization. So yeah, I think these are broadly applicable, and I think, yeah, rolling them around in your head, let us know if you come up with any great solutions.

+ +

STEPH: And if folks are interested in these types of scenarios, then I'm happy to share some more of them. I could share them on Twitter or anywhere else that folks find helpful. But I really like that nuance where I feel like is a nuanced discussion between building some great software and then those consulting skills. So thanks, Matt, for submitting such a great question.

+ +

CHRIS: And as an aside, just to give a little more context on Matt, he runs a blog called the Boring Rails, which,, if you are not following it, it is a wonderful, straightforward summary of small, useful tidbits of information in the Rails world that are boring, but that's part of what we love about Rails. So I highly recommend that as well, and we'll include a link in the show notes. But yeah, thank you so much, Matt. And on that note, shall we wrap up?

+ +

STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Chris gives some small updates on working with Svelte. He really likes Svelte so far. Svelte's great. Modals are complicated. He also talks about using a little JavaScript library, called Quicklink. Steph talks about sending data to a third-party system and using feature flags to help deprecate some code.

+ +

Finally, they both riff on a listener question on consulting. Said listener asked, "Do you think about your work as 'consulting first' or as 'building great software first and then good experiences for your clients will follow naturally?'" Find out their take and give us your own, here on this episode of 'The Bike Shed!'

+ + + +

Transcript:

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So hey, Chris, happy Friday. How has your week been?

+ +

CHRIS: Happy Friday. My week's been great, yeah. I've been writing a lot of code, moving things around, planning some features, and all that fun stuff that goes into building an app, so I'm enjoying that process. I'm also halfway through listening to your recent episode with Nate Berkopec, which was absolutely delightful, well, at least the first half that I've listened to so far. I assume the rest will continue to be absolutely delightful, but it does remain to be seen. So I'll report back next week when I've listened to the whole thing. But yeah, that's great. And I'm glad that Nate got to come on, and we got to share a little bit of his story as well.

+ +

STEPH: I like how clear you are in terms of like, "The part that I've listened to so far is great, but I reserve judgment until I've heard the rest of it." [chuckles] But that's awesome.

+ +

CHRIS: The thing about being a developer is it has broken my brain such that I am overly specific all the time because I just argue with a computer all day. It's what I do. So then I start talking to humans, and I'm like, wait, I should probably behave differently now. And I got to unwind some of those computer fights. But anyway, and let's see, small updates working with Svelte, really like Svelte. I'm leaning into it more and more and embracing...I think I'm starting to understand the aspects of it that I really like. And one of the things that I really like about it is that it is somewhat underpowered. And what I mean by that is working on React applications, I find that I can do some fancy stuff, and I can express it really well in TypeScript. And I can really go for it and create some components that are wildly variable and configurable and can take in any combination of props and do all sorts of things. And I can slice out tiny, little components and do all of this. When I'm doing that, I enjoy it.

+ +

But in Svelte, I have a little bit less power in my control. Svelte is closer to HTML, CSS, and JavaScript fundamentally. So you can make components, and I really like that. You can bundle up the pieces of functionality and display and formatting, and all of that, but it's not quite as powerful. It's not quite as expressive. And I've actually found that to be a useful limitation, which is an interesting frame. It's not something that I thought I would say, but I'm finding that the code that I'm authoring in my editor is so much closer to the code that's actually going to be presented to the end-user. That is really useful in my mind. I find that to be really valuable. There are small things like in Svelte; you can actually say class equals when you're trying to define a class on an HTML element. It turns out I really like that one instead of having to say class name or similarly HTML for. There is a handful of them in React that you have to change the name of. So if you copy a snippet of HTML from the web, and then you dump it into your editor, if you're working in React, you have to change a bunch of stuff. It doesn't work right away. And it's a small thing, but I found that I really seem to care about it. But there's the “it's nice that it just works” version. But I feel like there's also an actually practical, meaningful edge of it is so much closer to the thing that's actually going to be in the browser, and I like that.

+ +

STEPH: I liked the phrasing that you used just a moment ago where you said, "Useful limitation." Since I haven't used Svelte myself, one of my understandings is that you like the fact that it is that low JS in terms that we are introducing this framework, but it's not as heavy-handed as React or another framework that you could retour. But then you also said you're running up to areas where you feel like you're missing some stuff from React, is what I'm hearing. Is there a particular feature, or do you have a concrete example to help me understand some of the stuff that you are really missing?

+ +

CHRIS: It's not so much that I feel like there are specific features missing, but as a pointed example, I am not able to pass in the DOM element that I would like the component to render as. That's a weird thing, but often, component libraries will do this. So you have a button component, but the button can render either as a literal HTML button element or an anchor element. And you can pass in as equals and then button as the string there. And in React, you can do that, and then you can actually do some type inference across it and say, "Okay, now the rest of the props that you can pass in are button props.” And if you pass in as equals a, so implying that you want it to be an anchor or a link, then it will constrain you to the link properties and say, "Oh, you must have a HREF now." That's really cool that you can do that. It's also super complicated, and the TypeScript representation of it, while it works, is very, very complicated and the types of errors that you get. The complexity of what you can build with React is really interesting. But I worry now that I've spent a good bit of time in Svelte, I worry if it's overpowered. I've worked on plenty of applications where the system as designed in React, all the set of different components is very, very complicated. And you sort of have to learn that system in order to be able to work in it, whereas in Svelte, you just start, and you're writing in HTML and CSS. And then, as you need more fancy stuff, you can slowly layer it in. And to be clear, Svelte definitely has plenty of power.

+ +

This past week, actually, we were working on a modal component, but we were really focused on accessibility, which is probably a good thing that you should do, but it turns out modals are very hard to get right. The dialogue component that should exist in HTML is not complete, and it's not a thing that we can rely on. So we have to do certain things ourselves. So the idea of focus trapping when the model pops up, we need to say, oh, okay, the focus should be trapped inside of here, so you can tab forward and back, but it's going to stay within that modal component. There's actually a way that you're supposed to portal it. So you move it outside of the documents so that you can make the rest of the document...I want to say aria-hidden is the property, but you're basically saying the entire rest of the document that's behind this modal component should be inert to a screen reader essentially or invisible to a screen reader while the modal is up. And doing all of those sorts of things is super complicated. After you close the modal, you're supposed to refocus the button that opened it, the triggering element, and that's a tricky one where you have to pass down a reference to something. And that was all very expressive, actually, very straightforward in Svelte in a way that I was really impressed by. So it definitely has all the power that you need but not any more than what you need. Or there is a small line of it's just right.

+ +

STEPH: So we should just scrap modals. That's one of the things that I'm hearing from you. So I just want to clarify because I do feel a little confused because in the beginning, it sounded like you were saying that Svelte is wonderful, but you do feel like you're missing a little bit of functionality there that you do receive with other frameworks like React. But then that last thing you said where “it's just right” sounds like it's the Goldilocks. So I'm a little confused as to exactly how you're feeling about Svelte in the moment.

+ +

CHRIS: Yeah. I'm probably not being as clear as I should. I am a big fan of Svelte, so as the first answer, a big fan of Svelte. I'm recognizing that, strictly speaking, it is somewhat less powerful than React. But I'm also trying to say, perhaps failing at saying, but trying to say that I like that, that I'm finding its constraints are useful. React can do a ton of stuff. You can represent a real impressive array of component functionality and have components that take 17 different props that covary in different ways, and it's very complicated. And I've worked on plenty of React applications where I just have to stare very hard at the component library for a while. And I'm like, ugh, I still don't know how this works. And it's this custom bespoke language where Svelte feels like it is much closer to the thing that we're actually doing, which is rendering HTML and CSS and JavaScript and whatnot, and I like that. I'm finding that very useful. I'm finding that lack of power not to be a hindrance but, in fact, to be useful.

+ +

STEPH: Hmm. Okay. I like that last part. Yeah, there are often times where I feel like the less powerful something is, even if it means a little extra work on my end but it's clear as to the work that's being done...I'm going to take it back a couple of years to when I was first learning Elixir because that's how I felt jumping from Ruby to Elixir and from Rails to Phoenix, where suddenly I felt like I had more clarity. There were some things that I had to do more on my own, but I felt more clarity as to what exactly was being done versus Ruby and Rails doing a lot on my behalf. So I can certainly relate to that.

+ +

CHRIS: Yeah, I think that captures it well, that the expressive power of React can perhaps lead to somewhat more confusing code, and the small handful of cases where I need to be slightly more verbose in Svelte I actually find really useful. Like, Svelte is making sure that I'm writing components that are clear and easy to work with, but it still has all of the power that I need, and I can do everything I want in it. And yeah, overall, just yeah, Svelte's great. Modals are complicated. And that's my story. But yeah, that's a little bit of what's up with me. What's going on in your world?

+ +

STEPH: Before we switch gears. I want to add on a little bit more to what you just said because something that I have noticed with me is that the longer that I've been a developer, the more I want that lower-level control and understanding as to what is happening. And it sounds like that is very much what you're saying that you're enjoying with Svelte is even if it does require a little more extra effort, that then at least I have that ability to exactly control what's happening versus if you're using higher-level obstructions, you're stuck with the API that's been designed for you. And that API works 98% of the time, that's wonderful but then that 2% of the time you're in trouble. So I've definitely noticed that trend, that over time, I want that lower-level control over everything that I'm working with and building, although not all the way to C, let's not go that far.

+ +

CHRIS: I mean, there's Assembly underneath C. We can keep going, and we can just manually manipulate transistors as well if we really want to get after it. [laughs]

+ +

STEPH: Next week on The Bike Shed. [laughs]

+ +

CHRIS: Much, much higher level of abstractions are interesting to me, but yeah, there is a sweet spot. Svelte seems like it's the one for me.

+ +

STEPH: Nice. So then switching back to what's new in my week, it's been a little bit of a weird week in terms of there's been a lot of focusing on sending data to a third-party system. So we had a lot of data that they needed in their system. So I have been focused on running a number of processes that are then sending that data over and then essentially babysitting processes, making sure everything is going smoothly. Also communicating with their team to understand okay, what's being received? Do we have any errors? Is there any sort of miscommunication between our systems, and that's why we're needing to resend this data to you? So it's been very different in terms that it wasn't a typical feature development week. It was more, hey, I sent you some data. What did you receive? And then let's fine-tune both of our systems on each end, which that part I always enjoy. As soon as I can get to that level of collaboration with someone, I very much enjoy that part because initially, it felt like a stressful task of like, hey, we've got this giant CSV. We need to process and send data. But then as soon as I have someone else to work with, then I'm like, yeah, okay, this is great. They can update their system. We can fine-tune ours as well in case there's something that's not communicating properly, and that part I really enjoy. I really enjoy collaborating with someone else so then we can both improve our systems together, so that part was a little different.

+ +

But the actual weird thing that I did this week is we have feature flags, and we are using those feature flags to help us sunset and deprecate some code. So we have a controller path that is pretty gnarly. It is one of the more dense, difficult areas of our codebase to understand. And so we are refactoring it and creating a new green space for it so we can start to pull in some of that behavior and then also refactor as we go. So we essentially have class version one, and we now have class version two, which is always something. And we want to be able to feature flag this because, with our deployment workflow, we need the ability one; we want to be able to switch back quickly. So that way, if something goes awry, we can switch back to the original code if we've made some misassumption in our V2 version. And then we want to leave that on for a while to make sure things are running smoothly, and then we can go back and actually remove that class.

+ +

But then the question came up is like, well, if we have these two files, how do we tell the team not to touch this particular file but only contribute or make a change to this other file? Because we have a sizeable team, and we work in different time zones. And there is a very reasonable answer that we communicate with the team that other folks are aware because they've seen the PR. There's a whole self-discipline of we review PRs and make sure stuff wasn't changed. All of that stuff is fine. It's reasonable. But I wanted to do something a little less reasonable [chuckles] that would still fail loudly in case someone changed a file. So the question was presented is there a way that we could fail loudly if someone changed this file? And there's a fun thing that we'll do at some of our daily syncs where someone will say, "That's a good idea. I have a bad idea." There's a fun thing that happens at our daily syncs where someone will often ask a question, and someone will provide an idea. And then someone else will say, "That's a good idea, but just to throw it out there, I have a bad idea. So let's just explore all of the ideas." And one of them was like, "Could we write a test around this? So if the file hash or something about that changed, then could we alert the team so then we know that this file changed and you're not supposed to change this file?" And essentially, having that discussion of like, well, then we're reimplementing Git because we're trying to track file changes. That seems like a bad idea but still a novel one to talk about for a few minutes.

+ +

The implementation that I landed on and then shared with a person that's working on this is you do have the ability with Ruby, the file class itself; you can open a particular file. And for this one, select class one, and then you can use the function mtime, which returns the modification time for a file. So you can check the last time that a file was changed. So I wrote a test that says that "This file was last altered at…" and I grabbed that file's last altered at time with mtime. And then, I compared that to a particular DateTime. And then that DateTime could be any DateTime in the future once we deploy this class version two, so we don't expect that file to be altered. So this test will always pass until someone changes that file. And then Ruby is going to say, "Oh, your time is now greater than that other time you said." And so it's going to fail, which actually works pretty well. It's not as ugly as I thought it was going to be. [chuckles] As to whether it's a good thing to add to the codebase, I don't know, but it was a fun thing to write.

+ +

CHRIS: I like it. I've definitely written things like that in the past, and I guess; therefore, I'm biased. [chuckles] I'm a fan of this sort of thing. But when you can take that group knowledge that is just shared in communication or via code review and you can capture it in the code, especially if you can do it in a stable, robust way…In particular, the first thing that comes to mind with that is like, well, are there going to be different representations of the timestamp on your system versus CI? Will that ever change over time? Like, Linux versus OS X or things like that. I actually have reached for Git in situations like this in the past. So, in particular, the one that I found myself doing a few times is trying to instrument code generation. So say we're working with Apollo, and we are generating the TypeScript types associated with a GraphQL request. I wanted to put something into CI to say, "If we haven't committed those changes," because we're supposed to be committing those files alongside, "then warn." And so the idea was take a snapshot of what things look like right now, run the command that does the code generation, and then check after that.

+ +

I've done different versions where it's like, hey, Git, is the working directory dirty at this point? That's a version. I've also done one recently where I got the checksum of the file but again, asking Git. Because you're totally right that a lot of this...this is what Git does, and we don't want to rewrite Git. But I did feel okay reaching out and being like, "Hey, Git, can you help me understand the word?" But I like these sorts of things, particularly if you can do it in a way that won't ever require someone turning it off. I don't know if you've worked on projects where ESLint is enabled, but every third line has an eslint-disable-next-line. And it's just like, well, we have a bunch of rules, but we ignore them in a lot of cases. And those sort of...the like trust scenario with an automated tool I think is so important. If it's ever giving you false positives, false negatives, whichever it is, then it immediately, I think, loses so much of its utility. But if you can do it in a way that is stable and robust, then I am a huge fan.

+ +

STEPH: Well, we'll see if the person decides to include it in their PR or not. But I do like that idea of where we can take away the idea that we're going to catch it if it changes in a PR because then we're just going to end up in a bad place that if we fix a bug in the class V1 but don't apply that to class V2, we're just going to be in a bad spot. And it's likely we'll forget about it when we go back to then delete class version one. There is something that you said that has reminded me of a very small change that I made to my process, but I feel like it had a big impact. And it's specific to working with feature flags, how often you'll have your tests where it's like if feature flag is on, this behavior should happen, if it's off, this behavior. And I often would wrap my test in the default path where the feature flag is off, and then I'd have my other if the feature flag is on; this is the behavior. But as we are migrating with the intent that this feature flag at some point in the near term future is going to always be on, so we know we're going to come back and remove all of the other code. I switched those two paths and treat the default happy path as the new if the feature flag is on; this is the new world. So then when folks are going back to say, "Okay, I just need to delete everything that represents when the feature flag is off," suddenly, it's just very easy to find that context to say, "Hey, feature flag is off and then boom, delete all of those tests." And that's been really nice.

+ +

CHRIS: I really like that lens of designing or coding for deleteability. How easy is it to just rip this thing out? It's one of the things that I love about Tailwind, or one of the purported facets of Tailwind that makes it really nice is when you're looking at a given template, you can just rip it out. You don't have to worry about it because there's no associated CSS that you need to think about because the CSS is sort of generated available, whatever you want to call it with Tailwind. But I really like that idea of making it easy to delete stuff. Because it's so easy to just have your codebase slowly grow over time and look at files and be like, "I don't know if we're using that, but better to be safe." Cool. I'm excited to hear if that does land in the codebase and how folks respond to it. What did you phrase the message as? So if there's a test failure, did you give a particular like a special RSpec formatted message to be like, "Hey, friend, you're not supposed to touch this file. I know you're well-intentioned, but…" or is it just like, "Failure, bad. Mtime is different." Which end of the spectrum are we on there?

+ +

STEPH: I love that you asked that question because I almost went down that path, and I was like, well, this should really have its own custom failure message because it's odd enough that I want to tell someone a little bit of a story when it fails. But I didn't because this was something that one; I just want to see if I could do. So I initially started looking at standard rb in RuboCop because at first, I was wondering if this was something I could solve via linting if it was something that RuboCop…if I could say, "Hey, RuboCop, if you notice that this file changed…" I didn't know if they had a hook into Git as they're looking for files to analyze. So I first leaned on RuboCop standard rb, which essentially then uses RuboCop under the hood, and I didn't find anything there. So then that's when I was like, okay, maybe Ruby has something, and that's when I found the file mtime. So at that point, once I'd gotten the test to pass, I'm like, you know, this is good. There's a very nice, friendly test description that goes along with if this fails; this is the reason why. But I do think that would be like cherry on the top addition to the test to have a very nice error message that goes along with this. So if I were the one that was adding this to the codebase, I would take a few more minutes to do that myself. It definitely felt like one of those moments where I had gone far enough into an experimental mode, and I felt like I had just reached that point where this is useful, and I want to share it with the person who's actually working on this. But then I pulled back going further because I'm like, I don't actually know if they want to use this and if they're going to implement it. So it felt like that right friendly balance of like, here's something that works. Feel free to use as is, make it better, don't use it, totally up to you.

+ +

CHRIS: Yeah, I think given that context, that's definitely I feel like a good line to draw, not like, “Here's fully completed code that you can now just drop in. I did all the work, but here it is.” Versus like, “Oh, here's a kernel of an idea if you want, run with it, but if not...”But yeah, [chuckles] if you went to the length of writing a nice paragraph summary message to the end-user, that feels like you're really taking over the show. So cool. Well, yeah, interested again to hear how that goes and hear if it does, in fact, stop. That's the other thing. It's like, if it never actually fails, then everybody was just fine with the human process. But I'm intrigued to see how many times it actually does stop unwanted modifications of the file. So that's an interesting measure to track.

+ +

STEPH: Yeah, that would be an interesting thing to track because if we do have it, then we may have less visibility into knowing if it failed because then someone will see it fail locally, but then we will have prevented it from getting to that PR state. It is one of those “did someone not change it because we added the test, or could we have skipped that process?” It feels like one of those nice safety measures, but that would be a fun thing to measure, I agree.

+ +

CHRIS: Yeah, especially if it's a small change; in this case, I think it's totally worth it. But now, as I said it, I didn't mean it to be more of a thing. But now that I think about the question, I wonder if all tests should fail at some point. Like, all tests have a cost, both in terms of development and then thinking about them in runtime and all of that. And a good test is one that eventually fails because you change the system in a way that broke some constraint. And so, therefore, I'm now asking the question, like, should every test fail at some point? Are tests that only ever pass actually not that useful? I don't think so. Now there's a story running in the back of my head that's like, I kind of want to look at the CI stats. And feature specs will occasionally fail for unrelated reasons. But unit-level tests that never break, that never fail and catch something that was broken…I don't know that I actually believe this, but I'm just intrigued. As I asked the question, I was like, huh, should all tests fail? Sort of like one hand clapping kind of thing, anyway.

+ +

STEPH: I like the question, or it's making me stop and think because my initial answer is yes, as long as it's failing for a meaningful reason, as long as it's not a flaky test or something along those lines. But otherwise, as you're working on the system and you're making changes, then I'm inclined to say that yes, every test should fail at some point. But I agree, if we're getting into existential test area, then I don't have concrete feelings about this yet.

+ +

CHRIS: Yeah, and I feel like it's one of those sorts of questions. So pivoting off of that ever so slightly to bring us to something much more practical, I have a tiny utility that I want to chat about. And then I think we have a listener question that we want to discuss. But the utility, I think I brought this up on a previous Bike Shed episode, but the tool it's a little JavaScript library, but it's called Quicklink. And so the heading is instant next-page navigations. And so the way it works is it's just a little snippet of JavaScript that you'll include from a CDN, or you can NPM install it or any number of ways. But it's a tiny, little one kilobyte JavaScript thing that basically what it does is it attaches to every link on the page whenever you use that link. So you click on it or if you're on mobile if you tap, or however you're interacting with it, if it's an internal link, so not external to your site and not going to a different domain, but if it's internal to your domain, what it's going to do is it's actually going to prefetch in the background as you hover on that link. So it's going to say, "Hover is a good indication of intent to follow this link. So we're going to prefetch it in the background." And then when the user actually subsequently clicks it, which is often a couple of 100 milliseconds later, that's often enough time actually for the page to load in the background. And then, when they click the link, it almost feels like instant navigation. There's a similar thing that happens based on when you tap and when the actual firing of the link happens on mobile. So there's another delay that they can take advantage of there that's not quite the same as hover. But overall, it just takes basically any webpage, any website, and makes it feel very much faster. And it's cheap, easy, just kind of works. I really like it. It's a very interesting little project.

+ +

STEPH: I'm fascinated by how that would feel as a user because if I'm hovering over a link, I'm thinking through my specific navigation habits. So if I'm going to a link, like, I don't hover very long. I don't think of myself as a hovering internet user. [laughs] I'm probably going to click on it right away. So I wonder if I would still feel that same speediness versus...yeah, I am interested in the metrics if they have something around like...I don't know why they would know this or have this, but like, most people hover for this long. And so then it speeds up their feeling of the page load. I'd be interested in that.

+ +

CHRIS: I like the idea that you're bracketing yourself into the quickest click of a link in the west. I'm looking around on their website, seeing they have a quote from NewEgg at the top, which is, "We implemented Quicklink and saw a 50% increase in conversions and 4x faster page transitions." So it sounds like I'm reading an ad for this now, which I'm not because it's a free project. So you can use it or not and pay the $0. They have a demo, and then they have a measure page. So I think you can actually get to...I think they're just talking about how to measure it. But I've definitely seen another page where you can click on a link, and it will tell you what was the difference between hover and active when you actually interacted with it. And it turns out the bounding box for a link is bigger than what you see. And you're often moving your mouse not entirely to the center, but you're not just getting to the edge of it and clicking. And so that period of time where you're moving your mouse onto the link, there's actually often a couple of hundred milliseconds, which is enough to really make a difference if you've got a speedy site. You can take what feels like a couple of hundred milliseconds and turn it into nothing.

+ +

STEPH: All I can think of right now is the image of a little mouse that's moving closer to a link with the Jaws' theme song playing. So it's ta-dum ta-dum. [vocalization] And this whole time, Quicklink is getting ready to then load as soon as the mouse reaches that perfect zone to then start loading. That's what I'm getting is Jaws and Quicklink. [laughs]

+ +

CHRIS: I like the...it's not personification, but it's jawsification that you're doing of this JavaScript library where it's like, I just imagine them hovering on the side really watching intently. But on the sites that I've used it, it does make a noticeable difference. I feel the difference even with very active clicking.

+ +

STEPH: That sounds really neat. I'll have to look into it. Maybe I think I'm the quickest click in the west. That's very hard to say. And it turns out that I'm actually quite slow, who knows?

+ +

CHRIS: You might just be average; that’s fine.

+ +

STEPH: No way.

+ +

CHRIS: Most people are, mathematically speaking at least. [laughter]

+ +

STEPH: Not possible. I'm certain that I'm special. I hope listeners get a kick out of my oddities, [laughs] my very honest self that's coming through on the mic today.

+ +

CHRIS: We're all a little special. But pivoting one more time…

+ +

STEPH: That means no one's special. [laughs]

+ +

CHRIS: Are you just doing the quote from Incredibles, or are you actually trying to say that? [laughs]

+ +

STEPH: I wasn't intentionally quoting The Incredibles, but I did just watch that movie recently, and you're totally right. I am quoting The Incredibles.

+ +

CHRIS: This is our second episode in a row then with a Pixar theme, which is always fun. But pivoting ever so slightly, I think our final pivot for the episode, we have a listener question today. So this question comes in from Matt Swanson, and he is asking about consulting first versus software first. So his question is, "One of the biggest turning points in my career was realizing that software consulting is, well, consulting. Do you think about your work as 'consulting first' or as building great software first and good experience for your clients will follow naturally?" So, Steph, what do you think?

+ +

STEPH: I liked this question because it really made me stop and think about the differences in how I approach my client work. So I will say that I do think it varies slightly for each client, but most of the time, I do think of my work as first building great software. And then, once I've had time to understand how the team works and then identify opportunities for improvement, then I'll put on my consultant blazer and start scheduling meetings. I'm just kidding. I don't like meetings, so I don't do that part. But I do find that most of my engagements are looking for initially a strong developer to help contribute to the team and mentor. And then, I find that a lot of my consulting skills can then start to shine once I have that opportunity to build trust and then share outsider views with the team and then coach them in other directions. So I do take the approach of building great software first. Although this question really made me pause and think about it because I do think of the consulting and building software as so tightly coupled. It's a little hard for me to define when am I switching from my developer hat over to more of my consulting hat.

+ +

CHRIS: Yeah, I think my initial reaction to the question was similar where I don't view these as two different modes that I'm fundamentally operating in. It's a continuum, or it's like a two by two grid thing, and I'm sort of moving around between the different spaces, but there's always a little bit of both. And I think if I were to answer the question directly, I would lean towards building great software. That's always the thing that I'm trying to do but often that requires some other more human-centric interactions. So having a difficult discussion around a feature and why we may not reach a deadline that we're going for or talking about ways in which the workflow is not necessarily going as well as it could, and we're ending up losing information along the way or different process things, all of that is a little bit removed from building great software. But at the same time, it's...actually, this is true of me now. I'm not technically a consultant anymore. I've stopped doing that, and I'm now full-time at an organization. And I'm not imagining my role changing fundamentally. I was consulting with them. I've now come on as a full-time employee, and I'm still viewing my work as very much the same thing. Maybe that's because I spent so long consulting that that's sort of the mode that I think of as how I work. But I think yeah, it's not necessarily two different modes. It's definitely a continuum that I'm operating across.

+ +

STEPH: Yeah, I think that's why for me, it often varies. I like that word that you're using around how it's a continuum and that you're constantly sliding back and forth between one mode and the other. And if I think back to earlier days when I was working specifically with product teams before then, I joined thoughtbot and trying to think, well, what are some of the differences? How would I define what is more of my consulting mode versus then the building great software mode? Although I think the latter does encompass the consulting skills. But thinking back to when I was working on a product team, I found...and this may also just be because I was new in my career. But I found that I often referred to whoever was more senior on the team to handle a lot of those more human-centric topics, as you phrased it earlier. So if there was some communication that we needed to share in regards to why we were delayed on implementing a feature, if we needed to run a retro, if there were some meetings that needed to be scheduled, it always felt something like, oh, this leader of the team is going to take care of that. I am more in the development role, so I will do my job but then defer a lot of that to them.

+ +

And then since joining thoughtbot with the way that we operate, I feel like I have more ownership in the process, and I want more ownership in the process. I want to be someone that is very aware of what are the specific goals that we're looking to reach? What are the deadlines? What's behind those deadlines that's encouraging us to push hard? And then also understanding how is the team functioning? What's something that we could do to improve the team's efficacy? Is the team happy? Are there areas there that we could improve? So I think for me, that is one of the core parts where I feel like I transitioned from being more focused on development to being more...you know, I don't have a great word for it. I often referred to it as being more of like a product owner. And since then, I feel like I have more ownership around the code that I'm working with and the team, and then the processes and the decisions for the product. But I actually don't have a great word that encompasses that sense of I want to be part of this and help make decisions and look out for everyone else that's around me. Does that resonate with you? Do you have any particular way that you would describe that or a word for it?

+ +

CHRIS: I don't have a specific word for it. In my mind, this is just how we build software. But I think that that speaks to the culture that we grew up in as software developers. It's so strongly in our minds to think this way. A thing that we've talked about in the past is encouraging software developers to observe the sales demo, to see what it looks like when we're talking to end-users, or, similarly, to sit on customer support calls or listen to user interviews or things like that. And the reason for that is we want...I believe strongly that developers will do better work if they understand the context of the end-user of the application. But I think fundamentally, that sort of loads things up in someone's mind that might encourage them to push back or to suggest a different way of working down the road, and I think that's a good thing. I think every software developer should have some amount of that going on. And so that idea that consulting is this other thing that you sometimes do I feel like that stuff fits under the umbrella of consulting and, therefore, I think it's just part of how we build good software, but maybe it's a nomenclature thing, and I'm just thinking about it wrong.

+ +

STEPH: Well, I want to pull at that thread a little bit because I was having that internal discussion with myself when I was thinking about this question is in regards to that being more aware of how the other teams are working to then help inform our decisions around the software that we're helping build, and implement advocating for a new process or advocating for how to build great software, is that consulting? I think you and I fall more into the camp of that's just how you build great software is; you have to be part of those decisions to be able to have more insights into the work that's being done. So I don't know if I could even really classify that as a consulting skill.

+ +

CHRIS: Yeah, that matches my thinking. There is a distinction between consultant and contractor that I'll sometimes push on a little bit where I see consultants as being perhaps a bit more strategic and not necessarily being handed the work to do. I see that perhaps more on the contractor end. It's like, "We need a website built. Here are the specs. Here's the design mock-up. Please build it," and that's that. Versus a consultant being like, "We need a website, but we're not even sure exactly what that means. Can you help us think about the features and prioritize? Do we need a mobile app or not?" And a consultant potentially working more in that space of helping to determine what is the work that we're even going to do. But again, that's a question of like, how do we build good software? We have to answer those questions, and maybe not everyone on the team is always answering those questions. But the more people feel empowered to and feel like they've got the context to be able to make those sorts of at least suggestions around those sort of decisions, I think the better.

+ +

STEPH: Yeah. I agree with the distinction in regards to being a consultant or a developer versus being a contractor because one definitely feels more removed from that decision or with that team collaboration process where you are more handed work, and then you implement that work, but you don't necessarily ask questions and be like, "Well, what are the benefits of adding this particular feature? Are we tracking to know that we've added the right thing?" those types of things that I would naturally include as part of my work. Versus if you're doing more of the contract work, then maybe you just implement and then don't ask those questions. Thinking back to then, what's different about being a consultant versus then doing development work…and I'm totally sidestepping all the financial stuff here. Like, if you're a consultant, then your world may be very different in terms of how you are acquiring jobs and then your marketing. So I am sidestepping that big conversation there but then focusing more on your day-to-day, how it may be different.

+ +

And the times that I do feel that I'm wearing more of my lower-casey consulting hat is where I am joining teams that have a very specific goal that they have brought thoughtbot on to help with. So maybe there is a particular certification that they want their software to achieve, or maybe they're looking to level up their team and a particular tech stack, maybe it's Rails, maybe it's testing. And that one feels more focused on I am here to help provide an outsider opinion, to help evaluate your team, to help you provide advice, to communicate more with leadership that's on the team so then they know how things are going. That feels more like a consulting engagement that is less focused on building great software. But I feel like that often still starts with we want that stuff, but we also still want great software. So I always feel like I'm in both, and I really can't be as effective at the consulting part without actually working with the team and understanding the struggles that they're going through. So I still feel like they fit very hand in hand, but I do find that there are certain engagements that do require more external communication versus the others are often more internal with the team that I'm helping build software with.

+ +

CHRIS: Well, I like that as a framing, the internal versus external communication and sort of the ratio of those. That's an interesting one.

+ +

STEPH: To me, that's really what then sort of differentiates the consulting versus the just focused on building great software is if I'm doing more external communication, I'm focused less on the building part of the software but more on the guidance part.

+ +

CHRIS: Yeah, I think that's a really good encapsulation or perhaps a way to differentiate the two ends of this. But I think both you and I probably feel that this just varies project to project. In some cases, we need more of what would fall into the consulting bucket, and other days, it's just nope, we got to go in. We got to implement. We got to build a bunch of features. We've got to get to the MVP launch and whatnot. And that often requires a little bit less on the consulting or the external communication side. But I think it's a case-by-case thing. And it's not that I think of myself as one or the other; it's I'll scale up or down as necessary based on the context of the situation. So I am both, I think.

+ +

STEPH: Two for one, consulting and building great software. [laughs]

+ +

CHRIS: One-stop shopping, everything you need.

+ +

STEPH: So, I do have a couple of examples that I can provide that may provide some insight as to how we view consulting a little differently than necessarily focusing on implementation. I feel that I'm still reaching for that separation between consulting and developing. So I'm going to focus on the external communication and the implementation. I feel like those are the two areas that are trying to be divided in this particular question. But I do have some examples from thoughtbot discussions around consulting. So every so often, we get together at thoughtbot, and we have these internal discussions where we talk about the different consulting challenges that we have faced. And it's a really nice time where we get together, and we may discuss ongoing active consulting challenges and questions that we have, or it may be scenarios that have happened in the past. And so then we present that scenario to groups, and then we break off into smaller groups, and then everybody has an opportunity to talk through how they would react, what advice they would give, how they would approach it. And I have found those sessions to be incredibly helpful, but I think it could be fun to share some of those examples. Folks can think about them as to how they would react to them. But I think this helps highlight why those consulting skills and then also building great software are so tightly coupled together.

+ +

So this first example focuses on building MVPs. So let's say that you're working with a client, and you've been focused on building an MVP, and the engagement is coming to a close in a few weeks. But the client is disappointed that there is a particular feature that they're really excited about that's not being included in the MVP, and they'd really like to know why that particular feature was cut. And they are worried that that will actually cause the business to fail if they don't have that feature in the MVP. So that's something that often comes up when we are focused on scoping MVPs to make sure that we are aligned with the client team to understand what is very important for the MVP and what can be a fast follow. And that can be a thorny one, especially if someone feels emotionally attached to a feature that is something that can be tricky to navigate. And how do you help the team reach a consensus that this feature really does need to be in the MVP, or it's okay that it doesn't need to go out now, and it can be in a future iteration?

+ +

And for another example, this one is more focused on communicating the progress of particular work and how it's going. So you can imagine this scenario coming from the client saying that they have been working with you for a few weeks and you've made good progress, but it feels like the last week things have stalled. And they don't understand why a particular feature is taking longer than expected to ship. And they haven't had any communication from the team regarding what's taking that feature a longer time to get out. So, again, these are just some scenarios that you can think through and imagine how then you would respond or handle each of these situations. But I think both of those are really great examples that focus on the more consulting aspect of our work and then when we need to have more external communication with teams, so then they feel confident that we are developing great software.

+ +

CHRIS: I think this is the first time that I've observed us giving homework to the listeners. But I think one thing that I'll highlight is we are talking about this in the context of consulting or being a consultant. But I think both of those examples that you gave, and more generally, most of these sort of conversations, actually apply pretty equally to working within an organization as an employee. You're still working on projects. You still have deadlines. You still need to ship things. You maybe aren't shipping as quickly as you need to; that maybe needs to get communicated to both internally within your team and externally within your larger organization. So yeah, I think these are broadly applicable, and I think, yeah, rolling them around in your head, let us know if you come up with any great solutions.

+ +

STEPH: And if folks are interested in these types of scenarios, then I'm happy to share some more of them. I could share them on Twitter or anywhere else that folks find helpful. But I really like that nuance where I feel like is a nuanced discussion between building some great software and then those consulting skills. So thanks, Matt, for submitting such a great question.

+ +

CHRIS: And as an aside, just to give a little more context on Matt, he runs a blog called the Boring Rails, which,, if you are not following it, it is a wonderful, straightforward summary of small, useful tidbits of information in the Rails world that are boring, but that's part of what we love about Rails. So I highly recommend that as well, and we'll include a link in the show notes. But yeah, thank you so much, Matt. And on that note, shall we wrap up?

+ +

STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Blm1neb3 + + ]]> + + Chris Toomey + Steph Viccari + + + 297: We’re Making A Pixar Movie! + https://bikeshed.thoughtbot.com/297 + 7eadd17c-2c26-411b-aeed-7d4e29bda4f8 + Tue, 22 Jun 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Chris gives the deets on that new new – (he joined a startup!) and laments about the back button being so complicated. Steph talks about extracting an untrustworthy service and likens the scenario to making a Pixar movie. You don't wanna miss this hero's journey! + 48:57 + no + + + Chris gives the deets on that new new – (he joined a startup!) and laments about the back button being so complicated. Steph talks about extracting an untrustworthy service and likens the scenario to making a Pixar movie. You don't wanna miss this hero's journey! +Eric Bailey's bunny updates (https://twitter.com/ericwbailey/status/1389332217088851971) +Katrina Owen's Therapeutic Refactoring Talk (https://www.youtube.com/watch?v=J4dlF0kcThQ) +EnjoyHQ (https://getenjoyhq.com/) User research platform +Aurelius (https://www.aureliuslab.com/) also a user research platform +Dry Monad (https://dry-rb.org/gems/dry-monads/1.3/) (part of dry-rb (https://dry-rb.org/)) +Previous Bike Shed discussing dry-monads (https://www.bikeshed.fm/243) +Railway Oriented Programming (https://fsharpforfunandprofit.com/rop/) +Bike Shed "Seeking Calm" Episode (https://www.bikeshed.fm/279) +Previous Episode Discussing Multi-Step Forms (https://www.bikeshed.fm/295) +Discussion thread on Inertia repo re: back button cache (https://github.com/inertiajs/inertia/issues/247) +Transcript: +STEPH: Yes, I was getting text messages from you where you were like, “Go on without me.” +CHRIS: [laughs] Leave me behind! +STEPH: [laughs] No developer left behind!! +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I’m Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going? +STEPH: Hey, Chris. It's been a very busy week. There's been a lot going on. But the most delightful part of my week has been that Eric Bailey, another thoughtboter and also a former guest on this show, has a tiny, little baby bunny living in his backyard, and so he has been sharing updates about this little baby bunny. In fact, he's been sharing some pictures on Twitter as well. So I'll include a link in the show notes so other people can experience the joy. Also, the name of the bunny gets me every time. But they have named the bunny “Corndog.” +CHRIS: Checks out. It seems like a very obvious name for a small bunny. +STEPH: It gets me because that's such a big name. I don't know why it's a big name, but it feels like a big name for a little bunny. +CHRIS: I can say yeah, it's a cornball. Yeah, that's a large name. And so a tiny bunny is a...it's like Little John from Robin Hood. It's perfect. +STEPH: [chuckles] I kept referring to him as Corn Nugget, I guess, because of size. But yes, it’s not corn nugget; it’s Corndog. [chuckles] So watching Eric's little bunny has been delightful and a wonderful addition to the week. How about you? How has your week been? +CHRIS: My week has been great. I was off on vacation last week (so you had a guest on), which was fun to just take a week off and reset the system. But actually, this week has been interesting. It was my first full-time week with a new startup that I have joined. I think, yeah, that seems to be the truth in the world. So a bit of a shift from what I've been doing for the last year and a half, almost something like that. The reason there's hesitance in my voice is because I've actually been working with this organization for six months-ish, depending on how you count it. I've been having conversations, and then it’s slowly grown over time where it was just conversations, and then it was an afternoon a week, and then one day a week, and then two, and three. And finally, we decided we think we've got an idea. We've got a thing that we want to build. And so I am the developer on this team, but we are an early-stage startup trying to build something. I'm now full-time on the project. I rotated down the other projects that I was working on from a freelance consulting perspective, and now I'm trying something new. So it's a very different vibe. Even though I'd been working with the organization for a long time, this week just felt so much more real. And there was so much more space, so much more room for activities, having a full week to actually work on things. So yeah, it's very exciting, it’s very new, it's very early stage, so all of those things are true. But there are a lot of great aspects to that, and I'm super excited about it. +STEPH: That is some big news. That's a big change too. Well, I guess with consulting, there are the stresses that go into consulting and then changing projects and managing the projects that you're taking on. But then to joining a team and such an early startup team too...anytime, someone says startup life, I'm always like, well, tell me more. How calm is the startup life, or how uncalm is this startup life? +CHRIS: It's somewhere between calm and uncalm, I would say, but in a, I would say purposeful and intentional way. I was looking for...this has largely been true over the entire time that I was freelancing, but freelancing was a way for me to keep the lights on, and stay engaged with tech, and continue working, and frankly, have more conversations and meet more organizations. But I was looking for something that I could engage with a bit more. I was looking for, largely, something like this. So it definitely is occupying a different space in my head than, say, any individual consulting client where with consulting, I was pretty rigid, you know, these are the hours that I'm working. When I'm off the clock, I'm really not thinking about it too much. I'm responsive if I see an incident or something like that or if the database falls over; I’m going to look at that on the weekend but otherwise, largely not doing anything. Whereas with this project, I'm somewhat purposefully allowing it to have a little bit more space in my head off-hours, that sort of thing. And I'm more invested in the work. It's not just a thing that I'm doing, but it's a project that I believe in. It's something that I want to exist in the world. And so, I'm engaged with it in a different way in that manner. I'm also engineer number one, so I'm choosing all of the technologies and setting the standards. Thankfully, there's a lot of good thoughtbot material out there that I can link to, which is great. But yeah, so it's mostly within the context of what I think startups can be. The expectations and the way that the team is working is very reasonable. And I think it's more for my own self. I'm allowing it to occupy a little bit more of my space, but in a fun way so far. +STEPH: Well, along that line, in terms of choosing the tech stack and starting greenfield, I am curious to hear more about the type of project that you're going to be working on. But I'm also recognizing y'all may be in stealth mode. Is that where you're at, or can you talk a bit more about the type of work you'll be doing? +CHRIS: We're stealth-ish right now, I would say, partly because we're likely in the process of rebranding, and renaming, and things like that. So partly it's just like, oh, I probably shouldn't say that. But at some point, this will become public, and so at that point, I can probably be a little bit more open about it. But at the end of the day, we're building a financial product, FinTech sort of thing. And the tech stack is relatively straightforward. I'm actually using my preferred tech stack is...I got to choose, so it's Rails, Inertia, and Svelte with some TypeScript because why not? And I love it, and it's fantastic. I continue to believe deeply in that tech stack. So, yeah, that's most of what I think is good to say now. But I think over the coming weeks, I'll be able to say more and share more. And I certainly will be able to talk about the details of building and growing a team and things like that. +STEPH: Awesome. Yeah, you answered my other question too. I was going to ask what tech stack you chose. +CHRIS: I chose the tech stack, the one with the acronym, which I don't even know...the STIR stack I think we went with or something. +STEPH: I was about to say I don't remember the acronym. [laughs] +CHRIS: I think I never committed to an acronym previously, and then that was the one that got thrown around on the internet. I think I just was like, in the next episode of The Bike Shed, I'll choose an acronym so STIR, why not? +STEPH: I like it, causing a stir. +CHRIS: But yeah, so it's a pretty sizable shift in my life. But frankly, I don't even know exactly the shape that the coming weeks will have. So it will be interesting to report back as things evolve and as new concerns and considerations come up. But, yeah, we'll save that for future weeks. For now, what else is up in your world? +STEPH: Yeah, it's been an interesting week. There have been really two things on my mind, so one of them has been focused on writing a task that's going to process a sizable CSV. And then it's going to essentially enqueue a bunch of jobs and send off a bunch of data to other third-party systems. So that's been a big focus of the week. The other topic is what I'm going to call extracting an untrustworthy service into its own service. And I know that’s a bit vague, but I've got both of those topics. So which one would you want to hear about first? +CHRIS: I definitely want to hear about both. But because you veiled it in mystery and said, “An untrustworthy,” that one's just going to call to me a little bit more. So yeah, what about this extracting and untrustworthy service? What more can you say there? +STEPH: Good question. I'm glad that you picked the mysterious one and started there. That feels right. So this is a part of our codebase, and it's very related to also the task that I'm writing. So to provide a bit of context, this particular portion of the codebase manages a big part of where we are sending data from our application over to third-party systems. And it's a very important feature of our application. And it's also probably one of the gnarliest sections of our application in terms of there are tons of conditionals based on which type of service we're sending to or the discreet customer that we're sending it to, and any particular preferences that they need and how we're sending that data. And then there's also just a lot of room for ambiguity and errors. And when we are sending that data, was it actually successful? And what if it was successful, but we still got back error messages? What does that mean? Is that successful with warning? And so there are just a lot of unknowns. +It's also one of the less tested areas of the codebase. So even though it's important, we really don't feel confident making changes at this point until we've added some more test coverage. And testing it can be a beast because right now, we really just want to add some security around that section of the codebase. So we're often going for high-level tests, which are then our slower tests, but then also means it's hard to test the more granular aspects of that code. This is that untrustworthy section of the code in terms that we're a bit skittish to make changes, but yet it's a very active part of the codebase, so not the best place to be. But we also recognize that this part of the codebase would be really well-fitted to live outside of the application. It really doesn't need to live with the rest of the application. And there are other services that need to be able to talk to the service as well. So instead of having it grouped together, which -- It's funny. I see your eyebrows go up when I talk about -- For people who can't see, Chris raised his eyebrows when I talked about extracting this to another service. [chuckles] +CHRIS: That doesn't sound like me at all. I don't ever… +STEPH: [chuckles] And since we do have other services that need to be able to pull data or to talk to this particular portion of the codebase, we are looking to then move it out into its own application, so that way, it can stand alone. It can focus on this one task, and then other services can benefit from it as well. And there's been an interesting discussion around, well, we need to make changes to this codebase. And we also have some recognition that we need to make improvements. Do we go ahead and go heads down for a bit and improve the section of the codebase, add more test coverage, get to understand more of what this code does, where the risks are? Or do we go ahead and extract it in its current form to the new greenfield space and just essentially port it, and then we work on it from that space? And so, there's been a conversation around which one do we do first? And I'll tell you my thoughts, and then I'd love to hear yours. +As one of the primary individuals that's been working in this codebase, my stance has been let's leave it in place for now because I want to build some confidence around what this does. So I really want to have some confident understanding about the requirements, about when we extract this, what is that going to look like? But also, I feel like I'm in a place where I'm starting to understand the beast enough that I want to continue that progress and add some testing around it before then we just move it to this new location. And I can't decide if that's one of those decisions where like, I just feel too close to it, and extracting it feels risky to me. So I feel like we're adding on this extra level of complexity. Like, this is already code that's hard to understand. And then we're going to add this network connection on top of that where then we have to talk to it in a different way. And in my mind, that's adding another level of risk and another level of having to debug this service. So my current approach is let's leave it in place. Let's try to identify some low-hanging fruit. Let's go ahead and add some more tests. And I feel pretty good about that decision. I'm curious, what are your thoughts? +CHRIS: I have a bunch of them. The first is that the story that you're telling here feels like the hero's journey of software development. Like, all right, we got this gnarly bit of the code. It's super important. It's super complicated. It doesn't really have any test coverage for historical reasons that are complicated, but here we are. What do we do? That story feels so true. It feels like there are nine Pixar movies about it if Pixar made movies about writing code, and they would be great movies. +STEPH: That's amazing. [laughs] I would watch those movies. +CHRIS: I think of it like Katrina Owen’s therapeutic refactoring, which I feel like is probably my most referenced...It's one of my two most referenced talks that I bring up on the show all the time, but it is almost exactly about that sort of thing. We've got this gnarly piece of code. It's super important, but nobody really knows how it works. But we know it does work, which is an interesting bit. And so to the question of would you extract as is or would you try and shore it up before you extract it? I am 100% on the side that you are on, which is let's shore this thing up before we move it over. Because moving it over, like you said, that's going to add the additional complexity and failure modes of network latency, network timeouts, async disconnects, whatever, any of those complexities. That's another set of failure modes that you'll be introducing or just complexity and things that you have to think about. So that feels complicated. Also, there's probably a poor analogy that I have in my head. But imagine that you're moving, and your bedroom is just a complete mess, and you're like, oh, there are some old to-go food containers over there. And I haven't done my laundry in a couple of weeks. I'm just going to throw it all on a blanket and take it to the new house, and I'll figure out what I want to keep on the other side. It's like, that doesn't feel like the right move. I would definitely throw some things out before I move to a new house. So I definitely lean in to let's clean this up and understand it so that when it's in the new place, we have a slightly more contained, understood, manageable version of the software to try and extract to a service. +STEPH: I feel very judged for my moving style. +CHRIS: [laughs] I mean, obviously, with software, you're doing the one thing. But did I just describe exactly how you move house? +STEPH: [laughs] +CHRIS: To each their own now, you know, whatever works for you. +STEPH: No, I'm with you. I'm definitely the person that's going to clean up first before I put stuff in boxes. I'm going to try to give away as much stuff as possible. +CHRIS: It's a great time to just figure out what's true in your life or what's true in your software. I am intrigued. So yes, I did raise my eyebrows when you mentioned extracting a service and other services talking to each other. In particular, the way you described this piece of the system, I would be surprised if there weren't data requirements and/or transactional consistency things that you wanted to uphold. And that's one of the main things that causes me concern when we're extracting services is if this thing still needs to know about a bunch of different pieces of data and if it's going to make multiple updates to different records where if one succeeds and the other doesn't, we should roll back the whole thing. You lose all of that by moving to a service. And so that's where my broad…like, I'm always going to question if we're going to surface this. So I'm intrigued. Is this thing a very functional piece of your system where some data comes in, some stuff happens, and you get data out at the end of the day? Or is it more operating on related data within your system and potentially updating records after the fact? +STEPH: Yeah, that's a great point. For this area of the codebase, it does feel more functional in terms that we have data, and we essentially want to notify other people that we have this data, and then we want to share it with them. So there is still that coupling of where we need access to those values. So if we're sending it over to the new system, either that new system needs to be able to read from the same database, or we have to send all of those details over to the new system. So then it can build up the message and then send it over to the other third-party systems. So it feels more functional, but there are still some of those requirements that we need to think about. +CHRIS: Okay. That definitely clarifies things. And I wouldn't say that I have a unified theory of services. But what you're describing feels like the type of service that I'm more open to. It sounds almost like a SendGrid where I want to deal with all of my application data. And then I send a bunch of structured data over to SendGrid, and their job is to send an email and retry as necessary or send a text message or even do a voice call if it's Twilio or something like that. And so they're really good at those weird things and the failure modes that exist in those communication channels. But that's not logic that I need to live in my app. And so what you're describing there definitely makes sense as something that could comfortably be extracted to a service and not have more complexity be introduced by that. You did mention something about services talking to services and other things. So is the idea that this would be extracted, then other parts of the system would also use it to communicate out messages or something like that. +STEPH: Yeah, one of the motivations for extracting this is because we have another application that also wants to perform similar behavior. So now we have two applications that need to do similar work, and they feel more in that line of functional work where it would be great if we could share this. But it doesn't fit in the space that we want to extract it in regards to extract it to a gem and make it shareable. It feels more appropriate for it to be its own service and then also capture. Because the other nice thing that we want to include that we're doing now as well is we want to capture feedback from whenever we are sending that data over to other systems. We want to know, hey, how did it go? Did you give us back that successfully, but maybe with some warnings or some errors? Maybe you accepted the data, but then you also gave us a response about something else. +I think one really important question to consider is when is it trustworthy enough to extract? Because we know we're headed down this path. So at what point are we ready to then go ahead and extract this over to its own service? And that was the more interesting conversation because I think those who were in favor of extracting it now had the concern that we can't add test coverage in its current form. So my first response was if I need to make changes and I can't add test coverage, I will sound the alarm, and we will reconsider. But my goal right now is to turn this untrustworthy service into a little more trust. Just dial up the trust a little bit further, and then we can port this over. So then, as we do add some network complexities on top of this, we will at least have more faith and understanding the underlying behavior of the system. But then we still want to understand that it's not going to be perfect. And we're not going to wait until it's perfect before we do extract it. But that's the tale or the mysterious extracting an untrustworthy service. So I think it will be an interesting journey. And it was a very interesting conversation that I was excited to have your thoughts because I know you and I often lean so far away from extracting stuff to a service that it was an interesting conversation to have around; well, this code is a bit of a mess. When do we start to tackle that mess? +CHRIS: I like that you didn't even frame it necessarily in terms of that, but I still definitely got there. I was like, wait, wait, wait, but let's actually talk about whether or not. But this is definitely the sort of thing that I think makes sense to consider as a service extraction. I think the question that you're asking around when do we feel good enough in its current state to do the extraction? That's right on the line of art in the software world as opposed to the science of this is how we connect HTTP. So I'm very interested to see where you get to both with that question and how you actually make that decision and then how the extraction goes. And I imagine this will be the sort of thing that goes on for a bit of time. So it feels like we could make a mini-story arc that'll span a couple of episodes, and you can follow the characters on their journey. This is the Pixar movie. We're making a Pixar movie. +STEPH: We're making a Pixar movie. They're missing an entire genre for their Pixar movies. If they just appeal to developers, that'd be wonderful. I’m so in for that. We should write Pixar. +CHRIS: There are more developers every day, so think Hackers meets Up. That's what we're going for. We're just going to fuse those two together. It's going to pull at your heartstrings, but it's also going to talk about hacking the Gibson. It's going to be great. +STEPH: Oh man, you reached for the most heartfelt one going for Up. That one has the toughest beginning. [laughs] +CHRIS: That's what I'm going for here. +STEPH: For anyone that hasn't seen Up, you can go watch the beginning of it. Just be prepared. +CHRIS: And if anyone hasn't seen Hackers, also be prepared. [laughs] +STEPH: Which is me. I haven't seen Hackers. +CHRIS: All right. You still haven’t. All right, that's a thing we need to work on. +STEPH: [chuckles] +CHRIS: But cool. Okay. So we're going to work on the Pixar movie. You're going to update us because we need to actually gather the information. But yeah, we'll come back to that in future episodes. But shifting gears just a little bit, actually, I have a couple of things, two small things, and then one more sizable thing that is more just like, I'm confused. So yeah, we're going to go in that order. Thing number one is, we are, again, it's a very early-stage startup that I'm working with. And part of what we're doing that I really like is that we are talking to potential customers, potential end-users of the application doing lots of user interviews, which is a thing that I have more from a distance seen often. But now, because we're actually working as a distributed team, we're remote because that's the nature of the world right now. We'll probably meet each other in person at some point, but that's down the road. But all of these conversations are happening over Zoom calls, all of these user interviews. And so I made the suggestion that we use a tool to actually manage those. And so we're using a tool called EnjoyHQ, I think is the name of it. There's another similar tool called Aurelius. We can put the links in the show notes for both of those. But what it does is it basically makes the video available after the fact. I think it automatically transcribes it, and then it allows you to annotate and add notes and things like that, which is great for aggregating this body of information that we're collecting over time as we do all of these user interviews and start to tag common themes that we're seeing. And bringing them together will also allow us to revisit them. But for me as the developer, I've been to a few of them, but not as many as the rest of the team. And what's great is I've now taken to...as I'm doing more mundane…cleaning up email or whatever sort of tasks, I will just put on one of these videos in the background at 2X. And what's great is I can now just hear literally the voice of the users of the application. What are the words that they're choosing? How are they talking about it? What matters to them? What doesn't matter to them? What do they get really passionate about? And it's been just such a wonderful thing to have available. It's almost like a podcast of our app that we're building, and it's like, that's awesome. +STEPH: I love that. Yeah, I would love to be able to hear from people that are using the application. And like you mentioned, just turn it on in the background so that way I can process what they're saying. But then, I don't know, depending on what they're saying, maybe it needs full attention or otherwise, maybe you're able to just absorb little bits and pieces while you're hacking away on something else. And now I've got the word hacking stuck in my mind. [laughs] +CHRIS: It's the best word to describe what we do. Yeah, there's definitely a version of someone should be reviewing...someone's actually doing the interview, so they're going to be very close to it. And then there maybe is a secondary someone's watching it closely and trying to glean, and categorize, and all of that. And I could potentially be any one of those, but I really like this version of this is just a background soundtrack that I'm exposing myself to so that I'm all the more immersed in the problem space that we are working on. And it's one of the things that I fundamentally believe about software development is developers shouldn't be hidden in the corner just writing code. We should always care about what the end-user wants, and what better way to get there than to actually hear their voice and hear the words that they're using. So this is a magical little trick that I have now found that I'm like, oh my God, this is amazing. +STEPH: Funny enough, I had a similar experience this past week where I realized I was feeling very disconnected from the people that are using the application and also the people that are setting priorities for the work that our team is doing. And that is something that I'm very accustomed to with thoughtbot that we always want to be part of the team. We're not necessarily just we can churn through a backlog. But we also really want to be in touch with product decisions, and share opinions, and then also be in touch with users too. So I had some similar revelations this week where I realized I was feeling very disconnected where I was picking up tickets, and I was like, I don't really understand why this is great or how this is helpful. And so, I shared that with the team, and someone encouraged me to attend a specific meeting. And that was wonderful because then I got to hear from the people who were creating those tickets and then giving them a high priority because something was urgent and why it was urgent. And having that insight was huge to me. And I realized that it was incredibly motivational as well. Because then I'm like, yes, okay, I understand how this is going to impact someone. And I'm now very encouraged to get this done. +CHRIS: I think that idea, that ethos of wanting to get into the user persona and understand that better is a very strong thoughtbot ideal. So it’s unsurprising both of us share that. But yeah, that was a really great thing and particularly a tool that facilitated that in a really straightforward way, which I appreciated. Another thing that I used this week, which I've talked about at length in a previous episode, so we can link to that episode, but it's a project called dry-monad. So there's dry-rb is the collection of, I think, a set of gems, but dry-monad is one that allows for defining sequential tasks, so tasks that you have to do a bunch of steps in order and the outcome of a previous step will be the input of the next part of the process. So it can fail in a bunch of ways like, okay, fetch this thing from the network and then look up a user based on that. And then get the user's profile, which may or may not exist, and then assuming that all of that's gone well, actually persist to this new record, to the database. And they're really finicky to write that sort of sequential processing. And so I actually had written that thing manually. And part of it was I'd wrapped the whole thing in a database transaction, but I was trying to make it so that if something went wrong, I would manually roll back the transaction. And then I wanted to return an object to the caller that indicated that things had failed and an error message or something like that. And that was actually really hard to do because of the way transactions work. +The mechanism that I was using was apparently deprecated in Rails. And so the whole thing was just kind of confusing, and it was a bit messy in the code. And I knew in the back of my mind that dry-monad exists. I've used it before. I've really enjoyed it. But I was trying to minimize the amount of new technologies that I'm bringing in this early on in the project. It's like, yeah, I'll bring that in when I need it. But finally, I was like, you know what? I think I've reached that point. I grabbed it, brought it in, and I haven't worked with it in a while, but I was very quickly able to refactor my class to use dry-monad. It cleaned it up immensely. The tests remained identical, which was really interesting. I didn't have to change anything on the test side. And one of my tests was failing before and then passed because of the introduction of dry-monad. And yeah, it was just like a win-win-win, and also the fact that I was able to revisit dry-monad as a library and just get running with it again was really interesting to me because it is a bit complicated and interesting in how it works. But again, I was able to just sort of pick it up and run with it. So that was wonderful. And I will now all the more staunchly suggest that folks reach for that when they have more complex, procedural type code that they need to write. +STEPH: I remember you highlighting dry-monad before in previous episodes and talking about the pain of writing that sort of procedural code, but then we also want to return something helpful. And I looked at it briefly, but I haven't used it. But now that you are reminding me of it, I'm very interested in it because I agree that process is difficult to write, at least in Ruby it's difficult to write. I understand the hesitancy that you have around bringing something in that's new. But then if you recognize that it's going to be a theme in your application around this is something that we're going to do a fair amount, and we want to do it in a clean, efficient way, then it starts to feel more reasonable to say, “Okay, I'm bringing in something new, but it is representative of how we want to handle this step or this type of process in our application.” So it's not just bringing in a gem to handle one small area of the code, something that we could have written, but it is elevating our process and our system. +CHRIS: Yup. Indeed. In this case, these are command objects within the system. That's actually the name that I got from the creator of the project. That was his suggestion on Twitter as to what to call these objects. And it's a pattern that I do want to encode and has become the standard within the application for any of these more complex processing tasks. So, again, we'll link to the previous episode. I talked about it in more depth and the ideas behind it. Railway Oriented Programming is a phrase that's used, which talks about how to sequence failures or successes and whatnot together. And there's some good material behind it, more general, but yeah, wonderful, little library. +STEPH: What is Railway Oriented Programming? I'm not familiar with that term. +CHRIS: That refers to the sequential processing that I was describing. So imagine that you have a bunch of different steps where first you fetch from the network to get this record, then using what you got back, you look up a user in your database, then you fetch that user's profile. Then you do something else. Each of those steps along the way could fail. And so the railway metaphor is the track is going forward, but if at any point you branch off the track because of a failure, then you're in the failure track, and that's a different thing. And so it's a very...the dry-monad or other similar Railway Oriented Programming or monads generally I think is the actual...it's the words in there. And I wish it wasn't in there because it's such a complicated word. But that idea is the fundamental, underlying thing that's going on there. And it is conceptually somewhat complicated, but if you don't try and think about the category theory behind it, and you're just like, well, I want to do a bunch of stuff, and it may fail at any point, and I want to return either a success message with everything having gone well or an error message at the point that it failed and stopped processing, then that's what this thing does, and it's fantastic at it. +STEPH: Okay, cool. Thank you. +CHRIS: You are welcome. And I think there's a bit more in the previous episode as well. So if that sounded interesting to anyone, I think I rambled more in a previous episode about it and probably better because I feel like I was more prepared that time than this time. +STEPH: Well, along those lines of running a process and then being able to fail at any moment, I'm going to circle back to that other topic that I highlighted where most of my week has been focused on writing a task that is processing a CSV, something probably a number of us have done at some point in our career but processing a number of rows, and then sending and queuing jobs to then send data to a third party system. And it was really interesting less so because of the processing of the CSV and then enqueuing jobs. But it was more of the reporting that went behind it and the process that went into writing this task. So Joël and I were pairing on this task. Joël being another thoughtboter and also a former guest on this show. And we had an interesting process of where we started with one, let's do the simplest thing. Let's get it done. Let's also check through the CSV because you're often going to find stuff that doesn't align with what you expect it to when it's a CSV that's provided from an external source. One of the risks that we highlighted right away was how are we going to get the CSV on the server? Because we just have this one CSV that we need to run. We don't want to add it to the repo, and we can't generate it ourselves. So how are we actually going to get the CSV in a place that we can run this in a production mode? I learned that I could pass a CSV as standard input into the Rake task. So then I could actually run it locally because we're using AWS. So I could inform AWS to run this task, but then I could actually stream the CSV into the task that way. And that was really nice because then we no longer had the question of how are we going to get this file on the server? +CHRIS: That's interesting. I didn't know...Yeah, the streaming of it from local to remote is an interesting one. On Heroku, I will typically open up a bash prompt, so Heroku run bash. And then, I will curl the file down onto the server and then run it locally. But that’s an ephemeral dyno. It may die at any point. There are various things that could go wrong there. So that's always interesting. I imagine a similar thing could be done, but I don't know, actually, if you can directly stream into a Heroku dyno like that, which is an even more straightforward one because I end up having to bounce a file off of a random. Like, I'll often put it in a Gist or a Pastebin or something like that. And then I'll curl it down to the server, and yeah, this is interesting. +STEPH: Yeah, I'm also not sure the specifics of how it would work with Heroku. But it was a really nice process for us to be able to use versus having to then read the file from, like you mentioned, curl it from somewhere else and then be able to parse it that way. Two other things that were top of mind for working on this task is one, idempotency. You're going to rerun it, friends. At some point, your task is either going to bomb, and it's going to err. And then you're going to have to triage and run it again. Or whoever requested that you run this task and they said, “Oh, it's just temporary. We're just going to run the once,” that's not true. You're going to run it again. So keep in mind how to make that safe, that you can rerun it. And then that won't be its own scenario that then you have to triage and figure out. +CHRIS: Idempotency is one of those critical ideas, and I just wish the word were different. I feel ridiculous every time I say it. And I feel like I have to push my glasses up on my nose, and I'm like, well, have we considered idempotency for this? But it's such a good idea. And it's the sort of thing that...you're totally right. Every time you're doing this sort of thing, it is something that you should consider. And we use GET requests, and they have rules about it. And it's such a good idea and such an important idea. And I just wish the word were different so that I felt more comfortable using it in polite conversation. +STEPH: [laughs] I don't know why… and this may be sharing too much of myself. But the song Under Pressure by Queen and David Bowie the Under Pressure song has been in my head. But I've been replacing the under pressure part with idempotent. So it's [singing] under pressure, and I've been [singing] idempotent. [laughter] And that has just been my song for the week. +CHRIS: You've normalized it enough for me now that I'll just hear you singing it every time, and I'll be like, this is a nonsense word. We're fine. We can just go – [laughs] +STEPH: That's what I'm here for, to turn technical terms into nonsense. [laughs] +CHRIS: It's really what this show is about at the end of the day. So you are our hero. +STEPH: I just have to work on more lyrics for the song. I really just have that one line, that one hook. [laughs] +CHRIS: Now I just want to scrap the rest of the episode and just come up with lyrics to idempotent. [chuckles] But maybe we don't do that. +STEPH: [laughs] +CHRIS: Maybe that'll be after the credits B-roll, something like that. +STEPH: The other way I do phrase that question is I'm like, what happens when it fails? And that always feels like a safe way. Because if I ask someone like, “Hey, is the idempotent?” It feels more natural for people to be like, “Oh, it's fine. It doesn't need to be.” But if you say, “What happens when it fails?” It's harder for someone to say, “Oh, it's never going to fail. [laughs] There is nothing that could go wrong.” So it feels like a more intentional question in regards to how are we going to handle this when we need to rerun it? The other part that really came in handy was the fact that we spent more time on the reporting as well. So we really wanted to know what happened when we are processing all of these rows. So were there any invalid rows? And if we do encounter an invalid row, do we want to just stop processing and stop right there, or do we want to keep moving? Do we have any rows that didn't match, a row in our database, and how do we capture those? And because it's idempotent, maybe we want to capture skipped rows so then that way when we rerun it, we can see okay, well, we skipped, you know, a thousand rows because we'd already run them before. And all of that reporting has been so handy because we're also using this to triage. Like, hey, we're sending a bunch of messages to this third-party system. We reach out to that third-party group, and we say, “Hey, we sent you all of this. This is how it went. Let us know how it went on your end.” And then, we can have a more collaborative discussion around what happened on their end versus what happened on our end, and then we can make tweaks to each system. +So overall, it felt more of that run-of-the-mill task where you're going to write a Rake task, you're going to parse a CSV. But something about the reporting really resonated with me because in the past, when I've written Rake tasks, I've leaned more on the this is temporary, so it's okay if it's not great. But the reporting has been so crucial that from now on, I always want reporting from any Rake tasks that I run, and I want to know what happened. And then I also want to be able to rerun it. And I'm very wary of any time that someone says, “Oh, this is temporary,” because then I also think that leads to interesting discussions around testing. Because initially, when we started this, we were under some pressure. Hey, that goes back to my song. We were under some pressure for writing this particular task. And then the question came up: do we want to test it? And to be frank, testing a Rake task isn't great; it’s not fun, which is one of the reasons we get out of a Rake task as quickly as possible and put it into a class. So that was also one of the drivers or one of the conversations that went against, like, oh, this is temporary. So it's okay if it's not the best code. It's okay if it's not tested. And then I was more of an advocate for, like, well, I don't feel good about this. And I'm rerunning the Rake task every time I want to confirm that the changes that I've made are correct. And so once I hit that manual labor point where I'm like, okay, I'm testing this. I just don't have automated tests for this, that then I actually started adding test coverage around it. +CHRIS: I'm so excited that we have transcripts, particularly for that last minute that you were just talking about, because I feel like that was a mini master class in software development. And more generally, there's been almost like a poetic something to the two different topics that you’ve brought up today are the sort of mundane, very real things that actual software development is made almost entirely of. It's not often that we're just starting with a greenfield app and building a new thing. I happen to be doing that this week, but it's rare. It's going to be over very soon. And then I'm going to be in the world of oh; we have to backfill a bunch of data. How are we going to do that? Or we have this portion of the code that, frankly, we should have been testing more, but we didn't. How do we deal with that? And these murky, gray areas where there isn't a clear answer and you have to go with intuition, and you have to...a bunch of the things that you just listed as these good heuristics that you have around how you think about software. I'm just really excited for the transcript to that because that was awesome. +STEPH: I'm so glad you enjoyed it because I think it's not until right now where I'm processing this and talking about it with you that it is...I was trying to think earlier, like, why is this so interesting? Why am I so excited to bring this here to this conversation? And I think it is for the reasons exactly that you said, that it does feel like one of these...this is a mundane task. We write a task; we process some things; we send some data. We do that all the time. But then it's all the other bits around it, and the other ways that we've been bitten, and how we avoid those scenarios, and then how we identify a risk like when someone says, “Oh, it's temporary. It's fine.” That part, I think, is always the very interesting aspect of writing software. +CHRIS: Do you consider this sort of stuff the distraction from the work or actually the work? And in my experience, this makes up a lot of the work. And treating it like what you were saying about testing like, “Yeah, that thing where you're telling me that it's going to be temporary and we probably don't need to test it, I've been told that before,” and I just want to spot-check that real quick. Or what you said of the when I was manually testing, and I crossed a threshold where I'd done that enough, that now adding a test harness around that totally makes sense. It's worth the investment at that point. Those little heuristics that we build up over time are the things that are hard to get. And so, yeah, I love that conversation. +STEPH: I really like how you also asked and then responded to that question around is this distraction, or is this the work? And I am wholeheartedly with you that this is the work. This is the part of the work that I do find interesting, and knowing when to make those trade-offs, and when you've hit a decision point, and which direction you're going to go, and being able to recognize something that otherwise could have been a fire. It could have been much worse in terms of if we'd built a task that wasn't robust. Because of course, then the second time that I ran it, you know, emphasis on the second time that I ran it because we needed to do it again to process more data. It erred halfway through, and I panicked in the moment. But then I was like, oh yeah, this is fine. We planned for this. This was in the game plan. So it goes back to that we want the calm execution. We want to plan so we are back in that calm state. We want calm software. And this feels very in line with how do we make this more calm? +CHRIS: I love that theme that you're bringing up there, which I think is a theme that we've touched on a bunch of times. I think we actually have an episode called Seeking Calm. And I think that little title there, as much as I love the nonsense titles that we have for most of the episodes, that one I think really captures the theme that a lot of what we talk about is in orbit around yeah, we want it to be calm. We don't want things to be on fire every day. And what does it look like to build software with that in mind? +STEPH: Yeah. I also love that theme. And I like that it's something that we have surfaced and then really stuck to because it resonates deeply with me. But that's pretty much all I have for my Rake task adventure. What else is new in your world? +CHRIS: Well, I have one more hopefully quick thing. I'm going to try and boil this down to its essence, but I ran into, let's call it, a subtlety. It's not an issue. It wasn't a bug per se. But looping back to the previous episode that you and I recorded together, we talked a bunch about multi-step forms, which was a great conversation in and of itself. But I eventually completed the feature that I was working on, put it up for acceptance. And the product manager who was reviewing it highlighted a couple of different things. They recorded a video which, as an aside, I love that as a way to do acceptance and show what's going on and talk through it. There were a couple of smaller issues, which I was able to resolve very quickly, but there was one more interesting one that I've extracted this as future work because it was too complex to try and solve in the moment. But basically, what's happening is imagine that we have a two-step form. So there's the first page of the form. The first form that you see is for your name. So it's just an input that says, “Name,” and you fill in your name and then you hit continue. That posts to the server. We save off that data. And then, we redirect you to the next page on the form, which is, say, phone number. So two steps. We start with name; we go to phone number. What happens if you type in your name, you hit continue, everything processes correctly. You end up on the phone number page, but you hit back. What do you think happens? +STEPH: I would expect to go back to the name field and probably expect my name to be populated but would also be fine if it's not. +CHRIS: I like that you would be fine with the fact that it's not, if it's not, because it's not is the answer. And what's unfortunate is so if someone goes back, they will see the unpopulated form, so not filled out. But if they reload at that point, we will serialize down the value and pre-fill the input with their saved data. And so that inconsistency is not great. It's all the more unfortunate because as I tried to resolve it, I'm like, oh, okay, this feels like a solvable thing. I just need to tell Chrome, “Hey, if someone hits the back button, do a better thing than what you're doing.” I needed a way to instruct Chrome or whichever browser because this should be a standards-level thing. And there are things in the HTTP spec about this. So there's the Cache-Control Header is one of the headers that you can send down with a response. And there's a bunch of different values that can be in there, no-cache, no-store. There's also the…I want to say it's the max-age, or I think it's Expires. That's a different header. But you can set it to have an expiry that's just already expired. There's also a Pragma, which you can say no-cache. Some of these are standard. Some of these are not standard. Chrome ignores all of them. Chrome’s just like, “Nevermind.” So the idea is that those headers are intended to inform intermediate proxies. +Say you have a caching layer, so you're using Fastly or CloudFront or something like that. When that service fetches the page from your backend, from your actual, say, Rails app, then it will look at that header and say, “Should I hold onto this for a little while or not? Is it public, or is it private? What should I do as an intermediate caching proxy?” Ideally, Chrome would also look at those and say, like…there should be a version of me being able to tell Chrome, “Listen, if someone hits the back button, please go to the server and ask for it.” Like, I'll take the second of latency that that introduces in navigating back because I always want to show them the correct data. Unfortunately, I have not found a way to do that. There's a bunch of things on Stack Overflow and other places of JavaScript solutions where I can listen to the window.popstate event and then force location.reload. But that feels like a pile of hacks that I don't want to get into. It feels like it will be very inconsistent between browsers. So I am still searching for a solution. But I would like to figure something out here. +As a more pointed version of this to try and explain an example where this could happen, imagine that you've got the header of your application, and in it, you have a sign-out button. And so that sign out is going to delete to the session's endpoint. So you're deleting your session. And after that, you get redirected to the login form. If you then hit back, you will be taken back to the browser’s cached version of the previous logged-in state page that you were at. This is probably fine in a lot of cases. If you reload, you can't do any nefarious action at that point because you are logged out. But you are seeing potentially sensitive information. So imagine that you log in in a cafe, you go through Gmail, or whatever, or your bank, then you log out, you walk away. If you leave that page up and someone hits back, they can now see what was on the page. And part of that particular version, I read a bunch of backstory about that on the Inertia repo because someone posted this as an issue against Inertia as a framework. And the Inertia team...and I really love how they handle these sorts of things. So they were very kind, very welcoming to the issue but also said, “Actually, we're doing...like, this isn't us. But let's talk about it,” and gave a ton of detail and went through the HTTP spec. And it's a fantastic issue as a read. It's like a fun bedtime reading sort of thing to learn about how the internet works. But the Inertia crew really, really cares about being spec-compliant and doing the right thing. So, unfortunately, this is outside of their purview as well. But yeah, I don't have a solution, and it makes me sad. +STEPH: I liked that second example that you provided because I feel like I see that one more commonly when I'm on an application, and I don't know why. But I hit back, and then it shows that I'm signed in, and I'm like, that's a lie, I'm not signed in. I also really appreciate how Inertia is responding so kindly and welcoming to folks and then providing such thoughtful responses. That sounds immensely helpful. I don't know, yeah, I am also interested in this. It's something that I haven't worked with in a while, so I don't have any grand ideas at the moment. So I'm also curious if other people have run into this and how they've approached it. +CHRIS: Yeah. If we're being honest, partly I wanted to share this with you, but also I wanted to say this into a microphone, and then hopefully someone out there on the internet knows an answer. I've tried, I think, all of the normal things, all of the different variations of headers. I haven't actually poked at the JavaScript things yet, but that's probably the direction I'm going. But if anyone out there has an idea, I would absolutely love it. I think in my mind, the ideal version of this is if I'm making GET requests and I'm clicking around on a page, it's perfectly fine for Chrome to use its cache version of the previous page because, sure, that's fine. It may actually be stale just based on it's been a few seconds, and something's changed on the server, but I'm willing to accept that. But if I've posted, or patched, or deleted, or done any action that by definition should be changing data on the server, then I would love for a way to invalidate Chrome's back cache, so its version of the pages that it's restoring when I'm hitting back. I'd love that as the heuristic to get to. I don't know if I can get there. My sense says chrome’s like, “No, I want to go fast. That's all I care about.” [chuckles] I’m like, all right. Well, I get that vibe but -- +STEPH: Yeah, that’s a nice, succinct way to say that if I've changed data, then I want to invalidate that browser cache, so then we don't show them a fresh page and we actually show them the name that they entered on the form. +CHRIS: As we know, though, cache invalidation is one of the very easy things to do in software development. So I'm sure my naive, quick idea is very easy to implement and will have no edge cases of its own. +STEPH: Well, this will be our parallel Pixar movie. We have one that we highlighted earlier, and this will be the other one, The Cache Buster. I'm not great with titles. [laughs] This will be our other Pixar movie. +CHRIS: Buster the Lonely Cache. Yep. +STEPH: All right. Well, in parallel, we'll work on Buster the Lonely Cache. Is that the name of this? +CHRIS: Yep. +STEPH: Cool. We'll work on that script. And in the meantime, I'll also think about it if I encounter this or come up with some ideas and share them with you. And then also if other people have any ideas, that'd be fantastic. +CHRIS: That would be fantastic. +STEPH: Yes. Please write in to help Buster with the lonely cache, which, wait; I don't get it. Why is it the lonely cache? +CHRIS: Because the cache has been busted and evicted. So he's got no friends. There's nothing...There's no data left. I don't know. +STEPH: [laughs] +CHRIS: I came up with it real quick. I don't stand by it. It's not a great idea, but we'll workshop it. It'll be fine. +STEPH: That's true. Yeah, we'll go through it. I'm asking too many questions for a very quick creative. We're in the creative space, not the critical space. But please write in to help Buster figure out [laughs] the lonely cache or how to bust the cache. Oh, goodness. I'm done with my jokes for today. I'll try to stop. +CHRIS: I believe that's a perfect note. Shall we wrap up? +STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. +STEPH: And I’m @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chris gives the deets on that new new – (he joined a startup!) and laments about the back button being so complicated. Steph talks about extracting an untrustworthy service and likens the scenario to making a Pixar movie. You don't wanna miss this hero's journey!

+ + + +

Transcript:

+ +

STEPH: Yes, I was getting text messages from you where you were like, “Go on without me.”

+ +

CHRIS: [laughs] Leave me behind!

+ +

STEPH: [laughs] No developer left behind!!

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I’m Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going?

+ +

STEPH: Hey, Chris. It's been a very busy week. There's been a lot going on. But the most delightful part of my week has been that Eric Bailey, another thoughtboter and also a former guest on this show, has a tiny, little baby bunny living in his backyard, and so he has been sharing updates about this little baby bunny. In fact, he's been sharing some pictures on Twitter as well. So I'll include a link in the show notes so other people can experience the joy. Also, the name of the bunny gets me every time. But they have named the bunny “Corndog.”

+ +

CHRIS: Checks out. It seems like a very obvious name for a small bunny.

+ +

STEPH: It gets me because that's such a big name. I don't know why it's a big name, but it feels like a big name for a little bunny.

+ +

CHRIS: I can say yeah, it's a cornball. Yeah, that's a large name. And so a tiny bunny is a...it's like Little John from Robin Hood. It's perfect.

+ +

STEPH: [chuckles] I kept referring to him as Corn Nugget, I guess, because of size. But yes, it’s not corn nugget; it’s Corndog. [chuckles] So watching Eric's little bunny has been delightful and a wonderful addition to the week. How about you? How has your week been?

+ +

CHRIS: My week has been great. I was off on vacation last week (so you had a guest on), which was fun to just take a week off and reset the system. But actually, this week has been interesting. It was my first full-time week with a new startup that I have joined. I think, yeah, that seems to be the truth in the world. So a bit of a shift from what I've been doing for the last year and a half, almost something like that. The reason there's hesitance in my voice is because I've actually been working with this organization for six months-ish, depending on how you count it. I've been having conversations, and then it’s slowly grown over time where it was just conversations, and then it was an afternoon a week, and then one day a week, and then two, and three. And finally, we decided we think we've got an idea. We've got a thing that we want to build. And so I am the developer on this team, but we are an early-stage startup trying to build something. I'm now full-time on the project. I rotated down the other projects that I was working on from a freelance consulting perspective, and now I'm trying something new. So it's a very different vibe. Even though I'd been working with the organization for a long time, this week just felt so much more real. And there was so much more space, so much more room for activities, having a full week to actually work on things. So yeah, it's very exciting, it’s very new, it's very early stage, so all of those things are true. But there are a lot of great aspects to that, and I'm super excited about it.

+ +

STEPH: That is some big news. That's a big change too. Well, I guess with consulting, there are the stresses that go into consulting and then changing projects and managing the projects that you're taking on. But then to joining a team and such an early startup team too...anytime, someone says startup life, I'm always like, well, tell me more. How calm is the startup life, or how uncalm is this startup life?

+ +

CHRIS: It's somewhere between calm and uncalm, I would say, but in a, I would say purposeful and intentional way. I was looking for...this has largely been true over the entire time that I was freelancing, but freelancing was a way for me to keep the lights on, and stay engaged with tech, and continue working, and frankly, have more conversations and meet more organizations. But I was looking for something that I could engage with a bit more. I was looking for, largely, something like this. So it definitely is occupying a different space in my head than, say, any individual consulting client where with consulting, I was pretty rigid, you know, these are the hours that I'm working. When I'm off the clock, I'm really not thinking about it too much. I'm responsive if I see an incident or something like that or if the database falls over; I’m going to look at that on the weekend but otherwise, largely not doing anything. Whereas with this project, I'm somewhat purposefully allowing it to have a little bit more space in my head off-hours, that sort of thing. And I'm more invested in the work. It's not just a thing that I'm doing, but it's a project that I believe in. It's something that I want to exist in the world. And so, I'm engaged with it in a different way in that manner. I'm also engineer number one, so I'm choosing all of the technologies and setting the standards. Thankfully, there's a lot of good thoughtbot material out there that I can link to, which is great. But yeah, so it's mostly within the context of what I think startups can be. The expectations and the way that the team is working is very reasonable. And I think it's more for my own self. I'm allowing it to occupy a little bit more of my space, but in a fun way so far.

+ +

STEPH: Well, along that line, in terms of choosing the tech stack and starting greenfield, I am curious to hear more about the type of project that you're going to be working on. But I'm also recognizing y'all may be in stealth mode. Is that where you're at, or can you talk a bit more about the type of work you'll be doing?

+ +

CHRIS: We're stealth-ish right now, I would say, partly because we're likely in the process of rebranding, and renaming, and things like that. So partly it's just like, oh, I probably shouldn't say that. But at some point, this will become public, and so at that point, I can probably be a little bit more open about it. But at the end of the day, we're building a financial product, FinTech sort of thing. And the tech stack is relatively straightforward. I'm actually using my preferred tech stack is...I got to choose, so it's Rails, Inertia, and Svelte with some TypeScript because why not? And I love it, and it's fantastic. I continue to believe deeply in that tech stack. So, yeah, that's most of what I think is good to say now. But I think over the coming weeks, I'll be able to say more and share more. And I certainly will be able to talk about the details of building and growing a team and things like that.

+ +

STEPH: Awesome. Yeah, you answered my other question too. I was going to ask what tech stack you chose.

+ +

CHRIS: I chose the tech stack, the one with the acronym, which I don't even know...the STIR stack I think we went with or something.

+ +

STEPH: I was about to say I don't remember the acronym. [laughs]

+ +

CHRIS: I think I never committed to an acronym previously, and then that was the one that got thrown around on the internet. I think I just was like, in the next episode of The Bike Shed, I'll choose an acronym so STIR, why not?

+ +

STEPH: I like it, causing a stir.

+ +

CHRIS: But yeah, so it's a pretty sizable shift in my life. But frankly, I don't even know exactly the shape that the coming weeks will have. So it will be interesting to report back as things evolve and as new concerns and considerations come up. But, yeah, we'll save that for future weeks. For now, what else is up in your world?

+ +

STEPH: Yeah, it's been an interesting week. There have been really two things on my mind, so one of them has been focused on writing a task that's going to process a sizable CSV. And then it's going to essentially enqueue a bunch of jobs and send off a bunch of data to other third-party systems. So that's been a big focus of the week. The other topic is what I'm going to call extracting an untrustworthy service into its own service. And I know that’s a bit vague, but I've got both of those topics. So which one would you want to hear about first?

+ +

CHRIS: I definitely want to hear about both. But because you veiled it in mystery and said, “An untrustworthy,” that one's just going to call to me a little bit more. So yeah, what about this extracting and untrustworthy service? What more can you say there?

+ +

STEPH: Good question. I'm glad that you picked the mysterious one and started there. That feels right. So this is a part of our codebase, and it's very related to also the task that I'm writing. So to provide a bit of context, this particular portion of the codebase manages a big part of where we are sending data from our application over to third-party systems. And it's a very important feature of our application. And it's also probably one of the gnarliest sections of our application in terms of there are tons of conditionals based on which type of service we're sending to or the discreet customer that we're sending it to, and any particular preferences that they need and how we're sending that data. And then there's also just a lot of room for ambiguity and errors. And when we are sending that data, was it actually successful? And what if it was successful, but we still got back error messages? What does that mean? Is that successful with warning? And so there are just a lot of unknowns.

+ +

It's also one of the less tested areas of the codebase. So even though it's important, we really don't feel confident making changes at this point until we've added some more test coverage. And testing it can be a beast because right now, we really just want to add some security around that section of the codebase. So we're often going for high-level tests, which are then our slower tests, but then also means it's hard to test the more granular aspects of that code. This is that untrustworthy section of the code in terms that we're a bit skittish to make changes, but yet it's a very active part of the codebase, so not the best place to be. But we also recognize that this part of the codebase would be really well-fitted to live outside of the application. It really doesn't need to live with the rest of the application. And there are other services that need to be able to talk to the service as well. So instead of having it grouped together, which -- It's funny. I see your eyebrows go up when I talk about -- For people who can't see, Chris raised his eyebrows when I talked about extracting this to another service. [chuckles]

+ +

CHRIS: That doesn't sound like me at all. I don't ever…

+ +

STEPH: [chuckles] And since we do have other services that need to be able to pull data or to talk to this particular portion of the codebase, we are looking to then move it out into its own application, so that way, it can stand alone. It can focus on this one task, and then other services can benefit from it as well. And there's been an interesting discussion around, well, we need to make changes to this codebase. And we also have some recognition that we need to make improvements. Do we go ahead and go heads down for a bit and improve the section of the codebase, add more test coverage, get to understand more of what this code does, where the risks are? Or do we go ahead and extract it in its current form to the new greenfield space and just essentially port it, and then we work on it from that space? And so, there's been a conversation around which one do we do first? And I'll tell you my thoughts, and then I'd love to hear yours.

+ +

As one of the primary individuals that's been working in this codebase, my stance has been let's leave it in place for now because I want to build some confidence around what this does. So I really want to have some confident understanding about the requirements, about when we extract this, what is that going to look like? But also, I feel like I'm in a place where I'm starting to understand the beast enough that I want to continue that progress and add some testing around it before then we just move it to this new location. And I can't decide if that's one of those decisions where like, I just feel too close to it, and extracting it feels risky to me. So I feel like we're adding on this extra level of complexity. Like, this is already code that's hard to understand. And then we're going to add this network connection on top of that where then we have to talk to it in a different way. And in my mind, that's adding another level of risk and another level of having to debug this service. So my current approach is let's leave it in place. Let's try to identify some low-hanging fruit. Let's go ahead and add some more tests. And I feel pretty good about that decision. I'm curious, what are your thoughts?

+ +

CHRIS: I have a bunch of them. The first is that the story that you're telling here feels like the hero's journey of software development. Like, all right, we got this gnarly bit of the code. It's super important. It's super complicated. It doesn't really have any test coverage for historical reasons that are complicated, but here we are. What do we do? That story feels so true. It feels like there are nine Pixar movies about it if Pixar made movies about writing code, and they would be great movies.

+ +

STEPH: That's amazing. [laughs] I would watch those movies.

+ +

CHRIS: I think of it like Katrina Owen’s therapeutic refactoring, which I feel like is probably my most referenced...It's one of my two most referenced talks that I bring up on the show all the time, but it is almost exactly about that sort of thing. We've got this gnarly piece of code. It's super important, but nobody really knows how it works. But we know it does work, which is an interesting bit. And so to the question of would you extract as is or would you try and shore it up before you extract it? I am 100% on the side that you are on, which is let's shore this thing up before we move it over. Because moving it over, like you said, that's going to add the additional complexity and failure modes of network latency, network timeouts, async disconnects, whatever, any of those complexities. That's another set of failure modes that you'll be introducing or just complexity and things that you have to think about. So that feels complicated. Also, there's probably a poor analogy that I have in my head. But imagine that you're moving, and your bedroom is just a complete mess, and you're like, oh, there are some old to-go food containers over there. And I haven't done my laundry in a couple of weeks. I'm just going to throw it all on a blanket and take it to the new house, and I'll figure out what I want to keep on the other side. It's like, that doesn't feel like the right move. I would definitely throw some things out before I move to a new house. So I definitely lean in to let's clean this up and understand it so that when it's in the new place, we have a slightly more contained, understood, manageable version of the software to try and extract to a service.

+ +

STEPH: I feel very judged for my moving style.

+ +

CHRIS: [laughs] I mean, obviously, with software, you're doing the one thing. But did I just describe exactly how you move house?

+ +

STEPH: [laughs]

+ +

CHRIS: To each their own now, you know, whatever works for you.

+ +

STEPH: No, I'm with you. I'm definitely the person that's going to clean up first before I put stuff in boxes. I'm going to try to give away as much stuff as possible.

+ +

CHRIS: It's a great time to just figure out what's true in your life or what's true in your software. I am intrigued. So yes, I did raise my eyebrows when you mentioned extracting a service and other services talking to each other. In particular, the way you described this piece of the system, I would be surprised if there weren't data requirements and/or transactional consistency things that you wanted to uphold. And that's one of the main things that causes me concern when we're extracting services is if this thing still needs to know about a bunch of different pieces of data and if it's going to make multiple updates to different records where if one succeeds and the other doesn't, we should roll back the whole thing. You lose all of that by moving to a service. And so that's where my broad…like, I'm always going to question if we're going to surface this. So I'm intrigued. Is this thing a very functional piece of your system where some data comes in, some stuff happens, and you get data out at the end of the day? Or is it more operating on related data within your system and potentially updating records after the fact?

+ +

STEPH: Yeah, that's a great point. For this area of the codebase, it does feel more functional in terms that we have data, and we essentially want to notify other people that we have this data, and then we want to share it with them. So there is still that coupling of where we need access to those values. So if we're sending it over to the new system, either that new system needs to be able to read from the same database, or we have to send all of those details over to the new system. So then it can build up the message and then send it over to the other third-party systems. So it feels more functional, but there are still some of those requirements that we need to think about.

+ +

CHRIS: Okay. That definitely clarifies things. And I wouldn't say that I have a unified theory of services. But what you're describing feels like the type of service that I'm more open to. It sounds almost like a SendGrid where I want to deal with all of my application data. And then I send a bunch of structured data over to SendGrid, and their job is to send an email and retry as necessary or send a text message or even do a voice call if it's Twilio or something like that. And so they're really good at those weird things and the failure modes that exist in those communication channels. But that's not logic that I need to live in my app. And so what you're describing there definitely makes sense as something that could comfortably be extracted to a service and not have more complexity be introduced by that. You did mention something about services talking to services and other things. So is the idea that this would be extracted, then other parts of the system would also use it to communicate out messages or something like that.

+ +

STEPH: Yeah, one of the motivations for extracting this is because we have another application that also wants to perform similar behavior. So now we have two applications that need to do similar work, and they feel more in that line of functional work where it would be great if we could share this. But it doesn't fit in the space that we want to extract it in regards to extract it to a gem and make it shareable. It feels more appropriate for it to be its own service and then also capture. Because the other nice thing that we want to include that we're doing now as well is we want to capture feedback from whenever we are sending that data over to other systems. We want to know, hey, how did it go? Did you give us back that successfully, but maybe with some warnings or some errors? Maybe you accepted the data, but then you also gave us a response about something else.

+ +

I think one really important question to consider is when is it trustworthy enough to extract? Because we know we're headed down this path. So at what point are we ready to then go ahead and extract this over to its own service? And that was the more interesting conversation because I think those who were in favor of extracting it now had the concern that we can't add test coverage in its current form. So my first response was if I need to make changes and I can't add test coverage, I will sound the alarm, and we will reconsider. But my goal right now is to turn this untrustworthy service into a little more trust. Just dial up the trust a little bit further, and then we can port this over. So then, as we do add some network complexities on top of this, we will at least have more faith and understanding the underlying behavior of the system. But then we still want to understand that it's not going to be perfect. And we're not going to wait until it's perfect before we do extract it. But that's the tale or the mysterious extracting an untrustworthy service. So I think it will be an interesting journey. And it was a very interesting conversation that I was excited to have your thoughts because I know you and I often lean so far away from extracting stuff to a service that it was an interesting conversation to have around; well, this code is a bit of a mess. When do we start to tackle that mess?

+ +

CHRIS: I like that you didn't even frame it necessarily in terms of that, but I still definitely got there. I was like, wait, wait, wait, but let's actually talk about whether or not. But this is definitely the sort of thing that I think makes sense to consider as a service extraction. I think the question that you're asking around when do we feel good enough in its current state to do the extraction? That's right on the line of art in the software world as opposed to the science of this is how we connect HTTP. So I'm very interested to see where you get to both with that question and how you actually make that decision and then how the extraction goes. And I imagine this will be the sort of thing that goes on for a bit of time. So it feels like we could make a mini-story arc that'll span a couple of episodes, and you can follow the characters on their journey. This is the Pixar movie. We're making a Pixar movie.

+ +

STEPH: We're making a Pixar movie. They're missing an entire genre for their Pixar movies. If they just appeal to developers, that'd be wonderful. I’m so in for that. We should write Pixar.

+ +

CHRIS: There are more developers every day, so think Hackers meets Up. That's what we're going for. We're just going to fuse those two together. It's going to pull at your heartstrings, but it's also going to talk about hacking the Gibson. It's going to be great.

+ +

STEPH: Oh man, you reached for the most heartfelt one going for Up. That one has the toughest beginning. [laughs]

+ +

CHRIS: That's what I'm going for here.

+ +

STEPH: For anyone that hasn't seen Up, you can go watch the beginning of it. Just be prepared.

+ +

CHRIS: And if anyone hasn't seen Hackers, also be prepared. [laughs]

+ +

STEPH: Which is me. I haven't seen Hackers.

+ +

CHRIS: All right. You still haven’t. All right, that's a thing we need to work on.

+ +

STEPH: [chuckles]

+ +

CHRIS: But cool. Okay. So we're going to work on the Pixar movie. You're going to update us because we need to actually gather the information. But yeah, we'll come back to that in future episodes. But shifting gears just a little bit, actually, I have a couple of things, two small things, and then one more sizable thing that is more just like, I'm confused. So yeah, we're going to go in that order. Thing number one is, we are, again, it's a very early-stage startup that I'm working with. And part of what we're doing that I really like is that we are talking to potential customers, potential end-users of the application doing lots of user interviews, which is a thing that I have more from a distance seen often. But now, because we're actually working as a distributed team, we're remote because that's the nature of the world right now. We'll probably meet each other in person at some point, but that's down the road. But all of these conversations are happening over Zoom calls, all of these user interviews. And so I made the suggestion that we use a tool to actually manage those. And so we're using a tool called EnjoyHQ, I think is the name of it. There's another similar tool called Aurelius. We can put the links in the show notes for both of those. But what it does is it basically makes the video available after the fact. I think it automatically transcribes it, and then it allows you to annotate and add notes and things like that, which is great for aggregating this body of information that we're collecting over time as we do all of these user interviews and start to tag common themes that we're seeing. And bringing them together will also allow us to revisit them. But for me as the developer, I've been to a few of them, but not as many as the rest of the team. And what's great is I've now taken to...as I'm doing more mundane…cleaning up email or whatever sort of tasks, I will just put on one of these videos in the background at 2X. And what's great is I can now just hear literally the voice of the users of the application. What are the words that they're choosing? How are they talking about it? What matters to them? What doesn't matter to them? What do they get really passionate about? And it's been just such a wonderful thing to have available. It's almost like a podcast of our app that we're building, and it's like, that's awesome.

+ +

STEPH: I love that. Yeah, I would love to be able to hear from people that are using the application. And like you mentioned, just turn it on in the background so that way I can process what they're saying. But then, I don't know, depending on what they're saying, maybe it needs full attention or otherwise, maybe you're able to just absorb little bits and pieces while you're hacking away on something else. And now I've got the word hacking stuck in my mind. [laughs]

+ +

CHRIS: It's the best word to describe what we do. Yeah, there's definitely a version of someone should be reviewing...someone's actually doing the interview, so they're going to be very close to it. And then there maybe is a secondary someone's watching it closely and trying to glean, and categorize, and all of that. And I could potentially be any one of those, but I really like this version of this is just a background soundtrack that I'm exposing myself to so that I'm all the more immersed in the problem space that we are working on. And it's one of the things that I fundamentally believe about software development is developers shouldn't be hidden in the corner just writing code. We should always care about what the end-user wants, and what better way to get there than to actually hear their voice and hear the words that they're using. So this is a magical little trick that I have now found that I'm like, oh my God, this is amazing.

+ +

STEPH: Funny enough, I had a similar experience this past week where I realized I was feeling very disconnected from the people that are using the application and also the people that are setting priorities for the work that our team is doing. And that is something that I'm very accustomed to with thoughtbot that we always want to be part of the team. We're not necessarily just we can churn through a backlog. But we also really want to be in touch with product decisions, and share opinions, and then also be in touch with users too. So I had some similar revelations this week where I realized I was feeling very disconnected where I was picking up tickets, and I was like, I don't really understand why this is great or how this is helpful. And so, I shared that with the team, and someone encouraged me to attend a specific meeting. And that was wonderful because then I got to hear from the people who were creating those tickets and then giving them a high priority because something was urgent and why it was urgent. And having that insight was huge to me. And I realized that it was incredibly motivational as well. Because then I'm like, yes, okay, I understand how this is going to impact someone. And I'm now very encouraged to get this done.

+ +

CHRIS: I think that idea, that ethos of wanting to get into the user persona and understand that better is a very strong thoughtbot ideal. So it’s unsurprising both of us share that. But yeah, that was a really great thing and particularly a tool that facilitated that in a really straightforward way, which I appreciated. Another thing that I used this week, which I've talked about at length in a previous episode, so we can link to that episode, but it's a project called dry-monad. So there's dry-rb is the collection of, I think, a set of gems, but dry-monad is one that allows for defining sequential tasks, so tasks that you have to do a bunch of steps in order and the outcome of a previous step will be the input of the next part of the process. So it can fail in a bunch of ways like, okay, fetch this thing from the network and then look up a user based on that. And then get the user's profile, which may or may not exist, and then assuming that all of that's gone well, actually persist to this new record, to the database. And they're really finicky to write that sort of sequential processing. And so I actually had written that thing manually. And part of it was I'd wrapped the whole thing in a database transaction, but I was trying to make it so that if something went wrong, I would manually roll back the transaction. And then I wanted to return an object to the caller that indicated that things had failed and an error message or something like that. And that was actually really hard to do because of the way transactions work.

+ +

The mechanism that I was using was apparently deprecated in Rails. And so the whole thing was just kind of confusing, and it was a bit messy in the code. And I knew in the back of my mind that dry-monad exists. I've used it before. I've really enjoyed it. But I was trying to minimize the amount of new technologies that I'm bringing in this early on in the project. It's like, yeah, I'll bring that in when I need it. But finally, I was like, you know what? I think I've reached that point. I grabbed it, brought it in, and I haven't worked with it in a while, but I was very quickly able to refactor my class to use dry-monad. It cleaned it up immensely. The tests remained identical, which was really interesting. I didn't have to change anything on the test side. And one of my tests was failing before and then passed because of the introduction of dry-monad. And yeah, it was just like a win-win-win, and also the fact that I was able to revisit dry-monad as a library and just get running with it again was really interesting to me because it is a bit complicated and interesting in how it works. But again, I was able to just sort of pick it up and run with it. So that was wonderful. And I will now all the more staunchly suggest that folks reach for that when they have more complex, procedural type code that they need to write.

+ +

STEPH: I remember you highlighting dry-monad before in previous episodes and talking about the pain of writing that sort of procedural code, but then we also want to return something helpful. And I looked at it briefly, but I haven't used it. But now that you are reminding me of it, I'm very interested in it because I agree that process is difficult to write, at least in Ruby it's difficult to write. I understand the hesitancy that you have around bringing something in that's new. But then if you recognize that it's going to be a theme in your application around this is something that we're going to do a fair amount, and we want to do it in a clean, efficient way, then it starts to feel more reasonable to say, “Okay, I'm bringing in something new, but it is representative of how we want to handle this step or this type of process in our application.” So it's not just bringing in a gem to handle one small area of the code, something that we could have written, but it is elevating our process and our system.

+ +

CHRIS: Yup. Indeed. In this case, these are command objects within the system. That's actually the name that I got from the creator of the project. That was his suggestion on Twitter as to what to call these objects. And it's a pattern that I do want to encode and has become the standard within the application for any of these more complex processing tasks. So, again, we'll link to the previous episode. I talked about it in more depth and the ideas behind it. Railway Oriented Programming is a phrase that's used, which talks about how to sequence failures or successes and whatnot together. And there's some good material behind it, more general, but yeah, wonderful, little library.

+ +

STEPH: What is Railway Oriented Programming? I'm not familiar with that term.

+ +

CHRIS: That refers to the sequential processing that I was describing. So imagine that you have a bunch of different steps where first you fetch from the network to get this record, then using what you got back, you look up a user in your database, then you fetch that user's profile. Then you do something else. Each of those steps along the way could fail. And so the railway metaphor is the track is going forward, but if at any point you branch off the track because of a failure, then you're in the failure track, and that's a different thing. And so it's a very...the dry-monad or other similar Railway Oriented Programming or monads generally I think is the actual...it's the words in there. And I wish it wasn't in there because it's such a complicated word. But that idea is the fundamental, underlying thing that's going on there. And it is conceptually somewhat complicated, but if you don't try and think about the category theory behind it, and you're just like, well, I want to do a bunch of stuff, and it may fail at any point, and I want to return either a success message with everything having gone well or an error message at the point that it failed and stopped processing, then that's what this thing does, and it's fantastic at it.

+ +

STEPH: Okay, cool. Thank you.

+ +

CHRIS: You are welcome. And I think there's a bit more in the previous episode as well. So if that sounded interesting to anyone, I think I rambled more in a previous episode about it and probably better because I feel like I was more prepared that time than this time.

+ +

STEPH: Well, along those lines of running a process and then being able to fail at any moment, I'm going to circle back to that other topic that I highlighted where most of my week has been focused on writing a task that is processing a CSV, something probably a number of us have done at some point in our career but processing a number of rows, and then sending and queuing jobs to then send data to a third party system. And it was really interesting less so because of the processing of the CSV and then enqueuing jobs. But it was more of the reporting that went behind it and the process that went into writing this task. So Joël and I were pairing on this task. Joël being another thoughtboter and also a former guest on this show. And we had an interesting process of where we started with one, let's do the simplest thing. Let's get it done. Let's also check through the CSV because you're often going to find stuff that doesn't align with what you expect it to when it's a CSV that's provided from an external source. One of the risks that we highlighted right away was how are we going to get the CSV on the server? Because we just have this one CSV that we need to run. We don't want to add it to the repo, and we can't generate it ourselves. So how are we actually going to get the CSV in a place that we can run this in a production mode? I learned that I could pass a CSV as standard input into the Rake task. So then I could actually run it locally because we're using AWS. So I could inform AWS to run this task, but then I could actually stream the CSV into the task that way. And that was really nice because then we no longer had the question of how are we going to get this file on the server?

+ +

CHRIS: That's interesting. I didn't know...Yeah, the streaming of it from local to remote is an interesting one. On Heroku, I will typically open up a bash prompt, so Heroku run bash. And then, I will curl the file down onto the server and then run it locally. But that’s an ephemeral dyno. It may die at any point. There are various things that could go wrong there. So that's always interesting. I imagine a similar thing could be done, but I don't know, actually, if you can directly stream into a Heroku dyno like that, which is an even more straightforward one because I end up having to bounce a file off of a random. Like, I'll often put it in a Gist or a Pastebin or something like that. And then I'll curl it down to the server, and yeah, this is interesting.

+ +

STEPH: Yeah, I'm also not sure the specifics of how it would work with Heroku. But it was a really nice process for us to be able to use versus having to then read the file from, like you mentioned, curl it from somewhere else and then be able to parse it that way. Two other things that were top of mind for working on this task is one, idempotency. You're going to rerun it, friends. At some point, your task is either going to bomb, and it's going to err. And then you're going to have to triage and run it again. Or whoever requested that you run this task and they said, “Oh, it's just temporary. We're just going to run the once,” that's not true. You're going to run it again. So keep in mind how to make that safe, that you can rerun it. And then that won't be its own scenario that then you have to triage and figure out.

+ +

CHRIS: Idempotency is one of those critical ideas, and I just wish the word were different. I feel ridiculous every time I say it. And I feel like I have to push my glasses up on my nose, and I'm like, well, have we considered idempotency for this? But it's such a good idea. And it's the sort of thing that...you're totally right. Every time you're doing this sort of thing, it is something that you should consider. And we use GET requests, and they have rules about it. And it's such a good idea and such an important idea. And I just wish the word were different so that I felt more comfortable using it in polite conversation.

+ +

STEPH: [laughs] I don't know why… and this may be sharing too much of myself. But the song Under Pressure by Queen and David Bowie the Under Pressure song has been in my head. But I've been replacing the under pressure part with idempotent. So it's [singing] under pressure, and I've been [singing] idempotent. [laughter] And that has just been my song for the week.

+ +

CHRIS: You've normalized it enough for me now that I'll just hear you singing it every time, and I'll be like, this is a nonsense word. We're fine. We can just go – [laughs]

+ +

STEPH: That's what I'm here for, to turn technical terms into nonsense. [laughs]

+ +

CHRIS: It's really what this show is about at the end of the day. So you are our hero.

+ +

STEPH: I just have to work on more lyrics for the song. I really just have that one line, that one hook. [laughs]

+ +

CHRIS: Now I just want to scrap the rest of the episode and just come up with lyrics to idempotent. [chuckles] But maybe we don't do that.

+ +

STEPH: [laughs]

+ +

CHRIS: Maybe that'll be after the credits B-roll, something like that.

+ +

STEPH: The other way I do phrase that question is I'm like, what happens when it fails? And that always feels like a safe way. Because if I ask someone like, “Hey, is the idempotent?” It feels more natural for people to be like, “Oh, it's fine. It doesn't need to be.” But if you say, “What happens when it fails?” It's harder for someone to say, “Oh, it's never going to fail. [laughs] There is nothing that could go wrong.” So it feels like a more intentional question in regards to how are we going to handle this when we need to rerun it? The other part that really came in handy was the fact that we spent more time on the reporting as well. So we really wanted to know what happened when we are processing all of these rows. So were there any invalid rows? And if we do encounter an invalid row, do we want to just stop processing and stop right there, or do we want to keep moving? Do we have any rows that didn't match, a row in our database, and how do we capture those? And because it's idempotent, maybe we want to capture skipped rows so then that way when we rerun it, we can see okay, well, we skipped, you know, a thousand rows because we'd already run them before. And all of that reporting has been so handy because we're also using this to triage. Like, hey, we're sending a bunch of messages to this third-party system. We reach out to that third-party group, and we say, “Hey, we sent you all of this. This is how it went. Let us know how it went on your end.” And then, we can have a more collaborative discussion around what happened on their end versus what happened on our end, and then we can make tweaks to each system.

+ +

So overall, it felt more of that run-of-the-mill task where you're going to write a Rake task, you're going to parse a CSV. But something about the reporting really resonated with me because in the past, when I've written Rake tasks, I've leaned more on the this is temporary, so it's okay if it's not great. But the reporting has been so crucial that from now on, I always want reporting from any Rake tasks that I run, and I want to know what happened. And then I also want to be able to rerun it. And I'm very wary of any time that someone says, “Oh, this is temporary,” because then I also think that leads to interesting discussions around testing. Because initially, when we started this, we were under some pressure. Hey, that goes back to my song. We were under some pressure for writing this particular task. And then the question came up: do we want to test it? And to be frank, testing a Rake task isn't great; it’s not fun, which is one of the reasons we get out of a Rake task as quickly as possible and put it into a class. So that was also one of the drivers or one of the conversations that went against, like, oh, this is temporary. So it's okay if it's not the best code. It's okay if it's not tested. And then I was more of an advocate for, like, well, I don't feel good about this. And I'm rerunning the Rake task every time I want to confirm that the changes that I've made are correct. And so once I hit that manual labor point where I'm like, okay, I'm testing this. I just don't have automated tests for this, that then I actually started adding test coverage around it.

+ +

CHRIS: I'm so excited that we have transcripts, particularly for that last minute that you were just talking about, because I feel like that was a mini master class in software development. And more generally, there's been almost like a poetic something to the two different topics that you’ve brought up today are the sort of mundane, very real things that actual software development is made almost entirely of. It's not often that we're just starting with a greenfield app and building a new thing. I happen to be doing that this week, but it's rare. It's going to be over very soon. And then I'm going to be in the world of oh; we have to backfill a bunch of data. How are we going to do that? Or we have this portion of the code that, frankly, we should have been testing more, but we didn't. How do we deal with that? And these murky, gray areas where there isn't a clear answer and you have to go with intuition, and you have to...a bunch of the things that you just listed as these good heuristics that you have around how you think about software. I'm just really excited for the transcript to that because that was awesome.

+ +

STEPH: I'm so glad you enjoyed it because I think it's not until right now where I'm processing this and talking about it with you that it is...I was trying to think earlier, like, why is this so interesting? Why am I so excited to bring this here to this conversation? And I think it is for the reasons exactly that you said, that it does feel like one of these...this is a mundane task. We write a task; we process some things; we send some data. We do that all the time. But then it's all the other bits around it, and the other ways that we've been bitten, and how we avoid those scenarios, and then how we identify a risk like when someone says, “Oh, it's temporary. It's fine.” That part, I think, is always the very interesting aspect of writing software.

+ +

CHRIS: Do you consider this sort of stuff the distraction from the work or actually the work? And in my experience, this makes up a lot of the work. And treating it like what you were saying about testing like, “Yeah, that thing where you're telling me that it's going to be temporary and we probably don't need to test it, I've been told that before,” and I just want to spot-check that real quick. Or what you said of the when I was manually testing, and I crossed a threshold where I'd done that enough, that now adding a test harness around that totally makes sense. It's worth the investment at that point. Those little heuristics that we build up over time are the things that are hard to get. And so, yeah, I love that conversation.

+ +

STEPH: I really like how you also asked and then responded to that question around is this distraction, or is this the work? And I am wholeheartedly with you that this is the work. This is the part of the work that I do find interesting, and knowing when to make those trade-offs, and when you've hit a decision point, and which direction you're going to go, and being able to recognize something that otherwise could have been a fire. It could have been much worse in terms of if we'd built a task that wasn't robust. Because of course, then the second time that I ran it, you know, emphasis on the second time that I ran it because we needed to do it again to process more data. It erred halfway through, and I panicked in the moment. But then I was like, oh yeah, this is fine. We planned for this. This was in the game plan. So it goes back to that we want the calm execution. We want to plan so we are back in that calm state. We want calm software. And this feels very in line with how do we make this more calm?

+ +

CHRIS: I love that theme that you're bringing up there, which I think is a theme that we've touched on a bunch of times. I think we actually have an episode called Seeking Calm. And I think that little title there, as much as I love the nonsense titles that we have for most of the episodes, that one I think really captures the theme that a lot of what we talk about is in orbit around yeah, we want it to be calm. We don't want things to be on fire every day. And what does it look like to build software with that in mind?

+ +

STEPH: Yeah. I also love that theme. And I like that it's something that we have surfaced and then really stuck to because it resonates deeply with me. But that's pretty much all I have for my Rake task adventure. What else is new in your world?

+ +

CHRIS: Well, I have one more hopefully quick thing. I'm going to try and boil this down to its essence, but I ran into, let's call it, a subtlety. It's not an issue. It wasn't a bug per se. But looping back to the previous episode that you and I recorded together, we talked a bunch about multi-step forms, which was a great conversation in and of itself. But I eventually completed the feature that I was working on, put it up for acceptance. And the product manager who was reviewing it highlighted a couple of different things. They recorded a video which, as an aside, I love that as a way to do acceptance and show what's going on and talk through it. There were a couple of smaller issues, which I was able to resolve very quickly, but there was one more interesting one that I've extracted this as future work because it was too complex to try and solve in the moment. But basically, what's happening is imagine that we have a two-step form. So there's the first page of the form. The first form that you see is for your name. So it's just an input that says, “Name,” and you fill in your name and then you hit continue. That posts to the server. We save off that data. And then, we redirect you to the next page on the form, which is, say, phone number. So two steps. We start with name; we go to phone number. What happens if you type in your name, you hit continue, everything processes correctly. You end up on the phone number page, but you hit back. What do you think happens?

+ +

STEPH: I would expect to go back to the name field and probably expect my name to be populated but would also be fine if it's not.

+ +

CHRIS: I like that you would be fine with the fact that it's not, if it's not, because it's not is the answer. And what's unfortunate is so if someone goes back, they will see the unpopulated form, so not filled out. But if they reload at that point, we will serialize down the value and pre-fill the input with their saved data. And so that inconsistency is not great. It's all the more unfortunate because as I tried to resolve it, I'm like, oh, okay, this feels like a solvable thing. I just need to tell Chrome, “Hey, if someone hits the back button, do a better thing than what you're doing.” I needed a way to instruct Chrome or whichever browser because this should be a standards-level thing. And there are things in the HTTP spec about this. So there's the Cache-Control Header is one of the headers that you can send down with a response. And there's a bunch of different values that can be in there, no-cache, no-store. There's also the…I want to say it's the max-age, or I think it's Expires. That's a different header. But you can set it to have an expiry that's just already expired. There's also a Pragma, which you can say no-cache. Some of these are standard. Some of these are not standard. Chrome ignores all of them. Chrome’s just like, “Nevermind.” So the idea is that those headers are intended to inform intermediate proxies.

+ +

Say you have a caching layer, so you're using Fastly or CloudFront or something like that. When that service fetches the page from your backend, from your actual, say, Rails app, then it will look at that header and say, “Should I hold onto this for a little while or not? Is it public, or is it private? What should I do as an intermediate caching proxy?” Ideally, Chrome would also look at those and say, like…there should be a version of me being able to tell Chrome, “Listen, if someone hits the back button, please go to the server and ask for it.” Like, I'll take the second of latency that that introduces in navigating back because I always want to show them the correct data. Unfortunately, I have not found a way to do that. There's a bunch of things on Stack Overflow and other places of JavaScript solutions where I can listen to the window.popstate event and then force location.reload. But that feels like a pile of hacks that I don't want to get into. It feels like it will be very inconsistent between browsers. So I am still searching for a solution. But I would like to figure something out here.

+ +

As a more pointed version of this to try and explain an example where this could happen, imagine that you've got the header of your application, and in it, you have a sign-out button. And so that sign out is going to delete to the session's endpoint. So you're deleting your session. And after that, you get redirected to the login form. If you then hit back, you will be taken back to the browser’s cached version of the previous logged-in state page that you were at. This is probably fine in a lot of cases. If you reload, you can't do any nefarious action at that point because you are logged out. But you are seeing potentially sensitive information. So imagine that you log in in a cafe, you go through Gmail, or whatever, or your bank, then you log out, you walk away. If you leave that page up and someone hits back, they can now see what was on the page. And part of that particular version, I read a bunch of backstory about that on the Inertia repo because someone posted this as an issue against Inertia as a framework. And the Inertia team...and I really love how they handle these sorts of things. So they were very kind, very welcoming to the issue but also said, “Actually, we're doing...like, this isn't us. But let's talk about it,” and gave a ton of detail and went through the HTTP spec. And it's a fantastic issue as a read. It's like a fun bedtime reading sort of thing to learn about how the internet works. But the Inertia crew really, really cares about being spec-compliant and doing the right thing. So, unfortunately, this is outside of their purview as well. But yeah, I don't have a solution, and it makes me sad.

+ +

STEPH: I liked that second example that you provided because I feel like I see that one more commonly when I'm on an application, and I don't know why. But I hit back, and then it shows that I'm signed in, and I'm like, that's a lie, I'm not signed in. I also really appreciate how Inertia is responding so kindly and welcoming to folks and then providing such thoughtful responses. That sounds immensely helpful. I don't know, yeah, I am also interested in this. It's something that I haven't worked with in a while, so I don't have any grand ideas at the moment. So I'm also curious if other people have run into this and how they've approached it.

+ +

CHRIS: Yeah. If we're being honest, partly I wanted to share this with you, but also I wanted to say this into a microphone, and then hopefully someone out there on the internet knows an answer. I've tried, I think, all of the normal things, all of the different variations of headers. I haven't actually poked at the JavaScript things yet, but that's probably the direction I'm going. But if anyone out there has an idea, I would absolutely love it. I think in my mind, the ideal version of this is if I'm making GET requests and I'm clicking around on a page, it's perfectly fine for Chrome to use its cache version of the previous page because, sure, that's fine. It may actually be stale just based on it's been a few seconds, and something's changed on the server, but I'm willing to accept that. But if I've posted, or patched, or deleted, or done any action that by definition should be changing data on the server, then I would love for a way to invalidate Chrome's back cache, so its version of the pages that it's restoring when I'm hitting back. I'd love that as the heuristic to get to. I don't know if I can get there. My sense says chrome’s like, “No, I want to go fast. That's all I care about.” [chuckles] I’m like, all right. Well, I get that vibe but --

+ +

STEPH: Yeah, that’s a nice, succinct way to say that if I've changed data, then I want to invalidate that browser cache, so then we don't show them a fresh page and we actually show them the name that they entered on the form.

+ +

CHRIS: As we know, though, cache invalidation is one of the very easy things to do in software development. So I'm sure my naive, quick idea is very easy to implement and will have no edge cases of its own.

+ +

STEPH: Well, this will be our parallel Pixar movie. We have one that we highlighted earlier, and this will be the other one, The Cache Buster. I'm not great with titles. [laughs] This will be our other Pixar movie.

+ +

CHRIS: Buster the Lonely Cache. Yep.

+ +

STEPH: All right. Well, in parallel, we'll work on Buster the Lonely Cache. Is that the name of this?

+ +

CHRIS: Yep.

+ +

STEPH: Cool. We'll work on that script. And in the meantime, I'll also think about it if I encounter this or come up with some ideas and share them with you. And then also if other people have any ideas, that'd be fantastic.

+ +

CHRIS: That would be fantastic.

+ +

STEPH: Yes. Please write in to help Buster with the lonely cache, which, wait; I don't get it. Why is it the lonely cache?

+ +

CHRIS: Because the cache has been busted and evicted. So he's got no friends. There's nothing...There's no data left. I don't know.

+ +

STEPH: [laughs]

+ +

CHRIS: I came up with it real quick. I don't stand by it. It's not a great idea, but we'll workshop it. It'll be fine.

+ +

STEPH: That's true. Yeah, we'll go through it. I'm asking too many questions for a very quick creative. We're in the creative space, not the critical space. But please write in to help Buster figure out [laughs] the lonely cache or how to bust the cache. Oh, goodness. I'm done with my jokes for today. I'll try to stop.

+ +

CHRIS: I believe that's a perfect note. Shall we wrap up?

+ +

STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Chris gives the deets on that new new – (he joined a startup!) and laments about the back button being so complicated. Steph talks about extracting an untrustworthy service and likens the scenario to making a Pixar movie. You don't wanna miss this hero's journey!

+ + + +

Transcript:

+ +

STEPH: Yes, I was getting text messages from you where you were like, “Go on without me.”

+ +

CHRIS: [laughs] Leave me behind!

+ +

STEPH: [laughs] No developer left behind!!

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I’m Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, how's your week going?

+ +

STEPH: Hey, Chris. It's been a very busy week. There's been a lot going on. But the most delightful part of my week has been that Eric Bailey, another thoughtboter and also a former guest on this show, has a tiny, little baby bunny living in his backyard, and so he has been sharing updates about this little baby bunny. In fact, he's been sharing some pictures on Twitter as well. So I'll include a link in the show notes so other people can experience the joy. Also, the name of the bunny gets me every time. But they have named the bunny “Corndog.”

+ +

CHRIS: Checks out. It seems like a very obvious name for a small bunny.

+ +

STEPH: It gets me because that's such a big name. I don't know why it's a big name, but it feels like a big name for a little bunny.

+ +

CHRIS: I can say yeah, it's a cornball. Yeah, that's a large name. And so a tiny bunny is a...it's like Little John from Robin Hood. It's perfect.

+ +

STEPH: [chuckles] I kept referring to him as Corn Nugget, I guess, because of size. But yes, it’s not corn nugget; it’s Corndog. [chuckles] So watching Eric's little bunny has been delightful and a wonderful addition to the week. How about you? How has your week been?

+ +

CHRIS: My week has been great. I was off on vacation last week (so you had a guest on), which was fun to just take a week off and reset the system. But actually, this week has been interesting. It was my first full-time week with a new startup that I have joined. I think, yeah, that seems to be the truth in the world. So a bit of a shift from what I've been doing for the last year and a half, almost something like that. The reason there's hesitance in my voice is because I've actually been working with this organization for six months-ish, depending on how you count it. I've been having conversations, and then it’s slowly grown over time where it was just conversations, and then it was an afternoon a week, and then one day a week, and then two, and three. And finally, we decided we think we've got an idea. We've got a thing that we want to build. And so I am the developer on this team, but we are an early-stage startup trying to build something. I'm now full-time on the project. I rotated down the other projects that I was working on from a freelance consulting perspective, and now I'm trying something new. So it's a very different vibe. Even though I'd been working with the organization for a long time, this week just felt so much more real. And there was so much more space, so much more room for activities, having a full week to actually work on things. So yeah, it's very exciting, it’s very new, it's very early stage, so all of those things are true. But there are a lot of great aspects to that, and I'm super excited about it.

+ +

STEPH: That is some big news. That's a big change too. Well, I guess with consulting, there are the stresses that go into consulting and then changing projects and managing the projects that you're taking on. But then to joining a team and such an early startup team too...anytime, someone says startup life, I'm always like, well, tell me more. How calm is the startup life, or how uncalm is this startup life?

+ +

CHRIS: It's somewhere between calm and uncalm, I would say, but in a, I would say purposeful and intentional way. I was looking for...this has largely been true over the entire time that I was freelancing, but freelancing was a way for me to keep the lights on, and stay engaged with tech, and continue working, and frankly, have more conversations and meet more organizations. But I was looking for something that I could engage with a bit more. I was looking for, largely, something like this. So it definitely is occupying a different space in my head than, say, any individual consulting client where with consulting, I was pretty rigid, you know, these are the hours that I'm working. When I'm off the clock, I'm really not thinking about it too much. I'm responsive if I see an incident or something like that or if the database falls over; I’m going to look at that on the weekend but otherwise, largely not doing anything. Whereas with this project, I'm somewhat purposefully allowing it to have a little bit more space in my head off-hours, that sort of thing. And I'm more invested in the work. It's not just a thing that I'm doing, but it's a project that I believe in. It's something that I want to exist in the world. And so, I'm engaged with it in a different way in that manner. I'm also engineer number one, so I'm choosing all of the technologies and setting the standards. Thankfully, there's a lot of good thoughtbot material out there that I can link to, which is great. But yeah, so it's mostly within the context of what I think startups can be. The expectations and the way that the team is working is very reasonable. And I think it's more for my own self. I'm allowing it to occupy a little bit more of my space, but in a fun way so far.

+ +

STEPH: Well, along that line, in terms of choosing the tech stack and starting greenfield, I am curious to hear more about the type of project that you're going to be working on. But I'm also recognizing y'all may be in stealth mode. Is that where you're at, or can you talk a bit more about the type of work you'll be doing?

+ +

CHRIS: We're stealth-ish right now, I would say, partly because we're likely in the process of rebranding, and renaming, and things like that. So partly it's just like, oh, I probably shouldn't say that. But at some point, this will become public, and so at that point, I can probably be a little bit more open about it. But at the end of the day, we're building a financial product, FinTech sort of thing. And the tech stack is relatively straightforward. I'm actually using my preferred tech stack is...I got to choose, so it's Rails, Inertia, and Svelte with some TypeScript because why not? And I love it, and it's fantastic. I continue to believe deeply in that tech stack. So, yeah, that's most of what I think is good to say now. But I think over the coming weeks, I'll be able to say more and share more. And I certainly will be able to talk about the details of building and growing a team and things like that.

+ +

STEPH: Awesome. Yeah, you answered my other question too. I was going to ask what tech stack you chose.

+ +

CHRIS: I chose the tech stack, the one with the acronym, which I don't even know...the STIR stack I think we went with or something.

+ +

STEPH: I was about to say I don't remember the acronym. [laughs]

+ +

CHRIS: I think I never committed to an acronym previously, and then that was the one that got thrown around on the internet. I think I just was like, in the next episode of The Bike Shed, I'll choose an acronym so STIR, why not?

+ +

STEPH: I like it, causing a stir.

+ +

CHRIS: But yeah, so it's a pretty sizable shift in my life. But frankly, I don't even know exactly the shape that the coming weeks will have. So it will be interesting to report back as things evolve and as new concerns and considerations come up. But, yeah, we'll save that for future weeks. For now, what else is up in your world?

+ +

STEPH: Yeah, it's been an interesting week. There have been really two things on my mind, so one of them has been focused on writing a task that's going to process a sizable CSV. And then it's going to essentially enqueue a bunch of jobs and send off a bunch of data to other third-party systems. So that's been a big focus of the week. The other topic is what I'm going to call extracting an untrustworthy service into its own service. And I know that’s a bit vague, but I've got both of those topics. So which one would you want to hear about first?

+ +

CHRIS: I definitely want to hear about both. But because you veiled it in mystery and said, “An untrustworthy,” that one's just going to call to me a little bit more. So yeah, what about this extracting and untrustworthy service? What more can you say there?

+ +

STEPH: Good question. I'm glad that you picked the mysterious one and started there. That feels right. So this is a part of our codebase, and it's very related to also the task that I'm writing. So to provide a bit of context, this particular portion of the codebase manages a big part of where we are sending data from our application over to third-party systems. And it's a very important feature of our application. And it's also probably one of the gnarliest sections of our application in terms of there are tons of conditionals based on which type of service we're sending to or the discreet customer that we're sending it to, and any particular preferences that they need and how we're sending that data. And then there's also just a lot of room for ambiguity and errors. And when we are sending that data, was it actually successful? And what if it was successful, but we still got back error messages? What does that mean? Is that successful with warning? And so there are just a lot of unknowns.

+ +

It's also one of the less tested areas of the codebase. So even though it's important, we really don't feel confident making changes at this point until we've added some more test coverage. And testing it can be a beast because right now, we really just want to add some security around that section of the codebase. So we're often going for high-level tests, which are then our slower tests, but then also means it's hard to test the more granular aspects of that code. This is that untrustworthy section of the code in terms that we're a bit skittish to make changes, but yet it's a very active part of the codebase, so not the best place to be. But we also recognize that this part of the codebase would be really well-fitted to live outside of the application. It really doesn't need to live with the rest of the application. And there are other services that need to be able to talk to the service as well. So instead of having it grouped together, which -- It's funny. I see your eyebrows go up when I talk about -- For people who can't see, Chris raised his eyebrows when I talked about extracting this to another service. [chuckles]

+ +

CHRIS: That doesn't sound like me at all. I don't ever…

+ +

STEPH: [chuckles] And since we do have other services that need to be able to pull data or to talk to this particular portion of the codebase, we are looking to then move it out into its own application, so that way, it can stand alone. It can focus on this one task, and then other services can benefit from it as well. And there's been an interesting discussion around, well, we need to make changes to this codebase. And we also have some recognition that we need to make improvements. Do we go ahead and go heads down for a bit and improve the section of the codebase, add more test coverage, get to understand more of what this code does, where the risks are? Or do we go ahead and extract it in its current form to the new greenfield space and just essentially port it, and then we work on it from that space? And so, there's been a conversation around which one do we do first? And I'll tell you my thoughts, and then I'd love to hear yours.

+ +

As one of the primary individuals that's been working in this codebase, my stance has been let's leave it in place for now because I want to build some confidence around what this does. So I really want to have some confident understanding about the requirements, about when we extract this, what is that going to look like? But also, I feel like I'm in a place where I'm starting to understand the beast enough that I want to continue that progress and add some testing around it before then we just move it to this new location. And I can't decide if that's one of those decisions where like, I just feel too close to it, and extracting it feels risky to me. So I feel like we're adding on this extra level of complexity. Like, this is already code that's hard to understand. And then we're going to add this network connection on top of that where then we have to talk to it in a different way. And in my mind, that's adding another level of risk and another level of having to debug this service. So my current approach is let's leave it in place. Let's try to identify some low-hanging fruit. Let's go ahead and add some more tests. And I feel pretty good about that decision. I'm curious, what are your thoughts?

+ +

CHRIS: I have a bunch of them. The first is that the story that you're telling here feels like the hero's journey of software development. Like, all right, we got this gnarly bit of the code. It's super important. It's super complicated. It doesn't really have any test coverage for historical reasons that are complicated, but here we are. What do we do? That story feels so true. It feels like there are nine Pixar movies about it if Pixar made movies about writing code, and they would be great movies.

+ +

STEPH: That's amazing. [laughs] I would watch those movies.

+ +

CHRIS: I think of it like Katrina Owen’s therapeutic refactoring, which I feel like is probably my most referenced...It's one of my two most referenced talks that I bring up on the show all the time, but it is almost exactly about that sort of thing. We've got this gnarly piece of code. It's super important, but nobody really knows how it works. But we know it does work, which is an interesting bit. And so to the question of would you extract as is or would you try and shore it up before you extract it? I am 100% on the side that you are on, which is let's shore this thing up before we move it over. Because moving it over, like you said, that's going to add the additional complexity and failure modes of network latency, network timeouts, async disconnects, whatever, any of those complexities. That's another set of failure modes that you'll be introducing or just complexity and things that you have to think about. So that feels complicated. Also, there's probably a poor analogy that I have in my head. But imagine that you're moving, and your bedroom is just a complete mess, and you're like, oh, there are some old to-go food containers over there. And I haven't done my laundry in a couple of weeks. I'm just going to throw it all on a blanket and take it to the new house, and I'll figure out what I want to keep on the other side. It's like, that doesn't feel like the right move. I would definitely throw some things out before I move to a new house. So I definitely lean in to let's clean this up and understand it so that when it's in the new place, we have a slightly more contained, understood, manageable version of the software to try and extract to a service.

+ +

STEPH: I feel very judged for my moving style.

+ +

CHRIS: [laughs] I mean, obviously, with software, you're doing the one thing. But did I just describe exactly how you move house?

+ +

STEPH: [laughs]

+ +

CHRIS: To each their own now, you know, whatever works for you.

+ +

STEPH: No, I'm with you. I'm definitely the person that's going to clean up first before I put stuff in boxes. I'm going to try to give away as much stuff as possible.

+ +

CHRIS: It's a great time to just figure out what's true in your life or what's true in your software. I am intrigued. So yes, I did raise my eyebrows when you mentioned extracting a service and other services talking to each other. In particular, the way you described this piece of the system, I would be surprised if there weren't data requirements and/or transactional consistency things that you wanted to uphold. And that's one of the main things that causes me concern when we're extracting services is if this thing still needs to know about a bunch of different pieces of data and if it's going to make multiple updates to different records where if one succeeds and the other doesn't, we should roll back the whole thing. You lose all of that by moving to a service. And so that's where my broad…like, I'm always going to question if we're going to surface this. So I'm intrigued. Is this thing a very functional piece of your system where some data comes in, some stuff happens, and you get data out at the end of the day? Or is it more operating on related data within your system and potentially updating records after the fact?

+ +

STEPH: Yeah, that's a great point. For this area of the codebase, it does feel more functional in terms that we have data, and we essentially want to notify other people that we have this data, and then we want to share it with them. So there is still that coupling of where we need access to those values. So if we're sending it over to the new system, either that new system needs to be able to read from the same database, or we have to send all of those details over to the new system. So then it can build up the message and then send it over to the other third-party systems. So it feels more functional, but there are still some of those requirements that we need to think about.

+ +

CHRIS: Okay. That definitely clarifies things. And I wouldn't say that I have a unified theory of services. But what you're describing feels like the type of service that I'm more open to. It sounds almost like a SendGrid where I want to deal with all of my application data. And then I send a bunch of structured data over to SendGrid, and their job is to send an email and retry as necessary or send a text message or even do a voice call if it's Twilio or something like that. And so they're really good at those weird things and the failure modes that exist in those communication channels. But that's not logic that I need to live in my app. And so what you're describing there definitely makes sense as something that could comfortably be extracted to a service and not have more complexity be introduced by that. You did mention something about services talking to services and other things. So is the idea that this would be extracted, then other parts of the system would also use it to communicate out messages or something like that.

+ +

STEPH: Yeah, one of the motivations for extracting this is because we have another application that also wants to perform similar behavior. So now we have two applications that need to do similar work, and they feel more in that line of functional work where it would be great if we could share this. But it doesn't fit in the space that we want to extract it in regards to extract it to a gem and make it shareable. It feels more appropriate for it to be its own service and then also capture. Because the other nice thing that we want to include that we're doing now as well is we want to capture feedback from whenever we are sending that data over to other systems. We want to know, hey, how did it go? Did you give us back that successfully, but maybe with some warnings or some errors? Maybe you accepted the data, but then you also gave us a response about something else.

+ +

I think one really important question to consider is when is it trustworthy enough to extract? Because we know we're headed down this path. So at what point are we ready to then go ahead and extract this over to its own service? And that was the more interesting conversation because I think those who were in favor of extracting it now had the concern that we can't add test coverage in its current form. So my first response was if I need to make changes and I can't add test coverage, I will sound the alarm, and we will reconsider. But my goal right now is to turn this untrustworthy service into a little more trust. Just dial up the trust a little bit further, and then we can port this over. So then, as we do add some network complexities on top of this, we will at least have more faith and understanding the underlying behavior of the system. But then we still want to understand that it's not going to be perfect. And we're not going to wait until it's perfect before we do extract it. But that's the tale or the mysterious extracting an untrustworthy service. So I think it will be an interesting journey. And it was a very interesting conversation that I was excited to have your thoughts because I know you and I often lean so far away from extracting stuff to a service that it was an interesting conversation to have around; well, this code is a bit of a mess. When do we start to tackle that mess?

+ +

CHRIS: I like that you didn't even frame it necessarily in terms of that, but I still definitely got there. I was like, wait, wait, wait, but let's actually talk about whether or not. But this is definitely the sort of thing that I think makes sense to consider as a service extraction. I think the question that you're asking around when do we feel good enough in its current state to do the extraction? That's right on the line of art in the software world as opposed to the science of this is how we connect HTTP. So I'm very interested to see where you get to both with that question and how you actually make that decision and then how the extraction goes. And I imagine this will be the sort of thing that goes on for a bit of time. So it feels like we could make a mini-story arc that'll span a couple of episodes, and you can follow the characters on their journey. This is the Pixar movie. We're making a Pixar movie.

+ +

STEPH: We're making a Pixar movie. They're missing an entire genre for their Pixar movies. If they just appeal to developers, that'd be wonderful. I’m so in for that. We should write Pixar.

+ +

CHRIS: There are more developers every day, so think Hackers meets Up. That's what we're going for. We're just going to fuse those two together. It's going to pull at your heartstrings, but it's also going to talk about hacking the Gibson. It's going to be great.

+ +

STEPH: Oh man, you reached for the most heartfelt one going for Up. That one has the toughest beginning. [laughs]

+ +

CHRIS: That's what I'm going for here.

+ +

STEPH: For anyone that hasn't seen Up, you can go watch the beginning of it. Just be prepared.

+ +

CHRIS: And if anyone hasn't seen Hackers, also be prepared. [laughs]

+ +

STEPH: Which is me. I haven't seen Hackers.

+ +

CHRIS: All right. You still haven’t. All right, that's a thing we need to work on.

+ +

STEPH: [chuckles]

+ +

CHRIS: But cool. Okay. So we're going to work on the Pixar movie. You're going to update us because we need to actually gather the information. But yeah, we'll come back to that in future episodes. But shifting gears just a little bit, actually, I have a couple of things, two small things, and then one more sizable thing that is more just like, I'm confused. So yeah, we're going to go in that order. Thing number one is, we are, again, it's a very early-stage startup that I'm working with. And part of what we're doing that I really like is that we are talking to potential customers, potential end-users of the application doing lots of user interviews, which is a thing that I have more from a distance seen often. But now, because we're actually working as a distributed team, we're remote because that's the nature of the world right now. We'll probably meet each other in person at some point, but that's down the road. But all of these conversations are happening over Zoom calls, all of these user interviews. And so I made the suggestion that we use a tool to actually manage those. And so we're using a tool called EnjoyHQ, I think is the name of it. There's another similar tool called Aurelius. We can put the links in the show notes for both of those. But what it does is it basically makes the video available after the fact. I think it automatically transcribes it, and then it allows you to annotate and add notes and things like that, which is great for aggregating this body of information that we're collecting over time as we do all of these user interviews and start to tag common themes that we're seeing. And bringing them together will also allow us to revisit them. But for me as the developer, I've been to a few of them, but not as many as the rest of the team. And what's great is I've now taken to...as I'm doing more mundane…cleaning up email or whatever sort of tasks, I will just put on one of these videos in the background at 2X. And what's great is I can now just hear literally the voice of the users of the application. What are the words that they're choosing? How are they talking about it? What matters to them? What doesn't matter to them? What do they get really passionate about? And it's been just such a wonderful thing to have available. It's almost like a podcast of our app that we're building, and it's like, that's awesome.

+ +

STEPH: I love that. Yeah, I would love to be able to hear from people that are using the application. And like you mentioned, just turn it on in the background so that way I can process what they're saying. But then, I don't know, depending on what they're saying, maybe it needs full attention or otherwise, maybe you're able to just absorb little bits and pieces while you're hacking away on something else. And now I've got the word hacking stuck in my mind. [laughs]

+ +

CHRIS: It's the best word to describe what we do. Yeah, there's definitely a version of someone should be reviewing...someone's actually doing the interview, so they're going to be very close to it. And then there maybe is a secondary someone's watching it closely and trying to glean, and categorize, and all of that. And I could potentially be any one of those, but I really like this version of this is just a background soundtrack that I'm exposing myself to so that I'm all the more immersed in the problem space that we are working on. And it's one of the things that I fundamentally believe about software development is developers shouldn't be hidden in the corner just writing code. We should always care about what the end-user wants, and what better way to get there than to actually hear their voice and hear the words that they're using. So this is a magical little trick that I have now found that I'm like, oh my God, this is amazing.

+ +

STEPH: Funny enough, I had a similar experience this past week where I realized I was feeling very disconnected from the people that are using the application and also the people that are setting priorities for the work that our team is doing. And that is something that I'm very accustomed to with thoughtbot that we always want to be part of the team. We're not necessarily just we can churn through a backlog. But we also really want to be in touch with product decisions, and share opinions, and then also be in touch with users too. So I had some similar revelations this week where I realized I was feeling very disconnected where I was picking up tickets, and I was like, I don't really understand why this is great or how this is helpful. And so, I shared that with the team, and someone encouraged me to attend a specific meeting. And that was wonderful because then I got to hear from the people who were creating those tickets and then giving them a high priority because something was urgent and why it was urgent. And having that insight was huge to me. And I realized that it was incredibly motivational as well. Because then I'm like, yes, okay, I understand how this is going to impact someone. And I'm now very encouraged to get this done.

+ +

CHRIS: I think that idea, that ethos of wanting to get into the user persona and understand that better is a very strong thoughtbot ideal. So it’s unsurprising both of us share that. But yeah, that was a really great thing and particularly a tool that facilitated that in a really straightforward way, which I appreciated. Another thing that I used this week, which I've talked about at length in a previous episode, so we can link to that episode, but it's a project called dry-monad. So there's dry-rb is the collection of, I think, a set of gems, but dry-monad is one that allows for defining sequential tasks, so tasks that you have to do a bunch of steps in order and the outcome of a previous step will be the input of the next part of the process. So it can fail in a bunch of ways like, okay, fetch this thing from the network and then look up a user based on that. And then get the user's profile, which may or may not exist, and then assuming that all of that's gone well, actually persist to this new record, to the database. And they're really finicky to write that sort of sequential processing. And so I actually had written that thing manually. And part of it was I'd wrapped the whole thing in a database transaction, but I was trying to make it so that if something went wrong, I would manually roll back the transaction. And then I wanted to return an object to the caller that indicated that things had failed and an error message or something like that. And that was actually really hard to do because of the way transactions work.

+ +

The mechanism that I was using was apparently deprecated in Rails. And so the whole thing was just kind of confusing, and it was a bit messy in the code. And I knew in the back of my mind that dry-monad exists. I've used it before. I've really enjoyed it. But I was trying to minimize the amount of new technologies that I'm bringing in this early on in the project. It's like, yeah, I'll bring that in when I need it. But finally, I was like, you know what? I think I've reached that point. I grabbed it, brought it in, and I haven't worked with it in a while, but I was very quickly able to refactor my class to use dry-monad. It cleaned it up immensely. The tests remained identical, which was really interesting. I didn't have to change anything on the test side. And one of my tests was failing before and then passed because of the introduction of dry-monad. And yeah, it was just like a win-win-win, and also the fact that I was able to revisit dry-monad as a library and just get running with it again was really interesting to me because it is a bit complicated and interesting in how it works. But again, I was able to just sort of pick it up and run with it. So that was wonderful. And I will now all the more staunchly suggest that folks reach for that when they have more complex, procedural type code that they need to write.

+ +

STEPH: I remember you highlighting dry-monad before in previous episodes and talking about the pain of writing that sort of procedural code, but then we also want to return something helpful. And I looked at it briefly, but I haven't used it. But now that you are reminding me of it, I'm very interested in it because I agree that process is difficult to write, at least in Ruby it's difficult to write. I understand the hesitancy that you have around bringing something in that's new. But then if you recognize that it's going to be a theme in your application around this is something that we're going to do a fair amount, and we want to do it in a clean, efficient way, then it starts to feel more reasonable to say, “Okay, I'm bringing in something new, but it is representative of how we want to handle this step or this type of process in our application.” So it's not just bringing in a gem to handle one small area of the code, something that we could have written, but it is elevating our process and our system.

+ +

CHRIS: Yup. Indeed. In this case, these are command objects within the system. That's actually the name that I got from the creator of the project. That was his suggestion on Twitter as to what to call these objects. And it's a pattern that I do want to encode and has become the standard within the application for any of these more complex processing tasks. So, again, we'll link to the previous episode. I talked about it in more depth and the ideas behind it. Railway Oriented Programming is a phrase that's used, which talks about how to sequence failures or successes and whatnot together. And there's some good material behind it, more general, but yeah, wonderful, little library.

+ +

STEPH: What is Railway Oriented Programming? I'm not familiar with that term.

+ +

CHRIS: That refers to the sequential processing that I was describing. So imagine that you have a bunch of different steps where first you fetch from the network to get this record, then using what you got back, you look up a user in your database, then you fetch that user's profile. Then you do something else. Each of those steps along the way could fail. And so the railway metaphor is the track is going forward, but if at any point you branch off the track because of a failure, then you're in the failure track, and that's a different thing. And so it's a very...the dry-monad or other similar Railway Oriented Programming or monads generally I think is the actual...it's the words in there. And I wish it wasn't in there because it's such a complicated word. But that idea is the fundamental, underlying thing that's going on there. And it is conceptually somewhat complicated, but if you don't try and think about the category theory behind it, and you're just like, well, I want to do a bunch of stuff, and it may fail at any point, and I want to return either a success message with everything having gone well or an error message at the point that it failed and stopped processing, then that's what this thing does, and it's fantastic at it.

+ +

STEPH: Okay, cool. Thank you.

+ +

CHRIS: You are welcome. And I think there's a bit more in the previous episode as well. So if that sounded interesting to anyone, I think I rambled more in a previous episode about it and probably better because I feel like I was more prepared that time than this time.

+ +

STEPH: Well, along those lines of running a process and then being able to fail at any moment, I'm going to circle back to that other topic that I highlighted where most of my week has been focused on writing a task that is processing a CSV, something probably a number of us have done at some point in our career but processing a number of rows, and then sending and queuing jobs to then send data to a third party system. And it was really interesting less so because of the processing of the CSV and then enqueuing jobs. But it was more of the reporting that went behind it and the process that went into writing this task. So Joël and I were pairing on this task. Joël being another thoughtboter and also a former guest on this show. And we had an interesting process of where we started with one, let's do the simplest thing. Let's get it done. Let's also check through the CSV because you're often going to find stuff that doesn't align with what you expect it to when it's a CSV that's provided from an external source. One of the risks that we highlighted right away was how are we going to get the CSV on the server? Because we just have this one CSV that we need to run. We don't want to add it to the repo, and we can't generate it ourselves. So how are we actually going to get the CSV in a place that we can run this in a production mode? I learned that I could pass a CSV as standard input into the Rake task. So then I could actually run it locally because we're using AWS. So I could inform AWS to run this task, but then I could actually stream the CSV into the task that way. And that was really nice because then we no longer had the question of how are we going to get this file on the server?

+ +

CHRIS: That's interesting. I didn't know...Yeah, the streaming of it from local to remote is an interesting one. On Heroku, I will typically open up a bash prompt, so Heroku run bash. And then, I will curl the file down onto the server and then run it locally. But that’s an ephemeral dyno. It may die at any point. There are various things that could go wrong there. So that's always interesting. I imagine a similar thing could be done, but I don't know, actually, if you can directly stream into a Heroku dyno like that, which is an even more straightforward one because I end up having to bounce a file off of a random. Like, I'll often put it in a Gist or a Pastebin or something like that. And then I'll curl it down to the server, and yeah, this is interesting.

+ +

STEPH: Yeah, I'm also not sure the specifics of how it would work with Heroku. But it was a really nice process for us to be able to use versus having to then read the file from, like you mentioned, curl it from somewhere else and then be able to parse it that way. Two other things that were top of mind for working on this task is one, idempotency. You're going to rerun it, friends. At some point, your task is either going to bomb, and it's going to err. And then you're going to have to triage and run it again. Or whoever requested that you run this task and they said, “Oh, it's just temporary. We're just going to run the once,” that's not true. You're going to run it again. So keep in mind how to make that safe, that you can rerun it. And then that won't be its own scenario that then you have to triage and figure out.

+ +

CHRIS: Idempotency is one of those critical ideas, and I just wish the word were different. I feel ridiculous every time I say it. And I feel like I have to push my glasses up on my nose, and I'm like, well, have we considered idempotency for this? But it's such a good idea. And it's the sort of thing that...you're totally right. Every time you're doing this sort of thing, it is something that you should consider. And we use GET requests, and they have rules about it. And it's such a good idea and such an important idea. And I just wish the word were different so that I felt more comfortable using it in polite conversation.

+ +

STEPH: [laughs] I don't know why… and this may be sharing too much of myself. But the song Under Pressure by Queen and David Bowie the Under Pressure song has been in my head. But I've been replacing the under pressure part with idempotent. So it's [singing] under pressure, and I've been [singing] idempotent. [laughter] And that has just been my song for the week.

+ +

CHRIS: You've normalized it enough for me now that I'll just hear you singing it every time, and I'll be like, this is a nonsense word. We're fine. We can just go – [laughs]

+ +

STEPH: That's what I'm here for, to turn technical terms into nonsense. [laughs]

+ +

CHRIS: It's really what this show is about at the end of the day. So you are our hero.

+ +

STEPH: I just have to work on more lyrics for the song. I really just have that one line, that one hook. [laughs]

+ +

CHRIS: Now I just want to scrap the rest of the episode and just come up with lyrics to idempotent. [chuckles] But maybe we don't do that.

+ +

STEPH: [laughs]

+ +

CHRIS: Maybe that'll be after the credits B-roll, something like that.

+ +

STEPH: The other way I do phrase that question is I'm like, what happens when it fails? And that always feels like a safe way. Because if I ask someone like, “Hey, is the idempotent?” It feels more natural for people to be like, “Oh, it's fine. It doesn't need to be.” But if you say, “What happens when it fails?” It's harder for someone to say, “Oh, it's never going to fail. [laughs] There is nothing that could go wrong.” So it feels like a more intentional question in regards to how are we going to handle this when we need to rerun it? The other part that really came in handy was the fact that we spent more time on the reporting as well. So we really wanted to know what happened when we are processing all of these rows. So were there any invalid rows? And if we do encounter an invalid row, do we want to just stop processing and stop right there, or do we want to keep moving? Do we have any rows that didn't match, a row in our database, and how do we capture those? And because it's idempotent, maybe we want to capture skipped rows so then that way when we rerun it, we can see okay, well, we skipped, you know, a thousand rows because we'd already run them before. And all of that reporting has been so handy because we're also using this to triage. Like, hey, we're sending a bunch of messages to this third-party system. We reach out to that third-party group, and we say, “Hey, we sent you all of this. This is how it went. Let us know how it went on your end.” And then, we can have a more collaborative discussion around what happened on their end versus what happened on our end, and then we can make tweaks to each system.

+ +

So overall, it felt more of that run-of-the-mill task where you're going to write a Rake task, you're going to parse a CSV. But something about the reporting really resonated with me because in the past, when I've written Rake tasks, I've leaned more on the this is temporary, so it's okay if it's not great. But the reporting has been so crucial that from now on, I always want reporting from any Rake tasks that I run, and I want to know what happened. And then I also want to be able to rerun it. And I'm very wary of any time that someone says, “Oh, this is temporary,” because then I also think that leads to interesting discussions around testing. Because initially, when we started this, we were under some pressure. Hey, that goes back to my song. We were under some pressure for writing this particular task. And then the question came up: do we want to test it? And to be frank, testing a Rake task isn't great; it’s not fun, which is one of the reasons we get out of a Rake task as quickly as possible and put it into a class. So that was also one of the drivers or one of the conversations that went against, like, oh, this is temporary. So it's okay if it's not the best code. It's okay if it's not tested. And then I was more of an advocate for, like, well, I don't feel good about this. And I'm rerunning the Rake task every time I want to confirm that the changes that I've made are correct. And so once I hit that manual labor point where I'm like, okay, I'm testing this. I just don't have automated tests for this, that then I actually started adding test coverage around it.

+ +

CHRIS: I'm so excited that we have transcripts, particularly for that last minute that you were just talking about, because I feel like that was a mini master class in software development. And more generally, there's been almost like a poetic something to the two different topics that you’ve brought up today are the sort of mundane, very real things that actual software development is made almost entirely of. It's not often that we're just starting with a greenfield app and building a new thing. I happen to be doing that this week, but it's rare. It's going to be over very soon. And then I'm going to be in the world of oh; we have to backfill a bunch of data. How are we going to do that? Or we have this portion of the code that, frankly, we should have been testing more, but we didn't. How do we deal with that? And these murky, gray areas where there isn't a clear answer and you have to go with intuition, and you have to...a bunch of the things that you just listed as these good heuristics that you have around how you think about software. I'm just really excited for the transcript to that because that was awesome.

+ +

STEPH: I'm so glad you enjoyed it because I think it's not until right now where I'm processing this and talking about it with you that it is...I was trying to think earlier, like, why is this so interesting? Why am I so excited to bring this here to this conversation? And I think it is for the reasons exactly that you said, that it does feel like one of these...this is a mundane task. We write a task; we process some things; we send some data. We do that all the time. But then it's all the other bits around it, and the other ways that we've been bitten, and how we avoid those scenarios, and then how we identify a risk like when someone says, “Oh, it's temporary. It's fine.” That part, I think, is always the very interesting aspect of writing software.

+ +

CHRIS: Do you consider this sort of stuff the distraction from the work or actually the work? And in my experience, this makes up a lot of the work. And treating it like what you were saying about testing like, “Yeah, that thing where you're telling me that it's going to be temporary and we probably don't need to test it, I've been told that before,” and I just want to spot-check that real quick. Or what you said of the when I was manually testing, and I crossed a threshold where I'd done that enough, that now adding a test harness around that totally makes sense. It's worth the investment at that point. Those little heuristics that we build up over time are the things that are hard to get. And so, yeah, I love that conversation.

+ +

STEPH: I really like how you also asked and then responded to that question around is this distraction, or is this the work? And I am wholeheartedly with you that this is the work. This is the part of the work that I do find interesting, and knowing when to make those trade-offs, and when you've hit a decision point, and which direction you're going to go, and being able to recognize something that otherwise could have been a fire. It could have been much worse in terms of if we'd built a task that wasn't robust. Because of course, then the second time that I ran it, you know, emphasis on the second time that I ran it because we needed to do it again to process more data. It erred halfway through, and I panicked in the moment. But then I was like, oh yeah, this is fine. We planned for this. This was in the game plan. So it goes back to that we want the calm execution. We want to plan so we are back in that calm state. We want calm software. And this feels very in line with how do we make this more calm?

+ +

CHRIS: I love that theme that you're bringing up there, which I think is a theme that we've touched on a bunch of times. I think we actually have an episode called Seeking Calm. And I think that little title there, as much as I love the nonsense titles that we have for most of the episodes, that one I think really captures the theme that a lot of what we talk about is in orbit around yeah, we want it to be calm. We don't want things to be on fire every day. And what does it look like to build software with that in mind?

+ +

STEPH: Yeah. I also love that theme. And I like that it's something that we have surfaced and then really stuck to because it resonates deeply with me. But that's pretty much all I have for my Rake task adventure. What else is new in your world?

+ +

CHRIS: Well, I have one more hopefully quick thing. I'm going to try and boil this down to its essence, but I ran into, let's call it, a subtlety. It's not an issue. It wasn't a bug per se. But looping back to the previous episode that you and I recorded together, we talked a bunch about multi-step forms, which was a great conversation in and of itself. But I eventually completed the feature that I was working on, put it up for acceptance. And the product manager who was reviewing it highlighted a couple of different things. They recorded a video which, as an aside, I love that as a way to do acceptance and show what's going on and talk through it. There were a couple of smaller issues, which I was able to resolve very quickly, but there was one more interesting one that I've extracted this as future work because it was too complex to try and solve in the moment. But basically, what's happening is imagine that we have a two-step form. So there's the first page of the form. The first form that you see is for your name. So it's just an input that says, “Name,” and you fill in your name and then you hit continue. That posts to the server. We save off that data. And then, we redirect you to the next page on the form, which is, say, phone number. So two steps. We start with name; we go to phone number. What happens if you type in your name, you hit continue, everything processes correctly. You end up on the phone number page, but you hit back. What do you think happens?

+ +

STEPH: I would expect to go back to the name field and probably expect my name to be populated but would also be fine if it's not.

+ +

CHRIS: I like that you would be fine with the fact that it's not, if it's not, because it's not is the answer. And what's unfortunate is so if someone goes back, they will see the unpopulated form, so not filled out. But if they reload at that point, we will serialize down the value and pre-fill the input with their saved data. And so that inconsistency is not great. It's all the more unfortunate because as I tried to resolve it, I'm like, oh, okay, this feels like a solvable thing. I just need to tell Chrome, “Hey, if someone hits the back button, do a better thing than what you're doing.” I needed a way to instruct Chrome or whichever browser because this should be a standards-level thing. And there are things in the HTTP spec about this. So there's the Cache-Control Header is one of the headers that you can send down with a response. And there's a bunch of different values that can be in there, no-cache, no-store. There's also the…I want to say it's the max-age, or I think it's Expires. That's a different header. But you can set it to have an expiry that's just already expired. There's also a Pragma, which you can say no-cache. Some of these are standard. Some of these are not standard. Chrome ignores all of them. Chrome’s just like, “Nevermind.” So the idea is that those headers are intended to inform intermediate proxies.

+ +

Say you have a caching layer, so you're using Fastly or CloudFront or something like that. When that service fetches the page from your backend, from your actual, say, Rails app, then it will look at that header and say, “Should I hold onto this for a little while or not? Is it public, or is it private? What should I do as an intermediate caching proxy?” Ideally, Chrome would also look at those and say, like…there should be a version of me being able to tell Chrome, “Listen, if someone hits the back button, please go to the server and ask for it.” Like, I'll take the second of latency that that introduces in navigating back because I always want to show them the correct data. Unfortunately, I have not found a way to do that. There's a bunch of things on Stack Overflow and other places of JavaScript solutions where I can listen to the window.popstate event and then force location.reload. But that feels like a pile of hacks that I don't want to get into. It feels like it will be very inconsistent between browsers. So I am still searching for a solution. But I would like to figure something out here.

+ +

As a more pointed version of this to try and explain an example where this could happen, imagine that you've got the header of your application, and in it, you have a sign-out button. And so that sign out is going to delete to the session's endpoint. So you're deleting your session. And after that, you get redirected to the login form. If you then hit back, you will be taken back to the browser’s cached version of the previous logged-in state page that you were at. This is probably fine in a lot of cases. If you reload, you can't do any nefarious action at that point because you are logged out. But you are seeing potentially sensitive information. So imagine that you log in in a cafe, you go through Gmail, or whatever, or your bank, then you log out, you walk away. If you leave that page up and someone hits back, they can now see what was on the page. And part of that particular version, I read a bunch of backstory about that on the Inertia repo because someone posted this as an issue against Inertia as a framework. And the Inertia team...and I really love how they handle these sorts of things. So they were very kind, very welcoming to the issue but also said, “Actually, we're doing...like, this isn't us. But let's talk about it,” and gave a ton of detail and went through the HTTP spec. And it's a fantastic issue as a read. It's like a fun bedtime reading sort of thing to learn about how the internet works. But the Inertia crew really, really cares about being spec-compliant and doing the right thing. So, unfortunately, this is outside of their purview as well. But yeah, I don't have a solution, and it makes me sad.

+ +

STEPH: I liked that second example that you provided because I feel like I see that one more commonly when I'm on an application, and I don't know why. But I hit back, and then it shows that I'm signed in, and I'm like, that's a lie, I'm not signed in. I also really appreciate how Inertia is responding so kindly and welcoming to folks and then providing such thoughtful responses. That sounds immensely helpful. I don't know, yeah, I am also interested in this. It's something that I haven't worked with in a while, so I don't have any grand ideas at the moment. So I'm also curious if other people have run into this and how they've approached it.

+ +

CHRIS: Yeah. If we're being honest, partly I wanted to share this with you, but also I wanted to say this into a microphone, and then hopefully someone out there on the internet knows an answer. I've tried, I think, all of the normal things, all of the different variations of headers. I haven't actually poked at the JavaScript things yet, but that's probably the direction I'm going. But if anyone out there has an idea, I would absolutely love it. I think in my mind, the ideal version of this is if I'm making GET requests and I'm clicking around on a page, it's perfectly fine for Chrome to use its cache version of the previous page because, sure, that's fine. It may actually be stale just based on it's been a few seconds, and something's changed on the server, but I'm willing to accept that. But if I've posted, or patched, or deleted, or done any action that by definition should be changing data on the server, then I would love for a way to invalidate Chrome's back cache, so its version of the pages that it's restoring when I'm hitting back. I'd love that as the heuristic to get to. I don't know if I can get there. My sense says chrome’s like, “No, I want to go fast. That's all I care about.” [chuckles] I’m like, all right. Well, I get that vibe but --

+ +

STEPH: Yeah, that’s a nice, succinct way to say that if I've changed data, then I want to invalidate that browser cache, so then we don't show them a fresh page and we actually show them the name that they entered on the form.

+ +

CHRIS: As we know, though, cache invalidation is one of the very easy things to do in software development. So I'm sure my naive, quick idea is very easy to implement and will have no edge cases of its own.

+ +

STEPH: Well, this will be our parallel Pixar movie. We have one that we highlighted earlier, and this will be the other one, The Cache Buster. I'm not great with titles. [laughs] This will be our other Pixar movie.

+ +

CHRIS: Buster the Lonely Cache. Yep.

+ +

STEPH: All right. Well, in parallel, we'll work on Buster the Lonely Cache. Is that the name of this?

+ +

CHRIS: Yep.

+ +

STEPH: Cool. We'll work on that script. And in the meantime, I'll also think about it if I encounter this or come up with some ideas and share them with you. And then also if other people have any ideas, that'd be fantastic.

+ +

CHRIS: That would be fantastic.

+ +

STEPH: Yes. Please write in to help Buster with the lonely cache, which, wait; I don't get it. Why is it the lonely cache?

+ +

CHRIS: Because the cache has been busted and evicted. So he's got no friends. There's nothing...There's no data left. I don't know.

+ +

STEPH: [laughs]

+ +

CHRIS: I came up with it real quick. I don't stand by it. It's not a great idea, but we'll workshop it. It'll be fine.

+ +

STEPH: That's true. Yeah, we'll go through it. I'm asking too many questions for a very quick creative. We're in the creative space, not the critical space. But please write in to help Buster figure out [laughs] the lonely cache or how to bust the cache. Oh, goodness. I'm done with my jokes for today. I'll try to stop.

+ +

CHRIS: I believe that's a perfect note. Shall we wrap up?

+ +

STEPH: Let's wrap up. Show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+INgqY8YX + + ]]> + + Chris Toomey + Steph Viccari + + + 296: Speedy Performance with Nate Berkopec + https://bikeshed.thoughtbot.com/296 + 61f180b8-432b-4aa7-9290-2da6329d4ac5 + Tue, 15 Jun 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Nate Berkopec is the author of the Complete Guide to Rails Performance, the creator of the Rails Performance Workshop, and the maintainer of Puma. He talks with Steph about being known as "The Rails Speed Guy," and how he ended up with that title, publishing content, working on workshops, and also contributing to open source projects. (You could say he's kind of a busy guy!) + 1:03:33 + no + + + Nate Berkopec is the author of the Complete Guide to Rails Performance, the creator of the Rails Performance Workshop, and the co-maintainer of Puma. He talks with Steph about being known as "The Rails Speed Guy," and how he ended up with that title, publishing content, working on workshops, and also contributing to open source projects. (You could say he's kind of a busy guy!) +Speedshop (https://www.speedshop.co/) +Puma (https://github.com/puma/puma/commits/master?author=nateberkopec) +The Rails Performance Workshop (https://www.speedshop.co/rails-performance-workshop.html) +The Complete Guide to Rails Performance (https://www.railsspeed.com/) +How To Use Turbolinks to Make Fast Rails Apps (https://www.speedshop.co/2015/05/27/100-ms-to-glass-with-rails-and-turbolinks.html) +Sidekiq (https://sidekiq.org/) +Follow Nate Berkopec on Twitter (https://twitter.com/nateberkopec) +Visit Nate's Website (https://www.nateberkopec.com/) +Sign up for Nate's Speedshop Ruby Performance Newsletter (https://speedshop.us11.list-manage.com/subscribe?u=1aa0f43522f6d9ef96d1c5d6f&id=840412962b) +Transcript: +STEPH: All right. I'll kick us off with our fancy intro. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I’m Steph Viccari. And this week, Chris is taking a break. But while he's away, I'm joined by Nate Berkopec, who is the owner of Speedshop, a Ruby on Rails performance consultancy. And, Nate, in addition to running a consultancy, you're the co-maintainer of Puma. You're also an author as you wrote a book called The Complete Guide to Rails Performance. And you run the workshop called The Rails Performance Workshop. So, Nate, I'm sensing a theme here. +NATE: Yeah, make code go fast. +STEPH: And you've been doing that for quite a while, haven't you? +NATE: Yeah. It's pretty much been since 2015, or so I think. It all started when I actually wrote a blog post about Turbolinks that got a lot of pick up. My hot take at the time was that Turbolinks is actually a good thing. That take has since become uncontroversial, but it was quite controversial in 2015. So I got a lot of pick up on that, and I realized I liked working on performance, and people seem to want to hear about it. So I've been in that groove ever since. +STEPH: When you started down the path of really focusing on performance, were you running your own consultancy at that point, or were you working for someone else? +NATE: I would say it didn't really kick off until I actually published The Complete Guide to Rails Performance. So after that came out, which was, I think, March of 2016…I hope I’m getting that right. It wasn't until after that point when it was like, oh, I'm the Rails performance guy now. And I started getting emails inbound about that. I didn't really have any time when I was actually working on the CGRP to do that sort of thing. I just made that my full-time job to actually write, and market, and publish that. So it wasn't until after that that I was like, oh, I'm a performance consultant now. This is the lane I've driven myself into. I don't think I really had that as a strategy when I was writing the book. I wasn't like, okay, this is what I'm going to do. I'm going to build some reputation around this, and then that'll help me be a better consultant with this. But that's what ended up happening. +STEPH: I see. So it sounds like it really started more as a passion and something that you wanted to share. And it has manifested to this point where you are the speed guy. +NATE: Yeah, I think you could say that. I think when I started writing about it, I just knew...I liked it. I liked the work of performance. In a lot of ways, performance is a much more concrete discipline than a lot of other sub-disciplines of programming where I joke my job is number go down. It's very measurable, and it's very clear when you've made a difference. You can say, “Hey, this number was this, and now it's this. Look what I did.” And I always loved that concreteness of performance work. It makes it actually a lot more like a real kind of engineering discipline where I think of performance engineering as clarifying requirements and the limitations and then building a project that meets the requirements while staying within those limitations and constraints. And that's often not quite as clear for other disciplines like general feature work. It's kind of hard to say sometimes, like, did you actually make the user's life better by implementing such and such? That's more of a guess. That's more of a less clear relationship. And with performance, nobody's going to wake up ten years from today and wish that their app was slower. So we can argue about the relative importance of performance in an application, but we don't really argue about whether or not we made it faster because we can prove that. +STEPH: Yeah. That's one area that working with different teams (as I tend to shift the clients that I'm working with every six months) where we often push hard around feature work to say, “How can we measure this? How can we know that we are delivering something valuable to users?” But as you said, that's really tricky. It's hard to evaluate. And then also, when you add on the fact that if I am leaving that project in six months, then I don't have the same insights to understand how something went for that team. So I can certainly appreciate the satisfaction that comes from knowing that, yes, you are delivering a faster app. And it's very measurable, given the time that you're there, whether it's a short time or if it's a long time that you're with that team. +NATE: Yeah, totally. My consulting engagements are often really short. I don't really do a lot of super long-term stuff, and that's usually fine because I can point to stuff and say, “Yep. This thing was at A, and now it's at B. And that's what you hired me to do, so now it's done.” +STEPH: I am curious; given that you have so many different facets where you are running your consultancy, you are also often publishing a lot of content and working on workshops and then also contributing to open source projects. What does a typical week look like for you? +NATE: Well, right now is actually a decent example. I have client work two or three days a week. And I'm actually working on a new product right now that I'm calling Sidekiq in Practice, which is a course/workshop about scaling Sidekiq from zero to 1000 jobs per second. And I'll spend the other days of the week working on that. My content is...I always struggle with how much time to spend on blogging specifically because it takes so much time for me to come up with a post and publish that. But the newsletter that I write, which I try to write two once a week, I haven't been doing so well with it lately. But I think I got 50 newsletters done in 2020 or something like that. +STEPH: Wow. +NATE: And so I do okay on the per-week basis. And it's all content I've never published anywhere else. So that actually is like 45 minutes of me sitting down on a Monday and being like rant, [chuckles] slam keyboard and rant and then hit send. And my open source work is mostly 15 minutes a day while I'm drinking morning coffee kind of stuff. So I try to spread myself around and do a lot of different stuff. And a lot of that means, I think, pulling back in terms of thinking how much you need to spend on something, especially with newsletters, email newsletters, it was very easy to overthink that and spend a lot of time revising and whatever. But some newsletter is better than no newsletter. And especially when it comes to content and marketing, I've learned that frequency and regularity is more important than each and every post is the greatest thing that's ever come out since sliced bread. So trying to build a discipline and a practice around doing that regularly is more important for me. +STEPH: I like that, some newsletter is better than no newsletter. I was listening to your chat with Brittany Martin on the Ruby on Rails podcast. And you said something very honest that I appreciated where you said, “Writing is really hard, and writing sucks.” And that made me laugh in the moment because even though I do enjoy writing, I still find it very hard to be disciplined, to sit down and make it happen. And then you go into that editor mode where you critique everything, and then you never really get it published because you are constantly fixing it. It sounds like...you've mentioned you set aside about 45 minutes on a Monday, and you crank out some work. How do you work through that inner critic? How do you get past it to the point where then you just publish? +NATE: You have to separate the steps. You have to not do editing and first drafting at the same time. And the reason why I say it sucks and it's hard is because I think a lot of people don't do a lot of regular writing, maybe get intimidated when they try to start. And they're like, “Wow, this is really hard. This is not fun.” And I'm just trying to say that's everybody's experience and if it doesn't get any better, because it doesn't, [chuckles] there's nothing wrong with you, that's just writing, it's hard. For me, especially with the newsletter, I just have to give myself permission not to edit and to just hit send when I'm done. I try to do some spell checking,, and that's it. I just let it go. I'm not going back and reading it through again and making sure that I was very clear and cogent in all my points and that there's a really good flow through that newsletter. I think it comes with a little bit of confidence in your own ideas and your own experience and knowledge, believing that that's worth sharing and that's worth somebody's time, even if it's not a perfect expression of what's in your head. Like, a 75% expression is good enough, especially in a newsletter format where it's like 500 to 700 words. And it's something that comes once a week. And maybe not everyone's amazing, but some of them are, enough of them are that people stay subscribed. So I think a combination of separating editing and first drafting and just having enough confidence and the basis where you have to say, “It doesn't have to be perfect every single time.” +STEPH: Yeah, I think that's something that I learned a while back to apply to my coding process where I had to separate those two steps of where I have to let the creator in me just create and write some code and make it work, and then come back to the editing process, and taking a similar approach with writing. As you may be familiar with thoughtbot, we're big advocates when it comes to sharing content and sharing things that we have learned throughout the week and different projects that we're working on. And often when people join thoughtbot, they're very excited to contribute to the blog. But it is daunting for that first post because you think it has to be this really grand novel. And it has to be something that is really going to appeal to everybody, and it's going to help everyone. And then over time, you learn it's like, oh well, actually it can be this very just small thing that I learned that maybe only helps 20 people, but it still helped those 20 people. And learning to publish more frequently versus going for those grand pieces is more favorable and often more helpful for people. +NATE: Yeah, totally. That's something that is difficult for people at first. But everything in my experience has led me to believe that frequency and regularity is just as, if not more important than the quality of any individual piece of content that I put out. So that's not to say that...I guess it's weird advice to give because people will take it too far the other way and think that means he's saying quality doesn't matter. No, of course, it does, but I think just everyone's internal biases are just way too tuned towards this thing must be perfect. I've also learned we're just really bad judges internally of what is useful and good for people. Stuff that I think is amazing and really interesting sometimes I'll put that out, and nobody cares. [chuckles] And the other stuff I put out that's just like the 45-minute banging out newsletter, people email me back and say, “This is the most helpful thing anyone’s ever read.” So that quality bias also assumes that you know what is good and actually we're not really good at that, knowing every time what our audience needs is actually really difficult. +STEPH: That's totally fair. And I have definitely run into that too, where I have something that I'm very proud of and excited to share, and I realize it relates to a very small group of people. But then there's something small that I do every day, and then I just happen to tweet about it or talk about it, and suddenly that's the thing that everybody's really excited about. So yeah, you never know. So share it all. +NATE: Yeah. And it's important to listen. I pay attention to what people get interested in from what I put out, and I will do more of that in the future. +STEPH: You mentioned earlier that you are working on another workshop focused on Sidekiq. What can you tell me about that? +NATE: So it's meant to be a guide to scaling Sidekiq from zero to 1000 requests per second. And it's meant to be a missing guide to all the things that happen, like the situations that can crop up operationally when you're working on an application that does a lot of work with Sidekiq. Whereas Mike Sidekiq, Wiki, or the docs are great about how do, you do this? What does this setting mean? And the basics of getting it just running, Sidekiq in practice, is meant to be the last half of that. How do you get it to run 1,000 jobs per second in a day-to-day application? So it's the collected wisdom and collected battle scars from five years of getting called in to fix people's Sidekiq installations and very much a product of what are the actual problems that people experience, and how do you fix and deal with those? So stuff about memory and managing Sidekiq memory usage, how to think about queues. Like, what should your queue structure be? How many should you have? Like, how do you organize jobs into queues, and how do you deal with problems like some client is dropping 10,000, 20,000 jobs into a queue. And now the other jobs I put in that queue have 20,000 jobs in front of them. And now this other job I've got will take three hours to get through that queue. How do you deal with problems like that? All the stuff that people have come to me over the years and that I've had to help them fix. +STEPH: That sounds really great. Because yeah, I find that teams who are often in this space with Sidekiq we just let it run until there's a fire. And then suddenly, we start to care as to how it's processing, and we care about our queue structure and how many workers that we have that are pulling from that queue. So that sounds really helpful. When you're building a workshop, do you often go back to any of those customers and pull more ideas from them, or do you find that you just have enough examples from your collective work with clients that that itself creates a course? +NATE: Usually, pretty much every chapter in the workshop I've probably implemented like three-plus times, so I don't really have to go back to any individual customer. I have had some interesting stuff with my current client, Gusto. And Gusto is going through some background job reorganization right now and actually started to implement a lot of the things that I'm advocating in the workshop actually without talking to me. It was a good validation of hey, we all actually think the same here. And a lot of the solutions that they were implementing were things that I was ready to put down into those workshops. So I'd like to see those solutions implemented and succeed. So I think a lot of the stuff in here has been pretty battle-tested. +STEPH: For the Rails Performance Workshop, you started off doing those live and in-person with teams, and then you have since switched to now it is a CLI course, correct? +NATE: That's correct. Yep. +STEPH: I love that very much. When you’ve talked about it, it does feel very appropriate in terms of developers and how we like to consume content and learn. So that is really novel and also, it seems like a really nice win for you. So then other people can take this course, but you are no longer the individual that has to deliver it to their team, that they can independently take the course and go through it on their own. Are you thinking about doing the same thing for the Sidekiq course, or what are your plans for that one? +NATE: Yeah, it's the exact same structure. So it's going to be delivered via the command line. Although I would say Sidekiq in practice has more text components. So it's going to be a combination of a very short manual or book, and some video, and some hands-on exercises. So, an equal blend between all three of those components. And it's a lot of stuff that I've learned over having to teach; I guess intermediate to advanced programming concepts for the last five years now that people learn at different paces. And one of the great things about this kind of format is you can pick it up, drop it off, and move at your own speed. Whereas a lot of times when I would do this in person, I think I would lose people halfway through because they would get stuck on something that I couldn't go back to because we only had four hours of the day. And if you deliver it in a class format, you're one person, and I've got 24 other people in this room. So it's infinitely pausable and replayable, and you can go back, or you can just skip ahead. If you've got a particular problem and you're like, hey, I just want to figure out how to fix such and such; you can do that. You can just come in and do a particular thing and then leave, and that's fine. So it's a good format that way. And I've definitely learned a lot from switching to pre-recorded and pre-prepared stuff rather than trying to do this all live in person. +STEPH: That is one of the lessons that I've learned as well from the couple of workshops that I've led is that doing them in person, there's a lot of energy. And I really enjoy that part where I get to see people respond to the content. And then I get a lot of great feedback from people about what type of questions they have, where they are getting stuck. And that part is so important to me that I always love doing them live first. But then you get to the point, as you'd mentioned, where if you have a room full of 20 people and you have two people that are stuck, how do you help them but then still keep the class going forward? And then, if you are trying to tailor this content for a wide audience…so maybe beginners could take the Rails Performance Workshop, or they could also take the Sidekiq course. But you also want the more senior engineers to get something out of it as well. It's a very challenging task to make that content scale for everyone. +NATE: Yeah. What you said there about getting feedback and learning was definitely something that I got out of doing the Rails Performance Workshop in person like three dozen times, was the ability to look over people's shoulders and see where they got stuck. Because people won't email me and say, “Hey, this thing is really confusing.” Or “It doesn't work the way you said it does for me.” But when I'm in the same room with them, I can look over their shoulder and be like, “Hey, you're stuck here.” People will not ask questions. And you can get past that in an in-person environment. Or there are even certain questions people will ask in person, but they won't take the time to sit down and email me about. So I definitely don't regret doing it in person for so long because I think I learned a lot about how to teach the material and what was important and how people...what were the problems that people would encounter and stuff like that. So that was useful. And definitely, the Rails Performance Workshop would not be in the place that it is today if I hadn't done that. +STEPH: Yeah, helping people feel comfortable asking questions is incredibly hard and something I've gone so far in the past where I've created an anonymous way for people to submit questions. So during class, even if you didn't want to ask a question in front of everybody, you could submit a question to this forum, and I would get notified. I could bring it up, and we could answer it together. And even taking that strategy, I found that people wouldn't ask questions. And I guess it circles back to that inner critic that we have that's also preventing us from sharing knowledge that we have with the world because we're always judging what we're going to share and what we're going to ask in front of our peers who we respect. So I can certainly relate to being able to look over someone's shoulder and say, “Hey, I think you're stuck. We should talk. Let me walk you through this or help you out.” +NATE: There are also weird dynamics around in-person, not necessarily in a small group setting. But I think one thing I really picked up on and learned from RailsConf2021 which was done online, was that in-person question asking requires a certain amount of confidence and bravado that you're not...People are worried about looking stupid, and they won't ask things in a public or semi-public setting that they think might make them look dumb. And so then the people that do end up asking questions are sometimes overconfident. They don't even ask a question. They just want to show off how smart they are about a particular issue. This is more of an issue at conferences. But the quality of questions that I got in the Q&A after RailsConf this year (They did it as Discord chats.) was way better. The quality of questions and discussion after my RailsConf talk was miles better than I've ever had at a conference before. Like, not even close. So I think experimenting with different formats around interaction is really good and interesting. Because it's clear there's no perfect format for everybody and experimenting with these different settings and different methods of delivery has been very useful to me. +STEPH: Yeah, that makes a ton of sense. And I'm really glad then for those opportunities where we're discovering that certain forums will help us get more feedback and questions from people because then we can incorporate that and to future conferences where people can speak up and ask questions, and not necessarily be the one that's very confident and enjoys hearing their own voice. For the Rails Performance Workshop, what are some of the general things that you dive into for that workshop? I'm curious, what is it like to attend that workshop? Although I guess one can't attend it anymore. But what is it like to take that workshop? +NATE: Well, you still can attend it in some sense because I do corporate bookings for it. So if you want to buy 20 seats, then I can come in and basically do a Q&A every week while everybody takes the workshop. Anyway, I still do that. I have one coming up in July, actually. But my overall approach to performance is to always start with monitoring. So the course starts with goals and monitoring and understanding where you want to go and where you are when it comes to performance. So the first module of the Rails Performance Workshop is actually really a group exercise that's about what are our performance requirements and how can we set those? Both high-level and low-levels. So what is our goal for page load time? How are we going to measure that? How are we going to use that to back into lower-level metrics? What is our goal for back-end response times? What is our goal for JavaScript bundle sizes? That all flows from a higher-level metric of how fast you want the page to load or how fast you want a route to change in a React app or something, and it talks about those goals. And then where should you even start with where those numbers should be? And then how are you going to measure it? What are the browser events that matter here? What tools are available to help you to get that data? Because without measurement, you don't really have a performance practice. You just have people guessing at what stuff is faster and what is not. And I teach performance as a scientific process as science and engineering. And so, in the scientific method, we have hypotheses. We test those hypotheses, and then we learn based on those tests of our hypotheses. So that requires us to A, have a hypothesis, so like, I think that doing X makes this faster. And I talk about how you generate hypotheses using profiling, using tools that will show you where all the time goes when you do this particular operation of your software—and then measuring what happens when you do that? And that's benchmarking. So if you think that getting rid of method X or changing method X will speed up the app, benchmarking tells you did you actually speed it up or not? And there are all sorts of little finer points to making sure that that hypothesis and that experiment is tested in a valid way. +I spend a lot of time in the workshop yapping about the differences between development/local environments and production environments and which ones matter. Because what differences matter, it's not often the ones that we think about, but instead it's differences like actually in Rails apps the asset packaging and asset pipeline performs very differently in production than it does in development, works very differently. And it makes it one of the primary reasons development is slower than production, so making sure that we understand how to change those settings to more production-like settings. I talk a lot about data. It’s the other primary difference between development and production is production has a million users, and development has 10. So when you call things like User.all, that behavior is very different in production than it is locally. So having decent production-like data is another big one that I like to harp on in the workshops. So it's a process in the workshop of you just go lesson by lesson. And it's a lot of video followed up by hands-on exercises that half of them are pre-baked problems where I'm like, hey, take a look at this Turbolinks app that I've given you and look at it in DevTools. And here's what you should see. And then the other half is like, go work on your application. And here are some pull requests I think you should probably go try on your app. So it's a combination of hands-on and videos of the actual experience going through it. +STEPH: I love how you start with a smaller application that everyone can look at and then start to learn how performant is this particular application that I'm looking at? Versus trying to assess, let’s say, their own application where there may be a number of other variables that they have to consider. That sounds really nice. You'd mentioned one of the first exercises is talking about setting some of those goals and perhaps some of those benchmarks that you want to meet in terms of how fast should this page load, or how quickly should a response from the API be? Do you have a certain set of numbers for those benchmarks, or is it something that is different for each product? +NATE: Well, to some extent, Google has suddenly given us numbers to work with. So as of this month, I think, June 2021, Google has started to use what they're calling Core Web Vitals in their ranking of search results. They've always tried to say it's not a huge ranking factor, et cetera, et cetera, but it does exist. It is being used. And that data is based on Chrome user telemetry. So every time you go to a website in Chrome, it measures three metrics and sends those back to Google. And those three metrics are Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). And First Input Delay and Cumulative Layout shift are more important for your single-page apps kind of stuff. It's hard to screw those up with a Golden Path Rails app that just does Turbolinks or Hotwire or whatever. But Largest Contentful Paint is an easy one to screw up. So Google's line in the sand that they've drawn is 2.5 seconds for Largest Contentful Paint. So that's saying that from clicking on your website in a Google search result, it should take 2.5 seconds for the page to paint the largest component of that new page. That's often an image or a video or a large H1 tag or something like that. And that process then will help you to...to get to 2.5 seconds in Largest Contentful Paint; there are things that have to happen along the way. We have to download and execute all JavaScript. We have to download CSS. We have to send and receive back-end responses. In the case of a simple Hotwire app, it's one back-end response. But in the case of a single-page app, you got to download the document and then maybe download several XHR fetches or whatever. So there's a chain of events that has to happen there. And you have to walk that back now from 2.5 seconds in Largest Contentful Paint. So that's the line that I'm seeing getting drawn in the sand right now with Google's Core Web Vitals. So pretty much any meaningful web application performance metric can be walked back from that. +STEPH: Okay. That's super helpful. I wasn't aware of the Core Web Vitals and that particular stat that Google is using to then rank the sites. I was going to ask, this kind of blends in nicely into when do you start caring about performance? So if you have a new application that you are just starting to get to market, based on the fact that Google is going to start ranking you right away, you do have to care some right out of the gate. But I am curious, when do you start caring more about performance, and are there certain tools and benchmarking that you want to have in place from day one versus other things that you'll say, “Well, we can wait until we have X numbers of users or other conditions before we add more profiling?” +NATE: I'd say as an approach, I teach people not to have a performance strategy of monitoring. So if your strategy is to have dashboards and look at them regularly, you're going to lose. Eventually, you're not going to look at that dashboard, or more often, you just don't understand what you're looking at. You just install New Relic or Datadog or whatever, and you don't know how to turn a dashboard into actual action. Also, it seems to just wear teams out, and there's no clear mechanism when you just have a dashboard of turning that into oh, well, this has to now be something that somebody on our team has to go work on. Contrast that with bugs, so teams usually have very defined processes around bugs. So usually, what happens is you'll get an Exception Notification through Sentry or Bugsnag or whatever your preferred Exception Notification service is. That gets read by a developer. And then you turn that into a Jira ticket or a Kanban board or whatever. And then that is where work is done and prioritized. Contrast that with performance; there’s often no clear mechanism for turning metrics into stuff that people actually work on. So understanding at your organization how that's going to work and setting up a process that automatically will turn performance issues into actual work that people get done is important. +The way that I generally teach people to do this is to focus instead of dashboards and monitoring, on alerts, on automated thresholds that get tripped and then sends somebody's an email or put something in the Kanban board or whatever. It just has to be something that automatically gets fired. Different tools have different ways of doing this. Datadog has pretty much built their entire product around monitoring and what they call monitors. That's a perfectly fine way to do it, whatever your chosen performance monitoring tool, which I would say is a required thing. I don't think there's really any good excuse in 2021 for not having a performance monitoring tool. There are a million different ways to slice it. You can do it yourself with OpenTelemetry and then like statsD, I don't know, or pay someone else like everyone else does for Datadog or New Relic or AppSignal or whatever. But you got to have one installed. And then I would say you have to have some sort of automated alerting. Now that alerting means that you've also decided on thresholds. And that's the hard work that doesn't get done when your strategy is just monitoring. So it's very easy to just install a dashboard and say, “Hey, I have this average page time load dashboard. That means I'm paying attention to performance.” But if you don't have a clear answer to what number is good and what number is bad, then that dashboard cannot be turned into real action. So that's why I push monitoring so hard is because it allows people to ignore performance is all that matters, and it forces you to make the decision upfront as to what number matters. So that is what I would say, install some kind of performance monitoring. I don't really care what kind. +Nowadays, I also think there's probably no excuse to not have Real User Monitoring. So there's enough GDPR compliance Real User Monitoring now that I think everyone should be using it. So for industry terms, Real User Monitoring is just performance monitoring in the browser. So it's just users’ browser APIs and sends those back to you or your third-party provider, so having that so you actually are collecting back-end and front-end performance metrics. And then making decisions around what is bad and what is good. Probably everybody should just start with a page load time monitor, Largest Contentful Paint monitor. And if you've got a single-page app, probably hooking up some stuff around route changes or whatever your app...because you don't actually have page loads on every single time you navigate. You have to instrument whatever those interactions are. So having those up and then just drawing some lines that say, “Hey, we want our React route changes to always be one second or less.” So I will set an alert that if the 95th percentile is one second or more, I'm going to get alerted. There's a lot of different ways to do that, and everybody will have different needs there. But having a handful of automated monitors is probably a place to start. +STEPH: I like how you also focus on once you have decided those thresholds and have that monitoring in place, but then how do you make it actionable? Because I have certainly been part of teams where we get those alerts, but we don't necessarily...what you just mentioned, prioritize that work to get done until we have perhaps a user complaint about it. Or we start actually having pages that are timing out and not loading, and then they get bumped up in the priority queue. So I really like that idea that if we agree upon those thresholds and then we get alerted, we treat that alert as if it is a user that is letting us know that a page is too slow and that they are unable to use our application, so then we can prioritize that work. +NATE: And it's not all that dissimilar to bugs, really. And I think most teams have processes around correctness issues. And so, all that my strategy is really advocating for is to make performance fail loudly in the same way that most exceptions do. [chuckles] Once you get to that point, I think a lot of teams have processes around prioritization for bugs versus features and all that. And just getting performance into that conversation at least tends to make that solve itself. +STEPH: I'm curious, as you're joining teams and helping them with their performance issues, are there particular buckets or categories of performance issues that are the most common in terms of, let's say, 50% of issues are SQL-related N+1 issues? What tends to be the breakdown that you see? +NATE: So, when it comes to why something is slow in a Ruby application, I teach a method that I call DRM. And that doesn't have anything to do with actual DRM. It's just memorable because it reminds me of things I don't like. DRM stands for Database Ruby and Memory and in that order. So the most common issue is database, the second most common issue is issues with your Ruby code. The least common issue is memory. Specifically, I'm talking about allocation of objects, creating lots of objects. So probably 80% of your issues are in some way database-related. In Rails, it's 50% of those are probably N+1. And then 30% of database issues are probably what I would call unnecessary SQL. So it's not necessarily N+1, but it's a SQL query for information that you already had, or you could do in a more efficient way. So a common thing for unnecessary SQL would be people will filter an ActiveRecord::Collection like ten different ways when they could have just loaded the whole collection, filtered it with Ruby in the ten different ways afterwards, and that works really well if the collection that you're loading is like 10, 20. Turning that into one database query, plus a bunch of calls to innumerable methods is often way faster than doing that as ten separate database queries. Also, that tends to be a more robust approach. This doesn't happen in most companies, but what could happen is the database is like a shared resource. It's a resource that everybody is affected by. So a performance degradation to the database is the worst possible scenario because everything is affected. But if you screw up what's happening at an individual Rails process, then only that Rails process is affected. The blast radius is tiny. It's just that one request. So doing less stuff in the database while it can actually seem like, oh, that doesn't feel right. I'm supposed to do a lot of stuff in the database. It actually can reduce blast radiuses of performance issues because you're not doing it on this database that everyone has to have access to. There are a lot of areas of gray here. And I talk a lot in all my other material like why -- There's a lot of nuance here. +So database is the main stuff. Issues in how you write your Ruby code is probably the other one. Usually, that's just what I would call code that goes bump in the night. It's code that you don't know is running but actually is. Profilers are what help us figure that out. So oftentimes, I'll have someone open up a profiler on their controller action for the first time. And they're like, wait a minute, I had no idea that such and such was running during this controller action, and actually, we don't need to do that at all. So why is it here? So that's the second most common issue. And then the third issue that really doesn't actually come up all that often is object allocation, numbers of objects that get created. So primarily, this is a problem in index actions or actions transactions that deal with big collections. So in Ruby, we often get overly focused on garbage collection, but garbage collection doesn't take any time if you just don't create objects. And object creation itself takes time. So looking at code through the lens of what object does this code create? And trying to get rid of those object allocations can often be a pretty productive way to make stuff faster. +STEPH: You said a lot of amazing things there. So I'm debating on which one to follow up on. I think the one that stuck out to me the most where I have felt pain around this is you mentioned identifying code that goes bump in the night or code that is running, but it doesn't need to be run. And that is something that I've run into with applications where we have a code path that seems important, but yet I can't prove that it's being executed and exactly why it's there and what flow it's supporting. And I'm curious, do you have any tips or tricks in how you’ve helped teams identify that this code path isn't used and it's something that we can remove and then that itself will help speed up the performance of that particular endpoint? +NATE: Like, there's no performance cost to like 100 models in an application that never actually get used. There's really no performance downside to code in an app that doesn't actually ever get run. But instead, what happens is code gets added into callbacks that usually is probably the biggest offender that’s like, always do this thing after you do X. But then, two years later, you don't always need to do that thing after you do X. So the callbacks always run, but sometimes requirements change, and they don't always need to be run. So usually, it's enough to just pop the profiler now on something. And I have people look at it, and they're like, “I don't know why any of this is happening.” Like, it's usually a pretty big Eureka moment once we look at a flame graph for the first time and people understand how to read those, and they understand what they're looking at. But sometimes there's a bit of a process where especially in a bigger app where it's like, “Such and such is running, and this was an entire other team that's working on this. I have no idea what this even does.” So on bigger apps, there's going to be more learning that has to get done there. You have to learn about other parts of the application that maybe you've never learned about before. But profiling helps us to not only see what code is running but also what that relative importance is. Like, okay, maybe this one callback runs, and you don't know what it does, and it's probably unnecessary. But if it only takes 1% of the total time to run this action, that's probably less important than something that takes 20% of total time. And so profilers help us to not only just see all the code that's being run but also to know where that time goes and what time corresponds to what parts of the code. +STEPH: Yeah, that's often the code that makes me the most nervous is where it's code that I suspect is being run or maybe being run, but I don't understand why it's there and then figuring out if it can be removed and then figuring out ways to perhaps even log when a call is being made to that code to determine if it's truly in use or not or at least supported by a code path that a user is hitting. You have a blog post that I read recently that I really appreciated that talks about essentially gaming benchmarking where you talk about the importance of having context around benchmarks. So if someone says, “I've improved something where it is now 10% faster.” It's like, well, what is that 10% relative to? And if it's a tool that other people are using, what does that mean for them? Or did you improve something that was already very fast, and you made it 10% faster? Was that a really valuable use of your time? +NATE: Yeah. You know, something that I read recently that made me think of that again was this Hacker News post that went viral. That was like, how I optimize an AWS EC2 instance to take 1.5 million requests per second on my JSON API. And out of the box, it was like 500 requests per second, and then he got it to 1.5 million. And the whole article was presented with relative numbers. So it was like, “I made this change, and things got 33% faster. And if you do the whole thing right, 500 to 1.5 million requests per second, it's like my app is three times faster now,” or whatever. And that's true, but it would probably be more accurate to say, “I've taken three-millionth of a second out of every request in my app.” That's two ways of saying the same thing because latency and throughput are just related that way. But it's probably more accurate and more useful to say the absolute number, but it doesn't make for great blog posts, so that doesn't tend to get said. The kinds of improvements that were discussed in this article were really, really low-level stuff. That was like if you turn off...I think it was like turn off iptables or something like that. And it's like, that shaves a microsecond off of every time we make a syscall or something. And that is useful if your performance goal is to serve 1.5 million requests per second Hello World responses off of my EC2 instance, which is what this person admittedly was doing. But there's a tendency to walk that back to if I do all things in this article, my application will be three times faster. And that's just not what the evidence says. It's not what you were told. So there's just a tendency to use relative numbers when absolute numbers would be more useful to giving you the context of like, oh, well, this will improve my app or it won't. We get this a lot in Puma. We get benchmarks that are like, hey, this thing is going to help us to do 50,000 requests per second in Puma instead of 10,000. And another way of saying that is you took a couple of nanoseconds off of the overhead of every single request to Puma. And most Puma applications have a hundred millisecond response time. So it's like, yeah, I guess it's cool that you took a nanosecond off, and I’m sure it's going to help us have cool benchmarks, but none of our users are going to care. No one that's used Puma is going to care that their requests are one nanosecond faster now. So what did we really gain here? +STEPH: Yeah, it makes sense that people would want to share those more...I want to call them sparkly stats and something that catches your attention, but they're not necessarily something that's going to translate to us in the way that we hoped that they will in terms of it's not going to speed up our app 30% or have those same rewards or benefits. Speaking of Puma, how is it being a co-maintainer of Puma? And how do you balance that role with all of your other work? +NATE: Actually, it doesn't take all that much of my time. I try to spend about 15 minutes a day on it. And that's really possible because of the philosophy I have around open-source maintenance. I think that open source projects are fundamentally about collaboration and about sharing our hard-fought extractions and fixes and knowledge together. And it's not about a single super contributor or super maintainer who is just out of the goodness of their heart releasing all of their incredible work and time into the public domain or into a free software license. Puma is a pretty popular piece of Ruby software, so a lot of people use it. And I have things on my back burner of if I ever got 20 hours to work on Puma, here’s stuff I would do. But there are a lot of other people that have more time than me to work on Puma. And they're just as smart, and they have other tools they've got in their locker that I don't have. And I realized that it was more important that I actually find ways to recruit and then unblock those people than it was for me to devote as much time as I could to Puma. And so my work on Puma now is really just more like management than anything else. It's more trying to recruit new contributors and trying to give them what they need to help Puma. And contributing to open source is a really fraught experience for a lot of people, especially their first time. And I think we should also be really conscious of that. Like, 95% of software developers have really never contributed to open source in a meaningful way. And that's a huge talent pool of people that could be helping us that aren't. So I'm less concerned about the problems of the 5% that are currently contributing than I am about why there are 95% of us that don't do anything. So that's what gets me excited to work on Puma now, is trying to change that ratio. +STEPH: I really like that mindset of where you are there to provide guidance but then essentially help unblock others as they're making contributions to the project but then still be there to have the history and full context and also provide a path forward of a good direction for Puma to head. In regards to encouraging more people to contribute to open source projects, I've often heard people say how challenging that is, where they have an open-source project that they would really love people to contribute to but finding people is really hard or just letting people know that they're interested in contributions. Have you had any strategies that have been successful for you in encouraging people to contribute? +NATE: Yeah. So first thing, the easiest thing is we have a contributing.md file. So that's something I think more projects should adopt is have an actual file in your project that says everything about how to contribute. Like, what kinds of contributions do you want? Different projects have different things that they want. Like, Rails doesn't want to refactor PRs. Don't send a refactor PR to Rails because they'll reject it. Puma, I'm happy to accept those. So letting people know like, “Hey, here's how we work here. Here's the community we're creating, and here's how it works. Here's how to get involved.” And I think of it as hanging out the shingle and saying, “Yes, I want your contributions. Here's how to do it.” That alone puts you a step above other projects. +The second thing I would say is you need to have contributor-only communication channels. So we have Matrix chat. So Matrix is like this successor to IRC. So we have a chat channel basically, but it's like contributors only. I don't enforce that, but I just don't want support requests in there. I don't want people coming in there and being like, “My Puma config doesn't work.” And instead, it's just for people that want to contribute to Puma, and that want to help out. If you have a question and come in there, anyone can answer it. +And then finally, another thing that I've had success with is doing one-on-one stuff. So I will actually...I have a Calendly invite that I think is in contributing.md now that you can just book 30 minutes with me anytime about contributing to Puma. And I will get on a Zoom call with you and talk to you about what are your concerns? Where do I think you can help? And I give my time away that way. The way I see it is like if I do that 20 times and I create one super contributor to Puma, that is worth more than me spending 10 hours on Puma because that person can contribute 100, 200, 1,000 hours over their lifetime of contributing to Puma. So that's actually a much more higher leverage contribution, really from my perspective. It's actually helping other people contribute more. +STEPH: Yeah, that's huge to offer people to say, “Hey, you can book time with me, and I will walk you through and let you know where you can start making an impactful contribution right away,” or “Here are some areas that I think you'd be interested, to begin with.” That seems like such a nice onboarding for someone who says, “I'm interested, but I'm nervous,” or “I'm just not sure about where to get started.” Also, I love your complaint department voice for the person who their Puma config doesn't work. That was delightful. [chuckles] +NATE: I think it's a little bit part of my open-source philosophy that, especially at a certain scale like Puma is at that we really kind of over-prioritize users. And I'm not really here to do support; I'm here to make the project better. And users don't actually contribute to open source projects. Users use the thing, and that's great. That's the whole reason we're open-sourcing is so more people use it. But it's important not to prioritize that over people who want to make the project better. And I think a lot of times; people get caught up in this almost clout chasing of getting the most GitHub stars that they think they need and users they think they need. And you don't get paid for having users, and the product doesn't get any better either. So I don't prioritize users. I prioritize the quality of the project and getting contributors. And that will create a better project, which will then create more users. So I think it's easy to get sidetracked by people that ask for your time when they're not giving anything back to the project in return. And especially at Puma’s scale, we have enough people that want my time or the time of other maintainers at Puma so that they can contribute to the project. And putting user support requests ahead of that is not good for the project. It's not the biggest, long-term value increase we could be making, so I don't prioritize them anymore. +STEPH: Yep. That sounds like more the pursuit of sparkly stats and looking for all those GitHub stars or all of those likes. Well, Nate, if you're game, I have two listener questions that I'd like to run by you because I shared with some folks that you are going to be on The Bike Shed today. And they're very excited and have two questions that they'd like me to run by you. How does that sound? +NATE: Yeah, all right. +STEPH: So the first question is, are there any paradigms or trends in Rails that inherently hurt performance? +NATE: Yeah. I get this question a lot, and I will preface it with saying that I'm the performance guy, and I'm not the software design guy. And I get a lot of questions about does such and such software design...how does that impact performance? And usually, there's like a way to do anything in a performant way. And I'm just here to help people to find the performant way and not to prescribe “You must always do X, Y, or Z,” or “ActiveRecord is bad. Never use it.” That's not my job here. And in my experience, there's a fast way to do almost anything. +Now, one thing that I think is dying, I guess, or one approach or one common...I don't know what to call it. One common mistake that is clearly wrong is to not do any form of server-side rendering in a web application. So I am anti-client-side app. But there are ways to do that and to do it quickly. But rendering a basically blank document, which is what most of these applications will do when they're using Rails as a back-end…you'll serve this basically blank document or a document with maybe some Chrome in it. And then, the client-side app has to execute, compile JavaScript, make XHR requests, and then render the page. That is just by definition slower than serving somebody a server-side rendered page. Now, I am 100% agnostic on how you want to generate that server-side rendering. There are some people that are working on better ways to do that with Rails and client-side apps. Or you could just go the Hotwire Turbolinks way. And it's more progressive enhancement where the back-end is always just serving the server-side rendered response. And then you do some JavaScript on top of that. +So I think five years from now, nobody will be doing this approach of serving blank documents and then booting client-side apps into that. Or at least it will be seen as outdated enough that you should never design a project that way anymore. It's one of those few things where it's like, yeah, just by definition, you're adding more steps into a rendering flow. That means, by necessity, it has to be slower. So I think everybody should be thinking about server-side rendering in their project. Again, I’m totally agnostic on how you want to implement that. With React, whatever front-end flavor of the month you want to go with, there's plenty of ways to do that, but I just think you have to be prioritizing that now. +STEPH: All right. Well, I like that five-year projection of where we're headed. I have found that it's often the admin-side where people will still bring in a lot of JavaScript rendering, just to touch on a bit of what you're saying, in terms of let's favor the server-rendered HTML versus over-optimizing a space that one, probably isn't a profitable space in terms that we do want our admins to have a great experience for our product. But if they are not necessarily our users, then it also doesn't need to be anything that is over the top or fancy or probably uses a lot of JavaScript. And instead, we can start simple. And there's a number of times that I've been on projects where we have often walked the admin back to be more server-rendered because we got to a point where someone was very excited to make the admin very splashy and quick but then couldn't keep up with the requests because then they were having to prioritize the user experience first. So it was almost like optimizing the admin, but then it got left out in the cold. So then it's just sort of this poor experience. +NATE: Yes. Shopify famously walked back their admin from I think it was Backbone to Turbolinks. And I think that that has now moved back to React is my understanding. But Shopify is a huge company, so they have plenty of time and resources to be able to do that. But I just remember that happening at the time where I was like, oh wow, they just rolled the whole thing back to Turbolinks again. And now, with the consolidation that's gone on in the React world, it's a little bit easier to pipe a server-side rendering into a React app. Whereas with Backbone, it was like no one knew what you were doing. So there was less knowledge about how to server-side render this stuff. Now it doesn't seem to be so much of a problem. But yeah, I mean, Rails is really good at CRUD apps, and admin is like 99% CRUD. And adhering as closely as possible to the Rails Golden Path there in an admin seems to be the most productive way to work on that kind of feature. +STEPH: All right. Ready for your second question? +NATE: Yes. +STEPH: Okay. This one's a bit more in-depth. They also mentioned a particular project name. So I am going to swap it out with a different name. So on project cinnamon roll, we found a really gnarly time-consuming API endpoint that's getting hammered. And on a first pass, we addressed a couple of N+1 issues and tuned the performance, and felt pretty confident that they had addressed the issue. But it was still fairly slow. So then they took some additional incremental steps. So they swapped out to use OJ for serialization that shaved off an additional 10% but was still slow. They also went the route of going straight to Rails cache with a one-minute expiration. So that way, they could avoid mucking with cache busting because they confirmed with the client that data could be slightly stale. And this was great. It worked out well. So it dropped their average response time down to less than 70 milliseconds. With all that said, that journey took a few hours over a few days, and multiple production deploys. And had they gone straight to the cache, then they would have had a 15-minute fix with a single deploy. So this person's wondering, are there any other examples like that where, rather than taking these incremental seemingly obvious performance whims, there are situations where you want to be much more direct with your path? +NATE: I guess I'd say that profiling can help you to understand and form better hypotheses about what will make things faster and what won't. Because a profiler can't really lie to you about where time goes, either you spent 20% of your time in this method, or you didn't. So I don't spend any time in any of my material talking about what JSON serializer you use. Because really that's actually never...that's really never anybody's bottleneck. It's never a huge proportion of people's total percentage of time. And I know that because I've looked at enough profiles that the issues are usually in other places. So I would say that if your hypotheses that you're generating are not working, it's because you're not generating good enough hypotheses. And profiling is the place to do that. So having profilers running in production is probably the biggest level-upscale-like that most teams could take. So having profilers that you can access as on production servers as a user is probably the biggest level up that you could make to generating the hypotheses because that'll have real production data, real production servers, real production environment. And it's pretty common now that pretty much every team that I work with either has that already, or we work on implementing it. It's something that I've seen in production at GitHub and Shopify. You can do it yourself with rack-mini-profiler. It's all about setting up the authorization, just making sure that only authorized users get to see every single SQL query generated in the flame graph and all that. But other than that, there's no reason you shouldn't do it. So I would say that if you're not generating the right hypotheses or you don't...if the last hypothesis out of 10 is the one that works, you need better hypotheses, and the best way to do that is better profiling. +STEPH: Okay, better profiling. And yeah, it sounds like there's also a bit of experience in there in terms of things that you're used to seeing, that you've noticed that could be outliers in terms of that they're not necessarily the thing that you want to improve. Like you mentioned spending time on how you're serializing your JSON is not somewhere that you would look. But then there are other areas that you've gained experience that you know would be likely more beneficial to then focus on to form that hypothesis. +NATE: Yeah, that's a long way of saying experience pays off. I've had six years of doing this every single day. So I'm going to be pretty good at...that's what I get paid for. [laughs] So if I wasn't very good at that, I probably wouldn't be making any money at it. +STEPH: [laughs] All right. Well, thanks, Nate, so much for coming on the show today and talking so much about performance. On that note, I think it's a good place for us to wrap up. If people are interested in following along with what you're working on and they want to keep up with your latest and greatest workshops that are coming out, where can they find you on the internet? +NATE: speedshop.co is my site. @nateberkopec on Twitter. And speedshop.co has a link to my newsletter, which is where I'm actively thinking every week and publishing stuff too. So if you want to get the drip of news and thoughts, that's probably the best place to go. +STEPH: Perfect. All right. Well, thank you so much. +NATE: No problem. +STEPH: The show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey. +STEPH: And I’m @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +Together: Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Nate Berkopec is the author of the Complete Guide to Rails Performance, the creator of the Rails Performance Workshop, and the co-maintainer of Puma. He talks with Steph about being known as "The Rails Speed Guy," and how he ended up with that title, publishing content, working on workshops, and also contributing to open source projects. (You could say he's kind of a busy guy!)

+ + + +

Transcript:

+ +

STEPH: All right. I'll kick us off with our fancy intro. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I’m Steph Viccari. And this week, Chris is taking a break. But while he's away, I'm joined by Nate Berkopec, who is the owner of Speedshop, a Ruby on Rails performance consultancy. And, Nate, in addition to running a consultancy, you're the co-maintainer of Puma. You're also an author as you wrote a book called The Complete Guide to Rails Performance. And you run the workshop called The Rails Performance Workshop. So, Nate, I'm sensing a theme here.

+ +

NATE: Yeah, make code go fast.

+ +

STEPH: And you've been doing that for quite a while, haven't you?

+ +

NATE: Yeah. It's pretty much been since 2015, or so I think. It all started when I actually wrote a blog post about Turbolinks that got a lot of pick up. My hot take at the time was that Turbolinks is actually a good thing. That take has since become uncontroversial, but it was quite controversial in 2015. So I got a lot of pick up on that, and I realized I liked working on performance, and people seem to want to hear about it. So I've been in that groove ever since.

+ +

STEPH: When you started down the path of really focusing on performance, were you running your own consultancy at that point, or were you working for someone else?

+ +

NATE: I would say it didn't really kick off until I actually published The Complete Guide to Rails Performance. So after that came out, which was, I think, March of 2016…I hope I’m getting that right. It wasn't until after that point when it was like, oh, I'm the Rails performance guy now. And I started getting emails inbound about that. I didn't really have any time when I was actually working on the CGRP to do that sort of thing. I just made that my full-time job to actually write, and market, and publish that. So it wasn't until after that that I was like, oh, I'm a performance consultant now. This is the lane I've driven myself into. I don't think I really had that as a strategy when I was writing the book. I wasn't like, okay, this is what I'm going to do. I'm going to build some reputation around this, and then that'll help me be a better consultant with this. But that's what ended up happening.

+ +

STEPH: I see. So it sounds like it really started more as a passion and something that you wanted to share. And it has manifested to this point where you are the speed guy.

+ +

NATE: Yeah, I think you could say that. I think when I started writing about it, I just knew...I liked it. I liked the work of performance. In a lot of ways, performance is a much more concrete discipline than a lot of other sub-disciplines of programming where I joke my job is number go down. It's very measurable, and it's very clear when you've made a difference. You can say, “Hey, this number was this, and now it's this. Look what I did.” And I always loved that concreteness of performance work. It makes it actually a lot more like a real kind of engineering discipline where I think of performance engineering as clarifying requirements and the limitations and then building a project that meets the requirements while staying within those limitations and constraints. And that's often not quite as clear for other disciplines like general feature work. It's kind of hard to say sometimes, like, did you actually make the user's life better by implementing such and such? That's more of a guess. That's more of a less clear relationship. And with performance, nobody's going to wake up ten years from today and wish that their app was slower. So we can argue about the relative importance of performance in an application, but we don't really argue about whether or not we made it faster because we can prove that.

+ +

STEPH: Yeah. That's one area that working with different teams (as I tend to shift the clients that I'm working with every six months) where we often push hard around feature work to say, “How can we measure this? How can we know that we are delivering something valuable to users?” But as you said, that's really tricky. It's hard to evaluate. And then also, when you add on the fact that if I am leaving that project in six months, then I don't have the same insights to understand how something went for that team. So I can certainly appreciate the satisfaction that comes from knowing that, yes, you are delivering a faster app. And it's very measurable, given the time that you're there, whether it's a short time or if it's a long time that you're with that team.

+ +

NATE: Yeah, totally. My consulting engagements are often really short. I don't really do a lot of super long-term stuff, and that's usually fine because I can point to stuff and say, “Yep. This thing was at A, and now it's at B. And that's what you hired me to do, so now it's done.”

+ +

STEPH: I am curious; given that you have so many different facets where you are running your consultancy, you are also often publishing a lot of content and working on workshops and then also contributing to open source projects. What does a typical week look like for you?

+ +

NATE: Well, right now is actually a decent example. I have client work two or three days a week. And I'm actually working on a new product right now that I'm calling Sidekiq in Practice, which is a course/workshop about scaling Sidekiq from zero to 1000 jobs per second. And I'll spend the other days of the week working on that. My content is...I always struggle with how much time to spend on blogging specifically because it takes so much time for me to come up with a post and publish that. But the newsletter that I write, which I try to write two once a week, I haven't been doing so well with it lately. But I think I got 50 newsletters done in 2020 or something like that.

+ +

STEPH: Wow.

+ +

NATE: And so I do okay on the per-week basis. And it's all content I've never published anywhere else. So that actually is like 45 minutes of me sitting down on a Monday and being like rant, [chuckles] slam keyboard and rant and then hit send. And my open source work is mostly 15 minutes a day while I'm drinking morning coffee kind of stuff. So I try to spread myself around and do a lot of different stuff. And a lot of that means, I think, pulling back in terms of thinking how much you need to spend on something, especially with newsletters, email newsletters, it was very easy to overthink that and spend a lot of time revising and whatever. But some newsletter is better than no newsletter. And especially when it comes to content and marketing, I've learned that frequency and regularity is more important than each and every post is the greatest thing that's ever come out since sliced bread. So trying to build a discipline and a practice around doing that regularly is more important for me.

+ +

STEPH: I like that, some newsletter is better than no newsletter. I was listening to your chat with Brittany Martin on the Ruby on Rails podcast. And you said something very honest that I appreciated where you said, “Writing is really hard, and writing sucks.” And that made me laugh in the moment because even though I do enjoy writing, I still find it very hard to be disciplined, to sit down and make it happen. And then you go into that editor mode where you critique everything, and then you never really get it published because you are constantly fixing it. It sounds like...you've mentioned you set aside about 45 minutes on a Monday, and you crank out some work. How do you work through that inner critic? How do you get past it to the point where then you just publish?

+ +

NATE: You have to separate the steps. You have to not do editing and first drafting at the same time. And the reason why I say it sucks and it's hard is because I think a lot of people don't do a lot of regular writing, maybe get intimidated when they try to start. And they're like, “Wow, this is really hard. This is not fun.” And I'm just trying to say that's everybody's experience and if it doesn't get any better, because it doesn't, [chuckles] there's nothing wrong with you, that's just writing, it's hard. For me, especially with the newsletter, I just have to give myself permission not to edit and to just hit send when I'm done. I try to do some spell checking,, and that's it. I just let it go. I'm not going back and reading it through again and making sure that I was very clear and cogent in all my points and that there's a really good flow through that newsletter. I think it comes with a little bit of confidence in your own ideas and your own experience and knowledge, believing that that's worth sharing and that's worth somebody's time, even if it's not a perfect expression of what's in your head. Like, a 75% expression is good enough, especially in a newsletter format where it's like 500 to 700 words. And it's something that comes once a week. And maybe not everyone's amazing, but some of them are, enough of them are that people stay subscribed. So I think a combination of separating editing and first drafting and just having enough confidence and the basis where you have to say, “It doesn't have to be perfect every single time.”

+ +

STEPH: Yeah, I think that's something that I learned a while back to apply to my coding process where I had to separate those two steps of where I have to let the creator in me just create and write some code and make it work, and then come back to the editing process, and taking a similar approach with writing. As you may be familiar with thoughtbot, we're big advocates when it comes to sharing content and sharing things that we have learned throughout the week and different projects that we're working on. And often when people join thoughtbot, they're very excited to contribute to the blog. But it is daunting for that first post because you think it has to be this really grand novel. And it has to be something that is really going to appeal to everybody, and it's going to help everyone. And then over time, you learn it's like, oh well, actually it can be this very just small thing that I learned that maybe only helps 20 people, but it still helped those 20 people. And learning to publish more frequently versus going for those grand pieces is more favorable and often more helpful for people.

+ +

NATE: Yeah, totally. That's something that is difficult for people at first. But everything in my experience has led me to believe that frequency and regularity is just as, if not more important than the quality of any individual piece of content that I put out. So that's not to say that...I guess it's weird advice to give because people will take it too far the other way and think that means he's saying quality doesn't matter. No, of course, it does, but I think just everyone's internal biases are just way too tuned towards this thing must be perfect. I've also learned we're just really bad judges internally of what is useful and good for people. Stuff that I think is amazing and really interesting sometimes I'll put that out, and nobody cares. [chuckles] And the other stuff I put out that's just like the 45-minute banging out newsletter, people email me back and say, “This is the most helpful thing anyone’s ever read.” So that quality bias also assumes that you know what is good and actually we're not really good at that, knowing every time what our audience needs is actually really difficult.

+ +

STEPH: That's totally fair. And I have definitely run into that too, where I have something that I'm very proud of and excited to share, and I realize it relates to a very small group of people. But then there's something small that I do every day, and then I just happen to tweet about it or talk about it, and suddenly that's the thing that everybody's really excited about. So yeah, you never know. So share it all.

+ +

NATE: Yeah. And it's important to listen. I pay attention to what people get interested in from what I put out, and I will do more of that in the future.

+ +

STEPH: You mentioned earlier that you are working on another workshop focused on Sidekiq. What can you tell me about that?

+ +

NATE: So it's meant to be a guide to scaling Sidekiq from zero to 1000 requests per second. And it's meant to be a missing guide to all the things that happen, like the situations that can crop up operationally when you're working on an application that does a lot of work with Sidekiq. Whereas Mike Sidekiq, Wiki, or the docs are great about how do, you do this? What does this setting mean? And the basics of getting it just running, Sidekiq in practice, is meant to be the last half of that. How do you get it to run 1,000 jobs per second in a day-to-day application? So it's the collected wisdom and collected battle scars from five years of getting called in to fix people's Sidekiq installations and very much a product of what are the actual problems that people experience, and how do you fix and deal with those? So stuff about memory and managing Sidekiq memory usage, how to think about queues. Like, what should your queue structure be? How many should you have? Like, how do you organize jobs into queues, and how do you deal with problems like some client is dropping 10,000, 20,000 jobs into a queue. And now the other jobs I put in that queue have 20,000 jobs in front of them. And now this other job I've got will take three hours to get through that queue. How do you deal with problems like that? All the stuff that people have come to me over the years and that I've had to help them fix.

+ +

STEPH: That sounds really great. Because yeah, I find that teams who are often in this space with Sidekiq we just let it run until there's a fire. And then suddenly, we start to care as to how it's processing, and we care about our queue structure and how many workers that we have that are pulling from that queue. So that sounds really helpful. When you're building a workshop, do you often go back to any of those customers and pull more ideas from them, or do you find that you just have enough examples from your collective work with clients that that itself creates a course?

+ +

NATE: Usually, pretty much every chapter in the workshop I've probably implemented like three-plus times, so I don't really have to go back to any individual customer. I have had some interesting stuff with my current client, Gusto. And Gusto is going through some background job reorganization right now and actually started to implement a lot of the things that I'm advocating in the workshop actually without talking to me. It was a good validation of hey, we all actually think the same here. And a lot of the solutions that they were implementing were things that I was ready to put down into those workshops. So I'd like to see those solutions implemented and succeed. So I think a lot of the stuff in here has been pretty battle-tested.

+ +

STEPH: For the Rails Performance Workshop, you started off doing those live and in-person with teams, and then you have since switched to now it is a CLI course, correct?

+ +

NATE: That's correct. Yep.

+ +

STEPH: I love that very much. When you’ve talked about it, it does feel very appropriate in terms of developers and how we like to consume content and learn. So that is really novel and also, it seems like a really nice win for you. So then other people can take this course, but you are no longer the individual that has to deliver it to their team, that they can independently take the course and go through it on their own. Are you thinking about doing the same thing for the Sidekiq course, or what are your plans for that one?

+ +

NATE: Yeah, it's the exact same structure. So it's going to be delivered via the command line. Although I would say Sidekiq in practice has more text components. So it's going to be a combination of a very short manual or book, and some video, and some hands-on exercises. So, an equal blend between all three of those components. And it's a lot of stuff that I've learned over having to teach; I guess intermediate to advanced programming concepts for the last five years now that people learn at different paces. And one of the great things about this kind of format is you can pick it up, drop it off, and move at your own speed. Whereas a lot of times when I would do this in person, I think I would lose people halfway through because they would get stuck on something that I couldn't go back to because we only had four hours of the day. And if you deliver it in a class format, you're one person, and I've got 24 other people in this room. So it's infinitely pausable and replayable, and you can go back, or you can just skip ahead. If you've got a particular problem and you're like, hey, I just want to figure out how to fix such and such; you can do that. You can just come in and do a particular thing and then leave, and that's fine. So it's a good format that way. And I've definitely learned a lot from switching to pre-recorded and pre-prepared stuff rather than trying to do this all live in person.

+ +

STEPH: That is one of the lessons that I've learned as well from the couple of workshops that I've led is that doing them in person, there's a lot of energy. And I really enjoy that part where I get to see people respond to the content. And then I get a lot of great feedback from people about what type of questions they have, where they are getting stuck. And that part is so important to me that I always love doing them live first. But then you get to the point, as you'd mentioned, where if you have a room full of 20 people and you have two people that are stuck, how do you help them but then still keep the class going forward? And then, if you are trying to tailor this content for a wide audience…so maybe beginners could take the Rails Performance Workshop, or they could also take the Sidekiq course. But you also want the more senior engineers to get something out of it as well. It's a very challenging task to make that content scale for everyone.

+ +

NATE: Yeah. What you said there about getting feedback and learning was definitely something that I got out of doing the Rails Performance Workshop in person like three dozen times, was the ability to look over people's shoulders and see where they got stuck. Because people won't email me and say, “Hey, this thing is really confusing.” Or “It doesn't work the way you said it does for me.” But when I'm in the same room with them, I can look over their shoulder and be like, “Hey, you're stuck here.” People will not ask questions. And you can get past that in an in-person environment. Or there are even certain questions people will ask in person, but they won't take the time to sit down and email me about. So I definitely don't regret doing it in person for so long because I think I learned a lot about how to teach the material and what was important and how people...what were the problems that people would encounter and stuff like that. So that was useful. And definitely, the Rails Performance Workshop would not be in the place that it is today if I hadn't done that.

+ +

STEPH: Yeah, helping people feel comfortable asking questions is incredibly hard and something I've gone so far in the past where I've created an anonymous way for people to submit questions. So during class, even if you didn't want to ask a question in front of everybody, you could submit a question to this forum, and I would get notified. I could bring it up, and we could answer it together. And even taking that strategy, I found that people wouldn't ask questions. And I guess it circles back to that inner critic that we have that's also preventing us from sharing knowledge that we have with the world because we're always judging what we're going to share and what we're going to ask in front of our peers who we respect. So I can certainly relate to being able to look over someone's shoulder and say, “Hey, I think you're stuck. We should talk. Let me walk you through this or help you out.”

+ +

NATE: There are also weird dynamics around in-person, not necessarily in a small group setting. But I think one thing I really picked up on and learned from RailsConf2021 which was done online, was that in-person question asking requires a certain amount of confidence and bravado that you're not...People are worried about looking stupid, and they won't ask things in a public or semi-public setting that they think might make them look dumb. And so then the people that do end up asking questions are sometimes overconfident. They don't even ask a question. They just want to show off how smart they are about a particular issue. This is more of an issue at conferences. But the quality of questions that I got in the Q&A after RailsConf this year (They did it as Discord chats.) was way better. The quality of questions and discussion after my RailsConf talk was miles better than I've ever had at a conference before. Like, not even close. So I think experimenting with different formats around interaction is really good and interesting. Because it's clear there's no perfect format for everybody and experimenting with these different settings and different methods of delivery has been very useful to me.

+ +

STEPH: Yeah, that makes a ton of sense. And I'm really glad then for those opportunities where we're discovering that certain forums will help us get more feedback and questions from people because then we can incorporate that and to future conferences where people can speak up and ask questions, and not necessarily be the one that's very confident and enjoys hearing their own voice. For the Rails Performance Workshop, what are some of the general things that you dive into for that workshop? I'm curious, what is it like to attend that workshop? Although I guess one can't attend it anymore. But what is it like to take that workshop?

+ +

NATE: Well, you still can attend it in some sense because I do corporate bookings for it. So if you want to buy 20 seats, then I can come in and basically do a Q&A every week while everybody takes the workshop. Anyway, I still do that. I have one coming up in July, actually. But my overall approach to performance is to always start with monitoring. So the course starts with goals and monitoring and understanding where you want to go and where you are when it comes to performance. So the first module of the Rails Performance Workshop is actually really a group exercise that's about what are our performance requirements and how can we set those? Both high-level and low-levels. So what is our goal for page load time? How are we going to measure that? How are we going to use that to back into lower-level metrics? What is our goal for back-end response times? What is our goal for JavaScript bundle sizes? That all flows from a higher-level metric of how fast you want the page to load or how fast you want a route to change in a React app or something, and it talks about those goals. And then where should you even start with where those numbers should be? And then how are you going to measure it? What are the browser events that matter here? What tools are available to help you to get that data? Because without measurement, you don't really have a performance practice. You just have people guessing at what stuff is faster and what is not. And I teach performance as a scientific process as science and engineering. And so, in the scientific method, we have hypotheses. We test those hypotheses, and then we learn based on those tests of our hypotheses. So that requires us to A, have a hypothesis, so like, I think that doing X makes this faster. And I talk about how you generate hypotheses using profiling, using tools that will show you where all the time goes when you do this particular operation of your software—and then measuring what happens when you do that? And that's benchmarking. So if you think that getting rid of method X or changing method X will speed up the app, benchmarking tells you did you actually speed it up or not? And there are all sorts of little finer points to making sure that that hypothesis and that experiment is tested in a valid way.

+ +

I spend a lot of time in the workshop yapping about the differences between development/local environments and production environments and which ones matter. Because what differences matter, it's not often the ones that we think about, but instead it's differences like actually in Rails apps the asset packaging and asset pipeline performs very differently in production than it does in development, works very differently. And it makes it one of the primary reasons development is slower than production, so making sure that we understand how to change those settings to more production-like settings. I talk a lot about data. It’s the other primary difference between development and production is production has a million users, and development has 10. So when you call things like User.all, that behavior is very different in production than it is locally. So having decent production-like data is another big one that I like to harp on in the workshops. So it's a process in the workshop of you just go lesson by lesson. And it's a lot of video followed up by hands-on exercises that half of them are pre-baked problems where I'm like, hey, take a look at this Turbolinks app that I've given you and look at it in DevTools. And here's what you should see. And then the other half is like, go work on your application. And here are some pull requests I think you should probably go try on your app. So it's a combination of hands-on and videos of the actual experience going through it.

+ +

STEPH: I love how you start with a smaller application that everyone can look at and then start to learn how performant is this particular application that I'm looking at? Versus trying to assess, let’s say, their own application where there may be a number of other variables that they have to consider. That sounds really nice. You'd mentioned one of the first exercises is talking about setting some of those goals and perhaps some of those benchmarks that you want to meet in terms of how fast should this page load, or how quickly should a response from the API be? Do you have a certain set of numbers for those benchmarks, or is it something that is different for each product?

+ +

NATE: Well, to some extent, Google has suddenly given us numbers to work with. So as of this month, I think, June 2021, Google has started to use what they're calling Core Web Vitals in their ranking of search results. They've always tried to say it's not a huge ranking factor, et cetera, et cetera, but it does exist. It is being used. And that data is based on Chrome user telemetry. So every time you go to a website in Chrome, it measures three metrics and sends those back to Google. And those three metrics are Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). And First Input Delay and Cumulative Layout shift are more important for your single-page apps kind of stuff. It's hard to screw those up with a Golden Path Rails app that just does Turbolinks or Hotwire or whatever. But Largest Contentful Paint is an easy one to screw up. So Google's line in the sand that they've drawn is 2.5 seconds for Largest Contentful Paint. So that's saying that from clicking on your website in a Google search result, it should take 2.5 seconds for the page to paint the largest component of that new page. That's often an image or a video or a large H1 tag or something like that. And that process then will help you to...to get to 2.5 seconds in Largest Contentful Paint; there are things that have to happen along the way. We have to download and execute all JavaScript. We have to download CSS. We have to send and receive back-end responses. In the case of a simple Hotwire app, it's one back-end response. But in the case of a single-page app, you got to download the document and then maybe download several XHR fetches or whatever. So there's a chain of events that has to happen there. And you have to walk that back now from 2.5 seconds in Largest Contentful Paint. So that's the line that I'm seeing getting drawn in the sand right now with Google's Core Web Vitals. So pretty much any meaningful web application performance metric can be walked back from that.

+ +

STEPH: Okay. That's super helpful. I wasn't aware of the Core Web Vitals and that particular stat that Google is using to then rank the sites. I was going to ask, this kind of blends in nicely into when do you start caring about performance? So if you have a new application that you are just starting to get to market, based on the fact that Google is going to start ranking you right away, you do have to care some right out of the gate. But I am curious, when do you start caring more about performance, and are there certain tools and benchmarking that you want to have in place from day one versus other things that you'll say, “Well, we can wait until we have X numbers of users or other conditions before we add more profiling?”

+ +

NATE: I'd say as an approach, I teach people not to have a performance strategy of monitoring. So if your strategy is to have dashboards and look at them regularly, you're going to lose. Eventually, you're not going to look at that dashboard, or more often, you just don't understand what you're looking at. You just install New Relic or Datadog or whatever, and you don't know how to turn a dashboard into actual action. Also, it seems to just wear teams out, and there's no clear mechanism when you just have a dashboard of turning that into oh, well, this has to now be something that somebody on our team has to go work on. Contrast that with bugs, so teams usually have very defined processes around bugs. So usually, what happens is you'll get an Exception Notification through Sentry or Bugsnag or whatever your preferred Exception Notification service is. That gets read by a developer. And then you turn that into a Jira ticket or a Kanban board or whatever. And then that is where work is done and prioritized. Contrast that with performance; there’s often no clear mechanism for turning metrics into stuff that people actually work on. So understanding at your organization how that's going to work and setting up a process that automatically will turn performance issues into actual work that people get done is important.

+ +

The way that I generally teach people to do this is to focus instead of dashboards and monitoring, on alerts, on automated thresholds that get tripped and then sends somebody's an email or put something in the Kanban board or whatever. It just has to be something that automatically gets fired. Different tools have different ways of doing this. Datadog has pretty much built their entire product around monitoring and what they call monitors. That's a perfectly fine way to do it, whatever your chosen performance monitoring tool, which I would say is a required thing. I don't think there's really any good excuse in 2021 for not having a performance monitoring tool. There are a million different ways to slice it. You can do it yourself with OpenTelemetry and then like statsD, I don't know, or pay someone else like everyone else does for Datadog or New Relic or AppSignal or whatever. But you got to have one installed. And then I would say you have to have some sort of automated alerting. Now that alerting means that you've also decided on thresholds. And that's the hard work that doesn't get done when your strategy is just monitoring. So it's very easy to just install a dashboard and say, “Hey, I have this average page time load dashboard. That means I'm paying attention to performance.” But if you don't have a clear answer to what number is good and what number is bad, then that dashboard cannot be turned into real action. So that's why I push monitoring so hard is because it allows people to ignore performance is all that matters, and it forces you to make the decision upfront as to what number matters. So that is what I would say, install some kind of performance monitoring. I don't really care what kind.

+ +

Nowadays, I also think there's probably no excuse to not have Real User Monitoring. So there's enough GDPR compliance Real User Monitoring now that I think everyone should be using it. So for industry terms, Real User Monitoring is just performance monitoring in the browser. So it's just users’ browser APIs and sends those back to you or your third-party provider, so having that so you actually are collecting back-end and front-end performance metrics. And then making decisions around what is bad and what is good. Probably everybody should just start with a page load time monitor, Largest Contentful Paint monitor. And if you've got a single-page app, probably hooking up some stuff around route changes or whatever your app...because you don't actually have page loads on every single time you navigate. You have to instrument whatever those interactions are. So having those up and then just drawing some lines that say, “Hey, we want our React route changes to always be one second or less.” So I will set an alert that if the 95th percentile is one second or more, I'm going to get alerted. There's a lot of different ways to do that, and everybody will have different needs there. But having a handful of automated monitors is probably a place to start.

+ +

STEPH: I like how you also focus on once you have decided those thresholds and have that monitoring in place, but then how do you make it actionable? Because I have certainly been part of teams where we get those alerts, but we don't necessarily...what you just mentioned, prioritize that work to get done until we have perhaps a user complaint about it. Or we start actually having pages that are timing out and not loading, and then they get bumped up in the priority queue. So I really like that idea that if we agree upon those thresholds and then we get alerted, we treat that alert as if it is a user that is letting us know that a page is too slow and that they are unable to use our application, so then we can prioritize that work.

+ +

NATE: And it's not all that dissimilar to bugs, really. And I think most teams have processes around correctness issues. And so, all that my strategy is really advocating for is to make performance fail loudly in the same way that most exceptions do. [chuckles] Once you get to that point, I think a lot of teams have processes around prioritization for bugs versus features and all that. And just getting performance into that conversation at least tends to make that solve itself.

+ +

STEPH: I'm curious, as you're joining teams and helping them with their performance issues, are there particular buckets or categories of performance issues that are the most common in terms of, let's say, 50% of issues are SQL-related N+1 issues? What tends to be the breakdown that you see?

+ +

NATE: So, when it comes to why something is slow in a Ruby application, I teach a method that I call DRM. And that doesn't have anything to do with actual DRM. It's just memorable because it reminds me of things I don't like. DRM stands for Database Ruby and Memory and in that order. So the most common issue is database, the second most common issue is issues with your Ruby code. The least common issue is memory. Specifically, I'm talking about allocation of objects, creating lots of objects. So probably 80% of your issues are in some way database-related. In Rails, it's 50% of those are probably N+1. And then 30% of database issues are probably what I would call unnecessary SQL. So it's not necessarily N+1, but it's a SQL query for information that you already had, or you could do in a more efficient way. So a common thing for unnecessary SQL would be people will filter an ActiveRecord::Collection like ten different ways when they could have just loaded the whole collection, filtered it with Ruby in the ten different ways afterwards, and that works really well if the collection that you're loading is like 10, 20. Turning that into one database query, plus a bunch of calls to innumerable methods is often way faster than doing that as ten separate database queries. Also, that tends to be a more robust approach. This doesn't happen in most companies, but what could happen is the database is like a shared resource. It's a resource that everybody is affected by. So a performance degradation to the database is the worst possible scenario because everything is affected. But if you screw up what's happening at an individual Rails process, then only that Rails process is affected. The blast radius is tiny. It's just that one request. So doing less stuff in the database while it can actually seem like, oh, that doesn't feel right. I'm supposed to do a lot of stuff in the database. It actually can reduce blast radiuses of performance issues because you're not doing it on this database that everyone has to have access to. There are a lot of areas of gray here. And I talk a lot in all my other material like why -- There's a lot of nuance here.

+ +

So database is the main stuff. Issues in how you write your Ruby code is probably the other one. Usually, that's just what I would call code that goes bump in the night. It's code that you don't know is running but actually is. Profilers are what help us figure that out. So oftentimes, I'll have someone open up a profiler on their controller action for the first time. And they're like, wait a minute, I had no idea that such and such was running during this controller action, and actually, we don't need to do that at all. So why is it here? So that's the second most common issue. And then the third issue that really doesn't actually come up all that often is object allocation, numbers of objects that get created. So primarily, this is a problem in index actions or actions transactions that deal with big collections. So in Ruby, we often get overly focused on garbage collection, but garbage collection doesn't take any time if you just don't create objects. And object creation itself takes time. So looking at code through the lens of what object does this code create? And trying to get rid of those object allocations can often be a pretty productive way to make stuff faster.

+ +

STEPH: You said a lot of amazing things there. So I'm debating on which one to follow up on. I think the one that stuck out to me the most where I have felt pain around this is you mentioned identifying code that goes bump in the night or code that is running, but it doesn't need to be run. And that is something that I've run into with applications where we have a code path that seems important, but yet I can't prove that it's being executed and exactly why it's there and what flow it's supporting. And I'm curious, do you have any tips or tricks in how you’ve helped teams identify that this code path isn't used and it's something that we can remove and then that itself will help speed up the performance of that particular endpoint?

+ +

NATE: Like, there's no performance cost to like 100 models in an application that never actually get used. There's really no performance downside to code in an app that doesn't actually ever get run. But instead, what happens is code gets added into callbacks that usually is probably the biggest offender that’s like, always do this thing after you do X. But then, two years later, you don't always need to do that thing after you do X. So the callbacks always run, but sometimes requirements change, and they don't always need to be run. So usually, it's enough to just pop the profiler now on something. And I have people look at it, and they're like, “I don't know why any of this is happening.” Like, it's usually a pretty big Eureka moment once we look at a flame graph for the first time and people understand how to read those, and they understand what they're looking at. But sometimes there's a bit of a process where especially in a bigger app where it's like, “Such and such is running, and this was an entire other team that's working on this. I have no idea what this even does.” So on bigger apps, there's going to be more learning that has to get done there. You have to learn about other parts of the application that maybe you've never learned about before. But profiling helps us to not only see what code is running but also what that relative importance is. Like, okay, maybe this one callback runs, and you don't know what it does, and it's probably unnecessary. But if it only takes 1% of the total time to run this action, that's probably less important than something that takes 20% of total time. And so profilers help us to not only just see all the code that's being run but also to know where that time goes and what time corresponds to what parts of the code.

+ +

STEPH: Yeah, that's often the code that makes me the most nervous is where it's code that I suspect is being run or maybe being run, but I don't understand why it's there and then figuring out if it can be removed and then figuring out ways to perhaps even log when a call is being made to that code to determine if it's truly in use or not or at least supported by a code path that a user is hitting. You have a blog post that I read recently that I really appreciated that talks about essentially gaming benchmarking where you talk about the importance of having context around benchmarks. So if someone says, “I've improved something where it is now 10% faster.” It's like, well, what is that 10% relative to? And if it's a tool that other people are using, what does that mean for them? Or did you improve something that was already very fast, and you made it 10% faster? Was that a really valuable use of your time?

+ +

NATE: Yeah. You know, something that I read recently that made me think of that again was this Hacker News post that went viral. That was like, how I optimize an AWS EC2 instance to take 1.5 million requests per second on my JSON API. And out of the box, it was like 500 requests per second, and then he got it to 1.5 million. And the whole article was presented with relative numbers. So it was like, “I made this change, and things got 33% faster. And if you do the whole thing right, 500 to 1.5 million requests per second, it's like my app is three times faster now,” or whatever. And that's true, but it would probably be more accurate to say, “I've taken three-millionth of a second out of every request in my app.” That's two ways of saying the same thing because latency and throughput are just related that way. But it's probably more accurate and more useful to say the absolute number, but it doesn't make for great blog posts, so that doesn't tend to get said. The kinds of improvements that were discussed in this article were really, really low-level stuff. That was like if you turn off...I think it was like turn off iptables or something like that. And it's like, that shaves a microsecond off of every time we make a syscall or something. And that is useful if your performance goal is to serve 1.5 million requests per second Hello World responses off of my EC2 instance, which is what this person admittedly was doing. But there's a tendency to walk that back to if I do all things in this article, my application will be three times faster. And that's just not what the evidence says. It's not what you were told. So there's just a tendency to use relative numbers when absolute numbers would be more useful to giving you the context of like, oh, well, this will improve my app or it won't. We get this a lot in Puma. We get benchmarks that are like, hey, this thing is going to help us to do 50,000 requests per second in Puma instead of 10,000. And another way of saying that is you took a couple of nanoseconds off of the overhead of every single request to Puma. And most Puma applications have a hundred millisecond response time. So it's like, yeah, I guess it's cool that you took a nanosecond off, and I’m sure it's going to help us have cool benchmarks, but none of our users are going to care. No one that's used Puma is going to care that their requests are one nanosecond faster now. So what did we really gain here?

+ +

STEPH: Yeah, it makes sense that people would want to share those more...I want to call them sparkly stats and something that catches your attention, but they're not necessarily something that's going to translate to us in the way that we hoped that they will in terms of it's not going to speed up our app 30% or have those same rewards or benefits. Speaking of Puma, how is it being a co-maintainer of Puma? And how do you balance that role with all of your other work?

+ +

NATE: Actually, it doesn't take all that much of my time. I try to spend about 15 minutes a day on it. And that's really possible because of the philosophy I have around open-source maintenance. I think that open source projects are fundamentally about collaboration and about sharing our hard-fought extractions and fixes and knowledge together. And it's not about a single super contributor or super maintainer who is just out of the goodness of their heart releasing all of their incredible work and time into the public domain or into a free software license. Puma is a pretty popular piece of Ruby software, so a lot of people use it. And I have things on my back burner of if I ever got 20 hours to work on Puma, here’s stuff I would do. But there are a lot of other people that have more time than me to work on Puma. And they're just as smart, and they have other tools they've got in their locker that I don't have. And I realized that it was more important that I actually find ways to recruit and then unblock those people than it was for me to devote as much time as I could to Puma. And so my work on Puma now is really just more like management than anything else. It's more trying to recruit new contributors and trying to give them what they need to help Puma. And contributing to open source is a really fraught experience for a lot of people, especially their first time. And I think we should also be really conscious of that. Like, 95% of software developers have really never contributed to open source in a meaningful way. And that's a huge talent pool of people that could be helping us that aren't. So I'm less concerned about the problems of the 5% that are currently contributing than I am about why there are 95% of us that don't do anything. So that's what gets me excited to work on Puma now, is trying to change that ratio.

+ +

STEPH: I really like that mindset of where you are there to provide guidance but then essentially help unblock others as they're making contributions to the project but then still be there to have the history and full context and also provide a path forward of a good direction for Puma to head. In regards to encouraging more people to contribute to open source projects, I've often heard people say how challenging that is, where they have an open-source project that they would really love people to contribute to but finding people is really hard or just letting people know that they're interested in contributions. Have you had any strategies that have been successful for you in encouraging people to contribute?

+ +

NATE: Yeah. So first thing, the easiest thing is we have a contributing.md file. So that's something I think more projects should adopt is have an actual file in your project that says everything about how to contribute. Like, what kinds of contributions do you want? Different projects have different things that they want. Like, Rails doesn't want to refactor PRs. Don't send a refactor PR to Rails because they'll reject it. Puma, I'm happy to accept those. So letting people know like, “Hey, here's how we work here. Here's the community we're creating, and here's how it works. Here's how to get involved.” And I think of it as hanging out the shingle and saying, “Yes, I want your contributions. Here's how to do it.” That alone puts you a step above other projects.

+ +

The second thing I would say is you need to have contributor-only communication channels. So we have Matrix chat. So Matrix is like this successor to IRC. So we have a chat channel basically, but it's like contributors only. I don't enforce that, but I just don't want support requests in there. I don't want people coming in there and being like, “My Puma config doesn't work.” And instead, it's just for people that want to contribute to Puma, and that want to help out. If you have a question and come in there, anyone can answer it.

+ +

And then finally, another thing that I've had success with is doing one-on-one stuff. So I will actually...I have a Calendly invite that I think is in contributing.md now that you can just book 30 minutes with me anytime about contributing to Puma. And I will get on a Zoom call with you and talk to you about what are your concerns? Where do I think you can help? And I give my time away that way. The way I see it is like if I do that 20 times and I create one super contributor to Puma, that is worth more than me spending 10 hours on Puma because that person can contribute 100, 200, 1,000 hours over their lifetime of contributing to Puma. So that's actually a much more higher leverage contribution, really from my perspective. It's actually helping other people contribute more.

+ +

STEPH: Yeah, that's huge to offer people to say, “Hey, you can book time with me, and I will walk you through and let you know where you can start making an impactful contribution right away,” or “Here are some areas that I think you'd be interested, to begin with.” That seems like such a nice onboarding for someone who says, “I'm interested, but I'm nervous,” or “I'm just not sure about where to get started.” Also, I love your complaint department voice for the person who their Puma config doesn't work. That was delightful. [chuckles]

+ +

NATE: I think it's a little bit part of my open-source philosophy that, especially at a certain scale like Puma is at that we really kind of over-prioritize users. And I'm not really here to do support; I'm here to make the project better. And users don't actually contribute to open source projects. Users use the thing, and that's great. That's the whole reason we're open-sourcing is so more people use it. But it's important not to prioritize that over people who want to make the project better. And I think a lot of times; people get caught up in this almost clout chasing of getting the most GitHub stars that they think they need and users they think they need. And you don't get paid for having users, and the product doesn't get any better either. So I don't prioritize users. I prioritize the quality of the project and getting contributors. And that will create a better project, which will then create more users. So I think it's easy to get sidetracked by people that ask for your time when they're not giving anything back to the project in return. And especially at Puma’s scale, we have enough people that want my time or the time of other maintainers at Puma so that they can contribute to the project. And putting user support requests ahead of that is not good for the project. It's not the biggest, long-term value increase we could be making, so I don't prioritize them anymore.

+ +

STEPH: Yep. That sounds like more the pursuit of sparkly stats and looking for all those GitHub stars or all of those likes. Well, Nate, if you're game, I have two listener questions that I'd like to run by you because I shared with some folks that you are going to be on The Bike Shed today. And they're very excited and have two questions that they'd like me to run by you. How does that sound?

+ +

NATE: Yeah, all right.

+ +

STEPH: So the first question is, are there any paradigms or trends in Rails that inherently hurt performance?

+ +

NATE: Yeah. I get this question a lot, and I will preface it with saying that I'm the performance guy, and I'm not the software design guy. And I get a lot of questions about does such and such software design...how does that impact performance? And usually, there's like a way to do anything in a performant way. And I'm just here to help people to find the performant way and not to prescribe “You must always do X, Y, or Z,” or “ActiveRecord is bad. Never use it.” That's not my job here. And in my experience, there's a fast way to do almost anything.

+ +

Now, one thing that I think is dying, I guess, or one approach or one common...I don't know what to call it. One common mistake that is clearly wrong is to not do any form of server-side rendering in a web application. So I am anti-client-side app. But there are ways to do that and to do it quickly. But rendering a basically blank document, which is what most of these applications will do when they're using Rails as a back-end…you'll serve this basically blank document or a document with maybe some Chrome in it. And then, the client-side app has to execute, compile JavaScript, make XHR requests, and then render the page. That is just by definition slower than serving somebody a server-side rendered page. Now, I am 100% agnostic on how you want to generate that server-side rendering. There are some people that are working on better ways to do that with Rails and client-side apps. Or you could just go the Hotwire Turbolinks way. And it's more progressive enhancement where the back-end is always just serving the server-side rendered response. And then you do some JavaScript on top of that.

+ +

So I think five years from now, nobody will be doing this approach of serving blank documents and then booting client-side apps into that. Or at least it will be seen as outdated enough that you should never design a project that way anymore. It's one of those few things where it's like, yeah, just by definition, you're adding more steps into a rendering flow. That means, by necessity, it has to be slower. So I think everybody should be thinking about server-side rendering in their project. Again, I’m totally agnostic on how you want to implement that. With React, whatever front-end flavor of the month you want to go with, there's plenty of ways to do that, but I just think you have to be prioritizing that now.

+ +

STEPH: All right. Well, I like that five-year projection of where we're headed. I have found that it's often the admin-side where people will still bring in a lot of JavaScript rendering, just to touch on a bit of what you're saying, in terms of let's favor the server-rendered HTML versus over-optimizing a space that one, probably isn't a profitable space in terms that we do want our admins to have a great experience for our product. But if they are not necessarily our users, then it also doesn't need to be anything that is over the top or fancy or probably uses a lot of JavaScript. And instead, we can start simple. And there's a number of times that I've been on projects where we have often walked the admin back to be more server-rendered because we got to a point where someone was very excited to make the admin very splashy and quick but then couldn't keep up with the requests because then they were having to prioritize the user experience first. So it was almost like optimizing the admin, but then it got left out in the cold. So then it's just sort of this poor experience.

+ +

NATE: Yes. Shopify famously walked back their admin from I think it was Backbone to Turbolinks. And I think that that has now moved back to React is my understanding. But Shopify is a huge company, so they have plenty of time and resources to be able to do that. But I just remember that happening at the time where I was like, oh wow, they just rolled the whole thing back to Turbolinks again. And now, with the consolidation that's gone on in the React world, it's a little bit easier to pipe a server-side rendering into a React app. Whereas with Backbone, it was like no one knew what you were doing. So there was less knowledge about how to server-side render this stuff. Now it doesn't seem to be so much of a problem. But yeah, I mean, Rails is really good at CRUD apps, and admin is like 99% CRUD. And adhering as closely as possible to the Rails Golden Path there in an admin seems to be the most productive way to work on that kind of feature.

+ +

STEPH: All right. Ready for your second question?

+ +

NATE: Yes.

+ +

STEPH: Okay. This one's a bit more in-depth. They also mentioned a particular project name. So I am going to swap it out with a different name. So on project cinnamon roll, we found a really gnarly time-consuming API endpoint that's getting hammered. And on a first pass, we addressed a couple of N+1 issues and tuned the performance, and felt pretty confident that they had addressed the issue. But it was still fairly slow. So then they took some additional incremental steps. So they swapped out to use OJ for serialization that shaved off an additional 10% but was still slow. They also went the route of going straight to Rails cache with a one-minute expiration. So that way, they could avoid mucking with cache busting because they confirmed with the client that data could be slightly stale. And this was great. It worked out well. So it dropped their average response time down to less than 70 milliseconds. With all that said, that journey took a few hours over a few days, and multiple production deploys. And had they gone straight to the cache, then they would have had a 15-minute fix with a single deploy. So this person's wondering, are there any other examples like that where, rather than taking these incremental seemingly obvious performance whims, there are situations where you want to be much more direct with your path?

+ +

NATE: I guess I'd say that profiling can help you to understand and form better hypotheses about what will make things faster and what won't. Because a profiler can't really lie to you about where time goes, either you spent 20% of your time in this method, or you didn't. So I don't spend any time in any of my material talking about what JSON serializer you use. Because really that's actually never...that's really never anybody's bottleneck. It's never a huge proportion of people's total percentage of time. And I know that because I've looked at enough profiles that the issues are usually in other places. So I would say that if your hypotheses that you're generating are not working, it's because you're not generating good enough hypotheses. And profiling is the place to do that. So having profilers running in production is probably the biggest level-upscale-like that most teams could take. So having profilers that you can access as on production servers as a user is probably the biggest level up that you could make to generating the hypotheses because that'll have real production data, real production servers, real production environment. And it's pretty common now that pretty much every team that I work with either has that already, or we work on implementing it. It's something that I've seen in production at GitHub and Shopify. You can do it yourself with rack-mini-profiler. It's all about setting up the authorization, just making sure that only authorized users get to see every single SQL query generated in the flame graph and all that. But other than that, there's no reason you shouldn't do it. So I would say that if you're not generating the right hypotheses or you don't...if the last hypothesis out of 10 is the one that works, you need better hypotheses, and the best way to do that is better profiling.

+ +

STEPH: Okay, better profiling. And yeah, it sounds like there's also a bit of experience in there in terms of things that you're used to seeing, that you've noticed that could be outliers in terms of that they're not necessarily the thing that you want to improve. Like you mentioned spending time on how you're serializing your JSON is not somewhere that you would look. But then there are other areas that you've gained experience that you know would be likely more beneficial to then focus on to form that hypothesis.

+ +

NATE: Yeah, that's a long way of saying experience pays off. I've had six years of doing this every single day. So I'm going to be pretty good at...that's what I get paid for. [laughs] So if I wasn't very good at that, I probably wouldn't be making any money at it.

+ +

STEPH: [laughs] All right. Well, thanks, Nate, so much for coming on the show today and talking so much about performance. On that note, I think it's a good place for us to wrap up. If people are interested in following along with what you're working on and they want to keep up with your latest and greatest workshops that are coming out, where can they find you on the internet?

+ +

NATE: speedshop.co is my site. @nateberkopec on Twitter. And speedshop.co has a link to my newsletter, which is where I'm actively thinking every week and publishing stuff too. So if you want to get the drip of news and thoughts, that's probably the best place to go.

+ +

STEPH: Perfect. All right. Well, thank you so much.

+ +

NATE: No problem.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

Together: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + Nate Berkopec is the author of the Complete Guide to Rails Performance, the creator of the Rails Performance Workshop, and the co-maintainer of Puma. He talks with Steph about being known as "The Rails Speed Guy," and how he ended up with that title, publishing content, working on workshops, and also contributing to open source projects. (You could say he's kind of a busy guy!)

+ + + +

Transcript:

+ +

STEPH: All right. I'll kick us off with our fancy intro. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I’m Steph Viccari. And this week, Chris is taking a break. But while he's away, I'm joined by Nate Berkopec, who is the owner of Speedshop, a Ruby on Rails performance consultancy. And, Nate, in addition to running a consultancy, you're the co-maintainer of Puma. You're also an author as you wrote a book called The Complete Guide to Rails Performance. And you run the workshop called The Rails Performance Workshop. So, Nate, I'm sensing a theme here.

+ +

NATE: Yeah, make code go fast.

+ +

STEPH: And you've been doing that for quite a while, haven't you?

+ +

NATE: Yeah. It's pretty much been since 2015, or so I think. It all started when I actually wrote a blog post about Turbolinks that got a lot of pick up. My hot take at the time was that Turbolinks is actually a good thing. That take has since become uncontroversial, but it was quite controversial in 2015. So I got a lot of pick up on that, and I realized I liked working on performance, and people seem to want to hear about it. So I've been in that groove ever since.

+ +

STEPH: When you started down the path of really focusing on performance, were you running your own consultancy at that point, or were you working for someone else?

+ +

NATE: I would say it didn't really kick off until I actually published The Complete Guide to Rails Performance. So after that came out, which was, I think, March of 2016…I hope I’m getting that right. It wasn't until after that point when it was like, oh, I'm the Rails performance guy now. And I started getting emails inbound about that. I didn't really have any time when I was actually working on the CGRP to do that sort of thing. I just made that my full-time job to actually write, and market, and publish that. So it wasn't until after that that I was like, oh, I'm a performance consultant now. This is the lane I've driven myself into. I don't think I really had that as a strategy when I was writing the book. I wasn't like, okay, this is what I'm going to do. I'm going to build some reputation around this, and then that'll help me be a better consultant with this. But that's what ended up happening.

+ +

STEPH: I see. So it sounds like it really started more as a passion and something that you wanted to share. And it has manifested to this point where you are the speed guy.

+ +

NATE: Yeah, I think you could say that. I think when I started writing about it, I just knew...I liked it. I liked the work of performance. In a lot of ways, performance is a much more concrete discipline than a lot of other sub-disciplines of programming where I joke my job is number go down. It's very measurable, and it's very clear when you've made a difference. You can say, “Hey, this number was this, and now it's this. Look what I did.” And I always loved that concreteness of performance work. It makes it actually a lot more like a real kind of engineering discipline where I think of performance engineering as clarifying requirements and the limitations and then building a project that meets the requirements while staying within those limitations and constraints. And that's often not quite as clear for other disciplines like general feature work. It's kind of hard to say sometimes, like, did you actually make the user's life better by implementing such and such? That's more of a guess. That's more of a less clear relationship. And with performance, nobody's going to wake up ten years from today and wish that their app was slower. So we can argue about the relative importance of performance in an application, but we don't really argue about whether or not we made it faster because we can prove that.

+ +

STEPH: Yeah. That's one area that working with different teams (as I tend to shift the clients that I'm working with every six months) where we often push hard around feature work to say, “How can we measure this? How can we know that we are delivering something valuable to users?” But as you said, that's really tricky. It's hard to evaluate. And then also, when you add on the fact that if I am leaving that project in six months, then I don't have the same insights to understand how something went for that team. So I can certainly appreciate the satisfaction that comes from knowing that, yes, you are delivering a faster app. And it's very measurable, given the time that you're there, whether it's a short time or if it's a long time that you're with that team.

+ +

NATE: Yeah, totally. My consulting engagements are often really short. I don't really do a lot of super long-term stuff, and that's usually fine because I can point to stuff and say, “Yep. This thing was at A, and now it's at B. And that's what you hired me to do, so now it's done.”

+ +

STEPH: I am curious; given that you have so many different facets where you are running your consultancy, you are also often publishing a lot of content and working on workshops and then also contributing to open source projects. What does a typical week look like for you?

+ +

NATE: Well, right now is actually a decent example. I have client work two or three days a week. And I'm actually working on a new product right now that I'm calling Sidekiq in Practice, which is a course/workshop about scaling Sidekiq from zero to 1000 jobs per second. And I'll spend the other days of the week working on that. My content is...I always struggle with how much time to spend on blogging specifically because it takes so much time for me to come up with a post and publish that. But the newsletter that I write, which I try to write two once a week, I haven't been doing so well with it lately. But I think I got 50 newsletters done in 2020 or something like that.

+ +

STEPH: Wow.

+ +

NATE: And so I do okay on the per-week basis. And it's all content I've never published anywhere else. So that actually is like 45 minutes of me sitting down on a Monday and being like rant, [chuckles] slam keyboard and rant and then hit send. And my open source work is mostly 15 minutes a day while I'm drinking morning coffee kind of stuff. So I try to spread myself around and do a lot of different stuff. And a lot of that means, I think, pulling back in terms of thinking how much you need to spend on something, especially with newsletters, email newsletters, it was very easy to overthink that and spend a lot of time revising and whatever. But some newsletter is better than no newsletter. And especially when it comes to content and marketing, I've learned that frequency and regularity is more important than each and every post is the greatest thing that's ever come out since sliced bread. So trying to build a discipline and a practice around doing that regularly is more important for me.

+ +

STEPH: I like that, some newsletter is better than no newsletter. I was listening to your chat with Brittany Martin on the Ruby on Rails podcast. And you said something very honest that I appreciated where you said, “Writing is really hard, and writing sucks.” And that made me laugh in the moment because even though I do enjoy writing, I still find it very hard to be disciplined, to sit down and make it happen. And then you go into that editor mode where you critique everything, and then you never really get it published because you are constantly fixing it. It sounds like...you've mentioned you set aside about 45 minutes on a Monday, and you crank out some work. How do you work through that inner critic? How do you get past it to the point where then you just publish?

+ +

NATE: You have to separate the steps. You have to not do editing and first drafting at the same time. And the reason why I say it sucks and it's hard is because I think a lot of people don't do a lot of regular writing, maybe get intimidated when they try to start. And they're like, “Wow, this is really hard. This is not fun.” And I'm just trying to say that's everybody's experience and if it doesn't get any better, because it doesn't, [chuckles] there's nothing wrong with you, that's just writing, it's hard. For me, especially with the newsletter, I just have to give myself permission not to edit and to just hit send when I'm done. I try to do some spell checking,, and that's it. I just let it go. I'm not going back and reading it through again and making sure that I was very clear and cogent in all my points and that there's a really good flow through that newsletter. I think it comes with a little bit of confidence in your own ideas and your own experience and knowledge, believing that that's worth sharing and that's worth somebody's time, even if it's not a perfect expression of what's in your head. Like, a 75% expression is good enough, especially in a newsletter format where it's like 500 to 700 words. And it's something that comes once a week. And maybe not everyone's amazing, but some of them are, enough of them are that people stay subscribed. So I think a combination of separating editing and first drafting and just having enough confidence and the basis where you have to say, “It doesn't have to be perfect every single time.”

+ +

STEPH: Yeah, I think that's something that I learned a while back to apply to my coding process where I had to separate those two steps of where I have to let the creator in me just create and write some code and make it work, and then come back to the editing process, and taking a similar approach with writing. As you may be familiar with thoughtbot, we're big advocates when it comes to sharing content and sharing things that we have learned throughout the week and different projects that we're working on. And often when people join thoughtbot, they're very excited to contribute to the blog. But it is daunting for that first post because you think it has to be this really grand novel. And it has to be something that is really going to appeal to everybody, and it's going to help everyone. And then over time, you learn it's like, oh well, actually it can be this very just small thing that I learned that maybe only helps 20 people, but it still helped those 20 people. And learning to publish more frequently versus going for those grand pieces is more favorable and often more helpful for people.

+ +

NATE: Yeah, totally. That's something that is difficult for people at first. But everything in my experience has led me to believe that frequency and regularity is just as, if not more important than the quality of any individual piece of content that I put out. So that's not to say that...I guess it's weird advice to give because people will take it too far the other way and think that means he's saying quality doesn't matter. No, of course, it does, but I think just everyone's internal biases are just way too tuned towards this thing must be perfect. I've also learned we're just really bad judges internally of what is useful and good for people. Stuff that I think is amazing and really interesting sometimes I'll put that out, and nobody cares. [chuckles] And the other stuff I put out that's just like the 45-minute banging out newsletter, people email me back and say, “This is the most helpful thing anyone’s ever read.” So that quality bias also assumes that you know what is good and actually we're not really good at that, knowing every time what our audience needs is actually really difficult.

+ +

STEPH: That's totally fair. And I have definitely run into that too, where I have something that I'm very proud of and excited to share, and I realize it relates to a very small group of people. But then there's something small that I do every day, and then I just happen to tweet about it or talk about it, and suddenly that's the thing that everybody's really excited about. So yeah, you never know. So share it all.

+ +

NATE: Yeah. And it's important to listen. I pay attention to what people get interested in from what I put out, and I will do more of that in the future.

+ +

STEPH: You mentioned earlier that you are working on another workshop focused on Sidekiq. What can you tell me about that?

+ +

NATE: So it's meant to be a guide to scaling Sidekiq from zero to 1000 requests per second. And it's meant to be a missing guide to all the things that happen, like the situations that can crop up operationally when you're working on an application that does a lot of work with Sidekiq. Whereas Mike Sidekiq, Wiki, or the docs are great about how do, you do this? What does this setting mean? And the basics of getting it just running, Sidekiq in practice, is meant to be the last half of that. How do you get it to run 1,000 jobs per second in a day-to-day application? So it's the collected wisdom and collected battle scars from five years of getting called in to fix people's Sidekiq installations and very much a product of what are the actual problems that people experience, and how do you fix and deal with those? So stuff about memory and managing Sidekiq memory usage, how to think about queues. Like, what should your queue structure be? How many should you have? Like, how do you organize jobs into queues, and how do you deal with problems like some client is dropping 10,000, 20,000 jobs into a queue. And now the other jobs I put in that queue have 20,000 jobs in front of them. And now this other job I've got will take three hours to get through that queue. How do you deal with problems like that? All the stuff that people have come to me over the years and that I've had to help them fix.

+ +

STEPH: That sounds really great. Because yeah, I find that teams who are often in this space with Sidekiq we just let it run until there's a fire. And then suddenly, we start to care as to how it's processing, and we care about our queue structure and how many workers that we have that are pulling from that queue. So that sounds really helpful. When you're building a workshop, do you often go back to any of those customers and pull more ideas from them, or do you find that you just have enough examples from your collective work with clients that that itself creates a course?

+ +

NATE: Usually, pretty much every chapter in the workshop I've probably implemented like three-plus times, so I don't really have to go back to any individual customer. I have had some interesting stuff with my current client, Gusto. And Gusto is going through some background job reorganization right now and actually started to implement a lot of the things that I'm advocating in the workshop actually without talking to me. It was a good validation of hey, we all actually think the same here. And a lot of the solutions that they were implementing were things that I was ready to put down into those workshops. So I'd like to see those solutions implemented and succeed. So I think a lot of the stuff in here has been pretty battle-tested.

+ +

STEPH: For the Rails Performance Workshop, you started off doing those live and in-person with teams, and then you have since switched to now it is a CLI course, correct?

+ +

NATE: That's correct. Yep.

+ +

STEPH: I love that very much. When you’ve talked about it, it does feel very appropriate in terms of developers and how we like to consume content and learn. So that is really novel and also, it seems like a really nice win for you. So then other people can take this course, but you are no longer the individual that has to deliver it to their team, that they can independently take the course and go through it on their own. Are you thinking about doing the same thing for the Sidekiq course, or what are your plans for that one?

+ +

NATE: Yeah, it's the exact same structure. So it's going to be delivered via the command line. Although I would say Sidekiq in practice has more text components. So it's going to be a combination of a very short manual or book, and some video, and some hands-on exercises. So, an equal blend between all three of those components. And it's a lot of stuff that I've learned over having to teach; I guess intermediate to advanced programming concepts for the last five years now that people learn at different paces. And one of the great things about this kind of format is you can pick it up, drop it off, and move at your own speed. Whereas a lot of times when I would do this in person, I think I would lose people halfway through because they would get stuck on something that I couldn't go back to because we only had four hours of the day. And if you deliver it in a class format, you're one person, and I've got 24 other people in this room. So it's infinitely pausable and replayable, and you can go back, or you can just skip ahead. If you've got a particular problem and you're like, hey, I just want to figure out how to fix such and such; you can do that. You can just come in and do a particular thing and then leave, and that's fine. So it's a good format that way. And I've definitely learned a lot from switching to pre-recorded and pre-prepared stuff rather than trying to do this all live in person.

+ +

STEPH: That is one of the lessons that I've learned as well from the couple of workshops that I've led is that doing them in person, there's a lot of energy. And I really enjoy that part where I get to see people respond to the content. And then I get a lot of great feedback from people about what type of questions they have, where they are getting stuck. And that part is so important to me that I always love doing them live first. But then you get to the point, as you'd mentioned, where if you have a room full of 20 people and you have two people that are stuck, how do you help them but then still keep the class going forward? And then, if you are trying to tailor this content for a wide audience…so maybe beginners could take the Rails Performance Workshop, or they could also take the Sidekiq course. But you also want the more senior engineers to get something out of it as well. It's a very challenging task to make that content scale for everyone.

+ +

NATE: Yeah. What you said there about getting feedback and learning was definitely something that I got out of doing the Rails Performance Workshop in person like three dozen times, was the ability to look over people's shoulders and see where they got stuck. Because people won't email me and say, “Hey, this thing is really confusing.” Or “It doesn't work the way you said it does for me.” But when I'm in the same room with them, I can look over their shoulder and be like, “Hey, you're stuck here.” People will not ask questions. And you can get past that in an in-person environment. Or there are even certain questions people will ask in person, but they won't take the time to sit down and email me about. So I definitely don't regret doing it in person for so long because I think I learned a lot about how to teach the material and what was important and how people...what were the problems that people would encounter and stuff like that. So that was useful. And definitely, the Rails Performance Workshop would not be in the place that it is today if I hadn't done that.

+ +

STEPH: Yeah, helping people feel comfortable asking questions is incredibly hard and something I've gone so far in the past where I've created an anonymous way for people to submit questions. So during class, even if you didn't want to ask a question in front of everybody, you could submit a question to this forum, and I would get notified. I could bring it up, and we could answer it together. And even taking that strategy, I found that people wouldn't ask questions. And I guess it circles back to that inner critic that we have that's also preventing us from sharing knowledge that we have with the world because we're always judging what we're going to share and what we're going to ask in front of our peers who we respect. So I can certainly relate to being able to look over someone's shoulder and say, “Hey, I think you're stuck. We should talk. Let me walk you through this or help you out.”

+ +

NATE: There are also weird dynamics around in-person, not necessarily in a small group setting. But I think one thing I really picked up on and learned from RailsConf2021 which was done online, was that in-person question asking requires a certain amount of confidence and bravado that you're not...People are worried about looking stupid, and they won't ask things in a public or semi-public setting that they think might make them look dumb. And so then the people that do end up asking questions are sometimes overconfident. They don't even ask a question. They just want to show off how smart they are about a particular issue. This is more of an issue at conferences. But the quality of questions that I got in the Q&A after RailsConf this year (They did it as Discord chats.) was way better. The quality of questions and discussion after my RailsConf talk was miles better than I've ever had at a conference before. Like, not even close. So I think experimenting with different formats around interaction is really good and interesting. Because it's clear there's no perfect format for everybody and experimenting with these different settings and different methods of delivery has been very useful to me.

+ +

STEPH: Yeah, that makes a ton of sense. And I'm really glad then for those opportunities where we're discovering that certain forums will help us get more feedback and questions from people because then we can incorporate that and to future conferences where people can speak up and ask questions, and not necessarily be the one that's very confident and enjoys hearing their own voice. For the Rails Performance Workshop, what are some of the general things that you dive into for that workshop? I'm curious, what is it like to attend that workshop? Although I guess one can't attend it anymore. But what is it like to take that workshop?

+ +

NATE: Well, you still can attend it in some sense because I do corporate bookings for it. So if you want to buy 20 seats, then I can come in and basically do a Q&A every week while everybody takes the workshop. Anyway, I still do that. I have one coming up in July, actually. But my overall approach to performance is to always start with monitoring. So the course starts with goals and monitoring and understanding where you want to go and where you are when it comes to performance. So the first module of the Rails Performance Workshop is actually really a group exercise that's about what are our performance requirements and how can we set those? Both high-level and low-levels. So what is our goal for page load time? How are we going to measure that? How are we going to use that to back into lower-level metrics? What is our goal for back-end response times? What is our goal for JavaScript bundle sizes? That all flows from a higher-level metric of how fast you want the page to load or how fast you want a route to change in a React app or something, and it talks about those goals. And then where should you even start with where those numbers should be? And then how are you going to measure it? What are the browser events that matter here? What tools are available to help you to get that data? Because without measurement, you don't really have a performance practice. You just have people guessing at what stuff is faster and what is not. And I teach performance as a scientific process as science and engineering. And so, in the scientific method, we have hypotheses. We test those hypotheses, and then we learn based on those tests of our hypotheses. So that requires us to A, have a hypothesis, so like, I think that doing X makes this faster. And I talk about how you generate hypotheses using profiling, using tools that will show you where all the time goes when you do this particular operation of your software—and then measuring what happens when you do that? And that's benchmarking. So if you think that getting rid of method X or changing method X will speed up the app, benchmarking tells you did you actually speed it up or not? And there are all sorts of little finer points to making sure that that hypothesis and that experiment is tested in a valid way.

+ +

I spend a lot of time in the workshop yapping about the differences between development/local environments and production environments and which ones matter. Because what differences matter, it's not often the ones that we think about, but instead it's differences like actually in Rails apps the asset packaging and asset pipeline performs very differently in production than it does in development, works very differently. And it makes it one of the primary reasons development is slower than production, so making sure that we understand how to change those settings to more production-like settings. I talk a lot about data. It’s the other primary difference between development and production is production has a million users, and development has 10. So when you call things like User.all, that behavior is very different in production than it is locally. So having decent production-like data is another big one that I like to harp on in the workshops. So it's a process in the workshop of you just go lesson by lesson. And it's a lot of video followed up by hands-on exercises that half of them are pre-baked problems where I'm like, hey, take a look at this Turbolinks app that I've given you and look at it in DevTools. And here's what you should see. And then the other half is like, go work on your application. And here are some pull requests I think you should probably go try on your app. So it's a combination of hands-on and videos of the actual experience going through it.

+ +

STEPH: I love how you start with a smaller application that everyone can look at and then start to learn how performant is this particular application that I'm looking at? Versus trying to assess, let’s say, their own application where there may be a number of other variables that they have to consider. That sounds really nice. You'd mentioned one of the first exercises is talking about setting some of those goals and perhaps some of those benchmarks that you want to meet in terms of how fast should this page load, or how quickly should a response from the API be? Do you have a certain set of numbers for those benchmarks, or is it something that is different for each product?

+ +

NATE: Well, to some extent, Google has suddenly given us numbers to work with. So as of this month, I think, June 2021, Google has started to use what they're calling Core Web Vitals in their ranking of search results. They've always tried to say it's not a huge ranking factor, et cetera, et cetera, but it does exist. It is being used. And that data is based on Chrome user telemetry. So every time you go to a website in Chrome, it measures three metrics and sends those back to Google. And those three metrics are Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). And First Input Delay and Cumulative Layout shift are more important for your single-page apps kind of stuff. It's hard to screw those up with a Golden Path Rails app that just does Turbolinks or Hotwire or whatever. But Largest Contentful Paint is an easy one to screw up. So Google's line in the sand that they've drawn is 2.5 seconds for Largest Contentful Paint. So that's saying that from clicking on your website in a Google search result, it should take 2.5 seconds for the page to paint the largest component of that new page. That's often an image or a video or a large H1 tag or something like that. And that process then will help you to...to get to 2.5 seconds in Largest Contentful Paint; there are things that have to happen along the way. We have to download and execute all JavaScript. We have to download CSS. We have to send and receive back-end responses. In the case of a simple Hotwire app, it's one back-end response. But in the case of a single-page app, you got to download the document and then maybe download several XHR fetches or whatever. So there's a chain of events that has to happen there. And you have to walk that back now from 2.5 seconds in Largest Contentful Paint. So that's the line that I'm seeing getting drawn in the sand right now with Google's Core Web Vitals. So pretty much any meaningful web application performance metric can be walked back from that.

+ +

STEPH: Okay. That's super helpful. I wasn't aware of the Core Web Vitals and that particular stat that Google is using to then rank the sites. I was going to ask, this kind of blends in nicely into when do you start caring about performance? So if you have a new application that you are just starting to get to market, based on the fact that Google is going to start ranking you right away, you do have to care some right out of the gate. But I am curious, when do you start caring more about performance, and are there certain tools and benchmarking that you want to have in place from day one versus other things that you'll say, “Well, we can wait until we have X numbers of users or other conditions before we add more profiling?”

+ +

NATE: I'd say as an approach, I teach people not to have a performance strategy of monitoring. So if your strategy is to have dashboards and look at them regularly, you're going to lose. Eventually, you're not going to look at that dashboard, or more often, you just don't understand what you're looking at. You just install New Relic or Datadog or whatever, and you don't know how to turn a dashboard into actual action. Also, it seems to just wear teams out, and there's no clear mechanism when you just have a dashboard of turning that into oh, well, this has to now be something that somebody on our team has to go work on. Contrast that with bugs, so teams usually have very defined processes around bugs. So usually, what happens is you'll get an Exception Notification through Sentry or Bugsnag or whatever your preferred Exception Notification service is. That gets read by a developer. And then you turn that into a Jira ticket or a Kanban board or whatever. And then that is where work is done and prioritized. Contrast that with performance; there’s often no clear mechanism for turning metrics into stuff that people actually work on. So understanding at your organization how that's going to work and setting up a process that automatically will turn performance issues into actual work that people get done is important.

+ +

The way that I generally teach people to do this is to focus instead of dashboards and monitoring, on alerts, on automated thresholds that get tripped and then sends somebody's an email or put something in the Kanban board or whatever. It just has to be something that automatically gets fired. Different tools have different ways of doing this. Datadog has pretty much built their entire product around monitoring and what they call monitors. That's a perfectly fine way to do it, whatever your chosen performance monitoring tool, which I would say is a required thing. I don't think there's really any good excuse in 2021 for not having a performance monitoring tool. There are a million different ways to slice it. You can do it yourself with OpenTelemetry and then like statsD, I don't know, or pay someone else like everyone else does for Datadog or New Relic or AppSignal or whatever. But you got to have one installed. And then I would say you have to have some sort of automated alerting. Now that alerting means that you've also decided on thresholds. And that's the hard work that doesn't get done when your strategy is just monitoring. So it's very easy to just install a dashboard and say, “Hey, I have this average page time load dashboard. That means I'm paying attention to performance.” But if you don't have a clear answer to what number is good and what number is bad, then that dashboard cannot be turned into real action. So that's why I push monitoring so hard is because it allows people to ignore performance is all that matters, and it forces you to make the decision upfront as to what number matters. So that is what I would say, install some kind of performance monitoring. I don't really care what kind.

+ +

Nowadays, I also think there's probably no excuse to not have Real User Monitoring. So there's enough GDPR compliance Real User Monitoring now that I think everyone should be using it. So for industry terms, Real User Monitoring is just performance monitoring in the browser. So it's just users’ browser APIs and sends those back to you or your third-party provider, so having that so you actually are collecting back-end and front-end performance metrics. And then making decisions around what is bad and what is good. Probably everybody should just start with a page load time monitor, Largest Contentful Paint monitor. And if you've got a single-page app, probably hooking up some stuff around route changes or whatever your app...because you don't actually have page loads on every single time you navigate. You have to instrument whatever those interactions are. So having those up and then just drawing some lines that say, “Hey, we want our React route changes to always be one second or less.” So I will set an alert that if the 95th percentile is one second or more, I'm going to get alerted. There's a lot of different ways to do that, and everybody will have different needs there. But having a handful of automated monitors is probably a place to start.

+ +

STEPH: I like how you also focus on once you have decided those thresholds and have that monitoring in place, but then how do you make it actionable? Because I have certainly been part of teams where we get those alerts, but we don't necessarily...what you just mentioned, prioritize that work to get done until we have perhaps a user complaint about it. Or we start actually having pages that are timing out and not loading, and then they get bumped up in the priority queue. So I really like that idea that if we agree upon those thresholds and then we get alerted, we treat that alert as if it is a user that is letting us know that a page is too slow and that they are unable to use our application, so then we can prioritize that work.

+ +

NATE: And it's not all that dissimilar to bugs, really. And I think most teams have processes around correctness issues. And so, all that my strategy is really advocating for is to make performance fail loudly in the same way that most exceptions do. [chuckles] Once you get to that point, I think a lot of teams have processes around prioritization for bugs versus features and all that. And just getting performance into that conversation at least tends to make that solve itself.

+ +

STEPH: I'm curious, as you're joining teams and helping them with their performance issues, are there particular buckets or categories of performance issues that are the most common in terms of, let's say, 50% of issues are SQL-related N+1 issues? What tends to be the breakdown that you see?

+ +

NATE: So, when it comes to why something is slow in a Ruby application, I teach a method that I call DRM. And that doesn't have anything to do with actual DRM. It's just memorable because it reminds me of things I don't like. DRM stands for Database Ruby and Memory and in that order. So the most common issue is database, the second most common issue is issues with your Ruby code. The least common issue is memory. Specifically, I'm talking about allocation of objects, creating lots of objects. So probably 80% of your issues are in some way database-related. In Rails, it's 50% of those are probably N+1. And then 30% of database issues are probably what I would call unnecessary SQL. So it's not necessarily N+1, but it's a SQL query for information that you already had, or you could do in a more efficient way. So a common thing for unnecessary SQL would be people will filter an ActiveRecord::Collection like ten different ways when they could have just loaded the whole collection, filtered it with Ruby in the ten different ways afterwards, and that works really well if the collection that you're loading is like 10, 20. Turning that into one database query, plus a bunch of calls to innumerable methods is often way faster than doing that as ten separate database queries. Also, that tends to be a more robust approach. This doesn't happen in most companies, but what could happen is the database is like a shared resource. It's a resource that everybody is affected by. So a performance degradation to the database is the worst possible scenario because everything is affected. But if you screw up what's happening at an individual Rails process, then only that Rails process is affected. The blast radius is tiny. It's just that one request. So doing less stuff in the database while it can actually seem like, oh, that doesn't feel right. I'm supposed to do a lot of stuff in the database. It actually can reduce blast radiuses of performance issues because you're not doing it on this database that everyone has to have access to. There are a lot of areas of gray here. And I talk a lot in all my other material like why -- There's a lot of nuance here.

+ +

So database is the main stuff. Issues in how you write your Ruby code is probably the other one. Usually, that's just what I would call code that goes bump in the night. It's code that you don't know is running but actually is. Profilers are what help us figure that out. So oftentimes, I'll have someone open up a profiler on their controller action for the first time. And they're like, wait a minute, I had no idea that such and such was running during this controller action, and actually, we don't need to do that at all. So why is it here? So that's the second most common issue. And then the third issue that really doesn't actually come up all that often is object allocation, numbers of objects that get created. So primarily, this is a problem in index actions or actions transactions that deal with big collections. So in Ruby, we often get overly focused on garbage collection, but garbage collection doesn't take any time if you just don't create objects. And object creation itself takes time. So looking at code through the lens of what object does this code create? And trying to get rid of those object allocations can often be a pretty productive way to make stuff faster.

+ +

STEPH: You said a lot of amazing things there. So I'm debating on which one to follow up on. I think the one that stuck out to me the most where I have felt pain around this is you mentioned identifying code that goes bump in the night or code that is running, but it doesn't need to be run. And that is something that I've run into with applications where we have a code path that seems important, but yet I can't prove that it's being executed and exactly why it's there and what flow it's supporting. And I'm curious, do you have any tips or tricks in how you’ve helped teams identify that this code path isn't used and it's something that we can remove and then that itself will help speed up the performance of that particular endpoint?

+ +

NATE: Like, there's no performance cost to like 100 models in an application that never actually get used. There's really no performance downside to code in an app that doesn't actually ever get run. But instead, what happens is code gets added into callbacks that usually is probably the biggest offender that’s like, always do this thing after you do X. But then, two years later, you don't always need to do that thing after you do X. So the callbacks always run, but sometimes requirements change, and they don't always need to be run. So usually, it's enough to just pop the profiler now on something. And I have people look at it, and they're like, “I don't know why any of this is happening.” Like, it's usually a pretty big Eureka moment once we look at a flame graph for the first time and people understand how to read those, and they understand what they're looking at. But sometimes there's a bit of a process where especially in a bigger app where it's like, “Such and such is running, and this was an entire other team that's working on this. I have no idea what this even does.” So on bigger apps, there's going to be more learning that has to get done there. You have to learn about other parts of the application that maybe you've never learned about before. But profiling helps us to not only see what code is running but also what that relative importance is. Like, okay, maybe this one callback runs, and you don't know what it does, and it's probably unnecessary. But if it only takes 1% of the total time to run this action, that's probably less important than something that takes 20% of total time. And so profilers help us to not only just see all the code that's being run but also to know where that time goes and what time corresponds to what parts of the code.

+ +

STEPH: Yeah, that's often the code that makes me the most nervous is where it's code that I suspect is being run or maybe being run, but I don't understand why it's there and then figuring out if it can be removed and then figuring out ways to perhaps even log when a call is being made to that code to determine if it's truly in use or not or at least supported by a code path that a user is hitting. You have a blog post that I read recently that I really appreciated that talks about essentially gaming benchmarking where you talk about the importance of having context around benchmarks. So if someone says, “I've improved something where it is now 10% faster.” It's like, well, what is that 10% relative to? And if it's a tool that other people are using, what does that mean for them? Or did you improve something that was already very fast, and you made it 10% faster? Was that a really valuable use of your time?

+ +

NATE: Yeah. You know, something that I read recently that made me think of that again was this Hacker News post that went viral. That was like, how I optimize an AWS EC2 instance to take 1.5 million requests per second on my JSON API. And out of the box, it was like 500 requests per second, and then he got it to 1.5 million. And the whole article was presented with relative numbers. So it was like, “I made this change, and things got 33% faster. And if you do the whole thing right, 500 to 1.5 million requests per second, it's like my app is three times faster now,” or whatever. And that's true, but it would probably be more accurate to say, “I've taken three-millionth of a second out of every request in my app.” That's two ways of saying the same thing because latency and throughput are just related that way. But it's probably more accurate and more useful to say the absolute number, but it doesn't make for great blog posts, so that doesn't tend to get said. The kinds of improvements that were discussed in this article were really, really low-level stuff. That was like if you turn off...I think it was like turn off iptables or something like that. And it's like, that shaves a microsecond off of every time we make a syscall or something. And that is useful if your performance goal is to serve 1.5 million requests per second Hello World responses off of my EC2 instance, which is what this person admittedly was doing. But there's a tendency to walk that back to if I do all things in this article, my application will be three times faster. And that's just not what the evidence says. It's not what you were told. So there's just a tendency to use relative numbers when absolute numbers would be more useful to giving you the context of like, oh, well, this will improve my app or it won't. We get this a lot in Puma. We get benchmarks that are like, hey, this thing is going to help us to do 50,000 requests per second in Puma instead of 10,000. And another way of saying that is you took a couple of nanoseconds off of the overhead of every single request to Puma. And most Puma applications have a hundred millisecond response time. So it's like, yeah, I guess it's cool that you took a nanosecond off, and I’m sure it's going to help us have cool benchmarks, but none of our users are going to care. No one that's used Puma is going to care that their requests are one nanosecond faster now. So what did we really gain here?

+ +

STEPH: Yeah, it makes sense that people would want to share those more...I want to call them sparkly stats and something that catches your attention, but they're not necessarily something that's going to translate to us in the way that we hoped that they will in terms of it's not going to speed up our app 30% or have those same rewards or benefits. Speaking of Puma, how is it being a co-maintainer of Puma? And how do you balance that role with all of your other work?

+ +

NATE: Actually, it doesn't take all that much of my time. I try to spend about 15 minutes a day on it. And that's really possible because of the philosophy I have around open-source maintenance. I think that open source projects are fundamentally about collaboration and about sharing our hard-fought extractions and fixes and knowledge together. And it's not about a single super contributor or super maintainer who is just out of the goodness of their heart releasing all of their incredible work and time into the public domain or into a free software license. Puma is a pretty popular piece of Ruby software, so a lot of people use it. And I have things on my back burner of if I ever got 20 hours to work on Puma, here’s stuff I would do. But there are a lot of other people that have more time than me to work on Puma. And they're just as smart, and they have other tools they've got in their locker that I don't have. And I realized that it was more important that I actually find ways to recruit and then unblock those people than it was for me to devote as much time as I could to Puma. And so my work on Puma now is really just more like management than anything else. It's more trying to recruit new contributors and trying to give them what they need to help Puma. And contributing to open source is a really fraught experience for a lot of people, especially their first time. And I think we should also be really conscious of that. Like, 95% of software developers have really never contributed to open source in a meaningful way. And that's a huge talent pool of people that could be helping us that aren't. So I'm less concerned about the problems of the 5% that are currently contributing than I am about why there are 95% of us that don't do anything. So that's what gets me excited to work on Puma now, is trying to change that ratio.

+ +

STEPH: I really like that mindset of where you are there to provide guidance but then essentially help unblock others as they're making contributions to the project but then still be there to have the history and full context and also provide a path forward of a good direction for Puma to head. In regards to encouraging more people to contribute to open source projects, I've often heard people say how challenging that is, where they have an open-source project that they would really love people to contribute to but finding people is really hard or just letting people know that they're interested in contributions. Have you had any strategies that have been successful for you in encouraging people to contribute?

+ +

NATE: Yeah. So first thing, the easiest thing is we have a contributing.md file. So that's something I think more projects should adopt is have an actual file in your project that says everything about how to contribute. Like, what kinds of contributions do you want? Different projects have different things that they want. Like, Rails doesn't want to refactor PRs. Don't send a refactor PR to Rails because they'll reject it. Puma, I'm happy to accept those. So letting people know like, “Hey, here's how we work here. Here's the community we're creating, and here's how it works. Here's how to get involved.” And I think of it as hanging out the shingle and saying, “Yes, I want your contributions. Here's how to do it.” That alone puts you a step above other projects.

+ +

The second thing I would say is you need to have contributor-only communication channels. So we have Matrix chat. So Matrix is like this successor to IRC. So we have a chat channel basically, but it's like contributors only. I don't enforce that, but I just don't want support requests in there. I don't want people coming in there and being like, “My Puma config doesn't work.” And instead, it's just for people that want to contribute to Puma, and that want to help out. If you have a question and come in there, anyone can answer it.

+ +

And then finally, another thing that I've had success with is doing one-on-one stuff. So I will actually...I have a Calendly invite that I think is in contributing.md now that you can just book 30 minutes with me anytime about contributing to Puma. And I will get on a Zoom call with you and talk to you about what are your concerns? Where do I think you can help? And I give my time away that way. The way I see it is like if I do that 20 times and I create one super contributor to Puma, that is worth more than me spending 10 hours on Puma because that person can contribute 100, 200, 1,000 hours over their lifetime of contributing to Puma. So that's actually a much more higher leverage contribution, really from my perspective. It's actually helping other people contribute more.

+ +

STEPH: Yeah, that's huge to offer people to say, “Hey, you can book time with me, and I will walk you through and let you know where you can start making an impactful contribution right away,” or “Here are some areas that I think you'd be interested, to begin with.” That seems like such a nice onboarding for someone who says, “I'm interested, but I'm nervous,” or “I'm just not sure about where to get started.” Also, I love your complaint department voice for the person who their Puma config doesn't work. That was delightful. [chuckles]

+ +

NATE: I think it's a little bit part of my open-source philosophy that, especially at a certain scale like Puma is at that we really kind of over-prioritize users. And I'm not really here to do support; I'm here to make the project better. And users don't actually contribute to open source projects. Users use the thing, and that's great. That's the whole reason we're open-sourcing is so more people use it. But it's important not to prioritize that over people who want to make the project better. And I think a lot of times; people get caught up in this almost clout chasing of getting the most GitHub stars that they think they need and users they think they need. And you don't get paid for having users, and the product doesn't get any better either. So I don't prioritize users. I prioritize the quality of the project and getting contributors. And that will create a better project, which will then create more users. So I think it's easy to get sidetracked by people that ask for your time when they're not giving anything back to the project in return. And especially at Puma’s scale, we have enough people that want my time or the time of other maintainers at Puma so that they can contribute to the project. And putting user support requests ahead of that is not good for the project. It's not the biggest, long-term value increase we could be making, so I don't prioritize them anymore.

+ +

STEPH: Yep. That sounds like more the pursuit of sparkly stats and looking for all those GitHub stars or all of those likes. Well, Nate, if you're game, I have two listener questions that I'd like to run by you because I shared with some folks that you are going to be on The Bike Shed today. And they're very excited and have two questions that they'd like me to run by you. How does that sound?

+ +

NATE: Yeah, all right.

+ +

STEPH: So the first question is, are there any paradigms or trends in Rails that inherently hurt performance?

+ +

NATE: Yeah. I get this question a lot, and I will preface it with saying that I'm the performance guy, and I'm not the software design guy. And I get a lot of questions about does such and such software design...how does that impact performance? And usually, there's like a way to do anything in a performant way. And I'm just here to help people to find the performant way and not to prescribe “You must always do X, Y, or Z,” or “ActiveRecord is bad. Never use it.” That's not my job here. And in my experience, there's a fast way to do almost anything.

+ +

Now, one thing that I think is dying, I guess, or one approach or one common...I don't know what to call it. One common mistake that is clearly wrong is to not do any form of server-side rendering in a web application. So I am anti-client-side app. But there are ways to do that and to do it quickly. But rendering a basically blank document, which is what most of these applications will do when they're using Rails as a back-end…you'll serve this basically blank document or a document with maybe some Chrome in it. And then, the client-side app has to execute, compile JavaScript, make XHR requests, and then render the page. That is just by definition slower than serving somebody a server-side rendered page. Now, I am 100% agnostic on how you want to generate that server-side rendering. There are some people that are working on better ways to do that with Rails and client-side apps. Or you could just go the Hotwire Turbolinks way. And it's more progressive enhancement where the back-end is always just serving the server-side rendered response. And then you do some JavaScript on top of that.

+ +

So I think five years from now, nobody will be doing this approach of serving blank documents and then booting client-side apps into that. Or at least it will be seen as outdated enough that you should never design a project that way anymore. It's one of those few things where it's like, yeah, just by definition, you're adding more steps into a rendering flow. That means, by necessity, it has to be slower. So I think everybody should be thinking about server-side rendering in their project. Again, I’m totally agnostic on how you want to implement that. With React, whatever front-end flavor of the month you want to go with, there's plenty of ways to do that, but I just think you have to be prioritizing that now.

+ +

STEPH: All right. Well, I like that five-year projection of where we're headed. I have found that it's often the admin-side where people will still bring in a lot of JavaScript rendering, just to touch on a bit of what you're saying, in terms of let's favor the server-rendered HTML versus over-optimizing a space that one, probably isn't a profitable space in terms that we do want our admins to have a great experience for our product. But if they are not necessarily our users, then it also doesn't need to be anything that is over the top or fancy or probably uses a lot of JavaScript. And instead, we can start simple. And there's a number of times that I've been on projects where we have often walked the admin back to be more server-rendered because we got to a point where someone was very excited to make the admin very splashy and quick but then couldn't keep up with the requests because then they were having to prioritize the user experience first. So it was almost like optimizing the admin, but then it got left out in the cold. So then it's just sort of this poor experience.

+ +

NATE: Yes. Shopify famously walked back their admin from I think it was Backbone to Turbolinks. And I think that that has now moved back to React is my understanding. But Shopify is a huge company, so they have plenty of time and resources to be able to do that. But I just remember that happening at the time where I was like, oh wow, they just rolled the whole thing back to Turbolinks again. And now, with the consolidation that's gone on in the React world, it's a little bit easier to pipe a server-side rendering into a React app. Whereas with Backbone, it was like no one knew what you were doing. So there was less knowledge about how to server-side render this stuff. Now it doesn't seem to be so much of a problem. But yeah, I mean, Rails is really good at CRUD apps, and admin is like 99% CRUD. And adhering as closely as possible to the Rails Golden Path there in an admin seems to be the most productive way to work on that kind of feature.

+ +

STEPH: All right. Ready for your second question?

+ +

NATE: Yes.

+ +

STEPH: Okay. This one's a bit more in-depth. They also mentioned a particular project name. So I am going to swap it out with a different name. So on project cinnamon roll, we found a really gnarly time-consuming API endpoint that's getting hammered. And on a first pass, we addressed a couple of N+1 issues and tuned the performance, and felt pretty confident that they had addressed the issue. But it was still fairly slow. So then they took some additional incremental steps. So they swapped out to use OJ for serialization that shaved off an additional 10% but was still slow. They also went the route of going straight to Rails cache with a one-minute expiration. So that way, they could avoid mucking with cache busting because they confirmed with the client that data could be slightly stale. And this was great. It worked out well. So it dropped their average response time down to less than 70 milliseconds. With all that said, that journey took a few hours over a few days, and multiple production deploys. And had they gone straight to the cache, then they would have had a 15-minute fix with a single deploy. So this person's wondering, are there any other examples like that where, rather than taking these incremental seemingly obvious performance whims, there are situations where you want to be much more direct with your path?

+ +

NATE: I guess I'd say that profiling can help you to understand and form better hypotheses about what will make things faster and what won't. Because a profiler can't really lie to you about where time goes, either you spent 20% of your time in this method, or you didn't. So I don't spend any time in any of my material talking about what JSON serializer you use. Because really that's actually never...that's really never anybody's bottleneck. It's never a huge proportion of people's total percentage of time. And I know that because I've looked at enough profiles that the issues are usually in other places. So I would say that if your hypotheses that you're generating are not working, it's because you're not generating good enough hypotheses. And profiling is the place to do that. So having profilers running in production is probably the biggest level-upscale-like that most teams could take. So having profilers that you can access as on production servers as a user is probably the biggest level up that you could make to generating the hypotheses because that'll have real production data, real production servers, real production environment. And it's pretty common now that pretty much every team that I work with either has that already, or we work on implementing it. It's something that I've seen in production at GitHub and Shopify. You can do it yourself with rack-mini-profiler. It's all about setting up the authorization, just making sure that only authorized users get to see every single SQL query generated in the flame graph and all that. But other than that, there's no reason you shouldn't do it. So I would say that if you're not generating the right hypotheses or you don't...if the last hypothesis out of 10 is the one that works, you need better hypotheses, and the best way to do that is better profiling.

+ +

STEPH: Okay, better profiling. And yeah, it sounds like there's also a bit of experience in there in terms of things that you're used to seeing, that you've noticed that could be outliers in terms of that they're not necessarily the thing that you want to improve. Like you mentioned spending time on how you're serializing your JSON is not somewhere that you would look. But then there are other areas that you've gained experience that you know would be likely more beneficial to then focus on to form that hypothesis.

+ +

NATE: Yeah, that's a long way of saying experience pays off. I've had six years of doing this every single day. So I'm going to be pretty good at...that's what I get paid for. [laughs] So if I wasn't very good at that, I probably wouldn't be making any money at it.

+ +

STEPH: [laughs] All right. Well, thanks, Nate, so much for coming on the show today and talking so much about performance. On that note, I think it's a good place for us to wrap up. If people are interested in following along with what you're working on and they want to keep up with your latest and greatest workshops that are coming out, where can they find you on the internet?

+ +

NATE: speedshop.co is my site. @nateberkopec on Twitter. And speedshop.co has a link to my newsletter, which is where I'm actively thinking every week and publishing stuff too. So if you want to get the drip of news and thoughts, that's probably the best place to go.

+ +

STEPH: Perfect. All right. Well, thank you so much.

+ +

NATE: No problem.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I’m @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

Together: Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+EgiiQk4X + + ]]> + + Steph Viccari + + + 295: To the Left, to the Left + https://bikeshed.thoughtbot.com/295 + 8d9706a4-7c85-48e3-9a2b-9db9167f44e6 + Mon, 07 Jun 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + After the last episode where database switching was discussed, a number of listeners reached out with thoughts. In particular, one listener gave a reproducible example of how to make things better. Chris talks about why he always moves errors to the left, and Steph gives a hot take where she admits that she is not a fan of hackathons and explains why. + +Steph and Chris also share exciting Bike Shed show news in that we now have transcripts for each episode, and tackle another listener question asking, "How do you properly implement a multi-step form in a boring Rails way?” Chris talks about his experiences with multi-step forms and gives his own hot take on refactoring: he doesn't until he feels pain! + 35:33 + no + + + After the last episode where database switching was discussed, a number of listeners reached out with thoughts. In particular, one listener gave a reproducible example of how to make things better. Chris talks about why he always moves errors to the left, and Steph gives a hot take where she admits that she is not a fan of hackathons and explains why. +Steph and Chris also share exciting Bike Shed show news in that we now have transcripts for each episode, and tackle another listener question asking, "How do you properly implement a multi-step form in a boring Rails way?” Chris talks about his experiences with multi-step forms and gives his own hot take on refactoring: he doesn't until he feels pain! +Database Switching in Dev Mode Gist (https://gist.github.com/danott/e698435bb4e1d34bc70853514ba681a7) +In Relentless Pursuit of REST – Derek Prior (https://www.youtube.com/watch?v=HctYHe-YjnE) +Transcript: +CHRIS: Happy Friday or whatever day it happens to be in your future situation. +STEPH: Happy day. [chuckles] +CHRIS: Happy day or night. I'm sorry, I'm done. [laughter] +STEPH: Shut up. [laughs] +Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I’m Steph Viccari. +CHRIS: And I’m Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been? +CHRIS: Happy Friday to you as well. My week's been good. It's been busy. I am taking next week off for a quick vacation. So it’s that…I think I've talked about this every time before I go on a vacation on the podcast, that focusing lens that going on vacation gives you. I want to make sure everything's buttoned up and ready to hand off, and I'm not going to be blocking anyone. And so, I always like the clarity that that brings. Because a lot of times I can look at well, there are infinity things to do, how do I pick? And now I'm like, no, but really, if I'm going to be gone for a week, I must pick. And so yeah, I'm now very excited to lean into vacation mode and relax for a bit. +STEPH: Yeah, that's awesome. I hear you. I always go into that same mode pre-vacation. +CHRIS: But in tech news, after the most recent episode that was released where we talked about the database switching stuff, a number of listeners were very kind and reached out with some thoughts. In particular, Dan Ott is one listener who reached out not only with just some generic thoughts, but he also gave a reproducible example of how to make things slightly better. So the particular thing that a few folks honed in on was the idea that I was describing the feeling of in production; we can occasionally run into these ActiveRecord read-only errors, which is a case where you have a GET request that happens to try to create or update a record. And as a result, you're going to get this ActiveRecord read-only because you're using the follower database, which has a read-only connection. All of that is fine, but ideally, we would want to catch those before production. We want to catch them in development. And broadly, the issue that we have here is that in production, our system is running in a different way. It's running with two different database connections, one for read-only, one for writing, and that's different than in development, where we're running with a single connection. +As an interesting thing, a lot of the stuff that I see on the internet is about using SQLite in development and then Postgres in production. And so that's an example of development production parity that we've really...I think thoughtbot is definitely a place that I internalize this very strongly. But you've got to have the same database, and especially because it's relatively straightforward to run Postgres locally, I'm always going to be running the same version of the database locally as in production. But in this case, I'm now getting this differentiation. And so what Dan and a handful of other folks highlighted was you can actually reproduce this functionality in development mode with a fun little trick where you end up creating a secondary connection to your development database, but you mark it as replica:true. And so, by doing that, Rails will establish a read-only connection. And then, all of the behavior that you configure for production can also be run in development. So now, as you're building out a new feature, and if you happen to implement a GET request that does some side effect in the database, that'll blow up in development as opposed to production, which is very exciting. +STEPH: Yeah, that’s awesome. I love that Dan reached out and shared this example with us. I actually haven't read through all of the details just yet. In fact, I just opened it up, and I started going through it, and there's a lot of really...it looks like a lot of great notes here and a really nice example that walks you through how to have that production parity locally. So this is really neat. I appreciate Dan sending this to us. +CHRIS: Yeah, this is a wonderful little artifact actually that’s interesting just in and of itself. We'll certainly include a link in the show notes to the gist that Dan shared. What's interesting...I think I knew of this, but I've never actually seen it before. This is a single-file Rails application, which is a very novel concept, but it's got a bundler/inline call at the very top. And then there's an inline gemfile block, and then a set of requires to pull in the relevant Rails stuff. And then it configures the database connection, configures a single controller or actually a handful of controllers, it looks like, and then it renders inline HTML. And so it has all of the pieces. And I didn't realize that at first, but then I pulled it down and I just ran it locally. So it’s just Ruby and then the file that this just represents, and suddenly I had a reproducible Rails app. I believe this is used in reporting issues to Rails so you can get the minimum reproducible test case. And that's why this works is, I think, the Rails core team, over time, has pushed on any of the edges that wouldn't have worked and made it so that this is possible. But it's a really neat little thing where it's this self-contained example. And so running this file just via Ruby does all of this stuff, installs everything that's necessary. And then, you can click around in the very minimal HTML page that it provides and see the examples of the edges that it's hitting. And again, this is in development mode, so it's pushing on that. But yeah, it's both a really interesting tip as to how to work with this and a really interesting way to communicate that tip—so double points to Gryffindor, aka Dan Ott. +STEPH: Double points to Gryffindor. I love it. +CHRIS: I’m cool. [laughs] +STEPH: That's very charming. [laughs] I've never seen anything like this either, in terms of one file that then can reproduce and run in a Rails app. Agreed, double points to Gryffindor, aka Dan. +CHRIS: Aka Dan. +STEPH: [chuckles] I hope Dan’s a Harry Potter fan. +CHRIS: I hope so. And I hope he's a Gryffindor, who knows? Maybe Ravenclaw. It's really up in the air. But the other thing that is interesting that I haven't yet figured out here is this works for development mode. I've tested it in development. It's great. I was able to remove the fix line that I had in my code where I had one of these breaking controller actions and run with this configuration in development mode. And then boom, it blew up in development, and I was like, yay, this is great. Move those errors to the left, as they say. But I realized there are some other edge cases, known ones actually. Another developer on the team mentioned something where he knows of a place that this is happening, but that code path isn't running right now just because it's a seasonal thing within the app. And I was like, oh, that's really interesting. I wish there were a way to test all the behavior. Oh, tests, that's what I need here. And so I tried to configure this in test mode, but I wasn't exactly clear on what was failing. But at a minimum, I know that the tests run in transaction, so I think that might make this more complicated because if you have two connections to the same database, but you have transactions, I feel like that might be conflating things, and it wouldn't necessarily map perfectly in. But if we could get that, that would be really great. Moving forward, any new development the development configuration will cover what I need. But retroactively, as I'm introducing the database switching to the application, it would be great if the test suite were a way to find these edge cases. So that's still an open question in my mind. But overall, the development fix is such a nice little addition to this world. And again, thank you so much to Dan for sending this in. +STEPH: Yeah, I agree; having this in tests would be wonderful. I am intrigued not having read through the full example that's been provided. But I'm wondering if this is one of those we default to read-only mode, although that feels like too much because we're often creating data for each test. So maybe we default to...yeah, you have to have both because you have to have your test set up where you're going to write data. So you can't default to just being in read-only mode. But then say you want to run a controller action or something else in a read-only mode. So then you would have to change your database connection for that action, and that sounds complicated. You also said something else I'm intrigued by. You said, “Move errors to the left.” +CHRIS: Yes. Now that you're asking me, I'm trying to remember the exact context. But it's the idea that there are different phases in your development and eventually getting to production life cycle, and so a bug that a user sees that's all the way to the right. That's as far along the development pipeline as it can be, and that's the worst case. You don't want a user to see a bug. So QA would be a step right before that. And if you can catch it in QA, you've moved it to the left, which is a good thing. But even better than that would be to catch it in your automated tests, and maybe even better than that would be static analysis that's running in your editor, and maybe even better than that is a type system or something like that. So the idea of moving to the left is to push those errors or when you're catching the errors closer to the point where you're actually introducing them. And that's just a general theme that I like or a Beyoncé song. +STEPH: I was just going to say, all right, move over, Beyoncé. There's another phrase in town, moving to the left. [laughs] +CHRIS: I'm really going for a lot of topical pop culture references today. That's what I'm about. +STEPH: We’ve got Harry Potter, Beyoncé. We've got to pull out one more at some point. +CHRIS: We'll see. I don't want to stretch myself too thin right before vacation. But yeah, thanks again to Dan and the handful of other folks that reached out either on Twitter or via email to point me in the right direction on the database switching stuff. At some point, I should definitely do a write-up on this because I've now collected together just about enough information that it feels like it's worthy of a blog post, or at least that's the story in the back of my head. I got to cross a certain threshold before I'm probably going to write a blog post. But yeah, that's a bit of what's up in my world. What's going on in your world? +STEPH: I love it. You're saying write a blog post into the mic, so then that way you know it's going to encourage you to write it later. +CHRIS: That’s the trick right there. [chuckles] +STEPH: Let's see, today's been a lovely day. It's been a lovely week in general. Today is especially lovely because it is thoughtbot’s Summit, and Summit is where we all gather. We do this once a year. So the whole team, all of us across all of our...I was going to say offices but now just across all of our home offices. And we get together, and we have a day filled with events, and we usually have a wonderful team that helps organize a bunch of events that then we get together for. So a number of those fun events are like paired chats, which is one of my favorites because I often talk to people that I haven't talked to in a long time or perhaps people that I haven't even met yet that have just recently joined the company. We also have lightning talks, and I know I'm very biased, but I think we have some of the best lightning talks. They are just hilarious. So I love our lightning talks. We're also doing escape rooms. Oh, speaking of which, there's a Harry Potter-themed murder mystery that's happening. We have Nintendo Switch parties and a professional tarot card reading, which I've never done, but I'm actually doing that later today after we're done chatting. +CHRIS: Wow, that is an adventurous day. And I like that it's fun, and it's connecting people and getting to know your teammates and all those nice things. +STEPH: Very much. I also have a hot take. I don't know if I've shared this with you, so I'm going to share it here with you on the mic in regards to this. So previous years, for Summit, we used to have more coding projects, too. They were often opt-in, but that's something that happened. And specifically, we have Ralphapalooza, which is our hackathon. And it recently came up where a number of us were talking about Ralphapalooza, and I have come to the potentially contentious point of view that I don't like hackathons. I'm not a fan of them. +CHRIS: Hot take. I like that you led in calling it a hot take, and then you provided said hot take, so I have to respond as if it's a very hot take. +STEPH: That's true. Maybe it's not a hot take. Maybe people disagree. What do you think? Do you like hackathons? +CHRIS: I have enjoyed them in the past. But I will say, particularly within the context of Summit or Ralphapalooza, I always felt a ton of pressure. It's so hard to right-size a project to that space, to that amount of time. You want to do something that's not trivial. You want to do something that at the end of it you're like, oh cool, I did that. Either it's like a novel thing that you're creating, or you're learning something new or whatever, but it's so hard to really do something meaningful in that amount of time. And often, people are shooting for the moon, and then they're just like, “Ah, so it's just a blank page right now. But behind the scenes, there's a machine learning algorithm that is generating the blank page. And we think with enough inputs to the model that it'll…” and it is actually super interesting work they did. But there's the wonderful pressure at the end to present, which I think is really useful. I like constraints. I like the presentations; they’re always enjoyable, even in a case where it's like, this project did not go well, let's talk about that. That's even fun. But it really is so hard to get right. I've never gone to a hackathon outside of thoughtbot, so I can't speak to that, but I know that I have heard folks having a negative opinion of them. And I don't know that I'm quite at the hot take level that you are, but it's complicated, if nothing else. It's a lot of fun sometimes. I particularly remember the Elm project that you and I worked on. Well, we worked in the same group. We didn't actually work together, but same idea. That was a lot of fun. I liked that. +STEPH: That’s a good point. Even within the context of Ralphapalooza, our hackathons are more...I’m going to use the word sustainable because they're nine-to-five hackathons where we are showing up; we are putting in the work. There is pressure, and we do want to present. But it's not one of those stay up all night and completely leave your family for a day or two to hack on some code. [laughs] Sorry, I'm throwing some shade right now. But even with that sustainable approach, I've always felt so much pressure. I enjoyed that green space and then getting to collaborate with people I don't typically collaborate with, but it still felt like there was a lot of pressure there, especially that presentation mode always made me nervous. Even if it is welcoming to say, “Hey, this didn't go well,” that doesn't necessarily feel great to present unless you are comfortable presenting that scenario. And I also really look forward to these company events as a way to connect and have some downtime and to just relax because then the rest of our days are often more stressful. So I want more company time for me to connect with colleagues but then also feel relaxed. So I was always, in the beginning, I was like, yeah, Ralphapalooza, woo, let’s go. And now I'm just like, nah, I'm good. I'd really just want a chill day with my colleagues. +CHRIS: Is there an option to go for a walk with friends? Because if so, I will be taking door number two. +STEPH: Cool. Well, I feel better having gotten that out into the ether now. But switching just a bit, there is something that I'm very excited about where we now have transcripts for each episode. This is something that you and I have been very excited about for a while and wanted to make happen but just weren't able to, but we now have them. And so people may have noticed them as we're adding them to the show notes. And I'm just so excited for a number of reasons, one, because there are a number of times that I have really wanted to search the shows or an episode for a particular topic and couldn't do so. So I'm just sitting there listening, trying to find a particular topic. There's also the fact that it will make the episodes more accessible. So for anyone that is hearing impaired or maybe if English isn't their first language, having it written down can make the episode more accessible. And there’s the massive SEO boost that's always a win. And then I don't know if this is going to happen, but I'm excited that transcripts may help us repurpose content because there's a number of our topics that I would love to see turned into blog posts, and I think having the transcript will make that easier. +CHRIS: Yeah. I'm equally super excited about the addition of transcripts, and across the line, SEO is cool, I think. Yeah, that sounds nice. Being able to reuse the content is very interesting to me because this is definitely my preferred medium. I find that I can just show up on the microphone, and it turns out I have opinions about a lot of stuff but trying to write a blog post is incredibly difficult for me. The small handful of good things that we might have collectively said over the years if we can turn those into more stuff that sounds great and honestly, just the ability to search for and find older episodes now based on like, I know we talked about inbox zero. I remember that was an episode, but I don't know which one, now that’s searchable, and that's a thing that we can find. I actually still use the Upcase search for…I know I said something. I know there was a weekly iteration where I talked about some topic. And I built the search on Upcase for me as the primary user because one, I'm often referencing content on Upcase, and I want to be able to find it more easily, so I made the search. I also put a SQL injection vulnerability into the search in my first implementation so, go me. But then I got rid of it shortly after. +STEPH: I love when people bring that energy of “I introduced this issue, go me,” because I find that very fun and also just very healthy in terms of we're going to make mistakes. And I have noticed a number of times at thoughtbot standup that whenever we make a mistake, or it’s like, I accidentally sent out real emails on production for a job that I thought I was testing on staging. Sharing those mistakes in a very positive light is a very honest way to approach it. So I just had to comment on that because I'm a big fan of that. +CHRIS: I'm glad you enjoyed my framing of it. I really enjoy that type of approach or way to communicate, although I think it is a delicate line. Like, I don't want to celebrate these sorts of things because an SQL injection vulnerability is a non-trivial thing. It shows up in tons of applications, and we need to take security seriously and all of that sort of stuff. But I think the version that I think is good for that type of thinking or communication is the psychological safety. If we're scared of admitting that we introduced a bug, that's bad. That's going to lead to worse outcomes longer term. And so having the shared communication style openness to like, yep, that happened yesterday. And there should be a certain amount of contrite in this where it’s like, I feel bad that I did that. I even feel worse because when it happened, I recognized that it happened, and then I tried to exploit it in development mode to prove it to myself, and I couldn't exploit it. So I was like, I feel doubly bad as a programmer today. I both introduced a bug, and I'm not even smart enough to exploit it. But I know that an uber lead hacker out there could, and so I got to fix it. But that sort of story is part of the game. It's a delicate equilibrium, but having the ability to talk about that and having a group that can have a conversation, I do think that's very important. +STEPH: Yeah, well said. I do think there's an important balance to strike there. Pivoting just a bit, we have a listener question, and this question comes from Benoit. Benoit wrote in to the show, “How do you properly implement a multi-step form in a boring Rails way?” I'm very interested in this question because I am working on a project that has a multi-step form. There are probably about maybe six, seven steps, and those steps can change based on different configurations. And our form is not implemented in a boring way at all. It's a very intricate, confusing design, I would say, which I think is fairly common when it comes to multi-step forms. I'm curious, what experience do you have with multi-step forms, and what's your general feeling with them? +CHRIS: Well, I happen to be working on one right now. So generally, I don't have an oh, I got this, I know the answer. This is one of those that I'm like; I feel like each time I reinvent it a little bit. But the version that I'm working on right now is an onboarding flow. So we create a user record, which at this point I only have email associated with, and then from there, when a user lands, they need to provide a bunch of profile information, and it is a requirement. They have to fill it out. We need to have all of it before we can actually start doing the real stuff of the application. And so, the way that I've ended up modeling it is interesting. I'm going to use the word Interesting. I think I like it, but I'm not sure. So I have this model; let’s call it a profile that we're going to associate with the user. And the profile has a bunch of fields: first name, last name, address, phone number, and a handful of other things. And again, I need to have these pieces of information. So I want those to be non-nullable columns. But as someone is walking through this form, I'm not going to have all the information. So there's going to be a progression. We'll get first name, then we get last name, and then we get the next piece of information. So I need a nullable storage, but I don't want to just put it into the session or something like that, which I think would be an option. So what I've done is I've introduced a secondary model. So this is a full ApplicationRecord database-backed model called partial profile. And it is almost identically the same interface as the profile, but each field is nullable. There's also a slight difference in that the profile field has an additional status column that talks about once we've gone through all of this, we can add some status and track other things. But yeah, that main difference of in the profile, everything is non-nullable, and the partial profile is nullable. +So then there's a workflowy object, a command object, as I like to have in my systems these days that handles the once they've gathered all their information, turn the partial profile into a profile, send it out to an external system that does some verification and some other lookups and things like that. And then, based on the status of that, mark the status of the profile. But one of the things that I was able to do is make that transition from partial profile to full profile. I'm doing that within a transaction. So if at any point anything fails within all of this, I can roll the whole thing back, and I'll be back to only having the partial profile, which was a very important thing. I would not want to have a partial profile and a profile because that's a bad state. But a lot of this for me is about data modeling and wanting to tell truths with the database and constrain what are the valid states of my application? So one solution would be to just have a profile model that has nullable columns for all of these fields. But man, do I hate that answer. So I went what feels like an extreme take of having two fundamentally different models, but that's where it's actually working out well. I'm able to share validations across them. So as new data is added, I can conditionally validate as new things are shared, and I'm able to share that via concern in the two models. So it's progressively getting more constrained as I add data to this thing. And then, in the background, there is a single controller that skips through all of the steps and has an update action that just keeps pushing data into this partial profile until, eventually, it becomes a profile. So that's focused specifically on the data model stuff. I think there are other aspects of a more workflowy type thing in Rails, but that's our thing. What do you think, good idea, bad idea, terrible idea? +STEPH: [chuckles] One, I love that you have this concrete example because I have some higher-level ideas around this particular question, but I didn't have a great example that I wanted to share. So I love that you have that, that we can talk through. I really, really like how you have found a way to represent the fact that each valid state of your application as you refer to it….so you have this concept of someone's going through the flow and their address can be nullable at this stage, but by the end of this flow, it shouldn't be nullable anymore. So you have that concept of a partial profile, and then it gets converted into a profile. I am intrigued by the fact that it's one controller because that is where I am feeling pain with the multi-step form that I'm working on where we have one very large controller that handles this entire...I'm going to call it a wizard since that's how it's referred to, and there are seven or eight different steps in this wizard. And the job of this controller is each time someone goes to a new step; this controller is trying to figure out okay; what step are you on based on the parameters that you have, based on some of the model attributes that are set? What step are you on, and what should we show you? And that has led to a very large method and then also complex, lots of conditional-based code. And instead, I would really like to flip that question around or essentially remove the what step am I on? And instead, ask what step is next? So instead, take the approach that each step of the form should have a one-to-one mapping to another controller. And that can get really hard because we're often conditioned to the idea that we should have a one-to-one correlation between each controller and an ActiveRecord model, but that's not necessarily what happens in our form. +You have the concept of a partial profile versus being able to map to a full profile. So I am very much in favor of the idea of trying to map each step of the form to a controller. So that, to me, makes the code more boring. It makes it more understandable. I can see what's happening for each step. But then it's not boring in terms that it requires creativity to say, okay, I don't have a perfect ActiveRecord model that maps to this controller, but what resourceful controller can I make instead? What is the domain object that I can put here instead? Maybe it's an ActiveModel object instead. So that way, we can apply ActiveRecord-like behavior to plain old Ruby objects, or maybe it's using a form object. That way, we can still validate all the fields that the user is providing to us, but that doesn't necessarily map directly to a full profile just yet. So I really like all the things that you've said. But I am intrigued by the approach of using a single controller. How's that feeling so far? +CHRIS: That part is actually feeling fine. So a couple of things you said in there stand out to me, one, where it's a very big controller. That is something that I would definitely avoid. And so, I have extracted other pieces. There is an object that I created, which at this point is just in-app models because I didn't know where else to put it, but it's called onboarding. And so the workflow that I'm trying to introduce, the resource maybe is what we would call it, is the idea of onboarding, but it's not an ActiveRecord level thing. At the ActiveRecord level, I have a profile and a partial profile, and then there's an account, and there's also a user. There are four different database level models that I want to think about. But fundamentally, from a user perspective, we're talking about onboarding. And so I have an object that is called onboarding, and it contains the logic around given the data that we have now, what step comes next? Is this a valid step? Should the user go back? Et cetera, et cetera. So that extraction is one piece that definitely makes sense. Also, thus far, mine is relatively straightforward in terms of I get data in, and I just need to update my partial profile record each time. So the update action is very straightforward. But I've done different versions of this where there are more complex things that happen. And so what I've done is basically make a splat route. So it's like onboarding/ and then the step name and that gets posted or gets put, I guess, along with everything else for the update. And so now the update says, “Well, if I'm updating for this, then handle it this way; otherwise, just update the profile record.” And so then I can extract maybe another command object that handles like, “Oh, when we're doing the address stuff, we actually have to do a little bit of a lookup and a cross-reference and some other things, but everything else is just throwing data into a database record.” And so that's another place where I would probably make an extraction, which is this specialized case of handling the update of the address is special. So I want to extract that, be able to test around that, et cetera. But fundamentally, the controller thing actually works out pretty well. The single controller with those sorts of extractions has worked out well for me. +STEPH: Okay, cool. Yeah, I can see how depending on how complex your multi-step form is, having it all in one controller and then extracting those smaller objects to then handle each step makes a lot of sense and feels very friendly to read, and is very testable. For the form that I'm working in, there are enough steps and enough complexity. I'd really love to break it out. In fact, that's something that we're working on right now is taking each of those chunks, each state of the form, and introducing a controller for it. So let's say if you are filling out an appointment and we need to get your consent for something, then we actually have a consent controller that's going to handle that part, that portion of it. And I'd be intrigued for your form if things got complicated enough that it’s the concept of onboarding or a wizard that leads us to having one controller because then we think of this one concept. But there are often four or five concepts that are then hiding within that general idea of an onboarding flow. So then maybe you get to the point that you have an onboarding address or something like that. So then you could break it out into something that still feels RESTful but then lets you have that very boring controller that does just enough and essentially behaves like a bi-directional linked list. So it knows, based on the route, it knows the step that it's on, and it knows where to go back, and then it knows the next step to go forward. And then that's all it's responsible for, so it doesn't have to also figure out what step am I currently on? +CHRIS: I like the bi-directional link list, dropping knowledge bombs right there. +STEPH: Pew-pew. +CHRIS: It's interesting. I don't necessarily feel...right now; I don't feel that pressure. I feel fine with the shape of the singular controller. This is perhaps not necessarily even a good thing, but I think my bias is always to think a lot about the URL structure and really strongly embrace the user point of view. I'm going through the workflow. I don't care if I'm picking from a calendar and setting up a date versus filling in an address field or how you're storing those on the back end; that’s your job, developer people. And I try as hard as I can to put myself in that mindset. And so the idea that there's this sequential thing that knows how to go back and forward and shows like, show which page we're on, that feels like it belongs in one controller in my mind, or I guess I'm fine with it being in one controller. And splitting it out feels almost more complicated in that I then need to share some of that logic across them, which is very doable by extracting some object that contains a logic of what goes back, what goes forward. But I think I like to align URL structure to how many controllers as opposed to anything else. And because I'm keeping a consistent URL structure where it's /onboarding/name /onboarding/address, and I'm stepping through in that way for all of those things, then it makes sense to me that those go to my onboardings controller. But I'm interested to see if I start to feel pain somewhere down the road because I expect this onboarding to get more complicated as time goes on. And will I bump my head on the ceiling? Probably. It seems likely. But for now, I'm liking it. +STEPH: Yeah, it certainly makes sense. It's one of those areas that you want to start small and then build out as it feels reasonable. But in regard to the URLs, I'm with you, where I very much want there to be a clean, nice URL for the user to see. And then we handle out any of those details on the back end since that is our work to do. But I am still envisioning that there is a clean URL. So it may be you have an onboarding/address and then onboarding/consent, borrowing from my previous example, but then that maps to where you have an onboarding namespaced controller that is then for an address or for consent. So you don't necessarily have an object that's having to be passed along that stores the state and the next step that the person is on. But that way, you do definitively know from the route okay, I am on this step. And so then that's how you get away from that question of what step am I on? Because that's already given to us based on the URL and then the controller. So then you only have to care about validating the input that's provided on that page, but then also being able to calculate dynamically okay, if this person needs to go back, what's the previous step and if they go forward, what's the next step? +CHRIS: What you're saying totally makes sense. And I'm now worried that I'm going to wake up a few days from now and look at my controllers and be like, I hate this. Why did I ever do this? I think the hesitation that I had, and this feels like a terrible reason, but in terms of what the config/routes.rb setup would be for this, it's namespace onboardings. And then within that, a bunch of singular routes and inside of that, inside that namespace, would be a bunch of singular resources so like, resource address, resource blah, blah. And I don't know why, but I don't like that. I don't like that. I don't like that. Now that I'm saying it out loud, I'm like, yeah, that actually would be a pretty clean mapping. And right now, I have implicitly what those available routes are but not explicitly. It also feels like there would be a real explosion of controllers there because there's a bunch of steps and growing in this controller or in this namespace. And they're all going to do the same thing, in my case at least, of just adding data in. But that's not a reason to not make...like, controllers are cheap; I should make controllers so, hmm. +STEPH: Yeah. So I think that's the part in my mind that maps to the boring part is because we are creating controllers. There's maybe an explosion of them, and it's boring. Like, the controllers don't do very much. And then that feels a little bit wrong to us because we're like, okay, I created this controller, it does very little. So maybe I should actually group this logic somewhere else. But I think that is the heart of it and how you stay boring is where you have just that code be so simple that it almost feels wrong. +CHRIS: That right there, that sound bite that we just had, that was a knowledge bomb drop, and I liked it. Now I've got to go back and refactor to the form that you're talking about because I am sold. +STEPH: Oh, I'm glad you like it. I am intrigued if you do refactor then what that would look like and how it feels. But I also totally understand you're busy, so if you don't, that's cool too, no pressure. +CHRIS: My honest answer is that I almost certainly won't refactor until I feel the pain. It's one of those things where like, okay, maybe I've now decided that this code is not the best, but the time to refactor it isn't when that code is just humming along working fine. It's a general thing that I think we share in terms of how we think about it. But the preemptive refactoring, I guess broadly speaking, I'm not a fan of preemptive factoring. I'm a fan of refactoring just in time or as we're feeling the pain, which is the counterpoint to that is let's not extract tech debt tickets because then they turn into preemptive refactoring again. It’s like, ah, I'm not really feeling...I'm not in there right now. But the version of the code that I have now is probably fine. I don't think it's a problem although I am convinced now of the boring way. I want to go back to the boring way, but it will feel like it's worth changing down the road when I feel any pressure in that system or need to revisit it. So it's like that. That's how I think about that sort of thing. +STEPH: Yeah, I wholeheartedly agree. It's one of those if you refactor...if this is a side project, if you want to refactor just for testing new software theories and then reflecting on what that new refactor looks like, that's awesome. In terms of any other refactors, then I wholeheartedly favor waiting until you feel that pain and it feels like the right thing to do; otherwise, it's unnecessary code turn. And while I strongly believe in experiments, I don't believe in putting teams through those personal experiments. +CHRIS: More hot takes from Steph. I like it. +STEPH: Circling back just a bit and talking about having one controller for each step of the form, that part I struggle with it frankly because it is hard to think about this is a concept, but what do I call this? Because it doesn't necessarily map to something necessarily in my database. There's a really great talk by Derek Prior that’s called In Relentless Pursuit of REST, where Derek does a great job of providing some inspiration around how to create routes that don't necessarily feel like they could be RESTful, or maybe they're following that more RPC format. And he does a great job of then turning around and saying, “Well, this is how we could think about, or this is how we could shift our thinking in turning this into a more RESTful route.” So then it does map to something that's meaningful in our domain. Because we have thoughtfully, or likely very thoughtfully, grouped this form together in a meaningful way to the user. So then that's inspiration right there to give us a way to name this thing because we are showing it to the user in a meaningful way. So then that means we can also give it a meaningful name. That’s all I got on multi-step forms. [laughs] +CHRIS: That feels like it was a lot. We've covered data models. We’ve covered controller structures. We fundamentally reoriented my thinking on the matter. I feel like we covered it. +STEPH: Yeah, I agree. Well, Benoit, thank you for sending in this question. I hope you found our discussion very helpful. And on that note, shall we wrap up? +CHRIS: Let's wrap up +STEPH: The show notes for this episode can be found at bikeshed.fm. +CHRIS: This show is produced and edited by Mandy Moore. +STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or review in iTunes as it helps other people find the show. +CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @bikeshed on Twitter. And I'm @christoomey. +STEPH: And I'm at @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Byeeeee. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + After the last episode where database switching was discussed, a number of listeners reached out with thoughts. In particular, one listener gave a reproducible example of how to make things better. Chris talks about why he always moves errors to the left, and Steph gives a hot take where she admits that she is not a fan of hackathons and explains why.

+ +

Steph and Chris also share exciting Bike Shed show news in that we now have transcripts for each episode, and tackle another listener question asking, "How do you properly implement a multi-step form in a boring Rails way?” Chris talks about his experiences with multi-step forms and gives his own hot take on refactoring: he doesn't until he feels pain!

+ + + +

Transcript:

+ +

CHRIS: Happy Friday or whatever day it happens to be in your future situation.

+ +

STEPH: Happy day. [chuckles]

+ +

CHRIS: Happy day or night. I'm sorry, I'm done. [laughter]

+ +

STEPH: Shut up. [laughs]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I’m Steph Viccari.

+ +

CHRIS: And I’m Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been?

+ +

CHRIS: Happy Friday to you as well. My week's been good. It's been busy. I am taking next week off for a quick vacation. So it’s that…I think I've talked about this every time before I go on a vacation on the podcast, that focusing lens that going on vacation gives you. I want to make sure everything's buttoned up and ready to hand off, and I'm not going to be blocking anyone. And so, I always like the clarity that that brings. Because a lot of times I can look at well, there are infinity things to do, how do I pick? And now I'm like, no, but really, if I'm going to be gone for a week, I must pick. And so yeah, I'm now very excited to lean into vacation mode and relax for a bit.

+ +

STEPH: Yeah, that's awesome. I hear you. I always go into that same mode pre-vacation.

+ +

CHRIS: But in tech news, after the most recent episode that was released where we talked about the database switching stuff, a number of listeners were very kind and reached out with some thoughts. In particular, Dan Ott is one listener who reached out not only with just some generic thoughts, but he also gave a reproducible example of how to make things slightly better. So the particular thing that a few folks honed in on was the idea that I was describing the feeling of in production; we can occasionally run into these ActiveRecord read-only errors, which is a case where you have a GET request that happens to try to create or update a record. And as a result, you're going to get this ActiveRecord read-only because you're using the follower database, which has a read-only connection. All of that is fine, but ideally, we would want to catch those before production. We want to catch them in development. And broadly, the issue that we have here is that in production, our system is running in a different way. It's running with two different database connections, one for read-only, one for writing, and that's different than in development, where we're running with a single connection.

+ +

As an interesting thing, a lot of the stuff that I see on the internet is about using SQLite in development and then Postgres in production. And so that's an example of development production parity that we've really...I think thoughtbot is definitely a place that I internalize this very strongly. But you've got to have the same database, and especially because it's relatively straightforward to run Postgres locally, I'm always going to be running the same version of the database locally as in production. But in this case, I'm now getting this differentiation. And so what Dan and a handful of other folks highlighted was you can actually reproduce this functionality in development mode with a fun little trick where you end up creating a secondary connection to your development database, but you mark it as replica:true. And so, by doing that, Rails will establish a read-only connection. And then, all of the behavior that you configure for production can also be run in development. So now, as you're building out a new feature, and if you happen to implement a GET request that does some side effect in the database, that'll blow up in development as opposed to production, which is very exciting.

+ +

STEPH: Yeah, that’s awesome. I love that Dan reached out and shared this example with us. I actually haven't read through all of the details just yet. In fact, I just opened it up, and I started going through it, and there's a lot of really...it looks like a lot of great notes here and a really nice example that walks you through how to have that production parity locally. So this is really neat. I appreciate Dan sending this to us.

+ +

CHRIS: Yeah, this is a wonderful little artifact actually that’s interesting just in and of itself. We'll certainly include a link in the show notes to the gist that Dan shared. What's interesting...I think I knew of this, but I've never actually seen it before. This is a single-file Rails application, which is a very novel concept, but it's got a bundler/inline call at the very top. And then there's an inline gemfile block, and then a set of requires to pull in the relevant Rails stuff. And then it configures the database connection, configures a single controller or actually a handful of controllers, it looks like, and then it renders inline HTML. And so it has all of the pieces. And I didn't realize that at first, but then I pulled it down and I just ran it locally. So it’s just Ruby and then the file that this just represents, and suddenly I had a reproducible Rails app. I believe this is used in reporting issues to Rails so you can get the minimum reproducible test case. And that's why this works is, I think, the Rails core team, over time, has pushed on any of the edges that wouldn't have worked and made it so that this is possible. But it's a really neat little thing where it's this self-contained example. And so running this file just via Ruby does all of this stuff, installs everything that's necessary. And then, you can click around in the very minimal HTML page that it provides and see the examples of the edges that it's hitting. And again, this is in development mode, so it's pushing on that. But yeah, it's both a really interesting tip as to how to work with this and a really interesting way to communicate that tip—so double points to Gryffindor, aka Dan Ott.

+ +

STEPH: Double points to Gryffindor. I love it.

+ +

CHRIS: I’m cool. [laughs]

+ +

STEPH: That's very charming. [laughs] I've never seen anything like this either, in terms of one file that then can reproduce and run in a Rails app. Agreed, double points to Gryffindor, aka Dan.

+ +

CHRIS: Aka Dan.

+ +

STEPH: [chuckles] I hope Dan’s a Harry Potter fan.

+ +

CHRIS: I hope so. And I hope he's a Gryffindor, who knows? Maybe Ravenclaw. It's really up in the air. But the other thing that is interesting that I haven't yet figured out here is this works for development mode. I've tested it in development. It's great. I was able to remove the fix line that I had in my code where I had one of these breaking controller actions and run with this configuration in development mode. And then boom, it blew up in development, and I was like, yay, this is great. Move those errors to the left, as they say. But I realized there are some other edge cases, known ones actually. Another developer on the team mentioned something where he knows of a place that this is happening, but that code path isn't running right now just because it's a seasonal thing within the app. And I was like, oh, that's really interesting. I wish there were a way to test all the behavior. Oh, tests, that's what I need here. And so I tried to configure this in test mode, but I wasn't exactly clear on what was failing. But at a minimum, I know that the tests run in transaction, so I think that might make this more complicated because if you have two connections to the same database, but you have transactions, I feel like that might be conflating things, and it wouldn't necessarily map perfectly in. But if we could get that, that would be really great. Moving forward, any new development the development configuration will cover what I need. But retroactively, as I'm introducing the database switching to the application, it would be great if the test suite were a way to find these edge cases. So that's still an open question in my mind. But overall, the development fix is such a nice little addition to this world. And again, thank you so much to Dan for sending this in.

+ +

STEPH: Yeah, I agree; having this in tests would be wonderful. I am intrigued not having read through the full example that's been provided. But I'm wondering if this is one of those we default to read-only mode, although that feels like too much because we're often creating data for each test. So maybe we default to...yeah, you have to have both because you have to have your test set up where you're going to write data. So you can't default to just being in read-only mode. But then say you want to run a controller action or something else in a read-only mode. So then you would have to change your database connection for that action, and that sounds complicated. You also said something else I'm intrigued by. You said, “Move errors to the left.”

+ +

CHRIS: Yes. Now that you're asking me, I'm trying to remember the exact context. But it's the idea that there are different phases in your development and eventually getting to production life cycle, and so a bug that a user sees that's all the way to the right. That's as far along the development pipeline as it can be, and that's the worst case. You don't want a user to see a bug. So QA would be a step right before that. And if you can catch it in QA, you've moved it to the left, which is a good thing. But even better than that would be to catch it in your automated tests, and maybe even better than that would be static analysis that's running in your editor, and maybe even better than that is a type system or something like that. So the idea of moving to the left is to push those errors or when you're catching the errors closer to the point where you're actually introducing them. And that's just a general theme that I like or a Beyoncé song.

+ +

STEPH: I was just going to say, all right, move over, Beyoncé. There's another phrase in town, moving to the left. [laughs]

+ +

CHRIS: I'm really going for a lot of topical pop culture references today. That's what I'm about.

+ +

STEPH: We’ve got Harry Potter, Beyoncé. We've got to pull out one more at some point.

+ +

CHRIS: We'll see. I don't want to stretch myself too thin right before vacation. But yeah, thanks again to Dan and the handful of other folks that reached out either on Twitter or via email to point me in the right direction on the database switching stuff. At some point, I should definitely do a write-up on this because I've now collected together just about enough information that it feels like it's worthy of a blog post, or at least that's the story in the back of my head. I got to cross a certain threshold before I'm probably going to write a blog post. But yeah, that's a bit of what's up in my world. What's going on in your world?

+ +

STEPH: I love it. You're saying write a blog post into the mic, so then that way you know it's going to encourage you to write it later.

+ +

CHRIS: That’s the trick right there. [chuckles]

+ +

STEPH: Let's see, today's been a lovely day. It's been a lovely week in general. Today is especially lovely because it is thoughtbot’s Summit, and Summit is where we all gather. We do this once a year. So the whole team, all of us across all of our...I was going to say offices but now just across all of our home offices. And we get together, and we have a day filled with events, and we usually have a wonderful team that helps organize a bunch of events that then we get together for. So a number of those fun events are like paired chats, which is one of my favorites because I often talk to people that I haven't talked to in a long time or perhaps people that I haven't even met yet that have just recently joined the company. We also have lightning talks, and I know I'm very biased, but I think we have some of the best lightning talks. They are just hilarious. So I love our lightning talks. We're also doing escape rooms. Oh, speaking of which, there's a Harry Potter-themed murder mystery that's happening. We have Nintendo Switch parties and a professional tarot card reading, which I've never done, but I'm actually doing that later today after we're done chatting.

+ +

CHRIS: Wow, that is an adventurous day. And I like that it's fun, and it's connecting people and getting to know your teammates and all those nice things.

+ +

STEPH: Very much. I also have a hot take. I don't know if I've shared this with you, so I'm going to share it here with you on the mic in regards to this. So previous years, for Summit, we used to have more coding projects, too. They were often opt-in, but that's something that happened. And specifically, we have Ralphapalooza, which is our hackathon. And it recently came up where a number of us were talking about Ralphapalooza, and I have come to the potentially contentious point of view that I don't like hackathons. I'm not a fan of them.

+ +

CHRIS: Hot take. I like that you led in calling it a hot take, and then you provided said hot take, so I have to respond as if it's a very hot take.

+ +

STEPH: That's true. Maybe it's not a hot take. Maybe people disagree. What do you think? Do you like hackathons?

+ +

CHRIS: I have enjoyed them in the past. But I will say, particularly within the context of Summit or Ralphapalooza, I always felt a ton of pressure. It's so hard to right-size a project to that space, to that amount of time. You want to do something that's not trivial. You want to do something that at the end of it you're like, oh cool, I did that. Either it's like a novel thing that you're creating, or you're learning something new or whatever, but it's so hard to really do something meaningful in that amount of time. And often, people are shooting for the moon, and then they're just like, “Ah, so it's just a blank page right now. But behind the scenes, there's a machine learning algorithm that is generating the blank page. And we think with enough inputs to the model that it'll…” and it is actually super interesting work they did. But there's the wonderful pressure at the end to present, which I think is really useful. I like constraints. I like the presentations; they’re always enjoyable, even in a case where it's like, this project did not go well, let's talk about that. That's even fun. But it really is so hard to get right. I've never gone to a hackathon outside of thoughtbot, so I can't speak to that, but I know that I have heard folks having a negative opinion of them. And I don't know that I'm quite at the hot take level that you are, but it's complicated, if nothing else. It's a lot of fun sometimes. I particularly remember the Elm project that you and I worked on. Well, we worked in the same group. We didn't actually work together, but same idea. That was a lot of fun. I liked that.

+ +

STEPH: That’s a good point. Even within the context of Ralphapalooza, our hackathons are more...I’m going to use the word sustainable because they're nine-to-five hackathons where we are showing up; we are putting in the work. There is pressure, and we do want to present. But it's not one of those stay up all night and completely leave your family for a day or two to hack on some code. [laughs] Sorry, I'm throwing some shade right now. But even with that sustainable approach, I've always felt so much pressure. I enjoyed that green space and then getting to collaborate with people I don't typically collaborate with, but it still felt like there was a lot of pressure there, especially that presentation mode always made me nervous. Even if it is welcoming to say, “Hey, this didn't go well,” that doesn't necessarily feel great to present unless you are comfortable presenting that scenario. And I also really look forward to these company events as a way to connect and have some downtime and to just relax because then the rest of our days are often more stressful. So I want more company time for me to connect with colleagues but then also feel relaxed. So I was always, in the beginning, I was like, yeah, Ralphapalooza, woo, let’s go. And now I'm just like, nah, I'm good. I'd really just want a chill day with my colleagues.

+ +

CHRIS: Is there an option to go for a walk with friends? Because if so, I will be taking door number two.

+ +

STEPH: Cool. Well, I feel better having gotten that out into the ether now. But switching just a bit, there is something that I'm very excited about where we now have transcripts for each episode. This is something that you and I have been very excited about for a while and wanted to make happen but just weren't able to, but we now have them. And so people may have noticed them as we're adding them to the show notes. And I'm just so excited for a number of reasons, one, because there are a number of times that I have really wanted to search the shows or an episode for a particular topic and couldn't do so. So I'm just sitting there listening, trying to find a particular topic. There's also the fact that it will make the episodes more accessible. So for anyone that is hearing impaired or maybe if English isn't their first language, having it written down can make the episode more accessible. And there’s the massive SEO boost that's always a win. And then I don't know if this is going to happen, but I'm excited that transcripts may help us repurpose content because there's a number of our topics that I would love to see turned into blog posts, and I think having the transcript will make that easier.

+ +

CHRIS: Yeah. I'm equally super excited about the addition of transcripts, and across the line, SEO is cool, I think. Yeah, that sounds nice. Being able to reuse the content is very interesting to me because this is definitely my preferred medium. I find that I can just show up on the microphone, and it turns out I have opinions about a lot of stuff but trying to write a blog post is incredibly difficult for me. The small handful of good things that we might have collectively said over the years if we can turn those into more stuff that sounds great and honestly, just the ability to search for and find older episodes now based on like, I know we talked about inbox zero. I remember that was an episode, but I don't know which one, now that’s searchable, and that's a thing that we can find. I actually still use the Upcase search for…I know I said something. I know there was a weekly iteration where I talked about some topic. And I built the search on Upcase for me as the primary user because one, I'm often referencing content on Upcase, and I want to be able to find it more easily, so I made the search. I also put a SQL injection vulnerability into the search in my first implementation so, go me. But then I got rid of it shortly after.

+ +

STEPH: I love when people bring that energy of “I introduced this issue, go me,” because I find that very fun and also just very healthy in terms of we're going to make mistakes. And I have noticed a number of times at thoughtbot standup that whenever we make a mistake, or it’s like, I accidentally sent out real emails on production for a job that I thought I was testing on staging. Sharing those mistakes in a very positive light is a very honest way to approach it. So I just had to comment on that because I'm a big fan of that.

+ +

CHRIS: I'm glad you enjoyed my framing of it. I really enjoy that type of approach or way to communicate, although I think it is a delicate line. Like, I don't want to celebrate these sorts of things because an SQL injection vulnerability is a non-trivial thing. It shows up in tons of applications, and we need to take security seriously and all of that sort of stuff. But I think the version that I think is good for that type of thinking or communication is the psychological safety. If we're scared of admitting that we introduced a bug, that's bad. That's going to lead to worse outcomes longer term. And so having the shared communication style openness to like, yep, that happened yesterday. And there should be a certain amount of contrite in this where it’s like, I feel bad that I did that. I even feel worse because when it happened, I recognized that it happened, and then I tried to exploit it in development mode to prove it to myself, and I couldn't exploit it. So I was like, I feel doubly bad as a programmer today. I both introduced a bug, and I'm not even smart enough to exploit it. But I know that an uber lead hacker out there could, and so I got to fix it. But that sort of story is part of the game. It's a delicate equilibrium, but having the ability to talk about that and having a group that can have a conversation, I do think that's very important.

+ +

STEPH: Yeah, well said. I do think there's an important balance to strike there. Pivoting just a bit, we have a listener question, and this question comes from Benoit. Benoit wrote in to the show, “How do you properly implement a multi-step form in a boring Rails way?” I'm very interested in this question because I am working on a project that has a multi-step form. There are probably about maybe six, seven steps, and those steps can change based on different configurations. And our form is not implemented in a boring way at all. It's a very intricate, confusing design, I would say, which I think is fairly common when it comes to multi-step forms. I'm curious, what experience do you have with multi-step forms, and what's your general feeling with them?

+ +

CHRIS: Well, I happen to be working on one right now. So generally, I don't have an oh, I got this, I know the answer. This is one of those that I'm like; I feel like each time I reinvent it a little bit. But the version that I'm working on right now is an onboarding flow. So we create a user record, which at this point I only have email associated with, and then from there, when a user lands, they need to provide a bunch of profile information, and it is a requirement. They have to fill it out. We need to have all of it before we can actually start doing the real stuff of the application. And so, the way that I've ended up modeling it is interesting. I'm going to use the word Interesting. I think I like it, but I'm not sure. So I have this model; let’s call it a profile that we're going to associate with the user. And the profile has a bunch of fields: first name, last name, address, phone number, and a handful of other things. And again, I need to have these pieces of information. So I want those to be non-nullable columns. But as someone is walking through this form, I'm not going to have all the information. So there's going to be a progression. We'll get first name, then we get last name, and then we get the next piece of information. So I need a nullable storage, but I don't want to just put it into the session or something like that, which I think would be an option. So what I've done is I've introduced a secondary model. So this is a full ApplicationRecord database-backed model called partial profile. And it is almost identically the same interface as the profile, but each field is nullable. There's also a slight difference in that the profile field has an additional status column that talks about once we've gone through all of this, we can add some status and track other things. But yeah, that main difference of in the profile, everything is non-nullable, and the partial profile is nullable.

+ +

So then there's a workflowy object, a command object, as I like to have in my systems these days that handles the once they've gathered all their information, turn the partial profile into a profile, send it out to an external system that does some verification and some other lookups and things like that. And then, based on the status of that, mark the status of the profile. But one of the things that I was able to do is make that transition from partial profile to full profile. I'm doing that within a transaction. So if at any point anything fails within all of this, I can roll the whole thing back, and I'll be back to only having the partial profile, which was a very important thing. I would not want to have a partial profile and a profile because that's a bad state. But a lot of this for me is about data modeling and wanting to tell truths with the database and constrain what are the valid states of my application? So one solution would be to just have a profile model that has nullable columns for all of these fields. But man, do I hate that answer. So I went what feels like an extreme take of having two fundamentally different models, but that's where it's actually working out well. I'm able to share validations across them. So as new data is added, I can conditionally validate as new things are shared, and I'm able to share that via concern in the two models. So it's progressively getting more constrained as I add data to this thing. And then, in the background, there is a single controller that skips through all of the steps and has an update action that just keeps pushing data into this partial profile until, eventually, it becomes a profile. So that's focused specifically on the data model stuff. I think there are other aspects of a more workflowy type thing in Rails, but that's our thing. What do you think, good idea, bad idea, terrible idea?

+ +

STEPH: [chuckles] One, I love that you have this concrete example because I have some higher-level ideas around this particular question, but I didn't have a great example that I wanted to share. So I love that you have that, that we can talk through. I really, really like how you have found a way to represent the fact that each valid state of your application as you refer to it….so you have this concept of someone's going through the flow and their address can be nullable at this stage, but by the end of this flow, it shouldn't be nullable anymore. So you have that concept of a partial profile, and then it gets converted into a profile. I am intrigued by the fact that it's one controller because that is where I am feeling pain with the multi-step form that I'm working on where we have one very large controller that handles this entire...I'm going to call it a wizard since that's how it's referred to, and there are seven or eight different steps in this wizard. And the job of this controller is each time someone goes to a new step; this controller is trying to figure out okay; what step are you on based on the parameters that you have, based on some of the model attributes that are set? What step are you on, and what should we show you? And that has led to a very large method and then also complex, lots of conditional-based code. And instead, I would really like to flip that question around or essentially remove the what step am I on? And instead, ask what step is next? So instead, take the approach that each step of the form should have a one-to-one mapping to another controller. And that can get really hard because we're often conditioned to the idea that we should have a one-to-one correlation between each controller and an ActiveRecord model, but that's not necessarily what happens in our form.

+ +

You have the concept of a partial profile versus being able to map to a full profile. So I am very much in favor of the idea of trying to map each step of the form to a controller. So that, to me, makes the code more boring. It makes it more understandable. I can see what's happening for each step. But then it's not boring in terms that it requires creativity to say, okay, I don't have a perfect ActiveRecord model that maps to this controller, but what resourceful controller can I make instead? What is the domain object that I can put here instead? Maybe it's an ActiveModel object instead. So that way, we can apply ActiveRecord-like behavior to plain old Ruby objects, or maybe it's using a form object. That way, we can still validate all the fields that the user is providing to us, but that doesn't necessarily map directly to a full profile just yet. So I really like all the things that you've said. But I am intrigued by the approach of using a single controller. How's that feeling so far?

+ +

CHRIS: That part is actually feeling fine. So a couple of things you said in there stand out to me, one, where it's a very big controller. That is something that I would definitely avoid. And so, I have extracted other pieces. There is an object that I created, which at this point is just in-app models because I didn't know where else to put it, but it's called onboarding. And so the workflow that I'm trying to introduce, the resource maybe is what we would call it, is the idea of onboarding, but it's not an ActiveRecord level thing. At the ActiveRecord level, I have a profile and a partial profile, and then there's an account, and there's also a user. There are four different database level models that I want to think about. But fundamentally, from a user perspective, we're talking about onboarding. And so I have an object that is called onboarding, and it contains the logic around given the data that we have now, what step comes next? Is this a valid step? Should the user go back? Et cetera, et cetera. So that extraction is one piece that definitely makes sense. Also, thus far, mine is relatively straightforward in terms of I get data in, and I just need to update my partial profile record each time. So the update action is very straightforward. But I've done different versions of this where there are more complex things that happen. And so what I've done is basically make a splat route. So it's like onboarding/ and then the step name and that gets posted or gets put, I guess, along with everything else for the update. And so now the update says, “Well, if I'm updating for this, then handle it this way; otherwise, just update the profile record.” And so then I can extract maybe another command object that handles like, “Oh, when we're doing the address stuff, we actually have to do a little bit of a lookup and a cross-reference and some other things, but everything else is just throwing data into a database record.” And so that's another place where I would probably make an extraction, which is this specialized case of handling the update of the address is special. So I want to extract that, be able to test around that, et cetera. But fundamentally, the controller thing actually works out pretty well. The single controller with those sorts of extractions has worked out well for me.

+ +

STEPH: Okay, cool. Yeah, I can see how depending on how complex your multi-step form is, having it all in one controller and then extracting those smaller objects to then handle each step makes a lot of sense and feels very friendly to read, and is very testable. For the form that I'm working in, there are enough steps and enough complexity. I'd really love to break it out. In fact, that's something that we're working on right now is taking each of those chunks, each state of the form, and introducing a controller for it. So let's say if you are filling out an appointment and we need to get your consent for something, then we actually have a consent controller that's going to handle that part, that portion of it. And I'd be intrigued for your form if things got complicated enough that it’s the concept of onboarding or a wizard that leads us to having one controller because then we think of this one concept. But there are often four or five concepts that are then hiding within that general idea of an onboarding flow. So then maybe you get to the point that you have an onboarding address or something like that. So then you could break it out into something that still feels RESTful but then lets you have that very boring controller that does just enough and essentially behaves like a bi-directional linked list. So it knows, based on the route, it knows the step that it's on, and it knows where to go back, and then it knows the next step to go forward. And then that's all it's responsible for, so it doesn't have to also figure out what step am I currently on?

+ +

CHRIS: I like the bi-directional link list, dropping knowledge bombs right there.

+ +

STEPH: Pew-pew.

+ +

CHRIS: It's interesting. I don't necessarily feel...right now; I don't feel that pressure. I feel fine with the shape of the singular controller. This is perhaps not necessarily even a good thing, but I think my bias is always to think a lot about the URL structure and really strongly embrace the user point of view. I'm going through the workflow. I don't care if I'm picking from a calendar and setting up a date versus filling in an address field or how you're storing those on the back end; that’s your job, developer people. And I try as hard as I can to put myself in that mindset. And so the idea that there's this sequential thing that knows how to go back and forward and shows like, show which page we're on, that feels like it belongs in one controller in my mind, or I guess I'm fine with it being in one controller. And splitting it out feels almost more complicated in that I then need to share some of that logic across them, which is very doable by extracting some object that contains a logic of what goes back, what goes forward. But I think I like to align URL structure to how many controllers as opposed to anything else. And because I'm keeping a consistent URL structure where it's /onboarding/name /onboarding/address, and I'm stepping through in that way for all of those things, then it makes sense to me that those go to my onboardings controller. But I'm interested to see if I start to feel pain somewhere down the road because I expect this onboarding to get more complicated as time goes on. And will I bump my head on the ceiling? Probably. It seems likely. But for now, I'm liking it.

+ +

STEPH: Yeah, it certainly makes sense. It's one of those areas that you want to start small and then build out as it feels reasonable. But in regard to the URLs, I'm with you, where I very much want there to be a clean, nice URL for the user to see. And then we handle out any of those details on the back end since that is our work to do. But I am still envisioning that there is a clean URL. So it may be you have an onboarding/address and then onboarding/consent, borrowing from my previous example, but then that maps to where you have an onboarding namespaced controller that is then for an address or for consent. So you don't necessarily have an object that's having to be passed along that stores the state and the next step that the person is on. But that way, you do definitively know from the route okay, I am on this step. And so then that's how you get away from that question of what step am I on? Because that's already given to us based on the URL and then the controller. So then you only have to care about validating the input that's provided on that page, but then also being able to calculate dynamically okay, if this person needs to go back, what's the previous step and if they go forward, what's the next step?

+ +

CHRIS: What you're saying totally makes sense. And I'm now worried that I'm going to wake up a few days from now and look at my controllers and be like, I hate this. Why did I ever do this? I think the hesitation that I had, and this feels like a terrible reason, but in terms of what the config/routes.rb setup would be for this, it's namespace onboardings. And then within that, a bunch of singular routes and inside of that, inside that namespace, would be a bunch of singular resources so like, resource address, resource blah, blah. And I don't know why, but I don't like that. I don't like that. I don't like that. Now that I'm saying it out loud, I'm like, yeah, that actually would be a pretty clean mapping. And right now, I have implicitly what those available routes are but not explicitly. It also feels like there would be a real explosion of controllers there because there's a bunch of steps and growing in this controller or in this namespace. And they're all going to do the same thing, in my case at least, of just adding data in. But that's not a reason to not make...like, controllers are cheap; I should make controllers so, hmm.

+ +

STEPH: Yeah. So I think that's the part in my mind that maps to the boring part is because we are creating controllers. There's maybe an explosion of them, and it's boring. Like, the controllers don't do very much. And then that feels a little bit wrong to us because we're like, okay, I created this controller, it does very little. So maybe I should actually group this logic somewhere else. But I think that is the heart of it and how you stay boring is where you have just that code be so simple that it almost feels wrong.

+ +

CHRIS: That right there, that sound bite that we just had, that was a knowledge bomb drop, and I liked it. Now I've got to go back and refactor to the form that you're talking about because I am sold.

+ +

STEPH: Oh, I'm glad you like it. I am intrigued if you do refactor then what that would look like and how it feels. But I also totally understand you're busy, so if you don't, that's cool too, no pressure.

+ +

CHRIS: My honest answer is that I almost certainly won't refactor until I feel the pain. It's one of those things where like, okay, maybe I've now decided that this code is not the best, but the time to refactor it isn't when that code is just humming along working fine. It's a general thing that I think we share in terms of how we think about it. But the preemptive refactoring, I guess broadly speaking, I'm not a fan of preemptive factoring. I'm a fan of refactoring just in time or as we're feeling the pain, which is the counterpoint to that is let's not extract tech debt tickets because then they turn into preemptive refactoring again. It’s like, ah, I'm not really feeling...I'm not in there right now. But the version of the code that I have now is probably fine. I don't think it's a problem although I am convinced now of the boring way. I want to go back to the boring way, but it will feel like it's worth changing down the road when I feel any pressure in that system or need to revisit it. So it's like that. That's how I think about that sort of thing.

+ +

STEPH: Yeah, I wholeheartedly agree. It's one of those if you refactor...if this is a side project, if you want to refactor just for testing new software theories and then reflecting on what that new refactor looks like, that's awesome. In terms of any other refactors, then I wholeheartedly favor waiting until you feel that pain and it feels like the right thing to do; otherwise, it's unnecessary code turn. And while I strongly believe in experiments, I don't believe in putting teams through those personal experiments.

+ +

CHRIS: More hot takes from Steph. I like it.

+ +

STEPH: Circling back just a bit and talking about having one controller for each step of the form, that part I struggle with it frankly because it is hard to think about this is a concept, but what do I call this? Because it doesn't necessarily map to something necessarily in my database. There's a really great talk by Derek Prior that’s called In Relentless Pursuit of REST, where Derek does a great job of providing some inspiration around how to create routes that don't necessarily feel like they could be RESTful, or maybe they're following that more RPC format. And he does a great job of then turning around and saying, “Well, this is how we could think about, or this is how we could shift our thinking in turning this into a more RESTful route.” So then it does map to something that's meaningful in our domain. Because we have thoughtfully, or likely very thoughtfully, grouped this form together in a meaningful way to the user. So then that's inspiration right there to give us a way to name this thing because we are showing it to the user in a meaningful way. So then that means we can also give it a meaningful name. That’s all I got on multi-step forms. [laughs]

+ +

CHRIS: That feels like it was a lot. We've covered data models. We’ve covered controller structures. We fundamentally reoriented my thinking on the matter. I feel like we covered it.

+ +

STEPH: Yeah, I agree. Well, Benoit, thank you for sending in this question. I hope you found our discussion very helpful. And on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I'm at @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm. Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + After the last episode where database switching was discussed, a number of listeners reached out with thoughts. In particular, one listener gave a reproducible example of how to make things better. Chris talks about why he always moves errors to the left, and Steph gives a hot take where she admits that she is not a fan of hackathons and explains why.

+ +

Steph and Chris also share exciting Bike Shed show news in that we now have transcripts for each episode, and tackle another listener question asking, "How do you properly implement a multi-step form in a boring Rails way?” Chris talks about his experiences with multi-step forms and gives his own hot take on refactoring: he doesn't until he feels pain!

+ + + +

Transcript:

+ +

CHRIS: Happy Friday or whatever day it happens to be in your future situation.

+ +

STEPH: Happy day. [chuckles]

+ +

CHRIS: Happy day or night. I'm sorry, I'm done. [laughter]

+ +

STEPH: Shut up. [laughs]

+ +

Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I’m Steph Viccari.

+ +

CHRIS: And I’m Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been?

+ +

CHRIS: Happy Friday to you as well. My week's been good. It's been busy. I am taking next week off for a quick vacation. So it’s that…I think I've talked about this every time before I go on a vacation on the podcast, that focusing lens that going on vacation gives you. I want to make sure everything's buttoned up and ready to hand off, and I'm not going to be blocking anyone. And so, I always like the clarity that that brings. Because a lot of times I can look at well, there are infinity things to do, how do I pick? And now I'm like, no, but really, if I'm going to be gone for a week, I must pick. And so yeah, I'm now very excited to lean into vacation mode and relax for a bit.

+ +

STEPH: Yeah, that's awesome. I hear you. I always go into that same mode pre-vacation.

+ +

CHRIS: But in tech news, after the most recent episode that was released where we talked about the database switching stuff, a number of listeners were very kind and reached out with some thoughts. In particular, Dan Ott is one listener who reached out not only with just some generic thoughts, but he also gave a reproducible example of how to make things slightly better. So the particular thing that a few folks honed in on was the idea that I was describing the feeling of in production; we can occasionally run into these ActiveRecord read-only errors, which is a case where you have a GET request that happens to try to create or update a record. And as a result, you're going to get this ActiveRecord read-only because you're using the follower database, which has a read-only connection. All of that is fine, but ideally, we would want to catch those before production. We want to catch them in development. And broadly, the issue that we have here is that in production, our system is running in a different way. It's running with two different database connections, one for read-only, one for writing, and that's different than in development, where we're running with a single connection.

+ +

As an interesting thing, a lot of the stuff that I see on the internet is about using SQLite in development and then Postgres in production. And so that's an example of development production parity that we've really...I think thoughtbot is definitely a place that I internalize this very strongly. But you've got to have the same database, and especially because it's relatively straightforward to run Postgres locally, I'm always going to be running the same version of the database locally as in production. But in this case, I'm now getting this differentiation. And so what Dan and a handful of other folks highlighted was you can actually reproduce this functionality in development mode with a fun little trick where you end up creating a secondary connection to your development database, but you mark it as replica:true. And so, by doing that, Rails will establish a read-only connection. And then, all of the behavior that you configure for production can also be run in development. So now, as you're building out a new feature, and if you happen to implement a GET request that does some side effect in the database, that'll blow up in development as opposed to production, which is very exciting.

+ +

STEPH: Yeah, that’s awesome. I love that Dan reached out and shared this example with us. I actually haven't read through all of the details just yet. In fact, I just opened it up, and I started going through it, and there's a lot of really...it looks like a lot of great notes here and a really nice example that walks you through how to have that production parity locally. So this is really neat. I appreciate Dan sending this to us.

+ +

CHRIS: Yeah, this is a wonderful little artifact actually that’s interesting just in and of itself. We'll certainly include a link in the show notes to the gist that Dan shared. What's interesting...I think I knew of this, but I've never actually seen it before. This is a single-file Rails application, which is a very novel concept, but it's got a bundler/inline call at the very top. And then there's an inline gemfile block, and then a set of requires to pull in the relevant Rails stuff. And then it configures the database connection, configures a single controller or actually a handful of controllers, it looks like, and then it renders inline HTML. And so it has all of the pieces. And I didn't realize that at first, but then I pulled it down and I just ran it locally. So it’s just Ruby and then the file that this just represents, and suddenly I had a reproducible Rails app. I believe this is used in reporting issues to Rails so you can get the minimum reproducible test case. And that's why this works is, I think, the Rails core team, over time, has pushed on any of the edges that wouldn't have worked and made it so that this is possible. But it's a really neat little thing where it's this self-contained example. And so running this file just via Ruby does all of this stuff, installs everything that's necessary. And then, you can click around in the very minimal HTML page that it provides and see the examples of the edges that it's hitting. And again, this is in development mode, so it's pushing on that. But yeah, it's both a really interesting tip as to how to work with this and a really interesting way to communicate that tip—so double points to Gryffindor, aka Dan Ott.

+ +

STEPH: Double points to Gryffindor. I love it.

+ +

CHRIS: I’m cool. [laughs]

+ +

STEPH: That's very charming. [laughs] I've never seen anything like this either, in terms of one file that then can reproduce and run in a Rails app. Agreed, double points to Gryffindor, aka Dan.

+ +

CHRIS: Aka Dan.

+ +

STEPH: [chuckles] I hope Dan’s a Harry Potter fan.

+ +

CHRIS: I hope so. And I hope he's a Gryffindor, who knows? Maybe Ravenclaw. It's really up in the air. But the other thing that is interesting that I haven't yet figured out here is this works for development mode. I've tested it in development. It's great. I was able to remove the fix line that I had in my code where I had one of these breaking controller actions and run with this configuration in development mode. And then boom, it blew up in development, and I was like, yay, this is great. Move those errors to the left, as they say. But I realized there are some other edge cases, known ones actually. Another developer on the team mentioned something where he knows of a place that this is happening, but that code path isn't running right now just because it's a seasonal thing within the app. And I was like, oh, that's really interesting. I wish there were a way to test all the behavior. Oh, tests, that's what I need here. And so I tried to configure this in test mode, but I wasn't exactly clear on what was failing. But at a minimum, I know that the tests run in transaction, so I think that might make this more complicated because if you have two connections to the same database, but you have transactions, I feel like that might be conflating things, and it wouldn't necessarily map perfectly in. But if we could get that, that would be really great. Moving forward, any new development the development configuration will cover what I need. But retroactively, as I'm introducing the database switching to the application, it would be great if the test suite were a way to find these edge cases. So that's still an open question in my mind. But overall, the development fix is such a nice little addition to this world. And again, thank you so much to Dan for sending this in.

+ +

STEPH: Yeah, I agree; having this in tests would be wonderful. I am intrigued not having read through the full example that's been provided. But I'm wondering if this is one of those we default to read-only mode, although that feels like too much because we're often creating data for each test. So maybe we default to...yeah, you have to have both because you have to have your test set up where you're going to write data. So you can't default to just being in read-only mode. But then say you want to run a controller action or something else in a read-only mode. So then you would have to change your database connection for that action, and that sounds complicated. You also said something else I'm intrigued by. You said, “Move errors to the left.”

+ +

CHRIS: Yes. Now that you're asking me, I'm trying to remember the exact context. But it's the idea that there are different phases in your development and eventually getting to production life cycle, and so a bug that a user sees that's all the way to the right. That's as far along the development pipeline as it can be, and that's the worst case. You don't want a user to see a bug. So QA would be a step right before that. And if you can catch it in QA, you've moved it to the left, which is a good thing. But even better than that would be to catch it in your automated tests, and maybe even better than that would be static analysis that's running in your editor, and maybe even better than that is a type system or something like that. So the idea of moving to the left is to push those errors or when you're catching the errors closer to the point where you're actually introducing them. And that's just a general theme that I like or a Beyoncé song.

+ +

STEPH: I was just going to say, all right, move over, Beyoncé. There's another phrase in town, moving to the left. [laughs]

+ +

CHRIS: I'm really going for a lot of topical pop culture references today. That's what I'm about.

+ +

STEPH: We’ve got Harry Potter, Beyoncé. We've got to pull out one more at some point.

+ +

CHRIS: We'll see. I don't want to stretch myself too thin right before vacation. But yeah, thanks again to Dan and the handful of other folks that reached out either on Twitter or via email to point me in the right direction on the database switching stuff. At some point, I should definitely do a write-up on this because I've now collected together just about enough information that it feels like it's worthy of a blog post, or at least that's the story in the back of my head. I got to cross a certain threshold before I'm probably going to write a blog post. But yeah, that's a bit of what's up in my world. What's going on in your world?

+ +

STEPH: I love it. You're saying write a blog post into the mic, so then that way you know it's going to encourage you to write it later.

+ +

CHRIS: That’s the trick right there. [chuckles]

+ +

STEPH: Let's see, today's been a lovely day. It's been a lovely week in general. Today is especially lovely because it is thoughtbot’s Summit, and Summit is where we all gather. We do this once a year. So the whole team, all of us across all of our...I was going to say offices but now just across all of our home offices. And we get together, and we have a day filled with events, and we usually have a wonderful team that helps organize a bunch of events that then we get together for. So a number of those fun events are like paired chats, which is one of my favorites because I often talk to people that I haven't talked to in a long time or perhaps people that I haven't even met yet that have just recently joined the company. We also have lightning talks, and I know I'm very biased, but I think we have some of the best lightning talks. They are just hilarious. So I love our lightning talks. We're also doing escape rooms. Oh, speaking of which, there's a Harry Potter-themed murder mystery that's happening. We have Nintendo Switch parties and a professional tarot card reading, which I've never done, but I'm actually doing that later today after we're done chatting.

+ +

CHRIS: Wow, that is an adventurous day. And I like that it's fun, and it's connecting people and getting to know your teammates and all those nice things.

+ +

STEPH: Very much. I also have a hot take. I don't know if I've shared this with you, so I'm going to share it here with you on the mic in regards to this. So previous years, for Summit, we used to have more coding projects, too. They were often opt-in, but that's something that happened. And specifically, we have Ralphapalooza, which is our hackathon. And it recently came up where a number of us were talking about Ralphapalooza, and I have come to the potentially contentious point of view that I don't like hackathons. I'm not a fan of them.

+ +

CHRIS: Hot take. I like that you led in calling it a hot take, and then you provided said hot take, so I have to respond as if it's a very hot take.

+ +

STEPH: That's true. Maybe it's not a hot take. Maybe people disagree. What do you think? Do you like hackathons?

+ +

CHRIS: I have enjoyed them in the past. But I will say, particularly within the context of Summit or Ralphapalooza, I always felt a ton of pressure. It's so hard to right-size a project to that space, to that amount of time. You want to do something that's not trivial. You want to do something that at the end of it you're like, oh cool, I did that. Either it's like a novel thing that you're creating, or you're learning something new or whatever, but it's so hard to really do something meaningful in that amount of time. And often, people are shooting for the moon, and then they're just like, “Ah, so it's just a blank page right now. But behind the scenes, there's a machine learning algorithm that is generating the blank page. And we think with enough inputs to the model that it'll…” and it is actually super interesting work they did. But there's the wonderful pressure at the end to present, which I think is really useful. I like constraints. I like the presentations; they’re always enjoyable, even in a case where it's like, this project did not go well, let's talk about that. That's even fun. But it really is so hard to get right. I've never gone to a hackathon outside of thoughtbot, so I can't speak to that, but I know that I have heard folks having a negative opinion of them. And I don't know that I'm quite at the hot take level that you are, but it's complicated, if nothing else. It's a lot of fun sometimes. I particularly remember the Elm project that you and I worked on. Well, we worked in the same group. We didn't actually work together, but same idea. That was a lot of fun. I liked that.

+ +

STEPH: That’s a good point. Even within the context of Ralphapalooza, our hackathons are more...I’m going to use the word sustainable because they're nine-to-five hackathons where we are showing up; we are putting in the work. There is pressure, and we do want to present. But it's not one of those stay up all night and completely leave your family for a day or two to hack on some code. [laughs] Sorry, I'm throwing some shade right now. But even with that sustainable approach, I've always felt so much pressure. I enjoyed that green space and then getting to collaborate with people I don't typically collaborate with, but it still felt like there was a lot of pressure there, especially that presentation mode always made me nervous. Even if it is welcoming to say, “Hey, this didn't go well,” that doesn't necessarily feel great to present unless you are comfortable presenting that scenario. And I also really look forward to these company events as a way to connect and have some downtime and to just relax because then the rest of our days are often more stressful. So I want more company time for me to connect with colleagues but then also feel relaxed. So I was always, in the beginning, I was like, yeah, Ralphapalooza, woo, let’s go. And now I'm just like, nah, I'm good. I'd really just want a chill day with my colleagues.

+ +

CHRIS: Is there an option to go for a walk with friends? Because if so, I will be taking door number two.

+ +

STEPH: Cool. Well, I feel better having gotten that out into the ether now. But switching just a bit, there is something that I'm very excited about where we now have transcripts for each episode. This is something that you and I have been very excited about for a while and wanted to make happen but just weren't able to, but we now have them. And so people may have noticed them as we're adding them to the show notes. And I'm just so excited for a number of reasons, one, because there are a number of times that I have really wanted to search the shows or an episode for a particular topic and couldn't do so. So I'm just sitting there listening, trying to find a particular topic. There's also the fact that it will make the episodes more accessible. So for anyone that is hearing impaired or maybe if English isn't their first language, having it written down can make the episode more accessible. And there’s the massive SEO boost that's always a win. And then I don't know if this is going to happen, but I'm excited that transcripts may help us repurpose content because there's a number of our topics that I would love to see turned into blog posts, and I think having the transcript will make that easier.

+ +

CHRIS: Yeah. I'm equally super excited about the addition of transcripts, and across the line, SEO is cool, I think. Yeah, that sounds nice. Being able to reuse the content is very interesting to me because this is definitely my preferred medium. I find that I can just show up on the microphone, and it turns out I have opinions about a lot of stuff but trying to write a blog post is incredibly difficult for me. The small handful of good things that we might have collectively said over the years if we can turn those into more stuff that sounds great and honestly, just the ability to search for and find older episodes now based on like, I know we talked about inbox zero. I remember that was an episode, but I don't know which one, now that’s searchable, and that's a thing that we can find. I actually still use the Upcase search for…I know I said something. I know there was a weekly iteration where I talked about some topic. And I built the search on Upcase for me as the primary user because one, I'm often referencing content on Upcase, and I want to be able to find it more easily, so I made the search. I also put a SQL injection vulnerability into the search in my first implementation so, go me. But then I got rid of it shortly after.

+ +

STEPH: I love when people bring that energy of “I introduced this issue, go me,” because I find that very fun and also just very healthy in terms of we're going to make mistakes. And I have noticed a number of times at thoughtbot standup that whenever we make a mistake, or it’s like, I accidentally sent out real emails on production for a job that I thought I was testing on staging. Sharing those mistakes in a very positive light is a very honest way to approach it. So I just had to comment on that because I'm a big fan of that.

+ +

CHRIS: I'm glad you enjoyed my framing of it. I really enjoy that type of approach or way to communicate, although I think it is a delicate line. Like, I don't want to celebrate these sorts of things because an SQL injection vulnerability is a non-trivial thing. It shows up in tons of applications, and we need to take security seriously and all of that sort of stuff. But I think the version that I think is good for that type of thinking or communication is the psychological safety. If we're scared of admitting that we introduced a bug, that's bad. That's going to lead to worse outcomes longer term. And so having the shared communication style openness to like, yep, that happened yesterday. And there should be a certain amount of contrite in this where it’s like, I feel bad that I did that. I even feel worse because when it happened, I recognized that it happened, and then I tried to exploit it in development mode to prove it to myself, and I couldn't exploit it. So I was like, I feel doubly bad as a programmer today. I both introduced a bug, and I'm not even smart enough to exploit it. But I know that an uber lead hacker out there could, and so I got to fix it. But that sort of story is part of the game. It's a delicate equilibrium, but having the ability to talk about that and having a group that can have a conversation, I do think that's very important.

+ +

STEPH: Yeah, well said. I do think there's an important balance to strike there. Pivoting just a bit, we have a listener question, and this question comes from Benoit. Benoit wrote in to the show, “How do you properly implement a multi-step form in a boring Rails way?” I'm very interested in this question because I am working on a project that has a multi-step form. There are probably about maybe six, seven steps, and those steps can change based on different configurations. And our form is not implemented in a boring way at all. It's a very intricate, confusing design, I would say, which I think is fairly common when it comes to multi-step forms. I'm curious, what experience do you have with multi-step forms, and what's your general feeling with them?

+ +

CHRIS: Well, I happen to be working on one right now. So generally, I don't have an oh, I got this, I know the answer. This is one of those that I'm like; I feel like each time I reinvent it a little bit. But the version that I'm working on right now is an onboarding flow. So we create a user record, which at this point I only have email associated with, and then from there, when a user lands, they need to provide a bunch of profile information, and it is a requirement. They have to fill it out. We need to have all of it before we can actually start doing the real stuff of the application. And so, the way that I've ended up modeling it is interesting. I'm going to use the word Interesting. I think I like it, but I'm not sure. So I have this model; let’s call it a profile that we're going to associate with the user. And the profile has a bunch of fields: first name, last name, address, phone number, and a handful of other things. And again, I need to have these pieces of information. So I want those to be non-nullable columns. But as someone is walking through this form, I'm not going to have all the information. So there's going to be a progression. We'll get first name, then we get last name, and then we get the next piece of information. So I need a nullable storage, but I don't want to just put it into the session or something like that, which I think would be an option. So what I've done is I've introduced a secondary model. So this is a full ApplicationRecord database-backed model called partial profile. And it is almost identically the same interface as the profile, but each field is nullable. There's also a slight difference in that the profile field has an additional status column that talks about once we've gone through all of this, we can add some status and track other things. But yeah, that main difference of in the profile, everything is non-nullable, and the partial profile is nullable.

+ +

So then there's a workflowy object, a command object, as I like to have in my systems these days that handles the once they've gathered all their information, turn the partial profile into a profile, send it out to an external system that does some verification and some other lookups and things like that. And then, based on the status of that, mark the status of the profile. But one of the things that I was able to do is make that transition from partial profile to full profile. I'm doing that within a transaction. So if at any point anything fails within all of this, I can roll the whole thing back, and I'll be back to only having the partial profile, which was a very important thing. I would not want to have a partial profile and a profile because that's a bad state. But a lot of this for me is about data modeling and wanting to tell truths with the database and constrain what are the valid states of my application? So one solution would be to just have a profile model that has nullable columns for all of these fields. But man, do I hate that answer. So I went what feels like an extreme take of having two fundamentally different models, but that's where it's actually working out well. I'm able to share validations across them. So as new data is added, I can conditionally validate as new things are shared, and I'm able to share that via concern in the two models. So it's progressively getting more constrained as I add data to this thing. And then, in the background, there is a single controller that skips through all of the steps and has an update action that just keeps pushing data into this partial profile until, eventually, it becomes a profile. So that's focused specifically on the data model stuff. I think there are other aspects of a more workflowy type thing in Rails, but that's our thing. What do you think, good idea, bad idea, terrible idea?

+ +

STEPH: [chuckles] One, I love that you have this concrete example because I have some higher-level ideas around this particular question, but I didn't have a great example that I wanted to share. So I love that you have that, that we can talk through. I really, really like how you have found a way to represent the fact that each valid state of your application as you refer to it….so you have this concept of someone's going through the flow and their address can be nullable at this stage, but by the end of this flow, it shouldn't be nullable anymore. So you have that concept of a partial profile, and then it gets converted into a profile. I am intrigued by the fact that it's one controller because that is where I am feeling pain with the multi-step form that I'm working on where we have one very large controller that handles this entire...I'm going to call it a wizard since that's how it's referred to, and there are seven or eight different steps in this wizard. And the job of this controller is each time someone goes to a new step; this controller is trying to figure out okay; what step are you on based on the parameters that you have, based on some of the model attributes that are set? What step are you on, and what should we show you? And that has led to a very large method and then also complex, lots of conditional-based code. And instead, I would really like to flip that question around or essentially remove the what step am I on? And instead, ask what step is next? So instead, take the approach that each step of the form should have a one-to-one mapping to another controller. And that can get really hard because we're often conditioned to the idea that we should have a one-to-one correlation between each controller and an ActiveRecord model, but that's not necessarily what happens in our form.

+ +

You have the concept of a partial profile versus being able to map to a full profile. So I am very much in favor of the idea of trying to map each step of the form to a controller. So that, to me, makes the code more boring. It makes it more understandable. I can see what's happening for each step. But then it's not boring in terms that it requires creativity to say, okay, I don't have a perfect ActiveRecord model that maps to this controller, but what resourceful controller can I make instead? What is the domain object that I can put here instead? Maybe it's an ActiveModel object instead. So that way, we can apply ActiveRecord-like behavior to plain old Ruby objects, or maybe it's using a form object. That way, we can still validate all the fields that the user is providing to us, but that doesn't necessarily map directly to a full profile just yet. So I really like all the things that you've said. But I am intrigued by the approach of using a single controller. How's that feeling so far?

+ +

CHRIS: That part is actually feeling fine. So a couple of things you said in there stand out to me, one, where it's a very big controller. That is something that I would definitely avoid. And so, I have extracted other pieces. There is an object that I created, which at this point is just in-app models because I didn't know where else to put it, but it's called onboarding. And so the workflow that I'm trying to introduce, the resource maybe is what we would call it, is the idea of onboarding, but it's not an ActiveRecord level thing. At the ActiveRecord level, I have a profile and a partial profile, and then there's an account, and there's also a user. There are four different database level models that I want to think about. But fundamentally, from a user perspective, we're talking about onboarding. And so I have an object that is called onboarding, and it contains the logic around given the data that we have now, what step comes next? Is this a valid step? Should the user go back? Et cetera, et cetera. So that extraction is one piece that definitely makes sense. Also, thus far, mine is relatively straightforward in terms of I get data in, and I just need to update my partial profile record each time. So the update action is very straightforward. But I've done different versions of this where there are more complex things that happen. And so what I've done is basically make a splat route. So it's like onboarding/ and then the step name and that gets posted or gets put, I guess, along with everything else for the update. And so now the update says, “Well, if I'm updating for this, then handle it this way; otherwise, just update the profile record.” And so then I can extract maybe another command object that handles like, “Oh, when we're doing the address stuff, we actually have to do a little bit of a lookup and a cross-reference and some other things, but everything else is just throwing data into a database record.” And so that's another place where I would probably make an extraction, which is this specialized case of handling the update of the address is special. So I want to extract that, be able to test around that, et cetera. But fundamentally, the controller thing actually works out pretty well. The single controller with those sorts of extractions has worked out well for me.

+ +

STEPH: Okay, cool. Yeah, I can see how depending on how complex your multi-step form is, having it all in one controller and then extracting those smaller objects to then handle each step makes a lot of sense and feels very friendly to read, and is very testable. For the form that I'm working in, there are enough steps and enough complexity. I'd really love to break it out. In fact, that's something that we're working on right now is taking each of those chunks, each state of the form, and introducing a controller for it. So let's say if you are filling out an appointment and we need to get your consent for something, then we actually have a consent controller that's going to handle that part, that portion of it. And I'd be intrigued for your form if things got complicated enough that it’s the concept of onboarding or a wizard that leads us to having one controller because then we think of this one concept. But there are often four or five concepts that are then hiding within that general idea of an onboarding flow. So then maybe you get to the point that you have an onboarding address or something like that. So then you could break it out into something that still feels RESTful but then lets you have that very boring controller that does just enough and essentially behaves like a bi-directional linked list. So it knows, based on the route, it knows the step that it's on, and it knows where to go back, and then it knows the next step to go forward. And then that's all it's responsible for, so it doesn't have to also figure out what step am I currently on?

+ +

CHRIS: I like the bi-directional link list, dropping knowledge bombs right there.

+ +

STEPH: Pew-pew.

+ +

CHRIS: It's interesting. I don't necessarily feel...right now; I don't feel that pressure. I feel fine with the shape of the singular controller. This is perhaps not necessarily even a good thing, but I think my bias is always to think a lot about the URL structure and really strongly embrace the user point of view. I'm going through the workflow. I don't care if I'm picking from a calendar and setting up a date versus filling in an address field or how you're storing those on the back end; that’s your job, developer people. And I try as hard as I can to put myself in that mindset. And so the idea that there's this sequential thing that knows how to go back and forward and shows like, show which page we're on, that feels like it belongs in one controller in my mind, or I guess I'm fine with it being in one controller. And splitting it out feels almost more complicated in that I then need to share some of that logic across them, which is very doable by extracting some object that contains a logic of what goes back, what goes forward. But I think I like to align URL structure to how many controllers as opposed to anything else. And because I'm keeping a consistent URL structure where it's /onboarding/name /onboarding/address, and I'm stepping through in that way for all of those things, then it makes sense to me that those go to my onboardings controller. But I'm interested to see if I start to feel pain somewhere down the road because I expect this onboarding to get more complicated as time goes on. And will I bump my head on the ceiling? Probably. It seems likely. But for now, I'm liking it.

+ +

STEPH: Yeah, it certainly makes sense. It's one of those areas that you want to start small and then build out as it feels reasonable. But in regard to the URLs, I'm with you, where I very much want there to be a clean, nice URL for the user to see. And then we handle out any of those details on the back end since that is our work to do. But I am still envisioning that there is a clean URL. So it may be you have an onboarding/address and then onboarding/consent, borrowing from my previous example, but then that maps to where you have an onboarding namespaced controller that is then for an address or for consent. So you don't necessarily have an object that's having to be passed along that stores the state and the next step that the person is on. But that way, you do definitively know from the route okay, I am on this step. And so then that's how you get away from that question of what step am I on? Because that's already given to us based on the URL and then the controller. So then you only have to care about validating the input that's provided on that page, but then also being able to calculate dynamically okay, if this person needs to go back, what's the previous step and if they go forward, what's the next step?

+ +

CHRIS: What you're saying totally makes sense. And I'm now worried that I'm going to wake up a few days from now and look at my controllers and be like, I hate this. Why did I ever do this? I think the hesitation that I had, and this feels like a terrible reason, but in terms of what the config/routes.rb setup would be for this, it's namespace onboardings. And then within that, a bunch of singular routes and inside of that, inside that namespace, would be a bunch of singular resources so like, resource address, resource blah, blah. And I don't know why, but I don't like that. I don't like that. I don't like that. Now that I'm saying it out loud, I'm like, yeah, that actually would be a pretty clean mapping. And right now, I have implicitly what those available routes are but not explicitly. It also feels like there would be a real explosion of controllers there because there's a bunch of steps and growing in this controller or in this namespace. And they're all going to do the same thing, in my case at least, of just adding data in. But that's not a reason to not make...like, controllers are cheap; I should make controllers so, hmm.

+ +

STEPH: Yeah. So I think that's the part in my mind that maps to the boring part is because we are creating controllers. There's maybe an explosion of them, and it's boring. Like, the controllers don't do very much. And then that feels a little bit wrong to us because we're like, okay, I created this controller, it does very little. So maybe I should actually group this logic somewhere else. But I think that is the heart of it and how you stay boring is where you have just that code be so simple that it almost feels wrong.

+ +

CHRIS: That right there, that sound bite that we just had, that was a knowledge bomb drop, and I liked it. Now I've got to go back and refactor to the form that you're talking about because I am sold.

+ +

STEPH: Oh, I'm glad you like it. I am intrigued if you do refactor then what that would look like and how it feels. But I also totally understand you're busy, so if you don't, that's cool too, no pressure.

+ +

CHRIS: My honest answer is that I almost certainly won't refactor until I feel the pain. It's one of those things where like, okay, maybe I've now decided that this code is not the best, but the time to refactor it isn't when that code is just humming along working fine. It's a general thing that I think we share in terms of how we think about it. But the preemptive refactoring, I guess broadly speaking, I'm not a fan of preemptive factoring. I'm a fan of refactoring just in time or as we're feeling the pain, which is the counterpoint to that is let's not extract tech debt tickets because then they turn into preemptive refactoring again. It’s like, ah, I'm not really feeling...I'm not in there right now. But the version of the code that I have now is probably fine. I don't think it's a problem although I am convinced now of the boring way. I want to go back to the boring way, but it will feel like it's worth changing down the road when I feel any pressure in that system or need to revisit it. So it's like that. That's how I think about that sort of thing.

+ +

STEPH: Yeah, I wholeheartedly agree. It's one of those if you refactor...if this is a side project, if you want to refactor just for testing new software theories and then reflecting on what that new refactor looks like, that's awesome. In terms of any other refactors, then I wholeheartedly favor waiting until you feel that pain and it feels like the right thing to do; otherwise, it's unnecessary code turn. And while I strongly believe in experiments, I don't believe in putting teams through those personal experiments.

+ +

CHRIS: More hot takes from Steph. I like it.

+ +

STEPH: Circling back just a bit and talking about having one controller for each step of the form, that part I struggle with it frankly because it is hard to think about this is a concept, but what do I call this? Because it doesn't necessarily map to something necessarily in my database. There's a really great talk by Derek Prior that’s called In Relentless Pursuit of REST, where Derek does a great job of providing some inspiration around how to create routes that don't necessarily feel like they could be RESTful, or maybe they're following that more RPC format. And he does a great job of then turning around and saying, “Well, this is how we could think about, or this is how we could shift our thinking in turning this into a more RESTful route.” So then it does map to something that's meaningful in our domain. Because we have thoughtfully, or likely very thoughtfully, grouped this form together in a meaningful way to the user. So then that's inspiration right there to give us a way to name this thing because we are showing it to the user in a meaningful way. So then that means we can also give it a meaningful name. That’s all I got on multi-step forms. [laughs]

+ +

CHRIS: That feels like it was a lot. We've covered data models. We’ve covered controller structures. We fundamentally reoriented my thinking on the matter. I feel like we covered it.

+ +

STEPH: Yeah, I agree. Well, Benoit, thank you for sending in this question. I hope you found our discussion very helpful. And on that note, shall we wrap up?

+ +

CHRIS: Let's wrap up

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This show is produced and edited by Mandy Moore.

+ +

STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or review in iTunes as it helps other people find the show.

+ +

CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: And I'm at @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm. Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Byeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+x75I-ubb + + ]]> + + Chris Toomey + Steph Viccari + + + 294: Perfect Duplication + https://bikeshed.thoughtbot.com/294 + a36bdd2d-f3e0-47b3-8239-c1aa7041625f + Tue, 25 May 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris respond to a listener question about how to know if we're improving as developers. They discuss the heuristics they think about when it comes to improving, how they've helped the teams they've worked with plan for and measure their growth, and they share some specific tips for improving. + 45:31 + no + + + On this week's episode, Steph and Chris respond to a listener question about how to know if we're improving as developers. They discuss the heuristics they think about when it comes to improving, how they've helped the teams they've worked with plan for and measure their growth, and some specific tips for improving. +Rails Autoscale (https://railsautoscale.com/) +Rubular regex playground (https://rubular.com/) +The Pragmatic Programmer (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) +Go Ahead, Make a Mess by Sandi Metz (https://www.youtube.com/watch?v=xi3DClfGuqQ) +Confident Code - Avdi Grimm (https://www.youtube.com/watch?v=T8J0j2xJFgQ) +Therapeutic Refactoring - Katrina Owen (https://www.youtube.com/watch?v=J4dlF0kcThQ) +Refactoring, Good to Great - Ben Orenstein (https://www.youtube.com/watch?v=DC-pQPq0acs) +Transcript +CHRIS: There's something intriguing about the fact that we're having this conversation, but the thing that's recorded just starts at this arbitrary point in time, and it's usually us rambling about golden roads. But, I don't know; there's something existential about that. +STEPH: It's usually when someone says something very funny or starts singing [laughs], and then that's when we immediately: record, record! +CHRIS: I've never sung on the mic. That doesn't sound like a thing I would do. +STEPH: [laughs] +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. +STEPH: And I'm Steph Viccari. +CHRIS: And together, we're here to share a bit of what we've learned along the way. So Steph, how's your week going? +STEPH: Hey Chris, it's going really well. Normally I'm always like, wow, it's been such an exciting week, and it's been a pretty calm, chill week. It's been lovely. +CHRIS: That sounds nice actually in contrast to the "Well, it's been a week," that sort of intro of "I don't know, it's been fine. It can be really nice." +STEPH: By the time we get to this moment of the week, I either have stuff that I'm so excited to talk about and have a little bit of a therapy session with you or share something new that I've learned. I agree; it's nice to be like, yeah, it's been smooth sailing this whole week. In fact, it was smooth sailing enough that I decided to take on something that I've been meaning to tackle for a while but have just been avoiding it because I have strong feelings about this, which you know but we haven't talked about yet. But it comes down to managing emails and how many emails one should have that are either unread that are just existing. And I fall into the category of where I am less scrupulous about how many unread or managed emails that I have. But I decided that I'd had enough. So I used a really nice filter in Gmail where I said I want all emails that are before 2021 and also don't have a user label, so it's has:nouserlabels because then I know those are all the emails that I haven't labeled or assigned to a particular...I want to say folder, but they're not truly folders; they just look like folders. So they're essentially like untriaged or just emails that I've left hanging out in the ether. And then I just started deleting, and I got rid of all of those that hadn't been organized up until that point. And I was just like yep, you know if I haven't looked at it, it's that old, and I haven't given a label by this point, I'm just going to move on. If it's important, it will bubble back up. And I feel really good about it. +CHRIS: Wow, that is -- I like how you backed me into a corner. Obviously, I'm on the other side where I'm fastidiously managing my email, which I am, but you backed me into that corner here. So, yeah, that's true. Although the approach that you're taking of just deleting all the old email that's a different one than I would have taken [chuckles] so, I like it. It's the nuclear option. +STEPH: Okay, so now I need to qualify. When you delete an email, initially, I'm thinking it's going to trash, and so it's still technically there if I need to retrieve it and go back and find it. But you just said nuclear option, so maybe they're actually getting deleted. +CHRIS: They're going into the trash for 30 days; I think is the timeline. But after that, they will actually delete them. The archive is supposed to be the place where you put stuff I don't want to see you anymore. But did you archive or delete? +STEPH: Oh, I deleted. +CHRIS: Oh, wow. Yeah. All right, you went for it. [laughter] +STEPH: Yeah, and that's cool. And it's in trash. So I basically have a 30-day window where I'm like, oh, I made a mistake, and I need to search for something and find something and bring it back into my world; I can find it. If I haven't searched for it by then in 30 days, then I say, you know, thanks for the email, goodbye. [chuckles] And it'll come back if it needs to. +CHRIS: I like the approach. It would not be my approach, but I like the commitment to the cause. Although you still have...how many emails are still in your inbox now? +STEPH: Why do we have to play the numbers game? +CHRIS: [laughs] +STEPH: Can't we just talk about the progress that I have made? +CHRIS: What wonderful progress you've made, Steph. [laughter] Like, it doesn't matter what I think. What do you think about this? Are you happy with this? Does this make you feel more joy when you look into your email in the Marie Kondo sense? +STEPH: It does. I am excited that I went ahead and cleared all this because it just felt like craft. So I have taken what may be a very contentious approach to my email, where I treat it as this searchable space. So as things come in, I triage them, and I will label them, I will star them. I will either snooze them to make sure I don't miss the high actionable emails or something that's very important to me to act on quickly. But for the most part, then a lot of stuff will sit in that inbox area. So it becomes like this junk drawer. It's a very searchable junk drawer, thanks to Google. They've done a great job with that. And it feels nice to clear out that junk drawer. But I do have such an aversion to that very strong email inbox zero. I respect the heck out of it, but I have an aversion; I think from prior jobs where I was on a team, and we could easily get like 800 emails a day. My day all day was just triaging and responding to emails and writing emails. And so I think that just left a really bitter experience where now I just don't want to have to live that life where I'm constantly catering to what's in my inbox. +CHRIS: That's so many emails. +STEPH: It was so many emails. We were a team. It was a team inbox. So there were three of us managing this inbox. So if someone stepped away or if someone was away on vacation, we all had access to the same emails. But still, it was a lot of emails. +CHRIS: Yeah, inbox zero in a shared inbox that is a level that I have not gotten to but getting to inbox zero and actually maintaining that is very much a labor of love and something that I've had to invest in. And it's probably not worth it for most people. You could convince me that it is not worth it for me, that the effort I'm putting in is too much effort for not enough reward. Well, it's one of those things where I find the framing that it puts on it, like, okay, I need to process my email and get it to zero at least once a day. Having that lens makes me think about email in a different way. I unsubscribe from absolutely everything. The only things that are allowed to come into my email are things that I will act on that actually deserve my attention, and so it forces that, which I really like. And then it forces me to think about things. I have a tendency to really hold off on decisions. So I'm like, ah, okay. I can go see friends on Saturday or I can do something else. Friends like actual humans, not the TV show, although for the past year, it's definitely more of the TV show than the real people. But let's say there's a potential thing that I could do on the weekend and I have to decide on that. I have a real tendency to drag my feet and to wait for some magical information from the universe to help this decision be obvious to me. But it's never going to be obvious, and at some point, I just need to pick. And so for inbox zero, one of the things that comes out of it for me is that pressure and just forcing me to be like, dude, there's no perfect answer here, just pick something. You got to just pick something and not wasting multiple cycles rethinking the same decision over and over because that's my natural tendency. So in a way, it's, I don't know, almost like a meditative practice sort of thing. There's utility there for me, but it is an effort, and it's, again, arguably not worth it. Still, I do it. I like it. I'm a fan. I think it's worth it. +STEPH: I like how you argued both sides. I'm with you. I think it depends on the value that you get out of it. And then, as long as you are effective with whichever strategy you take, then that's really what matters. And I do appreciate the lens that it applies where if you are getting to inbox zero every day, then you are going to be very strict about who can send you emails about notifications that you're going to receive because you are trying to reduce the work that then you have to get to inbox zero. So I do very much admire that because there are probably -- I'm wasting a couple of minutes each day deleting notifications from chats or stuff that I know I'm not necessarily directly involved in and don't need action from me. And then I do get frustrated when I can't adjust those notification settings for that particular application, and I'm just subscribed to all of it. So some of it I feel like I can't change, and then some of it, I probably am wasting a few minutes. So I think there's totally value in both approaches. And I'm also saying that to try to justify my approach of my searchable inbox. [laughs] +CHRIS: There are absolutely reasons to go either way. And also, to come back to what I was saying a minute ago, it may have sounded like I'm a person who's just on top of this. I may have given that impression briefly. I think the only time this has actually worked in my life is when Gmail introduced snooze both in the mobile app and on the desktop. So this is sometime after Google's inbox product came out, and that was eventually shut down. So it's relatively recent because, man, I just snooze everything. That is the actual secret to achieving inbox zero, just to reach the end of the day and be like, nah, and just send all the emails to future me. And then future me wakes up and is like, "You know, it's first thing in the morning. I got a nice cup of coffee, and this is what you're going to do to me, past me?" So there's a little bit of internal strife there within my one human. But yeah, the snoozing is actually incredibly useful and probably the only way that I actually get things done and the same within any task management system that I have; maybe future me will do this. +STEPH: I think you and I both subscribed to the that's a future me problem. We just do it in very different ways. But switching gears a bit, how's your week been? +CHRIS: It's been good, pretty normal, doing some coding, normal developer things. Actually, there's one tool that I was revisiting this week that I'm not sure that we've actually talked about on the show before, but it's Rails Autoscale. Have you used that before? +STEPH: I don't think I have. It sounds very familiar, but I don't think I've used it. +CHRIS: It's a very nice, straightforward Heroku add-on that does exactly what you want it to do. It monitors your web and worker dynos and will scale up. But it uses a different heuristic than -- So Heroku has built-in autoscaling, but theirs is based on response time, which is, I think, a little bit laggier of a metric. Like if your response time has gotten bad, then you're already in trouble, whereas Rails Autoscale uses queue time. So how long is a request waiting before? I think it's at the Heroku router; it goes onto the dyno that's actually going to process the request? So I think that's what they're monitoring. I may be wrong on that. But from the website, they're looking at that, and you can configure it. They actually have a really nice configuration dashboard for configure between this range, so one to five dynos at most, and scale in this way up and in this way down. So like, how long should it wait? What's the threshold of queue time? Those sorts of things. So they have a default like just do the smart thing for me, and then they give you more control if your app happens to have a different shape of data, which is all really nice. And then I've been using that for a while, but I recently this week actually just turned on the worker side. And so now the workers will autoscale up and down as the Sidekiq queue -- I think for the Sidekiq side, it's also the queue time, so how long a job sits in the queue before getting picked up. And there are some extra niceties. It can actually infer the different queue names that you have. So if you have a critical, and then a mailer, and then a general as the three queues that Sidekiq is managing, you really want critical to not back up. So you can tell it to watch that one but ignore the normal one and only use -- Like, when critical is actually getting backed up, and all the other stuff is taken over then -- Again, it's got nice knobs and things, but mostly you can just say, "Turn it on and do the normal thing," and it'll do a very smart thing." +STEPH: That does sound really helpful. Just to revisit, so Heroku for autoscaling, when you turn that on, I think Heroku does it based on response times. So if you get into a specific percentile, then Heroku is going to scale up for you to then bring down that response time. But it sounds like with this tool, with Rails autoscaling, then you have additional knobs like the Sidekiq timing that you'd referenced. Are there some other knobs that you found really helpful? +CHRIS: Basically, there are two different sides of it. So web and background jobs are going to be handled differently within this tool, and you can actually turn them on or off individually, and you can also, within them, the configurations are specific to that type of thing. So for the web side, you have different values that you can set as the thresholds than you do on the Sidekiq side. Overall, the queue name only makes sense on the Sidekiq side, whereas on the web side, it's just like the web requests all of them 'Please make sure they're not spending too much time waiting for a dyno to actually start processing them.' But yeah, again, it's just a very straightforward tool that does the thing that it says on the tin. I enjoy it. It's one of those simple additions where it's like, yeah, I think I'm happy to pay for this because you're just going to save me a bunch of money every month, in theory. And actually, that side of it is certainly interesting, but more of my app will be responsive if there is any spike in traffic. There's still plenty of other performance things under the hood that I need to make better, but it was nice to just turn those on and be like, yeah, okay. I think everything's going to run a little better now. That seems nice. But yeah, otherwise, for me, a very straightforward week. +So I think actually shifting gears again, we have a listener question that we wanted to chat about. And this is one that both of us got very interested to chat about because there's a lot to this topic, but I'm happy to read it here. So the overall topic is improving as a developer, and the question goes, "How do you know you're improving as developers? Is your improvement consistent? Are there regressions? I find myself having very different views about code than I did even a year ago. In some cases, I write code now in a way that I would have criticized not too long ago. For example, I started writing a lot more comments. I used to think a well-named variable obviated the need for comments. While it feels like I'm improving, I have no way of measuring the improvement. It's only a gut feeling. Thanks. Love the show." And this comes from Tom. Thank you, Tom. Glad you enjoy the show. So, Steph, are you improving as a developer? +STEPH: I love this question. Thanks, Tom, for sending it in because it is one that I think about but haven't really verbalized, and so I'm really excited to dive into this. So am I improving as a developer? It comes down to, I mean, we first have to talk through definitions. Like, what does it mean to become a better developer? And then, we can talk through metrics and understanding how we're getting there. I also love the other questions, which I know we'll get to. I'm just excited. But are there any regressions? And also, in my mind, they already answered their own question. But I'm getting ahead of myself. So let me actually back up. So how do you know you're improving as a developer? There are a couple of areas that come to mind. And for me, these are probably more in that space of they still have a little bit of a gut feeling to them, but I'm going to try hard to walk that back into a more measurable state. So one of them could be that you're becoming more comfortable with the work that you're doing, so if you are implementing a new email flow or running task on production or writing tests that become second nature, those types of activities are starting to feel more comfortable. To me, that is already a sign of progress, that you are getting more comfortable in that area. It could be that time estimates are becoming more accurate. So perhaps, in the beginning, they're incredibly -- like, you don't have any idea. But as you are gaining experience and you're improving as a developer, you can provide more accurate estimates. +I also like to use the metric of how many people are coming to you for help, not necessarily in hard numbers, but I tend to notice when someone on a team is the person that everybody else goes to for help, maybe it's just on a specific topic, maybe it's for the application in general. But I take that as a sign that someone is becoming very knowledgeable in the area, and that way, they're showing that they're improving as a developer, and other people are noticing that and then going to them for help. Those are a couple of the ones that I have. I have some more, but I'd love to hear your thoughts. +CHRIS: I think if nothing else, starting with how would we even measure this? Because I do agree it's going to be a bit loose. Unfortunately, I don't believe that there are metrics that we can use for this. So the idea of how many thousand lines of codes do you write a month? Like, that's certainly not the one I want to go with. Or, how many pull requests? Anything like that is going to get gamified too quickly. And so it's really hard to actually define truly quantifiable metrics. I have three in mind that scale the feedback loop length of time. So the first is just speed. Like, how quickly are you able to do the same tasks? So I need to build out a page in Rails. I need a route; I need a controller. I need a feature spec, those sort of things. Those tasks that come up over and over: are you getting faster with those? That's a way to measure. And there's an adage that I think comes from biking, professional cycling, that it never gets any easier; you just go faster. And so the idea is you're doing the same work over time, but you just get a little bit faster, and you're always trying that edge of your capabilities. And so that idea of it never gets any easier, but you are getting faster. I like that framing. We should be doing the same work. We should never get too good for building a crud app. That's my official stance on the matter; thank you very much. But yeah, so that's speed. I think that is a meaningful thing to keep an eye on and your ability to actually deliver features in a timely fashion. +The next one would be how robust are the things that you're building? What's the bug count? How regularly do you have to revisit something that you've built to change it, to tweak it either because it doesn't exactly match the intent of the feature that you're developing or because there's an actual bug in it? It turns out this thing that we do is very hard. There are so many moving pieces and getting the design right and getting the functionality just right and handling user input, man, that's tricky. Users will just send anything. And so that core idea of robustness that's going to be more on a week scale sort of thing. So there's a little bit of latency in that measure, whereas speed that's a pretty direct measure. +The third one is…I don't know how to frame this, but the idea of being able to revisit your code either yourself or someone else. So if you've written some code, you tried to solve a problem; you tried to encode whatever knowledge you had at the given time in the code. And then when you come back three months later, how easy is it to revisit that code, to change it, to extend it either for yourself (because at that point you've forgotten everything) or for someone else on the team? And so the more that you're writing code that is very easy to extend, that is very easy to revisit and reload that context into your head, how closely the code maps to the actual domain context I think that's a measure as well that I'm really interested in, but there's the most lag in that one. It's like, yeah, months later, did you do a good job? And so the more time you spend, the more you'll have a measure of that, but that's definitely the laggiest of the measures that I have in mind. +STEPH: I love that adage that you shared that it never gets easier, but you get faster. That feels so relevant. I really like that. And then I hadn't considered the robustness. That's a really nice one, too, in terms of how often do you have to go back and revisit issues that you've added? +CHRIS: You just write code without bugs; that's why you don't think about it. +STEPH: [laughs] Oh, if only that were true. +CHRIS: Yeah, if only that were true of any of us. +STEPH: To keep adding to the list, there are a couple more that come to mind too. I'd mentioned the idea that certain tasks become easier. There's also the capability or the level of comfort in taking on that new, big, scary, unknown task. So there is something on the Teams' board where you're like, I have no idea how to do that, but I have confidence that I can figure it out. I think that is a really big sign that you are growing as a developer because you understand the tools that'll get you to that successful point. And maybe that means persuading someone else to help you; maybe it means looking elsewhere for resources. But you at least know how to get there, which then follows up on your ability to unblock yourself. So if you are in that state of I just don't know what to do next, maybe it's Googling, or maybe it is reaching out for help, but either way, you keep something moving forward instead of just letting it sit there. +Another area that I've seen myself and other people grow as developers is our ability to reason about quality and speed. It's something that I feel you, and I talk about pretty often here on the show, but it comes down to our ability to not just write code but then to also make good decisions on behalf of the company that we are working for and the team that we're working with and understanding what matters in terms of what features really need to be part of this MVP? Where can we make compromises? And then figuring out where can we make compromises to get this out to market? But what's really important then for circling back to your idea of revisiting the code, we want code that we can still come back and trust and then easily maintain and make updates to. And then I feel like I'm rambling, but I have a couple more. Shall I keep going? +CHRIS: Keep going. Those are great. +STEPH: All right. So for the others, there's an increase in responsibilities that I notice. So, in addition to people coming to you more often for help, then it could be that you are receiving more responsibilities. Maybe you are taking on specific ownership of the codebase or a particular part of the team processes. Then that also shows that you are improving and that people would like you to take leadership or ownership of certain areas. And then this one, I am throwing it in here, but your ability to run a meeting. Because I think that's an important part of being a good developer is to also be able to run a meeting with your colleagues and for that to be a productive meeting. +CHRIS: Cool. I like that one. I think I want to build on that because I think the core idea of being able to run a meeting well is communication. And I think there's one level of doing this job where it's just about doing the job. It's just about writing the code, maybe some amount of translating a specification or a ticket or whatever it is into the actual code that you need to write. But then how well can you communicate back out? How well when someone in project management says, "Hey, we want to build an aggregated search across the system that searches across our users, and our accounts, and our products, and our orders, and our everything." And you're like, "Okay. We can do that, but it will be hard. And let's talk about the trade-offs inherent in that and the different approaches and why we might pick one versus the other," being able to have that conversation requires a depth of knowledge in the technical but then also being able to understand the business needs and communicate across that boundary. And I think that's definitely an axis on which I enjoy pushing on as I'm continuing to work as a developer. +STEPH: Yeah, I'm with you. And I think being a consultant and working at thoughtbot heavily influences my concept of improving as a developer because as developers, it's not just our job to write code but to also be able to communicate and help make good decisions for the team and then collaborate with everyone else in the company versus just implement certain features as they come down the pipeline. So communication is incredibly important. And so I love that that's one of the areas that you highlighted. +CHRIS: Actually speaking of the communication thing, there's obviously the very human-centric part of that, but there's, I think, another facet of technical communication that is API design. When you're writing your code, what do you choose to expose and make accessible to collaborators? And I don't just mean API in the terms of a REST API that people are heading, but I mean a class that you have in your system. What are the private methods, and what are the public methods? And how do you think about the shape of it? What data do you expose? What do you not expose? And that can be really impactful because it allows how can you change things over time? The more that you hide, the more you can change. But then, if you don't allow your collaborators to access the bits that they need to be able to work with your system, that's an interesting one that comes to mind. It also aligns with, I don't think you were saying this exactly, but the idea of taking on more amorphous projects. So like, are you working within a system and adding a new feature, or are you designing a system? Are you architecting? The word architect that role can sometimes be complicated within organizations, but that idea of I'm starting fresh, and I'm building a system that others will then work within I think this idea of API design becomes really interesting in that context. What shape do you give to the system that we're working within, and what affordances? And all of that. And that's a very hard thing to get right. So it comes from experience of being like, I used some stuff in the past, and I hated it, so when I am the architect, I will build it better. And then you try, and you fail, and you're like, well, okay, but now I've learned. And then you try it, and then you fail for different reasons. But the seventh time you try, it may be just that time you get the public API just right on the first go. +STEPH: Seven times's a charm. That's how that goes, right? +CHRIS: That is my understanding, yes. +STEPH: I think something that is related to the idea of are you working in a structured space versus working in a new space and then how you develop that API for other people to work with. And then how do you identify when to write a test and what to test? That's another area that you were just making me think of is that I can tell when someone has experience with testing because they know what to test and what feels important to test. And essentially, it comes down to can I deploy with confidence? But there are a lot of times, especially if you're new to testing, that you're going to test everything, and you're going to have a lot of probably useless slow tests. But over time, you will start to realize what's really important. And I think that's one of the areas where then it does start to get harder to measure yourself as a developer because all of our jobs are different, and we work with different tech stacks, and we all have our unique responsibilities and goals. So it may be hard to say specifically like, "Oh, you're really good at X, Y, and Z, and that's how you know that you're improving as a developer." But I have more thoughts on that, which we'll get to in a moment where Tom mentioned that they don't have a way of measuring improvement. Shall I go ahead and jump ahead to I have no way of measuring that improvement, or shall we talk about regressions next? +CHRIS: I'm interested in your thoughts on the regressions question because it's not something that I've really thought about. But now that he's asked the question, I'm thinking about it. So yeah, what are your thoughts on that? +STEPH: My very quick answer is yes, [laughs] that there are regressions mainly because I respect that our brain can only make so much knowledge readily available to us, and then everything else goes into long-term storage. We can access it at some point, but it takes additional time, or maybe it takes some practice to recall that skill. So I do think there are regressions, and I think that's totally fine that we should be focused on what is serving us most at the moment and be okay with letting go of some of those other skills until we need to refine them again. +CHRIS: Yeah. I think there's definitely a truth to true knowledge and experience with, say, a framework or a language that can fade. So if I spend a lot of time away from JavaScript, and then I come back, I'm going to hit my head on a few low ceilings every once in a while for the first couple of days or weeks or whatever it is. It was interesting actually that Tom highlighted the idea of he used to not write comments, and now he writes more comments, and so that transition -- I think we've talked about comments enough so our general thinking on it. But I think it's totally reasonable for there to be a pendulum swing, and maybe there's a slight overcorrection. And you read some blog posts that tell you the truth of the world, and suddenly, absolutely no comments ever that's the rule. And then, later on, you're like, you know, I could really use a comment here. And so you go that way, and then you decide you know what? Comments are good, and you start writing a bunch of them. And so it's sort of weaving back and forth. Ideally, you're honing in on your own personal truth about comments. But that's just an interesting example to me because I certainly wouldn't consider that one a regression. +But then there's the bigger story of like, how do we approach building software? Ideally, that's what this podcast does at its best. We're not really a podcast about Rails or JavaScript or whatever it is we're talking about that week, but we're talking about how to build software well. And I think those core ideas feel like they're more permanent for me, or I feel like I'm changing those less. If anything, I feel like I'm ratcheting in on what I believe about good software. And there are some core ideas that I'm just refining over time, not done by any means, but it's that I don't feel like I'm fundamentally reevaluating those core ideas. Whereas I am picking up a new language and approaching a new framework and taking a different approach to what tools I'm using, that sort of thing. +STEPH: Yeah, I agree. The core concepts definitely feel more important and more applicable to all the future situations that we're going to be in. So those skills that may fall into the regression category feel appropriate because we are focused on the bigger picture versus how well do I remember this rejects library or something that won't serve us as well? So I agree. I am often focused more on how can I take this lesson and then apply it to other tech stacks or other teams and keep that with me? And I don't want that to regress. But it's okay if those other smaller, easily Google-able skills fall to the side. [laughs] +CHRIS: Wait, are you implying that you can't write rejects just off the top of your head or what's…? +STEPH: I don't think I could write any rejects off the top of my head. [laughter] +CHRIS: Fair. All right. You just go to rubular.com, hit enter, and then we iterate. +STEPH: Oh yeah. I don't want to use up valuable space for maintaining that sort of information. Rubular has it for me. I'm just going to go there. +CHRIS: I mean, as long as you have the index of the places you go on the internet to find the truth, then you don't need to store that truth. +STEPH: A moment ago, you mentioned where Tom highlights that they have different views about code that they wrote, even code that they wrote just like a year ago. And to me, that's a sign of growth in terms that you can look back on code that you have written and be like, well, maybe this would be different, or maybe this is still a good idea, but the fact that you are changing and then reevaluating, I think that is awesome because otherwise, if we aren't able to do that, then that is just a sign of being stagnant to me. We are sticking to the knowledge that we had a year ago, and we haven't grown since then versus that already shows that they have taken in new knowledge. So then that way, they can assess should I be adding comments? When should I add comments? Maybe I should swing away from that idea of this is a hard line of don't ever do this. I think I just have to mention it because there is one that I always feel so deeply about, DRY. DRY is the concept that gives me the most grief in terms that people just overuse it to the point that they do make code very hard to change. All right, that's my bit. I'll get off my pedestal. But DRY and comments are two things [chuckles] that both have their places. +CHRIS: I don't know if your experience was similar, but around DRY, I definitely have had the pendulum swing of how I feel about it. And I think again, that honing in thing. But initially, I think I read The Pragmatic Programmers, and they told me that DRY is important. And then I was like, absolutely, there will be no duplication anywhere, and then I felt some pain from that. And I've been in other systems and experienced places where people did remove duplication. I was like, oh, maybe it would have been better, and so I slowly got out of that mindset. But now I'm just in the place of like, I don't know, copy and paste not now, there was a period where I was like, just copy and paste everything. And then I was like, all right, I think there's a subtle line. There's a perfect amount of duplication, and that's the goal is to figure out that just perfect level. But for me, it really has been that evolution, and I was on one side, and then I was on the other side, and then I'm honing back in. And now I have my personal truth about duplication. +STEPH: Oh, me too. And I feel like I can be a little more negative about it because I was in the same spot. Because it's a rule, it's a rule that you can apply that when you are new to software development, there aren't that many rules that are so easy to apply to your codebase, but DRY is one of them. You can say, oh, that is duplication. I know exactly what that is, and I can extract it. And then it takes time for you to realize, okay, I can identify it, but just because it's there, it doesn't mean it's a bad thing. Perfect duplication, I like it. +CHRIS: Coming back to the idea of when we look back on our code six months, a year later, something like that, I think I believe the statement that we should always look back on our code and be like, oh, what was I doing there? But I think that arc should change over time. So early on in my career, six months later, I look back at my code, and I'm like, oh, goodness, what was happening there? I was very much a self-taught or blog internet-taught programmer just working on my own. I had no one else to talk to. So the stuff that I wrote early on was not good is how I will describe it. And then I got better, and then I got better, and I hope that I'm still getting better. And it's something that probably draws me to software development is I feel like there's always room to get a little bit better. Again, even back to that adage of it doesn't get any easier; you just go faster. Like, that's a version of getting better in my mind. So I hope that I can continue to feel that improvement and that ratcheting up. But I also hope that that arc is leveling off. There is an asymptotic approach to "good software developer." People in the audience, you can't see my air quotes, but I made air quotes there around good software developer. But that idea of I shouldn't look back probably this far into my career and look back at code from three months ago and be like, that's awful. That dude should be fired. I hope I'm not there. And so if you're measuring over time, what does your three months ago look back feel like? Oh, I feel like it's a little better. Still, you should look back and be like, oh, I probably would do that a little bit different given what I know now, what I've learned, but less so, I think. I don't know, what do you think about that? +STEPH: Yeah, that makes sense. And I'm also realizing I haven't looked back at my code that much since I am changing projects, and then I don't always have the opportunity to go back to that project and then revisit some of the code. But I do agree with the idea that if you're looking back at code that you've written a couple of months ago that you can see areas that you would improve, but I agree that you wouldn't want it to be something drastic. Like, you wouldn't want to see something that was more of an obvious security hole or performance issue. I think there are maybe certain metrics that I would use. I think they can still happen for sure because we're always learning, but there's also -- I may be taking this in a slightly different direction than you meant, but there's also a kindness filter that I also want us to apply to ourselves where if you're looking back three months ago to six years ago and you're like, oh, that's some rough code, Stephanie. But it's also like, yeah, but that code got me to where I am today, and I'm continuing to progress. So I appreciate who I was in the past, and I have continued to progress to who I am today and then who I will be. +CHRIS: What a wonderfully positive lens to put on it. Actually, that makes me think of one of -- We may be getting into rant territory here, but we talk a lot about imposter syndrome in the software development world. And I think there's a lot of utility because this is something that almost everyone experiences. But I think there's a corollary to it that we should talk about, which is a lot of people are coming into this industry, and they're like one year in, and the expectation that one year into a career that -- The thing that we do is not easy as far as I can tell. I haven't figured out how to make it easy. And the expectation that someone's going to be an expert that early on is just completely unreasonable in my mind. In my previous career, I was a mechanical engineer, and I went to school for four years. I actually went to school for five years, not because I was bad at school, but because I went to a place that had a co-op. And so I had both three different six months experiences working and four years of classroom education before I even got any job. And then I started doing things, and that's normal in that world. Whereas in the development world, it is so accessible, and I really feel like that's an absolutely wonderful thing. But the counterpoint of that is folks can jump into this career path very early on in their learning, and the expectation that they can immediately become experts or even in the short order I don't think is realistic. I think sometimes, when we talk about imposter syndrome, we may do a disservice. Like, it's not imposter syndrome. You're just new, and that's totally fine. And I hope you're working in an organization that is supportive of that and that has space for that and can help you grow in a purposeful way. In my mind, it's not realistic to expect everyone to be an expert a year in—end rant. +STEPH: Well, I would love to plus-one your rant and add to it a little bit because I completely agree. I also love the phrasing that you just said where it's not that you have imposter syndrome; it's just that you are new and that team should be supportive of people that are new and helping them grow and level up. I also think that's true for senior developers in terms that you are very good at certain skills, but there's always going to be some area of the web or some area of software development that you are new to, and that is also not imposter syndrome. But it's fine to assess your own skills and say, "That's something that I don't know how to do." And sometimes, I think that gets labeled as imposter syndrome, but it's not. It's someone just being genuine and reflecting on their current skills and saying, "I am good at a lot of stuff, but I don't know this one, and I am new to this area." And I think that's an important distinction to make because I still want -- even if you are not new in the sense that you are new to being a software engineer, but you still have that space to be new to something. +CHRIS: Yeah, it's an interesting, constantly evolving space. And so giving ourselves a little bit of permission to be beginners on various topics and for me, that's been an experience that's been continual. I think being a consultant, being a freelancer that impacts it a little bit. But nonetheless, even when I go into organizations, I'm like, oh, years in technology that only came out two years ago. That's pretty fresh. And so it's really hard to be an expert on something that's that new. +STEPH: Yeah. I think being new to a team has its own superpower. I don't know if we've talked about that before; if we haven't, we should talk about, it but I won't do that now. But being new is its own superpower. But I do want to pivot back to where Tom mentioned that I have no way of measuring that improvement. And I think that's a really great thing to recognize that you're not sure how to measure something. And my very first honest suggestion if you are feeling that way is to go ask your manager and ask them how they are measuring your improvement because that is their job is to understand where you're at and to understand your path as a developer on the team and then helping you set goals. +So since I'm a manager at thoughtbot, I'll go first, and I can share some ways that I help my team measure their own improvement. So one of the ways is that each time that we meet to discuss work, I listen to their challenges, and I take notes; I'm a heavy note-taker. And so once I have all those notes, then I can see are there any particular challenges that resurface? Are there any patterns, any areas where they continuously get stuck on? Or are they actually gaining confidence, and maybe something that would have given them trouble a couple of weeks ago is suddenly no big deal? And then I also see if they're able to unblock themselves. So a lot of what I do is far more listening, and I'm happy to then provide suggestions. But I am often just a space for someone to share what they are thinking, what they're going through, and then to walk through ideas and then provide suggestions if they would like some, and then they choose a suggestion that works best for them. And then we can revisit how did it go? So their ability to unblock themselves is also something that I'm looking for in terms of growth. And then together, we also set goals together, and then we measure that progress together. So it's all very transparent. And what areas would you like to improve, and then what areas would it be helpful for thoughtbot or as a consultant for you to improve? And then if I am fortunate enough to be on a project with them and see how they reason about quality and speed, how they communicate the type of features they're most comfortable to work on, and which tasks are more challenging for them, I also look to see do people enjoy working with them? That's a big area of growth and reflects communication, and reliability, and trust. And those are important areas for us to grow as developers. So those are some of the areas that I look to when I'm helping someone else measure their own improvement. +CHRIS: I really like that, the structured framing of it, and the way that you're able to give feedback and have that as a constant, continuous way to evaluate, define, measure, and then try and drive towards it. Flipping things around, I want to offer a slightly different thing, which isn't necessarily specifically in the question, but I think it's very close to the question of how do we actually improve as developers? What are the specific things that we can try and do? I'm going to offer a handful of ideas. I'd be super interested to hear what your ideas are. But one of the things that has been really valuable for me is exploring different languages and frameworks. I, without fail, find something in every new language or framework that I then bring back to the core things that I'm working with. And I've continued to work with Rails basically throughout my career, but everything else that I'm doing has informed the way that I work with Rails and the way that I think about building code. As specific examples, functional programming is a really interesting frame of mind, and Elm as a language is such a wonderful, gentle, friendly, fun introduction to functional programming because functional programming can get very abstract very easily. I've also worked with Haskell and Scala and other languages like that, and I find them much more difficult to work with. But Elm has a set of constraints and a user-centric approach that is just absolutely wonderful. So even if you never plan to build a production Elm application, I recommend Elm to absolutely everyone. +In terms of frameworks, depending on what you're using, maybe try and find the thing that's the exact opposite. If you're in the JavaScript space, I highly recommend Svelte. I think it's been very informative to me and altered a number of my opinions. A lot of those opinions were formed by React. And it's been interesting to observe my own thinking evolve in that space. But yeah, I think exploring, trying out, -- Have you ever used Lisp? Personally, I haven't, but that's one of the things that's on my list of that seems like it's got some different ideas in it. I wonder what I would learn from that. And so continually pushing on those edges and then bringing that back to the core work you're doing that's one of my favorite things. +Another is… It's actually two-fold here. Teaching is one, and I don't mean that in the grand sense; you don't have to be an instructor at a bootcamp or anything like that but even just within your organization trying to host a lunch and learn and teach a concept. Without fail, you have to understand something all the better to be able to teach it. Or as you try and teach something, someone may ask you a question that just shakes the foundation of what you know, and you're like, wow, I hadn't thought about it that way. And so teaching for me has just been this absolutely incredible forcing function for understanding something and being able to communicate about it again, that being one of the core things that I'm thinking about. And then the other facet sort of a related idea is pairing, pair with another developer, pair with a developer who is more senior than you on the team, pair with someone who is more junior than you, pair with someone who's at the same level, pair with the designer, pair with the developer, pair with a product manager, pair with everyone. I cannot get enough pairing. Well, I can, actually. I read a blog post recently about 100% pairing, and I've never gotten anywhere close to that number. But I think a better way to put it is I think pairing applies in so many more contexts than people may traditionally think of it. People sometimes like to compartmentalize and like, pairing is great for big architecture design, but that's about it. And my stance would be pairing is actually great at everything. It is very high bandwidth. It is exhausting, but I have found immense value in every pairing session I've ever had. So, yeah, those are some loose thoughts off the top of my head. Do you have any how to get better protips? +STEPH: Yeah, that's a wonderful list. And I'm not sure if this exactly applies because it's been a while since I have seen this talk, but there is a wonderful talk by Sandi Metz. I mean, all of her talks are wonderful, but this one is Go Ahead, Make a Mess. And I believe that Sandi refers to or highlights the idea of trying something new and then reflecting on how did it go? And that was one of the areas that I learned early on, one of the ways to help me progress quickly as a developer. Outside of the suggestions that you've already shared around lots of pairing that was one of the ways that I leveled up quickly is to iterate quickly. So I used to really focus on the code that I was writing, and I thought it needed to be perfect before my colleagues could review it. But then I realized that the sooner that I would push something out for feedback, then the faster I would get other more experienced developers' input, and then that helped me learn at an accelerated rate and then also ship more frequently. So I'd also encourage you to just go ahead and iterate quickly. We talk about with software in general, we want to iterate on the code that we are pushing up for other people to look at and then give us feedback on and then reflect on how did it go? What did we learn? What are some areas that we can improve? I feel like that self-evaluation is huge, and it's something that I know that I frankly don't do enough because one, it also prompts us to appreciate the progress that we have made but then also highlights areas where I feel strong in this area, but these are other areas that I want to work on. +CHRIS: While we're on the topic of talks that have been impactful in our journeys of leveling up as developers, I want to quickly list three that just always come to mind for me: Avdi Grimm's Confident Code, Katrina Owen's Therapeutic Refactoring, and Ben Orenstein's Refactoring from Good to Great. There's a theme if you look across those three talks. They're all about refactoring, which is interesting. That tells you some stories about what I believe about how good software is made. It's not made; it's refactored. That's my official belief, but yeah. +STEPH: Love it. That's also another great list. [laughs] For additional ways to level up, there are some very specific areas where it could be maybe do code katas or code exercises, or maybe you subscribe to certain newsletters, stay up to date with a language, new features that are being released. But outside of those very specific things, and if folks find this helpful, then maybe you and I can make a fun list, and then we could share that on Twitter as well. But I always go back to the idea of regardless of what level you're at in your career is to think about your specific goals, maybe if you are new to a team and you're new to software development, then maybe you just have very incremental goals of like, I want to learn how to write a test, or I want to learn how to get better at PR review or something very specific. But to have real growth, I think you have to first consider where it is that you want to go and then figure out a way to measure to get there. Circling back to some of the ways that I help my teammates measure that growth, that's one of the things that we talk about. If someone says, "Well, I want to get better at PR review," I'm like, "Great. What does that mean to you? Like, how do you get better at PR review? How can we actually measure this and make it something actionable versus just having this vague feeling of am I better?" I think I've ended up taking this a bit more broad as you were providing more specific examples on how to level up. But I like the examples that you've already provided around education and then trying something outside of your comfort zone. So what's coming to mind are more of those broad strategies of goal setting. +CHRIS: I think generally, you need that combination. You need how do I set the measure? How do I think about improvement? And then also ideally a handful of tactics that you can try out. So hopefully, we provided a nice balanced summary here in this episode. And hopefully, Tom, if you're listening, you have gotten some useful things out of this conversation. +STEPH: Yeah, this was fun. We managed to take this topic and make a whole episode out of this. So thanks, Tom, for sending in such a great topic. +CHRIS: Frankly, when I saw the topic, I was certain this was going to happen. [chuckles] This was an obvious one that was going to fill up the time for us. But yeah, with that, I think we've probably covered plenty here. Should we wrap up? +STEPH: I'm sure there's more, but sure, let's wrap up. +CHRIS: The show notes for this episode can be found at bikeshed.fm. +STEPH: This show is produced and edited by Mandy Moore. +CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. +STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me @SViccari on Twitter. +CHRIS: And I'm @christoomey. +STEPH: Or hosts@bikeshed.fm via email. +CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. +Both: Byeeeeeee. +Announcer: This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + On this week's episode, Steph and Chris respond to a listener question about how to know if we're improving as developers. They discuss the heuristics they think about when it comes to improving, how they've helped the teams they've worked with plan for and measure their growth, and some specific tips for improving.

+ + + +

Transcript

+ +

CHRIS: There's something intriguing about the fact that we're having this conversation, but the thing that's recorded just starts at this arbitrary point in time, and it's usually us rambling about golden roads. But, I don't know; there's something existential about that.

+ +

STEPH: It's usually when someone says something very funny or starts singing [laughs], and then that's when we immediately: record, record!

+ +

CHRIS: I've never sung on the mic. That doesn't sound like a thing I would do.

+ +

STEPH: [laughs]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So Steph, how's your week going?

+ +

STEPH: Hey Chris, it's going really well. Normally I'm always like, wow, it's been such an exciting week, and it's been a pretty calm, chill week. It's been lovely.

+ +

CHRIS: That sounds nice actually in contrast to the "Well, it's been a week," that sort of intro of "I don't know, it's been fine. It can be really nice."

+ +

STEPH: By the time we get to this moment of the week, I either have stuff that I'm so excited to talk about and have a little bit of a therapy session with you or share something new that I've learned. I agree; it's nice to be like, yeah, it's been smooth sailing this whole week. In fact, it was smooth sailing enough that I decided to take on something that I've been meaning to tackle for a while but have just been avoiding it because I have strong feelings about this, which you know but we haven't talked about yet. But it comes down to managing emails and how many emails one should have that are either unread that are just existing. And I fall into the category of where I am less scrupulous about how many unread or managed emails that I have. But I decided that I'd had enough. So I used a really nice filter in Gmail where I said I want all emails that are before 2021 and also don't have a user label, so it's has:nouserlabels because then I know those are all the emails that I haven't labeled or assigned to a particular...I want to say folder, but they're not truly folders; they just look like folders. So they're essentially like untriaged or just emails that I've left hanging out in the ether. And then I just started deleting, and I got rid of all of those that hadn't been organized up until that point. And I was just like yep, you know if I haven't looked at it, it's that old, and I haven't given a label by this point, I'm just going to move on. If it's important, it will bubble back up. And I feel really good about it.

+ +

CHRIS: Wow, that is -- I like how you backed me into a corner. Obviously, I'm on the other side where I'm fastidiously managing my email, which I am, but you backed me into that corner here. So, yeah, that's true. Although the approach that you're taking of just deleting all the old email that's a different one than I would have taken [chuckles] so, I like it. It's the nuclear option.

+ +

STEPH: Okay, so now I need to qualify. When you delete an email, initially, I'm thinking it's going to trash, and so it's still technically there if I need to retrieve it and go back and find it. But you just said nuclear option, so maybe they're actually getting deleted.

+ +

CHRIS: They're going into the trash for 30 days; I think is the timeline. But after that, they will actually delete them. The archive is supposed to be the place where you put stuff I don't want to see you anymore. But did you archive or delete?

+ +

STEPH: Oh, I deleted.

+ +

CHRIS: Oh, wow. Yeah. All right, you went for it. [laughter]

+ +

STEPH: Yeah, and that's cool. And it's in trash. So I basically have a 30-day window where I'm like, oh, I made a mistake, and I need to search for something and find something and bring it back into my world; I can find it. If I haven't searched for it by then in 30 days, then I say, you know, thanks for the email, goodbye. [chuckles] And it'll come back if it needs to.

+ +

CHRIS: I like the approach. It would not be my approach, but I like the commitment to the cause. Although you still have...how many emails are still in your inbox now?

+ +

STEPH: Why do we have to play the numbers game?

+ +

CHRIS: [laughs]

+ +

STEPH: Can't we just talk about the progress that I have made?

+ +

CHRIS: What wonderful progress you've made, Steph. [laughter] Like, it doesn't matter what I think. What do you think about this? Are you happy with this? Does this make you feel more joy when you look into your email in the Marie Kondo sense?

+ +

STEPH: It does. I am excited that I went ahead and cleared all this because it just felt like craft. So I have taken what may be a very contentious approach to my email, where I treat it as this searchable space. So as things come in, I triage them, and I will label them, I will star them. I will either snooze them to make sure I don't miss the high actionable emails or something that's very important to me to act on quickly. But for the most part, then a lot of stuff will sit in that inbox area. So it becomes like this junk drawer. It's a very searchable junk drawer, thanks to Google. They've done a great job with that. And it feels nice to clear out that junk drawer. But I do have such an aversion to that very strong email inbox zero. I respect the heck out of it, but I have an aversion; I think from prior jobs where I was on a team, and we could easily get like 800 emails a day. My day all day was just triaging and responding to emails and writing emails. And so I think that just left a really bitter experience where now I just don't want to have to live that life where I'm constantly catering to what's in my inbox.

+ +

CHRIS: That's so many emails.

+ +

STEPH: It was so many emails. We were a team. It was a team inbox. So there were three of us managing this inbox. So if someone stepped away or if someone was away on vacation, we all had access to the same emails. But still, it was a lot of emails.

+ +

CHRIS: Yeah, inbox zero in a shared inbox that is a level that I have not gotten to but getting to inbox zero and actually maintaining that is very much a labor of love and something that I've had to invest in. And it's probably not worth it for most people. You could convince me that it is not worth it for me, that the effort I'm putting in is too much effort for not enough reward. Well, it's one of those things where I find the framing that it puts on it, like, okay, I need to process my email and get it to zero at least once a day. Having that lens makes me think about email in a different way. I unsubscribe from absolutely everything. The only things that are allowed to come into my email are things that I will act on that actually deserve my attention, and so it forces that, which I really like. And then it forces me to think about things. I have a tendency to really hold off on decisions. So I'm like, ah, okay. I can go see friends on Saturday or I can do something else. Friends like actual humans, not the TV show, although for the past year, it's definitely more of the TV show than the real people. But let's say there's a potential thing that I could do on the weekend and I have to decide on that. I have a real tendency to drag my feet and to wait for some magical information from the universe to help this decision be obvious to me. But it's never going to be obvious, and at some point, I just need to pick. And so for inbox zero, one of the things that comes out of it for me is that pressure and just forcing me to be like, dude, there's no perfect answer here, just pick something. You got to just pick something and not wasting multiple cycles rethinking the same decision over and over because that's my natural tendency. So in a way, it's, I don't know, almost like a meditative practice sort of thing. There's utility there for me, but it is an effort, and it's, again, arguably not worth it. Still, I do it. I like it. I'm a fan. I think it's worth it.

+ +

STEPH: I like how you argued both sides. I'm with you. I think it depends on the value that you get out of it. And then, as long as you are effective with whichever strategy you take, then that's really what matters. And I do appreciate the lens that it applies where if you are getting to inbox zero every day, then you are going to be very strict about who can send you emails about notifications that you're going to receive because you are trying to reduce the work that then you have to get to inbox zero. So I do very much admire that because there are probably -- I'm wasting a couple of minutes each day deleting notifications from chats or stuff that I know I'm not necessarily directly involved in and don't need action from me. And then I do get frustrated when I can't adjust those notification settings for that particular application, and I'm just subscribed to all of it. So some of it I feel like I can't change, and then some of it, I probably am wasting a few minutes. So I think there's totally value in both approaches. And I'm also saying that to try to justify my approach of my searchable inbox. [laughs]

+ +

CHRIS: There are absolutely reasons to go either way. And also, to come back to what I was saying a minute ago, it may have sounded like I'm a person who's just on top of this. I may have given that impression briefly. I think the only time this has actually worked in my life is when Gmail introduced snooze both in the mobile app and on the desktop. So this is sometime after Google's inbox product came out, and that was eventually shut down. So it's relatively recent because, man, I just snooze everything. That is the actual secret to achieving inbox zero, just to reach the end of the day and be like, nah, and just send all the emails to future me. And then future me wakes up and is like, "You know, it's first thing in the morning. I got a nice cup of coffee, and this is what you're going to do to me, past me?" So there's a little bit of internal strife there within my one human. But yeah, the snoozing is actually incredibly useful and probably the only way that I actually get things done and the same within any task management system that I have; maybe future me will do this.

+ +

STEPH: I think you and I both subscribed to the that's a future me problem. We just do it in very different ways. But switching gears a bit, how's your week been?

+ +

CHRIS: It's been good, pretty normal, doing some coding, normal developer things. Actually, there's one tool that I was revisiting this week that I'm not sure that we've actually talked about on the show before, but it's Rails Autoscale. Have you used that before?

+ +

STEPH: I don't think I have. It sounds very familiar, but I don't think I've used it.

+ +

CHRIS: It's a very nice, straightforward Heroku add-on that does exactly what you want it to do. It monitors your web and worker dynos and will scale up. But it uses a different heuristic than -- So Heroku has built-in autoscaling, but theirs is based on response time, which is, I think, a little bit laggier of a metric. Like if your response time has gotten bad, then you're already in trouble, whereas Rails Autoscale uses queue time. So how long is a request waiting before? I think it's at the Heroku router; it goes onto the dyno that's actually going to process the request? So I think that's what they're monitoring. I may be wrong on that. But from the website, they're looking at that, and you can configure it. They actually have a really nice configuration dashboard for configure between this range, so one to five dynos at most, and scale in this way up and in this way down. So like, how long should it wait? What's the threshold of queue time? Those sorts of things. So they have a default like just do the smart thing for me, and then they give you more control if your app happens to have a different shape of data, which is all really nice. And then I've been using that for a while, but I recently this week actually just turned on the worker side. And so now the workers will autoscale up and down as the Sidekiq queue -- I think for the Sidekiq side, it's also the queue time, so how long a job sits in the queue before getting picked up. And there are some extra niceties. It can actually infer the different queue names that you have. So if you have a critical, and then a mailer, and then a general as the three queues that Sidekiq is managing, you really want critical to not back up. So you can tell it to watch that one but ignore the normal one and only use -- Like, when critical is actually getting backed up, and all the other stuff is taken over then -- Again, it's got nice knobs and things, but mostly you can just say, "Turn it on and do the normal thing," and it'll do a very smart thing."

+ +

STEPH: That does sound really helpful. Just to revisit, so Heroku for autoscaling, when you turn that on, I think Heroku does it based on response times. So if you get into a specific percentile, then Heroku is going to scale up for you to then bring down that response time. But it sounds like with this tool, with Rails autoscaling, then you have additional knobs like the Sidekiq timing that you'd referenced. Are there some other knobs that you found really helpful?

+ +

CHRIS: Basically, there are two different sides of it. So web and background jobs are going to be handled differently within this tool, and you can actually turn them on or off individually, and you can also, within them, the configurations are specific to that type of thing. So for the web side, you have different values that you can set as the thresholds than you do on the Sidekiq side. Overall, the queue name only makes sense on the Sidekiq side, whereas on the web side, it's just like the web requests all of them 'Please make sure they're not spending too much time waiting for a dyno to actually start processing them.' But yeah, again, it's just a very straightforward tool that does the thing that it says on the tin. I enjoy it. It's one of those simple additions where it's like, yeah, I think I'm happy to pay for this because you're just going to save me a bunch of money every month, in theory. And actually, that side of it is certainly interesting, but more of my app will be responsive if there is any spike in traffic. There's still plenty of other performance things under the hood that I need to make better, but it was nice to just turn those on and be like, yeah, okay. I think everything's going to run a little better now. That seems nice. But yeah, otherwise, for me, a very straightforward week.

+ +

So I think actually shifting gears again, we have a listener question that we wanted to chat about. And this is one that both of us got very interested to chat about because there's a lot to this topic, but I'm happy to read it here. So the overall topic is improving as a developer, and the question goes, "How do you know you're improving as developers? Is your improvement consistent? Are there regressions? I find myself having very different views about code than I did even a year ago. In some cases, I write code now in a way that I would have criticized not too long ago. For example, I started writing a lot more comments. I used to think a well-named variable obviated the need for comments. While it feels like I'm improving, I have no way of measuring the improvement. It's only a gut feeling. Thanks. Love the show." And this comes from Tom. Thank you, Tom. Glad you enjoy the show. So, Steph, are you improving as a developer?

+ +

STEPH: I love this question. Thanks, Tom, for sending it in because it is one that I think about but haven't really verbalized, and so I'm really excited to dive into this. So am I improving as a developer? It comes down to, I mean, we first have to talk through definitions. Like, what does it mean to become a better developer? And then, we can talk through metrics and understanding how we're getting there. I also love the other questions, which I know we'll get to. I'm just excited. But are there any regressions? And also, in my mind, they already answered their own question. But I'm getting ahead of myself. So let me actually back up. So how do you know you're improving as a developer? There are a couple of areas that come to mind. And for me, these are probably more in that space of they still have a little bit of a gut feeling to them, but I'm going to try hard to walk that back into a more measurable state. So one of them could be that you're becoming more comfortable with the work that you're doing, so if you are implementing a new email flow or running task on production or writing tests that become second nature, those types of activities are starting to feel more comfortable. To me, that is already a sign of progress, that you are getting more comfortable in that area. It could be that time estimates are becoming more accurate. So perhaps, in the beginning, they're incredibly -- like, you don't have any idea. But as you are gaining experience and you're improving as a developer, you can provide more accurate estimates.

+ +

I also like to use the metric of how many people are coming to you for help, not necessarily in hard numbers, but I tend to notice when someone on a team is the person that everybody else goes to for help, maybe it's just on a specific topic, maybe it's for the application in general. But I take that as a sign that someone is becoming very knowledgeable in the area, and that way, they're showing that they're improving as a developer, and other people are noticing that and then going to them for help. Those are a couple of the ones that I have. I have some more, but I'd love to hear your thoughts.

+ +

CHRIS: I think if nothing else, starting with how would we even measure this? Because I do agree it's going to be a bit loose. Unfortunately, I don't believe that there are metrics that we can use for this. So the idea of how many thousand lines of codes do you write a month? Like, that's certainly not the one I want to go with. Or, how many pull requests? Anything like that is going to get gamified too quickly. And so it's really hard to actually define truly quantifiable metrics. I have three in mind that scale the feedback loop length of time. So the first is just speed. Like, how quickly are you able to do the same tasks? So I need to build out a page in Rails. I need a route; I need a controller. I need a feature spec, those sort of things. Those tasks that come up over and over: are you getting faster with those? That's a way to measure. And there's an adage that I think comes from biking, professional cycling, that it never gets any easier; you just go faster. And so the idea is you're doing the same work over time, but you just get a little bit faster, and you're always trying that edge of your capabilities. And so that idea of it never gets any easier, but you are getting faster. I like that framing. We should be doing the same work. We should never get too good for building a crud app. That's my official stance on the matter; thank you very much. But yeah, so that's speed. I think that is a meaningful thing to keep an eye on and your ability to actually deliver features in a timely fashion.

+ +

The next one would be how robust are the things that you're building? What's the bug count? How regularly do you have to revisit something that you've built to change it, to tweak it either because it doesn't exactly match the intent of the feature that you're developing or because there's an actual bug in it? It turns out this thing that we do is very hard. There are so many moving pieces and getting the design right and getting the functionality just right and handling user input, man, that's tricky. Users will just send anything. And so that core idea of robustness that's going to be more on a week scale sort of thing. So there's a little bit of latency in that measure, whereas speed that's a pretty direct measure.

+ +

The third one is…I don't know how to frame this, but the idea of being able to revisit your code either yourself or someone else. So if you've written some code, you tried to solve a problem; you tried to encode whatever knowledge you had at the given time in the code. And then when you come back three months later, how easy is it to revisit that code, to change it, to extend it either for yourself (because at that point you've forgotten everything) or for someone else on the team? And so the more that you're writing code that is very easy to extend, that is very easy to revisit and reload that context into your head, how closely the code maps to the actual domain context I think that's a measure as well that I'm really interested in, but there's the most lag in that one. It's like, yeah, months later, did you do a good job? And so the more time you spend, the more you'll have a measure of that, but that's definitely the laggiest of the measures that I have in mind.

+ +

STEPH: I love that adage that you shared that it never gets easier, but you get faster. That feels so relevant. I really like that. And then I hadn't considered the robustness. That's a really nice one, too, in terms of how often do you have to go back and revisit issues that you've added?

+ +

CHRIS: You just write code without bugs; that's why you don't think about it.

+ +

STEPH: [laughs] Oh, if only that were true.

+ +

CHRIS: Yeah, if only that were true of any of us.

+ +

STEPH: To keep adding to the list, there are a couple more that come to mind too. I'd mentioned the idea that certain tasks become easier. There's also the capability or the level of comfort in taking on that new, big, scary, unknown task. So there is something on the Teams' board where you're like, I have no idea how to do that, but I have confidence that I can figure it out. I think that is a really big sign that you are growing as a developer because you understand the tools that'll get you to that successful point. And maybe that means persuading someone else to help you; maybe it means looking elsewhere for resources. But you at least know how to get there, which then follows up on your ability to unblock yourself. So if you are in that state of I just don't know what to do next, maybe it's Googling, or maybe it is reaching out for help, but either way, you keep something moving forward instead of just letting it sit there.

+ +

Another area that I've seen myself and other people grow as developers is our ability to reason about quality and speed. It's something that I feel you, and I talk about pretty often here on the show, but it comes down to our ability to not just write code but then to also make good decisions on behalf of the company that we are working for and the team that we're working with and understanding what matters in terms of what features really need to be part of this MVP? Where can we make compromises? And then figuring out where can we make compromises to get this out to market? But what's really important then for circling back to your idea of revisiting the code, we want code that we can still come back and trust and then easily maintain and make updates to. And then I feel like I'm rambling, but I have a couple more. Shall I keep going?

+ +

CHRIS: Keep going. Those are great.

+ +

STEPH: All right. So for the others, there's an increase in responsibilities that I notice. So, in addition to people coming to you more often for help, then it could be that you are receiving more responsibilities. Maybe you are taking on specific ownership of the codebase or a particular part of the team processes. Then that also shows that you are improving and that people would like you to take leadership or ownership of certain areas. And then this one, I am throwing it in here, but your ability to run a meeting. Because I think that's an important part of being a good developer is to also be able to run a meeting with your colleagues and for that to be a productive meeting.

+ +

CHRIS: Cool. I like that one. I think I want to build on that because I think the core idea of being able to run a meeting well is communication. And I think there's one level of doing this job where it's just about doing the job. It's just about writing the code, maybe some amount of translating a specification or a ticket or whatever it is into the actual code that you need to write. But then how well can you communicate back out? How well when someone in project management says, "Hey, we want to build an aggregated search across the system that searches across our users, and our accounts, and our products, and our orders, and our everything." And you're like, "Okay. We can do that, but it will be hard. And let's talk about the trade-offs inherent in that and the different approaches and why we might pick one versus the other," being able to have that conversation requires a depth of knowledge in the technical but then also being able to understand the business needs and communicate across that boundary. And I think that's definitely an axis on which I enjoy pushing on as I'm continuing to work as a developer.

+ +

STEPH: Yeah, I'm with you. And I think being a consultant and working at thoughtbot heavily influences my concept of improving as a developer because as developers, it's not just our job to write code but to also be able to communicate and help make good decisions for the team and then collaborate with everyone else in the company versus just implement certain features as they come down the pipeline. So communication is incredibly important. And so I love that that's one of the areas that you highlighted.

+ +

CHRIS: Actually speaking of the communication thing, there's obviously the very human-centric part of that, but there's, I think, another facet of technical communication that is API design. When you're writing your code, what do you choose to expose and make accessible to collaborators? And I don't just mean API in the terms of a REST API that people are heading, but I mean a class that you have in your system. What are the private methods, and what are the public methods? And how do you think about the shape of it? What data do you expose? What do you not expose? And that can be really impactful because it allows how can you change things over time? The more that you hide, the more you can change. But then, if you don't allow your collaborators to access the bits that they need to be able to work with your system, that's an interesting one that comes to mind. It also aligns with, I don't think you were saying this exactly, but the idea of taking on more amorphous projects. So like, are you working within a system and adding a new feature, or are you designing a system? Are you architecting? The word architect that role can sometimes be complicated within organizations, but that idea of I'm starting fresh, and I'm building a system that others will then work within I think this idea of API design becomes really interesting in that context. What shape do you give to the system that we're working within, and what affordances? And all of that. And that's a very hard thing to get right. So it comes from experience of being like, I used some stuff in the past, and I hated it, so when I am the architect, I will build it better. And then you try, and you fail, and you're like, well, okay, but now I've learned. And then you try it, and then you fail for different reasons. But the seventh time you try, it may be just that time you get the public API just right on the first go.

+ +

STEPH: Seven times's a charm. That's how that goes, right?

+ +

CHRIS: That is my understanding, yes.

+ +

STEPH: I think something that is related to the idea of are you working in a structured space versus working in a new space and then how you develop that API for other people to work with. And then how do you identify when to write a test and what to test? That's another area that you were just making me think of is that I can tell when someone has experience with testing because they know what to test and what feels important to test. And essentially, it comes down to can I deploy with confidence? But there are a lot of times, especially if you're new to testing, that you're going to test everything, and you're going to have a lot of probably useless slow tests. But over time, you will start to realize what's really important. And I think that's one of the areas where then it does start to get harder to measure yourself as a developer because all of our jobs are different, and we work with different tech stacks, and we all have our unique responsibilities and goals. So it may be hard to say specifically like, "Oh, you're really good at X, Y, and Z, and that's how you know that you're improving as a developer." But I have more thoughts on that, which we'll get to in a moment where Tom mentioned that they don't have a way of measuring improvement. Shall I go ahead and jump ahead to I have no way of measuring that improvement, or shall we talk about regressions next?

+ +

CHRIS: I'm interested in your thoughts on the regressions question because it's not something that I've really thought about. But now that he's asked the question, I'm thinking about it. So yeah, what are your thoughts on that?

+ +

STEPH: My very quick answer is yes, [laughs] that there are regressions mainly because I respect that our brain can only make so much knowledge readily available to us, and then everything else goes into long-term storage. We can access it at some point, but it takes additional time, or maybe it takes some practice to recall that skill. So I do think there are regressions, and I think that's totally fine that we should be focused on what is serving us most at the moment and be okay with letting go of some of those other skills until we need to refine them again.

+ +

CHRIS: Yeah. I think there's definitely a truth to true knowledge and experience with, say, a framework or a language that can fade. So if I spend a lot of time away from JavaScript, and then I come back, I'm going to hit my head on a few low ceilings every once in a while for the first couple of days or weeks or whatever it is. It was interesting actually that Tom highlighted the idea of he used to not write comments, and now he writes more comments, and so that transition -- I think we've talked about comments enough so our general thinking on it. But I think it's totally reasonable for there to be a pendulum swing, and maybe there's a slight overcorrection. And you read some blog posts that tell you the truth of the world, and suddenly, absolutely no comments ever that's the rule. And then, later on, you're like, you know, I could really use a comment here. And so you go that way, and then you decide you know what? Comments are good, and you start writing a bunch of them. And so it's sort of weaving back and forth. Ideally, you're honing in on your own personal truth about comments. But that's just an interesting example to me because I certainly wouldn't consider that one a regression.

+ +

But then there's the bigger story of like, how do we approach building software? Ideally, that's what this podcast does at its best. We're not really a podcast about Rails or JavaScript or whatever it is we're talking about that week, but we're talking about how to build software well. And I think those core ideas feel like they're more permanent for me, or I feel like I'm changing those less. If anything, I feel like I'm ratcheting in on what I believe about good software. And there are some core ideas that I'm just refining over time, not done by any means, but it's that I don't feel like I'm fundamentally reevaluating those core ideas. Whereas I am picking up a new language and approaching a new framework and taking a different approach to what tools I'm using, that sort of thing.

+ +

STEPH: Yeah, I agree. The core concepts definitely feel more important and more applicable to all the future situations that we're going to be in. So those skills that may fall into the regression category feel appropriate because we are focused on the bigger picture versus how well do I remember this rejects library or something that won't serve us as well? So I agree. I am often focused more on how can I take this lesson and then apply it to other tech stacks or other teams and keep that with me? And I don't want that to regress. But it's okay if those other smaller, easily Google-able skills fall to the side. [laughs]

+ +

CHRIS: Wait, are you implying that you can't write rejects just off the top of your head or what's…?

+ +

STEPH: I don't think I could write any rejects off the top of my head. [laughter]

+ +

CHRIS: Fair. All right. You just go to rubular.com, hit enter, and then we iterate.

+ +

STEPH: Oh yeah. I don't want to use up valuable space for maintaining that sort of information. Rubular has it for me. I'm just going to go there.

+ +

CHRIS: I mean, as long as you have the index of the places you go on the internet to find the truth, then you don't need to store that truth.

+ +

STEPH: A moment ago, you mentioned where Tom highlights that they have different views about code that they wrote, even code that they wrote just like a year ago. And to me, that's a sign of growth in terms that you can look back on code that you have written and be like, well, maybe this would be different, or maybe this is still a good idea, but the fact that you are changing and then reevaluating, I think that is awesome because otherwise, if we aren't able to do that, then that is just a sign of being stagnant to me. We are sticking to the knowledge that we had a year ago, and we haven't grown since then versus that already shows that they have taken in new knowledge. So then that way, they can assess should I be adding comments? When should I add comments? Maybe I should swing away from that idea of this is a hard line of don't ever do this. I think I just have to mention it because there is one that I always feel so deeply about, DRY. DRY is the concept that gives me the most grief in terms that people just overuse it to the point that they do make code very hard to change. All right, that's my bit. I'll get off my pedestal. But DRY and comments are two things [chuckles] that both have their places.

+ +

CHRIS: I don't know if your experience was similar, but around DRY, I definitely have had the pendulum swing of how I feel about it. And I think again, that honing in thing. But initially, I think I read The Pragmatic Programmers, and they told me that DRY is important. And then I was like, absolutely, there will be no duplication anywhere, and then I felt some pain from that. And I've been in other systems and experienced places where people did remove duplication. I was like, oh, maybe it would have been better, and so I slowly got out of that mindset. But now I'm just in the place of like, I don't know, copy and paste not now, there was a period where I was like, just copy and paste everything. And then I was like, all right, I think there's a subtle line. There's a perfect amount of duplication, and that's the goal is to figure out that just perfect level. But for me, it really has been that evolution, and I was on one side, and then I was on the other side, and then I'm honing back in. And now I have my personal truth about duplication.

+ +

STEPH: Oh, me too. And I feel like I can be a little more negative about it because I was in the same spot. Because it's a rule, it's a rule that you can apply that when you are new to software development, there aren't that many rules that are so easy to apply to your codebase, but DRY is one of them. You can say, oh, that is duplication. I know exactly what that is, and I can extract it. And then it takes time for you to realize, okay, I can identify it, but just because it's there, it doesn't mean it's a bad thing. Perfect duplication, I like it.

+ +

CHRIS: Coming back to the idea of when we look back on our code six months, a year later, something like that, I think I believe the statement that we should always look back on our code and be like, oh, what was I doing there? But I think that arc should change over time. So early on in my career, six months later, I look back at my code, and I'm like, oh, goodness, what was happening there? I was very much a self-taught or blog internet-taught programmer just working on my own. I had no one else to talk to. So the stuff that I wrote early on was not good is how I will describe it. And then I got better, and then I got better, and I hope that I'm still getting better. And it's something that probably draws me to software development is I feel like there's always room to get a little bit better. Again, even back to that adage of it doesn't get any easier; you just go faster. Like, that's a version of getting better in my mind. So I hope that I can continue to feel that improvement and that ratcheting up. But I also hope that that arc is leveling off. There is an asymptotic approach to "good software developer." People in the audience, you can't see my air quotes, but I made air quotes there around good software developer. But that idea of I shouldn't look back probably this far into my career and look back at code from three months ago and be like, that's awful. That dude should be fired. I hope I'm not there. And so if you're measuring over time, what does your three months ago look back feel like? Oh, I feel like it's a little better. Still, you should look back and be like, oh, I probably would do that a little bit different given what I know now, what I've learned, but less so, I think. I don't know, what do you think about that?

+ +

STEPH: Yeah, that makes sense. And I'm also realizing I haven't looked back at my code that much since I am changing projects, and then I don't always have the opportunity to go back to that project and then revisit some of the code. But I do agree with the idea that if you're looking back at code that you've written a couple of months ago that you can see areas that you would improve, but I agree that you wouldn't want it to be something drastic. Like, you wouldn't want to see something that was more of an obvious security hole or performance issue. I think there are maybe certain metrics that I would use. I think they can still happen for sure because we're always learning, but there's also -- I may be taking this in a slightly different direction than you meant, but there's also a kindness filter that I also want us to apply to ourselves where if you're looking back three months ago to six years ago and you're like, oh, that's some rough code, Stephanie. But it's also like, yeah, but that code got me to where I am today, and I'm continuing to progress. So I appreciate who I was in the past, and I have continued to progress to who I am today and then who I will be.

+ +

CHRIS: What a wonderfully positive lens to put on it. Actually, that makes me think of one of -- We may be getting into rant territory here, but we talk a lot about imposter syndrome in the software development world. And I think there's a lot of utility because this is something that almost everyone experiences. But I think there's a corollary to it that we should talk about, which is a lot of people are coming into this industry, and they're like one year in, and the expectation that one year into a career that -- The thing that we do is not easy as far as I can tell. I haven't figured out how to make it easy. And the expectation that someone's going to be an expert that early on is just completely unreasonable in my mind. In my previous career, I was a mechanical engineer, and I went to school for four years. I actually went to school for five years, not because I was bad at school, but because I went to a place that had a co-op. And so I had both three different six months experiences working and four years of classroom education before I even got any job. And then I started doing things, and that's normal in that world. Whereas in the development world, it is so accessible, and I really feel like that's an absolutely wonderful thing. But the counterpoint of that is folks can jump into this career path very early on in their learning, and the expectation that they can immediately become experts or even in the short order I don't think is realistic. I think sometimes, when we talk about imposter syndrome, we may do a disservice. Like, it's not imposter syndrome. You're just new, and that's totally fine. And I hope you're working in an organization that is supportive of that and that has space for that and can help you grow in a purposeful way. In my mind, it's not realistic to expect everyone to be an expert a year in—end rant.

+ +

STEPH: Well, I would love to plus-one your rant and add to it a little bit because I completely agree. I also love the phrasing that you just said where it's not that you have imposter syndrome; it's just that you are new and that team should be supportive of people that are new and helping them grow and level up. I also think that's true for senior developers in terms that you are very good at certain skills, but there's always going to be some area of the web or some area of software development that you are new to, and that is also not imposter syndrome. But it's fine to assess your own skills and say, "That's something that I don't know how to do." And sometimes, I think that gets labeled as imposter syndrome, but it's not. It's someone just being genuine and reflecting on their current skills and saying, "I am good at a lot of stuff, but I don't know this one, and I am new to this area." And I think that's an important distinction to make because I still want -- even if you are not new in the sense that you are new to being a software engineer, but you still have that space to be new to something.

+ +

CHRIS: Yeah, it's an interesting, constantly evolving space. And so giving ourselves a little bit of permission to be beginners on various topics and for me, that's been an experience that's been continual. I think being a consultant, being a freelancer that impacts it a little bit. But nonetheless, even when I go into organizations, I'm like, oh, years in technology that only came out two years ago. That's pretty fresh. And so it's really hard to be an expert on something that's that new.

+ +

STEPH: Yeah. I think being new to a team has its own superpower. I don't know if we've talked about that before; if we haven't, we should talk about, it but I won't do that now. But being new is its own superpower. But I do want to pivot back to where Tom mentioned that I have no way of measuring that improvement. And I think that's a really great thing to recognize that you're not sure how to measure something. And my very first honest suggestion if you are feeling that way is to go ask your manager and ask them how they are measuring your improvement because that is their job is to understand where you're at and to understand your path as a developer on the team and then helping you set goals.

+ +

So since I'm a manager at thoughtbot, I'll go first, and I can share some ways that I help my team measure their own improvement. So one of the ways is that each time that we meet to discuss work, I listen to their challenges, and I take notes; I'm a heavy note-taker. And so once I have all those notes, then I can see are there any particular challenges that resurface? Are there any patterns, any areas where they continuously get stuck on? Or are they actually gaining confidence, and maybe something that would have given them trouble a couple of weeks ago is suddenly no big deal? And then I also see if they're able to unblock themselves. So a lot of what I do is far more listening, and I'm happy to then provide suggestions. But I am often just a space for someone to share what they are thinking, what they're going through, and then to walk through ideas and then provide suggestions if they would like some, and then they choose a suggestion that works best for them. And then we can revisit how did it go? So their ability to unblock themselves is also something that I'm looking for in terms of growth. And then together, we also set goals together, and then we measure that progress together. So it's all very transparent. And what areas would you like to improve, and then what areas would it be helpful for thoughtbot or as a consultant for you to improve? And then if I am fortunate enough to be on a project with them and see how they reason about quality and speed, how they communicate the type of features they're most comfortable to work on, and which tasks are more challenging for them, I also look to see do people enjoy working with them? That's a big area of growth and reflects communication, and reliability, and trust. And those are important areas for us to grow as developers. So those are some of the areas that I look to when I'm helping someone else measure their own improvement.

+ +

CHRIS: I really like that, the structured framing of it, and the way that you're able to give feedback and have that as a constant, continuous way to evaluate, define, measure, and then try and drive towards it. Flipping things around, I want to offer a slightly different thing, which isn't necessarily specifically in the question, but I think it's very close to the question of how do we actually improve as developers? What are the specific things that we can try and do? I'm going to offer a handful of ideas. I'd be super interested to hear what your ideas are. But one of the things that has been really valuable for me is exploring different languages and frameworks. I, without fail, find something in every new language or framework that I then bring back to the core things that I'm working with. And I've continued to work with Rails basically throughout my career, but everything else that I'm doing has informed the way that I work with Rails and the way that I think about building code. As specific examples, functional programming is a really interesting frame of mind, and Elm as a language is such a wonderful, gentle, friendly, fun introduction to functional programming because functional programming can get very abstract very easily. I've also worked with Haskell and Scala and other languages like that, and I find them much more difficult to work with. But Elm has a set of constraints and a user-centric approach that is just absolutely wonderful. So even if you never plan to build a production Elm application, I recommend Elm to absolutely everyone.

+ +

In terms of frameworks, depending on what you're using, maybe try and find the thing that's the exact opposite. If you're in the JavaScript space, I highly recommend Svelte. I think it's been very informative to me and altered a number of my opinions. A lot of those opinions were formed by React. And it's been interesting to observe my own thinking evolve in that space. But yeah, I think exploring, trying out, -- Have you ever used Lisp? Personally, I haven't, but that's one of the things that's on my list of that seems like it's got some different ideas in it. I wonder what I would learn from that. And so continually pushing on those edges and then bringing that back to the core work you're doing that's one of my favorite things.

+ +

Another is… It's actually two-fold here. Teaching is one, and I don't mean that in the grand sense; you don't have to be an instructor at a bootcamp or anything like that but even just within your organization trying to host a lunch and learn and teach a concept. Without fail, you have to understand something all the better to be able to teach it. Or as you try and teach something, someone may ask you a question that just shakes the foundation of what you know, and you're like, wow, I hadn't thought about it that way. And so teaching for me has just been this absolutely incredible forcing function for understanding something and being able to communicate about it again, that being one of the core things that I'm thinking about. And then the other facet sort of a related idea is pairing, pair with another developer, pair with a developer who is more senior than you on the team, pair with someone who is more junior than you, pair with someone who's at the same level, pair with the designer, pair with the developer, pair with a product manager, pair with everyone. I cannot get enough pairing. Well, I can, actually. I read a blog post recently about 100% pairing, and I've never gotten anywhere close to that number. But I think a better way to put it is I think pairing applies in so many more contexts than people may traditionally think of it. People sometimes like to compartmentalize and like, pairing is great for big architecture design, but that's about it. And my stance would be pairing is actually great at everything. It is very high bandwidth. It is exhausting, but I have found immense value in every pairing session I've ever had. So, yeah, those are some loose thoughts off the top of my head. Do you have any how to get better protips?

+ +

STEPH: Yeah, that's a wonderful list. And I'm not sure if this exactly applies because it's been a while since I have seen this talk, but there is a wonderful talk by Sandi Metz. I mean, all of her talks are wonderful, but this one is Go Ahead, Make a Mess. And I believe that Sandi refers to or highlights the idea of trying something new and then reflecting on how did it go? And that was one of the areas that I learned early on, one of the ways to help me progress quickly as a developer. Outside of the suggestions that you've already shared around lots of pairing that was one of the ways that I leveled up quickly is to iterate quickly. So I used to really focus on the code that I was writing, and I thought it needed to be perfect before my colleagues could review it. But then I realized that the sooner that I would push something out for feedback, then the faster I would get other more experienced developers' input, and then that helped me learn at an accelerated rate and then also ship more frequently. So I'd also encourage you to just go ahead and iterate quickly. We talk about with software in general, we want to iterate on the code that we are pushing up for other people to look at and then give us feedback on and then reflect on how did it go? What did we learn? What are some areas that we can improve? I feel like that self-evaluation is huge, and it's something that I know that I frankly don't do enough because one, it also prompts us to appreciate the progress that we have made but then also highlights areas where I feel strong in this area, but these are other areas that I want to work on.

+ +

CHRIS: While we're on the topic of talks that have been impactful in our journeys of leveling up as developers, I want to quickly list three that just always come to mind for me: Avdi Grimm's Confident Code, Katrina Owen's Therapeutic Refactoring, and Ben Orenstein's Refactoring from Good to Great. There's a theme if you look across those three talks. They're all about refactoring, which is interesting. That tells you some stories about what I believe about how good software is made. It's not made; it's refactored. That's my official belief, but yeah.

+ +

STEPH: Love it. That's also another great list. [laughs] For additional ways to level up, there are some very specific areas where it could be maybe do code katas or code exercises, or maybe you subscribe to certain newsletters, stay up to date with a language, new features that are being released. But outside of those very specific things, and if folks find this helpful, then maybe you and I can make a fun list, and then we could share that on Twitter as well. But I always go back to the idea of regardless of what level you're at in your career is to think about your specific goals, maybe if you are new to a team and you're new to software development, then maybe you just have very incremental goals of like, I want to learn how to write a test, or I want to learn how to get better at PR review or something very specific. But to have real growth, I think you have to first consider where it is that you want to go and then figure out a way to measure to get there. Circling back to some of the ways that I help my teammates measure that growth, that's one of the things that we talk about. If someone says, "Well, I want to get better at PR review," I'm like, "Great. What does that mean to you? Like, how do you get better at PR review? How can we actually measure this and make it something actionable versus just having this vague feeling of am I better?" I think I've ended up taking this a bit more broad as you were providing more specific examples on how to level up. But I like the examples that you've already provided around education and then trying something outside of your comfort zone. So what's coming to mind are more of those broad strategies of goal setting.

+ +

CHRIS: I think generally, you need that combination. You need how do I set the measure? How do I think about improvement? And then also ideally a handful of tactics that you can try out. So hopefully, we provided a nice balanced summary here in this episode. And hopefully, Tom, if you're listening, you have gotten some useful things out of this conversation.

+ +

STEPH: Yeah, this was fun. We managed to take this topic and make a whole episode out of this. So thanks, Tom, for sending in such a great topic.

+ +

CHRIS: Frankly, when I saw the topic, I was certain this was going to happen. [chuckles] This was an obvious one that was going to fill up the time for us. But yeah, with that, I think we've probably covered plenty here. Should we wrap up?

+ +

STEPH: I'm sure there's more, but sure, let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me @SViccari on Twitter.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

Both: Byeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris respond to a listener question about how to know if we're improving as developers. They discuss the heuristics they think about when it comes to improving, how they've helped the teams they've worked with plan for and measure their growth, and some specific tips for improving.

+ + + +

Transcript

+ +

CHRIS: There's something intriguing about the fact that we're having this conversation, but the thing that's recorded just starts at this arbitrary point in time, and it's usually us rambling about golden roads. But, I don't know; there's something existential about that.

+ +

STEPH: It's usually when someone says something very funny or starts singing [laughs], and then that's when we immediately: record, record!

+ +

CHRIS: I've never sung on the mic. That doesn't sound like a thing I would do.

+ +

STEPH: [laughs]

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey.

+ +

STEPH: And I'm Steph Viccari.

+ +

CHRIS: And together, we're here to share a bit of what we've learned along the way. So Steph, how's your week going?

+ +

STEPH: Hey Chris, it's going really well. Normally I'm always like, wow, it's been such an exciting week, and it's been a pretty calm, chill week. It's been lovely.

+ +

CHRIS: That sounds nice actually in contrast to the "Well, it's been a week," that sort of intro of "I don't know, it's been fine. It can be really nice."

+ +

STEPH: By the time we get to this moment of the week, I either have stuff that I'm so excited to talk about and have a little bit of a therapy session with you or share something new that I've learned. I agree; it's nice to be like, yeah, it's been smooth sailing this whole week. In fact, it was smooth sailing enough that I decided to take on something that I've been meaning to tackle for a while but have just been avoiding it because I have strong feelings about this, which you know but we haven't talked about yet. But it comes down to managing emails and how many emails one should have that are either unread that are just existing. And I fall into the category of where I am less scrupulous about how many unread or managed emails that I have. But I decided that I'd had enough. So I used a really nice filter in Gmail where I said I want all emails that are before 2021 and also don't have a user label, so it's has:nouserlabels because then I know those are all the emails that I haven't labeled or assigned to a particular...I want to say folder, but they're not truly folders; they just look like folders. So they're essentially like untriaged or just emails that I've left hanging out in the ether. And then I just started deleting, and I got rid of all of those that hadn't been organized up until that point. And I was just like yep, you know if I haven't looked at it, it's that old, and I haven't given a label by this point, I'm just going to move on. If it's important, it will bubble back up. And I feel really good about it.

+ +

CHRIS: Wow, that is -- I like how you backed me into a corner. Obviously, I'm on the other side where I'm fastidiously managing my email, which I am, but you backed me into that corner here. So, yeah, that's true. Although the approach that you're taking of just deleting all the old email that's a different one than I would have taken [chuckles] so, I like it. It's the nuclear option.

+ +

STEPH: Okay, so now I need to qualify. When you delete an email, initially, I'm thinking it's going to trash, and so it's still technically there if I need to retrieve it and go back and find it. But you just said nuclear option, so maybe they're actually getting deleted.

+ +

CHRIS: They're going into the trash for 30 days; I think is the timeline. But after that, they will actually delete them. The archive is supposed to be the place where you put stuff I don't want to see you anymore. But did you archive or delete?

+ +

STEPH: Oh, I deleted.

+ +

CHRIS: Oh, wow. Yeah. All right, you went for it. [laughter]

+ +

STEPH: Yeah, and that's cool. And it's in trash. So I basically have a 30-day window where I'm like, oh, I made a mistake, and I need to search for something and find something and bring it back into my world; I can find it. If I haven't searched for it by then in 30 days, then I say, you know, thanks for the email, goodbye. [chuckles] And it'll come back if it needs to.

+ +

CHRIS: I like the approach. It would not be my approach, but I like the commitment to the cause. Although you still have...how many emails are still in your inbox now?

+ +

STEPH: Why do we have to play the numbers game?

+ +

CHRIS: [laughs]

+ +

STEPH: Can't we just talk about the progress that I have made?

+ +

CHRIS: What wonderful progress you've made, Steph. [laughter] Like, it doesn't matter what I think. What do you think about this? Are you happy with this? Does this make you feel more joy when you look into your email in the Marie Kondo sense?

+ +

STEPH: It does. I am excited that I went ahead and cleared all this because it just felt like craft. So I have taken what may be a very contentious approach to my email, where I treat it as this searchable space. So as things come in, I triage them, and I will label them, I will star them. I will either snooze them to make sure I don't miss the high actionable emails or something that's very important to me to act on quickly. But for the most part, then a lot of stuff will sit in that inbox area. So it becomes like this junk drawer. It's a very searchable junk drawer, thanks to Google. They've done a great job with that. And it feels nice to clear out that junk drawer. But I do have such an aversion to that very strong email inbox zero. I respect the heck out of it, but I have an aversion; I think from prior jobs where I was on a team, and we could easily get like 800 emails a day. My day all day was just triaging and responding to emails and writing emails. And so I think that just left a really bitter experience where now I just don't want to have to live that life where I'm constantly catering to what's in my inbox.

+ +

CHRIS: That's so many emails.

+ +

STEPH: It was so many emails. We were a team. It was a team inbox. So there were three of us managing this inbox. So if someone stepped away or if someone was away on vacation, we all had access to the same emails. But still, it was a lot of emails.

+ +

CHRIS: Yeah, inbox zero in a shared inbox that is a level that I have not gotten to but getting to inbox zero and actually maintaining that is very much a labor of love and something that I've had to invest in. And it's probably not worth it for most people. You could convince me that it is not worth it for me, that the effort I'm putting in is too much effort for not enough reward. Well, it's one of those things where I find the framing that it puts on it, like, okay, I need to process my email and get it to zero at least once a day. Having that lens makes me think about email in a different way. I unsubscribe from absolutely everything. The only things that are allowed to come into my email are things that I will act on that actually deserve my attention, and so it forces that, which I really like. And then it forces me to think about things. I have a tendency to really hold off on decisions. So I'm like, ah, okay. I can go see friends on Saturday or I can do something else. Friends like actual humans, not the TV show, although for the past year, it's definitely more of the TV show than the real people. But let's say there's a potential thing that I could do on the weekend and I have to decide on that. I have a real tendency to drag my feet and to wait for some magical information from the universe to help this decision be obvious to me. But it's never going to be obvious, and at some point, I just need to pick. And so for inbox zero, one of the things that comes out of it for me is that pressure and just forcing me to be like, dude, there's no perfect answer here, just pick something. You got to just pick something and not wasting multiple cycles rethinking the same decision over and over because that's my natural tendency. So in a way, it's, I don't know, almost like a meditative practice sort of thing. There's utility there for me, but it is an effort, and it's, again, arguably not worth it. Still, I do it. I like it. I'm a fan. I think it's worth it.

+ +

STEPH: I like how you argued both sides. I'm with you. I think it depends on the value that you get out of it. And then, as long as you are effective with whichever strategy you take, then that's really what matters. And I do appreciate the lens that it applies where if you are getting to inbox zero every day, then you are going to be very strict about who can send you emails about notifications that you're going to receive because you are trying to reduce the work that then you have to get to inbox zero. So I do very much admire that because there are probably -- I'm wasting a couple of minutes each day deleting notifications from chats or stuff that I know I'm not necessarily directly involved in and don't need action from me. And then I do get frustrated when I can't adjust those notification settings for that particular application, and I'm just subscribed to all of it. So some of it I feel like I can't change, and then some of it, I probably am wasting a few minutes. So I think there's totally value in both approaches. And I'm also saying that to try to justify my approach of my searchable inbox. [laughs]

+ +

CHRIS: There are absolutely reasons to go either way. And also, to come back to what I was saying a minute ago, it may have sounded like I'm a person who's just on top of this. I may have given that impression briefly. I think the only time this has actually worked in my life is when Gmail introduced snooze both in the mobile app and on the desktop. So this is sometime after Google's inbox product came out, and that was eventually shut down. So it's relatively recent because, man, I just snooze everything. That is the actual secret to achieving inbox zero, just to reach the end of the day and be like, nah, and just send all the emails to future me. And then future me wakes up and is like, "You know, it's first thing in the morning. I got a nice cup of coffee, and this is what you're going to do to me, past me?" So there's a little bit of internal strife there within my one human. But yeah, the snoozing is actually incredibly useful and probably the only way that I actually get things done and the same within any task management system that I have; maybe future me will do this.

+ +

STEPH: I think you and I both subscribed to the that's a future me problem. We just do it in very different ways. But switching gears a bit, how's your week been?

+ +

CHRIS: It's been good, pretty normal, doing some coding, normal developer things. Actually, there's one tool that I was revisiting this week that I'm not sure that we've actually talked about on the show before, but it's Rails Autoscale. Have you used that before?

+ +

STEPH: I don't think I have. It sounds very familiar, but I don't think I've used it.

+ +

CHRIS: It's a very nice, straightforward Heroku add-on that does exactly what you want it to do. It monitors your web and worker dynos and will scale up. But it uses a different heuristic than -- So Heroku has built-in autoscaling, but theirs is based on response time, which is, I think, a little bit laggier of a metric. Like if your response time has gotten bad, then you're already in trouble, whereas Rails Autoscale uses queue time. So how long is a request waiting before? I think it's at the Heroku router; it goes onto the dyno that's actually going to process the request? So I think that's what they're monitoring. I may be wrong on that. But from the website, they're looking at that, and you can configure it. They actually have a really nice configuration dashboard for configure between this range, so one to five dynos at most, and scale in this way up and in this way down. So like, how long should it wait? What's the threshold of queue time? Those sorts of things. So they have a default like just do the smart thing for me, and then they give you more control if your app happens to have a different shape of data, which is all really nice. And then I've been using that for a while, but I recently this week actually just turned on the worker side. And so now the workers will autoscale up and down as the Sidekiq queue -- I think for the Sidekiq side, it's also the queue time, so how long a job sits in the queue before getting picked up. And there are some extra niceties. It can actually infer the different queue names that you have. So if you have a critical, and then a mailer, and then a general as the three queues that Sidekiq is managing, you really want critical to not back up. So you can tell it to watch that one but ignore the normal one and only use -- Like, when critical is actually getting backed up, and all the other stuff is taken over then -- Again, it's got nice knobs and things, but mostly you can just say, "Turn it on and do the normal thing," and it'll do a very smart thing."

+ +

STEPH: That does sound really helpful. Just to revisit, so Heroku for autoscaling, when you turn that on, I think Heroku does it based on response times. So if you get into a specific percentile, then Heroku is going to scale up for you to then bring down that response time. But it sounds like with this tool, with Rails autoscaling, then you have additional knobs like the Sidekiq timing that you'd referenced. Are there some other knobs that you found really helpful?

+ +

CHRIS: Basically, there are two different sides of it. So web and background jobs are going to be handled differently within this tool, and you can actually turn them on or off individually, and you can also, within them, the configurations are specific to that type of thing. So for the web side, you have different values that you can set as the thresholds than you do on the Sidekiq side. Overall, the queue name only makes sense on the Sidekiq side, whereas on the web side, it's just like the web requests all of them 'Please make sure they're not spending too much time waiting for a dyno to actually start processing them.' But yeah, again, it's just a very straightforward tool that does the thing that it says on the tin. I enjoy it. It's one of those simple additions where it's like, yeah, I think I'm happy to pay for this because you're just going to save me a bunch of money every month, in theory. And actually, that side of it is certainly interesting, but more of my app will be responsive if there is any spike in traffic. There's still plenty of other performance things under the hood that I need to make better, but it was nice to just turn those on and be like, yeah, okay. I think everything's going to run a little better now. That seems nice. But yeah, otherwise, for me, a very straightforward week.

+ +

So I think actually shifting gears again, we have a listener question that we wanted to chat about. And this is one that both of us got very interested to chat about because there's a lot to this topic, but I'm happy to read it here. So the overall topic is improving as a developer, and the question goes, "How do you know you're improving as developers? Is your improvement consistent? Are there regressions? I find myself having very different views about code than I did even a year ago. In some cases, I write code now in a way that I would have criticized not too long ago. For example, I started writing a lot more comments. I used to think a well-named variable obviated the need for comments. While it feels like I'm improving, I have no way of measuring the improvement. It's only a gut feeling. Thanks. Love the show." And this comes from Tom. Thank you, Tom. Glad you enjoy the show. So, Steph, are you improving as a developer?

+ +

STEPH: I love this question. Thanks, Tom, for sending it in because it is one that I think about but haven't really verbalized, and so I'm really excited to dive into this. So am I improving as a developer? It comes down to, I mean, we first have to talk through definitions. Like, what does it mean to become a better developer? And then, we can talk through metrics and understanding how we're getting there. I also love the other questions, which I know we'll get to. I'm just excited. But are there any regressions? And also, in my mind, they already answered their own question. But I'm getting ahead of myself. So let me actually back up. So how do you know you're improving as a developer? There are a couple of areas that come to mind. And for me, these are probably more in that space of they still have a little bit of a gut feeling to them, but I'm going to try hard to walk that back into a more measurable state. So one of them could be that you're becoming more comfortable with the work that you're doing, so if you are implementing a new email flow or running task on production or writing tests that become second nature, those types of activities are starting to feel more comfortable. To me, that is already a sign of progress, that you are getting more comfortable in that area. It could be that time estimates are becoming more accurate. So perhaps, in the beginning, they're incredibly -- like, you don't have any idea. But as you are gaining experience and you're improving as a developer, you can provide more accurate estimates.

+ +

I also like to use the metric of how many people are coming to you for help, not necessarily in hard numbers, but I tend to notice when someone on a team is the person that everybody else goes to for help, maybe it's just on a specific topic, maybe it's for the application in general. But I take that as a sign that someone is becoming very knowledgeable in the area, and that way, they're showing that they're improving as a developer, and other people are noticing that and then going to them for help. Those are a couple of the ones that I have. I have some more, but I'd love to hear your thoughts.

+ +

CHRIS: I think if nothing else, starting with how would we even measure this? Because I do agree it's going to be a bit loose. Unfortunately, I don't believe that there are metrics that we can use for this. So the idea of how many thousand lines of codes do you write a month? Like, that's certainly not the one I want to go with. Or, how many pull requests? Anything like that is going to get gamified too quickly. And so it's really hard to actually define truly quantifiable metrics. I have three in mind that scale the feedback loop length of time. So the first is just speed. Like, how quickly are you able to do the same tasks? So I need to build out a page in Rails. I need a route; I need a controller. I need a feature spec, those sort of things. Those tasks that come up over and over: are you getting faster with those? That's a way to measure. And there's an adage that I think comes from biking, professional cycling, that it never gets any easier; you just go faster. And so the idea is you're doing the same work over time, but you just get a little bit faster, and you're always trying that edge of your capabilities. And so that idea of it never gets any easier, but you are getting faster. I like that framing. We should be doing the same work. We should never get too good for building a crud app. That's my official stance on the matter; thank you very much. But yeah, so that's speed. I think that is a meaningful thing to keep an eye on and your ability to actually deliver features in a timely fashion.

+ +

The next one would be how robust are the things that you're building? What's the bug count? How regularly do you have to revisit something that you've built to change it, to tweak it either because it doesn't exactly match the intent of the feature that you're developing or because there's an actual bug in it? It turns out this thing that we do is very hard. There are so many moving pieces and getting the design right and getting the functionality just right and handling user input, man, that's tricky. Users will just send anything. And so that core idea of robustness that's going to be more on a week scale sort of thing. So there's a little bit of latency in that measure, whereas speed that's a pretty direct measure.

+ +

The third one is…I don't know how to frame this, but the idea of being able to revisit your code either yourself or someone else. So if you've written some code, you tried to solve a problem; you tried to encode whatever knowledge you had at the given time in the code. And then when you come back three months later, how easy is it to revisit that code, to change it, to extend it either for yourself (because at that point you've forgotten everything) or for someone else on the team? And so the more that you're writing code that is very easy to extend, that is very easy to revisit and reload that context into your head, how closely the code maps to the actual domain context I think that's a measure as well that I'm really interested in, but there's the most lag in that one. It's like, yeah, months later, did you do a good job? And so the more time you spend, the more you'll have a measure of that, but that's definitely the laggiest of the measures that I have in mind.

+ +

STEPH: I love that adage that you shared that it never gets easier, but you get faster. That feels so relevant. I really like that. And then I hadn't considered the robustness. That's a really nice one, too, in terms of how often do you have to go back and revisit issues that you've added?

+ +

CHRIS: You just write code without bugs; that's why you don't think about it.

+ +

STEPH: [laughs] Oh, if only that were true.

+ +

CHRIS: Yeah, if only that were true of any of us.

+ +

STEPH: To keep adding to the list, there are a couple more that come to mind too. I'd mentioned the idea that certain tasks become easier. There's also the capability or the level of comfort in taking on that new, big, scary, unknown task. So there is something on the Teams' board where you're like, I have no idea how to do that, but I have confidence that I can figure it out. I think that is a really big sign that you are growing as a developer because you understand the tools that'll get you to that successful point. And maybe that means persuading someone else to help you; maybe it means looking elsewhere for resources. But you at least know how to get there, which then follows up on your ability to unblock yourself. So if you are in that state of I just don't know what to do next, maybe it's Googling, or maybe it is reaching out for help, but either way, you keep something moving forward instead of just letting it sit there.

+ +

Another area that I've seen myself and other people grow as developers is our ability to reason about quality and speed. It's something that I feel you, and I talk about pretty often here on the show, but it comes down to our ability to not just write code but then to also make good decisions on behalf of the company that we are working for and the team that we're working with and understanding what matters in terms of what features really need to be part of this MVP? Where can we make compromises? And then figuring out where can we make compromises to get this out to market? But what's really important then for circling back to your idea of revisiting the code, we want code that we can still come back and trust and then easily maintain and make updates to. And then I feel like I'm rambling, but I have a couple more. Shall I keep going?

+ +

CHRIS: Keep going. Those are great.

+ +

STEPH: All right. So for the others, there's an increase in responsibilities that I notice. So, in addition to people coming to you more often for help, then it could be that you are receiving more responsibilities. Maybe you are taking on specific ownership of the codebase or a particular part of the team processes. Then that also shows that you are improving and that people would like you to take leadership or ownership of certain areas. And then this one, I am throwing it in here, but your ability to run a meeting. Because I think that's an important part of being a good developer is to also be able to run a meeting with your colleagues and for that to be a productive meeting.

+ +

CHRIS: Cool. I like that one. I think I want to build on that because I think the core idea of being able to run a meeting well is communication. And I think there's one level of doing this job where it's just about doing the job. It's just about writing the code, maybe some amount of translating a specification or a ticket or whatever it is into the actual code that you need to write. But then how well can you communicate back out? How well when someone in project management says, "Hey, we want to build an aggregated search across the system that searches across our users, and our accounts, and our products, and our orders, and our everything." And you're like, "Okay. We can do that, but it will be hard. And let's talk about the trade-offs inherent in that and the different approaches and why we might pick one versus the other," being able to have that conversation requires a depth of knowledge in the technical but then also being able to understand the business needs and communicate across that boundary. And I think that's definitely an axis on which I enjoy pushing on as I'm continuing to work as a developer.

+ +

STEPH: Yeah, I'm with you. And I think being a consultant and working at thoughtbot heavily influences my concept of improving as a developer because as developers, it's not just our job to write code but to also be able to communicate and help make good decisions for the team and then collaborate with everyone else in the company versus just implement certain features as they come down the pipeline. So communication is incredibly important. And so I love that that's one of the areas that you highlighted.

+ +

CHRIS: Actually speaking of the communication thing, there's obviously the very human-centric part of that, but there's, I think, another facet of technical communication that is API design. When you're writing your code, what do you choose to expose and make accessible to collaborators? And I don't just mean API in the terms of a REST API that people are heading, but I mean a class that you have in your system. What are the private methods, and what are the public methods? And how do you think about the shape of it? What data do you expose? What do you not expose? And that can be really impactful because it allows how can you change things over time? The more that you hide, the more you can change. But then, if you don't allow your collaborators to access the bits that they need to be able to work with your system, that's an interesting one that comes to mind. It also aligns with, I don't think you were saying this exactly, but the idea of taking on more amorphous projects. So like, are you working within a system and adding a new feature, or are you designing a system? Are you architecting? The word architect that role can sometimes be complicated within organizations, but that idea of I'm starting fresh, and I'm building a system that others will then work within I think this idea of API design becomes really interesting in that context. What shape do you give to the system that we're working within, and what affordances? And all of that. And that's a very hard thing to get right. So it comes from experience of being like, I used some stuff in the past, and I hated it, so when I am the architect, I will build it better. And then you try, and you fail, and you're like, well, okay, but now I've learned. And then you try it, and then you fail for different reasons. But the seventh time you try, it may be just that time you get the public API just right on the first go.

+ +

STEPH: Seven times's a charm. That's how that goes, right?

+ +

CHRIS: That is my understanding, yes.

+ +

STEPH: I think something that is related to the idea of are you working in a structured space versus working in a new space and then how you develop that API for other people to work with. And then how do you identify when to write a test and what to test? That's another area that you were just making me think of is that I can tell when someone has experience with testing because they know what to test and what feels important to test. And essentially, it comes down to can I deploy with confidence? But there are a lot of times, especially if you're new to testing, that you're going to test everything, and you're going to have a lot of probably useless slow tests. But over time, you will start to realize what's really important. And I think that's one of the areas where then it does start to get harder to measure yourself as a developer because all of our jobs are different, and we work with different tech stacks, and we all have our unique responsibilities and goals. So it may be hard to say specifically like, "Oh, you're really good at X, Y, and Z, and that's how you know that you're improving as a developer." But I have more thoughts on that, which we'll get to in a moment where Tom mentioned that they don't have a way of measuring improvement. Shall I go ahead and jump ahead to I have no way of measuring that improvement, or shall we talk about regressions next?

+ +

CHRIS: I'm interested in your thoughts on the regressions question because it's not something that I've really thought about. But now that he's asked the question, I'm thinking about it. So yeah, what are your thoughts on that?

+ +

STEPH: My very quick answer is yes, [laughs] that there are regressions mainly because I respect that our brain can only make so much knowledge readily available to us, and then everything else goes into long-term storage. We can access it at some point, but it takes additional time, or maybe it takes some practice to recall that skill. So I do think there are regressions, and I think that's totally fine that we should be focused on what is serving us most at the moment and be okay with letting go of some of those other skills until we need to refine them again.

+ +

CHRIS: Yeah. I think there's definitely a truth to true knowledge and experience with, say, a framework or a language that can fade. So if I spend a lot of time away from JavaScript, and then I come back, I'm going to hit my head on a few low ceilings every once in a while for the first couple of days or weeks or whatever it is. It was interesting actually that Tom highlighted the idea of he used to not write comments, and now he writes more comments, and so that transition -- I think we've talked about comments enough so our general thinking on it. But I think it's totally reasonable for there to be a pendulum swing, and maybe there's a slight overcorrection. And you read some blog posts that tell you the truth of the world, and suddenly, absolutely no comments ever that's the rule. And then, later on, you're like, you know, I could really use a comment here. And so you go that way, and then you decide you know what? Comments are good, and you start writing a bunch of them. And so it's sort of weaving back and forth. Ideally, you're honing in on your own personal truth about comments. But that's just an interesting example to me because I certainly wouldn't consider that one a regression.

+ +

But then there's the bigger story of like, how do we approach building software? Ideally, that's what this podcast does at its best. We're not really a podcast about Rails or JavaScript or whatever it is we're talking about that week, but we're talking about how to build software well. And I think those core ideas feel like they're more permanent for me, or I feel like I'm changing those less. If anything, I feel like I'm ratcheting in on what I believe about good software. And there are some core ideas that I'm just refining over time, not done by any means, but it's that I don't feel like I'm fundamentally reevaluating those core ideas. Whereas I am picking up a new language and approaching a new framework and taking a different approach to what tools I'm using, that sort of thing.

+ +

STEPH: Yeah, I agree. The core concepts definitely feel more important and more applicable to all the future situations that we're going to be in. So those skills that may fall into the regression category feel appropriate because we are focused on the bigger picture versus how well do I remember this rejects library or something that won't serve us as well? So I agree. I am often focused more on how can I take this lesson and then apply it to other tech stacks or other teams and keep that with me? And I don't want that to regress. But it's okay if those other smaller, easily Google-able skills fall to the side. [laughs]

+ +

CHRIS: Wait, are you implying that you can't write rejects just off the top of your head or what's…?

+ +

STEPH: I don't think I could write any rejects off the top of my head. [laughter]

+ +

CHRIS: Fair. All right. You just go to rubular.com, hit enter, and then we iterate.

+ +

STEPH: Oh yeah. I don't want to use up valuable space for maintaining that sort of information. Rubular has it for me. I'm just going to go there.

+ +

CHRIS: I mean, as long as you have the index of the places you go on the internet to find the truth, then you don't need to store that truth.

+ +

STEPH: A moment ago, you mentioned where Tom highlights that they have different views about code that they wrote, even code that they wrote just like a year ago. And to me, that's a sign of growth in terms that you can look back on code that you have written and be like, well, maybe this would be different, or maybe this is still a good idea, but the fact that you are changing and then reevaluating, I think that is awesome because otherwise, if we aren't able to do that, then that is just a sign of being stagnant to me. We are sticking to the knowledge that we had a year ago, and we haven't grown since then versus that already shows that they have taken in new knowledge. So then that way, they can assess should I be adding comments? When should I add comments? Maybe I should swing away from that idea of this is a hard line of don't ever do this. I think I just have to mention it because there is one that I always feel so deeply about, DRY. DRY is the concept that gives me the most grief in terms that people just overuse it to the point that they do make code very hard to change. All right, that's my bit. I'll get off my pedestal. But DRY and comments are two things [chuckles] that both have their places.

+ +

CHRIS: I don't know if your experience was similar, but around DRY, I definitely have had the pendulum swing of how I feel about it. And I think again, that honing in thing. But initially, I think I read The Pragmatic Programmers, and they told me that DRY is important. And then I was like, absolutely, there will be no duplication anywhere, and then I felt some pain from that. And I've been in other systems and experienced places where people did remove duplication. I was like, oh, maybe it would have been better, and so I slowly got out of that mindset. But now I'm just in the place of like, I don't know, copy and paste not now, there was a period where I was like, just copy and paste everything. And then I was like, all right, I think there's a subtle line. There's a perfect amount of duplication, and that's the goal is to figure out that just perfect level. But for me, it really has been that evolution, and I was on one side, and then I was on the other side, and then I'm honing back in. And now I have my personal truth about duplication.

+ +

STEPH: Oh, me too. And I feel like I can be a little more negative about it because I was in the same spot. Because it's a rule, it's a rule that you can apply that when you are new to software development, there aren't that many rules that are so easy to apply to your codebase, but DRY is one of them. You can say, oh, that is duplication. I know exactly what that is, and I can extract it. And then it takes time for you to realize, okay, I can identify it, but just because it's there, it doesn't mean it's a bad thing. Perfect duplication, I like it.

+ +

CHRIS: Coming back to the idea of when we look back on our code six months, a year later, something like that, I think I believe the statement that we should always look back on our code and be like, oh, what was I doing there? But I think that arc should change over time. So early on in my career, six months later, I look back at my code, and I'm like, oh, goodness, what was happening there? I was very much a self-taught or blog internet-taught programmer just working on my own. I had no one else to talk to. So the stuff that I wrote early on was not good is how I will describe it. And then I got better, and then I got better, and I hope that I'm still getting better. And it's something that probably draws me to software development is I feel like there's always room to get a little bit better. Again, even back to that adage of it doesn't get any easier; you just go faster. Like, that's a version of getting better in my mind. So I hope that I can continue to feel that improvement and that ratcheting up. But I also hope that that arc is leveling off. There is an asymptotic approach to "good software developer." People in the audience, you can't see my air quotes, but I made air quotes there around good software developer. But that idea of I shouldn't look back probably this far into my career and look back at code from three months ago and be like, that's awful. That dude should be fired. I hope I'm not there. And so if you're measuring over time, what does your three months ago look back feel like? Oh, I feel like it's a little better. Still, you should look back and be like, oh, I probably would do that a little bit different given what I know now, what I've learned, but less so, I think. I don't know, what do you think about that?

+ +

STEPH: Yeah, that makes sense. And I'm also realizing I haven't looked back at my code that much since I am changing projects, and then I don't always have the opportunity to go back to that project and then revisit some of the code. But I do agree with the idea that if you're looking back at code that you've written a couple of months ago that you can see areas that you would improve, but I agree that you wouldn't want it to be something drastic. Like, you wouldn't want to see something that was more of an obvious security hole or performance issue. I think there are maybe certain metrics that I would use. I think they can still happen for sure because we're always learning, but there's also -- I may be taking this in a slightly different direction than you meant, but there's also a kindness filter that I also want us to apply to ourselves where if you're looking back three months ago to six years ago and you're like, oh, that's some rough code, Stephanie. But it's also like, yeah, but that code got me to where I am today, and I'm continuing to progress. So I appreciate who I was in the past, and I have continued to progress to who I am today and then who I will be.

+ +

CHRIS: What a wonderfully positive lens to put on it. Actually, that makes me think of one of -- We may be getting into rant territory here, but we talk a lot about imposter syndrome in the software development world. And I think there's a lot of utility because this is something that almost everyone experiences. But I think there's a corollary to it that we should talk about, which is a lot of people are coming into this industry, and they're like one year in, and the expectation that one year into a career that -- The thing that we do is not easy as far as I can tell. I haven't figured out how to make it easy. And the expectation that someone's going to be an expert that early on is just completely unreasonable in my mind. In my previous career, I was a mechanical engineer, and I went to school for four years. I actually went to school for five years, not because I was bad at school, but because I went to a place that had a co-op. And so I had both three different six months experiences working and four years of classroom education before I even got any job. And then I started doing things, and that's normal in that world. Whereas in the development world, it is so accessible, and I really feel like that's an absolutely wonderful thing. But the counterpoint of that is folks can jump into this career path very early on in their learning, and the expectation that they can immediately become experts or even in the short order I don't think is realistic. I think sometimes, when we talk about imposter syndrome, we may do a disservice. Like, it's not imposter syndrome. You're just new, and that's totally fine. And I hope you're working in an organization that is supportive of that and that has space for that and can help you grow in a purposeful way. In my mind, it's not realistic to expect everyone to be an expert a year in—end rant.

+ +

STEPH: Well, I would love to plus-one your rant and add to it a little bit because I completely agree. I also love the phrasing that you just said where it's not that you have imposter syndrome; it's just that you are new and that team should be supportive of people that are new and helping them grow and level up. I also think that's true for senior developers in terms that you are very good at certain skills, but there's always going to be some area of the web or some area of software development that you are new to, and that is also not imposter syndrome. But it's fine to assess your own skills and say, "That's something that I don't know how to do." And sometimes, I think that gets labeled as imposter syndrome, but it's not. It's someone just being genuine and reflecting on their current skills and saying, "I am good at a lot of stuff, but I don't know this one, and I am new to this area." And I think that's an important distinction to make because I still want -- even if you are not new in the sense that you are new to being a software engineer, but you still have that space to be new to something.

+ +

CHRIS: Yeah, it's an interesting, constantly evolving space. And so giving ourselves a little bit of permission to be beginners on various topics and for me, that's been an experience that's been continual. I think being a consultant, being a freelancer that impacts it a little bit. But nonetheless, even when I go into organizations, I'm like, oh, years in technology that only came out two years ago. That's pretty fresh. And so it's really hard to be an expert on something that's that new.

+ +

STEPH: Yeah. I think being new to a team has its own superpower. I don't know if we've talked about that before; if we haven't, we should talk about, it but I won't do that now. But being new is its own superpower. But I do want to pivot back to where Tom mentioned that I have no way of measuring that improvement. And I think that's a really great thing to recognize that you're not sure how to measure something. And my very first honest suggestion if you are feeling that way is to go ask your manager and ask them how they are measuring your improvement because that is their job is to understand where you're at and to understand your path as a developer on the team and then helping you set goals.

+ +

So since I'm a manager at thoughtbot, I'll go first, and I can share some ways that I help my team measure their own improvement. So one of the ways is that each time that we meet to discuss work, I listen to their challenges, and I take notes; I'm a heavy note-taker. And so once I have all those notes, then I can see are there any particular challenges that resurface? Are there any patterns, any areas where they continuously get stuck on? Or are they actually gaining confidence, and maybe something that would have given them trouble a couple of weeks ago is suddenly no big deal? And then I also see if they're able to unblock themselves. So a lot of what I do is far more listening, and I'm happy to then provide suggestions. But I am often just a space for someone to share what they are thinking, what they're going through, and then to walk through ideas and then provide suggestions if they would like some, and then they choose a suggestion that works best for them. And then we can revisit how did it go? So their ability to unblock themselves is also something that I'm looking for in terms of growth. And then together, we also set goals together, and then we measure that progress together. So it's all very transparent. And what areas would you like to improve, and then what areas would it be helpful for thoughtbot or as a consultant for you to improve? And then if I am fortunate enough to be on a project with them and see how they reason about quality and speed, how they communicate the type of features they're most comfortable to work on, and which tasks are more challenging for them, I also look to see do people enjoy working with them? That's a big area of growth and reflects communication, and reliability, and trust. And those are important areas for us to grow as developers. So those are some of the areas that I look to when I'm helping someone else measure their own improvement.

+ +

CHRIS: I really like that, the structured framing of it, and the way that you're able to give feedback and have that as a constant, continuous way to evaluate, define, measure, and then try and drive towards it. Flipping things around, I want to offer a slightly different thing, which isn't necessarily specifically in the question, but I think it's very close to the question of how do we actually improve as developers? What are the specific things that we can try and do? I'm going to offer a handful of ideas. I'd be super interested to hear what your ideas are. But one of the things that has been really valuable for me is exploring different languages and frameworks. I, without fail, find something in every new language or framework that I then bring back to the core things that I'm working with. And I've continued to work with Rails basically throughout my career, but everything else that I'm doing has informed the way that I work with Rails and the way that I think about building code. As specific examples, functional programming is a really interesting frame of mind, and Elm as a language is such a wonderful, gentle, friendly, fun introduction to functional programming because functional programming can get very abstract very easily. I've also worked with Haskell and Scala and other languages like that, and I find them much more difficult to work with. But Elm has a set of constraints and a user-centric approach that is just absolutely wonderful. So even if you never plan to build a production Elm application, I recommend Elm to absolutely everyone.

+ +

In terms of frameworks, depending on what you're using, maybe try and find the thing that's the exact opposite. If you're in the JavaScript space, I highly recommend Svelte. I think it's been very informative to me and altered a number of my opinions. A lot of those opinions were formed by React. And it's been interesting to observe my own thinking evolve in that space. But yeah, I think exploring, trying out, -- Have you ever used Lisp? Personally, I haven't, but that's one of the things that's on my list of that seems like it's got some different ideas in it. I wonder what I would learn from that. And so continually pushing on those edges and then bringing that back to the core work you're doing that's one of my favorite things.

+ +

Another is… It's actually two-fold here. Teaching is one, and I don't mean that in the grand sense; you don't have to be an instructor at a bootcamp or anything like that but even just within your organization trying to host a lunch and learn and teach a concept. Without fail, you have to understand something all the better to be able to teach it. Or as you try and teach something, someone may ask you a question that just shakes the foundation of what you know, and you're like, wow, I hadn't thought about it that way. And so teaching for me has just been this absolutely incredible forcing function for understanding something and being able to communicate about it again, that being one of the core things that I'm thinking about. And then the other facet sort of a related idea is pairing, pair with another developer, pair with a developer who is more senior than you on the team, pair with someone who is more junior than you, pair with someone who's at the same level, pair with the designer, pair with the developer, pair with a product manager, pair with everyone. I cannot get enough pairing. Well, I can, actually. I read a blog post recently about 100% pairing, and I've never gotten anywhere close to that number. But I think a better way to put it is I think pairing applies in so many more contexts than people may traditionally think of it. People sometimes like to compartmentalize and like, pairing is great for big architecture design, but that's about it. And my stance would be pairing is actually great at everything. It is very high bandwidth. It is exhausting, but I have found immense value in every pairing session I've ever had. So, yeah, those are some loose thoughts off the top of my head. Do you have any how to get better protips?

+ +

STEPH: Yeah, that's a wonderful list. And I'm not sure if this exactly applies because it's been a while since I have seen this talk, but there is a wonderful talk by Sandi Metz. I mean, all of her talks are wonderful, but this one is Go Ahead, Make a Mess. And I believe that Sandi refers to or highlights the idea of trying something new and then reflecting on how did it go? And that was one of the areas that I learned early on, one of the ways to help me progress quickly as a developer. Outside of the suggestions that you've already shared around lots of pairing that was one of the ways that I leveled up quickly is to iterate quickly. So I used to really focus on the code that I was writing, and I thought it needed to be perfect before my colleagues could review it. But then I realized that the sooner that I would push something out for feedback, then the faster I would get other more experienced developers' input, and then that helped me learn at an accelerated rate and then also ship more frequently. So I'd also encourage you to just go ahead and iterate quickly. We talk about with software in general, we want to iterate on the code that we are pushing up for other people to look at and then give us feedback on and then reflect on how did it go? What did we learn? What are some areas that we can improve? I feel like that self-evaluation is huge, and it's something that I know that I frankly don't do enough because one, it also prompts us to appreciate the progress that we have made but then also highlights areas where I feel strong in this area, but these are other areas that I want to work on.

+ +

CHRIS: While we're on the topic of talks that have been impactful in our journeys of leveling up as developers, I want to quickly list three that just always come to mind for me: Avdi Grimm's Confident Code, Katrina Owen's Therapeutic Refactoring, and Ben Orenstein's Refactoring from Good to Great. There's a theme if you look across those three talks. They're all about refactoring, which is interesting. That tells you some stories about what I believe about how good software is made. It's not made; it's refactored. That's my official belief, but yeah.

+ +

STEPH: Love it. That's also another great list. [laughs] For additional ways to level up, there are some very specific areas where it could be maybe do code katas or code exercises, or maybe you subscribe to certain newsletters, stay up to date with a language, new features that are being released. But outside of those very specific things, and if folks find this helpful, then maybe you and I can make a fun list, and then we could share that on Twitter as well. But I always go back to the idea of regardless of what level you're at in your career is to think about your specific goals, maybe if you are new to a team and you're new to software development, then maybe you just have very incremental goals of like, I want to learn how to write a test, or I want to learn how to get better at PR review or something very specific. But to have real growth, I think you have to first consider where it is that you want to go and then figure out a way to measure to get there. Circling back to some of the ways that I help my teammates measure that growth, that's one of the things that we talk about. If someone says, "Well, I want to get better at PR review," I'm like, "Great. What does that mean to you? Like, how do you get better at PR review? How can we actually measure this and make it something actionable versus just having this vague feeling of am I better?" I think I've ended up taking this a bit more broad as you were providing more specific examples on how to level up. But I like the examples that you've already provided around education and then trying something outside of your comfort zone. So what's coming to mind are more of those broad strategies of goal setting.

+ +

CHRIS: I think generally, you need that combination. You need how do I set the measure? How do I think about improvement? And then also ideally a handful of tactics that you can try out. So hopefully, we provided a nice balanced summary here in this episode. And hopefully, Tom, if you're listening, you have gotten some useful things out of this conversation.

+ +

STEPH: Yeah, this was fun. We managed to take this topic and make a whole episode out of this. So thanks, Tom, for sending in such a great topic.

+ +

CHRIS: Frankly, when I saw the topic, I was certain this was going to happen. [chuckles] This was an obvious one that was going to fill up the time for us. But yeah, with that, I think we've probably covered plenty here. Should we wrap up?

+ +

STEPH: I'm sure there's more, but sure, let's wrap up.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm.

+ +

STEPH: This show is produced and edited by Mandy Moore.

+ +

CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show.

+ +

STEPH: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed or reach me @SViccari on Twitter.

+ +

CHRIS: And I'm @christoomey.

+ +

STEPH: Or hosts@bikeshed.fm via email.

+ +

CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

Both: Byeeeeeee.

+ +

Announcer: This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+gaB2Gfnz + + ]]> + + Chris Toomey + Steph Viccari + + + 293: Sportstaphors + https://bikeshed.thoughtbot.com/293 + 6c14868c-bc1d-4869-b0b2-ec352f1670ce + Tue, 18 May 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph share a speedy step to restart your rails server and chat about accessibility improvements and favorite a11y tools. They also dive into a tale of database switching and delight in a new Rails query method that returns orphaned records. + 41:17 + no + + + On this week's episode, Chris and Steph share a speedy step to restart your rails server and chat about accessibility improvements and favorite a11y tools. They also dive into a tale of database switching and delight in a new Rails query method that returns orphaned records. +Restart Rails server via tmp/restart.txt (https://twitter.com/christoomey/status/1387799863929212931?s=20) +WebAIM: Constrast Checker (https://webaim.org/resources/contrastchecker/) +IBM Equal Access Accessibility Checker (https://www.ibm.com/able/toolkit) +axe™ DevTools (https://www.deque.com/axe/browser-extensions/) +AccessLint (https://accesslint.com/) +Assistiv Labs (https://assistivlabs.com/) +An introduction to macOS Head Pointer (https://thoughtbot.com/blog/an-introduction-to-macos-head-pointer) +Rails date_select (https://api.rubyonrails.org/classes/ActionView/Helpers/DateHelper.html#method-i-date_select) +Rails strong_migrations (https://github.com/ankane/strong_migrations) +Ruby RBS (https://github.com/ruby/rbs) +Sorbet - Ruby Type Checker (https://sorbet.org/) +Scout APM (https://scoutapm.com/) +Rails 6.1 adds query method missing to find orphan records (https://blog.saeloun.com/2020/01/21/rails-6-1-adds-query-method-missing-to-find-orphan-records.html) +Transcript: +STEPH: People put microphones in front of us. That is their fault, not ours. We just show up. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. Hey Chris, happy Friday. +CHRIS: Happy Friday. +STEPH: How's your week been? +CHRIS: It's been great. I did something that is wildly overdue, but I got a new chair and one day in. But it's also a very familiar chair because it's basically the same -- I think it's the same model as we had at the thoughtbot office. And it's nice to have a chair that is reasonable. And I think my old chair was maybe ten years old or something, deeply embarrassing and absurd like that for such a critical piece of infrastructure in my house. +STEPH: I mean, I guess depending on if it's a good chair. I don't know what the lifespan is of a good chair. [laughs] +CHRIS: I would not describe it as such. +STEPH: [laughs] +CHRIS: I think it was like $100 at Staples. It was a fine chair. It served me well for many years. I'm very slow and cautious with what I consider to be large-scale purchases. I hate the idea of having a thing that I've spent a bunch of money on, but I don't actually like. And these are very solvable problems. But I just tend to drag my feet and over-research and do all those sorts of things. And so finally I was just like, nope, we're going to get a chair, got a chair. Cool. Now I have a chair, and it's good. It's got all of the adjustments, which is what makes it very nice. I'd say Steelcase Leap is the model for anyone that's interested. +STEPH: That's funny. I tend to do the same thing. I tend to drag my feet until I get desperate enough that then I'm forced to make a decision and buy something. I do have an oddly specific question. Do you like chairs with or without the arms? +CHRIS: Oh, with the arms. +STEPH: Really? +CHRIS: Yeah. +STEPH: I am team, no arms. +CHRIS: Where do your arms go if there are no arms to put on the chair? +STEPH: They're always on my lap or on my keyboard. So I just don't rest them on the armrest. +CHRIS: Interesting. I feel like that would put -- I've definitely had small bouts of RSI strain fatigue in my forearms. And so I'm very purposeful with how I'm bracing my wrists. I have a little wrist rest that I put my hands on when I'm using my keyboard because the keyboard is slightly raised up because I have a nonsense mechanical keyboard, of course. +STEPH: Delightful, not nonsense. +CHRIS: Yeah, I love it. I would never trade that in, but I have to make it work and not actually sacrifice my body for a clackety keyboard. [chuckles] But yeah, I think I need some more support for my arms; otherwise, there's too much pressure on my wrists, and things are breaking at weird angles, and that's been my experience. I'm intrigued by the free-flying no arms on the chair approach that you're talking about. This particular model has nine degrees of freedom on the armrest. So I'm able to bring them in and forward and at the exact right height so that they perfectly meet my arm where it would naturally be, and that seems good. That seems like the thing that I want. +STEPH: That makes a lot of sense. But yeah, I'm team no arms. Every time I have them, I can't get them at the right comfortable spot. And I like the freedom of where I can quickly get up and out of my chair and not have arms in the way, which sounds like a very small improvement in my life, but yet it's what I want. +CHRIS: I just like the idea of you sitting there and being like, I need to be able to make a quick escape at any moment; who knows what's going to happen? And I need to be able to run the other way. +STEPH: If there's a gnarly bug, I got to be able to run. I can run away quickly as possible. [laughs] +CHRIS: But in other news, so yeah, new chair that's great. I also recently embraced something in the Rails world that I have known about I think for forever for the entire time that I've worked in Rails, but I've never really used it, which is the tmp/restart.txt file, which my understanding of it is if you touch that file, or if that file exists, Rails will recognize that and will restart the server in development mode. And I think I've always known about this, but I've never used it. And I recognized recently that either I was trying to use a gem that I'd added to the Gemfile, but my server didn't know about it. So I was going to do the thing that I normally do, which is kill the server and then restart the server so CTRL+C and then CTRL+P in my terminal and hit enter, and then wait a bunch of minutes and get distracted, all of the bad things there. And I was like, wait; I remember that there's a thing here. And I don't know why I haven't been doing this for years. It's so much better. I actually went the one step further, and I configured a tmux binding so that tmux prefix and then R will touch tmp/restart in the local directory of the tmux session. That's been very nice, I will say. So I keep moving between branches. And I have environment variables that I need to reload or config initializers that I've made a change to, and I want to load that in. Or a gem that I've added to the Gemfile and I've now installed, but the server doesn't know about. All of these are just so quick now. And why wasn't I doing this the whole time? +STEPH: I saw that you mentioned this on Twitter a couple of days ago, and I was so excited. But at the moment, I bookmarked it for later, but I didn't have time to actually really check it out. And I'm so glad you're bringing it up because I actually just tried it while we're chatting. So I started up my Rails server, and then I did the touch tmp/restart, and this is amazing. This is awesome. I'm very excited. +CHRIS: It just does the thing. +STEPH: It just does the thing. +CHRIS: Yeah, it's so nice. [laughter] +STEPH: Yeah, this is fabulous, almost as good as the pending migrations button. Not quite because that's a very special button, but this is also up there. +CHRIS: It's a very, very good button. [laughs] I really got very enthusiastic about that button, didn't I? But I stand by it. It's a very good button, and this is a very good file. But this file has existed for so much longer, this workflow. And so many times, I have restarted the server and have been annoyed that I had to do it. And my brain just had this answer available. I didn't read a blog post and relearn this thing. I've always known it. And it was this one particular time that my brain was like, "Hey, you know how we're always annoyed by having to restart the server? You know there's another answer, right? I know that you know it because I'm your brain, and I'm telling you this." [chuckles] This is my weird internal monologue. So I'm very happy to be on the other side of that and to share that with as many people as possible who may be, like me, know about this but haven't actually leaned into it, small things that make the Rails world very nice. +STEPH: Well, I'm glad you internalized it and then surfaced it because this is not something that I had heard of before. So I'm very appreciative of it. This is going to be great. +CHRIS: Happy to share the wealth. But yeah, that's some of the stuff that's been up in my world. What's been going on in your world? +STEPH: It's been a rather busy week. Most of that week has been focused on improving the accessibility of existing pages and forms, which is an area that I don't get to spend a lot of time, but each time I do, I really would like to be a pro when it comes to accessibility. Well, that's probably a long journey to become a pro. I would like to become more knowledgeable in terms of accessibility because it is so important. And while working specifically on these accessibility tickets and improvements, I've discovered a few helpful tools that I figured I'd share here. So one of the tools that I've started using is a color contrast tool. It's created by WebAIM or web accessibility in mind. And a number of our headers in our application have a white font that's on a background color, and we were getting warnings that this isn't very accessible and that there's not enough contrast. So with the Contrast Checker, you can provide the foreground color and the background color, and then it's going to tell you that contrast ratio. So if you're wondering, well, what's a good ratio? That's a great question. And the W3C Accessibility Guidelines recommend a contrast ratio of 4:5:1 for normal texts and 3:1 for larger texts. Larger text is anything that's typically around 18 px, 18.5 px, or larger. So the color contrast tool has been really helpful because then that's been very easy that we give the blue that we're using, and then we can just darken it a bit to improve that contrast. And then we apply that everywhere throughout the app. The other tool that I've been using that I'm really excited about it's a browser extension called the IBM Equal Access Accessibility Checker. Is that something you've heard of or used before? +CHRIS: I have not heard of that. +STEPH: I would love to know what you currently use for accessibility, and I'll circle back to that in just a moment. But for this particular browser extension, I'm pretty sure they have it for multiple browsers. I'm using Chrome. So I've installed the Chrome extension. Once you have it installed, you can open up the browser console and then tell it to scan the page that you're on. And then it generates a really helpful report that has all the high-level offenses, which are called violations. It also has warnings and recommendations. And then if you click on a specific issue, then the right-hand area shows a detailed description of the offending HTML, what's wrong, why it's important, which I really appreciate that part, and then a couple of examples of how to fix it. So it's been a really nice way as we are working to improve the accessibility of form. We actually have feedback to know that we are making progress and that we are improving the accessibility of that particular page. And then circling back, I'm curious, do you have any particular tools that you use when it comes to improving accessibility or any standards that you tend to follow? +CHRIS: Yeah, this is a very apropos question. I'm working on a new project now, and accessibility is definitely something that I want to consider on every project, but it's all the more so important for this particular project, or it's something that we're, as a team, collectively really embracing early on and wanting it to be a core focus of how we're building out the application. That said, I will say that I'm accessibility aware but far from an expert and still very much learning. But some of the things that I have used are the axe DevTools. I forget what the acronym actually stands for there, but we can certainly include a link in the show notes. But those are DevTools that allow you to, I think, do some color contrast checking actually in the browser just right there, which is really nice. There's also AccessLint, which is a project that scans pull requests and, where possible, does static analysis of the HTML. And that's actually by some former thoughtboters. So it's always nice to have that in the reference. +There's actually a new tool that I've been looking at. I haven't actually tried it out yet, but it's from a company called Assistiv Labs, Assistiv without an E interestingly at the end. But their tool is, as far as I can tell, it allows you to use screen readers and other tools but across various platforms so that you sort of turn on -- It's very similar to if you've ever used an emulated Internet Explorer session because you're working on not an Internet Explorer machine, but you want to make sure your site works in Internet Explorer, same sort of idea, I believe. But it allows you to do the same approach for accessibility. So using a screen reader or using what the native accessibility technologies are on various platforms and being able to test across a wide range of things. So that's definitely one that I'm going to be exploring more in the near future. +And beyond that, there are a handful of static analysis-based tools that I've used. So Svelte actually has some built-in stuff around accessibility. Because they are a compiler, they can do some really nice things there, and I really appreciate that that is a fundamental concern that they've built into the language, and the framework, and the compiler, and all of that. And I've also used ESLint A11y, which is the acronymnified version of the word accessibility. But that again, static analysis, so it can only go so far. And unfortunately, accessibility is one of those things that's hard to get at from a static analysis point of view, but it's still better than nothing. And it allows you to have a first line of defense at the code as you're authoring it. So that's a smattering of things. I've used some of them. I'm interested in others of them. But this is definitely an area that I'm going to be exploring a bunch more in the near future. +STEPH: I like that you brought in the static analysis tools because that's the other thing that's been on my mind as we're making these accessibility improvements; that's been great. And we can run this particular browser extension to then check for warnings or issues on the page but then looking out for regressions is on my mind. Or as we're introducing new pages and new forms, how do we make sure that those are up to standard if someone forgets to run that extension? So I really like the idea of -- There's AccessLint that you mentioned, which will then scan PRs for accessibility improvements. That sounds really great. I'm also intrigued if there's a way to also -- I don't know if maybe tests are a good way to also look for any sort of regressions in terms of changes that we've made to a page. I don't know what those tests would look like. So I'll have to think on that some more, but I think some people at thoughtbot have thought about it. +CHRIS: My understanding is the testing library suite of testing frameworks, so it's like testing library React, testing library, et cetera. It's primarily used in the JavaScript world, although there is Cypress, which is more of a browser-level automation. But it fundamentally works from not exactly an accessibility but a -- It doesn't allow you to do DOM selectors. It really tries to hide that. And it says, "No, no, no. You're not going to be digging in and finding the class name of this thing because guess what? A user of your application can't do that." What we want are – Typically, it's like find by label or find by things that are accessibility available or just generally available to users of your application. So whether it's users that are just clicking around or if they're using any sort of assistive technology, the testing library framework forces you in that direction. You can't write a test if your code is inaccessible tends to be the way it plays out, and it really nudges you in that direction. So it's one of the things that I really love about that. And I actually miss it when I'm working in a Capybara test suite because, as far as I know, there is not a Capybara testing library variant of it. And really, at the end of the day, it's just a bunch of functions to allow you to select within the context of the page. But again, it does it from that standpoint, and I'm all about that. +STEPH: Yeah, that's really nice. That's a good point. Yeah, I don't think Capybara has that explicitly. I know that you have to use specific parameters. Like, if you want to access something on the page that is hidden, that's not something you can just do easily. You have to specify: I'm looking for an element that is hidden on the page. But otherwise, I don't think it goes out of its way to prevent you from doing that. There is an article that this conversation about accessibility made me think of. There's a really fun blog post written by Eric Bailey, who has been or who is a champion of accessibility at thoughtbot and has written a lot of great content around making the web more accessible. And in addition to publishing with the thoughtbot blog post, he has written for a number of publications. And the article that comes to mind that he published on the thoughtbot blog posts is An Introduction to macOS Head Pointer, and we'll link to it in the show notes. But he does a great job walking through what the head pointer is on macOS and then how to use it. And he uses his eyebrows to essentially move the mouse and then click on certain buttons or click on certain links on the screen. And it's incredible. So if you need a little bit of accessibility and joy in your life, I highly recommend checking out that article. +CHRIS: Yeah. Eric has absolutely just been such a fantastic champion of accessibility. And he's definitely someone that I think of constantly as being -- I think he's involved with the Accessibility Project. He writes on CSS Tricks. He's around the internet just being the hero we need because accessibility is such a critical thing. And I'm a deep believer in the idea that accessible applications are better for everyone. And I so appreciate the efforts that he's putting in out there. Thanks, Eric. +STEPH: Thanks, Eric. And then, on a slightly separate note, I have a slight complaint that I'd like to file. And this one is with Rails specifically. And I'm filing this complaint with the understanding that I'm also very spoiled in terms of Rails does so much, and I'm very appreciative of how much Rails does for me and for us. But specifically, while working on accessibility for a date of birth form field, so it's a form field with three different selects, so you have your month, day, and year. And while creating this, there's a very helpful Rails method that's called date_select, where then you can generate all three of those select fields. And you can even specify the order in which you want them generated, but this particular function doesn't have a way to make it accessible. So you can generate a label for each option that's in the select dropdown. And there's no parameter. There's nothing you can pass through. It doesn't automatically generate it for you. +So I was in a spot where I was updating a form that's using the Rails dateselect. I can't use dateselect and make an accessible dropdown selection for date of birth. So instead, what I had to do is I had to split it out. I had to move away from using dateselect, and instead, I'm using selectmonth and then selectday and selectyear because from there, I then can pass in; in my case, I'm using aria-label to provide a label because I don't actually want the label to show up on a screen, which could be another accessibility concern because we do have the birth date label for those three sections. But then we still want at least each text field to have a label, even if it's only visible to screen readers. So then that way, if someone is selecting from year, they understand they're selecting from year or for month they're selecting from month. So by using selectyear and selectday and selectmonth, I could specify the aria-label as month, day, or year, but I couldn't do that with the dateselect. And I just realized that there's probably a number of date of birth forms out there that aren't accessible because us Rails developers are leveraging this existing method. So it just seems like a really good opportunity to improve date_select to be able to pass in a label or generate one automatically. +CHRIS: Wow. I'm surprised that's the state of the art that we're currently at. I really wonder if there have been conversations or if there are fundamental limitations because I'd be surprised if such a core piece of the Rails world someone hadn't brought this up in the issues. What's the story there? Because I'm guessing there's a story there. Although flipping it around, I wonder -- I've never loved that input sequence; as an aside, like three different selects, that's not how I think of my birthday. My birthday is one thing. It's not three things that we smash together. But I wonder are we at a point now where IE 11 usage is so small that we can use a native date_select input and then have a polyfill -- And then I start to trail off because I don't know what the story is for. Like, I think Safari doesn't do a great job, and I forget where it's at right now. And what about mobile Safari? And wouldn't it be nice if everything was just easy and everybody kept up? [laughter] But that's an aside. But yeah, that's part of my question here, is like, can we just not use that thing at all? Like, the three select dropdown version of picking a date of birth because, man, that's my least favorite way to do it. +STEPH: Yeah. I'm with you. I'm also curious if there is a story behind this and also if anyone has a different opinion, and I'd love to hear it. Because this has been my experience in digging through the docs is I would date_select, and I could not find a way to pass in a label or have one generated to make it accessible. So then that prompted me to use the three different methods, which, by the way, is fine. It made me stop and pause to think this is the method that most people recommend the usage of in terms of creating those three different select fields for a date of birth or for any particular date that you're supplying; it does not have to be a date of birth. So it also surprised me that then we couldn't make it accessible. So yeah, I was a bit miffed in the moment. [laughter] I had to walk myself back and be like, well, if I want to make the world a better place, I should help make the world a better place. And that started with changing the code in this codebase. But then also it means looking into Rails to see if there's an improvement that I could help with there. +CHRIS: This is what we do: we take our moments of miffed, and we turn them into positive action in the world. This is what we want to see. [chuckles] +STEPH: I figure the least I can do is share a blog post or something on Twitter that shows what it was before and then using the new dateselect functions because that is reasonable, although working with a form is a bit different. It got a little tricky there in terms of making sure that each value for each select field is still being passed within the expected nested parameter. And some of that was available in the public API for selectyear and select_day, but it's not as well documented. So I'm like, well, this seems to be intentionally public, but it's not documented, so I feel a little nervous about using this. Yeah, that's it. I just wanted to share my annoyance with Rails [laughs] or the fact that it made me work so hard to have a date of birth field. +CHRIS: You joke, but that's a lot of why we use Rails is because we want these common regular things that we're doing to be as easy as possible, to require as little code on our part as possible but also this sort of thing like there's a lot of subtlety and stuff. Accessibility is one of those things that I want a framework that has security, and accessibility, and ease of use, and all of these things just baked in, so I don't have to think about it every time. It turns out having a date of birth, or generically any date field, is going to come up in web applications a lot, it turns out. And so having all of that stuff covered is frankly what I expect of a framework like Rails. So I'm totally on board with your being miffed here. +STEPH: Yeah. Those are all really valid points. So I'm with you. What else has been up in your week? +CHRIS: Well, we've been leading up to this, I think, for many weeks. I did a Rails 6.0 upgrade a while back, and a big reason for that was partly just to get on the current version of Rails but also because I wanted to open the door to database switching, and finally, this week, I tackled it. And let's tell a tale because there was a bit of an adventure, if we're being honest. Fundamentally, all the stuff there makes sense. I'm happy with the end configuration, but there was a surprising amount of back and forth. I broke the app more times than I want to actually announce on a podcast, but I broke it only for a brief period of time. It's fine. It's fine. Everybody's fine. [laughs] I feel a little bad about it, but these things happen. But yeah, it was interesting, is how I'll describe it. +So fundamentally, Rails just has nice configuration for it. So at a high level, you're introducing your config/database.yml. Instead of it just being production is this URL, you now say primary is this replica or follower, whatever you want to name it is this. So you have now two configurations nested within your production config. And then in your ApplicationRecord, you inform Rails that it connects_to, and then you define a Hash for writing goes to the primary, reading goes to the follower. And you have to sync those up with the thing you just wrote in the config/database.yml but fundamentally, that kind of works. That makes it possible in your application to now switch your database connection. The real magic comes in the config environment production file. And in that, you specify that you want Rails to use a database resolver that says GET requests go to the replica, and anything that is not a GET request goes to the primary. So anytime you're writing data, anytime you're changing data within the system, that's going to go to the primary. +And there's also a configuration that, as far as I can tell, gives a session affinity. So for the next two seconds after that, even if you make a GET request subsequently right following it, so you make a right, you POST, and then immediately after that, you do a GET. Like, you create an object, and then you get redirected to the show page for that object, Rails will continue to go to the primary. I think it's probably using a cookie or something to that effect, but you can configure that time span. So you can say like, "Actually, we see that our follower lags behind a little bit more, so let's give it a five-second timeout where all requests for that user will then go to the primary." But otherwise, once that timeout clears, then you're going to switch back, and you're going to go to the follower, and all GET requests will happen to the follower. And that's the story. You have to configure that, and then it works. +STEPH: I always love when you start these out with "I have a tale to tell." I very much enjoy these adventures. And you also answered my question in regards to if you immediately just created something, but then you do a fetch that's very close to after you just created it and how that gets rendered. So that was perfect. +CHRIS: Frankly, the core configuration is very straightforward, and it's very much in line with what we were just talking about of; this is what I want from Rails: make this thing very easy, hide the details behind the scenes. But as I said, there's a bit of a tale here. So that was the base configuration. It sort of worked but then immediately upon deploying it to production -- So we deployed it to staging first just to test it out. Staging was fine, as is often the case. Increasingly, I'm leaning into Charity Majors' idea of you got to test in production. You're testing in production even if you say you aren't. So once it got to production, we started seeing a bunch of errors raised or a handful of errors. And they were related to a handful of controller actions, which are GET requests, so they're either show or index, but in them, they were creating, or they were trying to create data. And so we were getting an error that was read-only connection error or something to that effect, ActiveRecord read-only, I think, was the error class. And that makes sense because I told it, "Hey, whenever you get a GET request, you're going to use that follower." But the follower is a read-only database connection because it's a follower, and so it was erroring. +It was interesting because when this happened, I was like, wait, what? And then I looked into it. And it's frankly fine at all the levels. It is okay to create a record in a GET request as long as that creation is idempotent. You create if it doesn't exist, and then from there on, you use that same one. That still fits within the HTTP rules of idempotents, and everybody's fine with that, except for the database connection. Thankfully, this is relatively easy to work around. You just need to explicitly within that controller action say, "Use the right database, use the primary." And the way I implemented that, I wrote a method within ApplicationRecord that was with right DB connection, and then it takes a block, and you yield to that block. It's basically just proxying to another similar thing. And it's very similar to wrapping something in a transaction; it sort of feels like that. It's saying just for this point in time, switch over and use the primary because I know that I'm going to be having some side effect here. +STEPH: Wow. That's so fun. I'm sure it was not fun for you. But as me hearing the story later, that's fun in regards to I hadn't thought about that idea of you're telling all the GETs you can only go to the read, and now you're also trying to create. I am feeling nervous in terms of local development. So if you're working on a new controller and if you have a fetch or GET action, but you're also creating something, you haven't seen another controller that is demonstrating that strategy that needs to be used. Is it just going to work locally? I imagine it does because it was working for the other code that you were running that didn't yet have that strategy in place. So I'm feeling nervous in terms of someone could easily miss that. +CHRIS: I think there are a couple of different questions in what you just said. So let me try and answer all of the ones that I think I heard. So for local development, your database/config.yml is still going to be the same as it was. So you're just connecting to database namedevelopment. There's only one of them; there's no primary follower. So this is a case where you have a discrepancy between production and development, which is always interesting. And maybe that's something to poke at because ideally, I want as little gap there as possible. But this is one of those cases where I'm like, eh, I don't think I'm going to run two databases locally and have one be a follower. That feels like too much to manage. Under the hood with that right DB connection method that I talked about where you want to explicitly opt-in, in the case that we're in development, I just yield directly to the block. So instead of doing the actual database switching at that point, the method is basically saying, "If we're in production, then switch to the primary and yield and if we're not in production, then just yield." And so it'll just run that code, and it'll connect to the only database. More generally, I have the connectsto configuration; I wrapped that. So that's in ApplicationRecord where you're saying, "Hey, connect to these databases based on this logic," that is wrapped if we're in production check as well. And the same thing in the top-level configuration that says -- We're getting ahead of ourselves in the story because this is the end state that I got to. It's not where I started, and I screwed some stuff up in here, but basically, all of the different configuration points, my end result was to wrap them in a check that we are in production. +STEPH: Okay. Sorry if I rushed your story. I was already thinking ahead to how could we accidentally goof this up? That makes a lot of sense for the method that's with right DB connection, that method that then it's going to check if we're in production, then we can use a primary follower strategy; otherwise, just use the database that we know of. So that helps a lot in answering those questions. And then we can pause and then get to my question later. But my other question that I'm curious about is what helps us prevent the team from making this mistake in terms of where we're adding a new controller, we add a new GET action, and we are also creating data, but then someone doesn't know to add that strategy that says, "Hey, you are allowed to go to the primary to also get data but also to write data too." And I'll let you take it away. +CHRIS: I don't know that I have a great answer to that one if we're being honest. As I saw this, it was very easy to find -- I think there were three controller actions that had this behavior in the system that I was working on. They all threw errors. It was very easy to just wrap them in this extra method and fix that, and then we're good, and I haven't seen that error again. As for preventing it from new instances of this behavior, I don't have a good answer other than potentially you share this information within the team and then PR review. Ideally, someone's like, "Oh, this is one of those things you've got to wrap it in the fancy database switching logic." Potentially, and I don't actually think this would be possible, but there's a chance that RuboCop or other static analysis type thing could look inside any index or show action and say, "I see a create or an update or any of the methods." But again, Rails is so hard to do static analysis on that I would be surprised if were actually feasible to do that in a trustworthy way, probably worth a poke because this is the sort of thing that can easily sneak out. But potentially, my answer is, well, it'll blow up pretty loudly the first time you do it. And then you'll just fix it after that, which is not a great answer. I'm open to that being a mediocre answer at best. +STEPH: [chuckles] Yeah. That's a fair answer. Just because I pose a question, I don't know if there necessarily is a great answer to it right away. And disseminating that information to the team to then having the team be able to point that out also sounds very reasonable but then still hashes that danger of someone overlooking it. The static analysis is an interesting idea, sort of like strong migrations. As you're introducing a new migration, strong migrations will do a wonderful job of showing you concerns that it has with the migration that you've added. And this is all just theoretical dreams and hopes because, yeah, that would help prevent some of those scenarios. +CHRIS: It's interesting now that this is the second time we've discussed static analysis in this very episode. Clearly, it's a thing that I want more of in my world, and yet I work in languages like Ruby that are notoriously difficult to perform static analysis on. +STEPH: I had a moment today writing a method that was currently just returning a string each time but then I was about to update that method. I was looking for a way like, well, maybe I don't always want a string. Maybe I actually want a Boolean here. But in the other case, I want a string. And the person I was pairing with they're like, "You could return -- [inaudible 29:31] Boolean in one case and then a string in the other case. Like, this is Ruby." [laughs] I was like, true, but I feel bad about it, and I don't love it. And we just had a phone conversation around that. If you're in the Ruby world following the more functional programming or type strictness and where you're returning specific types or trying to return a consistent type, it's ideal. But then also in Ruby, it's like it's Ruby, so sometimes you can finagle the rules a little bit. +CHRIS: YOLO, as they say. +STEPH: [laughs] +CHRIS: Yeah, I'm definitely interested to see where projects like Sorbet and...I forgot what the core Ruby typed thing in Ruby 3.0 is called, but either of those. I'm really intrigued to see where they go and how the Ruby community either adopts or doesn't. I wouldn't be surprised if that were part of the outcome there. I've been impressed with the adoption of TypeScript and JavaScript, which is also a very, very free language, not quite to the degree that Ruby is. But yeah, it remains to be seen what will happen on those fronts. +But continuing back to our saga, so we've now had the read-only error, we've fixed those, just wrapped them in blocks, and said, "Explicitly connect to the primary." So the next thing that I did after that, I realized that my configuration was a little bit flimsy is probably the best word to describe it. I was explicitly creating a new environment variable with the URL, the Postgres URL of the follower. And so I was using that environment variable to define where the URL like the Postgres URL of the follower database -- But I realized if Heroku comes in and does any maintenance on that Postgres instance, it's possible that the AWS IP address or other details of it will actually change and so that Postgres URL will no longer be valid. So that's one of the things that I rely on Heroku for, is to maintain my databases for me. But they will update, say, the DATABASE_URL environment variable if they change out your database. But now, I had broken that consistency. And so I'd set us up for somewhere down the road this will break, and I realized that because Heroku reached out and said, "Hey, your follower database needs maintenance." And I was like, oh, no. So, I tried to get it from -- It turned out, in this case, it didn't actually change. They were able to swap it out in place, but I wanted to add a little bit of robustness around that. +And so I actually reached out, and Dan Croak, former CMO of thoughtbot, actually had written a wonderful blog post about how to configure this and particularly how to configure it in the context of Heroku. And he described how to use the Heroku naming scheme for the environment variables. They happen to have colors in them. So it's like Heroku Postgres cyan URL or orange URL or purple URL. And so he defined a scheme where you set an environment variable that describes the color, and then it can infer the database URL environment variable from that. And then went the one step further to say, "If that color environment variable is set, then treat as if we are configured for database switching. But if it is not set, even if we're in production, pretend like we don't have database switching," which that was another nice feature that I hadn't built in the first place. When I first configured this, I just said, "Production gets database switching. And if we're in production, then database switching is true," but that's actually not something that I want. I want to be able to say, "Upgrade our follower," at some point or do other things like that. And so I don't want to be locked into database switching on production. So that was a handful of nice configurations that I wanted to get to. +Unfortunately, when I tried to deploy that switch, man, did it break. It broke, and then I was like, oh, I see I did something wrong there. So then I tested again on staging. Staging was fine. And then I went to production, and it broke again. And this happened like three times in one day. I felt like a terrible programmer. I had no idea what I was doing. Turns out that staging and production had different environment config files, and so their configurations were fundamentally different. They also had a different configuration for the database level. So one of the things I did as part of this was to clean those up and unify them so that staging was production with some environment variables to config it, but identically production, which is definitely a thing that I believe in, and I want basically all the time. I don't think we should have a distinct staging environment config that is wildly different. It should only vary in very small ways, basically just variables that say, "This is where the database is for staging," but otherwise be exactly configured as production. So I eventually got on the other side of that, fixed everything, have a nicely Heroku-fied color-based environment variable scheme, which is a bit of a Rube Goldberg machine, but it works. And I was able to hide that config in one place. And then everything else just says, "If there is a database follower URL defined, then use it." But yeah, so that was the last hard, weird bit of it. +And then the only other thing that I did was I realized that this configuration was telling the Rails server how to behave, but there are also background jobs. And this application actually happens to have a ton of background job traffic. And so I did a quick check of those, and there were a handful of background jobs that were read-only. A lot of them were actually sending data to external systems, so to analytics or other email marketing or things like that. And so constantly, as users are doing anything in the application, there are jobs that are queued that aggregate some information, maybe calculate some statistics, and then push it to another system. But those are purely read-only when those jobs execute. And so I was able to add another configuration which said, "Use the read-only connection and configure that to wrap those particular sidekick jobs." And with that, I think I have a working database switching configuration that will hopefully give us a lot of headroom in the future. That's the idea, that's the dream, but we will see. +STEPH: That is quite the saga between having GET requests that create data and then also the environment inconsistencies, which is a nice win that then you're able to improve that to make those environments more consistent. And then the background jobs, yeah, that's something that I had not considered until you just brought it up, and then being able to opt-out of the database switching sounds really nice. In regards to moving in this direction, you're saying gave you a lot of headroom for this; when it comes to monitoring performance, is there anything in place to let you know how it's doing? +CHRIS: I love that I knew that this was going to be your question. I love that this is your question because it's a very good question. And unfortunately, in this case, it's actually somewhat unsatisfying. So as is my typical answer for this, we're using Scout as the application performance monitoring tool on this. And I was able to go in and monitor what it looked like a week ago, what it looked like after I made the change, and it was a little better. And that's all I can say about it. But that's fine. The idea with this, and at least in the way I was thinking about it, is this should get better at the margins. On the days where we have a high spike in traffic, those are the days where the database is actually working hard. They shouldn't make the normal throughput of the application that much higher in the regular case; it's for those outlier instances. To that end, though, I did analyze it. And so the average response time got 2% to 3% better in that week-by-week comparison, which was fine. The 95th percentile response time, so starting to get out to those margins, starting to get to the long tale of where stuff gets -- a couple of requests came in at the same time, and the application had to try a little harder, those got 8% to 9% better. That shape of improvement where for most requests, nothing really changed for some of the requests that used to be a little bit slower; those got a little bit better. That's the shape of what I would hope to see here. And it remains to be seen. This application has particular traffic patterns where they'll encourage a lot of users to be using the app at the same time. And historically, those have been somewhat problematic, and we've had to really work to shore up the performance in those cases. That's where I'm really interested to see how this goes. It would be hard to replicate those traffic patterns at this point. So I don't have a good way to really stress test this, but my hope is that for those cases, things will just hum along and be happy. +STEPH: That makes a lot of sense and something that would be hard to measure, but the fact that you already see a little bit of improvements that's encouraging. +CHRIS: But yeah, certainly, if I get a chance to see what that looks like in the near term, I will respond back and let you know how this has played out. But overall, now the configuration seems pretty stable. I think we're in a good spot. Hopefully, we won't have to do too much proactive management around this. And ideally, it just buys us a little bit of headroom. So that is certainly nice. But with that, with your wonderful question getting to the heart of the issue, I think that wraps up the saga of the database switching. +STEPH: Well, I appreciate you sharing that saga. That's really helpful. I've been very excited to hear about how this goes because I haven't gotten to work on a project that's going to use database switching just yet. And now I know all the inside baseball. I'm trying to use sports metaphors here as to how to do this for when I get to work with database switching. +CHRIS: Sports de force. +CHRIS: Along the lines of new stuff, there is something I'm excited about. So in juxtaposition to my earlier statement or my earlier grievance where friends don't let friends use dateselect in regards to trying to keep the web accessible, I do have some praise for something that's being added in Rails 6.1 that I'm excited about. And it's a really nice method. It's a query method that can be used to find orphan records. So if I'm writing a query that is then looking for some of these missing records, so if I have my table -- I didn't come with a great example today, so let's just say we have like table A and then we're going to leftjoins on table B. And then we're going to look for where the ID for table B is nil, so then that way we find where we don't have that association that it's missing. And so leftjoins does this for us nicely. And then I always have to think about it a little bit where I'm like, okay, I want everything from table A, and I don't want to exclude anything in table B if there's not a match on the two. And so then I can find missing records that way or orphaned records that way. The method that's being introduced or has been introduced in Rails 6.1, so anyone that's on that new-new, there is the missing method. So you could do tableA.where.missing and then provide the table name. So there's a really nice blog post that highlights exactly how this method works, so I'll use the example that they have. So for where job listings are missing a manager, so you could do JobListing.where.missing(: manager), and then it's going to perform that leftjoin for you. And it's going to look for where the ID is nil. And I love it. It's really nice. +CHRIS: That sounds excellent. That's definitely one of those things that I would have to sit down and squint my eyes and think very hard, really anything involving left_joins otherwise center. Any joins always make me have to think and so having Rails embrace that a little bit more nicely sounds delightful. +STEPH: Yeah, it sounds like a nicety that's been added on top of Rails so that way we don't have to think quite as hard for any time; we want to find these orphaned records, and we know that we can use this new missing method. +CHRIS: On the one hand, I feel bad saying, "I don't want to think that hard." On the other hand, that's literally our job is to make it so that we encode the thinking into the code, and then the machines do it for us. So it's kind of the game, but I still feel kind of bad. [laughs] +STEPH: Well, it's more thinking about the new stuff, right? Like, if it's something that I've done repetitively, finding orphan records is something I've done several times, but I do it so infrequently that then each time I come back to it, I'm like, oh, I know how to do this, but I have to dig up the knowledge. How to do it is that part that I want to optimize. So I feel less bad in terms of saying, "I don't want to think about it," because I've thought about it before. I just don't want to think about it again. +CHRIS: I like it. That's a good framing. I've thought about this before. Don't make me think about it again. [chuckles] +STEPH: Exactly. On that note, shall we wrap up? +CHRIS: Let's wrap up. +STEPH: The show notes for this episode can be found at bikeshed.fm. +CHRIS: The show is produced and edited by Mandy Moore. +STEPH: Thanks, Mandy. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show. +CHRIS: If you have feedback for this or any of our other episodes, you can reach us at @bikeshed. And you can reach me @christoomey. +STEPH: And I'm @SViccari. +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. + + accessibility, rails, database, database switching, sql + + On this week's episode, Chris and Steph share a speedy step to restart your rails server and chat about accessibility improvements and favorite a11y tools. They also dive into a tale of database switching and delight in a new Rails query method that returns orphaned records.

+ + + +

Transcript:

+ +

STEPH: People put microphones in front of us. That is their fault, not ours. We just show up. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey Chris, happy Friday.

+ +

CHRIS: Happy Friday.

+ +

STEPH: How's your week been?

+ +

CHRIS: It's been great. I did something that is wildly overdue, but I got a new chair and one day in. But it's also a very familiar chair because it's basically the same -- I think it's the same model as we had at the thoughtbot office. And it's nice to have a chair that is reasonable. And I think my old chair was maybe ten years old or something, deeply embarrassing and absurd like that for such a critical piece of infrastructure in my house.

+ +

STEPH: I mean, I guess depending on if it's a good chair. I don't know what the lifespan is of a good chair. [laughs]

+ +

CHRIS: I would not describe it as such.

+ +

STEPH: [laughs]

+ +

CHRIS: I think it was like $100 at Staples. It was a fine chair. It served me well for many years. I'm very slow and cautious with what I consider to be large-scale purchases. I hate the idea of having a thing that I've spent a bunch of money on, but I don't actually like. And these are very solvable problems. But I just tend to drag my feet and over-research and do all those sorts of things. And so finally I was just like, nope, we're going to get a chair, got a chair. Cool. Now I have a chair, and it's good. It's got all of the adjustments, which is what makes it very nice. I'd say Steelcase Leap is the model for anyone that's interested.

+ +

STEPH: That's funny. I tend to do the same thing. I tend to drag my feet until I get desperate enough that then I'm forced to make a decision and buy something. I do have an oddly specific question. Do you like chairs with or without the arms?

+ +

CHRIS: Oh, with the arms.

+ +

STEPH: Really?

+ +

CHRIS: Yeah.

+ +

STEPH: I am team, no arms.

+ +

CHRIS: Where do your arms go if there are no arms to put on the chair?

+ +

STEPH: They're always on my lap or on my keyboard. So I just don't rest them on the armrest.

+ +

CHRIS: Interesting. I feel like that would put -- I've definitely had small bouts of RSI strain fatigue in my forearms. And so I'm very purposeful with how I'm bracing my wrists. I have a little wrist rest that I put my hands on when I'm using my keyboard because the keyboard is slightly raised up because I have a nonsense mechanical keyboard, of course.

+ +

STEPH: Delightful, not nonsense.

+ +

CHRIS: Yeah, I love it. I would never trade that in, but I have to make it work and not actually sacrifice my body for a clackety keyboard. [chuckles] But yeah, I think I need some more support for my arms; otherwise, there's too much pressure on my wrists, and things are breaking at weird angles, and that's been my experience. I'm intrigued by the free-flying no arms on the chair approach that you're talking about. This particular model has nine degrees of freedom on the armrest. So I'm able to bring them in and forward and at the exact right height so that they perfectly meet my arm where it would naturally be, and that seems good. That seems like the thing that I want.

+ +

STEPH: That makes a lot of sense. But yeah, I'm team no arms. Every time I have them, I can't get them at the right comfortable spot. And I like the freedom of where I can quickly get up and out of my chair and not have arms in the way, which sounds like a very small improvement in my life, but yet it's what I want.

+ +

CHRIS: I just like the idea of you sitting there and being like, I need to be able to make a quick escape at any moment; who knows what's going to happen? And I need to be able to run the other way.

+ +

STEPH: If there's a gnarly bug, I got to be able to run. I can run away quickly as possible. [laughs]

+ +

CHRIS: But in other news, so yeah, new chair that's great. I also recently embraced something in the Rails world that I have known about I think for forever for the entire time that I've worked in Rails, but I've never really used it, which is the tmp/restart.txt file, which my understanding of it is if you touch that file, or if that file exists, Rails will recognize that and will restart the server in development mode. And I think I've always known about this, but I've never used it. And I recognized recently that either I was trying to use a gem that I'd added to the Gemfile, but my server didn't know about it. So I was going to do the thing that I normally do, which is kill the server and then restart the server so CTRL+C and then CTRL+P in my terminal and hit enter, and then wait a bunch of minutes and get distracted, all of the bad things there. And I was like, wait; I remember that there's a thing here. And I don't know why I haven't been doing this for years. It's so much better. I actually went the one step further, and I configured a tmux binding so that tmux prefix and then R will touch tmp/restart in the local directory of the tmux session. That's been very nice, I will say. So I keep moving between branches. And I have environment variables that I need to reload or config initializers that I've made a change to, and I want to load that in. Or a gem that I've added to the Gemfile and I've now installed, but the server doesn't know about. All of these are just so quick now. And why wasn't I doing this the whole time?

+ +

STEPH: I saw that you mentioned this on Twitter a couple of days ago, and I was so excited. But at the moment, I bookmarked it for later, but I didn't have time to actually really check it out. And I'm so glad you're bringing it up because I actually just tried it while we're chatting. So I started up my Rails server, and then I did the touch tmp/restart, and this is amazing. This is awesome. I'm very excited.

+ +

CHRIS: It just does the thing.

+ +

STEPH: It just does the thing.

+ +

CHRIS: Yeah, it's so nice. [laughter]

+ +

STEPH: Yeah, this is fabulous, almost as good as the pending migrations button. Not quite because that's a very special button, but this is also up there.

+ +

CHRIS: It's a very, very good button. [laughs] I really got very enthusiastic about that button, didn't I? But I stand by it. It's a very good button, and this is a very good file. But this file has existed for so much longer, this workflow. And so many times, I have restarted the server and have been annoyed that I had to do it. And my brain just had this answer available. I didn't read a blog post and relearn this thing. I've always known it. And it was this one particular time that my brain was like, "Hey, you know how we're always annoyed by having to restart the server? You know there's another answer, right? I know that you know it because I'm your brain, and I'm telling you this." [chuckles] This is my weird internal monologue. So I'm very happy to be on the other side of that and to share that with as many people as possible who may be, like me, know about this but haven't actually leaned into it, small things that make the Rails world very nice.

+ +

STEPH: Well, I'm glad you internalized it and then surfaced it because this is not something that I had heard of before. So I'm very appreciative of it. This is going to be great.

+ +

CHRIS: Happy to share the wealth. But yeah, that's some of the stuff that's been up in my world. What's been going on in your world?

+ +

STEPH: It's been a rather busy week. Most of that week has been focused on improving the accessibility of existing pages and forms, which is an area that I don't get to spend a lot of time, but each time I do, I really would like to be a pro when it comes to accessibility. Well, that's probably a long journey to become a pro. I would like to become more knowledgeable in terms of accessibility because it is so important. And while working specifically on these accessibility tickets and improvements, I've discovered a few helpful tools that I figured I'd share here. So one of the tools that I've started using is a color contrast tool. It's created by WebAIM or web accessibility in mind. And a number of our headers in our application have a white font that's on a background color, and we were getting warnings that this isn't very accessible and that there's not enough contrast. So with the Contrast Checker, you can provide the foreground color and the background color, and then it's going to tell you that contrast ratio. So if you're wondering, well, what's a good ratio? That's a great question. And the W3C Accessibility Guidelines recommend a contrast ratio of 4:5:1 for normal texts and 3:1 for larger texts. Larger text is anything that's typically around 18 px, 18.5 px, or larger. So the color contrast tool has been really helpful because then that's been very easy that we give the blue that we're using, and then we can just darken it a bit to improve that contrast. And then we apply that everywhere throughout the app. The other tool that I've been using that I'm really excited about it's a browser extension called the IBM Equal Access Accessibility Checker. Is that something you've heard of or used before?

+ +

CHRIS: I have not heard of that.

+ +

STEPH: I would love to know what you currently use for accessibility, and I'll circle back to that in just a moment. But for this particular browser extension, I'm pretty sure they have it for multiple browsers. I'm using Chrome. So I've installed the Chrome extension. Once you have it installed, you can open up the browser console and then tell it to scan the page that you're on. And then it generates a really helpful report that has all the high-level offenses, which are called violations. It also has warnings and recommendations. And then if you click on a specific issue, then the right-hand area shows a detailed description of the offending HTML, what's wrong, why it's important, which I really appreciate that part, and then a couple of examples of how to fix it. So it's been a really nice way as we are working to improve the accessibility of form. We actually have feedback to know that we are making progress and that we are improving the accessibility of that particular page. And then circling back, I'm curious, do you have any particular tools that you use when it comes to improving accessibility or any standards that you tend to follow?

+ +

CHRIS: Yeah, this is a very apropos question. I'm working on a new project now, and accessibility is definitely something that I want to consider on every project, but it's all the more so important for this particular project, or it's something that we're, as a team, collectively really embracing early on and wanting it to be a core focus of how we're building out the application. That said, I will say that I'm accessibility aware but far from an expert and still very much learning. But some of the things that I have used are the axe DevTools. I forget what the acronym actually stands for there, but we can certainly include a link in the show notes. But those are DevTools that allow you to, I think, do some color contrast checking actually in the browser just right there, which is really nice. There's also AccessLint, which is a project that scans pull requests and, where possible, does static analysis of the HTML. And that's actually by some former thoughtboters. So it's always nice to have that in the reference.

+ +

There's actually a new tool that I've been looking at. I haven't actually tried it out yet, but it's from a company called Assistiv Labs, Assistiv without an E interestingly at the end. But their tool is, as far as I can tell, it allows you to use screen readers and other tools but across various platforms so that you sort of turn on -- It's very similar to if you've ever used an emulated Internet Explorer session because you're working on not an Internet Explorer machine, but you want to make sure your site works in Internet Explorer, same sort of idea, I believe. But it allows you to do the same approach for accessibility. So using a screen reader or using what the native accessibility technologies are on various platforms and being able to test across a wide range of things. So that's definitely one that I'm going to be exploring more in the near future.

+ +

And beyond that, there are a handful of static analysis-based tools that I've used. So Svelte actually has some built-in stuff around accessibility. Because they are a compiler, they can do some really nice things there, and I really appreciate that that is a fundamental concern that they've built into the language, and the framework, and the compiler, and all of that. And I've also used ESLint A11y, which is the acronymnified version of the word accessibility. But that again, static analysis, so it can only go so far. And unfortunately, accessibility is one of those things that's hard to get at from a static analysis point of view, but it's still better than nothing. And it allows you to have a first line of defense at the code as you're authoring it. So that's a smattering of things. I've used some of them. I'm interested in others of them. But this is definitely an area that I'm going to be exploring a bunch more in the near future.

+ +

STEPH: I like that you brought in the static analysis tools because that's the other thing that's been on my mind as we're making these accessibility improvements; that's been great. And we can run this particular browser extension to then check for warnings or issues on the page but then looking out for regressions is on my mind. Or as we're introducing new pages and new forms, how do we make sure that those are up to standard if someone forgets to run that extension? So I really like the idea of -- There's AccessLint that you mentioned, which will then scan PRs for accessibility improvements. That sounds really great. I'm also intrigued if there's a way to also -- I don't know if maybe tests are a good way to also look for any sort of regressions in terms of changes that we've made to a page. I don't know what those tests would look like. So I'll have to think on that some more, but I think some people at thoughtbot have thought about it.

+ +

CHRIS: My understanding is the testing library suite of testing frameworks, so it's like testing library React, testing library, et cetera. It's primarily used in the JavaScript world, although there is Cypress, which is more of a browser-level automation. But it fundamentally works from not exactly an accessibility but a -- It doesn't allow you to do DOM selectors. It really tries to hide that. And it says, "No, no, no. You're not going to be digging in and finding the class name of this thing because guess what? A user of your application can't do that." What we want are – Typically, it's like find by label or find by things that are accessibility available or just generally available to users of your application. So whether it's users that are just clicking around or if they're using any sort of assistive technology, the testing library framework forces you in that direction. You can't write a test if your code is inaccessible tends to be the way it plays out, and it really nudges you in that direction. So it's one of the things that I really love about that. And I actually miss it when I'm working in a Capybara test suite because, as far as I know, there is not a Capybara testing library variant of it. And really, at the end of the day, it's just a bunch of functions to allow you to select within the context of the page. But again, it does it from that standpoint, and I'm all about that.

+ +

STEPH: Yeah, that's really nice. That's a good point. Yeah, I don't think Capybara has that explicitly. I know that you have to use specific parameters. Like, if you want to access something on the page that is hidden, that's not something you can just do easily. You have to specify: I'm looking for an element that is hidden on the page. But otherwise, I don't think it goes out of its way to prevent you from doing that. There is an article that this conversation about accessibility made me think of. There's a really fun blog post written by Eric Bailey, who has been or who is a champion of accessibility at thoughtbot and has written a lot of great content around making the web more accessible. And in addition to publishing with the thoughtbot blog post, he has written for a number of publications. And the article that comes to mind that he published on the thoughtbot blog posts is An Introduction to macOS Head Pointer, and we'll link to it in the show notes. But he does a great job walking through what the head pointer is on macOS and then how to use it. And he uses his eyebrows to essentially move the mouse and then click on certain buttons or click on certain links on the screen. And it's incredible. So if you need a little bit of accessibility and joy in your life, I highly recommend checking out that article.

+ +

CHRIS: Yeah. Eric has absolutely just been such a fantastic champion of accessibility. And he's definitely someone that I think of constantly as being -- I think he's involved with the Accessibility Project. He writes on CSS Tricks. He's around the internet just being the hero we need because accessibility is such a critical thing. And I'm a deep believer in the idea that accessible applications are better for everyone. And I so appreciate the efforts that he's putting in out there. Thanks, Eric.

+ +

STEPH: Thanks, Eric. And then, on a slightly separate note, I have a slight complaint that I'd like to file. And this one is with Rails specifically. And I'm filing this complaint with the understanding that I'm also very spoiled in terms of Rails does so much, and I'm very appreciative of how much Rails does for me and for us. But specifically, while working on accessibility for a date of birth form field, so it's a form field with three different selects, so you have your month, day, and year. And while creating this, there's a very helpful Rails method that's called date_select, where then you can generate all three of those select fields. And you can even specify the order in which you want them generated, but this particular function doesn't have a way to make it accessible. So you can generate a label for each option that's in the select dropdown. And there's no parameter. There's nothing you can pass through. It doesn't automatically generate it for you.

+ +

So I was in a spot where I was updating a form that's using the Rails date_select. I can't use date_select and make an accessible dropdown selection for date of birth. So instead, what I had to do is I had to split it out. I had to move away from using date_select, and instead, I'm using select_month and then select_day and select_year because from there, I then can pass in; in my case, I'm using aria-label to provide a label because I don't actually want the label to show up on a screen, which could be another accessibility concern because we do have the birth date label for those three sections. But then we still want at least each text field to have a label, even if it's only visible to screen readers. So then that way, if someone is selecting from year, they understand they're selecting from year or for month they're selecting from month. So by using select_year and select_day and select_month, I could specify the aria-label as month, day, or year, but I couldn't do that with the date_select. And I just realized that there's probably a number of date of birth forms out there that aren't accessible because us Rails developers are leveraging this existing method. So it just seems like a really good opportunity to improve date_select to be able to pass in a label or generate one automatically.

+ +

CHRIS: Wow. I'm surprised that's the state of the art that we're currently at. I really wonder if there have been conversations or if there are fundamental limitations because I'd be surprised if such a core piece of the Rails world someone hadn't brought this up in the issues. What's the story there? Because I'm guessing there's a story there. Although flipping it around, I wonder -- I've never loved that input sequence; as an aside, like three different selects, that's not how I think of my birthday. My birthday is one thing. It's not three things that we smash together. But I wonder are we at a point now where IE 11 usage is so small that we can use a native date_select input and then have a polyfill -- And then I start to trail off because I don't know what the story is for. Like, I think Safari doesn't do a great job, and I forget where it's at right now. And what about mobile Safari? And wouldn't it be nice if everything was just easy and everybody kept up? [laughter] But that's an aside. But yeah, that's part of my question here, is like, can we just not use that thing at all? Like, the three select dropdown version of picking a date of birth because, man, that's my least favorite way to do it.

+ +

STEPH: Yeah. I'm with you. I'm also curious if there is a story behind this and also if anyone has a different opinion, and I'd love to hear it. Because this has been my experience in digging through the docs is I would date_select, and I could not find a way to pass in a label or have one generated to make it accessible. So then that prompted me to use the three different methods, which, by the way, is fine. It made me stop and pause to think this is the method that most people recommend the usage of in terms of creating those three different select fields for a date of birth or for any particular date that you're supplying; it does not have to be a date of birth. So it also surprised me that then we couldn't make it accessible. So yeah, I was a bit miffed in the moment. [laughter] I had to walk myself back and be like, well, if I want to make the world a better place, I should help make the world a better place. And that started with changing the code in this codebase. But then also it means looking into Rails to see if there's an improvement that I could help with there.

+ +

CHRIS: This is what we do: we take our moments of miffed, and we turn them into positive action in the world. This is what we want to see. [chuckles]

+ +

STEPH: I figure the least I can do is share a blog post or something on Twitter that shows what it was before and then using the new date_select functions because that is reasonable, although working with a form is a bit different. It got a little tricky there in terms of making sure that each value for each select field is still being passed within the expected nested parameter. And some of that was available in the public API for select_year and select_day, but it's not as well documented. So I'm like, well, this seems to be intentionally public, but it's not documented, so I feel a little nervous about using this. Yeah, that's it. I just wanted to share my annoyance with Rails [laughs] or the fact that it made me work so hard to have a date of birth field.

+ +

CHRIS: You joke, but that's a lot of why we use Rails is because we want these common regular things that we're doing to be as easy as possible, to require as little code on our part as possible but also this sort of thing like there's a lot of subtlety and stuff. Accessibility is one of those things that I want a framework that has security, and accessibility, and ease of use, and all of these things just baked in, so I don't have to think about it every time. It turns out having a date of birth, or generically any date field, is going to come up in web applications a lot, it turns out. And so having all of that stuff covered is frankly what I expect of a framework like Rails. So I'm totally on board with your being miffed here.

+ +

STEPH: Yeah. Those are all really valid points. So I'm with you. What else has been up in your week?

+ +

CHRIS: Well, we've been leading up to this, I think, for many weeks. I did a Rails 6.0 upgrade a while back, and a big reason for that was partly just to get on the current version of Rails but also because I wanted to open the door to database switching, and finally, this week, I tackled it. And let's tell a tale because there was a bit of an adventure, if we're being honest. Fundamentally, all the stuff there makes sense. I'm happy with the end configuration, but there was a surprising amount of back and forth. I broke the app more times than I want to actually announce on a podcast, but I broke it only for a brief period of time. It's fine. It's fine. Everybody's fine. [laughs] I feel a little bad about it, but these things happen. But yeah, it was interesting, is how I'll describe it.

+ +

So fundamentally, Rails just has nice configuration for it. So at a high level, you're introducing your config/database.yml. Instead of it just being production is this URL, you now say primary is this replica or follower, whatever you want to name it is this. So you have now two configurations nested within your production config. And then in your ApplicationRecord, you inform Rails that it connects_to, and then you define a Hash for writing goes to the primary, reading goes to the follower. And you have to sync those up with the thing you just wrote in the config/database.yml but fundamentally, that kind of works. That makes it possible in your application to now switch your database connection. The real magic comes in the config environment production file. And in that, you specify that you want Rails to use a database resolver that says GET requests go to the replica, and anything that is not a GET request goes to the primary. So anytime you're writing data, anytime you're changing data within the system, that's going to go to the primary.

+ +

And there's also a configuration that, as far as I can tell, gives a session affinity. So for the next two seconds after that, even if you make a GET request subsequently right following it, so you make a right, you POST, and then immediately after that, you do a GET. Like, you create an object, and then you get redirected to the show page for that object, Rails will continue to go to the primary. I think it's probably using a cookie or something to that effect, but you can configure that time span. So you can say like, "Actually, we see that our follower lags behind a little bit more, so let's give it a five-second timeout where all requests for that user will then go to the primary." But otherwise, once that timeout clears, then you're going to switch back, and you're going to go to the follower, and all GET requests will happen to the follower. And that's the story. You have to configure that, and then it works.

+ +

STEPH: I always love when you start these out with "I have a tale to tell." I very much enjoy these adventures. And you also answered my question in regards to if you immediately just created something, but then you do a fetch that's very close to after you just created it and how that gets rendered. So that was perfect.

+ +

CHRIS: Frankly, the core configuration is very straightforward, and it's very much in line with what we were just talking about of; this is what I want from Rails: make this thing very easy, hide the details behind the scenes. But as I said, there's a bit of a tale here. So that was the base configuration. It sort of worked but then immediately upon deploying it to production -- So we deployed it to staging first just to test it out. Staging was fine, as is often the case. Increasingly, I'm leaning into Charity Majors' idea of you got to test in production. You're testing in production even if you say you aren't. So once it got to production, we started seeing a bunch of errors raised or a handful of errors. And they were related to a handful of controller actions, which are GET requests, so they're either show or index, but in them, they were creating, or they were trying to create data. And so we were getting an error that was read-only connection error or something to that effect, ActiveRecord read-only, I think, was the error class. And that makes sense because I told it, "Hey, whenever you get a GET request, you're going to use that follower." But the follower is a read-only database connection because it's a follower, and so it was erroring.

+ +

It was interesting because when this happened, I was like, wait, what? And then I looked into it. And it's frankly fine at all the levels. It is okay to create a record in a GET request as long as that creation is idempotent. You create if it doesn't exist, and then from there on, you use that same one. That still fits within the HTTP rules of idempotents, and everybody's fine with that, except for the database connection. Thankfully, this is relatively easy to work around. You just need to explicitly within that controller action say, "Use the right database, use the primary." And the way I implemented that, I wrote a method within ApplicationRecord that was with right DB connection, and then it takes a block, and you yield to that block. It's basically just proxying to another similar thing. And it's very similar to wrapping something in a transaction; it sort of feels like that. It's saying just for this point in time, switch over and use the primary because I know that I'm going to be having some side effect here.

+ +

STEPH: Wow. That's so fun. I'm sure it was not fun for you. But as me hearing the story later, that's fun in regards to I hadn't thought about that idea of you're telling all the GETs you can only go to the read, and now you're also trying to create. I am feeling nervous in terms of local development. So if you're working on a new controller and if you have a fetch or GET action, but you're also creating something, you haven't seen another controller that is demonstrating that strategy that needs to be used. Is it just going to work locally? I imagine it does because it was working for the other code that you were running that didn't yet have that strategy in place. So I'm feeling nervous in terms of someone could easily miss that.

+ +

CHRIS: I think there are a couple of different questions in what you just said. So let me try and answer all of the ones that I think I heard. So for local development, your database/config.yml is still going to be the same as it was. So you're just connecting to database name_development. There's only one of them; there's no primary follower. So this is a case where you have a discrepancy between production and development, which is always interesting. And maybe that's something to poke at because ideally, I want as little gap there as possible. But this is one of those cases where I'm like, eh, I don't think I'm going to run two databases locally and have one be a follower. That feels like too much to manage. Under the hood with that right DB connection method that I talked about where you want to explicitly opt-in, in the case that we're in development, I just yield directly to the block. So instead of doing the actual database switching at that point, the method is basically saying, "If we're in production, then switch to the primary and yield and if we're not in production, then just yield." And so it'll just run that code, and it'll connect to the only database. More generally, I have the connects_to configuration; I wrapped that. So that's in ApplicationRecord where you're saying, "Hey, connect to these databases based on this logic," that is wrapped if we're in production check as well. And the same thing in the top-level configuration that says -- We're getting ahead of ourselves in the story because this is the end state that I got to. It's not where I started, and I screwed some stuff up in here, but basically, all of the different configuration points, my end result was to wrap them in a check that we are in production.

+ +

STEPH: Okay. Sorry if I rushed your story. I was already thinking ahead to how could we accidentally goof this up? That makes a lot of sense for the method that's with right DB connection, that method that then it's going to check if we're in production, then we can use a primary follower strategy; otherwise, just use the database that we know of. So that helps a lot in answering those questions. And then we can pause and then get to my question later. But my other question that I'm curious about is what helps us prevent the team from making this mistake in terms of where we're adding a new controller, we add a new GET action, and we are also creating data, but then someone doesn't know to add that strategy that says, "Hey, you are allowed to go to the primary to also get data but also to write data too." And I'll let you take it away.

+ +

CHRIS: I don't know that I have a great answer to that one if we're being honest. As I saw this, it was very easy to find -- I think there were three controller actions that had this behavior in the system that I was working on. They all threw errors. It was very easy to just wrap them in this extra method and fix that, and then we're good, and I haven't seen that error again. As for preventing it from new instances of this behavior, I don't have a good answer other than potentially you share this information within the team and then PR review. Ideally, someone's like, "Oh, this is one of those things you've got to wrap it in the fancy database switching logic." Potentially, and I don't actually think this would be possible, but there's a chance that RuboCop or other static analysis type thing could look inside any index or show action and say, "I see a create or an update or any of the methods." But again, Rails is so hard to do static analysis on that I would be surprised if were actually feasible to do that in a trustworthy way, probably worth a poke because this is the sort of thing that can easily sneak out. But potentially, my answer is, well, it'll blow up pretty loudly the first time you do it. And then you'll just fix it after that, which is not a great answer. I'm open to that being a mediocre answer at best.

+ +

STEPH: [chuckles] Yeah. That's a fair answer. Just because I pose a question, I don't know if there necessarily is a great answer to it right away. And disseminating that information to the team to then having the team be able to point that out also sounds very reasonable but then still hashes that danger of someone overlooking it. The static analysis is an interesting idea, sort of like strong migrations. As you're introducing a new migration, strong migrations will do a wonderful job of showing you concerns that it has with the migration that you've added. And this is all just theoretical dreams and hopes because, yeah, that would help prevent some of those scenarios.

+ +

CHRIS: It's interesting now that this is the second time we've discussed static analysis in this very episode. Clearly, it's a thing that I want more of in my world, and yet I work in languages like Ruby that are notoriously difficult to perform static analysis on.

+ +

STEPH: I had a moment today writing a method that was currently just returning a string each time but then I was about to update that method. I was looking for a way like, well, maybe I don't always want a string. Maybe I actually want a Boolean here. But in the other case, I want a string. And the person I was pairing with they're like, "You could return -- [inaudible 29:31] Boolean in one case and then a string in the other case. Like, this is Ruby." [laughs] I was like, true, but I feel bad about it, and I don't love it. And we just had a phone conversation around that. If you're in the Ruby world following the more functional programming or type strictness and where you're returning specific types or trying to return a consistent type, it's ideal. But then also in Ruby, it's like it's Ruby, so sometimes you can finagle the rules a little bit.

+ +

CHRIS: YOLO, as they say.

+ +

STEPH: [laughs]

+ +

CHRIS: Yeah, I'm definitely interested to see where projects like Sorbet and...I forgot what the core Ruby typed thing in Ruby 3.0 is called, but either of those. I'm really intrigued to see where they go and how the Ruby community either adopts or doesn't. I wouldn't be surprised if that were part of the outcome there. I've been impressed with the adoption of TypeScript and JavaScript, which is also a very, very free language, not quite to the degree that Ruby is. But yeah, it remains to be seen what will happen on those fronts.

+ +

But continuing back to our saga, so we've now had the read-only error, we've fixed those, just wrapped them in blocks, and said, "Explicitly connect to the primary." So the next thing that I did after that, I realized that my configuration was a little bit flimsy is probably the best word to describe it. I was explicitly creating a new environment variable with the URL, the Postgres URL of the follower. And so I was using that environment variable to define where the URL like the Postgres URL of the follower database -- But I realized if Heroku comes in and does any maintenance on that Postgres instance, it's possible that the AWS IP address or other details of it will actually change and so that Postgres URL will no longer be valid. So that's one of the things that I rely on Heroku for, is to maintain my databases for me. But they will update, say, the DATABASE_URL environment variable if they change out your database. But now, I had broken that consistency. And so I'd set us up for somewhere down the road this will break, and I realized that because Heroku reached out and said, "Hey, your follower database needs maintenance." And I was like, oh, no. So, I tried to get it from -- It turned out, in this case, it didn't actually change. They were able to swap it out in place, but I wanted to add a little bit of robustness around that.

+ +

And so I actually reached out, and Dan Croak, former CMO of thoughtbot, actually had written a wonderful blog post about how to configure this and particularly how to configure it in the context of Heroku. And he described how to use the Heroku naming scheme for the environment variables. They happen to have colors in them. So it's like Heroku Postgres cyan URL or orange URL or purple URL. And so he defined a scheme where you set an environment variable that describes the color, and then it can infer the database URL environment variable from that. And then went the one step further to say, "If that color environment variable is set, then treat as if we are configured for database switching. But if it is not set, even if we're in production, pretend like we don't have database switching," which that was another nice feature that I hadn't built in the first place. When I first configured this, I just said, "Production gets database switching. And if we're in production, then database switching is true," but that's actually not something that I want. I want to be able to say, "Upgrade our follower," at some point or do other things like that. And so I don't want to be locked into database switching on production. So that was a handful of nice configurations that I wanted to get to.

+ +

Unfortunately, when I tried to deploy that switch, man, did it break. It broke, and then I was like, oh, I see I did something wrong there. So then I tested again on staging. Staging was fine. And then I went to production, and it broke again. And this happened like three times in one day. I felt like a terrible programmer. I had no idea what I was doing. Turns out that staging and production had different environment config files, and so their configurations were fundamentally different. They also had a different configuration for the database level. So one of the things I did as part of this was to clean those up and unify them so that staging was production with some environment variables to config it, but identically production, which is definitely a thing that I believe in, and I want basically all the time. I don't think we should have a distinct staging environment config that is wildly different. It should only vary in very small ways, basically just variables that say, "This is where the database is for staging," but otherwise be exactly configured as production. So I eventually got on the other side of that, fixed everything, have a nicely Heroku-fied color-based environment variable scheme, which is a bit of a Rube Goldberg machine, but it works. And I was able to hide that config in one place. And then everything else just says, "If there is a database follower URL defined, then use it." But yeah, so that was the last hard, weird bit of it.

+ +

And then the only other thing that I did was I realized that this configuration was telling the Rails server how to behave, but there are also background jobs. And this application actually happens to have a ton of background job traffic. And so I did a quick check of those, and there were a handful of background jobs that were read-only. A lot of them were actually sending data to external systems, so to analytics or other email marketing or things like that. And so constantly, as users are doing anything in the application, there are jobs that are queued that aggregate some information, maybe calculate some statistics, and then push it to another system. But those are purely read-only when those jobs execute. And so I was able to add another configuration which said, "Use the read-only connection and configure that to wrap those particular sidekick jobs." And with that, I think I have a working database switching configuration that will hopefully give us a lot of headroom in the future. That's the idea, that's the dream, but we will see.

+ +

STEPH: That is quite the saga between having GET requests that create data and then also the environment inconsistencies, which is a nice win that then you're able to improve that to make those environments more consistent. And then the background jobs, yeah, that's something that I had not considered until you just brought it up, and then being able to opt-out of the database switching sounds really nice. In regards to moving in this direction, you're saying gave you a lot of headroom for this; when it comes to monitoring performance, is there anything in place to let you know how it's doing?

+ +

CHRIS: I love that I knew that this was going to be your question. I love that this is your question because it's a very good question. And unfortunately, in this case, it's actually somewhat unsatisfying. So as is my typical answer for this, we're using Scout as the application performance monitoring tool on this. And I was able to go in and monitor what it looked like a week ago, what it looked like after I made the change, and it was a little better. And that's all I can say about it. But that's fine. The idea with this, and at least in the way I was thinking about it, is this should get better at the margins. On the days where we have a high spike in traffic, those are the days where the database is actually working hard. They shouldn't make the normal throughput of the application that much higher in the regular case; it's for those outlier instances. To that end, though, I did analyze it. And so the average response time got 2% to 3% better in that week-by-week comparison, which was fine. The 95th percentile response time, so starting to get out to those margins, starting to get to the long tale of where stuff gets -- a couple of requests came in at the same time, and the application had to try a little harder, those got 8% to 9% better. That shape of improvement where for most requests, nothing really changed for some of the requests that used to be a little bit slower; those got a little bit better. That's the shape of what I would hope to see here. And it remains to be seen. This application has particular traffic patterns where they'll encourage a lot of users to be using the app at the same time. And historically, those have been somewhat problematic, and we've had to really work to shore up the performance in those cases. That's where I'm really interested to see how this goes. It would be hard to replicate those traffic patterns at this point. So I don't have a good way to really stress test this, but my hope is that for those cases, things will just hum along and be happy.

+ +

STEPH: That makes a lot of sense and something that would be hard to measure, but the fact that you already see a little bit of improvements that's encouraging.

+ +

CHRIS: But yeah, certainly, if I get a chance to see what that looks like in the near term, I will respond back and let you know how this has played out. But overall, now the configuration seems pretty stable. I think we're in a good spot. Hopefully, we won't have to do too much proactive management around this. And ideally, it just buys us a little bit of headroom. So that is certainly nice. But with that, with your wonderful question getting to the heart of the issue, I think that wraps up the saga of the database switching.

+ +

STEPH: Well, I appreciate you sharing that saga. That's really helpful. I've been very excited to hear about how this goes because I haven't gotten to work on a project that's going to use database switching just yet. And now I know all the inside baseball. I'm trying to use sports metaphors here as to how to do this for when I get to work with database switching.

+ +

CHRIS: Sports de force.

+ +

CHRIS: Along the lines of new stuff, there is something I'm excited about. So in juxtaposition to my earlier statement or my earlier grievance where friends don't let friends use date_select in regards to trying to keep the web accessible, I do have some praise for something that's being added in Rails 6.1 that I'm excited about. And it's a really nice method. It's a query method that can be used to find orphan records. So if I'm writing a query that is then looking for some of these missing records, so if I have my table -- I didn't come with a great example today, so let's just say we have like table A and then we're going to left_joins on table B. And then we're going to look for where the ID for table B is nil, so then that way we find where we don't have that association that it's missing. And so left_joins does this for us nicely. And then I always have to think about it a little bit where I'm like, okay, I want everything from table A, and I don't want to exclude anything in table B if there's not a match on the two. And so then I can find missing records that way or orphaned records that way. The method that's being introduced or has been introduced in Rails 6.1, so anyone that's on that new-new, there is the missing method. So you could do tableA.where.missing and then provide the table name. So there's a really nice blog post that highlights exactly how this method works, so I'll use the example that they have. So for where job listings are missing a manager, so you could do JobListing.where.missing(: manager), and then it's going to perform that left_join for you. And it's going to look for where the ID is nil. And I love it. It's really nice.

+ +

CHRIS: That sounds excellent. That's definitely one of those things that I would have to sit down and squint my eyes and think very hard, really anything involving left_joins otherwise center. Any joins always make me have to think and so having Rails embrace that a little bit more nicely sounds delightful.

+ +

STEPH: Yeah, it sounds like a nicety that's been added on top of Rails so that way we don't have to think quite as hard for any time; we want to find these orphaned records, and we know that we can use this new missing method.

+ +

CHRIS: On the one hand, I feel bad saying, "I don't want to think that hard." On the other hand, that's literally our job is to make it so that we encode the thinking into the code, and then the machines do it for us. So it's kind of the game, but I still feel kind of bad. [laughs]

+ +

STEPH: Well, it's more thinking about the new stuff, right? Like, if it's something that I've done repetitively, finding orphan records is something I've done several times, but I do it so infrequently that then each time I come back to it, I'm like, oh, I know how to do this, but I have to dig up the knowledge. How to do it is that part that I want to optimize. So I feel less bad in terms of saying, "I don't want to think about it," because I've thought about it before. I just don't want to think about it again.

+ +

CHRIS: I like it. That's a good framing. I've thought about this before. Don't make me think about it again. [chuckles]

+ +

STEPH: Exactly. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: The show is produced and edited by Mandy Moore.

+ +

STEPH: Thanks, Mandy. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show.

+ +

CHRIS: If you have feedback for this or any of our other episodes, you can reach us at @bikeshed. And you can reach me @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph share a speedy step to restart your rails server and chat about accessibility improvements and favorite a11y tools. They also dive into a tale of database switching and delight in a new Rails query method that returns orphaned records.

+ + + +

Transcript:

+ +

STEPH: People put microphones in front of us. That is their fault, not ours. We just show up. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. Hey Chris, happy Friday.

+ +

CHRIS: Happy Friday.

+ +

STEPH: How's your week been?

+ +

CHRIS: It's been great. I did something that is wildly overdue, but I got a new chair and one day in. But it's also a very familiar chair because it's basically the same -- I think it's the same model as we had at the thoughtbot office. And it's nice to have a chair that is reasonable. And I think my old chair was maybe ten years old or something, deeply embarrassing and absurd like that for such a critical piece of infrastructure in my house.

+ +

STEPH: I mean, I guess depending on if it's a good chair. I don't know what the lifespan is of a good chair. [laughs]

+ +

CHRIS: I would not describe it as such.

+ +

STEPH: [laughs]

+ +

CHRIS: I think it was like $100 at Staples. It was a fine chair. It served me well for many years. I'm very slow and cautious with what I consider to be large-scale purchases. I hate the idea of having a thing that I've spent a bunch of money on, but I don't actually like. And these are very solvable problems. But I just tend to drag my feet and over-research and do all those sorts of things. And so finally I was just like, nope, we're going to get a chair, got a chair. Cool. Now I have a chair, and it's good. It's got all of the adjustments, which is what makes it very nice. I'd say Steelcase Leap is the model for anyone that's interested.

+ +

STEPH: That's funny. I tend to do the same thing. I tend to drag my feet until I get desperate enough that then I'm forced to make a decision and buy something. I do have an oddly specific question. Do you like chairs with or without the arms?

+ +

CHRIS: Oh, with the arms.

+ +

STEPH: Really?

+ +

CHRIS: Yeah.

+ +

STEPH: I am team, no arms.

+ +

CHRIS: Where do your arms go if there are no arms to put on the chair?

+ +

STEPH: They're always on my lap or on my keyboard. So I just don't rest them on the armrest.

+ +

CHRIS: Interesting. I feel like that would put -- I've definitely had small bouts of RSI strain fatigue in my forearms. And so I'm very purposeful with how I'm bracing my wrists. I have a little wrist rest that I put my hands on when I'm using my keyboard because the keyboard is slightly raised up because I have a nonsense mechanical keyboard, of course.

+ +

STEPH: Delightful, not nonsense.

+ +

CHRIS: Yeah, I love it. I would never trade that in, but I have to make it work and not actually sacrifice my body for a clackety keyboard. [chuckles] But yeah, I think I need some more support for my arms; otherwise, there's too much pressure on my wrists, and things are breaking at weird angles, and that's been my experience. I'm intrigued by the free-flying no arms on the chair approach that you're talking about. This particular model has nine degrees of freedom on the armrest. So I'm able to bring them in and forward and at the exact right height so that they perfectly meet my arm where it would naturally be, and that seems good. That seems like the thing that I want.

+ +

STEPH: That makes a lot of sense. But yeah, I'm team no arms. Every time I have them, I can't get them at the right comfortable spot. And I like the freedom of where I can quickly get up and out of my chair and not have arms in the way, which sounds like a very small improvement in my life, but yet it's what I want.

+ +

CHRIS: I just like the idea of you sitting there and being like, I need to be able to make a quick escape at any moment; who knows what's going to happen? And I need to be able to run the other way.

+ +

STEPH: If there's a gnarly bug, I got to be able to run. I can run away quickly as possible. [laughs]

+ +

CHRIS: But in other news, so yeah, new chair that's great. I also recently embraced something in the Rails world that I have known about I think for forever for the entire time that I've worked in Rails, but I've never really used it, which is the tmp/restart.txt file, which my understanding of it is if you touch that file, or if that file exists, Rails will recognize that and will restart the server in development mode. And I think I've always known about this, but I've never used it. And I recognized recently that either I was trying to use a gem that I'd added to the Gemfile, but my server didn't know about it. So I was going to do the thing that I normally do, which is kill the server and then restart the server so CTRL+C and then CTRL+P in my terminal and hit enter, and then wait a bunch of minutes and get distracted, all of the bad things there. And I was like, wait; I remember that there's a thing here. And I don't know why I haven't been doing this for years. It's so much better. I actually went the one step further, and I configured a tmux binding so that tmux prefix and then R will touch tmp/restart in the local directory of the tmux session. That's been very nice, I will say. So I keep moving between branches. And I have environment variables that I need to reload or config initializers that I've made a change to, and I want to load that in. Or a gem that I've added to the Gemfile and I've now installed, but the server doesn't know about. All of these are just so quick now. And why wasn't I doing this the whole time?

+ +

STEPH: I saw that you mentioned this on Twitter a couple of days ago, and I was so excited. But at the moment, I bookmarked it for later, but I didn't have time to actually really check it out. And I'm so glad you're bringing it up because I actually just tried it while we're chatting. So I started up my Rails server, and then I did the touch tmp/restart, and this is amazing. This is awesome. I'm very excited.

+ +

CHRIS: It just does the thing.

+ +

STEPH: It just does the thing.

+ +

CHRIS: Yeah, it's so nice. [laughter]

+ +

STEPH: Yeah, this is fabulous, almost as good as the pending migrations button. Not quite because that's a very special button, but this is also up there.

+ +

CHRIS: It's a very, very good button. [laughs] I really got very enthusiastic about that button, didn't I? But I stand by it. It's a very good button, and this is a very good file. But this file has existed for so much longer, this workflow. And so many times, I have restarted the server and have been annoyed that I had to do it. And my brain just had this answer available. I didn't read a blog post and relearn this thing. I've always known it. And it was this one particular time that my brain was like, "Hey, you know how we're always annoyed by having to restart the server? You know there's another answer, right? I know that you know it because I'm your brain, and I'm telling you this." [chuckles] This is my weird internal monologue. So I'm very happy to be on the other side of that and to share that with as many people as possible who may be, like me, know about this but haven't actually leaned into it, small things that make the Rails world very nice.

+ +

STEPH: Well, I'm glad you internalized it and then surfaced it because this is not something that I had heard of before. So I'm very appreciative of it. This is going to be great.

+ +

CHRIS: Happy to share the wealth. But yeah, that's some of the stuff that's been up in my world. What's been going on in your world?

+ +

STEPH: It's been a rather busy week. Most of that week has been focused on improving the accessibility of existing pages and forms, which is an area that I don't get to spend a lot of time, but each time I do, I really would like to be a pro when it comes to accessibility. Well, that's probably a long journey to become a pro. I would like to become more knowledgeable in terms of accessibility because it is so important. And while working specifically on these accessibility tickets and improvements, I've discovered a few helpful tools that I figured I'd share here. So one of the tools that I've started using is a color contrast tool. It's created by WebAIM or web accessibility in mind. And a number of our headers in our application have a white font that's on a background color, and we were getting warnings that this isn't very accessible and that there's not enough contrast. So with the Contrast Checker, you can provide the foreground color and the background color, and then it's going to tell you that contrast ratio. So if you're wondering, well, what's a good ratio? That's a great question. And the W3C Accessibility Guidelines recommend a contrast ratio of 4:5:1 for normal texts and 3:1 for larger texts. Larger text is anything that's typically around 18 px, 18.5 px, or larger. So the color contrast tool has been really helpful because then that's been very easy that we give the blue that we're using, and then we can just darken it a bit to improve that contrast. And then we apply that everywhere throughout the app. The other tool that I've been using that I'm really excited about it's a browser extension called the IBM Equal Access Accessibility Checker. Is that something you've heard of or used before?

+ +

CHRIS: I have not heard of that.

+ +

STEPH: I would love to know what you currently use for accessibility, and I'll circle back to that in just a moment. But for this particular browser extension, I'm pretty sure they have it for multiple browsers. I'm using Chrome. So I've installed the Chrome extension. Once you have it installed, you can open up the browser console and then tell it to scan the page that you're on. And then it generates a really helpful report that has all the high-level offenses, which are called violations. It also has warnings and recommendations. And then if you click on a specific issue, then the right-hand area shows a detailed description of the offending HTML, what's wrong, why it's important, which I really appreciate that part, and then a couple of examples of how to fix it. So it's been a really nice way as we are working to improve the accessibility of form. We actually have feedback to know that we are making progress and that we are improving the accessibility of that particular page. And then circling back, I'm curious, do you have any particular tools that you use when it comes to improving accessibility or any standards that you tend to follow?

+ +

CHRIS: Yeah, this is a very apropos question. I'm working on a new project now, and accessibility is definitely something that I want to consider on every project, but it's all the more so important for this particular project, or it's something that we're, as a team, collectively really embracing early on and wanting it to be a core focus of how we're building out the application. That said, I will say that I'm accessibility aware but far from an expert and still very much learning. But some of the things that I have used are the axe DevTools. I forget what the acronym actually stands for there, but we can certainly include a link in the show notes. But those are DevTools that allow you to, I think, do some color contrast checking actually in the browser just right there, which is really nice. There's also AccessLint, which is a project that scans pull requests and, where possible, does static analysis of the HTML. And that's actually by some former thoughtboters. So it's always nice to have that in the reference.

+ +

There's actually a new tool that I've been looking at. I haven't actually tried it out yet, but it's from a company called Assistiv Labs, Assistiv without an E interestingly at the end. But their tool is, as far as I can tell, it allows you to use screen readers and other tools but across various platforms so that you sort of turn on -- It's very similar to if you've ever used an emulated Internet Explorer session because you're working on not an Internet Explorer machine, but you want to make sure your site works in Internet Explorer, same sort of idea, I believe. But it allows you to do the same approach for accessibility. So using a screen reader or using what the native accessibility technologies are on various platforms and being able to test across a wide range of things. So that's definitely one that I'm going to be exploring more in the near future.

+ +

And beyond that, there are a handful of static analysis-based tools that I've used. So Svelte actually has some built-in stuff around accessibility. Because they are a compiler, they can do some really nice things there, and I really appreciate that that is a fundamental concern that they've built into the language, and the framework, and the compiler, and all of that. And I've also used ESLint A11y, which is the acronymnified version of the word accessibility. But that again, static analysis, so it can only go so far. And unfortunately, accessibility is one of those things that's hard to get at from a static analysis point of view, but it's still better than nothing. And it allows you to have a first line of defense at the code as you're authoring it. So that's a smattering of things. I've used some of them. I'm interested in others of them. But this is definitely an area that I'm going to be exploring a bunch more in the near future.

+ +

STEPH: I like that you brought in the static analysis tools because that's the other thing that's been on my mind as we're making these accessibility improvements; that's been great. And we can run this particular browser extension to then check for warnings or issues on the page but then looking out for regressions is on my mind. Or as we're introducing new pages and new forms, how do we make sure that those are up to standard if someone forgets to run that extension? So I really like the idea of -- There's AccessLint that you mentioned, which will then scan PRs for accessibility improvements. That sounds really great. I'm also intrigued if there's a way to also -- I don't know if maybe tests are a good way to also look for any sort of regressions in terms of changes that we've made to a page. I don't know what those tests would look like. So I'll have to think on that some more, but I think some people at thoughtbot have thought about it.

+ +

CHRIS: My understanding is the testing library suite of testing frameworks, so it's like testing library React, testing library, et cetera. It's primarily used in the JavaScript world, although there is Cypress, which is more of a browser-level automation. But it fundamentally works from not exactly an accessibility but a -- It doesn't allow you to do DOM selectors. It really tries to hide that. And it says, "No, no, no. You're not going to be digging in and finding the class name of this thing because guess what? A user of your application can't do that." What we want are – Typically, it's like find by label or find by things that are accessibility available or just generally available to users of your application. So whether it's users that are just clicking around or if they're using any sort of assistive technology, the testing library framework forces you in that direction. You can't write a test if your code is inaccessible tends to be the way it plays out, and it really nudges you in that direction. So it's one of the things that I really love about that. And I actually miss it when I'm working in a Capybara test suite because, as far as I know, there is not a Capybara testing library variant of it. And really, at the end of the day, it's just a bunch of functions to allow you to select within the context of the page. But again, it does it from that standpoint, and I'm all about that.

+ +

STEPH: Yeah, that's really nice. That's a good point. Yeah, I don't think Capybara has that explicitly. I know that you have to use specific parameters. Like, if you want to access something on the page that is hidden, that's not something you can just do easily. You have to specify: I'm looking for an element that is hidden on the page. But otherwise, I don't think it goes out of its way to prevent you from doing that. There is an article that this conversation about accessibility made me think of. There's a really fun blog post written by Eric Bailey, who has been or who is a champion of accessibility at thoughtbot and has written a lot of great content around making the web more accessible. And in addition to publishing with the thoughtbot blog post, he has written for a number of publications. And the article that comes to mind that he published on the thoughtbot blog posts is An Introduction to macOS Head Pointer, and we'll link to it in the show notes. But he does a great job walking through what the head pointer is on macOS and then how to use it. And he uses his eyebrows to essentially move the mouse and then click on certain buttons or click on certain links on the screen. And it's incredible. So if you need a little bit of accessibility and joy in your life, I highly recommend checking out that article.

+ +

CHRIS: Yeah. Eric has absolutely just been such a fantastic champion of accessibility. And he's definitely someone that I think of constantly as being -- I think he's involved with the Accessibility Project. He writes on CSS Tricks. He's around the internet just being the hero we need because accessibility is such a critical thing. And I'm a deep believer in the idea that accessible applications are better for everyone. And I so appreciate the efforts that he's putting in out there. Thanks, Eric.

+ +

STEPH: Thanks, Eric. And then, on a slightly separate note, I have a slight complaint that I'd like to file. And this one is with Rails specifically. And I'm filing this complaint with the understanding that I'm also very spoiled in terms of Rails does so much, and I'm very appreciative of how much Rails does for me and for us. But specifically, while working on accessibility for a date of birth form field, so it's a form field with three different selects, so you have your month, day, and year. And while creating this, there's a very helpful Rails method that's called date_select, where then you can generate all three of those select fields. And you can even specify the order in which you want them generated, but this particular function doesn't have a way to make it accessible. So you can generate a label for each option that's in the select dropdown. And there's no parameter. There's nothing you can pass through. It doesn't automatically generate it for you.

+ +

So I was in a spot where I was updating a form that's using the Rails date_select. I can't use date_select and make an accessible dropdown selection for date of birth. So instead, what I had to do is I had to split it out. I had to move away from using date_select, and instead, I'm using select_month and then select_day and select_year because from there, I then can pass in; in my case, I'm using aria-label to provide a label because I don't actually want the label to show up on a screen, which could be another accessibility concern because we do have the birth date label for those three sections. But then we still want at least each text field to have a label, even if it's only visible to screen readers. So then that way, if someone is selecting from year, they understand they're selecting from year or for month they're selecting from month. So by using select_year and select_day and select_month, I could specify the aria-label as month, day, or year, but I couldn't do that with the date_select. And I just realized that there's probably a number of date of birth forms out there that aren't accessible because us Rails developers are leveraging this existing method. So it just seems like a really good opportunity to improve date_select to be able to pass in a label or generate one automatically.

+ +

CHRIS: Wow. I'm surprised that's the state of the art that we're currently at. I really wonder if there have been conversations or if there are fundamental limitations because I'd be surprised if such a core piece of the Rails world someone hadn't brought this up in the issues. What's the story there? Because I'm guessing there's a story there. Although flipping it around, I wonder -- I've never loved that input sequence; as an aside, like three different selects, that's not how I think of my birthday. My birthday is one thing. It's not three things that we smash together. But I wonder are we at a point now where IE 11 usage is so small that we can use a native date_select input and then have a polyfill -- And then I start to trail off because I don't know what the story is for. Like, I think Safari doesn't do a great job, and I forget where it's at right now. And what about mobile Safari? And wouldn't it be nice if everything was just easy and everybody kept up? [laughter] But that's an aside. But yeah, that's part of my question here, is like, can we just not use that thing at all? Like, the three select dropdown version of picking a date of birth because, man, that's my least favorite way to do it.

+ +

STEPH: Yeah. I'm with you. I'm also curious if there is a story behind this and also if anyone has a different opinion, and I'd love to hear it. Because this has been my experience in digging through the docs is I would date_select, and I could not find a way to pass in a label or have one generated to make it accessible. So then that prompted me to use the three different methods, which, by the way, is fine. It made me stop and pause to think this is the method that most people recommend the usage of in terms of creating those three different select fields for a date of birth or for any particular date that you're supplying; it does not have to be a date of birth. So it also surprised me that then we couldn't make it accessible. So yeah, I was a bit miffed in the moment. [laughter] I had to walk myself back and be like, well, if I want to make the world a better place, I should help make the world a better place. And that started with changing the code in this codebase. But then also it means looking into Rails to see if there's an improvement that I could help with there.

+ +

CHRIS: This is what we do: we take our moments of miffed, and we turn them into positive action in the world. This is what we want to see. [chuckles]

+ +

STEPH: I figure the least I can do is share a blog post or something on Twitter that shows what it was before and then using the new date_select functions because that is reasonable, although working with a form is a bit different. It got a little tricky there in terms of making sure that each value for each select field is still being passed within the expected nested parameter. And some of that was available in the public API for select_year and select_day, but it's not as well documented. So I'm like, well, this seems to be intentionally public, but it's not documented, so I feel a little nervous about using this. Yeah, that's it. I just wanted to share my annoyance with Rails [laughs] or the fact that it made me work so hard to have a date of birth field.

+ +

CHRIS: You joke, but that's a lot of why we use Rails is because we want these common regular things that we're doing to be as easy as possible, to require as little code on our part as possible but also this sort of thing like there's a lot of subtlety and stuff. Accessibility is one of those things that I want a framework that has security, and accessibility, and ease of use, and all of these things just baked in, so I don't have to think about it every time. It turns out having a date of birth, or generically any date field, is going to come up in web applications a lot, it turns out. And so having all of that stuff covered is frankly what I expect of a framework like Rails. So I'm totally on board with your being miffed here.

+ +

STEPH: Yeah. Those are all really valid points. So I'm with you. What else has been up in your week?

+ +

CHRIS: Well, we've been leading up to this, I think, for many weeks. I did a Rails 6.0 upgrade a while back, and a big reason for that was partly just to get on the current version of Rails but also because I wanted to open the door to database switching, and finally, this week, I tackled it. And let's tell a tale because there was a bit of an adventure, if we're being honest. Fundamentally, all the stuff there makes sense. I'm happy with the end configuration, but there was a surprising amount of back and forth. I broke the app more times than I want to actually announce on a podcast, but I broke it only for a brief period of time. It's fine. It's fine. Everybody's fine. [laughs] I feel a little bad about it, but these things happen. But yeah, it was interesting, is how I'll describe it.

+ +

So fundamentally, Rails just has nice configuration for it. So at a high level, you're introducing your config/database.yml. Instead of it just being production is this URL, you now say primary is this replica or follower, whatever you want to name it is this. So you have now two configurations nested within your production config. And then in your ApplicationRecord, you inform Rails that it connects_to, and then you define a Hash for writing goes to the primary, reading goes to the follower. And you have to sync those up with the thing you just wrote in the config/database.yml but fundamentally, that kind of works. That makes it possible in your application to now switch your database connection. The real magic comes in the config environment production file. And in that, you specify that you want Rails to use a database resolver that says GET requests go to the replica, and anything that is not a GET request goes to the primary. So anytime you're writing data, anytime you're changing data within the system, that's going to go to the primary.

+ +

And there's also a configuration that, as far as I can tell, gives a session affinity. So for the next two seconds after that, even if you make a GET request subsequently right following it, so you make a right, you POST, and then immediately after that, you do a GET. Like, you create an object, and then you get redirected to the show page for that object, Rails will continue to go to the primary. I think it's probably using a cookie or something to that effect, but you can configure that time span. So you can say like, "Actually, we see that our follower lags behind a little bit more, so let's give it a five-second timeout where all requests for that user will then go to the primary." But otherwise, once that timeout clears, then you're going to switch back, and you're going to go to the follower, and all GET requests will happen to the follower. And that's the story. You have to configure that, and then it works.

+ +

STEPH: I always love when you start these out with "I have a tale to tell." I very much enjoy these adventures. And you also answered my question in regards to if you immediately just created something, but then you do a fetch that's very close to after you just created it and how that gets rendered. So that was perfect.

+ +

CHRIS: Frankly, the core configuration is very straightforward, and it's very much in line with what we were just talking about of; this is what I want from Rails: make this thing very easy, hide the details behind the scenes. But as I said, there's a bit of a tale here. So that was the base configuration. It sort of worked but then immediately upon deploying it to production -- So we deployed it to staging first just to test it out. Staging was fine, as is often the case. Increasingly, I'm leaning into Charity Majors' idea of you got to test in production. You're testing in production even if you say you aren't. So once it got to production, we started seeing a bunch of errors raised or a handful of errors. And they were related to a handful of controller actions, which are GET requests, so they're either show or index, but in them, they were creating, or they were trying to create data. And so we were getting an error that was read-only connection error or something to that effect, ActiveRecord read-only, I think, was the error class. And that makes sense because I told it, "Hey, whenever you get a GET request, you're going to use that follower." But the follower is a read-only database connection because it's a follower, and so it was erroring.

+ +

It was interesting because when this happened, I was like, wait, what? And then I looked into it. And it's frankly fine at all the levels. It is okay to create a record in a GET request as long as that creation is idempotent. You create if it doesn't exist, and then from there on, you use that same one. That still fits within the HTTP rules of idempotents, and everybody's fine with that, except for the database connection. Thankfully, this is relatively easy to work around. You just need to explicitly within that controller action say, "Use the right database, use the primary." And the way I implemented that, I wrote a method within ApplicationRecord that was with right DB connection, and then it takes a block, and you yield to that block. It's basically just proxying to another similar thing. And it's very similar to wrapping something in a transaction; it sort of feels like that. It's saying just for this point in time, switch over and use the primary because I know that I'm going to be having some side effect here.

+ +

STEPH: Wow. That's so fun. I'm sure it was not fun for you. But as me hearing the story later, that's fun in regards to I hadn't thought about that idea of you're telling all the GETs you can only go to the read, and now you're also trying to create. I am feeling nervous in terms of local development. So if you're working on a new controller and if you have a fetch or GET action, but you're also creating something, you haven't seen another controller that is demonstrating that strategy that needs to be used. Is it just going to work locally? I imagine it does because it was working for the other code that you were running that didn't yet have that strategy in place. So I'm feeling nervous in terms of someone could easily miss that.

+ +

CHRIS: I think there are a couple of different questions in what you just said. So let me try and answer all of the ones that I think I heard. So for local development, your database/config.yml is still going to be the same as it was. So you're just connecting to database name_development. There's only one of them; there's no primary follower. So this is a case where you have a discrepancy between production and development, which is always interesting. And maybe that's something to poke at because ideally, I want as little gap there as possible. But this is one of those cases where I'm like, eh, I don't think I'm going to run two databases locally and have one be a follower. That feels like too much to manage. Under the hood with that right DB connection method that I talked about where you want to explicitly opt-in, in the case that we're in development, I just yield directly to the block. So instead of doing the actual database switching at that point, the method is basically saying, "If we're in production, then switch to the primary and yield and if we're not in production, then just yield." And so it'll just run that code, and it'll connect to the only database. More generally, I have the connects_to configuration; I wrapped that. So that's in ApplicationRecord where you're saying, "Hey, connect to these databases based on this logic," that is wrapped if we're in production check as well. And the same thing in the top-level configuration that says -- We're getting ahead of ourselves in the story because this is the end state that I got to. It's not where I started, and I screwed some stuff up in here, but basically, all of the different configuration points, my end result was to wrap them in a check that we are in production.

+ +

STEPH: Okay. Sorry if I rushed your story. I was already thinking ahead to how could we accidentally goof this up? That makes a lot of sense for the method that's with right DB connection, that method that then it's going to check if we're in production, then we can use a primary follower strategy; otherwise, just use the database that we know of. So that helps a lot in answering those questions. And then we can pause and then get to my question later. But my other question that I'm curious about is what helps us prevent the team from making this mistake in terms of where we're adding a new controller, we add a new GET action, and we are also creating data, but then someone doesn't know to add that strategy that says, "Hey, you are allowed to go to the primary to also get data but also to write data too." And I'll let you take it away.

+ +

CHRIS: I don't know that I have a great answer to that one if we're being honest. As I saw this, it was very easy to find -- I think there were three controller actions that had this behavior in the system that I was working on. They all threw errors. It was very easy to just wrap them in this extra method and fix that, and then we're good, and I haven't seen that error again. As for preventing it from new instances of this behavior, I don't have a good answer other than potentially you share this information within the team and then PR review. Ideally, someone's like, "Oh, this is one of those things you've got to wrap it in the fancy database switching logic." Potentially, and I don't actually think this would be possible, but there's a chance that RuboCop or other static analysis type thing could look inside any index or show action and say, "I see a create or an update or any of the methods." But again, Rails is so hard to do static analysis on that I would be surprised if were actually feasible to do that in a trustworthy way, probably worth a poke because this is the sort of thing that can easily sneak out. But potentially, my answer is, well, it'll blow up pretty loudly the first time you do it. And then you'll just fix it after that, which is not a great answer. I'm open to that being a mediocre answer at best.

+ +

STEPH: [chuckles] Yeah. That's a fair answer. Just because I pose a question, I don't know if there necessarily is a great answer to it right away. And disseminating that information to the team to then having the team be able to point that out also sounds very reasonable but then still hashes that danger of someone overlooking it. The static analysis is an interesting idea, sort of like strong migrations. As you're introducing a new migration, strong migrations will do a wonderful job of showing you concerns that it has with the migration that you've added. And this is all just theoretical dreams and hopes because, yeah, that would help prevent some of those scenarios.

+ +

CHRIS: It's interesting now that this is the second time we've discussed static analysis in this very episode. Clearly, it's a thing that I want more of in my world, and yet I work in languages like Ruby that are notoriously difficult to perform static analysis on.

+ +

STEPH: I had a moment today writing a method that was currently just returning a string each time but then I was about to update that method. I was looking for a way like, well, maybe I don't always want a string. Maybe I actually want a Boolean here. But in the other case, I want a string. And the person I was pairing with they're like, "You could return -- [inaudible 29:31] Boolean in one case and then a string in the other case. Like, this is Ruby." [laughs] I was like, true, but I feel bad about it, and I don't love it. And we just had a phone conversation around that. If you're in the Ruby world following the more functional programming or type strictness and where you're returning specific types or trying to return a consistent type, it's ideal. But then also in Ruby, it's like it's Ruby, so sometimes you can finagle the rules a little bit.

+ +

CHRIS: YOLO, as they say.

+ +

STEPH: [laughs]

+ +

CHRIS: Yeah, I'm definitely interested to see where projects like Sorbet and...I forgot what the core Ruby typed thing in Ruby 3.0 is called, but either of those. I'm really intrigued to see where they go and how the Ruby community either adopts or doesn't. I wouldn't be surprised if that were part of the outcome there. I've been impressed with the adoption of TypeScript and JavaScript, which is also a very, very free language, not quite to the degree that Ruby is. But yeah, it remains to be seen what will happen on those fronts.

+ +

But continuing back to our saga, so we've now had the read-only error, we've fixed those, just wrapped them in blocks, and said, "Explicitly connect to the primary." So the next thing that I did after that, I realized that my configuration was a little bit flimsy is probably the best word to describe it. I was explicitly creating a new environment variable with the URL, the Postgres URL of the follower. And so I was using that environment variable to define where the URL like the Postgres URL of the follower database -- But I realized if Heroku comes in and does any maintenance on that Postgres instance, it's possible that the AWS IP address or other details of it will actually change and so that Postgres URL will no longer be valid. So that's one of the things that I rely on Heroku for, is to maintain my databases for me. But they will update, say, the DATABASE_URL environment variable if they change out your database. But now, I had broken that consistency. And so I'd set us up for somewhere down the road this will break, and I realized that because Heroku reached out and said, "Hey, your follower database needs maintenance." And I was like, oh, no. So, I tried to get it from -- It turned out, in this case, it didn't actually change. They were able to swap it out in place, but I wanted to add a little bit of robustness around that.

+ +

And so I actually reached out, and Dan Croak, former CMO of thoughtbot, actually had written a wonderful blog post about how to configure this and particularly how to configure it in the context of Heroku. And he described how to use the Heroku naming scheme for the environment variables. They happen to have colors in them. So it's like Heroku Postgres cyan URL or orange URL or purple URL. And so he defined a scheme where you set an environment variable that describes the color, and then it can infer the database URL environment variable from that. And then went the one step further to say, "If that color environment variable is set, then treat as if we are configured for database switching. But if it is not set, even if we're in production, pretend like we don't have database switching," which that was another nice feature that I hadn't built in the first place. When I first configured this, I just said, "Production gets database switching. And if we're in production, then database switching is true," but that's actually not something that I want. I want to be able to say, "Upgrade our follower," at some point or do other things like that. And so I don't want to be locked into database switching on production. So that was a handful of nice configurations that I wanted to get to.

+ +

Unfortunately, when I tried to deploy that switch, man, did it break. It broke, and then I was like, oh, I see I did something wrong there. So then I tested again on staging. Staging was fine. And then I went to production, and it broke again. And this happened like three times in one day. I felt like a terrible programmer. I had no idea what I was doing. Turns out that staging and production had different environment config files, and so their configurations were fundamentally different. They also had a different configuration for the database level. So one of the things I did as part of this was to clean those up and unify them so that staging was production with some environment variables to config it, but identically production, which is definitely a thing that I believe in, and I want basically all the time. I don't think we should have a distinct staging environment config that is wildly different. It should only vary in very small ways, basically just variables that say, "This is where the database is for staging," but otherwise be exactly configured as production. So I eventually got on the other side of that, fixed everything, have a nicely Heroku-fied color-based environment variable scheme, which is a bit of a Rube Goldberg machine, but it works. And I was able to hide that config in one place. And then everything else just says, "If there is a database follower URL defined, then use it." But yeah, so that was the last hard, weird bit of it.

+ +

And then the only other thing that I did was I realized that this configuration was telling the Rails server how to behave, but there are also background jobs. And this application actually happens to have a ton of background job traffic. And so I did a quick check of those, and there were a handful of background jobs that were read-only. A lot of them were actually sending data to external systems, so to analytics or other email marketing or things like that. And so constantly, as users are doing anything in the application, there are jobs that are queued that aggregate some information, maybe calculate some statistics, and then push it to another system. But those are purely read-only when those jobs execute. And so I was able to add another configuration which said, "Use the read-only connection and configure that to wrap those particular sidekick jobs." And with that, I think I have a working database switching configuration that will hopefully give us a lot of headroom in the future. That's the idea, that's the dream, but we will see.

+ +

STEPH: That is quite the saga between having GET requests that create data and then also the environment inconsistencies, which is a nice win that then you're able to improve that to make those environments more consistent. And then the background jobs, yeah, that's something that I had not considered until you just brought it up, and then being able to opt-out of the database switching sounds really nice. In regards to moving in this direction, you're saying gave you a lot of headroom for this; when it comes to monitoring performance, is there anything in place to let you know how it's doing?

+ +

CHRIS: I love that I knew that this was going to be your question. I love that this is your question because it's a very good question. And unfortunately, in this case, it's actually somewhat unsatisfying. So as is my typical answer for this, we're using Scout as the application performance monitoring tool on this. And I was able to go in and monitor what it looked like a week ago, what it looked like after I made the change, and it was a little better. And that's all I can say about it. But that's fine. The idea with this, and at least in the way I was thinking about it, is this should get better at the margins. On the days where we have a high spike in traffic, those are the days where the database is actually working hard. They shouldn't make the normal throughput of the application that much higher in the regular case; it's for those outlier instances. To that end, though, I did analyze it. And so the average response time got 2% to 3% better in that week-by-week comparison, which was fine. The 95th percentile response time, so starting to get out to those margins, starting to get to the long tale of where stuff gets -- a couple of requests came in at the same time, and the application had to try a little harder, those got 8% to 9% better. That shape of improvement where for most requests, nothing really changed for some of the requests that used to be a little bit slower; those got a little bit better. That's the shape of what I would hope to see here. And it remains to be seen. This application has particular traffic patterns where they'll encourage a lot of users to be using the app at the same time. And historically, those have been somewhat problematic, and we've had to really work to shore up the performance in those cases. That's where I'm really interested to see how this goes. It would be hard to replicate those traffic patterns at this point. So I don't have a good way to really stress test this, but my hope is that for those cases, things will just hum along and be happy.

+ +

STEPH: That makes a lot of sense and something that would be hard to measure, but the fact that you already see a little bit of improvements that's encouraging.

+ +

CHRIS: But yeah, certainly, if I get a chance to see what that looks like in the near term, I will respond back and let you know how this has played out. But overall, now the configuration seems pretty stable. I think we're in a good spot. Hopefully, we won't have to do too much proactive management around this. And ideally, it just buys us a little bit of headroom. So that is certainly nice. But with that, with your wonderful question getting to the heart of the issue, I think that wraps up the saga of the database switching.

+ +

STEPH: Well, I appreciate you sharing that saga. That's really helpful. I've been very excited to hear about how this goes because I haven't gotten to work on a project that's going to use database switching just yet. And now I know all the inside baseball. I'm trying to use sports metaphors here as to how to do this for when I get to work with database switching.

+ +

CHRIS: Sports de force.

+ +

CHRIS: Along the lines of new stuff, there is something I'm excited about. So in juxtaposition to my earlier statement or my earlier grievance where friends don't let friends use date_select in regards to trying to keep the web accessible, I do have some praise for something that's being added in Rails 6.1 that I'm excited about. And it's a really nice method. It's a query method that can be used to find orphan records. So if I'm writing a query that is then looking for some of these missing records, so if I have my table -- I didn't come with a great example today, so let's just say we have like table A and then we're going to left_joins on table B. And then we're going to look for where the ID for table B is nil, so then that way we find where we don't have that association that it's missing. And so left_joins does this for us nicely. And then I always have to think about it a little bit where I'm like, okay, I want everything from table A, and I don't want to exclude anything in table B if there's not a match on the two. And so then I can find missing records that way or orphaned records that way. The method that's being introduced or has been introduced in Rails 6.1, so anyone that's on that new-new, there is the missing method. So you could do tableA.where.missing and then provide the table name. So there's a really nice blog post that highlights exactly how this method works, so I'll use the example that they have. So for where job listings are missing a manager, so you could do JobListing.where.missing(: manager), and then it's going to perform that left_join for you. And it's going to look for where the ID is nil. And I love it. It's really nice.

+ +

CHRIS: That sounds excellent. That's definitely one of those things that I would have to sit down and squint my eyes and think very hard, really anything involving left_joins otherwise center. Any joins always make me have to think and so having Rails embrace that a little bit more nicely sounds delightful.

+ +

STEPH: Yeah, it sounds like a nicety that's been added on top of Rails so that way we don't have to think quite as hard for any time; we want to find these orphaned records, and we know that we can use this new missing method.

+ +

CHRIS: On the one hand, I feel bad saying, "I don't want to think that hard." On the other hand, that's literally our job is to make it so that we encode the thinking into the code, and then the machines do it for us. So it's kind of the game, but I still feel kind of bad. [laughs]

+ +

STEPH: Well, it's more thinking about the new stuff, right? Like, if it's something that I've done repetitively, finding orphan records is something I've done several times, but I do it so infrequently that then each time I come back to it, I'm like, oh, I know how to do this, but I have to dig up the knowledge. How to do it is that part that I want to optimize. So I feel less bad in terms of saying, "I don't want to think about it," because I've thought about it before. I just don't want to think about it again.

+ +

CHRIS: I like it. That's a good framing. I've thought about this before. Don't make me think about it again. [chuckles]

+ +

STEPH: Exactly. On that note, shall we wrap up?

+ +

CHRIS: Let's wrap up.

+ +

STEPH: The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: The show is produced and edited by Mandy Moore.

+ +

STEPH: Thanks, Mandy. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes as it really helps other people find the show.

+ +

CHRIS: If you have feedback for this or any of our other episodes, you can reach us at @bikeshed. And you can reach me @christoomey.

+ +

STEPH: And I'm @SViccari.

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+dEhGRiKE + + ]]> + + Chris Toomey + Steph Viccari + + + 292: Debugging with Joël Quenneville + https://bikeshed.thoughtbot.com/292 + 834b6ce3-e660-4b09-b948-39b9f7a19d59 + Tue, 11 May 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris are joined by fellow thoughtbotter, Joël Quenneville, to discuss all things debugging. Joël is helping publish a weekly debugging blog series and in this conversation they discuss how the series got started, technology agnostic debugging strategies, writing less bug-prone software, and speculate if Joël moonlights as a hockey coach. + + 43:01 + no + + + On this week's episode, Steph and Chris are joined by fellow thoughtbotter, Joël Quenneville, to discuss all things debugging. Joël is helping publish a weekly debugging blog series and in this conversation they discuss how the series got started, technology agnostic debugging strategies, writing less bug-prone software, and speculate if Joël moonlights as a hockey coach. +Debugging Blog Series 2021 (https://thoughtbot.com/blog/tags/debugging-series-2021) +Classical Reasoning and Debugging (https://thoughtbot.com/blog/classical-reasoning-and-debugging) +Monodraw (https://monodraw.helftone.com/) +An Elm debugging story (https://thoughtbot.com/blog/elm-debugging-story) +Chelsea Troy - PoSD 2: What causes insidious bugs? (https://chelseatroy.com/2019/12/30/posd-2-what-causes-insidious-bugs/) +Follow Joël Quenneville on Twitter (https://twitter.com/joelquen) +Joël Quenneville on the thoughtbot blog post (https://thoughtbot.com/blog/authors/joel-quenneville) +Transcript: +STEPH: All right. And then who will be editing this episode will be Mandy. So as we run into blunders, which we never do, but if we do, then we can talk to Mandy and ask her to edit things for us. So I will try very hard to do that because I will likely still talk to Thom. [chuckles] +CHRIS: Hello, Mandy. It is a pleasure to meet you. In the last recording that will be going through you, I was referring to you indirectly as our next producer. But now that we know your name, I'm so excited to have you on the team and to know who is on the other side of these, hopefully not too nonsensical recordings. So pleasure to meet you. +STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. +CHRIS: And I'm Chris Toomey. +STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey Chris, today is an extra special day as we have a guest today. Joining us is Joël Quenneville, a thoughtbot developer extraordinaire and a previous Bike Shed guest. Welcome, Joël! +JOËL: Hi. +CHRIS: It's a pleasure to have you. +JOËL: It's good to be on the show. +STEPH: So, Joël, you and I are on the same client project. And during the past few weeks, we have encountered some very challenging bugs. In fact, if I look back at my developer journal, the last five or so of my entries begin with a very cheesy mystery title that's like the case of the missing data or Harry Potter and the chamber of errors. But in addition to spending your time bug hunting with me on this project, I understand that you and other thoughtboters, Jesse Bailey and Louis Antonopoulos, have been publishing weekly blog posts specifically about debugging. +JOËL: Yes, that's correct. This has been a project that we've been doing for a little while. We spent about three months doing research, conducting a bunch of interviews, and gathering a lot of material on debugging. And then, starting in April and through the middle of the summer, we are publishing an article every week on the topic of debugging and exploring different aspects of it. +STEPH: I'm really curious; what prompted y'all to start talking about debugging? I'm really excited to talk about the specific topics that are included in the series. And then also you mentioned all the research. I'd love to know how you went about that research. But before we go there, what prompted this conversation and then led to the creation of the series? +JOËL: Within thoughtbot, we spend a lot of time trying to improve ourselves, improve the broader community as well. And there was a conversation that got started about how we could get better at debugging. It's a thing that, as developers, we do all the time, and it's not something that's often taught explicitly. Many of us our experience with debugging has been very much just learning on the job and picking it up by osmosis and trial and error. And when you're more junior, a lot of that is just random stuff and changing random lines of code and maybe copying something from the internet and hoping things go well. And as you build experience, you tend to start becoming a little bit more methodical because you've seen what works and what doesn't. And so we wondered within thoughtbot, we have all these different people who've come up with their own experience. Can we meld that together and share the summary of all thoughtbot debugging knowledge combined and help everybody level up? Initially, we were wondering could this be just an internal workshop or something where we get together and exchange on the different ways that we've learned or different techniques that each of us uses? But then this evolved into a project that we wanted to share not just within thoughtbot but with the wider world. And so its final form, or at least its current form, has been a blog post series that's going to run over the course of three to four months. +STEPH: I appreciate how you've taken the opportunity to take all of this knowledge and then turn it outward-facing, so it's available to the public as well. And it really wasn't until you were talking about the series and then I started reading the weekly blog posts that are being published how little I read about concrete strategies around debugging. I think you said it very well earlier in terms of it as something that you pick up on the job, and you learn different strategies as you go. It's really hard to know exactly how to go about debugging unless you've had experience with that type of bug before. +CHRIS: I've been also reading the blog posts as they come out. And I'm similarly very grateful for both the general theme of thoughtbot of hey, let's take this thing and actually make it a shared resource for the world. But specific to debugging, it really is this interesting intersection of practical steps that you can take but also almost an art form. There's like, oh, I use Pry, and I put a debugger statement here, and that's a mechanical approach that we have. But then there's also the more general how do I think about code, and how do I build a model in my head and compare that to the thing that's running on my screen? And that is really so much more something that you learn in passing, or at least it typically is. And this idea of trying to be a little more purposeful and share more of that with the world is something that I absolutely love because it is both the harder aspects of the job but also probably one of the more common. I'm spending a lot of time being like, why isn't that working the way that I thought it would? I don't know, maybe 90% of my time as a developer, maybe I'm a bad developer, but it's so much of the time that I spend. And so any amount that I can get better at this or learn from others, I'm super open to that. So thank you for producing this and for sharing all the secrets. +JOËL: I liked your example of saying you drop in and you drop Pry to put a debugger at a particular location. And I think that maybe that's something that most people are familiar with and might use. But even something like that sounds like a fairly simple, basic concept. I think someone with a lot of experience, if you're pairing with them, you might ask, "Why did you put the Pry here and not there?" And that might make the difference between spending all day versus spending half an hour to find the bug. And that's, I think, a lot of where the experience comes in and where being a little bit more structured, having a strategy can really make the difference in being efficient. Because oftentimes, you're using the same tools and doing roughly the same techniques, but one can be totally flailing and doing random stuff, hoping you'll get lucky with a solution. And the other one is very methodically working towards finding the problem. +CHRIS: I love that framing of the question, but I also love the idea of you ask that to someone, and they're like, "Huh? I don't actually know. But now that I think about it…" and then they sort of discover the answer. But it's very much they're operating from intuition and just like, well, obviously I put the debugger right before the line that I think has this going on. But that's not necessarily something that's top of mind. So when you ask the question, you almost help them to formalize it. So yeah, there's gold in those hills. +JOËL: Absolutely. Definitely. I think gaining self-awareness about why you do what you do is always such a rich exercise, at least in my experience. +STEPH: There's an interesting comparison here where people will ask me how to do something in Vim. And I'm like, oh, let me do it first because I need the muscle memory for it, and then I can tell you how to do it. And I feel like debugging is often the same way where I'm like, well, let me hear about the problem, and then I can work through it with you, but I can't necessarily tell you off the top of my head all the different strategies that I would apply. So I really liked the idea of becoming more self-aware as to how you would approach that so then you can provide those tips to someone else. +You mentioned earlier about the research for creating the series, and I'd love to hear more about that. Because I imagine there's so much that you could talk about in terms of debugging but then still wanting it to be helpful to people that are working in different technologies. So how did that research go? What did that look like? +JOËL: Initially, this was focused on experience within thoughtbot. So we focused a lot on more internal research. We had a survey where people just shared their debugging thoughts, tips, and tricks. And then, we also set up a bunch of interviews with multiple thoughtboters across varying levels of experience to get their thoughts on debugging, and that was incredibly rich. So we did, I think, 10 or 12 interviews within the company. We captured all of that and then synthesized the output of those interviews, the survey with all of the random tips and tricks, existing thoughtbot blog content. And then, we also pulled some external resources that we had found as well as some podcasts, some other blog posts elsewhere. And we have tried to mix all of that together to come up with 10 or 12 high-level topics that we thought were particularly valuable to talk about and then turn those into blog posts. +STEPH: That's really awesome. I love how you took that approach of interviewing different people to take that instinctual knowledge that we have around how we're debugging but then helping people put that into words and then capturing that and then sharing it. What type of questions did you ask people to help people walk through what are their debugging strategies? +JOËL: That was actually pretty fun because we came up with a list of questions ahead of time, not that it was a strict list to be adhered to, but we wanted to have something to have a little bit of commonality between the interviews and then let them go where they will. Most of them we opened up with just asking people, "What does the word debugging make you feel?" What is your personal connection to debugging?" And I expected most people to be like, "Oh, dread or frustration," And that was not the case. Most people said, "Actually, I like debugging. It's a challenge. It's a puzzle. It appeals to the analytical side of me." One person mentioned that it's like the code equivalent of an escape room and that escape rooms are one of their favorite things, and so they actually really enjoyed it. Where a lot of the frustration comes in is when you have deadlines, and this bug is unexpected and therefore is taking time away from things you really need to be doing now or yesterday. And so the timeline can cause pressure, but the bug itself most people seem to enjoy finding the bug. +STEPH: I love so much that you just used the comparison of an escape room because I was just chatting with someone recently about how my week has been going, and I'm like, I am in an escape room. That is my job this week is to figure out how to get out of this or to understand what is happening in the system. So that's really funny. That's also very encouraging to hear that so many people have a positive association with debugging. But I certainly understand that it's more the deadline, the timeline that is then putting pressure on us to solve something quickly, but we actually enjoy the hunt is what it sounds like. +CHRIS: And in my experience, when it goes well, it can be really fun. But then there are those days where not just under deadline pressure but just sort of I lost a day to blah. I couldn't figure out what was going on. And especially when it turns out to be something relatively simple, that feeling is somewhat crushing. But when there's this like, oh no, things are not working the way I expect it, and then I'm able to dig in, read a bunch of Stack Overflow, put a bunch of debug or put statements and crack that, that is a fantastic feeling. And there is the optimum flow level of where it's just at the edge of your knowledge and skill set, and it doesn't take too long, but it's not too easy. Because, like you said, the thrill of the hunt is there. So there is a sweet spot, I think, and there are ways that it can go wrong on either side. But I definitely resonate with the idea that a medium-scale bug that I'm able to tackle that's a good day, actually. I feel good at the end of that day. +STEPH: There's a delightful blog post by Chelsea Troy where they share a graph that talks about the time spent debugging versus the probability of a one-line fix. And so the more hours that you've invested into fixing a bug -- Joël, I think I found this particular blog post thanks to the Debugging Series. It's like two in one of those posts. And so the more hours that you sink in finding a bug, the more likely that it's going to be just a one-line fix. And those are the ones that feel the most painful to me. It's something that is small and comes down to an incorrect assumption about the system. And those are the ones that feel good that I solved it, but I didn't really enjoy the hunt for that one. There's a specific time window in which I'm enjoying myself, which then just becomes stressful and frustrating. +JOËL: Sometimes, it almost feels like the number of lines of code for the solution needs to match the amount of effort it took to find the bug. And so if I spend a day searching for the bug, it's frustrating that it's only one line and that the solution took 30 seconds, but the search took eight hours. +CHRIS: I think my measure would be the length of the commit message associated. I'm fine with a one-line change as long as there is a couple of paragraphs of explanation of the journey that I went on and not just self-serving like, hey everyone, listen, because this was rough for me. But the look at all the things I learned, let me capture that knowledge here because there's actually a bunch that this one code line change encapsulates. But it's actually looking at the history of HTTP and the way that the different headers are handled in different browsers and, for many reasons, this one-line change. But if it's a one-line change and the commit message is like, "Oh, typo, sorry," then I feel bad. That's a bad day for me. [chuckles] +JOËL: This reminds me of the project, Steph, that you and I are on where I've definitely had several bugs that I've gone through to fix where the commit message is definitely quite a bit longer than the actual diff. And the commit message includes ASCII diagrams showing the structure of certain database tables and why I had to change a particular query. And it's weird. And you would never understand why without realizing the schema. So yeah, I definitely feel you there, Chris, where sometimes you go on a journey, and it's very important to record that for the next person. +STEPH: Yeah, your commit messages have been phenomenal. And I love all the diagrams that you've included because that has helped me have context for what exactly you understand about the system and what appears to be wrong with the system. That has been wonderful. Speaking along those lines, as we were just talking about how it can feel very ephemeral in terms of the strategies that we use for debugging, I'm really curious what strategies do y'all use for debugging? Do you have particular tools that you use? I know Joël, you are a fan of diagrams. Is there a particular tool that you use for that? +JOËL: There's a variety of tools that I'll use. Recently I've been using Monodraw, which is a tool for macOS that allows you to make diagrams that can be exported as text using various ASCII characters, which means that you can then draw an entity-relationship diagram of your database and include that in a commit message where it needs to be text. You can also export it as an image. But the fact that I can use it as text in a commit message has made it particularly valuable recently. So that's my latest go-to diagramming tool. +STEPH: That's really nice. I haven't used that, but I've been seeing you use it so extensively that I've added it to my list of things to check out very soon. Are there any other particular strategies that you use, since we're on the topic of concrete strategies, for debugging and how you approach debugging? +JOËL: I am a big fan of binary search, which sounds like a fancy computer science term. But I think from a very practical standpoint; it's just a process of elimination. Sometimes finding where the bug is, is harder than where it's not. And so can I eliminate roughly half of this file or this project or whatever and know that it's not a concern and then keep repeating that until I have a pretty small surface area to actually find the bug itself. And this can be as simple as just commenting out lines of code. And so, like, I'm going to comment out roughly half the lines in this method and see can I still reproduce the bug? If so, then I know it's in the ones that haven't been commented repeat, repeat until I find the bug. And because you remove so much code every time that you have, it takes relatively few steps until you find a very narrow area in which the bug likely is. +CHRIS: I love that. Binary search is definitely one of my favorite approaches. And I think that was a very welcoming and friendly introduction to the topic for anyone that might not be familiar. But it really is such a simple and yet effective tool for narrowing down the scope. Because when you look at an entire application, you're like, ah, something's wrong, and you start from the outside, that's overwhelming. But if you can start to narrow it down, especially, like you said, in this more methodical, purposeful approach, that is really wonderful. I think one of the tactics that I have been reaching for more and more is using minimal reproduction cases. So rather than actually working in the context of the full application -- This is especially true if I'm working on, say, a JavaScript app or Svelte is the most recent example. Svelte has a REPL on the svelte.dev website. And I find myself more and more reaching for that and just trying to very minimally reproduce code that just isolates that bug. And then I try and tease away the pieces, but now I'm left with this minimal reproduction there in an executable format, and that ends up being really useful. The same sort of thing if I'm on the Ruby side, I might actually do in a Spec just because that's a really nice way to harness execution and be like, I want to do these things. Here's the setup. And it's one of the reasons we love Specs, but I find it's actually a really great tool for setting up some data, executing the app in a certain way, and then testing it. And I find particularly with RSpec and Rails; I feel like I have good control over getting the system into a certain shape. Other applications I find that's a little more difficult, so other techniques may be necessary. But yeah, that's definitely one of the things that I've been leaning on more and more is minimal reproduction so that I can really narrow down the scope of what I'm looking at. +JOËL: I like that example, Chris. And that actually is a variant of probably one of my favorite approaches, which is reasoning by analogy. So you have a hard problem, and you can't figure out a way to solve it. So you find a similar easy problem, find the solution to that, and then try to backport the solution to your hard problem. Oftentimes, the easy problem is just a simplified version of your hard problem, such as stripping out all the unnecessary detail, then you can backport that. But sometimes, it's just something in a different domain that you understand more easily, and then you can take that solution and backport it. And I had a magical experience a while back. For those of you who know me, I'm a big fan of the Elm language. And I spend a lot of time in their Slack just helping out people. And someone ran into a situation with random generators, which are a concept in that language that can generate random values. And they're trying to combine a bunch of them and having really weird bugs. And I tried a bunch of different techniques to figure out what was going on, and I couldn't figure it out. But the thing that I did figure out is that random generators in this particular dimension we were trying to understand work very similarly to functions, which are a much more simple concept. And the moment I realized, oh, in this very particular way, generators and functions are the same, all of a sudden, that unlocked in my mind; wait, I can reason by analogy here because I know how to solve this problem with functions. I don't know how to solve it with random generators. So I went and solved it by saying, "I don't know how to compose a bunch of generators. I do know how to compose a bunch of functions, figure that out and then take that solution and bring it back to generators." And I followed that process through, and it worked, and it was amazing. I came in to work the next day, and I was really excited about this. And I was talking with some colleagues, and everyone's like, "You should write about that." So there's a blog post from a year or two ago where I walked through my whole process and all the different debugging strategies I used, including reasoning by analogy to solve what was a pretty tricky bug. +STEPH: I love how the typical response from talking to a thoughtboter about going through something like that is often, "Oh, you should write about it." +CHRIS: And I'll help you edit it, not just "Please go write that." And Joël, you live that to the extreme. You have been an absolutely prolific author on the thoughtbot blog. And you bring some of the images and things like that that you're talking about. You really, I think, provide such a great example of paying knowledge forward and sharing better. So if anyone wants to learn about blogging on the internet, just go follow Joël's, work for a while, and you'll learn some great things. +STEPH: Yeah, that is so true. I love how much you publish, and I'm a big fan of everything that you write. One of the debugging strategies that was mentioned in the blog post that really rang true for me was talking about identifying assumptions because that is one that I typically fall into where I will read about a problem, and then I will say, "Okay, I understand exactly what problem they're running into." And once I start troubleshooting, if I'm unable to reproduce -- Because I follow a similar strategy, Chris, that you just mentioned where I will try to replicate the issue either if I'm doing it locally or ideally if I'm writing a test, so then I can write a test that fails and then I can then make that test pass. But if I'm unable to reproduce, then I'm forced to go back and say, "Okay, am I making an incorrect assumption about what's being reported?" And that has been so helpful. Like, there are just little things where I realize I'm on autopilot for where it's like, the user downloads a report, and I'm like, oh well, they mean this report. And then I find out that they actually meant something else. Also, assumptions in the codebase, and that's one that you and I, Joël, have run into so much with this past week in regards to assumptions in the codebase as to how many associations a record can have. Is it one? Is it many? It has many, but it really only wants one record. So assumptions from the perspective of when someone is reporting an issue and then also assumptions in the codebase. For the first one, I have found that, especially when I'm new to a team when someone reports an issue, I often like to hop on a quick call with them and say, "Hey, are you able to reproduce this for me? And so I can watch you, and I can understand your workflow." And I have found that typically speeds me up drastically. +JOËL: One of the things that was mentioned in the article on listing assumptions which is maybe a bold claim, but it opens by saying that all bugs are a form of miscommunication. And this might be human-to-human communication where you didn't understand the requirements or what was trying to be done. But code is also communication between us and computers. We want computers to do a thing. And if the computer doesn't do what we're telling it to, it's not doing that just to show us who's boss; it's because we didn't communicate correctly what we wanted. And so yeah, trying to better understand ourselves what we mean and our assumptions is a key part of debugging. And that's the thing that came up over and over and over in all the interviews was one, build self-awareness about the assumptions you have, and there's a bunch of different techniques for doing that. And then once you have self-awareness of what your assumptions are, never trust anything, validate, validate, validate, because yeah, you're often wrong. +CHRIS: There's an interesting parallel to that in my mind of we often end up with these systems, and it's behaving in an odd way. And so we have to build this mental map of okay; what are all of the different states and workflows that can get us into those various states? And having now debugged a handful of times in my life, I'm trying as much as possible to flip the script and go with an ounce of prevention is worth a pound of cure. And this is why one of the most common things that I say in a pull request is, "Hey, can we make that null false on that new database column? Hey, can we change this type constraint so that instead of it being a Boolean and then another attribute, it's actually a three-state enum?" and et cetera, et cetera. How can I collapse the states down so that when I'm in debugging mode, I actually can take some things as givens? Still, maybe validate from time to time, but the more I can learn to trust a type system or the database or things like that, things that are a little more trustworthy than I am or other humans, I'm increasingly loving that. And there's obviously a gentle balance there, but that's something that I've been leaning into more and more. And I think it's directly informed by the years of my life that have gone into debugging at this point. Is that accurate? That seems like a high estimate, but it's a lot. It's a bunch of weeks at a minimum. +JOËL: I felt that really strongly. I'm kind of disappointed as an industry that we default things to be nullable so often. I wish database columns were non-nullable by default, and you had to opt in to make them nullable. I wish GraphQL didn't make columns nullable by default. And I think oftentimes, when you're working in a dynamic language, you don't care about that distinction. And so you just let it go by. And let's say with GraphQL, again, I hang out a lot in the Elm Slack channel, and I spend a lot of time helping people integrate Elm in GraphQL. And when you get a schema and try to load that into Elm because it has a type system, it will read your schema and wrap everything in maybes because it's as though this field is optional, this thing is optional, this thing is optional. And then people come to the Slack, and they're like, "Why is there maybe everywhere with deeply nested -- This is a terrible mess in Elm. What went wrong?" And then I have to tell them, "It's not the Elm tool that's wrong. If your schema has this implicitly, the default thing was to make it null." And so it just looks normal, and you want to put all those exclamation marks everywhere. And a lot of time people don't believe me. And I have to say, "No, no, you're right. It really is the schema that's the problem. Please go put all these exclamation points." I'll give an example of a non-null schema, and then they try it, and they're like, "Wow, this makes such a difference." +STEPH: Joël, the defender of Elm. +JOËL: [laughs] +STEPH: And I am with you, and it is interesting. And I've been there myself, too, where there's a fear of over-restriction in terms of if I make this not null and something blows up, then that feels like a bad outcome. And so I've seen a number of projects where we let nil get through so easily because then we just always handle the nil versus having that restriction earlier and making that decision. It's like we're pushing off that decision of like, well, that'd be nil for now, and then we'll figure it out later. Versus starting with that decision upfront and saying, "No, let's go ahead and make that decision now. What do we do if this is nil?" And I agree that it would be wonderful if we had more restriction upfront and then we loosened the requirements as we find out that we need to versus starting with the loose requirements because walking that backwards is incredibly difficult. +JOËL: Yes, having to backfill nullable columns that we don't have values for in the database because now we want to restrict it, but for years we didn't collect that value. And so what do we do now? That becomes really tricky. +STEPH: Chris, a minute ago, you were mentioning prevention, which I love so much because then we can avoid a number of these debugging discussions, although this is also delightful. But there's an opposite end of that spectrum that has taken me a while to gain comfort with, and it is when you don't know enough about the bug, and you can't reproduce, and then you essentially have to let it go. And there are other ways that you can debug, but you can't fix it in the moment. So let's say that you have an error or something that happens every once in a while, but you can't actually find the reasons that it's happening or if you have data that's getting created in a certain state, but you don't know what in your application is creating that state. So instead of spending what could be hours and days triaging how your system got in that state is instead perhaps adding some logging around it to say, "Hey, this is the moment where we are causing this to happen," or maybe it's adding a constraint, so something fails very loudly whenever the system tries to put data in a particular state. And in those cases, it took me a while to become comfortable with the idea that I can't solve this today. I can't solve it now, but I can take steps to then know how this is happening. So then, in the future, we can actually prevent this or apply the fix. But initially, that always felt like a really bad outcome for a ticket that's reporting a bug where it's like, hey, I can't fix this today. I don't know exactly what's happening, but I've added some logging, or I've added something that's going to raise when this happens. So when we do get notified of it again, then we can more quickly triage and put the right fix in. +CHRIS: Yeah. If anything, I feel like there can be a -- Like we were talking about earlier, there's almost an enjoyment to solving a bug where it's a puzzle. It's a thing that may capture our attention, but sometimes, actually, perhaps often, the correct answer is that's actually not the most important thing right now, or the cost is too high to try and solve it given the information that we have. It's affecting a very small number of users. Maybe we can make that experience better. It's not just a generic 500-page, but we turn it into a, "Hey, sorry, you got into a…" like a more explicit error state but defer the actual debugging because there are other things that are slightly more pressing, affecting more users, or again, we just don't have enough information. And I feel like that actually can be a difficult thing to be like, no, but I want to solve the puzzle now. This is a fun puzzle. Please let me solve the puzzle. But sometimes, we don't get to solve the puzzle today. +JOËL: One of the articles in our series that I'm really excited about takes a look at classical philosophy and various categories of reasoning identified in classical philosophy and how we can apply them to debugging to debug in a more strategic and methodical manner. And one of those categories is inductive reasoning, which is very similar to, say, the scientific method where you gather a lot of information. And then, based off of those cases, you try to come up with a pattern, have a hypothesis for it, test it. And then if you can show that it's actually the case, then you're likely correct. But of course, that depends on having enough test cases for there to actually be a pattern and for it to be statistically significant. And so for some bugs, if there's only one instance of it happening and you just say, oh, somehow a bad value made it from our front end UI into the database, and we don't know how. But it's not happening to every user. Like, there's only one use case, and we can't figure out how that happened. We don't have enough information to build up those test cases to try to find a pattern. And so that's where getting more test cases becomes really important. As Steph mentioned, logging can be really helpful here, raising whatever you need to do. Maybe it's adding a constraint or a validation to say, "Blow up the next time this happens." But once you have enough test cases, then you can start seeing patterns. And that's your inductive reasoning to solve the bug. +STEPH: Something that we touched on earlier but I don't think I've given enough credit to but is something that I really appreciate is the fact that all of these strategies that are being talked about in each blog post are applicable across technology stacks, across languages. Because you really highlighted a point just a moment ago around how most of the bugs that we're working with are all bespoke. They're all special little bugs in their own special way. And so it's really hard to have a blanket strategy that then applies to each one because they are unique. And the fact that y'all are creating so much content that has general strategies that people can apply when debugging is really impressive to me. So I'm really curious how are y'all doing that? +JOËL: When we came up with a series idea, we laid down a few principles for how we wanted the outcome to be. And one thing that came up pretty early was it's important for this to be language agnostic. We don't want to just teach like, here are some very specific Ruby tools you can use, which that's a very helpful article, but that's not really the kind of information that we were looking for. So we were trying to find what are some higher-level techniques and strategies that are usable throughout your career? And then secondly, we wanted to focus on finding bugs rather than how do you solve them or how do you prevent them? Chris mentioned a little bit earlier about techniques for preventing bugs from happening in the first place, and we might have a bonus episode or article on how to write bug-resistant code. But the focus of the series is what are some language agnostic ways that we can improve your search to find the root cause of a bug? And a lot of that has just been synthesis, so saying okay, here's a bunch of different things that different people told us. And we were fine with having language-specific examples in the interviews. But how can we then find what's common and what's not? One thing that I think was really interesting was talking how different people gain information about a particular point in code, and debuggers are a pretty common way of doing this. But print line debugging is also a really common way to do that. And every language does this slightly differently. And you can even do this, not just via text, but visually. So if you're writing CSS and you are trying to figure out when a particular rule triggers, you might put a 1-pixel red border around something. And that's CSS' equivalent to print here or console.log in JavaScript or Ruby or some other language. +So the idea is to see all what different people told us and then see can we extract a general principle out of this? And walking a fine line between we want the theories to have practical advice for people that they can use but also zoom out just a little bit so that we have some of the big picture so that you can make some of these big connections and see some of the patterns that can help you apply in different situations that you run into for debugging without necessarily getting head in the clouds, you know, what is debugging? And I'm sure there's a really fascinating philosophy article, not the classical philosophy article I mentioned; that one's actually good. But you can philosophize about debugging in a way that's too abstract to be useful. So we want just a touch of the philosophy to keep it big picture while also giving very concrete, useful tips and techniques that are language agnostic that folks can use. +STEPH: That's fabulous how y'all are able to separate that thought process away from the direct, specific action that someone takes. So when someone is dropping in that console.log statement or that print statement, it's like, okay, but what thought process took you there to the point that then you were trying that action? I really like that. There's one other trick that was mentioned in one of the articles that I also really enjoy. It's the analogy of taking a ball of yarn with you, so you're always tracking where you've been. And that is the other thing that I do heavily when I'm debugging is that I always have a note-taking application that's open because I always document what I've looked at, what were my findings. And then I think through what do I want to look at next? And sometimes I'll write down a list of three or four different questions of it could be this, it could be that. And then, I will prioritize those based on what's the quickest to look at? What can I replicate the fastest? What can I remove from this list? Back to earlier, when you were talking about the process of elimination and then walk through each one. So that way, when I do find the bug, I also have those steps that I can look back. So in case, someone has a question about it, in case they're like, "Well, what about this?" I can say, "Well, yes, I also checked that," or there just may be extra helpful tidbits that fall out of that process. At least they prevent me from checking something twice. +JOËL: I've been pairing with you, Steph, on several bugs recently, and I've really appreciated the notes that you keep. They're very thorough, and that's something that I've tried to bring into my own practice by seeing you do that. +CHRIS: That's something I've been iterating on in my own workflow of late is having a directory of notes associated with each project. And as I'm working on each, it's almost not even just bugs at this point but any new feature anything that I'm exploring. Because often, initial exploration of integrating with a library feels a little bit like debugging, sort of poking at the edges and what's true and what's not and writing up little reproducible steps of okay, run this code, then this code, then this code. And I've now just taken to keeping those forever because it turns out like, oh, I know I integrated that, but what was the step? I feel like there was something I did. And being able to go back and have that artifact now is so useful. And it's actually something that I've only really gotten in the habit of over, I'd say, the last two years, but that archive of notes is now very useful even to this day. +STEPH: So I think we've covered a number or hinted at a number of the wonderful topics that are included in the series, including some of the different ways that we can identify our assumptions or ways that we can get unstuck. That was one of my favorite ones on all the different ways to get yourself unstuck when you are in the throes of debugging. There's also the idea of when you encounter a bug that if you can't fix it right away, but then some of the steps that you can take to then be able to fix it in the future. I would love to know, if you don't mind sharing some spoilers, as to some upcoming topics that will be in the unpublished but soon-to-be-published blog posts. +JOËL: Yeah. So for all of The Bike Shed listeners who want the inside scoop, there are a few that I'm really interested in. So we opened the series by talking about mindset issues, how to approach a bug, how to think about assumptions, and now we're moving into some more concrete techniques and tooling. One that I'm really excited for is ways you can use Git more effectively. There are a couple of people that we interviewed who mentioned just how important it was to their workflow. And we've got some really interesting notes on that. There are also some really interesting ideas around areas in our codebase where bugs tend to accrue that are more likely to be, particularly around the nebulous concept of boundaries. This was a conversation that we had with one of our interviewees where we had our initial list of questions, and then we ended up completely throwing them away and going down this long, random tangent about boundaries; it was so good. We decided to dedicate a whole article to it because there are really interesting things around that. +STEPH: All of that sounds really exciting. I love that you mentioned Git because even in the conversation that we've been having right now, that didn't cross my mind, but yeah, that is such an incredible debugging tool. So I'm really looking forward to that and also the one that's going to dive into boundaries. All of that sounds really exciting. +JOËL: One thing that I think is really fun with digging into Git is that generally, when we think of debugging, we're trying to find where the bug is. But oftentimes, the real question we need to answer is not just where is the bug it's when is the bug? So not just debugging through space but debugging through time, and Git is the tool to do that. +STEPH: Oh, that made me laugh but also made me depressed: when is the bug? [laughs] +JOËL: And I feel like this is going to turn into a cheesy sci-fi TV series. +CHRIS: It doesn't need to be cheesy. +JOËL: True. +CHRIS: Yeah, it does. [laughter] +STEPH: For it to be good, I think it has to be a little cheesy. Sci-fi bugs coming to your application next summer. +CHRIS: Everybody hop in the Tardis. We're going to find the bug. +JOËL: I feel like there's some variation of that line that shows up in a lot of time travel series. Like not where is X, but when is X? +STEPH: On that delightful note, thank you, Joël, so much for coming onto The Bike Shed and chatting with Chris and I about debugging. For everyone that would like to follow along for the Debugging Series, where can they find those articles? +JOËL: So you can go to the thoughtbot blog. There is a tag we created specifically for that, Debugging Series 2021. And I'm sure that you'll link to that. All the articles are also going to be linked from the first article of the series, and I'm sure that will be included in the notes as well. +STEPH: Perfect. And where can people follow your work? +CHRIS: People can follow me on Twitter @joelquen, J-O-E-L-Q-U-E-N. It's not the hockey coach, although I can neither confirm nor deny that the two are the same person. We've never seen them in the same room together. +STEPH: I didn't know you were a hockey coach in your spare time. Oh wait, this is the part that you can't confirm, right? +JOËL: [laughs] Well, that would be letting the secret out. +STEPH: All right. We will try to maintain your secret identity or whichever one that is. +CHRIS: It's a really terrible secret identity if it's actually the same name. Joël, you really should have put more effort into this, coach Q. +JOËL: [laughs] +STEPH: Coach Q. I'm going to start calling you Coach Q. That's wonderful. Well, with your permission. +JOËL: That's the real nickname. For those who don't know, Joël Quenneville is or formerly was the coach of the Chicago Blackhawks NHL hockey team, one of the best coaches ever in the National Hockey League. And a couple of years ago, I got to give a talk in Chicago, a conference talk. And everybody asked me, "Ooh, any connection to the coach?" +STEPH: To which you replied? +JOËL: Oh, I had a whole slide about the conspiracy that we may or may not be the same person. +STEPH: That's really fun. Well, thank you again so much for coming on our show, Coach, and walking us through the wonderful Debugging Series. The show notes for this episode can be found at bikeshed.fm. +CHRIS: This episode was produced and edited by Mandy Moore. +STEPH: If you enjoy listening, one really easy way to support the show is to leave us a quick rating or a review on iTunes as it helps other people find the show. +CHRIS: If you have feedback for this or any of our other episodes, you can reach us at @ _bikeshed on Twitter. And I'm @christoomey. +STEPH: I'm @SViccari. +JOËL: And I'm @joelquen +CHRIS: Or you can email us at hosts@bikeshed.fm. +STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. +All: Bye. + + debugging, debugging series 2021 + + On this week's episode, Steph and Chris are joined by fellow thoughtbotter, Joël Quenneville, to discuss all things debugging. Joël is helping publish a weekly debugging blog series and in this conversation they discuss how the series got started, technology agnostic debugging strategies, writing less bug-prone software, and speculate if Joël moonlights as a hockey coach.

+ + + +

Transcript:

+ +

STEPH: All right. And then who will be editing this episode will be Mandy. So as we run into blunders, which we never do, but if we do, then we can talk to Mandy and ask her to edit things for us. So I will try very hard to do that because I will likely still talk to Thom. [chuckles]

+ +

CHRIS: Hello, Mandy. It is a pleasure to meet you. In the last recording that will be going through you, I was referring to you indirectly as our next producer. But now that we know your name, I'm so excited to have you on the team and to know who is on the other side of these, hopefully not too nonsensical recordings. So pleasure to meet you.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey Chris, today is an extra special day as we have a guest today. Joining us is Joël Quenneville, a thoughtbot developer extraordinaire and a previous Bike Shed guest. Welcome, Joël!

+ +

JOËL: Hi.

+ +

CHRIS: It's a pleasure to have you.

+ +

JOËL: It's good to be on the show.

+ +

STEPH: So, Joël, you and I are on the same client project. And during the past few weeks, we have encountered some very challenging bugs. In fact, if I look back at my developer journal, the last five or so of my entries begin with a very cheesy mystery title that's like the case of the missing data or Harry Potter and the chamber of errors. But in addition to spending your time bug hunting with me on this project, I understand that you and other thoughtboters, Jesse Bailey and Louis Antonopoulos, have been publishing weekly blog posts specifically about debugging.

+ +

JOËL: Yes, that's correct. This has been a project that we've been doing for a little while. We spent about three months doing research, conducting a bunch of interviews, and gathering a lot of material on debugging. And then, starting in April and through the middle of the summer, we are publishing an article every week on the topic of debugging and exploring different aspects of it.

+ +

STEPH: I'm really curious; what prompted y'all to start talking about debugging? I'm really excited to talk about the specific topics that are included in the series. And then also you mentioned all the research. I'd love to know how you went about that research. But before we go there, what prompted this conversation and then led to the creation of the series?

+ +

JOËL: Within thoughtbot, we spend a lot of time trying to improve ourselves, improve the broader community as well. And there was a conversation that got started about how we could get better at debugging. It's a thing that, as developers, we do all the time, and it's not something that's often taught explicitly. Many of us our experience with debugging has been very much just learning on the job and picking it up by osmosis and trial and error. And when you're more junior, a lot of that is just random stuff and changing random lines of code and maybe copying something from the internet and hoping things go well. And as you build experience, you tend to start becoming a little bit more methodical because you've seen what works and what doesn't. And so we wondered within thoughtbot, we have all these different people who've come up with their own experience. Can we meld that together and share the summary of all thoughtbot debugging knowledge combined and help everybody level up? Initially, we were wondering could this be just an internal workshop or something where we get together and exchange on the different ways that we've learned or different techniques that each of us uses? But then this evolved into a project that we wanted to share not just within thoughtbot but with the wider world. And so its final form, or at least its current form, has been a blog post series that's going to run over the course of three to four months.

+ +

STEPH: I appreciate how you've taken the opportunity to take all of this knowledge and then turn it outward-facing, so it's available to the public as well. And it really wasn't until you were talking about the series and then I started reading the weekly blog posts that are being published how little I read about concrete strategies around debugging. I think you said it very well earlier in terms of it as something that you pick up on the job, and you learn different strategies as you go. It's really hard to know exactly how to go about debugging unless you've had experience with that type of bug before.

+ +

CHRIS: I've been also reading the blog posts as they come out. And I'm similarly very grateful for both the general theme of thoughtbot of hey, let's take this thing and actually make it a shared resource for the world. But specific to debugging, it really is this interesting intersection of practical steps that you can take but also almost an art form. There's like, oh, I use Pry, and I put a debugger statement here, and that's a mechanical approach that we have. But then there's also the more general how do I think about code, and how do I build a model in my head and compare that to the thing that's running on my screen? And that is really so much more something that you learn in passing, or at least it typically is. And this idea of trying to be a little more purposeful and share more of that with the world is something that I absolutely love because it is both the harder aspects of the job but also probably one of the more common. I'm spending a lot of time being like, why isn't that working the way that I thought it would? I don't know, maybe 90% of my time as a developer, maybe I'm a bad developer, but it's so much of the time that I spend. And so any amount that I can get better at this or learn from others, I'm super open to that. So thank you for producing this and for sharing all the secrets.

+ +

JOËL: I liked your example of saying you drop in and you drop Pry to put a debugger at a particular location. And I think that maybe that's something that most people are familiar with and might use. But even something like that sounds like a fairly simple, basic concept. I think someone with a lot of experience, if you're pairing with them, you might ask, "Why did you put the Pry here and not there?" And that might make the difference between spending all day versus spending half an hour to find the bug. And that's, I think, a lot of where the experience comes in and where being a little bit more structured, having a strategy can really make the difference in being efficient. Because oftentimes, you're using the same tools and doing roughly the same techniques, but one can be totally flailing and doing random stuff, hoping you'll get lucky with a solution. And the other one is very methodically working towards finding the problem.

+ +

CHRIS: I love that framing of the question, but I also love the idea of you ask that to someone, and they're like, "Huh? I don't actually know. But now that I think about it…" and then they sort of discover the answer. But it's very much they're operating from intuition and just like, well, obviously I put the debugger right before the line that I think has this going on. But that's not necessarily something that's top of mind. So when you ask the question, you almost help them to formalize it. So yeah, there's gold in those hills.

+ +

JOËL: Absolutely. Definitely. I think gaining self-awareness about why you do what you do is always such a rich exercise, at least in my experience.

+ +

STEPH: There's an interesting comparison here where people will ask me how to do something in Vim. And I'm like, oh, let me do it first because I need the muscle memory for it, and then I can tell you how to do it. And I feel like debugging is often the same way where I'm like, well, let me hear about the problem, and then I can work through it with you, but I can't necessarily tell you off the top of my head all the different strategies that I would apply. So I really liked the idea of becoming more self-aware as to how you would approach that so then you can provide those tips to someone else.

+ +

You mentioned earlier about the research for creating the series, and I'd love to hear more about that. Because I imagine there's so much that you could talk about in terms of debugging but then still wanting it to be helpful to people that are working in different technologies. So how did that research go? What did that look like?

+ +

JOËL: Initially, this was focused on experience within thoughtbot. So we focused a lot on more internal research. We had a survey where people just shared their debugging thoughts, tips, and tricks. And then, we also set up a bunch of interviews with multiple thoughtboters across varying levels of experience to get their thoughts on debugging, and that was incredibly rich. So we did, I think, 10 or 12 interviews within the company. We captured all of that and then synthesized the output of those interviews, the survey with all of the random tips and tricks, existing thoughtbot blog content. And then, we also pulled some external resources that we had found as well as some podcasts, some other blog posts elsewhere. And we have tried to mix all of that together to come up with 10 or 12 high-level topics that we thought were particularly valuable to talk about and then turn those into blog posts.

+ +

STEPH: That's really awesome. I love how you took that approach of interviewing different people to take that instinctual knowledge that we have around how we're debugging but then helping people put that into words and then capturing that and then sharing it. What type of questions did you ask people to help people walk through what are their debugging strategies?

+ +

JOËL: That was actually pretty fun because we came up with a list of questions ahead of time, not that it was a strict list to be adhered to, but we wanted to have something to have a little bit of commonality between the interviews and then let them go where they will. Most of them we opened up with just asking people, "What does the word debugging make you feel?" What is your personal connection to debugging?" And I expected most people to be like, "Oh, dread or frustration," And that was not the case. Most people said, "Actually, I like debugging. It's a challenge. It's a puzzle. It appeals to the analytical side of me." One person mentioned that it's like the code equivalent of an escape room and that escape rooms are one of their favorite things, and so they actually really enjoyed it. Where a lot of the frustration comes in is when you have deadlines, and this bug is unexpected and therefore is taking time away from things you really need to be doing now or yesterday. And so the timeline can cause pressure, but the bug itself most people seem to enjoy finding the bug.

+ +

STEPH: I love so much that you just used the comparison of an escape room because I was just chatting with someone recently about how my week has been going, and I'm like, I am in an escape room. That is my job this week is to figure out how to get out of this or to understand what is happening in the system. So that's really funny. That's also very encouraging to hear that so many people have a positive association with debugging. But I certainly understand that it's more the deadline, the timeline that is then putting pressure on us to solve something quickly, but we actually enjoy the hunt is what it sounds like.

+ +

CHRIS: And in my experience, when it goes well, it can be really fun. But then there are those days where not just under deadline pressure but just sort of I lost a day to blah. I couldn't figure out what was going on. And especially when it turns out to be something relatively simple, that feeling is somewhat crushing. But when there's this like, oh no, things are not working the way I expect it, and then I'm able to dig in, read a bunch of Stack Overflow, put a bunch of debug or put statements and crack that, that is a fantastic feeling. And there is the optimum flow level of where it's just at the edge of your knowledge and skill set, and it doesn't take too long, but it's not too easy. Because, like you said, the thrill of the hunt is there. So there is a sweet spot, I think, and there are ways that it can go wrong on either side. But I definitely resonate with the idea that a medium-scale bug that I'm able to tackle that's a good day, actually. I feel good at the end of that day.

+ +

STEPH: There's a delightful blog post by Chelsea Troy where they share a graph that talks about the time spent debugging versus the probability of a one-line fix. And so the more hours that you've invested into fixing a bug -- Joël, I think I found this particular blog post thanks to the Debugging Series. It's like two in one of those posts. And so the more hours that you sink in finding a bug, the more likely that it's going to be just a one-line fix. And those are the ones that feel the most painful to me. It's something that is small and comes down to an incorrect assumption about the system. And those are the ones that feel good that I solved it, but I didn't really enjoy the hunt for that one. There's a specific time window in which I'm enjoying myself, which then just becomes stressful and frustrating.

+ +

JOËL: Sometimes, it almost feels like the number of lines of code for the solution needs to match the amount of effort it took to find the bug. And so if I spend a day searching for the bug, it's frustrating that it's only one line and that the solution took 30 seconds, but the search took eight hours.

+ +

CHRIS: I think my measure would be the length of the commit message associated. I'm fine with a one-line change as long as there is a couple of paragraphs of explanation of the journey that I went on and not just self-serving like, hey everyone, listen, because this was rough for me. But the look at all the things I learned, let me capture that knowledge here because there's actually a bunch that this one code line change encapsulates. But it's actually looking at the history of HTTP and the way that the different headers are handled in different browsers and, for many reasons, this one-line change. But if it's a one-line change and the commit message is like, "Oh, typo, sorry," then I feel bad. That's a bad day for me. [chuckles]

+ +

JOËL: This reminds me of the project, Steph, that you and I are on where I've definitely had several bugs that I've gone through to fix where the commit message is definitely quite a bit longer than the actual diff. And the commit message includes ASCII diagrams showing the structure of certain database tables and why I had to change a particular query. And it's weird. And you would never understand why without realizing the schema. So yeah, I definitely feel you there, Chris, where sometimes you go on a journey, and it's very important to record that for the next person.

+ +

STEPH: Yeah, your commit messages have been phenomenal. And I love all the diagrams that you've included because that has helped me have context for what exactly you understand about the system and what appears to be wrong with the system. That has been wonderful. Speaking along those lines, as we were just talking about how it can feel very ephemeral in terms of the strategies that we use for debugging, I'm really curious what strategies do y'all use for debugging? Do you have particular tools that you use? I know Joël, you are a fan of diagrams. Is there a particular tool that you use for that?

+ +

JOËL: There's a variety of tools that I'll use. Recently I've been using Monodraw, which is a tool for macOS that allows you to make diagrams that can be exported as text using various ASCII characters, which means that you can then draw an entity-relationship diagram of your database and include that in a commit message where it needs to be text. You can also export it as an image. But the fact that I can use it as text in a commit message has made it particularly valuable recently. So that's my latest go-to diagramming tool.

+ +

STEPH: That's really nice. I haven't used that, but I've been seeing you use it so extensively that I've added it to my list of things to check out very soon. Are there any other particular strategies that you use, since we're on the topic of concrete strategies, for debugging and how you approach debugging?

+ +

JOËL: I am a big fan of binary search, which sounds like a fancy computer science term. But I think from a very practical standpoint; it's just a process of elimination. Sometimes finding where the bug is, is harder than where it's not. And so can I eliminate roughly half of this file or this project or whatever and know that it's not a concern and then keep repeating that until I have a pretty small surface area to actually find the bug itself. And this can be as simple as just commenting out lines of code. And so, like, I'm going to comment out roughly half the lines in this method and see can I still reproduce the bug? If so, then I know it's in the ones that haven't been commented repeat, repeat until I find the bug. And because you remove so much code every time that you have, it takes relatively few steps until you find a very narrow area in which the bug likely is.

+ +

CHRIS: I love that. Binary search is definitely one of my favorite approaches. And I think that was a very welcoming and friendly introduction to the topic for anyone that might not be familiar. But it really is such a simple and yet effective tool for narrowing down the scope. Because when you look at an entire application, you're like, ah, something's wrong, and you start from the outside, that's overwhelming. But if you can start to narrow it down, especially, like you said, in this more methodical, purposeful approach, that is really wonderful. I think one of the tactics that I have been reaching for more and more is using minimal reproduction cases. So rather than actually working in the context of the full application -- This is especially true if I'm working on, say, a JavaScript app or Svelte is the most recent example. Svelte has a REPL on the svelte.dev website. And I find myself more and more reaching for that and just trying to very minimally reproduce code that just isolates that bug. And then I try and tease away the pieces, but now I'm left with this minimal reproduction there in an executable format, and that ends up being really useful. The same sort of thing if I'm on the Ruby side, I might actually do in a Spec just because that's a really nice way to harness execution and be like, I want to do these things. Here's the setup. And it's one of the reasons we love Specs, but I find it's actually a really great tool for setting up some data, executing the app in a certain way, and then testing it. And I find particularly with RSpec and Rails; I feel like I have good control over getting the system into a certain shape. Other applications I find that's a little more difficult, so other techniques may be necessary. But yeah, that's definitely one of the things that I've been leaning on more and more is minimal reproduction so that I can really narrow down the scope of what I'm looking at.

+ +

JOËL: I like that example, Chris. And that actually is a variant of probably one of my favorite approaches, which is reasoning by analogy. So you have a hard problem, and you can't figure out a way to solve it. So you find a similar easy problem, find the solution to that, and then try to backport the solution to your hard problem. Oftentimes, the easy problem is just a simplified version of your hard problem, such as stripping out all the unnecessary detail, then you can backport that. But sometimes, it's just something in a different domain that you understand more easily, and then you can take that solution and backport it. And I had a magical experience a while back. For those of you who know me, I'm a big fan of the Elm language. And I spend a lot of time in their Slack just helping out people. And someone ran into a situation with random generators, which are a concept in that language that can generate random values. And they're trying to combine a bunch of them and having really weird bugs. And I tried a bunch of different techniques to figure out what was going on, and I couldn't figure it out. But the thing that I did figure out is that random generators in this particular dimension we were trying to understand work very similarly to functions, which are a much more simple concept. And the moment I realized, oh, in this very particular way, generators and functions are the same, all of a sudden, that unlocked in my mind; wait, I can reason by analogy here because I know how to solve this problem with functions. I don't know how to solve it with random generators. So I went and solved it by saying, "I don't know how to compose a bunch of generators. I do know how to compose a bunch of functions, figure that out and then take that solution and bring it back to generators." And I followed that process through, and it worked, and it was amazing. I came in to work the next day, and I was really excited about this. And I was talking with some colleagues, and everyone's like, "You should write about that." So there's a blog post from a year or two ago where I walked through my whole process and all the different debugging strategies I used, including reasoning by analogy to solve what was a pretty tricky bug.

+ +

STEPH: I love how the typical response from talking to a thoughtboter about going through something like that is often, "Oh, you should write about it."

+ +

CHRIS: And I'll help you edit it, not just "Please go write that." And Joël, you live that to the extreme. You have been an absolutely prolific author on the thoughtbot blog. And you bring some of the images and things like that that you're talking about. You really, I think, provide such a great example of paying knowledge forward and sharing better. So if anyone wants to learn about blogging on the internet, just go follow Joël's, work for a while, and you'll learn some great things.

+ +

STEPH: Yeah, that is so true. I love how much you publish, and I'm a big fan of everything that you write. One of the debugging strategies that was mentioned in the blog post that really rang true for me was talking about identifying assumptions because that is one that I typically fall into where I will read about a problem, and then I will say, "Okay, I understand exactly what problem they're running into." And once I start troubleshooting, if I'm unable to reproduce -- Because I follow a similar strategy, Chris, that you just mentioned where I will try to replicate the issue either if I'm doing it locally or ideally if I'm writing a test, so then I can write a test that fails and then I can then make that test pass. But if I'm unable to reproduce, then I'm forced to go back and say, "Okay, am I making an incorrect assumption about what's being reported?" And that has been so helpful. Like, there are just little things where I realize I'm on autopilot for where it's like, the user downloads a report, and I'm like, oh well, they mean this report. And then I find out that they actually meant something else. Also, assumptions in the codebase, and that's one that you and I, Joël, have run into so much with this past week in regards to assumptions in the codebase as to how many associations a record can have. Is it one? Is it many? It has many, but it really only wants one record. So assumptions from the perspective of when someone is reporting an issue and then also assumptions in the codebase. For the first one, I have found that, especially when I'm new to a team when someone reports an issue, I often like to hop on a quick call with them and say, "Hey, are you able to reproduce this for me? And so I can watch you, and I can understand your workflow." And I have found that typically speeds me up drastically.

+ +

JOËL: One of the things that was mentioned in the article on listing assumptions which is maybe a bold claim, but it opens by saying that all bugs are a form of miscommunication. And this might be human-to-human communication where you didn't understand the requirements or what was trying to be done. But code is also communication between us and computers. We want computers to do a thing. And if the computer doesn't do what we're telling it to, it's not doing that just to show us who's boss; it's because we didn't communicate correctly what we wanted. And so yeah, trying to better understand ourselves what we mean and our assumptions is a key part of debugging. And that's the thing that came up over and over and over in all the interviews was one, build self-awareness about the assumptions you have, and there's a bunch of different techniques for doing that. And then once you have self-awareness of what your assumptions are, never trust anything, validate, validate, validate, because yeah, you're often wrong.

+ +

CHRIS: There's an interesting parallel to that in my mind of we often end up with these systems, and it's behaving in an odd way. And so we have to build this mental map of okay; what are all of the different states and workflows that can get us into those various states? And having now debugged a handful of times in my life, I'm trying as much as possible to flip the script and go with an ounce of prevention is worth a pound of cure. And this is why one of the most common things that I say in a pull request is, "Hey, can we make that null false on that new database column? Hey, can we change this type constraint so that instead of it being a Boolean and then another attribute, it's actually a three-state enum?" and et cetera, et cetera. How can I collapse the states down so that when I'm in debugging mode, I actually can take some things as givens? Still, maybe validate from time to time, but the more I can learn to trust a type system or the database or things like that, things that are a little more trustworthy than I am or other humans, I'm increasingly loving that. And there's obviously a gentle balance there, but that's something that I've been leaning into more and more. And I think it's directly informed by the years of my life that have gone into debugging at this point. Is that accurate? That seems like a high estimate, but it's a lot. It's a bunch of weeks at a minimum.

+ +

JOËL: I felt that really strongly. I'm kind of disappointed as an industry that we default things to be nullable so often. I wish database columns were non-nullable by default, and you had to opt in to make them nullable. I wish GraphQL didn't make columns nullable by default. And I think oftentimes, when you're working in a dynamic language, you don't care about that distinction. And so you just let it go by. And let's say with GraphQL, again, I hang out a lot in the Elm Slack channel, and I spend a lot of time helping people integrate Elm in GraphQL. And when you get a schema and try to load that into Elm because it has a type system, it will read your schema and wrap everything in maybes because it's as though this field is optional, this thing is optional, this thing is optional. And then people come to the Slack, and they're like, "Why is there maybe everywhere with deeply nested -- This is a terrible mess in Elm. What went wrong?" And then I have to tell them, "It's not the Elm tool that's wrong. If your schema has this implicitly, the default thing was to make it null." And so it just looks normal, and you want to put all those exclamation marks everywhere. And a lot of time people don't believe me. And I have to say, "No, no, you're right. It really is the schema that's the problem. Please go put all these exclamation points." I'll give an example of a non-null schema, and then they try it, and they're like, "Wow, this makes such a difference."

+ +

STEPH: Joël, the defender of Elm.

+ +

JOËL: [laughs]

+ +

STEPH: And I am with you, and it is interesting. And I've been there myself, too, where there's a fear of over-restriction in terms of if I make this not null and something blows up, then that feels like a bad outcome. And so I've seen a number of projects where we let nil get through so easily because then we just always handle the nil versus having that restriction earlier and making that decision. It's like we're pushing off that decision of like, well, that'd be nil for now, and then we'll figure it out later. Versus starting with that decision upfront and saying, "No, let's go ahead and make that decision now. What do we do if this is nil?" And I agree that it would be wonderful if we had more restriction upfront and then we loosened the requirements as we find out that we need to versus starting with the loose requirements because walking that backwards is incredibly difficult.

+ +

JOËL: Yes, having to backfill nullable columns that we don't have values for in the database because now we want to restrict it, but for years we didn't collect that value. And so what do we do now? That becomes really tricky.

+ +

STEPH: Chris, a minute ago, you were mentioning prevention, which I love so much because then we can avoid a number of these debugging discussions, although this is also delightful. But there's an opposite end of that spectrum that has taken me a while to gain comfort with, and it is when you don't know enough about the bug, and you can't reproduce, and then you essentially have to let it go. And there are other ways that you can debug, but you can't fix it in the moment. So let's say that you have an error or something that happens every once in a while, but you can't actually find the reasons that it's happening or if you have data that's getting created in a certain state, but you don't know what in your application is creating that state. So instead of spending what could be hours and days triaging how your system got in that state is instead perhaps adding some logging around it to say, "Hey, this is the moment where we are causing this to happen," or maybe it's adding a constraint, so something fails very loudly whenever the system tries to put data in a particular state. And in those cases, it took me a while to become comfortable with the idea that I can't solve this today. I can't solve it now, but I can take steps to then know how this is happening. So then, in the future, we can actually prevent this or apply the fix. But initially, that always felt like a really bad outcome for a ticket that's reporting a bug where it's like, hey, I can't fix this today. I don't know exactly what's happening, but I've added some logging, or I've added something that's going to raise when this happens. So when we do get notified of it again, then we can more quickly triage and put the right fix in.

+ +

CHRIS: Yeah. If anything, I feel like there can be a -- Like we were talking about earlier, there's almost an enjoyment to solving a bug where it's a puzzle. It's a thing that may capture our attention, but sometimes, actually, perhaps often, the correct answer is that's actually not the most important thing right now, or the cost is too high to try and solve it given the information that we have. It's affecting a very small number of users. Maybe we can make that experience better. It's not just a generic 500-page, but we turn it into a, "Hey, sorry, you got into a…" like a more explicit error state but defer the actual debugging because there are other things that are slightly more pressing, affecting more users, or again, we just don't have enough information. And I feel like that actually can be a difficult thing to be like, no, but I want to solve the puzzle now. This is a fun puzzle. Please let me solve the puzzle. But sometimes, we don't get to solve the puzzle today.

+ +

JOËL: One of the articles in our series that I'm really excited about takes a look at classical philosophy and various categories of reasoning identified in classical philosophy and how we can apply them to debugging to debug in a more strategic and methodical manner. And one of those categories is inductive reasoning, which is very similar to, say, the scientific method where you gather a lot of information. And then, based off of those cases, you try to come up with a pattern, have a hypothesis for it, test it. And then if you can show that it's actually the case, then you're likely correct. But of course, that depends on having enough test cases for there to actually be a pattern and for it to be statistically significant. And so for some bugs, if there's only one instance of it happening and you just say, oh, somehow a bad value made it from our front end UI into the database, and we don't know how. But it's not happening to every user. Like, there's only one use case, and we can't figure out how that happened. We don't have enough information to build up those test cases to try to find a pattern. And so that's where getting more test cases becomes really important. As Steph mentioned, logging can be really helpful here, raising whatever you need to do. Maybe it's adding a constraint or a validation to say, "Blow up the next time this happens." But once you have enough test cases, then you can start seeing patterns. And that's your inductive reasoning to solve the bug.

+ +

STEPH: Something that we touched on earlier but I don't think I've given enough credit to but is something that I really appreciate is the fact that all of these strategies that are being talked about in each blog post are applicable across technology stacks, across languages. Because you really highlighted a point just a moment ago around how most of the bugs that we're working with are all bespoke. They're all special little bugs in their own special way. And so it's really hard to have a blanket strategy that then applies to each one because they are unique. And the fact that y'all are creating so much content that has general strategies that people can apply when debugging is really impressive to me. So I'm really curious how are y'all doing that?

+ +

JOËL: When we came up with a series idea, we laid down a few principles for how we wanted the outcome to be. And one thing that came up pretty early was it's important for this to be language agnostic. We don't want to just teach like, here are some very specific Ruby tools you can use, which that's a very helpful article, but that's not really the kind of information that we were looking for. So we were trying to find what are some higher-level techniques and strategies that are usable throughout your career? And then secondly, we wanted to focus on finding bugs rather than how do you solve them or how do you prevent them? Chris mentioned a little bit earlier about techniques for preventing bugs from happening in the first place, and we might have a bonus episode or article on how to write bug-resistant code. But the focus of the series is what are some language agnostic ways that we can improve your search to find the root cause of a bug? And a lot of that has just been synthesis, so saying okay, here's a bunch of different things that different people told us. And we were fine with having language-specific examples in the interviews. But how can we then find what's common and what's not? One thing that I think was really interesting was talking how different people gain information about a particular point in code, and debuggers are a pretty common way of doing this. But print line debugging is also a really common way to do that. And every language does this slightly differently. And you can even do this, not just via text, but visually. So if you're writing CSS and you are trying to figure out when a particular rule triggers, you might put a 1-pixel red border around something. And that's CSS' equivalent to print here or console.log in JavaScript or Ruby or some other language.

+ +

So the idea is to see all what different people told us and then see can we extract a general principle out of this? And walking a fine line between we want the theories to have practical advice for people that they can use but also zoom out just a little bit so that we have some of the big picture so that you can make some of these big connections and see some of the patterns that can help you apply in different situations that you run into for debugging without necessarily getting head in the clouds, you know, what is debugging? And I'm sure there's a really fascinating philosophy article, not the classical philosophy article I mentioned; that one's actually good. But you can philosophize about debugging in a way that's too abstract to be useful. So we want just a touch of the philosophy to keep it big picture while also giving very concrete, useful tips and techniques that are language agnostic that folks can use.

+ +

STEPH: That's fabulous how y'all are able to separate that thought process away from the direct, specific action that someone takes. So when someone is dropping in that console.log statement or that print statement, it's like, okay, but what thought process took you there to the point that then you were trying that action? I really like that. There's one other trick that was mentioned in one of the articles that I also really enjoy. It's the analogy of taking a ball of yarn with you, so you're always tracking where you've been. And that is the other thing that I do heavily when I'm debugging is that I always have a note-taking application that's open because I always document what I've looked at, what were my findings. And then I think through what do I want to look at next? And sometimes I'll write down a list of three or four different questions of it could be this, it could be that. And then, I will prioritize those based on what's the quickest to look at? What can I replicate the fastest? What can I remove from this list? Back to earlier, when you were talking about the process of elimination and then walk through each one. So that way, when I do find the bug, I also have those steps that I can look back. So in case, someone has a question about it, in case they're like, "Well, what about this?" I can say, "Well, yes, I also checked that," or there just may be extra helpful tidbits that fall out of that process. At least they prevent me from checking something twice.

+ +

JOËL: I've been pairing with you, Steph, on several bugs recently, and I've really appreciated the notes that you keep. They're very thorough, and that's something that I've tried to bring into my own practice by seeing you do that.

+ +

CHRIS: That's something I've been iterating on in my own workflow of late is having a directory of notes associated with each project. And as I'm working on each, it's almost not even just bugs at this point but any new feature anything that I'm exploring. Because often, initial exploration of integrating with a library feels a little bit like debugging, sort of poking at the edges and what's true and what's not and writing up little reproducible steps of okay, run this code, then this code, then this code. And I've now just taken to keeping those forever because it turns out like, oh, I know I integrated that, but what was the step? I feel like there was something I did. And being able to go back and have that artifact now is so useful. And it's actually something that I've only really gotten in the habit of over, I'd say, the last two years, but that archive of notes is now very useful even to this day.

+ +

STEPH: So I think we've covered a number or hinted at a number of the wonderful topics that are included in the series, including some of the different ways that we can identify our assumptions or ways that we can get unstuck. That was one of my favorite ones on all the different ways to get yourself unstuck when you are in the throes of debugging. There's also the idea of when you encounter a bug that if you can't fix it right away, but then some of the steps that you can take to then be able to fix it in the future. I would love to know, if you don't mind sharing some spoilers, as to some upcoming topics that will be in the unpublished but soon-to-be-published blog posts.

+ +

JOËL: Yeah. So for all of The Bike Shed listeners who want the inside scoop, there are a few that I'm really interested in. So we opened the series by talking about mindset issues, how to approach a bug, how to think about assumptions, and now we're moving into some more concrete techniques and tooling. One that I'm really excited for is ways you can use Git more effectively. There are a couple of people that we interviewed who mentioned just how important it was to their workflow. And we've got some really interesting notes on that. There are also some really interesting ideas around areas in our codebase where bugs tend to accrue that are more likely to be, particularly around the nebulous concept of boundaries. This was a conversation that we had with one of our interviewees where we had our initial list of questions, and then we ended up completely throwing them away and going down this long, random tangent about boundaries; it was so good. We decided to dedicate a whole article to it because there are really interesting things around that.

+ +

STEPH: All of that sounds really exciting. I love that you mentioned Git because even in the conversation that we've been having right now, that didn't cross my mind, but yeah, that is such an incredible debugging tool. So I'm really looking forward to that and also the one that's going to dive into boundaries. All of that sounds really exciting.

+ +

JOËL: One thing that I think is really fun with digging into Git is that generally, when we think of debugging, we're trying to find where the bug is. But oftentimes, the real question we need to answer is not just where is the bug it's when is the bug? So not just debugging through space but debugging through time, and Git is the tool to do that.

+ +

STEPH: Oh, that made me laugh but also made me depressed: when is the bug? [laughs]

+ +

JOËL: And I feel like this is going to turn into a cheesy sci-fi TV series.

+ +

CHRIS: It doesn't need to be cheesy.

+ +

JOËL: True.

+ +

CHRIS: Yeah, it does. [laughter]

+ +

STEPH: For it to be good, I think it has to be a little cheesy. Sci-fi bugs coming to your application next summer.

+ +

CHRIS: Everybody hop in the Tardis. We're going to find the bug.

+ +

JOËL: I feel like there's some variation of that line that shows up in a lot of time travel series. Like not where is X, but when is X?

+ +

STEPH: On that delightful note, thank you, Joël, so much for coming onto The Bike Shed and chatting with Chris and I about debugging. For everyone that would like to follow along for the Debugging Series, where can they find those articles?

+ +

JOËL: So you can go to the thoughtbot blog. There is a tag we created specifically for that, Debugging Series 2021. And I'm sure that you'll link to that. All the articles are also going to be linked from the first article of the series, and I'm sure that will be included in the notes as well.

+ +

STEPH: Perfect. And where can people follow your work?

+ +

CHRIS: People can follow me on Twitter @joelquen, J-O-E-L-Q-U-E-N. It's not the hockey coach, although I can neither confirm nor deny that the two are the same person. We've never seen them in the same room together.

+ +

STEPH: I didn't know you were a hockey coach in your spare time. Oh wait, this is the part that you can't confirm, right?

+ +

JOËL: [laughs] Well, that would be letting the secret out.

+ +

STEPH: All right. We will try to maintain your secret identity or whichever one that is.

+ +

CHRIS: It's a really terrible secret identity if it's actually the same name. Joël, you really should have put more effort into this, coach Q.

+ +

JOËL: [laughs]

+ +

STEPH: Coach Q. I'm going to start calling you Coach Q. That's wonderful. Well, with your permission.

+ +

JOËL: That's the real nickname. For those who don't know, Joël Quenneville is or formerly was the coach of the Chicago Blackhawks NHL hockey team, one of the best coaches ever in the National Hockey League. And a couple of years ago, I got to give a talk in Chicago, a conference talk. And everybody asked me, "Ooh, any connection to the coach?"

+ +

STEPH: To which you replied?

+ +

JOËL: Oh, I had a whole slide about the conspiracy that we may or may not be the same person.

+ +

STEPH: That's really fun. Well, thank you again so much for coming on our show, Coach, and walking us through the wonderful Debugging Series. The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This episode was produced and edited by Mandy Moore.

+ +

STEPH: If you enjoy listening, one really easy way to support the show is to leave us a quick rating or a review on iTunes as it helps other people find the show.

+ +

CHRIS: If you have feedback for this or any of our other episodes, you can reach us at @ _bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: I'm @SViccari.

+ +

JOËL: And I'm @joelquen

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris are joined by fellow thoughtbotter, Joël Quenneville, to discuss all things debugging. Joël is helping publish a weekly debugging blog series and in this conversation they discuss how the series got started, technology agnostic debugging strategies, writing less bug-prone software, and speculate if Joël moonlights as a hockey coach.

+ + + +

Transcript:

+ +

STEPH: All right. And then who will be editing this episode will be Mandy. So as we run into blunders, which we never do, but if we do, then we can talk to Mandy and ask her to edit things for us. So I will try very hard to do that because I will likely still talk to Thom. [chuckles]

+ +

CHRIS: Hello, Mandy. It is a pleasure to meet you. In the last recording that will be going through you, I was referring to you indirectly as our next producer. But now that we know your name, I'm so excited to have you on the team and to know who is on the other side of these, hopefully not too nonsensical recordings. So pleasure to meet you.

+ +

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

+ +

CHRIS: And I'm Chris Toomey.

+ +

STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey Chris, today is an extra special day as we have a guest today. Joining us is Joël Quenneville, a thoughtbot developer extraordinaire and a previous Bike Shed guest. Welcome, Joël!

+ +

JOËL: Hi.

+ +

CHRIS: It's a pleasure to have you.

+ +

JOËL: It's good to be on the show.

+ +

STEPH: So, Joël, you and I are on the same client project. And during the past few weeks, we have encountered some very challenging bugs. In fact, if I look back at my developer journal, the last five or so of my entries begin with a very cheesy mystery title that's like the case of the missing data or Harry Potter and the chamber of errors. But in addition to spending your time bug hunting with me on this project, I understand that you and other thoughtboters, Jesse Bailey and Louis Antonopoulos, have been publishing weekly blog posts specifically about debugging.

+ +

JOËL: Yes, that's correct. This has been a project that we've been doing for a little while. We spent about three months doing research, conducting a bunch of interviews, and gathering a lot of material on debugging. And then, starting in April and through the middle of the summer, we are publishing an article every week on the topic of debugging and exploring different aspects of it.

+ +

STEPH: I'm really curious; what prompted y'all to start talking about debugging? I'm really excited to talk about the specific topics that are included in the series. And then also you mentioned all the research. I'd love to know how you went about that research. But before we go there, what prompted this conversation and then led to the creation of the series?

+ +

JOËL: Within thoughtbot, we spend a lot of time trying to improve ourselves, improve the broader community as well. And there was a conversation that got started about how we could get better at debugging. It's a thing that, as developers, we do all the time, and it's not something that's often taught explicitly. Many of us our experience with debugging has been very much just learning on the job and picking it up by osmosis and trial and error. And when you're more junior, a lot of that is just random stuff and changing random lines of code and maybe copying something from the internet and hoping things go well. And as you build experience, you tend to start becoming a little bit more methodical because you've seen what works and what doesn't. And so we wondered within thoughtbot, we have all these different people who've come up with their own experience. Can we meld that together and share the summary of all thoughtbot debugging knowledge combined and help everybody level up? Initially, we were wondering could this be just an internal workshop or something where we get together and exchange on the different ways that we've learned or different techniques that each of us uses? But then this evolved into a project that we wanted to share not just within thoughtbot but with the wider world. And so its final form, or at least its current form, has been a blog post series that's going to run over the course of three to four months.

+ +

STEPH: I appreciate how you've taken the opportunity to take all of this knowledge and then turn it outward-facing, so it's available to the public as well. And it really wasn't until you were talking about the series and then I started reading the weekly blog posts that are being published how little I read about concrete strategies around debugging. I think you said it very well earlier in terms of it as something that you pick up on the job, and you learn different strategies as you go. It's really hard to know exactly how to go about debugging unless you've had experience with that type of bug before.

+ +

CHRIS: I've been also reading the blog posts as they come out. And I'm similarly very grateful for both the general theme of thoughtbot of hey, let's take this thing and actually make it a shared resource for the world. But specific to debugging, it really is this interesting intersection of practical steps that you can take but also almost an art form. There's like, oh, I use Pry, and I put a debugger statement here, and that's a mechanical approach that we have. But then there's also the more general how do I think about code, and how do I build a model in my head and compare that to the thing that's running on my screen? And that is really so much more something that you learn in passing, or at least it typically is. And this idea of trying to be a little more purposeful and share more of that with the world is something that I absolutely love because it is both the harder aspects of the job but also probably one of the more common. I'm spending a lot of time being like, why isn't that working the way that I thought it would? I don't know, maybe 90% of my time as a developer, maybe I'm a bad developer, but it's so much of the time that I spend. And so any amount that I can get better at this or learn from others, I'm super open to that. So thank you for producing this and for sharing all the secrets.

+ +

JOËL: I liked your example of saying you drop in and you drop Pry to put a debugger at a particular location. And I think that maybe that's something that most people are familiar with and might use. But even something like that sounds like a fairly simple, basic concept. I think someone with a lot of experience, if you're pairing with them, you might ask, "Why did you put the Pry here and not there?" And that might make the difference between spending all day versus spending half an hour to find the bug. And that's, I think, a lot of where the experience comes in and where being a little bit more structured, having a strategy can really make the difference in being efficient. Because oftentimes, you're using the same tools and doing roughly the same techniques, but one can be totally flailing and doing random stuff, hoping you'll get lucky with a solution. And the other one is very methodically working towards finding the problem.

+ +

CHRIS: I love that framing of the question, but I also love the idea of you ask that to someone, and they're like, "Huh? I don't actually know. But now that I think about it…" and then they sort of discover the answer. But it's very much they're operating from intuition and just like, well, obviously I put the debugger right before the line that I think has this going on. But that's not necessarily something that's top of mind. So when you ask the question, you almost help them to formalize it. So yeah, there's gold in those hills.

+ +

JOËL: Absolutely. Definitely. I think gaining self-awareness about why you do what you do is always such a rich exercise, at least in my experience.

+ +

STEPH: There's an interesting comparison here where people will ask me how to do something in Vim. And I'm like, oh, let me do it first because I need the muscle memory for it, and then I can tell you how to do it. And I feel like debugging is often the same way where I'm like, well, let me hear about the problem, and then I can work through it with you, but I can't necessarily tell you off the top of my head all the different strategies that I would apply. So I really liked the idea of becoming more self-aware as to how you would approach that so then you can provide those tips to someone else.

+ +

You mentioned earlier about the research for creating the series, and I'd love to hear more about that. Because I imagine there's so much that you could talk about in terms of debugging but then still wanting it to be helpful to people that are working in different technologies. So how did that research go? What did that look like?

+ +

JOËL: Initially, this was focused on experience within thoughtbot. So we focused a lot on more internal research. We had a survey where people just shared their debugging thoughts, tips, and tricks. And then, we also set up a bunch of interviews with multiple thoughtboters across varying levels of experience to get their thoughts on debugging, and that was incredibly rich. So we did, I think, 10 or 12 interviews within the company. We captured all of that and then synthesized the output of those interviews, the survey with all of the random tips and tricks, existing thoughtbot blog content. And then, we also pulled some external resources that we had found as well as some podcasts, some other blog posts elsewhere. And we have tried to mix all of that together to come up with 10 or 12 high-level topics that we thought were particularly valuable to talk about and then turn those into blog posts.

+ +

STEPH: That's really awesome. I love how you took that approach of interviewing different people to take that instinctual knowledge that we have around how we're debugging but then helping people put that into words and then capturing that and then sharing it. What type of questions did you ask people to help people walk through what are their debugging strategies?

+ +

JOËL: That was actually pretty fun because we came up with a list of questions ahead of time, not that it was a strict list to be adhered to, but we wanted to have something to have a little bit of commonality between the interviews and then let them go where they will. Most of them we opened up with just asking people, "What does the word debugging make you feel?" What is your personal connection to debugging?" And I expected most people to be like, "Oh, dread or frustration," And that was not the case. Most people said, "Actually, I like debugging. It's a challenge. It's a puzzle. It appeals to the analytical side of me." One person mentioned that it's like the code equivalent of an escape room and that escape rooms are one of their favorite things, and so they actually really enjoyed it. Where a lot of the frustration comes in is when you have deadlines, and this bug is unexpected and therefore is taking time away from things you really need to be doing now or yesterday. And so the timeline can cause pressure, but the bug itself most people seem to enjoy finding the bug.

+ +

STEPH: I love so much that you just used the comparison of an escape room because I was just chatting with someone recently about how my week has been going, and I'm like, I am in an escape room. That is my job this week is to figure out how to get out of this or to understand what is happening in the system. So that's really funny. That's also very encouraging to hear that so many people have a positive association with debugging. But I certainly understand that it's more the deadline, the timeline that is then putting pressure on us to solve something quickly, but we actually enjoy the hunt is what it sounds like.

+ +

CHRIS: And in my experience, when it goes well, it can be really fun. But then there are those days where not just under deadline pressure but just sort of I lost a day to blah. I couldn't figure out what was going on. And especially when it turns out to be something relatively simple, that feeling is somewhat crushing. But when there's this like, oh no, things are not working the way I expect it, and then I'm able to dig in, read a bunch of Stack Overflow, put a bunch of debug or put statements and crack that, that is a fantastic feeling. And there is the optimum flow level of where it's just at the edge of your knowledge and skill set, and it doesn't take too long, but it's not too easy. Because, like you said, the thrill of the hunt is there. So there is a sweet spot, I think, and there are ways that it can go wrong on either side. But I definitely resonate with the idea that a medium-scale bug that I'm able to tackle that's a good day, actually. I feel good at the end of that day.

+ +

STEPH: There's a delightful blog post by Chelsea Troy where they share a graph that talks about the time spent debugging versus the probability of a one-line fix. And so the more hours that you've invested into fixing a bug -- Joël, I think I found this particular blog post thanks to the Debugging Series. It's like two in one of those posts. And so the more hours that you sink in finding a bug, the more likely that it's going to be just a one-line fix. And those are the ones that feel the most painful to me. It's something that is small and comes down to an incorrect assumption about the system. And those are the ones that feel good that I solved it, but I didn't really enjoy the hunt for that one. There's a specific time window in which I'm enjoying myself, which then just becomes stressful and frustrating.

+ +

JOËL: Sometimes, it almost feels like the number of lines of code for the solution needs to match the amount of effort it took to find the bug. And so if I spend a day searching for the bug, it's frustrating that it's only one line and that the solution took 30 seconds, but the search took eight hours.

+ +

CHRIS: I think my measure would be the length of the commit message associated. I'm fine with a one-line change as long as there is a couple of paragraphs of explanation of the journey that I went on and not just self-serving like, hey everyone, listen, because this was rough for me. But the look at all the things I learned, let me capture that knowledge here because there's actually a bunch that this one code line change encapsulates. But it's actually looking at the history of HTTP and the way that the different headers are handled in different browsers and, for many reasons, this one-line change. But if it's a one-line change and the commit message is like, "Oh, typo, sorry," then I feel bad. That's a bad day for me. [chuckles]

+ +

JOËL: This reminds me of the project, Steph, that you and I are on where I've definitely had several bugs that I've gone through to fix where the commit message is definitely quite a bit longer than the actual diff. And the commit message includes ASCII diagrams showing the structure of certain database tables and why I had to change a particular query. And it's weird. And you would never understand why without realizing the schema. So yeah, I definitely feel you there, Chris, where sometimes you go on a journey, and it's very important to record that for the next person.

+ +

STEPH: Yeah, your commit messages have been phenomenal. And I love all the diagrams that you've included because that has helped me have context for what exactly you understand about the system and what appears to be wrong with the system. That has been wonderful. Speaking along those lines, as we were just talking about how it can feel very ephemeral in terms of the strategies that we use for debugging, I'm really curious what strategies do y'all use for debugging? Do you have particular tools that you use? I know Joël, you are a fan of diagrams. Is there a particular tool that you use for that?

+ +

JOËL: There's a variety of tools that I'll use. Recently I've been using Monodraw, which is a tool for macOS that allows you to make diagrams that can be exported as text using various ASCII characters, which means that you can then draw an entity-relationship diagram of your database and include that in a commit message where it needs to be text. You can also export it as an image. But the fact that I can use it as text in a commit message has made it particularly valuable recently. So that's my latest go-to diagramming tool.

+ +

STEPH: That's really nice. I haven't used that, but I've been seeing you use it so extensively that I've added it to my list of things to check out very soon. Are there any other particular strategies that you use, since we're on the topic of concrete strategies, for debugging and how you approach debugging?

+ +

JOËL: I am a big fan of binary search, which sounds like a fancy computer science term. But I think from a very practical standpoint; it's just a process of elimination. Sometimes finding where the bug is, is harder than where it's not. And so can I eliminate roughly half of this file or this project or whatever and know that it's not a concern and then keep repeating that until I have a pretty small surface area to actually find the bug itself. And this can be as simple as just commenting out lines of code. And so, like, I'm going to comment out roughly half the lines in this method and see can I still reproduce the bug? If so, then I know it's in the ones that haven't been commented repeat, repeat until I find the bug. And because you remove so much code every time that you have, it takes relatively few steps until you find a very narrow area in which the bug likely is.

+ +

CHRIS: I love that. Binary search is definitely one of my favorite approaches. And I think that was a very welcoming and friendly introduction to the topic for anyone that might not be familiar. But it really is such a simple and yet effective tool for narrowing down the scope. Because when you look at an entire application, you're like, ah, something's wrong, and you start from the outside, that's overwhelming. But if you can start to narrow it down, especially, like you said, in this more methodical, purposeful approach, that is really wonderful. I think one of the tactics that I have been reaching for more and more is using minimal reproduction cases. So rather than actually working in the context of the full application -- This is especially true if I'm working on, say, a JavaScript app or Svelte is the most recent example. Svelte has a REPL on the svelte.dev website. And I find myself more and more reaching for that and just trying to very minimally reproduce code that just isolates that bug. And then I try and tease away the pieces, but now I'm left with this minimal reproduction there in an executable format, and that ends up being really useful. The same sort of thing if I'm on the Ruby side, I might actually do in a Spec just because that's a really nice way to harness execution and be like, I want to do these things. Here's the setup. And it's one of the reasons we love Specs, but I find it's actually a really great tool for setting up some data, executing the app in a certain way, and then testing it. And I find particularly with RSpec and Rails; I feel like I have good control over getting the system into a certain shape. Other applications I find that's a little more difficult, so other techniques may be necessary. But yeah, that's definitely one of the things that I've been leaning on more and more is minimal reproduction so that I can really narrow down the scope of what I'm looking at.

+ +

JOËL: I like that example, Chris. And that actually is a variant of probably one of my favorite approaches, which is reasoning by analogy. So you have a hard problem, and you can't figure out a way to solve it. So you find a similar easy problem, find the solution to that, and then try to backport the solution to your hard problem. Oftentimes, the easy problem is just a simplified version of your hard problem, such as stripping out all the unnecessary detail, then you can backport that. But sometimes, it's just something in a different domain that you understand more easily, and then you can take that solution and backport it. And I had a magical experience a while back. For those of you who know me, I'm a big fan of the Elm language. And I spend a lot of time in their Slack just helping out people. And someone ran into a situation with random generators, which are a concept in that language that can generate random values. And they're trying to combine a bunch of them and having really weird bugs. And I tried a bunch of different techniques to figure out what was going on, and I couldn't figure it out. But the thing that I did figure out is that random generators in this particular dimension we were trying to understand work very similarly to functions, which are a much more simple concept. And the moment I realized, oh, in this very particular way, generators and functions are the same, all of a sudden, that unlocked in my mind; wait, I can reason by analogy here because I know how to solve this problem with functions. I don't know how to solve it with random generators. So I went and solved it by saying, "I don't know how to compose a bunch of generators. I do know how to compose a bunch of functions, figure that out and then take that solution and bring it back to generators." And I followed that process through, and it worked, and it was amazing. I came in to work the next day, and I was really excited about this. And I was talking with some colleagues, and everyone's like, "You should write about that." So there's a blog post from a year or two ago where I walked through my whole process and all the different debugging strategies I used, including reasoning by analogy to solve what was a pretty tricky bug.

+ +

STEPH: I love how the typical response from talking to a thoughtboter about going through something like that is often, "Oh, you should write about it."

+ +

CHRIS: And I'll help you edit it, not just "Please go write that." And Joël, you live that to the extreme. You have been an absolutely prolific author on the thoughtbot blog. And you bring some of the images and things like that that you're talking about. You really, I think, provide such a great example of paying knowledge forward and sharing better. So if anyone wants to learn about blogging on the internet, just go follow Joël's, work for a while, and you'll learn some great things.

+ +

STEPH: Yeah, that is so true. I love how much you publish, and I'm a big fan of everything that you write. One of the debugging strategies that was mentioned in the blog post that really rang true for me was talking about identifying assumptions because that is one that I typically fall into where I will read about a problem, and then I will say, "Okay, I understand exactly what problem they're running into." And once I start troubleshooting, if I'm unable to reproduce -- Because I follow a similar strategy, Chris, that you just mentioned where I will try to replicate the issue either if I'm doing it locally or ideally if I'm writing a test, so then I can write a test that fails and then I can then make that test pass. But if I'm unable to reproduce, then I'm forced to go back and say, "Okay, am I making an incorrect assumption about what's being reported?" And that has been so helpful. Like, there are just little things where I realize I'm on autopilot for where it's like, the user downloads a report, and I'm like, oh well, they mean this report. And then I find out that they actually meant something else. Also, assumptions in the codebase, and that's one that you and I, Joël, have run into so much with this past week in regards to assumptions in the codebase as to how many associations a record can have. Is it one? Is it many? It has many, but it really only wants one record. So assumptions from the perspective of when someone is reporting an issue and then also assumptions in the codebase. For the first one, I have found that, especially when I'm new to a team when someone reports an issue, I often like to hop on a quick call with them and say, "Hey, are you able to reproduce this for me? And so I can watch you, and I can understand your workflow." And I have found that typically speeds me up drastically.

+ +

JOËL: One of the things that was mentioned in the article on listing assumptions which is maybe a bold claim, but it opens by saying that all bugs are a form of miscommunication. And this might be human-to-human communication where you didn't understand the requirements or what was trying to be done. But code is also communication between us and computers. We want computers to do a thing. And if the computer doesn't do what we're telling it to, it's not doing that just to show us who's boss; it's because we didn't communicate correctly what we wanted. And so yeah, trying to better understand ourselves what we mean and our assumptions is a key part of debugging. And that's the thing that came up over and over and over in all the interviews was one, build self-awareness about the assumptions you have, and there's a bunch of different techniques for doing that. And then once you have self-awareness of what your assumptions are, never trust anything, validate, validate, validate, because yeah, you're often wrong.

+ +

CHRIS: There's an interesting parallel to that in my mind of we often end up with these systems, and it's behaving in an odd way. And so we have to build this mental map of okay; what are all of the different states and workflows that can get us into those various states? And having now debugged a handful of times in my life, I'm trying as much as possible to flip the script and go with an ounce of prevention is worth a pound of cure. And this is why one of the most common things that I say in a pull request is, "Hey, can we make that null false on that new database column? Hey, can we change this type constraint so that instead of it being a Boolean and then another attribute, it's actually a three-state enum?" and et cetera, et cetera. How can I collapse the states down so that when I'm in debugging mode, I actually can take some things as givens? Still, maybe validate from time to time, but the more I can learn to trust a type system or the database or things like that, things that are a little more trustworthy than I am or other humans, I'm increasingly loving that. And there's obviously a gentle balance there, but that's something that I've been leaning into more and more. And I think it's directly informed by the years of my life that have gone into debugging at this point. Is that accurate? That seems like a high estimate, but it's a lot. It's a bunch of weeks at a minimum.

+ +

JOËL: I felt that really strongly. I'm kind of disappointed as an industry that we default things to be nullable so often. I wish database columns were non-nullable by default, and you had to opt in to make them nullable. I wish GraphQL didn't make columns nullable by default. And I think oftentimes, when you're working in a dynamic language, you don't care about that distinction. And so you just let it go by. And let's say with GraphQL, again, I hang out a lot in the Elm Slack channel, and I spend a lot of time helping people integrate Elm in GraphQL. And when you get a schema and try to load that into Elm because it has a type system, it will read your schema and wrap everything in maybes because it's as though this field is optional, this thing is optional, this thing is optional. And then people come to the Slack, and they're like, "Why is there maybe everywhere with deeply nested -- This is a terrible mess in Elm. What went wrong?" And then I have to tell them, "It's not the Elm tool that's wrong. If your schema has this implicitly, the default thing was to make it null." And so it just looks normal, and you want to put all those exclamation marks everywhere. And a lot of time people don't believe me. And I have to say, "No, no, you're right. It really is the schema that's the problem. Please go put all these exclamation points." I'll give an example of a non-null schema, and then they try it, and they're like, "Wow, this makes such a difference."

+ +

STEPH: Joël, the defender of Elm.

+ +

JOËL: [laughs]

+ +

STEPH: And I am with you, and it is interesting. And I've been there myself, too, where there's a fear of over-restriction in terms of if I make this not null and something blows up, then that feels like a bad outcome. And so I've seen a number of projects where we let nil get through so easily because then we just always handle the nil versus having that restriction earlier and making that decision. It's like we're pushing off that decision of like, well, that'd be nil for now, and then we'll figure it out later. Versus starting with that decision upfront and saying, "No, let's go ahead and make that decision now. What do we do if this is nil?" And I agree that it would be wonderful if we had more restriction upfront and then we loosened the requirements as we find out that we need to versus starting with the loose requirements because walking that backwards is incredibly difficult.

+ +

JOËL: Yes, having to backfill nullable columns that we don't have values for in the database because now we want to restrict it, but for years we didn't collect that value. And so what do we do now? That becomes really tricky.

+ +

STEPH: Chris, a minute ago, you were mentioning prevention, which I love so much because then we can avoid a number of these debugging discussions, although this is also delightful. But there's an opposite end of that spectrum that has taken me a while to gain comfort with, and it is when you don't know enough about the bug, and you can't reproduce, and then you essentially have to let it go. And there are other ways that you can debug, but you can't fix it in the moment. So let's say that you have an error or something that happens every once in a while, but you can't actually find the reasons that it's happening or if you have data that's getting created in a certain state, but you don't know what in your application is creating that state. So instead of spending what could be hours and days triaging how your system got in that state is instead perhaps adding some logging around it to say, "Hey, this is the moment where we are causing this to happen," or maybe it's adding a constraint, so something fails very loudly whenever the system tries to put data in a particular state. And in those cases, it took me a while to become comfortable with the idea that I can't solve this today. I can't solve it now, but I can take steps to then know how this is happening. So then, in the future, we can actually prevent this or apply the fix. But initially, that always felt like a really bad outcome for a ticket that's reporting a bug where it's like, hey, I can't fix this today. I don't know exactly what's happening, but I've added some logging, or I've added something that's going to raise when this happens. So when we do get notified of it again, then we can more quickly triage and put the right fix in.

+ +

CHRIS: Yeah. If anything, I feel like there can be a -- Like we were talking about earlier, there's almost an enjoyment to solving a bug where it's a puzzle. It's a thing that may capture our attention, but sometimes, actually, perhaps often, the correct answer is that's actually not the most important thing right now, or the cost is too high to try and solve it given the information that we have. It's affecting a very small number of users. Maybe we can make that experience better. It's not just a generic 500-page, but we turn it into a, "Hey, sorry, you got into a…" like a more explicit error state but defer the actual debugging because there are other things that are slightly more pressing, affecting more users, or again, we just don't have enough information. And I feel like that actually can be a difficult thing to be like, no, but I want to solve the puzzle now. This is a fun puzzle. Please let me solve the puzzle. But sometimes, we don't get to solve the puzzle today.

+ +

JOËL: One of the articles in our series that I'm really excited about takes a look at classical philosophy and various categories of reasoning identified in classical philosophy and how we can apply them to debugging to debug in a more strategic and methodical manner. And one of those categories is inductive reasoning, which is very similar to, say, the scientific method where you gather a lot of information. And then, based off of those cases, you try to come up with a pattern, have a hypothesis for it, test it. And then if you can show that it's actually the case, then you're likely correct. But of course, that depends on having enough test cases for there to actually be a pattern and for it to be statistically significant. And so for some bugs, if there's only one instance of it happening and you just say, oh, somehow a bad value made it from our front end UI into the database, and we don't know how. But it's not happening to every user. Like, there's only one use case, and we can't figure out how that happened. We don't have enough information to build up those test cases to try to find a pattern. And so that's where getting more test cases becomes really important. As Steph mentioned, logging can be really helpful here, raising whatever you need to do. Maybe it's adding a constraint or a validation to say, "Blow up the next time this happens." But once you have enough test cases, then you can start seeing patterns. And that's your inductive reasoning to solve the bug.

+ +

STEPH: Something that we touched on earlier but I don't think I've given enough credit to but is something that I really appreciate is the fact that all of these strategies that are being talked about in each blog post are applicable across technology stacks, across languages. Because you really highlighted a point just a moment ago around how most of the bugs that we're working with are all bespoke. They're all special little bugs in their own special way. And so it's really hard to have a blanket strategy that then applies to each one because they are unique. And the fact that y'all are creating so much content that has general strategies that people can apply when debugging is really impressive to me. So I'm really curious how are y'all doing that?

+ +

JOËL: When we came up with a series idea, we laid down a few principles for how we wanted the outcome to be. And one thing that came up pretty early was it's important for this to be language agnostic. We don't want to just teach like, here are some very specific Ruby tools you can use, which that's a very helpful article, but that's not really the kind of information that we were looking for. So we were trying to find what are some higher-level techniques and strategies that are usable throughout your career? And then secondly, we wanted to focus on finding bugs rather than how do you solve them or how do you prevent them? Chris mentioned a little bit earlier about techniques for preventing bugs from happening in the first place, and we might have a bonus episode or article on how to write bug-resistant code. But the focus of the series is what are some language agnostic ways that we can improve your search to find the root cause of a bug? And a lot of that has just been synthesis, so saying okay, here's a bunch of different things that different people told us. And we were fine with having language-specific examples in the interviews. But how can we then find what's common and what's not? One thing that I think was really interesting was talking how different people gain information about a particular point in code, and debuggers are a pretty common way of doing this. But print line debugging is also a really common way to do that. And every language does this slightly differently. And you can even do this, not just via text, but visually. So if you're writing CSS and you are trying to figure out when a particular rule triggers, you might put a 1-pixel red border around something. And that's CSS' equivalent to print here or console.log in JavaScript or Ruby or some other language.

+ +

So the idea is to see all what different people told us and then see can we extract a general principle out of this? And walking a fine line between we want the theories to have practical advice for people that they can use but also zoom out just a little bit so that we have some of the big picture so that you can make some of these big connections and see some of the patterns that can help you apply in different situations that you run into for debugging without necessarily getting head in the clouds, you know, what is debugging? And I'm sure there's a really fascinating philosophy article, not the classical philosophy article I mentioned; that one's actually good. But you can philosophize about debugging in a way that's too abstract to be useful. So we want just a touch of the philosophy to keep it big picture while also giving very concrete, useful tips and techniques that are language agnostic that folks can use.

+ +

STEPH: That's fabulous how y'all are able to separate that thought process away from the direct, specific action that someone takes. So when someone is dropping in that console.log statement or that print statement, it's like, okay, but what thought process took you there to the point that then you were trying that action? I really like that. There's one other trick that was mentioned in one of the articles that I also really enjoy. It's the analogy of taking a ball of yarn with you, so you're always tracking where you've been. And that is the other thing that I do heavily when I'm debugging is that I always have a note-taking application that's open because I always document what I've looked at, what were my findings. And then I think through what do I want to look at next? And sometimes I'll write down a list of three or four different questions of it could be this, it could be that. And then, I will prioritize those based on what's the quickest to look at? What can I replicate the fastest? What can I remove from this list? Back to earlier, when you were talking about the process of elimination and then walk through each one. So that way, when I do find the bug, I also have those steps that I can look back. So in case, someone has a question about it, in case they're like, "Well, what about this?" I can say, "Well, yes, I also checked that," or there just may be extra helpful tidbits that fall out of that process. At least they prevent me from checking something twice.

+ +

JOËL: I've been pairing with you, Steph, on several bugs recently, and I've really appreciated the notes that you keep. They're very thorough, and that's something that I've tried to bring into my own practice by seeing you do that.

+ +

CHRIS: That's something I've been iterating on in my own workflow of late is having a directory of notes associated with each project. And as I'm working on each, it's almost not even just bugs at this point but any new feature anything that I'm exploring. Because often, initial exploration of integrating with a library feels a little bit like debugging, sort of poking at the edges and what's true and what's not and writing up little reproducible steps of okay, run this code, then this code, then this code. And I've now just taken to keeping those forever because it turns out like, oh, I know I integrated that, but what was the step? I feel like there was something I did. And being able to go back and have that artifact now is so useful. And it's actually something that I've only really gotten in the habit of over, I'd say, the last two years, but that archive of notes is now very useful even to this day.

+ +

STEPH: So I think we've covered a number or hinted at a number of the wonderful topics that are included in the series, including some of the different ways that we can identify our assumptions or ways that we can get unstuck. That was one of my favorite ones on all the different ways to get yourself unstuck when you are in the throes of debugging. There's also the idea of when you encounter a bug that if you can't fix it right away, but then some of the steps that you can take to then be able to fix it in the future. I would love to know, if you don't mind sharing some spoilers, as to some upcoming topics that will be in the unpublished but soon-to-be-published blog posts.

+ +

JOËL: Yeah. So for all of The Bike Shed listeners who want the inside scoop, there are a few that I'm really interested in. So we opened the series by talking about mindset issues, how to approach a bug, how to think about assumptions, and now we're moving into some more concrete techniques and tooling. One that I'm really excited for is ways you can use Git more effectively. There are a couple of people that we interviewed who mentioned just how important it was to their workflow. And we've got some really interesting notes on that. There are also some really interesting ideas around areas in our codebase where bugs tend to accrue that are more likely to be, particularly around the nebulous concept of boundaries. This was a conversation that we had with one of our interviewees where we had our initial list of questions, and then we ended up completely throwing them away and going down this long, random tangent about boundaries; it was so good. We decided to dedicate a whole article to it because there are really interesting things around that.

+ +

STEPH: All of that sounds really exciting. I love that you mentioned Git because even in the conversation that we've been having right now, that didn't cross my mind, but yeah, that is such an incredible debugging tool. So I'm really looking forward to that and also the one that's going to dive into boundaries. All of that sounds really exciting.

+ +

JOËL: One thing that I think is really fun with digging into Git is that generally, when we think of debugging, we're trying to find where the bug is. But oftentimes, the real question we need to answer is not just where is the bug it's when is the bug? So not just debugging through space but debugging through time, and Git is the tool to do that.

+ +

STEPH: Oh, that made me laugh but also made me depressed: when is the bug? [laughs]

+ +

JOËL: And I feel like this is going to turn into a cheesy sci-fi TV series.

+ +

CHRIS: It doesn't need to be cheesy.

+ +

JOËL: True.

+ +

CHRIS: Yeah, it does. [laughter]

+ +

STEPH: For it to be good, I think it has to be a little cheesy. Sci-fi bugs coming to your application next summer.

+ +

CHRIS: Everybody hop in the Tardis. We're going to find the bug.

+ +

JOËL: I feel like there's some variation of that line that shows up in a lot of time travel series. Like not where is X, but when is X?

+ +

STEPH: On that delightful note, thank you, Joël, so much for coming onto The Bike Shed and chatting with Chris and I about debugging. For everyone that would like to follow along for the Debugging Series, where can they find those articles?

+ +

JOËL: So you can go to the thoughtbot blog. There is a tag we created specifically for that, Debugging Series 2021. And I'm sure that you'll link to that. All the articles are also going to be linked from the first article of the series, and I'm sure that will be included in the notes as well.

+ +

STEPH: Perfect. And where can people follow your work?

+ +

CHRIS: People can follow me on Twitter @joelquen, J-O-E-L-Q-U-E-N. It's not the hockey coach, although I can neither confirm nor deny that the two are the same person. We've never seen them in the same room together.

+ +

STEPH: I didn't know you were a hockey coach in your spare time. Oh wait, this is the part that you can't confirm, right?

+ +

JOËL: [laughs] Well, that would be letting the secret out.

+ +

STEPH: All right. We will try to maintain your secret identity or whichever one that is.

+ +

CHRIS: It's a really terrible secret identity if it's actually the same name. Joël, you really should have put more effort into this, coach Q.

+ +

JOËL: [laughs]

+ +

STEPH: Coach Q. I'm going to start calling you Coach Q. That's wonderful. Well, with your permission.

+ +

JOËL: That's the real nickname. For those who don't know, Joël Quenneville is or formerly was the coach of the Chicago Blackhawks NHL hockey team, one of the best coaches ever in the National Hockey League. And a couple of years ago, I got to give a talk in Chicago, a conference talk. And everybody asked me, "Ooh, any connection to the coach?"

+ +

STEPH: To which you replied?

+ +

JOËL: Oh, I had a whole slide about the conspiracy that we may or may not be the same person.

+ +

STEPH: That's really fun. Well, thank you again so much for coming on our show, Coach, and walking us through the wonderful Debugging Series. The show notes for this episode can be found at bikeshed.fm.

+ +

CHRIS: This episode was produced and edited by Mandy Moore.

+ +

STEPH: If you enjoy listening, one really easy way to support the show is to leave us a quick rating or a review on iTunes as it helps other people find the show.

+ +

CHRIS: If you have feedback for this or any of our other episodes, you can reach us at @ _bikeshed on Twitter. And I'm @christoomey.

+ +

STEPH: I'm @SViccari.

+ +

JOËL: And I'm @joelquen

+ +

CHRIS: Or you can email us at hosts@bikeshed.fm.

+ +

STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

All: Bye.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+tE4xUWXu + + ]]> + + Chris Toomey + Steph Viccari + + + 291: All Things Inertia.js with Jonathan Reinink + https://bikeshed.thoughtbot.com/291 + b9cf47d9-38b3-4c40-bb27-4dad2003c41b + Tue, 04 May 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + This week, Steph's taking a quick break, but while she's off, Chris is joined by a special guest - Jonathan Reinink. Jonathan is the creator of Inertia.js. Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers, and listeners of the show will certainly have heard Chris rave about it on previous episodes. + 50:25 + no + + + This week Steph's taking a quick break, but while she's off, Chris is joined by a special guest - Jonathan Reinink. Jonathan is the creator of Inertia.js. Inertia.js (https://inertiajs.com/) lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers, and listeners of the show will certainly have heard Chris rave about it on previous episodes. +Chris and Jonathan dig into what makes Inertia unique as compared to frameworks like Phoenix LiveView, Laravel Livewire, and Rails' Hotwire & Turbo. They also discuss how Inertia embraces the URL, the unique "protocol" nature of Inertia, and how to consider Inertia alongside native mobile applications. Throughout the conversation, Jonathan's consistent philosophy of wanting to build robust, performant, and delightful applications shines through. +Jonathan Reinink on twitter (https://twitter.com/reinink) +Inertia.js (https://inertiajs.com/) +Eloquent Performance Patterns (https://eloquent-course.reinink.ca/) +TailwindCSS (https://tailwindcss.com/) +Church Social (https://churchsocial.com/) +Jonathan on Full Stack Radio (https://twitter.com/adamwathan/status/1192152495407222784?s=21) +Foundational blog post: Server-side apps with client-side rendering (https://reinink.ca/articles/server-side-apps-with-client-side-rendering) +Laravel Livewire (https://laravel-livewire.com/) +Alpine.js (https://github.com/alpinejs/alpine) +Phoenix LiveView (https://github.com/phoenixframework/phoenix_live_view) +Hotwire Turbo (https://turbo.hotwire.dev/) +The Inertia Protocol (https://inertiajs.com/the-protocol) +Transcript: +CHRIS TOOMEY: I am seeing what I believe to be the relevant things. +JONATHAN REINIK: Let's dance. +CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week, Steph is taking a quick break, but while she's away, I'm joined by a special guest, Jonathan Reinik. Jonathan Reinik is the creator of Inertia.js. And listeners of the show will know that that is increasingly one of my favorite frameworks and, frankly, just ways to build applications on the internet. Jonathan is also the creator of the Eloquent Performance Patterns course, which teaches the Eloquent ORM, which is the ORM in Laravel but really digs into deep performance and database things, so really covering that back end as well. Jonathan also collaborated on the development of Tailwind CSS, a utility-first CSS framework which again is something that I have spoken of in very high terms on this podcast. And lastly, Jonathan currently runs his own SaaS business called Church Social. So really, Jonathan is a bit of a quadruple threat covering back end and front end design and entrepreneurship. So pretty much everything you want to see. And frankly, I've been so impressed by the breadth and the depth of Jonathan's work and just the deep way that he is thinking about building applications. So I am absolutely thrilled to have him on the show today. So without further ado, Jonathan, thank you so much for joining me. +JONATHAN: Thanks so much, Chris. That was a very kind introduction, and yeah, it's awesome to be on The Bike Shed. I've been a long-time listener, and as I've said to you, I really appreciate the support that you've given to my work over the years. So yeah, it's awesome to be here. +CHRIS: That's interesting. We're measuring it in years now, but it's a very sincere thing for me. I think with Inertia, you've built something that is both very unique and a special approach to how we build things, but it's also built from very familiar pieces and allows us to reuse the deep amounts of knowledge that we have in the Rails community or the Laravel community. But actually backing up just a little bit, because we're going to dive deep on Inertia.js today, for folks that are not as familiar or have only heard me mention it in passing, there's a wonderful episode of Full Stack Radio where Jonathan and Adam Wathan talked about Inertia.js, and I think gave a very good foundational summary. So we'll link to that in the show notes in case anyone wants to dig in a little bit more. Likewise, Jonathan has a really fantastic blog post called Server-side Apps With Client-side Rendering, which, as far as I can tell, is the manifesto that began this whole journey for you. And I really love that you have done so much of the work in public, and people can see the history of how this idea has evolved and really crystallized into what now is a very production-ready framework in sort of the way to build things. But I would love to hear right now just for anyone who is not as familiar and also just to hear how you summarize it at this point in time. What does your introductory elevator pitch for Inertia.js sound like in April 2021? +JONATHAN: That's a great question. So it's hard to answer this without unpacking a lot of different things. And you mentioned the podcast with Adam; I think that's good because it goes in a lot of the technical detail of how Inertia works and why I created it. But the elevator pitch these days for when I talk to someone about it, it's generally I explain it as a way of building modern web apps. And in particular, when I say modern, I mean web apps that have a lot of JavaScript, so frameworks like Vue or React or Svelte, so applications that are built using those tools. And the key thing that Inertia offers is for you to develop these modern applications without having to first build an API sort of the way historically if you ever wanted to use one of these modern web stacks like Vue or React or Svelte, you could use them within Laravel or Rails by inserting them into your Vue or into your Blade templates or your ERB templates. But it was difficult if you ever wanted to turn it into a legitimate single-page application. And anytime you would ask that question, if you go out on the internet and say, “Hey, how do I build SPA with, say, Vue and Laravel or React and Rails?” The answer was always, “Well, you need to build an API. You need to build an API.” That was always the missing piece because that's the way that everyone in the Jamstack era that we're in that's the way that everyone's building their applications that are like these heavy client-side applications. +And I totally get the need for those style apps and the place for those style apps. But I really missed this way that you could build an application with Rails or with Laravel where you could just literally spin up a new app, create some routes within your server-side framework, create some controllers, create some views, and have a working application within minutes really. You could have something being displayed on the screen within minutes with these classic monolith applications. And if you wanted to do the same thing, if you wanted to get an app up and running in minutes with Vue or React as your completely client-side SPA scenario, it just wasn't working because as soon as you say, “Well, in order to do that, you're going to need to have a back end Rails or a Lavarel application, and then a client-side Vue or React application. And then you're going to have to create this API that connects the two together.” There's just a lot more work that goes into that. It's not only the work of actually creating the API; I find a lot of the decisions that come along with building an API; it’s like, okay, what does the abstraction look like? Am I going to build it with REST, or am I going to build it as a GraphQL API? And all the decisions that come along with designing and architecting that which again has its place. But there's just something awesome about saying, “Here's a new route. Here's the view that I want to render. And here's the data that I want that view to have,” and just go off and do it, and it's done. +And some people ask me, “Well, with Inertia, if you're not building an API, what happens someday if you need an API?” And they frame it like, well, this is a terrible decision. You should be starting with an API. But for me, the reality is that so many of the web applications that I was building and that I've seen other people building is they had already made the decision not to use an API because they had already made the decision that they wanted to use Laravel as a monolith app that had their controllers and the routes and their views all within that and the same thing with Rails. So if you've made that decision to build a monolith app with Laravel or Rails, you've already made the decision to not build it with an API. I was coming in from the other way. It's like, I just want to build an app the way I've always built in Laravel, and I don't want to have to build this API. Of course, there are times where you do need an API, which I think we're going to talk about maybe a little bit later if I don't ramble on too long, where it does make sense to have an API. But yeah, that's kind of the elevator pitch. +I think maybe to close off that thought is that I really, really enjoy having a tight coupling between my routes and my data layer and my views, which, again, I appreciate that. That probably sounds like blasphemy in modern web development. But for me, I think it's so empowering when you say, “Hey, I have a controller that's given me some data, and I have a view that's rendering the data, and those two know about each other, and those two depend on each other.” You can work so fast because I'm not thinking, okay, well, I have this API endpoint that returns a user, and that has their first name and their last name and their email. But I also need to think about it in the situation in the future where I might need this attribute or that attribute or some other attribute and make sure I have all that figured out ahead of time or at least have a way to add it in later. And all of that thinking that goes into designing an API, I find that that adds a lot of overhead. +And then maybe related to that also is the amount of times that you're rendering a view within your application that needs data from multiple different places. And to me, this is like one of the huge performance benefits that you get with a tool like Inertia is with, say a REST API, GraphQl solves this, but with a REST API, you're often getting too much data for what you actually need for the page, or you're often making more than one HTTP request because you say, “Well, on this particular dashboard, I need some user information. So I have to hit the user endpoint. I need maybe the latest product sales data, so I need to hit that endpoint.” And you’re dealing with these performance issues that you get with a REST API that with Inertia, you don't have that problem because it's just going back to classic Laravel Blade views or Rails and ERB templates. Am I saying that right, ERB template? +CHRIS: Mm-hmm. +JONATHAN: In those situations, you say, “Well, if I need data from three different places, well, I'll just grab data from three different places and send it to the view, and that's fine. And I can do that in the most efficient way and get the data that I need specifically for that view.” So anyway, that's some of the thinking that drove me to build Inertia and some of the things that I was going for. And yeah, it was an evolution. It really came out of me using Turbolinks and really appreciating what Turbolinks gave me but taking it to that next step where it's like Turbolinks, except it's built with the same principles as Turbolinks but built for modern client-side frameworks like Vue and React. +CHRIS: Yeah, that all feels very familiar to me. And in my experience, I've now worked with Inertia on a handful of projects, but in particular, I have just a small personal app that I use to manage different aspects of my life. And it's been my playground for different technologies. And I've migrated it through a bunch of different versions where it used to just be a Rails app. And I was like, oh no, the thing that I need to do to be on the cutting edge is to turn this into -- it's a Rails app on the back end with an API, and then it's a React app. It's separately deployed, but those two talk to each other. And what you were talking about of the deep coupling, I think that coupling exists whether we want it to or not. And so embracing that and revisiting when I eventually migrated that application to use Inertia and the client-side stuff folded back into the core codebase. Now deployments all go out in sync. And that turns out to actually be a really nice thing and a non-trivial thing to solve otherwise. +As a developer of one on this particular project, the amount of complexity that was removed from the app when I switched it over to Inertia was amazing. I got to remove client-side routing. I got to remove client-side state management, which I think I was using Redux at the time. I got to remove some form helpers that I had. I think I might've been using Formik or React Use Former, any of those. But there are so many different little pieces that you ended up cobbling together to make an application. And it was amazing to me as I moved to Inertia, where I was like; actually, I don't need any of those, and routes suddenly are defined in one place in Rails in a familiar way. But things like redirects all work -- It feels just like a Rails app but with the extra abilities that a front-end client-side framework gives you when you want those when you need those. But otherwise, it really does feel like I'm rendering to an ERB template. It just happens to be that that template is rendering on the client-side and is written in React or Svelte or whatever the front-end framework is. But it almost feels like progressive enhancement. I'm borrowing a term, and it's not actually applicable here, but it really feels like that. It's like, oh, it's a Rails app, but I just want to make it a little bit fancier, and Inertia does that in such a fantastic way. +And actually pivoting just a bit, as far as I can tell, there seems to be an explosion of thinking in this space. There are a handful of frameworks, namely Laravel Livewire, which is often paired with Alpine.js. Elixir has Phoenix LiveView, and then Rails has the Hotwire suite, which Turbo and Stimulus are the most pointed considerations. But interestingly, I think all of those frameworks, which I think are trying to provide a very similar experience, tend to keep things on the server-side, so using the Laravel Blade templates or the ERB in Rails. But you've taken the different approach to say, “No, let's embrace this front-end technology where it makes sense.” And again, there are a lot of pieces that can fall in, and I don't need the Redux and the React Router and all of those things but still use that client-side framework to be the rendering engine. And so I'm intrigued if you can talk a little bit more about that and that trade-off because I think it really differentiates Inertia and its approach. I personally found it to be fantastic, but I'd love to hear a little bit more about your thinking on that. +JONATHAN: The thing about modern websites and web apps, in particular, is it doesn't matter how you slice it; we need JavaScript. So if you disagree with me there, then everything I say from this point on will not make sense to you. But I think we can all agree that modern web apps need JavaScript. JavaScript is the programming language of the web of the browser that allows us to do whatever magical things that we want to do. And if you look at tools like Phoenix LiveView, Laravel Livewire, and even the new Turbo stuff from the folks over at Basecamp, they all are embracing JavaScript in the same way. It's just they're framing it in a different way. I would say, especially with Livewire and LiveView, they're almost creating like an abstraction between the server and the way you write things on the server and the client-side. And they're almost hiding the JavaScript, which is really, really cool. I think it's such an interesting thing to try to do where somebody who's not familiar with JavaScript and not familiar with Vue, React, and Svelte can go and do things, write server-side code that gets rendered server-side. And then there's some JavaScript that these libraries insert that allow you to do more interesting things, whatever those things might be, show a drop-down, or drag and drop or validate a form or submit a form without actually submitting it fully to the server but submit it over XHR instead, all these kinds of things. But the point is they're embracing JavaScript just in a different way. And same with Turbo, Turbo gives you a way to write JavaScript for an application that mostly has server-side rendered HTML. +So I think it's important to just recognize that JavaScript is key in all these frameworks. With Inertia, it's the same idea in that Inertia wants to embrace that classic way of building applications using the classic server-side monolith application framework like Laravel or Rails. But the difference is it acknowledges or embraces these existing client-side frameworks that have really grown in popularity. And the three, again, I keep mentioning them, Vue, React, or Svelte. Svelte being an up-and-coming one that's not nearly as popular yet, but it seems to be gaining a lot of steam. +CHRIS: It's on the rise. That’s my long [inaudible 14:46] +JONATHAN: Yes, and people keep saying that. So anyway, Inertia basically said, “Hey, we want to keep building server-side apps. We want to keep building monolith apps similar to these other tools, except what we're going to do is we're going to embrace the fact that there's this really, really amazing tooling that's been developed for the client-side.” And it just doubles down on that. So for me, the reason that I ended up here was because, in my own SaaS application, it was a Laravel application that started with mostly Blade views initially. And then, over the years of building it, which has been many, many years, I've slowly added more and more Vue components within my app. And initially, the way I did it is those Vue components would just be inserted in as regular HTML tags in my server-side rendered templates. And then, when the page renders, those Vue components would boot up and do whatever they need to do. So for me, when I was building Inertia, I had already fallen in love with Vue, in particular, and having all the power of these client-side frameworks. And there is so much there. It's not just Vue, React, and Svelte; it's all the amazing tooling that's available out there that you can add on top of it. +And this is the thing I often tell people that Inertia isn’t -- we say right on the homepage, “Inertia isn't a framework.” And the reason why I say that is because I don't want people to think of Inertia as an alternative to Vue, React, and Svelte. Do you know what is a better way to frame it? It's actually more of an alternative to React Router or Vue Router; that's really more what it is, where you can say, “All my routings are handled server-side,” and that has all kinds of interesting implications. But it's more of a router, and it just so happens to pass along that routing control over to the server. Anyway, so that's really for me what differentiates Inertia from those other tools is because it's really doubled down on these client-side frameworks. +And I think the reason why Inertia has been relatively popular is because people know Vue and people know React. And when it comes to then working with Inertia, it's not some new thing that they have to learn. It's an existing set of tools that they're already super comfortable with. And in so many ways, when you're building an Inertia app, you're kind of building a classic Vue app or a classic React app or a classic Svelte app. It's just there's a bunch of pieces missing. Like you said, it's like a bunch of the client-side state management stuff, which nobody likes anyway, is gone. The other thing that's gone is client-side routing. You don't have this back-end routing is over here now, and client-side routing is over here, and I have two different routing definitions. It's like, no, that's all just server-side now in one place. +The other amazing thing you get is you mentioned redirects and that whole HTTP layer you get just along with Inertia for free because it's just part of your server-side stack. And one key aspect of that is auth. You can just use good old-fashioned nothing is better than session auth. Like, it just works. And, so whatever your typical solution for doing session auth in Laravel or Rails or whatever server-side framework you're using, all this stuff just works. So anyway, coming full circle on your question, the reason why Inertia has gone this way is because I really think that there's a huge amount of value with using these modern frameworks. And we just doubled down on using them. +CHRIS: Yeah, that resonates with my experiences using Inertia and in contrast to the other frameworks. Everyone seems to be trying to get to the same place of providing a mechanism to have more almost app-like functionality but still using the traditional server-side technologies. But I think Inertia has chosen an approach to that that is unique in that category and really has provided a fantastic outcome. I've been very frankly surprised by the fidelity of experience and how app-like I can get something to feel when building with Inertia while still using all the same technologies. And the fact that I can use just traditional server-side auth and redirects and things like that is just so nice, and everything feels right. +There's an experience that I've had on many applications that are, say, a React client-side bundle that gets sent down and then boots up, and then the layout starts to render. And as its data fetching, it gets like a 402 response or something like that in that data fetching. And then it's like, oh no, I need to hard redirect you over here on the client-side to this other page. And there's this junk of semi-filled-out layout, and then suddenly you're on the login page. And again, with Inertia, it looks like a normal server-side rendered app, but it isn't in the ways that really matter to us. And it is one of those things where the more I played with it, the more there's an experience of interacting with Inertia that it surprises me consistently how nice it is to work with it and yet it's so much easier to maintain an application using it. I know I'm raving here, but I am really a big fan of this for everyone listening in the audience. +JONATHAN: [laughs] +CHRIS: And actually to continue on one of the things you were saying there, one of the things that stands out to me in Inertia is the way that it embraces URLs and to a certain degree, that seems like a purposeful thing, but it also seems like it just naturally falls out of how Inertia works because we're no longer using a client-side state management technology, the way to manipulate state is through the URL. If you want to see a different version of the to-do list you're looking at when you click on that link, you change the URL and the state changes in response to that. And so everything is fundamentally kept in sync, but URLs are very much at the center of the architecture, and I really love that so much. I think URLs are often forgotten in client-side frameworks or underserved or underused. And it turns out in my experience as a user and both having served many users, people love to command-click on links. They love to right-click open a new tab. They love to be able to reload and see the same thing on the screen when they reload the page. They love to be able to bookmark. These are all really wonderful things that come out of working on the web. And the fact that Inertia has a pit of success around having URLs and have that be the way that we drive state is just so fantastic. So I'm wondering how much of that was very purposeful on your part versus how much of that fell out of the architecture. +JONATHAN: That is very much something that fell out of the architecture. I say that not to say that I don't value URLs; I absolutely did. That's the way every single one of my Laravel built apps worked. It always starts in the route file. You hit the route file, you define a new route, and it goes from there. So I absolutely think that the URLs are critical. But the fact that it just ended up working out so nicely was, yeah, I'm going to say it was a bit of luck, a bit of coincidence. I find this is what's so interesting when you start pushing on a new way of things; you initially don't really know where it's going to end. It’s like you have some ideas of how the tool can work and where it might go, but I think there's a lot of unknowns that you just figure out after a while. So the thing I said earlier actually about the fact that Inertia in a lot of ways is like a client-side router; it’s, it's a routing library, to put it that way. I had been working on Inertia for a year and a half, and then a buddy of mine, Taylor Otwell, the creator of Laravel, he and I were chatting, and he said to me at one point he's like, “Oh, you know what? Inertia is actually super simple. It's really just a routing library.” And it was like, bam. It was kind of that moment; it’s like, oh yeah, I hadn't thought of it like that at all. But when he said that, it made a ton of sense to me. So it's just this interesting progression the more you work on something, and the more you push on the edges, you learn what's possible and what it even is. +I had this interesting experience, so remembering that Inertia came from Turbolinks. So I had my whole app built with Laravel ton of server-side rendered templates with Blade with view mixed in. And I had the SPA mode by clicking around using Turbolinks. So when I decided to try building Inertia, I removed Turbolinks, and all these requests now happened over XHR but using this preset JSON structure that powers Inertia. I really, in my mind, had this idea that it was only for GET requests, for GET visits; it was just for that. So the initial version of Inertia, there was no Inertia.post or Inertia.put or anything like that. It just wasn't something I even thought was possible. But then I remember, and this is often how it goes; I was out for a hike that day to get away from the computer for a little while and just let your brain drift; I'm sure you can relate to that. I was like, wait a minute; I could totally just support POST, PUT, PATCH, DELETE. And that was such an aha moment for me where I just realized that it was so much more than what I originally thought it was. +And then the whole thing from that I remember it was a bit of like a waterfall effect after that where I remember running home out on that hike and hacked it together, and then it was like, okay, well, if I submit a form using POST, well, okay, I'm on the create user page. And I submit this form using Inertia.post to the user's endpoint. I'm like, well, how do I now end up back at the user index page or whatever page, maybe the user edit page. I’m like, wait a minute, I can just return a redirect back to the user index page, and it's literally going to return an Inertia response from the user index page. And then the way Inertia works is it dynamically swaps the page component client-side. And it was just like, oh, this is way too cool. And this really drives my thinking now that it's become a little bit more clear to me is that it really it's all based on HTTP using headers and normal HTTP stuff like redirects are such a critical piece of the story. But to me, that's super neat that, in a way, it's like a throwback to the fundamentals of the web and the browser and the fact that Inertia can just use those things,,, and it doesn't have to be fancy in a lot of the ways. It can just rely on those existing core pieces of the browser. So, yeah. +CHRIS: It really is interesting to me how it feels like progressive enhancement in that way where you're building on top of these core fundamentals of HTTP and requests and redirects and status codes and things of that nature. Particularly interesting to me was it took me a while, I'm going to be honest, to figure out forms and particularly validation errors in Inertia. And that is entirely my fault. You have absolutely fantastic documentation. I am so impressed by the quality and the density of the documentation that you have that really covers everything. If we're being honest, I hadn't read the page, but I was doing form posting and then the subsequent errors and how you deal with that. I was doing it in a very traditional Rails way which if we're being honest, that is not a fundamental of how HTTP works. Rails just chose an option of oh, if you POST but we don't create the object because there's a validation error, then we're going to stay on the URL of the POST, so the collection route, but we're going to re-render the form in line. And that's a choice that Rails made that is interesting because at that point, if a user reloads the page, then things are weird, and it's not going to reload. They're not going to see the same thing after that reload, or it's going to try to repost or et cetera, et cetera. There's a bunch of edge cases there that sort of fall out. Whereas with Inertia, you end up redirecting back, and there's this interesting handshake of the errors, but from an end-user experience, it is absolutely fantastic where you stay on the form; the URL does not change. Technically, there's a POST and a redirect back under the hood, but Inertia just handles all of that for you. And you end up with sort of in-line validation errors. But you don't clear out any fields, and there are just wonderful things that fall out of it that again took me a while to get there, but it was another one of those oh, wow, this just naturally falls out of the architecture, but it's so nice and such a nice incremental advance on top of frankly, the stuff that I was doing in Rails historically. +JONATHAN: So the way that Laravel works and it's always worked this way is when you make a request using POST or PATCH or DELETE or whatever to an endpoint, and that endpoint does its validation in the event that that validation fails, this is just like built-in standard like Laravel Stock behavior. It automatically redirects you back to the endpoint that you were on. So if you're on the create page or the edit page, it automatically redirects. That's just Laravel behavior. And what it does is it takes those errors that come out of the validator, it flashes them to the session, and then when the forum page reloads, you have those errors available to you in the session. Now, of course, if you're building like a classic server-side rendered application and you redirect now back to your form, you have to repopulate old form inputs, which is not a lot of fun, which you don't have any of that stuff with Inertia because Inertia allows you to preserve your state. But anyway, that's a separate thing. But for me, it’s like you build a tool a little bit like in your own silo and the world that you know, and for me, that's Laravel. But there are also ideas that you get that just come from the tooling that you use, and the fact that Taylor Otwell made that decision in Laravel at one point is absolutely what now dictates how is the go-to way to do it in Inertia, just because it works so nicely. +CHRIS: I wonder if there's been any consideration in the Rails world to adopt that because I think from an experience perspective, it feels like it's a better thing. It feels like it has the same robustness and guarantees that I would expect. But yeah, that's interesting. It makes sense that that was just naturally there because, again, it didn't feel like the obvious correct thing that Rails was doing. It was always a little bit odd and so interesting that Laravel was already there. But then Inertia can take it that one step further. But taking a slightly higher level view of all of this, one of the things that's really interesting about Inertia to me, especially in contrast to some of the other frameworks that we've been talking about like the Livewires in the LiveViews is Inertia is almost at its core a protocol more than it is…it's a sum of pieces, and with Inertia, you have a server-side adapter, so there's the Rails adapter and the Laravel adapter. And then, on the client-side, you have a separate either Vue or React or Svelte. So those are the officially supported ones on both sides, but there's also been a swell of community support. And so there's a Django one, which I'm not sure if it's currently maintained, but I just saw a Clojure one the other day. There's a Java Spring Boot. So those are all server-side adapters. I haven't seen as much on the client-side, but I imagine there are at least a handful of them out there. And it's so interesting to me that there's this core idea that you define this protocol of communicating back and forth from the server to the client and now this collection of things that are growing around that. And I wonder again, how much was that purposeful versus how much did that just happen? And then further to add a second question to complicate things, how are you thinking about managing that community? Because my sense is that this could allow for Inertia to be so much of a bigger tent and really bring in the best ideas from all of these different communities and end up with something at the core of this Inertia thing that is the best of every community and all of that. So yeah, a lot of questions there, but I'll hand it over to you because I'm super interested. +JONATHAN: So I think when I first got going, it was Laravel and Vue; those were the tools that I worked with. And often, the best software and the best open-source software in my mind comes out of trying to solve something for your own needs. So that's really where Inertia came from and specifically for Laravel and Vue. But I quickly realized early on that it didn't have to be just a Vue and Laravel thing. So intentionally early on, I had this idea of trying to build it with multiple adapters, and I had this idea that you could build as many server-side adapters as you want and as many client-side adapters as you want, and maybe we'll officially maintain a certain amount of those, which is what we do right now. We officially maintain the Vue, the React, the Svelte adapters. And then, we also maintain officially the Laravel and the Rails server-side adapters. So that was, I would say, pretty intentional. And it's crazy how many server-side adapters people have been able to put together. Somebody wrote a ColdFusion server-side adapter for Inertia. I had no idea ColdFusion was even a thing anymore; yeah, legit. There are node ones; there are Phoenix ones; if you can believe it, there's a WordPress one, which I'm not even totally sure even how that works. There is ASP.NET. +CHRIS: [chuckles] +JONATHAN: Like, there's a whole bunch of them. And it's actually despite of me, not because of me, that this has happened because I am yet to write a good here's how to build an Inertia server-side adapter in the language and framework of your choice guide. It's been on my to-do list. I have a bunch of things I want to do. So it's still something I want to write, but people what they're doing is they're just reverse engineering what we're doing in Laravel and Rails and these other adapters, and they're figuring out how to do it in their own server-side language and framework. So that's been really, really cool. +On the flip side, on the client side, I'm starting to realize more and more that that's actually where the most important work for us as the maintainers of Inertia that we need to focus our efforts on because it's non-trivial to create these client-side adapters. And for us, we actually have four of them now because we have React and Svelte, but then we have Vue 2 and Vue 3. And they're different enough those frameworks that we actually had to create a separate adapter. So that's really where all our work is. The core of Inertia is actually ridiculously short, like the whole file, like the whole core Inertia adapter is 150 to 200 lines of code. And maybe it's a bit more than that, but it was that for a long time. It might be 300 or 400 now. It's very short. Even honestly, the client-side adapters are pretty short too. It's just that it's more difficult to make these client-side adapters because you get to learn all the intricacies of how each one of these frameworks handles their rendering. The core behavior that Inertia uses is the fact that you can dynamically swap components. So we dynamically swap page components when you visit from one page to the next and the details that come along with that. +Anyway, so I’ve realized that moving forward, my job is going to be to make sure that the client-side adapters are awesome and then letting the community drive the server-side adapters a little bit more and providing some better guides on how to do that. But yeah, for now, it’s like if we can get it working in Laravel and Rails, we should be able to get that functionality working in any server-side adapter. And because it's all again just based on HTTP, that's the language, that's the protocol like you say. That's the thing that matters between all these web frameworks, which they all, of course, support since they’re web frameworks. +CHRIS: I think you're not giving yourself nearly enough credit for the support that you've given to the server-side frameworks because you do actually have a page in the documentation called the protocol that does a great job of at least summarizing it at that HTTP level. But at the end of the day, again, like the job of someone implementing it is to then map that into their given language and framework of choice. But yeah, the documentation is impressive in just how much you put in there and how much care you obviously put into it and lots of nice, subtle details that are covered very well in that. So that again, if you read it, unlike me, then you get to know everything; eventually, I got there. I think I've read the whole thing now. But there's a lot there, and you cover all of the details. +But actually looping back to a topic that you hinted at earlier, but this is something that I've been pressing up against lately is I absolutely love building web apps in Inertia, but there's often the need to bring in a mobile app, and we want native mobile for various reasons. I love the idea of progressive web apps, and I want to push that envelope as much as I can. But as an example, right now, iOS does not support push notifications to PWA. So if that's a key feature that we want, then we're dead in the water or if there are certain GPS things. There are a bunch of true platform native things that we just can't get. And so I'm now contemplating building out an app alongside my Inertia web stuff, but I want to build a React Native app, and I'm wondering, to a certain degree, does this invalidate some of my ideas? I know you hinted at this earlier, but I think I'm still convinced of the utility of Inertia on the web. But I think I need a different paradigm to build for a mobile app, and I'm trying to decide where that line falls. I'm also wondering if I can just get away with embedding a bunch of web views and reusing my web logic because, again, if I'm building all of this, I'm going to build it in a mobile responsive way. I don't want to rebuild the core page functionality of my app just to put it on mobile. Maybe mobile folks would tell me I'm wrong there, but I'm interested in maybe wrapping it and getting access to those platform features. But yeah, I'm interested in what your thoughts are there. +JONATHAN: Well, embedding a web view within a native app has been proven to work just as DHH, obviously. But yeah, there are definitely people who disagree with that approach and feel like you should build a legitimately native app. Let's say that we're going to legitimately build a real native app. We want to have an Android and iOS app. So I actually ran into this myself for my own SaaS application, and I solved it by building a native app using React Native so React Native obviously being an abstraction on top of iOS and Android and all the tooling there, which is such an amazing platform. It was just a real joy to work with. And I don't even hardly work with React, and I was able to get a nice, high-quality native feeling app built relatively easily. But I had to come to grips with this very question because, like I've been saying all along like, “Inertia is great because you don't need to build an API. Yay, this is amazing. This is what you should do. Oh, crap. I need an API.” And I had those questions like, okay, well, does this invalidate everything that I've been doing? So I was thinking about it, and in the end, what I did is I just built a light API alongside my Inertia application. So what it is is I think I have seven endpoints, and they're just REST endpoints that are designed specifically for my native app. And this works honestly so well. +And I think I've explained to you a little bit in a previous conversation, so I'll repeat myself a little bit here for the benefit of the listeners. The reason why I think it's completely legitimate to have Inertia and build your entire web app that way and then have a companion API alongside it in the same monolith app (let's be clear: it's in the same application. It's in my Laravel app, or it would be in your Rails application) is because it just extends a core principle for me of what Inertia is. And that core principle is a tight coupling between my data layer so my controllers, and my views. So if we take that thinking where we say, well, Inertia in an Inertia web app when we have an endpoint, we hit the controller, we load data from the database, we pass that very specific data to the view, which is Vue or React or Svelte and it renders it. And there's a very tight coupling between the two. And I treated my native app in the exact same way. I said, “Okay, I need an API because obviously, the native app on iOS and Android has to make an HTTP request to get this data somehow. But instead of trying to create this super generalized API that could theoretically be used for anything, I use the same principle that said I'm going to allow myself to create an API that has a really tight coupling between the screens in my native apps and the actual data that's coming from those API endpoints. +And this worked out really, really, really well. I don't have to deal with a lot of the issues that you run into when trying to create a more generalized API because I could just say, “Hey, I have this calendar page, and I want that calendar page in my particular app. I want it to show people's birthdays, and I want it to show wedding anniversaries, and I want it to show custom events and these things that we have called schedule reminders.” So it’s data from four different endpoints. I didn't try to say, “Well, I'm going to go and create now my event’s endpoint, and my birthday's endpoint, and my anniversary's endpoint, and my schedule reminder’s endpoint,” and now have all that work to do in my native app to okay, we'll hit all these different endpoints and merge it all together; it wasn't like that at all. I created a calendar endpoint that returned all the data that's needed for that screen. And I basically applied that thinking through my whole native app, and it was really a joy to work this way. So I think that approach works really well if you have an app that doesn't have complete feature parity with your web app. +And I think if you had a native app that needed absolute feature parity between the native app and the web app, then my thinking might be a little bit different on this. But in my experience, so often, native apps have a vastly reduced subset of the features that the web app has in particular, even if not for the core functionality of the application but just for the administrative side of it. There's a whole bunch of stuff that you tend to have in a web app around administrative stuff that you literally never need. And I mean administrative both in terms of it's a multi-tenant style app, which most apps are so in terms of the user's administrative functionality and in terms of the system level, the software owner administration. If you build your whole web app to be built on top of an API, all that administrative stuff that really doesn't need to exist in both places, you now have to make it exist in your API because you've made that decision to build it that way. Whereas if you just stick with Inertia on the web and just build it using that classic monolith way where you get data from the controls and send it to your Blade views or in this situation, client-side page views, and then you just expose the stuff that you actually need natively, for me personally, it's worked out so well. And if I look at my own web app, the amount of controllers that I have for the whole web app, I have like 100; it's a very big app. And for my native app, I have about 10. So that was like, I'm so glad that I didn't have to create 100 of these in both places. +And then some people will be like you might be thinking, well, now I have duplication. I have duplication in some of my API endpoints and my web endpoints, and that's true. I would say first that duplication isn't always a bad thing. I think more duplication in our web apps would actually probably lead -- I feel like we run away from duplication too quickly. I don't think duplication is as bad as software developers often think it is. But even then, if with the duplication you can't live with yourself, there are still ways to solve duplication. So Laravel, for instance, has this concept of they're called API resources, which is basically they're essentially transformers. You give it some models, and it transforms that model into some other states, some other design. So there's nothing stopping you. And I even did this myself within my server-side application within Laravel to have an API resource to have a transformer that's used by both my Inertia controller and my API controller in a couple of situations and for me, only when it makes sense. I'm not going to do it all the time because I found that most often, I wanted the data in a slightly different format in my native apps than I'd want it into my web app. So quite often, that didn't happen. But I'm just saying if you're scared of duplication, there are totally ways to solve it. And we can solve this in our existing frameworks. Laravel or Rails has ways to allow us to abstract some of that stuff and reuse it in multiple places. So, yeah, that's my long-winded answer to how I've approached doing the native apps sort of thing. I think that tight coupling between the data and the screen I think that's a really nice thing, and you just can build faster. And just like you can build faster with Inertia on the website, you can build fast [inaudible 43:19] +CHRIS: Frankly, that answer makes a ton of sense one and two, makes me feel better about the path that I'm on because, again, I'm really desperate to cling to Inertia for the web side of things. So I love what you're saying. And again, it really resonates with me and how you're thinking about building. There's also I really appreciate a subtle common theme that I've seen in a bunch of things that you've said where you're like; let me poke at best practices a bit and see what falls out. What if we were to actually embrace the coupling between our data and our view layer? And it's like, actually some really nice things happen there. And actually, going back to an earlier project that you worked on, Tailwind CSS is one of those projects that when you first see it, you're like, well, that's obviously wrong. That's definitely an incorrect way to do things. But then you explore it, and you're like, well, I mean, I know there are trade-offs here, but actually, in my experience and I'm sure in your experience, Tailwind is absolutely fantastic. And the trade-offs you totally win in the long game, and it's maintainable, and it's understandable. And you can continue to develop on top of it in a way that I've never found with any other CSS framework. But again, at first glance, you're like, ooh, that's not right. That can't be right. +JONATHAN: 100%, exactly. I think it's fun to push back and just experiment with different things. And for me, I think a lot of my decisions, too, come back to the fact that I'm running a SaaS application as one person, and I need to be able to move fast. I don't want to have two different servers and two different repos. I want to be able to build my applications as fast as I can, as a single developer, a single founder. And so I think the things that I push against and try and experiment with come out of me trying to find the simplest ways to maintain things. So Tailwind, that's really Adam's brainchild. I came along in the first six months or so; me and him built it. I was really just helping him flesh out his idea there, and that was super fun. But yeah, I had the exact same experience as you. Adam was telling me about this, and I'm like, that sounds pretty terrible. Like, I have CSS figured out already. And then it was like, oh man, this is amazing. Fun little fact, my SaaS app, me and him, were both working on web apps at that time. So my SaaS app was one of the first Tailwind applications ever because I and Adam were literally both building our own apps while building Tailwind CSS. +But anyway, so yeah, it comes out of not me trying to be like, I know better than other people; it's not that at all. It's more just I'm trying to find a way to survive as a business and trying to build at the same time, not only survive but also I want to build awesome products. I don't want to build software that is just kind of okay. I love striving to make software that's just exceptional that delights people that works the way someone expects it to work. And I just think that there's so much broken software out there. There's a lot of bad software. And don't get me wrong, I've created a lot of bad software, too. But I really try to hold myself to a high standard. And really, for me, that comes down to not necessarily what some purist says that “This is how you need to do it.” It comes more down to like, okay, let me see the results. How fast does the webpage open? What's the performance? You mentioned my course earlier. I’m really, really interested in database performance and how to use databases more intelligently to deliver really fast web applications. And that matters to me because customers hate waiting. They hate it. And that was even part of what drove me to create Inertia because I hated this. I was working for a company, and we had built the right way where we have an API and the client separate And we went down that road. And that was a big team with 20 to 30 developers in the end. And I was just like -- I shouldn't say, “I was,” but we, in general, were not happy with what happened because just the way that the app was built and the way that single views were hitting the API. You could probably argue that this was like we were doing something wrong, but the paradigm didn't lend us to doing it right, in my opinion. So we'd have pages that were hitting the REST API with sometimes 10, 20 HTTP requests just to get the data. And you're dealing with all the loading states of all this stuff. And of course, there were probably better ways to design, but we were trying to ship a product there too. We were trying to get it out the door and make happy customers. And I didn't feel like that way was helping us. +I think GraphQL, just as an aside, is a huge step forward where you can say, “Hey, here's all my data in an API, but I'm not going to hit the user's endpoint just to get back whatever you decide to give me.” I can be much more intentional about saying, “Hey, I want this data and then pull in this relationship for that data and this other piece of data.” And I think that's really, really cool. But I think the problem there again is you need to build that GraphQL API, and that's non-trivial, not to mention you probably have to figure out OAuth, which is pretty much always a game-stopper for me because if I never have to work with OAuth in my life [laughs] I'll be totally okay with that. I know it has its place, but yeah. +CHRIS: There's a clear passion and a desire that you're describing there to just build good things and the belief that it can be done. And then, as someone who has really benefited from your work, I thank you for carrying that torch and for pushing the envelope. And like you said, having that high standard and holding yourself to it but then hopefully bringing the rest of us along, and I really appreciate that. But I think with that, that's probably a perfect time to wrap up. If folks want to follow more of what you are working on, where can they find what you're up to on the internet? +JONATHAN: I'm on Twitter, the classic place to go for following someone in tech, so twitter.com/reinink, my last name. That's R-E-I-N-I-N-K. So that's where even if I have stuff shared elsewhere on the web, that's where it starts. +CHRIS: Perfect. We'll include links to your Twitter as well as everything else that we've mentioned in this episode in the show notes. So folks that do want to keep up or investigate further listening to that other podcast episode that I mentioned will have all of that available. But with that, thank you so much for your time, and yeah, again, really appreciate you joining. +JONATHAN: Thanks so much, Chris. Pleasure to be here. +CHRIS: The show notes for this episode can be found at bikeshed.fm. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. If you have any feedback for this or any of our other episodes, you can reach us at _bikeshed on Twitter. Or you can reach me @christoomey, or you can e-mail hosts@bikeshed.fm. Thanks so much for listening to The Bike Shed, and we'll see you next week. +This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + inertiajs, rails, laravel + + This week Steph's taking a quick break, but while she's off, Chris is joined by a special guest - Jonathan Reinink. Jonathan is the creator of Inertia.js. Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers, and listeners of the show will certainly have heard Chris rave about it on previous episodes.

+ +

Chris and Jonathan dig into what makes Inertia unique as compared to frameworks like Phoenix LiveView, Laravel Livewire, and Rails' Hotwire & Turbo. They also discuss how Inertia embraces the URL, the unique "protocol" nature of Inertia, and how to consider Inertia alongside native mobile applications. Throughout the conversation, Jonathan's consistent philosophy of wanting to build robust, performant, and delightful applications shines through.

+ + + +

Transcript:

+ +

CHRIS TOOMEY: I am seeing what I believe to be the relevant things.

+ +

JONATHAN REINIK: Let's dance.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week, Steph is taking a quick break, but while she's away, I'm joined by a special guest, Jonathan Reinik. Jonathan Reinik is the creator of Inertia.js. And listeners of the show will know that that is increasingly one of my favorite frameworks and, frankly, just ways to build applications on the internet. Jonathan is also the creator of the Eloquent Performance Patterns course, which teaches the Eloquent ORM, which is the ORM in Laravel but really digs into deep performance and database things, so really covering that back end as well. Jonathan also collaborated on the development of Tailwind CSS, a utility-first CSS framework which again is something that I have spoken of in very high terms on this podcast. And lastly, Jonathan currently runs his own SaaS business called Church Social. So really, Jonathan is a bit of a quadruple threat covering back end and front end design and entrepreneurship. So pretty much everything you want to see. And frankly, I've been so impressed by the breadth and the depth of Jonathan's work and just the deep way that he is thinking about building applications. So I am absolutely thrilled to have him on the show today. So without further ado, Jonathan, thank you so much for joining me.

+ +

JONATHAN: Thanks so much, Chris. That was a very kind introduction, and yeah, it's awesome to be on The Bike Shed. I've been a long-time listener, and as I've said to you, I really appreciate the support that you've given to my work over the years. So yeah, it's awesome to be here.

+ +

CHRIS: That's interesting. We're measuring it in years now, but it's a very sincere thing for me. I think with Inertia, you've built something that is both very unique and a special approach to how we build things, but it's also built from very familiar pieces and allows us to reuse the deep amounts of knowledge that we have in the Rails community or the Laravel community. But actually backing up just a little bit, because we're going to dive deep on Inertia.js today, for folks that are not as familiar or have only heard me mention it in passing, there's a wonderful episode of Full Stack Radio where Jonathan and Adam Wathan talked about Inertia.js, and I think gave a very good foundational summary. So we'll link to that in the show notes in case anyone wants to dig in a little bit more. Likewise, Jonathan has a really fantastic blog post called Server-side Apps With Client-side Rendering, which, as far as I can tell, is the manifesto that began this whole journey for you. And I really love that you have done so much of the work in public, and people can see the history of how this idea has evolved and really crystallized into what now is a very production-ready framework in sort of the way to build things. But I would love to hear right now just for anyone who is not as familiar and also just to hear how you summarize it at this point in time. What does your introductory elevator pitch for Inertia.js sound like in April 2021?

+ +

JONATHAN: That's a great question. So it's hard to answer this without unpacking a lot of different things. And you mentioned the podcast with Adam; I think that's good because it goes in a lot of the technical detail of how Inertia works and why I created it. But the elevator pitch these days for when I talk to someone about it, it's generally I explain it as a way of building modern web apps. And in particular, when I say modern, I mean web apps that have a lot of JavaScript, so frameworks like Vue or React or Svelte, so applications that are built using those tools. And the key thing that Inertia offers is for you to develop these modern applications without having to first build an API sort of the way historically if you ever wanted to use one of these modern web stacks like Vue or React or Svelte, you could use them within Laravel or Rails by inserting them into your Vue or into your Blade templates or your ERB templates. But it was difficult if you ever wanted to turn it into a legitimate single-page application. And anytime you would ask that question, if you go out on the internet and say, “Hey, how do I build SPA with, say, Vue and Laravel or React and Rails?” The answer was always, “Well, you need to build an API. You need to build an API.” That was always the missing piece because that's the way that everyone in the Jamstack era that we're in that's the way that everyone's building their applications that are like these heavy client-side applications.

+ +

And I totally get the need for those style apps and the place for those style apps. But I really missed this way that you could build an application with Rails or with Laravel where you could just literally spin up a new app, create some routes within your server-side framework, create some controllers, create some views, and have a working application within minutes really. You could have something being displayed on the screen within minutes with these classic monolith applications. And if you wanted to do the same thing, if you wanted to get an app up and running in minutes with Vue or React as your completely client-side SPA scenario, it just wasn't working because as soon as you say, “Well, in order to do that, you're going to need to have a back end Rails or a Lavarel application, and then a client-side Vue or React application. And then you're going to have to create this API that connects the two together.” There's just a lot more work that goes into that. It's not only the work of actually creating the API; I find a lot of the decisions that come along with building an API; it’s like, okay, what does the abstraction look like? Am I going to build it with REST, or am I going to build it as a GraphQL API? And all the decisions that come along with designing and architecting that which again has its place. But there's just something awesome about saying, “Here's a new route. Here's the view that I want to render. And here's the data that I want that view to have,” and just go off and do it, and it's done.

+ +

And some people ask me, “Well, with Inertia, if you're not building an API, what happens someday if you need an API?” And they frame it like, well, this is a terrible decision. You should be starting with an API. But for me, the reality is that so many of the web applications that I was building and that I've seen other people building is they had already made the decision not to use an API because they had already made the decision that they wanted to use Laravel as a monolith app that had their controllers and the routes and their views all within that and the same thing with Rails. So if you've made that decision to build a monolith app with Laravel or Rails, you've already made the decision to not build it with an API. I was coming in from the other way. It's like, I just want to build an app the way I've always built in Laravel, and I don't want to have to build this API. Of course, there are times where you do need an API, which I think we're going to talk about maybe a little bit later if I don't ramble on too long, where it does make sense to have an API. But yeah, that's kind of the elevator pitch.

+ +

I think maybe to close off that thought is that I really, really enjoy having a tight coupling between my routes and my data layer and my views, which, again, I appreciate that. That probably sounds like blasphemy in modern web development. But for me, I think it's so empowering when you say, “Hey, I have a controller that's given me some data, and I have a view that's rendering the data, and those two know about each other, and those two depend on each other.” You can work so fast because I'm not thinking, okay, well, I have this API endpoint that returns a user, and that has their first name and their last name and their email. But I also need to think about it in the situation in the future where I might need this attribute or that attribute or some other attribute and make sure I have all that figured out ahead of time or at least have a way to add it in later. And all of that thinking that goes into designing an API, I find that that adds a lot of overhead.

+ +

And then maybe related to that also is the amount of times that you're rendering a view within your application that needs data from multiple different places. And to me, this is like one of the huge performance benefits that you get with a tool like Inertia is with, say a REST API, GraphQl solves this, but with a REST API, you're often getting too much data for what you actually need for the page, or you're often making more than one HTTP request because you say, “Well, on this particular dashboard, I need some user information. So I have to hit the user endpoint. I need maybe the latest product sales data, so I need to hit that endpoint.” And you’re dealing with these performance issues that you get with a REST API that with Inertia, you don't have that problem because it's just going back to classic Laravel Blade views or Rails and ERB templates. Am I saying that right, ERB template?

+ +

CHRIS: Mm-hmm.

+ +

JONATHAN: In those situations, you say, “Well, if I need data from three different places, well, I'll just grab data from three different places and send it to the view, and that's fine. And I can do that in the most efficient way and get the data that I need specifically for that view.” So anyway, that's some of the thinking that drove me to build Inertia and some of the things that I was going for. And yeah, it was an evolution. It really came out of me using Turbolinks and really appreciating what Turbolinks gave me but taking it to that next step where it's like Turbolinks, except it's built with the same principles as Turbolinks but built for modern client-side frameworks like Vue and React.

+ +

CHRIS: Yeah, that all feels very familiar to me. And in my experience, I've now worked with Inertia on a handful of projects, but in particular, I have just a small personal app that I use to manage different aspects of my life. And it's been my playground for different technologies. And I've migrated it through a bunch of different versions where it used to just be a Rails app. And I was like, oh no, the thing that I need to do to be on the cutting edge is to turn this into -- it's a Rails app on the back end with an API, and then it's a React app. It's separately deployed, but those two talk to each other. And what you were talking about of the deep coupling, I think that coupling exists whether we want it to or not. And so embracing that and revisiting when I eventually migrated that application to use Inertia and the client-side stuff folded back into the core codebase. Now deployments all go out in sync. And that turns out to actually be a really nice thing and a non-trivial thing to solve otherwise.

+ +

As a developer of one on this particular project, the amount of complexity that was removed from the app when I switched it over to Inertia was amazing. I got to remove client-side routing. I got to remove client-side state management, which I think I was using Redux at the time. I got to remove some form helpers that I had. I think I might've been using Formik or React Use Former, any of those. But there are so many different little pieces that you ended up cobbling together to make an application. And it was amazing to me as I moved to Inertia, where I was like; actually, I don't need any of those, and routes suddenly are defined in one place in Rails in a familiar way. But things like redirects all work -- It feels just like a Rails app but with the extra abilities that a front-end client-side framework gives you when you want those when you need those. But otherwise, it really does feel like I'm rendering to an ERB template. It just happens to be that that template is rendering on the client-side and is written in React or Svelte or whatever the front-end framework is. But it almost feels like progressive enhancement. I'm borrowing a term, and it's not actually applicable here, but it really feels like that. It's like, oh, it's a Rails app, but I just want to make it a little bit fancier, and Inertia does that in such a fantastic way.

+ +

And actually pivoting just a bit, as far as I can tell, there seems to be an explosion of thinking in this space. There are a handful of frameworks, namely Laravel Livewire, which is often paired with Alpine.js. Elixir has Phoenix LiveView, and then Rails has the Hotwire suite, which Turbo and Stimulus are the most pointed considerations. But interestingly, I think all of those frameworks, which I think are trying to provide a very similar experience, tend to keep things on the server-side, so using the Laravel Blade templates or the ERB in Rails. But you've taken the different approach to say, “No, let's embrace this front-end technology where it makes sense.” And again, there are a lot of pieces that can fall in, and I don't need the Redux and the React Router and all of those things but still use that client-side framework to be the rendering engine. And so I'm intrigued if you can talk a little bit more about that and that trade-off because I think it really differentiates Inertia and its approach. I personally found it to be fantastic, but I'd love to hear a little bit more about your thinking on that.

+ +

JONATHAN: The thing about modern websites and web apps, in particular, is it doesn't matter how you slice it; we need JavaScript. So if you disagree with me there, then everything I say from this point on will not make sense to you. But I think we can all agree that modern web apps need JavaScript. JavaScript is the programming language of the web of the browser that allows us to do whatever magical things that we want to do. And if you look at tools like Phoenix LiveView, Laravel Livewire, and even the new Turbo stuff from the folks over at Basecamp, they all are embracing JavaScript in the same way. It's just they're framing it in a different way. I would say, especially with Livewire and LiveView, they're almost creating like an abstraction between the server and the way you write things on the server and the client-side. And they're almost hiding the JavaScript, which is really, really cool. I think it's such an interesting thing to try to do where somebody who's not familiar with JavaScript and not familiar with Vue, React, and Svelte can go and do things, write server-side code that gets rendered server-side. And then there's some JavaScript that these libraries insert that allow you to do more interesting things, whatever those things might be, show a drop-down, or drag and drop or validate a form or submit a form without actually submitting it fully to the server but submit it over XHR instead, all these kinds of things. But the point is they're embracing JavaScript just in a different way. And same with Turbo, Turbo gives you a way to write JavaScript for an application that mostly has server-side rendered HTML.

+ +

So I think it's important to just recognize that JavaScript is key in all these frameworks. With Inertia, it's the same idea in that Inertia wants to embrace that classic way of building applications using the classic server-side monolith application framework like Laravel or Rails. But the difference is it acknowledges or embraces these existing client-side frameworks that have really grown in popularity. And the three, again, I keep mentioning them, Vue, React, or Svelte. Svelte being an up-and-coming one that's not nearly as popular yet, but it seems to be gaining a lot of steam.

+ +

CHRIS: It's on the rise. That’s my long [inaudible 14:46]

+ +

JONATHAN: Yes, and people keep saying that. So anyway, Inertia basically said, “Hey, we want to keep building server-side apps. We want to keep building monolith apps similar to these other tools, except what we're going to do is we're going to embrace the fact that there's this really, really amazing tooling that's been developed for the client-side.” And it just doubles down on that. So for me, the reason that I ended up here was because, in my own SaaS application, it was a Laravel application that started with mostly Blade views initially. And then, over the years of building it, which has been many, many years, I've slowly added more and more Vue components within my app. And initially, the way I did it is those Vue components would just be inserted in as regular HTML tags in my server-side rendered templates. And then, when the page renders, those Vue components would boot up and do whatever they need to do. So for me, when I was building Inertia, I had already fallen in love with Vue, in particular, and having all the power of these client-side frameworks. And there is so much there. It's not just Vue, React, and Svelte; it's all the amazing tooling that's available out there that you can add on top of it.

+ +

And this is the thing I often tell people that Inertia isn’t -- we say right on the homepage, “Inertia isn't a framework.” And the reason why I say that is because I don't want people to think of Inertia as an alternative to Vue, React, and Svelte. Do you know what is a better way to frame it? It's actually more of an alternative to React Router or Vue Router; that's really more what it is, where you can say, “All my routings are handled server-side,” and that has all kinds of interesting implications. But it's more of a router, and it just so happens to pass along that routing control over to the server. Anyway, so that's really for me what differentiates Inertia from those other tools is because it's really doubled down on these client-side frameworks.

+ +

And I think the reason why Inertia has been relatively popular is because people know Vue and people know React. And when it comes to then working with Inertia, it's not some new thing that they have to learn. It's an existing set of tools that they're already super comfortable with. And in so many ways, when you're building an Inertia app, you're kind of building a classic Vue app or a classic React app or a classic Svelte app. It's just there's a bunch of pieces missing. Like you said, it's like a bunch of the client-side state management stuff, which nobody likes anyway, is gone. The other thing that's gone is client-side routing. You don't have this back-end routing is over here now, and client-side routing is over here, and I have two different routing definitions. It's like, no, that's all just server-side now in one place.

+ +

The other amazing thing you get is you mentioned redirects and that whole HTTP layer you get just along with Inertia for free because it's just part of your server-side stack. And one key aspect of that is auth. You can just use good old-fashioned nothing is better than session auth. Like, it just works. And, so whatever your typical solution for doing session auth in Laravel or Rails or whatever server-side framework you're using, all this stuff just works. So anyway, coming full circle on your question, the reason why Inertia has gone this way is because I really think that there's a huge amount of value with using these modern frameworks. And we just doubled down on using them.

+ +

CHRIS: Yeah, that resonates with my experiences using Inertia and in contrast to the other frameworks. Everyone seems to be trying to get to the same place of providing a mechanism to have more almost app-like functionality but still using the traditional server-side technologies. But I think Inertia has chosen an approach to that that is unique in that category and really has provided a fantastic outcome. I've been very frankly surprised by the fidelity of experience and how app-like I can get something to feel when building with Inertia while still using all the same technologies. And the fact that I can use just traditional server-side auth and redirects and things like that is just so nice, and everything feels right.

+ +

There's an experience that I've had on many applications that are, say, a React client-side bundle that gets sent down and then boots up, and then the layout starts to render. And as its data fetching, it gets like a 402 response or something like that in that data fetching. And then it's like, oh no, I need to hard redirect you over here on the client-side to this other page. And there's this junk of semi-filled-out layout, and then suddenly you're on the login page. And again, with Inertia, it looks like a normal server-side rendered app, but it isn't in the ways that really matter to us. And it is one of those things where the more I played with it, the more there's an experience of interacting with Inertia that it surprises me consistently how nice it is to work with it and yet it's so much easier to maintain an application using it. I know I'm raving here, but I am really a big fan of this for everyone listening in the audience.

+ +

JONATHAN: [laughs]

+ +

CHRIS: And actually to continue on one of the things you were saying there, one of the things that stands out to me in Inertia is the way that it embraces URLs and to a certain degree, that seems like a purposeful thing, but it also seems like it just naturally falls out of how Inertia works because we're no longer using a client-side state management technology, the way to manipulate state is through the URL. If you want to see a different version of the to-do list you're looking at when you click on that link, you change the URL and the state changes in response to that. And so everything is fundamentally kept in sync, but URLs are very much at the center of the architecture, and I really love that so much. I think URLs are often forgotten in client-side frameworks or underserved or underused. And it turns out in my experience as a user and both having served many users, people love to command-click on links. They love to right-click open a new tab. They love to be able to reload and see the same thing on the screen when they reload the page. They love to be able to bookmark. These are all really wonderful things that come out of working on the web. And the fact that Inertia has a pit of success around having URLs and have that be the way that we drive state is just so fantastic. So I'm wondering how much of that was very purposeful on your part versus how much of that fell out of the architecture.

+ +

JONATHAN: That is very much something that fell out of the architecture. I say that not to say that I don't value URLs; I absolutely did. That's the way every single one of my Laravel built apps worked. It always starts in the route file. You hit the route file, you define a new route, and it goes from there. So I absolutely think that the URLs are critical. But the fact that it just ended up working out so nicely was, yeah, I'm going to say it was a bit of luck, a bit of coincidence. I find this is what's so interesting when you start pushing on a new way of things; you initially don't really know where it's going to end. It’s like you have some ideas of how the tool can work and where it might go, but I think there's a lot of unknowns that you just figure out after a while. So the thing I said earlier actually about the fact that Inertia in a lot of ways is like a client-side router; it’s, it's a routing library, to put it that way. I had been working on Inertia for a year and a half, and then a buddy of mine, Taylor Otwell, the creator of Laravel, he and I were chatting, and he said to me at one point he's like, “Oh, you know what? Inertia is actually super simple. It's really just a routing library.” And it was like, bam. It was kind of that moment; it’s like, oh yeah, I hadn't thought of it like that at all. But when he said that, it made a ton of sense to me. So it's just this interesting progression the more you work on something, and the more you push on the edges, you learn what's possible and what it even is.

+ +

I had this interesting experience, so remembering that Inertia came from Turbolinks. So I had my whole app built with Laravel ton of server-side rendered templates with Blade with view mixed in. And I had the SPA mode by clicking around using Turbolinks. So when I decided to try building Inertia, I removed Turbolinks, and all these requests now happened over XHR but using this preset JSON structure that powers Inertia. I really, in my mind, had this idea that it was only for GET requests, for GET visits; it was just for that. So the initial version of Inertia, there was no Inertia.post or Inertia.put or anything like that. It just wasn't something I even thought was possible. But then I remember, and this is often how it goes; I was out for a hike that day to get away from the computer for a little while and just let your brain drift; I'm sure you can relate to that. I was like, wait a minute; I could totally just support POST, PUT, PATCH, DELETE. And that was such an aha moment for me where I just realized that it was so much more than what I originally thought it was.

+ +

And then the whole thing from that I remember it was a bit of like a waterfall effect after that where I remember running home out on that hike and hacked it together, and then it was like, okay, well, if I submit a form using POST, well, okay, I'm on the create user page. And I submit this form using Inertia.post to the user's endpoint. I'm like, well, how do I now end up back at the user index page or whatever page, maybe the user edit page. I’m like, wait a minute, I can just return a redirect back to the user index page, and it's literally going to return an Inertia response from the user index page. And then the way Inertia works is it dynamically swaps the page component client-side. And it was just like, oh, this is way too cool. And this really drives my thinking now that it's become a little bit more clear to me is that it really it's all based on HTTP using headers and normal HTTP stuff like redirects are such a critical piece of the story. But to me, that's super neat that, in a way, it's like a throwback to the fundamentals of the web and the browser and the fact that Inertia can just use those things,,, and it doesn't have to be fancy in a lot of the ways. It can just rely on those existing core pieces of the browser. So, yeah.

+ +

CHRIS: It really is interesting to me how it feels like progressive enhancement in that way where you're building on top of these core fundamentals of HTTP and requests and redirects and status codes and things of that nature. Particularly interesting to me was it took me a while, I'm going to be honest, to figure out forms and particularly validation errors in Inertia. And that is entirely my fault. You have absolutely fantastic documentation. I am so impressed by the quality and the density of the documentation that you have that really covers everything. If we're being honest, I hadn't read the page, but I was doing form posting and then the subsequent errors and how you deal with that. I was doing it in a very traditional Rails way which if we're being honest, that is not a fundamental of how HTTP works. Rails just chose an option of oh, if you POST but we don't create the object because there's a validation error, then we're going to stay on the URL of the POST, so the collection route, but we're going to re-render the form in line. And that's a choice that Rails made that is interesting because at that point, if a user reloads the page, then things are weird, and it's not going to reload. They're not going to see the same thing after that reload, or it's going to try to repost or et cetera, et cetera. There's a bunch of edge cases there that sort of fall out. Whereas with Inertia, you end up redirecting back, and there's this interesting handshake of the errors, but from an end-user experience, it is absolutely fantastic where you stay on the form; the URL does not change. Technically, there's a POST and a redirect back under the hood, but Inertia just handles all of that for you. And you end up with sort of in-line validation errors. But you don't clear out any fields, and there are just wonderful things that fall out of it that again took me a while to get there, but it was another one of those oh, wow, this just naturally falls out of the architecture, but it's so nice and such a nice incremental advance on top of frankly, the stuff that I was doing in Rails historically.

+ +

JONATHAN: So the way that Laravel works and it's always worked this way is when you make a request using POST or PATCH or DELETE or whatever to an endpoint, and that endpoint does its validation in the event that that validation fails, this is just like built-in standard like Laravel Stock behavior. It automatically redirects you back to the endpoint that you were on. So if you're on the create page or the edit page, it automatically redirects. That's just Laravel behavior. And what it does is it takes those errors that come out of the validator, it flashes them to the session, and then when the forum page reloads, you have those errors available to you in the session. Now, of course, if you're building like a classic server-side rendered application and you redirect now back to your form, you have to repopulate old form inputs, which is not a lot of fun, which you don't have any of that stuff with Inertia because Inertia allows you to preserve your state. But anyway, that's a separate thing. But for me, it’s like you build a tool a little bit like in your own silo and the world that you know, and for me, that's Laravel. But there are also ideas that you get that just come from the tooling that you use, and the fact that Taylor Otwell made that decision in Laravel at one point is absolutely what now dictates how is the go-to way to do it in Inertia, just because it works so nicely.

+ +

CHRIS: I wonder if there's been any consideration in the Rails world to adopt that because I think from an experience perspective, it feels like it's a better thing. It feels like it has the same robustness and guarantees that I would expect. But yeah, that's interesting. It makes sense that that was just naturally there because, again, it didn't feel like the obvious correct thing that Rails was doing. It was always a little bit odd and so interesting that Laravel was already there. But then Inertia can take it that one step further. But taking a slightly higher level view of all of this, one of the things that's really interesting about Inertia to me, especially in contrast to some of the other frameworks that we've been talking about like the Livewires in the LiveViews is Inertia is almost at its core a protocol more than it is…it's a sum of pieces, and with Inertia, you have a server-side adapter, so there's the Rails adapter and the Laravel adapter. And then, on the client-side, you have a separate either Vue or React or Svelte. So those are the officially supported ones on both sides, but there's also been a swell of community support. And so there's a Django one, which I'm not sure if it's currently maintained, but I just saw a Clojure one the other day. There's a Java Spring Boot. So those are all server-side adapters. I haven't seen as much on the client-side, but I imagine there are at least a handful of them out there. And it's so interesting to me that there's this core idea that you define this protocol of communicating back and forth from the server to the client and now this collection of things that are growing around that. And I wonder again, how much was that purposeful versus how much did that just happen? And then further to add a second question to complicate things, how are you thinking about managing that community? Because my sense is that this could allow for Inertia to be so much of a bigger tent and really bring in the best ideas from all of these different communities and end up with something at the core of this Inertia thing that is the best of every community and all of that. So yeah, a lot of questions there, but I'll hand it over to you because I'm super interested.

+ +

JONATHAN: So I think when I first got going, it was Laravel and Vue; those were the tools that I worked with. And often, the best software and the best open-source software in my mind comes out of trying to solve something for your own needs. So that's really where Inertia came from and specifically for Laravel and Vue. But I quickly realized early on that it didn't have to be just a Vue and Laravel thing. So intentionally early on, I had this idea of trying to build it with multiple adapters, and I had this idea that you could build as many server-side adapters as you want and as many client-side adapters as you want, and maybe we'll officially maintain a certain amount of those, which is what we do right now. We officially maintain the Vue, the React, the Svelte adapters. And then, we also maintain officially the Laravel and the Rails server-side adapters. So that was, I would say, pretty intentional. And it's crazy how many server-side adapters people have been able to put together. Somebody wrote a ColdFusion server-side adapter for Inertia. I had no idea ColdFusion was even a thing anymore; yeah, legit. There are node ones; there are Phoenix ones; if you can believe it, there's a WordPress one, which I'm not even totally sure even how that works. There is ASP.NET.

+ +

CHRIS: [chuckles]

+ +

JONATHAN: Like, there's a whole bunch of them. And it's actually despite of me, not because of me, that this has happened because I am yet to write a good here's how to build an Inertia server-side adapter in the language and framework of your choice guide. It's been on my to-do list. I have a bunch of things I want to do. So it's still something I want to write, but people what they're doing is they're just reverse engineering what we're doing in Laravel and Rails and these other adapters, and they're figuring out how to do it in their own server-side language and framework. So that's been really, really cool.

+ +

On the flip side, on the client side, I'm starting to realize more and more that that's actually where the most important work for us as the maintainers of Inertia that we need to focus our efforts on because it's non-trivial to create these client-side adapters. And for us, we actually have four of them now because we have React and Svelte, but then we have Vue 2 and Vue 3. And they're different enough those frameworks that we actually had to create a separate adapter. So that's really where all our work is. The core of Inertia is actually ridiculously short, like the whole file, like the whole core Inertia adapter is 150 to 200 lines of code. And maybe it's a bit more than that, but it was that for a long time. It might be 300 or 400 now. It's very short. Even honestly, the client-side adapters are pretty short too. It's just that it's more difficult to make these client-side adapters because you get to learn all the intricacies of how each one of these frameworks handles their rendering. The core behavior that Inertia uses is the fact that you can dynamically swap components. So we dynamically swap page components when you visit from one page to the next and the details that come along with that.

+ +

Anyway, so I’ve realized that moving forward, my job is going to be to make sure that the client-side adapters are awesome and then letting the community drive the server-side adapters a little bit more and providing some better guides on how to do that. But yeah, for now, it’s like if we can get it working in Laravel and Rails, we should be able to get that functionality working in any server-side adapter. And because it's all again just based on HTTP, that's the language, that's the protocol like you say. That's the thing that matters between all these web frameworks, which they all, of course, support since they’re web frameworks.

+ +

CHRIS: I think you're not giving yourself nearly enough credit for the support that you've given to the server-side frameworks because you do actually have a page in the documentation called the protocol that does a great job of at least summarizing it at that HTTP level. But at the end of the day, again, like the job of someone implementing it is to then map that into their given language and framework of choice. But yeah, the documentation is impressive in just how much you put in there and how much care you obviously put into it and lots of nice, subtle details that are covered very well in that. So that again, if you read it, unlike me, then you get to know everything; eventually, I got there. I think I've read the whole thing now. But there's a lot there, and you cover all of the details.

+ +

But actually looping back to a topic that you hinted at earlier, but this is something that I've been pressing up against lately is I absolutely love building web apps in Inertia, but there's often the need to bring in a mobile app, and we want native mobile for various reasons. I love the idea of progressive web apps, and I want to push that envelope as much as I can. But as an example, right now, iOS does not support push notifications to PWA. So if that's a key feature that we want, then we're dead in the water or if there are certain GPS things. There are a bunch of true platform native things that we just can't get. And so I'm now contemplating building out an app alongside my Inertia web stuff, but I want to build a React Native app, and I'm wondering, to a certain degree, does this invalidate some of my ideas? I know you hinted at this earlier, but I think I'm still convinced of the utility of Inertia on the web. But I think I need a different paradigm to build for a mobile app, and I'm trying to decide where that line falls. I'm also wondering if I can just get away with embedding a bunch of web views and reusing my web logic because, again, if I'm building all of this, I'm going to build it in a mobile responsive way. I don't want to rebuild the core page functionality of my app just to put it on mobile. Maybe mobile folks would tell me I'm wrong there, but I'm interested in maybe wrapping it and getting access to those platform features. But yeah, I'm interested in what your thoughts are there.

+ +

JONATHAN: Well, embedding a web view within a native app has been proven to work just as DHH, obviously. But yeah, there are definitely people who disagree with that approach and feel like you should build a legitimately native app. Let's say that we're going to legitimately build a real native app. We want to have an Android and iOS app. So I actually ran into this myself for my own SaaS application, and I solved it by building a native app using React Native so React Native obviously being an abstraction on top of iOS and Android and all the tooling there, which is such an amazing platform. It was just a real joy to work with. And I don't even hardly work with React, and I was able to get a nice, high-quality native feeling app built relatively easily. But I had to come to grips with this very question because, like I've been saying all along like, “Inertia is great because you don't need to build an API. Yay, this is amazing. This is what you should do. Oh, crap. I need an API.” And I had those questions like, okay, well, does this invalidate everything that I've been doing? So I was thinking about it, and in the end, what I did is I just built a light API alongside my Inertia application. So what it is is I think I have seven endpoints, and they're just REST endpoints that are designed specifically for my native app. And this works honestly so well.

+ +

And I think I've explained to you a little bit in a previous conversation, so I'll repeat myself a little bit here for the benefit of the listeners. The reason why I think it's completely legitimate to have Inertia and build your entire web app that way and then have a companion API alongside it in the same monolith app (let's be clear: it's in the same application. It's in my Laravel app, or it would be in your Rails application) is because it just extends a core principle for me of what Inertia is. And that core principle is a tight coupling between my data layer so my controllers, and my views. So if we take that thinking where we say, well, Inertia in an Inertia web app when we have an endpoint, we hit the controller, we load data from the database, we pass that very specific data to the view, which is Vue or React or Svelte and it renders it. And there's a very tight coupling between the two. And I treated my native app in the exact same way. I said, “Okay, I need an API because obviously, the native app on iOS and Android has to make an HTTP request to get this data somehow. But instead of trying to create this super generalized API that could theoretically be used for anything, I use the same principle that said I'm going to allow myself to create an API that has a really tight coupling between the screens in my native apps and the actual data that's coming from those API endpoints.

+ +

And this worked out really, really, really well. I don't have to deal with a lot of the issues that you run into when trying to create a more generalized API because I could just say, “Hey, I have this calendar page, and I want that calendar page in my particular app. I want it to show people's birthdays, and I want it to show wedding anniversaries, and I want it to show custom events and these things that we have called schedule reminders.” So it’s data from four different endpoints. I didn't try to say, “Well, I'm going to go and create now my event’s endpoint, and my birthday's endpoint, and my anniversary's endpoint, and my schedule reminder’s endpoint,” and now have all that work to do in my native app to okay, we'll hit all these different endpoints and merge it all together; it wasn't like that at all. I created a calendar endpoint that returned all the data that's needed for that screen. And I basically applied that thinking through my whole native app, and it was really a joy to work this way. So I think that approach works really well if you have an app that doesn't have complete feature parity with your web app.

+ +

And I think if you had a native app that needed absolute feature parity between the native app and the web app, then my thinking might be a little bit different on this. But in my experience, so often, native apps have a vastly reduced subset of the features that the web app has in particular, even if not for the core functionality of the application but just for the administrative side of it. There's a whole bunch of stuff that you tend to have in a web app around administrative stuff that you literally never need. And I mean administrative both in terms of it's a multi-tenant style app, which most apps are so in terms of the user's administrative functionality and in terms of the system level, the software owner administration. If you build your whole web app to be built on top of an API, all that administrative stuff that really doesn't need to exist in both places, you now have to make it exist in your API because you've made that decision to build it that way. Whereas if you just stick with Inertia on the web and just build it using that classic monolith way where you get data from the controls and send it to your Blade views or in this situation, client-side page views, and then you just expose the stuff that you actually need natively, for me personally, it's worked out so well. And if I look at my own web app, the amount of controllers that I have for the whole web app, I have like 100; it's a very big app. And for my native app, I have about 10. So that was like, I'm so glad that I didn't have to create 100 of these in both places.

+ +

And then some people will be like you might be thinking, well, now I have duplication. I have duplication in some of my API endpoints and my web endpoints, and that's true. I would say first that duplication isn't always a bad thing. I think more duplication in our web apps would actually probably lead -- I feel like we run away from duplication too quickly. I don't think duplication is as bad as software developers often think it is. But even then, if with the duplication you can't live with yourself, there are still ways to solve duplication. So Laravel, for instance, has this concept of they're called API resources, which is basically they're essentially transformers. You give it some models, and it transforms that model into some other states, some other design. So there's nothing stopping you. And I even did this myself within my server-side application within Laravel to have an API resource to have a transformer that's used by both my Inertia controller and my API controller in a couple of situations and for me, only when it makes sense. I'm not going to do it all the time because I found that most often, I wanted the data in a slightly different format in my native apps than I'd want it into my web app. So quite often, that didn't happen. But I'm just saying if you're scared of duplication, there are totally ways to solve it. And we can solve this in our existing frameworks. Laravel or Rails has ways to allow us to abstract some of that stuff and reuse it in multiple places. So, yeah, that's my long-winded answer to how I've approached doing the native apps sort of thing. I think that tight coupling between the data and the screen I think that's a really nice thing, and you just can build faster. And just like you can build faster with Inertia on the website, you can build fast [inaudible 43:19]

+ +

CHRIS: Frankly, that answer makes a ton of sense one and two, makes me feel better about the path that I'm on because, again, I'm really desperate to cling to Inertia for the web side of things. So I love what you're saying. And again, it really resonates with me and how you're thinking about building. There's also I really appreciate a subtle common theme that I've seen in a bunch of things that you've said where you're like; let me poke at best practices a bit and see what falls out. What if we were to actually embrace the coupling between our data and our view layer? And it's like, actually some really nice things happen there. And actually, going back to an earlier project that you worked on, Tailwind CSS is one of those projects that when you first see it, you're like, well, that's obviously wrong. That's definitely an incorrect way to do things. But then you explore it, and you're like, well, I mean, I know there are trade-offs here, but actually, in my experience and I'm sure in your experience, Tailwind is absolutely fantastic. And the trade-offs you totally win in the long game, and it's maintainable, and it's understandable. And you can continue to develop on top of it in a way that I've never found with any other CSS framework. But again, at first glance, you're like, ooh, that's not right. That can't be right.

+ +

JONATHAN: 100%, exactly. I think it's fun to push back and just experiment with different things. And for me, I think a lot of my decisions, too, come back to the fact that I'm running a SaaS application as one person, and I need to be able to move fast. I don't want to have two different servers and two different repos. I want to be able to build my applications as fast as I can, as a single developer, a single founder. And so I think the things that I push against and try and experiment with come out of me trying to find the simplest ways to maintain things. So Tailwind, that's really Adam's brainchild. I came along in the first six months or so; me and him built it. I was really just helping him flesh out his idea there, and that was super fun. But yeah, I had the exact same experience as you. Adam was telling me about this, and I'm like, that sounds pretty terrible. Like, I have CSS figured out already. And then it was like, oh man, this is amazing. Fun little fact, my SaaS app, me and him, were both working on web apps at that time. So my SaaS app was one of the first Tailwind applications ever because I and Adam were literally both building our own apps while building Tailwind CSS.

+ +

But anyway, so yeah, it comes out of not me trying to be like, I know better than other people; it's not that at all. It's more just I'm trying to find a way to survive as a business and trying to build at the same time, not only survive but also I want to build awesome products. I don't want to build software that is just kind of okay. I love striving to make software that's just exceptional that delights people that works the way someone expects it to work. And I just think that there's so much broken software out there. There's a lot of bad software. And don't get me wrong, I've created a lot of bad software, too. But I really try to hold myself to a high standard. And really, for me, that comes down to not necessarily what some purist says that “This is how you need to do it.” It comes more down to like, okay, let me see the results. How fast does the webpage open? What's the performance? You mentioned my course earlier. I’m really, really interested in database performance and how to use databases more intelligently to deliver really fast web applications. And that matters to me because customers hate waiting. They hate it. And that was even part of what drove me to create Inertia because I hated this. I was working for a company, and we had built the right way where we have an API and the client separate And we went down that road. And that was a big team with 20 to 30 developers in the end. And I was just like -- I shouldn't say, “I was,” but we, in general, were not happy with what happened because just the way that the app was built and the way that single views were hitting the API. You could probably argue that this was like we were doing something wrong, but the paradigm didn't lend us to doing it right, in my opinion. So we'd have pages that were hitting the REST API with sometimes 10, 20 HTTP requests just to get the data. And you're dealing with all the loading states of all this stuff. And of course, there were probably better ways to design, but we were trying to ship a product there too. We were trying to get it out the door and make happy customers. And I didn't feel like that way was helping us.

+ +

I think GraphQL, just as an aside, is a huge step forward where you can say, “Hey, here's all my data in an API, but I'm not going to hit the user's endpoint just to get back whatever you decide to give me.” I can be much more intentional about saying, “Hey, I want this data and then pull in this relationship for that data and this other piece of data.” And I think that's really, really cool. But I think the problem there again is you need to build that GraphQL API, and that's non-trivial, not to mention you probably have to figure out OAuth, which is pretty much always a game-stopper for me because if I never have to work with OAuth in my life [laughs] I'll be totally okay with that. I know it has its place, but yeah.

+ +

CHRIS: There's a clear passion and a desire that you're describing there to just build good things and the belief that it can be done. And then, as someone who has really benefited from your work, I thank you for carrying that torch and for pushing the envelope. And like you said, having that high standard and holding yourself to it but then hopefully bringing the rest of us along, and I really appreciate that. But I think with that, that's probably a perfect time to wrap up. If folks want to follow more of what you are working on, where can they find what you're up to on the internet?

+ +

JONATHAN: I'm on Twitter, the classic place to go for following someone in tech, so twitter.com/reinink, my last name. That's R-E-I-N-I-N-K. So that's where even if I have stuff shared elsewhere on the web, that's where it starts.

+ +

CHRIS: Perfect. We'll include links to your Twitter as well as everything else that we've mentioned in this episode in the show notes. So folks that do want to keep up or investigate further listening to that other podcast episode that I mentioned will have all of that available. But with that, thank you so much for your time, and yeah, again, really appreciate you joining.

+ +

JONATHAN: Thanks so much, Chris. Pleasure to be here.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. If you have any feedback for this or any of our other episodes, you can reach us at _bikeshed on Twitter. Or you can reach me @christoomey, or you can e-mail hosts@bikeshed.fm. Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + + This week Steph's taking a quick break, but while she's off, Chris is joined by a special guest - Jonathan Reinink. Jonathan is the creator of Inertia.js. Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers, and listeners of the show will certainly have heard Chris rave about it on previous episodes.

+ +

Chris and Jonathan dig into what makes Inertia unique as compared to frameworks like Phoenix LiveView, Laravel Livewire, and Rails' Hotwire & Turbo. They also discuss how Inertia embraces the URL, the unique "protocol" nature of Inertia, and how to consider Inertia alongside native mobile applications. Throughout the conversation, Jonathan's consistent philosophy of wanting to build robust, performant, and delightful applications shines through.

+ + + +

Transcript:

+ +

CHRIS TOOMEY: I am seeing what I believe to be the relevant things.

+ +

JONATHAN REINIK: Let's dance.

+ +

CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. And this week, Steph is taking a quick break, but while she's away, I'm joined by a special guest, Jonathan Reinik. Jonathan Reinik is the creator of Inertia.js. And listeners of the show will know that that is increasingly one of my favorite frameworks and, frankly, just ways to build applications on the internet. Jonathan is also the creator of the Eloquent Performance Patterns course, which teaches the Eloquent ORM, which is the ORM in Laravel but really digs into deep performance and database things, so really covering that back end as well. Jonathan also collaborated on the development of Tailwind CSS, a utility-first CSS framework which again is something that I have spoken of in very high terms on this podcast. And lastly, Jonathan currently runs his own SaaS business called Church Social. So really, Jonathan is a bit of a quadruple threat covering back end and front end design and entrepreneurship. So pretty much everything you want to see. And frankly, I've been so impressed by the breadth and the depth of Jonathan's work and just the deep way that he is thinking about building applications. So I am absolutely thrilled to have him on the show today. So without further ado, Jonathan, thank you so much for joining me.

+ +

JONATHAN: Thanks so much, Chris. That was a very kind introduction, and yeah, it's awesome to be on The Bike Shed. I've been a long-time listener, and as I've said to you, I really appreciate the support that you've given to my work over the years. So yeah, it's awesome to be here.

+ +

CHRIS: That's interesting. We're measuring it in years now, but it's a very sincere thing for me. I think with Inertia, you've built something that is both very unique and a special approach to how we build things, but it's also built from very familiar pieces and allows us to reuse the deep amounts of knowledge that we have in the Rails community or the Laravel community. But actually backing up just a little bit, because we're going to dive deep on Inertia.js today, for folks that are not as familiar or have only heard me mention it in passing, there's a wonderful episode of Full Stack Radio where Jonathan and Adam Wathan talked about Inertia.js, and I think gave a very good foundational summary. So we'll link to that in the show notes in case anyone wants to dig in a little bit more. Likewise, Jonathan has a really fantastic blog post called Server-side Apps With Client-side Rendering, which, as far as I can tell, is the manifesto that began this whole journey for you. And I really love that you have done so much of the work in public, and people can see the history of how this idea has evolved and really crystallized into what now is a very production-ready framework in sort of the way to build things. But I would love to hear right now just for anyone who is not as familiar and also just to hear how you summarize it at this point in time. What does your introductory elevator pitch for Inertia.js sound like in April 2021?

+ +

JONATHAN: That's a great question. So it's hard to answer this without unpacking a lot of different things. And you mentioned the podcast with Adam; I think that's good because it goes in a lot of the technical detail of how Inertia works and why I created it. But the elevator pitch these days for when I talk to someone about it, it's generally I explain it as a way of building modern web apps. And in particular, when I say modern, I mean web apps that have a lot of JavaScript, so frameworks like Vue or React or Svelte, so applications that are built using those tools. And the key thing that Inertia offers is for you to develop these modern applications without having to first build an API sort of the way historically if you ever wanted to use one of these modern web stacks like Vue or React or Svelte, you could use them within Laravel or Rails by inserting them into your Vue or into your Blade templates or your ERB templates. But it was difficult if you ever wanted to turn it into a legitimate single-page application. And anytime you would ask that question, if you go out on the internet and say, “Hey, how do I build SPA with, say, Vue and Laravel or React and Rails?” The answer was always, “Well, you need to build an API. You need to build an API.” That was always the missing piece because that's the way that everyone in the Jamstack era that we're in that's the way that everyone's building their applications that are like these heavy client-side applications.

+ +

And I totally get the need for those style apps and the place for those style apps. But I really missed this way that you could build an application with Rails or with Laravel where you could just literally spin up a new app, create some routes within your server-side framework, create some controllers, create some views, and have a working application within minutes really. You could have something being displayed on the screen within minutes with these classic monolith applications. And if you wanted to do the same thing, if you wanted to get an app up and running in minutes with Vue or React as your completely client-side SPA scenario, it just wasn't working because as soon as you say, “Well, in order to do that, you're going to need to have a back end Rails or a Lavarel application, and then a client-side Vue or React application. And then you're going to have to create this API that connects the two together.” There's just a lot more work that goes into that. It's not only the work of actually creating the API; I find a lot of the decisions that come along with building an API; it’s like, okay, what does the abstraction look like? Am I going to build it with REST, or am I going to build it as a GraphQL API? And all the decisions that come along with designing and architecting that which again has its place. But there's just something awesome about saying, “Here's a new route. Here's the view that I want to render. And here's the data that I want that view to have,” and just go off and do it, and it's done.

+ +

And some people ask me, “Well, with Inertia, if you're not building an API, what happens someday if you need an API?” And they frame it like, well, this is a terrible decision. You should be starting with an API. But for me, the reality is that so many of the web applications that I was building and that I've seen other people building is they had already made the decision not to use an API because they had already made the decision that they wanted to use Laravel as a monolith app that had their controllers and the routes and their views all within that and the same thing with Rails. So if you've made that decision to build a monolith app with Laravel or Rails, you've already made the decision to not build it with an API. I was coming in from the other way. It's like, I just want to build an app the way I've always built in Laravel, and I don't want to have to build this API. Of course, there are times where you do need an API, which I think we're going to talk about maybe a little bit later if I don't ramble on too long, where it does make sense to have an API. But yeah, that's kind of the elevator pitch.

+ +

I think maybe to close off that thought is that I really, really enjoy having a tight coupling between my routes and my data layer and my views, which, again, I appreciate that. That probably sounds like blasphemy in modern web development. But for me, I think it's so empowering when you say, “Hey, I have a controller that's given me some data, and I have a view that's rendering the data, and those two know about each other, and those two depend on each other.” You can work so fast because I'm not thinking, okay, well, I have this API endpoint that returns a user, and that has their first name and their last name and their email. But I also need to think about it in the situation in the future where I might need this attribute or that attribute or some other attribute and make sure I have all that figured out ahead of time or at least have a way to add it in later. And all of that thinking that goes into designing an API, I find that that adds a lot of overhead.

+ +

And then maybe related to that also is the amount of times that you're rendering a view within your application that needs data from multiple different places. And to me, this is like one of the huge performance benefits that you get with a tool like Inertia is with, say a REST API, GraphQl solves this, but with a REST API, you're often getting too much data for what you actually need for the page, or you're often making more than one HTTP request because you say, “Well, on this particular dashboard, I need some user information. So I have to hit the user endpoint. I need maybe the latest product sales data, so I need to hit that endpoint.” And you’re dealing with these performance issues that you get with a REST API that with Inertia, you don't have that problem because it's just going back to classic Laravel Blade views or Rails and ERB templates. Am I saying that right, ERB template?

+ +

CHRIS: Mm-hmm.

+ +

JONATHAN: In those situations, you say, “Well, if I need data from three different places, well, I'll just grab data from three different places and send it to the view, and that's fine. And I can do that in the most efficient way and get the data that I need specifically for that view.” So anyway, that's some of the thinking that drove me to build Inertia and some of the things that I was going for. And yeah, it was an evolution. It really came out of me using Turbolinks and really appreciating what Turbolinks gave me but taking it to that next step where it's like Turbolinks, except it's built with the same principles as Turbolinks but built for modern client-side frameworks like Vue and React.

+ +

CHRIS: Yeah, that all feels very familiar to me. And in my experience, I've now worked with Inertia on a handful of projects, but in particular, I have just a small personal app that I use to manage different aspects of my life. And it's been my playground for different technologies. And I've migrated it through a bunch of different versions where it used to just be a Rails app. And I was like, oh no, the thing that I need to do to be on the cutting edge is to turn this into -- it's a Rails app on the back end with an API, and then it's a React app. It's separately deployed, but those two talk to each other. And what you were talking about of the deep coupling, I think that coupling exists whether we want it to or not. And so embracing that and revisiting when I eventually migrated that application to use Inertia and the client-side stuff folded back into the core codebase. Now deployments all go out in sync. And that turns out to actually be a really nice thing and a non-trivial thing to solve otherwise.

+ +

As a developer of one on this particular project, the amount of complexity that was removed from the app when I switched it over to Inertia was amazing. I got to remove client-side routing. I got to remove client-side state management, which I think I was using Redux at the time. I got to remove some form helpers that I had. I think I might've been using Formik or React Use Former, any of those. But there are so many different little pieces that you ended up cobbling together to make an application. And it was amazing to me as I moved to Inertia, where I was like; actually, I don't need any of those, and routes suddenly are defined in one place in Rails in a familiar way. But things like redirects all work -- It feels just like a Rails app but with the extra abilities that a front-end client-side framework gives you when you want those when you need those. But otherwise, it really does feel like I'm rendering to an ERB template. It just happens to be that that template is rendering on the client-side and is written in React or Svelte or whatever the front-end framework is. But it almost feels like progressive enhancement. I'm borrowing a term, and it's not actually applicable here, but it really feels like that. It's like, oh, it's a Rails app, but I just want to make it a little bit fancier, and Inertia does that in such a fantastic way.

+ +

And actually pivoting just a bit, as far as I can tell, there seems to be an explosion of thinking in this space. There are a handful of frameworks, namely Laravel Livewire, which is often paired with Alpine.js. Elixir has Phoenix LiveView, and then Rails has the Hotwire suite, which Turbo and Stimulus are the most pointed considerations. But interestingly, I think all of those frameworks, which I think are trying to provide a very similar experience, tend to keep things on the server-side, so using the Laravel Blade templates or the ERB in Rails. But you've taken the different approach to say, “No, let's embrace this front-end technology where it makes sense.” And again, there are a lot of pieces that can fall in, and I don't need the Redux and the React Router and all of those things but still use that client-side framework to be the rendering engine. And so I'm intrigued if you can talk a little bit more about that and that trade-off because I think it really differentiates Inertia and its approach. I personally found it to be fantastic, but I'd love to hear a little bit more about your thinking on that.

+ +

JONATHAN: The thing about modern websites and web apps, in particular, is it doesn't matter how you slice it; we need JavaScript. So if you disagree with me there, then everything I say from this point on will not make sense to you. But I think we can all agree that modern web apps need JavaScript. JavaScript is the programming language of the web of the browser that allows us to do whatever magical things that we want to do. And if you look at tools like Phoenix LiveView, Laravel Livewire, and even the new Turbo stuff from the folks over at Basecamp, they all are embracing JavaScript in the same way. It's just they're framing it in a different way. I would say, especially with Livewire and LiveView, they're almost creating like an abstraction between the server and the way you write things on the server and the client-side. And they're almost hiding the JavaScript, which is really, really cool. I think it's such an interesting thing to try to do where somebody who's not familiar with JavaScript and not familiar with Vue, React, and Svelte can go and do things, write server-side code that gets rendered server-side. And then there's some JavaScript that these libraries insert that allow you to do more interesting things, whatever those things might be, show a drop-down, or drag and drop or validate a form or submit a form without actually submitting it fully to the server but submit it over XHR instead, all these kinds of things. But the point is they're embracing JavaScript just in a different way. And same with Turbo, Turbo gives you a way to write JavaScript for an application that mostly has server-side rendered HTML.

+ +

So I think it's important to just recognize that JavaScript is key in all these frameworks. With Inertia, it's the same idea in that Inertia wants to embrace that classic way of building applications using the classic server-side monolith application framework like Laravel or Rails. But the difference is it acknowledges or embraces these existing client-side frameworks that have really grown in popularity. And the three, again, I keep mentioning them, Vue, React, or Svelte. Svelte being an up-and-coming one that's not nearly as popular yet, but it seems to be gaining a lot of steam.

+ +

CHRIS: It's on the rise. That’s my long [inaudible 14:46]

+ +

JONATHAN: Yes, and people keep saying that. So anyway, Inertia basically said, “Hey, we want to keep building server-side apps. We want to keep building monolith apps similar to these other tools, except what we're going to do is we're going to embrace the fact that there's this really, really amazing tooling that's been developed for the client-side.” And it just doubles down on that. So for me, the reason that I ended up here was because, in my own SaaS application, it was a Laravel application that started with mostly Blade views initially. And then, over the years of building it, which has been many, many years, I've slowly added more and more Vue components within my app. And initially, the way I did it is those Vue components would just be inserted in as regular HTML tags in my server-side rendered templates. And then, when the page renders, those Vue components would boot up and do whatever they need to do. So for me, when I was building Inertia, I had already fallen in love with Vue, in particular, and having all the power of these client-side frameworks. And there is so much there. It's not just Vue, React, and Svelte; it's all the amazing tooling that's available out there that you can add on top of it.

+ +

And this is the thing I often tell people that Inertia isn’t -- we say right on the homepage, “Inertia isn't a framework.” And the reason why I say that is because I don't want people to think of Inertia as an alternative to Vue, React, and Svelte. Do you know what is a better way to frame it? It's actually more of an alternative to React Router or Vue Router; that's really more what it is, where you can say, “All my routings are handled server-side,” and that has all kinds of interesting implications. But it's more of a router, and it just so happens to pass along that routing control over to the server. Anyway, so that's really for me what differentiates Inertia from those other tools is because it's really doubled down on these client-side frameworks.

+ +

And I think the reason why Inertia has been relatively popular is because people know Vue and people know React. And when it comes to then working with Inertia, it's not some new thing that they have to learn. It's an existing set of tools that they're already super comfortable with. And in so many ways, when you're building an Inertia app, you're kind of building a classic Vue app or a classic React app or a classic Svelte app. It's just there's a bunch of pieces missing. Like you said, it's like a bunch of the client-side state management stuff, which nobody likes anyway, is gone. The other thing that's gone is client-side routing. You don't have this back-end routing is over here now, and client-side routing is over here, and I have two different routing definitions. It's like, no, that's all just server-side now in one place.

+ +

The other amazing thing you get is you mentioned redirects and that whole HTTP layer you get just along with Inertia for free because it's just part of your server-side stack. And one key aspect of that is auth. You can just use good old-fashioned nothing is better than session auth. Like, it just works. And, so whatever your typical solution for doing session auth in Laravel or Rails or whatever server-side framework you're using, all this stuff just works. So anyway, coming full circle on your question, the reason why Inertia has gone this way is because I really think that there's a huge amount of value with using these modern frameworks. And we just doubled down on using them.

+ +

CHRIS: Yeah, that resonates with my experiences using Inertia and in contrast to the other frameworks. Everyone seems to be trying to get to the same place of providing a mechanism to have more almost app-like functionality but still using the traditional server-side technologies. But I think Inertia has chosen an approach to that that is unique in that category and really has provided a fantastic outcome. I've been very frankly surprised by the fidelity of experience and how app-like I can get something to feel when building with Inertia while still using all the same technologies. And the fact that I can use just traditional server-side auth and redirects and things like that is just so nice, and everything feels right.

+ +

There's an experience that I've had on many applications that are, say, a React client-side bundle that gets sent down and then boots up, and then the layout starts to render. And as its data fetching, it gets like a 402 response or something like that in that data fetching. And then it's like, oh no, I need to hard redirect you over here on the client-side to this other page. And there's this junk of semi-filled-out layout, and then suddenly you're on the login page. And again, with Inertia, it looks like a normal server-side rendered app, but it isn't in the ways that really matter to us. And it is one of those things where the more I played with it, the more there's an experience of interacting with Inertia that it surprises me consistently how nice it is to work with it and yet it's so much easier to maintain an application using it. I know I'm raving here, but I am really a big fan of this for everyone listening in the audience.

+ +

JONATHAN: [laughs]

+ +

CHRIS: And actually to continue on one of the things you were saying there, one of the things that stands out to me in Inertia is the way that it embraces URLs and to a certain degree, that seems like a purposeful thing, but it also seems like it just naturally falls out of how Inertia works because we're no longer using a client-side state management technology, the way to manipulate state is through the URL. If you want to see a different version of the to-do list you're looking at when you click on that link, you change the URL and the state changes in response to that. And so everything is fundamentally kept in sync, but URLs are very much at the center of the architecture, and I really love that so much. I think URLs are often forgotten in client-side frameworks or underserved or underused. And it turns out in my experience as a user and both having served many users, people love to command-click on links. They love to right-click open a new tab. They love to be able to reload and see the same thing on the screen when they reload the page. They love to be able to bookmark. These are all really wonderful things that come out of working on the web. And the fact that Inertia has a pit of success around having URLs and have that be the way that we drive state is just so fantastic. So I'm wondering how much of that was very purposeful on your part versus how much of that fell out of the architecture.

+ +

JONATHAN: That is very much something that fell out of the architecture. I say that not to say that I don't value URLs; I absolutely did. That's the way every single one of my Laravel built apps worked. It always starts in the route file. You hit the route file, you define a new route, and it goes from there. So I absolutely think that the URLs are critical. But the fact that it just ended up working out so nicely was, yeah, I'm going to say it was a bit of luck, a bit of coincidence. I find this is what's so interesting when you start pushing on a new way of things; you initially don't really know where it's going to end. It’s like you have some ideas of how the tool can work and where it might go, but I think there's a lot of unknowns that you just figure out after a while. So the thing I said earlier actually about the fact that Inertia in a lot of ways is like a client-side router; it’s, it's a routing library, to put it that way. I had been working on Inertia for a year and a half, and then a buddy of mine, Taylor Otwell, the creator of Laravel, he and I were chatting, and he said to me at one point he's like, “Oh, you know what? Inertia is actually super simple. It's really just a routing library.” And it was like, bam. It was kind of that moment; it’s like, oh yeah, I hadn't thought of it like that at all. But when he said that, it made a ton of sense to me. So it's just this interesting progression the more you work on something, and the more you push on the edges, you learn what's possible and what it even is.

+ +

I had this interesting experience, so remembering that Inertia came from Turbolinks. So I had my whole app built with Laravel ton of server-side rendered templates with Blade with view mixed in. And I had the SPA mode by clicking around using Turbolinks. So when I decided to try building Inertia, I removed Turbolinks, and all these requests now happened over XHR but using this preset JSON structure that powers Inertia. I really, in my mind, had this idea that it was only for GET requests, for GET visits; it was just for that. So the initial version of Inertia, there was no Inertia.post or Inertia.put or anything like that. It just wasn't something I even thought was possible. But then I remember, and this is often how it goes; I was out for a hike that day to get away from the computer for a little while and just let your brain drift; I'm sure you can relate to that. I was like, wait a minute; I could totally just support POST, PUT, PATCH, DELETE. And that was such an aha moment for me where I just realized that it was so much more than what I originally thought it was.

+ +

And then the whole thing from that I remember it was a bit of like a waterfall effect after that where I remember running home out on that hike and hacked it together, and then it was like, okay, well, if I submit a form using POST, well, okay, I'm on the create user page. And I submit this form using Inertia.post to the user's endpoint. I'm like, well, how do I now end up back at the user index page or whatever page, maybe the user edit page. I’m like, wait a minute, I can just return a redirect back to the user index page, and it's literally going to return an Inertia response from the user index page. And then the way Inertia works is it dynamically swaps the page component client-side. And it was just like, oh, this is way too cool. And this really drives my thinking now that it's become a little bit more clear to me is that it really it's all based on HTTP using headers and normal HTTP stuff like redirects are such a critical piece of the story. But to me, that's super neat that, in a way, it's like a throwback to the fundamentals of the web and the browser and the fact that Inertia can just use those things,,, and it doesn't have to be fancy in a lot of the ways. It can just rely on those existing core pieces of the browser. So, yeah.

+ +

CHRIS: It really is interesting to me how it feels like progressive enhancement in that way where you're building on top of these core fundamentals of HTTP and requests and redirects and status codes and things of that nature. Particularly interesting to me was it took me a while, I'm going to be honest, to figure out forms and particularly validation errors in Inertia. And that is entirely my fault. You have absolutely fantastic documentation. I am so impressed by the quality and the density of the documentation that you have that really covers everything. If we're being honest, I hadn't read the page, but I was doing form posting and then the subsequent errors and how you deal with that. I was doing it in a very traditional Rails way which if we're being honest, that is not a fundamental of how HTTP works. Rails just chose an option of oh, if you POST but we don't create the object because there's a validation error, then we're going to stay on the URL of the POST, so the collection route, but we're going to re-render the form in line. And that's a choice that Rails made that is interesting because at that point, if a user reloads the page, then things are weird, and it's not going to reload. They're not going to see the same thing after that reload, or it's going to try to repost or et cetera, et cetera. There's a bunch of edge cases there that sort of fall out. Whereas with Inertia, you end up redirecting back, and there's this interesting handshake of the errors, but from an end-user experience, it is absolutely fantastic where you stay on the form; the URL does not change. Technically, there's a POST and a redirect back under the hood, but Inertia just handles all of that for you. And you end up with sort of in-line validation errors. But you don't clear out any fields, and there are just wonderful things that fall out of it that again took me a while to get there, but it was another one of those oh, wow, this just naturally falls out of the architecture, but it's so nice and such a nice incremental advance on top of frankly, the stuff that I was doing in Rails historically.

+ +

JONATHAN: So the way that Laravel works and it's always worked this way is when you make a request using POST or PATCH or DELETE or whatever to an endpoint, and that endpoint does its validation in the event that that validation fails, this is just like built-in standard like Laravel Stock behavior. It automatically redirects you back to the endpoint that you were on. So if you're on the create page or the edit page, it automatically redirects. That's just Laravel behavior. And what it does is it takes those errors that come out of the validator, it flashes them to the session, and then when the forum page reloads, you have those errors available to you in the session. Now, of course, if you're building like a classic server-side rendered application and you redirect now back to your form, you have to repopulate old form inputs, which is not a lot of fun, which you don't have any of that stuff with Inertia because Inertia allows you to preserve your state. But anyway, that's a separate thing. But for me, it’s like you build a tool a little bit like in your own silo and the world that you know, and for me, that's Laravel. But there are also ideas that you get that just come from the tooling that you use, and the fact that Taylor Otwell made that decision in Laravel at one point is absolutely what now dictates how is the go-to way to do it in Inertia, just because it works so nicely.

+ +

CHRIS: I wonder if there's been any consideration in the Rails world to adopt that because I think from an experience perspective, it feels like it's a better thing. It feels like it has the same robustness and guarantees that I would expect. But yeah, that's interesting. It makes sense that that was just naturally there because, again, it didn't feel like the obvious correct thing that Rails was doing. It was always a little bit odd and so interesting that Laravel was already there. But then Inertia can take it that one step further. But taking a slightly higher level view of all of this, one of the things that's really interesting about Inertia to me, especially in contrast to some of the other frameworks that we've been talking about like the Livewires in the LiveViews is Inertia is almost at its core a protocol more than it is…it's a sum of pieces, and with Inertia, you have a server-side adapter, so there's the Rails adapter and the Laravel adapter. And then, on the client-side, you have a separate either Vue or React or Svelte. So those are the officially supported ones on both sides, but there's also been a swell of community support. And so there's a Django one, which I'm not sure if it's currently maintained, but I just saw a Clojure one the other day. There's a Java Spring Boot. So those are all server-side adapters. I haven't seen as much on the client-side, but I imagine there are at least a handful of them out there. And it's so interesting to me that there's this core idea that you define this protocol of communicating back and forth from the server to the client and now this collection of things that are growing around that. And I wonder again, how much was that purposeful versus how much did that just happen? And then further to add a second question to complicate things, how are you thinking about managing that community? Because my sense is that this could allow for Inertia to be so much of a bigger tent and really bring in the best ideas from all of these different communities and end up with something at the core of this Inertia thing that is the best of every community and all of that. So yeah, a lot of questions there, but I'll hand it over to you because I'm super interested.

+ +

JONATHAN: So I think when I first got going, it was Laravel and Vue; those were the tools that I worked with. And often, the best software and the best open-source software in my mind comes out of trying to solve something for your own needs. So that's really where Inertia came from and specifically for Laravel and Vue. But I quickly realized early on that it didn't have to be just a Vue and Laravel thing. So intentionally early on, I had this idea of trying to build it with multiple adapters, and I had this idea that you could build as many server-side adapters as you want and as many client-side adapters as you want, and maybe we'll officially maintain a certain amount of those, which is what we do right now. We officially maintain the Vue, the React, the Svelte adapters. And then, we also maintain officially the Laravel and the Rails server-side adapters. So that was, I would say, pretty intentional. And it's crazy how many server-side adapters people have been able to put together. Somebody wrote a ColdFusion server-side adapter for Inertia. I had no idea ColdFusion was even a thing anymore; yeah, legit. There are node ones; there are Phoenix ones; if you can believe it, there's a WordPress one, which I'm not even totally sure even how that works. There is ASP.NET.

+ +

CHRIS: [chuckles]

+ +

JONATHAN: Like, there's a whole bunch of them. And it's actually despite of me, not because of me, that this has happened because I am yet to write a good here's how to build an Inertia server-side adapter in the language and framework of your choice guide. It's been on my to-do list. I have a bunch of things I want to do. So it's still something I want to write, but people what they're doing is they're just reverse engineering what we're doing in Laravel and Rails and these other adapters, and they're figuring out how to do it in their own server-side language and framework. So that's been really, really cool.

+ +

On the flip side, on the client side, I'm starting to realize more and more that that's actually where the most important work for us as the maintainers of Inertia that we need to focus our efforts on because it's non-trivial to create these client-side adapters. And for us, we actually have four of them now because we have React and Svelte, but then we have Vue 2 and Vue 3. And they're different enough those frameworks that we actually had to create a separate adapter. So that's really where all our work is. The core of Inertia is actually ridiculously short, like the whole file, like the whole core Inertia adapter is 150 to 200 lines of code. And maybe it's a bit more than that, but it was that for a long time. It might be 300 or 400 now. It's very short. Even honestly, the client-side adapters are pretty short too. It's just that it's more difficult to make these client-side adapters because you get to learn all the intricacies of how each one of these frameworks handles their rendering. The core behavior that Inertia uses is the fact that you can dynamically swap components. So we dynamically swap page components when you visit from one page to the next and the details that come along with that.

+ +

Anyway, so I’ve realized that moving forward, my job is going to be to make sure that the client-side adapters are awesome and then letting the community drive the server-side adapters a little bit more and providing some better guides on how to do that. But yeah, for now, it’s like if we can get it working in Laravel and Rails, we should be able to get that functionality working in any server-side adapter. And because it's all again just based on HTTP, that's the language, that's the protocol like you say. That's the thing that matters between all these web frameworks, which they all, of course, support since they’re web frameworks.

+ +

CHRIS: I think you're not giving yourself nearly enough credit for the support that you've given to the server-side frameworks because you do actually have a page in the documentation called the protocol that does a great job of at least summarizing it at that HTTP level. But at the end of the day, again, like the job of someone implementing it is to then map that into their given language and framework of choice. But yeah, the documentation is impressive in just how much you put in there and how much care you obviously put into it and lots of nice, subtle details that are covered very well in that. So that again, if you read it, unlike me, then you get to know everything; eventually, I got there. I think I've read the whole thing now. But there's a lot there, and you cover all of the details.

+ +

But actually looping back to a topic that you hinted at earlier, but this is something that I've been pressing up against lately is I absolutely love building web apps in Inertia, but there's often the need to bring in a mobile app, and we want native mobile for various reasons. I love the idea of progressive web apps, and I want to push that envelope as much as I can. But as an example, right now, iOS does not support push notifications to PWA. So if that's a key feature that we want, then we're dead in the water or if there are certain GPS things. There are a bunch of true platform native things that we just can't get. And so I'm now contemplating building out an app alongside my Inertia web stuff, but I want to build a React Native app, and I'm wondering, to a certain degree, does this invalidate some of my ideas? I know you hinted at this earlier, but I think I'm still convinced of the utility of Inertia on the web. But I think I need a different paradigm to build for a mobile app, and I'm trying to decide where that line falls. I'm also wondering if I can just get away with embedding a bunch of web views and reusing my web logic because, again, if I'm building all of this, I'm going to build it in a mobile responsive way. I don't want to rebuild the core page functionality of my app just to put it on mobile. Maybe mobile folks would tell me I'm wrong there, but I'm interested in maybe wrapping it and getting access to those platform features. But yeah, I'm interested in what your thoughts are there.

+ +

JONATHAN: Well, embedding a web view within a native app has been proven to work just as DHH, obviously. But yeah, there are definitely people who disagree with that approach and feel like you should build a legitimately native app. Let's say that we're going to legitimately build a real native app. We want to have an Android and iOS app. So I actually ran into this myself for my own SaaS application, and I solved it by building a native app using React Native so React Native obviously being an abstraction on top of iOS and Android and all the tooling there, which is such an amazing platform. It was just a real joy to work with. And I don't even hardly work with React, and I was able to get a nice, high-quality native feeling app built relatively easily. But I had to come to grips with this very question because, like I've been saying all along like, “Inertia is great because you don't need to build an API. Yay, this is amazing. This is what you should do. Oh, crap. I need an API.” And I had those questions like, okay, well, does this invalidate everything that I've been doing? So I was thinking about it, and in the end, what I did is I just built a light API alongside my Inertia application. So what it is is I think I have seven endpoints, and they're just REST endpoints that are designed specifically for my native app. And this works honestly so well.

+ +

And I think I've explained to you a little bit in a previous conversation, so I'll repeat myself a little bit here for the benefit of the listeners. The reason why I think it's completely legitimate to have Inertia and build your entire web app that way and then have a companion API alongside it in the same monolith app (let's be clear: it's in the same application. It's in my Laravel app, or it would be in your Rails application) is because it just extends a core principle for me of what Inertia is. And that core principle is a tight coupling between my data layer so my controllers, and my views. So if we take that thinking where we say, well, Inertia in an Inertia web app when we have an endpoint, we hit the controller, we load data from the database, we pass that very specific data to the view, which is Vue or React or Svelte and it renders it. And there's a very tight coupling between the two. And I treated my native app in the exact same way. I said, “Okay, I need an API because obviously, the native app on iOS and Android has to make an HTTP request to get this data somehow. But instead of trying to create this super generalized API that could theoretically be used for anything, I use the same principle that said I'm going to allow myself to create an API that has a really tight coupling between the screens in my native apps and the actual data that's coming from those API endpoints.

+ +

And this worked out really, really, really well. I don't have to deal with a lot of the issues that you run into when trying to create a more generalized API because I could just say, “Hey, I have this calendar page, and I want that calendar page in my particular app. I want it to show people's birthdays, and I want it to show wedding anniversaries, and I want it to show custom events and these things that we have called schedule reminders.” So it’s data from four different endpoints. I didn't try to say, “Well, I'm going to go and create now my event’s endpoint, and my birthday's endpoint, and my anniversary's endpoint, and my schedule reminder’s endpoint,” and now have all that work to do in my native app to okay, we'll hit all these different endpoints and merge it all together; it wasn't like that at all. I created a calendar endpoint that returned all the data that's needed for that screen. And I basically applied that thinking through my whole native app, and it was really a joy to work this way. So I think that approach works really well if you have an app that doesn't have complete feature parity with your web app.

+ +

And I think if you had a native app that needed absolute feature parity between the native app and the web app, then my thinking might be a little bit different on this. But in my experience, so often, native apps have a vastly reduced subset of the features that the web app has in particular, even if not for the core functionality of the application but just for the administrative side of it. There's a whole bunch of stuff that you tend to have in a web app around administrative stuff that you literally never need. And I mean administrative both in terms of it's a multi-tenant style app, which most apps are so in terms of the user's administrative functionality and in terms of the system level, the software owner administration. If you build your whole web app to be built on top of an API, all that administrative stuff that really doesn't need to exist in both places, you now have to make it exist in your API because you've made that decision to build it that way. Whereas if you just stick with Inertia on the web and just build it using that classic monolith way where you get data from the controls and send it to your Blade views or in this situation, client-side page views, and then you just expose the stuff that you actually need natively, for me personally, it's worked out so well. And if I look at my own web app, the amount of controllers that I have for the whole web app, I have like 100; it's a very big app. And for my native app, I have about 10. So that was like, I'm so glad that I didn't have to create 100 of these in both places.

+ +

And then some people will be like you might be thinking, well, now I have duplication. I have duplication in some of my API endpoints and my web endpoints, and that's true. I would say first that duplication isn't always a bad thing. I think more duplication in our web apps would actually probably lead -- I feel like we run away from duplication too quickly. I don't think duplication is as bad as software developers often think it is. But even then, if with the duplication you can't live with yourself, there are still ways to solve duplication. So Laravel, for instance, has this concept of they're called API resources, which is basically they're essentially transformers. You give it some models, and it transforms that model into some other states, some other design. So there's nothing stopping you. And I even did this myself within my server-side application within Laravel to have an API resource to have a transformer that's used by both my Inertia controller and my API controller in a couple of situations and for me, only when it makes sense. I'm not going to do it all the time because I found that most often, I wanted the data in a slightly different format in my native apps than I'd want it into my web app. So quite often, that didn't happen. But I'm just saying if you're scared of duplication, there are totally ways to solve it. And we can solve this in our existing frameworks. Laravel or Rails has ways to allow us to abstract some of that stuff and reuse it in multiple places. So, yeah, that's my long-winded answer to how I've approached doing the native apps sort of thing. I think that tight coupling between the data and the screen I think that's a really nice thing, and you just can build faster. And just like you can build faster with Inertia on the website, you can build fast [inaudible 43:19]

+ +

CHRIS: Frankly, that answer makes a ton of sense one and two, makes me feel better about the path that I'm on because, again, I'm really desperate to cling to Inertia for the web side of things. So I love what you're saying. And again, it really resonates with me and how you're thinking about building. There's also I really appreciate a subtle common theme that I've seen in a bunch of things that you've said where you're like; let me poke at best practices a bit and see what falls out. What if we were to actually embrace the coupling between our data and our view layer? And it's like, actually some really nice things happen there. And actually, going back to an earlier project that you worked on, Tailwind CSS is one of those projects that when you first see it, you're like, well, that's obviously wrong. That's definitely an incorrect way to do things. But then you explore it, and you're like, well, I mean, I know there are trade-offs here, but actually, in my experience and I'm sure in your experience, Tailwind is absolutely fantastic. And the trade-offs you totally win in the long game, and it's maintainable, and it's understandable. And you can continue to develop on top of it in a way that I've never found with any other CSS framework. But again, at first glance, you're like, ooh, that's not right. That can't be right.

+ +

JONATHAN: 100%, exactly. I think it's fun to push back and just experiment with different things. And for me, I think a lot of my decisions, too, come back to the fact that I'm running a SaaS application as one person, and I need to be able to move fast. I don't want to have two different servers and two different repos. I want to be able to build my applications as fast as I can, as a single developer, a single founder. And so I think the things that I push against and try and experiment with come out of me trying to find the simplest ways to maintain things. So Tailwind, that's really Adam's brainchild. I came along in the first six months or so; me and him built it. I was really just helping him flesh out his idea there, and that was super fun. But yeah, I had the exact same experience as you. Adam was telling me about this, and I'm like, that sounds pretty terrible. Like, I have CSS figured out already. And then it was like, oh man, this is amazing. Fun little fact, my SaaS app, me and him, were both working on web apps at that time. So my SaaS app was one of the first Tailwind applications ever because I and Adam were literally both building our own apps while building Tailwind CSS.

+ +

But anyway, so yeah, it comes out of not me trying to be like, I know better than other people; it's not that at all. It's more just I'm trying to find a way to survive as a business and trying to build at the same time, not only survive but also I want to build awesome products. I don't want to build software that is just kind of okay. I love striving to make software that's just exceptional that delights people that works the way someone expects it to work. And I just think that there's so much broken software out there. There's a lot of bad software. And don't get me wrong, I've created a lot of bad software, too. But I really try to hold myself to a high standard. And really, for me, that comes down to not necessarily what some purist says that “This is how you need to do it.” It comes more down to like, okay, let me see the results. How fast does the webpage open? What's the performance? You mentioned my course earlier. I’m really, really interested in database performance and how to use databases more intelligently to deliver really fast web applications. And that matters to me because customers hate waiting. They hate it. And that was even part of what drove me to create Inertia because I hated this. I was working for a company, and we had built the right way where we have an API and the client separate And we went down that road. And that was a big team with 20 to 30 developers in the end. And I was just like -- I shouldn't say, “I was,” but we, in general, were not happy with what happened because just the way that the app was built and the way that single views were hitting the API. You could probably argue that this was like we were doing something wrong, but the paradigm didn't lend us to doing it right, in my opinion. So we'd have pages that were hitting the REST API with sometimes 10, 20 HTTP requests just to get the data. And you're dealing with all the loading states of all this stuff. And of course, there were probably better ways to design, but we were trying to ship a product there too. We were trying to get it out the door and make happy customers. And I didn't feel like that way was helping us.

+ +

I think GraphQL, just as an aside, is a huge step forward where you can say, “Hey, here's all my data in an API, but I'm not going to hit the user's endpoint just to get back whatever you decide to give me.” I can be much more intentional about saying, “Hey, I want this data and then pull in this relationship for that data and this other piece of data.” And I think that's really, really cool. But I think the problem there again is you need to build that GraphQL API, and that's non-trivial, not to mention you probably have to figure out OAuth, which is pretty much always a game-stopper for me because if I never have to work with OAuth in my life [laughs] I'll be totally okay with that. I know it has its place, but yeah.

+ +

CHRIS: There's a clear passion and a desire that you're describing there to just build good things and the belief that it can be done. And then, as someone who has really benefited from your work, I thank you for carrying that torch and for pushing the envelope. And like you said, having that high standard and holding yourself to it but then hopefully bringing the rest of us along, and I really appreciate that. But I think with that, that's probably a perfect time to wrap up. If folks want to follow more of what you are working on, where can they find what you're up to on the internet?

+ +

JONATHAN: I'm on Twitter, the classic place to go for following someone in tech, so twitter.com/reinink, my last name. That's R-E-I-N-I-N-K. So that's where even if I have stuff shared elsewhere on the web, that's where it starts.

+ +

CHRIS: Perfect. We'll include links to your Twitter as well as everything else that we've mentioned in this episode in the show notes. So folks that do want to keep up or investigate further listening to that other podcast episode that I mentioned will have all of that available. But with that, thank you so much for your time, and yeah, again, really appreciate you joining.

+ +

JONATHAN: Thanks so much, Chris. Pleasure to be here.

+ +

CHRIS: The show notes for this episode can be found at bikeshed.fm. If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. If you have any feedback for this or any of our other episodes, you can reach us at _bikeshed on Twitter. Or you can reach me @christoomey, or you can e-mail hosts@bikeshed.fm. Thanks so much for listening to The Bike Shed, and we'll see you next week.

+ +

This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+WvRUBjOv + + ]]> + + Chris Toomey + + + 290: Can You See My Secrets? + https://bikeshed.thoughtbot.com/290 + 6c0c3734-c116-4699-8814-c513184f0796 + Tue, 27 Apr 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss testing webhooks, the challenges in replicating third-party data, and troubleshooting unexpected side effects. They also respond to a listener question about secrets management, touring popular solutions and discussing the trade-offs. + 32:54 + no + + On this week's episode, Chris and Steph discuss testing webhooks, the challenges in replicating third-party data, and troubleshooting unexpected side effects. They also respond to a listener question about secrets management, touring popular solutions and discussing the trade-offs. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +webhook.site (https://webhook.site) +git-secret (https://git-secret.io/) +Datomic (https://www.datomic.com/) +1Password Secrets (https://1password.com/secrets/) +Hashicorp Vault (https://www.vaultproject.io/) +Heroku Secure Key (https://devcenter.heroku.com/articles/securekey) + + webhooks, replicating data, side-effects, callbacks, secrets, secrets management + + On this week's episode, Chris and Steph discuss testing webhooks, the challenges in replicating third-party data, and troubleshooting unexpected side effects. They also respond to a listener question about secrets management, touring popular solutions and discussing the trade-offs.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph discuss testing webhooks, the challenges in replicating third-party data, and troubleshooting unexpected side effects. They also respond to a listener question about secrets management, touring popular solutions and discussing the trade-offs.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GJ9XZ3JW + + ]]> + + Chris Toomey + Steph Viccari + + + 289: Have You Ever Ridden a Horse? + https://bikeshed.thoughtbot.com/289 + a687cda5-d1cc-4ae6-ac71-98f79b250d54 + Tue, 20 Apr 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris tackle a pair of questions -- the first dealing with how closely we might want to map an API to the underlying database schema, and the second dealing with back of the envelope math and horses (it makes more sense in context.... mostly). They also discuss the subtleties of the javascript date API across browsers, and a quick adventure in tuning database indexes for fun and profit. + 37:58 + no + + On this week's episode, Steph and Chris tackle a pair of questions -- the first dealing with how closely we might want to map an API to the underlying database schema, and the second dealing with back of the envelope math and horses (it makes more sense in context.... mostly). They also discuss the subtleties of the javascript date API across browsers, and a quick adventure in tuning database indexes for fun and profit. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Testing LiveView (https://www.testingliveview.com/) +Inspecting Postgres Indexes (https://www.postgresqltutorial.com/postgresql-database-indexes-table-size) +Postgres Partial Indexes (https://www.postgresql.org/docs/current/indexes-partial.html) +Postgres Create Index Concurrently (https://www.postgresql.org/docs/9.1/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY) + + + On this week's episode, Steph and Chris tackle a pair of questions -- the first dealing with how closely we might want to map an API to the underlying database schema, and the second dealing with back of the envelope math and horses (it makes more sense in context.... mostly). They also discuss the subtleties of the javascript date API across browsers, and a quick adventure in tuning database indexes for fun and profit.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris tackle a pair of questions -- the first dealing with how closely we might want to map an API to the underlying database schema, and the second dealing with back of the envelope math and horses (it makes more sense in context.... mostly). They also discuss the subtleties of the javascript date API across browsers, and a quick adventure in tuning database indexes for fun and profit.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+XrRtyJL7 + + ]]> + + + + 288: 10x Puppy + https://bikeshed.thoughtbot.com/288 + 8289c888-d66b-4d9e-a070-0107f93ad856 + Tue, 13 Apr 2021 09:30:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss migrating a polymorphic relationship over to UUIDs and balancing trade-offs between data integrity vs complexity. They also touch on a new Rails feature that adds support to safely remove and add columns, GitHub Discussions, measuring team experiments, and purposeful communication. + 36:34 + no + + On this week's episode, Chris and Steph discuss migrating a polymorphic relationship over to UUIDs and balancing trade-offs between data integrity vs complexity. They also touch on a new Rails feature that adds support to safely remove and add columns, GitHub Discussions, measuring team experiments, and purposeful communication. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Modeling Polymorphic Associations in a Relational Database (https://hashrocket.com/blog/posts/modeling-polymorphic-associations-in-a-relational-database) +Rails 6.1 - Add support for ifexists/ifnot_exists (https://github.com/rails/rails/pull/38352) +GitHub Discussions (https://docs.github.com/en/discussions) +Loom: Video Messaging (https://www.loom.com/) + + uuid, polymorphic, rails, github, communication, video, experiment + + On this week's episode, Chris and Steph discuss migrating a polymorphic relationship over to UUIDs and balancing trade-offs between data integrity vs complexity. They also touch on a new Rails feature that adds support to safely remove and add columns, GitHub Discussions, measuring team experiments, and purposeful communication.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph discuss migrating a polymorphic relationship over to UUIDs and balancing trade-offs between data integrity vs complexity. They also touch on a new Rails feature that adds support to safely remove and add columns, GitHub Discussions, measuring team experiments, and purposeful communication.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+JL8a3SYn + + ]]> + + + + 287: Turn it up to Eleven + https://bikeshed.thoughtbot.com/287 + 253c1703-de3d-4aa7-856c-4d2d3d527b39 + Tue, 30 Mar 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph shares a recent performance improvement, a Postgres delight, and testing concurrency in RSpec. Chris revisits an earlier theme of "Good Idea, Bad Idea?" as he explores ways to speed up tests builds and avoid duplicate test builds. They round things out with a listener question about managing ERB partials and Vue components. + 37:30 + no + + On this week's episode, Steph shares a recent performance improvement, a Postgres delight, and testing concurrency in RSpec. Chris revisits an earlier theme of "Good Idea, Bad Idea?" as he explores ways to speed up tests builds and avoid duplicate test builds. They round things out with a listener question about managing ERB partials and Vue components. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +ActiveRecord - with_lock (https://apidock.com/rails/ActiveRecord/Locking/Pessimistic/with_lock) +Domain Name Sanity by Edward Loveall (https://edwardloveall.com/projects/domain-name-sanity) +strong_migrations gem (https://github.com/ankane/strong_migrations) +react-rails gem (https://github.com/reactjs/react-rails) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed + + rails, locking, pessimistic lock, testing, rspec, postgres, Circle CI + + On this week's episode, Steph shares a recent performance improvement, a Postgres delight, and testing concurrency in RSpec. Chris revisits an earlier theme of "Good Idea, Bad Idea?" as he explores ways to speed up tests builds and avoid duplicate test builds. They round things out with a listener question about managing ERB partials and Vue components.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph shares a recent performance improvement, a Postgres delight, and testing concurrency in RSpec. Chris revisits an earlier theme of "Good Idea, Bad Idea?" as he explores ways to speed up tests builds and avoid duplicate test builds. They round things out with a listener question about managing ERB partials and Vue components.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+nQiGkAIQ + + ]]> + + + + 286: Time After Time + https://bikeshed.thoughtbot.com/286 + cf880d6b-7473-4729-be93-b79f40256a6e + Tue, 23 Mar 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris shares a rare airing of grievances regarding the importance of secure, encrypted websites, and Steph shares a tale of time zone troubles and testing. + 26:46 + no + + On this week's episode, Chris shares a rare airing of grievances regarding the importance of secure, encrypted websites and Steph shares a tale of time zone troubles and testing. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Time.use_zone (https://apidock.com/rails/v6.0.0/Time/use_zone/class) +Sidekiq (https://sidekiq.org/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed + + ssl, rails, timezone, testing + + On this week's episode, Chris shares a rare airing of grievances regarding the importance of secure, encrypted websites and Steph shares a tale of time zone troubles and testing.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris shares a rare airing of grievances regarding the importance of secure, encrypted websites and Steph shares a tale of time zone troubles and testing.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+sizKJk-u + + ]]> + + + + 285: Tell a Cohesive, Testable Story + https://bikeshed.thoughtbot.com/285 + db0cf7a3-61ef-4ea8-afb2-0fa9d2213ff0 + Tue, 16 Mar 2021 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris tackle a listener question around the world of service objects. Where, really, should we be putting our business logic. Model concerns, "service" objects, the model files themselves? Tune in to find out. They also discuss a perilous Rails 6 upgrade deployment and the ensuing debugging session, as well as Steph's retro on her extended break from work. + 39:39 + no + + On this week's episode, Steph and Chris tackle a listener question around the world of service objects. Where, really, should we be putting our business logic. Model concerns, "service" objects, the model files themselves? Tune in to find out. They also discuss a perilous Rails 6 upgrade deployment and the ensuing debugging session, as well as Steph's retro on her extended break from work. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +USDR (US Digital Response) Volunteer Organization (https://www.usdigitalresponse.org/) +18f (https://18f.gsa.gov/) +USDS (https://usds.gov/) +TwiddleWakka (https://depfu.com/blog/2016/12/14/get-to-know-your-twiddle-wakka) +Clearance Issue w/ LOWER email (https://github.com/thoughtbot/clearance/pull/930) +Say No To More Process (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) +Bike Shed Question Form (https://docs.google.com/forms/d/1RM1o56KXO8aZUryxKsMsbuMy-ptRZ8iNXqpqT5FRbzs/edit?ts=6010aa37&gxids=7628) +dry-rb (https://dry-rb.org/) & dry-rb monad (https://dry-rb.org/gems/dry-monads/1.3/) +Bike Shed Episode discussing dry-rb (https://www.bikeshed.fm/243) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed + + + On this week's episode, Steph and Chris tackle a listener question around the world of service objects. Where, really, should we be putting our business logic. Model concerns, "service" objects, the model files themselves? Tune in to find out. They also discuss a perilous Rails 6 upgrade deployment and the ensuing debugging session, as well as Steph's retro on her extended break from work.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris tackle a listener question around the world of service objects. Where, really, should we be putting our business logic. Model concerns, "service" objects, the model files themselves? Tune in to find out. They also discuss a perilous Rails 6 upgrade deployment and the ensuing debugging session, as well as Steph's retro on her extended break from work.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+khpIiIvi + + ]]> + + + + 284: Lovely, Wonderful Spam + https://bikeshed.thoughtbot.com/284 + 9460e41d-ef10-482b-9394-671d753c0169 + Tue, 09 Mar 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode Chris and Steph chat about upgrading to Rails 6, intercepting emails, and play a few rounds of Software Terminology Trivia. They also discuss "Deep Work" by Cal Newport and share strategies for finding and maintaining focus. + 46:55 + no + + On this week's episode Chris and Steph chat about upgrading to Rails 6, intercepting emails, and play a few rounds of Software Terminology Trivia. They also discuss "Deep Work" by Cal Newport and share strategies for finding and maintaining focus. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Letter Opener (https://github.com/ryanb/letter_opener) +recipient_interceptor (https://github.com/croaky/recipient_interceptor) +Spam Monty Python (https://en.wikipedia.org/wiki/Spam_(Monty_Python)) +CAN-SPAM Act (https://en.wikipedia.org/wiki/CAN-SPAM_Act_of_2003) +Deep Work by Cal Newport (https://www.goodreads.com/book/show/25744928-deep-work) +brain.fm (https://www.brain.fm/) +Getting Things Done (https://www.goodreads.com/book/show/1633.Getting_Things_Done) +Send us your question (https://thoughtbot.com/blog/send-your-questions-to-the-bike-shed), we would love to hear about it. +Looking for your next role? thoughtbot is hiring! (https://thoughtbot.com/jobs) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed + + rails, upgrade, email, deep work, focus, trivia + + On this week's episode Chris and Steph chat about upgrading to Rails 6, intercepting emails, and play a few rounds of Software Terminology Trivia. They also discuss "Deep Work" by Cal Newport and share strategies for finding and maintaining focus.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Send us your question, we would love to hear about it.
+Looking for your next role? thoughtbot is hiring!
+Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode Chris and Steph chat about upgrading to Rails 6, intercepting emails, and play a few rounds of Software Terminology Trivia. They also discuss "Deep Work" by Cal Newport and share strategies for finding and maintaining focus.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Send us your question, we would love to hear about it.
+Looking for your next role? thoughtbot is hiring!
+Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+eGZ4aKSt + + ]]> + + + + 283: Who's The User? + https://bikeshed.thoughtbot.com/283 + b88576b4-dc3b-45fe-9cc6-48cd502578db + Tue, 02 Mar 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode Steph and Chris discuss a listener question around managing content within an application, weighing options like an integrated CMS, headless CMS provides, proxying the content, and supporting marketing and landing pages without needing a developer for every change. They also provide an update on dead man's snitch and a preview of a rails 6 upgrade on the horizon and dreams of database switching. + 26:14 + no + + On this week's episode Steph and Chris discuss a listener question around managing content within an application, weighing options like an integrated CMS, headless CMS provides, proxying the content, and supporting marketing and landing pages without needing a developer for every change. They also provide an update on dead man's snitch and a preview of a rails 6 upgrade on the horizon and dreams of database switching. +This episode is brought to you by SPOTcon (https://www.scoutapm.com/spotbikeshed). Tune in to Scout APM's first conference, and join for developers from around the world to meet, engage with, and learn about solutions that drive leading-edge transformation in application development by registering for free today! +Dead Man's Snitch (https://deadmanssnitch.com/) +Multiple Databases with Active Record (https://guides.rubyonrails.org/active_record_multiple_databases.html) +Refinery CMS (https://www.refinerycms.com/) +ActiveAdmin (https://activeadmin.info/) +Rails Admin (https://github.com/sferik/rails_admin) +MBTA dotcom repo (https://github.com/mbta/dotcom) +Fastly thoughtbot.com proxy blog post (https://thoughtbot.com/blog/host-your-blog-under-blog-on-your-www-domain) +"There's a typo on the homepage" - thoughtbot.com website redesign workshop (https://thoughtbot.com/events/website-redesign-workshop) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed + + + On this week's episode Steph and Chris discuss a listener question around managing content within an application, weighing options like an integrated CMS, headless CMS provides, proxying the content, and supporting marketing and landing pages without needing a developer for every change. They also provide an update on dead man's snitch and a preview of a rails 6 upgrade on the horizon and dreams of database switching.

+ +
+ +

This episode is brought to you by SPOTcon. Tune in to Scout APM's first conference, and join for developers from around the world to meet, engage with, and learn about solutions that drive leading-edge transformation in application development by registering for free today!

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode Steph and Chris discuss a listener question around managing content within an application, weighing options like an integrated CMS, headless CMS provides, proxying the content, and supporting marketing and landing pages without needing a developer for every change. They also provide an update on dead man's snitch and a preview of a rails 6 upgrade on the horizon and dreams of database switching.

+ +
+ +

This episode is brought to you by SPOTcon. Tune in to Scout APM's first conference, and join for developers from around the world to meet, engage with, and learn about solutions that drive leading-edge transformation in application development by registering for free today!

+ +
+ + + +

Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+YvUZsLfz + + ]]> + + + + 282: What is Normal? + https://bikeshed.thoughtbot.com/282 + a904cbc3-5abf-417f-a714-f833652fd902 + Tue, 23 Feb 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris adds Dead Man's Snitch to a personal project and considers "what is the app doing at runtime?" as he touches on the importance of creating observable systems. Steph shares analyzing a site's traffic and using Apache Bench for simple load testing. They also respond to a listener question about creating environment-specific data for data-intensive applications. + 39:54 + no + + On this week's episode, Chris adds Dead Man's Snitch to a personal project and considers "what is the app doing at runtime?" as he touches on the importance of creating observable systems. Steph shares analyzing a site's traffic and using Apache Bench for simple load testing. They also respond to a listener question about creating environment-specific data for data-intensive applications. +This episode is brought to you by SPOTcon (https://www.scoutapm.com/spotbikeshed). Tune in to Scout APM's first conference, and join for developers from around the world to meet, engage with, and learn about solutions that drive leading-edge transformation in application development by registering for free today! +Dead Man's Snitch (https://deadmanssnitch.com/) +Apache Bench (https://httpd.apache.org/docs/current/programs/ab.html) +HTTP Keep-Alive (https://en.wikipedia.org/wiki/HTTP_persistent_connection) +Send us your question (https://thoughtbot.com/blog/send-your-questions-to-the-bike-shed), we would love to hear about it. +Looking for your next role? thoughtbot is hiring! (https://thoughtbot.com/jobs) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed + + observable systems, apache bench, load testing, staging data, development data + + On this week's episode, Chris adds Dead Man's Snitch to a personal project and considers "what is the app doing at runtime?" as he touches on the importance of creating observable systems. Steph shares analyzing a site's traffic and using Apache Bench for simple load testing. They also respond to a listener question about creating environment-specific data for data-intensive applications.

+ +
+ +

This episode is brought to you by SPOTcon. Tune in to Scout APM's first conference, and join for developers from around the world to meet, engage with, and learn about solutions that drive leading-edge transformation in application development by registering for free today!

+ +
+ + + +

Send us your question, we would love to hear about it.
+Looking for your next role? thoughtbot is hiring!
+Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris adds Dead Man's Snitch to a personal project and considers "what is the app doing at runtime?" as he touches on the importance of creating observable systems. Steph shares analyzing a site's traffic and using Apache Bench for simple load testing. They also respond to a listener question about creating environment-specific data for data-intensive applications.

+ +
+ +

This episode is brought to you by SPOTcon. Tune in to Scout APM's first conference, and join for developers from around the world to meet, engage with, and learn about solutions that drive leading-edge transformation in application development by registering for free today!

+ +
+ + + +

Send us your question, we would love to hear about it.
+Looking for your next role? thoughtbot is hiring!
+Become a Sponsor of The Bike Shed

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+YR6AtXaD + + ]]> + + + + 281: Finding That Middle Ground + https://bikeshed.thoughtbot.com/281 + 1f0b9a72-9414-4c2d-893e-8bd4159f2042 + Tue, 16 Feb 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris tackle a listener question around switching from mostly-developing to mostly-communicating and the tactics they've used to balance these facets of their work. They also discuss the new error objects in Rails 6.1, the value of breakable toys, and the importance of keeping presentational concerns out of the data model. + 31:29 + no + + On this week's episode, Steph and Chris tackle a listener question around switching from mostly-developing, to mostly-communicating and the tactics they've used to balance these facets of their work. They also discuss the new error objects in Rails 6.1, the value of breakable toys, and the importance of keeping presentational concerns out of the data model. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Rails 6.1's ActiveModel Errors Revamp (https://code.lulalala.com/2020/0531-1013.html) blog post from @lulalala +Model error as object (https://github.com/rails/rails/pull/32313) pull request with great conversation +Previous Bike Shed episode w/ discussion about error handling with dry-rb (https://www.bikeshed.fm/243) +Tell Me When It Closes (https://tellmewhenitcloses.com/) +Monopoly Deal (https://boardgamegeek.com/boardgame/40398/monopoly-deal-card-game) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph and Chris tackle a listener question around switching from mostly-developing, to mostly-communicating and the tactics they've used to balance these facets of their work. They also discuss the new error objects in Rails 6.1, the value of breakable toys, and the importance of keeping presentational concerns out of the data model.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris tackle a listener question around switching from mostly-developing, to mostly-communicating and the tactics they've used to balance these facets of their work. They also discuss the new error objects in Rails 6.1, the value of breakable toys, and the importance of keeping presentational concerns out of the data model.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Ow0POVII + + ]]> + + + + 280: Stable New New + https://bikeshed.thoughtbot.com/280 + bd6e8182-1835-4cdc-82c8-e55241f9b05f + Tue, 09 Feb 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode Chris and Steph discuss a new tmux feature and wvim, a script that streamlines shell command edits. They also discuss the value of taking a sabbatical and protecting downtime. Steph shares some exciting news about thoughtbot and they answer a listener question about GraphQL and whether your app really needs an API? + 31:56 + no + + On this week's episode Chris and Steph discuss a new tmux feature and wvim, a script that streamlines shell command edits. They also discuss the value of taking a sabbatical and protecting downtime. Steph shares some exciting news about thoughtbot and they answer a listener question about GraphQL and whether your app really needs an API? +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +thoughtbot is hiring! (https://thoughtbot.com/jobs) +Send a question to The Bike Shed! (https://thoughtbot.com/blog/send-your-questions-to-the-bike-shed) +"which + vim = wvim" post (https://ctoomey.com/writing/which-plus-vim-wvim/) +GraphQL Ruby (https://graphql-ruby.org/) +Hasura (https://hasura.io/) +PostGraphile (https://www.graphile.org/postgraphile/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + graphql, remote, sabbatical, tmux, vim + + On this week's episode Chris and Steph discuss a new tmux feature and wvim, a script that streamlines shell command edits. They also discuss the value of taking a sabbatical and protecting downtime. Steph shares some exciting news about thoughtbot and they answer a listener question about GraphQL and whether your app really needs an API?

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode Chris and Steph discuss a new tmux feature and wvim, a script that streamlines shell command edits. They also discuss the value of taking a sabbatical and protecting downtime. Steph shares some exciting news about thoughtbot and they answer a listener question about GraphQL and whether your app really needs an API?

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+rz6ndFak + + ]]> + + + + 279: Seeking Calm + https://bikeshed.thoughtbot.com/279 + bd2526c5-788c-436a-a647-9bb27096b52d + Tue, 02 Feb 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode Steph and Chris discuss some of characteristics and behaviors they've observed in high-performing teams, touching on pull request sizing and prioritizing code review, deploy cadence, error monitoring and response, and minimizing the number of themes being tackled by the team in parallel. They also touch on moving to Netlify and simplifying deploys, an odd edge case with 303 vs 302 status code, and the quirks of the ActiveRecord `or` method. + 35:07 + no + + On this week's episode Steph and Chris discuss some of characteristics and behaviors they've observed in high-performing teams, touching on pull request sizing and prioritizing code review, deploy cadence, error monitoring and response, and minimizing the number of themes being tackled by the team in parallel. They also touch on moving to Netlify and simplifying deploys, an odd edge case with 303 vs 302 status code, and the quirks of the ActiveRecord or method. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Netlify (https://www.netlify.com/) +Netlify build plugins (https://www.netlify.com/products/build/plugins/) +Git LFS (https://git-lfs.github.com/) +Issue opened on Inertia for 302 vs 303s (https://github.com/inertiajs/inertia/issues/419) +"Scoping .or clauses with common joins" post (https://thoughtbot.com/blog/scoping-or-clauses-with-common-joins) +Derek Prior's Building a Culture of Code Review (https://www.youtube.com/watch?v=PJjmw9TRB7s) +Charity Majors (https://twitter.com/mipsytipsy?lang=en) +Honeycomb.io (https://www.honeycomb.io/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode Steph and Chris discuss some of characteristics and behaviors they've observed in high-performing teams, touching on pull request sizing and prioritizing code review, deploy cadence, error monitoring and response, and minimizing the number of themes being tackled by the team in parallel. They also touch on moving to Netlify and simplifying deploys, an odd edge case with 303 vs 302 status code, and the quirks of the ActiveRecord or method.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode Steph and Chris discuss some of characteristics and behaviors they've observed in high-performing teams, touching on pull request sizing and prioritizing code review, deploy cadence, error monitoring and response, and minimizing the number of themes being tackled by the team in parallel. They also touch on moving to Netlify and simplifying deploys, an odd edge case with 303 vs 302 status code, and the quirks of the ActiveRecord or method.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+gRyoLw52 + + ]]> + + + + 278: Beliefs in the Firmware + https://bikeshed.thoughtbot.com/278 + a876106e-9438-47e1-b2f4-336910ba72a8 + Tue, 26 Jan 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + In this week's episode, Steph and Chris discuss the popular testing themes and questions that emerged during the RSpec training course, reflecting on which testing "rules" still apply and when to break the rules. They also chat about the results of the 2020 State of JS survey and repurposing email validations to be helpful vs strict. + 39:15 + no + + In this week's episode, Steph and Chris discuss the popular testing themes and questions that emerged during the RSpec training course, reflecting on which testing "rules" still apply and when to break the rules. They also chat about the results of the 2020 State of JS survey and repurposing email validations to be helpful vs strict. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +RSpec focus filter (https://relishapp.com/rspec/rspec-core/v/3-10/docs/filtering/inclusion-filters) +RSpec subject (https://relishapp.com/rspec/rspec-core/v/3-10/docs/subject) +FactoryBot (https://github.com/thoughtbot/factory_bot) +The State of JS 2020 (https://2020.stateofjs.com/en-US/) +Svelte.js (https://svelte.dev/) +Snowpack (https://www.snowpack.dev/) +esbuild (https://github.com/evanw/esbuild) +Mailcheck (https://github.com/mailcheck/mailcheck) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + ruby, rspec, testing, javascript, svelte, email, validation + + In this week's episode, Steph and Chris discuss the popular testing themes and questions that emerged during the RSpec training course, reflecting on which testing "rules" still apply and when to break the rules. They also chat about the results of the 2020 State of JS survey and repurposing email validations to be helpful vs strict.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + In this week's episode, Steph and Chris discuss the popular testing themes and questions that emerged during the RSpec training course, reflecting on which testing "rules" still apply and when to break the rules. They also chat about the results of the 2020 State of JS survey and repurposing email validations to be helpful vs strict.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+vmrhvRDr + + ]]> + + + + 277: Making Communication Easier + https://bikeshed.thoughtbot.com/277 + 77bfb530-7501-4fc9-ae36-67c46c99e927 + Tue, 19 Jan 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + In this week's episode, Steph and Chris discuss some of their methods for helping out reviewers of their pull requests and keeping code review moving along smoothly. They also discus the shift to async communication and the tools, processes, and workflows that come with a shift to async. Does standup still have a place in an async world? Tune in to find out. + 39:52 + no + + In this week's episode, Steph and Chris discuss some of their methods for helping out reviewers of their pull requests and keeping code review moving along smoothly. They also discus the shift to async communication and the tools, processes, and workflows that come with a shift to async. Does standup still have a place in an async world? Tune in to find out. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Svelte society coining an acronym (https://twitter.com/SvelteSociety/status/1346579120721809410) +GitHub now supports video uploads (https://github.blog/changelog/2020-12-16-video-upload-public-beta/) +Recordit (https://recordit.co/) +Giphy Capture (https://giphy.com/apps/giphycapture) +Basecamp (https://basecamp.com/) +Telegram (https://telegram.org/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + In this week's episode, Steph and Chris discuss some of their methods for helping out reviewers of their pull requests and keeping code review moving along smoothly. They also discus the shift to async communication and the tools, processes, and workflows that come with a shift to async. Does standup still have a place in an async world? Tune in to find out.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + In this week's episode, Steph and Chris discuss some of their methods for helping out reviewers of their pull requests and keeping code review moving along smoothly. They also discus the shift to async communication and the tools, processes, and workflows that come with a shift to async. Does standup still have a place in an async world? Tune in to find out.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+e896Bqk6 + + ]]> + + + + 276: Ride-Along Files + https://bikeshed.thoughtbot.com/276 + 93c640a6-509d-4c94-9941-ff7c58480d60 + Tue, 12 Jan 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris shares a new favorite tool for querying JSON and Steph revisits a previous deployment issue. They also dive into the new features in Ruby 3, ponder the idea of adding types to Ruby, revisit breaking changes, and round out the conversation with a listener question about managing tmux sessions. + 26:58 + no + + On this week's episode, Chris shares a new favorite tool for querying JSON and Steph revisits a previous deployment issue. They also dive into the new features in Ruby 3, ponder the idea of adding types to Ruby, revisit breaking changes, and round out the conversation with a listener question about managing tmux sessions. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +fx - Command-line JSON processor (https://github.com/antonmedv/fx) +jq - Command-line JSON processor (https://stedolan.github.io/jq/) +Postman (https://www.postman.com/) +Insomnia (https://insomnia.rest/) +Ruby 3 Release Notes (https://www.ruby-lang.org/en/news/2020/12/20/ruby-3-0-0-rc1-released/) +Ruby 3 - Separation of positional and keyword arguments (https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/) +Ruby adds experimental support for end-less method definition (https://blog.saeloun.com/2020/04/27/ruby-adds-endless-method-definition-experimental.html) +Tmuxinator (https://github.com/tmuxinator/tmuxinator) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + ruby, ruby 3, fx, jq, json, types + + On this week's episode, Chris shares a new favorite tool for querying JSON and Steph revisits a previous deployment issue. They also dive into the new features in Ruby 3, ponder the idea of adding types to Ruby, revisit breaking changes, and round out the conversation with a listener question about managing tmux sessions.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris shares a new favorite tool for querying JSON and Steph revisits a previous deployment issue. They also dive into the new features in Ruby 3, ponder the idea of adding types to Ruby, revisit breaking changes, and round out the conversation with a listener question about managing tmux sessions.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+aBZeFswd + + ]]> + + + + 275: In Search of An Acronym + https://bikeshed.thoughtbot.com/275 + 04fa5a09-d3e3-4982-9b88-168cfcf152f6 + Tue, 05 Jan 2021 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris revisit their discussion about testing rack rewrite redirect logic, mystery guests, DNS configuration, and trying very hard to not be too dogmatic. Steph describes her recent work trying to debug failing deploys with Concourse, Kubernetes, and Google Cloud while touching on blue-green deployment and secrets management. Finally, Chris talks about porting a svelte project to typescript and the trade-offs of adding Types upfront vs types after the fact, and the parallels to testing and TDD. + 35:00 + no + + On this week's episode, Steph and Chris revisit their discussion about testing rack rewrite redirect logic, mystery guests, DNS configuration, and trying very hard to not be too dogmatic. Steph describes her recent work trying to debug failing deploys with Concourse, Kubernetes, and Google Cloud while touching on blue-green deployment and secrets management. Finally, Chris talks about porting a svelte project to typescript and the trade-offs of adding Types upfront vs types after the fact, and the parallels to testing and TDD. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Solo Stove (https://www.solostove.com/) +rack_rewrite (https://github.com/jtrupiano/rack-rewrite) +Climate Control (https://github.com/thoughtbot/climate_control) +The Art of Code Comments talk by Sarah Drasner (https://www.youtube.com/watch?v=yhF7OmuIILc) +Concourse (https://concourse-ci.org/) +Kubernetes (https://kubernetes.io/) +Google Cloud Platform (https://cloud.google.com/) +git-crypt (https://github.com/AGWA/git-crypt) +Rails encrypted secrets (https://blog.engineyard.com/encrypted-rails-secrets-on-rails-5.1) +Tailwind CSS (https://tailwindcss.com/) +InertiaJS (https://inertiajs.com/) +Svelte (https://svelte.dev/) +Rich Harris and Evan You on Undefined podcast (https://undefined.fm/radio/vue-vs-svelte-with-evan-you-and-rich-harris) +ts-routes gem (https://github.com/bitjourney/ts_routes-rails) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph and Chris revisit their discussion about testing rack rewrite redirect logic, mystery guests, DNS configuration, and trying very hard to not be too dogmatic. Steph describes her recent work trying to debug failing deploys with Concourse, Kubernetes, and Google Cloud while touching on blue-green deployment and secrets management. Finally, Chris talks about porting a svelte project to typescript and the trade-offs of adding Types upfront vs types after the fact, and the parallels to testing and TDD.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris revisit their discussion about testing rack rewrite redirect logic, mystery guests, DNS configuration, and trying very hard to not be too dogmatic. Steph describes her recent work trying to debug failing deploys with Concourse, Kubernetes, and Google Cloud while touching on blue-green deployment and secrets management. Finally, Chris talks about porting a svelte project to typescript and the trade-offs of adding Types upfront vs types after the fact, and the parallels to testing and TDD.

+ +
+ +

This episode is brought to you by ScoutAPM. Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy

+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+x4nxpbVW + + ]]> + + + + 274: Top 10 Review for 2020 + https://bikeshed.thoughtbot.com/274 + 5e182573-e043-4671-9fd5-265e38b6a9a7 + Tue, 29 Dec 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph reflect on their top themes and technical picks for 2020. + 26:10 + no + + On this week's episode, Chris and Steph reflect on their top themes and technical picks for 2020. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to can get an extra 3 months free on a one-year package. +Tailwind CSS (https://tailwindcss.com/) +BEM CSS (http://getbem.com/) +Styled Components (https://styled-components.com/) +css-modules (https://github.com/css-modules/css-modules) +BikeShed Episode: I'm a Designer Now (https://www.bikeshed.fm/252) +ActiveModel Error Objects (https://blog.saeloun.com/2020/06/17/rails-active-model-errors.html) +Razer Kiyo (https://www.razer.com/streaming-cameras/razer-kiyo/RZ19-02320100-R3M1) +Upright Go 2 (https://store.uprightpose.com/products/upright-go2) +Svelte (https://svelte.dev/) +Phoenix Live View (https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html) +Laravel Livewire (https://laravel-livewire.com/) +Stimulus (https://stimulus.hotwire.dev/) +Inertia.js (https://inertiajs.com/) + + tailwind, rails, remote + + On this week's episode, Chris and Steph reflect on their top themes and technical picks for 2020.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph reflect on their top themes and technical picks for 2020.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+p1ZxT_41 + + ]]> + + + + 273: Revisiting 2019, A Top 10 Review + https://bikeshed.thoughtbot.com/273 + b0532a90-ffa6-476f-92aa-e724f6c55043 + Tue, 22 Dec 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris begin wrapping up 2020 with a review of their 2019 top 10 list. They share what's changed, what's stayed the same, and what they'd like to see more of in the coming year. + 27:29 + no + + On this week's episode, Steph and Chris begin wrapping up 2020 with a review of their 2019 top 10 list. They share what's changed, what's stayed the same, and what they'd like to see more of in the coming year. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +Last year's top 10 countdown list (https://www.bikeshed.fm/226) +ErgoDox EZ (https://ergodox-ez.com/) +Leopold FC750 (https://mechanicalkeyboards.com/shop/index.php?c=171&l=product_list) +Keybordio Atreus (https://shop.keyboard.io/products/keyboardio-atreus) +Prettier (https://prettier.io/) +Prettier Ruby (https://github.com/prettier/plugin-ruby) +Elm (https://elm-lang.org/) +Code Hospitality (https://www.youtube.com/watch?v=hHzWG1FltaE) +Testing Library (https://testing-library.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph and Chris begin wrapping up 2020 with a review of their 2019 top 10 list. They share what's changed, what's stayed the same, and what they'd like to see more of in the coming year.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris begin wrapping up 2020 with a review of their 2019 top 10 list. They share what's changed, what's stayed the same, and what they'd like to see more of in the coming year.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+DXxHO9Os + + ]]> + + + + 272: Hacking the Gibson + https://bikeshed.thoughtbot.com/272 + fe72afb6-df0d-45cb-8fae-00dc1149e35c + Tue, 15 Dec 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + In this week's episode, Chris undertakes long-running background jobs that are performing duplicate work and adding significant load on the database. Steph shares her initial take of the book "Soul of a New Machine", a non-fiction account that chronicles the development of a mini-computer in the 1980s. They also dive into the question "how can teams turn a slow, hard to maintain test suite from a liability into an asset?" and touch on how to identify highly-functioning teams. + 33:27 + no + + In this week's episode, Chris undertakes long-running background jobs that are performing duplicate work and adding significant load on the database. Steph shares her initial take of the book "Soul of a New Machine", a non-fiction account that chronicles the development of a mini-computer in the 1980s. +They also dive into the question "how can teams turn a slow, hard to maintain test suite from a liability into an asset?" and touch on how to identify highly-functioning teams. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. +HelloFresh (https://HelloFresh.com/bikeshed80) - Visit HelloFresh and use code bikeshed80 to get $80 off including free shipping. +ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to can get an extra 3 months free on a one-year package. +Sidekiq (https://github.com/mperham/sidekiq) +The Soul of a New Machine by Tracy Kidder (https://www.tracykidder.com/the-soul-of-a-new-machine.html) +Bike Shed Episode 236 - Featuring "The Cuckoo's Egg" by Cliff Stoll (https://www.bikeshed.fm/236) +Hackers (https://en.wikipedia.org/wiki/Hackers_(film)) +WarGames (https://en.wikipedia.org/wiki/WarGames) +Labyrinth (https://en.wikipedia.org/wiki/Labyrinth_(1986_film)) +Therapeutic Refactoring by Katrina Owen (https://youtu.be/KA9i5IGS-oU) +Goodhart's law (https://en.wikipedia.org/wiki/Goodhart%27s_law) +Drive by Daniel Pink (https://www.danpink.com/drive./) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + sidekiq, minicomputer, rails, testing + + In this week's episode, Chris undertakes long-running background jobs that are performing duplicate work and adding significant load on the database. Steph shares her initial take of the book "Soul of a New Machine", a non-fiction account that chronicles the development of a mini-computer in the 1980s.

+ +

They also dive into the question "how can teams turn a slow, hard to maintain test suite from a liability into an asset?" and touch on how to identify highly-functioning teams.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.
    • +
  • HelloFresh - Visit HelloFresh and use code bikeshed80 to get $80 off including free shipping.
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + In this week's episode, Chris undertakes long-running background jobs that are performing duplicate work and adding significant load on the database. Steph shares her initial take of the book "Soul of a New Machine", a non-fiction account that chronicles the development of a mini-computer in the 1980s.

+ +

They also dive into the question "how can teams turn a slow, hard to maintain test suite from a liability into an asset?" and touch on how to identify highly-functioning teams.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy.
    • +
  • HelloFresh - Visit HelloFresh and use code bikeshed80 to get $80 off including free shipping.
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4AbQ4zNP + + ]]> + + + + 271: Is That Your Final Answer? + https://bikeshed.thoughtbot.com/271 + 0f15a51d-5b44-4a50-b697-b6729edba0a9 + Tue, 08 Dec 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris describes his continued explorations with Svelte specifically bringing TypeScript into the mix. Steph discusses the first cohort for the RSpec training and some related testing questions around third party APIs. They round things out with a listener question about managing permissions and roles, with a brief detour around single table inheritance vs polymorphic associations. Oh, and Steph rented goats to mow her lawn. 🐐 + 37:49 + no + + On this week's episode, Chris describes his continued explorations with Svelte specifically bringing TypeScript into the mix. Steph discusses the first cohort for the RSpec training and some related testing questions around third party APIs. They round things out with a listener question about managing permissions and roles, with a brief detour around single table inheritance vs polymorphic associations. Oh, and Steph rented goats to mow her lawn. 🐐 +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to can get an extra 3 months free on a one-year package. +Elm (https://elm-lang.org/) +Svelte (https://svelte.dev/) +React (https://reactjs.org/) +Redux (https://redux.js.org/) +Svelte - Writable Stores (https://svelte.dev/tutorial/writable-stores) +webmock (https://github.com/webmock/webmock) +Pundit (https://github.com/varvet/pundit) +EdgeDB (https://www.edgedb.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Chris describes his continued explorations with Svelte specifically bringing TypeScript into the mix. Steph discusses the first cohort for the RSpec training and some related testing questions around third party APIs. They round things out with a listener question about managing permissions and roles, with a brief detour around single table inheritance vs polymorphic associations. Oh, and Steph rented goats to mow her lawn. 🐐

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris describes his continued explorations with Svelte specifically bringing TypeScript into the mix. Steph discusses the first cohort for the RSpec training and some related testing questions around third party APIs. They round things out with a listener question about managing permissions and roles, with a brief detour around single table inheritance vs polymorphic associations. Oh, and Steph rented goats to mow her lawn. 🐐

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Dz1BFwem + + ]]> + + + + 270: Both Nothing and Deeply Special + https://bikeshed.thoughtbot.com/270 + 658350de-cba9-4de5-a20d-20071869913e + Tue, 01 Dec 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + In this week's episode, Chris and Steph discuss redirecting requests for various hostnames to one canonical host, creating student personas to improve educational content, and walking away from failing tests. They also embark on a Hollywood themed tour of RSpec mocks, stubs, and spies, when to use each approach, and discuss the types of tests they do (or do not) write. + 38:57 + no + + In this week's episode, Chris and Steph discuss redirecting requests for various hostnames to one canonical host, creating student personas to improve educational content, and walking away from failing tests. They also embark on a Hollywood themed tour of RSpec mocks, stubs, and spies, when to use each approach, and discuss the types of tests they do (or do not) write. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Remote Works Podcast (https://link.chtbl.com/remoteworks_cyoa?sid=podcast.TheBikeShed) +Rack Canonical Host (https://github.com/tylerhunt/rack-canonical-host) +Spring (https://github.com/rails/spring) +rack-rewrite (https://github.com/jtrupiano/rack-rewrite) +Sandi Metz - The Magic Tricks of Testing (https://youtu.be/URSWYvyc42M) +Erlang Dialyzer (http://erlang.org/doc/man/dialyzer.html) +Elixir Dialyxir (https://github.com/jeremyjh/dialyxir) +Sorbet - type checker for Ruby (https://sorbet.org/) +Svelte (https://svelte.dev/) + + rails, ruby, testing, rspec, canonical host + + In this week's episode, Chris and Steph discuss redirecting requests for various hostnames to one canonical host, creating student personas to improve educational content, and walking away from failing tests. They also embark on a Hollywood themed tour of RSpec mocks, stubs, and spies, when to use each approach, and discuss the types of tests they do (or do not) write.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Remote Works Podcast
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + In this week's episode, Chris and Steph discuss redirecting requests for various hostnames to one canonical host, creating student personas to improve educational content, and walking away from failing tests. They also embark on a Hollywood themed tour of RSpec mocks, stubs, and spies, when to use each approach, and discuss the types of tests they do (or do not) write.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Remote Works Podcast
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ipbkGXSN + + ]]> + + + + 269: Things are Knowable (Gary Bernhardt) + https://bikeshed.thoughtbot.com/269 + ae1b6ec7-159b-4f9c-a04a-a62f0ac28147 + Tue, 17 Nov 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + In the episode, Chris is joined by Gary Bernhardt to discuss Gary's recent work with TypeScript and how it compares with his focus on testing, they revisit some of Gary's ideas around software architecture and how they map to his current work, Gary's thoughts around the value of knowing our tools deeply, and the trade-offs between careful upfront design and shipping early and often. + 46:04 + no + + Steph's taking a quick break this week, but while she's away, Chris is joined by special guest Gary Bernhardt. Gary is the creator of Destroy All Software screencasts as well as his more recent venture, Execute Program. Between Execute Program, his screencasts, conference talks, and more Gary has consistently provided some of the highest quality and most impactful educational content around building great software and has been a huge inspiration to the hosts of this show. +In the episode, Chris and Gary discuss Gary's recent work with TypeScript and how it compares with Gary's focus on testing, they revisit some of Gary's ideas around software architecture and how they map to his current work, Gary's thoughts around the value of knowing our tools deeply, and the trade-offs between careful upfront design and shipping early and often. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +Gary Bernhardt on Twitter (https://twitter.com/garybernhardt) +Destroy All Software Screencasts (https://www.destroyallsoftware.com/) +Execute Program (https://www.executeprogram.com/) +Deconstruct Conf (https://www.deconstructconf.com/) +Gary's Conference Talks (https://www.destroyallsoftware.com/talks) +Gary's new video - End-to-End TypeScript: Database, Backend, API, and Frontend (https://www.youtube.com/watch?v=GrnBXhsr0ng) +TypeScript Eslint (https://github.com/typescript-eslint/typescript-eslint) +tsuquyomi Vim TypeScript integration (https://github.com/Quramy/tsuquyomi) +Functional Core, Imperative Shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) +Boundaries (https://www.destroyallsoftware.com/talks/boundaries) +A Compiler From Scratch (https://www.destroyallsoftware.com/screencasts/catalog/a-compiler-from-scratch) +The Unix Chainsaw (https://www.youtube.com/watch?v=sCZJblyT_XM) +A Whole New World (https://www.destroyallsoftware.com/talks/a-whole-new-world) +Hammock Driven Development (https://www.youtube.com/watch?v=f84n5oFoZBc) +WaniKani kanji learning app (https://www.wanikani.com/) +Anki - spaced repetition flashcard system (https://apps.ankiweb.net/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + Steph's taking a quick break this week, but while she's away, Chris is joined by special guest Gary Bernhardt. Gary is the creator of Destroy All Software screencasts as well as his more recent venture, Execute Program. Between Execute Program, his screencasts, conference talks, and more Gary has consistently provided some of the highest quality and most impactful educational content around building great software and has been a huge inspiration to the hosts of this show.

+ +

In the episode, Chris and Gary discuss Gary's recent work with TypeScript and how it compares with Gary's focus on testing, they revisit some of Gary's ideas around software architecture and how they map to his current work, Gary's thoughts around the value of knowing our tools deeply, and the trade-offs between careful upfront design and shipping early and often.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + Steph's taking a quick break this week, but while she's away, Chris is joined by special guest Gary Bernhardt. Gary is the creator of Destroy All Software screencasts as well as his more recent venture, Execute Program. Between Execute Program, his screencasts, conference talks, and more Gary has consistently provided some of the highest quality and most impactful educational content around building great software and has been a huge inspiration to the hosts of this show.

+ +

In the episode, Chris and Gary discuss Gary's recent work with TypeScript and how it compares with Gary's focus on testing, they revisit some of Gary's ideas around software architecture and how they map to his current work, Gary's thoughts around the value of knowing our tools deeply, and the trade-offs between careful upfront design and shipping early and often.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+zUloTQiZ + + ]]> + + + + 268: Getting Your First-Through-N Jobs + https://bikeshed.thoughtbot.com/268 + 14df9fde-b66f-4d8c-b8ef-fa8ab09f4e5e + Tue, 10 Nov 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph discusses the value of conducting student research when creating course content and Chris revisits a recent architecture decision to use Svelt and Inertia. They also explore the challenges developers face in acquiring their first job and share insights for those looking for their next big role. + 52:56 + no + + On this week's episode, Steph discusses the value of conducting student research when creating course content and Chris revisits a recent architecture decision to use Svelt and Inertia. They also explore the challenges developers face in acquiring their first job and share insights for those looking for their next big role. +This episode is brought to you by: +ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to can get an extra 3 months free on a one-year package. +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Hunt for the Wilderpeople (https://www.imdb.com/title/tt4698684/) +Wicked (https://wickedthemusical.com/) +Svelte (https://svelte.dev/) +Inertia.js (https://inertiajs.com/) +Ruby on Rails Podcast - 285: Bikeshedding with Steph Viccari (https://5by5.tv/rubyonrails/285) +Will Johnson (https://twitter.com/willjohnsonio) +Alexander and the Terrible, Horrible, No Good, Very Bad Day (https://en.wikipedia.org/wiki/Alexander_and_the_Terrible,_Horrible,_No_Good,_Very_Bad_Day) + + + On this week's episode, Steph discusses the value of conducting student research when creating course content and Chris revisits a recent architecture decision to use Svelt and Inertia. They also explore the challenges developers face in acquiring their first job and share insights for those looking for their next big role.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph discusses the value of conducting student research when creating course content and Chris revisits a recent architecture decision to use Svelt and Inertia. They also explore the challenges developers face in acquiring their first job and share insights for those looking for their next big role.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+J6Qrsy7r + + ]]> + + + + 267: Shiny New Things + https://bikeshed.thoughtbot.com/267 + 91a4d0c8-0a19-47f7-8032-272c67338399 + Tue, 03 Nov 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph describes her unique new project where they're building and presenting a training course around RSpec, testing, and TDD specific to an organization's codebase. Chris then runs some architecture choices by Steph to discuss a collection of new technologies he's considering, and more generally how we think about our experimentation budget. + 48:01 + no + + On this week's episode, Steph describes her unique new project where they're building and presenting a training course around RSpec, testing, and TDD specific to an organization's codebase. Chris then runs some architecture choices by Steph to discuss a collection of new technologies he's considering, and more generally how we think about our experimentation budget. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +The Witches (https://www.imdb.com/title/tt0100944/) +The Witches (2020) (https://www.imdb.com/title/tt0805647/) +Addams Family (https://www.imdb.com/title/tt0101272/) +Addams Family Values (https://www.imdb.com/title/tt0106220/) +Practical Magic (https://www.imdb.com/title/tt0120791/) +Oculus Quest 2 (https://www.oculus.com/quest-2) +SuperHot (https://superhotgame.com/) +Beat Saber (https://beatsaber.com/) +Rocket League (https://www.rocketleague.com/) +Sandi Metz (https://sandimetz.com/) +Inertia.js (https://inertiajs.com/) +Svelte (https://svelte.dev/) +Rich Harris (Svelte creator): Futuristic Web Development (https://www.youtube.com/watch?v=qSfdtmcZ4d0) +Bike Shed episode talking about Inertia.js (https://www.bikeshed.fm/237) +Another Bike Shed episode talking about Inertia.js (https://www.bikeshed.fm/240) +Write Less, Do More (https://www.youtube.com/watch?v=BzX4aTRPzno) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph describes her unique new project where they're building and presenting a training course around RSpec, testing, and TDD specific to an organization's codebase. Chris then runs some architecture choices by Steph to discuss a collection of new technologies he's considering, and more generally how we think about our experimentation budget.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph describes her unique new project where they're building and presenting a training course around RSpec, testing, and TDD specific to an organization's codebase. Chris then runs some architecture choices by Steph to discuss a collection of new technologies he's considering, and more generally how we think about our experimentation budget.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+zj3z0dC2 + + ]]> + + + + 266: Spring is My Least Favorite Season + https://bikeshed.thoughtbot.com/266 + 0746f02b-6fa1-4e48-8886-ebb6610e1b04 + Tue, 27 Oct 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph share mixed-feelings about Spring preloader and how to use Spring just for tests. They also dive into troubleshooting an OpenSSL error, Postgres generated columns, and creating moments of contentment. + 37:48 + no + + On this week's episode, Chris and Steph share mixed-feelings about Spring preloader and how to use Spring just for tests. They also dive into troubleshooting an OpenSSL error, Postgres generated columns, and creating moments of contentment. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Datadog (http://datadog.com/thebikeshed) - Click through to get a free 14-day trial and a free Datadog t-shirt! +Scale Your Rails App Internationally in 30 Days (https://locale.webinarninja.com/live-webinars/518780/register) +Spring (https://github.com/rails/spring) +LibreSSL (https://en.wikipedia.org/wiki/LibreSSL) +OpenSSL (https://www.openssl.org/) +Apple WWDC 2011 - Next Generation Cryptographic Services (https://developer.apple.com/videos/play/wwdc2011/212/) +Postgres Generated Columns (https://www.postgresql.org/docs/12/ddl-generated-columns.html) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + spring, rails, ruby, openssl, wellness + + On this week's episode, Chris and Steph share mixed-feelings about Spring preloader and how to use Spring just for tests. They also dive into troubleshooting an OpenSSL error, Postgres generated columns, and creating moments of contentment.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Datadog - Click through to get a free 14-day trial and a free Datadog t-shirt!
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph share mixed-feelings about Spring preloader and how to use Spring just for tests. They also dive into troubleshooting an OpenSSL error, Postgres generated columns, and creating moments of contentment.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Datadog - Click through to get a free 14-day trial and a free Datadog t-shirt!
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1zS8qMjS + + ]]> + + + + 265: There Are No Free Lunches + https://bikeshed.thoughtbot.com/265 + 759b1c8f-b7fb-42ae-8b4e-4b975fbb0061 + Tue, 20 Oct 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris chat about database transactions and job queues, building static sites with GatsbyJS and NetlifyCMS, the performance impacts of front end frameworks and static content, and lastly they catch up on Hacktoberfest and the complexities of encouraging and supporting work in open source. + 46:02 + no + + On this week's episode, Steph and Chris chat about database transactions and job queues, building static sites with GatsbyJS and NetlifyCMS, the performance impacts of front end frameworks and static content, and lastly they catch up on Hacktoberfest and the complexities of encouraging and supporting work in open source. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Datadog (http://datadog.com/thebikeshed). Click through to get a free 14-day trial and a free Datadog t-shirt! +Sidekiq (https://sidekiq.org/) +delayed_job (https://github.com/collectiveidea/delayed_job) +Que (Postgres-backed job queuing system for ruby apps) (https://github.com/que-rb/que) +Transactionally Staged Job Drains in Postgres (https://brandur.org/job-drain) +Postgres Job Queues & Failure By MVCC (https://brandur.org/postgres-queues) +Gatsby.js (https://www.gatsbyjs.com/) +Netlify (https://www.netlify.com/) +NetlifyCMS (https://www.netlifycms.org/) +Middleman (https://middlemanapp.com/) +MDX (https://mdxjs.com/) +Steph's Monster blog (https://monster-cute.netlify.app/) +monster-cute blog repo (https://github.com/SViccari/monster-cute) +Svelte (https://svelte.dev/) +Rich Harris - creator of Svelte (https://twitter.com/rich_harris) +Rich Harris on full stack radio (https://fullstackradio.com/143) +Extensity chrome extension (https://chrome.google.com/webstore/detail/extensity/jjmflmamggggndanpgfnpelongoepncg?hl=en) +Hacktoberfest (https://hacktoberfest.digitalocean.com/) +DigitalOcean's Hacktoberfest is Hurting Open Source (https://blog.domenic.me/hacktoberfest/) +Hacktoberfest Update from Digital Ocean (https://hacktoberfest.digitalocean.com/hacktoberfest-update) +Goodhart's law (https://en.wikipedia.org/wiki/Goodhart%27s_law) +Adam Wathan of Tailwind Labs (https://adamwathan.me/) +Remix Run (https://remix.run/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph and Chris chat about database transactions and job queues, building static sites with GatsbyJS and NetlifyCMS, the performance impacts of front end frameworks and static content, and lastly they catch up on Hacktoberfest and the complexities of encouraging and supporting work in open source.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris chat about database transactions and job queues, building static sites with GatsbyJS and NetlifyCMS, the performance impacts of front end frameworks and static content, and lastly they catch up on Hacktoberfest and the complexities of encouraging and supporting work in open source.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+aTlbRICy + + ]]> + + + + 264: How to Win Friends and Influence Processes + https://bikeshed.thoughtbot.com/264 + fed2066c-ac76-42da-b36b-bd7a64bec204 + Tue, 13 Oct 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode Steph and Chris discuss the ins and outs of joining teams, building trust, and working together to improve processes and communication. They also touch on some lesser used features of bundler, and revisit a discussion around Rails maintenance periods thanks to some listener feedback. + 41:42 + no + + On this week's episode Steph and Chris discuss the ins and outs of joining teams, building trust, and working together to improve processes and communication. They also touch on some lesser used features of bundler, and revisit a discussion around Rails maintenance periods thanks to some listener feedback. +This episode is brought to you by: +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to can get an extra 3 months free on a one-year package. +Initial conversation about posible Rails downtime handling (https://www.bikeshed.fm/262) +Chris' post about read-only mode for better Rails downtime (https://ctoomey.com/writing/read-only-mode-for-better-rails-downtime/) +Bundler options to load specific gems (https://bundler.io/bundle_install.html) + + + On this week's episode Steph and Chris discuss the ins and outs of joining teams, building trust, and working together to improve processes and communication. They also touch on some lesser used features of bundler, and revisit a discussion around Rails maintenance periods thanks to some listener feedback.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode Steph and Chris discuss the ins and outs of joining teams, building trust, and working together to improve processes and communication. They also touch on some lesser used features of bundler, and revisit a discussion around Rails maintenance periods thanks to some listener feedback.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
  • ExpressVPN - Click through to can get an extra 3 months free on a one-year package.
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+pM2us8Z5 + + ]]> + + + + 263: Keeping The Night Brain At Bay (Dave Rupert) + https://bikeshed.thoughtbot.com/263 + 7b51bb64-cbc5-4093-b6ab-a5249bbcec3e + Tue, 06 Oct 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + Steph's taking a quick break this week, but in her absence, Chris is joined by [Dave Rupert][]. Dave is the lead developer at Paravel, co-host of the Shop Talk Show podcast, creator of The Accessibility Project, and an all-around prolific and thoughtful maker of digital things. + +Chris and Dave chat about creating and sharing content like podcasts and blogs and how to get past your inner editor. They discuss the web platform and accessibility, and finally, they round out the conversation with a chat about design systems as an intersection between design and development. + 54:00 + no + + Steph's taking a quick break this week, but in her absence, Chris is joined by Dave Rupert (https://daverupert.com/). Dave is the lead developer at Paravel, co-host of the Shop Talk Show podcast, creator of The Accessibility Project, and an all-around prolific and thoughtful maker of digital things. +Chris and Dave chat about creating and sharing content like podcasts and blogs and how to get past your inner editor. They discuss the web platform and accessibility, and finally, they round out the conversation with a chat about design systems as an intersection between design and development. +This episode is brought to you by: +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +Datadog (http://datadog.com/thebikeshed). Click through to get a free 14-day trial and a free Datadog t-shirt! +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Dave on Twitter (https://twitter.com/davatron5000) +Dave's site / blog (https://daverupert.com/) +Paravel (https://paravelinc.com/) +The Accessibility Project (https://www.a11yproject.com/) +Shop Talk Show Podcast (https://shoptalkshow.com/) +How to Start a Podcast (https://daverupert.com/2020/01/how-to-start-a-podcast/) +The Good Path (on Blogging) (https://daverupert.com/2018/11/the-good-path/) +Jeremy Kieth (https://adactio.com/) +Jekyll (https://jekyllrb.com/) static site generator +What is the Value of Browser Diversity? (https://daverupert.com/2020/09/the-value-of-browser-diversity/) +The WebAIM Million Project (https://webaim.org/projects/million/) +Web Content Accessibility Guidelines (WCAG) (https://www.w3.org/WAI/standards-guidelines/wcag/) +Accessible Rich Internet Applications (ARIA) (https://www.w3.org/WAI/standards-guidelines/aria/) +The Accessibility Project Checklist (https://www.a11yproject.com/checklist/) +Scott Hanselman (https://www.hanselman.com/) +The Hanselminutes Podcast (https://hanselminutes.com/) +Five Key Milestones in the Life of a Design System (https://daverupert.com/2020/05/5-design-system-milestones/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + Steph's taking a quick break this week, but in her absence, Chris is joined by Dave Rupert. Dave is the lead developer at Paravel, co-host of the Shop Talk Show podcast, creator of The Accessibility Project, and an all-around prolific and thoughtful maker of digital things.

+ +

Chris and Dave chat about creating and sharing content like podcasts and blogs and how to get past your inner editor. They discuss the web platform and accessibility, and finally, they round out the conversation with a chat about design systems as an intersection between design and development.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
  • Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!
    • +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + Steph's taking a quick break this week, but in her absence, Chris is joined by Dave Rupert. Dave is the lead developer at Paravel, co-host of the Shop Talk Show podcast, creator of The Accessibility Project, and an all-around prolific and thoughtful maker of digital things.

+ +

Chris and Dave chat about creating and sharing content like podcasts and blogs and how to get past your inner editor. They discuss the web platform and accessibility, and finally, they round out the conversation with a chat about design systems as an intersection between design and development.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
  • Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!
    • +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Ex6-nLNv + + ]]> + + + + 262: Good Idea, Terrible Idea? + https://bikeshed.thoughtbot.com/262 + 77f69cc8-ba0f-4b22-9457-8edc2e2e96c6 + Tue, 29 Sep 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris introduces a new segment called "Good Idea, Bad Idea?" as he considers introducing a read-only mode to avoid interrupting users during scheduled downtime. Steph has started a new project and explores the idea of merging separate, but similar, applications into one codebase. They also dive into micro-service environments to discuss the difficulties of integration testing and potential strategies. + 52:41 + no + + On this week's episode, Chris introduces a new segment called "Good Idea, Terrible Idea?" as he considers introducing a read-only mode to avoid interrupting users during scheduled downtime. Steph has started a new project and explores the idea of merging separate, but similar, applications into one codebase. +They also dive into micro-service environments to discuss the difficulties of integration testing and potential strategies. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +Earth, Wind & Fire - September (https://youtu.be/Gs069dndIYk) +ActiveRecord Persistence (https://api.rubyonrails.org/files/activerecord/lib/active_record/persistence_rb.html) +Amazon SQS (https://aws.amazon.com/sqs/) +Swagger (https://swagger.io/docs/) +GraphQL (https://graphql.org/) +VCR (https://github.com/vcr/vcr) +The Bike Shed VCR episode - 189: It's Gonna Work, Definitely, No Problems Whatsoever (https://www.bikeshed.fm/189) +Capybara Discoball (https://github.com/thoughtbot/capybara_discoball) +React Podcast Episode - 110: Sam Selikoff on Finding a Full Stack React (https://spec.fm/podcasts/reactpodcast/X1swadgC) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + persistence, ruby, rails, testing, microservices + + On this week's episode, Chris introduces a new segment called "Good Idea, Terrible Idea?" as he considers introducing a read-only mode to avoid interrupting users during scheduled downtime. Steph has started a new project and explores the idea of merging separate, but similar, applications into one codebase.

+ +

They also dive into micro-service environments to discuss the difficulties of integration testing and potential strategies.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris introduces a new segment called "Good Idea, Terrible Idea?" as he considers introducing a read-only mode to avoid interrupting users during scheduled downtime. Steph has started a new project and explores the idea of merging separate, but similar, applications into one codebase.

+ +

They also dive into micro-service environments to discuss the difficulties of integration testing and potential strategies.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+FFI7kHTM + + ]]> + + + + 261: A Jenga Tower of Lets and Context + https://bikeshed.thoughtbot.com/261 + 96c847da-0512-44d0-9bbe-f35976400312 + Tue, 22 Sep 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris tackle a listener question around composition over inheritance, especially in the context of Rails which makes regular use of inheritance. Dependency injection, OOP vs FP, frameworks vs app code -- they hit it all! + +They also chat about burnout and how they've dealt with it, using jq to investigate differences between json responses, refactoring tests and using `let`, and Steph shares her recent learnings about graphviz. + 52:30 + no + + On this week's episode, Steph and Chris tackle a listener question around composition over inheritance, especially in the context of Rails which makes regular use of inheritance. Dependency injection, OOP vs FP, frameworks vs app code -- they hit it all! +They also chat about burnout and how they've dealt with it, using jq to investigate differences between json responses, refactoring tests and using let, and Steph shares her recent learnings about graphviz. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +ExpressVPN (https://www.expressvpn.com/BIKESHED) - Click through to get get an extra three months FREE on a one-year package! +Getting Back to Work by Carl Reyes (https://thoughtbot.com/blog/authors/carl-reyes) +"If you're feeling down lately, here's a quick test to figure out why" tweet (https://twitter.com/levelsio/status/1187045109063225345) +jq (https://stedolan.github.io/jq/) (command-line JSON processor) +lets not (https://thoughtbot.com/blog/lets-not) +graphviz (https://graphviz.org/) +Composition over Inheritance on Upcase (https://thoughtbot.com/upcase/videos/composition-over-inheritance) +React hooks, composition (https://reactjs.org/docs/composition-vs-inheritance.html) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph and Chris tackle a listener question around composition over inheritance, especially in the context of Rails which makes regular use of inheritance. Dependency injection, OOP vs FP, frameworks vs app code -- they hit it all!

+ +

They also chat about burnout and how they've dealt with it, using jq to investigate differences between json responses, refactoring tests and using let, and Steph shares her recent learnings about graphviz.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to get get an extra three months FREE on a one-year package!
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris tackle a listener question around composition over inheritance, especially in the context of Rails which makes regular use of inheritance. Dependency injection, OOP vs FP, frameworks vs app code -- they hit it all!

+ +

They also chat about burnout and how they've dealt with it, using jq to investigate differences between json responses, refactoring tests and using let, and Steph shares her recent learnings about graphviz.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to get get an extra three months FREE on a one-year package!
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+LaK_d0lA + + ]]> + + + + 260: N+1s For Days + https://bikeshed.thoughtbot.com/260 + dfcb7d9c-cf95-430b-9264-c8a4cae081c0 + Tue, 15 Sep 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris shares a tale of performance improvements and a recent discussion about replacing a REST API with GraphQL. Steph dives into migrating a database column to restrict input and dropping database columns safely. They also discuss when to abstract code (a topic that surprisingly, they may not agree on) and running "Unused" to identify dead code. + 44:59 + no + + On this week's episode, Chris shares a tale of performance improvements and a recent discussion about replacing a REST API with GraphQL. Steph dives into migrating a database column to restrict input and dropping database columns safely. They also discuss when to abstract code (a topic that surprisingly, they may not agree on) and running "Unused" to identify dead code. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +ActiveRecord - ignore_columns (https://apidock.com/rails/v6.0.0/ActiveRecord/ModelSchema/ClassMethods/ignored_columns) +strong_migrations (https://github.com/ankane/strong_migrations) +Rails Issue - ActiveRecord enum: use validation if exists instead of raising ArgumentError (https://github.com/rails/rails/issues/13971) +Insomnia (https://insomnia.rest/) +Unused (https://unused.codes/) +Using Vim with ctags (https://thoughtbot.com/upcase/videos/intelligent-navigation-with-ctags) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + GraphQL, rails, cache, postgres, unused + + On this week's episode, Chris shares a tale of performance improvements and a recent discussion about replacing a REST API with GraphQL. Steph dives into migrating a database column to restrict input and dropping database columns safely. They also discuss when to abstract code (a topic that surprisingly, they may not agree on) and running "Unused" to identify dead code.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris shares a tale of performance improvements and a recent discussion about replacing a REST API with GraphQL. Steph dives into migrating a database column to restrict input and dropping database columns safely. They also discuss when to abstract code (a topic that surprisingly, they may not agree on) and running "Unused" to identify dead code.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+yIexLoO5 + + ]]> + + + + 259: That's Not How Numbers Work + https://bikeshed.thoughtbot.com/259 + edd72357-ea65-47f0-a715-6c22053799fb + Tue, 08 Sep 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris tackle the thorny topic of 10X engineers. Do we think they really exist? What characteristics make an individual more effective, and more importantly, what can they do for a team? + +To round out the conversation, they chat about rewrites and when they do and don't make sense, Ruby 2.7 keyword argument deprecation warnings, and a listener question revisiting Ruby popularity and what languages would we learn if we couldn't write Ruby anymore. + 48:43 + no + + On this week's episode, Steph and Chris tackle the thorny topic of 10X engineers. Do we think they really exist? What characteristics make an individual more effective, and more importantly, what can they do for a team? +To round out the conversation, they chat about rewrites and when they do and don't make sense, Ruby 2.7 keyword argument deprecation warnings, and a listener question revisiting Ruby popularity and what languages would we learn if we couldn't write Ruby anymore. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +Ruby 2.7 Deprecates Conversion Of Keyword Arguments (https://blog.bigbinary.com/2020/04/14/ruby-2-7-deprecates-conversion-of-keyword-arguments.html) +GitHub - Upgrading GitHub to Ruby 2.7 (https://github.blog/2020-08-25-upgrading-github-to-ruby-2-7/) +Matz -- New 2.7/3.0 keyword argument pain point (https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argument-pain-point/74980) +warnings gem (https://github.com/jeremyevans/ruby-warning) +Bike Shed 217 (https://www.bikeshed.fm/217) -- we answer "encouraging companies to use Ruby and Rails and asking how we identify ourselves as developers" +Bike Shed 208 (https://www.bikeshed.fm/208) -- we answer "what makes Rails successful?" +Bike Shed 234 (https://www.bikeshed.fm/234) -- we answer "the complex tradeoffs between craft, preferences, and business needs" +GitHub Survey - Top Languages (https://octoverse.github.com/#top-languages) +Stack Overflow survey - Programming Languages (https://insights.stackoverflow.com/survey/2019#technology-_-programming-scripting-and-markup-languages) +Google Trends - Dynamic Programming Languages (https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F06ff5,%2Fm%2F05z1_,%2Fm%2F02p97) +2020 Ruby on Rails Community Survey Results (https://rails-hosting.com/2020/) +Ruby on Rails Podcast - 2020 Ruby on Rails Community Survey with Robby Russell (https://5by5.tv/rubyonrails/332) +Rust - Are we web yet? (https://www.arewewebyet.org/) +10x engineer thread from 2019 (https://twitter.com/skirani/status/1149302828420067328) +Alice Goldfuss twitter thread on honesty in teams (https://twitter.com/alicegoldfuss/status/1298094389122629632?s=21) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph and Chris tackle the thorny topic of 10X engineers. Do we think they really exist? What characteristics make an individual more effective, and more importantly, what can they do for a team?

+ +

To round out the conversation, they chat about rewrites and when they do and don't make sense, Ruby 2.7 keyword argument deprecation warnings, and a listener question revisiting Ruby popularity and what languages would we learn if we couldn't write Ruby anymore.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris tackle the thorny topic of 10X engineers. Do we think they really exist? What characteristics make an individual more effective, and more importantly, what can they do for a team?

+ +

To round out the conversation, they chat about rewrites and when they do and don't make sense, Ruby 2.7 keyword argument deprecation warnings, and a listener question revisiting Ruby popularity and what languages would we learn if we couldn't write Ruby anymore.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+WpfOLj_r + + ]]> + + + + 258: Digital Gardeners + https://bikeshed.thoughtbot.com/258 + b805a93a-3fc0-4f67-b596-3d635c9306d2 + Tue, 01 Sep 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss a git-blame feature that supports bypassing less helpful commits. They also revisit a discussion about Dependabot PRs and recent performance adjustments, sharing which strategies worked and which ones didn't. They also discuss the dreaded three-state boolean, designing a system for cacheability, and using Ruby's magic comment to freeze string literals. + 41:14 + no + + On this week's episode, Steph and Chris discuss a git-blame feature that supports bypassing less helpful commits. They also revisit a discussion about Dependabot PRs and recent performance adjustments, sharing which strategies worked and which ones didn't. They also discuss the dreaded three-state boolean, designing a system for cacheability, and using Ruby's magic comment to freeze string literals. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +Trello Account Switching Feature (https://blog.trello.com/trello-account-switcher-feature) +Git feature: ignore-revs-file (https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt) +Chris's Tweet about ignore-revs-file (https://twitter.com/christoomey/status/1295790063008141312) +Strong Migrations (https://github.com/ankane/strong_migrations) +MemCachier (https://devcenter.heroku.com/articles/memcachier) +Ruby 2.3 - magic comment to freeze string literals (https://www.ruby-lang.org/en/news/2015/12/25/ruby-2-3-0-released/) + + git, ruby, performance, cache, dependabot + + On this week's episode, Steph and Chris discuss a git-blame feature that supports bypassing less helpful commits. They also revisit a discussion about Dependabot PRs and recent performance adjustments, sharing which strategies worked and which ones didn't. They also discuss the dreaded three-state boolean, designing a system for cacheability, and using Ruby's magic comment to freeze string literals.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris discuss a git-blame feature that supports bypassing less helpful commits. They also revisit a discussion about Dependabot PRs and recent performance adjustments, sharing which strategies worked and which ones didn't. They also discuss the dreaded three-state boolean, designing a system for cacheability, and using Ruby's magic comment to freeze string literals.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Ywgh76J7 + + ]]> + + + + 257: How Late On a Friday Can You Deploy? + https://bikeshed.thoughtbot.com/257 + 313b8cc9-4509-4a48-a2d6-f538eb9e196f + Tue, 18 Aug 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph & Chris take a deep dive into all things technical debt. How do you know when your code has reached "good enough"? When might we purposefully knowingly take on technical debt? How do we tackle existing technical debt without halting new development? How can we tell high-interest, hair on fire debt from "ehh, it's fine" debt that we can let lie? Tune in to find out! + 50:27 + no + + On this week's episode, Steph & Chris take a deep dive into all things technical debt. How do you know when your code has reached "good enough"? When might we purposefully knowingly take on technical debt? How do we tackle existing technical debt without halting new development? How can we tell high-interest, hair on fire debt from "ehh, it's fine" debt that we can let lie? Tune in to find out! +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +FusionAuth (http://fusionauth.io/podcast) - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code BIKESHED +Rack::Timeout Sigterm (https://github.com/sharpstone/rack-timeout/pull/157) +The Art of Code Comments - Sarah Drasner | JSConf Hawaii 2020 (https://www.youtube.com/watch?v=yhF7OmuIILc) +Technical Debt Panel from thoughtbot (https://thoughtbot.wistia.com/medias/msdwdg790m) +Gary Bernhardt on Full Stack Radio (https://www.fullstackradio.com/episodes/144) +Sandy Metz - The Halflife of Code (https://sandimetz.com/blog/2017/6/1/the-half-life-of-code) +Code Climate Churn vs Complexity Graph (https://docs.codeclimate.com/docs/churn) +Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! + + + On this week's episode, Steph & Chris take a deep dive into all things technical debt. How do you know when your code has reached "good enough"? When might we purposefully knowingly take on technical debt? How do we tackle existing technical debt without halting new development? How can we tell high-interest, hair on fire debt from "ehh, it's fine" debt that we can let lie? Tune in to find out!

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • FusionAuth - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code BIKESHED
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph & Chris take a deep dive into all things technical debt. How do you know when your code has reached "good enough"? When might we purposefully knowingly take on technical debt? How do we tackle existing technical debt without halting new development? How can we tell high-interest, hair on fire debt from "ehh, it's fine" debt that we can let lie? Tune in to find out!

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • FusionAuth - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code BIKESHED
    • +
+ +
+ + + +

Become a Sponsor of The Bike Shed!

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+gJi5tS7b + + ]]> + + + + 256: Rational Pessimism + https://bikeshed.thoughtbot.com/256 + 0f6eb8e4-947e-4626-9029-fd211332e3d9 + Tue, 11 Aug 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris shares his recent adventures of working with a team that prioritizes async-first communication and Steph revisits a previous discussion around the use of web sockets and optimistic user interfaces. They also dive into the classically hard question "should we rewrite the app?" and share survival tips for learning to type on a split keyboard. + 46:31 + no + + On this week's episode, Chris shares his recent adventures of working with a team that prioritizes async-first communication and Steph revisits a previous discussion around the use of web sockets and optimistic user interfaces. They also dive into the classically hard question "should we rewrite the app?" and share survival tips for learning to type on a split keyboard. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +Telegram (https://telegram.org/) +Phoenix Channels JavaScript client (https://hexdocs.pm/phoenix/js/) +Express.js (https://expressjs.com/) +MongoDB (https://www.mongodb.com/) +ErgoDox Keyboard (https://ergodox-ez.com/) +A Modern Space Cadet (https://stevelosh.com/blog/2012/10/a-modern-space-cadet/) +Atreus Keyboard (https://atreus.technomancy.us/) +Moonlander Keyboard (https://ergodox-ez.com/) + + team communication, phoenix, web sockets, javascript, mechanical keyboard + + On this week's episode, Chris shares his recent adventures of working with a team that prioritizes async-first communication and Steph revisits a previous discussion around the use of web sockets and optimistic user interfaces. They also dive into the classically hard question "should we rewrite the app?" and share survival tips for learning to type on a split keyboard.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris shares his recent adventures of working with a team that prioritizes async-first communication and Steph revisits a previous discussion around the use of web sockets and optimistic user interfaces. They also dive into the classically hard question "should we rewrite the app?" and share survival tips for learning to type on a split keyboard.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+PO5szpuC + + ]]> + + + + 255: Aiming for 'Capable' + https://bikeshed.thoughtbot.com/255 + 0ecb3b3b-dc04-4917-9314-42eb5f73f0c7 + Tue, 04 Aug 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris chat about the relatively new Rails view_component library from GitHub, Steph talks about her work with Storybook as part of extracting and defining a design system, and they chat about the attr_extras project with convenience helpers for ruby & Rails apps. They round out the conversation with some keyboard updates (ErgoDox onramp is steep!) and project rotation notes. + 28:47 + no + + On this week's episode, Steph and Chris chat about the relatively new Rails viewcomponent library from GitHub, Steph talks about her work with Storybook as part of extracting and defining a design system, and they chat about the attrextras project with convenience helpers for ruby & Rails apps. They round out the conversation with some keyboard updates (ErgoDox onramp is steep!) and project rotation notes. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +ErgoDox (https://ergodox-ez.com/) +Atreus Keyboard (https://atreus.technomancy.us/) +Rails view_component (https://github.com/github/view_component) +Storybook.js (https://storybook.js.org/) +Styleguidist (https://react-styleguidist.js.org/) +attr_extras (https://github.com/barsoom/attr_extras) +Sorbet static types for Ruby (https://sorbet.org/) + + + On this week's episode, Steph and Chris chat about the relatively new Rails view_component library from GitHub, Steph talks about her work with Storybook as part of extracting and defining a design system, and they chat about the attr_extras project with convenience helpers for ruby & Rails apps. They round out the conversation with some keyboard updates (ErgoDox onramp is steep!) and project rotation notes.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris chat about the relatively new Rails view_component library from GitHub, Steph talks about her work with Storybook as part of extracting and defining a design system, and they chat about the attr_extras project with convenience helpers for ruby & Rails apps. They round out the conversation with some keyboard updates (ErgoDox onramp is steep!) and project rotation notes.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+cu8KrP2t + + ]]> + + + + 254: Listener Mailbag Roundup Rodeo + https://bikeshed.thoughtbot.com/254 + 5ca5c5d1-80c3-487b-9dfd-f42c60e8a0ab + Tue, 28 Jul 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph celebrates passing an important test and discovers an API that returns different data than it's provided while Chris asks the important bikeshed question "What is the proper maximum line length?". They also roundup the latest listener questions and discuss establishing freelancing rates, property-based testing, and time tracking skills that help them manage competing priorities. + 42:26 + no + + On this week's episode, Steph celebrates passing an important test and discovers an API that returns different data than it's provided while Chris asks the important bikeshed question "What is the proper maximum line length?". +They also roundup the latest listener questions and discuss establishing freelancing rates, property-based testing, and time tracking skills that help them manage competing priorities. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Prettier Ruby (https://github.com/prettier/plugin-ruby) +Toptal (https://www.toptal.com/) +Upwork (https://www.upwork.com/) +QuickCheck (https://en.wikipedia.org/wiki/QuickCheck) +Hypothesis (https://hypothesis.readthedocs.io/en/latest/) +Rantly (https://github.com/rantly-rb/rantly) + + freelancing, ruby, time management, testing + + On this week's episode, Steph celebrates passing an important test and discovers an API that returns different data than it's provided while Chris asks the important bikeshed question "What is the proper maximum line length?".

+ +

They also roundup the latest listener questions and discuss establishing freelancing rates, property-based testing, and time tracking skills that help them manage competing priorities.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph celebrates passing an important test and discovers an API that returns different data than it's provided while Chris asks the important bikeshed question "What is the proper maximum line length?".

+ +

They also roundup the latest listener questions and discuss establishing freelancing rates, property-based testing, and time tracking skills that help them manage competing priorities.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+JU6ZS8WA + + ]]> + + + + 253: Find Yourself Through The Art of Podcast + https://bikeshed.thoughtbot.com/253 + ce60d7a3-6845-414e-b133-a25ad384750b + Tue, 21 Jul 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris have a brief chat about Snowpack, a new and ultra-speedy bundler in the front-end world, and revisit a conversation around namespacing models in Rails. The conversation then shifts to a discussion of the ins and outs of hosting a podcast and how folks might be able to dive in if they're interested in starting one themselves -- from selecting topics, to the hardware and software they use, to the guiding philosophy in how to discuss technical concepts. + 46:34 + no + + On this week's episode, Steph and Chris have a brief chat about Snowpack, a new and ultra-speedy bundler in the front-end world, and revisit a conversation around namespacing models in Rails. The conversation then shifts to a discussion of the ins and outs of hosting a podcast and how folks might be able to dive in if they're interested in starting one themselves -- from selecting topics, to the hardware and software they use, to the guiding philosophy in how to discuss technical concepts. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post +"Selling Technical Debt Back to The Business" workshop (http://tbot.io/tech-debt) +Snowpack (https://www.snowpack.dev/) +Vite (https://github.com/vitejs/vite) +React Fast Refresh (https://github.com/facebook/react/issues/16604#issuecomment-528663101) +Saron's tweet about questions re: starting a podcast (https://twitter.com/saronyitbarek/status/1269364274025152514) +The War of Art (https://stevenpressfield.com/books/the-war-of-art/) +Fireside.fm (https://fireside.fm/) +AudioHijack (https://rogueamoeba.com/audiohijack/) +ZenCastr (https://zencastr.com/) +Audio-Technica ATR2100x-USB Microphone (https://www.amazon.com/Audio-Technica-ATR2100x-USB-Cardioid-Microphone-ATR/dp/B07ZPBFVKK) +Shure SM7Bs (https://www.shure.com/en-US/products/microphones/sm7b) +Foam Mic Cover (aka pop filter, aka windscreen (https://www.amazon.com/gp/product/B019OO4IY6/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1) +Patreon (https://www.patreon.com/) +The Ginger People (https://gingerpeople.com/) + + snowpack, podcasting, rails + + On this week's episode, Steph and Chris have a brief chat about Snowpack, a new and ultra-speedy bundler in the front-end world, and revisit a conversation around namespacing models in Rails. The conversation then shifts to a discussion of the ins and outs of hosting a podcast and how folks might be able to dive in if they're interested in starting one themselves -- from selecting topics, to the hardware and software they use, to the guiding philosophy in how to discuss technical concepts.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris have a brief chat about Snowpack, a new and ultra-speedy bundler in the front-end world, and revisit a conversation around namespacing models in Rails. The conversation then shifts to a discussion of the ins and outs of hosting a podcast and how folks might be able to dive in if they're interested in starting one themselves -- from selecting topics, to the hardware and software they use, to the guiding philosophy in how to discuss technical concepts.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • Indeed - Click through and get started with a free seventy five dollar credit for your first job post
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+kyNy9vqz + + ]]> + + + + 252: I'm a Designer Now + https://bikeshed.thoughtbot.com/252 + 9a6bb833-9811-41fd-8da6-1f88ed3acbb7 + Tue, 14 Jul 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss leveraging the Unix utility `sed` to search files and remove unnecessary test setup, using Vim's Arglist to create a to-do list for file edits, and budgeting time for fancy command-line scripts. They then take a deep dive into the world of utility-first CSS and TailwindCSS. + 54:50 + no + + On this week's episode, Steph and Chris discuss leveraging the Unix utility sed to search files and remove unnecessary test setup, using Vim's Arglist to create a to-do list for file edits, and budgeting time for fancy command-line scripts. They then take a deep dive into the world of utility-first CSS and TailwindCSS. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy +ExpressVPN (https://www.expressvpn.com/bikeshed) - Click through to get get an extra three months FREE on a one-year package +Register here to attend the free panel discussion "How to sell technical debt to the business" (https://tbot.io/tech-debt) +sed (https://www.gnu.org/software/sed/manual/sed.html) +The Unix Chainsaw by Gary Bernhardt (https://youtu.be/ZQnyApKysg4) +awk (https://en.wikipedia.org/wiki/AWK) +Vim's Arglist as a File-Centric Todo List (https://ctoomey.com/writing/using-vims-arglist-as-a-todo-list/) +xkcd (https://xkcd.com/) +React Podcast - 88: Adam Wathan on Making Your Own Money, Refactoring UI, and tailwindcss (https://reactpodcast.com/episodes/88) +Tailwind CSS (https://tailwindcss.com/) +Tailwind Cheat Sheet (https://nerdcave.com/tailwind-cheat-sheet) +Redesigning the Tuple Client UI (https://tuple.app/blog/redesign) +Bourbon (https://github.com/thoughtbot/bourbon) +PurgeCSS (https://purgecss.com/) +thoughtbot dotfiles (https://github.com/thoughtbot/dotfiles) +PostCSS (https://postcss.org/) + + sed, awk, tailwind css, css, rails, react, vim + + On this week's episode, Steph and Chris discuss leveraging the Unix utility sed to search files and remove unnecessary test setup, using Vim's Arglist to create a to-do list for file edits, and budgeting time for fancy command-line scripts. They then take a deep dive into the world of utility-first CSS and TailwindCSS.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to get get an extra three months FREE on a one-year package
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris discuss leveraging the Unix utility sed to search files and remove unnecessary test setup, using Vim's Arglist to create a to-do list for file edits, and budgeting time for fancy command-line scripts. They then take a deep dive into the world of utility-first CSS and TailwindCSS.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy
    • +
  • ExpressVPN - Click through to get get an extra three months FREE on a one-year package
    • +
+ +
+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+qa2b0qU- + + ]]> + + + + 251: Absent-Minded Whistling + https://bikeshed.thoughtbot.com/251 + 2628e8f2-613c-483a-85c1-887d6596530e + Tue, 07 Jul 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss using JSONB to store survey responses and the differences between JSON and JSONB, using (or not using!) exceptions in Ruby and the `fail` keyword, the pros and cons of namespacing models in Rails to organize features, and a new recommendation for running tests from vim. + 37:27 + no + + On this week's episode, Steph and Chris discuss using JSONB to store survey responses and the differences between JSON and JSONB, using (or not using!) exceptions in Ruby and the fail keyword, the pros and cons of namespacing models in Rails to organize features, and a new recommendation for running tests from vim. +This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Seagull Mic Drop (https://i.kym-cdn.com/photos/images/facebook/001/383/162/20c.jpg) +vim-test (https://github.com/vim-test/vim-test) plugin for running tests +vim-rspec (https://github.com/thoughtbot/vim-rspec) thoughtbot's plugin for running specs from vim +JSON types in Postgres (https://www.postgresql.org/docs/9.4/datatype-json.html) +Ruby fail keyword (https://apidock.com/ruby/Kernel/fail) +Avdi Grimm and Jim Weirich on exceptions (https://avdi.codes/jim-weirich-on-exceptions/) +The Zen of Python (https://www.python.org/dev/peps/pep-0020/) +Idris programming language (https://www.idris-lang.org/) + + json, jsonb, ruby, rails, vim, test + + On this week's episode, Steph and Chris discuss using JSONB to store survey responses and the differences between JSON and JSONB, using (or not using!) exceptions in Ruby and the fail keyword, the pros and cons of namespacing models in Rails to organize features, and a new recommendation for running tests from vim.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris discuss using JSONB to store survey responses and the differences between JSON and JSONB, using (or not using!) exceptions in Ruby and the fail keyword, the pros and cons of namespacing models in Rails to organize features, and a new recommendation for running tests from vim.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+tWu2GL74 + + ]]> + + + + 250: To Infinity and Beyond + https://bikeshed.thoughtbot.com/250 + f8bd8aa4-7736-4713-908d-1dec20dd37a0 + Tue, 30 Jun 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss the importance of using inclusive language, branching into new branch names, and strategies that encourage the use of inclusive terminology. Chris also shares his latest experience with merging two systems that were split apart back into one system, tackling conflicting foreign keys and competing auth libraries. Steph discusses using polling vs web sockets to monitor work being completed in a background job and communicating to the user the various states of success and failure. + 42:05 + no + + On this week's episode, Chris and Steph discuss the importance of using inclusive language, branching into new branch names, and strategies that encourage the use of inclusive terminology. Chris also shares his latest experience with merging two systems that were split apart back into one system, tackling conflicting foreign keys and competing auth libraries. Steph discusses using polling vs web sockets to monitor work being completed in a background job and communicating to the user the various states of success and failure. +Seagulls are the Worst (https://www.youtube.com/watch?v=U9t-slLl30E) +Angie Jones (https://twitter.com/techgirl1908) +Tatiana Mac (https://twitter.com/TatianaTMac) +Pariss Athena (https://twitter.com/ParissAthena) +Renaming factorygirl to factorybot (https://thoughtbot.com/blog/factory_bot) +Juneteenth (https://en.wikipedia.org/wiki/Juneteenth) +Empathy Online (https://thoughtbot.com/blog/empathy-online) +SlackBot - Keep Conversations Inclusive (https://thoughtbot.com/blog/slack-tips-for-building-trust#keep-conversations-inclusive) +Clearance (https://github.com/thoughtbot/clearance) +Devise (https://github.com/heartcombo/devise) +Active Model Serializers (https://github.com/rails-api/active_model_serializers) +Blueprinter (https://github.com/procore/blueprinter) +203: A Blessed Monkeypatch (Eileen M. Uchitelle) (https://www.bikeshed.fm/203) +JWT (https://en.wikipedia.org/wiki/JSON_Web_Token) +Action Cable (https://guides.rubyonrails.org/action_cable_overview.html) +Akka Streams (https://doc.akka.io/docs/akka/2.5.31/typed/stream.html) + + inclusive language, microservices, rails, react, web sockets + + On this week's episode, Chris and Steph discuss the importance of using inclusive language, branching into new branch names, and strategies that encourage the use of inclusive terminology. Chris also shares his latest experience with merging two systems that were split apart back into one system, tackling conflicting foreign keys and competing auth libraries. Steph discusses using polling vs web sockets to monitor work being completed in a background job and communicating to the user the various states of success and failure.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph discuss the importance of using inclusive language, branching into new branch names, and strategies that encourage the use of inclusive terminology. Chris also shares his latest experience with merging two systems that were split apart back into one system, tackling conflicting foreign keys and competing auth libraries. Steph discusses using polling vs web sockets to monitor work being completed in a background job and communicating to the user the various states of success and failure.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+55raZyMn + + ]]> + + + + 249: What Would You Say You Do Here? + https://bikeshed.thoughtbot.com/249 + 129d509d-142e-46f6-aea3-1ef1aeb8382e + Tue, 23 Jun 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris trade some consulting and everyone comes out a winner. Steph talks about a win and a loss on the battlefield of refactoring, and Chris shares a related effort around identifying and removing unused code. Chris shares a pattern his team has been using with a special "demo" flag to provide small enhancements but otherwise keep sales demos within the product. + +Steph then shares some friction related to using dependabot on her team's project that hints at more foundational ideas at the intersection of workflow, team dynamics, testing, deployment. And finally, Chris asks Steph for her thoughts on how best to add testing around the structure of API responses. + 41:02 + no + + On this week's episode, Steph and Chris trade some consulting and everyone comes out a winner. Steph talks about a win and a loss on the battlefield of refactoring, and Chris shares a related effort around identifying and removing unused code. Chris shares a pattern his team has been using with a special "demo" flag to provide small enhancements but otherwise keep sales demos within the product. +Steph then shares some friction related to using dependabot on her team's project that hints at more foundational ideas at the intersection of workflow, team dynamics, testing, deployment. And finally, Chris asks Steph for her thoughts on how best to add testing around the structure of API responses. +This episode is brought to you by Datadog (http://datadog.com/thebikeshed). Click through to get a free 14-day trial and a free Datadog t-shirt! +Coverband (https://github.com/danmayer/coverband) for production code coverage +Flipper feature flag gem (https://github.com/jnunemaker/flipper) +Dependabot (https://dependabot.com/) +JSON Schema (https://json-schema.org/) +Swagger (https://swagger.io/) +rspec-request_snapshot (https://github.com/CareMessagePlatform/rspec-request_snapshot) +Say no to more process, say yes to trust (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) +One electron theory (https://en.wikipedia.org/wiki/One-electron_universe) + + + On this week's episode, Steph and Chris trade some consulting and everyone comes out a winner. Steph talks about a win and a loss on the battlefield of refactoring, and Chris shares a related effort around identifying and removing unused code. Chris shares a pattern his team has been using with a special "demo" flag to provide small enhancements but otherwise keep sales demos within the product.

+ +

Steph then shares some friction related to using dependabot on her team's project that hints at more foundational ideas at the intersection of workflow, team dynamics, testing, deployment. And finally, Chris asks Steph for her thoughts on how best to add testing around the structure of API responses.

+ +

This episode is brought to you by Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris trade some consulting and everyone comes out a winner. Steph talks about a win and a loss on the battlefield of refactoring, and Chris shares a related effort around identifying and removing unused code. Chris shares a pattern his team has been using with a special "demo" flag to provide small enhancements but otherwise keep sales demos within the product.

+ +

Steph then shares some friction related to using dependabot on her team's project that hints at more foundational ideas at the intersection of workflow, team dynamics, testing, deployment. And finally, Chris asks Steph for her thoughts on how best to add testing around the structure of API responses.

+ +

This episode is brought to you by Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+exz3Atbm + + ]]> + + + + 248: Here Be Dragons + https://bikeshed.thoughtbot.com/248 + 703bda3b-382f-4513-979e-d57d2c7d5a57 + Tue, 16 Jun 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph shares a keyboard confession and interest in migrating to a split keyboard layout. Chris dives into creating static error pages that are independent of the app while still leveraging the app's CSS framework. They also respond to a listener question about Conventional Commits and discuss when automation tooling feels helpful vs harmful. + 34:16 + no + + On this week's episode, Steph shares a keyboard confession and interest in migrating to a split keyboard layout. Chris dives into creating static error pages that are independent of the app while still leveraging the app's CSS framework. They also respond to a listener question about Conventional Commits and discuss when automation tooling feels helpful vs harmful. +ErgoDox EZ Keyboard (https://ergodox-ez.com/) +Keyboardio Atreus (https://www.kickstarter.com/projects/keyboardio/atreus) +Tailwind CSS (https://tailwindcss.com/) +PurgeCSS (https://purgecss.com/) +CSS Used Chrome Extension (https://chrome.google.com/webstore/detail/css-used/cdopjfddjlonogibjahpnmjpoangjfff?hl=en) +Conventional Commits (https://www.conventionalcommits.org/en/v1.0.0-beta.2/) +SemVer (https://semver.org/) +semantic-release (https://github.com/semantic-release/semantic-release) +husky (https://github.com/typicode/husky) +GitHub Issue and Pull Request Templates (https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates) + + keyboard, css, rails, tailwind css, git, commit + + On this week's episode, Steph shares a keyboard confession and interest in migrating to a split keyboard layout. Chris dives into creating static error pages that are independent of the app while still leveraging the app's CSS framework. They also respond to a listener question about Conventional Commits and discuss when automation tooling feels helpful vs harmful.

+ +

ErgoDox EZ Keyboard
+Keyboardio Atreus
+Tailwind CSS
+PurgeCSS
+CSS Used Chrome Extension
+Conventional Commits
+SemVer
+semantic-release
+husky
+GitHub Issue and Pull Request Templates

Support The Bike Shed

]]> + + + On this week's episode, Steph shares a keyboard confession and interest in migrating to a split keyboard layout. Chris dives into creating static error pages that are independent of the app while still leveraging the app's CSS framework. They also respond to a listener question about Conventional Commits and discuss when automation tooling feels helpful vs harmful.

+ +

ErgoDox EZ Keyboard
+Keyboardio Atreus
+Tailwind CSS
+PurgeCSS
+CSS Used Chrome Extension
+Conventional Commits
+SemVer
+semantic-release
+husky
+GitHub Issue and Pull Request Templates

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+vK9sXH1X + + ]]> + + + + 247: Acronyms By Moonlight + https://bikeshed.thoughtbot.com/247 + f4eac01b-b2a9-4201-b467-d746fc683c92 + Tue, 09 Jun 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss potential approaches to a complex client-side workflow, Chris shares the highs and lows of his recent adventures revising the caching in a REST API, Steph shares an Ember testing pro-tip and then explores the questions it brings up, and lastly, they revisit prettier-ruby and it's fantastic configuration setup. + 49:28 + no + + On this week's episode, Steph and Chris discuss potential approaches to a complex client-side workflow, Chris shares the highs and lows of his recent adventures revising the caching in a REST API, Steph shares an Ember testing pro-tip and then explores the questions it brings up, and lastly, they revisit prettier-ruby and it's fantastic configuration setup. +This episode is brought to you by Datadog (http://datadog.com/thebikeshed). Click through to get a free 14-day trial and a free Datadog t-shirt! +prettier-ruby configuration (https://github.com/prettier/plugin-ruby#configuration) +Chrome DevTools Keyboard Shortcuts (https://developers.google.com/web/tools/chrome-devtools/shortcuts) +Test'em - Ember test runner (https://github.com/testem/testem) +Chrome full-page screenshots (https://developers.google.com/web/updates/2017/04/devtools-release-notes#screenshots) +Rails action caching (https://guides.rubyonrails.org/caching_with_rails.html#action-caching) +Memcachier (https://www.memcachier.com/) +Rails stale? and fresh_when etag calculation (https://guides.rubyonrails.org/caching_with_rails.html#conditional-get-support) +Rails cache method for "fragment caching" (https://guides.rubyonrails.org/caching_with_rails.html#fragment-caching) +Rails travel_to time helpers (https://api.rubyonrails.org/v5.2.4.3/classes/ActiveSupport/Testing/TimeHelpers.html) +Rspec and_call_original (https://relishapp.com/rspec/rspec-mocks/v/2-14/docs/message-expectations/calling-the-original-method) +Single-table inheritance vs. polymorphic associations in Rails (https://www.freecodecamp.org/news/single-table-inheritance-vs-polymorphic-associations-in-rails-af3a07a204f2/) +Inertia.js (https://inertiajs.com/) + + + On this week's episode, Steph and Chris discuss potential approaches to a complex client-side workflow, Chris shares the highs and lows of his recent adventures revising the caching in a REST API, Steph shares an Ember testing pro-tip and then explores the questions it brings up, and lastly, they revisit prettier-ruby and it's fantastic configuration setup.

+ +

This episode is brought to you by Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris discuss potential approaches to a complex client-side workflow, Chris shares the highs and lows of his recent adventures revising the caching in a REST API, Steph shares an Ember testing pro-tip and then explores the questions it brings up, and lastly, they revisit prettier-ruby and it's fantastic configuration setup.

+ +

This episode is brought to you by Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+E5TDRR3_ + + ]]> + + + + 246: A True Movement (Pariss Athena) + https://bikeshed.thoughtbot.com/246 + 482752dc-fa21-4503-9bb0-58132a30e3ca + Tue, 02 Jun 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + We are pausing our normal tech-talk this week in support of the ongoing protests and to re-share the #BlackTechTwitter episode with Pariss Athena from our sister podcast, Giant Robots. + +During the past week, millions of people across the country have participated in protests in response to the killing of George Floyd and the systemic racism that plagues our nation. + +For everyone fighting for equality and justice, we see you, we love you, and we support you. Black lives matter. Black culture matters. Black communities matter. + +For those looking for ways to take action, we have provided a few resources in the show notes. The list is intentionally short as we ask everyone to research ways to get involved and listen to leaders in the Black community. + +Fighting for equality falls on each of us, regardless of race or position, to work together to fight racism and unequal treatment. + +Stay Safe. + 28:13 + no + + We are pausing our normal tech-talk this week in support of the ongoing protests and to re-share the #BlackTechTwitter episode with Pariss Athena from our sister podcast, Giant Robots. +During the past week, millions of people across the country have participated in protests in response to the killing of George Floyd and the systemic racism that plagues our nation. +For everyone fighting for equality and justice, we see you, we love you, and we support you. Black lives matter. Black culture matters. Black communities matter. +For those looking for ways to take action, we have provided a few resources in the show notes. The list is intentionally short as we ask everyone to research ways to get involved and listen to leaders in the Black community. +Fighting for equality falls on each of us, regardless of race or position, to work together to fight racism and unequal treatment. +Stay Safe. +Giant Robots: A True Movement (Pariss Athena) (https://www.giantrobots.fm/343) +Black Tech Twitter (https://twitter.com/search?q=%23BlackTechTwitter&src=saved_search_click) +Black Tech Pipeline (https://www.blacktechpipeline.com/) +Black Lives Matter (https://blacklivesmatter.com/) +Resources provided by Diversify Tech (https://twitter.com/DiversifyTechCo/status/1266797966498684928) +Original Notes from Giant Robots Episode 343 +Pariss Athena, Hiring & Product Team Member at G2i, creator of #BlackTechTwitter, and founder of Black Tech Pipeline, shares her journey from never hearing about code to viral awareness campaign creator, as well as discusses visibility, finding value on twitter, and life online with thousands of followers. +<ul><li><a href="https://www.resilientcoders.org/">Resilient Coders</a></li><li><a href="https://twitter.com/ParissAthena/status/1068873547005812737?s=20">The Tweet that started #BlackTechTwitter</a></li><li><a href="https://blockclubchicago.org/2019/08/08/hannibal-buress-is-building-an-arts-and-technology-center-for-the-future-masterminds-of-the-west-side/">"Hannibal Buress Is Building An Arts And Technology Center For The Future Masterminds Of The West Side"</a></li><li><a href="https://www.blacktechpipeline.com/">Black Tech Pipeline</a></li><li><a href="https://twitter.com/ParissAthena">Pariss on Twitter</a></li></ul> + + + We are pausing our normal tech-talk this week in support of the ongoing protests and to re-share the #BlackTechTwitter episode with Pariss Athena from our sister podcast, Giant Robots.

+ +

During the past week, millions of people across the country have participated in protests in response to the killing of George Floyd and the systemic racism that plagues our nation.

+ +

For everyone fighting for equality and justice, we see you, we love you, and we support you. Black lives matter. Black culture matters. Black communities matter.

+ +

For those looking for ways to take action, we have provided a few resources in the show notes. The list is intentionally short as we ask everyone to research ways to get involved and listen to leaders in the Black community.

+ +

Fighting for equality falls on each of us, regardless of race or position, to work together to fight racism and unequal treatment.

+ +

Stay Safe.

+ + + +
+ +

Original Notes from Giant Robots Episode 343

+ +

Pariss Athena, Hiring & Product Team Member at G2i, creator of #BlackTechTwitter, and founder of Black Tech Pipeline, shares her journey from never hearing about code to viral awareness campaign creator, as well as discusses visibility, finding value on twitter, and life online with thousands of followers.

+ +

Support The Bike Shed

]]> + + + We are pausing our normal tech-talk this week in support of the ongoing protests and to re-share the #BlackTechTwitter episode with Pariss Athena from our sister podcast, Giant Robots.

+ +

During the past week, millions of people across the country have participated in protests in response to the killing of George Floyd and the systemic racism that plagues our nation.

+ +

For everyone fighting for equality and justice, we see you, we love you, and we support you. Black lives matter. Black culture matters. Black communities matter.

+ +

For those looking for ways to take action, we have provided a few resources in the show notes. The list is intentionally short as we ask everyone to research ways to get involved and listen to leaders in the Black community.

+ +

Fighting for equality falls on each of us, regardless of race or position, to work together to fight racism and unequal treatment.

+ +

Stay Safe.

+ + + +
+ +

Original Notes from Giant Robots Episode 343

+ +

Pariss Athena, Hiring & Product Team Member at G2i, creator of #BlackTechTwitter, and founder of Black Tech Pipeline, shares her journey from never hearing about code to viral awareness campaign creator, as well as discusses visibility, finding value on twitter, and life online with thousands of followers.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+FY3G2VFY + + ]]> + + + + 245: Developer Therapy (German Velasco) + https://bikeshed.thoughtbot.com/245 + 29eba8ca-d257-4095-9a56-a0ee8ce3d53e + Wed, 27 May 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph is joined by thoughtbotter German Velasco. German and Steph chat about remote work and the rewards and challenges of their new(ish) roles as Development Team Leads. German also shares that he is writing a book! German shares his approach for defining an MVB (Minimum Viable Book), ideas for how to collect feedback, and plans for publishing. Lastly, they discuss a vim plugin that lives up to the hype. + 45:17 + no + + On this week's episode, Steph is joined by thoughtbotter German Velasco. German and Steph chat about remote work and the rewards and challenges of their new(ish) roles as Development Team Leads. German also shares that he is writing a book! German shares his approach for defining a MVB (Minimum Viable Book), ideas for how to collect feedback, and plans for publishing. Lastly, they discuss a vim plugin that lives up to the hype. +This episode is brought to you by Datadog (http://datadog.com/thebikeshed). Click through to get a free 14-day trial and a free Datadog t-shirt! +To register for the free online workshop "How to Supercharge Your Rails App with a Code Audit", visit https://thoughtbot.com/events/code-audit-workshop. +GitBook (https://www.gitbook.com/) +Michael Hartl - The Ruby on Rails Tutorial (https://www.railstutorial.org/) +Workshop - Being Human in the Absence of Humans (https://info.thoughtbot.com/remote-product-team-resources) +Workshop - How to stay agile when building compliant health tech products (https://info.thoughtbot.com/building-compliant-health-tech-products-recording) +vim-fugitive (https://github.com/tpope/vim-fugitive) +Write good commit messages by blaming others (https://thoughtbot.com/blog/write-good-commit-messages-by-blaming-others) +Upcase course featuring vim-fugitive (https://thoughtbot.com/upcase/videos/git-vim-and-git) +More episodes with German: +- 188: A Function by Any Other Name (https://www.bikeshed.fm/188) +- 167: I Feel Like We Should've Solved This By Now (https://www.bikeshed.fm/167) + + remote, team lead, mentoring, elixir, phoenix, writing, teaching + + On this week's episode, Steph is joined by thoughtbotter German Velasco. German and Steph chat about remote work and the rewards and challenges of their new(ish) roles as Development Team Leads. German also shares that he is writing a book! German shares his approach for defining a MVB (Minimum Viable Book), ideas for how to collect feedback, and plans for publishing. Lastly, they discuss a vim plugin that lives up to the hype.

+ +

This episode is brought to you by Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!

+ +

To register for the free online workshop "How to Supercharge Your Rails App with a Code Audit", visit https://thoughtbot.com/events/code-audit-workshop.

+ + + +

More episodes with German:

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph is joined by thoughtbotter German Velasco. German and Steph chat about remote work and the rewards and challenges of their new(ish) roles as Development Team Leads. German also shares that he is writing a book! German shares his approach for defining a MVB (Minimum Viable Book), ideas for how to collect feedback, and plans for publishing. Lastly, they discuss a vim plugin that lives up to the hype.

+ +

This episode is brought to you by Datadog. Click through to get a free 14-day trial and a free Datadog t-shirt!

+ +

To register for the free online workshop "How to Supercharge Your Rails App with a Code Audit", visit https://thoughtbot.com/events/code-audit-workshop.

+ + + +

More episodes with German:

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+cIMD06Tv + + ]]> + + + + 244: Existential JavaScript + https://bikeshed.thoughtbot.com/244 + 13efe0a8-7203-474a-bc2b-256d65bb632f + Tue, 19 May 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph troubleshoots a mysterious Ember test failure that can't find a visible element, and Chris recounts an exciting three-act adventure that spans N+1 queries, caching, and SQL window functions. Steph also touches on upgrading to Ember Octane and Glimmer components and Chris shares a new helpful tool for drawing architecture diagrams. + 40:54 + no + + On this week's episode, Steph troubleshoots a mysterious Ember test failure that can't find a visible element, and Chris recounts an exciting three-act adventure that spans N+1 queries, caching, and SQL window functions. Steph also touches on upgrading to Ember Octane and Glimmer components and Chris shares a new helpful tool for drawing architecture diagrams. +Window.find() (https://developer.mozilla.org/en-US/docs/Web/API/Window/find/) +Dash (https://kapeli.com/dash/) +Wat - Lightning talk by Gary Bernhardt (https://www.destroyallsoftware.com/talks/wat/) +Draw.io (https://app.diagrams.net/) +batch-loader (https://github.com/exAspArk/batch-loader) +SQL Window Function (https://thoughtbot.com/blog/postgres-window-functions) +Advanced ActiveRecord Querying (https://thoughtbot.com/upcase/advanced-activerecord-querying) +Scout (https://scoutapm.com/) +ActiveSupport::Notifications (https://api.rubyonrails.org/classes/ActiveSupport/Notifications.html) +Ember Octane (https://emberjs.com/editions/octane/) +Pry show-source (https://github.com/pry/pry#code-browsing) + + ember, javascript, n+1 query, performance, octane, rails, ruby + + On this week's episode, Steph troubleshoots a mysterious Ember test failure that can't find a visible element, and Chris recounts an exciting three-act adventure that spans N+1 queries, caching, and SQL window functions. Steph also touches on upgrading to Ember Octane and Glimmer components and Chris shares a new helpful tool for drawing architecture diagrams.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Steph troubleshoots a mysterious Ember test failure that can't find a visible element, and Chris recounts an exciting three-act adventure that spans N+1 queries, caching, and SQL window functions. Steph also touches on upgrading to Ember Octane and Glimmer components and Chris shares a new helpful tool for drawing architecture diagrams.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+TUm4nYdK + + ]]> + + + + 243: I'm Not a Couch Worker + https://bikeshed.thoughtbot.com/243 + a723d35f-4107-425c-b8db-14b46f0435eb + Tue, 12 May 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris shares his recent explorations of railway oriented programming (hint: not what you think!) while doing his best to avoid words like "monad" and "functor" (he does not succeed in this effort). Steph updates on her quest for the ultimate personal note taking app and some misadventures in DNS and networking, and they touch on their shared search for ergonomics in the home office world we all live in these days. + 40:20 + no + + On this week's episode, Chris shares his recent explorations of railway oriented programming (hint: not what you think!) while doing his best to avoid words like "monad" and "functor" (he does not succeed in this effort). Steph updates on her quest for the ultimate personal note taking app and some misadventures in DNS and networking, and they touch on their shared search for ergonomics in the home office world we all live in these days. +This episode is brought to you by ExpressVPN (https://www.expressvpn.com/BIKESHED). Click through to get three months for free. +Chris's new rounded footrest (https://www.amazon.com/gp/product/B07QZDLZVZ/ref=ppx_yo_dt_b_asin_title_o07_s00) +VSCode LiveShare (https://code.visualstudio.com/blogs/2017/11/15/live-share) +dry-monads (https://dry-rb.org/gems/dry-monads/1.3/) +dry-monads Do notations (https://dry-rb.org/gems/dry-monads/1.3/do-notation/) +Railway Oriented Programming (https://fsharpforfunandprofit.com/rop/) +Dont Use Exceptions For Flow Control (https://wiki.c2.com/?DontUseExceptionsForFlowControl) +Roam Research (https://roamresearch.com/) +Bear notes app (https://bear.app/) +mDNSResponder (https://www.howtogeek.com/338914/what-is-mdnsresponder-and-why-is-it-running-on-my-mac/) +SIGHUP (https://en.wikipedia.org/wiki/SIGHUP) +iStats (https://bjango.com/mac/istatmenus/) +Spurious Qs (https://github.com/neovim/neovim/issues/6403) +fzf Preview Window (https://github.com/junegunn/fzf#preview-window) +bat (alternative to cat) (https://github.com/sharkdp/bat) +Vim floating windows (https://old.reddit.com/r/neovim/comments/ars2ad/want_to_try_with_neovims_floating_window/) + + + On this week's episode, Chris shares his recent explorations of railway oriented programming (hint: not what you think!) while doing his best to avoid words like "monad" and "functor" (he does not succeed in this effort). Steph updates on her quest for the ultimate personal note taking app and some misadventures in DNS and networking, and they touch on their shared search for ergonomics in the home office world we all live in these days.

+ +

This episode is brought to you by ExpressVPN. Click through to get three months for free.

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris shares his recent explorations of railway oriented programming (hint: not what you think!) while doing his best to avoid words like "monad" and "functor" (he does not succeed in this effort). Steph updates on her quest for the ultimate personal note taking app and some misadventures in DNS and networking, and they touch on their shared search for ergonomics in the home office world we all live in these days.

+ +

This episode is brought to you by ExpressVPN. Click through to get three months for free.

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ojTVLbIj + + ]]> + + + + 242: As Few Consonants as Possible + https://bikeshed.thoughtbot.com/242 + 36a1f305-6284-45f9-abd1-ee3d125e8021 + Tue, 05 May 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week’s episode, Chris and Steph share their excitement for Roam Research and formatting Ruby with Prettier Ruby. They also discuss writing test coverage for an important GDPR process, embracing async communication, and share their preferred strategies for knowledge sharing within teams and the broader community. + 41:36 + no + + On this week’s episode, Chris and Steph share their excitement for Roam Research and formatting Ruby with Prettier Ruby. They also discuss writing test coverage for an important GDPR process, embracing async communication, and share their preferred strategies for knowledge sharing within teams and the broader community. +Roam Research (https://roamresearch.com/) +Bear (https://bear.app/) +DayOne (https://dayoneapp.com/) +Reveal.js (https://revealjs.com/#/) +Github Draft Pull Requests (https://github.blog/2019-02-14-introducing-draft-pull-requests/) +Prettier Ruby (https://github.com/prettier/plugin-ruby) +CoC (https://vimawesome.com/plugin/coc-nvim) +GDPR (https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) +Stack Overflow for Teams (https://stackoverflow.com/teams) +Basecamp (https://basecamp.com/) +Twist (https://twist.com/home) +The Golden Rule for programmers (https://thepugautomatic.com/2014/07/golden-rule/) + + note-taking, prettier, ruby, GDPR, knowledge sharing, testing + + On this week’s episode, Chris and Steph share their excitement for Roam Research and formatting Ruby with Prettier Ruby. They also discuss writing test coverage for an important GDPR process, embracing async communication, and share their preferred strategies for knowledge sharing within teams and the broader community.

+ +

Support The Bike Shed

]]> + + + On this week’s episode, Chris and Steph share their excitement for Roam Research and formatting Ruby with Prettier Ruby. They also discuss writing test coverage for an important GDPR process, embracing async communication, and share their preferred strategies for knowledge sharing within teams and the broader community.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+cFZsl-LT + + ]]> + + + + 241: What If We Just Put a Phone Number? + https://bikeshed.thoughtbot.com/241 + a1b48f40-2747-4846-a5a9-1ac94e369222 + Tue, 28 Apr 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode Steph and Chris dig into MVP thinking and asking how we can write as little code as possible before finding out if any user will actually want the thing we're building. + +They also tackle a listener question around Vim and the general ROI on honing our developer tools, discuss some of the subtleties of HTTP and forms as well as the difficulties when half of our UI is in React and the other half Rails, and lastly chat a bit about their adaptation to full-time remote work. + 36:39 + no + + On this week's episode Steph and Chris dig into MVP thinking and asking how we can write as little code as possible before finding out if any user will actually want the thing we're building. +They also tackle a listener question around Vim and the general ROI on honing our developer tools, discuss some of the subtleties of HTTP and forms as well as the difficulties when half of our UI is in React and the other half Rails, and lastly chat a bit about their adaptation to full-time remote work. +VS Code (https://code.visualstudio.com/) +Mastering the Vim Language talk by Chris (https://www.youtube.com/watch?v=wlR5gYd6um0) +Bogdan Gusiev's Rails issue describing the select multiple behavior (https://github.com/rails/rails/pull/1552) +postgres check_constraint (https://www.postgresqltutorial.com/postgresql-check-constraint/) +Formik (https://formik.com/) +react-hook-form (https://react-hook-form.com/) +Balsamiq Mockups (https://balsamiq.com/) +7 Tips for Better User Interviews with Jaclyn Perrone (https://www.userinterviews.com/blog/7-tips-for-better-user-interviews) +More of Jaclyn Perrone on thoughtbot's design-focussed podcast, Tentative (https://www.tentative.fm/) + + + On this week's episode Steph and Chris dig into MVP thinking and asking how we can write as little code as possible before finding out if any user will actually want the thing we're building.

+ +

They also tackle a listener question around Vim and the general ROI on honing our developer tools, discuss some of the subtleties of HTTP and forms as well as the difficulties when half of our UI is in React and the other half Rails, and lastly chat a bit about their adaptation to full-time remote work.

+ +

Support The Bike Shed

]]> + + + On this week's episode Steph and Chris dig into MVP thinking and asking how we can write as little code as possible before finding out if any user will actually want the thing we're building.

+ +

They also tackle a listener question around Vim and the general ROI on honing our developer tools, discuss some of the subtleties of HTTP and forms as well as the difficulties when half of our UI is in React and the other half Rails, and lastly chat a bit about their adaptation to full-time remote work.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+F2zu88kA + + ]]> + + + + 240: A Framework in Motion Tends to Stay in Motion + https://bikeshed.thoughtbot.com/240 + 865a677d-ae76-4b5d-896a-74108c9d1a04 + Tue, 21 Apr 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss troubleshooting a race condition, trusting your intuition and pessimistic locks. They also touch briefly on TailWind CSS before diving deep into first impressions of Inertia.js. + 34:02 + no + + On this week's episode, Chris and Steph discuss troubleshooting a race condition, trusting your intuition and pessimistic locks. They also touch briefly on TailWind CSS before diving deep into first impressions of Inertia.js. +This episode is brought to you by ExpressVPN (https://www.expressvpn.com/bikeshed). Click through to get three months for free. +ActiveRecord::Locking::Pessimistic#with_lock (https://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html#method-i-with_lock) +Derek Prior's blog post - "Validation, Database Constraint, or Both?" (https://thoughtbot.com/blog/validation-database-constraint-or-both) +TailWind CSS (https://tailwindcss.com/) +Inertia.js (https://inertiajs.com/) + + pessimistic locking, tailwind, css, inertia, javascript + + On this week's episode, Chris and Steph discuss troubleshooting a race condition, trusting your intuition and pessimistic locks. They also touch briefly on TailWind CSS before diving deep into first impressions of Inertia.js.

+ +

This episode is brought to you by ExpressVPN. Click through to get three months for free.

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph discuss troubleshooting a race condition, trusting your intuition and pessimistic locks. They also touch briefly on TailWind CSS before diving deep into first impressions of Inertia.js.

+ +

This episode is brought to you by ExpressVPN. Click through to get three months for free.

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Dd4f523a + + ]]> + + + + 239: Admins All the Way Down + https://bikeshed.thoughtbot.com/239 + d6fa2a30-f36d-4f26-98a8-d1981e63455b + Tue, 07 Apr 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss what it really means to make a project "open source". Is it just about making the code publicly available, or should we be considering licenses and responsibility to update? + +They also discuss the need for breaks and structure now that everyone is working from home, revisit previous discussions around building functionality for admin users and the various admin systems out there, and they round out the conversation with a discussion around doubles vs spies in testing. + 38:05 + no + + On this week's episode, Steph and Chris discuss what it really means to make a project "open source". Is it just about making the code publicly available, or should we be considering licenses and responsibility to update? +They also discuss the need for breaks and structure now that everyone is working from home, revisit previous discussions around building functionality for admin users and the various admin systems out there, and they round out the conversation with a discussion around doubles vs spies in testing. +Note - No snakes were harmed as Steph found them a new home 😊 +Enroll in our free online-workshop on code audits How to supercharge your Rails application with a code audit (https://info.thoughtbot.com/code-audit-workshop?utm_source=BikeShed&utm_medium=Podcast) +Using CDPATH to Quickly cd (https://thoughtbot.com/blog/cding-to-frequently-used-directories-in-zsh) +Upcase repo on GitHub (https://github.com/thoughtbot/upcase) +MIT License (https://opensource.org/licenses/MIT) +Choosing an open-source license (https://choosealicense.com/) +active_admin (https://github.com/activeadmin/activeadmin) +React admin (https://github.com/marmelab/react-admin) +Administrate (https://github.com/thoughtbot/administrate) +Rails postgres native array (https://guides.rubyonrails.org/active_record_postgresql.html#array) +Inertia.js (https://inertiajs.com/) +RSpec Spies vs Doubles (https://thoughtbot.com/blog/a-closer-look-at-test-spies) +RSpec verified doubles (https://relishapp.com/rspec/rspec-mocks/v/3-9/docs/verifying-doubles) + + + On this week's episode, Steph and Chris discuss what it really means to make a project "open source". Is it just about making the code publicly available, or should we be considering licenses and responsibility to update?

+ +

They also discuss the need for breaks and structure now that everyone is working from home, revisit previous discussions around building functionality for admin users and the various admin systems out there, and they round out the conversation with a discussion around doubles vs spies in testing.

+ +

Note - No snakes were harmed as Steph found them a new home 😊

+ +

Enroll in our free online-workshop on code audits How to supercharge your Rails application with a code audit

+ +

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris discuss what it really means to make a project "open source". Is it just about making the code publicly available, or should we be considering licenses and responsibility to update?

+ +

They also discuss the need for breaks and structure now that everyone is working from home, revisit previous discussions around building functionality for admin users and the various admin systems out there, and they round out the conversation with a discussion around doubles vs spies in testing.

+ +

Note - No snakes were harmed as Steph found them a new home 😊

+ +

Enroll in our free online-workshop on code audits How to supercharge your Rails application with a code audit

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+y6KKSn2z + + ]]> + + + + 238: All the Single Quotes + https://bikeshed.thoughtbot.com/238 + e455299c-ea31-4db0-a783-51c4c2006623 + Tue, 31 Mar 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + In this week's episode, Chris shares details about his new greenfield project, implementing static pages with high voltage, opting for just-in-time architecture decisions and working with various admin libraries. Steph discusses various ways to advocate for change across larger engineering teams, recognizing when it's important to push for change vs letting go of strong opinions, and how to gain buy-in from your team. + 28:12 + no + + In this week's episode, Chris shares details about his new greenfield project, implementing static pages with high voltage, opting for just-in-time architecture decisions and working with various admin libraries. Steph discusses various ways to advocate for change across larger engineering teams, recognizing when it's important to push for change vs letting go of strong opinions, and how to gain buy-in from your team. +Enroll in our free online-workshop on going remote Being Human in the Absence of Humans: A Live Q&A for Product Teams (https://info.thoughtbot.com/being-human-in-the-absence-of-humans?utm_source=BikeShed&utm_medium=Podcast) +Rock & Roll with Ember.js (https://www.balinterdi.com/rock-and-roll-with-emberjs/) +suspenders (https://github.com/thoughtbot/suspenders) +high voltage (https://github.com/thoughtbot/high_voltage) +active admin (https://github.com/activeadmin/activeadmin) +rails admin (https://github.com/sferik/rails_admin) +administrate (https://github.com/thoughtbot/administrate) +dependabot (https://github.com/marketplace/dependabot-preview) +thoughtbot guides (https://github.com/thoughtbot/guides) + + ember, rails, high voltage, admin, team, process + + In this week's episode, Chris shares details about his new greenfield project, implementing static pages with high voltage, opting for just-in-time architecture decisions and working with various admin libraries. Steph discusses various ways to advocate for change across larger engineering teams, recognizing when it's important to push for change vs letting go of strong opinions, and how to gain buy-in from your team.

+ +

Enroll in our free online-workshop on going remote Being Human in the Absence of Humans: A Live Q&A for Product Teams

+ +

Support The Bike Shed

]]> + + + In this week's episode, Chris shares details about his new greenfield project, implementing static pages with high voltage, opting for just-in-time architecture decisions and working with various admin libraries. Steph discusses various ways to advocate for change across larger engineering teams, recognizing when it's important to push for change vs letting go of strong opinions, and how to gain buy-in from your team.

+ +

Enroll in our free online-workshop on going remote Being Human in the Absence of Humans: A Live Q&A for Product Teams

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+LmlCwz79 + + ]]> + + + + 237: I Love The Squiggles + https://bikeshed.thoughtbot.com/237 + c49d7ded-32b0-4117-86e0-2020cf182c8d + Tue, 17 Mar 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss the pros and cons of memoization, Chris revisits the discussion around the value of react snapshot tests as well as his continued explorations with Inertia.js while Steph updates us on living in a schema-less world, and they round out the conversation with a listener question about pairing tools, setup, and approaches. + 39:18 + no + + On this week's episode, Steph and Chris discuss the pros and cons of memoization, Chris revisits the discussion around the value of react snapshot tests as well as his continued explorations with Inertia.js while Steph updates us on living in a schema-less world, and they round out the conversation with a listener question about pairing tools, setup, and approaches. +This episode is brought to you by ExpressVPN (https://www.expressvpn.com/BIKESHED). +Click through to get three months for free. +memoization (https://en.wikipedia.org/wiki/Memoization) +Jest snapshot tests (https://jestjs.io/docs/en/snapshot-testing) +RSpec custom matchers (https://relishapp.com/rspec/rspec-expectations/v/2-3/docs/custom-matchers/define-matcher) +ActiveRecord columns_hash (https://apidock.com/rails/ActiveRecord/Base/columns_hash/class) +Inertia.js (https://inertiajs.com/) +Tuple (https://tuple.app/) +VSCode Live Share (https://code.visualstudio.com/blogs/2017/11/15/live-share) +tmate (https://tmate.io/) +Tomato Timer (https://tomato-timer.com/) +Effective Pairing Checklist (https://thoughtbot.com/blog/how-to-get-better-at-pair-programming) + + react, jest, testing, pair programming + + On this week's episode, Steph and Chris discuss the pros and cons of memoization, Chris revisits the discussion around the value of react snapshot tests as well as his continued explorations with Inertia.js while Steph updates us on living in a schema-less world, and they round out the conversation with a listener question about pairing tools, setup, and approaches.

+ +

This episode is brought to you by ExpressVPN.
+Click through to get three months for free.

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris discuss the pros and cons of memoization, Chris revisits the discussion around the value of react snapshot tests as well as his continued explorations with Inertia.js while Steph updates us on living in a schema-less world, and they round out the conversation with a listener question about pairing tools, setup, and approaches.

+ +

This episode is brought to you by ExpressVPN.
+Click through to get three months for free.

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+H5vo1TWE + + ]]> + + + + 236: What's GNU With You? + https://bikeshed.thoughtbot.com/236 + 28cb5719-d4d8-4afd-b9bd-05dddfff9660 + Tue, 10 Mar 2020 00:15:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss recent challenges associated with upgrading React Router and uploading files to Amazon S3. Steph also shares her latest reading adventure in cybersecurity and Chris reflects on his time at thoughtbot, how his approach to web development has shifted over the past seven years, and what he plans to do next. + 44:20 + no + + On this week's episode, Chris and Steph discuss recent challenges associated with upgrading React Router and uploading files to Amazon S3. Steph also shares her latest reading adventure in cybersecurity and Chris reflects on his time at thoughtbot, how his approach to web development has shifted over the past seven years, and what he plans to do next. +The Cuckoo's Egg by Cliff Stoll (https://amzn.to/3aqoWJM) +GNU (https://en.wikipedia.org/wiki/GNU) +UNIX (https://en.wikipedia.org/wiki/Unix) +POSIX (https://en.wikipedia.org/wiki/POSIX) +PAX (https://www.paxsite.com/) +React Router (https://github.com/ReactTraining/react-router) +Enzyme (https://github.com/enzymejs/enzyme) +React Testing Library (https://github.com/testing-library/react-testing-library) +Amazon S3 (https://aws.amazon.com/s3/) +FTP (https://en.wikipedia.org/wiki/File_Transfer_Protocol) +Inertia.js (https://inertiajs.com/) +New Pepperjuice Track! (https://soundcloud.com/encorebroderskab/bomlowpromo/s-bty8u) +*Correction - The Cuckoo's Egg helped pioneer cybersecurity techniques + + cybersecurity, VR, react, react router, AWS, consulting + + On this week's episode, Chris and Steph discuss recent challenges associated with upgrading React Router and uploading files to Amazon S3. Steph also shares her latest reading adventure in cybersecurity and Chris reflects on his time at thoughtbot, how his approach to web development has shifted over the past seven years, and what he plans to do next.

+ + + +

*Correction - The Cuckoo's Egg helped pioneer cybersecurity techniques

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph discuss recent challenges associated with upgrading React Router and uploading files to Amazon S3. Steph also shares her latest reading adventure in cybersecurity and Chris reflects on his time at thoughtbot, how his approach to web development has shifted over the past seven years, and what he plans to do next.

+ + + +

*Correction - The Cuckoo's Egg helped pioneer cybersecurity techniques

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+J0OnOD5P + + ]]> + + + + 235: Take a Deep Breath + https://bikeshed.thoughtbot.com/235 + 08280a05-dc7f-45cb-b0ea-f46d36807571 + Tue, 03 Mar 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris dig into their shared love of refactoring. How do they think about it, have they ever reverted a refactor, thoughts on deferred refactoring, and more. + +They also discuss some positive team habits, snapshot testing, the importance of keeping your testing as close to production as possible, and finally, Chris shares some big personal news. + 44:24 + no + + On this week's episode, Steph and Chris dig into their shared love of refactoring. How do they think about it, have they ever reverted a refactor, thoughts on deferred refactoring, and more. +They also discuss some positive team habits, snapshot testing, the importance of keeping your testing as close to production as possible, and finally, Chris shares some big personal news. +Snapshot tests (https://jestjs.io/docs/en/snapshot-testing) +styled-components (https://www.styled-components.com/) +rollup (https://rollupjs.org/) +react-testing-library (https://github.com/testing-library/react-testing-library) +"Don't worry about this tech debt, we'll clean it up next sprint." (https://twitter.com/markdalgleish/status/1219174509309087744) + + testing, refactoring + + On this week's episode, Steph and Chris dig into their shared love of refactoring. How do they think about it, have they ever reverted a refactor, thoughts on deferred refactoring, and more.

+ +

They also discuss some positive team habits, snapshot testing, the importance of keeping your testing as close to production as possible, and finally, Chris shares some big personal news.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris dig into their shared love of refactoring. How do they think about it, have they ever reverted a refactor, thoughts on deferred refactoring, and more.

+ +

They also discuss some positive team habits, snapshot testing, the importance of keeping your testing as close to production as possible, and finally, Chris shares some big personal news.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+POt1sEKu + + ]]> + + + + 234: No More Weird Stuff + https://bikeshed.thoughtbot.com/234 + ab24e2f3-f3a0-4a73-804a-83cb491af9ec + Tue, 25 Feb 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph respond to a listener question about the complex tradeoffs between craft, preferences, and business needs. They also revisit Steph's recent work with mirage factories, Chris's struggles with test failures, and discuss Steph's recent use of the acts_as_paranoid gem. + 34:10 + no + + On this week's episode, Chris and Steph respond to a listener question about the complex tradeoffs between craft, preferences, and business needs. They also revisit Steph's recent work with mirage factories, Chris's struggles with test failures, and discuss Steph's recent use of the actsasparanoid gem. +This episode is brought to you by Clubhouse (http://go.thoughtleaders.io/1658420200225). Click through to get 2 free months on any paid plan. +Mirage.js (https://miragejs.com/) +Creating Ember Data models on the client with Mirage (https://www.ember-cli-mirage.com/docs/testing/integration-and-unit-tests#creating-ember-data-models-on-the-client-with-mirage) +FactoryBot (https://github.com/thoughtbot/factory_bot) +Sam Selikoff (https://twitter.com/samselikoff/) +Babel (https://babeljs.io/) +Browserlist (https://github.com/browserslist/browserslist) +actsasparanoid (https://github.com/ActsAsParanoid/acts_as_paranoid) +Default scopes in Rails (https://guides.rubyonrails.org/active_record_querying.html#applying-a-default-scope) +Braintree hosted fields (https://developers.braintreepayments.com/start/hosted-fields) + + testing, ember, mirage.js + + On this week's episode, Chris and Steph respond to a listener question about the complex tradeoffs between craft, preferences, and business needs. They also revisit Steph's recent work with mirage factories, Chris's struggles with test failures, and discuss Steph's recent use of the acts_as_paranoid gem.

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph respond to a listener question about the complex tradeoffs between craft, preferences, and business needs. They also revisit Steph's recent work with mirage factories, Chris's struggles with test failures, and discuss Steph's recent use of the acts_as_paranoid gem.

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+gPaAwrc5 + + ]]> + + + + 233: Software Development in Ancient Rome (Joël Quenneville) + https://bikeshed.thoughtbot.com/233 + 22084315-a8ac-41b0-ba28-2b41f5c0535a + Tue, 18 Feb 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph is joined by Joël Quenneville. It's the season for CFPs (call for proposals) and Joël shares insights about his past conference talk submissions, both the accepted and rejected. They also discuss writing habits that help increase blogpost frequency and helping teams upgrade their Rails application. + 42:56 + no + + On this week's episode, Steph is joined by Joël Quenneville. It's the season for CFPs (call for proposals) and Joël shares insights about his past conference talk submissions, both the accepted and rejected. They also discuss writing habits that help increase blogpost frequency and helping teams upgrade their Rails application. +Joël's "Rolling Random Romans" talk (https://youtu.be/YxGWQdFo2Yc) +Steph's "Building Compliant Health Tech Products" Workshop (https://info.thoughtbot.com/building-compliant-health-tech-products-recording) +Joël's "Working with Maybe" talk (https://www.youtube.com/watch?v=43eM4kNbb6c) +Joël and Rachel's "Beyond the Whiteboard" talk (https://youtu.be/8FkkMkeJKU8) +elm-conf (https://twitter.com/elmconf) +Joël's "Conference talk proposal examples" (https://thoughtbot.com/blog/conference-talk-proposal-examples) +Sarah Mei "What Your Conference Proposal Is Missing" (http://www.sarahmei.com/blog/2014/04/07/what-your-conference-proposal-is-missing/) +Noel Rappin's "What I Learned from Reading 429 Conference Proposals" (http://www.noelrappin.com/railsrx/2014/3/17/what-i-learned-from-reading-429-conference-proposals) +Supercharge your product with a Code Audit (https://thoughtbot.com/services/code-audit) +Addressing technical debt (https://thoughtbot.com/blog/addressing-technical-debt) +Strong parameters gem (https://github.com/rails/strong_parameters) +Blogposts by Joël (https://thoughtbot.com/blog/authors/joel-quenneville) + + conference talk, conference proposal, rails, rails upgrade, blogposts, writing + + On this week's episode, Steph is joined by Joël Quenneville. It's the season for CFPs (call for proposals) and Joël shares insights about his past conference talk submissions, both the accepted and rejected. They also discuss writing habits that help increase blogpost frequency and helping teams upgrade their Rails application.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Steph is joined by Joël Quenneville. It's the season for CFPs (call for proposals) and Joël shares insights about his past conference talk submissions, both the accepted and rejected. They also discuss writing habits that help increase blogpost frequency and helping teams upgrade their Rails application.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GFN87Qqh + + ]]> + + + + 232: I'm Not Allowed to Play With Other Shells + https://bikeshed.thoughtbot.com/232 + 0eaa8e83-114a-4fc8-ba9a-6b3238f14b60 + Tue, 11 Feb 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph celebrate the new Bike Shed website and logo! Steph has found a new way to optimize her keyboard happiness and Chris dabbles with Zsh auto-suggestions. They also explore the team and technical trade-offs in the pursuit of clean code and respond to a listener question about building products that meet strict security policies. + 36:00 + no + + On this week's episode, Chris and Steph celebrate the new Bike Shed website and logo! +Steph finds a new way to optimize her keyboard happiness and Chris dabbles with Zsh auto-suggestions. They also explore the team and technical trade-offs in the pursuit of clean code and respond to a listener question about building products that meet strict security policies. +This episode is brought to you by Clubhouse (http://go.thoughtleaders.io/1658320200211). Click through to get 2 free months on any paid plan. +Karabiner-Elements (https://pqrs.org/osx/karabiner/) +Oh My Zsh (https://ohmyz.sh/) +Fish shell (https://fishshell.com/) +zsh-autosuggestions (https://github.com/zsh-users/zsh-autosuggestions) +Steve Losh - Shift Key Training Wheels (https://stevelosh.com/blog/2012/10/a-modern-space-cadet/#s16-shift-key-training-wheels) +Learn Vimscript the Hard Way (https://learnvimscriptthehardway.stevelosh.com/) +Grammarly (https://www.grammarly.com/) +Dan Abramov - Goodbye, Clean Code (https://overreacted.io/goodbye-clean-code/) +Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (https://www.oreilly.com/library/view/clean-code/9780136083238/) +99 Bottles of OOP (https://www.sandimetz.com/99bottles) +Steph's "Building Compliant Health Tech Products" Workshop (https://info.thoughtbot.com/building-compliant-health-tech-products-recording) + + mechanical keyboard, clean code, vim, zsh, security + + On this week's episode, Chris and Steph celebrate the new Bike Shed website and logo!

+ +

Steph finds a new way to optimize her keyboard happiness and Chris dabbles with Zsh auto-suggestions. They also explore the team and technical trade-offs in the pursuit of clean code and respond to a listener question about building products that meet strict security policies.

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph celebrate the new Bike Shed website and logo!

+ +

Steph finds a new way to optimize her keyboard happiness and Chris dabbles with Zsh auto-suggestions. They also explore the team and technical trade-offs in the pursuit of clean code and respond to a listener question about building products that meet strict security policies.

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+G3FrhSEA + + ]]> + + + + 231: Fun and Useful + https://bikeshed.thoughtbot.com/231 + de1fa74d-2dfd-4203-9d8a-aa4bdabf457e + Tue, 04 Feb 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph shares some of her Ember testing adventures, Chris discusses the subtle realities of tooling and automation, and they answer a listener question about using React without an API. + 32:25 + no + + On this week's episode, Steph shares more of her Ember adventures, specifically sharing some of her work with the Mirage API mocking and prototyping library, and her search for factories and more ergonomic data in tests. +Chris shares some struggles he's had recently with automation and tooling around deployment and releasing packages, and they discuss the inherent trade-offs that we have to consider when automating anything. +Lastly they touch on Twitter's alt text accessibility features, and answer a listener question about using React without having an API, and instead just using it as a more dynamic view layer. +Mirage.js (https://miragejs.com/) +RSpec instance doubles (https://relishapp.com/rspec/rspec-mocks/v/3-2/docs/verifying-doubles/using-an-instance-double) +Semantic release (https://github.com/semantic-release/semantic-release) +Heroku Review Apps (https://devcenter.heroku.com/articles/github-integration-review-apps) +Netlify pull request builds (https://www.netlify.com/tags/pull-request/) +Twitter alt text accessibility (https://help.twitter.com/en/using-twitter/picture-descriptions) +Basecamp 3 for iOS: Hybrid Architecture (https://m.signalvnoise.com/basecamp-3-for-ios-hybrid-architecture/) +Inertia.js (https://inertiajs.com/) +Vue.js (https://vuejs.org/) + + ember, react, testing + + On this week's episode, Steph shares more of her Ember adventures, specifically sharing some of her work with the Mirage API mocking and prototyping library, and her search for factories and more ergonomic data in tests.

+ +

Chris shares some struggles he's had recently with automation and tooling around deployment and releasing packages, and they discuss the inherent trade-offs that we have to consider when automating anything.

+ +

Lastly they touch on Twitter's alt text accessibility features, and answer a listener question about using React without having an API, and instead just using it as a more dynamic view layer.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Steph shares more of her Ember adventures, specifically sharing some of her work with the Mirage API mocking and prototyping library, and her search for factories and more ergonomic data in tests.

+ +

Chris shares some struggles he's had recently with automation and tooling around deployment and releasing packages, and they discuss the inherent trade-offs that we have to consider when automating anything.

+ +

Lastly they touch on Twitter's alt text accessibility features, and answer a listener question about using React without having an API, and instead just using it as a more dynamic view layer.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+_Wu1YWgt + + ]]> + + + + 230: The Broken Road + https://bikeshed.thoughtbot.com/230 + 131fff19-472c-499d-bd6c-42dd1e8fd842 + Tue, 28 Jan 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph revisit the long-lived feature branch Chris has been working on and chat about adventures with Yalc. They also dive into the common questions and concerns associated with coding bootcamps, thoughtbot's exciting new partnership with Resilient Coders, and what it would be like to "start over". + 42:19 + no + + On this week's episode, Chris and Steph revisit the long-lived feature branch Chris has been working on and chat about adventures with Yalc. They also dive into the common questions and concerns associated with coding bootcamps, thoughtbot's exciting new partnership with Resilient Coders, and what it would be like to "start over". +This episode is brought to you by Clubhouse (http://go.thoughtleaders.io/1658220200124). Click through to get 2 free months on any paid plan. +yalc (https://github.com/whitecolor/yalc/) +thoughtbot + Resilient Coders (https://twitter.com/thoughtbot/status/1216812506716557313) +Bless the Broken Road (https://youtu.be/lZp6pmgbZyU) +Railscasts (http://railscasts.com) +Destroy All Software (https://www.destroyallsoftware.com) + + react, bootcamps, resilient coders + + On this week's episode, Chris and Steph revisit the long-lived feature branch Chris has been working on and chat about adventures with Yalc. They also dive into the common questions and concerns associated with coding bootcamps, thoughtbot's exciting new partnership with Resilient Coders, and what it would be like to "start over".

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph revisit the long-lived feature branch Chris has been working on and chat about adventures with Yalc. They also dive into the common questions and concerns associated with coding bootcamps, thoughtbot's exciting new partnership with Resilient Coders, and what it would be like to "start over".

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+sF7jwXX2 + + ]]> + + + + 229: Nothing but Positive Fire + https://bikeshed.thoughtbot.com/229 + 56dbe784-caa4-409d-b825-3c112f5c1fc5 + Tue, 21 Jan 2020 00:15:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris catch up in their first recording of 2020. They discuss git workflows and the surprisingly strong opinions often associated with them, testing at all levels of your application, Steph gives a quick summary of her Ember adventures, and they round out the discussion with some new years systems building and Star Wars reviews. + 52:40 + no + + On this week's episode, Steph and Chris catch up in their first recording of 2020. They discuss git workflows and the surprisingly strong opinions often associated with them, testing at all levels of your application, Steph gives a quick summary of her Ember adventures, and they round out the discussion with some new years systems building and Star Wars reviews. +This episode is brought to you by Clubhouse (http://go.thoughtleaders.io/1658120200117). Click through to get 2 free months on any paid plan. +Ember Documentation (https://emberjs.com/learn/) +JSON Schema (https://json-schema.org/) +Pretender (https://github.com/pretenderjs/pretender) +Apollo GraphQL (https://www.apollographql.com/) +React Testing Library (https://testing-library.com/docs/react-testing-library/intro) +Write good commit messages by blaming others (https://thoughtbot.com/blog/write-good-commit-messages-by-blaming-others) (German's blog post) +Prettier (https://prettier.io/) + + + On this week's episode, Steph and Chris catch up in their first recording of 2020. They discuss git workflows and the surprisingly strong opinions often associated with them, testing at all levels of your application, Steph gives a quick summary of her Ember adventures, and they round out the discussion with some new years systems building and Star Wars reviews.

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris catch up in their first recording of 2020. They discuss git workflows and the surprisingly strong opinions often associated with them, testing at all levels of your application, Steph gives a quick summary of her Ember adventures, and they round out the discussion with some new years systems building and Star Wars reviews.

+ +

This episode is brought to you by Clubhouse. Click through to get 2 free months on any paid plan.

+ +

Sponsored By:

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+h079Tm-8 + + ]]> + + + + 228: Friends and Food (George Brocklehurst) + https://bikeshed.thoughtbot.com/228 + b7535e54-f8aa-44ef-ad0c-eeb72ef0e3d2 + Tue, 14 Jan 2020 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph is joined by George Brocklehurst, a Development Director in the NYC thoughtbot office. Steph and George chat about the variety of projects and technologies that caught their attention during thoughtbot's recent internal hackathon. They also dive into Gitsh, a dedicated shell for Git commands, as they chat about preferred git workflows and George shares his recent adventure in updating Gitsh to support tab completion. + 50:07 + no + + <p>On this week's episode, Steph is joined by George Brocklehurst, a Development Director in the NYC thoughtbot office. Steph and George chat about the variety of projects and technologies that caught their attention during thoughtbot's recent internal hackathon. They also dive into Gitsh, a dedicated shell for Git commands, as they chat about preferred git workflows and George shares his recent adventure in updating Gitsh to support tab completion. </p><ul><li><a href="https://firebase.google.com/docs/database">Firebase</a></li><li><a href="https://flow.org/">Flow</a></li><li><a href="https://github.com/thoughtbot/gitsh">Gitsh - An interactive shell for git</a></li><li><a href="https://thoughtbot.com/upcase/videos/gitsh">Upcase - Learn Gitsh</a></li></ul> + + +

On this week's episode, Steph is joined by George Brocklehurst, a Development Director in the NYC thoughtbot office. Steph and George chat about the variety of projects and technologies that caught their attention during thoughtbot's recent internal hackathon. They also dive into Gitsh, a dedicated shell for Git commands, as they chat about preferred git workflows and George shares his recent adventure in updating Gitsh to support tab completion.

Support The Bike Shed

]]> + + +

On this week's episode, Steph is joined by George Brocklehurst, a Development Director in the NYC thoughtbot office. Steph and George chat about the variety of projects and technologies that caught their attention during thoughtbot's recent internal hackathon. They also dive into Gitsh, a dedicated shell for Git commands, as they chat about preferred git workflows and George shares his recent adventure in updating Gitsh to support tab completion.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NnpGz2ac + + ]]> + + + + 227: Hacks and Cheats + https://bikeshed.thoughtbot.com/227 + 95450d77-631f-4f02-ac53-8e9dd5e6db18 + Tue, 07 Jan 2020 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss their recent holiday hackathon efforts building a game in Elm. They discuss their experiences with Elm and the broader prospects of using Elm in more production applications. They also discuss the new git subcommands "git switch" and "git restore", and round things out with a listener question concerning FactoryBot and "minimum viable factories". + 32:31 + no + + <p>On this week's episode, Chris and Steph discuss their recent holiday hackathon efforts building a game in Elm. They discuss their experiences with Elm and the broader prospects of using Elm in more production applications. They also discuss the new git subcommands "git switch" and "git restore", and round things out with a listener question concerning FactoryBot and "minimum viable factories".</p><ul><li><a href="https://public-inbox.org/git/xmqqy2zszuz7.fsf@gitster-ct.c.googlers.com/">Git new commands (git switch & git restore)</a></li><li><a href="https://reaction.ctoomey.com/">Live playable version of the hackathon game</a></li><li><a href="https://github.com/christoomey/elm-reaction">Reaction Game Repo</a></li><li><a href="https://thoughtbot.com/blog/lessons-learned-avoiding-primitives-in-elm">Lessons Learned: Avoiding Primitives in Elm</a></li><li><a href="https://bikeshed.fm/episodes/211">Previous Bike Shed discussions about deleting migrations</a></li><li><a href="https://thoughtbot.com/blog/factories-should-be-the-bare-minimum">Factories Should Be The Bare Minimum</a></li><li><a href="https://github.com/thoughtbot/factory_bot/blob/master/GETTING_STARTED.md#linting-factories">FactoryBot.lint</a></li><li><a href="https://thoughtbot.com/blog/use-factory-girls-build-stubbed-for-a-faster-test">FactoryBot build_stubbed</a></li></ul> + + +

On this week's episode, Chris and Steph discuss their recent holiday hackathon efforts building a game in Elm. They discuss their experiences with Elm and the broader prospects of using Elm in more production applications. They also discuss the new git subcommands "git switch" and "git restore", and round things out with a listener question concerning FactoryBot and "minimum viable factories".

Support The Bike Shed

]]> + + +

On this week's episode, Chris and Steph discuss their recent holiday hackathon efforts building a game in Elm. They discuss their experiences with Elm and the broader prospects of using Elm in more production applications. They also discuss the new git subcommands "git switch" and "git restore", and round things out with a listener question concerning FactoryBot and "minimum viable factories".

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+scMLSNUx + + ]]> + + + + 226: Bespoke Nonsense + https://bikeshed.thoughtbot.com/226 + 8ca6d4e5-cfcd-48ad-a7b8-a5dc69778b0a + Tue, 31 Dec 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, in celebration of the new year, Thom shares the 2019 blooper reel! Words are hard and here's the audio to prove it. Listen to all of the silly mishaps, goofs, and general nonsense captured in between the moments of "professional podcasting". Chris and Steph also reflect on their top themes of 2019 and discuss New Year Systems vs New Year Resolutions. + 40:58 + no + + <p>On this week's episode, in celebration of the new year, Thom shares the 2019 blooper reel! Words are hard and here's the audio to prove it. Listen to all of the silly mishaps, goofs, and general nonsense captured in between the moments of "professional podcasting". Chris and Steph also reflect on their top themes of 2019 and discuss New Year Systems vs New Year Resolutions.</p><ul><li><a href="https://pqrs.org/osx/karabiner/">Karabiner-Elements</a></li><li><a href="https://youtu.be/hHzWG1FltaE">RailsConf 2016 - The Guest: A Guide To Code Hospitality by Nadia Odunayo</a></li><li><a href="https://amzn.to/2Eh8Wf3"><i>Atomic Habits</i></a>: James Clear</li></ul> + + +

On this week's episode, in celebration of the new year, Thom shares the 2019 blooper reel! Words are hard and here's the audio to prove it. Listen to all of the silly mishaps, goofs, and general nonsense captured in between the moments of "professional podcasting". Chris and Steph also reflect on their top themes of 2019 and discuss New Year Systems vs New Year Resolutions.

Support The Bike Shed

]]> + + +

On this week's episode, in celebration of the new year, Thom shares the 2019 blooper reel! Words are hard and here's the audio to prove it. Listen to all of the silly mishaps, goofs, and general nonsense captured in between the moments of "professional podcasting". Chris and Steph also reflect on their top themes of 2019 and discuss New Year Systems vs New Year Resolutions.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ji2Wen39 + + ]]> + + + + 225: Pepper in Some Security + https://bikeshed.thoughtbot.com/225 + aa54ab7e-8bc9-4b77-bde5-68a3b984a904 + Tue, 10 Dec 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph gets Chris to share his biggest developer regrets over the years. They also revisit a favorite topic of estimation and story points, and round out the conversation with some details from the world of application security. + 40:41 + no + + <p>On this week's episode, Steph gets Chris to share his biggest developer regrets over the years. They also revisit a favorite topic of estimation and story points, and round out the conversation with some details from the world of application security.</p><ul><li><a href="https://api.rubyonrails.org/classes/ActiveSupport/SecurityUtils.html">ActiveSupport securecompare</a> and <a href="https://api.rubyonrails.org/classes/ActiveSupport/SecurityUtils.html#method-c-fixedlengthsecurecompare">fixedlengthsecurecompare</a></li><li><a href="https://github.com/thoughtbot/guides/blob/master/security/application.md">thoughtbot's Application security guide</a></li><li><a href="https://en.wikipedia.org/wiki/Pepper(cryptography)">Pepper (cryptography)</a></li><li><a href="https://twitter.com/derekprior/status/609358666530205698">How did this complicated RegEx come to be? (Derek's tweet)</a></li><li><a href="https://github.com/christoomey/vim-rfactory">Vim RFactory</a></li><li><a href="https://bikeshed.fm/episodes/172">What I Believe About Software - Bike Shed episode 172</a></li><li><a href="https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust">Say No To More Process</a> blog post</li></ul> + + +

On this week's episode, Steph gets Chris to share his biggest developer regrets over the years. They also revisit a favorite topic of estimation and story points, and round out the conversation with some details from the world of application security.

Support The Bike Shed

]]> + + +

On this week's episode, Steph gets Chris to share his biggest developer regrets over the years. They also revisit a favorite topic of estimation and story points, and round out the conversation with some details from the world of application security.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4yK6K2yM + + ]]> + + + + 224: The One Manhattan Rule + https://bikeshed.thoughtbot.com/224 + bccf6dc4-faf8-492b-8f42-6587490c5dfa + Tue, 03 Dec 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris catches us up on his latest keyboard adventures and Steph shares her first impression of working with Ember. + +They also dive into Chris's experience triaging errors with Sentry, their love for Elm, how teams achieve a consistent velocity, and Steph's upcoming workshop on how to stay agile when building a healthcare product. To bring it home, they respond to a listener who's wondering when is it a good idea to convert a loose data structure (e.g.: hash) into a class? + 41:37 + no + + <p>On this week's episode, Chris catches us up on his latest keyboard adventures and Steph shares her first impression of working with Ember.</p><p>They also dive into Chris's experience triaging errors Sentry, their love for Elm, how teams achieve a consistent velocity, and Steph's upcoming workshop on how to stay agile when building a healthcare product. To bring it home, they respond to a listener who's wondering when is it a good idea to convert a loose data structure (e.g.: hash) into a class?</p><ul><li><a href="https://prettier.io/">Prettier</a></li><li><a href="https://sentry.io/welcome/">Sentry</a></li><li><a href="https://info.thoughtbot.com/how-to-stay-agile-workshop">Free Workshop - How to stay agile when building compliant health tech products</a></li></ul><p>If you're enjoying The Bike Shed, we'd love it if you could give it a <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">rating or review on iTunes</a>. Thanks!</p> + + + + On this week's episode, Chris catches us up on his latest keyboard adventures and Steph shares her first impression of working with Ember.

They also dive into Chris's experience triaging errors Sentry, their love for Elm, how teams achieve a consistent velocity, and Steph's upcoming workshop on how to stay agile when building a healthcare product. To bring it home, they respond to a listener who's wondering when is it a good idea to convert a loose data structure (e.g.: hash) into a class?

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + + On this week's episode, Chris catches us up on his latest keyboard adventures and Steph shares her first impression of working with Ember.

They also dive into Chris's experience triaging errors Sentry, their love for Elm, how teams achieve a consistent velocity, and Steph's upcoming workshop on how to stay agile when building a healthcare product. To bring it home, they respond to a listener who's wondering when is it a good idea to convert a loose data structure (e.g.: hash) into a class?

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ol18kkyV + + ]]> + + + + 223: Terrible and Easy + https://bikeshed.thoughtbot.com/223 + 687bbbdb-de99-494e-aafa-726d71ef6c5c + Tue, 26 Nov 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss identifying refactoring opportunities by highlighting overly coupled code and Chris announces that he has advanced his vim setup into the 21st century by making the switch to Neovim. + +They also respond to a timely question from a listener who's thinking about learning vim, which raises the important question: is vim still relevant? And if so, how does one get started? Rounding out the conversation, they discuss treating the database as a product's first (or last) line of defense. + 44:52 + no + + On this week's episode, Chris and Steph discuss identifying refactoring opportunities by highlighting overly coupled code and Chris announces that he has advanced his vim setup into the 21st century by making the switch to Neovim. +<ul><li><a href="https://thoughtbot.com/blog/types-of-coupling">Types of Coupling</a></li><li><a href="https://github.com/typicode/husky">Husky</a></li><li><a href="https://github.com/neoclide/coc.nvim">Conquer of Completion Plugin</a></li><li><a href="https://thoughtbot.com/upcase/dive-into-neovim">Dive Into Neovim on Upcase</a></li><li><a href="https://thoughtbot.com/blog/mastering-the-vim-language">Mastering the Vim Language</a></li><li><a href="https://thoughtbot.com/upcase/onramp-to-vim">Onramp to Vim</a></li><li><a href="https://www.postgresql.org/docs/9.4/ddl-constraints.html">Postgres Check Constraints</a></li></ul> + + + On this week's episode, Chris and Steph discuss identifying refactoring opportunities by highlighting overly coupled code and Chris announces that he has advanced his vim setup into the 21st century by making the switch to Neovim.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph discuss identifying refactoring opportunities by highlighting overly coupled code and Chris announces that he has advanced his vim setup into the 21st century by making the switch to Neovim.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+uGmx63B2 + + ]]> + + + + 222: That Eureka Moment + https://bikeshed.thoughtbot.com/222 + b994d4e6-aaf7-4fa1-a7c5-549a729a817b + Tue, 12 Nov 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris dive into the world of crafting pull requests for optimal code review, as well as the flip side of providing code review. How can we make it easy for reviewers, and as reviewers, how can we make it easy for our teammates to incorporate our suggestions? + +They also discuss the world of testing, from integration to visual to unit testing, and some of the tools an practices they use at each level. + +Lastly, they discuss Steph's continued pairing adventures and possibly finding her max on the pairing front, a quick update on mechanical keyboards, and Steph shares a teaser of an upcoming workshop she'll be hosting around how to stay agile when building health tech products. + 36:29 + no + + <p>On this week's episode, Steph and Chris dive into the world of crafting pull requests for optimal code review, as well as the flip side of providing code review. How can we make it easy for reviewers, and as reviewers, how can we make it easy for our teammates to incorporate our suggestions?</p><p>They also discuss the world of testing, from integration to visual to unit testing, and some of the tools an practices they use at each level.</p><p>Lastly, they discuss Steph's continued pairing adventures and possibly finding her max on the pairing front, a quick update on mechanical keyboards, and Steph shares a teaser of an upcoming workshop she'll be hosting around how to stay agile when building health tech products.</p><p>This episode of <i>The Bike Shed</i> is sponsored by <a href="https://www.honeybadger.io">Honeybadger</a>.</p><ul><li><a href="https://xkcd.com/1095/">XKCD - Crazy Straws Fractal Subgroups</a></li><li><a href="https://www.keyboardmaestro.com/">Keyboard Maestro</a></li><li><a href="https://brettterpstra.com/2017/06/15/a-hyper-key-with-karabiner-elements-full-instructions/">Brett Terpstra - Hyper Key</a></li><li><a href="https://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/">Brett Terpstra - A Useful Caps Lock Key</a></li><li><a href="https://vimium.github.io/">Vimium chrome extension</a></li><li><a href="https://tuple.app/">Tuple app</a></li><li><a href="https://devexpress.github.io/testcafe/">testcafe</a></li><li><a href="https://www.cypress.com/">Cypress</a></li><li><a href="https://percy.io/">Percy.io</a></li><li><a href="https://www.npmjs.com/package/jest-screenshot">Jest screenshots</a></li><li><a href="https://testing-library.com/docs/react-testing-library/intro">React Testing Library</a></li><li><a href="https://airbnb.io/enzyme/">Enzyme</a></li><li><a href="https://reactjs.org/docs/hooks-intro.html">React hooks</a></li><li><a href="https://info.thoughtbot.com/how-to-stay-agile-workshop">thoughtbot Health Tech Online Workshop (hosted by Steph!)</a></li></ul><p>If you're enjoying The Bike Shed, we'd love it if you could give it a <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">rating or review on iTunes</a>. Thanks!</p> + + + + On this week's episode, Steph and Chris dive into the world of crafting pull requests for optimal code review, as well as the flip side of providing code review. How can we make it easy for reviewers, and as reviewers, how can we make it easy for our teammates to incorporate our suggestions?

They also discuss the world of testing, from integration to visual to unit testing, and some of the tools an practices they use at each level.

Lastly, they discuss Steph's continued pairing adventures and possibly finding her max on the pairing front, a quick update on mechanical keyboards, and Steph shares a teaser of an upcoming workshop she'll be hosting around how to stay agile when building health tech products.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris dive into the world of crafting pull requests for optimal code review, as well as the flip side of providing code review. How can we make it easy for reviewers, and as reviewers, how can we make it easy for our teammates to incorporate our suggestions?

They also discuss the world of testing, from integration to visual to unit testing, and some of the tools an practices they use at each level.

Lastly, they discuss Steph's continued pairing adventures and possibly finding her max on the pairing front, a quick update on mechanical keyboards, and Steph shares a teaser of an upcoming workshop she'll be hosting around how to stay agile when building health tech products.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+XxuOpv4u + + ]]> + + + + 221: An Informed Opinion + https://bikeshed.thoughtbot.com/221 + c40044a9-f7e2-43a0-a55d-f25ee1182b0d + Tue, 05 Nov 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph catch up on recent client adventures, revisit their feelings on using `let` in rspec, and spend a bit of time outside their respective comfort zones. There's also some talk about nearly full-time pairing, mechanical keyboards, debugging thorny datetime issues, and how we interact with our developer tools and workflows. + + 45:13 + no + + <p>On this week's episode, Chris and Steph catch up on recent client adventures, revisit their feelings on using let in rspec, and spend a bit of time outside their respective comfort zones. There's also some talk about nearly full-time pairing, mechanical keyboards, debugging thorny datetime issues, and how we interact with our developer tools and workflows.</p><p>This episode of <i>The Bike Shed</i> is sponsored by <a href="https://www.honeybadger.io">Honeybadger</a>.</p><ul><li><a href="https://tuple.app/">Tuple (remote pairing app)</a></li><li><a href="https://mechanicalkeyboards.com/shop/index.php?l=product_detail&p=3545">Leopold 660 with Cherry MX Browns</a></li><li><a href="https://github.com/typicode/husky">Husky</a> - "git hooks made easy"</li><li><a href="https://twitter.com/cassidoo/status/1185656470953549824?s=20">Cassidy Williams eslint video tweet</a></li><li><a href="https://github.com/jnunemaker/flipper/tree/master/docs/ui#fun-mode">Flipper "disable fun mode"</a></li><li><a href="https://thoughtbot.com/blog/lets-not">Let’s Not - Rspec blog post</a></li><li><a href="https://www.python.org/dev/peps/pep-0020/">The Zen of Python</a></li></ul><p>If you're enjoying The Bike Shed, we'd love it if you could give it a <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">rating or review on iTunes</a>. Thanks!</p> + + +

On this week's episode, Chris and Steph catch up on recent client adventures, revisit their feelings on using let in rspec, and spend a bit of time outside their respective comfort zones. There's also some talk about nearly full-time pairing, mechanical keyboards, debugging thorny datetime issues, and how we interact with our developer tools and workflows.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + +

On this week's episode, Chris and Steph catch up on recent client adventures, revisit their feelings on using let in rspec, and spend a bit of time outside their respective comfort zones. There's also some talk about nearly full-time pairing, mechanical keyboards, debugging thorny datetime issues, and how we interact with our developer tools and workflows.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+s8qZbCMK + + ]]> + + + + 220: Adequately Fun + https://bikeshed.thoughtbot.com/220 + 10d34c93-8f45-4e9f-8488-c4591a08ccfb + Tue, 29 Oct 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph chat about their new client projects, VimScript, and ways to automate refreshing materialized views in tests. They also play the game Overrated/Underrated, created by Tyler Cowen, and respond to a CS student who is feeling overwhelmed by the various technologies and looking to transition from tutorials to meaningful projects. + 52:29 + no + + <p>On this week's episode, Chris and Steph chat about their new client projects, VimScript, and ways to automate refreshing materialized views in tests. They also play the game Overrated/Underrated, created by Tyler Owen, and respond to a CS student who is feeling overwhelmed by the various technologies and looking to transition from tutorials to meaningful projects.</p><p>This episode of <i>The Bike Shed</i> is sponsored by <a href="https://www.honeybadger.io">Honeybadger</a>.</p><ul><li><a href="https://github.com/thoughtbot/dotfiles">thoughtbot dotfiles</a></li><li><a href="https://github.com/kien/ctrlp.vim">ctrlp.vim</a></li><li><a href="https://github.com/junegunn/fzf">FZF</a></li><li><a href="http://learnvimscriptthehardway.stevelosh.com/">Learn Vimscript the Hard Way</a></li><li><a href="https://github.com/thoughtbot/laptop">thoughtbot laptop script</a></li><li><a href="https://github.com/scenic-views/scenic">scenic</a></li><li><a href="https://conversationswithtyler.com/">Conversations with Tyler</a></li><li><a href="https://shoptalkshow.com/">ShopTalk Show</a></li><li><a href="https://thoughtbot.com/blog/deadlines">Deadlines</a></li><li><a href="https://thoughtbot.com/blog/the-real-story-behind-story-points">The Real Story Behind Story Points</a></li></ul><p>If you're enjoying The Bike Shed, we'd love it if you could give it a <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">rating or review on iTunes</a>. Thanks!</p> + + + + On this week's episode, Chris and Steph chat about their new client projects, VimScript, and ways to automate refreshing materialized views in tests. They also play the game Overrated/Underrated, created by Tyler Owen, and respond to a CS student who is feeling overwhelmed by the various technologies and looking to transition from tutorials to meaningful projects.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph chat about their new client projects, VimScript, and ways to automate refreshing materialized views in tests. They also play the game Overrated/Underrated, created by Tyler Owen, and respond to a CS student who is feeling overwhelmed by the various technologies and looking to transition from tutorials to meaningful projects.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+r_E-Rikg + + ]]> + + + + 219: Seeking That Middle Option + https://bikeshed.thoughtbot.com/219 + 602b38bf-b494-45d5-82c8-6e3627779ad5 + Tue, 22 Oct 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph catches us up on her ever-growing collection of mechanical keyboards, Chris talks about his recent purchase of an apple watch, and they follow up a previous discussion around case-sensitivity (or insensitivity) in URLs and email addresses. They round out the discussion with a chat about writing blog posts and some postgres fun, and finally discuss the merits and drawbacks of monorepos. + 36:02 + no + + <p>On this week's episode, Steph catches us up on her ever-growing collection of mechanical keyboards, Chris talks about his recent purchase of an apple watch, and they follow up a previous discussion around case-sensitivity (or insensitivity) in URLs and email addresses. They round out the discussion with a chat about writing blog posts and some postgres fun, and finally discuss the merits and drawbacks of monorepos.</p><p>This episode of <i>The Bike Shed</i> is sponsored by <a href="https://www.honeybadger.io">Honeybadger</a>.</p><ul><li><a href="http://mechanicalkeyboards.com">MechanicalKeyboards.com</a></li><li><a href="https://mechanicalkeyboards.com/shop/index.php?l=product_detail&p=5269">Frozen LLama Ducky Keyboard</a></li><li><a href="https://www.apple.com/watch/">Apple Watch</a></li><li><a href="https://www.withings.com/us/en/watches">Withings Watch</a></li><li><a href="https://www.postgresql.org/docs/12/citext.html">Postgres Citext (Case-Insensitive text field type)</a></li><li><a href="https://thoughtbot.com/blog/sharing-query-logic-within-activerecord-mdoels">Chris's blog post on Sharing Query Logic Within ActiveRecord Models</a></li><li><a href="https://thoughtbot.com/blog/deadlines">Matt Sumner's Post on Deadlines</a></li><li><a href="https://www.stephenking.com/library/nonfiction/on_writing:_a_memoir_of_the_craft.html">On Writing by Stephen King</a></li><li><a href="https://stevenpressfield.com/books/the-war-of-art/">The War of Art</a></li><li><a href="https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b">Monorepos: Please don’t!</a></li><li><a href="https://medium.com/@adamhjk/monorepo-please-do-3657e08a4b70">Monorepo: please do!</a></li><li><a href="https://github.com/lerna/lerna">Lerna - toll for monorepo management in javascript</a></li></ul><p>If you're enjoying The Bike Shed, we'd love it if you could give it a <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">rating or review on iTunes</a>. Thanks!</p> + + + + On this week's episode, Steph catches us up on her ever-growing collection of mechanical keyboards, Chris talks about his recent purchase of an apple watch, and they follow up a previous discussion around case-sensitivity (or insensitivity) in URLs and email addresses. They round out the discussion with a chat about writing blog posts and some postgres fun, and finally discuss the merits and drawbacks of monorepos.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + + On this week's episode, Steph catches us up on her ever-growing collection of mechanical keyboards, Chris talks about his recent purchase of an apple watch, and they follow up a previous discussion around case-sensitivity (or insensitivity) in URLs and email addresses. They round out the discussion with a chat about writing blog posts and some postgres fun, and finally discuss the merits and drawbacks of monorepos.

This episode of The Bike Shed is sponsored by Honeybadger.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+U8JL94JO + + ]]> + + + + 218: Finesse in Quitting (Brittany Martin) + https://bikeshed.thoughtbot.com/218 + 506b3307-ff99-407a-aaad-eb3eb58f9f79 + Tue, 15 Oct 2019 10:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph is joined by Brittany Martin, an avid Rubyist and the host of the Ruby on Rails Podcast. They discuss Brittany's passion for roller derby and her upcoming Ruby conference talk: "Hire Me, I'm Excellent at Quitting." They also discuss using AWS Serverless, troubleshooting Postgress connection errors and working with Google Pay and Apple Wallet to introduce digital tickets. + 41:54 + no + + <p>On this week's episode, Steph is joined by Brittany Martin, an avid Rubyist and the host of the Ruby on Rails Podcast. They discuss Brittany's passion for roller derby and her upcoming Ruby conference talk: "Hire Me, I'm Excellent at Quitting." They also discuss using AWS Serverless, troubleshooting Postgress connection errors and working with Google Pay and Apple Wallet to introduce digital tickets.</p><ul><li><a href="https://twitter.com/BrittJMartin">@BrittJMartin - Brittany on Twitter</a></li><li><a href="http://5by5.tv/rubyonrails">Ruby on Rails Podcast</a></li><li><a href="http://rubyconf.org/program#session-888">RubyConf 2019 - Hire Me: I'm Excellent at Quitting</a></li><li><a href="http://5by5.tv/rubyonrails/285">Bikeshedding with Steph Viccari</a></li><li><a href="https://www.youtube.com/watch?v=iJM8EOXeKy0">TN Inspire! "Ramping Up With Roller Derby"</a></li><li><a href="https://www.youtube.com/watch?v=bmIfkcAQEE8">RubyConf MY - Rails Against the Machine</a></li><li><a href="https://www.hanselman.com/blog/RubyOnRailsOnWindowsIsNotJustPossibleItsFabulousUsingWSL2AndVSCode.aspx">Ruby on Rails on Windows is not just possible, it's fabulous using WSL2 and VS Code</a></li><li><a href="https://aws.amazon.com/rds/aurora/serverless/">Amazon Aurora Serverless</a></li><li><a href="https://www.nateberkopec.com/">Nate Berkopec - Speed Shop</a></li></ul> + + +

On this week's episode, Steph is joined by Brittany Martin, an avid Rubyist and the host of the Ruby on Rails Podcast. They discuss Brittany's passion for roller derby and her upcoming Ruby conference talk: "Hire Me, I'm Excellent at Quitting." They also discuss using AWS Serverless, troubleshooting Postgress connection errors and working with Google Pay and Apple Wallet to introduce digital tickets.

Support The Bike Shed

]]> + + +

On this week's episode, Steph is joined by Brittany Martin, an avid Rubyist and the host of the Ruby on Rails Podcast. They discuss Brittany's passion for roller derby and her upcoming Ruby conference talk: "Hire Me, I'm Excellent at Quitting." They also discuss using AWS Serverless, troubleshooting Postgress connection errors and working with Google Pay and Apple Wallet to introduce digital tickets.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+tcVtnPLx + + ]]> + + + + 217: A Vote For Reasonableness + https://bikeshed.thoughtbot.com/217 + 6f782749-4f6c-44ca-97ea-b16d0fc34f4e + Tue, 08 Oct 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph shares an update on her mechanical keyboard adventures and provides a summary for the Ruby pipeline operator being reverted. Chris gets Steph's opinion on a possible improvement around using materialized views in tests and describes a recent debugging adventure he and Steph went on. They also discuss a listener question regarding encouraging companies to use Ruby and Rails and asking how we identify ourselves as developers. Finally, they round out the conversation with a clarification around public vs private GraphQL APIs. + 32:47 + no + + <p>On this week's episode, Steph shares an update on her mechanical keyboard adventures and provides a summary for the Ruby pipeline operator being reverted. Chris gets Steph's opinion on a possible improvement around using materialized views in tests and describes a recent debugging adventure he and Steph went on. They also discuss a listener question regarding encouraging companies to use Ruby and Rails and asking how we identify ourselves as developers. Finally, they round out the conversation with a clarification around public vs private GraphQL APIs.</p><ul><li><a href="https://mechanicalkeyboards.com/shop/index.php?l=product_list&c=170">Leopold 660 Keyboard</a></li><li><a href="https://deskthority.net/wiki/Topre_switch">Topre Silent Keys</a></li><li><a href="https://www.keychron.com/products/keychron-k2-mechanical-keyboard">Keychron K2</a></li><li><a href="https://www.postgresql.org/docs/9.3/rules-materializedviews.html">Postgres Materialized Views</a></li><li><a href="https://github.com/scenic-views/scenic">Scenic - Database Views Library for Rails</a></li><li><a href="https://api.rubyonrails.org/classes/ActiveSupport/Cache/NullStore.html">Rails Cache Null Store</a></li><li><a href="http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/94645">Ruby Pipeline Operator Reverted</a></li><li><a href="https://github.com/rails/rails/tree/master/activemodel">ActiveModel::Model</a></li><li><a href="https://github.com/rails/spring">Spring Rails Preloader</a></li><li><a href="http://ruby-doc.org/core-2.6.3/Method.html">Ruby <code>:method</code> source_location</a></li></ul><p>If you're enjoying The Bike Shed, we'd love it if you could give it a <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">rating or review on iTunes</a>. Thanks!</p> + + +

On this week's episode, Steph shares an update on her mechanical keyboard adventures and provides a summary for the Ruby pipeline operator being reverted. Chris gets Steph's opinion on a possible improvement around using materialized views in tests and describes a recent debugging adventure he and Steph went on. They also discuss a listener question regarding encouraging companies to use Ruby and Rails and asking how we identify ourselves as developers. Finally, they round out the conversation with a clarification around public vs private GraphQL APIs.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + +

On this week's episode, Steph shares an update on her mechanical keyboard adventures and provides a summary for the Ruby pipeline operator being reverted. Chris gets Steph's opinion on a possible improvement around using materialized views in tests and describes a recent debugging adventure he and Steph went on. They also discuss a listener question regarding encouraging companies to use Ruby and Rails and asking how we identify ourselves as developers. Finally, they round out the conversation with a clarification around public vs private GraphQL APIs.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+SWHdNq42 + + ]]> + + + + 216: I'm Not the Best Criminal + https://bikeshed.thoughtbot.com/216 + 123a5830-8e92-4c71-8a02-c0ead8199e30 + Tue, 01 Oct 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph recounts an issue with an email client that lowercases URLs and Chris ponders the art of logging and using structured logs. They also highlight a plugin that improves TypeScript support in Vim, how the Pinterest team celebrates the "retirement" of code, and respond to a listener who is debating between refactoring their app or investing in a full rewrite. + 39:16 + no + + <p>On this week's episode, Steph recounts an issue with an email client that lowercases URLs and Chris ponders the art of logging and using structured logs. They also highlight a plugin that improves TypeScript support in Vim, how the Pinterest team celebrates the "retirement" of code, and respond to a listener who is debating between refactoring their app or investing in a full rewrite.</p><ul><li><a href="https://deskthority.net/wiki/Topre_switch">Topre</a></li><li><a href="https://mechanicalkeyboards.com/shop/index.php?l=product_list&c=170">Leopold FC660C Keyboard</a></li><li><a href="https://deskthority.net/wiki/Cherry_MX">Cherry MX Switches</a></li><li><a href="https://api.rubyonrails.org/classes/ActiveSupport/MessageVerifier.html">ActiveSupport::MessageVerifier</a></li><li><a href="https://github.com/thoughtbot/clearance">Clearance</a></li><li><a href="https://github.com/plataformatec/devise">Devise</a></li><li><a href="https://github.com/rails/rails/issues/27995">ActiveSupport Message verifier with double slash trouble</a></li><li><a href="https://www.owasp.org/index.php/Main_Page">OWASP</a></li><li><a href="https://reactpodcast.simplecast.fm/64">React Podcast - Chris Toomey on TypeScript, GraphQL, and Product Thinking</a></li><li><a href="https://bikeshed.fm/episodes/209">We Will Never Know Enough (Michael Chan)</a></li><li><a href="https://api.rubyonrails.org/classes/ActiveSupport/TaggedLogging.html">ActiveSupport::TaggedLogging</a></li><li><a href="https://docs.timber.io/guides/structured-logging-best-practices">Structured Logging</a></li><li><a href="https://github.com/neoclide/coc.nvim">Conquer of Completion - Make your vim/neovim as smart as VSCode</a></li><li><a href="https://medium.com/pinterest-engineering/the-dead-code-society-2f189ff46b04">The Dead Code Society</a></li></ul><p>If you're enjoying The Bike Shed, we'd love it if you could give it a <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">rating or review on iTunes</a>. Thanks!</p> + + + + On this week's episode, Steph recounts an issue with an email client that lowercases URLs and Chris ponders the art of logging and using structured logs. They also highlight a plugin that improves TypeScript support in Vim, how the Pinterest team celebrates the "retirement" of code, and respond to a listener who is debating between refactoring their app or investing in a full rewrite.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + + On this week's episode, Steph recounts an issue with an email client that lowercases URLs and Chris ponders the art of logging and using structured logs. They also highlight a plugin that improves TypeScript support in Vim, how the Pinterest team celebrates the "retirement" of code, and respond to a listener who is debating between refactoring their app or investing in a full rewrite.

If you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+9l3Qy-EJ + + ]]> + + + + 215: Start With People + https://bikeshed.thoughtbot.com/215 + 6c9b0d6e-2769-4a38-a41b-7899720515d9 + Tue, 24 Sep 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph returns from vacation and Chris makes some noise about a fantastic new button. They discuss Steph's continued adventures in search of the perfect mechanical keyboard and then dig into two listener questions on landing a first job as a developer and what frameworks and languages to focus on, as well as discussing some of the common objections to GraphQL. + 35:00 + no + + <p>On this week's episode, Steph returns from vacation and Chris makes some noise about a fantastic new button. They discuss Steph's continued adventures in search of the perfect mechanical keyboard and then dig into two listener questions on landing a first job as a developer and what frameworks and languages to focus on, as well as discussing some of the common objections to GraphQL.</p><ul><li><a href="https://github.com/rails/rails/pull/34788">Rails ActionableErrors - Migration Button</a></li><li><a href="https://codekeyboards.com/">CODE Keyboard</a></li><li><a href="https://www.keychron.com/products/keychron-k2-mechanical-keyboard">Keychron K2 keyboard</a></li><li><a href="https://twitter.com/cassidoo">Cassidy Williams on Twitter</a></li><li><a href="https://www.youtube.com/watch?v=T8J0j2xJFgQ">Avdi Confident Code talk</a></li><li><a href="https://www.confidentruby.com/">Avdi Confident Ruby book</a></li><li><a href="https://en.wikipedia.org/wiki/Robustness_principle">Robustness principle</a></li><li><a href="https://www.railstutorial.org/">The Rails Tutorial</a></li><li><a href="https://insights.stackoverflow.com/survey/2019#most-popular-technologies">Stack Overflow 2019 developer survey</a></li><li><a href="https://github.com/graphql/dataloader">Dataloader for GraphQL</a></li><li><a href="https://github.com/Shopify/graphql-batch">graphql-batch from Shopify</a></li><li><a href="https://blog.apollographql.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5">GraphQL persisted Queries</a></li></ul> + + +

On this week's episode, Steph returns from vacation and Chris makes some noise about a fantastic new button. They discuss Steph's continued adventures in search of the perfect mechanical keyboard and then dig into two listener questions on landing a first job as a developer and what frameworks and languages to focus on, as well as discussing some of the common objections to GraphQL.

Support The Bike Shed

]]> + + +

On this week's episode, Steph returns from vacation and Chris makes some noise about a fantastic new button. They discuss Steph's continued adventures in search of the perfect mechanical keyboard and then dig into two listener questions on landing a first job as a developer and what frameworks and languages to focus on, as well as discussing some of the common objections to GraphQL.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+j6cCZ6rL + + ]]> + + + + 214: Have You Tried Refreshing the Page? + https://bikeshed.thoughtbot.com/214 + 2483e8c9-edef-4977-940e-6939ad67a98e + Tue, 17 Sep 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Matt Sumner guest stars to discuss his recent adventures on a project that uses React, TypeScript and GraphQL. Along the way, Matt and Chris discuss VS Code features, Apollo caching and reflect upon their first year as Development Directors. 
 + 38:43 + no + + <p>On this week's episode, Matt Sumner guest stars to discuss his recent adventures on a project that uses React, TypeScript and GraphQL. Along the way, Matt and Chris discuss VS Code features, Apollo caching and reflect upon their first year as Development Directors. 
</p><ul><li><a href="http://5by5.tv/rubyonrails/285">RoR Podcast episode with Steph</a></li><li><a href="https://www.ethereum.org">Etherium</a></li><li><a href="https://reactjs.org">React</a></li><li><a href="https://www.typescriptlang.org/">TypeScript</a></li><li><a href="https://graphql.org/">GraphQL</a></li><li><a href="http://www.extremeprogramming.org/rules/testfirst.html">TDD</a></li><li><a href="https://code.visualstudio.com/">
VS Code</a></li><li><a href="https://www.apollographql.com/">Apollo</a></li><li><a href="https://github.com/apollographql/apollo-tooling">
Apollo tooling</a></li><li><a href="https://elm-lang.org/">
Elm</a></li><li><a href="https://redux.js.org/:">Redux</a></li><li><a href="https://bikeshed.fm/episodes/188">German Velasco - A Function by Any Other Name</a></li><li><a href="https://bikeshed.fm/episodes/167">German Velasco - I Feel Like We Should've Solved This By Now</a></li><li><a href="https://www.beplucky.com/">Plucky</a></li></ul><p><a href="https://thoughtbot.com/jobs">
thoughtbot is hiring!</a></p> + + +

On this week's episode, Matt Sumner guest stars to discuss his recent adventures on a project that uses React, TypeScript and GraphQL. Along the way, Matt and Chris discuss VS Code features, Apollo caching and reflect upon their first year as Development Directors. 



thoughtbot is hiring!

Support The Bike Shed

]]> + + +

On this week's episode, Matt Sumner guest stars to discuss his recent adventures on a project that uses React, TypeScript and GraphQL. Along the way, Matt and Chris discuss VS Code features, Apollo caching and reflect upon their first year as Development Directors. 



thoughtbot is hiring!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+FtidZhSu + + ]]> + + + + 213: Admins Matter Too + https://bikeshed.thoughtbot.com/213 + 16193764-2442-4fe3-8e06-073f8b497d50 + Tue, 10 Sep 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph discusses a mini design sprint she led to help validate an internal admin tool while Chris muses on the merits of net negative lines of code on a project. They dig into the idea that while code can certainly be an asset, it may also be a liability. They investigate ActiveSupport::MessageVerifier for secure time-sensitive tokens. Steph shares details about her recent visit to the Ruby on Rails Podcast and Chris shares the recording for a talk he gave on understanding technology choices. Lastly, they round out the conversation with a listener question about build times and lock files and how to organize and split up our tests. + 35:18 + no + + <p>On this week's episode, Steph discusses a mini design sprint she led to help validate an internal admin tool while Chris muses on the merits of net negative lines of code on a project. They dig into the idea that while code can certainly be an asset, it may also be a liability. They investigate ActiveSupport::MessageVerifier for secure time-sensitive tokens. Steph shares details about her recent visit to the Ruby on Rails Podcast and Chris shares the recording for a talk he gave on understanding technology choices. Lastly, they round out the conversation with a listener question about build times and lock files and how to organize and split up our tests.</p><ul><li><a href="https://thoughtbot.com/resources/speed?wvideo=zb68qyu0xi">Your First Technology Decisions Talk by Chris Toomey - video recording</a></li><li><a href="http://5by5.tv/rubyonrails/285">Steph on The Ruby on Rails Podcast</a></li><li><a href="https://thoughtbot.com/product-design-sprint/guide">Product Design Sprint Guide</a></li><li><a href="https://thoughtbot.com/resources/validation?wvideo=xyh7stibu2">Product Design Sprint - Five Phases Overview Video</a></li><li><a href="https://api.rubyonrails.org/v5.2.3/classes/ActiveSupport/MessageVerifier.html">ActiveSupport::MessageVerifier</a></li><li><a href="https://www.youtube.com/watch?v=IcgmSRJHu_8">Making Impossible States Impossible talk by Richard Feldman</a></li><li><a href="https://thoughtbot.com/blog/how-we-test-rails-applications#view-specs">Rails View Specs</a></li></ul> + + +

On this week's episode, Steph discusses a mini design sprint she led to help validate an internal admin tool while Chris muses on the merits of net negative lines of code on a project. They dig into the idea that while code can certainly be an asset, it may also be a liability. They investigate ActiveSupport::MessageVerifier for secure time-sensitive tokens. Steph shares details about her recent visit to the Ruby on Rails Podcast and Chris shares the recording for a talk he gave on understanding technology choices. Lastly, they round out the conversation with a listener question about build times and lock files and how to organize and split up our tests.

Support The Bike Shed

]]> + + +

On this week's episode, Steph discusses a mini design sprint she led to help validate an internal admin tool while Chris muses on the merits of net negative lines of code on a project. They dig into the idea that while code can certainly be an asset, it may also be a liability. They investigate ActiveSupport::MessageVerifier for secure time-sensitive tokens. Steph shares details about her recent visit to the Ruby on Rails Podcast and Chris shares the recording for a talk he gave on understanding technology choices. Lastly, they round out the conversation with a listener question about build times and lock files and how to organize and split up our tests.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+2KcFkS76 + + ]]> + + + + 212: Award Winning Sheds + https://bikeshed.thoughtbot.com/212 + 26b79cad-c0a8-4871-87c4-c1143ac4c85b + Wed, 04 Sep 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris share the news that The Bike Shed won the Best Dev Podcast on the Hackernoon Noonies awards! After a bit of celebration, they get back to their normal adventures with a discussion around onboarding covering the importance, approach, and pitfalls that they've seen in their time joining countless teams. They also touch on the relevance and increasing ease of SSL everywhere, and they answer a listener question about technical debt and rewriting applications. + 37:17 + no + + <p>On this week's episode, Steph and Chris share the news that The Bike Shed won the Best Dev Podcast on the Hackernoon Noonies awards! After a bit of celebration, they get back to their normal adventures with a discussion around onboarding covering the importance, approach, and pitfalls that they've seen in their time joining countless teams. They also touch on the relevance and increasing ease of SSL everywhere, and they answer a listener question about technical debt and rewriting applications.</p> +<ul> +<li><a href="https://noonies.hackernoon.com/award/cjxrat2ogn51d0b429e2zwy52">Bike Shed - Best Dev Podcast Noonies</a></li> +<li><a href="https://simplecast.com/">Simplecast</a></li> +<li><a href="https://letsencrypt.org/">Let's Encrypt</a></li> +<li><a href="https://www.heroku.com/">Heroku</a></li> +<li><a href="https://www.netlify.com/">Netlify</a></li> +<li><a href="https://giantrobots.fm/episodes/163">Nadia Odunayo on Giant Robots</a></li> +<li><a href="http://www.nadiaodunayo.com/speaking/the-guest-a-guide-to-code-hospitality">A Guide To Code Hospitality - Nadia Odunayo</a></li> +<li><a href="https://www.rahulpnath.com/blog/the-headphones-rule/">The Headphones Rule</a></li> +<li><a href="https://en.wikipedia.org/wiki/Second-system_effect">Second System Syndrome</a></li> +<li><a href="https://www.michaelnygard.com/blog/2017/12/the-entity-service-antipattern/">Entity Service Antipattern</a></li> +<li><a href="https://giantrobots.fm/episodes/334">Devon Zuegel on Giant Robots</a></li> +</ul> + + + + On this week's episode, Steph and Chris share the news that The Bike Shed won the Best Dev Podcast on the Hackernoon Noonies awards! After a bit of celebration, they get back to their normal adventures with a discussion around onboarding covering the importance, approach, and pitfalls that they've seen in their time joining countless teams. They also touch on the relevance and increasing ease of SSL everywhere, and they answer a listener question about technical debt and rewriting applications.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris share the news that The Bike Shed won the Best Dev Podcast on the Hackernoon Noonies awards! After a bit of celebration, they get back to their normal adventures with a discussion around onboarding covering the importance, approach, and pitfalls that they've seen in their time joining countless teams. They also touch on the relevance and increasing ease of SSL everywhere, and they answer a listener question about technical debt and rewriting applications.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+2RnhtJne + + ]]> + + + + 211: I'm Not a Lawyer, But... + https://bikeshed.thoughtbot.com/211 + d30e004a-c0d7-409d-831f-ddd524898196 + Tue, 27 Aug 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph discuss their preferred strategy when building an admin portal (spoiler: it's not using a client-side technology), separating our identity from our preferred technology, coding styles that require greater mental effort, and answer a listener's question about deleting migrations. + 36:28 + no + + <p>On this week's episode, Chris and Steph discuss their preferred strategy when building an admin portal (spoiler: it's not using a client-side technology), separating our identity from our preferred technology, coding styles that require greater mental effort, and answer a listener's question about deleting migrations.</p> +<ul> +<li><a href="https://jquery.com/">JQuery</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://ruby-doc.org/core-2.6.3/Enumerable.html#method-i-drop_while">Enumerable#drop_while</a></li> +<li><a href="https://thoughtbot.com/blog/priming-the-pump">rails dev prime task</a></li> +<li><a href="https://edgeguides.rubyonrails.org/active_record_migrations.html">Active Record Migrations</a></li> +<li><a href="https://github.com/thoughtbot/factory_bot/blob/master/GETTING_STARTED.md#linting-factories">Factory Bot - linting factories</a></li> +</ul> + + + + On this week's episode, Chris and Steph discuss their preferred strategy when building an admin portal (spoiler: it's not using a client-side technology), separating our identity from our preferred technology, coding styles that require greater mental effort, and answer a listener's question about deleting migrations.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph discuss their preferred strategy when building an admin portal (spoiler: it's not using a client-side technology), separating our identity from our preferred technology, coding styles that require greater mental effort, and answer a listener's question about deleting migrations.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MNY_WJW9 + + ]]> + + + + 210: Stop Trying to Make Fetch Happen + https://bikeshed.thoughtbot.com/210 + 4e818d55-0d08-4c8e-8e86-00516ea43aa8 + Tue, 20 Aug 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss mechanical keyboards, combating error fatigue, the joy of admin features and respond to two listener questions about typed vs dynamic languages and various ways to "speed up" third-party API calls. + 34:46 + no + + <p>On this week's episode, Steph and Chris discuss mechanical keyboards, combating error fatigue, the joy of admin features and respond to two listener questions about typed vs dynamic languages and various ways to &quot;speed up&quot; third-party API calls.</p> +<ul> +<li><a href="https://appsignal.com/">AppSignal</a></li> +<li><a href="https://blog.newrelic.com/engineering/prevent-alert-fatigue/">New Relic - Six Steps to Combat Alert Fatigue</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary">Details and Summary HTML elements</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://www.typescriptlang.org/">Typescript</a></li> +<li><a href="https://edgeguides.rubyonrails.org/active_job_basics.html">Active Job</a></li> +<li><a href="https://guides.rubyonrails.org/action_cable_overview.html">Action Cable</a></li> +<li><a href="https://stimulusjs.org/">Stimulus</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/Guide/AJAX">Ajax</a></li> +<li><a href="https://github.com/typhoeus/typhoeus">Typheous</a></li> +<li><a href="https://api.rubyonrails.org/classes/ActionController/Streaming.html">Rails HTTP Streaming</a></li> +<li><a href="https://jquery.com/">JQuery</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of <em>The Bike Shed</em>!</p> + + + + On this week's episode, Steph and Chris discuss mechanical keyboards, combating error fatigue, the joy of admin features and respond to two listener questions about typed vs dynamic languages and various ways to "speed up" third-party API calls.

+ + + +

Become a Sponsor of The Bike Shed!

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris discuss mechanical keyboards, combating error fatigue, the joy of admin features and respond to two listener questions about typed vs dynamic languages and various ways to "speed up" third-party API calls.

+ + + +

Become a Sponsor of The Bike Shed!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+71iBTnVi + + ]]> + + + + 209: We Will Never Know Enough (Michael Chan) + https://bikeshed.thoughtbot.com/209 + 28456ea1-b255-4784-b4d2-be591f8bd6ab + Tue, 13 Aug 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode Chris is joined by Michael Chan aka @chantastic, host of the React Podcast and prolific maker and sharer throughout the internets. They discuss Micheal's work on the React Podcast and themes in open source in general, Michael's focus on communication and delivering value, and the honest take that no one has all the answers or a silver bullet. + 39:15 + no + + <p>On this week's episode Chris is joined by Michael Chan aka @chantastic, host of the React Podcast and prolific maker and sharer throughout the internets. They discuss Micheal's work on the React Podcast and themes in open source in general, Michael's focus on communication and delivering value, and the honest take that no one has all the answers or a silver bullet.</p> +<ul> +<li><a href="https://twitter.com/chantastic">Michael Chan</a></li> +<li><a href="https://twitter.com/chantastic">@chantastic - Michael on twitter</a></li> +<li><a href="https://reactpodcast.simplecast.fm/">React Podcast</a></li> +<li><a href="https://chan.dev/blog">Michael's Blog</a></li> +<li><a href="https://dev.to/chantastic">Michael's writing on dev.to</a></li> +<li><a href="https://www.youtube.com/watch?v=-NP_upexPFg">Hot Garbage - the Death Of Clean Code</a></li> +<li><a href="https://stevenpressfield.com/books/the-war-of-art/">War of Art</a></li> +<li><a href="https://www.sandimetz.com/">Sandi Metz</a></li> +<li><a href="https://www.styled-components.com/">Styled Components</a></li> +<li><a href="https://emotion.sh/docs/introduction">Emotion</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties">CSS Variables</a></li> +<li><a href="https://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html">React: CSS in JS - talk by Christopher &quot;vjeux&quot; Chedeau</a></li> +<li><a href="http://getbem.com/">BEM</a></li> +<li><a href="https://github.com/lerna/lerna">Lerna</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/Web_Components">Web components</a></li> +<li><a href="https://reactpodcast.simplecast.fm/56">Paul Henschel on React Spring - React Podcast episode</a></li> +</ul> + + + + On this week's episode Chris is joined by Michael Chan aka @chantastic, host of the React Podcast and prolific maker and sharer throughout the internets. They discuss Micheal's work on the React Podcast and themes in open source in general, Michael's focus on communication and delivering value, and the honest take that no one has all the answers or a silver bullet.

+ +

Support The Bike Shed

]]> + + + On this week's episode Chris is joined by Michael Chan aka @chantastic, host of the React Podcast and prolific maker and sharer throughout the internets. They discuss Micheal's work on the React Podcast and themes in open source in general, Michael's focus on communication and delivering value, and the honest take that no one has all the answers or a silver bullet.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+mALMPMnR + + ]]> + + + + 208: Goldilocks and the Three Monitors + https://bikeshed.thoughtbot.com/208 + 204dca0b-816e-4f9d-9f9a-da0f370f7103 + Tue, 06 Aug 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris and Steph weigh-in on curved monitors, discuss how pairing improves productivity and team morale, and respond to two listener questions inquiring what makes Rails successful and new project nerves. + 33:30 + no + + <p>On this week's episode, Chris and Steph weigh-in on curved monitors, discuss how pairing improves productivity and team morale, and respond to two listener questions inquiring what makes Rails successful and new project nerves.</p> +<p>Vote for us for <a href="https://noonies.hackernoon.com/award/cjxrat2ogn51d0b429e2zwy52">'Best Dev' Podcast</a> in this year's Noonie Awards.</p> +<ul> +<li><a href="https://rubyonrails.org/">Rails</a></li> +<li><a href="https://github.com/testing-library/react-testing-library">react-testing-library</a></li> +<li><a href="https://reactjs.org/">React</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://github.com/rails-api/active_model_serializers">active_model_serializers</a></li> +<li><a href="https://github.com/nesquena/rabl">RABL</a></li> +<li><a href="https://github.com/rails/jbuilder">Jbuilder</a></li> +<li><a href="https://www.ruby-lang.org/en/">Ruby</a></li> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://www.python.org/">Python</a></li> +</ul> + + + + On this week's episode, Chris and Steph weigh-in on curved monitors, discuss how pairing improves productivity and team morale, and respond to two listener questions inquiring what makes Rails successful and new project nerves.

+ +

Vote for us for 'Best Dev' Podcast in this year's Noonie Awards.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris and Steph weigh-in on curved monitors, discuss how pairing improves productivity and team morale, and respond to two listener questions inquiring what makes Rails successful and new project nerves.

+ +

Vote for us for 'Best Dev' Podcast in this year's Noonie Awards.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+UI1kbi2T + + ]]> + + + + 207: Very-Bad, Or Just Normal-Bad? + https://bikeshed.thoughtbot.com/207 + 60cd79c9-6db0-4baf-b994-63e15647e77b + Tue, 30 Jul 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss a handful of utilities that help with their workflows and GitHub, and then dive into a handful of ActiveRecord, SQL, and postgres-related topics. They discuss safe vs unsafe migrations when dealing with larger volumes of data, adding an index safely in migration without downtime, and bringing postgres enums into Rails. + 39:46 + no + + <p>On this week's episode, Steph and Chris discuss a handful of utilities that help with their workflows and GitHub, and then dive into a handful of ActiveRecord, SQL, and postgres-related topics. They discuss safe vs unsafe migrations when dealing with larger volumes of data, adding an index safely in migration without downtime, and bringing postgres enums into Rails.</p> +<p>Vote for us for <a href="https://noonies.hackernoon.com/award/cjxrat2ogn51d0b429e2zwy52">'Best Dev Podcast'</a> in this year's Noonie Awards.</p> +<p>This episode of <em>The Bike Shed</em> is sponsored by <a href="http://www.indeedprime.com/thoughtbot">Indeed Prime</a></p> +<ul> +<li><a href="https://github.blog/changelog/2019-06-11-jump-to-definition-in-public-repositories">GitHub beta jump to definition</a></li> +<li><a href="https://eslint.org/">ESlint</a></li> +<li><a href="https://github.com/rubocop-hq/rubocop">Rubocop</a></li> +<li><a href="https://github.com/sindresorhus/refined-github">Refined GitHub</a></li> +<li><a href="https://sindresorhus.com/">Sindresorhus</a></li> +<li><a href="https://github.blog/2018-08-28-announcing-paper-cuts/">Paper Cuts team at github</a></li> +<li><a href="https://help.github.com/en/articles/getting-permanent-links-to-files">GitHub permalinks</a></li> +<li><a href="https://tellmewhenitcloses.com/">Tell Me When It Closes</a></li> +<li><a href="https://github.blog/changelog/2019-05-09-custom-thread-subscriptions/">GitHub &quot;Custom thread subscriptions&quot; - TMWIC native on GitHub</a></li> +<li><a href="https://github.com/apollographql/apollo-tooling">Apollo codegen</a></li> +<li><a href="https://github.com/gocardless/activerecord-safer_migrations">ActiveRecord safer migrations gem</a></li> +<li><a href="https://github.com/ankane/strong_migrations">Strong migrations gem</a></li> +<li><a href="https://github.com/ankane/strong_migrations#dangerous-operations">Strong migrations README summary of unsafe operations</a></li> +<li><a href="https://www.postgresql.org/docs/9.1/sql-createindex.html">Postgres add index concurrently</a></li> +<li><a href="https://github.com/alassek/activerecord-pg_enum">ActiveRecord::PGEnum</a></li> +</ul> + + +

On this week's episode, Steph and Chris discuss a handful of utilities that help with their workflows and GitHub, and then dive into a handful of ActiveRecord, SQL, and postgres-related topics. They discuss safe vs unsafe migrations when dealing with larger volumes of data, adding an index safely in migration without downtime, and bringing postgres enums into Rails.

+ +

Vote for us for 'Best Dev Podcast' in this year's Noonie Awards.

+ +

This episode of The Bike Shed is sponsored by Indeed Prime

+ +

Support The Bike Shed

]]> + + +

On this week's episode, Steph and Chris discuss a handful of utilities that help with their workflows and GitHub, and then dive into a handful of ActiveRecord, SQL, and postgres-related topics. They discuss safe vs unsafe migrations when dealing with larger volumes of data, adding an index safely in migration without downtime, and bringing postgres enums into Rails.

+ +

Vote for us for 'Best Dev Podcast' in this year's Noonie Awards.

+ +

This episode of The Bike Shed is sponsored by Indeed Prime

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Oo9ih34z + + ]]> + + + + 206: No-One Wants to be the Canary + https://bikeshed.thoughtbot.com/206 + f9eb67eb-d0b0-40da-a576-edc59021d02c + Tue, 23 Jul 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris discuss working with Django, Angular, and explore the new features released in Ruby 2.7.0-preview1! They also respond to a listener's question regarding the trade-offs of using client state management tools like NgRx and Redux. + 38:08 + no + + <p>On this week's episode, Steph and Chris discuss working with Django, Angular, and explore the new features released in Ruby 2.7.0-preview1! They also respond to a listener's question regarding the trade-offs of using client state management tools like NgRx and Redux.</p> +<p>Vote for us for <a href="https://noonies.hackernoon.com/award/cjxrat2ogn51d0b429e2zwy52">'Best Dev' Podcast</a> in this year's Noonie Awards.</p> +<ul> +<li><a href="https://www.python.org/">Python</a></li> +<li><a href="https://www.djangoproject.com/">Django</a></li> +<li><a href="https://angular.io/">Angular</a></li> +<li><a href="https://www.typescriptlang.org/">TypeScript</a></li> +<li><a href="https://www.mysql.com/">MySQL</a></li> +<li><a href="https://graphql.org/">GraphQL</a></li> +<li><a href="https://www.ruby-lang.org/en/">Ruby</a></li> +<li><a href="https://www.ruby-lang.org/en/news/2019/05/30/ruby-2-7-0-preview1-released/">Ruby 2.7.0-preview1</a></li> +<li><a href="https://bugs.ruby-lang.org/issues/15626">Manual Compaction for MRI's GC submitted by Aaron Patterson</a></li> +<li><a href="https://en.wikipedia.org/wiki/Interactive_Ruby_Shell">IRB - Interactive Ruby Shell</a></li> +<li><a href="https://mamememo.blogspot.com/2019/06/a-brief-history-of-pipeline-operator.html">A Brief History of Pipeline Operator</a></li> +<li><a href="https://thoughtbot.com/blog/using-yieldself-for-composable-activerecord-relations">Using yield_self for composable ActiveRecord relations</a></li> +<li><a href="https://bugs.ruby-lang.org/projects/ruby-trunk/roadmap">Ruby trunk - roadmap</a></li> +<li><a href="https://elixir-lang.org/">Elixir</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://ngrx.io/">NgRx</a></li> +<li><a href="https://reactjs.org/">React</a></li> +<li><a href="https://redux.js.org/">Redux</a></li> +<li><a href="https://github.com/reduxjs/redux-thunk">Redux thunk</a></li> +<li><a href="https://facebook.github.io/flux/">Flux</a></li> +<li><a href="https://react-redux.js.org/next/api/hooks">Redux Hooks</a></li> +</ul> + + +

On this week's episode, Steph and Chris discuss working with Django, Angular, and explore the new features released in Ruby 2.7.0-preview1! They also respond to a listener's question regarding the trade-offs of using client state management tools like NgRx and Redux.

+ +

Vote for us for 'Best Dev' Podcast in this year's Noonie Awards.

+ +

Support The Bike Shed

]]> + + +

On this week's episode, Steph and Chris discuss working with Django, Angular, and explore the new features released in Ruby 2.7.0-preview1! They also respond to a listener's question regarding the trade-offs of using client state management tools like NgRx and Redux.

+ +

Vote for us for 'Best Dev' Podcast in this year's Noonie Awards.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+RPfbMF2- + + ]]> + + + + 205: Won't Somebody Think of The Jokes (Aaron Patterson) + https://bikeshed.thoughtbot.com/205 + 18dee379-a7e0-43ae-ad0c-3645c0bce6d4 + Tue, 09 Jul 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined in a live recording from RailsConf by the one and only Aaron Patterson. They discuss Aaron's many RailsConf keynotes, his recent work on Rails view rendering and his three-year-long effort to bring more advanced garbage collection to Ruby which will finally be seeing the light of day. And of course, plenty of puns. + 45:29 + no + + <p>On this week's episode, Chris is joined in a live recording from RailsConf by the one and only <a href="https://twitter.com/tenderlove?lang=en">Aaron Patterson</a>. They discuss Aaron's many RailsConf keynotes, his recent work on Rails view rendering and his three-year-long effort to bring more advanced garbage collection to Ruby which will finally be seeing the light of day. And of course, plenty of puns.</p> +<p>This episode of <em>The Bike Shed</em> is sponsored by <a href="http://www.indeedprime.com/thoughtbot">Indeed Prime</a></p> +<ul> +<li><a href="https://www.youtube.com/watch?v=8Dld5kFWGCc">Aaron’s Closing Keynote - RailsConf 2019</a></li> +<li><a href="https://github.com/tenderlove">Aaron on GitHub</a></li> +<li><a href="https://twitter.com/tenderlove">Aaron on Twitter</a></li> +<li><a href="https://www.youtube.com/watch?v=VBwWbFpkltg">DHHs Keynote - RailsConf 2019</a></li> +<li><a href="https://nokogiri.org/">Nokogiri</a></li> +<li><a href="http://xmlsoft.org/">libxml2</a></li> +<li><a href="https://www.youtube.com/watch?v=_kNO-LaGfhA">George Brocklehurst - Intro to Machine Learning (with fizzbuzz)</a></li> +<li><a href="https://en.wikipedia.org/wiki/Ruby_MRI">MRI</a></li> +<li><a href="https://en.wikipedia.org/wiki/Java_virtual_machine">JVM</a></li> +<li><a href="http://gchandbook.org/">The GC Handbook</a></li> +<li><a href="https://tenderlovemaking.com/2018/01/23/reducing-memory-usage-in-ruby.html">Compacting Garbage Collector in Ruby</a></li> +<li><a href="https://en.wikipedia.org/wiki/Peter_principle">Peter Principle</a></li> +<li><a href="https://subversion.apache.org/">Subversion</a></li> +<li><a href="https://en.wikipedia.org/wiki/Concurrent_Versions_System">CVS</a></li> +<li><a href="https://github.com/puma/puma">Puma Web Server</a></li> +<li><a href="https://perl6.org/">Perl 6</a></li> +<li><a href="https://twitter.com/pragdave?lang=en">Dave Thomas</a></li> +</ul> + + + + On this week's episode, Chris is joined in a live recording from RailsConf by the one and only Aaron Patterson. They discuss Aaron's many RailsConf keynotes, his recent work on Rails view rendering and his three-year-long effort to bring more advanced garbage collection to Ruby which will finally be seeing the light of day. And of course, plenty of puns.

+ +

This episode of The Bike Shed is sponsored by Indeed Prime

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined in a live recording from RailsConf by the one and only Aaron Patterson. They discuss Aaron's many RailsConf keynotes, his recent work on Rails view rendering and his three-year-long effort to bring more advanced garbage collection to Ruby which will finally be seeing the light of day. And of course, plenty of puns.

+ +

This episode of The Bike Shed is sponsored by Indeed Prime

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-YhuP4sA + + ]]> + + + + 204: I Don't Like Rest + https://bikeshed.thoughtbot.com/204 + 419f4b4a-523f-4b27-ba96-4555834035b2 + Tue, 02 Jul 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + In this week's episode, Steph and Chris discuss ways to unplug and protect personal downtime, RESTful sorting, altering production data within a Rails migration vs a rake task, adopting Unicode characters, and respond to a listener's question about how they approach client relationships and share thoughtbot's Agile-like process. + 45:52 + no + + <p>In this week's episode, Steph and Chris discuss ways to unplug and protect personal downtime, RESTful sorting, altering production data within a Rails migration vs a rake task, adopting Unicode characters, and respond to a listener's question about how they approach client relationships and share thoughtbot's Agile-like process.</p> +<ul> +<li><a href="https://slack.com/">Slack</a></li> +<li><a href="https://github.com/features/code-review/">GitHub - Pull Request Review</a></li> +<li><a href="https://reactjs.org/">React</a></li> +<li><a href="https://angular.io/">Angular</a></li> +<li><a href="https://www.postgresql.org/">Postgres</a></li> +<li><a href="https://www.mysql.com/">MySQL</a></li> +<li><a href="https://en.wikipedia.org/wiki/Representational_state_transfer">REST</a></li> +<li><a href="https://en.wikipedia.org/wiki/Remote_procedure_call">RPC</a></li> +<li><a href="https://graphql.org/">GraphQL</a></li> +<li><a href="https://www.graphile.org/postgraphile/">PostGraphile</a></li> +<li><a href="https://www.ruby-lang.org/en/">Ruby</a></li> +<li><a href="https://www.graphile.org/postgraphile/">PostGraphile</a></li> +<li><a href="https://en.wikipedia.org/wiki/Pair_programming">Pair programming</a></li> +<li><a href="https://agilemanifesto.org">Agile Manifesto</a></li> +<li><a href="https://amzn.to/2NhDXGQ"><em>Extreme Programming</em></a>- Kent Beck</li> +<li><a href="https://unicode.org/consortium/adopt-a-character.html">Unicode Consortium - Adopt a Character</a></li> +<li><a href="https://thoughtbot.com/blog/the-real-story-behind-story-points">The Real Story Behind Story Points</a></li> +<li><a href="https://guides.rubyonrails.org/active_record_migrations.html">Active Record Migrations</a></li> +<li><a href="https://guides.rubyonrails.org/command_line.html#custom-rake-tasks">Rails Custom Rake Task</a></li> +<li><a href="https://soundcloud.com/pepperjuice/tracks">Pepperjuice</a></li> +</ul> + + + + In this week's episode, Steph and Chris discuss ways to unplug and protect personal downtime, RESTful sorting, altering production data within a Rails migration vs a rake task, adopting Unicode characters, and respond to a listener's question about how they approach client relationships and share thoughtbot's Agile-like process.

+ +

Support The Bike Shed

]]> + + + In this week's episode, Steph and Chris discuss ways to unplug and protect personal downtime, RESTful sorting, altering production data within a Rails migration vs a rake task, adopting Unicode characters, and respond to a listener's question about how they approach client relationships and share thoughtbot's Agile-like process.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+6sji2o6c + + ]]> + + + + 203: A Blessed Monkeypatch (Eileen M. Uchitelle) + https://bikeshed.thoughtbot.com/203 + ee22b37c-b039-4ad5-b318-418a011ea730 + Tue, 25 Jun 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, we revisit RailsConf 2019 for another live recording, this time with Eileen M. Uchitelle, GitHubber and rails core team member. Eileen joins Chris to discuss her RailsConf talk on how GitHub maintained a custom fork of Rails for years, how they finally moved off it, and what lessons we can take away from their experience. They also discussed Eileen's recent work on automatic database switching coming in Rails 6, microservices and monoliths, and getting into working on Rails. + 40:46 + no + + <p>On this week's episode, we revisit RailsConf 2019 for another live recording, this time with <a href="https://twitter.com/eileencodes">Eileen M. Uchitelle</a>, GitHubber and rails core team member. Eileen joins Chris to discuss her RailsConf talk on how GitHub maintained a custom fork of Rails for years, how they finally moved off it, and what lessons we can take away from their experience. They also discussed Eileen's recent work on automatic database switching coming in Rails 6, microservices and monoliths, and getting into working on Rails.</p> +<p>This episode of <em>The Bike Shed</em> is sponsored by <a href="http://www.indeedprime.com/thoughtbot">Indeed Prime</a></p> +<ul> +<li><a href="https://twitter.com/eileencodes">Eileen M. Uchitelle - eileencodes</a></li> +<li><a href="https://www.youtube.com/watch?v=vIScxVu00bs">Eileen's talk - The Past, Present, and Future of Rails at GitHub</a></li> +<li><a href="https://github.com/rails/rails/pull/35073">Rails 6 connection switching for databases</a></li> +<li><a href="https://martinfowler.com/bliki/CircuitBreaker.html">Circuit break pattern</a></li> +<li><a href="https://edgeguides.rubyonrails.org/active_job_basics.html">ActiveJob</a></li> +<li><a href="https://github.com/resque/resque">Resque</a></li> +<li><a href="https://www.amazon.com/Success-Open-Source-Steven-Weber/dp/0674018583">The Success of Open Source</a></li> +<li><a href="https://api.rubyonrails.org/v5.2.3/classes/ActiveRecord/Enum.html">ActiveRecord Enums</a></li> +<li><a href="https://guides.rubyonrails.org/action_cable_overview.html">ActionCable</a></li> +<li><a href="https://aws.amazon.com/message/41926/">S3 Service Disruption Indident</a></li> +<li><a href="https://en.wikipedia.org/wiki/2016_Dyn_cyberattack">IOT DDOS on DNS</a></li> +<li><a href="https://twitter.com/tenderlove">Aaron Patterson</a></li> +</ul> + + + + On this week's episode, we revisit RailsConf 2019 for another live recording, this time with Eileen M. Uchitelle, GitHubber and rails core team member. Eileen joins Chris to discuss her RailsConf talk on how GitHub maintained a custom fork of Rails for years, how they finally moved off it, and what lessons we can take away from their experience. They also discussed Eileen's recent work on automatic database switching coming in Rails 6, microservices and monoliths, and getting into working on Rails.

+ +

This episode of The Bike Shed is sponsored by Indeed Prime

+ +

Support The Bike Shed

]]> + + + On this week's episode, we revisit RailsConf 2019 for another live recording, this time with Eileen M. Uchitelle, GitHubber and rails core team member. Eileen joins Chris to discuss her RailsConf talk on how GitHub maintained a custom fork of Rails for years, how they finally moved off it, and what lessons we can take away from their experience. They also discussed Eileen's recent work on automatic database switching coming in Rails 6, microservices and monoliths, and getting into working on Rails.

+ +

This episode of The Bike Shed is sponsored by Indeed Prime

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+_82RtviU + + ]]> + + + + 202: I Left it All on The Dance Floor + https://bikeshed.thoughtbot.com/202 + 86e14a2e-ad1e-444d-baab-3839dadbe696 + Tue, 18 Jun 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + In this week's episode, Chris and Steph discuss how working with typed-languages influences their work with dynamic languages. They also chat about the benefits of pair programming, tracking performance events using Rails' Instrumentation API and respond to a listener's question about how to structure code that doesn't fit neatly within the default Rails' structure. + 32:21 + no + + <p>In this week's episode, Chris and Steph discuss how working with typed-languages influences their work with dynamic languages. They also chat about the benefits of pair programming, tracking performance events using Rails' Instrumentation API and respond to a listener's question about how to structure code that doesn't fit neatly within the default Rails' structure.</p> +<ul> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://reactjs.org/">React</a></li> +<li><a href="https://www.typescriptlang.org/">TypeScript</a></li> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript">JavaScript</a></li> +<li><a href="https://youtu.be/IcgmSRJHu_8">&quot;Making Impossible States Impossible&quot; by Richard Feldman</a></li> +<li><a href="https://youtu.be/43eM4kNbb6c">&quot;Working with Maybe&quot; by Joël Quenneville</a></li> +<li><a href="https://en.wikipedia.org/wiki/Functional_programming">Functional programming</a></li> +<li><a href="https://en.wikipedia.org/wiki/Object-oriented_programming">Object-oriented programming</a></li> +<li><a href="https://www.ruby-lang.org/en/">Ruby</a></li> +<li><a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type">TypeScript 3 - Unknown Type</a></li> +<li><a href="https://en.wikipedia.org/wiki/Pair_programming">Pair programming</a></li> +<li><a href="https://api.rubyonrails.org/classes/ActiveSupport/Notifications.html">ActiveSupport::Notifications</a></li> +<li><a href="https://appsignal.com">AppSignal</a></li> +<li><a href="https://segment.com">Segment</a></li> +<li><a href="https://mixpanel.com/">MixPanel</a></li> +<li><a href="https://www.drip.com/">Drip</a></li> +<li><a href="https://www.kissmetricshq.com/">KissMetrics</a></li> +<li><a href="https://grafana.com/">Graphana</a></li> +<li><a href="https://rubyonrails.org/">Rails</a></li> +<li><a href="https://en.wikipedia.org/wiki/Application_programming_interface">API</a></li> +</ul> + + + + In this week's episode, Chris and Steph discuss how working with typed-languages influences their work with dynamic languages. They also chat about the benefits of pair programming, tracking performance events using Rails' Instrumentation API and respond to a listener's question about how to structure code that doesn't fit neatly within the default Rails' structure.

+ +

Support The Bike Shed

]]> + + + In this week's episode, Chris and Steph discuss how working with typed-languages influences their work with dynamic languages. They also chat about the benefits of pair programming, tracking performance events using Rails' Instrumentation API and respond to a listener's question about how to structure code that doesn't fit neatly within the default Rails' structure.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+vJ1a-5rL + + ]]> + + + + 201: Artisanally Indented Code (Kevin Deisz) + https://bikeshed.thoughtbot.com/201 + f8782989-eae1-4f44-860b-81e0d6eeb65b + Tue, 11 Jun 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by Kevin Deisz, CTO of CultureHQ, live from RailsConf. They discuss Kevin's RailsConf talk on preevalution in Ruby, but dig further into Kevin's core philosophies that drive his work on tools like preval. They round out the discussion with Kevin's work on prettier-plugin Ruby, an automated code formatter to finally tame the wild west of Ruby syntax, and the hopeful path to a v1.0 in the not too distant future. + 45:39 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/kddeisz">Kevin Deisz</a>, CTO of <a href="https://www.culturehq.com">CultureHQ</a>, live from RailsConf. They discuss Kevin's RailsConf talk on preevalution in Ruby, but dig further into Kevin's core philosophies that drive his work on tools like preval. They round out the discussion with Kevin's work on prettier-plugin Ruby, an automated code formatter to finally tame the wild west of Ruby syntax, and the hopeful path to a v1.0 in the not too distant future.</p> +<ul> +<li><a href="https://twitter.com/kddeisz">Kevin on Twitter</a></li> +<li><a href="https://www.youtube.com/watch?v=7GqhHmfjemY">Kevin's RailsConf 2019 talk - Pre-evaluation in Ruby</a></li> +<li><a href="https://github.com/kddeisz/preval">Preval - Kevin's pre-evaluation Ruby optimize</a></li> +<li><a href="https://vimeo.com/36579366">Bret Victor Inventing on Principle</a></li> +<li><a href="https://github.com/DamirSvrtan/fasterer">Fasterer static analysis in ruby</a></li> +<li><a href="https://github.com/rubocop-hq/rubocop">Rubocop</a></li> +<li><a href="https://docs.ruby-lang.org/en/2.4.0/Ripper.html">Ripper</a></li> +<li><a href="http://prototypejs.org/">Prototype.js</a></li> +<li><a href="https://docs.ruby-lang.org/en/2.4.0/syntax/refinements_rdoc.html">Ruby Refinements</a></li> +<li><a href="https://github.com/avh4/elm-format">Elm format</a></li> +<li><a href="https://www.python.org/dev/peps/pep-0008/">PEP 8</a></li> +<li><a href="https://prettier.io/">Prettier</a></li> +<li><a href="https://github.com/prettier/plugin-ruby">Prettier-plugin ruby</a></li> +<li><a href="https://code.visualstudio.com/">Visual Studio Code</a></li> +<li><a href="https://github.com/facebook/codemod">Codemods</a></li> +<li><a href="https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags">Don’t parse HTML with regex</a></li> +<li><a href="https://prepack.io/">Prepack</a></li> +<li><a href="https://www.python.org/dev/peps/pep-0020/">The Zen of Python</a></li> +<li><a href="https://www.youtube.com/watch?v=VBwWbFpkltg">RailsConf 2019 - Opening Keynote by David Heinemeier Hansson</a></li> +<li><a href="https://github.com/samphippen/rubyfmt">rubyfmt</a></li> +<li><a href="https://github.com/ruby-formatter/rufo">rufo</a></li> +</ul> + + + + On this week's episode, Chris is joined by Kevin Deisz, CTO of CultureHQ, live from RailsConf. They discuss Kevin's RailsConf talk on preevalution in Ruby, but dig further into Kevin's core philosophies that drive his work on tools like preval. They round out the discussion with Kevin's work on prettier-plugin Ruby, an automated code formatter to finally tame the wild west of Ruby syntax, and the hopeful path to a v1.0 in the not too distant future.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Kevin Deisz, CTO of CultureHQ, live from RailsConf. They discuss Kevin's RailsConf talk on preevalution in Ruby, but dig further into Kevin's core philosophies that drive his work on tools like preval. They round out the discussion with Kevin's work on prettier-plugin Ruby, an automated code formatter to finally tame the wild west of Ruby syntax, and the hopeful path to a v1.0 in the not too distant future.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+QWMmc9tW + + ]]> + + + + 200: FOMO for Hallway Track (200th Episode!) + https://bikeshed.thoughtbot.com/200 + 3e58b8e6-718c-4d51-94fb-3e9f86d772c7 + Wed, 29 May 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this very special Bike Shed, Steph and Chris celebrate reaching the 200th episode. They discuss the origins of the show and thank some of the wonderful folks who helped make it happen (thanks Derek, Sean, Amanda, Laila, and of course Thom!). They discuss Chris's recent trip to RailsConf and some strategies for making the most of conference attendance. Also, Steph's recent work hosting an intro to web development course. They wrap things up with a series of questions captured live from RailsConf at the community meetup covering career growth, naming, graphql, joy, and more. + 53:51 + no + + <p>On this very special Bike Shed, Steph and Chris celebrate reaching the 200th episode. They discuss the origins of the show and thank some of the wonderful folks who helped make it happen (thanks Derek, Sean, Amanda, Laila, and of course Thom!). They discuss Chris's recent trip to RailsConf and some strategies for making the most of conference attendance. Also, Steph's recent work hosting an intro to web development course. They wrap things up with a series of questions captured live from RailsConf at the community meetup covering career growth, naming, graphql, joy, and more.</p> +<ul> +<li><a href="http://bikeshed.fm/1">Sandi &amp; Derek's Rules</a> - The Bike Shed's first episode, from Oct 31 2014.</li> +<li><a href="https://twitter.com/thoughtbot/status/1129415008679530497">New Podcast Hosts!</a></li> +<li><a href="https://twitter.com/derekprior">Derek Prior</a></li> +<li><a href="https://twitter.com/sgrif">Sean Griffin</a></li> +<li><a href="https://twitter.com/malandr1na">Laila Winner</a></li> +<li><a href="https://twitter.com/mandybess">Amanda Adams (Amanda Hill at the time)</a></li> +<li><a href="https://www.intercom.com/">Intercom</a></li> +<li><a href="https://www.ericholscher.com/blog/2017/aug/2/pacman-rule-conferences/">Pacman rule - Eric Holscher</a></li> +<li><a href="https://www.girldevelopit.com/">Girl Develop It</a></li> +<li><a href="https://www.womenwhocode.com/">Women Who Code</a></li> +<li><a href="https://github.com/alex/what-happens-when">&quot;What happens when you type google.com into your browser's address box and press enter?&quot;</a></li> +<li><a href="https://atom.io/">Atom</a></li> +<li><a href="https://neocities.org/">Neocities</a></li> +<li><a href="https://www.netlify.com/">Netlify</a></li> +<li><a href="https://www.heroku.com/">Heroku</a></li> +<li><a href="https://walkerart.org/visit/garden">Minneapolis Sculpture Garden</a></li> +<li><a href="https://dependabot.com/">Dependabot</a></li> +<li><a href="https://www.youtube.com/watch?v=KRUQHdXngO8">Semisonic - Sculpture Garden</a></li> +</ul> + + + + On this very special Bike Shed, Steph and Chris celebrate reaching the 200th episode. They discuss the origins of the show and thank some of the wonderful folks who helped make it happen (thanks Derek, Sean, Amanda, Laila, and of course Thom!). They discuss Chris's recent trip to RailsConf and some strategies for making the most of conference attendance. Also, Steph's recent work hosting an intro to web development course. They wrap things up with a series of questions captured live from RailsConf at the community meetup covering career growth, naming, graphql, joy, and more.

+ +

Support The Bike Shed

]]> + + + On this very special Bike Shed, Steph and Chris celebrate reaching the 200th episode. They discuss the origins of the show and thank some of the wonderful folks who helped make it happen (thanks Derek, Sean, Amanda, Laila, and of course Thom!). They discuss Chris's recent trip to RailsConf and some strategies for making the most of conference attendance. Also, Steph's recent work hosting an intro to web development course. They wrap things up with a series of questions captured live from RailsConf at the community meetup covering career growth, naming, graphql, joy, and more.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+IRNsFPKj + + ]]> + + + + 199: Pave That Path + https://bikeshed.thoughtbot.com/199 + 7ef174ec-6ef8-4400-8cea-02186726a5fc + Tue, 21 May 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Steph and Chris talk about PR sizing, load testing (the weird way), and ponder the merits and pitfalls of personal style in code. They also discuss Hertz suing Accenture for undelivered software and the belief that engineers should talk to users! This one truly has something for everyone. + 45:16 + no + + <p>On this week's episode, Steph and Chris talk about PR sizing, load testing (the weird way), and ponder the merits and pitfalls of personal style in code. They also discuss Hertz suing Accenture for undelivered software and the belief that engineers should talk to users! This one truly has something for everyone.</p> +<ul> +<li><a href="https://prettier.io/">prettier</a></li> +<li><a href="https://github.com/avh4/elm-format">elm-format</a></li> +<li><a href="https://martinfowler.com/eaaCatalog/queryObject.html">Query objects</a></li> +<li><a href="https://github.com/prettier/plugin-ruby">Prettier plugin-ruby</a></li> +<li><a href="https://thoughtbot.com/blog/stop-coding-and-start-drawing">Stop Coding and Start Drawing - Joël's post on drawing</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events">Server sent events</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API">WebSockets</a></li> +<li><a href="https://daniel.haxx.se/blog/2015/11/23/copy-as-curl/">Copy as cURL</a></li> +<li><a href="https://cloud.google.com/appengine/">Google App Engine</a></li> +<li><a href="https://www.hirefire.io/">HireFire</a></li> +<li><a href="https://twitter.com/allafarce/status/1121174850226147328">Hertz &amp; Accenture tweet summary</a></li> +</ul> + + + + On this week's episode, Steph and Chris talk about PR sizing, load testing (the weird way), and ponder the merits and pitfalls of personal style in code. They also discuss Hertz suing Accenture for undelivered software and the belief that engineers should talk to users! This one truly has something for everyone.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Steph and Chris talk about PR sizing, load testing (the weird way), and ponder the merits and pitfalls of personal style in code. They also discuss Hertz suing Accenture for undelivered software and the belief that engineers should talk to users! This one truly has something for everyone.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+JJtPwSyR + + ]]> + + + + 198: In Terms of Tradeoffs (Glenn Vanderburg) + https://bikeshed.thoughtbot.com/198 + 4d34a6cf-edd3-4188-8915-446395d1728f + Tue, 14 May 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by Glenn Vanderburg, VP of Engineering at First.io, live from RailsConf. They discuss Glenn's RailsConf talk, "The 30-Month Migration", covering distributed data models, refactoring, and the wonders of postgres. They also discuss Glenn's famous talk, "Real Software Engineering", and what the term "software engineering" means within our communities. + 41:22 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/glv">Glenn Vanderburg</a>, VP of Engineering at <a href="https://www.first.io/">First.io</a>, live from RailsConf. They discuss Glenn's RailsConf talk, &quot;The 30-Month Migration&quot;, covering distributed data models, refactoring, and the wonders of postgres. They also discuss Glenn's famous talk, &quot;Real Software Engineering&quot;, and what the term &quot;software engineering&quot; means within our communities.</p> +<ul> +<li><a href="https://twitter.com/glv">Glenn on Twitter</a></li> +<li><a href="https://www.youtube.com/watch?v=Nz-aU3vOFbw">Glenn's RailsConf talk - The 30-Month Migration</a></li> +<li><a href="https://vanderburg.org/">Glenn's blog</a></li> +<li><a href="https://www.first.io/">First.io</a></li> +<li><a href="https://www.postgresql.org/">Postgres</a></li> +<li><a href="https://www.mysql.com/">MySQL</a></li> +<li><a href="https://www.postgresql.org/docs/9.1/queries-with.html">Postgres Common Table Expressions (CTEs)</a></li> +<li><a href="https://www.youtube.com/watch?v=a-3sm1rUbPg">Swanand Pagnis - It's 2017, and I <em>still</em> want to sell you a graph database!</a></li> +<li><a href="https://graphql.org/">GraphQL</a></li> +<li><a href="https://www.youtube.com/watch?v=RhdlBHHimeM">Glenn Vanderburg - Real Software Engineering</a></li> +<li><a href="https://agilemanifesto.org/">Agile Manifesto</a></li> +<li><a href="https://en.wikipedia.org/wiki/Extreme_programming">Extreme Programming</a></li> +<li><a href="https://www.rust-lang.org/">Rust Language</a></li> +<li><a href="https://www.cs.tufts.edu/%7Ekfisher/Kathleen_Fisher/Home.html">Kathleen Fisher</a></li> +<li><a href="https://www.youtube.com/watch?v=3D6jxBDy8k8">Kathleen Fisher, High Assurance Systems</a></li> +<li><a href="https://aws.amazon.com/about-aws/whats-new/2018/11/firecracker-lightweight-virtualization-for-serverless-computing/">AWS Firecracker</a></li> +<li><a href="http://bikeshed.fm/195">Bike Shed with Lin Clark &amp; Till Schneidereit on WebAssembly &amp; WASI</a></li> +<li><a href="https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime">Fastly Lucet</a></li> +<li><a href="https://principlesofchaos.org/">Chaos Engineering</a></li> +<li><a href="https://netflix.github.io/chaosmonkey/">Chaos Monkey</a></li> +<li><a href="https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer)">Joe Armstrong</a></li> +<li><a href="https://www.erlang.org/">Erlang</a></li> +<li><a href="https://hypothesis.works/articles/what-is-property-based-testing/">Property Based Testing</a></li> +<li><a href="https://en.wikipedia.org/wiki/Actor_model">Erlang Actor Model</a></li> +<li><a href="https://clojure.org/">Clojure</a></li> +<li><a href="https://clojurescript.org/">ClojureScript</a></li> +<li><a href="https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell">Functional Core, Imperative Shell</a></li> +<li><a href="https://sorbet.org/">Sorbet - Stripe library for gradual static typing in Ruby</a></li> +</ul> + + + + On this week's episode, Chris is joined by Glenn Vanderburg, VP of Engineering at First.io, live from RailsConf. They discuss Glenn's RailsConf talk, "The 30-Month Migration", covering distributed data models, refactoring, and the wonders of postgres. They also discuss Glenn's famous talk, "Real Software Engineering", and what the term "software engineering" means within our communities.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Glenn Vanderburg, VP of Engineering at First.io, live from RailsConf. They discuss Glenn's RailsConf talk, "The 30-Month Migration", covering distributed data models, refactoring, and the wonders of postgres. They also discuss Glenn's famous talk, "Real Software Engineering", and what the term "software engineering" means within our communities.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+PktvZty9 + + ]]> + + + + 197: Don't Go Chasing Waterfalls + https://bikeshed.thoughtbot.com/197 + 26ef0732-df1a-4ea3-91ab-3f3c28b73d33 + Tue, 07 May 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Steph and Chris discuss Redux, integration testing strategies, scoping data for React components, and take a question from a listener about improving process and reducing bugs in a complex service-oriented system with a hint of waterfall in their workflow. + 44:27 + no + + <p>Steph and Chris discuss Redux, integration testing strategies, scoping data for React components, and take a question from a listener about improving process and reducing bugs in a complex service-oriented system with a hint of waterfall in their workflow.</p> +<ul> +<li><a href="https://angular.io/">Angular</a></li> +<li><a href="https://www.apollographql.com/">Apollo</a></li> +<li><a href="http://teamcapybara.github.io/capybara/">Capybara</a></li> +<li><a href="https://circleci.com/">CircleCI</a></li> +<li><a href="https://circleci.com/orbs/">CircleCI Orbs</a></li> +<li><a href="https://cypress.io">Cypress</a></li> +<li><a href="https://www.docker.com/">Docker</a></li> +<li><a href="https://airbnb.io/enzyme/">Enzyme</a></li> +<li><a href="https://graphql.org/">GraphQL</a></li> +<li><a href="https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol">HTTP</a></li> +<li><a href="https://devcenter.heroku.com/articles/buildpacks">Heroku Buildpack</a></li> +<li><a href="https://thoughtbot.com/blog/mystery-guest">Mystery Guests</a></li> +<li><a href="http://www.nightmarejs.org/">Nightmare.js</a></li> +<li><a href="https://github.com/paularmstrong/normalizr">Normalizer</a></li> +<li><a href="https://rspec.info/">RSpec</a></li> +<li><a href="https://reactjs.org/">React</a></li> +<li><a href="https://redux.js.org/">Redux</a></li> +<li><a href="https://github.com/reduxjs/reselect">Reselect</a></li> +<li><a href="https://thoughtbot.com/blog/services-are-not-a-silver-bullet">SOA - Service Oriented Architecture</a></li> +<li><a href="https://www.seleniumhq.org/">Selenium</a></li> +<li><a href="https://github.com/swagger-api">Swagger</a></li> +<li><a href="https://thoughtbot.com/blog/the-real-story-behind-story-points">The Real Story Behind Story Points</a></li> +<li><a href="https://github.com/reduxjs/redux-thunk">Thunk</a></li> +<li><a href="https://json-schema.org/">json schema</a></li> +<li><a href="https://github.com/ezcater/lunar-core">lunar</a></li> +<li><a href="https://www.npmjs.com/">npm</a></li> +<li><a href="https://github.com/testing-library/react-testing-library">react-testing-library</a></li> +</ul> + + + + Steph and Chris discuss Redux, integration testing strategies, scoping data for React components, and take a question from a listener about improving process and reducing bugs in a complex service-oriented system with a hint of waterfall in their workflow.

+ +

Support The Bike Shed

]]> + + + Steph and Chris discuss Redux, integration testing strategies, scoping data for React components, and take a question from a listener about improving process and reducing bugs in a complex service-oriented system with a hint of waterfall in their workflow.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+63v1WBon + + ]]> + + + + 196: I Can Be Wrong on the Internet + https://bikeshed.thoughtbot.com/196 + c11752a7-194f-43be-91ff-d5f1ef643521 + Tue, 30 Apr 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris welcomes Steph as the new co-host of The Bike Shed! Chris and Steph discuss their experiences using React, TypeScript, and Angular. + 38:28 + no + + <p>On this week's episode, Chris welcomes Steph as the new co-host of The Bike Shed! Chris and Steph discuss their experiences using React, TypeScript, and Angular.</p> +<ul> +<li><a href="https://angular.io/">Angular</a></li> +<li><a href="https://backbonejs.org/">Backbone</a></li> +<li><a href="https://en.wikipedia.org/wiki/Behavior-driven_development">BDD</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://emberjs.com/">Ember</a></li> +<li><a href="https://es6.io/">ES6</a></li> +<li><a href="https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol">HTTP</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript">Javascript</a></li> +<li><a href="https://www.python.org/">Python</a></li> +<li><a href="https://rubyonrails.org/">Rails</a></li> +<li><a href="https://reactjs.org/">React</a></li> +<li><a href="https://rxjs-dev.firebaseapp.com/">RSJX</a></li> +<li><a href="https://martinfowler.com/bliki/TestDrivenDevelopment.html">TDD</a></li> +<li><a href="https://www.typescriptlang.org/">Typescript</a></li> +<li><a href="https://vuejs.org/">Vue</a></li> +</ul> + + + + On this week's episode, Chris welcomes Steph as the new co-host of The Bike Shed! Chris and Steph discuss their experiences using React, TypeScript, and Angular.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris welcomes Steph as the new co-host of The Bike Shed! Chris and Steph discuss their experiences using React, TypeScript, and Angular.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ERIVkiBX + + ]]> + + + + 195: WebAssembly & WASI (Lin Clark & Till Schneidereit) + https://bikeshed.thoughtbot.com/195 + 73b1d179-525d-4e31-b76e-d00542abe676 + Fri, 19 Apr 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by Lin Clark and Till Schneidereit of Mozilla to discuss all things WebAssembly. Lin and Till are helping to lead the development and advocacy around WebAssembly and in this conversation they discuss the current state of WASM, new developments like the WebAssembly System Interface (WASI), and the longer term possibilities and goals for WASM. + 37:01 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/linclark">Lin Clark</a> and <a href="https://twitter.com/tschneidereit">Till Schneidereit</a> of Mozilla to discuss all things WebAssembly. Lin and Till are helping to lead the development and advocacy around WebAssembly and in this conversation they discuss the current state of WASM, new developments like the WebAssembly System Interface (WASI), and the longer term possibilities and goals for WASM.</p> +<ul> +<li><a href="https://twitter.com/linclark">Lin Clark</a></li> +<li><a href="https://twitter.com/tschneidereit">Till Schneidereit</a></li> +<li><a href="https://twitter.com/codecartoons">Code Cartoons</a></li> +<li><a href="https://webassembly.org/">WebAssembly</a></li> +<li><a href="https://www.rust-lang.org/">Rust</a></li> +<li><a href="https://github.com/tc39">TC39 JavaScript committee</a></li> +<li><a href="https://www.w3.org/">W3C</a></li> +<li><a href="https://github.com/WebAssembly/webidl-bindings/blob/master/proposals/webidl-bindings/Explainer.md">WebAssembly WebIDL</a></li> +<li><a href="https://rustwasm.github.io/docs/wasm-pack/">Rust wasm toolchain</a></li> +<li><a href="https://babeljs.io/">Babel</a></li> +<li><a href="https://emscripten.org/">Emscripten</a></li> +<li><a href="http://asmjs.org/">Asm.js</a></li> +<li><a href="https://www.figma.com/">Figma</a></li> +<li><a href="https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/">WASI Web Assembly System Interface</a></li> +<li><a href="https://github.com/CraneStation/wasmtime">wasmtime</a></li> +<li><a href="https://www.fastly.com/">Fastly CDN</a></li> +<li><a href="https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime">Lucet - Fastly's WASM Runtime</a></li> +<li><a href="https://twitter.com/solomonstre/status/1111004913222324225">Solomon Hykes tweet re: Docker &amp; WASM+WASI</a></li> +<li><a href="https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript">The Birth &amp; Death of JavaScript</a></li> +<li><a href="https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/">Lin’s post on Post MVP future for WASM</a></li> +<li><a href="https://hacks.mozilla.org/">Mozilla hacks blog</a></li> +<li><a href="https://www.youtube.com/watch?v=snmSH3ALQ4E">WebAssembly's Post MVP Future talk by Lin Clark and Till Schneidereit</a></li> +</ul> + + + + On this week's episode, Chris is joined by Lin Clark and Till Schneidereit of Mozilla to discuss all things WebAssembly. Lin and Till are helping to lead the development and advocacy around WebAssembly and in this conversation they discuss the current state of WASM, new developments like the WebAssembly System Interface (WASI), and the longer term possibilities and goals for WASM.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Lin Clark and Till Schneidereit of Mozilla to discuss all things WebAssembly. Lin and Till are helping to lead the development and advocacy around WebAssembly and in this conversation they discuss the current state of WASM, new developments like the WebAssembly System Interface (WASI), and the longer term possibilities and goals for WASM.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+G1iLjcwS + + ]]> + + + + 194: My PGP Shame + https://bikeshed.thoughtbot.com/194 + 4626e4cb-7f73-4e65-b8a0-b89bca2c2994 + Fri, 12 Apr 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Mike Burns discusses the ins and outs of application security, his comprehensive Application Security Guide, common security holes, and his personal information & security management workflow. + 47:13 + no + + <p>On this week's episode, Chris is joined by Mike Burns, developer in our New York studio, to discuss the ins and outs of application security. Mike recently added a comprehensive <a href="https://github.com/thoughtbot/guides/blob/master/security/application.md">Application Security Guide</a> to the <a href="https://github.com/thoughtbot/guides">thoughtbot guides</a>, and in this chat they discuss some of the high points of the guide, some of the low points of common security holes, and some of the fantastically specific workflows and approaches Mike has for his personal information and security management.</p> +<ul> +<li><a href="https://mastodon.technology/@mikeburns">Mike Burns on Mastodon</a></li> +<li><a href="https://thoughtbot.com/blog/authors/mike-burns">Mike Burns on the thoughtbot blog</a></li> +<li><a href="https://github.com/thoughtbot/guides/blob/master/security/application.md">Application Security Guide</a></li> +<li><a href="https://yaml.org/">YAML</a></li> +<li><a href="https://www.json.org/">JSON</a></li> +<li><a href="https://github.com/toml-lang/toml">TOML</a></li> +<li><a href="https://en.wikipedia.org/wiki/Bcrypt">Bcrypt</a></li> +<li><a href="https://en.wikipedia.org/wiki/Scrypt">Scrypt</a></li> +<li><a href="https://www.youtube.com/watch?v=YEBfamv-_do&amp;t=402s">TLS Handshake explained with paint colors</a></li> +<li><a href="https://pages.nist.gov/800-63-3/sp800-63b.html">NIST - Digital Identity Guidelines</a></li> +<li><a href="https://github.com/thoughtbot/clearance">Clearance</a></li> +<li><a href="https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail">DKIM</a> &amp; <a href="https://en.wikipedia.org/wiki/Sender_Policy_Framework">SPF</a> for email verification</li> +<li><a href="https://thoughtbot.com/blog/pgp-and-you">PGP Signing of Emails</a></li> +<li><a href="https://help.github.com/en/articles/signing-commits">PGP Signing git Commits</a></li> +<li><a href="https://www.wired.com/story/facebook-passwords-plaintext-change-yours/">Facebook Stored Millions Of Passwords In Plaintext</a></li> +<li><a href="https://cofense.com/">PhishMe (now Cofense)</a></li> +<li><a href="http://www.mutt.org/">Mutt email client</a></li> +<li><a href="https://www.yubico.com/">YubiKey</a></li> +<li><a href="https://www.passwordstore.org/">Pass</a></li> +<li><a href="https://linux.die.net/man/1/pwgen">pwgen</a></li> +<li><a href="https://www.lastpass.com/">LastPass</a></li> +<li><a href="https://en.wikipedia.org/wiki/Forward_secrecy">Perfect Forward Secrecy</a></li> +<li><a href="https://www.tarsnap.com/">Tarsnap</a></li> +</ul> + + + + On this week's episode, Chris is joined by Mike Burns, developer in our New York studio, to discuss the ins and outs of application security. Mike recently added a comprehensive Application Security Guide to the thoughtbot guides, and in this chat they discuss some of the high points of the guide, some of the low points of common security holes, and some of the fantastically specific workflows and approaches Mike has for his personal information and security management.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Mike Burns, developer in our New York studio, to discuss the ins and outs of application security. Mike recently added a comprehensive Application Security Guide to the thoughtbot guides, and in this chat they discuss some of the high points of the guide, some of the low points of common security holes, and some of the fantastically specific workflows and approaches Mike has for his personal information and security management.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+dTuOcs2U + + ]]> + + + + 193: A Thing I Know Almost Nothing About + https://bikeshed.thoughtbot.com/193 + f2d3ece6-da34-4c06-87c6-9f7aaa4f218d + Fri, 05 Apr 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Edward Loveall, former thoughtbot design apprentice and now thoughtbot developer, chats about his thoughtbot origin story, podcasts, DNS, and "must have" developer tools on new machines. + 47:41 + no + + <p>On this week's episode, Chris is joined by <a href="https://edwardloveall.com/">Edward Loveall</a>, former thoughtbot design apprentice and now thoughtbot developer. After a quick chat about Edward's thoughtbot origin story, podcasts, and DNS, they dig into the heart of the conversation talking about their respective &quot;must have&quot; developer tools on new machines.</p> +<ul> +<li><a href="https://edwardloveall.com/">edwardloveall.com</a></li> +<li><a href="https://thoughtbot.com/playbook/our-company/apprenticeship">thoughtbot apprenticeship</a></li> +<li><a href="https://gumroad.com/l/domain-name-sanity">Domain Name Sanity</a></li> +<li><a href="https://www.heroku.com/">Heroku</a></li> +<li><a href="https://dnsimple.com/">DNSimple</a></li> +<li><a href="https://aws.amazon.com/route53/">Amazon Route53</a></li> +<li><a href="http://giantrobots.fm/">Giant Robots podcast</a></li> +<li><a href="http://giantrobots.fm/8">Edward's episode on Giant Robots talking about the apprenticeship</a></li> +<li><a href="https://twitter.com/david_perell/status/1073290274766499841">Tweet about using a podcast as internal onboarding</a></li> +<li><a href="https://www.hammerspoon.org/">Hammerspoon</a></li> +<li><a href="https://github.com/jigish/slate">Slate</a></li> +<li><a href="https://www.spectacleapp.com/">Spectacle</a></li> +<li><a href="https://getdivvy.com/">Divvy</a></li> +<li><a href="https://www.vim.org/">Vim</a></li> +<li><a href="https://github.com/tmux/tmux">Tmux</a></li> +<li><a href="https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare">VSCode Live share</a></li> +<li><a href="https://tmate.io/">tmate</a></li> +<li><a href="https://www.alfredapp.com/">Alfred</a></li> +<li><a href="https://www.alfredapp.com/help/features/clipboard/">Alfred clipboard</a></li> +<li><a href="https://en.wikipedia.org/wiki/AppleScript">AppleScript</a></li> +<li><a href="https://www.archlinux.org/">Arch Linux</a></li> +<li><a href="https://youtu.be/qXtXsUqhHiI">Jeff Goldblum iMac Commercials</a></li> +<li><a href="https://feedly.com/">Feedly</a></li> +<li><a href="https://feedbin.com/">Feedbin</a></li> +<li><a href="https://readkitapp.com/">ReadKit</a></li> +<li><a href="https://jsonfeed.org/">JSON Feed</a></li> +<li><a href="https://jameshfisher.com/2019/03/08/why-cant-i-set-the-font-size-of-a-visited-link/">CSS &amp; Privacy - Why can’t I set the font size of a visited link?</a></li> +<li><a href="https://lobste.rs/">Lobsters</a></li> +</ul> +<p>Thank you to <a href="http://circleci.com/bikeshed">CircleCI</a> for sponsoring this episode.</p> + + + + On this week's episode, Chris is joined by Edward Loveall, former thoughtbot design apprentice and now thoughtbot developer. After a quick chat about Edward's thoughtbot origin story, podcasts, and DNS, they dig into the heart of the conversation talking about their respective "must have" developer tools on new machines.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Edward Loveall, former thoughtbot design apprentice and now thoughtbot developer. After a quick chat about Edward's thoughtbot origin story, podcasts, and DNS, they dig into the heart of the conversation talking about their respective "must have" developer tools on new machines.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+sKEfBeQO + + ]]> + + + + 192: I Don't Want to Think That Hard + https://bikeshed.thoughtbot.com/192 + 978dbebc-56a6-4a22-a0b1-5649a7ee2cd3 + Fri, 29 Mar 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sid Raval chats about functional programming, strong types, and accessibility. The discussion touches on TypeScript, Haskell, Scala, Elm, as well as accessibility and developer tools. + +Thank you to CircleCI for sponsoring this episode. + 34:05 + no + + <p>On this week's episode, Chris is joined by <a href="https://github.com/sidraval">Sid Raval</a>, developer in our New York studio. Chris and Sid chat about functional programming, strong types, and accessibility. Along the way they touch on TypeScript, Haskell, Scala, Elm, and plenty in between. They round out the conversation with a discussion around accessibility and developer tools.</p> +<ul> +<li><a href="https://www.ruby-lang.org/en/">Ruby</a></li> +<li><a href="https://www.haskell.org/">Haskell</a></li> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://github.com/ghcjs/ghcjs">GHCJS</a></li> +<li><a href="https://github.com/reflex-frp/reflex">Reflex (frp library for Hasekll)</a></li> +<li><a href="https://www.scala-js.org/">Scala.js</a></li> +<li><a href="https://www.typescriptlang.org/">TypeScript</a></li> +<li><a href="http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html">How Elm Slays a UI Antipattern</a></li> +<li><a href="https://package.elm-lang.org/packages/krisajenkins/remotedata/latest/">RemoteData library in Elm</a></li> +<li><a href="https://thoughtbot.com/blog/static-types-in-medias-res">Sid's blog post on gradually adding flow</a></li> +<li><a href="http://hackage.haskell.org/package/QuickCheck">QuickCheck library for haskell</a></li> +<li><a href="https://medium.com/byteconf/stripe-is-building-a-ruby-typechecker-d6cd7cee6abf">Sorbet - Ruby static type annotations</a></li> +<li><a href="https://thoughtbot.com/blog/grouping-elements-for-better-accessibility-on-ios">Sids' blog post - Grouping elements for better accessibility</a></li> +</ul> +<p>Thank you to <a href="http://circleci.com/bikeshed">CircleCI</a> for sponsoring this episode.</p> + + + + On this week's episode, Chris is joined by Sid Raval, developer in our New York studio. Chris and Sid chat about functional programming, strong types, and accessibility. Along the way they touch on TypeScript, Haskell, Scala, Elm, and plenty in between. They round out the conversation with a discussion around accessibility and developer tools.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Sid Raval, developer in our New York studio. Chris and Sid chat about functional programming, strong types, and accessibility. Along the way they touch on TypeScript, Haskell, Scala, Elm, and plenty in between. They round out the conversation with a discussion around accessibility and developer tools.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+N20zJ30G + + ]]> + + + + 191: Open Source is Created By Humans (Devon Zuegel) + https://bikeshed.thoughtbot.com/191 + 15ae1095-7310-4574-8f31-bcc546c47318 + Fri, 22 Mar 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris is joined by Devon Zuegel who recently joined GitHub in the new Open Source Product Manager role. Devon and Chris discuss the complexities inherent to open source including funding models, managing motivation and burnout, different open source models, and end with a discussion around how we can be better open source citizens, both as consumers and maintainers. + +Thank you to CircleCI for sponsoring this episode. + 39:32 + no + + <p>Chris is joined by <a href="https://twitter.com/devonzuegel">Devon Zuegel</a> who recently joined GitHub in the new Open Source Product Manager role. Devon and Chris discuss the complexities inherent to open source including funding models, managing motivation and burnout, different open source models, and end with a discussion around how we can be better open source citizens, both as consumers and maintainers.</p> +<ul> +<li><a href="https://twitter.com/devonzuegel">Devon on Twitter</a></li> +<li><a href="https://devonzuegel.com/">Devon's Blog</a></li> +<li><a href="https://www.fordfoundation.org/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf">Nadia Eghbal - Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure</a></li> +<li><a href="https://www.patreon.com/">Patreon</a></li> +<li><a href="https://www.patreon.com/sindresorhus">Sindre Sorhus on Patreon</a></li> +<li><a href="https://opencollective.com/">Open Collective</a></li> +<li><a href="https://opencollective.com/eslint">ESLint on Open Collective</a></li> +<li><a href="https://opencollective.com/webpack">Webpack on Open Collective</a></li> +<li><a href="https://opencollective.com/babel">Babel on Open Collective</a></li> +<li><a href="https://sidekiq.org/products/pro.html">Sidekiq Pro</a></li> +<li><a href="https://graphql.pro/">GraphQL Pro</a></li> +<li><a href="https://twitter.com/github/status/1059866337801957376">GitHub related issues</a></li> +<li><a href="https://clojure.org/">Clojure</a></li> +<li><a href="https://twitter.com/richhickey">Rich Hickey</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://twitter.com/czaplic">Evan Czaplicki</a></li> +<li><a href="https://www.reddit.com/r/ruby/comments/ado2wb/matz_replies_to_post_from_this_sub_about_ruby/">Matz replies to post around Ruby moving slowly</a></li> +<li><a href="https://github.com/maintainers">Open Source Maintainers Group on GitHub</a></li> +</ul> +<p>Thank you to <a href="http://circleci.com/bikeshed">CircleCI</a> for sponsoring this episode.</p> + + + + Chris is joined by Devon Zuegel who recently joined GitHub in the new Open Source Product Manager role. Devon and Chris discuss the complexities inherent to open source including funding models, managing motivation and burnout, different open source models, and end with a discussion around how we can be better open source citizens, both as consumers and maintainers.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + + Chris is joined by Devon Zuegel who recently joined GitHub in the new Open Source Product Manager role. Devon and Chris discuss the complexities inherent to open source including funding models, managing motivation and burnout, different open source models, and end with a discussion around how we can be better open source citizens, both as consumers and maintainers.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+DEL9-EQG + + ]]> + + + + 190: Going Steady With a Platform + https://bikeshed.thoughtbot.com/190 + d6aab70e-5c65-4415-a4c3-bf93e1c2b71e + Fri, 15 Mar 2019 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Alex Sullivan takes Chris on a tour of the mobile landscape comparing the core native platforms (the languages, developer tooling and IDEs, and fundamental thinking), React Native, and briefly touching on the newest entrant into the mobile space, Flutter. + +Thank you to CircleCI for sponsoring this episode. + 52:26 + no + + <p>On this week's episode, Chris is joined by <a href="https://github.com/alexsullivan114">Alex Sullivan</a>, mobile developer in our Boston office. Alex takes Chris on a tour of the mobile landscape comparing the core native platforms (Android and iOS), the languages, developer tooling and IDEs, and fundamental thinking. They also dip into a discussion around React Native highlighting some of its strengths, as well as areas where native still clearly wins. Finally they touch on Flutter, the newest entrant into the mobile space to round out the discussion.</p> +<ul> +<li><a href="https://runkeeper.com/">Runkeeper</a></li> +<li><a href="https://www.android.com/">Android</a></li> +<li><a href="https://developer.apple.com/ios/">iOS</a></li> +<li><a href="https://developer.android.com/topic/libraries/architecture/viewmodel">ViewModel</a></li> +<li><a href="https://developer.android.com/topic/libraries/architecture/room">Room</a></li> +<li><a href="https://www.java.com/">Java</a></li> +<li><a href="https://kotlinlang.org/">Kotlin</a></li> +<li><a href="https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html">Objective C</a></li> +<li><a href="https://swift.org/">Swift</a></li> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://www.jetbrains.com/">JetBrains</a></li> +<li><a href="https://en.wikipedia.org/wiki/Type_erasure">Type erasure</a></li> +<li><a href="https://kotlinlang.org/docs/reference/inline-functions.html">Reified types</a></li> +<li><a href="https://developer.android.com/studio">Android Studio</a></li> +<li><a href="https://developer.apple.com/xcode/">Xcode</a></li> +<li><a href="https://www.jetbrains.com/objc/">AppCode</a></li> +<li><a href="https://twitter.com/garybernhardt">Gary Bernhardt</a></li> +<li><a href="https://facebook.github.io/react-native/">React Native</a></li> +<li><a href="https://visualstudio.microsoft.com/xamarin/">Xamarin</a></li> +<li><a href="https://flutter.dev/">Flutter</a></li> +<li><a href="https://www.dartlang.org/">Dart</a></li> +<li><a href="https://thoughtbot.com/blog/examining-performance-differences-between-native-flutter-and-react-native-mobile-development">Alex's post comparing performance of native, Flutter, and React Native</a></li> +</ul> +<p>Thank you to <a href="http://circleci.com/bikeshed">CircleCI</a> for sponsoring this episode.</p> + + + + On this week's episode, Chris is joined by Alex Sullivan, mobile developer in our Boston office. Alex takes Chris on a tour of the mobile landscape comparing the core native platforms (Android and iOS), the languages, developer tooling and IDEs, and fundamental thinking. They also dip into a discussion around React Native highlighting some of its strengths, as well as areas where native still clearly wins. Finally they touch on Flutter, the newest entrant into the mobile space to round out the discussion.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Alex Sullivan, mobile developer in our Boston office. Alex takes Chris on a tour of the mobile landscape comparing the core native platforms (Android and iOS), the languages, developer tooling and IDEs, and fundamental thinking. They also dip into a discussion around React Native highlighting some of its strengths, as well as areas where native still clearly wins. Finally they touch on Flutter, the newest entrant into the mobile space to round out the discussion.

+ + + +

Thank you to CircleCI for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+CSg6zPPs + + ]]> + + + + 189: It's Gonna Work, Definitely, No Problems Whatsoever + https://bikeshed.thoughtbot.com/189 + 162ad7d1-3586-41a1-9c91-8c1a9958eb0e + Fri, 01 Mar 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Chris is joined by Steph Viccari to chat about Steph's recent experience working on the Hubspot API ruby wrapper, testing third-party APIs, VCR, using exceptions as control flow, and spooky mystery guests at a distance. A little something for everyone! + 41:38 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/sviccari">Steph Viccari</a> to chat about Steph's recent experience working on the Hubspot API ruby wrapper as a client project. They discuss strategies for testing third-party APIs, focusing on VCR and some of the benefits and trade-offs inherent to that style of API testing. Following that they chat about using exceptions for control flow, digging into why this seems to be a common pattern in Ruby API wrappers, what the alternatives are, and even a quick tour to React-land where this pattern is being used for interesting effect.</p> +<ul> +<li><a href="https://github.com/adimichele/hubspot-ruby">Hubspot ruby gem</a></li> +<li><a href="https://github.com/vcr/vcr">VCR</a></li> +<li><a href="https://docs.cucumber.io/">Cucumber</a></li> +<li><a href="https://thoughtbot.com/blog/mystery-guest">Mystery Guests</a></li> +<li><a href="https://github.com/rspec/rspec-mocks">Rspec mocks</a></li> +<li><a href="https://thoughtbot.com/blog/faking-apis-in-development-and-staging">Faking APIs in Development and Staging</a></li> +<li><a href="https://github.com/thoughtbot/capybara_discoball">Capybara Discoball</a></li> +<li><a href="https://thoughtbot.com/upcase/videos/testing-interaction-with-3rd-party-apis">Upcase - Testing Third Party APIs</a></li> +<li><a href="https://github.com/thoughtbot/fake_stripe">Fake stripe</a></li> +<li><a href="http://wiki.c2.com/?PrincipleOfLeastSurprise">Principle of least surprise</a></li> +<li><a href="https://en.wikipedia.org/wiki/Timeboxing">Time boxing</a></li> +<li><a href="https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise">JavaScript Promises</a></li> +<li><a href="https://reactjs.org/docs/react-api.html#reactsuspense">React.Suspense</a></li> +<li><a href="https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html">Dan Abramov Introducing React Suspense at JSConf Iceland</a></li> +</ul> + + + + On this week's episode, Chris is joined by Steph Viccari to chat about Steph's recent experience working on the Hubspot API ruby wrapper as a client project. They discuss strategies for testing third-party APIs, focusing on VCR and some of the benefits and trade-offs inherent to that style of API testing. Following that they chat about using exceptions for control flow, digging into why this seems to be a common pattern in Ruby API wrappers, what the alternatives are, and even a quick tour to React-land where this pattern is being used for interesting effect.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Steph Viccari to chat about Steph's recent experience working on the Hubspot API ruby wrapper as a client project. They discuss strategies for testing third-party APIs, focusing on VCR and some of the benefits and trade-offs inherent to that style of API testing. Following that they chat about using exceptions for control flow, digging into why this seems to be a common pattern in Ruby API wrappers, what the alternatives are, and even a quick tour to React-land where this pattern is being used for interesting effect.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+KQk5NskS + + ]]> + + + + 188: A Function by Any Other Name + https://bikeshed.thoughtbot.com/188 + 578b1e65-fea8-4e4e-9a68-a0a221cc6c52 + Fri, 22 Feb 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by German Velasco for a conversation that fully lives up to the name of the show with plenty of opinions and impressively deep dives on topics that folks outside the world of programming would never think could warrant this much discussion. + 38:01 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/germsvel">German Velasco</a> for a conversation<br /> +that fully lives up to the name of the show with plenty of opinions and<br /> +impressively deep dives on topics that folks outside the world of programming<br /> +would never think could warrant this much discussion.</p> +<p>How much duplication should we have? Is there such a thing as too DRY? Is there<br /> +ever a need for code comments, really? Lest you worry that Chris &amp; German spend<br /> +the whole episode just volleying opinions, have no fear: the episode is balanced<br /> +out with plenty of pointed suggestions and useful anecdotes to make sure<br /> +everyone will enjoy it.</p> +<ul> +<li><a href="https://www.netlify.com/">Netlify</a></li> +<li><a href="https://middlemanapp.com/">Middleman</a></li> +<li><a href="https://en.wikipedia.org/wiki/The_Pragmatic_Programmer">Pragmatic Programmer</a></li> +<li><a href="https://github.com/apollographql/apollo-tooling">Apollo CLI - codegen</a></li> +<li><a href="https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction">&quot;Duplication is far cheaper than the wrong abstraction&quot; - Sandi Metz</a></li> +<li><a href="https://thoughtbot.com/blog/don-t-forget-the-silent-step-when-you-squash-and-merge">German's Post on Writing a Good Commit Message</a></li> +<li><a href="https://thoughtbot.com/blog/write-good-commit-messages-by-blaming-others">German's Post on Git Blame</a></li> +<li><a href="https://hexdocs.pm/elixir/writing-documentation.html">Elixir first class documentation doctag</a></li> +<li><a href="https://elixir-lang.org/getting-started/mix-otp/docs-tests-and-with.html#doctests">Doctest in elixir</a></li> +<li><a href="https://docs.python.org/2/library/doctest.html">Doctest in python</a></li> +</ul> + + + + On this week's episode, Chris is joined by German Velasco for a conversation
+that fully lives up to the name of the show with plenty of opinions and
+impressively deep dives on topics that folks outside the world of programming
+would never think could warrant this much discussion.

+ +

How much duplication should we have? Is there such a thing as too DRY? Is there
+ever a need for code comments, really? Lest you worry that Chris & German spend
+the whole episode just volleying opinions, have no fear: the episode is balanced
+out with plenty of pointed suggestions and useful anecdotes to make sure
+everyone will enjoy it.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by German Velasco for a conversation
+that fully lives up to the name of the show with plenty of opinions and
+impressively deep dives on topics that folks outside the world of programming
+would never think could warrant this much discussion.

+ +

How much duplication should we have? Is there such a thing as too DRY? Is there
+ever a need for code comments, really? Lest you worry that Chris & German spend
+the whole episode just volleying opinions, have no fear: the episode is balanced
+out with plenty of pointed suggestions and useful anecdotes to make sure
+everyone will enjoy it.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+IFx-pm2M + + ]]> + + + + 187: Convincing People Not to Build Software + https://bikeshed.thoughtbot.com/187 + 54036025-095e-491a-b780-73f2ae772ec6 + Fri, 15 Feb 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by Matt Sumner, development director in our Boston Studio to discuss Matt's crypto adventures, design sprint experiences, a new ecosystem for him with Scala & GraphQL. + 41:31 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/matthewmsumner">Matt Sumner</a>, development director in our Boston Studio. Chris &amp; Matt start with a quick update on Matt's crypto adventures, and then transition to the core of the conversation as Matt describes the past few weeks of starting a new project and all the decisions that come with that.</p> +<p>The project kicked off with a product design sprint to help determine the initial direction for MVP. From there, Matt describes some of the thinking that went into the technology choices for the app, as well as describing his experience thus far working in a novel ecosystem for him with Scala &amp; GraphQL.</p> +<ul> +<li><a href="https://thoughtbot.com/playbook/product-design-sprint/introduction">Product Design Sprint</a></li> +<li><a href="https://thoughtbot.com/resources/validation?wvideo=xyh7stibu2">Design Sprint - 5 Phase Breakdown</a></li> +<li><a href="https://developer.apple.com/swift/">Swift</a></li> +<li><a href="https://graphql.org/">GraphQL</a></li> +<li><a href="https://graphql.pro/">GraphQL Ruby Pro</a></li> +<li><a href="https://github.com/varvet/pundit">Pundit</a></li> +<li><a href="https://github.com/CanCanCommunity/cancancan">CanCanCan</a></li> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://eslint.org/">Eslint</a></li> +<li><a href="https://www.typescriptlang.org/">Typescript</a></li> +<li><a href="https://github.com/sangria-graphql">Sangria GraphQL</a></li> +<li><a href="https://www.playframework.com/">Play Web Framework</a></li> +<li><a href="https://github.com/http4s/http4s">Http4s</a></li> +<li><a href="https://github.com/tpolecat/doobie">Doobie</a></li> +<li><a href="https://www.postgresql.org/docs/9.1/datatype-enum.html">Postgres enums</a></li> +<li><a href="https://github.com/thoughtbot/administrate">Administrate</a></li> +<li><a href="https://www.youtube.com/watch?v=8bZh5LMaSmE">All the Little Things by Sandi Metz &quot;Squint Test&quot;</a></li> +</ul> + + + + On this week's episode, Chris is joined by Matt Sumner, development director in our Boston Studio. Chris & Matt start with a quick update on Matt's crypto adventures, and then transition to the core of the conversation as Matt describes the past few weeks of starting a new project and all the decisions that come with that.

+ +

The project kicked off with a product design sprint to help determine the initial direction for MVP. From there, Matt describes some of the thinking that went into the technology choices for the app, as well as describing his experience thus far working in a novel ecosystem for him with Scala & GraphQL.

+ +

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Matt Sumner, development director in our Boston Studio. Chris & Matt start with a quick update on Matt's crypto adventures, and then transition to the core of the conversation as Matt describes the past few weeks of starting a new project and all the decisions that come with that.

+ +

The project kicked off with a product design sprint to help determine the initial direction for MVP. From there, Matt describes some of the thinking that went into the technology choices for the app, as well as describing his experience thus far working in a novel ecosystem for him with Scala & GraphQL.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ZVE32tWu + + ]]> + + + + 186: Let's Duplicate Stuff + https://bikeshed.thoughtbot.com/186 + ccb0a870-eba1-4bb3-bbb7-ebaa5504c72b + Fri, 01 Feb 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by Daniel Colson, developer in our New York studio and current maintainer of all things FactoryBot. Chris & Daniel discuss Daniel's work as maintainer of one of thoughtbot's most popular open source projects and some of the parallels to thoughtbot's consulting work. They then discuss a bit more on the specifics of FactoryBot and what's in store for upcoming versions. + 38:12 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/dodecadaniel">Daniel Colson</a>, developer in our New York studio and current maintainer of all things FactoryBot. Chris &amp; Daniel discuss Daniel's work as maintainer of one of thoughtbot's most popular open source projects and some of the parallels to thoughtbot's consulting work. They then discuss a bit more on the specifics of FactoryBot and what's in store for upcoming versions.</p> +<p>To round out the conversation Daniel and Chris also dig into some of the testing related best practices and patterns common to thoughtbot projects, linting and formatting tools, and even dip into the age old discussion around single quotes vs double quotes (just a tiny bit).</p> +<ul> +<li><a href="https://github.com/thoughtbot/factory_bot">factory_bot</a></li> +<li><a href="https://github.com/thoughtbot/factory_bot_rails">factory_bot_rails</a></li> +<li><a href="https://words.steveklabnik.com/how-to-be-an-open-source-gardener">How to be an open source gardener</a></li> +<li><a href="https://thoughtbot.com/blog/mystery-guest">Mystery Guest</a></li> +<li><a href="https://thoughtbot.com/blog/lets-not">Let's Not</a></li> +<li><a href="https://twitter.com/samphippen/status/1088398921993519107">&quot;What's the most painful thing you've ever had to do with RSpec?&quot;</a></li> +<li><a href="https://github.com/testdouble/standard">Standard - Ruby style guide, linter, and formatter</a></li> +<li><a href="https://github.com/prettier/prettier">Prettier - opinionated code formatter</a></li> +<li><a href="https://github.com/ruby-formatter/rufo">Rufo</a></li> +<li><a href="https://thoughtbot.com/blog/speed-up-tests-by-selectively-avoiding-factory-girl">Speed Up Tests by Selectively Avoiding Factory Girl</a></li> +</ul> +<p>Thank you to <a href="https://onemonth.com/thebikeshed">One Month</a> for sponsoring this episode.</p> + + + + On this week's episode, Chris is joined by Daniel Colson, developer in our New York studio and current maintainer of all things FactoryBot. Chris & Daniel discuss Daniel's work as maintainer of one of thoughtbot's most popular open source projects and some of the parallels to thoughtbot's consulting work. They then discuss a bit more on the specifics of FactoryBot and what's in store for upcoming versions.

+ +

To round out the conversation Daniel and Chris also dig into some of the testing related best practices and patterns common to thoughtbot projects, linting and formatting tools, and even dip into the age old discussion around single quotes vs double quotes (just a tiny bit).

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Daniel Colson, developer in our New York studio and current maintainer of all things FactoryBot. Chris & Daniel discuss Daniel's work as maintainer of one of thoughtbot's most popular open source projects and some of the parallels to thoughtbot's consulting work. They then discuss a bit more on the specifics of FactoryBot and what's in store for upcoming versions.

+ +

To round out the conversation Daniel and Chris also dig into some of the testing related best practices and patterns common to thoughtbot projects, linting and formatting tools, and even dip into the age old discussion around single quotes vs double quotes (just a tiny bit).

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+h_svK45Y + + ]]> + + + + 185: The Transactional Fallacy (Avdi Grimm) + https://bikeshed.thoughtbot.com/185 + cda197e9-8096-46b1-93bf-7f67cff47569 + Fri, 25 Jan 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by Ruby Hero Avdi Grimm. They discuss Avdi's history of guiding the Ruby and broader programming communities, his thoughts about where we're at with object-oriented programming, and where he's looking to next for our industry. + 35:01 + no + + <p>On this week's episode, Chris is joined by Ruby Hero <a href="https://twitter.com/avdi">Avdi Grimm</a>. They discuss Avdi's history of guiding the Ruby and broader programming communities, his thoughts about where we're at with object-oriented programming, and where he's looking to next for our industry.</p> +<p>This conversation touches on a variety of topics both technical and personal. Avdi shares some of his thinking around where we've failed with our approaches to object-oriented programming and viewing the world as transactional, and instead offers ideas around modeling our systems as processes.</p> +<p>Avdi &amp; Chris also chat about some of Avdi's my recent explorations into the world of JavaScript &amp; React, as well as the growing &quot;resilience engineering&quot; mindset.</p> +<ul> +<li><a href="https://devchat.tv/ruby-rogues/">Ruby Rouges Podcast</a></li> +<li><a href="https://www.youtube.com/watch?v=T8J0j2xJFgQ&amp;t=1s">Confident Code</a></li> +<li><a href="https://www.youtube.com/watch?v=UJnsXUVsr7w">Avdi's Keep Ruby Weird Keynote</a></li> +<li><a href="http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented">Alan Kay - Creator of Object Oriented Programming</a></li> +<li><a href="https://en.wikipedia.org/wiki/Actor_model">Actor Model</a></li> +<li><a href="https://kafka.apache.org/">Kafka</a></li> +<li><a href="https://www.rubytapas.com/">Ruby Tapas - Avdi's Weekly Ruby Screencast Series</a></li> +<li><a href="https://www.greaterthancode.com/podcast/">Greater Than Code Podcast</a></li> +<li><a href="https://avdi.codes/moom/">Mastering the Object Oriented Mindset</a></li> +<li><a href="http://www.pairprogramwith.me/">Pair Program With Me</a></li> +<li><a href="https://avdi.codes/duck/">Avdi - Ruby Duck Sessions</a></li> +<li><a href="https://www.youtube.com/watch?v=a8yWDfDip1o">Avdi and Jess stumble through modern web development</a></li> +<li><a href="https://glitch.com/">Glitch</a></li> +<li><a href="https://www.typescriptlang.org/">TypeScript</a></li> +<li><a href="https://www.aidr.org.au/programs/australian-disaster-resilience-conference/">Australian Disaster Resilience Conference</a></li> +<li><a href="https://github.com/Netflix/chaosmonkey">Chaos Monkey from Netflix</a></li> +<li><a href="https://avdi.codes">avdi.codes</a></li> +</ul> +<p>Thank you to <a href="https://onemonth.com/thebikeshed">One Month</a> for sponsoring this episode.</p> + + + + On this week's episode, Chris is joined by Ruby Hero Avdi Grimm. They discuss Avdi's history of guiding the Ruby and broader programming communities, his thoughts about where we're at with object-oriented programming, and where he's looking to next for our industry.

+ +

This conversation touches on a variety of topics both technical and personal. Avdi shares some of his thinking around where we've failed with our approaches to object-oriented programming and viewing the world as transactional, and instead offers ideas around modeling our systems as processes.

+ +

Avdi & Chris also chat about some of Avdi's my recent explorations into the world of JavaScript & React, as well as the growing "resilience engineering" mindset.

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Ruby Hero Avdi Grimm. They discuss Avdi's history of guiding the Ruby and broader programming communities, his thoughts about where we're at with object-oriented programming, and where he's looking to next for our industry.

+ +

This conversation touches on a variety of topics both technical and personal. Avdi shares some of his thinking around where we've failed with our approaches to object-oriented programming and viewing the world as transactional, and instead offers ideas around modeling our systems as processes.

+ +

Avdi & Chris also chat about some of Avdi's my recent explorations into the world of JavaScript & React, as well as the growing "resilience engineering" mindset.

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+VNDwiUQ4 + + ]]> + + + + 184: Fun, Interesting, and I Wouldn't Recommend It + https://bikeshed.thoughtbot.com/184 + 00b0a0ff-afb3-4a87-a099-b7905bbbd149 + Fri, 18 Jan 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this week's episode, Chris is joined by Eebs Kobeissi, a developer in our Boston studio, for a discussion encompassing the front end, back end, and everything in between. They start by discussing Eebs' recent work with both Elm & TypeScript, and the relative merits of these two strongly typed languages for the front end. From there they move on to a discussion around the different communities and rates of change in each. + 41:22 + no + + <p>On this week's episode, Chris is joined by <a href="https://twitter.com/EebsKobeissi">Eebs Kobeissi</a>, a developer in our Boston studio, for a discussion encompassing the front end, back end, and everything in between. They start by discussing Eebs' recent work with both Elm &amp; TypeScript, and the relative merits of these two strongly typed languages for the front end. From there they move on to a discussion around the different communities and rates of change in each.</p> +<p>Shifting gears, Chris then asks Eebs about his experience with more distributed systems and technologies like JSON Web Tokens, ElasitcSearch, RabbitMQ, Kafka, and more.</p> +<p>They round out the conversation with a discussion around some recent security discussions in package managers and their collective surprise that things work at all.</p> +<ul> +<li><a href="https://github.com/postmodern/chruby">chruby</a></li> +<li><a href="https://github.com/asdf-vm/asdf">asdf</a></li> +<li><a href="https://www.reddit.com/r/ruby/comments/ado2wb/matz_replies_to_post_from_this_sub_about_ruby/">Matz replies to post around Ruby moving slowly</a></li> +<li><a href="https://www.typescriptlang.org/">TypeScript</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://2018.stateofjs.com/javascript-flavors/typescript">TypeScript Growing Popularity on State of JS 2018</a></li> +<li><a href="https://jwt.io/">JSON Web Tokens (JTW)</a></li> +<li><a href="https://en.wikipedia.org/wiki/RSA_(cryptosystem)">RSA Public Key Cryptography</a></li> +<li><a href="https://en.wikipedia.org/wiki/OAuth">OAuth</a></li> +<li><a href="https://www.rabbitmq.com/">RabbitMQ</a></li> +<li><a href="https://www.elastic.co/products/elasticsearch">ElasitcSearch</a></li> +<li><a href="https://www.postgresql.org/docs/9.5/textsearch.html">Postgres Full Text Search</a></li> +<li><a href="https://kafka.apache.org/">Kafka</a></li> +<li><a href="https://martinfowler.com/eaaDev/EventSourcing.html">Event Sourcing</a></li> +<li><a href="https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident">Details about the event-stream incident</a></li> +<li><a href="http://heartbleed.com/">Heartbleed</a></li> +<li><a href="https://reactpodcast.simplecast.fm/33">Transcendence and the Future of React with Laurie Voss</a></li> +</ul> +<p>Thank you to <a href="https://onemonth.com/thebikeshed">One Month</a> for sponsoring this episode.</p> + + + + On this week's episode, Chris is joined by Eebs Kobeissi, a developer in our Boston studio, for a discussion encompassing the front end, back end, and everything in between. They start by discussing Eebs' recent work with both Elm & TypeScript, and the relative merits of these two strongly typed languages for the front end. From there they move on to a discussion around the different communities and rates of change in each.

+ +

Shifting gears, Chris then asks Eebs about his experience with more distributed systems and technologies like JSON Web Tokens, ElasitcSearch, RabbitMQ, Kafka, and more.

+ +

They round out the conversation with a discussion around some recent security discussions in package managers and their collective surprise that things work at all.

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + + On this week's episode, Chris is joined by Eebs Kobeissi, a developer in our Boston studio, for a discussion encompassing the front end, back end, and everything in between. They start by discussing Eebs' recent work with both Elm & TypeScript, and the relative merits of these two strongly typed languages for the front end. From there they move on to a discussion around the different communities and rates of change in each.

+ +

Shifting gears, Chris then asks Eebs about his experience with more distributed systems and technologies like JSON Web Tokens, ElasitcSearch, RabbitMQ, Kafka, and more.

+ +

They round out the conversation with a discussion around some recent security discussions in package managers and their collective surprise that things work at all.

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+_U4tI5v1 + + ]]> + + + + 183: Former Robots Smashing Into Other Giant Robots (Ben Orenstein) + https://bikeshed.thoughtbot.com/183 + f194b834-01b2-4011-8d0f-cee7d3fad9b0 + Fri, 11 Jan 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this episode of the Bike Shed, Chris is joined by former thoughtbotter Ben Orenstein. Ben & team are currently feverishly working towards launching Tuple.app, an app for remote pair programming. The conversation covers the unique technical challenges inherent to building this sort of app (WebRTC & firewalls, oh my), as well as a discussion around the merits and value of pair programming. To round out the conversation, Ben checks in on whether Chris is still "nerding out hard on Vim". + + 49:25 + no + + <p>On this episode of the Bike Shed, Chris is joined by former thoughtbotter <a href="https://twitter.com/r00k">Ben Orenstein</a>. Ben &amp; team are currently feverishly working towards launching Tuple.app, an app for remote pair programming. The conversation covers the unique technical challenges inherent to building this sort of app (WebRTC &amp; firewalls, oh my), as well as a discussion around the merits and value of pair programming. To round out the conversation, Ben checks in on whether Chris is still &quot;nerding out hard on Vim&quot;.</p> +<ul> +<li><a href="http://giantrobots.fm/">Giant Robots</a></li> +<li><a href="https://artofproductpodcast.com/">Art of Product Podcast</a></li> +<li><a href="https://tuple.app/">Tuple App</a></li> +<li><a href="https://webrtc.org/">WebRTC</a></li> +<li><a href="https://tuple.app/pair-programming-guide">Tuple - Pair Programming Guide</a></li> +<li><a href="https://news.ycombinator.com/item?id=9224">Infamous Hacker News Comment about the initial version Dropbox</a></li> +<li><a href="https://letsencrypt.org/">Let's Encrypt</a></li> +<li><a href="https://www.redhat.com/en">Red Hat - Enterprise Linux</a></li> +<li><a href="https://github.com/junegunn/fzf">fzf - generic fuzzy finder</a></li> +<li><a href="https://code.visualstudio.com/">VS Code</a></li> +<li><a href="https://www.youtube.com/watch?v=wlR5gYd6um0">Mastering the Vim Language</a></li> +<li><a href="https://twitter.com/r00k">@r00k - Ben on twitter</a></li> +</ul> +<p>Thank you to <a href="https://onemonth.com/thebikeshed">One Month</a> for sponsoring this episode.</p> + + + + On this episode of the Bike Shed, Chris is joined by former thoughtbotter Ben Orenstein. Ben & team are currently feverishly working towards launching Tuple.app, an app for remote pair programming. The conversation covers the unique technical challenges inherent to building this sort of app (WebRTC & firewalls, oh my), as well as a discussion around the merits and value of pair programming. To round out the conversation, Ben checks in on whether Chris is still "nerding out hard on Vim".

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + + On this episode of the Bike Shed, Chris is joined by former thoughtbotter Ben Orenstein. Ben & team are currently feverishly working towards launching Tuple.app, an app for remote pair programming. The conversation covers the unique technical challenges inherent to building this sort of app (WebRTC & firewalls, oh my), as well as a discussion around the merits and value of pair programming. To round out the conversation, Ben checks in on whether Chris is still "nerding out hard on Vim".

+ + + +

Thank you to One Month for sponsoring this episode.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+FP76q8Rw + + ]]> + + + + 182: What's it in the Service Of? + https://bikeshed.thoughtbot.com/182 + 86551ea2-ba9f-4657-a60f-9a46356933b9 + Fri, 04 Jan 2019 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Chris is joined by Eric Bailey, thoughtbot designer and champion for all things accessibility on the web. Chris & Eric chat about how Eric approaches accessibility and works to include it throughout the design process, design systems, functional CSS, CSS in JS, and more. + 39:12 + no + + <p>Chris is joined by <a href="https://twitter.com/ericwbailey">Eric Bailey</a>, thoughtbot designer and champion for all things accessibility on the web. Chris &amp; Eric chat about how Eric approaches accessibility and works to include it throughout the design process, design systems, functional CSS, CSS in JS, and more.</p> +<ul> +<li><a href="https://youtu.be/43OYDFgLjMQ">Eric's recent accessibility talk</a></li> +<li><a href="https://www.deque.com/shift-left/">Shifting Left</a></li> +<li><a href="https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb?hl=en">Vimium</a></li> +<li><a href="https://www.lightningdesignsystem.com/">Salesforce Lightning Design System</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM">Shadow DOM</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade">Introducing the CSS Cascade</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog">The element</a></li> +<li><a href="http://www.heydonworks.com/article/reluctant-gatekeeping-the-problem-with-full-stack">Heydon Pickering - Reluctant Gatekeeping: The Problem With Full Stack</a></li> +<li><a href="https://github.com/stubbornella/oocss/tree/master/oocss">Nicole Sulivan - Object Oriented CSS</a></li> +<li><a href="https://cssinjs.org/?v=v10.0.0-alpha.7">CSS in JS</a></li> +<li><a href="http://getbem.com/">BEM CSS Methodology</a></li> +<li><a href="https://tachyons.io/">Tachyons</a></li> +<li><a href="https://tailwindcss.com/">Tailwind CSS</a></li> +<li><a href="https://sass-lang.com/">Sass Lang</a></li> +<li><a href="https://csswizardry.com/2013/04/shame-css/">shame.css</a></li> +<li><a href="https://reach.tech/">Reach.tech</a> - Accessible foundation for React component design system</li> +<li><a href="https://www.freedomscientific.com/Products/Blindness/JAWS">JAWS Screen Reader</a></li> +<li><a href="https://ericwbailey.design/">ericwbailey.design</a></li> +</ul> + + + + Chris is joined by Eric Bailey, thoughtbot designer and champion for all things accessibility on the web. Chris & Eric chat about how Eric approaches accessibility and works to include it throughout the design process, design systems, functional CSS, CSS in JS, and more.

+ +

Support The Bike Shed

]]> + + + Chris is joined by Eric Bailey, thoughtbot designer and champion for all things accessibility on the web. Chris & Eric chat about how Eric approaches accessibility and works to include it throughout the design process, design systems, functional CSS, CSS in JS, and more.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NA0PcaDO + + ]]> + + + + 181: Strong Types and a Functional Flair + https://bikeshed.thoughtbot.com/181 + 820d4b55-af78-40fe-9598-80540d476636 + Fri, 14 Dec 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this episode of the Bike Shed, Chris is joined by thoughtbot CTO Joe Ferris. Chris & Joe start by talking about all things data. More and more we're building applications that need to manage medium to large data sets, combining data from multiple sources, and our approaches and frameworks need to evolve to match these needs. Joe provides the low down on how this can shape the way we build our applications. + +As part of the discussion around data they dig into the idea of event logs, most notably discussing Apache Kafka and it's unique approach to capturing state by storing an immutable event log, and the resulting architecture that falls out of this. + +Lastly they chat about the Scala language both in relation to data and streaming applications, but also more generally as an example of an approachable yet powerful strongly typed language. + 41:31 + no + + <p>On this episode of the Bike Shed, Chris is joined by thoughtbot CTO <a href="https://twitter.com/joeferris">Joe Ferris</a>. Chris &amp; Joe start by talking about all things data. More and more we're building applications that need to manage medium to large data sets, combining data from multiple sources, and our approaches and frameworks need to evolve to match these needs. Joe provides the low down on how this can shape the way we build our applications.</p> +<p>As part of the discussion around data they dig into the idea of event logs, most notably discussing Apache Kafka and it's unique approach to capturing state by storing an immutable event log, and the resulting architecture that falls out of this.</p> +<p>Lastly they chat about the Scala language both in relation to data and streaming applications, but also more generally as an example of an approachable yet powerful strongly typed language.</p> +<ul> +<li><a href="https://kafka.apache.org/">Kafka</a></li> +<li><a href="https://redux.js.org/">Redux</a></li> +<li><a href="https://flink.apache.org/">Flink</a></li> +<li><a href="https://spark.apache.org/">Spark</a></li> +<li><a href="https://www.postgresql.org/docs/9.1/wal-intro.html">Postgres Write-Ahead Log</a></li> +<li><a href="https://www.youtube.com/watch?v=fU9hR3kiOK0">&quot;Turning the database inside out with Apache Samza&quot; by Martin Kleppmann</a></li> +<li><a href="https://pixelastic.github.io/pokemonorbigdata/">Big Data or Pokemon</a></li> +<li><a href="https://www.datomic.com/">Datomic</a></li> +<li><a href="https://www.rabbitmq.com/">RabbitMQ</a></li> +<li><a href="https://www.amqp.org/">AMQP</a></li> +<li><a href="https://martinfowler.com/eaaDev/EventSourcing.html">Event Sourcing</a></li> +<li><a href="https://docs.python.org/3/library/typing.html">Python <code>typing</code> — Support for type hints</a></li> +<li><a href="https://medium.com/byteconf/stripe-is-building-a-ruby-typechecker-d6cd7cee6abf">Sorbet - gradual type annotations for Ruby from Strip</a></li> +</ul> + + + + On this episode of the Bike Shed, Chris is joined by thoughtbot CTO Joe Ferris. Chris & Joe start by talking about all things data. More and more we're building applications that need to manage medium to large data sets, combining data from multiple sources, and our approaches and frameworks need to evolve to match these needs. Joe provides the low down on how this can shape the way we build our applications.

+ +

As part of the discussion around data they dig into the idea of event logs, most notably discussing Apache Kafka and it's unique approach to capturing state by storing an immutable event log, and the resulting architecture that falls out of this.

+ +

Lastly they chat about the Scala language both in relation to data and streaming applications, but also more generally as an example of an approachable yet powerful strongly typed language.

+ +

Support The Bike Shed

]]> + + + On this episode of the Bike Shed, Chris is joined by thoughtbot CTO Joe Ferris. Chris & Joe start by talking about all things data. More and more we're building applications that need to manage medium to large data sets, combining data from multiple sources, and our approaches and frameworks need to evolve to match these needs. Joe provides the low down on how this can shape the way we build our applications.

+ +

As part of the discussion around data they dig into the idea of event logs, most notably discussing Apache Kafka and it's unique approach to capturing state by storing an immutable event log, and the resulting architecture that falls out of this.

+ +

Lastly they chat about the Scala language both in relation to data and streaming applications, but also more generally as an example of an approachable yet powerful strongly typed language.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+6z7ZLF5o + + ]]> + + + + 180: A Citizen of the Internet (John Resig) + https://bikeshed.thoughtbot.com/180 + 525bc5f9-fbcb-48b5-baae-363074a1516c + Fri, 07 Dec 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We're thrilled to welcome special guest John Resig, creator of jQuery and front-end architect at Khan Academy. + 39:14 + no + + <p>On this episode of the Bike Shed, we're thrilled to welcome special guest <a href="https://johnresig.com/">John Resig</a>, creator of jQuery and front-end architect at Khan Academy. The conversation begins with a discussion around John's work on jQuery, one of the most influential libraries in the history of the web. From there the discussion shifts to John's role as front-end architect at Khan Academy and how he balances feature development and paying down tech debt or exploring new technologies.</p> +<p>John and Chris then discuss the rate of change of front-end technologies, and John provides wonderfully pragmatic guidance distinguishing the rate of innovation from the perceived needed rate of adoption. The conversation also ventures into discussions around the trade-offs involved in open sourcing internal projects. Lastly, they touch briefly on the topic of GraphQL based on John's work at Kahn Academy, as well as his in-progress book, <a href="https://graphql.guide/">The GraphQL Guide</a>.</p> +<p>A little bit of everything with one of the most influential web developers of<br /> +the past 15 years. What more could you ask for?</p> +<ul> +<li><a href="http://jquery.com/">jQuery</a></li> +<li><a href="https://www.khanacademy.org/">Khan Academy</a></li> +<li><a href="https://githubengineering.com/removing-jquery-from-github-frontend/">Removing jQuery from GitHub.com frontend</a></li> +<li><a href="https://reactjs.org/docs/hooks-intro.html">React hooks</a></li> +<li><a href="https://webpack.js.org/">Webpack</a></li> +<li><a href="https://github.com/Khan/aphrodite">Aphrodite styling library from Khan Academy</a></li> +<li><a href="https://github.com/dominictarr/event-stream/issues/116">Event Stream NPM Package Security Issue</a></li> +<li><a href="https://graphql.guide/">The GraphQL Guide</a></li> +<li><a href="https://sangria-graphql.org/">Sangria GraphQL Framework in Scala</a></li> +<li><a href="https://johnresig.com/">John's personal site</a></li> +<li><a href="https://twitter.com/jeresig">John on twitter</a></li> +</ul> + + + + On this episode of the Bike Shed, we're thrilled to welcome special guest John Resig, creator of jQuery and front-end architect at Khan Academy. The conversation begins with a discussion around John's work on jQuery, one of the most influential libraries in the history of the web. From there the discussion shifts to John's role as front-end architect at Khan Academy and how he balances feature development and paying down tech debt or exploring new technologies.

+ +

John and Chris then discuss the rate of change of front-end technologies, and John provides wonderfully pragmatic guidance distinguishing the rate of innovation from the perceived needed rate of adoption. The conversation also ventures into discussions around the trade-offs involved in open sourcing internal projects. Lastly, they touch briefly on the topic of GraphQL based on John's work at Kahn Academy, as well as his in-progress book, The GraphQL Guide.

+ +

A little bit of everything with one of the most influential web developers of
+the past 15 years. What more could you ask for?

+ +

Support The Bike Shed

]]> + + + On this episode of the Bike Shed, we're thrilled to welcome special guest John Resig, creator of jQuery and front-end architect at Khan Academy. The conversation begins with a discussion around John's work on jQuery, one of the most influential libraries in the history of the web. From there the discussion shifts to John's role as front-end architect at Khan Academy and how he balances feature development and paying down tech debt or exploring new technologies.

+ +

John and Chris then discuss the rate of change of front-end technologies, and John provides wonderfully pragmatic guidance distinguishing the rate of innovation from the perceived needed rate of adoption. The conversation also ventures into discussions around the trade-offs involved in open sourcing internal projects. Lastly, they touch briefly on the topic of GraphQL based on John's work at Kahn Academy, as well as his in-progress book, The GraphQL Guide.

+ +

A little bit of everything with one of the most influential web developers of
+the past 15 years. What more could you ask for?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+dbbCK4SM + + ]]> + + + + 179: We CAN Just Use a Form! + https://bikeshed.thoughtbot.com/179 + 6f949866-544b-42dd-905c-dbe726bf0d88 + Fri, 30 Nov 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Matt Sumner returns to chat with Chris about their recent adventures. They discuss Matt's ongoing work building an open source Ethereum implementation in Elixir, Chris's recent trip to speak at GraphQL Summit, and React Hooks. + 49:47 + no + + <p>On this episode of the Bike Shed, <a href="https://twitter.com/matthewmsumner">Matt Sumner</a> returns to chat with Chris about their recent adventures. They start by discussing Matt's ongoing work building an open source Ethereum implementation in Elixir and the joys of a test suite guiding your work. From there, Matt asks Chris about Chris's recent trip to speak at GraphQL Summit and his take on the current state of affairs in the GraphQL world (hint, it's good).</p> +<p>Matt and Chris then discussed the progress they've made on simpler form handling in React applications and consider how far they could go with this, and then discuss the recent announcement of React Hooks.</p> +<p>And finally, they discuss the fact that thoughtbot is hiring, and we think you should apply! Head on over to <a href="https://thoughtbot.com/jobs">thoughtbot.com/jobs</a> and drop us a line :)</p> +<ul> +<li><a href="https://github.com/mana-ethereum/mana">Mana - ethereum</a></li> +<li><a href="https://devcenter.heroku.com/articles/exec">Heroku SSH</a></li> +<li><a href="http://erlang.org/doc/">Erlang OTP</a></li> +<li><a href="https://summit.graphql.com/">GraphQL Summit 2018</a></li> +<li><a href="https://foundation.graphql.org/">GraphQL Foundation</a></li> +<li><a href="https://www.apollographql.com/">Apollo GraphQL</a></li> +<li><a href="https://www.prisma.io/">Prisma</a></li> +<li><a href="https://www.graph.cool/">Graph.cool</a></li> +<li><a href="https://netflix.github.io/falcor/">Falcor (Netflix GraphQL-like library)</a></li> +<li><a href="http://netflix.github.io/falcor/documentation/jsongraph.html">JSON Graph</a></li> +<li><a href="https://github.com/leebyron">Lee Byron</a></li> +<li><a href="https://twitter.com/schrockn?lang=en">Nick Schrock</a></li> +<li><a href="https://github.com/Shopify/graphql-design-tutorial">Shopify GraphQL Design Tutorial</a></li> +<li><a href="https://www.youtube.com/watch?v=Qsoj4s_Ml6s">Chris Toomey: React &amp; GraphQL – Bringing Simplicity to Client Side Development video</a></li> +<li><a href="https://codesandbox.io/s/4220378010">CodeSandbox Proof of Concept - Simple React Form Handling</a></li> +<li><a href="https://jaredpalmer.com/formik">Formik</a> &amp; <a href="https://www.npmjs.com/package/yup">Yup</a></li> +<li><a href="https://reactjs.org/docs/hooks-intro.html">React -- Introducing Hooks</a></li> +<li><a href="https://github.com/reactjs/rfcs/pull/68">React Hooks RFC (now merged)</a></li> +</ul> + + + + On this episode of the Bike Shed, Matt Sumner returns to chat with Chris about their recent adventures. They start by discussing Matt's ongoing work building an open source Ethereum implementation in Elixir and the joys of a test suite guiding your work. From there, Matt asks Chris about Chris's recent trip to speak at GraphQL Summit and his take on the current state of affairs in the GraphQL world (hint, it's good).

+ +

Matt and Chris then discussed the progress they've made on simpler form handling in React applications and consider how far they could go with this, and then discuss the recent announcement of React Hooks.

+ +

And finally, they discuss the fact that thoughtbot is hiring, and we think you should apply! Head on over to thoughtbot.com/jobs and drop us a line :)

+ +

Support The Bike Shed

]]> + + + On this episode of the Bike Shed, Matt Sumner returns to chat with Chris about their recent adventures. They start by discussing Matt's ongoing work building an open source Ethereum implementation in Elixir and the joys of a test suite guiding your work. From there, Matt asks Chris about Chris's recent trip to speak at GraphQL Summit and his take on the current state of affairs in the GraphQL world (hint, it's good).

+ +

Matt and Chris then discussed the progress they've made on simpler form handling in React applications and consider how far they could go with this, and then discuss the recent announcement of React Hooks.

+ +

And finally, they discuss the fact that thoughtbot is hiring, and we think you should apply! Head on over to thoughtbot.com/jobs and drop us a line :)

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+K-8DE3w- + + ]]> + + + + 178: Friday is For Spikes + https://bikeshed.thoughtbot.com/178 + a755a0be-a19a-4ec3-9711-1b4d66f873e0 + Fri, 16 Nov 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this episode of the Bike Shed Chris is joined by Derek Prior, former thoughtbotter and previous host of this very podcast. Derek has recently moved on from thoughtbot to try out a new role as an engineering manager at GitHub. + 38:31 + no + + <p>On this episode of the Bike Shed Chris is joined by <a href="https://twitter.com/derekprior">Derek Prior</a>, former<br /> +thoughtbotter and previous host of this very podcast. Derek has recently moved<br /> +on from thoughtbot to try out a new role as an engineering manager at GitHub.</p> +<p>During their conversation they talk about Derek's experience shipping the<br /> +&quot;Suggested Changes&quot; feature on github.com, and the MVP process Derek brought to<br /> +the planning and development of the feature. They also touch on the architecture<br /> +of GitHub and where services and monoliths fit in the world of larger systems<br /> +like GitHub. Lastly they discuss Chris &amp; Derek's respective transitions into<br /> +more roles with a bit less code and a bit more management. As usual, this one<br /> +has a little bit of everything!</p> +<ul> +<li><a href="https://twitter.com/github/status/1053360435074949120">Suggested Changes feature</a></li> +<li><a href="https://githubuniverse.com/">GitHub Universe</a></li> +<li><a href="https://github.com/features/actions">GitHub Actions</a></li> +<li><a href="https://blog.github.com/2018-08-28-announcing-paper-cuts/">Project Papercuts at GitHub</a></li> +<li><a href="http://bikeshed.fm/166">Are Services the New Rewrite Bike Shed Episode</a></li> +<li><a href="https://github.com/github/scientist">GitHub Scientist</a></li> +<li><a href="https://www.beplucky.com/manager/">Be Plucky Manager Training</a></li> +</ul> + + + + On this episode of the Bike Shed Chris is joined by Derek Prior, former
+thoughtbotter and previous host of this very podcast. Derek has recently moved
+on from thoughtbot to try out a new role as an engineering manager at GitHub.

+ +

During their conversation they talk about Derek's experience shipping the
+"Suggested Changes" feature on github.com, and the MVP process Derek brought to
+the planning and development of the feature. They also touch on the architecture
+of GitHub and where services and monoliths fit in the world of larger systems
+like GitHub. Lastly they discuss Chris & Derek's respective transitions into
+more roles with a bit less code and a bit more management. As usual, this one
+has a little bit of everything!

+ +

Support The Bike Shed

]]> + + + On this episode of the Bike Shed Chris is joined by Derek Prior, former
+thoughtbotter and previous host of this very podcast. Derek has recently moved
+on from thoughtbot to try out a new role as an engineering manager at GitHub.

+ +

During their conversation they talk about Derek's experience shipping the
+"Suggested Changes" feature on github.com, and the MVP process Derek brought to
+the planning and development of the feature. They also touch on the architecture
+of GitHub and where services and monoliths fit in the world of larger systems
+like GitHub. Lastly they discuss Chris & Derek's respective transitions into
+more roles with a bit less code and a bit more management. As usual, this one
+has a little bit of everything!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+jOW2wRXi + + ]]> + + + + 177: Tricking Computers Into Doing Things + https://bikeshed.thoughtbot.com/177 + 25e92a73-f61e-4b3c-8def-1314a3576e27 + Fri, 09 Nov 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + On this episode of the Bike Shed, Chris is joined by Christina Entcheva, developer from thoughtbot’s New York studio to discuss rails performance, user focused development, and headless CMSs. + 32:21 + no + + <p>On this episode of the Bike Shed, Chris is joined by <a href="https://twitter.com/christinaent">Christina Entcheva</a>, developer from thoughtbot's New York studio who has been a product manager and designer previously in her career, but has since settled in to her role as a developer.</p> +<p>Chris &amp; Christina share a conversation ranging from their shared love of &quot;boring Rails apps&quot;, Christina's recent work with headless CMSs like Contentful &amp; Prismic, and a discussion around Rails performance. Throughout the conversation they touch on theme's of keeping a focus on user needs throughout the work of developing applications.</p> +<ul> +<li><a href="https://www.contentful.com/">Contentful</a></li> +<li><a href="https://prismic.io/">Prismic</a></li> +<li><a href="https://underscore.io/books/essential-scala/">Essential Scala book</a></li> +<li><a href="https://www.nateberkopec.com/">Nate Berkopec</a></li> +<li><a href="https://www.railsspeed.com/">The Complete Guide to Rails Performance</a></li> +<li><a href="https://www.youtube.com/watch?v=EPpWMoA6_Pc">Mark/Compact GC in MRI - Aaron Patterson</a></li> +<li><a href="http://ruby-doc.org/stdlib-2.2.0/libdoc/benchmark/rdoc/Benchmark.html">Benchmark module in Ruby</a></li> +<li><a href="https://www.postgresql.org/docs/current/ddl-partitioning.html">Postgres Table Partitioning</a></li> +<li><a href="https://basecamp.com/books/getting-real">Getting Real book by Basecamp</a></li> +<li><a href="https://smile.amazon.com/Doesnt-Have-Be-Crazy-Work/dp/0062874780">It Doesn't Have to Be Crazy at Work</a></li> +<li><a href="https://robots.thoughtbot.com/announcing-upcase-is-free">Upcase is now Free!</a></li> +<li><a href="https://thoughtbot.com/upcase/videos/testing-interaction-with-3rd-party-apis">Testing Interaction with 3rd-party APIs on Upcase</a></li> +<li><a href="https://thoughtbot.com/upcase/videos/composition-over-inheritance">Composition Over Inheritance on Upcase</a></li> +</ul> + + + + On this episode of the Bike Shed, Chris is joined by Christina Entcheva, developer from thoughtbot's New York studio who has been a product manager and designer previously in her career, but has since settled in to her role as a developer.

+ +

Chris & Christina share a conversation ranging from their shared love of "boring Rails apps", Christina's recent work with headless CMSs like Contentful & Prismic, and a discussion around Rails performance. Throughout the conversation they touch on theme's of keeping a focus on user needs throughout the work of developing applications.

+ +

Support The Bike Shed

]]> + + + On this episode of the Bike Shed, Chris is joined by Christina Entcheva, developer from thoughtbot's New York studio who has been a product manager and designer previously in her career, but has since settled in to her role as a developer.

+ +

Chris & Christina share a conversation ranging from their shared love of "boring Rails apps", Christina's recent work with headless CMSs like Contentful & Prismic, and a discussion around Rails performance. Throughout the conversation they touch on theme's of keeping a focus on user needs throughout the work of developing applications.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Ugop-_NJ + + ]]> + + + + 176: The Machines Will Learn + https://bikeshed.thoughtbot.com/176 + 8d100b22-a647-4f16-86de-b99e579ea07b + Fri, 02 Nov 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this episode of the Bike Shed Chris is joined by George Brocklehurst, development director in thoughtbot's New York studio. The conversation starts with a discussion around progressive enhancement and the state of the modern web, and then shifts to focus on George's recent explorations of machine learning. This episode is a perfect introduction to the topic of ML, and provides a great summary of why you might want to start working with it and how to go about that. + 37:10 + no + + <p>On this episode of the Bike Shed Chris is joined by <a href="https://twitter.com/georgebrock">George Brocklehurst</a>, development director in thoughtbot's New York studio. The conversation starts with a discussion around progressive enhancement and the state of the modern web, and then shifts to focus on George's recent explorations of machine learning. This episode is a perfect introduction to the topic of ML, and provides a great summary of why you might want to start working with it and how to go about that.</p> +<ul> +<li><a href="https://www.youtube.com/watch?v=zuoMsxA9vOg">Does Progressive Enhancement Have a Place in Today's Web?</a></li> +<li><a href="https://vuejs.org/">Vue.js</a></li> +<li><a href="https://electronjs.org/">Electron</a></li> +<li><a href="https://facebook.github.io/react-native/">React Native</a></li> +<li><a href="https://github.com/status-im/react-native-desktop">React Native for Desktop</a></li> +</ul> +<h2>Frameworks and Tools For Exploring Machine Learning</h2> +<ul> +<li><a href="http://www.numpy.org/">NumPy</a></li> +<li><a href="https://www.scipy.org/">SciPy</a></li> +<li><a href="http://jupyter.org/">Jupyter Notebook</a></li> +<li><a href="https://pandas.pydata.org/">Pandas</a></li> +<li><a href="http://scikit-learn.org/stable/">scikit-learn</a></li> +<li><a href="https://www.nltk.org/">Natural Language Toolkit (NLKT)</a></li> +<li><a href="https://spacy.io/">spaCy</a></li> +<li><a href="https://radimrehurek.com/gensim/">gensim</a></li> +</ul> +<h2>Getting Started with Machine Learning:</h2> +<ul> +<li><a href="https://youtu.be/_kNO-LaGfhA">Intro to Machine Learning Workshop</a></li> +<li><a href="https://robots.thoughtbot.com/what-is-machine-learning">What is Machine Learning?</a></li> +<li><a href="https://robots.thoughtbot.com/named-entity-recognition">Named Entity Recognition</a></li> +<li><a href="https://robots.thoughtbot.com/recommending-blog-posts">Recommending blog posts with machine learning</a></li> +</ul> + + + + On this episode of the Bike Shed Chris is joined by George Brocklehurst, development director in thoughtbot's New York studio. The conversation starts with a discussion around progressive enhancement and the state of the modern web, and then shifts to focus on George's recent explorations of machine learning. This episode is a perfect introduction to the topic of ML, and provides a great summary of why you might want to start working with it and how to go about that.

+ + + +

Frameworks and Tools For Exploring Machine Learning

+ + + +

Getting Started with Machine Learning:

+ +

Support The Bike Shed

]]> + + + On this episode of the Bike Shed Chris is joined by George Brocklehurst, development director in thoughtbot's New York studio. The conversation starts with a discussion around progressive enhancement and the state of the modern web, and then shifts to focus on George's recent explorations of machine learning. This episode is a perfect introduction to the topic of ML, and provides a great summary of why you might want to start working with it and how to go about that.

+ + + +

Frameworks and Tools For Exploring Machine Learning

+ + + +

Getting Started with Machine Learning:

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+gg2F-o63 + + ]]> + + + + 175: Tell Me When It's Real + https://bikeshed.thoughtbot.com/175 + ef893b70-88c2-4b64-8507-fab3e03d9d72 + Fri, 26 Oct 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + On this episode of the Bike Shed, Chris is joined by Josh Clayton, thoughtbot’s managing director in our Boston studio. Chris and Josh spend the episode discussing the various patterns and trends they see in the world of web development, covering languages and frameworks as well as more general patterns and approaches. + 42:11 + no + + <p>On this episode of the Bike Shed, Chris is joined by <a href="https://twitter.com/joshuaclayton">Josh Clayton</a>, thoughtbot's managing director in our Boston studio. Chris and Josh spend the episode discussing the various patterns and trends they see in the world of web development. Specifically, they touch on server side frameworks like Ruby on Rails and Phoenix in the Elixir world. In addition, they discuss a variety of front end trends including the move towards typed languages like ReasonML, TypeScript, Elm, PureScript, and Scala.js, as well as frameworks like React, Ember, Angular, and Vue.js.</p> +<ul> +<li><a href="http://bikeshed.fm/20">Bike Shed 20 w/ Josh Clayton: Intentionally Excruciatingly Painful</a></li> +<li><a href="https://developers.google.com/web/tools/lighthouse/">Google Lighthouse</a></li> +<li><a href="https://www.youtube.com/watch?v=v6iR3Zk4oDY">Beyond React 16 by Dan Abramov - JSConf Iceland</a></li> +<li><a href="https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c">AirBnB Moving Away from React Native</a></li> +<li><a href="https://www.youtube.com/watch?v=Dr3kQB8byEo&amp;t=545s">Josh Steiner - Elm native UI in production</a></li> +<li><a href="https://robots.thoughtbot.com/announcing-purple-train">Announcing Purple Train</a></li> +<li><a href="https://reasonml.github.io/">ReasonML</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://www.typescriptlang.org/">TypeScript</a></li> +<li><a href="http://www.purescript.org/">PureScript</a></li> +<li><a href="https://www.scala-js.org/">Scala.js</a></li> +<li><a href="http://tonsky.me/blog/disenchantment/">Software disenchantment blog post</a></li> +<li><a href="http://bikeshed.fm/166">166: Are Services the New Rewrite?</a></li> +<li><a href="https://github.com/apollographql/apollo-client">Apollo Client</a></li> +<li><a href="https://vuejs.org/">Vue.js</a></li> +<li><a href="https://www.thoughtworks.com/radar">Thoughtworks Technology Radar</a></li> +<li><a href="https://github.com/parcel-bundler/parcel">Parcel Bundler</a></li> +<li><a href="https://github.com/terser-js/terser">Terser javascript minifier</a></li> +<li><a href="https://github.com/ruby-formatter/rufo">Rufo - Ruby autoformatter</a></li> +</ul> + + + + On this episode of the Bike Shed, Chris is joined by Josh Clayton, thoughtbot's managing director in our Boston studio. Chris and Josh spend the episode discussing the various patterns and trends they see in the world of web development. Specifically, they touch on server side frameworks like Ruby on Rails and Phoenix in the Elixir world. In addition, they discuss a variety of front end trends including the move towards typed languages like ReasonML, TypeScript, Elm, PureScript, and Scala.js, as well as frameworks like React, Ember, Angular, and Vue.js.

+ +

Support The Bike Shed

]]> + + + On this episode of the Bike Shed, Chris is joined by Josh Clayton, thoughtbot's managing director in our Boston studio. Chris and Josh spend the episode discussing the various patterns and trends they see in the world of web development. Specifically, they touch on server side frameworks like Ruby on Rails and Phoenix in the Elixir world. In addition, they discuss a variety of front end trends including the move towards typed languages like ReasonML, TypeScript, Elm, PureScript, and Scala.js, as well as frameworks like React, Ember, Angular, and Vue.js.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+S_W1ksoK + + ]]> + + + + 174: I've Watched a Lot of Vim Courses + https://bikeshed.thoughtbot.com/174 + d4f6664f-b373-440f-ad45-8367045d7933 + Thu, 18 Oct 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + In this special crossover episode, Chris is joined by Chad Pytel, Co-founder & CEO of thoughtbot and host of _Giant Robots Smashing Into Other Giant Robots_ podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE. + 30:48 + no + + <p>In this special crossover episode, Chris is joined by Chad Pytel, Co-founder &amp; CEO of thoughtbot and host of <em>Giant Robots Smashing Into Other Giant Robots</em> podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE.</p> +<ul> +<li><a href="http://giantrobots.fm/"><em>Giant Robots</em> Podcast</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://thoughtbot.com/upcase/test-driven-rails">Test Driven Rails</a></li> +<li><a href="https://thoughtbot.com/upcase/mastering-git">Mastering Git</a></li> +<li><a href="https://thoughtbot.com/upcase/fundamentals-of-tdd">Fundamentals of TDD</a></li> +<li><a href="http://bikeshed.fm/166">SOA on <em>The Bike Shed</em></a></li> +<li><a href="https://thoughtbot.com/upcase/onramp-to-vim">Onramp to Vim</a></li> +<li><a href="https://thoughtbot.com/purpose">thoughtbot Purpose Statement</a></li> +<li><a href="https://twitter.com/cpytel">Chad on Twitter</a></li> +</ul> + + + + In this special crossover episode, Chris is joined by Chad Pytel, Co-founder & CEO of thoughtbot and host of Giant Robots Smashing Into Other Giant Robots podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE.

+ +

Support The Bike Shed

]]> + + + In this special crossover episode, Chris is joined by Chad Pytel, Co-founder & CEO of thoughtbot and host of Giant Robots Smashing Into Other Giant Robots podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+fZL6pY2T + + ]]> + + + + 173: A Combinatoric Explosion of Nulls + https://bikeshed.thoughtbot.com/173 + 53f132c2-e212-428d-842f-0c70f021838d + Fri, 12 Oct 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Joël Quenneville joins Chris to discuss Elm, the strongly typed functional programming language for writing reliable client side web apps. They discuss recent changes from the 0.19 release including reduced bundle size from dead code elimination, the somewhat controversial removal of custom operators. Anecdotally, Joël and team saw a reduction from 31.5K to 16.6K in bundle size going from 0.18 to 0.19 and felt no pain from the custom operators removal, so a big net win for them with this new version. + +Along the way Joël and Chris detour into the complexity of managing a project and community like Elm's and discuss Joel's recent work with the thoughtbot apprentice program. To round things out, Joël and Chris discuss the power of using a type system like Elm's to constrain the valid states of your application and make your apps more robust and maintainable. + 50:05 + no + + <p><a href="https://twitter.com/joelquen">Joël Quenneville</a> joins Chris to discuss Elm, the strongly typed functional programming language for writing reliable client side web apps. They discuss recent changes from the 0.19 release including reduced bundle size from dead code elimination, the somewhat controversial removal of custom operators. Anecdotally, Joël and team saw a reduction from 31.5K to 16.6K in bundle size going from 0.18 to 0.19 and felt no pain from the custom operators removal, so a big net win for them with this new version.</p> +<p>Along the way Joël and Chris detour into the complexity of managing a project and community like Elm's and discuss Joël‘s recent work with the thoughtbot apprentice program. To round things out, Joël and Chris discuss the power of using a type system like Elm's to constrain the valid states of your application and make your apps more robust and maintainable.</p> +<ul> +<li><a href="https://elm-lang.org/">Elm - A delightful language for reliable webapps.</a></li> +<li><a href="https://elm-lang.org/blog/small-assets-without-the-headache">Elm 0.19 Release Notes</a></li> +<li><a href="https://github.com/rails/webpacker">Webpacker</a></li> +<li><a href="https://elm-lang.org/blog/small-assets-without-the-headache#dead-code-elimination">Elm 0.19 - Dead Code Elimination</a></li> +<li><a href="https://www.scala-js.org/">Scala.js</a></li> +<li><a href="https://gist.github.com/evancz/769bba8abb9ddc3bf81d69fa80cc76b1">The reasoning behind removing user-defined operators</a></li> +<li><a href="https://slikts.github.io/js-equality-game/">Minesweeper for JavaScript Equality</a></li> +<li><a href="https://webassembly.org/">WebAssembly</a></li> +<li><a href="https://lkml.org/lkml/2018/9/16/167">Linus Torvalds - &quot;I am going to take time off and get some assistance...&quot;</a></li> +<li><a href="https://lkml.org/lkml/2004/12/20/255">Also Linus, on the importance of &quot;trivial patches&quot; as entry points for new kernal developers</a></li> +<li><a href="https://www.youtube.com/watch?v=PJjmw9TRB7s">Derek Prior - Implementing a Strong Code-Review Culture</a></li> +<li><a href="https://github.com/thoughtbot/guides/blob/master/code-review/README.md">thoughtbot code review guidelines</a></li> +<li><a href="https://thoughtbot.com/playbook/our-company/apprenticeship">thoughtbot apprentice program</a></li> +<li><a href="http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html">How Elm Slays a UI Antipattern</a></li> +<li><a href="https://www.youtube.com/watch?v=IcgmSRJHu_8">&quot;Making Impossible States Impossible&quot; talk by Richard Feldman</a></li> +<li><a href="https://www.youtube.com/watch?v=43eM4kNbb6c">&quot;Working with Maybe&quot; talk by Joël Quenneville</a></li> +<li><a href="https://www.youtube.com/watch?v=T8J0j2xJFgQ">&quot;Confident Code&quot; talk by Avdi Grimm</a></li> +<li><a href="https://www.youtube.com/watch?v=OMPfEXIlTVE">&quot;Nothing is Something&quot; talk by Sandi Metz</a></li> +<li><a href="https://www.python.org/dev/peps/pep-0020/">The Zen of Python</a></li> +<li><a href="http://redsquirrel.com/dave/work/a2j/patterns/BreakableToys.html">Breakable Toys</a></li> +<li><a href="https://robots.thoughtbot.com/authors/joel-quenneville">Joel’s many posts on the Giant Robots blog</a></li> +<li><a href="https://robots.thoughtbot.com/stop-coding-and-start-drawing">Stop Coding and Start Drawing</a></li> +</ul> + + + + Joël Quenneville joins Chris to discuss Elm, the strongly typed functional programming language for writing reliable client side web apps. They discuss recent changes from the 0.19 release including reduced bundle size from dead code elimination, the somewhat controversial removal of custom operators. Anecdotally, Joël and team saw a reduction from 31.5K to 16.6K in bundle size going from 0.18 to 0.19 and felt no pain from the custom operators removal, so a big net win for them with this new version.

+ +

Along the way Joël and Chris detour into the complexity of managing a project and community like Elm's and discuss Joël‘s recent work with the thoughtbot apprentice program. To round things out, Joël and Chris discuss the power of using a type system like Elm's to constrain the valid states of your application and make your apps more robust and maintainable.

+ +

Support The Bike Shed

]]> + + + Joël Quenneville joins Chris to discuss Elm, the strongly typed functional programming language for writing reliable client side web apps. They discuss recent changes from the 0.19 release including reduced bundle size from dead code elimination, the somewhat controversial removal of custom operators. Anecdotally, Joël and team saw a reduction from 31.5K to 16.6K in bundle size going from 0.18 to 0.19 and felt no pain from the custom operators removal, so a big net win for them with this new version.

+ +

Along the way Joël and Chris detour into the complexity of managing a project and community like Elm's and discuss Joël‘s recent work with the thoughtbot apprentice program. To round things out, Joël and Chris discuss the power of using a type system like Elm's to constrain the valid states of your application and make your apps more robust and maintainable.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+uydsdEzK + + ]]> + + + + 172: What I Believe About Software + https://bikeshed.thoughtbot.com/172 + b6a78f74-fbd8-4953-972f-4764c79f4b22 + Fri, 05 Oct 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Steph Viccari joins Chris for a conversation starting with a discussion of some deployment and orchestration issues Chris was helping out with, followed by some of Steph's recent experiences with JSONB in postgres and the relative trade-offs of unstructured data. + +The heart of the conversation revolves around the core processes we use to develop software touching on sprint planning & story points, deadlines, the place for refactoring and code review in the regular cadence of development, and the often lamented retrospective meeting. + 55:51 + no + + <p><a href="https://twitter.com/sviccari">Steph Viccari</a> joins Chris for a conversation starting with a discussion of some deployment and orchestration issues Chris was helping out with, followed by some of Steph's recent experiences with JSONB in postgres and the relative trade-offs of unstructured data.</p> +<p>The heart of the conversation revolves around the core processes we use to develop software touching on sprint planning &amp; story points, deadlines, the place for refactoring and code review in the regular cadence of development, and the often lamented retrospective meeting.</p> +<ul> +<li><a href="https://www.aptible.com/">Aptible</a> - PAAS with strong security and HIPAA compliance</li> +<li><a href="https://www.heroku.com/shield">Heroku Shield</a></li> +<li><a href="https://www.zdnet.com/article/chrome-69-kills-off-www-in-urls-heres-why-googles-move-has-made-people-angry/">Google hiding www in URLs</a></li> +<li><a href="https://auth0.com/">Auth0</a> - Identity management and auth as a service</li> +<li><a href="https://edgeguides.rubyonrails.org/active_storage_overview.html">ActiveStorage</a> - Rails's built in filie attachment framework</li> +<li><a href="https://www.postgresql.org/docs/9.4/static/datatype-json.html">Postgres JSON &amp; JSONB Types</a></li> +<li><a href="https://robots.thoughtbot.com/the-real-story-behind-story-points">The Real Story Behind Story Points</a></li> +<li><a href="https://www.linkedin.com/feed/update/urn:li:activity:6441293207857958913/">Laurie Young Post on His Use of Story Points</a></li> +<li><a href="https://robots.thoughtbot.com/deadlines">Deadlines</a></li> +<li><a href="https://xkcd.com/1425/">XKCD - And Check Whether the Photo is of a Bird</a></li> +<li><a href="https://www.headspace.com/">Headspace meditation</a></li> +</ul> + + + + Steph Viccari joins Chris for a conversation starting with a discussion of some deployment and orchestration issues Chris was helping out with, followed by some of Steph's recent experiences with JSONB in postgres and the relative trade-offs of unstructured data.

+ +

The heart of the conversation revolves around the core processes we use to develop software touching on sprint planning & story points, deadlines, the place for refactoring and code review in the regular cadence of development, and the often lamented retrospective meeting.

+ +

Support The Bike Shed

]]> + + + Steph Viccari joins Chris for a conversation starting with a discussion of some deployment and orchestration issues Chris was helping out with, followed by some of Steph's recent experiences with JSONB in postgres and the relative trade-offs of unstructured data.

+ +

The heart of the conversation revolves around the core processes we use to develop software touching on sprint planning & story points, deadlines, the place for refactoring and code review in the regular cadence of development, and the often lamented retrospective meeting.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+SpleU69M + + ]]> + + + + 171: What If We Just Used a Form? + https://bikeshed.thoughtbot.com/171 + 17c17cd2-20ea-4d7f-ab1d-3da0aa1cb6af + Fri, 21 Sep 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Matt Sumner joins Chris for a discussion around Matt's recent adventures with the block chain and Ethereum, as well as tackling the thorny issue of server rendered vs client side apps. They cover a bit of history, a bit of opinion, and some practical considerations to keep in mind when tackling rich client development. + 45:55 + no + + <p><a href="https://github.com/MattMSumner">Matt Sumner</a> joins Chris for a discussion around Matt's recent adventures with the block chain and Ethereum, as well as tackling the thorny issue of server rendered vs client side apps. They cover a bit of history, a bit of opinion, and some practical considerations to keep in mind when tackling rich client development.</p> +<ul> +<li><a href="https://www.ethereum.org/">Ethereum</a></li> +<li><a href="https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs">Ethereum Proof of Stake</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/API/History_API">Browser History APIs including pushState</a></li> +<li><a href="https://en.wikipedia.org/wiki/SOAP">SOAP</a></li> +<li><a href="https://guides.emberjs.com/release/routing/">Ember's heroic focus on the URL &amp; Routes</a></li> +<li><a href="https://graphql.org/">GraphQL</a></li> +<li><a href="https://www.typescriptlang.org/">TypeScript</a></li> +<li><a href="https://vimium.github.io/">Vimium</a></li> +<li><a href="http://www.reactboston.com/">Boston React Conference</a></li> +</ul> + + + + Matt Sumner joins Chris for a discussion around Matt's recent adventures with the block chain and Ethereum, as well as tackling the thorny issue of server rendered vs client side apps. They cover a bit of history, a bit of opinion, and some practical considerations to keep in mind when tackling rich client development.

+ +

Support The Bike Shed

]]> + + + Matt Sumner joins Chris for a discussion around Matt's recent adventures with the block chain and Ethereum, as well as tackling the thorny issue of server rendered vs client side apps. They cover a bit of history, a bit of opinion, and some practical considerations to keep in mind when tackling rich client development.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+F8_yMHEo + + ]]> + + + + 170: Less Charted Territory + https://bikeshed.thoughtbot.com/170 + f7c6c5e5-160d-4022-a321-24d60f6d778b + Fri, 14 Sep 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris is joined by Paul Smith to discuss Crystal, a statically-typed and compiled language with a Ruby inspired syntax. Paul has spent much of the past few years exploring Crystal and building a new web framework called Lucky. + +Paul's infectious enthusiasm for the Crystal language shines through in this discussion covering some of the unique features of Crystal & Lucky, but there is plenty to enjoy even if you're not specifically interested in Crystal. + +With Lucky, Paul has done a great job of taking the best of what has been built in other frameworks and bring it to Crystal, drawing inspiration from Ruby & Rails, Elixir & Phoenix, and even PHP and the Laravel framework. There's something in this episode for everyone! + 49:14 + no + + <p>Chris is joined by <a href="https://twitter.com/paulcsmith">Paul Smith</a> to discuss Crystal, a statically-typed and compiled language with a Ruby inspired syntax. Paul has spent much of the past few years exploring Crystal and building a new web framework called Lucky.</p> +<p>Paul's infectious enthusiasm for the Crystal language shines through in this discussion covering some of the unique features of Crystal &amp; Lucky, but there is plenty to enjoy even if you're not specifically interested in Crystal.</p> +<p>With Lucky, Paul has done a great job of taking the best of what has been built in other frameworks and bring it to Crystal, drawing inspiration from Ruby &amp; Rails, Elixir &amp; Phoenix, and even PHP and the Laravel framework. There's something in this episode for everyone!</p> +<ul> +<li><a href="https://crystal-lang.org">Crystal</a></li> +<li><a href="https://robots.thoughtbot.com/if-you-gaze-into-nil-nil-gazes-also-into-you">If You Gaze Into nil, nil Gazes Also Into You</a></li> +<li><a href="https://elm-lang.org/">Elm</a></li> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://elixir-lang.org/">Elixir</a></li> +<li><a href="https://phoenixframework.org/">Elixir Phoenix</a></li> +<li><a href="https://laravel.com/">Laravel</a></li> +<li><a href="https://github.com/JeffreyWay/laravel-mix">Laravel Mix</a></li> +<li><a href="https://github.com/luckyframework/lucky">Lucky on GitHub</a></li> +<li><a href="https://luckyframework.org/guides/rendering-html/">Render HTML pages in Lucky</a></li> +<li><a href="https://luckyframework.org/guides/actions-and-routing/">Actions and Routing in Lucky</a></li> +<li><a href="https://luckyframework.org/guides/browser-tests/">Browser tests with LuckyFlow</a></li> +<li><a href="https://laravel.com/docs/5.6/dusk#dusk-selectors">Dusk selectors</a></li> +<li><a href="https://mail.python.org/pipermail/python-committers/2018-July/005664.html">Guido Van Rossum, Python BDFL, Stepping down</a></li> +<li><a href="https://code.visualstudio.com/">VS Code</a></li> +<li><a href="http://bikeshed.fm/167">BikeShed episode w/ German Velasco disucssing Elixir</a></li> +</ul> + + + + Chris is joined by Paul Smith to discuss Crystal, a statically-typed and compiled language with a Ruby inspired syntax. Paul has spent much of the past few years exploring Crystal and building a new web framework called Lucky.

+ +

Paul's infectious enthusiasm for the Crystal language shines through in this discussion covering some of the unique features of Crystal & Lucky, but there is plenty to enjoy even if you're not specifically interested in Crystal.

+ +

With Lucky, Paul has done a great job of taking the best of what has been built in other frameworks and bring it to Crystal, drawing inspiration from Ruby & Rails, Elixir & Phoenix, and even PHP and the Laravel framework. There's something in this episode for everyone!

+ +

Support The Bike Shed

]]> + + + Chris is joined by Paul Smith to discuss Crystal, a statically-typed and compiled language with a Ruby inspired syntax. Paul has spent much of the past few years exploring Crystal and building a new web framework called Lucky.

+ +

Paul's infectious enthusiasm for the Crystal language shines through in this discussion covering some of the unique features of Crystal & Lucky, but there is plenty to enjoy even if you're not specifically interested in Crystal.

+ +

With Lucky, Paul has done a great job of taking the best of what has been built in other frameworks and bring it to Crystal, drawing inspiration from Ruby & Rails, Elixir & Phoenix, and even PHP and the Laravel framework. There's something in this episode for everyone!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ML-2my_j + + ]]> + + + + 169: Fear Driven Development + https://bikeshed.thoughtbot.com/169 + 85aad1f7-0c7a-440a-99eb-63e943325457 + Fri, 07 Sep 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris is joined by Kane Baccigalupi, development director from thoughtbot's San Francisco office to discuss Kane's history in government working for 18F and California State and how those experiences have informed Kane's work since. + +Throughout the conversation Chris and Kane discuss their shared desire to hide all implementation details and their love of Ruby for how it allows us to do that, testing vs test driven development, and approaches for refactoring large untested systems. + 38:44 + no + + <p>Chris is joined by <a href="https://twitter.com/rubyghetto">Kane Baccigalupi</a>, development director from thoughtbot's San Francisco office to discuss Kane's history in government working for 18F and California State and how those experiences have informed Kane's work since.</p> +<p>Throughout the conversation Chris and Kane discuss their shared desire to hide all implementation details and their love of Ruby for how it allows us to do<br /> +that, testing vs test driven development, and approaches for refactoring large<br /> +untested systems.</p> +<ul> +<li><a href="https://18f.gsa.gov/">18F</a> - A consulting team within the government helping to introduce modern<br /> +software development practices.</li> +<li><a href="https://twitter.com/rubyghetto/status/995096564153573376">Kane's tweet about the enjoyment of the refactoring and design parts of the process.</a></li> +<li><a href="http://bikeshed.fm/15">Sarah Mei on <em>The Bike Shed</em></a></li> +<li><a href="https://en.wikipedia.org/wiki/Uniform_access_principle">Uniform Access Principle</a></li> +<li><a href="https://medium.freecodecamp.org/8-observations-on-test-driven-development-a9b5144f868">Observations on the testing culture of Test Driven Development</a> - TDD<br /> +article that introduces the phrase &quot;calling the shot&quot; for the practice of TDD.</li> +<li><a href="https://codeclimate.com/blog/why-ruby-class-methods-resist-refactoring/">Convenience class methods on service objects</a></li> +<li><a href="https://martinfowler.com/bliki/TestPyramid.html">Testing Pyramid</a> - A way to think about the cost and value of the<br /> +various types of tests.</li> +<li><a href="https://www.youtube.com/watch?v=J4dlF0kcThQ">Therapeutic Refactoring by Katrina Owen</a></li> +<li><a href="http://bikeshed.fm/65">Katrina Owen on <em>The Bike Shed</em></a></li> +<li><a href="https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler">Strangler Pattern</a> - A systematic approach to refactoring and decomposing<br /> +large-scale</li> +<li><a href="https://18f.gsa.gov/2014/09/08/the-encasement-strategy-on-legacy-systems-and-the/">The encasement strategy: on legacy systems and the importance of APIs</a></li> +<li><a href="https://www.martinfowler.com/bliki/StranglerApplication.html">Martin Fowler on the Strangler Pattern</a></li> +</ul> + + + + Chris is joined by Kane Baccigalupi, development director from thoughtbot's San Francisco office to discuss Kane's history in government working for 18F and California State and how those experiences have informed Kane's work since.

+ +

Throughout the conversation Chris and Kane discuss their shared desire to hide all implementation details and their love of Ruby for how it allows us to do
+that, testing vs test driven development, and approaches for refactoring large
+untested systems.

+ +

Support The Bike Shed

]]> + + + Chris is joined by Kane Baccigalupi, development director from thoughtbot's San Francisco office to discuss Kane's history in government working for 18F and California State and how those experiences have informed Kane's work since.

+ +

Throughout the conversation Chris and Kane discuss their shared desire to hide all implementation details and their love of Ruby for how it allows us to do
+that, testing vs test driven development, and approaches for refactoring large
+untested systems.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NEpZBMf6 + + ]]> + + + + 168: An Escape Rope of Learning + https://bikeshed.thoughtbot.com/168 + 4c9e92bd-2100-4180-9723-cfa55885e852 + Fri, 31 Aug 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris is joined by Rachel Mathew to discuss Rachel's recent experiences with Scala on a handful of client and side projects. They discuss the benefits of working within a type system, learning to work with a compiler, and the process of getting to know a new language and paradigm. + +Along they way they dip into the complexity of twitter as a platform for discussion and making improvements to development workflows. + 42:19 + no + + <p>Chris is joined by Rachel Mathew to discuss Rachel's recent experiences with<br /> +Scala on a handful of client and side projects. They discuss the benefits of<br /> +working within a type system, learning to work with a compiler, and the process<br /> +of getting to know a new language and paradigm.</p> +<p>Along they way they dip into the complexity of twitter as a platform for<br /> +discussion and making improvements to development workflows.</p> +<ul> +<li><a href="https://www.scala-lang.org/">Scala</a></li> +<li><a href="https://docs.scala-lang.org/tour/implicit-parameters.html">Scala implicits</a></li> +<li><a href="https://kotlinlang.org/">Kotlin</a></li> +<li><a href="https://en.wikipedia.org/wiki/Four_stages_of_competence">Four stages of competence</a></li> +<li><a href="https://www.playframework.com/">Scala Play</a> - Full-featured Scala web framework, comparable to Rails</li> +<li><a href="https://github.com/http4s/http4s">http4s</a> - Lower level Scala web framework</li> +<li><a href="https://en.wikipedia.org/wiki/SOAP">SOAP</a> - An approach to building APIs popular before the focus on REST APIs</li> +<li><a href="https://en.wikipedia.org/wiki/Web_Services_Description_Language">WSDL</a> - Schemas in the land of SOAP</li> +<li><a href="https://github.com/sangria-graphql/sangria">Sangria</a> - Scala GraphQL library</li> +<li><a href="https://neo4j.com/">neo4j</a> - An example of a graph database</li> +<li><a href="http://bikeshed.fm/166">Are Services the New Rewrite?</a> - recent Bike Shed episode discussion<br /> +microservice architecture</li> +<li><a href="http://giantrobots.fm/283">283: Overcoming Awkward Data (Joe Ferris)</a> - Recent Giant Robots episode<br /> +with Joe Ferris discussing &quot;awkward data&quot;</li> +<li><a href="https://github.com/apollographql/apollo-cli#code-generation">GraphQL Code Generation</a></li> +<li><a href="https://robots.thoughtbot.com/announcing-purple-train">Purple Train App</a></li> +</ul> + + + + Chris is joined by Rachel Mathew to discuss Rachel's recent experiences with
+Scala on a handful of client and side projects. They discuss the benefits of
+working within a type system, learning to work with a compiler, and the process
+of getting to know a new language and paradigm.

+ +

Along they way they dip into the complexity of twitter as a platform for
+discussion and making improvements to development workflows.

+ +

Support The Bike Shed

]]> + + + Chris is joined by Rachel Mathew to discuss Rachel's recent experiences with
+Scala on a handful of client and side projects. They discuss the benefits of
+working within a type system, learning to work with a compiler, and the process
+of getting to know a new language and paradigm.

+ +

Along they way they dip into the complexity of twitter as a platform for
+discussion and making improvements to development workflows.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+SqSGM4pe + + ]]> + + + + 167: I Feel Like We Should've Solved This By Now + https://bikeshed.thoughtbot.com/167 + aef672c7-27a0-46c7-b2e1-63f75803f8e5 + Fri, 24 Aug 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris is joined by German Velasco for a discussion ranging from German's recent transition to remote working to the wonders of the Elixir language and the Erlang platform, blockchain, Ethereum, TypeScript, the Language Server Protocol, and more! + 43:36 + no + + <p>Chris is joined by <a href="https://github.com/germsvel">German Velasco</a> for a discussion ranging from German's<br /> +recent transition to remote working to the wonders of the Elixir language and<br /> +the Erlang platform, blockchain, Ethereum, TypeScript, the Language Server<br /> +Protocol, and more!</p> +<ul> +<li><a href="https://github.com/tmate-io/tmate">tmate</a> - shared terminal sessions via a special build of <a href="https://github.com/tmux/tmux">tmux</a></li> +<li><a href="https://sneek.io/">Sneak</a> - Human contact for remote teams (persistent video chat for teams)</li> +<li><a href="https://tomayko.com/blog/2012/adopt-an-open-source-process-constraints">Ryan Tomayko - Your team should work like an open source project</a> - great<br /> +post with actionable advice for teams adopting the remote life</li> +<li><a href="https://medium.com/cylinder-blog/how-to-create-a-distributed-work-culture-b7ca0d59746a">How to Create a Distributed Work Culture</a></li> +<li><a href="https://shift.infinite.red/5-things-that-suck-about-remote-work-506b98dd38f9">5 Things that Suck about Remote Work</a></li> +<li><a href="https://shift.infinite.red/taking-the-pain-out-of-video-conferences-7b7abe822b36">Taking the Pain Out of Video Conferences</a></li> +<li><a href="https://thoughtbot.com/jobs">thoughtbot.com/jobs</a> - Come work with us!</li> +<li><a href="https://elixir-lang.org/">Elixir</a> - The language German loves!</li> +<li><a href="https://elixir-lang.org/getting-started/pattern-matching.html">Pattern matching in Elixir</a></li> +<li><a href="https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system">Hindley–Milner type system</a></li> +<li><a href="http://erlang.org/doc/man/dialyzer.html">dialyzer</a> - Erlang static analysis</li> +<li><a href="https://github.com/erlang/otp">Erlang OTP</a> - a set of Erlang libraries &amp; principles that carry over to<br /> +Elixir</li> +<li><a href="http://wiki.c2.com/?LetItCrash">Erlang &quot;Let It Crash&quot;</a></li> +<li><a href="https://en.wikipedia.org/wiki/Blockchain">Blockchain</a></li> +<li><a href="https://www.ethereum.org/">Ethereum</a></li> +<li><a href="https://en.wikipedia.org/wiki/Proof-of-authority">Proof of Authority</a></li> +<li><a href="https://graphql.org/">GraphQL</a></li> +<li><a href="https://code.visualstudio.com/">VS Code</a></li> +<li><a href="https://langserver.org/">Language Server Protocol</a></li> +<li><a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html">TypeScript 3.0</a></li> +</ul> + + + + Chris is joined by German Velasco for a discussion ranging from German's
+recent transition to remote working to the wonders of the Elixir language and
+the Erlang platform, blockchain, Ethereum, TypeScript, the Language Server
+Protocol, and more!

+ +

Support The Bike Shed

]]> + + + Chris is joined by German Velasco for a discussion ranging from German's
+recent transition to remote working to the wonders of the Elixir language and
+the Erlang platform, blockchain, Ethereum, TypeScript, the Language Server
+Protocol, and more!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+sb24l6aD + + ]]> + + + + 166: Are Services the New Rewrite? + https://bikeshed.thoughtbot.com/166 + 7ba8f608-43f3-4e95-b446-03195fee441e + Fri, 10 Aug 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris & Derek discuss the world of services, exploring the various forms SOA can take, the oft stated benefits, and some of the pitfalls they commonly see in the +wild. The discussion ranges from alternative architectures, guidelines for how to think about services within your platform, and even includes an anecdote about thoughtbot's foray into the world of SOA on Upcase. + 37:17 + no + + <p>Chris &amp; Derek discuss the world of services, exploring the various forms SOA can take, the oft stated benefits, and some of the pitfalls they commonly see in the<br /> +wild. The discussion ranges from alternative architectures, guidelines for how to think about services within your platform, and even includes an anecdote about thoughtbot's foray into the world of SOA on Upcase.</p> +<ul> +<li><a href="https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/">Things You Should Never Do, Part I</a></li> +<li><a href="http://www.michaelnygard.com/blog/2017/12/the-entity-service-antipattern/">The Entity Service Antipattern</a></li> +<li><a href="https://www.youtube.com/watch?v=zMa8rfXI6MM">The Past, Present, and Future of GraphQL Native - Nick Schrock</a></li> +<li><a href="https://github.com/Netflix/chaosmonkey">Netflix - Chaos Monkey</a></li> +<li><a href="https://segment.com/blog/goodbye-microservices/">Goodbye Microservices: From 100s of problem children to 1 superstar (Segment)</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +</ul> + + + + Chris & Derek discuss the world of services, exploring the various forms SOA can take, the oft stated benefits, and some of the pitfalls they commonly see in the
+wild. The discussion ranges from alternative architectures, guidelines for how to think about services within your platform, and even includes an anecdote about thoughtbot's foray into the world of SOA on Upcase.

+ +

Support The Bike Shed

]]> + + + Chris & Derek discuss the world of services, exploring the various forms SOA can take, the oft stated benefits, and some of the pitfalls they commonly see in the
+wild. The discussion ranges from alternative architectures, guidelines for how to think about services within your platform, and even includes an anecdote about thoughtbot's foray into the world of SOA on Upcase.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+G8baBCnH + + ]]> + + + + 165: The Tables Have Turned + https://bikeshed.thoughtbot.com/165 + f1551cf6-3ed5-40a4-8915-4b0bcf8c26f3 + Fri, 03 Aug 2018 11:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris & Derek talk about beginnings and ends, borrowing from their consulting mindset for a conversation spanning CI, deployment, communication, team structure, and everything in between. + 40:33 + no + + <p>Chris &amp; Derek talk about beginnings and ends, borrowing from their consulting mindset for a conversation spanning CI, deployment, communication, team structure, and everything in between.</p> +<ul> +<li><a href="https://robots.thoughtbot.com/bin-setup">bin/setup</a></li> +<li><a href="https://devcenter.heroku.com/articles/active-storage-on-heroku">ActiveStorage confi on heroku</a></li> +<li><a href="https://github.com/rails/rails/pull/30067">Rails encrypted &quot;Credentials&quot;</a></li> +<li><a href="https://12factor.net/">12 Factor App</a></li> +<li><a href="https://youtu.be/xGytDsqkQY8">Semisonic- Closing Time</a></li> +<li><a href="https://github.com/thoughtbot/suspenders/pull/899">Suspenders changes moving to per-topic generators</a></li> +<li>Ruby bug <a href="https://bugs.ruby-lang.org/issues/14373">Methods with more than 32 keyword arguments with default values have some of the arguments set to default despite being passed in.</a></li> +</ul> + + + + Chris & Derek talk about beginnings and ends, borrowing from their consulting mindset for a conversation spanning CI, deployment, communication, team structure, and everything in between.

+ +

Support The Bike Shed

]]> + + + Chris & Derek talk about beginnings and ends, borrowing from their consulting mindset for a conversation spanning CI, deployment, communication, team structure, and everything in between.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+xnKr1vF3 + + ]]> + + + + 164: A Piece of My Identity + https://bikeshed.thoughtbot.com/164 + 98b54f30-1ab8-4c08-b5f9-d5bc656d819a + Fri, 27 Jul 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + + 47:08 + no + + + + Support The Bike Shed

]]> + + + Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Ym5T9xtY + + ]]> + + + + 163: Insert Some Colons For Me + https://bikeshed.thoughtbot.com/163 + 5a7d5ec4-8dd3-4443-ae07-75da5a5d5242 + Fri, 20 Jul 2018 11:00:00 -0400 + thoughtbot + + full + thoughtbot + After Sean confronts some breaking changes to Diesel, we discuss what we like about Visual Studio Code and how changing your tools can change your perspective. + 38:59 + no + + <p>After Sean confronts some breaking changes to Diesel, we discuss what we like about Visual Studio Code and how changing your tools can change your perspective.</p> +<ul> +<li><a href="https://code.visualstudio.com/">Visual Studio Code</a></li> +<li><a href="https://langserver.org/">Language Server Protocol</a></li> +<li><a href="https://github.com/prabirshrestha/vim-lsp">Vim-LSP</a></li> +<li><a href="https://robots.thoughtbot.com/seamlessly-navigate-vim-and-tmux-splits">Seamlessly Navigate Vim and tmux Splits</a></li> +<li><a href="https://github.com/thoughtbot/rcm">rcm: rc file (dotfile) management</a></li> +<li><a href="https://github.com/derekprior/dotfiles/commit/9b2f5e5a1f57b83916a8751a4a7e778b92d24387">Add facility for syncing VSCode extensions</a></li> +<li><a href="https://stackoverflow.com/questions/11828270/how-to-exit-the-vim-editor">How to exit the Vim editor?</a></li> +<li><a href="https://robots.thoughtbot.com/have-you-evaluated-your-toolchain-recently">Have you evaluated your toolchain recently?</a></li> +<li><a href="https://tuple.app/">Tuple</a></li> +</ul> + + + + After Sean confronts some breaking changes to Diesel, we discuss what we like about Visual Studio Code and how changing your tools can change your perspective.

+ +

Support The Bike Shed

]]> + + + After Sean confronts some breaking changes to Diesel, we discuss what we like about Visual Studio Code and how changing your tools can change your perspective.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+fTQDhIzl + + ]]> + + + + 162: You Have Ruined Your Rails App (Sam Phippen) + https://bikeshed.thoughtbot.com/162 + c623eada-9b88-4472-9b4f-49365a012f91 + Fri, 13 Jul 2018 12:00:00 -0400 + thoughtbot + + full + thoughtbot + Sam Phippen joins us to discuss the maintenance burden of supporting old Rubies, service oriented architecture, and explorations of GraphQL and graph databases. + 42:17 + no + + <p>Sam Phippen joins us to discuss the maintenance burden of supporting old Rubies, service oriented architecture, and explorations of GraphQL and graph databases.</p> +<ul> +<li><a href="https://twitter.com/samphippen?lang=en">Sam Phippen on Twitter</a></li> +<li><a href="https://github.com/rspec/rspec-rails/pull/1967">RFC: rspec-rails versioning strategy</a></li> +<li><a href="https://hexdocs.pm/mix/Mix.Tasks.Deps.html#module-options">Mix deps documentation</a></li> +<li><a href="https://en.wikipedia.org/wiki/NP-hardness">NP-hardness</a></li> +<li><a href="https://bundler.io/man/bundle-update.1.html#OPTIONS"><code>bundle update --conservative</code> docs</a></li> +<li><a href="https://sikac.hu/use-create-or-find-by-to-avoid-race-condition-in-rails-6-0-f44fca97d16b">Use create_or_find_by to avoid race condition in Rails 6.0</a></li> +<li><a href="https://dgraph.io/">Dgraph — A Distributed, Fast Graph Database</a></li> +<li><a href="http://bikeshed.fm/100">100: Nouns You Can Verb | The Bike Shed</a> - Sam's previous discussion of GRPC on the podcast</li> +<li><a href="https://www.postgresql.org/docs/current/static/queries-with.html">PostgreSQL: WITH Queries (Common Table Expressions)</a></li> +<li><a href="https://www.digitalocean.com/company/careers/">Work at DigitalOcean</a></li> +<li><a href="https://thoughtbot.com/jobs">Jobs - thoughtbot</a></li> +<li><a href="https://www.shopify.com/careers">Careers and Jobs at Shopify</a></li> +</ul> + + + + Sam Phippen joins us to discuss the maintenance burden of supporting old Rubies, service oriented architecture, and explorations of GraphQL and graph databases.

+ +

Support The Bike Shed

]]> + + + Sam Phippen joins us to discuss the maintenance burden of supporting old Rubies, service oriented architecture, and explorations of GraphQL and graph databases.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4l3tyk8f + + ]]> + + + + 161: Re-Incoherence + https://bikeshed.thoughtbot.com/161 + f66ea053-ec35-4f94-a76e-83e9c04cd235 + Fri, 06 Jul 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Rails performance, rebalancing coherence, and themes from career advice requests. + + 39:50 + no + + <p>Rails performance, rebalancing coherence, and themes from career advice requests.</p> +<ul> +<li><a href="https://twitter.com/codinghorror/status/1002448764630470656?lang=en">Jeff Atwood on Rails performance</a></li> +<li><a href="https://samsaffron.com/archive/2018/06/01/an-analysis-of-memory-bloat-in-active-record-5-2">An analysis of memory bloat in Active Record 5.2</a></li> +<li><a href="http://bikeshed.fm/134">134: Fastributes | The Bike Shed</a></li> +<li><a href="http://bikeshed.fm/17">17: Railing About Performance (Sam Saffron) | The Bike Shed</a></li> +<li><a href="https://github.com/rust-lang/rfcs/pull/2451">Re-Rebalancing Coherence</a></li> +</ul> + + + + Rails performance, rebalancing coherence, and themes from career advice requests.

+ +

Support The Bike Shed

]]> + + + Rails performance, rebalancing coherence, and themes from career advice requests.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+vWkED1KR + + ]]> + + + + 160: Praise Hands Emoji 🙌 (Vaidehi Joshi) + https://bikeshed.thoughtbot.com/160 + 9dc4f1ed-4b6a-4d60-82a3-002818af4627 + Fri, 29 Jun 2018 00:45:00 -0400 + thoughtbot + + full + thoughtbot + We're joined by Vaidehi Joshi to discuss her multimedia empire, conference talk prep, getting started with computer science, and the applicability of a computer science education in every day development work. We wrap the episode with live Q&A from our RailsConf audience. + 47:31 + no + + <p>We're joined by Vaidehi Joshi to discuss her multimedia empire, conference talk prep, getting started with computer science, and the applicability of a computer science education in every day development work. We wrap the episode with live Q&amp;A from our RailsConf audience.</p> +<ul> +<li><a href="https://twitter.com/vaidehijoshi">Vaidehi Joshi on Twitter</a></li> +<li><a href="https://medium.com/basecs">Base CS – The Blog Posts</a></li> +<li><a href="https://www.codenewbie.org/basecs">Base CS - The Podcast</a></li> +<li><a href="https://dev.to/t/basecs">Base CS - The Video Series</a></li> +<li><a href="https://www.youtube.com/watch?v=lEC-QoZeBkM">RailsConf 2018: Re-graphing The Mental Model of The Rails Router by Vaidehi Joshi</a></li> +<li><a href="https://www.deckset.com/">Deckset for Mac: Presentations from Markdown</a></li> +<li><a href="https://www.youtube.com/watch?v=wxPehGkoNOw">RustConf 2017 - Type System Tips for the Real World by Sean Griffin</a></li> +<li><a href="https://www.youtube.com/watch?v=wkfc0Mvg4QY">EmberConf 2018: Closing Keynote by Saron Yitbarek &amp; Vaidehi Joshi</a></li> +<li><a href="https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life">Conway's Game of Life</a></li> +<li><a href="https://www.amazon.com/Understanding-Computation-Machines-Impossible-Programs/dp/1449329276">Understanding Computation: From Simple Machines to Impossible Programs: Tom Stuart</a></li> +<li><a href="http://blog.skylight.io/announcing-the-skylight-for-open-source-program/">Announcing Skylight for Open Source!</a></li> +</ul> + + + + We're joined by Vaidehi Joshi to discuss her multimedia empire, conference talk prep, getting started with computer science, and the applicability of a computer science education in every day development work. We wrap the episode with live Q&A from our RailsConf audience.

+ +

Support The Bike Shed

]]> + + + We're joined by Vaidehi Joshi to discuss her multimedia empire, conference talk prep, getting started with computer science, and the applicability of a computer science education in every day development work. We wrap the episode with live Q&A from our RailsConf audience.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+08-dw2pz + + ]]> + + + + 159: Confusing and Hard to Use + https://bikeshed.thoughtbot.com/159 + 42b13543-d600-42e5-bc27-d1746512e7d0 + Fri, 22 Jun 2018 12:00:00 -0400 + thoughtbot + + full + thoughtbot + An ORM that's a pleasure to use with raw SQL when needed? Sean discusses how that can be. Plus, Derek shares a new and exciting way for migrations to break! + 23:39 + no + + <p>An ORM that's a pleasure to use with raw SQL when needed? Sean discusses how that can be. Plus, Derek shares a new and exciting way for migrations to break!</p> +<ul> +<li><a href="https://github.com/diesel-rs/diesel/releases/tag/v1.3.0">Diesel v1.3.0</a></li> +<li><a href="https://www.youtube.com/watch?v=_wR4NIQNmOI">RailsConf 2018: Up And Down Again: A Migration's Tale by Derek Prior</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveSupport/Inflector.html">ActiveSupport::Inflector</a></li> +</ul> + + + + An ORM that's a pleasure to use with raw SQL when needed? Sean discusses how that can be. Plus, Derek shares a new and exciting way for migrations to break!

+ +

Support The Bike Shed

]]> + + + An ORM that's a pleasure to use with raw SQL when needed? Sean discusses how that can be. Plus, Derek shares a new and exciting way for migrations to break!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+g5MEr-0M + + ]]> + + + + 158: This is How I Ruin Meetings (Aaron Patterson) + https://bikeshed.thoughtbot.com/158 + 8640ef06-9d4c-4d21-b669-60fa511e2a02 + Fri, 15 Jun 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We're joined by Aaron Patterson for puns. Aaron also updates us on compacting GC for Ruby and Ruby 2.6's JIT compiler before telling us how he really feels about functional programming. + 47:01 + no + + <p>We're joined by Aaron Patterson for puns. Aaron also updates us on compacting GC for Ruby and Ruby 2.6's JIT compiler before telling us how he really feels about functional programming.</p> +<ul> +<li><a href="https://twitter.com/tenderlove">Aaron Patterson (@tenderlove) on Twitter</a></li> +<li><a href="https://en.wikipedia.org/wiki/Law_of_triviality">Parkinson's Law of Triviality (The Bike Shed Effect)</a></li> +<li><a href="https://en.wikipedia.org/wiki/Cargo_cult">Cargo Cult</a></li> +<li><a href="https://www.youtube.com/watch?v=8Q7M513vewk">Building a Compacting GC for MRI by Aaron Patterson</a></li> +<li><a href="https://twitter.com/allie_p">Allison McMillan on Twitter</a></li> +<li><a href="https://en.wikipedia.org/wiki/CAR_and_CDR">CAR and CDR</a></li> +<li><a href="https://en.wikipedia.org/wiki/Honeypot_(computing)">Honeypot</a></li> +<li><a href="https://medium.com/@k0kubun/the-method-jit-compiler-for-ruby-2-6-388ee0989c13">The method JIT compiler for Ruby 2.6</a></li> +<li><a href="https://www.youtube.com/watch?v=cBFuZivrdT0">Closing Keynote by Aaron Patterson</a></li> +<li><a href="https://www.youtube.com/watch?v=zKyv-IGvgGE">Opening Keynote: FIXME by David Heinemeier Hansson</a></li> +<li><a href="https://www.youtube.com/watch?v=8evXWvM4oXM">The Future of Rails 6: Scalable by Default by Eileen Uchitelle</a></li> +<li><a href="https://crystal-lang.org/">The Crystal Programming Language</a></li> +</ul> + + + + We're joined by Aaron Patterson for puns. Aaron also updates us on compacting GC for Ruby and Ruby 2.6's JIT compiler before telling us how he really feels about functional programming.

+ +

Support The Bike Shed

]]> + + + We're joined by Aaron Patterson for puns. Aaron also updates us on compacting GC for Ruby and Ruby 2.6's JIT compiler before telling us how he really feels about functional programming.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+tbeBZZZQ + + ]]> + + + + 157: Whiz-Bangy Frontend Thing (Chris Toomey) + https://bikeshed.thoughtbot.com/157 + 6a5cc70d-94bf-400d-9245-4cb6203b3621 + Fri, 08 Jun 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris Toomey joins Derek to talk about their shared experience in Elm and their excitement about GraphQL. + 42:12 + no + + <p>Chris Toomey joins Derek to talk about their shared experience in Elm and their excitement about GraphQL.</p> +<ul> +<li><a href="https://twitter.com/christoomey">Chris on Twitter</a></li> +<li><a href="https://hackernoon.com/the-reader-monad-part-1-1e4d947983a8">The Reader Monad — Part 1</a></li> +<li><a href="https://en.wikipedia.org/wiki/Kind_(type_theory)">Kind (type theory)</a></li> +<li><a href="https://blog.plover.com/prog/burritos.html">Monads are like burritos</a></li> +<li><a href="https://www.scala-js.org/">Scala.js</a></li> +<li><a href="https://graphql.org/">GraphQL | A query language for your API</a></li> +<li><a href="https://tellmewhenitcloses.com/">Tell Me When it Closes</a></li> +<li><a href="https://www.youtube.com/watch?v=HctYHe-YjnE">RailsConf 2017: In Relentless Pursuit of REST by Derek Prior</a></li> +<li><a href="https://thoughtbot.com/jobs">Jobs at thoughtbot</a></li> +<li><a href="https://github.com/graphql/graphiql">graphiql</a></li> +</ul> + + + + Chris Toomey joins Derek to talk about their shared experience in Elm and their excitement about GraphQL.

+ +

Support The Bike Shed

]]> + + + Chris Toomey joins Derek to talk about their shared experience in Elm and their excitement about GraphQL.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+VE8holFo + + ]]> + + + + 156: It's a Commercial Enterprise (Olivier Lacan) + https://bikeshed.thoughtbot.com/156 + a61b23d7-77e0-44d7-8796-63c4c1163b48 + Fri, 01 Jun 2018 11:45:00 -0400 + thoughtbot + + full + thoughtbot + We speak with Olivier Lacan about KeepAChangelog.com, tooling improvements for better developer experience, and the emotional impact of shutting down CodeSchool.com + 41:04 + no + + <p>We speak with Olivier Lacan about KeepAChangelog.com, tooling improvements for better developer experience, and the emotional impact of shutting down CodeSchool.com</p> +<ul> +<li><a href="https://keepachangelog.com/en/1.0.0/">Keep a Changelog</a></li> +<li><a href="https://guides.rubygems.org/specification-reference/">RubyGems Specification Reference</a></li> +<li><a href="https://olivierlacan.com/posts/why-wont-bundle-update/">Why Won't Bundle Update?</a></li> +<li><a href="https://github.com/jmmastey/bundler-stats">bundler-stats</a></li> +<li><a href="https://www.youtube.com/watch?v=zrR181LhOv4">The Life and Death of a Rails App by Olivier Lacan</a></li> +<li><a href="https://techcrunch.com/2015/01/26/online-learning-service-pluralsight-acquires-code-school-for-36-million/">Online Learning Service Pluralsight Acquires Code School For $36 Million</a></li> +<li><a href="https://www.youtube.com/watch?v=eASsqQsaNOA">Human Errors by Olivier Lacan</a></li> +<li><a href="https://github.com/rails/rails/pull/26815">Log the original call site for an ActiveRecord query</a></li> +<li><a href="https://twitter.com/olivierlacan">Olivier on Twitter</a></li> +</ul> + + + + We speak with Olivier Lacan about KeepAChangelog.com, tooling improvements for better developer experience, and the emotional impact of shutting down CodeSchool.com

+ +

Support The Bike Shed

]]> + + + We speak with Olivier Lacan about KeepAChangelog.com, tooling improvements for better developer experience, and the emotional impact of shutting down CodeSchool.com

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+qm7jA89n + + ]]> + + + + 155: Abstractions on Abstractions (Alex Sullivan) + https://bikeshed.thoughtbot.com/155 + dd44b91e-d00b-4d51-9e8a-397e3f82c0e5 + Fri, 25 May 2018 06:00:00 -0400 + thoughtbot + + full + thoughtbot + Amanda is joined by Alex Sullivan, Android developer at thoughtbot, to discuss the state of React Native and its new competitor from Google, Flutter. + 44:09 + no + + <p>Amanda is joined by Alex Sullivan, Android developer at thoughtbot, to discuss the state of React Native and its new competitor from Google, Flutter.</p> +<ul> +<li><a href="https://flutter.io/">Flutter - Beautiful native apps in record time</a></li> +<li><a href="http://www.osnews.com/images/comics/wtfm.jpg">WTFs per minute</a></li> +<li><a href="https://kotlinlang.org/docs/reference/native-overview.html">Kotlin/Native</a></li> +<li><a href="https://images.thoughtbot.com/blog-vellum-image-uploads/UNDRvZ6lSR677HuPluf8_IMG_9902.JPG">thoughtbot's BART sign</a></li> +<li><a href="https://instagram-engineering.com/react-native-at-instagram-dd828a9a90c7">React Native at Instagram</a></li> +<li><a href="https://www.xamarin.com/">Xamarin</a></li> +<li><a href="https://www.youtube.com/watch?v=st1XVfkDWqk&amp;feature=youtu.be">Jake Whorton I/O Talk</a></li> +<li><a href="https://www.youtube.com/watch?v=WVPH48lUzGY">I/O: how to smartly use Fragments in your UI</a></li> +<li><a href="https://www.youtube.com/watch?v=pErTyQpA390">I/O: what's new in Architecture Components</a></li> +<li><a href="https://www.youtube.com/watch?v=eMHsnvhcf78">I/O: What's new in Android</a></li> +</ul> + + + + Amanda is joined by Alex Sullivan, Android developer at thoughtbot, to discuss the state of React Native and its new competitor from Google, Flutter.

+ +

Support The Bike Shed

]]> + + + Amanda is joined by Alex Sullivan, Android developer at thoughtbot, to discuss the state of React Native and its new competitor from Google, Flutter.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+EYQIFPbO + + ]]> + + + + 154: We All Have Work to Do (Eileen Uchitelle) + https://bikeshed.thoughtbot.com/154 + 9ad593e2-1850-4c7d-acde-e90f6af82b79 + Fri, 18 May 2018 01:00:00 -0400 + thoughtbot + + full + thoughtbot + Eileen Uchitelle joins us live from RailsConf to talk about exciting improvements coming to Rails 6, problems encountered by larger Rails apps, strategies for upgrading Rails and more! + 41:07 + no + + <p>Eileen Uchitelle joins us live from RailsConf to talk about exciting improvements coming to Rails 6, problems encountered by larger Rails apps, strategies for upgrading Rails and more!</p> +<ul> +<li><a href="https://twitter.com/eileencodes">Eileen on Twitter</a></li> +<li><a href="http://confreaks.tv/videos/railsconf2018-keynote-the-future-of-rails-6-scalable-by-default">The Future of Rails 6: Scalable by Default</a> - Eileen's RailsConf Keynote</li> +<li><a href="http://bikeshed.fm/22">The Bike Shed #22: No Capes! (Eileen Uchitelle)</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveSupport/PerThreadRegistry.html">ActiveSupport::PerThreadRegistry</a></li> +<li><a href="https://github.com/grosser/parallel_tests">Parallel Tests</a></li> +<li><a href="https://github.com/tmm1/test-queue">Test Queue</a></li> +<li><a href="https://github.com/DatabaseCleaner/database_cleaner">DatabaseCleaner</a></li> +<li><a href="https://github.com/soundcloud/lhm">LHM: Online MySQL schema migrations</a></li> +<li><a href="https://github.com/github/gh-ost">GH-ost: GitHub's Online Schema Migrations for MySQL</a></li> +<li><a href="https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html">pt-online-schema-change</a></li> +<li><a href="https://twitter.com/eileencodes/status/974632238896828417">Eileen removes dead code from GitHub after the Rails 4.2 upgrade</a></li> +<li><a href="https://groups.google.com/forum/#!forum/rubyonrails-security">Ruby on Rails: Security</a></li> +<li><a href="https://railslts.com/">Long term support for Ruby on Rails 3.2 and Rails 2.3</a></li> +</ul> + + + + Eileen Uchitelle joins us live from RailsConf to talk about exciting improvements coming to Rails 6, problems encountered by larger Rails apps, strategies for upgrading Rails and more!

+ +

Support The Bike Shed

]]> + + + Eileen Uchitelle joins us live from RailsConf to talk about exciting improvements coming to Rails 6, problems encountered by larger Rails apps, strategies for upgrading Rails and more!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+u05EGLnW + + ]]> + + + + 153: 🎶 I Would Lose 3,000 Crates, and I Would Lose 12,000 More 🎶 + https://bikeshed.thoughtbot.com/153 + b98f1e2e-d5eb-45f0-8256-4457a27c4533 + Fri, 11 May 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Is the bug in Postgres? Sean takes over operations of crates.io and keeps himself very busy. We also wrap up our experience at RailsConf. + 36:42 + no + + <p>Is the bug in Postgres? Sean takes over operations of crates.io and keeps himself very busy. We also wrap up our experience at RailsConf.</p> +<ul> +<li><a href="https://blog.2ndquadrant.com/logical-replication-postgresql-10/">Logical Replication in PostgreSQL 10</a></li> +<li><a href="https://devcenter.heroku.com/articles/error-codes#h12-request-timeout">Heroku Error Codes: H12</a></li> +<li><a href="https://en.wikipedia.org/wiki/Materialized_view">Materialized view</a></li> +<li><a href="https://stackoverflow.com/questions/28888375/run-a-query-with-a-limit-offset-and-also-get-the-total-number-of-rows">Run a query with a LIMIT/OFFSET and also get the total number of rows</a></li> +<li><a href="http://www.guiasrails.es/active_record_querying.html#retrieving-multiple-objects-in-batches">ActiveRecord: retrieving records in batches</a></li> +</ul> +<p>See <a href="https://goo.gl/cVj7Jm">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of The Bike Shed!</p> + + + + Is the bug in Postgres? Sean takes over operations of crates.io and keeps himself very busy. We also wrap up our experience at RailsConf.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of The Bike Shed!

Support The Bike Shed

]]> + + + Is the bug in Postgres? Sean takes over operations of crates.io and keeps himself very busy. We also wrap up our experience at RailsConf.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of The Bike Shed!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+9rJtS9LN + + ]]> + + + + 152: I Look For Stories (Nickolas Means) + https://bikeshed.thoughtbot.com/152 + cecc83e6-4e6e-4304-8fa3-eecb5298bb6d + Fri, 04 May 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We catch up with Nick Means at RailsConf and discuss storytelling, "human error", advice for job seekers, and the idea of licensing software developers. + 31:13 + no + + <p>We catch up with Nick Means at RailsConf and discuss storytelling, &quot;human error&quot;, advice for job seekers, and the idea of licensing software developers.</p> +<ul> +<li><a href="https://twitter.com/nmeans">Nick on Twitter</a></li> +<li><a href="http://bikeshed.fm/71">The Bike Shed #71: It's a Total Hack</a> - Our earlier episode discussing Nick's previous keynote at RailsConf</li> +<li><a href="https://www.youtube.com/watch?v=ggPE-JHzfAM&amp;index=2&amp;list=PLE7tQUdRKcyZGYLfj6oRQWPxB6ijg1YsC">Skunk Works by Nickolas Means</a></li> +<li><a href="https://amzn.to/2HNvaW5">Skunk Works: A Personal Memoir of My Years at Lockheed</a></li> +<li><a href="https://amzn.to/2rdLglF">The Field Guide to Understanding 'Human Error'</a></li> +<li><a href="https://amzn.to/2JPZ0JY">Atomic Accidents: A History of Nuclear Meltdowns and Disasters</a></li> +<li><a href="https://www.retroreport.org/video/major-malfunction-lessons-from-challenger/">Retro Report | Go or no Go: The Challenger Legacy</a></li> +<li><a href="https://en.wikipedia.org/wiki/Three_Mile_Island_accident">Three Mile Island accident</a></li> +<li><a href="https://www.nytimes.com/2018/04/18/business/southwest-plane-engine-failure.html">Southwest’s Fatal Accident Prompts Scrutiny of Engine Inspections</a></li> +<li><a href="https://static01.nyt.com/images/2018/04/19/reader-center/20xp-masks/20xp-masks-master768.jpg">People wearing oxygen masks wrong</a></li> +<li><a href="https://xkcd.com/303/">xkcd: Compiling</a></li> +<li><a href="https://www.amazon.com/Making-Atomic-Bomb-25th-Anniversary/dp/1451677618">The Making of the Atomic Bomb: 25th Anniversary Edition</a></li> +<li><a href="https://www.calebthompson.io/talks/dont-get-distracted">Don't Get Distracted - Caleb Thompson</a></li> +</ul> + + + + We catch up with Nick Means at RailsConf and discuss storytelling, "human error", advice for job seekers, and the idea of licensing software developers.

+ +

Support The Bike Shed

]]> + + + We catch up with Nick Means at RailsConf and discuss storytelling, "human error", advice for job seekers, and the idea of licensing software developers.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4N0LZQ5U + + ]]> + + + + 151: Scheming About Schema + https://bikeshed.thoughtbot.com/151 + 3acad438-4f08-45b3-8979-6aee00caa4d7 + Fri, 27 Apr 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek & Sean discuss their final preparations for RailsConf, the role of Diesel's `schema.rs` is in comparison to `schema.rb` in Rails, and how Derek took down production. + 35:11 + no + + <p>Derek &amp; Sean discuss their final preparations for RailsConf, the role of Diesel's <code>schema.rs</code> is in comparison to <code>schema.rb</code> in Rails, and how Derek took down production.</p> +<ul> +<li><a href="https://www.vox.com/2018/4/10/17207588/american-chopper-meme">The American Chopper meme, explained</a></li> +<li><a href="https://www.papercall.io/">PaperCall.io</a></li> +<li><a href="http://diesel.rs/guides/schema-in-depth/">Diesel schema in depth</a></li> +</ul> + + + + Derek & Sean discuss their final preparations for RailsConf, the role of Diesel's schema.rs is in comparison to schema.rb in Rails, and how Derek took down production.

+ +

Support The Bike Shed

]]> + + + Derek & Sean discuss their final preparations for RailsConf, the role of Diesel's schema.rs is in comparison to schema.rb in Rails, and how Derek took down production.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+rWUAVYsc + + ]]> + + + + 150: I Fight For the Users + https://bikeshed.thoughtbot.com/150 + bfad90d3-1141-497f-9f60-cb7802ae5399 + Fri, 13 Apr 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss ethical concerns in software development and the prospect of licensing software developers. + 47:27 + no + + <p>Derek and Sean discuss ethical concerns in software development and the prospect of licensing software developers.</p> +<ul> +<li><a href="https://dataplan.xfinity.com/">XFINITY Data Usage Center</a></li> +<li><a href="https://www.gimletmedia.com/reply-all/118#episode-player">Reply All: A Pirate in Search of a Judge</a></li> +<li><a href="https://medium.com/@monteiro/designs-lost-generation-ac7289549017">Design’s Lost Generation</a></li> +<li><a href="https://www.vox.com/policy-and-politics/2018/3/21/17141428/cambridge-analytica-trump-russia-mueller">Cambridge Analytica scandals, explained</a></li> +<li><a href="https://www.huffingtonpost.com/2014/01/08/outed-on-facebook_n_4563522.html">Blogger Bobbie Duncan Recalls Getting Outed Accidentally On Facebook</a></li> +<li><a href="https://www.bloomberg.com/news/articles/2018-04-12/tesla-draws-rebuke-for-blaming-autopilot-death-on-model-x-driver">Tesla Criticized for Blaming Autopilot Death on Model X Driver</a></li> +<li><a href="https://www.caranddriver.com/news/self-driving-mercedes-will-prioritize-occupant-safety-over-pedestrians">Self-Driving Mercedes-Benzes Will Prioritize Occupant Safety over Pedestrians</a></li> +<li><a href="https://www.eugdpr.org/">GDPR</a></li> +<li><a href="https://robots.thoughtbot.com/bike-shed-railsconf-2018">The Bike Shed at RailsConf 2018</a></li> +</ul> + + + + Derek and Sean discuss ethical concerns in software development and the prospect of licensing software developers.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss ethical concerns in software development and the prospect of licensing software developers.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+YblLf2GW + + ]]> + + + + 149: E With an Umlaut + https://bikeshed.thoughtbot.com/149 + 037d45c5-2968-4a2e-9b49-2d171a099a70 + Fri, 06 Apr 2018 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean experiences a frustrating Ruby bug while building tooling to enforce module boundaries in Shopfiy's monolith. Derek deprecates Rails functionality instead of preparing his talk. + 33:26 + no + + <p>Sean experiences a frustrating Ruby bug while building tooling to enforce module boundaries in Shopfiy's monolith. Derek deprecates Rails functionality instead of preparing his talk.</p> +<ul> +<li><a href="https://ruby-doc.org/core-2.5.0/TracePoint.html"><code>TracePoint</code> documentation</a></li> +<li><a href="http://unicode.org/reports/tr15/">Unicode Normalization Forms</a></li> +<li><a href="https://buildkite.com/">Buildkite</a></li> +<li><a href="https://thepugautomatic.com/2013/08/struct-inheritance-is-overused/">Struct inheritance is overused</a></li> +<li><a href="https://github.com/rails/rails/pull/32277">Deprecate controller level force_ssl</a></li> +<li><a href="https://dataplan.xfinity.com/faq/">XFINITY Data Usage Center — FAQ</a></li> +</ul> + + + + Sean experiences a frustrating Ruby bug while building tooling to enforce module boundaries in Shopfiy's monolith. Derek deprecates Rails functionality instead of preparing his talk.

+ +

Support The Bike Shed

]]> + + + Sean experiences a frustrating Ruby bug while building tooling to enforce module boundaries in Shopfiy's monolith. Derek deprecates Rails functionality instead of preparing his talk.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+tzvSIaL9 + + ]]> + + + + 148: Baseball is a Legacy App + https://bikeshed.thoughtbot.com/148 + cd7c8291-c941-41c2-8407-8a0a73856a2e + Fri, 30 Mar 2018 17:00:00 -0400 + thoughtbot + + full + thoughtbot + Amanda and Sean discuss Flutter, modeling the game of baseball, and the state of persistence and networking in Android. + 36:48 + no + + <p>Amanda and Sean discuss Flutter, modeling the game of baseball, and the state of persistence and networking in Android.</p> +<ul> +<li><a href="https://flutter.io/">Flutter - Beautiful native apps in record time</a></li> +<li><a href="https://www.dartlang.org/">Dart programming language</a></li> +<li><a href="https://en.wikipedia.org/wiki/Functional_reactive_programming">Functional reactive programming (FRP)</a></li> +<li><a href="https://www.vuforia.com/">Vuforia | Augmented Reality</a></li> +<li><a href="https://en.wikipedia.org/wiki/Baseball_scorekeeping">Baseball scorekeeping</a></li> +<li><a href="https://developer.android.com/topic/libraries/architecture/room.html">Room Persistence Library</a></li> +<li><a href="https://square.github.io/okhttp/">OkHttp</a></li> +<li><a href="https://manishearth.github.io/blog/2017/01/14/stop-ascribing-meaning-to-unicode-code-points/">Let’s Stop Ascribing Meaning to Code Points</a></li> +</ul> + + + + Amanda and Sean discuss Flutter, modeling the game of baseball, and the state of persistence and networking in Android.

+ +

Support The Bike Shed

]]> + + + Amanda and Sean discuss Flutter, modeling the game of baseball, and the state of persistence and networking in Android.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+2UaOjZue + + ]]> + + + + 147: Is a Lambda a Sandwich? + https://bikeshed.thoughtbot.com/147 + 1b545f7e-d170-4623-bec5-d427ecbeffa5 + Fri, 23 Mar 2018 11:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek shares his experiences with new features in Ruby 2.5 before we turn our ire towards daylight savings time and timezones once more. + 34:58 + no + + <p>Derek shares his experiences with new features in Ruby 2.5 before we turn our ire towards daylight savings time and timezones once more.</p> +<ul> +<li><a href="https://robots.thoughtbot.com/using-yieldself-for-composable-activerecord-relations">Using <code>yield_self</code> for composable ActiveRecord relations</a></li> +<li><a href="http://awaxman11.github.io/blog/2013/08/05/what-is-the-difference-between-a-block/">What is the difference between a block, a proc, and a lambda in ruby?</a></li> +<li><a href="https://blog.bigbinary.com/2018/03/07/ruby-2-5-prints-backstrace-and-error-message-in-reverse-order.html">Ruby 2.5 prints backtrace and error message in reverse order</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/SpawnMethods.html#method-i-merge">ActiveRecord <code>#merge</code></a></li> +<li><a href="https://twitter.com/sgrif/status/974062373769129989">Sean's Formulas</a></li> +<li><a href="https://www.youtube.com/watch?v=-J1NHzQ1sgc">Changed Timezones (The West Wing)</a></li> +<li><a href="https://www.boston.com/news/local-news/2017/11/05/new-england-atlantic-time-zone">Could New England actually change time zones?</a></li> +<li><a href="https://en.wikipedia.org/wiki/Pi_Day">Pi Day - Wikipedia</a></li> +<li><a href="https://www.postgresql.org/docs/current/static/functions-datetime.html">PostgreSQL Date/Time Functions and Operators</a></li> +</ul> + + + + Derek shares his experiences with new features in Ruby 2.5 before we turn our ire towards daylight savings time and timezones once more.

+ +

Support The Bike Shed

]]> + + + Derek shares his experiences with new features in Ruby 2.5 before we turn our ire towards daylight savings time and timezones once more.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+PuXmFoMR + + ]]> + + + + 146: --YOLO + https://bikeshed.thoughtbot.com/146 + 3e6f26a4-4193-457a-889d-f18f085159a4 + Fri, 16 Mar 2018 12:45:00 -0400 + thoughtbot + + full + thoughtbot + Amanda, Derek, and Sean discuss style guides, automated code formatting, and the cycle of disillusionment in development work. + 29:54 + no + + <p>Amanda, Derek, and Sean discuss style guides, automated code formatting, and the cycle of disillusionment in development work.</p> +<ul> +<li><a href="https://github.com/avh4/elm-format">elm-format</a></li> +<li><a href="https://github.com/stil4m/elm-analyse">elm-analyse</a></li> +<li><a href="https://android.github.io/kotlin-guides/style.html">Android Kotlin Style Guide</a></li> +<li><a href="https://swift.org/documentation/api-design-guidelines/">Swift API Design Guidelines</a></li> +<li><a href="https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_move_away_from_elm/">Do we need to move away from Elm?</a></li> +<li><a href="https://discourse.elm-lang.org/t/native-code-in-0-19/826">&quot;Native Code&quot; in Elm 0.19</a></li> +<li><a href="https://android.jlelse.eu/android-performance-avoid-using-enum-on-android-326be0794dc3">Android Performance: Avoid using ENUM on Android</a></li> +</ul> + + +

Amanda, Derek, and Sean discuss style guides, automated code formatting, and the cycle of disillusionment in development work.

+ +

Support The Bike Shed

]]> + + +

Amanda, Derek, and Sean discuss style guides, automated code formatting, and the cycle of disillusionment in development work.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+28j_jTBY + + ]]> + + + + 145: The Internet is Ruined + https://bikeshed.thoughtbot.com/145 + 57d5f2bf-f9e5-42f1-9109-fe252dc16ae8 + Fri, 09 Mar 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean commiserate about the latest generation of MacBooks, Slack, and the state of the Web. + 35:56 + no + + <p>Derek and Sean commiserate about the latest generation of MacBooks, Slack, and the state of the Web.</p> +<ul> +<li><a href="https://en.wikipedia.org/wiki/SoftRAM">SoftRAM</a></li> +<li><a href="https://github.com/thoughtbot/laptop">thoughtbot/laptop: A shell script to set up a macOS laptop for web and mobile development.</a></li> +<li><a href="https://github.com/derekprior/dotfiles">derekprior/dotfiles</a></li> +<li><a href="https://www.washingtonpost.com/news/the-switch/wp/2018/02/13/salon-com-wants-to-fight-ad-blockers-by-using-your-pc-to-mine-cryptocurrency/?utm_term=.d9fc6cfba1e5">Salon.com wants to use your PC to mine cryptocurrency</a></li> +<li><a href="https://brave.com/">Brave: Secure, Fast &amp; Private Web Browser with Adblocker</a></li> +<li><a href="https://blog.branch.io/ios-11-safari-view-controller-cookie-passthrough-and-the-future-of-mobile-web/">iOS 11 Safari View Controller cookie passthrough</a></li> +<li><a href="https://thoughtbot.com/resources">Purpose-built - thoughtbot</a></li> +<li><a href="https://en.wikipedia.org/wiki/Internet2">Internet2</a></li> +</ul> + + + + Derek and Sean commiserate about the latest generation of MacBooks, Slack, and the state of the Web.

+ +

Support The Bike Shed

]]> + + + Derek and Sean commiserate about the latest generation of MacBooks, Slack, and the state of the Web.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+dv9lE5UC + + ]]> + + + + 144: Fisher Price™ Tools + https://bikeshed.thoughtbot.com/144 + ff4ebf1e-5931-4c00-ad13-f701f1d2e466 + Fri, 02 Mar 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We talk about everyone's favorite Fisher-Price web framework and a small upcoming change to it before pivoting to discuss Derek's experience with his first Elm PR. + 29:04 + no + + <p>We talk about everyone's favorite Fisher-Price web framework and a small upcoming change to it before pivoting to discuss Derek's experience with his first Elm PR.</p> +<ul> +<li><a href="http://railsconf.com/schedule">RailsConf 2018 Schedule</a></li> +<li><a href="https://www.vanityfair.com/news/2018/02/how-twitter-lost-the-internet-war">“Just an Ass-Backward Tech Company”: How Twitter Lost the Internet War</a></li> +<li><a href="https://twitter.com/JEG2/status/965947283207573507">James Edward Gray II on Twitter's use of Rails</a></li> +<li><a href="https://sikac.hu/use-create-or-find-by-to-avoid-race-condition-in-rails-6-0-f44fca97d16b">Use <code>create_or_find_by</code> to avoid race condition in Rails 6.0</a></li> +<li><a href="https://sourcemaking.com/refactoring/smells/shotgun-surgery">Shotgun Surgery</a></li> +<li><a href="https://spaceflight.nasa.gov/shuttle/reference/shutref/verboseindex.html">Shuttle Reference Manual</a></li> +<li><a href="https://ksp-kos.github.io/KOS/index.html">kOS: Kerbal Operating System</a></li> +</ul> + + + + We talk about everyone's favorite Fisher-Price web framework and a small upcoming change to it before pivoting to discuss Derek's experience with his first Elm PR.

+ +

Support The Bike Shed

]]> + + + We talk about everyone's favorite Fisher-Price web framework and a small upcoming change to it before pivoting to discuss Derek's experience with his first Elm PR.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+h0feM_wO + + ]]> + + + + 143: It's Hard to Have a Secret Rocket + https://bikeshed.thoughtbot.com/143 + 2796c6fe-10a6-4625-8288-07c1d77f3872 + Fri, 16 Feb 2018 10:00:00 -0500 + thoughtbot + + full + thoughtbot + We chat about the Falcon Heavy launch before discussing a couple of issues Derek encountered when upgrading to Rails 5.2 + 31:40 + no + + <p>We chat about the Falcon Heavy launch before discussing a couple of issues Derek encountered when upgrading to Rails 5.2</p> +<ul> +<li><a href="https://qzprod.files.wordpress.com/2018/02/tesla-spacex-starman-falcon-heavy-rocket-elon-musk.jpg?quality=80&amp;strip=all&amp;w=3200">Starman</a></li> +<li><a href="https://cdn.teslarati.com/wp-content/uploads/2018/02/spacex-falcon-heavy-double-landing.gif">Double rocket landing</a></li> +<li><a href="http://weblog.rubyonrails.org/2018/1/30/Rails-5-2-RC1-Active-Storage-Redis-Cache-Store-HTTP2-Early-Hints-Credentials/">Rails 5.2.0 RC1: Active Storage, Redis Cache Store, HTTP/2 Early Hints, CSP, Credentials</a></li> +<li><a href="https://github.com/rails/rails/pull/27947">Disallow raw SQL in dangerous AR methods</a></li> +<li><a href="http://edgeguides.rubyonrails.org/active_storage_overview.html">Active Storage Overview — Ruby on Rails Guides</a></li> +</ul> + + + + We chat about the Falcon Heavy launch before discussing a couple of issues Derek encountered when upgrading to Rails 5.2

+ +

Support The Bike Shed

]]> + + + We chat about the Falcon Heavy launch before discussing a couple of issues Derek encountered when upgrading to Rails 5.2

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+C_6-tUYs + + ]]> + + + + 142: What if We Didn't Do Any of This? + https://bikeshed.thoughtbot.com/142 + c1b1c635-aacc-4a27-a295-6a9760652db8 + Fri, 09 Feb 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean debate the value provided by database migrations written in your programming language of choice versus those written in SQL. + 42:00 + no + + <p>Derek and Sean debate the value provided by database migrations written in your programming language of choice versus those written in SQL.</p> +<ul> +<li><a href="https://railsconf.com/">RailsConf 2018</a></li> +<li><a href="https://dev.mysql.com/doc/refman/5.7/en/timestamp-initialization.html">MySQL Automatic Updating for TIMESTAMP and DATETIME</a></li> +<li><a href="https://github.com/cockroachdb/cockroach">CockroachDB - the open source, cloud-native SQL database.</a></li> +<li><a href="https://luckyframework.org/guides/database-migrations/">Lucky Migrations in Crystal</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/Migration.html#method-i-reversible">ActiveRecord::Migration <code>reversible</code></a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/Migration.html#method-i-revert">ActiveRecord::Migration <code>revert</code></a></li> +<li><a href="https://github.com/thoughtbot/parity">Parity: Shell commands for development, staging, and production parity for Heroku apps</a></li> +</ul> + + + + Derek and Sean debate the value provided by database migrations written in your programming language of choice versus those written in SQL.

+ +

Support The Bike Shed

]]> + + + Derek and Sean debate the value provided by database migrations written in your programming language of choice versus those written in SQL.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+vLoEjvLb + + ]]> + + + + 141: Go Baby, Go + https://bikeshed.thoughtbot.com/141 + dfde0fc1-54d4-4baf-9174-4b99ce77418b + Thu, 01 Feb 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We discuss the challenges in parallelizing development work and also take a look at what's coming soon in Rails 5.2. + 31:11 + no + + <p>We discuss the challenges in parallelizing development work and also take a look at what's coming soon in Rails 5.2.</p> +<ul> +<li><a href="https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959">The Mythical Man-Month: Essays on Software Engineering</a></li> +<li><a href="https://en.wikipedia.org/wiki/Hype_cycle">Hype cycle</a></li> +<li><a href="https://en.wikipedia.org/wiki/Write_once,_run_anywhere">Write once, run anywhere</a></li> +<li><a href="https://github.com/rails/rails/tree/master/activestorage">ActiveStorage</a></li> +<li><a href="https://github.com/thoughtbot/paperclip">Paperclip</a></li> +<li><a href="http://weblog.rubyonrails.org/2018/1/30/Rails-5-2-RC1-Active-Storage-Redis-Cache-Store-HTTP2-Early-Hints-Credentials/">Rails 5.2.0 RC1</a></li> +<li><a href="https://thoughtbot.workable.com/j/5C8FE1B71A">Work at thoughtbot</a></li> +</ul> + + + + We discuss the challenges in parallelizing development work and also take a look at what's coming soon in Rails 5.2.

+ +

Support The Bike Shed

]]> + + + We discuss the challenges in parallelizing development work and also take a look at what's coming soon in Rails 5.2.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Fkoif13k + + ]]> + + + + 140: A Sign of... Stability? + https://bikeshed.thoughtbot.com/140 + 997d3919-0812-4ab8-9cf5-963308d3e23e + Thu, 25 Jan 2018 12:00:00 -0500 + thoughtbot + + full + thoughtbot + Sean and Derek argue the semantics of versioning and opine for automated reporting on more structured changelogs as a feature of future package managers. + 43:01 + no + + <p>Sean and Derek argue the semantics of versioning and opine for automated reporting on more structured changelogs as a feature of future package managers.</p> +<ul> +<li><a href="https://github.com/nox/rust-rfcs/blob/master/text/1105-api-evolution.md">Rust API Evolution Guide</a></li> +<li><a href="http://www.prioritized.net/blog/embracing-promiscuous-gemfiles">Embracing Promiscuous Gemfiles</a></li> +<li><a href="http://bundler.io/v1.3/bundle_outdated.html"><code>bundle outdated</code></a></li> +<li><a href="https://hex.pm/docs/tasks#hex_outdated"><code>mix hex.outdated</code></a></li> +<li><a href="http://keepachangelog.com/en/1.0.0/">Keep a Changelog</a></li> +</ul> + + + + Sean and Derek argue the semantics of versioning and opine for automated reporting on more structured changelogs as a feature of future package managers.

+ +

Support The Bike Shed

]]> + + + Sean and Derek argue the semantics of versioning and opine for automated reporting on more structured changelogs as a feature of future package managers.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ZmUiMmlJ + + ]]> + + + + 139: Red, Green, Refactor (Alex Clark & Sean Doyle) + https://bikeshed.thoughtbot.com/139 + 8624ce06-165c-40b5-95fb-e76999ae2ec9 + Fri, 19 Jan 2018 10:15:00 -0500 + thoughtbot + + full + thoughtbot + Derek is joined by coworker Sean Doyle and Codecademy’s Alex Clark to discuss the process of test-driven development and the development of a new TDD course for Codecademy. + 33:08 + no + + <p>Derek is joined by coworker Sean Doyle and Codecademy’s Alex Clark to discuss the process of test-driven development and the development of a new TDD course for Codecademy.</p> +<ul> +<li><a href="https://gumroad.com/l/testing-rails/?utm_campaign=announcement&amp;utm_medium=blog&amp;utm_source=giant-robots">Testing Rails</a></li> +<li><a href="https://robots.thoughtbot.com/four-phase-test">Four-Phase Test</a></li> +<li><a href="https://www.codecademy.com/pro/intensive/test-driven-development?utm_source=thoughtbot&amp;utm_medium=podcast&amp;utm_campaign=tdd&amp;utm_content=thebikeshed">Test-Driven Development Course on Codecademy</a></li> +<li><a href="http://www.jamesshore.com/Blog/Red-Green-Refactor.html">Red-Green-Refactor</a></li> +<li><a href="http://chaijs.com/">Chai</a></li> +<li><a href="http://webdriver.io/">WebdriverIO</a> - WebDriver bindings for Node.js</li> +<li><a href="https://github.com/visionmedia/supertest">SuperTest</a> - Super-agent driven library for testing node.js HTTP servers using a fluent API</li> +</ul> + + + + Derek is joined by coworker Sean Doyle and Codecademy’s Alex Clark to discuss the process of test-driven development and the development of a new TDD course for Codecademy.

+ +

Support The Bike Shed

]]> + + + Derek is joined by coworker Sean Doyle and Codecademy’s Alex Clark to discuss the process of test-driven development and the development of a new TDD course for Codecademy.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1j4MOyeb + + ]]> + + + + 138: I Don't Know How the World Works Anymore + https://bikeshed.thoughtbot.com/138 + a497495f-06df-4767-bc13-c152bf9e70a2 + Fri, 12 Jan 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We chat about how shared global state in tests can cause you to doubt foundational truths of the universe, some issues with Rails system tests, and recent changes in browser behavior. + 48:00 + no + + <p>We chat about how shared global state in tests can cause you to doubt foundational truths of the universe, some issues with Rails system tests, and recent changes in browser behavior.</p> +<ul> +<li><a href="https://medium.com/@sgrif/announcing-diesel-1-0-a-safe-extensible-query-builder-and-orm-15e6bd8a9ed0">Announcing Diesel 1.0</a> - Congratulations to Sean and all committers.</li> +<li><a href="https://twitter.com/PragTob/status/947868743195152385">Where do Rubyists Go?</a></li> +<li><a href="https://github.com/alexreisner/geocoder#testing-apps-that-use-geocoder">Testing apps that use Geocoder</a></li> +<li><a href="https://www.postgresql.org/list/">PostgreSQL Mailing List Archives</a></li> +<li><a href="https://github.com/rails/rails/pull/31384">Respect user-set <code>Capybara.server</code> with Rails system tests</a></li> +<li><a href="https://github.com/rails/rails/pull/30638">Default Puma to non-clustered mode with Rails system tests</a></li> +<li><a href="https://github.com/thoughtbot/suspenders">Suspenders</a></li> +<li><a href="https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/">Chrome 63 forces .dev domains to HTTPS via preloaded HSTS</a></li> +<li><a href="https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robot-arg-plugin-firefox-looking-glass">Mozilla faces blowback after slipping Mr Robot plugin into Firefox - The Verge</a></li> +<li><a href="https://www.janbambas.cz/firefox-57-delays-requests-tracking-domains/">Firefox 57 delays requests to tracking domains</a></li> +</ul> + + + + We chat about how shared global state in tests can cause you to doubt foundational truths of the universe, some issues with Rails system tests, and recent changes in browser behavior.

+ +

Support The Bike Shed

]]> + + + We chat about how shared global state in tests can cause you to doubt foundational truths of the universe, some issues with Rails system tests, and recent changes in browser behavior.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GEgzfqMH + + ]]> + + + + 137: What's Up, Docs + https://bikeshed.thoughtbot.com/137 + f547c984-628b-4d8c-9e1e-3ddebbcb2ab2 + Fri, 05 Jan 2018 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Who should library documentation be written for? How do you, as an author, know what your users will need to know? Should you have long form guides in addition to API documentation? We ask and answer these questions in the context of Sean's work to document Diesel 1.0. + +Stick around for the spoiler-filled after show about Star Wars: The Last Jedi. + 48:43 + no + + <p>Who should library documentation be written for? How do you, as an author, know what your users will need to know? Should you have long form guides in addition to API documentation? We ask and answer these questions in the context of Sean's work to document Diesel 1.0.</p> +<p>Stick around for the spoiler-filled after show about <em>Star Wars: The Last Jedi</em>.</p> +<ul> +<li><a href="http://diesel.rs/guides/">Diesel Guides</a></li> +<li><a href="https://www.postgresql.org/docs/10/static/sql-prepare.html">Prepared Statements</a></li> +<li><a href="http://docs.diesel.rs/diesel/index.html">Diesel Documentation</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord.html">ActiveRecord Root Documentation</a></li> +</ul> + + + + Who should library documentation be written for? How do you, as an author, know what your users will need to know? Should you have long form guides in addition to API documentation? We ask and answer these questions in the context of Sean's work to document Diesel 1.0.

+ +

Stick around for the spoiler-filled after show about Star Wars: The Last Jedi.

+ +

Support The Bike Shed

]]> + + + Who should library documentation be written for? How do you, as an author, know what your users will need to know? Should you have long form guides in addition to API documentation? We ask and answer these questions in the context of Sean's work to document Diesel 1.0.

+ +

Stick around for the spoiler-filled after show about Star Wars: The Last Jedi.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+W-T2SArJ + + ]]> + + + + 136: Propagating Conspiracy Theories + https://bikeshed.thoughtbot.com/136 + 66295ee7-68af-4a40-ba00-367fe4e94eb6 + Fri, 22 Dec 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Amanda joins Derek to discuss KotlinConf, powerful IDEs, our Ralphapalooza hackathon, and the React Native experience from a native mobile developer's perspective. + 38:23 + no + + <p>Amanda joins Derek to discuss KotlinConf, powerful IDEs, our Ralphapalooza hackathon, and the React Native experience from a native mobile developer's perspective.</p> +<ul> +<li><a href="https://www.youtube.com/watch?v=Vre-Ih5Gdc0">A View State Machine for Network Calls on Android</a> - Amanda's KotlinConf talk</li> +<li><a href="https://www.youtube.com/watch?v=FDOECr-sT6U">How to Build a React App in Kotlin by Dave Ford</a></li> +<li><a href="https://www.youtube.com/watch?v=p8yX5-lPS6o">Kotlin Static Analysis with Android Lint by Tor Norbye</a></li> +<li><a href="https://www.jetbrains.com/resharper/">ReSharper: Visual Studio Extension for .NET Developers</a></li> +<li><a href="https://github.com/thoughtbot/trail-map">thoughtbot Trail Maps</a></li> +<li><a href="https://luckyframework.org/">Lucky</a> - a web framework for Crystal</li> +<li><a href="https://frinkiac.com/">Frinkiac</a></li> +<li><a href="https://www.instagram.com/p/BcgO4FYj74r/">thoughtbot does screen printing</a></li> +<li><a href="https://www.youtube.com/watch?v=juz0GcBkwxo&amp;feature=youtu.be">The Pixar Theory</a></li> +<li><a href="https://www.cbssports.com/mlb/news/mlb-twitter-thinks-something-fishy-is-going-on-with-jeter-trading-stanton-to-yankees/">MLB Twitter thinks something fishy is going on with Jeter trading Stanton to Yankees - CBSSports.com</a></li> +<li><a href="https://github.com/necolas/react-native-web">React Native Web</a></li> +</ul> + + + + Amanda joins Derek to discuss KotlinConf, powerful IDEs, our Ralphapalooza hackathon, and the React Native experience from a native mobile developer's perspective.

+ +

Support The Bike Shed

]]> + + + Amanda joins Derek to discuss KotlinConf, powerful IDEs, our Ralphapalooza hackathon, and the React Native experience from a native mobile developer's perspective.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+l0fYOg9j + + ]]> + + + + 135: A Series of Unfortunate Examples + https://bikeshed.thoughtbot.com/135 + c7367f25-0b1f-47dd-9999-ce0025443b5b + Wed, 13 Dec 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We discuss a possible ActiveRecord bug Derek encountered and explore the ambiguity of SQL formatting best practices. + 33:12 + no + + <p>We discuss a possible ActiveRecord bug Derek encountered and explore the ambiguity of SQL formatting best practices.</p> +<ul> +<li><a href="https://thoughtbot.com/podcasts">thoughtbot podcast swag</a></li> +<li><a href="https://gist.github.com/derekprior/03ad1f7fd4537321cd6ee7100f95e453">Working around ActiveRecord joining the same table twice</a></li> +<li><a href="https://github.com/rust-lang/crates.io/blob/82ac341240d02892b2f865b2f5a075d36471ee24/src/pagination.rs#L33-L38">Pagination in Crates.io</a></li> +<li><a href="https://github.com/rails/rails/commit/d3688e02ca52c0b72d3092e8498da51e06b7fc58">ActiveRecord auto-explain removed in Rails 4.0</a></li> +<li><a href="https://github.com/darold/pgFormatter">pgFormatter: A PostgreSQL SQL syntax beautifier</a></li> +<li><a href="https://github.com/rust-lang/crates.io/blob/82ac341240d02892b2f865b2f5a075d36471ee24/src/krate/krate_reverse_dependencies.sql">How would you format this SQL query?</a></li> +</ul> + + + + We discuss a possible ActiveRecord bug Derek encountered and explore the ambiguity of SQL formatting best practices.

+ +

Support The Bike Shed

]]> + + + We discuss a possible ActiveRecord bug Derek encountered and explore the ambiguity of SQL formatting best practices.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+gp4rL5_L + + ]]> + + + + 134: Fastributes + https://bikeshed.thoughtbot.com/134 + 360f59c9-2a71-4375-9ed1-878f6bbeb910 + Fri, 08 Dec 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We share our favorite talks from RubyConf and discuss how Sean has made ActiveRecord attributes allocation significantly faster with Rust. + 31:24 + no + + <p>We share our favorite talks from RubyConf and discuss how Sean has made ActiveRecord attributes allocation significantly faster with Rust.</p> +<ul> +<li><a href="http://confreaks.tv/videos/rubyconf2017-saving-ruby-from-the-apocalypse">Saving Ruby From the Apocalypse</a> by Jason Charnes</li> +<li><a href="http://confreaks.tv/videos/rubyconf2017-esoteric-obfuscated-artistic-programming-in-ruby">Esoteric, Obfuscated, Artistic Programming in Ruby</a> by Yusuke Endoh</li> +<li><a href="http://confreaks.tv/videos/rubyconf2017-keynote-the-impermanence-of-software">The Impermanence of Software</a> by Andy Croll</li> +<li><a href="http://confreaks.tv/videos/rubyconf2017-git-driven-refactoring">Git Driven Refactoring</a> by Ashley Ellis Pierce</li> +<li><a href="http://confreaks.tv/videos/rubyconf2017-the-unbearable-vulnerability-of-open-source">The Unbearable Vulnerability of Open Source</a> by Eileen Uchitelle</li> +<li><a href="http://confreaks.tv/events/rubyconf2017">All The Great Talks</a> from RubyConf</li> +<li><a href="https://thoughtbot.com/podcasts">thoughtbot Podcast Swag Sale</a></li> +</ul> + + + + We share our favorite talks from RubyConf and discuss how Sean has made ActiveRecord attributes allocation significantly faster with Rust.

+ +

Support The Bike Shed

]]> + + + We share our favorite talks from RubyConf and discuss how Sean has made ActiveRecord attributes allocation significantly faster with Rust.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+BW95m8Ef + + ]]> + + + + 133: A Very Special Bike Shed + https://bikeshed.thoughtbot.com/133 + ff312988-5a9e-42dd-b1b8-cec9ede8155c + Thu, 23 Nov 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Sean is on to a significant ActiveRecord optimization using an extension written in Rust and Derek shares an overdue thanks to an excellent manager. + 31:01 + no + + <p>Sean is on to a significant ActiveRecord optimization using an extension written in Rust and Derek shares an overdue thanks to an excellent manager.</p> +<ul> +<li><a href="https://github.com/tildeio/helix">Helix</a></li> +<li><a href="https://github.com/SamSaffron/fast_blank">Fast Blank</a></li> +<li>Turns out, Rails Fast Attributes might be more on the order of <a href="https://twitter.com/sgrif/status/928275953486323715">2x faster</a>!</li> +<li><a href="https://github.com/Shopify/bootsnap">Bootsnap</a></li> +<li><a href="https://github.com/rails/rails/pull/28083#issuecomment-313486810">Do I need Database Cleaner?</a></li> +<li><a href="https://github.com/nettofarah/graphql-query-resolver">GraphQL Query Resolver</a></li> +<li><a href="https://github.com/postgraphql/postgraphql">PostGraphQL</a></li> +<li><a href="https://twitter.com/thoughtbot/status/925413386623569920">Headless Capybara!</a></li> +<li><a href="http://www.siebel-tech.com/wp-content/uploads/2014/12/Tools6.3.gif">Working in Siebel… Ugh</a></li> +<li>Rebecca <a href="https://www.amazon.com/Math-Lab-Kids-Hands-Activities/dp/1631592521">wrote a book</a></li> +<li><a href="https://medium.com/@upcase">Upcase Crossroads</a></li> +</ul> + + + + Sean is on to a significant ActiveRecord optimization using an extension written in Rust and Derek shares an overdue thanks to an excellent manager.

+ +

Support The Bike Shed

]]> + + + Sean is on to a significant ActiveRecord optimization using an extension written in Rust and Derek shares an overdue thanks to an excellent manager.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-jTm7maC + + ]]> + + + + 132: What Went Well? + https://bikeshed.thoughtbot.com/132 + 1721fe14-a6ec-4698-9d8b-a689ce3f8f83 + Thu, 16 Nov 2017 11:30:00 -0500 + thoughtbot + + full + thoughtbot + We discuss patterns and anti-patterns encountered in agile retrospectives and revisit a favorite topic: form objects. + 36:52 + no + + <p>We discuss patterns and anti-patterns encountered in agile retrospectives and revisit a favorite topic: form objects.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/videos/running-a-retrospective">Running a Retrospective</a></li> +<li><a href="https://en.wikipedia.org/wiki/Scrum_(software_development)#Sprint">Scrum Sprints</a></li> +<li><a href="https://thoughtbot.com/product-design-sprint">Product Design Sprint</a></li> +<li><a href="https://auth0.com">Auth0</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveModel/Dirty.html">ActiveModel::Dirty</a></li> +<li><a href="https://github.com/trailblazer/reform">Reform</a></li> +<li><a href="https://hexdocs.pm/ecto/Ecto.Changeset.html">Ecto Changeset</a></li> +<li><a href="https://robots.thoughtbot.com/lucky-an-experimental-new-web-framework-by-thoughtbot">Lucky, an experimental new web framework by thoughtbot</a></li> +</ul> + + + + We discuss patterns and anti-patterns encountered in agile retrospectives and revisit a favorite topic: form objects.

+ +

Support The Bike Shed

]]> + + + We discuss patterns and anti-patterns encountered in agile retrospectives and revisit a favorite topic: form objects.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+SX8exRZg + + ]]> + + + + 131: Nouns For Verbs Sake + https://bikeshed.thoughtbot.com/131 + b5e3be8e-b3d8-4dd6-9939-84effe37853e + Wed, 08 Nov 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We briefly discuss the renaming of factory_girl to factory_bot before diving in to the visitor pattern; what is it, and what are its inherent tradeoffs. + 39:03 + no + + <p>We briefly discuss the renaming of factory_girl to factory_bot before diving in to the visitor pattern; what is it, and what are its inherent tradeoffs.</p> +<ul> +<li><a href="https://robots.thoughtbot.com/factory_bot">factory_bot</a></li> +<li><a href="https://en.wikipedia.org/wiki/Visitor_pattern">visitor pattern</a></li> +<li><a href="https://blog.bigbinary.com/2013/07/07/visitor-pattern-and-double-dispatch.html">Visitor pattern and double dispatch in ruby</a></li> +<li><a href="https://twitter.com/sgrif/status/927713606027931648">Sean drives for Lyft</a></li> +</ul> + + + + We briefly discuss the renaming of factory_girl to factory_bot before diving in to the visitor pattern; what is it, and what are its inherent tradeoffs.

+ +

Support The Bike Shed

]]> + + + We briefly discuss the renaming of factory_girl to factory_bot before diving in to the visitor pattern; what is it, and what are its inherent tradeoffs.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+wTz_VksK + + ]]> + + + + 130: I Grew Up in Balloons + https://bikeshed.thoughtbot.com/130 + 9d9b2525-e765-43e3-a91d-90e65601aad3 + Fri, 03 Nov 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Is Database Cleaner necessary anymore? Tune in for our exciting play-by-play reporting on that issue and stick around for chatter on personal defaults for new Rails applications. + 33:49 + no + + <p>Is Database Cleaner necessary anymore? Tune in for our exciting play-by-play reporting on that issue and stick around for chatter on personal defaults for new Rails applications.</p> +<ul> +<li><a href="https://github.com/rspec/rspec-rails/pull/1813">Integrate with ActionDispatch::SystemTest</a></li> +<li><a href="https://github.com/DatabaseCleaner/database_cleaner">Database Cleaner</a></li> +<li><a href="http://rspec.info/blog/2017/10/rspec-3-7-has-been-released/">RSpec 3.7 has been released!</a></li> +<li><a href="http://bundler.io/blog/2015/03/20/moving-bins-to-exe.html">Bundler template moves bins to exe</a></li> +<li><a href="https://github.com/thoughtbot/suspenders">Suspenders</a></li> +<li><a href="https://github.com/getsentry/raven-ruby/pull/769">Exclude all 4xx Rails errors from Sentry reporting</a></li> +<li><a href="http://www.balloonfiesta.com">Balloon Fiesta</a></li> +</ul> + + + + Is Database Cleaner necessary anymore? Tune in for our exciting play-by-play reporting on that issue and stick around for chatter on personal defaults for new Rails applications.

+ +

Support The Bike Shed

]]> + + + Is Database Cleaner necessary anymore? Tune in for our exciting play-by-play reporting on that issue and stick around for chatter on personal defaults for new Rails applications.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+oho42xyT + + ]]> + + + + 129: You Wanna Talk About GraphQL? + https://bikeshed.thoughtbot.com/129 + aba988ea-0aac-48a3-b5e2-d01f84c1c73f + Fri, 27 Oct 2017 10:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss an issue in the interaction between Rails, Chrome, and the HTTP referrer policy before Derek shares his love for GraphQL. + 47:03 + no + + <p>We discuss an issue in the interaction between Rails, Chrome, and the HTTP referrer policy before Derek shares his love for GraphQL.</p> +<ul> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy">Referrer-Policy</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin">Origin header</a></li> +<li><a href="https://github.com/rails/rails/issues/28299">Rails/Chrome/no-referrer issue</a></li> +<li><a href="http://graphql.org">GraphQL</a></li> +<li><a href="http://graphql-ruby.org">GraphQL-Ruby</a></li> +<li><a href="https://github.com/Shopify/graphql-batch">GraphQL-Batch</a></li> +<li><a href="http://sangria-graphql.org">Sangria</a></li> +<li><a href="https://hashrocket.com/blog/posts/format-your-elixir-code-now">Elixir 1.6 Formatter</a></li> +</ul> + + + + We discuss an issue in the interaction between Rails, Chrome, and the HTTP referrer policy before Derek shares his love for GraphQL.

+ +

Support The Bike Shed

]]> + + + We discuss an issue in the interaction between Rails, Chrome, and the HTTP referrer policy before Derek shares his love for GraphQL.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+FvDO-TJX + + ]]> + + + + 128: And Now for My Next Trick! + https://bikeshed.thoughtbot.com/128 + 16e13d4a-60e7-4e67-8c5c-3f0dab847ac1 + Thu, 19 Oct 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss strategies for fighting back against project management overhead, refactoring workflows, and on-call rotations. + 45:46 + no + + <p>We discuss strategies for fighting back against project management overhead, refactoring workflows, and on-call rotations.</p> +<ul> +<li><a href="https://twitter.com/kentbeck/status/250733358307500032?lang=en">Make the change easy, then make the easy change.</a></li> +<li><a href="https://robots.thoughtbot.com/refactor-in-a-branch">Refactor in a Branch</a></li> +<li><a href="https://github.com/Netflix/chaosmonkey">Chaos Monkey</a></li> +<li><a href="https://www.reddit.com/r/haskell/comments/3vfq69/what_languages_support_anonymous_union_types/">What languages support anonymous union types?</a></li> +</ul> + + + + We discuss strategies for fighting back against project management overhead, refactoring workflows, and on-call rotations.

+ +

Support The Bike Shed

]]> + + + We discuss strategies for fighting back against project management overhead, refactoring workflows, and on-call rotations.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+8m3IDUpc + + ]]> + + + + 127: Bike Shed: Discovery + https://bikeshed.thoughtbot.com/127 + 9b508be5-42c7-4635-9c6b-d7955e218657 + Fri, 13 Oct 2017 10:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss Bundler warning us to update to a prerelease version and other recent annoyances with our favorite dependency manager. We also wonder what GitHub diff stats can tell you about your contributions to a project and when they might be a smell. Stick around post credits for some spoiler-filled chatter about the first couple episodes of Star Trek: Discovery. + 52:42 + no + + <p>We discuss Bundler warning us to update to a prerelease version and other recent annoyances with our favorite dependency manager. We also wonder what GitHub diff stats can tell you about your contributions to a project and when they might be a smell. Stick around post credits for some spoiler-filled chatter about the first couple episodes of Star Trek: Discovery.</p> +<ul> +<li><a href="https://www.theverge.com/2017/9/28/16382716/spacex-elon-musk-moon-base-alpha-mars-colonization-interplanetary-transport-system">SpaceX Moon Base</a></li> +<li><a href="https://www.theverge.com/2017/9/29/16383048/elon-musk-spacex-rocket-transport-earth-travel">SpaceX Travel</a></li> +<li><a href="http://rubyconf.org/program#session-188">RubyConf talk involving Kerbal Space Program</a></li> +<li><a href="https://github.com/bundler/bundler/issues/6004">Bundler warns users to install pre-release version</a><br /> +*<a href="https://depfu.com/blog/2017/09/06/gemfiles-new-clothes"><code>Gemfile</code>/<code>Gemfile.lock</code> to <code>gems.rb/gems.locked</code></a></li> +<li><a href="https://www.sqlite.org/c3ref/column_name.html">SQLite docs</a> vs <a href="https://dev.mysql.com/doc/refman/5.7/en/mysql-fetch-fields.html">MySQL docs</a></li> +<li><a href="https://medium.com/@sgrif/impl-version-1-0-for-diesel-10f5872c7be">Diesel is Joining the Rust Impl Period</a></li> +<li><a href="http://www.cbs.com/shows/star-trek-discovery/">Star Trek Discovery</a></li> +</ul> + + + + We discuss Bundler warning us to update to a prerelease version and other recent annoyances with our favorite dependency manager. We also wonder what GitHub diff stats can tell you about your contributions to a project and when they might be a smell. Stick around post credits for some spoiler-filled chatter about the first couple episodes of Star Trek: Discovery.

+ +

Support The Bike Shed

]]> + + + We discuss Bundler warning us to update to a prerelease version and other recent annoyances with our favorite dependency manager. We also wonder what GitHub diff stats can tell you about your contributions to a project and when they might be a smell. Stick around post credits for some spoiler-filled chatter about the first couple episodes of Star Trek: Discovery.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7Ivu9sGk + + ]]> + + + + 126: Speaking of Compilers... + https://bikeshed.thoughtbot.com/126 + dd57a255-014f-4b1a-b58e-91699b8d9b70 + Thu, 05 Oct 2017 10:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss a major change to Diesel's insert statements in advance of its 1.0 release and reexamine Contracts.ruby after Derek spends some time with it in use. + 35:25 + no + + <p>We discuss a major change to Diesel's insert statements in advance of its 1.0 release and reexamine Contracts.ruby after Derek spends some time with it in use.</p> +<ul> +<li><a href="http://www.lampsplus.com/products/chandeliers/type_sputnik/">Sputnik lamp</a></li> +<li><a href="http://egonschiele.github.io/contracts.ruby/">Contracts.ruby</a></li> +<li><a href="http://wiki.c2.com/?DontUseExceptionsForFlowControl">Don't use exceptions for flow control</a></li> +<li><a href="https://crystal-lang.org">Crystal</a></li> +<li><a href="https://twitter.com/nateberkopec/status/909941660015923200">Matz doesn't like current proposals for types in Ruby</a></li> +</ul> + + + + We discuss a major change to Diesel's insert statements in advance of its 1.0 release and reexamine Contracts.ruby after Derek spends some time with it in use.

+ +

Support The Bike Shed

]]> + + + We discuss a major change to Diesel's insert statements in advance of its 1.0 release and reexamine Contracts.ruby after Derek spends some time with it in use.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+rru7X6GG + + ]]> + + + + 125: Less Bad Than Expected + https://bikeshed.thoughtbot.com/125 + 3554ece0-a800-468c-977c-4d3b19298ed1 + Thu, 28 Sep 2017 10:00:00 -0400 + thoughtbot + + full + thoughtbot + We share and discuss some user feedback on fakes and mocks, discuss the benefits and drawbacks to FactoryGirl and share exasperation over the handling of the Equifax data breach. + 44:19 + no + + <p>We share and discuss some user feedback on fakes and mocks, discuss the benefits and drawbacks to FactoryGirl and share exasperation over the handling of the Equifax data breach.</p> +<ul> +<li><a href="https://github.com/stripe/stripe-mock">Stripe Mock</a></li> +<li><a href="https://github.com/betterment/webvalve">Web Valve</a></li> +<li><a href="https://github.com/stympy/faker#deterministic-random">Seeding Faker</a></li> +<li><a href="https://robots.thoughtbot.com/speed-up-tests-by-selectively-avoiding-factory-girl">Speed Up Tests by Selectively Avoiding Factory Girl</a></li> +<li><a href="https://arstechnica.com/information-technology/2017/09/why-the-equifax-breach-is-very-possibly-the-worst-leak-of-personal-info-ever/">Why the Equifax breach is very possibly the worst leak of personal info ever</a></li> +<li><a href="https://www.consumer.ftc.gov/articles/0497-credit-freeze-faqs">Credit Freeze FAQs</a></li> +</ul> + + + + We share and discuss some user feedback on fakes and mocks, discuss the benefits and drawbacks to FactoryGirl and share exasperation over the handling of the Equifax data breach.

+ +

Support The Bike Shed

]]> + + + We share and discuss some user feedback on fakes and mocks, discuss the benefits and drawbacks to FactoryGirl and share exasperation over the handling of the Equifax data breach.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7xbWQIv- + + ]]> + + + + 124: Nope. Nope. Nope. Nope. + https://bikeshed.thoughtbot.com/124 + c8b6b7d4-f751-4355-af2c-63c0d078e518 + Wed, 20 Sep 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We go inside the RubyConf CFP review process before turning our attention to questions about the impact of code review. Stick around post credits for some spoiler-filled, lukewarm Game of Thrones takes. + 41:56 + no + + <p>We go inside the RubyConf CFP review process before turning our attention to questions about the impact of code review. Stick around post credits for some spoiler-filled, lukewarm Game of Thrones takes.</p> +<ul> +<li><a href="http://www.sarahmei.com/blog/2014/04/07/what-your-conference-proposal-is-missing/">What Your Conference Proposal is Missing</a> by Sarah Mei</li> +<li><a href="https://github.com/rspec/rspec-core/issues/2460">Add a configuration option to cause tests to fail if they write stderr or stdout</a></li> +<li><a href="https://en.wikipedia.org/wiki/Survivorship_bias">Survivorship Bias</a></li> +<li><a href="https://www.youtube.com/watch?v=PJjmw9TRB7s">Cultivating a Code Review Culture</a> by Derek</li> +<li><a href="https://www.youtube.com/watch?v=-6EzycFNwzY">Goldilocks and the Three Code Reviews</a> by Vaidehi Joshi</li> +</ul> + + + + We go inside the RubyConf CFP review process before turning our attention to questions about the impact of code review. Stick around post credits for some spoiler-filled, lukewarm Game of Thrones takes.

+ +

Support The Bike Shed

]]> + + + We go inside the RubyConf CFP review process before turning our attention to questions about the impact of code review. Stick around post credits for some spoiler-filled, lukewarm Game of Thrones takes.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NZCixW_H + + ]]> + + + + 123: Too Many Parameters + https://bikeshed.thoughtbot.com/123 + 28a35d16-f1c6-4d42-9a94-a6fec106cb2c + Wed, 13 Sep 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss the troubles encountered when code reuse is a goal above all others and strategies to have your reusable cake and eat it too. + 33:45 + no + + <p>Derek and Sean discuss the troubles encountered when code reuse is a goal above all others and strategies to have your reusable cake and eat it too.</p> +<ul> +<li><a href="https://twitter.com/derekprior/status/900441860568690688">16 positional arguments</a></li> +<li><a href="https://robots.thoughtbot.com/ruby-2-keyword-arguments">Ruby's keyword arguments</a></li> +<li><a href="https://github.com/nicolasblanco/rails_param">Rails Param</a></li> +<li><a href="https://github.com/zendesk/stronger_parameters">Stronger Params</a></li> +<li><a href="https://robots.thoughtbot.com/meditations-on-a-class-method">Meditations on a Class Method</a></li> +<li><a href="https://martinfowler.com/bliki/TellDontAsk.html">Tell Don't Ask</a></li> +<li><a href="https://www.youtube.com/watch?v=PJjHfa5yxlU">Get a Whiff of This</a> by Sandi Metz</li> +</ul> + + + + Derek and Sean discuss the troubles encountered when code reuse is a goal above all others and strategies to have your reusable cake and eat it too.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss the troubles encountered when code reuse is a goal above all others and strategies to have your reusable cake and eat it too.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Tn0y5as8 + + ]]> + + + + 122: Name That Smell + https://bikeshed.thoughtbot.com/122 + 58468955-992e-42da-95e2-6d76c42468a3 + Tue, 05 Sep 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss going from zero to code on new projects, writing tests that deal with external services, and a tricky floating point precision bug Sean encountered in ActiveRecord. + 41:04 + no + + <p>Derek and Sean discuss going from zero to code on new projects, writing tests that deal with external services, and a tricky floating point precision bug Sean encountered in ActiveRecord.</p> +<ul> +<li><a href="https://github.com/thoughtbot/laptop">The thoughtbot laptop script</a></li> +<li><a href="https://robots.thoughtbot.com/bin-setup"><code>bin/setup</code></a></li> +<li><a href="https://github.com/vcr/vcr">VCR</a></li> +<li><a href="https://robots.thoughtbot.com/mystery-guest">Mystery Guest</a></li> +<li><a href="https://robots.thoughtbot.com/how-to-stub-external-services-in-tests">How to Stub External Services in Tests</a></li> +<li><a href="https://github.com/thoughtbot/fake_stripe">Fake Stripe</a></li> +<li><a href="https://bugs.ruby-lang.org/issues/12958">Breaking change in how <code>#round</code> works</a></li> +</ul> + + + + Derek and Sean discuss going from zero to code on new projects, writing tests that deal with external services, and a tricky floating point precision bug Sean encountered in ActiveRecord.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss going from zero to code on new projects, writing tests that deal with external services, and a tricky floating point precision bug Sean encountered in ActiveRecord.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+kGYQB__X + + ]]> + + + + 121: The Bike Log (Jerod Santo) + https://bikeshed.thoughtbot.com/121 + 15a575a2-af3b-4153-913c-c8b1a7bd5cdc + Mon, 21 Aug 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + The Changelog's Jerod Santos joins the show to talk finding time for, sustaining, and funding open source development. + 43:47 + no + + <p>The Changelog's Jerod Santo joins the show to talk finding time for, sustaining, and funding open source development.</p> +<ul> +<li><a href="https://twitter.com/jerodsanto">Jerod Santo</a></li> +<li><a href="https://changelog.com">The Changelog</a></li> +<li><a href="https://changelog.com/rfc">Request for Commits</a></li> +<li><a href="https://opencollective.com">Open Collective</a></li> +<li><a href="https://machinelearning.apple.com">Apple Machine Learning Journal</a></li> +<li><a href="http://ryanbigg.com/2015/11/open-source-work">Ryan Bigg Quits Open Source Maintenance</a></li> +<li><a href="https://confreaks.tv/videos/keeprubyweird2015-kill-your-inner-code-monkey">Kill Your Inner Code Monkey by Patrick McKenzie</a></li> +</ul> + + + + The Changelog's Jerod Santo joins the show to talk finding time for, sustaining, and funding open source development.

+ +

Support The Bike Shed

]]> + + + The Changelog's Jerod Santo joins the show to talk finding time for, sustaining, and funding open source development.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7RmD6FVS + + ]]> + + + + 120: Free Apples + https://bikeshed.thoughtbot.com/120 + 6c068bc2-212f-4b46-b74f-a6cb0b964bb3 + Thu, 03 Aug 2017 10:00:00 -0400 + thoughtbot + + full + thoughtbot + We do some follow-up on open source fundraising and discuss some interesting patterns in Derek's new client project. + 36:23 + no + + <p>We do some follow-up on open source fundraising and discuss some interesting patterns in Derek's new client project.</p> +<ul> +<li><a href="https://twitter.com/alexcameron89/status/886960319754534912">Sean is back from leave</a></li> +<li><a href="http://devonestes.herokuapp.com/patronizing-open-source">Patronizing Open Source</a> by Devon C. Estes</li> +<li><a href="https://thoughtbot.com/jobs">thoughtbot is hiring</a></li> +<li><a href="https://opencollective.com/webpack">webpack on Open Collective</a></li> +<li><a href="http://www.mikeperham.com/2015/11/23/how-to-charge-for-your-open-source/">How to Charge for your Open Source</a></li> +<li><a href="http://dev.hasenj.org/post/3272592502/ibm-and-its-minions">IBM uses JSLint for evil</a></li> +<li><a href="https://jobs.lever.co/notarize">Notarize is hiring</a></li> +<li><a href="https://egonschiele.github.io/contracts.ruby/">Contracts.ruby</a></li> +<li><a href="http://ruby-doc.org/core-2.4.1/Module.html#method-i-method_added"><code>methodadded</code></a></li> +<li><a href="https://github.com/rails/rails/issues/29762">countercache called twice with after_create callback</a></li> +<li><a href="https://www.goodreads.com/quotes/112142-why-sometimes-i-ve-believed-as-many-as-six-impossible-things">“Why, sometimes I've believed as many as six impossible things before breakfast.”</a></li> +</ul> + + +

We do some follow-up on open source fundraising and discuss some interesting patterns in Derek's new client project.

+ +

Support The Bike Shed

]]> + + +

We do some follow-up on open source fundraising and discuss some interesting patterns in Derek's new client project.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+2j-Kt1w3 + + ]]> + + + + 119: Questions Are For the Weak (Caleb Thompson & Matt Mongeau) + https://bikeshed.thoughtbot.com/119 + de20691a-efcd-456d-980f-7b893c069002 + Wed, 26 Jul 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Derek are joined by Caleb Thompson and Matthew Mongeau for our annual live episode to discuss lessons learned from past projects, and speaking at conferences. + 51:23 + no + + <p>Sean and Derek are joined by Caleb Thompson and Matthew Mongeau for our annual live episode to discuss lessons learned from past projects, and speaking at conferences.</p> +<ul> +<li><a href="https://youtu.be/ahTSxNdDqsg">Video Version</a></li> +<li><a href="https://myglu.org">myglu.com (The project being discussed)</a></li> +<li><a href="https://robots.thoughtbot.com/sandi-metz-rules-for-developers">Sandi Metz' Rules for Developers</a></li> +<li><a href="https://en.wikipedia.org/wiki/Facade_pattern">Facade pattern</a></li> +<li><a href="http://docs.diesel.rs/diesel/associations/index.html">Diesel's association API</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#method-i-has_many"><code>has_many</code></a></li> +<li><a href="https://github.com/matthuhiggins/foreigner">The foreigner gem</a></li> +<li><a href="http://confreaks.tv/videos/keeprubyweird2015-at-the-mountains-of-madness-a-primer-on-writing">Goose talks about designing a programming language</a></li> +<li><a href="https://www.serviceobjects.com/">Service Objects</a></li> +<li><a href="https://github.com/halogenandtoast/monban">Monban</a></li> +<li><a href="https://blog.codeship.com/why-you-shouldnt-roll-your-own-authentication/">Why you shouldn't roll your own authentication</a></li> +<li>Please send Caleb sunglasses.</li> +<li>Rails 5.1 did ship while we were recording.</li> +<li><a href="https://www.youtube.com/watch?v=l9JXH7JPjR4">How to Talk to Developers</a></li> +</ul> + + + + Sean and Derek are joined by Caleb Thompson and Matthew Mongeau for our annual live episode to discuss lessons learned from past projects, and speaking at conferences.

+ +

Support The Bike Shed

]]> + + + Sean and Derek are joined by Caleb Thompson and Matthew Mongeau for our annual live episode to discuss lessons learned from past projects, and speaking at conferences.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+L7SW9nZ2 + + ]]> + + + + 118: Nonsense In, Nonsense Out + https://bikeshed.thoughtbot.com/118 + e70fd1fe-d346-4d59-949a-8a04e2a37c56 + Tue, 18 Jul 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss the economics of remote work, ActionDispatch::SystemTest in RSpec, and the use of Patreon on open source projects. + 45:22 + no + + <p>We discuss the economics of remote work, <code>ActionDispatch::SystemTest</code> in RSpec, and the use of Patreon on open source projects.</p> +<ul> +<li><a href="http://how-i-met-your-mother.wikia.com/wiki/Robin_Sparkles">Robin Sparkles</a></li> +<li><a href="https://github.com/rails/rails/blob/master/activerecord/lib/active_record/persistence.rb#L455-L468"><code>ActiveRecord::Base.reload</code></a></li> +<li><a href="https://github.com/rails/rails/blob/9d112c2527ab50c519fdaf21a8d432b5ca18bc85/activerecord/lib/active_record/persistence.rb#L214-L235"><code>ActiveRecord::Base.becomes</code></a></li> +<li><a href="https://github.com/rspec/rspec-rails/pull/1813">RSpec integration with <code>ActionDispatch::SystemTest</code></a></li> +<li><a href="https://rubytogether.org">Ruby Together</a></li> +</ul> + + + + We discuss the economics of remote work, ActionDispatch::SystemTest in RSpec, and the use of Patreon on open source projects.

+ +

Support The Bike Shed

]]> + + + We discuss the economics of remote work, ActionDispatch::SystemTest in RSpec, and the use of Patreon on open source projects.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+5TYMhQnL + + ]]> + + + + 117: S.A.L.T. (Justin Searls) + https://bikeshed.thoughtbot.com/117 + 5d93bf1a-0c9a-43b9-8d1d-c19d8f790cc4 + Mon, 10 Jul 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We chat with Justin Searls about testing, programmer personality types, programming communities, and putting spreadsheets on the Internet. + 46:04 + no + + <p>We chat with Justin Searls about testing, programmer personality types, programming communities, and putting spreadsheets on the Internet.</p> +<ul> +<li><a href="https://twitter.com/searls">Justin Searls</a></li> +<li><a href="https://www.youtube.com/watch?v=V4fnzHxHXMI">Justin’s RailsConf Keynote</a></li> +<li><a href="http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-doubles.html">My Favorite Way to TDD</a> by Justin Searls</li> +<li><a href="https://docs.google.com/forms/d/e/1FAIpQLSfHlw_qQLPcZTE4_oSlSxdivJQEJQ30jL7E8FFusUdqqHUbEw/viewform">Searls-Briggs Type Indicator</a></li> +<li><a href="http://testdouble.com/">Test Double</a></li> +<li><a href="https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692">Deep Work</a></li> +</ul> + + + + We chat with Justin Searls about testing, programmer personality types, programming communities, and putting spreadsheets on the Internet.

+ +

Support The Bike Shed

]]> + + + We chat with Justin Searls about testing, programmer personality types, programming communities, and putting spreadsheets on the Internet.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+dvHzeZCp + + ]]> + + + + 116: A More "WALL-E" Future + https://bikeshed.thoughtbot.com/116 + 9dc34595-d199-4c05-8655-59ae0e70feae + Wed, 28 Jun 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Amanda is joined by SF thoughtbot developers Tony, Josh, & Greg to discuss learning new languages (and whether developers should do that in their free time), machine learning, the future of AR/VR, and tech that strives to make a social difference. + 36:17 + no + + <p>Amanda is joined by SF thoughtbot developers Tony, Josh, &amp; Greg to discuss learning new languages (and whether developers should do that in their free time), machine learning, the future of AR/VR, and tech that strives to make a social difference.</p> +<ul> +<li><a href="https://twitter.com/haley/status/873309896489312256">Twitter Thread</a></li> +<li><a href="https://github.com/arbox/machine-learning-with-ruby">Machine Learning in Ruby Resources</a></li> +<li><a href="https://developer.apple.com/machine-learning/">Apple Machine Learning Resources</a></li> +<li><a href="https://techcrunch.com/2015/11/29/the-last-bus-startup-standing-chariot/">Chariot on TechCrunch</a></li> +<li><a href="https://blog.safecast.org/">Safecast</a>- Open Environmental Data</li> +<li><a href="https://github.com/safecast/">Contribute to Safecast</a></li> +<li><a href="http://www.asktia.com/">Ask Tia</a></li> +<li><a href="http://heatseek.org/welcome">Heat Seek</a></li> +</ul> + + + + Amanda is joined by SF thoughtbot developers Tony, Josh, & Greg to discuss learning new languages (and whether developers should do that in their free time), machine learning, the future of AR/VR, and tech that strives to make a social difference.

+ +

Support The Bike Shed

]]> + + + Amanda is joined by SF thoughtbot developers Tony, Josh, & Greg to discuss learning new languages (and whether developers should do that in their free time), machine learning, the future of AR/VR, and tech that strives to make a social difference.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ZkGEDQ-o + + ]]> + + + + 115: I Don't Need Another Google Hangout (Cecy Correa) + https://bikeshed.thoughtbot.com/115 + 26e8c209-5657-498b-a0d1-df5290686048 + Thu, 22 Jun 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We talk with Cecy Correa about how to hire and get hired. + 42:57 + no + + <p>We talk with Cecy Correa about how to hire and get hired.</p> +<ul> +<li><a href="https://twitter.com/cecycorrea?lang=en">Cecy Correa</a></li> +<li><a href="https://www.girldevelopit.com">Girl Develop It</a></li> +<li><a href="http://www.austinonrails.org">Austin on Rails</a></li> +<li><a href="https://journal.thriveglobal.com/why-weve-stopped-saying-culture-fit-and-what-we-re-saying-instead-a7d1e045b96b">Why We’ve Stopped Saying “Culture Fit” — and What We’re Saying Instead</a></li> +<li><a href="https://returnpath.com/careers">Jobs at Return Path</a></li> +<li><a href="https://thoughtbot.com/jobs">Jobs at thoughtbot</a></li> +</ul> + + + + We talk with Cecy Correa about how to hire and get hired.

+ +

Support The Bike Shed

]]> + + + We talk with Cecy Correa about how to hire and get hired.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+uQnIe0oT + + ]]> + + + + 114: Reasonably Thread Safe + https://bikeshed.thoughtbot.com/114 + c2aa2efb-2163-4d1b-b917-20be6558bf9f + Fri, 16 Jun 2017 10:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss a tiny DOS caused when upgrading thoughtbot.com to Rails 5.1 and how Rails could better surface warnings that only occur in your production configuration. We also get an update on multi-table joins in Rust. + 39:15 + no + + <p>We discuss a tiny DOS caused when upgrading thoughtbot.com to Rails 5.1 and how Rails could better surface warnings that only occur in your production configuration. We also get an update on multi-table joins in Rust.</p> +<ul> +<li><a href="https://twitter.com/derekprior/status/868197670900334596">Meaningful schema diffs in Rails 5.1</a></li> +<li><a href="https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet">HSTS</a></li> +<li><a href="https://en.wikipedia.org/wiki/Firesheep">Firesheep</a></li> +<li><a href="https://github.com/thoughtbot/clearance/pull/423">Use a secure session cookie for new installs</a></li> +<li><a href="https://github.com/dhs-ncats/pshtt">pshtt</a></li> +<li><a href="https://observatory.mozilla.org">Observatory by Mozilla</a></li> +<li><a href="http://www.starkandwayne.com/blog/rails-5-1-applications-can-be-a-lot-more-secretive-on-cloud-foundry-and-heroku/">Encrypted secrets in Rails 5.1</a></li> +<li><a href="https://groups.google.com/forum/#!topic/phantomjs/9aI5d-LDuNE">PhantomJS maintainer steps down</a></li> +<li>Sean solves his problem: <a href="https://github.com/diesel-rs/diesel/pull/928">Multi-tabls joins in Rust</a></li> +</ul> + + + + We discuss a tiny DOS caused when upgrading thoughtbot.com to Rails 5.1 and how Rails could better surface warnings that only occur in your production configuration. We also get an update on multi-table joins in Rust.

+ +

Support The Bike Shed

]]> + + + We discuss a tiny DOS caused when upgrading thoughtbot.com to Rails 5.1 and how Rails could better surface warnings that only occur in your production configuration. We also get an update on multi-table joins in Rust.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+e7teWAZP + + ]]> + + + + 113: Have You Considered Rust? (Matt Casper) + https://bikeshed.thoughtbot.com/113 + 7aa566ae-1de3-47f2-8dd7-f9c93ea20424 + Fri, 09 Jun 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We talk to Matt Casper about contributing to Diesel, Rust's ecosystem, and the next big thing. + 29:07 + no + + <p>We talk to Matt Casper about contributing to Diesel, Rust's ecosystem, and the next big thing.</p> +<ul> +<li><a href="https://twitter.com/cattmasper">Matt Casper</a></li> +<li><a href="https://github.com/diesel-rs/diesel/commits?author=mcasper">Matt’s Diesel’s Diesel contributions</a></li> +<li><a href="https://doc.rust-lang.org/book/">The Rust Book</a></li> +<li><a href="https://www.youtube.com/watch?v=Cx6aGMC6MjU">DHH’s RailsConf Keynote</a></li> +<li><a href="https://github.com/SergioBenitez/Rocket">Rocket</a></li> +<li><a href="https://github.com/kbknapp/clap-rs">Clap</a></li> +<li><a href="https://www.youtube.com/watch?v=V4fnzHxHXMI">Justin Searls’ RailsConf Keynote</a></li> +<li><a href="https://www.procore.com/jobs/">Procore Jobs</a></li> +</ul> + + + + We talk to Matt Casper about contributing to Diesel, Rust's ecosystem, and the next big thing.

+ +

Support The Bike Shed

]]> + + + We talk to Matt Casper about contributing to Diesel, Rust's ecosystem, and the next big thing.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+nU9sz_Mp + + ]]> + + + + 112: Lifecycles Are Dead, Long Live Lifecycles! + https://bikeshed.thoughtbot.com/112 + d341f204-9698-41d9-a3db-17390bbff6a4 + Thu, 01 Jun 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Amanda joins Sean to discuss all the Android news to come out of Google I/O, Kotlin as a "first class language", and features of Android "O"! + 33:21 + no + + <p>Amanda joins Sean to discuss all the Android news to come out of Google I/O, Kotlin as a &quot;first class language&quot;, and features of Android &quot;O&quot;!</p> +<ul> +<li><a href="https://events.google.com/io/recap/">I/O '17 Recap</a></li> +<li><a href="http://www.jetbrains.com/">JetBrains</a></li> +<li><a href="https://developer.android.com/studio/index.html">Android Studio</a></li> +<li><a href="https://developer.android.com/topic/libraries/architecture/index.html">Android Architecture Components</a></li> +<li><a href="http://www.joda.org/joda-time/">Joda-Time Library</a></li> +<li><a href="https://github.com/Kotlin/anko">Anko</a></li> +</ul> + + +

Amanda joins Sean to discuss all the Android news to come out of Google I/O, Kotlin as a "first class language", and features of Android "O"!

+ +

Support The Bike Shed

]]> + + +

Amanda joins Sean to discuss all the Android news to come out of Google I/O, Kotlin as a "first class language", and features of Android "O"!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7IICwxs9 + + ]]> + + + + 111: Trike Shed (Aaron Patterson) + https://bikeshed.thoughtbot.com/111 + 84fd2b71-9bba-40db-98dd-036889a8728d + Thu, 25 May 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We talk with Aaron Patterson about Ruby and Rails upgrades, and the goal of making Ruby 3 three times faster than Ruby 2. + 31:14 + no + + <p>We talk with Aaron Patterson about Ruby and Rails upgrades, and the goal of making Ruby 3 three times faster than Ruby 2.</p> +<ul> +<li><a href="https://twitter.com/tenderlove">Aaron Patterson</a></li> +<li><a href="https://www.youtube.com/watch?v=Cx6aGMC6MjU">DHH’s RailsConf Keynote</a></li> +<li><a href="https://bugs.ruby-lang.org/issues/10967"><code>warning: private attribute?</code></a></li> +<li><a href="https://blog.heroku.com/ruby-2-4-features-hashes-integers-rounding#proposed-rounding-changes">Ruby 2.4 Rounding Changes</a></li> +<li><a href="http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3">Ruby 3x3</a></li> +<li><a href="https://github.com/mame/optcarrot">optcarrot: A NES Emulator for Ruby Benchmark</a></li> +<li><a href="https://www.youtube.com/watch?v=uVYdSuFFmCU">Windows 98 Defragging</a></li> +</ul> + + + + We talk with Aaron Patterson about Ruby and Rails upgrades, and the goal of making Ruby 3 three times faster than Ruby 2.

+ +

Support The Bike Shed

]]> + + + We talk with Aaron Patterson about Ruby and Rails upgrades, and the goal of making Ruby 3 three times faster than Ruby 2.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+mKVoSZh3 + + ]]> + + + + 110: Green Chips + https://bikeshed.thoughtbot.com/110 + b4f23141-8997-486e-85b8-020a93f1e845 + Thu, 18 May 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + What’s the deal with green potato chips? Also: RailsConf wrap up and an AST pass refactor for Diesel. + 32:43 + no + + <p>What’s the deal with green potato chips? Also: RailsConf wrap up and an AST pass refactor for Diesel.</p> +<ul> +<li><a href="http://nowiknow.com/green-potato-chips/">Green Potato Chips</a></li> +<li><a href="https://twitter.com/sgrif/status/853709192607215616">Baby Ruby Stickers</a></li> +<li><a href="http://confreaks.tv/videos/railsconf2017-keynote">Justin Searls - How to Program</a></li> +<li><a href="http://confreaks.tv/videos/railsconf2017-building-rails-actiondispatch-systemtestcase-framework">Eileen Uchitelle - Building Rails ActionDispatch::SystemTestCase Framework</a></li> +<li><a href="http://confreaks.tv/videos/railsconf2017-perusing-the-rails-source-code-a-beginners-guide">Alex Kitchens - Perusing the Rails Source Code - A Beginners Guide</a></li> +<li><a href="https://en.wikipedia.org/wiki/Abstract_syntax_tree">Abstract syntax tree</a></li> +<li><a href="https://en.wikipedia.org/wiki/Visitor_pattern">Visitor Pattern</a></li> +<li><a href="https://github.com/diesel-rs/diesel/pull/894">Refactor the query builder to make it easier to add new AST passes</a></li> +<li><a href="https://github.com/diesel-rs/diesel/pull/903">Turn <code>to_sql</code> into a standard AST pass</a></li> +</ul> + + + + What’s the deal with green potato chips? Also: RailsConf wrap up and an AST pass refactor for Diesel.

+ +

Support The Bike Shed

]]> + + + What’s the deal with green potato chips? Also: RailsConf wrap up and an AST pass refactor for Diesel.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+DlwGkXSk + + ]]> + + + + 109: The Final Countdown + https://bikeshed.thoughtbot.com/109 + 26218c6a-2818-42be-880f-14bffb07d2a2 + Wed, 26 Apr 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Follow up about Service Objects and Computer Engineering. Plus, RailsConf prep, code slide woes, and modal pop-ups. + 32:48 + no + + <p>Follow up about Service Objects and Computer Engineering. Plus, RailsConf prep, code slide woes, and modal pop-ups.</p> +<ul> +<li><a href="https://youtu.be/0cKcWNj-MPI">Sandi Metz- Gilded Rose Kata</a></li> +<li><a href="https://youtu.be/l9JXH7JPjR4">Ben Orenstein- How to Talk to Developers</a></li> +<li><a href="https://youtu.be/rLinNRMwFYA">Sean @ RubyConf Portugal '15</a>- With smoke machine and intro music</li> +<li><a href="https://webmasters.googleblog.com/2016/08/helping-users-easily-access-content-on.html">Google's Intrusive Pop-Up Announcement</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://pages.sparkpost.com/bikeshed">SparkPost</a></p> + + + + Follow up about Service Objects and Computer Engineering. Plus, RailsConf prep, code slide woes, and modal pop-ups.

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + + Follow up about Service Objects and Computer Engineering. Plus, RailsConf prep, code slide woes, and modal pop-ups.

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+HfYxJFM- + + ]]> + + + + 108: Have You Tried Rebooting? + https://bikeshed.thoughtbot.com/108 + 7a6e90b9-2ec9-42f8-bb41-a670604c8da8 + Tue, 18 Apr 2017 16:00:00 -0400 + thoughtbot + + full + thoughtbot + Is your operating system hosed? That might be related to Rails! We also chat about the trend towards compiled languages. + 41:26 + no + + <p>Is your operating system hosed? That might be related to Rails! We also chat about the trend towards compiled languages.</p> +<ul> +<li><a href="https://tbot.io/bikeshop">RailsConf Shirts</a>- Please only order if you will be at RailsConf to pick up!</li> +<li><a href="http://media3.giphy.com/media/3ohzdGjdYn6eM83dEQ/giphy.gif">The pre-show</a></li> +<li><a href="https://github.com/rails/rails/issues/26158">The listen gem breaks my laptop</a></li> +<li><a href="https://en.wikipedia.org/wiki/Interpreted_language">Interpreted Language</a></li> +<li><a href="http://llvm.org/">LLVM</a></li> +<li><a href="https://en.wikipedia.org/wiki/Cambrian_explosion">Cambrian Explosion</a></li> +<li><a href="https://crystal-lang.org/">Crystal</a></li> +<li><a href="https://twitter.com/Symbo1ics/status/851933116042182657">Rob Pike on Googlers</a></li> +<li><a href="https://twitter.com/rob_pike/status/744950332120170497?lang=en">Rob Pike on the programmer prerequisites</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://pages.sparkpost.com/bikeshed">SparkPost</a></p> + + + + Is your operating system hosed? That might be related to Rails! We also chat about the trend towards compiled languages.

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + + Is your operating system hosed? That might be related to Rails! We also chat about the trend towards compiled languages.

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-1uksyq6 + + ]]> + + + + 107: "Composition" Over Inheritance + https://bikeshed.thoughtbot.com/107 + f8f1e17b-464b-44cc-831e-9173bf0dbef3 + Fri, 14 Apr 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Single table inheritance, polymorphic associations, state machines and service objects, oh my! + 52:50 + no + + <p>Single table inheritance, polymorphic associations, state machines and service objects, oh my!</p> +<ul> +<li><a href="https://tbot.io/bikeshop">RailsConf Shirts</a>- Please only order if you will be at RailsConf to pick up!</li> +<li><a href="http://imgur.com/gallery/vX3zm">How to Win at Monopoly and Lose All Your Friends</a></li> +<li><a href="http://www.space.com/36292-touchdown-spacexs-1st-reused-rocket-lands-on-drone-ship-video.html">Touchdown! SpaceX’s 1st Reused Rocket Lands on Drone Ship</a></li> +<li><a href="https://en.wikipedia.org/wiki/Little_Boy_Blue">Little Boy Blue</a></li> +<li><a href="http://guides.rubyonrails.org/association_basics.html#single-table-inheritance">Single Table Inheritance</a></li> +<li><a href="http://guides.rubyonrails.org/association_basics.html#polymorphic-associations">Polymorphic Associations</a></li> +<li><a href="https://en.wikipedia.org/wiki/Tagged_union">Tagged Union</a></li> +<li><a href="https://github.com/vanruby/canada">Canada</a></li> +<li><a href="https://www.happiestbaby.com/pages/snoo">Snoo</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://pages.sparkpost.com/bikeshed">SparkPost</a></p> + + + + Single table inheritance, polymorphic associations, state machines and service objects, oh my!

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + + Single table inheritance, polymorphic associations, state machines and service objects, oh my!

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+zUE7lseT + + ]]> + + + + 106: Nerd Sniping (Chris Toomey) + https://bikeshed.thoughtbot.com/106 + 3bd5f801-1d99-4d83-a69f-588ec2a3b37b + Wed, 05 Apr 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Chris Toomey joins to talk about Tell Me When It Closes, Haskell, and GraphQL. + 46:21 + no + + <p>Chris Toomey joins to talk about Tell Me When It Closes, Haskell, and GraphQL.</p> +<ul> +<li>Chris Toomey - <a href="https://twitter.com/christoomey">twitter</a>, <a href="https://github.com/christoomey">github</a></li> +<li><a href="https://tellmewhenitcloses.com">Tell Me When It Closes</a></li> +<li><a href="https://github.com/christoomey/vim-rfactory">RFactory</a></li> +<li><a href="https://xkcd.com/356/">Nerd Sniping</a></li> +<li><a href="https://github.com/rails/rails/pull/28603">Add an alias for <code>reverse_merge</code> to <code>with_defaults</code></a></li> +<li><a href="http://bitemyapp.com/posts/2014-04-29-meditations-on-learning-haskell.html">“I write Haskell because I’m dumb”</a></li> +<li><a href="http://graphql.org/">GraphQL</a></li> +<li><a href="https://developer.github.com/early-access/graphql/">GitHub GraphQL API</a></li> +<li><a href="https://mruby.sh/201703270126.html">The $500,000 mruby Relase</a></li> +<li><a href="https://daniel.haxx.se/blog/2017/03/27/curl-is-c/">Curl is C</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://pages.sparkpost.com/bikeshed">SparkPost</a></p> + + + + Chris Toomey joins to talk about Tell Me When It Closes, Haskell, and GraphQL.

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + + Chris Toomey joins to talk about Tell Me When It Closes, Haskell, and GraphQL.

+ + + +

Thank you to our sponsor this week, SparkPost

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+S74QJE4u + + ]]> + + + + 105: For Display Purposes Only + https://bikeshed.thoughtbot.com/105 + 0f1d9866-8362-4576-ac48-fc07da7cb9f4 + Thu, 30 Mar 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Complexity vs Functionality, Validations vs Database Constraints, plus whatever a Cap'n Proto is. + 46:51 + no + + <p>Complexity vs Functionality, Validations vs Database Constraints, plus whatever a Cap'n Proto is.</p> +<ul> +<li><a href="http://zelda.wikia.com/wiki/Second_Quest">Second Quests in Zelda Games</a></li> +<li><a href="https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message">5 Useful Tips For A Better Commit Message</a></li> +<li><a href="https://gist.github.com/sgrif/14bb6f4a1f32b9cf09a8c40a004e86f7">Sean’s rocket equations</a></li> +<li><a href="https://en.wikipedia.org/wiki/Atlas_(rocket_family)">Atlas Rocket Family</a></li> +<li><a href="https://bugs.ruby-lang.org/issues/13334">Removed deprecated mathn extentions</a> is targeted for Ruby 2.5</li> +<li><a href="https://hackernoon.com/complexity-and-strategy-325cd7f59a92">Complexity and Strategy</a></li> +<li><a href="https://ernie.io/2015/10/07/talk-how-to-build-a-skyscraper/">How to Build a Skyscrapper</a></li> +<li><a href="https://github.com/nullobject/rein">Rein</a> - database constraints for Rails</li> +<li><a href="https://github.com/thoughtbot/scenic">Scenic</a> - database views for Rails</li> +<li><a href="https://robots.thoughtbot.com/validation-database-constraint-or-both">Validation, Database Constraint, or Both?</a></li> +<li><a href="https://robots.thoughtbot.com/the-perils-of-uniqueness-validations">The Perils of Uniqueness Validations</a></li> +<li><a href="https://hexdocs.pm/ecto/Ecto.Changeset.html#module-validations-and-constraints">Ecto Validations and Constraints</a></li> +<li><a href="https://capnproto.org/">Cap’n Proto</a></li> +<li><a href="https://developers.google.com/protocol-buffers/">Protocol Buffer</a></li> +<li><a href="https://www.w3.org/TR/wsdl">WSDL</a></li> +</ul> + + + + Complexity vs Functionality, Validations vs Database Constraints, plus whatever a Cap'n Proto is.

+ +

Support The Bike Shed

]]> + + + Complexity vs Functionality, Validations vs Database Constraints, plus whatever a Cap'n Proto is.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+fOPrpU9g + + ]]> + + + + 104: It's Dangerous to Refactor Alone! + https://bikeshed.thoughtbot.com/104 + c9f0bb65-16af-47ed-bfd8-9829b8fd896c + Thu, 23 Mar 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Google's carrot-and-stick HTTPS policies and how playing The Legend of Zelda is like refactoring. + 42:00 + no + + <p>Google's carrot-and-stick HTTPS policies and how playing The Legend of Zelda is like refactoring.</p> +<ul> +<li><a href="https://motherboard.vice.com/en_us/article/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https">Google Will Soon Shame All Websites That Are Unencrypted</a></li> +<li><a href="https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security">HSTS</a></li> +<li><a href="http://www.romhacking.net/forum/index.php?topic=15707.0">Super Mario Bros. 3 right-side scroll artifacts</a></li> +<li><a href="https://www.howtogeek.com/181303/htg-explains-how-the-nintendo-zapper-worked-and-why-it-doesnt-work-on-new-tvs/">How the Nintendo NES Zapper Worked, and Why It Doesn’t Work On HDTVs</a></li> +<li><a href="https://twitter.com/derekprior/status/840396180341309441">NES R.O.B</a></li> +<li><a href="https://github.com/rust-lang/crates.io/blob/master/src/krate_reverse_dependencies.sql">reverse dependencies query</a></li> +<li><a href="http://www.nintendo.com/games/detail/snipperclips-switch">Snipperclips</a></li> +<li><a href="http://zelda.wikia.com/wiki/Second_Quest">Second Quests in Zelda Games</a></li> +<li><a href="http://brickseek.com/">Brickseek</a></li> +</ul> + + + + Google's carrot-and-stick HTTPS policies and how playing The Legend of Zelda is like refactoring.

+ +

Support The Bike Shed

]]> + + + Google's carrot-and-stick HTTPS policies and how playing The Legend of Zelda is like refactoring.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+r8K479N6 + + ]]> + + + + 103: I Just Want to See Green Dots + https://bikeshed.thoughtbot.com/103 + cc357c78-347a-482c-aa23-46107ed468d1 + Thu, 16 Mar 2017 00:00:00 -0400 + thoughtbot + + full + thoughtbot + When a hash isn't a hash, GitHub as your Résumé, and porting Crates.io to Diesel. + 53:02 + no + + <p>When a hash isn't a hash, GitHub as your Résumé, and porting Crates.io to Diesel.</p> +<ul> +<li><a href="https://github.com/rails/rails/issues/28353"><code>ActionController::Parameters</code> should implement <code>reverse_merge</code></a></li> +<li><a href="https://en.wikipedia.org/wiki/Expression-oriented_programming_language">Expression-oriented programming language</a></li> +<li><a href="https://thoughtbot.com/jobs">Jobs at thoughtbot</a></li> +<li><a href="https://github.com/rust-lang/crates.io/pull/589">Set up the groundwork for a port to Diesel</a></li> +<li><a href="https://www.postgresql.org/docs/current/static/tutorial-window.html">Window Functions</a></li> +<li><a href="https://github.com/rust-lang/crates.io/pull/592">Remove the <code>max_version</code> column from Crates</a></li> +</ul> + + + + When a hash isn't a hash, GitHub as your Résumé, and porting Crates.io to Diesel.

+ +

Support The Bike Shed

]]> + + + When a hash isn't a hash, GitHub as your Résumé, and porting Crates.io to Diesel.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+D67UIqPE + + ]]> + + + + 102: To the Moon! + https://bikeshed.thoughtbot.com/102 + 7eaa711a-e149-4856-906d-ff47a891351c + Fri, 10 Mar 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Going "to" the moon, hidden type errors in our Rails apps, the process of talk prep, and the S3 outage. + 49:57 + no + + <p>Going &quot;to&quot; the moon, hidden type errors in our Rails apps, the process of talk prep, and the S3 outage.</p> +<ul> +<li><a href="http://www.spacex.com/news/2017/02/27/spacex-send-privately-crewed-dragon-spacecraft-beyond-moon-next-year">SpaceX to Send Privately Crewed Dragon Spacecraft Beyond the Moon</a></li> +<li><a href="https://www.nasa.gov/exploration/systems/orion/">NASA’s Orion Spacecraft</a></li> +<li><a href="https://upload.wikimedia.org/wikipedia/commons/b/b2/SLS_on_MLP_at_night.jpg">Retro looking rendering of SLS</a></li> +<li><a href="https://robots.thoughtbot.com/git-push-git-paid"><code>git push &amp;&amp; git paid</code></a></li> +<li><a href="https://github.com/SergioBenitez/Rocket">Rocket</a></li> +<li><a href="http://eileencodes.com/posts/my-process-for-writing-a-talk/">My Process for Writing a Talk</a> by Eileen Uchitelle</li> +<li><a href="https://aws.amazon.com/message/41926/">Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region</a></li> +<li><a href="https://github.com/Netflix/chaosmonkey">Chaos Monkey</a></li> +</ul> + + + + Going "to" the moon, hidden type errors in our Rails apps, the process of talk prep, and the S3 outage.

+ +

Support The Bike Shed

]]> + + + Going "to" the moon, hidden type errors in our Rails apps, the process of talk prep, and the S3 outage.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+6cHVxmWX + + ]]> + + + + 101: Hey, You Leaned! + https://bikeshed.thoughtbot.com/101 + 4e3a1509-40d4-4aa1-bcde-184bf00aa1d6 + Tue, 28 Feb 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Amanda and Sean discuss the evolving stages of open source projects, native apps vs web apps, and space. + 50:35 + no + + <p>Amanda and Sean discuss the evolving stages of open source projects, native apps vs web apps, and space.</p> +<ul> +<li><a href="https://www.appveyor.com/">AppVeyor</a></li> +<li><a href="https://github.com/electron/electron">Electron</a></li> +<li><a href="https://www.xamarin.com/">Xamarin</a> is the Microsoft-owned cross-platform mobile application company.</li> +<li><a href="https://www.nasa.gov/press-release/nasa-telescope-reveals-largest-batch-of-earth-size-habitable-zone-planets-around/">NASA TRAPPIST 1 Announcement</a></li> +<li><a href="https://spaceflightnow.com/">Spaceflight Now</a></li> +<li><a href="http://www.writespeakcode.com/">Write/Speak/Code</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a></p> + + + + Amanda and Sean discuss the evolving stages of open source projects, native apps vs web apps, and space.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support The Bike Shed

]]> + + + Amanda and Sean discuss the evolving stages of open source projects, native apps vs web apps, and space.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+K2Tk3w2O + + ]]> + + + + 100: Nouns You Can Verb + https://bikeshed.thoughtbot.com/100 + 5c46be79-b992-451a-82ae-591824154d81 + Fri, 24 Feb 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Sam Phippen helps us celebrate episode 100, as we discuss Diesel bugs, REST, RPC, and more. + 51:32 + no + + <p>Sam Phippen helps us celebrate episode 100, as we discuss Diesel bugs, REST, RPC, and more.</p> +<ul> +<li><a href="https://github.com/diesel-rs/diesel/issues/621">Diesel <code>LEFT JOINS</code> bug</a></li> +<li><a href="https://cloud.google.com/spanner/">Google Spanner</a></li> +<li><a href="https://en.wikipedia.org/wiki/Information_schema">Information Schema Standard</a></li> +<li><a href="https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf">Spanner Beta Paper</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#attr-formaction">HTML5 <code>formaction</code></a></li> +<li><a href="https://twitter.com/samphippen/status/710414430010548224">Must be Willing to Relocate to San Francisco</a></li> +<li><a href="http://www.grpc.io">GRPC</a></li> +<li><a href="https://developers.google.com/protocol-buffers/">Protocol Buffers</a></li> +<li><a href="https://github.com/rails/rails/issues/26158">The Listen gem breaks my laptop</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a>!</p> + + + + Sam Phippen helps us celebrate episode 100, as we discuss Diesel bugs, REST, RPC, and more.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + + Sam Phippen helps us celebrate episode 100, as we discuss Diesel bugs, REST, RPC, and more.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+lKOhD8pY + + ]]> + + + + 99: Just Sayin' + https://bikeshed.thoughtbot.com/99 + 29cda09a-7355-443c-9f37-71974e98bd6a + Thu, 16 Feb 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We go into the weeds with MySQL and discuss the virtues of database migrations written in SQL. + 46:05 + no + + <p>We go into the weeds with MySQL and discuss the virtues of database migrations written in SQL.</p> +<ul> +<li><a href="https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html">Big and little endian</a></li> +<li><a href="https://dev.mysql.com/doc/refman/5.7/en/mysql-real-escape-string.html"><code>mysql_real_escape_string</code></a></li> +<li><a href="https://github.com/diesel-rs/diesel/issues/643">Should we set <code>CLIENT_IGNORE_SIGPIPE</code> for MySQL?</a></li> +<li><a href="https://eng.uber.com/mysql-migration/">Why Uber Switched From Postgres to MySQL</a></li> +<li><a href="http://www.mccartie.com/2016/12/05/rails-5.1.html">Default Primary Keys Are Now BIGINT</a></li> +<li><a href="http://guides.rubyonrails.org/active_record_migrations.html#using-reversible">Using <code>reversible</code> in migrations</a></li> +<li><a href="https://twitter.com/garybernhardt/status/829123988718628864">Gary's tweet</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a>!</p> + + + + We go into the weeds with MySQL and discuss the virtues of database migrations written in SQL.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + + We go into the weeds with MySQL and discuss the virtues of database migrations written in SQL.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Fh4TUj4Z + + ]]> + + + + 98: I Have Good Branch Hygiene + https://bikeshed.thoughtbot.com/98 + c29e27af-27b5-47e8-8e43-0e6c8fa2e21d + Wed, 08 Feb 2017 11:00:00 -0500 + thoughtbot + + full + thoughtbot + We discuss complexity and progressive disclosure, garbage collection, and the impenetrable nature of Git. + 35:30 + no + + <p>We discuss complexity and progressive disclosure, garbage collection, and the impenetrable nature of Git.</p> +<ul> +<li><a href="http://atp.fm/episodes/205">Chris Lattner on Accidental Tech Podcase</a></li> +<li><a href="https://www.infoq.com/presentations/Simple-Made-Easy">Simple Made Easy</a></li> +<li><a href="http://theocacao.com/document.page/510">Garbage Collection was a feature of Objective-C 2.0</a></li> +<li><a href="https://github.com/rails/rails/issues/26158">The listen gem breaks my laptop</a></li> +<li><a href="https://blog.golang.org/go15gc">Go GC: Prioritizing low latency and simplicity</a></li> +<li><a href="https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.c1tlft2do">Modern Garbage Collection</a> which calls out the tradeoffs of Go's approach</li> +<li><a href="https://webkit.org/blog/7122/introducing-riptide-webkits-retreating-wavefront-concurrent-garbage-collector/">WebKit’s Retreating Wavefront Concurrent Garbage Collector</a></li> +<li><a href="https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/">The Joel Test</a></li> +<li><a href="https://github.com/jonas/tig">Tig: text-mode interface for Git</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a>!</p> + + + + We discuss complexity and progressive disclosure, garbage collection, and the impenetrable nature of Git.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + + We discuss complexity and progressive disclosure, garbage collection, and the impenetrable nature of Git.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1PUAd_Qm + + ]]> + + + + 97: One Equals Zero + https://bikeshed.thoughtbot.com/97 + 515a7741-d5bb-4a12-82f5-d038b22f6f8f + Tue, 31 Jan 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We wonder why writing parameterized associations in Rails is not easy, and discuss the difficulty in eliminating no-op queries in ActiveRecord. Plus, we discuss how you can give a great RailsConf talk proposal that doesn't have anything to do with Rails. + 29:16 + no + + <p>We wonder why writing parameterized associations in Rails is not easy, and discuss the difficulty in eliminating no-op queries in ActiveRecord. Plus, we discuss how you can give a great RailsConf talk proposal that doesn't have anything to do with Rails.</p> +<ul> +<li><a href="https://github.com/steveklabnik/request_store">RequestStore</a></li> +<li><a href="https://github.com/rails/rails/compare/master...derekprior:dp-ids-writer">The IDs writer patch Derek sent Sean</a></li> +<li><a href="https://www.youtube.com/watch?v=ggPE-JHzfAM&amp;index=2&amp;list=PLE7tQUdRKcyZGYLfj6oRQWPxB6ijg1YsC">Skunk Works</a> by Nickolas Means</li> +<li><a href="http://bikeshed.fm/71">It’s a Total Hack</a> The Bike Shed episode inspired by Skunk Works</li> +<li><a href="http://hanamirb.org">Hanami</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a>!</p> + + + + We wonder why writing parameterized associations in Rails is not easy, and discuss the difficulty in eliminating no-op queries in ActiveRecord. Plus, we discuss how you can give a great RailsConf talk proposal that doesn't have anything to do with Rails.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + + We wonder why writing parameterized associations in Rails is not easy, and discuss the difficulty in eliminating no-op queries in ActiveRecord. Plus, we discuss how you can give a great RailsConf talk proposal that doesn't have anything to do with Rails.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4s7xx3Ir + + ]]> + + + + 96: Who Stinks? + https://bikeshed.thoughtbot.com/96 + 08d7083e-498d-458a-8b37-48df1a36d231 + Fri, 27 Jan 2017 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Baby Ruby, Ruby refinements, Rails discoverability, and annoying polyfills. + 39:26 + no + + <p>Baby Ruby, Ruby refinements, Rails discoverability, and annoying polyfills.</p> +<ul> +<li><a href="http://interblah.net/why-is-nobody-using-refinements">Refinements</a></li> +<li><a href="https://github.com/rails/rails/pull/27363">Refinements in Rails</a></li> +<li><a href="https://github.com/rails/rails-ujs/pull/16">Remove required field polyfill from Rails-UJS</a></li> +<li><a href="https://nolanlawson.com/2015/06/30/safari-is-the-new-ie/">Safari is the New IE</a></li> +<li><a href="http://www.imore.com/safari-isnt-new-ie-its-user-centric-web">Safari isn't the new IE: it's the user-centric web</a></li> +</ul> +<p><img src="https://trello-attachments.s3.amazonaws.com/5409f575dbacf8b89b38236f/58863e3c869037fefa1df0d6/8af505caf7ab2829bf0692fea9917b0b/IMG_20170125_102533.jpg" alt="Baby Ruby" />- &quot;Send me onesies!&quot;</p> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a>!</p> + + + + Baby Ruby, Ruby refinements, Rails discoverability, and annoying polyfills.

+ + + +

Baby Ruby- "Send me onesies!"

+ +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + + Baby Ruby, Ruby refinements, Rails discoverability, and annoying polyfills.

+ + + +

Baby Ruby- "Send me onesies!"

+ +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+l-Yat-QZ + + ]]> + + + + 95: Click 'Cat' to go 'Home' (Morgane Santos) + https://bikeshed.thoughtbot.com/95 + bfb32ec8-976f-4768-8fc9-8b3e17a2bac0 + Fri, 20 Jan 2017 13:00:00 -0500 + thoughtbot + + full + thoughtbot + Amanda is joined by Morgane Santos to discuss the experiences, technology, and development of Virtual Reality. + 28:35 + no + + <p>Amanda is joined by Morgane Santos to discuss the experiences, technology, and development of Virtual Reality.</p> +<ul> +<li><a href="http://arstechnica.com/gaming/2008/11/snowy-game-vr-goggles-take-burn-victims-minds-off-of-pain/">VR For Burn Relief</a></li> +<li><a href="https://www.vive.com/us/">Vive</a></li> +<li><a href="https://robots.thoughtbot.com/maya-for-beginners">Maya for Beginners</a></li> +<li><a href="https://developers.google.com/vr/">GoogleVR Dev Resources</a></li> +<li><a href="https://github.com/github/game-off-2016">GitHub Game Off</a></li> +<li><a href="https://vr.google.com/cardboard/get-cardboard/">Get Cardboard</a></li> +<li><a href="http://grayarea.org/">Gray Area</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a>!</p> + + + + Amanda is joined by Morgane Santos to discuss the experiences, technology, and development of Virtual Reality.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + + Amanda is joined by Morgane Santos to discuss the experiences, technology, and development of Virtual Reality.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+6w5e8Beb + + ]]> + + + + 94: It's Not Supposed to Work + https://bikeshed.thoughtbot.com/94 + 8f2eb6b0-6337-4c0f-880d-5fd87e1b974d + Wed, 11 Jan 2017 10:00:00 -0500 + thoughtbot + + full + thoughtbot + We discuss the pain of custom inputs in HTML, ActiveRecord bugs, and Rust's Fire Flower. + 44:08 + no + + <p>We discuss the pain of custom inputs in HTML, ActiveRecord bugs, and Rust's Fire Flower.</p> +<ul> +<li><a href="https://twitter.com/sgrif/status/809886265524961281">Sean’s Haircut</a></li> +<li><a href="https://select2.github.io">Select2</a></li> +<li><a href="https://github.com/rails/rails/issues/16959">Query with 'exists' subquery fails to bind parameters</a></li> +<li><a href="https://github.com/SergioBenitez/Rocket">Rocket</a></li> +<li><a href="https://github.com/diesel-rs/diesel/issues/44">Diesel JSON data type</a></li> +<li><a href="http://words.steveklabnik.com/rust-is-more-than-safety">Rust is More Than Safety</a></li> +<li><a href="https://thefeedbackloop.xyz/safety-is-rusts-fireflower/">Safety is Rust’s Fire Flower</a></li> +<li><a href="https://medium.com/@ag_dubs/fire-flowers-and-marios-marketing-rust-996b3fdbe8f3#.r3xwm5zje">Fire Flowers and Marios: Marketing Rust</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/bike">FreshBooks</a>!</p> + + +

We discuss the pain of custom inputs in HTML, ActiveRecord bugs, and Rust's Fire Flower.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + +

We discuss the pain of custom inputs in HTML, ActiveRecord bugs, and Rust's Fire Flower.

+ + + +

Thank you to our sponsor this week, FreshBooks!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1v_jZT7f + + ]]> + + + + 93: I Have Complex Feelings + https://bikeshed.thoughtbot.com/93 + cc3ae74d-baca-465d-8791-58d25ef01eab + Wed, 21 Dec 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + The impact of codes of conduct on community behavior, shipping a mobile app written in Elm, and yet more to say on SemVer. + 41:35 + no + + <p>The impact of codes of conduct on community behavior, shipping a mobile app written in Elm, and yet more to say on SemVer.</p> +<ul> +<li><a href="https://github.com/diesel-rs/diesel/releases/tag/v0.9.0">Diesel 0.9</a></li> +<li><a href="https://github.com/rails/rails/pull/26266">Change Default Primary Keys to BIGINT</a></li> +<li><a href="https://www.rust-lang.org/en-US/conduct.html">The Rust Code of Conduct</a></li> +<li><a href="https://bugs.ruby-lang.org/issues/12004">Ruby Code of Conduct issue</a></li> +<li><a href="http://rubyonrails.org/conduct/">Rails Code of Conduct</a></li> +<li><a href="https://thoughtbot.com/open-source-code-of-conduct">thoughtbot Code of Conduct</a></li> +<li><a href="https://twitter.com/chrishalebarnes/status/808471974221672452">Disabling submit on invalid forms without JavaScript</a></li> +<li><a href="https://purpletrainapp.com">Purple Train</a></li> +<li><a href="https://github.com/ohanhi/elm-native-ui">Elm Native</a></li> +<li><a href="https://facebook.github.io/react-native/">React Native</a></li> +<li><a href="http://bikeshed.fm/86">Our earlier episode on Purple Train and React Native</a></li> +<li><a href="https://github.com/Homebrew/homebrew-core/issues/6677">Homebrew SemVer issue</a></li> +</ul> + + + + The impact of codes of conduct on community behavior, shipping a mobile app written in Elm, and yet more to say on SemVer.

+ +

Support The Bike Shed

]]> + + + The impact of codes of conduct on community behavior, shipping a mobile app written in Elm, and yet more to say on SemVer.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+D7cVZ6TD + + ]]> + + + + 92: The Queen of Canada + https://bikeshed.thoughtbot.com/92 + 577727f0-1d3e-476b-868e-98c72f0c4f57 + Fri, 16 Dec 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We discuss the sneaky performance differences between `present?`, `any?`, `blank?` and `empty?` with ActiveRecord, when N+1 is a "feature", and the future of Diesel. + 38:22 + no + + <p>We discuss the sneaky performance differences between <code>present?</code>, <code>any?</code>, <code>blank?</code> and <code>empty?</code> with ActiveRecord, when N+1 is a &quot;feature&quot;, and the future of Diesel.</p> +<ul> +<li><a href="http://imgur.com/o78ezI3">An awesome gif</a></li> +<li><a href="https://pbs.twimg.com/media/Cy8JfjxWgAAvIWO.jpg:large">Justin Trudeau’s Shopify selfie</a></li> +<li><a href="https://en.wikipedia.org/wiki/Toonie">The Toonie</a></li> +<li><a href="https://wiki.postgresql.org/wiki/Slow_Counting">Slow Counting in Postgres</a></li> +<li><a href="https://rossta.net/blog/n+1-is-a-rails-feature.html">N+1 is a Feature</a></li> +<li><a href="http://edgeguides.rubyonrails.org/caching_with_rails.html#managing-dependencies">Managing dependencies with Rails’ Russian doll caching</a></li> +<li><a href="https://www.postgresql.org/docs/9.6/static/sql-insert.html">Postgres Upsert</a></li> +<li><a href="https://thoughtbot.com/podcasts">Support The Bike Shed and other thoughtbot podcasts</a></li> +</ul> + + +

We discuss the sneaky performance differences between present?, any?, blank? and empty? with ActiveRecord, when N+1 is a "feature", and the future of Diesel.

+ +

Support The Bike Shed

]]> + + +

We discuss the sneaky performance differences between present?, any?, blank? and empty? with ActiveRecord, when N+1 is a "feature", and the future of Diesel.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4k6Y2_EE + + ]]> + + + + 91: I Think It's a Fish + https://bikeshed.thoughtbot.com/91 + 1ee15329-cb6e-4bf1-b1c2-d1f01f7a5909 + Thu, 08 Dec 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek briefly complains of the staleness of the asset pipeline in Rails 5, before Sean catches Derek up on Rails 5.1's support for Webpack, Yarn, and ES6. We also discuss the pain of deprecations in the upgrade to Rails 5. + 41:05 + no + + <p>Derek briefly complains of the staleness of the asset pipeline in Rails 5, before Sean catches Derek up on Rails 5.1's support for Webpack, Yarn, and ES6. We also discuss the pain of deprecations in the upgrade to Rails 5.</p> +<ul> +<li><a href="http://caniuse.com/#feat=form-validation">Can I Use: HTML 5 validations</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLSelectElement/checkValidity"><code>checkValidity()</code></a></li> +<li><a href="http://eslint.org">ESLint</a></li> +<li><a href="https://github.com/rails/rails/pull/27288">Rails 5.1 can use Webpack and Yarn</a></li> +<li><a href="https://robots.thoughtbot.com/a-tour-of-rails-jquery-ujs">A Tour of Rails’ jQuery UJS</a></li> +<li><a href="https://knowledgelayer.softlayer.com/faq/how-does-origin-pull-work">How Does Origin Pull Work?</a></li> +<li><a href="https://github.com/airblade/paper_trail/pull/899">PaperTrail Rails 5.1 pull request</a></li> +<li><a href="https://github.com/thoughtbot/clearance/blob/master/spec/support/http_method_shim.rb">A shim for Rails 5 controller tests</a></li> +</ul> + + + + Derek briefly complains of the staleness of the asset pipeline in Rails 5, before Sean catches Derek up on Rails 5.1's support for Webpack, Yarn, and ES6. We also discuss the pain of deprecations in the upgrade to Rails 5.

+ +

Support The Bike Shed

]]> + + + Derek briefly complains of the staleness of the asset pipeline in Rails 5, before Sean catches Derek up on Rails 5.1's support for Webpack, Yarn, and ES6. We also discuss the pain of deprecations in the upgrade to Rails 5.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+BTHHvZAX + + ]]> + + + + 90: Freedom Units + https://bikeshed.thoughtbot.com/90 + b9c5f83f-84b7-41d2-8d87-f486cbc0a803 + Thu, 01 Dec 2016 11:00:00 -0500 + thoughtbot + + full + thoughtbot + We discuss adventures with shared mutable state in Elixir before turning to our thoughts on mocking HTTP interaction and how our approaches may differ depending on the language we’re using. + 35:51 + no + + <p>We discuss adventures with shared mutable state in Elixir before turning to our thoughts on mocking HTTP interaction and how our approaches may differ depending on the language we’re using.</p> +<ul> +<li><a href="//guide-staging.careporthealth.com/provider_placeholder_image.svg">How to Solve a Rubik’s Cube</a></li> +<li><a href="http://elixir-lang.org/docs/stable/elixir/GenServer.html">GenServer</a></li> +<li><a href="http://elixir-lang.org/docs/stable/elixir/Agent.html">Agent</a></li> +<li><a href="http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/">Mocks and Explicit Contracts</a> by José Valim</li> +<li><a href="https://github.com/vcr/vcr">VCR</a> and <a href="https://github.com/parroty/exvcr">exvcr</a></li> +<li><a href="http://www.knowahead.in/wp-content/uploads/2012/05/car-radio-buttons.jpg">actual radio buttons</a></li> +</ul> + + + + We discuss adventures with shared mutable state in Elixir before turning to our thoughts on mocking HTTP interaction and how our approaches may differ depending on the language we’re using.

+ +

Support The Bike Shed

]]> + + + We discuss adventures with shared mutable state in Elixir before turning to our thoughts on mocking HTTP interaction and how our approaches may differ depending on the language we’re using.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+oiCyJtD2 + + ]]> + + + + 89: There Will Never Be One Right Way (Ashley Williams) + https://bikeshed.thoughtbot.com/89 + a7c1a7da-a8c7-4a31-b73e-4f87f0cf46be + Wed, 23 Nov 2016 14:00:00 -0500 + thoughtbot + + full + thoughtbot + Ashley Williams joins the show to discuss NPM, Yarn, and the general package manager ecosystem. + 37:52 + no + + <p>Ashley Williams joins the show to discuss NPM, Yarn, and the general package manager ecosystem.</p> +<ul> +<li><a href="https://twitter.com/ag_dubs?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor">Ashley Williams</a></li> +<li><a href="http://yarnpkg.com">Yarn</a></li> +<li><a href="https://yarnpkg.com/en/docs/cli/install#toc-yarn-install-flat"><code>yarn install--flat</code></a></li> +<li><a href="https://nodejs.org/en/blog/npm/peer-dependencies/">Peer Dependency</a></li> +<li><a href="http://elixir-lang.org/docs/stable/mix/Mix.Tasks.Deps.html#module-dependency-definition-options"><code>--override</code> for Elixir dependencies</a></li> +<li><a href="https://docs.npmjs.com/cli/shrinkwrap">npm shrinkwrap</a></li> +<li><a href="http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/">Clarifying the Roles of the .gemspec and Gemfile</a></li> +<li><a href="https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935">Zero One Infinity READMEs</a></li> +<li><a href="https://github.com/ashleygwilliams/mansplain">mansplain</a></li> +<li><a href="https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935">CocoaPods' impact on GitHub</a></li> +<li><a href="https://www.youtube.com/watch?v=vgebB4sfilw&amp;list=PLQso55XhxkgBTHuvdOCaye2dIJlji4GJl&amp;index=5">npmCamp 2016 Panel - Package Managers: Before and After npm</a></li> +<li><a href="http://www.nodetogether.org">Node Together</a></li> +<li><a href="https://ashleygwilliams.github.io/a-very-brief-intro-to-rust/#1">A Very Brief Intro to Rust</a></li> +</ul> + + +

Ashley Williams joins the show to discuss NPM, Yarn, and the general package manager ecosystem.

+ +

Support The Bike Shed

]]> + + +

Ashley Williams joins the show to discuss NPM, Yarn, and the general package manager ecosystem.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+KL7xl_ZA + + ]]> + + + + 88: How Many Puppies Now? + https://bikeshed.thoughtbot.com/88 + bdb14e09-8d48-4d3c-bd04-8149a147710f + Fri, 18 Nov 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Amanda and Sean discuss talk prep and slide envy before diving in to Kotlin 1.0.5, UTF-8 identifiers in programming, and responsive layouts in Android. + 29:39 + no + + <p>Amanda and Sean discuss talk prep and slide envy before diving in to Kotlin 1.0.5, UTF-8 identifiers in programming, and responsive layouts in Android.</p> +<ul> +<li><a href="https://www.youtube.com/watch?v=lxzu6izFyTM&amp;list=PLnVy79PaFHMXJha06t6pWfkYcATV4oPvC&amp;index=29">Expandable RecyclerViews and You</a> - Amanda's DroidCon talk.</li> +<li><a href="http://www.decksetapp.com">Deckset</a></li> +<li><a href="https://youtu.be/l9JXH7JPjR4">How to Talk to Developers</a></li> +<li><a href="http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF">Is UTF-8 a Racist Kludge or Stroke of Genius?</a></li> +<li><a href="https://thoughtbot.workable.com/jobs/352194">Senior Android Developer at thoughtbot in New York City</a></li> +<li><a href="https://blog.jetbrains.com/kotlin/2016/11/kotlin-1-0-5-is-here/">Kotlin 1.0.5</a></li> +<li><a href="https://developer.android.com/training/constraint-layout/index.html">Build a Responsive UI with ConstraintLayout</a></li> +</ul> + + + + Amanda and Sean discuss talk prep and slide envy before diving in to Kotlin 1.0.5, UTF-8 identifiers in programming, and responsive layouts in Android.

+ +

Support The Bike Shed

]]> + + + Amanda and Sean discuss talk prep and slide envy before diving in to Kotlin 1.0.5, UTF-8 identifiers in programming, and responsive layouts in Android.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+sRgjA35H + + ]]> + + + + 87: The Refrigerator Took Down Your Website + https://bikeshed.thoughtbot.com/87 + ad140369-cf7f-4db7-8f52-a685019d2818 + Thu, 10 Nov 2016 17:00:00 -0500 + thoughtbot + + full + thoughtbot + We talk about a widespread DNS outage and what steps you might take to avoid or limit your application's exposure to these things in the future. + 32:01 + no + + <p>We talk about a widespread DNS outage and what steps you might take to avoid or limit your application's exposure to these things in the future.</p> +<ul> +<li><a href="https://github.com/rails/rails/pull/25337">Deprecate the behavior of AR::Dirty inside of after_(create|update|save) callbacks</a></li> +<li><a href="http://dyn.com/blog/dyn-statement-on-10212016-ddos-attack/">Distributed Denial of Service attack on DNS Provider Dyn</a></li> +<li><a href="https://support.dnsimple.com/articles/alias-record/">What is an <code>ALIAS</code> Record?</a></li> +<li><a href="http://www.dnsmadeeasy.com/services/anamerecords/"><code>ANAME</code> records</a></li> +<li><a href="http://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-aka-root-of-a-domain">Why can't a <code>CNAME</code> record be used at the apex (aka root) of a domain?</a></li> +<li><a href="https://github.com/thoughtbot/guides/pull/347">Avoid using non-standard DNS entries</a></li> +<li><a href="https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links">Is Your Site Leaking Password Reset Links?</a> with <a href="https://news.ycombinator.com/item?id=12777896">Comments from Hacker News</a></li> +</ul> + + + + We talk about a widespread DNS outage and what steps you might take to avoid or limit your application's exposure to these things in the future.

+ +

Support The Bike Shed

]]> + + + We talk about a widespread DNS outage and what steps you might take to avoid or limit your application's exposure to these things in the future.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+AfHbziOk + + ]]> + + + + 86: Purple Train, Purrrple Train (Ian Anderson) + https://bikeshed.thoughtbot.com/86 + c0ce39cf-217c-452a-815a-d68ba2184a0b + Wed, 02 Nov 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek chats with Ian Anderson about developing a mobile app for iOS and Android with React Native. + 30:46 + no + + <p>Derek chats with Ian Anderson about developing a mobile app for iOS and Android with React Native.</p> +<ul> +<li><a href="https://twitter.com/iancanderson">Ian on Twitter</a></li> +<li><a href="https://www.youtube.com/watch?v=yZLJRGPhBck&amp;t=21s">Purple (T)Rain</a></li> +<li><a href="http://elixir-lang.org/docs/stable/elixir/GenServer.html">GenServer</a></li> +<li><a href="http://elixir-lang.org/docs/stable/elixir/Agent.html">Agent</a></li> +<li><a href="https://facebook.github.io/react-native/">React Native</a></li> +<li><a href="https://github.com/facebook/flow">Flow</a></li> +<li><a href="https://github.com/ohanhi/elm-native-ui">Elm Native UI</a></li> +<li><a href="https://github.com/necolas/react-native-web">React Native Web</a></li> +</ul> + + + + Derek chats with Ian Anderson about developing a mobile app for iOS and Android with React Native.

+ +

Support The Bike Shed

]]> + + + Derek chats with Ian Anderson about developing a mobile app for iOS and Android with React Native.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+VPWt1Wf9 + + ]]> + + + + 85: Are We in a Black Hole? + https://bikeshed.thoughtbot.com/85 + 013abaf4-2b0c-4b0c-87a1-48d3f973274d + Wed, 26 Oct 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We briefly ponder the very nature of our existence before discussing edge cases and interesting bugs encountered in ActiveRecord. + 53:13 + no + + <p>We briefly ponder the very nature of our existence before discussing edge cases and interesting bugs encountered in ActiveRecord.</p> +<ul> +<li><a href="http://tbot.io/survey">Podcast Patreon Survey</a></li> +<li><a href="http://bigthink.com/think-tank/we-may-be-living-inside-a-black-hole">We May Be Living Inside a Black Hole</a></li> +<li><a href="https://www.scientificamerican.com/article/are-we-living-in-a-computer-simulation/">Are We Living in a Computer Simulation?</a></li> +<li><a href="https://en.wikipedia.org/wiki/R-7_(rocket_family)">The R-7 Rocket Family</a></li> +<li><a href="http://www.nature.com/news/computing-glitch-may-have-doomed-mars-lander-1.20861">Computing Glitch May Have Doomed Mars lander</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#method-i-from">ActiveRecord’s <code>from</code> method</a></li> +<li><a href="https://robots.thoughtbot.com/activerecords-wherenot">ActiveRecord’s <code>where.not</code> method</a></li> +<li><a href="https://github.com/rails/rails/blob/master/activerecord/lib/active_record/relation/where_clause.rb">ActiveRecord’s <code>WhereClause</code> class</a></li> +<li><a href="https://github.com/rails/rails/issues/13420">Let’s fix <code>deepmunge</code></a></li> +<li><a href="https://en.wikipedia.org/wiki/Object-relationalimpedance_mismatch">Object-relation impedance mismatch</a></li> +</ul> + + +

We briefly ponder the very nature of our existence before discussing edge cases and interesting bugs encountered in ActiveRecord.

+ +

Support The Bike Shed

]]> + + +

We briefly ponder the very nature of our existence before discussing edge cases and interesting bugs encountered in ActiveRecord.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ULoPXEvG + + ]]> + + + + 84: Why Are Manhole Covers Round? + https://bikeshed.thoughtbot.com/84 + 37c33c60-f331-4575-a9dd-0cadab4381be + Wed, 19 Oct 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + What do we look for when reviewing job applications, interviewing candidates, and pairing with prospective co-workers? + 50:42 + no + + <p>What do we look for when reviewing job applications, interviewing candidates, and pairing with prospective co-workers?</p> +<ul> +<li><a href="https://tbot.io/survey">thoughtbot Podcast Listener Survey</a></li> +<li><a href="https://code.facebook.com/posts/1840075619545360">Yarn: A new package manager for JavaScript</a></li> +<li><a href="https://www.npmjs.com/about">About NPM</a></li> +<li><a href="https://thoughtbot.workable.com">Jobs at thoughtbot</a></li> +<li><a href="https://github.com/thoughtbot/liftoff/pull/178">LAMP Stack recruitment in GitHub Issues</a></li> +<li><a href="https://github.com/thoughtbot/factory_girl/commit/d5417ced422ad6bde58a48e0b4be3a4a17b614cc">The fruits of Derek’s FactoryGirl pairing session</a></li> +<li><a href="https://en.wikipedia.org/wiki/Infield_fly_rule">The Infield Fly Rule</a></li> +</ul> + + + + What do we look for when reviewing job applications, interviewing candidates, and pairing with prospective co-workers?

+ +

Support The Bike Shed

]]> + + + What do we look for when reviewing job applications, interviewing candidates, and pairing with prospective co-workers?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+QjfwgYW4 + + ]]> + + + + 83: Canadian Halloween + https://bikeshed.thoughtbot.com/83 + 7120fd4d-b0ea-4c93-ad4c-cd29cfd8f9e4 + Wed, 12 Oct 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean encounters a roadblock in updating Diesel to use Rust’s new soon-to-be-stabilized procedural macros. Derek and Sean discuss the most recent CVE filed for Bundler, which is a lot like the previous CVE filed for Bundler. + 27:37 + no + + <p>Sean encounters a roadblock in updating Diesel to use Rust’s new soon-to-be-stabilized procedural macros. Derek and Sean discuss the most recent CVE filed for Bundler, which is a lot like the previous CVE filed for Bundler.</p> +<ul> +<li><a href="https://github.com/diesel-rs/diesel/releases/tag/v0.8.0">Diesel 0.8.0</a></li> +<li><a href="http://rustbyexample.com/trait/derive.html">Derive</a></li> +<li><a href="https://github.com/rust-lang/rfcs/pull/1681">Rust Macros 1.1</a></li> +<li><a href="https://developers.google.com/gmail/design/css">CSS Support in GMail</a></li> +<li><a href="https://developers.google.com/gmail/api/">GMail REST API</a></li> +<li><a href="http://collectiveidea.com/blog/archives/2016/10/06/bundlers-multiple-source-security-vulnerability/">Bundler’s Multiple Source Security Vulnerability</a></li> +<li><a href="https://github.com/bundler/bundler/issues/5062">Bundler Response</a></li> +<li><a href="https://tbot.io/survey">Listener Survey</a></li> +</ul> + + + + Sean encounters a roadblock in updating Diesel to use Rust’s new soon-to-be-stabilized procedural macros. Derek and Sean discuss the most recent CVE filed for Bundler, which is a lot like the previous CVE filed for Bundler.

+ +

Support The Bike Shed

]]> + + + Sean encounters a roadblock in updating Diesel to use Rust’s new soon-to-be-stabilized procedural macros. Derek and Sean discuss the most recent CVE filed for Bundler, which is a lot like the previous CVE filed for Bundler.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NZiK5abB + + ]]> + + + + 82: I Just Want a Dog in a Spacesuit + https://bikeshed.thoughtbot.com/82 + 743c0701-103c-44e5-bf0c-705853f46cd3 + Wed, 05 Oct 2016 10:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss the problems with getting a CVE and the new lightning fast search tool, ripgrep. Sandwiched between those topics, we dive into the colonization of Mars. Yes, that's right, Mars. + 50:51 + no + + <p>We discuss the problems with getting a CVE and the new lightning fast search tool, ripgrep. Sandwiched between those topics, we dive into the colonization of Mars. Yes, that's right, Mars.</p> +<ul> +<li><a href="http://tbot.io/survey">Podcast Patreon Survey</a></li> +<li><a href="https://github.com/thoughtbot/clearance/pull/707">Clearance password reset fix</a></li> +<li><a href="https://iwantacve.org">iwantacve.org</a></li> +<li><a href="http://www.csoonline.com/article/3122460/techology-business/over-6000-vulnerabilities-went-unassigned-by-mitres-cve-project-in-2015.html">Over 6,000 vulnerabilities went unassigned by MITRE's CVE project in 2015</a></li> +<li><a href="https://robots.thoughtbot.com/handling-security-issues-in-open-source-projects">Handling Security Issues in Open Source Projects</a> by Tute Costa</li> +<li><a href="https://www.youtube.com/watch?v=IFA6DLT1jBA">Elon Musk unveils plan to colonise Mars</a></li> +<li><a href="http://www.spacex.com/careers/list">SpaceX Jobs</a></li> +<li><a href="https://en.wikipedia.org/wiki/Red_Dragon_(spacecraft)">Red Dragon Spacecraft</a></li> +<li><a href="http://www.nasa.gov/audience/forstudents/5-8/features/nasa-knows/what-is-orion-58.html">NASA Orion</a></li> +<li><a href="https://www.youtube.com/watch?v=-O_DMyHdq_M">Major Malfunction: Revisiting Challenger</a></li> +<li><a href="http://blog.burntsushi.net/ripgrep/">ripgrep is faster than {grep, ag, git grep, ucg, pt, sift}</a></li> +<li><a href="https://en.wikipedia.org/wiki/Roentgenium">111 Rg</a></li> +<li><a href="https://news.ycombinator.com/item?id=12567328">A pleasant HackerNews comment thread</a></li> +</ul> + + + + We discuss the problems with getting a CVE and the new lightning fast search tool, ripgrep. Sandwiched between those topics, we dive into the colonization of Mars. Yes, that's right, Mars.

+ +

Support The Bike Shed

]]> + + + We discuss the problems with getting a CVE and the new lightning fast search tool, ripgrep. Sandwiched between those topics, we dive into the colonization of Mars. Yes, that's right, Mars.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+_Pb_GT0_ + + ]]> + + + + 81: Is This Really a CVE? + https://bikeshed.thoughtbot.com/81 + 077f3e86-86dc-4614-ab8b-ab80cd9f657b + Wed, 28 Sep 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean talk through how to handle a security vulnerability that was reported for Clearance, a user authentication library. + 27:21 + no + + <p>Derek and Sean talk through how to handle a security vulnerability that was reported for Clearance, a user authentication library.</p> +<ul> +<li><a href="http://images.thoughtbot.com/podcasts/general/CardboardJankowski.jpg">Cardboard Jankowski</a></li> +<li><a href="https://github.com/thoughtbot/clearance/pull/707">Prevent password reset token leak via HTTP referer</a></li> +<li><a href="https://moz.com/blog/meta-referrer-tag">The Meta Referrer Tag</a></li> +<li><a href="https://cve.mitre.org">CVE</a></li> +<li><a href="https://github.com/rubysec/bundler-audit">Bundler Audit</a></li> +<li><a href="https://github.com/rubysec/ruby-advisory-db">Ruby Advisory Database</a></li> +<li><a href="https://groups.google.com/forum/#!forum/ruby-security-ann">Ruby security announcement mailing list</a></li> +<li><a href="https://www.destroyallsoftware.com/screencasts">Destroy All Software</a></li> +</ul> + + + + Derek and Sean talk through how to handle a security vulnerability that was reported for Clearance, a user authentication library.

+ +

Support The Bike Shed

]]> + + + Derek and Sean talk through how to handle a security vulnerability that was reported for Clearance, a user authentication library.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+A2HqnLeB + + ]]> + + + + 80: Back to the Futures + https://bikeshed.thoughtbot.com/80 + f90548fe-1898-4d71-9e6f-0da76a9ae303 + Wed, 21 Sep 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + What's appropriate for a web middleware stack to provide? Does Rack do too much? Plus, our thoughts on NeoVim and Vim 8. + 39:00 + no + + <p>What's appropriate for a web middleware stack to provide? Does Rack do too much? Plus, our thoughts on NeoVim and Vim 8.</p> +<ul> +<li><a href="https://aturon.github.io/blog/2016/08/11/futures/">Futures-RS</a></li> +<li><a href="https://robots.thoughtbot.com/my-life-with-neovim">My Life With NeoVim</a></li> +<li><a href="https://github.com/vim/vim/blob/master/runtime/doc/version8.txt">Vim 8</a></li> +<li><a href="https://groups.google.com/forum/#!msg/vim_dev/-4pqDJfHCsM/LkYNCpZjQ70J">Asynchronous functions patch discussion</a></li> +<li><a href="https://github.com/thoughtbot/gitsh">gitsh</a></li> +<li><a href="https://github.com/google/xi-editor">Xi Editor</a></li> +<li><a href="https://groups.google.com/d/msg/elm-discuss/1acyOfxvasA/oN7uBjdSDZcJ">Stop saying &quot;the ____ monad&quot;</a></li> +</ul> + + + + What's appropriate for a web middleware stack to provide? Does Rack do too much? Plus, our thoughts on NeoVim and Vim 8.

+ +

Support The Bike Shed

]]> + + + What's appropriate for a web middleware stack to provide? Does Rack do too much? Plus, our thoughts on NeoVim and Vim 8.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+wazb5Een + + ]]> + + + + 79: Comments in Your Queries + https://bikeshed.thoughtbot.com/79 + 1167599b-58e3-40ed-8349-7b539e6061fc + Wed, 14 Sep 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean talk through some complex SQL before they examine the calluses developed from years of writing software on OS X. + 41:18 + no + + <p>Derek and Sean talk through some complex SQL before they examine the calluses developed from years of writing software on OS X.</p> +<ul> +<li><a href="https://twitter.com/devoncestes/status/773363608042418177">Press 1 for Lobby</a></li> +<li><a href="https://github.com/activerecord-hackery/ransack">Ransack</a></li> +<li><a href="https://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT"><code>EXTRACT</code></a></li> +<li><a href="https://en.wikipedia.org/wiki/Pivot_table">Pivot Tables</a></li> +<li><a href="https://www.postgresql.org/docs/current/static/tablefunc.html"><code>crosstab</code></a></li> +<li><a href="https://gist.github.com/derekprior/3a99e111012174b8edf0be9307c65adf">Derek’s <code>crosstab</code> Query</a></li> +<li><a href="https://www.postgresql.org/docs/current/static/tutorial-window.html">Window Functions</a></li> +<li><a href="https://www.postgresql.org/docs/9.1/static/functions-srf.html">Set Returning Functions</a></li> +<li><a href="http://stackoverflow.com/questions/8095209/uninstall-all-installed-gems-in-osx">Uninstall All Installed Gems on OS X</a></li> +</ul> + + + + Derek and Sean talk through some complex SQL before they examine the calluses developed from years of writing software on OS X.

+ +

Support The Bike Shed

]]> + + + Derek and Sean talk through some complex SQL before they examine the calluses developed from years of writing software on OS X.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+45ze56S4 + + ]]> + + + + 78: I'm an Adult and I Choose Java + https://bikeshed.thoughtbot.com/78 + 6e568aa4-632a-4752-83c9-74332dddf3a0 + Fri, 09 Sep 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Amanda discuss the state of Android Development in 2016. Java, Kotlin, Dependency Injection, and Functional Reactive Programming, oh my! + 50:11 + no + + <p>Sean and Amanda discuss the state of Android Development in 2016. Java, Kotlin, Dependency Injection, and Functional Reactive Programming, oh my!</p> +<ul> +<li><a href="https://twitter.com/mandybess">Amanda Hill on Twitter</a></li> +<li><a href="https://developer.android.com/studio/command-line/adb.html">Android Debug Bridge</a> (ADB)</li> +<li><a href="https://developer.android.com/studio/index.html">Android Studio</a> - The Official IDE for Android</li> +<li><a href="https://www.jetbrains.com">JetBrains</a></li> +<li><a href="https://kotlinlang.org">Kotlin</a></li> +<li><a href="http://troposweather.com">Tropos Weather</a></li> +<li><a href="https://github.com/thoughtbot/Runes">Runes: Monadic Functions in Swift</a></li> +<li><a href="https://developer.android.com/training/location/receive-location-updates.html">Receiving Location Updates in Android</a></li> +<li><a href="http://square.github.io/dagger/">Dagger: A fast dependency injector for Android</a></li> +<li><a href="https://robots.thoughtbot.com/introducing-expandablerecyclerview">Introducing ExpandingRecyclerView</a></li> +<li><a href="https://github.com/ReactiveX/RxAndroid">RxAndroid</a></li> +<li><a href="https://martialcodex.com">Marial Codex</a></li> +</ul> + + + + Sean and Amanda discuss the state of Android Development in 2016. Java, Kotlin, Dependency Injection, and Functional Reactive Programming, oh my!

+ +

Support The Bike Shed

]]> + + + Sean and Amanda discuss the state of Android Development in 2016. Java, Kotlin, Dependency Injection, and Functional Reactive Programming, oh my!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+bbNSwb5O + + ]]> + + + + 77: The Floors Are Not Zero Indexed + https://bikeshed.thoughtbot.com/77 + c2838e93-ce7b-433c-8fcb-9d349f55f896 + Wed, 31 Aug 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + How can you get your open source pull request merged? + 32:52 + no + + <p>How can you get your open source pull request merged?</p> +<ul> +<li><a href="http://i.imgur.com/3WhRd8H.jpg">Elevator number pad</a></li> +<li>Sorry, video of Sean’s Abstractions Conference talk is not yet available</li> +<li><a href="https://github.com/thoughtbot/clearance/pull/687">Clearance PR discussion driven by contributors</a></li> +<li><a href="http://www.justinweiss.com/articles/rails-5-module-number-prepend-and-the-end-of-alias-method-chain/"><code>Module#prepend</code> is the end of <code>alias_method_chain</code></a> - by Justin Weiss</li> +</ul> + + + + How can you get your open source pull request merged?

+ +

Support The Bike Shed

]]> + + + How can you get your open source pull request merged?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+afdxmZ0V + + ]]> + + + + 76: The One With Laila & Brenda + https://bikeshed.thoughtbot.com/76 + 61b1bfc3-cda5-4953-b6c5-3593a9db308b + Wed, 17 Aug 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Between thoughtbot's Summer Summit and Sean's vacation, we are sadly without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila & Brenda Show! + +Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts! + 40:58 + no + + <p>Between thoughtbot's Summer Summit and Sean's vacation, we are sadly without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila &amp; Brenda Show!</p> +<p>Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts!</p> +<ul> +<li><a href="http://lailaandbrenda.fm/">The Laila &amp; Brenda Show</a></li> +</ul> + + + + Between thoughtbot's Summer Summit and Sean's vacation, we are sadly without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila & Brenda Show!

+ +

Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts!

+ +

Support The Bike Shed

]]> + + + Between thoughtbot's Summer Summit and Sean's vacation, we are sadly without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila & Brenda Show!

+ +

Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts!

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Qb0bbhqC + + ]]> + + + + 75: I'm Not Sure That's Better + https://bikeshed.thoughtbot.com/75 + eca869eb-82ef-4140-8982-3107a1bc4664 + Thu, 11 Aug 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss hunting down intermittently failing tests, finding unused code in your application, and why you should never ever change your test framework. + 33:49 + no + + <p>Derek and Sean discuss hunting down intermittently failing tests, finding unused code in your application, and why you should never ever change your test framework.</p> +<ul> +<li><a href="https://relishapp.com/rspec/rspec-core/docs/command-line/bisect">RSpec Bisect</a></li> +<li><a href="http://rspec.info/blog/2015/06/rspec-3-3-has-been-released/">RSpec 3.3 Release Notes</a></li> +<li><a href="https://robots.thoughtbot.com/git-bisect">Git Bisect</a></li> +<li><a href="http://unused.codes">Unused</a></li> +<li><a href="https://en.wikipedia.org/wiki/Halting_problem">The Halting Problem</a></li> +<li><a href="https://github.com/diesel-rs/diesel/releases/tag/v0.7.0">Diesel 0.7</a></li> +</ul> + + + + Derek and Sean discuss hunting down intermittently failing tests, finding unused code in your application, and why you should never ever change your test framework.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss hunting down intermittently failing tests, finding unused code in your application, and why you should never ever change your test framework.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ziiiOKm- + + ]]> + + + + 74: A Dip in the Connection Pool + https://bikeshed.thoughtbot.com/74 + de7bf874-70ef-4feb-b1b2-9cfbc86ce5ab + Wed, 03 Aug 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We talk through design considerations for a user-visible custom query builder for a high volume ecommerce system. + 34:48 + no + + <p>We talk through design considerations for a user-visible custom query builder for a high volume ecommerce system.</p> +<ul> +<li><a href="https://github.com/activerecord-hackery/ransack">Ransack</a></li> +<li><a href="https://robots.thoughtbot.com/using-arel-to-compose-sql-queries">Using Arel to Compose SQL Queries</a></li> +<li><a href="https://pgbouncer.github.io">PgBouncer</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/ConnectionHandling.html#method-i-establish_connection"><code>establish_connection</code></a></li> +<li><a href="https://www.expeditedssl.com/aws-in-plain-english">AWS in Plain English</a></li> +<li><a href="https://github.com/Dania02525/apartmentex">ApartmentEx</a></li> +<li><a href="https://github.com/jashkenas/underscore/issues/2182">Underscore + Lodash</a></li> +</ul> + + + + We talk through design considerations for a user-visible custom query builder for a high volume ecommerce system.

+ +

Support The Bike Shed

]]> + + + We talk through design considerations for a user-visible custom query builder for a high volume ecommerce system.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+X_TP5azR + + ]]> + + + + 73: Probably In My Other Pants + https://bikeshed.thoughtbot.com/73 + 933c28f7-63d6-4a35-afb6-f5f9701ae108 + Thu, 28 Jul 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss Pokémon Go and what its success might mean for software developers before Sean lays out his case for replacing the `pg` gem and `libpq`. + 43:31 + no + + <p>We discuss Pokémon Go and what it's success might mean for software developers before Sean lays out his case for replacing the <code>pg</code> gem and <code>libpq</code>.</p> +<ul> +<li><a href="https://fullstackradio.com/45">Derek on Full Stack Radio</a></li> +<li><a href="https://lailaandbrenda.fm">The Laila and Brenda Show</a></li> +<li>Google's <a href="https://en.wikipedia.org/wiki/Project_Tango">Project Tango</a> devices</li> +<li><a href="http://searchsecurity.techtarget.com/news/450300257/Pokemon-GO-reveals-full-account-access-flaw-for-Google-authentication">Pokemon Go gets full access Google auth token</a></li> +<li><a href="http://bikeshed.fm/35">Why your email address isn't your identity</a></li> +<li><a href="https://bitbucket.org/ged/ruby-pg/wiki/Home">The <code>pg</code> gem</a></li> +<li><a href="https://www.postgresql.org/docs/9.1/static/libpq.html"><code>libpq</code></a></li> +<li><a href="https://msdn.microsoft.com/en-us/library/ms187752.aspx">SQL Server data types</a></li> +</ul> + + + + We discuss Pokémon Go and what it's success might mean for software developers before Sean lays out his case for replacing the pg gem and libpq.

+ +

Support The Bike Shed

]]> + + + We discuss Pokémon Go and what it's success might mean for software developers before Sean lays out his case for replacing the pg gem and libpq.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ub3uM69D + + ]]> + + + + 72: Surprises Cut For Time (Aaron Patterson) + https://bikeshed.thoughtbot.com/72 + d781e8ee-fc08-4ce1-9722-a738ed0a07e8 + Wed, 20 Jul 2016 10:00:00 -0400 + thoughtbot + + full + thoughtbot + Aaron Patterson joins us from RailsConf for puns, performance improvements in Ruby, and AirDropping cats. + 43:28 + no + + <p>Aaron Patterson joins us from RailsConf for puns, performance improvements in Ruby, and AirDropping cats.</p> +<ul> +<li><a href="http://images.thoughtbot.com/podcasts/bikeshed/gorbypuff_virus.jpg">Gorbypuff Virus</a></li> +<li><a href="http://stackoverflow.com/questions/496321/utf8-utf16-and-utf32">UTF8 vs UTF16 vs UTF32</a></li> +<li><a href="https://blog.engineyard.com/2013/rails-4-queue-api">What happened to the Rails 4 queue API?</a></li> +<li><a href="http://confreaks.tv/videos/railsconf2016-precompiling-ruby-scripts-myth-and-fact">Koichi talks about AOT compilation</a></li> +<li>Aaron hates encoding. This isn't a link, just a fact.</li> +<li><a href="https://github.com/sgrif/dotfiles/blob/master/bin/test">Sean's terrifying test script, slightly out of date</a></li> +<li><a href="https://github.com/tpope/vim-rails">rails.vim, the tpope jam</a></li> +</ul> + + + + Aaron Patterson joins us from RailsConf for puns, performance improvements in Ruby, and AirDropping cats.

+ +

Support The Bike Shed

]]> + + + Aaron Patterson joins us from RailsConf for puns, performance improvements in Ruby, and AirDropping cats.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+2k382ZMC + + ]]> + + + + 71: It's a Total Hack + https://bikeshed.thoughtbot.com/71 + bd85d13f-b4a7-4e39-bd29-9a7f60ce4f3d + Wed, 13 Jul 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Inspired by Nickolas Means’ fantastic RailsConf keynote, we discuss the corollaries between Lockheed Martin’s Skunk Works projects and our software development projects. + 42:25 + no + + <p>Inspired by Nickolas Means’ fantastic RailsConf keynote, we discuss the corollaries between Lockheed Martin’s Skunk Works projects and our software development projects.</p> +<ul> +<li>Sean’s <a href="http://www.dxracer.com/us/en-us/">DXRacer Chair</a></li> +<li><a href="https://www.youtube.com/watch?v=ggPE-JHzfAM&amp;index=2&amp;list=PLE7tQUdRKcyZGYLfj6oRQWPxB6ijg1YsC">Skunk Works</a> by Nickolas Means</li> +<li><a href="https://en.wikipedia.org/wiki/Lockheed_Martin_F-35_Lightning_II">Lockheed Martin F-35 Lightning II</a></li> +<li><a href="https://en.wikipedia.org/wiki/Big_Design_Up_Front">Big Design Up Front</a></li> +<li><a href="http://www.lockheedmartin.com/us/aeronautics/skunkworks/14rules.html">Kelly’s 14 Rules and Processes</a></li> +<li><a href="https://robots.thoughtbot.com/rules-made-up-by-you">Rules Made Up by You</a> - Kelly’s rules as applied to modern software development</li> +<li><a href="https://www.youtube.com/watch?v=WCr478LuSV4">Factory, Workshop, Stage</a> by Sarah Mei</li> +<li><a href="https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness">The Tyranny of Structurelessness</a></li> +<li><a href="https://www.youtube.com/watch?v=S2FUSr3WlPk">How to Crash an Airplane</a> by Nickolas Means</li> +</ul> + + + + Inspired by Nickolas Means’ fantastic RailsConf keynote, we discuss the corollaries between Lockheed Martin’s Skunk Works projects and our software development projects.

+ +

Support The Bike Shed

]]> + + + Inspired by Nickolas Means’ fantastic RailsConf keynote, we discuss the corollaries between Lockheed Martin’s Skunk Works projects and our software development projects.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ROBR0Q5o + + ]]> + + + + 70: Make Small Things (Sandi Metz) + https://bikeshed.thoughtbot.com/70 + 70b37d8b-f701-4778-a938-4ba27f2d2012 + Wed, 06 Jul 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sandi Metz joins us live from RailsConf to talk about the rules, the trouble with naming things, making the right kinds of errors, and conference speaking. + +A big thanks to everyone who came out to our live show! A video version of this episode is available on the thoughtbot YouTube Page. + 1:04:21 + no + + <p>Sandi Metz joins us live from RailsConf to talk about the rules, the trouble with naming things, making the right kinds of errors, and conference speaking.</p> +<ul> +<li><a href="http://bikeshed.fm/1">The Bike Shed - Episode 1: Sandi and Derek's Rules</a></li> +<li><a href="https://robots.thoughtbot.com/sandi-metz-rules-for-developers">Sandi Metz' Rules For Developers</a></li> +<li><a href="https://devchat.tv/ruby-rogues/087-rr-book-club-practical-object-oriented-design-in-ruby-with-sandi-metz">Sandi on the Ruby Rogues</a></li> +<li><a href="http://c2.com/cgi/wiki?DontCreateVerbClasses">Don't Create Verb Classes</a></li> +<li><a href="http://mjtsai.com/blog/2015/12/21/swift-proposal-for-default-final/">Swift Proposal for Default Final</a></li> +<li><a href="https://www.youtube.com/watch?v=v-2yFMzxqwU">GoRuCo 2009: SOLID Object-Oriented Design by Sandi Metz</a></li> +<li><a href="https://www.youtube.com/watch?v=l9JXH7JPjR4">How to Talk to Developers by Ben Orenstein</a></li> +<li><a href="http://www.sarahmei.com/blog/2014/04/07/what-your-conference-proposal-is-missing/">What Your Conference Proposal is Missing</a> by Sarah Mei</li> +</ul> +<p>A big thanks to everyone who came out to our live show! A video version of this episode is available on the <a href="https://youtu.be/3DEA8njVTIc">thoughtbot YouTube Page</a>.</p> + + + + Sandi Metz joins us live from RailsConf to talk about the rules, the trouble with naming things, making the right kinds of errors, and conference speaking.

+ + + +

A big thanks to everyone who came out to our live show! A video version of this episode is available on the thoughtbot YouTube Page.

Support The Bike Shed

]]> + + + Sandi Metz joins us live from RailsConf to talk about the rules, the trouble with naming things, making the right kinds of errors, and conference speaking.

+ + + +

A big thanks to everyone who came out to our live show! A video version of this episode is available on the thoughtbot YouTube Page.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+FdQKr6kK + + ]]> + + + + 69: No More Drills + https://bikeshed.thoughtbot.com/69 + c3746f70-85a5-4479-9770-0b4de69a1417 + Wed, 29 Jun 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We discuss thoughtbot's increasing use of Elixir and Phoenix and what that means for our Rails work before diving into what's new in Elixir 1.3 and Ecto 2.0. + 40:31 + no + + <p>We discuss thoughtbot's increasing use of Elixir and Phoenix and what that means for our Rails work before diving into what's new in Elixir 1.3 and Ecto 2.0.</p> +<ul> +<li><a href="https://www.youtube.com/watch?v=IUPu_ipbVB0">Jonathon Coulton: IKEA</a></li> +<li>Derek's <a href="https://twitter.com/derekprior/status/743241973079801856">thoughtbot ♥️ Elixir</a> tweet.</li> +<li><a href="https://robots.thoughtbot.com/fuck-bullshit">Fuck Bullshit</a></li> +<li><a href="https://www.youtube.com/watch?v=l7daHWnPlD0">HTC Vive Office Simulator Demo</a></li> +<li><a href="https://github.com/thoughtbot/ex_machina">ExMachina</a> and <a href="https://github.com/thoughtbot/bamboo">Bamboo</a> from <a href="https://twitter.com/paulcsmith">Paul Smith</a></li> +<li><a href="https://github.com/elixir-lang/elixir/blob/v1.3/CHANGELOG.md">Elixir 1.3 CHANGELOG</a></li> +<li><a href="https://github.com/elixir-ecto/ecto/blob/master/CHANGELOG.md">Ecto 2.0 CHANGELOG</a></li> +<li><a href="https://dockyard.com/blog/2016/03/25/what-makes-phoenix-presence-special-sneak-peek">Phoenix Presence</a></li> +</ul> + + + + We discuss thoughtbot's increasing use of Elixir and Phoenix and what that means for our Rails work before diving into what's new in Elixir 1.3 and Ecto 2.0.

+ +

Support The Bike Shed

]]> + + + We discuss thoughtbot's increasing use of Elixir and Phoenix and what that means for our Rails work before diving into what's new in Elixir 1.3 and Ecto 2.0.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+QLAS5-86 + + ]]> + + + + 68: Mostly Undocumented + https://bikeshed.thoughtbot.com/68 + 4b099f47-75f1-4553-ac22-7e60bb04f68d + Wed, 22 Jun 2016 10:30:00 -0400 + thoughtbot + + full + thoughtbot + Sean runs through a Rails bug that sits at the intersection of several magical and confusing Rails features. + 33:09 + no + + <p>Sean runs through a Rails bug that sits at the intersection of several magical and confusing Rails features.</p> +<ul> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html"><code>accepts_nested_attributes_for</code></a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#module-ActiveRecord::Associations::ClassMethods-label-Setting+Inverses"><code>inverse_of</code></a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/AutosaveAssociation.html"><code>autosave</code></a></li> +<li><a href="https://github.com/rails/rails/pull/25337">The proposed fix for 5.1.0</a></li> +<li><a href="http://www.datomic.com">Datomic</a></li> +</ul> + + + + Sean runs through a Rails bug that sits at the intersection of several magical and confusing Rails features.

+ +

Support The Bike Shed

]]> + + + Sean runs through a Rails bug that sits at the intersection of several magical and confusing Rails features.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MhT7t5d1 + + ]]> + + + + 67: Longtime Listener, First Time Caller (Rafael Franca) + https://bikeshed.thoughtbot.com/67 + d3d9953c-cfe4-4039-9ef0-95d91034c936 + Wed, 15 Jun 2016 11:00:00 -0400 + thoughtbot + + full + thoughtbot + Leading Rails contributor Rafael Franca joins us from RailsConf to talk about taking over Sprockets, the future of the asset pipeline in Rails, managing Rails dependencies, and the hard work of software maintenance. + +Also, Sean said you'd all "definitely" have the final build of Rails 5 by now. Whoops! + 39:30 + no + + <p>Leading Rails contributor Rafael Franca joins us from RailsConf to talk about taking over Sprockets, the future of the asset pipeline in Rails, managing Rails dependencies, and the hard work of software maintenance.</p> +<ul> +<li><a href="https://twitter.com/rafaelfranca">Rafael Franca</a></li> +<li><a href="http://contributors.rubyonrails.org">Rails Contributors</a></li> +<li><a href="https://github.com/rails/sprockets">Sprockets</a></li> +<li><a href="https://github.com/rails/sprockets/pull/193">Reintroducing gzip file generation in Sprockets</a></li> +<li><a href="http://sass-lang.com/libsass">LibSass</a> is Sass in C (and fast)</li> +<li><a href="http://compass-style.org/help/tutorials/spriting/">Spriting with Compass</a></li> +<li><a href="https://github.com/tenex/rails-assets/issues/312">Rails Assets is not Dead</a></li> +<li><a href="https://github.com/Shopify/turbograft">turbograft</a></li> +<li><a href="http://www.ecma-international.org/memento/TC39.htm">TC39</a></li> +</ul> +<p>Sean said you'd all &quot;definitely&quot; have the final build of Rails 5 by now. Whoops!</p> + + + + Leading Rails contributor Rafael Franca joins us from RailsConf to talk about taking over Sprockets, the future of the asset pipeline in Rails, managing Rails dependencies, and the hard work of software maintenance.

+ + + +

Sean said you'd all "definitely" have the final build of Rails 5 by now. Whoops!

Support The Bike Shed

]]> + + + Leading Rails contributor Rafael Franca joins us from RailsConf to talk about taking over Sprockets, the future of the asset pipeline in Rails, managing Rails dependencies, and the hard work of software maintenance.

+ + + +

Sean said you'd all "definitely" have the final build of Rails 5 by now. Whoops!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+hB-6EdAi + + ]]> + + + + 66: Make Ruby Scripting Great Again (Terence Lee) + https://bikeshed.thoughtbot.com/66 + ff7d046a-3d70-42e1-a794-bea98836a7f4 + Wed, 08 Jun 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We talk with Terence Lee of Heroku, Bundler, and mruby-cli fame about Apache Kafka and the future of mruby scripting. + 39:31 + no + + <p>We talk with Terence Lee of Heroku, Bundler, and mruby-cli fame about Apache Kafka and the future of mruby scripting.</p> +<ul> +<li><a href="https://twitter.com/hone02?lang=en">Terence Lee</a></li> +<li><a href="http://kafka.apache.org">Kafka</a></li> +<li><a href="https://www.youtube.com/watch?v=s3VQIGD5iGo">I Can’t Believe It’s Not A Queue: Using Kafka with Rails</a> - Terence’s RailsConf talk.</li> +<li><a href="https://github.com/mruby/mruby">mruby</a></li> +<li><a href="https://github.com/hone/mruby-cli">mruby-cli</a></li> +<li><a href="https://github.com/phusion/traveling-ruby">Traveling Ruby</a></li> +<li><a href="http://keeprubyweird.com">Keep Ruby Weird</a></li> +</ul> + + + + We talk with Terence Lee of Heroku, Bundler, and mruby-cli fame about Apache Kafka and the future of mruby scripting.

+ +

Support The Bike Shed

]]> + + + We talk with Terence Lee of Heroku, Bundler, and mruby-cli fame about Apache Kafka and the future of mruby scripting.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GCLDtS1b + + ]]> + + + + 65: Free as in Puppy (Katrina Owen) + https://bikeshed.thoughtbot.com/65 + 07cc8c1b-b647-43af-84a0-f4762cf22fd0 + Wed, 25 May 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + While at RailsConf, we talk with Katrina Owen about finding metaphors for software development, the successes and mistakes of Exercism.io, and the benefits of providing code reviews. + 45:52 + no + + <p>While at RailsConf, we talk with Katrina Owen about finding metaphors for software development, the successes and mistakes of Exercism.io, and the benefits of providing code reviews.</p> +<ul> +<li><a href="https://twitter.com/kytrinyx">Katrina Owen</a></li> +<li><a href="http://confreaks.tv/presenters/katrina-owen">Katrina's conference talks</a></li> +<li><a href="https://twitter.com/kentbeck/status/250733358307500032">Make the change easy, then make the easy change</a></li> +<li><a href="https://www.youtube.com/watch?v=ggPE-JHzfAM">Skunk Works by Nickolas Means</a></li> +<li><a href="https://www.youtube.com/watch?v=WCr478LuSV4">Factory, Workshop, Stage by Sarah Mei</a></li> +<li><a href="https://robots.thoughtbot.com/the-product-design-sprint">The Product Design Sprint</a></li> +<li><a href="http://exercism.io">Exercism.io</a></li> +<li><a href="https://github.com/exercism">Exercism GitHub Organization</a></li> +</ul> + + + + While at RailsConf, we talk with Katrina Owen about finding metaphors for software development, the successes and mistakes of Exercism.io, and the benefits of providing code reviews.

+ +

Support The Bike Shed

]]> + + + While at RailsConf, we talk with Katrina Owen about finding metaphors for software development, the successes and mistakes of Exercism.io, and the benefits of providing code reviews.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1VM9Ni60 + + ]]> + + + + 64: Open Mic SF + https://bikeshed.thoughtbot.com/64 + 77d3c42d-e5cb-471d-951d-36830fb8ce88 + Wed, 18 May 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Open Mic is back by popular demand, this time in San Francisco. We hear from developers in thoughtbot's San Francisco office about their recent investment time projects. + 55:11 + no + + <p>Open Mic is back by popular demand, this time in San Francisco. We hear from developers in thoughtbot's San Francisco office about their recent investment time projects.</p> +<ul> +<li><a href="http://croniker.io/">Croniker</a></li> +<li><a href="http://meowni.ca/posts/emoji-emoji-emoji/">Monica Dinculescu on emoji</a></li> +<li><a href="https://twitter.com/gabebw/status/721813208697167872">Gabe learns about emoji on Twitter</a></li> +<li><a href="https://robots.thoughtbot.com/">thoughtbot blog</a></li> +<li><a href="https://en.wikipedia.org/wiki/Fear_of_missing_out">Fear of missing out on Wikipedia</a></li> +<li><a href="https://github.com/thoughtbot/fomobot">FOMObot</a></li> +<li><a href="http://www.gv.com/sprint/">Design Sprint</a></li> +<li><a href="http://troposweather.com/">Tropos</a></li> +<li><a href="https://twitter.com/gabebw">Gabe Berke-Williams on Twitter</a></li> +<li><a href="https://twitter.com/TonyD256">Tony DiPasquale on Twitter</a></li> +<li><a href="https://twitter.com/mandybess">Amanda Hill on Twitter</a></li> +</ul> + + + + Open Mic is back by popular demand, this time in San Francisco. We hear from developers in thoughtbot's San Francisco office about their recent investment time projects.

+ +

Support The Bike Shed

]]> + + + Open Mic is back by popular demand, this time in San Francisco. We hear from developers in thoughtbot's San Francisco office about their recent investment time projects.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+KFb3oTkH + + ]]> + + + + 63: Types Are Only Good If You Use Them + https://bikeshed.thoughtbot.com/63 + 04e19f2d-8feb-4151-8f41-42b93f19773a + Wed, 11 May 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss some recent issues with exciting language features like pattern matching, macros, and static types. + 38:16 + no + + <p>Derek and Sean discuss some recent issues with exciting language features like pattern matching, macros, and static types.</p> +<ul> +<li><a href="http://elixir-lang.org/getting-started/pattern-matching.html">Pattern Matching</a></li> +<li><a href="http://c2.com/cgi/wiki?PrimitiveObsession">Primitive Obsession</a></li> +<li><a href="http://blog.codinghorror.com/new-programming-jargon/">Stringly Typed</a></li> +<li><a href="https://www.youtube.com/c/SeanGriffin">Sean's open source programming streams</a></li> +<li><a href="https://www.twitch.tv/seantheprogrammer">Sean's Twitch channel</a></li> +</ul> + + + + Derek and Sean discuss some recent issues with exciting language features like pattern matching, macros, and static types.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss some recent issues with exciting language features like pattern matching, macros, and static types.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+KVBMOpMx + + ]]> + + + + 62: Shipping is the Fastest Way to Get Somewhere + https://bikeshed.thoughtbot.com/62 + f717595a-fb51-4205-a20c-d2e09d500fac + Wed, 04 May 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean celebrates Diesel reaching "faster than a SQL string" status before we chat about Rails 5 blockers and the clarity of focus and priorities that only shipping can bring. + 34:16 + no + + <p>Sean celebrates Diesel reaching &quot;faster than a SQL string&quot; status before we chat about Rails 5 blockers and the clarity of focus and priorities that only shipping can bring.</p> +<ul> +<li><a href="https://github.com/diesel-rs/diesel/pull/283">Make Diesel faster than a SQL String</a></li> +<li><a href="http://bikeshed.fm/49">How can an ORM be faster than a SQL string?</a></li> +<li><a href="https://github.com/rails/rails/pull/23807"><code>ActionSupport::Executor</code> and <code>ActionSupport::Reloader</code> APIs</a></li> +<li><a href="https://bugs.ruby-lang.org/issues/5653">&quot;I strongly discourage the use of autoload in any standard libraries”</a></li> +</ul> + + + + Sean celebrates Diesel reaching "faster than a SQL string" status before we chat about Rails 5 blockers and the clarity of focus and priorities that only shipping can bring.

+ +

Support The Bike Shed

]]> + + + Sean celebrates Diesel reaching "faster than a SQL string" status before we chat about Rails 5 blockers and the clarity of focus and priorities that only shipping can bring.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Cy2NTWm1 + + ]]> + + + + 61: I'm Not Telling You My Birthday + https://bikeshed.thoughtbot.com/61 + 537a116b-312b-4ce7-9d6f-de66c3da880e + Wed, 27 Apr 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + "Send me an email every year for my birthday" is an easy thing for a human to understand but it can be deceptively tricky to do with computers. Also tricky for (some) computers: `SELECT * FROM `. Wait... what? + 31:04 + no + + <p>&quot;Send me an email every year for my birthday&quot; is an easy thing for a human to understand but it can be deceptively tricky to do with computers. Also tricky for (some) computers: <code>SELECT * FROM</code>. Wait... what?</p> +<ul> +<li><a href="http://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT"><code>DATE_PART</code> or <code>EXTRACT</code></a></li> +<li><a href="http://www.postgresql.org/docs/9.5/static/trigger-definition.html">Triggers</a></li> +<li><a href="http://www.postgresql.org/docs/9.5/static/using-explain.html">Using <code>EXPLAIN</code></a></li> +<li><a href="http://www.postgresql.org/docs/9.5/static/sql-analyze.html">Using <code>ANALYZE</code></a></li> +<li><a href="http://www.postgresql.org/docs/9.5/static/sql-vacuum.html"><code>VACUUM</code></a></li> +<li>Derek's (mostly useless) <a href="https://github.com/derekprior/approximately/blob/master/lib/approximately/approximate_count.rb">Approximately</a> Gem</li> +</ul> + + + + "Send me an email every year for my birthday" is an easy thing for a human to understand but it can be deceptively tricky to do with computers. Also tricky for (some) computers: SELECT * FROM. Wait... what?

+ +

Support The Bike Shed

]]> + + + "Send me an email every year for my birthday" is an easy thing for a human to understand but it can be deceptively tricky to do with computers. Also tricky for (some) computers: SELECT * FROM. Wait... what?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+j4vfa7V2 + + ]]> + + + + 60: Remote Control (Katherine Fellows) + https://bikeshed.thoughtbot.com/60 + 0ef7ca7e-2c36-4fa9-b8dd-3655776dd5f3 + Wed, 20 Apr 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + KF (Katherine Fellows) joins the show to chat about successful BridgeFoundry events and creating environments where remote developers, junior and otherwise, can thrive. + 38:02 + no + + <p>KF (Katherine Fellows) joins the show to chat about successful BridgeFoundry events and creating environments where remote developers, junior and otherwise, can thrive.</p> +<ul> +<li><a href="https://twitter.com/kf">KF</a></li> +<li><a href="http://clojurewest.org">Clojure / West</a></li> +<li><a href="http://www.clojurebridge.org">ClojureBridge</a></li> +<li><a href="http://bridgefoundry.org">BridgeFoundry</a></li> +<li><a href="http://selfconference.org">Self Conference</a></li> +<li><a href="https://en.wikipedia.org/wiki/Conway%27s_law">Conway's Law</a></li> +<li><a href="https://en.wikipedia.org/wiki/Negativity_bias">Negativity Bias</a></li> +<li><a href="http://plibmttbhgaty.com">PLIBMTTBHGATY</a></li> +</ul> + + + + KF (Katherine Fellows) joins the show to chat about successful BridgeFoundry events and creating environments where remote developers, junior and otherwise, can thrive.

+ +

Support The Bike Shed

]]> + + + KF (Katherine Fellows) joins the show to chat about successful BridgeFoundry events and creating environments where remote developers, junior and otherwise, can thrive.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+tyTv0mWP + + ]]> + + + + 59: I Wish They Wouldn't Do That + https://bikeshed.thoughtbot.com/59 + d5be2773-af63-42a2-adee-5369b716a55a + Wed, 13 Apr 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss the left-pad saga, how other programming communities are reacting to it, and what you should learn from it as a library or application author. + 40:59 + no + + <p>Derek and Sean discuss the left-pad saga, how other programming communities are reacting to it, and what you should learn from it as a library or application author.</p> +<ul> +<li><a href="https://msdn.microsoft.com/en-us/commandline/wsl/about">Bash on Ubuntu on Windows</a></li> +<li><a href="https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c#.82bcheok9">I’ve Just Liberated My Modules</a> by Azer Koçulu</li> +<li><a href="https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d#.kpr3o8515">A discussion about the breaking of the internet</a> (Kik’s side of the story) by Mike Roberts</li> +<li><a href="http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm">Kik, left-pad, and npm</a> by Isaac Z. Schlueter from npm</li> +<li><a href="https://medium.freecodecamp.com/npm-package-hijacking-from-the-hijackers-perspective-af0c48ab9922#.vnwnjan9o">npm Package Hijacking: From the Hijackers Perspective</a> by Nathan Johnson</li> +<li><a href="https://github.com/rubygems/rubygems.org/issues/1226">Is <code>gem yank</code> a security concern?</a></li> +<li><a href="https://www.mikeperham.com/2016/02/09/kill-your-dependencies/">Kill Your Dependencies</a> by Mike Perham</li> +<li><a href="https://robots.thoughtbot.com/to-gem-or-not-to-gem">To gem, or not to gem</a> by Elle Meredith</li> +<li><a href="http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy">changes to npm’s unpublish policy</a> by Ashley Williams from npm</li> +<li><a href="http://blog.bigbinary.com/2015/12/28/application-record-in-rails-5.html">ApplicationRecord in Rails 5</a></li> +</ul> +<p>Thank you to <a href="https://hired.com/bikeshed">Hired</a> for sponsoring this episode!</p> + + + + Derek and Sean discuss the left-pad saga, how other programming communities are reacting to it, and what you should learn from it as a library or application author.

+ + + +

Thank you to Hired for sponsoring this episode!

Support The Bike Shed

]]> + + + Derek and Sean discuss the left-pad saga, how other programming communities are reacting to it, and what you should learn from it as a library or application author.

+ + + +

Thank you to Hired for sponsoring this episode!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MnYtpKj9 + + ]]> + + + + 58: Nobody Gets Fired For Buying IBM + https://bikeshed.thoughtbot.com/58 + 7b4e3794-9cac-441a-9452-614e45b0a821 + Wed, 06 Apr 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Should you rewrite or refactor? What should you consider as you weigh this decision and what exactly constitutes a rewrite anyway? + 45:36 + no + + <p>Should you rewrite or refactor? What should you consider as you weigh this decision and what exactly constitutes a rewrite anyway?</p> +<ul> +<li><a href="http://www.joelonsoftware.com/articles/fog0000000069.html">Things You Should Never Do, Part I</a> - Joel Spolsky on Software Rewrites</li> +<li><a href="https://www.quora.com/What-does-the-phrase-Nobody-ever-got-fired-for-choosing-IBM-mean#!n=12">What does the phrase &quot;Nobody ever got fired for choosing IBM&quot; mean?</a></li> +<li><a href="http://blog.codinghorror.com/when-understanding-means-rewriting/">When Understanding Means Rewriting</a> by Jeff Atwood</li> +<li><a href="https://signalvnoise.com/posts/3856-the-big-rewrite-revisited">The Big Rewrite, revisited</a> by DHH</li> +</ul> +<p>Thank you to <a href="https://hired.com/bikeshed">Hired</a> for sponsoring this episode!</p> + + + + Should you rewrite or refactor? What should you consider as you weigh this decision and what exactly constitutes a rewrite anyway?

+ + + +

Thank you to Hired for sponsoring this episode!

Support The Bike Shed

]]> + + + Should you rewrite or refactor? What should you consider as you weigh this decision and what exactly constitutes a rewrite anyway?

+ + + +

Thank you to Hired for sponsoring this episode!

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ln4RLr3- + + ]]> + + + + 57: Mutability Ruins the Whole Party (José Valim) + https://bikeshed.thoughtbot.com/57 + ab55c16b-f23b-403f-b693-a66f9314c801 + Wed, 30 Mar 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We chat with José Valim about bringing light to Elixir's dark corners, the design goals of Ecto, and the future of Elixir, Ecto, and Phoenix. + 55:50 + no + + <p>We chat with José Valim about bringing light to Elixir's dark corners, the design goals of Ecto, and the future of Elixir, Ecto, and Phoenix.</p> +<ul> +<li><a href="https://twitter.com/josevalim">José Valim</a> on Twitter</li> +<li><a href="https://groups.google.com/d/msg/elixir-lang-core/KvJQaUcUlOk/-bHTRb1ADQAJ">Introducing unifying calendar types to Elixir</a></li> +<li><a href="http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html">Falsehoods programmers believe about time and time zones</a> by Lau Taarnskov</li> +<li><a href="http://elixir-lang.org/docs/master/mix/Mix.Tasks.Deps.Tree.html"><code>mix deps.tree</code></a> in Elixir 1.3</li> +<li><a href="http://elixir-lang.org/docs/master/mix/Mix.Tasks.App.Tree.html"><code>mix app.tree</code></a> in Elixir 1.3</li> +<li><a href="https://hexdocs.pm/ecto/Ecto.Query.html#preload/3"><code>Ecto.Query.preload</code></a></li> +<li><a href="http://blog.plataformatec.com.br/2015/08/working-with-ecto-associations-and-embeds/">Working with Ecto Associations and Embeds</a> by José Valim.</li> +<li><a href="https://hexdocs.pm/ecto/Ecto.Changeset.html"><code>Ecto.Changeset</code></a></li> +<li><a href="http://blog.plataformatec.com.br/2016/02/ecto-2-0-0-beta-0-is-out/">Ecto 2 beta is out</a>, including concurrent database tests</li> +<li><a href="https://github.com/wojtekmach/github_ecto"><code>github_ecto</code></a>: An Ecto adapter for the GitHub API.</li> +<li><a href="https://dockyard.com/blog/2016/03/25/what-makes-phoenix-presence-special-sneak-peek">What Makes Phoenix Presence Special</a> by Chris McCord</li> +<li><a href="https://github.com/thoughtbot/ex_machina">ExMachina</a> - test factories for Elixir</li> +<li><a href="https://github.com/elixir-lang/gen_router">GenRouter</a></li> +<li><a href="http://www.elixirconf.eu">ElixirConf EU</a></li> +<li><a href="http://www.elixirconf.com">ElixirConf US</a></li> +</ul> + + + + We chat with José Valim about bringing light to Elixir's dark corners, the design goals of Ecto, and the future of Elixir, Ecto, and Phoenix.

+ +

Support The Bike Shed

]]> + + + We chat with José Valim about bringing light to Elixir's dark corners, the design goals of Ecto, and the future of Elixir, Ecto, and Phoenix.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+uirpGUbh + + ]]> + + + + 56: Most People Aren't Building Trello + https://bikeshed.thoughtbot.com/56 + 942c4135-09fc-473a-8537-8cac38d73bbc + Wed, 23 Mar 2016 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Is ActiveRecord reinventing Sequel? If it is, does it matter? Derek and Sean discuss that and whether maybe we could all stand to tone down the JavaScript. + 38:53 + no + + <p>Is ActiveRecord reinventing Sequel? If it is, does it matter? Derek and Sean discuss that and whether maybe we could all stand to tone down the JavaScript.</p> +<ul> +<li><a href="http://twin.github.io/activerecord-is-reinventing-sequel/">ActiveRecord is Reinventing Sequel</a></li> +<li><a href="http://ryanbigg.com/2015/11/open-source-work/">Ryan Bigg gives up his open source projects</a></li> +<li><a href="https://eev.ee/blog/2016/03/06/maybe-we-could-tone-down-the-javascript/">Maybe We Could Tone Down the JavaScript</a> by Evee</li> +<li><a href="https://github.com/zendesk/stronger_parameters">Stronger Parameters</a></li> +<li><a href="http://motherfuckingwebsite.com">Mother F*cking Website</a></li> +<li><a href="http://try.discourse.org">Discourse</a></li> +<li><a href="https://github.com/tildeio/ember-cli-fastboot">Ember CLI Fastboot</a></li> +<li><a href="http://webcomponents.org/articles/introduction-to-html-imports/">Introduction to HTML Imports</a></li> +<li><a href="http://www.ecma-international.org/memento/TC39.htm">TC39</a></li> +<li><a href="https://modernizr.com">Modernizr</a></li> +<li><a href="http://caniuse.com/#feat=input-datetime">Can I Use: Date and Time Input Types</a></li> +</ul> + + + + Is ActiveRecord reinventing Sequel? If it is, does it matter? Derek and Sean discuss that and whether maybe we could all stand to tone down the JavaScript.

+ +

Support The Bike Shed

]]> + + + Is ActiveRecord reinventing Sequel? If it is, does it matter? Derek and Sean discuss that and whether maybe we could all stand to tone down the JavaScript.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+WUOiLl3v + + ]]> + + + + 55: Hot Dog is Not a Dessert + https://bikeshed.thoughtbot.com/55 + 4a383a21-1a8d-4f1f-8de2-d6c3d9e00ba0 + Wed, 09 Mar 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean talk about their experience with the Rails 5 betas, how to test against them today, and things that you might want to look out for when updating your app. + 40:54 + no + + <p>Derek and Sean talk about their experience with the Rails 5 betas, how to test against them today, and things that you might want to look out for when updating your app.</p> +<ul> +<li><a href="https://en.wikipedia.org/wiki/Ides_of_March">Ides of March</a></li> +<li><a href="https://github.com/rails/rails/issues/23645">Presence validation of virtual attribute not firing appropriately</a></li> +<li><a href="https://github.com/rails/rails/issues/23643">ActionDispatch request helpers don't properly rewrite positional arguments to keyword arguments</a></li> +<li><a href="https://github.com/rails/strong_parameters#migration-path-to-rails-4">Strong Parameters migration path to Rails 4</a></li> +<li><a href="http://patshaughnessy.net/2014/6/16/a-rule-of-thumb-for-strong-parameters">A Rule of Thumb for Strong Parameters</a> by Pat Shaughnessy</li> +<li><a href="https://github.com/ruby-concurrency/concurrent-ruby">Concurrent Ruby</a></li> +<li><a href="https://github.com/thoghtbot/appraisal">Appraisal</a></li> +</ul> + + + + Derek and Sean talk about their experience with the Rails 5 betas, how to test against them today, and things that you might want to look out for when updating your app.

+ +

Support The Bike Shed

]]> + + + Derek and Sean talk about their experience with the Rails 5 betas, how to test against them today, and things that you might want to look out for when updating your app.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+giPgVGZ7 + + ]]> + + + + 54: Argument Error + https://bikeshed.thoughtbot.com/54 + 317f5f08-afdb-4e6d-8273-0cfba7b40911 + Wed, 02 Mar 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek shares some Elixir annoyances with Sean and they discus how a consulting role colors their perception of languages and frameworks, both for better and for worse. Sean provides an update on SQLite and Association support in Diesel. + 42:25 + no + + <p>Derek shares some Elixir annoyances with Sean and they discus how a consulting role colors their perception of languages and frameworks, both for better and for worse. Sean provides an update on SQLite and Association support in Diesel.</p> +<ul> +<li><a href="https://github.com/DevL/good_times">GoodTImes</a>, <a href="https://github.com/bitwalker/timex">Timex</a>, and <a href="https://hexdocs.pm/ecto/Ecto.DateTime.html">Ecto.DateTime</a></li> +<li><a href="https://gist.github.com/pixeltrix/e2298822dd89d854444b">When should you use <code>DateTime</code> and when should you use <code>Time</code></a> by Andrew White</li> +<li><a href="https://twitter.com/brandonhilkert/status/700723702841749505">Twitter conversation with Brandon Hikert</a></li> +<li><a href="http://www.postgresql.org/docs/current/static/sql-insert.html">Postgres <code>RETURNING</code></a></li> +<li><a href="https://hexdocs.pm/ecto/Ecto.Query.html#preload/3">Preloading in Ecto</a></li> +<li><a href="https://www.youtube.com/watch?v=oYk8CKH7OhE">User Focused Design in Elm</a> by Evan Czaplicki</li> +<li><a href="http://diesel.rs/guides/getting-started/">Getting Started with Diesel</a></li> +<li><a href="https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md">Rust API Evolution</a></li> +</ul> + + + + Derek shares some Elixir annoyances with Sean and they discus how a consulting role colors their perception of languages and frameworks, both for better and for worse. Sean provides an update on SQLite and Association support in Diesel.

+ +

Support The Bike Shed

]]> + + + Derek shares some Elixir annoyances with Sean and they discus how a consulting role colors their perception of languages and frameworks, both for better and for worse. Sean provides an update on SQLite and Association support in Diesel.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+RUUYgHUb + + ]]> + + + + 53: Cache Machine + https://bikeshed.thoughtbot.com/53 + 8e27de9f-2b5d-4394-8831-d06aca2850f3 + Wed, 24 Feb 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Laila and Derek go on a tour of the various caching mechanisms available to web applications in general, and Rails specifically. When is the right time to cache and at what level? + 43:28 + no + + <p>Laila and Derek go on a tour of the various caching mechanisms available to web applications in general, and Rails specifically. When is the right time to cache and at what level?</p> +<ul> +<li><a href="http://www.phoenixframework.org/v1.0.0/blog/the-road-to-2-million-websocket-connections">The Road to 2 Million Websocket Connections in Phoenix</a> by Gary Rennie</li> +<li><a href="http://www.healthline.com/health/toxic-synovitis">Toxic Synovitis</a></li> +<li><a href="http://thepugautomatic.com/2013/08/memoization-is-a-liability/">Memoization is a Liability</a> by Henrik Nyh</li> +<li><a href="https://github.com/thoughtbot/guides/pull/373">Use a leading underscore for memoization</a></li> +<li><a href="http://martinfowler.com/bliki/TwoHardThings.html">Two Hard Things in Computer Science</a></li> +<li><a href="http://guides.rubyonrails.org/caching_with_rails.html#sql-caching">Rails SQL Cache</a></li> +<li><a href="http://guides.rubyonrails.org/caching_with_rails.html#low-level-caching">Low-Level Caching (<code>Rails.cache.fetch</code>)</a></li> +<li><a href="http://guides.rubyonrails.org/association_basics.html#counter-cache">Association <code>counter_cache</code></a></li> +<li><a href="http://guides.rubyonrails.org/caching_with_rails.html#fragment-caching">Fragment Caching</a></li> +<li><a href="https://robots.thoughtbot.com/take-control-of-your-http-caching-in-rails">Introduction to Conditional HTTP Caching With Rails</a> by Damian Galarza</li> +<li><a href="https://robots.thoughtbot.com/a-guide-to-caching-your-rails-application-with-fastly">A Guide to Caching Your Rails Application with Fastly</a> by Jessie Young</li> +<li><a href="https://www.mnot.net/cache_docs/">Caching Tutorial for Web Authors and Webmasters</a> by Mark Nottingham</li> +<li><a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching">Web Fundamentals: HTTP Caching</a></li> +</ul> + + + + Laila and Derek go on a tour of the various caching mechanisms available to web applications in general, and Rails specifically. When is the right time to cache and at what level?

+ +

Support The Bike Shed

]]> + + + Laila and Derek go on a tour of the various caching mechanisms available to web applications in general, and Rails specifically. When is the right time to cache and at what level?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+h6gP95dB + + ]]> + + + + 52: You're an Elixir Developer Now + https://bikeshed.thoughtbot.com/52 + 3abc0d1d-9a33-441f-9336-291270d4d930 + Wed, 17 Feb 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Laila discuss Derek's excitement for Elixir and Phoenix. Is Elixir as fun to write as Ruby? Is Phoenix a better Rails? + 46:31 + no + + <p>Derek and Laila discuss Derek's excitement for Elixir and Phoenix. Is Elixir as fun to write as Ruby? Is Phoenix a better Rails?</p> +<ul> +<li><a href="http://elixir-lang.org">Elixir</a> and <a href="http://phoenixframework.org">Phoenix</a></li> +<li><a href="http://www.phoenixframework.org/docs/routing">Routes in Phoenix</a></li> +<li><a href="https://github.com/thoughtbot/dotfiles/pull/465">Using ctags with Elixir</a></li> +<li><a href="http://www.phoenixframework.org/docs/static-assets">Static Assets in Phoenix</a></li> +<li><a href="https://github.com/AgilionApps/ja_serializer">ja_serializers</a></li> +<li><a href="https://github.com/elixir-lang/ecto">ecto</a></li> +<li><a href="http://jsonapi.org/faq/#is-there-a-json-schema-describing-json-api">Is There a JSON Schema describing JSON API?</a></li> +<li><a href="https://github.com/elixir-lang/elixir/blob/v1.2.0/CHANGELOG.md">Elixir 1.2 <code>Map</code> and <code>MapSet</code> scale better</a></li> +<li><a href="https://github.com/thoughtbot/ex_machina">ExMachina</a> - factories for Elixir</li> +<li><a href="http://elixir-lang.org/getting-started/typespecs-and-behaviours.html">Elixir Typespecs and Behaviours</a></li> +</ul> + + + + Derek and Laila discuss Derek's excitement for Elixir and Phoenix. Is Elixir as fun to write as Ruby? Is Phoenix a better Rails?

+ +

Support The Bike Shed

]]> + + + Derek and Laila discuss Derek's excitement for Elixir and Phoenix. Is Elixir as fun to write as Ruby? Is Phoenix a better Rails?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+7r8lhkTK + + ]]> + + + + 51: Is Sim City Running? (Steve Klabnik) + https://bikeshed.thoughtbot.com/51 + 7a633b03-3acf-4888-9ca1-a6ff7832bf2f + Wed, 10 Feb 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We enjoy a wide-ranging discussion with Steve Klabnik on the importance of good documentation, the sometimes cloudy definition of a breaking change, the politics of open source contributions, and work/life balance or boundaries. + 43:56 + no + + <p>We enjoy a wide-ranging discussion with Steve Klabnik on the importance of good documentation, the sometimes cloudy definition of a breaking change, the politics of open source contributions, and work/life balance or boundaries.</p> +<ul> +<li>Steve Klabnik - <a href="https://twitter.com/steveklabnik">twitter</a>, <a href="http://www.steveklabnik.com">website</a>, <a href="http://words.steveklabnik.com">blog</a></li> +<li><a href="https://users.rust-lang.org/t/lets-talk-about-ecosystem-documentation/2791">Let’s Talk About Ecosystem Documentation</a></li> +<li><a href="http://www.joelonsoftware.com/articles/APIWar.html">SimCity Mode in Windows 3.1</a> from Joel Spolsky</li> +<li><a href="http://words.steveklabnik.com/rescuing-resque-again">Rescuing Resque… Again</a></li> +<li><a href="https://en.wikipedia.org/wiki/Netrunner">Netrunner</a></li> +<li><a href="http://intermezzos.github.io">IntermezzOS</a></li> +<li><a href="http://os.phil-opp.com">Writing an OS in Rust</a> by Philipp Oppermann</li> +<li><a href="https://github.com/graydon/bors">Bors</a> - an automated integrator for GitHub</li> +<li><a href="https://github.com/nrc/highfive">High Five</a> - a bot that encourages good contributions</li> +</ul> + + + + We enjoy a wide-ranging discussion with Steve Klabnik on the importance of good documentation, the sometimes cloudy definition of a breaking change, the politics of open source contributions, and work/life balance or boundaries.

+ +

Support The Bike Shed

]]> + + + We enjoy a wide-ranging discussion with Steve Klabnik on the importance of good documentation, the sometimes cloudy definition of a breaking change, the politics of open source contributions, and work/life balance or boundaries.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+pzJqaflk + + ]]> + + + + 50: Open Mic + https://bikeshed.thoughtbot.com/50 + 3cfda3a9-536a-4b46-8870-a1855e6d0d56 + Wed, 03 Feb 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + It's Open Mic day at The Bike Shed. We hear from other thoughtbot designers and developers about what they're excited to be spending their investment time on lately. + 28:30 + no + + <p>It's Open Mic day at The Bike Shed. We hear from other thoughtbot designers and developers about what they're excited to be spending their investment time on lately.</p> +<ul> +<li> +<p><a href="https://twitter.com/matthewmsumner">Matt Sumner</a></p> +</li> +<li> +<p><a href="http://hunchpig.audio">Hunchpig Podcast</a></p> +</li> +<li> +<p><a href="http://haskellbook.com">Haskell Programming</a></p> +</li> +<li> +<p><a href="https://en.wikipedia.org/wiki/Lambda_calculus">The Lambda Calculus</a></p> +</li> +<li> +<p><a href="http://learnyouahaskell.com">Learn You a Haskell for Great Good</a></p> +</li> +<li> +<p><a href="http://bikeshed.fm/48">Is Everyone Trying Their Best?</a> - The Bike Shed on software quality</p> +</li> +<li> +<p><a href="https://twitter.com/twnsndco">Cole Townsend</a></p> +</li> +<li> +<p><a href="http://julian.com/research/velocity/">Velocity JS</a></p> +</li> +<li> +<p><a href="https://dribbble.com/coletownsend">Cole on Dribbble</a></p> +</li> +<li> +<p><a href="https://en.wikipedia.org/wiki/List_of_NFL_franchise_post-season_droughts">The Buffalo Bills` Playoff Drought</a> - The longest current drought in sports</p> +</li> +<li> +<p><a href="https://twitter.com/joelquen">Joël Quenneville</a></p> +</li> +<li> +<p><a href="https://en.wikipedia.org/wiki/Joel_Quenneville">Alter Ego</a></p> +</li> +<li> +<p><a href="https://elm-lang.org">Elm</a></p> +</li> +<li> +<p><a href="http://debug.elm-lang.org">Elm's Time Traveling Debugger</a></p> +</li> +</ul> + + + + It's Open Mic day at The Bike Shed. We hear from other thoughtbot designers and developers about what they're excited to be spending their investment time on lately.

+ +

Support The Bike Shed

]]> + + + It's Open Mic day at The Bike Shed. We hear from other thoughtbot designers and developers about what they're excited to be spending their investment time on lately.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+JEYlJLHR + + ]]> + + + + 49: A More Practical Haskell + https://bikeshed.thoughtbot.com/49 + 392e8f24-4a8f-4f50-9c74-b85a278dac2e + Wed, 27 Jan 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + How can an ORM be faster than a SQL String? Laila and Sean discuss the latest happenings in Diesel and why it is that a systems language needs an ORM, anyway. + 34:40 + no + + <p>How can an ORM be faster than a SQL String? Laila and Sean discuss the latest happenings in Diesel and why it is that a systems language needs an ORM, anyway.</p> +<ul> +<li><a href="http://stackoverflow.com/questions/28123453/what-is-the-difference-between-traits-in-rust-and-typeclasses-in-haskell">What is the difference between traits in Rust and typeclasses in Haskell?</a></li> +<li>What is a <a href="https://en.wikipedia.org/wiki/Pure_function">pure function</a>?</li> +<li><a href="http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focus=3855">Why Rust Ditched Pure Functions</a></li> +<li>The <a href="http://www.martinfowler.com/eaaCatalog/activeRecord.html">ActiveRecord</a> and <a href="http://martinfowler.com/eaaCatalog/dataMapper.html">DataMapper</a> patterns (not libraries) as defined by Martin Fowler in Patterns of Enterprise Application Architecture</li> +<li><a href="http://blog.rust-lang.org/2015/05/11/traits.html">Zero-cost abstractions</a> in Rust by Aaron Turon.</li> +<li><a href="https://github.com/sgrif/diesel/issues/89">What should Diesel associations look like?</a></li> +<li><a href="http://ironframework.io">Iron</a> and <a href="http://nickel.rs">Nickel</a> web frameworks for Rust.</li> +<li><a href="https://github.com/rails/rails/pull/22950">Adapterizing storage for ActionCable</a> - Thanks Jon Moss!</li> +<li><a href="https://github.com/rails/rails/pull/22934">Moving ActionCable from Celluloid to ConcurrentRuby</a> - Thanks Mike Perham!</li> +</ul> + + + + How can an ORM be faster than a SQL String? Laila and Sean discuss the latest happenings in Diesel and why it is that a systems language needs an ORM, anyway.

+ +

Support The Bike Shed

]]> + + + How can an ORM be faster than a SQL String? Laila and Sean discuss the latest happenings in Diesel and why it is that a systems language needs an ORM, anyway.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+rIYT5kNN + + ]]> + + + + 48: Is Everyone Trying Their Best? + https://bikeshed.thoughtbot.com/48 + 878836be-a3dc-4aad-994e-949f8ba93acb + Thu, 21 Jan 2016 10:00:00 -0500 + thoughtbot + + full + thoughtbot + Software is broken. In this episode, Derek and Sean discuss why exactly it's broken, and what we can do to make it better. + 34:44 + no + + <p>Software is broken. In this episode, Derek and Sean discuss why exactly it's broken, and what we can do to make it better.</p> +<ul> +<li><a href="https://bertrandmeyer.com/2013/04/04/the-origin-of-software-engineering/">The origin of &quot;software engineering&quot;</a></li> +<li><a href="https://coq.inria.fr/">The Coq Proof Assistant</a></li> +<li><a href="http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/">NASA's 10 rules for developing safety critical code</a></li> +<li><a href="http://stackoverflow.com/questions/11889602/difference-between-strong-vs-static-typing-and-weak-vs-dynamic-typing">The differences between strong and static typing</a></li> +<li><a href="https://wiki.haskell.org/Why_Haskell_just_works">&quot;If it compiles it works&quot;</a></li> +<li><a href="https://github.com/sgrif/diesel/pull/27">Derek adds <code>IS NULL</code> to Diesel</a></li> +<li><a href="https://github.com/justincampbell/generative">&quot;Quickcheck in Ruby&quot;</a></li> +<li>Note: Shopify is fewer than 700 developers</li> +</ul> + + + + Software is broken. In this episode, Derek and Sean discuss why exactly it's broken, and what we can do to make it better.

+ +

Support The Bike Shed

]]> + + + Software is broken. In this episode, Derek and Sean discuss why exactly it's broken, and what we can do to make it better.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+c-07BH2I + + ]]> + + + + 47: Star Wars Oranges + https://bikeshed.thoughtbot.com/47 + eef8fb6c-a502-47f3-bbbd-6657d09134e4 + Wed, 13 Jan 2016 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Ruby 2.3 is out! What are we looking forward to trying and what do we think of `&.` and `try`? Stick around after the credits for spoiler-filled discussion of Star Wars: The Force Awakens + + 54:12 + no + + <p>Ruby 2.3 is out! What are we looking forward to trying and what do we think of <code>&amp;.</code> and <code>try</code>? Stick around after the credits for spoiler-filled discussion of <em>Star Wars: The Force Awakens</em></p> +<ul> +<li><a href="http://www.techinsider.io/star-wars-fruits-and-vegetables-are-not-the-droids-youre-looking-for-2015-12"><em>Star Wars</em> Fruit</a></li> +<li><a href="https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fintroductiontokerberosauthentication.htm">What is Kerberos?</a></li> +<li><a href="http://mitrev.net/ruby/2015/11/13/the-operator-in-ruby/">Safe navigation operator (AKA the lonely operator)</a> by Georgi Mitrev</li> +<li><a href="http://devblog.avdi.org/2015/10/30/activesupports-try-might-not-be-doing-what-you-think-its-doing/">ActiveSupport’s <code>#try</code> might not be doing what you think it’s doing</a> by Avdi Grimm</li> +<li><a href="http://devblog.avdi.org/2015/10/30/activesupports-try-might-not-be-doing-what-you-think-its-doing/#comment-44346">The history of <code>try</code> in Rails</a> a comment from Myron Marston</li> +<li><a href="https://andrewjgrimm.wordpress.com/2011/10/03/in-ruby-method-passes-you/">In Ruby, <code>&amp;method</code> Passes You!</a></li> +<li><a href="http://ruby-doc.org/core-2.3.0_preview1/Hash.html#method-i-dig"><code>Hash#dig</code></a></li> +<li><a href="http://olivierlacan.com/posts/hash-comparison-in-ruby-2-3/">Hash Comparison in Ruby 2.3</a> by Olivier Lacan</li> +<li><a href="https://github.com/yuki24/did_you_mean"><code>did_you_mean</code></a> by Yuki Nishijima.</li> +<li><a href="https://wyeworks.com/blog/2015/12/1/immutable-strings-in-ruby-2-dot-3">Immutable Strings in Ruby 2.3</a> by Alexis Mas</li> +<li><a href="https://infinum.co/the-capsized-eight/articles/multiline-strings-ruby-2-3-0-the-squiggly-heredoc">Multiline strings in Ruby 2.3 - the squiggly heredoc</a> by Damir Svrtan</li> +</ul> + + + + Ruby 2.3 is out! What are we looking forward to trying and what do we think of &. and try? Stick around after the credits for spoiler-filled discussion of Star Wars: The Force Awakens

+ +

Support The Bike Shed

]]> + + + Ruby 2.3 is out! What are we looking forward to trying and what do we think of &. and try? Stick around after the credits for spoiler-filled discussion of Star Wars: The Force Awakens

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+_QAZBh15 + + ]]> + + + + 46: Don't Breathe, Save the Planet + https://bikeshed.thoughtbot.com/46 + e3bd3117-c57a-4971-8290-360d037ac056 + Wed, 06 Jan 2016 13:00:00 -0500 + thoughtbot + + full + thoughtbot + We discuss the maintenance burden of ActionCable and its dependencies on Rails 5, follow-up on Scenic issues, and discuss implementing migrations anew in Diesel. + 34:14 + no + + <p>We discuss the maintenance burden of ActionCable and its dependencies on Rails 5, follow-up on Scenic issues, and discuss implementing migrations anew in Diesel.</p> +<ul> +<li><a href="http://imgur.com/iA3Lr5M">Don't Breathe</a></li> +<li><a href="http://bikeshed.fm/14">DHH on The Bike Shed</a></li> +<li><a href="https://www.youtube.com/watch?v=n0WUjGkDFS0">DHH's ActionCable Demo</a></li> +<li><a href="https://github.com/thoughtbot/scenic/pull/117">Fixing Scenic view dumping</a></li> +<li><a href="https://github.com/thoughtbot/scenic/pull/102">Updatable materialized views in Scenic</a></li> +<li><a href="https://github.com/sgrif/diesel/pull/64">A first pass at Diesel migrations</a></li> +<li><a href="https://bikeshed.fm/43">Teachable moments</a></li> +</ul> + + + + We discuss the maintenance burden of ActionCable and its dependencies on Rails 5, follow-up on Scenic issues, and discuss implementing migrations anew in Diesel.

+ +

Support The Bike Shed

]]> + + + We discuss the maintenance burden of ActionCable and its dependencies on Rails 5, follow-up on Scenic issues, and discuss implementing migrations anew in Diesel.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+4yQWVzkY + + ]]> + + + + 45: I Think I'd Prefer An Error to Nonsense + https://bikeshed.thoughtbot.com/45 + 26e29f4b-6beb-41e8-918c-20b42daa0b8b + Wed, 23 Dec 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek shipped Scenic 1.0, which spurs a conversation about semantic versioning and the value of the 1.0 milestone. We discuss what the bar for breaking changes in a library should be and look at some specific changes on tap for Scenic and whether they will or should carry a major version bump. + 47:57 + no + + <p>Derek shipped Scenic 1.0, which spurs a conversation about semantic versioning and the value of the 1.0 milestone. We discuss what the bar for breaking changes in a library should be and look at some specific changes on tap for Scenic and whether they will or should carry a major version bump.</p> +<ul> +<li><a href="https://github.com/thoughtbot/scenic">Scenic</a></li> +<li><a href="http://semver.org">Semantic Versioning</a> - See points 4 and 5</li> +<li><a href="https://robots.thoughtbot.com/implementing-multi-table-full-text-search-with-postgres">Implementing Multi-Table Full Text Search with Postgres in Rails</a></li> +<li><a href="https://github.com/thoughtbot/scenic/issues/96">Issue handling view dependencies in Scenic migrations</a> and a <a href="https://github.com/thoughtbot/scenic/pull/100">potential partial solution</a></li> +<li><a href="https://github.com/thoughtbot/scenic/issues/99">The trouble with <code>SELECT *</code> in Postgres views</a></li> +<li><a href="https://github.com/thoughtbot/appraisal">Appraisal</a></li> +<li><a href="https://github.com/thoughtbot/scenic/blob/master/spec/smoke">Scenic smoke tests</a></li> +</ul> + + + + Derek shipped Scenic 1.0, which spurs a conversation about semantic versioning and the value of the 1.0 milestone. We discuss what the bar for breaking changes in a library should be and look at some specific changes on tap for Scenic and whether they will or should carry a major version bump.

+ +

Support The Bike Shed

]]> + + + Derek shipped Scenic 1.0, which spurs a conversation about semantic versioning and the value of the 1.0 milestone. We discuss what the bar for breaking changes in a library should be and look at some specific changes on tap for Scenic and whether they will or should carry a major version bump.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+ejkptL63 + + ]]> + + + + 44: It Won't Crash... It Might Crash + https://bikeshed.thoughtbot.com/44 + 9ad635c6-255e-4db7-b8f6-fc02f056b12d + Thu, 17 Dec 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Sean has shipped early versions of Diesel, an ORM for Rust! We discuss its semantic versioning, the ergonomics of use versus the complexities of implementation, early issues with the API and the road to Diesel 1.0. + 47:29 + no + + <p>Sean has shipped early versions of Diesel, an ORM for Rust! We discuss its semantic versioning, the ergonomics of use versus the complexities of implementation, early issues with the API and the road to Diesel 1.0.</p> +<ul> +<li><a href="https://github.com/sgrif/diesel">Diesel</a></li> +<li><a href="http://semver.org">Semantic Versioning</a></li> +<li><a href="http://www.schneems.com/2015/11/29/what-is-semver.html">SemVer for Library Maintainers</a> by Richard Schneeman</li> +<li><a href="https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md">Rust RFC 1122 - Language SemVer</a></li> +<li><a href="https://lobste.rs">Lobsters</a></li> +<li><a href="https://github.com/sgrif/diesel/issues/26">API hole in diesel updates</a></li> +<li><a href="https://github.com/sgrif/diesel/commit/a3f1055bc8c3bc6b4d47b24fa6dbbccf59c16540">Implementing <code>IS NULL</code> and <code>IS NOT NULL</code> for Diesel</a></li> +<li><a href="https://github.com/sgrif/diesel/issues/10">Diesel issue for migrations</a></li> +<li><a href="https://github.com/rust-lang/crates.io/pull/228">Crates.io PR for using Database behavior</a></li> +</ul> + + + + Sean has shipped early versions of Diesel, an ORM for Rust! We discuss its semantic versioning, the ergonomics of use versus the complexities of implementation, early issues with the API and the road to Diesel 1.0.

+ +

Support The Bike Shed

]]> + + + Sean has shipped early versions of Diesel, an ORM for Rust! We discuss its semantic versioning, the ergonomics of use versus the complexities of implementation, early issues with the API and the road to Diesel 1.0.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+e_wUeOA2 + + ]]> + + + + 43: That's DOCTOR Internet Technologist + https://bikeshed.thoughtbot.com/43 + 54fd3dd7-4cc3-40bc-bb1d-1fa509b043e0 + Wed, 09 Dec 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We talk about lessons learned from teachable moments both in the moment and decades later. + 50:43 + no + + <p>We talk about lessons learned from teachable moments both in the moment and decades later.</p> +<ul> +<li><a href="https://en.wikipedia.org/wiki/Teachable_moment">Teachable moment</a></li> +<li><a href="https://www.braintreepayments.com/blog/safe-operations-for-high-volume-postgresql/">Safe Operations for High Volume PostgreSQL</a> by Paul Gross</li> +<li><a href="https://robots.thoughtbot.com/how-to-create-postgres-indexes-concurrently-in">How to Create Postgres Indexes Concurrently in ActiveRecord Migrations</a> by Dan Croak</li> +<li><a href="http://www.postgresql.org/docs/9.4/static/sql-copy.html">PostgreSQL <code>COPY FROM</code></a></li> +<li><a href="https://github.com/thoughtbot/suspenders/pull/601">Guarding against truncating the production database in Suspenders</a></li> +<li><a href="https://robots.thoughtbot.com/referential-integrity-with-foreign-keys">Have Some (Referential) Integrity with Foreign Keys</a></li> +<li><a href="https://twitter.com/sarahmei/status/635822455337058304">&quot;Inheritance is not for sharing code&quot;</a> tweet from Sarah Mei</li> +<li><a href="https://www.youtube.com/watch?v=OMPfEXIlTVE">&quot;Inheritance is for specialization, not for sharing code&quot;</a> from Sandi Metz' &quot;Nothing is Something&quot; talk at RailsConf</li> +<li><a href="https://robots.thoughtbot.com/lets-not">Let's Not</a> by Joe Ferris</li> +<li><a href="https://robots.thoughtbot.com/mystery-guest">Mystery Guest</a> by Dan Croak</li> +<li><a href="http://vertassets.blob.core.windows.net/image/27d976d3/27d976d3-9a08-11d4-8c69-009027de0829/eqamppop.jpg">A modem pool</a></li> +<li><a href="https://github.com/sgrif/diesel">Diesel née YAQB</a></li> +</ul> + + + + We talk about lessons learned from teachable moments both in the moment and decades later.

+ +

Support The Bike Shed

]]> + + + We talk about lessons learned from teachable moments both in the moment and decades later.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+WyFk-pw7 + + ]]> + + + + 42: That's Incredibly Ambitious (Grayson Wright) + https://bikeshed.thoughtbot.com/42 + bffbb32a-f468-474b-a913-1724027c0ba5 + Wed, 02 Dec 2015 11:30:00 -0500 + thoughtbot + + full + thoughtbot + We speak to Grayson Wright about building Administrate, an open source Rails framework for administrative interfaces. What makes Administrate different than existing solutions and what are the challenges in maintaining high-level dependencies. + 37:32 + no + + <p>We speak to Grayson Wright about building Administrate, an open source Rails framework for administrative interfaces. What makes Administrate different than existing solutions and what are the challenges in maintaining high-level dependencies.</p> +<ul> +<li><a href="https://robots.thoughtbot.com/announcing-administrate">Announcing Administrate</a></li> +<li><a href="https://github.com/thoughtbot/administrate">Administrate on GitHub</a></li> +<li><a href="https://administrate-prototype.herokuapp.com/admin">Administrate Demo</a></li> +<li><a href="http://bourbon.io">Bourbon</a> and <a href="http://neat.bourbon.io">Neat</a></li> +<li><a href="https://css-tricks.com/responsive-data-tables/">Responsive tables</a></li> +<li><a href="https://github.com/spree/spree">Spree</a></li> +<li><a href="http://keepachangelog.com">Keep A Changelog</a></li> +<li><a href="https://github.com/thoughtbot/clearance/blob/master/NEWS.md">Clearance's <code>NEWS</code> file</a></li> +<li><a href="http://codeforamerica.org">Code For America</a></li> +<li><a href="https://twitter.com/grayson_wright">Grayson on Twitter</a></li> +</ul> + + + + We speak to Grayson Wright about building Administrate, an open source Rails framework for administrative interfaces. What makes Administrate different than existing solutions and what are the challenges in maintaining high-level dependencies.

+ +

Support The Bike Shed

]]> + + + We speak to Grayson Wright about building Administrate, an open source Rails framework for administrative interfaces. What makes Administrate different than existing solutions and what are the challenges in maintaining high-level dependencies.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+PTu3CBvG + + ]]> + + + + 41: Ugh, I Have to Write Web Apps in This Thing + https://bikeshed.thoughtbot.com/41 + f5515cd2-bf8d-4545-92ac-1f7e203d6b70 + Wed, 25 Nov 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean talk about Derek's exploration into Elixir and Phoenix, when and how performance matters, and ways to keep your Rails app fast from day 1. + 35:25 + no + + <p>Derek and Sean talk about Derek's exploration into Elixir and Phoenix, when and how performance matters, and ways to keep your Rails app fast from day 1.</p> +<ul> +<li><a href="http://elixir-lang.org/">The Elixir Programming Language</a></li> +<li><a href="http://www.phoenixframework.org/">Phoenix Web Framework</a></li> +<li><a href="https://robots.thoughtbot.com/announcing-ex-machina">Announcing Ex Machina</a></li> +<li><a href="https://github.com/thoughtbot/ex_machina">ex_machina on Github</a></li> +<li><a href="https://github.com/rails/rails/pull/19324">touches are now batched in Rails 5</a></li> +<li><a href="http://bitfission.com/redirect_blame/">Basecamp 3 Source Code</a></li> +<li><a href="https://github.com/flyerhzm/bullet">Bullet</a> and <a href="https://github.com/MiniProfiler/rack-mini-profiler">Rack MiniProfiler</a></li> +<li><a href="http://bikeshed.fm/17">Railing About Performance with Sam Saffron</a></li> +<li><a href="https://robots.thoughtbot.com/a-client-project-two-years-later">A Client Project, Two Years Later</a></li> +<li><a href="http://i.imgur.com/WBz29mK.png">Derek at a Coworking Space</a></li> +</ul> + + + + Derek and Sean talk about Derek's exploration into Elixir and Phoenix, when and how performance matters, and ways to keep your Rails app fast from day 1.

+ +

Support The Bike Shed

]]> + + + Derek and Sean talk about Derek's exploration into Elixir and Phoenix, when and how performance matters, and ways to keep your Rails app fast from day 1.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Nrb8qtYv + + ]]> + + + + 40: ActiveRecord Deprecated Persistence + https://bikeshed.thoughtbot.com/40 + 373627d8-922e-4735-835f-1534dce77a40 + Wed, 18 Nov 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + The ActiveRecord update API is a mess of methods that confuse even ActiveRecord’s maintainer. What are the problems and is there any hope for a solution? + 34:22 + no + + <p>The ActiveRecord update API is a mess of methods that confuse even ActiveRecord’s maintainer. What are the problems and is there any hope for a solution?</p> +<ul> +<li><a href="https://www.youtube.com/watch?v=AjtpplE39_g">40</a></li> +<li><a href="https://greg.molnar.io/tech/2015/10/28/prevent-rails-information-leaking.html">Prevent Information leaking In Rails</a></li> +<li><a href="http://www.davidverhasselt.com/set-attributes-in-activerecord/">Different ways to update in Rails</a></li> +<li><a href="https://robots.thoughtbot.com/the-perils-of-uniqueness-validations">The Perils of Uniqueness Validations</a></li> +<li><a href="https://github.com/rails/rails/pull/21135"><code>disable with</code> is default in Rails 5</a></li> +<li><a href="http://bikeshed.fm/11">The Bike Shed #11: Forming Opinions</a></li> +</ul> + + + + The ActiveRecord update API is a mess of methods that confuse even ActiveRecord’s maintainer. What are the problems and is there any hope for a solution?

+ +

Support The Bike Shed

]]> + + + The ActiveRecord update API is a mess of methods that confuse even ActiveRecord’s maintainer. What are the problems and is there any hope for a solution?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+PrQvE547 + + ]]> + + + + 39: Okay with Instability (Yehuda Katz) + https://bikeshed.thoughtbot.com/39 + ed9aad07-e9cf-4564-9eee-1bea588d0cf2 + Wed, 11 Nov 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + We talk with Yehuda Katz about how much risk is right for you and your app, the sharp tools of high level abstractions, and how our statistical intuition leads us astray on web performance. + 1:07:10 + no + + <p>We talk with Yehuda Katz about how much risk is right for you and your app, the sharp tools of high level abstractions, and how our statistical intuition leads us astray on web performance.</p> +<ul> +<li><a href="https://signalvnoise.com/posts/3963-remove-the-stress-pick-a-deadline">Remove The Stress, Pick a Deadline</a></li> +<li><a href="https://www.youtube.com/watch?v=9LfmrkyP81M">Writing Software by DHH</a></li> +<li><a href="http://skylight.io">Skylight</a></li> +<li><a href="http://blog.skylight.io/the-log-normal-reality/">The Log Normal Reality</a> - On how our statistical intuition leads us astray.</li> +<li><a href="https://twitter.com/wycats">Yehuda on Twitter</a></li> +</ul> + + + + We talk with Yehuda Katz about how much risk is right for you and your app, the sharp tools of high level abstractions, and how our statistical intuition leads us astray on web performance.

+ +

Support The Bike Shed

]]> + + + We talk with Yehuda Katz about how much risk is right for you and your app, the sharp tools of high level abstractions, and how our statistical intuition leads us astray on web performance.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+eJSq6WhK + + ]]> + + + + 38: Ugh, Forms + https://bikeshed.thoughtbot.com/38 + 995cd679-4dcd-4c96-b8ef-de2123de48a3 + Tue, 03 Nov 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Laila and Derek discuss how they have handled forms with complex validation requirements and how to make these forms have a smooth user experience. + 40:33 + no + + <p>Laila and Derek discuss how they have handled forms with complex validation requirements and how to make these forms have a smooth user experience.</p> +<ul> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5/Constraint_validation">HTML Form Validations</a></li> +<li><a href="http://caniuse.com/#search=validation">HTML5 Validation Browser Support</a></li> +<li><a href="http://parsleyjs.org">Parsely JS</a></li> +<li><a href="https://github.com/DavyJonesLocker/client_side_validations">Client Side Validations</a></li> +<li><a href="http://simple-form.plataformatec.com.br">SimpleForm</a></li> +<li><a href="http://conversionxl.com/form-accessibility/">7 Ways Form Accessibility Can Boost Conversions</a></li> +</ul> + + + + Laila and Derek discuss how they have handled forms with complex validation requirements and how to make these forms have a smooth user experience.

+ +

Support The Bike Shed

]]> + + + Laila and Derek discuss how they have handled forms with complex validation requirements and how to make these forms have a smooth user experience.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3wBZUUKw + + ]]> + + + + 37: The Web is Faster Without Garbage + https://bikeshed.thoughtbot.com/37 + 00e1c032-2e2b-4c4f-836d-484d49124efd + Thu, 29 Oct 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Begun, the ad block wars have. Derek debugs an issue that arises from iOS ad blocking and wonders if analytics will move back to the server side. Sean fills us in on how dirty checking works in ActiveRecord and how he's making it faster and better in Rails 5. + 44:15 + no + + <p>Begun, the ad block wars have. Derek debugs an issue that arises from iOS ad blocking and wonders if analytics will move back to the server side. Sean fills us in on how dirty checking works in ActiveRecord and how he's making it faster and better in Rails 5.</p> +<ul> +<li><a href="https://pbs.twimg.com/media/CQ9YJJ4U8AAscMz.jpg">Sean and his wife in a hot air balloon</a></li> +<li><a href="http://www.loopinsight.com/2015/09/16/a-list-of-content-blockers-for-ios-9/">iOS 9 Content Blockers</a></li> +<li><a href="http://www.nytimes.com/interactive/2015/10/01/business/cost-of-mobile-ads.html">The Cost of Mobile Ads on 50 News Websites</a></li> +<li><a href="https://en.wikipedia.org/wiki/Do_Not_Track">Do No Track</a> HTTP Header</li> +<li><a href="http://api.rubyonrails.org/classes/ActiveModel/Dirty.html">ActiveModel Dirty API</a></li> +<li><a href="https://github.com/rails/rails/blob/master/activerecord/lib/active_record/attribute_methods/dirty.rb">ActiveRecord Dirty</a></li> +</ul> + + + + Begun, the ad block wars have. Derek debugs an issue that arises from iOS ad blocking and wonders if analytics will move back to the server side. Sean fills us in on how dirty checking works in ActiveRecord and how he's making it faster and better in Rails 5.

+ +

Support The Bike Shed

]]> + + + Begun, the ad block wars have. Derek debugs an issue that arises from iOS ad blocking and wonders if analytics will move back to the server side. Sean fills us in on how dirty checking works in ActiveRecord and how he's making it faster and better in Rails 5.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+XIAG-jAz + + ]]> + + + + 36: Python Unchained + https://bikeshed.thoughtbot.com/36 + f8d31edf-2dc0-4199-9d5d-bfce39f83c3f + Thu, 15 Oct 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Laila talk about learning Python and Django and discuss how thoughtbot adopts new languages, frameworks, and libraries. What factors influence adoption? How do we share what works and doesn't work? + 50:06 + no + + <p>Derek and Laila talk about learning Python and Django and discuss how thoughtbot adopts new languages, frameworks, and libraries. What factors influence adoption? How do we share what works and doesn't work?</p> +<ul> +<li><a href="https://docs.djangoproject.com/en/1.8/intro/tutorial01/">Writing your first Django app</a></li> +<li><a href="https://docs.python.org/2/tutorial/index.html">The Python Tutorial</a></li> +<li><a href="https://docs.djangoproject.com/en/1.8/topics/http/urls/">Django URLs</a></li> +<li><a href="https://docs.djangoproject.com/en/1.8/topics/db/queries/#retrieving-specific-objects-with-filters">Django filters</a></li> +<li><a href="http://learnyouahaskell.com">Learn You A Haskell For Great Good</a></li> +<li><a href="http://www.seas.upenn.edu/%7Ecis194/">CIS 194: Introduction to Haskell</a></li> +<li><a href="http://twoscoopspress.org/products/two-scoops-of-django-1-8">Two Scoops of Django</a></li> +<li><a href="https://gumroad.com/l/ruby-science">Ruby Science</a></li> +<li><a href="https://github.com/thoughtbot/suspenders">Suspenders</a></li> +<li><a href="https://playbook.thoughtbot.com/#research">thoughtbot's research board</a></li> +<li><a href="https://robots.thoughtbot.com/validating-json-schemas-with-an-rspec-matcher">Validating Schemas with an RSpec Matcher</a></li> +<li><a href="https://github.com/thoughtbot/json_matchers"><code>json_matchers</code></a></li> +<li><a href="https://github.com/thoughtbot/scenic"><code>scenic</code></a></li> +</ul> + + + + Derek and Laila talk about learning Python and Django and discuss how thoughtbot adopts new languages, frameworks, and libraries. What factors influence adoption? How do we share what works and doesn't work?

+ +

Support The Bike Shed

]]> + + + Derek and Laila talk about learning Python and Django and discuss how thoughtbot adopts new languages, frameworks, and libraries. What factors influence adoption? How do we share what works and doesn't work?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+lFrXNIdh + + ]]> + + + + 35: GitHub Ate My Résumé + https://bikeshed.thoughtbot.com/35 + eb16a137-f5b9-4465-abbb-8bf7fa6ec8c7 + Wed, 07 Oct 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Derek explain why you should always use a personal email address in your Git configuration before they dive into Ruby exception handling, and potential MRI proc optimizations. + 40:12 + no + + <p>Sean and Derek explain why you should always use a personal email address in your Git configuration before they dive into Ruby exception handling, and potential MRI proc optimizations.</p> +<ul> +<li>Set your <a href="https://help.github.com/articles/setting-your-email-in-git/">Git email address</a> to an address you own &quot;forever&quot;.</li> +<li>Git <a href="https://git-scm.com/docs/git-shortlog#_mapping_authors"><code>.mailmap</code></a></li> +<li><a href="https://thoughtbot.com/jobs">Jobs at thoughtbot</a></li> +<li><a href="https://github.com/rest-client/rest-client">rest-client</a></li> +<li>Ruby's <a href="http://ruby-doc.org/core-2.2.3/Kernel.html#method-i-raise"><code>Kernel#raise</code></a> documentation</li> +<li>Ruby's <a href="http://ruby-doc.org/core-2.2.3/Exception.html#method-i-cause"><code>Exception#cause</code></a> documentation</li> +<li><a href="https://github.com/rails/spring/blob/master/lib/spring/application.rb#L258-L275">Spring overrides <code>raise</code></a>, but feels uneasy about it.</li> +<li><a href="http://exceptionalruby.com">Exceptional Ruby</a> by Avdi Grim.</li> +<li><a href="http://ruby-doc.org/core-2.2.3/Proc.html#method-i-3D-3D-3D"><code>Proc#===</code></a> documentation.</li> +<li><a href="http://www.upcase.com/coupons/podcast-oct">Upcase</a>: 50% Off Your First Month For Bike Shed Listeners!</li> +</ul> + + + + Sean and Derek explain why you should always use a personal email address in your Git configuration before they dive into Ruby exception handling, and potential MRI proc optimizations.

+ +

Support The Bike Shed

]]> + + + Sean and Derek explain why you should always use a personal email address in your Git configuration before they dive into Ruby exception handling, and potential MRI proc optimizations.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+JoH-jXs1 + + ]]> + + + + 34: README.md + https://bikeshed.thoughtbot.com/34 + 3f20e045-13c3-4a99-8d23-53070234f524 + Tue, 29 Sep 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek is joined by Laila Winner to discuss Neo4j, the importance of fantastic documentation, and the different types of documentation a project requires. + 38:47 + no + + <p>Derek is joined by Laila Winner to discuss Neo4j, the importance of fantastic documentation, and the different types of documentation a project requires.</p> +<ul> +<li><a href="http://plibmttbhgaty.com/">PLIBMTTBHGATY</a></li> +<li><a href="http://neo4j.com/">Neo4j</a></li> +<li><a href="http://stevelosh.com/blog/2013/09/teach-dont-tell/">Teach, Don't Tell</a></li> +<li><a href="https://users.rust-lang.org/t/lets-talk-about-ecosystem-documentation/2791">Let's talk about ecosystem documentation</a> - Grading documentation of the top 40 crates in Rust.</li> +<li><a href="https://github.com/thoughtbot/factory_girl/blob/master/GETTING_STARTED.md">FactoryGirl Getting Started</a></li> +<li><a href="https://github.com/thoughtbot/clearance/blob/master/lib/clearance/sign_in_guard.rb#L4-L39">Clearance <code>SignInGuard</code> documentation</a></li> +<li><a href="http://guides.rubyonrails.org/security.html">Rails Security Guide</a></li> +<li><a href="https://thoughtbot.com/jobs">Jobs at thoughtbot</a></li> +<li><a href="https://twitter.com/malandr1na">Laila on Twitter</a></li> +</ul> + + + + Derek is joined by Laila Winner to discuss Neo4j, the importance of fantastic documentation, and the different types of documentation a project requires.

+ +

Support The Bike Shed

]]> + + + Derek is joined by Laila Winner to discuss Neo4j, the importance of fantastic documentation, and the different types of documentation a project requires.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+PF_ckgwQ + + ]]> + + + + 33: Just Put it in a Module, Man + https://bikeshed.thoughtbot.com/33 + 9e592860-5916-4af6-85a4-6f32bdbd37bf + Tue, 22 Sep 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Derek take some listener questions, and dig into DRY. + 40:23 + no + + <p>Sean and Derek take some listener questions, and dig into DRY.</p> +<ul> +<li><a href="http://c2.com/cgi/wiki?DontRepeatYourself">DRY</a></li> +<li><a href="http://c2.com/cgi/wiki?SingleResponsibilityPrinciple">Single Responsibility Principle (SRP)</a></li> +<li><a href="https://github.com/josevalim/inherited_resources">Inherited Resources</a></li> +<li><a href="https://www.youtube.com/watch?v=8bZh5LMaSmE">Sandi Mets - All The Little Things</a></li> +<li>Sign up for <a href="http://www.sandimetz.com/">Sandi Metz's &quot;Chainline&quot; newsletter</a></li> +<li><a href="https://en.wikipedia.org/wiki/Sunk_costs">Sunk cost fallacy</a></li> +<li><a href="https://twitter.com/sarahmei/status/635822455337058304">&quot;Inheritence is not for sharing code&quot;</a></li> +<li><a href="https://github.com/rails/rails/pull/21337">Eric Hayes' Rails PR</a></li> +<li><a href="http://www.basketball-reference.com/players/b/birdla01.html">Larry Bird</a></li> +</ul> +<p>Thanks for sending us your questions and feedback. Got more? You can email us at <a href="mailto:hosts@bikeshed.fm">hosts@bikeshed.fm</a> or <a href="https://twitter.com/_bikeshed">tweet us</a>.</p> + + + + Sean and Derek take some listener questions, and dig into DRY.

+ + + +

Thanks for sending us your questions and feedback. Got more? You can email us at hosts@bikeshed.fm or tweet us.

Support The Bike Shed

]]> + + + Sean and Derek take some listener questions, and dig into DRY.

+ + + +

Thanks for sending us your questions and feedback. Got more? You can email us at hosts@bikeshed.fm or tweet us.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+mGM4JNW5 + + ]]> + + + + 32: Bug For Bug Compatibility + https://bikeshed.thoughtbot.com/32 + 914ca847-10a0-4ba0-a3f3-94eac8bbeac0 + Tue, 15 Sep 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss Microsoft's interest in open source, improving the Rails development story on Windows, and Sean's progress implementing an ORM in Rust. + 50:36 + no + + <p>Derek and Sean discuss Microsoft's interest in open source, improving the Rails development story on Windows, and Sean's progress implementing an ORM in Rust.</p> +<ul> +<li><a href="http://daverupert.com/2015/08/developing-on-windows/">Developing on Windows</a></li> +<li><a href="https://en.wikipedia.org/wiki/Windows_PowerShell">PowerShell</a></li> +<li><a href="https://en.wikipedia.org/wiki/Cygwin">Cygwin</a></li> +<li><a href="http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork">Does Windows <code>fork</code>?</a></li> +<li><a href="https://dev.modern.ie/">Modern.ie</a></li> +<li><a href="https://github.com/xdissent/ievms">ievms</a></li> +<li><a href="http://blogs.msdn.com/b/askie/archive/2009/03/23/understanding-compatibility-modes-in-internet-explorer-8.aspx">Internet Explorer compatibility mode</a></li> +<li><a href="http://postgis.net/">PostGIS</a></li> +<li><a href="https://robots.thoughtbot.com/using-arel-to-compose-sql-queries">Using Arel to Compose SQL Queries</a></li> +<li><a href="https://github.com/activerecord-hackery/ransack">Ransack</a></li> +<li>Rust <a href="https://github.com/rust-lang/rfcs/pull/1210/">specialization</a></li> +<li>Rust grapples with <a href="https://internals.rust-lang.org/t/orphan-rules/1322">orphan instances</a></li> +<li><a href="https://github.com/sgrif/yaqb">Sean's in-progress Rust ORM</a></li> +</ul> + + + + Derek and Sean discuss Microsoft's interest in open source, improving the Rails development story on Windows, and Sean's progress implementing an ORM in Rust.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss Microsoft's interest in open source, improving the Rails development story on Windows, and Sean's progress implementing an ORM in Rust.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+trwg-pMS + + ]]> + + + + 31: Oxidizing an ORM + https://bikeshed.thoughtbot.com/31 + fc041ad6-6bbf-4287-9c54-a1407b16ed83 + Tue, 08 Sep 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Are provably correct queries of interest to you? Sean gives a rundown of what a Rusty ORM might be like to build. + 48:24 + no + + <p>Are provably correct queries of interest to you? Sean gives a rundown of what a Rusty ORM might be like to build.</p> +<ul> +<li><a href="http://doc.rust-lang.org/std/string/struct.String.html">String</a>, <a href="http://doc.rust-lang.org/std/str/index.html">str</a>, and <a href="http://doc.rust-lang.org/std/ffi/struct.CStr.html">CStr</a>.</li> +<li>What's a <a href="http://www.miroslavkopecky.com/2014/08/design-patterns-with-scala-fundamental.html">marker trait</a>?</li> +<li>Rust <a href="http://doc.rust-lang.org/book/macros.html">macros</a>.</li> +<li>Rust <a href="https://doc.rust-lang.org/book/compiler-plugins.html">compiler plugins</a>.</li> +<li><a href="http://www.merriam-webster.com/dictionary/hygienic">hy·gien·ic ˌhī-ˈjē-nik, -ˈje- also -jē-ˈe-nik</a></li> +<li>Sean's <a href="https://gist.github.com/sgrif/5f44e911eb9be515bdfb">ORM query thoughts</a></li> +</ul> + + + + Are provably correct queries of interest to you? Sean gives a rundown of what a Rusty ORM might be like to build.

+ +

Support The Bike Shed

]]> + + + Are provably correct queries of interest to you? Sean gives a rundown of what a Rusty ORM might be like to build.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+pUr0jIiG + + ]]> + + + + 30: Just Go to Slash Wibble + https://bikeshed.thoughtbot.com/30 + 48931772-9af3-4952-81b6-a408758b0f83 + Tue, 01 Sep 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean discuss hypothetical changes to Rails routing before turning their attention toward hunting memory bloat and the proposal that strings be frozen by default in Ruby 3. + 46:26 + no + + <p>Derek and Sean discuss hypothetical changes to Rails routing before turning their attention toward hunting memory bloat and the proposal that strings be frozen by default in Ruby 3.</p> +<ul> +<li>The Bike Shed listeners <a href="https://github.com/rails/rails/pull/21135">make <code>disable_with</code> default</a> on <code>submit_tag</code></li> +<li>Derek <a href="https://gist.github.com/derekprior/3015a311182a34e0aa3a">tries to explain the trouble with unrestricted routes</a> to a client.</li> +<li>The trouble with <a href="http://stackoverflow.com/questions/3736759/ruby-on-rails-singular-resource-and-form-for">singular resources and <code>form_for</code></a></li> +<li>Use <a href="https://github.com/schneems/derailed_benchmarks"><code>derailed benchmarks</code></a> to find memory leaks and bloat.</li> +<li><a href="https://blog.engineyard.com/2009/thats-not-a-memory-leak-its-bloat">ActiveRecord memory bloat</a></li> +<li>Matz: <a href="https://twitter.com/yukihiro_matz/status/634386185507311616">String literals frozen by default in Ruby 3</a></li> +<li>The <a href="https://bugs.ruby-lang.org/issues/11473">issue for discussion</a> because Twitter is terrible for these things.</li> +<li><a href="https://speakerdeck.com/sferik/symbols">The trouble with symbols</a></li> +<li><a href="https://robots.thoughtbot.com/ruby-2-keyword-arguments#required-keyword-arguments">Required keyword argument syntax</a> is ugly.</li> +</ul> + + + + Derek and Sean discuss hypothetical changes to Rails routing before turning their attention toward hunting memory bloat and the proposal that strings be frozen by default in Ruby 3.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss hypothetical changes to Rails routing before turning their attention toward hunting memory bloat and the proposal that strings be frozen by default in Ruby 3.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+lbqIvIHD + + ]]> + + + + 29: Django Unchained (Mike Burns) + https://bikeshed.thoughtbot.com/29 + 753d2e1e-abad-4493-ad46-7829be12c61e + Tue, 25 Aug 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean is joined by Mike Burns to discuss what Ruby and Rails can learn from Python and Django. + 23:26 + no + + <p>Sean is joined by Mike Burns to discuss what Ruby and Rails can learn from Python and Django.</p> +<ul> +<li><a href="https://twitter.com/mikeburns">Mike Burns</a></li> +<li>Python's <a href="https://docs.python.org/2/library/functions.html#map"><code>map</code></a></li> +<li><a href="https://www.djangoproject.com/">Django</a></li> +<li>George's <a href="http://confreaks.tv/videos/railsconf2013-sleeping-with-the-enemy">Sleeping with the Enemy</a> talk from RailsConf 2013</li> +<li><a href="http://lwn.net/Articles/590299/">A False Midnight</a></li> +<li><a href="https://docs.python.org/2/library/doctest.html">Python doctest</a></li> +<li><a href="https://wiki.python.org/moin/PythonDecoratorLibrary">Python Decorator Library</a></li> +</ul> + + + + Sean is joined by Mike Burns to discuss what Ruby and Rails can learn from Python and Django.

+ +

Support The Bike Shed

]]> + + + Sean is joined by Mike Burns to discuss what Ruby and Rails can learn from Python and Django.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+98qZsFuP + + ]]> + + + + 28: Minisode 0.1.1 + https://bikeshed.thoughtbot.com/28 + 55e3d20f-dda1-4b35-b4fb-cb2da10bae91 + Tue, 18 Aug 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Did you know Rails has no integration test suite? What could go wrong? + 9:17 + no + + <p>Did you know Rails has no integration test suite? What could go wrong?</p> +<ul> +<li><a href="https://github.com/rails/rails/pull/14384"><code>ActionController::Parameters</code> no longer inherits from <code>Hash</code></a></li> +</ul> + + + + Did you know Rails has no integration test suite? What could go wrong?

+ +

Support The Bike Shed

]]> + + + Did you know Rails has no integration test suite? What could go wrong?

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+X5XeF6Ei + + ]]> + + + + 27: I've Got 29.97 Problems (and codecs are some) + https://bikeshed.thoughtbot.com/27 + 926f910c-9ead-40d7-a222-d31df877e898 + Tue, 11 Aug 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Derek circle back on HTTP before diving into unsafe rust, and finally the merits of a small standard library. + 43:56 + no + + <p>Sean and Derek circle back on HTTP before diving into unsafe rust, and finally the merits of a small standard library.</p> +<ul> +<li><a href="https://www.mnot.net/blog/2015/06/15/http2_implementation_status">HTTP2 implementation status</a></li> +<li><a href="http://ffmpeg.org/">libffmpeg</a></li> +<li><a href="https://doc.rust-lang.org/nightly/nomicon/">unsafe rust</a></li> +<li><a href="https://internals.rust-lang.org/t/uninitialized-memory/1652">uninitialized memory in Rust</a></li> +<li><a href="https://users.rust-lang.org/t/stdx-the-missing-batteries-of-rus">stdx - the missing batteries of Rust</a></li> +<li><a href="https://github.com/npm/npm/releases/tag/v3.0.0">NPM 3.0.0</a></li> +<li><a href="https://docs.npmjs.com/cli/shrinkwrap">NPM Shrinkwrap</a></li> +</ul> + + + + Sean and Derek circle back on HTTP before diving into unsafe rust, and finally the merits of a small standard library.

+ +

Support The Bike Shed

]]> + + + Sean and Derek circle back on HTTP before diving into unsafe rust, and finally the merits of a small standard library.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3Tw9dkxW + + ]]> + + + + 26: My Cache is in the Cloud + https://bikeshed.thoughtbot.com/26 + 14d66ef5-302f-4d1e-85ac-31ff93345f10 + Tue, 04 Aug 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + This week, Sean and Derek discuss performance and inheriting code. In a stroke of complete madness, Derek decides that turbolinks isn't that bad. + 33:59 + no + + <p>This week, Sean and Derek discuss performance and inheriting code. In a stroke of complete madness, Derek decides that turbolinks isn't that bad.</p> +<ul> +<li><a href="https://github.com/spree/spree">Spree</a></li> +<li><a href="http://www.browserscope.org/?category=network&amp;v=top">Browserscope network profile details</a></li> +<li><a href="https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead">RFC2616 is Dead</a></li> +<li><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4">Original HTTP/1.1 connection limit</a></li> +<li><a href="http://tools.ietf.org/html/rfc7230#section-6.4">Updated HTTP/1.1 connection specification removes the specific limit</a></li> +<li><a href="https://github.com/panicsteve/cloud-to-butt">cloud-to-butt</a></li> +<li><a href="https://github.com/rails/turbolinks">turbolinks</a></li> +<li><a href="https://github.com/kossnocorp/jquery.turbolinks">jquery.turbolinks</a></li> +<li><a href="http://caniuse.com/#feat=script-async">async script loading</a></li> +<li>Disabling form buttons with <a href="https://robots.thoughtbot.com/a-tour-of-rails-jquery-ujs#disabling-links-and-buttons"><code>disable_with</code></a></li> +<li><a href="http://www.paulirish.com/2009/fighting-the-font-face-fout/">FOUT: flash of unstyled text</a></li> +</ul> + + + + This week, Sean and Derek discuss performance and inheriting code. In a stroke of complete madness, Derek decides that turbolinks isn't that bad.

+ +

Support The Bike Shed

]]> + + + This week, Sean and Derek discuss performance and inheriting code. In a stroke of complete madness, Derek decides that turbolinks isn't that bad.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+zZ0L-R9o + + ]]> + + + + 25: Throwing the Schema Out With the SOAPy Bathwater (Gordon Fontenot) + https://bikeshed.thoughtbot.com/25 + 1ba0a4b6-02af-4eec-be7a-c6848638d68f + Tue, 28 Jul 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek is joined by Gordon Fontenot for a discussion of the JSON API specification, problems consuming it from Swift, and the future of functional programming in Swift. + +This episode of The Bike Shed is sponsored by Code School. Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School. + 51:11 + no + + <p>Derek is joined by Gordon Fontenot for a discussion of the JSON API specification, problems consuming it from Swift, and the future of functional programming in Swift.</p> +<p>This episode of The Bike Shed is sponsored by:</p> +<ul> +<li><a href="http://www.codeschool.com/thebikeshed/?utm_source=test&amp;utm_medium=podcast&amp;utm_content=homepage&amp;utm_campaign=the%20bike%20shed">Code School</a>: Entertaining online learning for existing and aspiring developers. Leave a review on our <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119?mt=2">iTunes page</a> to be entered to win a free month of Code School.</li> +</ul> +<p>Links / Show Notes</p> +<ul> +<li><a href="http://jsonapi.org/">JSON API</a></li> +<li><a href="https://github.com/thoughtbot/argo">Argo</a>: Functional JSON parsing in Swift</li> +<li><a href="https://robots.thoughtbot.com/functional-swift-for-dealing-with-optional-values">Swift Optionals</a></li> +<li><a href="https://github.com/wvteijlingen/spine">Spine</a>: A Swift JSON API client</li> +<li><a href="https://github.com/thoughtbot/curry">Curry</a>: Swift framework for function currying.</li> +<li><a href="http://stateless.co/hal_specification.html">HAL</a>: Hypertext Application Language</li> +<li><a href="https://en.wikipedia.org/wiki/SOAP">SOAP</a></li> +<li><a href="http://json-schema.org/">JSON Schema</a></li> +<li><a href="https://github.com/thoughtbot/runes">Runes</a></li> +<li><a href="http://buildphase.fm/">Build Phase</a>- For more of Gordon's insight into baseball and iOS development</li> +<li><a href="https://twitter.com/GFontenot">Gordon on Twitter</a></li> +<li><a href="http://orteil.dashnet.org/cookieclicker/">Cookie Clicker</a></li> +<li><a href="https://swarmsim.github.io/#/">Swarm Sim</a></li> +</ul> + + +

Derek is joined by Gordon Fontenot for a discussion of the JSON API specification, problems consuming it from Swift, and the future of functional programming in Swift.

+ +

This episode of The Bike Shed is sponsored by:

+ +
    +
  • Code School: Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School.
    • +
+ +

Links / Show Notes

+ +

Support The Bike Shed

]]> + + +

Derek is joined by Gordon Fontenot for a discussion of the JSON API specification, problems consuming it from Swift, and the future of functional programming in Swift.

+ +

This episode of The Bike Shed is sponsored by:

+ +
    +
  • Code School: Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School.
    • +
+ +

Links / Show Notes

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+GPP4BQhP + + ]]> + + + + 24: You Look Good in a Lab Coat (Richard Schneeman) + https://bikeshed.thoughtbot.com/24 + aefb2e68-d349-42dc-a9e3-68edd2341bf9 + Tue, 21 Jul 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Richard Schneeman joins The Bike Shed to discuss ruby memory use, horizontal scaling, and tackling open source issues big and small. + +This episode of The Bike Shed is sponsored by Code School. Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School. + 41:04 + no + + <p>Richard Schneeman joins The Bike Shed to discuss ruby memory use, horizontal scaling, and tackling open source issues big and small.</p> +<p>This episode of The Bike Shed is sponsored by:</p> +<ul> +<li><a href="http://www.codeschool.com/thebikeshed/?utm_source=test&amp;utm_medium=podcast&amp;utm_content=homepage&amp;utm_campaign=the%20bike%20shed">Code School</a>: Entertaining online learning for existing and aspiring developers. Leave a review on our <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119?mt=2">iTunes page</a> to be entered to win a free month of Code School.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://confreaks.tv/videos/railsconf2015-speed-science">Speed Science</a> - Richard's Railsconf 2015 talk</li> +<li><a href="https://github.com/mikel/mail/issues/812"><code>mail</code> gem memory use</a></li> +<li><a href="https://github.com/mime-types/ruby-mime-types/issues/94"><code>mime-types</code> memory use</a></li> +<li><a href="https://github.com/rails/rails/pull/15840">Deprecate <code>*_path</code> methods in mailers</a></li> +<li><a href="https://xkcd.com/1172/">XKCD: Evey change breaks someone's workflow</a></li> +<li><a href="https://www.quora.com/The-Hitchhikers-Guide-to-the-Galaxy-creative-franchise/Why-does-six-times-nine-equal-forty-two">Why does 6 times 9 equal 42?</a></li> +<li><a href="http://words.steveklabnik.com/the-language-strangeness-budget">The Language Strangeness Budget</a></li> +<li><a href="http://codetriage.com">Code Triage</a></li> +<li><a href="http://docsdoctor.org">Docs Doctor</a></li> +<li><a href="https://rubytogether.org/">Ruby Together</a></li> +<li><a href="http://keeprubyweird.com/">Keep Ruby Weird</a></li> +<li><a href="https://twitter.com/schneems">Richard on Twitter</a></li> +</ul> + + + + Richard Schneeman joins The Bike Shed to discuss ruby memory use, horizontal scaling, and tackling open source issues big and small.

+ +

This episode of The Bike Shed is sponsored by:

+ +
    +
  • Code School: Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School.
    • +
+ +

Links & Show Notes

+ +

Support The Bike Shed

]]> + + + Richard Schneeman joins The Bike Shed to discuss ruby memory use, horizontal scaling, and tackling open source issues big and small.

+ +

This episode of The Bike Shed is sponsored by:

+ +
    +
  • Code School: Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School.
    • +
+ +

Links & Show Notes

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+MDNcxW7P + + ]]> + + + + 23: Why Did They Call it Rust?! + https://bikeshed.thoughtbot.com/23 + 5a2a7d64-7eb1-4954-b028-7b58a3533d1d + Tue, 14 Jul 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean gives Derek a tour of Rust, a new systems language from Mozilla. + +This episode of The Bike Shed is sponsored by Code School. Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School. + 43:09 + no + + <p>Sean gives Derek a tour of Rust, a new systems language from Mozilla.</p> +<p>This episode of The Bike Shed is sponsored by:</p> +<ul> +<li> +<p><a href="http://www.codeschool.com/thebikeshed/?utm_source=test&amp;utm_medium=podcast&amp;utm_content=homepage&amp;utm_campaign=the%20bike%20shed">Code School</a>: Entertaining online learning for existing and aspiring developers. Leave a review on our <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119?mt=2">iTunes page</a> to be entered to win a free month of Code School.</p> +</li> +<li> +<p><a href="http://rust-lang.org">Rust</a></p> +</li> +<li> +<p><a href="http://doc.rust-lang.org/book/">The Rust Programming Language</a></p> +</li> +<li> +<p><a href="https://air.mozilla.org/guaranteeing-memory-safety-in-rust/">Guaranteeing Memory Safety in Rust</a></p> +</li> +<li> +<p><a href="http://blog.rust-lang.org/2015/05/11/traits.html">Rust traits</a></p> +</li> +<li> +<p><a href="http://doc.crates.io/">Cargo</a></p> +</li> +<li> +<p><a href="http://doc.rust-lang.org/std/macro.include_str!.html"><code>include_str!</code></a></p> +</li> +<li> +<p><a href="http://doc.rust-lang.org/stable/book/match.html">Pattern matching in Rust</a></p> +</li> +</ul> + + + + Sean gives Derek a tour of Rust, a new systems language from Mozilla.

+ +

This episode of The Bike Shed is sponsored by:

+ +

Support The Bike Shed

]]> + + + Sean gives Derek a tour of Rust, a new systems language from Mozilla.

+ +

This episode of The Bike Shed is sponsored by:

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+X5xDjqU- + + ]]> + + + + 22: No Capes! (Eileen Uchitelle) + https://bikeshed.thoughtbot.com/22 + 9790b228-252b-43cd-b719-047d535b7ba9 + Tue, 07 Jul 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Eileen Uchitelle joins the show to discuss performance improvements to ActiveRecord, speeding up integration tests, and contributing to or running open source projects. + +This episode of The Bike Shed is sponsored by Code School. Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School. + 38:12 + no + + <p>Eileen Uchitelle joins the show to discuss performance improvements to ActiveRecord, speeding up integration tests, and contributing to or running open source projects.</p> +<p>This episode of The Bike Shed is sponsored by:</p> +<ul> +<li><a href="http://www.codeschool.com/thebikeshed/?utm_source=test&amp;utm_medium=podcast&amp;utm_content=homepage&amp;utm_campaign=the%20bike%20shed">Code School</a>: Entertaining online learning for existing and aspiring developers. Leave a review on our <a href="https://itunes.apple.com/us/podcast/the-bike-shed/id935763119">iTunes page</a> to be entered to win a free month of Code School.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://i1190.photobucket.com/albums/z457/selene0789/NoCapes_zps82c1bcc0.jpg">No Capes!</a></li> +<li><a href="https://www.youtube.com/watch?v=lOpVcqiAIiI">CRUD! The Consequences of Not Understanding How ActiveRecord</a> - Eileen's Midwest Ruby Talk</li> +<li><a href="https://github.com/rails/rails/commit/e247f3257927e008ed89944249ac38a8838f719f">fix delete_all to remove records directly</a></li> +<li><a href="http://confreaks.tv/videos/goruco2015-how-to-performance">How To Performance</a> - Eileen's talk from GORUCO</li> +<li><a href="http://www.confreaks.tv/videos/railsconf2015-breaking-down-the-barrier-demystifying-contributing-to-rails">Breaking Down the Barrier: Demystifying Contributing to Rails</a> - Eileen's lab from RailsConf</li> +<li><a href="https://twitter.com/eileencodes">Eileen on Twitter</a></li> +</ul> + + + + Eileen Uchitelle joins the show to discuss performance improvements to ActiveRecord, speeding up integration tests, and contributing to or running open source projects.

+ +

This episode of The Bike Shed is sponsored by:

+ +
    +
  • Code School: Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School.
    • +
+ +

Links & Show Notes

+ +

Support The Bike Shed

]]> + + + Eileen Uchitelle joins the show to discuss performance improvements to ActiveRecord, speeding up integration tests, and contributing to or running open source projects.

+ +

This episode of The Bike Shed is sponsored by:

+ +
    +
  • Code School: Entertaining online learning for existing and aspiring developers. Leave a review on our iTunes page to be entered to win a free month of Code School.
    • +
+ +

Links & Show Notes

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+VLYw9dtL + + ]]> + + + + 21: The "Best" Canada (Godfrey Chan) + https://bikeshed.thoughtbot.com/21 + 14ff89fa-e996-47d1-832b-fe93aa8db851 + Tue, 30 Jun 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Rails Core Team member Godfrey Chan joins the show to demystify rails bug hunting and contributing. + 23:38 + no + + <p>Rails Core Team member Godfrey Chan joins the show to demystify rails bug hunting and contributing.</p> +<ul> +<li>Godfrey's RailsConf talk: <a href="http://confreaks.tv/videos/railsconf2015-prying-open-the-black-box">Prying Open The Black Box</a></li> +<li><a href="https://youtu.be/cp7_u0kcQRo">The Waltons Say Goodnight</a></li> +<li><a href="https://github.com/vanruby/canada">Canada gem</a></li> +<li><a href="http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#create-an-executable-test-case">Rails Bug Templates</a></li> +<li><a href="http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html">Rails Contributing Guide</a></li> +<li><a href="http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/">Travis Container Infrastructure</a></li> +<li><a href="http://vanruby.org/">Vancouver Ruby Group</a></li> +<li><a href="https://twitter.com/chancancode">Godfrey on Twitter</a></li> +</ul> + + + + Rails Core Team member Godfrey Chan joins the show to demystify rails bug hunting and contributing.

+ +

Support The Bike Shed

]]> + + + Rails Core Team member Godfrey Chan joins the show to demystify rails bug hunting and contributing.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+NR4PUxOT + + ]]> + + + + 20: Intentionally Excruciatingly Painful + https://bikeshed.thoughtbot.com/20 + 772c3efd-c4ad-4eee-a861-d1e29e3b4fb2 + Tue, 23 Jun 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We're joined by Josh Clayton to discuss our differing strategies on testing view behavior, strategies for dealing with brittle feature specs, and what types of tests each of us favor. + 41:02 + no + + <p>We're joined by Josh Clayton to discuss our differing strategies on testing view behavior, strategies for dealing with brittle feature specs, and what types of tests each of us favor.</p> +<ul> +<li><a href="https://relishapp.com/rspec/rspec-mocks/v/3-3/docs/verifying-doubles/partial-doubles">Verifying partial doubles</a></li> +<li><a href="https://github.com/hashrocket/decent_exposure">Decent exposure</a></li> +<li><a href="https://github.com/MIT-IR/abet/commit/7443270b3f52364d7899cefd95f42735f50e79f1">Defining helpers directly on the view in view specs</a></li> +<li><a href="https://robots.thoughtbot.com/don-t-stub-the-system-under-test">Don't stub the system under test</a></li> +<li><a href="https://robots.thoughtbot.com/faster-tests-sign-in-through-the-back-door">Clearance Back Door</a></li> +<li>Automatic form filling driven by i18n and Factory Girl with <a href="https://github.com/thoughtbot/formulaic">Formulaic</a></li> +<li><a href="https://robots.thoughtbot.com/mystery-guest">Mystery guests</a></li> +<li>Using data attributes to <a href="https://robots.thoughtbot.com/decoupling-data-from-presentation">decouple data from presentation</a></li> +<li><a href="http://martinfowler.com/bliki/TestPyramid.html">Testing pyramid</a></li> +<li><a href="https://github.com/thoughtbot/shoulda-matchers">Shoulda Matchers</a></li> +<li><a href="https://github.com/trptcolin/consistency_fail">Consistency Fail</a></li> +<li><a href="https://twitter.com/joshuaclayton">Josh Clayton on Twitter</a></li> +</ul> + + + + We're joined by Josh Clayton to discuss our differing strategies on testing view behavior, strategies for dealing with brittle feature specs, and what types of tests each of us favor.

+ +

Support The Bike Shed

]]> + + + We're joined by Josh Clayton to discuss our differing strategies on testing view behavior, strategies for dealing with brittle feature specs, and what types of tests each of us favor.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+fy9TB4kK + + ]]> + + + + 19: The Oncoming Storm (Sam Phippen) + https://bikeshed.thoughtbot.com/19 + 8cca25f0-f850-4b7a-a10b-c9b54f12199e + Tue, 16 Jun 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean are joined by Sam Phippen from the RSpec core team to discuss RSpec mocks, testing strategies, and minitest. + 29:11 + no + + <p>Derek and Sean are joined by Sam Phippen from the RSpec core team to discuss RSpec mocks, testing strategies, and minitest.</p> +<ul> +<li>RSpec 3 adds <a href="http://rspec.info/blog/2014/01/new-in-rspec-3-composable-matchers/">composable matchers</a></li> +<li><a href="https://relishapp.com/rspec/rspec-mocks/docs/basics/spies">Spies</a> were added to RSpec in 2.14</li> +<li>Using <a href="https://relishapp.com/rspec/rspec-mocks/docs/working-with-legacy-code/any-instance"><code>any_instance</code></a> to test legacy code</li> +<li><a href="https://github.com/seattlerb/minitest">minitest</a></li> +<li>RSpec's <a href="https://www.relishapp.com/rspec/rspec-mocks/docs/mutating-constants"><code>stub_const</code></a> method.</li> +<li><a href="https://robots.thoughtbot.com/don-t-stub-the-system-under-test">Don't Stub the System Under Test</a></li> +<li><code>assigns</code> and <code>assert_template</code> are <a href="https://github.com/rails/rails/issues/18950">deprecated in Rails 5</a></li> +<li>Sam's RailsConf talk: <a href="https://www.youtube.com/watch?v=SOi_1reKn8M">Understanding Rails Test Types in RSpec</a></li> +<li><a href="http://funandplausible.solutions/">Fun &amp; Plausible Solutions</a></li> +<li><a href="https://twitter.com/samphippen">Sam on Twitter</a></li> +</ul> + + + + Derek and Sean are joined by Sam Phippen from the RSpec core team to discuss RSpec mocks, testing strategies, and minitest.

+ +

Support The Bike Shed

]]> + + + Derek and Sean are joined by Sam Phippen from the RSpec core team to discuss RSpec mocks, testing strategies, and minitest.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+-Wfiubvv + + ]]> + + + + 18: This Podcast is Rigged (But Not Animated) + https://bikeshed.thoughtbot.com/18 + aba0ae0d-49a7-4073-aef5-14bc60642eda + Tue, 09 Jun 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Derek discuss rails asset dependencies before diving into an overview of animation techniques and C extensions. + 39:14 + no + + <p>Sean and Derek discuss rails asset dependencies before diving into an overview of animation techniques and C extensions.</p> +<ul> +<li><a href="https://rails-assets.org/">Rails Assets</a></li> +<li><a href="http://www.prioritized.net/blog/gemify-assets-for-rails/">Gemify Assets for Rails</a></li> +<li><a href="https://bibwild.wordpress.com/2014/10/02/non-digested-asset-names-in-rails-4-your-options/">Non-digested asset names in Rails 4</a></li> +<li><a href="http://en.wikipedia.org/wiki/Skeletal_animation">Animation Rigging</a></li> +<li><a href="https://www.unrealengine.com/what-is-unreal-engine-4">Unreal Engine</a></li> +<li><a href="https://unity3d.com/">Unity</a></li> +<li><a href="http://www.reddit.com/r/starcitizen/comments/1rl7bq/could_somebody_please_explain_physical_based/">Physically Based Rendering</a></li> +<li><a href="http://en.wikipedia.org/wiki/Fast_inverse_square_root">The Carmack Constant or Fast Inverse Square Root</a></li> +<li><a href="http://blog.skylight.io/bending-the-curve-writing-safe-fast-native-gems-with-rust/">Bending the Curve: Writing Safe &amp; Fast Native Gems With Rust</a></li> +</ul> + + + + Sean and Derek discuss rails asset dependencies before diving into an overview of animation techniques and C extensions.

+ +

Support The Bike Shed

]]> + + + Sean and Derek discuss rails asset dependencies before diving into an overview of animation techniques and C extensions.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+EoDRd4aV + + ]]> + + + + 17: Railing About Performance (Sam Saffron) + https://bikeshed.thoughtbot.com/17 + b2b10ebb-804f-4ea9-8eae-3ee0d288e2a0 + Tue, 02 Jun 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + We chat with Sam Saffron about performance, benchmarking, and database migration strategies. + 46:46 + no + + <p>We chat with Sam Saffron about performance, benchmarking, and database migration strategies.</p> +<ul> +<li><a href="http://samsaffron.com/">Sam Saffron</a></li> +<li><a href="http://www.discourse.org/">Discourse</a></li> +<li><a href="https://github.com/MiniProfiler/rack-mini-profiler">rack-mini-profiler</a></li> +<li><a href="https://github.com/tmm1/stackprof">stackprof</a></li> +<li><a href="https://rubybench.org/">RubyBench</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/Scoping/Default/ClassMethods.html#method-i-default_scope"><code>default_scope</code></a></li> +<li><a href="http://en.wikipedia.org/wiki/View_%28SQL%29">SQL Views</a></li> +<li><a href="https://github.com/thoughtbot/scenic">Scenic</a> - Database view support in Rails</li> +<li><a href="http://grafana.org/">Grafana</a></li> +<li><a href="https://www.docker.com/">Docker</a></li> +<li><a href="http://guides.rubyonrails.org/v3.2.8/migrations.html#types-of-schema-dumps">Types of Rails schema dumps</a></li> +<li><a href="https://github.com/SamSaffron/message_bus">Message Bus</a></li> +<li><a href="http://logster.info">Logster</a></li> +</ul> +<p>Feedback? You can <a href="https://twitter.com/_bikeshed">tweet us</a>, <a href="mailto:hosts@bikeshed.fm">email us</a>, or leave a <a href="http://bikeshed.fm/17">comment on our website</a>.</p> + + + + We chat with Sam Saffron about performance, benchmarking, and database migration strategies.

+ + + +

Feedback? You can tweet us, email us, or leave a comment on our website.

Support The Bike Shed

]]> + + + We chat with Sam Saffron about performance, benchmarking, and database migration strategies.

+ + + +

Feedback? You can tweet us, email us, or leave a comment on our website.

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+x_n_X-hp + + ]]> + + + + 16: Wizards Are Hard to Kill + https://bikeshed.thoughtbot.com/16 + 204afc53-03c3-447f-95ec-4d27998f8144 + Wed, 27 May 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Grab Bag! Derek and Sean talk about math, augmented reality, RailsConf wrap up, Minimum Viable Products, Accessibility... + 36:40 + no + + <p>Grab Bag! Derek and Sean talk about math, augmented reality, RailsConf wrap up, Minimum Viable Products, Accessibility...</p> +<ul> +<li><a href="http://en.wikipedia.org/wiki/Homography_%28computer_vision%29">Homography</a></li> +<li><a href="http://en.wikipedia.org/wiki/Isomorphism">Isomorphism</a></li> +<li><a href="http://en.wikipedia.org/wiki/Homomorphism">Homomorphism</a></li> +<li><a href="https://www.youtube.com/watch?v=KokSHK_MV-U">Sean's Augmented Reality PoC</a></li> +<li><a href="https://kerbalspaceprogram.com/en/">Kerbal Space Program</a></li> +<li>Derek's talk on <a href="http://confreaks.tv/videos/railsconf2015-implementing-a-strong-code-review-culture">Cultivating Code Review Culture</a></li> +<li>Sean's talk on <a href="http://confreaks.tv/videos/railsconf2015-designing-a-great-ruby-api-how-we-re-simplifying-rails-5">Designing a Great Ruby API</a></li> +<li><a href="http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html#method-i-attribute">Attributes API documentation</a></li> +<li><a href="http://en.wikipedia.org/wiki/Minimum_viable_product">Minimum Viable Product</a></li> +<li><a href="https://twitter.com/chandracarney">Chandra Carney</a>'s talk on <a href="http://confreaks.tv/videos/railsconf2015-how-to-program-with-accessibility-in-mind">Programming with Accessibility in Mind</a></li> +<li><a href="https://www.youtube.com/watch?v=OMPfEXIlTVE">Nothing is Something</a> by <a href="https://twitter.com/sandimetz">Sandi Metz</a></li> +<li><a href="https://www.youtube.com/watch?v=MSgR-hJjdTo">Sometimes a Controller is Just a Controller</a> by <a href="https://twitter.com/searls">Justin Searls</a></li> +</ul> + + + + Grab Bag! Derek and Sean talk about math, augmented reality, RailsConf wrap up, Minimum Viable Products, Accessibility...

+ +

Support The Bike Shed

]]> + + + Grab Bag! Derek and Sean talk about math, augmented reality, RailsConf wrap up, Minimum Viable Products, Accessibility...

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+UumD9Kh2 + + ]]> + + + + 15: Might As Well Be About Trains (Sarah Mei) + https://bikeshed.thoughtbot.com/15 + 87c18c0c-4379-4dad-943f-8c17815537da + Tue, 19 May 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean, Derek, and Sarah Mei talk about conference speaking, refactoring, and OO vs FP problems. + 31:18 + no + + <p>Sean, Derek, and Sarah Mei talk about conference speaking, refactoring, and OO vs FP problems.</p> +<ul> +<li><a href="http://www.sarahmei.com/">Sarah Mei</a></li> +<li><a href="http://www.sarahmei.com/blog/2014/04/07/what-your-conference-proposal-is-missing/">What Your Conference Proposal Is Missing</a></li> +<li><a href="http://en.wikipedia.org/wiki/Conway%27s_law">Conway's Law</a></li> +<li><a href="https://www.omniref.com/blog/blog/2014/11/17/matz-at-rubyconf-2014-will-ruby-3-dot-0-be-statically-typed/">Will Ruby 3.0 Be Statically Typed?</a></li> +<li><a href="https://twitter.com/sarahmei">Sarah on Twitter</a></li> +</ul> + + + + Sean, Derek, and Sarah Mei talk about conference speaking, refactoring, and OO vs FP problems.

+ +

Support The Bike Shed

]]> + + + Sean, Derek, and Sarah Mei talk about conference speaking, refactoring, and OO vs FP problems.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+3hSeqlcW + + ]]> + + + + 14: An Acceptable Level of Hassle (David Heinemeier Hansson) + https://bikeshed.thoughtbot.com/14 + 1470df51-73f4-44e3-ba09-dec4556a0a0d + Tue, 12 May 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + This week, we're joined by DHH and discuss microservices, monoliths, shared abstractions, and the fate of Action Cable. + 54:31 + no + + <p>This week, we're joined by DHH and discuss microservices, monoliths, shared abstractions, and the fate of Action Cable.</p> +<ul> +<li><a href="https://www.youtube.com/watch?v=KJVTM7mE1Cc">DHH's Keynote</a></li> +<li><a href="http://martinfowler.com/articles/microservices.html">Microservices</a></li> +<li><a href="http://martinfowler.com/bliki/SacrificialArchitecture.html">Sacrificial Architecture</a></li> +<li><a href="https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/">Scaling Mercurial at Facebook</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveModel/SecurePassword/ClassMethods.html#method-i-has_secure_password"><code>has_secure_password</code></a></li> +<li><a href="https://github.com/codahale/bcrypt-ruby">BCrypt</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection.html">Request Forgery Protection</a></li> +<li><a href="http://apidock.com/rails/ActionView/Helpers/ActiveRecordHelper/error_messages_for"><code>error_messages_for</code></a> removed in Rails 3</li> +<li>Sandi Metz on <a href="https://twitter.com/sandimetz/status/273110526706462721">the cost of the wrong abstraction</a></li> +<li><a href="https://developer.mozilla.org/en-US/docs/WebSockets">WebSockets</a></li> +<li><a href="https://github.com/eventmachine/eventmachine">Event Machine</a></li> +<li><a href="http://faye.jcoglan.com/">Faye</a></li> +<li><a href="http://basecamp.com">Basecamp</a></li> +</ul> + + + + This week, we're joined by DHH and discuss microservices, monoliths, shared abstractions, and the fate of Action Cable.

+ +

Support The Bike Shed

]]> + + + This week, we're joined by DHH and discuss microservices, monoliths, shared abstractions, and the fate of Action Cable.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Haexb10W + + ]]> + + + + 13: Begrudging Applause (Aaron Patterson) + https://bikeshed.thoughtbot.com/13 + 4217bded-354d-4d72-bef2-ead33ff1c130 + Tue, 05 May 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Live from RailsConf, Aaron Patterson joins the show to talk about Rails 5, Rack 2, Contributing to Open Source, and cats. We also field audience questions. + 53:27 + no + + <p>Live from RailsConf, Aaron Patterson joins the show to talk about Rails 5, Rack 2, Contributing to Open Source, and cats. We also field audience questions.</p> +<ul> +<li><a href="https://youtu.be/kDdYNPVqLZs">Video-version of this podcast!</a></li> +<li><a href="https://youtu.be/KJVTM7mE1Cc">DHH's RailsConf Keynote</a></li> +<li><a href="https://youtu.be/B3gYklsN9uc">Aaron's RailsConf Keynote</a></li> +<li><a href="https://gist.github.com/derekprior/45ffcccf55b7b7d26ace">Action Cable</a></li> +<li><a href="http://en.wikipedia.org/wiki/Push_technology#Long_polling">Long Polling</a></li> +<li><a href="https://github.com/rails/turbolinks">TurboLinks</a></li> +<li><a href="https://github.com/emberjs/rfcs">Ember RFC Process</a></li> +<li><a href="https://github.com/tenderlove/the_metal">Rack 2</a></li> +<li><a href="https://itunes.apple.com/us/app/nekoatsume/id923917775?mt=8">Neko Atsume</a> (<a href="https://play.google.com/store/apps/details?id=jp.co.hit_point.nekoatsume&amp;hl=ja">also on Android</a>)</li> +<li><a href="https://rubytogether.org/">Ruby Together</a></li> +<li><a href="http://www.call-cc.org/">Chicken Scheme</a></li> +<li><a href="http://wiki.call-cc.org/eggref/4/awful">Awful</a></li> +<li><a href="http://en.wikipedia.org/wiki/Offal">Offal</a></li> +<li><a href="https://iojs.org/en/faq.html">Node/IO Fork</a></li> +<li><a href="https://pragprog.com/book/rails4/agile-web-development-with-rails-4">Agile Web Development With Rails</a></li> +<li><a href="https://github.com/apotonick/cells">Cells</a></li> +</ul> + + + + Live from RailsConf, Aaron Patterson joins the show to talk about Rails 5, Rack 2, Contributing to Open Source, and cats. We also field audience questions.

+ +

Support The Bike Shed

]]> + + + Live from RailsConf, Aaron Patterson joins the show to talk about Rails 5, Rack 2, Contributing to Open Source, and cats. We also field audience questions.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+lOxyYSq9 + + ]]> + + + + 12: A Poor Man's binding.pry + https://bikeshed.thoughtbot.com/12 + 088fe107-3e91-4794-98ca-6461c27a9ede + Fri, 17 Apr 2015 13:00:00 -0400 + thoughtbot + + full + thoughtbot + Derek and Sean talk about naming, debugging, and the anxiety of conference talks. + 31:55 + no + + <p>Derek and Sean talk about naming, debugging, and the anxiety of conference talks.</p> +<ul> +<li>Sean <a href="https://github.com/saturday06/gradle-android-scala-plugin/pull/55/files#diff-7b639ea9e4a150c67861b3c35dbd8b9eL211">fixes Android tooling</a> in one line.</li> +<li>Martin Fowler on <a href="http://martinfowler.com/articles/refactoring-external-service.html">naming objects after patterns</a></li> +<li><a href="https://kapeli.com/dash">Dash</a> for OS X</li> +<li><a href="http://www.alfredapp.com/">Alfred</a> for OS X</li> +<li>The beauty of <a href="http://sapphiresteel.com/IMG/png/intellisense.png">Intellisense</a> in Visual Studio</li> +<li>Derek's <a href="https://github.com/thoughtbot/dotfiles/pull/360"><code>bundle search</code></a> command</li> +<li><a href="https://www.jetbrains.com/ruby/">Ruby Mine</a></li> +<li><a href="http://www.windycityrails.org/videos/2014/#9">Sean's talk at windy city rails</a></li> +<li><a href="https://www.youtube.com/watch?v=l9JXH7JPjR4">How to talk to Developers</a> by Ben Orenstein</li> +</ul> + + + + Derek and Sean talk about naming, debugging, and the anxiety of conference talks.

+ +

Support The Bike Shed

]]> + + + Derek and Sean talk about naming, debugging, and the anxiety of conference talks.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+AFjybsW- + + ]]> + + + + 11: Form-ing Opinions + https://bikeshed.thoughtbot.com/11 + a41615a3-81e7-445b-a31d-1e524392bb39 + Fri, 03 Apr 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Derek talk about the state of Android tooling, refactoring journeys, and an approach to rails form objects. + 37:19 + no + + <p>Sean and Derek talk about the state of Android tooling, refactoring journeys, and an approach to rails form objects.</p> +<ul> +<li><a href="https://developer.android.com/tools/building/multidex.html">Dalvik executables limited to 65,536 methods</a></li> +<li><a href="http://proguard.sourceforge.net/">ProGuard</a></li> +<li><a href="http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164546.aspx">Stylesheet limits in Internet Explorer</a></li> +<li>A <a href="https://lh4.googleusercontent.com/-q_CSd6VuGxg/UfeYTp6ci_I/AAAAAAAAgV8/gXy32wVX47A/w480-h360-no/programming.gif">refactoring jounrney</a> in animated gif form.</li> +<li><a href="https://github.com/plataformatec/simple_form#the-wrappers-api">Simple Form wrappers</a></li> +<li><a href="https://www.playframework.com/documentation/2.0/ScalaForms">ScalaForms</a></li> +<li><a href="http://www.yesodweb.com/book/routing-and-handlers">Type-safe URLs in Yesod</a></li> +<li><a href="https://docs.djangoproject.com/en/1.8/topics/forms/">Django forms</a></li> +<li><a href="https://github.com/rails/rails/pull/19324">Batching up touch calls</a></li> +<li><a href="https://robots.thoughtbot.com/the-perils-of-uniqueness-validations">Issues with uniqueness validations</a></li> +</ul> + + + + Sean and Derek talk about the state of Android tooling, refactoring journeys, and an approach to rails form objects.

+ +

Support The Bike Shed

]]> + + + Sean and Derek talk about the state of Android tooling, refactoring journeys, and an approach to rails form objects.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+fgiVrbqB + + ]]> + + + + 10: I Don't Get Functional Programming + https://bikeshed.thoughtbot.com/10 + 4ee821ab-ad43-4432-b5da-4b8468858bf3 + Fri, 20 Mar 2015 00:00:00 -0400 + thoughtbot + + full + thoughtbot + Pat Brisbin joins Derek to discuss the many advantages of Haskell programming. + 40:35 + no + + <p>Pat Brisbin joins Derek to discuss the many advantages of Haskell programming.</p> +<p><em>note: at 27:01 Pat says &quot;referential integrity&quot; when he meant &quot;<a href="https://wiki.haskell.org/Referential_transparency">referential transparency</a>&quot;; he's very sorry.</em></p> +<ul> +<li><a href="http://maybe-haskell.com/bikeshed">Maybe Haskell</a> 50% off</li> +<li><a href="http://xmonad.org/">xmonad</a> tiling window manager</li> +<li><a href="http://learnyouahaskell.com/">Learn You A Haskell</a></li> +<li><a href="https://github.com/thoughtbot/carnival">Carnival</a> - Open source, Haskell-powered commenting for the <a href="https://robots.thoughtbot.com/ship-you-a-haskell">Giant Robots Blog</a></li> +<li><a href="https://wiki.haskell.org/Pointfree">Pointfree Style</a></li> +<li><a href="https://twitter.com/patbrisbin/status/556555319909056512">How to say dots and dollars</a></li> +<li><a href="https://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Maybe.html">The Maybe data type</a></li> +<li><a href="https://hackhands.com/guide-lazy-evaluation-haskell/">The Incomplete Guide to Lazy Evaluation (in Haskell)</a></li> +<li><a href="https://robots.thoughtbot.com/building-haskell-projects-with-halcyon">Building Haskell Projects with Halcyon</a></li> +</ul> + + + + Pat Brisbin joins Derek to discuss the many advantages of Haskell programming.

+ +

note: at 27:01 Pat says "referential integrity" when he meant "referential transparency"; he's very sorry.

+ +

Support The Bike Shed

]]> + + + Pat Brisbin joins Derek to discuss the many advantages of Haskell programming.

+ +

note: at 27:01 Pat says "referential integrity" when he meant "referential transparency"; he's very sorry.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+IWY0QJG7 + + ]]> + + + + 9: Monorails, For the Kids + https://bikeshed.thoughtbot.com/9 + 2baab32c-1c02-4b38-a1c5-25fbd8ee626b + Fri, 06 Mar 2015 00:00:00 -0500 + thoughtbot + + full + thoughtbot + Sean and Derek discuss Monoliths, Service Oriented Architecture, and the new Adapter Specific Type Registry in Rails 5. + 34:37 + no + + <p>Sean and Derek discuss Monoliths, Service Oriented Architecture, and the new Adapter Specific Type Registry in Rails 5.</p> +<ul> +<li><a href="http://images.thoughtbot.com/podcasts/bikeshed/guestsean.jpg">Guest Sean</a></li> +<li><a href="http://pokemondb.net/pokedex/furret">Furret</a></li> +<li><a href="https://upcase.com/haskell">Haskell</a> and <a href="https://upcase.com/workflow">tmux</a> Upcase trails.</li> +<li><a href="http://www.schneems.com/2014/12/15/hashie-considered-harmful.html">Hashie Considered Harmful</a></li> +<li><a href="https://github.com/rails/rails/blob/265dcb779dd4bfd9745e0131f585749d7034c3c7/activerecord/lib/active_record/type/adapter_specific_registry.rb">Adapter Specific Type Registry</a></li> +</ul> + + + + Sean and Derek discuss Monoliths, Service Oriented Architecture, and the new Adapter Specific Type Registry in Rails 5.

+ +

Support The Bike Shed

]]> + + + Sean and Derek discuss Monoliths, Service Oriented Architecture, and the new Adapter Specific Type Registry in Rails 5.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Sl56kN4x + + ]]> + + + + 8: Attributes API, Relation#or, Paid Open Source + https://bikeshed.thoughtbot.com/8 + 242598f2-9ef0-40e3-bcdf-153a2f9602d0 + Fri, 20 Feb 2015 13:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean discuss what the Attributes API enables, the addition of `Relation#or` and paid open source. + 37:29 + no + + <p>Derek and Sean discuss what the Attributes API enables, the addition of <code>Relation#or</code> and paid open source.</p> +<ul> +<li><a href="https://github.com/rails/rails/commit/70ac072976c8cc6f013f0df3777e54ccae3f4f8c">Sean's attributes API is &quot;finished&quot;</a></li> +<li><a href="https://github.com/rails/rails/blob/8c752c7ac739d5a86d4136ab1e9d0142c4041e58/activerecord/lib/active_record/attributes.rb">Attributes API documentation</a></li> +<li><a href="https://github.com/rgeo/activerecord-postgis-adapter">PostGIS ActiveRecord Adapter</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/Aggregations/ClassMethods.html"><code>composed_of</code></a></li> +<li><a href="http://confreaks.tv/videos/railsconf2014-keynote-10-years">Yehuda's RailsConf Keynote</a> on the power of shared abstractions.</li> +<li><a href="http://confreaks.tv/videos/railsconf2014-curmudgeon-an-opinionated-look-at-an-opinionated-framework">Ernie Miller's RailsConf talk</a> on the consequences of Rails' abstractions.</li> +<li><a href="https://github.com/rails/rails/blob/158c7eb1d61a28452e0aafd1e05314352eea2749/activerecord/lib/active_record/model_schema.rb#L310-L320"><code>load_schema</code> makes sense now.</a></li> +<li><a href="http://ruby-doc.org//stdlib-2.2.0/libdoc/delegate/rdoc/Object.html"><code>DelegateClass</code></a></li> +<li><a href="https://twitter.com/steveklabnik/status/563169746615406592">Steve Klabnik tweets</a> about companies not giving back significantly to Ruby open source</li> +<li><a href="https://github.com/jruby/jruby/pull/2562">Sean speeds up <code>&amp;block</code> on MRI and jRuby</a></li> +</ul> + + + + Derek and Sean discuss what the Attributes API enables, the addition of Relation#or and paid open source.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss what the Attributes API enables, the addition of Relation#or and paid open source.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+Jf-8Q4E2 + + ]]> + + + + 7: At the Car Wash + https://bikeshed.thoughtbot.com/7 + da778230-899a-4e95-aa22-8087d3384df6 + Fri, 30 Jan 2015 10:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean talk trade schools, sneaky bugs, bad method names, before_filters, and the Superbowl. + 48:52 + no + + <p>Derek and Sean talk trade schools, sneaky bugs, bad method names, before_filters, and the Superbowl.</p> +<ul> +<li><a href="http://turing.io">Turing School</a> and <a href="http://www.thisismetis.com/ruby-on-rails">Metis</a> trade schools.</li> +<li><a href="http://youtu.be/3v8I5egzoMo">&quot;Car Wash&quot;</a> by Rose Royce</li> +<li>Sean introduces <a href="https://github.com/rails/rails/commit/be9b68038e83a617eb38c26147659162e4ac3d2c"><code>accessed_fields</code></a> to the ActiveRecord Attributes API.</li> +<li><a href="https://github.com/peek/peek">Peek</a> for insights into your rails app.</li> +<li><a href="https://github.com/flyerhzm/bullet">Bullet</a> for hunting down N+1 queries and unused eager loading.</li> +<li>What does <a href="https://github.com/lostisland/faraday#writing-middleware">Faraday middleware</a> look like?</li> +<li>The <a href="https://github.com/thoughtbot/clearance/commit/4b514d94a5a00c754f3638709d1a36814522422a">Clearance redirect loop</a> Derek introduced and fixed.</li> +<li><code>before filter</code> and its friends have been <a href="https://github.com/rails/rails/commit/7644a99d90a0521165ebde1ccd201603bf7f126a">deprecated in Rails 5.0</a></li> +<li>The various ways people <a href="http://www.intridea.com/blog/2011/6/7/conversations-controller-setter-pattern">set instance variables in Rails controllers</a>.</li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/BeforeTypeCast.html#method-i-read_attribute_before_type_cast"><code>read_attribute_before_typecast</code></a></li> +<li><a href="https://github.com/rails/rails/compare/787e22bb491bd8c36db1e9734261c4ce02c5c5fd%7E1...d8e710410ea300ec4626250c0b35946cb52bc38c">problems from _before_type_cast</a></li> +<li><a href="https://github.com/rails/rails/commit/96e504ec8af149962312c13dd418e13e4c74ce86">dirty checking causes errors</a></li> +<li><a href="https://github.com/rails/rails/commit/7c6f3938dee47f0932c2a1d4924adaebc25517ac"><code>RangeError</code> s are hard</a> (Sean's solution to the test placement problem was to not commit the test)</li> +</ul> + + + + Derek and Sean talk trade schools, sneaky bugs, bad method names, before_filters, and the Superbowl.

+ +

Support The Bike Shed

]]> + + + Derek and Sean talk trade schools, sneaky bugs, bad method names, before_filters, and the Superbowl.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+M-HMP8k9 + + ]]> + + + + 6: Shh! Library Under Maintenance + https://bikeshed.thoughtbot.com/6 + 2d532b6f-620a-46a1-86f6-be6689fdd875 + Fri, 16 Jan 2015 11:00:00 -0500 + thoughtbot + + full + thoughtbot + Sean and Derek discuss thoughtful deprecations, backwards compatibility, and other joys of library maintenance. + 42:12 + no + + <p>Sean and Derek discuss thoughtful deprecations, backwards compatibility, and other joys of library maintenance.</p> +<ul> +<li><a href="https://github.com/apotonick/trailblazer">Trailblazer</a></li> +<li><a href="https://github.com/thoughtbot/clearance">Clearance</a></li> +<li><a href="https://github.com/emberjs/rfcs/pull/15">Ember 2.0</a> - Stability without Stagnation</li> +<li><a href="https://github.com/rails/rails/pull/18306">Ruby 2.2 on Rails 3.2</a>. Now merged, but unreleased.</li> +<li>The original <a href="https://github.com/rails/arel/commit/008445d6fd5f825d9b445ac75a7be67f0f7ab52c">removal of ARel type casting</a></li> +<li>Narrowing the scope - a <a href="https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11">less impactful ARel deprecation</a></li> +<li><a href="https://github.com/rails/rails/compare/266ff70...2223f49">Rails changes</a> to accompany the ARel API changes.</li> +<li>An <a href="https://github.com/rails/rails/issues/18385#issuecomment-69979898">example of an issue</a> these refactorings solve.</li> +</ul> + + + + Sean and Derek discuss thoughtful deprecations, backwards compatibility, and other joys of library maintenance.

+ +

Support The Bike Shed

]]> + + + Sean and Derek discuss thoughtful deprecations, backwards compatibility, and other joys of library maintenance.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+P_olymIh + + ]]> + + + + 5: Rails is Not Your Architecture + https://bikeshed.thoughtbot.com/5 + 5db5d987-947f-41ab-8fbf-0c9f8de726d2 + Wed, 31 Dec 2014 11:30:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean discuss various ways of taking the Rails out of your Ruby on Rails application, what folder to put your files in, and the difficulties and rewards of learning new programming languages. + 39:10 + no + + <p>Derek and Sean discuss various ways of taking the Rails out of your Ruby on Rails application, what folder to put your files in, and the difficulties and rewards of learning new programming languages.</p> +<ul> +<li><a href="http://naildrivin5.com/blog/2014/05/27/rails-does-not-define-your-application-architecture.html">Rails Does Not Define Your Application Architecture</a></li> +<li>What the hell is a <a href="http://stevelorek.com/service-objects.html">service object</a>?</li> +<li>Fuzzy file finding with <a href="https://github.com/ctrlpvim/ctrlp.vim">ctrl-p</a></li> +<li><a href="http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models#query-objects">Query Objects</a></li> +<li>Uncle Bob's <a href="http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html">Clean Architecture</a></li> +<li><a href="http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/#form-objects">Form Objects</a></li> +<li><a href="https://www.playframework.com/documentation/2.0/ScalaForms">Scala Play forms</a></li> +<li><a href="http://www.yesodweb.com/book/forms">Haskell Yesod Forms</a></li> +<li><a href="https://www.haskell.org/haskellwiki/Pointfree#But_pointfree_has_more_points.21">But Pointfree Has More Points</a>!</li> +</ul> + + + + Derek and Sean discuss various ways of taking the Rails out of your Ruby on Rails application, what folder to put your files in, and the difficulties and rewards of learning new programming languages.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss various ways of taking the Rails out of your Ruby on Rails application, what folder to put your files in, and the difficulties and rewards of learning new programming languages.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+FmDflQJZ + + ]]> + + + + 4: Put Everything on the Front End + https://bikeshed.thoughtbot.com/4 + 0a0137bb-9417-4765-8842-aacc8aeeac38 + Fri, 12 Dec 2014 14:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean discuss hunting Rails performance regressions and techniques for improving performance in your web applications. + 38:20 + no + + <p>Derek and Sean discuss hunting Rails performance regressions and techniques for improving performance in your web applications.</p> +<ul> +<li><a href="http://samsaffron.com/archive/2014/12/01/speeding-up-rails-4-2">Speeding Up Rails 4.2</a></li> +<li><a href="http://tmm1.net/ruby21-profiling/">StackProf</a></li> +<li><a href="http://samsaffron.com/archive/2013/03/19/flame-graphs-in-ruby-miniprofiler">Flame Graphs</a></li> +<li><a href="http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/">5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service</a></li> +<li><a href="http://en.wikipedia.org/wiki/Key_frame">Key Frames</a></li> +<li><a href="http://c2.com/cgi/wiki?BinarySearch">Binary Search Algorithm</a></li> +<li><a href="https://www.youtube.com/watch?v=fGFM_UrSp70">Writing Fast Ruby</a> from Erik Micahels-Ober</li> +<li>The <a href="http://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#method-i-select">select</a> and <a href="http://api.rubyonrails.org/classes/ActiveRecord/Calculations.html#method-i-pluck">pluck</a> methods</li> +<li><a href="http://guides.rubyonrails.org/caching_with_rails.html#fragment-caching">Fragment Caching</a></li> +<li><a href="https://github.com/rails/jquery-ujs/commit/c7dcc344eefcd9a646fe570f00fec73078ecb6c4">Exposing CSRF token refresh</a> in the jQuery UJS public API.</li> +<li>Postgres <a href="http://www.postgresql.org/docs/9.3/static/using-explain.html">Explain Plans</a></li> +<li><a href="http://robots.thoughtbot.com/implementing-multi-table-full-text-search-with-postgres">Implementing Multi-Table Full Text Search with Postgres in Rails</a></li> +<li>Creating database views in Rails with <a href="https://github.com/thoughtbot/scenic">Scenic</a></li> +<li>Tweet us <a href="https://twitter.com/_bikeshed">@_bikeshed</a> or send us <a href="mailto:hosts@bikeshed.fm">email</a></li> +</ul> + + + + Derek and Sean discuss hunting Rails performance regressions and techniques for improving performance in your web applications.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss hunting Rails performance regressions and techniques for improving performance in your web applications.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+HpAyMqvr + + ]]> + + + + 3: Flipping the Script + https://bikeshed.thoughtbot.com/3 + 4bf29fc6-2832-418c-84c9-76c6862efaf5 + Fri, 28 Nov 2014 01:00:00 -0500 + thoughtbot + + full + thoughtbot + Sean and Derek take a fresh look at the tradeoffs in writing CoffeeScript and whether we should be using an ES6 transpiler instead. + 25:37 + no + + <p>Sean and Derek take a fresh look at the tradeoffs in writing CoffeeScript and whether we should be using an ES6 transpiler instead.</p> +<ul> +<li><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment">destructiring assignment</a> in JavaScript</li> +<li><a href="http://robots.thoughtbot.com/function-currying-in-coffeescript">function currying</a> in CoffeeScript</li> +<li>The <a href="http://coffeescript.org/#operators-existential">existential operator</a> in CoffeeScript</li> +<li><a href="http://en.wikipedia.org/wiki/Stockholm_syndrome">Stockholm syndrome</a></li> +<li><a href="https://www.youtube.com/watch?v=pM_ak1KsBKI#t=15m57s">CoffeeScript writes better JavaScript than you</a></li> +<li><a href="http://kangax.github.io/compat-table/es5/">ES5 Compatibility Chart</a>: When can I use <code>map</code>, <code>reduce</code> and <code>forEach</code>?</li> +<li>Underscore.js <a href="https://github.com/jashkenas/underscore/pull/1525">removes fallbacks to native ES5 array functions</a></li> +<li>Safari's <a href="https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/">LLVM-optimized FTL JIT Compiler</a></li> +<li>ES6 Transpilers <a href="https://github.com/google/traceur-compiler">traceur</a> and <a href="https://github.com/esnext/esnext">ESNext</a></li> +<li><a href="https://github.com/lukehoban/es6features">ES6 Features</a></li> +<li>A plethora of <a href="http://blog.cozycloud.cc/technic/2014/06/18/task-runners-comparison/">JavaScript build tools</a></li> +<li>ES5 <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode">strict mode</a></li> +<li>Sprockets <a href="https://github.com/sstephenson/sprockets/issues/643">road map</a> for source maps support</li> +</ul> + + + + Sean and Derek take a fresh look at the tradeoffs in writing CoffeeScript and whether we should be using an ES6 transpiler instead.

+ +

Support The Bike Shed

]]> + + + Sean and Derek take a fresh look at the tradeoffs in writing CoffeeScript and whether we should be using an ES6 transpiler instead.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+AAHZcIR9 + + ]]> + + + + 2: Rails 4.2 + https://bikeshed.thoughtbot.com/2 + 2cba067b-7e70-4b18-a338-a88460c46f98 + Mon, 17 Nov 2014 09:00:00 -0500 + thoughtbot + + full + thoughtbot + Derek and Sean discuss Sean's commit access to Rails, what's coming in Rails 4.2, and how to go about making Rails code better. + 35:51 + no + + <p>Derek and Sean discuss Sean's commit access to Rails, what's coming in Rails 4.2, and how to go about making Rails code better.</p> +<ul> +<li>Ylan Segal wrote us to raise a <a href="http://ylan.segal-family.com/blog/2013/12/11/sandi-metz-revised-rules/">clarification</a> on one of Sandi's rules discussed in episode #1.</li> +<li><a href="http://confreaks.com/videos/3387-railsconf-curmudgeon-an-opinionated-look-at-an-opinionated-framework">Ernie Miller's RailsConf Talk</a></li> +<li>The <a href="http://edgeguides.rubyonrails.org/4_2_release_notes.html">Rails 4.2 release notes</a>.</li> +<li>Sean's work on the <a href="https://github.com/rails/rails/blob/master/activerecord/lib/active_record/attributes.rb">attributes API</a>.</li> +<li>Aaron Patterson explains <a href="http://tenderlovemaking.com/2014/02/19/adequaterecord-pro-like-activerecord.html">Adequate Record</a></li> +<li>Aaron Patterson discusses adequate record, rails, and other topics on <a href="http://giantrobots.fm/100">Giant Robots #100</a>.</li> +<li><a href="http://edgeguides.rubyonrails.org/active_job_basics.html">Active Job</a></li> +<li><a href="https://github.com/rails/globalid">Global Id</a></li> +<li><a href="https://github.com/rails/web-console">Web Console</a></li> +<li><a href="https://github.com/matthuhiggins/foreigner">Foreigner</a> and <a href="https://github.com/jenseng/immigrant">Immigrant</a> are a good foreign key combination today with Foreigner subsumed by 4.2.</li> +<li><a href="http://edgeapi.rubyonrails.org/classes/Hash.html#method-i-transform_values">transform_values</a></li> +<li><a href="https://github.com/plataformatec/responders">Responders</a></li> +<li>Derek's <a href="https://github.com/rails/rails/commit/9cdd0a1fdf8308985231242d378e3a1c29c4ab00">unDRY Rails Commit</a>.</li> +<li>Thanks to <a href="https://twitter.com/rachelcope">Rachel Cope</a> and <a href="https://twitter.com/kaishin">Reda Lemeden</a> for our great artwork.</li> +</ul> + + + + Derek and Sean discuss Sean's commit access to Rails, what's coming in Rails 4.2, and how to go about making Rails code better.

+ +

Support The Bike Shed

]]> + + + Derek and Sean discuss Sean's commit access to Rails, what's coming in Rails 4.2, and how to go about making Rails code better.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+1G0ZeEEp + + ]]> + + + + 1: Sandi & Derek's Rules + https://bikeshed.thoughtbot.com/1 + 8edf6560-02ff-4be0-beed-0f5e668c87c9 + Fri, 31 Oct 2014 10:00:00 -0400 + thoughtbot + + full + thoughtbot + Sean and Derek discuss lessons learned from following Sandi Metz' rules on a project and the overall impact of rules on code. + 27:48 + no + + <p>Sean and Derek discuss lessons learned from following Sandi Metz' rules on a project and the overall impact of rules on code.</p> +<ul> +<li><a href="http://robots.thoughtbot.com/sandi-metz-rules-for-developers">Sandi Metz' Rules</a></li> +<li><a href="http://robots.thoughtbot.com/sandi-metz-rules-for-developers">Ruby Rogues, episode #87</a>, where Sandi tells us the rules at 1 hour, 18 minutes, 27 seconds in.</li> +<li><a href="http://www.poodr.com/">Practical Object Oriented Design in Ruby</a>, or POODR, is an excellent book you should all check out.</li> +<li><a href="http://en.wikipedia.org/wiki/God_object">God classes</a></li> +<li><a href="https://github.com/thoughtbot/guides/tree/master/style#ruby">thoughtbot's Ruby style guidelines</a> wherein we disavow ternary operators and conditional modifiers.</li> +<li><a href="http://c2.com/cgi/wiki?FacadePattern">The facade pattern</a></li> +<li><a href="http://c2.com/cgi/wiki?GuardClause">Guard clause</a></li> +<li>Ruby's <a href="http://www.ruby-doc.org/core-2.1.3/Module.html#method-i-method_added"><code>method_added</code></a> method.</li> +</ul> + + + + Sean and Derek discuss lessons learned from following Sandi Metz' rules on a project and the overall impact of rules on code.

+ +

Support The Bike Shed

]]> + + + Sean and Derek discuss lessons learned from following Sandi Metz' rules on a project and the overall impact of rules on code.

+ +

Support The Bike Shed

]]> + + https://fireside.fm/player/v2/fa2C4vFU+caZVe0Sv + + ]]> + + + + diff --git a/spec/fixtures/giant_robots_feed.xml b/spec/fixtures/giant_robots_feed.xml new file mode 100644 index 0000000..63629f8 --- /dev/null +++ b/spec/fixtures/giant_robots_feed.xml @@ -0,0 +1,128515 @@ + + + + feed02.fireside.fm + Mon, 16 Dec 2024 07:20:55 -0600 + Fireside (https://fireside.fm) + Giant Robots Smashing Into Other Giant Robots + https://podcast.thoughtbot.com + Mon, 16 Dec 2024 13:15:49 -0000 + A podcast about the design, development, and business of great software. Each week thoughtbot is joined by the people who build and nurture the products we love. + + en-us + © 2024 thoughtbot, inc. + episodic + + thoughtbot + A podcast about the design, development, and business of great software. Each week thoughtbot is joined by the people who build and nurture the products we love. + + + no + design, development, software, saas, business of software, app development, founders, software development, business + + thoughtbot + hosts@giantrobots.fm + + yes + Support the show! + + + + + + + + + 553: The One with Sami and Chad + https://podcast.thoughtbot.com/553 + 9853e4d7-1268-41c5-862e-52d5dc6b24d0 + Thu, 05 Dec 2024 03:00:00 -0500 + thoughtbot + + full + 14 + thoughtbot + After 10 years and 550 episodes of Giant Robots, Chad and Sami are ready to discuss what’s next for the podcast. The pair dive into some podcast role-play as they test out some ideas for iterating the show’s formula. + +Peak behind the curtain as they discuss the inner workings of the show, the challenges of working on a mature codebase, how thoughtbot tackles impostor syndrome when onboarding new employees and the developing accessibility of AI. + 38:09 + no + + After 10 years and 550 episodes of Giant Robots, Chad and Sami are ready to discuss what’s next for the podcast. The pair dive into some podcast role-play as they test out some ideas for iterating the show’s formula. +Peek behind the curtain as they discuss the inner workings of the show, the challenges of working on a mature codebase, how thoughtbot tackles impostor syndrome when onboarding new employees and the developing accessibility of AI. +— +Your hosts for this episode have been Chad Pytel and Sami Birnbaum. +You can find Chad all over social media as @cpytel, or over on LinkedIn (https://www.linkedin.com/in/cpytel/). Sami can be found through his website (https://samibirnbaum.com) or via LinkedIn (https://www.linkedin.com/in/samibirnbaum/). +— +If you would like to support the show, head over to our GitHub page (https://github.com/sponsors/thoughtbot), or check out our website (https://podcast.thoughtbot.com). +Got a question or comment about the show? Why not write to our hosts: hosts@giantrobots.fm +This has been a thoughtbot (https://thoughtbot.com/) podcast. +Stay up to date by following us on social media - LinkedIn (https://www.linkedin.com/company/150727/) - Mastodon (https://thoughtbot.social/@thoughtbot) - Instagram (https://www.instagram.com/thoughtbot/) +© 2024 thoughtbot, inc. + + AI, codebase, impostor syndrome + + After 10 years and 550 episodes of Giant Robots, Chad and Sami are ready to discuss what’s next for the podcast. The pair dive into some podcast role-play as they test out some ideas for iterating the show’s formula.

+ +

Peek behind the curtain as they discuss the inner workings of the show, the challenges of working on a mature codebase, how thoughtbot tackles impostor syndrome when onboarding new employees and the developing accessibility of AI.

+ +

—

+ +

Your hosts for this episode have been Chad Pytel and Sami Birnbaum.
+You can find Chad all over social media as @cpytel, or over on LinkedIn. Sami can be found through his website or via LinkedIn.

+ +

—

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@giantrobots.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + After 10 years and 550 episodes of Giant Robots, Chad and Sami are ready to discuss what’s next for the podcast. The pair dive into some podcast role-play as they test out some ideas for iterating the show’s formula.

+ +

Peek behind the curtain as they discuss the inner workings of the show, the challenges of working on a mature codebase, how thoughtbot tackles impostor syndrome when onboarding new employees and the developing accessibility of AI.

+ +

—

+ +

Your hosts for this episode have been Chad Pytel and Sami Birnbaum.
+You can find Chad all over social media as @cpytel, or over on LinkedIn. Sami can be found through his website or via LinkedIn.

+ +

—

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@giantrobots.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+yy7iS0sb + + ]]> + + Sami Birnbaum + Chad Pytel + + + 552: Scaling an Online Telehealth Experience with Aakash Shah + https://podcast.thoughtbot.com/552 + a9b7495a-1af0-4c7b-8acd-06f42df251b4 + Thu, 28 Nov 2024 03:00:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Chad talks with Aakash Shah, Founder and CEO of Wyndly, about how he built a new online telehealth experience to expand convenient access to allergy immunotherapy. The pair discuss the mechanics of building an online healthcare operation from scratch, the challenges that arise as you begin to scale your business, and how Aakash utilised his past experience as a software engineer to support his new venture. + +Discover why this area of medicine has been overlooked for so long, how COVID has shifted our view on healthcare as a whole, as well as the odd rules and quirks of the FDA when trying to market a new medical service. + 34:50 + no + + Chad talks with Aakash Shah, Founder and CEO of Wyndly (https://www.wyndly.com/), about how he built a new online telehealth experience to expand convenient access to allergy immunotherapy. The pair discuss the mechanics of building an online healthcare operation from scratch, the challenges that arise as you begin to scale your business, and how Aakash utilised his past experience as a software engineer to support his new venture. +Discover why this area of medicine has been overlooked for so long, how COVID has shifted our view on healthcare as a whole, as well as the odd rules and quirks of the FDA when trying to market a new medical service. +To find out more about Aakash’s work with Wyndly you can connect with him on LinkedIn (https://www.linkedin.com/in/mraakashshah/) or send him an email: aakash@wyndly.com +If you’re interested in receiving treatment for persistent allergies, you can book a consultation through Wyndly’s website (https://www.wyndly.com/). +— +Your host for this episode has been Chad Pytel. You can find Chad over on Mastodon (https://thoughtbot.social/@cpytel), or connect with via LinkedIn (https://www.linkedin.com/in/cpytel/). +If you would like to support the show, head over to our GitHub page (https://github.com/sponsors/thoughtbot), or check out our website (https://podcast.thoughtbot.com). +Got a question or comment about the show? Why not write to our hosts: hosts@giantrobots.fm +This has been a thoughtbot (https://thoughtbot.com/) podcast. +Stay up to date by following us on social media - LinkedIn (https://www.linkedin.com/company/150727/) - Mastodon (https://thoughtbot.social/@thoughtbot) - Instagram (https://www.instagram.com/thoughtbot/) +© 2024 thoughtbot, inc. + + healthcare, allergies, telehealth, thoughtbot + + Chad talks with Aakash Shah, Founder and CEO of Wyndly, about how he built a new online telehealth experience to expand convenient access to allergy immunotherapy. The pair discuss the mechanics of building an online healthcare operation from scratch, the challenges that arise as you begin to scale your business, and how Aakash utilised his past experience as a software engineer to support his new venture.

+ +

Discover why this area of medicine has been overlooked for so long, how COVID has shifted our view on healthcare as a whole, as well as the odd rules and quirks of the FDA when trying to market a new medical service.

+ +

To find out more about Aakash’s work with Wyndly you can connect with him on LinkedIn or send him an email: aakash@wyndly.com

+ +

If you’re interested in receiving treatment for persistent allergies, you can book a consultation through Wyndly’s website.

+ +

—

+ +

Your host for this episode has been Chad Pytel. You can find Chad over on Mastodon, or connect with via LinkedIn.

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@giantrobots.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with Aakash Shah, Founder and CEO of Wyndly, about how he built a new online telehealth experience to expand convenient access to allergy immunotherapy. The pair discuss the mechanics of building an online healthcare operation from scratch, the challenges that arise as you begin to scale your business, and how Aakash utilised his past experience as a software engineer to support his new venture.

+ +

Discover why this area of medicine has been overlooked for so long, how COVID has shifted our view on healthcare as a whole, as well as the odd rules and quirks of the FDA when trying to market a new medical service.

+ +

To find out more about Aakash’s work with Wyndly you can connect with him on LinkedIn or send him an email: aakash@wyndly.com

+ +

If you’re interested in receiving treatment for persistent allergies, you can book a consultation through Wyndly’s website.

+ +

—

+ +

Your host for this episode has been Chad Pytel. You can find Chad over on Mastodon, or connect with via LinkedIn.

+ +

If you would like to support the show, head over to our GitHub page, or check out our website.

+ +

Got a question or comment about the show? Why not write to our hosts: hosts@giantrobots.fm

+ +

This has been a thoughtbot podcast.
+Stay up to date by following us on social media - LinkedIn - Mastodon - Instagram

+ +

© 2024 thoughtbot, inc.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+sIK_dZ9q + + ]]> + + Chad Pytel + + + 551: System Design is a Team Sport with Tom Johnson + https://podcast.thoughtbot.com/551 + cac8a515-6c3e-4396-95cd-f41e2379ac39 + Thu, 21 Nov 2024 03:00:00 -0500 + thoughtbot + + full + 14 + thoughtbot + In this episode, entrepreneur, CTO, and co-founder Tom Johnson joins us to discuss Multiplayer, a collaborative tool streamlining system design and documentation for developers. + 37:06 + no + + If system design is a team sport, then you need to make sure that your team has the tools they need to work together. In this episode, entrepreneur, CTO, and co-founder Tom Johnson joins us to discuss Multiplayer, a collaborative tool streamlining system design and documentation for developers. Multiplayer is often likened to “Figma for developers,” as it allows teams to map, document, and debug distributed systems visually and collaboratively. Tom shares his experience building this tool, drawing on years of backend development challenges, from debugging to coordinating across teams. We also discuss the business side of startups before learning about the AI features that they have planned for Multiplayer and how it will benefit users, including eliminating time-consuming “grunt work”. Join us to learn how Multiplayer is revolutionizing system design and get a sneak peek into the exciting AI-powered features on the horizon! +Key Points From This Episode: +Introducing Tom Johnson, co-founder of Multiplayer. +An overview of Multiplayer and how it helps developers work on distributed systems. +The teams and developers that will get the most use out of Multiplayer. +Details on Multiplayer’s debugging and auto-documentation tools. +A breakdown of what distributed systems are in modern software development. +Why Tom sees contemporary systems design as a team sport. +Multiplier’s whiteboard-type space and how it allows teams to collaborate. +Tom’s back-end developer experience and how it helped him create Multiplayer. +How Tom co-founded Multiplayer with his wife, Steph Johnson, and her role as CEO. +Why solving a problem you’ve personally experienced is a good starting point for startups. +What you need to have before fundraising: a minimum viable product (MVP). +How they used the open-source software, YJS, for virtual, real-time collaboration. +Insights into Multiplayer’s upcoming AI-powered features. +Links Mentioned in Today’s Episode: +
Thomas Johnson on LinkedIn (https://www.linkedin.com/in/tomjohnson3/) +Thomas Johnson on X (https://x.com/tomjohnson3) +Thomas Johnson on Threads (https://www.threads.net/@tomjohnson3?hl=en)
 +Steph Johnson on LinkedIn (https://www.linkedin.com/in/steph-johnson-14355b3/)
 +Multiplayer (https://www.multiplayer.app/)
 +YJS (https://github.com/yjs/yjs)
 +Figma (https://www.figma.com/) +Chad Pytel on LinkedIn (https://www.linkedin.com/in/cpytel/) +Chad Pytel on X (https://x.com/cpytel) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + If system design is a team sport, then you need to make sure that your team has the tools they need to work together. In this episode, entrepreneur, CTO, and co-founder Tom Johnson joins us to discuss Multiplayer, a collaborative tool streamlining system design and documentation for developers. Multiplayer is often likened to “Figma for developers,” as it allows teams to map, document, and debug distributed systems visually and collaboratively. Tom shares his experience building this tool, drawing on years of backend development challenges, from debugging to coordinating across teams. We also discuss the business side of startups before learning about the AI features that they have planned for Multiplayer and how it will benefit users, including eliminating time-consuming “grunt work”. Join us to learn how Multiplayer is revolutionizing system design and get a sneak peek into the exciting AI-powered features on the horizon!

+ +

Key Points From This Episode:

+ +

Introducing Tom Johnson, co-founder of Multiplayer.
+An overview of Multiplayer and how it helps developers work on distributed systems.
+The teams and developers that will get the most use out of Multiplayer.
+Details on Multiplayer’s debugging and auto-documentation tools.
+A breakdown of what distributed systems are in modern software development.
+Why Tom sees contemporary systems design as a team sport.
+Multiplier’s whiteboard-type space and how it allows teams to collaborate.
+Tom’s back-end developer experience and how it helped him create Multiplayer.
+How Tom co-founded Multiplayer with his wife, Steph Johnson, and her role as CEO.
+Why solving a problem you’ve personally experienced is a good starting point for startups.
+What you need to have before fundraising: a minimum viable product (MVP).
+How they used the open-source software, YJS, for virtual, real-time collaboration.
+Insights into Multiplayer’s upcoming AI-powered features.

+ +

Links Mentioned in Today’s Episode:
+
Thomas Johnson on LinkedIn
+Thomas Johnson on X
+Thomas Johnson on Threads

+Steph Johnson on LinkedIn

+Multiplayer

+YJS

+Figma
+Chad Pytel on LinkedIn
+Chad Pytel on X
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + If system design is a team sport, then you need to make sure that your team has the tools they need to work together. In this episode, entrepreneur, CTO, and co-founder Tom Johnson joins us to discuss Multiplayer, a collaborative tool streamlining system design and documentation for developers. Multiplayer is often likened to “Figma for developers,” as it allows teams to map, document, and debug distributed systems visually and collaboratively. Tom shares his experience building this tool, drawing on years of backend development challenges, from debugging to coordinating across teams. We also discuss the business side of startups before learning about the AI features that they have planned for Multiplayer and how it will benefit users, including eliminating time-consuming “grunt work”. Join us to learn how Multiplayer is revolutionizing system design and get a sneak peek into the exciting AI-powered features on the horizon!

+ +

Key Points From This Episode:

+ +

Introducing Tom Johnson, co-founder of Multiplayer.
+An overview of Multiplayer and how it helps developers work on distributed systems.
+The teams and developers that will get the most use out of Multiplayer.
+Details on Multiplayer’s debugging and auto-documentation tools.
+A breakdown of what distributed systems are in modern software development.
+Why Tom sees contemporary systems design as a team sport.
+Multiplier’s whiteboard-type space and how it allows teams to collaborate.
+Tom’s back-end developer experience and how it helped him create Multiplayer.
+How Tom co-founded Multiplayer with his wife, Steph Johnson, and her role as CEO.
+Why solving a problem you’ve personally experienced is a good starting point for startups.
+What you need to have before fundraising: a minimum viable product (MVP).
+How they used the open-source software, YJS, for virtual, real-time collaboration.
+Insights into Multiplayer’s upcoming AI-powered features.

+ +

Links Mentioned in Today’s Episode:
+
Thomas Johnson on LinkedIn
+Thomas Johnson on X
+Thomas Johnson on Threads

+Steph Johnson on LinkedIn

+Multiplayer

+YJS

+Figma
+Chad Pytel on LinkedIn
+Chad Pytel on X
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+AUGVD9lF + + ]]> + + Chad Pytel + + + 550: Disrupting and Democratizing Private Chefs with Iyabo Bello + https://podcast.thoughtbot.com/550 + a3d3c74f-c558-4a00-bfe6-71407be4d6ad + Thu, 14 Nov 2024 03:00:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Iyabo Bello is a serial founder and entrepreneur, best known for iKooK, an app connecting private chefs to their target audience. Join us as she shares the unlikely story of how she came up with the idea to start iKooK after working in fashion design and food science. + 39:52 + no + + What if booking a private chef was as easy as ordering an Uber? Iyabo Bello is a serial founder and entrepreneur, best known for iKooK, an app connecting private chefs to their target audience. Join us as she shares the unlikely story of how she came up with the idea to start iKooK after working in fashion design and food science. We get into the weeds with the premise of the app, how it differs from other home chef experiences, and how the cooks are vetted before being allowed to register on the app. Iyabo shares her experience of navigating a double-sided marketplace and discusses the process of building an app and driving traffic toward it instead of her website. We discuss bootstrapping and outsourcing to create a user-friendly, effective app, and handling health and safety as a food service. Join us as we discuss the challenges and benefits of building iKooK, and what you can learn from her journey. Thanks for tuning in. +Key Points From This Episode: +Welcoming Iyabo Bello, founder of iKooK, and the story of the inception of her business. +Her background in fashion design and food science. +The premise of iKooK and how it differs from other home chef experiences. +How the process behind vetting chefs has evolved. +Navigating a double-sided marketplace. +The challenge of finding the right chef with an eye for detail. +Taking down the website to encourage users to book on the app. +Bootstrapping and outsourcing to build the app. +Handling health and safety and building it into the program. +The inclusive and flexible nature of Iyabo’s product. +Challenges she has faced while building the app. +How Jared and Sami would go about assessing the app and user experience. +Links Mentioned in Today’s Episode: +
Iyabo Bello on LinkedIn (https://www.linkedin.com/in/iyabobello/)
 + iKooK Email (info@ikook.co.uk)
 +iKooK (https://ikook.info/) +Sami Birnbaum on LinkedIn (https://www.linkedin.com/in/samibirnbaum/?originalSubdomain=uk)
 +Jared Turner on X (https://x.com/jaredlt) 
 +Jared Turner on LinkedIn (https://www.linkedin.com/in/jaredlt/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + What if booking a private chef was as easy as ordering an Uber? Iyabo Bello is a serial founder and entrepreneur, best known for iKooK, an app connecting private chefs to their target audience. Join us as she shares the unlikely story of how she came up with the idea to start iKooK after working in fashion design and food science. We get into the weeds with the premise of the app, how it differs from other home chef experiences, and how the cooks are vetted before being allowed to register on the app. Iyabo shares her experience of navigating a double-sided marketplace and discusses the process of building an app and driving traffic toward it instead of her website. We discuss bootstrapping and outsourcing to create a user-friendly, effective app, and handling health and safety as a food service. Join us as we discuss the challenges and benefits of building iKooK, and what you can learn from her journey. Thanks for tuning in.

+ +

Key Points From This Episode:

+ +

Welcoming Iyabo Bello, founder of iKooK, and the story of the inception of her business.
+Her background in fashion design and food science.
+The premise of iKooK and how it differs from other home chef experiences.
+How the process behind vetting chefs has evolved.
+Navigating a double-sided marketplace.
+The challenge of finding the right chef with an eye for detail.
+Taking down the website to encourage users to book on the app.
+Bootstrapping and outsourcing to build the app.
+Handling health and safety and building it into the program.
+The inclusive and flexible nature of Iyabo’s product.
+Challenges she has faced while building the app.
+How Jared and Sami would go about assessing the app and user experience.

+ +

Links Mentioned in Today’s Episode:
+
Iyabo Bello on LinkedIn

+ [iKooK Email](info@ikook.co.uk)

+iKooK
+Sami Birnbaum on LinkedIn

+Jared Turner on X 

+Jared Turner on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + What if booking a private chef was as easy as ordering an Uber? Iyabo Bello is a serial founder and entrepreneur, best known for iKooK, an app connecting private chefs to their target audience. Join us as she shares the unlikely story of how she came up with the idea to start iKooK after working in fashion design and food science. We get into the weeds with the premise of the app, how it differs from other home chef experiences, and how the cooks are vetted before being allowed to register on the app. Iyabo shares her experience of navigating a double-sided marketplace and discusses the process of building an app and driving traffic toward it instead of her website. We discuss bootstrapping and outsourcing to create a user-friendly, effective app, and handling health and safety as a food service. Join us as we discuss the challenges and benefits of building iKooK, and what you can learn from her journey. Thanks for tuning in.

+ +

Key Points From This Episode:

+ +

Welcoming Iyabo Bello, founder of iKooK, and the story of the inception of her business.
+Her background in fashion design and food science.
+The premise of iKooK and how it differs from other home chef experiences.
+How the process behind vetting chefs has evolved.
+Navigating a double-sided marketplace.
+The challenge of finding the right chef with an eye for detail.
+Taking down the website to encourage users to book on the app.
+Bootstrapping and outsourcing to build the app.
+Handling health and safety and building it into the program.
+The inclusive and flexible nature of Iyabo’s product.
+Challenges she has faced while building the app.
+How Jared and Sami would go about assessing the app and user experience.

+ +

Links Mentioned in Today’s Episode:
+
Iyabo Bello on LinkedIn

+ [iKooK Email](info@ikook.co.uk)

+iKooK
+Sami Birnbaum on LinkedIn

+Jared Turner on X 

+Jared Turner on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mBuPkiIR + + ]]> + + Will Larry + Chad Pytel + + + 549: Scaling Startups and AI-Powered Real Estate with Chris Fellows + https://podcast.thoughtbot.com/549 + 238191e7-d750-4628-bb86-d974acbe6872 + Thu, 07 Nov 2024 03:00:00 -0500 + thoughtbot + + full + 14 + thoughtbot + We're joined by Chris Fellows, founder and CEO of Bold Street, to explore how his AI-powered platform is reshaping residential investment for real estate professionals. + 33:48 + no + + How do you build a tool that redefines the real estate game for agents and brokers? Today on the show, host Chad Pytel sits down with Chris Fellows, founder and CEO of Bold Street, to explore how his AI-powered platform is reshaping residential investment for real estate professionals. Originally focused on data analytics for big investors, Bold Street pivoted after the Great Recession to meet the needs of agents and brokers. Chris shares how the platform, developed over 18 months, helps agents master investor math and market analysis, boosting efficiency. The conversation dives into current market dynamics, like the rising costs of leads from platforms such as Zillow, which make Bold Street’s value proposition increasingly vital. Chris also expands on the company’s latest round of fundraising before sharing key lessons on scaling a startup in real estate. For these insights and more, don’t miss this fascinating conversation with Chris Fellows!

 +Key Points From This Episode: +A warm welcome to today’s guest, Chris Fellows, founder and CEO of Bold Street. +Founding Bold Street: their initial AI strategy and how it has shifted. +How their software helps agents and brokers be more efficient. +Key takeaways from bringing their first product to market. +Reflections on what could have helped the development process go more quickly. +Chris and his team’s approach to sales and their general pricing model. +A breakdown of their ideal customer and how they are reaching them. +What they’ve done to address their ideal customers’ biggest objections. +Unpacking current market dynamics, from expensive leads to class action lawsuits. +How Bold Street brings value to the current real estate market. +The benefits and challenges of running a business in such a disrupted market. +Reflections on their current fundraising efforts versus their previous round. +Lessons on scaling a startup both locally and through internet marketing. +Links Mentioned in Today’s Episode: +Chris Fellows on LinkedIn (https://www.linkedin.com/in/chriscfellows/)
 +Chris Fellows' email (chris@boldstreet.ai) +Bold Street (https://www.boldstreet.ai/) +Chad Pytel on LinkedIn (https://www.linkedin.com/in/cpytel/) +Chad Pytel on X (https://x.com/cpytel) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + How do you build a tool that redefines the real estate game for agents and brokers? Today on the show, host Chad Pytel sits down with Chris Fellows, founder and CEO of Bold Street, to explore how his AI-powered platform is reshaping residential investment for real estate professionals. Originally focused on data analytics for big investors, Bold Street pivoted after the Great Recession to meet the needs of agents and brokers. Chris shares how the platform, developed over 18 months, helps agents master investor math and market analysis, boosting efficiency. The conversation dives into current market dynamics, like the rising costs of leads from platforms such as Zillow, which make Bold Street’s value proposition increasingly vital. Chris also expands on the company’s latest round of fundraising before sharing key lessons on scaling a startup in real estate. For these insights and more, don’t miss this fascinating conversation with Chris Fellows!



+ +

Key Points From This Episode:

+ +

A warm welcome to today’s guest, Chris Fellows, founder and CEO of Bold Street.
+Founding Bold Street: their initial AI strategy and how it has shifted.
+How their software helps agents and brokers be more efficient.
+Key takeaways from bringing their first product to market.
+Reflections on what could have helped the development process go more quickly.
+Chris and his team’s approach to sales and their general pricing model.
+A breakdown of their ideal customer and how they are reaching them.
+What they’ve done to address their ideal customers’ biggest objections.
+Unpacking current market dynamics, from expensive leads to class action lawsuits.
+How Bold Street brings value to the current real estate market.
+The benefits and challenges of running a business in such a disrupted market.
+Reflections on their current fundraising efforts versus their previous round.
+Lessons on scaling a startup both locally and through internet marketing.

+ +

Links Mentioned in Today’s Episode:

+ +

Chris Fellows on LinkedIn

+[Chris Fellows' email](chris@boldstreet.ai)
+Bold Street
+Chad Pytel on LinkedIn
+Chad Pytel on X
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + How do you build a tool that redefines the real estate game for agents and brokers? Today on the show, host Chad Pytel sits down with Chris Fellows, founder and CEO of Bold Street, to explore how his AI-powered platform is reshaping residential investment for real estate professionals. Originally focused on data analytics for big investors, Bold Street pivoted after the Great Recession to meet the needs of agents and brokers. Chris shares how the platform, developed over 18 months, helps agents master investor math and market analysis, boosting efficiency. The conversation dives into current market dynamics, like the rising costs of leads from platforms such as Zillow, which make Bold Street’s value proposition increasingly vital. Chris also expands on the company’s latest round of fundraising before sharing key lessons on scaling a startup in real estate. For these insights and more, don’t miss this fascinating conversation with Chris Fellows!



+ +

Key Points From This Episode:

+ +

A warm welcome to today’s guest, Chris Fellows, founder and CEO of Bold Street.
+Founding Bold Street: their initial AI strategy and how it has shifted.
+How their software helps agents and brokers be more efficient.
+Key takeaways from bringing their first product to market.
+Reflections on what could have helped the development process go more quickly.
+Chris and his team’s approach to sales and their general pricing model.
+A breakdown of their ideal customer and how they are reaching them.
+What they’ve done to address their ideal customers’ biggest objections.
+Unpacking current market dynamics, from expensive leads to class action lawsuits.
+How Bold Street brings value to the current real estate market.
+The benefits and challenges of running a business in such a disrupted market.
+Reflections on their current fundraising efforts versus their previous round.
+Lessons on scaling a startup both locally and through internet marketing.

+ +

Links Mentioned in Today’s Episode:

+ +

Chris Fellows on LinkedIn

+[Chris Fellows' email](chris@boldstreet.ai)
+Bold Street
+Chad Pytel on LinkedIn
+Chad Pytel on X
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Da9hR7Wr + + ]]> + + Will Larry + Chad Pytel + + + 548: Product Management vs Project Management with Bethan Ashley + https://podcast.thoughtbot.com/548 + e11a1997-5eb5-464f-a979-f051c2b1c948 + Fri, 01 Nov 2024 14:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + In this episode, we're joined by Senior Product Manager at thoughtbot and Founderland Startup Mentor, Bethan Ashley, who shares her insights and advice on how and when to leverage AI tooling, the difference between project management and product management, and much more. + 34:35 + no + + What if, instead of asking how to integrate AI into your product, the question was, should you? During this episode, Jared Turner and Sami Birnbaum interview Senior Product Manager at thoughtbot and Founderland Startup Mentor, Bethan Ashley, who shares her insights and advice on how and when to leverage AI tooling. Sharing her career journey leading up to this point, Bethan makes the key distinction between project management and product management, and why this is essential to understand. Next, you’ll hear about her views on the importance of talking to customers about your products and the different ways to reach them effectively. We get into some of the classic reasons that products fail, the appropriate time to bring in a product manager, and a few of the techniques, prompts, and exercises that Bethan favors when mentoring others. Join us as we unpack how to avoid common pitfalls, discuss practical steps to overcome the fear of failure, and share advice for those seeking to put AI tooling into their product. Thanks for tuning in. +Key Points From This Episode: +From building bespoke apps for companies to product management, mentorship, and more: Bethan Ashley’s career journey. +Distinguishing between project management and product management. +Why talking to your customers is fundamental to successful products. +Some of the many different ways to reach customers. +Classic reasons that products fail. +How to identify the point at which a product manager has become a necessity. +Bethan’s path to mentorship through Founderland. +The Speedy Eights exercise that she uses to prompt ideas. +Advice to avoid common pitfalls: just get started. +Exploring the obstacle created by the fear of failure. +Strategies from the book The Mom Test. +Insights on AI in the day-to-day product management space. +Advice for those seeking to put AI tooling into their product. +Spicy takes on product management. +Links Mentioned in Today’s Episode: +Bethan Ashley on LinkedIn (https://www.linkedin.com/in/bethanashley/) +Founderland (https://www.founderland.org/) +Customer Discovery Playbook (https://thoughtbot.com/playbook/customer-discovery/preparation-and-setup) +The Mom Test (https://www.amazon.com/Mom-Test-customers-business-everyone/dp/1492180742) +Gamma (https://gamma.app/)
 +Gemini (https://gemini.google.com/) +Loom (https://www.loom.com/) +Figma (https://www.figma.com/) +Motion (https://www.usemotion.com/) +WIP is waste (https://thoughtbot.com/blog/wip-is-waste#) +Jared Turner on X (https://x.com/jaredlt) +Jared Turner on LinkedIn (https://www.linkedin.com/in/jaredlt/) +Will Larry on X (https://x.com/will23larry) +Will Larry on LinkedIn (https://www.linkedin.com/in/william-larry/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + What if, instead of asking how to integrate AI into your product, the question was, should you? During this episode, Jared Turner and Sami Birnbaum interview Senior Product Manager at thoughtbot and Founderland Startup Mentor, Bethan Ashley, who shares her insights and advice on how and when to leverage AI tooling. Sharing her career journey leading up to this point, Bethan makes the key distinction between project management and product management, and why this is essential to understand. Next, you’ll hear about her views on the importance of talking to customers about your products and the different ways to reach them effectively. We get into some of the classic reasons that products fail, the appropriate time to bring in a product manager, and a few of the techniques, prompts, and exercises that Bethan favors when mentoring others. Join us as we unpack how to avoid common pitfalls, discuss practical steps to overcome the fear of failure, and share advice for those seeking to put AI tooling into their product. Thanks for tuning in.

+ +

Key Points From This Episode:

+ +

From building bespoke apps for companies to product management, mentorship, and more: Bethan Ashley’s career journey.
+Distinguishing between project management and product management.
+Why talking to your customers is fundamental to successful products.
+Some of the many different ways to reach customers.
+Classic reasons that products fail.
+How to identify the point at which a product manager has become a necessity.
+Bethan’s path to mentorship through Founderland.
+The Speedy Eights exercise that she uses to prompt ideas.
+Advice to avoid common pitfalls: just get started.
+Exploring the obstacle created by the fear of failure.
+Strategies from the book The Mom Test.
+Insights on AI in the day-to-day product management space.
+Advice for those seeking to put AI tooling into their product.
+Spicy takes on product management.

+ +

Links Mentioned in Today’s Episode:

+ +

Bethan Ashley on LinkedIn
+Founderland
+Customer Discovery Playbook
+The Mom Test
+Gamma

+Gemini
+Loom
+Figma
+Motion
+WIP is waste
+Jared Turner on X
+Jared Turner on LinkedIn
+Will Larry on X
+Will Larry on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + What if, instead of asking how to integrate AI into your product, the question was, should you? During this episode, Jared Turner and Sami Birnbaum interview Senior Product Manager at thoughtbot and Founderland Startup Mentor, Bethan Ashley, who shares her insights and advice on how and when to leverage AI tooling. Sharing her career journey leading up to this point, Bethan makes the key distinction between project management and product management, and why this is essential to understand. Next, you’ll hear about her views on the importance of talking to customers about your products and the different ways to reach them effectively. We get into some of the classic reasons that products fail, the appropriate time to bring in a product manager, and a few of the techniques, prompts, and exercises that Bethan favors when mentoring others. Join us as we unpack how to avoid common pitfalls, discuss practical steps to overcome the fear of failure, and share advice for those seeking to put AI tooling into their product. Thanks for tuning in.

+ +

Key Points From This Episode:

+ +

From building bespoke apps for companies to product management, mentorship, and more: Bethan Ashley’s career journey.
+Distinguishing between project management and product management.
+Why talking to your customers is fundamental to successful products.
+Some of the many different ways to reach customers.
+Classic reasons that products fail.
+How to identify the point at which a product manager has become a necessity.
+Bethan’s path to mentorship through Founderland.
+The Speedy Eights exercise that she uses to prompt ideas.
+Advice to avoid common pitfalls: just get started.
+Exploring the obstacle created by the fear of failure.
+Strategies from the book The Mom Test.
+Insights on AI in the day-to-day product management space.
+Advice for those seeking to put AI tooling into their product.
+Spicy takes on product management.

+ +

Links Mentioned in Today’s Episode:

+ +

Bethan Ashley on LinkedIn
+Founderland
+Customer Discovery Playbook
+The Mom Test
+Gamma

+Gemini
+Loom
+Figma
+Motion
+WIP is waste
+Jared Turner on X
+Jared Turner on LinkedIn
+Will Larry on X
+Will Larry on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dgtN4FOK + + ]]> + + Sami Birnbaum + Chad Pytel + + + 547: Fight better using AI with CJ Tayeh + https://podcast.thoughtbot.com/547 + 99b1ef3a-2920-4e1c-92b5-8da45b5092aa + Thu, 24 Oct 2024 03:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + We’re joined by Flank founder, CJ Tayeh, a human rights lawyer turned growth marketer turned social innovator. With a mission to address inequalities and power imbalances, especially around money, she explains how Flank’s AI companion acts as a mediator to foster trust and communication. + 38:12 + no + + Could our inability to agree be holding us back from achieving meaningful social progress? What if AI could help us "fight better,” not by winning arguments but by resolving conflicts in ways that benefit our communities, businesses, and relationships? Flank’s innovative technology offers just that: a smarter, more empathetic approach to conflict resolution that could transform how we engage with one another. Today, we’re joined by Flank founder, CJ Tayeh, a human rights lawyer turned growth marketer turned social innovator. With a mission to address inequalities and power imbalances, especially around money, she explains how Flank’s AI companion acts as a mediator to foster trust and communication. We explore the different user experiences Flank serves, the careful research and development that went into its creation, and how joining Flank’s community can revolutionize conflict resolution. CJ also shares the challenges the startup faces, the role of interaction design in addressing them, and why high-quality data is crucial for effective AI-driven solutions. Don’t miss this fascinating conversation with serial innovator, CJ Tayeh! +Key Points From This Episode: +An overview of CJ’s journey into the emerging AI startup space. +How growing up in a high-conflict family has informed her work as a social innovator. +The problem Flank is focused on and how it aims to solve that problem with AI. +Perspectives on conflict resolution and the impact of joining Flank’s community. +How Flank’s AI companion acts as a mediator to foster communication and trust. +Different kinds of user experiences that Flank aims to cater to. +The amount of time, effort, and care that went into research and development. +Challenges that Flank faces and how interaction design can address them. +Why machine learning models are only as good as the data you train them with. +Links Mentioned in Today’s Episode: +Flank (https://flankdigital.org/) +CJ Tayeh on LinkedIn (https://www.linkedin.com/in/cj-tayeh/) +CJ Tayeh on X (https://x.com/oheycj) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://x.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + Could our inability to agree be holding us back from achieving meaningful social progress? What if AI could help us "fight better,” not by winning arguments but by resolving conflicts in ways that benefit our communities, businesses, and relationships? Flank’s innovative technology offers just that: a smarter, more empathetic approach to conflict resolution that could transform how we engage with one another. Today, we’re joined by Flank founder, CJ Tayeh, a human rights lawyer turned growth marketer turned social innovator. With a mission to address inequalities and power imbalances, especially around money, she explains how Flank’s AI companion acts as a mediator to foster trust and communication. We explore the different user experiences Flank serves, the careful research and development that went into its creation, and how joining Flank’s community can revolutionize conflict resolution. CJ also shares the challenges the startup faces, the role of interaction design in addressing them, and why high-quality data is crucial for effective AI-driven solutions. Don’t miss this fascinating conversation with serial innovator, CJ Tayeh!

+ +

Key Points From This Episode:
+An overview of CJ’s journey into the emerging AI startup space.
+How growing up in a high-conflict family has informed her work as a social innovator.
+The problem Flank is focused on and how it aims to solve that problem with AI.
+Perspectives on conflict resolution and the impact of joining Flank’s community.
+How Flank’s AI companion acts as a mediator to foster communication and trust.
+Different kinds of user experiences that Flank aims to cater to.
+The amount of time, effort, and care that went into research and development.
+Challenges that Flank faces and how interaction design can address them.
+Why machine learning models are only as good as the data you train them with.

+ +

Links Mentioned in Today’s Episode:
+Flank
+CJ Tayeh on LinkedIn
+CJ Tayeh on X
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Could our inability to agree be holding us back from achieving meaningful social progress? What if AI could help us "fight better,” not by winning arguments but by resolving conflicts in ways that benefit our communities, businesses, and relationships? Flank’s innovative technology offers just that: a smarter, more empathetic approach to conflict resolution that could transform how we engage with one another. Today, we’re joined by Flank founder, CJ Tayeh, a human rights lawyer turned growth marketer turned social innovator. With a mission to address inequalities and power imbalances, especially around money, she explains how Flank’s AI companion acts as a mediator to foster trust and communication. We explore the different user experiences Flank serves, the careful research and development that went into its creation, and how joining Flank’s community can revolutionize conflict resolution. CJ also shares the challenges the startup faces, the role of interaction design in addressing them, and why high-quality data is crucial for effective AI-driven solutions. Don’t miss this fascinating conversation with serial innovator, CJ Tayeh!

+ +

Key Points From This Episode:
+An overview of CJ’s journey into the emerging AI startup space.
+How growing up in a high-conflict family has informed her work as a social innovator.
+The problem Flank is focused on and how it aims to solve that problem with AI.
+Perspectives on conflict resolution and the impact of joining Flank’s community.
+How Flank’s AI companion acts as a mediator to foster communication and trust.
+Different kinds of user experiences that Flank aims to cater to.
+The amount of time, effort, and care that went into research and development.
+Challenges that Flank faces and how interaction design can address them.
+Why machine learning models are only as good as the data you train them with.

+ +

Links Mentioned in Today’s Episode:
+Flank
+CJ Tayeh on LinkedIn
+CJ Tayeh on X
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+6x4yHa8s + + ]]> + + Chad Pytel + + + 546: Class Awareness with Dr. Justin Key + https://podcast.thoughtbot.com/546 + aa2af571-f445-44c7-a438-a2017c7727a1 + Thu, 17 Oct 2024 03:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + In this special episode, we're joined by Dr. Justin Key, the Founder of Black Theorem Consulting, to discuss societal divisions driven by social and economic status, and how digital products and services can drive change on a global scale, how designers and developers can be a part of that change, and why developers need to check their biases when building digital technology. + 41:25 + no + + What happens when competition goes from being a driver of success to a source of division and exclusion? In today’s episode, Chad is joined by Dr. Justin Key, Founder of Black Theorem Consulting, to unpack societal divisions driven by social and economic status. Dr. Key is an accomplished consultant, speaker, and thought leader with expertise in helping organizations achieve growth and innovation through data-driven strategies. He is the founder of Black Theorem Consulting, a firm specializing in harnessing the power of diversity and technology to solve complex business challenges. In our conversation, we unpack today’s topic through the lens of the products and services developers bring to market. We discuss the hyper-competitive nature of society, the impacts of toxic competition, real-world examples of rigid and fluid drivers of division, and why we should not be afraid to discuss race. Explore how digital products and services can drive change on a global scale, how designers and developers can be a part of that change, and why developers need to check their biases when building digital technology. He shares his motivation for starting Black Theorem Consulting, what the company focuses on, and how it is helping drive change. He also shares how he stays motivated, the types of industries Black Theorem Consulting serves, and how you can contribute to a better world. Join us as we untangle systemic societal problems and how to reflect the world you serve in your product or service with Dr. Justin Key! +Key Points From This Episode: +Learn how social and economic status divides society and creates division. +Discover how the impacts of exclusion compound into larger societal problems. +Find out the difference between healthy and unhealthy competition. +Uncover the common misconceptions about power and wealth in society. +Hear how societal divisions have played a role in the decline of mental health. +Explore how the societal structure of America compares to other countries. +Find out why race cannot be ignored when discussing social divisions. +Understand the significance of considering race in discussions about social division. +Positive ways digital products and services can bridge the gap and drive change. +Ways technology creates obstacles between different socio-economic groups. +Steps developers can take to ensure that technology is inclusive and accessible. +Background about Black Theorem Consulting and the services it provides. +How inclusion and equity apply to developers and the development process. +Final takeaways and how to find out more about Black Theorem and Dr. Key. +Links Mentioned in Today’s Episode: +Dr. Justin Key (https://www.justindkey.com/) +Dr. Justin Key on LinkedIn (https://www.linkedin.com/in/justindkey/) +Dr. Justin Key on YouTube (https://www.youtube.com/@JustinKey) +Black Theorem Consulting (https://www.blacktheorem.com/) +Gracie's Corner (www.youtube.com/@graciescorner) +Chad Pytel on LinkedIn (https://www.linkedin.com/in/cpytel/) +Chad Pytel on Mastodon (https://thoughtbot.social/@cpytel) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://x.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + What happens when competition goes from being a driver of success to a source of division and exclusion? In today’s episode, Chad is joined by Dr. Justin Key, Founder of Black Theorem Consulting, to unpack societal divisions driven by social and economic status. Dr. Key is an accomplished consultant, speaker, and thought leader with expertise in helping organizations achieve growth and innovation through data-driven strategies. He is the founder of Black Theorem Consulting, a firm specializing in harnessing the power of diversity and technology to solve complex business challenges. In our conversation, we unpack today’s topic through the lens of the products and services developers bring to market. We discuss the hyper-competitive nature of society, the impacts of toxic competition, real-world examples of rigid and fluid drivers of division, and why we should not be afraid to discuss race. Explore how digital products and services can drive change on a global scale, how designers and developers can be a part of that change, and why developers need to check their biases when building digital technology. He shares his motivation for starting Black Theorem Consulting, what the company focuses on, and how it is helping drive change. He also shares how he stays motivated, the types of industries Black Theorem Consulting serves, and how you can contribute to a better world. Join us as we untangle systemic societal problems and how to reflect the world you serve in your product or service with Dr. Justin Key!

+ +

Key Points From This Episode:
+Learn how social and economic status divides society and creates division.
+Discover how the impacts of exclusion compound into larger societal problems.
+Find out the difference between healthy and unhealthy competition.
+Uncover the common misconceptions about power and wealth in society.
+Hear how societal divisions have played a role in the decline of mental health.
+Explore how the societal structure of America compares to other countries.
+Find out why race cannot be ignored when discussing social divisions.
+Understand the significance of considering race in discussions about social division.
+Positive ways digital products and services can bridge the gap and drive change.
+Ways technology creates obstacles between different socio-economic groups.
+Steps developers can take to ensure that technology is inclusive and accessible.
+Background about Black Theorem Consulting and the services it provides.
+How inclusion and equity apply to developers and the development process.
+Final takeaways and how to find out more about Black Theorem and Dr. Key.

+ +

Links Mentioned in Today’s Episode:
+Dr. Justin Key
+Dr. Justin Key on LinkedIn
+Dr. Justin Key on YouTube
+Black Theorem Consulting
+[Gracie's Corner](www.youtube.com/@graciescorner)
+Chad Pytel on LinkedIn
+Chad Pytel on Mastodon
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + What happens when competition goes from being a driver of success to a source of division and exclusion? In today’s episode, Chad is joined by Dr. Justin Key, Founder of Black Theorem Consulting, to unpack societal divisions driven by social and economic status. Dr. Key is an accomplished consultant, speaker, and thought leader with expertise in helping organizations achieve growth and innovation through data-driven strategies. He is the founder of Black Theorem Consulting, a firm specializing in harnessing the power of diversity and technology to solve complex business challenges. In our conversation, we unpack today’s topic through the lens of the products and services developers bring to market. We discuss the hyper-competitive nature of society, the impacts of toxic competition, real-world examples of rigid and fluid drivers of division, and why we should not be afraid to discuss race. Explore how digital products and services can drive change on a global scale, how designers and developers can be a part of that change, and why developers need to check their biases when building digital technology. He shares his motivation for starting Black Theorem Consulting, what the company focuses on, and how it is helping drive change. He also shares how he stays motivated, the types of industries Black Theorem Consulting serves, and how you can contribute to a better world. Join us as we untangle systemic societal problems and how to reflect the world you serve in your product or service with Dr. Justin Key!

+ +

Key Points From This Episode:
+Learn how social and economic status divides society and creates division.
+Discover how the impacts of exclusion compound into larger societal problems.
+Find out the difference between healthy and unhealthy competition.
+Uncover the common misconceptions about power and wealth in society.
+Hear how societal divisions have played a role in the decline of mental health.
+Explore how the societal structure of America compares to other countries.
+Find out why race cannot be ignored when discussing social divisions.
+Understand the significance of considering race in discussions about social division.
+Positive ways digital products and services can bridge the gap and drive change.
+Ways technology creates obstacles between different socio-economic groups.
+Steps developers can take to ensure that technology is inclusive and accessible.
+Background about Black Theorem Consulting and the services it provides.
+How inclusion and equity apply to developers and the development process.
+Final takeaways and how to find out more about Black Theorem and Dr. Key.

+ +

Links Mentioned in Today’s Episode:
+Dr. Justin Key
+Dr. Justin Key on LinkedIn
+Dr. Justin Key on YouTube
+Black Theorem Consulting
+[Gracie's Corner](www.youtube.com/@graciescorner)
+Chad Pytel on LinkedIn
+Chad Pytel on Mastodon
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+I0cePedR + + ]]> + + Chad Pytel + + + 545: Generative AI: How to Leverage its Power and Mitigate the Risks + https://podcast.thoughtbot.com/545 + a2fe07ef-d46f-4a38-8a5e-664bb72139c5 + Thu, 10 Oct 2024 03:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + We're joined by Sema Founder and CEO, Matt Van Itallie. Sema improves outcomes for users, companies, and developers by providing automated tools to assess code. We discuss the five reasons why you should know how much generative AI is used in your code, and much more. + 46:18 + no + + Since its inception in 2017, Sema has been improving outcomes for users, companies, and developers by providing automated tools to assess code. During this episode, we are joined by Sema Founder and CEO, Matt Van Itallie. Matt discusses five reasons why you should know how much generative AI is used in your code, from the capacity to increase the quantity, quality, and maintainability to intellectual property risk. These also include exit risks. Next, we explore how this is detected, how it can be solved, and the advantages of looking at code. Next, we explore the origins of Sema and how Matt sourced his co-founders, consider his thoughts on open source, and why it matters to know how much generative AI is used in your code. Hear advice on where to begin, how much to prioritize precision, and why it is imperative to make generative AI your own. Tune in today to hear all this and more. +Key Points From This Episode: +Introducing Sema CEO and Founder Matt Van Itallie. +How the work is distributed among different target customers: companies, financial and strategic buyers. +Why Sema is language agnostic and what it does instead. +Matt’s belief that the fundamental health of a software product depends on the team. +Understanding key person risk and the concept of golden handcuffs. +How Matt’s background set him up to easily understand the world of coding. +Why the combination of manual implementation and automation via Sema is most effective. +The process behind turning the idea into a product with the University of Michigan and a Founder from AngelList. +Why he does not recommend using his approach. +The single biggest focus: code inspection and due diligence. +Using open source code and the risks involved. +Five sets of reasons why it matters to know how much generative AI is used in your code. +How this is detected and how it can be solved. +Advice on where to begin, how precise to be, and more. +Leveraging the expertise of Co-Founder Brendan Cody-Kenny to build Sema. +Why it is imperative to make generative AI your own. +Free advisory AI counsels that Matt and Sema have set up. 
 +Links Mentioned in Today’s Episode: +Matt Van Itallie on LinkedIn (https://www.linkedin.com/in/mvi/) +Matt Van Itallie on X (https://x.com/vanitallie_matt) +Matt Van Itallie Email (mvi@sema.com) +Sema (https://semasoftware.com/ai-code-monitor) +University of Michigan (https://umich.edu/) +AngelList (https://www.angellist.com/) +CoPilot (https://copilot.microsoft.com/) +Chad Pytel on LinkedIn (https://www.linkedin.com/in/cpytel/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + Since its inception in 2017, Sema has been improving outcomes for users, companies, and developers by providing automated tools to assess code. During this episode, we are joined by Sema Founder and CEO, Matt Van Itallie. Matt discusses five reasons why you should know how much generative AI is used in your code, from the capacity to increase the quantity, quality, and maintainability to intellectual property risk. These also include exit risks. Next, we explore how this is detected, how it can be solved, and the advantages of looking at code. Next, we explore the origins of Sema and how Matt sourced his co-founders, consider his thoughts on open source, and why it matters to know how much generative AI is used in your code. Hear advice on where to begin, how much to prioritize precision, and why it is imperative to make generative AI your own. Tune in today to hear all this and more.

+ +

Key Points From This Episode:

+ +

Introducing Sema CEO and Founder Matt Van Itallie.
+How the work is distributed among different target customers: companies, financial and strategic buyers.
+Why Sema is language agnostic and what it does instead.
+Matt’s belief that the fundamental health of a software product depends on the team.
+Understanding key person risk and the concept of golden handcuffs.
+How Matt’s background set him up to easily understand the world of coding.
+Why the combination of manual implementation and automation via Sema is most effective.
+The process behind turning the idea into a product with the University of Michigan and a Founder from AngelList.
+Why he does not recommend using his approach.
+The single biggest focus: code inspection and due diligence.
+Using open source code and the risks involved.
+Five sets of reasons why it matters to know how much generative AI is used in your code.
+How this is detected and how it can be solved.
+Advice on where to begin, how precise to be, and more.
+Leveraging the expertise of Co-Founder Brendan Cody-Kenny to build Sema.
+Why it is imperative to make generative AI your own.
+Free advisory AI counsels that Matt and Sema have set up. 


+ +

Links Mentioned in Today’s Episode:

+ +

Matt Van Itallie on LinkedIn
+Matt Van Itallie on X
+[Matt Van Itallie Email](mvi@sema.com)
+Sema
+University of Michigan
+AngelList
+CoPilot
+Chad Pytel on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Since its inception in 2017, Sema has been improving outcomes for users, companies, and developers by providing automated tools to assess code. During this episode, we are joined by Sema Founder and CEO, Matt Van Itallie. Matt discusses five reasons why you should know how much generative AI is used in your code, from the capacity to increase the quantity, quality, and maintainability to intellectual property risk. These also include exit risks. Next, we explore how this is detected, how it can be solved, and the advantages of looking at code. Next, we explore the origins of Sema and how Matt sourced his co-founders, consider his thoughts on open source, and why it matters to know how much generative AI is used in your code. Hear advice on where to begin, how much to prioritize precision, and why it is imperative to make generative AI your own. Tune in today to hear all this and more.

+ +

Key Points From This Episode:

+ +

Introducing Sema CEO and Founder Matt Van Itallie.
+How the work is distributed among different target customers: companies, financial and strategic buyers.
+Why Sema is language agnostic and what it does instead.
+Matt’s belief that the fundamental health of a software product depends on the team.
+Understanding key person risk and the concept of golden handcuffs.
+How Matt’s background set him up to easily understand the world of coding.
+Why the combination of manual implementation and automation via Sema is most effective.
+The process behind turning the idea into a product with the University of Michigan and a Founder from AngelList.
+Why he does not recommend using his approach.
+The single biggest focus: code inspection and due diligence.
+Using open source code and the risks involved.
+Five sets of reasons why it matters to know how much generative AI is used in your code.
+How this is detected and how it can be solved.
+Advice on where to begin, how precise to be, and more.
+Leveraging the expertise of Co-Founder Brendan Cody-Kenny to build Sema.
+Why it is imperative to make generative AI your own.
+Free advisory AI counsels that Matt and Sema have set up. 


+ +

Links Mentioned in Today’s Episode:

+ +

Matt Van Itallie on LinkedIn
+Matt Van Itallie on X
+[Matt Van Itallie Email](mvi@sema.com)
+Sema
+University of Michigan
+AngelList
+CoPilot
+Chad Pytel on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bQVAd9BA + + ]]> + + Chad Pytel + + + 544: How BonePixel is Redefining Diagnosis and Treatment with Nazgol Tavabi and Mohammadreza Movahhedi + https://podcast.thoughtbot.com/544 + 4b724965-75f7-4639-8290-047f646c303f + Thu, 03 Oct 2024 03:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + We're joined by Nazgol Tavabi and Mohammadreza Movahhedi, the co-founders of BonePixel, a healthcare startup focused on using AI and big data for the diagnosis and treatment planning of joint disorders. We discuss the origins of BonePixel, the challenges of building a healthcare startup, and how they are leveraging AI to make patient-specific treatment planning more accurate and efficient. + 39:36 + no + + What if diagnosing complex joint disorders could be as precise and personalized as a fingerprint? Today, Will sits down with Nazgol Tavabi and Mohammadreza Movahhedi to discuss their journey of transforming cutting-edge research into a revolutionary AI-powered platform for diagnosing joint disorders. +Nazgol and Mohammadreza are the co-founders of BonePixel, a healthcare startup focused on using AI and big data for the diagnosis and treatment planning of joint disorders. In our conversation, we unpack the origins of BonePixel, the challenges of building a healthcare startup, and how they are leveraging AI to make patient-specific treatment planning more accurate and efficient. Explore how its data-driven process facilitates decision-making for surgeons, how they were able to commercialize the software, and the positive impact it is making on patients’ lives. +They share details about BonePixel’s current state of development, the regulatory hurdles, and their surgeon-centric approach to software development. We discuss the complexities of securing funding and their approach to fostering a healthy company culture. Gain insights into how they make their software inclusive, the ethical aspects of BonePixels development, why human involvement is crucial, and more. Join us to learn how BonePixel is transforming orthopedic care and pushing the boundaries of what’s possible with AI with Nazgol Tavabi and Mohammadreza Movahhedi! +Key Points From This Episode: +Background about the development of BonePixel’s innovative software. +Learn about BonePixel and how it leverages data to improve decision-making. +Hear about BonePixel’s research origins at Harvard Medical School. +How Harvard Medical School is facilitating the commercialization of BonePixel. +Uncover the role that machine learning and AI play in BonePixel’s software. +Find out how their collaborators have acted as data sources for their models. +They share details about upcoming features and software additions. +Discover the core values of BonePixel that are driving its development. +What got them interested in applying their research skills in healthcare. +Explore the ethical considerations that need to be taken into account. +Why human involvement during BonePixels implementation is vital. +Hear their opinion on regulating the development of AI-based technologies. +Lessons from their careers, final takeaways, and how to get in contact with them. +Links Mentioned in Today’s Episode: +BonePixel (https://www.bonepixel.com/) +Nazgol Tavabi on LinkedIn (https://www.linkedin.com/in/nazgoltavabi/) +Mohammadreza Movahhedi on LinkedIn (https://www.linkedin.com/in/mohammadreza-movahhedi-phd-5aa652145/) +Harvard Medical School (https://hms.harvard.edu/) +Boston Children's Hospital (https://www.childrenshospital.org/) +VirtualHip (https://virtualhip.childrenshospital.org/) +Will Larry on X (https://x.com/will23larry) +Will Larry on LinkedIn (https://www.linkedin.com/in/william-larry/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (mailto:hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + What if diagnosing complex joint disorders could be as precise and personalized as a fingerprint? Today, Will sits down with Nazgol Tavabi and Mohammadreza Movahhedi to discuss their journey of transforming cutting-edge research into a revolutionary AI-powered platform for diagnosing joint disorders.

+ +

Nazgol and Mohammadreza are the co-founders of BonePixel, a healthcare startup focused on using AI and big data for the diagnosis and treatment planning of joint disorders. In our conversation, we unpack the origins of BonePixel, the challenges of building a healthcare startup, and how they are leveraging AI to make patient-specific treatment planning more accurate and efficient. Explore how its data-driven process facilitates decision-making for surgeons, how they were able to commercialize the software, and the positive impact it is making on patients’ lives.

+ +

They share details about BonePixel’s current state of development, the regulatory hurdles, and their surgeon-centric approach to software development. We discuss the complexities of securing funding and their approach to fostering a healthy company culture. Gain insights into how they make their software inclusive, the ethical aspects of BonePixels development, why human involvement is crucial, and more. Join us to learn how BonePixel is transforming orthopedic care and pushing the boundaries of what’s possible with AI with Nazgol Tavabi and Mohammadreza Movahhedi!

+ +

Key Points From This Episode:

+ +

Background about the development of BonePixel’s innovative software.
+Learn about BonePixel and how it leverages data to improve decision-making.
+Hear about BonePixel’s research origins at Harvard Medical School.
+How Harvard Medical School is facilitating the commercialization of BonePixel.
+Uncover the role that machine learning and AI play in BonePixel’s software.
+Find out how their collaborators have acted as data sources for their models.
+They share details about upcoming features and software additions.
+Discover the core values of BonePixel that are driving its development.
+What got them interested in applying their research skills in healthcare.
+Explore the ethical considerations that need to be taken into account.
+Why human involvement during BonePixels implementation is vital.
+Hear their opinion on regulating the development of AI-based technologies.
+Lessons from their careers, final takeaways, and how to get in contact with them.

+ +

Links Mentioned in Today’s Episode:

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + What if diagnosing complex joint disorders could be as precise and personalized as a fingerprint? Today, Will sits down with Nazgol Tavabi and Mohammadreza Movahhedi to discuss their journey of transforming cutting-edge research into a revolutionary AI-powered platform for diagnosing joint disorders.

+ +

Nazgol and Mohammadreza are the co-founders of BonePixel, a healthcare startup focused on using AI and big data for the diagnosis and treatment planning of joint disorders. In our conversation, we unpack the origins of BonePixel, the challenges of building a healthcare startup, and how they are leveraging AI to make patient-specific treatment planning more accurate and efficient. Explore how its data-driven process facilitates decision-making for surgeons, how they were able to commercialize the software, and the positive impact it is making on patients’ lives.

+ +

They share details about BonePixel’s current state of development, the regulatory hurdles, and their surgeon-centric approach to software development. We discuss the complexities of securing funding and their approach to fostering a healthy company culture. Gain insights into how they make their software inclusive, the ethical aspects of BonePixels development, why human involvement is crucial, and more. Join us to learn how BonePixel is transforming orthopedic care and pushing the boundaries of what’s possible with AI with Nazgol Tavabi and Mohammadreza Movahhedi!

+ +

Key Points From This Episode:

+ +

Background about the development of BonePixel’s innovative software.
+Learn about BonePixel and how it leverages data to improve decision-making.
+Hear about BonePixel’s research origins at Harvard Medical School.
+How Harvard Medical School is facilitating the commercialization of BonePixel.
+Uncover the role that machine learning and AI play in BonePixel’s software.
+Find out how their collaborators have acted as data sources for their models.
+They share details about upcoming features and software additions.
+Discover the core values of BonePixel that are driving its development.
+What got them interested in applying their research skills in healthcare.
+Explore the ethical considerations that need to be taken into account.
+Why human involvement during BonePixels implementation is vital.
+Hear their opinion on regulating the development of AI-based technologies.
+Lessons from their careers, final takeaways, and how to get in contact with them.

+ +

Links Mentioned in Today’s Episode:

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tQ9ltaDj + + ]]> + + Will Larry + Chad Pytel + + + 543: The Intersection of AI and Recruitment with Brian Glover + https://podcast.thoughtbot.com/543 + e16c492e-d601-4ad6-adc1-548baa3b255e + Thu, 19 Sep 2024 03:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + We're joined by Brian Glover, Co-founder and CEO of Previewed, an immersive, streamlined, and intelligent solution for recruiters and candidates. We unpack the company’s skill-based assessment method, the ‘gamification’ of recruitment tools, how Previewed’s platform helps with retention, identifying gaps in a candidate’s skills, and much more. + 42:12 + no + + Is it time to rethink how we approach hiring? The traditional recruitment process often fails to capture the true potential of candidates, relying heavily on outdated methods like résumés and generic job descriptions. In this episode, Will sits down with Brian Glover, Co-founder and CEO of Previewed, to unpack the revolutionary interplay between technology and the recruitment sector. Previewed aims to revolutionize how job seekers connect with potential employers by allowing them to showcase their skills and experiences in a more personalized and impactful way. It leverages cutting-edge technology to create a platform that helps candidates stand out in a competitive job market, ensuring that everyone has a fair shot at landing their dream job. In our conversation, we discuss how the Previewed platform creates an immersive, streamlined, and intelligent solution for recruiters and candidates. Learn about the innovative technology behind Previewed’s platform and how it is revolutionizing the traditional recruitment landscape. Discover the inspiration behind Previewed, its approach to career life-cycle, and how it empowers the candidate. We unpack the company’s skill-based assessment method, the ‘gamification’ of recruitment tools, how Previewed’s platform helps with retention, identifying gaps in a candidate’s skills, and much more. Join us as we explore where AI meets talent acquisition and how it turns purpose into a career with Brian Glover. Tune in now! +Key Points From This Episode: +How he uses prayer and meditation to keep him grounded as an entrepreneur. +Overcoming the mental hurdles of being a founder and business owner. +Previewed’s platform and how it leverages AI to enhance the recruitment process. +Issues in the traditional job search and hiring process that Previewed solves. +Discover why aligning a candidate’s job description with their purpose is so vital. +Reasons for Previewed’s skill-based method and how it assesses candidates. +The benefits of Previewed’s skill-based approach for candidates and recruiters. +Brian shares how his hustler background growing up led him to become an entrepreneur. +Hear about Previewed’s roots and the many challenges he overcame starting it. +Recommendations for budding entrepreneurs and what Brian is currently focusing on. +Links Mentioned in Today’s Episode: +Brian Glover on LinkedIn (https://www.linkedin.com/in/brian-glover-startupfounder/) +Previewed (https://www.previewed.careers) +Will Larry on X (https://x.com/will23larry) +Will Larry on LinkedIn (https://www.linkedin.com/in/william-larry/) +Victoria Guido on X (https://x.com/victori_ousg) +Victoria Guido on LinkedIn (https://www.linkedin.com/in/victorialguido/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + Is it time to rethink how we approach hiring? The traditional recruitment process often fails to capture the true potential of candidates, relying heavily on outdated methods like résumés and generic job descriptions. In this episode, Will sits down with Brian Glover, Co-founder and CEO of Previewed, to unpack the revolutionary interplay between technology and the recruitment sector. Previewed aims to revolutionize how job seekers connect with potential employers by allowing them to showcase their skills and experiences in a more personalized and impactful way. It leverages cutting-edge technology to create a platform that helps candidates stand out in a competitive job market, ensuring that everyone has a fair shot at landing their dream job. In our conversation, we discuss how the Previewed platform creates an immersive, streamlined, and intelligent solution for recruiters and candidates. Learn about the innovative technology behind Previewed’s platform and how it is revolutionizing the traditional recruitment landscape. Discover the inspiration behind Previewed, its approach to career life-cycle, and how it empowers the candidate. We unpack the company’s skill-based assessment method, the ‘gamification’ of recruitment tools, how Previewed’s platform helps with retention, identifying gaps in a candidate’s skills, and much more. Join us as we explore where AI meets talent acquisition and how it turns purpose into a career with Brian Glover. Tune in now!

+ +

Key Points From This Episode:

+ +

How he uses prayer and meditation to keep him grounded as an entrepreneur.
+Overcoming the mental hurdles of being a founder and business owner.
+Previewed’s platform and how it leverages AI to enhance the recruitment process.
+Issues in the traditional job search and hiring process that Previewed solves.
+Discover why aligning a candidate’s job description with their purpose is so vital.
+Reasons for Previewed’s skill-based method and how it assesses candidates.
+The benefits of Previewed’s skill-based approach for candidates and recruiters.
+Brian shares how his hustler background growing up led him to become an entrepreneur.
+Hear about Previewed’s roots and the many challenges he overcame starting it.
+Recommendations for budding entrepreneurs and what Brian is currently focusing on.

+ +

Links Mentioned in Today’s Episode:

+ +

Brian Glover on LinkedIn
+Previewed
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Is it time to rethink how we approach hiring? The traditional recruitment process often fails to capture the true potential of candidates, relying heavily on outdated methods like résumés and generic job descriptions. In this episode, Will sits down with Brian Glover, Co-founder and CEO of Previewed, to unpack the revolutionary interplay between technology and the recruitment sector. Previewed aims to revolutionize how job seekers connect with potential employers by allowing them to showcase their skills and experiences in a more personalized and impactful way. It leverages cutting-edge technology to create a platform that helps candidates stand out in a competitive job market, ensuring that everyone has a fair shot at landing their dream job. In our conversation, we discuss how the Previewed platform creates an immersive, streamlined, and intelligent solution for recruiters and candidates. Learn about the innovative technology behind Previewed’s platform and how it is revolutionizing the traditional recruitment landscape. Discover the inspiration behind Previewed, its approach to career life-cycle, and how it empowers the candidate. We unpack the company’s skill-based assessment method, the ‘gamification’ of recruitment tools, how Previewed’s platform helps with retention, identifying gaps in a candidate’s skills, and much more. Join us as we explore where AI meets talent acquisition and how it turns purpose into a career with Brian Glover. Tune in now!

+ +

Key Points From This Episode:

+ +

How he uses prayer and meditation to keep him grounded as an entrepreneur.
+Overcoming the mental hurdles of being a founder and business owner.
+Previewed’s platform and how it leverages AI to enhance the recruitment process.
+Issues in the traditional job search and hiring process that Previewed solves.
+Discover why aligning a candidate’s job description with their purpose is so vital.
+Reasons for Previewed’s skill-based method and how it assesses candidates.
+The benefits of Previewed’s skill-based approach for candidates and recruiters.
+Brian shares how his hustler background growing up led him to become an entrepreneur.
+Hear about Previewed’s roots and the many challenges he overcame starting it.
+Recommendations for budding entrepreneurs and what Brian is currently focusing on.

+ +

Links Mentioned in Today’s Episode:

+ +

Brian Glover on LinkedIn
+Previewed
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JQJonepg + + ]]> + + Will Larry + Chad Pytel + + + 542: Shaping Company Culture using AI with Elie Rashbass + https://podcast.thoughtbot.com/542 + 80627e62-8205-4004-b871-57c20a2cb166 + Thu, 12 Sep 2024 03:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Elie Rashbass, CEO & Co-founder at ScultureAI, a startup developing innovative solutions that shape organizational culture from the ground up joins the show to discuss the endless interactions that shape company culture, why it matters, and how Elie and his team are helping companies use AI to embed their culture into actualized, organization-wide behavior. + 41:16 + no + + Company culture plays a fundamental role in the success of your organization. Unfortunately, it’s not always clear what methods will lead to optimal outcomes. Top research shows an alarming gap between a company’s stated culture and what employees report about their experience working there. But what if one could harness the power of AI to close this gap? Today on the show, we’re joined by Elie Rashbass, CEO & Co-founder at ScultureAI, a startup developing innovative solutions that shape organizational culture from the ground up. He tells us about the groundbreaking work being done by ScultureAI and how they are leveraging AI to coach everyday interactions between internal staff members and external stakeholders. We discuss the endless interactions that shape company culture, why it matters, and how Elie and his team are helping companies use AI to embed their culture into actualized, organization-wide behavior. To learn more about how AI is used to transform company culture, tune in today!
 +Key Points From This Episode: +How Elie’s corporate background instilled an appreciation for good company culture. +Co-founding ScultureAI with his father and what led them into the AI startup space. +His father’s experience fostering strong company cultures and his extensive AI research. +The significant gap between what companies say their culture is and what it actually is. +Why company culture matters, from employee well-being to organizational success. +What to consider when selecting and defining your company values. +Common challenges organizations face when implementing company culture. +How ScultureAI is helping companies embed company culture from the ground up. +Their groundbreaking AI-powered behavioral coach and examples of its workflow integration. +Key challenges they’ve encountered working with LLMs and how they’ve addressed these. +What you can expect from the ScultureAI demo and how to get in touch. +An overview of hiring as a potential use case for their behavioral AI coach. +How ScultureAI prioritizes and safeguards user data and privacy. +Overcoming challenges as innovators in the space and advice to other leaders. +Links Mentioned in Today’s Episode: +Elie Rashbass on LinkedIn (https://www.linkedin.com/in/elie-rashbass-cfa-b78631132/) +ScultureAI (https://sculture.ai/) +Donald Sull (https://mitsloan.mit.edu/faculty/directory/donald-sull) +Sami Birnbaum (https://samibirnbaum.com) +Sami Birnbaum on LinkedIn (https://www.linkedin.com/in/samibirnbaum/) +Svenja Schäfer (svenjaschaefer.com) +Svenja Schäfer on LinkedIn (https://www.linkedin.com/in/svenjaschaefer/) +Will Larry on X (https://x.com/will23larry) +Will Larry on LinkedIn (https://www.linkedin.com/in/william-larry/) +Victoria Guido on X (https://x.com/victori_ousg) +Victoria Guido on LinkedIn (https://www.linkedin.com/in/victorialguido/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + Company culture plays a fundamental role in the success of your organization. Unfortunately, it’s not always clear what methods will lead to optimal outcomes. Top research shows an alarming gap between a company’s stated culture and what employees report about their experience working there. But what if one could harness the power of AI to close this gap? Today on the show, we’re joined by Elie Rashbass, CEO & Co-founder at ScultureAI, a startup developing innovative solutions that shape organizational culture from the ground up. He tells us about the groundbreaking work being done by ScultureAI and how they are leveraging AI to coach everyday interactions between internal staff members and external stakeholders. We discuss the endless interactions that shape company culture, why it matters, and how Elie and his team are helping companies use AI to embed their culture into actualized, organization-wide behavior. To learn more about how AI is used to transform company culture, tune in today!


+ +

Key Points From This Episode:

+ +

How Elie’s corporate background instilled an appreciation for good company culture.
+Co-founding ScultureAI with his father and what led them into the AI startup space.
+His father’s experience fostering strong company cultures and his extensive AI research.
+The significant gap between what companies say their culture is and what it actually is.
+Why company culture matters, from employee well-being to organizational success.
+What to consider when selecting and defining your company values.
+Common challenges organizations face when implementing company culture.
+How ScultureAI is helping companies embed company culture from the ground up.
+Their groundbreaking AI-powered behavioral coach and examples of its workflow integration.
+Key challenges they’ve encountered working with LLMs and how they’ve addressed these.
+What you can expect from the ScultureAI demo and how to get in touch.
+An overview of hiring as a potential use case for their behavioral AI coach.
+How ScultureAI prioritizes and safeguards user data and privacy.
+Overcoming challenges as innovators in the space and advice to other leaders.

+ +

Links Mentioned in Today’s Episode:

+ +

Elie Rashbass on LinkedIn
+ScultureAI
+Donald Sull
+Sami Birnbaum
+Sami Birnbaum on LinkedIn
+[Svenja Schäfer](svenjaschaefer.com)
+Svenja Schäfer on LinkedIn
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Company culture plays a fundamental role in the success of your organization. Unfortunately, it’s not always clear what methods will lead to optimal outcomes. Top research shows an alarming gap between a company’s stated culture and what employees report about their experience working there. But what if one could harness the power of AI to close this gap? Today on the show, we’re joined by Elie Rashbass, CEO & Co-founder at ScultureAI, a startup developing innovative solutions that shape organizational culture from the ground up. He tells us about the groundbreaking work being done by ScultureAI and how they are leveraging AI to coach everyday interactions between internal staff members and external stakeholders. We discuss the endless interactions that shape company culture, why it matters, and how Elie and his team are helping companies use AI to embed their culture into actualized, organization-wide behavior. To learn more about how AI is used to transform company culture, tune in today!


+ +

Key Points From This Episode:

+ +

How Elie’s corporate background instilled an appreciation for good company culture.
+Co-founding ScultureAI with his father and what led them into the AI startup space.
+His father’s experience fostering strong company cultures and his extensive AI research.
+The significant gap between what companies say their culture is and what it actually is.
+Why company culture matters, from employee well-being to organizational success.
+What to consider when selecting and defining your company values.
+Common challenges organizations face when implementing company culture.
+How ScultureAI is helping companies embed company culture from the ground up.
+Their groundbreaking AI-powered behavioral coach and examples of its workflow integration.
+Key challenges they’ve encountered working with LLMs and how they’ve addressed these.
+What you can expect from the ScultureAI demo and how to get in touch.
+An overview of hiring as a potential use case for their behavioral AI coach.
+How ScultureAI prioritizes and safeguards user data and privacy.
+Overcoming challenges as innovators in the space and advice to other leaders.

+ +

Links Mentioned in Today’s Episode:

+ +

Elie Rashbass on LinkedIn
+ScultureAI
+Donald Sull
+Sami Birnbaum
+Sami Birnbaum on LinkedIn
+[Svenja Schäfer](svenjaschaefer.com)
+Svenja Schäfer on LinkedIn
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+sR0K6Req + + ]]> + + Will Larry + Chad Pytel + + + 541: Fixing the way that families hire, manage, and pay in-home care professionals with Jon Levinson + https://podcast.thoughtbot.com/541 + a095d53c-c291-44c5-91dc-677b0bf39721 + Thu, 05 Sep 2024 17:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + We're joined by Jon Levinson, founder of Clara Home Care, to share his personal experiences with in-home care that led him to research the industry, identify the challenges, and co-found Clara, which is reimagining the way that home care is delivered in America. + 42:48 + no + + By addressing the way that families hire, manage, and pay in-home care professionals, Clara Home Care is reimagining the way that home care is delivered in America, and Jon Levinson is at the helm. He joins us today to share his personal experiences with in-home care that led him to research the industry, identify the challenges, and co-found Clara. Hear how Jon was able to draw on his background in product management for TripAdvisor and Uber to pioneer his company, what it was like to develop early iterations of the product, and how all this resulted in creating the first-ever caregiver-specific payroll platform. We touch on finding the appropriate market, creating foundational code, and the importance of setting best practices to support scaling and changing. Jon also describes the critical role of thoughtbot in setting Clara Home Care up for scaling success. To finish, Jon shares some of the exciting opportunities that exist in the realm of care management, and how Clara is already taking advantage of them. Thanks for listening! +Key Points From This Episode: +Introducing Jon Levinson, Co-Founder and CEO at Clara Home Care. +The role of thoughtbot in bringing Clara to life. +A personal experience that led Jon to pioneer Clara Home Care. +Results of researching the specific problems faced in the broader industry. +His background in product management at TripAdvisor, Uber, and more. +The engineer who became his technical co-founder. +Fundraising choices and investment during his early journey. +Three consumer problems that care agencies do not adequately address. +Why using an agency is still beneficial in comparison to hiring independently. +Developing the first version of the product. +Identifying the opportunity to pioneer the first caregiver-specific payroll platform. +The challenge of finding people seeking a caregiving product. +Setting foundational code structured to scale and the role of Thoughtbot in this process. +Reaching a critical mass by building a strong grounding through relationships. +Balancing building the marketplace, solving discovery, and investing in caregiving technology. +Flexible metrics for success in a given marketplace. +Why caregivers still favor agencies over independent work. +Understanding how emotionally taxing the caregiver coordination role can be. +Features that support the relationship with long-term care insurance providers and care management. +Links Mentioned in Today’s Episode: +Jon Levinson on X (https://x.com/levinsonjon) +Jon Levinson on LinkedIn (https://www.linkedin.com/in/jonlevinson1/) +Jon Levinson Email (jon@clarahomecare.com) +Clara Home Care (https://www.clarahomecare.com/) +Clara Home Care on Facebook (https://www.facebook.com/HomeCareNearMe/) +Clara Home Care on LinkedIn (https://www.linkedin.com/company/clarahomecare/) +Thoughtbot (https://thoughtbot.com/) +Will Larry on X (https://x.com/will23larry) +Will Larry on LinkedIn (https://www.linkedin.com/in/william-larry/) +Victoria Guido on X (https://x.com/victori_ousg) +Victoria Guido on LinkedIn (https://www.linkedin.com/in/victorialguido/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + By addressing the way that families hire, manage, and pay in-home care professionals, Clara Home Care is reimagining the way that home care is delivered in America, and Jon Levinson is at the helm. He joins us today to share his personal experiences with in-home care that led him to research the industry, identify the challenges, and co-found Clara. Hear how Jon was able to draw on his background in product management for TripAdvisor and Uber to pioneer his company, what it was like to develop early iterations of the product, and how all this resulted in creating the first-ever caregiver-specific payroll platform. We touch on finding the appropriate market, creating foundational code, and the importance of setting best practices to support scaling and changing. Jon also describes the critical role of thoughtbot in setting Clara Home Care up for scaling success. To finish, Jon shares some of the exciting opportunities that exist in the realm of care management, and how Clara is already taking advantage of them. Thanks for listening!

+ +

Key Points From This Episode:

+ +

Introducing Jon Levinson, Co-Founder and CEO at Clara Home Care.
+The role of thoughtbot in bringing Clara to life.
+A personal experience that led Jon to pioneer Clara Home Care.
+Results of researching the specific problems faced in the broader industry.
+His background in product management at TripAdvisor, Uber, and more.
+The engineer who became his technical co-founder.
+Fundraising choices and investment during his early journey.
+Three consumer problems that care agencies do not adequately address.
+Why using an agency is still beneficial in comparison to hiring independently.
+Developing the first version of the product.
+Identifying the opportunity to pioneer the first caregiver-specific payroll platform.
+The challenge of finding people seeking a caregiving product.
+Setting foundational code structured to scale and the role of Thoughtbot in this process.
+Reaching a critical mass by building a strong grounding through relationships.
+Balancing building the marketplace, solving discovery, and investing in caregiving technology.
+Flexible metrics for success in a given marketplace.
+Why caregivers still favor agencies over independent work.
+Understanding how emotionally taxing the caregiver coordination role can be.
+Features that support the relationship with long-term care insurance providers and care management.

+ +

Links Mentioned in Today’s Episode:

+ +

Jon Levinson on X
+Jon Levinson on LinkedIn
+[Jon Levinson Email](jon@clarahomecare.com)
+Clara Home Care
+Clara Home Care on Facebook
+Clara Home Care on LinkedIn
+Thoughtbot
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + By addressing the way that families hire, manage, and pay in-home care professionals, Clara Home Care is reimagining the way that home care is delivered in America, and Jon Levinson is at the helm. He joins us today to share his personal experiences with in-home care that led him to research the industry, identify the challenges, and co-found Clara. Hear how Jon was able to draw on his background in product management for TripAdvisor and Uber to pioneer his company, what it was like to develop early iterations of the product, and how all this resulted in creating the first-ever caregiver-specific payroll platform. We touch on finding the appropriate market, creating foundational code, and the importance of setting best practices to support scaling and changing. Jon also describes the critical role of thoughtbot in setting Clara Home Care up for scaling success. To finish, Jon shares some of the exciting opportunities that exist in the realm of care management, and how Clara is already taking advantage of them. Thanks for listening!

+ +

Key Points From This Episode:

+ +

Introducing Jon Levinson, Co-Founder and CEO at Clara Home Care.
+The role of thoughtbot in bringing Clara to life.
+A personal experience that led Jon to pioneer Clara Home Care.
+Results of researching the specific problems faced in the broader industry.
+His background in product management at TripAdvisor, Uber, and more.
+The engineer who became his technical co-founder.
+Fundraising choices and investment during his early journey.
+Three consumer problems that care agencies do not adequately address.
+Why using an agency is still beneficial in comparison to hiring independently.
+Developing the first version of the product.
+Identifying the opportunity to pioneer the first caregiver-specific payroll platform.
+The challenge of finding people seeking a caregiving product.
+Setting foundational code structured to scale and the role of Thoughtbot in this process.
+Reaching a critical mass by building a strong grounding through relationships.
+Balancing building the marketplace, solving discovery, and investing in caregiving technology.
+Flexible metrics for success in a given marketplace.
+Why caregivers still favor agencies over independent work.
+Understanding how emotionally taxing the caregiver coordination role can be.
+Features that support the relationship with long-term care insurance providers and care management.

+ +

Links Mentioned in Today’s Episode:

+ +

Jon Levinson on X
+Jon Levinson on LinkedIn
+[Jon Levinson Email](jon@clarahomecare.com)
+Clara Home Care
+Clara Home Care on Facebook
+Clara Home Care on LinkedIn
+Thoughtbot
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+O8nZSJaC + + ]]> + + Will Larry + Chad Pytel + + + 540: The Tech Behind Eslando’s Circular Fashion Revolution with Karishma Gupta + https://podcast.thoughtbot.com/540 + b12711dd-6f90-40a7-b860-14e4d0ff06f5 + Wed, 04 Sep 2024 17:00:00 -0400 + thoughtbot + + full + 14 + thoughtbot + We're joined by Karishma Gupta, the Founder and CEO of Eslando Circular Fashion, a company dedicated to changing the clothing industry through circular economy principles and textile recycling. + 37:46 + no + + In this episode of Giant Robots Smashing into Other Giant Robots (On Tour!), hosts Sami Birnbaum and Svenja Schäfer are joined by Karishma Gupta, the Founder and CEO of Eslando Circular Fashion. Eslando is a fashion company dedicated to changing the clothing industry through circular economy principles and textile recycling. Its mission is to simplify recycling and ensure compliance with EU regulations by connecting brands, consumers, and recyclers, fostering transparency and efficiency in the fashion industry. In today’s conversation, Karishma delves into her company’s innovative Digital Product Passport and how it’s revolutionizing the fashion and textile industries. We discuss how her company helps the right material get to the right recycler using data and leveraging AI to map the process. Tune in to explore how the circular economy applies to the fashion industry, the current recycling gaps, what motivates fashion brands to be more sustainable, and how Eslando is reducing the carbon footprint of the textile supply chain! +Key Points From This Episode: +Background on Karishma and what led her to start a tech company. +How recycling in fashion differs from other industries that recycle. +An outline of the biggest recycling hurdles facing the fashion industry. +The complex range of materials in clothes and the problems they create. +Karishma’s transition from the fashion industry to founding a tech-based company. +Some of the materials in clothes that are endlessly recyclable. +Details about the Digital Product Passport and what it offers the supply chain. +Benefits and costs of sustainable regulations and solutions for fashion brands. +Ways that Eslando is monetizing its various solutions. +The value proposition the Digital Product Passport offers consumers. +How long it took to create and build a workable prototype. +What Karishma has planned for the future of Eslando Circular Fashion. +Links Mentioned in Today’s Episode: +Karishma Gupta on LinkedIn (https://www.linkedin.com/in/karishma248/) +Karishma Gupta on X (https://x.com/_karishmagupta) +Eslando Circular Fashion (https://www.eslando.com) +Innovate UK (https://www.ukri.org/councils/innovate-uk/) +Carbon13 (https://carbonthirteen.com) +Sami Birnbaum (https://samibirnbaum.com) +Sami Birnbaum on LinkedIn (https://www.linkedin.com/in/samibirnbaum/) +Svenja Schäfer (svenjaschaefer.com) +Svenja Schäfer on LinkedIn (https://www.linkedin.com/in/svenjaschaefer/) +Will Larry on X (https://x.com/will23larry) +Will Larry on LinkedIn (https://www.linkedin.com/in/william-larry/) +Victoria Guido on X (https://x.com/victori_ousg) +Victoria Guido on LinkedIn (https://www.linkedin.com/in/victorialguido/) +thoughtbot (https://thoughtbot.com) +thoughtbot on LinkedIn (https://www.linkedin.com/company/150727/) +thoughtbot on X (https://twitter.com/thoughtbot) +Giant Robots Smashing Into Other Giant Robots Podcast (https://podcast.thoughtbot.com/) +Giant Robots Smashing Into Other Giant Robots Email (hosts@giantrobots.fm) +Support Giant Robots Smashing Into Other Giant Robots (https://github.com/sponsors/thoughtbot) + + + In this episode of Giant Robots Smashing into Other Giant Robots (On Tour!), hosts Sami Birnbaum and Svenja Schäfer are joined by Karishma Gupta, the Founder and CEO of Eslando Circular Fashion. Eslando is a fashion company dedicated to changing the clothing industry through circular economy principles and textile recycling. Its mission is to simplify recycling and ensure compliance with EU regulations by connecting brands, consumers, and recyclers, fostering transparency and efficiency in the fashion industry. In today’s conversation, Karishma delves into her company’s innovative Digital Product Passport and how it’s revolutionizing the fashion and textile industries. We discuss how her company helps the right material get to the right recycler using data and leveraging AI to map the process. Tune in to explore how the circular economy applies to the fashion industry, the current recycling gaps, what motivates fashion brands to be more sustainable, and how Eslando is reducing the carbon footprint of the textile supply chain!

+ +

Key Points From This Episode:

+ +

Background on Karishma and what led her to start a tech company.
+How recycling in fashion differs from other industries that recycle.
+An outline of the biggest recycling hurdles facing the fashion industry.
+The complex range of materials in clothes and the problems they create.
+Karishma’s transition from the fashion industry to founding a tech-based company.
+Some of the materials in clothes that are endlessly recyclable.
+Details about the Digital Product Passport and what it offers the supply chain.
+Benefits and costs of sustainable regulations and solutions for fashion brands.
+Ways that Eslando is monetizing its various solutions.
+The value proposition the Digital Product Passport offers consumers.
+How long it took to create and build a workable prototype.
+What Karishma has planned for the future of Eslando Circular Fashion.

+ +

Links Mentioned in Today’s Episode:

+ +

Karishma Gupta on LinkedIn
+Karishma Gupta on X
+Eslando Circular Fashion
+Innovate UK
+Carbon13
+Sami Birnbaum
+Sami Birnbaum on LinkedIn
+[Svenja Schäfer](svenjaschaefer.com)
+Svenja Schäfer on LinkedIn
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode of Giant Robots Smashing into Other Giant Robots (On Tour!), hosts Sami Birnbaum and Svenja Schäfer are joined by Karishma Gupta, the Founder and CEO of Eslando Circular Fashion. Eslando is a fashion company dedicated to changing the clothing industry through circular economy principles and textile recycling. Its mission is to simplify recycling and ensure compliance with EU regulations by connecting brands, consumers, and recyclers, fostering transparency and efficiency in the fashion industry. In today’s conversation, Karishma delves into her company’s innovative Digital Product Passport and how it’s revolutionizing the fashion and textile industries. We discuss how her company helps the right material get to the right recycler using data and leveraging AI to map the process. Tune in to explore how the circular economy applies to the fashion industry, the current recycling gaps, what motivates fashion brands to be more sustainable, and how Eslando is reducing the carbon footprint of the textile supply chain!

+ +

Key Points From This Episode:

+ +

Background on Karishma and what led her to start a tech company.
+How recycling in fashion differs from other industries that recycle.
+An outline of the biggest recycling hurdles facing the fashion industry.
+The complex range of materials in clothes and the problems they create.
+Karishma’s transition from the fashion industry to founding a tech-based company.
+Some of the materials in clothes that are endlessly recyclable.
+Details about the Digital Product Passport and what it offers the supply chain.
+Benefits and costs of sustainable regulations and solutions for fashion brands.
+Ways that Eslando is monetizing its various solutions.
+The value proposition the Digital Product Passport offers consumers.
+How long it took to create and build a workable prototype.
+What Karishma has planned for the future of Eslando Circular Fashion.

+ +

Links Mentioned in Today’s Episode:

+ +

Karishma Gupta on LinkedIn
+Karishma Gupta on X
+Eslando Circular Fashion
+Innovate UK
+Carbon13
+Sami Birnbaum
+Sami Birnbaum on LinkedIn
+[Svenja Schäfer](svenjaschaefer.com)
+Svenja Schäfer on LinkedIn
+Will Larry on X
+Will Larry on LinkedIn
+Victoria Guido on X
+Victoria Guido on LinkedIn
+thoughtbot
+thoughtbot on LinkedIn
+thoughtbot on X
+Giant Robots Smashing Into Other Giant Robots Podcast
+[Giant Robots Smashing Into Other Giant Robots Email](hosts@giantrobots.fm)
+Support Giant Robots Smashing Into Other Giant Robots

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7kbba_40 + + ]]> + + Will Larry + Chad Pytel + + + 539: Human-Centered Design and Innovation with Sheng-Hung Lee + https://podcast.thoughtbot.com/539 + 36e0f3eb-38f1-4eca-8ff9-e7686578700f + Thu, 22 Aug 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Giant Robots On Tour introduces Sheng-Hung Lee, a designer and PhD researcher at MIT AgeLab. He shares his journey into design and emphasizes the evolving role of designers in addressing broader issues like climate change and aging. Sheng-Hung discusses practical applications such as smart homes for aging populations, the importance of designing for different life stages, and his views on well-designed and poorly designed products. + 41:24 + no + + + Giant Robots On Tour Hosts Sami Birnbaum and Jared Turner introduce Sheng-Hung Lee, a designer, PhD researcher at MIT AgeLab, and board director at the Industrial Designers Society of America. Sheng-Hung shares his journey into design and engineering, emphasizing the importance of interpreting signals in design and the evolving role of designers from problem-solvers to culture shapers. He discusses how designers must now consider broader, systematic issues such as climate change and aging. Sheng-Hung explains that design is a teachable and essential life skill, highlighting the significance of personal experiences and failures in learning design. He elaborates on the concept of signals, explaining that they represent different perspectives and interpretations in design, which are crucial in addressing complex problems. +The conversation shifts to practical design applications and Sheng-Hung's work in smart homes for aging populations. He discusses the integration of various smart systems and the importance of designing for different life stages rather than specific age groups. Jared and Sami also engage Sheng-Hung in discussing the worst and best-designed products, where Sheng-Hung mentions his initial skepticism but eventual appreciation for facial recognition technology. +MIT AgeLab (https://agelab.mit.edu/) +Industrial Designers Society of America (https://www.idsa.org/) +Follow Sheng-Hung Lee on LinkedIn (https://www.linkedin.com/in/shenghunglee/). Visit his website: shenghunglee.com (https://www.shenghunglee.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: + SAMI: Hello again, and this is The Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots On Tour Series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Sami Birnbaum. +JARED: And I'm your other host, Jared Turner. +SAMI: If you are wondering, which you might have been for a while now, where are Will or Victoria, well, make sure you find one of our previous podcasts where we introduce the Giant Robots on Tour Series, and you'll understand why you're hearing myself and Jared a little bit more frequently than before. In that podcast, we throw random icebreakers at each other, and we find out that Svenja does not like online banking. And if you haven't listened to our previous podcast with our guest, Ishani, check that out as quick as you can and find out why AI is compared to babies. +Joining us today is Sheng-Hung Lee, a Designer and PhD Researcher at MIT AgeLab and Board Director at the Industrial Designers Society of America. Sheng-Hung, I'm going to level with you. I've done my research. I've done my due diligence on the guests that we have on this podcast, and I'm exhausted. +SHENG-HUNG: [laughs] +SAMI: I've looked through your own website, and I've read as much as I can find about you. And between education, experience, awards, scholarships, there is an incredible amount of things that you're involved in that you get up to. And it really wasn't good for my own self-esteem just to see how much you have going on. +SHENG-HUNG: [laughs] +SAMI: Jared, a question for you first. Bear in mind, the only thing I've ever been awarded is my own driving license. So, our guest, Sheng-Hung, how many awards do you think he has currently listed on his website? Give a guess. +JARED: Oh gosh, I remember looking at the page, and I remember having to scroll. +SAMI: [laughs] Yeah, you had to scroll. +JARED: Let's pick 33. +SAMI: 33. Do you know what? It's not even close. Okay, he's nearly double that. So, he's up at 60 awards that are currently listed. So, we're talking about a guest that you guys do not want to miss. And you want to make sure that you get into this conversation. I always like to go back to the start with my guests. So, everyone has a story. And I'm interested, Sheng-Hung, in your journey and what led you into the world of design and engineering. +SHENG-HUNG: My personal definition of design is, like, decoding signals. So, everything in our lives, like, we have different types of signals. How do we interpret the signal? How do we, like, understand, or perceive different types of signals in our lives? And I feel design is more like...not just creation. It is creation, for sure, but also about curation. I feel like, for me, problem-solving or, like, problem-defining is really interesting. And especially you mentioned, like, my very early stage as a designer, the reason I submitted my work to get an award is because I want to show my problem-solving skill. +And I realize nowadays, like, the problem is too complicated. It's not just about solving problems, right? I mean, I feel design is more bigger than that, especially now most of the problems are systematic and complex. Climate change, right? Like, you think about aging, and you think about all this, like, sustainable issues. I feel like designers, like, for me, starting from problem solver, as engineer, and now more I've become like a translator, curator, or even, like, a culture shaper. How do you shape the culture you want, right? +Especially now, like, AI it's just, like...that really let me rethink about my role as designer, you know, because everyone can have tons of ideas, but the truth is, like, we have so many ideas, but do you know what good taste is about? Do you know what the good qualities of life's about? So, you have to have some personal experiences to really help people to understand or curate the vision in the future. +SAMI: That's really interesting. I struggle to dress my kids in the morning from a design perspective, right? I don't get colors, and I don't understand necessarily how they match and how to get things working. In fact, sometimes I'll dress my kids only to find that my wife has redressed the kids. Things are that bad at home. +Do you think then design is something which can be taught, or is it something, like, innate? Is it something, in your own experiences, that it's kind of part of your nature? So, you see the world differently to someone like myself or Jared sees the world. Or could that be something which we could pick up on, you know, and learn about? +SHENG-HUNG: Yeah, I definitely think design can be teachable. It's skillable. And I feel like, yeah, people talk about this is, like, a hardcore skill. It's a soft skill. No, I think design is a life skill. It's a human skill. So, that includes like, for example, like, yeah, how do you choose the color? How do you choose the clothes for kids? But also about, like, how do you celebrate the quality of lives, right? How do you, like, have better, like, qualities? +And I feel like, I don't know, life skill means, like, team building, creative leadership, knows people, listening to people. And, for me, that's part of design because you're decoding different signals. You understand your life. You perceive different types of noises. Or how do you resonate with other people? And that's a life skill, I think. And I also feel most of the design skills I learned is actually not from school. It's from, like, personal life failure [laughs]. +SAMI: That's really interesting. I just want to jump in because I don't know if I fully understand what you mean by signals. Can you just elaborate on that a little bit more? And then, I will bring you back up on personal failures. +SHENG-HUNG: Signal is like different ways of seeing things, right? So, for example, like, if I go to wait in line for a free bagel, right? You share this with your friends. What I see is it's a free bagel. But what my friends see is like, oh, probably, like, I don't need to wait in line and so many challenges. You know, I have to, like, oh, why should I get this? But I see very clearly I want a free bagel. So, these are different. It's the same thing but different message mixed up, right? +And then, for me, I see design, like, it happens every day. It's a life skill. For example, like, I saw the challenges, but what if we think another perspective to rethink about what kind of challenge [inaudible 06:38] or reframe the right questions, right? And all this, like, mixed all together, it feels like it's not just about drawing beautiful sketches or rendering sexy, you know, ideas. It's all about, like, how do you frame these challenges? How do you look at this? Can you see the question from social aspect, from cultural aspect, or you just see this as a solution-driven approach? +JARED: In some cases, I feel, there is an element of subjectivity to the designs, but then we also want to measure the success of a design. Do you have any tips for, like, how you go about putting numbers to what defines success for a particular design? +SHENG-HUNG: This is such a great question, especially now my research focus is really on services, you know, service design, experience design. Like, how do you quantify this, right? For example, three of us we go to the restaurant, and I feel it's really, really great restaurant. And probably some people feel no, that's not really great. And then, how do we quantify this, right? +And then, I feel it's sometimes, like, really by personal preferences. It's hard to measure. Maybe there will be some sort of, like, a principle direction or criteria we can follow, so, for example, service quality metrics or something, like, based on people's life experiences. I feel it's hard to measure, especially now the design challenge the question it's really complicated. +Some people talk about demographic. How do you, like, [inaudible 08:09] design? Like, for example, a participant design process, right? Or, like, inclusiveness. People talk about equity, power, power dynamic. And I think it's less of a measure or quantify. It's more about do you show your respect? Can we be more inclusive in this process? Can we really engage or integrate multiple voices in this design process? +And I feel like that kind of shows the flexibility, also, the real flexibility of the design, not just that, oh, we look for one single solution. Because, most of the time, we actually want to design for a solution, but, actually, I feel now the shift is from we try to build the condition to let people land on this condition and solve the problem. So, in the end, we'll be like, yeah, we landed here, and we can solve the problem together collectively. So, something I feel a little bit different, but that's a great question. It's open-ended. Yeah. +JARED: Yeah. Thank you. There's a lot to think about there. I want to bring it back to failure because this is something I think about a lot in terms of teaching and learning from history versus learning from your own failure. +We have, like, thousands of years of history of failure. You think we have made all the mistakes already, and, oh, it should be easy, right? All we need to do is teach all of the young generation about all of this failure, and then they'll remember not to do it. But in reality, it doesn't really work that way. I find the strength of the argument is oftentimes weak compared to failing yourself and really deeply learning that lesson. I'm curious about your thoughts on that. And then, I'm also curious to hear about some of your, let's call them, best failures. +SHENG-HUNG: I personally feel like people fail. They fail forward, not backward. So, even if you fail, you move a little bit. It depends on how crazy, right, and how fast you fail. It's an iterative process. The reason I say learning from failure because from traditional Asian family, Asian students, right? Probably in the past, I would say I raised my hand. I want to learn, or I ask senior people. I want to learn. But, actually, more than that, it says, "I want to experience. I want to be part of it," right? So, you're not becoming the manager because you learn to become a...no, you're in that position, and you learn to be a manager. +So, I learned that mindset when I worked at IDEO. And one of the senior design directors told me, "No, you should say, 'I want to experience.'" So, that means that you have fully immersed experiences. And one of the best examples for me is that the first two years I worked at IDEO and IDEO Asia, supporting projects in Tokyo, Shanghai, Singapore offices, and sometimes European, like, office work; the first two years, my confidence almost collapsed. I have to collect my confidence. It's so hard because I'm eager to learn so many things. I didn't beat myself. And then, after two years, I met an amazing, like, design mentor. And I started the things I'm good at as product designer, a tangible designer. I start as product-focused and thinking about whole design process. +And then, I start to collect my confidence. And I realized every single project at IDEO or in my life it's a vehicle, you know. And then, you always connect the dots when you're looking backwards. And you realize, oh, this is failure. Let me know what do you mean by client management? What do you mean by, like, teamworking? Because everyone is from so diverse background. And everyone says, "I'm a designer," but they have different interpretation. And how do you communicate it, right? And how do you keep the conversation transparent and also effective, and how do you empower people? And I feel because of that connect the dots process, also, all the things I want to learn, I want to experience it really helps me to grow at the third year or second year in IDEO. +And that really makes me think about, oh, wow, I didn't know. I failed completely. And that's really healthy, for me, because you become very strong. At some point, I started to realize, oh, what do you mean by...what does it mean by design consultancy business? What we can sell. Where's our capacity, our limitation? You know, other than just, oh, everything's, like, imaginative conceptual. I kind of know what happened, and I know the boundary. And I know how can I empower people and also the client. +SAMI: Yeah, embracing failure is a real strength. At thoughtbot, we kind of...if we're developing products and we're, let's say, designing or coding, whether websites or applications, we have this concept of failing fast. So, the faster you can fail, the quicker you can iterate towards the right solution. And that's something which is difficult to embrace because the first time you do it, I want this to be perfect, and I want to build it in the way that it works. But, actually, you'll spend a lot of time trying to get towards that perfection, and it's much better to ship faster, fail faster, and then get towards the solution. +I noticed as well that...well, I read that the one thing you've been recently working on is designed for the aging population, so more specifically, smart homes for the aging populations. Shout out to my parents if they're looking for a smart home. Sorry, mom and dad. +SHENG-HUNG: [laughs] +SAMI: I've always found, especially my generation, so I'm about...I'm not about; I am 32 years [chuckles] old. So yeah, there's always been, like, a big gap between kind of my generation, the way we've engaged with technology products, the way my parents' generation have been able to. And I imagine a future where my kids are running around in VR headsets, and I'm still, you know, using a basic laptop. I would love to know more about your work kind of in this area and designing for a different sector of the population. +SHENG-HUNG: My master thesis and my master project is focused on redesigning, like, smart footwear for aging population, and then that's part of the smart home ecosystem. And I was actually impressed and surprised. It's like most of the sponsors or clients we talk about, like, people [inaudible 14:38] to think about just the product level, so smart like [inaudible 14:43], smart like a door, or smart like, you know, like a bed or a smart, like, alarm clock. +People start to think about how can we integrate all this system together? Because, like, for example, if you bought Amazon, you know, versus Apple and all these different devices, the platform is really a problem because the products cannot communicate with each other. And we want to make sure all the products can communicate and support you, or, like, they can at least receive your data or information to give the appropriate response. +So, the smart home project starts to think about from ideas to become more like platform integration. IKEA is the best example, right? Like, I think two years ago, they talk about, yeah, they launched their first app, right? Everything is, yeah, it seems like, oh, what's the big deal about this, right? No, but you think of this from the intention perspective to actually connect the whole system together because they want to make sure their internal designer, developer they really can think through their own internal system to make sure everything's connected, interconnected, not just, oh, you do a part of this. We sell this to a certain Asian, and it didn't really connect. +So, I feel like when we designed it, it's really from the system perspective to talk about a smart home. And then, regarding of, like, design across [inaudible 16:04] generation, that's really important, actually, because especially now I'm focused on design for retirement. And I shifted to design for longevity. And then, the cool thing about this is, like, we think about our life in terms of age, but, actually, now we need to think about our life in terms of different life stages, different lifestyle. +The book called "Stage (Not Age)", means, like, now we cannot even describe people above 100 years old or 85 years. So, we call them future hood, right? So, like, different life stages. And I feel like that really impacts, as designers, the way we design products or interfaces, right? And it has to evolve with people. When you say, for example, if we have, like, a smart, like, a robot in our home, they have to know your personal routine. And you kind of grow, right? For example, oh, I get older. I move slower, or my mobility is different, and it changes. How does that mean to our product or our smart services? +And I feel like across different generations, it's really thinking about design for different people in different life stages. And that's really important, not just about financial planning or about your future education, family, community, right? Now people are probably thinking about aging in place. My parents just bought a second home. They're thinking about retirement life. And so, these are things that really impact all aspects of life. And I feel like the idea of one solution for all the era is kind of over because we have to think about not just one solution, multiple solution tailor-made for multiple different people in different life stages. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +JARED: And, Sheng-Hung, in one of your articles that I was reading about design for longevity, you sort of say that design for aging isn't just about designing for older people, but rather, I think one of your colleagues asked this question, which I really liked, which is, how can inclusive methods build elegant design solutions that work for all? And I find that a really aspirational goal. +But one of the things, say, at thoughtbot, when they're building a product, so we often talk about targeting a specific niche or a specific user base because then we can really optimize for them. And so, you're designing something that's elegant, and that works for all. It doesn't sound very easy. It sounds like a good challenge. And I'm curious about how do you go about that, and do you have any examples you can you can share? +SHENG-HUNG: Design for all elegantly also seamlessly. Optimize everyone's needs or, like, design process. I feel...because my topic is focused on financial planning, right? And I think about everyone's income level is different. Their investable income asset is also different. We have a different situation, right? Our family issue, the healthcare condition is also different. And I feel like that, also, if we look at this question, we should think about, okay, how do we define design for all, right? Is it universal design, or is it inclusive design? +I think there are definitely some, like, basic or fundamental, like, foundation or criteria we need to meet. Like, for example, human-centered, right? Or, like, we think about accessibility for certain technology. What's the threshold for a certain way of use the technology or product? That could be, like, a universal or, like, basic. Like I said, people's life stages are so different. And can we really make sure our product or interfaces is always dynamic, always change? Design for transformation, right? And I feel the ideas of changing is kind of scaring for most people. Because you don't want to, like, you woke up, and you realize your iPhone just update the whole interfaces, and you suddenly don't know how to use it [laughs]. It changed too dramatically. +What I mean by change is like, it's a gradual integration process. And I feel that's kind of beautiful. Like, for example, the way I use my bicycle, the biking, right? They can ultimately adjust my speed, recharging, or understand my personal preferences. That could be something I think is powerful for future for providing the right solution, yeah. But also, it's a benefit of this, but also, there's downsides. Like, maybe because of that, we all live our own personal bubbles pretty well, right? Like, oh, yeah, yeah, I read a newspaper. No, you read the newspaper that I curated for you. So, somehow, the information started different [laughs]. So, there's a gap, but I don't know. It's very cool. It's very great, great question. I think there's still...I don't have the exact same answer, but I feel that could be potential for now. Yeah. +JARED: Yeah, I really like that. So, it's not just a one-size-fits-all-all, but, like, it's a sort of an elegant transformation over the course of someone's life. We've discussed a few different things like design for longevity. You touched on there, as we were speaking, human-centered design. I know you've made a distinction of humanity-centered design as well, and there's also life-centered design. I wonder if you could give us and our listeners a little rapid-fire explainer of each of them. +SHENG-HUNG: Like, when we talk about human-centered design, right? Like, it's, like, a buzzword. And everyone talks about HCD, and most people think, oh, if you got a post-it note, you're, like, a HCD designer. No, like, what does that mean, right [laughs]? It's very cliché. And they're like, oh, yeah, all these, like, HCD designers bring the post-it notes with Sharpies and go to facilitate tons of workshops, and they sit and know people. And I feel it's more than that, right? +Human-centered is really, like, put yourself, designers, in the shoes of clients, users, customers, and participants to know their needs, their desire and address their pain point. And I think for human-centered design like Don Norman said in his latest book, it's not just about design as a discipline. It also covers, like, politics, covers, like, ethical issue, culture. It's broader. And, for me, the simplest version is, like, you design with care. You design with human temperature. We create technology with human temperature. That means that we're now for this technology to [inaudible 23:13] technology. We know why we need that technology. +So, for example, if you provide the, like, the cell phone to the developing countries, you probably don't want to send, like, the latest cell phone. You want to send them, like, the adequate technology. What I mean by that is like, it's very, like, stereotype, but I'm trying to explain the idea is like, oh, Nokia could be a great option at this point, for example. You can communicate. You don't need, like, crazy, like, AR VR function. You at least can communicate. So, it's adequate. I think that kind of lens is, like, you think about the culture, the needs, economic, social status. And then, you can start to move on and upgrade the devices. +And I feel like life-centered is even broader. It's like, can you design something to the lens of cats, your pets, your animals? So, it's really like, it's really...it sounds a little bit like a speculative design. But the truth is, like, we can shift our perspective to different kinds of species, cross-species, not just focus on human, because everything we design definitely starts from also for a human being. But now life-centered is like, it's longer, broader. And then, for me, it also means like, we just talk about life-centered. It's like, really think through all different stages of life, not just, like, focus on one single age or a single stage, too specific, too narrow. It's, like, broader. +So, when we talk about life-centered design, LCD, we really think about a lot of different systems, framework. What's the model we can follow? You know, so we're also thinking about policy, about power dynamic, government, ethical issues. So, this, I think, like, it's broader, and it's really large. Sometimes it's pretty vague, for sure. We have to use some cases or really think about in different contexts. Context is really important, designed for different contextual knowledges and needs. +SAMI: Yeah, I think that is actually a really helpful understanding. Myself I don't know anything about those concepts, so to kind of get that theoretical understanding and explanation from yourself is really helpful. In a more practical sense, I have a question, which is a very selfish question. The reason it's a selfish question is because I want to know what do you think? When you look at the world through your designer lenses, what do you think is the worst-designed product you've ever seen or come across? And I think I know the answer to this. I think there is a right answer. +While you have a think, I'll share my answer. I don't know if you have this because you said you're based in Boston at the moment. And I'm showing you because we're on camera, but I will describe it to the listeners as well is what they've done with bottles now is when you open, like, a Coke bottle, for example, all other beverages are available...Coke, if you want to sponsor us [laughter], we're happy just to mention you. When you take the bottle cap off, it's now connected to the top of the bottle. +So, someone has decided...now, I understand the reason behind it. They're saying that it's for recycling. So, when you throw your bottle away, make sure the cap goes with the bottle. But someone has sat there, and they've designed the bottles. So, when you take off the cap, it's still connected to the top of the bottle. And countless times, I'm either pouring into a cup or pouring into my mouth. And that cap is getting in the way. So, the liquid kind of goes into that cap, and it spills on me, or it spills on the table. This is an absolute design failure, a catastrophe in my eyes. That's my worst design that I've come across in real life. Do you have anything you can think of that you look at, and you're like, who designed this? +SHENG-HUNG: This is such a great example because I did have similar experiences when I went to Milan Design Week last year. All the plastic bottle is, like, connected. The cap connects with the bottle. And I didn't know that it's on purpose at the very beginning. I thought, how come it's, like, connected? I want to take it out because it's easier for me to drink. And I realized it's not just this one; all of them is the same [laughs]. Yeah, that's a great example. +I think, for me, design for failure adapter, for example, you know, adapter, like dongle, right? Like, we have so many different...this guy HDMI cable, the cable for iPhone, and the magnet for my Apple MacBook Pro. That's painful because you try to find, like, when you go to, like, a talk or a speech or try to present something, I think, for me, the easiest way is, like, AirPlay, right, Wi-Fi or Bluetooth to connect to the projector. But in reality, you always need this HDMI cable. And this guy connects with my Mac. There's some problem. It depends on...now I always bring my adapter with me. +It's just like, we have that [inaudible 28:04] like, you know, it almost, like, very frequently, if we're meeting, you have to show your screen. How can we design less physical but it's user-friendly, right? People use Mac. People use Apple, use, like, Microsoft. How do you design something like a universal adaptable to everyones, just sharing screen? This is what I need. So, I think this could be one bad design, I think, at this moment [laughs]. +SAMI: Yeah, that's a great example as well, and so frustrating. And I wonder if it's, like, a money-making scheme, you know, everyone has their own chargers. And that's a way kind of they make some income as well on the side. Jared, what have you seen in the world? What's your pet peeve? What really grinds your gears? +JARED: This was easy for me. It came to me straight away. Any door that has a handle that you can wrap your hand around which signifies it should be pulled that is push. It's just, I mean, what is going on there? It drives me bonkers. +SHENG-HUNG: [laughs] +SAMI: That is brilliant. I think it's only fair if we flip the question, right? And then, we say, what's the best thing you've seen designed, right? There must be something out there where you've gone, "Oh, that is so useful. That makes so much sense. Why haven't we done that until now?" And have you kind of...I guess this is for Sheng-Hung, like, have you got any inspiration from that sort of thing? +SHENG-HUNG: I have to be honest. Like, I really feel like in the past, I'm kind of scared about, like, use your face to unlock your phone. But the more I use it, I feel like, oh my God, this is so convenient. You just look at it. I know it's a bit scary because they have all your biometric data information. I know even you protect under the regular law, but still, I feel like, yeah, it's so seamless connected. And I feel maybe the better answer is like, I feel a great design is, like, to reduce the friction between the transition of devices by devices, right? So, for me, I mean, so interface by interface. +So, when I share the data on my phone, what does that mean? From phone to my computer or phone to other people, right? All the different interfaces changing. The less friction, the better. I feel seamless connected. So, you know, AirDrop, super convenient, photos, videos with people, Mac users. But what does that mean for, like, Windows users, right? And so, every platform has their own, like, spec, or criteria. And I feel if the user can feel the seamless friction between these interfaces, for me, that could be a great design solution. +JARED: I love that answer. And I love that description of reducing friction. It reminds me a little bit of, I think, my favorite book on UX is by Steve Krug, which is "Don't Make Me Think." And it's just all about doing the simplest thing, reducing confusion, overcoming objections, and reducing friction. So, I really love that. +I do have an answer for this one as well. It's a little bit selfish or focused on my own life. So, I have a dog. She's a Welsh Terrier called Rosie. She's just turned one. Whenever we used to go out, you've got to take water for her if it's a hot day. I always used to take a bottle, whether you could unscrew the top or not, I'm not sure, Sami, and, like, a little bowl to put that in, or you use your hands. And, invariably, she's not going to drink all of the water, so you've got waste. You throw that out. The bag gets wet, all of that. +Someone has designed this really cool bottle where the top is actually the bowl. It's an all-in-one. And you press a button; the water goes into the bowl. She drinks. Whatever's left, you press the button again, turn it upright. And the water just flows back in into the rest of the bottle. It's such a simple thing. But, like you say, it just reduces that friction. Anytime a problem no longer exists, manual to automatic cars, fight me, I'm all for it. Well, that's a problem solved. That's less friction. That's beauty in the world. +SAMI: Yeah, I think it's amazing. When you think about these examples, it really brings out how much of an impact design has. So, you can have the best product in the world, but if you don't get that frictionless design, or you don't get that design that's going to really bring that improvement, it's going to be difficult to make that product a success. +And I think there's some, like, when I think about leaders and innovators in this kind of space, so I know you already mentioned IKEA and I think of Apple. And I don't know the answer to this, and maybe our listeners also wonder, like, how do these companies...they seem to keep getting it right. No matter what happens, they seem to set the trends, and they get their design spot-on, and they innovate in that space. How are they so successful in their design? +SHENG-HUNG: I think a recent example is like, you know, like, Apple just recently launched the Vision Pro, right? The XR, the goggles. And put the demo time 30 minutes to get in-store experiences. You're booking the demo time with them, the 30 minutes. For me, I wrote an article about it. It is less about the goggle itself. It is about the whole experiences. +The time you enter the store, right, and then you're waiting there, who guiding you? The Genius Bar people guiding you. You sit down. You have the prescription and your glasses that get measured, scan the QR code, and find the match [inaudible 33:35] pair of goggles that fit your [inaudible 33:37] of your face. And they put it on. They sit on the side, use the iPad to guiding you, and tell personal experiences or stories. +These companies are very design-driven, vision-driven company. They really think about the whole experiences of users, right? And, for me, it's too pricey, for me, the product, obviously, right now. But I have very delightful, positive experiences because of that 30-minute demo. So, I kind of plant the seeds in my heart. Oh, if the second generation or something have discount, I would definitely want to get one for myself. Not really because...it's a great design for sure, but also, the impression I have. +And I feel that really, really, like, make a difference, right? It's tiny. It's very subtle. They can, "No, we don't have, like, demo experiences." They can just purely sell the product. But I think they sell something bigger than just product. Branding user experiences, delightful experiences. And I can really feel that, and that's really powerful in the end. +JARED: Do you think that that sort of level of design is limited to the companies that can afford it like the big names? Like, obviously, there is a cost dedicated to having the time and to putting the resources to that. Is it always just going to be the big players, or are there things we can do to democratize that availability for the startups, for the SMEs? +SHENG-HUNG: I actually think it's about a company's culture. So, another example I would love to share is, like, when we did, like, an inspiration trip in Tokyo, and there's a very famous, like, chain bookstore called Tsutaya bookstore or Tsutaya electrics. So, to my surprise, like, yeah, it's a big bookstore, and we probably think bookstore selling books. No, they're actually selling a lifestyle. +So, for example, like, if I want to buy the book around how to use a camera, right, the way they curate it, it's like, yeah, we do have the books around camera, but also, we'll put the real camera, like, near the book. So, they curate the whole experiences. You flip the book. Oh, this is so cool. Thanks, I want to try it. You probably, in the end, you got both. So, very interesting and also very human-centered, like, retail experiences. +Why did I say culture? Because when I entered the store, I asked for one book I was looking for. The staff came to me, and she bring two books to me. One is the book I want, unpack. And one is the book...it's the same book, but without the plastic cover. It's brand new. And why she brought two books to me because if I want to buy this book, I not only read inside, but also, I can just get the new one with me to check out. And this is so subtle, right? Because they're not just bringing you, like, the sample. They also bring the final product with you. +So, I feel that kind of culture is, like, very strong, customer-centered, think about your needs, think about your next step. So, they kind of plan ahead, and this is so strong message to me. Oh my God, this is such a great design culture, or at least a human-centered culture to think about my needs, my decision-making process. So, I feel connected with that, and I feel like, yes, they have money, but also, like, they really cultivate that culture within the...not just...they also send a message to their customers. +SAMI: I feel like, Sheng-Hung, we could speak to you for hours. I mean, you are opening my world and my eyes to a different world of design. I've got one final question for you before we wrap up that I wanted to cover. I've seen from your website, like, you've personally designed products. So, out of all the products you've either designed yourself or you've been involved with, what would you say, and could you describe for us your favorite product that you've designed yourself? +SHENG-HUNG: I think my favorite product is, like, I help and re-design, like, Shanghai Library Innovation Space that, for me, is OMG. Oh my God. It's crazy. Like, one single team, my side project and collaborate with the full staff, librarian, the leadership team. What is powerful is, like, library for them in Shanghai, it's a local hub to connect the community and also to teach, to learn for the younger generation how to use the space. For sure, most people use that space for, like, self-studying, you know, activity and all this stuff. But, for me, like, it's so impactful because every single change that means a lot of impact because it's a public space. +And also, it's really, really powerful. Like, you think about the decision-making process. You have to think about feasibility, viability, and also desirability, all things to connect together. And it's really hard, not easy process. It took me about a year-long project. And I'm really happy because, in the end, it's really from sketches, concept, prototyping models, all the way they rebuild, modify the design, integrated. And now the new library they build on another area of Shanghai is really based on this model and framework. I'm very happy, and I also feel like, yeah, design can make a positive impact. It's not like a concept. It's real. And it's nice. It's painful, but it's really satisfying, yeah [laughs]. +SAMI: That's really cool when you get to a point where you've done something, and then you see people using what you've designed and, like, enjoying that space and benefiting from all that hard work that you've put into. I have to thank you so much for joining us and giving us time today on the Giant Robots On Tour Series of the Giant Robots Smashing Into Other Giant Robots podcast. Our listeners don't know, but you've had about two hours of sleep. +SHENG-HUNG: [laughs] Yeah. +SAMI: So, it's probably time for you to get back into bed yourself. But that is your dedication to us. It's been an incredible episode and an incredible chat. I finally understand why Jared does not like doors. I myself, you will understand if you see me in the street and I'm tearing a bottle cap off of a bottle, you'll understand why. And we need to sort Sheng-Hung out with more adapters with just a single charger for all his devices. If people want to get a hold of you, Sheng-Hung, where's the best place they can reach out after listening to this podcast? +SHENG-HUNG: Yeah, definitely, you can reach out through my personal website portfolio. Yeah, shenghunglee.com. And I'm happy to respond and discuss about design-related topic. Thanks for having me on this podcast. It's very exciting, and hope we can create all the great stuff for our society. +SAMI: Pleasure. There's always a challenge I give to my listeners at the end, and it normally is just please hit that subscribe button. Jared has promised me that he will do a shoey if we can double our subscribers by the end of the series. If you don't know what a shoey is, my only advice to you is do not Google it because you do not want to know. +You can find notes and a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See ya. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + design innovation, Sheng-Hung Lee, MIT AgeLab, human-centered design, smart homes, aging population, AI in design, culture shaping, problem-solving in design, generative AI, design lessons, award-winning designer, smart home technology, future of design, design for longevity, technology in design, human-centric processes, design insights, modern design trends, MIT researcher + + Giant Robots On Tour Hosts Sami Birnbaum and Jared Turner introduce Sheng-Hung Lee, a designer, PhD researcher at MIT AgeLab, and board director at the Industrial Designers Society of America. Sheng-Hung shares his journey into design and engineering, emphasizing the importance of interpreting signals in design and the evolving role of designers from problem-solvers to culture shapers. He discusses how designers must now consider broader, systematic issues such as climate change and aging. Sheng-Hung explains that design is a teachable and essential life skill, highlighting the significance of personal experiences and failures in learning design. He elaborates on the concept of signals, explaining that they represent different perspectives and interpretations in design, which are crucial in addressing complex problems.

+ +

The conversation shifts to practical design applications and Sheng-Hung's work in smart homes for aging populations. He discusses the integration of various smart systems and the importance of designing for different life stages rather than specific age groups. Jared and Sami also engage Sheng-Hung in discussing the worst and best-designed products, where Sheng-Hung mentions his initial skepticism but eventual appreciation for facial recognition technology.

+ + + +

Transcript:

+ +

 SAMI: Hello again, and this is The Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots On Tour Series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Sami Birnbaum.

+ +

JARED: And I'm your other host, Jared Turner.

+ +

SAMI: If you are wondering, which you might have been for a while now, where are Will or Victoria, well, make sure you find one of our previous podcasts where we introduce the Giant Robots on Tour Series, and you'll understand why you're hearing myself and Jared a little bit more frequently than before. In that podcast, we throw random icebreakers at each other, and we find out that Svenja does not like online banking. And if you haven't listened to our previous podcast with our guest, Ishani, check that out as quick as you can and find out why AI is compared to babies.

+ +

Joining us today is Sheng-Hung Lee, a Designer and PhD Researcher at MIT AgeLab and Board Director at the Industrial Designers Society of America. Sheng-Hung, I'm going to level with you. I've done my research. I've done my due diligence on the guests that we have on this podcast, and I'm exhausted.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: I've looked through your own website, and I've read as much as I can find about you. And between education, experience, awards, scholarships, there is an incredible amount of things that you're involved in that you get up to. And it really wasn't good for my own self-esteem just to see how much you have going on.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: Jared, a question for you first. Bear in mind, the only thing I've ever been awarded is my own driving license. So, our guest, Sheng-Hung, how many awards do you think he has currently listed on his website? Give a guess.

+ +

JARED: Oh gosh, I remember looking at the page, and I remember having to scroll.

+ +

SAMI: [laughs] Yeah, you had to scroll.

+ +

JARED: Let's pick 33.

+ +

SAMI: 33. Do you know what? It's not even close. Okay, he's nearly double that. So, he's up at 60 awards that are currently listed. So, we're talking about a guest that you guys do not want to miss. And you want to make sure that you get into this conversation. I always like to go back to the start with my guests. So, everyone has a story. And I'm interested, Sheng-Hung, in your journey and what led you into the world of design and engineering.

+ +

SHENG-HUNG: My personal definition of design is, like, decoding signals. So, everything in our lives, like, we have different types of signals. How do we interpret the signal? How do we, like, understand, or perceive different types of signals in our lives? And I feel design is more like...not just creation. It is creation, for sure, but also about curation. I feel like, for me, problem-solving or, like, problem-defining is really interesting. And especially you mentioned, like, my very early stage as a designer, the reason I submitted my work to get an award is because I want to show my problem-solving skill.

+ +

And I realize nowadays, like, the problem is too complicated. It's not just about solving problems, right? I mean, I feel design is more bigger than that, especially now most of the problems are systematic and complex. Climate change, right? Like, you think about aging, and you think about all this, like, sustainable issues. I feel like designers, like, for me, starting from problem solver, as engineer, and now more I've become like a translator, curator, or even, like, a culture shaper. How do you shape the culture you want, right?

+ +

Especially now, like, AI it's just, like...that really let me rethink about my role as designer, you know, because everyone can have tons of ideas, but the truth is, like, we have so many ideas, but do you know what good taste is about? Do you know what the good qualities of life's about? So, you have to have some personal experiences to really help people to understand or curate the vision in the future.

+ +

SAMI: That's really interesting. I struggle to dress my kids in the morning from a design perspective, right? I don't get colors, and I don't understand necessarily how they match and how to get things working. In fact, sometimes I'll dress my kids only to find that my wife has redressed the kids. Things are that bad at home.

+ +

Do you think then design is something which can be taught, or is it something, like, innate? Is it something, in your own experiences, that it's kind of part of your nature? So, you see the world differently to someone like myself or Jared sees the world. Or could that be something which we could pick up on, you know, and learn about?

+ +

SHENG-HUNG: Yeah, I definitely think design can be teachable. It's skillable. And I feel like, yeah, people talk about this is, like, a hardcore skill. It's a soft skill. No, I think design is a life skill. It's a human skill. So, that includes like, for example, like, yeah, how do you choose the color? How do you choose the clothes for kids? But also about, like, how do you celebrate the quality of lives, right? How do you, like, have better, like, qualities?

+ +

And I feel like, I don't know, life skill means, like, team building, creative leadership, knows people, listening to people. And, for me, that's part of design because you're decoding different signals. You understand your life. You perceive different types of noises. Or how do you resonate with other people? And that's a life skill, I think. And I also feel most of the design skills I learned is actually not from school. It's from, like, personal life failure [laughs].

+ +

SAMI: That's really interesting. I just want to jump in because I don't know if I fully understand what you mean by signals. Can you just elaborate on that a little bit more? And then, I will bring you back up on personal failures.

+ +

SHENG-HUNG: Signal is like different ways of seeing things, right? So, for example, like, if I go to wait in line for a free bagel, right? You share this with your friends. What I see is it's a free bagel. But what my friends see is like, oh, probably, like, I don't need to wait in line and so many challenges. You know, I have to, like, oh, why should I get this? But I see very clearly I want a free bagel. So, these are different. It's the same thing but different message mixed up, right?

+ +

And then, for me, I see design, like, it happens every day. It's a life skill. For example, like, I saw the challenges, but what if we think another perspective to rethink about what kind of challenge [inaudible 06:38] or reframe the right questions, right? And all this, like, mixed all together, it feels like it's not just about drawing beautiful sketches or rendering sexy, you know, ideas. It's all about, like, how do you frame these challenges? How do you look at this? Can you see the question from social aspect, from cultural aspect, or you just see this as a solution-driven approach?

+ +

JARED: In some cases, I feel, there is an element of subjectivity to the designs, but then we also want to measure the success of a design. Do you have any tips for, like, how you go about putting numbers to what defines success for a particular design?

+ +

SHENG-HUNG: This is such a great question, especially now my research focus is really on services, you know, service design, experience design. Like, how do you quantify this, right? For example, three of us we go to the restaurant, and I feel it's really, really great restaurant. And probably some people feel no, that's not really great. And then, how do we quantify this, right?

+ +

And then, I feel it's sometimes, like, really by personal preferences. It's hard to measure. Maybe there will be some sort of, like, a principle direction or criteria we can follow, so, for example, service quality metrics or something, like, based on people's life experiences. I feel it's hard to measure, especially now the design challenge the question it's really complicated.

+ +

Some people talk about demographic. How do you, like, [inaudible 08:09] design? Like, for example, a participant design process, right? Or, like, inclusiveness. People talk about equity, power, power dynamic. And I think it's less of a measure or quantify. It's more about do you show your respect? Can we be more inclusive in this process? Can we really engage or integrate multiple voices in this design process?

+ +

And I feel like that kind of shows the flexibility, also, the real flexibility of the design, not just that, oh, we look for one single solution. Because, most of the time, we actually want to design for a solution, but, actually, I feel now the shift is from we try to build the condition to let people land on this condition and solve the problem. So, in the end, we'll be like, yeah, we landed here, and we can solve the problem together collectively. So, something I feel a little bit different, but that's a great question. It's open-ended. Yeah.

+ +

JARED: Yeah. Thank you. There's a lot to think about there. I want to bring it back to failure because this is something I think about a lot in terms of teaching and learning from history versus learning from your own failure.

+ +

We have, like, thousands of years of history of failure. You think we have made all the mistakes already, and, oh, it should be easy, right? All we need to do is teach all of the young generation about all of this failure, and then they'll remember not to do it. But in reality, it doesn't really work that way. I find the strength of the argument is oftentimes weak compared to failing yourself and really deeply learning that lesson. I'm curious about your thoughts on that. And then, I'm also curious to hear about some of your, let's call them, best failures.

+ +

SHENG-HUNG: I personally feel like people fail. They fail forward, not backward. So, even if you fail, you move a little bit. It depends on how crazy, right, and how fast you fail. It's an iterative process. The reason I say learning from failure because from traditional Asian family, Asian students, right? Probably in the past, I would say I raised my hand. I want to learn, or I ask senior people. I want to learn. But, actually, more than that, it says, "I want to experience. I want to be part of it," right? So, you're not becoming the manager because you learn to become a...no, you're in that position, and you learn to be a manager.

+ +

So, I learned that mindset when I worked at IDEO. And one of the senior design directors told me, "No, you should say, 'I want to experience.'" So, that means that you have fully immersed experiences. And one of the best examples for me is that the first two years I worked at IDEO and IDEO Asia, supporting projects in Tokyo, Shanghai, Singapore offices, and sometimes European, like, office work; the first two years, my confidence almost collapsed. I have to collect my confidence. It's so hard because I'm eager to learn so many things. I didn't beat myself. And then, after two years, I met an amazing, like, design mentor. And I started the things I'm good at as product designer, a tangible designer. I start as product-focused and thinking about whole design process.

+ +

And then, I start to collect my confidence. And I realized every single project at IDEO or in my life it's a vehicle, you know. And then, you always connect the dots when you're looking backwards. And you realize, oh, this is failure. Let me know what do you mean by client management? What do you mean by, like, teamworking? Because everyone is from so diverse background. And everyone says, "I'm a designer," but they have different interpretation. And how do you communicate it, right? And how do you keep the conversation transparent and also effective, and how do you empower people? And I feel because of that connect the dots process, also, all the things I want to learn, I want to experience it really helps me to grow at the third year or second year in IDEO.

+ +

And that really makes me think about, oh, wow, I didn't know. I failed completely. And that's really healthy, for me, because you become very strong. At some point, I started to realize, oh, what do you mean by...what does it mean by design consultancy business? What we can sell. Where's our capacity, our limitation? You know, other than just, oh, everything's, like, imaginative conceptual. I kind of know what happened, and I know the boundary. And I know how can I empower people and also the client.

+ +

SAMI: Yeah, embracing failure is a real strength. At thoughtbot, we kind of...if we're developing products and we're, let's say, designing or coding, whether websites or applications, we have this concept of failing fast. So, the faster you can fail, the quicker you can iterate towards the right solution. And that's something which is difficult to embrace because the first time you do it, I want this to be perfect, and I want to build it in the way that it works. But, actually, you'll spend a lot of time trying to get towards that perfection, and it's much better to ship faster, fail faster, and then get towards the solution.

+ +

I noticed as well that...well, I read that the one thing you've been recently working on is designed for the aging population, so more specifically, smart homes for the aging populations. Shout out to my parents if they're looking for a smart home. Sorry, mom and dad.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: I've always found, especially my generation, so I'm about...I'm not about; I am 32 years [chuckles] old. So yeah, there's always been, like, a big gap between kind of my generation, the way we've engaged with technology products, the way my parents' generation have been able to. And I imagine a future where my kids are running around in VR headsets, and I'm still, you know, using a basic laptop. I would love to know more about your work kind of in this area and designing for a different sector of the population.

+ +

SHENG-HUNG: My master thesis and my master project is focused on redesigning, like, smart footwear for aging population, and then that's part of the smart home ecosystem. And I was actually impressed and surprised. It's like most of the sponsors or clients we talk about, like, people [inaudible 14:38] to think about just the product level, so smart like [inaudible 14:43], smart like a door, or smart like, you know, like a bed or a smart, like, alarm clock.

+ +

People start to think about how can we integrate all this system together? Because, like, for example, if you bought Amazon, you know, versus Apple and all these different devices, the platform is really a problem because the products cannot communicate with each other. And we want to make sure all the products can communicate and support you, or, like, they can at least receive your data or information to give the appropriate response.

+ +

So, the smart home project starts to think about from ideas to become more like platform integration. IKEA is the best example, right? Like, I think two years ago, they talk about, yeah, they launched their first app, right? Everything is, yeah, it seems like, oh, what's the big deal about this, right? No, but you think of this from the intention perspective to actually connect the whole system together because they want to make sure their internal designer, developer they really can think through their own internal system to make sure everything's connected, interconnected, not just, oh, you do a part of this. We sell this to a certain Asian, and it didn't really connect.

+ +

So, I feel like when we designed it, it's really from the system perspective to talk about a smart home. And then, regarding of, like, design across [inaudible 16:04] generation, that's really important, actually, because especially now I'm focused on design for retirement. And I shifted to design for longevity. And then, the cool thing about this is, like, we think about our life in terms of age, but, actually, now we need to think about our life in terms of different life stages, different lifestyle.

+ +

The book called "Stage (Not Age)", means, like, now we cannot even describe people above 100 years old or 85 years. So, we call them future hood, right? So, like, different life stages. And I feel like that really impacts, as designers, the way we design products or interfaces, right? And it has to evolve with people. When you say, for example, if we have, like, a smart, like, a robot in our home, they have to know your personal routine. And you kind of grow, right? For example, oh, I get older. I move slower, or my mobility is different, and it changes. How does that mean to our product or our smart services?

+ +

And I feel like across different generations, it's really thinking about design for different people in different life stages. And that's really important, not just about financial planning or about your future education, family, community, right? Now people are probably thinking about aging in place. My parents just bought a second home. They're thinking about retirement life. And so, these are things that really impact all aspects of life. And I feel like the idea of one solution for all the era is kind of over because we have to think about not just one solution, multiple solution tailor-made for multiple different people in different life stages.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

JARED: And, Sheng-Hung, in one of your articles that I was reading about design for longevity, you sort of say that design for aging isn't just about designing for older people, but rather, I think one of your colleagues asked this question, which I really liked, which is, how can inclusive methods build elegant design solutions that work for all? And I find that a really aspirational goal.

+ +

But one of the things, say, at thoughtbot, when they're building a product, so we often talk about targeting a specific niche or a specific user base because then we can really optimize for them. And so, you're designing something that's elegant, and that works for all. It doesn't sound very easy. It sounds like a good challenge. And I'm curious about how do you go about that, and do you have any examples you can you can share?

+ +

SHENG-HUNG: Design for all elegantly also seamlessly. Optimize everyone's needs or, like, design process. I feel...because my topic is focused on financial planning, right? And I think about everyone's income level is different. Their investable income asset is also different. We have a different situation, right? Our family issue, the healthcare condition is also different. And I feel like that, also, if we look at this question, we should think about, okay, how do we define design for all, right? Is it universal design, or is it inclusive design?

+ +

I think there are definitely some, like, basic or fundamental, like, foundation or criteria we need to meet. Like, for example, human-centered, right? Or, like, we think about accessibility for certain technology. What's the threshold for a certain way of use the technology or product? That could be, like, a universal or, like, basic. Like I said, people's life stages are so different. And can we really make sure our product or interfaces is always dynamic, always change? Design for transformation, right? And I feel the ideas of changing is kind of scaring for most people. Because you don't want to, like, you woke up, and you realize your iPhone just update the whole interfaces, and you suddenly don't know how to use it [laughs]. It changed too dramatically.

+ +

What I mean by change is like, it's a gradual integration process. And I feel that's kind of beautiful. Like, for example, the way I use my bicycle, the biking, right? They can ultimately adjust my speed, recharging, or understand my personal preferences. That could be something I think is powerful for future for providing the right solution, yeah. But also, it's a benefit of this, but also, there's downsides. Like, maybe because of that, we all live our own personal bubbles pretty well, right? Like, oh, yeah, yeah, I read a newspaper. No, you read the newspaper that I curated for you. So, somehow, the information started different [laughs]. So, there's a gap, but I don't know. It's very cool. It's very great, great question. I think there's still...I don't have the exact same answer, but I feel that could be potential for now. Yeah.

+ +

JARED: Yeah, I really like that. So, it's not just a one-size-fits-all-all, but, like, it's a sort of an elegant transformation over the course of someone's life. We've discussed a few different things like design for longevity. You touched on there, as we were speaking, human-centered design. I know you've made a distinction of humanity-centered design as well, and there's also life-centered design. I wonder if you could give us and our listeners a little rapid-fire explainer of each of them.

+ +

SHENG-HUNG: Like, when we talk about human-centered design, right? Like, it's, like, a buzzword. And everyone talks about HCD, and most people think, oh, if you got a post-it note, you're, like, a HCD designer. No, like, what does that mean, right [laughs]? It's very cliché. And they're like, oh, yeah, all these, like, HCD designers bring the post-it notes with Sharpies and go to facilitate tons of workshops, and they sit and know people. And I feel it's more than that, right?

+ +

Human-centered is really, like, put yourself, designers, in the shoes of clients, users, customers, and participants to know their needs, their desire and address their pain point. And I think for human-centered design like Don Norman said in his latest book, it's not just about design as a discipline. It also covers, like, politics, covers, like, ethical issue, culture. It's broader. And, for me, the simplest version is, like, you design with care. You design with human temperature. We create technology with human temperature. That means that we're now for this technology to [inaudible 23:13] technology. We know why we need that technology.

+ +

So, for example, if you provide the, like, the cell phone to the developing countries, you probably don't want to send, like, the latest cell phone. You want to send them, like, the adequate technology. What I mean by that is like, it's very, like, stereotype, but I'm trying to explain the idea is like, oh, Nokia could be a great option at this point, for example. You can communicate. You don't need, like, crazy, like, AR VR function. You at least can communicate. So, it's adequate. I think that kind of lens is, like, you think about the culture, the needs, economic, social status. And then, you can start to move on and upgrade the devices.

+ +

And I feel like life-centered is even broader. It's like, can you design something to the lens of cats, your pets, your animals? So, it's really like, it's really...it sounds a little bit like a speculative design. But the truth is, like, we can shift our perspective to different kinds of species, cross-species, not just focus on human, because everything we design definitely starts from also for a human being. But now life-centered is like, it's longer, broader. And then, for me, it also means like, we just talk about life-centered. It's like, really think through all different stages of life, not just, like, focus on one single age or a single stage, too specific, too narrow. It's, like, broader.

+ +

So, when we talk about life-centered design, LCD, we really think about a lot of different systems, framework. What's the model we can follow? You know, so we're also thinking about policy, about power dynamic, government, ethical issues. So, this, I think, like, it's broader, and it's really large. Sometimes it's pretty vague, for sure. We have to use some cases or really think about in different contexts. Context is really important, designed for different contextual knowledges and needs.

+ +

SAMI: Yeah, I think that is actually a really helpful understanding. Myself I don't know anything about those concepts, so to kind of get that theoretical understanding and explanation from yourself is really helpful. In a more practical sense, I have a question, which is a very selfish question. The reason it's a selfish question is because I want to know what do you think? When you look at the world through your designer lenses, what do you think is the worst-designed product you've ever seen or come across? And I think I know the answer to this. I think there is a right answer.

+ +

While you have a think, I'll share my answer. I don't know if you have this because you said you're based in Boston at the moment. And I'm showing you because we're on camera, but I will describe it to the listeners as well is what they've done with bottles now is when you open, like, a Coke bottle, for example, all other beverages are available...Coke, if you want to sponsor us [laughter], we're happy just to mention you. When you take the bottle cap off, it's now connected to the top of the bottle.

+ +

So, someone has decided...now, I understand the reason behind it. They're saying that it's for recycling. So, when you throw your bottle away, make sure the cap goes with the bottle. But someone has sat there, and they've designed the bottles. So, when you take off the cap, it's still connected to the top of the bottle. And countless times, I'm either pouring into a cup or pouring into my mouth. And that cap is getting in the way. So, the liquid kind of goes into that cap, and it spills on me, or it spills on the table. This is an absolute design failure, a catastrophe in my eyes. That's my worst design that I've come across in real life. Do you have anything you can think of that you look at, and you're like, who designed this?

+ +

SHENG-HUNG: This is such a great example because I did have similar experiences when I went to Milan Design Week last year. All the plastic bottle is, like, connected. The cap connects with the bottle. And I didn't know that it's on purpose at the very beginning. I thought, how come it's, like, connected? I want to take it out because it's easier for me to drink. And I realized it's not just this one; all of them is the same [laughs]. Yeah, that's a great example.

+ +

I think, for me, design for failure adapter, for example, you know, adapter, like dongle, right? Like, we have so many different...this guy HDMI cable, the cable for iPhone, and the magnet for my Apple MacBook Pro. That's painful because you try to find, like, when you go to, like, a talk or a speech or try to present something, I think, for me, the easiest way is, like, AirPlay, right, Wi-Fi or Bluetooth to connect to the projector. But in reality, you always need this HDMI cable. And this guy connects with my Mac. There's some problem. It depends on...now I always bring my adapter with me.

+ +

It's just like, we have that [inaudible 28:04] like, you know, it almost, like, very frequently, if we're meeting, you have to show your screen. How can we design less physical but it's user-friendly, right? People use Mac. People use Apple, use, like, Microsoft. How do you design something like a universal adaptable to everyones, just sharing screen? This is what I need. So, I think this could be one bad design, I think, at this moment [laughs].

+ +

SAMI: Yeah, that's a great example as well, and so frustrating. And I wonder if it's, like, a money-making scheme, you know, everyone has their own chargers. And that's a way kind of they make some income as well on the side. Jared, what have you seen in the world? What's your pet peeve? What really grinds your gears?

+ +

JARED: This was easy for me. It came to me straight away. Any door that has a handle that you can wrap your hand around which signifies it should be pulled that is push. It's just, I mean, what is going on there? It drives me bonkers.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: That is brilliant. I think it's only fair if we flip the question, right? And then, we say, what's the best thing you've seen designed, right? There must be something out there where you've gone, "Oh, that is so useful. That makes so much sense. Why haven't we done that until now?" And have you kind of...I guess this is for Sheng-Hung, like, have you got any inspiration from that sort of thing?

+ +

SHENG-HUNG: I have to be honest. Like, I really feel like in the past, I'm kind of scared about, like, use your face to unlock your phone. But the more I use it, I feel like, oh my God, this is so convenient. You just look at it. I know it's a bit scary because they have all your biometric data information. I know even you protect under the regular law, but still, I feel like, yeah, it's so seamless connected. And I feel maybe the better answer is like, I feel a great design is, like, to reduce the friction between the transition of devices by devices, right? So, for me, I mean, so interface by interface.

+ +

So, when I share the data on my phone, what does that mean? From phone to my computer or phone to other people, right? All the different interfaces changing. The less friction, the better. I feel seamless connected. So, you know, AirDrop, super convenient, photos, videos with people, Mac users. But what does that mean for, like, Windows users, right? And so, every platform has their own, like, spec, or criteria. And I feel if the user can feel the seamless friction between these interfaces, for me, that could be a great design solution.

+ +

JARED: I love that answer. And I love that description of reducing friction. It reminds me a little bit of, I think, my favorite book on UX is by Steve Krug, which is "Don't Make Me Think." And it's just all about doing the simplest thing, reducing confusion, overcoming objections, and reducing friction. So, I really love that.

+ +

I do have an answer for this one as well. It's a little bit selfish or focused on my own life. So, I have a dog. She's a Welsh Terrier called Rosie. She's just turned one. Whenever we used to go out, you've got to take water for her if it's a hot day. I always used to take a bottle, whether you could unscrew the top or not, I'm not sure, Sami, and, like, a little bowl to put that in, or you use your hands. And, invariably, she's not going to drink all of the water, so you've got waste. You throw that out. The bag gets wet, all of that.

+ +

Someone has designed this really cool bottle where the top is actually the bowl. It's an all-in-one. And you press a button; the water goes into the bowl. She drinks. Whatever's left, you press the button again, turn it upright. And the water just flows back in into the rest of the bottle. It's such a simple thing. But, like you say, it just reduces that friction. Anytime a problem no longer exists, manual to automatic cars, fight me, I'm all for it. Well, that's a problem solved. That's less friction. That's beauty in the world.

+ +

SAMI: Yeah, I think it's amazing. When you think about these examples, it really brings out how much of an impact design has. So, you can have the best product in the world, but if you don't get that frictionless design, or you don't get that design that's going to really bring that improvement, it's going to be difficult to make that product a success.

+ +

And I think there's some, like, when I think about leaders and innovators in this kind of space, so I know you already mentioned IKEA and I think of Apple. And I don't know the answer to this, and maybe our listeners also wonder, like, how do these companies...they seem to keep getting it right. No matter what happens, they seem to set the trends, and they get their design spot-on, and they innovate in that space. How are they so successful in their design?

+ +

SHENG-HUNG: I think a recent example is like, you know, like, Apple just recently launched the Vision Pro, right? The XR, the goggles. And put the demo time 30 minutes to get in-store experiences. You're booking the demo time with them, the 30 minutes. For me, I wrote an article about it. It is less about the goggle itself. It is about the whole experiences.

+ +

The time you enter the store, right, and then you're waiting there, who guiding you? The Genius Bar people guiding you. You sit down. You have the prescription and your glasses that get measured, scan the QR code, and find the match [inaudible 33:35] pair of goggles that fit your [inaudible 33:37] of your face. And they put it on. They sit on the side, use the iPad to guiding you, and tell personal experiences or stories.

+ +

These companies are very design-driven, vision-driven company. They really think about the whole experiences of users, right? And, for me, it's too pricey, for me, the product, obviously, right now. But I have very delightful, positive experiences because of that 30-minute demo. So, I kind of plant the seeds in my heart. Oh, if the second generation or something have discount, I would definitely want to get one for myself. Not really because...it's a great design for sure, but also, the impression I have.

+ +

And I feel that really, really, like, make a difference, right? It's tiny. It's very subtle. They can, "No, we don't have, like, demo experiences." They can just purely sell the product. But I think they sell something bigger than just product. Branding user experiences, delightful experiences. And I can really feel that, and that's really powerful in the end.

+ +

JARED: Do you think that that sort of level of design is limited to the companies that can afford it like the big names? Like, obviously, there is a cost dedicated to having the time and to putting the resources to that. Is it always just going to be the big players, or are there things we can do to democratize that availability for the startups, for the SMEs?

+ +

SHENG-HUNG: I actually think it's about a company's culture. So, another example I would love to share is, like, when we did, like, an inspiration trip in Tokyo, and there's a very famous, like, chain bookstore called Tsutaya bookstore or Tsutaya electrics. So, to my surprise, like, yeah, it's a big bookstore, and we probably think bookstore selling books. No, they're actually selling a lifestyle.

+ +

So, for example, like, if I want to buy the book around how to use a camera, right, the way they curate it, it's like, yeah, we do have the books around camera, but also, we'll put the real camera, like, near the book. So, they curate the whole experiences. You flip the book. Oh, this is so cool. Thanks, I want to try it. You probably, in the end, you got both. So, very interesting and also very human-centered, like, retail experiences.

+ +

Why did I say culture? Because when I entered the store, I asked for one book I was looking for. The staff came to me, and she bring two books to me. One is the book I want, unpack. And one is the book...it's the same book, but without the plastic cover. It's brand new. And why she brought two books to me because if I want to buy this book, I not only read inside, but also, I can just get the new one with me to check out. And this is so subtle, right? Because they're not just bringing you, like, the sample. They also bring the final product with you.

+ +

So, I feel that kind of culture is, like, very strong, customer-centered, think about your needs, think about your next step. So, they kind of plan ahead, and this is so strong message to me. Oh my God, this is such a great design culture, or at least a human-centered culture to think about my needs, my decision-making process. So, I feel connected with that, and I feel like, yes, they have money, but also, like, they really cultivate that culture within the...not just...they also send a message to their customers.

+ +

SAMI: I feel like, Sheng-Hung, we could speak to you for hours. I mean, you are opening my world and my eyes to a different world of design. I've got one final question for you before we wrap up that I wanted to cover. I've seen from your website, like, you've personally designed products. So, out of all the products you've either designed yourself or you've been involved with, what would you say, and could you describe for us your favorite product that you've designed yourself?

+ +

SHENG-HUNG: I think my favorite product is, like, I help and re-design, like, Shanghai Library Innovation Space that, for me, is OMG. Oh my God. It's crazy. Like, one single team, my side project and collaborate with the full staff, librarian, the leadership team. What is powerful is, like, library for them in Shanghai, it's a local hub to connect the community and also to teach, to learn for the younger generation how to use the space. For sure, most people use that space for, like, self-studying, you know, activity and all this stuff. But, for me, like, it's so impactful because every single change that means a lot of impact because it's a public space.

+ +

And also, it's really, really powerful. Like, you think about the decision-making process. You have to think about feasibility, viability, and also desirability, all things to connect together. And it's really hard, not easy process. It took me about a year-long project. And I'm really happy because, in the end, it's really from sketches, concept, prototyping models, all the way they rebuild, modify the design, integrated. And now the new library they build on another area of Shanghai is really based on this model and framework. I'm very happy, and I also feel like, yeah, design can make a positive impact. It's not like a concept. It's real. And it's nice. It's painful, but it's really satisfying, yeah [laughs].

+ +

SAMI: That's really cool when you get to a point where you've done something, and then you see people using what you've designed and, like, enjoying that space and benefiting from all that hard work that you've put into. I have to thank you so much for joining us and giving us time today on the Giant Robots On Tour Series of the Giant Robots Smashing Into Other Giant Robots podcast. Our listeners don't know, but you've had about two hours of sleep.

+ +

SHENG-HUNG: [laughs] Yeah.

+ +

SAMI: So, it's probably time for you to get back into bed yourself. But that is your dedication to us. It's been an incredible episode and an incredible chat. I finally understand why Jared does not like doors. I myself, you will understand if you see me in the street and I'm tearing a bottle cap off of a bottle, you'll understand why. And we need to sort Sheng-Hung out with more adapters with just a single charger for all his devices. If people want to get a hold of you, Sheng-Hung, where's the best place they can reach out after listening to this podcast?

+ +

SHENG-HUNG: Yeah, definitely, you can reach out through my personal website portfolio. Yeah, shenghunglee.com. And I'm happy to respond and discuss about design-related topic. Thanks for having me on this podcast. It's very exciting, and hope we can create all the great stuff for our society.

+ +

SAMI: Pleasure. There's always a challenge I give to my listeners at the end, and it normally is just please hit that subscribe button. Jared has promised me that he will do a shoey if we can double our subscribers by the end of the series. If you don't know what a shoey is, my only advice to you is do not Google it because you do not want to know.

+ +

You can find notes and a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See ya.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Giant Robots On Tour Hosts Sami Birnbaum and Jared Turner introduce Sheng-Hung Lee, a designer, PhD researcher at MIT AgeLab, and board director at the Industrial Designers Society of America. Sheng-Hung shares his journey into design and engineering, emphasizing the importance of interpreting signals in design and the evolving role of designers from problem-solvers to culture shapers. He discusses how designers must now consider broader, systematic issues such as climate change and aging. Sheng-Hung explains that design is a teachable and essential life skill, highlighting the significance of personal experiences and failures in learning design. He elaborates on the concept of signals, explaining that they represent different perspectives and interpretations in design, which are crucial in addressing complex problems.

+ +

The conversation shifts to practical design applications and Sheng-Hung's work in smart homes for aging populations. He discusses the integration of various smart systems and the importance of designing for different life stages rather than specific age groups. Jared and Sami also engage Sheng-Hung in discussing the worst and best-designed products, where Sheng-Hung mentions his initial skepticism but eventual appreciation for facial recognition technology.

+ + + +

Transcript:

+ +

 SAMI: Hello again, and this is The Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots On Tour Series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Sami Birnbaum.

+ +

JARED: And I'm your other host, Jared Turner.

+ +

SAMI: If you are wondering, which you might have been for a while now, where are Will or Victoria, well, make sure you find one of our previous podcasts where we introduce the Giant Robots on Tour Series, and you'll understand why you're hearing myself and Jared a little bit more frequently than before. In that podcast, we throw random icebreakers at each other, and we find out that Svenja does not like online banking. And if you haven't listened to our previous podcast with our guest, Ishani, check that out as quick as you can and find out why AI is compared to babies.

+ +

Joining us today is Sheng-Hung Lee, a Designer and PhD Researcher at MIT AgeLab and Board Director at the Industrial Designers Society of America. Sheng-Hung, I'm going to level with you. I've done my research. I've done my due diligence on the guests that we have on this podcast, and I'm exhausted.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: I've looked through your own website, and I've read as much as I can find about you. And between education, experience, awards, scholarships, there is an incredible amount of things that you're involved in that you get up to. And it really wasn't good for my own self-esteem just to see how much you have going on.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: Jared, a question for you first. Bear in mind, the only thing I've ever been awarded is my own driving license. So, our guest, Sheng-Hung, how many awards do you think he has currently listed on his website? Give a guess.

+ +

JARED: Oh gosh, I remember looking at the page, and I remember having to scroll.

+ +

SAMI: [laughs] Yeah, you had to scroll.

+ +

JARED: Let's pick 33.

+ +

SAMI: 33. Do you know what? It's not even close. Okay, he's nearly double that. So, he's up at 60 awards that are currently listed. So, we're talking about a guest that you guys do not want to miss. And you want to make sure that you get into this conversation. I always like to go back to the start with my guests. So, everyone has a story. And I'm interested, Sheng-Hung, in your journey and what led you into the world of design and engineering.

+ +

SHENG-HUNG: My personal definition of design is, like, decoding signals. So, everything in our lives, like, we have different types of signals. How do we interpret the signal? How do we, like, understand, or perceive different types of signals in our lives? And I feel design is more like...not just creation. It is creation, for sure, but also about curation. I feel like, for me, problem-solving or, like, problem-defining is really interesting. And especially you mentioned, like, my very early stage as a designer, the reason I submitted my work to get an award is because I want to show my problem-solving skill.

+ +

And I realize nowadays, like, the problem is too complicated. It's not just about solving problems, right? I mean, I feel design is more bigger than that, especially now most of the problems are systematic and complex. Climate change, right? Like, you think about aging, and you think about all this, like, sustainable issues. I feel like designers, like, for me, starting from problem solver, as engineer, and now more I've become like a translator, curator, or even, like, a culture shaper. How do you shape the culture you want, right?

+ +

Especially now, like, AI it's just, like...that really let me rethink about my role as designer, you know, because everyone can have tons of ideas, but the truth is, like, we have so many ideas, but do you know what good taste is about? Do you know what the good qualities of life's about? So, you have to have some personal experiences to really help people to understand or curate the vision in the future.

+ +

SAMI: That's really interesting. I struggle to dress my kids in the morning from a design perspective, right? I don't get colors, and I don't understand necessarily how they match and how to get things working. In fact, sometimes I'll dress my kids only to find that my wife has redressed the kids. Things are that bad at home.

+ +

Do you think then design is something which can be taught, or is it something, like, innate? Is it something, in your own experiences, that it's kind of part of your nature? So, you see the world differently to someone like myself or Jared sees the world. Or could that be something which we could pick up on, you know, and learn about?

+ +

SHENG-HUNG: Yeah, I definitely think design can be teachable. It's skillable. And I feel like, yeah, people talk about this is, like, a hardcore skill. It's a soft skill. No, I think design is a life skill. It's a human skill. So, that includes like, for example, like, yeah, how do you choose the color? How do you choose the clothes for kids? But also about, like, how do you celebrate the quality of lives, right? How do you, like, have better, like, qualities?

+ +

And I feel like, I don't know, life skill means, like, team building, creative leadership, knows people, listening to people. And, for me, that's part of design because you're decoding different signals. You understand your life. You perceive different types of noises. Or how do you resonate with other people? And that's a life skill, I think. And I also feel most of the design skills I learned is actually not from school. It's from, like, personal life failure [laughs].

+ +

SAMI: That's really interesting. I just want to jump in because I don't know if I fully understand what you mean by signals. Can you just elaborate on that a little bit more? And then, I will bring you back up on personal failures.

+ +

SHENG-HUNG: Signal is like different ways of seeing things, right? So, for example, like, if I go to wait in line for a free bagel, right? You share this with your friends. What I see is it's a free bagel. But what my friends see is like, oh, probably, like, I don't need to wait in line and so many challenges. You know, I have to, like, oh, why should I get this? But I see very clearly I want a free bagel. So, these are different. It's the same thing but different message mixed up, right?

+ +

And then, for me, I see design, like, it happens every day. It's a life skill. For example, like, I saw the challenges, but what if we think another perspective to rethink about what kind of challenge [inaudible 06:38] or reframe the right questions, right? And all this, like, mixed all together, it feels like it's not just about drawing beautiful sketches or rendering sexy, you know, ideas. It's all about, like, how do you frame these challenges? How do you look at this? Can you see the question from social aspect, from cultural aspect, or you just see this as a solution-driven approach?

+ +

JARED: In some cases, I feel, there is an element of subjectivity to the designs, but then we also want to measure the success of a design. Do you have any tips for, like, how you go about putting numbers to what defines success for a particular design?

+ +

SHENG-HUNG: This is such a great question, especially now my research focus is really on services, you know, service design, experience design. Like, how do you quantify this, right? For example, three of us we go to the restaurant, and I feel it's really, really great restaurant. And probably some people feel no, that's not really great. And then, how do we quantify this, right?

+ +

And then, I feel it's sometimes, like, really by personal preferences. It's hard to measure. Maybe there will be some sort of, like, a principle direction or criteria we can follow, so, for example, service quality metrics or something, like, based on people's life experiences. I feel it's hard to measure, especially now the design challenge the question it's really complicated.

+ +

Some people talk about demographic. How do you, like, [inaudible 08:09] design? Like, for example, a participant design process, right? Or, like, inclusiveness. People talk about equity, power, power dynamic. And I think it's less of a measure or quantify. It's more about do you show your respect? Can we be more inclusive in this process? Can we really engage or integrate multiple voices in this design process?

+ +

And I feel like that kind of shows the flexibility, also, the real flexibility of the design, not just that, oh, we look for one single solution. Because, most of the time, we actually want to design for a solution, but, actually, I feel now the shift is from we try to build the condition to let people land on this condition and solve the problem. So, in the end, we'll be like, yeah, we landed here, and we can solve the problem together collectively. So, something I feel a little bit different, but that's a great question. It's open-ended. Yeah.

+ +

JARED: Yeah. Thank you. There's a lot to think about there. I want to bring it back to failure because this is something I think about a lot in terms of teaching and learning from history versus learning from your own failure.

+ +

We have, like, thousands of years of history of failure. You think we have made all the mistakes already, and, oh, it should be easy, right? All we need to do is teach all of the young generation about all of this failure, and then they'll remember not to do it. But in reality, it doesn't really work that way. I find the strength of the argument is oftentimes weak compared to failing yourself and really deeply learning that lesson. I'm curious about your thoughts on that. And then, I'm also curious to hear about some of your, let's call them, best failures.

+ +

SHENG-HUNG: I personally feel like people fail. They fail forward, not backward. So, even if you fail, you move a little bit. It depends on how crazy, right, and how fast you fail. It's an iterative process. The reason I say learning from failure because from traditional Asian family, Asian students, right? Probably in the past, I would say I raised my hand. I want to learn, or I ask senior people. I want to learn. But, actually, more than that, it says, "I want to experience. I want to be part of it," right? So, you're not becoming the manager because you learn to become a...no, you're in that position, and you learn to be a manager.

+ +

So, I learned that mindset when I worked at IDEO. And one of the senior design directors told me, "No, you should say, 'I want to experience.'" So, that means that you have fully immersed experiences. And one of the best examples for me is that the first two years I worked at IDEO and IDEO Asia, supporting projects in Tokyo, Shanghai, Singapore offices, and sometimes European, like, office work; the first two years, my confidence almost collapsed. I have to collect my confidence. It's so hard because I'm eager to learn so many things. I didn't beat myself. And then, after two years, I met an amazing, like, design mentor. And I started the things I'm good at as product designer, a tangible designer. I start as product-focused and thinking about whole design process.

+ +

And then, I start to collect my confidence. And I realized every single project at IDEO or in my life it's a vehicle, you know. And then, you always connect the dots when you're looking backwards. And you realize, oh, this is failure. Let me know what do you mean by client management? What do you mean by, like, teamworking? Because everyone is from so diverse background. And everyone says, "I'm a designer," but they have different interpretation. And how do you communicate it, right? And how do you keep the conversation transparent and also effective, and how do you empower people? And I feel because of that connect the dots process, also, all the things I want to learn, I want to experience it really helps me to grow at the third year or second year in IDEO.

+ +

And that really makes me think about, oh, wow, I didn't know. I failed completely. And that's really healthy, for me, because you become very strong. At some point, I started to realize, oh, what do you mean by...what does it mean by design consultancy business? What we can sell. Where's our capacity, our limitation? You know, other than just, oh, everything's, like, imaginative conceptual. I kind of know what happened, and I know the boundary. And I know how can I empower people and also the client.

+ +

SAMI: Yeah, embracing failure is a real strength. At thoughtbot, we kind of...if we're developing products and we're, let's say, designing or coding, whether websites or applications, we have this concept of failing fast. So, the faster you can fail, the quicker you can iterate towards the right solution. And that's something which is difficult to embrace because the first time you do it, I want this to be perfect, and I want to build it in the way that it works. But, actually, you'll spend a lot of time trying to get towards that perfection, and it's much better to ship faster, fail faster, and then get towards the solution.

+ +

I noticed as well that...well, I read that the one thing you've been recently working on is designed for the aging population, so more specifically, smart homes for the aging populations. Shout out to my parents if they're looking for a smart home. Sorry, mom and dad.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: I've always found, especially my generation, so I'm about...I'm not about; I am 32 years [chuckles] old. So yeah, there's always been, like, a big gap between kind of my generation, the way we've engaged with technology products, the way my parents' generation have been able to. And I imagine a future where my kids are running around in VR headsets, and I'm still, you know, using a basic laptop. I would love to know more about your work kind of in this area and designing for a different sector of the population.

+ +

SHENG-HUNG: My master thesis and my master project is focused on redesigning, like, smart footwear for aging population, and then that's part of the smart home ecosystem. And I was actually impressed and surprised. It's like most of the sponsors or clients we talk about, like, people [inaudible 14:38] to think about just the product level, so smart like [inaudible 14:43], smart like a door, or smart like, you know, like a bed or a smart, like, alarm clock.

+ +

People start to think about how can we integrate all this system together? Because, like, for example, if you bought Amazon, you know, versus Apple and all these different devices, the platform is really a problem because the products cannot communicate with each other. And we want to make sure all the products can communicate and support you, or, like, they can at least receive your data or information to give the appropriate response.

+ +

So, the smart home project starts to think about from ideas to become more like platform integration. IKEA is the best example, right? Like, I think two years ago, they talk about, yeah, they launched their first app, right? Everything is, yeah, it seems like, oh, what's the big deal about this, right? No, but you think of this from the intention perspective to actually connect the whole system together because they want to make sure their internal designer, developer they really can think through their own internal system to make sure everything's connected, interconnected, not just, oh, you do a part of this. We sell this to a certain Asian, and it didn't really connect.

+ +

So, I feel like when we designed it, it's really from the system perspective to talk about a smart home. And then, regarding of, like, design across [inaudible 16:04] generation, that's really important, actually, because especially now I'm focused on design for retirement. And I shifted to design for longevity. And then, the cool thing about this is, like, we think about our life in terms of age, but, actually, now we need to think about our life in terms of different life stages, different lifestyle.

+ +

The book called "Stage (Not Age)", means, like, now we cannot even describe people above 100 years old or 85 years. So, we call them future hood, right? So, like, different life stages. And I feel like that really impacts, as designers, the way we design products or interfaces, right? And it has to evolve with people. When you say, for example, if we have, like, a smart, like, a robot in our home, they have to know your personal routine. And you kind of grow, right? For example, oh, I get older. I move slower, or my mobility is different, and it changes. How does that mean to our product or our smart services?

+ +

And I feel like across different generations, it's really thinking about design for different people in different life stages. And that's really important, not just about financial planning or about your future education, family, community, right? Now people are probably thinking about aging in place. My parents just bought a second home. They're thinking about retirement life. And so, these are things that really impact all aspects of life. And I feel like the idea of one solution for all the era is kind of over because we have to think about not just one solution, multiple solution tailor-made for multiple different people in different life stages.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

JARED: And, Sheng-Hung, in one of your articles that I was reading about design for longevity, you sort of say that design for aging isn't just about designing for older people, but rather, I think one of your colleagues asked this question, which I really liked, which is, how can inclusive methods build elegant design solutions that work for all? And I find that a really aspirational goal.

+ +

But one of the things, say, at thoughtbot, when they're building a product, so we often talk about targeting a specific niche or a specific user base because then we can really optimize for them. And so, you're designing something that's elegant, and that works for all. It doesn't sound very easy. It sounds like a good challenge. And I'm curious about how do you go about that, and do you have any examples you can you can share?

+ +

SHENG-HUNG: Design for all elegantly also seamlessly. Optimize everyone's needs or, like, design process. I feel...because my topic is focused on financial planning, right? And I think about everyone's income level is different. Their investable income asset is also different. We have a different situation, right? Our family issue, the healthcare condition is also different. And I feel like that, also, if we look at this question, we should think about, okay, how do we define design for all, right? Is it universal design, or is it inclusive design?

+ +

I think there are definitely some, like, basic or fundamental, like, foundation or criteria we need to meet. Like, for example, human-centered, right? Or, like, we think about accessibility for certain technology. What's the threshold for a certain way of use the technology or product? That could be, like, a universal or, like, basic. Like I said, people's life stages are so different. And can we really make sure our product or interfaces is always dynamic, always change? Design for transformation, right? And I feel the ideas of changing is kind of scaring for most people. Because you don't want to, like, you woke up, and you realize your iPhone just update the whole interfaces, and you suddenly don't know how to use it [laughs]. It changed too dramatically.

+ +

What I mean by change is like, it's a gradual integration process. And I feel that's kind of beautiful. Like, for example, the way I use my bicycle, the biking, right? They can ultimately adjust my speed, recharging, or understand my personal preferences. That could be something I think is powerful for future for providing the right solution, yeah. But also, it's a benefit of this, but also, there's downsides. Like, maybe because of that, we all live our own personal bubbles pretty well, right? Like, oh, yeah, yeah, I read a newspaper. No, you read the newspaper that I curated for you. So, somehow, the information started different [laughs]. So, there's a gap, but I don't know. It's very cool. It's very great, great question. I think there's still...I don't have the exact same answer, but I feel that could be potential for now. Yeah.

+ +

JARED: Yeah, I really like that. So, it's not just a one-size-fits-all-all, but, like, it's a sort of an elegant transformation over the course of someone's life. We've discussed a few different things like design for longevity. You touched on there, as we were speaking, human-centered design. I know you've made a distinction of humanity-centered design as well, and there's also life-centered design. I wonder if you could give us and our listeners a little rapid-fire explainer of each of them.

+ +

SHENG-HUNG: Like, when we talk about human-centered design, right? Like, it's, like, a buzzword. And everyone talks about HCD, and most people think, oh, if you got a post-it note, you're, like, a HCD designer. No, like, what does that mean, right [laughs]? It's very cliché. And they're like, oh, yeah, all these, like, HCD designers bring the post-it notes with Sharpies and go to facilitate tons of workshops, and they sit and know people. And I feel it's more than that, right?

+ +

Human-centered is really, like, put yourself, designers, in the shoes of clients, users, customers, and participants to know their needs, their desire and address their pain point. And I think for human-centered design like Don Norman said in his latest book, it's not just about design as a discipline. It also covers, like, politics, covers, like, ethical issue, culture. It's broader. And, for me, the simplest version is, like, you design with care. You design with human temperature. We create technology with human temperature. That means that we're now for this technology to [inaudible 23:13] technology. We know why we need that technology.

+ +

So, for example, if you provide the, like, the cell phone to the developing countries, you probably don't want to send, like, the latest cell phone. You want to send them, like, the adequate technology. What I mean by that is like, it's very, like, stereotype, but I'm trying to explain the idea is like, oh, Nokia could be a great option at this point, for example. You can communicate. You don't need, like, crazy, like, AR VR function. You at least can communicate. So, it's adequate. I think that kind of lens is, like, you think about the culture, the needs, economic, social status. And then, you can start to move on and upgrade the devices.

+ +

And I feel like life-centered is even broader. It's like, can you design something to the lens of cats, your pets, your animals? So, it's really like, it's really...it sounds a little bit like a speculative design. But the truth is, like, we can shift our perspective to different kinds of species, cross-species, not just focus on human, because everything we design definitely starts from also for a human being. But now life-centered is like, it's longer, broader. And then, for me, it also means like, we just talk about life-centered. It's like, really think through all different stages of life, not just, like, focus on one single age or a single stage, too specific, too narrow. It's, like, broader.

+ +

So, when we talk about life-centered design, LCD, we really think about a lot of different systems, framework. What's the model we can follow? You know, so we're also thinking about policy, about power dynamic, government, ethical issues. So, this, I think, like, it's broader, and it's really large. Sometimes it's pretty vague, for sure. We have to use some cases or really think about in different contexts. Context is really important, designed for different contextual knowledges and needs.

+ +

SAMI: Yeah, I think that is actually a really helpful understanding. Myself I don't know anything about those concepts, so to kind of get that theoretical understanding and explanation from yourself is really helpful. In a more practical sense, I have a question, which is a very selfish question. The reason it's a selfish question is because I want to know what do you think? When you look at the world through your designer lenses, what do you think is the worst-designed product you've ever seen or come across? And I think I know the answer to this. I think there is a right answer.

+ +

While you have a think, I'll share my answer. I don't know if you have this because you said you're based in Boston at the moment. And I'm showing you because we're on camera, but I will describe it to the listeners as well is what they've done with bottles now is when you open, like, a Coke bottle, for example, all other beverages are available...Coke, if you want to sponsor us [laughter], we're happy just to mention you. When you take the bottle cap off, it's now connected to the top of the bottle.

+ +

So, someone has decided...now, I understand the reason behind it. They're saying that it's for recycling. So, when you throw your bottle away, make sure the cap goes with the bottle. But someone has sat there, and they've designed the bottles. So, when you take off the cap, it's still connected to the top of the bottle. And countless times, I'm either pouring into a cup or pouring into my mouth. And that cap is getting in the way. So, the liquid kind of goes into that cap, and it spills on me, or it spills on the table. This is an absolute design failure, a catastrophe in my eyes. That's my worst design that I've come across in real life. Do you have anything you can think of that you look at, and you're like, who designed this?

+ +

SHENG-HUNG: This is such a great example because I did have similar experiences when I went to Milan Design Week last year. All the plastic bottle is, like, connected. The cap connects with the bottle. And I didn't know that it's on purpose at the very beginning. I thought, how come it's, like, connected? I want to take it out because it's easier for me to drink. And I realized it's not just this one; all of them is the same [laughs]. Yeah, that's a great example.

+ +

I think, for me, design for failure adapter, for example, you know, adapter, like dongle, right? Like, we have so many different...this guy HDMI cable, the cable for iPhone, and the magnet for my Apple MacBook Pro. That's painful because you try to find, like, when you go to, like, a talk or a speech or try to present something, I think, for me, the easiest way is, like, AirPlay, right, Wi-Fi or Bluetooth to connect to the projector. But in reality, you always need this HDMI cable. And this guy connects with my Mac. There's some problem. It depends on...now I always bring my adapter with me.

+ +

It's just like, we have that [inaudible 28:04] like, you know, it almost, like, very frequently, if we're meeting, you have to show your screen. How can we design less physical but it's user-friendly, right? People use Mac. People use Apple, use, like, Microsoft. How do you design something like a universal adaptable to everyones, just sharing screen? This is what I need. So, I think this could be one bad design, I think, at this moment [laughs].

+ +

SAMI: Yeah, that's a great example as well, and so frustrating. And I wonder if it's, like, a money-making scheme, you know, everyone has their own chargers. And that's a way kind of they make some income as well on the side. Jared, what have you seen in the world? What's your pet peeve? What really grinds your gears?

+ +

JARED: This was easy for me. It came to me straight away. Any door that has a handle that you can wrap your hand around which signifies it should be pulled that is push. It's just, I mean, what is going on there? It drives me bonkers.

+ +

SHENG-HUNG: [laughs]

+ +

SAMI: That is brilliant. I think it's only fair if we flip the question, right? And then, we say, what's the best thing you've seen designed, right? There must be something out there where you've gone, "Oh, that is so useful. That makes so much sense. Why haven't we done that until now?" And have you kind of...I guess this is for Sheng-Hung, like, have you got any inspiration from that sort of thing?

+ +

SHENG-HUNG: I have to be honest. Like, I really feel like in the past, I'm kind of scared about, like, use your face to unlock your phone. But the more I use it, I feel like, oh my God, this is so convenient. You just look at it. I know it's a bit scary because they have all your biometric data information. I know even you protect under the regular law, but still, I feel like, yeah, it's so seamless connected. And I feel maybe the better answer is like, I feel a great design is, like, to reduce the friction between the transition of devices by devices, right? So, for me, I mean, so interface by interface.

+ +

So, when I share the data on my phone, what does that mean? From phone to my computer or phone to other people, right? All the different interfaces changing. The less friction, the better. I feel seamless connected. So, you know, AirDrop, super convenient, photos, videos with people, Mac users. But what does that mean for, like, Windows users, right? And so, every platform has their own, like, spec, or criteria. And I feel if the user can feel the seamless friction between these interfaces, for me, that could be a great design solution.

+ +

JARED: I love that answer. And I love that description of reducing friction. It reminds me a little bit of, I think, my favorite book on UX is by Steve Krug, which is "Don't Make Me Think." And it's just all about doing the simplest thing, reducing confusion, overcoming objections, and reducing friction. So, I really love that.

+ +

I do have an answer for this one as well. It's a little bit selfish or focused on my own life. So, I have a dog. She's a Welsh Terrier called Rosie. She's just turned one. Whenever we used to go out, you've got to take water for her if it's a hot day. I always used to take a bottle, whether you could unscrew the top or not, I'm not sure, Sami, and, like, a little bowl to put that in, or you use your hands. And, invariably, she's not going to drink all of the water, so you've got waste. You throw that out. The bag gets wet, all of that.

+ +

Someone has designed this really cool bottle where the top is actually the bowl. It's an all-in-one. And you press a button; the water goes into the bowl. She drinks. Whatever's left, you press the button again, turn it upright. And the water just flows back in into the rest of the bottle. It's such a simple thing. But, like you say, it just reduces that friction. Anytime a problem no longer exists, manual to automatic cars, fight me, I'm all for it. Well, that's a problem solved. That's less friction. That's beauty in the world.

+ +

SAMI: Yeah, I think it's amazing. When you think about these examples, it really brings out how much of an impact design has. So, you can have the best product in the world, but if you don't get that frictionless design, or you don't get that design that's going to really bring that improvement, it's going to be difficult to make that product a success.

+ +

And I think there's some, like, when I think about leaders and innovators in this kind of space, so I know you already mentioned IKEA and I think of Apple. And I don't know the answer to this, and maybe our listeners also wonder, like, how do these companies...they seem to keep getting it right. No matter what happens, they seem to set the trends, and they get their design spot-on, and they innovate in that space. How are they so successful in their design?

+ +

SHENG-HUNG: I think a recent example is like, you know, like, Apple just recently launched the Vision Pro, right? The XR, the goggles. And put the demo time 30 minutes to get in-store experiences. You're booking the demo time with them, the 30 minutes. For me, I wrote an article about it. It is less about the goggle itself. It is about the whole experiences.

+ +

The time you enter the store, right, and then you're waiting there, who guiding you? The Genius Bar people guiding you. You sit down. You have the prescription and your glasses that get measured, scan the QR code, and find the match [inaudible 33:35] pair of goggles that fit your [inaudible 33:37] of your face. And they put it on. They sit on the side, use the iPad to guiding you, and tell personal experiences or stories.

+ +

These companies are very design-driven, vision-driven company. They really think about the whole experiences of users, right? And, for me, it's too pricey, for me, the product, obviously, right now. But I have very delightful, positive experiences because of that 30-minute demo. So, I kind of plant the seeds in my heart. Oh, if the second generation or something have discount, I would definitely want to get one for myself. Not really because...it's a great design for sure, but also, the impression I have.

+ +

And I feel that really, really, like, make a difference, right? It's tiny. It's very subtle. They can, "No, we don't have, like, demo experiences." They can just purely sell the product. But I think they sell something bigger than just product. Branding user experiences, delightful experiences. And I can really feel that, and that's really powerful in the end.

+ +

JARED: Do you think that that sort of level of design is limited to the companies that can afford it like the big names? Like, obviously, there is a cost dedicated to having the time and to putting the resources to that. Is it always just going to be the big players, or are there things we can do to democratize that availability for the startups, for the SMEs?

+ +

SHENG-HUNG: I actually think it's about a company's culture. So, another example I would love to share is, like, when we did, like, an inspiration trip in Tokyo, and there's a very famous, like, chain bookstore called Tsutaya bookstore or Tsutaya electrics. So, to my surprise, like, yeah, it's a big bookstore, and we probably think bookstore selling books. No, they're actually selling a lifestyle.

+ +

So, for example, like, if I want to buy the book around how to use a camera, right, the way they curate it, it's like, yeah, we do have the books around camera, but also, we'll put the real camera, like, near the book. So, they curate the whole experiences. You flip the book. Oh, this is so cool. Thanks, I want to try it. You probably, in the end, you got both. So, very interesting and also very human-centered, like, retail experiences.

+ +

Why did I say culture? Because when I entered the store, I asked for one book I was looking for. The staff came to me, and she bring two books to me. One is the book I want, unpack. And one is the book...it's the same book, but without the plastic cover. It's brand new. And why she brought two books to me because if I want to buy this book, I not only read inside, but also, I can just get the new one with me to check out. And this is so subtle, right? Because they're not just bringing you, like, the sample. They also bring the final product with you.

+ +

So, I feel that kind of culture is, like, very strong, customer-centered, think about your needs, think about your next step. So, they kind of plan ahead, and this is so strong message to me. Oh my God, this is such a great design culture, or at least a human-centered culture to think about my needs, my decision-making process. So, I feel connected with that, and I feel like, yes, they have money, but also, like, they really cultivate that culture within the...not just...they also send a message to their customers.

+ +

SAMI: I feel like, Sheng-Hung, we could speak to you for hours. I mean, you are opening my world and my eyes to a different world of design. I've got one final question for you before we wrap up that I wanted to cover. I've seen from your website, like, you've personally designed products. So, out of all the products you've either designed yourself or you've been involved with, what would you say, and could you describe for us your favorite product that you've designed yourself?

+ +

SHENG-HUNG: I think my favorite product is, like, I help and re-design, like, Shanghai Library Innovation Space that, for me, is OMG. Oh my God. It's crazy. Like, one single team, my side project and collaborate with the full staff, librarian, the leadership team. What is powerful is, like, library for them in Shanghai, it's a local hub to connect the community and also to teach, to learn for the younger generation how to use the space. For sure, most people use that space for, like, self-studying, you know, activity and all this stuff. But, for me, like, it's so impactful because every single change that means a lot of impact because it's a public space.

+ +

And also, it's really, really powerful. Like, you think about the decision-making process. You have to think about feasibility, viability, and also desirability, all things to connect together. And it's really hard, not easy process. It took me about a year-long project. And I'm really happy because, in the end, it's really from sketches, concept, prototyping models, all the way they rebuild, modify the design, integrated. And now the new library they build on another area of Shanghai is really based on this model and framework. I'm very happy, and I also feel like, yeah, design can make a positive impact. It's not like a concept. It's real. And it's nice. It's painful, but it's really satisfying, yeah [laughs].

+ +

SAMI: That's really cool when you get to a point where you've done something, and then you see people using what you've designed and, like, enjoying that space and benefiting from all that hard work that you've put into. I have to thank you so much for joining us and giving us time today on the Giant Robots On Tour Series of the Giant Robots Smashing Into Other Giant Robots podcast. Our listeners don't know, but you've had about two hours of sleep.

+ +

SHENG-HUNG: [laughs] Yeah.

+ +

SAMI: So, it's probably time for you to get back into bed yourself. But that is your dedication to us. It's been an incredible episode and an incredible chat. I finally understand why Jared does not like doors. I myself, you will understand if you see me in the street and I'm tearing a bottle cap off of a bottle, you'll understand why. And we need to sort Sheng-Hung out with more adapters with just a single charger for all his devices. If people want to get a hold of you, Sheng-Hung, where's the best place they can reach out after listening to this podcast?

+ +

SHENG-HUNG: Yeah, definitely, you can reach out through my personal website portfolio. Yeah, shenghunglee.com. And I'm happy to respond and discuss about design-related topic. Thanks for having me on this podcast. It's very exciting, and hope we can create all the great stuff for our society.

+ +

SAMI: Pleasure. There's always a challenge I give to my listeners at the end, and it normally is just please hit that subscribe button. Jared has promised me that he will do a shoey if we can double our subscribers by the end of the series. If you don't know what a shoey is, my only advice to you is do not Google it because you do not want to know.

+ +

You can find notes and a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See ya.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cPtCOsdB + + ]]> + + + + 538: Transforming Therapy with Gaming: How MindJam Supports Young Minds + https://podcast.thoughtbot.com/538 + 6023d59e-0065-495c-9447-5e0233b3499d + Thu, 15 Aug 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + In this episode of "Giant Robots On Tour," Sami Birnbaum and Rémy Hannequin interview Dan Clark, Founder and CEO of MindJam, which provides emotional and Special Educational Needs support for young people through gaming. Dan shares how MindJam began during the pandemic to help neurodivergent youth using games like Minecraft, emphasizing gaming's benefits for cognitive and social development. MindJam has grown significantly, now supporting over 2,000 young people globally with 110 mentors. + 43:26 + no + + + In this episode of the "Giant Robots On Tour" podcast, hosts Sami Birnbaum and Rémy Hannequin interview Dan Clark, the Founder and CEO of MindJam, an innovative platform providing emotional and SEN (Special Educational Needs) support for young people through gaming, game design, and digital skills. Sami shares a personal story about how his mother, an educational psychologist, introduced him to MindJam, highlighting its impact and relevance. Dan explains that MindJam was born out of the need to support young people who feel out of place in traditional educational settings, particularly those with ADHD, autism, and other neurodivergent conditions. By leveraging popular games like Minecraft, MindJam builds trust and engages young people in a medium they enjoy, transforming therapeutic support into a more effective and engaging process. +Dan discusses the inception and growth of MindJam, which started during the pandemic when traditional in-person support became impossible. This shift to online sessions via gaming platforms provided a new avenue to connect with young people, enabling them to open up and build trust in a familiar and enjoyable environment. Dan emphasizes that gaming offers numerous benefits, such as enhancing cognitive abilities, fostering social connections, and providing a safe space for expression. Despite the negative stigma around gaming, he points out that it can be a powerful tool for personal development and emotional support. MindJam has grown significantly, now with 110 mentors supporting over 2,000 young people globally, showcasing the scalability and effectiveness of this approach. +The conversation also touches on the broader implications and challenges of integrating gaming into therapeutic and educational contexts. Dan highlights the need for societal perception shifts to recognize the positive aspects of gaming, counteracting the negative media portrayal. He underscores the importance of educating parents, educators, and social services about the benefits of gaming and how it can be used constructively. Dan shares inspiring success stories from MindJam, illustrating how gaming can lead to real-world achievements and personal growth. +MindJam (https://mindjam.org.uk/) +Follw MindJam on Facebook (https://www.facebook.com/MindJamOfficial), LinkedIn (https://www.linkedin.com/company/mindjam/), or Instagram (https://www.instagram.com/mindjamofficial/). +Follow Dan Clark on LinkedIn (https://www.linkedin.com/in/dan-clark-58533220b/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: + SAMI: Right, we are back again. And this is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host Sami Birnbaum. +RÉMY: And I'm your other host, Rémy Hannequin. +SAMI: Let's get into it, Rémy. Joining us today is Dan Clark, the Founder and CEO of MindJam, a platform that provides online one-to-one sessions, providing emotional and SEN support for young people through gaming, game design, and digital skills. +Dan, full disclosure on this one: so, about a month ago, right? I get an email from my mom. Now [laughs], this email says, "You've got to check this guy out. Go and take a look at MindJam." And I'm thinking, mom, I don't get these emails from you. This is not the normal sort of thing I'd get from my mom on your average weekday. And I know in the past, like, I've told her that I'm kind of doing this podcast thing, and I'm starting to regret, like, telling her this. Like, what is she throwing my way? +But I get into some research...and maybe for some context, actually, which is helpful because my mom isn't just doing research for the podcast, my mom's an educational psychologist. So, she's been doing that ever since I can remember. I remember growing up as a kid, and that was, I mean, she assessed me numerous times. And she works, I guess, similar kind of to the children or people that you're working with, people with ADHD, autism, neurodivergent children, just often who are struggling in school and trying to find where they fit. +And I start doing my research. I look into it, hit the website, hit your LinkedIn. And I'll be, like, totally honest with you: We were both just blown away by what you are doing. And this is coming not only from me, and I work in the tech industry, and I've got a history of slight gaming addictions, which we might touch on, but also coming from my mom who works on the other side and works with all the local authorities. She does the kind of tribunals that they have to do to try and get people into the right schools and kids into the right schools. +And, literally, we were blown away, and I nearly got lost as well on your website. I found some kind of gaming streams that you do, and I feel almost like we missed a trick here, Rémy, because we could have done this podcast on Minecraft. It's such a nice flow, right, when you're streaming. +DAN: Yeah, it makes it easier when you've got that distraction there as well. You can just chat about it. Thank you so much for inviting me on. It's a pleasure being here and, yeah, I'm glad you kind of understand what we're doing here. MindJam itself is four years old now. But I was doing things before in the pandemic, similar. But once the pandemic hit, that was the key moment where everything went online for my support with young people. And, suddenly, the light bulb came on, and I was like, this is a way in. +You know, there are so many young people that are struggling, lost, feel they're stupid, and don't fit in. Yet, actually, they're amazing. But, you know, a standard way of sitting in front of them going, "Tell me why you can't go to school. Why can't you do this?" you know, it doesn't work. They don't trust that person. They've got trauma. They've been, you know, battered down by education and by health services. +And so, to suddenly have someone who comes in and goes, "Oh, so you love Minecraft. Oh, I love Minecraft, too. Let's join in. Let's go in a world." And then, you can build that trust to then go, "How's your week been then?" Or, you know, and start talking, and you're just on the same wavelength. And, for me, it was something as soon as I sort of realized, it was like, this is...of course, this makes perfect sense. And then, I looked and saw nobody else is doing it [laughs]. +So, I started off MindJam just on my own. At first, very quickly, we got working with lots of...in the UK, we have local authorities, which is the councils around, so seeing there is a real, you know, thing that they would work with us. So, that was great, to be recognized as actually a real service, rather than just someone playing games with kids. It's like, no, this is real. This really works. And then, it quickly got bigger than me, and now we are at 110 mentors working for us, and we're supporting over 2,000 young people all over the world. +SAMI: That's incredible. +DAN: It's a mission of mine, you know, we'll go more into my sort of history, but I've got two neurodivergent children: both autistic, one's ADHD as well. When you see something that you think is going to work for your child, to then suddenly see it's got, like, a two-year waiting list, which most have, it's heartbreaking, and you know it's going to be too late. +So, it's always been my mission with MindJam to keep that waiting list as small as I can, but also, obviously, expanding with quality mentors and all that. So, you know, we generally tend to always say about three months before we can sort of get that support for young people. But yeah, it's something very close to my heart that I'm so passionate about and, yeah, it's been a great journey so far. +SAMI: You can tell. It's so interesting because, like you say, when you find something that works for your kids. Because when I was younger, I struggled with separation anxiety a lot in school. So, I would have days when I would really struggle to go to school. During my high school period, I went to the Royal Free, which is down in Hampstead, so not too far from where I grew up and not too far from my school. And my parents...I tried to engage with a therapist. But it's almost like, I don't know if I wasn't cognitively or intellectually developed enough to engage in that way, but it didn't work. Ultimately, I did kind of one or two sessions. I remember filling in some questionnaire and thinking, like, I don't get this. This doesn't make sense. +And what you're talking about, if I understand correctly, is you're coming to where the child is at. You're coming to a safe space for them, a place where they feel comfortable. It's almost like a world which is predictable. Whereas the outside world is very scary, right? Especially for people who have generalized anxiety disorder, like I said, autism. It's very challenging. And so, you come to their level, and you say, "Right, let's find a place where we all feel comfortable." And then, we can start to engage. And you say, like, you know, the pandemic was a little bit of a light bulb moment. +What's been the biggest barrier then? So, you've found yourself kind of going into this and saying, right, this is something which works. It works for my kids. I want to make this available, accessible. What's been your biggest barrier to getting this off the ground and getting it working? +DAN: It's the negative thoughts and the way the media portrays and education portrays gaming, basically. That has been the hardest thing is most parents are on board, but they still feel a little bit ashamed of how social media is on gaming and screen time. And they're very worried that they're not doing the right thing. And we come in a way of also educating. We educate the educators. We do training plans for schools, and for social services, and all sorts because there are so many benefits to gaming that aren't recognized. +And, you know, gaming is still generally quite new. It's evolved so much in the last even 10 years. It's insane the way the characters have evolved. And the emotional nature of games now is really complex and, you know, young people and older people can get so much from them. But gaming still, in general, people are still like, "Well, get off that. Do something actually worthwhile." It's like, it's so worthwhile. There's so much, you know, strategy game you've got so much from it. And a fast-paced shooting you've got cognitive abilities. The perfect example I've got is, did you hear a couple of months ago a young lad, I think he was 13, he beat Tetris. +SAMI: Yes. +DAN: He completed Tetris, which is incredible, you know, it's like, oh, wow. And the first thing the newsreader said to them, the media person interviewing him went, "You should get out more." That's the way she portrayed it, rather than going, "What an achievement it is. You should get outside more." I'm literally like, what? What's going on? You know, again, this kid, you know, he's in the Guinness World of Records. What an achievement. He's famous around the world for doing it. +It's like, why is that not seen as such a good thing? You know, so yeah, so that was the hard thing was especially schools, you know, they're very frightened of gaming and of change. And so, trying to help them see that, actually, if you meet a young person where they're at in something they love, then you can help inspire them and help find out why they can't deal with the things, why they can't engage with school, and also inspire them for future learning careers. Even healthy gaming comes from having that understanding of how they're gaming. +So, if someone's sat up all night gaming, yeah, we all know it's not great for them. But if you just say, "Gaming's evil. Get off it. You're wasting your time. I'm turning that off," they're going to want to rebel against that. Yet if you come in and go, "Oh, wow, I can see why you were sat up all night doing that. But have you noticed that you're not as good at playing when you're really tired or really hungry?" And if you look at the top e-sports players, they're athletes. They exercise; they eat well; they sleep well. So, you know, if you embrace gaming a bit more, you can get that trust and that bond to then help inspire in other ways. +RÉMY: I mean, I could talk about it for a long time. It's really refreshing to hear someone talk about video games in such a positive way and talking about the benefits. And you even mentioned strong players like athletes. It's really refreshing. And I'm wondering, how did this knowledge come up to you in the first place? +So, I bet you might be someone enjoying playing games yourself. But how did you see all these benefits yourself? Because, unfortunately, it's not something we talk a lot about. As you mentioned, in the press, we hear about all the negativity. Every time there is a strong event, we blame video games, all that. And we forgot all the stories where the video games enhance people, if they have trouble or not. It can be very beneficial to a lot of people. So, how did you see this value yourself? +DAN: Yeah, well, yeah, I've always been a gamer, you know, ever since Spectrum 48K, I think you had. I'm showing my age now, but it was mainly when the Sega Megadrive, and from then, PlayStation onwards were my days. And me and my brother used to have great times together on that as well. You know, it was our bonding. But then I think the biggest light bulb to me...before the pandemic, I was a teacher. And I used to teach music and ICT and computers as well, and having my children as well, and both in school connecting with the young people. +Because I was a gamer, I could talk about the games that they're playing with them and to see their eyes light up...and you're on a different wavelength with that young person. They suddenly got this trust in you, and they want to tell you all about what they've done on Minecraft, or what the new season of Fortnite's about. And it was having such a beneficial effect on them and same with my family as well. We, you know, both my children are autistic, and we've got, you know, we have a lot of difficulties around that of bonding together as a family, yet our closest moments have been through gaming together. +So, Mario 3D World was the first one I remember with my children playing, and we could play at all levels. So, my son was about four and, you know, he was often in a bubble, killed, and floating back onto the screen again. But, you know, we had a great time. And I was suddenly, like, looking, thinking, this is amazing. You know, nobody hears about this side of it that it's bringing us together. And so, from there, I then started doing after-school gaming clubs, so not coding clubs, nothing like that. It was gaming. And the young people they loved it. It was oversubscribed. Masses of kids came to it. +We had all sorts of things from Super Smash Bros, if you know that, to, you know, to PlayStation games, Go Simulator, and everything playing. And we just had a whale of a time, and they could really relax and make friends. And, again, it was all coming from the joy of gaming together, basically. And it's, you know, as much as some people might not like it, it's bigger and bigger. It's the biggest entertainment industry now. +And, you know, on the other side of it, there are so many careers in it. If your young person has an interest in gaming, see what they're interested, help it, champion it because it's, yeah, you know, there's such a future there. But yeah, that's my story, basically, and where that sort of light bulb came from. +And then, I've done a lot of research into the benefits of gaming and how you can use that for connecting with young people. And, you know, so many games now have characters with, you know, emotional things going off, or, you know, you can talk about feelings even in games like Minecraft where the characters don't talk. But you can be like, how must that person be feeling there? And, you know, you can really bring in real-life situations while gaming and also have a lot of fun, which I think is super important as well, which sometimes gets forgotten about. But, you know, real life is really enhanced by having loads of fun, and gaming's fun. +SAMI: Yeah. It's so fascinating. As you're speaking, I'm having this internal dilemma, right? Because, in my head, everything you're saying is true and makes sense. And I believe it, and I've seen it. And then, I probably still harbor those feelings that are almost entrenched, like you're saying, in the media with, you know, the person who completed Tetris. And those sorts of feelings are still, like, a little bit entrenched to me in terms of the negative sides of gaming. +Like, I guess I grew up probably similar to you, where it was like, "Well, why aren't you outside more?" and the negative aspect of it. I spoke about this in a different podcast, which I've apologized to my parents for mentioning in public. But when I was in university, it's too late now, I also kind of developed, I would call it probably, like, a small gaming addiction. I don't know where it would sit, but I was doing all-nighters Playing Call of Duty, Modern Warfare. And so, there definitely is a negative side. But I like what you say about, well, actually, you can address that in a healthy way. +But then, this week, just this week, which is quite uncanny, my seven-year-old comes, and he says, "Daddy, I really want to get an Xbox, you know, my friend's got one." And he's just starting to get to that cusp of gaming. So, in my head, I say, yeah, like that makes total sense, and I imagine the benefits and the fun time me and him could have on an Xbox. But I still struggle with those feelings of...maybe they're my own worries of, well, but what if he neglects his other stuff? What if he goes into like, yeah, with ADHD, he goes into hyperfocus, and that's all he does? How [laughs] can you counsel me out of this concern? +DAN: Well, no, I completely understand, and that is where all our fears come from, especially our generation and how it's put through. But I think young people more and more connect through gaming, whereas I think when we were gamers as young, a lot of stuff wasn't online. So, we weren't playing with our friends. We were playing on our own a lot of the time, whereas it's very social now. Platforms like Roblox and Minecraft are the things that are super social, working together as a team, things like that. +But also screen time, I can show you that we've got a whole list of benefits of gaming, actually, that I'll share with you because there's studies that even screen time has been proven not to be detrimental the way we're told it is. And I think we must know that through how we work. Most of us work on screens these days, so. +SAMI: Yeah, that's such a point of contention in the house because we currently do only on Fridays. So, they get, like, two hours of screen time. I don't know if that's strict. I don't know where I am on that. Do you have, like, with your own kids, or how do you handle that discipline? So, let's say I get the console, right? I bring it into the house to my seven-year-old. Do I limit it with screen time? How would you approach that sort of thing? +DAN: Obviously, with a seven-year-old, it's a little bit different from...mine are now 17 and 14. So, we discuss it more, but yeah, definitely, you know, have boundaries. And also, if you're worried about how they're gaming, maybe have the Xbox in the living room, so instead of gaming in their bedroom, they're gaming when you're around, and it's a shared family activity. And then, it's easier to say, "Well, we're going to be having food in a minute. So, finish up on that game." And you can have all that understanding. +But I think also, you know, that other side of things of coming from seeing what they're playing. I talk to parents a lot about this, and they get, you know, they see frustrations in their young people when they're trying to get them off. But they don't realize that maybe they're playing something like Fortnite or something that's a bit more online team-based, where if they pulled them off the game in the middle of the match, it could be detrimental to the team they're working with, their rankings. You know, they could even get banned from the game for a few days, you know. +So, understanding and them being able to work time management together, being like, "Well, after this game is finished, this is where we're going, you know, we've got to go out. We've got to do this," you know, there is a give and take there. And I'm not saying there isn't negatives to gaming. We need, you know, everybody needs a break as well. But, again, through the understanding of what they're playing, you can have those conversations. If you're not playing them or watching them and don't understand what the game is about, and what the joy is about, there's going to be a gap between you, you know, where the young person is going to be like, "You don't understand me. You don't understand why I want to play this." +My kids, you know, we went from the other [inaudible 17:37] because they've had severe problems at school, both of them, through their neurodivergency, and gaming has really helped them both to regulate. And maybe when you're saying about yourself when you had problems, and maybe there was something else going on. And then, the gaming was a way for you to cope, that safe space to go to that was actually working in a way as a little bit of therapy and keeping you grounded, you know, as well. So, you know, there's two sides to see it. +But yeah, definitely, I can understand the worries of staying up all night playing it or not doing your homework and playing it, although I have different things to say about homework. But to say it's not actually beneficial is wrong because, you know, you just got to look at something like Minecraft and the amount a young person can learn, everything from biomes, and blocks, and diamonds, or ores to actual mathematics and things. And it naturally leads onto PCs and learning how to code things and who knows where that's going to lead, to creating something completely new. +So, I worry for the ones that are heavily restricted on screen time. I worry that they're being held a little bit back. You know, that might sound a bit controversial for some people. But when most jobs are digital and you're not allowed to learn, I mean, the young people I see they're so gifted at such a young age in understanding digital things that they're going to be at the forefront of the new technology. So, it's almost like, yeah, I think it should be embraced with both hands. +RÉMY: There's an incredible opportunity to learn new things through video games and to be happy and to share, like you said. And I bet our audience is already quite open to video games, but we never know it. I think it could be interesting if you could provide, like, a very simple, not comprehensive list of famous games and the kind of skills and benefits they provide you. You mentioned Minecraft; you mentioned creativity. But what kind of games and skills benefits you? You could say for our audience to understand more about the opportunity that is out there. +DAN: Yeah, I mean, there are so many. But yeah, so, if we look at your normal shooter game like Call of Duty, and Fortnite, and things like that, that is for cognitive ability. You know, getting those dexterity in your hands and learning those [inaudible 20:11] of pressing buttons is more than you think. It's really training that brain and getting that brain working really quick. It's proven to boost your brain power, your gray matter. It's actually proven that gaming, in general, just boosts your gray matter. +I mean, we all know about doing brain training games, but all games using that brain, you know, it's much more advanced than sitting watching TV. But then if you go into more things like puzzle games, so things from your Tetris all the way through to more advanced ones like Portal or strategy games like Civilization and things, there is so much you're doing. You're boosting that brainpower, and you're thinking all the time. +But then you can get into...yeah, back onto the shooter games as well, they help with spatial recognition. So, it's actually helping to spot things from a distance: dangers or things to collect. You can see them, and it actually enhances eyesight. It is proven to enhance eyesight, which is great. Decision-making and leadership skills, which is a key thing people talk about for business, is all there when you're in your team of shooters. You're playing Overwatch or you're playing, you know, any game like that. You know, there's always somebody leading or, you know, saying what should be best, seeing the best strategies in there. +Problem-solving comes into all sorts so, obviously, in shooters and things again, I'd- say, but also your Minecraft. You know, you've got to create a certain thing to defeat the dragon or whatever you're doing. There's always something, or if you're building something. But then, of course, your high-end puzzle games and even things like Mario. I mean, they get so complex in the problem-solving to overcome a level. Again, the brain power, and the brain power seeing these young people that they're way more advanced than we were playing games. The games are so intricate and so hard now. +One you never hear about is social skills until...I think the pandemic helped that a bit. People started to see, oh, Animal Crossing, it's a great way to connect with people. And, you know, and Roblox as much as it gets a lot of bad press, for young people to connect and play, and lot of it is almost like playground role playing play, and they're playing together. You know, there's games just based in Ikea, and they're shopping, and [laughs] things like that. It's really good for them to be doing that. +And health and fitness surprisingly, of course, is in gaming. So, obviously, a lot of Nintendo Switch games are sort of standing up, you know, playing switch sports and things, but then virtual reality is huge for that. And if you've ever tried Beat Saber, that's a real workout, which is really good. But there's loads of boxing ones. There's one that kids play now called Gorilla Tag, where, oh my God, that is such a workout. I have mentees that I work with, and then we'll be like, "Oh, Gorilla Tag," an hour of that, I am exhausted. Because you're just flinging your arms around like a gorilla trying to move fast. It's amazing. +SAMI: I saw a post you did recently about there's, like, a Greek mythology level on Fortnite, like, an educational aspect [laughs]. It's so funny because I remember playing God of War on the PS2, and I learned so much about Greek mythology. Everything I know comes from God of War. And so, there's also that educational aspect. +DAN: Yeah, exactly. You get this deep dive into something, and you really find what you're interested in. So, I've got a kid, and he loves this game called War Thunder, which is all about planes, World War planes, and he can tell me everything about every plane and what country it's made. He can spot it a mile off. You know, "Oh, that's a Russian plane from so and so. Its weak points are here. It was built by so and so." And it's like, you're a genius, and it's all come from, you know, this game's sparked this real interest. +And, you know, like I said, Fortnite brings it in, God of War, of course. Assassin's Creed is amazing for things like that, history, it goes from Egypt times. And they even now have walkthroughs in the game where...this needs to be used in schools. I don't know if schools embrace it yet, but you don't have any of this story and the killings and stuff. You just are going through history and walking through the towns and things like that, which is brilliant. The latest one for Assassin's Creed was Vikings, wasn't it? And that was brilliant because that brought in the UK and how it was when the Vikings came over. There's so much stuff. +I've got a young person, and he loves this game called For Honor, which is all about medieval sword fights. And he got such an interest in weapons that he's then become a blacksmith. He's enrolled onto a college course apprenticeship being a blacksmith. He wants to be making armory and swords for movies. You know, he said like, "Look, Lord of the Rings, that's all made properly, isn't it?" I mean, that's [inaudible 24:50] +SAMI: Wow. +DAN: Yeah, it's amazing. One other thing that the games bring, which I think is amazing, is mindfulness as well. There's a huge thing of that. Yeah, like I said, going back to maybe yourself when you were gaming at night, and you maybe needed to destress and maybe take your mind off something, you can get into a game and almost...there's a thing called the grind in the game. Minecraft has it a lot, where you've just got to get yourself a hundred diamonds, or whatever [laughs]. +So, it's like, you can almost turn your brain off and just do that, you know, and it can be so super relaxing. And you can get into this thing called flow state. A lot of driving games are like that. If you hit every corner perfectly, you're kind of just in this dream-like state where you just...everything's going well. And that brings a euphoria, too. There's so many good things. +But now there's loads of games that are actually based around mindfulness. Tetris is one that's been proven for that. But I don't know if you've heard a more recent one called PowerWash Simulator. Now, this game was one of my most favorite for the last couple of years. All you're doing is washing stuff with a power washer. But the way it works, it gives you a little ding when you've cleaned something properly, like a [vocalization]. And it just...you stand back and look at your job. Honestly, it's amazing. But now Oxford University are doing a full study on it because they realize how beneficial it is to relaxing and chilling out, you know, and just making yourself just feeling happy when you need to just de-stress. It's amazing. +RÉMY: I can totally relate. I remember a few years ago, I played GTA 5, and GTA 5 is the kind of game famous for arbitrary violence or all this kind of stuff we hear in the media. But I remember me playing and sometimes I wanted to play just to take a bike and to go on the road and to see a sunset. And, of course, we could argue that I can see the sunset out there, but, in a game, it's just a piece of art. +At work, recently, we just had a conversation about beautiful games. So, we weren't interested in all the features or how the game would work but just how beautiful it is. And sometimes we just play video games because they're beautiful. And so, they could provide so much on the intellectual level, on the skills, but also, just as piece of art, just beautiful things made by beautiful artists. +DAN: Yeah, it is amazing when you see that. And yeah, I get that completely with GTA. It gets a lot of bad reputation, you know, and story-wise, it is very adult. But, you know, it's the biggest game in the world for a reason. And, you know, like you said, you climb the mountain, you look at the view, you know, it is such a lovely thing to do. +There was a game, Red Dead Redemption. I had a young lady I was mentoring, and she was situationally mute, which means, you know, she couldn't talk to anybody. She used to type her responses to me. But she loved Red Dead Redemption, loved horses. And she actually created a group from all around the world, where they would all meet her on a Friday in the game, and she would take them on horse trails. +And so, this is all in the game, and she would just take them around to beautiful spots, do nice little jumps with the horses, setting up camp, you know, and, I mean, that's [inaudible 28:08]. It's amazing. And yeah, she ended up making a horse game on Roblox, and that doing really well, and her actually working for Roblox themselves. So, yeah, you know, it all inspires them to work on that. +And, I think, sorry, I'm going on tangents here, but also, as you say, appreciating art. There are so many different sides to gaming. A lot of people used to think gaming is just coding, and I don't want to be a coder. That's confusing. I don't want to do that. If you look at the credits that roll on a main game, and they go on for, like, about an hour. There are so many different jobs from artists, storyboard writers, level designers, musicians. There's everything there. The coders are just one part of it. +So, as I said before, there are so many career opportunities there, either starting up your own business as a self-employed person or getting involved in it. One I love...a lot of the neurodivergent people I work with [inaudible 29:07] is being a games tester. Because the first thing my son ever does is, if he gets a game, he tries to break it. He tries to find where he can walk through a wall, or something like that. So, it's like that job would be ideal for you. It's like, it's amazing. And that's a job. That's a really important job as well. +SAMI: Yeah. When you talk about these stories, they are inspirational. Like, I feel like almost, like, a flutter in my heart as you talk about this kid who maybe felt he has kind of no hope or very little opportunities to actually honing in on this Viking game and then being able to go and become a blacksmith, or this other person you mentioned who's now with Roblox. Yeah, I almost wish, like, they had more publicity around them. And maybe we're kind of doing some of that work now. What would you say is your biggest success story? +DAN: I guess MindJam in itself I think is just, I mean, it's way bigger than me now. Obviously, it was born from this idea of giving young people the time and the respect. They are doing something that they love to do and is beneficial. That's what I found was everybody...even when I was teaching, we used to have this connection with the kids, and I used to work one-to-one with the, you know, special education needs, young ones. And a great connection talking about gaming, and their eyes would light up. They would talk about their week, and how they were feeling, and what they achieved. +But then it would always be, in the back of my mind, we need to get back onto what we're supposed to be doing and, you know, I need to tick these boxes. And there's always something wanted from them. And it's the same if they go and see a health service. There's always something that they want from that young person. Yet if you just approach them and say, "You know, let's do what you want to do." It's child-led. It's low demand, and let's see where that takes us. That's where we got to discovering about the blacksmith thing. And that's why we've got young people making albums and things with MindJam. You know, it goes anywhere. I've got one young person who shows me Tai Chi, you know, that's our MindJam session. It started off from Rocket League. So, it can really go anywhere. +But yeah, sorry, going back to the big success, it is every day now I get a message saying how one of my mentors has helped a young person to help the whole family. That is just the best thing in the world. You know, this is something we've created, and we work hard. We work really hard to make sure we've got the best people. +You know, and we're well-trained, and informed, and everything. To hear that it's really making such a difference, and, you know, some people say we're saving lives, and, you know, I just have to pinch myself. Me and my wife we were just like, we can't believe it really how amazing it is. But we're just on a mission now to make sure it's accessible for as many people who need it. +SAMI: Yeah, I've seen some of the reviews on your website, and they're heartwarming. But, like, it kind of makes sense, right? Like, for some people, this is the only place that they feel safe. They feel comfortable. You imagine all the cortisol that's going through someone when they're in that fight or flight moment, and there's lots of stress and anxiety. And they enter into a gaming world, and they can escape. And all of a sudden, that reduces. You're dealing with a different person. You're dealing with someone who feels happy, who feels content. +And then, you're opening up their mind to have other conversations, you know, like you say. I really recommend it to our listeners. Go and check out the stream. You do kind of...I've seen you've done a few episodes of streaming with other mentors. And it's fascinating to see how all of you, whilst you're playing, are in a conversation about, "Oh, how was your week? And how's that been going?" And, you know, something happened over there. And it's like, you're just in a more of a relaxed state to have those conversations. +DAN: Yeah, you know, it's been used before, you know, LEGO therapy is kind of like that. You know, that's what MindJam is in a way is play therapy, but there's so much more you can do with the digital platform. And we're at an amazing age as well, where most bits of software are free. I'll click on like, you know, if they want to look into 3D modeling, it's easy to get a copy of Blender. If you want to get into Unity or Unreal Engine, I mean, there's always into...and it's all, you know, what a wonderful time. When we were younger, if I wanted to get into game design, it was so complicated. You didn't know where to start where, you know, so yeah, it's really amazing. +And another thing that I love as well is the mentors that work for us. Most of them are really [inaudible 33:28]. I struggled when I was in my early twenties, and I remember seeing a counselor. And it felt like they had no idea what they were...yeah, they're reading from a textbook, you know, and I remember just really patronizing me. And I was just like, you've got no clue. Whereas I think all the mentors we have all said, "I wish MindJam was around when I was a young person." +And I thought, that's the key thing for me, their empathy, their understanding. We don't have to solve it straight away. It's just being there and going, "Yeah, that is hard. Yeah, you know, you'll be okay though. And there's, you know, you're not on your own here." And, you know, I think that is...so many people seem to have to try and heal people straight away. And it's like, no, people just need time to talk, and it's the same as adults as well. Yeah, it could just carry on really to all ages really, couldn't it? +SAMI: Yeah. And you've also got that buy-in, right? Whereas, you know, I think of myself perhaps going to therapy at that young age. I didn't really buy into it because I was sitting there with an adult who I didn't really know what we were doing. And I was just kind of there for a conversation. And here you've got...you're doing something that they like, and they enjoy. +To put my parent and adult hat back on [laughs] because it's something I want to pick your brains on, right? So, working in the tech industry and working in coding, I've read articles about games, which kind of it says that they're more and more...you see it maybe more on the games on the mobile phone. So, they're employing, like, these kind of gambling tactics, so a lot of the stuff where it's treasure chests. And what is it? On Fortnite, it's the packs. On FIFA, it's also, like, you open up the pack and you see what players you get. +So, that sort of stuff I also find scary where I feel like you have from the industry...so, whilst you're using the industry in this way, is the industry itself there to promote and perpetuate the benefits that come from games? Or are they looking, I want to get people in; I want to get them hooked; I want to use these gambling techniques, A/B testing, whatever it is? +DAN: From all big companies, we get both sides, obviously. So, you got your unscrupulous ones that, oh, go for it. You loot boxes. But I think more and more, especially with young people, they're more and more aware. They're far more savvy than we are in these things. And the good one is EA with, you know, FIFA. They get review bombed because as soon as someone's putting in loot boxes and things, people are just like, you're just after our money. This is a con. It's pay to win. Mobile games are the worst for it, of course. You know, they're quick cash-making things. +Again, instead of, like, saying, "All gaming is evil. We should never do it," it's being aware and being aware of what these games are trying to do, which, again, when you're looking at a young child, is having shared gaming experiences. So, you can go, "Ah, can you see what they're doing here? You know, they've hooked us in. We've played this for two minutes, and we've had free play. And now they're asking us to pay five pounds for extra things. That's a bit of a con, isn't it?" And, you know, you can actually bring that awareness, and then they're not going to fall for things like that. +But at the other side of it, I see firsthand...I've luckily enough to work closely with Sony. One of their great companies is called Media Molecule. I don't know if you've heard of them. They did LittleBigPlanet, and lately, they had a game called Dreams, which is actually making games on a PlayStation, which is really cool. But they're so accessible. It's all about, you know, making everybody happy, giving people the keys to creativity, and really help making everything accessible. +Again, they worked with this wonderful, wonderful artist who created characters, character designs. They'd never met her. She was so socially anxious. She never could leave her house but was actually one of their top artists that they would send the work, send the brief. She'd send this amazing art back, and then they'd pay her. They didn't have to come into the office nine till five for no reason whatsoever. And there's a lovely side, and, of course, there's a business unscrupulous side. +And yeah, again, bring that education of that. This is what I think should be in schools. Instead of avoiding the whole issue, is actually talk about being toxic gamers and what that means, and how to deal with toxic gamers, and how not to be a toxic gamer yourself. For those that don't know toxic gamers, it's just people that are really, really mean to everybody, which seems to be a set thing that people do, especially to a new player. It's like, learn how to encourage people in. And there's now games coming out where they ban people straight away if they're being toxic, and it's all about helping that new player feel like part of the team. +But again, yeah, let's say if this was actually brought into education, so then we learn about loot boxes and, you know, pay-to-win type games, then young people would be on that same wavelength. They would get it, either that or it would make gaming so lame that no one would play gaming anymore because it's in schools [laughs]. Like, oh, it sucks now [laughs]. +SAMI: Yeah, I think that that way that you embrace kind of what gaming is and you say, well, actually, we can see that it's got a benefit. We can see that it's positive. How do we get the absolute most out of this? How can we not hide, stick our heads in the sand to the issues that might be there? And how can we then say, "Let's use this?" +And I think, I mean, my mom will be listening to this podcast for sure. But I think it's something which it's quite disruptive what you're doing. I really do feel that way kind of dabbling in gaming, working as a consultant in the coding industry. I actually teach neurodivergent kids as well on the side. And I'm actually mentoring another kid in coding as well. And what you're doing, as I said at the beginning, it's mind-blowing, and we could talk to you for hours. +We have a little chat on this podcast, which listeners can't see. And I asked Rémy, like, "Do you have any questions before you want to wrap up?" And Rémy was just like, "I just want to keep listening. I'm loving it." And I'm exactly...I feel like we can listen to...I think me and Rémy game and we dabble here and there as well ourselves. So, it's definitely something which speaks to us so much. But I've got to thank you so much for your time, for taking the time to jump on with us, give us such an insight into the work that you're doing with MindJam. +Let's talk about the BAFTA Young Game Designers Award Ceremony Open Day. Give us some info. +DAN: Oh yeah. Well, this is a lovely thing. I've luckily enough to be involved with BAFTA on this for a few years. An early success of MindJam was I was nominated as Mentor of The Year and finalist for Mentor of The Year for BAFTA in 2021. And they run this thing called Young Games Designers every year, and it's brilliant because they do...it's two sides to it. One is actually making a game, but then, of course, not all young people are ready to make a game. And, you know, so the other side is a games concept where you could just send in sketches, ideas, things like that. And that's really accessible for lots of young people we work with, of course. +But yeah, in July, I don't have the date; it's early July, we have the award ceremony, which is on this Saturday. But then on the Sunday at BAFTA in London, it's an open day for families to come. You have to apply and get a ticket. I'm sure you guys can put the link on here later on. But yeah, MindJam will be there, but there's loads of game places. I think TT Games will be there who make the LEGO games. And there's all sorts of...we have D&D there. We have all sorts and talks on how to get into the industry and things like that. So, it's really a great thing to come to if you're a young person who's interested in gaming. +SAMI: That's really cool. So, parents, if you're listening, save up all that screen time so you can use it. A month's worth of screen time [chuckles] at the BAFTA Awards, Young Game Designers Awards Ceremony in the Open Day in London. +If people want to get hold of you, Dan, where's the best place? They've heard this. They're inspired. They feel like they've got someone who would benefit from your services. Where's the best place to get in touch? +DAN: If you go to our website, it's mindjam.org.uk, and you can email us at hello@mindjam.org.uk. And I think you said this podcast is international, isn't it? So, we do offer sessions all around the world. We have mentors in America, in Australia, in Japan, all over the place basically. MindJam is universal. So, wherever you are, get in touch. And if you're interested in being a mentor as well, get in touch as well, so... +SAMI: Definitely, I highly recommend. And I've already got people I can think of that I'm going to be passing your details on to. +Listeners, listeners, listeners, our lovely listeners, no one likes missing out on things. Remember that flight you missed? The train that passed you by? Your partner's birthday? I've been there, by the way; I missed one recently. It's a horrible feeling. I cannot deal with you missing out on these things, but I can make sure that this feeling doesn't come about when it comes to our podcast. So, move your thumb. Yes, you, move your thumb. Hit that subscribe button. I can guarantee you, you will never miss one of our podcasts. And you'll hear amazing guests, just like Dan, as we get them in, and we have great chats together on the Giant Robots on Tour podcast. +You can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech. +Thanks for listening. See you next time. Bye. +  +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + neurodivergent youth, gaming therapy, emotional support, SEN support, MindJam, Dan Clark, Minecraft therapy, digital skills, neurodivergent children, gaming benefits, mental health, online therapy, ADHD support, autism support, innovative therapy, youth therapy, gaming for good, digital transformation, educational gaming, mental health support + + In this episode of the "Giant Robots On Tour" podcast, hosts Sami Birnbaum and Rémy Hannequin interview Dan Clark, the Founder and CEO of MindJam, an innovative platform providing emotional and SEN (Special Educational Needs) support for young people through gaming, game design, and digital skills. Sami shares a personal story about how his mother, an educational psychologist, introduced him to MindJam, highlighting its impact and relevance. Dan explains that MindJam was born out of the need to support young people who feel out of place in traditional educational settings, particularly those with ADHD, autism, and other neurodivergent conditions. By leveraging popular games like Minecraft, MindJam builds trust and engages young people in a medium they enjoy, transforming therapeutic support into a more effective and engaging process.

+ +

Dan discusses the inception and growth of MindJam, which started during the pandemic when traditional in-person support became impossible. This shift to online sessions via gaming platforms provided a new avenue to connect with young people, enabling them to open up and build trust in a familiar and enjoyable environment. Dan emphasizes that gaming offers numerous benefits, such as enhancing cognitive abilities, fostering social connections, and providing a safe space for expression. Despite the negative stigma around gaming, he points out that it can be a powerful tool for personal development and emotional support. MindJam has grown significantly, now with 110 mentors supporting over 2,000 young people globally, showcasing the scalability and effectiveness of this approach.

+ +

The conversation also touches on the broader implications and challenges of integrating gaming into therapeutic and educational contexts. Dan highlights the need for societal perception shifts to recognize the positive aspects of gaming, counteracting the negative media portrayal. He underscores the importance of educating parents, educators, and social services about the benefits of gaming and how it can be used constructively. Dan shares inspiring success stories from MindJam, illustrating how gaming can lead to real-world achievements and personal growth.

+ + + +

Transcript:

+ +

 SAMI: Right, we are back again. And this is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host Sami Birnbaum.

+ +

RÉMY: And I'm your other host, Rémy Hannequin.

+ +

SAMI: Let's get into it, Rémy. Joining us today is Dan Clark, the Founder and CEO of MindJam, a platform that provides online one-to-one sessions, providing emotional and SEN support for young people through gaming, game design, and digital skills.

+ +

Dan, full disclosure on this one: so, about a month ago, right? I get an email from my mom. Now [laughs], this email says, "You've got to check this guy out. Go and take a look at MindJam." And I'm thinking, mom, I don't get these emails from you. This is not the normal sort of thing I'd get from my mom on your average weekday. And I know in the past, like, I've told her that I'm kind of doing this podcast thing, and I'm starting to regret, like, telling her this. Like, what is she throwing my way?

+ +

But I get into some research...and maybe for some context, actually, which is helpful because my mom isn't just doing research for the podcast, my mom's an educational psychologist. So, she's been doing that ever since I can remember. I remember growing up as a kid, and that was, I mean, she assessed me numerous times. And she works, I guess, similar kind of to the children or people that you're working with, people with ADHD, autism, neurodivergent children, just often who are struggling in school and trying to find where they fit.

+ +

And I start doing my research. I look into it, hit the website, hit your LinkedIn. And I'll be, like, totally honest with you: We were both just blown away by what you are doing. And this is coming not only from me, and I work in the tech industry, and I've got a history of slight gaming addictions, which we might touch on, but also coming from my mom who works on the other side and works with all the local authorities. She does the kind of tribunals that they have to do to try and get people into the right schools and kids into the right schools.

+ +

And, literally, we were blown away, and I nearly got lost as well on your website. I found some kind of gaming streams that you do, and I feel almost like we missed a trick here, Rémy, because we could have done this podcast on Minecraft. It's such a nice flow, right, when you're streaming.

+ +

DAN: Yeah, it makes it easier when you've got that distraction there as well. You can just chat about it. Thank you so much for inviting me on. It's a pleasure being here and, yeah, I'm glad you kind of understand what we're doing here. MindJam itself is four years old now. But I was doing things before in the pandemic, similar. But once the pandemic hit, that was the key moment where everything went online for my support with young people. And, suddenly, the light bulb came on, and I was like, this is a way in.

+ +

You know, there are so many young people that are struggling, lost, feel they're stupid, and don't fit in. Yet, actually, they're amazing. But, you know, a standard way of sitting in front of them going, "Tell me why you can't go to school. Why can't you do this?" you know, it doesn't work. They don't trust that person. They've got trauma. They've been, you know, battered down by education and by health services.

+ +

And so, to suddenly have someone who comes in and goes, "Oh, so you love Minecraft. Oh, I love Minecraft, too. Let's join in. Let's go in a world." And then, you can build that trust to then go, "How's your week been then?" Or, you know, and start talking, and you're just on the same wavelength. And, for me, it was something as soon as I sort of realized, it was like, this is...of course, this makes perfect sense. And then, I looked and saw nobody else is doing it [laughs].

+ +

So, I started off MindJam just on my own. At first, very quickly, we got working with lots of...in the UK, we have local authorities, which is the councils around, so seeing there is a real, you know, thing that they would work with us. So, that was great, to be recognized as actually a real service, rather than just someone playing games with kids. It's like, no, this is real. This really works. And then, it quickly got bigger than me, and now we are at 110 mentors working for us, and we're supporting over 2,000 young people all over the world.

+ +

SAMI: That's incredible.

+ +

DAN: It's a mission of mine, you know, we'll go more into my sort of history, but I've got two neurodivergent children: both autistic, one's ADHD as well. When you see something that you think is going to work for your child, to then suddenly see it's got, like, a two-year waiting list, which most have, it's heartbreaking, and you know it's going to be too late.

+ +

So, it's always been my mission with MindJam to keep that waiting list as small as I can, but also, obviously, expanding with quality mentors and all that. So, you know, we generally tend to always say about three months before we can sort of get that support for young people. But yeah, it's something very close to my heart that I'm so passionate about and, yeah, it's been a great journey so far.

+ +

SAMI: You can tell. It's so interesting because, like you say, when you find something that works for your kids. Because when I was younger, I struggled with separation anxiety a lot in school. So, I would have days when I would really struggle to go to school. During my high school period, I went to the Royal Free, which is down in Hampstead, so not too far from where I grew up and not too far from my school. And my parents...I tried to engage with a therapist. But it's almost like, I don't know if I wasn't cognitively or intellectually developed enough to engage in that way, but it didn't work. Ultimately, I did kind of one or two sessions. I remember filling in some questionnaire and thinking, like, I don't get this. This doesn't make sense.

+ +

And what you're talking about, if I understand correctly, is you're coming to where the child is at. You're coming to a safe space for them, a place where they feel comfortable. It's almost like a world which is predictable. Whereas the outside world is very scary, right? Especially for people who have generalized anxiety disorder, like I said, autism. It's very challenging. And so, you come to their level, and you say, "Right, let's find a place where we all feel comfortable." And then, we can start to engage. And you say, like, you know, the pandemic was a little bit of a light bulb moment.

+ +

What's been the biggest barrier then? So, you've found yourself kind of going into this and saying, right, this is something which works. It works for my kids. I want to make this available, accessible. What's been your biggest barrier to getting this off the ground and getting it working?

+ +

DAN: It's the negative thoughts and the way the media portrays and education portrays gaming, basically. That has been the hardest thing is most parents are on board, but they still feel a little bit ashamed of how social media is on gaming and screen time. And they're very worried that they're not doing the right thing. And we come in a way of also educating. We educate the educators. We do training plans for schools, and for social services, and all sorts because there are so many benefits to gaming that aren't recognized.

+ +

And, you know, gaming is still generally quite new. It's evolved so much in the last even 10 years. It's insane the way the characters have evolved. And the emotional nature of games now is really complex and, you know, young people and older people can get so much from them. But gaming still, in general, people are still like, "Well, get off that. Do something actually worthwhile." It's like, it's so worthwhile. There's so much, you know, strategy game you've got so much from it. And a fast-paced shooting you've got cognitive abilities. The perfect example I've got is, did you hear a couple of months ago a young lad, I think he was 13, he beat Tetris.

+ +

SAMI: Yes.

+ +

DAN: He completed Tetris, which is incredible, you know, it's like, oh, wow. And the first thing the newsreader said to them, the media person interviewing him went, "You should get out more." That's the way she portrayed it, rather than going, "What an achievement it is. You should get outside more." I'm literally like, what? What's going on? You know, again, this kid, you know, he's in the Guinness World of Records. What an achievement. He's famous around the world for doing it.

+ +

It's like, why is that not seen as such a good thing? You know, so yeah, so that was the hard thing was especially schools, you know, they're very frightened of gaming and of change. And so, trying to help them see that, actually, if you meet a young person where they're at in something they love, then you can help inspire them and help find out why they can't deal with the things, why they can't engage with school, and also inspire them for future learning careers. Even healthy gaming comes from having that understanding of how they're gaming.

+ +

So, if someone's sat up all night gaming, yeah, we all know it's not great for them. But if you just say, "Gaming's evil. Get off it. You're wasting your time. I'm turning that off," they're going to want to rebel against that. Yet if you come in and go, "Oh, wow, I can see why you were sat up all night doing that. But have you noticed that you're not as good at playing when you're really tired or really hungry?" And if you look at the top e-sports players, they're athletes. They exercise; they eat well; they sleep well. So, you know, if you embrace gaming a bit more, you can get that trust and that bond to then help inspire in other ways.

+ +

RÉMY: I mean, I could talk about it for a long time. It's really refreshing to hear someone talk about video games in such a positive way and talking about the benefits. And you even mentioned strong players like athletes. It's really refreshing. And I'm wondering, how did this knowledge come up to you in the first place?

+ +

So, I bet you might be someone enjoying playing games yourself. But how did you see all these benefits yourself? Because, unfortunately, it's not something we talk a lot about. As you mentioned, in the press, we hear about all the negativity. Every time there is a strong event, we blame video games, all that. And we forgot all the stories where the video games enhance people, if they have trouble or not. It can be very beneficial to a lot of people. So, how did you see this value yourself?

+ +

DAN: Yeah, well, yeah, I've always been a gamer, you know, ever since Spectrum 48K, I think you had. I'm showing my age now, but it was mainly when the Sega Megadrive, and from then, PlayStation onwards were my days. And me and my brother used to have great times together on that as well. You know, it was our bonding. But then I think the biggest light bulb to me...before the pandemic, I was a teacher. And I used to teach music and ICT and computers as well, and having my children as well, and both in school connecting with the young people.

+ +

Because I was a gamer, I could talk about the games that they're playing with them and to see their eyes light up...and you're on a different wavelength with that young person. They suddenly got this trust in you, and they want to tell you all about what they've done on Minecraft, or what the new season of Fortnite's about. And it was having such a beneficial effect on them and same with my family as well. We, you know, both my children are autistic, and we've got, you know, we have a lot of difficulties around that of bonding together as a family, yet our closest moments have been through gaming together.

+ +

So, Mario 3D World was the first one I remember with my children playing, and we could play at all levels. So, my son was about four and, you know, he was often in a bubble, killed, and floating back onto the screen again. But, you know, we had a great time. And I was suddenly, like, looking, thinking, this is amazing. You know, nobody hears about this side of it that it's bringing us together. And so, from there, I then started doing after-school gaming clubs, so not coding clubs, nothing like that. It was gaming. And the young people they loved it. It was oversubscribed. Masses of kids came to it.

+ +

We had all sorts of things from Super Smash Bros, if you know that, to, you know, to PlayStation games, Go Simulator, and everything playing. And we just had a whale of a time, and they could really relax and make friends. And, again, it was all coming from the joy of gaming together, basically. And it's, you know, as much as some people might not like it, it's bigger and bigger. It's the biggest entertainment industry now.

+ +

And, you know, on the other side of it, there are so many careers in it. If your young person has an interest in gaming, see what they're interested, help it, champion it because it's, yeah, you know, there's such a future there. But yeah, that's my story, basically, and where that sort of light bulb came from.

+ +

And then, I've done a lot of research into the benefits of gaming and how you can use that for connecting with young people. And, you know, so many games now have characters with, you know, emotional things going off, or, you know, you can talk about feelings even in games like Minecraft where the characters don't talk. But you can be like, how must that person be feeling there? And, you know, you can really bring in real-life situations while gaming and also have a lot of fun, which I think is super important as well, which sometimes gets forgotten about. But, you know, real life is really enhanced by having loads of fun, and gaming's fun.

+ +

SAMI: Yeah. It's so fascinating. As you're speaking, I'm having this internal dilemma, right? Because, in my head, everything you're saying is true and makes sense. And I believe it, and I've seen it. And then, I probably still harbor those feelings that are almost entrenched, like you're saying, in the media with, you know, the person who completed Tetris. And those sorts of feelings are still, like, a little bit entrenched to me in terms of the negative sides of gaming.

+ +

Like, I guess I grew up probably similar to you, where it was like, "Well, why aren't you outside more?" and the negative aspect of it. I spoke about this in a different podcast, which I've apologized to my parents for mentioning in public. But when I was in university, it's too late now, I also kind of developed, I would call it probably, like, a small gaming addiction. I don't know where it would sit, but I was doing all-nighters Playing Call of Duty, Modern Warfare. And so, there definitely is a negative side. But I like what you say about, well, actually, you can address that in a healthy way.

+ +

But then, this week, just this week, which is quite uncanny, my seven-year-old comes, and he says, "Daddy, I really want to get an Xbox, you know, my friend's got one." And he's just starting to get to that cusp of gaming. So, in my head, I say, yeah, like that makes total sense, and I imagine the benefits and the fun time me and him could have on an Xbox. But I still struggle with those feelings of...maybe they're my own worries of, well, but what if he neglects his other stuff? What if he goes into like, yeah, with ADHD, he goes into hyperfocus, and that's all he does? How [laughs] can you counsel me out of this concern?

+ +

DAN: Well, no, I completely understand, and that is where all our fears come from, especially our generation and how it's put through. But I think young people more and more connect through gaming, whereas I think when we were gamers as young, a lot of stuff wasn't online. So, we weren't playing with our friends. We were playing on our own a lot of the time, whereas it's very social now. Platforms like Roblox and Minecraft are the things that are super social, working together as a team, things like that.

+ +

But also screen time, I can show you that we've got a whole list of benefits of gaming, actually, that I'll share with you because there's studies that even screen time has been proven not to be detrimental the way we're told it is. And I think we must know that through how we work. Most of us work on screens these days, so.

+ +

SAMI: Yeah, that's such a point of contention in the house because we currently do only on Fridays. So, they get, like, two hours of screen time. I don't know if that's strict. I don't know where I am on that. Do you have, like, with your own kids, or how do you handle that discipline? So, let's say I get the console, right? I bring it into the house to my seven-year-old. Do I limit it with screen time? How would you approach that sort of thing?

+ +

DAN: Obviously, with a seven-year-old, it's a little bit different from...mine are now 17 and 14. So, we discuss it more, but yeah, definitely, you know, have boundaries. And also, if you're worried about how they're gaming, maybe have the Xbox in the living room, so instead of gaming in their bedroom, they're gaming when you're around, and it's a shared family activity. And then, it's easier to say, "Well, we're going to be having food in a minute. So, finish up on that game." And you can have all that understanding.

+ +

But I think also, you know, that other side of things of coming from seeing what they're playing. I talk to parents a lot about this, and they get, you know, they see frustrations in their young people when they're trying to get them off. But they don't realize that maybe they're playing something like Fortnite or something that's a bit more online team-based, where if they pulled them off the game in the middle of the match, it could be detrimental to the team they're working with, their rankings. You know, they could even get banned from the game for a few days, you know.

+ +

So, understanding and them being able to work time management together, being like, "Well, after this game is finished, this is where we're going, you know, we've got to go out. We've got to do this," you know, there is a give and take there. And I'm not saying there isn't negatives to gaming. We need, you know, everybody needs a break as well. But, again, through the understanding of what they're playing, you can have those conversations. If you're not playing them or watching them and don't understand what the game is about, and what the joy is about, there's going to be a gap between you, you know, where the young person is going to be like, "You don't understand me. You don't understand why I want to play this."

+ +

My kids, you know, we went from the other [inaudible 17:37] because they've had severe problems at school, both of them, through their neurodivergency, and gaming has really helped them both to regulate. And maybe when you're saying about yourself when you had problems, and maybe there was something else going on. And then, the gaming was a way for you to cope, that safe space to go to that was actually working in a way as a little bit of therapy and keeping you grounded, you know, as well. So, you know, there's two sides to see it.

+ +

But yeah, definitely, I can understand the worries of staying up all night playing it or not doing your homework and playing it, although I have different things to say about homework. But to say it's not actually beneficial is wrong because, you know, you just got to look at something like Minecraft and the amount a young person can learn, everything from biomes, and blocks, and diamonds, or ores to actual mathematics and things. And it naturally leads onto PCs and learning how to code things and who knows where that's going to lead, to creating something completely new.

+ +

So, I worry for the ones that are heavily restricted on screen time. I worry that they're being held a little bit back. You know, that might sound a bit controversial for some people. But when most jobs are digital and you're not allowed to learn, I mean, the young people I see they're so gifted at such a young age in understanding digital things that they're going to be at the forefront of the new technology. So, it's almost like, yeah, I think it should be embraced with both hands.

+ +

RÉMY: There's an incredible opportunity to learn new things through video games and to be happy and to share, like you said. And I bet our audience is already quite open to video games, but we never know it. I think it could be interesting if you could provide, like, a very simple, not comprehensive list of famous games and the kind of skills and benefits they provide you. You mentioned Minecraft; you mentioned creativity. But what kind of games and skills benefits you? You could say for our audience to understand more about the opportunity that is out there.

+ +

DAN: Yeah, I mean, there are so many. But yeah, so, if we look at your normal shooter game like Call of Duty, and Fortnite, and things like that, that is for cognitive ability. You know, getting those dexterity in your hands and learning those [inaudible 20:11] of pressing buttons is more than you think. It's really training that brain and getting that brain working really quick. It's proven to boost your brain power, your gray matter. It's actually proven that gaming, in general, just boosts your gray matter.

+ +

I mean, we all know about doing brain training games, but all games using that brain, you know, it's much more advanced than sitting watching TV. But then if you go into more things like puzzle games, so things from your Tetris all the way through to more advanced ones like Portal or strategy games like Civilization and things, there is so much you're doing. You're boosting that brainpower, and you're thinking all the time.

+ +

But then you can get into...yeah, back onto the shooter games as well, they help with spatial recognition. So, it's actually helping to spot things from a distance: dangers or things to collect. You can see them, and it actually enhances eyesight. It is proven to enhance eyesight, which is great. Decision-making and leadership skills, which is a key thing people talk about for business, is all there when you're in your team of shooters. You're playing Overwatch or you're playing, you know, any game like that. You know, there's always somebody leading or, you know, saying what should be best, seeing the best strategies in there.

+ +

Problem-solving comes into all sorts so, obviously, in shooters and things again, I'd- say, but also your Minecraft. You know, you've got to create a certain thing to defeat the dragon or whatever you're doing. There's always something, or if you're building something. But then, of course, your high-end puzzle games and even things like Mario. I mean, they get so complex in the problem-solving to overcome a level. Again, the brain power, and the brain power seeing these young people that they're way more advanced than we were playing games. The games are so intricate and so hard now.

+ +

One you never hear about is social skills until...I think the pandemic helped that a bit. People started to see, oh, Animal Crossing, it's a great way to connect with people. And, you know, and Roblox as much as it gets a lot of bad press, for young people to connect and play, and lot of it is almost like playground role playing play, and they're playing together. You know, there's games just based in Ikea, and they're shopping, and [laughs] things like that. It's really good for them to be doing that.

+ +

And health and fitness surprisingly, of course, is in gaming. So, obviously, a lot of Nintendo Switch games are sort of standing up, you know, playing switch sports and things, but then virtual reality is huge for that. And if you've ever tried Beat Saber, that's a real workout, which is really good. But there's loads of boxing ones. There's one that kids play now called Gorilla Tag, where, oh my God, that is such a workout. I have mentees that I work with, and then we'll be like, "Oh, Gorilla Tag," an hour of that, I am exhausted. Because you're just flinging your arms around like a gorilla trying to move fast. It's amazing.

+ +

SAMI: I saw a post you did recently about there's, like, a Greek mythology level on Fortnite, like, an educational aspect [laughs]. It's so funny because I remember playing God of War on the PS2, and I learned so much about Greek mythology. Everything I know comes from God of War. And so, there's also that educational aspect.

+ +

DAN: Yeah, exactly. You get this deep dive into something, and you really find what you're interested in. So, I've got a kid, and he loves this game called War Thunder, which is all about planes, World War planes, and he can tell me everything about every plane and what country it's made. He can spot it a mile off. You know, "Oh, that's a Russian plane from so and so. Its weak points are here. It was built by so and so." And it's like, you're a genius, and it's all come from, you know, this game's sparked this real interest.

+ +

And, you know, like I said, Fortnite brings it in, God of War, of course. Assassin's Creed is amazing for things like that, history, it goes from Egypt times. And they even now have walkthroughs in the game where...this needs to be used in schools. I don't know if schools embrace it yet, but you don't have any of this story and the killings and stuff. You just are going through history and walking through the towns and things like that, which is brilliant. The latest one for Assassin's Creed was Vikings, wasn't it? And that was brilliant because that brought in the UK and how it was when the Vikings came over. There's so much stuff.

+ +

I've got a young person, and he loves this game called For Honor, which is all about medieval sword fights. And he got such an interest in weapons that he's then become a blacksmith. He's enrolled onto a college course apprenticeship being a blacksmith. He wants to be making armory and swords for movies. You know, he said like, "Look, Lord of the Rings, that's all made properly, isn't it?" I mean, that's [inaudible 24:50]

+ +

SAMI: Wow.

+ +

DAN: Yeah, it's amazing. One other thing that the games bring, which I think is amazing, is mindfulness as well. There's a huge thing of that. Yeah, like I said, going back to maybe yourself when you were gaming at night, and you maybe needed to destress and maybe take your mind off something, you can get into a game and almost...there's a thing called the grind in the game. Minecraft has it a lot, where you've just got to get yourself a hundred diamonds, or whatever [laughs].

+ +

So, it's like, you can almost turn your brain off and just do that, you know, and it can be so super relaxing. And you can get into this thing called flow state. A lot of driving games are like that. If you hit every corner perfectly, you're kind of just in this dream-like state where you just...everything's going well. And that brings a euphoria, too. There's so many good things.

+ +

But now there's loads of games that are actually based around mindfulness. Tetris is one that's been proven for that. But I don't know if you've heard a more recent one called PowerWash Simulator. Now, this game was one of my most favorite for the last couple of years. All you're doing is washing stuff with a power washer. But the way it works, it gives you a little ding when you've cleaned something properly, like a [vocalization]. And it just...you stand back and look at your job. Honestly, it's amazing. But now Oxford University are doing a full study on it because they realize how beneficial it is to relaxing and chilling out, you know, and just making yourself just feeling happy when you need to just de-stress. It's amazing.

+ +

RÉMY: I can totally relate. I remember a few years ago, I played GTA 5, and GTA 5 is the kind of game famous for arbitrary violence or all this kind of stuff we hear in the media. But I remember me playing and sometimes I wanted to play just to take a bike and to go on the road and to see a sunset. And, of course, we could argue that I can see the sunset out there, but, in a game, it's just a piece of art.

+ +

At work, recently, we just had a conversation about beautiful games. So, we weren't interested in all the features or how the game would work but just how beautiful it is. And sometimes we just play video games because they're beautiful. And so, they could provide so much on the intellectual level, on the skills, but also, just as piece of art, just beautiful things made by beautiful artists.

+ +

DAN: Yeah, it is amazing when you see that. And yeah, I get that completely with GTA. It gets a lot of bad reputation, you know, and story-wise, it is very adult. But, you know, it's the biggest game in the world for a reason. And, you know, like you said, you climb the mountain, you look at the view, you know, it is such a lovely thing to do.

+ +

There was a game, Red Dead Redemption. I had a young lady I was mentoring, and she was situationally mute, which means, you know, she couldn't talk to anybody. She used to type her responses to me. But she loved Red Dead Redemption, loved horses. And she actually created a group from all around the world, where they would all meet her on a Friday in the game, and she would take them on horse trails.

+ +

And so, this is all in the game, and she would just take them around to beautiful spots, do nice little jumps with the horses, setting up camp, you know, and, I mean, that's [inaudible 28:08]. It's amazing. And yeah, she ended up making a horse game on Roblox, and that doing really well, and her actually working for Roblox themselves. So, yeah, you know, it all inspires them to work on that.

+ +

And, I think, sorry, I'm going on tangents here, but also, as you say, appreciating art. There are so many different sides to gaming. A lot of people used to think gaming is just coding, and I don't want to be a coder. That's confusing. I don't want to do that. If you look at the credits that roll on a main game, and they go on for, like, about an hour. There are so many different jobs from artists, storyboard writers, level designers, musicians. There's everything there. The coders are just one part of it.

+ +

So, as I said before, there are so many career opportunities there, either starting up your own business as a self-employed person or getting involved in it. One I love...a lot of the neurodivergent people I work with [inaudible 29:07] is being a games tester. Because the first thing my son ever does is, if he gets a game, he tries to break it. He tries to find where he can walk through a wall, or something like that. So, it's like that job would be ideal for you. It's like, it's amazing. And that's a job. That's a really important job as well.

+ +

SAMI: Yeah. When you talk about these stories, they are inspirational. Like, I feel like almost, like, a flutter in my heart as you talk about this kid who maybe felt he has kind of no hope or very little opportunities to actually honing in on this Viking game and then being able to go and become a blacksmith, or this other person you mentioned who's now with Roblox. Yeah, I almost wish, like, they had more publicity around them. And maybe we're kind of doing some of that work now. What would you say is your biggest success story?

+ +

DAN: I guess MindJam in itself I think is just, I mean, it's way bigger than me now. Obviously, it was born from this idea of giving young people the time and the respect. They are doing something that they love to do and is beneficial. That's what I found was everybody...even when I was teaching, we used to have this connection with the kids, and I used to work one-to-one with the, you know, special education needs, young ones. And a great connection talking about gaming, and their eyes would light up. They would talk about their week, and how they were feeling, and what they achieved.

+ +

But then it would always be, in the back of my mind, we need to get back onto what we're supposed to be doing and, you know, I need to tick these boxes. And there's always something wanted from them. And it's the same if they go and see a health service. There's always something that they want from that young person. Yet if you just approach them and say, "You know, let's do what you want to do." It's child-led. It's low demand, and let's see where that takes us. That's where we got to discovering about the blacksmith thing. And that's why we've got young people making albums and things with MindJam. You know, it goes anywhere. I've got one young person who shows me Tai Chi, you know, that's our MindJam session. It started off from Rocket League. So, it can really go anywhere.

+ +

But yeah, sorry, going back to the big success, it is every day now I get a message saying how one of my mentors has helped a young person to help the whole family. That is just the best thing in the world. You know, this is something we've created, and we work hard. We work really hard to make sure we've got the best people.

+ +

You know, and we're well-trained, and informed, and everything. To hear that it's really making such a difference, and, you know, some people say we're saving lives, and, you know, I just have to pinch myself. Me and my wife we were just like, we can't believe it really how amazing it is. But we're just on a mission now to make sure it's accessible for as many people who need it.

+ +

SAMI: Yeah, I've seen some of the reviews on your website, and they're heartwarming. But, like, it kind of makes sense, right? Like, for some people, this is the only place that they feel safe. They feel comfortable. You imagine all the cortisol that's going through someone when they're in that fight or flight moment, and there's lots of stress and anxiety. And they enter into a gaming world, and they can escape. And all of a sudden, that reduces. You're dealing with a different person. You're dealing with someone who feels happy, who feels content.

+ +

And then, you're opening up their mind to have other conversations, you know, like you say. I really recommend it to our listeners. Go and check out the stream. You do kind of...I've seen you've done a few episodes of streaming with other mentors. And it's fascinating to see how all of you, whilst you're playing, are in a conversation about, "Oh, how was your week? And how's that been going?" And, you know, something happened over there. And it's like, you're just in a more of a relaxed state to have those conversations.

+ +

DAN: Yeah, you know, it's been used before, you know, LEGO therapy is kind of like that. You know, that's what MindJam is in a way is play therapy, but there's so much more you can do with the digital platform. And we're at an amazing age as well, where most bits of software are free. I'll click on like, you know, if they want to look into 3D modeling, it's easy to get a copy of Blender. If you want to get into Unity or Unreal Engine, I mean, there's always into...and it's all, you know, what a wonderful time. When we were younger, if I wanted to get into game design, it was so complicated. You didn't know where to start where, you know, so yeah, it's really amazing.

+ +

And another thing that I love as well is the mentors that work for us. Most of them are really [inaudible 33:28]. I struggled when I was in my early twenties, and I remember seeing a counselor. And it felt like they had no idea what they were...yeah, they're reading from a textbook, you know, and I remember just really patronizing me. And I was just like, you've got no clue. Whereas I think all the mentors we have all said, "I wish MindJam was around when I was a young person."

+ +

And I thought, that's the key thing for me, their empathy, their understanding. We don't have to solve it straight away. It's just being there and going, "Yeah, that is hard. Yeah, you know, you'll be okay though. And there's, you know, you're not on your own here." And, you know, I think that is...so many people seem to have to try and heal people straight away. And it's like, no, people just need time to talk, and it's the same as adults as well. Yeah, it could just carry on really to all ages really, couldn't it?

+ +

SAMI: Yeah. And you've also got that buy-in, right? Whereas, you know, I think of myself perhaps going to therapy at that young age. I didn't really buy into it because I was sitting there with an adult who I didn't really know what we were doing. And I was just kind of there for a conversation. And here you've got...you're doing something that they like, and they enjoy.

+ +

To put my parent and adult hat back on [laughs] because it's something I want to pick your brains on, right? So, working in the tech industry and working in coding, I've read articles about games, which kind of it says that they're more and more...you see it maybe more on the games on the mobile phone. So, they're employing, like, these kind of gambling tactics, so a lot of the stuff where it's treasure chests. And what is it? On Fortnite, it's the packs. On FIFA, it's also, like, you open up the pack and you see what players you get.

+ +

So, that sort of stuff I also find scary where I feel like you have from the industry...so, whilst you're using the industry in this way, is the industry itself there to promote and perpetuate the benefits that come from games? Or are they looking, I want to get people in; I want to get them hooked; I want to use these gambling techniques, A/B testing, whatever it is?

+ +

DAN: From all big companies, we get both sides, obviously. So, you got your unscrupulous ones that, oh, go for it. You loot boxes. But I think more and more, especially with young people, they're more and more aware. They're far more savvy than we are in these things. And the good one is EA with, you know, FIFA. They get review bombed because as soon as someone's putting in loot boxes and things, people are just like, you're just after our money. This is a con. It's pay to win. Mobile games are the worst for it, of course. You know, they're quick cash-making things.

+ +

Again, instead of, like, saying, "All gaming is evil. We should never do it," it's being aware and being aware of what these games are trying to do, which, again, when you're looking at a young child, is having shared gaming experiences. So, you can go, "Ah, can you see what they're doing here? You know, they've hooked us in. We've played this for two minutes, and we've had free play. And now they're asking us to pay five pounds for extra things. That's a bit of a con, isn't it?" And, you know, you can actually bring that awareness, and then they're not going to fall for things like that.

+ +

But at the other side of it, I see firsthand...I've luckily enough to work closely with Sony. One of their great companies is called Media Molecule. I don't know if you've heard of them. They did LittleBigPlanet, and lately, they had a game called Dreams, which is actually making games on a PlayStation, which is really cool. But they're so accessible. It's all about, you know, making everybody happy, giving people the keys to creativity, and really help making everything accessible.

+ +

Again, they worked with this wonderful, wonderful artist who created characters, character designs. They'd never met her. She was so socially anxious. She never could leave her house but was actually one of their top artists that they would send the work, send the brief. She'd send this amazing art back, and then they'd pay her. They didn't have to come into the office nine till five for no reason whatsoever. And there's a lovely side, and, of course, there's a business unscrupulous side.

+ +

And yeah, again, bring that education of that. This is what I think should be in schools. Instead of avoiding the whole issue, is actually talk about being toxic gamers and what that means, and how to deal with toxic gamers, and how not to be a toxic gamer yourself. For those that don't know toxic gamers, it's just people that are really, really mean to everybody, which seems to be a set thing that people do, especially to a new player. It's like, learn how to encourage people in. And there's now games coming out where they ban people straight away if they're being toxic, and it's all about helping that new player feel like part of the team.

+ +

But again, yeah, let's say if this was actually brought into education, so then we learn about loot boxes and, you know, pay-to-win type games, then young people would be on that same wavelength. They would get it, either that or it would make gaming so lame that no one would play gaming anymore because it's in schools [laughs]. Like, oh, it sucks now [laughs].

+ +

SAMI: Yeah, I think that that way that you embrace kind of what gaming is and you say, well, actually, we can see that it's got a benefit. We can see that it's positive. How do we get the absolute most out of this? How can we not hide, stick our heads in the sand to the issues that might be there? And how can we then say, "Let's use this?"

+ +

And I think, I mean, my mom will be listening to this podcast for sure. But I think it's something which it's quite disruptive what you're doing. I really do feel that way kind of dabbling in gaming, working as a consultant in the coding industry. I actually teach neurodivergent kids as well on the side. And I'm actually mentoring another kid in coding as well. And what you're doing, as I said at the beginning, it's mind-blowing, and we could talk to you for hours.

+ +

We have a little chat on this podcast, which listeners can't see. And I asked Rémy, like, "Do you have any questions before you want to wrap up?" And Rémy was just like, "I just want to keep listening. I'm loving it." And I'm exactly...I feel like we can listen to...I think me and Rémy game and we dabble here and there as well ourselves. So, it's definitely something which speaks to us so much. But I've got to thank you so much for your time, for taking the time to jump on with us, give us such an insight into the work that you're doing with MindJam.

+ +

Let's talk about the BAFTA Young Game Designers Award Ceremony Open Day. Give us some info.

+ +

DAN: Oh yeah. Well, this is a lovely thing. I've luckily enough to be involved with BAFTA on this for a few years. An early success of MindJam was I was nominated as Mentor of The Year and finalist for Mentor of The Year for BAFTA in 2021. And they run this thing called Young Games Designers every year, and it's brilliant because they do...it's two sides to it. One is actually making a game, but then, of course, not all young people are ready to make a game. And, you know, so the other side is a games concept where you could just send in sketches, ideas, things like that. And that's really accessible for lots of young people we work with, of course.

+ +

But yeah, in July, I don't have the date; it's early July, we have the award ceremony, which is on this Saturday. But then on the Sunday at BAFTA in London, it's an open day for families to come. You have to apply and get a ticket. I'm sure you guys can put the link on here later on. But yeah, MindJam will be there, but there's loads of game places. I think TT Games will be there who make the LEGO games. And there's all sorts of...we have D&D there. We have all sorts and talks on how to get into the industry and things like that. So, it's really a great thing to come to if you're a young person who's interested in gaming.

+ +

SAMI: That's really cool. So, parents, if you're listening, save up all that screen time so you can use it. A month's worth of screen time [chuckles] at the BAFTA Awards, Young Game Designers Awards Ceremony in the Open Day in London.

+ +

If people want to get hold of you, Dan, where's the best place? They've heard this. They're inspired. They feel like they've got someone who would benefit from your services. Where's the best place to get in touch?

+ +

DAN: If you go to our website, it's mindjam.org.uk, and you can email us at hello@mindjam.org.uk. And I think you said this podcast is international, isn't it? So, we do offer sessions all around the world. We have mentors in America, in Australia, in Japan, all over the place basically. MindJam is universal. So, wherever you are, get in touch. And if you're interested in being a mentor as well, get in touch as well, so...

+ +

SAMI: Definitely, I highly recommend. And I've already got people I can think of that I'm going to be passing your details on to.

+ +

Listeners, listeners, listeners, our lovely listeners, no one likes missing out on things. Remember that flight you missed? The train that passed you by? Your partner's birthday? I've been there, by the way; I missed one recently. It's a horrible feeling. I cannot deal with you missing out on these things, but I can make sure that this feeling doesn't come about when it comes to our podcast. So, move your thumb. Yes, you, move your thumb. Hit that subscribe button. I can guarantee you, you will never miss one of our podcasts. And you'll hear amazing guests, just like Dan, as we get them in, and we have great chats together on the Giant Robots on Tour podcast.

+ +

You can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech.

+ +

Thanks for listening. See you next time. Bye.
+ 
+AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode of the "Giant Robots On Tour" podcast, hosts Sami Birnbaum and Rémy Hannequin interview Dan Clark, the Founder and CEO of MindJam, an innovative platform providing emotional and SEN (Special Educational Needs) support for young people through gaming, game design, and digital skills. Sami shares a personal story about how his mother, an educational psychologist, introduced him to MindJam, highlighting its impact and relevance. Dan explains that MindJam was born out of the need to support young people who feel out of place in traditional educational settings, particularly those with ADHD, autism, and other neurodivergent conditions. By leveraging popular games like Minecraft, MindJam builds trust and engages young people in a medium they enjoy, transforming therapeutic support into a more effective and engaging process.

+ +

Dan discusses the inception and growth of MindJam, which started during the pandemic when traditional in-person support became impossible. This shift to online sessions via gaming platforms provided a new avenue to connect with young people, enabling them to open up and build trust in a familiar and enjoyable environment. Dan emphasizes that gaming offers numerous benefits, such as enhancing cognitive abilities, fostering social connections, and providing a safe space for expression. Despite the negative stigma around gaming, he points out that it can be a powerful tool for personal development and emotional support. MindJam has grown significantly, now with 110 mentors supporting over 2,000 young people globally, showcasing the scalability and effectiveness of this approach.

+ +

The conversation also touches on the broader implications and challenges of integrating gaming into therapeutic and educational contexts. Dan highlights the need for societal perception shifts to recognize the positive aspects of gaming, counteracting the negative media portrayal. He underscores the importance of educating parents, educators, and social services about the benefits of gaming and how it can be used constructively. Dan shares inspiring success stories from MindJam, illustrating how gaming can lead to real-world achievements and personal growth.

+ + + +

Transcript:

+ +

 SAMI: Right, we are back again. And this is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host Sami Birnbaum.

+ +

RÉMY: And I'm your other host, Rémy Hannequin.

+ +

SAMI: Let's get into it, Rémy. Joining us today is Dan Clark, the Founder and CEO of MindJam, a platform that provides online one-to-one sessions, providing emotional and SEN support for young people through gaming, game design, and digital skills.

+ +

Dan, full disclosure on this one: so, about a month ago, right? I get an email from my mom. Now [laughs], this email says, "You've got to check this guy out. Go and take a look at MindJam." And I'm thinking, mom, I don't get these emails from you. This is not the normal sort of thing I'd get from my mom on your average weekday. And I know in the past, like, I've told her that I'm kind of doing this podcast thing, and I'm starting to regret, like, telling her this. Like, what is she throwing my way?

+ +

But I get into some research...and maybe for some context, actually, which is helpful because my mom isn't just doing research for the podcast, my mom's an educational psychologist. So, she's been doing that ever since I can remember. I remember growing up as a kid, and that was, I mean, she assessed me numerous times. And she works, I guess, similar kind of to the children or people that you're working with, people with ADHD, autism, neurodivergent children, just often who are struggling in school and trying to find where they fit.

+ +

And I start doing my research. I look into it, hit the website, hit your LinkedIn. And I'll be, like, totally honest with you: We were both just blown away by what you are doing. And this is coming not only from me, and I work in the tech industry, and I've got a history of slight gaming addictions, which we might touch on, but also coming from my mom who works on the other side and works with all the local authorities. She does the kind of tribunals that they have to do to try and get people into the right schools and kids into the right schools.

+ +

And, literally, we were blown away, and I nearly got lost as well on your website. I found some kind of gaming streams that you do, and I feel almost like we missed a trick here, Rémy, because we could have done this podcast on Minecraft. It's such a nice flow, right, when you're streaming.

+ +

DAN: Yeah, it makes it easier when you've got that distraction there as well. You can just chat about it. Thank you so much for inviting me on. It's a pleasure being here and, yeah, I'm glad you kind of understand what we're doing here. MindJam itself is four years old now. But I was doing things before in the pandemic, similar. But once the pandemic hit, that was the key moment where everything went online for my support with young people. And, suddenly, the light bulb came on, and I was like, this is a way in.

+ +

You know, there are so many young people that are struggling, lost, feel they're stupid, and don't fit in. Yet, actually, they're amazing. But, you know, a standard way of sitting in front of them going, "Tell me why you can't go to school. Why can't you do this?" you know, it doesn't work. They don't trust that person. They've got trauma. They've been, you know, battered down by education and by health services.

+ +

And so, to suddenly have someone who comes in and goes, "Oh, so you love Minecraft. Oh, I love Minecraft, too. Let's join in. Let's go in a world." And then, you can build that trust to then go, "How's your week been then?" Or, you know, and start talking, and you're just on the same wavelength. And, for me, it was something as soon as I sort of realized, it was like, this is...of course, this makes perfect sense. And then, I looked and saw nobody else is doing it [laughs].

+ +

So, I started off MindJam just on my own. At first, very quickly, we got working with lots of...in the UK, we have local authorities, which is the councils around, so seeing there is a real, you know, thing that they would work with us. So, that was great, to be recognized as actually a real service, rather than just someone playing games with kids. It's like, no, this is real. This really works. And then, it quickly got bigger than me, and now we are at 110 mentors working for us, and we're supporting over 2,000 young people all over the world.

+ +

SAMI: That's incredible.

+ +

DAN: It's a mission of mine, you know, we'll go more into my sort of history, but I've got two neurodivergent children: both autistic, one's ADHD as well. When you see something that you think is going to work for your child, to then suddenly see it's got, like, a two-year waiting list, which most have, it's heartbreaking, and you know it's going to be too late.

+ +

So, it's always been my mission with MindJam to keep that waiting list as small as I can, but also, obviously, expanding with quality mentors and all that. So, you know, we generally tend to always say about three months before we can sort of get that support for young people. But yeah, it's something very close to my heart that I'm so passionate about and, yeah, it's been a great journey so far.

+ +

SAMI: You can tell. It's so interesting because, like you say, when you find something that works for your kids. Because when I was younger, I struggled with separation anxiety a lot in school. So, I would have days when I would really struggle to go to school. During my high school period, I went to the Royal Free, which is down in Hampstead, so not too far from where I grew up and not too far from my school. And my parents...I tried to engage with a therapist. But it's almost like, I don't know if I wasn't cognitively or intellectually developed enough to engage in that way, but it didn't work. Ultimately, I did kind of one or two sessions. I remember filling in some questionnaire and thinking, like, I don't get this. This doesn't make sense.

+ +

And what you're talking about, if I understand correctly, is you're coming to where the child is at. You're coming to a safe space for them, a place where they feel comfortable. It's almost like a world which is predictable. Whereas the outside world is very scary, right? Especially for people who have generalized anxiety disorder, like I said, autism. It's very challenging. And so, you come to their level, and you say, "Right, let's find a place where we all feel comfortable." And then, we can start to engage. And you say, like, you know, the pandemic was a little bit of a light bulb moment.

+ +

What's been the biggest barrier then? So, you've found yourself kind of going into this and saying, right, this is something which works. It works for my kids. I want to make this available, accessible. What's been your biggest barrier to getting this off the ground and getting it working?

+ +

DAN: It's the negative thoughts and the way the media portrays and education portrays gaming, basically. That has been the hardest thing is most parents are on board, but they still feel a little bit ashamed of how social media is on gaming and screen time. And they're very worried that they're not doing the right thing. And we come in a way of also educating. We educate the educators. We do training plans for schools, and for social services, and all sorts because there are so many benefits to gaming that aren't recognized.

+ +

And, you know, gaming is still generally quite new. It's evolved so much in the last even 10 years. It's insane the way the characters have evolved. And the emotional nature of games now is really complex and, you know, young people and older people can get so much from them. But gaming still, in general, people are still like, "Well, get off that. Do something actually worthwhile." It's like, it's so worthwhile. There's so much, you know, strategy game you've got so much from it. And a fast-paced shooting you've got cognitive abilities. The perfect example I've got is, did you hear a couple of months ago a young lad, I think he was 13, he beat Tetris.

+ +

SAMI: Yes.

+ +

DAN: He completed Tetris, which is incredible, you know, it's like, oh, wow. And the first thing the newsreader said to them, the media person interviewing him went, "You should get out more." That's the way she portrayed it, rather than going, "What an achievement it is. You should get outside more." I'm literally like, what? What's going on? You know, again, this kid, you know, he's in the Guinness World of Records. What an achievement. He's famous around the world for doing it.

+ +

It's like, why is that not seen as such a good thing? You know, so yeah, so that was the hard thing was especially schools, you know, they're very frightened of gaming and of change. And so, trying to help them see that, actually, if you meet a young person where they're at in something they love, then you can help inspire them and help find out why they can't deal with the things, why they can't engage with school, and also inspire them for future learning careers. Even healthy gaming comes from having that understanding of how they're gaming.

+ +

So, if someone's sat up all night gaming, yeah, we all know it's not great for them. But if you just say, "Gaming's evil. Get off it. You're wasting your time. I'm turning that off," they're going to want to rebel against that. Yet if you come in and go, "Oh, wow, I can see why you were sat up all night doing that. But have you noticed that you're not as good at playing when you're really tired or really hungry?" And if you look at the top e-sports players, they're athletes. They exercise; they eat well; they sleep well. So, you know, if you embrace gaming a bit more, you can get that trust and that bond to then help inspire in other ways.

+ +

RÉMY: I mean, I could talk about it for a long time. It's really refreshing to hear someone talk about video games in such a positive way and talking about the benefits. And you even mentioned strong players like athletes. It's really refreshing. And I'm wondering, how did this knowledge come up to you in the first place?

+ +

So, I bet you might be someone enjoying playing games yourself. But how did you see all these benefits yourself? Because, unfortunately, it's not something we talk a lot about. As you mentioned, in the press, we hear about all the negativity. Every time there is a strong event, we blame video games, all that. And we forgot all the stories where the video games enhance people, if they have trouble or not. It can be very beneficial to a lot of people. So, how did you see this value yourself?

+ +

DAN: Yeah, well, yeah, I've always been a gamer, you know, ever since Spectrum 48K, I think you had. I'm showing my age now, but it was mainly when the Sega Megadrive, and from then, PlayStation onwards were my days. And me and my brother used to have great times together on that as well. You know, it was our bonding. But then I think the biggest light bulb to me...before the pandemic, I was a teacher. And I used to teach music and ICT and computers as well, and having my children as well, and both in school connecting with the young people.

+ +

Because I was a gamer, I could talk about the games that they're playing with them and to see their eyes light up...and you're on a different wavelength with that young person. They suddenly got this trust in you, and they want to tell you all about what they've done on Minecraft, or what the new season of Fortnite's about. And it was having such a beneficial effect on them and same with my family as well. We, you know, both my children are autistic, and we've got, you know, we have a lot of difficulties around that of bonding together as a family, yet our closest moments have been through gaming together.

+ +

So, Mario 3D World was the first one I remember with my children playing, and we could play at all levels. So, my son was about four and, you know, he was often in a bubble, killed, and floating back onto the screen again. But, you know, we had a great time. And I was suddenly, like, looking, thinking, this is amazing. You know, nobody hears about this side of it that it's bringing us together. And so, from there, I then started doing after-school gaming clubs, so not coding clubs, nothing like that. It was gaming. And the young people they loved it. It was oversubscribed. Masses of kids came to it.

+ +

We had all sorts of things from Super Smash Bros, if you know that, to, you know, to PlayStation games, Go Simulator, and everything playing. And we just had a whale of a time, and they could really relax and make friends. And, again, it was all coming from the joy of gaming together, basically. And it's, you know, as much as some people might not like it, it's bigger and bigger. It's the biggest entertainment industry now.

+ +

And, you know, on the other side of it, there are so many careers in it. If your young person has an interest in gaming, see what they're interested, help it, champion it because it's, yeah, you know, there's such a future there. But yeah, that's my story, basically, and where that sort of light bulb came from.

+ +

And then, I've done a lot of research into the benefits of gaming and how you can use that for connecting with young people. And, you know, so many games now have characters with, you know, emotional things going off, or, you know, you can talk about feelings even in games like Minecraft where the characters don't talk. But you can be like, how must that person be feeling there? And, you know, you can really bring in real-life situations while gaming and also have a lot of fun, which I think is super important as well, which sometimes gets forgotten about. But, you know, real life is really enhanced by having loads of fun, and gaming's fun.

+ +

SAMI: Yeah. It's so fascinating. As you're speaking, I'm having this internal dilemma, right? Because, in my head, everything you're saying is true and makes sense. And I believe it, and I've seen it. And then, I probably still harbor those feelings that are almost entrenched, like you're saying, in the media with, you know, the person who completed Tetris. And those sorts of feelings are still, like, a little bit entrenched to me in terms of the negative sides of gaming.

+ +

Like, I guess I grew up probably similar to you, where it was like, "Well, why aren't you outside more?" and the negative aspect of it. I spoke about this in a different podcast, which I've apologized to my parents for mentioning in public. But when I was in university, it's too late now, I also kind of developed, I would call it probably, like, a small gaming addiction. I don't know where it would sit, but I was doing all-nighters Playing Call of Duty, Modern Warfare. And so, there definitely is a negative side. But I like what you say about, well, actually, you can address that in a healthy way.

+ +

But then, this week, just this week, which is quite uncanny, my seven-year-old comes, and he says, "Daddy, I really want to get an Xbox, you know, my friend's got one." And he's just starting to get to that cusp of gaming. So, in my head, I say, yeah, like that makes total sense, and I imagine the benefits and the fun time me and him could have on an Xbox. But I still struggle with those feelings of...maybe they're my own worries of, well, but what if he neglects his other stuff? What if he goes into like, yeah, with ADHD, he goes into hyperfocus, and that's all he does? How [laughs] can you counsel me out of this concern?

+ +

DAN: Well, no, I completely understand, and that is where all our fears come from, especially our generation and how it's put through. But I think young people more and more connect through gaming, whereas I think when we were gamers as young, a lot of stuff wasn't online. So, we weren't playing with our friends. We were playing on our own a lot of the time, whereas it's very social now. Platforms like Roblox and Minecraft are the things that are super social, working together as a team, things like that.

+ +

But also screen time, I can show you that we've got a whole list of benefits of gaming, actually, that I'll share with you because there's studies that even screen time has been proven not to be detrimental the way we're told it is. And I think we must know that through how we work. Most of us work on screens these days, so.

+ +

SAMI: Yeah, that's such a point of contention in the house because we currently do only on Fridays. So, they get, like, two hours of screen time. I don't know if that's strict. I don't know where I am on that. Do you have, like, with your own kids, or how do you handle that discipline? So, let's say I get the console, right? I bring it into the house to my seven-year-old. Do I limit it with screen time? How would you approach that sort of thing?

+ +

DAN: Obviously, with a seven-year-old, it's a little bit different from...mine are now 17 and 14. So, we discuss it more, but yeah, definitely, you know, have boundaries. And also, if you're worried about how they're gaming, maybe have the Xbox in the living room, so instead of gaming in their bedroom, they're gaming when you're around, and it's a shared family activity. And then, it's easier to say, "Well, we're going to be having food in a minute. So, finish up on that game." And you can have all that understanding.

+ +

But I think also, you know, that other side of things of coming from seeing what they're playing. I talk to parents a lot about this, and they get, you know, they see frustrations in their young people when they're trying to get them off. But they don't realize that maybe they're playing something like Fortnite or something that's a bit more online team-based, where if they pulled them off the game in the middle of the match, it could be detrimental to the team they're working with, their rankings. You know, they could even get banned from the game for a few days, you know.

+ +

So, understanding and them being able to work time management together, being like, "Well, after this game is finished, this is where we're going, you know, we've got to go out. We've got to do this," you know, there is a give and take there. And I'm not saying there isn't negatives to gaming. We need, you know, everybody needs a break as well. But, again, through the understanding of what they're playing, you can have those conversations. If you're not playing them or watching them and don't understand what the game is about, and what the joy is about, there's going to be a gap between you, you know, where the young person is going to be like, "You don't understand me. You don't understand why I want to play this."

+ +

My kids, you know, we went from the other [inaudible 17:37] because they've had severe problems at school, both of them, through their neurodivergency, and gaming has really helped them both to regulate. And maybe when you're saying about yourself when you had problems, and maybe there was something else going on. And then, the gaming was a way for you to cope, that safe space to go to that was actually working in a way as a little bit of therapy and keeping you grounded, you know, as well. So, you know, there's two sides to see it.

+ +

But yeah, definitely, I can understand the worries of staying up all night playing it or not doing your homework and playing it, although I have different things to say about homework. But to say it's not actually beneficial is wrong because, you know, you just got to look at something like Minecraft and the amount a young person can learn, everything from biomes, and blocks, and diamonds, or ores to actual mathematics and things. And it naturally leads onto PCs and learning how to code things and who knows where that's going to lead, to creating something completely new.

+ +

So, I worry for the ones that are heavily restricted on screen time. I worry that they're being held a little bit back. You know, that might sound a bit controversial for some people. But when most jobs are digital and you're not allowed to learn, I mean, the young people I see they're so gifted at such a young age in understanding digital things that they're going to be at the forefront of the new technology. So, it's almost like, yeah, I think it should be embraced with both hands.

+ +

RÉMY: There's an incredible opportunity to learn new things through video games and to be happy and to share, like you said. And I bet our audience is already quite open to video games, but we never know it. I think it could be interesting if you could provide, like, a very simple, not comprehensive list of famous games and the kind of skills and benefits they provide you. You mentioned Minecraft; you mentioned creativity. But what kind of games and skills benefits you? You could say for our audience to understand more about the opportunity that is out there.

+ +

DAN: Yeah, I mean, there are so many. But yeah, so, if we look at your normal shooter game like Call of Duty, and Fortnite, and things like that, that is for cognitive ability. You know, getting those dexterity in your hands and learning those [inaudible 20:11] of pressing buttons is more than you think. It's really training that brain and getting that brain working really quick. It's proven to boost your brain power, your gray matter. It's actually proven that gaming, in general, just boosts your gray matter.

+ +

I mean, we all know about doing brain training games, but all games using that brain, you know, it's much more advanced than sitting watching TV. But then if you go into more things like puzzle games, so things from your Tetris all the way through to more advanced ones like Portal or strategy games like Civilization and things, there is so much you're doing. You're boosting that brainpower, and you're thinking all the time.

+ +

But then you can get into...yeah, back onto the shooter games as well, they help with spatial recognition. So, it's actually helping to spot things from a distance: dangers or things to collect. You can see them, and it actually enhances eyesight. It is proven to enhance eyesight, which is great. Decision-making and leadership skills, which is a key thing people talk about for business, is all there when you're in your team of shooters. You're playing Overwatch or you're playing, you know, any game like that. You know, there's always somebody leading or, you know, saying what should be best, seeing the best strategies in there.

+ +

Problem-solving comes into all sorts so, obviously, in shooters and things again, I'd- say, but also your Minecraft. You know, you've got to create a certain thing to defeat the dragon or whatever you're doing. There's always something, or if you're building something. But then, of course, your high-end puzzle games and even things like Mario. I mean, they get so complex in the problem-solving to overcome a level. Again, the brain power, and the brain power seeing these young people that they're way more advanced than we were playing games. The games are so intricate and so hard now.

+ +

One you never hear about is social skills until...I think the pandemic helped that a bit. People started to see, oh, Animal Crossing, it's a great way to connect with people. And, you know, and Roblox as much as it gets a lot of bad press, for young people to connect and play, and lot of it is almost like playground role playing play, and they're playing together. You know, there's games just based in Ikea, and they're shopping, and [laughs] things like that. It's really good for them to be doing that.

+ +

And health and fitness surprisingly, of course, is in gaming. So, obviously, a lot of Nintendo Switch games are sort of standing up, you know, playing switch sports and things, but then virtual reality is huge for that. And if you've ever tried Beat Saber, that's a real workout, which is really good. But there's loads of boxing ones. There's one that kids play now called Gorilla Tag, where, oh my God, that is such a workout. I have mentees that I work with, and then we'll be like, "Oh, Gorilla Tag," an hour of that, I am exhausted. Because you're just flinging your arms around like a gorilla trying to move fast. It's amazing.

+ +

SAMI: I saw a post you did recently about there's, like, a Greek mythology level on Fortnite, like, an educational aspect [laughs]. It's so funny because I remember playing God of War on the PS2, and I learned so much about Greek mythology. Everything I know comes from God of War. And so, there's also that educational aspect.

+ +

DAN: Yeah, exactly. You get this deep dive into something, and you really find what you're interested in. So, I've got a kid, and he loves this game called War Thunder, which is all about planes, World War planes, and he can tell me everything about every plane and what country it's made. He can spot it a mile off. You know, "Oh, that's a Russian plane from so and so. Its weak points are here. It was built by so and so." And it's like, you're a genius, and it's all come from, you know, this game's sparked this real interest.

+ +

And, you know, like I said, Fortnite brings it in, God of War, of course. Assassin's Creed is amazing for things like that, history, it goes from Egypt times. And they even now have walkthroughs in the game where...this needs to be used in schools. I don't know if schools embrace it yet, but you don't have any of this story and the killings and stuff. You just are going through history and walking through the towns and things like that, which is brilliant. The latest one for Assassin's Creed was Vikings, wasn't it? And that was brilliant because that brought in the UK and how it was when the Vikings came over. There's so much stuff.

+ +

I've got a young person, and he loves this game called For Honor, which is all about medieval sword fights. And he got such an interest in weapons that he's then become a blacksmith. He's enrolled onto a college course apprenticeship being a blacksmith. He wants to be making armory and swords for movies. You know, he said like, "Look, Lord of the Rings, that's all made properly, isn't it?" I mean, that's [inaudible 24:50]

+ +

SAMI: Wow.

+ +

DAN: Yeah, it's amazing. One other thing that the games bring, which I think is amazing, is mindfulness as well. There's a huge thing of that. Yeah, like I said, going back to maybe yourself when you were gaming at night, and you maybe needed to destress and maybe take your mind off something, you can get into a game and almost...there's a thing called the grind in the game. Minecraft has it a lot, where you've just got to get yourself a hundred diamonds, or whatever [laughs].

+ +

So, it's like, you can almost turn your brain off and just do that, you know, and it can be so super relaxing. And you can get into this thing called flow state. A lot of driving games are like that. If you hit every corner perfectly, you're kind of just in this dream-like state where you just...everything's going well. And that brings a euphoria, too. There's so many good things.

+ +

But now there's loads of games that are actually based around mindfulness. Tetris is one that's been proven for that. But I don't know if you've heard a more recent one called PowerWash Simulator. Now, this game was one of my most favorite for the last couple of years. All you're doing is washing stuff with a power washer. But the way it works, it gives you a little ding when you've cleaned something properly, like a [vocalization]. And it just...you stand back and look at your job. Honestly, it's amazing. But now Oxford University are doing a full study on it because they realize how beneficial it is to relaxing and chilling out, you know, and just making yourself just feeling happy when you need to just de-stress. It's amazing.

+ +

RÉMY: I can totally relate. I remember a few years ago, I played GTA 5, and GTA 5 is the kind of game famous for arbitrary violence or all this kind of stuff we hear in the media. But I remember me playing and sometimes I wanted to play just to take a bike and to go on the road and to see a sunset. And, of course, we could argue that I can see the sunset out there, but, in a game, it's just a piece of art.

+ +

At work, recently, we just had a conversation about beautiful games. So, we weren't interested in all the features or how the game would work but just how beautiful it is. And sometimes we just play video games because they're beautiful. And so, they could provide so much on the intellectual level, on the skills, but also, just as piece of art, just beautiful things made by beautiful artists.

+ +

DAN: Yeah, it is amazing when you see that. And yeah, I get that completely with GTA. It gets a lot of bad reputation, you know, and story-wise, it is very adult. But, you know, it's the biggest game in the world for a reason. And, you know, like you said, you climb the mountain, you look at the view, you know, it is such a lovely thing to do.

+ +

There was a game, Red Dead Redemption. I had a young lady I was mentoring, and she was situationally mute, which means, you know, she couldn't talk to anybody. She used to type her responses to me. But she loved Red Dead Redemption, loved horses. And she actually created a group from all around the world, where they would all meet her on a Friday in the game, and she would take them on horse trails.

+ +

And so, this is all in the game, and she would just take them around to beautiful spots, do nice little jumps with the horses, setting up camp, you know, and, I mean, that's [inaudible 28:08]. It's amazing. And yeah, she ended up making a horse game on Roblox, and that doing really well, and her actually working for Roblox themselves. So, yeah, you know, it all inspires them to work on that.

+ +

And, I think, sorry, I'm going on tangents here, but also, as you say, appreciating art. There are so many different sides to gaming. A lot of people used to think gaming is just coding, and I don't want to be a coder. That's confusing. I don't want to do that. If you look at the credits that roll on a main game, and they go on for, like, about an hour. There are so many different jobs from artists, storyboard writers, level designers, musicians. There's everything there. The coders are just one part of it.

+ +

So, as I said before, there are so many career opportunities there, either starting up your own business as a self-employed person or getting involved in it. One I love...a lot of the neurodivergent people I work with [inaudible 29:07] is being a games tester. Because the first thing my son ever does is, if he gets a game, he tries to break it. He tries to find where he can walk through a wall, or something like that. So, it's like that job would be ideal for you. It's like, it's amazing. And that's a job. That's a really important job as well.

+ +

SAMI: Yeah. When you talk about these stories, they are inspirational. Like, I feel like almost, like, a flutter in my heart as you talk about this kid who maybe felt he has kind of no hope or very little opportunities to actually honing in on this Viking game and then being able to go and become a blacksmith, or this other person you mentioned who's now with Roblox. Yeah, I almost wish, like, they had more publicity around them. And maybe we're kind of doing some of that work now. What would you say is your biggest success story?

+ +

DAN: I guess MindJam in itself I think is just, I mean, it's way bigger than me now. Obviously, it was born from this idea of giving young people the time and the respect. They are doing something that they love to do and is beneficial. That's what I found was everybody...even when I was teaching, we used to have this connection with the kids, and I used to work one-to-one with the, you know, special education needs, young ones. And a great connection talking about gaming, and their eyes would light up. They would talk about their week, and how they were feeling, and what they achieved.

+ +

But then it would always be, in the back of my mind, we need to get back onto what we're supposed to be doing and, you know, I need to tick these boxes. And there's always something wanted from them. And it's the same if they go and see a health service. There's always something that they want from that young person. Yet if you just approach them and say, "You know, let's do what you want to do." It's child-led. It's low demand, and let's see where that takes us. That's where we got to discovering about the blacksmith thing. And that's why we've got young people making albums and things with MindJam. You know, it goes anywhere. I've got one young person who shows me Tai Chi, you know, that's our MindJam session. It started off from Rocket League. So, it can really go anywhere.

+ +

But yeah, sorry, going back to the big success, it is every day now I get a message saying how one of my mentors has helped a young person to help the whole family. That is just the best thing in the world. You know, this is something we've created, and we work hard. We work really hard to make sure we've got the best people.

+ +

You know, and we're well-trained, and informed, and everything. To hear that it's really making such a difference, and, you know, some people say we're saving lives, and, you know, I just have to pinch myself. Me and my wife we were just like, we can't believe it really how amazing it is. But we're just on a mission now to make sure it's accessible for as many people who need it.

+ +

SAMI: Yeah, I've seen some of the reviews on your website, and they're heartwarming. But, like, it kind of makes sense, right? Like, for some people, this is the only place that they feel safe. They feel comfortable. You imagine all the cortisol that's going through someone when they're in that fight or flight moment, and there's lots of stress and anxiety. And they enter into a gaming world, and they can escape. And all of a sudden, that reduces. You're dealing with a different person. You're dealing with someone who feels happy, who feels content.

+ +

And then, you're opening up their mind to have other conversations, you know, like you say. I really recommend it to our listeners. Go and check out the stream. You do kind of...I've seen you've done a few episodes of streaming with other mentors. And it's fascinating to see how all of you, whilst you're playing, are in a conversation about, "Oh, how was your week? And how's that been going?" And, you know, something happened over there. And it's like, you're just in a more of a relaxed state to have those conversations.

+ +

DAN: Yeah, you know, it's been used before, you know, LEGO therapy is kind of like that. You know, that's what MindJam is in a way is play therapy, but there's so much more you can do with the digital platform. And we're at an amazing age as well, where most bits of software are free. I'll click on like, you know, if they want to look into 3D modeling, it's easy to get a copy of Blender. If you want to get into Unity or Unreal Engine, I mean, there's always into...and it's all, you know, what a wonderful time. When we were younger, if I wanted to get into game design, it was so complicated. You didn't know where to start where, you know, so yeah, it's really amazing.

+ +

And another thing that I love as well is the mentors that work for us. Most of them are really [inaudible 33:28]. I struggled when I was in my early twenties, and I remember seeing a counselor. And it felt like they had no idea what they were...yeah, they're reading from a textbook, you know, and I remember just really patronizing me. And I was just like, you've got no clue. Whereas I think all the mentors we have all said, "I wish MindJam was around when I was a young person."

+ +

And I thought, that's the key thing for me, their empathy, their understanding. We don't have to solve it straight away. It's just being there and going, "Yeah, that is hard. Yeah, you know, you'll be okay though. And there's, you know, you're not on your own here." And, you know, I think that is...so many people seem to have to try and heal people straight away. And it's like, no, people just need time to talk, and it's the same as adults as well. Yeah, it could just carry on really to all ages really, couldn't it?

+ +

SAMI: Yeah. And you've also got that buy-in, right? Whereas, you know, I think of myself perhaps going to therapy at that young age. I didn't really buy into it because I was sitting there with an adult who I didn't really know what we were doing. And I was just kind of there for a conversation. And here you've got...you're doing something that they like, and they enjoy.

+ +

To put my parent and adult hat back on [laughs] because it's something I want to pick your brains on, right? So, working in the tech industry and working in coding, I've read articles about games, which kind of it says that they're more and more...you see it maybe more on the games on the mobile phone. So, they're employing, like, these kind of gambling tactics, so a lot of the stuff where it's treasure chests. And what is it? On Fortnite, it's the packs. On FIFA, it's also, like, you open up the pack and you see what players you get.

+ +

So, that sort of stuff I also find scary where I feel like you have from the industry...so, whilst you're using the industry in this way, is the industry itself there to promote and perpetuate the benefits that come from games? Or are they looking, I want to get people in; I want to get them hooked; I want to use these gambling techniques, A/B testing, whatever it is?

+ +

DAN: From all big companies, we get both sides, obviously. So, you got your unscrupulous ones that, oh, go for it. You loot boxes. But I think more and more, especially with young people, they're more and more aware. They're far more savvy than we are in these things. And the good one is EA with, you know, FIFA. They get review bombed because as soon as someone's putting in loot boxes and things, people are just like, you're just after our money. This is a con. It's pay to win. Mobile games are the worst for it, of course. You know, they're quick cash-making things.

+ +

Again, instead of, like, saying, "All gaming is evil. We should never do it," it's being aware and being aware of what these games are trying to do, which, again, when you're looking at a young child, is having shared gaming experiences. So, you can go, "Ah, can you see what they're doing here? You know, they've hooked us in. We've played this for two minutes, and we've had free play. And now they're asking us to pay five pounds for extra things. That's a bit of a con, isn't it?" And, you know, you can actually bring that awareness, and then they're not going to fall for things like that.

+ +

But at the other side of it, I see firsthand...I've luckily enough to work closely with Sony. One of their great companies is called Media Molecule. I don't know if you've heard of them. They did LittleBigPlanet, and lately, they had a game called Dreams, which is actually making games on a PlayStation, which is really cool. But they're so accessible. It's all about, you know, making everybody happy, giving people the keys to creativity, and really help making everything accessible.

+ +

Again, they worked with this wonderful, wonderful artist who created characters, character designs. They'd never met her. She was so socially anxious. She never could leave her house but was actually one of their top artists that they would send the work, send the brief. She'd send this amazing art back, and then they'd pay her. They didn't have to come into the office nine till five for no reason whatsoever. And there's a lovely side, and, of course, there's a business unscrupulous side.

+ +

And yeah, again, bring that education of that. This is what I think should be in schools. Instead of avoiding the whole issue, is actually talk about being toxic gamers and what that means, and how to deal with toxic gamers, and how not to be a toxic gamer yourself. For those that don't know toxic gamers, it's just people that are really, really mean to everybody, which seems to be a set thing that people do, especially to a new player. It's like, learn how to encourage people in. And there's now games coming out where they ban people straight away if they're being toxic, and it's all about helping that new player feel like part of the team.

+ +

But again, yeah, let's say if this was actually brought into education, so then we learn about loot boxes and, you know, pay-to-win type games, then young people would be on that same wavelength. They would get it, either that or it would make gaming so lame that no one would play gaming anymore because it's in schools [laughs]. Like, oh, it sucks now [laughs].

+ +

SAMI: Yeah, I think that that way that you embrace kind of what gaming is and you say, well, actually, we can see that it's got a benefit. We can see that it's positive. How do we get the absolute most out of this? How can we not hide, stick our heads in the sand to the issues that might be there? And how can we then say, "Let's use this?"

+ +

And I think, I mean, my mom will be listening to this podcast for sure. But I think it's something which it's quite disruptive what you're doing. I really do feel that way kind of dabbling in gaming, working as a consultant in the coding industry. I actually teach neurodivergent kids as well on the side. And I'm actually mentoring another kid in coding as well. And what you're doing, as I said at the beginning, it's mind-blowing, and we could talk to you for hours.

+ +

We have a little chat on this podcast, which listeners can't see. And I asked Rémy, like, "Do you have any questions before you want to wrap up?" And Rémy was just like, "I just want to keep listening. I'm loving it." And I'm exactly...I feel like we can listen to...I think me and Rémy game and we dabble here and there as well ourselves. So, it's definitely something which speaks to us so much. But I've got to thank you so much for your time, for taking the time to jump on with us, give us such an insight into the work that you're doing with MindJam.

+ +

Let's talk about the BAFTA Young Game Designers Award Ceremony Open Day. Give us some info.

+ +

DAN: Oh yeah. Well, this is a lovely thing. I've luckily enough to be involved with BAFTA on this for a few years. An early success of MindJam was I was nominated as Mentor of The Year and finalist for Mentor of The Year for BAFTA in 2021. And they run this thing called Young Games Designers every year, and it's brilliant because they do...it's two sides to it. One is actually making a game, but then, of course, not all young people are ready to make a game. And, you know, so the other side is a games concept where you could just send in sketches, ideas, things like that. And that's really accessible for lots of young people we work with, of course.

+ +

But yeah, in July, I don't have the date; it's early July, we have the award ceremony, which is on this Saturday. But then on the Sunday at BAFTA in London, it's an open day for families to come. You have to apply and get a ticket. I'm sure you guys can put the link on here later on. But yeah, MindJam will be there, but there's loads of game places. I think TT Games will be there who make the LEGO games. And there's all sorts of...we have D&D there. We have all sorts and talks on how to get into the industry and things like that. So, it's really a great thing to come to if you're a young person who's interested in gaming.

+ +

SAMI: That's really cool. So, parents, if you're listening, save up all that screen time so you can use it. A month's worth of screen time [chuckles] at the BAFTA Awards, Young Game Designers Awards Ceremony in the Open Day in London.

+ +

If people want to get hold of you, Dan, where's the best place? They've heard this. They're inspired. They feel like they've got someone who would benefit from your services. Where's the best place to get in touch?

+ +

DAN: If you go to our website, it's mindjam.org.uk, and you can email us at hello@mindjam.org.uk. And I think you said this podcast is international, isn't it? So, we do offer sessions all around the world. We have mentors in America, in Australia, in Japan, all over the place basically. MindJam is universal. So, wherever you are, get in touch. And if you're interested in being a mentor as well, get in touch as well, so...

+ +

SAMI: Definitely, I highly recommend. And I've already got people I can think of that I'm going to be passing your details on to.

+ +

Listeners, listeners, listeners, our lovely listeners, no one likes missing out on things. Remember that flight you missed? The train that passed you by? Your partner's birthday? I've been there, by the way; I missed one recently. It's a horrible feeling. I cannot deal with you missing out on these things, but I can make sure that this feeling doesn't come about when it comes to our podcast. So, move your thumb. Yes, you, move your thumb. Hit that subscribe button. I can guarantee you, you will never miss one of our podcasts. And you'll hear amazing guests, just like Dan, as we get them in, and we have great chats together on the Giant Robots on Tour podcast.

+ +

You can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech.

+ +

Thanks for listening. See you next time. Bye.
+ 
+AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+6jsOG7RF + + ]]> + + + + 537: Navigating the Startup Ecosystem with Marc Gauthier + https://podcast.thoughtbot.com/537 + 09845ff9-70e0-410d-89d2-082b9495e678 + Thu, 08 Aug 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Marc G. Gauthier shares his journey from learning QBasic as a child to becoming a startup coach and founder of The Shadow Boxing App. He discusses his experiences in scaling startups, emphasizing the balance between speed and reliability in software development and the challenges of managing rapid team growth. Marc also offers insights on the role of AI in augmenting human workflows and advises developers to view AI as a tool to enhance their capabilities. + 45:49 + no + + + In the latest episode of the "Giant Robots On Tour" podcast, hosts Rémy Hannequin and Sami Birnbaum welcome Marc G. Gauthier, a solopreneur and startup coach, who shares his journey from software development to becoming the founder and developer of The Shadow Boxing App. Marc describes how his interest in software engineering began at a young age with QBasic and evolved through various leadership roles at companies like Drivy (now Getaround) and Back Market. His early passion for gaming led him to learn coding, and over time, he naturally transitioned into management roles, finding excitement in organizing and leading teams while maintaining his love for building products. +During the episode, Marc discusses the challenges and intricacies of scaling startups, emphasizing the importance of balancing speed and reliability in software development. He recounts his experiences in leadership positions, where he faced the dual task of managing rapid team growth and maintaining software efficiency. Marc also shares insights into the startup ecosystem, noting that most startups struggle to achieve success due to a combination of market timing, team dynamics, and resource management. His own venture, The Shadow Boxing App, represents his attempt to return to hands-on coding while leveraging his extensive experience in startup coaching and advising. +Marc also touches on the role of AI in the future of software development, expressing cautious optimism about its potential to augment human workflows and automate repetitive tasks. He advises current and aspiring developers to embrace AI as a tool to enhance their capabilities rather than a replacement for human ingenuity. Marc concludes by highlighting the importance of realistic expectations in the startup world and the need for continuous learning and adaptation in the ever-evolving tech landscape. +Getaround (https://getaround.com/) +Follow Getaround on LinkedIn (https://www.linkedin.com/company/getaround/), Facebook (https://www.facebook.com/getaround), X (https://twitter.com/getaround), YouTube (https://www.youtube.com/getaround), or Instagram (https://www.instagram.com/getaround/). +Back Market (https://www.backmarket.com/en-us) +Follow Back Market on LinkedIn (https://www.linkedin.com/company/back-market/), Facebook (https://www.facebook.com/BackMarketCom), X (https://x.com/backmarket), or Instagram (https://www.instagram.com/backmarket). +The Shadow Boxing App (https://shadowboxingapp.com/) +Follow Marc Gauthier on LinkedIn (https://www.linkedin.com/in/marcggauthier/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +RÉMY:  This is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Rémy Hannequin. +SAMI: And I'm your other host, Sami Birnbaum. +RÉMY: If you are wondering who we are, make sure you find the previous podcast where we introduced the Giant Robots on Tour series by throwing random icebreakers at each other. And find out that Jared likes it when someone takes the time to understand someone else's point of view. +Joining us today is Marc G Gauthier, a Solopreneur and Startup Coach. +Marc, you used to be VP of Engineering at Drivy, now known as Getaround, and also Director of Engineering at Back Market. You also have been a coach and advisor to a startup for over a decade. Currently, your current adventure is being the Founder and Developer of The Shadow Boxing App available on the Apple App Store. We always like to go back to the start with our guests. Everyone has a story, and we are interested in your journey. So, Marc, what led you into the world of software engineering in the first place? +MARC: Hello. Well, happy to be here. And, yeah, I started getting into software development quite a long time ago. I actually learned software development with QBasic when I was something like seven. And, from there, I just kept on learning, learning, and learning and got into school for it, then worked in different startups, and then moved into more leadership position management. And I'm now, like, coaching people and building my own product. +What do you want to get? Because it's broad. I've been doing it for quite a while. Like, I don't think the QBasic days are that insightful. The only thing I remember from that time is being confused by the print comment that I would expect it to print on my printer or something, but it didn't; it just printed on the screen. That's the only thing I have from back then. +SAMI: Why at seven years old? And I'm taking you back too far, but at seven years old, I was probably collecting Pokémon cards and possibly like, you know, those football stickers. I don't know if you had the Panini stickers. +MARC: Oh yeah, I was doing that as well. +SAMI: But you were doing that as well. But then what drove you at that age? What do you think it was that made you think, I want to start learning to code, or play around with the computer, or get into tech? +MARC: [laughs] Yeah. Well, I remember, back then, I really wanted a computer to play games. Like, I had a friend who had a computer. He was playing games, and I wanted to do that. So, I was asking my mom to have a computer, and she told me, "Yeah, you can have one." And she found a really old computer she bought from a neighbor, I think. But she told me like, "I don't know anything about it. So, you have to figure it out and set it up." And she just found someone to kind of help me. And this person told me to, like, take the computer apart. She taught me a bit of software development, and I kind of liked it. +And I was always trying to change the games. Back then, it was way easier. You could just edit a sound file, and you would just edit the sound file in the game, so yeah, just learning like this. It wasn't really my intent to learn programming. It just kind of happened because I wanted to play video games really. +SAMI: That's really cool. It's really interesting. Rémy, do you remember how...how did you first get...do you remember your first computer, Rémy? +RÉMY: My first computer, I think I remember, but the first one I used it was, first, a very long time ago. I discovered that it was an Apple computer way, way later when I discovered what Apple was and what computers were actually. And I just remember playing SimCity 2000 on it, and it was amazing. And we had to, you know, cancel people from making phone calls while we were on the computer because of the internet and all the way we had to connect to the internet back then. +And after that, just, I think, Windows 95 at home. Yeah, that's the only thing I can remember actually. Because I think I was lucky, so I got one quite early. And I don't really remember not having one, so I was quite lucky with that. And so, I was always kind of in the computer game without being too much [inaudible 05:02] [laughs]. +SAMI: Yeah, I think that's similar to me as well. Like, it's interesting because my initial introduction to computers would have been watching my older brothers kind of play computer games and actually being told to get out the room, or like, you know, "We're busy now. Don't bother us." And then, what actually happened is when they left the room, I managed to play what they were playing, which was the first ever GTA. I don't know if anyone ever played this, but it is so cool if you look back on it. You could probably find emulators online, but it was, like, a bird's eye view, like, way of operating. +And it was probably also that drive where you get frustrated on a computer because you want to do something, so, like you were saying, Marc, where you went to edit the sound files because you want to change something. You want to do something. I definitely think that is something which I felt as well is that frustration of I want to change this thing. And then, that kind of gets into well, how does it work? And if I know how it works, then I can probably change it. +MARC: Yeah. And once you figure out how things work, it's also really exciting. Like, once you figure out the initialization file on Windows, like, you can edit, like, what level is unlocked right away. It's kind of cheat codes but not really. And there are some really fun ones. Like, I would edit sound files for racing games. And, usually, it's just a base sound file, and then they would pitch shift the sound to make it sound like an engine. So, if you record your voice, it's just really funny. +RÉMY: So, Marc, you mentioned moving to management positions quite early. Do you remember what made you do this move? Was it for, like, a natural path in your career, or was it something you really wanted from the first part of your career as a developer? What happened at this moment? +MARC: Yeah, that was not completely planned. Like, I don't think I really plan my career precisely. It's just something that happens. So, I joined Drivy after, like, I was already a software engineer for, like, five years at that point. I joined as a lead backend engineer. I did that for three years. And after three years, the company went from...I think there was, like, three software engineers to a dozen. There was a need for more structure, and the CTO, at the time so, Nicolas, wanted to focus more on products. And it was hard to do both, like do the product side, the design, the data, and do the engineering, the software, and so on. +So, he wanted to get a bit away from software engineering and more into product. So, there was a gap in the organization. I was there. I was interested to try, and I was already doing some more things on the human side, so talking to people, organizing, internal communication. I kind of liked it. So, I was excited to try, give it a try. It was really interesting. +I found that it was a different way to have an impact on the team. I just kept doing it. And my plan was to keep doing it until I'm bored with it. And I'm still not bored with it, even though you kind of miss just actually building the software yourselves, actually coding. So, that's also why I'm trying something different right now with my mobile app adventure. +SAMI: Right. So, on the side, you've got this Shadow Boxing App, which, in my dedicated research, I downloaded and had a go with it. +MARC: Did you actually try it, or did you just click around? +SAMI: I did a proper workout, mate. I did. I put myself as, like, the absolute beginner. I did it on my MacBook Pro. I know it's built for iPad or iPhone, but it still worked amazingly well. And it kind of reminded me why I stopped doing boxing because it's hard work. +MARC: [laughs] Yeah, it is. +SAMI: It's not a gimmick this thing, right? So, it's like, the best way to describe it is it's essentially replacing if I was to go to the gym and have a trainer who's telling me kind of the moves to make or how to do it, then this kind of replaces that trainer. So, it's something you can do at home. It was really cool. I was surprised, actually. I thought, at the beginning, it's not going to be that interactive, or it won't actually be as hard or difficult as a workout, and it really was. So, it's, yeah, it was really cool, really interesting to try it. +And going into that, you say you wanted to get back more into coding, and that's why you are doing this kind of, like, app on the side, or it allowed you to kind of do a bit more coding away from the people management. You've been involved in a lot of startups, and I actually often get...as consultants, when we work at thoughtbot, we get a lot of people who come with different startup ideas. When you look back at all the startups you've been involved with, do you think more startups are successful than those that fail? Or have you seen a lot of startups...actually, people come with these great ideas; they want to build this amazing product, but it's actually really hard to be a successful product? +MARC: I think it's [inaudible 10:22] how to have the right idea, be at the right spot at the right time, build the right team, get enough momentum. I think most startups fail, and even startups that are successful often can be the result of a pivot. Like, I know companies that pivoted a bunch of times before finding any success. So, it's really hard actually...if I take my past four companies, only two are still alive. Like, the first two went under. Actually, there's even more companies that went under after I left. Yeah, it's just really hard to get anything off the ground. So, yeah, it's complicated, and I have a lot of respect for all the founders that go through it. +For The Shadow Boxing App, I worked on it for the past three years, but I'm only working on it almost full-time for the past two months. And it was way safer. I could check the product-market fit. I could check if I enjoyed working on it. So, I guess it was easier. I had the luxury of having a full-time job. Building the app didn't take that much time. +But to answer your question, I think, from my experience, most startups fail. And the ones that succeed it's kind of lightning in a bottle, or, like, there's a lot of factors that get into it. It's hard to replicate. A lot of people try to replicate some science, some ideas. They go, oh, we'll do this, and we'll do that. And we use this technique that Google uses and so on, but it's never that straightforward. +SAMI: Yeah, I'm so happy you said that because I think it's a real brutal truth that I'd also say most of the startup projects that I've worked on probably have failed. Like, there's very few that actually make it. It's such a saturated market. And I think, I guess, in your role as advising startups, it's really good to come in with that honesty at the beginning and to say, "It's a big investment if you want to build something. Most people probably aren't successful." And then, when you work from that perspective, you can have, like, way more transparent and open discussions from the get-go. +Because when you're outside of tech...and a lot of people have this idea of if I could just get an app to do my idea, I'm going to be the next Facebook. I'm going to be the next, you know, Amazon Marketplace. And it just kind of isn't like that. You've got these massive leaders in Facebook, Amazon, Google, Netflix. But below that, there's a lot of failures and a massively saturated market. So, yeah, just, it's so interesting that you also see it in a similar way. +MARC: What I saw evolve in the past 10 years is the fact that people got more realistic with it. So, maybe 10 years ago, I would have people coming to me with just the most ridiculous idea, like, you know, I'll do Airbnb for cats. And really think, yeah, I just need a good idea, and that's it. But now I feel like people kind of understand that it's more complicated. There's way more resources online. People are more educated. They also see way more successes. Failures are also a bit more advertised. +We saw a bunch of startups just go under. It feels like every month I get an email from a tool I used in the past saying, "Oh, we're shutting down," and so on. So, I think it's not as bad as 10 years ago where weekly I would have just people asking me, "I want to build this app," and the app would be just the most ridiculous thing or something that would be really smart, but it's really like, "Oh, I want to do, like, food delivery but better than what exists." It's like, yeah, that's a really good idea, but then you need...it's not only software. There's logistics. There's so much behind it that you don't seem to understand just yet. +But, as a coach, so, what I'm doing is I'm helping startups that are usually before or after series A but not too large of startups just go to the next stage. And people are really aware of that and really worried. Like, they see money going down, market fit not necessarily being there. And they know, like, their company is at risk. +And especially when you talk to founders, they're really aware that, you know, everything could be collapsing really quickly. If they make, like, three really bad decisions in a row, you're basically done. Obviously, it depends on the company, but yeah, people are more aware than before, especially nowadays where money is a bit harder to get. Let's say two years ago, there was infinite money, it felt like. Now it's more tight. People are more looking at the unit economics precisely. So, people need to be more realistic to succeed. +RÉMY: What's the kind of recurrent struggle the startups you coach usually face? Apparently, it quite changed in the past decade, but maybe what are the current struggles they face? +MARC: It really depends. It's kind of broad. But, usually, it would be, let's say, a startup after their first round of funding, let's say, if you take startups that are looking for funding. So, you usually have a group of founders, two to four, usually two or three, that are really entrepreneurs that want to bootstrap some things. +They're builders. They're hacking things together, and they're really excited about the product. +And, suddenly, fast forward a few years, they're starting to be successful, and they have to lead a team of, you know, like, 50 people, 100 people, and they weren't prepared for that. They were really prepared to, like, build software. Like, especially the CTOs, they are usually really great hackers. They can, like, create a product really quickly. But, suddenly, they need to manage 30 engineers, and it's completely different, and they're struggling with that. So, that's a common problem for CTOs. And then, it creates a bunch of problems. +Like, you would have CEOs and CTOs not agreeing on how to approach the strategy, how to approach building a thing. What should be the methodology? Something that worked with 3 engineers around the table doesn't work with 50 engineers distributed in 5 countries. And if it's your first time being a CTO, and often founders of early-stage startups are first-time CTOs, it can be really hard to figure out. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +RÉMY: In your past companies, so you've been VP and CTO. So, in your opinion, what's the best a VP or a CTO can bring to a scaling startup? What are your best tips to share? +MARC: I guess it depends [laughs], obviously, like, depending on the stage of the company, the size of the company. For instance, when I was at Drivy, at some point, the most important thing was scaling the team hiring, and so on. But, at some point, we got acquired by Getaround, and the priorities got shifted. It was more like, okay, how do you figure out this new setup for the company and the team? Like, what is good? What is bad? How do you communicate with the team? How do you get people to stay motivated when everything is changing? How do you make sure you make the right decisions? +And then, when I joined Back Market, Back Market when I joined, I had a team of a bit less than 12 engineers reporting directly to me. And after a bit more than a year, I had 60, and I hired most of them. So, here the challenge was just scaling insanely fast. Like, the company is really successful. Like, Back Market is selling refurbished electronics in a mission to, you know, provide a viable alternative to buying new electronics. So, it's basically, do you want a smartphone that is both cheaper and more ecologically viable? And most people would say yes to that. So, a company is insanely successful, but it's really hard to scale. +So, at that point, the role was, okay, how do you make sure you scale as well as possible with a lot of pressure while still leaving the team in a state that they're able to still build software? Because it's just really chaotic. Like, you can't, like, 5X your team without chaos. But how do you minimize that but still go really fast? +SAMI: Yeah. So, not only did I try that Shadow App. I actually went on that Backup website. What's it called? It's not called Backup. What's it called again? +MARC: Back Market. +SAMI: Back Market. Thank you. Yeah, it was really cool. I checked my old iPhone SE from 2020, which I've kept for about...over three years, I've had this iPhone. And they said they would give me $72 for it, which was really cool. So, it sounds like a really cool idea. +MARC: That's something we worked on, which is, basically, if you have any old phones in your drawer, it's a really bad spot for them. And so, there's a service. You go on the website. You say, "I have this, I have that; I have this, I have that." And either we buy it from you, or we just take it away from you, and we recycle them, which is much better than just having them collect dust. +SAMI: Yeah, no, it's a great idea. What interested me when you were speaking about kind of these different positions that you've been in, I was almost expecting you to talk about maybe, like, a technical challenge or code complexity difficulty. But, actually, what you've described is more people problems. And how do we scale with regards to people, and how do we keep people motivated? +So, I guess using that experience, and this might be counterintuitive to what a lot of people think, but what do you think is the hardest thing about software development? I know there could be many things. But if you had to pick something that is the most difficult, and maybe we can all have an answer to what we think this is, but starting with you, Marc, what do you think is the hardest thing about software development then? +MARC: What I saw is how do you build something that works for enough time to bring value to the customers? So, it's easy to hack something together pretty quickly and get it in front of people, but then it might not be reliable. It might break down. Or you could decide to build something perfect and spend, like, two years on it and then ship it, and then it's really stable, but maybe it's not what people want. And finding this balance between shipping something fast, but shipping something that is reliable enough for what you're building. Obviously, if you're building a health care system, you will have more, like, the bar will be higher than if you build, like, Airbnb for cats. +Finding this balance and adjusting as you go is really hard. So, for instance, when do you introduce caching? Because, obviously, caching is hard to do right. If you don't do it, your site will be slow, which can be okay for a time. But then if you introduce it too late, then it's really hard to just retrofit into whatever you already have. So, finding the right moment to introduce a new practice, introduce a new technology is tricky. +And then, like, I talked a lot about the people, and it's also because I spent quite a bit of time in leadership position. But, at the end of the day, it will be the people writing the code that gets the software to exist and run. So, having people aligned and agreeing on the vision is also key because unless I'm the only developer on the project, I can't really make all decisions on things that are going to get built. So, figuring out how to get people motivated, interested in just building in the same direction is really important. It's really easy. +Like, one thing with Drivy, when I was there, that was really fun to see, like, many people have this reaction, especially the more senior people joining the company. They would see the engineering team, and they were really, really surprised by how small it was because we were being really, really efficient. Like, we were paying really close attention to what we would work on. +So, kind of technology we would introduce would be quite conservative on both to really be able to deliver what is the most important. So, we were able to do a lot with, honestly, not a lot of people. And I think this is a great mark for success. You don't need a thousand people to build your software if you ask the right question, like, "Do I need to build X or Y?" and always having these discussions. +RÉMY: What's your opinion on that, Sami? +SAMI: Yeah, I guess it changes. Like, for example, today, the hardest thing about software development was just getting Jira to work. That has literally ruined my whole day. But I've found, for me, what I find is the most difficult thing to do is making code resilient to change. What I mean by that is writing code that's easy to change. And a lot of that, I guess, we try to work on at thoughtbot, as consultants, is following kind of design principles and best practices and certain design patterns that really make the code easy to change. Because that, I think, when I'm writing code is the biggest challenge. +And where I feel when I'm working with our clients one of the biggest things they can invest in, which is difficult because there's not a lot of visibility around it or metrics, is ensuring that code that's written is easy to change because, at some point, it will. And I've also worked on systems which are bigger, and when you can't change them, conversations start happening about the cost of change. Do we rewrite it from the ground up again? And that opens a whole different can of worms. So, that, for me, I think, is definitely one of the hardest things. How about yourself, Rémy? +RÉMY: I don't know about the most difficult. I mean, there are many things difficult. But I remember something that I had to put extra effort, so maybe it was one of the most difficult for me. When I started being a consultant, when I joined thoughtbot was to understand what's the boundary between executing and giving an advice? So, basically, I discovered that when you're a consultant, but it works also when you're a developer in a team, you know, you're not just only the one who is going to write the code. You're supposed to be also someone with expertise, experience to share it and to make the project and the team benefit from it. +So, at some point, I discovered that I should not just listen to what the client would say they want. Obviously, that's what they want, but it's more interesting and more difficult to understand why they want it and why they actually need, which could be different from what they want. So, it's a whole different conversation to discover together what is actually the necessary thing to build, and with your expertise and experience, try to find the thing that is going to be the most efficient, reliable, and making both the client and the customers happy. +MARC: Yeah. And as software engineers, it's really easy to get excited about a problem and just go, "Oh, I could solve it this way." But then you need to step back and go, "Well, maybe it doesn't need fixing, or we should do something completely different." At some point, I was working with a customer service organization. In their workflows, they had to go on, let's say, five different pages and click on the button to get something to do one action. +And so, what they asked for is to have those five buttons on one single page, and so, they could go, click, click, click, click, click. But after looking at it, what they needed is just automation of that, not five buttons on the page. But it's really easy to go, oh, and we could make those buttons, like, kind of generic and have a button creator thing and make it really fancy. When you step back, you go, oh, they shouldn't be clicking that many buttons. +SAMI: Yeah, that makes so much sense because just in that example...I can't remember where I read this, but every line of code you write has to be maintained. So, in that example where you've got five buttons, you're kind of maintaining probably a lot more code than when you've got the single button, which goes to, I don't know, a single action or a method that will handle kind of all the automation for you. And that's also, you know, driving at simplicity. +So, sometimes, like, you see this really cool problem, and there's a really cool way to solve it. But if you can solve it, you mentioned, like, being conservative with the type of frameworks maybe you used in a previous company, like, solve it in the most simple way, and you'll thank yourself later. Because, at some point, you have to come back to it, and maintain it, change it. Yeah, so it makes a lot of sense. +And, Marc, you said you started when you were 7, which is really young. Through that amount of time, you've probably seen massive changes in the way websites look, feel, and how they work. In that time, what's the biggest change you actually think you've seen? +MARC: The biggest thing I saw is, when I started, internet didn't exist or at least wasn't available. Like, I remember being at school and the teacher would ask like, "How many people have a computer at home?" And we'd be like, two or three people. So, people didn't have internet until I was like 14, 15, I'd say. So, that's the biggest one. +But, let's say, after it started, they just got more complicated. Like, so, the complexity is getting crazy. Like, I remember, at some point, where I saw I think it was called Aviary. It was basically Photoshop in the browser, and I was just insanely impressed by just the fact that you could do this in the browser. And, nowadays, like, you've got Figma, and you've got so many tools that are insanely impressive. Back then, it was just text, images, and that's it. +I actually wrote a blog post a few years ago about how I used to build websites just using frames. So, I don't know if you're familiar with just frames, but I didn't really know how to do divs. So, I would just do frames because that's what I understood back then, again, little kid. But it was kind of working. You were dealing with IE 5 or, like, I remember, like, professionally fixing bugs for IE 5.5 or, like, AOL, like, 9, something ridiculous like this. +So, building a website just got way easier but also way more complicated, if that makes sense. Like, it's way easier to do most things. For instance, I don't know, like, 20 years ago, you wanted a rounded corner; you would have to create images and kind of overlay them in a weird way. It would break in many cases. Nowadays, you want rounded corners? That's a non-topic. But now you need, like, offline capabilities of your website. And, in a lot of cases, there's really complex features that are expected from users. So, the bar is getting raised to crazy levels. +SAMI: Yeah, I always wonder about this. Like, when you look at how the internet used to be and how people develop for the internet, and, like you're saying, now it's more complex but easier to do some things. I don't know if as developers we're making things harder or easier for ourselves. Like, if you look at the amount of technology someone needs to know to get started, it grows constantly. To do this, you have to add this framework, and you need to have this library, and maybe even a different language, and then, to even host something now, the amount of technologies you need to know. Do you think we're making things harder for ourselves, or do you think easier? +MARC: Well, I guess there's always back and forth, like, regarding complexity. So, things will get really, really complex, and then someone will go, "Well, let's stop that and simplify." That's why, like, I'm seeing some people not rejecting React and so on, but going a simpler route like Rails has options like this. There's people using HTMX, which is really simple. So, just going back to something simpler. +I think a lot of the really complex solutions also come from the fact that now we have massive teams building websites, and you need that complexity to be able to handle the team size. But it's kind of, then you need more people to handle the complexity, and it's just getting crazy. Yeah, honestly, I don't know. I'm seeing a lot of things that feel too complex for...like, the technology feels really complicated to accomplish some things that should be simple or at least feel simple. But, at the same time, there are things that got so simple that it's ridiculous like just accepting payment. +I remember, like, if you wanted to accept payment on a site, it would be months of work, and now it takes a minute. You just plug in Stripe, and it works. And it's often cheaper than what it used to be. So, it's kind of...or deploying. You mentioned deploying can be really hard. Well, you don't need to have a physical server in your room just eating your place up to have your website, your personal website running. You just push it to Vercel, or Heroku, or whatever, or just a static page on S3. So, this got simpler, but then, yeah, you can get it to be so much more crazy. So, if you host your static website on S3, fairly simple. But then if you try to understand permissions on S3, then, you know, it's over. +RÉMY: I don't know if it's really in the path of our discussion. I just wanted to ask you, so this is the on tour series, where we...so, usually, the Giant Robots podcast used to be a little bit more American-centric, and this on tour is moving back to the other side of the Atlantic with, again, Europe, West Asia, and Africa. You've been part of a company, Drivy, which expanded from France to neighboring countries in Europe. What could you tell our listeners about how to expand a business internationally? +MARC: That's a tough question, especially in Europe. Because I know looking from the outside, like, if you're from the U.S. and you look at Europe, it feels like, you know, a uniform continent, but really, it's very different. Like, just payment methods are different. Culture is very different. +For instance, when I was working at Back Market in France, one of the branding aspects of Back Market was its humor. Like, we would be making a lot of jokes on the website, and it would work really well in France. Like, people would love the brand. But then you expand to other countries, and they just don't find that funny at all. Like, it's not helping at all, and they're expecting a different tone of voice. So, it's not just, okay, I need to translate my own page; it's I need to internationalize for this market. +I guess my advice is do it country by country. Sometimes I see companies going like, oh, we opened in 20 different countries, and you go, how even do you do that? And spend some time understanding how people are using your product or, like, a similar product locally because you would be surprised by what you learn. Sometimes there's different capabilities. +For instance, when Drivy went to the UK, there's so much more you can learn. There's the government database that you can look up, and it really helps with managing risk. If people are known to steal cars, you can kind of figure it out. I'm simplifying a bit, but you can use this. You don't have that in France because we just don't have this solution. But if you go to Nordic countries, for instance, they have way more electric vehicles, so maybe the product doesn't work as well. +So, it's really understanding what's different locally and being willing to invest, to adapt. Because if you go, okay, I'm going to open in the Netherlands but you don't adopt the payment methods that are used in the Netherlands, you might as well not open at all. So, it's either you do it properly and you kind of figure out what properly means for your product, or you postpone, and you do it well later. +Like, right now, I'm struggling a bit with my app because it's open. So, it's on the App Store, so it's open globally. And it's a SaaS, so it's simpler, but I struggle with language. So, it's in French and English. I spoke both of this language, obviously, French better than English. But I think I'm doing okay with both. But I also built it in Spanish because I speak some Spanish fairly poorly, and I wanted to try to hit a different market like the Mexican market that are doing boxing quite a lot. But the quality doesn't seem there. +Like, I don't have the specific boxing lingo, so I'm contemplating just rolling it back, like, removing the Spanish language until I get it really well, maybe with a translator dedicated to it that knows boxing in Spanish. Because I work with translators that would translate, but they don't really know that, yeah, like a jab in boxing. In Spanish, they might also say, "Jab." They won't translate it to, like, [inaudible 38:31]. +SAMI: Yeah. At thoughtbot, we have one of our clients they wanted to release their app also internationally. And so, we had also kind of a lot of these problems. We even had to handle...so, in some languages, you go from left to right, right to left. So, that kind of also changed a lot of the way you would design things is mainly for people who are going from left to right. I mean, that's thinking kind of more Europe, U.S.-centric. And then, you could be releasing your app into a different country where they read the other direction. +So, yeah, a lot of this stuff is really interesting, especially the culture, like you're saying. Do they find this humor funny? And then, how do they translate things? Which, in my head, I think, could you use AI to do that. Which is a nice segue into, like, the mandatory question about AI, which we can't let you go until we ask you. +MARC: [laughs] +SAMI: So, okay, obviously, I'm going to ask you about your thoughts on AI and where you think we're headed. But I've seen something interesting, which I don't know if this is something that resonates with you as well. I've seen a bit of a trend where the more experienced developers or more senior developers I talk to seem to be a bit more calm and less concerned. Whereas I would consider myself as less experienced, and I feel, like, kind of more anxious, more nervous, more jumping on the bandwagon sort of feeling of keeping an eye on it. So, I guess, with your experience, what are your thoughts on AI? Where do you think we are headed? +MARC: That's a big question, and it feels like it's changing month to month. It feels way more interesting than other trends before. Like, I'm way more excited about the capabilities of AI than, like, NFTs or stuff like this. I'm actively using AI tooling in my app. I was using some AI at Back Market. So, it's interesting. There's a bunch of things you can be doing. +Personally, I don't think that it's going to, like, make programming irrelevant, for instance. It will just change a bit how you will build things just like...so, we talked about what changed in the past. For instance, at some point, you would need a team of people moving around physical computers and servers and just hooking them up to be able to have a website. But now, most people would just use a cloud provider. So, all those people either they work for the cloud provider, or they're out of a job. But really what happened is most shifted into something different, and then we focused on something different. Instead of learning how to handle a farm of servers, we learned how to, I don't know, handle more concurrency in our models. +And I think when I look back, I feel like, technically, maybe, I don't know, 70%, 80% of what I learned is now useless. Like, I spent years getting really good at handling Internet Explorer as a web developer. Now it's just gone, so it's just gone forever. And it feels like there's some practice that we're having right now that will be gone forever thanks to AI or because of AI, depending on how you look at it. But then there'll be new things to do. I'm not sure yet what it will be, but it will create new opportunities. There are some things that look a bit scary, like, or creepy. But I'm not worried about jobs or things like this. +I'm a bit concerned about people learning programming right now because, yeah, there's a lot of hand-holding, and there's a lot of tools that you have to pay to get access to this hand-holding. So, if you're a student right now in school learning programming and your school is giving you some AI assistant, like Copilot or whatever, and this assistant is really good, but suddenly it goes away because you're not paying anymore, or, like, the model change, if you don't know how to code anymore, then it's a problem. Or maybe you're not struggling as much. And you're not digging deep enough, and so you're learning slower. And you're being a bit robbed of the opportunity to learn by the AI. So, it's just giving you the solution. +But it's just, like, the way I use it right now, so I don't have an assistant enabled, but I usually have, like, a ChatGPT window open somewhere. It's more like a better Stack Overflow or a more precise Stack Overflow. And that helps me a lot, and that's really convenient. Like, right now, I'm building mostly using Swift and Swift UI, but I'm mainly a Ruby and JavaScript developer. So, I'm struggling a lot and being able to ask really simple questions. +I had a case just this morning where I asked how to handle loading of images without using the assets folder in Xcode. I just couldn't figure it out, but it's really simple. So, it was able to tell me, like, right away, like, five options on how to do it, and I was able to pick the one that would fit. So, yeah, really interesting, but yeah, I'm not that worried. The only part I would be worried is if people are learning right now and relying way too much on AI. +RÉMY: Well, at least it's positive for our job. Thank you for making us believe in a bright future, Marc. +MARC: [laughs] +RÉMY: All right. Thank you so much, Marc, for joining us. It was a real pleasure. Before we leave, Marc, if you want to be contacted, if people want to get a hold of you, how can you be contacted? +MARC: There's two ways: either LinkedIn, look up Marc G Gauthier. Like, the middle initial is important because Marc Gauthier is basically John Smith in France. My website, which is marcgg.com. You can find my blog. You can find a way to hire me as a coach or advisor. That's the best way to reach out to me. +RÉMY: Thank you so much. And thank you, Sami, as well. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm. You can find me on social media as rhannequin. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening, and see you next time. + AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + software engineer, startup coach, solopreneur, The Shadow Boxing App, scaling startups, software development, AI in software, tech leadership, startup success, software engineering journey, Drivy, Getaround, Back Market, startup challenges, AI automation, tech ecosystem, leadership in tech, software reliability, balancing speed and reliability, tech startups + + In the latest episode of the "Giant Robots On Tour" podcast, hosts Rémy Hannequin and Sami Birnbaum welcome Marc G. Gauthier, a solopreneur and startup coach, who shares his journey from software development to becoming the founder and developer of The Shadow Boxing App. Marc describes how his interest in software engineering began at a young age with QBasic and evolved through various leadership roles at companies like Drivy (now Getaround) and Back Market. His early passion for gaming led him to learn coding, and over time, he naturally transitioned into management roles, finding excitement in organizing and leading teams while maintaining his love for building products.

+ +

During the episode, Marc discusses the challenges and intricacies of scaling startups, emphasizing the importance of balancing speed and reliability in software development. He recounts his experiences in leadership positions, where he faced the dual task of managing rapid team growth and maintaining software efficiency. Marc also shares insights into the startup ecosystem, noting that most startups struggle to achieve success due to a combination of market timing, team dynamics, and resource management. His own venture, The Shadow Boxing App, represents his attempt to return to hands-on coding while leveraging his extensive experience in startup coaching and advising.

+ +

Marc also touches on the role of AI in the future of software development, expressing cautious optimism about its potential to augment human workflows and automate repetitive tasks. He advises current and aspiring developers to embrace AI as a tool to enhance their capabilities rather than a replacement for human ingenuity. Marc concludes by highlighting the importance of realistic expectations in the startup world and the need for continuous learning and adaptation in the ever-evolving tech landscape.

+ + + +

Transcript:

+ +

RÉMY:  This is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Rémy Hannequin.

+ +

SAMI: And I'm your other host, Sami Birnbaum.

+ +

RÉMY: If you are wondering who we are, make sure you find the previous podcast where we introduced the Giant Robots on Tour series by throwing random icebreakers at each other. And find out that Jared likes it when someone takes the time to understand someone else's point of view.

+ +

Joining us today is Marc G Gauthier, a Solopreneur and Startup Coach.

+ +

Marc, you used to be VP of Engineering at Drivy, now known as Getaround, and also Director of Engineering at Back Market. You also have been a coach and advisor to a startup for over a decade. Currently, your current adventure is being the Founder and Developer of The Shadow Boxing App available on the Apple App Store. We always like to go back to the start with our guests. Everyone has a story, and we are interested in your journey. So, Marc, what led you into the world of software engineering in the first place?

+ +

MARC: Hello. Well, happy to be here. And, yeah, I started getting into software development quite a long time ago. I actually learned software development with QBasic when I was something like seven. And, from there, I just kept on learning, learning, and learning and got into school for it, then worked in different startups, and then moved into more leadership position management. And I'm now, like, coaching people and building my own product.

+ +

What do you want to get? Because it's broad. I've been doing it for quite a while. Like, I don't think the QBasic days are that insightful. The only thing I remember from that time is being confused by the print comment that I would expect it to print on my printer or something, but it didn't; it just printed on the screen. That's the only thing I have from back then.

+ +

SAMI: Why at seven years old? And I'm taking you back too far, but at seven years old, I was probably collecting Pokémon cards and possibly like, you know, those football stickers. I don't know if you had the Panini stickers.

+ +

MARC: Oh yeah, I was doing that as well.

+ +

SAMI: But you were doing that as well. But then what drove you at that age? What do you think it was that made you think, I want to start learning to code, or play around with the computer, or get into tech?

+ +

MARC: [laughs] Yeah. Well, I remember, back then, I really wanted a computer to play games. Like, I had a friend who had a computer. He was playing games, and I wanted to do that. So, I was asking my mom to have a computer, and she told me, "Yeah, you can have one." And she found a really old computer she bought from a neighbor, I think. But she told me like, "I don't know anything about it. So, you have to figure it out and set it up." And she just found someone to kind of help me. And this person told me to, like, take the computer apart. She taught me a bit of software development, and I kind of liked it.

+ +

And I was always trying to change the games. Back then, it was way easier. You could just edit a sound file, and you would just edit the sound file in the game, so yeah, just learning like this. It wasn't really my intent to learn programming. It just kind of happened because I wanted to play video games really.

+ +

SAMI: That's really cool. It's really interesting. Rémy, do you remember how...how did you first get...do you remember your first computer, Rémy?

+ +

RÉMY: My first computer, I think I remember, but the first one I used it was, first, a very long time ago. I discovered that it was an Apple computer way, way later when I discovered what Apple was and what computers were actually. And I just remember playing SimCity 2000 on it, and it was amazing. And we had to, you know, cancel people from making phone calls while we were on the computer because of the internet and all the way we had to connect to the internet back then.

+ +

And after that, just, I think, Windows 95 at home. Yeah, that's the only thing I can remember actually. Because I think I was lucky, so I got one quite early. And I don't really remember not having one, so I was quite lucky with that. And so, I was always kind of in the computer game without being too much [inaudible 05:02] [laughs].

+ +

SAMI: Yeah, I think that's similar to me as well. Like, it's interesting because my initial introduction to computers would have been watching my older brothers kind of play computer games and actually being told to get out the room, or like, you know, "We're busy now. Don't bother us." And then, what actually happened is when they left the room, I managed to play what they were playing, which was the first ever GTA. I don't know if anyone ever played this, but it is so cool if you look back on it. You could probably find emulators online, but it was, like, a bird's eye view, like, way of operating.

+ +

And it was probably also that drive where you get frustrated on a computer because you want to do something, so, like you were saying, Marc, where you went to edit the sound files because you want to change something. You want to do something. I definitely think that is something which I felt as well is that frustration of I want to change this thing. And then, that kind of gets into well, how does it work? And if I know how it works, then I can probably change it.

+ +

MARC: Yeah. And once you figure out how things work, it's also really exciting. Like, once you figure out the initialization file on Windows, like, you can edit, like, what level is unlocked right away. It's kind of cheat codes but not really. And there are some really fun ones. Like, I would edit sound files for racing games. And, usually, it's just a base sound file, and then they would pitch shift the sound to make it sound like an engine. So, if you record your voice, it's just really funny.

+ +

RÉMY: So, Marc, you mentioned moving to management positions quite early. Do you remember what made you do this move? Was it for, like, a natural path in your career, or was it something you really wanted from the first part of your career as a developer? What happened at this moment?

+ +

MARC: Yeah, that was not completely planned. Like, I don't think I really plan my career precisely. It's just something that happens. So, I joined Drivy after, like, I was already a software engineer for, like, five years at that point. I joined as a lead backend engineer. I did that for three years. And after three years, the company went from...I think there was, like, three software engineers to a dozen. There was a need for more structure, and the CTO, at the time so, Nicolas, wanted to focus more on products. And it was hard to do both, like do the product side, the design, the data, and do the engineering, the software, and so on.

+ +

So, he wanted to get a bit away from software engineering and more into product. So, there was a gap in the organization. I was there. I was interested to try, and I was already doing some more things on the human side, so talking to people, organizing, internal communication. I kind of liked it. So, I was excited to try, give it a try. It was really interesting.

+ +

I found that it was a different way to have an impact on the team. I just kept doing it. And my plan was to keep doing it until I'm bored with it. And I'm still not bored with it, even though you kind of miss just actually building the software yourselves, actually coding. So, that's also why I'm trying something different right now with my mobile app adventure.

+ +

SAMI: Right. So, on the side, you've got this Shadow Boxing App, which, in my dedicated research, I downloaded and had a go with it.

+ +

MARC: Did you actually try it, or did you just click around?

+ +

SAMI: I did a proper workout, mate. I did. I put myself as, like, the absolute beginner. I did it on my MacBook Pro. I know it's built for iPad or iPhone, but it still worked amazingly well. And it kind of reminded me why I stopped doing boxing because it's hard work.

+ +

MARC: [laughs] Yeah, it is.

+ +

SAMI: It's not a gimmick this thing, right? So, it's like, the best way to describe it is it's essentially replacing if I was to go to the gym and have a trainer who's telling me kind of the moves to make or how to do it, then this kind of replaces that trainer. So, it's something you can do at home. It was really cool. I was surprised, actually. I thought, at the beginning, it's not going to be that interactive, or it won't actually be as hard or difficult as a workout, and it really was. So, it's, yeah, it was really cool, really interesting to try it.

+ +

And going into that, you say you wanted to get back more into coding, and that's why you are doing this kind of, like, app on the side, or it allowed you to kind of do a bit more coding away from the people management. You've been involved in a lot of startups, and I actually often get...as consultants, when we work at thoughtbot, we get a lot of people who come with different startup ideas. When you look back at all the startups you've been involved with, do you think more startups are successful than those that fail? Or have you seen a lot of startups...actually, people come with these great ideas; they want to build this amazing product, but it's actually really hard to be a successful product?

+ +

MARC: I think it's [inaudible 10:22] how to have the right idea, be at the right spot at the right time, build the right team, get enough momentum. I think most startups fail, and even startups that are successful often can be the result of a pivot. Like, I know companies that pivoted a bunch of times before finding any success. So, it's really hard actually...if I take my past four companies, only two are still alive. Like, the first two went under. Actually, there's even more companies that went under after I left. Yeah, it's just really hard to get anything off the ground. So, yeah, it's complicated, and I have a lot of respect for all the founders that go through it.

+ +

For The Shadow Boxing App, I worked on it for the past three years, but I'm only working on it almost full-time for the past two months. And it was way safer. I could check the product-market fit. I could check if I enjoyed working on it. So, I guess it was easier. I had the luxury of having a full-time job. Building the app didn't take that much time.

+ +

But to answer your question, I think, from my experience, most startups fail. And the ones that succeed it's kind of lightning in a bottle, or, like, there's a lot of factors that get into it. It's hard to replicate. A lot of people try to replicate some science, some ideas. They go, oh, we'll do this, and we'll do that. And we use this technique that Google uses and so on, but it's never that straightforward.

+ +

SAMI: Yeah, I'm so happy you said that because I think it's a real brutal truth that I'd also say most of the startup projects that I've worked on probably have failed. Like, there's very few that actually make it. It's such a saturated market. And I think, I guess, in your role as advising startups, it's really good to come in with that honesty at the beginning and to say, "It's a big investment if you want to build something. Most people probably aren't successful." And then, when you work from that perspective, you can have, like, way more transparent and open discussions from the get-go.

+ +

Because when you're outside of tech...and a lot of people have this idea of if I could just get an app to do my idea, I'm going to be the next Facebook. I'm going to be the next, you know, Amazon Marketplace. And it just kind of isn't like that. You've got these massive leaders in Facebook, Amazon, Google, Netflix. But below that, there's a lot of failures and a massively saturated market. So, yeah, just, it's so interesting that you also see it in a similar way.

+ +

MARC: What I saw evolve in the past 10 years is the fact that people got more realistic with it. So, maybe 10 years ago, I would have people coming to me with just the most ridiculous idea, like, you know, I'll do Airbnb for cats. And really think, yeah, I just need a good idea, and that's it. But now I feel like people kind of understand that it's more complicated. There's way more resources online. People are more educated. They also see way more successes. Failures are also a bit more advertised.

+ +

We saw a bunch of startups just go under. It feels like every month I get an email from a tool I used in the past saying, "Oh, we're shutting down," and so on. So, I think it's not as bad as 10 years ago where weekly I would have just people asking me, "I want to build this app," and the app would be just the most ridiculous thing or something that would be really smart, but it's really like, "Oh, I want to do, like, food delivery but better than what exists." It's like, yeah, that's a really good idea, but then you need...it's not only software. There's logistics. There's so much behind it that you don't seem to understand just yet.

+ +

But, as a coach, so, what I'm doing is I'm helping startups that are usually before or after series A but not too large of startups just go to the next stage. And people are really aware of that and really worried. Like, they see money going down, market fit not necessarily being there. And they know, like, their company is at risk.

+ +

And especially when you talk to founders, they're really aware that, you know, everything could be collapsing really quickly. If they make, like, three really bad decisions in a row, you're basically done. Obviously, it depends on the company, but yeah, people are more aware than before, especially nowadays where money is a bit harder to get. Let's say two years ago, there was infinite money, it felt like. Now it's more tight. People are more looking at the unit economics precisely. So, people need to be more realistic to succeed.

+ +

RÉMY: What's the kind of recurrent struggle the startups you coach usually face? Apparently, it quite changed in the past decade, but maybe what are the current struggles they face?

+ +

MARC: It really depends. It's kind of broad. But, usually, it would be, let's say, a startup after their first round of funding, let's say, if you take startups that are looking for funding. So, you usually have a group of founders, two to four, usually two or three, that are really entrepreneurs that want to bootstrap some things.
+They're builders. They're hacking things together, and they're really excited about the product.

+ +

And, suddenly, fast forward a few years, they're starting to be successful, and they have to lead a team of, you know, like, 50 people, 100 people, and they weren't prepared for that. They were really prepared to, like, build software. Like, especially the CTOs, they are usually really great hackers. They can, like, create a product really quickly. But, suddenly, they need to manage 30 engineers, and it's completely different, and they're struggling with that. So, that's a common problem for CTOs. And then, it creates a bunch of problems.

+ +

Like, you would have CEOs and CTOs not agreeing on how to approach the strategy, how to approach building a thing. What should be the methodology? Something that worked with 3 engineers around the table doesn't work with 50 engineers distributed in 5 countries. And if it's your first time being a CTO, and often founders of early-stage startups are first-time CTOs, it can be really hard to figure out.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

RÉMY: In your past companies, so you've been VP and CTO. So, in your opinion, what's the best a VP or a CTO can bring to a scaling startup? What are your best tips to share?

+ +

MARC: I guess it depends [laughs], obviously, like, depending on the stage of the company, the size of the company. For instance, when I was at Drivy, at some point, the most important thing was scaling the team hiring, and so on. But, at some point, we got acquired by Getaround, and the priorities got shifted. It was more like, okay, how do you figure out this new setup for the company and the team? Like, what is good? What is bad? How do you communicate with the team? How do you get people to stay motivated when everything is changing? How do you make sure you make the right decisions?

+ +

And then, when I joined Back Market, Back Market when I joined, I had a team of a bit less than 12 engineers reporting directly to me. And after a bit more than a year, I had 60, and I hired most of them. So, here the challenge was just scaling insanely fast. Like, the company is really successful. Like, Back Market is selling refurbished electronics in a mission to, you know, provide a viable alternative to buying new electronics. So, it's basically, do you want a smartphone that is both cheaper and more ecologically viable? And most people would say yes to that. So, a company is insanely successful, but it's really hard to scale.

+ +

So, at that point, the role was, okay, how do you make sure you scale as well as possible with a lot of pressure while still leaving the team in a state that they're able to still build software? Because it's just really chaotic. Like, you can't, like, 5X your team without chaos. But how do you minimize that but still go really fast?

+ +

SAMI: Yeah. So, not only did I try that Shadow App. I actually went on that Backup website. What's it called? It's not called Backup. What's it called again?

+ +

MARC: Back Market.

+ +

SAMI: Back Market. Thank you. Yeah, it was really cool. I checked my old iPhone SE from 2020, which I've kept for about...over three years, I've had this iPhone. And they said they would give me $72 for it, which was really cool. So, it sounds like a really cool idea.

+ +

MARC: That's something we worked on, which is, basically, if you have any old phones in your drawer, it's a really bad spot for them. And so, there's a service. You go on the website. You say, "I have this, I have that; I have this, I have that." And either we buy it from you, or we just take it away from you, and we recycle them, which is much better than just having them collect dust.

+ +

SAMI: Yeah, no, it's a great idea. What interested me when you were speaking about kind of these different positions that you've been in, I was almost expecting you to talk about maybe, like, a technical challenge or code complexity difficulty. But, actually, what you've described is more people problems. And how do we scale with regards to people, and how do we keep people motivated?

+ +

So, I guess using that experience, and this might be counterintuitive to what a lot of people think, but what do you think is the hardest thing about software development? I know there could be many things. But if you had to pick something that is the most difficult, and maybe we can all have an answer to what we think this is, but starting with you, Marc, what do you think is the hardest thing about software development then?

+ +

MARC: What I saw is how do you build something that works for enough time to bring value to the customers? So, it's easy to hack something together pretty quickly and get it in front of people, but then it might not be reliable. It might break down. Or you could decide to build something perfect and spend, like, two years on it and then ship it, and then it's really stable, but maybe it's not what people want. And finding this balance between shipping something fast, but shipping something that is reliable enough for what you're building. Obviously, if you're building a health care system, you will have more, like, the bar will be higher than if you build, like, Airbnb for cats.

+ +

Finding this balance and adjusting as you go is really hard. So, for instance, when do you introduce caching? Because, obviously, caching is hard to do right. If you don't do it, your site will be slow, which can be okay for a time. But then if you introduce it too late, then it's really hard to just retrofit into whatever you already have. So, finding the right moment to introduce a new practice, introduce a new technology is tricky.

+ +

And then, like, I talked a lot about the people, and it's also because I spent quite a bit of time in leadership position. But, at the end of the day, it will be the people writing the code that gets the software to exist and run. So, having people aligned and agreeing on the vision is also key because unless I'm the only developer on the project, I can't really make all decisions on things that are going to get built. So, figuring out how to get people motivated, interested in just building in the same direction is really important. It's really easy.

+ +

Like, one thing with Drivy, when I was there, that was really fun to see, like, many people have this reaction, especially the more senior people joining the company. They would see the engineering team, and they were really, really surprised by how small it was because we were being really, really efficient. Like, we were paying really close attention to what we would work on.

+ +

So, kind of technology we would introduce would be quite conservative on both to really be able to deliver what is the most important. So, we were able to do a lot with, honestly, not a lot of people. And I think this is a great mark for success. You don't need a thousand people to build your software if you ask the right question, like, "Do I need to build X or Y?" and always having these discussions.

+ +

RÉMY: What's your opinion on that, Sami?

+ +

SAMI: Yeah, I guess it changes. Like, for example, today, the hardest thing about software development was just getting Jira to work. That has literally ruined my whole day. But I've found, for me, what I find is the most difficult thing to do is making code resilient to change. What I mean by that is writing code that's easy to change. And a lot of that, I guess, we try to work on at thoughtbot, as consultants, is following kind of design principles and best practices and certain design patterns that really make the code easy to change. Because that, I think, when I'm writing code is the biggest challenge.

+ +

And where I feel when I'm working with our clients one of the biggest things they can invest in, which is difficult because there's not a lot of visibility around it or metrics, is ensuring that code that's written is easy to change because, at some point, it will. And I've also worked on systems which are bigger, and when you can't change them, conversations start happening about the cost of change. Do we rewrite it from the ground up again? And that opens a whole different can of worms. So, that, for me, I think, is definitely one of the hardest things. How about yourself, Rémy?

+ +

RÉMY: I don't know about the most difficult. I mean, there are many things difficult. But I remember something that I had to put extra effort, so maybe it was one of the most difficult for me. When I started being a consultant, when I joined thoughtbot was to understand what's the boundary between executing and giving an advice? So, basically, I discovered that when you're a consultant, but it works also when you're a developer in a team, you know, you're not just only the one who is going to write the code. You're supposed to be also someone with expertise, experience to share it and to make the project and the team benefit from it.

+ +

So, at some point, I discovered that I should not just listen to what the client would say they want. Obviously, that's what they want, but it's more interesting and more difficult to understand why they want it and why they actually need, which could be different from what they want. So, it's a whole different conversation to discover together what is actually the necessary thing to build, and with your expertise and experience, try to find the thing that is going to be the most efficient, reliable, and making both the client and the customers happy.

+ +

MARC: Yeah. And as software engineers, it's really easy to get excited about a problem and just go, "Oh, I could solve it this way." But then you need to step back and go, "Well, maybe it doesn't need fixing, or we should do something completely different." At some point, I was working with a customer service organization. In their workflows, they had to go on, let's say, five different pages and click on the button to get something to do one action.

+ +

And so, what they asked for is to have those five buttons on one single page, and so, they could go, click, click, click, click, click. But after looking at it, what they needed is just automation of that, not five buttons on the page. But it's really easy to go, oh, and we could make those buttons, like, kind of generic and have a button creator thing and make it really fancy. When you step back, you go, oh, they shouldn't be clicking that many buttons.

+ +

SAMI: Yeah, that makes so much sense because just in that example...I can't remember where I read this, but every line of code you write has to be maintained. So, in that example where you've got five buttons, you're kind of maintaining probably a lot more code than when you've got the single button, which goes to, I don't know, a single action or a method that will handle kind of all the automation for you. And that's also, you know, driving at simplicity.

+ +

So, sometimes, like, you see this really cool problem, and there's a really cool way to solve it. But if you can solve it, you mentioned, like, being conservative with the type of frameworks maybe you used in a previous company, like, solve it in the most simple way, and you'll thank yourself later. Because, at some point, you have to come back to it, and maintain it, change it. Yeah, so it makes a lot of sense.

+ +

And, Marc, you said you started when you were 7, which is really young. Through that amount of time, you've probably seen massive changes in the way websites look, feel, and how they work. In that time, what's the biggest change you actually think you've seen?

+ +

MARC: The biggest thing I saw is, when I started, internet didn't exist or at least wasn't available. Like, I remember being at school and the teacher would ask like, "How many people have a computer at home?" And we'd be like, two or three people. So, people didn't have internet until I was like 14, 15, I'd say. So, that's the biggest one.

+ +

But, let's say, after it started, they just got more complicated. Like, so, the complexity is getting crazy. Like, I remember, at some point, where I saw I think it was called Aviary. It was basically Photoshop in the browser, and I was just insanely impressed by just the fact that you could do this in the browser. And, nowadays, like, you've got Figma, and you've got so many tools that are insanely impressive. Back then, it was just text, images, and that's it.

+ +

I actually wrote a blog post a few years ago about how I used to build websites just using frames. So, I don't know if you're familiar with just frames, but I didn't really know how to do divs. So, I would just do frames because that's what I understood back then, again, little kid. But it was kind of working. You were dealing with IE 5 or, like, I remember, like, professionally fixing bugs for IE 5.5 or, like, AOL, like, 9, something ridiculous like this.

+ +

So, building a website just got way easier but also way more complicated, if that makes sense. Like, it's way easier to do most things. For instance, I don't know, like, 20 years ago, you wanted a rounded corner; you would have to create images and kind of overlay them in a weird way. It would break in many cases. Nowadays, you want rounded corners? That's a non-topic. But now you need, like, offline capabilities of your website. And, in a lot of cases, there's really complex features that are expected from users. So, the bar is getting raised to crazy levels.

+ +

SAMI: Yeah, I always wonder about this. Like, when you look at how the internet used to be and how people develop for the internet, and, like you're saying, now it's more complex but easier to do some things. I don't know if as developers we're making things harder or easier for ourselves. Like, if you look at the amount of technology someone needs to know to get started, it grows constantly. To do this, you have to add this framework, and you need to have this library, and maybe even a different language, and then, to even host something now, the amount of technologies you need to know. Do you think we're making things harder for ourselves, or do you think easier?

+ +

MARC: Well, I guess there's always back and forth, like, regarding complexity. So, things will get really, really complex, and then someone will go, "Well, let's stop that and simplify." That's why, like, I'm seeing some people not rejecting React and so on, but going a simpler route like Rails has options like this. There's people using HTMX, which is really simple. So, just going back to something simpler.

+ +

I think a lot of the really complex solutions also come from the fact that now we have massive teams building websites, and you need that complexity to be able to handle the team size. But it's kind of, then you need more people to handle the complexity, and it's just getting crazy. Yeah, honestly, I don't know. I'm seeing a lot of things that feel too complex for...like, the technology feels really complicated to accomplish some things that should be simple or at least feel simple. But, at the same time, there are things that got so simple that it's ridiculous like just accepting payment.

+ +

I remember, like, if you wanted to accept payment on a site, it would be months of work, and now it takes a minute. You just plug in Stripe, and it works. And it's often cheaper than what it used to be. So, it's kind of...or deploying. You mentioned deploying can be really hard. Well, you don't need to have a physical server in your room just eating your place up to have your website, your personal website running. You just push it to Vercel, or Heroku, or whatever, or just a static page on S3. So, this got simpler, but then, yeah, you can get it to be so much more crazy. So, if you host your static website on S3, fairly simple. But then if you try to understand permissions on S3, then, you know, it's over.

+ +

RÉMY: I don't know if it's really in the path of our discussion. I just wanted to ask you, so this is the on tour series, where we...so, usually, the Giant Robots podcast used to be a little bit more American-centric, and this on tour is moving back to the other side of the Atlantic with, again, Europe, West Asia, and Africa. You've been part of a company, Drivy, which expanded from France to neighboring countries in Europe. What could you tell our listeners about how to expand a business internationally?

+ +

MARC: That's a tough question, especially in Europe. Because I know looking from the outside, like, if you're from the U.S. and you look at Europe, it feels like, you know, a uniform continent, but really, it's very different. Like, just payment methods are different. Culture is very different.

+ +

For instance, when I was working at Back Market in France, one of the branding aspects of Back Market was its humor. Like, we would be making a lot of jokes on the website, and it would work really well in France. Like, people would love the brand. But then you expand to other countries, and they just don't find that funny at all. Like, it's not helping at all, and they're expecting a different tone of voice. So, it's not just, okay, I need to translate my own page; it's I need to internationalize for this market.

+ +

I guess my advice is do it country by country. Sometimes I see companies going like, oh, we opened in 20 different countries, and you go, how even do you do that? And spend some time understanding how people are using your product or, like, a similar product locally because you would be surprised by what you learn. Sometimes there's different capabilities.

+ +

For instance, when Drivy went to the UK, there's so much more you can learn. There's the government database that you can look up, and it really helps with managing risk. If people are known to steal cars, you can kind of figure it out. I'm simplifying a bit, but you can use this. You don't have that in France because we just don't have this solution. But if you go to Nordic countries, for instance, they have way more electric vehicles, so maybe the product doesn't work as well.

+ +

So, it's really understanding what's different locally and being willing to invest, to adapt. Because if you go, okay, I'm going to open in the Netherlands but you don't adopt the payment methods that are used in the Netherlands, you might as well not open at all. So, it's either you do it properly and you kind of figure out what properly means for your product, or you postpone, and you do it well later.

+ +

Like, right now, I'm struggling a bit with my app because it's open. So, it's on the App Store, so it's open globally. And it's a SaaS, so it's simpler, but I struggle with language. So, it's in French and English. I spoke both of this language, obviously, French better than English. But I think I'm doing okay with both. But I also built it in Spanish because I speak some Spanish fairly poorly, and I wanted to try to hit a different market like the Mexican market that are doing boxing quite a lot. But the quality doesn't seem there.

+ +

Like, I don't have the specific boxing lingo, so I'm contemplating just rolling it back, like, removing the Spanish language until I get it really well, maybe with a translator dedicated to it that knows boxing in Spanish. Because I work with translators that would translate, but they don't really know that, yeah, like a jab in boxing. In Spanish, they might also say, "Jab." They won't translate it to, like, [inaudible 38:31].

+ +

SAMI: Yeah. At thoughtbot, we have one of our clients they wanted to release their app also internationally. And so, we had also kind of a lot of these problems. We even had to handle...so, in some languages, you go from left to right, right to left. So, that kind of also changed a lot of the way you would design things is mainly for people who are going from left to right. I mean, that's thinking kind of more Europe, U.S.-centric. And then, you could be releasing your app into a different country where they read the other direction.

+ +

So, yeah, a lot of this stuff is really interesting, especially the culture, like you're saying. Do they find this humor funny? And then, how do they translate things? Which, in my head, I think, could you use AI to do that. Which is a nice segue into, like, the mandatory question about AI, which we can't let you go until we ask you.

+ +

MARC: [laughs]

+ +

SAMI: So, okay, obviously, I'm going to ask you about your thoughts on AI and where you think we're headed. But I've seen something interesting, which I don't know if this is something that resonates with you as well. I've seen a bit of a trend where the more experienced developers or more senior developers I talk to seem to be a bit more calm and less concerned. Whereas I would consider myself as less experienced, and I feel, like, kind of more anxious, more nervous, more jumping on the bandwagon sort of feeling of keeping an eye on it. So, I guess, with your experience, what are your thoughts on AI? Where do you think we are headed?

+ +

MARC: That's a big question, and it feels like it's changing month to month. It feels way more interesting than other trends before. Like, I'm way more excited about the capabilities of AI than, like, NFTs or stuff like this. I'm actively using AI tooling in my app. I was using some AI at Back Market. So, it's interesting. There's a bunch of things you can be doing.

+ +

Personally, I don't think that it's going to, like, make programming irrelevant, for instance. It will just change a bit how you will build things just like...so, we talked about what changed in the past. For instance, at some point, you would need a team of people moving around physical computers and servers and just hooking them up to be able to have a website. But now, most people would just use a cloud provider. So, all those people either they work for the cloud provider, or they're out of a job. But really what happened is most shifted into something different, and then we focused on something different. Instead of learning how to handle a farm of servers, we learned how to, I don't know, handle more concurrency in our models.

+ +

And I think when I look back, I feel like, technically, maybe, I don't know, 70%, 80% of what I learned is now useless. Like, I spent years getting really good at handling Internet Explorer as a web developer. Now it's just gone, so it's just gone forever. And it feels like there's some practice that we're having right now that will be gone forever thanks to AI or because of AI, depending on how you look at it. But then there'll be new things to do. I'm not sure yet what it will be, but it will create new opportunities. There are some things that look a bit scary, like, or creepy. But I'm not worried about jobs or things like this.

+ +

I'm a bit concerned about people learning programming right now because, yeah, there's a lot of hand-holding, and there's a lot of tools that you have to pay to get access to this hand-holding. So, if you're a student right now in school learning programming and your school is giving you some AI assistant, like Copilot or whatever, and this assistant is really good, but suddenly it goes away because you're not paying anymore, or, like, the model change, if you don't know how to code anymore, then it's a problem. Or maybe you're not struggling as much. And you're not digging deep enough, and so you're learning slower. And you're being a bit robbed of the opportunity to learn by the AI. So, it's just giving you the solution.

+ +

But it's just, like, the way I use it right now, so I don't have an assistant enabled, but I usually have, like, a ChatGPT window open somewhere. It's more like a better Stack Overflow or a more precise Stack Overflow. And that helps me a lot, and that's really convenient. Like, right now, I'm building mostly using Swift and Swift UI, but I'm mainly a Ruby and JavaScript developer. So, I'm struggling a lot and being able to ask really simple questions.

+ +

I had a case just this morning where I asked how to handle loading of images without using the assets folder in Xcode. I just couldn't figure it out, but it's really simple. So, it was able to tell me, like, right away, like, five options on how to do it, and I was able to pick the one that would fit. So, yeah, really interesting, but yeah, I'm not that worried. The only part I would be worried is if people are learning right now and relying way too much on AI.

+ +

RÉMY: Well, at least it's positive for our job. Thank you for making us believe in a bright future, Marc.

+ +

MARC: [laughs]

+ +

RÉMY: All right. Thank you so much, Marc, for joining us. It was a real pleasure. Before we leave, Marc, if you want to be contacted, if people want to get a hold of you, how can you be contacted?

+ +

MARC: There's two ways: either LinkedIn, look up Marc G Gauthier. Like, the middle initial is important because Marc Gauthier is basically John Smith in France. My website, which is marcgg.com. You can find my blog. You can find a way to hire me as a coach or advisor. That's the best way to reach out to me.

+ +

RÉMY: Thank you so much. And thank you, Sami, as well.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm. You can find me on social media as rhannequin.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening, and see you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In the latest episode of the "Giant Robots On Tour" podcast, hosts Rémy Hannequin and Sami Birnbaum welcome Marc G. Gauthier, a solopreneur and startup coach, who shares his journey from software development to becoming the founder and developer of The Shadow Boxing App. Marc describes how his interest in software engineering began at a young age with QBasic and evolved through various leadership roles at companies like Drivy (now Getaround) and Back Market. His early passion for gaming led him to learn coding, and over time, he naturally transitioned into management roles, finding excitement in organizing and leading teams while maintaining his love for building products.

+ +

During the episode, Marc discusses the challenges and intricacies of scaling startups, emphasizing the importance of balancing speed and reliability in software development. He recounts his experiences in leadership positions, where he faced the dual task of managing rapid team growth and maintaining software efficiency. Marc also shares insights into the startup ecosystem, noting that most startups struggle to achieve success due to a combination of market timing, team dynamics, and resource management. His own venture, The Shadow Boxing App, represents his attempt to return to hands-on coding while leveraging his extensive experience in startup coaching and advising.

+ +

Marc also touches on the role of AI in the future of software development, expressing cautious optimism about its potential to augment human workflows and automate repetitive tasks. He advises current and aspiring developers to embrace AI as a tool to enhance their capabilities rather than a replacement for human ingenuity. Marc concludes by highlighting the importance of realistic expectations in the startup world and the need for continuous learning and adaptation in the ever-evolving tech landscape.

+ + + +

Transcript:

+ +

RÉMY:  This is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Rémy Hannequin.

+ +

SAMI: And I'm your other host, Sami Birnbaum.

+ +

RÉMY: If you are wondering who we are, make sure you find the previous podcast where we introduced the Giant Robots on Tour series by throwing random icebreakers at each other. And find out that Jared likes it when someone takes the time to understand someone else's point of view.

+ +

Joining us today is Marc G Gauthier, a Solopreneur and Startup Coach.

+ +

Marc, you used to be VP of Engineering at Drivy, now known as Getaround, and also Director of Engineering at Back Market. You also have been a coach and advisor to a startup for over a decade. Currently, your current adventure is being the Founder and Developer of The Shadow Boxing App available on the Apple App Store. We always like to go back to the start with our guests. Everyone has a story, and we are interested in your journey. So, Marc, what led you into the world of software engineering in the first place?

+ +

MARC: Hello. Well, happy to be here. And, yeah, I started getting into software development quite a long time ago. I actually learned software development with QBasic when I was something like seven. And, from there, I just kept on learning, learning, and learning and got into school for it, then worked in different startups, and then moved into more leadership position management. And I'm now, like, coaching people and building my own product.

+ +

What do you want to get? Because it's broad. I've been doing it for quite a while. Like, I don't think the QBasic days are that insightful. The only thing I remember from that time is being confused by the print comment that I would expect it to print on my printer or something, but it didn't; it just printed on the screen. That's the only thing I have from back then.

+ +

SAMI: Why at seven years old? And I'm taking you back too far, but at seven years old, I was probably collecting Pokémon cards and possibly like, you know, those football stickers. I don't know if you had the Panini stickers.

+ +

MARC: Oh yeah, I was doing that as well.

+ +

SAMI: But you were doing that as well. But then what drove you at that age? What do you think it was that made you think, I want to start learning to code, or play around with the computer, or get into tech?

+ +

MARC: [laughs] Yeah. Well, I remember, back then, I really wanted a computer to play games. Like, I had a friend who had a computer. He was playing games, and I wanted to do that. So, I was asking my mom to have a computer, and she told me, "Yeah, you can have one." And she found a really old computer she bought from a neighbor, I think. But she told me like, "I don't know anything about it. So, you have to figure it out and set it up." And she just found someone to kind of help me. And this person told me to, like, take the computer apart. She taught me a bit of software development, and I kind of liked it.

+ +

And I was always trying to change the games. Back then, it was way easier. You could just edit a sound file, and you would just edit the sound file in the game, so yeah, just learning like this. It wasn't really my intent to learn programming. It just kind of happened because I wanted to play video games really.

+ +

SAMI: That's really cool. It's really interesting. Rémy, do you remember how...how did you first get...do you remember your first computer, Rémy?

+ +

RÉMY: My first computer, I think I remember, but the first one I used it was, first, a very long time ago. I discovered that it was an Apple computer way, way later when I discovered what Apple was and what computers were actually. And I just remember playing SimCity 2000 on it, and it was amazing. And we had to, you know, cancel people from making phone calls while we were on the computer because of the internet and all the way we had to connect to the internet back then.

+ +

And after that, just, I think, Windows 95 at home. Yeah, that's the only thing I can remember actually. Because I think I was lucky, so I got one quite early. And I don't really remember not having one, so I was quite lucky with that. And so, I was always kind of in the computer game without being too much [inaudible 05:02] [laughs].

+ +

SAMI: Yeah, I think that's similar to me as well. Like, it's interesting because my initial introduction to computers would have been watching my older brothers kind of play computer games and actually being told to get out the room, or like, you know, "We're busy now. Don't bother us." And then, what actually happened is when they left the room, I managed to play what they were playing, which was the first ever GTA. I don't know if anyone ever played this, but it is so cool if you look back on it. You could probably find emulators online, but it was, like, a bird's eye view, like, way of operating.

+ +

And it was probably also that drive where you get frustrated on a computer because you want to do something, so, like you were saying, Marc, where you went to edit the sound files because you want to change something. You want to do something. I definitely think that is something which I felt as well is that frustration of I want to change this thing. And then, that kind of gets into well, how does it work? And if I know how it works, then I can probably change it.

+ +

MARC: Yeah. And once you figure out how things work, it's also really exciting. Like, once you figure out the initialization file on Windows, like, you can edit, like, what level is unlocked right away. It's kind of cheat codes but not really. And there are some really fun ones. Like, I would edit sound files for racing games. And, usually, it's just a base sound file, and then they would pitch shift the sound to make it sound like an engine. So, if you record your voice, it's just really funny.

+ +

RÉMY: So, Marc, you mentioned moving to management positions quite early. Do you remember what made you do this move? Was it for, like, a natural path in your career, or was it something you really wanted from the first part of your career as a developer? What happened at this moment?

+ +

MARC: Yeah, that was not completely planned. Like, I don't think I really plan my career precisely. It's just something that happens. So, I joined Drivy after, like, I was already a software engineer for, like, five years at that point. I joined as a lead backend engineer. I did that for three years. And after three years, the company went from...I think there was, like, three software engineers to a dozen. There was a need for more structure, and the CTO, at the time so, Nicolas, wanted to focus more on products. And it was hard to do both, like do the product side, the design, the data, and do the engineering, the software, and so on.

+ +

So, he wanted to get a bit away from software engineering and more into product. So, there was a gap in the organization. I was there. I was interested to try, and I was already doing some more things on the human side, so talking to people, organizing, internal communication. I kind of liked it. So, I was excited to try, give it a try. It was really interesting.

+ +

I found that it was a different way to have an impact on the team. I just kept doing it. And my plan was to keep doing it until I'm bored with it. And I'm still not bored with it, even though you kind of miss just actually building the software yourselves, actually coding. So, that's also why I'm trying something different right now with my mobile app adventure.

+ +

SAMI: Right. So, on the side, you've got this Shadow Boxing App, which, in my dedicated research, I downloaded and had a go with it.

+ +

MARC: Did you actually try it, or did you just click around?

+ +

SAMI: I did a proper workout, mate. I did. I put myself as, like, the absolute beginner. I did it on my MacBook Pro. I know it's built for iPad or iPhone, but it still worked amazingly well. And it kind of reminded me why I stopped doing boxing because it's hard work.

+ +

MARC: [laughs] Yeah, it is.

+ +

SAMI: It's not a gimmick this thing, right? So, it's like, the best way to describe it is it's essentially replacing if I was to go to the gym and have a trainer who's telling me kind of the moves to make or how to do it, then this kind of replaces that trainer. So, it's something you can do at home. It was really cool. I was surprised, actually. I thought, at the beginning, it's not going to be that interactive, or it won't actually be as hard or difficult as a workout, and it really was. So, it's, yeah, it was really cool, really interesting to try it.

+ +

And going into that, you say you wanted to get back more into coding, and that's why you are doing this kind of, like, app on the side, or it allowed you to kind of do a bit more coding away from the people management. You've been involved in a lot of startups, and I actually often get...as consultants, when we work at thoughtbot, we get a lot of people who come with different startup ideas. When you look back at all the startups you've been involved with, do you think more startups are successful than those that fail? Or have you seen a lot of startups...actually, people come with these great ideas; they want to build this amazing product, but it's actually really hard to be a successful product?

+ +

MARC: I think it's [inaudible 10:22] how to have the right idea, be at the right spot at the right time, build the right team, get enough momentum. I think most startups fail, and even startups that are successful often can be the result of a pivot. Like, I know companies that pivoted a bunch of times before finding any success. So, it's really hard actually...if I take my past four companies, only two are still alive. Like, the first two went under. Actually, there's even more companies that went under after I left. Yeah, it's just really hard to get anything off the ground. So, yeah, it's complicated, and I have a lot of respect for all the founders that go through it.

+ +

For The Shadow Boxing App, I worked on it for the past three years, but I'm only working on it almost full-time for the past two months. And it was way safer. I could check the product-market fit. I could check if I enjoyed working on it. So, I guess it was easier. I had the luxury of having a full-time job. Building the app didn't take that much time.

+ +

But to answer your question, I think, from my experience, most startups fail. And the ones that succeed it's kind of lightning in a bottle, or, like, there's a lot of factors that get into it. It's hard to replicate. A lot of people try to replicate some science, some ideas. They go, oh, we'll do this, and we'll do that. And we use this technique that Google uses and so on, but it's never that straightforward.

+ +

SAMI: Yeah, I'm so happy you said that because I think it's a real brutal truth that I'd also say most of the startup projects that I've worked on probably have failed. Like, there's very few that actually make it. It's such a saturated market. And I think, I guess, in your role as advising startups, it's really good to come in with that honesty at the beginning and to say, "It's a big investment if you want to build something. Most people probably aren't successful." And then, when you work from that perspective, you can have, like, way more transparent and open discussions from the get-go.

+ +

Because when you're outside of tech...and a lot of people have this idea of if I could just get an app to do my idea, I'm going to be the next Facebook. I'm going to be the next, you know, Amazon Marketplace. And it just kind of isn't like that. You've got these massive leaders in Facebook, Amazon, Google, Netflix. But below that, there's a lot of failures and a massively saturated market. So, yeah, just, it's so interesting that you also see it in a similar way.

+ +

MARC: What I saw evolve in the past 10 years is the fact that people got more realistic with it. So, maybe 10 years ago, I would have people coming to me with just the most ridiculous idea, like, you know, I'll do Airbnb for cats. And really think, yeah, I just need a good idea, and that's it. But now I feel like people kind of understand that it's more complicated. There's way more resources online. People are more educated. They also see way more successes. Failures are also a bit more advertised.

+ +

We saw a bunch of startups just go under. It feels like every month I get an email from a tool I used in the past saying, "Oh, we're shutting down," and so on. So, I think it's not as bad as 10 years ago where weekly I would have just people asking me, "I want to build this app," and the app would be just the most ridiculous thing or something that would be really smart, but it's really like, "Oh, I want to do, like, food delivery but better than what exists." It's like, yeah, that's a really good idea, but then you need...it's not only software. There's logistics. There's so much behind it that you don't seem to understand just yet.

+ +

But, as a coach, so, what I'm doing is I'm helping startups that are usually before or after series A but not too large of startups just go to the next stage. And people are really aware of that and really worried. Like, they see money going down, market fit not necessarily being there. And they know, like, their company is at risk.

+ +

And especially when you talk to founders, they're really aware that, you know, everything could be collapsing really quickly. If they make, like, three really bad decisions in a row, you're basically done. Obviously, it depends on the company, but yeah, people are more aware than before, especially nowadays where money is a bit harder to get. Let's say two years ago, there was infinite money, it felt like. Now it's more tight. People are more looking at the unit economics precisely. So, people need to be more realistic to succeed.

+ +

RÉMY: What's the kind of recurrent struggle the startups you coach usually face? Apparently, it quite changed in the past decade, but maybe what are the current struggles they face?

+ +

MARC: It really depends. It's kind of broad. But, usually, it would be, let's say, a startup after their first round of funding, let's say, if you take startups that are looking for funding. So, you usually have a group of founders, two to four, usually two or three, that are really entrepreneurs that want to bootstrap some things.
+They're builders. They're hacking things together, and they're really excited about the product.

+ +

And, suddenly, fast forward a few years, they're starting to be successful, and they have to lead a team of, you know, like, 50 people, 100 people, and they weren't prepared for that. They were really prepared to, like, build software. Like, especially the CTOs, they are usually really great hackers. They can, like, create a product really quickly. But, suddenly, they need to manage 30 engineers, and it's completely different, and they're struggling with that. So, that's a common problem for CTOs. And then, it creates a bunch of problems.

+ +

Like, you would have CEOs and CTOs not agreeing on how to approach the strategy, how to approach building a thing. What should be the methodology? Something that worked with 3 engineers around the table doesn't work with 50 engineers distributed in 5 countries. And if it's your first time being a CTO, and often founders of early-stage startups are first-time CTOs, it can be really hard to figure out.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

RÉMY: In your past companies, so you've been VP and CTO. So, in your opinion, what's the best a VP or a CTO can bring to a scaling startup? What are your best tips to share?

+ +

MARC: I guess it depends [laughs], obviously, like, depending on the stage of the company, the size of the company. For instance, when I was at Drivy, at some point, the most important thing was scaling the team hiring, and so on. But, at some point, we got acquired by Getaround, and the priorities got shifted. It was more like, okay, how do you figure out this new setup for the company and the team? Like, what is good? What is bad? How do you communicate with the team? How do you get people to stay motivated when everything is changing? How do you make sure you make the right decisions?

+ +

And then, when I joined Back Market, Back Market when I joined, I had a team of a bit less than 12 engineers reporting directly to me. And after a bit more than a year, I had 60, and I hired most of them. So, here the challenge was just scaling insanely fast. Like, the company is really successful. Like, Back Market is selling refurbished electronics in a mission to, you know, provide a viable alternative to buying new electronics. So, it's basically, do you want a smartphone that is both cheaper and more ecologically viable? And most people would say yes to that. So, a company is insanely successful, but it's really hard to scale.

+ +

So, at that point, the role was, okay, how do you make sure you scale as well as possible with a lot of pressure while still leaving the team in a state that they're able to still build software? Because it's just really chaotic. Like, you can't, like, 5X your team without chaos. But how do you minimize that but still go really fast?

+ +

SAMI: Yeah. So, not only did I try that Shadow App. I actually went on that Backup website. What's it called? It's not called Backup. What's it called again?

+ +

MARC: Back Market.

+ +

SAMI: Back Market. Thank you. Yeah, it was really cool. I checked my old iPhone SE from 2020, which I've kept for about...over three years, I've had this iPhone. And they said they would give me $72 for it, which was really cool. So, it sounds like a really cool idea.

+ +

MARC: That's something we worked on, which is, basically, if you have any old phones in your drawer, it's a really bad spot for them. And so, there's a service. You go on the website. You say, "I have this, I have that; I have this, I have that." And either we buy it from you, or we just take it away from you, and we recycle them, which is much better than just having them collect dust.

+ +

SAMI: Yeah, no, it's a great idea. What interested me when you were speaking about kind of these different positions that you've been in, I was almost expecting you to talk about maybe, like, a technical challenge or code complexity difficulty. But, actually, what you've described is more people problems. And how do we scale with regards to people, and how do we keep people motivated?

+ +

So, I guess using that experience, and this might be counterintuitive to what a lot of people think, but what do you think is the hardest thing about software development? I know there could be many things. But if you had to pick something that is the most difficult, and maybe we can all have an answer to what we think this is, but starting with you, Marc, what do you think is the hardest thing about software development then?

+ +

MARC: What I saw is how do you build something that works for enough time to bring value to the customers? So, it's easy to hack something together pretty quickly and get it in front of people, but then it might not be reliable. It might break down. Or you could decide to build something perfect and spend, like, two years on it and then ship it, and then it's really stable, but maybe it's not what people want. And finding this balance between shipping something fast, but shipping something that is reliable enough for what you're building. Obviously, if you're building a health care system, you will have more, like, the bar will be higher than if you build, like, Airbnb for cats.

+ +

Finding this balance and adjusting as you go is really hard. So, for instance, when do you introduce caching? Because, obviously, caching is hard to do right. If you don't do it, your site will be slow, which can be okay for a time. But then if you introduce it too late, then it's really hard to just retrofit into whatever you already have. So, finding the right moment to introduce a new practice, introduce a new technology is tricky.

+ +

And then, like, I talked a lot about the people, and it's also because I spent quite a bit of time in leadership position. But, at the end of the day, it will be the people writing the code that gets the software to exist and run. So, having people aligned and agreeing on the vision is also key because unless I'm the only developer on the project, I can't really make all decisions on things that are going to get built. So, figuring out how to get people motivated, interested in just building in the same direction is really important. It's really easy.

+ +

Like, one thing with Drivy, when I was there, that was really fun to see, like, many people have this reaction, especially the more senior people joining the company. They would see the engineering team, and they were really, really surprised by how small it was because we were being really, really efficient. Like, we were paying really close attention to what we would work on.

+ +

So, kind of technology we would introduce would be quite conservative on both to really be able to deliver what is the most important. So, we were able to do a lot with, honestly, not a lot of people. And I think this is a great mark for success. You don't need a thousand people to build your software if you ask the right question, like, "Do I need to build X or Y?" and always having these discussions.

+ +

RÉMY: What's your opinion on that, Sami?

+ +

SAMI: Yeah, I guess it changes. Like, for example, today, the hardest thing about software development was just getting Jira to work. That has literally ruined my whole day. But I've found, for me, what I find is the most difficult thing to do is making code resilient to change. What I mean by that is writing code that's easy to change. And a lot of that, I guess, we try to work on at thoughtbot, as consultants, is following kind of design principles and best practices and certain design patterns that really make the code easy to change. Because that, I think, when I'm writing code is the biggest challenge.

+ +

And where I feel when I'm working with our clients one of the biggest things they can invest in, which is difficult because there's not a lot of visibility around it or metrics, is ensuring that code that's written is easy to change because, at some point, it will. And I've also worked on systems which are bigger, and when you can't change them, conversations start happening about the cost of change. Do we rewrite it from the ground up again? And that opens a whole different can of worms. So, that, for me, I think, is definitely one of the hardest things. How about yourself, Rémy?

+ +

RÉMY: I don't know about the most difficult. I mean, there are many things difficult. But I remember something that I had to put extra effort, so maybe it was one of the most difficult for me. When I started being a consultant, when I joined thoughtbot was to understand what's the boundary between executing and giving an advice? So, basically, I discovered that when you're a consultant, but it works also when you're a developer in a team, you know, you're not just only the one who is going to write the code. You're supposed to be also someone with expertise, experience to share it and to make the project and the team benefit from it.

+ +

So, at some point, I discovered that I should not just listen to what the client would say they want. Obviously, that's what they want, but it's more interesting and more difficult to understand why they want it and why they actually need, which could be different from what they want. So, it's a whole different conversation to discover together what is actually the necessary thing to build, and with your expertise and experience, try to find the thing that is going to be the most efficient, reliable, and making both the client and the customers happy.

+ +

MARC: Yeah. And as software engineers, it's really easy to get excited about a problem and just go, "Oh, I could solve it this way." But then you need to step back and go, "Well, maybe it doesn't need fixing, or we should do something completely different." At some point, I was working with a customer service organization. In their workflows, they had to go on, let's say, five different pages and click on the button to get something to do one action.

+ +

And so, what they asked for is to have those five buttons on one single page, and so, they could go, click, click, click, click, click. But after looking at it, what they needed is just automation of that, not five buttons on the page. But it's really easy to go, oh, and we could make those buttons, like, kind of generic and have a button creator thing and make it really fancy. When you step back, you go, oh, they shouldn't be clicking that many buttons.

+ +

SAMI: Yeah, that makes so much sense because just in that example...I can't remember where I read this, but every line of code you write has to be maintained. So, in that example where you've got five buttons, you're kind of maintaining probably a lot more code than when you've got the single button, which goes to, I don't know, a single action or a method that will handle kind of all the automation for you. And that's also, you know, driving at simplicity.

+ +

So, sometimes, like, you see this really cool problem, and there's a really cool way to solve it. But if you can solve it, you mentioned, like, being conservative with the type of frameworks maybe you used in a previous company, like, solve it in the most simple way, and you'll thank yourself later. Because, at some point, you have to come back to it, and maintain it, change it. Yeah, so it makes a lot of sense.

+ +

And, Marc, you said you started when you were 7, which is really young. Through that amount of time, you've probably seen massive changes in the way websites look, feel, and how they work. In that time, what's the biggest change you actually think you've seen?

+ +

MARC: The biggest thing I saw is, when I started, internet didn't exist or at least wasn't available. Like, I remember being at school and the teacher would ask like, "How many people have a computer at home?" And we'd be like, two or three people. So, people didn't have internet until I was like 14, 15, I'd say. So, that's the biggest one.

+ +

But, let's say, after it started, they just got more complicated. Like, so, the complexity is getting crazy. Like, I remember, at some point, where I saw I think it was called Aviary. It was basically Photoshop in the browser, and I was just insanely impressed by just the fact that you could do this in the browser. And, nowadays, like, you've got Figma, and you've got so many tools that are insanely impressive. Back then, it was just text, images, and that's it.

+ +

I actually wrote a blog post a few years ago about how I used to build websites just using frames. So, I don't know if you're familiar with just frames, but I didn't really know how to do divs. So, I would just do frames because that's what I understood back then, again, little kid. But it was kind of working. You were dealing with IE 5 or, like, I remember, like, professionally fixing bugs for IE 5.5 or, like, AOL, like, 9, something ridiculous like this.

+ +

So, building a website just got way easier but also way more complicated, if that makes sense. Like, it's way easier to do most things. For instance, I don't know, like, 20 years ago, you wanted a rounded corner; you would have to create images and kind of overlay them in a weird way. It would break in many cases. Nowadays, you want rounded corners? That's a non-topic. But now you need, like, offline capabilities of your website. And, in a lot of cases, there's really complex features that are expected from users. So, the bar is getting raised to crazy levels.

+ +

SAMI: Yeah, I always wonder about this. Like, when you look at how the internet used to be and how people develop for the internet, and, like you're saying, now it's more complex but easier to do some things. I don't know if as developers we're making things harder or easier for ourselves. Like, if you look at the amount of technology someone needs to know to get started, it grows constantly. To do this, you have to add this framework, and you need to have this library, and maybe even a different language, and then, to even host something now, the amount of technologies you need to know. Do you think we're making things harder for ourselves, or do you think easier?

+ +

MARC: Well, I guess there's always back and forth, like, regarding complexity. So, things will get really, really complex, and then someone will go, "Well, let's stop that and simplify." That's why, like, I'm seeing some people not rejecting React and so on, but going a simpler route like Rails has options like this. There's people using HTMX, which is really simple. So, just going back to something simpler.

+ +

I think a lot of the really complex solutions also come from the fact that now we have massive teams building websites, and you need that complexity to be able to handle the team size. But it's kind of, then you need more people to handle the complexity, and it's just getting crazy. Yeah, honestly, I don't know. I'm seeing a lot of things that feel too complex for...like, the technology feels really complicated to accomplish some things that should be simple or at least feel simple. But, at the same time, there are things that got so simple that it's ridiculous like just accepting payment.

+ +

I remember, like, if you wanted to accept payment on a site, it would be months of work, and now it takes a minute. You just plug in Stripe, and it works. And it's often cheaper than what it used to be. So, it's kind of...or deploying. You mentioned deploying can be really hard. Well, you don't need to have a physical server in your room just eating your place up to have your website, your personal website running. You just push it to Vercel, or Heroku, or whatever, or just a static page on S3. So, this got simpler, but then, yeah, you can get it to be so much more crazy. So, if you host your static website on S3, fairly simple. But then if you try to understand permissions on S3, then, you know, it's over.

+ +

RÉMY: I don't know if it's really in the path of our discussion. I just wanted to ask you, so this is the on tour series, where we...so, usually, the Giant Robots podcast used to be a little bit more American-centric, and this on tour is moving back to the other side of the Atlantic with, again, Europe, West Asia, and Africa. You've been part of a company, Drivy, which expanded from France to neighboring countries in Europe. What could you tell our listeners about how to expand a business internationally?

+ +

MARC: That's a tough question, especially in Europe. Because I know looking from the outside, like, if you're from the U.S. and you look at Europe, it feels like, you know, a uniform continent, but really, it's very different. Like, just payment methods are different. Culture is very different.

+ +

For instance, when I was working at Back Market in France, one of the branding aspects of Back Market was its humor. Like, we would be making a lot of jokes on the website, and it would work really well in France. Like, people would love the brand. But then you expand to other countries, and they just don't find that funny at all. Like, it's not helping at all, and they're expecting a different tone of voice. So, it's not just, okay, I need to translate my own page; it's I need to internationalize for this market.

+ +

I guess my advice is do it country by country. Sometimes I see companies going like, oh, we opened in 20 different countries, and you go, how even do you do that? And spend some time understanding how people are using your product or, like, a similar product locally because you would be surprised by what you learn. Sometimes there's different capabilities.

+ +

For instance, when Drivy went to the UK, there's so much more you can learn. There's the government database that you can look up, and it really helps with managing risk. If people are known to steal cars, you can kind of figure it out. I'm simplifying a bit, but you can use this. You don't have that in France because we just don't have this solution. But if you go to Nordic countries, for instance, they have way more electric vehicles, so maybe the product doesn't work as well.

+ +

So, it's really understanding what's different locally and being willing to invest, to adapt. Because if you go, okay, I'm going to open in the Netherlands but you don't adopt the payment methods that are used in the Netherlands, you might as well not open at all. So, it's either you do it properly and you kind of figure out what properly means for your product, or you postpone, and you do it well later.

+ +

Like, right now, I'm struggling a bit with my app because it's open. So, it's on the App Store, so it's open globally. And it's a SaaS, so it's simpler, but I struggle with language. So, it's in French and English. I spoke both of this language, obviously, French better than English. But I think I'm doing okay with both. But I also built it in Spanish because I speak some Spanish fairly poorly, and I wanted to try to hit a different market like the Mexican market that are doing boxing quite a lot. But the quality doesn't seem there.

+ +

Like, I don't have the specific boxing lingo, so I'm contemplating just rolling it back, like, removing the Spanish language until I get it really well, maybe with a translator dedicated to it that knows boxing in Spanish. Because I work with translators that would translate, but they don't really know that, yeah, like a jab in boxing. In Spanish, they might also say, "Jab." They won't translate it to, like, [inaudible 38:31].

+ +

SAMI: Yeah. At thoughtbot, we have one of our clients they wanted to release their app also internationally. And so, we had also kind of a lot of these problems. We even had to handle...so, in some languages, you go from left to right, right to left. So, that kind of also changed a lot of the way you would design things is mainly for people who are going from left to right. I mean, that's thinking kind of more Europe, U.S.-centric. And then, you could be releasing your app into a different country where they read the other direction.

+ +

So, yeah, a lot of this stuff is really interesting, especially the culture, like you're saying. Do they find this humor funny? And then, how do they translate things? Which, in my head, I think, could you use AI to do that. Which is a nice segue into, like, the mandatory question about AI, which we can't let you go until we ask you.

+ +

MARC: [laughs]

+ +

SAMI: So, okay, obviously, I'm going to ask you about your thoughts on AI and where you think we're headed. But I've seen something interesting, which I don't know if this is something that resonates with you as well. I've seen a bit of a trend where the more experienced developers or more senior developers I talk to seem to be a bit more calm and less concerned. Whereas I would consider myself as less experienced, and I feel, like, kind of more anxious, more nervous, more jumping on the bandwagon sort of feeling of keeping an eye on it. So, I guess, with your experience, what are your thoughts on AI? Where do you think we are headed?

+ +

MARC: That's a big question, and it feels like it's changing month to month. It feels way more interesting than other trends before. Like, I'm way more excited about the capabilities of AI than, like, NFTs or stuff like this. I'm actively using AI tooling in my app. I was using some AI at Back Market. So, it's interesting. There's a bunch of things you can be doing.

+ +

Personally, I don't think that it's going to, like, make programming irrelevant, for instance. It will just change a bit how you will build things just like...so, we talked about what changed in the past. For instance, at some point, you would need a team of people moving around physical computers and servers and just hooking them up to be able to have a website. But now, most people would just use a cloud provider. So, all those people either they work for the cloud provider, or they're out of a job. But really what happened is most shifted into something different, and then we focused on something different. Instead of learning how to handle a farm of servers, we learned how to, I don't know, handle more concurrency in our models.

+ +

And I think when I look back, I feel like, technically, maybe, I don't know, 70%, 80% of what I learned is now useless. Like, I spent years getting really good at handling Internet Explorer as a web developer. Now it's just gone, so it's just gone forever. And it feels like there's some practice that we're having right now that will be gone forever thanks to AI or because of AI, depending on how you look at it. But then there'll be new things to do. I'm not sure yet what it will be, but it will create new opportunities. There are some things that look a bit scary, like, or creepy. But I'm not worried about jobs or things like this.

+ +

I'm a bit concerned about people learning programming right now because, yeah, there's a lot of hand-holding, and there's a lot of tools that you have to pay to get access to this hand-holding. So, if you're a student right now in school learning programming and your school is giving you some AI assistant, like Copilot or whatever, and this assistant is really good, but suddenly it goes away because you're not paying anymore, or, like, the model change, if you don't know how to code anymore, then it's a problem. Or maybe you're not struggling as much. And you're not digging deep enough, and so you're learning slower. And you're being a bit robbed of the opportunity to learn by the AI. So, it's just giving you the solution.

+ +

But it's just, like, the way I use it right now, so I don't have an assistant enabled, but I usually have, like, a ChatGPT window open somewhere. It's more like a better Stack Overflow or a more precise Stack Overflow. And that helps me a lot, and that's really convenient. Like, right now, I'm building mostly using Swift and Swift UI, but I'm mainly a Ruby and JavaScript developer. So, I'm struggling a lot and being able to ask really simple questions.

+ +

I had a case just this morning where I asked how to handle loading of images without using the assets folder in Xcode. I just couldn't figure it out, but it's really simple. So, it was able to tell me, like, right away, like, five options on how to do it, and I was able to pick the one that would fit. So, yeah, really interesting, but yeah, I'm not that worried. The only part I would be worried is if people are learning right now and relying way too much on AI.

+ +

RÉMY: Well, at least it's positive for our job. Thank you for making us believe in a bright future, Marc.

+ +

MARC: [laughs]

+ +

RÉMY: All right. Thank you so much, Marc, for joining us. It was a real pleasure. Before we leave, Marc, if you want to be contacted, if people want to get a hold of you, how can you be contacted?

+ +

MARC: There's two ways: either LinkedIn, look up Marc G Gauthier. Like, the middle initial is important because Marc Gauthier is basically John Smith in France. My website, which is marcgg.com. You can find my blog. You can find a way to hire me as a coach or advisor. That's the best way to reach out to me.

+ +

RÉMY: Thank you so much. And thank you, Sami, as well.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm. You can find me on social media as rhannequin.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening, and see you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pbyCRoxh + + ]]> + + + + 536: Exploring AI and Mental Health with Sara Wilder + https://podcast.thoughtbot.com/536 + 9a53318e-43bc-4ac3-a3d3-0bf9f15aecc6 + Thu, 01 Aug 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + In this episode of "Giant Robots On Tour," hosts Sami Birnbaum and Rémy Hannequin discuss mental health in the age of AI with Sara Wilder, a Therapeutic Life Consultant. Sara shares how the COVID-19 pandemic pushed her to integrate technology into her practice, emphasizing the benefits and challenges of using AI tools like ChatGPT. The conversation highlights the broader impact of technology on mental health, the need for ethical AI use, and maintaining human connection in digital therapy. + 43:56 + no + + + In this podcast episode of "Giant Robots On Tour," hosts Sami Birnbaum and Rémy Hannequin explore mental health in the age of artificial intelligence with Sara Wilder, a Therapeutic Life Consultant and Licensed Clinical Social Worker. Sami shares his own brief foray into psychotherapy before transitioning to tech, highlighting the relevance of mental health in today's rapidly evolving technological landscape. Sara, whose path to therapy was influenced by her personal struggles and a desire to help others, discusses her unique approach as a Therapeutic Life Consultant, which blends traditional therapy with direct coaching and consulting. +Sara elaborates on her journey and how the COVID-19 pandemic pushed her towards integrating technology into her practice. She transitioned from in-person sessions to virtual consultations, emphasizing the impact of this shift on mental health and brain function. Sara's interest in AI stemmed from her need to scale her business and her desire to use technology to aid her clients. She discusses her experience with AI tools like ChatGPT, both the benefits and challenges, such as generating relatable content and addressing AI "hallucinations." Sara highlights the importance of using AI ethically and maintaining human oversight to ensure the authenticity and accuracy of AI-generated outputs. +The conversation also delves into broader concerns about the impact of AI and technology on mental health. Sami and Rémy discuss the addictive nature of technology and its parallels with substance addiction, emphasizing the need for self-imposed boundaries and emotional intelligence. Sara shares insights into how AI can be a valuable tool in therapy, such as using AI for social anxiety role-playing or to generate conversation prompts. The episode concludes with a discussion on the balance between leveraging AI for efficiency and maintaining human connection, stressing the need for ongoing education and ethical considerations in AI development and deployment. +Follow Sara Wilder on LinkedIn (https://www.linkedin.com/in/sara-wilder-lcsw-lcas-ccs-9753517b/). Visit her website: sarawilderlcsw.com (https://sarawilderlcsw.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: + SAMI: Yes, and we are back. And this is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Sami Birnbaum. +RÉMY: And I'm your other host, Rémy Hannequin. +SAMI: Okay, if you're wondering where Jared is, we finally got rid of him. No, that's a joke, Jared, if you're listening. He was my previous co-host. You can go back to our other podcasts. But we've got Rémy on board today. And you could take a look at our previous podcast, where we introduce the Giant Robots on Tour series, where you'll find out about all the different co-hosts. And you can learn more about Rémy's sourdough bread. +Joining us today is Sara Wilder, a Therapeutic Life Consultant, Licensed Clinical Social Worker, and Clinical Addictions Specialist. +Okay, Sara, this is going to sound a little bit strange, but, actually, once upon a time in my own life, I kind of wanted to be you, not exactly you because that would be even more strange. +SARA: [chuckles] +SAMI: But before I got into coding and tech, I was interested in psychotherapy. And I started a course and, for different reasons, it didn't work out, and I never pursued that career. But what's really interested us about you is the work and research you're doing around mental health in this new world of AI, artificial intelligence. You have a really interesting talk coming up at the CreativeVerse Conference in North Carolina. And we actually have Fatima from thoughtbot who's going to be presenting at the same conference. +And you're specifically talking about prioritizing mental health in the age of AI. And there is so much we want to ask you about this. But before we do, I always like to go back to the start with my guests. Everyone has a story, and I'm interested in your journey. What led you into the world of therapy? +SARA: Well, to unpack that, it's, like, probably way too long for this podcast, but in a nutshell, I had no idea what...I did not want to be a therapist when I grew up, so thank you for wanting that more than me. But I landed here, I think, partly just because of, you know, I always wanted to help people. I never really knew what that was going to look like. I thought it maybe was going into nursing or more of the medical side. But really what landed me here and made me stay here and really choose to stay in my profession...because, at one point, I was like, no, I'm not sure I could do this for the rest of my life; this is a lot. But it was really my own suffering. +I had to take a really hard look at where I came from, what I had gone through, and why I wanted to just, you know, like, help people, but then try to keep changing how I did that. And I'm glad I chose to stay put in this kind of therapeutic, you know, life. Therapeutic life consultant is a term that I kind of formulated myself because I'm not quite a traditional therapist anymore. I'm not sitting in an office with the couch. We talk a lot about our relationship with our mothers. +But I have more of a personality that's direct and kind of coaching. And I want to go more into consulting and help people understand how to do their own healing work using my clinical background of being in diagnostics in different hospital settings, stuff like that. And because I had to do my own work, and I had to understand how to make sense of how my pain and my suffering was holding me back, and how I could turn that really into something that could help me thrive. +SAMI: Yeah, I think that's really powerful. I think that's a really powerful place to be able to come from, you know, to be able to kind of take your own challenges and the things that you've struggled with. And it's kind of like almost sometimes you have...the best teachers are the people who've gone through it themselves. And I can imagine that's been quite a journey. If only we had a longer podcast, right? +SARA: [chuckles] +SAMI: We could go into all our journeys. But it's super interesting. And, specifically, what has then kind of propelled you more towards looking into the tech aspect of it, right? So, I'm assuming...well, AI, at least, is relatively recent. And so, I'm assuming when you started out, it was more, like you're saying, a therapeutic setting, a life coaching setting, and now there's this sort of other angle, which is kind of coming into it. So, how did you end up getting involved or interested in the tech or the AI side? +SARA: I am an entrepreneur myself. When we go into what we call private practice, there is an element of business that most of us don't know. They don't really teach you business in social work school, and I kind of had to figure it out. But what really pushed me off that ledge to just figure it out and fly was COVID. And I, you know, went from a traditional office with the couch to being virtual. And it was going to be temporary, but I made the decision, and it was quite a difficult decision, given what I had already experienced in helping people through that transition, you know, going from traditional office spaces to at-home working. +But it was, yeah, I really had to understand the impact of technology on my practice, let alone my life. Working from home is a very different lifestyle when it comes to understanding what mental health means. You know, working from home and brain health is a big focus of, you know, what I discuss with my clients and educate them on. But more recently, and this is kind of how I got into the conference, when I started realizing that a lot of my own mental health was...I needed an outlet of creativity of something to be able to help me cope. I realized my business, and my content, and my passion could be that. So, I had to figure out how to scale myself. +And I'm still learning AI. I have an assistant, and she helps me. I have to use her to help me use ChatGPT because it is a beast if you don't know not only just learning the program but learning how to use it and also for it to really be authentic and not necessarily something that, you know, the bot just develops content for you, and you don't make it your own. So, it's a big old brain twister. And the concept of perception is very delicate, let alone with AI. But when you bring it into the tech world, it's a completely different type of language. +RÉMY: Since you started working with AI, you mentioned ChatGPT, have you noticed answers or generated content that is either incredibly useful and accurate, and, on the other side, other content that might be, I won't say disturbing, but at least not exactly what you would expect from a human? +SARA: Yeah, absolutely. It kind of weirds me out to, like...because I use it to kind of help my creative flow, like, if I have a blog post that I need to write. And it's very important for me to, you know, bring myself into my writing. So, when I started with ChatGPT, and it brings up something, and I'm like, who ever says that? Like, no one says that. Like, that's completely maybe like, you know, just it's a little bit unrelatable and a little stiff, I guess, is the best word I can use. +And then, I go through the processing of like, okay, let me figure out how I would write this. I feel like it does help me. It does prolong the process a little bit more. But I have also, yeah, so just kind of relatability factor, for me, is the first thing that sticks out. +But the other thing that I've learned a little bit more about listening to, you know, other podcasts and just trying to educate myself, which is a funny term because we use this, you know, in my field of mental health all the time, is it comes up with hallucination. So, it will fill in gaps of, you know, whether it be data, or in a statistic, or whether it's just a concept that it kind of makes up to kind of fill and have fillers in what it produces, which I'm still new to understanding what that really means. Like, yeah, it definitely can be some...and it needs to be something that we fact-check as well since it's just pulling from the general abyss of the internet, and that's not always the most accurate, you know, place of reference in general. +SAMI: Yeah, I can vouch for the abyss of the internet not always being the best place to find yourself [laughs]. There's some rabbit holes we've probably all been down. But it's so interesting because I find that the world has woken up to the impact that social media has had on everyone's mental health. And it almost feels like that was our first experiment with how tech can really impact us as a society and as individuals. And so, we've kind of seen that experiment and how that's played out, and I would argue we've probably failed. We've probably had this social media wave. And whether you'd look at it from a government perspective or a healthcare perspective, I don't actually think we've handled it well. +And it's almost, like, now we're on the cusp of our second experiment, right? This is now, okay, no longer social media. I mean, that is still relevant but put that to the side for a second. And you've got AI coming out with all these chatbots, generative AI, whether that's across images, text, and the impact that is going to have. So, I feel like the space that you're in is huge. I think you spoke before we started recording about, like, there's a mental health crisis. What do you see, or what concerns do you have given what we've seen with social media, the impact AI can have on our mental health? +SARA: You know, there's a lot of different points here, but I think I'll just go with the first thing that comes to my mind is the limits. There are not many limits, let alone...so, tech in itself, but just in our own natural human world, as individuals, we have to learn what boundaries are. We have to learn self-imposed limitations or else someone else is going to impose them on us, and that just doesn't feel as good when someone puts their own limitations on our reality. +So, when we bring this into tech,...and I also include...since my background is in addictions, I started realizing that correlation between, like, technology, the boom of access to information is really...it's a pleasure concept, is that when we have a thought and we can just go get information about the answer and it's immediate, that immediate gratification teaches the brain like, oh, I can do this. I can handle this myself. We're not looking at the by-product of that anymore. And I think because we're dealing with it, we can't really...we're so in it now. We can't see that like, oh, this could potentially be a problem, because it is. +We have become an immediate access world. I mean, even in rural...like, kids in Africa have a TikTok dancing. And they don't have running water in their communities, but they have a cell phone where they can get support. Like, I'm glad they can because that's great access. But they're not necessarily realizing the addictive aspect of what just being interconnected this way has on the brain, let alone the foundational understanding of what boundaries, and self-discipline, or just mental discipline would look like. +So, then when you bring this, I think, into the, you know, the AI world, we're already on a shaky ground of abuse of information and having too much information and not knowing how to process it. And I think that's probably been...I know an issue, for me, is that when I have too much information, I can't necessarily ask questions very well because I'm like, what is the question? Like, I know my brain is oversaturated, essentially, with information as well as potentially chemicals at this point because I'm just working so fast, so fast, so fast. +And I'm in my mid-thirties at this point. So, a teenager who's already dealing with impulse control issues because they're naturally developing, that gets really complicated very quickly. And that's what, in turn, we call attention deficit disorder, anxiety, autism spectrum. That's a little bit more complicated, but a lot of that intersects to be like, well, what are we dealing with? We're dealing with immediate gratification and a sensory processing issue because we're looking at screens, and our brains don't know how to adapt to that let alone regulate that. +SAMI: That makes so much sense. I guess it's because it's kind of a world that we all inhabit, right? As much as we talk about this and sometimes we like to think of the other like we're talking about someone else, I've found this in my own life as well. I'm addicted to my phone in ways, and I'm also seeking that immediate gratification. And it's almost, like you said, that dopamine hit, right? If there's a piece of information I want or there's a video that I want to see, it's there, and it's immediate. +And when you say these things, I guess it's kind of...it's a bit scary. And then, I wonder, on a more macro level, why, as a society, do we do this to ourselves? I don't expect anyone on this podcast [chuckles] to have the answer, right? But I'm always interested, like, if we're aware of this and we're cognizant of what's going on, and, Rémy, feel free to jump in on this as well, like, as a society, why are we doing this to ourselves? +SARA: Now, by no means is this...like, this is just my answer, and I don't have the answer for everything. But I've had...sometimes as a therapist, you have to fill space and come up with an answer. So, my hypothesis is that it's natural human behavior. I think our brains...we are, you know, survival of the fittest. That's natural. Like, at the end of the day, we're going to fight for our life. And life really comes down, in my perspective, it comes down to, like, we have suffering, and we have pleasure. +However, we've learned now that as an evolving, you know, species, that we are one of the only species that can build executive functioning skills in our brains and have different parts of that that we have to kind of understand the baseline. Survival has gotten us so far, and we've made a lot of great headway with that. But pleasure is not sustainable. Pleasure is a beautiful concept to have in life. But when we talk about what's the goal of life, we want to be happy. Happy and pleasure are actually two very different things to the brain. And a lot of it is just a matter of space being used. +Pleasure and dopamine is actually a very small part of the brain, whereas happiness expands and is able to circulate chemicals, and synapses, and energy throughout the rest of the brain but that it has to be a conscious choice. And I think a lot of people don't realize, yeah, you're making choices. I'm not saying, like, no one doesn't have, you know, some degree of free will, but if you're dealing with any degree of stress, emotions, cognitive bias in general, you're not making an actual, like, expansive choice about what options you have to expand your consciousness and your brain capacity. +RÉMY: I like the way that today we realized that a lot of things related to this is chemicals that we all have, which remove a little bit the guilt when you are addicted, you know, because it can happen to anyone. But also, it's a reminder that it can happen to anyone. So, nobody is immune to that because that's how we're built. And I really like this approach. It's just natural, which means it's okay to feel it. But it's also dangerous to anyone, so anyone should address it. And, again, if you feel like you're losing it and losing to addiction, it feels good to just know that everybody is entitled to, unfortunately, to feel that at some point in their life. +SARA: I love that you mentioned that, and that's absolutely one of my goals is to break down the stigma of...when I use the word addiction...and I don't do small talk that well because I'm just like, let's talk about some real things here. This is what's going on. And it's scary to think of, like, addiction and what that means because of how we've seen it. And I don't know what it looks like particularly in the countries that you're from...a little bit. But I know, here in America, it's messy. It's hurtful. It's a lot of suffering. +It doesn't make us feel good to even think about that, which is why I try to teach my clients how to manage and regulate that because it does not discriminate. It's your brain. It's doing its natural thing and how you have to train and just learn how to train that. And it can get better, for sure. But yeah, I really try to break through, like, it's not something that we need to keep being scared about because that is actually what gives it its power. It gives that restrictiveness and that isolation and breaks that connection from each other. And that's ultimately what brings us out of an active addictive cycle is connection. +SAMI: Yeah, it's really interesting because technology it almost masks that by making you feel really connected. Like, I'm connected to all these people and all these things, but I don't feel that connection. And that really resonates with me when you talk about the difference between pleasure and happiness. +So, I hope my parents don't listen to this. But when I was in university, I'm pretty sure I had a gaming addiction. So, I used to live in the loft in my house. I don't know what you'd call it in America. Maybe it's called the attic. I was at the top floor. So, essentially, I had...oh, back then, it would have been a PS3, and I was seriously addicted to Call of Duty, playing online. +And I remember doing just all-nighters, like, really often. I remember it got to a point where I would almost have to reset my whole sleep cycle because I ended up in a situation where I'd be awake in the night kind of always playing all night because I couldn't put the game down, and then sleeping during the day. And to get myself back into a normal rhythm, I'd have to force myself to stay awake for 24 hours. And I would even consider myself someone who doesn't have an addictive personality. +But when you were saying about the difference between pleasure and happiness, like, it was definitely hitting that dopamine, and it was pleasurable, but I didn't feel happy. Like, once I stopped, then there was all those feelings that Rémy described, which is, oh no, what have I done? I've wasted so much time and all that guilt that comes with it. So, it's really interesting. +And I guess it's also a bit like a codependency, which is something I've seen that you've touched on in your work as well, which I understand to be an unhealthy reliance on a human relationship. But I'm guessing we're probably seeing more of that and unhealthy reliance on tech software products and AI. Is that something you're seeing in your therapeutic work as well? +SARA: Oh, absolutely. Codependency it's a big topic to unpack. And I'll say it's a balance. We're never going to not be codependent on something because it literally...we're supposed to work together. We need each other to survive and to grow. But the unhealthy parts of it is, I think, because...I'll just speak from my own experience. I was never taught what emotional intelligence was when I was a kid. I grew up in a very middle-class, non-diverse part of the United States, where I didn't understand the foundational, like, what are boundaries? What are emotions? They try to teach you. +And I think that's been something that is going to take people a while to understand. But there is an unhealthy part of it because it's just mixed with...and confuse people of what do we actually need to need other people for. And it naturally sends us...I think this is primarily where relationships become a point of the discussion is relationships are necessary. But they're less successful if you don't have a relationship with yourself as a foundation because that's naturally going to help you realize that you don't need this one person. And you don't attach to a person out of necessity and out of survival or else, yeah, you're going to lose a huge aspect of your identity because you didn't have much of one to begin with. +And so, that's ultimately what I teach and educate people on when I work with them in session is just what codependency really is. We're going to be codependent on something. I'd rather you be aware of it. Denial is just dangerous in general. But being aware of how these things show up, you have a better of a choice now. And free will comes back to really in your control without less consequence over time or less negative consequence over time. [inaudible 20:44] my brother, though, Rémy. Call of Duty...[inaudible 20:48] the attic, it was the basement, but yeah. It doesn't discriminate against gender, but for men...he's also in the military. So, it was a very good outlet for him before he went, you know, active duty or [inaudible 21:02] and just self-expression. You don't have to talk about things. +I don't think this discriminates against country by any means, but I know for America, I try to stay in my lane with just speaking about Americans, is that men have been put in a very tough position when it comes to mental health because society reinforces: keep it together; be the provider; just deal with it, and painted this picture of, like, you don't have and can't express emotions. And then, we wonder why guns are an issue. We wonder why drinking and alcoholism is an issue and, you know, in the male population. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +SAMI: So, there's a lot of concerns. There's a lot of worries, and there's, I guess, negativity around tech and AI. Is there any silver lining? You know, some things we're getting from tech as we already know it, perhaps social media but also AI. Is there anything that we can look at and be like, actually, that will enhance our mental health, improve our society? Are there any positive things that you see coming from it? +SARA: I love that question because it is a heavy conversation. I tell people, if you're considering therapy, like, you got to consider it's a full-time job to intentionally lean into the heaviness of the reality that we live in. There's a lot going on right now. I kind of surprise myself every day as to why I do have some degree of hope. But I think that's also just because I see people recover every day. I am grateful for that because not everyone gets that experience. +If you're working more of a tech job and you're looking more at coding, and data, and screens all day, you don't see change from the human perspective. And if anything, if you go outside these days, it's just tense. We're extremely inflamed. I don't care what country you live in. We're all experiencing the sensory, like, I see it as...I was not good at chemistry, but one's like, when you heat up molecules and they move really fast, like, that's combustion. And it's about to be summer, so it's about to even be literally hotter. I'm not going to say it's going to get worse. +But I say that to say I do believe there is a degree of hope because not only do I see it, but I also see...I'm connected to communities who are doing work from what I kind of...is stealth and, like, covert. You're not really going to see goodness and kindness in the abundance of negativity and darkness, but it is there. And I also like to say that I educate people every day where it changes...maybe not everyone's going to change in that regard. But as an individual in a network and a system, if one person's changed, the system automatically changes. +And little by little, over time, I think the pendulum will swing back in a place where it's like, oh yeah, no, it really is happening. And I also kind of see it in this mental health crisis. Change comes out of crisis. It's unfortunate, but if we don't have a big enough reason to look at something, then we tend not to fix it, you know, be proactive. I mean, one of my goals is to get from this reactive place into a proactive and preemptive, you know, wellness space for people, but that also does have to be choice. +But I think it really has to start with people understanding and committing to themselves and taking care of themselves, which is why I also am hopeful is because that's a lot easier than trying to get other people to change for you. If you can commit and commit to yourself, and taking care of yourself, and prioritizing you being self-focused, not necessarily selfish because a lot of that gets a bad rap of like, oh, I'm being selfish. We do it a lot out of defense, which is why I think it's not that effective. +And so, like, oh, I'm just going to be selfish. I'm going to do what's best for me. You're also locking...you're doing that out of reaction typically because you're not realizing like, oh, I feel hurt because this person didn't prioritize me, so now I'm not going to prioritize them. I'm going to prioritize me. And what I mean intention and recovery comes down to like, when people hurt you, you still have to choose not to hurt them and not pull away. And so, I think if we can all understand...and it's a tough concept to stay in your lane. It really is. But if we can all try to stay in our lane and focus on taking care of ourselves, that is what I believe is going to make the most impact. +SAMI: And do you feel AI could help with that? Could we use AI? I'm interested how, like, specifically with regards to the tech, could that be part of this? +SARA: Absolutely. I think there's some foundational knowledge that needs to be done and work that needs to be done in each individual before AI can just kind of come in without creating, like, more intense dependency on it. But I know there are agencies here locally. I can't remember the name of...I was trying to remember this earlier. I met them at a networking event recently, but an agency who uses AI to help with social anxiety and role-playing when it comes to situational circumstances and exposure. +So, me as a therapist, I love doing exposure. I, for the most part, am an exposure exercise for some people is, you know, we open up and talk about, like, these things that people don't feel safe to talk about with their general networks. But AI, I've started kind of dabbling in, you know, I have some clients who deal with, you know, some, like, delusional disorders, schizoaffective disorder, where they didn't grow up in families where any of the, like, really important foundational concepts were discussed, or they were shut down. So, they're naturally trained to just stay in their head. And, in turn, you build a distrust with all the thoughts you have in your brain. +And I encourage my clients to have conversations with ChatGPT just to be like, "Hey, what's up? What's going on?" And telling it what it is that they need, to just normalize the communication of being like, okay, I'm a little nervous to go on a date. I don't know what to say. Can you help me with some ideas of what questions to ask to get to know someone? That, I think, is a lot less intimidating sometimes talking with me because my energy is easily transferable. And that can scare some people because I can get quite excited about, like, "Yo, you did that. That's great." And they're like, "Whoa, that's a lot." +SAMI: I'm loving your vibes. +SARA: Oh [laughs]. +SAMI: It's good energy. I'm enjoying it. +SARA: Well, thank you. But I have a couple of clients that...talk about an investment, and I've told them this, and I was like, "I am going to pour into you." Because they just never had certain experiences at the right time to build a degree of confidence that would get them to the next place in life, where they realized like, oh, I can do that. Failure is not that bad, and it's different for everyone. But I do think AI can help in that regard. +It also can become a little bit challenging. I had a discussion on this with a colleague of mine who works in cybersecurity, and we were talking about AI and the intersection in relationships and the impact on intimacy in relationships, mostly with heterosexual relationships. But there, yeah, it can go a very different direction than hopeful. And it can cause harm or conflict in some relationships because it's easier to talk to a very structured computer bot than it is to a woman per se. But I think it can help as well to build a foundation for people to get to those points where you can be assertive and reflective in your experiences, build emotional intelligence over time to help relationships. +RÉMY: At thoughtbot, we have worked on projects that implement AI, and we are becoming more familiar with training models. One thing that concerns us is doing this in an ethical and safe way. What tips would you have for people who are actually creating models and driving change in this space? +SARA: I'd say the first thing that comes to my mind, though, and this is kind of going to go into my talk during the conference, how do you know you're connected with your own reality? I think that's the hardest part about the tech world is like, it's the boundary. Your brain does not know the difference between a computer screen and your reality. The biggest difference is your senses. And that's kind of been the...it's what's caused a lot of the problem with tech is that, you know, here we're having this conversation. I can see y'all. I can generally take into account what your environment is like, but I can't experience it the same way as if I was not sitting in the room with you. +And I think that is when you teach people how to activate their own realities, you know, teach them about their body and the somatic work, especially with trauma. When trauma is involved, is you have to know how to activate the here and now and train your brain to know what your reality is or else you're going to get lost in the sauce of, like, everyone else's reality, let alone opinions, but especially in the virtual world. +So, being able to know your sensory activation, how mindfulness is, that's a huge term, honestly. We could unpack that for 30 minutes itself. But that sensory activation is a huge part of mindfulness is being able to experience a thought that can trigger something of a reaction and being able to effectively detach from it without judgment, you know, it's training. It takes a lot of training, but senses are huge, and being able to, I think, ethically venture into that world of, you know, using the virtual space, using AI to train and be effective. +SAMI: Yeah, I want to pick up on something you said before because it kind of scared me [laughs], which I don't mind [laughs] saying that to you, right? Because I've got this fear that probably other people have also considered as well is people say about AI taking jobs. So, as a coder, we know AI is becoming more proficient at coding. Maybe other designers, other people in the tech world have this fear as well so much so I actually mentioned this in a previous podcast. +I taught myself some, like, real physical skills because I thought when AI takes my job completely, well, at least I'll be able to do something. I actually taught myself to silicone a bathroom. And if you know, you have those silicone beads that kind of go around a bathroom, so the water doesn't get in between the grating and the tiles. So, I remember when I was learning it, thinking, well, if AI does take our jobs, at least I'll be able to do this. But that's where my brain goes sometimes. +And then, when you were mentioning about using it in a therapeutic setting, like, oh, well, it can actually be helpful to chat to an AI bot about certain scenarios that you might be trying to work through in therapy. So, I guess the question is twofold. Number one, do you see AI having a big impact in a therapeutic setting and coming in and almost disrupting that industry? And also, what tips do you have for the majority of people who are now concerned that what is life going to look like, and what is it going to be? And will we all have jobs? +SARA: I think what's important is to understand what happens to the individual when fear is at play before we can even get to the bigger question of like, will AI take our jobs? But I'll start from the end. There will be some jobs that are taken by AI. But what you're talking about Rémy is, yes, there is a huge power to know how you can connect with your own life and AI. Even if you have a job that is in tech and can be overrun by AI, you still have value as a human being. However, you're not going to feel that way, one, if you have a lot of fear because we have to understand why you can't connect with that. +But because value is an invariant, to value something, you have to be quite intentional with training your brain to understand value, and you can do that if you know what fear does to your brain, and it's...quite simply, we've all heard it. It's the stress response: fight, flight, freeze, or fawn. So, when you're having a perceived threat, it doesn't mean...external is not the only threat. We threaten ourselves all the time with our own thought process based off of the experiences that we've had and trigger our own fear. +And your brain essentially is like, hold up, no, we're not going any further. There's a risk here. We're going to stop you. So, this is where a lot of people, like, have those moments. I could stare at a wall for, like, 10 minutes, but it's actually, like, almost two hours if I'm stressed out to the point...because I'm processing too much information, but it's also triggering a stress response for my brain. And we just get saturated and stuck in that moment. So, being able to know, okay, this is happening, then we can actually come back online. +So, I use the brain as a computer metaphor quite often. And when we know that we're in that fight or flight response mode, we can in turn engage so that...I actually have an acronym for fear that I'm going to be debuting at this conference. I'll just go ahead and debut it for y'all, a little sneak peek since you guys may or may not be able to be there. So, that fear is...we usually as an acronym, if you've ever heard this, is F everything and run. +And I'm going to define it as the F would be the fight response, fight, flight, freeze, and fawn. So, if you know that's going on, you can address it. The E would be engage. So, engage with your present moment, and that's where your body is, the one thing that tends to be in that present moment. And then, the A is accept. A lot of times we have to accept that we're maybe stuck. We may be at a problem. We may need to take a break. Accepting the things that we can't change in that moment is going to make a big difference on how we come back online on our brains and be able to understand, like, AI is a threat, but it's not going to take over everything, right? And then, the R is redirect. So, redirect to something that is going to change your perception of what the original trigger was. +And so, I think if people can understand how they work and how the brain is actually self-protecting, it's very, like, it's like, whoa, we're not going to let you do something completely destructive. But it cannot distinguish the severity of the threat, let alone can it not...actually, there's a lot of people who've trained their brain to not experience fear. Fear is what is supposed to keep us safe. So, it is just perceiving like, hey, AI could take our jobs, but it's also not giving you the context that you brought up, Rémy, about it's not going to take everything from us. It's actually supposed to be here to help us in [inaudible 36:23]. And it's also dependent on us. +So, if we're creating fear in the AI, then yeah, it's going to learn that, and it, could, I don't know, I can't tell the future in that regard. But we have plenty of things that don't have to be tech-related that AI won't take from us. And a lot of that is the natural world if we can keep it alive and value it enough. +RÉMY: I have one question for you. It might not be very in sync with the train of thought we're having because it's more related to the beginning of the episode. But you mentioned sometimes rebuilding confidence with people and building confidence and building the ability to trust yourself and to make your own good decisions. It feels like, to some extent, it can be rebuilding yourself. How do you deal with such a big action, such a big project? I mean, it's something that could take life to do so. +SARA: That's a great question. And sometimes it will take people's lives. I don't handle the whole rest of their life. I tell people like, "I'm going to give you some foundational things." And I do a lot of training. I'm very direct, which is why I have that therapeutic life consultant of like, I'm going to take my vast amount of experience, things that people are probably not going to experience and help them build a security in themselves and, over time, prepare them for when they deviate from that. +I tell people, like, especially if you have loved ones still living, depression is never going to just leave. The concept...there's no cure. It's being able to be prepared for when things happen in life versus feel completely unprepared. I just came out of a season of grief of, you know, I walked away from a relationship, as well as then trying to still maintain my business, still trying to maintain my clients and those relationships, let alone the relationship with myself, and then put my cat down, you know, like, you know, he was a child. I had him for 14 years. So, like, life is going to continuously happen. So, I'm not trying to figure it all out, but I'm trying to get people back to a point where they can understand how to find security for themselves. +Since mental health has been such a taboo topic for a long time, there is quite a bit of backlog, and that's what we're seeing. I don't know what it looks like in y'alls countries, but here in America, there is this rush of people. I need a therapist. I need to go to therapy. And we're at a shortage. Therapists can't necessarily help all, like, at once. And we also have to maintain our own mental health, or we're not going to be very helpful to people. +But really, it comes down to how you build that security with yourself and know and not anticipate, but be prepared for when there's something else that happens that disturbs your own peace. Because if you have an understanding of what peace looks like for you, and you can't necessarily control it, but you can influence it, and facilitate it in your life, then you have a stronger foundation to be able to endure, you know, potential loss of a loved one, hopefully, no time soon for anyone here, or out, or listening, but it's just the reality. +And that's part of, you know, my story of, I experienced a lot of loss from a young age, and it worked against me for a long time because I had no idea how to process and regulate energy and emotion in my body. And so, what it looked like was me holding on to repressing anger, not having a relationship with the natural emotions that we can't get rid of. You can't get rid of emotions. I wish I could just, you know, vomit them out and just be done with it and be like, okay, cool. We can all be stable. That's just not...that's not going to happen. I think that also is what makes us, you know, a great species and building, you know, great things in this world is emotion. +Tech was built off of passion and emotion. Did it cause some disarray and probably hurt some people in the process? Yeah. But I think we can reduce that from happening if people understand emotional intelligence and not just work, work, work, work, work. It's a new age coming to that. And I've, hopefully, been working on myself enough to be able to sustain helping people understand and shifting over to that new type of perspective of we can't do things the way that we've been doing them. We just can't. It's not sustainable. The human species will suffer from it and the earth will as well. +SAMI: Yeah, thank you so much, and just for bringing that level of transparency and honesty. It resonates with myself, and I'm sure it will help so many other people who are listening. We could talk to you for hours. I mean, there is so much. And some things we just did not have time to get into. But thank you so much for the time that you've given us. And it's been really insightful to look at AI and tech that we work with as consultants at thoughtbot on a daily basis from this perspective and look at it from this angle. If people want to get a hold of you, where would be the best place? +SARA: Finding my website is a big thing. That's just, you know, kind of the portal. So, that's sarawilderlcsw.com. Sara with an out an H. And then, also, venturing into this tech world, I have an app interface now that I have put together to kind of be a centerpiece for mental health resources, not only just, like, hotlines. That information is on my website as well. +But if you want to start doing your own work little by little, you know, having a centralized spot as well as not too much information. There's plenty of stuff you can Google about mental health. But this is vetted by me and organized to a point where they can, you know, one worksheet can make a difference, where you're just reflecting and taking, you know, 10-15 minutes to read through it and see how you can apply it in your life. It's called Power in Perspective. +SAMI: That's great. Definitely, I recommend go and check it out and check out Sara on her website. And if you can get down to that conference, that is, again, North Carolina called CreativeVerse, and you'll have the opportunity to hear Sara in person as well as Fatima from thoughtbot who's also presenting. +If you learned nothing else from today, then just remember: fear has an acronym for F everything and run. I guess that's my big takeaway. You also got a chance to hear about my gaming addiction. No one tell my parents. +And you can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. I always leave you the same challenge, and that challenge is to subscribe. We've got some great guests lined up, and you'll hear about it first if you subscribe. And feel free to leave any comments on Spotify or Apple Podcasts. We do check them all, and they're really helpful. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech. Thanks for listening. See ya. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + mental health, AI, artificial intelligence, therapy, Sara Wilder, virtual therapy, technology in therapy, AI in mental health, psychotherapy, ChatGPT, mental health insights, AI tools, ethical AI, digital mental health, virtual consultations, AI integration, mental health technology, tech and mental health, AI and psychotherapy, innovative therapy methods + + In this podcast episode of "Giant Robots On Tour," hosts Sami Birnbaum and Rémy Hannequin explore mental health in the age of artificial intelligence with Sara Wilder, a Therapeutic Life Consultant and Licensed Clinical Social Worker. Sami shares his own brief foray into psychotherapy before transitioning to tech, highlighting the relevance of mental health in today's rapidly evolving technological landscape. Sara, whose path to therapy was influenced by her personal struggles and a desire to help others, discusses her unique approach as a Therapeutic Life Consultant, which blends traditional therapy with direct coaching and consulting.

+ +

Sara elaborates on her journey and how the COVID-19 pandemic pushed her towards integrating technology into her practice. She transitioned from in-person sessions to virtual consultations, emphasizing the impact of this shift on mental health and brain function. Sara's interest in AI stemmed from her need to scale her business and her desire to use technology to aid her clients. She discusses her experience with AI tools like ChatGPT, both the benefits and challenges, such as generating relatable content and addressing AI "hallucinations." Sara highlights the importance of using AI ethically and maintaining human oversight to ensure the authenticity and accuracy of AI-generated outputs.

+ +

The conversation also delves into broader concerns about the impact of AI and technology on mental health. Sami and Rémy discuss the addictive nature of technology and its parallels with substance addiction, emphasizing the need for self-imposed boundaries and emotional intelligence. Sara shares insights into how AI can be a valuable tool in therapy, such as using AI for social anxiety role-playing or to generate conversation prompts. The episode concludes with a discussion on the balance between leveraging AI for efficiency and maintaining human connection, stressing the need for ongoing education and ethical considerations in AI development and deployment.

+ + + +

Transcript:

+ +

 SAMI: Yes, and we are back. And this is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Sami Birnbaum.

+ +

RÉMY: And I'm your other host, Rémy Hannequin.

+ +

SAMI: Okay, if you're wondering where Jared is, we finally got rid of him. No, that's a joke, Jared, if you're listening. He was my previous co-host. You can go back to our other podcasts. But we've got Rémy on board today. And you could take a look at our previous podcast, where we introduce the Giant Robots on Tour series, where you'll find out about all the different co-hosts. And you can learn more about Rémy's sourdough bread.

+ +

Joining us today is Sara Wilder, a Therapeutic Life Consultant, Licensed Clinical Social Worker, and Clinical Addictions Specialist.

+ +

Okay, Sara, this is going to sound a little bit strange, but, actually, once upon a time in my own life, I kind of wanted to be you, not exactly you because that would be even more strange.

+ +

SARA: [chuckles]

+ +

SAMI: But before I got into coding and tech, I was interested in psychotherapy. And I started a course and, for different reasons, it didn't work out, and I never pursued that career. But what's really interested us about you is the work and research you're doing around mental health in this new world of AI, artificial intelligence. You have a really interesting talk coming up at the CreativeVerse Conference in North Carolina. And we actually have Fatima from thoughtbot who's going to be presenting at the same conference.

+ +

And you're specifically talking about prioritizing mental health in the age of AI. And there is so much we want to ask you about this. But before we do, I always like to go back to the start with my guests. Everyone has a story, and I'm interested in your journey. What led you into the world of therapy?

+ +

SARA: Well, to unpack that, it's, like, probably way too long for this podcast, but in a nutshell, I had no idea what...I did not want to be a therapist when I grew up, so thank you for wanting that more than me. But I landed here, I think, partly just because of, you know, I always wanted to help people. I never really knew what that was going to look like. I thought it maybe was going into nursing or more of the medical side. But really what landed me here and made me stay here and really choose to stay in my profession...because, at one point, I was like, no, I'm not sure I could do this for the rest of my life; this is a lot. But it was really my own suffering.

+ +

I had to take a really hard look at where I came from, what I had gone through, and why I wanted to just, you know, like, help people, but then try to keep changing how I did that. And I'm glad I chose to stay put in this kind of therapeutic, you know, life. Therapeutic life consultant is a term that I kind of formulated myself because I'm not quite a traditional therapist anymore. I'm not sitting in an office with the couch. We talk a lot about our relationship with our mothers.

+ +

But I have more of a personality that's direct and kind of coaching. And I want to go more into consulting and help people understand how to do their own healing work using my clinical background of being in diagnostics in different hospital settings, stuff like that. And because I had to do my own work, and I had to understand how to make sense of how my pain and my suffering was holding me back, and how I could turn that really into something that could help me thrive.

+ +

SAMI: Yeah, I think that's really powerful. I think that's a really powerful place to be able to come from, you know, to be able to kind of take your own challenges and the things that you've struggled with. And it's kind of like almost sometimes you have...the best teachers are the people who've gone through it themselves. And I can imagine that's been quite a journey. If only we had a longer podcast, right?

+ +

SARA: [chuckles]

+ +

SAMI: We could go into all our journeys. But it's super interesting. And, specifically, what has then kind of propelled you more towards looking into the tech aspect of it, right? So, I'm assuming...well, AI, at least, is relatively recent. And so, I'm assuming when you started out, it was more, like you're saying, a therapeutic setting, a life coaching setting, and now there's this sort of other angle, which is kind of coming into it. So, how did you end up getting involved or interested in the tech or the AI side?

+ +

SARA: I am an entrepreneur myself. When we go into what we call private practice, there is an element of business that most of us don't know. They don't really teach you business in social work school, and I kind of had to figure it out. But what really pushed me off that ledge to just figure it out and fly was COVID. And I, you know, went from a traditional office with the couch to being virtual. And it was going to be temporary, but I made the decision, and it was quite a difficult decision, given what I had already experienced in helping people through that transition, you know, going from traditional office spaces to at-home working.

+ +

But it was, yeah, I really had to understand the impact of technology on my practice, let alone my life. Working from home is a very different lifestyle when it comes to understanding what mental health means. You know, working from home and brain health is a big focus of, you know, what I discuss with my clients and educate them on. But more recently, and this is kind of how I got into the conference, when I started realizing that a lot of my own mental health was...I needed an outlet of creativity of something to be able to help me cope. I realized my business, and my content, and my passion could be that. So, I had to figure out how to scale myself.

+ +

And I'm still learning AI. I have an assistant, and she helps me. I have to use her to help me use ChatGPT because it is a beast if you don't know not only just learning the program but learning how to use it and also for it to really be authentic and not necessarily something that, you know, the bot just develops content for you, and you don't make it your own. So, it's a big old brain twister. And the concept of perception is very delicate, let alone with AI. But when you bring it into the tech world, it's a completely different type of language.

+ +

RÉMY: Since you started working with AI, you mentioned ChatGPT, have you noticed answers or generated content that is either incredibly useful and accurate, and, on the other side, other content that might be, I won't say disturbing, but at least not exactly what you would expect from a human?

+ +

SARA: Yeah, absolutely. It kind of weirds me out to, like...because I use it to kind of help my creative flow, like, if I have a blog post that I need to write. And it's very important for me to, you know, bring myself into my writing. So, when I started with ChatGPT, and it brings up something, and I'm like, who ever says that? Like, no one says that. Like, that's completely maybe like, you know, just it's a little bit unrelatable and a little stiff, I guess, is the best word I can use.

+ +

And then, I go through the processing of like, okay, let me figure out how I would write this. I feel like it does help me. It does prolong the process a little bit more. But I have also, yeah, so just kind of relatability factor, for me, is the first thing that sticks out.

+ +

But the other thing that I've learned a little bit more about listening to, you know, other podcasts and just trying to educate myself, which is a funny term because we use this, you know, in my field of mental health all the time, is it comes up with hallucination. So, it will fill in gaps of, you know, whether it be data, or in a statistic, or whether it's just a concept that it kind of makes up to kind of fill and have fillers in what it produces, which I'm still new to understanding what that really means. Like, yeah, it definitely can be some...and it needs to be something that we fact-check as well since it's just pulling from the general abyss of the internet, and that's not always the most accurate, you know, place of reference in general.

+ +

SAMI: Yeah, I can vouch for the abyss of the internet not always being the best place to find yourself [laughs]. There's some rabbit holes we've probably all been down. But it's so interesting because I find that the world has woken up to the impact that social media has had on everyone's mental health. And it almost feels like that was our first experiment with how tech can really impact us as a society and as individuals. And so, we've kind of seen that experiment and how that's played out, and I would argue we've probably failed. We've probably had this social media wave. And whether you'd look at it from a government perspective or a healthcare perspective, I don't actually think we've handled it well.

+ +

And it's almost, like, now we're on the cusp of our second experiment, right? This is now, okay, no longer social media. I mean, that is still relevant but put that to the side for a second. And you've got AI coming out with all these chatbots, generative AI, whether that's across images, text, and the impact that is going to have. So, I feel like the space that you're in is huge. I think you spoke before we started recording about, like, there's a mental health crisis. What do you see, or what concerns do you have given what we've seen with social media, the impact AI can have on our mental health?

+ +

SARA: You know, there's a lot of different points here, but I think I'll just go with the first thing that comes to my mind is the limits. There are not many limits, let alone...so, tech in itself, but just in our own natural human world, as individuals, we have to learn what boundaries are. We have to learn self-imposed limitations or else someone else is going to impose them on us, and that just doesn't feel as good when someone puts their own limitations on our reality.

+ +

So, when we bring this into tech,...and I also include...since my background is in addictions, I started realizing that correlation between, like, technology, the boom of access to information is really...it's a pleasure concept, is that when we have a thought and we can just go get information about the answer and it's immediate, that immediate gratification teaches the brain like, oh, I can do this. I can handle this myself. We're not looking at the by-product of that anymore. And I think because we're dealing with it, we can't really...we're so in it now. We can't see that like, oh, this could potentially be a problem, because it is.

+ +

We have become an immediate access world. I mean, even in rural...like, kids in Africa have a TikTok dancing. And they don't have running water in their communities, but they have a cell phone where they can get support. Like, I'm glad they can because that's great access. But they're not necessarily realizing the addictive aspect of what just being interconnected this way has on the brain, let alone the foundational understanding of what boundaries, and self-discipline, or just mental discipline would look like.

+ +

So, then when you bring this, I think, into the, you know, the AI world, we're already on a shaky ground of abuse of information and having too much information and not knowing how to process it. And I think that's probably been...I know an issue, for me, is that when I have too much information, I can't necessarily ask questions very well because I'm like, what is the question? Like, I know my brain is oversaturated, essentially, with information as well as potentially chemicals at this point because I'm just working so fast, so fast, so fast.

+ +

And I'm in my mid-thirties at this point. So, a teenager who's already dealing with impulse control issues because they're naturally developing, that gets really complicated very quickly. And that's what, in turn, we call attention deficit disorder, anxiety, autism spectrum. That's a little bit more complicated, but a lot of that intersects to be like, well, what are we dealing with? We're dealing with immediate gratification and a sensory processing issue because we're looking at screens, and our brains don't know how to adapt to that let alone regulate that.

+ +

SAMI: That makes so much sense. I guess it's because it's kind of a world that we all inhabit, right? As much as we talk about this and sometimes we like to think of the other like we're talking about someone else, I've found this in my own life as well. I'm addicted to my phone in ways, and I'm also seeking that immediate gratification. And it's almost, like you said, that dopamine hit, right? If there's a piece of information I want or there's a video that I want to see, it's there, and it's immediate.

+ +

And when you say these things, I guess it's kind of...it's a bit scary. And then, I wonder, on a more macro level, why, as a society, do we do this to ourselves? I don't expect anyone on this podcast [chuckles] to have the answer, right? But I'm always interested, like, if we're aware of this and we're cognizant of what's going on, and, Rémy, feel free to jump in on this as well, like, as a society, why are we doing this to ourselves?

+ +

SARA: Now, by no means is this...like, this is just my answer, and I don't have the answer for everything. But I've had...sometimes as a therapist, you have to fill space and come up with an answer. So, my hypothesis is that it's natural human behavior. I think our brains...we are, you know, survival of the fittest. That's natural. Like, at the end of the day, we're going to fight for our life. And life really comes down, in my perspective, it comes down to, like, we have suffering, and we have pleasure.

+ +

However, we've learned now that as an evolving, you know, species, that we are one of the only species that can build executive functioning skills in our brains and have different parts of that that we have to kind of understand the baseline. Survival has gotten us so far, and we've made a lot of great headway with that. But pleasure is not sustainable. Pleasure is a beautiful concept to have in life. But when we talk about what's the goal of life, we want to be happy. Happy and pleasure are actually two very different things to the brain. And a lot of it is just a matter of space being used.

+ +

Pleasure and dopamine is actually a very small part of the brain, whereas happiness expands and is able to circulate chemicals, and synapses, and energy throughout the rest of the brain but that it has to be a conscious choice. And I think a lot of people don't realize, yeah, you're making choices. I'm not saying, like, no one doesn't have, you know, some degree of free will, but if you're dealing with any degree of stress, emotions, cognitive bias in general, you're not making an actual, like, expansive choice about what options you have to expand your consciousness and your brain capacity.

+ +

RÉMY: I like the way that today we realized that a lot of things related to this is chemicals that we all have, which remove a little bit the guilt when you are addicted, you know, because it can happen to anyone. But also, it's a reminder that it can happen to anyone. So, nobody is immune to that because that's how we're built. And I really like this approach. It's just natural, which means it's okay to feel it. But it's also dangerous to anyone, so anyone should address it. And, again, if you feel like you're losing it and losing to addiction, it feels good to just know that everybody is entitled to, unfortunately, to feel that at some point in their life.

+ +

SARA: I love that you mentioned that, and that's absolutely one of my goals is to break down the stigma of...when I use the word addiction...and I don't do small talk that well because I'm just like, let's talk about some real things here. This is what's going on. And it's scary to think of, like, addiction and what that means because of how we've seen it. And I don't know what it looks like particularly in the countries that you're from...a little bit. But I know, here in America, it's messy. It's hurtful. It's a lot of suffering.

+ +

It doesn't make us feel good to even think about that, which is why I try to teach my clients how to manage and regulate that because it does not discriminate. It's your brain. It's doing its natural thing and how you have to train and just learn how to train that. And it can get better, for sure. But yeah, I really try to break through, like, it's not something that we need to keep being scared about because that is actually what gives it its power. It gives that restrictiveness and that isolation and breaks that connection from each other. And that's ultimately what brings us out of an active addictive cycle is connection.

+ +

SAMI: Yeah, it's really interesting because technology it almost masks that by making you feel really connected. Like, I'm connected to all these people and all these things, but I don't feel that connection. And that really resonates with me when you talk about the difference between pleasure and happiness.

+ +

So, I hope my parents don't listen to this. But when I was in university, I'm pretty sure I had a gaming addiction. So, I used to live in the loft in my house. I don't know what you'd call it in America. Maybe it's called the attic. I was at the top floor. So, essentially, I had...oh, back then, it would have been a PS3, and I was seriously addicted to Call of Duty, playing online.

+ +

And I remember doing just all-nighters, like, really often. I remember it got to a point where I would almost have to reset my whole sleep cycle because I ended up in a situation where I'd be awake in the night kind of always playing all night because I couldn't put the game down, and then sleeping during the day. And to get myself back into a normal rhythm, I'd have to force myself to stay awake for 24 hours. And I would even consider myself someone who doesn't have an addictive personality.

+ +

But when you were saying about the difference between pleasure and happiness, like, it was definitely hitting that dopamine, and it was pleasurable, but I didn't feel happy. Like, once I stopped, then there was all those feelings that Rémy described, which is, oh no, what have I done? I've wasted so much time and all that guilt that comes with it. So, it's really interesting.

+ +

And I guess it's also a bit like a codependency, which is something I've seen that you've touched on in your work as well, which I understand to be an unhealthy reliance on a human relationship. But I'm guessing we're probably seeing more of that and unhealthy reliance on tech software products and AI. Is that something you're seeing in your therapeutic work as well?

+ +

SARA: Oh, absolutely. Codependency it's a big topic to unpack. And I'll say it's a balance. We're never going to not be codependent on something because it literally...we're supposed to work together. We need each other to survive and to grow. But the unhealthy parts of it is, I think, because...I'll just speak from my own experience. I was never taught what emotional intelligence was when I was a kid. I grew up in a very middle-class, non-diverse part of the United States, where I didn't understand the foundational, like, what are boundaries? What are emotions? They try to teach you.

+ +

And I think that's been something that is going to take people a while to understand. But there is an unhealthy part of it because it's just mixed with...and confuse people of what do we actually need to need other people for. And it naturally sends us...I think this is primarily where relationships become a point of the discussion is relationships are necessary. But they're less successful if you don't have a relationship with yourself as a foundation because that's naturally going to help you realize that you don't need this one person. And you don't attach to a person out of necessity and out of survival or else, yeah, you're going to lose a huge aspect of your identity because you didn't have much of one to begin with.

+ +

And so, that's ultimately what I teach and educate people on when I work with them in session is just what codependency really is. We're going to be codependent on something. I'd rather you be aware of it. Denial is just dangerous in general. But being aware of how these things show up, you have a better of a choice now. And free will comes back to really in your control without less consequence over time or less negative consequence over time. [inaudible 20:44] my brother, though, Rémy. Call of Duty...[inaudible 20:48] the attic, it was the basement, but yeah. It doesn't discriminate against gender, but for men...he's also in the military. So, it was a very good outlet for him before he went, you know, active duty or [inaudible 21:02] and just self-expression. You don't have to talk about things.

+ +

I don't think this discriminates against country by any means, but I know for America, I try to stay in my lane with just speaking about Americans, is that men have been put in a very tough position when it comes to mental health because society reinforces: keep it together; be the provider; just deal with it, and painted this picture of, like, you don't have and can't express emotions. And then, we wonder why guns are an issue. We wonder why drinking and alcoholism is an issue and, you know, in the male population.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

SAMI: So, there's a lot of concerns. There's a lot of worries, and there's, I guess, negativity around tech and AI. Is there any silver lining? You know, some things we're getting from tech as we already know it, perhaps social media but also AI. Is there anything that we can look at and be like, actually, that will enhance our mental health, improve our society? Are there any positive things that you see coming from it?

+ +

SARA: I love that question because it is a heavy conversation. I tell people, if you're considering therapy, like, you got to consider it's a full-time job to intentionally lean into the heaviness of the reality that we live in. There's a lot going on right now. I kind of surprise myself every day as to why I do have some degree of hope. But I think that's also just because I see people recover every day. I am grateful for that because not everyone gets that experience.

+ +

If you're working more of a tech job and you're looking more at coding, and data, and screens all day, you don't see change from the human perspective. And if anything, if you go outside these days, it's just tense. We're extremely inflamed. I don't care what country you live in. We're all experiencing the sensory, like, I see it as...I was not good at chemistry, but one's like, when you heat up molecules and they move really fast, like, that's combustion. And it's about to be summer, so it's about to even be literally hotter. I'm not going to say it's going to get worse.

+ +

But I say that to say I do believe there is a degree of hope because not only do I see it, but I also see...I'm connected to communities who are doing work from what I kind of...is stealth and, like, covert. You're not really going to see goodness and kindness in the abundance of negativity and darkness, but it is there. And I also like to say that I educate people every day where it changes...maybe not everyone's going to change in that regard. But as an individual in a network and a system, if one person's changed, the system automatically changes.

+ +

And little by little, over time, I think the pendulum will swing back in a place where it's like, oh yeah, no, it really is happening. And I also kind of see it in this mental health crisis. Change comes out of crisis. It's unfortunate, but if we don't have a big enough reason to look at something, then we tend not to fix it, you know, be proactive. I mean, one of my goals is to get from this reactive place into a proactive and preemptive, you know, wellness space for people, but that also does have to be choice.

+ +

But I think it really has to start with people understanding and committing to themselves and taking care of themselves, which is why I also am hopeful is because that's a lot easier than trying to get other people to change for you. If you can commit and commit to yourself, and taking care of yourself, and prioritizing you being self-focused, not necessarily selfish because a lot of that gets a bad rap of like, oh, I'm being selfish. We do it a lot out of defense, which is why I think it's not that effective.

+ +

And so, like, oh, I'm just going to be selfish. I'm going to do what's best for me. You're also locking...you're doing that out of reaction typically because you're not realizing like, oh, I feel hurt because this person didn't prioritize me, so now I'm not going to prioritize them. I'm going to prioritize me. And what I mean intention and recovery comes down to like, when people hurt you, you still have to choose not to hurt them and not pull away. And so, I think if we can all understand...and it's a tough concept to stay in your lane. It really is. But if we can all try to stay in our lane and focus on taking care of ourselves, that is what I believe is going to make the most impact.

+ +

SAMI: And do you feel AI could help with that? Could we use AI? I'm interested how, like, specifically with regards to the tech, could that be part of this?

+ +

SARA: Absolutely. I think there's some foundational knowledge that needs to be done and work that needs to be done in each individual before AI can just kind of come in without creating, like, more intense dependency on it. But I know there are agencies here locally. I can't remember the name of...I was trying to remember this earlier. I met them at a networking event recently, but an agency who uses AI to help with social anxiety and role-playing when it comes to situational circumstances and exposure.

+ +

So, me as a therapist, I love doing exposure. I, for the most part, am an exposure exercise for some people is, you know, we open up and talk about, like, these things that people don't feel safe to talk about with their general networks. But AI, I've started kind of dabbling in, you know, I have some clients who deal with, you know, some, like, delusional disorders, schizoaffective disorder, where they didn't grow up in families where any of the, like, really important foundational concepts were discussed, or they were shut down. So, they're naturally trained to just stay in their head. And, in turn, you build a distrust with all the thoughts you have in your brain.

+ +

And I encourage my clients to have conversations with ChatGPT just to be like, "Hey, what's up? What's going on?" And telling it what it is that they need, to just normalize the communication of being like, okay, I'm a little nervous to go on a date. I don't know what to say. Can you help me with some ideas of what questions to ask to get to know someone? That, I think, is a lot less intimidating sometimes talking with me because my energy is easily transferable. And that can scare some people because I can get quite excited about, like, "Yo, you did that. That's great." And they're like, "Whoa, that's a lot."

+ +

SAMI: I'm loving your vibes.

+ +

SARA: Oh [laughs].

+ +

SAMI: It's good energy. I'm enjoying it.

+ +

SARA: Well, thank you. But I have a couple of clients that...talk about an investment, and I've told them this, and I was like, "I am going to pour into you." Because they just never had certain experiences at the right time to build a degree of confidence that would get them to the next place in life, where they realized like, oh, I can do that. Failure is not that bad, and it's different for everyone. But I do think AI can help in that regard.

+ +

It also can become a little bit challenging. I had a discussion on this with a colleague of mine who works in cybersecurity, and we were talking about AI and the intersection in relationships and the impact on intimacy in relationships, mostly with heterosexual relationships. But there, yeah, it can go a very different direction than hopeful. And it can cause harm or conflict in some relationships because it's easier to talk to a very structured computer bot than it is to a woman per se. But I think it can help as well to build a foundation for people to get to those points where you can be assertive and reflective in your experiences, build emotional intelligence over time to help relationships.

+ +

RÉMY: At thoughtbot, we have worked on projects that implement AI, and we are becoming more familiar with training models. One thing that concerns us is doing this in an ethical and safe way. What tips would you have for people who are actually creating models and driving change in this space?

+ +

SARA: I'd say the first thing that comes to my mind, though, and this is kind of going to go into my talk during the conference, how do you know you're connected with your own reality? I think that's the hardest part about the tech world is like, it's the boundary. Your brain does not know the difference between a computer screen and your reality. The biggest difference is your senses. And that's kind of been the...it's what's caused a lot of the problem with tech is that, you know, here we're having this conversation. I can see y'all. I can generally take into account what your environment is like, but I can't experience it the same way as if I was not sitting in the room with you.

+ +

And I think that is when you teach people how to activate their own realities, you know, teach them about their body and the somatic work, especially with trauma. When trauma is involved, is you have to know how to activate the here and now and train your brain to know what your reality is or else you're going to get lost in the sauce of, like, everyone else's reality, let alone opinions, but especially in the virtual world.

+ +

So, being able to know your sensory activation, how mindfulness is, that's a huge term, honestly. We could unpack that for 30 minutes itself. But that sensory activation is a huge part of mindfulness is being able to experience a thought that can trigger something of a reaction and being able to effectively detach from it without judgment, you know, it's training. It takes a lot of training, but senses are huge, and being able to, I think, ethically venture into that world of, you know, using the virtual space, using AI to train and be effective.

+ +

SAMI: Yeah, I want to pick up on something you said before because it kind of scared me [laughs], which I don't mind [laughs] saying that to you, right? Because I've got this fear that probably other people have also considered as well is people say about AI taking jobs. So, as a coder, we know AI is becoming more proficient at coding. Maybe other designers, other people in the tech world have this fear as well so much so I actually mentioned this in a previous podcast.

+ +

I taught myself some, like, real physical skills because I thought when AI takes my job completely, well, at least I'll be able to do something. I actually taught myself to silicone a bathroom. And if you know, you have those silicone beads that kind of go around a bathroom, so the water doesn't get in between the grating and the tiles. So, I remember when I was learning it, thinking, well, if AI does take our jobs, at least I'll be able to do this. But that's where my brain goes sometimes.

+ +

And then, when you were mentioning about using it in a therapeutic setting, like, oh, well, it can actually be helpful to chat to an AI bot about certain scenarios that you might be trying to work through in therapy. So, I guess the question is twofold. Number one, do you see AI having a big impact in a therapeutic setting and coming in and almost disrupting that industry? And also, what tips do you have for the majority of people who are now concerned that what is life going to look like, and what is it going to be? And will we all have jobs?

+ +

SARA: I think what's important is to understand what happens to the individual when fear is at play before we can even get to the bigger question of like, will AI take our jobs? But I'll start from the end. There will be some jobs that are taken by AI. But what you're talking about Rémy is, yes, there is a huge power to know how you can connect with your own life and AI. Even if you have a job that is in tech and can be overrun by AI, you still have value as a human being. However, you're not going to feel that way, one, if you have a lot of fear because we have to understand why you can't connect with that.

+ +

But because value is an invariant, to value something, you have to be quite intentional with training your brain to understand value, and you can do that if you know what fear does to your brain, and it's...quite simply, we've all heard it. It's the stress response: fight, flight, freeze, or fawn. So, when you're having a perceived threat, it doesn't mean...external is not the only threat. We threaten ourselves all the time with our own thought process based off of the experiences that we've had and trigger our own fear.

+ +

And your brain essentially is like, hold up, no, we're not going any further. There's a risk here. We're going to stop you. So, this is where a lot of people, like, have those moments. I could stare at a wall for, like, 10 minutes, but it's actually, like, almost two hours if I'm stressed out to the point...because I'm processing too much information, but it's also triggering a stress response for my brain. And we just get saturated and stuck in that moment. So, being able to know, okay, this is happening, then we can actually come back online.

+ +

So, I use the brain as a computer metaphor quite often. And when we know that we're in that fight or flight response mode, we can in turn engage so that...I actually have an acronym for fear that I'm going to be debuting at this conference. I'll just go ahead and debut it for y'all, a little sneak peek since you guys may or may not be able to be there. So, that fear is...we usually as an acronym, if you've ever heard this, is F everything and run.

+ +

And I'm going to define it as the F would be the fight response, fight, flight, freeze, and fawn. So, if you know that's going on, you can address it. The E would be engage. So, engage with your present moment, and that's where your body is, the one thing that tends to be in that present moment. And then, the A is accept. A lot of times we have to accept that we're maybe stuck. We may be at a problem. We may need to take a break. Accepting the things that we can't change in that moment is going to make a big difference on how we come back online on our brains and be able to understand, like, AI is a threat, but it's not going to take over everything, right? And then, the R is redirect. So, redirect to something that is going to change your perception of what the original trigger was.

+ +

And so, I think if people can understand how they work and how the brain is actually self-protecting, it's very, like, it's like, whoa, we're not going to let you do something completely destructive. But it cannot distinguish the severity of the threat, let alone can it not...actually, there's a lot of people who've trained their brain to not experience fear. Fear is what is supposed to keep us safe. So, it is just perceiving like, hey, AI could take our jobs, but it's also not giving you the context that you brought up, Rémy, about it's not going to take everything from us. It's actually supposed to be here to help us in [inaudible 36:23]. And it's also dependent on us.

+ +

So, if we're creating fear in the AI, then yeah, it's going to learn that, and it, could, I don't know, I can't tell the future in that regard. But we have plenty of things that don't have to be tech-related that AI won't take from us. And a lot of that is the natural world if we can keep it alive and value it enough.

+ +

RÉMY: I have one question for you. It might not be very in sync with the train of thought we're having because it's more related to the beginning of the episode. But you mentioned sometimes rebuilding confidence with people and building confidence and building the ability to trust yourself and to make your own good decisions. It feels like, to some extent, it can be rebuilding yourself. How do you deal with such a big action, such a big project? I mean, it's something that could take life to do so.

+ +

SARA: That's a great question. And sometimes it will take people's lives. I don't handle the whole rest of their life. I tell people like, "I'm going to give you some foundational things." And I do a lot of training. I'm very direct, which is why I have that therapeutic life consultant of like, I'm going to take my vast amount of experience, things that people are probably not going to experience and help them build a security in themselves and, over time, prepare them for when they deviate from that.

+ +

I tell people, like, especially if you have loved ones still living, depression is never going to just leave. The concept...there's no cure. It's being able to be prepared for when things happen in life versus feel completely unprepared. I just came out of a season of grief of, you know, I walked away from a relationship, as well as then trying to still maintain my business, still trying to maintain my clients and those relationships, let alone the relationship with myself, and then put my cat down, you know, like, you know, he was a child. I had him for 14 years. So, like, life is going to continuously happen. So, I'm not trying to figure it all out, but I'm trying to get people back to a point where they can understand how to find security for themselves.

+ +

Since mental health has been such a taboo topic for a long time, there is quite a bit of backlog, and that's what we're seeing. I don't know what it looks like in y'alls countries, but here in America, there is this rush of people. I need a therapist. I need to go to therapy. And we're at a shortage. Therapists can't necessarily help all, like, at once. And we also have to maintain our own mental health, or we're not going to be very helpful to people.

+ +

But really, it comes down to how you build that security with yourself and know and not anticipate, but be prepared for when there's something else that happens that disturbs your own peace. Because if you have an understanding of what peace looks like for you, and you can't necessarily control it, but you can influence it, and facilitate it in your life, then you have a stronger foundation to be able to endure, you know, potential loss of a loved one, hopefully, no time soon for anyone here, or out, or listening, but it's just the reality.

+ +

And that's part of, you know, my story of, I experienced a lot of loss from a young age, and it worked against me for a long time because I had no idea how to process and regulate energy and emotion in my body. And so, what it looked like was me holding on to repressing anger, not having a relationship with the natural emotions that we can't get rid of. You can't get rid of emotions. I wish I could just, you know, vomit them out and just be done with it and be like, okay, cool. We can all be stable. That's just not...that's not going to happen. I think that also is what makes us, you know, a great species and building, you know, great things in this world is emotion.

+ +

Tech was built off of passion and emotion. Did it cause some disarray and probably hurt some people in the process? Yeah. But I think we can reduce that from happening if people understand emotional intelligence and not just work, work, work, work, work. It's a new age coming to that. And I've, hopefully, been working on myself enough to be able to sustain helping people understand and shifting over to that new type of perspective of we can't do things the way that we've been doing them. We just can't. It's not sustainable. The human species will suffer from it and the earth will as well.

+ +

SAMI: Yeah, thank you so much, and just for bringing that level of transparency and honesty. It resonates with myself, and I'm sure it will help so many other people who are listening. We could talk to you for hours. I mean, there is so much. And some things we just did not have time to get into. But thank you so much for the time that you've given us. And it's been really insightful to look at AI and tech that we work with as consultants at thoughtbot on a daily basis from this perspective and look at it from this angle. If people want to get a hold of you, where would be the best place?

+ +

SARA: Finding my website is a big thing. That's just, you know, kind of the portal. So, that's sarawilderlcsw.com. Sara with an out an H. And then, also, venturing into this tech world, I have an app interface now that I have put together to kind of be a centerpiece for mental health resources, not only just, like, hotlines. That information is on my website as well.

+ +

But if you want to start doing your own work little by little, you know, having a centralized spot as well as not too much information. There's plenty of stuff you can Google about mental health. But this is vetted by me and organized to a point where they can, you know, one worksheet can make a difference, where you're just reflecting and taking, you know, 10-15 minutes to read through it and see how you can apply it in your life. It's called Power in Perspective.

+ +

SAMI: That's great. Definitely, I recommend go and check it out and check out Sara on her website. And if you can get down to that conference, that is, again, North Carolina called CreativeVerse, and you'll have the opportunity to hear Sara in person as well as Fatima from thoughtbot who's also presenting.

+ +

If you learned nothing else from today, then just remember: fear has an acronym for F everything and run. I guess that's my big takeaway. You also got a chance to hear about my gaming addiction. No one tell my parents.

+ +

And you can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. I always leave you the same challenge, and that challenge is to subscribe. We've got some great guests lined up, and you'll hear about it first if you subscribe. And feel free to leave any comments on Spotify or Apple Podcasts. We do check them all, and they're really helpful.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech. Thanks for listening. See ya.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this podcast episode of "Giant Robots On Tour," hosts Sami Birnbaum and Rémy Hannequin explore mental health in the age of artificial intelligence with Sara Wilder, a Therapeutic Life Consultant and Licensed Clinical Social Worker. Sami shares his own brief foray into psychotherapy before transitioning to tech, highlighting the relevance of mental health in today's rapidly evolving technological landscape. Sara, whose path to therapy was influenced by her personal struggles and a desire to help others, discusses her unique approach as a Therapeutic Life Consultant, which blends traditional therapy with direct coaching and consulting.

+ +

Sara elaborates on her journey and how the COVID-19 pandemic pushed her towards integrating technology into her practice. She transitioned from in-person sessions to virtual consultations, emphasizing the impact of this shift on mental health and brain function. Sara's interest in AI stemmed from her need to scale her business and her desire to use technology to aid her clients. She discusses her experience with AI tools like ChatGPT, both the benefits and challenges, such as generating relatable content and addressing AI "hallucinations." Sara highlights the importance of using AI ethically and maintaining human oversight to ensure the authenticity and accuracy of AI-generated outputs.

+ +

The conversation also delves into broader concerns about the impact of AI and technology on mental health. Sami and Rémy discuss the addictive nature of technology and its parallels with substance addiction, emphasizing the need for self-imposed boundaries and emotional intelligence. Sara shares insights into how AI can be a valuable tool in therapy, such as using AI for social anxiety role-playing or to generate conversation prompts. The episode concludes with a discussion on the balance between leveraging AI for efficiency and maintaining human connection, stressing the need for ongoing education and ethical considerations in AI development and deployment.

+ + + +

Transcript:

+ +

 SAMI: Yes, and we are back. And this is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Sami Birnbaum.

+ +

RÉMY: And I'm your other host, Rémy Hannequin.

+ +

SAMI: Okay, if you're wondering where Jared is, we finally got rid of him. No, that's a joke, Jared, if you're listening. He was my previous co-host. You can go back to our other podcasts. But we've got Rémy on board today. And you could take a look at our previous podcast, where we introduce the Giant Robots on Tour series, where you'll find out about all the different co-hosts. And you can learn more about Rémy's sourdough bread.

+ +

Joining us today is Sara Wilder, a Therapeutic Life Consultant, Licensed Clinical Social Worker, and Clinical Addictions Specialist.

+ +

Okay, Sara, this is going to sound a little bit strange, but, actually, once upon a time in my own life, I kind of wanted to be you, not exactly you because that would be even more strange.

+ +

SARA: [chuckles]

+ +

SAMI: But before I got into coding and tech, I was interested in psychotherapy. And I started a course and, for different reasons, it didn't work out, and I never pursued that career. But what's really interested us about you is the work and research you're doing around mental health in this new world of AI, artificial intelligence. You have a really interesting talk coming up at the CreativeVerse Conference in North Carolina. And we actually have Fatima from thoughtbot who's going to be presenting at the same conference.

+ +

And you're specifically talking about prioritizing mental health in the age of AI. And there is so much we want to ask you about this. But before we do, I always like to go back to the start with my guests. Everyone has a story, and I'm interested in your journey. What led you into the world of therapy?

+ +

SARA: Well, to unpack that, it's, like, probably way too long for this podcast, but in a nutshell, I had no idea what...I did not want to be a therapist when I grew up, so thank you for wanting that more than me. But I landed here, I think, partly just because of, you know, I always wanted to help people. I never really knew what that was going to look like. I thought it maybe was going into nursing or more of the medical side. But really what landed me here and made me stay here and really choose to stay in my profession...because, at one point, I was like, no, I'm not sure I could do this for the rest of my life; this is a lot. But it was really my own suffering.

+ +

I had to take a really hard look at where I came from, what I had gone through, and why I wanted to just, you know, like, help people, but then try to keep changing how I did that. And I'm glad I chose to stay put in this kind of therapeutic, you know, life. Therapeutic life consultant is a term that I kind of formulated myself because I'm not quite a traditional therapist anymore. I'm not sitting in an office with the couch. We talk a lot about our relationship with our mothers.

+ +

But I have more of a personality that's direct and kind of coaching. And I want to go more into consulting and help people understand how to do their own healing work using my clinical background of being in diagnostics in different hospital settings, stuff like that. And because I had to do my own work, and I had to understand how to make sense of how my pain and my suffering was holding me back, and how I could turn that really into something that could help me thrive.

+ +

SAMI: Yeah, I think that's really powerful. I think that's a really powerful place to be able to come from, you know, to be able to kind of take your own challenges and the things that you've struggled with. And it's kind of like almost sometimes you have...the best teachers are the people who've gone through it themselves. And I can imagine that's been quite a journey. If only we had a longer podcast, right?

+ +

SARA: [chuckles]

+ +

SAMI: We could go into all our journeys. But it's super interesting. And, specifically, what has then kind of propelled you more towards looking into the tech aspect of it, right? So, I'm assuming...well, AI, at least, is relatively recent. And so, I'm assuming when you started out, it was more, like you're saying, a therapeutic setting, a life coaching setting, and now there's this sort of other angle, which is kind of coming into it. So, how did you end up getting involved or interested in the tech or the AI side?

+ +

SARA: I am an entrepreneur myself. When we go into what we call private practice, there is an element of business that most of us don't know. They don't really teach you business in social work school, and I kind of had to figure it out. But what really pushed me off that ledge to just figure it out and fly was COVID. And I, you know, went from a traditional office with the couch to being virtual. And it was going to be temporary, but I made the decision, and it was quite a difficult decision, given what I had already experienced in helping people through that transition, you know, going from traditional office spaces to at-home working.

+ +

But it was, yeah, I really had to understand the impact of technology on my practice, let alone my life. Working from home is a very different lifestyle when it comes to understanding what mental health means. You know, working from home and brain health is a big focus of, you know, what I discuss with my clients and educate them on. But more recently, and this is kind of how I got into the conference, when I started realizing that a lot of my own mental health was...I needed an outlet of creativity of something to be able to help me cope. I realized my business, and my content, and my passion could be that. So, I had to figure out how to scale myself.

+ +

And I'm still learning AI. I have an assistant, and she helps me. I have to use her to help me use ChatGPT because it is a beast if you don't know not only just learning the program but learning how to use it and also for it to really be authentic and not necessarily something that, you know, the bot just develops content for you, and you don't make it your own. So, it's a big old brain twister. And the concept of perception is very delicate, let alone with AI. But when you bring it into the tech world, it's a completely different type of language.

+ +

RÉMY: Since you started working with AI, you mentioned ChatGPT, have you noticed answers or generated content that is either incredibly useful and accurate, and, on the other side, other content that might be, I won't say disturbing, but at least not exactly what you would expect from a human?

+ +

SARA: Yeah, absolutely. It kind of weirds me out to, like...because I use it to kind of help my creative flow, like, if I have a blog post that I need to write. And it's very important for me to, you know, bring myself into my writing. So, when I started with ChatGPT, and it brings up something, and I'm like, who ever says that? Like, no one says that. Like, that's completely maybe like, you know, just it's a little bit unrelatable and a little stiff, I guess, is the best word I can use.

+ +

And then, I go through the processing of like, okay, let me figure out how I would write this. I feel like it does help me. It does prolong the process a little bit more. But I have also, yeah, so just kind of relatability factor, for me, is the first thing that sticks out.

+ +

But the other thing that I've learned a little bit more about listening to, you know, other podcasts and just trying to educate myself, which is a funny term because we use this, you know, in my field of mental health all the time, is it comes up with hallucination. So, it will fill in gaps of, you know, whether it be data, or in a statistic, or whether it's just a concept that it kind of makes up to kind of fill and have fillers in what it produces, which I'm still new to understanding what that really means. Like, yeah, it definitely can be some...and it needs to be something that we fact-check as well since it's just pulling from the general abyss of the internet, and that's not always the most accurate, you know, place of reference in general.

+ +

SAMI: Yeah, I can vouch for the abyss of the internet not always being the best place to find yourself [laughs]. There's some rabbit holes we've probably all been down. But it's so interesting because I find that the world has woken up to the impact that social media has had on everyone's mental health. And it almost feels like that was our first experiment with how tech can really impact us as a society and as individuals. And so, we've kind of seen that experiment and how that's played out, and I would argue we've probably failed. We've probably had this social media wave. And whether you'd look at it from a government perspective or a healthcare perspective, I don't actually think we've handled it well.

+ +

And it's almost, like, now we're on the cusp of our second experiment, right? This is now, okay, no longer social media. I mean, that is still relevant but put that to the side for a second. And you've got AI coming out with all these chatbots, generative AI, whether that's across images, text, and the impact that is going to have. So, I feel like the space that you're in is huge. I think you spoke before we started recording about, like, there's a mental health crisis. What do you see, or what concerns do you have given what we've seen with social media, the impact AI can have on our mental health?

+ +

SARA: You know, there's a lot of different points here, but I think I'll just go with the first thing that comes to my mind is the limits. There are not many limits, let alone...so, tech in itself, but just in our own natural human world, as individuals, we have to learn what boundaries are. We have to learn self-imposed limitations or else someone else is going to impose them on us, and that just doesn't feel as good when someone puts their own limitations on our reality.

+ +

So, when we bring this into tech,...and I also include...since my background is in addictions, I started realizing that correlation between, like, technology, the boom of access to information is really...it's a pleasure concept, is that when we have a thought and we can just go get information about the answer and it's immediate, that immediate gratification teaches the brain like, oh, I can do this. I can handle this myself. We're not looking at the by-product of that anymore. And I think because we're dealing with it, we can't really...we're so in it now. We can't see that like, oh, this could potentially be a problem, because it is.

+ +

We have become an immediate access world. I mean, even in rural...like, kids in Africa have a TikTok dancing. And they don't have running water in their communities, but they have a cell phone where they can get support. Like, I'm glad they can because that's great access. But they're not necessarily realizing the addictive aspect of what just being interconnected this way has on the brain, let alone the foundational understanding of what boundaries, and self-discipline, or just mental discipline would look like.

+ +

So, then when you bring this, I think, into the, you know, the AI world, we're already on a shaky ground of abuse of information and having too much information and not knowing how to process it. And I think that's probably been...I know an issue, for me, is that when I have too much information, I can't necessarily ask questions very well because I'm like, what is the question? Like, I know my brain is oversaturated, essentially, with information as well as potentially chemicals at this point because I'm just working so fast, so fast, so fast.

+ +

And I'm in my mid-thirties at this point. So, a teenager who's already dealing with impulse control issues because they're naturally developing, that gets really complicated very quickly. And that's what, in turn, we call attention deficit disorder, anxiety, autism spectrum. That's a little bit more complicated, but a lot of that intersects to be like, well, what are we dealing with? We're dealing with immediate gratification and a sensory processing issue because we're looking at screens, and our brains don't know how to adapt to that let alone regulate that.

+ +

SAMI: That makes so much sense. I guess it's because it's kind of a world that we all inhabit, right? As much as we talk about this and sometimes we like to think of the other like we're talking about someone else, I've found this in my own life as well. I'm addicted to my phone in ways, and I'm also seeking that immediate gratification. And it's almost, like you said, that dopamine hit, right? If there's a piece of information I want or there's a video that I want to see, it's there, and it's immediate.

+ +

And when you say these things, I guess it's kind of...it's a bit scary. And then, I wonder, on a more macro level, why, as a society, do we do this to ourselves? I don't expect anyone on this podcast [chuckles] to have the answer, right? But I'm always interested, like, if we're aware of this and we're cognizant of what's going on, and, Rémy, feel free to jump in on this as well, like, as a society, why are we doing this to ourselves?

+ +

SARA: Now, by no means is this...like, this is just my answer, and I don't have the answer for everything. But I've had...sometimes as a therapist, you have to fill space and come up with an answer. So, my hypothesis is that it's natural human behavior. I think our brains...we are, you know, survival of the fittest. That's natural. Like, at the end of the day, we're going to fight for our life. And life really comes down, in my perspective, it comes down to, like, we have suffering, and we have pleasure.

+ +

However, we've learned now that as an evolving, you know, species, that we are one of the only species that can build executive functioning skills in our brains and have different parts of that that we have to kind of understand the baseline. Survival has gotten us so far, and we've made a lot of great headway with that. But pleasure is not sustainable. Pleasure is a beautiful concept to have in life. But when we talk about what's the goal of life, we want to be happy. Happy and pleasure are actually two very different things to the brain. And a lot of it is just a matter of space being used.

+ +

Pleasure and dopamine is actually a very small part of the brain, whereas happiness expands and is able to circulate chemicals, and synapses, and energy throughout the rest of the brain but that it has to be a conscious choice. And I think a lot of people don't realize, yeah, you're making choices. I'm not saying, like, no one doesn't have, you know, some degree of free will, but if you're dealing with any degree of stress, emotions, cognitive bias in general, you're not making an actual, like, expansive choice about what options you have to expand your consciousness and your brain capacity.

+ +

RÉMY: I like the way that today we realized that a lot of things related to this is chemicals that we all have, which remove a little bit the guilt when you are addicted, you know, because it can happen to anyone. But also, it's a reminder that it can happen to anyone. So, nobody is immune to that because that's how we're built. And I really like this approach. It's just natural, which means it's okay to feel it. But it's also dangerous to anyone, so anyone should address it. And, again, if you feel like you're losing it and losing to addiction, it feels good to just know that everybody is entitled to, unfortunately, to feel that at some point in their life.

+ +

SARA: I love that you mentioned that, and that's absolutely one of my goals is to break down the stigma of...when I use the word addiction...and I don't do small talk that well because I'm just like, let's talk about some real things here. This is what's going on. And it's scary to think of, like, addiction and what that means because of how we've seen it. And I don't know what it looks like particularly in the countries that you're from...a little bit. But I know, here in America, it's messy. It's hurtful. It's a lot of suffering.

+ +

It doesn't make us feel good to even think about that, which is why I try to teach my clients how to manage and regulate that because it does not discriminate. It's your brain. It's doing its natural thing and how you have to train and just learn how to train that. And it can get better, for sure. But yeah, I really try to break through, like, it's not something that we need to keep being scared about because that is actually what gives it its power. It gives that restrictiveness and that isolation and breaks that connection from each other. And that's ultimately what brings us out of an active addictive cycle is connection.

+ +

SAMI: Yeah, it's really interesting because technology it almost masks that by making you feel really connected. Like, I'm connected to all these people and all these things, but I don't feel that connection. And that really resonates with me when you talk about the difference between pleasure and happiness.

+ +

So, I hope my parents don't listen to this. But when I was in university, I'm pretty sure I had a gaming addiction. So, I used to live in the loft in my house. I don't know what you'd call it in America. Maybe it's called the attic. I was at the top floor. So, essentially, I had...oh, back then, it would have been a PS3, and I was seriously addicted to Call of Duty, playing online.

+ +

And I remember doing just all-nighters, like, really often. I remember it got to a point where I would almost have to reset my whole sleep cycle because I ended up in a situation where I'd be awake in the night kind of always playing all night because I couldn't put the game down, and then sleeping during the day. And to get myself back into a normal rhythm, I'd have to force myself to stay awake for 24 hours. And I would even consider myself someone who doesn't have an addictive personality.

+ +

But when you were saying about the difference between pleasure and happiness, like, it was definitely hitting that dopamine, and it was pleasurable, but I didn't feel happy. Like, once I stopped, then there was all those feelings that Rémy described, which is, oh no, what have I done? I've wasted so much time and all that guilt that comes with it. So, it's really interesting.

+ +

And I guess it's also a bit like a codependency, which is something I've seen that you've touched on in your work as well, which I understand to be an unhealthy reliance on a human relationship. But I'm guessing we're probably seeing more of that and unhealthy reliance on tech software products and AI. Is that something you're seeing in your therapeutic work as well?

+ +

SARA: Oh, absolutely. Codependency it's a big topic to unpack. And I'll say it's a balance. We're never going to not be codependent on something because it literally...we're supposed to work together. We need each other to survive and to grow. But the unhealthy parts of it is, I think, because...I'll just speak from my own experience. I was never taught what emotional intelligence was when I was a kid. I grew up in a very middle-class, non-diverse part of the United States, where I didn't understand the foundational, like, what are boundaries? What are emotions? They try to teach you.

+ +

And I think that's been something that is going to take people a while to understand. But there is an unhealthy part of it because it's just mixed with...and confuse people of what do we actually need to need other people for. And it naturally sends us...I think this is primarily where relationships become a point of the discussion is relationships are necessary. But they're less successful if you don't have a relationship with yourself as a foundation because that's naturally going to help you realize that you don't need this one person. And you don't attach to a person out of necessity and out of survival or else, yeah, you're going to lose a huge aspect of your identity because you didn't have much of one to begin with.

+ +

And so, that's ultimately what I teach and educate people on when I work with them in session is just what codependency really is. We're going to be codependent on something. I'd rather you be aware of it. Denial is just dangerous in general. But being aware of how these things show up, you have a better of a choice now. And free will comes back to really in your control without less consequence over time or less negative consequence over time. [inaudible 20:44] my brother, though, Rémy. Call of Duty...[inaudible 20:48] the attic, it was the basement, but yeah. It doesn't discriminate against gender, but for men...he's also in the military. So, it was a very good outlet for him before he went, you know, active duty or [inaudible 21:02] and just self-expression. You don't have to talk about things.

+ +

I don't think this discriminates against country by any means, but I know for America, I try to stay in my lane with just speaking about Americans, is that men have been put in a very tough position when it comes to mental health because society reinforces: keep it together; be the provider; just deal with it, and painted this picture of, like, you don't have and can't express emotions. And then, we wonder why guns are an issue. We wonder why drinking and alcoholism is an issue and, you know, in the male population.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

SAMI: So, there's a lot of concerns. There's a lot of worries, and there's, I guess, negativity around tech and AI. Is there any silver lining? You know, some things we're getting from tech as we already know it, perhaps social media but also AI. Is there anything that we can look at and be like, actually, that will enhance our mental health, improve our society? Are there any positive things that you see coming from it?

+ +

SARA: I love that question because it is a heavy conversation. I tell people, if you're considering therapy, like, you got to consider it's a full-time job to intentionally lean into the heaviness of the reality that we live in. There's a lot going on right now. I kind of surprise myself every day as to why I do have some degree of hope. But I think that's also just because I see people recover every day. I am grateful for that because not everyone gets that experience.

+ +

If you're working more of a tech job and you're looking more at coding, and data, and screens all day, you don't see change from the human perspective. And if anything, if you go outside these days, it's just tense. We're extremely inflamed. I don't care what country you live in. We're all experiencing the sensory, like, I see it as...I was not good at chemistry, but one's like, when you heat up molecules and they move really fast, like, that's combustion. And it's about to be summer, so it's about to even be literally hotter. I'm not going to say it's going to get worse.

+ +

But I say that to say I do believe there is a degree of hope because not only do I see it, but I also see...I'm connected to communities who are doing work from what I kind of...is stealth and, like, covert. You're not really going to see goodness and kindness in the abundance of negativity and darkness, but it is there. And I also like to say that I educate people every day where it changes...maybe not everyone's going to change in that regard. But as an individual in a network and a system, if one person's changed, the system automatically changes.

+ +

And little by little, over time, I think the pendulum will swing back in a place where it's like, oh yeah, no, it really is happening. And I also kind of see it in this mental health crisis. Change comes out of crisis. It's unfortunate, but if we don't have a big enough reason to look at something, then we tend not to fix it, you know, be proactive. I mean, one of my goals is to get from this reactive place into a proactive and preemptive, you know, wellness space for people, but that also does have to be choice.

+ +

But I think it really has to start with people understanding and committing to themselves and taking care of themselves, which is why I also am hopeful is because that's a lot easier than trying to get other people to change for you. If you can commit and commit to yourself, and taking care of yourself, and prioritizing you being self-focused, not necessarily selfish because a lot of that gets a bad rap of like, oh, I'm being selfish. We do it a lot out of defense, which is why I think it's not that effective.

+ +

And so, like, oh, I'm just going to be selfish. I'm going to do what's best for me. You're also locking...you're doing that out of reaction typically because you're not realizing like, oh, I feel hurt because this person didn't prioritize me, so now I'm not going to prioritize them. I'm going to prioritize me. And what I mean intention and recovery comes down to like, when people hurt you, you still have to choose not to hurt them and not pull away. And so, I think if we can all understand...and it's a tough concept to stay in your lane. It really is. But if we can all try to stay in our lane and focus on taking care of ourselves, that is what I believe is going to make the most impact.

+ +

SAMI: And do you feel AI could help with that? Could we use AI? I'm interested how, like, specifically with regards to the tech, could that be part of this?

+ +

SARA: Absolutely. I think there's some foundational knowledge that needs to be done and work that needs to be done in each individual before AI can just kind of come in without creating, like, more intense dependency on it. But I know there are agencies here locally. I can't remember the name of...I was trying to remember this earlier. I met them at a networking event recently, but an agency who uses AI to help with social anxiety and role-playing when it comes to situational circumstances and exposure.

+ +

So, me as a therapist, I love doing exposure. I, for the most part, am an exposure exercise for some people is, you know, we open up and talk about, like, these things that people don't feel safe to talk about with their general networks. But AI, I've started kind of dabbling in, you know, I have some clients who deal with, you know, some, like, delusional disorders, schizoaffective disorder, where they didn't grow up in families where any of the, like, really important foundational concepts were discussed, or they were shut down. So, they're naturally trained to just stay in their head. And, in turn, you build a distrust with all the thoughts you have in your brain.

+ +

And I encourage my clients to have conversations with ChatGPT just to be like, "Hey, what's up? What's going on?" And telling it what it is that they need, to just normalize the communication of being like, okay, I'm a little nervous to go on a date. I don't know what to say. Can you help me with some ideas of what questions to ask to get to know someone? That, I think, is a lot less intimidating sometimes talking with me because my energy is easily transferable. And that can scare some people because I can get quite excited about, like, "Yo, you did that. That's great." And they're like, "Whoa, that's a lot."

+ +

SAMI: I'm loving your vibes.

+ +

SARA: Oh [laughs].

+ +

SAMI: It's good energy. I'm enjoying it.

+ +

SARA: Well, thank you. But I have a couple of clients that...talk about an investment, and I've told them this, and I was like, "I am going to pour into you." Because they just never had certain experiences at the right time to build a degree of confidence that would get them to the next place in life, where they realized like, oh, I can do that. Failure is not that bad, and it's different for everyone. But I do think AI can help in that regard.

+ +

It also can become a little bit challenging. I had a discussion on this with a colleague of mine who works in cybersecurity, and we were talking about AI and the intersection in relationships and the impact on intimacy in relationships, mostly with heterosexual relationships. But there, yeah, it can go a very different direction than hopeful. And it can cause harm or conflict in some relationships because it's easier to talk to a very structured computer bot than it is to a woman per se. But I think it can help as well to build a foundation for people to get to those points where you can be assertive and reflective in your experiences, build emotional intelligence over time to help relationships.

+ +

RÉMY: At thoughtbot, we have worked on projects that implement AI, and we are becoming more familiar with training models. One thing that concerns us is doing this in an ethical and safe way. What tips would you have for people who are actually creating models and driving change in this space?

+ +

SARA: I'd say the first thing that comes to my mind, though, and this is kind of going to go into my talk during the conference, how do you know you're connected with your own reality? I think that's the hardest part about the tech world is like, it's the boundary. Your brain does not know the difference between a computer screen and your reality. The biggest difference is your senses. And that's kind of been the...it's what's caused a lot of the problem with tech is that, you know, here we're having this conversation. I can see y'all. I can generally take into account what your environment is like, but I can't experience it the same way as if I was not sitting in the room with you.

+ +

And I think that is when you teach people how to activate their own realities, you know, teach them about their body and the somatic work, especially with trauma. When trauma is involved, is you have to know how to activate the here and now and train your brain to know what your reality is or else you're going to get lost in the sauce of, like, everyone else's reality, let alone opinions, but especially in the virtual world.

+ +

So, being able to know your sensory activation, how mindfulness is, that's a huge term, honestly. We could unpack that for 30 minutes itself. But that sensory activation is a huge part of mindfulness is being able to experience a thought that can trigger something of a reaction and being able to effectively detach from it without judgment, you know, it's training. It takes a lot of training, but senses are huge, and being able to, I think, ethically venture into that world of, you know, using the virtual space, using AI to train and be effective.

+ +

SAMI: Yeah, I want to pick up on something you said before because it kind of scared me [laughs], which I don't mind [laughs] saying that to you, right? Because I've got this fear that probably other people have also considered as well is people say about AI taking jobs. So, as a coder, we know AI is becoming more proficient at coding. Maybe other designers, other people in the tech world have this fear as well so much so I actually mentioned this in a previous podcast.

+ +

I taught myself some, like, real physical skills because I thought when AI takes my job completely, well, at least I'll be able to do something. I actually taught myself to silicone a bathroom. And if you know, you have those silicone beads that kind of go around a bathroom, so the water doesn't get in between the grating and the tiles. So, I remember when I was learning it, thinking, well, if AI does take our jobs, at least I'll be able to do this. But that's where my brain goes sometimes.

+ +

And then, when you were mentioning about using it in a therapeutic setting, like, oh, well, it can actually be helpful to chat to an AI bot about certain scenarios that you might be trying to work through in therapy. So, I guess the question is twofold. Number one, do you see AI having a big impact in a therapeutic setting and coming in and almost disrupting that industry? And also, what tips do you have for the majority of people who are now concerned that what is life going to look like, and what is it going to be? And will we all have jobs?

+ +

SARA: I think what's important is to understand what happens to the individual when fear is at play before we can even get to the bigger question of like, will AI take our jobs? But I'll start from the end. There will be some jobs that are taken by AI. But what you're talking about Rémy is, yes, there is a huge power to know how you can connect with your own life and AI. Even if you have a job that is in tech and can be overrun by AI, you still have value as a human being. However, you're not going to feel that way, one, if you have a lot of fear because we have to understand why you can't connect with that.

+ +

But because value is an invariant, to value something, you have to be quite intentional with training your brain to understand value, and you can do that if you know what fear does to your brain, and it's...quite simply, we've all heard it. It's the stress response: fight, flight, freeze, or fawn. So, when you're having a perceived threat, it doesn't mean...external is not the only threat. We threaten ourselves all the time with our own thought process based off of the experiences that we've had and trigger our own fear.

+ +

And your brain essentially is like, hold up, no, we're not going any further. There's a risk here. We're going to stop you. So, this is where a lot of people, like, have those moments. I could stare at a wall for, like, 10 minutes, but it's actually, like, almost two hours if I'm stressed out to the point...because I'm processing too much information, but it's also triggering a stress response for my brain. And we just get saturated and stuck in that moment. So, being able to know, okay, this is happening, then we can actually come back online.

+ +

So, I use the brain as a computer metaphor quite often. And when we know that we're in that fight or flight response mode, we can in turn engage so that...I actually have an acronym for fear that I'm going to be debuting at this conference. I'll just go ahead and debut it for y'all, a little sneak peek since you guys may or may not be able to be there. So, that fear is...we usually as an acronym, if you've ever heard this, is F everything and run.

+ +

And I'm going to define it as the F would be the fight response, fight, flight, freeze, and fawn. So, if you know that's going on, you can address it. The E would be engage. So, engage with your present moment, and that's where your body is, the one thing that tends to be in that present moment. And then, the A is accept. A lot of times we have to accept that we're maybe stuck. We may be at a problem. We may need to take a break. Accepting the things that we can't change in that moment is going to make a big difference on how we come back online on our brains and be able to understand, like, AI is a threat, but it's not going to take over everything, right? And then, the R is redirect. So, redirect to something that is going to change your perception of what the original trigger was.

+ +

And so, I think if people can understand how they work and how the brain is actually self-protecting, it's very, like, it's like, whoa, we're not going to let you do something completely destructive. But it cannot distinguish the severity of the threat, let alone can it not...actually, there's a lot of people who've trained their brain to not experience fear. Fear is what is supposed to keep us safe. So, it is just perceiving like, hey, AI could take our jobs, but it's also not giving you the context that you brought up, Rémy, about it's not going to take everything from us. It's actually supposed to be here to help us in [inaudible 36:23]. And it's also dependent on us.

+ +

So, if we're creating fear in the AI, then yeah, it's going to learn that, and it, could, I don't know, I can't tell the future in that regard. But we have plenty of things that don't have to be tech-related that AI won't take from us. And a lot of that is the natural world if we can keep it alive and value it enough.

+ +

RÉMY: I have one question for you. It might not be very in sync with the train of thought we're having because it's more related to the beginning of the episode. But you mentioned sometimes rebuilding confidence with people and building confidence and building the ability to trust yourself and to make your own good decisions. It feels like, to some extent, it can be rebuilding yourself. How do you deal with such a big action, such a big project? I mean, it's something that could take life to do so.

+ +

SARA: That's a great question. And sometimes it will take people's lives. I don't handle the whole rest of their life. I tell people like, "I'm going to give you some foundational things." And I do a lot of training. I'm very direct, which is why I have that therapeutic life consultant of like, I'm going to take my vast amount of experience, things that people are probably not going to experience and help them build a security in themselves and, over time, prepare them for when they deviate from that.

+ +

I tell people, like, especially if you have loved ones still living, depression is never going to just leave. The concept...there's no cure. It's being able to be prepared for when things happen in life versus feel completely unprepared. I just came out of a season of grief of, you know, I walked away from a relationship, as well as then trying to still maintain my business, still trying to maintain my clients and those relationships, let alone the relationship with myself, and then put my cat down, you know, like, you know, he was a child. I had him for 14 years. So, like, life is going to continuously happen. So, I'm not trying to figure it all out, but I'm trying to get people back to a point where they can understand how to find security for themselves.

+ +

Since mental health has been such a taboo topic for a long time, there is quite a bit of backlog, and that's what we're seeing. I don't know what it looks like in y'alls countries, but here in America, there is this rush of people. I need a therapist. I need to go to therapy. And we're at a shortage. Therapists can't necessarily help all, like, at once. And we also have to maintain our own mental health, or we're not going to be very helpful to people.

+ +

But really, it comes down to how you build that security with yourself and know and not anticipate, but be prepared for when there's something else that happens that disturbs your own peace. Because if you have an understanding of what peace looks like for you, and you can't necessarily control it, but you can influence it, and facilitate it in your life, then you have a stronger foundation to be able to endure, you know, potential loss of a loved one, hopefully, no time soon for anyone here, or out, or listening, but it's just the reality.

+ +

And that's part of, you know, my story of, I experienced a lot of loss from a young age, and it worked against me for a long time because I had no idea how to process and regulate energy and emotion in my body. And so, what it looked like was me holding on to repressing anger, not having a relationship with the natural emotions that we can't get rid of. You can't get rid of emotions. I wish I could just, you know, vomit them out and just be done with it and be like, okay, cool. We can all be stable. That's just not...that's not going to happen. I think that also is what makes us, you know, a great species and building, you know, great things in this world is emotion.

+ +

Tech was built off of passion and emotion. Did it cause some disarray and probably hurt some people in the process? Yeah. But I think we can reduce that from happening if people understand emotional intelligence and not just work, work, work, work, work. It's a new age coming to that. And I've, hopefully, been working on myself enough to be able to sustain helping people understand and shifting over to that new type of perspective of we can't do things the way that we've been doing them. We just can't. It's not sustainable. The human species will suffer from it and the earth will as well.

+ +

SAMI: Yeah, thank you so much, and just for bringing that level of transparency and honesty. It resonates with myself, and I'm sure it will help so many other people who are listening. We could talk to you for hours. I mean, there is so much. And some things we just did not have time to get into. But thank you so much for the time that you've given us. And it's been really insightful to look at AI and tech that we work with as consultants at thoughtbot on a daily basis from this perspective and look at it from this angle. If people want to get a hold of you, where would be the best place?

+ +

SARA: Finding my website is a big thing. That's just, you know, kind of the portal. So, that's sarawilderlcsw.com. Sara with an out an H. And then, also, venturing into this tech world, I have an app interface now that I have put together to kind of be a centerpiece for mental health resources, not only just, like, hotlines. That information is on my website as well.

+ +

But if you want to start doing your own work little by little, you know, having a centralized spot as well as not too much information. There's plenty of stuff you can Google about mental health. But this is vetted by me and organized to a point where they can, you know, one worksheet can make a difference, where you're just reflecting and taking, you know, 10-15 minutes to read through it and see how you can apply it in your life. It's called Power in Perspective.

+ +

SAMI: That's great. Definitely, I recommend go and check it out and check out Sara on her website. And if you can get down to that conference, that is, again, North Carolina called CreativeVerse, and you'll have the opportunity to hear Sara in person as well as Fatima from thoughtbot who's also presenting.

+ +

If you learned nothing else from today, then just remember: fear has an acronym for F everything and run. I guess that's my big takeaway. You also got a chance to hear about my gaming addiction. No one tell my parents.

+ +

And you can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. I always leave you the same challenge, and that challenge is to subscribe. We've got some great guests lined up, and you'll hear about it first if you subscribe. And feel free to leave any comments on Spotify or Apple Podcasts. We do check them all, and they're really helpful.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech. Thanks for listening. See ya.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+EDg1ugTb + + ]]> + + + + 535: AI in Healthcare: How CareTrainer.ai is Changing Elder Care + https://podcast.thoughtbot.com/535 + 6a94f4e8-7d4b-4c4c-ad5d-61f6934136c1 + Thu, 25 Jul 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Will Larry and Chad Pytel interview Brock Dubbels, Principal UX and AI Researcher at CareTrainer.ai, who explains how the company leverages AI to address the care crisis in elderly populations by automating routine tasks. This approach allows caregivers to focus on building meaningful relationships and providing personalized care, ultimately enhancing the quality of care and reducing burnout. Brock also discusses CareTrainer.ai’s apprenticeship model, which uses AI assistance to accelerate caregiver training and improve job satisfaction and retention. + 48:19 + no + + + Hosts Will Larry and Chad Pytel interview Brock Dubbels, Principal UX and AI Researcher at CareTrainer.ai. Brock discusses how CareTrainer.ai leverages AI to address the current care crisis in elderly populations. He highlights the growing demographic of individuals over 70 and the significant shortage of caregivers, exacerbated by COVID-19. CareTrainer.ai aims to alleviate this by automating routine tasks, allowing caregivers to focus on building meaningful relationships and providing personalized, compassionate care. The platform utilizes AI to manage tasks such as documentation, communication, and monitoring, which helps caregivers spend more time engaging with patients, ultimately enhancing the quality of care and reducing caregiver burnout. +Brock elaborates on the specific tasks that CareTrainer.ai automates, using an example from his own experience. He explains how AI can transform transactional interactions into conversational ones, fostering trust and authenticity between caregivers and patients. By automating repetitive tasks, caregivers are freed to engage more deeply with patients, encouraging them to participate in their own care. This not only improves patient outcomes but also increases job satisfaction and retention among caregivers. Brock mentions the alarming attrition rates in caregiving jobs and how CareTrainer.ai’s approach can help mitigate this by creating more rewarding and relational caregiving roles. +Additionally, Brock discusses the apprenticeship model CareTrainer.ai employs to train caregivers. This model allows new caregivers to learn on the job with AI assistance, accelerating their training and integrating them more quickly into the workforce. He emphasizes the importance of designing AI tools that are user-friendly and enhance the caregiving experience rather than replace human interaction, and by focusing on customer obsession and continuously iterating based on feedback, CareTrainer.ai aims to create AI solutions that are not only effective but also enrich the entire caregiving profession. +CareTrainer.ai (https://www.caretrainer.ai/) +Follow CareTrainer.ai on LinkedIn (https://www.linkedin.com/company/caretraining-ai/). +Follow Brock Dubbels on LinkedIn (https://www.linkedin.com/in/brockdubbels/). Visit his website: brockdubbels.com (https://brockdubbels.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +CHAD: And I'm your other host, Chad Pytel. And with us today is Brock Dubbels, Principal UX and AI Researcher at CareTrainer.ai, which is transforming health care and caregiving with a human-first approach to artificial intelligence. Brock, thank you for joining us. +BROCK: Hey, thanks for having me, guys. I'm excited to talk about this. +CHAD: Brock, let's get started with just diving into what CareTrainer.ai actually does. You know, so many businesses today are getting started with or incorporating artificial intelligence into their product offerings. And I know that it's been something that you've been working on for a long time. So, what is CareTrainer? +BROCK: Well, CareTrainer is an opportunity in the midst of a crisis. So, right now, we have what's called a care crisis for the elderly populations. If you were to look at the age of the North American population and look at it over the next 10 years, about 65% of our population will be over the age of 70. And right now, we are understaffed in caregiving by almost 20%. Caregivers, especially after COVID, are leaving at about a 40% clip. And enrollment in these care programs is down 9%, but yet that older population is growing. +And in the midst of this, we've just recently had an executive order called the Older Americans Act, which states that we actually have to reduce the ratio of caregivers to patients, and we need to give more humane interaction to the patients in these facilities, in homes and help them to retain their dignity. Many of them lose their identity to diagnosis, and they're often referred to as the tasks associated with them. +And what CareTrainer attempts to do is take many of the tasks out of the hands of the caregivers so that they can focus on what they're good at, which is building relationships, learning and understanding, acting with curiosity and compassion, and demonstrating expert knowledge in the service to caring for patients, either in homes, facilities or even post-acute care. +WILL: You mentioned your hope is to take some of the tasks away from the caregivers. Can you go a little bit deeper into that? What tasks are you referring to? +BROCK: Let's think about an example. My mom was a public health nurse, and she worked in child maternal health. And these were oftentimes reluctant counseling sessions between she and a young mother or a potential mother. And if she were sitting there with a clipboard or behind a computer screen and looking at the screen, or the clipboard, and doing the interview with questions, she would probably not get a very good interview because she's not making a relationship. It's not conversational; it's transactional. +And when we have these transactional relationships, oftentimes, we're not building trust. We're not expressing authenticity. We're not building relationships. It's not conversational. And we don't get to know the person, and they don't trust us. So, when we have these transactional relationships, we don't actually build the loyalty or the motivation. And when we can free people of the tasks associated with the people that they care for by automating those tasks, we can free them up to build relationships, to build trust, and, in many cases, become more playful, expose their own vulnerability, their own past, their own history, and, hopefully, help these patients feel a little bit more of their worth. +Many of these people worked meaningful lives as school teachers, working at the fire department, working at the hardware store. And they had a lot of friends, and they did a lot for their community. And now they're in a place where maybe there's somebody taking care of them that doesn't know anything about them, and they just become a person in a chair that, you know, needs to be fed at noon. And I think that's very sad. +So, what we help to do is generate the conversations people like to have, learn the stories. But more importantly, we do what's called restorative care, which is, when we have a patient who becomes much more invested in their own self-care, the caregiver can actually be more autonomous. So, let's say it's an elderly person, and, in the past, they wouldn't dress themselves. But because they've been able to build trust in a relationship, they're actually putting on their own blouse and slacks now. For example, a certified nursing assistant or a home health aide can actually make the bed while they're up dressing because the home health aide or certified nursing assistant is not dressing them or is not putting the toothpaste on the toothbrush. +So, what we're doing is we're saying, "Let's get you involved in helping with restorative care." And this also increases retention amongst the caregivers. One of the things that I learned in doing an ethnography of a five-state regional healthcare system was that these caregivers there was an attrition rate of about 45% of these workers within the first 30 days of work. So, it's a huge expense for the facility, that attrition rate. +One of the reasons why they said they were leaving is because they felt like they weren't building any relationships with the people that they were caring for, and it was more like a task than it was a care or a relationship. And, in fact, in many cases, they described it as maid service with bedpans for grumpy people [chuckles]. And many of them said, "I know there's somebody nice down there, but I think that they've just become a little bit hesitant to engage because of the huge number of people that come through this job, and the lack of continuity, the lack of relationship, the lack of understanding that comes from building a relationship and getting to know each other." +And when we're talking about taking the tasks away, we're helping with communication. We're actually helping with diagnosis and charting. We're helping with keeping the care plan updated and having more data for the care plan so that nurse practitioners and MDs can have a much more robust set of data to make decisions upon when they meet with this patient. And this actually reduces the cost for the care facilities because there's less catastrophic care in the form of emergency rooms, prescriptions, assisted care, as well as they actually retain their help. The caregivers stay there because it's a good quality of life. +And when those other costs go down, some of the institutions that I work for actually put that money back into more patient care, hiring more people to have more meaningful, humane interactions. And that's what I mean about taking the tasks off of the caregiver so that they can have the conversations and the relational interactions, rather than the transactional interactions. +CHAD: One thing I've heard from past guests and clients that we've had in this space, too, is, to speak more to the problem, the lack of staff and the decline in the quality of care and feeling like it's very impersonal causes families to take on that burden or family members to take on that burden, but they're not necessarily equipped to do it. And it sort of causes this downward spiral of stress and quality of care that impacts much bigger than just the individual person who needs the care. It often impacts entire families. +BROCK: Oh yeah. Currently, they're estimating that family, friends, and communities are providing between $90 and $260,000 worth of care per person per year. And this is leading to, you know, major financial investments that many of these people don't have. It leads to negative health outcomes. So, in a lot of ways, what I just described is providing caregiver respite, and that is providing time for a caregiver to actually engage with a person that they're caring for, teaching them communication skills. +And one of the big things here is many of these institutions and families are having a hard time finding caregivers. Part of that is because we're using old systems of education in new days that require new approaches to the problem. And the key thing that CareTrainer does is it provides a guided apprenticeship, which means that you can earn while you learn. And what I mean by that is, rather than sitting in a chair in front of a screen doing computer-based training off of a modified PowerPoint with multiple-choice tests, you can actually be in the context of care and earning while you learn rather than learning to earn. +CHAD: Well, at thoughtbot, we're a big believer in apprenticeships as a really solid way of learning quickly from an experienced mentor in a structured way. I was excited to hear about the apprenticeship model that you have. +BROCK: Well, it's really exciting, isn't it? I mean, when you begin looking at what AI can do as...let's call it a copilot. I thought some of the numbers that Ethan Mollick at Wharton Business School shared on his blog and his study with Boston Consulting Group, which is that an AI copilot can actually raise the quality of work, raise the floor to 82%, what he calls mediocrity. 82% was a pretty good grade for a lot of kids in my classes back when I was a Montessori teacher. +But, in this case, what it does is it raises the floor to care by guiding through apprenticeship, and it allows people to learn through observation and trial and error. And people who are already at that 82nd percentile, according to Mollick's numbers, increase their productivity by 40%. The thing that we're not clear on is if certain people have a greater natural proficiency or proclivity for using these care pilots or if it's a learned behavior. +CHAD: So, the impact that CareTrainer can have is huge. The surface area of the problem and the size of the industry is huge. But often, from a product perspective, what we're trying to do is get to market, figure out the smallest addressable, minimum viable product. Was that a challenge for you to figure out, okay, what's the first thing that we do, and how do we bring that to market and without getting overwhelmed with all the potential possibilities that you have? +BROCK: Yeah, of course. I start out with what I call a GRITS model. I start out with, what are my goals? Then R, let's review the market. How is this problem being addressed now? I, what are my ideas for addressing these goals, and what's currently being done? And T, what tasks need to be completed in order to test these ideas? And what steps will I take to test them and iterate as far as a roadmap? +And what that allowed me to do is to begin saying, okay, let's take the ideas that I can bring together first that are going to have the first initial impact because we're bootstrapping. And what we need to be able to do is get into a room with somebody who realizes that training caregivers and nursing is something that needs a review, maybe some fresh ideas. And getting that in front of them, understanding that that's our MVP 1 was really important. And what was really interesting is our MVP 2 through 5, we've begun to see that the technology is just exponential, the growth and progress. +Our MVP 2 we thought we're going to be doing a heck of a lot of stuff with multimedia reinforcement learning. But now we're finding that some of the AI giants have actually done the work for us. So, I have just been very happy that we started out simple. And we looked at what is our core problem, which is, you know, what's the best way to train people? And how do we do that with the least amount of effort and the most amount of impact? And the key to it is customer obsession. And this is something I learned at Amazon as their first principle. +And many of the experiences that I brought from places like Amazon and other big tech is, how do I understand the needs of the customer? What problems do they have, and what would make this a more playful experience? And, in this case, I wanted to design for curiosity. And the thing that I like to say about that is AI chose its symbol of the spark really smartly. And I think the spark is what people want in life. And the spark is exploring, and it's finding something. And you see this kind of spark of life, this learning, and you discover it. You create more from it. You share it. It's enlightening. It's inspirational. It makes people excited. It's something that they want to share. It's inventing. It's creation. +I think that's what we wanted to have people experience in our learning, rather than my own experience in computer-based training, which was sitting in front of a flashified PowerPoint with multiple choice questions and having the text read to me. And, you know, spending 40 hours doing that was kind of soul-killing. And what I really wanted to do was be engaged and start learning through experience. And that's what came down to our MVP 1 is, how do we begin to change the way that training occurs? How can we change the student experience and still provide for the institutional needs to get people on the floor and caring for people? And that was our first priority. +And that's how we began to make hard decisions about how we were going to develop from MVP 1, 2, 3, 4, and 5 because we had all the big ideas immediately. And part of that is because I had created a package like this back in 2004 for a five-state regional care provider in the Midwest. Back then, I was designing what could only be called a finite game. I'm designing in Flash for web. I'm doing decision trees with dialogue, and it's much like a video game, but a serious game. It's getting the assessment correct in the interactions and embedding the learning in the interaction and then being able to judge that and provide useful feedback for the player. +And what this did was it made it possible for them to have interactive learning through doing in the form of a video game, which was a little bit more fun than studying a textbook or taking a computer-based test. It also allowed the health system a little bit more focus on the patients because what was happening is that they would be taking their best people off the floor and taking a partial schedule to train these new people. But 45% of those that they were training were leaving within the first 30 days. So, the game was actually an approach to providing that interaction as a guided apprenticeship without taking their best people off the floor into part-time schedules and the idea that they might not even be there in 30 days. +So, that's kind of a lot to describe, but I would say that the focus on the MVP 1 was, this is the problem that we're going to help you with. We're going to get people out of the seats and onto the floor, off the screen, caring for people. And we're going to guide them through this guided apprenticeship, which allows for contextual computing and interaction, as we've worked with comparing across, like, OpenAI, Anthropic, Google, Mistral, Grok, trying these different approaches to AI, figuring out which models work best within this context. And, hopefully, when we walk in and we're sitting with an exec, we get a "Wow," [laughs]. And that's the big thing with our initial technology. We really want a wow. +I shared this with a former instructor at the University of Minnesota, Joe Gaugler, and I said...I showed him, and he's like, "Wow, why isn't anybody doing this with nursing and such?" And I said, "Well, we are," you know, that's what I was hoping he would say. And that's the thing that we want to see when we walk into somebody's office, and we show them, and they say, "Wow, this is cool." "Wow, we think it's cool. And we hope you're going to want to go on this journey with us." And that's what MVP 1 should do for us is solve what seems like a little problem, which is a finite game-type technology, but turn it into an infinite game technology, which is what's possible with AI and machine learning. +WILL: I love, you know, you're talking about your background, being a teacher, and in gaming, and I can see that in your product, which is awesome. Because training can be boring, especially if it's just reading or any of those things. But when you make it real life, when you put someone, I guess that's where the quote comes from, you put them in the game, it's so much better. So, for you, with your teacher background and your gaming background, was there a personal experience that you had that brought out your passion for caregiving? +BROCK: You know, my mom is a nurse. She has always been into personal development. By the time I was in sixth grade, I was going to CPR classes with her while she was [inaudible 19:22] her nursing thing [laughs]. So, I was invited to propose a solution for the first version of CareTrainer, which had a different name back in 2004, which we sold. That led to an invitation to work and support the virtual clinic for the University of Minnesota Medical School, which is no longer a thing. The virtual clinic that is the medical school is still one of the best in the country, a virtual stethoscope writing grants as an academic for elder care. +And I would have to say my personal story is that at the end of their lives, I took care of both my maternal grandmother in her home while I was going to college. And then, I took care of my paternal grandfather while I was going to college. And, you know, those experiences were profound for me because I was able to sit down and have coffee with them, tell jokes, learn about their lives. I saw the stories that went with the pictures. +And I think one of the greatest fears that I saw in many of the potential customers that I've spoken to is at the end of a loved one's life that they didn't learn some of the things that they had hoped from them. And they didn't have the stories that went with all the pictures in the box, and that's just an opportunity missed. +So, I think those are some of the things that drive me. It's just that connection to people. And I think that's what makes us humane is that compassion, that wanting to understand, and, also, I think a desire to have compassion and to be understood. And I think that's where gaming and play are really important because making mistakes is part of play. And you can make lots of mistakes and have lots of ways to solve a problem in a game. Whereas in computer-based training and standardized tests, which I used to address as a teacher, there's typically one right answer, and, in life, there is rarely a right answer [laughs]. +CHAD: Well, and not really an opportunity to learn from mistakes either. Like, you don't necessarily get an opportunity on a standardized test to review the answers you got wrong in any meaningful way and try to learn from that experience. +BROCK: Have you ever taken one of those tests and you're like, well, that's kind of right, but I think my answer is better, but it's not here [laughter]? I think what we really want from schools is creativity and innovation. And when we're showing kids that there's just a right answer, we kind of take the steam out of their engine, which is, you know, well, what if I just explore this and make mistakes? +And I remember, in high school, I had an art teacher who said, "Explore your mistakes." Maybe you'll find out that their best is intentional. Maybe it's a feature, not a bug [laughs]. I think when I say inculcate play or inspire play, there's a feeling of psychological safety that we can be vulnerable, that we can explore, we can discover; we can create, and we can share. +And when people say, "Oh, well, that's stupid," and you can say, "Well, I was just playing. I'm just exploring. I discovered this. I kind of messed around with a little bit, and I wanted to show you." And, hopefully, the person backs off a little bit from their strong statement and says, "Oh, I can see this and that." And, hopefully, that's the start of a conversation and maybe a startup, right [laughs]? +CHAD: Well, there are so many opportunities in so many different industries to have an impact by introducing play. Because, in some ways, I feel like that may have been lost a little bit in so many sort of like addressing problems at scale or when scaling up to particular challenges. I think we trend towards standardization and lose a little bit of that. +BROCK: I agree. I think humans do like continuity and predictability. But what we find in product is that when we can pleasantly surprise, we're going to build a customer base, you know, that doesn't come from, you know, doing the same thing all the time that everybody else does. That's kind of the table stakes, right? It works. But somebody is going to come along that does it in a more interesting way. And people are going to say, "Oh." +It's like the arts and crafts effect in industrialization, right? Everybody needs a spoon to eat soup, a lot of soup [laughs]. And somebody can make a lot of spoons. And somebody else says, "Well, I can make spoons, too." "And how do I differentiate?" "Well, I've put a nice scrollwork design on my spoon. And it's beautiful, versus this other very plain spoon. I'll sell it to you for a penny more." And most people will take the designed thing, the well-designed thing that provides some beauty and some pleasure in their life. And I think that's part of what I described as the spark is that realization that we live in beauty, that we live in this kind of amazing place that inspires wonder when we're open to it. +MID-ROLL AD: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +WILL: You mentioned gamifying the training and how users are more involved. It's interesting because I'm actually going through this with my five-year-old. We're trying to put him in kindergarten, and he loves to play. And so, if you put him around a game, he'll learn it. He loves it. But most of the schools are like, workbooks, sit down; focus, all of those things. +And it probably speaks to your background as being a Montessori teacher, but how did you come up with gamifying it for the trainee, I guess you could say? Like, how did you come up with that plan? Because I feel like in the school systems, a lot of that is missing because it's like, like you said, worksheets equal that boring PowerPoint that we have to sit down and read and stuff like that. So, how did you come up with the gamifying it when society is saying, "Worksheets, PowerPoints. Do it this way." +BROCK: I think that is something I call the adult convenience model. Who's it better for: the person who has to do the grading and the curriculum design, or the kid doing the learning? And I think that, in those cases, the kid doing the learning misses out. And the way that we validate that behavior is by saying, "Well, you've got to learn how to conform. You've got to learn how to put your own interests and drives aside and just learn how to focus on this because I'm telling you to do it." And I think that's important, to be able to do what you're asked to do in a way that you're asked to do it. But I think that the instructional model that I'm talking about takes much more up-front thought. +And where I came from with it is studying the way that I like to learn. I struggled in school. I really did. I was a high school dropout. I went to junior college in Cupertino, and I was very surprised to find out that I could actually go to college, even though I hadn't finished high school. And I began to understand that it's very different when you get to college, so much more of it is about giving you an unstructured problem that you have to address. And this is the criteria under which you're going to solve the problem and how I'm going to grade you. And these are the qualities of the criteria, and what this is, is basically a rubric. +We actually see these rubrics and such in products. So, for example, when I was at American Family, we had this matrix of different insurance policies and all the different things in the column based upon rows that you would get underneath either economy, standard, or performance. And I think it was said by somebody at Netflix years ago; there's only two ways to sell bundled and unbundled. The idea is that there were these qualities that changed as a gradient or a ratio as you moved across this matrix. And the price went up a little bit for each one of those qualities that you added into the next row or column, and that's basically a rubric. +And when we begin to create a rubric for learning, what we're really doing is moving into a moment where we say, "This is the criteria under which I'm going to assess you. These are the qualities that inform the numbers that you're going to be graded with or the letter A, B, or C, or 4, 3, 2, 1. What does it mean to have a 4? Well, let me give you some qualities." And one of the things that I do in training companies and training teams is Clapping Academy. You want to do that together? +WILL: Yeah, I would love to. +BROCK: Would you like to try it here? Okay. Which one of you would like to be the judge? +WILL: I'll do it. +BROCK: Okay. As the judge, you're going to tell me thumbs up or thumbs down. I'm going to clap for you. Ready? [Claps] Thumbs up or thumbs down? +CHAD: [laughs] +WILL: I say thumbs up. It was a clap [laughs]. +BROCK: Okay. Is it what you were expecting? +WILL: No, it wasn't. +BROCK: Ah. What are some of the qualities of clapping that we could probably tease out of what you were expecting? Like, could volume or dynamics be one? +WILL: Yeah, definitely. And then, like, I guess, rhythm of it like music, like a music rhythm of it. +BROCK: Okay. In some cases, you know, like at jazz and some churches, people actually snap. They don't clap. So, hands or fingers or style. So, if we were to take these three categories and we were to break them 4, 3, 2, 1 for each one, would a 4 be high volume, or would it be middle volume for you? +WILL: Oh, wow. For that, high volume. +BROCK: Okay. How about rhythm? Would it be 4 would be really fast; 1 would be really slow? I think slow would be...we have this cultural term called slow clapping, right [laughter]? So, maybe that would be bad, right [laughter]? A 1 [laughter]? And then, style maybe this could be a non-numerical category, where it could just be a 1 or a 2, and maybe hands or slapping a thigh or snapping knuckles. What do you think? +WILL: I'm going off of what I know. I guess a clap is technically described as with hands. So, I'll go with that. +BROCK: Okay, so a 4 would be a clap. A 3 might be a thigh slap [laughter]. A 2 might be a snap, and a 1 would be air clap [laughter]. +WILL: Yep. +BROCK: Okay. So, you can't see this right now. But let's see, if I were to ask you what constitutes a 12 out of 12 possible, we would have loud, fast, hand-to-hand clap. I think we could all do it together, right [Clapping]? And that is how it works. What I've just done is I've created criteria. I've created gradients or qualities. And then, we've talked about what those qualities mean, and then you have an idea of what it might look like into the future. You have previewed it. +And there's a difference here in video games. A simulation is where I copy you step by step, and I demonstrate, in performance, what's been shown to me to be accurate to what's been shown to me. Most humans don't learn like that. Most of us learn through emulation, which is we see that there's an outcome that we want to achieve, and we see how it starts. But we have to improvise between the start and the end. In a book by Michael Tomasello on being human...he's an anthropologist, and he studies humans, and he studied other primates like great apes. And he talks about emulation as like the mother using a blade of grass, licking it, and putting it down a hole to collect ants so that she can eat the ants. +And oftentimes, the mother may have their back to her babies. And the babies will see the grass, and they'll see that she's putting it in her mouth, but they won't see the whole act. So, they've just [inaudible 33:29] through trial and error, see if they can do it. And this is the way an earlier paper that I wrote in studying kids playing video games was. We start with trial and error. We find a tactic that works for us. And then, in a real situation, there might be multiple tactics that we can use, and that becomes a strategy. And then, we might choose different strategies for different economic benefits. +So, for example, do I want to pay for something with pennies or a dollar, or do I want a hundred pennies to carry around? Or would I rather have a dollar in a game, right? We have to make this decision of, what is the value of it, and what is the encumbrance of it? Or if it's a shooting game, am I going to take out a road sign with a bazooka when I might need that bazooka later on? And that becomes economic decision-making. +And then, eventually, we might have what's called top site, which is, I understand that the game has these different rules, opportunities, roles, and experiences. How do I want to play? For example, Fallout 4 was a game that I really enjoyed. And I was blown away when I found out that a player had actually gone through the Final Boss and never injured another non-player character in the game. They had just done the whole thing in stealth. And I thought that is an artistic way to play. It's an expression. It's creative. It's an intentional way of moving through the game. +And I think that when we provide that type of independent, individual expression of learning, we're allowing people to have a unique identity, to express it creatively, and to connect in ways that are interesting to other people so that we can learn from each other. And I think that's what games can do. +And one of the hurdles that I faced back in 2004 was I was creating a finite game, where what I had coded in decision trees, in dialogue, in video interactions, once that was there, that was done. Where we're at now is, I can create an infinite game because I've learned how to leverage machine learning in order to generate lots of different contexts using the type of criteria and qualities that I described to you in Clapping Academy, that allow me to evaluate many different variations of a situation, but with the same level of expectation for professionalism, knowledge and expertise, communication, compassion, curiosity. You know, these are part of the eight elements of what is valued in the nursing profession. +And when we have those rubrics, when we have that matrix, we begin to move into a new paradigm in teaching and learning because there's a much greater latitude and variety of how we get up the mountain. And that's one of the things that I learned as a teacher is that every kid comes in differently, but they're just as good. And every kid has a set of gifts that we can have them, you know, celebrate in service to warming up cold spots. +And I think that sometimes kids are put into situations, and so are adults, where they're told to overcome this cold spot without actually leveraging the things that they're good at. And the problem with that is, in learning sciences, it's a transfer problem, which is if I learn it to pass the test, am I ever going to apply it in life, or is it just going to be something that I forget right away? And my follow-ups on doing classroom and learning research is that it is usually that. They learned it for the test. They forgot it, and they don't even remember ever having learned it. +And the greatest gift that I got, having been a teacher, was when my wife and I would, I don't know, we'd be somewhere like the grocery store or walking out of a Target, and a couple of young people would come up and say, "Yo, Mr. Dubbs," And I'd be like, "Hey [laughs]!" And they're like, "Hey, man, you remember when we did that video game class and all that?" And I was like, "Yeah, you were so good at that." Or "Remember when we made those boats, and we raced them across the pool?" "Yeah, yeah, that was a lot of fun, wasn't it?" And I think part of it was that I was having as much fun doing the classes and the lessons as they were doing it. +And it's kind of like a stealth learning, where they are getting the experience to populate these abstract concepts, which are usually tested on these standardized choice tests. And it's the same problem that we have with scaling a technology. Oftentimes, the way that we scale is based on conformity and limited variation when we're really scaling the wrong things. And I think it's good to be able to scale a lot of the tasks but provide great variety in the way that we can be human-supported around them. +So, sure, let's scale sales and operations, but let's also make sure that we can scope out variation in how we do sales, and how we do customer service, and how we do present our product experience. So, how do we begin to personalize in scope and still be able to scale? And I think that's what I'm getting at as far as how I'm approaching CareTrainer, and how I'm approaching a lot of the knowledge translation that we're doing for startups, and consulting with larger and medium-sized businesses on how they can use AI. +CHAD: That's awesome. Bringing it back to CareTrainer, what are some of the hurdles or cold spots that are in front of you and the business? What are the next steps and challenges in front of you? +BROCK: I think the big thing is that I spend a good two to three [laughs] hours a day reading about the advances in the tech, you know, staying ahead of the knowledge translation and the possible applications. I mean, it's hard to actually find time to do the work because the technology is moving so fast. And, like I said, we were starting to build MVP 2, and we realized, you know what, this is going to be done for us in a little while. You know, it'd be cool if we can do this bespoke. But why not buy the thing that's already there rather than creating it from scratch, unless we're going to do something really different? +I think that the biggest hurdle is helping people to think differently. And with the elder care crisis and the care crisis, I think that we really have to help people think differently about the things that we've done. I think regulation is really important, especially when it comes to health care, treatment, prescription safety. I think, though, that there are a lot of ways that we can help people to understand those regulations rather than put them in a seat in front of a monitor. +CHAD: I think people respond to, you know, when there's a crisis, different people respond in different ways. And it's a natural tendency to not want to rock the boat, not introduce new things because that's scary. And adding more, you know, something that is scary to a difficult situation already is hard for some people. Whereas other people react to a crisis realizing that we got into the crisis for a reason. And the old ways of doing things might not necessarily be the thing to get us out of it. +BROCK: Yeah, I totally agree. When I run into that, the first thought that comes to my head is, when did you stop learning [laughs]? When did you stop seeking learning? Because, for me, if I were to ever stop learning, I'd realize that I'd started dying. And that's what I mean by the spark, is, no matter what your age, as long as you're engaged in seeking out learning opportunities, life is exciting. It's an adventure. You're discovering new frontiers, and, you know, that's the spark. I think when people become complacent, and they say, "Well, this is the way we've always done it," okay, has that always served us well? +And there are a lot of cultural issues that go with this. So, for example, there are cultural expectations about the way kids learn in class. Like, kids who come from blue-collar families might say, "Hey, you know what? My kid is going to be doing drywall, or he's going to be working fixing cars, or he's going to be in construction, or why does he need to do this? Or why does she need to do that? And, as a parent, I don't even understand the homework." And then, there are the middle-class folks who say, "You know what? I'm given these things. They need to be correct, accurate, and easy to read. And that's my job. And I don't see this in my kids' curriculum." +And then, there are the creatives who say, "Hey, you know, this has nothing to do with where my kid is going. My kids are creative. They're going to have ambiguous problems that they have to come up with creative solutions for." Then you get to the executive class where, like, these elite private schools, where they say, "My kid is going to be a leader in the industry, and what they should be doing is leading groups of people through an activity in order to accomplish a goal." +And those are four different pedagogical approaches to learning. +So, I'm wondering, what is it that we expect from our caregivers? And I've got kind of a crazy story from that, where this young woman, [SP] Gemma, who was a middle school student, I gave her the option, along with my other kids, to either take a standardized test on Greek myths, or they could write their own myth. And she wrote this myth about a mortal who fell in love with a young goddess. Whenever they would wrap and embrace and kiss, a flame would occur. +One day the mother found out and says, "Oh, you've fallen in love with a mortal. Well, here you shall stay. This shall be your penance." And she wrapped her in this thread, this rope, and dipped them in wax so they would be there forever. But then the flame jumped to the top, and that is how candles were created. +And I read that, and I was...and this is, like, you know, 30 years ago, and I still have this at the top of my head. And I was like, "Gemma, that was amazing. Are you going to go to college?" And she says, "No." "No? Really? What are you going to do?" "I want to be a hairstylist." And, in my mind, my teacher mind is like, oh no, no, no, no. You [laughs] need to go to college. But then I thought about it. I thought, why wouldn't I want a smart, skilled, creative person cutting my hair? And, you know, people who cut hair make really good money [laughter]. +And the whole idea is, are we actually, you know, empowering people to become their best selves and be able to explore those things? Or are we, you know, scaring them out of their futures with, you know, fear? Those are the big hurdles, which is, I'm afraid of the future. And the promise is, well, it's going to be different. But I can't assure you that it's not going to come without problems that we're going to have to figure out how to solve. And there are some who don't want the problems. They just want how it's always been. +And I think that's the biggest hurdle we face is innovation and convincing people that trying something new it may not be perfect, but it's a step in the right direction. And I think Hans Rosling in Factfulness said it very well. He said, "Things are better than they were before, but they're not great." Can we go from good to great? Sure. And what do we need to do? But we always are getting better, as long as we're continuing to adapt and create and be playful and look at different ways of doing things because now people are different, but just as good. +CHAD: Brock, I really appreciate you stopping by and bringing your creativity, and energy, and playfulness to this difficult problem of caregiving. I'm excited for what the future holds for not only CareTrainer but the impact that you're going to have on the world. I really appreciate it. +BROCK: Well, thank you for having me and letting me tell these stories, and, also, thanks for participating in Clapping Academy [laughter]. +WILL: It was great. +CHAD: If folks want to get in touch with you or follow along with you, or if they work in a healthcare organization where they think CareTrainer might be right for them, where are all the places that they can do that? +BROCK: You can reach me at brock@caretrainer.ai. They can express interest on our website at caretrainer.ai. They can reach me at my personal website, brockdubbels.com, or connect with me on LinkedIn, because, you know, life is too short not to have friends. So, let's be friends [laughs]. +CHAD: You can subscribe to the show and find notes for this entire episode along with a complete transcript at giantrobots.fm. +WILL: If you have questions or comments, email us at hosts@giantrobots.fm. +CHAD: You can find me on Mastodon at cpytel@thoughtbot.social. +WILL: And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +CHAD: Thank you again, Brock. And thank you all for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + + Hosts Will Larry and Chad Pytel interview Brock Dubbels, Principal UX and AI Researcher at CareTrainer.ai. Brock discusses how CareTrainer.ai leverages AI to address the current care crisis in elderly populations. He highlights the growing demographic of individuals over 70 and the significant shortage of caregivers, exacerbated by COVID-19. CareTrainer.ai aims to alleviate this by automating routine tasks, allowing caregivers to focus on building meaningful relationships and providing personalized, compassionate care. The platform utilizes AI to manage tasks such as documentation, communication, and monitoring, which helps caregivers spend more time engaging with patients, ultimately enhancing the quality of care and reducing caregiver burnout.

+ +

Brock elaborates on the specific tasks that CareTrainer.ai automates, using an example from his own experience. He explains how AI can transform transactional interactions into conversational ones, fostering trust and authenticity between caregivers and patients. By automating repetitive tasks, caregivers are freed to engage more deeply with patients, encouraging them to participate in their own care. This not only improves patient outcomes but also increases job satisfaction and retention among caregivers. Brock mentions the alarming attrition rates in caregiving jobs and how CareTrainer.ai’s approach can help mitigate this by creating more rewarding and relational caregiving roles.

+ +

Additionally, Brock discusses the apprenticeship model CareTrainer.ai employs to train caregivers. This model allows new caregivers to learn on the job with AI assistance, accelerating their training and integrating them more quickly into the workforce. He emphasizes the importance of designing AI tools that are user-friendly and enhance the caregiving experience rather than replace human interaction, and by focusing on customer obsession and continuously iterating based on feedback, CareTrainer.ai aims to create AI solutions that are not only effective but also enrich the entire caregiving profession.

+ + + +

Transcript:

+ +

WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

CHAD: And I'm your other host, Chad Pytel. And with us today is Brock Dubbels, Principal UX and AI Researcher at CareTrainer.ai, which is transforming health care and caregiving with a human-first approach to artificial intelligence. Brock, thank you for joining us.

+ +

BROCK: Hey, thanks for having me, guys. I'm excited to talk about this.

+ +

CHAD: Brock, let's get started with just diving into what CareTrainer.ai actually does. You know, so many businesses today are getting started with or incorporating artificial intelligence into their product offerings. And I know that it's been something that you've been working on for a long time. So, what is CareTrainer?

+ +

BROCK: Well, CareTrainer is an opportunity in the midst of a crisis. So, right now, we have what's called a care crisis for the elderly populations. If you were to look at the age of the North American population and look at it over the next 10 years, about 65% of our population will be over the age of 70. And right now, we are understaffed in caregiving by almost 20%. Caregivers, especially after COVID, are leaving at about a 40% clip. And enrollment in these care programs is down 9%, but yet that older population is growing.

+ +

And in the midst of this, we've just recently had an executive order called the Older Americans Act, which states that we actually have to reduce the ratio of caregivers to patients, and we need to give more humane interaction to the patients in these facilities, in homes and help them to retain their dignity. Many of them lose their identity to diagnosis, and they're often referred to as the tasks associated with them.

+ +

And what CareTrainer attempts to do is take many of the tasks out of the hands of the caregivers so that they can focus on what they're good at, which is building relationships, learning and understanding, acting with curiosity and compassion, and demonstrating expert knowledge in the service to caring for patients, either in homes, facilities or even post-acute care.

+ +

WILL: You mentioned your hope is to take some of the tasks away from the caregivers. Can you go a little bit deeper into that? What tasks are you referring to?

+ +

BROCK: Let's think about an example. My mom was a public health nurse, and she worked in child maternal health. And these were oftentimes reluctant counseling sessions between she and a young mother or a potential mother. And if she were sitting there with a clipboard or behind a computer screen and looking at the screen, or the clipboard, and doing the interview with questions, she would probably not get a very good interview because she's not making a relationship. It's not conversational; it's transactional.

+ +

And when we have these transactional relationships, oftentimes, we're not building trust. We're not expressing authenticity. We're not building relationships. It's not conversational. And we don't get to know the person, and they don't trust us. So, when we have these transactional relationships, we don't actually build the loyalty or the motivation. And when we can free people of the tasks associated with the people that they care for by automating those tasks, we can free them up to build relationships, to build trust, and, in many cases, become more playful, expose their own vulnerability, their own past, their own history, and, hopefully, help these patients feel a little bit more of their worth.

+ +

Many of these people worked meaningful lives as school teachers, working at the fire department, working at the hardware store. And they had a lot of friends, and they did a lot for their community. And now they're in a place where maybe there's somebody taking care of them that doesn't know anything about them, and they just become a person in a chair that, you know, needs to be fed at noon. And I think that's very sad.

+ +

So, what we help to do is generate the conversations people like to have, learn the stories. But more importantly, we do what's called restorative care, which is, when we have a patient who becomes much more invested in their own self-care, the caregiver can actually be more autonomous. So, let's say it's an elderly person, and, in the past, they wouldn't dress themselves. But because they've been able to build trust in a relationship, they're actually putting on their own blouse and slacks now. For example, a certified nursing assistant or a home health aide can actually make the bed while they're up dressing because the home health aide or certified nursing assistant is not dressing them or is not putting the toothpaste on the toothbrush.

+ +

So, what we're doing is we're saying, "Let's get you involved in helping with restorative care." And this also increases retention amongst the caregivers. One of the things that I learned in doing an ethnography of a five-state regional healthcare system was that these caregivers there was an attrition rate of about 45% of these workers within the first 30 days of work. So, it's a huge expense for the facility, that attrition rate.

+ +

One of the reasons why they said they were leaving is because they felt like they weren't building any relationships with the people that they were caring for, and it was more like a task than it was a care or a relationship. And, in fact, in many cases, they described it as maid service with bedpans for grumpy people [chuckles]. And many of them said, "I know there's somebody nice down there, but I think that they've just become a little bit hesitant to engage because of the huge number of people that come through this job, and the lack of continuity, the lack of relationship, the lack of understanding that comes from building a relationship and getting to know each other."

+ +

And when we're talking about taking the tasks away, we're helping with communication. We're actually helping with diagnosis and charting. We're helping with keeping the care plan updated and having more data for the care plan so that nurse practitioners and MDs can have a much more robust set of data to make decisions upon when they meet with this patient. And this actually reduces the cost for the care facilities because there's less catastrophic care in the form of emergency rooms, prescriptions, assisted care, as well as they actually retain their help. The caregivers stay there because it's a good quality of life.

+ +

And when those other costs go down, some of the institutions that I work for actually put that money back into more patient care, hiring more people to have more meaningful, humane interactions. And that's what I mean about taking the tasks off of the caregiver so that they can have the conversations and the relational interactions, rather than the transactional interactions.

+ +

CHAD: One thing I've heard from past guests and clients that we've had in this space, too, is, to speak more to the problem, the lack of staff and the decline in the quality of care and feeling like it's very impersonal causes families to take on that burden or family members to take on that burden, but they're not necessarily equipped to do it. And it sort of causes this downward spiral of stress and quality of care that impacts much bigger than just the individual person who needs the care. It often impacts entire families.

+ +

BROCK: Oh yeah. Currently, they're estimating that family, friends, and communities are providing between $90 and $260,000 worth of care per person per year. And this is leading to, you know, major financial investments that many of these people don't have. It leads to negative health outcomes. So, in a lot of ways, what I just described is providing caregiver respite, and that is providing time for a caregiver to actually engage with a person that they're caring for, teaching them communication skills.

+ +

And one of the big things here is many of these institutions and families are having a hard time finding caregivers. Part of that is because we're using old systems of education in new days that require new approaches to the problem. And the key thing that CareTrainer does is it provides a guided apprenticeship, which means that you can earn while you learn. And what I mean by that is, rather than sitting in a chair in front of a screen doing computer-based training off of a modified PowerPoint with multiple-choice tests, you can actually be in the context of care and earning while you learn rather than learning to earn.

+ +

CHAD: Well, at thoughtbot, we're a big believer in apprenticeships as a really solid way of learning quickly from an experienced mentor in a structured way. I was excited to hear about the apprenticeship model that you have.

+ +

BROCK: Well, it's really exciting, isn't it? I mean, when you begin looking at what AI can do as...let's call it a copilot. I thought some of the numbers that Ethan Mollick at Wharton Business School shared on his blog and his study with Boston Consulting Group, which is that an AI copilot can actually raise the quality of work, raise the floor to 82%, what he calls mediocrity. 82% was a pretty good grade for a lot of kids in my classes back when I was a Montessori teacher.

+ +

But, in this case, what it does is it raises the floor to care by guiding through apprenticeship, and it allows people to learn through observation and trial and error. And people who are already at that 82nd percentile, according to Mollick's numbers, increase their productivity by 40%. The thing that we're not clear on is if certain people have a greater natural proficiency or proclivity for using these care pilots or if it's a learned behavior.

+ +

CHAD: So, the impact that CareTrainer can have is huge. The surface area of the problem and the size of the industry is huge. But often, from a product perspective, what we're trying to do is get to market, figure out the smallest addressable, minimum viable product. Was that a challenge for you to figure out, okay, what's the first thing that we do, and how do we bring that to market and without getting overwhelmed with all the potential possibilities that you have?

+ +

BROCK: Yeah, of course. I start out with what I call a GRITS model. I start out with, what are my goals? Then R, let's review the market. How is this problem being addressed now? I, what are my ideas for addressing these goals, and what's currently being done? And T, what tasks need to be completed in order to test these ideas? And what steps will I take to test them and iterate as far as a roadmap?

+ +

And what that allowed me to do is to begin saying, okay, let's take the ideas that I can bring together first that are going to have the first initial impact because we're bootstrapping. And what we need to be able to do is get into a room with somebody who realizes that training caregivers and nursing is something that needs a review, maybe some fresh ideas. And getting that in front of them, understanding that that's our MVP 1 was really important. And what was really interesting is our MVP 2 through 5, we've begun to see that the technology is just exponential, the growth and progress.

+ +

Our MVP 2 we thought we're going to be doing a heck of a lot of stuff with multimedia reinforcement learning. But now we're finding that some of the AI giants have actually done the work for us. So, I have just been very happy that we started out simple. And we looked at what is our core problem, which is, you know, what's the best way to train people? And how do we do that with the least amount of effort and the most amount of impact? And the key to it is customer obsession. And this is something I learned at Amazon as their first principle.

+ +

And many of the experiences that I brought from places like Amazon and other big tech is, how do I understand the needs of the customer? What problems do they have, and what would make this a more playful experience? And, in this case, I wanted to design for curiosity. And the thing that I like to say about that is AI chose its symbol of the spark really smartly. And I think the spark is what people want in life. And the spark is exploring, and it's finding something. And you see this kind of spark of life, this learning, and you discover it. You create more from it. You share it. It's enlightening. It's inspirational. It makes people excited. It's something that they want to share. It's inventing. It's creation.

+ +

I think that's what we wanted to have people experience in our learning, rather than my own experience in computer-based training, which was sitting in front of a flashified PowerPoint with multiple choice questions and having the text read to me. And, you know, spending 40 hours doing that was kind of soul-killing. And what I really wanted to do was be engaged and start learning through experience. And that's what came down to our MVP 1 is, how do we begin to change the way that training occurs? How can we change the student experience and still provide for the institutional needs to get people on the floor and caring for people? And that was our first priority.

+ +

And that's how we began to make hard decisions about how we were going to develop from MVP 1, 2, 3, 4, and 5 because we had all the big ideas immediately. And part of that is because I had created a package like this back in 2004 for a five-state regional care provider in the Midwest. Back then, I was designing what could only be called a finite game. I'm designing in Flash for web. I'm doing decision trees with dialogue, and it's much like a video game, but a serious game. It's getting the assessment correct in the interactions and embedding the learning in the interaction and then being able to judge that and provide useful feedback for the player.

+ +

And what this did was it made it possible for them to have interactive learning through doing in the form of a video game, which was a little bit more fun than studying a textbook or taking a computer-based test. It also allowed the health system a little bit more focus on the patients because what was happening is that they would be taking their best people off the floor and taking a partial schedule to train these new people. But 45% of those that they were training were leaving within the first 30 days. So, the game was actually an approach to providing that interaction as a guided apprenticeship without taking their best people off the floor into part-time schedules and the idea that they might not even be there in 30 days.

+ +

So, that's kind of a lot to describe, but I would say that the focus on the MVP 1 was, this is the problem that we're going to help you with. We're going to get people out of the seats and onto the floor, off the screen, caring for people. And we're going to guide them through this guided apprenticeship, which allows for contextual computing and interaction, as we've worked with comparing across, like, OpenAI, Anthropic, Google, Mistral, Grok, trying these different approaches to AI, figuring out which models work best within this context. And, hopefully, when we walk in and we're sitting with an exec, we get a "Wow," [laughs]. And that's the big thing with our initial technology. We really want a wow.

+ +

I shared this with a former instructor at the University of Minnesota, Joe Gaugler, and I said...I showed him, and he's like, "Wow, why isn't anybody doing this with nursing and such?" And I said, "Well, we are," you know, that's what I was hoping he would say. And that's the thing that we want to see when we walk into somebody's office, and we show them, and they say, "Wow, this is cool." "Wow, we think it's cool. And we hope you're going to want to go on this journey with us." And that's what MVP 1 should do for us is solve what seems like a little problem, which is a finite game-type technology, but turn it into an infinite game technology, which is what's possible with AI and machine learning.

+ +

WILL: I love, you know, you're talking about your background, being a teacher, and in gaming, and I can see that in your product, which is awesome. Because training can be boring, especially if it's just reading or any of those things. But when you make it real life, when you put someone, I guess that's where the quote comes from, you put them in the game, it's so much better. So, for you, with your teacher background and your gaming background, was there a personal experience that you had that brought out your passion for caregiving?

+ +

BROCK: You know, my mom is a nurse. She has always been into personal development. By the time I was in sixth grade, I was going to CPR classes with her while she was [inaudible 19:22] her nursing thing [laughs]. So, I was invited to propose a solution for the first version of CareTrainer, which had a different name back in 2004, which we sold. That led to an invitation to work and support the virtual clinic for the University of Minnesota Medical School, which is no longer a thing. The virtual clinic that is the medical school is still one of the best in the country, a virtual stethoscope writing grants as an academic for elder care.

+ +

And I would have to say my personal story is that at the end of their lives, I took care of both my maternal grandmother in her home while I was going to college. And then, I took care of my paternal grandfather while I was going to college. And, you know, those experiences were profound for me because I was able to sit down and have coffee with them, tell jokes, learn about their lives. I saw the stories that went with the pictures.

+ +

And I think one of the greatest fears that I saw in many of the potential customers that I've spoken to is at the end of a loved one's life that they didn't learn some of the things that they had hoped from them. And they didn't have the stories that went with all the pictures in the box, and that's just an opportunity missed.

+ +

So, I think those are some of the things that drive me. It's just that connection to people. And I think that's what makes us humane is that compassion, that wanting to understand, and, also, I think a desire to have compassion and to be understood. And I think that's where gaming and play are really important because making mistakes is part of play. And you can make lots of mistakes and have lots of ways to solve a problem in a game. Whereas in computer-based training and standardized tests, which I used to address as a teacher, there's typically one right answer, and, in life, there is rarely a right answer [laughs].

+ +

CHAD: Well, and not really an opportunity to learn from mistakes either. Like, you don't necessarily get an opportunity on a standardized test to review the answers you got wrong in any meaningful way and try to learn from that experience.

+ +

BROCK: Have you ever taken one of those tests and you're like, well, that's kind of right, but I think my answer is better, but it's not here [laughter]? I think what we really want from schools is creativity and innovation. And when we're showing kids that there's just a right answer, we kind of take the steam out of their engine, which is, you know, well, what if I just explore this and make mistakes?

+ +

And I remember, in high school, I had an art teacher who said, "Explore your mistakes." Maybe you'll find out that their best is intentional. Maybe it's a feature, not a bug [laughs]. I think when I say inculcate play or inspire play, there's a feeling of psychological safety that we can be vulnerable, that we can explore, we can discover; we can create, and we can share.

+ +

And when people say, "Oh, well, that's stupid," and you can say, "Well, I was just playing. I'm just exploring. I discovered this. I kind of messed around with a little bit, and I wanted to show you." And, hopefully, the person backs off a little bit from their strong statement and says, "Oh, I can see this and that." And, hopefully, that's the start of a conversation and maybe a startup, right [laughs]?

+ +

CHAD: Well, there are so many opportunities in so many different industries to have an impact by introducing play. Because, in some ways, I feel like that may have been lost a little bit in so many sort of like addressing problems at scale or when scaling up to particular challenges. I think we trend towards standardization and lose a little bit of that.

+ +

BROCK: I agree. I think humans do like continuity and predictability. But what we find in product is that when we can pleasantly surprise, we're going to build a customer base, you know, that doesn't come from, you know, doing the same thing all the time that everybody else does. That's kind of the table stakes, right? It works. But somebody is going to come along that does it in a more interesting way. And people are going to say, "Oh."

+ +

It's like the arts and crafts effect in industrialization, right? Everybody needs a spoon to eat soup, a lot of soup [laughs]. And somebody can make a lot of spoons. And somebody else says, "Well, I can make spoons, too." "And how do I differentiate?" "Well, I've put a nice scrollwork design on my spoon. And it's beautiful, versus this other very plain spoon. I'll sell it to you for a penny more." And most people will take the designed thing, the well-designed thing that provides some beauty and some pleasure in their life. And I think that's part of what I described as the spark is that realization that we live in beauty, that we live in this kind of amazing place that inspires wonder when we're open to it.

+ +

MID-ROLL AD:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

WILL: You mentioned gamifying the training and how users are more involved. It's interesting because I'm actually going through this with my five-year-old. We're trying to put him in kindergarten, and he loves to play. And so, if you put him around a game, he'll learn it. He loves it. But most of the schools are like, workbooks, sit down; focus, all of those things.

+ +

And it probably speaks to your background as being a Montessori teacher, but how did you come up with gamifying it for the trainee, I guess you could say? Like, how did you come up with that plan? Because I feel like in the school systems, a lot of that is missing because it's like, like you said, worksheets equal that boring PowerPoint that we have to sit down and read and stuff like that. So, how did you come up with the gamifying it when society is saying, "Worksheets, PowerPoints. Do it this way."

+ +

BROCK: I think that is something I call the adult convenience model. Who's it better for: the person who has to do the grading and the curriculum design, or the kid doing the learning? And I think that, in those cases, the kid doing the learning misses out. And the way that we validate that behavior is by saying, "Well, you've got to learn how to conform. You've got to learn how to put your own interests and drives aside and just learn how to focus on this because I'm telling you to do it." And I think that's important, to be able to do what you're asked to do in a way that you're asked to do it. But I think that the instructional model that I'm talking about takes much more up-front thought.

+ +

And where I came from with it is studying the way that I like to learn. I struggled in school. I really did. I was a high school dropout. I went to junior college in Cupertino, and I was very surprised to find out that I could actually go to college, even though I hadn't finished high school. And I began to understand that it's very different when you get to college, so much more of it is about giving you an unstructured problem that you have to address. And this is the criteria under which you're going to solve the problem and how I'm going to grade you. And these are the qualities of the criteria, and what this is, is basically a rubric.

+ +

We actually see these rubrics and such in products. So, for example, when I was at American Family, we had this matrix of different insurance policies and all the different things in the column based upon rows that you would get underneath either economy, standard, or performance. And I think it was said by somebody at Netflix years ago; there's only two ways to sell bundled and unbundled. The idea is that there were these qualities that changed as a gradient or a ratio as you moved across this matrix. And the price went up a little bit for each one of those qualities that you added into the next row or column, and that's basically a rubric.

+ +

And when we begin to create a rubric for learning, what we're really doing is moving into a moment where we say, "This is the criteria under which I'm going to assess you. These are the qualities that inform the numbers that you're going to be graded with or the letter A, B, or C, or 4, 3, 2, 1. What does it mean to have a 4? Well, let me give you some qualities." And one of the things that I do in training companies and training teams is Clapping Academy. You want to do that together?

+ +

WILL: Yeah, I would love to.

+ +

BROCK: Would you like to try it here? Okay. Which one of you would like to be the judge?

+ +

WILL: I'll do it.

+ +

BROCK: Okay. As the judge, you're going to tell me thumbs up or thumbs down. I'm going to clap for you. Ready? [Claps] Thumbs up or thumbs down?

+ +

CHAD: [laughs]

+ +

WILL: I say thumbs up. It was a clap [laughs].

+ +

BROCK: Okay. Is it what you were expecting?

+ +

WILL: No, it wasn't.

+ +

BROCK: Ah. What are some of the qualities of clapping that we could probably tease out of what you were expecting? Like, could volume or dynamics be one?

+ +

WILL: Yeah, definitely. And then, like, I guess, rhythm of it like music, like a music rhythm of it.

+ +

BROCK: Okay. In some cases, you know, like at jazz and some churches, people actually snap. They don't clap. So, hands or fingers or style. So, if we were to take these three categories and we were to break them 4, 3, 2, 1 for each one, would a 4 be high volume, or would it be middle volume for you?

+ +

WILL: Oh, wow. For that, high volume.

+ +

BROCK: Okay. How about rhythm? Would it be 4 would be really fast; 1 would be really slow? I think slow would be...we have this cultural term called slow clapping, right [laughter]? So, maybe that would be bad, right [laughter]? A 1 [laughter]? And then, style maybe this could be a non-numerical category, where it could just be a 1 or a 2, and maybe hands or slapping a thigh or snapping knuckles. What do you think?

+ +

WILL: I'm going off of what I know. I guess a clap is technically described as with hands. So, I'll go with that.

+ +

BROCK: Okay, so a 4 would be a clap. A 3 might be a thigh slap [laughter]. A 2 might be a snap, and a 1 would be air clap [laughter].

+ +

WILL: Yep.

+ +

BROCK: Okay. So, you can't see this right now. But let's see, if I were to ask you what constitutes a 12 out of 12 possible, we would have loud, fast, hand-to-hand clap. I think we could all do it together, right [Clapping]? And that is how it works. What I've just done is I've created criteria. I've created gradients or qualities. And then, we've talked about what those qualities mean, and then you have an idea of what it might look like into the future. You have previewed it.

+ +

And there's a difference here in video games. A simulation is where I copy you step by step, and I demonstrate, in performance, what's been shown to me to be accurate to what's been shown to me. Most humans don't learn like that. Most of us learn through emulation, which is we see that there's an outcome that we want to achieve, and we see how it starts. But we have to improvise between the start and the end. In a book by Michael Tomasello on being human...he's an anthropologist, and he studies humans, and he studied other primates like great apes. And he talks about emulation as like the mother using a blade of grass, licking it, and putting it down a hole to collect ants so that she can eat the ants.

+ +

And oftentimes, the mother may have their back to her babies. And the babies will see the grass, and they'll see that she's putting it in her mouth, but they won't see the whole act. So, they've just [inaudible 33:29] through trial and error, see if they can do it. And this is the way an earlier paper that I wrote in studying kids playing video games was. We start with trial and error. We find a tactic that works for us. And then, in a real situation, there might be multiple tactics that we can use, and that becomes a strategy. And then, we might choose different strategies for different economic benefits.

+ +

So, for example, do I want to pay for something with pennies or a dollar, or do I want a hundred pennies to carry around? Or would I rather have a dollar in a game, right? We have to make this decision of, what is the value of it, and what is the encumbrance of it? Or if it's a shooting game, am I going to take out a road sign with a bazooka when I might need that bazooka later on? And that becomes economic decision-making.

+ +

And then, eventually, we might have what's called top site, which is, I understand that the game has these different rules, opportunities, roles, and experiences. How do I want to play? For example, Fallout 4 was a game that I really enjoyed. And I was blown away when I found out that a player had actually gone through the Final Boss and never injured another non-player character in the game. They had just done the whole thing in stealth. And I thought that is an artistic way to play. It's an expression. It's creative. It's an intentional way of moving through the game.

+ +

And I think that when we provide that type of independent, individual expression of learning, we're allowing people to have a unique identity, to express it creatively, and to connect in ways that are interesting to other people so that we can learn from each other. And I think that's what games can do.

+ +

And one of the hurdles that I faced back in 2004 was I was creating a finite game, where what I had coded in decision trees, in dialogue, in video interactions, once that was there, that was done. Where we're at now is, I can create an infinite game because I've learned how to leverage machine learning in order to generate lots of different contexts using the type of criteria and qualities that I described to you in Clapping Academy, that allow me to evaluate many different variations of a situation, but with the same level of expectation for professionalism, knowledge and expertise, communication, compassion, curiosity. You know, these are part of the eight elements of what is valued in the nursing profession.

+ +

And when we have those rubrics, when we have that matrix, we begin to move into a new paradigm in teaching and learning because there's a much greater latitude and variety of how we get up the mountain. And that's one of the things that I learned as a teacher is that every kid comes in differently, but they're just as good. And every kid has a set of gifts that we can have them, you know, celebrate in service to warming up cold spots.

+ +

And I think that sometimes kids are put into situations, and so are adults, where they're told to overcome this cold spot without actually leveraging the things that they're good at. And the problem with that is, in learning sciences, it's a transfer problem, which is if I learn it to pass the test, am I ever going to apply it in life, or is it just going to be something that I forget right away? And my follow-ups on doing classroom and learning research is that it is usually that. They learned it for the test. They forgot it, and they don't even remember ever having learned it.

+ +

And the greatest gift that I got, having been a teacher, was when my wife and I would, I don't know, we'd be somewhere like the grocery store or walking out of a Target, and a couple of young people would come up and say, "Yo, Mr. Dubbs," And I'd be like, "Hey [laughs]!" And they're like, "Hey, man, you remember when we did that video game class and all that?" And I was like, "Yeah, you were so good at that." Or "Remember when we made those boats, and we raced them across the pool?" "Yeah, yeah, that was a lot of fun, wasn't it?" And I think part of it was that I was having as much fun doing the classes and the lessons as they were doing it.

+ +

And it's kind of like a stealth learning, where they are getting the experience to populate these abstract concepts, which are usually tested on these standardized choice tests. And it's the same problem that we have with scaling a technology. Oftentimes, the way that we scale is based on conformity and limited variation when we're really scaling the wrong things. And I think it's good to be able to scale a lot of the tasks but provide great variety in the way that we can be human-supported around them.

+ +

So, sure, let's scale sales and operations, but let's also make sure that we can scope out variation in how we do sales, and how we do customer service, and how we do present our product experience. So, how do we begin to personalize in scope and still be able to scale? And I think that's what I'm getting at as far as how I'm approaching CareTrainer, and how I'm approaching a lot of the knowledge translation that we're doing for startups, and consulting with larger and medium-sized businesses on how they can use AI.

+ +

CHAD: That's awesome. Bringing it back to CareTrainer, what are some of the hurdles or cold spots that are in front of you and the business? What are the next steps and challenges in front of you?

+ +

BROCK: I think the big thing is that I spend a good two to three [laughs] hours a day reading about the advances in the tech, you know, staying ahead of the knowledge translation and the possible applications. I mean, it's hard to actually find time to do the work because the technology is moving so fast. And, like I said, we were starting to build MVP 2, and we realized, you know what, this is going to be done for us in a little while. You know, it'd be cool if we can do this bespoke. But why not buy the thing that's already there rather than creating it from scratch, unless we're going to do something really different?

+ +

I think that the biggest hurdle is helping people to think differently. And with the elder care crisis and the care crisis, I think that we really have to help people think differently about the things that we've done. I think regulation is really important, especially when it comes to health care, treatment, prescription safety. I think, though, that there are a lot of ways that we can help people to understand those regulations rather than put them in a seat in front of a monitor.

+ +

CHAD: I think people respond to, you know, when there's a crisis, different people respond in different ways. And it's a natural tendency to not want to rock the boat, not introduce new things because that's scary. And adding more, you know, something that is scary to a difficult situation already is hard for some people. Whereas other people react to a crisis realizing that we got into the crisis for a reason. And the old ways of doing things might not necessarily be the thing to get us out of it.

+ +

BROCK: Yeah, I totally agree. When I run into that, the first thought that comes to my head is, when did you stop learning [laughs]? When did you stop seeking learning? Because, for me, if I were to ever stop learning, I'd realize that I'd started dying. And that's what I mean by the spark, is, no matter what your age, as long as you're engaged in seeking out learning opportunities, life is exciting. It's an adventure. You're discovering new frontiers, and, you know, that's the spark. I think when people become complacent, and they say, "Well, this is the way we've always done it," okay, has that always served us well?

+ +

And there are a lot of cultural issues that go with this. So, for example, there are cultural expectations about the way kids learn in class. Like, kids who come from blue-collar families might say, "Hey, you know what? My kid is going to be doing drywall, or he's going to be working fixing cars, or he's going to be in construction, or why does he need to do this? Or why does she need to do that? And, as a parent, I don't even understand the homework." And then, there are the middle-class folks who say, "You know what? I'm given these things. They need to be correct, accurate, and easy to read. And that's my job. And I don't see this in my kids' curriculum."

+ +

And then, there are the creatives who say, "Hey, you know, this has nothing to do with where my kid is going. My kids are creative. They're going to have ambiguous problems that they have to come up with creative solutions for." Then you get to the executive class where, like, these elite private schools, where they say, "My kid is going to be a leader in the industry, and what they should be doing is leading groups of people through an activity in order to accomplish a goal."

+ +

And those are four different pedagogical approaches to learning.

+ +

So, I'm wondering, what is it that we expect from our caregivers? And I've got kind of a crazy story from that, where this young woman, [SP] Gemma, who was a middle school student, I gave her the option, along with my other kids, to either take a standardized test on Greek myths, or they could write their own myth. And she wrote this myth about a mortal who fell in love with a young goddess. Whenever they would wrap and embrace and kiss, a flame would occur.

+ +

One day the mother found out and says, "Oh, you've fallen in love with a mortal. Well, here you shall stay. This shall be your penance." And she wrapped her in this thread, this rope, and dipped them in wax so they would be there forever. But then the flame jumped to the top, and that is how candles were created.

+ +

And I read that, and I was...and this is, like, you know, 30 years ago, and I still have this at the top of my head. And I was like, "Gemma, that was amazing. Are you going to go to college?" And she says, "No." "No? Really? What are you going to do?" "I want to be a hairstylist." And, in my mind, my teacher mind is like, oh no, no, no, no. You [laughs] need to go to college. But then I thought about it. I thought, why wouldn't I want a smart, skilled, creative person cutting my hair? And, you know, people who cut hair make really good money [laughter].

+ +

And the whole idea is, are we actually, you know, empowering people to become their best selves and be able to explore those things? Or are we, you know, scaring them out of their futures with, you know, fear? Those are the big hurdles, which is, I'm afraid of the future. And the promise is, well, it's going to be different. But I can't assure you that it's not going to come without problems that we're going to have to figure out how to solve. And there are some who don't want the problems. They just want how it's always been.

+ +

And I think that's the biggest hurdle we face is innovation and convincing people that trying something new it may not be perfect, but it's a step in the right direction. And I think Hans Rosling in Factfulness said it very well. He said, "Things are better than they were before, but they're not great." Can we go from good to great? Sure. And what do we need to do? But we always are getting better, as long as we're continuing to adapt and create and be playful and look at different ways of doing things because now people are different, but just as good.

+ +

CHAD: Brock, I really appreciate you stopping by and bringing your creativity, and energy, and playfulness to this difficult problem of caregiving. I'm excited for what the future holds for not only CareTrainer but the impact that you're going to have on the world. I really appreciate it.

+ +

BROCK: Well, thank you for having me and letting me tell these stories, and, also, thanks for participating in Clapping Academy [laughter].

+ +

WILL: It was great.

+ +

CHAD: If folks want to get in touch with you or follow along with you, or if they work in a healthcare organization where they think CareTrainer might be right for them, where are all the places that they can do that?

+ +

BROCK: You can reach me at brock@caretrainer.ai. They can express interest on our website at caretrainer.ai. They can reach me at my personal website, brockdubbels.com, or connect with me on LinkedIn, because, you know, life is too short not to have friends. So, let's be friends [laughs].

+ +

CHAD: You can subscribe to the show and find notes for this entire episode along with a complete transcript at giantrobots.fm.

+ +

WILL: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Mastodon at cpytel@thoughtbot.social.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thank you again, Brock. And thank you all for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Chad Pytel interview Brock Dubbels, Principal UX and AI Researcher at CareTrainer.ai. Brock discusses how CareTrainer.ai leverages AI to address the current care crisis in elderly populations. He highlights the growing demographic of individuals over 70 and the significant shortage of caregivers, exacerbated by COVID-19. CareTrainer.ai aims to alleviate this by automating routine tasks, allowing caregivers to focus on building meaningful relationships and providing personalized, compassionate care. The platform utilizes AI to manage tasks such as documentation, communication, and monitoring, which helps caregivers spend more time engaging with patients, ultimately enhancing the quality of care and reducing caregiver burnout.

+ +

Brock elaborates on the specific tasks that CareTrainer.ai automates, using an example from his own experience. He explains how AI can transform transactional interactions into conversational ones, fostering trust and authenticity between caregivers and patients. By automating repetitive tasks, caregivers are freed to engage more deeply with patients, encouraging them to participate in their own care. This not only improves patient outcomes but also increases job satisfaction and retention among caregivers. Brock mentions the alarming attrition rates in caregiving jobs and how CareTrainer.ai’s approach can help mitigate this by creating more rewarding and relational caregiving roles.

+ +

Additionally, Brock discusses the apprenticeship model CareTrainer.ai employs to train caregivers. This model allows new caregivers to learn on the job with AI assistance, accelerating their training and integrating them more quickly into the workforce. He emphasizes the importance of designing AI tools that are user-friendly and enhance the caregiving experience rather than replace human interaction, and by focusing on customer obsession and continuously iterating based on feedback, CareTrainer.ai aims to create AI solutions that are not only effective but also enrich the entire caregiving profession.

+ + + +

Transcript:

+ +

WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

CHAD: And I'm your other host, Chad Pytel. And with us today is Brock Dubbels, Principal UX and AI Researcher at CareTrainer.ai, which is transforming health care and caregiving with a human-first approach to artificial intelligence. Brock, thank you for joining us.

+ +

BROCK: Hey, thanks for having me, guys. I'm excited to talk about this.

+ +

CHAD: Brock, let's get started with just diving into what CareTrainer.ai actually does. You know, so many businesses today are getting started with or incorporating artificial intelligence into their product offerings. And I know that it's been something that you've been working on for a long time. So, what is CareTrainer?

+ +

BROCK: Well, CareTrainer is an opportunity in the midst of a crisis. So, right now, we have what's called a care crisis for the elderly populations. If you were to look at the age of the North American population and look at it over the next 10 years, about 65% of our population will be over the age of 70. And right now, we are understaffed in caregiving by almost 20%. Caregivers, especially after COVID, are leaving at about a 40% clip. And enrollment in these care programs is down 9%, but yet that older population is growing.

+ +

And in the midst of this, we've just recently had an executive order called the Older Americans Act, which states that we actually have to reduce the ratio of caregivers to patients, and we need to give more humane interaction to the patients in these facilities, in homes and help them to retain their dignity. Many of them lose their identity to diagnosis, and they're often referred to as the tasks associated with them.

+ +

And what CareTrainer attempts to do is take many of the tasks out of the hands of the caregivers so that they can focus on what they're good at, which is building relationships, learning and understanding, acting with curiosity and compassion, and demonstrating expert knowledge in the service to caring for patients, either in homes, facilities or even post-acute care.

+ +

WILL: You mentioned your hope is to take some of the tasks away from the caregivers. Can you go a little bit deeper into that? What tasks are you referring to?

+ +

BROCK: Let's think about an example. My mom was a public health nurse, and she worked in child maternal health. And these were oftentimes reluctant counseling sessions between she and a young mother or a potential mother. And if she were sitting there with a clipboard or behind a computer screen and looking at the screen, or the clipboard, and doing the interview with questions, she would probably not get a very good interview because she's not making a relationship. It's not conversational; it's transactional.

+ +

And when we have these transactional relationships, oftentimes, we're not building trust. We're not expressing authenticity. We're not building relationships. It's not conversational. And we don't get to know the person, and they don't trust us. So, when we have these transactional relationships, we don't actually build the loyalty or the motivation. And when we can free people of the tasks associated with the people that they care for by automating those tasks, we can free them up to build relationships, to build trust, and, in many cases, become more playful, expose their own vulnerability, their own past, their own history, and, hopefully, help these patients feel a little bit more of their worth.

+ +

Many of these people worked meaningful lives as school teachers, working at the fire department, working at the hardware store. And they had a lot of friends, and they did a lot for their community. And now they're in a place where maybe there's somebody taking care of them that doesn't know anything about them, and they just become a person in a chair that, you know, needs to be fed at noon. And I think that's very sad.

+ +

So, what we help to do is generate the conversations people like to have, learn the stories. But more importantly, we do what's called restorative care, which is, when we have a patient who becomes much more invested in their own self-care, the caregiver can actually be more autonomous. So, let's say it's an elderly person, and, in the past, they wouldn't dress themselves. But because they've been able to build trust in a relationship, they're actually putting on their own blouse and slacks now. For example, a certified nursing assistant or a home health aide can actually make the bed while they're up dressing because the home health aide or certified nursing assistant is not dressing them or is not putting the toothpaste on the toothbrush.

+ +

So, what we're doing is we're saying, "Let's get you involved in helping with restorative care." And this also increases retention amongst the caregivers. One of the things that I learned in doing an ethnography of a five-state regional healthcare system was that these caregivers there was an attrition rate of about 45% of these workers within the first 30 days of work. So, it's a huge expense for the facility, that attrition rate.

+ +

One of the reasons why they said they were leaving is because they felt like they weren't building any relationships with the people that they were caring for, and it was more like a task than it was a care or a relationship. And, in fact, in many cases, they described it as maid service with bedpans for grumpy people [chuckles]. And many of them said, "I know there's somebody nice down there, but I think that they've just become a little bit hesitant to engage because of the huge number of people that come through this job, and the lack of continuity, the lack of relationship, the lack of understanding that comes from building a relationship and getting to know each other."

+ +

And when we're talking about taking the tasks away, we're helping with communication. We're actually helping with diagnosis and charting. We're helping with keeping the care plan updated and having more data for the care plan so that nurse practitioners and MDs can have a much more robust set of data to make decisions upon when they meet with this patient. And this actually reduces the cost for the care facilities because there's less catastrophic care in the form of emergency rooms, prescriptions, assisted care, as well as they actually retain their help. The caregivers stay there because it's a good quality of life.

+ +

And when those other costs go down, some of the institutions that I work for actually put that money back into more patient care, hiring more people to have more meaningful, humane interactions. And that's what I mean about taking the tasks off of the caregiver so that they can have the conversations and the relational interactions, rather than the transactional interactions.

+ +

CHAD: One thing I've heard from past guests and clients that we've had in this space, too, is, to speak more to the problem, the lack of staff and the decline in the quality of care and feeling like it's very impersonal causes families to take on that burden or family members to take on that burden, but they're not necessarily equipped to do it. And it sort of causes this downward spiral of stress and quality of care that impacts much bigger than just the individual person who needs the care. It often impacts entire families.

+ +

BROCK: Oh yeah. Currently, they're estimating that family, friends, and communities are providing between $90 and $260,000 worth of care per person per year. And this is leading to, you know, major financial investments that many of these people don't have. It leads to negative health outcomes. So, in a lot of ways, what I just described is providing caregiver respite, and that is providing time for a caregiver to actually engage with a person that they're caring for, teaching them communication skills.

+ +

And one of the big things here is many of these institutions and families are having a hard time finding caregivers. Part of that is because we're using old systems of education in new days that require new approaches to the problem. And the key thing that CareTrainer does is it provides a guided apprenticeship, which means that you can earn while you learn. And what I mean by that is, rather than sitting in a chair in front of a screen doing computer-based training off of a modified PowerPoint with multiple-choice tests, you can actually be in the context of care and earning while you learn rather than learning to earn.

+ +

CHAD: Well, at thoughtbot, we're a big believer in apprenticeships as a really solid way of learning quickly from an experienced mentor in a structured way. I was excited to hear about the apprenticeship model that you have.

+ +

BROCK: Well, it's really exciting, isn't it? I mean, when you begin looking at what AI can do as...let's call it a copilot. I thought some of the numbers that Ethan Mollick at Wharton Business School shared on his blog and his study with Boston Consulting Group, which is that an AI copilot can actually raise the quality of work, raise the floor to 82%, what he calls mediocrity. 82% was a pretty good grade for a lot of kids in my classes back when I was a Montessori teacher.

+ +

But, in this case, what it does is it raises the floor to care by guiding through apprenticeship, and it allows people to learn through observation and trial and error. And people who are already at that 82nd percentile, according to Mollick's numbers, increase their productivity by 40%. The thing that we're not clear on is if certain people have a greater natural proficiency or proclivity for using these care pilots or if it's a learned behavior.

+ +

CHAD: So, the impact that CareTrainer can have is huge. The surface area of the problem and the size of the industry is huge. But often, from a product perspective, what we're trying to do is get to market, figure out the smallest addressable, minimum viable product. Was that a challenge for you to figure out, okay, what's the first thing that we do, and how do we bring that to market and without getting overwhelmed with all the potential possibilities that you have?

+ +

BROCK: Yeah, of course. I start out with what I call a GRITS model. I start out with, what are my goals? Then R, let's review the market. How is this problem being addressed now? I, what are my ideas for addressing these goals, and what's currently being done? And T, what tasks need to be completed in order to test these ideas? And what steps will I take to test them and iterate as far as a roadmap?

+ +

And what that allowed me to do is to begin saying, okay, let's take the ideas that I can bring together first that are going to have the first initial impact because we're bootstrapping. And what we need to be able to do is get into a room with somebody who realizes that training caregivers and nursing is something that needs a review, maybe some fresh ideas. And getting that in front of them, understanding that that's our MVP 1 was really important. And what was really interesting is our MVP 2 through 5, we've begun to see that the technology is just exponential, the growth and progress.

+ +

Our MVP 2 we thought we're going to be doing a heck of a lot of stuff with multimedia reinforcement learning. But now we're finding that some of the AI giants have actually done the work for us. So, I have just been very happy that we started out simple. And we looked at what is our core problem, which is, you know, what's the best way to train people? And how do we do that with the least amount of effort and the most amount of impact? And the key to it is customer obsession. And this is something I learned at Amazon as their first principle.

+ +

And many of the experiences that I brought from places like Amazon and other big tech is, how do I understand the needs of the customer? What problems do they have, and what would make this a more playful experience? And, in this case, I wanted to design for curiosity. And the thing that I like to say about that is AI chose its symbol of the spark really smartly. And I think the spark is what people want in life. And the spark is exploring, and it's finding something. And you see this kind of spark of life, this learning, and you discover it. You create more from it. You share it. It's enlightening. It's inspirational. It makes people excited. It's something that they want to share. It's inventing. It's creation.

+ +

I think that's what we wanted to have people experience in our learning, rather than my own experience in computer-based training, which was sitting in front of a flashified PowerPoint with multiple choice questions and having the text read to me. And, you know, spending 40 hours doing that was kind of soul-killing. And what I really wanted to do was be engaged and start learning through experience. And that's what came down to our MVP 1 is, how do we begin to change the way that training occurs? How can we change the student experience and still provide for the institutional needs to get people on the floor and caring for people? And that was our first priority.

+ +

And that's how we began to make hard decisions about how we were going to develop from MVP 1, 2, 3, 4, and 5 because we had all the big ideas immediately. And part of that is because I had created a package like this back in 2004 for a five-state regional care provider in the Midwest. Back then, I was designing what could only be called a finite game. I'm designing in Flash for web. I'm doing decision trees with dialogue, and it's much like a video game, but a serious game. It's getting the assessment correct in the interactions and embedding the learning in the interaction and then being able to judge that and provide useful feedback for the player.

+ +

And what this did was it made it possible for them to have interactive learning through doing in the form of a video game, which was a little bit more fun than studying a textbook or taking a computer-based test. It also allowed the health system a little bit more focus on the patients because what was happening is that they would be taking their best people off the floor and taking a partial schedule to train these new people. But 45% of those that they were training were leaving within the first 30 days. So, the game was actually an approach to providing that interaction as a guided apprenticeship without taking their best people off the floor into part-time schedules and the idea that they might not even be there in 30 days.

+ +

So, that's kind of a lot to describe, but I would say that the focus on the MVP 1 was, this is the problem that we're going to help you with. We're going to get people out of the seats and onto the floor, off the screen, caring for people. And we're going to guide them through this guided apprenticeship, which allows for contextual computing and interaction, as we've worked with comparing across, like, OpenAI, Anthropic, Google, Mistral, Grok, trying these different approaches to AI, figuring out which models work best within this context. And, hopefully, when we walk in and we're sitting with an exec, we get a "Wow," [laughs]. And that's the big thing with our initial technology. We really want a wow.

+ +

I shared this with a former instructor at the University of Minnesota, Joe Gaugler, and I said...I showed him, and he's like, "Wow, why isn't anybody doing this with nursing and such?" And I said, "Well, we are," you know, that's what I was hoping he would say. And that's the thing that we want to see when we walk into somebody's office, and we show them, and they say, "Wow, this is cool." "Wow, we think it's cool. And we hope you're going to want to go on this journey with us." And that's what MVP 1 should do for us is solve what seems like a little problem, which is a finite game-type technology, but turn it into an infinite game technology, which is what's possible with AI and machine learning.

+ +

WILL: I love, you know, you're talking about your background, being a teacher, and in gaming, and I can see that in your product, which is awesome. Because training can be boring, especially if it's just reading or any of those things. But when you make it real life, when you put someone, I guess that's where the quote comes from, you put them in the game, it's so much better. So, for you, with your teacher background and your gaming background, was there a personal experience that you had that brought out your passion for caregiving?

+ +

BROCK: You know, my mom is a nurse. She has always been into personal development. By the time I was in sixth grade, I was going to CPR classes with her while she was [inaudible 19:22] her nursing thing [laughs]. So, I was invited to propose a solution for the first version of CareTrainer, which had a different name back in 2004, which we sold. That led to an invitation to work and support the virtual clinic for the University of Minnesota Medical School, which is no longer a thing. The virtual clinic that is the medical school is still one of the best in the country, a virtual stethoscope writing grants as an academic for elder care.

+ +

And I would have to say my personal story is that at the end of their lives, I took care of both my maternal grandmother in her home while I was going to college. And then, I took care of my paternal grandfather while I was going to college. And, you know, those experiences were profound for me because I was able to sit down and have coffee with them, tell jokes, learn about their lives. I saw the stories that went with the pictures.

+ +

And I think one of the greatest fears that I saw in many of the potential customers that I've spoken to is at the end of a loved one's life that they didn't learn some of the things that they had hoped from them. And they didn't have the stories that went with all the pictures in the box, and that's just an opportunity missed.

+ +

So, I think those are some of the things that drive me. It's just that connection to people. And I think that's what makes us humane is that compassion, that wanting to understand, and, also, I think a desire to have compassion and to be understood. And I think that's where gaming and play are really important because making mistakes is part of play. And you can make lots of mistakes and have lots of ways to solve a problem in a game. Whereas in computer-based training and standardized tests, which I used to address as a teacher, there's typically one right answer, and, in life, there is rarely a right answer [laughs].

+ +

CHAD: Well, and not really an opportunity to learn from mistakes either. Like, you don't necessarily get an opportunity on a standardized test to review the answers you got wrong in any meaningful way and try to learn from that experience.

+ +

BROCK: Have you ever taken one of those tests and you're like, well, that's kind of right, but I think my answer is better, but it's not here [laughter]? I think what we really want from schools is creativity and innovation. And when we're showing kids that there's just a right answer, we kind of take the steam out of their engine, which is, you know, well, what if I just explore this and make mistakes?

+ +

And I remember, in high school, I had an art teacher who said, "Explore your mistakes." Maybe you'll find out that their best is intentional. Maybe it's a feature, not a bug [laughs]. I think when I say inculcate play or inspire play, there's a feeling of psychological safety that we can be vulnerable, that we can explore, we can discover; we can create, and we can share.

+ +

And when people say, "Oh, well, that's stupid," and you can say, "Well, I was just playing. I'm just exploring. I discovered this. I kind of messed around with a little bit, and I wanted to show you." And, hopefully, the person backs off a little bit from their strong statement and says, "Oh, I can see this and that." And, hopefully, that's the start of a conversation and maybe a startup, right [laughs]?

+ +

CHAD: Well, there are so many opportunities in so many different industries to have an impact by introducing play. Because, in some ways, I feel like that may have been lost a little bit in so many sort of like addressing problems at scale or when scaling up to particular challenges. I think we trend towards standardization and lose a little bit of that.

+ +

BROCK: I agree. I think humans do like continuity and predictability. But what we find in product is that when we can pleasantly surprise, we're going to build a customer base, you know, that doesn't come from, you know, doing the same thing all the time that everybody else does. That's kind of the table stakes, right? It works. But somebody is going to come along that does it in a more interesting way. And people are going to say, "Oh."

+ +

It's like the arts and crafts effect in industrialization, right? Everybody needs a spoon to eat soup, a lot of soup [laughs]. And somebody can make a lot of spoons. And somebody else says, "Well, I can make spoons, too." "And how do I differentiate?" "Well, I've put a nice scrollwork design on my spoon. And it's beautiful, versus this other very plain spoon. I'll sell it to you for a penny more." And most people will take the designed thing, the well-designed thing that provides some beauty and some pleasure in their life. And I think that's part of what I described as the spark is that realization that we live in beauty, that we live in this kind of amazing place that inspires wonder when we're open to it.

+ +

MID-ROLL AD:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

WILL: You mentioned gamifying the training and how users are more involved. It's interesting because I'm actually going through this with my five-year-old. We're trying to put him in kindergarten, and he loves to play. And so, if you put him around a game, he'll learn it. He loves it. But most of the schools are like, workbooks, sit down; focus, all of those things.

+ +

And it probably speaks to your background as being a Montessori teacher, but how did you come up with gamifying it for the trainee, I guess you could say? Like, how did you come up with that plan? Because I feel like in the school systems, a lot of that is missing because it's like, like you said, worksheets equal that boring PowerPoint that we have to sit down and read and stuff like that. So, how did you come up with the gamifying it when society is saying, "Worksheets, PowerPoints. Do it this way."

+ +

BROCK: I think that is something I call the adult convenience model. Who's it better for: the person who has to do the grading and the curriculum design, or the kid doing the learning? And I think that, in those cases, the kid doing the learning misses out. And the way that we validate that behavior is by saying, "Well, you've got to learn how to conform. You've got to learn how to put your own interests and drives aside and just learn how to focus on this because I'm telling you to do it." And I think that's important, to be able to do what you're asked to do in a way that you're asked to do it. But I think that the instructional model that I'm talking about takes much more up-front thought.

+ +

And where I came from with it is studying the way that I like to learn. I struggled in school. I really did. I was a high school dropout. I went to junior college in Cupertino, and I was very surprised to find out that I could actually go to college, even though I hadn't finished high school. And I began to understand that it's very different when you get to college, so much more of it is about giving you an unstructured problem that you have to address. And this is the criteria under which you're going to solve the problem and how I'm going to grade you. And these are the qualities of the criteria, and what this is, is basically a rubric.

+ +

We actually see these rubrics and such in products. So, for example, when I was at American Family, we had this matrix of different insurance policies and all the different things in the column based upon rows that you would get underneath either economy, standard, or performance. And I think it was said by somebody at Netflix years ago; there's only two ways to sell bundled and unbundled. The idea is that there were these qualities that changed as a gradient or a ratio as you moved across this matrix. And the price went up a little bit for each one of those qualities that you added into the next row or column, and that's basically a rubric.

+ +

And when we begin to create a rubric for learning, what we're really doing is moving into a moment where we say, "This is the criteria under which I'm going to assess you. These are the qualities that inform the numbers that you're going to be graded with or the letter A, B, or C, or 4, 3, 2, 1. What does it mean to have a 4? Well, let me give you some qualities." And one of the things that I do in training companies and training teams is Clapping Academy. You want to do that together?

+ +

WILL: Yeah, I would love to.

+ +

BROCK: Would you like to try it here? Okay. Which one of you would like to be the judge?

+ +

WILL: I'll do it.

+ +

BROCK: Okay. As the judge, you're going to tell me thumbs up or thumbs down. I'm going to clap for you. Ready? [Claps] Thumbs up or thumbs down?

+ +

CHAD: [laughs]

+ +

WILL: I say thumbs up. It was a clap [laughs].

+ +

BROCK: Okay. Is it what you were expecting?

+ +

WILL: No, it wasn't.

+ +

BROCK: Ah. What are some of the qualities of clapping that we could probably tease out of what you were expecting? Like, could volume or dynamics be one?

+ +

WILL: Yeah, definitely. And then, like, I guess, rhythm of it like music, like a music rhythm of it.

+ +

BROCK: Okay. In some cases, you know, like at jazz and some churches, people actually snap. They don't clap. So, hands or fingers or style. So, if we were to take these three categories and we were to break them 4, 3, 2, 1 for each one, would a 4 be high volume, or would it be middle volume for you?

+ +

WILL: Oh, wow. For that, high volume.

+ +

BROCK: Okay. How about rhythm? Would it be 4 would be really fast; 1 would be really slow? I think slow would be...we have this cultural term called slow clapping, right [laughter]? So, maybe that would be bad, right [laughter]? A 1 [laughter]? And then, style maybe this could be a non-numerical category, where it could just be a 1 or a 2, and maybe hands or slapping a thigh or snapping knuckles. What do you think?

+ +

WILL: I'm going off of what I know. I guess a clap is technically described as with hands. So, I'll go with that.

+ +

BROCK: Okay, so a 4 would be a clap. A 3 might be a thigh slap [laughter]. A 2 might be a snap, and a 1 would be air clap [laughter].

+ +

WILL: Yep.

+ +

BROCK: Okay. So, you can't see this right now. But let's see, if I were to ask you what constitutes a 12 out of 12 possible, we would have loud, fast, hand-to-hand clap. I think we could all do it together, right [Clapping]? And that is how it works. What I've just done is I've created criteria. I've created gradients or qualities. And then, we've talked about what those qualities mean, and then you have an idea of what it might look like into the future. You have previewed it.

+ +

And there's a difference here in video games. A simulation is where I copy you step by step, and I demonstrate, in performance, what's been shown to me to be accurate to what's been shown to me. Most humans don't learn like that. Most of us learn through emulation, which is we see that there's an outcome that we want to achieve, and we see how it starts. But we have to improvise between the start and the end. In a book by Michael Tomasello on being human...he's an anthropologist, and he studies humans, and he studied other primates like great apes. And he talks about emulation as like the mother using a blade of grass, licking it, and putting it down a hole to collect ants so that she can eat the ants.

+ +

And oftentimes, the mother may have their back to her babies. And the babies will see the grass, and they'll see that she's putting it in her mouth, but they won't see the whole act. So, they've just [inaudible 33:29] through trial and error, see if they can do it. And this is the way an earlier paper that I wrote in studying kids playing video games was. We start with trial and error. We find a tactic that works for us. And then, in a real situation, there might be multiple tactics that we can use, and that becomes a strategy. And then, we might choose different strategies for different economic benefits.

+ +

So, for example, do I want to pay for something with pennies or a dollar, or do I want a hundred pennies to carry around? Or would I rather have a dollar in a game, right? We have to make this decision of, what is the value of it, and what is the encumbrance of it? Or if it's a shooting game, am I going to take out a road sign with a bazooka when I might need that bazooka later on? And that becomes economic decision-making.

+ +

And then, eventually, we might have what's called top site, which is, I understand that the game has these different rules, opportunities, roles, and experiences. How do I want to play? For example, Fallout 4 was a game that I really enjoyed. And I was blown away when I found out that a player had actually gone through the Final Boss and never injured another non-player character in the game. They had just done the whole thing in stealth. And I thought that is an artistic way to play. It's an expression. It's creative. It's an intentional way of moving through the game.

+ +

And I think that when we provide that type of independent, individual expression of learning, we're allowing people to have a unique identity, to express it creatively, and to connect in ways that are interesting to other people so that we can learn from each other. And I think that's what games can do.

+ +

And one of the hurdles that I faced back in 2004 was I was creating a finite game, where what I had coded in decision trees, in dialogue, in video interactions, once that was there, that was done. Where we're at now is, I can create an infinite game because I've learned how to leverage machine learning in order to generate lots of different contexts using the type of criteria and qualities that I described to you in Clapping Academy, that allow me to evaluate many different variations of a situation, but with the same level of expectation for professionalism, knowledge and expertise, communication, compassion, curiosity. You know, these are part of the eight elements of what is valued in the nursing profession.

+ +

And when we have those rubrics, when we have that matrix, we begin to move into a new paradigm in teaching and learning because there's a much greater latitude and variety of how we get up the mountain. And that's one of the things that I learned as a teacher is that every kid comes in differently, but they're just as good. And every kid has a set of gifts that we can have them, you know, celebrate in service to warming up cold spots.

+ +

And I think that sometimes kids are put into situations, and so are adults, where they're told to overcome this cold spot without actually leveraging the things that they're good at. And the problem with that is, in learning sciences, it's a transfer problem, which is if I learn it to pass the test, am I ever going to apply it in life, or is it just going to be something that I forget right away? And my follow-ups on doing classroom and learning research is that it is usually that. They learned it for the test. They forgot it, and they don't even remember ever having learned it.

+ +

And the greatest gift that I got, having been a teacher, was when my wife and I would, I don't know, we'd be somewhere like the grocery store or walking out of a Target, and a couple of young people would come up and say, "Yo, Mr. Dubbs," And I'd be like, "Hey [laughs]!" And they're like, "Hey, man, you remember when we did that video game class and all that?" And I was like, "Yeah, you were so good at that." Or "Remember when we made those boats, and we raced them across the pool?" "Yeah, yeah, that was a lot of fun, wasn't it?" And I think part of it was that I was having as much fun doing the classes and the lessons as they were doing it.

+ +

And it's kind of like a stealth learning, where they are getting the experience to populate these abstract concepts, which are usually tested on these standardized choice tests. And it's the same problem that we have with scaling a technology. Oftentimes, the way that we scale is based on conformity and limited variation when we're really scaling the wrong things. And I think it's good to be able to scale a lot of the tasks but provide great variety in the way that we can be human-supported around them.

+ +

So, sure, let's scale sales and operations, but let's also make sure that we can scope out variation in how we do sales, and how we do customer service, and how we do present our product experience. So, how do we begin to personalize in scope and still be able to scale? And I think that's what I'm getting at as far as how I'm approaching CareTrainer, and how I'm approaching a lot of the knowledge translation that we're doing for startups, and consulting with larger and medium-sized businesses on how they can use AI.

+ +

CHAD: That's awesome. Bringing it back to CareTrainer, what are some of the hurdles or cold spots that are in front of you and the business? What are the next steps and challenges in front of you?

+ +

BROCK: I think the big thing is that I spend a good two to three [laughs] hours a day reading about the advances in the tech, you know, staying ahead of the knowledge translation and the possible applications. I mean, it's hard to actually find time to do the work because the technology is moving so fast. And, like I said, we were starting to build MVP 2, and we realized, you know what, this is going to be done for us in a little while. You know, it'd be cool if we can do this bespoke. But why not buy the thing that's already there rather than creating it from scratch, unless we're going to do something really different?

+ +

I think that the biggest hurdle is helping people to think differently. And with the elder care crisis and the care crisis, I think that we really have to help people think differently about the things that we've done. I think regulation is really important, especially when it comes to health care, treatment, prescription safety. I think, though, that there are a lot of ways that we can help people to understand those regulations rather than put them in a seat in front of a monitor.

+ +

CHAD: I think people respond to, you know, when there's a crisis, different people respond in different ways. And it's a natural tendency to not want to rock the boat, not introduce new things because that's scary. And adding more, you know, something that is scary to a difficult situation already is hard for some people. Whereas other people react to a crisis realizing that we got into the crisis for a reason. And the old ways of doing things might not necessarily be the thing to get us out of it.

+ +

BROCK: Yeah, I totally agree. When I run into that, the first thought that comes to my head is, when did you stop learning [laughs]? When did you stop seeking learning? Because, for me, if I were to ever stop learning, I'd realize that I'd started dying. And that's what I mean by the spark, is, no matter what your age, as long as you're engaged in seeking out learning opportunities, life is exciting. It's an adventure. You're discovering new frontiers, and, you know, that's the spark. I think when people become complacent, and they say, "Well, this is the way we've always done it," okay, has that always served us well?

+ +

And there are a lot of cultural issues that go with this. So, for example, there are cultural expectations about the way kids learn in class. Like, kids who come from blue-collar families might say, "Hey, you know what? My kid is going to be doing drywall, or he's going to be working fixing cars, or he's going to be in construction, or why does he need to do this? Or why does she need to do that? And, as a parent, I don't even understand the homework." And then, there are the middle-class folks who say, "You know what? I'm given these things. They need to be correct, accurate, and easy to read. And that's my job. And I don't see this in my kids' curriculum."

+ +

And then, there are the creatives who say, "Hey, you know, this has nothing to do with where my kid is going. My kids are creative. They're going to have ambiguous problems that they have to come up with creative solutions for." Then you get to the executive class where, like, these elite private schools, where they say, "My kid is going to be a leader in the industry, and what they should be doing is leading groups of people through an activity in order to accomplish a goal."

+ +

And those are four different pedagogical approaches to learning.

+ +

So, I'm wondering, what is it that we expect from our caregivers? And I've got kind of a crazy story from that, where this young woman, [SP] Gemma, who was a middle school student, I gave her the option, along with my other kids, to either take a standardized test on Greek myths, or they could write their own myth. And she wrote this myth about a mortal who fell in love with a young goddess. Whenever they would wrap and embrace and kiss, a flame would occur.

+ +

One day the mother found out and says, "Oh, you've fallen in love with a mortal. Well, here you shall stay. This shall be your penance." And she wrapped her in this thread, this rope, and dipped them in wax so they would be there forever. But then the flame jumped to the top, and that is how candles were created.

+ +

And I read that, and I was...and this is, like, you know, 30 years ago, and I still have this at the top of my head. And I was like, "Gemma, that was amazing. Are you going to go to college?" And she says, "No." "No? Really? What are you going to do?" "I want to be a hairstylist." And, in my mind, my teacher mind is like, oh no, no, no, no. You [laughs] need to go to college. But then I thought about it. I thought, why wouldn't I want a smart, skilled, creative person cutting my hair? And, you know, people who cut hair make really good money [laughter].

+ +

And the whole idea is, are we actually, you know, empowering people to become their best selves and be able to explore those things? Or are we, you know, scaring them out of their futures with, you know, fear? Those are the big hurdles, which is, I'm afraid of the future. And the promise is, well, it's going to be different. But I can't assure you that it's not going to come without problems that we're going to have to figure out how to solve. And there are some who don't want the problems. They just want how it's always been.

+ +

And I think that's the biggest hurdle we face is innovation and convincing people that trying something new it may not be perfect, but it's a step in the right direction. And I think Hans Rosling in Factfulness said it very well. He said, "Things are better than they were before, but they're not great." Can we go from good to great? Sure. And what do we need to do? But we always are getting better, as long as we're continuing to adapt and create and be playful and look at different ways of doing things because now people are different, but just as good.

+ +

CHAD: Brock, I really appreciate you stopping by and bringing your creativity, and energy, and playfulness to this difficult problem of caregiving. I'm excited for what the future holds for not only CareTrainer but the impact that you're going to have on the world. I really appreciate it.

+ +

BROCK: Well, thank you for having me and letting me tell these stories, and, also, thanks for participating in Clapping Academy [laughter].

+ +

WILL: It was great.

+ +

CHAD: If folks want to get in touch with you or follow along with you, or if they work in a healthcare organization where they think CareTrainer might be right for them, where are all the places that they can do that?

+ +

BROCK: You can reach me at brock@caretrainer.ai. They can express interest on our website at caretrainer.ai. They can reach me at my personal website, brockdubbels.com, or connect with me on LinkedIn, because, you know, life is too short not to have friends. So, let's be friends [laughs].

+ +

CHAD: You can subscribe to the show and find notes for this entire episode along with a complete transcript at giantrobots.fm.

+ +

WILL: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Mastodon at cpytel@thoughtbot.social.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thank you again, Brock. And thank you all for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pBu8o0pO + + ]]> + + Will Larry + Chad Pytel + + + 534: How Toma is Transforming Car Dealerships with Voice AI Technology + https://podcast.thoughtbot.com/534 + fff864a8-70b1-4fbf-aa35-f4eb82fb36fd + Thu, 18 Jul 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Chad Pytel interviews Monik Pamecha, CEO of Toma, about how their AI technology automates phone calls for car dealerships, significantly enhancing customer service. Monik shares Toma's journey from initial AI experiments to focusing on voice AI, detailing the challenges and successes along the way. The discussion also covers the practical implementation of Toma's AI solutions in the automotive industry and the importance of clear communication about AI's role in customer interactions. + 44:37 + no + + + Host Chad Pytel interviews Monik Pamecha, the Co-Founder and CEO of Toma, a company specializing in AI for the automotive industry. Monik discusses how Toma automates phone calls for car dealerships, enhancing customer service and streamlining interactions. Despite advancements in digital communication, phone calls remain crucial in the automotive sector, and Toma leverages AI to improve these experiences significantly. +Monik shares his journey in the tech industry, detailing Toma's evolution from experimenting with different AI applications to focusing on voice AI. He explains the challenges and successes faced along the way, highlighting how AI technology has matured since his early work with chatbots in 2016. The conversation reveals how Toma's voice AI quickly gained user traction, validating their focus on this innovative technology. +The episode also delves into the practical implementation of Toma's AI solutions in the automotive industry. Monik emphasizes the importance of integrating AI with existing dealership software and the gradual rollout process to ensure effectiveness. He discusses the need for clear communication about AI's role in customer interactions, reflecting diverse responses across different demographics. Monik's insights provide a compelling look at the future of AI in automotive customer service. +Toma (https://www.toma.so/) +Follw Toma on X (https://twitter.com/toma_voice), LinkedIn (https://www.linkedin.com/company/tomavoice/), or Facebook (https://www.facebook.com/tomavoiceai/). +Follow Monik Pamecha on LinkedIn (https://www.linkedin.com/in/monikp/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: + CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And I'm joined today by Monik Pamecha, Co-Founder and CEO of Toma, which provides AI for the automotive industry. Monik, thanks for joining me. +MONIK: Hey, Chad, thanks for having me. +CHAD: Obviously, in fact, as evidenced by the guest list that we've had over the last few months, a lot of companies are either integrating AI into their products or starting new companies. And you've been around doing AI for quite a while now. Tell us about Toma. +MONIK: Yeah. So, Toma automates phone calls for the automotive industry right now, and we build a lot of different AI products as well. It's an interesting market, but one of the leading users of phone calls for doing business. So, a lot of the business, which is buying cars, you know, the first touch happens over the phone, you know, people bringing in their cars for service, getting updates, and all that, like, mostly happens over the phone, even though you have had websites and apps and all of these around. +And to give you, like, an idea of scale, like, there are 290 million cars in the U.S. alone, which is, like, about 90% of the population has at least one car. So, scale is massive, and Toma is making that experience of getting service and just dealing with anything related to automotive, like, 100 times better. +CHAD: So, I would encourage people to go to the website and check it out, because, I have to admit, I was a little skeptical, at first, about how good the phone call could actually be. And I was impressed by how natural it was, how it was able to respond in the video demos that I saw. So, how did you know that this was going to be possible? +MONIK: I think a lot of it comes from our own experiences, I mean, not with automotive, but with technology. So, I've been in tech for a long time. I mean, I started writing code when I was, I think, 11 or 12, a similar story for my co-founders as well. But I've been doing machine learning research as well in the past. In fact, this was in 2016 when I wrote a paper on this as well, and we built a chatbot that was based on generative models. And, at the time, in 2016, it was really funky. Like, Google had come up with something called Sequence to Sequence, and we were using that to train it on a little bit of data that we had, and we had something that kind of worked. +And, at the time, I was thinking that, I mean, when you were working with that, you'd see it, like, go off the rails and, like, do something really stupid. It couldn't even get grammar right. And, at the time, I saw all the holes that I was like, if somebody plugged these, like, you know, this would be phenomenal. Like, this is what it takes for it to work, you know, these are the places, more from a practical experience, right? Like, if you had to take it to production, like, what would you need to fix? +And then, six years later, I see that things actually started picking up, right, like, they actually fixed all those holes. And it came back to me, and I was like, all right, this is the time. You know, those were the issues. They're all fixed. Now you can go ahead and build. So, I think a lot of it came from experience as to like, all right, this is what we should build, or this is why we should build, like, in terms of the technology. But we didn't really arrive at this idea, so to speak, you know, at least as a founding team. It was a lot of pivots. +CHAD: What was the original sort of idea that you said, okay, we're going to start a company to do this? +MONIK: Well, that was very different from this very, very different. So, my co-founder and I, like, most founders, like, the first thing they do is they try to look for problems that they themselves have. And we're like, huh, looks like...what do we have in common? We have some chronic conditions, and we've used diet to, you know, manage them. So, maybe let's build a tool to help, you know, patients manage conditions with, you know, diet recommendations. And we spent six months on that, and it went absolutely nowhere. +Also, I think consumer products are just different. They require a different kind of thinking. But, you know, we were just trying to throw something on the wall and pray it sticks. And, you know, it was honestly pretty miserable because we got banned on a bunch of communities on Reddit and Facebook trying to promote it. And, like, all the people who tried our product they just never came back again, and, you know, things like that when you have something that people don't want, right? So, we see that side. +I mean, and after that, we go ahead and we try to do...I think it was during it, I don't know, like, when you get a sense of, like, something's not going to work, where, like, then we realized maybe we should stick to what we know best, which is, you know, we're both technical. So, maybe we should do something that's, you know, more relying on those skills than something entirely different, which I think Y Combinator calls it founder-market fit. I think that's also very true. Of course, you can, like, build something for a business you know nothing about, but there must be some compatibility. +So, yeah, we started with that, kept on experimenting. And then, I think, at some point, we were so annoyed that we made, you know, a list on Google Sheets. And we're like, all right, let's just, you know, vomit out 10 ideas that we have had, and let's write them all, and let's go after them one by one. Let's spend two weeks until we hit something that, you know, maybe we think has legs. And the third idea or the fourth idea on that was building something with voice AI. And, at the time, even that was, like, just a horizontal platform. That was it. All right, so we go ahead and commit to that. +So, if we go through the list, try the first two or three ideas, I think the first thing was...then we went on the other extreme where we're like, all right, let's do something we do all day long, which is, as engineers, we are on call. So, you know, even at, I don't know, 2:00 a.m. in the night if your system is down, you get a pager on your phone saying, "Get on the computer and fix it." And we're like, how could we make that better? That was the first thing on that list. We spent some time trying to do it and, again, we kind of get that feeling. +I think the more you fail, I guess, the better you get at detecting failure. I don't know about success but failure for sure it works like that. I think the third or the fourth idea was voice AI, and then we go ahead. We hack a prototype over a weekend and then put it out on...again, the communities that we know how to market were, like, Facebook groups and Reddit. And it picks up. Like, within, like, 3 days, we had 200 demo calls set up. And that just blew our minds because having been on the other side, we're like, oh, this is what it feels like when people kind of want something, what you have. I mean, it's still not clear, right? But -- +CHAD: And you put it out there as automated voice assistant for businesses? +MONIK: No, actually what we did [laughs], I mean, nobody will want to click that if you put it like that [laughter]. You know, just out of curiosity, I was like, "Hey, you know, I've built this thing. It does this, you know, what do you think? Do you think this has any use for you?" And that's it. Like, people are, you know, messaging me nonstop, like, DMing me that, "Can you please share it with me? You know, I run this business. This might be helpful." +It was, like, more genuine. Like, I was just exploring, but, you know, that was a question that I posed. And that had, like, so many people show up, and they're like, "How about you just give us that and we can make money off of this?" And then, we started, you know, digging deeper, and we're like, oh, okay, it looks like you have so many manual processes and across industries. So, we had, like, some people from healthcare, some people from, like, you know, MLMs, multi-level marketing, so many different industries, optometrists, some in construction. +Anyway, so we're, like, thinking at that point, huh, okay. Maybe there is something here. Again, no mention of automotive, no mention of dealerships, nothing. We had a single dealership then. And I would say this was, like, about six months. I don't even know how many months ago, but, like, a couple of months ago. I think, at the time, is when we applied to Y Combinator as well. +CHAD: So, you applied to Y Combinator with the voice idea. +MONIK: Right. And we put something out there. I forget if it was the healthcare idea or the voice idea, but it's probably one of the two. I mean, that's also the other thing about Y Combinator. I think they don't really focus on ideas as much as they just focus on teams, which I think is probably the best practice. You know, we pivoted again [laughs]. +But yeah, so we did voice AI, and then spent some time just trying to do everything, right? Trying to build a horizontal layer for voice, where building assistance for all kinds of businesses. And, you know, one of the businesses, at the time, was a dealership. I always like to think of this as an arranged marriage, where, you know, we have the customer. We kind of work through it -- +CHAD: So, you had an actual dealership that you were partnered with as sort of a expert in the industry? +MONIK: Our first customer, right. And they were very progressive dealers, so they're always trying new things. And, at the time, we were working with a bank. We were working with some healthcare locations as well. We had some construction industry... whatnot. And we were going crazy trying to build something because everybody had these different requirements. And then, in practice, like, if you push AI out in the wild, to make it work, you need a lot of things, like deep domain expertise being one of them. +So, that realization is happening, you know, where we're coming to terms with that. And, at the same time, it works really well for the dealership, and they bring another customer. And they're like, "Oh, they also want to use it," and we're like, "Okay, sure. We'll turn it on." Then we do it. And then, it works again. And then, they bring more customers. And then, we're like, wait a minute, you know, like, we're not doing any outreach. We're not pushing out anything, and it seems like customers want it. And then, there are these other places where we're struggling so much. +Like, even with healthcare, you know, the regulations in banking and healthcare they slow down, you know, any sort of, like, AI implementations. So, even that world was very different with the automotive space. And you kind of do more of it and then you're like, oh, okay, looks like there is something here, and then we just decide to double down on that space. And then, we go further deep in and you realize, oh -- +CHAD: Did Y Combinator...that can be a difficult decision for founders to make. So, did being in Y Combinator help you sort of give you the push to make that kind of bold decision? +MONIK: At least from our experience, it's always been that they're, like, get to the truth very quickly, whatever it is, and then make a decision. Do not delay it. I think we were, in fact, slow to do that. I think they were probably pushing people to do it more because we saw companies pivot in our batch, like, two times, three times right before demo day, which is the end of the program. Like, two weeks before, they just completely changed the company, and that's completely okay. +CHAD: So, how does an implementation actually happen? How does it roll out to a new customer? +MONIK: I mean, this is also very new, right? I think as you come across new customers, you have to adapt the process. But the essence of it is that you first have some data to start, which is, for example, for us, we work with a bunch of call recordings because a lot of our customers are already recording a lot of their calls. So, that gives you, like, some data as to what the experience is like today. Then the next thing is you get an idea of what you know your customers want the experience to be like. And then, you're basically now figuring out the delta between the two. +And then, you're configuring the AI agents, making sure, testing it. And then, you have, like, a period of, like, a week or so where you get through all of that. Then you work through integrations with existing softwares. That also, by the way, is another, like, I would say automotive is a sleeping giant. Like, an auto dealership, on average, like, per month will be spending $50, 000 on software. +CHAD: Wow. +MONIK: Because the whole business runs on software—everything starting from sales, inventory, parts, service, everything, repair orders—all of it comes through that. +CHAD: Now, is there a single common platform that a lot of dealers are using? +MONIK: Unfortunately, no. There are some major players; CDK Global is one of them, which actually was hacked recently. And it's in, like, over 15, 000 dealerships, and all of them shut down. +CHAD: Wow. +MONIK: Like, they just couldn't do any business, and they had to come up with creative workarounds. So, it was pretty painful, kind of, like, a COVID, you know, COVID moment for them. And then, yeah, we've been trying to help our dealers, whoever used that software, to, you know, again, come out with workarounds, where the AI is actually capturing all the information. And, you know, instead of dumping it into that system, it's, you know, finding workarounds on how to get it to our dealers. But yeah, so you integrate with them. That is, like, another major step. And they're, you know, they're not the most tech-forward companies so, you know, that can be a little challenging. +CHAD: Right. So, they use a lot of software, but they're not necessarily tech for...they probably don't have big IT departments and that kind of thing. And then, the users are probably non-technical. +MONIK: Correct. Yeah. The thing about dealers, I think, is that they're so plugged into the business, like, they know everything that is happening in the business. Everybody knows what the bottom line looks, what really will move the needle, what is a good customer experience. They may not be technical, but I don't think it even matters. That's the thing. +But yeah, we were talking about, like, the process, so it takes a couple of weeks So, you do, you know, you get all the information from them as to what needs to be done. You integrate into the systems. And then, the next thing that you do is you start slowly, where, for example, when we start taking phone calls for them, we initially start with off hours and overflow. So, when nobody's able to pick up a phone call, we get the phone calls. And that's how you get, like, some training data at the beginning in a safe manner. +And then, as the volume increases, you know, you get more confident, and you roll it out to a larger audience. But I think the key thing here is it has to be a gradual process because, even for the customer, it's something so new, like, to have a full-fledged conversation. Like, you can have a phone tree where it's, like, press one; press two. You're used to that kind of stuff, and that's been around for 15 years, and it still is, you know. And it is not the most natural thing, but it continues to exist. So, this is the next, you know, natural evolution of that interface where it's more free-flowing and, you know, less annoying. +CHAD: Do all of your customers...when the AI agent answers, does it say it's an AI agent? +MONIK: I mean, our recommendation is to always say that. I mean, it's up to the customer, eventually, if they want to say that or not. And, in fact, it is pretty interesting. Demographics make a huge difference. Like, we're live in, you know, all the states, not all but I would say, like, all the major states. And the way people behave with AI agents is so different, you know, Florida, and Michigan, and California, like, we see the call quality. We see the metrics. We see how annoyed people are or how happy they are and things like that. The way they talk is so different. +And one of the parameters in that is actually, you know, letting them know that it is an AI or not as well. So, we tweak that based on, you know, where we are. But for the most part, we always say that because we want to set the expectations, right? Because, initially, when we didn't, the most popular question on the call was like, "Are you a human?" +CHAD: [laughs] +MONIK: And the fact that people are asking it was also pretty insane, right? +CHAD: Right. They could sort of tell that something was different. +MONIK: Yeah, if you have, like, a long enough conversation because, obviously, it's not human, right? And then, you go, like, five turns into the conversation, and then you realize, okay, it sounds like a human, like, you know, it's speaking pretty quickly. It's giving me the kind of answers I want. But, like, this thing is strange because, you know, humans have a personality now. +Like, with AI, like, a lot of the systems, I mean, you can build personality into it, but it still doesn't have a personality, like, the truth is still that. And it does show up, you know, in interesting ways. And, of course, there can be, you know, some sort of mechanistic issues, you know, like, whatever, right, like, what the customer is really used to and then what you actually say. I think the best practice is to almost always declare, like, it's an AI. And that has improved call quality significantly. +MID-ROLL AD: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +CHAD: Did you train your own models? +MONIK: Yeah, we collected enough data to be able to do that, and we have trained a lot of different components and different models. So, when you think of it, there's not, like, one model that does the whole thing. You have, like, a lot of these small, medium, and large models that do different parts. So, the voice and speech are, let's say, two components. +I think the brain of the agent is really the thing that needs the most amount of training because, you know, text to speech and voice, I mean, they have, like, you know, some limits and then, some, you know, business return. Like, after some point, like, there's not really much value to be gained there because if you can transcribe everything, you know, to a certain level of accuracy, all the regions change, you know, accents change. You can always improve. Then it's just expanding scope. +But really, with the brain of the agent, you have multiple different models that actually interact with each other, and they're not just LLMs or generative models. You have a lot of different types of things that are going. You know, you're looking up information. You are, you know, validating something. You're making sure if, you know, this is compliant with what, you know, your company's tone is, all of these happening at the same time. And then, these are the different things that you actually really need to train because that's so specific to, you know, the type of business that is happening. +CHAD: So, are you also doing your own hosting of the models, or are you using a cloud provider for that? +MONIK: Yeah, we use cloud providers. I think having a small team it's insane. I mean, you can host custom models on a lot of these providers now. And then, a lot of them even offer services for you to, like, train and, you know, they take care of the infrastructure as well. I think it's a good thing to rely on it if you're lean and small. There's only so much a few people [chuckles] can do and focus on. +CHAD: What are you most focused on right now, either from a business or a product perspective, or, you know, where's your area of biggest risk? +MONIK: Of course, there is always, you know, risk of competition. And I guess the real question is, like, where...a lot of popular AI companies get asked this as well, right? Like, what is your moat, right? And then, I mean, I think that is the most obvious risk, right? Where, like, what is stopping anybody else from doing what you're doing, right? And there are certain parts of it, which, you know, you can de-risk. Like, having data and having proprietary data is, like, one of the biggest factors in this, right, of de-risking this. +I mean, there's also like, you know, the risk of, let's say, especially in our industry, is, like, taking technology to an industry where, you know, consumers are not pro-technology. You know, they don't want to jump at the best thing that there is, right, especially customer service generally suffers from that, right? Like, people anytime they hear a bot or something and they're like, "Ah, representative agent." So, there's, like, some underlying risk in, you know, human tendencies as to what they want. +But, again, to think about it, like, you know, IVRs, which are these interactive voice response systems, they've been around for so long. Nothing about it is natural. It is completely alien to how we interact, but they've been around for so long. So, a lot of times, like, this innovation is actually pushed down from the business to the consumer and not the other way around. It may not be the best experience. It's getting there. +So, it's that battle between the two, which I think can delay implementations. You know, some people, like, one of our customers, at one point, we went through the entire deal. And I think the owner of the dealership group just said, "I don't believe in AI." Now, you know, like, it's pretty hard, right? Like, you have the metrics. You have the numbers. You're generating value, but the belief is strongly held. And then, at that point, you know, there's nothing you can do. +CHAD: Do you know why they were saying that? Was it like, I don't believe it as in I don't think it can do it, or I don't believe in it as in, like, it's against my ethics, or something like that? +MONIK: I feel like it's probably because they've been burned by past experiences of AI. Like, I think chatbots have been around for so long, and a lot of people in the automotive industry have used them. Now, they used to suck. And as I remember in 2016 as well, you know, over the few years that came, like, it was still pretty terrible. So, I think it's some muscle memory from that. +And then, also, I think AI has been hyped a lot, and I feel like people just generally discount anything that is hyped. And the opinion is that let's just wait for the dust to settle, and then we'll just pick the winners. So, it's also possible, right? On the adoption curve, like, there's you just hit some people who are probably not on the early or even the mid, right? Maybe on the tail end, which I guess is completely fine and true for any tech adoption cycle. +CHAD: And it's true for any product that you're...this is not just an AI company problem. I think it's a startup thing, you know, to find the early adopters and then to move on from there. But you need those early adopters, those champions who are willing to do something new before other people. +MONIK: Exactly. And, I mean, yeah, it's just surprising to me how many early adopters, even in...like, there are almost early adopters in every industry. Every business has people who just want to see something, you know, they're just excited about it, like, they're willing to take the risk. And sometimes I'm not even sure why. But, you know, there's just that element of thrill, and then also, you know, beating the market to it and things like that. +And once you feel it, you understand the adoption curve initially. Because when you see customers, you see, ah, I see every dealership. Everybody should use us. I mean, as a naive founder, I think that that's what I used to think initially. And then, you know, over time, you get a sense of like, all right, you know, these are the types of customers that you should go after. These are the people who you should talk to first. And you build that kind of muscle as a founder and, yeah, new learnings. +CHAD: So, you started with the voice assistant. But are you moving into providing other AI-driven solutions for the automotive industry? +MONIK: Right. So, as we work with more dealers, we found out, you know, more areas that can be improved and, you know, gaps in, for example, communication. I think a lot of, like, quality of service really comes from how you can, you know, communicate with your customer. And it's not just about...you could do a good job and, you know, you could just completely destroy your, you know, quality scores because you didn't communicate well enough. +And you could do a bad service and still have a great, you know, service, you know, experience by communicating well. So, I think a lot of it is key to communication, and that's our focus: using AI to make it better. Voice is one channel. There are other channels as well. And there are a lot of, you know, communication gaps within, you know, our customers, you know, business set up as well. So, we try to bridge that gap. +CHAD: So, since you're focused on communication then, you're probably still leveraging generative AI solutions. +MONIK: Oh, a lot of it is, you know, improved by that technology. Like, so I always think, like, great products usually bring in two things, right? One is a necessary evil. Let's say, you know, something that has to be done like a phone system, for example, like, you need people to call in. You need to set up all the numbers, phone trees, whatever, routing. And then, there is AI, which makes that whole process easier. +So, I think good products usually have these two things combined, where it lets you do one nasty thing, which, you know, obviously, everybody else can do in a different way. And then, there's this one exceptional thing that you can do. And then, [inaudible 27:04] together, and it makes, like, a great offering for the business. I think that's what we're working towards. +CHAD: What do you think about the way things are right now, in general? I do think that there are some companies that are saying, "Well, that great thing is the AI," but they're not necessarily solving a problem that needs to be solved in that way. +MONIK: Yeah. I mean, I think to that part, right, the hype is real. Even in my mind, I just discount, like, 40% of the things that people say about AI now. Like, I mean, I would say it's more true than not, like, 60%, sure, but, like, a rough number in my mind is just 40%, and people, like, exaggerate. But, I mean, that's not because, I guess, they're lying. It's because they're, you know, hopeful, right? Because nobody knows, like, in practice. Like, I mean, now that we've done, you know, hundreds and thousands of minutes of AI phone calls, like, that has, like, you know, added to my judgment. And I kind of know, like, you know, what is possible and what is not with even the most cutting-edge stuff there is. +I think a lot is possible. But it's unfair to say that, oh yeah, it's as good as a human, for example, right? Like, in certain use cases, that just is not true. It's a different paradigm. It's just a different design interaction that has never existed before. There's nothing human about it. You can try to force it to be as human as you want but then it is forced human. Like, it is still not natural because it just isn't. +CHAD: So, I'm getting the sense then that that might not be your north star. That might not be what you're shooting for. +MONIK: Yeah, not at all, no. At the end of the day, a tool should drive business outcomes, right? And then, to drive business outcomes, you got to understand what your customer and their users want, for example. You know, I can imagine a world where people will say, you know, when a human picks up the phone, and they're like, "No, I don't want to talk to you. Can you transfer me to a, you know, the virtual agent?" Like, it will happen, right? And it won't be natural. Like, I do not think it will be natural, and it will be different. +Because imagine, like, a human having access to all the information at the same time. Like, how would they behave, right? Like, humans behave in a serial manner, and then there is, like, some simplicity to some interactions and some complexity to others. That's not the case with, you know, all the information you have. Like, I already know, for example, if you call me, right, and I'm an AI agent for your business, I know so much about you already, right? +Like, I'm not going to act the way, you know, an agent would act who's, like, now pulling up something on the screen, and they're like, "Give me a moment," and then they're reading through your stuff. Like, I already know all the issues you've had, all the conversations you had in the past. So, now I know what's exactly wrong, and, in fact, I'll give you the answer straight up, right? Because I can kind of get ahead and figure out what you really want. +CHAD: There's an example in one of the example videos I watched or, actually, I was trying to think, would I ever want to not talk to a person, right? There's an example in one of your videos where you can see the person does exactly what I do on a call. They say their email address is their first name dot last name at gmail.com. And that's not exactly what mine is, but it's like that. +And I say that, and most of the people that I talk to on the phone when I say that they...and I think it might be because they're not on a screen that has my first name and my last name on it anymore. Oftentimes, they don't remember my name, or can't see it, or can't understand what I'm saying. But the AI has all the information, and it understood what you were saying, and it just gets it instantly. +MONIK: Exactly. Another example of that, right? Let's say, like, you called six times, right? I mean, usually what happens in call centers often is that, like, you get thrown around, different agents pick up, and then maybe the data comes there. I've heard that, like, on existing recordings of, like, humans, where it's like, "I'm calling for the sixth time. Like, do you need me to repeat the same thing again?" +And then, they go through the same flow again because that is the policy, for example. And then, they're just so annoyed. Like, with AI, there's no such thing. It's just, you know, one model that's consistent, that's listening to everything. And it's like, even before you say...like, "I see you've called for the sixth time. You know, I'm really sorry that this is happening," and, you know, whatever. Just simple things like that. +CHAD: I'm just thinking about those experiences that I've had with customer service that have been that. And, yeah, that's why I think that this is really, you know, has a lot of potential. So, how do you sort of, you know, critics of AI will often point to, like, putting people out of work, right? How do you think about that? +MONIK: Yeah. I always, like, to pin it down to, like, evidence, and, I think, at this point, I have enough to talk about this. I think what we've seen with our technology is that a lot of it leads to repurposing of existing talent. So, for example, there are, you know, business development companies that dealerships rely on for inbound and outbound calling. +Now, when we free their time up from inbound, like, that's what we focus on right now, and take off all the mundane tasks, like, the agents that they have are now free to do a lot more outbound, which actually drives more sales or, you know, gives a better experience because, you know, people are checking up on them and saying, "Okay, how was your service a week later," right? And the person feels really good. And if there's any problem, they address it, whatever, right? +So, I think there is more stuff to do than humans will ever be able to do, and our desires have no end. We will continue to pursue that. So, as you free up something...it's like a race which has no finish line. You get a little bit of lead, but that doesn't mean anything because now you still got to keep going and keep going, and that's what we've seen. So, you know, with service advisors, for example, who would get phone calls in the service department of the dealership all the time, now they don't get calls anymore, right? But they're able to spend more time with people in the store. So, they're actually able to upsell more. +So, this kind of efficiencies that you drive, like, they take off the stuff that, you know, you don't want to do all the time and is repeatable to some extent, and then you free them to do things that they couldn't have done before. So, it really is, you know, realizing that there is this endless amount of work that always needs to be done. And here, I took this off your plate, but you still have all this work to do. So, it's just repurposing of, like, talent that's been happening again and again. +And, I mean, there is, of course, that's not to say that there is not going to be a loss of job opportunities, things like that, because, you know, it's just part of creative destruction as it is called, right? Where anything new will create some sort of disruption and then, you know, destroy certain things, but then it creates more, you know, on a net basis. That's happening, yeah. +I mean, if you think about it, like, I mean, I remember I grew up in India. This was, like, 15 years ago, I don't know, maybe 10 years ago, too. There was somebody who would sit in the elevator, and their only job was to press a button. If you think about it, right? Like, I mean, is that job like, you know, what value is it driving? Of course, like, to some extent, right? And then, they came up with these elevators where you could punch in the numbers, you know, exact floors right at the beginning, and you just walk into the right elevator, and that's done. +So, I mean, that job obviously does not exist anymore or does not need to exist anymore, right? But, I mean, I don't know if anybody else in the world has an opinion on that job existing, for example. Like, it's just, over time, when we look back, it just seems, like, obvious that, you know, why were we doing that? We should be doing this other thing. So, I think it's just movement. +CHAD: Right. Yeah. I think it is uncomfortable in the moment but, you know, there is a certain trend to the world, aside from AI, aside even from technology, specifically of progress. And, you know, over time, positive comes from that, but that doesn't mean that there's not pain in the meantime. +MONIK: There is, yeah. Definitely, there is pain. And I think the real reason why people feel this a lot is sometimes, like, even I make that mistake myself of viewing yourself as, like, stationary in terms of, like, skills and learning. It's like, you are everything you've learned up till now. And, okay, if what I knew up until now is not going to be relevant tomorrow, then what am I going to do? +But the thing is that everybody has the capability to learn and improve, and, in fact, even that gets easier and easier with time because technology makes that easier. And then, people are able to do more things than they could do before, learn faster, for example. And it's important to not forget that we have that ability. You know, we can always change and improve, and, in fact, knowing so much makes us even better at knowing more. And that's why we've been able to adapt to every change in history so far; we always have. +You know, so that fear is natural. But I think, over time, when we all look back and we're like, oh my God, why were we doing that? You know, like, and we will all be doing different kinds of things. Like, that is guaranteed. That is going to happen. But that fear still exists, and I think that is what causes the pain. It's the anxiety of it. Like, really? Of course, you have to change, you know, tracks. That is very real, but it's not as painful as fear makes it. +CHAD: Well, speaking of growing, and changing, and improving, you mentioned that, you know, you and your co-founder are both technical. How have your roles changed as the company has progressed, and what have you learned [chuckles], and have you settled into any sort of roles? +MONIK: Yeah. So, I'm the CEO. My co-founder is a CTO. We both used to write code at the beginning. Now only one of us writes code. +CHAD: And I'm guessing it's not you [laughs]. +MONIK: Yeah, it's not me. Although I do miss it sometimes, but, actually, to be honest, I don't. +CHAD: [laughs] +MONIK: I feel so happy to have found that, I mean, to have realized that. But yeah, I think, basically, I think now that I understand at least B2B business to some extent, I think you always need to have a clear split of, like, build and sell. And then, of course, there's all this additional stuff that you need to do, but I think these two distinctions need to be absolutely crystal clear because both are full-time jobs. +And more than that, you need, like, owners of those spaces, and it's very hard to jump between the two. I mean, if they are solo founders, I mean, it's incredible how they do it if they're able to do both, or they rely on AI, or they rely on, you know, consultants, or contractors, or whatever. But I think those are the two roles. +And it came, I mean, I think it was just a natural progression. It's, like, when there's more work than people, I mean, that's usually a good place to be, I think, and that's how you know something is going well. You automatically assume natural roles. Because it's in that moment of, oh no, my list is, like, growing, like, quicker than you know, something, and then I need to jump in, and then you pick up the most natural and important things to you. +And then, even if you're not good at, like, you don't have an option. You have to get better at it. For example, selling, like, I never did any sales, ever. Like, I was doing machine learning and distributed systems and whatnot. But I've come to now realize that, okay, that is something that I enjoy that I think I can learn and get better at. And everything I did before, actually, even the engineering mindset helps with sales because it's just a process. So, we kind of assumed our roles when we just had too much on our plate, and we're like, "All right, you'll do this. I'll do this. Okay, fine." And then, we just talk about it, and then, all right, we keep doing it, and then now it just becomes a routine. +CHAD: Yeah, how has your team grown? +MONIK: Well, we've been two of us now, and we're hiring for a software engineer right now. So, we've been very lean. And I think...and this is also to something that Sam Altman said. I think it was him or I don't know who said that but, you know, you'll probably see the first one-person billion-dollar company. +CHAD: Yeah, I think it was, yeah. +MONIK: And I think there is some truth to it. Like, I don't know about billion, but, like, maybe a couple of million, a couple of hundred million, like, that might happen sooner. Because we've always tried to stay very, very lean, and I think we've relied on using technology wherever possible. But yeah, that's not to say...we still need people to build. And we are looking for a software engineer because, at some point, there's only so much we can do. +CHAD: Yeah. So, what would make someone a good fit for your team in that software engineering position? What are they coming to the table with? +MONIK: Everything, I wish. No, I mean, there are some exceptional people. And I think that's exactly what we're looking for is engineers with a founder's mindset because a founder's mindset is always like, you know, give us all the information. We'll make the decisions and figure out like, you know, what needs to be done. And someone who's, of course, exceptionally skilled at technology, at writing code, at building software, but also at understanding like, you know, what to build. I think that is, like, a killer combination and that is what differentiates, like, a great extraordinary engineer from anybody else. +CHAD: Well, especially since it's going to be the second developer [chuckles], you're going to have high needs and expectations for that. +MONIK: And with startups, right? It's always a little bit of chaos, and it's people who thrive in that chaos. And that's the thing, right? I've worked in, like, a bunch of startups that actually went on to become unicorns. I worked at Turing.com, which I think is...$4 billion, something like that now. But when I joined, there were, like, you know, just 10 people. And every company has problems, you know. And there's always this chaos that ensues, you know, at every stage. But there are some type of people who, like, thrive in that. They just love it. And there are some people who complain about it. +I think the ones who complain about it lose that opportunity to grow, and they don't have the mindset to see opportunity in it. And I think those are the people who are absolute amazing, you know, future founders, you know, or even, like, great founding engineers are employees like that because they like that challenge, you know. It's like, this is wrong. Let me go fix it. +CHAD: Right. And the reverse is also true. There's a point in a company's life cycle where they need a different kind of person that is more, like, stable [laughs]. +MONIK: Well, I don't know. I think I disagree with that. I think, I mean, that's when the company, you know, plateaus. Like, if you bring in more people like that, you...really, like, what is a company? It's just a collection of really smart people. The fact that OpenAI is able to do what Google cannot over the span of six years is because they just do not hire people, you know, of certain caliber, certain mindset. They just keep them out. Again, that's their policy, or even some larger companies. I think the idea is to keep that mindset going and going. It is tiring, right? But it is what drives innovation. Like, that's just the nature of it. +CHAD: Well, if what you're describing sounds like someone who's listening, or if someone's in the automotive industry and wants to learn more, where can they do that? +MONIK: Yeah, they can reach out to me, you know, my email is monik@toma.com. So, they could get to us. +CHAD: And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon at cpytel@thoughtbot.social. +Monik, thank you so much for joining me and sharing the story with me. +MONIK: Thanks, Chad. This was great. +CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening and see you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + ai in automotive, automotive customer service, voice AI technology, Toma AI, Monik Pamecha, AI phone calls, car dealership automation, automotive technology, customer experience, AI innovations, automotive industry AI, enhancing car services, AI-driven customer interactions, AI for dealerships, tech in automotive industry + + Host Chad Pytel interviews Monik Pamecha, the Co-Founder and CEO of Toma, a company specializing in AI for the automotive industry. Monik discusses how Toma automates phone calls for car dealerships, enhancing customer service and streamlining interactions. Despite advancements in digital communication, phone calls remain crucial in the automotive sector, and Toma leverages AI to improve these experiences significantly.

+ +

Monik shares his journey in the tech industry, detailing Toma's evolution from experimenting with different AI applications to focusing on voice AI. He explains the challenges and successes faced along the way, highlighting how AI technology has matured since his early work with chatbots in 2016. The conversation reveals how Toma's voice AI quickly gained user traction, validating their focus on this innovative technology.

+ +

The episode also delves into the practical implementation of Toma's AI solutions in the automotive industry. Monik emphasizes the importance of integrating AI with existing dealership software and the gradual rollout process to ensure effectiveness. He discusses the need for clear communication about AI's role in customer interactions, reflecting diverse responses across different demographics. Monik's insights provide a compelling look at the future of AI in automotive customer service.

+ + + +

Transcript:

+ +

 CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And I'm joined today by Monik Pamecha, Co-Founder and CEO of Toma, which provides AI for the automotive industry. Monik, thanks for joining me.

+ +

MONIK: Hey, Chad, thanks for having me.

+ +

CHAD: Obviously, in fact, as evidenced by the guest list that we've had over the last few months, a lot of companies are either integrating AI into their products or starting new companies. And you've been around doing AI for quite a while now. Tell us about Toma.

+ +

MONIK: Yeah. So, Toma automates phone calls for the automotive industry right now, and we build a lot of different AI products as well. It's an interesting market, but one of the leading users of phone calls for doing business. So, a lot of the business, which is buying cars, you know, the first touch happens over the phone, you know, people bringing in their cars for service, getting updates, and all that, like, mostly happens over the phone, even though you have had websites and apps and all of these around.

+ +

And to give you, like, an idea of scale, like, there are 290 million cars in the U.S. alone, which is, like, about 90% of the population has at least one car. So, scale is massive, and Toma is making that experience of getting service and just dealing with anything related to automotive, like, 100 times better.

+ +

CHAD: So, I would encourage people to go to the website and check it out, because, I have to admit, I was a little skeptical, at first, about how good the phone call could actually be. And I was impressed by how natural it was, how it was able to respond in the video demos that I saw. So, how did you know that this was going to be possible?

+ +

MONIK: I think a lot of it comes from our own experiences, I mean, not with automotive, but with technology. So, I've been in tech for a long time. I mean, I started writing code when I was, I think, 11 or 12, a similar story for my co-founders as well. But I've been doing machine learning research as well in the past. In fact, this was in 2016 when I wrote a paper on this as well, and we built a chatbot that was based on generative models. And, at the time, in 2016, it was really funky. Like, Google had come up with something called Sequence to Sequence, and we were using that to train it on a little bit of data that we had, and we had something that kind of worked.

+ +

And, at the time, I was thinking that, I mean, when you were working with that, you'd see it, like, go off the rails and, like, do something really stupid. It couldn't even get grammar right. And, at the time, I saw all the holes that I was like, if somebody plugged these, like, you know, this would be phenomenal. Like, this is what it takes for it to work, you know, these are the places, more from a practical experience, right? Like, if you had to take it to production, like, what would you need to fix?

+ +

And then, six years later, I see that things actually started picking up, right, like, they actually fixed all those holes. And it came back to me, and I was like, all right, this is the time. You know, those were the issues. They're all fixed. Now you can go ahead and build. So, I think a lot of it came from experience as to like, all right, this is what we should build, or this is why we should build, like, in terms of the technology. But we didn't really arrive at this idea, so to speak, you know, at least as a founding team. It was a lot of pivots.

+ +

CHAD: What was the original sort of idea that you said, okay, we're going to start a company to do this?

+ +

MONIK: Well, that was very different from this very, very different. So, my co-founder and I, like, most founders, like, the first thing they do is they try to look for problems that they themselves have. And we're like, huh, looks like...what do we have in common? We have some chronic conditions, and we've used diet to, you know, manage them. So, maybe let's build a tool to help, you know, patients manage conditions with, you know, diet recommendations. And we spent six months on that, and it went absolutely nowhere.

+ +

Also, I think consumer products are just different. They require a different kind of thinking. But, you know, we were just trying to throw something on the wall and pray it sticks. And, you know, it was honestly pretty miserable because we got banned on a bunch of communities on Reddit and Facebook trying to promote it. And, like, all the people who tried our product they just never came back again, and, you know, things like that when you have something that people don't want, right? So, we see that side.

+ +

I mean, and after that, we go ahead and we try to do...I think it was during it, I don't know, like, when you get a sense of, like, something's not going to work, where, like, then we realized maybe we should stick to what we know best, which is, you know, we're both technical. So, maybe we should do something that's, you know, more relying on those skills than something entirely different, which I think Y Combinator calls it founder-market fit. I think that's also very true. Of course, you can, like, build something for a business you know nothing about, but there must be some compatibility.

+ +

So, yeah, we started with that, kept on experimenting. And then, I think, at some point, we were so annoyed that we made, you know, a list on Google Sheets. And we're like, all right, let's just, you know, vomit out 10 ideas that we have had, and let's write them all, and let's go after them one by one. Let's spend two weeks until we hit something that, you know, maybe we think has legs. And the third idea or the fourth idea on that was building something with voice AI. And, at the time, even that was, like, just a horizontal platform. That was it. All right, so we go ahead and commit to that.

+ +

So, if we go through the list, try the first two or three ideas, I think the first thing was...then we went on the other extreme where we're like, all right, let's do something we do all day long, which is, as engineers, we are on call. So, you know, even at, I don't know, 2:00 a.m. in the night if your system is down, you get a pager on your phone saying, "Get on the computer and fix it." And we're like, how could we make that better? That was the first thing on that list. We spent some time trying to do it and, again, we kind of get that feeling.

+ +

I think the more you fail, I guess, the better you get at detecting failure. I don't know about success but failure for sure it works like that. I think the third or the fourth idea was voice AI, and then we go ahead. We hack a prototype over a weekend and then put it out on...again, the communities that we know how to market were, like, Facebook groups and Reddit. And it picks up. Like, within, like, 3 days, we had 200 demo calls set up. And that just blew our minds because having been on the other side, we're like, oh, this is what it feels like when people kind of want something, what you have. I mean, it's still not clear, right? But --

+ +

CHAD: And you put it out there as automated voice assistant for businesses?

+ +

MONIK: No, actually what we did [laughs], I mean, nobody will want to click that if you put it like that [laughter]. You know, just out of curiosity, I was like, "Hey, you know, I've built this thing. It does this, you know, what do you think? Do you think this has any use for you?" And that's it. Like, people are, you know, messaging me nonstop, like, DMing me that, "Can you please share it with me? You know, I run this business. This might be helpful."

+ +

It was, like, more genuine. Like, I was just exploring, but, you know, that was a question that I posed. And that had, like, so many people show up, and they're like, "How about you just give us that and we can make money off of this?" And then, we started, you know, digging deeper, and we're like, oh, okay, it looks like you have so many manual processes and across industries. So, we had, like, some people from healthcare, some people from, like, you know, MLMs, multi-level marketing, so many different industries, optometrists, some in construction.

+ +

Anyway, so we're, like, thinking at that point, huh, okay. Maybe there is something here. Again, no mention of automotive, no mention of dealerships, nothing. We had a single dealership then. And I would say this was, like, about six months. I don't even know how many months ago, but, like, a couple of months ago. I think, at the time, is when we applied to Y Combinator as well.

+ +

CHAD: So, you applied to Y Combinator with the voice idea.

+ +

MONIK: Right. And we put something out there. I forget if it was the healthcare idea or the voice idea, but it's probably one of the two. I mean, that's also the other thing about Y Combinator. I think they don't really focus on ideas as much as they just focus on teams, which I think is probably the best practice. You know, we pivoted again [laughs].

+ +

But yeah, so we did voice AI, and then spent some time just trying to do everything, right? Trying to build a horizontal layer for voice, where building assistance for all kinds of businesses. And, you know, one of the businesses, at the time, was a dealership. I always like to think of this as an arranged marriage, where, you know, we have the customer. We kind of work through it --

+ +

CHAD: So, you had an actual dealership that you were partnered with as sort of a expert in the industry?

+ +

MONIK: Our first customer, right. And they were very progressive dealers, so they're always trying new things. And, at the time, we were working with a bank. We were working with some healthcare locations as well. We had some construction industry... whatnot. And we were going crazy trying to build something because everybody had these different requirements. And then, in practice, like, if you push AI out in the wild, to make it work, you need a lot of things, like deep domain expertise being one of them.

+ +

So, that realization is happening, you know, where we're coming to terms with that. And, at the same time, it works really well for the dealership, and they bring another customer. And they're like, "Oh, they also want to use it," and we're like, "Okay, sure. We'll turn it on." Then we do it. And then, it works again. And then, they bring more customers. And then, we're like, wait a minute, you know, like, we're not doing any outreach. We're not pushing out anything, and it seems like customers want it. And then, there are these other places where we're struggling so much.

+ +

Like, even with healthcare, you know, the regulations in banking and healthcare they slow down, you know, any sort of, like, AI implementations. So, even that world was very different with the automotive space. And you kind of do more of it and then you're like, oh, okay, looks like there is something here, and then we just decide to double down on that space. And then, we go further deep in and you realize, oh --

+ +

CHAD: Did Y Combinator...that can be a difficult decision for founders to make. So, did being in Y Combinator help you sort of give you the push to make that kind of bold decision?

+ +

MONIK: At least from our experience, it's always been that they're, like, get to the truth very quickly, whatever it is, and then make a decision. Do not delay it. I think we were, in fact, slow to do that. I think they were probably pushing people to do it more because we saw companies pivot in our batch, like, two times, three times right before demo day, which is the end of the program. Like, two weeks before, they just completely changed the company, and that's completely okay.

+ +

CHAD: So, how does an implementation actually happen? How does it roll out to a new customer?

+ +

MONIK: I mean, this is also very new, right? I think as you come across new customers, you have to adapt the process. But the essence of it is that you first have some data to start, which is, for example, for us, we work with a bunch of call recordings because a lot of our customers are already recording a lot of their calls. So, that gives you, like, some data as to what the experience is like today. Then the next thing is you get an idea of what you know your customers want the experience to be like. And then, you're basically now figuring out the delta between the two.

+ +

And then, you're configuring the AI agents, making sure, testing it. And then, you have, like, a period of, like, a week or so where you get through all of that. Then you work through integrations with existing softwares. That also, by the way, is another, like, I would say automotive is a sleeping giant. Like, an auto dealership, on average, like, per month will be spending $50, 000 on software.

+ +

CHAD: Wow.

+ +

MONIK: Because the whole business runs on software—everything starting from sales, inventory, parts, service, everything, repair orders—all of it comes through that.

+ +

CHAD: Now, is there a single common platform that a lot of dealers are using?

+ +

MONIK: Unfortunately, no. There are some major players; CDK Global is one of them, which actually was hacked recently. And it's in, like, over 15, 000 dealerships, and all of them shut down.

+ +

CHAD: Wow.

+ +

MONIK: Like, they just couldn't do any business, and they had to come up with creative workarounds. So, it was pretty painful, kind of, like, a COVID, you know, COVID moment for them. And then, yeah, we've been trying to help our dealers, whoever used that software, to, you know, again, come out with workarounds, where the AI is actually capturing all the information. And, you know, instead of dumping it into that system, it's, you know, finding workarounds on how to get it to our dealers. But yeah, so you integrate with them. That is, like, another major step. And they're, you know, they're not the most tech-forward companies so, you know, that can be a little challenging.

+ +

CHAD: Right. So, they use a lot of software, but they're not necessarily tech for...they probably don't have big IT departments and that kind of thing. And then, the users are probably non-technical.

+ +

MONIK: Correct. Yeah. The thing about dealers, I think, is that they're so plugged into the business, like, they know everything that is happening in the business. Everybody knows what the bottom line looks, what really will move the needle, what is a good customer experience. They may not be technical, but I don't think it even matters. That's the thing.

+ +

But yeah, we were talking about, like, the process, so it takes a couple of weeks So, you do, you know, you get all the information from them as to what needs to be done. You integrate into the systems. And then, the next thing that you do is you start slowly, where, for example, when we start taking phone calls for them, we initially start with off hours and overflow. So, when nobody's able to pick up a phone call, we get the phone calls. And that's how you get, like, some training data at the beginning in a safe manner.

+ +

And then, as the volume increases, you know, you get more confident, and you roll it out to a larger audience. But I think the key thing here is it has to be a gradual process because, even for the customer, it's something so new, like, to have a full-fledged conversation. Like, you can have a phone tree where it's, like, press one; press two. You're used to that kind of stuff, and that's been around for 15 years, and it still is, you know. And it is not the most natural thing, but it continues to exist. So, this is the next, you know, natural evolution of that interface where it's more free-flowing and, you know, less annoying.

+ +

CHAD: Do all of your customers...when the AI agent answers, does it say it's an AI agent?

+ +

MONIK: I mean, our recommendation is to always say that. I mean, it's up to the customer, eventually, if they want to say that or not. And, in fact, it is pretty interesting. Demographics make a huge difference. Like, we're live in, you know, all the states, not all but I would say, like, all the major states. And the way people behave with AI agents is so different, you know, Florida, and Michigan, and California, like, we see the call quality. We see the metrics. We see how annoyed people are or how happy they are and things like that. The way they talk is so different.

+ +

And one of the parameters in that is actually, you know, letting them know that it is an AI or not as well. So, we tweak that based on, you know, where we are. But for the most part, we always say that because we want to set the expectations, right? Because, initially, when we didn't, the most popular question on the call was like, "Are you a human?"

+ +

CHAD: [laughs]

+ +

MONIK: And the fact that people are asking it was also pretty insane, right?

+ +

CHAD: Right. They could sort of tell that something was different.

+ +

MONIK: Yeah, if you have, like, a long enough conversation because, obviously, it's not human, right? And then, you go, like, five turns into the conversation, and then you realize, okay, it sounds like a human, like, you know, it's speaking pretty quickly. It's giving me the kind of answers I want. But, like, this thing is strange because, you know, humans have a personality now.

+ +

Like, with AI, like, a lot of the systems, I mean, you can build personality into it, but it still doesn't have a personality, like, the truth is still that. And it does show up, you know, in interesting ways. And, of course, there can be, you know, some sort of mechanistic issues, you know, like, whatever, right, like, what the customer is really used to and then what you actually say. I think the best practice is to almost always declare, like, it's an AI. And that has improved call quality significantly.

+ +

MID-ROLL AD:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

CHAD: Did you train your own models?

+ +

MONIK: Yeah, we collected enough data to be able to do that, and we have trained a lot of different components and different models. So, when you think of it, there's not, like, one model that does the whole thing. You have, like, a lot of these small, medium, and large models that do different parts. So, the voice and speech are, let's say, two components.

+ +

I think the brain of the agent is really the thing that needs the most amount of training because, you know, text to speech and voice, I mean, they have, like, you know, some limits and then, some, you know, business return. Like, after some point, like, there's not really much value to be gained there because if you can transcribe everything, you know, to a certain level of accuracy, all the regions change, you know, accents change. You can always improve. Then it's just expanding scope.

+ +

But really, with the brain of the agent, you have multiple different models that actually interact with each other, and they're not just LLMs or generative models. You have a lot of different types of things that are going. You know, you're looking up information. You are, you know, validating something. You're making sure if, you know, this is compliant with what, you know, your company's tone is, all of these happening at the same time. And then, these are the different things that you actually really need to train because that's so specific to, you know, the type of business that is happening.

+ +

CHAD: So, are you also doing your own hosting of the models, or are you using a cloud provider for that?

+ +

MONIK: Yeah, we use cloud providers. I think having a small team it's insane. I mean, you can host custom models on a lot of these providers now. And then, a lot of them even offer services for you to, like, train and, you know, they take care of the infrastructure as well. I think it's a good thing to rely on it if you're lean and small. There's only so much a few people [chuckles] can do and focus on.

+ +

CHAD: What are you most focused on right now, either from a business or a product perspective, or, you know, where's your area of biggest risk?

+ +

MONIK: Of course, there is always, you know, risk of competition. And I guess the real question is, like, where...a lot of popular AI companies get asked this as well, right? Like, what is your moat, right? And then, I mean, I think that is the most obvious risk, right? Where, like, what is stopping anybody else from doing what you're doing, right? And there are certain parts of it, which, you know, you can de-risk. Like, having data and having proprietary data is, like, one of the biggest factors in this, right, of de-risking this.

+ +

I mean, there's also like, you know, the risk of, let's say, especially in our industry, is, like, taking technology to an industry where, you know, consumers are not pro-technology. You know, they don't want to jump at the best thing that there is, right, especially customer service generally suffers from that, right? Like, people anytime they hear a bot or something and they're like, "Ah, representative agent." So, there's, like, some underlying risk in, you know, human tendencies as to what they want.

+ +

But, again, to think about it, like, you know, IVRs, which are these interactive voice response systems, they've been around for so long. Nothing about it is natural. It is completely alien to how we interact, but they've been around for so long. So, a lot of times, like, this innovation is actually pushed down from the business to the consumer and not the other way around. It may not be the best experience. It's getting there.

+ +

So, it's that battle between the two, which I think can delay implementations. You know, some people, like, one of our customers, at one point, we went through the entire deal. And I think the owner of the dealership group just said, "I don't believe in AI." Now, you know, like, it's pretty hard, right? Like, you have the metrics. You have the numbers. You're generating value, but the belief is strongly held. And then, at that point, you know, there's nothing you can do.

+ +

CHAD: Do you know why they were saying that? Was it like, I don't believe it as in I don't think it can do it, or I don't believe in it as in, like, it's against my ethics, or something like that?

+ +

MONIK: I feel like it's probably because they've been burned by past experiences of AI. Like, I think chatbots have been around for so long, and a lot of people in the automotive industry have used them. Now, they used to suck. And as I remember in 2016 as well, you know, over the few years that came, like, it was still pretty terrible. So, I think it's some muscle memory from that.

+ +

And then, also, I think AI has been hyped a lot, and I feel like people just generally discount anything that is hyped. And the opinion is that let's just wait for the dust to settle, and then we'll just pick the winners. So, it's also possible, right? On the adoption curve, like, there's you just hit some people who are probably not on the early or even the mid, right? Maybe on the tail end, which I guess is completely fine and true for any tech adoption cycle.

+ +

CHAD: And it's true for any product that you're...this is not just an AI company problem. I think it's a startup thing, you know, to find the early adopters and then to move on from there. But you need those early adopters, those champions who are willing to do something new before other people.

+ +

MONIK: Exactly. And, I mean, yeah, it's just surprising to me how many early adopters, even in...like, there are almost early adopters in every industry. Every business has people who just want to see something, you know, they're just excited about it, like, they're willing to take the risk. And sometimes I'm not even sure why. But, you know, there's just that element of thrill, and then also, you know, beating the market to it and things like that.

+ +

And once you feel it, you understand the adoption curve initially. Because when you see customers, you see, ah, I see every dealership. Everybody should use us. I mean, as a naive founder, I think that that's what I used to think initially. And then, you know, over time, you get a sense of like, all right, you know, these are the types of customers that you should go after. These are the people who you should talk to first. And you build that kind of muscle as a founder and, yeah, new learnings.

+ +

CHAD: So, you started with the voice assistant. But are you moving into providing other AI-driven solutions for the automotive industry?

+ +

MONIK: Right. So, as we work with more dealers, we found out, you know, more areas that can be improved and, you know, gaps in, for example, communication. I think a lot of, like, quality of service really comes from how you can, you know, communicate with your customer. And it's not just about...you could do a good job and, you know, you could just completely destroy your, you know, quality scores because you didn't communicate well enough.

+ +

And you could do a bad service and still have a great, you know, service, you know, experience by communicating well. So, I think a lot of it is key to communication, and that's our focus: using AI to make it better. Voice is one channel. There are other channels as well. And there are a lot of, you know, communication gaps within, you know, our customers, you know, business set up as well. So, we try to bridge that gap.

+ +

CHAD: So, since you're focused on communication then, you're probably still leveraging generative AI solutions.

+ +

MONIK: Oh, a lot of it is, you know, improved by that technology. Like, so I always think, like, great products usually bring in two things, right? One is a necessary evil. Let's say, you know, something that has to be done like a phone system, for example, like, you need people to call in. You need to set up all the numbers, phone trees, whatever, routing. And then, there is AI, which makes that whole process easier.

+ +

So, I think good products usually have these two things combined, where it lets you do one nasty thing, which, you know, obviously, everybody else can do in a different way. And then, there's this one exceptional thing that you can do. And then, [inaudible 27:04] together, and it makes, like, a great offering for the business. I think that's what we're working towards.

+ +

CHAD: What do you think about the way things are right now, in general? I do think that there are some companies that are saying, "Well, that great thing is the AI," but they're not necessarily solving a problem that needs to be solved in that way.

+ +

MONIK: Yeah. I mean, I think to that part, right, the hype is real. Even in my mind, I just discount, like, 40% of the things that people say about AI now. Like, I mean, I would say it's more true than not, like, 60%, sure, but, like, a rough number in my mind is just 40%, and people, like, exaggerate. But, I mean, that's not because, I guess, they're lying. It's because they're, you know, hopeful, right? Because nobody knows, like, in practice. Like, I mean, now that we've done, you know, hundreds and thousands of minutes of AI phone calls, like, that has, like, you know, added to my judgment. And I kind of know, like, you know, what is possible and what is not with even the most cutting-edge stuff there is.

+ +

I think a lot is possible. But it's unfair to say that, oh yeah, it's as good as a human, for example, right? Like, in certain use cases, that just is not true. It's a different paradigm. It's just a different design interaction that has never existed before. There's nothing human about it. You can try to force it to be as human as you want but then it is forced human. Like, it is still not natural because it just isn't.

+ +

CHAD: So, I'm getting the sense then that that might not be your north star. That might not be what you're shooting for.

+ +

MONIK: Yeah, not at all, no. At the end of the day, a tool should drive business outcomes, right? And then, to drive business outcomes, you got to understand what your customer and their users want, for example. You know, I can imagine a world where people will say, you know, when a human picks up the phone, and they're like, "No, I don't want to talk to you. Can you transfer me to a, you know, the virtual agent?" Like, it will happen, right? And it won't be natural. Like, I do not think it will be natural, and it will be different.

+ +

Because imagine, like, a human having access to all the information at the same time. Like, how would they behave, right? Like, humans behave in a serial manner, and then there is, like, some simplicity to some interactions and some complexity to others. That's not the case with, you know, all the information you have. Like, I already know, for example, if you call me, right, and I'm an AI agent for your business, I know so much about you already, right?

+ +

Like, I'm not going to act the way, you know, an agent would act who's, like, now pulling up something on the screen, and they're like, "Give me a moment," and then they're reading through your stuff. Like, I already know all the issues you've had, all the conversations you had in the past. So, now I know what's exactly wrong, and, in fact, I'll give you the answer straight up, right? Because I can kind of get ahead and figure out what you really want.

+ +

CHAD: There's an example in one of the example videos I watched or, actually, I was trying to think, would I ever want to not talk to a person, right? There's an example in one of your videos where you can see the person does exactly what I do on a call. They say their email address is their first name dot last name at gmail.com. And that's not exactly what mine is, but it's like that.

+ +

And I say that, and most of the people that I talk to on the phone when I say that they...and I think it might be because they're not on a screen that has my first name and my last name on it anymore. Oftentimes, they don't remember my name, or can't see it, or can't understand what I'm saying. But the AI has all the information, and it understood what you were saying, and it just gets it instantly.

+ +

MONIK: Exactly. Another example of that, right? Let's say, like, you called six times, right? I mean, usually what happens in call centers often is that, like, you get thrown around, different agents pick up, and then maybe the data comes there. I've heard that, like, on existing recordings of, like, humans, where it's like, "I'm calling for the sixth time. Like, do you need me to repeat the same thing again?"

+ +

And then, they go through the same flow again because that is the policy, for example. And then, they're just so annoyed. Like, with AI, there's no such thing. It's just, you know, one model that's consistent, that's listening to everything. And it's like, even before you say...like, "I see you've called for the sixth time. You know, I'm really sorry that this is happening," and, you know, whatever. Just simple things like that.

+ +

CHAD: I'm just thinking about those experiences that I've had with customer service that have been that. And, yeah, that's why I think that this is really, you know, has a lot of potential. So, how do you sort of, you know, critics of AI will often point to, like, putting people out of work, right? How do you think about that?

+ +

MONIK: Yeah. I always, like, to pin it down to, like, evidence, and, I think, at this point, I have enough to talk about this. I think what we've seen with our technology is that a lot of it leads to repurposing of existing talent. So, for example, there are, you know, business development companies that dealerships rely on for inbound and outbound calling.

+ +

Now, when we free their time up from inbound, like, that's what we focus on right now, and take off all the mundane tasks, like, the agents that they have are now free to do a lot more outbound, which actually drives more sales or, you know, gives a better experience because, you know, people are checking up on them and saying, "Okay, how was your service a week later," right? And the person feels really good. And if there's any problem, they address it, whatever, right?

+ +

So, I think there is more stuff to do than humans will ever be able to do, and our desires have no end. We will continue to pursue that. So, as you free up something...it's like a race which has no finish line. You get a little bit of lead, but that doesn't mean anything because now you still got to keep going and keep going, and that's what we've seen. So, you know, with service advisors, for example, who would get phone calls in the service department of the dealership all the time, now they don't get calls anymore, right? But they're able to spend more time with people in the store. So, they're actually able to upsell more.

+ +

So, this kind of efficiencies that you drive, like, they take off the stuff that, you know, you don't want to do all the time and is repeatable to some extent, and then you free them to do things that they couldn't have done before. So, it really is, you know, realizing that there is this endless amount of work that always needs to be done. And here, I took this off your plate, but you still have all this work to do. So, it's just repurposing of, like, talent that's been happening again and again.

+ +

And, I mean, there is, of course, that's not to say that there is not going to be a loss of job opportunities, things like that, because, you know, it's just part of creative destruction as it is called, right? Where anything new will create some sort of disruption and then, you know, destroy certain things, but then it creates more, you know, on a net basis. That's happening, yeah.

+ +

I mean, if you think about it, like, I mean, I remember I grew up in India. This was, like, 15 years ago, I don't know, maybe 10 years ago, too. There was somebody who would sit in the elevator, and their only job was to press a button. If you think about it, right? Like, I mean, is that job like, you know, what value is it driving? Of course, like, to some extent, right? And then, they came up with these elevators where you could punch in the numbers, you know, exact floors right at the beginning, and you just walk into the right elevator, and that's done.

+ +

So, I mean, that job obviously does not exist anymore or does not need to exist anymore, right? But, I mean, I don't know if anybody else in the world has an opinion on that job existing, for example. Like, it's just, over time, when we look back, it just seems, like, obvious that, you know, why were we doing that? We should be doing this other thing. So, I think it's just movement.

+ +

CHAD: Right. Yeah. I think it is uncomfortable in the moment but, you know, there is a certain trend to the world, aside from AI, aside even from technology, specifically of progress. And, you know, over time, positive comes from that, but that doesn't mean that there's not pain in the meantime.

+ +

MONIK: There is, yeah. Definitely, there is pain. And I think the real reason why people feel this a lot is sometimes, like, even I make that mistake myself of viewing yourself as, like, stationary in terms of, like, skills and learning. It's like, you are everything you've learned up till now. And, okay, if what I knew up until now is not going to be relevant tomorrow, then what am I going to do?

+ +

But the thing is that everybody has the capability to learn and improve, and, in fact, even that gets easier and easier with time because technology makes that easier. And then, people are able to do more things than they could do before, learn faster, for example. And it's important to not forget that we have that ability. You know, we can always change and improve, and, in fact, knowing so much makes us even better at knowing more. And that's why we've been able to adapt to every change in history so far; we always have.

+ +

You know, so that fear is natural. But I think, over time, when we all look back and we're like, oh my God, why were we doing that? You know, like, and we will all be doing different kinds of things. Like, that is guaranteed. That is going to happen. But that fear still exists, and I think that is what causes the pain. It's the anxiety of it. Like, really? Of course, you have to change, you know, tracks. That is very real, but it's not as painful as fear makes it.

+ +

CHAD: Well, speaking of growing, and changing, and improving, you mentioned that, you know, you and your co-founder are both technical. How have your roles changed as the company has progressed, and what have you learned [chuckles], and have you settled into any sort of roles?

+ +

MONIK: Yeah. So, I'm the CEO. My co-founder is a CTO. We both used to write code at the beginning. Now only one of us writes code.

+ +

CHAD: And I'm guessing it's not you [laughs].

+ +

MONIK: Yeah, it's not me. Although I do miss it sometimes, but, actually, to be honest, I don't.

+ +

CHAD: [laughs]

+ +

MONIK: I feel so happy to have found that, I mean, to have realized that. But yeah, I think, basically, I think now that I understand at least B2B business to some extent, I think you always need to have a clear split of, like, build and sell. And then, of course, there's all this additional stuff that you need to do, but I think these two distinctions need to be absolutely crystal clear because both are full-time jobs.

+ +

And more than that, you need, like, owners of those spaces, and it's very hard to jump between the two. I mean, if they are solo founders, I mean, it's incredible how they do it if they're able to do both, or they rely on AI, or they rely on, you know, consultants, or contractors, or whatever. But I think those are the two roles.

+ +

And it came, I mean, I think it was just a natural progression. It's, like, when there's more work than people, I mean, that's usually a good place to be, I think, and that's how you know something is going well. You automatically assume natural roles. Because it's in that moment of, oh no, my list is, like, growing, like, quicker than you know, something, and then I need to jump in, and then you pick up the most natural and important things to you.

+ +

And then, even if you're not good at, like, you don't have an option. You have to get better at it. For example, selling, like, I never did any sales, ever. Like, I was doing machine learning and distributed systems and whatnot. But I've come to now realize that, okay, that is something that I enjoy that I think I can learn and get better at. And everything I did before, actually, even the engineering mindset helps with sales because it's just a process. So, we kind of assumed our roles when we just had too much on our plate, and we're like, "All right, you'll do this. I'll do this. Okay, fine." And then, we just talk about it, and then, all right, we keep doing it, and then now it just becomes a routine.

+ +

CHAD: Yeah, how has your team grown?

+ +

MONIK: Well, we've been two of us now, and we're hiring for a software engineer right now. So, we've been very lean. And I think...and this is also to something that Sam Altman said. I think it was him or I don't know who said that but, you know, you'll probably see the first one-person billion-dollar company.

+ +

CHAD: Yeah, I think it was, yeah.

+ +

MONIK: And I think there is some truth to it. Like, I don't know about billion, but, like, maybe a couple of million, a couple of hundred million, like, that might happen sooner. Because we've always tried to stay very, very lean, and I think we've relied on using technology wherever possible. But yeah, that's not to say...we still need people to build. And we are looking for a software engineer because, at some point, there's only so much we can do.

+ +

CHAD: Yeah. So, what would make someone a good fit for your team in that software engineering position? What are they coming to the table with?

+ +

MONIK: Everything, I wish. No, I mean, there are some exceptional people. And I think that's exactly what we're looking for is engineers with a founder's mindset because a founder's mindset is always like, you know, give us all the information. We'll make the decisions and figure out like, you know, what needs to be done. And someone who's, of course, exceptionally skilled at technology, at writing code, at building software, but also at understanding like, you know, what to build. I think that is, like, a killer combination and that is what differentiates, like, a great extraordinary engineer from anybody else.

+ +

CHAD: Well, especially since it's going to be the second developer [chuckles], you're going to have high needs and expectations for that.

+ +

MONIK: And with startups, right? It's always a little bit of chaos, and it's people who thrive in that chaos. And that's the thing, right? I've worked in, like, a bunch of startups that actually went on to become unicorns. I worked at Turing.com, which I think is...$4 billion, something like that now. But when I joined, there were, like, you know, just 10 people. And every company has problems, you know. And there's always this chaos that ensues, you know, at every stage. But there are some type of people who, like, thrive in that. They just love it. And there are some people who complain about it.

+ +

I think the ones who complain about it lose that opportunity to grow, and they don't have the mindset to see opportunity in it. And I think those are the people who are absolute amazing, you know, future founders, you know, or even, like, great founding engineers are employees like that because they like that challenge, you know. It's like, this is wrong. Let me go fix it.

+ +

CHAD: Right. And the reverse is also true. There's a point in a company's life cycle where they need a different kind of person that is more, like, stable [laughs].

+ +

MONIK: Well, I don't know. I think I disagree with that. I think, I mean, that's when the company, you know, plateaus. Like, if you bring in more people like that, you...really, like, what is a company? It's just a collection of really smart people. The fact that OpenAI is able to do what Google cannot over the span of six years is because they just do not hire people, you know, of certain caliber, certain mindset. They just keep them out. Again, that's their policy, or even some larger companies. I think the idea is to keep that mindset going and going. It is tiring, right? But it is what drives innovation. Like, that's just the nature of it.

+ +

CHAD: Well, if what you're describing sounds like someone who's listening, or if someone's in the automotive industry and wants to learn more, where can they do that?

+ +

MONIK: Yeah, they can reach out to me, you know, my email is monik@toma.com. So, they could get to us.

+ +

CHAD: And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon at cpytel@thoughtbot.social.

+ +

Monik, thank you so much for joining me and sharing the story with me.

+ +

MONIK: Thanks, Chad. This was great.

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening and see you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Chad Pytel interviews Monik Pamecha, the Co-Founder and CEO of Toma, a company specializing in AI for the automotive industry. Monik discusses how Toma automates phone calls for car dealerships, enhancing customer service and streamlining interactions. Despite advancements in digital communication, phone calls remain crucial in the automotive sector, and Toma leverages AI to improve these experiences significantly.

+ +

Monik shares his journey in the tech industry, detailing Toma's evolution from experimenting with different AI applications to focusing on voice AI. He explains the challenges and successes faced along the way, highlighting how AI technology has matured since his early work with chatbots in 2016. The conversation reveals how Toma's voice AI quickly gained user traction, validating their focus on this innovative technology.

+ +

The episode also delves into the practical implementation of Toma's AI solutions in the automotive industry. Monik emphasizes the importance of integrating AI with existing dealership software and the gradual rollout process to ensure effectiveness. He discusses the need for clear communication about AI's role in customer interactions, reflecting diverse responses across different demographics. Monik's insights provide a compelling look at the future of AI in automotive customer service.

+ + + +

Transcript:

+ +

 CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And I'm joined today by Monik Pamecha, Co-Founder and CEO of Toma, which provides AI for the automotive industry. Monik, thanks for joining me.

+ +

MONIK: Hey, Chad, thanks for having me.

+ +

CHAD: Obviously, in fact, as evidenced by the guest list that we've had over the last few months, a lot of companies are either integrating AI into their products or starting new companies. And you've been around doing AI for quite a while now. Tell us about Toma.

+ +

MONIK: Yeah. So, Toma automates phone calls for the automotive industry right now, and we build a lot of different AI products as well. It's an interesting market, but one of the leading users of phone calls for doing business. So, a lot of the business, which is buying cars, you know, the first touch happens over the phone, you know, people bringing in their cars for service, getting updates, and all that, like, mostly happens over the phone, even though you have had websites and apps and all of these around.

+ +

And to give you, like, an idea of scale, like, there are 290 million cars in the U.S. alone, which is, like, about 90% of the population has at least one car. So, scale is massive, and Toma is making that experience of getting service and just dealing with anything related to automotive, like, 100 times better.

+ +

CHAD: So, I would encourage people to go to the website and check it out, because, I have to admit, I was a little skeptical, at first, about how good the phone call could actually be. And I was impressed by how natural it was, how it was able to respond in the video demos that I saw. So, how did you know that this was going to be possible?

+ +

MONIK: I think a lot of it comes from our own experiences, I mean, not with automotive, but with technology. So, I've been in tech for a long time. I mean, I started writing code when I was, I think, 11 or 12, a similar story for my co-founders as well. But I've been doing machine learning research as well in the past. In fact, this was in 2016 when I wrote a paper on this as well, and we built a chatbot that was based on generative models. And, at the time, in 2016, it was really funky. Like, Google had come up with something called Sequence to Sequence, and we were using that to train it on a little bit of data that we had, and we had something that kind of worked.

+ +

And, at the time, I was thinking that, I mean, when you were working with that, you'd see it, like, go off the rails and, like, do something really stupid. It couldn't even get grammar right. And, at the time, I saw all the holes that I was like, if somebody plugged these, like, you know, this would be phenomenal. Like, this is what it takes for it to work, you know, these are the places, more from a practical experience, right? Like, if you had to take it to production, like, what would you need to fix?

+ +

And then, six years later, I see that things actually started picking up, right, like, they actually fixed all those holes. And it came back to me, and I was like, all right, this is the time. You know, those were the issues. They're all fixed. Now you can go ahead and build. So, I think a lot of it came from experience as to like, all right, this is what we should build, or this is why we should build, like, in terms of the technology. But we didn't really arrive at this idea, so to speak, you know, at least as a founding team. It was a lot of pivots.

+ +

CHAD: What was the original sort of idea that you said, okay, we're going to start a company to do this?

+ +

MONIK: Well, that was very different from this very, very different. So, my co-founder and I, like, most founders, like, the first thing they do is they try to look for problems that they themselves have. And we're like, huh, looks like...what do we have in common? We have some chronic conditions, and we've used diet to, you know, manage them. So, maybe let's build a tool to help, you know, patients manage conditions with, you know, diet recommendations. And we spent six months on that, and it went absolutely nowhere.

+ +

Also, I think consumer products are just different. They require a different kind of thinking. But, you know, we were just trying to throw something on the wall and pray it sticks. And, you know, it was honestly pretty miserable because we got banned on a bunch of communities on Reddit and Facebook trying to promote it. And, like, all the people who tried our product they just never came back again, and, you know, things like that when you have something that people don't want, right? So, we see that side.

+ +

I mean, and after that, we go ahead and we try to do...I think it was during it, I don't know, like, when you get a sense of, like, something's not going to work, where, like, then we realized maybe we should stick to what we know best, which is, you know, we're both technical. So, maybe we should do something that's, you know, more relying on those skills than something entirely different, which I think Y Combinator calls it founder-market fit. I think that's also very true. Of course, you can, like, build something for a business you know nothing about, but there must be some compatibility.

+ +

So, yeah, we started with that, kept on experimenting. And then, I think, at some point, we were so annoyed that we made, you know, a list on Google Sheets. And we're like, all right, let's just, you know, vomit out 10 ideas that we have had, and let's write them all, and let's go after them one by one. Let's spend two weeks until we hit something that, you know, maybe we think has legs. And the third idea or the fourth idea on that was building something with voice AI. And, at the time, even that was, like, just a horizontal platform. That was it. All right, so we go ahead and commit to that.

+ +

So, if we go through the list, try the first two or three ideas, I think the first thing was...then we went on the other extreme where we're like, all right, let's do something we do all day long, which is, as engineers, we are on call. So, you know, even at, I don't know, 2:00 a.m. in the night if your system is down, you get a pager on your phone saying, "Get on the computer and fix it." And we're like, how could we make that better? That was the first thing on that list. We spent some time trying to do it and, again, we kind of get that feeling.

+ +

I think the more you fail, I guess, the better you get at detecting failure. I don't know about success but failure for sure it works like that. I think the third or the fourth idea was voice AI, and then we go ahead. We hack a prototype over a weekend and then put it out on...again, the communities that we know how to market were, like, Facebook groups and Reddit. And it picks up. Like, within, like, 3 days, we had 200 demo calls set up. And that just blew our minds because having been on the other side, we're like, oh, this is what it feels like when people kind of want something, what you have. I mean, it's still not clear, right? But --

+ +

CHAD: And you put it out there as automated voice assistant for businesses?

+ +

MONIK: No, actually what we did [laughs], I mean, nobody will want to click that if you put it like that [laughter]. You know, just out of curiosity, I was like, "Hey, you know, I've built this thing. It does this, you know, what do you think? Do you think this has any use for you?" And that's it. Like, people are, you know, messaging me nonstop, like, DMing me that, "Can you please share it with me? You know, I run this business. This might be helpful."

+ +

It was, like, more genuine. Like, I was just exploring, but, you know, that was a question that I posed. And that had, like, so many people show up, and they're like, "How about you just give us that and we can make money off of this?" And then, we started, you know, digging deeper, and we're like, oh, okay, it looks like you have so many manual processes and across industries. So, we had, like, some people from healthcare, some people from, like, you know, MLMs, multi-level marketing, so many different industries, optometrists, some in construction.

+ +

Anyway, so we're, like, thinking at that point, huh, okay. Maybe there is something here. Again, no mention of automotive, no mention of dealerships, nothing. We had a single dealership then. And I would say this was, like, about six months. I don't even know how many months ago, but, like, a couple of months ago. I think, at the time, is when we applied to Y Combinator as well.

+ +

CHAD: So, you applied to Y Combinator with the voice idea.

+ +

MONIK: Right. And we put something out there. I forget if it was the healthcare idea or the voice idea, but it's probably one of the two. I mean, that's also the other thing about Y Combinator. I think they don't really focus on ideas as much as they just focus on teams, which I think is probably the best practice. You know, we pivoted again [laughs].

+ +

But yeah, so we did voice AI, and then spent some time just trying to do everything, right? Trying to build a horizontal layer for voice, where building assistance for all kinds of businesses. And, you know, one of the businesses, at the time, was a dealership. I always like to think of this as an arranged marriage, where, you know, we have the customer. We kind of work through it --

+ +

CHAD: So, you had an actual dealership that you were partnered with as sort of a expert in the industry?

+ +

MONIK: Our first customer, right. And they were very progressive dealers, so they're always trying new things. And, at the time, we were working with a bank. We were working with some healthcare locations as well. We had some construction industry... whatnot. And we were going crazy trying to build something because everybody had these different requirements. And then, in practice, like, if you push AI out in the wild, to make it work, you need a lot of things, like deep domain expertise being one of them.

+ +

So, that realization is happening, you know, where we're coming to terms with that. And, at the same time, it works really well for the dealership, and they bring another customer. And they're like, "Oh, they also want to use it," and we're like, "Okay, sure. We'll turn it on." Then we do it. And then, it works again. And then, they bring more customers. And then, we're like, wait a minute, you know, like, we're not doing any outreach. We're not pushing out anything, and it seems like customers want it. And then, there are these other places where we're struggling so much.

+ +

Like, even with healthcare, you know, the regulations in banking and healthcare they slow down, you know, any sort of, like, AI implementations. So, even that world was very different with the automotive space. And you kind of do more of it and then you're like, oh, okay, looks like there is something here, and then we just decide to double down on that space. And then, we go further deep in and you realize, oh --

+ +

CHAD: Did Y Combinator...that can be a difficult decision for founders to make. So, did being in Y Combinator help you sort of give you the push to make that kind of bold decision?

+ +

MONIK: At least from our experience, it's always been that they're, like, get to the truth very quickly, whatever it is, and then make a decision. Do not delay it. I think we were, in fact, slow to do that. I think they were probably pushing people to do it more because we saw companies pivot in our batch, like, two times, three times right before demo day, which is the end of the program. Like, two weeks before, they just completely changed the company, and that's completely okay.

+ +

CHAD: So, how does an implementation actually happen? How does it roll out to a new customer?

+ +

MONIK: I mean, this is also very new, right? I think as you come across new customers, you have to adapt the process. But the essence of it is that you first have some data to start, which is, for example, for us, we work with a bunch of call recordings because a lot of our customers are already recording a lot of their calls. So, that gives you, like, some data as to what the experience is like today. Then the next thing is you get an idea of what you know your customers want the experience to be like. And then, you're basically now figuring out the delta between the two.

+ +

And then, you're configuring the AI agents, making sure, testing it. And then, you have, like, a period of, like, a week or so where you get through all of that. Then you work through integrations with existing softwares. That also, by the way, is another, like, I would say automotive is a sleeping giant. Like, an auto dealership, on average, like, per month will be spending $50, 000 on software.

+ +

CHAD: Wow.

+ +

MONIK: Because the whole business runs on software—everything starting from sales, inventory, parts, service, everything, repair orders—all of it comes through that.

+ +

CHAD: Now, is there a single common platform that a lot of dealers are using?

+ +

MONIK: Unfortunately, no. There are some major players; CDK Global is one of them, which actually was hacked recently. And it's in, like, over 15, 000 dealerships, and all of them shut down.

+ +

CHAD: Wow.

+ +

MONIK: Like, they just couldn't do any business, and they had to come up with creative workarounds. So, it was pretty painful, kind of, like, a COVID, you know, COVID moment for them. And then, yeah, we've been trying to help our dealers, whoever used that software, to, you know, again, come out with workarounds, where the AI is actually capturing all the information. And, you know, instead of dumping it into that system, it's, you know, finding workarounds on how to get it to our dealers. But yeah, so you integrate with them. That is, like, another major step. And they're, you know, they're not the most tech-forward companies so, you know, that can be a little challenging.

+ +

CHAD: Right. So, they use a lot of software, but they're not necessarily tech for...they probably don't have big IT departments and that kind of thing. And then, the users are probably non-technical.

+ +

MONIK: Correct. Yeah. The thing about dealers, I think, is that they're so plugged into the business, like, they know everything that is happening in the business. Everybody knows what the bottom line looks, what really will move the needle, what is a good customer experience. They may not be technical, but I don't think it even matters. That's the thing.

+ +

But yeah, we were talking about, like, the process, so it takes a couple of weeks So, you do, you know, you get all the information from them as to what needs to be done. You integrate into the systems. And then, the next thing that you do is you start slowly, where, for example, when we start taking phone calls for them, we initially start with off hours and overflow. So, when nobody's able to pick up a phone call, we get the phone calls. And that's how you get, like, some training data at the beginning in a safe manner.

+ +

And then, as the volume increases, you know, you get more confident, and you roll it out to a larger audience. But I think the key thing here is it has to be a gradual process because, even for the customer, it's something so new, like, to have a full-fledged conversation. Like, you can have a phone tree where it's, like, press one; press two. You're used to that kind of stuff, and that's been around for 15 years, and it still is, you know. And it is not the most natural thing, but it continues to exist. So, this is the next, you know, natural evolution of that interface where it's more free-flowing and, you know, less annoying.

+ +

CHAD: Do all of your customers...when the AI agent answers, does it say it's an AI agent?

+ +

MONIK: I mean, our recommendation is to always say that. I mean, it's up to the customer, eventually, if they want to say that or not. And, in fact, it is pretty interesting. Demographics make a huge difference. Like, we're live in, you know, all the states, not all but I would say, like, all the major states. And the way people behave with AI agents is so different, you know, Florida, and Michigan, and California, like, we see the call quality. We see the metrics. We see how annoyed people are or how happy they are and things like that. The way they talk is so different.

+ +

And one of the parameters in that is actually, you know, letting them know that it is an AI or not as well. So, we tweak that based on, you know, where we are. But for the most part, we always say that because we want to set the expectations, right? Because, initially, when we didn't, the most popular question on the call was like, "Are you a human?"

+ +

CHAD: [laughs]

+ +

MONIK: And the fact that people are asking it was also pretty insane, right?

+ +

CHAD: Right. They could sort of tell that something was different.

+ +

MONIK: Yeah, if you have, like, a long enough conversation because, obviously, it's not human, right? And then, you go, like, five turns into the conversation, and then you realize, okay, it sounds like a human, like, you know, it's speaking pretty quickly. It's giving me the kind of answers I want. But, like, this thing is strange because, you know, humans have a personality now.

+ +

Like, with AI, like, a lot of the systems, I mean, you can build personality into it, but it still doesn't have a personality, like, the truth is still that. And it does show up, you know, in interesting ways. And, of course, there can be, you know, some sort of mechanistic issues, you know, like, whatever, right, like, what the customer is really used to and then what you actually say. I think the best practice is to almost always declare, like, it's an AI. And that has improved call quality significantly.

+ +

MID-ROLL AD:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

CHAD: Did you train your own models?

+ +

MONIK: Yeah, we collected enough data to be able to do that, and we have trained a lot of different components and different models. So, when you think of it, there's not, like, one model that does the whole thing. You have, like, a lot of these small, medium, and large models that do different parts. So, the voice and speech are, let's say, two components.

+ +

I think the brain of the agent is really the thing that needs the most amount of training because, you know, text to speech and voice, I mean, they have, like, you know, some limits and then, some, you know, business return. Like, after some point, like, there's not really much value to be gained there because if you can transcribe everything, you know, to a certain level of accuracy, all the regions change, you know, accents change. You can always improve. Then it's just expanding scope.

+ +

But really, with the brain of the agent, you have multiple different models that actually interact with each other, and they're not just LLMs or generative models. You have a lot of different types of things that are going. You know, you're looking up information. You are, you know, validating something. You're making sure if, you know, this is compliant with what, you know, your company's tone is, all of these happening at the same time. And then, these are the different things that you actually really need to train because that's so specific to, you know, the type of business that is happening.

+ +

CHAD: So, are you also doing your own hosting of the models, or are you using a cloud provider for that?

+ +

MONIK: Yeah, we use cloud providers. I think having a small team it's insane. I mean, you can host custom models on a lot of these providers now. And then, a lot of them even offer services for you to, like, train and, you know, they take care of the infrastructure as well. I think it's a good thing to rely on it if you're lean and small. There's only so much a few people [chuckles] can do and focus on.

+ +

CHAD: What are you most focused on right now, either from a business or a product perspective, or, you know, where's your area of biggest risk?

+ +

MONIK: Of course, there is always, you know, risk of competition. And I guess the real question is, like, where...a lot of popular AI companies get asked this as well, right? Like, what is your moat, right? And then, I mean, I think that is the most obvious risk, right? Where, like, what is stopping anybody else from doing what you're doing, right? And there are certain parts of it, which, you know, you can de-risk. Like, having data and having proprietary data is, like, one of the biggest factors in this, right, of de-risking this.

+ +

I mean, there's also like, you know, the risk of, let's say, especially in our industry, is, like, taking technology to an industry where, you know, consumers are not pro-technology. You know, they don't want to jump at the best thing that there is, right, especially customer service generally suffers from that, right? Like, people anytime they hear a bot or something and they're like, "Ah, representative agent." So, there's, like, some underlying risk in, you know, human tendencies as to what they want.

+ +

But, again, to think about it, like, you know, IVRs, which are these interactive voice response systems, they've been around for so long. Nothing about it is natural. It is completely alien to how we interact, but they've been around for so long. So, a lot of times, like, this innovation is actually pushed down from the business to the consumer and not the other way around. It may not be the best experience. It's getting there.

+ +

So, it's that battle between the two, which I think can delay implementations. You know, some people, like, one of our customers, at one point, we went through the entire deal. And I think the owner of the dealership group just said, "I don't believe in AI." Now, you know, like, it's pretty hard, right? Like, you have the metrics. You have the numbers. You're generating value, but the belief is strongly held. And then, at that point, you know, there's nothing you can do.

+ +

CHAD: Do you know why they were saying that? Was it like, I don't believe it as in I don't think it can do it, or I don't believe in it as in, like, it's against my ethics, or something like that?

+ +

MONIK: I feel like it's probably because they've been burned by past experiences of AI. Like, I think chatbots have been around for so long, and a lot of people in the automotive industry have used them. Now, they used to suck. And as I remember in 2016 as well, you know, over the few years that came, like, it was still pretty terrible. So, I think it's some muscle memory from that.

+ +

And then, also, I think AI has been hyped a lot, and I feel like people just generally discount anything that is hyped. And the opinion is that let's just wait for the dust to settle, and then we'll just pick the winners. So, it's also possible, right? On the adoption curve, like, there's you just hit some people who are probably not on the early or even the mid, right? Maybe on the tail end, which I guess is completely fine and true for any tech adoption cycle.

+ +

CHAD: And it's true for any product that you're...this is not just an AI company problem. I think it's a startup thing, you know, to find the early adopters and then to move on from there. But you need those early adopters, those champions who are willing to do something new before other people.

+ +

MONIK: Exactly. And, I mean, yeah, it's just surprising to me how many early adopters, even in...like, there are almost early adopters in every industry. Every business has people who just want to see something, you know, they're just excited about it, like, they're willing to take the risk. And sometimes I'm not even sure why. But, you know, there's just that element of thrill, and then also, you know, beating the market to it and things like that.

+ +

And once you feel it, you understand the adoption curve initially. Because when you see customers, you see, ah, I see every dealership. Everybody should use us. I mean, as a naive founder, I think that that's what I used to think initially. And then, you know, over time, you get a sense of like, all right, you know, these are the types of customers that you should go after. These are the people who you should talk to first. And you build that kind of muscle as a founder and, yeah, new learnings.

+ +

CHAD: So, you started with the voice assistant. But are you moving into providing other AI-driven solutions for the automotive industry?

+ +

MONIK: Right. So, as we work with more dealers, we found out, you know, more areas that can be improved and, you know, gaps in, for example, communication. I think a lot of, like, quality of service really comes from how you can, you know, communicate with your customer. And it's not just about...you could do a good job and, you know, you could just completely destroy your, you know, quality scores because you didn't communicate well enough.

+ +

And you could do a bad service and still have a great, you know, service, you know, experience by communicating well. So, I think a lot of it is key to communication, and that's our focus: using AI to make it better. Voice is one channel. There are other channels as well. And there are a lot of, you know, communication gaps within, you know, our customers, you know, business set up as well. So, we try to bridge that gap.

+ +

CHAD: So, since you're focused on communication then, you're probably still leveraging generative AI solutions.

+ +

MONIK: Oh, a lot of it is, you know, improved by that technology. Like, so I always think, like, great products usually bring in two things, right? One is a necessary evil. Let's say, you know, something that has to be done like a phone system, for example, like, you need people to call in. You need to set up all the numbers, phone trees, whatever, routing. And then, there is AI, which makes that whole process easier.

+ +

So, I think good products usually have these two things combined, where it lets you do one nasty thing, which, you know, obviously, everybody else can do in a different way. And then, there's this one exceptional thing that you can do. And then, [inaudible 27:04] together, and it makes, like, a great offering for the business. I think that's what we're working towards.

+ +

CHAD: What do you think about the way things are right now, in general? I do think that there are some companies that are saying, "Well, that great thing is the AI," but they're not necessarily solving a problem that needs to be solved in that way.

+ +

MONIK: Yeah. I mean, I think to that part, right, the hype is real. Even in my mind, I just discount, like, 40% of the things that people say about AI now. Like, I mean, I would say it's more true than not, like, 60%, sure, but, like, a rough number in my mind is just 40%, and people, like, exaggerate. But, I mean, that's not because, I guess, they're lying. It's because they're, you know, hopeful, right? Because nobody knows, like, in practice. Like, I mean, now that we've done, you know, hundreds and thousands of minutes of AI phone calls, like, that has, like, you know, added to my judgment. And I kind of know, like, you know, what is possible and what is not with even the most cutting-edge stuff there is.

+ +

I think a lot is possible. But it's unfair to say that, oh yeah, it's as good as a human, for example, right? Like, in certain use cases, that just is not true. It's a different paradigm. It's just a different design interaction that has never existed before. There's nothing human about it. You can try to force it to be as human as you want but then it is forced human. Like, it is still not natural because it just isn't.

+ +

CHAD: So, I'm getting the sense then that that might not be your north star. That might not be what you're shooting for.

+ +

MONIK: Yeah, not at all, no. At the end of the day, a tool should drive business outcomes, right? And then, to drive business outcomes, you got to understand what your customer and their users want, for example. You know, I can imagine a world where people will say, you know, when a human picks up the phone, and they're like, "No, I don't want to talk to you. Can you transfer me to a, you know, the virtual agent?" Like, it will happen, right? And it won't be natural. Like, I do not think it will be natural, and it will be different.

+ +

Because imagine, like, a human having access to all the information at the same time. Like, how would they behave, right? Like, humans behave in a serial manner, and then there is, like, some simplicity to some interactions and some complexity to others. That's not the case with, you know, all the information you have. Like, I already know, for example, if you call me, right, and I'm an AI agent for your business, I know so much about you already, right?

+ +

Like, I'm not going to act the way, you know, an agent would act who's, like, now pulling up something on the screen, and they're like, "Give me a moment," and then they're reading through your stuff. Like, I already know all the issues you've had, all the conversations you had in the past. So, now I know what's exactly wrong, and, in fact, I'll give you the answer straight up, right? Because I can kind of get ahead and figure out what you really want.

+ +

CHAD: There's an example in one of the example videos I watched or, actually, I was trying to think, would I ever want to not talk to a person, right? There's an example in one of your videos where you can see the person does exactly what I do on a call. They say their email address is their first name dot last name at gmail.com. And that's not exactly what mine is, but it's like that.

+ +

And I say that, and most of the people that I talk to on the phone when I say that they...and I think it might be because they're not on a screen that has my first name and my last name on it anymore. Oftentimes, they don't remember my name, or can't see it, or can't understand what I'm saying. But the AI has all the information, and it understood what you were saying, and it just gets it instantly.

+ +

MONIK: Exactly. Another example of that, right? Let's say, like, you called six times, right? I mean, usually what happens in call centers often is that, like, you get thrown around, different agents pick up, and then maybe the data comes there. I've heard that, like, on existing recordings of, like, humans, where it's like, "I'm calling for the sixth time. Like, do you need me to repeat the same thing again?"

+ +

And then, they go through the same flow again because that is the policy, for example. And then, they're just so annoyed. Like, with AI, there's no such thing. It's just, you know, one model that's consistent, that's listening to everything. And it's like, even before you say...like, "I see you've called for the sixth time. You know, I'm really sorry that this is happening," and, you know, whatever. Just simple things like that.

+ +

CHAD: I'm just thinking about those experiences that I've had with customer service that have been that. And, yeah, that's why I think that this is really, you know, has a lot of potential. So, how do you sort of, you know, critics of AI will often point to, like, putting people out of work, right? How do you think about that?

+ +

MONIK: Yeah. I always, like, to pin it down to, like, evidence, and, I think, at this point, I have enough to talk about this. I think what we've seen with our technology is that a lot of it leads to repurposing of existing talent. So, for example, there are, you know, business development companies that dealerships rely on for inbound and outbound calling.

+ +

Now, when we free their time up from inbound, like, that's what we focus on right now, and take off all the mundane tasks, like, the agents that they have are now free to do a lot more outbound, which actually drives more sales or, you know, gives a better experience because, you know, people are checking up on them and saying, "Okay, how was your service a week later," right? And the person feels really good. And if there's any problem, they address it, whatever, right?

+ +

So, I think there is more stuff to do than humans will ever be able to do, and our desires have no end. We will continue to pursue that. So, as you free up something...it's like a race which has no finish line. You get a little bit of lead, but that doesn't mean anything because now you still got to keep going and keep going, and that's what we've seen. So, you know, with service advisors, for example, who would get phone calls in the service department of the dealership all the time, now they don't get calls anymore, right? But they're able to spend more time with people in the store. So, they're actually able to upsell more.

+ +

So, this kind of efficiencies that you drive, like, they take off the stuff that, you know, you don't want to do all the time and is repeatable to some extent, and then you free them to do things that they couldn't have done before. So, it really is, you know, realizing that there is this endless amount of work that always needs to be done. And here, I took this off your plate, but you still have all this work to do. So, it's just repurposing of, like, talent that's been happening again and again.

+ +

And, I mean, there is, of course, that's not to say that there is not going to be a loss of job opportunities, things like that, because, you know, it's just part of creative destruction as it is called, right? Where anything new will create some sort of disruption and then, you know, destroy certain things, but then it creates more, you know, on a net basis. That's happening, yeah.

+ +

I mean, if you think about it, like, I mean, I remember I grew up in India. This was, like, 15 years ago, I don't know, maybe 10 years ago, too. There was somebody who would sit in the elevator, and their only job was to press a button. If you think about it, right? Like, I mean, is that job like, you know, what value is it driving? Of course, like, to some extent, right? And then, they came up with these elevators where you could punch in the numbers, you know, exact floors right at the beginning, and you just walk into the right elevator, and that's done.

+ +

So, I mean, that job obviously does not exist anymore or does not need to exist anymore, right? But, I mean, I don't know if anybody else in the world has an opinion on that job existing, for example. Like, it's just, over time, when we look back, it just seems, like, obvious that, you know, why were we doing that? We should be doing this other thing. So, I think it's just movement.

+ +

CHAD: Right. Yeah. I think it is uncomfortable in the moment but, you know, there is a certain trend to the world, aside from AI, aside even from technology, specifically of progress. And, you know, over time, positive comes from that, but that doesn't mean that there's not pain in the meantime.

+ +

MONIK: There is, yeah. Definitely, there is pain. And I think the real reason why people feel this a lot is sometimes, like, even I make that mistake myself of viewing yourself as, like, stationary in terms of, like, skills and learning. It's like, you are everything you've learned up till now. And, okay, if what I knew up until now is not going to be relevant tomorrow, then what am I going to do?

+ +

But the thing is that everybody has the capability to learn and improve, and, in fact, even that gets easier and easier with time because technology makes that easier. And then, people are able to do more things than they could do before, learn faster, for example. And it's important to not forget that we have that ability. You know, we can always change and improve, and, in fact, knowing so much makes us even better at knowing more. And that's why we've been able to adapt to every change in history so far; we always have.

+ +

You know, so that fear is natural. But I think, over time, when we all look back and we're like, oh my God, why were we doing that? You know, like, and we will all be doing different kinds of things. Like, that is guaranteed. That is going to happen. But that fear still exists, and I think that is what causes the pain. It's the anxiety of it. Like, really? Of course, you have to change, you know, tracks. That is very real, but it's not as painful as fear makes it.

+ +

CHAD: Well, speaking of growing, and changing, and improving, you mentioned that, you know, you and your co-founder are both technical. How have your roles changed as the company has progressed, and what have you learned [chuckles], and have you settled into any sort of roles?

+ +

MONIK: Yeah. So, I'm the CEO. My co-founder is a CTO. We both used to write code at the beginning. Now only one of us writes code.

+ +

CHAD: And I'm guessing it's not you [laughs].

+ +

MONIK: Yeah, it's not me. Although I do miss it sometimes, but, actually, to be honest, I don't.

+ +

CHAD: [laughs]

+ +

MONIK: I feel so happy to have found that, I mean, to have realized that. But yeah, I think, basically, I think now that I understand at least B2B business to some extent, I think you always need to have a clear split of, like, build and sell. And then, of course, there's all this additional stuff that you need to do, but I think these two distinctions need to be absolutely crystal clear because both are full-time jobs.

+ +

And more than that, you need, like, owners of those spaces, and it's very hard to jump between the two. I mean, if they are solo founders, I mean, it's incredible how they do it if they're able to do both, or they rely on AI, or they rely on, you know, consultants, or contractors, or whatever. But I think those are the two roles.

+ +

And it came, I mean, I think it was just a natural progression. It's, like, when there's more work than people, I mean, that's usually a good place to be, I think, and that's how you know something is going well. You automatically assume natural roles. Because it's in that moment of, oh no, my list is, like, growing, like, quicker than you know, something, and then I need to jump in, and then you pick up the most natural and important things to you.

+ +

And then, even if you're not good at, like, you don't have an option. You have to get better at it. For example, selling, like, I never did any sales, ever. Like, I was doing machine learning and distributed systems and whatnot. But I've come to now realize that, okay, that is something that I enjoy that I think I can learn and get better at. And everything I did before, actually, even the engineering mindset helps with sales because it's just a process. So, we kind of assumed our roles when we just had too much on our plate, and we're like, "All right, you'll do this. I'll do this. Okay, fine." And then, we just talk about it, and then, all right, we keep doing it, and then now it just becomes a routine.

+ +

CHAD: Yeah, how has your team grown?

+ +

MONIK: Well, we've been two of us now, and we're hiring for a software engineer right now. So, we've been very lean. And I think...and this is also to something that Sam Altman said. I think it was him or I don't know who said that but, you know, you'll probably see the first one-person billion-dollar company.

+ +

CHAD: Yeah, I think it was, yeah.

+ +

MONIK: And I think there is some truth to it. Like, I don't know about billion, but, like, maybe a couple of million, a couple of hundred million, like, that might happen sooner. Because we've always tried to stay very, very lean, and I think we've relied on using technology wherever possible. But yeah, that's not to say...we still need people to build. And we are looking for a software engineer because, at some point, there's only so much we can do.

+ +

CHAD: Yeah. So, what would make someone a good fit for your team in that software engineering position? What are they coming to the table with?

+ +

MONIK: Everything, I wish. No, I mean, there are some exceptional people. And I think that's exactly what we're looking for is engineers with a founder's mindset because a founder's mindset is always like, you know, give us all the information. We'll make the decisions and figure out like, you know, what needs to be done. And someone who's, of course, exceptionally skilled at technology, at writing code, at building software, but also at understanding like, you know, what to build. I think that is, like, a killer combination and that is what differentiates, like, a great extraordinary engineer from anybody else.

+ +

CHAD: Well, especially since it's going to be the second developer [chuckles], you're going to have high needs and expectations for that.

+ +

MONIK: And with startups, right? It's always a little bit of chaos, and it's people who thrive in that chaos. And that's the thing, right? I've worked in, like, a bunch of startups that actually went on to become unicorns. I worked at Turing.com, which I think is...$4 billion, something like that now. But when I joined, there were, like, you know, just 10 people. And every company has problems, you know. And there's always this chaos that ensues, you know, at every stage. But there are some type of people who, like, thrive in that. They just love it. And there are some people who complain about it.

+ +

I think the ones who complain about it lose that opportunity to grow, and they don't have the mindset to see opportunity in it. And I think those are the people who are absolute amazing, you know, future founders, you know, or even, like, great founding engineers are employees like that because they like that challenge, you know. It's like, this is wrong. Let me go fix it.

+ +

CHAD: Right. And the reverse is also true. There's a point in a company's life cycle where they need a different kind of person that is more, like, stable [laughs].

+ +

MONIK: Well, I don't know. I think I disagree with that. I think, I mean, that's when the company, you know, plateaus. Like, if you bring in more people like that, you...really, like, what is a company? It's just a collection of really smart people. The fact that OpenAI is able to do what Google cannot over the span of six years is because they just do not hire people, you know, of certain caliber, certain mindset. They just keep them out. Again, that's their policy, or even some larger companies. I think the idea is to keep that mindset going and going. It is tiring, right? But it is what drives innovation. Like, that's just the nature of it.

+ +

CHAD: Well, if what you're describing sounds like someone who's listening, or if someone's in the automotive industry and wants to learn more, where can they do that?

+ +

MONIK: Yeah, they can reach out to me, you know, my email is monik@toma.com. So, they could get to us.

+ +

CHAD: And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon at cpytel@thoughtbot.social.

+ +

Monik, thank you so much for joining me and sharing the story with me.

+ +

MONIK: Thanks, Chad. This was great.

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening and see you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+eJ-CGfFq + + ]]> + + Chad Pytel + + + 533: Leveraging Data for Gender Equality with Amy-Willard Cross + https://podcast.thoughtbot.com/533 + 079ea106-7153-45b0-b5ba-d008b377a16d + Thu, 11 Jul 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Founder Amy-Willard Cross discusses Gender Fair, a consumer rating system for gender equality that uses data and UN Women Empowerment Principles to evaluate companies in various categories, making it easier for consumers to make informed choices via their app and browser extension. She emphasizes the power of transparency and collective consumer action in driving corporate accountability and reflects on the challenges and future plans of Gender Fair. + 32:59 + no + + + Founder Amy-Willard Cross discusses the mission and operations of Gender Fair, the first consumer rating system for gender equality. Gender Fair aims to measure and promote gender equality within consumer-facing companies by utilizing data and the UN Women Empowerment Principles. Amy highlights the importance of transparency and data-driven insights to create social change, emphasizing that gender equality in corporate practices benefits not just women but overall fairness in the workplace. Gender Fair evaluates companies across five categories: women in leadership, employee policies, diversity reporting, supplier diversity, and philanthropy for women. +Amy also shares how Gender Fair has incorporated technology to increase its impact, including an app and browser extension that allow consumers to easily access company ratings on gender equality. These tools enable users to make informed purchasing decisions based on a company's gender equality practices. The app features functionalities like barcode scanning and logo recognition to provide real-time information about products. Amy emphasizes the significance of making gender equality data accessible and actionable for consumers, believing that collective consumer power can drive corporate accountability and fairness. +Throughout the conversation, Amy discusses the challenges and successes of building Gender Fair, the importance of leveraging economic power for social change, and the role of technology in facilitating gender fairness. She also touches on the broader impact of Gender Fair's work in promoting fair business practices and the potential for future expansions, such as a B2B database for procurement. +Gender Fair (https://www.genderfair.com/) +Follow Gender Fair on LinkedIn (https://www.linkedin.com/company/begenderfair/), Facebook (https://www.facebook.com/GenderFair/), or Instagram (https://www.instagram.com/genderfair). +Follow Amy-Willard Cross on LinkedIn (https://www.linkedin.com/in/amy-willard-cross-genderfair/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Amy-Willard Cross, the Founder of Gender Fair, the first consumer rating system for gender equality. Amy, thank you so much for joining me. +AMY-WILLARD: Well, I'm very happy to be talking to robots, giant and small. +CHAD: [laughs] We'll try not to smash into each other too much on this show. I think we probably have a lot to learn from each other rather than conflicting. +AMY-WILLARD: I think so. +CHAD: Let's just get started by digging in a little bit to what Gender Fair actually is in terms of what we mean when we say a consumer rating system for gender equality. +AMY-WILLARD: It's about data. So, I was originally a journalist. I've written for a living my whole life: books, magazines, articles [laughs], you know, radio shows. I wanted to do something to promote equality in the world. And I realized that data is one way that you can want to have commercial value. Data has value that isn't, like, just blah, blah, blogging, and also, data can create social change. +So, I decided to do something like, you know, we know fair trade has created great change as has, you know, marine stewards certified. And also, I was inspired by something that the Human Rights Campaign, the LGBTQ organization, does, which is called the Guide to Corporate Equality. So, our goal is to measure how companies do on gender and then share that with the public. +And I didn't just make this up. We use a set of principles called the UN Women Empowerment Principles, which look at eight different sort of areas of an organization. And so, we created metrics that are based on these UN Women Empowerment Principles and also based on what is findable in the public record. We rate consumer-facing public companies, you know, like Unilever, Procter & Gamble, the shampoos that you use, the cars that you buy, the airplanes you ride on. +And we look at five major categories, such as, like, women in leadership. We look at employee policies like parental leave, and flex time, part-time, summer Fridays. I'll be curious to know what you do at Giant Robot. I bet you have good ones. And then, we also look at diversity reporting. Our company is upfront with their attempt to bring more diversity into the workforce and also supplier diversity. I don't know, are you familiar with supplier diversity, Chad? +CHAD: I am because we often are a supplier, so... +AMY-WILLARD: You are. So, when they ask you if you're diverse...but one way companies, especially the big companies that we rate on this public database, they can make a big impact by trying to buy from women and minority-owned businesses, right? When procurement spending is huge. That's a metric that people may not know as well, but it's one that I would encourage every business to undertake because it's not that expensive. And you could just intentionally try to move capital into communities that are not typically the most rewarded. +The last category that we measure is philanthropy for women, and that's important. People say, "Well, why do you measure philanthropy?" One, because the amount of philanthropy that goes to women and girls is 1.5% of all donations, and it used to be 1.8. So, pets get more money than women. I don't know how that makes you feel, Chad, but it doesn't make me feel very happy. I mean, I suppose if you're Monster Beverage and you don't have any women clientele, one, it's okay if you don't score well on your gender metrics; just meet the basic fairness. But maybe Monster Beverage doesn't have to donate to the community of women. +But if you're making billions of dollars a year selling a shampoo, I would sort of think it's fair to ask that there's some capital that goes back the other way towards the community of women. So, that's the measurement. So, we could do it...and we do it for small companies like yours, too. I imagine your company would do well from the little bit I've talked to people on your staff. It sounds like you have a lot of women in leadership. And I don't know your policies yet, but I'm sure you...I bet in Massachusetts I know you have parental leave anyway in the state, but you're a more progressive state. +But I think this is something that all of your listeners can benefit from is putting a gender lens on their operations because a gender lens is a fairness lens. And it includes usually, you know, this includes people who are not just all the same men, White men. So, it helps all businesses sort of operate in a more fair way to put a gender lens on their operations. And it's not hard to do. +CHAD: So, one of the things that jumped out at me, in addition to just the Gender Fair mission, as I was learning about Gender Fair, is that you have an app and a browser extension. And so, that's part of why you're on the show, not only do we care about the impact you're having. +AMY-WILLARD: That's right. Yeah [laughs]. +CHAD: But you're a tech company. Did you always know as you got started that you were going to be making an app and a browser extension? +AMY-WILLARD: Well, yes, that was the beginning because you have data. You have to make it used. You have to make it available, right? Personally, I like to see it on packages. But yes, we've had two iterations of the app, and I'm sure it could always get better and better. The current one has a barcode scanner and, also, it can look at a logo and tell you, "Oh, this soda pop is not gender fair. Try this soda pop, which is gender fair." And it can make you a shopping list and stuff like that. +But, you know, tech is only good if people use it, so I hope they do. I mean, the idea is making it more accessible to people, right? I would like to have it as a filter, some easy tech. We've talked to big retailers before about having a filter put on online shopping sites, right? So, if I can choose fair-trade coffee, why can't I choose gender-fair shampoo? +I like it when people can use technology to create more fairness, right? If this is a great benefit to us if technology can take this journalism we do and make it accessible and available and in your hand for someone, you can do it in the store, for Pete's sake. You could just go on the store shelf, and that's pretty liberating, isn't it? When you think of it. It should be easy to know how the companies from which you buy are doing on values that you care about. So, I never really thought of it as a tech. I wish it was better tech, but, you know, I'd need millions and millions of dollars to do that. +CHAD: [laughs] Had you ever built in any of your prior companies, or had been directly responsible for the creation of an app? +AMY-WILLARD: No, but I did actually once when I worked at the major women's magazine in Canada, I did hire the person who created the first online sort of magazine in Canada, and she made money, so I felt good about that. I plucked her from...she was working as sort of tech support at the major...what do you call those? Internet providers in Canada. But no, I had not, and so I relied on experts. +I had a friend who was on the board of Southby, and he helped me find a tech team. I went through a few of them and, you know, it's hard to find. Like, where do you go and find people who will build something for you when you're a novice, right? As a journalist, I don't really know anything about building technology, and I certainly wasn't about to start at my age. It was definitely a voyage of discovery and learning, and I don't think I really learned much coding myself. +CHAD: That's okay. +AMY-WILLARD: That's okay [laughs]. +CHAD: But was there something that sort of surprised you that you didn't anticipate in the process of creating a digital app? +AMY-WILLARD: Oh gosh. Well, you know, of course, it's difficult, and there's lots of iterations, and there's lots of bugs. And in every business, mistakes are part of what people...in the construction industry, they'll tell you, "Mistakes are just going to happen every day. You just have to figure out how to fix each one." But, no, it's a difficult road. So yeah, I wish I could have coded it myself. I wish I could have done it myself, but I could not. But yeah, it's good learning. +And, of course, you know, I think anyone who's going to start building a company with technology...if it were me now 10 years ago, I would have actually done some coding classes so I could just even communicate better to people who were building for me. But I did learn something, but not really enough. But it's a very interesting partnership, that's for sure. +CHAD: And there is a lot of online classes now... +AMY-WILLARD: Right [laughs]. +CHAD: If someone is out there thinking, oh, you know, maybe that's good advice. And there's a lot of opportunities for sort of an on-ramp, and you don't need to become an expert. +AMY-WILLARD: No. +CHAD: But, like you said, even just knowing the vocabulary can be helpful. +AMY-WILLARD: I think that would have been useful. Yeah, definitely useful. But I definitely, like, you learn a little bit as a text-based person. You learn the rigor of just sort of, like, you have to think in ones and zeros. It either is or isn't. That helps. I learned that a little bit in working with tech devs. The last version we did actually white labeled off of someone who had created a technology to do with...it was to do with building communities online. And their project failed, but it had enough backbone that we were able to efficiently build what we needed to on top of what they built. +CHAD: Oh, that's really...was it someone you knew already, or how did you get connected? +AMY-WILLARD: Yes, they knew one of our partners in New York. We tried it first as a community project. It didn't really work. And then, we realized it could actually hold our data at the same time. So, my first iteration of the app was different. But yeah, anyway, we've built it a couple of times, and I could build it even more times... +CHAD: [laughs] +AMY-WILLARD: And make it even better and better. +CHAD: So, on the sort of company side of you've worked with companies like Procter & Gamble, MasterCard, Microsoft, do you find it difficult to convince companies to participate? +AMY-WILLARD: What we do is data journalism. We don't contact the companies. We have researchers. We have journalists go and look through the SEC data and CSR reports and collect the data points on which we measure them. So, no one has to cooperate with us to get the data. It's journalism. It's not opt-in surveys, which is a very common...when I first started, no one was measuring women, and now there's lots of different measurements. And they're often pay-to-play surveys, so they're not really very valuable. Ours is objective and fully transparent journalism. +But then afterwards, our business model how we typically used to pay for this is that companies that did well on our index were then invited to be quote, "certified." And this was a business model that was sort of suggested to us at the Clinton Global Initiative, to which I belonged in 2016. And they loved what we were doing, using the free market to drive gender equality. Because, you know, our whole point is that women and people who care about women and equality, we have a lot of power as consumers, or as taxpayers, or as tuition payers, or as donors to nonprofits. And whenever you give money to an organization or a company, you have the right to sort of ask questions about the fairness of that organization. Well, that's our whole ethic, really. +I answered that question and came around to a different idea, but yes, no. So, the companies do participate to be certified, and some of them are interested and some of them are not, and that's fine. We do projects with them sort of like when we...we've talked about MasterCard, and we did a big conference with them in New York. This is pre-pandemic. And then, we did a big, global exhibit with P&G, and Eli Lilly, and Microsoft at TED Global, which was very fun. It was all about fairness. And it was great to talk to technologists such as yourself. And we made a booth about fairness in general, not just about women. And we had a fairness game, and it was very interesting to just discuss with people. + I think people like to think about fairness, right? I don't know if you have children, but little children get very interested in the idea of what's fair very early on. Yeah, so some companies participate...now we have companies...we do some work in B2B procurement which is something that your listeners might be interested in thinking about is that just, like, supplier diversity. If I were purchasing your services, your company services, I would ask about the gender metrics of your organization. I already learned they're quite good. +So, big companies buying from other companies can put a gender lens on their B2B procurement. And so, that's a project we're doing with Salesforce, Logitech, Zoetis, Andela, which is another tech provider, and Quinnox, which is a similar sort of tech labor force, I believe. And so, we're going to be releasing a database about B2B suppliers. Actually, I should make sure that you get on it. That's a good idea. +CHAD: Yes. +AMY-WILLARD: That's a good idea because then it's going to be embedded in procurement platforms because this is a huge amount of money. It's even probably more...it could be more money than consumer spending, right? B2B spending. So, I'm excited about working with more companies on that to help promulgate this data and this idea because it's an easy way to drive fairness in a culture. When the government isn't requiring fairness, at least large companies can. And in some countries, actually, the government requires its vendors to do well on gender. Like, Italy now has a certification for gender, the government does, and companies that do well are privileged in RFPs and also get a tax deduction. +CHAD: I don't want to say something incorrect, but I think the UK has, like, a rule around equity in pay... +AMY-WILLARD: Yeah, absolutely. You're absolutely correct. +CHAD: And yet they don't have equity in pay, the data shows. +AMY-WILLARD: That's right. And we don't have that in the United States. It's voluntary in the U.S. We measure that, actually, too. That's seven points over a hundred points scale is whether they, one, publish the results of their pay study. In the U.S., though, we do it in a way that isn't rigorous as the way they do it in the UK. In the UK...you're great to remember that, Chad, in the UK, I mean, I wish my government did that. +In the UK, companies report on the overall salaries paid to men and the overall salaries paid to women. So, that means if, you know, all the million-dollar jobs are held by men, it shows very clearly, and all the five-dollar jobs are held by women, it shows very clearly there's an imbalance. And in the United States, we just say, "Oh, well, is the male VP paid the same as a female VP?" That's sort of easier to do, right? +CHAD: When we've talked with some larger companies about different products we're creating or those kinds of things, sometimes what I hear is they're looking for big wins, comprehensive things. And so, I was wondering whether you ever get pushback or feedback that's like, "Well, not that your issue is not important, but it's just focused on one aspect of what our goals are for this year." +AMY-WILLARD: Right. Yeah, that's always a hard thing because when I think about fairness to half of the population, it's a hard thing for me to think that's not hugely important. +CHAD: Yes. +AMY-WILLARD: I have a really hard time, but yes, of course, we get that a lot. And, you know, quite frankly, when we did this B2B project with Logitech and Zoetis, they would ask their vendors, like, the major consulting companies and big companies, to take a SaaS assessment that we do. We have a SaaS product that private companies can take, or just instead of doing our journalism, they can just get their own assessment. And they were very, very reluctant to do this. That was just, you know, half an hour. It was a thousand-dollar assessment. And it took many months to convince these companies to do it. And that was their big customers. +So, yes, it is very hard to have...what's the word? Coherence on what one company wants versus what a big company wants, and it's hard to know what they want. And it's, yeah, that's a difficult road for sure. And it changes [laughs]. +CHAD: Part of the reason why I asked is because from a product perspective, from a business perspective, at thoughtbot, we're big fans of, like, what can be called, like, niching down or being super clear about who you are, and what you believe, and what you offer. And if you try to be everything to everybody, it's usually not a very good tactic in the market. +AMY-WILLARD: That's right. That's right. +CHAD: So, the fact that you focus on one particular thing like you said, it's very important, and it's 50% of the population. But I imagine that focus is really healthy for you from a clarity of purpose perspective. +AMY-WILLARD: That's right. But at the same time, now there's lots of...when I started in 2016, there weren't a lot of things in this space, and now there's many, many, many, many, many, many, so corporations that want to sort of connect to the community of women or do better for women. There's many different options. So, there's many flavors of this ice cream. Even though we're niche, the niche is very crowded, I would say, actually, and people are very confused. +I mean, I think I remember hearing from Heineken that they're assaulted daily by things to, you know, ways to support women in different organizations and events. And they said they took our call because we were different. But yeah, there's many competitors. But, I mean, that's the main thing. In any business, in any endeavor in life, one has to show one's value to the people who may participate, and that's a challenge everywhere, isn't it? +CHAD: Yeah. +AMY-WILLARD: But the niching down thing is...and interesting we hear a lot these days is that women are done. We've moved on from that. Now we care about racial equality, and we say, "That's a yes, and… We can't move on." +CHAD: Well, the data doesn't show that we've moved on. +AMY-WILLARD: The data doesn't show that at all, and we're going way backwards, as you well know. So, I mean, actually, I don't know if you know, there's something called the named executive officers in public companies. Are you familiar with that? The top five paid people. +CHAD: Yeah. +AMY-WILLARD: They have to be registered with the government. Well, that number really hasn't changed in six years. That's where the big capital is, and the stock options, and the bonuses, and the big salaries. So, to me, that's very important that I would like, you know, rights and capital to be more...well, I want rights to be solid and capital to be flowing. And so, that's what we hope to do in our work. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +CHAD: So, going back to the founding of Gender Fair, when did you know that this was something you needed to do? +AMY-WILLARD: I wanted to serve, you know, you want to be useful in life. And I wanted to do work in this field that I care so much about. As I said, I think I told you I started doing journalism before, and I realized anyone could take the journalism, and they could, you know, Upworthy would publish things we would create and then not pay us for it. And I thought that's crazy. +But it's interesting talking to my husband. My husband's, like, a very privileged White guy. And I remember he said something to me very interesting. He said, "You either have power, or you take it." And he said, "Women have all this power." So, he helped me understand this. Like, you know, I think sometimes as women or communities that are underserved, you start thinking very oppositionally about what you don't have. But at the same time, you can realize that you do have this power. +So, what we're trying to do with Gender Fair is remind people they have this economic power, and they can use it everywhere, you know, in addition to our consumer database. I told you that we're doing a B2B database this year. And we also...I think next week I'm going to release a database of 20,000 nonprofits looking at their gender ratings. That was done as a volunteer project by Rose-Hulman Institute of Technology if you know them. So, yeah, this is an ethic that you can take everywhere in your life is you have this power, even as a consumer. Chad, even in your little town, you can ask your coffee shop if they pay fair wages. Like, this is just a way of looking at the world that I hope to encourage people to do. +CHAD: Along the journey of getting started, I assume you ran into many roadblocks. +AMY-WILLARD: Mm-hmm. +CHAD: Did you ever think maybe this is too hard? +AMY-WILLARD: Oh yes. Well, not in building. In building, you're very optimistic, you know, it's just like when you're writing your first book. You think it's going to be a bestseller. Like, you build something, and you think the whole world is going to use it right away, and you're going to...I did have a great...when I first launched, I had a wonderful, I had, you know, press in Fortune. I had Chelsea Clinton. I had big people writing about us. Melinda Gates has written about us many, many times. +The fact that...well, I've always wanted to build, like, a consumer revolution of women, and I'm going to keep at it. But it's very daunting. It's very daunting when you're trying to move a boulder such as, you know, big institutions and companies that don't really want to change, and they're not motivated to do it. So, yes, those are my roadblocks. +It's not creating the massive amount of change that I wanted to do. And I'm not going to give up, but, yes, it is very daunting, and it's very daunting to see how little people care. Some people don't care about it, but some people in power don't care about it. But I think if you asked, you know, regular women, they would say, "We would like fair pay. We would like equal opportunity. We would like paid parental leave." They would want all these things, and hopefully, together, we can fight for them. +CHAD: Well, and, like you said, the premise of what you're doing is you're focused on the power that you do have, which is the dollars that you spend with these companies. I think that's such a smart angle on this because especially for...it seems like the core in terms of the consumer-facing companies. That's so inherent in what this is. +AMY-WILLARD: That's right. +CHAD: Yeah, the angle of empowering consumers, and giving them the information, and leveraging the power that consumers have with these companies seems really smart to me... +AMY-WILLARD: That's right. If it works -- +CHAD: As opposed to individually going to the companies and saying, you know -- +AMY-WILLARD: "Please make it." Yeah. And some people would refute your use of the word empower because that implies that people don't have power. So, when I give speeches...I have a pair of beautiful gemstone red pumps, and I say it's the ruby slippers. We had this power all along. We just were not exercising it. But this power will only work, Chad, if it's done in the aggregate. +So, our challenge is to reach the aggregate of American women. I have to, you know, I have to go reach 50 million women this year. That's my goal. Reach 50 million women with this message that we have the power in the aggregate to make change. And that's the only way this will work. If it's just one by one, it really doesn't. +When I first launched, I found when I showed the app to people on the lower end of the economic scale, like, you know, people in the cash register; they understood this more than middle-class women. They understood the fact that if all women come together and, you know, buy from this company or don't buy from this company based on how they treat women, they understood that as a collective power. Whereas middle-class women who don't have as many struggles didn't really groove to that idea as quickly, which I thought was very...to me, it was very interesting, you know, individuals feel more powerful on the higher end of the social scale. They may or may not -- +CHAD: That is interesting. +AMY-WILLARD: Yeah. So, yeah, that's my goal. We'll see if I can do it. That's going to be my life's work, I think, Chad. +CHAD: How do you reach 50 million people? +AMY-WILLARD: I don't know. That's what I'm going to think about. You know, we're talking to different people about campaigns. We actually stopped the consumer work during the pandemic because it just, you know, everything changed. And so, now, this year, we're going back. I don't know; I mean, I guess if Ryan Reynolds tweeted about me, you know, that would help. If [laughs] anyone listening has any ideas how to reach 50 million women...no, maybe 3 million is what I need to create social change. +CHAD: I imagine that it doesn't just come down to spending money on advertising. One, you might not have that money. +AMY-WILLARD: No. And that would be, you know, that also would be not in the ethics of what Gender Fair is, for example, right? That means I would be paying money to Facebook and basically Facebook, I guess, and Google. If you look at the major spends of nonprofits, they're advertising with these big tech giants. And so, we have...actually, we have some partnerships with large women's organizations, and I think that's the way we hope to spread that. And if I had money for advertising, I would want to spend it with other women's organizations, or women's owned media, or women influencers. +There's another idea I talk about in my work I call the female domestic product, and so talking about how much money women earn or capital we control. And the more we can grow that female domestic product, the more we can achieve equality actually. I always say, in America, you get as much equality as you can pay for sadly. +CHAD: I was just about to say, "Sadly." +AMY-WILLARD: Sadly, yeah. It's true. We still don't have the Equal Rights Amendment. A hundred years. +CHAD: Well, 50% of the population would say, "Why do we need an Equal Rights Amendment [laughs]?" +AMY-WILLARD: All men are created equal, but yeah, it's quite astonishing. I don't know. Do you have daughter, too, or just a son? +CHAD: I have a son, and my younger one is non-binary. +AMY-WILLARD: Well, I'm sorry to be so binary. Excuse me. +CHAD: It's okay. +AMY-WILLARD: Well, interesting. And that's great, too, isn't it? Because we see how fluid gender is and their rights are just as important as a woman's rights. And these are, you know, women and non-binary people are often excluded from things. And so, we are all working together just to create fairness. I'm sure that the same thing happens in your family, too. +CHAD: Yeah. I think fairness is one of those things. Sometimes equality is not necessarily the same as fairness. +AMY-WILLARD: Yes. +CHAD: But I think, like you said at the top of the show, fairness is something that we seemingly learn very early on. But one of the ways that it comes across is I'm being. It is unfair to me, especially in little kids, at least with my kids [laughs]. +AMY-WILLARD: Of course, yes. +CHAD: That was the thing that they learned first and caused them the most pain. And it was very difficult for them to see that something was unfair for somebody else. So, I remember saying to my kids when they were little, "Fair doesn't mean you get your way." +AMY-WILLARD: That's right. Not fair. +CHAD: Right [laughs]. +AMY-WILLARD: It's true. But then, you know, it's funny. When I talk about equal pay, I often say to people, "When I used to cut cakes for my children, I cut equal slices, and I didn't put them under the table," like, you know what I mean [laughter]? So, why are we so cagey about the slices of economic pie we give to one another? +I mean, there's no reason why pay has to be secret, right? If it's fair. You could easily talk to people. Well, you know, Chad gets paid more money because he's the CEO, and he does the podcast, and he has to talk to the bank, you know what I mean? So, you could easily explain that to people. And I don't know why we have to keep salaries a secret from one another. It seems very irrational to me and not really a part of fairness. +CHAD: Yeah. Yep. That's something...so, all of our salary bands at thoughtbot are public on the internet. +AMY-WILLARD: Cool. On the internet. Oh, I'm very impressed. +CHAD: Yeah. So, you can go to thoughtbot and use our compensation calculator. You enter in your location, what role you have. +AMY-WILLARD: Oh. So, you do it for other people. Oh, that's cool. That's a great service. And that was just some sort of tech that was sort of pro bono tech that you all built for the world. +CHAD: Yeah, we created it for ourselves. +AMY-WILLARD: And then you shared it. +CHAD: Mm-hmm. +AMY-WILLARD: Then you open-sourced it. Great. Well, I bet you have a lot of happy employees. +CHAD: I like to think so [laughs]. I do think that there is an inherent understanding of fairness. And when people ask how we do things at thoughtbot or how we should do things, I say, "How do you want it to be?" I think that guides a lot of how we do things and why a lot of stuff we do is just common sense. And it's not until ulterior motives or maintaining power comes into play where the people in power don't want to give it up. Because, like you said, people don't understand that by giving someone else a bigger piece, they think that that means their piece is smaller. +AMY-WILLARD: Right. Or they just think they deserve it. I was reading last night about succession planning and CEOs. And apparently, a lot of them just stay...oh, sorry, in big public companies, not in their own companies, they stay on way too long. And all these consultants are saying it's the four Ps, you know, position, privilege, pay, and then...I forget the other one. But one of them was jets. They don't want to give up their jets. +So yeah, I think when you have things, it seems fair, and sharing them seems...giving up some of what you have seems unfair. But I do think humans can see fairness. But sometimes, when you have a lot, it's hard to see it. You're able to justify why it may be not unfair to people who don't have as much as you do. But anyway, I can't change human nature, but most people do understand fairness. I think you're right about that. +CHAD: Well, one thing...I noticed...so, you're a Public Benefit Corporation. +AMY-WILLARD: Yes. +CHAD: Did you set out to be a Public Benefit Corporation from day one? +AMY-WILLARD: Yes, you know, originally, when it came to how was I going to pay for this, the first part I paid myself with my own money. I hired MBAs. I hired researchers. I built the tech. And then, I wasn't sure how I was going to pay for it going forward. But I knew I didn't want to become a nonprofit because, in my mind, there are so many things that...there are so many problems that women have that need to be solved by nonprofit organizations, planned parenthood first among them. +Like, I don't want to take money away from women's organizations that help women fleeing abusive homes. So, I wanted to see if I could pay for this in the private sphere, which we've been able to do, and not have to seek donations because, really, I felt very strongly about not taking money out of that. +That's part of the FDP, the part of the female domestic product, but the part that's contributed by people philanthropically. And there isn't a lot of philanthropic dollars going to women, as I mentioned before. So, yes, I knew definitely I wanted to be a Public Benefit Corporation. And there's no tax benefits to that, you know, I don't know if you are yet, but... +CHAD: No, it's something that we've looked at, but it's very attractive to me. +AMY-WILLARD: Right. And there's also the private version of it being a B Corp, which is also very useful. It's an onerous process. Public Benefit Corporation isn't quite as onerous, I don't believe. I mean, we're in Delaware and New York, but it just says that you're, I mean, we exist for the public good. I'm not existing to make millions of dollars. I'm existing to create social change. And some organizations don't want...are leery of working with us because we're not a nonprofit so that's to assuage them. Well, it's not really about...we're not about enriching shareholders. It's just a different way to pay for it. +But yeah, I would encourage all companies to look into being a Public Benefit Corporation or do a B Corp assessment or a Gender Fair assessment. It helps them, you know, operate in a world that is increasingly more values concerned. Maybe 20 or 30 years ago, it wasn't so on the top of mind of many people. We were coming out of, you know, warring '80s capitalism. But nowadays, the younger people, especially, are very focused on issues of fairness and equality. So, I think those tools making business better that way are very useful. +CHAD: Well, I would encourage, you know, everyone listening to go check out the app, if you're at a company, to look at doing the assessment. Where can people do those things? +AMY-WILLARD: Ah, well, yeah, I would encourage them to do all those things. You're right, Chad. I would encourage you to download the app and check some of your favorite brands. It's very simple. Do the paid subscription. +And then, if you're a company, you can do an online assessment. You just go Gender Fair assessment, and you'll find it. If you're a business and would like to participate in our B2B database, you can also do the assessment, or there's a coalition for Gender Fair procurement, where you can get information. We had the prime minister of Australia speak at our launch. It was quite excellent. +We'll be launching our nonprofit. Actually, I think it's already online. It's called genderfair-nonprofits.org, if you want to see how your favorite nonprofits do. But, basically, we're here to help any business or organization do better on gender. And you can email me amy.cross@genderfair.com. And I would love to help anyone in their journey for fairness of any kind. Yeah, many ways to participate. Just go to genderfair.com or genderfairprocurement.com. +CHAD: Awesome. Amy, thank you so much for sharing with us. I really appreciate it. And thank you for all the good that you're doing in the world with Gender Fair. +AMY-WILLARD: Well, I appreciate the way you're running your company in a very new, interesting, and apparently ethical way. Privately, I could look at your website and your career page and figure out how you're doing. But it sounds, to me, when I've talked to people, that you're doing very well. And I honor your curiosity about learning from others. +CHAD: Awesome. Well, listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon @cpytel@thoughtbot.social. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and see you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + Gender equality, Gender Fair, Amy-Willard Cross, consumer rating system, corporate accountability, workplace fairness, gender equality data, technology for equality, gender ratings, social change, consumer empowerment, UN Women Empowerment Principles, gender equality app, diversity reporting, supplier diversity, women in leadership, employee policies, philanthropy for women, economic power, business practices + + Founder Amy-Willard Cross discusses the mission and operations of Gender Fair, the first consumer rating system for gender equality. Gender Fair aims to measure and promote gender equality within consumer-facing companies by utilizing data and the UN Women Empowerment Principles. Amy highlights the importance of transparency and data-driven insights to create social change, emphasizing that gender equality in corporate practices benefits not just women but overall fairness in the workplace. Gender Fair evaluates companies across five categories: women in leadership, employee policies, diversity reporting, supplier diversity, and philanthropy for women.

+ +

Amy also shares how Gender Fair has incorporated technology to increase its impact, including an app and browser extension that allow consumers to easily access company ratings on gender equality. These tools enable users to make informed purchasing decisions based on a company's gender equality practices. The app features functionalities like barcode scanning and logo recognition to provide real-time information about products. Amy emphasizes the significance of making gender equality data accessible and actionable for consumers, believing that collective consumer power can drive corporate accountability and fairness.

+ +

Throughout the conversation, Amy discusses the challenges and successes of building Gender Fair, the importance of leveraging economic power for social change, and the role of technology in facilitating gender fairness. She also touches on the broader impact of Gender Fair's work in promoting fair business practices and the potential for future expansions, such as a B2B database for procurement.

+ + + +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Amy-Willard Cross, the Founder of Gender Fair, the first consumer rating system for gender equality. Amy, thank you so much for joining me.

+ +

AMY-WILLARD: Well, I'm very happy to be talking to robots, giant and small.

+ +

CHAD: [laughs] We'll try not to smash into each other too much on this show. I think we probably have a lot to learn from each other rather than conflicting.

+ +

AMY-WILLARD: I think so.

+ +

CHAD: Let's just get started by digging in a little bit to what Gender Fair actually is in terms of what we mean when we say a consumer rating system for gender equality.

+ +

AMY-WILLARD: It's about data. So, I was originally a journalist. I've written for a living my whole life: books, magazines, articles [laughs], you know, radio shows. I wanted to do something to promote equality in the world. And I realized that data is one way that you can want to have commercial value. Data has value that isn't, like, just blah, blah, blogging, and also, data can create social change.

+ +

So, I decided to do something like, you know, we know fair trade has created great change as has, you know, marine stewards certified. And also, I was inspired by something that the Human Rights Campaign, the LGBTQ organization, does, which is called the Guide to Corporate Equality. So, our goal is to measure how companies do on gender and then share that with the public.

+ +

And I didn't just make this up. We use a set of principles called the UN Women Empowerment Principles, which look at eight different sort of areas of an organization. And so, we created metrics that are based on these UN Women Empowerment Principles and also based on what is findable in the public record. We rate consumer-facing public companies, you know, like Unilever, Procter & Gamble, the shampoos that you use, the cars that you buy, the airplanes you ride on.

+ +

And we look at five major categories, such as, like, women in leadership. We look at employee policies like parental leave, and flex time, part-time, summer Fridays. I'll be curious to know what you do at Giant Robot. I bet you have good ones. And then, we also look at diversity reporting. Our company is upfront with their attempt to bring more diversity into the workforce and also supplier diversity. I don't know, are you familiar with supplier diversity, Chad?

+ +

CHAD: I am because we often are a supplier, so...

+ +

AMY-WILLARD: You are. So, when they ask you if you're diverse...but one way companies, especially the big companies that we rate on this public database, they can make a big impact by trying to buy from women and minority-owned businesses, right? When procurement spending is huge. That's a metric that people may not know as well, but it's one that I would encourage every business to undertake because it's not that expensive. And you could just intentionally try to move capital into communities that are not typically the most rewarded.

+ +

The last category that we measure is philanthropy for women, and that's important. People say, "Well, why do you measure philanthropy?" One, because the amount of philanthropy that goes to women and girls is 1.5% of all donations, and it used to be 1.8. So, pets get more money than women. I don't know how that makes you feel, Chad, but it doesn't make me feel very happy. I mean, I suppose if you're Monster Beverage and you don't have any women clientele, one, it's okay if you don't score well on your gender metrics; just meet the basic fairness. But maybe Monster Beverage doesn't have to donate to the community of women.

+ +

But if you're making billions of dollars a year selling a shampoo, I would sort of think it's fair to ask that there's some capital that goes back the other way towards the community of women. So, that's the measurement. So, we could do it...and we do it for small companies like yours, too. I imagine your company would do well from the little bit I've talked to people on your staff. It sounds like you have a lot of women in leadership. And I don't know your policies yet, but I'm sure you...I bet in Massachusetts I know you have parental leave anyway in the state, but you're a more progressive state.

+ +

But I think this is something that all of your listeners can benefit from is putting a gender lens on their operations because a gender lens is a fairness lens. And it includes usually, you know, this includes people who are not just all the same men, White men. So, it helps all businesses sort of operate in a more fair way to put a gender lens on their operations. And it's not hard to do.

+ +

CHAD: So, one of the things that jumped out at me, in addition to just the Gender Fair mission, as I was learning about Gender Fair, is that you have an app and a browser extension. And so, that's part of why you're on the show, not only do we care about the impact you're having.

+ +

AMY-WILLARD: That's right. Yeah [laughs].

+ +

CHAD: But you're a tech company. Did you always know as you got started that you were going to be making an app and a browser extension?

+ +

AMY-WILLARD: Well, yes, that was the beginning because you have data. You have to make it used. You have to make it available, right? Personally, I like to see it on packages. But yes, we've had two iterations of the app, and I'm sure it could always get better and better. The current one has a barcode scanner and, also, it can look at a logo and tell you, "Oh, this soda pop is not gender fair. Try this soda pop, which is gender fair." And it can make you a shopping list and stuff like that.

+ +

But, you know, tech is only good if people use it, so I hope they do. I mean, the idea is making it more accessible to people, right? I would like to have it as a filter, some easy tech. We've talked to big retailers before about having a filter put on online shopping sites, right? So, if I can choose fair-trade coffee, why can't I choose gender-fair shampoo?

+ +

I like it when people can use technology to create more fairness, right? If this is a great benefit to us if technology can take this journalism we do and make it accessible and available and in your hand for someone, you can do it in the store, for Pete's sake. You could just go on the store shelf, and that's pretty liberating, isn't it? When you think of it. It should be easy to know how the companies from which you buy are doing on values that you care about. So, I never really thought of it as a tech. I wish it was better tech, but, you know, I'd need millions and millions of dollars to do that.

+ +

CHAD: [laughs] Had you ever built in any of your prior companies, or had been directly responsible for the creation of an app?

+ +

AMY-WILLARD: No, but I did actually once when I worked at the major women's magazine in Canada, I did hire the person who created the first online sort of magazine in Canada, and she made money, so I felt good about that. I plucked her from...she was working as sort of tech support at the major...what do you call those? Internet providers in Canada. But no, I had not, and so I relied on experts.

+ +

I had a friend who was on the board of Southby, and he helped me find a tech team. I went through a few of them and, you know, it's hard to find. Like, where do you go and find people who will build something for you when you're a novice, right? As a journalist, I don't really know anything about building technology, and I certainly wasn't about to start at my age. It was definitely a voyage of discovery and learning, and I don't think I really learned much coding myself.

+ +

CHAD: That's okay.

+ +

AMY-WILLARD: That's okay [laughs].

+ +

CHAD: But was there something that sort of surprised you that you didn't anticipate in the process of creating a digital app?

+ +

AMY-WILLARD: Oh gosh. Well, you know, of course, it's difficult, and there's lots of iterations, and there's lots of bugs. And in every business, mistakes are part of what people...in the construction industry, they'll tell you, "Mistakes are just going to happen every day. You just have to figure out how to fix each one." But, no, it's a difficult road. So yeah, I wish I could have coded it myself. I wish I could have done it myself, but I could not. But yeah, it's good learning.

+ +

And, of course, you know, I think anyone who's going to start building a company with technology...if it were me now 10 years ago, I would have actually done some coding classes so I could just even communicate better to people who were building for me. But I did learn something, but not really enough. But it's a very interesting partnership, that's for sure.

+ +

CHAD: And there is a lot of online classes now...

+ +

AMY-WILLARD: Right [laughs].

+ +

CHAD: If someone is out there thinking, oh, you know, maybe that's good advice. And there's a lot of opportunities for sort of an on-ramp, and you don't need to become an expert.

+ +

AMY-WILLARD: No.

+ +

CHAD: But, like you said, even just knowing the vocabulary can be helpful.

+ +

AMY-WILLARD: I think that would have been useful. Yeah, definitely useful. But I definitely, like, you learn a little bit as a text-based person. You learn the rigor of just sort of, like, you have to think in ones and zeros. It either is or isn't. That helps. I learned that a little bit in working with tech devs. The last version we did actually white labeled off of someone who had created a technology to do with...it was to do with building communities online. And their project failed, but it had enough backbone that we were able to efficiently build what we needed to on top of what they built.

+ +

CHAD: Oh, that's really...was it someone you knew already, or how did you get connected?

+ +

AMY-WILLARD: Yes, they knew one of our partners in New York. We tried it first as a community project. It didn't really work. And then, we realized it could actually hold our data at the same time. So, my first iteration of the app was different. But yeah, anyway, we've built it a couple of times, and I could build it even more times...

+ +

CHAD: [laughs]

+ +

AMY-WILLARD: And make it even better and better.

+ +

CHAD: So, on the sort of company side of you've worked with companies like Procter & Gamble, MasterCard, Microsoft, do you find it difficult to convince companies to participate?

+ +

AMY-WILLARD: What we do is data journalism. We don't contact the companies. We have researchers. We have journalists go and look through the SEC data and CSR reports and collect the data points on which we measure them. So, no one has to cooperate with us to get the data. It's journalism. It's not opt-in surveys, which is a very common...when I first started, no one was measuring women, and now there's lots of different measurements. And they're often pay-to-play surveys, so they're not really very valuable. Ours is objective and fully transparent journalism.

+ +

But then afterwards, our business model how we typically used to pay for this is that companies that did well on our index were then invited to be quote, "certified." And this was a business model that was sort of suggested to us at the Clinton Global Initiative, to which I belonged in 2016. And they loved what we were doing, using the free market to drive gender equality. Because, you know, our whole point is that women and people who care about women and equality, we have a lot of power as consumers, or as taxpayers, or as tuition payers, or as donors to nonprofits. And whenever you give money to an organization or a company, you have the right to sort of ask questions about the fairness of that organization. Well, that's our whole ethic, really.

+ +

I answered that question and came around to a different idea, but yes, no. So, the companies do participate to be certified, and some of them are interested and some of them are not, and that's fine. We do projects with them sort of like when we...we've talked about MasterCard, and we did a big conference with them in New York. This is pre-pandemic. And then, we did a big, global exhibit with P&G, and Eli Lilly, and Microsoft at TED Global, which was very fun. It was all about fairness. And it was great to talk to technologists such as yourself. And we made a booth about fairness in general, not just about women. And we had a fairness game, and it was very interesting to just discuss with people.

+ +

 I think people like to think about fairness, right? I don't know if you have children, but little children get very interested in the idea of what's fair very early on. Yeah, so some companies participate...now we have companies...we do some work in B2B procurement which is something that your listeners might be interested in thinking about is that just, like, supplier diversity. If I were purchasing your services, your company services, I would ask about the gender metrics of your organization. I already learned they're quite good.

+ +

So, big companies buying from other companies can put a gender lens on their B2B procurement. And so, that's a project we're doing with Salesforce, Logitech, Zoetis, Andela, which is another tech provider, and Quinnox, which is a similar sort of tech labor force, I believe. And so, we're going to be releasing a database about B2B suppliers. Actually, I should make sure that you get on it. That's a good idea.

+ +

CHAD: Yes.

+ +

AMY-WILLARD: That's a good idea because then it's going to be embedded in procurement platforms because this is a huge amount of money. It's even probably more...it could be more money than consumer spending, right? B2B spending. So, I'm excited about working with more companies on that to help promulgate this data and this idea because it's an easy way to drive fairness in a culture. When the government isn't requiring fairness, at least large companies can. And in some countries, actually, the government requires its vendors to do well on gender. Like, Italy now has a certification for gender, the government does, and companies that do well are privileged in RFPs and also get a tax deduction.

+ +

CHAD: I don't want to say something incorrect, but I think the UK has, like, a rule around equity in pay...

+ +

AMY-WILLARD: Yeah, absolutely. You're absolutely correct.

+ +

CHAD: And yet they don't have equity in pay, the data shows.

+ +

AMY-WILLARD: That's right. And we don't have that in the United States. It's voluntary in the U.S. We measure that, actually, too. That's seven points over a hundred points scale is whether they, one, publish the results of their pay study. In the U.S., though, we do it in a way that isn't rigorous as the way they do it in the UK. In the UK...you're great to remember that, Chad, in the UK, I mean, I wish my government did that.

+ +

In the UK, companies report on the overall salaries paid to men and the overall salaries paid to women. So, that means if, you know, all the million-dollar jobs are held by men, it shows very clearly, and all the five-dollar jobs are held by women, it shows very clearly there's an imbalance. And in the United States, we just say, "Oh, well, is the male VP paid the same as a female VP?" That's sort of easier to do, right?

+ +

CHAD: When we've talked with some larger companies about different products we're creating or those kinds of things, sometimes what I hear is they're looking for big wins, comprehensive things. And so, I was wondering whether you ever get pushback or feedback that's like, "Well, not that your issue is not important, but it's just focused on one aspect of what our goals are for this year."

+ +

AMY-WILLARD: Right. Yeah, that's always a hard thing because when I think about fairness to half of the population, it's a hard thing for me to think that's not hugely important.

+ +

CHAD: Yes.

+ +

AMY-WILLARD: I have a really hard time, but yes, of course, we get that a lot. And, you know, quite frankly, when we did this B2B project with Logitech and Zoetis, they would ask their vendors, like, the major consulting companies and big companies, to take a SaaS assessment that we do. We have a SaaS product that private companies can take, or just instead of doing our journalism, they can just get their own assessment. And they were very, very reluctant to do this. That was just, you know, half an hour. It was a thousand-dollar assessment. And it took many months to convince these companies to do it. And that was their big customers.

+ +

So, yes, it is very hard to have...what's the word? Coherence on what one company wants versus what a big company wants, and it's hard to know what they want. And it's, yeah, that's a difficult road for sure. And it changes [laughs].

+ +

CHAD: Part of the reason why I asked is because from a product perspective, from a business perspective, at thoughtbot, we're big fans of, like, what can be called, like, niching down or being super clear about who you are, and what you believe, and what you offer. And if you try to be everything to everybody, it's usually not a very good tactic in the market.

+ +

AMY-WILLARD: That's right. That's right.

+ +

CHAD: So, the fact that you focus on one particular thing like you said, it's very important, and it's 50% of the population. But I imagine that focus is really healthy for you from a clarity of purpose perspective.

+ +

AMY-WILLARD: That's right. But at the same time, now there's lots of...when I started in 2016, there weren't a lot of things in this space, and now there's many, many, many, many, many, many, so corporations that want to sort of connect to the community of women or do better for women. There's many different options. So, there's many flavors of this ice cream. Even though we're niche, the niche is very crowded, I would say, actually, and people are very confused.

+ +

I mean, I think I remember hearing from Heineken that they're assaulted daily by things to, you know, ways to support women in different organizations and events. And they said they took our call because we were different. But yeah, there's many competitors. But, I mean, that's the main thing. In any business, in any endeavor in life, one has to show one's value to the people who may participate, and that's a challenge everywhere, isn't it?

+ +

CHAD: Yeah.

+ +

AMY-WILLARD: But the niching down thing is...and interesting we hear a lot these days is that women are done. We've moved on from that. Now we care about racial equality, and we say, "That's a yes, and… We can't move on."

+ +

CHAD: Well, the data doesn't show that we've moved on.

+ +

AMY-WILLARD: The data doesn't show that at all, and we're going way backwards, as you well know. So, I mean, actually, I don't know if you know, there's something called the named executive officers in public companies. Are you familiar with that? The top five paid people.

+ +

CHAD: Yeah.

+ +

AMY-WILLARD: They have to be registered with the government. Well, that number really hasn't changed in six years. That's where the big capital is, and the stock options, and the bonuses, and the big salaries. So, to me, that's very important that I would like, you know, rights and capital to be more...well, I want rights to be solid and capital to be flowing. And so, that's what we hope to do in our work.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: So, going back to the founding of Gender Fair, when did you know that this was something you needed to do?

+ +

AMY-WILLARD: I wanted to serve, you know, you want to be useful in life. And I wanted to do work in this field that I care so much about. As I said, I think I told you I started doing journalism before, and I realized anyone could take the journalism, and they could, you know, Upworthy would publish things we would create and then not pay us for it. And I thought that's crazy.

+ +

But it's interesting talking to my husband. My husband's, like, a very privileged White guy. And I remember he said something to me very interesting. He said, "You either have power, or you take it." And he said, "Women have all this power." So, he helped me understand this. Like, you know, I think sometimes as women or communities that are underserved, you start thinking very oppositionally about what you don't have. But at the same time, you can realize that you do have this power.

+ +

So, what we're trying to do with Gender Fair is remind people they have this economic power, and they can use it everywhere, you know, in addition to our consumer database. I told you that we're doing a B2B database this year. And we also...I think next week I'm going to release a database of 20,000 nonprofits looking at their gender ratings. That was done as a volunteer project by Rose-Hulman Institute of Technology if you know them. So, yeah, this is an ethic that you can take everywhere in your life is you have this power, even as a consumer. Chad, even in your little town, you can ask your coffee shop if they pay fair wages. Like, this is just a way of looking at the world that I hope to encourage people to do.

+ +

CHAD: Along the journey of getting started, I assume you ran into many roadblocks.

+ +

AMY-WILLARD: Mm-hmm.

+ +

CHAD: Did you ever think maybe this is too hard?

+ +

AMY-WILLARD: Oh yes. Well, not in building. In building, you're very optimistic, you know, it's just like when you're writing your first book. You think it's going to be a bestseller. Like, you build something, and you think the whole world is going to use it right away, and you're going to...I did have a great...when I first launched, I had a wonderful, I had, you know, press in Fortune. I had Chelsea Clinton. I had big people writing about us. Melinda Gates has written about us many, many times.

+ +

The fact that...well, I've always wanted to build, like, a consumer revolution of women, and I'm going to keep at it. But it's very daunting. It's very daunting when you're trying to move a boulder such as, you know, big institutions and companies that don't really want to change, and they're not motivated to do it. So, yes, those are my roadblocks.

+ +

It's not creating the massive amount of change that I wanted to do. And I'm not going to give up, but, yes, it is very daunting, and it's very daunting to see how little people care. Some people don't care about it, but some people in power don't care about it. But I think if you asked, you know, regular women, they would say, "We would like fair pay. We would like equal opportunity. We would like paid parental leave." They would want all these things, and hopefully, together, we can fight for them.

+ +

CHAD: Well, and, like you said, the premise of what you're doing is you're focused on the power that you do have, which is the dollars that you spend with these companies. I think that's such a smart angle on this because especially for...it seems like the core in terms of the consumer-facing companies. That's so inherent in what this is.

+ +

AMY-WILLARD: That's right.

+ +

CHAD: Yeah, the angle of empowering consumers, and giving them the information, and leveraging the power that consumers have with these companies seems really smart to me...

+ +

AMY-WILLARD: That's right. If it works --

+ +

CHAD: As opposed to individually going to the companies and saying, you know --

+ +

AMY-WILLARD: "Please make it." Yeah. And some people would refute your use of the word empower because that implies that people don't have power. So, when I give speeches...I have a pair of beautiful gemstone red pumps, and I say it's the ruby slippers. We had this power all along. We just were not exercising it. But this power will only work, Chad, if it's done in the aggregate.

+ +

So, our challenge is to reach the aggregate of American women. I have to, you know, I have to go reach 50 million women this year. That's my goal. Reach 50 million women with this message that we have the power in the aggregate to make change. And that's the only way this will work. If it's just one by one, it really doesn't.

+ +

When I first launched, I found when I showed the app to people on the lower end of the economic scale, like, you know, people in the cash register; they understood this more than middle-class women. They understood the fact that if all women come together and, you know, buy from this company or don't buy from this company based on how they treat women, they understood that as a collective power. Whereas middle-class women who don't have as many struggles didn't really groove to that idea as quickly, which I thought was very...to me, it was very interesting, you know, individuals feel more powerful on the higher end of the social scale. They may or may not --

+ +

CHAD: That is interesting.

+ +

AMY-WILLARD: Yeah. So, yeah, that's my goal. We'll see if I can do it. That's going to be my life's work, I think, Chad.

+ +

CHAD: How do you reach 50 million people?

+ +

AMY-WILLARD: I don't know. That's what I'm going to think about. You know, we're talking to different people about campaigns. We actually stopped the consumer work during the pandemic because it just, you know, everything changed. And so, now, this year, we're going back. I don't know; I mean, I guess if Ryan Reynolds tweeted about me, you know, that would help. If [laughs] anyone listening has any ideas how to reach 50 million women...no, maybe 3 million is what I need to create social change.

+ +

CHAD: I imagine that it doesn't just come down to spending money on advertising. One, you might not have that money.

+ +

AMY-WILLARD: No. And that would be, you know, that also would be not in the ethics of what Gender Fair is, for example, right? That means I would be paying money to Facebook and basically Facebook, I guess, and Google. If you look at the major spends of nonprofits, they're advertising with these big tech giants. And so, we have...actually, we have some partnerships with large women's organizations, and I think that's the way we hope to spread that. And if I had money for advertising, I would want to spend it with other women's organizations, or women's owned media, or women influencers.

+ +

There's another idea I talk about in my work I call the female domestic product, and so talking about how much money women earn or capital we control. And the more we can grow that female domestic product, the more we can achieve equality actually. I always say, in America, you get as much equality as you can pay for sadly.

+ +

CHAD: I was just about to say, "Sadly."

+ +

AMY-WILLARD: Sadly, yeah. It's true. We still don't have the Equal Rights Amendment. A hundred years.

+ +

CHAD: Well, 50% of the population would say, "Why do we need an Equal Rights Amendment [laughs]?"

+ +

AMY-WILLARD: All men are created equal, but yeah, it's quite astonishing. I don't know. Do you have daughter, too, or just a son?

+ +

CHAD: I have a son, and my younger one is non-binary.

+ +

AMY-WILLARD: Well, I'm sorry to be so binary. Excuse me.

+ +

CHAD: It's okay.

+ +

AMY-WILLARD: Well, interesting. And that's great, too, isn't it? Because we see how fluid gender is and their rights are just as important as a woman's rights. And these are, you know, women and non-binary people are often excluded from things. And so, we are all working together just to create fairness. I'm sure that the same thing happens in your family, too.

+ +

CHAD: Yeah. I think fairness is one of those things. Sometimes equality is not necessarily the same as fairness.

+ +

AMY-WILLARD: Yes.

+ +

CHAD: But I think, like you said at the top of the show, fairness is something that we seemingly learn very early on. But one of the ways that it comes across is I'm being. It is unfair to me, especially in little kids, at least with my kids [laughs].

+ +

AMY-WILLARD: Of course, yes.

+ +

CHAD: That was the thing that they learned first and caused them the most pain. And it was very difficult for them to see that something was unfair for somebody else. So, I remember saying to my kids when they were little, "Fair doesn't mean you get your way."

+ +

AMY-WILLARD: That's right. Not fair.

+ +

CHAD: Right [laughs].

+ +

AMY-WILLARD: It's true. But then, you know, it's funny. When I talk about equal pay, I often say to people, "When I used to cut cakes for my children, I cut equal slices, and I didn't put them under the table," like, you know what I mean [laughter]? So, why are we so cagey about the slices of economic pie we give to one another?

+ +

I mean, there's no reason why pay has to be secret, right? If it's fair. You could easily talk to people. Well, you know, Chad gets paid more money because he's the CEO, and he does the podcast, and he has to talk to the bank, you know what I mean? So, you could easily explain that to people. And I don't know why we have to keep salaries a secret from one another. It seems very irrational to me and not really a part of fairness.

+ +

CHAD: Yeah. Yep. That's something...so, all of our salary bands at thoughtbot are public on the internet.

+ +

AMY-WILLARD: Cool. On the internet. Oh, I'm very impressed.

+ +

CHAD: Yeah. So, you can go to thoughtbot and use our compensation calculator. You enter in your location, what role you have.

+ +

AMY-WILLARD: Oh. So, you do it for other people. Oh, that's cool. That's a great service. And that was just some sort of tech that was sort of pro bono tech that you all built for the world.

+ +

CHAD: Yeah, we created it for ourselves.

+ +

AMY-WILLARD: And then you shared it.

+ +

CHAD: Mm-hmm.

+ +

AMY-WILLARD: Then you open-sourced it. Great. Well, I bet you have a lot of happy employees.

+ +

CHAD: I like to think so [laughs]. I do think that there is an inherent understanding of fairness. And when people ask how we do things at thoughtbot or how we should do things, I say, "How do you want it to be?" I think that guides a lot of how we do things and why a lot of stuff we do is just common sense. And it's not until ulterior motives or maintaining power comes into play where the people in power don't want to give it up. Because, like you said, people don't understand that by giving someone else a bigger piece, they think that that means their piece is smaller.

+ +

AMY-WILLARD: Right. Or they just think they deserve it. I was reading last night about succession planning and CEOs. And apparently, a lot of them just stay...oh, sorry, in big public companies, not in their own companies, they stay on way too long. And all these consultants are saying it's the four Ps, you know, position, privilege, pay, and then...I forget the other one. But one of them was jets. They don't want to give up their jets.

+ +

So yeah, I think when you have things, it seems fair, and sharing them seems...giving up some of what you have seems unfair. But I do think humans can see fairness. But sometimes, when you have a lot, it's hard to see it. You're able to justify why it may be not unfair to people who don't have as much as you do. But anyway, I can't change human nature, but most people do understand fairness. I think you're right about that.

+ +

CHAD: Well, one thing...I noticed...so, you're a Public Benefit Corporation.

+ +

AMY-WILLARD: Yes.

+ +

CHAD: Did you set out to be a Public Benefit Corporation from day one?

+ +

AMY-WILLARD: Yes, you know, originally, when it came to how was I going to pay for this, the first part I paid myself with my own money. I hired MBAs. I hired researchers. I built the tech. And then, I wasn't sure how I was going to pay for it going forward. But I knew I didn't want to become a nonprofit because, in my mind, there are so many things that...there are so many problems that women have that need to be solved by nonprofit organizations, planned parenthood first among them.

+ +

Like, I don't want to take money away from women's organizations that help women fleeing abusive homes. So, I wanted to see if I could pay for this in the private sphere, which we've been able to do, and not have to seek donations because, really, I felt very strongly about not taking money out of that.

+ +

That's part of the FDP, the part of the female domestic product, but the part that's contributed by people philanthropically. And there isn't a lot of philanthropic dollars going to women, as I mentioned before. So, yes, I knew definitely I wanted to be a Public Benefit Corporation. And there's no tax benefits to that, you know, I don't know if you are yet, but...

+ +

CHAD: No, it's something that we've looked at, but it's very attractive to me.

+ +

AMY-WILLARD: Right. And there's also the private version of it being a B Corp, which is also very useful. It's an onerous process. Public Benefit Corporation isn't quite as onerous, I don't believe. I mean, we're in Delaware and New York, but it just says that you're, I mean, we exist for the public good. I'm not existing to make millions of dollars. I'm existing to create social change. And some organizations don't want...are leery of working with us because we're not a nonprofit so that's to assuage them. Well, it's not really about...we're not about enriching shareholders. It's just a different way to pay for it.

+ +

But yeah, I would encourage all companies to look into being a Public Benefit Corporation or do a B Corp assessment or a Gender Fair assessment. It helps them, you know, operate in a world that is increasingly more values concerned. Maybe 20 or 30 years ago, it wasn't so on the top of mind of many people. We were coming out of, you know, warring '80s capitalism. But nowadays, the younger people, especially, are very focused on issues of fairness and equality. So, I think those tools making business better that way are very useful.

+ +

CHAD: Well, I would encourage, you know, everyone listening to go check out the app, if you're at a company, to look at doing the assessment. Where can people do those things?

+ +

AMY-WILLARD: Ah, well, yeah, I would encourage them to do all those things. You're right, Chad. I would encourage you to download the app and check some of your favorite brands. It's very simple. Do the paid subscription.

+ +

And then, if you're a company, you can do an online assessment. You just go Gender Fair assessment, and you'll find it. If you're a business and would like to participate in our B2B database, you can also do the assessment, or there's a coalition for Gender Fair procurement, where you can get information. We had the prime minister of Australia speak at our launch. It was quite excellent.

+ +

We'll be launching our nonprofit. Actually, I think it's already online. It's called genderfair-nonprofits.org, if you want to see how your favorite nonprofits do. But, basically, we're here to help any business or organization do better on gender. And you can email me amy.cross@genderfair.com. And I would love to help anyone in their journey for fairness of any kind. Yeah, many ways to participate. Just go to genderfair.com or genderfairprocurement.com.

+ +

CHAD: Awesome. Amy, thank you so much for sharing with us. I really appreciate it. And thank you for all the good that you're doing in the world with Gender Fair.

+ +

AMY-WILLARD: Well, I appreciate the way you're running your company in a very new, interesting, and apparently ethical way. Privately, I could look at your website and your career page and figure out how you're doing. But it sounds, to me, when I've talked to people, that you're doing very well. And I honor your curiosity about learning from others.

+ +

CHAD: Awesome. Well, listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon @cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Founder Amy-Willard Cross discusses the mission and operations of Gender Fair, the first consumer rating system for gender equality. Gender Fair aims to measure and promote gender equality within consumer-facing companies by utilizing data and the UN Women Empowerment Principles. Amy highlights the importance of transparency and data-driven insights to create social change, emphasizing that gender equality in corporate practices benefits not just women but overall fairness in the workplace. Gender Fair evaluates companies across five categories: women in leadership, employee policies, diversity reporting, supplier diversity, and philanthropy for women.

+ +

Amy also shares how Gender Fair has incorporated technology to increase its impact, including an app and browser extension that allow consumers to easily access company ratings on gender equality. These tools enable users to make informed purchasing decisions based on a company's gender equality practices. The app features functionalities like barcode scanning and logo recognition to provide real-time information about products. Amy emphasizes the significance of making gender equality data accessible and actionable for consumers, believing that collective consumer power can drive corporate accountability and fairness.

+ +

Throughout the conversation, Amy discusses the challenges and successes of building Gender Fair, the importance of leveraging economic power for social change, and the role of technology in facilitating gender fairness. She also touches on the broader impact of Gender Fair's work in promoting fair business practices and the potential for future expansions, such as a B2B database for procurement.

+ + + +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Amy-Willard Cross, the Founder of Gender Fair, the first consumer rating system for gender equality. Amy, thank you so much for joining me.

+ +

AMY-WILLARD: Well, I'm very happy to be talking to robots, giant and small.

+ +

CHAD: [laughs] We'll try not to smash into each other too much on this show. I think we probably have a lot to learn from each other rather than conflicting.

+ +

AMY-WILLARD: I think so.

+ +

CHAD: Let's just get started by digging in a little bit to what Gender Fair actually is in terms of what we mean when we say a consumer rating system for gender equality.

+ +

AMY-WILLARD: It's about data. So, I was originally a journalist. I've written for a living my whole life: books, magazines, articles [laughs], you know, radio shows. I wanted to do something to promote equality in the world. And I realized that data is one way that you can want to have commercial value. Data has value that isn't, like, just blah, blah, blogging, and also, data can create social change.

+ +

So, I decided to do something like, you know, we know fair trade has created great change as has, you know, marine stewards certified. And also, I was inspired by something that the Human Rights Campaign, the LGBTQ organization, does, which is called the Guide to Corporate Equality. So, our goal is to measure how companies do on gender and then share that with the public.

+ +

And I didn't just make this up. We use a set of principles called the UN Women Empowerment Principles, which look at eight different sort of areas of an organization. And so, we created metrics that are based on these UN Women Empowerment Principles and also based on what is findable in the public record. We rate consumer-facing public companies, you know, like Unilever, Procter & Gamble, the shampoos that you use, the cars that you buy, the airplanes you ride on.

+ +

And we look at five major categories, such as, like, women in leadership. We look at employee policies like parental leave, and flex time, part-time, summer Fridays. I'll be curious to know what you do at Giant Robot. I bet you have good ones. And then, we also look at diversity reporting. Our company is upfront with their attempt to bring more diversity into the workforce and also supplier diversity. I don't know, are you familiar with supplier diversity, Chad?

+ +

CHAD: I am because we often are a supplier, so...

+ +

AMY-WILLARD: You are. So, when they ask you if you're diverse...but one way companies, especially the big companies that we rate on this public database, they can make a big impact by trying to buy from women and minority-owned businesses, right? When procurement spending is huge. That's a metric that people may not know as well, but it's one that I would encourage every business to undertake because it's not that expensive. And you could just intentionally try to move capital into communities that are not typically the most rewarded.

+ +

The last category that we measure is philanthropy for women, and that's important. People say, "Well, why do you measure philanthropy?" One, because the amount of philanthropy that goes to women and girls is 1.5% of all donations, and it used to be 1.8. So, pets get more money than women. I don't know how that makes you feel, Chad, but it doesn't make me feel very happy. I mean, I suppose if you're Monster Beverage and you don't have any women clientele, one, it's okay if you don't score well on your gender metrics; just meet the basic fairness. But maybe Monster Beverage doesn't have to donate to the community of women.

+ +

But if you're making billions of dollars a year selling a shampoo, I would sort of think it's fair to ask that there's some capital that goes back the other way towards the community of women. So, that's the measurement. So, we could do it...and we do it for small companies like yours, too. I imagine your company would do well from the little bit I've talked to people on your staff. It sounds like you have a lot of women in leadership. And I don't know your policies yet, but I'm sure you...I bet in Massachusetts I know you have parental leave anyway in the state, but you're a more progressive state.

+ +

But I think this is something that all of your listeners can benefit from is putting a gender lens on their operations because a gender lens is a fairness lens. And it includes usually, you know, this includes people who are not just all the same men, White men. So, it helps all businesses sort of operate in a more fair way to put a gender lens on their operations. And it's not hard to do.

+ +

CHAD: So, one of the things that jumped out at me, in addition to just the Gender Fair mission, as I was learning about Gender Fair, is that you have an app and a browser extension. And so, that's part of why you're on the show, not only do we care about the impact you're having.

+ +

AMY-WILLARD: That's right. Yeah [laughs].

+ +

CHAD: But you're a tech company. Did you always know as you got started that you were going to be making an app and a browser extension?

+ +

AMY-WILLARD: Well, yes, that was the beginning because you have data. You have to make it used. You have to make it available, right? Personally, I like to see it on packages. But yes, we've had two iterations of the app, and I'm sure it could always get better and better. The current one has a barcode scanner and, also, it can look at a logo and tell you, "Oh, this soda pop is not gender fair. Try this soda pop, which is gender fair." And it can make you a shopping list and stuff like that.

+ +

But, you know, tech is only good if people use it, so I hope they do. I mean, the idea is making it more accessible to people, right? I would like to have it as a filter, some easy tech. We've talked to big retailers before about having a filter put on online shopping sites, right? So, if I can choose fair-trade coffee, why can't I choose gender-fair shampoo?

+ +

I like it when people can use technology to create more fairness, right? If this is a great benefit to us if technology can take this journalism we do and make it accessible and available and in your hand for someone, you can do it in the store, for Pete's sake. You could just go on the store shelf, and that's pretty liberating, isn't it? When you think of it. It should be easy to know how the companies from which you buy are doing on values that you care about. So, I never really thought of it as a tech. I wish it was better tech, but, you know, I'd need millions and millions of dollars to do that.

+ +

CHAD: [laughs] Had you ever built in any of your prior companies, or had been directly responsible for the creation of an app?

+ +

AMY-WILLARD: No, but I did actually once when I worked at the major women's magazine in Canada, I did hire the person who created the first online sort of magazine in Canada, and she made money, so I felt good about that. I plucked her from...she was working as sort of tech support at the major...what do you call those? Internet providers in Canada. But no, I had not, and so I relied on experts.

+ +

I had a friend who was on the board of Southby, and he helped me find a tech team. I went through a few of them and, you know, it's hard to find. Like, where do you go and find people who will build something for you when you're a novice, right? As a journalist, I don't really know anything about building technology, and I certainly wasn't about to start at my age. It was definitely a voyage of discovery and learning, and I don't think I really learned much coding myself.

+ +

CHAD: That's okay.

+ +

AMY-WILLARD: That's okay [laughs].

+ +

CHAD: But was there something that sort of surprised you that you didn't anticipate in the process of creating a digital app?

+ +

AMY-WILLARD: Oh gosh. Well, you know, of course, it's difficult, and there's lots of iterations, and there's lots of bugs. And in every business, mistakes are part of what people...in the construction industry, they'll tell you, "Mistakes are just going to happen every day. You just have to figure out how to fix each one." But, no, it's a difficult road. So yeah, I wish I could have coded it myself. I wish I could have done it myself, but I could not. But yeah, it's good learning.

+ +

And, of course, you know, I think anyone who's going to start building a company with technology...if it were me now 10 years ago, I would have actually done some coding classes so I could just even communicate better to people who were building for me. But I did learn something, but not really enough. But it's a very interesting partnership, that's for sure.

+ +

CHAD: And there is a lot of online classes now...

+ +

AMY-WILLARD: Right [laughs].

+ +

CHAD: If someone is out there thinking, oh, you know, maybe that's good advice. And there's a lot of opportunities for sort of an on-ramp, and you don't need to become an expert.

+ +

AMY-WILLARD: No.

+ +

CHAD: But, like you said, even just knowing the vocabulary can be helpful.

+ +

AMY-WILLARD: I think that would have been useful. Yeah, definitely useful. But I definitely, like, you learn a little bit as a text-based person. You learn the rigor of just sort of, like, you have to think in ones and zeros. It either is or isn't. That helps. I learned that a little bit in working with tech devs. The last version we did actually white labeled off of someone who had created a technology to do with...it was to do with building communities online. And their project failed, but it had enough backbone that we were able to efficiently build what we needed to on top of what they built.

+ +

CHAD: Oh, that's really...was it someone you knew already, or how did you get connected?

+ +

AMY-WILLARD: Yes, they knew one of our partners in New York. We tried it first as a community project. It didn't really work. And then, we realized it could actually hold our data at the same time. So, my first iteration of the app was different. But yeah, anyway, we've built it a couple of times, and I could build it even more times...

+ +

CHAD: [laughs]

+ +

AMY-WILLARD: And make it even better and better.

+ +

CHAD: So, on the sort of company side of you've worked with companies like Procter & Gamble, MasterCard, Microsoft, do you find it difficult to convince companies to participate?

+ +

AMY-WILLARD: What we do is data journalism. We don't contact the companies. We have researchers. We have journalists go and look through the SEC data and CSR reports and collect the data points on which we measure them. So, no one has to cooperate with us to get the data. It's journalism. It's not opt-in surveys, which is a very common...when I first started, no one was measuring women, and now there's lots of different measurements. And they're often pay-to-play surveys, so they're not really very valuable. Ours is objective and fully transparent journalism.

+ +

But then afterwards, our business model how we typically used to pay for this is that companies that did well on our index were then invited to be quote, "certified." And this was a business model that was sort of suggested to us at the Clinton Global Initiative, to which I belonged in 2016. And they loved what we were doing, using the free market to drive gender equality. Because, you know, our whole point is that women and people who care about women and equality, we have a lot of power as consumers, or as taxpayers, or as tuition payers, or as donors to nonprofits. And whenever you give money to an organization or a company, you have the right to sort of ask questions about the fairness of that organization. Well, that's our whole ethic, really.

+ +

I answered that question and came around to a different idea, but yes, no. So, the companies do participate to be certified, and some of them are interested and some of them are not, and that's fine. We do projects with them sort of like when we...we've talked about MasterCard, and we did a big conference with them in New York. This is pre-pandemic. And then, we did a big, global exhibit with P&G, and Eli Lilly, and Microsoft at TED Global, which was very fun. It was all about fairness. And it was great to talk to technologists such as yourself. And we made a booth about fairness in general, not just about women. And we had a fairness game, and it was very interesting to just discuss with people.

+ +

 I think people like to think about fairness, right? I don't know if you have children, but little children get very interested in the idea of what's fair very early on. Yeah, so some companies participate...now we have companies...we do some work in B2B procurement which is something that your listeners might be interested in thinking about is that just, like, supplier diversity. If I were purchasing your services, your company services, I would ask about the gender metrics of your organization. I already learned they're quite good.

+ +

So, big companies buying from other companies can put a gender lens on their B2B procurement. And so, that's a project we're doing with Salesforce, Logitech, Zoetis, Andela, which is another tech provider, and Quinnox, which is a similar sort of tech labor force, I believe. And so, we're going to be releasing a database about B2B suppliers. Actually, I should make sure that you get on it. That's a good idea.

+ +

CHAD: Yes.

+ +

AMY-WILLARD: That's a good idea because then it's going to be embedded in procurement platforms because this is a huge amount of money. It's even probably more...it could be more money than consumer spending, right? B2B spending. So, I'm excited about working with more companies on that to help promulgate this data and this idea because it's an easy way to drive fairness in a culture. When the government isn't requiring fairness, at least large companies can. And in some countries, actually, the government requires its vendors to do well on gender. Like, Italy now has a certification for gender, the government does, and companies that do well are privileged in RFPs and also get a tax deduction.

+ +

CHAD: I don't want to say something incorrect, but I think the UK has, like, a rule around equity in pay...

+ +

AMY-WILLARD: Yeah, absolutely. You're absolutely correct.

+ +

CHAD: And yet they don't have equity in pay, the data shows.

+ +

AMY-WILLARD: That's right. And we don't have that in the United States. It's voluntary in the U.S. We measure that, actually, too. That's seven points over a hundred points scale is whether they, one, publish the results of their pay study. In the U.S., though, we do it in a way that isn't rigorous as the way they do it in the UK. In the UK...you're great to remember that, Chad, in the UK, I mean, I wish my government did that.

+ +

In the UK, companies report on the overall salaries paid to men and the overall salaries paid to women. So, that means if, you know, all the million-dollar jobs are held by men, it shows very clearly, and all the five-dollar jobs are held by women, it shows very clearly there's an imbalance. And in the United States, we just say, "Oh, well, is the male VP paid the same as a female VP?" That's sort of easier to do, right?

+ +

CHAD: When we've talked with some larger companies about different products we're creating or those kinds of things, sometimes what I hear is they're looking for big wins, comprehensive things. And so, I was wondering whether you ever get pushback or feedback that's like, "Well, not that your issue is not important, but it's just focused on one aspect of what our goals are for this year."

+ +

AMY-WILLARD: Right. Yeah, that's always a hard thing because when I think about fairness to half of the population, it's a hard thing for me to think that's not hugely important.

+ +

CHAD: Yes.

+ +

AMY-WILLARD: I have a really hard time, but yes, of course, we get that a lot. And, you know, quite frankly, when we did this B2B project with Logitech and Zoetis, they would ask their vendors, like, the major consulting companies and big companies, to take a SaaS assessment that we do. We have a SaaS product that private companies can take, or just instead of doing our journalism, they can just get their own assessment. And they were very, very reluctant to do this. That was just, you know, half an hour. It was a thousand-dollar assessment. And it took many months to convince these companies to do it. And that was their big customers.

+ +

So, yes, it is very hard to have...what's the word? Coherence on what one company wants versus what a big company wants, and it's hard to know what they want. And it's, yeah, that's a difficult road for sure. And it changes [laughs].

+ +

CHAD: Part of the reason why I asked is because from a product perspective, from a business perspective, at thoughtbot, we're big fans of, like, what can be called, like, niching down or being super clear about who you are, and what you believe, and what you offer. And if you try to be everything to everybody, it's usually not a very good tactic in the market.

+ +

AMY-WILLARD: That's right. That's right.

+ +

CHAD: So, the fact that you focus on one particular thing like you said, it's very important, and it's 50% of the population. But I imagine that focus is really healthy for you from a clarity of purpose perspective.

+ +

AMY-WILLARD: That's right. But at the same time, now there's lots of...when I started in 2016, there weren't a lot of things in this space, and now there's many, many, many, many, many, many, so corporations that want to sort of connect to the community of women or do better for women. There's many different options. So, there's many flavors of this ice cream. Even though we're niche, the niche is very crowded, I would say, actually, and people are very confused.

+ +

I mean, I think I remember hearing from Heineken that they're assaulted daily by things to, you know, ways to support women in different organizations and events. And they said they took our call because we were different. But yeah, there's many competitors. But, I mean, that's the main thing. In any business, in any endeavor in life, one has to show one's value to the people who may participate, and that's a challenge everywhere, isn't it?

+ +

CHAD: Yeah.

+ +

AMY-WILLARD: But the niching down thing is...and interesting we hear a lot these days is that women are done. We've moved on from that. Now we care about racial equality, and we say, "That's a yes, and… We can't move on."

+ +

CHAD: Well, the data doesn't show that we've moved on.

+ +

AMY-WILLARD: The data doesn't show that at all, and we're going way backwards, as you well know. So, I mean, actually, I don't know if you know, there's something called the named executive officers in public companies. Are you familiar with that? The top five paid people.

+ +

CHAD: Yeah.

+ +

AMY-WILLARD: They have to be registered with the government. Well, that number really hasn't changed in six years. That's where the big capital is, and the stock options, and the bonuses, and the big salaries. So, to me, that's very important that I would like, you know, rights and capital to be more...well, I want rights to be solid and capital to be flowing. And so, that's what we hope to do in our work.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: So, going back to the founding of Gender Fair, when did you know that this was something you needed to do?

+ +

AMY-WILLARD: I wanted to serve, you know, you want to be useful in life. And I wanted to do work in this field that I care so much about. As I said, I think I told you I started doing journalism before, and I realized anyone could take the journalism, and they could, you know, Upworthy would publish things we would create and then not pay us for it. And I thought that's crazy.

+ +

But it's interesting talking to my husband. My husband's, like, a very privileged White guy. And I remember he said something to me very interesting. He said, "You either have power, or you take it." And he said, "Women have all this power." So, he helped me understand this. Like, you know, I think sometimes as women or communities that are underserved, you start thinking very oppositionally about what you don't have. But at the same time, you can realize that you do have this power.

+ +

So, what we're trying to do with Gender Fair is remind people they have this economic power, and they can use it everywhere, you know, in addition to our consumer database. I told you that we're doing a B2B database this year. And we also...I think next week I'm going to release a database of 20,000 nonprofits looking at their gender ratings. That was done as a volunteer project by Rose-Hulman Institute of Technology if you know them. So, yeah, this is an ethic that you can take everywhere in your life is you have this power, even as a consumer. Chad, even in your little town, you can ask your coffee shop if they pay fair wages. Like, this is just a way of looking at the world that I hope to encourage people to do.

+ +

CHAD: Along the journey of getting started, I assume you ran into many roadblocks.

+ +

AMY-WILLARD: Mm-hmm.

+ +

CHAD: Did you ever think maybe this is too hard?

+ +

AMY-WILLARD: Oh yes. Well, not in building. In building, you're very optimistic, you know, it's just like when you're writing your first book. You think it's going to be a bestseller. Like, you build something, and you think the whole world is going to use it right away, and you're going to...I did have a great...when I first launched, I had a wonderful, I had, you know, press in Fortune. I had Chelsea Clinton. I had big people writing about us. Melinda Gates has written about us many, many times.

+ +

The fact that...well, I've always wanted to build, like, a consumer revolution of women, and I'm going to keep at it. But it's very daunting. It's very daunting when you're trying to move a boulder such as, you know, big institutions and companies that don't really want to change, and they're not motivated to do it. So, yes, those are my roadblocks.

+ +

It's not creating the massive amount of change that I wanted to do. And I'm not going to give up, but, yes, it is very daunting, and it's very daunting to see how little people care. Some people don't care about it, but some people in power don't care about it. But I think if you asked, you know, regular women, they would say, "We would like fair pay. We would like equal opportunity. We would like paid parental leave." They would want all these things, and hopefully, together, we can fight for them.

+ +

CHAD: Well, and, like you said, the premise of what you're doing is you're focused on the power that you do have, which is the dollars that you spend with these companies. I think that's such a smart angle on this because especially for...it seems like the core in terms of the consumer-facing companies. That's so inherent in what this is.

+ +

AMY-WILLARD: That's right.

+ +

CHAD: Yeah, the angle of empowering consumers, and giving them the information, and leveraging the power that consumers have with these companies seems really smart to me...

+ +

AMY-WILLARD: That's right. If it works --

+ +

CHAD: As opposed to individually going to the companies and saying, you know --

+ +

AMY-WILLARD: "Please make it." Yeah. And some people would refute your use of the word empower because that implies that people don't have power. So, when I give speeches...I have a pair of beautiful gemstone red pumps, and I say it's the ruby slippers. We had this power all along. We just were not exercising it. But this power will only work, Chad, if it's done in the aggregate.

+ +

So, our challenge is to reach the aggregate of American women. I have to, you know, I have to go reach 50 million women this year. That's my goal. Reach 50 million women with this message that we have the power in the aggregate to make change. And that's the only way this will work. If it's just one by one, it really doesn't.

+ +

When I first launched, I found when I showed the app to people on the lower end of the economic scale, like, you know, people in the cash register; they understood this more than middle-class women. They understood the fact that if all women come together and, you know, buy from this company or don't buy from this company based on how they treat women, they understood that as a collective power. Whereas middle-class women who don't have as many struggles didn't really groove to that idea as quickly, which I thought was very...to me, it was very interesting, you know, individuals feel more powerful on the higher end of the social scale. They may or may not --

+ +

CHAD: That is interesting.

+ +

AMY-WILLARD: Yeah. So, yeah, that's my goal. We'll see if I can do it. That's going to be my life's work, I think, Chad.

+ +

CHAD: How do you reach 50 million people?

+ +

AMY-WILLARD: I don't know. That's what I'm going to think about. You know, we're talking to different people about campaigns. We actually stopped the consumer work during the pandemic because it just, you know, everything changed. And so, now, this year, we're going back. I don't know; I mean, I guess if Ryan Reynolds tweeted about me, you know, that would help. If [laughs] anyone listening has any ideas how to reach 50 million women...no, maybe 3 million is what I need to create social change.

+ +

CHAD: I imagine that it doesn't just come down to spending money on advertising. One, you might not have that money.

+ +

AMY-WILLARD: No. And that would be, you know, that also would be not in the ethics of what Gender Fair is, for example, right? That means I would be paying money to Facebook and basically Facebook, I guess, and Google. If you look at the major spends of nonprofits, they're advertising with these big tech giants. And so, we have...actually, we have some partnerships with large women's organizations, and I think that's the way we hope to spread that. And if I had money for advertising, I would want to spend it with other women's organizations, or women's owned media, or women influencers.

+ +

There's another idea I talk about in my work I call the female domestic product, and so talking about how much money women earn or capital we control. And the more we can grow that female domestic product, the more we can achieve equality actually. I always say, in America, you get as much equality as you can pay for sadly.

+ +

CHAD: I was just about to say, "Sadly."

+ +

AMY-WILLARD: Sadly, yeah. It's true. We still don't have the Equal Rights Amendment. A hundred years.

+ +

CHAD: Well, 50% of the population would say, "Why do we need an Equal Rights Amendment [laughs]?"

+ +

AMY-WILLARD: All men are created equal, but yeah, it's quite astonishing. I don't know. Do you have daughter, too, or just a son?

+ +

CHAD: I have a son, and my younger one is non-binary.

+ +

AMY-WILLARD: Well, I'm sorry to be so binary. Excuse me.

+ +

CHAD: It's okay.

+ +

AMY-WILLARD: Well, interesting. And that's great, too, isn't it? Because we see how fluid gender is and their rights are just as important as a woman's rights. And these are, you know, women and non-binary people are often excluded from things. And so, we are all working together just to create fairness. I'm sure that the same thing happens in your family, too.

+ +

CHAD: Yeah. I think fairness is one of those things. Sometimes equality is not necessarily the same as fairness.

+ +

AMY-WILLARD: Yes.

+ +

CHAD: But I think, like you said at the top of the show, fairness is something that we seemingly learn very early on. But one of the ways that it comes across is I'm being. It is unfair to me, especially in little kids, at least with my kids [laughs].

+ +

AMY-WILLARD: Of course, yes.

+ +

CHAD: That was the thing that they learned first and caused them the most pain. And it was very difficult for them to see that something was unfair for somebody else. So, I remember saying to my kids when they were little, "Fair doesn't mean you get your way."

+ +

AMY-WILLARD: That's right. Not fair.

+ +

CHAD: Right [laughs].

+ +

AMY-WILLARD: It's true. But then, you know, it's funny. When I talk about equal pay, I often say to people, "When I used to cut cakes for my children, I cut equal slices, and I didn't put them under the table," like, you know what I mean [laughter]? So, why are we so cagey about the slices of economic pie we give to one another?

+ +

I mean, there's no reason why pay has to be secret, right? If it's fair. You could easily talk to people. Well, you know, Chad gets paid more money because he's the CEO, and he does the podcast, and he has to talk to the bank, you know what I mean? So, you could easily explain that to people. And I don't know why we have to keep salaries a secret from one another. It seems very irrational to me and not really a part of fairness.

+ +

CHAD: Yeah. Yep. That's something...so, all of our salary bands at thoughtbot are public on the internet.

+ +

AMY-WILLARD: Cool. On the internet. Oh, I'm very impressed.

+ +

CHAD: Yeah. So, you can go to thoughtbot and use our compensation calculator. You enter in your location, what role you have.

+ +

AMY-WILLARD: Oh. So, you do it for other people. Oh, that's cool. That's a great service. And that was just some sort of tech that was sort of pro bono tech that you all built for the world.

+ +

CHAD: Yeah, we created it for ourselves.

+ +

AMY-WILLARD: And then you shared it.

+ +

CHAD: Mm-hmm.

+ +

AMY-WILLARD: Then you open-sourced it. Great. Well, I bet you have a lot of happy employees.

+ +

CHAD: I like to think so [laughs]. I do think that there is an inherent understanding of fairness. And when people ask how we do things at thoughtbot or how we should do things, I say, "How do you want it to be?" I think that guides a lot of how we do things and why a lot of stuff we do is just common sense. And it's not until ulterior motives or maintaining power comes into play where the people in power don't want to give it up. Because, like you said, people don't understand that by giving someone else a bigger piece, they think that that means their piece is smaller.

+ +

AMY-WILLARD: Right. Or they just think they deserve it. I was reading last night about succession planning and CEOs. And apparently, a lot of them just stay...oh, sorry, in big public companies, not in their own companies, they stay on way too long. And all these consultants are saying it's the four Ps, you know, position, privilege, pay, and then...I forget the other one. But one of them was jets. They don't want to give up their jets.

+ +

So yeah, I think when you have things, it seems fair, and sharing them seems...giving up some of what you have seems unfair. But I do think humans can see fairness. But sometimes, when you have a lot, it's hard to see it. You're able to justify why it may be not unfair to people who don't have as much as you do. But anyway, I can't change human nature, but most people do understand fairness. I think you're right about that.

+ +

CHAD: Well, one thing...I noticed...so, you're a Public Benefit Corporation.

+ +

AMY-WILLARD: Yes.

+ +

CHAD: Did you set out to be a Public Benefit Corporation from day one?

+ +

AMY-WILLARD: Yes, you know, originally, when it came to how was I going to pay for this, the first part I paid myself with my own money. I hired MBAs. I hired researchers. I built the tech. And then, I wasn't sure how I was going to pay for it going forward. But I knew I didn't want to become a nonprofit because, in my mind, there are so many things that...there are so many problems that women have that need to be solved by nonprofit organizations, planned parenthood first among them.

+ +

Like, I don't want to take money away from women's organizations that help women fleeing abusive homes. So, I wanted to see if I could pay for this in the private sphere, which we've been able to do, and not have to seek donations because, really, I felt very strongly about not taking money out of that.

+ +

That's part of the FDP, the part of the female domestic product, but the part that's contributed by people philanthropically. And there isn't a lot of philanthropic dollars going to women, as I mentioned before. So, yes, I knew definitely I wanted to be a Public Benefit Corporation. And there's no tax benefits to that, you know, I don't know if you are yet, but...

+ +

CHAD: No, it's something that we've looked at, but it's very attractive to me.

+ +

AMY-WILLARD: Right. And there's also the private version of it being a B Corp, which is also very useful. It's an onerous process. Public Benefit Corporation isn't quite as onerous, I don't believe. I mean, we're in Delaware and New York, but it just says that you're, I mean, we exist for the public good. I'm not existing to make millions of dollars. I'm existing to create social change. And some organizations don't want...are leery of working with us because we're not a nonprofit so that's to assuage them. Well, it's not really about...we're not about enriching shareholders. It's just a different way to pay for it.

+ +

But yeah, I would encourage all companies to look into being a Public Benefit Corporation or do a B Corp assessment or a Gender Fair assessment. It helps them, you know, operate in a world that is increasingly more values concerned. Maybe 20 or 30 years ago, it wasn't so on the top of mind of many people. We were coming out of, you know, warring '80s capitalism. But nowadays, the younger people, especially, are very focused on issues of fairness and equality. So, I think those tools making business better that way are very useful.

+ +

CHAD: Well, I would encourage, you know, everyone listening to go check out the app, if you're at a company, to look at doing the assessment. Where can people do those things?

+ +

AMY-WILLARD: Ah, well, yeah, I would encourage them to do all those things. You're right, Chad. I would encourage you to download the app and check some of your favorite brands. It's very simple. Do the paid subscription.

+ +

And then, if you're a company, you can do an online assessment. You just go Gender Fair assessment, and you'll find it. If you're a business and would like to participate in our B2B database, you can also do the assessment, or there's a coalition for Gender Fair procurement, where you can get information. We had the prime minister of Australia speak at our launch. It was quite excellent.

+ +

We'll be launching our nonprofit. Actually, I think it's already online. It's called genderfair-nonprofits.org, if you want to see how your favorite nonprofits do. But, basically, we're here to help any business or organization do better on gender. And you can email me amy.cross@genderfair.com. And I would love to help anyone in their journey for fairness of any kind. Yeah, many ways to participate. Just go to genderfair.com or genderfairprocurement.com.

+ +

CHAD: Awesome. Amy, thank you so much for sharing with us. I really appreciate it. And thank you for all the good that you're doing in the world with Gender Fair.

+ +

AMY-WILLARD: Well, I appreciate the way you're running your company in a very new, interesting, and apparently ethical way. Privately, I could look at your website and your career page and figure out how you're doing. But it sounds, to me, when I've talked to people, that you're doing very well. And I honor your curiosity about learning from others.

+ +

CHAD: Awesome. Well, listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon @cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+DDaSLlUU + + ]]> + + Chad Pytel + + + 532: Building Trust and Community in Sustainable Business + https://podcast.thoughtbot.com/532 + 5f76b0d1-dee1-4b94-a5ab-b97f0389d5e9 + Wed, 03 Jul 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Sami Birnbaum and Jared Turner are joined by Ishani Behl, CEO and Founder of Skillopp and Sustainr. Ishani shares how her background in instructional design and experiences at the UNDP inspired her to create Skillopp, which uses AI to simplify learning, and Sustainr, a platform connecting sustainable brands. She discusses the importance of dejargonization, the challenges of balancing multiple ventures, and her approach to building trust and fostering collaboration within her communities. + 39:30 + no + + + In this episode of the Giant Robots Smashing into Other Giant Robots (On Tour!) podcast, hosts Sami Birnbaum and Jared Turner are joined by Ishani Behl, CEO and Founder of Skillopp and Sustainr. Ishani, an instructional designer by trade, began her journey by creating online courses and eventually moved into sustainability, inspired by her exposure to startups at the UNDP. She founded Sustainr, a platform that connects sustainable brands, and Skillopp, which simplifies learning using AI, aiming to reduce information overload. +Ishani discusses how her educational background and experiences shaped her desire to improve learning and sustainability. She emphasizes the importance of dejargonization and how Skillopp uses AI to make complex information more accessible. She also highlights Sustainr's role in connecting sustainable brands with resources and opportunities, fostering a community that emphasizes collaboration over competition. Her journey reflects a commitment to creating impactful, sustainable business practices and improving educational approaches through technology. +Throughout the conversation, Ishani shares her challenges in balancing multiple ventures, the importance of delegation, and her approach to building trust within her communities. She provides insights into the evolving landscape of e-learning and sustainability, emphasizing the need for personalized learning and effective communication. +Skillopp (https://www.skillopp.com/) +Follow Skillopp on LinkedIn (https://www.linkedin.com/company/skillopp/). +Sustainr (https://www.sustainr.co/) +Follow Sustainr on LinkedIn (https://www.linkedin.com/company/econet2021/) or Instagram (https://www.instagram.com/sustainr.22). +Follow Ishani Behl on LinkedIn (https://www.linkedin.com/in/ishanibehl/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +SAMI: This is the Giant Robots Smashing into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. If you have no idea about this Giant Robots on Tour series, then please make sure you listen to our previous podcast, where we throw random icebreakers at each other and we have fun naming the new series. So, make sure you don't miss out on that one. I'm your host, Sami Birnbaum. +JARED: And I'm your other host, Jared Turner. +SAMI: And with us today is Ishani, CEO and Founder of Skillopp, which simplifies learning to amplify performance through AI, and Sustainr, the Fiverr for sustainable brands. We are so delighted to have you with us, Ishani, today. We're going to get more into depth and into detail exactly where you're at and what you're doing at present. But I always like to go back to the start with my guests because there's always a journey and a story about how they got to where they are. Would you give us some details about how you got to the place you are today? +ISHANI: Definitely. It's great to be on this. I'm delighted to also kind of share my story. It's been quite a journey. It all started a few years ago. I'm an instructional designer so that basically means that I design online courses for a living. So, if you see those ads on Instagram, "Hey, come to my masterclass," what I basically do is that I help in designing the whole course from the beginning but in a much better way. +I guess this whole journey of Sustainr and Skillopp really started after I graduated. So, I went to King's College, and I pursued a degree in liberal arts, after which I worked at UNDP. And I was exposed to this world of sustainability and all these really cool startups that were coming up in this space. And I thought to myself that this is such an interesting and innovative field to be in. +In every single startup that, you know, you would really do research around, you would just find these really interesting bits of information that you really didn't know. And I think that the business models per to se is also kind of like a way to emulate how you can live your own life in a much more efficient manner. That's why sustainability is called sustainability for a reason so that you can really sustain your livelihoods for a much longer amount of time. +I think just building upon that, when the pandemic started, I really thought of doing something around this. And we kind of created a community of practice, so to say, of just sustainable brands around the country, in the UK and India. We started connecting them with various opportunities, so it sort of became like a Fiverr [laughs] of sorts where we would kind of connect them to various kinds of opportunities that would help them grow. +I think when I went back to London for my master's, a lot of people in the faculty really liked the idea. And they were able to provide us with some funds, and we won a number of competitions. And that really led to the beginning of Sustainr, and we currently have around 40 brands on our platforms. We keep on having a lot of collaborations. We've also raised grants for a few startups as well. This idea of really merging learning with the community created impact, and I had no idea about that. +And I think when I started creating courses as well for other brands and other companies, this whole idea of Skillopp also emerged as well, where we really took into account one very important concept, which was dejargonization. Now, I'm not too sure if you're aware about this, but there's this very big problem that's happening in the world right now. It's called the information overload. +If you think about it, every single time you open, you know, some piece of content, or a reel, or anything, you see so many words that you just don't understand whether it's Web3, crypto, Bitcoin [chuckles], whatever it might be. So, what we basically did in that case through Skillopp, which was this new vertical that we created, we basically simplified content through using different AI tools. And that would really help automate digital learning and communication in organizations. And we've currently worked with the top MNCs in the world as well. +The whole idea, in a nutshell, in terms of my life so far, has really been around how exactly you can design content in the most simplest way possible. How do you dejargonize it? And also, how do you create impact in the sustainable space? Because that is one key area that I think can really teach us so much about our own lives and can create so much of impact given the current climate crisis as well. +JARED: That was a great intro. Thank you. You're working on two businesses. Are you still studying, or you finished studying now? +ISHANI: I finished studying. +JARED: You finished. So, I guess you were studying while you were working. +ISHANI: Mm-hmm. +JARED: But now you're working on two. So, how did you or how do you balance all of that? And how do you choose what to prioritize when they probably both seem just as important? +ISHANI: I think it took me some time to figure that out. It's not easy. I'm somewhat of an overthinker. So, it just so happens to be that when you think about several problems that your business is facing, you know, whether it's, you know, people; it's sales; it's operations, it just really makes you really flustered, and, you know, you're unable to figure out what do I exactly prioritize. One thing that really helped me was just reflecting on the business models and what I was up to, as well as what exactly deserved the amount of priority that it needed to. +So, what really ends up happening is that I think there's a lot of reflection on how do you delegate tasks, and that's how I exactly manage two businesses. I really believe in this whole concept that, as an entrepreneur, everybody looks at you and everyone's like, "Yeah, you must be doing it all," right? Like, the marketing, the sales, especially in the beginning. +But I believe that when you learn the art of delegation and just kind of letting go and surrendering that, okay, no, you know, I have a team who's handling this aspect of the business, and I should not worry about it, you automatically can start focusing on other aspects. And I think that's how I started prioritizing. I divided the tasks into whatever really received utmost importance in the beginning that was easier to do, and then, you know, you sort of get the hang of it. +I'd also like to add to the fact that I think we don't talk about this really often but look at, like, our moms, right? Like, they handle a household and their work at the same time, and they can do it. So, you know, I really think to myself, there are so many people who might be handling more than that, then why can't I do it? I think just setting that motivation really, really helps. And you can then start figuring out how to delegate, how to prioritize. But I think mindset is key because if you don't have the right mindset, you won't be able to do it. +SAMI: As a father of four, that analogy really resonates with me in terms of juggling all those different balls at the same time. But I can imagine it's exhausting as well. But you touched on this concept of dejargonization, which I love because I think there is such a barrier to learning sometimes because humans take simple things and make them complex. And it sounds like, through your e-learning platform, you're taking complex things and returning them back to being simple. +I've seen you describe yourself as a bad learner. +ISHANI: [laughs] +SAMI: What does that mean, and how exactly has that impacted you? +ISHANI: In the beginning, the reason why I pursued education, I guess, there was this very rebellious instinct that I had in mind. When I was in school, it was so different. I was told to especially memorize certain formulas in math. And there was this really gigantic physics book that I had to learn and, you know, kind of memorize the formulas and understand the concepts, no pictures at all. And, you know, you just had to be perceived as, hey, you know, if you can memorize them and you can get good grades, you are really, really smart, but if you can't, then that basically means that you don't have any future. And that was the kind of mindset that I grew up in. +And I think I had this rebellious instinct that if supposing I couldn't, like, especially because in science, I was really, really bad. I used to hate those horrible textbooks. I was just like, how can somebody learn through this? And I was just like, no, I want to change this. I want to change the way people approach education and learning. And I started seeing this and this started becoming so relevant. +A lot of us today might perceive that they know certain concepts. But when we start having a conversation around that concept, there are so many misconceptions that are created because of these preconceived notions of how they were taught earlier about a certain concept as well in school, right? I guess my mission is to kind of eliminate that barrier of questioning concepts right in the beginning when somebody is learning and not being like, hey, you know, if I don't understand this word, if I don't understand this concept, I'm really smart. I'm going to figure it out. +I hate the Superman complex that people have these days. I know it all. I really, really know it all. And I'm just like, well, do you? This is one of my favorite slogans, like, if you can't teach it, then don't preach it. And [laughs] I think that I keep on following that slogan all my life that if I really don't understand anything, I have to figure out a way to understand it, and that doesn't mean that I'm dumb or stupid. I have to figure out a way in terms of understanding that concept. +That's why I call myself a bad learner because I used to hate how I was taught in school. And I was just like, you know, I'm not going learn like this, either I have to change the way I think and I learn. That's the only way that I will do that. And that's why I got into education. I was just like, I really want to take some revenge on this [laughs]. +SAMI: I love that. That really resonates with me. I would also, in that sense, I would describe myself as a bad learner, but someone with a good memory, especially when I didn't understand things. I'll never forget when I was studying for my degree. I actually wasn't far from you. I think you were in King's College. +ISHANI: Oh. +SAMI: Well, I was down the road in LSE. +ISHANI: Oh, nice. Neighbor. +SAMI: Yes, I remember studying for my degree there, and there was one topic I was studying that I just couldn't understand and get my head around. But there's kind of a way to play the system, and that is memorizing things. So, I promise you, I memorized sentences. I could not tell you what they meant, but I used them in my exam. It was kind of cheating, in a way, but it was kind of also working with the system that I had in front of me. But it sounds like if I had something like an e-learning platform at that time, that is something which could have explained things properly and played into strengths that I might have had that I wasn't able to discover in the regular system. +Do you see e-learning platforms...and I've seen this actually from people who, let's say, are studying for their A levels in this country now, which is exams they do ages of, I think, 17 or 16. A lot of them are turning to YouTube, and they learn from YouTubers, and there's other platforms. Do you see e-learning as something which could replace more conventional education, either high schools, degrees? Is that where you see the industry heading? +ISHANI: Well, I wouldn't say that e-learning can replace educational systems. I think, at the end of the day, when it comes to e-learning platforms, as well, I really love them. But I wouldn't say that they're as personalized as you would think. They could be. And the number one element to learn well is to personalize learning because everybody is different. Everybody thinks differently. Everybody has a very different process of thinking. Some people learn in a very auditory way. Some people like listening to podcasts like the ones that you're conducting. Some people like learning visually. Some people like learning kinesthetically. +Sometimes what I believe is that not every single e-learning platform can do justice to every single style of learning or every single individual. And I'm pretty sure there are 500 more styles of learning that we in the L&D space still haven't discovered yet. I think what e-learning can do and how we can really benefit from e-learning is using it as a tool. We should not depend on e-learning platforms completely, like, in terms of even, like, just simplifying content or, like, figuring out a way in terms of writing an essay. That is something that perhaps we can use it as a tool to brainstorm upon, that it makes our lives much easier. +At the end of the day, AI, artificial intelligence, as well as all these e-learning platforms that are coming up, it's a way in terms of conducting the menial tasks that you really didn't want to do so that you can focus on the big stuff. I think if we start approaching e-learning in that way and, you know, also figure out how to set limitations in terms of how we don't depend on it; we will not have, like, a crisis in terms of how we're looking at social media today, where everybody is just addicted to their phones. +JARED: Ishani, I wanted to ask specifically about your product, Skillopp. Who's your target market? You know, we've talked a lot about sort of learners from an education perspective, like high school, university. Are you targeting them, or is it more business, commercial users? And how did you discover that market as well? +ISHANI: Great. So, I think, again, it really happened to be upon chance. So, like, a little bit more about Skillopp. It's not exactly how a product works. We work in a much more adaptable and flexible manner in terms of how you can use AI to simplify content as well. We started working with a number of corporates through word of mouth, I guess, and we created a lot of impact in that space. +And what we did was that we would figure out what would be the best platforms and tools that they can deploy. And we would put them onto one system, and we would develop that for them. So, how it would really end up working would be, like, this very flexible product that we would make as per the needs of the corporate itself, rather than making something of our own, which could not be flexible or adaptable to what the corporation wanted as well. It's really cool because we just end up building on various kinds of innovations. +Like, recently, we would also be open to various forms of different tech partnerships in terms of building those systems as well. So, it just ended up creating this collaboration over competition mindset and where everything happened to be, like, this win-win formula when we would build products. And we would kind of go to these businesses as a service, and we would end up building a product for them. I think, that way, it was very interesting to see how that journey really happened. And I think it was just through experimentation, and I really experimented a lot. +We do also have, like, some developers who are working with us. And we would kind of go out of our way to figure out what the company or the corporate really wants. And we started building upon these products and then we were able to, like, deploy those particular needs of what that organization wanted in terms of what kind of product they really wanted and how they wanted to simplify content. So, it was, like, as if it was made by them, not by us. And it provided that sense of pride within the organization that, hey, you know, this is something that I really built. +This whole concept just got extended through word of mouth to various different organizations and institutions. But, like, through some random way, and I always thought that I'm going to work with an institution first, it just so happened to be working in the corporate space, which is very strange. But I guess that's how entrepreneurship, to a certain extent, works with so much of experimentation that went on. +JARED: You're using generative AI as part of that to identify, let's say, jargon and then simplify that language. And one of the problems that generative AI has is what they call the hallucination problem, where it sort of makes stuff up that's not true. Have you encountered that? And I'm curious of any ways you're trying to tackle it. +ISHANI: [laughs] So many times. I think AI it's like raising a baby, you know [laughs]. I always like to use that anecdote because [laughs], like, my experience in terms of, like, generative AI and AI, in general, it's always been, like, as if I'm bringing a baby up in terms of, you know, the machine learning aspect of it. +I think, yeah, we've encountered that quite a number of times. I think the best way in terms of also approaching this hallucination aspect is to kind of keep the task as specific as possible. If you want to teach somebody a little bit about sales and how do you exactly approach a customer in terms of closing in a deal, right? The way we can approach it. How do you simplify that process for, let's say, sales agents, right? It's to kind of really figure out what is that particular skill that the sales agent really needs help upon. So that if we try and specify it more, then the AI will really understand that, okay, I have to stick to this boundary. I really can't go out of that. +And making it as specific as possible really helped us in the process, and they were able to really upskill themselves in that one specific subskill. And we really, really worked on that conversation to such an extent that I even know the script of that conversation in terms of how a sales agent is supposed to negotiate and what would that script be for that particular industry and that organization. So, I think just specifying it as much as you can really helps. I think the hallucination effect happens so much, and that is one problem and also an area that I'd love to do more research in as well. +JARED: So, humans aren't going anywhere just yet. +ISHANI: Yeah, not going anywhere. Actually, I really don't think so. A lot of people just keep on talking about AI is going to be...and I would...actually, this is a question that I'd love to ask both of you as well that do you think AI is really going to replace human beings? And everybody just keeps on talking about it, and I don't really think so. But what do you think? +JARED: Oh, gosh, we could have a whole episode just on this. +ISHANI: [laughs] +JARED: There's a lot of parallels to the industrial revolution, where everyone said all of the machinery that was created was going to get people out of jobs, farming, and agriculture. And all it really did was shifted the demand for resources into different and slightly more specialized roles. I think we'll see a similar shift with AI. I do think, in time, there will be a significant portion of existing jobs that might go the way of AI overlords. But I'd like to think there'll always be a place for us little humans. What about you, Sami? +SAMI: I love this question. I think I've gone around the houses with this one. So, I've gone through different phases of like, oh my gosh, we're all going to die, and no one's going to have any more jobs, and we don't know what we're going to do. Even to the extent that I was really proud of myself that I learned on YouTube how to silicon my bathroom because I was adamant that AI could not do that. And so, if all else goes to pot, then at the very least, I have a skill that is valuable. And then, recently, I've seen the robots they're coming up with, so even that is not really going to work for me. It's really difficult to know. It's so difficult. +I find generative AI less compelling because of the hallucinations that we've spoken about. I see that as being far off, and a lot of it depends on the accuracy. Your baby analogy is great. Because the way we're used to interacting with computers is they give us responses that are kind of, like, binary. They're either right or they're wrong. It's like a green light, red light relationship. And when it comes to generative AI, you need to have that more personal relationship with the computer to have that conversation back and forward to get it where you want it to be. +Something that has definitely come more to the forefront is discriminative AI, which is AI that can tell a difference between certain data sets. So, I see that taking off a lot more. So, for example, they're using it in, like, the medical sector where the AI can discriminate or tell the difference between certain brain scans in terms of understanding what might be an issue and what might not be an issue. So, that is very powerful. We've actually had that for quite a long time. But as computing power is becoming more affordable, as certain chips have become available, it's becoming more widespread, and we can harness that a lot more. +So, discriminative AI, I think, is being very disruptive, and I think it will continue to be. Degenerative AI, I'm not sure because of the difficulties you've spoken about. But worst-case scenario, I will personally come and silicon your bathroom. +So, the e-learning company that you have, that seems more familiar to me. And maybe it could be also potentially more familiar to some of our listeners because a lot of us have kind of grown up on YouTube. And I'm not comparing it to YouTube. I know it's a very different beast altogether. It's something which we could possibly identify with and understand more. The Sustainr aspect is a little bit more foreign to me. So, I'd love to get to understand more of what the Sustainr company that you have is all about and how it works. +ISHANI: Like I said, I think Sustainr is this very interesting community that we built over the pandemic kind of touching upon this whole aspect of...and I think I'll also, like, come to this point in terms of how Skillopp and Sustainr are also kind of interlinked. It all, actually, technically speaking, started with the same problem: dejargonization. +What really happened was that when you also start a startup, especially in the sustainable space, what a lot of people, and when I talked to a lot of founders, especially the 40 brands that we have on our platform, it's like, "Ishani, I just don't know who exactly to approach. I don't know what...supposing I'm trying to find sourcing materials related to my business, supposing I'm trying to find individuals who can create content that is based on the concept of my business, I just don't see the results. And I don't see that people are able to understand and comprehend what I'm trying to talk about." +And I feel like this is also perhaps a cultural problem as well. I mean, for example, this has been my experience as well as a number of people in India. Because India is currently growing at a massive rate with the economy, as well as the startup boom that's happening. If you think about it, every single person's mindset is like, I really need to get this done. And that's why a lot of us are also very impatient. +So, just thinking about how we're actually really thinking, we create, like, this impatience sort of situationship in our head. And we don't want to perhaps learn about new things. That stops us from learning and really digging deep because we're just like, no, no, no, we need to get this done, and we need to hustle. And there's a lot of that culture that's present over here because our economy is growing. Startups are booming. And there's lots of work to be done. Like, trust me, if you come to Bangalore or Bombay, you will actually feel that pressure [laughs]. +So, really thinking about that mindset, what really happens is that when somebody, especially in Southeast Asian countries or especially in a country like India, are looking for stuff for their sustainable business, a lot of people are like, "But what is sustainability? What is ESG? Is it just environment-related?" And, you know, just this communication style, so to say, creates a lot of impatience between both the parties, and that leads to mistrust. Miscommunication takes place. Orders don't come on time. There's a lot of problem and havoc. This also leads to a lot of mental stress. +That's why we created this platform, so to say. And how it really works is like, it's like any form of connecting platform. We have various categories, as well, through which people can perhaps list their business on the platform in terms of that particular category, whether it's in sourcing, whether it's in fundraising, finance, or even marketing per se. +And we just kind of connect them just like how you would connect people over LinkedIn, like, through an intro. But we would be the ones who would be part of that whole connection scenario so that everybody knows that there is, like, this trusted platform being built between the two people and that they're not alone. There's somebody else who's also dejargonizing the communication flow. +And through that, what really happens, Sami, is that, like, the ideas of collaborations really grew because we would also have events. We would also have, like, these very interesting micro podcasts just for the community. And we would just post all of that content that would, A, build a lot of positivity amongst people in that space. And, you know, it would just kind of lead to more productivity in terms of different collaborations. Like, for example, we just tied up somebody who was creating straws using, I think, coconut or something like that to a chain of vegan cafes. +I think what really happened was that through this trusted platform, through a community, I think it really, really bolsters a lot of positive mindset. At the end of the day, like I said in the beginning, I really think that it's all about mindset, which really helps you take that action. And that, in a nutshell, is what Sustainr really does in terms of just connecting resources. +And now because we work with corporates as well, if supposing there are companies who want to pursue, let's just say, corporate gifting or something like that, we kind of help and initiate that process as well. So, it just becomes, like, this interlinked network where you can really just harness as many collaborations as possible so that you can also grow your business. You have time for experimentation. You have the safe space as well. And I didn't get an opportunity to be a part of any such community. So, I was just like, why not try and see how I can create one? +JARED: That's great. It sounds like education and trust, a huge part of this marketplace. How do you ensure you find trusted partners, and how do you convince the people on the other side of that marketplace to trust you or to trust your marketplace? +ISHANI: So, I think in terms of building trust, it takes time. So, we're not a community, or we're not kind of, like, this platform; we're, like, telling everybody that, "Hey, you know, come on our platform. We'll ensure that your business will grow." I think, first of all, it's setting the right expectations in terms of what exactly you can really achieve out of this platform. B, I think what I really like to do is, like, a lot of phone calls, just talking to the founder in terms of how he started that particular idea of his. How did it really take place? +Our onboarding process is not like you have to fill in this very big, huge form, which will make you extremely bored, and you're just like, "Oh my God, this is, like, such a heavy task." Like, no, it's okay. There are some people in our team who also kind of talk to the founders and figure out what their story is all about. How did they really start that particular business? And if supposing what they're really looking for is something that we can really curtail to. Because we don't want to be also, like, a community where there's no value that we can add, then what's the whole point? +And I'm very hell-bent on setting those expectations so that when people actually join our platform, then, you know, it's not like, okay, like, this is going to be just spam coming on [laughs] your way in terms of all the other communities that we end up seeing. But it's so much more than that. I think it's kind of like when we establish that synergy that, all right, if this is what you're looking for, and these are the kind of people that we have, that's the only way that we kind of build that trust. And that trust-building, it takes time. It doesn't happen automatically; it takes a lot of time, and that's why we have a lot of events. +We share a lot of bits of content around, let's say, the investing market in the space of sustainability and ESG. What exactly is happening out there? We even link with other communities to build more trust. So, supposing there's a better community than Sustainr, I'd be like, yeah, 100%, you should definitely look at those communities. Like, that tagline has always been collaboration over competition, and I think it's always worked in our favor. +We would also end up collaborating with those communities around climate. In so many different aspects, that's helped us, and that's the way that you also kind of build trust, when you actually see those actionable steps being taken, and you see that taking place. But it's not something that I can, like, assure you, like, yeah, 100% the trust is built within that one day. It takes some time, but it happens over a period of time. +JARED: I love what you just said there about almost the long-term strategy of, you know what? If there's a better community, we're going to point you in that direction. That, to me, builds so much trust because the short-term option is to say, "Oh, okay, I've seen this. It's probably better for them, but that means they're not on our platform. So, that's not better for me." That is a tremendous way to build trust in a sort of long-term user base. So, I really love that. +SAMI: Yeah. I mean, we've only been, I don't know, we've been speaking for about half an hour, 40 minutes now, and I feel like I really trust you as well [laughter]. It's, like, rubbing off. This concept of, you know, demystification and simplifying things it shows this authenticity. And I think your personality comes across and the way that you run these businesses. And you're doing it in an incredibly genuine way. I think that really talks to people. I think people are looking, like, not for jargon. They really want authentic people they can relate to who are real human beings. And that's something which I think really comes across through speaking to you. +Obviously, as a consultancy, myself and Jared we work within thoughtbot, and we work with people like yourself to really try and solve their problems and understand what their pain points are. And we can come up with solutions through design or development. What would you say is your biggest challenge? In either one of these businesses or as a whole, where's your biggest challenge at the moment? +ISHANI: There are so many [laughs]. But I guess to start off with, kind of scaling it to a considerable level. But at the same time, you know, scaling requires investment, and scaling also requires some amount of time in terms of figuring out how exactly you want to grow your team, which also takes time. So, sometimes I feel like I'm in this catch-22 situation where I'm just like, if I do need investment, right? For example, scale or if I need investment to grow my team even further to get more clients so that I can target more projects, let's say for Skillopp; again, finding the right people it takes time. And I think that's something that I really also kind of struggle with. It took me a lot of time to find the right people for the projects that we're doing right now. +I think any tips would be great in terms of how exactly I can really do that so that even if supposing I want to raise investment and I know what I want to raise investment in, which is to grow the team, how exactly would I really approach that? Because I always feel like it's like this catch-22 situation. +JARED: Well, it sounds like you already have some clients, which is an infinite step up on most businesses that are starting out and trying to get investment. Like, the fact that you can prove you have revenue coming in is amazing. I mean, the typical things that investors want, like the investor deck, right? They're going to want to see your vision for the business. They're going to want to see your financials and the forecast. And then, it's a matter of finding the right investors as well because I guess there are so many out there. But I think you probably want to find one that matches your values around sustainability and dejargonization as well. +SAMI: Yeah, that's a great answer, Jared, actually. And, I think, just to add on top of that, this is where sometimes using a consultancy actually really helps. We see this a lot within thoughtbot, where someone is looking to get investment and wants to scale their team. But when you do that in-house, that comes with a lot of overheads. +So, for example, you might need an extra person, your HR team, to handle new people, you know, being directly employed. Going to a consultancy and getting a third-party delivery partner allows you to kind of scale your team quickly, but also, descale that team quickly as well, so that it gives you that flexibility whilst you're in that more turbulent zone of, "Oh, I'm trying to scale, and I'm trying to get investment. And I'm not sure where my budgets are." Until you, you know, complete that scaling that you want to do, you get to a place where you're more stable. And then, actually, what thoughtbot does is helps people to then hire their own in-person team. But yeah, something like a consultancy can give that flexibility. +But the way you describe this catch-22 situation is so common because what do I do first? I've got all these levers I could pull. So, I could pull the investment lever, or I could pull the, you know, extra resources lever. And then, there's like, you know, extra revenue lever as well. So, it's a really difficult problem. But definitely, we found, as a consultancy, that having that flexibility using third-party partners can be something which helps. +JARED: And I wanted to just ask, because I remember you were saying you're working with some developers, are they developers you've hired, or is that a third-party team you're working with? +ISHANI: It's very similar to what you really mentioned. It's like a strategic partnership with a third-party team. But, again, I think finding the third-party team also, like, it takes a long time to find. But I think that I really liked the thought that you were really talking about as well earlier, where you were kind of mentioning that that whole catch-22 situation is super, super important to understand. +And I feel that instead of kind of going on LinkedIn and, like, posting so many, like, you know, these job descriptions with the overhead costs...I started learning that once I made that mistake. I think I learned so much about that. And I think that what you said it's also, like, reflecting on the fact that, okay, you really can see this through the strategic partnerships. And I think I'd love to be somebody or, like, you know, aspire to be someone who can, like, master that whole art of finding the third-party consultancies like you were mentioning, especially what you're doing as well. So, I think it's great, and thank you so much for the feedback and as well as answering question. +SAMI: It's been great to have you on. And doing a podcast like this it just gives us the opportunity to speak to people like yourself. If people want to reach out to you, do you have any specific place you'd like them to reach out? +ISHANI: You can go on my LinkedIn, where you'll find a lot of stuff and links to what I do. +SAMI: Cool. So, I highly recommend our listeners to take a look at Skillopp, and take a look at Sustainr, and get to know all the great work that Ishani is doing. +For our listeners, we're going to bring you lots more content like this. This was the first one in the Giant Robots on Tour series. Your only challenge before the next one is to hit the subscribe button to make sure you get this content directly as soon as it comes out because we've got some incredible guests lined up for you. +You can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See ya. +Okay, before we sign off, a quick request. If you're enjoying Giant Robots on Tour, please drop us a review on Apple Podcasts or Spotify. Your reviews help us grow and reach more listeners, and we'd love to hear what you think. Thanks for being part of our journey, and stay tuned for more episodes. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + AI in education, sustainable startups, instructional design, Skillopp, Sustainr, learning simplification, dejargonization, sustainability, entrepreneurship, community building, online courses, corporate training, sustainable brands, AI tools, educational innovation, startup journey, collaboration over competition, sustainable business practices, e-learning platforms, business development + + In this episode of the Giant Robots Smashing into Other Giant Robots (On Tour!) podcast, hosts Sami Birnbaum and Jared Turner are joined by Ishani Behl, CEO and Founder of Skillopp and Sustainr. Ishani, an instructional designer by trade, began her journey by creating online courses and eventually moved into sustainability, inspired by her exposure to startups at the UNDP. She founded Sustainr, a platform that connects sustainable brands, and Skillopp, which simplifies learning using AI, aiming to reduce information overload.

+ +

Ishani discusses how her educational background and experiences shaped her desire to improve learning and sustainability. She emphasizes the importance of dejargonization and how Skillopp uses AI to make complex information more accessible. She also highlights Sustainr's role in connecting sustainable brands with resources and opportunities, fostering a community that emphasizes collaboration over competition. Her journey reflects a commitment to creating impactful, sustainable business practices and improving educational approaches through technology.

+ +

Throughout the conversation, Ishani shares her challenges in balancing multiple ventures, the importance of delegation, and her approach to building trust within her communities. She provides insights into the evolving landscape of e-learning and sustainability, emphasizing the need for personalized learning and effective communication.

+ + + +

Transcript:

+ +

SAMI: This is the Giant Robots Smashing into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. If you have no idea about this Giant Robots on Tour series, then please make sure you listen to our previous podcast, where we throw random icebreakers at each other and we have fun naming the new series. So, make sure you don't miss out on that one. I'm your host, Sami Birnbaum.

+ +

JARED: And I'm your other host, Jared Turner.

+ +

SAMI: And with us today is Ishani, CEO and Founder of Skillopp, which simplifies learning to amplify performance through AI, and Sustainr, the Fiverr for sustainable brands. We are so delighted to have you with us, Ishani, today. We're going to get more into depth and into detail exactly where you're at and what you're doing at present. But I always like to go back to the start with my guests because there's always a journey and a story about how they got to where they are. Would you give us some details about how you got to the place you are today?

+ +

ISHANI: Definitely. It's great to be on this. I'm delighted to also kind of share my story. It's been quite a journey. It all started a few years ago. I'm an instructional designer so that basically means that I design online courses for a living. So, if you see those ads on Instagram, "Hey, come to my masterclass," what I basically do is that I help in designing the whole course from the beginning but in a much better way.

+ +

I guess this whole journey of Sustainr and Skillopp really started after I graduated. So, I went to King's College, and I pursued a degree in liberal arts, after which I worked at UNDP. And I was exposed to this world of sustainability and all these really cool startups that were coming up in this space. And I thought to myself that this is such an interesting and innovative field to be in.

+ +

In every single startup that, you know, you would really do research around, you would just find these really interesting bits of information that you really didn't know. And I think that the business models per to se is also kind of like a way to emulate how you can live your own life in a much more efficient manner. That's why sustainability is called sustainability for a reason so that you can really sustain your livelihoods for a much longer amount of time.

+ +

I think just building upon that, when the pandemic started, I really thought of doing something around this. And we kind of created a community of practice, so to say, of just sustainable brands around the country, in the UK and India. We started connecting them with various opportunities, so it sort of became like a Fiverr [laughs] of sorts where we would kind of connect them to various kinds of opportunities that would help them grow.

+ +

I think when I went back to London for my master's, a lot of people in the faculty really liked the idea. And they were able to provide us with some funds, and we won a number of competitions. And that really led to the beginning of Sustainr, and we currently have around 40 brands on our platforms. We keep on having a lot of collaborations. We've also raised grants for a few startups as well. This idea of really merging learning with the community created impact, and I had no idea about that.

+ +

And I think when I started creating courses as well for other brands and other companies, this whole idea of Skillopp also emerged as well, where we really took into account one very important concept, which was dejargonization. Now, I'm not too sure if you're aware about this, but there's this very big problem that's happening in the world right now. It's called the information overload.

+ +

If you think about it, every single time you open, you know, some piece of content, or a reel, or anything, you see so many words that you just don't understand whether it's Web3, crypto, Bitcoin [chuckles], whatever it might be. So, what we basically did in that case through Skillopp, which was this new vertical that we created, we basically simplified content through using different AI tools. And that would really help automate digital learning and communication in organizations. And we've currently worked with the top MNCs in the world as well.

+ +

The whole idea, in a nutshell, in terms of my life so far, has really been around how exactly you can design content in the most simplest way possible. How do you dejargonize it? And also, how do you create impact in the sustainable space? Because that is one key area that I think can really teach us so much about our own lives and can create so much of impact given the current climate crisis as well.

+ +

JARED: That was a great intro. Thank you. You're working on two businesses. Are you still studying, or you finished studying now?

+ +

ISHANI: I finished studying.

+ +

JARED: You finished. So, I guess you were studying while you were working.

+ +

ISHANI: Mm-hmm.

+ +

JARED: But now you're working on two. So, how did you or how do you balance all of that? And how do you choose what to prioritize when they probably both seem just as important?

+ +

ISHANI: I think it took me some time to figure that out. It's not easy. I'm somewhat of an overthinker. So, it just so happens to be that when you think about several problems that your business is facing, you know, whether it's, you know, people; it's sales; it's operations, it just really makes you really flustered, and, you know, you're unable to figure out what do I exactly prioritize. One thing that really helped me was just reflecting on the business models and what I was up to, as well as what exactly deserved the amount of priority that it needed to.

+ +

So, what really ends up happening is that I think there's a lot of reflection on how do you delegate tasks, and that's how I exactly manage two businesses. I really believe in this whole concept that, as an entrepreneur, everybody looks at you and everyone's like, "Yeah, you must be doing it all," right? Like, the marketing, the sales, especially in the beginning.

+ +

But I believe that when you learn the art of delegation and just kind of letting go and surrendering that, okay, no, you know, I have a team who's handling this aspect of the business, and I should not worry about it, you automatically can start focusing on other aspects. And I think that's how I started prioritizing. I divided the tasks into whatever really received utmost importance in the beginning that was easier to do, and then, you know, you sort of get the hang of it.

+ +

I'd also like to add to the fact that I think we don't talk about this really often but look at, like, our moms, right? Like, they handle a household and their work at the same time, and they can do it. So, you know, I really think to myself, there are so many people who might be handling more than that, then why can't I do it? I think just setting that motivation really, really helps. And you can then start figuring out how to delegate, how to prioritize. But I think mindset is key because if you don't have the right mindset, you won't be able to do it.

+ +

SAMI: As a father of four, that analogy really resonates with me in terms of juggling all those different balls at the same time. But I can imagine it's exhausting as well. But you touched on this concept of dejargonization, which I love because I think there is such a barrier to learning sometimes because humans take simple things and make them complex. And it sounds like, through your e-learning platform, you're taking complex things and returning them back to being simple.

+ +

I've seen you describe yourself as a bad learner.

+ +

ISHANI: [laughs]

+ +

SAMI: What does that mean, and how exactly has that impacted you?

+ +

ISHANI: In the beginning, the reason why I pursued education, I guess, there was this very rebellious instinct that I had in mind. When I was in school, it was so different. I was told to especially memorize certain formulas in math. And there was this really gigantic physics book that I had to learn and, you know, kind of memorize the formulas and understand the concepts, no pictures at all. And, you know, you just had to be perceived as, hey, you know, if you can memorize them and you can get good grades, you are really, really smart, but if you can't, then that basically means that you don't have any future. And that was the kind of mindset that I grew up in.

+ +

And I think I had this rebellious instinct that if supposing I couldn't, like, especially because in science, I was really, really bad. I used to hate those horrible textbooks. I was just like, how can somebody learn through this? And I was just like, no, I want to change this. I want to change the way people approach education and learning. And I started seeing this and this started becoming so relevant.

+ +

A lot of us today might perceive that they know certain concepts. But when we start having a conversation around that concept, there are so many misconceptions that are created because of these preconceived notions of how they were taught earlier about a certain concept as well in school, right? I guess my mission is to kind of eliminate that barrier of questioning concepts right in the beginning when somebody is learning and not being like, hey, you know, if I don't understand this word, if I don't understand this concept, I'm really smart. I'm going to figure it out.

+ +

I hate the Superman complex that people have these days. I know it all. I really, really know it all. And I'm just like, well, do you? This is one of my favorite slogans, like, if you can't teach it, then don't preach it. And [laughs] I think that I keep on following that slogan all my life that if I really don't understand anything, I have to figure out a way to understand it, and that doesn't mean that I'm dumb or stupid. I have to figure out a way in terms of understanding that concept.

+ +

That's why I call myself a bad learner because I used to hate how I was taught in school. And I was just like, you know, I'm not going learn like this, either I have to change the way I think and I learn. That's the only way that I will do that. And that's why I got into education. I was just like, I really want to take some revenge on this [laughs].

+ +

SAMI: I love that. That really resonates with me. I would also, in that sense, I would describe myself as a bad learner, but someone with a good memory, especially when I didn't understand things. I'll never forget when I was studying for my degree. I actually wasn't far from you. I think you were in King's College.

+ +

ISHANI: Oh.

+ +

SAMI: Well, I was down the road in LSE.

+ +

ISHANI: Oh, nice. Neighbor.

+ +

SAMI: Yes, I remember studying for my degree there, and there was one topic I was studying that I just couldn't understand and get my head around. But there's kind of a way to play the system, and that is memorizing things. So, I promise you, I memorized sentences. I could not tell you what they meant, but I used them in my exam. It was kind of cheating, in a way, but it was kind of also working with the system that I had in front of me. But it sounds like if I had something like an e-learning platform at that time, that is something which could have explained things properly and played into strengths that I might have had that I wasn't able to discover in the regular system.

+ +

Do you see e-learning platforms...and I've seen this actually from people who, let's say, are studying for their A levels in this country now, which is exams they do ages of, I think, 17 or 16. A lot of them are turning to YouTube, and they learn from YouTubers, and there's other platforms. Do you see e-learning as something which could replace more conventional education, either high schools, degrees? Is that where you see the industry heading?

+ +

ISHANI: Well, I wouldn't say that e-learning can replace educational systems. I think, at the end of the day, when it comes to e-learning platforms, as well, I really love them. But I wouldn't say that they're as personalized as you would think. They could be. And the number one element to learn well is to personalize learning because everybody is different. Everybody thinks differently. Everybody has a very different process of thinking. Some people learn in a very auditory way. Some people like listening to podcasts like the ones that you're conducting. Some people like learning visually. Some people like learning kinesthetically.

+ +

Sometimes what I believe is that not every single e-learning platform can do justice to every single style of learning or every single individual. And I'm pretty sure there are 500 more styles of learning that we in the L&D space still haven't discovered yet. I think what e-learning can do and how we can really benefit from e-learning is using it as a tool. We should not depend on e-learning platforms completely, like, in terms of even, like, just simplifying content or, like, figuring out a way in terms of writing an essay. That is something that perhaps we can use it as a tool to brainstorm upon, that it makes our lives much easier.

+ +

At the end of the day, AI, artificial intelligence, as well as all these e-learning platforms that are coming up, it's a way in terms of conducting the menial tasks that you really didn't want to do so that you can focus on the big stuff. I think if we start approaching e-learning in that way and, you know, also figure out how to set limitations in terms of how we don't depend on it; we will not have, like, a crisis in terms of how we're looking at social media today, where everybody is just addicted to their phones.

+ +

JARED: Ishani, I wanted to ask specifically about your product, Skillopp. Who's your target market? You know, we've talked a lot about sort of learners from an education perspective, like high school, university. Are you targeting them, or is it more business, commercial users? And how did you discover that market as well?

+ +

ISHANI: Great. So, I think, again, it really happened to be upon chance. So, like, a little bit more about Skillopp. It's not exactly how a product works. We work in a much more adaptable and flexible manner in terms of how you can use AI to simplify content as well. We started working with a number of corporates through word of mouth, I guess, and we created a lot of impact in that space.

+ +

And what we did was that we would figure out what would be the best platforms and tools that they can deploy. And we would put them onto one system, and we would develop that for them. So, how it would really end up working would be, like, this very flexible product that we would make as per the needs of the corporate itself, rather than making something of our own, which could not be flexible or adaptable to what the corporation wanted as well. It's really cool because we just end up building on various kinds of innovations.

+ +

Like, recently, we would also be open to various forms of different tech partnerships in terms of building those systems as well. So, it just ended up creating this collaboration over competition mindset and where everything happened to be, like, this win-win formula when we would build products. And we would kind of go to these businesses as a service, and we would end up building a product for them. I think, that way, it was very interesting to see how that journey really happened. And I think it was just through experimentation, and I really experimented a lot.

+ +

We do also have, like, some developers who are working with us. And we would kind of go out of our way to figure out what the company or the corporate really wants. And we started building upon these products and then we were able to, like, deploy those particular needs of what that organization wanted in terms of what kind of product they really wanted and how they wanted to simplify content. So, it was, like, as if it was made by them, not by us. And it provided that sense of pride within the organization that, hey, you know, this is something that I really built.

+ +

This whole concept just got extended through word of mouth to various different organizations and institutions. But, like, through some random way, and I always thought that I'm going to work with an institution first, it just so happened to be working in the corporate space, which is very strange. But I guess that's how entrepreneurship, to a certain extent, works with so much of experimentation that went on.

+ +

JARED: You're using generative AI as part of that to identify, let's say, jargon and then simplify that language. And one of the problems that generative AI has is what they call the hallucination problem, where it sort of makes stuff up that's not true. Have you encountered that? And I'm curious of any ways you're trying to tackle it.

+ +

ISHANI: [laughs] So many times. I think AI it's like raising a baby, you know [laughs]. I always like to use that anecdote because [laughs], like, my experience in terms of, like, generative AI and AI, in general, it's always been, like, as if I'm bringing a baby up in terms of, you know, the machine learning aspect of it.

+ +

I think, yeah, we've encountered that quite a number of times. I think the best way in terms of also approaching this hallucination aspect is to kind of keep the task as specific as possible. If you want to teach somebody a little bit about sales and how do you exactly approach a customer in terms of closing in a deal, right? The way we can approach it. How do you simplify that process for, let's say, sales agents, right? It's to kind of really figure out what is that particular skill that the sales agent really needs help upon. So that if we try and specify it more, then the AI will really understand that, okay, I have to stick to this boundary. I really can't go out of that.

+ +

And making it as specific as possible really helped us in the process, and they were able to really upskill themselves in that one specific subskill. And we really, really worked on that conversation to such an extent that I even know the script of that conversation in terms of how a sales agent is supposed to negotiate and what would that script be for that particular industry and that organization. So, I think just specifying it as much as you can really helps. I think the hallucination effect happens so much, and that is one problem and also an area that I'd love to do more research in as well.

+ +

JARED: So, humans aren't going anywhere just yet.

+ +

ISHANI: Yeah, not going anywhere. Actually, I really don't think so. A lot of people just keep on talking about AI is going to be...and I would...actually, this is a question that I'd love to ask both of you as well that do you think AI is really going to replace human beings? And everybody just keeps on talking about it, and I don't really think so. But what do you think?

+ +

JARED: Oh, gosh, we could have a whole episode just on this.

+ +

ISHANI: [laughs]

+ +

JARED: There's a lot of parallels to the industrial revolution, where everyone said all of the machinery that was created was going to get people out of jobs, farming, and agriculture. And all it really did was shifted the demand for resources into different and slightly more specialized roles. I think we'll see a similar shift with AI. I do think, in time, there will be a significant portion of existing jobs that might go the way of AI overlords. But I'd like to think there'll always be a place for us little humans. What about you, Sami?

+ +

SAMI: I love this question. I think I've gone around the houses with this one. So, I've gone through different phases of like, oh my gosh, we're all going to die, and no one's going to have any more jobs, and we don't know what we're going to do. Even to the extent that I was really proud of myself that I learned on YouTube how to silicon my bathroom because I was adamant that AI could not do that. And so, if all else goes to pot, then at the very least, I have a skill that is valuable. And then, recently, I've seen the robots they're coming up with, so even that is not really going to work for me. It's really difficult to know. It's so difficult.

+ +

I find generative AI less compelling because of the hallucinations that we've spoken about. I see that as being far off, and a lot of it depends on the accuracy. Your baby analogy is great. Because the way we're used to interacting with computers is they give us responses that are kind of, like, binary. They're either right or they're wrong. It's like a green light, red light relationship. And when it comes to generative AI, you need to have that more personal relationship with the computer to have that conversation back and forward to get it where you want it to be.

+ +

Something that has definitely come more to the forefront is discriminative AI, which is AI that can tell a difference between certain data sets. So, I see that taking off a lot more. So, for example, they're using it in, like, the medical sector where the AI can discriminate or tell the difference between certain brain scans in terms of understanding what might be an issue and what might not be an issue. So, that is very powerful. We've actually had that for quite a long time. But as computing power is becoming more affordable, as certain chips have become available, it's becoming more widespread, and we can harness that a lot more.

+ +

So, discriminative AI, I think, is being very disruptive, and I think it will continue to be. Degenerative AI, I'm not sure because of the difficulties you've spoken about. But worst-case scenario, I will personally come and silicon your bathroom.

+ +

So, the e-learning company that you have, that seems more familiar to me. And maybe it could be also potentially more familiar to some of our listeners because a lot of us have kind of grown up on YouTube. And I'm not comparing it to YouTube. I know it's a very different beast altogether. It's something which we could possibly identify with and understand more. The Sustainr aspect is a little bit more foreign to me. So, I'd love to get to understand more of what the Sustainr company that you have is all about and how it works.

+ +

ISHANI: Like I said, I think Sustainr is this very interesting community that we built over the pandemic kind of touching upon this whole aspect of...and I think I'll also, like, come to this point in terms of how Skillopp and Sustainr are also kind of interlinked. It all, actually, technically speaking, started with the same problem: dejargonization.

+ +

What really happened was that when you also start a startup, especially in the sustainable space, what a lot of people, and when I talked to a lot of founders, especially the 40 brands that we have on our platform, it's like, "Ishani, I just don't know who exactly to approach. I don't know what...supposing I'm trying to find sourcing materials related to my business, supposing I'm trying to find individuals who can create content that is based on the concept of my business, I just don't see the results. And I don't see that people are able to understand and comprehend what I'm trying to talk about."

+ +

And I feel like this is also perhaps a cultural problem as well. I mean, for example, this has been my experience as well as a number of people in India. Because India is currently growing at a massive rate with the economy, as well as the startup boom that's happening. If you think about it, every single person's mindset is like, I really need to get this done. And that's why a lot of us are also very impatient.

+ +

So, just thinking about how we're actually really thinking, we create, like, this impatience sort of situationship in our head. And we don't want to perhaps learn about new things. That stops us from learning and really digging deep because we're just like, no, no, no, we need to get this done, and we need to hustle. And there's a lot of that culture that's present over here because our economy is growing. Startups are booming. And there's lots of work to be done. Like, trust me, if you come to Bangalore or Bombay, you will actually feel that pressure [laughs].

+ +

So, really thinking about that mindset, what really happens is that when somebody, especially in Southeast Asian countries or especially in a country like India, are looking for stuff for their sustainable business, a lot of people are like, "But what is sustainability? What is ESG? Is it just environment-related?" And, you know, just this communication style, so to say, creates a lot of impatience between both the parties, and that leads to mistrust. Miscommunication takes place. Orders don't come on time. There's a lot of problem and havoc. This also leads to a lot of mental stress.

+ +

That's why we created this platform, so to say. And how it really works is like, it's like any form of connecting platform. We have various categories, as well, through which people can perhaps list their business on the platform in terms of that particular category, whether it's in sourcing, whether it's in fundraising, finance, or even marketing per se.

+ +

And we just kind of connect them just like how you would connect people over LinkedIn, like, through an intro. But we would be the ones who would be part of that whole connection scenario so that everybody knows that there is, like, this trusted platform being built between the two people and that they're not alone. There's somebody else who's also dejargonizing the communication flow.

+ +

And through that, what really happens, Sami, is that, like, the ideas of collaborations really grew because we would also have events. We would also have, like, these very interesting micro podcasts just for the community. And we would just post all of that content that would, A, build a lot of positivity amongst people in that space. And, you know, it would just kind of lead to more productivity in terms of different collaborations. Like, for example, we just tied up somebody who was creating straws using, I think, coconut or something like that to a chain of vegan cafes.

+ +

I think what really happened was that through this trusted platform, through a community, I think it really, really bolsters a lot of positive mindset. At the end of the day, like I said in the beginning, I really think that it's all about mindset, which really helps you take that action. And that, in a nutshell, is what Sustainr really does in terms of just connecting resources.

+ +

And now because we work with corporates as well, if supposing there are companies who want to pursue, let's just say, corporate gifting or something like that, we kind of help and initiate that process as well. So, it just becomes, like, this interlinked network where you can really just harness as many collaborations as possible so that you can also grow your business. You have time for experimentation. You have the safe space as well. And I didn't get an opportunity to be a part of any such community. So, I was just like, why not try and see how I can create one?

+ +

JARED: That's great. It sounds like education and trust, a huge part of this marketplace. How do you ensure you find trusted partners, and how do you convince the people on the other side of that marketplace to trust you or to trust your marketplace?

+ +

ISHANI: So, I think in terms of building trust, it takes time. So, we're not a community, or we're not kind of, like, this platform; we're, like, telling everybody that, "Hey, you know, come on our platform. We'll ensure that your business will grow." I think, first of all, it's setting the right expectations in terms of what exactly you can really achieve out of this platform. B, I think what I really like to do is, like, a lot of phone calls, just talking to the founder in terms of how he started that particular idea of his. How did it really take place?

+ +

Our onboarding process is not like you have to fill in this very big, huge form, which will make you extremely bored, and you're just like, "Oh my God, this is, like, such a heavy task." Like, no, it's okay. There are some people in our team who also kind of talk to the founders and figure out what their story is all about. How did they really start that particular business? And if supposing what they're really looking for is something that we can really curtail to. Because we don't want to be also, like, a community where there's no value that we can add, then what's the whole point?

+ +

And I'm very hell-bent on setting those expectations so that when people actually join our platform, then, you know, it's not like, okay, like, this is going to be just spam coming on [laughs] your way in terms of all the other communities that we end up seeing. But it's so much more than that. I think it's kind of like when we establish that synergy that, all right, if this is what you're looking for, and these are the kind of people that we have, that's the only way that we kind of build that trust. And that trust-building, it takes time. It doesn't happen automatically; it takes a lot of time, and that's why we have a lot of events.

+ +

We share a lot of bits of content around, let's say, the investing market in the space of sustainability and ESG. What exactly is happening out there? We even link with other communities to build more trust. So, supposing there's a better community than Sustainr, I'd be like, yeah, 100%, you should definitely look at those communities. Like, that tagline has always been collaboration over competition, and I think it's always worked in our favor.

+ +

We would also end up collaborating with those communities around climate. In so many different aspects, that's helped us, and that's the way that you also kind of build trust, when you actually see those actionable steps being taken, and you see that taking place. But it's not something that I can, like, assure you, like, yeah, 100% the trust is built within that one day. It takes some time, but it happens over a period of time.

+ +

JARED: I love what you just said there about almost the long-term strategy of, you know what? If there's a better community, we're going to point you in that direction. That, to me, builds so much trust because the short-term option is to say, "Oh, okay, I've seen this. It's probably better for them, but that means they're not on our platform. So, that's not better for me." That is a tremendous way to build trust in a sort of long-term user base. So, I really love that.

+ +

SAMI: Yeah. I mean, we've only been, I don't know, we've been speaking for about half an hour, 40 minutes now, and I feel like I really trust you as well [laughter]. It's, like, rubbing off. This concept of, you know, demystification and simplifying things it shows this authenticity. And I think your personality comes across and the way that you run these businesses. And you're doing it in an incredibly genuine way. I think that really talks to people. I think people are looking, like, not for jargon. They really want authentic people they can relate to who are real human beings. And that's something which I think really comes across through speaking to you.

+ +

Obviously, as a consultancy, myself and Jared we work within thoughtbot, and we work with people like yourself to really try and solve their problems and understand what their pain points are. And we can come up with solutions through design or development. What would you say is your biggest challenge? In either one of these businesses or as a whole, where's your biggest challenge at the moment?

+ +

ISHANI: There are so many [laughs]. But I guess to start off with, kind of scaling it to a considerable level. But at the same time, you know, scaling requires investment, and scaling also requires some amount of time in terms of figuring out how exactly you want to grow your team, which also takes time. So, sometimes I feel like I'm in this catch-22 situation where I'm just like, if I do need investment, right? For example, scale or if I need investment to grow my team even further to get more clients so that I can target more projects, let's say for Skillopp; again, finding the right people it takes time. And I think that's something that I really also kind of struggle with. It took me a lot of time to find the right people for the projects that we're doing right now.

+ +

I think any tips would be great in terms of how exactly I can really do that so that even if supposing I want to raise investment and I know what I want to raise investment in, which is to grow the team, how exactly would I really approach that? Because I always feel like it's like this catch-22 situation.

+ +

JARED: Well, it sounds like you already have some clients, which is an infinite step up on most businesses that are starting out and trying to get investment. Like, the fact that you can prove you have revenue coming in is amazing. I mean, the typical things that investors want, like the investor deck, right? They're going to want to see your vision for the business. They're going to want to see your financials and the forecast. And then, it's a matter of finding the right investors as well because I guess there are so many out there. But I think you probably want to find one that matches your values around sustainability and dejargonization as well.

+ +

SAMI: Yeah, that's a great answer, Jared, actually. And, I think, just to add on top of that, this is where sometimes using a consultancy actually really helps. We see this a lot within thoughtbot, where someone is looking to get investment and wants to scale their team. But when you do that in-house, that comes with a lot of overheads.

+ +

So, for example, you might need an extra person, your HR team, to handle new people, you know, being directly employed. Going to a consultancy and getting a third-party delivery partner allows you to kind of scale your team quickly, but also, descale that team quickly as well, so that it gives you that flexibility whilst you're in that more turbulent zone of, "Oh, I'm trying to scale, and I'm trying to get investment. And I'm not sure where my budgets are." Until you, you know, complete that scaling that you want to do, you get to a place where you're more stable. And then, actually, what thoughtbot does is helps people to then hire their own in-person team. But yeah, something like a consultancy can give that flexibility.

+ +

But the way you describe this catch-22 situation is so common because what do I do first? I've got all these levers I could pull. So, I could pull the investment lever, or I could pull the, you know, extra resources lever. And then, there's like, you know, extra revenue lever as well. So, it's a really difficult problem. But definitely, we found, as a consultancy, that having that flexibility using third-party partners can be something which helps.

+ +

JARED: And I wanted to just ask, because I remember you were saying you're working with some developers, are they developers you've hired, or is that a third-party team you're working with?

+ +

ISHANI: It's very similar to what you really mentioned. It's like a strategic partnership with a third-party team. But, again, I think finding the third-party team also, like, it takes a long time to find. But I think that I really liked the thought that you were really talking about as well earlier, where you were kind of mentioning that that whole catch-22 situation is super, super important to understand.

+ +

And I feel that instead of kind of going on LinkedIn and, like, posting so many, like, you know, these job descriptions with the overhead costs...I started learning that once I made that mistake. I think I learned so much about that. And I think that what you said it's also, like, reflecting on the fact that, okay, you really can see this through the strategic partnerships. And I think I'd love to be somebody or, like, you know, aspire to be someone who can, like, master that whole art of finding the third-party consultancies like you were mentioning, especially what you're doing as well. So, I think it's great, and thank you so much for the feedback and as well as answering question.

+ +

SAMI: It's been great to have you on. And doing a podcast like this it just gives us the opportunity to speak to people like yourself. If people want to reach out to you, do you have any specific place you'd like them to reach out?

+ +

ISHANI: You can go on my LinkedIn, where you'll find a lot of stuff and links to what I do.

+ +

SAMI: Cool. So, I highly recommend our listeners to take a look at Skillopp, and take a look at Sustainr, and get to know all the great work that Ishani is doing.

+ +

For our listeners, we're going to bring you lots more content like this. This was the first one in the Giant Robots on Tour series. Your only challenge before the next one is to hit the subscribe button to make sure you get this content directly as soon as it comes out because we've got some incredible guests lined up for you.

+ +

You can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See ya.

+ +

Okay, before we sign off, a quick request. If you're enjoying Giant Robots on Tour, please drop us a review on Apple Podcasts or Spotify. Your reviews help us grow and reach more listeners, and we'd love to hear what you think. Thanks for being part of our journey, and stay tuned for more episodes.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode of the Giant Robots Smashing into Other Giant Robots (On Tour!) podcast, hosts Sami Birnbaum and Jared Turner are joined by Ishani Behl, CEO and Founder of Skillopp and Sustainr. Ishani, an instructional designer by trade, began her journey by creating online courses and eventually moved into sustainability, inspired by her exposure to startups at the UNDP. She founded Sustainr, a platform that connects sustainable brands, and Skillopp, which simplifies learning using AI, aiming to reduce information overload.

+ +

Ishani discusses how her educational background and experiences shaped her desire to improve learning and sustainability. She emphasizes the importance of dejargonization and how Skillopp uses AI to make complex information more accessible. She also highlights Sustainr's role in connecting sustainable brands with resources and opportunities, fostering a community that emphasizes collaboration over competition. Her journey reflects a commitment to creating impactful, sustainable business practices and improving educational approaches through technology.

+ +

Throughout the conversation, Ishani shares her challenges in balancing multiple ventures, the importance of delegation, and her approach to building trust within her communities. She provides insights into the evolving landscape of e-learning and sustainability, emphasizing the need for personalized learning and effective communication.

+ + + +

Transcript:

+ +

SAMI: This is the Giant Robots Smashing into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. If you have no idea about this Giant Robots on Tour series, then please make sure you listen to our previous podcast, where we throw random icebreakers at each other and we have fun naming the new series. So, make sure you don't miss out on that one. I'm your host, Sami Birnbaum.

+ +

JARED: And I'm your other host, Jared Turner.

+ +

SAMI: And with us today is Ishani, CEO and Founder of Skillopp, which simplifies learning to amplify performance through AI, and Sustainr, the Fiverr for sustainable brands. We are so delighted to have you with us, Ishani, today. We're going to get more into depth and into detail exactly where you're at and what you're doing at present. But I always like to go back to the start with my guests because there's always a journey and a story about how they got to where they are. Would you give us some details about how you got to the place you are today?

+ +

ISHANI: Definitely. It's great to be on this. I'm delighted to also kind of share my story. It's been quite a journey. It all started a few years ago. I'm an instructional designer so that basically means that I design online courses for a living. So, if you see those ads on Instagram, "Hey, come to my masterclass," what I basically do is that I help in designing the whole course from the beginning but in a much better way.

+ +

I guess this whole journey of Sustainr and Skillopp really started after I graduated. So, I went to King's College, and I pursued a degree in liberal arts, after which I worked at UNDP. And I was exposed to this world of sustainability and all these really cool startups that were coming up in this space. And I thought to myself that this is such an interesting and innovative field to be in.

+ +

In every single startup that, you know, you would really do research around, you would just find these really interesting bits of information that you really didn't know. And I think that the business models per to se is also kind of like a way to emulate how you can live your own life in a much more efficient manner. That's why sustainability is called sustainability for a reason so that you can really sustain your livelihoods for a much longer amount of time.

+ +

I think just building upon that, when the pandemic started, I really thought of doing something around this. And we kind of created a community of practice, so to say, of just sustainable brands around the country, in the UK and India. We started connecting them with various opportunities, so it sort of became like a Fiverr [laughs] of sorts where we would kind of connect them to various kinds of opportunities that would help them grow.

+ +

I think when I went back to London for my master's, a lot of people in the faculty really liked the idea. And they were able to provide us with some funds, and we won a number of competitions. And that really led to the beginning of Sustainr, and we currently have around 40 brands on our platforms. We keep on having a lot of collaborations. We've also raised grants for a few startups as well. This idea of really merging learning with the community created impact, and I had no idea about that.

+ +

And I think when I started creating courses as well for other brands and other companies, this whole idea of Skillopp also emerged as well, where we really took into account one very important concept, which was dejargonization. Now, I'm not too sure if you're aware about this, but there's this very big problem that's happening in the world right now. It's called the information overload.

+ +

If you think about it, every single time you open, you know, some piece of content, or a reel, or anything, you see so many words that you just don't understand whether it's Web3, crypto, Bitcoin [chuckles], whatever it might be. So, what we basically did in that case through Skillopp, which was this new vertical that we created, we basically simplified content through using different AI tools. And that would really help automate digital learning and communication in organizations. And we've currently worked with the top MNCs in the world as well.

+ +

The whole idea, in a nutshell, in terms of my life so far, has really been around how exactly you can design content in the most simplest way possible. How do you dejargonize it? And also, how do you create impact in the sustainable space? Because that is one key area that I think can really teach us so much about our own lives and can create so much of impact given the current climate crisis as well.

+ +

JARED: That was a great intro. Thank you. You're working on two businesses. Are you still studying, or you finished studying now?

+ +

ISHANI: I finished studying.

+ +

JARED: You finished. So, I guess you were studying while you were working.

+ +

ISHANI: Mm-hmm.

+ +

JARED: But now you're working on two. So, how did you or how do you balance all of that? And how do you choose what to prioritize when they probably both seem just as important?

+ +

ISHANI: I think it took me some time to figure that out. It's not easy. I'm somewhat of an overthinker. So, it just so happens to be that when you think about several problems that your business is facing, you know, whether it's, you know, people; it's sales; it's operations, it just really makes you really flustered, and, you know, you're unable to figure out what do I exactly prioritize. One thing that really helped me was just reflecting on the business models and what I was up to, as well as what exactly deserved the amount of priority that it needed to.

+ +

So, what really ends up happening is that I think there's a lot of reflection on how do you delegate tasks, and that's how I exactly manage two businesses. I really believe in this whole concept that, as an entrepreneur, everybody looks at you and everyone's like, "Yeah, you must be doing it all," right? Like, the marketing, the sales, especially in the beginning.

+ +

But I believe that when you learn the art of delegation and just kind of letting go and surrendering that, okay, no, you know, I have a team who's handling this aspect of the business, and I should not worry about it, you automatically can start focusing on other aspects. And I think that's how I started prioritizing. I divided the tasks into whatever really received utmost importance in the beginning that was easier to do, and then, you know, you sort of get the hang of it.

+ +

I'd also like to add to the fact that I think we don't talk about this really often but look at, like, our moms, right? Like, they handle a household and their work at the same time, and they can do it. So, you know, I really think to myself, there are so many people who might be handling more than that, then why can't I do it? I think just setting that motivation really, really helps. And you can then start figuring out how to delegate, how to prioritize. But I think mindset is key because if you don't have the right mindset, you won't be able to do it.

+ +

SAMI: As a father of four, that analogy really resonates with me in terms of juggling all those different balls at the same time. But I can imagine it's exhausting as well. But you touched on this concept of dejargonization, which I love because I think there is such a barrier to learning sometimes because humans take simple things and make them complex. And it sounds like, through your e-learning platform, you're taking complex things and returning them back to being simple.

+ +

I've seen you describe yourself as a bad learner.

+ +

ISHANI: [laughs]

+ +

SAMI: What does that mean, and how exactly has that impacted you?

+ +

ISHANI: In the beginning, the reason why I pursued education, I guess, there was this very rebellious instinct that I had in mind. When I was in school, it was so different. I was told to especially memorize certain formulas in math. And there was this really gigantic physics book that I had to learn and, you know, kind of memorize the formulas and understand the concepts, no pictures at all. And, you know, you just had to be perceived as, hey, you know, if you can memorize them and you can get good grades, you are really, really smart, but if you can't, then that basically means that you don't have any future. And that was the kind of mindset that I grew up in.

+ +

And I think I had this rebellious instinct that if supposing I couldn't, like, especially because in science, I was really, really bad. I used to hate those horrible textbooks. I was just like, how can somebody learn through this? And I was just like, no, I want to change this. I want to change the way people approach education and learning. And I started seeing this and this started becoming so relevant.

+ +

A lot of us today might perceive that they know certain concepts. But when we start having a conversation around that concept, there are so many misconceptions that are created because of these preconceived notions of how they were taught earlier about a certain concept as well in school, right? I guess my mission is to kind of eliminate that barrier of questioning concepts right in the beginning when somebody is learning and not being like, hey, you know, if I don't understand this word, if I don't understand this concept, I'm really smart. I'm going to figure it out.

+ +

I hate the Superman complex that people have these days. I know it all. I really, really know it all. And I'm just like, well, do you? This is one of my favorite slogans, like, if you can't teach it, then don't preach it. And [laughs] I think that I keep on following that slogan all my life that if I really don't understand anything, I have to figure out a way to understand it, and that doesn't mean that I'm dumb or stupid. I have to figure out a way in terms of understanding that concept.

+ +

That's why I call myself a bad learner because I used to hate how I was taught in school. And I was just like, you know, I'm not going learn like this, either I have to change the way I think and I learn. That's the only way that I will do that. And that's why I got into education. I was just like, I really want to take some revenge on this [laughs].

+ +

SAMI: I love that. That really resonates with me. I would also, in that sense, I would describe myself as a bad learner, but someone with a good memory, especially when I didn't understand things. I'll never forget when I was studying for my degree. I actually wasn't far from you. I think you were in King's College.

+ +

ISHANI: Oh.

+ +

SAMI: Well, I was down the road in LSE.

+ +

ISHANI: Oh, nice. Neighbor.

+ +

SAMI: Yes, I remember studying for my degree there, and there was one topic I was studying that I just couldn't understand and get my head around. But there's kind of a way to play the system, and that is memorizing things. So, I promise you, I memorized sentences. I could not tell you what they meant, but I used them in my exam. It was kind of cheating, in a way, but it was kind of also working with the system that I had in front of me. But it sounds like if I had something like an e-learning platform at that time, that is something which could have explained things properly and played into strengths that I might have had that I wasn't able to discover in the regular system.

+ +

Do you see e-learning platforms...and I've seen this actually from people who, let's say, are studying for their A levels in this country now, which is exams they do ages of, I think, 17 or 16. A lot of them are turning to YouTube, and they learn from YouTubers, and there's other platforms. Do you see e-learning as something which could replace more conventional education, either high schools, degrees? Is that where you see the industry heading?

+ +

ISHANI: Well, I wouldn't say that e-learning can replace educational systems. I think, at the end of the day, when it comes to e-learning platforms, as well, I really love them. But I wouldn't say that they're as personalized as you would think. They could be. And the number one element to learn well is to personalize learning because everybody is different. Everybody thinks differently. Everybody has a very different process of thinking. Some people learn in a very auditory way. Some people like listening to podcasts like the ones that you're conducting. Some people like learning visually. Some people like learning kinesthetically.

+ +

Sometimes what I believe is that not every single e-learning platform can do justice to every single style of learning or every single individual. And I'm pretty sure there are 500 more styles of learning that we in the L&D space still haven't discovered yet. I think what e-learning can do and how we can really benefit from e-learning is using it as a tool. We should not depend on e-learning platforms completely, like, in terms of even, like, just simplifying content or, like, figuring out a way in terms of writing an essay. That is something that perhaps we can use it as a tool to brainstorm upon, that it makes our lives much easier.

+ +

At the end of the day, AI, artificial intelligence, as well as all these e-learning platforms that are coming up, it's a way in terms of conducting the menial tasks that you really didn't want to do so that you can focus on the big stuff. I think if we start approaching e-learning in that way and, you know, also figure out how to set limitations in terms of how we don't depend on it; we will not have, like, a crisis in terms of how we're looking at social media today, where everybody is just addicted to their phones.

+ +

JARED: Ishani, I wanted to ask specifically about your product, Skillopp. Who's your target market? You know, we've talked a lot about sort of learners from an education perspective, like high school, university. Are you targeting them, or is it more business, commercial users? And how did you discover that market as well?

+ +

ISHANI: Great. So, I think, again, it really happened to be upon chance. So, like, a little bit more about Skillopp. It's not exactly how a product works. We work in a much more adaptable and flexible manner in terms of how you can use AI to simplify content as well. We started working with a number of corporates through word of mouth, I guess, and we created a lot of impact in that space.

+ +

And what we did was that we would figure out what would be the best platforms and tools that they can deploy. And we would put them onto one system, and we would develop that for them. So, how it would really end up working would be, like, this very flexible product that we would make as per the needs of the corporate itself, rather than making something of our own, which could not be flexible or adaptable to what the corporation wanted as well. It's really cool because we just end up building on various kinds of innovations.

+ +

Like, recently, we would also be open to various forms of different tech partnerships in terms of building those systems as well. So, it just ended up creating this collaboration over competition mindset and where everything happened to be, like, this win-win formula when we would build products. And we would kind of go to these businesses as a service, and we would end up building a product for them. I think, that way, it was very interesting to see how that journey really happened. And I think it was just through experimentation, and I really experimented a lot.

+ +

We do also have, like, some developers who are working with us. And we would kind of go out of our way to figure out what the company or the corporate really wants. And we started building upon these products and then we were able to, like, deploy those particular needs of what that organization wanted in terms of what kind of product they really wanted and how they wanted to simplify content. So, it was, like, as if it was made by them, not by us. And it provided that sense of pride within the organization that, hey, you know, this is something that I really built.

+ +

This whole concept just got extended through word of mouth to various different organizations and institutions. But, like, through some random way, and I always thought that I'm going to work with an institution first, it just so happened to be working in the corporate space, which is very strange. But I guess that's how entrepreneurship, to a certain extent, works with so much of experimentation that went on.

+ +

JARED: You're using generative AI as part of that to identify, let's say, jargon and then simplify that language. And one of the problems that generative AI has is what they call the hallucination problem, where it sort of makes stuff up that's not true. Have you encountered that? And I'm curious of any ways you're trying to tackle it.

+ +

ISHANI: [laughs] So many times. I think AI it's like raising a baby, you know [laughs]. I always like to use that anecdote because [laughs], like, my experience in terms of, like, generative AI and AI, in general, it's always been, like, as if I'm bringing a baby up in terms of, you know, the machine learning aspect of it.

+ +

I think, yeah, we've encountered that quite a number of times. I think the best way in terms of also approaching this hallucination aspect is to kind of keep the task as specific as possible. If you want to teach somebody a little bit about sales and how do you exactly approach a customer in terms of closing in a deal, right? The way we can approach it. How do you simplify that process for, let's say, sales agents, right? It's to kind of really figure out what is that particular skill that the sales agent really needs help upon. So that if we try and specify it more, then the AI will really understand that, okay, I have to stick to this boundary. I really can't go out of that.

+ +

And making it as specific as possible really helped us in the process, and they were able to really upskill themselves in that one specific subskill. And we really, really worked on that conversation to such an extent that I even know the script of that conversation in terms of how a sales agent is supposed to negotiate and what would that script be for that particular industry and that organization. So, I think just specifying it as much as you can really helps. I think the hallucination effect happens so much, and that is one problem and also an area that I'd love to do more research in as well.

+ +

JARED: So, humans aren't going anywhere just yet.

+ +

ISHANI: Yeah, not going anywhere. Actually, I really don't think so. A lot of people just keep on talking about AI is going to be...and I would...actually, this is a question that I'd love to ask both of you as well that do you think AI is really going to replace human beings? And everybody just keeps on talking about it, and I don't really think so. But what do you think?

+ +

JARED: Oh, gosh, we could have a whole episode just on this.

+ +

ISHANI: [laughs]

+ +

JARED: There's a lot of parallels to the industrial revolution, where everyone said all of the machinery that was created was going to get people out of jobs, farming, and agriculture. And all it really did was shifted the demand for resources into different and slightly more specialized roles. I think we'll see a similar shift with AI. I do think, in time, there will be a significant portion of existing jobs that might go the way of AI overlords. But I'd like to think there'll always be a place for us little humans. What about you, Sami?

+ +

SAMI: I love this question. I think I've gone around the houses with this one. So, I've gone through different phases of like, oh my gosh, we're all going to die, and no one's going to have any more jobs, and we don't know what we're going to do. Even to the extent that I was really proud of myself that I learned on YouTube how to silicon my bathroom because I was adamant that AI could not do that. And so, if all else goes to pot, then at the very least, I have a skill that is valuable. And then, recently, I've seen the robots they're coming up with, so even that is not really going to work for me. It's really difficult to know. It's so difficult.

+ +

I find generative AI less compelling because of the hallucinations that we've spoken about. I see that as being far off, and a lot of it depends on the accuracy. Your baby analogy is great. Because the way we're used to interacting with computers is they give us responses that are kind of, like, binary. They're either right or they're wrong. It's like a green light, red light relationship. And when it comes to generative AI, you need to have that more personal relationship with the computer to have that conversation back and forward to get it where you want it to be.

+ +

Something that has definitely come more to the forefront is discriminative AI, which is AI that can tell a difference between certain data sets. So, I see that taking off a lot more. So, for example, they're using it in, like, the medical sector where the AI can discriminate or tell the difference between certain brain scans in terms of understanding what might be an issue and what might not be an issue. So, that is very powerful. We've actually had that for quite a long time. But as computing power is becoming more affordable, as certain chips have become available, it's becoming more widespread, and we can harness that a lot more.

+ +

So, discriminative AI, I think, is being very disruptive, and I think it will continue to be. Degenerative AI, I'm not sure because of the difficulties you've spoken about. But worst-case scenario, I will personally come and silicon your bathroom.

+ +

So, the e-learning company that you have, that seems more familiar to me. And maybe it could be also potentially more familiar to some of our listeners because a lot of us have kind of grown up on YouTube. And I'm not comparing it to YouTube. I know it's a very different beast altogether. It's something which we could possibly identify with and understand more. The Sustainr aspect is a little bit more foreign to me. So, I'd love to get to understand more of what the Sustainr company that you have is all about and how it works.

+ +

ISHANI: Like I said, I think Sustainr is this very interesting community that we built over the pandemic kind of touching upon this whole aspect of...and I think I'll also, like, come to this point in terms of how Skillopp and Sustainr are also kind of interlinked. It all, actually, technically speaking, started with the same problem: dejargonization.

+ +

What really happened was that when you also start a startup, especially in the sustainable space, what a lot of people, and when I talked to a lot of founders, especially the 40 brands that we have on our platform, it's like, "Ishani, I just don't know who exactly to approach. I don't know what...supposing I'm trying to find sourcing materials related to my business, supposing I'm trying to find individuals who can create content that is based on the concept of my business, I just don't see the results. And I don't see that people are able to understand and comprehend what I'm trying to talk about."

+ +

And I feel like this is also perhaps a cultural problem as well. I mean, for example, this has been my experience as well as a number of people in India. Because India is currently growing at a massive rate with the economy, as well as the startup boom that's happening. If you think about it, every single person's mindset is like, I really need to get this done. And that's why a lot of us are also very impatient.

+ +

So, just thinking about how we're actually really thinking, we create, like, this impatience sort of situationship in our head. And we don't want to perhaps learn about new things. That stops us from learning and really digging deep because we're just like, no, no, no, we need to get this done, and we need to hustle. And there's a lot of that culture that's present over here because our economy is growing. Startups are booming. And there's lots of work to be done. Like, trust me, if you come to Bangalore or Bombay, you will actually feel that pressure [laughs].

+ +

So, really thinking about that mindset, what really happens is that when somebody, especially in Southeast Asian countries or especially in a country like India, are looking for stuff for their sustainable business, a lot of people are like, "But what is sustainability? What is ESG? Is it just environment-related?" And, you know, just this communication style, so to say, creates a lot of impatience between both the parties, and that leads to mistrust. Miscommunication takes place. Orders don't come on time. There's a lot of problem and havoc. This also leads to a lot of mental stress.

+ +

That's why we created this platform, so to say. And how it really works is like, it's like any form of connecting platform. We have various categories, as well, through which people can perhaps list their business on the platform in terms of that particular category, whether it's in sourcing, whether it's in fundraising, finance, or even marketing per se.

+ +

And we just kind of connect them just like how you would connect people over LinkedIn, like, through an intro. But we would be the ones who would be part of that whole connection scenario so that everybody knows that there is, like, this trusted platform being built between the two people and that they're not alone. There's somebody else who's also dejargonizing the communication flow.

+ +

And through that, what really happens, Sami, is that, like, the ideas of collaborations really grew because we would also have events. We would also have, like, these very interesting micro podcasts just for the community. And we would just post all of that content that would, A, build a lot of positivity amongst people in that space. And, you know, it would just kind of lead to more productivity in terms of different collaborations. Like, for example, we just tied up somebody who was creating straws using, I think, coconut or something like that to a chain of vegan cafes.

+ +

I think what really happened was that through this trusted platform, through a community, I think it really, really bolsters a lot of positive mindset. At the end of the day, like I said in the beginning, I really think that it's all about mindset, which really helps you take that action. And that, in a nutshell, is what Sustainr really does in terms of just connecting resources.

+ +

And now because we work with corporates as well, if supposing there are companies who want to pursue, let's just say, corporate gifting or something like that, we kind of help and initiate that process as well. So, it just becomes, like, this interlinked network where you can really just harness as many collaborations as possible so that you can also grow your business. You have time for experimentation. You have the safe space as well. And I didn't get an opportunity to be a part of any such community. So, I was just like, why not try and see how I can create one?

+ +

JARED: That's great. It sounds like education and trust, a huge part of this marketplace. How do you ensure you find trusted partners, and how do you convince the people on the other side of that marketplace to trust you or to trust your marketplace?

+ +

ISHANI: So, I think in terms of building trust, it takes time. So, we're not a community, or we're not kind of, like, this platform; we're, like, telling everybody that, "Hey, you know, come on our platform. We'll ensure that your business will grow." I think, first of all, it's setting the right expectations in terms of what exactly you can really achieve out of this platform. B, I think what I really like to do is, like, a lot of phone calls, just talking to the founder in terms of how he started that particular idea of his. How did it really take place?

+ +

Our onboarding process is not like you have to fill in this very big, huge form, which will make you extremely bored, and you're just like, "Oh my God, this is, like, such a heavy task." Like, no, it's okay. There are some people in our team who also kind of talk to the founders and figure out what their story is all about. How did they really start that particular business? And if supposing what they're really looking for is something that we can really curtail to. Because we don't want to be also, like, a community where there's no value that we can add, then what's the whole point?

+ +

And I'm very hell-bent on setting those expectations so that when people actually join our platform, then, you know, it's not like, okay, like, this is going to be just spam coming on [laughs] your way in terms of all the other communities that we end up seeing. But it's so much more than that. I think it's kind of like when we establish that synergy that, all right, if this is what you're looking for, and these are the kind of people that we have, that's the only way that we kind of build that trust. And that trust-building, it takes time. It doesn't happen automatically; it takes a lot of time, and that's why we have a lot of events.

+ +

We share a lot of bits of content around, let's say, the investing market in the space of sustainability and ESG. What exactly is happening out there? We even link with other communities to build more trust. So, supposing there's a better community than Sustainr, I'd be like, yeah, 100%, you should definitely look at those communities. Like, that tagline has always been collaboration over competition, and I think it's always worked in our favor.

+ +

We would also end up collaborating with those communities around climate. In so many different aspects, that's helped us, and that's the way that you also kind of build trust, when you actually see those actionable steps being taken, and you see that taking place. But it's not something that I can, like, assure you, like, yeah, 100% the trust is built within that one day. It takes some time, but it happens over a period of time.

+ +

JARED: I love what you just said there about almost the long-term strategy of, you know what? If there's a better community, we're going to point you in that direction. That, to me, builds so much trust because the short-term option is to say, "Oh, okay, I've seen this. It's probably better for them, but that means they're not on our platform. So, that's not better for me." That is a tremendous way to build trust in a sort of long-term user base. So, I really love that.

+ +

SAMI: Yeah. I mean, we've only been, I don't know, we've been speaking for about half an hour, 40 minutes now, and I feel like I really trust you as well [laughter]. It's, like, rubbing off. This concept of, you know, demystification and simplifying things it shows this authenticity. And I think your personality comes across and the way that you run these businesses. And you're doing it in an incredibly genuine way. I think that really talks to people. I think people are looking, like, not for jargon. They really want authentic people they can relate to who are real human beings. And that's something which I think really comes across through speaking to you.

+ +

Obviously, as a consultancy, myself and Jared we work within thoughtbot, and we work with people like yourself to really try and solve their problems and understand what their pain points are. And we can come up with solutions through design or development. What would you say is your biggest challenge? In either one of these businesses or as a whole, where's your biggest challenge at the moment?

+ +

ISHANI: There are so many [laughs]. But I guess to start off with, kind of scaling it to a considerable level. But at the same time, you know, scaling requires investment, and scaling also requires some amount of time in terms of figuring out how exactly you want to grow your team, which also takes time. So, sometimes I feel like I'm in this catch-22 situation where I'm just like, if I do need investment, right? For example, scale or if I need investment to grow my team even further to get more clients so that I can target more projects, let's say for Skillopp; again, finding the right people it takes time. And I think that's something that I really also kind of struggle with. It took me a lot of time to find the right people for the projects that we're doing right now.

+ +

I think any tips would be great in terms of how exactly I can really do that so that even if supposing I want to raise investment and I know what I want to raise investment in, which is to grow the team, how exactly would I really approach that? Because I always feel like it's like this catch-22 situation.

+ +

JARED: Well, it sounds like you already have some clients, which is an infinite step up on most businesses that are starting out and trying to get investment. Like, the fact that you can prove you have revenue coming in is amazing. I mean, the typical things that investors want, like the investor deck, right? They're going to want to see your vision for the business. They're going to want to see your financials and the forecast. And then, it's a matter of finding the right investors as well because I guess there are so many out there. But I think you probably want to find one that matches your values around sustainability and dejargonization as well.

+ +

SAMI: Yeah, that's a great answer, Jared, actually. And, I think, just to add on top of that, this is where sometimes using a consultancy actually really helps. We see this a lot within thoughtbot, where someone is looking to get investment and wants to scale their team. But when you do that in-house, that comes with a lot of overheads.

+ +

So, for example, you might need an extra person, your HR team, to handle new people, you know, being directly employed. Going to a consultancy and getting a third-party delivery partner allows you to kind of scale your team quickly, but also, descale that team quickly as well, so that it gives you that flexibility whilst you're in that more turbulent zone of, "Oh, I'm trying to scale, and I'm trying to get investment. And I'm not sure where my budgets are." Until you, you know, complete that scaling that you want to do, you get to a place where you're more stable. And then, actually, what thoughtbot does is helps people to then hire their own in-person team. But yeah, something like a consultancy can give that flexibility.

+ +

But the way you describe this catch-22 situation is so common because what do I do first? I've got all these levers I could pull. So, I could pull the investment lever, or I could pull the, you know, extra resources lever. And then, there's like, you know, extra revenue lever as well. So, it's a really difficult problem. But definitely, we found, as a consultancy, that having that flexibility using third-party partners can be something which helps.

+ +

JARED: And I wanted to just ask, because I remember you were saying you're working with some developers, are they developers you've hired, or is that a third-party team you're working with?

+ +

ISHANI: It's very similar to what you really mentioned. It's like a strategic partnership with a third-party team. But, again, I think finding the third-party team also, like, it takes a long time to find. But I think that I really liked the thought that you were really talking about as well earlier, where you were kind of mentioning that that whole catch-22 situation is super, super important to understand.

+ +

And I feel that instead of kind of going on LinkedIn and, like, posting so many, like, you know, these job descriptions with the overhead costs...I started learning that once I made that mistake. I think I learned so much about that. And I think that what you said it's also, like, reflecting on the fact that, okay, you really can see this through the strategic partnerships. And I think I'd love to be somebody or, like, you know, aspire to be someone who can, like, master that whole art of finding the third-party consultancies like you were mentioning, especially what you're doing as well. So, I think it's great, and thank you so much for the feedback and as well as answering question.

+ +

SAMI: It's been great to have you on. And doing a podcast like this it just gives us the opportunity to speak to people like yourself. If people want to reach out to you, do you have any specific place you'd like them to reach out?

+ +

ISHANI: You can go on my LinkedIn, where you'll find a lot of stuff and links to what I do.

+ +

SAMI: Cool. So, I highly recommend our listeners to take a look at Skillopp, and take a look at Sustainr, and get to know all the great work that Ishani is doing.

+ +

For our listeners, we're going to bring you lots more content like this. This was the first one in the Giant Robots on Tour series. Your only challenge before the next one is to hit the subscribe button to make sure you get this content directly as soon as it comes out because we've got some incredible guests lined up for you.

+ +

You can find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See ya.

+ +

Okay, before we sign off, a quick request. If you're enjoying Giant Robots on Tour, please drop us a review on Apple Podcasts or Spotify. Your reviews help us grow and reach more listeners, and we'd love to hear what you think. Thanks for being part of our journey, and stay tuned for more episodes.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9klz4FZB + + ]]> + + + + 531: Polished Podcasting with Mandy Moore + https://podcast.thoughtbot.com/531 + 6ba02c8b-3721-48e6-a218-dd256fad78eb + Thu, 27 Jun 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Will Larry and Victoria Guido chat with Mandy Moore, the mastermind behind thoughtbot's podcasts, about the technical aspects and crucial role of editing in creating top-notch content. Mandy highlights the importance of having a producer handle behind-the-scenes work, allowing hosts to focus on captivating content, and discusses how a well-produced podcast can boost a company's brand presence and serve as a potent sales tool. + 24:31 + no + + + Hosts Will Larry and Victoria Guido chat with Mandy Moore, the mastermind behind thoughtbot's Giant Robots Smashing Into Other Giant Robots and Bike Shed podcasts. Mandy shares some great insights on the technical aspects and the crucial role of editing in creating top-notch content. She stresses the importance of having a producer to handle the behind-the-scenes work, allowing the hosts to focus on delivering captivating content. Mandy also shares her personal journey into podcast editing, highlighting her resourcefulness and how her skills evolved over time. +Will and Victoria also delved into the strategic advantages of podcasting for businesses, highlighting its effectiveness in helping thoughtbot build a community and establish authority as a company. Mandy discusses how a well-produced podcast can be a potent sales tool and can significantly boost a company's brand presence. They even touch on the future of podcasting, with Mandy pointing out how continuous podcast production can help solidify a company's reputation, even in uncertain times. The episode wraps with some practical advice for anyone interested in starting their own podcasts, emphasizing the need for passion, persistence, and a clear strategy. +Follow Mandy Moore on LinkedIn (https://www.linkedin.com/in/missmandymoore/). Visit her website: mandymoore.tech (https://mandymoore.tech) +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Mandy Moore, our long-time Podcast Editor and Creative Content Marketer. Mandy, thank you for joining us. +MANDY: Thank you so much. +VICTORIA: So, I'm excited to dive into the topic of podcast, and creative content, and strategies for companies that are maybe long-time listeners of the Giant Robots podcast who are just curious about why we do this podcast and what it does for us as a company. So, excited to get into that, but before we do, let's start with a fun question to get us warmed up. Mandy, is there anything fun, exciting going on in your world outside of work? +MANDY: Outside of work, I spend a lot of time at my local dance studio doing a mixture of dance and aerial arts. It gives me something physical to do after my work days. It's an afternoon thing for me. So, I spend about one to two hours there. And it's really helped me overcome a lot of challenges in my life, dealing with a lot of trauma and other aspects of overall personal development and recovery. +WILL: That's awesome. I normally would never know what you're even talking about, or whatever, but [chuckles] my daughter is into dance. So, every Tuesday, I take her to dance. She begs me to take her, so I take her. So, my daughter is three—about to turn four. And every time we go to dance, she begs us to let her do the aerial dance. Like, I don't ever try to tell her, "Hey, you're too small," or whatever, but we're like, "Let's wait on that one. And then, let's wait until you can do the dance and then get up there." But she is so excited to get on the aerial dance and to do that. So, for you, was it scary when you started doing it, or did you just jump right in? How was it? +MANDY: I always jump right into everything, but it was hard at first. It looks like it shouldn't be that hard, but it takes a lot of strength. And I was in a much different place eight months ago than I am now. It amazes me the transformation and growth that I've been able to see in myself because, from the very beginning, my instructor encouraged me to video myself. So, I have beautiful videos of progressions. And I can't wait to get a little bit more confident with my own social media and start sharing some of the before and afters because I really want to inspire people. It's done wonders for me and my mental health. +WILL: A lot of respect to you because I don't know if I could just trust, I don't know what you call it, but that ribbon, that material just to hold you. I don't know if I could do it. So, a lot of respect to you [chuckles]. +MANDY: So, my instructor likes to point out a fun fact, and I'm going to butcher it. I think it can hold whatever a baby elephant weighs. It can hold up to three tons safely. +WILL: Is it...I'm going to throw this...I'ma tie it in with Victoria. Is it kind of like...because I know with rock climbing, it's all about hand placement, especially if you're belaying. Are the mistakes when you are not paying attention, and you let go of one of the materials, or how does it work? +MANDY: Mistakes happen when you think about it too much. And that is what I'm always working on is to just stop thinking about it and just doing it because I'm an overthinker, too. And when I start to think about it too much, then I get messed up. But your body knows. Your body adapts. And it learns after the exercise is over. So, in the evenings, after your exercises, that's when your body is, like, doing its internal magic and, like, memorizing your stuff. So, that's why when you go back, it gets easier each time because your muscle memory actually grows when you're on your downtime. +VICTORIA: Oh yeah. Yeah, I was going to say about climbing...it's funny that you asked that question, Will, about, like, the things that actually hold you because people get that question in climbing, too, about the ropes. Like, are the ropes actually going to hold you? And once you're comfortable with it, you know that it can hold a lot more weight than you [laughs], but it still can be scary. And I've seen people in Joshua Tree doing aerial silks from a line that's been drawn across the tops of two boulders. So, super cool. There's a lot of crossover in the community, I think, between people who do that type of dance and who also enjoy climbing and being outside. So, I love it. +And so, you make a really good point about how you learn and how information seeps into your brain. And maybe how do you see the world of podcasting and all the things you can learn from podcasting, like, how does that fit into, like, how you learn and how you think about the world? +MANDY: You know, I've built my entire career on figuring things out, and just building memory, and repeating processes, and figuring out what people want. Because, to me, editing is more than AI can do at this time. +WILL: Yeah. And I think you're super talented at what you do, so I just want to make sure that I tell you that. Like, you've done a really good job with us. I remember whenever I first had a conversation with Chad, I didn't know to what extent that being a podcast host with this podcast would be. But whenever he said, "We have an editor who will cut some stuff, make you sound good," I was like, "Oh, okay." "Like, essentially, Mandy is doing the hard work for us." +MANDY: [laughs] +WILL: And so, I was like, "I'm in. Let's do this." So, it's an art to do this. It's an art. How did you get started? How did you get the ball rolling to get to the point you're at right now? +MANDY: I was scrappy. I go in time by how old my daughter is, and my daughter is almost 15. So, that's how long I've been doing this. Because I was a single mom and I was a waitress. So, at the time, I had a one-bedroom apartment, and I still had a laptop. And my neighbor didn't have a Wi-Fi password. So, I used my neighbor's Wi-Fi, and I started doing virtual assistant jobs. And I met a developer. He was like, "Can you edit a podcast for me?" And I was like, "Yeah, I can totally do that." +And I got off the call and started Googling what is a podcast. And this was back in 2010, mind you, so podcasting was new at that point. And so, I just learned it, and I did a decent job. And every podcast that he did, I got better and better. And then, he had friends, and it just kind of turned into, like, Mandy's the go-to for tech podcasting there for a little bit. And I, at one point, got a referral to thoughtbot, and I've been with you ever since. I think it's been going on five or six years now. +VICTORIA: What's your first piece of advice for someone who's interested in starting their own podcast? +MANDY: Get a producer. I prefer to be behind the scenes. So, I like to help other people shine. So, like, my goal as a producer is just to have the host show up and be the talent and say the interesting things. So, if you want to have the bandwidth to be able to do that, you know, let somebody else do that work who specializes it because you can really bring your full self to the table and do what you need to do as the host and have fun with it. +VICTORIA: Yeah. And I think people either correctly estimate that it is a lot of work to edit your own podcast and to create the content, do all the marketing, invite people, plan great content. And it is much easier if you have help [laughs]. And you're probably going to have a better podcast that people want to listen to because it sounds good, and you might not want to skimp on that detail. +MANDY: Yeah. The other thing I would say when you go to start a podcast is a lot of people are focused on equipment. And that can take you down a long rabbit hole and make you never start to actually record the podcast because you're too worried about all of the details. Get a microphone and go. You don't even need an editor. You can make yourself sound decent through tons of free software. Audacity is one of my favorite platforms to use to edit podcasts. It's been free and open source since I've started. +WILL: Yeah. I love the advice, what you said, because not everyone...I don't want to do total assumptions, but majority of people fit in two camps. You have the people that want to be out front and chat and can connect with anyone. But you also have the people behind the scenes. So, I'm glad you said that because I think a lot of stuff...when people realize who they really are and what they're good at, it makes them so much better. I can't imagine doing a podcast and trying to edit everything and push it out. I think I'm decent at doing the podcast, and you make us so much better. So, I'm so glad that you said that about kind of just knowing your roles and what's your strengths and everything, so... +MANDY: Absolutely. I find it relaxing to edit a podcast. Believe it or not, editing a podcast with software is kind of like putting a puzzle together. I was a kid that loved to sit down with puzzles. You know, it is true that once I come to kind of memorize waveforms, like, Will, I know when you're going to say, "Um" a lot of times before I even hear you say, "Um" because I've recognized your speech patterns and same with Victoria. I will be able to pick them out. And it's very interesting. That's a little-known fact from a producer standpoint [chuckles]. +WILL: Well, that's actually really cool because I don't really talk about this much, but I'm originally from Louisiana, and so I have a thick Southern accent. And so, that was actually one of my fears about doing, like, a podcast. So, it's actually interesting that you're saying that you know the ums and, um, which I just did [laughs], but you know how to help us out with that. +So, yeah, that's actually...I think that was one of the things I have respect for you is that you break down the barriers for people to be better and not be so insecure. Because if you're from Louisiana, there are so many words if you look at it and you try to pronounce it, it's going to mess you up, like Atchafalaya, or Natchitoches, or so many of those words that you're like, you almost have to know the word and pronouncing is going to mess you up. +MANDY: I call it...and I don't think anybody is a not smart person, but when I edit podcasts, like, the finished product comes out, I liken it to giving the speakers IQ points because the listeners hear the final, polished version. A lot of people start sentences three times over. They only hear the polished version. So, in essence, it's giving the speakers IQ points just to give them a little bit more, you know, of a leg up. +Nobody wants to really hear somebody bumbling around, but we all do it. We all get nervous. It's human nature to stumble and get nervous and let all those speech patterns out that show us as nervous. But that's what we're for is to clean everybody up. And I love getting to help people have that confidence to go because it's just like, "Don't worry. I got you. Just go out there, have fun, and you're going to sound great." +VICTORIA: And, in your experience, what kind of reasons for a podcast make the most sense for a business? Like, it's a common piece of advice if you want to build a community to start a podcast, but why is that? Or, like, when does it really make sense for you to start your own podcast? +MANDY: I mean, you nailed the number one is the community. But, honestly, also, it's a great sales tool, especially if you're a customer with customers, and you're helping people network and expand the network. You're featuring the people. You're expanding the network broader than a community like in a Slack channel, say, or a message board because those are fine, too. +But putting your company out there and being authority and also giving people access to free content that is helpful to them can really help a business establish that trust in the market and be like, wow, they really take their time to put this out there. One of the things that I constantly still to this day hear people talk about is the thoughtbot Handbook, that was written years and years ago. And it was a beautiful piece of free content, and everybody still talks about it. +WILL: Yeah, I agree. I think one thing about thoughtbot is the handbook. I still hear people talk about it, and it's referenced often. So, that's actually really good advice. What does success look like for you, like, six months now to five years? Where do you want to go? +MANDY: I think, for me, I've been in the tech industry for a really long time. I've fallen into the background a little bit too much in that I used to produce a pretty popular podcast called Greater Than Code. And I needed to take a step back from that because, one, it was becoming pretty much a full-time job. +You know, content is in a really weird place. I've really been trying to pivot into the general content creation space because I do marketing as well, social media, design, and assets. I've designed my own website. I design my own graphics. So, just kind of letting people know that I'm kind of a one-stop, one-shot person. I do it all myself right now, and I have forever. The only thing I outsource is I have a transcriptionist who is a real person, which is a great selling point to a lot of clients of mine because I don't use AI. And I do have a person who goes over it with the human touch who is well-versed in the software developer lingo. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: What kind of trends do you see with podcasting and with the technology used to manage and produce podcasts? +MANDY: I see podcasting, in general, be a come-and-go trend in this industry. It tends to be, you know, one of the things that businesses are excited to ramp up on. But then it's also one of the things that is the first to go when things get tough or busy or you need to allocate your resources elsewhere. Podcasting seems to be like a trend that I see coming, going with the economy. +It's actually very weird to bring it to mind now that you mention it because people love podcasts. But when things are unstable, it's almost like they see it as a perk, and it just becomes something that's easily let go. And that's why I think thoughtbot and the podcasts have been so strong is that they have been kept going no matter what in the industry. +And thoughtbot has really become an authority in not just, you know, it started out as a Ruby podcast. And it very much has grown into a bigger startup, entrepreneurial, consultancy-driven show. And so, it just shows that when you stick in the game, what, we're 520-something episodes in now, that you really do have great things achieved. +VICTORIA: Yeah. And it sounds like just, you know, having that persistence and just keep going, and if you've found a formula that works for you, you can really benefit from continuing to invest in it. I love that. And let's see, what tips do you give people on how to have more exciting conversations, more engagement? +MANDY: I love when people just join the call and immediately hit record because some of the best parts of the conversations happen, and you're like, "Oh, wait, we should have been recording that." Start recording and relax and have...The opening conversations that we started this conversation with, it's an icebreaker. It gets into some of your everyday background. +And as hosts, one of the things that I told Victoria and Will to establish rapport with the audience to kind of start dropping a bit of the narrative. You talk about your story, and then the listeners become invested in you, and that's why they come back, too. It's great content all around, but they also really start to love the hosts too. +WILL: Yeah, I agree with that because most of the podcasts that I do listen to it's mostly around the host and the way that they treat people. Because if there's a host that's very mean, aggressive, I'm probably not going to listen to them. And, honestly, that's just me, like, I'm not saying don't listen to them. But the hosts do make the podcast a lot of times. And I'm not saying that we make the podcast though, but... +MANDY: [laughs] You do. +WILL: [laughs] +MANDY: It's the chemistry. You guys, I don't know if you know this, but I'm your biggest fan. Like, it's the chemistry. And it's The Bike shed. Fun fact: Joël and Stephanie, like, I told Joël [laughs]...when Joël took over from Steph and Chris, he had different co-hosts each week. And as soon as he had his episode with Stephanie, I said, "Joël, it's Stephanie." +VICTORIA: Yeah. And it can take a little while to get your dynamic between your co-host going. And other times, it happens right away, and it's very easy and natural. So, I love that for Stephanie and Joël. So, the idea behind a podcast like The Bike Shed, where it's two main hosts and they're coming up with different topics that they want to dive into, and sometimes they have guests but most of the time they don't, versus a show like Giant Robots where you're interviewing guests, what do you think about the content for each of those? Like, how do you kind of separate those in your mind and the direction content-wise? +MANDY: Marketing and knowing your audience. So, the Giant Robots appeals to startups and entrepreneurs. The Bike Shed is more into the code and into the nitty gritty of software development, so they go into deeper concepts. But Giant Robots is more about talking to the people. It's more of an interview-style show. It's featuring interesting people doing really awesome things and, getting the stories out there and connecting. And that's why I love that thoughtbot has both podcasts. We've just started, what—Giant Robots on Tour—to cater to the EWAA region, which is super exciting. +VICTORIA: Yeah and, for me, being an interview-style podcast gives me this opportunity to have these deep conversations with really interesting people that you wouldn't necessarily get into in, like, a normal networking event, right? +MANDY: Right. +VICTORIA: So, if you can think of a list of 10 interesting people you want to talk to, you should start a podcast. +[laughter] +MANDY: And if you can think of those people, a producer like me will also hunt those ten interesting people down for you and see if they'll talk to you because we can do that, too. +WILL: That is the truth. +MANDY: I've tracked some pretty cool people down. I'm pretty proud of my skills. +VICTORIA: We are absolutely thrilled to have you with us here today, Mandy, and to be such a big part of our podcast, and super delighted to have you come out of the background and be on the show with us today and share your voice. Do you have anything else that you'd like to promote? +MANDY: I'd just like to say that I am taking on clients. I would love to get into a general creative content role to utilize all my many skills that I've scrappily picked up over the years. It's hard to put into a resume. You can check me out at mandymoore.tech. +WILL: It's not just podcasts, correct? So, if I wanted to try to become an influencer, could you help me with that? Like, what's the different areas that you could help me? +MANDY: Oh, girl, yes. Let's make you an influencer, Will. Let's go. +VICTORIA: I could see that for you, Will. +WILL: I've thought about it, but it's a lot of work. So, that's a big thing, so...[laughs] +VICTORIA: Wonderful. I think that's really interesting to think about, Mandy. And I hope that people get a lot out of this episode when they're trying...if they're in this process of considering their own marketing plans, and podcast production, and other types of creative strategy, they might have to reach out to you. +MANDY: Thank you so much for having me. +WILL: Thank you for being here. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23Larry. +VICTORIA: And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + Podcast production, podcast editing, Mandy Moore, creative content, business podcasting, podcast strategy, building community, brand authority, content marketing, podcast trends, podcast tools, personal growth, podcast producer, podcasting tips, audience engagement, digital marketing, podcast success, podcast consistency, brand presence, podcast journey + + Hosts Will Larry and Victoria Guido chat with Mandy Moore, the mastermind behind thoughtbot's Giant Robots Smashing Into Other Giant Robots and Bike Shed podcasts. Mandy shares some great insights on the technical aspects and the crucial role of editing in creating top-notch content. She stresses the importance of having a producer to handle the behind-the-scenes work, allowing the hosts to focus on delivering captivating content. Mandy also shares her personal journey into podcast editing, highlighting her resourcefulness and how her skills evolved over time.

+ +

Will and Victoria also delved into the strategic advantages of podcasting for businesses, highlighting its effectiveness in helping thoughtbot build a community and establish authority as a company. Mandy discusses how a well-produced podcast can be a potent sales tool and can significantly boost a company's brand presence. They even touch on the future of podcasting, with Mandy pointing out how continuous podcast production can help solidify a company's reputation, even in uncertain times. The episode wraps with some practical advice for anyone interested in starting their own podcasts, emphasizing the need for passion, persistence, and a clear strategy.

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Mandy Moore, our long-time Podcast Editor and Creative Content Marketer. Mandy, thank you for joining us.

+ +

MANDY: Thank you so much.

+ +

VICTORIA: So, I'm excited to dive into the topic of podcast, and creative content, and strategies for companies that are maybe long-time listeners of the Giant Robots podcast who are just curious about why we do this podcast and what it does for us as a company. So, excited to get into that, but before we do, let's start with a fun question to get us warmed up. Mandy, is there anything fun, exciting going on in your world outside of work?

+ +

MANDY: Outside of work, I spend a lot of time at my local dance studio doing a mixture of dance and aerial arts. It gives me something physical to do after my work days. It's an afternoon thing for me. So, I spend about one to two hours there. And it's really helped me overcome a lot of challenges in my life, dealing with a lot of trauma and other aspects of overall personal development and recovery.

+ +

WILL: That's awesome. I normally would never know what you're even talking about, or whatever, but [chuckles] my daughter is into dance. So, every Tuesday, I take her to dance. She begs me to take her, so I take her. So, my daughter is three—about to turn four. And every time we go to dance, she begs us to let her do the aerial dance. Like, I don't ever try to tell her, "Hey, you're too small," or whatever, but we're like, "Let's wait on that one. And then, let's wait until you can do the dance and then get up there." But she is so excited to get on the aerial dance and to do that. So, for you, was it scary when you started doing it, or did you just jump right in? How was it?

+ +

MANDY: I always jump right into everything, but it was hard at first. It looks like it shouldn't be that hard, but it takes a lot of strength. And I was in a much different place eight months ago than I am now. It amazes me the transformation and growth that I've been able to see in myself because, from the very beginning, my instructor encouraged me to video myself. So, I have beautiful videos of progressions. And I can't wait to get a little bit more confident with my own social media and start sharing some of the before and afters because I really want to inspire people. It's done wonders for me and my mental health.

+ +

WILL: A lot of respect to you because I don't know if I could just trust, I don't know what you call it, but that ribbon, that material just to hold you. I don't know if I could do it. So, a lot of respect to you [chuckles].

+ +

MANDY: So, my instructor likes to point out a fun fact, and I'm going to butcher it. I think it can hold whatever a baby elephant weighs. It can hold up to three tons safely.

+ +

WILL: Is it...I'm going to throw this...I'ma tie it in with Victoria. Is it kind of like...because I know with rock climbing, it's all about hand placement, especially if you're belaying. Are the mistakes when you are not paying attention, and you let go of one of the materials, or how does it work?

+ +

MANDY: Mistakes happen when you think about it too much. And that is what I'm always working on is to just stop thinking about it and just doing it because I'm an overthinker, too. And when I start to think about it too much, then I get messed up. But your body knows. Your body adapts. And it learns after the exercise is over. So, in the evenings, after your exercises, that's when your body is, like, doing its internal magic and, like, memorizing your stuff. So, that's why when you go back, it gets easier each time because your muscle memory actually grows when you're on your downtime.

+ +

VICTORIA: Oh yeah. Yeah, I was going to say about climbing...it's funny that you asked that question, Will, about, like, the things that actually hold you because people get that question in climbing, too, about the ropes. Like, are the ropes actually going to hold you? And once you're comfortable with it, you know that it can hold a lot more weight than you [laughs], but it still can be scary. And I've seen people in Joshua Tree doing aerial silks from a line that's been drawn across the tops of two boulders. So, super cool. There's a lot of crossover in the community, I think, between people who do that type of dance and who also enjoy climbing and being outside. So, I love it.

+ +

And so, you make a really good point about how you learn and how information seeps into your brain. And maybe how do you see the world of podcasting and all the things you can learn from podcasting, like, how does that fit into, like, how you learn and how you think about the world?

+ +

MANDY: You know, I've built my entire career on figuring things out, and just building memory, and repeating processes, and figuring out what people want. Because, to me, editing is more than AI can do at this time.

+ +

WILL: Yeah. And I think you're super talented at what you do, so I just want to make sure that I tell you that. Like, you've done a really good job with us. I remember whenever I first had a conversation with Chad, I didn't know to what extent that being a podcast host with this podcast would be. But whenever he said, "We have an editor who will cut some stuff, make you sound good," I was like, "Oh, okay." "Like, essentially, Mandy is doing the hard work for us."

+ +

MANDY: [laughs]

+ +

WILL: And so, I was like, "I'm in. Let's do this." So, it's an art to do this. It's an art. How did you get started? How did you get the ball rolling to get to the point you're at right now?

+ +

MANDY: I was scrappy. I go in time by how old my daughter is, and my daughter is almost 15. So, that's how long I've been doing this. Because I was a single mom and I was a waitress. So, at the time, I had a one-bedroom apartment, and I still had a laptop. And my neighbor didn't have a Wi-Fi password. So, I used my neighbor's Wi-Fi, and I started doing virtual assistant jobs. And I met a developer. He was like, "Can you edit a podcast for me?" And I was like, "Yeah, I can totally do that."

+ +

And I got off the call and started Googling what is a podcast. And this was back in 2010, mind you, so podcasting was new at that point. And so, I just learned it, and I did a decent job. And every podcast that he did, I got better and better. And then, he had friends, and it just kind of turned into, like, Mandy's the go-to for tech podcasting there for a little bit. And I, at one point, got a referral to thoughtbot, and I've been with you ever since. I think it's been going on five or six years now.

+ +

VICTORIA: What's your first piece of advice for someone who's interested in starting their own podcast?

+ +

MANDY: Get a producer. I prefer to be behind the scenes. So, I like to help other people shine. So, like, my goal as a producer is just to have the host show up and be the talent and say the interesting things. So, if you want to have the bandwidth to be able to do that, you know, let somebody else do that work who specializes it because you can really bring your full self to the table and do what you need to do as the host and have fun with it.

+ +

VICTORIA: Yeah. And I think people either correctly estimate that it is a lot of work to edit your own podcast and to create the content, do all the marketing, invite people, plan great content. And it is much easier if you have help [laughs]. And you're probably going to have a better podcast that people want to listen to because it sounds good, and you might not want to skimp on that detail.

+ +

MANDY: Yeah. The other thing I would say when you go to start a podcast is a lot of people are focused on equipment. And that can take you down a long rabbit hole and make you never start to actually record the podcast because you're too worried about all of the details. Get a microphone and go. You don't even need an editor. You can make yourself sound decent through tons of free software. Audacity is one of my favorite platforms to use to edit podcasts. It's been free and open source since I've started.

+ +

WILL: Yeah. I love the advice, what you said, because not everyone...I don't want to do total assumptions, but majority of people fit in two camps. You have the people that want to be out front and chat and can connect with anyone. But you also have the people behind the scenes. So, I'm glad you said that because I think a lot of stuff...when people realize who they really are and what they're good at, it makes them so much better. I can't imagine doing a podcast and trying to edit everything and push it out. I think I'm decent at doing the podcast, and you make us so much better. So, I'm so glad that you said that about kind of just knowing your roles and what's your strengths and everything, so...

+ +

MANDY: Absolutely. I find it relaxing to edit a podcast. Believe it or not, editing a podcast with software is kind of like putting a puzzle together. I was a kid that loved to sit down with puzzles. You know, it is true that once I come to kind of memorize waveforms, like, Will, I know when you're going to say, "Um" a lot of times before I even hear you say, "Um" because I've recognized your speech patterns and same with Victoria. I will be able to pick them out. And it's very interesting. That's a little-known fact from a producer standpoint [chuckles].

+ +

WILL: Well, that's actually really cool because I don't really talk about this much, but I'm originally from Louisiana, and so I have a thick Southern accent. And so, that was actually one of my fears about doing, like, a podcast. So, it's actually interesting that you're saying that you know the ums and, um, which I just did [laughs], but you know how to help us out with that.

+ +

So, yeah, that's actually...I think that was one of the things I have respect for you is that you break down the barriers for people to be better and not be so insecure. Because if you're from Louisiana, there are so many words if you look at it and you try to pronounce it, it's going to mess you up, like Atchafalaya, or Natchitoches, or so many of those words that you're like, you almost have to know the word and pronouncing is going to mess you up.

+ +

MANDY: I call it...and I don't think anybody is a not smart person, but when I edit podcasts, like, the finished product comes out, I liken it to giving the speakers IQ points because the listeners hear the final, polished version. A lot of people start sentences three times over. They only hear the polished version. So, in essence, it's giving the speakers IQ points just to give them a little bit more, you know, of a leg up.

+ +

Nobody wants to really hear somebody bumbling around, but we all do it. We all get nervous. It's human nature to stumble and get nervous and let all those speech patterns out that show us as nervous. But that's what we're for is to clean everybody up. And I love getting to help people have that confidence to go because it's just like, "Don't worry. I got you. Just go out there, have fun, and you're going to sound great."

+ +

VICTORIA: And, in your experience, what kind of reasons for a podcast make the most sense for a business? Like, it's a common piece of advice if you want to build a community to start a podcast, but why is that? Or, like, when does it really make sense for you to start your own podcast?

+ +

MANDY: I mean, you nailed the number one is the community. But, honestly, also, it's a great sales tool, especially if you're a customer with customers, and you're helping people network and expand the network. You're featuring the people. You're expanding the network broader than a community like in a Slack channel, say, or a message board because those are fine, too.

+ +

But putting your company out there and being authority and also giving people access to free content that is helpful to them can really help a business establish that trust in the market and be like, wow, they really take their time to put this out there. One of the things that I constantly still to this day hear people talk about is the thoughtbot Handbook, that was written years and years ago. And it was a beautiful piece of free content, and everybody still talks about it.

+ +

WILL: Yeah, I agree. I think one thing about thoughtbot is the handbook. I still hear people talk about it, and it's referenced often. So, that's actually really good advice. What does success look like for you, like, six months now to five years? Where do you want to go?

+ +

MANDY: I think, for me, I've been in the tech industry for a really long time. I've fallen into the background a little bit too much in that I used to produce a pretty popular podcast called Greater Than Code. And I needed to take a step back from that because, one, it was becoming pretty much a full-time job.

+ +

You know, content is in a really weird place. I've really been trying to pivot into the general content creation space because I do marketing as well, social media, design, and assets. I've designed my own website. I design my own graphics. So, just kind of letting people know that I'm kind of a one-stop, one-shot person. I do it all myself right now, and I have forever. The only thing I outsource is I have a transcriptionist who is a real person, which is a great selling point to a lot of clients of mine because I don't use AI. And I do have a person who goes over it with the human touch who is well-versed in the software developer lingo.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: What kind of trends do you see with podcasting and with the technology used to manage and produce podcasts?

+ +

MANDY: I see podcasting, in general, be a come-and-go trend in this industry. It tends to be, you know, one of the things that businesses are excited to ramp up on. But then it's also one of the things that is the first to go when things get tough or busy or you need to allocate your resources elsewhere. Podcasting seems to be like a trend that I see coming, going with the economy.

+ +

It's actually very weird to bring it to mind now that you mention it because people love podcasts. But when things are unstable, it's almost like they see it as a perk, and it just becomes something that's easily let go. And that's why I think thoughtbot and the podcasts have been so strong is that they have been kept going no matter what in the industry.

+ +

And thoughtbot has really become an authority in not just, you know, it started out as a Ruby podcast. And it very much has grown into a bigger startup, entrepreneurial, consultancy-driven show. And so, it just shows that when you stick in the game, what, we're 520-something episodes in now, that you really do have great things achieved.

+ +

VICTORIA: Yeah. And it sounds like just, you know, having that persistence and just keep going, and if you've found a formula that works for you, you can really benefit from continuing to invest in it. I love that. And let's see, what tips do you give people on how to have more exciting conversations, more engagement?

+ +

MANDY: I love when people just join the call and immediately hit record because some of the best parts of the conversations happen, and you're like, "Oh, wait, we should have been recording that." Start recording and relax and have...The opening conversations that we started this conversation with, it's an icebreaker. It gets into some of your everyday background.

+ +

And as hosts, one of the things that I told Victoria and Will to establish rapport with the audience to kind of start dropping a bit of the narrative. You talk about your story, and then the listeners become invested in you, and that's why they come back, too. It's great content all around, but they also really start to love the hosts too.

+ +

WILL: Yeah, I agree with that because most of the podcasts that I do listen to it's mostly around the host and the way that they treat people. Because if there's a host that's very mean, aggressive, I'm probably not going to listen to them. And, honestly, that's just me, like, I'm not saying don't listen to them. But the hosts do make the podcast a lot of times. And I'm not saying that we make the podcast though, but...

+ +

MANDY: [laughs] You do.

+ +

WILL: [laughs]

+ +

MANDY: It's the chemistry. You guys, I don't know if you know this, but I'm your biggest fan. Like, it's the chemistry. And it's The Bike shed. Fun fact: Joël and Stephanie, like, I told Joël [laughs]...when Joël took over from Steph and Chris, he had different co-hosts each week. And as soon as he had his episode with Stephanie, I said, "Joël, it's Stephanie."

+ +

VICTORIA: Yeah. And it can take a little while to get your dynamic between your co-host going. And other times, it happens right away, and it's very easy and natural. So, I love that for Stephanie and Joël. So, the idea behind a podcast like The Bike Shed, where it's two main hosts and they're coming up with different topics that they want to dive into, and sometimes they have guests but most of the time they don't, versus a show like Giant Robots where you're interviewing guests, what do you think about the content for each of those? Like, how do you kind of separate those in your mind and the direction content-wise?

+ +

MANDY: Marketing and knowing your audience. So, the Giant Robots appeals to startups and entrepreneurs. The Bike Shed is more into the code and into the nitty gritty of software development, so they go into deeper concepts. But Giant Robots is more about talking to the people. It's more of an interview-style show. It's featuring interesting people doing really awesome things and, getting the stories out there and connecting. And that's why I love that thoughtbot has both podcasts. We've just started, what—Giant Robots on Tour—to cater to the EWAA region, which is super exciting.

+ +

VICTORIA: Yeah and, for me, being an interview-style podcast gives me this opportunity to have these deep conversations with really interesting people that you wouldn't necessarily get into in, like, a normal networking event, right?

+ +

MANDY: Right.

+ +

VICTORIA: So, if you can think of a list of 10 interesting people you want to talk to, you should start a podcast.

+ +

[laughter]

+ +

MANDY: And if you can think of those people, a producer like me will also hunt those ten interesting people down for you and see if they'll talk to you because we can do that, too.

+ +

WILL: That is the truth.

+ +

MANDY: I've tracked some pretty cool people down. I'm pretty proud of my skills.

+ +

VICTORIA: We are absolutely thrilled to have you with us here today, Mandy, and to be such a big part of our podcast, and super delighted to have you come out of the background and be on the show with us today and share your voice. Do you have anything else that you'd like to promote?

+ +

MANDY: I'd just like to say that I am taking on clients. I would love to get into a general creative content role to utilize all my many skills that I've scrappily picked up over the years. It's hard to put into a resume. You can check me out at mandymoore.tech.

+ +

WILL: It's not just podcasts, correct? So, if I wanted to try to become an influencer, could you help me with that? Like, what's the different areas that you could help me?

+ +

MANDY: Oh, girl, yes. Let's make you an influencer, Will. Let's go.

+ +

VICTORIA: I could see that for you, Will.

+ +

WILL: I've thought about it, but it's a lot of work. So, that's a big thing, so...[laughs]

+ +

VICTORIA: Wonderful. I think that's really interesting to think about, Mandy. And I hope that people get a lot out of this episode when they're trying...if they're in this process of considering their own marketing plans, and podcast production, and other types of creative strategy, they might have to reach out to you.

+ +

MANDY: Thank you so much for having me.

+ +

WILL: Thank you for being here.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23Larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Victoria Guido chat with Mandy Moore, the mastermind behind thoughtbot's Giant Robots Smashing Into Other Giant Robots and Bike Shed podcasts. Mandy shares some great insights on the technical aspects and the crucial role of editing in creating top-notch content. She stresses the importance of having a producer to handle the behind-the-scenes work, allowing the hosts to focus on delivering captivating content. Mandy also shares her personal journey into podcast editing, highlighting her resourcefulness and how her skills evolved over time.

+ +

Will and Victoria also delved into the strategic advantages of podcasting for businesses, highlighting its effectiveness in helping thoughtbot build a community and establish authority as a company. Mandy discusses how a well-produced podcast can be a potent sales tool and can significantly boost a company's brand presence. They even touch on the future of podcasting, with Mandy pointing out how continuous podcast production can help solidify a company's reputation, even in uncertain times. The episode wraps with some practical advice for anyone interested in starting their own podcasts, emphasizing the need for passion, persistence, and a clear strategy.

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Mandy Moore, our long-time Podcast Editor and Creative Content Marketer. Mandy, thank you for joining us.

+ +

MANDY: Thank you so much.

+ +

VICTORIA: So, I'm excited to dive into the topic of podcast, and creative content, and strategies for companies that are maybe long-time listeners of the Giant Robots podcast who are just curious about why we do this podcast and what it does for us as a company. So, excited to get into that, but before we do, let's start with a fun question to get us warmed up. Mandy, is there anything fun, exciting going on in your world outside of work?

+ +

MANDY: Outside of work, I spend a lot of time at my local dance studio doing a mixture of dance and aerial arts. It gives me something physical to do after my work days. It's an afternoon thing for me. So, I spend about one to two hours there. And it's really helped me overcome a lot of challenges in my life, dealing with a lot of trauma and other aspects of overall personal development and recovery.

+ +

WILL: That's awesome. I normally would never know what you're even talking about, or whatever, but [chuckles] my daughter is into dance. So, every Tuesday, I take her to dance. She begs me to take her, so I take her. So, my daughter is three—about to turn four. And every time we go to dance, she begs us to let her do the aerial dance. Like, I don't ever try to tell her, "Hey, you're too small," or whatever, but we're like, "Let's wait on that one. And then, let's wait until you can do the dance and then get up there." But she is so excited to get on the aerial dance and to do that. So, for you, was it scary when you started doing it, or did you just jump right in? How was it?

+ +

MANDY: I always jump right into everything, but it was hard at first. It looks like it shouldn't be that hard, but it takes a lot of strength. And I was in a much different place eight months ago than I am now. It amazes me the transformation and growth that I've been able to see in myself because, from the very beginning, my instructor encouraged me to video myself. So, I have beautiful videos of progressions. And I can't wait to get a little bit more confident with my own social media and start sharing some of the before and afters because I really want to inspire people. It's done wonders for me and my mental health.

+ +

WILL: A lot of respect to you because I don't know if I could just trust, I don't know what you call it, but that ribbon, that material just to hold you. I don't know if I could do it. So, a lot of respect to you [chuckles].

+ +

MANDY: So, my instructor likes to point out a fun fact, and I'm going to butcher it. I think it can hold whatever a baby elephant weighs. It can hold up to three tons safely.

+ +

WILL: Is it...I'm going to throw this...I'ma tie it in with Victoria. Is it kind of like...because I know with rock climbing, it's all about hand placement, especially if you're belaying. Are the mistakes when you are not paying attention, and you let go of one of the materials, or how does it work?

+ +

MANDY: Mistakes happen when you think about it too much. And that is what I'm always working on is to just stop thinking about it and just doing it because I'm an overthinker, too. And when I start to think about it too much, then I get messed up. But your body knows. Your body adapts. And it learns after the exercise is over. So, in the evenings, after your exercises, that's when your body is, like, doing its internal magic and, like, memorizing your stuff. So, that's why when you go back, it gets easier each time because your muscle memory actually grows when you're on your downtime.

+ +

VICTORIA: Oh yeah. Yeah, I was going to say about climbing...it's funny that you asked that question, Will, about, like, the things that actually hold you because people get that question in climbing, too, about the ropes. Like, are the ropes actually going to hold you? And once you're comfortable with it, you know that it can hold a lot more weight than you [laughs], but it still can be scary. And I've seen people in Joshua Tree doing aerial silks from a line that's been drawn across the tops of two boulders. So, super cool. There's a lot of crossover in the community, I think, between people who do that type of dance and who also enjoy climbing and being outside. So, I love it.

+ +

And so, you make a really good point about how you learn and how information seeps into your brain. And maybe how do you see the world of podcasting and all the things you can learn from podcasting, like, how does that fit into, like, how you learn and how you think about the world?

+ +

MANDY: You know, I've built my entire career on figuring things out, and just building memory, and repeating processes, and figuring out what people want. Because, to me, editing is more than AI can do at this time.

+ +

WILL: Yeah. And I think you're super talented at what you do, so I just want to make sure that I tell you that. Like, you've done a really good job with us. I remember whenever I first had a conversation with Chad, I didn't know to what extent that being a podcast host with this podcast would be. But whenever he said, "We have an editor who will cut some stuff, make you sound good," I was like, "Oh, okay." "Like, essentially, Mandy is doing the hard work for us."

+ +

MANDY: [laughs]

+ +

WILL: And so, I was like, "I'm in. Let's do this." So, it's an art to do this. It's an art. How did you get started? How did you get the ball rolling to get to the point you're at right now?

+ +

MANDY: I was scrappy. I go in time by how old my daughter is, and my daughter is almost 15. So, that's how long I've been doing this. Because I was a single mom and I was a waitress. So, at the time, I had a one-bedroom apartment, and I still had a laptop. And my neighbor didn't have a Wi-Fi password. So, I used my neighbor's Wi-Fi, and I started doing virtual assistant jobs. And I met a developer. He was like, "Can you edit a podcast for me?" And I was like, "Yeah, I can totally do that."

+ +

And I got off the call and started Googling what is a podcast. And this was back in 2010, mind you, so podcasting was new at that point. And so, I just learned it, and I did a decent job. And every podcast that he did, I got better and better. And then, he had friends, and it just kind of turned into, like, Mandy's the go-to for tech podcasting there for a little bit. And I, at one point, got a referral to thoughtbot, and I've been with you ever since. I think it's been going on five or six years now.

+ +

VICTORIA: What's your first piece of advice for someone who's interested in starting their own podcast?

+ +

MANDY: Get a producer. I prefer to be behind the scenes. So, I like to help other people shine. So, like, my goal as a producer is just to have the host show up and be the talent and say the interesting things. So, if you want to have the bandwidth to be able to do that, you know, let somebody else do that work who specializes it because you can really bring your full self to the table and do what you need to do as the host and have fun with it.

+ +

VICTORIA: Yeah. And I think people either correctly estimate that it is a lot of work to edit your own podcast and to create the content, do all the marketing, invite people, plan great content. And it is much easier if you have help [laughs]. And you're probably going to have a better podcast that people want to listen to because it sounds good, and you might not want to skimp on that detail.

+ +

MANDY: Yeah. The other thing I would say when you go to start a podcast is a lot of people are focused on equipment. And that can take you down a long rabbit hole and make you never start to actually record the podcast because you're too worried about all of the details. Get a microphone and go. You don't even need an editor. You can make yourself sound decent through tons of free software. Audacity is one of my favorite platforms to use to edit podcasts. It's been free and open source since I've started.

+ +

WILL: Yeah. I love the advice, what you said, because not everyone...I don't want to do total assumptions, but majority of people fit in two camps. You have the people that want to be out front and chat and can connect with anyone. But you also have the people behind the scenes. So, I'm glad you said that because I think a lot of stuff...when people realize who they really are and what they're good at, it makes them so much better. I can't imagine doing a podcast and trying to edit everything and push it out. I think I'm decent at doing the podcast, and you make us so much better. So, I'm so glad that you said that about kind of just knowing your roles and what's your strengths and everything, so...

+ +

MANDY: Absolutely. I find it relaxing to edit a podcast. Believe it or not, editing a podcast with software is kind of like putting a puzzle together. I was a kid that loved to sit down with puzzles. You know, it is true that once I come to kind of memorize waveforms, like, Will, I know when you're going to say, "Um" a lot of times before I even hear you say, "Um" because I've recognized your speech patterns and same with Victoria. I will be able to pick them out. And it's very interesting. That's a little-known fact from a producer standpoint [chuckles].

+ +

WILL: Well, that's actually really cool because I don't really talk about this much, but I'm originally from Louisiana, and so I have a thick Southern accent. And so, that was actually one of my fears about doing, like, a podcast. So, it's actually interesting that you're saying that you know the ums and, um, which I just did [laughs], but you know how to help us out with that.

+ +

So, yeah, that's actually...I think that was one of the things I have respect for you is that you break down the barriers for people to be better and not be so insecure. Because if you're from Louisiana, there are so many words if you look at it and you try to pronounce it, it's going to mess you up, like Atchafalaya, or Natchitoches, or so many of those words that you're like, you almost have to know the word and pronouncing is going to mess you up.

+ +

MANDY: I call it...and I don't think anybody is a not smart person, but when I edit podcasts, like, the finished product comes out, I liken it to giving the speakers IQ points because the listeners hear the final, polished version. A lot of people start sentences three times over. They only hear the polished version. So, in essence, it's giving the speakers IQ points just to give them a little bit more, you know, of a leg up.

+ +

Nobody wants to really hear somebody bumbling around, but we all do it. We all get nervous. It's human nature to stumble and get nervous and let all those speech patterns out that show us as nervous. But that's what we're for is to clean everybody up. And I love getting to help people have that confidence to go because it's just like, "Don't worry. I got you. Just go out there, have fun, and you're going to sound great."

+ +

VICTORIA: And, in your experience, what kind of reasons for a podcast make the most sense for a business? Like, it's a common piece of advice if you want to build a community to start a podcast, but why is that? Or, like, when does it really make sense for you to start your own podcast?

+ +

MANDY: I mean, you nailed the number one is the community. But, honestly, also, it's a great sales tool, especially if you're a customer with customers, and you're helping people network and expand the network. You're featuring the people. You're expanding the network broader than a community like in a Slack channel, say, or a message board because those are fine, too.

+ +

But putting your company out there and being authority and also giving people access to free content that is helpful to them can really help a business establish that trust in the market and be like, wow, they really take their time to put this out there. One of the things that I constantly still to this day hear people talk about is the thoughtbot Handbook, that was written years and years ago. And it was a beautiful piece of free content, and everybody still talks about it.

+ +

WILL: Yeah, I agree. I think one thing about thoughtbot is the handbook. I still hear people talk about it, and it's referenced often. So, that's actually really good advice. What does success look like for you, like, six months now to five years? Where do you want to go?

+ +

MANDY: I think, for me, I've been in the tech industry for a really long time. I've fallen into the background a little bit too much in that I used to produce a pretty popular podcast called Greater Than Code. And I needed to take a step back from that because, one, it was becoming pretty much a full-time job.

+ +

You know, content is in a really weird place. I've really been trying to pivot into the general content creation space because I do marketing as well, social media, design, and assets. I've designed my own website. I design my own graphics. So, just kind of letting people know that I'm kind of a one-stop, one-shot person. I do it all myself right now, and I have forever. The only thing I outsource is I have a transcriptionist who is a real person, which is a great selling point to a lot of clients of mine because I don't use AI. And I do have a person who goes over it with the human touch who is well-versed in the software developer lingo.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: What kind of trends do you see with podcasting and with the technology used to manage and produce podcasts?

+ +

MANDY: I see podcasting, in general, be a come-and-go trend in this industry. It tends to be, you know, one of the things that businesses are excited to ramp up on. But then it's also one of the things that is the first to go when things get tough or busy or you need to allocate your resources elsewhere. Podcasting seems to be like a trend that I see coming, going with the economy.

+ +

It's actually very weird to bring it to mind now that you mention it because people love podcasts. But when things are unstable, it's almost like they see it as a perk, and it just becomes something that's easily let go. And that's why I think thoughtbot and the podcasts have been so strong is that they have been kept going no matter what in the industry.

+ +

And thoughtbot has really become an authority in not just, you know, it started out as a Ruby podcast. And it very much has grown into a bigger startup, entrepreneurial, consultancy-driven show. And so, it just shows that when you stick in the game, what, we're 520-something episodes in now, that you really do have great things achieved.

+ +

VICTORIA: Yeah. And it sounds like just, you know, having that persistence and just keep going, and if you've found a formula that works for you, you can really benefit from continuing to invest in it. I love that. And let's see, what tips do you give people on how to have more exciting conversations, more engagement?

+ +

MANDY: I love when people just join the call and immediately hit record because some of the best parts of the conversations happen, and you're like, "Oh, wait, we should have been recording that." Start recording and relax and have...The opening conversations that we started this conversation with, it's an icebreaker. It gets into some of your everyday background.

+ +

And as hosts, one of the things that I told Victoria and Will to establish rapport with the audience to kind of start dropping a bit of the narrative. You talk about your story, and then the listeners become invested in you, and that's why they come back, too. It's great content all around, but they also really start to love the hosts too.

+ +

WILL: Yeah, I agree with that because most of the podcasts that I do listen to it's mostly around the host and the way that they treat people. Because if there's a host that's very mean, aggressive, I'm probably not going to listen to them. And, honestly, that's just me, like, I'm not saying don't listen to them. But the hosts do make the podcast a lot of times. And I'm not saying that we make the podcast though, but...

+ +

MANDY: [laughs] You do.

+ +

WILL: [laughs]

+ +

MANDY: It's the chemistry. You guys, I don't know if you know this, but I'm your biggest fan. Like, it's the chemistry. And it's The Bike shed. Fun fact: Joël and Stephanie, like, I told Joël [laughs]...when Joël took over from Steph and Chris, he had different co-hosts each week. And as soon as he had his episode with Stephanie, I said, "Joël, it's Stephanie."

+ +

VICTORIA: Yeah. And it can take a little while to get your dynamic between your co-host going. And other times, it happens right away, and it's very easy and natural. So, I love that for Stephanie and Joël. So, the idea behind a podcast like The Bike Shed, where it's two main hosts and they're coming up with different topics that they want to dive into, and sometimes they have guests but most of the time they don't, versus a show like Giant Robots where you're interviewing guests, what do you think about the content for each of those? Like, how do you kind of separate those in your mind and the direction content-wise?

+ +

MANDY: Marketing and knowing your audience. So, the Giant Robots appeals to startups and entrepreneurs. The Bike Shed is more into the code and into the nitty gritty of software development, so they go into deeper concepts. But Giant Robots is more about talking to the people. It's more of an interview-style show. It's featuring interesting people doing really awesome things and, getting the stories out there and connecting. And that's why I love that thoughtbot has both podcasts. We've just started, what—Giant Robots on Tour—to cater to the EWAA region, which is super exciting.

+ +

VICTORIA: Yeah and, for me, being an interview-style podcast gives me this opportunity to have these deep conversations with really interesting people that you wouldn't necessarily get into in, like, a normal networking event, right?

+ +

MANDY: Right.

+ +

VICTORIA: So, if you can think of a list of 10 interesting people you want to talk to, you should start a podcast.

+ +

[laughter]

+ +

MANDY: And if you can think of those people, a producer like me will also hunt those ten interesting people down for you and see if they'll talk to you because we can do that, too.

+ +

WILL: That is the truth.

+ +

MANDY: I've tracked some pretty cool people down. I'm pretty proud of my skills.

+ +

VICTORIA: We are absolutely thrilled to have you with us here today, Mandy, and to be such a big part of our podcast, and super delighted to have you come out of the background and be on the show with us today and share your voice. Do you have anything else that you'd like to promote?

+ +

MANDY: I'd just like to say that I am taking on clients. I would love to get into a general creative content role to utilize all my many skills that I've scrappily picked up over the years. It's hard to put into a resume. You can check me out at mandymoore.tech.

+ +

WILL: It's not just podcasts, correct? So, if I wanted to try to become an influencer, could you help me with that? Like, what's the different areas that you could help me?

+ +

MANDY: Oh, girl, yes. Let's make you an influencer, Will. Let's go.

+ +

VICTORIA: I could see that for you, Will.

+ +

WILL: I've thought about it, but it's a lot of work. So, that's a big thing, so...[laughs]

+ +

VICTORIA: Wonderful. I think that's really interesting to think about, Mandy. And I hope that people get a lot out of this episode when they're trying...if they're in this process of considering their own marketing plans, and podcast production, and other types of creative strategy, they might have to reach out to you.

+ +

MANDY: Thank you so much for having me.

+ +

WILL: Thank you for being here.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23Larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Check her out at mandymoore.tech. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+2-UBvXG8 + + ]]> + + Will Larry + Victoria Guido + + + 530: Giant Robots On Tour + https://podcast.thoughtbot.com/530 + 39976576-c3cb-458c-8ddd-4a5bee1ce0ca + Thu, 20 Jun 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Will Larry announces a new Giant Robots Smashing Into Other Giant Robots podcast limited series focusing on Europe, West Asia, and Africa, introducing new co-hosts Sami Birnbaum, Svenja Schäfer, Rémy Hannequin, and Jared Turner. The team shares their journeys into the tech industry and engages in an icebreaker game while brainstorming names for the series. They ultimately decide on "Giant Robots On Tour," capturing the spirit of exploration and collaboration. + 25:49 + no + + + Host Will Larry announces an exciting new Giant Robots Smashing Into Other Giant Robots podcast limited series focusing on Europe, West Asia, and Africa and introduces new co-hosts Sami Birnbaum, Svenja Schäfer, Rémy Hannequin, and Jared Turner! Sami sets a fun challenge for the team to devise a name for the new series by the end of the podcast. The co-hosts engage in an icebreaker game where Sami randomly generates questions for each to answer. +The team members talk about their paths into the tech industry. Jared, Rémy, and Will share stories of discovering their passion for tech, overcoming initial struggles, and finding their niche within the field. They discuss the importance of patience, problem-solving, and continuous learning in their careers. Sami emphasizes the value of realistic expectations and the ability to spend time with complex problems to find solutions. +As the first show progresses, the co-hosts have an amazing time brainstorming potential names for the new series, and ultimately, the team decides on "Giant Robots On Tour" to capture the spirit of exploration and collaboration across different regions. We're excited to keep bringing you this new limited EWAA series! Please subscribe and follow along with us! +Follow Sami Birnbaum on LinkedIn (https://www.linkedin.com/in/samibirnbaum/). Visit his website: samibirnbaum.com (https://samibirnbaum.com/). +Follow Svenja Schäfer on LinkedIn (https://www.linkedin.com/in/svenjaschaefer/). Visit her website: svenjaschaefer.com (http://svenjaschaefer.com/) +Follow Rémy Hannequin on LinkedIn (https://www.linkedin.com/in/rhannequin/). Visit his website rhannequ.in (http://rhannequ.in/) +Follow Jared Turner on LinkedIn (https://www.linkedin.com/in/jaredlt/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +And today, we're announcing a new limited series of the podcast focused on the region of Europe, West Asia, and Africa. Please welcome our new co-hosts. Let's start with Sami. Can you introduce yourself? +SAMI: I'm Sami. I'm a developer at thoughtbot based in the UK, in London specifically. And I'm really looking forward to this new Europe, West Asia, and Africa podcast, although we are going to need to come up with a name. We haven't got one yet because we're busy people, and we're consultants the rest of the time. But the plan is to get one. +I don't think there's any quicker way to do it than just for ourselves to come up with one. And so, I think we should do a bit of a challenge here. I think we could say that by the end of this podcast, we'll have a name. I don't know what that's going to be. I don't know what that's going to look like. But we'll go around at the end of the podcast, and we'll see if one of us during this podcast can pick a name for this new series. I'm going to pass on to Svenja. Hey, Svenja. +SVENJA: Hi, Sami. Thank you so much. My name is Svenja. I'm a developer and development team lead at thoughtbot. I live in Spain, more precisely in Almería. It's part of Andalusia. It's all the way in the South of Spain. I'm very excited to be in this podcast. And about the name, I'm also very excited about that. No clue yet. That's it for now from my side. Rémy, do you want to go next? +RÉMY: Thank you, Svenja. I'm Rémy. I'm a software developer at thoughtbot. I joined a little bit more than one year ago. And I'm working from Paris, France. And I'm very excited to join this series. Jared, do you want to go next? +JARED: Yeah. Thanks, Rémy. Hi, my name's Jared. I'm a product manager at thoughtbot. I am originally from Australia, but I live in London. And you're currently hearing me from Scotland. I'm very excited to hear what we're going to discuss over the course of this limited series and to hear what name Sami is about to come up with on this very podcast. Sami, back to you. +SAMI: Yeah. Thanks, Jared. It's great to be doing this with all of you. And formal intros are great, right? So, now everyone kind of knows our position at thoughtbot and where we live. But I was thinking possibly to spice some things up...I've never done a game like this before, so I have no idea where this is going to go. +It's kind of an icebreaker game where I use a random icebreaker generator online. They're not my questions. They're generated by someone else, which makes it even more risky. I'll kind of go to each of you individually with an icebreaker question that I've generated, and you're going to have to answer the question. +You have no idea what's coming. I have no idea what's coming. But it's a great way of other people getting to know kind of more about us in a more informal way, in a way which we might not think about sharing things. I will do you a favor, though; I'll give everyone two skips, okay? So, I'll hit you with a question, and then, if you don't like the question, you can skip the question. But you've only got two skips, so I would say use them wisely. Because if you skip and you get a worse question, you're not going back to the previous one. +Oh, okay, this is interesting. I'm going to start the way we intro'd, just to make it fair. Svenja. +SVENJA: I'm scared. I'm scared [laughs]. +SAMI: You should be scared. The best thing about this game is the one who's hosting doesn't get asked the questions. So, Svenja, this is your question. What is a lesson you feel you learned too late in life? +SVENJA: Online banking [laughs]. I don't use online banking for that long. I don't know. I was the last person, I think, who always ran around with cash because I also didn't use credit cards also, so maybe trust in online banking. I'm not sure [laughs] that's a lesson. Sometimes, I probably shouldn't trust in it, but yeah, it would have made my life a little bit easier. Does that count? +SAMI: It definitely counts. I mean, what could be more valuable information to know about Svenja? +SVENJA: [laughs] +SAMI: That she doesn't like online banking. And that's exactly the type of valuable content you will get from the Europe, West Asia, and Africa podcast series, which I hope, in the background, we are all thinking of a name because we cannot just say Europe, West Asia, and Africa series the whole time. +WILL: I have a question, a follow-up. So, how did you do banking? Did you go in every single time, deposit, and withdraw inside the bank? +SVENJA: Yes, actually, well, I did. It was good and kind of not so good because I always needed to go back home because I had one office I was kind of allowed to go to because all the others they didn't know me. And so, I went there; then I did my transfer there. I like to speak to real people [laughs], which is interesting because I always worked remotely, at least the last ten years, I think. But real-life interaction is kind of important to me. +WILL: Yeah, that's neat to know. Okay. Awesome. Awesome. +SAMI: That's cool. Okay, Rémy, I have not hit the generator button yet, so I don't know what's coming. Let's hit it now. Okay, this is interesting. What's something you do to relieve anger or stress? +RÉMY: I have a lot of different activities. I kind of find it hard not to do anything. I don't know if it's a quality or not, but I know I'm always busy. So, if I'm stressed, I just go to the next occupation, you know. So, I like to do bread at home. I like sourdough bread. It smells amazing. It's not that easy, but you're working with living organisms. It's kind of nice. I read a lot of astronomy magazines because I'm deeply in love with astronomy. Sometimes it works, sometimes it doesn't, but I love to play with my daughter. When you're stressed, sometimes it increases the stress depending, but it's always quite fun. +SAMI: That's great. Playing with the kids definitely resonates with me. I've got four of my own, so they keep me busy. Is the sourdough bread is that the one where you have that...I'm going to show how naive I am—my lack of knowledge. You have, like, that starter thing that kind of lives with you. +RÉMY: Yeah, exactly, the sourdough starter. That's actually the most fun part for me so far because you have to start from scratch. I mean, you can start with another starter. But it's quite interesting to just start with water and flour, and then you create something living, and it's a mutual benefit. You feed it, and then it feeds you a little bit later when you bake it in 200 degrees in your oven. It's interesting. +WILL: You said it's a living organism. So, you said that you started with water and flour. So, what introduces the living organism into the sourdough bread? +RÉMY: I lack a bit of the English vocabulary for that. I think it's called yeast. The living yeast on the flour, especially if it's organic, it's just out there, you know, even in the air. And when you just feed it with warm water and, like, a cozy environment, it starts eating the flour, and it develops, and it changes some of the texture and the taste into a lot of things. And then, it's quite powerful for making the bread rise and making a very nice taste and the crust and everything. But I think if I'm correct, Svenja might know a lot more about [inaudible 07:51] bread than me. +SVENJA: I don't. I think the reason you said is because I'm German [laughs]. We love bread, and I absolutely love bread, but I don't have the patience to feed something. I don't have kids. I do have dogs. I do feed them, but they also get sometimes a bit of bread. I was never able to do my own sour bread, unfortunately, because I really love it. And I don't get it around here, which is really sad. So, I will look into that. +SAMI: That's cool. That brings us to Jared. Jared has been waiting patiently for his question. +JARED: Hit me with it, Sami. +SAMI: Let's do it. Oh, okay. If you could kick one person out of this podcast...no, I'm kidding. I'm kidding. I'm kidding. I'm kidding. That's not, I mean, no, that was just...that's my own. Okay, let me actually do one. What's one characteristic you admire in others, and why? +JARED: Oh, interesting. I think I always appreciate when someone else takes the time to understand someone else's point of view. If that goes a bit meta, like, we live in our own heads so much that it's really nice when someone reflects on how someone else thinks or their point of view. So, that's my one characteristic. +SAMI: That's really interesting. And how have you found, I guess, in the world of consultancy, and when you're working with products, how have you found that's kind of helped you when it comes to the product ownership side of things? +JARED: Well, it's a constant reminder to do it myself; that's for one thing, especially dealing with a lot of different clients and a lot of different people. It's always really important to think about their perspective, their own customers' perspective. +SAMI: That's cool. I'll hand back to Will, but, Will, I'm not just going to hand it back to you for free, right? You're also going to have to do an icebreaker. +WILL: Let's do it. +SAMI: Will, would you rather receive a shout-out from the CEO at a company all-hands meeting or a private word of thanks from them? +WILL: Ooh, I'm usually a private person, so probably private. But I have learned in my leadership, and I've learned this, this is a lesson I've learned: it's like, praise publicly, but then, like, reprimand privately. And so, I think majority of the people like that. But I'm just a private individual person. So, I'm like, just tell me, and I'm okay with that. I don't need everyone else to tell me and to say, "Hey, Will, you did a good job." Because yeah, it just brings pressure and all of that to me. So, I'm more of a private individual. Because also, I can ask more questions then. I can get more detail around like, "Yo, what did you like? Why are you saying a thank you and a shout-out?" So, that's where I'm at. +SAMI: Okay, I'll hand back to Svenja. +SVENJA: Yeah, I think we should give it back to you as well. So, because I am able to open a website, so that's another lesson I learned: how to type it in. +SAMI: [chuckles] +SVENJA: And I do find a question for you. Since nobody skipped, we will remove that option for you, Sami. So, you only get one question and that is, what is one thing we would never guess about you? +SAMI: Oh, I love that. Should I say how much I hate podcasting? +SVENJA: [laughs] +SAMI: No, I'm kidding. I haven't done it enough yet to know if I hate it. Ooh, one thing. That kind of means I've got to reveal something, right? Because you would never guess this thing, and you would never know this thing. So, I am 32 years old, and my intention was never to be a developer, ever. +So, I actually wanted to be a psychotherapist, a cognitive behavioral therapist, to be precise. And I started on a master's course. I did it for six weeks, and then I realized I couldn't handle it. I had placements in a hospital, and the cases that we were dealing with it was too much for me. It was too overwhelming, and I didn't have the skills to kind of handle that as well as my own personal world. +So, at the age of about...I've got to remember what age it was. I think it was about 25 years old, 24, 25 years old. I already had one kid, and I was married with one child. And what am I going to do? My whole plan to be a psychotherapist that I'd done my undergraduate degree to go towards, and now I was on this master's just kind of fell apart. +So, it's like, what's the easiest thing I can do? And that was to learn to code, right [chuckles]? Well, I'd always been good at computers. I'd always been fixing things. I was always the one at home who'd been asked, you know, "There's a problem with this computer." Normally, it was the printer, and I hate printers, but that's for a totally other episode. I could do a whole episode on printers. My one next to me is currently plugged in. I don't use Wi-Fi—Bluetooth with it because it's just not worth it. +But either way, so I wrote my first line of code when I was 25. That was the first time I ever saw code, wrote HTML, and knew what it was. So, I never wanted to be a developer. Here I am all those years later, but it was never a plan, and I've found myself here. But I'm quite happy for it. +SVENJA: That is so interesting and definitely something I wouldn't have guessed. +SAMI: Yeah, it's been one hell of a journey, shall we say, but an exciting one. +SVENJA: I would be super interested how the others of you stepped into the world of tech, so to say. +JARED: Similar sort of thing to Sami in that I've always been interested, always been the sort of more technical, geekier person of the school and the social groups. And then, at uni, I actually took some computer science classes, and then quickly felt very confused and ended up doing a bachelor of commerce in marketing and management instead, which was a lot more straightforward basic business degree, sort of tick some things off. But still, like, throughout all that time, always just loved tech, loved reading about it, loved dabbling. +And I landed a job at a previous company that I just got a lot of freedom to help out where I needed, problem-solve, do lots of different things. It was quite a small business. I was able to level up a whole bunch of different skills, like some technical and some sort of more managerial as well. That's sort of how I got a lot of my knowledge and then moved on from there. How about you, Rémy? +RÉMY: I started in tech right away after high school. So, I had studied...I think we still call it multimedia. It was communication, coding, design, sound, video. I learned how to make step motions, you know, a lot of different things. It was kind of doing everything and trying to find the one thing that you actually like, and I found mine, which was actually coding. +I think I found what I liked when I was in school. I remember struggling on math homework. I don't have a very high background in math, but I used to enjoy it. I remember struggling on some homework, and the sensation when you finally find the answer, and you finally resolve the problem it was amazing. And I felt that again in coding. Like, you have a bug, or you have a feature, and you can't make it. And you try again, and you find some clues, but it doesn't work. And at some point, it works, and you finally made it. And it's an amazing sensation. I had it again, like yesterday. It's quite common. I love that so much. So, I think that's how I decided, okay, that's what I want to do every day. +SVENJA: Thank you so much, Rémy and Jared. What about you, Will? +WILL: Yeah, I think I've told this story before on the podcast, but I always love telling it again. I actually lost my job, and I was really struggling. And if you know me, fashion is not my thing at all, and I was working at this fashion store. It was this clothing store. I hated it. I hated it. Like, there's no shortage on that. I hated it [laughs]. I was working there, and then I also started working at this insurance place. We sold travelers insurance. So, it was very interesting to see how that works. And yeah, I'm not going to say too much about it, but yes, how that works [laughs]. +But at that company, the one good thing about it was they were like, as long as you get your work done, you could do whatever you want. And so, one day, I was at home, and my partner was like, "You're struggling. You're just trying to figure out what you're trying to do, and you're struggling." So, she kind of walked me through, like, "What do you want to do?" And I was...when Sami mentioned the printer, I laughed because I was that person also. And printers are tricky because you never know what the real issue is. You just got to tinker with it and hope it works. And yes, you never get the same answer twice, I feel sometimes [laughs]. +SAMI: I feel like all our listeners who are kind of really good at fixing printers are thinking like, oh my gosh, I'm going to work at thoughtbot now. I'm going to be an amazing developer one day. +WILL: You could. Why not [laughs]? And it's interesting you say that because, like, I was 29 or 30 whenever I started in the field. So, I was a little bit late, I feel sometimes, to get into development. But my wife, she asked me, "You're struggling. You need to do something because this is not going to work. We got to change it up." And I was like, well, I grew up in a small town in Louisiana, in the south of United States, and we didn't have anything tech there. It was just a rural place. And so I never had the opportunity to learn anything about computers. I guess the printer and stuff just came naturally to me, and this was before YouTube and all of that. +So, she challenged me. She said, "Go and learn it. Go figure it out. Go learn it." I did. And I forgot who mentioned; somebody mentioned something about being easy getting into development. It was not for me. I remember so many times at the coffee shop just, like, I don't know what I am doing. And if you know anything about me, I sometimes don't have the patience to slow down. And so, I came in, and I wanted to be a senior developer and produce like a senior developer. And I was sadly mistaken that that's not how it work. But five years now, I am a senior developer, so I've enjoyed it. I would not change it for anything, and I love it. So, it's been a good change for me, so I love tech. +SAMI: I think it's so helpful to kind of hear realistic expectations about how long it does take. It really is a skill. Some people often ask me, "What is one characteristic that kind of indicates success in the field?" And there isn't just one. But I definitely think that the ability to sit and spend time is so helpful. Because if you can spend time with something and just sit there and, like, be patient, like you were saying, often, you will get to a solution, and it will happen. +But it's about almost slowing yourself down and slowing your mind and your brain down. And we kind of call it in industry, you know, the concept of having a rubber duck, which is also a form of I'm stuck on something. I just need to speak this out, not necessarily with someone who can respond, but in a way that allows me to verbalize slowly what's going on. And you'll be surprised how often you reach a solution. So, that's really interesting. +So, yeah, we've got this great series coming. We have some great guests lined up. The advantage of doing this series over in Europe, West Asia, and Africa is we're going to get access to some guests within our time zones, within our region that this podcast has not been able to get access to before. And so, we are really excited about the people that we're going to bring on, and you're going to get to hear some of the most incredible podcasts that you've heard. +But we don't have a name. We still don't have a name. And I kind of set the challenge at the beginning of this podcast of, well, let's just come up with one. So, who wants to give a shout-out and think about, you know, what this name is going to be? Just to clarify, it's still going to be called the Giant Robots Smashing Into Other Giant Robots podcast, but where you see that kind of title of the individual episode, it will probably have a prefix of kind of the series name just so you know it's from us. Victoria, I feel like you're hiding away somewhere in the background, and I feel like you've got some suggestions up your sleeve. +VICTORIA: Yeah, so I love the name of the podcast. I like when I network, and I usually say that, "I'm, like, the co-host of the Giant Robots Smashing Into Other Giant Robots." So, I want to keep the name to be fun. And maybe it's giant robots in a different action like Giant Robots High-Fiving Other Giant Robots or Giant Robots Without Borders, or something like that. That's what I'm thinking. +SVENJA: I really like the Giant Robots Without Borders. I really like it. +JARED: Sami, you had a good one that I quite liked as well in the spirit of what we've been talking about: Giant Robots On Tour. +SAMI: Oh yeah, Giant Robots On Tour. That makes it sound, to me, like we're just going out and having a really fun time, not like we might not be doing sensible things, but we're going on tour. But that kind of also indicates, you know, what happens on tour stays on tour. And we probably need to be conscious that other people will listen to this. So, we have to maybe, like, tone it down if we are the giant robots who are on tour. But yeah, I like Giant Robots On Tour. This is cool. We're actually going to name our series. +VICTORIA: I do think it would be funny if it was, like, less...I don't want to say less violent, like, Giant Robots Smashing Into Other Giant Robots, like, Giant Robots Knitting Socks or something, like [laughs], fun, nice, but maybe not as exciting. +SVENJA: Baking Bread Together [laughs]. +VICTORIA: Giant Robots Baking Bread actually sounds pretty cool. +WILL: Giant Robots On Tour because it reminded me since we're talking about the different region, the great English rock band, the Beatles. That's what it reminded me of. So, shout out to the UK. +SAMI: Yeah. I actually often drive past...do you know where the Abbey Road studios were? And there's that famous picture of the Beatles on the album cover of where...I don't know which album it is. They're crossing that zebra crossing across the road. There's that picture of all of them. And what you get now is you get loads of tourists. And so, you're trying to drive your car, and they're just hanging out on the zebra crossing, trying to replicate that picture that they had on the album cover. If you're not familiar with what I'm talking about, just Google "Beatles zebra crossing album cover," and you'll get an idea of kind of what I have to face when I'm just trying to drive from A to B sometimes. +VICTORIA: Well, that's also part of, you know, bringing up why we were wanting to have some hosts in the Europe, West Asia, and Africa region, is there's a lot of context and things like calling it a zebra crossing. We call it a crosswalk. And just having more context and connection with our guests who are from that area would be really great. +I don't know if you all saw the pictures, but for the last RubyConf that was in San Diego, I actually made robot costumes out of cardboard boxes. And there's absolutely a picture of me in a giant robot costume sitting on a lounge chair outside in the sun. So, it might be perfect for your series. +SAMI: I think that's a great way to name things, right? Like, if you have a picture that works for a thing, then you have to kind of go with a name like that. Do we vote? How do we come up with it? Is this a democracy? Probably not. +JARED: Well, I think one thing we haven't clarified is that Sami, you're our primary co-host for the European adventure. So, maybe you should get the decider. Should you dictate to us? +SAMI: I feel like it's almost worth it kind of being the primary host just so I get to pick the name. So yeah, sure, I'm going to decide, so it's Sami's Giant Robots is going to be the name of this series. No, I'm kidding. Let's go with...okay, I'm stuck between without borders and on tour. I'm really stuck between those two. So, no one else can see this. I'm going to say, like, hands up if you want without borders. Hands up if you want on tour. Okay. Okay. Okay. +We're going to be calling our new series, with the most exciting guests that you've ever seen, Giant Robots On Tour. You've heard it here first. It's been announced. +WILL: Thank you for joining us. I look forward to the Giant Robots On Tour. I am excited about it. I love that we have the diversity at thoughtbot to be able to have this limited series. So, I'm excited to see what comes out of it. So, I can't wait to check it out. I'll be one of the first listeners on every podcast that comes out. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. +You can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + Podcast, Giant Robots Smashing Into Other Giant Robots, Europe, West Asia, Africa, new series, co-hosts, Sami, Svenja, Rémy, Jared, tech industry, developer stories, career journey, icebreaker game, online banking, sourdough bread, astronomy, product management, career shift, tech careers, name brainstorming, Giant Robots On Tour, thoughtbot, limited series, global focus, digital transformation, technology podcast, developer insights + + Host Will Larry announces an exciting new Giant Robots Smashing Into Other Giant Robots podcast limited series focusing on Europe, West Asia, and Africa and introduces new co-hosts Sami Birnbaum, Svenja Schäfer, Rémy Hannequin, and Jared Turner! Sami sets a fun challenge for the team to devise a name for the new series by the end of the podcast. The co-hosts engage in an icebreaker game where Sami randomly generates questions for each to answer.

+ +

The team members talk about their paths into the tech industry. Jared, Rémy, and Will share stories of discovering their passion for tech, overcoming initial struggles, and finding their niche within the field. They discuss the importance of patience, problem-solving, and continuous learning in their careers. Sami emphasizes the value of realistic expectations and the ability to spend time with complex problems to find solutions.

+ +

As the first show progresses, the co-hosts have an amazing time brainstorming potential names for the new series, and ultimately, the team decides on "Giant Robots On Tour" to capture the spirit of exploration and collaboration across different regions. We're excited to keep bringing you this new limited EWAA series! Please subscribe and follow along with us!

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

And today, we're announcing a new limited series of the podcast focused on the region of Europe, West Asia, and Africa. Please welcome our new co-hosts. Let's start with Sami. Can you introduce yourself?

+ +

SAMI: I'm Sami. I'm a developer at thoughtbot based in the UK, in London specifically. And I'm really looking forward to this new Europe, West Asia, and Africa podcast, although we are going to need to come up with a name. We haven't got one yet because we're busy people, and we're consultants the rest of the time. But the plan is to get one.

+ +

I don't think there's any quicker way to do it than just for ourselves to come up with one. And so, I think we should do a bit of a challenge here. I think we could say that by the end of this podcast, we'll have a name. I don't know what that's going to be. I don't know what that's going to look like. But we'll go around at the end of the podcast, and we'll see if one of us during this podcast can pick a name for this new series. I'm going to pass on to Svenja. Hey, Svenja.

+ +

SVENJA: Hi, Sami. Thank you so much. My name is Svenja. I'm a developer and development team lead at thoughtbot. I live in Spain, more precisely in Almería. It's part of Andalusia. It's all the way in the South of Spain. I'm very excited to be in this podcast. And about the name, I'm also very excited about that. No clue yet. That's it for now from my side. Rémy, do you want to go next?

+ +

RÉMY: Thank you, Svenja. I'm Rémy. I'm a software developer at thoughtbot. I joined a little bit more than one year ago. And I'm working from Paris, France. And I'm very excited to join this series. Jared, do you want to go next?

+ +

JARED: Yeah. Thanks, Rémy. Hi, my name's Jared. I'm a product manager at thoughtbot. I am originally from Australia, but I live in London. And you're currently hearing me from Scotland. I'm very excited to hear what we're going to discuss over the course of this limited series and to hear what name Sami is about to come up with on this very podcast. Sami, back to you.

+ +

SAMI: Yeah. Thanks, Jared. It's great to be doing this with all of you. And formal intros are great, right? So, now everyone kind of knows our position at thoughtbot and where we live. But I was thinking possibly to spice some things up...I've never done a game like this before, so I have no idea where this is going to go.

+ +

It's kind of an icebreaker game where I use a random icebreaker generator online. They're not my questions. They're generated by someone else, which makes it even more risky. I'll kind of go to each of you individually with an icebreaker question that I've generated, and you're going to have to answer the question.

+ +

You have no idea what's coming. I have no idea what's coming. But it's a great way of other people getting to know kind of more about us in a more informal way, in a way which we might not think about sharing things. I will do you a favor, though; I'll give everyone two skips, okay? So, I'll hit you with a question, and then, if you don't like the question, you can skip the question. But you've only got two skips, so I would say use them wisely. Because if you skip and you get a worse question, you're not going back to the previous one.

+ +

Oh, okay, this is interesting. I'm going to start the way we intro'd, just to make it fair. Svenja.

+ +

SVENJA: I'm scared. I'm scared [laughs].

+ +

SAMI: You should be scared. The best thing about this game is the one who's hosting doesn't get asked the questions. So, Svenja, this is your question. What is a lesson you feel you learned too late in life?

+ +

SVENJA: Online banking [laughs]. I don't use online banking for that long. I don't know. I was the last person, I think, who always ran around with cash because I also didn't use credit cards also, so maybe trust in online banking. I'm not sure [laughs] that's a lesson. Sometimes, I probably shouldn't trust in it, but yeah, it would have made my life a little bit easier. Does that count?

+ +

SAMI: It definitely counts. I mean, what could be more valuable information to know about Svenja?

+ +

SVENJA: [laughs]

+ +

SAMI: That she doesn't like online banking. And that's exactly the type of valuable content you will get from the Europe, West Asia, and Africa podcast series, which I hope, in the background, we are all thinking of a name because we cannot just say Europe, West Asia, and Africa series the whole time.

+ +

WILL: I have a question, a follow-up. So, how did you do banking? Did you go in every single time, deposit, and withdraw inside the bank?

+ +

SVENJA: Yes, actually, well, I did. It was good and kind of not so good because I always needed to go back home because I had one office I was kind of allowed to go to because all the others they didn't know me. And so, I went there; then I did my transfer there. I like to speak to real people [laughs], which is interesting because I always worked remotely, at least the last ten years, I think. But real-life interaction is kind of important to me.

+ +

WILL: Yeah, that's neat to know. Okay. Awesome. Awesome.

+ +

SAMI: That's cool. Okay, Rémy, I have not hit the generator button yet, so I don't know what's coming. Let's hit it now. Okay, this is interesting. What's something you do to relieve anger or stress?

+ +

RÉMY: I have a lot of different activities. I kind of find it hard not to do anything. I don't know if it's a quality or not, but I know I'm always busy. So, if I'm stressed, I just go to the next occupation, you know. So, I like to do bread at home. I like sourdough bread. It smells amazing. It's not that easy, but you're working with living organisms. It's kind of nice. I read a lot of astronomy magazines because I'm deeply in love with astronomy. Sometimes it works, sometimes it doesn't, but I love to play with my daughter. When you're stressed, sometimes it increases the stress depending, but it's always quite fun.

+ +

SAMI: That's great. Playing with the kids definitely resonates with me. I've got four of my own, so they keep me busy. Is the sourdough bread is that the one where you have that...I'm going to show how naive I am—my lack of knowledge. You have, like, that starter thing that kind of lives with you.

+ +

RÉMY: Yeah, exactly, the sourdough starter. That's actually the most fun part for me so far because you have to start from scratch. I mean, you can start with another starter. But it's quite interesting to just start with water and flour, and then you create something living, and it's a mutual benefit. You feed it, and then it feeds you a little bit later when you bake it in 200 degrees in your oven. It's interesting.

+ +

WILL: You said it's a living organism. So, you said that you started with water and flour. So, what introduces the living organism into the sourdough bread?

+ +

RÉMY: I lack a bit of the English vocabulary for that. I think it's called yeast. The living yeast on the flour, especially if it's organic, it's just out there, you know, even in the air. And when you just feed it with warm water and, like, a cozy environment, it starts eating the flour, and it develops, and it changes some of the texture and the taste into a lot of things. And then, it's quite powerful for making the bread rise and making a very nice taste and the crust and everything. But I think if I'm correct, Svenja might know a lot more about [inaudible 07:51] bread than me.

+ +

SVENJA: I don't. I think the reason you said is because I'm German [laughs]. We love bread, and I absolutely love bread, but I don't have the patience to feed something. I don't have kids. I do have dogs. I do feed them, but they also get sometimes a bit of bread. I was never able to do my own sour bread, unfortunately, because I really love it. And I don't get it around here, which is really sad. So, I will look into that.

+ +

SAMI: That's cool. That brings us to Jared. Jared has been waiting patiently for his question.

+ +

JARED: Hit me with it, Sami.

+ +

SAMI: Let's do it. Oh, okay. If you could kick one person out of this podcast...no, I'm kidding. I'm kidding. I'm kidding. I'm kidding. That's not, I mean, no, that was just...that's my own. Okay, let me actually do one. What's one characteristic you admire in others, and why?

+ +

JARED: Oh, interesting. I think I always appreciate when someone else takes the time to understand someone else's point of view. If that goes a bit meta, like, we live in our own heads so much that it's really nice when someone reflects on how someone else thinks or their point of view. So, that's my one characteristic.

+ +

SAMI: That's really interesting. And how have you found, I guess, in the world of consultancy, and when you're working with products, how have you found that's kind of helped you when it comes to the product ownership side of things?

+ +

JARED: Well, it's a constant reminder to do it myself; that's for one thing, especially dealing with a lot of different clients and a lot of different people. It's always really important to think about their perspective, their own customers' perspective.

+ +

SAMI: That's cool. I'll hand back to Will, but, Will, I'm not just going to hand it back to you for free, right? You're also going to have to do an icebreaker.

+ +

WILL: Let's do it.

+ +

SAMI: Will, would you rather receive a shout-out from the CEO at a company all-hands meeting or a private word of thanks from them?

+ +

WILL: Ooh, I'm usually a private person, so probably private. But I have learned in my leadership, and I've learned this, this is a lesson I've learned: it's like, praise publicly, but then, like, reprimand privately. And so, I think majority of the people like that. But I'm just a private individual person. So, I'm like, just tell me, and I'm okay with that. I don't need everyone else to tell me and to say, "Hey, Will, you did a good job." Because yeah, it just brings pressure and all of that to me. So, I'm more of a private individual. Because also, I can ask more questions then. I can get more detail around like, "Yo, what did you like? Why are you saying a thank you and a shout-out?" So, that's where I'm at.

+ +

SAMI: Okay, I'll hand back to Svenja.

+ +

SVENJA: Yeah, I think we should give it back to you as well. So, because I am able to open a website, so that's another lesson I learned: how to type it in.

+ +

SAMI: [chuckles]

+ +

SVENJA: And I do find a question for you. Since nobody skipped, we will remove that option for you, Sami. So, you only get one question and that is, what is one thing we would never guess about you?

+ +

SAMI: Oh, I love that. Should I say how much I hate podcasting?

+ +

SVENJA: [laughs]

+ +

SAMI: No, I'm kidding. I haven't done it enough yet to know if I hate it. Ooh, one thing. That kind of means I've got to reveal something, right? Because you would never guess this thing, and you would never know this thing. So, I am 32 years old, and my intention was never to be a developer, ever.

+ +

So, I actually wanted to be a psychotherapist, a cognitive behavioral therapist, to be precise. And I started on a master's course. I did it for six weeks, and then I realized I couldn't handle it. I had placements in a hospital, and the cases that we were dealing with it was too much for me. It was too overwhelming, and I didn't have the skills to kind of handle that as well as my own personal world.

+ +

So, at the age of about...I've got to remember what age it was. I think it was about 25 years old, 24, 25 years old. I already had one kid, and I was married with one child. And what am I going to do? My whole plan to be a psychotherapist that I'd done my undergraduate degree to go towards, and now I was on this master's just kind of fell apart.

+ +

So, it's like, what's the easiest thing I can do? And that was to learn to code, right [chuckles]? Well, I'd always been good at computers. I'd always been fixing things. I was always the one at home who'd been asked, you know, "There's a problem with this computer." Normally, it was the printer, and I hate printers, but that's for a totally other episode. I could do a whole episode on printers. My one next to me is currently plugged in. I don't use Wi-Fi—Bluetooth with it because it's just not worth it.

+ +

But either way, so I wrote my first line of code when I was 25. That was the first time I ever saw code, wrote HTML, and knew what it was. So, I never wanted to be a developer. Here I am all those years later, but it was never a plan, and I've found myself here. But I'm quite happy for it.

+ +

SVENJA: That is so interesting and definitely something I wouldn't have guessed.

+ +

SAMI: Yeah, it's been one hell of a journey, shall we say, but an exciting one.

+ +

SVENJA: I would be super interested how the others of you stepped into the world of tech, so to say.

+ +

JARED: Similar sort of thing to Sami in that I've always been interested, always been the sort of more technical, geekier person of the school and the social groups. And then, at uni, I actually took some computer science classes, and then quickly felt very confused and ended up doing a bachelor of commerce in marketing and management instead, which was a lot more straightforward basic business degree, sort of tick some things off. But still, like, throughout all that time, always just loved tech, loved reading about it, loved dabbling.

+ +

And I landed a job at a previous company that I just got a lot of freedom to help out where I needed, problem-solve, do lots of different things. It was quite a small business. I was able to level up a whole bunch of different skills, like some technical and some sort of more managerial as well. That's sort of how I got a lot of my knowledge and then moved on from there. How about you, Rémy?

+ +

RÉMY: I started in tech right away after high school. So, I had studied...I think we still call it multimedia. It was communication, coding, design, sound, video. I learned how to make step motions, you know, a lot of different things. It was kind of doing everything and trying to find the one thing that you actually like, and I found mine, which was actually coding.

+ +

I think I found what I liked when I was in school. I remember struggling on math homework. I don't have a very high background in math, but I used to enjoy it. I remember struggling on some homework, and the sensation when you finally find the answer, and you finally resolve the problem it was amazing. And I felt that again in coding. Like, you have a bug, or you have a feature, and you can't make it. And you try again, and you find some clues, but it doesn't work. And at some point, it works, and you finally made it. And it's an amazing sensation. I had it again, like yesterday. It's quite common. I love that so much. So, I think that's how I decided, okay, that's what I want to do every day.

+ +

SVENJA: Thank you so much, Rémy and Jared. What about you, Will?

+ +

WILL: Yeah, I think I've told this story before on the podcast, but I always love telling it again. I actually lost my job, and I was really struggling. And if you know me, fashion is not my thing at all, and I was working at this fashion store. It was this clothing store. I hated it. I hated it. Like, there's no shortage on that. I hated it [laughs]. I was working there, and then I also started working at this insurance place. We sold travelers insurance. So, it was very interesting to see how that works. And yeah, I'm not going to say too much about it, but yes, how that works [laughs].

+ +

But at that company, the one good thing about it was they were like, as long as you get your work done, you could do whatever you want. And so, one day, I was at home, and my partner was like, "You're struggling. You're just trying to figure out what you're trying to do, and you're struggling." So, she kind of walked me through, like, "What do you want to do?" And I was...when Sami mentioned the printer, I laughed because I was that person also. And printers are tricky because you never know what the real issue is. You just got to tinker with it and hope it works. And yes, you never get the same answer twice, I feel sometimes [laughs].

+ +

SAMI: I feel like all our listeners who are kind of really good at fixing printers are thinking like, oh my gosh, I'm going to work at thoughtbot now. I'm going to be an amazing developer one day.

+ +

WILL: You could. Why not [laughs]? And it's interesting you say that because, like, I was 29 or 30 whenever I started in the field. So, I was a little bit late, I feel sometimes, to get into development. But my wife, she asked me, "You're struggling. You need to do something because this is not going to work. We got to change it up." And I was like, well, I grew up in a small town in Louisiana, in the south of United States, and we didn't have anything tech there. It was just a rural place. And so I never had the opportunity to learn anything about computers. I guess the printer and stuff just came naturally to me, and this was before YouTube and all of that.

+ +

So, she challenged me. She said, "Go and learn it. Go figure it out. Go learn it." I did. And I forgot who mentioned; somebody mentioned something about being easy getting into development. It was not for me. I remember so many times at the coffee shop just, like, I don't know what I am doing. And if you know anything about me, I sometimes don't have the patience to slow down. And so, I came in, and I wanted to be a senior developer and produce like a senior developer. And I was sadly mistaken that that's not how it work. But five years now, I am a senior developer, so I've enjoyed it. I would not change it for anything, and I love it. So, it's been a good change for me, so I love tech.

+ +

SAMI: I think it's so helpful to kind of hear realistic expectations about how long it does take. It really is a skill. Some people often ask me, "What is one characteristic that kind of indicates success in the field?" And there isn't just one. But I definitely think that the ability to sit and spend time is so helpful. Because if you can spend time with something and just sit there and, like, be patient, like you were saying, often, you will get to a solution, and it will happen.

+ +

But it's about almost slowing yourself down and slowing your mind and your brain down. And we kind of call it in industry, you know, the concept of having a rubber duck, which is also a form of I'm stuck on something. I just need to speak this out, not necessarily with someone who can respond, but in a way that allows me to verbalize slowly what's going on. And you'll be surprised how often you reach a solution. So, that's really interesting.

+ +

So, yeah, we've got this great series coming. We have some great guests lined up. The advantage of doing this series over in Europe, West Asia, and Africa is we're going to get access to some guests within our time zones, within our region that this podcast has not been able to get access to before. And so, we are really excited about the people that we're going to bring on, and you're going to get to hear some of the most incredible podcasts that you've heard.

+ +

But we don't have a name. We still don't have a name. And I kind of set the challenge at the beginning of this podcast of, well, let's just come up with one. So, who wants to give a shout-out and think about, you know, what this name is going to be? Just to clarify, it's still going to be called the Giant Robots Smashing Into Other Giant Robots podcast, but where you see that kind of title of the individual episode, it will probably have a prefix of kind of the series name just so you know it's from us. Victoria, I feel like you're hiding away somewhere in the background, and I feel like you've got some suggestions up your sleeve.

+ +

VICTORIA: Yeah, so I love the name of the podcast. I like when I network, and I usually say that, "I'm, like, the co-host of the Giant Robots Smashing Into Other Giant Robots." So, I want to keep the name to be fun. And maybe it's giant robots in a different action like Giant Robots High-Fiving Other Giant Robots or Giant Robots Without Borders, or something like that. That's what I'm thinking.

+ +

SVENJA: I really like the Giant Robots Without Borders. I really like it.

+ +

JARED: Sami, you had a good one that I quite liked as well in the spirit of what we've been talking about: Giant Robots On Tour.

+ +

SAMI: Oh yeah, Giant Robots On Tour. That makes it sound, to me, like we're just going out and having a really fun time, not like we might not be doing sensible things, but we're going on tour. But that kind of also indicates, you know, what happens on tour stays on tour. And we probably need to be conscious that other people will listen to this. So, we have to maybe, like, tone it down if we are the giant robots who are on tour. But yeah, I like Giant Robots On Tour. This is cool. We're actually going to name our series.

+ +

VICTORIA: I do think it would be funny if it was, like, less...I don't want to say less violent, like, Giant Robots Smashing Into Other Giant Robots, like, Giant Robots Knitting Socks or something, like [laughs], fun, nice, but maybe not as exciting.

+ +

SVENJA: Baking Bread Together [laughs].

+ +

VICTORIA: Giant Robots Baking Bread actually sounds pretty cool.

+ +

WILL: Giant Robots On Tour because it reminded me since we're talking about the different region, the great English rock band, the Beatles. That's what it reminded me of. So, shout out to the UK.

+ +

SAMI: Yeah. I actually often drive past...do you know where the Abbey Road studios were? And there's that famous picture of the Beatles on the album cover of where...I don't know which album it is. They're crossing that zebra crossing across the road. There's that picture of all of them. And what you get now is you get loads of tourists. And so, you're trying to drive your car, and they're just hanging out on the zebra crossing, trying to replicate that picture that they had on the album cover. If you're not familiar with what I'm talking about, just Google "Beatles zebra crossing album cover," and you'll get an idea of kind of what I have to face when I'm just trying to drive from A to B sometimes.

+ +

VICTORIA: Well, that's also part of, you know, bringing up why we were wanting to have some hosts in the Europe, West Asia, and Africa region, is there's a lot of context and things like calling it a zebra crossing. We call it a crosswalk. And just having more context and connection with our guests who are from that area would be really great.

+ +

I don't know if you all saw the pictures, but for the last RubyConf that was in San Diego, I actually made robot costumes out of cardboard boxes. And there's absolutely a picture of me in a giant robot costume sitting on a lounge chair outside in the sun. So, it might be perfect for your series.

+ +

SAMI: I think that's a great way to name things, right? Like, if you have a picture that works for a thing, then you have to kind of go with a name like that. Do we vote? How do we come up with it? Is this a democracy? Probably not.

+ +

JARED: Well, I think one thing we haven't clarified is that Sami, you're our primary co-host for the European adventure. So, maybe you should get the decider. Should you dictate to us?

+ +

SAMI: I feel like it's almost worth it kind of being the primary host just so I get to pick the name. So yeah, sure, I'm going to decide, so it's Sami's Giant Robots is going to be the name of this series. No, I'm kidding. Let's go with...okay, I'm stuck between without borders and on tour. I'm really stuck between those two. So, no one else can see this. I'm going to say, like, hands up if you want without borders. Hands up if you want on tour. Okay. Okay. Okay.

+ +

We're going to be calling our new series, with the most exciting guests that you've ever seen, Giant Robots On Tour. You've heard it here first. It's been announced.

+ +

WILL: Thank you for joining us. I look forward to the Giant Robots On Tour. I am excited about it. I love that we have the diversity at thoughtbot to be able to have this limited series. So, I'm excited to see what comes out of it. So, I can't wait to check it out. I'll be one of the first listeners on every podcast that comes out.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Will Larry announces an exciting new Giant Robots Smashing Into Other Giant Robots podcast limited series focusing on Europe, West Asia, and Africa and introduces new co-hosts Sami Birnbaum, Svenja Schäfer, Rémy Hannequin, and Jared Turner! Sami sets a fun challenge for the team to devise a name for the new series by the end of the podcast. The co-hosts engage in an icebreaker game where Sami randomly generates questions for each to answer.

+ +

The team members talk about their paths into the tech industry. Jared, Rémy, and Will share stories of discovering their passion for tech, overcoming initial struggles, and finding their niche within the field. They discuss the importance of patience, problem-solving, and continuous learning in their careers. Sami emphasizes the value of realistic expectations and the ability to spend time with complex problems to find solutions.

+ +

As the first show progresses, the co-hosts have an amazing time brainstorming potential names for the new series, and ultimately, the team decides on "Giant Robots On Tour" to capture the spirit of exploration and collaboration across different regions. We're excited to keep bringing you this new limited EWAA series! Please subscribe and follow along with us!

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

And today, we're announcing a new limited series of the podcast focused on the region of Europe, West Asia, and Africa. Please welcome our new co-hosts. Let's start with Sami. Can you introduce yourself?

+ +

SAMI: I'm Sami. I'm a developer at thoughtbot based in the UK, in London specifically. And I'm really looking forward to this new Europe, West Asia, and Africa podcast, although we are going to need to come up with a name. We haven't got one yet because we're busy people, and we're consultants the rest of the time. But the plan is to get one.

+ +

I don't think there's any quicker way to do it than just for ourselves to come up with one. And so, I think we should do a bit of a challenge here. I think we could say that by the end of this podcast, we'll have a name. I don't know what that's going to be. I don't know what that's going to look like. But we'll go around at the end of the podcast, and we'll see if one of us during this podcast can pick a name for this new series. I'm going to pass on to Svenja. Hey, Svenja.

+ +

SVENJA: Hi, Sami. Thank you so much. My name is Svenja. I'm a developer and development team lead at thoughtbot. I live in Spain, more precisely in Almería. It's part of Andalusia. It's all the way in the South of Spain. I'm very excited to be in this podcast. And about the name, I'm also very excited about that. No clue yet. That's it for now from my side. Rémy, do you want to go next?

+ +

RÉMY: Thank you, Svenja. I'm Rémy. I'm a software developer at thoughtbot. I joined a little bit more than one year ago. And I'm working from Paris, France. And I'm very excited to join this series. Jared, do you want to go next?

+ +

JARED: Yeah. Thanks, Rémy. Hi, my name's Jared. I'm a product manager at thoughtbot. I am originally from Australia, but I live in London. And you're currently hearing me from Scotland. I'm very excited to hear what we're going to discuss over the course of this limited series and to hear what name Sami is about to come up with on this very podcast. Sami, back to you.

+ +

SAMI: Yeah. Thanks, Jared. It's great to be doing this with all of you. And formal intros are great, right? So, now everyone kind of knows our position at thoughtbot and where we live. But I was thinking possibly to spice some things up...I've never done a game like this before, so I have no idea where this is going to go.

+ +

It's kind of an icebreaker game where I use a random icebreaker generator online. They're not my questions. They're generated by someone else, which makes it even more risky. I'll kind of go to each of you individually with an icebreaker question that I've generated, and you're going to have to answer the question.

+ +

You have no idea what's coming. I have no idea what's coming. But it's a great way of other people getting to know kind of more about us in a more informal way, in a way which we might not think about sharing things. I will do you a favor, though; I'll give everyone two skips, okay? So, I'll hit you with a question, and then, if you don't like the question, you can skip the question. But you've only got two skips, so I would say use them wisely. Because if you skip and you get a worse question, you're not going back to the previous one.

+ +

Oh, okay, this is interesting. I'm going to start the way we intro'd, just to make it fair. Svenja.

+ +

SVENJA: I'm scared. I'm scared [laughs].

+ +

SAMI: You should be scared. The best thing about this game is the one who's hosting doesn't get asked the questions. So, Svenja, this is your question. What is a lesson you feel you learned too late in life?

+ +

SVENJA: Online banking [laughs]. I don't use online banking for that long. I don't know. I was the last person, I think, who always ran around with cash because I also didn't use credit cards also, so maybe trust in online banking. I'm not sure [laughs] that's a lesson. Sometimes, I probably shouldn't trust in it, but yeah, it would have made my life a little bit easier. Does that count?

+ +

SAMI: It definitely counts. I mean, what could be more valuable information to know about Svenja?

+ +

SVENJA: [laughs]

+ +

SAMI: That she doesn't like online banking. And that's exactly the type of valuable content you will get from the Europe, West Asia, and Africa podcast series, which I hope, in the background, we are all thinking of a name because we cannot just say Europe, West Asia, and Africa series the whole time.

+ +

WILL: I have a question, a follow-up. So, how did you do banking? Did you go in every single time, deposit, and withdraw inside the bank?

+ +

SVENJA: Yes, actually, well, I did. It was good and kind of not so good because I always needed to go back home because I had one office I was kind of allowed to go to because all the others they didn't know me. And so, I went there; then I did my transfer there. I like to speak to real people [laughs], which is interesting because I always worked remotely, at least the last ten years, I think. But real-life interaction is kind of important to me.

+ +

WILL: Yeah, that's neat to know. Okay. Awesome. Awesome.

+ +

SAMI: That's cool. Okay, Rémy, I have not hit the generator button yet, so I don't know what's coming. Let's hit it now. Okay, this is interesting. What's something you do to relieve anger or stress?

+ +

RÉMY: I have a lot of different activities. I kind of find it hard not to do anything. I don't know if it's a quality or not, but I know I'm always busy. So, if I'm stressed, I just go to the next occupation, you know. So, I like to do bread at home. I like sourdough bread. It smells amazing. It's not that easy, but you're working with living organisms. It's kind of nice. I read a lot of astronomy magazines because I'm deeply in love with astronomy. Sometimes it works, sometimes it doesn't, but I love to play with my daughter. When you're stressed, sometimes it increases the stress depending, but it's always quite fun.

+ +

SAMI: That's great. Playing with the kids definitely resonates with me. I've got four of my own, so they keep me busy. Is the sourdough bread is that the one where you have that...I'm going to show how naive I am—my lack of knowledge. You have, like, that starter thing that kind of lives with you.

+ +

RÉMY: Yeah, exactly, the sourdough starter. That's actually the most fun part for me so far because you have to start from scratch. I mean, you can start with another starter. But it's quite interesting to just start with water and flour, and then you create something living, and it's a mutual benefit. You feed it, and then it feeds you a little bit later when you bake it in 200 degrees in your oven. It's interesting.

+ +

WILL: You said it's a living organism. So, you said that you started with water and flour. So, what introduces the living organism into the sourdough bread?

+ +

RÉMY: I lack a bit of the English vocabulary for that. I think it's called yeast. The living yeast on the flour, especially if it's organic, it's just out there, you know, even in the air. And when you just feed it with warm water and, like, a cozy environment, it starts eating the flour, and it develops, and it changes some of the texture and the taste into a lot of things. And then, it's quite powerful for making the bread rise and making a very nice taste and the crust and everything. But I think if I'm correct, Svenja might know a lot more about [inaudible 07:51] bread than me.

+ +

SVENJA: I don't. I think the reason you said is because I'm German [laughs]. We love bread, and I absolutely love bread, but I don't have the patience to feed something. I don't have kids. I do have dogs. I do feed them, but they also get sometimes a bit of bread. I was never able to do my own sour bread, unfortunately, because I really love it. And I don't get it around here, which is really sad. So, I will look into that.

+ +

SAMI: That's cool. That brings us to Jared. Jared has been waiting patiently for his question.

+ +

JARED: Hit me with it, Sami.

+ +

SAMI: Let's do it. Oh, okay. If you could kick one person out of this podcast...no, I'm kidding. I'm kidding. I'm kidding. I'm kidding. That's not, I mean, no, that was just...that's my own. Okay, let me actually do one. What's one characteristic you admire in others, and why?

+ +

JARED: Oh, interesting. I think I always appreciate when someone else takes the time to understand someone else's point of view. If that goes a bit meta, like, we live in our own heads so much that it's really nice when someone reflects on how someone else thinks or their point of view. So, that's my one characteristic.

+ +

SAMI: That's really interesting. And how have you found, I guess, in the world of consultancy, and when you're working with products, how have you found that's kind of helped you when it comes to the product ownership side of things?

+ +

JARED: Well, it's a constant reminder to do it myself; that's for one thing, especially dealing with a lot of different clients and a lot of different people. It's always really important to think about their perspective, their own customers' perspective.

+ +

SAMI: That's cool. I'll hand back to Will, but, Will, I'm not just going to hand it back to you for free, right? You're also going to have to do an icebreaker.

+ +

WILL: Let's do it.

+ +

SAMI: Will, would you rather receive a shout-out from the CEO at a company all-hands meeting or a private word of thanks from them?

+ +

WILL: Ooh, I'm usually a private person, so probably private. But I have learned in my leadership, and I've learned this, this is a lesson I've learned: it's like, praise publicly, but then, like, reprimand privately. And so, I think majority of the people like that. But I'm just a private individual person. So, I'm like, just tell me, and I'm okay with that. I don't need everyone else to tell me and to say, "Hey, Will, you did a good job." Because yeah, it just brings pressure and all of that to me. So, I'm more of a private individual. Because also, I can ask more questions then. I can get more detail around like, "Yo, what did you like? Why are you saying a thank you and a shout-out?" So, that's where I'm at.

+ +

SAMI: Okay, I'll hand back to Svenja.

+ +

SVENJA: Yeah, I think we should give it back to you as well. So, because I am able to open a website, so that's another lesson I learned: how to type it in.

+ +

SAMI: [chuckles]

+ +

SVENJA: And I do find a question for you. Since nobody skipped, we will remove that option for you, Sami. So, you only get one question and that is, what is one thing we would never guess about you?

+ +

SAMI: Oh, I love that. Should I say how much I hate podcasting?

+ +

SVENJA: [laughs]

+ +

SAMI: No, I'm kidding. I haven't done it enough yet to know if I hate it. Ooh, one thing. That kind of means I've got to reveal something, right? Because you would never guess this thing, and you would never know this thing. So, I am 32 years old, and my intention was never to be a developer, ever.

+ +

So, I actually wanted to be a psychotherapist, a cognitive behavioral therapist, to be precise. And I started on a master's course. I did it for six weeks, and then I realized I couldn't handle it. I had placements in a hospital, and the cases that we were dealing with it was too much for me. It was too overwhelming, and I didn't have the skills to kind of handle that as well as my own personal world.

+ +

So, at the age of about...I've got to remember what age it was. I think it was about 25 years old, 24, 25 years old. I already had one kid, and I was married with one child. And what am I going to do? My whole plan to be a psychotherapist that I'd done my undergraduate degree to go towards, and now I was on this master's just kind of fell apart.

+ +

So, it's like, what's the easiest thing I can do? And that was to learn to code, right [chuckles]? Well, I'd always been good at computers. I'd always been fixing things. I was always the one at home who'd been asked, you know, "There's a problem with this computer." Normally, it was the printer, and I hate printers, but that's for a totally other episode. I could do a whole episode on printers. My one next to me is currently plugged in. I don't use Wi-Fi—Bluetooth with it because it's just not worth it.

+ +

But either way, so I wrote my first line of code when I was 25. That was the first time I ever saw code, wrote HTML, and knew what it was. So, I never wanted to be a developer. Here I am all those years later, but it was never a plan, and I've found myself here. But I'm quite happy for it.

+ +

SVENJA: That is so interesting and definitely something I wouldn't have guessed.

+ +

SAMI: Yeah, it's been one hell of a journey, shall we say, but an exciting one.

+ +

SVENJA: I would be super interested how the others of you stepped into the world of tech, so to say.

+ +

JARED: Similar sort of thing to Sami in that I've always been interested, always been the sort of more technical, geekier person of the school and the social groups. And then, at uni, I actually took some computer science classes, and then quickly felt very confused and ended up doing a bachelor of commerce in marketing and management instead, which was a lot more straightforward basic business degree, sort of tick some things off. But still, like, throughout all that time, always just loved tech, loved reading about it, loved dabbling.

+ +

And I landed a job at a previous company that I just got a lot of freedom to help out where I needed, problem-solve, do lots of different things. It was quite a small business. I was able to level up a whole bunch of different skills, like some technical and some sort of more managerial as well. That's sort of how I got a lot of my knowledge and then moved on from there. How about you, Rémy?

+ +

RÉMY: I started in tech right away after high school. So, I had studied...I think we still call it multimedia. It was communication, coding, design, sound, video. I learned how to make step motions, you know, a lot of different things. It was kind of doing everything and trying to find the one thing that you actually like, and I found mine, which was actually coding.

+ +

I think I found what I liked when I was in school. I remember struggling on math homework. I don't have a very high background in math, but I used to enjoy it. I remember struggling on some homework, and the sensation when you finally find the answer, and you finally resolve the problem it was amazing. And I felt that again in coding. Like, you have a bug, or you have a feature, and you can't make it. And you try again, and you find some clues, but it doesn't work. And at some point, it works, and you finally made it. And it's an amazing sensation. I had it again, like yesterday. It's quite common. I love that so much. So, I think that's how I decided, okay, that's what I want to do every day.

+ +

SVENJA: Thank you so much, Rémy and Jared. What about you, Will?

+ +

WILL: Yeah, I think I've told this story before on the podcast, but I always love telling it again. I actually lost my job, and I was really struggling. And if you know me, fashion is not my thing at all, and I was working at this fashion store. It was this clothing store. I hated it. I hated it. Like, there's no shortage on that. I hated it [laughs]. I was working there, and then I also started working at this insurance place. We sold travelers insurance. So, it was very interesting to see how that works. And yeah, I'm not going to say too much about it, but yes, how that works [laughs].

+ +

But at that company, the one good thing about it was they were like, as long as you get your work done, you could do whatever you want. And so, one day, I was at home, and my partner was like, "You're struggling. You're just trying to figure out what you're trying to do, and you're struggling." So, she kind of walked me through, like, "What do you want to do?" And I was...when Sami mentioned the printer, I laughed because I was that person also. And printers are tricky because you never know what the real issue is. You just got to tinker with it and hope it works. And yes, you never get the same answer twice, I feel sometimes [laughs].

+ +

SAMI: I feel like all our listeners who are kind of really good at fixing printers are thinking like, oh my gosh, I'm going to work at thoughtbot now. I'm going to be an amazing developer one day.

+ +

WILL: You could. Why not [laughs]? And it's interesting you say that because, like, I was 29 or 30 whenever I started in the field. So, I was a little bit late, I feel sometimes, to get into development. But my wife, she asked me, "You're struggling. You need to do something because this is not going to work. We got to change it up." And I was like, well, I grew up in a small town in Louisiana, in the south of United States, and we didn't have anything tech there. It was just a rural place. And so I never had the opportunity to learn anything about computers. I guess the printer and stuff just came naturally to me, and this was before YouTube and all of that.

+ +

So, she challenged me. She said, "Go and learn it. Go figure it out. Go learn it." I did. And I forgot who mentioned; somebody mentioned something about being easy getting into development. It was not for me. I remember so many times at the coffee shop just, like, I don't know what I am doing. And if you know anything about me, I sometimes don't have the patience to slow down. And so, I came in, and I wanted to be a senior developer and produce like a senior developer. And I was sadly mistaken that that's not how it work. But five years now, I am a senior developer, so I've enjoyed it. I would not change it for anything, and I love it. So, it's been a good change for me, so I love tech.

+ +

SAMI: I think it's so helpful to kind of hear realistic expectations about how long it does take. It really is a skill. Some people often ask me, "What is one characteristic that kind of indicates success in the field?" And there isn't just one. But I definitely think that the ability to sit and spend time is so helpful. Because if you can spend time with something and just sit there and, like, be patient, like you were saying, often, you will get to a solution, and it will happen.

+ +

But it's about almost slowing yourself down and slowing your mind and your brain down. And we kind of call it in industry, you know, the concept of having a rubber duck, which is also a form of I'm stuck on something. I just need to speak this out, not necessarily with someone who can respond, but in a way that allows me to verbalize slowly what's going on. And you'll be surprised how often you reach a solution. So, that's really interesting.

+ +

So, yeah, we've got this great series coming. We have some great guests lined up. The advantage of doing this series over in Europe, West Asia, and Africa is we're going to get access to some guests within our time zones, within our region that this podcast has not been able to get access to before. And so, we are really excited about the people that we're going to bring on, and you're going to get to hear some of the most incredible podcasts that you've heard.

+ +

But we don't have a name. We still don't have a name. And I kind of set the challenge at the beginning of this podcast of, well, let's just come up with one. So, who wants to give a shout-out and think about, you know, what this name is going to be? Just to clarify, it's still going to be called the Giant Robots Smashing Into Other Giant Robots podcast, but where you see that kind of title of the individual episode, it will probably have a prefix of kind of the series name just so you know it's from us. Victoria, I feel like you're hiding away somewhere in the background, and I feel like you've got some suggestions up your sleeve.

+ +

VICTORIA: Yeah, so I love the name of the podcast. I like when I network, and I usually say that, "I'm, like, the co-host of the Giant Robots Smashing Into Other Giant Robots." So, I want to keep the name to be fun. And maybe it's giant robots in a different action like Giant Robots High-Fiving Other Giant Robots or Giant Robots Without Borders, or something like that. That's what I'm thinking.

+ +

SVENJA: I really like the Giant Robots Without Borders. I really like it.

+ +

JARED: Sami, you had a good one that I quite liked as well in the spirit of what we've been talking about: Giant Robots On Tour.

+ +

SAMI: Oh yeah, Giant Robots On Tour. That makes it sound, to me, like we're just going out and having a really fun time, not like we might not be doing sensible things, but we're going on tour. But that kind of also indicates, you know, what happens on tour stays on tour. And we probably need to be conscious that other people will listen to this. So, we have to maybe, like, tone it down if we are the giant robots who are on tour. But yeah, I like Giant Robots On Tour. This is cool. We're actually going to name our series.

+ +

VICTORIA: I do think it would be funny if it was, like, less...I don't want to say less violent, like, Giant Robots Smashing Into Other Giant Robots, like, Giant Robots Knitting Socks or something, like [laughs], fun, nice, but maybe not as exciting.

+ +

SVENJA: Baking Bread Together [laughs].

+ +

VICTORIA: Giant Robots Baking Bread actually sounds pretty cool.

+ +

WILL: Giant Robots On Tour because it reminded me since we're talking about the different region, the great English rock band, the Beatles. That's what it reminded me of. So, shout out to the UK.

+ +

SAMI: Yeah. I actually often drive past...do you know where the Abbey Road studios were? And there's that famous picture of the Beatles on the album cover of where...I don't know which album it is. They're crossing that zebra crossing across the road. There's that picture of all of them. And what you get now is you get loads of tourists. And so, you're trying to drive your car, and they're just hanging out on the zebra crossing, trying to replicate that picture that they had on the album cover. If you're not familiar with what I'm talking about, just Google "Beatles zebra crossing album cover," and you'll get an idea of kind of what I have to face when I'm just trying to drive from A to B sometimes.

+ +

VICTORIA: Well, that's also part of, you know, bringing up why we were wanting to have some hosts in the Europe, West Asia, and Africa region, is there's a lot of context and things like calling it a zebra crossing. We call it a crosswalk. And just having more context and connection with our guests who are from that area would be really great.

+ +

I don't know if you all saw the pictures, but for the last RubyConf that was in San Diego, I actually made robot costumes out of cardboard boxes. And there's absolutely a picture of me in a giant robot costume sitting on a lounge chair outside in the sun. So, it might be perfect for your series.

+ +

SAMI: I think that's a great way to name things, right? Like, if you have a picture that works for a thing, then you have to kind of go with a name like that. Do we vote? How do we come up with it? Is this a democracy? Probably not.

+ +

JARED: Well, I think one thing we haven't clarified is that Sami, you're our primary co-host for the European adventure. So, maybe you should get the decider. Should you dictate to us?

+ +

SAMI: I feel like it's almost worth it kind of being the primary host just so I get to pick the name. So yeah, sure, I'm going to decide, so it's Sami's Giant Robots is going to be the name of this series. No, I'm kidding. Let's go with...okay, I'm stuck between without borders and on tour. I'm really stuck between those two. So, no one else can see this. I'm going to say, like, hands up if you want without borders. Hands up if you want on tour. Okay. Okay. Okay.

+ +

We're going to be calling our new series, with the most exciting guests that you've ever seen, Giant Robots On Tour. You've heard it here first. It's been announced.

+ +

WILL: Thank you for joining us. I look forward to the Giant Robots On Tour. I am excited about it. I love that we have the diversity at thoughtbot to be able to have this limited series. So, I'm excited to see what comes out of it. So, I can't wait to check it out. I'll be one of the first listeners on every podcast that comes out.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+K7BZd-7P + + ]]> + + + + 529: How AI Transforms Small Business Operations + https://podcast.thoughtbot.com/529 + e557960c-a61c-4680-85d3-feed7b0c1d37 + Thu, 13 Jun 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido talks with Jaclyn Siu, co-founder of Starcycle, an AI platform acting as a COO for small businesses, where Jaclyn shares her entrepreneurial journey and vision for democratizing startup tools for small business owners. She discusses the development of Starcycle to automate critical business phases—start-up, sale, or shutdown—and emphasizes the role of personal connections, genuine curiosity, and empathy in creating solutions that meet the true needs of small businesses. + 40:14 + no + + + Host Victoria Guido chats with Jaclyn Siu, the co-founder of Starcycle, an AI platform designed as a COO for small businesses. First, Jaclyn describes her entrepreneurial journey and what led her to Starcycle, detailing her earlier ventures, such as helping to scale a men's styling app and a software platform for authenticating high-end art. +Her ultimate goal is to make the tools and experiences typically reserved for startup founders accessible to small business owners, who comprise most of the global business ecosystem. She outlines how Starcycle supports crucial phases in a business’s lifecycle—start-up, sale, or shutdown—by automating operations and documentation, easing burdens on business owners. +Jaclyn also touches on the importance of personal connections and genuine curiosity in conducting user research and developing products that genuinely meet the needs of small businesses. She believes we can achieve this by being deeply rooted in empathy and strategically using technology like Starcycle. +Starcycle (https://starcycle.ai/) +Follow Starcycle on LinkedIn (https://www.linkedin.com/company/starcycleai/) or Instagram (https://www.instagram.com/jaclynsiu). +Follow Jaclyn Siu on LinkedIn (https://www.linkedin.com/in/jaclynsiu/). Visit her website: jaclynsiu.com (https://jaclynsiu.com/) +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jaclyn Siu, Co-Founder of Starcycle, the AI COO for small businesses. Jaclyn, thank you for joining me. +JACLYN: Thank you for having me. It's so fun to be here. +VICTORIA: Great to be here with you as well. Before we get into learning more about Starcycle, can you tell me what's going on in your life outside of work that's exciting for you? +JACLYN: This is a very big departure from what I do on a day-to-day basis, but I am a huge coffee fanatic. And so, I love sampling all different kinds of coffee beans from around the world. And this morning, actually, I just finished the last cup from this amazing roastery in Osaka, Japan. They're called Mel Coffee; shout out to Mel Coffee. That's what I spend a lot of my time outside of work doing is trying different coffee beans. +VICTORIA: No, I love it. I love coffee as well. Actually, I am currently out of espresso beans. We have a fancy espresso machine maker. It's like our one big luxury in the house, and I don't have any coffee beans for it. So, I might need some recommendations from you [laughs] on what to get. +JACLYN: My sympathies on the lack of coffee, but I have plenty of recommendations. We can absolutely jam on this afterwards. +VICTORIA: Okay. Because you've traveled quite a bit, of all the places that you've been, where is the best cup of coffee that you've had? +JACLYN: I mean, I definitely have my favorites. In New York where I am currently, I would say that honor belongs to The Coffee Project. Actually, it's a tie between The Coffee Project and Say Coffee. +In Berlin, where I was based for the last seven years or so, I would say that honor goes to Bonanza Coffee. I used to go there every single day. And I attribute a lot of my success in Berlin to all the beautiful cups of coffee that they served me. +In other places, I would say what comes to mind is for sure Mel Coffee in Osaka, Japan, also, Glitch Coffee in Tokyo. In Hong Kong, that would be Craft Coffee. Hong Kong is where I'm from originally, so I have a very big fondness for any local roasteries. And I am going to stop there because, otherwise, this would become a coffee podcast, and I don't think this is what we're here for [laughs]. +VICTORIA: I think there's a pretty strong coffee interest in our listeners, but they can tell me if I'm wrong. No, I think that's great, and it tells us a little bit about yourself. So, you've lived in all these different places and all these backgrounds. Maybe you can tell us a little bit about how your background led you to starting Starcycle. +JACLYN: Starcycle is my third company. I'm a three-time founder, advisor, investor, and mentor. I built my very first startup in my senior year of college, which was a men's personal styling app that surfaced shoppable outfits based on your calendar, style preferences, weather, and other things. And decided quite quickly early on, about a year in, that I wanted some real-world experience before understanding what it's like to run and build a company. I realized, hey, I need to know what it's like to be in one before I can build one. +So, I spent the next decade-plus in the creative culture and tech spaces, everything from sales and partnerships to marketing growth and operations. I worked on really exciting things from album releases for Rihanna to closing brand deals with TikTok. So, that led me to New York, to Berlin, and now back to New York, which has been really fun. +My second startup was co-founded over the height of the pandemic, and we built software for blue chip art galleries and working with them to authenticate blue chip and high-end physical art pieces. We authenticated $63 million worth of art in the company's lifetime. +The even tide of that, so towards the end of my second venture, that kind of initially planted the seed for Starcycle because we had been facing some more difficult times, and we were facing some pretty difficult decisions. I just had this Eureka moment, so to speak, where I was like, hey, I know firsthand how difficult it is to found a business. I want to use my knowledge to help at least one person get over the finish line. And I explored so many different permutations of that. I spoke to startup founders to small business owners, spent hundreds of hours exploring different ways that I could use tech to empower founders, and eventually ended up with Starcycle, which, as you mentioned earlier, is the AI COO for small businesses. +And what we do is we are supporting business owners at the mission-critical stages of their business life cycle, so the startup phase, the selling phase, which is when they're hoping to sell or get acquired, and also the shutdown phase. And so, we review and parse through key documentation and automate key operational tasks such as licensing, identifying engagement terms, drafting disclosure statements, et cetera, et cetera. So, it's very much born out of my own experience as the COO and also as an operator for many different kinds of businesses. +I grew up in a very entrepreneurial family of restauranteurs. My dad runs his own practice as a doctor. And I have cousins and other extended family members who are accountants and have their own practices. Somehow, half of my generation in my family are all startup founders now, so that has been really cool just being immersed in that, and also, yeah, wanting to use tech to give back, essentially. +VICTORIA: I love that connection with your family and how that mindset is a part of your culture and who you are. It's really interesting to hear and replay a little bit back of what you said about, you know, you knew you were entrepreneurial, but you wanted more experience. And then, you got to go through starting your own company several times. And now you're trying to share the experience you got from that with other founders. +JACLYN: Exactly. And what drew me to small businesses, really, was that startups do have quite a lot of help. Of course, we can argue perhaps a separate episode on how this support is distributed and whether or not it's equitable, but startups do tend to hog a lot of the headlines and a lot of the glamour and the glitz of being a founder. +And where I was really drawn to was the day-to-day coffee shop owners; for example, that was a big one, or just the fact that 99% of businesses around the world are considered small businesses. And I said there has to be a way to take a lot of the great tools and services that we have enjoyed as startup founders and kind of make that a lot more accessible to the people who really need it. And so, that was really the big bow on top for me to start working on Starcycle. +VICTORIA: Yeah. It's interesting to think about accessibility and inclusivity, and not just access to funding, but access to tools, access to knowledge, and support, and getting your business up and off the ground. +JACLYN: Exactly. I think the knowledge piece is a big one. And with knowledge, of course, comes support, as you say, and both of those things require a lot of hands-on education but also guidance. And one thing that I've learned over my career as an operator but also as a serial founder is how much that initial touch point really matters for folks. +And so, when I say that, I mean, just think about the very first time you encountered a new piece of technology and the feeling that inspired in you and how you felt like that new piece of tech, for better or for worse, reinforced, or not, that feeling. I've been really lucky to be at the forefront of helping a lot of people navigate these experiences, from helping fashion brands at the very beginning of my career, helping fashion brands understand social media. +This was before sponsored content was a thing. We still called them bloggers back in the day. Yeah, teaching them that social media is going to be an asset for brand marketing, and kind of being on the first wave of tech partnerships, and embracing social media as a platform, to working with artists to get them onboarded and comfortable with streaming. So, I was at Roc Nation at the time when streaming was really just starting to take off. It was the same year that Jay acquired Tidal. And so, there was a seismic shift in how the music industry as a whole was grappling with this new tech. +Fast forward to working with art galleries, probably one of the most difficult technical nuts to crack, so to speak, and working with traditionally folks who reject new technology and are wary of software that doesn't offer the same level of discretion or convenience that they are used to, and working to get them excited about software solutions that are built just for them. +And so, the through line, for me, you know, as I look back, is how can I take something scary, and intimidating, and difficult to understand for your person who is chronically offline, so to speak, and translate that into an experience that they look forward to that makes them see, "Oh, this is not just some sci-fi hubbub; it's not just what the Yahoo's at Silicon Valley are up to; this is going to help me and what I care about"? And that particular thought process, that particular intersection, is what really gets me going every day. +VICTORIA: That's really interesting. And it reminds me of friends that I have who have really deep domain expertise in certain things like nutrition, and coaching, and early childhood intervention and development. And they're asking me, someone who has, like, a connection to founders and startups, about, like, "How do I get my thing going? Like, how do I take this knowledge and build a business around it?" So, maybe you can tell me a little more about what research you're doing with these groups of people, with these small businesses. And what kind of questions are you asking, and what kind of things are you finding? +JACLYN: Sure. So, I started with a hypothesis, which was this slightly more nebulous notion that everyone will have an AI copilot. And so, I started to workshop what that could look like for a business owner, specifically because 78% of small businesses are owned and operated by one person. And my expertise or experience as a founder is having had a co-founding team where we can fill each other's gaps, and lift each other up, and work on different things. And a lot of small business owners don't have that luxury. +So, I said, okay, this is a problem that I have noticed. I am going to explore this to every single nook and cranny I can possibly find. And that led me to experiment with different ways to apply AI to this particular problem. I started looking at the early stage founding stage, where business owners are identifying their next steps to get their next big thing off the ground. They're navigating bureaucracy and figuring out what licenses they need what paperwork they need to file to make certain things a reality. And that, to me, felt like an easy place to start because it is a very well-documented and well-accounted-for space. So, we quickly shipped an early beta feature just to gauge market sentiment and to see what people were really looking for. +There really is no shortcut here, in my opinion. It's really about putting in the time and the effort to talk to everyone that is interested in finding a new solution for something that has deeply plagued them in some way or another. In a way, putting on different hats as a psychologist almost, like, understanding where their pain points are really stemming from. Is it, like, an operational thing? Is it an emotional thing? All the way to introducing them to something new, which involves reimagining what that user experience could look like, all the way to just being open and having a clear line of communication. +I talk to our users almost every day. We're on calls; we're on emails. And I just love hearing from them, and they know that they can come to me and talk to me about things. I've consulted for some of our small business owners before who come to me with different questions like, "Hey, can you help me with this business plan?" +Anyway, so, through all of those conversations, I started to stitch together a few things. The first being that AI is changing so rapidly, and, of course, this is something that is challenging but also incredibly exciting because no one really knows where it's going. We're all kind of testing out our hypotheses in real-time. We're all building towards that reality we want to see. So, noticing that a lot of co-pilot promises we were still, or at least I feel like, we're still a little bit far away from that. And so, I started examining, okay, what is AI already currently really good at and will only get better at? And how can that be applied to something that all business owners have to face? +And so, I expanded my search into other life stages of a business, and I identified that over hundreds of hours of conversations as the M&A stage and the closure stage. The M&A space is very exciting. It is also very well accounted for. And, currently, I'm spending quite a lot of time looking into the bankruptcy aspect, the end of life, something that, unfortunately, a lot of businesses will have to go through. +And yeah, really studying that space, deeply realizing that we can probably find a, if I may use this as a verb, a "turbo tax" for all of these different key operational moments for every small business, right? So, we can, quote, unquote, "turbo tax" starting a business. We can, quote, unquote, "turbo tax" trying to sell your business. We can turbo tax, closing down your life's work and trying to find a good place to put it to rest. +VICTORIA: How do you find people to be a part of the research? And how do you make sure that you're being inclusive or, you know, going after the right groups? +JACLYN: To the best of my ability. I start within my own networks. Luckily, since at this point, I have built quite a lot of friendships and relationships just within founders of all different kinds, I started by reaching out to different founders and just approached it with a lot of curiosity. I was like, "Hey, what are you working on? What is troubling you? How could I help?" And approaching it from a place of "How can I help?" as opposed to "How can you help me?" You being, of course, the founder I was speaking to. Yeah, really just being in the position of I want to learn from you, I would say, in hindsight, has been the key to a lot of folks being willing to speak with me. +And then, of course, on the call itself, when I do manage to get that scheduled, when I speak to them, and doing everything to make them feel heard, to make them feel welcomed. I show up to every single call prepared about this person. I have my questions prepared. Usually, within Calendly, for example, people should fill out what their profile kind of is. So, we do a lot of that pre-work and get that out of the way. And it also helps me prepare for the call. Weirdly enough, it's almost like preparing for a podcast interview. +And then, from those calls, I always ask like, "Hey, I really appreciate you spending time talking to me. Do you know one person who would be willing to do the same thing?" And I would say, nine times out of 10, the answer is "Yes." And then, I get a follow-up email being like, "I loved talking to you. Here's my friend who is also facing a similar thing. I already told them about our conversation. They would love to speak with you." And it just kind of flows from there. +And so, I guess to sum it all up, it really is being thoughtful with your relationships and letting that compounding effect work itself. And at this stage, like, as an early-stage founder, you and your...I don't like the word reputation, but I can't think of a better one right now. Your reputation is really what the currency is, and people typically want to help. And they also want to feel helpful, and they want you to show that they were helpful. And yeah, that has been something that I've seen a lot of success with personally, whether it's through user interviews or approaching it from, like, a sales and partnerships perspective. +VICTORIA: I agree. I think I found the same thing where, what you want to call it, and it's your reputation or your authenticity and your genuine interest in solving the problem that you're going after. I think a lot of people are, you know, of course, they want to talk about things that are bothering them, and they want to see other founders succeed, and it's part of a community. So, it's really nice to hear that's been working for you. +JACLYN: I'm so lucky that this particular thing is what really excites me about being a founder is: having that opportunity to have these conversations. Also, at this point, probably my superpower that I feel like I can draw from so many different experiences to be a good sounding board for whoever it is that I'm talking to. +And I remember this so clearly from my previous venture where we were building software for art galleries, and we had some of the most commercially successful artists and art galleries of modern times. And they went on record saying that, you know, they're switching their solutions, or they're coming on board for the first time. And they're not considering any other potential incumbents or competitors simply due to our ability or my ability to talk to them like equals, talk to them like people. +They were like, "We spoke to so many founders who were building different kinds of tech solutions for the art industry or the art world. And we always really felt kind of small talking to them because they were throwing a lot of jargon at us. They essentially wanted us to operate under a cloud of confusion so that, hopefully, we would just go along with whatever they say. And you were really the only one who would sit down, take the time to explain, take the time to hear us out, and kind of meet us where we are and see us people." +And I was really kind of taken aback by that. And I do think that advice applies generally, but especially when it comes to speaking to folks who identify so deeply with what they do, like small business owners, it is so key to really just treat them with respect. I mean, ultimately, that's really what it's about. Like, you respect that they know things that you don't, and you don't lord anything you know that they don't over them. +VICTORIA: I really appreciate that perspective. And I'm curious if maybe there are some core values from your educational background in journalism that flows through into your being a founder and how you have these conversations with people. Are there any core values that translate from that? +JACLYN: I love to listen. I'm just such a curious person. Yeah, I guess you could say that it is a journalistic approach to, you know, ask open questions and let the person feel like they are steering the conversation, and, you know, being that safe space that they know whatever it is they're saying is being taken seriously. +One of my personal philosophies when it comes to founding is that I let the problem tell me how it wants to be solved. I have a general direction, right? Like, my North Star is that I want to use tech to empower founders; in the same way, you could say that you might start writing a piece with the general idea of like, hey, this is what I want to write about. And I'm open to letting my subjects kind of steer where they really care about so that, like, I end up writing something that is compelling for everybody. +And so, yeah, I'm always open to finding the best way. This openness and curiosity, really, has led me to meet some really interesting people and dive through some very fascinating rabbit holes that I might not have done so otherwise. +VICTORIA: Oh, that's really cool. No, I like that a lot. That's super interesting. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: So, in these conversations, you're having in your early discovery process, were there any points where you decided to pivot your strategy based on what you learned? +JACLYN: I would say that the most interesting point was...I think this is probably, like, the clearest example of...whether it's a pivot, or, like, a redirection, whatever you want to call it. This was before I kind of arrived at the stage of bankruptcy or the idea of bankruptcy, which is where I'm really diving deep to at the moment. I had already spoken to a lot of founders in kind of the early stage of starting the business when I was talking to them about, like, "How can a tool like Starcycle help you on your journey?" +And a lot of them were like, the ultimate milestone was, of course, to sell the business, that they want that ROI, that they want to know that, you know, something that they've worked so hard on was going to end up in great hands. And so, I started examining that side of the spectrum. So, that was, I guess, refocusing number one, which was, okay, I want to understand the buy-sell space, kind of the M&A space, to hear what success factors led people there. +I spoke to everyone I could think of on that end of the spectrum, you know, people who had sold a business, people who tried to sell but didn't sell, people who acquired a business, people in private equity who are looking to buy and operate a business, you know, different buy and sell marketplaces, so on and so forth. +And this one conversation with the head of M&A at a language company it was a nice chat. And he kind of mentioned as a throwaway, "Oh, by the way, like, one thing we also look at are distressed assets." That was it. And I said, "Okay, let's unpack that a bit," and just kind of left the rest of my questions. And we started going in that direction. And then, I realized it's a different side of the same coin, exploring M&A and closure, because they are, unfortunately, very closely related to one another. They are both on the ends, like, end of the life cycle. +And so, that one comment which might not have occurred, you know, let's say if the person didn't feel like he had a safe space to kind of open up about his process, that has sent me on another journey to really, really dig deep into this very opaque and difficult area, where I'm actually, again, really, really excited to really unpack: How can we help people at the time of need, and how can we use tech to do a lot of the heavy lifting to free them up for very emotionally taxing tasks? Which, of course does happen at that end of the life cycle. +I still very much believe in the overall idea of using AI to help small business owners end to end, but really, I found this particular wedge because I guess I was open to that. And someone dropped the crumb, and I was like, "Let's take that path. Let's talk about it. " +VICTORIA: So, it had a high emotional element there, and there's a lot of tasks associated with it that would make it a good use case for AI to support that particular phase of the life cycle? +JACLYN: Yeah, that's absolutely my hypothesis right now. I've been validating this with different small business owners who have, unfortunately, had to close their business. I'm also talking to bankruptcy attorneys. And so, yeah, I guess we'll see what that process looks like. By the time this episode is up and running, I might have found the right angle to tackle this problem, or I might have just found some other opening to look at. So, I guess it really is up for grabs at the moment, which is a very exciting part of being at the early stage, but, of course, also slightly terrifying [laughs]. +VICTORIA: Well, we'll have to have you back on in a year to check in and see how things have progressed. But it makes sense to me. And in all of my recent experience just hearing from founders around San Diego, it sounds like if you're going to be a founder, you are going to have to shut down a business at least once [laughs]. Like, usually, you found multiple businesses and that means that you do have to close or, you know, go through this final action at least one time. You will be very lonely being a founder, and I can see having support through that time and having it be easy could be really helpful and make it seem, you know, easy and maybe even just, like, make it easier to start things up again, too. +JACLYN: For sure. And I love that you touched on the starting again because founders, typically, more often than not, have this very stubborn optimism that we're like, we're going to figure it out one day, and we're going to do it. And at the risk of sounding a bit hokey, bankruptcy can be a beautiful thing. It is, of course, incredibly emotionally difficult. +But what I find really incredible is the notion of bankruptcy was really born out of this idea of we recognize that you took a huge risk. And even though the risk didn't pan out in the way that we all hoped that it would, we don't want to penalize you further for having taken that risk. So, here is some protection so that when you are ready again, you can start again. And I just find that sentiment very, very powerful. And I've certainly seen that to be true in my own experience. +So, this really is, like, I feel like my heart and soul problem, you know what I mean? Again, of course, I'm back to my core value I mentioned earlier. I'm open to letting the problem tell me how it wants to be solved. And so, I'm going through that process again to find, okay, what is it in this journey that I can solve with AI? And so, yeah, we can check back in however long, maybe six months, a year or so, and then see where. I would love for you to hold me to that. +VICTORIA: Absolutely. I will. I'd love that. Yeah. And, well, on that note, then, what are the biggest challenges you see on the horizon in the next six months? +JACLYN: I would say the biggest challenge that's coming on the horizon really is, to me, what is very exciting. I alluded to this earlier, but it really is this notion that, of course, we all recognize that AI is disrupting. It has already disrupted a lot of what we know to be true. We're all just testing out our hypotheses in real-time. No one really knows in what direction this wind is blowing. I don't think people could even agree on what AGI means, right? Like, AGI, is it, like, a very, very general thing, or is it AGI for X, AGI for Y? Like, what does that look like? And I don't think there's, like, a consensus on what this looks like, right? +So, in a way, every founder building in this space, including myself, we're all just working towards what we think that reality is and what reality it is that we want to see. It's a huge challenge because we're quite literally building what has never really existed before. And it is a feeling that I'm personally, luckily, very familiar with, I get super energized by. We're in the beginning. Everyone says this, right? "We're so early," but we really, really are so early in this new wave. And I'm really looking forward to drawing on all of my experiences being at the forefront of various other big changes and applying them to this very particular change. +And then, of course, I'm also a little bit nervous about this. I think anyone would be nervous knowing that the tide could change at any moment. I'm also not delusional about this per se, but I'm definitely optimistic. I think we're going to see a lot of generational companies built at every single possible intersection of AI and something. So, it's like AI for small businesses, right? Or you could even go even more granular. There's going to be an AI for hair salons. There's going to be AI for coffee roasters. There's going to be just so many ways to capture this new energy and this revolution that I am very intimidated, but I'm really excited about this. +VICTORIA: So, the gravity and the size and scope of the change, and that being unknown, and also what you mentioned on the tech stack, having that variability and just knowing you might have to pivot or change very quickly, is an exciting challenge as well. +JACLYN: It is. It definitely is. And, of course, it's a tough one to solve for sure. Any founder who wants to build something, really now is the time to just give it a shot because there are so many intersections up for grabs, and that doesn't come around very often. +VICTORIA: That's really great. And I love your approach to that by just trying to see how can you use your expertise and follow the problem and see what solution comes up that is worth focusing on? So, I really appreciate you sharing that. I'm curious if you know what success looks like six months from now or even five years from now for Starcycle. +JACLYN: I would say in six months, I would envision, at this stage, having maybe a small suite, but a suite nonetheless, of different aspects of the small business life cycle, the mission-critical stages I spoke about, having the, quote, unquote, "different turbo taxable features" live. And so, we're already able to start really moving the needle for these folks. We have our first test feature live in beta. We're already helping close to 1,200 business owners. So, I'm really looking forward to just increasing that number. +In five years, I would really love for us to be at that stage where we are helping small business owners end to end. And so, I do see AI growing at a rate or the capabilities of AI growing at a rate way faster than any of us can imagine. +So, I'm going to just throw this out there and say, in five years, I would love for Starcycle to be, like, a true AI COO on every single step of the way, like, a real strategic thought partner, executional partner for your small business that you otherwise wouldn't have. And you're in the trenches with your AI COO, and we're going to help you build the best business you possibly can. And we'll take care of your end to end. And that, I would say, is my ultimate grand vision. So, I guess let's check back and see what happens. +VICTORIA: I like that. And, you know, that's a really awesome future vision to build towards. And in the immediate term, I'm curious to ask you more about Starcycle and how AI and people work together to give leaders confidence that the COO is giving them good answers and all that. +JACLYN: One thing that we noticed while we were developing our beta and continuing to improve on our current offering is coming to the realization that we want to focus on what AI is currently already really good at and will only get better over time and, to us, that was data parsing, data optimization, formatting, data extraction. And so, that's where the next immediate stage of product development is going to go is really leaning into this data extraction aspect. +And we feel like this true thought partner; strategic partner thing will happen over time once we have, like, a lot bigger pool of data of your business to work with, where we can connect dots that you might not have otherwise been able to connect, whether it's because you physically do not have the time, or you may not have the knowledge to, let's say, comb through your monthly P&Ls to draw out certain trends in the way that AI can really do for you. +So, we're acknowledging the current limitations of AI while maintaining optimism on kind of the long run of what we think AI is going to do. And so, I think for the small business owners that we're currently supporting, we are very much on deck as humans to help them with some of the more strategic moments. And our users know that they can find us anytime. And for a lot of the more data operational action item-driven tasks that they need help with, then AI can step in fairly comfortably and help them in the majority of the cases. +VICTORIA: That sounds really cool. I like how you broke that up. Do you have anything else you'd like to promote? +JACLYN: I'm open to so many different kinds of conversations. And every single conversation is helpful. So, please reach out or sign up, try the product. +We look at every single survey. I respond to every single survey personally with follow-up questions if you'll allow them. So, I really just want to help anyone who's listening. Whatever problem it is that you're dealing with on your founding journey, I'm here to help. So, in whatever way that I can help you, please let me know. I would love to hear from you. +VICTORIA: I read in your background that also includes asking you questions about your time working with Rihanna. Is that right? You're open? +JACLYN: [laughs] Correct. I suppose. Yes. If that is of interest, we can certainly talk about it [laughs]. +VICTORIA: Oh, that's great. No, I love that, the detail on that. And then, also, we didn't get to talk everything else about your background. You also have that you're an angel investor, and you also are just a general incredible mentor and coach. So, I don't know if there's anything else you wanted to share about that. +JACLYN: I think part of it is also really driven by my passion to empower folks with technology. And a lot of that component, as we've alluded to multiple times over this podcast, is the educational component. And I think I've been really lucky to be exposed to a lot of new things throughout my life. And I want to play even some small part in helping other people encounter tech in what they perceive to be a safe and gentle way. And so, that's what I'm really excited about. +I do occasionally write small checks to companies and founders that I believe in. I spend time guest lecturing at colleges and also mentoring young girls and young women. And, generally, I'm an open book if you want to ask me about how I taught myself stop motion video editing to do something for Rihanna, all the way to how on earth did you find it in yourself to do a third company. I just want to help anyone and everyone who wants to make that difference in the world to be that difference that they're looking for. +VICTORIA: Yeah, you know what always gets me excited about tech? Is when people use tech to solve simple problems that helps everyday people. You know, I'm from Washington D.C. I spend time on the side from doing consulting with big federal agencies. I was helping startup nonprofits that were working to end homelessness and solve communication problems with nonprofit organizations sharing their services to people who needed them and that type of tech. +And I've been in California now for three years, and I've started rebuilding my networking here. And I'm starting to find those people who are working on those kinds of projects. So, I'm really excited to build a little community here in San Diego and to start giving back to some of those groups again. +JACLYN: Yeah, that's really, really awesome. And that really is what keeps drawing me back to founding is knowing that whether it's founding a non-profit initiative, or a startup, or opening up a coffee shop, like, I keep coming to coffee shops because, of course, I have a deep appreciation for them. But, ultimately, it really is such a tangible way to provide and to give back. And I can't quit. +VICTORIA: I mean, I could quit. I could quit and just, like, rock climb and be bad at surfing for the rest of my life, but I won't. But yes, thank you so much for taking the time to be with us here today, Jaclyn. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on thoughtbotsocial@vguido. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + AI for small business, small business management, entrepreneurial tools, startup life cycle, automation in business, business operations, Jaclyn Siu, Starcycle, technology in business, AI COO, business innovation, digital transformation, small business support, AI integration, small business solutions, startup advice, business automation tools, empowering small businesses, AI technology, small business entrepreneurship + + Host Victoria Guido chats with Jaclyn Siu, the co-founder of Starcycle, an AI platform designed as a COO for small businesses. First, Jaclyn describes her entrepreneurial journey and what led her to Starcycle, detailing her earlier ventures, such as helping to scale a men's styling app and a software platform for authenticating high-end art.

+ +

Her ultimate goal is to make the tools and experiences typically reserved for startup founders accessible to small business owners, who comprise most of the global business ecosystem. She outlines how Starcycle supports crucial phases in a business’s lifecycle—start-up, sale, or shutdown—by automating operations and documentation, easing burdens on business owners.

+ +

Jaclyn also touches on the importance of personal connections and genuine curiosity in conducting user research and developing products that genuinely meet the needs of small businesses. She believes we can achieve this by being deeply rooted in empathy and strategically using technology like Starcycle.

+ + + +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jaclyn Siu, Co-Founder of Starcycle, the AI COO for small businesses. Jaclyn, thank you for joining me.

+ +

JACLYN: Thank you for having me. It's so fun to be here.

+ +

VICTORIA: Great to be here with you as well. Before we get into learning more about Starcycle, can you tell me what's going on in your life outside of work that's exciting for you?

+ +

JACLYN: This is a very big departure from what I do on a day-to-day basis, but I am a huge coffee fanatic. And so, I love sampling all different kinds of coffee beans from around the world. And this morning, actually, I just finished the last cup from this amazing roastery in Osaka, Japan. They're called Mel Coffee; shout out to Mel Coffee. That's what I spend a lot of my time outside of work doing is trying different coffee beans.

+ +

VICTORIA: No, I love it. I love coffee as well. Actually, I am currently out of espresso beans. We have a fancy espresso machine maker. It's like our one big luxury in the house, and I don't have any coffee beans for it. So, I might need some recommendations from you [laughs] on what to get.

+ +

JACLYN: My sympathies on the lack of coffee, but I have plenty of recommendations. We can absolutely jam on this afterwards.

+ +

VICTORIA: Okay. Because you've traveled quite a bit, of all the places that you've been, where is the best cup of coffee that you've had?

+ +

JACLYN: I mean, I definitely have my favorites. In New York where I am currently, I would say that honor belongs to The Coffee Project. Actually, it's a tie between The Coffee Project and Say Coffee.

+ +

In Berlin, where I was based for the last seven years or so, I would say that honor goes to Bonanza Coffee. I used to go there every single day. And I attribute a lot of my success in Berlin to all the beautiful cups of coffee that they served me.

+ +

In other places, I would say what comes to mind is for sure Mel Coffee in Osaka, Japan, also, Glitch Coffee in Tokyo. In Hong Kong, that would be Craft Coffee. Hong Kong is where I'm from originally, so I have a very big fondness for any local roasteries. And I am going to stop there because, otherwise, this would become a coffee podcast, and I don't think this is what we're here for [laughs].

+ +

VICTORIA: I think there's a pretty strong coffee interest in our listeners, but they can tell me if I'm wrong. No, I think that's great, and it tells us a little bit about yourself. So, you've lived in all these different places and all these backgrounds. Maybe you can tell us a little bit about how your background led you to starting Starcycle.

+ +

JACLYN: Starcycle is my third company. I'm a three-time founder, advisor, investor, and mentor. I built my very first startup in my senior year of college, which was a men's personal styling app that surfaced shoppable outfits based on your calendar, style preferences, weather, and other things. And decided quite quickly early on, about a year in, that I wanted some real-world experience before understanding what it's like to run and build a company. I realized, hey, I need to know what it's like to be in one before I can build one.

+ +

So, I spent the next decade-plus in the creative culture and tech spaces, everything from sales and partnerships to marketing growth and operations. I worked on really exciting things from album releases for Rihanna to closing brand deals with TikTok. So, that led me to New York, to Berlin, and now back to New York, which has been really fun.

+ +

My second startup was co-founded over the height of the pandemic, and we built software for blue chip art galleries and working with them to authenticate blue chip and high-end physical art pieces. We authenticated $63 million worth of art in the company's lifetime.

+ +

The even tide of that, so towards the end of my second venture, that kind of initially planted the seed for Starcycle because we had been facing some more difficult times, and we were facing some pretty difficult decisions. I just had this Eureka moment, so to speak, where I was like, hey, I know firsthand how difficult it is to found a business. I want to use my knowledge to help at least one person get over the finish line. And I explored so many different permutations of that. I spoke to startup founders to small business owners, spent hundreds of hours exploring different ways that I could use tech to empower founders, and eventually ended up with Starcycle, which, as you mentioned earlier, is the AI COO for small businesses.

+ +

And what we do is we are supporting business owners at the mission-critical stages of their business life cycle, so the startup phase, the selling phase, which is when they're hoping to sell or get acquired, and also the shutdown phase. And so, we review and parse through key documentation and automate key operational tasks such as licensing, identifying engagement terms, drafting disclosure statements, et cetera, et cetera. So, it's very much born out of my own experience as the COO and also as an operator for many different kinds of businesses.

+ +

I grew up in a very entrepreneurial family of restauranteurs. My dad runs his own practice as a doctor. And I have cousins and other extended family members who are accountants and have their own practices. Somehow, half of my generation in my family are all startup founders now, so that has been really cool just being immersed in that, and also, yeah, wanting to use tech to give back, essentially.

+ +

VICTORIA: I love that connection with your family and how that mindset is a part of your culture and who you are. It's really interesting to hear and replay a little bit back of what you said about, you know, you knew you were entrepreneurial, but you wanted more experience. And then, you got to go through starting your own company several times. And now you're trying to share the experience you got from that with other founders.

+ +

JACLYN: Exactly. And what drew me to small businesses, really, was that startups do have quite a lot of help. Of course, we can argue perhaps a separate episode on how this support is distributed and whether or not it's equitable, but startups do tend to hog a lot of the headlines and a lot of the glamour and the glitz of being a founder.

+ +

And where I was really drawn to was the day-to-day coffee shop owners; for example, that was a big one, or just the fact that 99% of businesses around the world are considered small businesses. And I said there has to be a way to take a lot of the great tools and services that we have enjoyed as startup founders and kind of make that a lot more accessible to the people who really need it. And so, that was really the big bow on top for me to start working on Starcycle.

+ +

VICTORIA: Yeah. It's interesting to think about accessibility and inclusivity, and not just access to funding, but access to tools, access to knowledge, and support, and getting your business up and off the ground.

+ +

JACLYN: Exactly. I think the knowledge piece is a big one. And with knowledge, of course, comes support, as you say, and both of those things require a lot of hands-on education but also guidance. And one thing that I've learned over my career as an operator but also as a serial founder is how much that initial touch point really matters for folks.

+ +

And so, when I say that, I mean, just think about the very first time you encountered a new piece of technology and the feeling that inspired in you and how you felt like that new piece of tech, for better or for worse, reinforced, or not, that feeling. I've been really lucky to be at the forefront of helping a lot of people navigate these experiences, from helping fashion brands at the very beginning of my career, helping fashion brands understand social media.

+ +

This was before sponsored content was a thing. We still called them bloggers back in the day. Yeah, teaching them that social media is going to be an asset for brand marketing, and kind of being on the first wave of tech partnerships, and embracing social media as a platform, to working with artists to get them onboarded and comfortable with streaming. So, I was at Roc Nation at the time when streaming was really just starting to take off. It was the same year that Jay acquired Tidal. And so, there was a seismic shift in how the music industry as a whole was grappling with this new tech.

+ +

Fast forward to working with art galleries, probably one of the most difficult technical nuts to crack, so to speak, and working with traditionally folks who reject new technology and are wary of software that doesn't offer the same level of discretion or convenience that they are used to, and working to get them excited about software solutions that are built just for them.

+ +

And so, the through line, for me, you know, as I look back, is how can I take something scary, and intimidating, and difficult to understand for your person who is chronically offline, so to speak, and translate that into an experience that they look forward to that makes them see, "Oh, this is not just some sci-fi hubbub; it's not just what the Yahoo's at Silicon Valley are up to; this is going to help me and what I care about"? And that particular thought process, that particular intersection, is what really gets me going every day.

+ +

VICTORIA: That's really interesting. And it reminds me of friends that I have who have really deep domain expertise in certain things like nutrition, and coaching, and early childhood intervention and development. And they're asking me, someone who has, like, a connection to founders and startups, about, like, "How do I get my thing going? Like, how do I take this knowledge and build a business around it?" So, maybe you can tell me a little more about what research you're doing with these groups of people, with these small businesses. And what kind of questions are you asking, and what kind of things are you finding?

+ +

JACLYN: Sure. So, I started with a hypothesis, which was this slightly more nebulous notion that everyone will have an AI copilot. And so, I started to workshop what that could look like for a business owner, specifically because 78% of small businesses are owned and operated by one person. And my expertise or experience as a founder is having had a co-founding team where we can fill each other's gaps, and lift each other up, and work on different things. And a lot of small business owners don't have that luxury.

+ +

So, I said, okay, this is a problem that I have noticed. I am going to explore this to every single nook and cranny I can possibly find. And that led me to experiment with different ways to apply AI to this particular problem. I started looking at the early stage founding stage, where business owners are identifying their next steps to get their next big thing off the ground. They're navigating bureaucracy and figuring out what licenses they need what paperwork they need to file to make certain things a reality. And that, to me, felt like an easy place to start because it is a very well-documented and well-accounted-for space. So, we quickly shipped an early beta feature just to gauge market sentiment and to see what people were really looking for.

+ +

There really is no shortcut here, in my opinion. It's really about putting in the time and the effort to talk to everyone that is interested in finding a new solution for something that has deeply plagued them in some way or another. In a way, putting on different hats as a psychologist almost, like, understanding where their pain points are really stemming from. Is it, like, an operational thing? Is it an emotional thing? All the way to introducing them to something new, which involves reimagining what that user experience could look like, all the way to just being open and having a clear line of communication.

+ +

I talk to our users almost every day. We're on calls; we're on emails. And I just love hearing from them, and they know that they can come to me and talk to me about things. I've consulted for some of our small business owners before who come to me with different questions like, "Hey, can you help me with this business plan?"

+ +

Anyway, so, through all of those conversations, I started to stitch together a few things. The first being that AI is changing so rapidly, and, of course, this is something that is challenging but also incredibly exciting because no one really knows where it's going. We're all kind of testing out our hypotheses in real-time. We're all building towards that reality we want to see. So, noticing that a lot of co-pilot promises we were still, or at least I feel like, we're still a little bit far away from that. And so, I started examining, okay, what is AI already currently really good at and will only get better at? And how can that be applied to something that all business owners have to face?

+ +

And so, I expanded my search into other life stages of a business, and I identified that over hundreds of hours of conversations as the M&A stage and the closure stage. The M&A space is very exciting. It is also very well accounted for. And, currently, I'm spending quite a lot of time looking into the bankruptcy aspect, the end of life, something that, unfortunately, a lot of businesses will have to go through.

+ +

And yeah, really studying that space, deeply realizing that we can probably find a, if I may use this as a verb, a "turbo tax" for all of these different key operational moments for every small business, right? So, we can, quote, unquote, "turbo tax" starting a business. We can, quote, unquote, "turbo tax" trying to sell your business. We can turbo tax, closing down your life's work and trying to find a good place to put it to rest.

+ +

VICTORIA: How do you find people to be a part of the research? And how do you make sure that you're being inclusive or, you know, going after the right groups?

+ +

JACLYN: To the best of my ability. I start within my own networks. Luckily, since at this point, I have built quite a lot of friendships and relationships just within founders of all different kinds, I started by reaching out to different founders and just approached it with a lot of curiosity. I was like, "Hey, what are you working on? What is troubling you? How could I help?" And approaching it from a place of "How can I help?" as opposed to "How can you help me?" You being, of course, the founder I was speaking to. Yeah, really just being in the position of I want to learn from you, I would say, in hindsight, has been the key to a lot of folks being willing to speak with me.

+ +

And then, of course, on the call itself, when I do manage to get that scheduled, when I speak to them, and doing everything to make them feel heard, to make them feel welcomed. I show up to every single call prepared about this person. I have my questions prepared. Usually, within Calendly, for example, people should fill out what their profile kind of is. So, we do a lot of that pre-work and get that out of the way. And it also helps me prepare for the call. Weirdly enough, it's almost like preparing for a podcast interview.

+ +

And then, from those calls, I always ask like, "Hey, I really appreciate you spending time talking to me. Do you know one person who would be willing to do the same thing?" And I would say, nine times out of 10, the answer is "Yes." And then, I get a follow-up email being like, "I loved talking to you. Here's my friend who is also facing a similar thing. I already told them about our conversation. They would love to speak with you." And it just kind of flows from there.

+ +

And so, I guess to sum it all up, it really is being thoughtful with your relationships and letting that compounding effect work itself. And at this stage, like, as an early-stage founder, you and your...I don't like the word reputation, but I can't think of a better one right now. Your reputation is really what the currency is, and people typically want to help. And they also want to feel helpful, and they want you to show that they were helpful. And yeah, that has been something that I've seen a lot of success with personally, whether it's through user interviews or approaching it from, like, a sales and partnerships perspective.

+ +

VICTORIA: I agree. I think I found the same thing where, what you want to call it, and it's your reputation or your authenticity and your genuine interest in solving the problem that you're going after. I think a lot of people are, you know, of course, they want to talk about things that are bothering them, and they want to see other founders succeed, and it's part of a community. So, it's really nice to hear that's been working for you.

+ +

JACLYN: I'm so lucky that this particular thing is what really excites me about being a founder is: having that opportunity to have these conversations. Also, at this point, probably my superpower that I feel like I can draw from so many different experiences to be a good sounding board for whoever it is that I'm talking to.

+ +

And I remember this so clearly from my previous venture where we were building software for art galleries, and we had some of the most commercially successful artists and art galleries of modern times. And they went on record saying that, you know, they're switching their solutions, or they're coming on board for the first time. And they're not considering any other potential incumbents or competitors simply due to our ability or my ability to talk to them like equals, talk to them like people.

+ +

They were like, "We spoke to so many founders who were building different kinds of tech solutions for the art industry or the art world. And we always really felt kind of small talking to them because they were throwing a lot of jargon at us. They essentially wanted us to operate under a cloud of confusion so that, hopefully, we would just go along with whatever they say. And you were really the only one who would sit down, take the time to explain, take the time to hear us out, and kind of meet us where we are and see us people."

+ +

And I was really kind of taken aback by that. And I do think that advice applies generally, but especially when it comes to speaking to folks who identify so deeply with what they do, like small business owners, it is so key to really just treat them with respect. I mean, ultimately, that's really what it's about. Like, you respect that they know things that you don't, and you don't lord anything you know that they don't over them.

+ +

VICTORIA: I really appreciate that perspective. And I'm curious if maybe there are some core values from your educational background in journalism that flows through into your being a founder and how you have these conversations with people. Are there any core values that translate from that?

+ +

JACLYN: I love to listen. I'm just such a curious person. Yeah, I guess you could say that it is a journalistic approach to, you know, ask open questions and let the person feel like they are steering the conversation, and, you know, being that safe space that they know whatever it is they're saying is being taken seriously.

+ +

One of my personal philosophies when it comes to founding is that I let the problem tell me how it wants to be solved. I have a general direction, right? Like, my North Star is that I want to use tech to empower founders; in the same way, you could say that you might start writing a piece with the general idea of like, hey, this is what I want to write about. And I'm open to letting my subjects kind of steer where they really care about so that, like, I end up writing something that is compelling for everybody.

+ +

And so, yeah, I'm always open to finding the best way. This openness and curiosity, really, has led me to meet some really interesting people and dive through some very fascinating rabbit holes that I might not have done so otherwise.

+ +

VICTORIA: Oh, that's really cool. No, I like that a lot. That's super interesting.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So, in these conversations, you're having in your early discovery process, were there any points where you decided to pivot your strategy based on what you learned?

+ +

JACLYN: I would say that the most interesting point was...I think this is probably, like, the clearest example of...whether it's a pivot, or, like, a redirection, whatever you want to call it. This was before I kind of arrived at the stage of bankruptcy or the idea of bankruptcy, which is where I'm really diving deep to at the moment. I had already spoken to a lot of founders in kind of the early stage of starting the business when I was talking to them about, like, "How can a tool like Starcycle help you on your journey?"

+ +

And a lot of them were like, the ultimate milestone was, of course, to sell the business, that they want that ROI, that they want to know that, you know, something that they've worked so hard on was going to end up in great hands. And so, I started examining that side of the spectrum. So, that was, I guess, refocusing number one, which was, okay, I want to understand the buy-sell space, kind of the M&A space, to hear what success factors led people there.

+ +

I spoke to everyone I could think of on that end of the spectrum, you know, people who had sold a business, people who tried to sell but didn't sell, people who acquired a business, people in private equity who are looking to buy and operate a business, you know, different buy and sell marketplaces, so on and so forth.

+ +

And this one conversation with the head of M&A at a language company it was a nice chat. And he kind of mentioned as a throwaway, "Oh, by the way, like, one thing we also look at are distressed assets." That was it. And I said, "Okay, let's unpack that a bit," and just kind of left the rest of my questions. And we started going in that direction. And then, I realized it's a different side of the same coin, exploring M&A and closure, because they are, unfortunately, very closely related to one another. They are both on the ends, like, end of the life cycle.

+ +

And so, that one comment which might not have occurred, you know, let's say if the person didn't feel like he had a safe space to kind of open up about his process, that has sent me on another journey to really, really dig deep into this very opaque and difficult area, where I'm actually, again, really, really excited to really unpack: How can we help people at the time of need, and how can we use tech to do a lot of the heavy lifting to free them up for very emotionally taxing tasks? Which, of course does happen at that end of the life cycle.

+ +

I still very much believe in the overall idea of using AI to help small business owners end to end, but really, I found this particular wedge because I guess I was open to that. And someone dropped the crumb, and I was like, "Let's take that path. Let's talk about it. "

+ +

VICTORIA: So, it had a high emotional element there, and there's a lot of tasks associated with it that would make it a good use case for AI to support that particular phase of the life cycle?

+ +

JACLYN: Yeah, that's absolutely my hypothesis right now. I've been validating this with different small business owners who have, unfortunately, had to close their business. I'm also talking to bankruptcy attorneys. And so, yeah, I guess we'll see what that process looks like. By the time this episode is up and running, I might have found the right angle to tackle this problem, or I might have just found some other opening to look at. So, I guess it really is up for grabs at the moment, which is a very exciting part of being at the early stage, but, of course, also slightly terrifying [laughs].

+ +

VICTORIA: Well, we'll have to have you back on in a year to check in and see how things have progressed. But it makes sense to me. And in all of my recent experience just hearing from founders around San Diego, it sounds like if you're going to be a founder, you are going to have to shut down a business at least once [laughs]. Like, usually, you found multiple businesses and that means that you do have to close or, you know, go through this final action at least one time. You will be very lonely being a founder, and I can see having support through that time and having it be easy could be really helpful and make it seem, you know, easy and maybe even just, like, make it easier to start things up again, too.

+ +

JACLYN: For sure. And I love that you touched on the starting again because founders, typically, more often than not, have this very stubborn optimism that we're like, we're going to figure it out one day, and we're going to do it. And at the risk of sounding a bit hokey, bankruptcy can be a beautiful thing. It is, of course, incredibly emotionally difficult.

+ +

But what I find really incredible is the notion of bankruptcy was really born out of this idea of we recognize that you took a huge risk. And even though the risk didn't pan out in the way that we all hoped that it would, we don't want to penalize you further for having taken that risk. So, here is some protection so that when you are ready again, you can start again. And I just find that sentiment very, very powerful. And I've certainly seen that to be true in my own experience.

+ +

So, this really is, like, I feel like my heart and soul problem, you know what I mean? Again, of course, I'm back to my core value I mentioned earlier. I'm open to letting the problem tell me how it wants to be solved. And so, I'm going through that process again to find, okay, what is it in this journey that I can solve with AI? And so, yeah, we can check back in however long, maybe six months, a year or so, and then see where. I would love for you to hold me to that.

+ +

VICTORIA: Absolutely. I will. I'd love that. Yeah. And, well, on that note, then, what are the biggest challenges you see on the horizon in the next six months?

+ +

JACLYN: I would say the biggest challenge that's coming on the horizon really is, to me, what is very exciting. I alluded to this earlier, but it really is this notion that, of course, we all recognize that AI is disrupting. It has already disrupted a lot of what we know to be true. We're all just testing out our hypotheses in real-time. No one really knows in what direction this wind is blowing. I don't think people could even agree on what AGI means, right? Like, AGI, is it, like, a very, very general thing, or is it AGI for X, AGI for Y? Like, what does that look like? And I don't think there's, like, a consensus on what this looks like, right?

+ +

So, in a way, every founder building in this space, including myself, we're all just working towards what we think that reality is and what reality it is that we want to see. It's a huge challenge because we're quite literally building what has never really existed before. And it is a feeling that I'm personally, luckily, very familiar with, I get super energized by. We're in the beginning. Everyone says this, right? "We're so early," but we really, really are so early in this new wave. And I'm really looking forward to drawing on all of my experiences being at the forefront of various other big changes and applying them to this very particular change.

+ +

And then, of course, I'm also a little bit nervous about this. I think anyone would be nervous knowing that the tide could change at any moment. I'm also not delusional about this per se, but I'm definitely optimistic. I think we're going to see a lot of generational companies built at every single possible intersection of AI and something. So, it's like AI for small businesses, right? Or you could even go even more granular. There's going to be an AI for hair salons. There's going to be AI for coffee roasters. There's going to be just so many ways to capture this new energy and this revolution that I am very intimidated, but I'm really excited about this.

+ +

VICTORIA: So, the gravity and the size and scope of the change, and that being unknown, and also what you mentioned on the tech stack, having that variability and just knowing you might have to pivot or change very quickly, is an exciting challenge as well.

+ +

JACLYN: It is. It definitely is. And, of course, it's a tough one to solve for sure. Any founder who wants to build something, really now is the time to just give it a shot because there are so many intersections up for grabs, and that doesn't come around very often.

+ +

VICTORIA: That's really great. And I love your approach to that by just trying to see how can you use your expertise and follow the problem and see what solution comes up that is worth focusing on? So, I really appreciate you sharing that. I'm curious if you know what success looks like six months from now or even five years from now for Starcycle.

+ +

JACLYN: I would say in six months, I would envision, at this stage, having maybe a small suite, but a suite nonetheless, of different aspects of the small business life cycle, the mission-critical stages I spoke about, having the, quote, unquote, "different turbo taxable features" live. And so, we're already able to start really moving the needle for these folks. We have our first test feature live in beta. We're already helping close to 1,200 business owners. So, I'm really looking forward to just increasing that number.

+ +

In five years, I would really love for us to be at that stage where we are helping small business owners end to end. And so, I do see AI growing at a rate or the capabilities of AI growing at a rate way faster than any of us can imagine.

+ +

So, I'm going to just throw this out there and say, in five years, I would love for Starcycle to be, like, a true AI COO on every single step of the way, like, a real strategic thought partner, executional partner for your small business that you otherwise wouldn't have. And you're in the trenches with your AI COO, and we're going to help you build the best business you possibly can. And we'll take care of your end to end. And that, I would say, is my ultimate grand vision. So, I guess let's check back and see what happens.

+ +

VICTORIA: I like that. And, you know, that's a really awesome future vision to build towards. And in the immediate term, I'm curious to ask you more about Starcycle and how AI and people work together to give leaders confidence that the COO is giving them good answers and all that.

+ +

JACLYN: One thing that we noticed while we were developing our beta and continuing to improve on our current offering is coming to the realization that we want to focus on what AI is currently already really good at and will only get better over time and, to us, that was data parsing, data optimization, formatting, data extraction. And so, that's where the next immediate stage of product development is going to go is really leaning into this data extraction aspect.

+ +

And we feel like this true thought partner; strategic partner thing will happen over time once we have, like, a lot bigger pool of data of your business to work with, where we can connect dots that you might not have otherwise been able to connect, whether it's because you physically do not have the time, or you may not have the knowledge to, let's say, comb through your monthly P&Ls to draw out certain trends in the way that AI can really do for you.

+ +

So, we're acknowledging the current limitations of AI while maintaining optimism on kind of the long run of what we think AI is going to do. And so, I think for the small business owners that we're currently supporting, we are very much on deck as humans to help them with some of the more strategic moments. And our users know that they can find us anytime. And for a lot of the more data operational action item-driven tasks that they need help with, then AI can step in fairly comfortably and help them in the majority of the cases.

+ +

VICTORIA: That sounds really cool. I like how you broke that up. Do you have anything else you'd like to promote?

+ +

JACLYN: I'm open to so many different kinds of conversations. And every single conversation is helpful. So, please reach out or sign up, try the product.

+ +

We look at every single survey. I respond to every single survey personally with follow-up questions if you'll allow them. So, I really just want to help anyone who's listening. Whatever problem it is that you're dealing with on your founding journey, I'm here to help. So, in whatever way that I can help you, please let me know. I would love to hear from you.

+ +

VICTORIA: I read in your background that also includes asking you questions about your time working with Rihanna. Is that right? You're open?

+ +

JACLYN: [laughs] Correct. I suppose. Yes. If that is of interest, we can certainly talk about it [laughs].

+ +

VICTORIA: Oh, that's great. No, I love that, the detail on that. And then, also, we didn't get to talk everything else about your background. You also have that you're an angel investor, and you also are just a general incredible mentor and coach. So, I don't know if there's anything else you wanted to share about that.

+ +

JACLYN: I think part of it is also really driven by my passion to empower folks with technology. And a lot of that component, as we've alluded to multiple times over this podcast, is the educational component. And I think I've been really lucky to be exposed to a lot of new things throughout my life. And I want to play even some small part in helping other people encounter tech in what they perceive to be a safe and gentle way. And so, that's what I'm really excited about.

+ +

I do occasionally write small checks to companies and founders that I believe in. I spend time guest lecturing at colleges and also mentoring young girls and young women. And, generally, I'm an open book if you want to ask me about how I taught myself stop motion video editing to do something for Rihanna, all the way to how on earth did you find it in yourself to do a third company. I just want to help anyone and everyone who wants to make that difference in the world to be that difference that they're looking for.

+ +

VICTORIA: Yeah, you know what always gets me excited about tech? Is when people use tech to solve simple problems that helps everyday people. You know, I'm from Washington D.C. I spend time on the side from doing consulting with big federal agencies. I was helping startup nonprofits that were working to end homelessness and solve communication problems with nonprofit organizations sharing their services to people who needed them and that type of tech.

+ +

And I've been in California now for three years, and I've started rebuilding my networking here. And I'm starting to find those people who are working on those kinds of projects. So, I'm really excited to build a little community here in San Diego and to start giving back to some of those groups again.

+ +

JACLYN: Yeah, that's really, really awesome. And that really is what keeps drawing me back to founding is knowing that whether it's founding a non-profit initiative, or a startup, or opening up a coffee shop, like, I keep coming to coffee shops because, of course, I have a deep appreciation for them. But, ultimately, it really is such a tangible way to provide and to give back. And I can't quit.

+ +

VICTORIA: I mean, I could quit. I could quit and just, like, rock climb and be bad at surfing for the rest of my life, but I won't. But yes, thank you so much for taking the time to be with us here today, Jaclyn.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on thoughtbotsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido chats with Jaclyn Siu, the co-founder of Starcycle, an AI platform designed as a COO for small businesses. First, Jaclyn describes her entrepreneurial journey and what led her to Starcycle, detailing her earlier ventures, such as helping to scale a men's styling app and a software platform for authenticating high-end art.

+ +

Her ultimate goal is to make the tools and experiences typically reserved for startup founders accessible to small business owners, who comprise most of the global business ecosystem. She outlines how Starcycle supports crucial phases in a business’s lifecycle—start-up, sale, or shutdown—by automating operations and documentation, easing burdens on business owners.

+ +

Jaclyn also touches on the importance of personal connections and genuine curiosity in conducting user research and developing products that genuinely meet the needs of small businesses. She believes we can achieve this by being deeply rooted in empathy and strategically using technology like Starcycle.

+ + + +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jaclyn Siu, Co-Founder of Starcycle, the AI COO for small businesses. Jaclyn, thank you for joining me.

+ +

JACLYN: Thank you for having me. It's so fun to be here.

+ +

VICTORIA: Great to be here with you as well. Before we get into learning more about Starcycle, can you tell me what's going on in your life outside of work that's exciting for you?

+ +

JACLYN: This is a very big departure from what I do on a day-to-day basis, but I am a huge coffee fanatic. And so, I love sampling all different kinds of coffee beans from around the world. And this morning, actually, I just finished the last cup from this amazing roastery in Osaka, Japan. They're called Mel Coffee; shout out to Mel Coffee. That's what I spend a lot of my time outside of work doing is trying different coffee beans.

+ +

VICTORIA: No, I love it. I love coffee as well. Actually, I am currently out of espresso beans. We have a fancy espresso machine maker. It's like our one big luxury in the house, and I don't have any coffee beans for it. So, I might need some recommendations from you [laughs] on what to get.

+ +

JACLYN: My sympathies on the lack of coffee, but I have plenty of recommendations. We can absolutely jam on this afterwards.

+ +

VICTORIA: Okay. Because you've traveled quite a bit, of all the places that you've been, where is the best cup of coffee that you've had?

+ +

JACLYN: I mean, I definitely have my favorites. In New York where I am currently, I would say that honor belongs to The Coffee Project. Actually, it's a tie between The Coffee Project and Say Coffee.

+ +

In Berlin, where I was based for the last seven years or so, I would say that honor goes to Bonanza Coffee. I used to go there every single day. And I attribute a lot of my success in Berlin to all the beautiful cups of coffee that they served me.

+ +

In other places, I would say what comes to mind is for sure Mel Coffee in Osaka, Japan, also, Glitch Coffee in Tokyo. In Hong Kong, that would be Craft Coffee. Hong Kong is where I'm from originally, so I have a very big fondness for any local roasteries. And I am going to stop there because, otherwise, this would become a coffee podcast, and I don't think this is what we're here for [laughs].

+ +

VICTORIA: I think there's a pretty strong coffee interest in our listeners, but they can tell me if I'm wrong. No, I think that's great, and it tells us a little bit about yourself. So, you've lived in all these different places and all these backgrounds. Maybe you can tell us a little bit about how your background led you to starting Starcycle.

+ +

JACLYN: Starcycle is my third company. I'm a three-time founder, advisor, investor, and mentor. I built my very first startup in my senior year of college, which was a men's personal styling app that surfaced shoppable outfits based on your calendar, style preferences, weather, and other things. And decided quite quickly early on, about a year in, that I wanted some real-world experience before understanding what it's like to run and build a company. I realized, hey, I need to know what it's like to be in one before I can build one.

+ +

So, I spent the next decade-plus in the creative culture and tech spaces, everything from sales and partnerships to marketing growth and operations. I worked on really exciting things from album releases for Rihanna to closing brand deals with TikTok. So, that led me to New York, to Berlin, and now back to New York, which has been really fun.

+ +

My second startup was co-founded over the height of the pandemic, and we built software for blue chip art galleries and working with them to authenticate blue chip and high-end physical art pieces. We authenticated $63 million worth of art in the company's lifetime.

+ +

The even tide of that, so towards the end of my second venture, that kind of initially planted the seed for Starcycle because we had been facing some more difficult times, and we were facing some pretty difficult decisions. I just had this Eureka moment, so to speak, where I was like, hey, I know firsthand how difficult it is to found a business. I want to use my knowledge to help at least one person get over the finish line. And I explored so many different permutations of that. I spoke to startup founders to small business owners, spent hundreds of hours exploring different ways that I could use tech to empower founders, and eventually ended up with Starcycle, which, as you mentioned earlier, is the AI COO for small businesses.

+ +

And what we do is we are supporting business owners at the mission-critical stages of their business life cycle, so the startup phase, the selling phase, which is when they're hoping to sell or get acquired, and also the shutdown phase. And so, we review and parse through key documentation and automate key operational tasks such as licensing, identifying engagement terms, drafting disclosure statements, et cetera, et cetera. So, it's very much born out of my own experience as the COO and also as an operator for many different kinds of businesses.

+ +

I grew up in a very entrepreneurial family of restauranteurs. My dad runs his own practice as a doctor. And I have cousins and other extended family members who are accountants and have their own practices. Somehow, half of my generation in my family are all startup founders now, so that has been really cool just being immersed in that, and also, yeah, wanting to use tech to give back, essentially.

+ +

VICTORIA: I love that connection with your family and how that mindset is a part of your culture and who you are. It's really interesting to hear and replay a little bit back of what you said about, you know, you knew you were entrepreneurial, but you wanted more experience. And then, you got to go through starting your own company several times. And now you're trying to share the experience you got from that with other founders.

+ +

JACLYN: Exactly. And what drew me to small businesses, really, was that startups do have quite a lot of help. Of course, we can argue perhaps a separate episode on how this support is distributed and whether or not it's equitable, but startups do tend to hog a lot of the headlines and a lot of the glamour and the glitz of being a founder.

+ +

And where I was really drawn to was the day-to-day coffee shop owners; for example, that was a big one, or just the fact that 99% of businesses around the world are considered small businesses. And I said there has to be a way to take a lot of the great tools and services that we have enjoyed as startup founders and kind of make that a lot more accessible to the people who really need it. And so, that was really the big bow on top for me to start working on Starcycle.

+ +

VICTORIA: Yeah. It's interesting to think about accessibility and inclusivity, and not just access to funding, but access to tools, access to knowledge, and support, and getting your business up and off the ground.

+ +

JACLYN: Exactly. I think the knowledge piece is a big one. And with knowledge, of course, comes support, as you say, and both of those things require a lot of hands-on education but also guidance. And one thing that I've learned over my career as an operator but also as a serial founder is how much that initial touch point really matters for folks.

+ +

And so, when I say that, I mean, just think about the very first time you encountered a new piece of technology and the feeling that inspired in you and how you felt like that new piece of tech, for better or for worse, reinforced, or not, that feeling. I've been really lucky to be at the forefront of helping a lot of people navigate these experiences, from helping fashion brands at the very beginning of my career, helping fashion brands understand social media.

+ +

This was before sponsored content was a thing. We still called them bloggers back in the day. Yeah, teaching them that social media is going to be an asset for brand marketing, and kind of being on the first wave of tech partnerships, and embracing social media as a platform, to working with artists to get them onboarded and comfortable with streaming. So, I was at Roc Nation at the time when streaming was really just starting to take off. It was the same year that Jay acquired Tidal. And so, there was a seismic shift in how the music industry as a whole was grappling with this new tech.

+ +

Fast forward to working with art galleries, probably one of the most difficult technical nuts to crack, so to speak, and working with traditionally folks who reject new technology and are wary of software that doesn't offer the same level of discretion or convenience that they are used to, and working to get them excited about software solutions that are built just for them.

+ +

And so, the through line, for me, you know, as I look back, is how can I take something scary, and intimidating, and difficult to understand for your person who is chronically offline, so to speak, and translate that into an experience that they look forward to that makes them see, "Oh, this is not just some sci-fi hubbub; it's not just what the Yahoo's at Silicon Valley are up to; this is going to help me and what I care about"? And that particular thought process, that particular intersection, is what really gets me going every day.

+ +

VICTORIA: That's really interesting. And it reminds me of friends that I have who have really deep domain expertise in certain things like nutrition, and coaching, and early childhood intervention and development. And they're asking me, someone who has, like, a connection to founders and startups, about, like, "How do I get my thing going? Like, how do I take this knowledge and build a business around it?" So, maybe you can tell me a little more about what research you're doing with these groups of people, with these small businesses. And what kind of questions are you asking, and what kind of things are you finding?

+ +

JACLYN: Sure. So, I started with a hypothesis, which was this slightly more nebulous notion that everyone will have an AI copilot. And so, I started to workshop what that could look like for a business owner, specifically because 78% of small businesses are owned and operated by one person. And my expertise or experience as a founder is having had a co-founding team where we can fill each other's gaps, and lift each other up, and work on different things. And a lot of small business owners don't have that luxury.

+ +

So, I said, okay, this is a problem that I have noticed. I am going to explore this to every single nook and cranny I can possibly find. And that led me to experiment with different ways to apply AI to this particular problem. I started looking at the early stage founding stage, where business owners are identifying their next steps to get their next big thing off the ground. They're navigating bureaucracy and figuring out what licenses they need what paperwork they need to file to make certain things a reality. And that, to me, felt like an easy place to start because it is a very well-documented and well-accounted-for space. So, we quickly shipped an early beta feature just to gauge market sentiment and to see what people were really looking for.

+ +

There really is no shortcut here, in my opinion. It's really about putting in the time and the effort to talk to everyone that is interested in finding a new solution for something that has deeply plagued them in some way or another. In a way, putting on different hats as a psychologist almost, like, understanding where their pain points are really stemming from. Is it, like, an operational thing? Is it an emotional thing? All the way to introducing them to something new, which involves reimagining what that user experience could look like, all the way to just being open and having a clear line of communication.

+ +

I talk to our users almost every day. We're on calls; we're on emails. And I just love hearing from them, and they know that they can come to me and talk to me about things. I've consulted for some of our small business owners before who come to me with different questions like, "Hey, can you help me with this business plan?"

+ +

Anyway, so, through all of those conversations, I started to stitch together a few things. The first being that AI is changing so rapidly, and, of course, this is something that is challenging but also incredibly exciting because no one really knows where it's going. We're all kind of testing out our hypotheses in real-time. We're all building towards that reality we want to see. So, noticing that a lot of co-pilot promises we were still, or at least I feel like, we're still a little bit far away from that. And so, I started examining, okay, what is AI already currently really good at and will only get better at? And how can that be applied to something that all business owners have to face?

+ +

And so, I expanded my search into other life stages of a business, and I identified that over hundreds of hours of conversations as the M&A stage and the closure stage. The M&A space is very exciting. It is also very well accounted for. And, currently, I'm spending quite a lot of time looking into the bankruptcy aspect, the end of life, something that, unfortunately, a lot of businesses will have to go through.

+ +

And yeah, really studying that space, deeply realizing that we can probably find a, if I may use this as a verb, a "turbo tax" for all of these different key operational moments for every small business, right? So, we can, quote, unquote, "turbo tax" starting a business. We can, quote, unquote, "turbo tax" trying to sell your business. We can turbo tax, closing down your life's work and trying to find a good place to put it to rest.

+ +

VICTORIA: How do you find people to be a part of the research? And how do you make sure that you're being inclusive or, you know, going after the right groups?

+ +

JACLYN: To the best of my ability. I start within my own networks. Luckily, since at this point, I have built quite a lot of friendships and relationships just within founders of all different kinds, I started by reaching out to different founders and just approached it with a lot of curiosity. I was like, "Hey, what are you working on? What is troubling you? How could I help?" And approaching it from a place of "How can I help?" as opposed to "How can you help me?" You being, of course, the founder I was speaking to. Yeah, really just being in the position of I want to learn from you, I would say, in hindsight, has been the key to a lot of folks being willing to speak with me.

+ +

And then, of course, on the call itself, when I do manage to get that scheduled, when I speak to them, and doing everything to make them feel heard, to make them feel welcomed. I show up to every single call prepared about this person. I have my questions prepared. Usually, within Calendly, for example, people should fill out what their profile kind of is. So, we do a lot of that pre-work and get that out of the way. And it also helps me prepare for the call. Weirdly enough, it's almost like preparing for a podcast interview.

+ +

And then, from those calls, I always ask like, "Hey, I really appreciate you spending time talking to me. Do you know one person who would be willing to do the same thing?" And I would say, nine times out of 10, the answer is "Yes." And then, I get a follow-up email being like, "I loved talking to you. Here's my friend who is also facing a similar thing. I already told them about our conversation. They would love to speak with you." And it just kind of flows from there.

+ +

And so, I guess to sum it all up, it really is being thoughtful with your relationships and letting that compounding effect work itself. And at this stage, like, as an early-stage founder, you and your...I don't like the word reputation, but I can't think of a better one right now. Your reputation is really what the currency is, and people typically want to help. And they also want to feel helpful, and they want you to show that they were helpful. And yeah, that has been something that I've seen a lot of success with personally, whether it's through user interviews or approaching it from, like, a sales and partnerships perspective.

+ +

VICTORIA: I agree. I think I found the same thing where, what you want to call it, and it's your reputation or your authenticity and your genuine interest in solving the problem that you're going after. I think a lot of people are, you know, of course, they want to talk about things that are bothering them, and they want to see other founders succeed, and it's part of a community. So, it's really nice to hear that's been working for you.

+ +

JACLYN: I'm so lucky that this particular thing is what really excites me about being a founder is: having that opportunity to have these conversations. Also, at this point, probably my superpower that I feel like I can draw from so many different experiences to be a good sounding board for whoever it is that I'm talking to.

+ +

And I remember this so clearly from my previous venture where we were building software for art galleries, and we had some of the most commercially successful artists and art galleries of modern times. And they went on record saying that, you know, they're switching their solutions, or they're coming on board for the first time. And they're not considering any other potential incumbents or competitors simply due to our ability or my ability to talk to them like equals, talk to them like people.

+ +

They were like, "We spoke to so many founders who were building different kinds of tech solutions for the art industry or the art world. And we always really felt kind of small talking to them because they were throwing a lot of jargon at us. They essentially wanted us to operate under a cloud of confusion so that, hopefully, we would just go along with whatever they say. And you were really the only one who would sit down, take the time to explain, take the time to hear us out, and kind of meet us where we are and see us people."

+ +

And I was really kind of taken aback by that. And I do think that advice applies generally, but especially when it comes to speaking to folks who identify so deeply with what they do, like small business owners, it is so key to really just treat them with respect. I mean, ultimately, that's really what it's about. Like, you respect that they know things that you don't, and you don't lord anything you know that they don't over them.

+ +

VICTORIA: I really appreciate that perspective. And I'm curious if maybe there are some core values from your educational background in journalism that flows through into your being a founder and how you have these conversations with people. Are there any core values that translate from that?

+ +

JACLYN: I love to listen. I'm just such a curious person. Yeah, I guess you could say that it is a journalistic approach to, you know, ask open questions and let the person feel like they are steering the conversation, and, you know, being that safe space that they know whatever it is they're saying is being taken seriously.

+ +

One of my personal philosophies when it comes to founding is that I let the problem tell me how it wants to be solved. I have a general direction, right? Like, my North Star is that I want to use tech to empower founders; in the same way, you could say that you might start writing a piece with the general idea of like, hey, this is what I want to write about. And I'm open to letting my subjects kind of steer where they really care about so that, like, I end up writing something that is compelling for everybody.

+ +

And so, yeah, I'm always open to finding the best way. This openness and curiosity, really, has led me to meet some really interesting people and dive through some very fascinating rabbit holes that I might not have done so otherwise.

+ +

VICTORIA: Oh, that's really cool. No, I like that a lot. That's super interesting.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So, in these conversations, you're having in your early discovery process, were there any points where you decided to pivot your strategy based on what you learned?

+ +

JACLYN: I would say that the most interesting point was...I think this is probably, like, the clearest example of...whether it's a pivot, or, like, a redirection, whatever you want to call it. This was before I kind of arrived at the stage of bankruptcy or the idea of bankruptcy, which is where I'm really diving deep to at the moment. I had already spoken to a lot of founders in kind of the early stage of starting the business when I was talking to them about, like, "How can a tool like Starcycle help you on your journey?"

+ +

And a lot of them were like, the ultimate milestone was, of course, to sell the business, that they want that ROI, that they want to know that, you know, something that they've worked so hard on was going to end up in great hands. And so, I started examining that side of the spectrum. So, that was, I guess, refocusing number one, which was, okay, I want to understand the buy-sell space, kind of the M&A space, to hear what success factors led people there.

+ +

I spoke to everyone I could think of on that end of the spectrum, you know, people who had sold a business, people who tried to sell but didn't sell, people who acquired a business, people in private equity who are looking to buy and operate a business, you know, different buy and sell marketplaces, so on and so forth.

+ +

And this one conversation with the head of M&A at a language company it was a nice chat. And he kind of mentioned as a throwaway, "Oh, by the way, like, one thing we also look at are distressed assets." That was it. And I said, "Okay, let's unpack that a bit," and just kind of left the rest of my questions. And we started going in that direction. And then, I realized it's a different side of the same coin, exploring M&A and closure, because they are, unfortunately, very closely related to one another. They are both on the ends, like, end of the life cycle.

+ +

And so, that one comment which might not have occurred, you know, let's say if the person didn't feel like he had a safe space to kind of open up about his process, that has sent me on another journey to really, really dig deep into this very opaque and difficult area, where I'm actually, again, really, really excited to really unpack: How can we help people at the time of need, and how can we use tech to do a lot of the heavy lifting to free them up for very emotionally taxing tasks? Which, of course does happen at that end of the life cycle.

+ +

I still very much believe in the overall idea of using AI to help small business owners end to end, but really, I found this particular wedge because I guess I was open to that. And someone dropped the crumb, and I was like, "Let's take that path. Let's talk about it. "

+ +

VICTORIA: So, it had a high emotional element there, and there's a lot of tasks associated with it that would make it a good use case for AI to support that particular phase of the life cycle?

+ +

JACLYN: Yeah, that's absolutely my hypothesis right now. I've been validating this with different small business owners who have, unfortunately, had to close their business. I'm also talking to bankruptcy attorneys. And so, yeah, I guess we'll see what that process looks like. By the time this episode is up and running, I might have found the right angle to tackle this problem, or I might have just found some other opening to look at. So, I guess it really is up for grabs at the moment, which is a very exciting part of being at the early stage, but, of course, also slightly terrifying [laughs].

+ +

VICTORIA: Well, we'll have to have you back on in a year to check in and see how things have progressed. But it makes sense to me. And in all of my recent experience just hearing from founders around San Diego, it sounds like if you're going to be a founder, you are going to have to shut down a business at least once [laughs]. Like, usually, you found multiple businesses and that means that you do have to close or, you know, go through this final action at least one time. You will be very lonely being a founder, and I can see having support through that time and having it be easy could be really helpful and make it seem, you know, easy and maybe even just, like, make it easier to start things up again, too.

+ +

JACLYN: For sure. And I love that you touched on the starting again because founders, typically, more often than not, have this very stubborn optimism that we're like, we're going to figure it out one day, and we're going to do it. And at the risk of sounding a bit hokey, bankruptcy can be a beautiful thing. It is, of course, incredibly emotionally difficult.

+ +

But what I find really incredible is the notion of bankruptcy was really born out of this idea of we recognize that you took a huge risk. And even though the risk didn't pan out in the way that we all hoped that it would, we don't want to penalize you further for having taken that risk. So, here is some protection so that when you are ready again, you can start again. And I just find that sentiment very, very powerful. And I've certainly seen that to be true in my own experience.

+ +

So, this really is, like, I feel like my heart and soul problem, you know what I mean? Again, of course, I'm back to my core value I mentioned earlier. I'm open to letting the problem tell me how it wants to be solved. And so, I'm going through that process again to find, okay, what is it in this journey that I can solve with AI? And so, yeah, we can check back in however long, maybe six months, a year or so, and then see where. I would love for you to hold me to that.

+ +

VICTORIA: Absolutely. I will. I'd love that. Yeah. And, well, on that note, then, what are the biggest challenges you see on the horizon in the next six months?

+ +

JACLYN: I would say the biggest challenge that's coming on the horizon really is, to me, what is very exciting. I alluded to this earlier, but it really is this notion that, of course, we all recognize that AI is disrupting. It has already disrupted a lot of what we know to be true. We're all just testing out our hypotheses in real-time. No one really knows in what direction this wind is blowing. I don't think people could even agree on what AGI means, right? Like, AGI, is it, like, a very, very general thing, or is it AGI for X, AGI for Y? Like, what does that look like? And I don't think there's, like, a consensus on what this looks like, right?

+ +

So, in a way, every founder building in this space, including myself, we're all just working towards what we think that reality is and what reality it is that we want to see. It's a huge challenge because we're quite literally building what has never really existed before. And it is a feeling that I'm personally, luckily, very familiar with, I get super energized by. We're in the beginning. Everyone says this, right? "We're so early," but we really, really are so early in this new wave. And I'm really looking forward to drawing on all of my experiences being at the forefront of various other big changes and applying them to this very particular change.

+ +

And then, of course, I'm also a little bit nervous about this. I think anyone would be nervous knowing that the tide could change at any moment. I'm also not delusional about this per se, but I'm definitely optimistic. I think we're going to see a lot of generational companies built at every single possible intersection of AI and something. So, it's like AI for small businesses, right? Or you could even go even more granular. There's going to be an AI for hair salons. There's going to be AI for coffee roasters. There's going to be just so many ways to capture this new energy and this revolution that I am very intimidated, but I'm really excited about this.

+ +

VICTORIA: So, the gravity and the size and scope of the change, and that being unknown, and also what you mentioned on the tech stack, having that variability and just knowing you might have to pivot or change very quickly, is an exciting challenge as well.

+ +

JACLYN: It is. It definitely is. And, of course, it's a tough one to solve for sure. Any founder who wants to build something, really now is the time to just give it a shot because there are so many intersections up for grabs, and that doesn't come around very often.

+ +

VICTORIA: That's really great. And I love your approach to that by just trying to see how can you use your expertise and follow the problem and see what solution comes up that is worth focusing on? So, I really appreciate you sharing that. I'm curious if you know what success looks like six months from now or even five years from now for Starcycle.

+ +

JACLYN: I would say in six months, I would envision, at this stage, having maybe a small suite, but a suite nonetheless, of different aspects of the small business life cycle, the mission-critical stages I spoke about, having the, quote, unquote, "different turbo taxable features" live. And so, we're already able to start really moving the needle for these folks. We have our first test feature live in beta. We're already helping close to 1,200 business owners. So, I'm really looking forward to just increasing that number.

+ +

In five years, I would really love for us to be at that stage where we are helping small business owners end to end. And so, I do see AI growing at a rate or the capabilities of AI growing at a rate way faster than any of us can imagine.

+ +

So, I'm going to just throw this out there and say, in five years, I would love for Starcycle to be, like, a true AI COO on every single step of the way, like, a real strategic thought partner, executional partner for your small business that you otherwise wouldn't have. And you're in the trenches with your AI COO, and we're going to help you build the best business you possibly can. And we'll take care of your end to end. And that, I would say, is my ultimate grand vision. So, I guess let's check back and see what happens.

+ +

VICTORIA: I like that. And, you know, that's a really awesome future vision to build towards. And in the immediate term, I'm curious to ask you more about Starcycle and how AI and people work together to give leaders confidence that the COO is giving them good answers and all that.

+ +

JACLYN: One thing that we noticed while we were developing our beta and continuing to improve on our current offering is coming to the realization that we want to focus on what AI is currently already really good at and will only get better over time and, to us, that was data parsing, data optimization, formatting, data extraction. And so, that's where the next immediate stage of product development is going to go is really leaning into this data extraction aspect.

+ +

And we feel like this true thought partner; strategic partner thing will happen over time once we have, like, a lot bigger pool of data of your business to work with, where we can connect dots that you might not have otherwise been able to connect, whether it's because you physically do not have the time, or you may not have the knowledge to, let's say, comb through your monthly P&Ls to draw out certain trends in the way that AI can really do for you.

+ +

So, we're acknowledging the current limitations of AI while maintaining optimism on kind of the long run of what we think AI is going to do. And so, I think for the small business owners that we're currently supporting, we are very much on deck as humans to help them with some of the more strategic moments. And our users know that they can find us anytime. And for a lot of the more data operational action item-driven tasks that they need help with, then AI can step in fairly comfortably and help them in the majority of the cases.

+ +

VICTORIA: That sounds really cool. I like how you broke that up. Do you have anything else you'd like to promote?

+ +

JACLYN: I'm open to so many different kinds of conversations. And every single conversation is helpful. So, please reach out or sign up, try the product.

+ +

We look at every single survey. I respond to every single survey personally with follow-up questions if you'll allow them. So, I really just want to help anyone who's listening. Whatever problem it is that you're dealing with on your founding journey, I'm here to help. So, in whatever way that I can help you, please let me know. I would love to hear from you.

+ +

VICTORIA: I read in your background that also includes asking you questions about your time working with Rihanna. Is that right? You're open?

+ +

JACLYN: [laughs] Correct. I suppose. Yes. If that is of interest, we can certainly talk about it [laughs].

+ +

VICTORIA: Oh, that's great. No, I love that, the detail on that. And then, also, we didn't get to talk everything else about your background. You also have that you're an angel investor, and you also are just a general incredible mentor and coach. So, I don't know if there's anything else you wanted to share about that.

+ +

JACLYN: I think part of it is also really driven by my passion to empower folks with technology. And a lot of that component, as we've alluded to multiple times over this podcast, is the educational component. And I think I've been really lucky to be exposed to a lot of new things throughout my life. And I want to play even some small part in helping other people encounter tech in what they perceive to be a safe and gentle way. And so, that's what I'm really excited about.

+ +

I do occasionally write small checks to companies and founders that I believe in. I spend time guest lecturing at colleges and also mentoring young girls and young women. And, generally, I'm an open book if you want to ask me about how I taught myself stop motion video editing to do something for Rihanna, all the way to how on earth did you find it in yourself to do a third company. I just want to help anyone and everyone who wants to make that difference in the world to be that difference that they're looking for.

+ +

VICTORIA: Yeah, you know what always gets me excited about tech? Is when people use tech to solve simple problems that helps everyday people. You know, I'm from Washington D.C. I spend time on the side from doing consulting with big federal agencies. I was helping startup nonprofits that were working to end homelessness and solve communication problems with nonprofit organizations sharing their services to people who needed them and that type of tech.

+ +

And I've been in California now for three years, and I've started rebuilding my networking here. And I'm starting to find those people who are working on those kinds of projects. So, I'm really excited to build a little community here in San Diego and to start giving back to some of those groups again.

+ +

JACLYN: Yeah, that's really, really awesome. And that really is what keeps drawing me back to founding is knowing that whether it's founding a non-profit initiative, or a startup, or opening up a coffee shop, like, I keep coming to coffee shops because, of course, I have a deep appreciation for them. But, ultimately, it really is such a tangible way to provide and to give back. And I can't quit.

+ +

VICTORIA: I mean, I could quit. I could quit and just, like, rock climb and be bad at surfing for the rest of my life, but I won't. But yes, thank you so much for taking the time to be with us here today, Jaclyn.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on thoughtbotsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jVVbPwiX + + ]]> + + Victoria Guido + + + 528: AI in Action—How Fireflies Transforms Meeting Productivity + https://podcast.thoughtbot.com/528 + c5237637-9090-4e8c-a7dc-9bf4a2090589 + Thu, 06 Jun 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Victoria Guido interviews Krish Ramineni, founder and CEO, about the evolution of Fireflies, an AI meeting assistant that transcribes and summarizes meetings in multiple languages. Krish talks about the rapid advancements in AI models, democratizing AI technology, and its potential to enhance productivity and enable small teams to achieve large-scale impacts. They also explore the future of work with AI, emphasizing the importance of adaptation and addressing challenges like data security and compliance. + 41:48 + no + + + Host Victoria Guido interviews Krish Ramineni, founder and CEO of Fireflies, who provides insights into the evolution of Fireflies. This AI meeting assistant transcribes and summarizes meetings in multiple languages. He explains the rapid advancements in AI models that have allowed Fireflies to expand its language support and improve its transcription and note-taking capabilities. The conversation shifts to the broader AI industry, where Krish comments on democratizing AI technology, making it more accessible and practical for various applications beyond just number crunching. He emphasizes the importance of AI in enhancing productivity and enabling small teams to achieve large-scale impacts. +Victoria and Krish explore the future of work with AI, discussing the balance between job creation and replacement. Krish argues that rejecting AI is akin to dismissing essential technological advancements like email, highlighting businesses' need to adapt and embrace AI tools. They also touch on Fireflies' journey to enterprise-level adoption, addressing challenges like data security and compliance. Krish shares his optimism about AI's potential to augment human productivity and creativity, positioning AI as a transformative force that can empower individuals and organizations to achieve unprecedented efficiency and innovation. +Fireflies (https://fireflies.ai/) +Follow Fireflies on LinkedIn (https://www.linkedin.com/company/fireflies-inc/), Facebook (https://www.facebook.com/firefliesapp), Instagram (https://www.instagram.com/firefliesai/), YouTube (https://www.youtube.com/channel/UCZHSvxWARx0TRK77t1AbY0A), or X (https://twitter.com/firefliesai). +Follow Krish Ramineni on LinkedIn (https://www.linkedin.com/in/krishramineni/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: + AD: +We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. +Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Krish Ramineni, Founder and CEO of Fireflies. Krish, great to be here with you. +KRISH: It's great to be here. Thanks for having me. +VICTORIA: Wonderful. Before we dive into what Fireflies is all about and start talking about AI, just in your personal world, what are you learning right now? +KRISH: Well, I'm traveling this summer, and I've always wanted to speak multiple languages, both for functional reasons and to be able to actually enjoy my travel experiences. So, I'm trying to learn Spanish. I took three years in high school, but I forgot everything, and I'm trying to pick that up. I'm also trying to learn Hindi. We have teammates that are in both Latin America as well as India. And so, both of these would be really valuable [chuckles] to learn. I probably need to get a tutor, something that I'm working on right now. +VICTORIA: Yeah. How are you learning? Are you using an app? You said you might get a tutor. +KRISH: Yeah. I started looking at Duolingo. I started doing flashcards. There are online instructors. So, I'm just trying to learn the quickest way possible so that I can get just the basic, common phrases down that I could understand so that I can ask questions and understand what people are saying when they're giving me directions on the streets. So, that's the plan. I don't expect to be a fluent speaker. You know, I always wondered, too, like, since we work in this AI space, if we could build a tool that, in real-time, could translate what I'm saying into the local language and the local language into English using my voice. That would be pretty cool. +So, I think our whole mission is around like, eliminating communication barriers. But as I've been trying to learn new languages, this is something I realized is...it's a big world out there, and a lot of people in the U.S. only know one language, whereas people in other countries know multiple languages. And yeah, something that I didn't really appreciate growing up or being in high school. But now I'm realizing, like, the immense benefits of being able to speak multiple languages. So, I'm trying [laughs]. +VICTORIA: Right. And I think the benefits even to your brain health and your way of thinking is really exciting. I also learned Spanish from a really young age and grew up with it. And recently, you know, I moved to San Diego, so I have a lot more exposure to people who are just speaking Spanish all the time and getting to overhear little bits of conversation, or at a restaurant, even though right now I usually end up ordering incorrectly [laughs] and getting a little bit of surprise. But it's, like, really sweet to be able to connect with people in the community at that level. +And last year, I went to Japan for a conference for Ruby, and I learned just a little bit of Japanese. And it just made me so happy, for some reason, to be able to say even a couple of words and a couple of phrases and to have other people, like, say that I was doing a good job [laughs]. You know, like, it's just really nice, especially if you're traveling a lot, and you want to actually connect to people to be able to share that language. +Yeah, it's interesting about AI translating there. I will say the translators that we had in Japan they may be caught about 60%. Like, you know, and then with context, it was quite difficult. So, yeah, I'd be curious how AI could address that and even get more personal and being able to use a voice and added more information into that, so you get that full translation. +KRISH: Yeah. Local languages and, like, the common phrases. So, for example, the Spanish that's spoken in Spain is going to have different phrases than the ones spoken in Mexico or in other places, right? So, that's also really interesting to think about how local dialects, accents all play into it. +Growing up, I used to love watching Bollywood Indian movies, and I would need subtitles. And I slowly started to get to a place where I can still understand what's going on without subtitles. It's really interesting that some of those jokes and some of the things that are said don't really translate exactly into English, right? Like, someone that's a native English speaker wouldn't quite get it. There's a lot more to language than just the words that are used. It's like the culture, the phrases, the people. And so, that's the beauty. That's the beauty of this world. There's so much diversity. +VICTORIA: So, I'm curious. As a founder of an AI app that takes recordings of people's meetings and turns it into summarized language, are the models based primarily on English, obviously, right away? And how are you thinking about incorporating other languages into your model? +KRISH: When we started, it was primarily English. Fireflies would take notes in English. It would transcribe English meetings. And then, this past year, we started support for 60 different languages, including Spanish, French, German, Hindi, and so many more. And on top of the transcription, we now can also do AI note-taking in some of these other languages. So, if you have a meeting in Portuguese, the summaries and notes will be in Portuguese. +We have a big global presence today with Fireflies. It's used in over a hundred countries and lots of different languages. And I would say the foreign language segment of our market is growing incredibly quickly. And we also hear requests from people where they have people that speak different languages because they have global teams in meetings. And it would be super helpful to be able to translate and transcribe and so that when they look back, they can get help and understand or clarify certain things. +Yeah. I think language when we started, and most of these LLMs (large language models) were primarily built around English, right? Especially transcription and speech. But there are companies coming out that are now building these models that give better representation to other languages. And we will have AI that will be able to understand and speak many different languages. And just the rate at which this technology is changing, I'm super impressed. +I read somewhere that they were building a model back in the day before the whole ChatGPT, where they were using reinforcement learning and transfer learning, where they were able to teach it one language. And it was able to quickly pick up another language, even though it wasn't taught to them. So, AI works in very magical ways [laughs]. +VICTORIA: That's really cool. I wish that I worked that way with Portuguese because I was like, oh, I know Spanish okay sometimes. And then, I was like, but Portuguese when I read it, the words make sense, but then hearing it, the pronunciation being totally different, it's like [laughs] a long way to go. But that's really interesting. And you've already started to talk a little bit about the changes in the industry and what you're seeing as the new capabilities for AI. Can you tell me more about that? What other changes do you see in the industry in the last, like, year or even, like, a couple of months? +KRISH: At least in the last two years, people's perception of how hard it is to deploy AI has changed. Before, you needed to have a PhD. You needed to write a lot of code, and the AI was not practical. Now, AI is just a few lines of code. You don't even have to be technical to deploy AI. And you can ask it to do a lot more than crunching numbers, and that's what's so powerful. And we are getting these generalized models where, in the past, if you had, like, an AI model, it could do one thing like classification or sentiment analysis. +Right now, I have AI that can give me French poetry. It can generate images. It can summarize things. It can help me have a conversation with it and learn how to improve my speaking skills. AI is trained on the web, right? And whatever is on the web, it's a reflection of that. So, that also comes with the good and the bad. The good being that it knows what most humans feel and think and can relate to. And the bad, though, is there's a lot of nonsense on the web, so a lot of the bias, a lot of the information that it's getting. +AI today can, with confidence say the wrong answer and believe that that is the right answer. So, that is one of the risks. Some people call this hallucination, where the AI goes haywire and wonky. But I'm hoping that with time, that does get solved; we have better guardrails and parameters. Some people will say that hallucination is a feature and not a bug because it's letting the AI be more expressive. But everyone's understanding of truth should not be, I think, different. Like, I think there is one set of truth sometimes, and you don't want the AI to misinterpret that. +So, yeah, I think it's an exciting time. And more people like our company are embracing and adopting AI into their core products. And it's causing incredible productivity gains. But it's nowhere perfect. People talk about this AGI, (artificial general intelligence). I think we're a little bit away from that, but we're moving fast. Like, this stuff is happening at an exponential rate. +In technology, there was this Moore's law, right? With the number of transistors and how amazing and exponentially better the chips got. We saw that with storage, right? The cost of cloud storage when it first came out was so expensive. Now it's super cheap. If you remember, back in the day, you got, like, a USB card where it could probably store, like, 10 megabytes. Now it can do, like, 10 gigabytes to, like, one terabyte. And the cost is, like, super affordable. +If you think about TVs that came out in the past, right? Like, getting a 60-inch TV was super expensive. Like, a 40-inch TV was super expensive. Now everything is, like, LCD. You get, like, 60, 70 inches. And the price is the same as what a 40-inch TV was back then. +So, AI is all of that and some more. It's moving at a rapid pace. Like, technology, as an industry, like, it's moving so quickly, and AI is moving more quickly than what most people can keep up with. So, that has pros and cons. We can dive into that more. But, yeah, things are changing on a weekly basis, not on a yearly basis right now. +VICTORIA: Right. And there's a few directions we can go in from there, I think, that are really interesting, right? There's, like, the future of work with AI because I can relate to a feeling of fear and anxiety about what is this new technology? Am I going to lose my job? And when I talk about it with people I'm mentoring, I try to position it more as this is going to change the way we work. You're still going to need people to do stuff. +But if you're rejecting AI because you think it's just a fad or it's just silly, like, I think it is fundamentally changing the way people are going to do their jobs if you pursue that. And I think if you're capable with using AI as a tool, you're going to be more powerful than you've ever been in your job in most cases. +KRISH: Rejecting AI is like someone rejecting email for faxing and sending paper mail by hand. You just cannot compete, right? Imagine if you were a business that said, "I don't believe in AI. I'm going to do everything old school." You'd be like, today, okay, cool. You should do that. And imagine if you're a business today that says, "I don't use email. I will physically mail everything to you handwritten." So, that's what it's going to be like in a few months to a year. Like, this stuff is happening quick. +And I always like to say that AI will it create more jobs? Yes. Will AI replace jobs? Yes. But the probability of someone using AI who will replace you is far greater. So, AI isn't going to replace you as much as someone using AI is going to replace you. It's a skill set that we have to all learn, just like how we had to learn to use a computer, to use the internet, to use the smartphone. This is the same thing here. Like, we're going to all have to learn to use it and learn to interact and gel with AI in the workplace. +VICTORIA: Absolutely. And how does that relate to what you learned in your journey with Fireflies and talking to people about AI? How have those conversations gone forward? +KRISH: Fireflies at the core is this AI meeting assistant that joins your meetings. It takes notes. It helps you remember what was discussed before a meeting, during a meeting, and after a meeting. It helps me recall any information that I talked about. If we met six months ago and I'm meeting you again, it has the notes for me. It lets me search back through it. It lets me ask it questions about what you talked about. What were the next steps? What were the action items? +So, it's giving me structure to my life because a lot of my life is having meetings with lots of people and having many conversations, and then recalling those conversations and staying on top of that. It gives me structure in terms of what I do day in and day out. +I always believe that work originates from conversations. Meetings are some of the most valuable conversations that we tend to have. It's also very expensive for an organization to have meetings. Because when you get four people in a room who are all making six figures and spending an hour having meetings, that information, whatever is discussed, can have a huge cost to the business. But it can also have a huge potential to move the business in the right direction. So, organizing all of that knowledge that originates from meetings was the initial vision of Firefly. +Before all of this AI and ChatGPT hype, that was what we'd set out to do. The LLMs and AI help us do that job better: summarize the meetings better, generate better action items, create meeting outlines, allow you to search back. Instead of searching by keywords, you can now ask specific questions and talk to AI. So, this is what AI enables people to do, especially with Fireflies, is you can now interact with Fireflies like you would with a teammate, and that has changed the way people feel and use our product. +And people don't come out and say, "Hey, you're replacing secretaries. You're replacing the intern that I've hired to take notes for me. Like, you are replacing the job that the new hire has to do because it's a rite of passage." 95% of people will not make that argument because it's actually silly because your assistant, your interns, your new hires have better things to do. And these are the mundane, monotonous stuff that you should delegate to AI. Obviously, you can have humans review all of that, have their own, you know, take on it, generate reports. But it's actually leveling them up to be more productive and be more valuable to your organization. +So, I think there's a lot of pieces of AI that will do the same. You know, other technologies like, for example, AI that generates images or graphic designs that's not going to replace the graphic designer. It's going to allow the graphic designer to be able to create many iterations, be more creative. Like, if they don't have the technical skills to use certain pieces of software, it can help them ease that barrier to entry and give them more assets to work with. So, I think of AI in the workplace as how can we augment human productivity by giving each and every person a superpower? +VICTORIA: And you started this eight years ago now. So, you were really, like, ahead of the curve in terms of all these AI companies coming out. I'm wondering, what challenges did you have early on, and how did you overcome them? +KRISH: When we started, this was not obvious, like, that we should be doing this. It sounded obvious to us. We felt like every person in the workplace deserved an AI assistant that takes notes, not just the C-suite who, has a secretary or a business admin. And it felt like it's so obvious. It should exist. We should build it. And we need to create the experience like an assistant that follows you around. +But when we started, there were so many uncertainties. Can this technology work? Can this technology scale? Is the transcription going to be accurate? Can you actually even summarize things? And does that stuff make sense? It's a new behavior. Are people willing to entertain AI assistants and meeting assistants? So, every step of the way, there's a technology risk, a go-to-market risk. You are doing a sales risk. Like there are so many like pieces to the puzzle that you have to figure out. And you have to peel each layer of the onion and get to the core. So, I think it's been quite a journey. +We've been lucky in a few ways, right? Because I do believe that luck is sometimes about being at the right place at the right time. But those that always keep showing up are going to be able to get lucky from time to time, right? If you take a thousand shots, at least one of them will make it. That was my philosophy. We tried. We built seven or eight different products that all somehow worked or utterly flopped. And eventually, we got closer and closer and closer to the truth of what customers needed. And that led us to build the version of Fireflies that exists today. +So, it's definitely not easy, but there were three core phases to Fireflies or three core movements that allowed Fireflies to exist. One is speech recognition and transcription fundamentally got better. It got more accurate and more affordable. Before, it was ridiculously expensive. It would take a dollar per minute of transcription, and you needed humans to do it. But these AI engines, speech engines, got better. +The second thing is when we launched Fireflies, the pandemic happened a few weeks later. Everyone went remote. Video conferencing became more mainstream, and people were actually having Zoom fatigue and way too many meetings. And they needed a way to organize all those meetings they're having, jumping from one meeting to the next. And Fireflies got pulled forward, and a lot of people wanted to have it in meetings and help them around. And that helped us grow exponentially, virally. To this day, Fireflies has taken notes for over 16 million people across 300,000 organizations. +And since the launch in January 2020 to where we are, the first two to three years were trial and error, right? From 2016 to 2020. We built our product in 2018, 2019, launched in 2020. The pandemic accelerated the adoption. And then, you have this new LLM wave that comes out at the end of 2021, which allowed us to make the product fundamentally more valuable. And everything got better from the notes, to the summaries, to the search. Everything got better. And we crossed the chasm from where people thought, "Huh, this is a cool idea, but I don't think it's going to work," to "Holy crap, this is one of the best use cases for generative AI and LLMs." +And yeah, like, it was luck in terms of being there when this movement was happening. I think a lot of AI companies can say that. But it also took a little bit of fortitude to be able to be doing this several years before the stuff came out, right? Once a gold rush occurs, everyone's going to want to go in and then build something. But if you were already there, and you were searching and searching, and you were very close to something, and then you discover the gold rush, you're going to have a head start, and that's what happened with us. +VICTORIA: Yeah, you said 7 to 8 product iterations, and I was like, uh, you really had to go through an emotional roller coaster, I'm sure early days. But you were lucky enough to be in the right place at the right time and have a good picture of what the problem space was. It's really incredible to hear that. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +VICTORIA: Why don't I move forward a little bit into where you are now, where you have GDPR and SOC 2 compliance, and you're, you know, really doing well. Like, what were the challenges in getting that product to enterprise level? +KRISH: We let the customers pull us in the direction that needed for us to go. A lot of times, we try to see, okay, what is every friction point along the way? What would it take for larger organizations to adopt it? There is incredible product value. People have been saying it. But I need these sorts of features and capabilities in order to deploy it inside my organization. And we are handling meetings, which is sensitive. And so, we have to be able to give them more access controls, give them more admin features. +You know, we have a policy at Fireflies where we say, "We do not train on your data by default." So, most AI companies they're using their customer data to train models. We do not do that. So, we made that explicitly clear. CIOs love hearing that because when they look at us and other potential competitors, those competitors are bragging outside, saying, "Hey, we built this amazing model training on all of this data." And we say, "We don't do that." So, unless you want us to build something custom for you, we will not train on your data by default. +The other thing we said is, "Look, you own your data. If you want to delete it anytime, you can. You can request to have the data deleted. If you were a participant on a meeting and you don't feel comfortable with the data, you can request the host to delete it, or you can come to us, and we'll delete that data for you." Like, you have rights to that. And we put everything in a very customer-centric worldview, and that usually aligns with the big enterprises. That aligns well with a lot of the folks that want to use your service. +Because when you're using a new technology, the first question people are going to have is, "Does it work?" The second question they're going to have is, "Is it safe?" And with AI, a lot of people think about the safety of using the tech. And when you're building for a B2B enterprise, we had to make sure we put in the hard work to tailor our product to the needs of those customers. +VICTORIA: That's really interesting. And maybe you could say more about why would a company want to train a model on their own data and create an LLM like that? +KRISH: Are you talking about customers wanting us to train something for them? +VICTORIA: Yes. I've heard this idea from a few different people, actually, where they want to be able to build an LLM and build a model based on a company's own knowledge and their own information. So, maybe you could say more about that. +KRISH: I think it's really around fine-tuning and personalizing the AI. Now you can train on models. You can do fine-tuning. You can do other parameters. But it's really giving everyone their own personal experience with AI. We can do this today even without training just by understanding your preferences, and we want to continue to build towards that. +So, yeah, we believe that every person inside an organization should have their own personal AI note-taker, and no two meeting notes will be the same because each set of notes is unique to you, your meetings, what your team wants. And so, that, to us, is like a vision we try to build towards. AI can bring about insane level of personalization, and that's one of the reasons why people would want to train their own models based on their like, knowledge graph, and information. +VICTORIA: How do you think about the cost of building and running these AI tools from an infrastructure cost perspective? How does that translate to your cost for your customers, that kind of thing? +KRISH: AI is expensive. The unit economics...I think a lot of people are taking for granted that it is insanely expensive to run these models to use a cloud provider of these AI models. Some people are spinning up their own models. It is insanely expensive. But the good news is the cost is going down at an accelerated pace, and it's just up to whether the pace of the cost decrease will outweigh the amount of spending some of these startups are doing. And that's why some of these companies are raising tons of money as well because they don't really have a monetization strategy. They have no revenue. They're making lofty goals that "This AI is going to do this. It's going to do this. It's going to replace this function in your org." +But who's going to pay for it? How are you going to make people pay for it? Is it going to be subscription-based? Is it going to be utility-based? How much upfront cost is going to be there to train these models? And what if you do all that work, and then you deploy an LLM; you're an infrastructure provider, and no one cares? What if you're an application layer, and you're giving all of this stuff away for free and then eventually realize you can't get people to pay for it? +So, there are so many open questions for these companies where the technology is changing quickly. The cost is changing quickly, and consumer preferences are also changing quickly. We'll have to see. Only time will tell because there's a hundred companies out there, all raising a hundred million dollars. We know that all of them are not going to make it, a few are. So, it'll be interesting to see what happens once the dust settles. But I think people should take that very seriously because you can't always expect to be bailed out by investors if you don't know how to utilize AI and how to build for cost. +And I think a lot of investors tell startups to not worry about that. They say, "Don't worry about the cost. You know, as long as someone's there to pump you money, you just keep building, like, the best product out there." That works for some companies. I just don't believe it should be the only strategy that someone should take. +VICTORIA: What if you build it and no one cares? It'd be so heartbreaking [laughs], but it happens, yeah. +KRISH: That's 95% of startups that die is because no one cares. +VICTORIA: Right. Yeah. And I'm curious, like, what other use cases do you see as being the most relevant for AI? Like, what problems does it really solve very well? I mean, note-taking, obviously, one of them. +KRISH: I'm really excited about all of these AI tools that can write code for you. And maybe they can't replace a software engineer, but could you make a developer 10x more productive? And could today AI start off as a copilot for writing code for you to eventually building you full-fledged apps, right? And imagine what that would do in terms of reducing the barrier for so many people to be able to create their own personal apps and tools. Easier said than done. +But I think what's really working really well, whether it's with GitHub or some of these other AI tools, is, can it actually write code for you? And I think that's a wonderful use case. It'll still need a lot more fleshing out, but I am bullish on that use case for sure. +VICTORIA: Yeah. I'm hopeful that companies will figure out how to use AI to level up engineers because right now, we have the problem of the flattening of the middle where you have really senior people who are very in high demand. And then, you have a lot of people with very little experience who really want a career in technology. So, I see that as an opportunity, but also a risk that some people will create things with AI code and sell it. And it'll just be a hot mess [laughs]. But, you know, that's kind of the risk it is even if you're paying real developers at the same time, so... +KRISH: Yeah. I think AI will take a C player and make them a B player, maybe a B player into a B plus player. And then, it can take an A player and make them, like, A plus. So, I think it just levels the playing field a little bit, eventually to a point where everyone in the org is going to get a little bit more productive. +And I also think that small teams are going to be able to do incredible things. You, as a small team will be able to compete at a larger scale with some of the bigger companies. You know, Sam Altman said maybe there's a chance that a 10-person company is going to build a billion-dollar market cap organization that goes public. So, all of those are possibilities, too. +I love the idea of solopreneurs and people that run their own, like, small businesses, you know, three to four people, super lean. Obviously, I'm in a venture-backed world, so I can't necessarily run that, but I am very excited by that potential. And I like those types of people that are entrepreneurial and don't need a lot of CapEx in order to get started. AI will allow a lot more solopreneurs to thrive. If social media created a market for people to have, like, a full-time job as influencers, I think AI can create a market for people to have full-time jobs as creators of products, goods, and services that can be managed with just, like, a few people. +VICTORIA: That is really interesting. I'm curious if you want to...let's say you're meeting a founder or an entrepreneur, and they're AI-curious, but they don't really know where to get started or how to step their toe into the water. What advice would you give them? +KRISH: I think the best place to start is by building and building something for yourself that you yourself would use. Try all these different AI products that are out there. Look at what's trending in the news in terms of which...every week, some new model is being deployed, some new changes are being rolled out. Google is rolling something out. Facebook is rolling out something. OpenAI is rolling out something. So, try to keep pace. It's going to be tough. +And then, go play around and tinker with these tools. Like, you should be a tinkerer first. You should like to build things. You don't have to be an engineer to get started, but you need to be able to go and get your hands dirty, roll up your sleeves, and play around with these tools. The belief and conviction comes with you yourself gaining experience through understanding these tools. You know, you can't tell someone, you know, how to make a music video or make a movie without ever having used a camera before, right? So, it's the same way. You've got to learn how to use the tools first. +VICTORIA: And are there any yellow or red flags you would tell people to watch out for if they're thinking about AI or thinking about using a new AI product? +KRISH: I think for those founders that want to build large venture-scale businesses, and they're trying to bite off way more than they can chew, you should consider focusing. These are the sort of folks that maybe are not making a sequence of bets. They're trying to throw a hundred darts and see what sticks. And I usually think that's a strategy that will fail. +You need to understand why you're building, what you're building, who you're building for. Don't just build it because the technology is cool. You know, not to pick on any products out there, but there's a lot of hardware devices coming out recently that have AI backed into them, right? And you wonder, why the heck is this a hardware device? Couldn't this be just an app on my phone? Like, why do I need to go spend $200, or $600, or $1000 buying this device that has a lot of limitations? +The reason you built it because you thought the technology was cool. But by the time it got to production, it has a lot of faults. And you're trying to get people to change their behavior and take money and pay for this? That's tough. And I think VCs are falling for that as well, like, in funding tons of this money into these sorts of companies. Some can argue that it will get better with time and iterations. +But I personally stay away from hardware. I don't want to touch anything related to hardware right now because we don't even know what the new form factor is going to be. But the hardware people should ask themselves, "Should this be a standalone device, or could it just be something on my iPhone as an app?" That is something that's really, really interesting. +The space that I'm most excited about outside of AI for the workplace is robotics. And I've been seeing a lot of really cool products where they're trying to build these AI humanoid-like robots that can do a series of tasks. They're not like the machines in, like, an industry or a factory. But they can make you coffee. They can clean the dishes. They can cook you some food. I think the market for that is massive. Like, if that stuff works, people are going to be able to pay a lot of money for it. Like, the amount you'd pay for a car, you would pay for a utility-based robot inside your house and, like, with nice financing options and stuff. So, whoever cracks that is going to be really, really successful. +There's people companies that have raised a lot of money solving that. While I'm generally not bullish about hardware little devices, I am very bullish about, like, these general-purpose robots that I think the potential is immense. Like imagine every household having one or two of those; what that means for domestic productivity, like, someone's folding the laundry, someone is cleaning up the house, taking out the trash. These are jobs to be done, yeah. +VICTORIA: Well, then what would my husband do [laughter]? I'm just kidding. I don't want to replace him. No, I think it's interesting especially just, like, thinking about elder care, and having someone in the home, and watching, and cleaning up, and all of those tasks and being able to live independently. I could see that having a huge potential. So, also, obviously, I think robots are cool. It's the title of the podcast. So, I'm very pro-robot [laughs] in most cases, not all cases. Yeah. Well, that's super interesting. Let's see. Do you have anything else that you would like to promote? +KRISH: You know, besides embracing AI and using, you know, these tools and services, I would really be excited to hear about people's ideas on, like, how they're using AI in the workplace. Everyone has so many creative ways to go about it. So, each week, we discover new ways people are using Fireflies, right? Some people use it for taking notes. Some people use it to be able to take customer quotes from calls. So, they can literally ask our AI, "Hey, go through these, like, past two customer calls and pull out all of the nice things they said about us, and then turn that into a soundbite that I can share with my marketing team so we can run a marketing campaign on that" So, there's just so many interesting use cases. +I do want to say that voice is going to be a great form factor for AI. We work in the voice space. Like, I love talking to my AI during the meeting. So, I think that's going to be something that I would say is if you are an end user in the workplace, think about how you would use voice to get work done and turn your words into AI. And we're trying to solve that at Fireflies. And if you are interested in that space, we would love to talk to you. And if you have some interesting use cases that you want to see for Fireflies, please send them our way. +VICTORIA: I love that. And it's interesting when you bring up voice. One thing I was surprised about with my parents, actually, obviously, a generation older, I got them an Alexa Dot that I got from a conference. I didn't think they would ever use it, but they actually use it all the time. They're, like, asking for recipes, setting timers, and doing things like that. And, yeah, if you have, like, an AI voice, like, "Send an email to this person" or, like, "Open this task and do it." Maybe I would actually get some more tasks done [laughs]. I could just do it over voice. Sometimes like, the keyboard and the screen is part of the delay. That's really interesting. Thank you so much for being on the podcast. +Do you have any questions for me before we sign off? +KRISH: I'm curious to hear your thoughts on what are the biggest risks with AI you foresee for people, and what makes you more skeptical about AI? +VICTORIA: Yeah, you touched on a little bit earlier when you said about the cost of AI and the cost-benefit analysis; I don't think is always there for every single use case, right? There are some use cases where it is so clear there is a benefit for that. Note-taking is one of them. There's a million professions, I think, that would benefit from having AI note-taking apps. +I think the risks which we've already seen that impact people, you mentioned the biases, and things like people getting denied health care, getting longer prison term sentences. You know, the way that they might blindly incorporate these algorithms into decisions that really reinforce biases because of this historical data that it's based on. +I think whenever someone asks me about the risks of AI and, like, people losing jobs, or, you know, rogue AI taking over the world, I always bring it back to that some AI is already hurting people, and it should be stopped, and people should be educated on it. Like, the big scary AI conversation is almost a distraction to what's really going on, and we need to all be smarter about it. +At the same time, I love using AI. I think it really can, like you said, get your productivity up 100%. In some cases, like, you can just do so much more so much faster. And I see that potential. And I think that there's always that balance, right? Like, you have to be able to be aware and embrace both if you're going to stay current. But there are some people who still send faxes and still do everything by mail. But, you know, it's like technology never really dies. There's just more of it in different ways, right? +KRISH: Absolutely [laughs]. That's awesome. Well, thank you. This was great. +VICTORIA: Wonderful. Yeah, I really enjoyed our conversation. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + AI, artificial intelligence, AI automation, AI note-taking, Fireflies.ai, Krish Ramineni, language learning, Duolingo, Victoria Guido, Giant Robots podcast, AI meeting assistant, real-time translation, AI transcription, generative AI, predictive AI, machine learning, AI models, business productivity, remote work, AI in business, enterprise AI adoption, data security, compliance, AI tools, technology adaptation, future of work, AI and human collaboration, language models, AI-driven insights, AI-powered workflows + + Host Victoria Guido interviews Krish Ramineni, founder and CEO of Fireflies, who provides insights into the evolution of Fireflies. This AI meeting assistant transcribes and summarizes meetings in multiple languages. He explains the rapid advancements in AI models that have allowed Fireflies to expand its language support and improve its transcription and note-taking capabilities. The conversation shifts to the broader AI industry, where Krish comments on democratizing AI technology, making it more accessible and practical for various applications beyond just number crunching. He emphasizes the importance of AI in enhancing productivity and enabling small teams to achieve large-scale impacts.

+ +

Victoria and Krish explore the future of work with AI, discussing the balance between job creation and replacement. Krish argues that rejecting AI is akin to dismissing essential technological advancements like email, highlighting businesses' need to adapt and embrace AI tools. They also touch on Fireflies' journey to enterprise-level adoption, addressing challenges like data security and compliance. Krish shares his optimism about AI's potential to augment human productivity and creativity, positioning AI as a transformative force that can empower individuals and organizations to achieve unprecedented efficiency and innovation.

+ + + +

Transcript:

+ +

 AD:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Krish Ramineni, Founder and CEO of Fireflies. Krish, great to be here with you.

+ +

KRISH: It's great to be here. Thanks for having me.

+ +

VICTORIA: Wonderful. Before we dive into what Fireflies is all about and start talking about AI, just in your personal world, what are you learning right now?

+ +

KRISH: Well, I'm traveling this summer, and I've always wanted to speak multiple languages, both for functional reasons and to be able to actually enjoy my travel experiences. So, I'm trying to learn Spanish. I took three years in high school, but I forgot everything, and I'm trying to pick that up. I'm also trying to learn Hindi. We have teammates that are in both Latin America as well as India. And so, both of these would be really valuable [chuckles] to learn. I probably need to get a tutor, something that I'm working on right now.

+ +

VICTORIA: Yeah. How are you learning? Are you using an app? You said you might get a tutor.

+ +

KRISH: Yeah. I started looking at Duolingo. I started doing flashcards. There are online instructors. So, I'm just trying to learn the quickest way possible so that I can get just the basic, common phrases down that I could understand so that I can ask questions and understand what people are saying when they're giving me directions on the streets. So, that's the plan. I don't expect to be a fluent speaker. You know, I always wondered, too, like, since we work in this AI space, if we could build a tool that, in real-time, could translate what I'm saying into the local language and the local language into English using my voice. That would be pretty cool.

+ +

So, I think our whole mission is around like, eliminating communication barriers. But as I've been trying to learn new languages, this is something I realized is...it's a big world out there, and a lot of people in the U.S. only know one language, whereas people in other countries know multiple languages. And yeah, something that I didn't really appreciate growing up or being in high school. But now I'm realizing, like, the immense benefits of being able to speak multiple languages. So, I'm trying [laughs].

+ +

VICTORIA: Right. And I think the benefits even to your brain health and your way of thinking is really exciting. I also learned Spanish from a really young age and grew up with it. And recently, you know, I moved to San Diego, so I have a lot more exposure to people who are just speaking Spanish all the time and getting to overhear little bits of conversation, or at a restaurant, even though right now I usually end up ordering incorrectly [laughs] and getting a little bit of surprise. But it's, like, really sweet to be able to connect with people in the community at that level.

+ +

And last year, I went to Japan for a conference for Ruby, and I learned just a little bit of Japanese. And it just made me so happy, for some reason, to be able to say even a couple of words and a couple of phrases and to have other people, like, say that I was doing a good job [laughs]. You know, like, it's just really nice, especially if you're traveling a lot, and you want to actually connect to people to be able to share that language.

+ +

Yeah, it's interesting about AI translating there. I will say the translators that we had in Japan they may be caught about 60%. Like, you know, and then with context, it was quite difficult. So, yeah, I'd be curious how AI could address that and even get more personal and being able to use a voice and added more information into that, so you get that full translation.

+ +

KRISH: Yeah. Local languages and, like, the common phrases. So, for example, the Spanish that's spoken in Spain is going to have different phrases than the ones spoken in Mexico or in other places, right? So, that's also really interesting to think about how local dialects, accents all play into it.

+ +

Growing up, I used to love watching Bollywood Indian movies, and I would need subtitles. And I slowly started to get to a place where I can still understand what's going on without subtitles. It's really interesting that some of those jokes and some of the things that are said don't really translate exactly into English, right? Like, someone that's a native English speaker wouldn't quite get it. There's a lot more to language than just the words that are used. It's like the culture, the phrases, the people. And so, that's the beauty. That's the beauty of this world. There's so much diversity.

+ +

VICTORIA: So, I'm curious. As a founder of an AI app that takes recordings of people's meetings and turns it into summarized language, are the models based primarily on English, obviously, right away? And how are you thinking about incorporating other languages into your model?

+ +

KRISH: When we started, it was primarily English. Fireflies would take notes in English. It would transcribe English meetings. And then, this past year, we started support for 60 different languages, including Spanish, French, German, Hindi, and so many more. And on top of the transcription, we now can also do AI note-taking in some of these other languages. So, if you have a meeting in Portuguese, the summaries and notes will be in Portuguese.

+ +

We have a big global presence today with Fireflies. It's used in over a hundred countries and lots of different languages. And I would say the foreign language segment of our market is growing incredibly quickly. And we also hear requests from people where they have people that speak different languages because they have global teams in meetings. And it would be super helpful to be able to translate and transcribe and so that when they look back, they can get help and understand or clarify certain things.

+ +

Yeah. I think language when we started, and most of these LLMs (large language models) were primarily built around English, right? Especially transcription and speech. But there are companies coming out that are now building these models that give better representation to other languages. And we will have AI that will be able to understand and speak many different languages. And just the rate at which this technology is changing, I'm super impressed.

+ +

I read somewhere that they were building a model back in the day before the whole ChatGPT, where they were using reinforcement learning and transfer learning, where they were able to teach it one language. And it was able to quickly pick up another language, even though it wasn't taught to them. So, AI works in very magical ways [laughs].

+ +

VICTORIA: That's really cool. I wish that I worked that way with Portuguese because I was like, oh, I know Spanish okay sometimes. And then, I was like, but Portuguese when I read it, the words make sense, but then hearing it, the pronunciation being totally different, it's like [laughs] a long way to go. But that's really interesting. And you've already started to talk a little bit about the changes in the industry and what you're seeing as the new capabilities for AI. Can you tell me more about that? What other changes do you see in the industry in the last, like, year or even, like, a couple of months?

+ +

KRISH: At least in the last two years, people's perception of how hard it is to deploy AI has changed. Before, you needed to have a PhD. You needed to write a lot of code, and the AI was not practical. Now, AI is just a few lines of code. You don't even have to be technical to deploy AI. And you can ask it to do a lot more than crunching numbers, and that's what's so powerful. And we are getting these generalized models where, in the past, if you had, like, an AI model, it could do one thing like classification or sentiment analysis.

+ +

Right now, I have AI that can give me French poetry. It can generate images. It can summarize things. It can help me have a conversation with it and learn how to improve my speaking skills. AI is trained on the web, right? And whatever is on the web, it's a reflection of that. So, that also comes with the good and the bad. The good being that it knows what most humans feel and think and can relate to. And the bad, though, is there's a lot of nonsense on the web, so a lot of the bias, a lot of the information that it's getting.

+ +

AI today can, with confidence say the wrong answer and believe that that is the right answer. So, that is one of the risks. Some people call this hallucination, where the AI goes haywire and wonky. But I'm hoping that with time, that does get solved; we have better guardrails and parameters. Some people will say that hallucination is a feature and not a bug because it's letting the AI be more expressive. But everyone's understanding of truth should not be, I think, different. Like, I think there is one set of truth sometimes, and you don't want the AI to misinterpret that.

+ +

So, yeah, I think it's an exciting time. And more people like our company are embracing and adopting AI into their core products. And it's causing incredible productivity gains. But it's nowhere perfect. People talk about this AGI, (artificial general intelligence). I think we're a little bit away from that, but we're moving fast. Like, this stuff is happening at an exponential rate.

+ +

In technology, there was this Moore's law, right? With the number of transistors and how amazing and exponentially better the chips got. We saw that with storage, right? The cost of cloud storage when it first came out was so expensive. Now it's super cheap. If you remember, back in the day, you got, like, a USB card where it could probably store, like, 10 megabytes. Now it can do, like, 10 gigabytes to, like, one terabyte. And the cost is, like, super affordable.

+ +

If you think about TVs that came out in the past, right? Like, getting a 60-inch TV was super expensive. Like, a 40-inch TV was super expensive. Now everything is, like, LCD. You get, like, 60, 70 inches. And the price is the same as what a 40-inch TV was back then.

+ +

So, AI is all of that and some more. It's moving at a rapid pace. Like, technology, as an industry, like, it's moving so quickly, and AI is moving more quickly than what most people can keep up with. So, that has pros and cons. We can dive into that more. But, yeah, things are changing on a weekly basis, not on a yearly basis right now.

+ +

VICTORIA: Right. And there's a few directions we can go in from there, I think, that are really interesting, right? There's, like, the future of work with AI because I can relate to a feeling of fear and anxiety about what is this new technology? Am I going to lose my job? And when I talk about it with people I'm mentoring, I try to position it more as this is going to change the way we work. You're still going to need people to do stuff.

+ +

But if you're rejecting AI because you think it's just a fad or it's just silly, like, I think it is fundamentally changing the way people are going to do their jobs if you pursue that. And I think if you're capable with using AI as a tool, you're going to be more powerful than you've ever been in your job in most cases.

+ +

KRISH: Rejecting AI is like someone rejecting email for faxing and sending paper mail by hand. You just cannot compete, right? Imagine if you were a business that said, "I don't believe in AI. I'm going to do everything old school." You'd be like, today, okay, cool. You should do that. And imagine if you're a business today that says, "I don't use email. I will physically mail everything to you handwritten." So, that's what it's going to be like in a few months to a year. Like, this stuff is happening quick.

+ +

And I always like to say that AI will it create more jobs? Yes. Will AI replace jobs? Yes. But the probability of someone using AI who will replace you is far greater. So, AI isn't going to replace you as much as someone using AI is going to replace you. It's a skill set that we have to all learn, just like how we had to learn to use a computer, to use the internet, to use the smartphone. This is the same thing here. Like, we're going to all have to learn to use it and learn to interact and gel with AI in the workplace.

+ +

VICTORIA: Absolutely. And how does that relate to what you learned in your journey with Fireflies and talking to people about AI? How have those conversations gone forward?

+ +

KRISH: Fireflies at the core is this AI meeting assistant that joins your meetings. It takes notes. It helps you remember what was discussed before a meeting, during a meeting, and after a meeting. It helps me recall any information that I talked about. If we met six months ago and I'm meeting you again, it has the notes for me. It lets me search back through it. It lets me ask it questions about what you talked about. What were the next steps? What were the action items?

+ +

So, it's giving me structure to my life because a lot of my life is having meetings with lots of people and having many conversations, and then recalling those conversations and staying on top of that. It gives me structure in terms of what I do day in and day out.

+ +

I always believe that work originates from conversations. Meetings are some of the most valuable conversations that we tend to have. It's also very expensive for an organization to have meetings. Because when you get four people in a room who are all making six figures and spending an hour having meetings, that information, whatever is discussed, can have a huge cost to the business. But it can also have a huge potential to move the business in the right direction. So, organizing all of that knowledge that originates from meetings was the initial vision of Firefly.

+ +

Before all of this AI and ChatGPT hype, that was what we'd set out to do. The LLMs and AI help us do that job better: summarize the meetings better, generate better action items, create meeting outlines, allow you to search back. Instead of searching by keywords, you can now ask specific questions and talk to AI. So, this is what AI enables people to do, especially with Fireflies, is you can now interact with Fireflies like you would with a teammate, and that has changed the way people feel and use our product.

+ +

And people don't come out and say, "Hey, you're replacing secretaries. You're replacing the intern that I've hired to take notes for me. Like, you are replacing the job that the new hire has to do because it's a rite of passage." 95% of people will not make that argument because it's actually silly because your assistant, your interns, your new hires have better things to do. And these are the mundane, monotonous stuff that you should delegate to AI. Obviously, you can have humans review all of that, have their own, you know, take on it, generate reports. But it's actually leveling them up to be more productive and be more valuable to your organization.

+ +

So, I think there's a lot of pieces of AI that will do the same. You know, other technologies like, for example, AI that generates images or graphic designs that's not going to replace the graphic designer. It's going to allow the graphic designer to be able to create many iterations, be more creative. Like, if they don't have the technical skills to use certain pieces of software, it can help them ease that barrier to entry and give them more assets to work with. So, I think of AI in the workplace as how can we augment human productivity by giving each and every person a superpower?

+ +

VICTORIA: And you started this eight years ago now. So, you were really, like, ahead of the curve in terms of all these AI companies coming out. I'm wondering, what challenges did you have early on, and how did you overcome them?

+ +

KRISH: When we started, this was not obvious, like, that we should be doing this. It sounded obvious to us. We felt like every person in the workplace deserved an AI assistant that takes notes, not just the C-suite who, has a secretary or a business admin. And it felt like it's so obvious. It should exist. We should build it. And we need to create the experience like an assistant that follows you around.

+ +

But when we started, there were so many uncertainties. Can this technology work? Can this technology scale? Is the transcription going to be accurate? Can you actually even summarize things? And does that stuff make sense? It's a new behavior. Are people willing to entertain AI assistants and meeting assistants? So, every step of the way, there's a technology risk, a go-to-market risk. You are doing a sales risk. Like there are so many like pieces to the puzzle that you have to figure out. And you have to peel each layer of the onion and get to the core. So, I think it's been quite a journey.

+ +

We've been lucky in a few ways, right? Because I do believe that luck is sometimes about being at the right place at the right time. But those that always keep showing up are going to be able to get lucky from time to time, right? If you take a thousand shots, at least one of them will make it. That was my philosophy. We tried. We built seven or eight different products that all somehow worked or utterly flopped. And eventually, we got closer and closer and closer to the truth of what customers needed. And that led us to build the version of Fireflies that exists today.

+ +

So, it's definitely not easy, but there were three core phases to Fireflies or three core movements that allowed Fireflies to exist. One is speech recognition and transcription fundamentally got better. It got more accurate and more affordable. Before, it was ridiculously expensive. It would take a dollar per minute of transcription, and you needed humans to do it. But these AI engines, speech engines, got better.

+ +

The second thing is when we launched Fireflies, the pandemic happened a few weeks later. Everyone went remote. Video conferencing became more mainstream, and people were actually having Zoom fatigue and way too many meetings. And they needed a way to organize all those meetings they're having, jumping from one meeting to the next. And Fireflies got pulled forward, and a lot of people wanted to have it in meetings and help them around. And that helped us grow exponentially, virally. To this day, Fireflies has taken notes for over 16 million people across 300,000 organizations.

+ +

And since the launch in January 2020 to where we are, the first two to three years were trial and error, right? From 2016 to 2020. We built our product in 2018, 2019, launched in 2020. The pandemic accelerated the adoption. And then, you have this new LLM wave that comes out at the end of 2021, which allowed us to make the product fundamentally more valuable. And everything got better from the notes, to the summaries, to the search. Everything got better. And we crossed the chasm from where people thought, "Huh, this is a cool idea, but I don't think it's going to work," to "Holy crap, this is one of the best use cases for generative AI and LLMs."

+ +

And yeah, like, it was luck in terms of being there when this movement was happening. I think a lot of AI companies can say that. But it also took a little bit of fortitude to be able to be doing this several years before the stuff came out, right? Once a gold rush occurs, everyone's going to want to go in and then build something. But if you were already there, and you were searching and searching, and you were very close to something, and then you discover the gold rush, you're going to have a head start, and that's what happened with us.

+ +

VICTORIA: Yeah, you said 7 to 8 product iterations, and I was like, uh, you really had to go through an emotional roller coaster, I'm sure early days. But you were lucky enough to be in the right place at the right time and have a good picture of what the problem space was. It's really incredible to hear that.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: Why don't I move forward a little bit into where you are now, where you have GDPR and SOC 2 compliance, and you're, you know, really doing well. Like, what were the challenges in getting that product to enterprise level?

+ +

KRISH: We let the customers pull us in the direction that needed for us to go. A lot of times, we try to see, okay, what is every friction point along the way? What would it take for larger organizations to adopt it? There is incredible product value. People have been saying it. But I need these sorts of features and capabilities in order to deploy it inside my organization. And we are handling meetings, which is sensitive. And so, we have to be able to give them more access controls, give them more admin features.

+ +

You know, we have a policy at Fireflies where we say, "We do not train on your data by default." So, most AI companies they're using their customer data to train models. We do not do that. So, we made that explicitly clear. CIOs love hearing that because when they look at us and other potential competitors, those competitors are bragging outside, saying, "Hey, we built this amazing model training on all of this data." And we say, "We don't do that." So, unless you want us to build something custom for you, we will not train on your data by default.

+ +

The other thing we said is, "Look, you own your data. If you want to delete it anytime, you can. You can request to have the data deleted. If you were a participant on a meeting and you don't feel comfortable with the data, you can request the host to delete it, or you can come to us, and we'll delete that data for you." Like, you have rights to that. And we put everything in a very customer-centric worldview, and that usually aligns with the big enterprises. That aligns well with a lot of the folks that want to use your service.

+ +

Because when you're using a new technology, the first question people are going to have is, "Does it work?" The second question they're going to have is, "Is it safe?" And with AI, a lot of people think about the safety of using the tech. And when you're building for a B2B enterprise, we had to make sure we put in the hard work to tailor our product to the needs of those customers.

+ +

VICTORIA: That's really interesting. And maybe you could say more about why would a company want to train a model on their own data and create an LLM like that?

+ +

KRISH: Are you talking about customers wanting us to train something for them?

+ +

VICTORIA: Yes. I've heard this idea from a few different people, actually, where they want to be able to build an LLM and build a model based on a company's own knowledge and their own information. So, maybe you could say more about that.

+ +

KRISH: I think it's really around fine-tuning and personalizing the AI. Now you can train on models. You can do fine-tuning. You can do other parameters. But it's really giving everyone their own personal experience with AI. We can do this today even without training just by understanding your preferences, and we want to continue to build towards that.

+ +

So, yeah, we believe that every person inside an organization should have their own personal AI note-taker, and no two meeting notes will be the same because each set of notes is unique to you, your meetings, what your team wants. And so, that, to us, is like a vision we try to build towards. AI can bring about insane level of personalization, and that's one of the reasons why people would want to train their own models based on their like, knowledge graph, and information.

+ +

VICTORIA: How do you think about the cost of building and running these AI tools from an infrastructure cost perspective? How does that translate to your cost for your customers, that kind of thing?

+ +

KRISH: AI is expensive. The unit economics...I think a lot of people are taking for granted that it is insanely expensive to run these models to use a cloud provider of these AI models. Some people are spinning up their own models. It is insanely expensive. But the good news is the cost is going down at an accelerated pace, and it's just up to whether the pace of the cost decrease will outweigh the amount of spending some of these startups are doing. And that's why some of these companies are raising tons of money as well because they don't really have a monetization strategy. They have no revenue. They're making lofty goals that "This AI is going to do this. It's going to do this. It's going to replace this function in your org."

+ +

But who's going to pay for it? How are you going to make people pay for it? Is it going to be subscription-based? Is it going to be utility-based? How much upfront cost is going to be there to train these models? And what if you do all that work, and then you deploy an LLM; you're an infrastructure provider, and no one cares? What if you're an application layer, and you're giving all of this stuff away for free and then eventually realize you can't get people to pay for it?

+ +

So, there are so many open questions for these companies where the technology is changing quickly. The cost is changing quickly, and consumer preferences are also changing quickly. We'll have to see. Only time will tell because there's a hundred companies out there, all raising a hundred million dollars. We know that all of them are not going to make it, a few are. So, it'll be interesting to see what happens once the dust settles. But I think people should take that very seriously because you can't always expect to be bailed out by investors if you don't know how to utilize AI and how to build for cost.

+ +

And I think a lot of investors tell startups to not worry about that. They say, "Don't worry about the cost. You know, as long as someone's there to pump you money, you just keep building, like, the best product out there." That works for some companies. I just don't believe it should be the only strategy that someone should take.

+ +

VICTORIA: What if you build it and no one cares? It'd be so heartbreaking [laughs], but it happens, yeah.

+ +

KRISH: That's 95% of startups that die is because no one cares.

+ +

VICTORIA: Right. Yeah. And I'm curious, like, what other use cases do you see as being the most relevant for AI? Like, what problems does it really solve very well? I mean, note-taking, obviously, one of them.

+ +

KRISH: I'm really excited about all of these AI tools that can write code for you. And maybe they can't replace a software engineer, but could you make a developer 10x more productive? And could today AI start off as a copilot for writing code for you to eventually building you full-fledged apps, right? And imagine what that would do in terms of reducing the barrier for so many people to be able to create their own personal apps and tools. Easier said than done.

+ +

But I think what's really working really well, whether it's with GitHub or some of these other AI tools, is, can it actually write code for you? And I think that's a wonderful use case. It'll still need a lot more fleshing out, but I am bullish on that use case for sure.

+ +

VICTORIA: Yeah. I'm hopeful that companies will figure out how to use AI to level up engineers because right now, we have the problem of the flattening of the middle where you have really senior people who are very in high demand. And then, you have a lot of people with very little experience who really want a career in technology. So, I see that as an opportunity, but also a risk that some people will create things with AI code and sell it. And it'll just be a hot mess [laughs]. But, you know, that's kind of the risk it is even if you're paying real developers at the same time, so...

+ +

KRISH: Yeah. I think AI will take a C player and make them a B player, maybe a B player into a B plus player. And then, it can take an A player and make them, like, A plus. So, I think it just levels the playing field a little bit, eventually to a point where everyone in the org is going to get a little bit more productive.

+ +

And I also think that small teams are going to be able to do incredible things. You, as a small team will be able to compete at a larger scale with some of the bigger companies. You know, Sam Altman said maybe there's a chance that a 10-person company is going to build a billion-dollar market cap organization that goes public. So, all of those are possibilities, too.

+ +

I love the idea of solopreneurs and people that run their own, like, small businesses, you know, three to four people, super lean. Obviously, I'm in a venture-backed world, so I can't necessarily run that, but I am very excited by that potential. And I like those types of people that are entrepreneurial and don't need a lot of CapEx in order to get started. AI will allow a lot more solopreneurs to thrive. If social media created a market for people to have, like, a full-time job as influencers, I think AI can create a market for people to have full-time jobs as creators of products, goods, and services that can be managed with just, like, a few people.

+ +

VICTORIA: That is really interesting. I'm curious if you want to...let's say you're meeting a founder or an entrepreneur, and they're AI-curious, but they don't really know where to get started or how to step their toe into the water. What advice would you give them?

+ +

KRISH: I think the best place to start is by building and building something for yourself that you yourself would use. Try all these different AI products that are out there. Look at what's trending in the news in terms of which...every week, some new model is being deployed, some new changes are being rolled out. Google is rolling something out. Facebook is rolling out something. OpenAI is rolling out something. So, try to keep pace. It's going to be tough.

+ +

And then, go play around and tinker with these tools. Like, you should be a tinkerer first. You should like to build things. You don't have to be an engineer to get started, but you need to be able to go and get your hands dirty, roll up your sleeves, and play around with these tools. The belief and conviction comes with you yourself gaining experience through understanding these tools. You know, you can't tell someone, you know, how to make a music video or make a movie without ever having used a camera before, right? So, it's the same way. You've got to learn how to use the tools first.

+ +

VICTORIA: And are there any yellow or red flags you would tell people to watch out for if they're thinking about AI or thinking about using a new AI product?

+ +

KRISH: I think for those founders that want to build large venture-scale businesses, and they're trying to bite off way more than they can chew, you should consider focusing. These are the sort of folks that maybe are not making a sequence of bets. They're trying to throw a hundred darts and see what sticks. And I usually think that's a strategy that will fail.

+ +

You need to understand why you're building, what you're building, who you're building for. Don't just build it because the technology is cool. You know, not to pick on any products out there, but there's a lot of hardware devices coming out recently that have AI backed into them, right? And you wonder, why the heck is this a hardware device? Couldn't this be just an app on my phone? Like, why do I need to go spend $200, or $600, or $1000 buying this device that has a lot of limitations?

+ +

The reason you built it because you thought the technology was cool. But by the time it got to production, it has a lot of faults. And you're trying to get people to change their behavior and take money and pay for this? That's tough. And I think VCs are falling for that as well, like, in funding tons of this money into these sorts of companies. Some can argue that it will get better with time and iterations.

+ +

But I personally stay away from hardware. I don't want to touch anything related to hardware right now because we don't even know what the new form factor is going to be. But the hardware people should ask themselves, "Should this be a standalone device, or could it just be something on my iPhone as an app?" That is something that's really, really interesting.

+ +

The space that I'm most excited about outside of AI for the workplace is robotics. And I've been seeing a lot of really cool products where they're trying to build these AI humanoid-like robots that can do a series of tasks. They're not like the machines in, like, an industry or a factory. But they can make you coffee. They can clean the dishes. They can cook you some food. I think the market for that is massive. Like, if that stuff works, people are going to be able to pay a lot of money for it. Like, the amount you'd pay for a car, you would pay for a utility-based robot inside your house and, like, with nice financing options and stuff. So, whoever cracks that is going to be really, really successful.

+ +

There's people companies that have raised a lot of money solving that. While I'm generally not bullish about hardware little devices, I am very bullish about, like, these general-purpose robots that I think the potential is immense. Like imagine every household having one or two of those; what that means for domestic productivity, like, someone's folding the laundry, someone is cleaning up the house, taking out the trash. These are jobs to be done, yeah.

+ +

VICTORIA: Well, then what would my husband do [laughter]? I'm just kidding. I don't want to replace him. No, I think it's interesting especially just, like, thinking about elder care, and having someone in the home, and watching, and cleaning up, and all of those tasks and being able to live independently. I could see that having a huge potential. So, also, obviously, I think robots are cool. It's the title of the podcast. So, I'm very pro-robot [laughs] in most cases, not all cases. Yeah. Well, that's super interesting. Let's see. Do you have anything else that you would like to promote?

+ +

KRISH: You know, besides embracing AI and using, you know, these tools and services, I would really be excited to hear about people's ideas on, like, how they're using AI in the workplace. Everyone has so many creative ways to go about it. So, each week, we discover new ways people are using Fireflies, right? Some people use it for taking notes. Some people use it to be able to take customer quotes from calls. So, they can literally ask our AI, "Hey, go through these, like, past two customer calls and pull out all of the nice things they said about us, and then turn that into a soundbite that I can share with my marketing team so we can run a marketing campaign on that" So, there's just so many interesting use cases.

+ +

I do want to say that voice is going to be a great form factor for AI. We work in the voice space. Like, I love talking to my AI during the meeting. So, I think that's going to be something that I would say is if you are an end user in the workplace, think about how you would use voice to get work done and turn your words into AI. And we're trying to solve that at Fireflies. And if you are interested in that space, we would love to talk to you. And if you have some interesting use cases that you want to see for Fireflies, please send them our way.

+ +

VICTORIA: I love that. And it's interesting when you bring up voice. One thing I was surprised about with my parents, actually, obviously, a generation older, I got them an Alexa Dot that I got from a conference. I didn't think they would ever use it, but they actually use it all the time. They're, like, asking for recipes, setting timers, and doing things like that. And, yeah, if you have, like, an AI voice, like, "Send an email to this person" or, like, "Open this task and do it." Maybe I would actually get some more tasks done [laughs]. I could just do it over voice. Sometimes like, the keyboard and the screen is part of the delay. That's really interesting. Thank you so much for being on the podcast.

+ +

Do you have any questions for me before we sign off?

+ +

KRISH: I'm curious to hear your thoughts on what are the biggest risks with AI you foresee for people, and what makes you more skeptical about AI?

+ +

VICTORIA: Yeah, you touched on a little bit earlier when you said about the cost of AI and the cost-benefit analysis; I don't think is always there for every single use case, right? There are some use cases where it is so clear there is a benefit for that. Note-taking is one of them. There's a million professions, I think, that would benefit from having AI note-taking apps.

+ +

I think the risks which we've already seen that impact people, you mentioned the biases, and things like people getting denied health care, getting longer prison term sentences. You know, the way that they might blindly incorporate these algorithms into decisions that really reinforce biases because of this historical data that it's based on.

+ +

I think whenever someone asks me about the risks of AI and, like, people losing jobs, or, you know, rogue AI taking over the world, I always bring it back to that some AI is already hurting people, and it should be stopped, and people should be educated on it. Like, the big scary AI conversation is almost a distraction to what's really going on, and we need to all be smarter about it.

+ +

At the same time, I love using AI. I think it really can, like you said, get your productivity up 100%. In some cases, like, you can just do so much more so much faster. And I see that potential. And I think that there's always that balance, right? Like, you have to be able to be aware and embrace both if you're going to stay current. But there are some people who still send faxes and still do everything by mail. But, you know, it's like technology never really dies. There's just more of it in different ways, right?

+ +

KRISH: Absolutely [laughs]. That's awesome. Well, thank you. This was great.

+ +

VICTORIA: Wonderful. Yeah, I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido interviews Krish Ramineni, founder and CEO of Fireflies, who provides insights into the evolution of Fireflies. This AI meeting assistant transcribes and summarizes meetings in multiple languages. He explains the rapid advancements in AI models that have allowed Fireflies to expand its language support and improve its transcription and note-taking capabilities. The conversation shifts to the broader AI industry, where Krish comments on democratizing AI technology, making it more accessible and practical for various applications beyond just number crunching. He emphasizes the importance of AI in enhancing productivity and enabling small teams to achieve large-scale impacts.

+ +

Victoria and Krish explore the future of work with AI, discussing the balance between job creation and replacement. Krish argues that rejecting AI is akin to dismissing essential technological advancements like email, highlighting businesses' need to adapt and embrace AI tools. They also touch on Fireflies' journey to enterprise-level adoption, addressing challenges like data security and compliance. Krish shares his optimism about AI's potential to augment human productivity and creativity, positioning AI as a transformative force that can empower individuals and organizations to achieve unprecedented efficiency and innovation.

+ + + +

Transcript:

+ +

 AD:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Krish Ramineni, Founder and CEO of Fireflies. Krish, great to be here with you.

+ +

KRISH: It's great to be here. Thanks for having me.

+ +

VICTORIA: Wonderful. Before we dive into what Fireflies is all about and start talking about AI, just in your personal world, what are you learning right now?

+ +

KRISH: Well, I'm traveling this summer, and I've always wanted to speak multiple languages, both for functional reasons and to be able to actually enjoy my travel experiences. So, I'm trying to learn Spanish. I took three years in high school, but I forgot everything, and I'm trying to pick that up. I'm also trying to learn Hindi. We have teammates that are in both Latin America as well as India. And so, both of these would be really valuable [chuckles] to learn. I probably need to get a tutor, something that I'm working on right now.

+ +

VICTORIA: Yeah. How are you learning? Are you using an app? You said you might get a tutor.

+ +

KRISH: Yeah. I started looking at Duolingo. I started doing flashcards. There are online instructors. So, I'm just trying to learn the quickest way possible so that I can get just the basic, common phrases down that I could understand so that I can ask questions and understand what people are saying when they're giving me directions on the streets. So, that's the plan. I don't expect to be a fluent speaker. You know, I always wondered, too, like, since we work in this AI space, if we could build a tool that, in real-time, could translate what I'm saying into the local language and the local language into English using my voice. That would be pretty cool.

+ +

So, I think our whole mission is around like, eliminating communication barriers. But as I've been trying to learn new languages, this is something I realized is...it's a big world out there, and a lot of people in the U.S. only know one language, whereas people in other countries know multiple languages. And yeah, something that I didn't really appreciate growing up or being in high school. But now I'm realizing, like, the immense benefits of being able to speak multiple languages. So, I'm trying [laughs].

+ +

VICTORIA: Right. And I think the benefits even to your brain health and your way of thinking is really exciting. I also learned Spanish from a really young age and grew up with it. And recently, you know, I moved to San Diego, so I have a lot more exposure to people who are just speaking Spanish all the time and getting to overhear little bits of conversation, or at a restaurant, even though right now I usually end up ordering incorrectly [laughs] and getting a little bit of surprise. But it's, like, really sweet to be able to connect with people in the community at that level.

+ +

And last year, I went to Japan for a conference for Ruby, and I learned just a little bit of Japanese. And it just made me so happy, for some reason, to be able to say even a couple of words and a couple of phrases and to have other people, like, say that I was doing a good job [laughs]. You know, like, it's just really nice, especially if you're traveling a lot, and you want to actually connect to people to be able to share that language.

+ +

Yeah, it's interesting about AI translating there. I will say the translators that we had in Japan they may be caught about 60%. Like, you know, and then with context, it was quite difficult. So, yeah, I'd be curious how AI could address that and even get more personal and being able to use a voice and added more information into that, so you get that full translation.

+ +

KRISH: Yeah. Local languages and, like, the common phrases. So, for example, the Spanish that's spoken in Spain is going to have different phrases than the ones spoken in Mexico or in other places, right? So, that's also really interesting to think about how local dialects, accents all play into it.

+ +

Growing up, I used to love watching Bollywood Indian movies, and I would need subtitles. And I slowly started to get to a place where I can still understand what's going on without subtitles. It's really interesting that some of those jokes and some of the things that are said don't really translate exactly into English, right? Like, someone that's a native English speaker wouldn't quite get it. There's a lot more to language than just the words that are used. It's like the culture, the phrases, the people. And so, that's the beauty. That's the beauty of this world. There's so much diversity.

+ +

VICTORIA: So, I'm curious. As a founder of an AI app that takes recordings of people's meetings and turns it into summarized language, are the models based primarily on English, obviously, right away? And how are you thinking about incorporating other languages into your model?

+ +

KRISH: When we started, it was primarily English. Fireflies would take notes in English. It would transcribe English meetings. And then, this past year, we started support for 60 different languages, including Spanish, French, German, Hindi, and so many more. And on top of the transcription, we now can also do AI note-taking in some of these other languages. So, if you have a meeting in Portuguese, the summaries and notes will be in Portuguese.

+ +

We have a big global presence today with Fireflies. It's used in over a hundred countries and lots of different languages. And I would say the foreign language segment of our market is growing incredibly quickly. And we also hear requests from people where they have people that speak different languages because they have global teams in meetings. And it would be super helpful to be able to translate and transcribe and so that when they look back, they can get help and understand or clarify certain things.

+ +

Yeah. I think language when we started, and most of these LLMs (large language models) were primarily built around English, right? Especially transcription and speech. But there are companies coming out that are now building these models that give better representation to other languages. And we will have AI that will be able to understand and speak many different languages. And just the rate at which this technology is changing, I'm super impressed.

+ +

I read somewhere that they were building a model back in the day before the whole ChatGPT, where they were using reinforcement learning and transfer learning, where they were able to teach it one language. And it was able to quickly pick up another language, even though it wasn't taught to them. So, AI works in very magical ways [laughs].

+ +

VICTORIA: That's really cool. I wish that I worked that way with Portuguese because I was like, oh, I know Spanish okay sometimes. And then, I was like, but Portuguese when I read it, the words make sense, but then hearing it, the pronunciation being totally different, it's like [laughs] a long way to go. But that's really interesting. And you've already started to talk a little bit about the changes in the industry and what you're seeing as the new capabilities for AI. Can you tell me more about that? What other changes do you see in the industry in the last, like, year or even, like, a couple of months?

+ +

KRISH: At least in the last two years, people's perception of how hard it is to deploy AI has changed. Before, you needed to have a PhD. You needed to write a lot of code, and the AI was not practical. Now, AI is just a few lines of code. You don't even have to be technical to deploy AI. And you can ask it to do a lot more than crunching numbers, and that's what's so powerful. And we are getting these generalized models where, in the past, if you had, like, an AI model, it could do one thing like classification or sentiment analysis.

+ +

Right now, I have AI that can give me French poetry. It can generate images. It can summarize things. It can help me have a conversation with it and learn how to improve my speaking skills. AI is trained on the web, right? And whatever is on the web, it's a reflection of that. So, that also comes with the good and the bad. The good being that it knows what most humans feel and think and can relate to. And the bad, though, is there's a lot of nonsense on the web, so a lot of the bias, a lot of the information that it's getting.

+ +

AI today can, with confidence say the wrong answer and believe that that is the right answer. So, that is one of the risks. Some people call this hallucination, where the AI goes haywire and wonky. But I'm hoping that with time, that does get solved; we have better guardrails and parameters. Some people will say that hallucination is a feature and not a bug because it's letting the AI be more expressive. But everyone's understanding of truth should not be, I think, different. Like, I think there is one set of truth sometimes, and you don't want the AI to misinterpret that.

+ +

So, yeah, I think it's an exciting time. And more people like our company are embracing and adopting AI into their core products. And it's causing incredible productivity gains. But it's nowhere perfect. People talk about this AGI, (artificial general intelligence). I think we're a little bit away from that, but we're moving fast. Like, this stuff is happening at an exponential rate.

+ +

In technology, there was this Moore's law, right? With the number of transistors and how amazing and exponentially better the chips got. We saw that with storage, right? The cost of cloud storage when it first came out was so expensive. Now it's super cheap. If you remember, back in the day, you got, like, a USB card where it could probably store, like, 10 megabytes. Now it can do, like, 10 gigabytes to, like, one terabyte. And the cost is, like, super affordable.

+ +

If you think about TVs that came out in the past, right? Like, getting a 60-inch TV was super expensive. Like, a 40-inch TV was super expensive. Now everything is, like, LCD. You get, like, 60, 70 inches. And the price is the same as what a 40-inch TV was back then.

+ +

So, AI is all of that and some more. It's moving at a rapid pace. Like, technology, as an industry, like, it's moving so quickly, and AI is moving more quickly than what most people can keep up with. So, that has pros and cons. We can dive into that more. But, yeah, things are changing on a weekly basis, not on a yearly basis right now.

+ +

VICTORIA: Right. And there's a few directions we can go in from there, I think, that are really interesting, right? There's, like, the future of work with AI because I can relate to a feeling of fear and anxiety about what is this new technology? Am I going to lose my job? And when I talk about it with people I'm mentoring, I try to position it more as this is going to change the way we work. You're still going to need people to do stuff.

+ +

But if you're rejecting AI because you think it's just a fad or it's just silly, like, I think it is fundamentally changing the way people are going to do their jobs if you pursue that. And I think if you're capable with using AI as a tool, you're going to be more powerful than you've ever been in your job in most cases.

+ +

KRISH: Rejecting AI is like someone rejecting email for faxing and sending paper mail by hand. You just cannot compete, right? Imagine if you were a business that said, "I don't believe in AI. I'm going to do everything old school." You'd be like, today, okay, cool. You should do that. And imagine if you're a business today that says, "I don't use email. I will physically mail everything to you handwritten." So, that's what it's going to be like in a few months to a year. Like, this stuff is happening quick.

+ +

And I always like to say that AI will it create more jobs? Yes. Will AI replace jobs? Yes. But the probability of someone using AI who will replace you is far greater. So, AI isn't going to replace you as much as someone using AI is going to replace you. It's a skill set that we have to all learn, just like how we had to learn to use a computer, to use the internet, to use the smartphone. This is the same thing here. Like, we're going to all have to learn to use it and learn to interact and gel with AI in the workplace.

+ +

VICTORIA: Absolutely. And how does that relate to what you learned in your journey with Fireflies and talking to people about AI? How have those conversations gone forward?

+ +

KRISH: Fireflies at the core is this AI meeting assistant that joins your meetings. It takes notes. It helps you remember what was discussed before a meeting, during a meeting, and after a meeting. It helps me recall any information that I talked about. If we met six months ago and I'm meeting you again, it has the notes for me. It lets me search back through it. It lets me ask it questions about what you talked about. What were the next steps? What were the action items?

+ +

So, it's giving me structure to my life because a lot of my life is having meetings with lots of people and having many conversations, and then recalling those conversations and staying on top of that. It gives me structure in terms of what I do day in and day out.

+ +

I always believe that work originates from conversations. Meetings are some of the most valuable conversations that we tend to have. It's also very expensive for an organization to have meetings. Because when you get four people in a room who are all making six figures and spending an hour having meetings, that information, whatever is discussed, can have a huge cost to the business. But it can also have a huge potential to move the business in the right direction. So, organizing all of that knowledge that originates from meetings was the initial vision of Firefly.

+ +

Before all of this AI and ChatGPT hype, that was what we'd set out to do. The LLMs and AI help us do that job better: summarize the meetings better, generate better action items, create meeting outlines, allow you to search back. Instead of searching by keywords, you can now ask specific questions and talk to AI. So, this is what AI enables people to do, especially with Fireflies, is you can now interact with Fireflies like you would with a teammate, and that has changed the way people feel and use our product.

+ +

And people don't come out and say, "Hey, you're replacing secretaries. You're replacing the intern that I've hired to take notes for me. Like, you are replacing the job that the new hire has to do because it's a rite of passage." 95% of people will not make that argument because it's actually silly because your assistant, your interns, your new hires have better things to do. And these are the mundane, monotonous stuff that you should delegate to AI. Obviously, you can have humans review all of that, have their own, you know, take on it, generate reports. But it's actually leveling them up to be more productive and be more valuable to your organization.

+ +

So, I think there's a lot of pieces of AI that will do the same. You know, other technologies like, for example, AI that generates images or graphic designs that's not going to replace the graphic designer. It's going to allow the graphic designer to be able to create many iterations, be more creative. Like, if they don't have the technical skills to use certain pieces of software, it can help them ease that barrier to entry and give them more assets to work with. So, I think of AI in the workplace as how can we augment human productivity by giving each and every person a superpower?

+ +

VICTORIA: And you started this eight years ago now. So, you were really, like, ahead of the curve in terms of all these AI companies coming out. I'm wondering, what challenges did you have early on, and how did you overcome them?

+ +

KRISH: When we started, this was not obvious, like, that we should be doing this. It sounded obvious to us. We felt like every person in the workplace deserved an AI assistant that takes notes, not just the C-suite who, has a secretary or a business admin. And it felt like it's so obvious. It should exist. We should build it. And we need to create the experience like an assistant that follows you around.

+ +

But when we started, there were so many uncertainties. Can this technology work? Can this technology scale? Is the transcription going to be accurate? Can you actually even summarize things? And does that stuff make sense? It's a new behavior. Are people willing to entertain AI assistants and meeting assistants? So, every step of the way, there's a technology risk, a go-to-market risk. You are doing a sales risk. Like there are so many like pieces to the puzzle that you have to figure out. And you have to peel each layer of the onion and get to the core. So, I think it's been quite a journey.

+ +

We've been lucky in a few ways, right? Because I do believe that luck is sometimes about being at the right place at the right time. But those that always keep showing up are going to be able to get lucky from time to time, right? If you take a thousand shots, at least one of them will make it. That was my philosophy. We tried. We built seven or eight different products that all somehow worked or utterly flopped. And eventually, we got closer and closer and closer to the truth of what customers needed. And that led us to build the version of Fireflies that exists today.

+ +

So, it's definitely not easy, but there were three core phases to Fireflies or three core movements that allowed Fireflies to exist. One is speech recognition and transcription fundamentally got better. It got more accurate and more affordable. Before, it was ridiculously expensive. It would take a dollar per minute of transcription, and you needed humans to do it. But these AI engines, speech engines, got better.

+ +

The second thing is when we launched Fireflies, the pandemic happened a few weeks later. Everyone went remote. Video conferencing became more mainstream, and people were actually having Zoom fatigue and way too many meetings. And they needed a way to organize all those meetings they're having, jumping from one meeting to the next. And Fireflies got pulled forward, and a lot of people wanted to have it in meetings and help them around. And that helped us grow exponentially, virally. To this day, Fireflies has taken notes for over 16 million people across 300,000 organizations.

+ +

And since the launch in January 2020 to where we are, the first two to three years were trial and error, right? From 2016 to 2020. We built our product in 2018, 2019, launched in 2020. The pandemic accelerated the adoption. And then, you have this new LLM wave that comes out at the end of 2021, which allowed us to make the product fundamentally more valuable. And everything got better from the notes, to the summaries, to the search. Everything got better. And we crossed the chasm from where people thought, "Huh, this is a cool idea, but I don't think it's going to work," to "Holy crap, this is one of the best use cases for generative AI and LLMs."

+ +

And yeah, like, it was luck in terms of being there when this movement was happening. I think a lot of AI companies can say that. But it also took a little bit of fortitude to be able to be doing this several years before the stuff came out, right? Once a gold rush occurs, everyone's going to want to go in and then build something. But if you were already there, and you were searching and searching, and you were very close to something, and then you discover the gold rush, you're going to have a head start, and that's what happened with us.

+ +

VICTORIA: Yeah, you said 7 to 8 product iterations, and I was like, uh, you really had to go through an emotional roller coaster, I'm sure early days. But you were lucky enough to be in the right place at the right time and have a good picture of what the problem space was. It's really incredible to hear that.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: Why don't I move forward a little bit into where you are now, where you have GDPR and SOC 2 compliance, and you're, you know, really doing well. Like, what were the challenges in getting that product to enterprise level?

+ +

KRISH: We let the customers pull us in the direction that needed for us to go. A lot of times, we try to see, okay, what is every friction point along the way? What would it take for larger organizations to adopt it? There is incredible product value. People have been saying it. But I need these sorts of features and capabilities in order to deploy it inside my organization. And we are handling meetings, which is sensitive. And so, we have to be able to give them more access controls, give them more admin features.

+ +

You know, we have a policy at Fireflies where we say, "We do not train on your data by default." So, most AI companies they're using their customer data to train models. We do not do that. So, we made that explicitly clear. CIOs love hearing that because when they look at us and other potential competitors, those competitors are bragging outside, saying, "Hey, we built this amazing model training on all of this data." And we say, "We don't do that." So, unless you want us to build something custom for you, we will not train on your data by default.

+ +

The other thing we said is, "Look, you own your data. If you want to delete it anytime, you can. You can request to have the data deleted. If you were a participant on a meeting and you don't feel comfortable with the data, you can request the host to delete it, or you can come to us, and we'll delete that data for you." Like, you have rights to that. And we put everything in a very customer-centric worldview, and that usually aligns with the big enterprises. That aligns well with a lot of the folks that want to use your service.

+ +

Because when you're using a new technology, the first question people are going to have is, "Does it work?" The second question they're going to have is, "Is it safe?" And with AI, a lot of people think about the safety of using the tech. And when you're building for a B2B enterprise, we had to make sure we put in the hard work to tailor our product to the needs of those customers.

+ +

VICTORIA: That's really interesting. And maybe you could say more about why would a company want to train a model on their own data and create an LLM like that?

+ +

KRISH: Are you talking about customers wanting us to train something for them?

+ +

VICTORIA: Yes. I've heard this idea from a few different people, actually, where they want to be able to build an LLM and build a model based on a company's own knowledge and their own information. So, maybe you could say more about that.

+ +

KRISH: I think it's really around fine-tuning and personalizing the AI. Now you can train on models. You can do fine-tuning. You can do other parameters. But it's really giving everyone their own personal experience with AI. We can do this today even without training just by understanding your preferences, and we want to continue to build towards that.

+ +

So, yeah, we believe that every person inside an organization should have their own personal AI note-taker, and no two meeting notes will be the same because each set of notes is unique to you, your meetings, what your team wants. And so, that, to us, is like a vision we try to build towards. AI can bring about insane level of personalization, and that's one of the reasons why people would want to train their own models based on their like, knowledge graph, and information.

+ +

VICTORIA: How do you think about the cost of building and running these AI tools from an infrastructure cost perspective? How does that translate to your cost for your customers, that kind of thing?

+ +

KRISH: AI is expensive. The unit economics...I think a lot of people are taking for granted that it is insanely expensive to run these models to use a cloud provider of these AI models. Some people are spinning up their own models. It is insanely expensive. But the good news is the cost is going down at an accelerated pace, and it's just up to whether the pace of the cost decrease will outweigh the amount of spending some of these startups are doing. And that's why some of these companies are raising tons of money as well because they don't really have a monetization strategy. They have no revenue. They're making lofty goals that "This AI is going to do this. It's going to do this. It's going to replace this function in your org."

+ +

But who's going to pay for it? How are you going to make people pay for it? Is it going to be subscription-based? Is it going to be utility-based? How much upfront cost is going to be there to train these models? And what if you do all that work, and then you deploy an LLM; you're an infrastructure provider, and no one cares? What if you're an application layer, and you're giving all of this stuff away for free and then eventually realize you can't get people to pay for it?

+ +

So, there are so many open questions for these companies where the technology is changing quickly. The cost is changing quickly, and consumer preferences are also changing quickly. We'll have to see. Only time will tell because there's a hundred companies out there, all raising a hundred million dollars. We know that all of them are not going to make it, a few are. So, it'll be interesting to see what happens once the dust settles. But I think people should take that very seriously because you can't always expect to be bailed out by investors if you don't know how to utilize AI and how to build for cost.

+ +

And I think a lot of investors tell startups to not worry about that. They say, "Don't worry about the cost. You know, as long as someone's there to pump you money, you just keep building, like, the best product out there." That works for some companies. I just don't believe it should be the only strategy that someone should take.

+ +

VICTORIA: What if you build it and no one cares? It'd be so heartbreaking [laughs], but it happens, yeah.

+ +

KRISH: That's 95% of startups that die is because no one cares.

+ +

VICTORIA: Right. Yeah. And I'm curious, like, what other use cases do you see as being the most relevant for AI? Like, what problems does it really solve very well? I mean, note-taking, obviously, one of them.

+ +

KRISH: I'm really excited about all of these AI tools that can write code for you. And maybe they can't replace a software engineer, but could you make a developer 10x more productive? And could today AI start off as a copilot for writing code for you to eventually building you full-fledged apps, right? And imagine what that would do in terms of reducing the barrier for so many people to be able to create their own personal apps and tools. Easier said than done.

+ +

But I think what's really working really well, whether it's with GitHub or some of these other AI tools, is, can it actually write code for you? And I think that's a wonderful use case. It'll still need a lot more fleshing out, but I am bullish on that use case for sure.

+ +

VICTORIA: Yeah. I'm hopeful that companies will figure out how to use AI to level up engineers because right now, we have the problem of the flattening of the middle where you have really senior people who are very in high demand. And then, you have a lot of people with very little experience who really want a career in technology. So, I see that as an opportunity, but also a risk that some people will create things with AI code and sell it. And it'll just be a hot mess [laughs]. But, you know, that's kind of the risk it is even if you're paying real developers at the same time, so...

+ +

KRISH: Yeah. I think AI will take a C player and make them a B player, maybe a B player into a B plus player. And then, it can take an A player and make them, like, A plus. So, I think it just levels the playing field a little bit, eventually to a point where everyone in the org is going to get a little bit more productive.

+ +

And I also think that small teams are going to be able to do incredible things. You, as a small team will be able to compete at a larger scale with some of the bigger companies. You know, Sam Altman said maybe there's a chance that a 10-person company is going to build a billion-dollar market cap organization that goes public. So, all of those are possibilities, too.

+ +

I love the idea of solopreneurs and people that run their own, like, small businesses, you know, three to four people, super lean. Obviously, I'm in a venture-backed world, so I can't necessarily run that, but I am very excited by that potential. And I like those types of people that are entrepreneurial and don't need a lot of CapEx in order to get started. AI will allow a lot more solopreneurs to thrive. If social media created a market for people to have, like, a full-time job as influencers, I think AI can create a market for people to have full-time jobs as creators of products, goods, and services that can be managed with just, like, a few people.

+ +

VICTORIA: That is really interesting. I'm curious if you want to...let's say you're meeting a founder or an entrepreneur, and they're AI-curious, but they don't really know where to get started or how to step their toe into the water. What advice would you give them?

+ +

KRISH: I think the best place to start is by building and building something for yourself that you yourself would use. Try all these different AI products that are out there. Look at what's trending in the news in terms of which...every week, some new model is being deployed, some new changes are being rolled out. Google is rolling something out. Facebook is rolling out something. OpenAI is rolling out something. So, try to keep pace. It's going to be tough.

+ +

And then, go play around and tinker with these tools. Like, you should be a tinkerer first. You should like to build things. You don't have to be an engineer to get started, but you need to be able to go and get your hands dirty, roll up your sleeves, and play around with these tools. The belief and conviction comes with you yourself gaining experience through understanding these tools. You know, you can't tell someone, you know, how to make a music video or make a movie without ever having used a camera before, right? So, it's the same way. You've got to learn how to use the tools first.

+ +

VICTORIA: And are there any yellow or red flags you would tell people to watch out for if they're thinking about AI or thinking about using a new AI product?

+ +

KRISH: I think for those founders that want to build large venture-scale businesses, and they're trying to bite off way more than they can chew, you should consider focusing. These are the sort of folks that maybe are not making a sequence of bets. They're trying to throw a hundred darts and see what sticks. And I usually think that's a strategy that will fail.

+ +

You need to understand why you're building, what you're building, who you're building for. Don't just build it because the technology is cool. You know, not to pick on any products out there, but there's a lot of hardware devices coming out recently that have AI backed into them, right? And you wonder, why the heck is this a hardware device? Couldn't this be just an app on my phone? Like, why do I need to go spend $200, or $600, or $1000 buying this device that has a lot of limitations?

+ +

The reason you built it because you thought the technology was cool. But by the time it got to production, it has a lot of faults. And you're trying to get people to change their behavior and take money and pay for this? That's tough. And I think VCs are falling for that as well, like, in funding tons of this money into these sorts of companies. Some can argue that it will get better with time and iterations.

+ +

But I personally stay away from hardware. I don't want to touch anything related to hardware right now because we don't even know what the new form factor is going to be. But the hardware people should ask themselves, "Should this be a standalone device, or could it just be something on my iPhone as an app?" That is something that's really, really interesting.

+ +

The space that I'm most excited about outside of AI for the workplace is robotics. And I've been seeing a lot of really cool products where they're trying to build these AI humanoid-like robots that can do a series of tasks. They're not like the machines in, like, an industry or a factory. But they can make you coffee. They can clean the dishes. They can cook you some food. I think the market for that is massive. Like, if that stuff works, people are going to be able to pay a lot of money for it. Like, the amount you'd pay for a car, you would pay for a utility-based robot inside your house and, like, with nice financing options and stuff. So, whoever cracks that is going to be really, really successful.

+ +

There's people companies that have raised a lot of money solving that. While I'm generally not bullish about hardware little devices, I am very bullish about, like, these general-purpose robots that I think the potential is immense. Like imagine every household having one or two of those; what that means for domestic productivity, like, someone's folding the laundry, someone is cleaning up the house, taking out the trash. These are jobs to be done, yeah.

+ +

VICTORIA: Well, then what would my husband do [laughter]? I'm just kidding. I don't want to replace him. No, I think it's interesting especially just, like, thinking about elder care, and having someone in the home, and watching, and cleaning up, and all of those tasks and being able to live independently. I could see that having a huge potential. So, also, obviously, I think robots are cool. It's the title of the podcast. So, I'm very pro-robot [laughs] in most cases, not all cases. Yeah. Well, that's super interesting. Let's see. Do you have anything else that you would like to promote?

+ +

KRISH: You know, besides embracing AI and using, you know, these tools and services, I would really be excited to hear about people's ideas on, like, how they're using AI in the workplace. Everyone has so many creative ways to go about it. So, each week, we discover new ways people are using Fireflies, right? Some people use it for taking notes. Some people use it to be able to take customer quotes from calls. So, they can literally ask our AI, "Hey, go through these, like, past two customer calls and pull out all of the nice things they said about us, and then turn that into a soundbite that I can share with my marketing team so we can run a marketing campaign on that" So, there's just so many interesting use cases.

+ +

I do want to say that voice is going to be a great form factor for AI. We work in the voice space. Like, I love talking to my AI during the meeting. So, I think that's going to be something that I would say is if you are an end user in the workplace, think about how you would use voice to get work done and turn your words into AI. And we're trying to solve that at Fireflies. And if you are interested in that space, we would love to talk to you. And if you have some interesting use cases that you want to see for Fireflies, please send them our way.

+ +

VICTORIA: I love that. And it's interesting when you bring up voice. One thing I was surprised about with my parents, actually, obviously, a generation older, I got them an Alexa Dot that I got from a conference. I didn't think they would ever use it, but they actually use it all the time. They're, like, asking for recipes, setting timers, and doing things like that. And, yeah, if you have, like, an AI voice, like, "Send an email to this person" or, like, "Open this task and do it." Maybe I would actually get some more tasks done [laughs]. I could just do it over voice. Sometimes like, the keyboard and the screen is part of the delay. That's really interesting. Thank you so much for being on the podcast.

+ +

Do you have any questions for me before we sign off?

+ +

KRISH: I'm curious to hear your thoughts on what are the biggest risks with AI you foresee for people, and what makes you more skeptical about AI?

+ +

VICTORIA: Yeah, you touched on a little bit earlier when you said about the cost of AI and the cost-benefit analysis; I don't think is always there for every single use case, right? There are some use cases where it is so clear there is a benefit for that. Note-taking is one of them. There's a million professions, I think, that would benefit from having AI note-taking apps.

+ +

I think the risks which we've already seen that impact people, you mentioned the biases, and things like people getting denied health care, getting longer prison term sentences. You know, the way that they might blindly incorporate these algorithms into decisions that really reinforce biases because of this historical data that it's based on.

+ +

I think whenever someone asks me about the risks of AI and, like, people losing jobs, or, you know, rogue AI taking over the world, I always bring it back to that some AI is already hurting people, and it should be stopped, and people should be educated on it. Like, the big scary AI conversation is almost a distraction to what's really going on, and we need to all be smarter about it.

+ +

At the same time, I love using AI. I think it really can, like you said, get your productivity up 100%. In some cases, like, you can just do so much more so much faster. And I see that potential. And I think that there's always that balance, right? Like, you have to be able to be aware and embrace both if you're going to stay current. But there are some people who still send faxes and still do everything by mail. But, you know, it's like technology never really dies. There's just more of it in different ways, right?

+ +

KRISH: Absolutely [laughs]. That's awesome. Well, thank you. This was great.

+ +

VICTORIA: Wonderful. Yeah, I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Jv6_SBaS + + ]]> + + Victoria Guido + + + 527: Exploring AI in Business with PrimeLab io’s Wendell Adams + https://podcast.thoughtbot.com/527 + b729bcad-76cc-46cc-bd88-046cc1715f32 + Thu, 30 May 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido welcomes Wendell Adams, CEO of PrimeLab io, who shares his journey from childhood tech enthusiast to entrepreneur, highlighting his focus on making technology accessible. Wendell discusses the strategic direction and market fit for PrimeLab, emphasizing innovative solutions for the entertainment industry that respect user control and privacy. The episode concludes with Wendell's insights on democratizing data access, enhancing business processes, and advice for aspiring entrepreneurs on thinking critically and creatively. + 44:50 + no + + + Host Victoria Guido welcomes Wendell Adams, CEO of PrimeLab.io, as he talks about his lifelong passion for technology and entrepreneurship. Wendell shares his experiences, from hacking electronics as a child to studying various fields in college and eventually starting his own business. He emphasizes the importance of understanding market needs and leveraging language to make technology accessible. Wendell's drive to improve encryption and data security led to the formation of PrimeLab; a company focused on making encryption functional and accessible without compromising performance. +Wendell discusses PrimeLab's strategic direction and market fit. He outlines the challenges and opportunities in the entertainment industry, emphasizing the need for innovative solutions that respect user control and privacy. Wendell also shares insights into how PrimeLab's technology can democratize data access and enhance business processes. The episode concludes with a reflection on the future of AI and encryption technologies and Wendell's advice for aspiring entrepreneurs to think critically and creatively about their ventures. +PrimeLab.io (https://primelab.io/) +Follow PrimeLab.io on LinkedIn (https://www.linkedin.com/company/primelab-io/), or X (https://x.com/PrimeLab4). +Follow Wendell Adams on LinkedIn (https://www.linkedin.com/in/wendell-a-83317895/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: + AD: +We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. +Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue.  +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Wendell Adams, CEO at PrimeLab io. Wendell, thank you for joining us. +WENDELL: Thanks for having me. So, question, actually, where'd you guys come up with the name? +VICTORIA: You know, I have asked this before, and I think I remember the answer. I might have to go back to the 500th episode to get it, but I think it was just robots was already kind of a theme at thoughtbot. I mean, thoughtbot, obviously, has robot in the name. Joe might have the best answer. And we have our special co-host, Joe Ferris. Who better to answer? +JOE: [chuckles] Yes, I'm not sure who better to answer, probably Chad. I don't remember the answer either, but happy to be here to speculate with the two of you. It comes from the blog. We named the blog Giant Robots Smashing Into Other Giant Robots and then used it for our podcast. But I don't remember where the blog name came from. +WENDELL: It kind of reminds me of the Robot Wars thing, like, where they would have competitors driving around the robots and then smashing into each other, trying to flip them over and disable them. +JOE: That was excellent. I also watched that. +WENDELL: [laughs] +VICTORIA: Yeah, it's a pretty great name. I really enjoy being a host. And, you know, I go out to local San Diego events and meet people and introduce myself as a co-host of Giant Robots Smashing Into Other Giant Robots. It's usually pretty funny [laughter], which is where I met you, Wendell; we met at a San Diego CTO Lunches, which was super fun. +WENDELL: Yeah, I always enjoy any type of tech conversation or anything else. I thought that was a lot of fun to sit down and just talk with people and talk about what they're working on. +VICTORIA: I love that, yeah. And before we dive into the tech and get to hear more about PrimeLab, I just want to start a little more socially question. What did you do last weekend, Wendell? +WENDELL: It was my father-in-law's birthday party at Legoland. We took my daughters my mother-in-law, and we all went to Legoland. It was a lot of fun. Although, honestly, I prefer the San Diego Zoo over Legoland, so... +VICTORIA: Can you please describe what Legoland is to people who may not know? +WENDELL: Okay. Legoland is based in Carlsbad, and it's really ideal for, like, four to nine-year-olds. And they have, like, miniatures of all the different cities. Actually, the SF miniature that they have is crazy detailed with Chinatown and everything else. They did an amazing job there. They actually...I think they just redid the San Diego part of it. But the miniatures are really cool, seeing all this stuff. +They have different rides performers, but it's definitely, like, one of those things that it's more for kids to go and kind of experience. If you're an adult, you're going to love a lot of the processes that go into place, like how they built things, but mostly, yeah, it's very much kid rides and stuff like that. +VICTORIA: I imagined it to be, like, life-size Lego buildings, but maybe I'm...that's very interesting all those other things you could do there. +WENDELL: Well, like, they have the One World Trade Center, and I think it's, like, 25 feet tall. It is, like, the replica of it. It's kind of interesting, too, because not all the Legos that they build, they're huge, are solid Legos. So, it's like, they'll do where it's like, on the outside, they'll do a base, and then they'll build it. There's a replica of a Lamborghini. That one's life-size. But it's heavy. It's, like, 2,000 pounds, something like that. +VICTORIA: Is that as much as a regular Lamborghini weighs, too, 2,000 pounds? It can't be that far up. +WENDELL: I don't know. No, I don't think it...no, it couldn't be. +VICTORIA: I have no idea how much cars [laughs] weigh. What about you, Joe? Did you do anything fun this weekend? +JOE: Not a lot. It was supposed to be my son's first soccer game ever, but it rained here in Boston, so they postponed it. Sunday he went to my parents' house for a grandma day, and so I did nothing. I ate cookies. +WENDELL: [laughs] +VICTORIA: Wait, what kind of cookies were they, though? +JOE: They were chocolate chip cookies. +VICTORIA: That's so good. +JOE: They were good. They were brown butter chocolate chip cookies, I should say. +VICTORIA: Were they homemade, or did you get them somewhere? +JOE: They were. We made them in this home. +VICTORIA: Oh, that's the best. Yeah, love that. I got some fancy cookies that someone else made, and they were also [laughs] very good. And then, yeah, I've just been having cookies pretty much every day. So, that's been my time. +WENDELL: My mother-in-law recently made me peanut butter cookies, and those are my favorite kind of homemade cookies. +VICTORIA: Okay. Noted. You'll get a post-podcast gift of peanut butter cookies [laughter]. I love that. It's so great to hear a little bit more about each of you as, like, in a personal way before we dive into AI. And tell me a little bit more about your background and what led you to PrimeLab. +WENDELL: I've always kind of, like, been a hacker, so to speak, just from a technical standpoint. My one grandfather was an engineer. He worked for GM designing, like, assembly arms and stuff like that. And then my other grandfather was a master electrician. So, I've always been the person that, like, just worked on things, got stuff together. +You know, there's a lot of stories. Like, there's the story about when I broke my grandmother's workbench, rocking bench out front, and it was all aluminum. I remember telling my grandfather, and he's like, "Oh, what are you going to do?" And I was like, "Buy a new one?" He's like, "You got money?" I said, "No." And he said, "Well, you better figure how to make it then." So, ironically, it's half aluminum, half wood. We took wood, sanded it down, and stuff. +So, it's just like I've always been an entrepreneur. I've always been interested in this kind of stuff. I used to hack VCRs, and PlayStations, and all kinds of stuff. I always liked parts and components and rewiring things. And as I got older, I also really liked math and all those things. And I wanted to understand more about how the world works, so to speak, like why it works the way it does, not just from a technology standpoint. But why do people think the way that they do? Why do things behave the certain way they do? +So, initially, I started going to college. I thought I might be a math professor, and then decided to get degrees in business, economics, finance, marketing, consumer product goods, and comparative religions. So, while I was in college, I started working on, like, hacking, different video games, writing JavaScript, writing Java, all kinds of stuff. And then, eventually, even writing mobile applications early on, and then just analyzing because I always liked to build phones, too. I would take apart phones. And I really was curious about, like, how to make things faster, more efficient, and better. So, now to bring it down, like, how to make things accessible, where it benefits some of the smallest people and make it where it's a greater opportunity for someone to come out ahead of something. +Like, one thing that I learned from my marketing degree is language matters. So, it's like, all the marketing it's not anything special. It's just they intentionally create language barriers that cause people not to feel as accessible with it. And then, like, you hire a consultant or something to just basically teach you about those language barriers. And I think every industry has, like, SAT, or LTM, or something like these abbreviations that mean a lot of different things. And it causes bottlenecks if you don't speak the language. So, understanding the language but also learning about how was very helpful from a standpoint on the marketing side. And I always try to figure out how do I make this accessible to people who don't understand that language? +VICTORIA: And what was the turning point where you decided to start PrimeLab, and what made you realize there was a company there? +WENDELL: It was a project I've been working on since at least 2011, honestly. And just as a heads up, PrimeLab as a whole works with encrypted data for AI models and to speed that up and everything else. So, early on, I was very obsessed with how advertising works through, like, stealing user data, which stealing is different, here or there, the sense of privacy, the sense of, like, how things could run, and the sense of messaging. +And initially, a lot of it was using encryption as an overlay in, like, the pixel application space, which is always a way to hack or get into it. And it slows everything down. So, I had always been working on trying to figure out how do you speed up and embed security so it's actually functional? And it took a while to figure out, like, give encryption functionality, like, make the encryption something that you could actually execute on. +And, actually, one of the things that really helped is the blockchain space there's a lot of, like, hash trees and everything else, like, where people are innovating in that. That's really helped innovate encryption as a whole from understanding, like, Merkle trees, hash graphs, and everything else to make it more functional and faster. Because people are trying to speed up distributed networks and stuff, but the actual technology that they built, like Hedera is...What Hedera has done with Hashgraphs and everything else—really amazing. I'm glad that they open-source stuff like that. +But it's also really interesting just to see how things push forward. So, like, when I first started, like, RAM was, like, 256 in a phone. So now, you know, you can get multiple gigabytes, which makes it a lot more capable to do encryption, decryption, and work more in the functional space of things. The bigger problem that you have on the data part is how an application communicates because there's so many levels of abstraction. Like, you have the Swift language that communicates into something else that then communicates into something else. +Like, right now, we're talking on a system that's recording us over the internet through a browser, all those different things. And it's an approximation of what the data is and what we sound like. It's not an absolute. So, I was really interested in when you have absolutes, and you can verify those absolutes, what can you do with that? +A few years ago, I felt like we got to a point where we could actually execute those things and actually deliver on that. So, therefore, I decided to start PrimeLab with my co-founder, who I really liked and enjoyed. And we've had a lot of really great advisors, where people have helped us continuously. Over, you know, the decade-plus of working on this, I've gotten a lot of input from some of the smartest people I know, from people who have designed full server racks for AWS to literally a good friend of mine that built cloud storage. His name's on the patent for it. So, that kind of stuff has really helped me understand and build this where it can communicate the lowest possible level. +VICTORIA: Yeah, and to just recap and reflect that back a little bit, it sounds like you were always interested in how to make encryption faster and lighter weight, and so you could build it in and build in security without impacting the performance of the applications. And then meeting your co-founder and the advancement of technology, this time a couple of years ago, led you to think, okay, let's really go forward with this. +WENDELL: Kind of rephrasing, I was always interested in control. So, like, one of the things that really interested me...so, I started a video game store buying and selling, like, video games and trading cards and stuff when I was roughly ten and a half or so, and then sold it roughly when I was 17, which is how I paid for quite a bit of college and likewise. But the things that really interested me about that is it went out of business three to four months afterwards because the person who basically bought the rest of it bought too much of Madden. And Madden, at this time, the margins were, like, a buck, as you go all the way through, and the price drops immensely. +So, I wanted to really understand why that happened. What you kind of get to is, like, they didn't have control over it, just, like, the bulk orders methodology, where they would buy the whole entire supply. And what I've seen over the years, be it Apple, Google, or anything else, is, like, that was...in that example, that's a game publisher, EA, flexing control, right? +But more and more companies are flexing control on a platform like now with Facebook or advertising. If you think about what Google used to do, Google used to provide a lot more insights when you had your own website. You used to know your own keywords. You used to know a lot of things about your users who come through. More and more, Facebook and Google try to stop that. And they're really the ones determining your own user personas for you. So, you become dependent upon them. +So, I wanted to say, okay, from a business standpoint, how do you implement control and privacy where it's permissioned? And encryption was one of the answers that I came to. But then it was, how do you make encryption functional then to actually execute on control? Because unless the system is secure, faster, cheaper, better, it's never going to get adopted. +VICTORIA: That makes sense. Thank you for sharing that. And you mentioned your founder. I'm curious, how does your founder kind of complete what you needed to be able to get the business up and running and off the ground? +WENDELL: He has a robotics degree, so he had launched several products that had failed. And he wanted to learn marketing after they had failed. So, we have a similar like mindset about, like, control and functionality for how something may or may not work, and that allowed us to communicate well. So, like, I have a lot of friends and stuff. But the thing that allows me and my co-founder to work really well is that we come from things in different angles, but we have the same language that we speak. +So, like, that's what I was talking about before, like, LTMs or otherwise, like, language really matters from how you can move something forward when you're talking in different industries. And just with him, there's a lot of stuff that you don't have to say. You can skip a lot of filler and then go straight to what something might be or a solution or something. Or if we have to jump to a tech abbreviation, to a market abbreviation, to a financial abbreviation, he's one that can follow along with me really quickly and then teach me a lot of things about operational execution because he's great at operations. I am not great at operations. +VICTORIA: That's really interesting. And I think you're making a good point about, like, a shared language. And it reminds me of any product that you're building; if you want to sell it to a company and you want them to adopt it, you have to consider their language, their belief system, how to influence change within the organization. And I wonder if you could talk a little bit more about that with your experience at PrimeLab. +WENDELL: I'll give you an example of a market that we decided to go after. So, instead of just working at, like, healthcare markets where you have, like, GDPR...for people who don't know GDPR or HIPAA, HIPAA is for the United States. GDPR is the EU privacy requirements, right? For the right to be forgotten and everything else. So, these are vernaculars that you need to know. But the requirements of each one is very different, and these are markets that we've learned being in tech and likewise. But we wanted to change it up. +So, I wanted to go after the entertainment market as a whole, namely because after meeting with some select people, including a stunt man, this is going back a few years ago, I started to realize that the entertainment market was getting kind of screwed over quite a bit from a tech standpoint. Basically, tech goes through this thing where...someone wrote a great article about this. It's called Enshittification. But, basically, where they go they try to take over a whole entire market, where first they're providing great value to your users. And then, gradually, you enshittify your product to provide greater value to your investors. And then, gradually, you suck all of the value out of the room for both. +Right now, if you look at Sora, what OpenAI is trying to do in entertainment, [inaudible 16:08], you kind of can see that happening. They're going, "Hey, here's a great value for it." And they're really pushing that stuff off. But the thing about the entertainment market that I think is really interesting is it's basically thousands and thousands of small businesses that are constantly going, it's so chaotic. It's not like tech and startups. There's a lot of overlay of, like, you know, people are looking for that top quartile film that's going to make the money back, and then long-term royalties that they can earn off of it, right? Whereas in tech, they're looking for those huge markups as well. +So, I was really fascinated by it, but it was something that, like, we had to learn. Like it was something that I didn't know otherwise. So, it was literally...how we learned it was we took our tech stuff, and we would walk SAG-AFTRA strike lines. We would walk strike lines. We would go to entertainment events, and we would demo what we were trying to do, and we would show them. And then, oftentimes, we got really negative feedback right off the bat. And we're like, "No, no, no, so, you know, this is for you. Like, you could control. Like, this is going to help you." +And then, after doing that enough times, talking to the SAG-AFTRA lawyers, and everything else from there, and all of the creatives, the creatives were coming to us and giving us ideas how to explain it because there's, like, three different formats. You have tech, business, creatives in the entertainment industry. And it's like, we could talk to the tech people. We could talk to the business people. But you really need the creatives. And, like, the wording of each one, like, each group of those is vastly different. +So, having the creatives be able to explain something in 90 seconds that used to take me a couple of hours to dive into became really valuable. And also, in tech, like, you have this thing where it's feature creep, where you're like, oh, I'll add this, this, and this. Just to hear very coldly and bluntly, like, "If it does X, I'm interested. If it does Y, I'm not interested." That was very interesting or refreshing of, like, "Yes, you're going to solve these problems. But I need sign-off for everything in there." +And it's kind of weird in the entertainment part, too. Like, you want to solve a problem without being a competitor to another vendor because you need so many different sign-offs. And if you're a competitor to another vendor, to a certain point, maybe that's going to cause a hiccup with sign-offs because there's 18 different cooks in the kitchen, so to speak, just so many different people that need to say, "Yes," all the way through with it. +VICTORIA: Thank you. Yeah, that's really interesting. I'm curious, Joe, if you have an answer for that question as well, like, any experiences about navigating change and putting new products in place at different clients, different industries? +JOE: I don't think I've had the same kind of resistance. Like, I haven't been on the front lines the way you described, like, literally in the, you know, going and talking to people on strike. I think I have more indirect experience talking to the people who are doing that. +And certainly, like, I think there's generally a resistance to bringing in new technology without eliminating the old way of doing things if that makes sense. Like, people want the old ways of backup. Like they want to be able to go back to paper, which I empathize with. But that's frequently been a challenge for the people I've worked with is that they don't fully embrace the new process, which significantly reduces the value they would get from using it. I don't know if that's something you've encountered with PrimeLab. +WENDELL: So, we were building another company of mine many, many, many years ago. I was building a website for this lumber company, and I remember showing up, and the owner was there. But it was his son that had commissioned it, and the owner didn't know about the website. And I was like, "Oh yeah, we'll get the website going." He goes, "Oh, this web thing it's a fad. It's never going to happen. You don't need websites. It's faxes." That's how everything would happen. But secretly, what was happening is they would get an order. They would print it off, and then they would fax it. So [laughs], I always thought that was crazy. +VICTORIA: I mean, one of my local bars still just writes the order on a ticket and sends it on a clothesline down to the grill. So [laughs], sometimes old is good. But I think that you know, I want to hear more about where you found or how you found a product-market fit for PrimeLab and where that AI really becomes useful and ethical in the industry you're focusing on +WENDELL: How I look at PMF (product-market fit)...and if you hear me just say PMF, that's what that means. So, how I look at PMF is I'm a little different in the fact that when I look at a product, or a technology, I don't just look at, like, so you have foundational tech. Like, okay, this is encryption. This is control, right? Now, where's the market that has the biggest problems with it? So, I like to go out and actually talk to those people. Because, like, when you're implementing tech, or you're implementing the product itself, it's different. So, you're like, you have the underlying infrastructure, but whether that's a button or a simple API that you need to build so it works different to hit that PMF...are you familiar with the term build a better mousetrap? +VICTORIA: I don't think so. +JOE: I'm familiar, but I'd still love to hear you describe it. +WENDELL: So, in business school, and likewise, they will tell you "If you build a better mousetrap, people will come, and they will buy your product." So, like, it's a common thing where they're like, "Build a better mousetrap. People will come. They'll be there." And the thing that you learn with consumer product goods and marketing, though, is they actually built a better mousetrap, and it failed. +And the reason why it failed is you had a mousetrap that was roughly a cent versus another mousetrap that was three cents. And I think this is in the '60s or so. The other mousetrap was reusable, so it executed a lot better, and everything else is more humane. But what they didn't understand is that it was wives most of the time that would have to actually handle this. And they didn't want the mouse alive, and they didn't want to reuse the trap. They wanted them to actually be disposed of right away. +So, by not understanding the market, even though they built a better mousetrap, they'd missed the point. Like, the main problem to solve wasn't killing the mouse or having it be reusable. The main problem to solve was, like, getting rid of the mouse. So like, if you have a solution for getting rid of the mouse, the next thing is your execution for it. Like, does it hit the actual market, which is the fit aspect? +Like, every product is a little bit different where you look at, like, how does this fit in? So, in this case, fit is very important for, like, disposing of the mouse, which is why you also have, like, you know, mouse poisons are popular, even though they're terrible because they die somewhere and, hopefully, you don't see them. And it's like sight unseen, right? Now, I'm glad, like, that's changing and stuff. +But it's understanding even if you have a solution to something, you need to understand what your market wants out of your solution, and it's not going to be an abstract. It's going to be an emotional, like, execution-based process. So, you kind of have to go, all right, this is my market. This is kind of my fit. But the actual product I'm building is going to change to make sure it works all the way through with this. +I was advising a startup many, many years ago, and they were building this CRM software on Android for South America. And I think they were building it for Android 6 or 7 at the time. But the market that they were targeting, they all ran Android 4.1. So, they spent a little over a million dollars building for the wrong version of Android that wouldn't even work on that version of the system. Like, it was one of those things where they were required to build it for that. But they didn't understand the actual market, and they didn't spend enough time researching it. So, it's like you get the Bay Area groupthink. +If they had actually spent the time to analyze that market and go, "Oh, they run, you know, an inexpensive phone. It's 4.1. It's low RAM," now you can design a product. If you want it to be a CRM, you're going to, like, chunk up the system more. Like, you're going to change all that instead of just wasting a million dollars building something that now you basically have to start over again from scratch. +VICTORIA: That seems like he got off cheap, too. People make way bigger mistakes that cost way more money [laughs] because they [inaudible 24:13] +WENDELL: Well, that wasn't me. That was an investor that -- +VICTORIA: Oh no. I mean, yeah, not just them. Yeah. +WENDELL: He's like, "What would you do?" And I was like, "You should sell this company or sell your stake ASAP because that's a really bad sign." +JOE: I have found that the answer nobody ever wants when you're doing product validation or testing product fit is, "You should not build this product." The idea that the software just shouldn't be written is universally unpopular. +WENDELL: Yes [laughs]. That's, you know, that's part of the reason why it took me so long to do PrimeLab is because, like, it took a long enough for the software to actually need to be written, if that makes sense. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +VICTORIA: What does success look like now versus six months or even five years from now? +WENDELL: I take a different approach to this because I have so many friends that have sold their businesses. They raise and everything else. I look at success as instead of an exit or another large thing, like, literally, we turned down a billion-dollar term sheet offer. I didn't like the terms. I didn't like what it would do from the control standpoint of the technology. What I care about is go-to-market and, like, adoption and actually getting the tech out there in a way that has market penetration but, like, that adds value to every person's life. +VICTORIA: Yeah, maybe say more about that. Like how do you see AI and this technology you have with PrimeLab benefiting people and benefiting the industry that you're working within? +WENDELL: So, the current AI models are kind of weird. They're basically just filter systems because they communicate in pixel space and then go down to functional space. It's the GPU. GPUs are actually terrible to use for AI. This is why you have dedicated AI chips getting built. Hopefully, the RISC-V chipset does actually do something because that's a chipset that I think it's an open-source chipset, but you can actually especially build models on it. +So, I think that we're going to see a lot more in the RISC-V chipset where it's like, this is just for one particular image, or this is just for explosions, or this is just for touching up all these different points in the actual individual, like, microcontroller module data that ends up compiling to move forward with it. +But the AI models now it's like you took the internet, and you're trying to ask it a probability question, what I was talking about before, where it's not an absolute. So, it's like, if I want to do an OCR system or anything, I take an image. It's got to say, "This is..." letters; it's going to recognize that. So, there's, like, multiple models and algorithms that need to run on that whole entire process. You even have artificial data, but all of that information is an approximation. It's not an absolute. If you want absolute, you can get a lot of absolute data from the actual hardware devices themselves. You know, take a Sony camera. You could see the lighting. You could see the raw information, everything else there. +But because of how expensive it is, people compress it. Like, take YouTube where it's compressed, and now you're training off of it. You're trying to compress it more and then run an algorithm so that you don't have to actually process those large, raw files all the way through. That's just a bad infrastructure for compute. You're trying to reduce, but you're also trying to utilize what you own for rights, same thing, contextual, or anything else there. There's no value in a model. Once a model is out there, it's just weights moving it back and forth. The value is in the data and the applications. So, the actual data itself that's going in. +So, if you have just lava scenes, like, having all that data for lava, and I want to put it in a background, now I can do that, but more importantly, it's not about just adding it into the background. The thing that is often missed is contextually the output. So, like, say I want to do a financial report. Rather than having the data of all financial reports out there, what I want as the input is my financial data. And what I want as, like, a fine-tuning output is an example of the reports that were generated. And I don't want those reports as the input to inform the output because that's where you get a hallucination. Maybe it starts grabbing financial data from someone else. +And I also think we're in store for a lot more hacks because with not just poisoning data, which we do in the functional space, if someone tries to access it. But, I mean, literally, there's the story...I think the guy was in Hong Kong, where they faked his board all the way through with it. Because you have agents acting and executing on people's behalf, you're going to have systems where people go onto the hardware and start generating fake financial numbers. And now that's going to get reported. Or you pay an invoice that you weren't supposed to pay because someone manipulated your AI agent. +And a lot of the stuff that we're seeing now from Microsoft and everything else that's not really where the models will go. It's great to do it, but it's kind of like we're in the dial-up stage of AI. Like [chuckles], dial-up has its use cases and stuff, but it's nowhere near what the tech will look like in the future, and it's nowhere near how it will function. +And one of the big pushbacks that you see, like, from Google, from all these different places, like, they want your attention. But at the end of the day, Google's an ad company. Facebook's an ad company. It's not in their best interest to have hyper-localized data that you control for your models and likewise. They want it in the cloud. They want it used there, where they can control that data, and they can monetize and advertise for you. But at the same time, like AI models work the best, and AI applications work the best when the data set is limited, so it can't hallucinate, and when the outputs are actually controlled to what it should be from an informed standpoint. So, where we're at this is just in the beginning stages of stuff. +VICTORIA: That's really interesting. Thank you so much for sharing. I think if you could go back in time when you first started PrimeLab and give yourself some advice, what would you say? +WENDELL: You know, I lived through the Great Recession. The Great Recession informed me a lot more. The things that I didn't understand this time...like the Great Recession, was market contributors doing stuff that impacted everyone with their spend and their adoption, and how those things were. But the Fed raising interest rates, which is, you know, Silicon Valley Bank failed and stuff like that, that dynamic of those startups and, like, how much startups power everything, like, I would have advised myself to pay more attention to the Fed and those market dynamics going forward. +Because what changed is it's not just the Silicon Valley Bank failed it, you know, Rippling went down, for instance, which would pay therapists in Florida and all kinds of stuff. Like, it broke so many different things. It caused bottlenecks in business that we're still going through. Like, everyone's like, "Oh, we're getting back to normal." Really not. It's still, like, delayed all the way through it. +The AI aspect is really getting back to normal, where people are really pushing AI. But if you look at SaaS and other industries, it really, really slowed down. And the reason why that matters is, like, in my field, production and timelines matter. So, when you have that plus, you know, the entertainment strike and everything else, you have things where the actual production of things starts slowing down immensely. Whereas AI is one of the few things that you still have innovations because that never really slowed down, same thing with the models. But all the rest of the industries and stuff have really slowed down. +And understanding what that means from an operational execution standpoint...it's a good thing I have my co-founder [inaudible 32:24]. It matters quite a bit because it means your team sizes have to change, how you handle certain clients has to change. Because once those companies start downsizing or laying off people for whatever reason like, that's going to change how you're working with them, and their requirements are going to change as well. +VICTORIA: And what do you see on the horizon as a challenge or a big hurdle that you face as a company or as an industry? +WENDELL: You know, the entertainment market's really interesting from all the different sign-offs. The challenge is more execution of timeline. So, like, if you're doing something with, like, Nvidia and the healthcare thing, it could take years. If you're doing something in, like, the IoT space, you know, also years. If you do something in the entertainment space, it could take weeks to months, except the large studios. The larger studios, it could take a couple of years as well. +But going to market, I think, is a very big challenge, not just for us but the whole entire industry. I mean, there's a reason why Sam Altman came down to LA to meet with studios, to try and get stuff moving forward. And I think one of the things that he's forgetting is like, you think of Netflix. Netflix is streaming. In order for that to work, they needed Roku, and they needed Kevin Spacey because [chuckles]...it's crazy to say that, but House of Cards is kind of what made it, right? And Hollywood was mostly boxing them out quite a bit. Same thing with Blockbuster otherwise. They had to drop a hundred million dollars, a large enough bankable star at the time that would really push something forward. And they had to basically really push Roku out there so that they had PMF across the board. +What that means, though, is, like, Netflix is paying for content like crazy, right? So, this is kind of enshittification in a process. So, they're paying for content like crazy. So, now Hollywood's making money. They like it. At the studios, they don't love it when their stuff's going there because maybe it's less money, but now they start cutting the seasons short. They start cutting...it's a lot more algorithmic-driven. You have the ad systems that sort of come out. So, now, like, Netflix is not just doing ads where the customer experience is getting worse, but now, also, the business experience for those partners selling stuff is also getting worse, and all that value is getting driven to Netflix. Like, that's the tech system and Hollywood's learned that. +But, like, when you're looking at the next adoption, like, they're hesitant for that. Just like a lot of stuff with AI, they're hesitant because they're thinking about all the power and control that they gave up. But you have to show how they're going to make money. You can't just cut costs, right? If you can't show how they're going to make money, you're not going to get adopted. That's kind of what I like there because so much of tech is about saving costs and being more efficient. In the entertainment industry, it's not just those two things. It's how can I make more money? And it's going to, like, ooh, you can monetize your content through training samples and stuff like that. +So, our model goes exactly against what the large tech companies have where they want to take content, train on it, like the search engine does, suck the value off Sam Altman's Sora. Ours goes, all right, this is your content. Only you own this. You can take your own content, train it, and then perform this operation on it that is more efficient likewise. And if you choose to monetize it in any way, shape, or form, we can just take the functional space, not all the images and no one will ever see it, and take that functional space for training so that you can actually monetize from that as well. +VICTORIA: I love that. Super interesting. Thank you so much for sharing. And do you have any questions for me or for Joe? +WENDELL: I've noticed a lot of differences on, like, applications and how systems are built. So, I'm kind of curious about you guys' standpoint about applications, you know, the Apple Vision Pro. Facebook just said they'd start licensing out their AI system, or Meta, whatever. So, you have the comparisons to Android versus iOS that's happening, stuff like that. So, I'm really curious about, like, you guys' thoughts on the Vision Pro and that ecosystem. +JOE: Well, I can't speak for all of thoughtbot, but I can say that, to me, it was interesting to see that get released. And it's been interesting to see how aggressively Meta and Apple have been pursuing the various VR markets. Like it reminds me of when television companies and studios worked really hard to get 3D movies to be a thing. +WENDELL: [laughs]. +JOE: Because I think they just ran out of things that people are asking for. Like, people were interested in getting better resolutions up to a point. Like, they wanted better packaging. But it got to a point where it was like, they didn't want to give anybody anything they were asking for. So, they were like, what if it's in 3D? And, like, for years, it seemed like Apple was really on top of seeing what people really wanted, and being able to present a very well-prepared version of that product before other companies were able to. And, personally, it's not what I saw with the Apple Vision Pro. Like, it wasn't the obvious missing space that was there when the iPhone or the iPad showed up. +WENDELL: Yeah, I always go back to, like, the "Why?" question. You know, previously when...even just before we had talked, I was talking about comparative religions, and why that's so valuable is because it really teaches you...again, I've had this conversation before, but the comparative religions, if you think about religion as a tech company, they're always trying to solve why. Like, why did the sun come up? Why did this happen, right? And you always have to do that. So, apply that to technology, Google or Apple, why does this product exist? And when you get to, like, it just existed to make money, I think that's really the 3D thing. Whereas, like, why did the iPhone exist? It existed to solve this problem of being portable on the go and getting information in the way that we communicated, too. +VICTORIA: Yeah. I think the Apple Vision Pro appeals to a very specific market segment and that that segment is not me [laughter]. I, actually, during COVID...after...it was, like...yeah, we're still in COVID. But during the pandemic, I moved from DC to California. And to connect with some old friends, I bought a VR headset and decided to go to virtual coffee with them. And it just makes me nauseous. And it actually affects...quite a lot of women get nauseous in VR. For some people, the look—the capability is really exciting. They have the extra money to spend on gadgets, and that's what they like. And it's very appealing, and the, like potential, is really interesting. I just find it for myself. Personally, I'm more drawn to tech that's not maybe cutting edge but solves problems for actual people. +And kind of why I'm interested in PrimeLab, what you were mentioning is just how artists can use this technology to protect their creative work. To give that power back to people and that control over their content, I think, is really interesting rather than...I'm not really sure what I would do with the Apple Vision Pro [laughs]. Like, the early ones, I mean, it's cool. It's fun. I definitely enjoy it. Like, I sometimes like to learn about it, but it's not my passionate genre of tech that I normally go for. +WENDELL: Going back to what you just said about, like, control, like, part of the thing is because of the hash IDs that we put into place, like, you don't need analytics. You don't need cookies or anything else, like the content holder. Basically, like, if you have a TV set or something and you want to stream content to it, you can actually see that information directly yourself. So, it takes the person generating it and the person viewing it. It forms...we call them function access keys. It forms a one-to-one relationship, basically, where you guys know if you want to know what you want to know, but then you choose to give access to the platform if you want to, which changes the dynamic of control quite a bit. +And it's interesting because when you look at platforms like the Apple Vision Pro, and you look at Apple's whole entire system as a whole, just trying to lock in people, I think it's interesting because something like what I just described, Apple can't really stop. It's how compute works. So, if people want to use it, there's nothing they could do to stop it from being used. So, I'm really interested in the product stuff and just more about, like, how...and I'm curious what you guys think on this, too. +Especially as you see phones and processors and everything else, I'm really interested in, like, how these things come about, like, how things are actually built and developed and the why for that, like, in the everyday use. So, like, the Apple Watch it started off as a fashion thing, which looked like a money grab, and then the why was, oh yeah, fitness. So, just curious if you guys have seen any other products out there that you're like, oh, this really resonates with me and the why. +JOE: Yeah, I'm not really a gadget person, but I think the idea of taking some of the capabilities that we've gotten with the internet and with phones and making them hands-free was interesting. And that, to me, was what I think started pushing the development of products like the Apple Watch or Google Glass. Like, I think that hands-free capability, the trade-off became rewarding in the fitness field, but I think it's more generically applicable. I think that technology it's too obtrusive in other scenarios and too bad at its job to do some of the things it could do. And people got creeped out by Google Glass. But it doesn't really seem like the Vision Pro fits in there. Something being successful hands-free means it becomes less obtrusive, whereas the Vision Pro is like you become a cyborg. +VICTORIA: Do you have anything else you would like to promote? +WENDELL: I wouldn't say necessarily promote as much as like people with ideas or aspirations, like, I think it's important that you think counter to what everyone else is doing. There's that line of, like, when everyone else is running in one direction, run the other. And it's like, if you have a business or startup idea, really think about your market. Like, think about why you're doing what you're doing, and don't be afraid to just go out there and talk to people. You will get value no matter who you talk to. +So, like, I'm a hugely tech-based person. My wife is a therapist, and I learn from her everyday things about emotional intelligence and all kinds of things that I would be an idiot otherwise. But also, learn, like, you can always learn something from someone. Like, take the time to listen to them. Take the time to actually, like, try and figure out what's one thing I can learn from someone, even if, you know, I learn stuff from my daughters even. Like, don't put things in boxes. Like, try to think outside of like, how can I ask a question to learn? +VICTORIA: I love that advice. That's great. +WENDELL: Have you guys used Suno before? +VICTORIA: That's music, right? Music AI. +WENDELL: All right, I got to show you guys this. We're going to create you a quick theme song. Like, this is what I mean by, like, it's an interesting solution for why. +VICTORIA: That does sound fun. I like the ones...like my friend's a doctor, and she uses AI to take her conversation she's having with patients and automatically fill out her notes. And it saves her, like, 20 hours of documentation every week. Like, I like that kind of app. I'm like, oh, that makes a lot of sense. +WENDELL: What's a style of music that you guys really like? +JOE: Swedish pop +VICTORIA: Like ABBA [laughs]? I'm down for an ABBA Giant Robots theme song. Sounds great. +WENDELL: I think you're going to like this. +[Music Playing] +VICTORIA: These are awesome. They're super fun. Thank you so much. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on X @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. + AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. Special Guest: Joe Ferris. + + AI automation, process orchestration, Wendell Adams, PrimeLab io, Victoria Guido, Joe Ferris, encryption technology, data security, Legoland visit, San Diego Zoo, startup journey, entrepreneur story, business process optimization, AI in entertainment, tech podcast, thoughtbot, Giant Robots podcast, predictive modeling, generative AI, assistive AI, market fit, technology accessibility, Camunda integration, AI-powered processes, workflow automation, machine learning, data analysis, innovation in tech, hacking electronics, business insights, customer personalization, fraud detection, risk management, product development + + Host Victoria Guido welcomes Wendell Adams, CEO of PrimeLab.io, as he talks about his lifelong passion for technology and entrepreneurship. Wendell shares his experiences, from hacking electronics as a child to studying various fields in college and eventually starting his own business. He emphasizes the importance of understanding market needs and leveraging language to make technology accessible. Wendell's drive to improve encryption and data security led to the formation of PrimeLab; a company focused on making encryption functional and accessible without compromising performance.

+ +

Wendell discusses PrimeLab's strategic direction and market fit. He outlines the challenges and opportunities in the entertainment industry, emphasizing the need for innovative solutions that respect user control and privacy. Wendell also shares insights into how PrimeLab's technology can democratize data access and enhance business processes. The episode concludes with a reflection on the future of AI and encryption technologies and Wendell's advice for aspiring entrepreneurs to think critically and creatively about their ventures.

+ + + +

Transcript:

+ +

 AD:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. 

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Wendell Adams, CEO at PrimeLab io. Wendell, thank you for joining us.

+ +

WENDELL: Thanks for having me. So, question, actually, where'd you guys come up with the name?

+ +

VICTORIA: You know, I have asked this before, and I think I remember the answer. I might have to go back to the 500th episode to get it, but I think it was just robots was already kind of a theme at thoughtbot. I mean, thoughtbot, obviously, has robot in the name. Joe might have the best answer. And we have our special co-host, Joe Ferris. Who better to answer?

+ +

JOE: [chuckles] Yes, I'm not sure who better to answer, probably Chad. I don't remember the answer either, but happy to be here to speculate with the two of you. It comes from the blog. We named the blog Giant Robots Smashing Into Other Giant Robots and then used it for our podcast. But I don't remember where the blog name came from.

+ +

WENDELL: It kind of reminds me of the Robot Wars thing, like, where they would have competitors driving around the robots and then smashing into each other, trying to flip them over and disable them.

+ +

JOE: That was excellent. I also watched that.

+ +

WENDELL: [laughs]

+ +

VICTORIA: Yeah, it's a pretty great name. I really enjoy being a host. And, you know, I go out to local San Diego events and meet people and introduce myself as a co-host of Giant Robots Smashing Into Other Giant Robots. It's usually pretty funny [laughter], which is where I met you, Wendell; we met at a San Diego CTO Lunches, which was super fun.

+ +

WENDELL: Yeah, I always enjoy any type of tech conversation or anything else. I thought that was a lot of fun to sit down and just talk with people and talk about what they're working on.

+ +

VICTORIA: I love that, yeah. And before we dive into the tech and get to hear more about PrimeLab, I just want to start a little more socially question. What did you do last weekend, Wendell?

+ +

WENDELL: It was my father-in-law's birthday party at Legoland. We took my daughters my mother-in-law, and we all went to Legoland. It was a lot of fun. Although, honestly, I prefer the San Diego Zoo over Legoland, so...

+ +

VICTORIA: Can you please describe what Legoland is to people who may not know?

+ +

WENDELL: Okay. Legoland is based in Carlsbad, and it's really ideal for, like, four to nine-year-olds. And they have, like, miniatures of all the different cities. Actually, the SF miniature that they have is crazy detailed with Chinatown and everything else. They did an amazing job there. They actually...I think they just redid the San Diego part of it. But the miniatures are really cool, seeing all this stuff.

+ +

They have different rides performers, but it's definitely, like, one of those things that it's more for kids to go and kind of experience. If you're an adult, you're going to love a lot of the processes that go into place, like how they built things, but mostly, yeah, it's very much kid rides and stuff like that.

+ +

VICTORIA: I imagined it to be, like, life-size Lego buildings, but maybe I'm...that's very interesting all those other things you could do there.

+ +

WENDELL: Well, like, they have the One World Trade Center, and I think it's, like, 25 feet tall. It is, like, the replica of it. It's kind of interesting, too, because not all the Legos that they build, they're huge, are solid Legos. So, it's like, they'll do where it's like, on the outside, they'll do a base, and then they'll build it. There's a replica of a Lamborghini. That one's life-size. But it's heavy. It's, like, 2,000 pounds, something like that.

+ +

VICTORIA: Is that as much as a regular Lamborghini weighs, too, 2,000 pounds? It can't be that far up.

+ +

WENDELL: I don't know. No, I don't think it...no, it couldn't be.

+ +

VICTORIA: I have no idea how much cars [laughs] weigh. What about you, Joe? Did you do anything fun this weekend?

+ +

JOE: Not a lot. It was supposed to be my son's first soccer game ever, but it rained here in Boston, so they postponed it. Sunday he went to my parents' house for a grandma day, and so I did nothing. I ate cookies.

+ +

WENDELL: [laughs]

+ +

VICTORIA: Wait, what kind of cookies were they, though?

+ +

JOE: They were chocolate chip cookies.

+ +

VICTORIA: That's so good.

+ +

JOE: They were good. They were brown butter chocolate chip cookies, I should say.

+ +

VICTORIA: Were they homemade, or did you get them somewhere?

+ +

JOE: They were. We made them in this home.

+ +

VICTORIA: Oh, that's the best. Yeah, love that. I got some fancy cookies that someone else made, and they were also [laughs] very good. And then, yeah, I've just been having cookies pretty much every day. So, that's been my time.

+ +

WENDELL: My mother-in-law recently made me peanut butter cookies, and those are my favorite kind of homemade cookies.

+ +

VICTORIA: Okay. Noted. You'll get a post-podcast gift of peanut butter cookies [laughter]. I love that. It's so great to hear a little bit more about each of you as, like, in a personal way before we dive into AI. And tell me a little bit more about your background and what led you to PrimeLab.

+ +

WENDELL: I've always kind of, like, been a hacker, so to speak, just from a technical standpoint. My one grandfather was an engineer. He worked for GM designing, like, assembly arms and stuff like that. And then my other grandfather was a master electrician. So, I've always been the person that, like, just worked on things, got stuff together.

+ +

You know, there's a lot of stories. Like, there's the story about when I broke my grandmother's workbench, rocking bench out front, and it was all aluminum. I remember telling my grandfather, and he's like, "Oh, what are you going to do?" And I was like, "Buy a new one?" He's like, "You got money?" I said, "No." And he said, "Well, you better figure how to make it then." So, ironically, it's half aluminum, half wood. We took wood, sanded it down, and stuff.

+ +

So, it's just like I've always been an entrepreneur. I've always been interested in this kind of stuff. I used to hack VCRs, and PlayStations, and all kinds of stuff. I always liked parts and components and rewiring things. And as I got older, I also really liked math and all those things. And I wanted to understand more about how the world works, so to speak, like why it works the way it does, not just from a technology standpoint. But why do people think the way that they do? Why do things behave the certain way they do?

+ +

So, initially, I started going to college. I thought I might be a math professor, and then decided to get degrees in business, economics, finance, marketing, consumer product goods, and comparative religions. So, while I was in college, I started working on, like, hacking, different video games, writing JavaScript, writing Java, all kinds of stuff. And then, eventually, even writing mobile applications early on, and then just analyzing because I always liked to build phones, too. I would take apart phones. And I really was curious about, like, how to make things faster, more efficient, and better. So, now to bring it down, like, how to make things accessible, where it benefits some of the smallest people and make it where it's a greater opportunity for someone to come out ahead of something.

+ +

Like, one thing that I learned from my marketing degree is language matters. So, it's like, all the marketing it's not anything special. It's just they intentionally create language barriers that cause people not to feel as accessible with it. And then, like, you hire a consultant or something to just basically teach you about those language barriers. And I think every industry has, like, SAT, or LTM, or something like these abbreviations that mean a lot of different things. And it causes bottlenecks if you don't speak the language. So, understanding the language but also learning about how was very helpful from a standpoint on the marketing side. And I always try to figure out how do I make this accessible to people who don't understand that language?

+ +

VICTORIA: And what was the turning point where you decided to start PrimeLab, and what made you realize there was a company there?

+ +

WENDELL: It was a project I've been working on since at least 2011, honestly. And just as a heads up, PrimeLab as a whole works with encrypted data for AI models and to speed that up and everything else. So, early on, I was very obsessed with how advertising works through, like, stealing user data, which stealing is different, here or there, the sense of privacy, the sense of, like, how things could run, and the sense of messaging.

+ +

And initially, a lot of it was using encryption as an overlay in, like, the pixel application space, which is always a way to hack or get into it. And it slows everything down. So, I had always been working on trying to figure out how do you speed up and embed security so it's actually functional? And it took a while to figure out, like, give encryption functionality, like, make the encryption something that you could actually execute on.

+ +

And, actually, one of the things that really helped is the blockchain space there's a lot of, like, hash trees and everything else, like, where people are innovating in that. That's really helped innovate encryption as a whole from understanding, like, Merkle trees, hash graphs, and everything else to make it more functional and faster. Because people are trying to speed up distributed networks and stuff, but the actual technology that they built, like Hedera is...What Hedera has done with Hashgraphs and everything else—really amazing. I'm glad that they open-source stuff like that.

+ +

But it's also really interesting just to see how things push forward. So, like, when I first started, like, RAM was, like, 256 in a phone. So now, you know, you can get multiple gigabytes, which makes it a lot more capable to do encryption, decryption, and work more in the functional space of things. The bigger problem that you have on the data part is how an application communicates because there's so many levels of abstraction. Like, you have the Swift language that communicates into something else that then communicates into something else.

+ +

Like, right now, we're talking on a system that's recording us over the internet through a browser, all those different things. And it's an approximation of what the data is and what we sound like. It's not an absolute. So, I was really interested in when you have absolutes, and you can verify those absolutes, what can you do with that?

+ +

A few years ago, I felt like we got to a point where we could actually execute those things and actually deliver on that. So, therefore, I decided to start PrimeLab with my co-founder, who I really liked and enjoyed. And we've had a lot of really great advisors, where people have helped us continuously. Over, you know, the decade-plus of working on this, I've gotten a lot of input from some of the smartest people I know, from people who have designed full server racks for AWS to literally a good friend of mine that built cloud storage. His name's on the patent for it. So, that kind of stuff has really helped me understand and build this where it can communicate the lowest possible level.

+ +

VICTORIA: Yeah, and to just recap and reflect that back a little bit, it sounds like you were always interested in how to make encryption faster and lighter weight, and so you could build it in and build in security without impacting the performance of the applications. And then meeting your co-founder and the advancement of technology, this time a couple of years ago, led you to think, okay, let's really go forward with this.

+ +

WENDELL: Kind of rephrasing, I was always interested in control. So, like, one of the things that really interested me...so, I started a video game store buying and selling, like, video games and trading cards and stuff when I was roughly ten and a half or so, and then sold it roughly when I was 17, which is how I paid for quite a bit of college and likewise. But the things that really interested me about that is it went out of business three to four months afterwards because the person who basically bought the rest of it bought too much of Madden. And Madden, at this time, the margins were, like, a buck, as you go all the way through, and the price drops immensely.

+ +

So, I wanted to really understand why that happened. What you kind of get to is, like, they didn't have control over it, just, like, the bulk orders methodology, where they would buy the whole entire supply. And what I've seen over the years, be it Apple, Google, or anything else, is, like, that was...in that example, that's a game publisher, EA, flexing control, right?

+ +

But more and more companies are flexing control on a platform like now with Facebook or advertising. If you think about what Google used to do, Google used to provide a lot more insights when you had your own website. You used to know your own keywords. You used to know a lot of things about your users who come through. More and more, Facebook and Google try to stop that. And they're really the ones determining your own user personas for you. So, you become dependent upon them.

+ +

So, I wanted to say, okay, from a business standpoint, how do you implement control and privacy where it's permissioned? And encryption was one of the answers that I came to. But then it was, how do you make encryption functional then to actually execute on control? Because unless the system is secure, faster, cheaper, better, it's never going to get adopted.

+ +

VICTORIA: That makes sense. Thank you for sharing that. And you mentioned your founder. I'm curious, how does your founder kind of complete what you needed to be able to get the business up and running and off the ground?

+ +

WENDELL: He has a robotics degree, so he had launched several products that had failed. And he wanted to learn marketing after they had failed. So, we have a similar like mindset about, like, control and functionality for how something may or may not work, and that allowed us to communicate well. So, like, I have a lot of friends and stuff. But the thing that allows me and my co-founder to work really well is that we come from things in different angles, but we have the same language that we speak.

+ +

So, like, that's what I was talking about before, like, LTMs or otherwise, like, language really matters from how you can move something forward when you're talking in different industries. And just with him, there's a lot of stuff that you don't have to say. You can skip a lot of filler and then go straight to what something might be or a solution or something. Or if we have to jump to a tech abbreviation, to a market abbreviation, to a financial abbreviation, he's one that can follow along with me really quickly and then teach me a lot of things about operational execution because he's great at operations. I am not great at operations.

+ +

VICTORIA: That's really interesting. And I think you're making a good point about, like, a shared language. And it reminds me of any product that you're building; if you want to sell it to a company and you want them to adopt it, you have to consider their language, their belief system, how to influence change within the organization. And I wonder if you could talk a little bit more about that with your experience at PrimeLab.

+ +

WENDELL: I'll give you an example of a market that we decided to go after. So, instead of just working at, like, healthcare markets where you have, like, GDPR...for people who don't know GDPR or HIPAA, HIPAA is for the United States. GDPR is the EU privacy requirements, right? For the right to be forgotten and everything else. So, these are vernaculars that you need to know. But the requirements of each one is very different, and these are markets that we've learned being in tech and likewise. But we wanted to change it up.

+ +

So, I wanted to go after the entertainment market as a whole, namely because after meeting with some select people, including a stunt man, this is going back a few years ago, I started to realize that the entertainment market was getting kind of screwed over quite a bit from a tech standpoint. Basically, tech goes through this thing where...someone wrote a great article about this. It's called Enshittification. But, basically, where they go they try to take over a whole entire market, where first they're providing great value to your users. And then, gradually, you enshittify your product to provide greater value to your investors. And then, gradually, you suck all of the value out of the room for both.

+ +

Right now, if you look at Sora, what OpenAI is trying to do in entertainment, [inaudible 16:08], you kind of can see that happening. They're going, "Hey, here's a great value for it." And they're really pushing that stuff off. But the thing about the entertainment market that I think is really interesting is it's basically thousands and thousands of small businesses that are constantly going, it's so chaotic. It's not like tech and startups. There's a lot of overlay of, like, you know, people are looking for that top quartile film that's going to make the money back, and then long-term royalties that they can earn off of it, right? Whereas in tech, they're looking for those huge markups as well.

+ +

So, I was really fascinated by it, but it was something that, like, we had to learn. Like it was something that I didn't know otherwise. So, it was literally...how we learned it was we took our tech stuff, and we would walk SAG-AFTRA strike lines. We would walk strike lines. We would go to entertainment events, and we would demo what we were trying to do, and we would show them. And then, oftentimes, we got really negative feedback right off the bat. And we're like, "No, no, no, so, you know, this is for you. Like, you could control. Like, this is going to help you."

+ +

And then, after doing that enough times, talking to the SAG-AFTRA lawyers, and everything else from there, and all of the creatives, the creatives were coming to us and giving us ideas how to explain it because there's, like, three different formats. You have tech, business, creatives in the entertainment industry. And it's like, we could talk to the tech people. We could talk to the business people. But you really need the creatives. And, like, the wording of each one, like, each group of those is vastly different.

+ +

So, having the creatives be able to explain something in 90 seconds that used to take me a couple of hours to dive into became really valuable. And also, in tech, like, you have this thing where it's feature creep, where you're like, oh, I'll add this, this, and this. Just to hear very coldly and bluntly, like, "If it does X, I'm interested. If it does Y, I'm not interested." That was very interesting or refreshing of, like, "Yes, you're going to solve these problems. But I need sign-off for everything in there."

+ +

And it's kind of weird in the entertainment part, too. Like, you want to solve a problem without being a competitor to another vendor because you need so many different sign-offs. And if you're a competitor to another vendor, to a certain point, maybe that's going to cause a hiccup with sign-offs because there's 18 different cooks in the kitchen, so to speak, just so many different people that need to say, "Yes," all the way through with it.

+ +

VICTORIA: Thank you. Yeah, that's really interesting. I'm curious, Joe, if you have an answer for that question as well, like, any experiences about navigating change and putting new products in place at different clients, different industries?

+ +

JOE: I don't think I've had the same kind of resistance. Like, I haven't been on the front lines the way you described, like, literally in the, you know, going and talking to people on strike. I think I have more indirect experience talking to the people who are doing that.

+ +

And certainly, like, I think there's generally a resistance to bringing in new technology without eliminating the old way of doing things if that makes sense. Like, people want the old ways of backup. Like they want to be able to go back to paper, which I empathize with. But that's frequently been a challenge for the people I've worked with is that they don't fully embrace the new process, which significantly reduces the value they would get from using it. I don't know if that's something you've encountered with PrimeLab.

+ +

WENDELL: So, we were building another company of mine many, many, many years ago. I was building a website for this lumber company, and I remember showing up, and the owner was there. But it was his son that had commissioned it, and the owner didn't know about the website. And I was like, "Oh yeah, we'll get the website going." He goes, "Oh, this web thing it's a fad. It's never going to happen. You don't need websites. It's faxes." That's how everything would happen. But secretly, what was happening is they would get an order. They would print it off, and then they would fax it. So [laughs], I always thought that was crazy.

+ +

VICTORIA: I mean, one of my local bars still just writes the order on a ticket and sends it on a clothesline down to the grill. So [laughs], sometimes old is good. But I think that you know, I want to hear more about where you found or how you found a product-market fit for PrimeLab and where that AI really becomes useful and ethical in the industry you're focusing on

+ +

WENDELL: How I look at PMF (product-market fit)...and if you hear me just say PMF, that's what that means. So, how I look at PMF is I'm a little different in the fact that when I look at a product, or a technology, I don't just look at, like, so you have foundational tech. Like, okay, this is encryption. This is control, right? Now, where's the market that has the biggest problems with it? So, I like to go out and actually talk to those people. Because, like, when you're implementing tech, or you're implementing the product itself, it's different. So, you're like, you have the underlying infrastructure, but whether that's a button or a simple API that you need to build so it works different to hit that PMF...are you familiar with the term build a better mousetrap?

+ +

VICTORIA: I don't think so.

+ +

JOE: I'm familiar, but I'd still love to hear you describe it.

+ +

WENDELL: So, in business school, and likewise, they will tell you "If you build a better mousetrap, people will come, and they will buy your product." So, like, it's a common thing where they're like, "Build a better mousetrap. People will come. They'll be there." And the thing that you learn with consumer product goods and marketing, though, is they actually built a better mousetrap, and it failed.

+ +

And the reason why it failed is you had a mousetrap that was roughly a cent versus another mousetrap that was three cents. And I think this is in the '60s or so. The other mousetrap was reusable, so it executed a lot better, and everything else is more humane. But what they didn't understand is that it was wives most of the time that would have to actually handle this. And they didn't want the mouse alive, and they didn't want to reuse the trap. They wanted them to actually be disposed of right away.

+ +

So, by not understanding the market, even though they built a better mousetrap, they'd missed the point. Like, the main problem to solve wasn't killing the mouse or having it be reusable. The main problem to solve was, like, getting rid of the mouse. So like, if you have a solution for getting rid of the mouse, the next thing is your execution for it. Like, does it hit the actual market, which is the fit aspect?

+ +

Like, every product is a little bit different where you look at, like, how does this fit in? So, in this case, fit is very important for, like, disposing of the mouse, which is why you also have, like, you know, mouse poisons are popular, even though they're terrible because they die somewhere and, hopefully, you don't see them. And it's like sight unseen, right? Now, I'm glad, like, that's changing and stuff.

+ +

But it's understanding even if you have a solution to something, you need to understand what your market wants out of your solution, and it's not going to be an abstract. It's going to be an emotional, like, execution-based process. So, you kind of have to go, all right, this is my market. This is kind of my fit. But the actual product I'm building is going to change to make sure it works all the way through with this.

+ +

I was advising a startup many, many years ago, and they were building this CRM software on Android for South America. And I think they were building it for Android 6 or 7 at the time. But the market that they were targeting, they all ran Android 4.1. So, they spent a little over a million dollars building for the wrong version of Android that wouldn't even work on that version of the system. Like, it was one of those things where they were required to build it for that. But they didn't understand the actual market, and they didn't spend enough time researching it. So, it's like you get the Bay Area groupthink.

+ +

If they had actually spent the time to analyze that market and go, "Oh, they run, you know, an inexpensive phone. It's 4.1. It's low RAM," now you can design a product. If you want it to be a CRM, you're going to, like, chunk up the system more. Like, you're going to change all that instead of just wasting a million dollars building something that now you basically have to start over again from scratch.

+ +

VICTORIA: That seems like he got off cheap, too. People make way bigger mistakes that cost way more money [laughs] because they [inaudible 24:13]

+ +

WENDELL: Well, that wasn't me. That was an investor that --

+ +

VICTORIA: Oh no. I mean, yeah, not just them. Yeah.

+ +

WENDELL: He's like, "What would you do?" And I was like, "You should sell this company or sell your stake ASAP because that's a really bad sign."

+ +

JOE: I have found that the answer nobody ever wants when you're doing product validation or testing product fit is, "You should not build this product." The idea that the software just shouldn't be written is universally unpopular.

+ +

WENDELL: Yes [laughs]. That's, you know, that's part of the reason why it took me so long to do PrimeLab is because, like, it took a long enough for the software to actually need to be written, if that makes sense.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: What does success look like now versus six months or even five years from now?

+ +

WENDELL: I take a different approach to this because I have so many friends that have sold their businesses. They raise and everything else. I look at success as instead of an exit or another large thing, like, literally, we turned down a billion-dollar term sheet offer. I didn't like the terms. I didn't like what it would do from the control standpoint of the technology. What I care about is go-to-market and, like, adoption and actually getting the tech out there in a way that has market penetration but, like, that adds value to every person's life.

+ +

VICTORIA: Yeah, maybe say more about that. Like how do you see AI and this technology you have with PrimeLab benefiting people and benefiting the industry that you're working within?

+ +

WENDELL: So, the current AI models are kind of weird. They're basically just filter systems because they communicate in pixel space and then go down to functional space. It's the GPU. GPUs are actually terrible to use for AI. This is why you have dedicated AI chips getting built. Hopefully, the RISC-V chipset does actually do something because that's a chipset that I think it's an open-source chipset, but you can actually especially build models on it.

+ +

So, I think that we're going to see a lot more in the RISC-V chipset where it's like, this is just for one particular image, or this is just for explosions, or this is just for touching up all these different points in the actual individual, like, microcontroller module data that ends up compiling to move forward with it.

+ +

But the AI models now it's like you took the internet, and you're trying to ask it a probability question, what I was talking about before, where it's not an absolute. So, it's like, if I want to do an OCR system or anything, I take an image. It's got to say, "This is..." letters; it's going to recognize that. So, there's, like, multiple models and algorithms that need to run on that whole entire process. You even have artificial data, but all of that information is an approximation. It's not an absolute. If you want absolute, you can get a lot of absolute data from the actual hardware devices themselves. You know, take a Sony camera. You could see the lighting. You could see the raw information, everything else there.

+ +

But because of how expensive it is, people compress it. Like, take YouTube where it's compressed, and now you're training off of it. You're trying to compress it more and then run an algorithm so that you don't have to actually process those large, raw files all the way through. That's just a bad infrastructure for compute. You're trying to reduce, but you're also trying to utilize what you own for rights, same thing, contextual, or anything else there. There's no value in a model. Once a model is out there, it's just weights moving it back and forth. The value is in the data and the applications. So, the actual data itself that's going in.

+ +

So, if you have just lava scenes, like, having all that data for lava, and I want to put it in a background, now I can do that, but more importantly, it's not about just adding it into the background. The thing that is often missed is contextually the output. So, like, say I want to do a financial report. Rather than having the data of all financial reports out there, what I want as the input is my financial data. And what I want as, like, a fine-tuning output is an example of the reports that were generated. And I don't want those reports as the input to inform the output because that's where you get a hallucination. Maybe it starts grabbing financial data from someone else.

+ +

And I also think we're in store for a lot more hacks because with not just poisoning data, which we do in the functional space, if someone tries to access it. But, I mean, literally, there's the story...I think the guy was in Hong Kong, where they faked his board all the way through with it. Because you have agents acting and executing on people's behalf, you're going to have systems where people go onto the hardware and start generating fake financial numbers. And now that's going to get reported. Or you pay an invoice that you weren't supposed to pay because someone manipulated your AI agent.

+ +

And a lot of the stuff that we're seeing now from Microsoft and everything else that's not really where the models will go. It's great to do it, but it's kind of like we're in the dial-up stage of AI. Like [chuckles], dial-up has its use cases and stuff, but it's nowhere near what the tech will look like in the future, and it's nowhere near how it will function.

+ +

And one of the big pushbacks that you see, like, from Google, from all these different places, like, they want your attention. But at the end of the day, Google's an ad company. Facebook's an ad company. It's not in their best interest to have hyper-localized data that you control for your models and likewise. They want it in the cloud. They want it used there, where they can control that data, and they can monetize and advertise for you. But at the same time, like AI models work the best, and AI applications work the best when the data set is limited, so it can't hallucinate, and when the outputs are actually controlled to what it should be from an informed standpoint. So, where we're at this is just in the beginning stages of stuff.

+ +

VICTORIA: That's really interesting. Thank you so much for sharing. I think if you could go back in time when you first started PrimeLab and give yourself some advice, what would you say?

+ +

WENDELL: You know, I lived through the Great Recession. The Great Recession informed me a lot more. The things that I didn't understand this time...like the Great Recession, was market contributors doing stuff that impacted everyone with their spend and their adoption, and how those things were. But the Fed raising interest rates, which is, you know, Silicon Valley Bank failed and stuff like that, that dynamic of those startups and, like, how much startups power everything, like, I would have advised myself to pay more attention to the Fed and those market dynamics going forward.

+ +

Because what changed is it's not just the Silicon Valley Bank failed it, you know, Rippling went down, for instance, which would pay therapists in Florida and all kinds of stuff. Like, it broke so many different things. It caused bottlenecks in business that we're still going through. Like, everyone's like, "Oh, we're getting back to normal." Really not. It's still, like, delayed all the way through it.

+ +

The AI aspect is really getting back to normal, where people are really pushing AI. But if you look at SaaS and other industries, it really, really slowed down. And the reason why that matters is, like, in my field, production and timelines matter. So, when you have that plus, you know, the entertainment strike and everything else, you have things where the actual production of things starts slowing down immensely. Whereas AI is one of the few things that you still have innovations because that never really slowed down, same thing with the models. But all the rest of the industries and stuff have really slowed down.

+ +

And understanding what that means from an operational execution standpoint...it's a good thing I have my co-founder [inaudible 32:24]. It matters quite a bit because it means your team sizes have to change, how you handle certain clients has to change. Because once those companies start downsizing or laying off people for whatever reason like, that's going to change how you're working with them, and their requirements are going to change as well.

+ +

VICTORIA: And what do you see on the horizon as a challenge or a big hurdle that you face as a company or as an industry?

+ +

WENDELL: You know, the entertainment market's really interesting from all the different sign-offs. The challenge is more execution of timeline. So, like, if you're doing something with, like, Nvidia and the healthcare thing, it could take years. If you're doing something in, like, the IoT space, you know, also years. If you do something in the entertainment space, it could take weeks to months, except the large studios. The larger studios, it could take a couple of years as well.

+ +

But going to market, I think, is a very big challenge, not just for us but the whole entire industry. I mean, there's a reason why Sam Altman came down to LA to meet with studios, to try and get stuff moving forward. And I think one of the things that he's forgetting is like, you think of Netflix. Netflix is streaming. In order for that to work, they needed Roku, and they needed Kevin Spacey because [chuckles]...it's crazy to say that, but House of Cards is kind of what made it, right? And Hollywood was mostly boxing them out quite a bit. Same thing with Blockbuster otherwise. They had to drop a hundred million dollars, a large enough bankable star at the time that would really push something forward. And they had to basically really push Roku out there so that they had PMF across the board.

+ +

What that means, though, is, like, Netflix is paying for content like crazy, right? So, this is kind of enshittification in a process. So, they're paying for content like crazy. So, now Hollywood's making money. They like it. At the studios, they don't love it when their stuff's going there because maybe it's less money, but now they start cutting the seasons short. They start cutting...it's a lot more algorithmic-driven. You have the ad systems that sort of come out. So, now, like, Netflix is not just doing ads where the customer experience is getting worse, but now, also, the business experience for those partners selling stuff is also getting worse, and all that value is getting driven to Netflix. Like, that's the tech system and Hollywood's learned that.

+ +

But, like, when you're looking at the next adoption, like, they're hesitant for that. Just like a lot of stuff with AI, they're hesitant because they're thinking about all the power and control that they gave up. But you have to show how they're going to make money. You can't just cut costs, right? If you can't show how they're going to make money, you're not going to get adopted. That's kind of what I like there because so much of tech is about saving costs and being more efficient. In the entertainment industry, it's not just those two things. It's how can I make more money? And it's going to, like, ooh, you can monetize your content through training samples and stuff like that.

+ +

So, our model goes exactly against what the large tech companies have where they want to take content, train on it, like the search engine does, suck the value off Sam Altman's Sora. Ours goes, all right, this is your content. Only you own this. You can take your own content, train it, and then perform this operation on it that is more efficient likewise. And if you choose to monetize it in any way, shape, or form, we can just take the functional space, not all the images and no one will ever see it, and take that functional space for training so that you can actually monetize from that as well.

+ +

VICTORIA: I love that. Super interesting. Thank you so much for sharing. And do you have any questions for me or for Joe?

+ +

WENDELL: I've noticed a lot of differences on, like, applications and how systems are built. So, I'm kind of curious about you guys' standpoint about applications, you know, the Apple Vision Pro. Facebook just said they'd start licensing out their AI system, or Meta, whatever. So, you have the comparisons to Android versus iOS that's happening, stuff like that. So, I'm really curious about, like, you guys' thoughts on the Vision Pro and that ecosystem.

+ +

JOE: Well, I can't speak for all of thoughtbot, but I can say that, to me, it was interesting to see that get released. And it's been interesting to see how aggressively Meta and Apple have been pursuing the various VR markets. Like it reminds me of when television companies and studios worked really hard to get 3D movies to be a thing.

+ +

WENDELL: [laughs].

+ +

JOE: Because I think they just ran out of things that people are asking for. Like, people were interested in getting better resolutions up to a point. Like, they wanted better packaging. But it got to a point where it was like, they didn't want to give anybody anything they were asking for. So, they were like, what if it's in 3D? And, like, for years, it seemed like Apple was really on top of seeing what people really wanted, and being able to present a very well-prepared version of that product before other companies were able to. And, personally, it's not what I saw with the Apple Vision Pro. Like, it wasn't the obvious missing space that was there when the iPhone or the iPad showed up.

+ +

WENDELL: Yeah, I always go back to, like, the "Why?" question. You know, previously when...even just before we had talked, I was talking about comparative religions, and why that's so valuable is because it really teaches you...again, I've had this conversation before, but the comparative religions, if you think about religion as a tech company, they're always trying to solve why. Like, why did the sun come up? Why did this happen, right? And you always have to do that. So, apply that to technology, Google or Apple, why does this product exist? And when you get to, like, it just existed to make money, I think that's really the 3D thing. Whereas, like, why did the iPhone exist? It existed to solve this problem of being portable on the go and getting information in the way that we communicated, too.

+ +

VICTORIA: Yeah. I think the Apple Vision Pro appeals to a very specific market segment and that that segment is not me [laughter]. I, actually, during COVID...after...it was, like...yeah, we're still in COVID. But during the pandemic, I moved from DC to California. And to connect with some old friends, I bought a VR headset and decided to go to virtual coffee with them. And it just makes me nauseous. And it actually affects...quite a lot of women get nauseous in VR. For some people, the look—the capability is really exciting. They have the extra money to spend on gadgets, and that's what they like. And it's very appealing, and the, like potential, is really interesting. I just find it for myself. Personally, I'm more drawn to tech that's not maybe cutting edge but solves problems for actual people.

+ +

And kind of why I'm interested in PrimeLab, what you were mentioning is just how artists can use this technology to protect their creative work. To give that power back to people and that control over their content, I think, is really interesting rather than...I'm not really sure what I would do with the Apple Vision Pro [laughs]. Like, the early ones, I mean, it's cool. It's fun. I definitely enjoy it. Like, I sometimes like to learn about it, but it's not my passionate genre of tech that I normally go for.

+ +

WENDELL: Going back to what you just said about, like, control, like, part of the thing is because of the hash IDs that we put into place, like, you don't need analytics. You don't need cookies or anything else, like the content holder. Basically, like, if you have a TV set or something and you want to stream content to it, you can actually see that information directly yourself. So, it takes the person generating it and the person viewing it. It forms...we call them function access keys. It forms a one-to-one relationship, basically, where you guys know if you want to know what you want to know, but then you choose to give access to the platform if you want to, which changes the dynamic of control quite a bit.

+ +

And it's interesting because when you look at platforms like the Apple Vision Pro, and you look at Apple's whole entire system as a whole, just trying to lock in people, I think it's interesting because something like what I just described, Apple can't really stop. It's how compute works. So, if people want to use it, there's nothing they could do to stop it from being used. So, I'm really interested in the product stuff and just more about, like, how...and I'm curious what you guys think on this, too.

+ +

Especially as you see phones and processors and everything else, I'm really interested in, like, how these things come about, like, how things are actually built and developed and the why for that, like, in the everyday use. So, like, the Apple Watch it started off as a fashion thing, which looked like a money grab, and then the why was, oh yeah, fitness. So, just curious if you guys have seen any other products out there that you're like, oh, this really resonates with me and the why.

+ +

JOE: Yeah, I'm not really a gadget person, but I think the idea of taking some of the capabilities that we've gotten with the internet and with phones and making them hands-free was interesting. And that, to me, was what I think started pushing the development of products like the Apple Watch or Google Glass. Like, I think that hands-free capability, the trade-off became rewarding in the fitness field, but I think it's more generically applicable. I think that technology it's too obtrusive in other scenarios and too bad at its job to do some of the things it could do. And people got creeped out by Google Glass. But it doesn't really seem like the Vision Pro fits in there. Something being successful hands-free means it becomes less obtrusive, whereas the Vision Pro is like you become a cyborg.

+ +

VICTORIA: Do you have anything else you would like to promote?

+ +

WENDELL: I wouldn't say necessarily promote as much as like people with ideas or aspirations, like, I think it's important that you think counter to what everyone else is doing. There's that line of, like, when everyone else is running in one direction, run the other. And it's like, if you have a business or startup idea, really think about your market. Like, think about why you're doing what you're doing, and don't be afraid to just go out there and talk to people. You will get value no matter who you talk to.

+ +

So, like, I'm a hugely tech-based person. My wife is a therapist, and I learn from her everyday things about emotional intelligence and all kinds of things that I would be an idiot otherwise. But also, learn, like, you can always learn something from someone. Like, take the time to listen to them. Take the time to actually, like, try and figure out what's one thing I can learn from someone, even if, you know, I learn stuff from my daughters even. Like, don't put things in boxes. Like, try to think outside of like, how can I ask a question to learn?

+ +

VICTORIA: I love that advice. That's great.

+ +

WENDELL: Have you guys used Suno before?

+ +

VICTORIA: That's music, right? Music AI.

+ +

WENDELL: All right, I got to show you guys this. We're going to create you a quick theme song. Like, this is what I mean by, like, it's an interesting solution for why.

+ +

VICTORIA: That does sound fun. I like the ones...like my friend's a doctor, and she uses AI to take her conversation she's having with patients and automatically fill out her notes. And it saves her, like, 20 hours of documentation every week. Like, I like that kind of app. I'm like, oh, that makes a lot of sense.

+ +

WENDELL: What's a style of music that you guys really like?

+ +

JOE: Swedish pop

+ +

VICTORIA: Like ABBA [laughs]? I'm down for an ABBA Giant Robots theme song. Sounds great.

+ +

WENDELL: I think you're going to like this.

+ +

[Music Playing]

+ +

VICTORIA: These are awesome. They're super fun. Thank you so much.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on X @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Special Guest: Joe Ferris.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido welcomes Wendell Adams, CEO of PrimeLab.io, as he talks about his lifelong passion for technology and entrepreneurship. Wendell shares his experiences, from hacking electronics as a child to studying various fields in college and eventually starting his own business. He emphasizes the importance of understanding market needs and leveraging language to make technology accessible. Wendell's drive to improve encryption and data security led to the formation of PrimeLab; a company focused on making encryption functional and accessible without compromising performance.

+ +

Wendell discusses PrimeLab's strategic direction and market fit. He outlines the challenges and opportunities in the entertainment industry, emphasizing the need for innovative solutions that respect user control and privacy. Wendell also shares insights into how PrimeLab's technology can democratize data access and enhance business processes. The episode concludes with a reflection on the future of AI and encryption technologies and Wendell's advice for aspiring entrepreneurs to think critically and creatively about their ventures.

+ + + +

Transcript:

+ +

 AD:

+ +

We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP.

+ +

Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. 

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Wendell Adams, CEO at PrimeLab io. Wendell, thank you for joining us.

+ +

WENDELL: Thanks for having me. So, question, actually, where'd you guys come up with the name?

+ +

VICTORIA: You know, I have asked this before, and I think I remember the answer. I might have to go back to the 500th episode to get it, but I think it was just robots was already kind of a theme at thoughtbot. I mean, thoughtbot, obviously, has robot in the name. Joe might have the best answer. And we have our special co-host, Joe Ferris. Who better to answer?

+ +

JOE: [chuckles] Yes, I'm not sure who better to answer, probably Chad. I don't remember the answer either, but happy to be here to speculate with the two of you. It comes from the blog. We named the blog Giant Robots Smashing Into Other Giant Robots and then used it for our podcast. But I don't remember where the blog name came from.

+ +

WENDELL: It kind of reminds me of the Robot Wars thing, like, where they would have competitors driving around the robots and then smashing into each other, trying to flip them over and disable them.

+ +

JOE: That was excellent. I also watched that.

+ +

WENDELL: [laughs]

+ +

VICTORIA: Yeah, it's a pretty great name. I really enjoy being a host. And, you know, I go out to local San Diego events and meet people and introduce myself as a co-host of Giant Robots Smashing Into Other Giant Robots. It's usually pretty funny [laughter], which is where I met you, Wendell; we met at a San Diego CTO Lunches, which was super fun.

+ +

WENDELL: Yeah, I always enjoy any type of tech conversation or anything else. I thought that was a lot of fun to sit down and just talk with people and talk about what they're working on.

+ +

VICTORIA: I love that, yeah. And before we dive into the tech and get to hear more about PrimeLab, I just want to start a little more socially question. What did you do last weekend, Wendell?

+ +

WENDELL: It was my father-in-law's birthday party at Legoland. We took my daughters my mother-in-law, and we all went to Legoland. It was a lot of fun. Although, honestly, I prefer the San Diego Zoo over Legoland, so...

+ +

VICTORIA: Can you please describe what Legoland is to people who may not know?

+ +

WENDELL: Okay. Legoland is based in Carlsbad, and it's really ideal for, like, four to nine-year-olds. And they have, like, miniatures of all the different cities. Actually, the SF miniature that they have is crazy detailed with Chinatown and everything else. They did an amazing job there. They actually...I think they just redid the San Diego part of it. But the miniatures are really cool, seeing all this stuff.

+ +

They have different rides performers, but it's definitely, like, one of those things that it's more for kids to go and kind of experience. If you're an adult, you're going to love a lot of the processes that go into place, like how they built things, but mostly, yeah, it's very much kid rides and stuff like that.

+ +

VICTORIA: I imagined it to be, like, life-size Lego buildings, but maybe I'm...that's very interesting all those other things you could do there.

+ +

WENDELL: Well, like, they have the One World Trade Center, and I think it's, like, 25 feet tall. It is, like, the replica of it. It's kind of interesting, too, because not all the Legos that they build, they're huge, are solid Legos. So, it's like, they'll do where it's like, on the outside, they'll do a base, and then they'll build it. There's a replica of a Lamborghini. That one's life-size. But it's heavy. It's, like, 2,000 pounds, something like that.

+ +

VICTORIA: Is that as much as a regular Lamborghini weighs, too, 2,000 pounds? It can't be that far up.

+ +

WENDELL: I don't know. No, I don't think it...no, it couldn't be.

+ +

VICTORIA: I have no idea how much cars [laughs] weigh. What about you, Joe? Did you do anything fun this weekend?

+ +

JOE: Not a lot. It was supposed to be my son's first soccer game ever, but it rained here in Boston, so they postponed it. Sunday he went to my parents' house for a grandma day, and so I did nothing. I ate cookies.

+ +

WENDELL: [laughs]

+ +

VICTORIA: Wait, what kind of cookies were they, though?

+ +

JOE: They were chocolate chip cookies.

+ +

VICTORIA: That's so good.

+ +

JOE: They were good. They were brown butter chocolate chip cookies, I should say.

+ +

VICTORIA: Were they homemade, or did you get them somewhere?

+ +

JOE: They were. We made them in this home.

+ +

VICTORIA: Oh, that's the best. Yeah, love that. I got some fancy cookies that someone else made, and they were also [laughs] very good. And then, yeah, I've just been having cookies pretty much every day. So, that's been my time.

+ +

WENDELL: My mother-in-law recently made me peanut butter cookies, and those are my favorite kind of homemade cookies.

+ +

VICTORIA: Okay. Noted. You'll get a post-podcast gift of peanut butter cookies [laughter]. I love that. It's so great to hear a little bit more about each of you as, like, in a personal way before we dive into AI. And tell me a little bit more about your background and what led you to PrimeLab.

+ +

WENDELL: I've always kind of, like, been a hacker, so to speak, just from a technical standpoint. My one grandfather was an engineer. He worked for GM designing, like, assembly arms and stuff like that. And then my other grandfather was a master electrician. So, I've always been the person that, like, just worked on things, got stuff together.

+ +

You know, there's a lot of stories. Like, there's the story about when I broke my grandmother's workbench, rocking bench out front, and it was all aluminum. I remember telling my grandfather, and he's like, "Oh, what are you going to do?" And I was like, "Buy a new one?" He's like, "You got money?" I said, "No." And he said, "Well, you better figure how to make it then." So, ironically, it's half aluminum, half wood. We took wood, sanded it down, and stuff.

+ +

So, it's just like I've always been an entrepreneur. I've always been interested in this kind of stuff. I used to hack VCRs, and PlayStations, and all kinds of stuff. I always liked parts and components and rewiring things. And as I got older, I also really liked math and all those things. And I wanted to understand more about how the world works, so to speak, like why it works the way it does, not just from a technology standpoint. But why do people think the way that they do? Why do things behave the certain way they do?

+ +

So, initially, I started going to college. I thought I might be a math professor, and then decided to get degrees in business, economics, finance, marketing, consumer product goods, and comparative religions. So, while I was in college, I started working on, like, hacking, different video games, writing JavaScript, writing Java, all kinds of stuff. And then, eventually, even writing mobile applications early on, and then just analyzing because I always liked to build phones, too. I would take apart phones. And I really was curious about, like, how to make things faster, more efficient, and better. So, now to bring it down, like, how to make things accessible, where it benefits some of the smallest people and make it where it's a greater opportunity for someone to come out ahead of something.

+ +

Like, one thing that I learned from my marketing degree is language matters. So, it's like, all the marketing it's not anything special. It's just they intentionally create language barriers that cause people not to feel as accessible with it. And then, like, you hire a consultant or something to just basically teach you about those language barriers. And I think every industry has, like, SAT, or LTM, or something like these abbreviations that mean a lot of different things. And it causes bottlenecks if you don't speak the language. So, understanding the language but also learning about how was very helpful from a standpoint on the marketing side. And I always try to figure out how do I make this accessible to people who don't understand that language?

+ +

VICTORIA: And what was the turning point where you decided to start PrimeLab, and what made you realize there was a company there?

+ +

WENDELL: It was a project I've been working on since at least 2011, honestly. And just as a heads up, PrimeLab as a whole works with encrypted data for AI models and to speed that up and everything else. So, early on, I was very obsessed with how advertising works through, like, stealing user data, which stealing is different, here or there, the sense of privacy, the sense of, like, how things could run, and the sense of messaging.

+ +

And initially, a lot of it was using encryption as an overlay in, like, the pixel application space, which is always a way to hack or get into it. And it slows everything down. So, I had always been working on trying to figure out how do you speed up and embed security so it's actually functional? And it took a while to figure out, like, give encryption functionality, like, make the encryption something that you could actually execute on.

+ +

And, actually, one of the things that really helped is the blockchain space there's a lot of, like, hash trees and everything else, like, where people are innovating in that. That's really helped innovate encryption as a whole from understanding, like, Merkle trees, hash graphs, and everything else to make it more functional and faster. Because people are trying to speed up distributed networks and stuff, but the actual technology that they built, like Hedera is...What Hedera has done with Hashgraphs and everything else—really amazing. I'm glad that they open-source stuff like that.

+ +

But it's also really interesting just to see how things push forward. So, like, when I first started, like, RAM was, like, 256 in a phone. So now, you know, you can get multiple gigabytes, which makes it a lot more capable to do encryption, decryption, and work more in the functional space of things. The bigger problem that you have on the data part is how an application communicates because there's so many levels of abstraction. Like, you have the Swift language that communicates into something else that then communicates into something else.

+ +

Like, right now, we're talking on a system that's recording us over the internet through a browser, all those different things. And it's an approximation of what the data is and what we sound like. It's not an absolute. So, I was really interested in when you have absolutes, and you can verify those absolutes, what can you do with that?

+ +

A few years ago, I felt like we got to a point where we could actually execute those things and actually deliver on that. So, therefore, I decided to start PrimeLab with my co-founder, who I really liked and enjoyed. And we've had a lot of really great advisors, where people have helped us continuously. Over, you know, the decade-plus of working on this, I've gotten a lot of input from some of the smartest people I know, from people who have designed full server racks for AWS to literally a good friend of mine that built cloud storage. His name's on the patent for it. So, that kind of stuff has really helped me understand and build this where it can communicate the lowest possible level.

+ +

VICTORIA: Yeah, and to just recap and reflect that back a little bit, it sounds like you were always interested in how to make encryption faster and lighter weight, and so you could build it in and build in security without impacting the performance of the applications. And then meeting your co-founder and the advancement of technology, this time a couple of years ago, led you to think, okay, let's really go forward with this.

+ +

WENDELL: Kind of rephrasing, I was always interested in control. So, like, one of the things that really interested me...so, I started a video game store buying and selling, like, video games and trading cards and stuff when I was roughly ten and a half or so, and then sold it roughly when I was 17, which is how I paid for quite a bit of college and likewise. But the things that really interested me about that is it went out of business three to four months afterwards because the person who basically bought the rest of it bought too much of Madden. And Madden, at this time, the margins were, like, a buck, as you go all the way through, and the price drops immensely.

+ +

So, I wanted to really understand why that happened. What you kind of get to is, like, they didn't have control over it, just, like, the bulk orders methodology, where they would buy the whole entire supply. And what I've seen over the years, be it Apple, Google, or anything else, is, like, that was...in that example, that's a game publisher, EA, flexing control, right?

+ +

But more and more companies are flexing control on a platform like now with Facebook or advertising. If you think about what Google used to do, Google used to provide a lot more insights when you had your own website. You used to know your own keywords. You used to know a lot of things about your users who come through. More and more, Facebook and Google try to stop that. And they're really the ones determining your own user personas for you. So, you become dependent upon them.

+ +

So, I wanted to say, okay, from a business standpoint, how do you implement control and privacy where it's permissioned? And encryption was one of the answers that I came to. But then it was, how do you make encryption functional then to actually execute on control? Because unless the system is secure, faster, cheaper, better, it's never going to get adopted.

+ +

VICTORIA: That makes sense. Thank you for sharing that. And you mentioned your founder. I'm curious, how does your founder kind of complete what you needed to be able to get the business up and running and off the ground?

+ +

WENDELL: He has a robotics degree, so he had launched several products that had failed. And he wanted to learn marketing after they had failed. So, we have a similar like mindset about, like, control and functionality for how something may or may not work, and that allowed us to communicate well. So, like, I have a lot of friends and stuff. But the thing that allows me and my co-founder to work really well is that we come from things in different angles, but we have the same language that we speak.

+ +

So, like, that's what I was talking about before, like, LTMs or otherwise, like, language really matters from how you can move something forward when you're talking in different industries. And just with him, there's a lot of stuff that you don't have to say. You can skip a lot of filler and then go straight to what something might be or a solution or something. Or if we have to jump to a tech abbreviation, to a market abbreviation, to a financial abbreviation, he's one that can follow along with me really quickly and then teach me a lot of things about operational execution because he's great at operations. I am not great at operations.

+ +

VICTORIA: That's really interesting. And I think you're making a good point about, like, a shared language. And it reminds me of any product that you're building; if you want to sell it to a company and you want them to adopt it, you have to consider their language, their belief system, how to influence change within the organization. And I wonder if you could talk a little bit more about that with your experience at PrimeLab.

+ +

WENDELL: I'll give you an example of a market that we decided to go after. So, instead of just working at, like, healthcare markets where you have, like, GDPR...for people who don't know GDPR or HIPAA, HIPAA is for the United States. GDPR is the EU privacy requirements, right? For the right to be forgotten and everything else. So, these are vernaculars that you need to know. But the requirements of each one is very different, and these are markets that we've learned being in tech and likewise. But we wanted to change it up.

+ +

So, I wanted to go after the entertainment market as a whole, namely because after meeting with some select people, including a stunt man, this is going back a few years ago, I started to realize that the entertainment market was getting kind of screwed over quite a bit from a tech standpoint. Basically, tech goes through this thing where...someone wrote a great article about this. It's called Enshittification. But, basically, where they go they try to take over a whole entire market, where first they're providing great value to your users. And then, gradually, you enshittify your product to provide greater value to your investors. And then, gradually, you suck all of the value out of the room for both.

+ +

Right now, if you look at Sora, what OpenAI is trying to do in entertainment, [inaudible 16:08], you kind of can see that happening. They're going, "Hey, here's a great value for it." And they're really pushing that stuff off. But the thing about the entertainment market that I think is really interesting is it's basically thousands and thousands of small businesses that are constantly going, it's so chaotic. It's not like tech and startups. There's a lot of overlay of, like, you know, people are looking for that top quartile film that's going to make the money back, and then long-term royalties that they can earn off of it, right? Whereas in tech, they're looking for those huge markups as well.

+ +

So, I was really fascinated by it, but it was something that, like, we had to learn. Like it was something that I didn't know otherwise. So, it was literally...how we learned it was we took our tech stuff, and we would walk SAG-AFTRA strike lines. We would walk strike lines. We would go to entertainment events, and we would demo what we were trying to do, and we would show them. And then, oftentimes, we got really negative feedback right off the bat. And we're like, "No, no, no, so, you know, this is for you. Like, you could control. Like, this is going to help you."

+ +

And then, after doing that enough times, talking to the SAG-AFTRA lawyers, and everything else from there, and all of the creatives, the creatives were coming to us and giving us ideas how to explain it because there's, like, three different formats. You have tech, business, creatives in the entertainment industry. And it's like, we could talk to the tech people. We could talk to the business people. But you really need the creatives. And, like, the wording of each one, like, each group of those is vastly different.

+ +

So, having the creatives be able to explain something in 90 seconds that used to take me a couple of hours to dive into became really valuable. And also, in tech, like, you have this thing where it's feature creep, where you're like, oh, I'll add this, this, and this. Just to hear very coldly and bluntly, like, "If it does X, I'm interested. If it does Y, I'm not interested." That was very interesting or refreshing of, like, "Yes, you're going to solve these problems. But I need sign-off for everything in there."

+ +

And it's kind of weird in the entertainment part, too. Like, you want to solve a problem without being a competitor to another vendor because you need so many different sign-offs. And if you're a competitor to another vendor, to a certain point, maybe that's going to cause a hiccup with sign-offs because there's 18 different cooks in the kitchen, so to speak, just so many different people that need to say, "Yes," all the way through with it.

+ +

VICTORIA: Thank you. Yeah, that's really interesting. I'm curious, Joe, if you have an answer for that question as well, like, any experiences about navigating change and putting new products in place at different clients, different industries?

+ +

JOE: I don't think I've had the same kind of resistance. Like, I haven't been on the front lines the way you described, like, literally in the, you know, going and talking to people on strike. I think I have more indirect experience talking to the people who are doing that.

+ +

And certainly, like, I think there's generally a resistance to bringing in new technology without eliminating the old way of doing things if that makes sense. Like, people want the old ways of backup. Like they want to be able to go back to paper, which I empathize with. But that's frequently been a challenge for the people I've worked with is that they don't fully embrace the new process, which significantly reduces the value they would get from using it. I don't know if that's something you've encountered with PrimeLab.

+ +

WENDELL: So, we were building another company of mine many, many, many years ago. I was building a website for this lumber company, and I remember showing up, and the owner was there. But it was his son that had commissioned it, and the owner didn't know about the website. And I was like, "Oh yeah, we'll get the website going." He goes, "Oh, this web thing it's a fad. It's never going to happen. You don't need websites. It's faxes." That's how everything would happen. But secretly, what was happening is they would get an order. They would print it off, and then they would fax it. So [laughs], I always thought that was crazy.

+ +

VICTORIA: I mean, one of my local bars still just writes the order on a ticket and sends it on a clothesline down to the grill. So [laughs], sometimes old is good. But I think that you know, I want to hear more about where you found or how you found a product-market fit for PrimeLab and where that AI really becomes useful and ethical in the industry you're focusing on

+ +

WENDELL: How I look at PMF (product-market fit)...and if you hear me just say PMF, that's what that means. So, how I look at PMF is I'm a little different in the fact that when I look at a product, or a technology, I don't just look at, like, so you have foundational tech. Like, okay, this is encryption. This is control, right? Now, where's the market that has the biggest problems with it? So, I like to go out and actually talk to those people. Because, like, when you're implementing tech, or you're implementing the product itself, it's different. So, you're like, you have the underlying infrastructure, but whether that's a button or a simple API that you need to build so it works different to hit that PMF...are you familiar with the term build a better mousetrap?

+ +

VICTORIA: I don't think so.

+ +

JOE: I'm familiar, but I'd still love to hear you describe it.

+ +

WENDELL: So, in business school, and likewise, they will tell you "If you build a better mousetrap, people will come, and they will buy your product." So, like, it's a common thing where they're like, "Build a better mousetrap. People will come. They'll be there." And the thing that you learn with consumer product goods and marketing, though, is they actually built a better mousetrap, and it failed.

+ +

And the reason why it failed is you had a mousetrap that was roughly a cent versus another mousetrap that was three cents. And I think this is in the '60s or so. The other mousetrap was reusable, so it executed a lot better, and everything else is more humane. But what they didn't understand is that it was wives most of the time that would have to actually handle this. And they didn't want the mouse alive, and they didn't want to reuse the trap. They wanted them to actually be disposed of right away.

+ +

So, by not understanding the market, even though they built a better mousetrap, they'd missed the point. Like, the main problem to solve wasn't killing the mouse or having it be reusable. The main problem to solve was, like, getting rid of the mouse. So like, if you have a solution for getting rid of the mouse, the next thing is your execution for it. Like, does it hit the actual market, which is the fit aspect?

+ +

Like, every product is a little bit different where you look at, like, how does this fit in? So, in this case, fit is very important for, like, disposing of the mouse, which is why you also have, like, you know, mouse poisons are popular, even though they're terrible because they die somewhere and, hopefully, you don't see them. And it's like sight unseen, right? Now, I'm glad, like, that's changing and stuff.

+ +

But it's understanding even if you have a solution to something, you need to understand what your market wants out of your solution, and it's not going to be an abstract. It's going to be an emotional, like, execution-based process. So, you kind of have to go, all right, this is my market. This is kind of my fit. But the actual product I'm building is going to change to make sure it works all the way through with this.

+ +

I was advising a startup many, many years ago, and they were building this CRM software on Android for South America. And I think they were building it for Android 6 or 7 at the time. But the market that they were targeting, they all ran Android 4.1. So, they spent a little over a million dollars building for the wrong version of Android that wouldn't even work on that version of the system. Like, it was one of those things where they were required to build it for that. But they didn't understand the actual market, and they didn't spend enough time researching it. So, it's like you get the Bay Area groupthink.

+ +

If they had actually spent the time to analyze that market and go, "Oh, they run, you know, an inexpensive phone. It's 4.1. It's low RAM," now you can design a product. If you want it to be a CRM, you're going to, like, chunk up the system more. Like, you're going to change all that instead of just wasting a million dollars building something that now you basically have to start over again from scratch.

+ +

VICTORIA: That seems like he got off cheap, too. People make way bigger mistakes that cost way more money [laughs] because they [inaudible 24:13]

+ +

WENDELL: Well, that wasn't me. That was an investor that --

+ +

VICTORIA: Oh no. I mean, yeah, not just them. Yeah.

+ +

WENDELL: He's like, "What would you do?" And I was like, "You should sell this company or sell your stake ASAP because that's a really bad sign."

+ +

JOE: I have found that the answer nobody ever wants when you're doing product validation or testing product fit is, "You should not build this product." The idea that the software just shouldn't be written is universally unpopular.

+ +

WENDELL: Yes [laughs]. That's, you know, that's part of the reason why it took me so long to do PrimeLab is because, like, it took a long enough for the software to actually need to be written, if that makes sense.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: What does success look like now versus six months or even five years from now?

+ +

WENDELL: I take a different approach to this because I have so many friends that have sold their businesses. They raise and everything else. I look at success as instead of an exit or another large thing, like, literally, we turned down a billion-dollar term sheet offer. I didn't like the terms. I didn't like what it would do from the control standpoint of the technology. What I care about is go-to-market and, like, adoption and actually getting the tech out there in a way that has market penetration but, like, that adds value to every person's life.

+ +

VICTORIA: Yeah, maybe say more about that. Like how do you see AI and this technology you have with PrimeLab benefiting people and benefiting the industry that you're working within?

+ +

WENDELL: So, the current AI models are kind of weird. They're basically just filter systems because they communicate in pixel space and then go down to functional space. It's the GPU. GPUs are actually terrible to use for AI. This is why you have dedicated AI chips getting built. Hopefully, the RISC-V chipset does actually do something because that's a chipset that I think it's an open-source chipset, but you can actually especially build models on it.

+ +

So, I think that we're going to see a lot more in the RISC-V chipset where it's like, this is just for one particular image, or this is just for explosions, or this is just for touching up all these different points in the actual individual, like, microcontroller module data that ends up compiling to move forward with it.

+ +

But the AI models now it's like you took the internet, and you're trying to ask it a probability question, what I was talking about before, where it's not an absolute. So, it's like, if I want to do an OCR system or anything, I take an image. It's got to say, "This is..." letters; it's going to recognize that. So, there's, like, multiple models and algorithms that need to run on that whole entire process. You even have artificial data, but all of that information is an approximation. It's not an absolute. If you want absolute, you can get a lot of absolute data from the actual hardware devices themselves. You know, take a Sony camera. You could see the lighting. You could see the raw information, everything else there.

+ +

But because of how expensive it is, people compress it. Like, take YouTube where it's compressed, and now you're training off of it. You're trying to compress it more and then run an algorithm so that you don't have to actually process those large, raw files all the way through. That's just a bad infrastructure for compute. You're trying to reduce, but you're also trying to utilize what you own for rights, same thing, contextual, or anything else there. There's no value in a model. Once a model is out there, it's just weights moving it back and forth. The value is in the data and the applications. So, the actual data itself that's going in.

+ +

So, if you have just lava scenes, like, having all that data for lava, and I want to put it in a background, now I can do that, but more importantly, it's not about just adding it into the background. The thing that is often missed is contextually the output. So, like, say I want to do a financial report. Rather than having the data of all financial reports out there, what I want as the input is my financial data. And what I want as, like, a fine-tuning output is an example of the reports that were generated. And I don't want those reports as the input to inform the output because that's where you get a hallucination. Maybe it starts grabbing financial data from someone else.

+ +

And I also think we're in store for a lot more hacks because with not just poisoning data, which we do in the functional space, if someone tries to access it. But, I mean, literally, there's the story...I think the guy was in Hong Kong, where they faked his board all the way through with it. Because you have agents acting and executing on people's behalf, you're going to have systems where people go onto the hardware and start generating fake financial numbers. And now that's going to get reported. Or you pay an invoice that you weren't supposed to pay because someone manipulated your AI agent.

+ +

And a lot of the stuff that we're seeing now from Microsoft and everything else that's not really where the models will go. It's great to do it, but it's kind of like we're in the dial-up stage of AI. Like [chuckles], dial-up has its use cases and stuff, but it's nowhere near what the tech will look like in the future, and it's nowhere near how it will function.

+ +

And one of the big pushbacks that you see, like, from Google, from all these different places, like, they want your attention. But at the end of the day, Google's an ad company. Facebook's an ad company. It's not in their best interest to have hyper-localized data that you control for your models and likewise. They want it in the cloud. They want it used there, where they can control that data, and they can monetize and advertise for you. But at the same time, like AI models work the best, and AI applications work the best when the data set is limited, so it can't hallucinate, and when the outputs are actually controlled to what it should be from an informed standpoint. So, where we're at this is just in the beginning stages of stuff.

+ +

VICTORIA: That's really interesting. Thank you so much for sharing. I think if you could go back in time when you first started PrimeLab and give yourself some advice, what would you say?

+ +

WENDELL: You know, I lived through the Great Recession. The Great Recession informed me a lot more. The things that I didn't understand this time...like the Great Recession, was market contributors doing stuff that impacted everyone with their spend and their adoption, and how those things were. But the Fed raising interest rates, which is, you know, Silicon Valley Bank failed and stuff like that, that dynamic of those startups and, like, how much startups power everything, like, I would have advised myself to pay more attention to the Fed and those market dynamics going forward.

+ +

Because what changed is it's not just the Silicon Valley Bank failed it, you know, Rippling went down, for instance, which would pay therapists in Florida and all kinds of stuff. Like, it broke so many different things. It caused bottlenecks in business that we're still going through. Like, everyone's like, "Oh, we're getting back to normal." Really not. It's still, like, delayed all the way through it.

+ +

The AI aspect is really getting back to normal, where people are really pushing AI. But if you look at SaaS and other industries, it really, really slowed down. And the reason why that matters is, like, in my field, production and timelines matter. So, when you have that plus, you know, the entertainment strike and everything else, you have things where the actual production of things starts slowing down immensely. Whereas AI is one of the few things that you still have innovations because that never really slowed down, same thing with the models. But all the rest of the industries and stuff have really slowed down.

+ +

And understanding what that means from an operational execution standpoint...it's a good thing I have my co-founder [inaudible 32:24]. It matters quite a bit because it means your team sizes have to change, how you handle certain clients has to change. Because once those companies start downsizing or laying off people for whatever reason like, that's going to change how you're working with them, and their requirements are going to change as well.

+ +

VICTORIA: And what do you see on the horizon as a challenge or a big hurdle that you face as a company or as an industry?

+ +

WENDELL: You know, the entertainment market's really interesting from all the different sign-offs. The challenge is more execution of timeline. So, like, if you're doing something with, like, Nvidia and the healthcare thing, it could take years. If you're doing something in, like, the IoT space, you know, also years. If you do something in the entertainment space, it could take weeks to months, except the large studios. The larger studios, it could take a couple of years as well.

+ +

But going to market, I think, is a very big challenge, not just for us but the whole entire industry. I mean, there's a reason why Sam Altman came down to LA to meet with studios, to try and get stuff moving forward. And I think one of the things that he's forgetting is like, you think of Netflix. Netflix is streaming. In order for that to work, they needed Roku, and they needed Kevin Spacey because [chuckles]...it's crazy to say that, but House of Cards is kind of what made it, right? And Hollywood was mostly boxing them out quite a bit. Same thing with Blockbuster otherwise. They had to drop a hundred million dollars, a large enough bankable star at the time that would really push something forward. And they had to basically really push Roku out there so that they had PMF across the board.

+ +

What that means, though, is, like, Netflix is paying for content like crazy, right? So, this is kind of enshittification in a process. So, they're paying for content like crazy. So, now Hollywood's making money. They like it. At the studios, they don't love it when their stuff's going there because maybe it's less money, but now they start cutting the seasons short. They start cutting...it's a lot more algorithmic-driven. You have the ad systems that sort of come out. So, now, like, Netflix is not just doing ads where the customer experience is getting worse, but now, also, the business experience for those partners selling stuff is also getting worse, and all that value is getting driven to Netflix. Like, that's the tech system and Hollywood's learned that.

+ +

But, like, when you're looking at the next adoption, like, they're hesitant for that. Just like a lot of stuff with AI, they're hesitant because they're thinking about all the power and control that they gave up. But you have to show how they're going to make money. You can't just cut costs, right? If you can't show how they're going to make money, you're not going to get adopted. That's kind of what I like there because so much of tech is about saving costs and being more efficient. In the entertainment industry, it's not just those two things. It's how can I make more money? And it's going to, like, ooh, you can monetize your content through training samples and stuff like that.

+ +

So, our model goes exactly against what the large tech companies have where they want to take content, train on it, like the search engine does, suck the value off Sam Altman's Sora. Ours goes, all right, this is your content. Only you own this. You can take your own content, train it, and then perform this operation on it that is more efficient likewise. And if you choose to monetize it in any way, shape, or form, we can just take the functional space, not all the images and no one will ever see it, and take that functional space for training so that you can actually monetize from that as well.

+ +

VICTORIA: I love that. Super interesting. Thank you so much for sharing. And do you have any questions for me or for Joe?

+ +

WENDELL: I've noticed a lot of differences on, like, applications and how systems are built. So, I'm kind of curious about you guys' standpoint about applications, you know, the Apple Vision Pro. Facebook just said they'd start licensing out their AI system, or Meta, whatever. So, you have the comparisons to Android versus iOS that's happening, stuff like that. So, I'm really curious about, like, you guys' thoughts on the Vision Pro and that ecosystem.

+ +

JOE: Well, I can't speak for all of thoughtbot, but I can say that, to me, it was interesting to see that get released. And it's been interesting to see how aggressively Meta and Apple have been pursuing the various VR markets. Like it reminds me of when television companies and studios worked really hard to get 3D movies to be a thing.

+ +

WENDELL: [laughs].

+ +

JOE: Because I think they just ran out of things that people are asking for. Like, people were interested in getting better resolutions up to a point. Like, they wanted better packaging. But it got to a point where it was like, they didn't want to give anybody anything they were asking for. So, they were like, what if it's in 3D? And, like, for years, it seemed like Apple was really on top of seeing what people really wanted, and being able to present a very well-prepared version of that product before other companies were able to. And, personally, it's not what I saw with the Apple Vision Pro. Like, it wasn't the obvious missing space that was there when the iPhone or the iPad showed up.

+ +

WENDELL: Yeah, I always go back to, like, the "Why?" question. You know, previously when...even just before we had talked, I was talking about comparative religions, and why that's so valuable is because it really teaches you...again, I've had this conversation before, but the comparative religions, if you think about religion as a tech company, they're always trying to solve why. Like, why did the sun come up? Why did this happen, right? And you always have to do that. So, apply that to technology, Google or Apple, why does this product exist? And when you get to, like, it just existed to make money, I think that's really the 3D thing. Whereas, like, why did the iPhone exist? It existed to solve this problem of being portable on the go and getting information in the way that we communicated, too.

+ +

VICTORIA: Yeah. I think the Apple Vision Pro appeals to a very specific market segment and that that segment is not me [laughter]. I, actually, during COVID...after...it was, like...yeah, we're still in COVID. But during the pandemic, I moved from DC to California. And to connect with some old friends, I bought a VR headset and decided to go to virtual coffee with them. And it just makes me nauseous. And it actually affects...quite a lot of women get nauseous in VR. For some people, the look—the capability is really exciting. They have the extra money to spend on gadgets, and that's what they like. And it's very appealing, and the, like potential, is really interesting. I just find it for myself. Personally, I'm more drawn to tech that's not maybe cutting edge but solves problems for actual people.

+ +

And kind of why I'm interested in PrimeLab, what you were mentioning is just how artists can use this technology to protect their creative work. To give that power back to people and that control over their content, I think, is really interesting rather than...I'm not really sure what I would do with the Apple Vision Pro [laughs]. Like, the early ones, I mean, it's cool. It's fun. I definitely enjoy it. Like, I sometimes like to learn about it, but it's not my passionate genre of tech that I normally go for.

+ +

WENDELL: Going back to what you just said about, like, control, like, part of the thing is because of the hash IDs that we put into place, like, you don't need analytics. You don't need cookies or anything else, like the content holder. Basically, like, if you have a TV set or something and you want to stream content to it, you can actually see that information directly yourself. So, it takes the person generating it and the person viewing it. It forms...we call them function access keys. It forms a one-to-one relationship, basically, where you guys know if you want to know what you want to know, but then you choose to give access to the platform if you want to, which changes the dynamic of control quite a bit.

+ +

And it's interesting because when you look at platforms like the Apple Vision Pro, and you look at Apple's whole entire system as a whole, just trying to lock in people, I think it's interesting because something like what I just described, Apple can't really stop. It's how compute works. So, if people want to use it, there's nothing they could do to stop it from being used. So, I'm really interested in the product stuff and just more about, like, how...and I'm curious what you guys think on this, too.

+ +

Especially as you see phones and processors and everything else, I'm really interested in, like, how these things come about, like, how things are actually built and developed and the why for that, like, in the everyday use. So, like, the Apple Watch it started off as a fashion thing, which looked like a money grab, and then the why was, oh yeah, fitness. So, just curious if you guys have seen any other products out there that you're like, oh, this really resonates with me and the why.

+ +

JOE: Yeah, I'm not really a gadget person, but I think the idea of taking some of the capabilities that we've gotten with the internet and with phones and making them hands-free was interesting. And that, to me, was what I think started pushing the development of products like the Apple Watch or Google Glass. Like, I think that hands-free capability, the trade-off became rewarding in the fitness field, but I think it's more generically applicable. I think that technology it's too obtrusive in other scenarios and too bad at its job to do some of the things it could do. And people got creeped out by Google Glass. But it doesn't really seem like the Vision Pro fits in there. Something being successful hands-free means it becomes less obtrusive, whereas the Vision Pro is like you become a cyborg.

+ +

VICTORIA: Do you have anything else you would like to promote?

+ +

WENDELL: I wouldn't say necessarily promote as much as like people with ideas or aspirations, like, I think it's important that you think counter to what everyone else is doing. There's that line of, like, when everyone else is running in one direction, run the other. And it's like, if you have a business or startup idea, really think about your market. Like, think about why you're doing what you're doing, and don't be afraid to just go out there and talk to people. You will get value no matter who you talk to.

+ +

So, like, I'm a hugely tech-based person. My wife is a therapist, and I learn from her everyday things about emotional intelligence and all kinds of things that I would be an idiot otherwise. But also, learn, like, you can always learn something from someone. Like, take the time to listen to them. Take the time to actually, like, try and figure out what's one thing I can learn from someone, even if, you know, I learn stuff from my daughters even. Like, don't put things in boxes. Like, try to think outside of like, how can I ask a question to learn?

+ +

VICTORIA: I love that advice. That's great.

+ +

WENDELL: Have you guys used Suno before?

+ +

VICTORIA: That's music, right? Music AI.

+ +

WENDELL: All right, I got to show you guys this. We're going to create you a quick theme song. Like, this is what I mean by, like, it's an interesting solution for why.

+ +

VICTORIA: That does sound fun. I like the ones...like my friend's a doctor, and she uses AI to take her conversation she's having with patients and automatically fill out her notes. And it saves her, like, 20 hours of documentation every week. Like, I like that kind of app. I'm like, oh, that makes a lot of sense.

+ +

WENDELL: What's a style of music that you guys really like?

+ +

JOE: Swedish pop

+ +

VICTORIA: Like ABBA [laughs]? I'm down for an ABBA Giant Robots theme song. Sounds great.

+ +

WENDELL: I think you're going to like this.

+ +

[Music Playing]

+ +

VICTORIA: These are awesome. They're super fun. Thank you so much.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on X @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Special Guest: Joe Ferris.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+KCxMHxHO + + ]]> + + Victoria Guido + Joe Ferris + + + 526: AI-Powered Leadership with Waggle AI + https://podcast.thoughtbot.com/526 + fbae3662-e432-4b3b-82c5-72bbb598c408 + Thu, 23 May 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Will Larry and Victoria Guido interview Sarah Touzani, founder of Waggle AI, who shares how her pottery hobby influenced her entrepreneurial journey and focus on improving managerial skills and workplace culture. Sarah discusses the challenges and pivots in developing Waggle AI, which aids in meeting preparations, note-taking, and providing feedback on leadership skills to enhance delegation and empathy. + 34:39 + no + + + Hosts Will Larry and Victoria Guido interview Sarah Touzani, the founder of Waggle AI, an AI leadership skills coach. Sarah shares insights from her entrepreneurial journey, discussing how her past pottery hobby has influenced her focus and patience, which are crucial skills in her role as a founder. She explains how her transition from a traditional business school path to a senior role in a fast-growing startup, and eventually to founding Waggle AI, was driven by a desire to foster better managerial skills and workplace culture. +Sarah talks about the early challenges and pivots in developing Waggle AI, such as incorporating AI for automatic note-taking to reduce user friction. She describes how Waggle AI assists in meeting preparations, records notes, and provides feedback on leadership skills, helping managers improve their delegation and empathy skills. She also highlights the importance of blending productivity tools with leadership development to enhance team performance and individual well-being. +The discussion also touches on the ethical considerations and core values driving Waggle AI, to emphasize user privacy and minimizing additional workload for managers. Sarah concludes by outlining her vision for the product, focusing on deepening the AI's understanding of managers and adapting recommendations to individual team members' needs. +Waggle AI (https://www.usewaggle.ai/) +Follow Waggle AI on LinkedIn (https://www.linkedin.com/company/wearewaggle/), Instagram (https://www.instagram.com/waggle__ai/), TikTok (https://www.tiktok.com/@waggleai), or X (https://twitter.com/waggle_ai). +Follow Sarah Touzani on LinkedIn (https://www.linkedin.com/in/sarah-touzani/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Sarah Touzani, Founder of Waggle AI, your AI leadership skills coach. Sarah, thank you for joining us. +SARAH: Of course. Thanks for having me. +VICTORIA: To open us up here, what is a past or current hobby that you enjoy? +SARAH: I need to be honest. I haven't done much outside of working since I started the company. But prior to that, I used to spend a lot of time in a pottery studio making pots, and bowls, and mugs, and gifting them to anyone I meet. +WILL: That's really impressive because I tried it for, like, I think a college class. And if you make one mistake, the whole thing gets ruined. I think I made, like, a little, very small bowl, and that was all I could get [laughs]. +SARAH: Yeah. I'm not surprised. It takes a lot of practice and a lot of extreme focus in a way because, like you said, like, the single moment your hand moves slightly off, the whole thing is over. +WILL: What's the item that was the most complicated or you're the most proud of? +SARAH: I would say a big bowl that I made, which has a bit of an odd shape because, actually, it was going bad. And I kind of caught it back and made that mistake into something done on purpose in the design, and it worked quite well. But it's also not your average pot or average bowl you see everywhere. +VICTORIA: That's really cool. And I echo Will's sentiments of being impressed by people who can do pottery because I did take a class right before the pandemic. And then, the pandemic hit, and we weren't able to fire any of our pieces [laughs]. But I found that it took just a lot of patience, even to be able to figure out the first step. Like, putting the clay onto the spinning wheel and doing that correctly just takes a lot of practice. And so, I'm curious if you find any of those skills or values from doing pottery translate into being a founder. +SARAH: Yeah, actually, this is funny because I wrote a blog article about this a few years ago when I first started. I think there are a lot of learnings to take away from that and bring into work, weirdly. It's that sense of focus. When you're starting a company very early, there's a million things that you want to be doing and, actually, you can't. You need to do one thing and do it well. And the ability to zoom in and focus on one single thing is a massive game changer. +Also, my last job was as busy and insane as the current one, which is being a founder, because it was, like, a senior role in a super-fast-growing startup. And I was always on my phone, or always thinking about work, or always having something coming at me and trying to answer questions and do stuff on Slack. And with your hands dirty, you're actually forced not to do any work and go back to that focus and that mental clarity. And that was also, like, extremely valuable back then. So, saying this out loud makes me think that I probably should go back and do it. +VICTORIA: I recommend it. I did a hand pottery class with my little sister. I have a big sister, little sister mentorship relationship. And we made little ceramics, and it was super fun. Just, like, an hour a week. +SARAH: Super nice. +WILL: So, Sarah, you mentioned a little bit about your background. Tell us more about that. Where did you get started? How did you become a founder of your company? How did the idea come up? Just anything in those areas. +SARAH: Yeah. Sounds good. So, I have a bit of, like, a traditional business school type of profile. I was a good student. I didn't really know what I wanted to do. So, I went into a business school, graduated, went into banking and consulting, which are, I guess, those, like, sexy jobs that you want to get when you are still at school. And I had done them and felt a bit out of place because I wanted to get things to move way faster than they were moving in these, like, very corporate set-in-their-ways type of companies. +So, left that industry and moved to a very early-stage startup. I used to live in Paris back then, and I moved to London. At the same time, joined a very early-stage startup in FinTech. We were four when I joined. And we didn't have a product, didn't have any revenue. And I had to grow that company to about 200,000 customers, 50 million series A, and 80 people in the team, of which I managed about 50. All of this happened in 4 years. +And I was hired into that role because of my background and because of my experience in risk management, compliance, like, all of the very technical aspects of my career. But at the end of the day, I spent most of my time trying to build a culture that motivated people to do their best work that enabled people to perform. And that's not something you really get to learn either at school or, in most cases, at work either. You just need to figure it out. +So, I was trying to find a way where we could enable managers to learn these skills once they're in the job. Because when they mess up and when I messed up as a manager, it had a cost not only on the company but also on the wellbeing and mental health of the people that I was managing. And I couldn't really find a solution existing. So, I started working on one and spoke to one of my best friends about it, who is a multiple-time founder, and we just got to work. And fast forward a year and a half, here we are. +VICTORIA: I'm wondering if there was anything in the early phases that surprised you in the customer discovery process, maybe caused you to shift direction. +SARAH: Yeah, definitely. So, early days, we started with this problem, which is that most interactions between a team member and their manager happen in meetings. And that, overall, everyone is kind of frustrated with meetings, especially post-COVID, where we started doing a bunch of them online. It seemed to not work. And it seems that meeting management skills were a bit absent, and they should be part of the toolbox for a manager. +So, started by trying to help managers run better meetings. And we relied on them taking notes from those meetings, like, in writing preparing for those meetings and taking notes for them in writing. And quickly realized that a very small portion of people were actually doing that note-taking. It seems obvious saying it out loud now, but back then, we didn't really know that. +And so, we kind of had to switch gears and use way more AI than we intended, at least at that stage, to enable that automatic note-taking and gathering of data for us to be able to support the managers. Because if we don't know what they're working on and what's happening in their world, it's super hard for us to give them any feedback. But if they don't take notes and share them with us, then we can't really do anything. So, I had to shift gears and build an embedded note taker within the product to remove, like, a big portion of that friction that we saw with early users. +WILL: I love that and just your whole product. I'm a productivity nerd, so I just love it. And I was a manager for a couple of years, and it's not the easiest. So, I love what your product is doing. Can you give us an overview of exactly what your product does so the audience can know what we're talking about? +SARAH: Yeah, of course. So, the product is an AI coach or an AI co-pilot for managers. And the way it works is it connects to your calendar. It creates a space to collaborate with your team on each of the meetings you have. Prior to the meeting happening, we also give you access to one-click templates and ways to run those meetings. And then, when the meeting is happening, the Waggle Bot joins the call, takes notes for you, picks up on both action items that you mentioned during the conversation, who they were assigned to, who mentioned them, but also decisions that were made or about to be made that you need to either come back to and confirm or make sure that everyone is aware of. +And finally, and the most exciting part, to me, is that it gives you feedback on your leadership skills, a bit like if your coach was listening to your conversations with your team members. And it will say things like, "You mentioned a few tasks during this call, and you didn't delegate any of them to the team while you had the opportunity to. So, next time you have a call, think about what tasks you could actually delegate," or it will say, "Well done showing empathy when Will, in your team, mentioned that their daughter was sick and that they had to leave work early today." +So, it really works as a feedback loop to reinforce good behavior, but also give you tips and show you those unknowns that you didn't really think about and what impact they can have on your team and on your team's productivity. And finally, from that, we build a full picture of where you're good at, and where we can support you, and how those skills evolve over time through the feedback we give you. +VICTORIA: Yeah, as a manager myself, I'm thinking about all the things I do to try to make my meetings as efficient as possible by, you know, having automatic Slack updates that say, "As a reminder, go look at your tickets, update them before the call," like, rotating who's taking notes and facilitating the meeting, and thinking about how that could reduce the burden from the team and just help everyone save time and share that information more widely. Because sometimes I do have maybe a dozen meetings in a day, like, 12, 30-minute meetings [laughs]. And that's a lot of notes to take. So, I usually estimate every meeting takes another 30 minutes to an hour to wrap up and follow up afterwards. +SARAH: Yeah, I think that's a good assessment. And if you actually stick to spending those 30 minutes extra for each one of the meetings, I can tell you you're one of the best performers. Because what we've been seeing is that a lot of people, especially in startups or, like, fast-moving environments cannot afford to spend that time. So, we're trying to see how we can remove that friction and make those 30 minutes that you need to spend more like five minutes pre-meeting and potentially another five minutes after the meeting. And that's it. You're done. +VICTORIA: How many people did you talk to in the first 30 and 90 days of your startup? +SARAH: So, that's all we did in the first few months because we wanted to validate that this was not, like, an us problem. So, I spoke to about 75 managers over the first 2 to 3 months. So, that's in itself a lot of meetings, and a lot of calls, and a lot of recorded calls. And we still speak to an average of 5 to 10 managers per week to make sure that we keep a pulse on what our users are really experiencing and the pain points they are going through. +WILL: Yeah, I could tell that you did talk to a lot of managers because I wish I would have had this whenever I had direct reports. Because I remember, early on, someone told me "No one cares what you know until they know that you care." But on the flip side of that, a lot of times, like you were saying, you're just so busy. +Most companies they give you multiple direct reports, more than three or four. And it's almost impossible to really show how much you care in a small amount of time. But this seems like it makes it way more helpful to say, "Hey, I not only care about you as a worker but as a person, too." So, like you said, show empathy because they mentioned X, Y, Z, or take notes around, you know, whatever happened in this so that you know next time that, hey, ask him about that. So, I really like this idea that you created. +The question I have around it is leadership is not easy. So, how did you come up with the direction to go with the leadership? If that makes sense. Because I've seen different leaderships, I've seen some leaderships it's like, yeah, show empathy. Show that you care about the person. And some it's like, no, it's all about work. All about work. And it seems like you lean more towards, I want to show that we care about the worker. So, where did you decide to take which route and things like that? +SARAH: I love this because you're right. There's an art and a science to leadership. And I think, actually, there's way more science than we think. It's this common belief that leadership is something you are born with, and you don't need to learn that it's, I think, hurting both managers and the people they manage a lot. Because then people think, "Oh, but it must come naturally," or "This is a natural born leader." And as a result, the person who isn't or that people think isn't we think they're never going to change, and I don't think that's true. +There's a set of behaviors that have been researched by organizational psychologists, behavioral scientists that have been shown to have impacts on people's motivation, productivity, outputs. So, we make sure to follow those best practices and those scientific data points. One of our advisors is a behavioral scientist. A couple of our advisors are leadership coaches. And one of them has even published a book around how to scale high-performing teams and high-performing companies. So, we try as much as we can to really embed what we're doing in science and in things that are known, albeit not super widely. +And as you said, you need both. You need to care about the person doing the tasks, and you need to care about the tasks being done. But they can't really be separate. And you need to balance the act between the two things. So, that's why we have blended the productivity app with a part that is more centered around skills and skills development because those two things need to communicate. You can't just throw a tool at people and expect them to know how to use it. And at the same time, if you don't make sure that the upskilling and, like, feedback you give is rooted in that person's context and what they're going through, it's not going to be leveraged or used. +So, our approach was really to blend these two things and make sure that, yes, this is going to make the manager's team happier, but it's also going to make them more productive. So, it's not just about happiness. It's about linking both productivity and well-being at work. +VICTORIA: That's really interesting. I'm curious, how do you measure the impact you're having on wellbeing at work? What are the success indicators, and how do you know you're successful in a year or five years from now? +SARAH: We only have been onboarding customers six months ago. So, I think we're starting to see some of the results we want to see, but it's still a bit early days because, as you said, behavioral change and habits take a long time to form and become sticky and start showing an impact on wellbeing. +But overall, the feedback, the qualitative feedback we got was that managers feel way less imposter syndrome using the app. They feel that they are on top of what they need to achieve. They know what they're doing. They know what's expected of them. And their team also appreciates the fact that they are spending time and effort trying to get better because they know that they are using this tool to improve. So, they also get a signal that, okay, they are really trying. But at the same time, we do measure these. So, that feedback we give is actually based on measurement or assessment of each one of the skills that we measure for our users. And we have seen those scores evolve and go up over time just over the last few months. +Personally, I'm quite bad at delegation. Potentially, that's why I brought it up earlier. And I have seen my score improve over the last few months using Waggle because it's more front of mind. I'm aware that I'm being assessed that almost someone is looking at what I'm doing, even if it's an AI. So, it feels a bit more safe than if it was a real person looking at what I was doing. But I know that I need to be on my A-game every day, and so I put in intentional efforts to try and delegate when I'm in a team meeting. And, potentially, I wouldn't have had that same level of awareness if I didn't get that feedback. I would just not delegate but not to be aware that I wasn't. +WILL: I like what you said is AI is not like your manager sitting in the meeting with you and saying, "Hey, you have to get these scores up," but it feels safer that AI is telling you, "Hey, you have to improve your empathy and get better at that." So, I really like that idea. +SARAH: Nice. Let's get you on the app then. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +WILL: So, I'm looking at your website now and, you know, I'm looking at the side, and it's like, "Hey, you know, Emily presented well, you know, send them a note of encouragement, or share a summary of the email." I made so many mistakes when I was a leader, so many. I wish I would have known the benefit of...because I almost...when I first went into it, I was like, they're adults. They can take their own notes. And now that I look at it, it's like, I could have easily helped out just saying, "Hey, here's a summary of the meeting that we had, and this is how we get better," and just helping each other out. So, I really like what you're doing here and what you have already in the app. What's on the horizon for the app? What does success look like in the next six months or five years for you? +SARAH: So, the way we see it is we want to know more about the managers we're helping, know more about their context, what's going on in their daily life. Because the more we know, the more we can help them and support them. So, the way we see it is now we basically get data through the calendar connection, and through the meeting notes, and transcripts that we get. +But we would also like to know how they communicate with their team on Slack. How do they get their tasks done, and how does their team get their tasks done? How do they follow up on those tasks? But also, how fast do they reply to emails? What's the context of their emails? All of these things are data points that we can use to know their context and know them better and really tweak the AI so that it knows them better and it adapts to their setup. So that, as we go, what the AI tells you is completely different from what it tells me, for example, because it's got to know you, and it's got to know what interventions work well for you and which ones don't and get smarter at that. +And also, it gets to know how your team reacts to those behaviors that you show and attitudes. Which types of management work for Amy in your team versus Jim, right? Because they are different people as well. And so, whatever works with one person doesn't necessarily work with another and help you adapt and flex your management style with them. +VICTORIA: Do you have any other core values that drive your everyday decisions? +SARAH: We want to make sure that this never turns into a spying tool, and this is super key in the way we thought about the product, and we built it from very early days. We're conscious that we're having access, and our users trust us with a lot of data. And we're never going to share that data, even with your own manager. Because this is a tool for you as a manager to work on your skills and have that growth mindset, not for someone to spy on you or know how you're behaving. So, that's a commitment that we'll never share any specific data from users to their leadership team, to their HR team, no one else in the team, really. +What we also have as a guiding principle is we want to minimize the amount of work that is required from you to leverage these skills. So, we are trying to save managers' time whenever we can and wherever we can and never just, like, load a lot of content and feedback on them that they're not going to have time to process an action. So to strike a balance between, okay, well, you probably need to spend a bit more time on this specific skill or following up on this specific meeting. But we also saved you two hours today throughout the day so that you can focus on that extra half an hour work that is going to help your skills improve. +WILL: What are some of your biggest hurdles? +SARAH: Well, basically, this didn't exist until now. And so, just finding how we talk about it and, like, I mean, no one is looking for the solution because they don't know it's there, right? So, the first part is, how do we find people that we can support and help who aren't necessarily looking for this but are looking for alternative solutions that exist right now? And how do we talk about it in a way that makes them click and makes them envision this new way of doing things as a potential better way? +A lot of startups go through this journey. But basically, no one was looking for Ubers before Uber existed. People would hail a cab. And so, at the beginning, Uber pretended to be a cab service before they said, "Okay, we're actually not a cab. We're something else." And so, that something else is what we're trying to define right now. +VICTORIA: I used to live in a neighborhood in DC where the cab drivers would not go to [laughs]. So, I really loved Uber when it first started because I could actually get a ride. So, that's where some of the innovation comes in sometimes. It's like, solving a problem and seeing the demand and then building a product around it. I'm curious about how you're building an AI product and how are you thinking about controlling the cost and the kind of infrastructure demands of an app like Waggle? +SARAH: To be completely honest, we're not focused on that so much right now. I think it's a very fair question, and it's something that we're going to start to have to look into as we start to scale. But, for now, we're really focused on figuring out are we delivering the value we want to deliver to our users? Can we fix the problems they are hiring us to fix? But yeah, for sure, at scale, this is super costly, and we'll need to figure out the unit economics of the product and how to make it work, but we're not there yet. +VICTORIA: And how are you finding the resources to be able to experiment and have the time to build this product? What networks, or communities, or venues have you found to create space to build your app? +SARAH: So, we've been through Techstars last year. And I think the network around Techstars was super useful in gathering a lot of feedback in a very short amount of time over the three months that the program lasted. And we try to put a lot of content out there to try help people who are looking for solutions to communicate with an employee who's not performing at the level they expected them to or for a manager that doesn't know how to do a one-on-one. +This type of content we're putting it out for free because it's solving our end user's problem, partially at least, and puts us on their radar. So, they might think, "Okay, I started looking into this first problem because that's what's front of mind right now. But as I see this product, it potentially could help me through a lot more issues that I'm currently having," and get visibility across those users that are exactly our perfect type of user. But yeah, overall, trying to put content out there creates a community around us. +Lots of connections that happen through LinkedIn, through existing networks, through our users talking to other users about us, and even a number of coaches and L&D experts who really, really love what we're doing and talk about us to their users, to their customers and spread the word that way. +WILL: You're talking about, like, explaining the product to your customers and everyone. I think, for me, it resonates fairly easy because I made so many mistakes as a leader. And I'm like, oh, this could have helped me so many times to be a better leader. And so, I'll make an assumption. It seems like your product was made out of you making mistakes and learning from them, and you built a product because you want to be a better leader. So, my question for you is: What advice would you go back and give yourself when you first started? What's some advice that you can go back in time and give yourself? +SARAH: One of the first ones, and one of the biggest mistakes, and I've also heard this from so many other managers, is that as human beings, we tend to treat people the way we would like to be treated. And very quickly, we understand that that's not how things work. So, I used to like having space not to be managed very closely. So, I would just naturally give a lot of space to the people I started managing when I first started. It might work for some of them, but not for all of them. And that's what created the most issues and lack of performance, I would say, coming from them. +And it's easy to think, oh, it's their fault. They're not performing. But no, it's my fault as a manager because I didn't adapt to their needs, and I didn't give them what they needed to perform. And that's, again, very different from one person to another. +VICTORIA: Yeah. And I'm curious to go back to something you mentioned earlier about empathy. And just maybe how do you build an AI with a sense of empathy that helps managers be more empathetic? +SARAH: So, again, interestingly, AI can pick up on human behaviors way more than we think. Like, the feedback we get from the app sometimes is super interesting and, like, sometimes even a bit scary because these are patterns, right? AI is good at recognizing patterns. If you tell it what to look for, it will find it. So, it works. It just works. +VICTORIA: Well, I'm very curious to try it out. And I have some people I'm thinking about who work in building empathy with developers and engineers, and they probably would also really love to try it out. +SARAH: Nice. Send them our way. +VICTORIA: Of course. Do you have any questions for me or Will? +SARAH: Yeah. What's the hardest thing you're currently doing at work that you would love support on? +WILL: I think as a developer, there's a lot of things that I don't know that I wish I know what direction to take. Because I feel like as a developer, you come in and you're like, I want to learn X, Y, Z, but there's so much to uncover. For example, mobile, there's so many directions to learn with mobile. +In the technical part, probably sometimes what direction to go in my learning and things like that. Because, like, I'm a senior developer, and I've reached a certain part. But I feel like now it's like you learn on the go. Like, oh, I have this problem. Let me solve it. So, sometimes I wish I can get ahead of that and be like, hey, go learn how to do this because you're going to use it later. So, that's probably my biggest thing with technical. +And probably relational, you touched on it a little bit, but naturally, we're bent towards treating other people the way we want to be treated. And so, what that says is everyone around me has my exact background, my exact trauma, my exact upbringing. So, if you treat them that way, this should make sense, and that's just not the way it is. And so, I think, for me, it's making sure that I remind myself of that and to listen, to understand that background, trauma, whatever, of the people that I'm working with so that I can get to know them better and understand them better, and then I can know how to treat them. +So, I would say that's probably my two biggest things that I have to continually work on and fight to make sure that I'm doing it the right way. +SARAH: I love that. +VICTORIA: Yeah. I really appreciate that perspective, Will. And from a slightly different angle, I think I'm someone who really enjoys complex tasks. So, I think those are actually more fun and easier to do [laughs] but that more mundane tasks are kind of difficult. And making sure I'm on top of those, like, tiny, little to-dos that make you effective just consistently with certain managing tasks. +But I think in terms of complexity and one of the hardest things to do, kind of along the lines of what Will was saying, you have to establish a common language between your team. And you have to have a system for managing your work so that everyone feels heard and everyone understands each other, and so you can move quickly and make decisions. So, I think that's a really complicated task. +And the more people you have, the more complicated it is. There's just so many different ways of solving that problem, and everyone comes back from different cultures, different corporate cultures, different tools that they've used, and their preferences. And people's preferences on tools can almost be religious, and that's interesting to me how strongly people can hold on to how they've been doing things. And making that shift in direction step by step and having the patience for it, I think, is difficult. +SARAH: It's so funny that most problems, at the end of the day, are people problems, even if they don't start by being that. +WILL: I totally agree with that because I chose what company to work for based off of the people and the culture more than the other problems. Because I've worked in some companies that had a great culture, but the people were treated right. And I enjoyed working with the people that I was working with. And then, I had some that I'm like, uh, I got to go in today and deal with such and such, and ugh. I think you're spot on. That caused me more stress than trying to solve the actual tasks that I was working on. +So, yeah, I actually choose companies that I like working with the people. So, with thoughtbot, I love my co-workers. I love getting to know them the diversity in it. So, that's one of the reasons why I love thoughtbot so much. +SARAH: What a great way to end this. +VICTORIA: Yes. Thank you so much for being here with us today, Sarah. I really enjoyed listening to your story. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on thoughtbot.social@vguido. +WILL: And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + AI leadership, Waggle AI, Sarah Touzani, leadership skills, AI coaching, management tools, productivity, empathy in leadership, startup journey, digital meetings, leadership development, AI technology, business podcast, manager coaching, leadership innovation, workplace culture, meeting efficiency, AI applications, tech podcast, founder insights + + Hosts Will Larry and Victoria Guido interview Sarah Touzani, the founder of Waggle AI, an AI leadership skills coach. Sarah shares insights from her entrepreneurial journey, discussing how her past pottery hobby has influenced her focus and patience, which are crucial skills in her role as a founder. She explains how her transition from a traditional business school path to a senior role in a fast-growing startup, and eventually to founding Waggle AI, was driven by a desire to foster better managerial skills and workplace culture.

+ +

Sarah talks about the early challenges and pivots in developing Waggle AI, such as incorporating AI for automatic note-taking to reduce user friction. She describes how Waggle AI assists in meeting preparations, records notes, and provides feedback on leadership skills, helping managers improve their delegation and empathy skills. She also highlights the importance of blending productivity tools with leadership development to enhance team performance and individual well-being.

+ +

The discussion also touches on the ethical considerations and core values driving Waggle AI, to emphasize user privacy and minimizing additional workload for managers. Sarah concludes by outlining her vision for the product, focusing on deepening the AI's understanding of managers and adapting recommendations to individual team members' needs.

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Sarah Touzani, Founder of Waggle AI, your AI leadership skills coach. Sarah, thank you for joining us.

+ +

SARAH: Of course. Thanks for having me.

+ +

VICTORIA: To open us up here, what is a past or current hobby that you enjoy?

+ +

SARAH: I need to be honest. I haven't done much outside of working since I started the company. But prior to that, I used to spend a lot of time in a pottery studio making pots, and bowls, and mugs, and gifting them to anyone I meet.

+ +

WILL: That's really impressive because I tried it for, like, I think a college class. And if you make one mistake, the whole thing gets ruined. I think I made, like, a little, very small bowl, and that was all I could get [laughs].

+ +

SARAH: Yeah. I'm not surprised. It takes a lot of practice and a lot of extreme focus in a way because, like you said, like, the single moment your hand moves slightly off, the whole thing is over.

+ +

WILL: What's the item that was the most complicated or you're the most proud of?

+ +

SARAH: I would say a big bowl that I made, which has a bit of an odd shape because, actually, it was going bad. And I kind of caught it back and made that mistake into something done on purpose in the design, and it worked quite well. But it's also not your average pot or average bowl you see everywhere.

+ +

VICTORIA: That's really cool. And I echo Will's sentiments of being impressed by people who can do pottery because I did take a class right before the pandemic. And then, the pandemic hit, and we weren't able to fire any of our pieces [laughs]. But I found that it took just a lot of patience, even to be able to figure out the first step. Like, putting the clay onto the spinning wheel and doing that correctly just takes a lot of practice. And so, I'm curious if you find any of those skills or values from doing pottery translate into being a founder.

+ +

SARAH: Yeah, actually, this is funny because I wrote a blog article about this a few years ago when I first started. I think there are a lot of learnings to take away from that and bring into work, weirdly. It's that sense of focus. When you're starting a company very early, there's a million things that you want to be doing and, actually, you can't. You need to do one thing and do it well. And the ability to zoom in and focus on one single thing is a massive game changer.

+ +

Also, my last job was as busy and insane as the current one, which is being a founder, because it was, like, a senior role in a super-fast-growing startup. And I was always on my phone, or always thinking about work, or always having something coming at me and trying to answer questions and do stuff on Slack. And with your hands dirty, you're actually forced not to do any work and go back to that focus and that mental clarity. And that was also, like, extremely valuable back then. So, saying this out loud makes me think that I probably should go back and do it.

+ +

VICTORIA: I recommend it. I did a hand pottery class with my little sister. I have a big sister, little sister mentorship relationship. And we made little ceramics, and it was super fun. Just, like, an hour a week.

+ +

SARAH: Super nice.

+ +

WILL: So, Sarah, you mentioned a little bit about your background. Tell us more about that. Where did you get started? How did you become a founder of your company? How did the idea come up? Just anything in those areas.

+ +

SARAH: Yeah. Sounds good. So, I have a bit of, like, a traditional business school type of profile. I was a good student. I didn't really know what I wanted to do. So, I went into a business school, graduated, went into banking and consulting, which are, I guess, those, like, sexy jobs that you want to get when you are still at school. And I had done them and felt a bit out of place because I wanted to get things to move way faster than they were moving in these, like, very corporate set-in-their-ways type of companies.

+ +

So, left that industry and moved to a very early-stage startup. I used to live in Paris back then, and I moved to London. At the same time, joined a very early-stage startup in FinTech. We were four when I joined. And we didn't have a product, didn't have any revenue. And I had to grow that company to about 200,000 customers, 50 million series A, and 80 people in the team, of which I managed about 50. All of this happened in 4 years.

+ +

And I was hired into that role because of my background and because of my experience in risk management, compliance, like, all of the very technical aspects of my career. But at the end of the day, I spent most of my time trying to build a culture that motivated people to do their best work that enabled people to perform. And that's not something you really get to learn either at school or, in most cases, at work either. You just need to figure it out.

+ +

So, I was trying to find a way where we could enable managers to learn these skills once they're in the job. Because when they mess up and when I messed up as a manager, it had a cost not only on the company but also on the wellbeing and mental health of the people that I was managing. And I couldn't really find a solution existing. So, I started working on one and spoke to one of my best friends about it, who is a multiple-time founder, and we just got to work. And fast forward a year and a half, here we are.

+ +

VICTORIA: I'm wondering if there was anything in the early phases that surprised you in the customer discovery process, maybe caused you to shift direction.

+ +

SARAH: Yeah, definitely. So, early days, we started with this problem, which is that most interactions between a team member and their manager happen in meetings. And that, overall, everyone is kind of frustrated with meetings, especially post-COVID, where we started doing a bunch of them online. It seemed to not work. And it seems that meeting management skills were a bit absent, and they should be part of the toolbox for a manager.

+ +

So, started by trying to help managers run better meetings. And we relied on them taking notes from those meetings, like, in writing preparing for those meetings and taking notes for them in writing. And quickly realized that a very small portion of people were actually doing that note-taking. It seems obvious saying it out loud now, but back then, we didn't really know that.

+ +

And so, we kind of had to switch gears and use way more AI than we intended, at least at that stage, to enable that automatic note-taking and gathering of data for us to be able to support the managers. Because if we don't know what they're working on and what's happening in their world, it's super hard for us to give them any feedback. But if they don't take notes and share them with us, then we can't really do anything. So, I had to shift gears and build an embedded note taker within the product to remove, like, a big portion of that friction that we saw with early users.

+ +

WILL: I love that and just your whole product. I'm a productivity nerd, so I just love it. And I was a manager for a couple of years, and it's not the easiest. So, I love what your product is doing. Can you give us an overview of exactly what your product does so the audience can know what we're talking about?

+ +

SARAH: Yeah, of course. So, the product is an AI coach or an AI co-pilot for managers. And the way it works is it connects to your calendar. It creates a space to collaborate with your team on each of the meetings you have. Prior to the meeting happening, we also give you access to one-click templates and ways to run those meetings. And then, when the meeting is happening, the Waggle Bot joins the call, takes notes for you, picks up on both action items that you mentioned during the conversation, who they were assigned to, who mentioned them, but also decisions that were made or about to be made that you need to either come back to and confirm or make sure that everyone is aware of.

+ +

And finally, and the most exciting part, to me, is that it gives you feedback on your leadership skills, a bit like if your coach was listening to your conversations with your team members. And it will say things like, "You mentioned a few tasks during this call, and you didn't delegate any of them to the team while you had the opportunity to. So, next time you have a call, think about what tasks you could actually delegate," or it will say, "Well done showing empathy when Will, in your team, mentioned that their daughter was sick and that they had to leave work early today."

+ +

So, it really works as a feedback loop to reinforce good behavior, but also give you tips and show you those unknowns that you didn't really think about and what impact they can have on your team and on your team's productivity. And finally, from that, we build a full picture of where you're good at, and where we can support you, and how those skills evolve over time through the feedback we give you.

+ +

VICTORIA: Yeah, as a manager myself, I'm thinking about all the things I do to try to make my meetings as efficient as possible by, you know, having automatic Slack updates that say, "As a reminder, go look at your tickets, update them before the call," like, rotating who's taking notes and facilitating the meeting, and thinking about how that could reduce the burden from the team and just help everyone save time and share that information more widely. Because sometimes I do have maybe a dozen meetings in a day, like, 12, 30-minute meetings [laughs]. And that's a lot of notes to take. So, I usually estimate every meeting takes another 30 minutes to an hour to wrap up and follow up afterwards.

+ +

SARAH: Yeah, I think that's a good assessment. And if you actually stick to spending those 30 minutes extra for each one of the meetings, I can tell you you're one of the best performers. Because what we've been seeing is that a lot of people, especially in startups or, like, fast-moving environments cannot afford to spend that time. So, we're trying to see how we can remove that friction and make those 30 minutes that you need to spend more like five minutes pre-meeting and potentially another five minutes after the meeting. And that's it. You're done.

+ +

VICTORIA: How many people did you talk to in the first 30 and 90 days of your startup?

+ +

SARAH: So, that's all we did in the first few months because we wanted to validate that this was not, like, an us problem. So, I spoke to about 75 managers over the first 2 to 3 months. So, that's in itself a lot of meetings, and a lot of calls, and a lot of recorded calls. And we still speak to an average of 5 to 10 managers per week to make sure that we keep a pulse on what our users are really experiencing and the pain points they are going through.

+ +

WILL: Yeah, I could tell that you did talk to a lot of managers because I wish I would have had this whenever I had direct reports. Because I remember, early on, someone told me "No one cares what you know until they know that you care." But on the flip side of that, a lot of times, like you were saying, you're just so busy.

+ +

Most companies they give you multiple direct reports, more than three or four. And it's almost impossible to really show how much you care in a small amount of time. But this seems like it makes it way more helpful to say, "Hey, I not only care about you as a worker but as a person, too." So, like you said, show empathy because they mentioned X, Y, Z, or take notes around, you know, whatever happened in this so that you know next time that, hey, ask him about that. So, I really like this idea that you created.

+ +

The question I have around it is leadership is not easy. So, how did you come up with the direction to go with the leadership? If that makes sense. Because I've seen different leaderships, I've seen some leaderships it's like, yeah, show empathy. Show that you care about the person. And some it's like, no, it's all about work. All about work. And it seems like you lean more towards, I want to show that we care about the worker. So, where did you decide to take which route and things like that?

+ +

SARAH: I love this because you're right. There's an art and a science to leadership. And I think, actually, there's way more science than we think. It's this common belief that leadership is something you are born with, and you don't need to learn that it's, I think, hurting both managers and the people they manage a lot. Because then people think, "Oh, but it must come naturally," or "This is a natural born leader." And as a result, the person who isn't or that people think isn't we think they're never going to change, and I don't think that's true.

+ +

There's a set of behaviors that have been researched by organizational psychologists, behavioral scientists that have been shown to have impacts on people's motivation, productivity, outputs. So, we make sure to follow those best practices and those scientific data points. One of our advisors is a behavioral scientist. A couple of our advisors are leadership coaches. And one of them has even published a book around how to scale high-performing teams and high-performing companies. So, we try as much as we can to really embed what we're doing in science and in things that are known, albeit not super widely.

+ +

And as you said, you need both. You need to care about the person doing the tasks, and you need to care about the tasks being done. But they can't really be separate. And you need to balance the act between the two things. So, that's why we have blended the productivity app with a part that is more centered around skills and skills development because those two things need to communicate. You can't just throw a tool at people and expect them to know how to use it. And at the same time, if you don't make sure that the upskilling and, like, feedback you give is rooted in that person's context and what they're going through, it's not going to be leveraged or used.

+ +

So, our approach was really to blend these two things and make sure that, yes, this is going to make the manager's team happier, but it's also going to make them more productive. So, it's not just about happiness. It's about linking both productivity and well-being at work.

+ +

VICTORIA: That's really interesting. I'm curious, how do you measure the impact you're having on wellbeing at work? What are the success indicators, and how do you know you're successful in a year or five years from now?

+ +

SARAH: We only have been onboarding customers six months ago. So, I think we're starting to see some of the results we want to see, but it's still a bit early days because, as you said, behavioral change and habits take a long time to form and become sticky and start showing an impact on wellbeing.

+ +

But overall, the feedback, the qualitative feedback we got was that managers feel way less imposter syndrome using the app. They feel that they are on top of what they need to achieve. They know what they're doing. They know what's expected of them. And their team also appreciates the fact that they are spending time and effort trying to get better because they know that they are using this tool to improve. So, they also get a signal that, okay, they are really trying. But at the same time, we do measure these. So, that feedback we give is actually based on measurement or assessment of each one of the skills that we measure for our users. And we have seen those scores evolve and go up over time just over the last few months.

+ +

Personally, I'm quite bad at delegation. Potentially, that's why I brought it up earlier. And I have seen my score improve over the last few months using Waggle because it's more front of mind. I'm aware that I'm being assessed that almost someone is looking at what I'm doing, even if it's an AI. So, it feels a bit more safe than if it was a real person looking at what I was doing. But I know that I need to be on my A-game every day, and so I put in intentional efforts to try and delegate when I'm in a team meeting. And, potentially, I wouldn't have had that same level of awareness if I didn't get that feedback. I would just not delegate but not to be aware that I wasn't.

+ +

WILL: I like what you said is AI is not like your manager sitting in the meeting with you and saying, "Hey, you have to get these scores up," but it feels safer that AI is telling you, "Hey, you have to improve your empathy and get better at that." So, I really like that idea.

+ +

SARAH: Nice. Let's get you on the app then.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

WILL: So, I'm looking at your website now and, you know, I'm looking at the side, and it's like, "Hey, you know, Emily presented well, you know, send them a note of encouragement, or share a summary of the email." I made so many mistakes when I was a leader, so many. I wish I would have known the benefit of...because I almost...when I first went into it, I was like, they're adults. They can take their own notes. And now that I look at it, it's like, I could have easily helped out just saying, "Hey, here's a summary of the meeting that we had, and this is how we get better," and just helping each other out. So, I really like what you're doing here and what you have already in the app. What's on the horizon for the app? What does success look like in the next six months or five years for you?

+ +

SARAH: So, the way we see it is we want to know more about the managers we're helping, know more about their context, what's going on in their daily life. Because the more we know, the more we can help them and support them. So, the way we see it is now we basically get data through the calendar connection, and through the meeting notes, and transcripts that we get.

+ +

But we would also like to know how they communicate with their team on Slack. How do they get their tasks done, and how does their team get their tasks done? How do they follow up on those tasks? But also, how fast do they reply to emails? What's the context of their emails? All of these things are data points that we can use to know their context and know them better and really tweak the AI so that it knows them better and it adapts to their setup. So that, as we go, what the AI tells you is completely different from what it tells me, for example, because it's got to know you, and it's got to know what interventions work well for you and which ones don't and get smarter at that.

+ +

And also, it gets to know how your team reacts to those behaviors that you show and attitudes. Which types of management work for Amy in your team versus Jim, right? Because they are different people as well. And so, whatever works with one person doesn't necessarily work with another and help you adapt and flex your management style with them.

+ +

VICTORIA: Do you have any other core values that drive your everyday decisions?

+ +

SARAH: We want to make sure that this never turns into a spying tool, and this is super key in the way we thought about the product, and we built it from very early days. We're conscious that we're having access, and our users trust us with a lot of data. And we're never going to share that data, even with your own manager. Because this is a tool for you as a manager to work on your skills and have that growth mindset, not for someone to spy on you or know how you're behaving. So, that's a commitment that we'll never share any specific data from users to their leadership team, to their HR team, no one else in the team, really.

+ +

What we also have as a guiding principle is we want to minimize the amount of work that is required from you to leverage these skills. So, we are trying to save managers' time whenever we can and wherever we can and never just, like, load a lot of content and feedback on them that they're not going to have time to process an action. So to strike a balance between, okay, well, you probably need to spend a bit more time on this specific skill or following up on this specific meeting. But we also saved you two hours today throughout the day so that you can focus on that extra half an hour work that is going to help your skills improve.

+ +

WILL: What are some of your biggest hurdles?

+ +

SARAH: Well, basically, this didn't exist until now. And so, just finding how we talk about it and, like, I mean, no one is looking for the solution because they don't know it's there, right? So, the first part is, how do we find people that we can support and help who aren't necessarily looking for this but are looking for alternative solutions that exist right now? And how do we talk about it in a way that makes them click and makes them envision this new way of doing things as a potential better way?

+ +

A lot of startups go through this journey. But basically, no one was looking for Ubers before Uber existed. People would hail a cab. And so, at the beginning, Uber pretended to be a cab service before they said, "Okay, we're actually not a cab. We're something else." And so, that something else is what we're trying to define right now.

+ +

VICTORIA: I used to live in a neighborhood in DC where the cab drivers would not go to [laughs]. So, I really loved Uber when it first started because I could actually get a ride. So, that's where some of the innovation comes in sometimes. It's like, solving a problem and seeing the demand and then building a product around it. I'm curious about how you're building an AI product and how are you thinking about controlling the cost and the kind of infrastructure demands of an app like Waggle?

+ +

SARAH: To be completely honest, we're not focused on that so much right now. I think it's a very fair question, and it's something that we're going to start to have to look into as we start to scale. But, for now, we're really focused on figuring out are we delivering the value we want to deliver to our users? Can we fix the problems they are hiring us to fix? But yeah, for sure, at scale, this is super costly, and we'll need to figure out the unit economics of the product and how to make it work, but we're not there yet.

+ +

VICTORIA: And how are you finding the resources to be able to experiment and have the time to build this product? What networks, or communities, or venues have you found to create space to build your app?

+ +

SARAH: So, we've been through Techstars last year. And I think the network around Techstars was super useful in gathering a lot of feedback in a very short amount of time over the three months that the program lasted. And we try to put a lot of content out there to try help people who are looking for solutions to communicate with an employee who's not performing at the level they expected them to or for a manager that doesn't know how to do a one-on-one.

+ +

This type of content we're putting it out for free because it's solving our end user's problem, partially at least, and puts us on their radar. So, they might think, "Okay, I started looking into this first problem because that's what's front of mind right now. But as I see this product, it potentially could help me through a lot more issues that I'm currently having," and get visibility across those users that are exactly our perfect type of user. But yeah, overall, trying to put content out there creates a community around us.

+ +

Lots of connections that happen through LinkedIn, through existing networks, through our users talking to other users about us, and even a number of coaches and L&D experts who really, really love what we're doing and talk about us to their users, to their customers and spread the word that way.

+ +

WILL: You're talking about, like, explaining the product to your customers and everyone. I think, for me, it resonates fairly easy because I made so many mistakes as a leader. And I'm like, oh, this could have helped me so many times to be a better leader. And so, I'll make an assumption. It seems like your product was made out of you making mistakes and learning from them, and you built a product because you want to be a better leader. So, my question for you is: What advice would you go back and give yourself when you first started? What's some advice that you can go back in time and give yourself?

+ +

SARAH: One of the first ones, and one of the biggest mistakes, and I've also heard this from so many other managers, is that as human beings, we tend to treat people the way we would like to be treated. And very quickly, we understand that that's not how things work. So, I used to like having space not to be managed very closely. So, I would just naturally give a lot of space to the people I started managing when I first started. It might work for some of them, but not for all of them. And that's what created the most issues and lack of performance, I would say, coming from them.

+ +

And it's easy to think, oh, it's their fault. They're not performing. But no, it's my fault as a manager because I didn't adapt to their needs, and I didn't give them what they needed to perform. And that's, again, very different from one person to another.

+ +

VICTORIA: Yeah. And I'm curious to go back to something you mentioned earlier about empathy. And just maybe how do you build an AI with a sense of empathy that helps managers be more empathetic?

+ +

SARAH: So, again, interestingly, AI can pick up on human behaviors way more than we think. Like, the feedback we get from the app sometimes is super interesting and, like, sometimes even a bit scary because these are patterns, right? AI is good at recognizing patterns. If you tell it what to look for, it will find it. So, it works. It just works.

+ +

VICTORIA: Well, I'm very curious to try it out. And I have some people I'm thinking about who work in building empathy with developers and engineers, and they probably would also really love to try it out.

+ +

SARAH: Nice. Send them our way.

+ +

VICTORIA: Of course. Do you have any questions for me or Will?

+ +

SARAH: Yeah. What's the hardest thing you're currently doing at work that you would love support on?

+ +

WILL: I think as a developer, there's a lot of things that I don't know that I wish I know what direction to take. Because I feel like as a developer, you come in and you're like, I want to learn X, Y, Z, but there's so much to uncover. For example, mobile, there's so many directions to learn with mobile.

+ +

In the technical part, probably sometimes what direction to go in my learning and things like that. Because, like, I'm a senior developer, and I've reached a certain part. But I feel like now it's like you learn on the go. Like, oh, I have this problem. Let me solve it. So, sometimes I wish I can get ahead of that and be like, hey, go learn how to do this because you're going to use it later. So, that's probably my biggest thing with technical.

+ +

And probably relational, you touched on it a little bit, but naturally, we're bent towards treating other people the way we want to be treated. And so, what that says is everyone around me has my exact background, my exact trauma, my exact upbringing. So, if you treat them that way, this should make sense, and that's just not the way it is. And so, I think, for me, it's making sure that I remind myself of that and to listen, to understand that background, trauma, whatever, of the people that I'm working with so that I can get to know them better and understand them better, and then I can know how to treat them.

+ +

So, I would say that's probably my two biggest things that I have to continually work on and fight to make sure that I'm doing it the right way.

+ +

SARAH: I love that.

+ +

VICTORIA: Yeah. I really appreciate that perspective, Will. And from a slightly different angle, I think I'm someone who really enjoys complex tasks. So, I think those are actually more fun and easier to do [laughs] but that more mundane tasks are kind of difficult. And making sure I'm on top of those, like, tiny, little to-dos that make you effective just consistently with certain managing tasks.

+ +

But I think in terms of complexity and one of the hardest things to do, kind of along the lines of what Will was saying, you have to establish a common language between your team. And you have to have a system for managing your work so that everyone feels heard and everyone understands each other, and so you can move quickly and make decisions. So, I think that's a really complicated task.

+ +

And the more people you have, the more complicated it is. There's just so many different ways of solving that problem, and everyone comes back from different cultures, different corporate cultures, different tools that they've used, and their preferences. And people's preferences on tools can almost be religious, and that's interesting to me how strongly people can hold on to how they've been doing things. And making that shift in direction step by step and having the patience for it, I think, is difficult.

+ +

SARAH: It's so funny that most problems, at the end of the day, are people problems, even if they don't start by being that.

+ +

WILL: I totally agree with that because I chose what company to work for based off of the people and the culture more than the other problems. Because I've worked in some companies that had a great culture, but the people were treated right. And I enjoyed working with the people that I was working with. And then, I had some that I'm like, uh, I got to go in today and deal with such and such, and ugh. I think you're spot on. That caused me more stress than trying to solve the actual tasks that I was working on.

+ +

So, yeah, I actually choose companies that I like working with the people. So, with thoughtbot, I love my co-workers. I love getting to know them the diversity in it. So, that's one of the reasons why I love thoughtbot so much.

+ +

SARAH: What a great way to end this.

+ +

VICTORIA: Yes. Thank you so much for being here with us today, Sarah. I really enjoyed listening to your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on thoughtbot.social@vguido.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Victoria Guido interview Sarah Touzani, the founder of Waggle AI, an AI leadership skills coach. Sarah shares insights from her entrepreneurial journey, discussing how her past pottery hobby has influenced her focus and patience, which are crucial skills in her role as a founder. She explains how her transition from a traditional business school path to a senior role in a fast-growing startup, and eventually to founding Waggle AI, was driven by a desire to foster better managerial skills and workplace culture.

+ +

Sarah talks about the early challenges and pivots in developing Waggle AI, such as incorporating AI for automatic note-taking to reduce user friction. She describes how Waggle AI assists in meeting preparations, records notes, and provides feedback on leadership skills, helping managers improve their delegation and empathy skills. She also highlights the importance of blending productivity tools with leadership development to enhance team performance and individual well-being.

+ +

The discussion also touches on the ethical considerations and core values driving Waggle AI, to emphasize user privacy and minimizing additional workload for managers. Sarah concludes by outlining her vision for the product, focusing on deepening the AI's understanding of managers and adapting recommendations to individual team members' needs.

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Sarah Touzani, Founder of Waggle AI, your AI leadership skills coach. Sarah, thank you for joining us.

+ +

SARAH: Of course. Thanks for having me.

+ +

VICTORIA: To open us up here, what is a past or current hobby that you enjoy?

+ +

SARAH: I need to be honest. I haven't done much outside of working since I started the company. But prior to that, I used to spend a lot of time in a pottery studio making pots, and bowls, and mugs, and gifting them to anyone I meet.

+ +

WILL: That's really impressive because I tried it for, like, I think a college class. And if you make one mistake, the whole thing gets ruined. I think I made, like, a little, very small bowl, and that was all I could get [laughs].

+ +

SARAH: Yeah. I'm not surprised. It takes a lot of practice and a lot of extreme focus in a way because, like you said, like, the single moment your hand moves slightly off, the whole thing is over.

+ +

WILL: What's the item that was the most complicated or you're the most proud of?

+ +

SARAH: I would say a big bowl that I made, which has a bit of an odd shape because, actually, it was going bad. And I kind of caught it back and made that mistake into something done on purpose in the design, and it worked quite well. But it's also not your average pot or average bowl you see everywhere.

+ +

VICTORIA: That's really cool. And I echo Will's sentiments of being impressed by people who can do pottery because I did take a class right before the pandemic. And then, the pandemic hit, and we weren't able to fire any of our pieces [laughs]. But I found that it took just a lot of patience, even to be able to figure out the first step. Like, putting the clay onto the spinning wheel and doing that correctly just takes a lot of practice. And so, I'm curious if you find any of those skills or values from doing pottery translate into being a founder.

+ +

SARAH: Yeah, actually, this is funny because I wrote a blog article about this a few years ago when I first started. I think there are a lot of learnings to take away from that and bring into work, weirdly. It's that sense of focus. When you're starting a company very early, there's a million things that you want to be doing and, actually, you can't. You need to do one thing and do it well. And the ability to zoom in and focus on one single thing is a massive game changer.

+ +

Also, my last job was as busy and insane as the current one, which is being a founder, because it was, like, a senior role in a super-fast-growing startup. And I was always on my phone, or always thinking about work, or always having something coming at me and trying to answer questions and do stuff on Slack. And with your hands dirty, you're actually forced not to do any work and go back to that focus and that mental clarity. And that was also, like, extremely valuable back then. So, saying this out loud makes me think that I probably should go back and do it.

+ +

VICTORIA: I recommend it. I did a hand pottery class with my little sister. I have a big sister, little sister mentorship relationship. And we made little ceramics, and it was super fun. Just, like, an hour a week.

+ +

SARAH: Super nice.

+ +

WILL: So, Sarah, you mentioned a little bit about your background. Tell us more about that. Where did you get started? How did you become a founder of your company? How did the idea come up? Just anything in those areas.

+ +

SARAH: Yeah. Sounds good. So, I have a bit of, like, a traditional business school type of profile. I was a good student. I didn't really know what I wanted to do. So, I went into a business school, graduated, went into banking and consulting, which are, I guess, those, like, sexy jobs that you want to get when you are still at school. And I had done them and felt a bit out of place because I wanted to get things to move way faster than they were moving in these, like, very corporate set-in-their-ways type of companies.

+ +

So, left that industry and moved to a very early-stage startup. I used to live in Paris back then, and I moved to London. At the same time, joined a very early-stage startup in FinTech. We were four when I joined. And we didn't have a product, didn't have any revenue. And I had to grow that company to about 200,000 customers, 50 million series A, and 80 people in the team, of which I managed about 50. All of this happened in 4 years.

+ +

And I was hired into that role because of my background and because of my experience in risk management, compliance, like, all of the very technical aspects of my career. But at the end of the day, I spent most of my time trying to build a culture that motivated people to do their best work that enabled people to perform. And that's not something you really get to learn either at school or, in most cases, at work either. You just need to figure it out.

+ +

So, I was trying to find a way where we could enable managers to learn these skills once they're in the job. Because when they mess up and when I messed up as a manager, it had a cost not only on the company but also on the wellbeing and mental health of the people that I was managing. And I couldn't really find a solution existing. So, I started working on one and spoke to one of my best friends about it, who is a multiple-time founder, and we just got to work. And fast forward a year and a half, here we are.

+ +

VICTORIA: I'm wondering if there was anything in the early phases that surprised you in the customer discovery process, maybe caused you to shift direction.

+ +

SARAH: Yeah, definitely. So, early days, we started with this problem, which is that most interactions between a team member and their manager happen in meetings. And that, overall, everyone is kind of frustrated with meetings, especially post-COVID, where we started doing a bunch of them online. It seemed to not work. And it seems that meeting management skills were a bit absent, and they should be part of the toolbox for a manager.

+ +

So, started by trying to help managers run better meetings. And we relied on them taking notes from those meetings, like, in writing preparing for those meetings and taking notes for them in writing. And quickly realized that a very small portion of people were actually doing that note-taking. It seems obvious saying it out loud now, but back then, we didn't really know that.

+ +

And so, we kind of had to switch gears and use way more AI than we intended, at least at that stage, to enable that automatic note-taking and gathering of data for us to be able to support the managers. Because if we don't know what they're working on and what's happening in their world, it's super hard for us to give them any feedback. But if they don't take notes and share them with us, then we can't really do anything. So, I had to shift gears and build an embedded note taker within the product to remove, like, a big portion of that friction that we saw with early users.

+ +

WILL: I love that and just your whole product. I'm a productivity nerd, so I just love it. And I was a manager for a couple of years, and it's not the easiest. So, I love what your product is doing. Can you give us an overview of exactly what your product does so the audience can know what we're talking about?

+ +

SARAH: Yeah, of course. So, the product is an AI coach or an AI co-pilot for managers. And the way it works is it connects to your calendar. It creates a space to collaborate with your team on each of the meetings you have. Prior to the meeting happening, we also give you access to one-click templates and ways to run those meetings. And then, when the meeting is happening, the Waggle Bot joins the call, takes notes for you, picks up on both action items that you mentioned during the conversation, who they were assigned to, who mentioned them, but also decisions that were made or about to be made that you need to either come back to and confirm or make sure that everyone is aware of.

+ +

And finally, and the most exciting part, to me, is that it gives you feedback on your leadership skills, a bit like if your coach was listening to your conversations with your team members. And it will say things like, "You mentioned a few tasks during this call, and you didn't delegate any of them to the team while you had the opportunity to. So, next time you have a call, think about what tasks you could actually delegate," or it will say, "Well done showing empathy when Will, in your team, mentioned that their daughter was sick and that they had to leave work early today."

+ +

So, it really works as a feedback loop to reinforce good behavior, but also give you tips and show you those unknowns that you didn't really think about and what impact they can have on your team and on your team's productivity. And finally, from that, we build a full picture of where you're good at, and where we can support you, and how those skills evolve over time through the feedback we give you.

+ +

VICTORIA: Yeah, as a manager myself, I'm thinking about all the things I do to try to make my meetings as efficient as possible by, you know, having automatic Slack updates that say, "As a reminder, go look at your tickets, update them before the call," like, rotating who's taking notes and facilitating the meeting, and thinking about how that could reduce the burden from the team and just help everyone save time and share that information more widely. Because sometimes I do have maybe a dozen meetings in a day, like, 12, 30-minute meetings [laughs]. And that's a lot of notes to take. So, I usually estimate every meeting takes another 30 minutes to an hour to wrap up and follow up afterwards.

+ +

SARAH: Yeah, I think that's a good assessment. And if you actually stick to spending those 30 minutes extra for each one of the meetings, I can tell you you're one of the best performers. Because what we've been seeing is that a lot of people, especially in startups or, like, fast-moving environments cannot afford to spend that time. So, we're trying to see how we can remove that friction and make those 30 minutes that you need to spend more like five minutes pre-meeting and potentially another five minutes after the meeting. And that's it. You're done.

+ +

VICTORIA: How many people did you talk to in the first 30 and 90 days of your startup?

+ +

SARAH: So, that's all we did in the first few months because we wanted to validate that this was not, like, an us problem. So, I spoke to about 75 managers over the first 2 to 3 months. So, that's in itself a lot of meetings, and a lot of calls, and a lot of recorded calls. And we still speak to an average of 5 to 10 managers per week to make sure that we keep a pulse on what our users are really experiencing and the pain points they are going through.

+ +

WILL: Yeah, I could tell that you did talk to a lot of managers because I wish I would have had this whenever I had direct reports. Because I remember, early on, someone told me "No one cares what you know until they know that you care." But on the flip side of that, a lot of times, like you were saying, you're just so busy.

+ +

Most companies they give you multiple direct reports, more than three or four. And it's almost impossible to really show how much you care in a small amount of time. But this seems like it makes it way more helpful to say, "Hey, I not only care about you as a worker but as a person, too." So, like you said, show empathy because they mentioned X, Y, Z, or take notes around, you know, whatever happened in this so that you know next time that, hey, ask him about that. So, I really like this idea that you created.

+ +

The question I have around it is leadership is not easy. So, how did you come up with the direction to go with the leadership? If that makes sense. Because I've seen different leaderships, I've seen some leaderships it's like, yeah, show empathy. Show that you care about the person. And some it's like, no, it's all about work. All about work. And it seems like you lean more towards, I want to show that we care about the worker. So, where did you decide to take which route and things like that?

+ +

SARAH: I love this because you're right. There's an art and a science to leadership. And I think, actually, there's way more science than we think. It's this common belief that leadership is something you are born with, and you don't need to learn that it's, I think, hurting both managers and the people they manage a lot. Because then people think, "Oh, but it must come naturally," or "This is a natural born leader." And as a result, the person who isn't or that people think isn't we think they're never going to change, and I don't think that's true.

+ +

There's a set of behaviors that have been researched by organizational psychologists, behavioral scientists that have been shown to have impacts on people's motivation, productivity, outputs. So, we make sure to follow those best practices and those scientific data points. One of our advisors is a behavioral scientist. A couple of our advisors are leadership coaches. And one of them has even published a book around how to scale high-performing teams and high-performing companies. So, we try as much as we can to really embed what we're doing in science and in things that are known, albeit not super widely.

+ +

And as you said, you need both. You need to care about the person doing the tasks, and you need to care about the tasks being done. But they can't really be separate. And you need to balance the act between the two things. So, that's why we have blended the productivity app with a part that is more centered around skills and skills development because those two things need to communicate. You can't just throw a tool at people and expect them to know how to use it. And at the same time, if you don't make sure that the upskilling and, like, feedback you give is rooted in that person's context and what they're going through, it's not going to be leveraged or used.

+ +

So, our approach was really to blend these two things and make sure that, yes, this is going to make the manager's team happier, but it's also going to make them more productive. So, it's not just about happiness. It's about linking both productivity and well-being at work.

+ +

VICTORIA: That's really interesting. I'm curious, how do you measure the impact you're having on wellbeing at work? What are the success indicators, and how do you know you're successful in a year or five years from now?

+ +

SARAH: We only have been onboarding customers six months ago. So, I think we're starting to see some of the results we want to see, but it's still a bit early days because, as you said, behavioral change and habits take a long time to form and become sticky and start showing an impact on wellbeing.

+ +

But overall, the feedback, the qualitative feedback we got was that managers feel way less imposter syndrome using the app. They feel that they are on top of what they need to achieve. They know what they're doing. They know what's expected of them. And their team also appreciates the fact that they are spending time and effort trying to get better because they know that they are using this tool to improve. So, they also get a signal that, okay, they are really trying. But at the same time, we do measure these. So, that feedback we give is actually based on measurement or assessment of each one of the skills that we measure for our users. And we have seen those scores evolve and go up over time just over the last few months.

+ +

Personally, I'm quite bad at delegation. Potentially, that's why I brought it up earlier. And I have seen my score improve over the last few months using Waggle because it's more front of mind. I'm aware that I'm being assessed that almost someone is looking at what I'm doing, even if it's an AI. So, it feels a bit more safe than if it was a real person looking at what I was doing. But I know that I need to be on my A-game every day, and so I put in intentional efforts to try and delegate when I'm in a team meeting. And, potentially, I wouldn't have had that same level of awareness if I didn't get that feedback. I would just not delegate but not to be aware that I wasn't.

+ +

WILL: I like what you said is AI is not like your manager sitting in the meeting with you and saying, "Hey, you have to get these scores up," but it feels safer that AI is telling you, "Hey, you have to improve your empathy and get better at that." So, I really like that idea.

+ +

SARAH: Nice. Let's get you on the app then.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

WILL: So, I'm looking at your website now and, you know, I'm looking at the side, and it's like, "Hey, you know, Emily presented well, you know, send them a note of encouragement, or share a summary of the email." I made so many mistakes when I was a leader, so many. I wish I would have known the benefit of...because I almost...when I first went into it, I was like, they're adults. They can take their own notes. And now that I look at it, it's like, I could have easily helped out just saying, "Hey, here's a summary of the meeting that we had, and this is how we get better," and just helping each other out. So, I really like what you're doing here and what you have already in the app. What's on the horizon for the app? What does success look like in the next six months or five years for you?

+ +

SARAH: So, the way we see it is we want to know more about the managers we're helping, know more about their context, what's going on in their daily life. Because the more we know, the more we can help them and support them. So, the way we see it is now we basically get data through the calendar connection, and through the meeting notes, and transcripts that we get.

+ +

But we would also like to know how they communicate with their team on Slack. How do they get their tasks done, and how does their team get their tasks done? How do they follow up on those tasks? But also, how fast do they reply to emails? What's the context of their emails? All of these things are data points that we can use to know their context and know them better and really tweak the AI so that it knows them better and it adapts to their setup. So that, as we go, what the AI tells you is completely different from what it tells me, for example, because it's got to know you, and it's got to know what interventions work well for you and which ones don't and get smarter at that.

+ +

And also, it gets to know how your team reacts to those behaviors that you show and attitudes. Which types of management work for Amy in your team versus Jim, right? Because they are different people as well. And so, whatever works with one person doesn't necessarily work with another and help you adapt and flex your management style with them.

+ +

VICTORIA: Do you have any other core values that drive your everyday decisions?

+ +

SARAH: We want to make sure that this never turns into a spying tool, and this is super key in the way we thought about the product, and we built it from very early days. We're conscious that we're having access, and our users trust us with a lot of data. And we're never going to share that data, even with your own manager. Because this is a tool for you as a manager to work on your skills and have that growth mindset, not for someone to spy on you or know how you're behaving. So, that's a commitment that we'll never share any specific data from users to their leadership team, to their HR team, no one else in the team, really.

+ +

What we also have as a guiding principle is we want to minimize the amount of work that is required from you to leverage these skills. So, we are trying to save managers' time whenever we can and wherever we can and never just, like, load a lot of content and feedback on them that they're not going to have time to process an action. So to strike a balance between, okay, well, you probably need to spend a bit more time on this specific skill or following up on this specific meeting. But we also saved you two hours today throughout the day so that you can focus on that extra half an hour work that is going to help your skills improve.

+ +

WILL: What are some of your biggest hurdles?

+ +

SARAH: Well, basically, this didn't exist until now. And so, just finding how we talk about it and, like, I mean, no one is looking for the solution because they don't know it's there, right? So, the first part is, how do we find people that we can support and help who aren't necessarily looking for this but are looking for alternative solutions that exist right now? And how do we talk about it in a way that makes them click and makes them envision this new way of doing things as a potential better way?

+ +

A lot of startups go through this journey. But basically, no one was looking for Ubers before Uber existed. People would hail a cab. And so, at the beginning, Uber pretended to be a cab service before they said, "Okay, we're actually not a cab. We're something else." And so, that something else is what we're trying to define right now.

+ +

VICTORIA: I used to live in a neighborhood in DC where the cab drivers would not go to [laughs]. So, I really loved Uber when it first started because I could actually get a ride. So, that's where some of the innovation comes in sometimes. It's like, solving a problem and seeing the demand and then building a product around it. I'm curious about how you're building an AI product and how are you thinking about controlling the cost and the kind of infrastructure demands of an app like Waggle?

+ +

SARAH: To be completely honest, we're not focused on that so much right now. I think it's a very fair question, and it's something that we're going to start to have to look into as we start to scale. But, for now, we're really focused on figuring out are we delivering the value we want to deliver to our users? Can we fix the problems they are hiring us to fix? But yeah, for sure, at scale, this is super costly, and we'll need to figure out the unit economics of the product and how to make it work, but we're not there yet.

+ +

VICTORIA: And how are you finding the resources to be able to experiment and have the time to build this product? What networks, or communities, or venues have you found to create space to build your app?

+ +

SARAH: So, we've been through Techstars last year. And I think the network around Techstars was super useful in gathering a lot of feedback in a very short amount of time over the three months that the program lasted. And we try to put a lot of content out there to try help people who are looking for solutions to communicate with an employee who's not performing at the level they expected them to or for a manager that doesn't know how to do a one-on-one.

+ +

This type of content we're putting it out for free because it's solving our end user's problem, partially at least, and puts us on their radar. So, they might think, "Okay, I started looking into this first problem because that's what's front of mind right now. But as I see this product, it potentially could help me through a lot more issues that I'm currently having," and get visibility across those users that are exactly our perfect type of user. But yeah, overall, trying to put content out there creates a community around us.

+ +

Lots of connections that happen through LinkedIn, through existing networks, through our users talking to other users about us, and even a number of coaches and L&D experts who really, really love what we're doing and talk about us to their users, to their customers and spread the word that way.

+ +

WILL: You're talking about, like, explaining the product to your customers and everyone. I think, for me, it resonates fairly easy because I made so many mistakes as a leader. And I'm like, oh, this could have helped me so many times to be a better leader. And so, I'll make an assumption. It seems like your product was made out of you making mistakes and learning from them, and you built a product because you want to be a better leader. So, my question for you is: What advice would you go back and give yourself when you first started? What's some advice that you can go back in time and give yourself?

+ +

SARAH: One of the first ones, and one of the biggest mistakes, and I've also heard this from so many other managers, is that as human beings, we tend to treat people the way we would like to be treated. And very quickly, we understand that that's not how things work. So, I used to like having space not to be managed very closely. So, I would just naturally give a lot of space to the people I started managing when I first started. It might work for some of them, but not for all of them. And that's what created the most issues and lack of performance, I would say, coming from them.

+ +

And it's easy to think, oh, it's their fault. They're not performing. But no, it's my fault as a manager because I didn't adapt to their needs, and I didn't give them what they needed to perform. And that's, again, very different from one person to another.

+ +

VICTORIA: Yeah. And I'm curious to go back to something you mentioned earlier about empathy. And just maybe how do you build an AI with a sense of empathy that helps managers be more empathetic?

+ +

SARAH: So, again, interestingly, AI can pick up on human behaviors way more than we think. Like, the feedback we get from the app sometimes is super interesting and, like, sometimes even a bit scary because these are patterns, right? AI is good at recognizing patterns. If you tell it what to look for, it will find it. So, it works. It just works.

+ +

VICTORIA: Well, I'm very curious to try it out. And I have some people I'm thinking about who work in building empathy with developers and engineers, and they probably would also really love to try it out.

+ +

SARAH: Nice. Send them our way.

+ +

VICTORIA: Of course. Do you have any questions for me or Will?

+ +

SARAH: Yeah. What's the hardest thing you're currently doing at work that you would love support on?

+ +

WILL: I think as a developer, there's a lot of things that I don't know that I wish I know what direction to take. Because I feel like as a developer, you come in and you're like, I want to learn X, Y, Z, but there's so much to uncover. For example, mobile, there's so many directions to learn with mobile.

+ +

In the technical part, probably sometimes what direction to go in my learning and things like that. Because, like, I'm a senior developer, and I've reached a certain part. But I feel like now it's like you learn on the go. Like, oh, I have this problem. Let me solve it. So, sometimes I wish I can get ahead of that and be like, hey, go learn how to do this because you're going to use it later. So, that's probably my biggest thing with technical.

+ +

And probably relational, you touched on it a little bit, but naturally, we're bent towards treating other people the way we want to be treated. And so, what that says is everyone around me has my exact background, my exact trauma, my exact upbringing. So, if you treat them that way, this should make sense, and that's just not the way it is. And so, I think, for me, it's making sure that I remind myself of that and to listen, to understand that background, trauma, whatever, of the people that I'm working with so that I can get to know them better and understand them better, and then I can know how to treat them.

+ +

So, I would say that's probably my two biggest things that I have to continually work on and fight to make sure that I'm doing it the right way.

+ +

SARAH: I love that.

+ +

VICTORIA: Yeah. I really appreciate that perspective, Will. And from a slightly different angle, I think I'm someone who really enjoys complex tasks. So, I think those are actually more fun and easier to do [laughs] but that more mundane tasks are kind of difficult. And making sure I'm on top of those, like, tiny, little to-dos that make you effective just consistently with certain managing tasks.

+ +

But I think in terms of complexity and one of the hardest things to do, kind of along the lines of what Will was saying, you have to establish a common language between your team. And you have to have a system for managing your work so that everyone feels heard and everyone understands each other, and so you can move quickly and make decisions. So, I think that's a really complicated task.

+ +

And the more people you have, the more complicated it is. There's just so many different ways of solving that problem, and everyone comes back from different cultures, different corporate cultures, different tools that they've used, and their preferences. And people's preferences on tools can almost be religious, and that's interesting to me how strongly people can hold on to how they've been doing things. And making that shift in direction step by step and having the patience for it, I think, is difficult.

+ +

SARAH: It's so funny that most problems, at the end of the day, are people problems, even if they don't start by being that.

+ +

WILL: I totally agree with that because I chose what company to work for based off of the people and the culture more than the other problems. Because I've worked in some companies that had a great culture, but the people were treated right. And I enjoyed working with the people that I was working with. And then, I had some that I'm like, uh, I got to go in today and deal with such and such, and ugh. I think you're spot on. That caused me more stress than trying to solve the actual tasks that I was working on.

+ +

So, yeah, I actually choose companies that I like working with the people. So, with thoughtbot, I love my co-workers. I love getting to know them the diversity in it. So, that's one of the reasons why I love thoughtbot so much.

+ +

SARAH: What a great way to end this.

+ +

VICTORIA: Yes. Thank you so much for being here with us today, Sarah. I really enjoyed listening to your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on thoughtbot.social@vguido.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+1w_FHlDR + + ]]> + + Will Larry + Victoria Guido + + + 525: Tech, Public Service, and Serendipity + https://podcast.thoughtbot.com/525 + 32a9162c-3bde-489d-98a9-7e999f678165 + Thu, 16 May 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Victoria Guido chats with Robbie Holmes, founder and CEO of Holmes Consulting Group, who shares his unexpected journey from an entry-level position at a small web hosting company to a pivotal role in civic tech and public interest technology. Robbie discusses his evolution through various tech roles and his love of the Drupal community, highlighting the influential role of networking in his career development. He also reflects on his work with the U.S. Digital Service while underscoring the significance of technology in public services. + 51:00 + no + + + Victoria Guido hosts Robbie Holmes, the founder and CEO of Holmes Consulting Group. The conversation kicks off with Robbie recounting his initial foray into the tech world at a small web hosting company named A1 Terabit.net, chosen for its alphabetical advantage in the white pages. This job was a stepping stone to a more significant role at Unisys, working for the state of New York's Department of Social Services, where Robbie inadvertently ventured into civic tech and public interest technology. +Robbie shares his career progression from supporting welfare systems in New York to becoming a technological liaison between the city and state, leading to a deeper involvement in open-source solutions. His journey through tech spaces includes developing websites, diving into the Drupal community, and eventually establishing his consulting business. Robbie emphasizes the serendipitous nature of his career path, influenced significantly by community involvement and networking rather than a planned trajectory. +Additionally, Robbie gives insights on the impact of technology in public services and his stint with the U.S. Digital Service (USDS), where he contributed to significant projects like vets.gov. Robbie promotes the value of community engagement in shaping one's career, stressing how connections and being in the right place at the right time can lead to unexpected opportunities and career pivots. +Follow Robbie Holmes on LinkedIn (https://www.linkedin.com/in/robbiethegeek/), X (https://twitter.com/RobbieTheGeek), Facebook (https://www.facebook.com/robbiethegeek), Instagram (https://www.instagram.com/robbiethegeek), or GitHub (https://github.com/robbiethegeek). Check out his website at robbiethegeek (https://about.me/robbiethegeek). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Robbie Holmes, Founder and CEO of Holmes Consulting Group. Robbie, thank you for joining me. +ROBBIE: I'm so happy to be here. It's great to talk to you, Victoria. +VICTORIA: Yes. I have known you for a long time now, but I don't know everything about you. So, I thought I would start with the question: What was your first job that you ever had? +ROBBIE: My first technical job, I ended up working for an internet web hosting company called A1 Terabit.net. And note the A1 because it came first in the white pages. It was a really small web hosting company run by a man named [SP] Maxim Avrutsky. I worked there for about six months before I submitted my resume to an online job forum. That's how old I am. And it ended up in the hands of Unisys, where I eventually worked for the state of New York. +VICTORIA: Wow [laughs]. So, what a journey that you've been on to get from starting there, and what a marketing ploy back in the day with the white pages. So, tell me a little bit more about how you went from that first job to where you are today with having your own business in consulting. +ROBBIE: Yeah, I wasn't even aware that I was jumping into the sort of civic tech space and public interest technology because the job I ended up with was working for New York State in the Department of Social Services. And welfare is federally funded and distributed to states and then states to localities. And New York City and New York State have a weird parasymbiotic relationship because over 50% of the welfare in New York State goes to the five boroughs in New York City. So, so much of my job was supporting the welfare system within the city, which was run by the human resources administration. +So, that just led to this cascade of me, like, getting invested in supporting that, and then eventually jumping over to the other side where I worked for the City of New York. And at that point, I ended up becoming sort of a technology project manager and almost a tech liaison between the city and state. And I was out in the welfare centers, helping get the job centers up to a new application called the Paperless Office System, which was a client-server app that was a wrapper around welfare. +All of that ended up leading to me finally making it to the network operation center for the City of New York, where I started replacing expensive solutions like HP OpenView with open-source solutions like Nagios and another open-source solution that provided an interface. And it really opened my eyes to the idea of open source. And I had really paid attention to a lot of open-source operating systems. So, I was kind of just a general tech nerd. +And eventually, I started building websites, and that led me to the Drupal community in New York City, which was sort of this cascade that led me to communities. And I think that's sort of a through line for my entire career is I don't really think I ever had a plan. I think my entire career has been this sort of a lucky happenstance of being prepared when an opportunity arose and sometimes being in the right place because of my connections and community. +VICTORIA: That's interesting about being involved with the people around you and seeing what problems are out there to solve and letting that lead you to where your interests lie. And then, following that, naturally led you to, like, this really long career and these really interesting, big projects and problems that you get to solve. +ROBBIE: Yeah. And I think one interesting aspect is like, I feel I spent a lot of time worried about what I was going to do and where I was going to do it. I don't have a bachelor's degree. I don't have an advanced degree. I have a high school diploma and a couple of years in college. Well, 137 credits, not the right 125 or 124 to have a bachelor's degree. I have enough credits for a couple of minors though, definitely Greek art history, I think mathematics, maybe one more. I just never got it together and actually got my degree. But that was so interesting because it was limiting to what jobs I could find. +So, I was in the tech space as an IT person and specifically doing networking. So, I was running the network operation center. I helped, like, create a whole process for how we track tickets, and how we created tickets, and how things were moved along. And, in the process, I started building websites for family and friends. +And I built a website for our network operation center, so that way we could have photos to go with our diagrams of the network. So that way, when we were troubleshooting remotely, we could actually pull up images and say, "The cable that's in port six goes off to the router. I think that port is dead. Can we move it to the port two to its right, and I'll activate it?" And that made a really interesting solution for something we weren't even aware we had, which was lack of visibility. So many of the people in the fields were newer or were trying to figure it out. And some of us had really deep knowledge of what was going on in those network rooms and hubs. +It led me to this solution of like, well, why don't we just start documenting it and making it easier for us to help when they're in the field? That led me to, like, the Drupal community because I started building sites in the Drupal CMS. And I went to, like, my first Drupal meetup in 2007, and there was, like, five of us around the table. That led to eventually me working for Sony Music and all these other things. +But the year before I found my way to the Drupal community, I probably sent out, like, 400 resumes for jobs in the tech space, didn't really get any callbacks. And then, I met the community, and I started attending events, and then eventually, I started organizing events. And then, Sony I interviewed and talked to them a couple of times. And then, a friend of mine became the boss. And she contacted me and was like, "Hey, are you in the market?" And I was like, "I don't know. Why? What's up?" And she's like, "I became Doug." And I was like, "What?" And she was like, "I'm now replacing Doug at Sony. I'm running the team." And I was like, "Yeah, I'm happy to talk." +And that was the big transition in my career from IT to sort of development and to delivery, right? Like, when it comes right down to it, is I became the manager of interactive media at Sony Music, which was really a job I landed because I was connected to the community, and running events, and getting to know everyone. +VICTORIA: Yeah. And I think it's really cool that you had this exposure early on to what you called civic tech, which we'll get into a little bit, and then you went from the community into a commercial technology space and really getting into engineering with Drupal. +ROBBIE: Yeah, it was an interesting transition because what they needed at Sony was sort of somebody who could ride the line between systems engineer, database administrator, and Drupal engineer, and also probably pre-DevOps DevOps person. So, I was responsible for all deployments and all tickets that came in. I was sort of both the technical arm of the help desk. When I joined, there was 24 websites on the Drupal platform, and when I left, there was over 200. And we upgraded it from Drupal 5 to Drupal 6 to Drupal 7 while I was there. So, I was heavily involved in all of those updates, and all those upgrades, and all of the deployments of all the new themes, and all the changes to all these sites. +So, what was great was they, I believe, if I understand it correctly, they actually created a role for me out of, like, two or three jobs because they needed a me, and they didn't have a role that existed. So, all of a sudden, they made a manager of interactive media role. And I was able to work there for two years, sort of being what I jokingly say, like, a digital janitor. I used to say that I had, like, an eight-bit key ring in a push broom. And I was always mad at your kids for trying to break my stuff. +VICTORIA: [laughs] That's so good. A digital service janitor [laughs]? The connection for me between that and where I met you in the U.S. digital service space [laughs] I feel like there's a lot of parallels between that and where your career evolved later on in life. +ROBBIE: Yeah. What's amazing is I did all this early work in my career in civic tech and didn't realize it was civic tech at the time. I just realized what I was doing was providing this huge impact and was value. You know, I spent a couple of years in the welfare centers, and I used to say all the time that the two hardest jobs in the welfare center are the person applying for welfare and the person deciding whether or not that person gets welfare. So, being a technologist and trying to help make that as simple as possible or easier and smooth the edges off of that process was really important. +And it really taught me how important technology is to delivering service. And I really never thought about it before. And then, when I was working for Phase2 technologies, I was a director of Digital Services. And I read in a blog post, I believe that was written by Mikey Dickerson, who was the original administrator for USDS, and he talked about HealthCare.gov. And he walked in the door, and he said, "How do you know HealthCare.gov is down?" And I think there was some allusion to the fact that we were like, we turn on the television and if they're yelling at us, we know it's down. And Mikey was like, "We know how to monitor things." +So, like, if you don't know Mikey Dickerson, he's the person who sort of created the web application hierarchy of needs in Google. He was an SRE. And his pyramid, like Maslow's hierarchy of needs, was all over Google when I was there. I was so impressed with the idea that, like, we aren't talking about how do we solve this problem? We're talking about knowing when there's a problem. And then, if we know there's a problem, we can put some messaging around that. We can say, like, "We're aware," right? Like if the president calls the secretary, the secretary can say, "We know it's down. We're working on it," which is building up political capital. +It's a really amazing process that I kept reading this blog post, and I was like, God, that's how I would approach it. And then, I was like, wow, I wonder if I could use my skills to help America, and very shortly submitted an application and was like, well, we'll see what happens. And about six months later, I walked in the door at the VA and was the eighth employee of the Digital Service team at the VA. That was a franchise team of the USDS model. +VICTORIA: And can you say a little bit more about what is the U.S. Digital Service and expand upon your early experience there? +ROBBIE: Yeah. So, the United States Digital Service was created after HealthCare.gov had its issues. Todd Park had convinced President Obama to reach out to get support from the private industry. And the few of the people who were there, Todd convinced to stick around and start creating a team that could support if there was this kind of issue in the future. I believe the team that was there on the ground was Mikey Dickerson, Erie Meyer, Haley Van Dyck, and Todd. And there was a few other people who came back or were very close at the beginning, including the current administrator of USDS. She has been around a long time and really helped with HealthCare.gov. It's amazing that Mina is back in government. We're very lucky to have her. +But what came out of that was what if we were able to stand up a team that was here in case agencies needed support or could vet solutions before these types of problems could exist? So, USDS was what they called the startup inside the White House that was created during the 2014 administration of President Obama. The team started that year, and I joined in May of 2016. So, I would be, like, sort of the beginning of the second team of the VA U.S. Digital Service team. +So, USDS supported this idea of tours of duty, where you're a schedule A employee, which meant you were a full-time government employee, but you were term-limited. You could do up to two years of duty and work, and then you could theoretically stick around and do two more years. That was how these roles were envisioned. I think there's lots of reasons why that was the case. But what's nice is it meant that you would come in with fresh eyes and would never become part of the entrenched IT ecosystem. +There are people that transition from USDS into government, and I think that's a huge value prop nowadays. It's something that I don't know they were thinking about when the original United States Digital Service was stood up, but it was hugely impactful. Like, I was part of the team at the VA that helped digitize the first form on vets.gov and all the work that was done. When the VA team started, there was a team that was helping with veteran benefits, and they worked on the appeals process for veteran benefits. And I joined. And there was a team that was...eventually, it became dubbed the veteran-facing tools team. +And we worked on vets.gov, which was a new front door to expose and let veterans interact with the VA digitally. And over time, all the work that went into the tools and the solutions that were built there, everything was user-researched. And all of that work eventually got brought into VA.gov in what they called a brand merger. So, we took, like, the sixth most trafficked front door of the VA and took all the modern solutioning that that was and brought it into VA.gov, the main front door. So, all of a sudden, there was an identity, a login provided on VA.gov for the first time. So big, impactful work that many people were a part of and is still ongoing today. +Surprisingly, so much of this work has now fallen under OCTO, which is the Office of the CTO in the VA. And the CTO is Charles Worthington, who was a USDSer who's the epitome of a person who goes where the work is. Charles was a Presidential Innovation Fellow who helped out in the times of HealthCare.gov and, joined USDS and did anything and everything that was necessary. He interviewed engineers. He was a product person. Charles is one of the most unique technologists and civic tech people I've ever met in my life. +But Charles, at the end of the Obama administration and in this transition, realized that the VA was in need of someone to fill the CTO role. So, he came over to become the interim CTO because one of the values of USDS is to go where the work is. And he realized, with the transition, that Marina Nitze, who was the CTO who was transitioning out, there was going to be a need for continuity. So, he came in to provide that continuity and eventually became the full-time CTO and has been there ever since. +So, he has helped shape the vision of what the VA is working towards digitally and is now...he was just named the Chief AI Officer for the agency. Charles is a great person. He has successfully, you know, shepherded the work that was being done early by some of us into what is now becoming a sort of enterprise-wide solution, and it's really impressive. +VICTORIA: I appreciate you sharing that. And, you know, I think there's a perception about working for public service or for government, state or federal agencies, that they are bureaucratic, difficult to work with, very slow. And I think that the USDS was a great example of trying to really create a massive change. And there's been this ripple effect of how the government acquires products and services to support public needs, right? +ROBBIE: Yeah, I would say there's a couple of arms of the government that were sort of modernization approaches, so you have the Presidential Innovation Fellows, which are the equivalent of, like, entrepreneurs and residents in government. And they run out of...I think they're out of the TTS, the Technology Transformation Service over at GSA, which is the General Services Administration. But the PIFs are this really interesting group of people that get a chance to go in and try to dig in and use their entrepreneurial mindset and approach to try to solve problems in government. And a lot of PIFS work in offices. +Like, Charles' early team when he first became the CTO included a lot of Presidential Innovation Fellows. It was basically like, "Hey, the VA could use some support," and these people were available and were able to be convinced to come and do this work. And then, you have the Presidential Management Fellows, which I think is a little bit more on the administration side. And then, we have 18F and USDS. +The United States Digital Service is a funded agency with an OMB. And we were created as a way to provide the government with support either by detailing people over or dropping in when there was a problem. And then, 18F is an organization that is named because the offices of GSA and TTS (Technology Transformation Service), where it's housed, are on the corner of 18th Street and F in DC. And 18F is sort of like having a technology or a digital agency for hire within the government. So, they are full-time employees of the government, sort of like USDS, except government agencies can procure the support of that 18F team, just like they would procure the support of your company. And it was a really interesting play. +They are fully cost-recoupable subcomponent of TTS, which means they have to basically make back all the money that they spend, whereas USDS is different. It's congressionally funded for what it does. But they're all similar sibling organizations that are all trying to change how government works or to bring a more modern idea or parlance into the government. I used to say to people all the time that at USDS, you know, we would set a broken bone say, and then we would come back around and say, like, "Hey, does your arm hurt anymore?" The idea being like, no. Be like, "Cool, cool. Maybe you should go to the gym, and you should eat better." And that would be, like, procurement change. That would be, like, changing for the long term. +So, all the work I was doing was building political capital so we could do better work in changing how procurement was done and then changing how the government delivered these things. So, what was awesome was, like, we used to have these fights at USDS about whether or not we were a culture change or we were firefighters. And I think the reality is once we're involved, culture changes happen. The bigger question is, are we going to be there for the long haul, or are we only there for a shorter period of time? And I think there are reasons why USDS teams had both plays. And I think it really is just two different plays for the same outcome. +VICTORIA: Yeah, that makes sense. And to pivot a little bit, I think, you know, our audience, we have clients and listeners who are founders of products that are aimed at making these, like, public service needs, or to give some examples, like, maybe they're trying to track Congressional voting patterns or contact information for different state representatives, and they're trying to navigate this space [laughs]. So, maybe you can give some advice for founders interested in selling their products to government agencies. What can they do to make it more appealing and less painful for themselves? +ROBBIE: I wouldn't consider myself a procurement expert, but at USDS, the procurement team called themselves the [SP] procurementati. +And I was a secret member of the procurementati. I often was the engineer they would call to evaluate statements of work or sometimes be on technology evaluation panels. And it was fun to be a part of that. Things that most companies don't realize is government agencies will put out things like request for information or sources sought in the government space. And this is a way for industry to influence how government tries to solve problems. +If you are trying to go after government work and you're only responding to an RFP, you're probably behind in your influence that you could have on the type of work. So, you'll see if a procurement seems to be, like, specifically focused on an approach, or a technology, or a framework, it's probably because some companies have come through and said, "I think this would probably solve your problem," and they gave examples. So, that's one way to be more connected to what's going on is to follow those types of requests. +Another is to follow the money. My wife is this amazing woman who helped write The Data Act and get it passed through government. And The Data Act is the Data and Transparency Act. And that led to her heading over to treasury and leading up a team that built USAspending.gov. So, there is a website that tracks every dollar, with some exceptions, of the funding that comes out of Congress every year. And what's great is you can track it down to where it's spent, and how it's spent, and things like that. For education purposes, I think that is a really good thing that business and growth people can focus on is try to see and target where competitors or where solutions that you've looked at have gone in the past. It's just a good set of data for you to take a look at. +The other piece is if you're creating a solution that is a delivery or a deliverable, like a SaaS solution, in order for something to be utilized in the government, it probably needs to be FedRAMP-approved, which is a process by which security approvals have been given so that government agencies have the green light to utilize your solution. So, there's tons of documentation out there about FedRAMP and the FedRAMP approval process. But that is one of those things that becomes a very big stopping point for product companies that are trying to work in the government. +The easiest way to work your way through that is to read up on it a bunch, but also find an agency that was probably willing to sponsor you getting FedRAMP approval. Most companies start working with a government agency, get an exemption for them to utilize your product, and then you get to shape what that FedRAMP process looks like. You start applying for it, and then you have to have some sort of person who's helping shepherd it for you internally in the government and accepting any issues that come along in the process. So, I guess FedRAMP approval is one that's a little complicated but would be worth looking into if you were planning on delivering a product in government. +VICTORIA: Right. And does that apply to state governments as well? +ROBBIE: So, lots of state-related and city and locality-related governments will actually adopt federal solutions or federal paradigms. So, I think in the state of California, I think FedRAMP as one of the guiding principles for accepting work into the state of California, so it's not consistent. There's not a one-to-one that every state, or every city, or every locality will pull this in. But if you are already approved to be a federal contractor, or a federal business, or a federal product, it's probably going to be easier to make your way into the local spaces also. +VICTORIA: Right. And as you said, there's plenty of resources, and tools, and everything to help you go along that journey if that's the group you're going for [laughs]. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +VICTORIA: So, kind of bringing it back to you, like, you're saying you want those partnerships within the government. You want someone advocating for you or for your product or your service. Drawing that back to what you said earlier about community, like, how do you form a community with this group of people who are in the state, or federal government, or civic tech spaces? +ROBBIE: Yeah, I think it's an interesting problem because so much of it feels impenetrable from the outside. Most people don't even know where to start. There are organizations out there that are pretty good community connections, an example I would give is ACT-IAC. It is a public-private partnership where people from within the government, experts in their fields, and people in the private industry who are experts in their fields will be together on community boards and engaging in panels. And so, it's a really nice way to start connecting those dots. +I have no direct affiliation with ACT-IAC. But if they'd like to give me my own account, that would be great. But it is one of those organizations I've seen be successful for people trying to find their way into a community that is a little harder to find. +I think, also, so much of the community engagement happens at conferences and around...so, like, if you're in the healthcare space, this last month, you've had multiple conferences that I think were really great for people to get to know one another, you know, an example is ViVE. It just happened out in LA, which is a little more on the private sector health space, but still, government agencies were there. I know that the Department of Veterans Affairs had people there and were on panels. And then, HIMSS is another conference that takes place, and that just took place down in Miami. And in Miami, HIMSS happened and a whole bunch of other social community events took place. +So, I'm close with a thing called the Digital Services Coalition, which is 47 companies that all try to deliver good government based on the Digital Services Playbook that was created by USDS that lives at playbook.cio.gov and the way that they try to accomplish this work. And that organization, while they were in Miami, hosted a happy hour. So, there's a lot of connections that can be made once you start seeing the players and getting to know who's around. So, it's a little bit about trying to find your way to that first event, and I think that will really open up everything for you. +Within a week or two, I was at an International Women's Day event at MetroStar, which is a really great company that I've gotten a chance to spend some time with. And then, I was at an event for the Digital Services Coalition talking about open source in government. So, there's a lot of stuff out there for you to be a part of that isn't super cost-prohibitive and also doesn't take a lot once you start to open the door. You know, once you peek around that corner and you find some people, there's a lot more to be done. +VICTORIA: Yeah. And you touched on something at the end there that wants me to bring up some of the advantages you can have being a small business, a minority-owned business, or woman-owned business, or veteran-owned business, so thinking about how you can form those connections, especially if you have one of those socio and economic set-asides that you might want to consider if they're looking to work with the government as well. +ROBBIE: Yeah. Those socioeconomic set-asides include small businesses, woman-owned small business. I think it's Native and Alaskan 8(a), which is historically underrepresented and service-disabled veteran-owned. So, there are also sub-communities of associations, like there's the Digital WOSB, the digital Women-Owned Small Business alliance that was founded by Jess Morris from Pluribus Digital, and a bunch of other companies in the Digital Services Coalition. I believe she's the president of the Digital WOSB right now. +That is a sub-community of women-owned small businesses that are trying to connect and create a community that they can support one another. And that's just one example of the type of connection you can make through those types of socioeconomic set-asides. But once you have those official socioeconomic set-asides, it will allow you to get specific contracts engagements in the government that are not allowed or available for others. So, the government procurement process will have some amount of these specific socioeconomic set-asides that need to be hit. Like, 8% of all procurements need to go to this and 10% of all procurements need to go to this. +So, I think the VA is probably one of the most effective at hitting any of the socioeconomic set-asides, specifically related to service-disabled veteran-owned small businesses. So, if you happen to be a person of color and you found a business and you are female presenting, right? You may have 8(a) woman-owned small business. If you also happen to be a veteran and you're service-disabled, all of those things stack. You don't just get to have one of them. And they can be really effective in helping a business get a leg up and starting out and trying to help even the playing field for those communities. +VICTORIA: Yeah. What I really appreciated about my experience working with Pluribus Digital, and you, and people who had had that experience in the U.S. Digital Services, that there is this community and desire to help each other out and that you can have access to people who know how to move your product forward, get you the connections that you need to be competitive, and to go after the work. So, I love encouraging people to consider civic tech options. And maybe even say more about just how impactful some of it can be. And what kind of missions are you solving in these spaces? +ROBBIE: Yeah, I often try to remind people, especially those who are heading towards or considering civic tech, there are very few places in this world that you can work on something that can impact millions of people. Sure, I was lucky enough. I have tons of privilege. I worked at a lot of wacky places that have given me the access to do the type of work that I think is impactful, but very little has the kind of impact. +Like, when I was interviewed by Marina Nitze as, my last interview when I joined USDS, she sent me an email at the end of it and said like, "Everything was great. I look forward to working with you. And remember, every time you commit code into our GitHub, you'll be helping 8 million veterans." And then, she cc'd Todd Park. And Todd was the CTO of the U.S., and he responded back within a minute. Todd is one of the most busy people. It was amazing to me how fast he responded. But he was like, "Lemme tell you, as somebody who can talk on behalf of our president, our country needs you." And those kinds of things they're hard to comprehend. +And then, I joined the Digital Service team at the VA. And one of the first things that I got to support was the 10-10EZ. It's the healthcare application for veterans. And before I got there, it was a hosted PDF that we were trying to replace. And the team had been working for months to try to build a new, modern solution. What it was is it was, like, less than six submissions were happening a day because it only worked in Adobe Acrobat, I think it was 6.5 and below, and Internet Explorer 8.5 and below. +And if you think about the people that could submit utilizing that limited set of technologies, it was slowly becoming homeless veterans who were using library computers that had not been upgraded. So, there was a diminishing amount of value that it was providing. And then, on top of it, it was sort of lying to veterans. If the version of the Adobe Acrobat was out of date, or wrong, or too new, it would tell them to upgrade their browser. So, like, it was effectively not providing any value over time. +We were able to create a new version of that and that was already well on its way when I joined, but we were able to get it out the door. And it was a React frontend using a Node backend to talk to that SOAP API endpoint. Within the first week, we went from 6 submissions a day to 60 submissions a day. It's a joke, right? We were all 10x developers. We were like, "Look at us. We're killing it." +But about three years later, Matt Cutts came to a staff meeting of USDS, and he was the second administrator of the USDS. And he brought the cake that had the actual 10-10EZ form on it, and it said, "500,000." And he had checked with the analytics team, and there were over 500,000 submissions of that form, which means there are 500,000 possible veterans that now may or may not have access to healthcare benefits. Those are big problems. +All of that was done by changing out one form. It opened up the world. It opened up to a group of veterans that no one else was able to do. They would have had to go into a veteran's office, and they would have had to fill it out in paper. And some veterans just don't have the ability to do that, or don't have an address, or don't have a...so, there are so many reasons why having a digital form that worked for veterans was so important. But this one form that we digitized and we helped make modern has been submitted so many times and has helped so many veterans and their families. And that's just one example. That's just one form that we helped digitize. +But now the team, I mean, I'm back in the VA ecosystem. There's, like, 2,500 people in the general channel in the office of the CTO Slack organization. That's amazing. There's people there that are working all day, every day, trying to solve the same problems that I was trying to solve when I got here. And there's so much work being done to help veterans. But that's just one example, right? Like, at USDS, I know that the digital filing for the free version of your tax form, the IRS e-file Direct, just went live. That was something that USDS had been working on for a very long time behind the scenes. And that's going to impact everybody who submits their taxes. +These are the kind of problems that you get to work on or the scope of some of the problems if you work in these types of organizations, and that's really powerful. It's the thing that keeps drawing me back. I'm back supporting the VA again through some contracts in my business. +But it's funny, like, I was working for another agency. I was over working at DHS on an asylum project. And a friend of mine kept telling people to tell me, "Man, veterans need you. If only there was another one of you to help us over here, that would be great." And eventually, it led to me being like, well, veterans need me. I'm going to go back to the VA. And that was my second tour at USDS at the Department of Veteran Affairs. And now I'm back there again. +So, it's a very impactful place to work. There's tons of value you can provide to veterans. And, to me, it's the kind of work that keeps bringing me back. I didn't realize just how much I was a, like, impact junkie until I joined USDS, and then it really came to a head. I cannot believe how much work I've gotten to be a part of that has affected and supported those who get benefits and services from the federal government. +VICTORIA: [inaudible 33:47] impact junkie. That's funny. But yeah, no, thank you for sharing that. That's really interesting. Let me see if you could go back in time to when you first started in this journey; if you could give yourself any advice, what would you say? +ROBBIE: Yeah, I think I spent so much time being nervous about not having my degree that I was worried it was going to hinder me forever. And it's pretty amazing the career I've been able to thread together, right? Like, you know, I've hit on a few of them already. +But, like, I started with a small web hosting company, and then New York State in the Department of Social Services, then New York City in the Human Resources Administration, Sony Music, Zagat Survey, Google, Johnson & Johnson, IDT telecommunications, Phase2 technologies, where I got to work on an awful lot of problems in lots of awesome places like NBA.com, and Major League Soccer, and Bassmaster. And then, the United States Digital Service where I got to work on things supporting the Department of Veterans Affairs and the Department of Homeland Security over at ADA.gov in DOJ. I helped them out. And I worked over at USDA helping get Farmers.gov off the ground. +So, everything on my left leg, tattoo-wise, is something that changed my life from my perspective. And I have a Drupal tattoo on the back of my leg. I have a DrupalCon. So, anytime somebody said "Drupal" anywhere near a USDS person, I would magically appear because they would just be like, "Oh, Robbie has that Drupal tattoo." So, I got to work on a lot of dot govs that eventually landed or were being built in Drupal. So, I got to support a lot of work. And it meant that I got to, like, float around in government and do a lot of things that others didn't get to do. +When CISA stood up, which is the office of security inside of DHS, it's one of the newest sub-communities or subcomponents, they built DHS SchoolSafety.gov, which is a cross-MOU'd site. And I got to sit in and help at the beginning of that because of my Drupal background. But it was really fun to be the person who helped them work with the vendors and make sure that they understood what they were trying to accomplish and be a sort of voice of reason in the room. +So, I did all of that work, and then after that, I went and worked at Pluribus Digital, where I got a chance to work side by side with you. And then, that led to other things, like, I was able to apply and become the director of Digital Services and software engineering for my local county. So, I worked for Prince William County, where I bought a house during the pandemic. And then, after that contract ended, I had already started my own business. So, that's led to me having multiple individual contracts with companies and so many people. I've gotten to work on so many different things. And I feel very lucky. +If I could go back and tell myself one thing, it's just, take a breath. Everything's going to be okay. And focus on the things that matter. Focus on the things that are going to help you. Focus on community. Focus on delivering value. Everything else will work itself out. You know, I joke all the time that I'm really good at providing impact. If you can measure my life in impact and value, I would be a very rich man. If you can measure it in money, I'm doing all right, but I'm never going to be yacht Robbie, you know, but I'm going to do okay. +VICTORIA: Oh my god, yacht Robbie. That's great. So, just to recap, everything's going to be okay. You never know where it's going to take you. And don't be limited by the things that you think, you know, make you not enough. Like, there's a lot of things that you can do out there. I really like that advice. +ROBBIE: And I think one last piece is, like, community matters, if you are a part of communities and you do it genuinely, how much that will impact your career. I gave a talk from Drupal NYC to the White House and beyond. And I talked through my entire resume and how everything changed when I started doing community engagement. When I went to the Drupal community in New York City and how that led to Sony, and that led to Zagat, which led to me getting acquired by Google, like, these things all cascaded. +And then, when I moved to the DMV, I was able to join here and continue supporting communities, which allowed me to bring people into the local civic tech community from the local DC tech community. So, so many of the best USDS engineers, and designers, and product people I was able to help influence to come to government were people I met in the community or the communities I helped support. You know, I was an early revivalist of Alexandria Code and Coffee. It was a community that was started and then wavered. +And then, Sean McBeth reached out to the community and said, "Do we want to help and support getting it off the ground again?" And I immediately said, "Yes." And then, that led to my friends at BLACK CODE COLLECTIVE wanting to create a community where they could feel safe and connected and create a community of their own. And then DC Code & Coffee started. And from there, Baltimore Code & Coffee kicked off. +And it's just really nice that, like, it doesn't matter where I've been. All these things keep coming back to be a part of community and help support others. And you will be surprised at how much you get back in return. I wouldn't be the person I am today in my community. I wouldn't have my career if it wasn't for the people who started and helped shepherd me when I was starting out. And I feel like I've been trying to do the same for people for a really long time. +VICTORIA: I love that. That's what I say, too, when people ask me for advice on careers and how to grow. And my biggest piece is always to go out and meet people. And go to your community, like, look and see what's happening. Like, find people you like hanging out with and learning from. And just that should be the majority of your time probably if you're trying to figure out where to go with your career or even just, like, expand as a person sometimes [laughs]. +Robbie, I was going to ask; you mentioned that you had bought a house in Virginia. One of my other warmup questions was going to be, what's your favorite thing to put on the grill? +ROBBIE: My house in Virginia definitely gets a lot of use, especially in the spring and the fall. I'm a big fan of team no extreme when it comes to temperature. But during those time periods, my grill is often fired up. My favorite is probably to make skirt steak on the grill. I'm a huge fan of tacos, especially made out of skirt steak. I'm in all day. That's one of my favorites. +I also love to smoke. I have a smoker because I'm a caricature-esque suburban dude. I'm going to live into all of the possible things I could have. But I've had a smoker for a long time, and I love making sort of poor man's burnt ends. It's one of my favorite things to make. But you got to have some time. That's the kind of thing that takes, you know, 14 hours or 16 hours, but it's really fun to take advantage of it. +A quick thing I love to make is actually smoked salmon. It takes longer to brine it than it usually does to smoke it. But it is one of the nicest things I've made on my smoker, you know, fresh pesto on a piece of salmon is pretty awesome, or everything bagel. Everything with the bagel seasoning is a pretty fun way to smoke some salmon. +VICTORIA: Wow, that sounds so good. I'm going to have to stop in next time I'm in Virginia and get some [laughs] and hang out. Do you have any questions for me? +ROBBIE: I'm excited to see where you've gone and how you've gotten here. I think this is such a cool job for you. Knowing who you are as a person and seeing you land in a company like this is really exciting. And I think you getting to be a part of this podcast, which we were joking about earlier, is I've been listening to probably since it started. I've been a big fan for a long time. So, it's cool to be here on this podcast. But it's also cool that my friend is a part of this and gets to be a part of this legacy. +I'm really excited to see where you go over time. I know my career has been changing, right? I worked in government. Before that, I did all kinds of other stuff. Nowadays I have my own business where I often joke I have sort of, like, three things I offer, which is, like, consigliere services. Wouldn't it be nice to have a Robbie on your executive team without having to pay them an executive salary? +You know, another one is like, you know, strategy and mentoring, but these are all things I know you do also, which I think is cool. But I've been working on contracts where I support companies trying to figure out how they modernize, or how their CTO can be more hands-off keyboard, or how their new director of business development can be more of a technical leader and taking on their first direct reports. So, I just enjoy all those aspects, and I just think it's something that I've watched you do in the company where we worked together. +And it's always fun to see what you're working on and getting a chance to catch up with you. I feel like you're one of those people that does a really great job of staying connected. Every once in a while, I'll get a random text message like, "Hey, how you doing?" It always makes me smile. I'm like, Victoria is a really good connector, and I feel like I am, but you're even better at it on the being proactive side. That's how this all came about, right? We caught up, and you were like, "Why don't you come on the podcast?" So, that's really exciting. +VICTORIA: Well, thank you, Robbie. Yeah, I think that's one of the great things about community is you meet people. You're like, "Oh, you're really cool. And you're doing cool stuff all the time. Like, how can I support you in your journey [laughs]? Like, what's up?" +Yeah, for me, it was hard to actually leave DC. I didn't, you know, really think about the impact of leaving behind my tech community, like, that network of people. It was pretty emotional for me, actually, especially when we finally, like, stopped doing the digital version [laughs]. And I, like, kind of gave up managing it from California, which was kind of funny anyways [laughs]. Yeah, so no, I'm grateful that we stayed in touch and that you made time to be here with us today. Is there anything else that you would like to promote? +ROBBIE: You know, just to remind you, you've done a great job of transitioning into where you are today, but anybody can do that, right? Like, before I moved to the DC area, I was in New York, and I was helping to organize JavaScript events. And I started looking at the DC area before I moved down here. And I found the DC Tech Community. And I found the Node School DC GitHub organization and reached out to the person who had ownership of it and said I wanted to help and support. +I looked at this the other day. I think I moved on May 8th, and then, like, May 11th, when I walked in the door, somebody was like, "Are you new?" And I was like, "Yeah, I just moved here." And they were like, "Oh, from where?" And I was like, "New York." And they were like, "Are you that guy who's been bugging Josh about running Node school events?" I was like, "Yeah." And like, they were planning an unconference at the end of the month. And they were like, "Would you like to run a Node school at that unconference?" Like, 27 days later. +So, it was amazing that, like, I immediately, like, fell from the New York Community where I was super connected, but I went out of my way to try to, like, see what the community looked like before I got there. And I was lucky enough to find the right people, and immediately I joked...I think I wrote a blog post that said like, "I found my new friends. By, like, going from one community to another, gave a person who was in his 40s a chance to meet new people very quickly." And it was pretty amazing, and I felt very lucky. But I did spend a little bit of energy and capital to try to figure it out because I knew it was going to be important to me. +So, I think you've done a really good job. You've helped launch and relaunch things that were going on in San Diego and becoming a part of this connection to more people. I think you and I have a very similar spirit, which is like, let's find a way to connect with humans, and we do it pretty effectively. +VICTORIA: Well, thank you. That really boosts my confidence, Robbie [laughs]. Sometimes, you show up to an event you've never been to before by yourself, and it's like a deer in headlights kind of moment. Like, oh God, what have I done [laughs]? +ROBBIE: Oh, and the last thing I need to mention is I also have a podcast. I have my podcast about film. It's called Geek on Film. I used to record it with my friend, Jon. He's a little busy right now. But I used to pitch it as a conversation show about the current films that were going on. Now, it's one lone geek's ramblings about what he just saw. +It's a great podcast for me because it gives me an opportunity to think a little more critically about film, which is one of the things that I probably have almost enough credits to get a minor in. But I absolutely love cinema and film in general. And it's given me an opportunity to connect with a lot more people about this subject and also to scratch the itch of me being able to create something around a community and around a thing I really love. +VICTORIA: That's super cool. Yeah. You're top of mind because I also like films. I'm like, what's Robbie up to? Like, what's the recommendations, you know [laughs]? Do you have a top film recommendation from the Oscars? Is that too big of a question? +ROBBIE: So, the one I will say that didn't get enough spotlight shined on it was Nimona. So, I'm a huge fan of the Spider-Man movies. I think Spider-Man Into the Spider-Verse and Across the Spider-Verse are both masterpieces. But Nimona is an animated film that was picked up by Netflix, and it is amazing. +I don't know that I laughed or cried or was more moved by a film last year. And I don't know that it gets enough credit for what it was. But it did get nominated for best-animated film, but I don't know that enough people paid attention to it. Like it may have gotten lost in the algorithm. So, if you get a chance, check out Nimona. It's one of those beautiful, little gems that, if you travel down its story, there's all these twists and turns. +It was based on a webcomic that became a graphic novel. One of the production companies picked it up, and it wasn't going to see the light of day. And then, Netflix bought its distribution rights. There's going to be a great documentary someday about, like, Inside Nimona. But I think the movie itself is really charming and moving, and I was really impressed with it. So, that was the one that got me, like, just before the Oscars this year, where I was like, this is the little animated movie that could, in my opinion. It's so charming. +VICTORIA: I will definitely have to check that out. Thank you for giving us that recommendation. +ROBBIE: Totally. +VICTORIA: Final question. I just wanted to see if you had anything to share about being an advisory board member for Gray and for Hutch Studio. Could you tell us a little bit more about that? +ROBBIE: Yeah. So, Gray Digital was founded by a friend of mine. We met through United States Digital Service. And his organization...I had been supporting him for a while and just being behind the scenes, talking to him and talking through business-related issues. And it was really nice. He offered to make me an official advisory board member. It was a great acknowledgment, and I really felt moved. There's some great people that are supporting him and have supported him. They've done really great work. Gray is out there delivering digital services in this space. And I think I was really lucky to be a part of it and to support my friend, Randall. +Hutch is different. Hutch is an organization that's kind of like if you think about it, it almost is a way to support entrepreneurs of color who are trying to make their way into the digital service delivery space. Being an advisory board member there has been really interesting because it's shaping how Hutch provides services and what their approach is to how to support these companies. +But over the last year, I've convinced the person who's running it, Stephanie, with a couple of other people, to open the door up or crack the door so we could talk directly and support the individual companies. So, it's been really great to be a Hutch advisory member to help shape how Hutch is approaching things. +But I've also been a part of, like, many interview processes. I've reviewed a lot of, like, [inaudible 48:01] who want to join the organization. And I've also created personal relationships with many of the people who are part of Hutch. And, you know, like, you know me personally, so you know I run a Day of the Dead party. We'll just party at my house every year. +I have a huge amount of affection for Mexican culture and, in general, the approach of how to remember people who are a part of your life. So, this is, like, the perfect way for me to bring people together at my house is to say, like, "Hey, my dad was awesome. What about your family? Who are your people?" What's really nice is that has given me an opportunity to host people at my house. +And I've had Hutch company owners at my house the last couple of years and the person who runs Hutch. So, it's a really great community that I look at that is trying to shape the next emergent companies that are helping deliver digital services across the government. And it's really fun to be early on in their career and help them grow. +Again, it seems silly, but it's the thing I care a lot about. How do I connect with people and provide the most value that I can? And this is a way I can provide that value to companies that may also go off and provide that value. It's a little bit of an amplifier. So, I'm a huge fan of what we've been able to accomplish and being a part of it in any way, shape, or form. +VICTORIA: Well, I think that's a really beautiful way to wrap it up. +ROBBIE: Really glad to catch up with you and be a part of this amazing podcast. +VICTORIA: Yeah, so much fun. Thank you again so much. It was great to be here with you today. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on thoughtbotsocial@vguido. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + civic tech, public interest technology, drupal community, technology consulting, career development, tech community, open source solutions, U.S. Digital Service, process automation, tech podcasts, community impact in technology, career paths in tech, New York technology, tech networking, tech leadership, from web hosting to consulting + + Victoria Guido hosts Robbie Holmes, the founder and CEO of Holmes Consulting Group. The conversation kicks off with Robbie recounting his initial foray into the tech world at a small web hosting company named A1 Terabit.net, chosen for its alphabetical advantage in the white pages. This job was a stepping stone to a more significant role at Unisys, working for the state of New York's Department of Social Services, where Robbie inadvertently ventured into civic tech and public interest technology.

+ +

Robbie shares his career progression from supporting welfare systems in New York to becoming a technological liaison between the city and state, leading to a deeper involvement in open-source solutions. His journey through tech spaces includes developing websites, diving into the Drupal community, and eventually establishing his consulting business. Robbie emphasizes the serendipitous nature of his career path, influenced significantly by community involvement and networking rather than a planned trajectory.

+ +

Additionally, Robbie gives insights on the impact of technology in public services and his stint with the U.S. Digital Service (USDS), where he contributed to significant projects like vets.gov. Robbie promotes the value of community engagement in shaping one's career, stressing how connections and being in the right place at the right time can lead to unexpected opportunities and career pivots.

+ + + +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Robbie Holmes, Founder and CEO of Holmes Consulting Group. Robbie, thank you for joining me.

+ +

ROBBIE: I'm so happy to be here. It's great to talk to you, Victoria.

+ +

VICTORIA: Yes. I have known you for a long time now, but I don't know everything about you. So, I thought I would start with the question: What was your first job that you ever had?

+ +

ROBBIE: My first technical job, I ended up working for an internet web hosting company called A1 Terabit.net. And note the A1 because it came first in the white pages. It was a really small web hosting company run by a man named [SP] Maxim Avrutsky. I worked there for about six months before I submitted my resume to an online job forum. That's how old I am. And it ended up in the hands of Unisys, where I eventually worked for the state of New York.

+ +

VICTORIA: Wow [laughs]. So, what a journey that you've been on to get from starting there, and what a marketing ploy back in the day with the white pages. So, tell me a little bit more about how you went from that first job to where you are today with having your own business in consulting.

+ +

ROBBIE: Yeah, I wasn't even aware that I was jumping into the sort of civic tech space and public interest technology because the job I ended up with was working for New York State in the Department of Social Services. And welfare is federally funded and distributed to states and then states to localities. And New York City and New York State have a weird parasymbiotic relationship because over 50% of the welfare in New York State goes to the five boroughs in New York City. So, so much of my job was supporting the welfare system within the city, which was run by the human resources administration.

+ +

So, that just led to this cascade of me, like, getting invested in supporting that, and then eventually jumping over to the other side where I worked for the City of New York. And at that point, I ended up becoming sort of a technology project manager and almost a tech liaison between the city and state. And I was out in the welfare centers, helping get the job centers up to a new application called the Paperless Office System, which was a client-server app that was a wrapper around welfare.

+ +

All of that ended up leading to me finally making it to the network operation center for the City of New York, where I started replacing expensive solutions like HP OpenView with open-source solutions like Nagios and another open-source solution that provided an interface. And it really opened my eyes to the idea of open source. And I had really paid attention to a lot of open-source operating systems. So, I was kind of just a general tech nerd.

+ +

And eventually, I started building websites, and that led me to the Drupal community in New York City, which was sort of this cascade that led me to communities. And I think that's sort of a through line for my entire career is I don't really think I ever had a plan. I think my entire career has been this sort of a lucky happenstance of being prepared when an opportunity arose and sometimes being in the right place because of my connections and community.

+ +

VICTORIA: That's interesting about being involved with the people around you and seeing what problems are out there to solve and letting that lead you to where your interests lie. And then, following that, naturally led you to, like, this really long career and these really interesting, big projects and problems that you get to solve.

+ +

ROBBIE: Yeah. And I think one interesting aspect is like, I feel I spent a lot of time worried about what I was going to do and where I was going to do it. I don't have a bachelor's degree. I don't have an advanced degree. I have a high school diploma and a couple of years in college. Well, 137 credits, not the right 125 or 124 to have a bachelor's degree. I have enough credits for a couple of minors though, definitely Greek art history, I think mathematics, maybe one more. I just never got it together and actually got my degree. But that was so interesting because it was limiting to what jobs I could find.

+ +

So, I was in the tech space as an IT person and specifically doing networking. So, I was running the network operation center. I helped, like, create a whole process for how we track tickets, and how we created tickets, and how things were moved along. And, in the process, I started building websites for family and friends.

+ +

And I built a website for our network operation center, so that way we could have photos to go with our diagrams of the network. So that way, when we were troubleshooting remotely, we could actually pull up images and say, "The cable that's in port six goes off to the router. I think that port is dead. Can we move it to the port two to its right, and I'll activate it?" And that made a really interesting solution for something we weren't even aware we had, which was lack of visibility. So many of the people in the fields were newer or were trying to figure it out. And some of us had really deep knowledge of what was going on in those network rooms and hubs.

+ +

It led me to this solution of like, well, why don't we just start documenting it and making it easier for us to help when they're in the field? That led me to, like, the Drupal community because I started building sites in the Drupal CMS. And I went to, like, my first Drupal meetup in 2007, and there was, like, five of us around the table. That led to eventually me working for Sony Music and all these other things.

+ +

But the year before I found my way to the Drupal community, I probably sent out, like, 400 resumes for jobs in the tech space, didn't really get any callbacks. And then, I met the community, and I started attending events, and then eventually, I started organizing events. And then, Sony I interviewed and talked to them a couple of times. And then, a friend of mine became the boss. And she contacted me and was like, "Hey, are you in the market?" And I was like, "I don't know. Why? What's up?" And she's like, "I became Doug." And I was like, "What?" And she was like, "I'm now replacing Doug at Sony. I'm running the team." And I was like, "Yeah, I'm happy to talk."

+ +

And that was the big transition in my career from IT to sort of development and to delivery, right? Like, when it comes right down to it, is I became the manager of interactive media at Sony Music, which was really a job I landed because I was connected to the community, and running events, and getting to know everyone.

+ +

VICTORIA: Yeah. And I think it's really cool that you had this exposure early on to what you called civic tech, which we'll get into a little bit, and then you went from the community into a commercial technology space and really getting into engineering with Drupal.

+ +

ROBBIE: Yeah, it was an interesting transition because what they needed at Sony was sort of somebody who could ride the line between systems engineer, database administrator, and Drupal engineer, and also probably pre-DevOps DevOps person. So, I was responsible for all deployments and all tickets that came in. I was sort of both the technical arm of the help desk. When I joined, there was 24 websites on the Drupal platform, and when I left, there was over 200. And we upgraded it from Drupal 5 to Drupal 6 to Drupal 7 while I was there. So, I was heavily involved in all of those updates, and all those upgrades, and all of the deployments of all the new themes, and all the changes to all these sites.

+ +

So, what was great was they, I believe, if I understand it correctly, they actually created a role for me out of, like, two or three jobs because they needed a me, and they didn't have a role that existed. So, all of a sudden, they made a manager of interactive media role. And I was able to work there for two years, sort of being what I jokingly say, like, a digital janitor. I used to say that I had, like, an eight-bit key ring in a push broom. And I was always mad at your kids for trying to break my stuff.

+ +

VICTORIA: [laughs] That's so good. A digital service janitor [laughs]? The connection for me between that and where I met you in the U.S. digital service space [laughs] I feel like there's a lot of parallels between that and where your career evolved later on in life.

+ +

ROBBIE: Yeah. What's amazing is I did all this early work in my career in civic tech and didn't realize it was civic tech at the time. I just realized what I was doing was providing this huge impact and was value. You know, I spent a couple of years in the welfare centers, and I used to say all the time that the two hardest jobs in the welfare center are the person applying for welfare and the person deciding whether or not that person gets welfare. So, being a technologist and trying to help make that as simple as possible or easier and smooth the edges off of that process was really important.

+ +

And it really taught me how important technology is to delivering service. And I really never thought about it before. And then, when I was working for Phase2 technologies, I was a director of Digital Services. And I read in a blog post, I believe that was written by Mikey Dickerson, who was the original administrator for USDS, and he talked about HealthCare.gov. And he walked in the door, and he said, "How do you know HealthCare.gov is down?" And I think there was some allusion to the fact that we were like, we turn on the television and if they're yelling at us, we know it's down. And Mikey was like, "We know how to monitor things."

+ +

So, like, if you don't know Mikey Dickerson, he's the person who sort of created the web application hierarchy of needs in Google. He was an SRE. And his pyramid, like Maslow's hierarchy of needs, was all over Google when I was there. I was so impressed with the idea that, like, we aren't talking about how do we solve this problem? We're talking about knowing when there's a problem. And then, if we know there's a problem, we can put some messaging around that. We can say, like, "We're aware," right? Like if the president calls the secretary, the secretary can say, "We know it's down. We're working on it," which is building up political capital.

+ +

It's a really amazing process that I kept reading this blog post, and I was like, God, that's how I would approach it. And then, I was like, wow, I wonder if I could use my skills to help America, and very shortly submitted an application and was like, well, we'll see what happens. And about six months later, I walked in the door at the VA and was the eighth employee of the Digital Service team at the VA. That was a franchise team of the USDS model.

+ +

VICTORIA: And can you say a little bit more about what is the U.S. Digital Service and expand upon your early experience there?

+ +

ROBBIE: Yeah. So, the United States Digital Service was created after HealthCare.gov had its issues. Todd Park had convinced President Obama to reach out to get support from the private industry. And the few of the people who were there, Todd convinced to stick around and start creating a team that could support if there was this kind of issue in the future. I believe the team that was there on the ground was Mikey Dickerson, Erie Meyer, Haley Van Dyck, and Todd. And there was a few other people who came back or were very close at the beginning, including the current administrator of USDS. She has been around a long time and really helped with HealthCare.gov. It's amazing that Mina is back in government. We're very lucky to have her.

+ +

But what came out of that was what if we were able to stand up a team that was here in case agencies needed support or could vet solutions before these types of problems could exist? So, USDS was what they called the startup inside the White House that was created during the 2014 administration of President Obama. The team started that year, and I joined in May of 2016. So, I would be, like, sort of the beginning of the second team of the VA U.S. Digital Service team.

+ +

So, USDS supported this idea of tours of duty, where you're a schedule A employee, which meant you were a full-time government employee, but you were term-limited. You could do up to two years of duty and work, and then you could theoretically stick around and do two more years. That was how these roles were envisioned. I think there's lots of reasons why that was the case. But what's nice is it meant that you would come in with fresh eyes and would never become part of the entrenched IT ecosystem.

+ +

There are people that transition from USDS into government, and I think that's a huge value prop nowadays. It's something that I don't know they were thinking about when the original United States Digital Service was stood up, but it was hugely impactful. Like, I was part of the team at the VA that helped digitize the first form on vets.gov and all the work that was done. When the VA team started, there was a team that was helping with veteran benefits, and they worked on the appeals process for veteran benefits. And I joined. And there was a team that was...eventually, it became dubbed the veteran-facing tools team.

+ +

And we worked on vets.gov, which was a new front door to expose and let veterans interact with the VA digitally. And over time, all the work that went into the tools and the solutions that were built there, everything was user-researched. And all of that work eventually got brought into VA.gov in what they called a brand merger. So, we took, like, the sixth most trafficked front door of the VA and took all the modern solutioning that that was and brought it into VA.gov, the main front door. So, all of a sudden, there was an identity, a login provided on VA.gov for the first time. So big, impactful work that many people were a part of and is still ongoing today.

+ +

Surprisingly, so much of this work has now fallen under OCTO, which is the Office of the CTO in the VA. And the CTO is Charles Worthington, who was a USDSer who's the epitome of a person who goes where the work is. Charles was a Presidential Innovation Fellow who helped out in the times of HealthCare.gov and, joined USDS and did anything and everything that was necessary. He interviewed engineers. He was a product person. Charles is one of the most unique technologists and civic tech people I've ever met in my life.

+ +

But Charles, at the end of the Obama administration and in this transition, realized that the VA was in need of someone to fill the CTO role. So, he came over to become the interim CTO because one of the values of USDS is to go where the work is. And he realized, with the transition, that Marina Nitze, who was the CTO who was transitioning out, there was going to be a need for continuity. So, he came in to provide that continuity and eventually became the full-time CTO and has been there ever since.

+ +

So, he has helped shape the vision of what the VA is working towards digitally and is now...he was just named the Chief AI Officer for the agency. Charles is a great person. He has successfully, you know, shepherded the work that was being done early by some of us into what is now becoming a sort of enterprise-wide solution, and it's really impressive.

+ +

VICTORIA: I appreciate you sharing that. And, you know, I think there's a perception about working for public service or for government, state or federal agencies, that they are bureaucratic, difficult to work with, very slow. And I think that the USDS was a great example of trying to really create a massive change. And there's been this ripple effect of how the government acquires products and services to support public needs, right?

+ +

ROBBIE: Yeah, I would say there's a couple of arms of the government that were sort of modernization approaches, so you have the Presidential Innovation Fellows, which are the equivalent of, like, entrepreneurs and residents in government. And they run out of...I think they're out of the TTS, the Technology Transformation Service over at GSA, which is the General Services Administration. But the PIFs are this really interesting group of people that get a chance to go in and try to dig in and use their entrepreneurial mindset and approach to try to solve problems in government. And a lot of PIFS work in offices.

+ +

Like, Charles' early team when he first became the CTO included a lot of Presidential Innovation Fellows. It was basically like, "Hey, the VA could use some support," and these people were available and were able to be convinced to come and do this work. And then, you have the Presidential Management Fellows, which I think is a little bit more on the administration side. And then, we have 18F and USDS.

+ +

The United States Digital Service is a funded agency with an OMB. And we were created as a way to provide the government with support either by detailing people over or dropping in when there was a problem. And then, 18F is an organization that is named because the offices of GSA and TTS (Technology Transformation Service), where it's housed, are on the corner of 18th Street and F in DC. And 18F is sort of like having a technology or a digital agency for hire within the government. So, they are full-time employees of the government, sort of like USDS, except government agencies can procure the support of that 18F team, just like they would procure the support of your company. And it was a really interesting play.

+ +

They are fully cost-recoupable subcomponent of TTS, which means they have to basically make back all the money that they spend, whereas USDS is different. It's congressionally funded for what it does. But they're all similar sibling organizations that are all trying to change how government works or to bring a more modern idea or parlance into the government. I used to say to people all the time that at USDS, you know, we would set a broken bone say, and then we would come back around and say, like, "Hey, does your arm hurt anymore?" The idea being like, no. Be like, "Cool, cool. Maybe you should go to the gym, and you should eat better." And that would be, like, procurement change. That would be, like, changing for the long term.

+ +

So, all the work I was doing was building political capital so we could do better work in changing how procurement was done and then changing how the government delivered these things. So, what was awesome was, like, we used to have these fights at USDS about whether or not we were a culture change or we were firefighters. And I think the reality is once we're involved, culture changes happen. The bigger question is, are we going to be there for the long haul, or are we only there for a shorter period of time? And I think there are reasons why USDS teams had both plays. And I think it really is just two different plays for the same outcome.

+ +

VICTORIA: Yeah, that makes sense. And to pivot a little bit, I think, you know, our audience, we have clients and listeners who are founders of products that are aimed at making these, like, public service needs, or to give some examples, like, maybe they're trying to track Congressional voting patterns or contact information for different state representatives, and they're trying to navigate this space [laughs]. So, maybe you can give some advice for founders interested in selling their products to government agencies. What can they do to make it more appealing and less painful for themselves?

+ +

ROBBIE: I wouldn't consider myself a procurement expert, but at USDS, the procurement team called themselves the [SP] procurementati.

+ +

And I was a secret member of the procurementati. I often was the engineer they would call to evaluate statements of work or sometimes be on technology evaluation panels. And it was fun to be a part of that. Things that most companies don't realize is government agencies will put out things like request for information or sources sought in the government space. And this is a way for industry to influence how government tries to solve problems.

+ +

If you are trying to go after government work and you're only responding to an RFP, you're probably behind in your influence that you could have on the type of work. So, you'll see if a procurement seems to be, like, specifically focused on an approach, or a technology, or a framework, it's probably because some companies have come through and said, "I think this would probably solve your problem," and they gave examples. So, that's one way to be more connected to what's going on is to follow those types of requests.

+ +

Another is to follow the money. My wife is this amazing woman who helped write The Data Act and get it passed through government. And The Data Act is the Data and Transparency Act. And that led to her heading over to treasury and leading up a team that built USAspending.gov. So, there is a website that tracks every dollar, with some exceptions, of the funding that comes out of Congress every year. And what's great is you can track it down to where it's spent, and how it's spent, and things like that. For education purposes, I think that is a really good thing that business and growth people can focus on is try to see and target where competitors or where solutions that you've looked at have gone in the past. It's just a good set of data for you to take a look at.

+ +

The other piece is if you're creating a solution that is a delivery or a deliverable, like a SaaS solution, in order for something to be utilized in the government, it probably needs to be FedRAMP-approved, which is a process by which security approvals have been given so that government agencies have the green light to utilize your solution. So, there's tons of documentation out there about FedRAMP and the FedRAMP approval process. But that is one of those things that becomes a very big stopping point for product companies that are trying to work in the government.

+ +

The easiest way to work your way through that is to read up on it a bunch, but also find an agency that was probably willing to sponsor you getting FedRAMP approval. Most companies start working with a government agency, get an exemption for them to utilize your product, and then you get to shape what that FedRAMP process looks like. You start applying for it, and then you have to have some sort of person who's helping shepherd it for you internally in the government and accepting any issues that come along in the process. So, I guess FedRAMP approval is one that's a little complicated but would be worth looking into if you were planning on delivering a product in government.

+ +

VICTORIA: Right. And does that apply to state governments as well?

+ +

ROBBIE: So, lots of state-related and city and locality-related governments will actually adopt federal solutions or federal paradigms. So, I think in the state of California, I think FedRAMP as one of the guiding principles for accepting work into the state of California, so it's not consistent. There's not a one-to-one that every state, or every city, or every locality will pull this in. But if you are already approved to be a federal contractor, or a federal business, or a federal product, it's probably going to be easier to make your way into the local spaces also.

+ +

VICTORIA: Right. And as you said, there's plenty of resources, and tools, and everything to help you go along that journey if that's the group you're going for [laughs].

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: So, kind of bringing it back to you, like, you're saying you want those partnerships within the government. You want someone advocating for you or for your product or your service. Drawing that back to what you said earlier about community, like, how do you form a community with this group of people who are in the state, or federal government, or civic tech spaces?

+ +

ROBBIE: Yeah, I think it's an interesting problem because so much of it feels impenetrable from the outside. Most people don't even know where to start. There are organizations out there that are pretty good community connections, an example I would give is ACT-IAC. It is a public-private partnership where people from within the government, experts in their fields, and people in the private industry who are experts in their fields will be together on community boards and engaging in panels. And so, it's a really nice way to start connecting those dots.

+ +

I have no direct affiliation with ACT-IAC. But if they'd like to give me my own account, that would be great. But it is one of those organizations I've seen be successful for people trying to find their way into a community that is a little harder to find.

+ +

I think, also, so much of the community engagement happens at conferences and around...so, like, if you're in the healthcare space, this last month, you've had multiple conferences that I think were really great for people to get to know one another, you know, an example is ViVE. It just happened out in LA, which is a little more on the private sector health space, but still, government agencies were there. I know that the Department of Veterans Affairs had people there and were on panels. And then, HIMSS is another conference that takes place, and that just took place down in Miami. And in Miami, HIMSS happened and a whole bunch of other social community events took place.

+ +

So, I'm close with a thing called the Digital Services Coalition, which is 47 companies that all try to deliver good government based on the Digital Services Playbook that was created by USDS that lives at playbook.cio.gov and the way that they try to accomplish this work. And that organization, while they were in Miami, hosted a happy hour. So, there's a lot of connections that can be made once you start seeing the players and getting to know who's around. So, it's a little bit about trying to find your way to that first event, and I think that will really open up everything for you.

+ +

Within a week or two, I was at an International Women's Day event at MetroStar, which is a really great company that I've gotten a chance to spend some time with. And then, I was at an event for the Digital Services Coalition talking about open source in government. So, there's a lot of stuff out there for you to be a part of that isn't super cost-prohibitive and also doesn't take a lot once you start to open the door. You know, once you peek around that corner and you find some people, there's a lot more to be done.

+ +

VICTORIA: Yeah. And you touched on something at the end there that wants me to bring up some of the advantages you can have being a small business, a minority-owned business, or woman-owned business, or veteran-owned business, so thinking about how you can form those connections, especially if you have one of those socio and economic set-asides that you might want to consider if they're looking to work with the government as well.

+ +

ROBBIE: Yeah. Those socioeconomic set-asides include small businesses, woman-owned small business. I think it's Native and Alaskan 8(a), which is historically underrepresented and service-disabled veteran-owned. So, there are also sub-communities of associations, like there's the Digital WOSB, the digital Women-Owned Small Business alliance that was founded by Jess Morris from Pluribus Digital, and a bunch of other companies in the Digital Services Coalition. I believe she's the president of the Digital WOSB right now.

+ +

That is a sub-community of women-owned small businesses that are trying to connect and create a community that they can support one another. And that's just one example of the type of connection you can make through those types of socioeconomic set-asides. But once you have those official socioeconomic set-asides, it will allow you to get specific contracts engagements in the government that are not allowed or available for others. So, the government procurement process will have some amount of these specific socioeconomic set-asides that need to be hit. Like, 8% of all procurements need to go to this and 10% of all procurements need to go to this.

+ +

So, I think the VA is probably one of the most effective at hitting any of the socioeconomic set-asides, specifically related to service-disabled veteran-owned small businesses. So, if you happen to be a person of color and you found a business and you are female presenting, right? You may have 8(a) woman-owned small business. If you also happen to be a veteran and you're service-disabled, all of those things stack. You don't just get to have one of them. And they can be really effective in helping a business get a leg up and starting out and trying to help even the playing field for those communities.

+ +

VICTORIA: Yeah. What I really appreciated about my experience working with Pluribus Digital, and you, and people who had had that experience in the U.S. Digital Services, that there is this community and desire to help each other out and that you can have access to people who know how to move your product forward, get you the connections that you need to be competitive, and to go after the work. So, I love encouraging people to consider civic tech options. And maybe even say more about just how impactful some of it can be. And what kind of missions are you solving in these spaces?

+ +

ROBBIE: Yeah, I often try to remind people, especially those who are heading towards or considering civic tech, there are very few places in this world that you can work on something that can impact millions of people. Sure, I was lucky enough. I have tons of privilege. I worked at a lot of wacky places that have given me the access to do the type of work that I think is impactful, but very little has the kind of impact.

+ +

Like, when I was interviewed by Marina Nitze as, my last interview when I joined USDS, she sent me an email at the end of it and said like, "Everything was great. I look forward to working with you. And remember, every time you commit code into our GitHub, you'll be helping 8 million veterans." And then, she cc'd Todd Park. And Todd was the CTO of the U.S., and he responded back within a minute. Todd is one of the most busy people. It was amazing to me how fast he responded. But he was like, "Lemme tell you, as somebody who can talk on behalf of our president, our country needs you." And those kinds of things they're hard to comprehend.

+ +

And then, I joined the Digital Service team at the VA. And one of the first things that I got to support was the 10-10EZ. It's the healthcare application for veterans. And before I got there, it was a hosted PDF that we were trying to replace. And the team had been working for months to try to build a new, modern solution. What it was is it was, like, less than six submissions were happening a day because it only worked in Adobe Acrobat, I think it was 6.5 and below, and Internet Explorer 8.5 and below.

+ +

And if you think about the people that could submit utilizing that limited set of technologies, it was slowly becoming homeless veterans who were using library computers that had not been upgraded. So, there was a diminishing amount of value that it was providing. And then, on top of it, it was sort of lying to veterans. If the version of the Adobe Acrobat was out of date, or wrong, or too new, it would tell them to upgrade their browser. So, like, it was effectively not providing any value over time.

+ +

We were able to create a new version of that and that was already well on its way when I joined, but we were able to get it out the door. And it was a React frontend using a Node backend to talk to that SOAP API endpoint. Within the first week, we went from 6 submissions a day to 60 submissions a day. It's a joke, right? We were all 10x developers. We were like, "Look at us. We're killing it."

+ +

But about three years later, Matt Cutts came to a staff meeting of USDS, and he was the second administrator of the USDS. And he brought the cake that had the actual 10-10EZ form on it, and it said, "500,000." And he had checked with the analytics team, and there were over 500,000 submissions of that form, which means there are 500,000 possible veterans that now may or may not have access to healthcare benefits. Those are big problems.

+ +

All of that was done by changing out one form. It opened up the world. It opened up to a group of veterans that no one else was able to do. They would have had to go into a veteran's office, and they would have had to fill it out in paper. And some veterans just don't have the ability to do that, or don't have an address, or don't have a...so, there are so many reasons why having a digital form that worked for veterans was so important. But this one form that we digitized and we helped make modern has been submitted so many times and has helped so many veterans and their families. And that's just one example. That's just one form that we helped digitize.

+ +

But now the team, I mean, I'm back in the VA ecosystem. There's, like, 2,500 people in the general channel in the office of the CTO Slack organization. That's amazing. There's people there that are working all day, every day, trying to solve the same problems that I was trying to solve when I got here. And there's so much work being done to help veterans. But that's just one example, right? Like, at USDS, I know that the digital filing for the free version of your tax form, the IRS e-file Direct, just went live. That was something that USDS had been working on for a very long time behind the scenes. And that's going to impact everybody who submits their taxes.

+ +

These are the kind of problems that you get to work on or the scope of some of the problems if you work in these types of organizations, and that's really powerful. It's the thing that keeps drawing me back. I'm back supporting the VA again through some contracts in my business.

+ +

But it's funny, like, I was working for another agency. I was over working at DHS on an asylum project. And a friend of mine kept telling people to tell me, "Man, veterans need you. If only there was another one of you to help us over here, that would be great." And eventually, it led to me being like, well, veterans need me. I'm going to go back to the VA. And that was my second tour at USDS at the Department of Veteran Affairs. And now I'm back there again.

+ +

So, it's a very impactful place to work. There's tons of value you can provide to veterans. And, to me, it's the kind of work that keeps bringing me back. I didn't realize just how much I was a, like, impact junkie until I joined USDS, and then it really came to a head. I cannot believe how much work I've gotten to be a part of that has affected and supported those who get benefits and services from the federal government.

+ +

VICTORIA: [inaudible 33:47] impact junkie. That's funny. But yeah, no, thank you for sharing that. That's really interesting. Let me see if you could go back in time to when you first started in this journey; if you could give yourself any advice, what would you say?

+ +

ROBBIE: Yeah, I think I spent so much time being nervous about not having my degree that I was worried it was going to hinder me forever. And it's pretty amazing the career I've been able to thread together, right? Like, you know, I've hit on a few of them already.

+ +

But, like, I started with a small web hosting company, and then New York State in the Department of Social Services, then New York City in the Human Resources Administration, Sony Music, Zagat Survey, Google, Johnson & Johnson, IDT telecommunications, Phase2 technologies, where I got to work on an awful lot of problems in lots of awesome places like NBA.com, and Major League Soccer, and Bassmaster. And then, the United States Digital Service where I got to work on things supporting the Department of Veterans Affairs and the Department of Homeland Security over at ADA.gov in DOJ. I helped them out. And I worked over at USDA helping get Farmers.gov off the ground.

+ +

So, everything on my left leg, tattoo-wise, is something that changed my life from my perspective. And I have a Drupal tattoo on the back of my leg. I have a DrupalCon. So, anytime somebody said "Drupal" anywhere near a USDS person, I would magically appear because they would just be like, "Oh, Robbie has that Drupal tattoo." So, I got to work on a lot of dot govs that eventually landed or were being built in Drupal. So, I got to support a lot of work. And it meant that I got to, like, float around in government and do a lot of things that others didn't get to do.

+ +

When CISA stood up, which is the office of security inside of DHS, it's one of the newest sub-communities or subcomponents, they built DHS SchoolSafety.gov, which is a cross-MOU'd site. And I got to sit in and help at the beginning of that because of my Drupal background. But it was really fun to be the person who helped them work with the vendors and make sure that they understood what they were trying to accomplish and be a sort of voice of reason in the room.

+ +

So, I did all of that work, and then after that, I went and worked at Pluribus Digital, where I got a chance to work side by side with you. And then, that led to other things, like, I was able to apply and become the director of Digital Services and software engineering for my local county. So, I worked for Prince William County, where I bought a house during the pandemic. And then, after that contract ended, I had already started my own business. So, that's led to me having multiple individual contracts with companies and so many people. I've gotten to work on so many different things. And I feel very lucky.

+ +

If I could go back and tell myself one thing, it's just, take a breath. Everything's going to be okay. And focus on the things that matter. Focus on the things that are going to help you. Focus on community. Focus on delivering value. Everything else will work itself out. You know, I joke all the time that I'm really good at providing impact. If you can measure my life in impact and value, I would be a very rich man. If you can measure it in money, I'm doing all right, but I'm never going to be yacht Robbie, you know, but I'm going to do okay.

+ +

VICTORIA: Oh my god, yacht Robbie. That's great. So, just to recap, everything's going to be okay. You never know where it's going to take you. And don't be limited by the things that you think, you know, make you not enough. Like, there's a lot of things that you can do out there. I really like that advice.

+ +

ROBBIE: And I think one last piece is, like, community matters, if you are a part of communities and you do it genuinely, how much that will impact your career. I gave a talk from Drupal NYC to the White House and beyond. And I talked through my entire resume and how everything changed when I started doing community engagement. When I went to the Drupal community in New York City and how that led to Sony, and that led to Zagat, which led to me getting acquired by Google, like, these things all cascaded.

+ +

And then, when I moved to the DMV, I was able to join here and continue supporting communities, which allowed me to bring people into the local civic tech community from the local DC tech community. So, so many of the best USDS engineers, and designers, and product people I was able to help influence to come to government were people I met in the community or the communities I helped support. You know, I was an early revivalist of Alexandria Code and Coffee. It was a community that was started and then wavered.

+ +

And then, Sean McBeth reached out to the community and said, "Do we want to help and support getting it off the ground again?" And I immediately said, "Yes." And then, that led to my friends at BLACK CODE COLLECTIVE wanting to create a community where they could feel safe and connected and create a community of their own. And then DC Code & Coffee started. And from there, Baltimore Code & Coffee kicked off.

+ +

And it's just really nice that, like, it doesn't matter where I've been. All these things keep coming back to be a part of community and help support others. And you will be surprised at how much you get back in return. I wouldn't be the person I am today in my community. I wouldn't have my career if it wasn't for the people who started and helped shepherd me when I was starting out. And I feel like I've been trying to do the same for people for a really long time.

+ +

VICTORIA: I love that. That's what I say, too, when people ask me for advice on careers and how to grow. And my biggest piece is always to go out and meet people. And go to your community, like, look and see what's happening. Like, find people you like hanging out with and learning from. And just that should be the majority of your time probably if you're trying to figure out where to go with your career or even just, like, expand as a person sometimes [laughs].

+ +

Robbie, I was going to ask; you mentioned that you had bought a house in Virginia. One of my other warmup questions was going to be, what's your favorite thing to put on the grill?

+ +

ROBBIE: My house in Virginia definitely gets a lot of use, especially in the spring and the fall. I'm a big fan of team no extreme when it comes to temperature. But during those time periods, my grill is often fired up. My favorite is probably to make skirt steak on the grill. I'm a huge fan of tacos, especially made out of skirt steak. I'm in all day. That's one of my favorites.

+ +

I also love to smoke. I have a smoker because I'm a caricature-esque suburban dude. I'm going to live into all of the possible things I could have. But I've had a smoker for a long time, and I love making sort of poor man's burnt ends. It's one of my favorite things to make. But you got to have some time. That's the kind of thing that takes, you know, 14 hours or 16 hours, but it's really fun to take advantage of it.

+ +

A quick thing I love to make is actually smoked salmon. It takes longer to brine it than it usually does to smoke it. But it is one of the nicest things I've made on my smoker, you know, fresh pesto on a piece of salmon is pretty awesome, or everything bagel. Everything with the bagel seasoning is a pretty fun way to smoke some salmon.

+ +

VICTORIA: Wow, that sounds so good. I'm going to have to stop in next time I'm in Virginia and get some [laughs] and hang out. Do you have any questions for me?

+ +

ROBBIE: I'm excited to see where you've gone and how you've gotten here. I think this is such a cool job for you. Knowing who you are as a person and seeing you land in a company like this is really exciting. And I think you getting to be a part of this podcast, which we were joking about earlier, is I've been listening to probably since it started. I've been a big fan for a long time. So, it's cool to be here on this podcast. But it's also cool that my friend is a part of this and gets to be a part of this legacy.

+ +

I'm really excited to see where you go over time. I know my career has been changing, right? I worked in government. Before that, I did all kinds of other stuff. Nowadays I have my own business where I often joke I have sort of, like, three things I offer, which is, like, consigliere services. Wouldn't it be nice to have a Robbie on your executive team without having to pay them an executive salary?

+ +

You know, another one is like, you know, strategy and mentoring, but these are all things I know you do also, which I think is cool. But I've been working on contracts where I support companies trying to figure out how they modernize, or how their CTO can be more hands-off keyboard, or how their new director of business development can be more of a technical leader and taking on their first direct reports. So, I just enjoy all those aspects, and I just think it's something that I've watched you do in the company where we worked together.

+ +

And it's always fun to see what you're working on and getting a chance to catch up with you. I feel like you're one of those people that does a really great job of staying connected. Every once in a while, I'll get a random text message like, "Hey, how you doing?" It always makes me smile. I'm like, Victoria is a really good connector, and I feel like I am, but you're even better at it on the being proactive side. That's how this all came about, right? We caught up, and you were like, "Why don't you come on the podcast?" So, that's really exciting.

+ +

VICTORIA: Well, thank you, Robbie. Yeah, I think that's one of the great things about community is you meet people. You're like, "Oh, you're really cool. And you're doing cool stuff all the time. Like, how can I support you in your journey [laughs]? Like, what's up?"

+ +

Yeah, for me, it was hard to actually leave DC. I didn't, you know, really think about the impact of leaving behind my tech community, like, that network of people. It was pretty emotional for me, actually, especially when we finally, like, stopped doing the digital version [laughs]. And I, like, kind of gave up managing it from California, which was kind of funny anyways [laughs]. Yeah, so no, I'm grateful that we stayed in touch and that you made time to be here with us today. Is there anything else that you would like to promote?

+ +

ROBBIE: You know, just to remind you, you've done a great job of transitioning into where you are today, but anybody can do that, right? Like, before I moved to the DC area, I was in New York, and I was helping to organize JavaScript events. And I started looking at the DC area before I moved down here. And I found the DC Tech Community. And I found the Node School DC GitHub organization and reached out to the person who had ownership of it and said I wanted to help and support.

+ +

I looked at this the other day. I think I moved on May 8th, and then, like, May 11th, when I walked in the door, somebody was like, "Are you new?" And I was like, "Yeah, I just moved here." And they were like, "Oh, from where?" And I was like, "New York." And they were like, "Are you that guy who's been bugging Josh about running Node school events?" I was like, "Yeah." And like, they were planning an unconference at the end of the month. And they were like, "Would you like to run a Node school at that unconference?" Like, 27 days later.

+ +

So, it was amazing that, like, I immediately, like, fell from the New York Community where I was super connected, but I went out of my way to try to, like, see what the community looked like before I got there. And I was lucky enough to find the right people, and immediately I joked...I think I wrote a blog post that said like, "I found my new friends. By, like, going from one community to another, gave a person who was in his 40s a chance to meet new people very quickly." And it was pretty amazing, and I felt very lucky. But I did spend a little bit of energy and capital to try to figure it out because I knew it was going to be important to me.

+ +

So, I think you've done a really good job. You've helped launch and relaunch things that were going on in San Diego and becoming a part of this connection to more people. I think you and I have a very similar spirit, which is like, let's find a way to connect with humans, and we do it pretty effectively.

+ +

VICTORIA: Well, thank you. That really boosts my confidence, Robbie [laughs]. Sometimes, you show up to an event you've never been to before by yourself, and it's like a deer in headlights kind of moment. Like, oh God, what have I done [laughs]?

+ +

ROBBIE: Oh, and the last thing I need to mention is I also have a podcast. I have my podcast about film. It's called Geek on Film. I used to record it with my friend, Jon. He's a little busy right now. But I used to pitch it as a conversation show about the current films that were going on. Now, it's one lone geek's ramblings about what he just saw.

+ +

It's a great podcast for me because it gives me an opportunity to think a little more critically about film, which is one of the things that I probably have almost enough credits to get a minor in. But I absolutely love cinema and film in general. And it's given me an opportunity to connect with a lot more people about this subject and also to scratch the itch of me being able to create something around a community and around a thing I really love.

+ +

VICTORIA: That's super cool. Yeah. You're top of mind because I also like films. I'm like, what's Robbie up to? Like, what's the recommendations, you know [laughs]? Do you have a top film recommendation from the Oscars? Is that too big of a question?

+ +

ROBBIE: So, the one I will say that didn't get enough spotlight shined on it was Nimona. So, I'm a huge fan of the Spider-Man movies. I think Spider-Man Into the Spider-Verse and Across the Spider-Verse are both masterpieces. But Nimona is an animated film that was picked up by Netflix, and it is amazing.

+ +

I don't know that I laughed or cried or was more moved by a film last year. And I don't know that it gets enough credit for what it was. But it did get nominated for best-animated film, but I don't know that enough people paid attention to it. Like it may have gotten lost in the algorithm. So, if you get a chance, check out Nimona. It's one of those beautiful, little gems that, if you travel down its story, there's all these twists and turns.

+ +

It was based on a webcomic that became a graphic novel. One of the production companies picked it up, and it wasn't going to see the light of day. And then, Netflix bought its distribution rights. There's going to be a great documentary someday about, like, Inside Nimona. But I think the movie itself is really charming and moving, and I was really impressed with it. So, that was the one that got me, like, just before the Oscars this year, where I was like, this is the little animated movie that could, in my opinion. It's so charming.

+ +

VICTORIA: I will definitely have to check that out. Thank you for giving us that recommendation.

+ +

ROBBIE: Totally.

+ +

VICTORIA: Final question. I just wanted to see if you had anything to share about being an advisory board member for Gray and for Hutch Studio. Could you tell us a little bit more about that?

+ +

ROBBIE: Yeah. So, Gray Digital was founded by a friend of mine. We met through United States Digital Service. And his organization...I had been supporting him for a while and just being behind the scenes, talking to him and talking through business-related issues. And it was really nice. He offered to make me an official advisory board member. It was a great acknowledgment, and I really felt moved. There's some great people that are supporting him and have supported him. They've done really great work. Gray is out there delivering digital services in this space. And I think I was really lucky to be a part of it and to support my friend, Randall.

+ +

Hutch is different. Hutch is an organization that's kind of like if you think about it, it almost is a way to support entrepreneurs of color who are trying to make their way into the digital service delivery space. Being an advisory board member there has been really interesting because it's shaping how Hutch provides services and what their approach is to how to support these companies.

+ +

But over the last year, I've convinced the person who's running it, Stephanie, with a couple of other people, to open the door up or crack the door so we could talk directly and support the individual companies. So, it's been really great to be a Hutch advisory member to help shape how Hutch is approaching things.

+ +

But I've also been a part of, like, many interview processes. I've reviewed a lot of, like, [inaudible 48:01] who want to join the organization. And I've also created personal relationships with many of the people who are part of Hutch. And, you know, like, you know me personally, so you know I run a Day of the Dead party. We'll just party at my house every year.

+ +

I have a huge amount of affection for Mexican culture and, in general, the approach of how to remember people who are a part of your life. So, this is, like, the perfect way for me to bring people together at my house is to say, like, "Hey, my dad was awesome. What about your family? Who are your people?" What's really nice is that has given me an opportunity to host people at my house.

+ +

And I've had Hutch company owners at my house the last couple of years and the person who runs Hutch. So, it's a really great community that I look at that is trying to shape the next emergent companies that are helping deliver digital services across the government. And it's really fun to be early on in their career and help them grow.

+ +

Again, it seems silly, but it's the thing I care a lot about. How do I connect with people and provide the most value that I can? And this is a way I can provide that value to companies that may also go off and provide that value. It's a little bit of an amplifier. So, I'm a huge fan of what we've been able to accomplish and being a part of it in any way, shape, or form.

+ +

VICTORIA: Well, I think that's a really beautiful way to wrap it up.

+ +

ROBBIE: Really glad to catch up with you and be a part of this amazing podcast.

+ +

VICTORIA: Yeah, so much fun. Thank you again so much. It was great to be here with you today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on thoughtbotsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Victoria Guido hosts Robbie Holmes, the founder and CEO of Holmes Consulting Group. The conversation kicks off with Robbie recounting his initial foray into the tech world at a small web hosting company named A1 Terabit.net, chosen for its alphabetical advantage in the white pages. This job was a stepping stone to a more significant role at Unisys, working for the state of New York's Department of Social Services, where Robbie inadvertently ventured into civic tech and public interest technology.

+ +

Robbie shares his career progression from supporting welfare systems in New York to becoming a technological liaison between the city and state, leading to a deeper involvement in open-source solutions. His journey through tech spaces includes developing websites, diving into the Drupal community, and eventually establishing his consulting business. Robbie emphasizes the serendipitous nature of his career path, influenced significantly by community involvement and networking rather than a planned trajectory.

+ +

Additionally, Robbie gives insights on the impact of technology in public services and his stint with the U.S. Digital Service (USDS), where he contributed to significant projects like vets.gov. Robbie promotes the value of community engagement in shaping one's career, stressing how connections and being in the right place at the right time can lead to unexpected opportunities and career pivots.

+ + + +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Robbie Holmes, Founder and CEO of Holmes Consulting Group. Robbie, thank you for joining me.

+ +

ROBBIE: I'm so happy to be here. It's great to talk to you, Victoria.

+ +

VICTORIA: Yes. I have known you for a long time now, but I don't know everything about you. So, I thought I would start with the question: What was your first job that you ever had?

+ +

ROBBIE: My first technical job, I ended up working for an internet web hosting company called A1 Terabit.net. And note the A1 because it came first in the white pages. It was a really small web hosting company run by a man named [SP] Maxim Avrutsky. I worked there for about six months before I submitted my resume to an online job forum. That's how old I am. And it ended up in the hands of Unisys, where I eventually worked for the state of New York.

+ +

VICTORIA: Wow [laughs]. So, what a journey that you've been on to get from starting there, and what a marketing ploy back in the day with the white pages. So, tell me a little bit more about how you went from that first job to where you are today with having your own business in consulting.

+ +

ROBBIE: Yeah, I wasn't even aware that I was jumping into the sort of civic tech space and public interest technology because the job I ended up with was working for New York State in the Department of Social Services. And welfare is federally funded and distributed to states and then states to localities. And New York City and New York State have a weird parasymbiotic relationship because over 50% of the welfare in New York State goes to the five boroughs in New York City. So, so much of my job was supporting the welfare system within the city, which was run by the human resources administration.

+ +

So, that just led to this cascade of me, like, getting invested in supporting that, and then eventually jumping over to the other side where I worked for the City of New York. And at that point, I ended up becoming sort of a technology project manager and almost a tech liaison between the city and state. And I was out in the welfare centers, helping get the job centers up to a new application called the Paperless Office System, which was a client-server app that was a wrapper around welfare.

+ +

All of that ended up leading to me finally making it to the network operation center for the City of New York, where I started replacing expensive solutions like HP OpenView with open-source solutions like Nagios and another open-source solution that provided an interface. And it really opened my eyes to the idea of open source. And I had really paid attention to a lot of open-source operating systems. So, I was kind of just a general tech nerd.

+ +

And eventually, I started building websites, and that led me to the Drupal community in New York City, which was sort of this cascade that led me to communities. And I think that's sort of a through line for my entire career is I don't really think I ever had a plan. I think my entire career has been this sort of a lucky happenstance of being prepared when an opportunity arose and sometimes being in the right place because of my connections and community.

+ +

VICTORIA: That's interesting about being involved with the people around you and seeing what problems are out there to solve and letting that lead you to where your interests lie. And then, following that, naturally led you to, like, this really long career and these really interesting, big projects and problems that you get to solve.

+ +

ROBBIE: Yeah. And I think one interesting aspect is like, I feel I spent a lot of time worried about what I was going to do and where I was going to do it. I don't have a bachelor's degree. I don't have an advanced degree. I have a high school diploma and a couple of years in college. Well, 137 credits, not the right 125 or 124 to have a bachelor's degree. I have enough credits for a couple of minors though, definitely Greek art history, I think mathematics, maybe one more. I just never got it together and actually got my degree. But that was so interesting because it was limiting to what jobs I could find.

+ +

So, I was in the tech space as an IT person and specifically doing networking. So, I was running the network operation center. I helped, like, create a whole process for how we track tickets, and how we created tickets, and how things were moved along. And, in the process, I started building websites for family and friends.

+ +

And I built a website for our network operation center, so that way we could have photos to go with our diagrams of the network. So that way, when we were troubleshooting remotely, we could actually pull up images and say, "The cable that's in port six goes off to the router. I think that port is dead. Can we move it to the port two to its right, and I'll activate it?" And that made a really interesting solution for something we weren't even aware we had, which was lack of visibility. So many of the people in the fields were newer or were trying to figure it out. And some of us had really deep knowledge of what was going on in those network rooms and hubs.

+ +

It led me to this solution of like, well, why don't we just start documenting it and making it easier for us to help when they're in the field? That led me to, like, the Drupal community because I started building sites in the Drupal CMS. And I went to, like, my first Drupal meetup in 2007, and there was, like, five of us around the table. That led to eventually me working for Sony Music and all these other things.

+ +

But the year before I found my way to the Drupal community, I probably sent out, like, 400 resumes for jobs in the tech space, didn't really get any callbacks. And then, I met the community, and I started attending events, and then eventually, I started organizing events. And then, Sony I interviewed and talked to them a couple of times. And then, a friend of mine became the boss. And she contacted me and was like, "Hey, are you in the market?" And I was like, "I don't know. Why? What's up?" And she's like, "I became Doug." And I was like, "What?" And she was like, "I'm now replacing Doug at Sony. I'm running the team." And I was like, "Yeah, I'm happy to talk."

+ +

And that was the big transition in my career from IT to sort of development and to delivery, right? Like, when it comes right down to it, is I became the manager of interactive media at Sony Music, which was really a job I landed because I was connected to the community, and running events, and getting to know everyone.

+ +

VICTORIA: Yeah. And I think it's really cool that you had this exposure early on to what you called civic tech, which we'll get into a little bit, and then you went from the community into a commercial technology space and really getting into engineering with Drupal.

+ +

ROBBIE: Yeah, it was an interesting transition because what they needed at Sony was sort of somebody who could ride the line between systems engineer, database administrator, and Drupal engineer, and also probably pre-DevOps DevOps person. So, I was responsible for all deployments and all tickets that came in. I was sort of both the technical arm of the help desk. When I joined, there was 24 websites on the Drupal platform, and when I left, there was over 200. And we upgraded it from Drupal 5 to Drupal 6 to Drupal 7 while I was there. So, I was heavily involved in all of those updates, and all those upgrades, and all of the deployments of all the new themes, and all the changes to all these sites.

+ +

So, what was great was they, I believe, if I understand it correctly, they actually created a role for me out of, like, two or three jobs because they needed a me, and they didn't have a role that existed. So, all of a sudden, they made a manager of interactive media role. And I was able to work there for two years, sort of being what I jokingly say, like, a digital janitor. I used to say that I had, like, an eight-bit key ring in a push broom. And I was always mad at your kids for trying to break my stuff.

+ +

VICTORIA: [laughs] That's so good. A digital service janitor [laughs]? The connection for me between that and where I met you in the U.S. digital service space [laughs] I feel like there's a lot of parallels between that and where your career evolved later on in life.

+ +

ROBBIE: Yeah. What's amazing is I did all this early work in my career in civic tech and didn't realize it was civic tech at the time. I just realized what I was doing was providing this huge impact and was value. You know, I spent a couple of years in the welfare centers, and I used to say all the time that the two hardest jobs in the welfare center are the person applying for welfare and the person deciding whether or not that person gets welfare. So, being a technologist and trying to help make that as simple as possible or easier and smooth the edges off of that process was really important.

+ +

And it really taught me how important technology is to delivering service. And I really never thought about it before. And then, when I was working for Phase2 technologies, I was a director of Digital Services. And I read in a blog post, I believe that was written by Mikey Dickerson, who was the original administrator for USDS, and he talked about HealthCare.gov. And he walked in the door, and he said, "How do you know HealthCare.gov is down?" And I think there was some allusion to the fact that we were like, we turn on the television and if they're yelling at us, we know it's down. And Mikey was like, "We know how to monitor things."

+ +

So, like, if you don't know Mikey Dickerson, he's the person who sort of created the web application hierarchy of needs in Google. He was an SRE. And his pyramid, like Maslow's hierarchy of needs, was all over Google when I was there. I was so impressed with the idea that, like, we aren't talking about how do we solve this problem? We're talking about knowing when there's a problem. And then, if we know there's a problem, we can put some messaging around that. We can say, like, "We're aware," right? Like if the president calls the secretary, the secretary can say, "We know it's down. We're working on it," which is building up political capital.

+ +

It's a really amazing process that I kept reading this blog post, and I was like, God, that's how I would approach it. And then, I was like, wow, I wonder if I could use my skills to help America, and very shortly submitted an application and was like, well, we'll see what happens. And about six months later, I walked in the door at the VA and was the eighth employee of the Digital Service team at the VA. That was a franchise team of the USDS model.

+ +

VICTORIA: And can you say a little bit more about what is the U.S. Digital Service and expand upon your early experience there?

+ +

ROBBIE: Yeah. So, the United States Digital Service was created after HealthCare.gov had its issues. Todd Park had convinced President Obama to reach out to get support from the private industry. And the few of the people who were there, Todd convinced to stick around and start creating a team that could support if there was this kind of issue in the future. I believe the team that was there on the ground was Mikey Dickerson, Erie Meyer, Haley Van Dyck, and Todd. And there was a few other people who came back or were very close at the beginning, including the current administrator of USDS. She has been around a long time and really helped with HealthCare.gov. It's amazing that Mina is back in government. We're very lucky to have her.

+ +

But what came out of that was what if we were able to stand up a team that was here in case agencies needed support or could vet solutions before these types of problems could exist? So, USDS was what they called the startup inside the White House that was created during the 2014 administration of President Obama. The team started that year, and I joined in May of 2016. So, I would be, like, sort of the beginning of the second team of the VA U.S. Digital Service team.

+ +

So, USDS supported this idea of tours of duty, where you're a schedule A employee, which meant you were a full-time government employee, but you were term-limited. You could do up to two years of duty and work, and then you could theoretically stick around and do two more years. That was how these roles were envisioned. I think there's lots of reasons why that was the case. But what's nice is it meant that you would come in with fresh eyes and would never become part of the entrenched IT ecosystem.

+ +

There are people that transition from USDS into government, and I think that's a huge value prop nowadays. It's something that I don't know they were thinking about when the original United States Digital Service was stood up, but it was hugely impactful. Like, I was part of the team at the VA that helped digitize the first form on vets.gov and all the work that was done. When the VA team started, there was a team that was helping with veteran benefits, and they worked on the appeals process for veteran benefits. And I joined. And there was a team that was...eventually, it became dubbed the veteran-facing tools team.

+ +

And we worked on vets.gov, which was a new front door to expose and let veterans interact with the VA digitally. And over time, all the work that went into the tools and the solutions that were built there, everything was user-researched. And all of that work eventually got brought into VA.gov in what they called a brand merger. So, we took, like, the sixth most trafficked front door of the VA and took all the modern solutioning that that was and brought it into VA.gov, the main front door. So, all of a sudden, there was an identity, a login provided on VA.gov for the first time. So big, impactful work that many people were a part of and is still ongoing today.

+ +

Surprisingly, so much of this work has now fallen under OCTO, which is the Office of the CTO in the VA. And the CTO is Charles Worthington, who was a USDSer who's the epitome of a person who goes where the work is. Charles was a Presidential Innovation Fellow who helped out in the times of HealthCare.gov and, joined USDS and did anything and everything that was necessary. He interviewed engineers. He was a product person. Charles is one of the most unique technologists and civic tech people I've ever met in my life.

+ +

But Charles, at the end of the Obama administration and in this transition, realized that the VA was in need of someone to fill the CTO role. So, he came over to become the interim CTO because one of the values of USDS is to go where the work is. And he realized, with the transition, that Marina Nitze, who was the CTO who was transitioning out, there was going to be a need for continuity. So, he came in to provide that continuity and eventually became the full-time CTO and has been there ever since.

+ +

So, he has helped shape the vision of what the VA is working towards digitally and is now...he was just named the Chief AI Officer for the agency. Charles is a great person. He has successfully, you know, shepherded the work that was being done early by some of us into what is now becoming a sort of enterprise-wide solution, and it's really impressive.

+ +

VICTORIA: I appreciate you sharing that. And, you know, I think there's a perception about working for public service or for government, state or federal agencies, that they are bureaucratic, difficult to work with, very slow. And I think that the USDS was a great example of trying to really create a massive change. And there's been this ripple effect of how the government acquires products and services to support public needs, right?

+ +

ROBBIE: Yeah, I would say there's a couple of arms of the government that were sort of modernization approaches, so you have the Presidential Innovation Fellows, which are the equivalent of, like, entrepreneurs and residents in government. And they run out of...I think they're out of the TTS, the Technology Transformation Service over at GSA, which is the General Services Administration. But the PIFs are this really interesting group of people that get a chance to go in and try to dig in and use their entrepreneurial mindset and approach to try to solve problems in government. And a lot of PIFS work in offices.

+ +

Like, Charles' early team when he first became the CTO included a lot of Presidential Innovation Fellows. It was basically like, "Hey, the VA could use some support," and these people were available and were able to be convinced to come and do this work. And then, you have the Presidential Management Fellows, which I think is a little bit more on the administration side. And then, we have 18F and USDS.

+ +

The United States Digital Service is a funded agency with an OMB. And we were created as a way to provide the government with support either by detailing people over or dropping in when there was a problem. And then, 18F is an organization that is named because the offices of GSA and TTS (Technology Transformation Service), where it's housed, are on the corner of 18th Street and F in DC. And 18F is sort of like having a technology or a digital agency for hire within the government. So, they are full-time employees of the government, sort of like USDS, except government agencies can procure the support of that 18F team, just like they would procure the support of your company. And it was a really interesting play.

+ +

They are fully cost-recoupable subcomponent of TTS, which means they have to basically make back all the money that they spend, whereas USDS is different. It's congressionally funded for what it does. But they're all similar sibling organizations that are all trying to change how government works or to bring a more modern idea or parlance into the government. I used to say to people all the time that at USDS, you know, we would set a broken bone say, and then we would come back around and say, like, "Hey, does your arm hurt anymore?" The idea being like, no. Be like, "Cool, cool. Maybe you should go to the gym, and you should eat better." And that would be, like, procurement change. That would be, like, changing for the long term.

+ +

So, all the work I was doing was building political capital so we could do better work in changing how procurement was done and then changing how the government delivered these things. So, what was awesome was, like, we used to have these fights at USDS about whether or not we were a culture change or we were firefighters. And I think the reality is once we're involved, culture changes happen. The bigger question is, are we going to be there for the long haul, or are we only there for a shorter period of time? And I think there are reasons why USDS teams had both plays. And I think it really is just two different plays for the same outcome.

+ +

VICTORIA: Yeah, that makes sense. And to pivot a little bit, I think, you know, our audience, we have clients and listeners who are founders of products that are aimed at making these, like, public service needs, or to give some examples, like, maybe they're trying to track Congressional voting patterns or contact information for different state representatives, and they're trying to navigate this space [laughs]. So, maybe you can give some advice for founders interested in selling their products to government agencies. What can they do to make it more appealing and less painful for themselves?

+ +

ROBBIE: I wouldn't consider myself a procurement expert, but at USDS, the procurement team called themselves the [SP] procurementati.

+ +

And I was a secret member of the procurementati. I often was the engineer they would call to evaluate statements of work or sometimes be on technology evaluation panels. And it was fun to be a part of that. Things that most companies don't realize is government agencies will put out things like request for information or sources sought in the government space. And this is a way for industry to influence how government tries to solve problems.

+ +

If you are trying to go after government work and you're only responding to an RFP, you're probably behind in your influence that you could have on the type of work. So, you'll see if a procurement seems to be, like, specifically focused on an approach, or a technology, or a framework, it's probably because some companies have come through and said, "I think this would probably solve your problem," and they gave examples. So, that's one way to be more connected to what's going on is to follow those types of requests.

+ +

Another is to follow the money. My wife is this amazing woman who helped write The Data Act and get it passed through government. And The Data Act is the Data and Transparency Act. And that led to her heading over to treasury and leading up a team that built USAspending.gov. So, there is a website that tracks every dollar, with some exceptions, of the funding that comes out of Congress every year. And what's great is you can track it down to where it's spent, and how it's spent, and things like that. For education purposes, I think that is a really good thing that business and growth people can focus on is try to see and target where competitors or where solutions that you've looked at have gone in the past. It's just a good set of data for you to take a look at.

+ +

The other piece is if you're creating a solution that is a delivery or a deliverable, like a SaaS solution, in order for something to be utilized in the government, it probably needs to be FedRAMP-approved, which is a process by which security approvals have been given so that government agencies have the green light to utilize your solution. So, there's tons of documentation out there about FedRAMP and the FedRAMP approval process. But that is one of those things that becomes a very big stopping point for product companies that are trying to work in the government.

+ +

The easiest way to work your way through that is to read up on it a bunch, but also find an agency that was probably willing to sponsor you getting FedRAMP approval. Most companies start working with a government agency, get an exemption for them to utilize your product, and then you get to shape what that FedRAMP process looks like. You start applying for it, and then you have to have some sort of person who's helping shepherd it for you internally in the government and accepting any issues that come along in the process. So, I guess FedRAMP approval is one that's a little complicated but would be worth looking into if you were planning on delivering a product in government.

+ +

VICTORIA: Right. And does that apply to state governments as well?

+ +

ROBBIE: So, lots of state-related and city and locality-related governments will actually adopt federal solutions or federal paradigms. So, I think in the state of California, I think FedRAMP as one of the guiding principles for accepting work into the state of California, so it's not consistent. There's not a one-to-one that every state, or every city, or every locality will pull this in. But if you are already approved to be a federal contractor, or a federal business, or a federal product, it's probably going to be easier to make your way into the local spaces also.

+ +

VICTORIA: Right. And as you said, there's plenty of resources, and tools, and everything to help you go along that journey if that's the group you're going for [laughs].

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: So, kind of bringing it back to you, like, you're saying you want those partnerships within the government. You want someone advocating for you or for your product or your service. Drawing that back to what you said earlier about community, like, how do you form a community with this group of people who are in the state, or federal government, or civic tech spaces?

+ +

ROBBIE: Yeah, I think it's an interesting problem because so much of it feels impenetrable from the outside. Most people don't even know where to start. There are organizations out there that are pretty good community connections, an example I would give is ACT-IAC. It is a public-private partnership where people from within the government, experts in their fields, and people in the private industry who are experts in their fields will be together on community boards and engaging in panels. And so, it's a really nice way to start connecting those dots.

+ +

I have no direct affiliation with ACT-IAC. But if they'd like to give me my own account, that would be great. But it is one of those organizations I've seen be successful for people trying to find their way into a community that is a little harder to find.

+ +

I think, also, so much of the community engagement happens at conferences and around...so, like, if you're in the healthcare space, this last month, you've had multiple conferences that I think were really great for people to get to know one another, you know, an example is ViVE. It just happened out in LA, which is a little more on the private sector health space, but still, government agencies were there. I know that the Department of Veterans Affairs had people there and were on panels. And then, HIMSS is another conference that takes place, and that just took place down in Miami. And in Miami, HIMSS happened and a whole bunch of other social community events took place.

+ +

So, I'm close with a thing called the Digital Services Coalition, which is 47 companies that all try to deliver good government based on the Digital Services Playbook that was created by USDS that lives at playbook.cio.gov and the way that they try to accomplish this work. And that organization, while they were in Miami, hosted a happy hour. So, there's a lot of connections that can be made once you start seeing the players and getting to know who's around. So, it's a little bit about trying to find your way to that first event, and I think that will really open up everything for you.

+ +

Within a week or two, I was at an International Women's Day event at MetroStar, which is a really great company that I've gotten a chance to spend some time with. And then, I was at an event for the Digital Services Coalition talking about open source in government. So, there's a lot of stuff out there for you to be a part of that isn't super cost-prohibitive and also doesn't take a lot once you start to open the door. You know, once you peek around that corner and you find some people, there's a lot more to be done.

+ +

VICTORIA: Yeah. And you touched on something at the end there that wants me to bring up some of the advantages you can have being a small business, a minority-owned business, or woman-owned business, or veteran-owned business, so thinking about how you can form those connections, especially if you have one of those socio and economic set-asides that you might want to consider if they're looking to work with the government as well.

+ +

ROBBIE: Yeah. Those socioeconomic set-asides include small businesses, woman-owned small business. I think it's Native and Alaskan 8(a), which is historically underrepresented and service-disabled veteran-owned. So, there are also sub-communities of associations, like there's the Digital WOSB, the digital Women-Owned Small Business alliance that was founded by Jess Morris from Pluribus Digital, and a bunch of other companies in the Digital Services Coalition. I believe she's the president of the Digital WOSB right now.

+ +

That is a sub-community of women-owned small businesses that are trying to connect and create a community that they can support one another. And that's just one example of the type of connection you can make through those types of socioeconomic set-asides. But once you have those official socioeconomic set-asides, it will allow you to get specific contracts engagements in the government that are not allowed or available for others. So, the government procurement process will have some amount of these specific socioeconomic set-asides that need to be hit. Like, 8% of all procurements need to go to this and 10% of all procurements need to go to this.

+ +

So, I think the VA is probably one of the most effective at hitting any of the socioeconomic set-asides, specifically related to service-disabled veteran-owned small businesses. So, if you happen to be a person of color and you found a business and you are female presenting, right? You may have 8(a) woman-owned small business. If you also happen to be a veteran and you're service-disabled, all of those things stack. You don't just get to have one of them. And they can be really effective in helping a business get a leg up and starting out and trying to help even the playing field for those communities.

+ +

VICTORIA: Yeah. What I really appreciated about my experience working with Pluribus Digital, and you, and people who had had that experience in the U.S. Digital Services, that there is this community and desire to help each other out and that you can have access to people who know how to move your product forward, get you the connections that you need to be competitive, and to go after the work. So, I love encouraging people to consider civic tech options. And maybe even say more about just how impactful some of it can be. And what kind of missions are you solving in these spaces?

+ +

ROBBIE: Yeah, I often try to remind people, especially those who are heading towards or considering civic tech, there are very few places in this world that you can work on something that can impact millions of people. Sure, I was lucky enough. I have tons of privilege. I worked at a lot of wacky places that have given me the access to do the type of work that I think is impactful, but very little has the kind of impact.

+ +

Like, when I was interviewed by Marina Nitze as, my last interview when I joined USDS, she sent me an email at the end of it and said like, "Everything was great. I look forward to working with you. And remember, every time you commit code into our GitHub, you'll be helping 8 million veterans." And then, she cc'd Todd Park. And Todd was the CTO of the U.S., and he responded back within a minute. Todd is one of the most busy people. It was amazing to me how fast he responded. But he was like, "Lemme tell you, as somebody who can talk on behalf of our president, our country needs you." And those kinds of things they're hard to comprehend.

+ +

And then, I joined the Digital Service team at the VA. And one of the first things that I got to support was the 10-10EZ. It's the healthcare application for veterans. And before I got there, it was a hosted PDF that we were trying to replace. And the team had been working for months to try to build a new, modern solution. What it was is it was, like, less than six submissions were happening a day because it only worked in Adobe Acrobat, I think it was 6.5 and below, and Internet Explorer 8.5 and below.

+ +

And if you think about the people that could submit utilizing that limited set of technologies, it was slowly becoming homeless veterans who were using library computers that had not been upgraded. So, there was a diminishing amount of value that it was providing. And then, on top of it, it was sort of lying to veterans. If the version of the Adobe Acrobat was out of date, or wrong, or too new, it would tell them to upgrade their browser. So, like, it was effectively not providing any value over time.

+ +

We were able to create a new version of that and that was already well on its way when I joined, but we were able to get it out the door. And it was a React frontend using a Node backend to talk to that SOAP API endpoint. Within the first week, we went from 6 submissions a day to 60 submissions a day. It's a joke, right? We were all 10x developers. We were like, "Look at us. We're killing it."

+ +

But about three years later, Matt Cutts came to a staff meeting of USDS, and he was the second administrator of the USDS. And he brought the cake that had the actual 10-10EZ form on it, and it said, "500,000." And he had checked with the analytics team, and there were over 500,000 submissions of that form, which means there are 500,000 possible veterans that now may or may not have access to healthcare benefits. Those are big problems.

+ +

All of that was done by changing out one form. It opened up the world. It opened up to a group of veterans that no one else was able to do. They would have had to go into a veteran's office, and they would have had to fill it out in paper. And some veterans just don't have the ability to do that, or don't have an address, or don't have a...so, there are so many reasons why having a digital form that worked for veterans was so important. But this one form that we digitized and we helped make modern has been submitted so many times and has helped so many veterans and their families. And that's just one example. That's just one form that we helped digitize.

+ +

But now the team, I mean, I'm back in the VA ecosystem. There's, like, 2,500 people in the general channel in the office of the CTO Slack organization. That's amazing. There's people there that are working all day, every day, trying to solve the same problems that I was trying to solve when I got here. And there's so much work being done to help veterans. But that's just one example, right? Like, at USDS, I know that the digital filing for the free version of your tax form, the IRS e-file Direct, just went live. That was something that USDS had been working on for a very long time behind the scenes. And that's going to impact everybody who submits their taxes.

+ +

These are the kind of problems that you get to work on or the scope of some of the problems if you work in these types of organizations, and that's really powerful. It's the thing that keeps drawing me back. I'm back supporting the VA again through some contracts in my business.

+ +

But it's funny, like, I was working for another agency. I was over working at DHS on an asylum project. And a friend of mine kept telling people to tell me, "Man, veterans need you. If only there was another one of you to help us over here, that would be great." And eventually, it led to me being like, well, veterans need me. I'm going to go back to the VA. And that was my second tour at USDS at the Department of Veteran Affairs. And now I'm back there again.

+ +

So, it's a very impactful place to work. There's tons of value you can provide to veterans. And, to me, it's the kind of work that keeps bringing me back. I didn't realize just how much I was a, like, impact junkie until I joined USDS, and then it really came to a head. I cannot believe how much work I've gotten to be a part of that has affected and supported those who get benefits and services from the federal government.

+ +

VICTORIA: [inaudible 33:47] impact junkie. That's funny. But yeah, no, thank you for sharing that. That's really interesting. Let me see if you could go back in time to when you first started in this journey; if you could give yourself any advice, what would you say?

+ +

ROBBIE: Yeah, I think I spent so much time being nervous about not having my degree that I was worried it was going to hinder me forever. And it's pretty amazing the career I've been able to thread together, right? Like, you know, I've hit on a few of them already.

+ +

But, like, I started with a small web hosting company, and then New York State in the Department of Social Services, then New York City in the Human Resources Administration, Sony Music, Zagat Survey, Google, Johnson & Johnson, IDT telecommunications, Phase2 technologies, where I got to work on an awful lot of problems in lots of awesome places like NBA.com, and Major League Soccer, and Bassmaster. And then, the United States Digital Service where I got to work on things supporting the Department of Veterans Affairs and the Department of Homeland Security over at ADA.gov in DOJ. I helped them out. And I worked over at USDA helping get Farmers.gov off the ground.

+ +

So, everything on my left leg, tattoo-wise, is something that changed my life from my perspective. And I have a Drupal tattoo on the back of my leg. I have a DrupalCon. So, anytime somebody said "Drupal" anywhere near a USDS person, I would magically appear because they would just be like, "Oh, Robbie has that Drupal tattoo." So, I got to work on a lot of dot govs that eventually landed or were being built in Drupal. So, I got to support a lot of work. And it meant that I got to, like, float around in government and do a lot of things that others didn't get to do.

+ +

When CISA stood up, which is the office of security inside of DHS, it's one of the newest sub-communities or subcomponents, they built DHS SchoolSafety.gov, which is a cross-MOU'd site. And I got to sit in and help at the beginning of that because of my Drupal background. But it was really fun to be the person who helped them work with the vendors and make sure that they understood what they were trying to accomplish and be a sort of voice of reason in the room.

+ +

So, I did all of that work, and then after that, I went and worked at Pluribus Digital, where I got a chance to work side by side with you. And then, that led to other things, like, I was able to apply and become the director of Digital Services and software engineering for my local county. So, I worked for Prince William County, where I bought a house during the pandemic. And then, after that contract ended, I had already started my own business. So, that's led to me having multiple individual contracts with companies and so many people. I've gotten to work on so many different things. And I feel very lucky.

+ +

If I could go back and tell myself one thing, it's just, take a breath. Everything's going to be okay. And focus on the things that matter. Focus on the things that are going to help you. Focus on community. Focus on delivering value. Everything else will work itself out. You know, I joke all the time that I'm really good at providing impact. If you can measure my life in impact and value, I would be a very rich man. If you can measure it in money, I'm doing all right, but I'm never going to be yacht Robbie, you know, but I'm going to do okay.

+ +

VICTORIA: Oh my god, yacht Robbie. That's great. So, just to recap, everything's going to be okay. You never know where it's going to take you. And don't be limited by the things that you think, you know, make you not enough. Like, there's a lot of things that you can do out there. I really like that advice.

+ +

ROBBIE: And I think one last piece is, like, community matters, if you are a part of communities and you do it genuinely, how much that will impact your career. I gave a talk from Drupal NYC to the White House and beyond. And I talked through my entire resume and how everything changed when I started doing community engagement. When I went to the Drupal community in New York City and how that led to Sony, and that led to Zagat, which led to me getting acquired by Google, like, these things all cascaded.

+ +

And then, when I moved to the DMV, I was able to join here and continue supporting communities, which allowed me to bring people into the local civic tech community from the local DC tech community. So, so many of the best USDS engineers, and designers, and product people I was able to help influence to come to government were people I met in the community or the communities I helped support. You know, I was an early revivalist of Alexandria Code and Coffee. It was a community that was started and then wavered.

+ +

And then, Sean McBeth reached out to the community and said, "Do we want to help and support getting it off the ground again?" And I immediately said, "Yes." And then, that led to my friends at BLACK CODE COLLECTIVE wanting to create a community where they could feel safe and connected and create a community of their own. And then DC Code & Coffee started. And from there, Baltimore Code & Coffee kicked off.

+ +

And it's just really nice that, like, it doesn't matter where I've been. All these things keep coming back to be a part of community and help support others. And you will be surprised at how much you get back in return. I wouldn't be the person I am today in my community. I wouldn't have my career if it wasn't for the people who started and helped shepherd me when I was starting out. And I feel like I've been trying to do the same for people for a really long time.

+ +

VICTORIA: I love that. That's what I say, too, when people ask me for advice on careers and how to grow. And my biggest piece is always to go out and meet people. And go to your community, like, look and see what's happening. Like, find people you like hanging out with and learning from. And just that should be the majority of your time probably if you're trying to figure out where to go with your career or even just, like, expand as a person sometimes [laughs].

+ +

Robbie, I was going to ask; you mentioned that you had bought a house in Virginia. One of my other warmup questions was going to be, what's your favorite thing to put on the grill?

+ +

ROBBIE: My house in Virginia definitely gets a lot of use, especially in the spring and the fall. I'm a big fan of team no extreme when it comes to temperature. But during those time periods, my grill is often fired up. My favorite is probably to make skirt steak on the grill. I'm a huge fan of tacos, especially made out of skirt steak. I'm in all day. That's one of my favorites.

+ +

I also love to smoke. I have a smoker because I'm a caricature-esque suburban dude. I'm going to live into all of the possible things I could have. But I've had a smoker for a long time, and I love making sort of poor man's burnt ends. It's one of my favorite things to make. But you got to have some time. That's the kind of thing that takes, you know, 14 hours or 16 hours, but it's really fun to take advantage of it.

+ +

A quick thing I love to make is actually smoked salmon. It takes longer to brine it than it usually does to smoke it. But it is one of the nicest things I've made on my smoker, you know, fresh pesto on a piece of salmon is pretty awesome, or everything bagel. Everything with the bagel seasoning is a pretty fun way to smoke some salmon.

+ +

VICTORIA: Wow, that sounds so good. I'm going to have to stop in next time I'm in Virginia and get some [laughs] and hang out. Do you have any questions for me?

+ +

ROBBIE: I'm excited to see where you've gone and how you've gotten here. I think this is such a cool job for you. Knowing who you are as a person and seeing you land in a company like this is really exciting. And I think you getting to be a part of this podcast, which we were joking about earlier, is I've been listening to probably since it started. I've been a big fan for a long time. So, it's cool to be here on this podcast. But it's also cool that my friend is a part of this and gets to be a part of this legacy.

+ +

I'm really excited to see where you go over time. I know my career has been changing, right? I worked in government. Before that, I did all kinds of other stuff. Nowadays I have my own business where I often joke I have sort of, like, three things I offer, which is, like, consigliere services. Wouldn't it be nice to have a Robbie on your executive team without having to pay them an executive salary?

+ +

You know, another one is like, you know, strategy and mentoring, but these are all things I know you do also, which I think is cool. But I've been working on contracts where I support companies trying to figure out how they modernize, or how their CTO can be more hands-off keyboard, or how their new director of business development can be more of a technical leader and taking on their first direct reports. So, I just enjoy all those aspects, and I just think it's something that I've watched you do in the company where we worked together.

+ +

And it's always fun to see what you're working on and getting a chance to catch up with you. I feel like you're one of those people that does a really great job of staying connected. Every once in a while, I'll get a random text message like, "Hey, how you doing?" It always makes me smile. I'm like, Victoria is a really good connector, and I feel like I am, but you're even better at it on the being proactive side. That's how this all came about, right? We caught up, and you were like, "Why don't you come on the podcast?" So, that's really exciting.

+ +

VICTORIA: Well, thank you, Robbie. Yeah, I think that's one of the great things about community is you meet people. You're like, "Oh, you're really cool. And you're doing cool stuff all the time. Like, how can I support you in your journey [laughs]? Like, what's up?"

+ +

Yeah, for me, it was hard to actually leave DC. I didn't, you know, really think about the impact of leaving behind my tech community, like, that network of people. It was pretty emotional for me, actually, especially when we finally, like, stopped doing the digital version [laughs]. And I, like, kind of gave up managing it from California, which was kind of funny anyways [laughs]. Yeah, so no, I'm grateful that we stayed in touch and that you made time to be here with us today. Is there anything else that you would like to promote?

+ +

ROBBIE: You know, just to remind you, you've done a great job of transitioning into where you are today, but anybody can do that, right? Like, before I moved to the DC area, I was in New York, and I was helping to organize JavaScript events. And I started looking at the DC area before I moved down here. And I found the DC Tech Community. And I found the Node School DC GitHub organization and reached out to the person who had ownership of it and said I wanted to help and support.

+ +

I looked at this the other day. I think I moved on May 8th, and then, like, May 11th, when I walked in the door, somebody was like, "Are you new?" And I was like, "Yeah, I just moved here." And they were like, "Oh, from where?" And I was like, "New York." And they were like, "Are you that guy who's been bugging Josh about running Node school events?" I was like, "Yeah." And like, they were planning an unconference at the end of the month. And they were like, "Would you like to run a Node school at that unconference?" Like, 27 days later.

+ +

So, it was amazing that, like, I immediately, like, fell from the New York Community where I was super connected, but I went out of my way to try to, like, see what the community looked like before I got there. And I was lucky enough to find the right people, and immediately I joked...I think I wrote a blog post that said like, "I found my new friends. By, like, going from one community to another, gave a person who was in his 40s a chance to meet new people very quickly." And it was pretty amazing, and I felt very lucky. But I did spend a little bit of energy and capital to try to figure it out because I knew it was going to be important to me.

+ +

So, I think you've done a really good job. You've helped launch and relaunch things that were going on in San Diego and becoming a part of this connection to more people. I think you and I have a very similar spirit, which is like, let's find a way to connect with humans, and we do it pretty effectively.

+ +

VICTORIA: Well, thank you. That really boosts my confidence, Robbie [laughs]. Sometimes, you show up to an event you've never been to before by yourself, and it's like a deer in headlights kind of moment. Like, oh God, what have I done [laughs]?

+ +

ROBBIE: Oh, and the last thing I need to mention is I also have a podcast. I have my podcast about film. It's called Geek on Film. I used to record it with my friend, Jon. He's a little busy right now. But I used to pitch it as a conversation show about the current films that were going on. Now, it's one lone geek's ramblings about what he just saw.

+ +

It's a great podcast for me because it gives me an opportunity to think a little more critically about film, which is one of the things that I probably have almost enough credits to get a minor in. But I absolutely love cinema and film in general. And it's given me an opportunity to connect with a lot more people about this subject and also to scratch the itch of me being able to create something around a community and around a thing I really love.

+ +

VICTORIA: That's super cool. Yeah. You're top of mind because I also like films. I'm like, what's Robbie up to? Like, what's the recommendations, you know [laughs]? Do you have a top film recommendation from the Oscars? Is that too big of a question?

+ +

ROBBIE: So, the one I will say that didn't get enough spotlight shined on it was Nimona. So, I'm a huge fan of the Spider-Man movies. I think Spider-Man Into the Spider-Verse and Across the Spider-Verse are both masterpieces. But Nimona is an animated film that was picked up by Netflix, and it is amazing.

+ +

I don't know that I laughed or cried or was more moved by a film last year. And I don't know that it gets enough credit for what it was. But it did get nominated for best-animated film, but I don't know that enough people paid attention to it. Like it may have gotten lost in the algorithm. So, if you get a chance, check out Nimona. It's one of those beautiful, little gems that, if you travel down its story, there's all these twists and turns.

+ +

It was based on a webcomic that became a graphic novel. One of the production companies picked it up, and it wasn't going to see the light of day. And then, Netflix bought its distribution rights. There's going to be a great documentary someday about, like, Inside Nimona. But I think the movie itself is really charming and moving, and I was really impressed with it. So, that was the one that got me, like, just before the Oscars this year, where I was like, this is the little animated movie that could, in my opinion. It's so charming.

+ +

VICTORIA: I will definitely have to check that out. Thank you for giving us that recommendation.

+ +

ROBBIE: Totally.

+ +

VICTORIA: Final question. I just wanted to see if you had anything to share about being an advisory board member for Gray and for Hutch Studio. Could you tell us a little bit more about that?

+ +

ROBBIE: Yeah. So, Gray Digital was founded by a friend of mine. We met through United States Digital Service. And his organization...I had been supporting him for a while and just being behind the scenes, talking to him and talking through business-related issues. And it was really nice. He offered to make me an official advisory board member. It was a great acknowledgment, and I really felt moved. There's some great people that are supporting him and have supported him. They've done really great work. Gray is out there delivering digital services in this space. And I think I was really lucky to be a part of it and to support my friend, Randall.

+ +

Hutch is different. Hutch is an organization that's kind of like if you think about it, it almost is a way to support entrepreneurs of color who are trying to make their way into the digital service delivery space. Being an advisory board member there has been really interesting because it's shaping how Hutch provides services and what their approach is to how to support these companies.

+ +

But over the last year, I've convinced the person who's running it, Stephanie, with a couple of other people, to open the door up or crack the door so we could talk directly and support the individual companies. So, it's been really great to be a Hutch advisory member to help shape how Hutch is approaching things.

+ +

But I've also been a part of, like, many interview processes. I've reviewed a lot of, like, [inaudible 48:01] who want to join the organization. And I've also created personal relationships with many of the people who are part of Hutch. And, you know, like, you know me personally, so you know I run a Day of the Dead party. We'll just party at my house every year.

+ +

I have a huge amount of affection for Mexican culture and, in general, the approach of how to remember people who are a part of your life. So, this is, like, the perfect way for me to bring people together at my house is to say, like, "Hey, my dad was awesome. What about your family? Who are your people?" What's really nice is that has given me an opportunity to host people at my house.

+ +

And I've had Hutch company owners at my house the last couple of years and the person who runs Hutch. So, it's a really great community that I look at that is trying to shape the next emergent companies that are helping deliver digital services across the government. And it's really fun to be early on in their career and help them grow.

+ +

Again, it seems silly, but it's the thing I care a lot about. How do I connect with people and provide the most value that I can? And this is a way I can provide that value to companies that may also go off and provide that value. It's a little bit of an amplifier. So, I'm a huge fan of what we've been able to accomplish and being a part of it in any way, shape, or form.

+ +

VICTORIA: Well, I think that's a really beautiful way to wrap it up.

+ +

ROBBIE: Really glad to catch up with you and be a part of this amazing podcast.

+ +

VICTORIA: Yeah, so much fun. Thank you again so much. It was great to be here with you today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on thoughtbotsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+qMczszvl + + ]]> + + Victoria Guido + + + 524: From Personal Loss to Pioneering Pediatric Health + https://podcast.thoughtbot.com/524 + 0bf0cb3d-79d5-496e-97b1-b4cdd4188bdc + Thu, 09 May 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Will Larry and Victoria Guido are joined by Hans Kullberg, Co-Founder of Pathfinder Health, a startup that integrates technology with pediatric health to provide objective developmental insights. Hans recounts his journey, from a career on Wall Street to the impactful work at Pathfinder Health, spurred by the tragic loss of his daughter, which motivated him to improve developmental diagnostics. He discusses how Pathfinder Health leverages machine learning and video analysis to enhance pediatric care, aiming for earlier and more accurate interventions by merging detailed developmental data into health records. + 36:44 + no + + + Hosts Will Larry and Victoria Guido are joined by Hans Kullberg, Co-Founder and Head of Product at Pathfinder Health. Pathfinder Health is an early-stage startup that provides objective insights into children's developmental health to pediatric clinics. Hans shares his journey, starting with his career on Wall Street, moving through various startup experiences, and finally, his pivotal role at Visa, which was significantly shaped by the tragic loss of his daughter, Aviva. This loss inspired him to focus on helping families get timely and accurate developmental diagnoses for their children. +The episode highlights pediatricians' challenges in monitoring developmental health due to time constraints during appointments and the lack of detailed observation that these brief interactions afford. Hans explains how Pathfinder Health aims to address these challenges by enhancing the collaboration between parents and pediatricians through technology, providing detailed tracking and insights into a child's development outside of clinical visits. This includes innovative approaches like using machine learning to analyze video data of children in their natural environments, helping to pinpoint developmental milestones more accurately. +Hans also discusses the broader implications of early and accurate developmental diagnosis by emphasizing the importance of using data to overcome the limitations of current medical practices. By integrating detailed developmental data into health records, Pathfinder Health hopes to transform pediatric care by being able to allow for earlier interventions for its patients. +Pathfinder Health (https://www.pathfinder.health/) +Follow Pathfinder Health on LinkedIn (https://www.linkedin.com/company/pathfinderhealth-inc/), Instagram (https://www.instagram.com/pathfinderhealth/), YouTube (https://www.youtube.com/@pathfinderhealthapp), TikTok (https://www.tiktok.com/@pathfinder.health), X (https://twitter.com/joinpathfinder), or Facebook (https://www.facebook.com/PathfinderHealthInc). +Follow Hans Kullberg on LinkedIn (https://www.linkedin.com/in/hamidah-nalwoga-78143a255/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with me today is Hans Kullberg, Co-Founder and Head of Product at Pathfinder Health, an early-stage pediatric developmental health tech startup focused on bringing objective insights on children's developmental health to pediatric clinics everywhere. Hans, thank you for joining us. +HANS: Thank you, Will. Thank you, Victoria. It's really awesome to be here. +VICTORIA: Great. Well, I met you at the San Diego Founders Hike at probably 7:30 in the morning on a Friday [laughs] a couple of weeks ago. So, tell me just a little bit more about what do you do for fun around San Diego? +HANS: Yeah, I do a lot of fun. First of all, I'm a dad of four kids, so that keeps me busy, and it keeps my fun time relegated to the windows that I can do it. But I love to start morning surf right out here in Mission Beach in San Diego. I love to cook for a lot of people, house parties, and as well as hunger suppers. And then, I love playing saxophone when I can. +VICTORIA: What's your favorite song to play on the saxophone? +HANS: So, I'm messing around with it right now. I'm not great, but I'm learning Happy Birthday right now. +VICTORIA: That's a great song, and you have a lot of birthdays to celebrate, it sounds like, over there. So, good to have that handy. +HANS: Mm-hmm. Yep. +VICTORIA: Well, awesome. Well, why don't you tell us a little bit more about your background and how it led to Pathfinder Health? +HANS: My background is in data science and economics, and started my career actually on Wall Street, really looking at economic data, things like GDP and inflation, and macroeconomic variables like employment nonfarm payrolls. And I really tried to figure out a way to understand how to predict those at a very high degree of accuracy. That kind of led to my very first startup called, EconoCast, which was fairly successful. And that was exited back in 2013. +Then I did a few other things, some startups that were successful, others that were not. But then I really wanted to kind of chop my teeth into product and really learn product from the inside out at a much bigger company. So, I joined the innovation team at Visa. I was working on Visa Acceptance Cloud, which is really kind of a point-of-sale solution in the cloud. So, if you're familiar with Apple Pay and Google Pay, it was pretty much the mirror image of that for receiving payments and accepting payments. And that really helps a lot of long-tail merchants, if you will, kind of in places like India, and Nigeria, Brazil, et cetera, that are traditionally accepting cash payments to be able to accept credit and debit payments. +However, life took a turn. And while I was at Visa, my third child, Aviva, passed away. And there's, you know, a lot of backstory on that side, but she still doesn't have a diagnosis to this day. It was certainly the hardest part of my life and time of my life for my wife, my family. And I took some time off, really embraced the grieving process, but really tried to figure out what I wanted to do next. And really, that centered around a promise that I made to my daughter was to really try to get parents and families the answers that they deserve to really understand their diagnosis. +So, I talked to a lot of different people in the healthcare community, trying to figure out what I wanted to do with my particular background in data science and technology and building products to be able to kind of marry that with getting parents the answers that they need. And so, that's where I really came in contact with my co-founders at Pathfinder Health to really build what we believe is the most advanced way to really help pediatricians and providers understand how children are developing outside the clinic by collaborating, having parents and pediatricians really collaborate to understand the development across social, emotional, language, cognitive, and movement, all of those things that happen that require observation where pediatricians just have very little time. +And we really kind of package that in a way to give them a snapshot of how they're developing relative to the peer group, to really kind of clarify a lot of these gray areas, if you will, and not take that wait-and-see approach, but rather to make that referral or diagnosis or get them on any kind of therapy that they need as soon as possible. And really, that's the diagnosis that this problem. The meta-problem that we're trying to solve is 25% of all children have some type of developmental delay, yet only 3% get diagnosed before the age of 3. And so, that's, you know, something very near and dear to my heart and something I'm working on every single day. That's how I got to where I am. +WILL: Wow. I am so sorry to hear about your daughter. And I'll just be totally honest: that's one of my biggest fears as a dad. So yeah, I am so sorry to hear that about your daughter. What was that situation like? How long ago was it? And kind of not having to answer, like, where are you at with that? +HANS: My daughter was born in January of 2020. Aviva lived for over ten months, and she passed away here in San Diego in November of 2020. I won't get into the background of it, but the short end of it is she never really had a diagnosis. But she had some anomalies that really created a condition called bradycardia, which is slow heart rate, only intermittently. It happened every couple of months. So, it wasn't really even a daily thing. Doctors didn't have any answers for it. We saw teams of specialists and I'm talking about cardiologists, neurologists, mitochondrial specialists, pulmonologists, every single type of specialist under the sun. +But throughout six different hospitalizations and then the autopsy afterwards, they never figured out what the root cause was. And she had some signs that were different, but, you know, we live in this world where data is abundance. Generative AI is huge, right? We have all these tools and everything else, but yet when it comes to medicine, a lot of times we rely on the human knowledge of the physicians that we see. I'm not saying that they did anything wrong because they did the best they could. +But what really upset me was that, you know, we go through this differential diagnosis of A, B, C, D, and this and the other, and they all strike out. You know, what's the backup plan? And that's where, you know, we should be using a lot more data at the big data level to really understand, you know, these anomalies. And maybe someone out there had something similar that she did or maybe a doctor in New York, or Boston, or Atlanta, or Miami somewhere would have known what to do. Unfortunately, that wasn't the case. +And really, that set me off my journey, really trying to understand that problem, in particular. There's a lot of things that kind of stand in the way from real AI being used in medicine. Of course, radiology is one exception. But when it comes down to interoperability of electronic health records as well as HIPAA, and privacy, and all the data silos they're in, Google's tried at this for a while to get to a place where you can have more precise type of data from a diagnostic perspective. Similar to the way that Facebook, and Amazon, and the Googles of the world know precisely how likely you are to click a button, I think medicine should be moving in that form and fashion. And so, yeah, that's really where I came across this journey. +And the grieving process that's a whole 'nother subject as well, but I'm a very big believer in embracing that. Each of us took a year off and really just made sure that we were taking a lot of self-care and healing. And I went to therapy for the first time in my life, did a lot of writing and a lot of other therapeutic activities, including writing children's books. So, I'm a children's book author. And that's kind of what led me to finding out what I wanted to do on a day-in, day-out basis to help parents get the answers they need, knowing that, you know, mom and dad play a very big role in this, those first five years of life which, in my opinion, are the most critical and crucial and also the most precious years of your life. +VICTORIA: You know, I really admire how you took such a painful moment and turned it into, how do I solve this problem for other people and really build community off of that as well? I don't have kids myself, but I have a niece and nephew who's two and four now. And I remember watching my sister-in-law try to keep track of all of the things that are happening for her child in the first year of their life, and it's not easy. And how do you identify if something has gone wrong? And I'm curious, like, what you learned from that process, or if you've learned anything about that process that's shifted your direction with Pathfinder. +HANS: I mean, the biggest takeaway from my own personal experience is knowing that parents can play a very proactive role, an important role in the care for their child. And so, when you look at the pediatric visit, and, Will, you probably can relate to this, you know, for 15 minutes, you know, they're checking your eyes, ears, throat, heart, giving you your vaccines, et cetera. And there's a lot of different things they have to do to check off on their task list. +But yeah, when it comes down to developmental health, we're talking about social, emotional cues, movement, cognitive, and language; it really requires observation. And they have very little time for that. Plus, you know, kids never [inaudible 08:49] themselves. There's well-child visits as well. It sort of leads to a lot of these gray areas. You know, on average, a pediatrician sees about 20 to 24 different kiddos a day, which is quite a heavy burden. They're definitely the most overworked and underpaid specialists across the whole healthcare system. +But when you think about it, you know, what they do after the well-child visits is they give usually mom or dad a two-page handout of "This is..." you know, "Your child is two years old, and here's what you can do." A lot of times those handouts just, you know, get lost, and they're very not personalized. +So, what we're doing we're a team of developmental-behavioral pediatricians, as well as early childhood specialist. We're talking about occupational therapists, physical therapists, child psychologists, and speech therapists. We're really combining all our interdisciplinary skills as well as machine learning experts on our team to be able to give parents the type of knowledge that's packaged in a way, on a parent level, that they really can understand how to track, monitor their child's growth and development. But also, if they're falling behind, or even if they're ahead, be able to enhance their development through daily activities that are tailored and customized to each individual's unique developmental trajectory. +And so, we've come up with what's called developmental biomarkers, similar to what you know as height and weight charts, to really measure and monitor a child's progress versus peers. On the physical side, we're doing that across all of those developmental domains and being able to make those conversations, and insights, and visits with the doctor a lot more comprehensive in scope, including video-based data, where we kind of isolate the milestones. We call it smart detection, really show the parents what those milestones are happening. +Parents know a lot about walking, talking, sitting, rolling over, but there's over 400 milestones that happen in the first five years of life. And so, being able to kind of understand pincer grip, you know, picking up a cheerio or looking when you call their name those are really big milestones that are very significant when it comes to determining where that child stands relative to their peers. So, yeah, that's a little how it works at a high level. +WILL: Yeah. Wow. I want to go back and tell you this just so that...I try to whenever I think of something, especially positive, I just try to tell people. And so, like, your inspiration of how you dealt with your child's passing away and everything...because I think the statistics and what I've heard is most people hit a downward spiral. Most marriages don't make it. So, it's very inspiring to hear that you grieved and you worked through the process. So, I just want you to know that, like, that's super, even for me, that's super inspiring to know that that is even possible in that situation. So, I just want you to know that. +HANS: Yeah. And I'm glad that you brought up that point. You're absolutely correct. I think over 50% of couples do get divorced after a death of a child. And a lot of times, it's not the event itself. Certainly, losing a child is very, very painful. But the cause of that separation is really the differences in the way that each other grieve, you know, the spouses grieve. And that's something that, honestly, you don't learn until you're going through it. +And so, what we did was, just like other things in our life, we were very intentional about it and really sought out as much help and support through books. Books were fantastic, also grieving groups. There's a lot of great different grieving groups out there to really understand that, hey, you're not necessarily alone. Certainly, the pain of losing a child is definitely, in my opinion, the hardest thing that anyone can go through. But in terms of being able to empathize and even commiserate, but even to hear other people's stories, you start to learn, you know, what that journey looks like five years, ten years, 20 years down the road. +But you also, you know, one of the things that I say is there's no right way to grieve at all. You can't tell someone how to grieve. But there is a wrong way to grieve. And I know that sounds like an oxymoron. But the wrong way to grieve is not doing it at all. And that's usually where we saw a lot of people kind of turn to negative addiction, or self-inflicted behaviors, or a lot of other things where they try to bottle it up, put it away, lock it in the closet and not think about it, you know, maybe bury their heads in work or any other kinds of addictions. +That's something we learned very, very early on that we try to be conscientious of and try to really steer clear from. But, again, it's a very individually unique path, and I'm definitely not an expert at all, but have certainly learned, you know, tenfold what I didn't know about grief beforehand. And so, you really don't know grief until you actually go through it. +In terms of being able to kind of parlay that into motivation to help others...and really, for me, that's my North star is really helping others, if that's helping detect diagnosis, or even, you know, just smiling to the person on the street, you know, that's what really gives me a lot of fulfillment. And so, in terms of that motivation, where does that come from, and how do you actually take that grief and transcend that into something productive like that? +The only thing I can actually say to all the parents that are listening out there it's akin to when you hold your firstborn, especially when you become a new parent. And you have that magical feeling where you're holding that small, little infant in your arms. And you have this great burden of responsibility as well. And you start thinking to yourself, man, now it's not just my life that I'm in charge of. I'm in charge of this little human being's life, who you have to do everything for them. +And so, that inspiration to be the better parent or better person that you feel as a new parent is only correlated, I would describe, to actually losing a child where that same feeling is, I would say, magnified times 3. And that's, you know, for me, I know my daughter's looking down on us, and I know that she's behind a lot of things that I'm doing, but I'm certainly inspired in a whole 'nother way apart from being just a parent. +WILL: Yeah, definitely. You said something that really caught my attention. Like, it was around how when you're holding your child, like, you're responsible for your child. I have a background in sports medicine, spent four years doing it. I still have no idea a lot of medical history when it comes to a kid. I feel like majority of the items that you're supposed to be looking for or even thinking about is totally different with a kid. +I don't know how to say this, but, like, the healthcare, the more that I have my kids, I'm seeing that there's different sides of healthcare. So, we moved from North Carolina. Our first pediatrician we loved. Every time we had an appointment, probably spent 30 to 40 minutes just talking us through, hanging out with our kids, asking questions. You know, they always gave us this list beforehand to say, "Hey, look out for these things. When you come in the office, we're going to ask you, 'Have you noticed it, or how are they doing with that?'" +And then, we moved to South Florida, and it's been totally different. Totally different. We had to fire one pediatrician because it wasn't the same care. The pediatrician we're at now is a lot better, but it's nowhere near what North Carolina was. And so, there's a lot of times that we're questioning ourselves. It's like, what does the development of our kid look like? +My oldest he had a tongue tie where he couldn't touch the top of his mouth, and we didn't know how important that was to take care of. We finally got it taken care of, but he is delayed in speech because he couldn't touch the top of his mouth. So, whenever I saw that we were going to have this podcast interview, I was just so excited because this is a huge issue. As a parent of three, this is a huge issue because you just don't know. And even when I didn't have kids, the knowledge that I had of even being a parent, yeah, I didn't know anything [laughs], and it's just learning on the go. So, everything you're doing is just speaking to me, and you are helping people. It's needed out there. So, I am so excited that you're doing it. +HANS: That warms my heart. Thank you, Will, for saying that because I didn't realize that you're actually from North Carolina. I'm from North Carolina myself from a little town called Gastonia. But when it comes to, you know, developmental health, it is the biggest gray area in all of pediatrics. And we know that pediatricians just don't have the time. That's a very big burden. +In addition, when it comes to specialists, we're talking about, you know, autism, for instance. You know, they have to be diagnosed through developmental-behavioral pediatricians or a child psychologist, and there's just a very big dearth of them. There's long waiting lines. It could be 12 to 18 months to actually get in front of them and get that evaluation, and then another 6 to 9 months to actually get therapy. And by that time, there's a lot of time lost, which is absolutely precious when it comes to the child. +90% of your child's brain, actually, develops by the time they're three years old. Another stat that parents actually don't know is that there's centers called Early Intervention Service Centers across the U.S. There's over 4,000. Their specific remit, their mandate is actually to go out and find children in their community, in the region, that do have developmental delay. And, you know, it's a very labor-intensive process to do that. I've actually done it here with my fourth child here in San Diego. +They send out two therapists. They come in, do an evaluation, talk to the parent, see how they're doing, jot down some notes, you know, it's at least an hour of their time, driving included, but it's a very kind of manually intensive process. And what we can do is really be able to preempt that and really give parents the fidelity and advocacy to speak on behalf of their child. And I would say that's the number one thing that our parents say is they thought there was a concern. They knew there was some kind of gray area. +And we know that there's a lot of stigma and denial around delays. What we're trying to do is actually lower that barrier so they have the wherewithal to actually have that conversation with their pediatrician. And simply to ask that question from a clinical-based evidence perspective, you know, that could do wonders, you know. If a kid's not speaking by the time they're two years old, if they're not saying a word, that's a big red flag. And a lot of the de facto status quo, a pediatrician will say, "Well, let's just wait till the next visit because every single child develops uniquely," which they do. But their next visit is at three years old, 12 months later. And that's time that's lost in that process. +Apart from the evaluation, they can actually do at-home interventions. There are a lot of different activities and modules that we have for parents to actually be more proactive in enhancing that child's development along the way. And so, yeah, at the end of the day, we're committed to making sure parents have those tools and knowledge that's necessary. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +VICTORIA: As a head of product, how do you approach the design for the app you're building given just how complex it is? And you said there's 400 milestones in the first 5 years to track. How do you prioritize which one to do first? +[chuckles] +HANS: Yeah, that's a good question. And now I get into the nitty-gritty. But there's certainly been a lot of focus, and it really starts with the users, and so that's both parents as well as pediatricians. And so, personally, I've visited, even in six months, I've visited over 70 different pediatric clinics here in Southern California as well as New York and Washington State, you know, really talking to pediatricians and really understanding what would actually help, you know, make it a lot more useful and helpful for them in their own day to day. +You know, the biggest capacity constraint is really their time crunch. And so, can you get me those answers immediately? And they tell us they don't want to go to some other system. So, we've integrated directly into almost a hundred different EHRs (Electronic Health Records) across the board to the point where parents can actually just search for their pediatrician on our app and then be able to send their data directly to the pediatrician. Because when it comes down to trust, in healthcare, it's all about trust. Parents really trust the pediatrician the most at the end of the day, and so getting them on board and making sure that they're the biggest advocates for our platform will speak a lot more than just having our app in the App Store, which it is. +But in terms of the parent's side, we want them to have a really great and engaging experience where they're getting a lot of joy. We could talk about this concept called burst of joy from watching their child grow and develop. And so, there's a fine line between creating too much anxiety versus giving more information. And when it comes to development [chuckles], there's a very fine line on that. But being able to kind of track those milestones on a continuous basis, not just that point in time, you know, that one time, you know, every three, six months that they're in the doctor's office, but even on a weekly basis, kind of seeing that growth that actually happens organically on a day-to-day basis is a huge part of the parent experience. +Being able to kind of look and see what that is, why it's important, and oh, by the way, if the child's not doing that, here's some activities that you can do to really help them excel and get to the next level, you know, that's the type of thought process. And if you do have concerns, here's resources. We put together these 4,000 early intervention centers, where on the web, you have to go to each individual website. We basically just took all the information and just put it right there in one place where it's just a zip code lookup functionality. +And so, a lot of those types of approaches is really great. I think, in the future, being able to connect directly with therapists and providers might be another step because we know that the gaps in care is really one of the most critical problem. Right now, we're trying to solve that through that parent-led approach. But even reducing that 6 to 9 months down to 1 or 2 weeks, I think, that's actually a possibility. +VICTORIA: I love how you described it as what you're going for is a burst of joy and that you want to focus on having it be a joyful experience for parents. And it should be because I have also seen the anxiety part and how anxiety-inducing it can be when you're trying to keep track of all these different milestones. And, like you said, you have a handout from your doctor, or maybe you're looking up things on TikTok or Instagram [laughs]. How do you work those emotions into your design? Can you say a little bit more about that? +HANS: Yeah. So, for example, after completing an activity...so, we have all these daily activities that you can do. We start the app. We've got inspired from Headspace in terms of what they ask you to do. Here's 2 or 3 things that you can do with your child. We start with an activity, and it takes nothing more than items lying around in your home. +We believe in this concept of serve and return approach when it comes to that parent-child interaction. And so, you have those materials. You have the 10, 15 minutes that you have with your child. You're asking yourself, like, "What can I actually do to really stimulate development?" We want to meet them where they are. So, we have even at bath time, or on the playground, or in a car ride, or while you're doing laundry, sorting socks, right? Any place in time could actually have that really great approach. +And then, after completion of the activity, we have this kind of pop-up that it's almost like an accomplishment, like, we did it as a joint team, as a joint effort, with a little celebration and kind of that approach. And then, also, when you're checking off milestones, and when you check off frequently on our app, there's little hearts that kind of come out of the button to celebrate this little...we call them smilestones, but it's a small part of that celebration that happens day in, day out. +VICTORIA: I'm definitely going to say smilestones to my team next week. That's how we're going to rebrand our milestones as as well. I love it. +HANS: Yeah. I don't think that's copyrighted, so go ahead. Take it away. +WILL: What is your, I'll use that, smilestone for the next six months or, you know, next year? What's in the future? I saw on your website you're incorporating some AI into it. So, can you talk about that and anything else that you have coming up? +HANS: Yeah. So, one of the places where we're really, you know, focusing on is really getting objective about the data. So, we want to take a lot of the subjectivity, a lot of the guesswork, a lot of the recall bias, even misinterpretation of milestones, as well as language barriers of milestones. And so, just really being able to not just have the parent kind of fill out, you know, the checklist, but also, being able to incorporate the videos component as well. And so, being able to upload any kind of video of the child at the dinner table, playing with friends in the playground, playing at home in the living room. Parents have tons of these videos, right? +We're able to kind of spot and detect where those milestones are actually taking place. And so, we can isolate that three to five seconds of, here's where their child's doing the pincer grip, which is basically picking up a cheerio between your forefinger and thumb, and really being able to kind of give that validation and confirmation to the parents so they can actually say, "Oh, wow, my child actually did this new thing that I actually didn't even know about." +But on top of that, being able to turn that into a highlight reel, you know, similar to like SportsCenter highlight reel. Like, you're taking all of those different clips and turn that into maybe a 60-second highlight reel of everything that happened that transpired in between the last visit. So, when you talk about going from, like, a 12-month visit to an 18-month visit, here's all the things, in 60 seconds, that the kid's been doing to give a lot more comprehensive evaluation for their pediatrician to make better decisions at the end of the day. +Again, we are clinical decision support. We're not making the diagnosis ourselves. We leave that to the providers. But what we believe in our ethos is really giving all that information and packaging it up so that those decisions can be much better made at the end of the day. So, that's one use case of AI. +But there's still a human element to it right now, but we want to be able to kind of transpire that to a fully autonomous computer vision, which, when you look at generative AI, understanding videos and being able to detect that when you think about all of the different angles, shapes, lighting, et cetera, it's the, I would say, the last frontier of being able to kind of get data insights out of videos itself. It's very easy to go from having a text prompt and generating a video from it. It's much harder to take a video and spitting back out what we have as milestones. So, that's one part. +And the other is developmental biomarkers which is another...what we think is groundbreaking in the pediatric space. +VICTORIA: Can you explain what developmental biomarker is? +HANS: Yeah. So, it's a concept similar to what we know as the height and weight chart. And when I first became a parent, a lot of times you're speaking with other new parents, and you are, you know, on the playground, right? And they're saying that "Hey, my kid is on the 90th percentile in height or weight," or "Hey, they're 80th percentile on head circumference," because that's literally, like, as a new parent, like, that's the only basis you have other than their sleep habits, which, Will, I know you can probably attest to most parents track a lot. +But similar to that, like, in terms of, you know, how developmental tracking is done right now, the status quo is using developmental screeners. And so, that's, again, point in time, static approach while you're in the well-child visit. But the problem with developmental screeners is it has what's called a low sensitivity and specificity in terms of really over-detecting or over-failing basically one side of the distribution. So, it's typically 40% to 50% of kids would fail a screener when, in reality it should be around 20 to 25. +To really get more granular and very objective about understanding a child's developmental trend, one has to kind of be able to, we believe, understand both the right and the left side of the distribution and being able to understand, hey, is this child actually tracking ahead of the curve or behind the curve relative to everyone else? +And so, we've developed an algorithm. It's fairly complex, but it uses a lot of the underlying data sets that we have to kind of give a much more high-fidelity picture of, hey, your child's in the 60th to 65th percentile. At the end of the day, we want to be able to identify delays. And so, anything below 20% or so, you know, parents should be more informed about that and looking at it on a domain-by-domain specific level. +So, it's very common for a kid to be accelerated on 3 of the four domains, but maybe they're behind on speech. And so, what does the doctor do with that? If they're at 15th percentile in speech, they can then come in the clinic and say, "Hey, I see the screening results, but I also see this Pathfinder report. Let's spend the next 5 to 10 minutes actually seeing how you verbalize and how you're able to speak and express yourself." So, that's really what we're talking about when it comes to developmental biomarkers. +VICTORIA: Gotcha. Okay. Yeah. I think I knew what you were referring to, but I wanted to make sure [laughs], but that makes sense. So, it's like whatever the data that helps the parent identify where there might be an area that some intervention or some more time might need to be taken to help move them forward. +HANS: It is on a longitudinal basis, which, if you're in healthcare, you know longitudinal trend. Really understanding what that looks like is hugely important versus point in time. And so, we're able to see it not just at the sixth month and nine month, but every day in between as well. And we believe, you know, the early results are kind of showing that we're able to even preempt what those potential red flags will look like, or a failed screening result will look like at an earlier rate as well. +VICTORIA: That's really interesting. I'm curious if you have other statistics like that or some results from the first year, almost two years of data that you have now, on how people are interacting with the app. And what kind of outcomes are you getting? +HANS: Yeah, as I said, you know, the biggest outcome is really being able to give parents a really highly objective look at how their children are developing, and so giving them the level of advocacy to speak on the child's behalf with clinical evidence. If you look at our testimonials, that's probably the number one thing. We have different personas for different types of moms. +But there's some moms that are the Nervous Nellies, the ones that are concerned about every single cut, scrape, and bruise. There's also the Inkling Ingrids, the ones that think there might be something there, but they're not necessarily sure. But then there's also the Ambitious Amandas, these types of moms that want to put their kids in every single type of advanced activity, right? Music classes, Legos, et cetera. And then, the Brand New Brendas, the ones that are brand new to parenting and want to know, learn, explore, and track the child's development. +So yeah, there's different things for different types of personas that we have. By and large, it's really giving that information in a very parent-friendly way so it's not overwhelming them with too much anxiety or, you know, going over their heads as a lot of times medical jargon does as well. +VICTORIA: Wow. That's great. Thank you for sharing that. And I wonder, actually, Hans, I wanted to ask you a question about bias and about bias in AI and in health tech. And how do you approach that in Pathfinder and making sure that everyone's getting equitable health incomes and recommendations within the app? +HANS: Yeah, bias and accessibility are two big topics that we think a lot about, you know, first of all, on the underlying data bias, you know, that could present itself. Right now, our app is available on App Store and Play Store. We have over 50,000 parents, you know, still small but growing in about 120 different countries, mainly English-speaking ones, because right now the app is completely in English. That's about to change. We're about to go multilingual, starting with Spanish, which is definitely the biggest request. +But so, when it comes to, like, being able to compare across different groups and subsets, you know, we do believe we have a fairly heterogeneous group. Only about 50% of our users are actually here in the U.S. In terms of the actual milestones themselves, there could be, you know, some differences in cultures. Something like "Eats with a fork" is a milestone that happens, I think, around two or three years old. You know, in cultures like India, for instance, they usually eat with their hands for a lot of time. So, that would be obviously a difference. That milestone wouldn't necessarily apply as much. +But then when you talk about accessibility, one of the things that we screen for in our standard screening that we do have, and I forgot to mention this earlier up front, we almost have, like, a four-legged stool, if you will, in terms of the underlying data that we capture. One is standard screeners because that is status quo. That is reimbursed on the pediatrician's side. And the biggest value prop to pediatricians to adopt our platform is, hey, we can help you get towards 100% developmental screen adherence, which right now it's only about 60 or even less than 50% across the board. So, that's a reimbursable event. So, that's layer 1. +Layer 2 is parent concerns, caption that in a good, valid way, and then continuous milestone tracking. And then, finally, the videos as well. So, certainly, some parents don't submit videos for privacy reasons, which is okay. We still have all of the other 3. So, going back to social determinants of health and health equity, that's one of the things that we screen for as well, knowing that the more vulnerable populations and minorities, lower socioeconomic classes, actually do have a higher prevalence of delays. And so, we want to be able to be accessible to them as much as we can but also, raise those things to the surface when it comes to getting those answers to pediatricians. +There's another big movement happening called Adverse Childhood Experiences screeners (ACEs) that really looks at, you know, how the child's been developing and what their background, their environment actually looks like. So, looking at those questions of, is that child being raised in an environment of neglect, or abuse, or a broken home, or drug addictions in the home? Those can really have an effect, not just on the early part of life, but even later in life when you talk about physical as well as mental well-being. And so, just having that awareness and that insight into how that child's been developing is really important on the background side. +And so, at the end of the day, when we're talking about who actually holds the bag, if you will, in terms of this big gap that we're trying to solve, at the end of the day, it's really the government. If the child does have a delay that doesn't get addressed at an early age, doesn't get, you know, therapy, a lot of times, it leads on to run-on consequences, whether that's mental issues or maybe not being able to be self-sufficient, independent, job seeking, tax-paying, delinquencies. There's a lot of different ramifications from things that happen at a very early age. +That's where we believe in partnership with Medicaid through clinics like Federal Qualified Health Centers that focus on the Medicaid population, which 38% of all kids fall under, those are ideal partners for us. It's a longer, harder slog and a long road. But we believe there's a lot that we can offer at that level as well as more ACO and value-based payer type of model. +VICTORIA: Oh, wonderful. Well, thank you so much, Hans, for coming on and sharing your story with us. Do you have anything that you would like to promote? +HANS: I know we didn't get a chance to speak about it, but the children's book I've written very near and dear to my heart is called Baby Aviva, Orangutan Diva. You can get that out on Amazon, anywhere. But it's A-V-I-V-A. If you're a parent and if you have a kid under the age of five, feel free to check out our app called Pathfinder Health. And Pathfinder is just one word on the App Store and Play Store. But thank you, Will, and thank you, Victoria. +WILL: Thank you. It was great talking to you. And I'm going to go download the app. +HANS: Absolutely. Thanks so much. And I really appreciate it. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +VICTORIA: And you can find me on X or Twitter [laughs] @victori_ousg or on Mastodon @thoughtbotsocial@vguido. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. + AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + pediatric health, developmental diagnosis, Hans Kullberg, Pathfinder Health, machine learning in healthcare, children's health technology, early intervention, pediatric data analysis, grieving process, healthcare innovation, startup culture, child development milestones, pediatric care challenges, collaborative healthcare, technology and medicine + + Hosts Will Larry and Victoria Guido are joined by Hans Kullberg, Co-Founder and Head of Product at Pathfinder Health. Pathfinder Health is an early-stage startup that provides objective insights into children's developmental health to pediatric clinics. Hans shares his journey, starting with his career on Wall Street, moving through various startup experiences, and finally, his pivotal role at Visa, which was significantly shaped by the tragic loss of his daughter, Aviva. This loss inspired him to focus on helping families get timely and accurate developmental diagnoses for their children.

+ +

The episode highlights pediatricians' challenges in monitoring developmental health due to time constraints during appointments and the lack of detailed observation that these brief interactions afford. Hans explains how Pathfinder Health aims to address these challenges by enhancing the collaboration between parents and pediatricians through technology, providing detailed tracking and insights into a child's development outside of clinical visits. This includes innovative approaches like using machine learning to analyze video data of children in their natural environments, helping to pinpoint developmental milestones more accurately.

+ +

Hans also discusses the broader implications of early and accurate developmental diagnosis by emphasizing the importance of using data to overcome the limitations of current medical practices. By integrating detailed developmental data into health records, Pathfinder Health hopes to transform pediatric care by being able to allow for earlier interventions for its patients.

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Hans Kullberg, Co-Founder and Head of Product at Pathfinder Health, an early-stage pediatric developmental health tech startup focused on bringing objective insights on children's developmental health to pediatric clinics everywhere. Hans, thank you for joining us.

+ +

HANS: Thank you, Will. Thank you, Victoria. It's really awesome to be here.

+ +

VICTORIA: Great. Well, I met you at the San Diego Founders Hike at probably 7:30 in the morning on a Friday [laughs] a couple of weeks ago. So, tell me just a little bit more about what do you do for fun around San Diego?

+ +

HANS: Yeah, I do a lot of fun. First of all, I'm a dad of four kids, so that keeps me busy, and it keeps my fun time relegated to the windows that I can do it. But I love to start morning surf right out here in Mission Beach in San Diego. I love to cook for a lot of people, house parties, and as well as hunger suppers. And then, I love playing saxophone when I can.

+ +

VICTORIA: What's your favorite song to play on the saxophone?

+ +

HANS: So, I'm messing around with it right now. I'm not great, but I'm learning Happy Birthday right now.

+ +

VICTORIA: That's a great song, and you have a lot of birthdays to celebrate, it sounds like, over there. So, good to have that handy.

+ +

HANS: Mm-hmm. Yep.

+ +

VICTORIA: Well, awesome. Well, why don't you tell us a little bit more about your background and how it led to Pathfinder Health?

+ +

HANS: My background is in data science and economics, and started my career actually on Wall Street, really looking at economic data, things like GDP and inflation, and macroeconomic variables like employment nonfarm payrolls. And I really tried to figure out a way to understand how to predict those at a very high degree of accuracy. That kind of led to my very first startup called, EconoCast, which was fairly successful. And that was exited back in 2013.

+ +

Then I did a few other things, some startups that were successful, others that were not. But then I really wanted to kind of chop my teeth into product and really learn product from the inside out at a much bigger company. So, I joined the innovation team at Visa. I was working on Visa Acceptance Cloud, which is really kind of a point-of-sale solution in the cloud. So, if you're familiar with Apple Pay and Google Pay, it was pretty much the mirror image of that for receiving payments and accepting payments. And that really helps a lot of long-tail merchants, if you will, kind of in places like India, and Nigeria, Brazil, et cetera, that are traditionally accepting cash payments to be able to accept credit and debit payments.

+ +

However, life took a turn. And while I was at Visa, my third child, Aviva, passed away. And there's, you know, a lot of backstory on that side, but she still doesn't have a diagnosis to this day. It was certainly the hardest part of my life and time of my life for my wife, my family. And I took some time off, really embraced the grieving process, but really tried to figure out what I wanted to do next. And really, that centered around a promise that I made to my daughter was to really try to get parents and families the answers that they deserve to really understand their diagnosis.

+ +

So, I talked to a lot of different people in the healthcare community, trying to figure out what I wanted to do with my particular background in data science and technology and building products to be able to kind of marry that with getting parents the answers that they need. And so, that's where I really came in contact with my co-founders at Pathfinder Health to really build what we believe is the most advanced way to really help pediatricians and providers understand how children are developing outside the clinic by collaborating, having parents and pediatricians really collaborate to understand the development across social, emotional, language, cognitive, and movement, all of those things that happen that require observation where pediatricians just have very little time.

+ +

And we really kind of package that in a way to give them a snapshot of how they're developing relative to the peer group, to really kind of clarify a lot of these gray areas, if you will, and not take that wait-and-see approach, but rather to make that referral or diagnosis or get them on any kind of therapy that they need as soon as possible. And really, that's the diagnosis that this problem. The meta-problem that we're trying to solve is 25% of all children have some type of developmental delay, yet only 3% get diagnosed before the age of 3. And so, that's, you know, something very near and dear to my heart and something I'm working on every single day. That's how I got to where I am.

+ +

WILL: Wow. I am so sorry to hear about your daughter. And I'll just be totally honest: that's one of my biggest fears as a dad. So yeah, I am so sorry to hear that about your daughter. What was that situation like? How long ago was it? And kind of not having to answer, like, where are you at with that?

+ +

HANS: My daughter was born in January of 2020. Aviva lived for over ten months, and she passed away here in San Diego in November of 2020. I won't get into the background of it, but the short end of it is she never really had a diagnosis. But she had some anomalies that really created a condition called bradycardia, which is slow heart rate, only intermittently. It happened every couple of months. So, it wasn't really even a daily thing. Doctors didn't have any answers for it. We saw teams of specialists and I'm talking about cardiologists, neurologists, mitochondrial specialists, pulmonologists, every single type of specialist under the sun.

+ +

But throughout six different hospitalizations and then the autopsy afterwards, they never figured out what the root cause was. And she had some signs that were different, but, you know, we live in this world where data is abundance. Generative AI is huge, right? We have all these tools and everything else, but yet when it comes to medicine, a lot of times we rely on the human knowledge of the physicians that we see. I'm not saying that they did anything wrong because they did the best they could.

+ +

But what really upset me was that, you know, we go through this differential diagnosis of A, B, C, D, and this and the other, and they all strike out. You know, what's the backup plan? And that's where, you know, we should be using a lot more data at the big data level to really understand, you know, these anomalies. And maybe someone out there had something similar that she did or maybe a doctor in New York, or Boston, or Atlanta, or Miami somewhere would have known what to do. Unfortunately, that wasn't the case.

+ +

And really, that set me off my journey, really trying to understand that problem, in particular. There's a lot of things that kind of stand in the way from real AI being used in medicine. Of course, radiology is one exception. But when it comes down to interoperability of electronic health records as well as HIPAA, and privacy, and all the data silos they're in, Google's tried at this for a while to get to a place where you can have more precise type of data from a diagnostic perspective. Similar to the way that Facebook, and Amazon, and the Googles of the world know precisely how likely you are to click a button, I think medicine should be moving in that form and fashion. And so, yeah, that's really where I came across this journey.

+ +

And the grieving process that's a whole 'nother subject as well, but I'm a very big believer in embracing that. Each of us took a year off and really just made sure that we were taking a lot of self-care and healing. And I went to therapy for the first time in my life, did a lot of writing and a lot of other therapeutic activities, including writing children's books. So, I'm a children's book author. And that's kind of what led me to finding out what I wanted to do on a day-in, day-out basis to help parents get the answers they need, knowing that, you know, mom and dad play a very big role in this, those first five years of life which, in my opinion, are the most critical and crucial and also the most precious years of your life.

+ +

VICTORIA: You know, I really admire how you took such a painful moment and turned it into, how do I solve this problem for other people and really build community off of that as well? I don't have kids myself, but I have a niece and nephew who's two and four now. And I remember watching my sister-in-law try to keep track of all of the things that are happening for her child in the first year of their life, and it's not easy. And how do you identify if something has gone wrong? And I'm curious, like, what you learned from that process, or if you've learned anything about that process that's shifted your direction with Pathfinder.

+ +

HANS: I mean, the biggest takeaway from my own personal experience is knowing that parents can play a very proactive role, an important role in the care for their child. And so, when you look at the pediatric visit, and, Will, you probably can relate to this, you know, for 15 minutes, you know, they're checking your eyes, ears, throat, heart, giving you your vaccines, et cetera. And there's a lot of different things they have to do to check off on their task list.

+ +

But yeah, when it comes down to developmental health, we're talking about social, emotional cues, movement, cognitive, and language; it really requires observation. And they have very little time for that. Plus, you know, kids never [inaudible 08:49] themselves. There's well-child visits as well. It sort of leads to a lot of these gray areas. You know, on average, a pediatrician sees about 20 to 24 different kiddos a day, which is quite a heavy burden. They're definitely the most overworked and underpaid specialists across the whole healthcare system.

+ +

But when you think about it, you know, what they do after the well-child visits is they give usually mom or dad a two-page handout of "This is..." you know, "Your child is two years old, and here's what you can do." A lot of times those handouts just, you know, get lost, and they're very not personalized.

+ +

So, what we're doing we're a team of developmental-behavioral pediatricians, as well as early childhood specialist. We're talking about occupational therapists, physical therapists, child psychologists, and speech therapists. We're really combining all our interdisciplinary skills as well as machine learning experts on our team to be able to give parents the type of knowledge that's packaged in a way, on a parent level, that they really can understand how to track, monitor their child's growth and development. But also, if they're falling behind, or even if they're ahead, be able to enhance their development through daily activities that are tailored and customized to each individual's unique developmental trajectory.

+ +

And so, we've come up with what's called developmental biomarkers, similar to what you know as height and weight charts, to really measure and monitor a child's progress versus peers. On the physical side, we're doing that across all of those developmental domains and being able to make those conversations, and insights, and visits with the doctor a lot more comprehensive in scope, including video-based data, where we kind of isolate the milestones. We call it smart detection, really show the parents what those milestones are happening.

+ +

Parents know a lot about walking, talking, sitting, rolling over, but there's over 400 milestones that happen in the first five years of life. And so, being able to kind of understand pincer grip, you know, picking up a cheerio or looking when you call their name those are really big milestones that are very significant when it comes to determining where that child stands relative to their peers. So, yeah, that's a little how it works at a high level.

+ +

WILL: Yeah. Wow. I want to go back and tell you this just so that...I try to whenever I think of something, especially positive, I just try to tell people. And so, like, your inspiration of how you dealt with your child's passing away and everything...because I think the statistics and what I've heard is most people hit a downward spiral. Most marriages don't make it. So, it's very inspiring to hear that you grieved and you worked through the process. So, I just want you to know that, like, that's super, even for me, that's super inspiring to know that that is even possible in that situation. So, I just want you to know that.

+ +

HANS: Yeah. And I'm glad that you brought up that point. You're absolutely correct. I think over 50% of couples do get divorced after a death of a child. And a lot of times, it's not the event itself. Certainly, losing a child is very, very painful. But the cause of that separation is really the differences in the way that each other grieve, you know, the spouses grieve. And that's something that, honestly, you don't learn until you're going through it.

+ +

And so, what we did was, just like other things in our life, we were very intentional about it and really sought out as much help and support through books. Books were fantastic, also grieving groups. There's a lot of great different grieving groups out there to really understand that, hey, you're not necessarily alone. Certainly, the pain of losing a child is definitely, in my opinion, the hardest thing that anyone can go through. But in terms of being able to empathize and even commiserate, but even to hear other people's stories, you start to learn, you know, what that journey looks like five years, ten years, 20 years down the road.

+ +

But you also, you know, one of the things that I say is there's no right way to grieve at all. You can't tell someone how to grieve. But there is a wrong way to grieve. And I know that sounds like an oxymoron. But the wrong way to grieve is not doing it at all. And that's usually where we saw a lot of people kind of turn to negative addiction, or self-inflicted behaviors, or a lot of other things where they try to bottle it up, put it away, lock it in the closet and not think about it, you know, maybe bury their heads in work or any other kinds of addictions.

+ +

That's something we learned very, very early on that we try to be conscientious of and try to really steer clear from. But, again, it's a very individually unique path, and I'm definitely not an expert at all, but have certainly learned, you know, tenfold what I didn't know about grief beforehand. And so, you really don't know grief until you actually go through it.

+ +

In terms of being able to kind of parlay that into motivation to help others...and really, for me, that's my North star is really helping others, if that's helping detect diagnosis, or even, you know, just smiling to the person on the street, you know, that's what really gives me a lot of fulfillment. And so, in terms of that motivation, where does that come from, and how do you actually take that grief and transcend that into something productive like that?

+ +

The only thing I can actually say to all the parents that are listening out there it's akin to when you hold your firstborn, especially when you become a new parent. And you have that magical feeling where you're holding that small, little infant in your arms. And you have this great burden of responsibility as well. And you start thinking to yourself, man, now it's not just my life that I'm in charge of. I'm in charge of this little human being's life, who you have to do everything for them.

+ +

And so, that inspiration to be the better parent or better person that you feel as a new parent is only correlated, I would describe, to actually losing a child where that same feeling is, I would say, magnified times 3. And that's, you know, for me, I know my daughter's looking down on us, and I know that she's behind a lot of things that I'm doing, but I'm certainly inspired in a whole 'nother way apart from being just a parent.

+ +

WILL: Yeah, definitely. You said something that really caught my attention. Like, it was around how when you're holding your child, like, you're responsible for your child. I have a background in sports medicine, spent four years doing it. I still have no idea a lot of medical history when it comes to a kid. I feel like majority of the items that you're supposed to be looking for or even thinking about is totally different with a kid.

+ +

I don't know how to say this, but, like, the healthcare, the more that I have my kids, I'm seeing that there's different sides of healthcare. So, we moved from North Carolina. Our first pediatrician we loved. Every time we had an appointment, probably spent 30 to 40 minutes just talking us through, hanging out with our kids, asking questions. You know, they always gave us this list beforehand to say, "Hey, look out for these things. When you come in the office, we're going to ask you, 'Have you noticed it, or how are they doing with that?'"

+ +

And then, we moved to South Florida, and it's been totally different. Totally different. We had to fire one pediatrician because it wasn't the same care. The pediatrician we're at now is a lot better, but it's nowhere near what North Carolina was. And so, there's a lot of times that we're questioning ourselves. It's like, what does the development of our kid look like?

+ +

My oldest he had a tongue tie where he couldn't touch the top of his mouth, and we didn't know how important that was to take care of. We finally got it taken care of, but he is delayed in speech because he couldn't touch the top of his mouth. So, whenever I saw that we were going to have this podcast interview, I was just so excited because this is a huge issue. As a parent of three, this is a huge issue because you just don't know. And even when I didn't have kids, the knowledge that I had of even being a parent, yeah, I didn't know anything [laughs], and it's just learning on the go. So, everything you're doing is just speaking to me, and you are helping people. It's needed out there. So, I am so excited that you're doing it.

+ +

HANS: That warms my heart. Thank you, Will, for saying that because I didn't realize that you're actually from North Carolina. I'm from North Carolina myself from a little town called Gastonia. But when it comes to, you know, developmental health, it is the biggest gray area in all of pediatrics. And we know that pediatricians just don't have the time. That's a very big burden.

+ +

In addition, when it comes to specialists, we're talking about, you know, autism, for instance. You know, they have to be diagnosed through developmental-behavioral pediatricians or a child psychologist, and there's just a very big dearth of them. There's long waiting lines. It could be 12 to 18 months to actually get in front of them and get that evaluation, and then another 6 to 9 months to actually get therapy. And by that time, there's a lot of time lost, which is absolutely precious when it comes to the child.

+ +

90% of your child's brain, actually, develops by the time they're three years old. Another stat that parents actually don't know is that there's centers called Early Intervention Service Centers across the U.S. There's over 4,000. Their specific remit, their mandate is actually to go out and find children in their community, in the region, that do have developmental delay. And, you know, it's a very labor-intensive process to do that. I've actually done it here with my fourth child here in San Diego.

+ +

They send out two therapists. They come in, do an evaluation, talk to the parent, see how they're doing, jot down some notes, you know, it's at least an hour of their time, driving included, but it's a very kind of manually intensive process. And what we can do is really be able to preempt that and really give parents the fidelity and advocacy to speak on behalf of their child. And I would say that's the number one thing that our parents say is they thought there was a concern. They knew there was some kind of gray area.

+ +

And we know that there's a lot of stigma and denial around delays. What we're trying to do is actually lower that barrier so they have the wherewithal to actually have that conversation with their pediatrician. And simply to ask that question from a clinical-based evidence perspective, you know, that could do wonders, you know. If a kid's not speaking by the time they're two years old, if they're not saying a word, that's a big red flag. And a lot of the de facto status quo, a pediatrician will say, "Well, let's just wait till the next visit because every single child develops uniquely," which they do. But their next visit is at three years old, 12 months later. And that's time that's lost in that process.

+ +

Apart from the evaluation, they can actually do at-home interventions. There are a lot of different activities and modules that we have for parents to actually be more proactive in enhancing that child's development along the way. And so, yeah, at the end of the day, we're committed to making sure parents have those tools and knowledge that's necessary.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: As a head of product, how do you approach the design for the app you're building given just how complex it is? And you said there's 400 milestones in the first 5 years to track. How do you prioritize which one to do first?

+ +

[chuckles]

+ +

HANS: Yeah, that's a good question. And now I get into the nitty-gritty. But there's certainly been a lot of focus, and it really starts with the users, and so that's both parents as well as pediatricians. And so, personally, I've visited, even in six months, I've visited over 70 different pediatric clinics here in Southern California as well as New York and Washington State, you know, really talking to pediatricians and really understanding what would actually help, you know, make it a lot more useful and helpful for them in their own day to day.

+ +

You know, the biggest capacity constraint is really their time crunch. And so, can you get me those answers immediately? And they tell us they don't want to go to some other system. So, we've integrated directly into almost a hundred different EHRs (Electronic Health Records) across the board to the point where parents can actually just search for their pediatrician on our app and then be able to send their data directly to the pediatrician. Because when it comes down to trust, in healthcare, it's all about trust. Parents really trust the pediatrician the most at the end of the day, and so getting them on board and making sure that they're the biggest advocates for our platform will speak a lot more than just having our app in the App Store, which it is.

+ +

But in terms of the parent's side, we want them to have a really great and engaging experience where they're getting a lot of joy. We could talk about this concept called burst of joy from watching their child grow and develop. And so, there's a fine line between creating too much anxiety versus giving more information. And when it comes to development [chuckles], there's a very fine line on that. But being able to kind of track those milestones on a continuous basis, not just that point in time, you know, that one time, you know, every three, six months that they're in the doctor's office, but even on a weekly basis, kind of seeing that growth that actually happens organically on a day-to-day basis is a huge part of the parent experience.

+ +

Being able to kind of look and see what that is, why it's important, and oh, by the way, if the child's not doing that, here's some activities that you can do to really help them excel and get to the next level, you know, that's the type of thought process. And if you do have concerns, here's resources. We put together these 4,000 early intervention centers, where on the web, you have to go to each individual website. We basically just took all the information and just put it right there in one place where it's just a zip code lookup functionality.

+ +

And so, a lot of those types of approaches is really great. I think, in the future, being able to connect directly with therapists and providers might be another step because we know that the gaps in care is really one of the most critical problem. Right now, we're trying to solve that through that parent-led approach. But even reducing that 6 to 9 months down to 1 or 2 weeks, I think, that's actually a possibility.

+ +

VICTORIA: I love how you described it as what you're going for is a burst of joy and that you want to focus on having it be a joyful experience for parents. And it should be because I have also seen the anxiety part and how anxiety-inducing it can be when you're trying to keep track of all these different milestones. And, like you said, you have a handout from your doctor, or maybe you're looking up things on TikTok or Instagram [laughs]. How do you work those emotions into your design? Can you say a little bit more about that?

+ +

HANS: Yeah. So, for example, after completing an activity...so, we have all these daily activities that you can do. We start the app. We've got inspired from Headspace in terms of what they ask you to do. Here's 2 or 3 things that you can do with your child. We start with an activity, and it takes nothing more than items lying around in your home.

+ +

We believe in this concept of serve and return approach when it comes to that parent-child interaction. And so, you have those materials. You have the 10, 15 minutes that you have with your child. You're asking yourself, like, "What can I actually do to really stimulate development?" We want to meet them where they are. So, we have even at bath time, or on the playground, or in a car ride, or while you're doing laundry, sorting socks, right? Any place in time could actually have that really great approach.

+ +

And then, after completion of the activity, we have this kind of pop-up that it's almost like an accomplishment, like, we did it as a joint team, as a joint effort, with a little celebration and kind of that approach. And then, also, when you're checking off milestones, and when you check off frequently on our app, there's little hearts that kind of come out of the button to celebrate this little...we call them smilestones, but it's a small part of that celebration that happens day in, day out.

+ +

VICTORIA: I'm definitely going to say smilestones to my team next week. That's how we're going to rebrand our milestones as as well. I love it.

+ +

HANS: Yeah. I don't think that's copyrighted, so go ahead. Take it away.

+ +

WILL: What is your, I'll use that, smilestone for the next six months or, you know, next year? What's in the future? I saw on your website you're incorporating some AI into it. So, can you talk about that and anything else that you have coming up?

+ +

HANS: Yeah. So, one of the places where we're really, you know, focusing on is really getting objective about the data. So, we want to take a lot of the subjectivity, a lot of the guesswork, a lot of the recall bias, even misinterpretation of milestones, as well as language barriers of milestones. And so, just really being able to not just have the parent kind of fill out, you know, the checklist, but also, being able to incorporate the videos component as well. And so, being able to upload any kind of video of the child at the dinner table, playing with friends in the playground, playing at home in the living room. Parents have tons of these videos, right?

+ +

We're able to kind of spot and detect where those milestones are actually taking place. And so, we can isolate that three to five seconds of, here's where their child's doing the pincer grip, which is basically picking up a cheerio between your forefinger and thumb, and really being able to kind of give that validation and confirmation to the parents so they can actually say, "Oh, wow, my child actually did this new thing that I actually didn't even know about."

+ +

But on top of that, being able to turn that into a highlight reel, you know, similar to like SportsCenter highlight reel. Like, you're taking all of those different clips and turn that into maybe a 60-second highlight reel of everything that happened that transpired in between the last visit. So, when you talk about going from, like, a 12-month visit to an 18-month visit, here's all the things, in 60 seconds, that the kid's been doing to give a lot more comprehensive evaluation for their pediatrician to make better decisions at the end of the day.

+ +

Again, we are clinical decision support. We're not making the diagnosis ourselves. We leave that to the providers. But what we believe in our ethos is really giving all that information and packaging it up so that those decisions can be much better made at the end of the day. So, that's one use case of AI.

+ +

But there's still a human element to it right now, but we want to be able to kind of transpire that to a fully autonomous computer vision, which, when you look at generative AI, understanding videos and being able to detect that when you think about all of the different angles, shapes, lighting, et cetera, it's the, I would say, the last frontier of being able to kind of get data insights out of videos itself. It's very easy to go from having a text prompt and generating a video from it. It's much harder to take a video and spitting back out what we have as milestones. So, that's one part.

+ +

And the other is developmental biomarkers which is another...what we think is groundbreaking in the pediatric space.

+ +

VICTORIA: Can you explain what developmental biomarker is?

+ +

HANS: Yeah. So, it's a concept similar to what we know as the height and weight chart. And when I first became a parent, a lot of times you're speaking with other new parents, and you are, you know, on the playground, right? And they're saying that "Hey, my kid is on the 90th percentile in height or weight," or "Hey, they're 80th percentile on head circumference," because that's literally, like, as a new parent, like, that's the only basis you have other than their sleep habits, which, Will, I know you can probably attest to most parents track a lot.

+ +

But similar to that, like, in terms of, you know, how developmental tracking is done right now, the status quo is using developmental screeners. And so, that's, again, point in time, static approach while you're in the well-child visit. But the problem with developmental screeners is it has what's called a low sensitivity and specificity in terms of really over-detecting or over-failing basically one side of the distribution. So, it's typically 40% to 50% of kids would fail a screener when, in reality it should be around 20 to 25.

+ +

To really get more granular and very objective about understanding a child's developmental trend, one has to kind of be able to, we believe, understand both the right and the left side of the distribution and being able to understand, hey, is this child actually tracking ahead of the curve or behind the curve relative to everyone else?

+ +

And so, we've developed an algorithm. It's fairly complex, but it uses a lot of the underlying data sets that we have to kind of give a much more high-fidelity picture of, hey, your child's in the 60th to 65th percentile. At the end of the day, we want to be able to identify delays. And so, anything below 20% or so, you know, parents should be more informed about that and looking at it on a domain-by-domain specific level.

+ +

So, it's very common for a kid to be accelerated on 3 of the four domains, but maybe they're behind on speech. And so, what does the doctor do with that? If they're at 15th percentile in speech, they can then come in the clinic and say, "Hey, I see the screening results, but I also see this Pathfinder report. Let's spend the next 5 to 10 minutes actually seeing how you verbalize and how you're able to speak and express yourself." So, that's really what we're talking about when it comes to developmental biomarkers.

+ +

VICTORIA: Gotcha. Okay. Yeah. I think I knew what you were referring to, but I wanted to make sure [laughs], but that makes sense. So, it's like whatever the data that helps the parent identify where there might be an area that some intervention or some more time might need to be taken to help move them forward.

+ +

HANS: It is on a longitudinal basis, which, if you're in healthcare, you know longitudinal trend. Really understanding what that looks like is hugely important versus point in time. And so, we're able to see it not just at the sixth month and nine month, but every day in between as well. And we believe, you know, the early results are kind of showing that we're able to even preempt what those potential red flags will look like, or a failed screening result will look like at an earlier rate as well.

+ +

VICTORIA: That's really interesting. I'm curious if you have other statistics like that or some results from the first year, almost two years of data that you have now, on how people are interacting with the app. And what kind of outcomes are you getting?

+ +

HANS: Yeah, as I said, you know, the biggest outcome is really being able to give parents a really highly objective look at how their children are developing, and so giving them the level of advocacy to speak on the child's behalf with clinical evidence. If you look at our testimonials, that's probably the number one thing. We have different personas for different types of moms.

+ +

But there's some moms that are the Nervous Nellies, the ones that are concerned about every single cut, scrape, and bruise. There's also the Inkling Ingrids, the ones that think there might be something there, but they're not necessarily sure. But then there's also the Ambitious Amandas, these types of moms that want to put their kids in every single type of advanced activity, right? Music classes, Legos, et cetera. And then, the Brand New Brendas, the ones that are brand new to parenting and want to know, learn, explore, and track the child's development.

+ +

So yeah, there's different things for different types of personas that we have. By and large, it's really giving that information in a very parent-friendly way so it's not overwhelming them with too much anxiety or, you know, going over their heads as a lot of times medical jargon does as well.

+ +

VICTORIA: Wow. That's great. Thank you for sharing that. And I wonder, actually, Hans, I wanted to ask you a question about bias and about bias in AI and in health tech. And how do you approach that in Pathfinder and making sure that everyone's getting equitable health incomes and recommendations within the app?

+ +

HANS: Yeah, bias and accessibility are two big topics that we think a lot about, you know, first of all, on the underlying data bias, you know, that could present itself. Right now, our app is available on App Store and Play Store. We have over 50,000 parents, you know, still small but growing in about 120 different countries, mainly English-speaking ones, because right now the app is completely in English. That's about to change. We're about to go multilingual, starting with Spanish, which is definitely the biggest request.

+ +

But so, when it comes to, like, being able to compare across different groups and subsets, you know, we do believe we have a fairly heterogeneous group. Only about 50% of our users are actually here in the U.S. In terms of the actual milestones themselves, there could be, you know, some differences in cultures. Something like "Eats with a fork" is a milestone that happens, I think, around two or three years old. You know, in cultures like India, for instance, they usually eat with their hands for a lot of time. So, that would be obviously a difference. That milestone wouldn't necessarily apply as much.

+ +

But then when you talk about accessibility, one of the things that we screen for in our standard screening that we do have, and I forgot to mention this earlier up front, we almost have, like, a four-legged stool, if you will, in terms of the underlying data that we capture. One is standard screeners because that is status quo. That is reimbursed on the pediatrician's side. And the biggest value prop to pediatricians to adopt our platform is, hey, we can help you get towards 100% developmental screen adherence, which right now it's only about 60 or even less than 50% across the board. So, that's a reimbursable event. So, that's layer 1.

+ +

Layer 2 is parent concerns, caption that in a good, valid way, and then continuous milestone tracking. And then, finally, the videos as well. So, certainly, some parents don't submit videos for privacy reasons, which is okay. We still have all of the other 3. So, going back to social determinants of health and health equity, that's one of the things that we screen for as well, knowing that the more vulnerable populations and minorities, lower socioeconomic classes, actually do have a higher prevalence of delays. And so, we want to be able to be accessible to them as much as we can but also, raise those things to the surface when it comes to getting those answers to pediatricians.

+ +

There's another big movement happening called Adverse Childhood Experiences screeners (ACEs) that really looks at, you know, how the child's been developing and what their background, their environment actually looks like. So, looking at those questions of, is that child being raised in an environment of neglect, or abuse, or a broken home, or drug addictions in the home? Those can really have an effect, not just on the early part of life, but even later in life when you talk about physical as well as mental well-being. And so, just having that awareness and that insight into how that child's been developing is really important on the background side.

+ +

And so, at the end of the day, when we're talking about who actually holds the bag, if you will, in terms of this big gap that we're trying to solve, at the end of the day, it's really the government. If the child does have a delay that doesn't get addressed at an early age, doesn't get, you know, therapy, a lot of times, it leads on to run-on consequences, whether that's mental issues or maybe not being able to be self-sufficient, independent, job seeking, tax-paying, delinquencies. There's a lot of different ramifications from things that happen at a very early age.

+ +

That's where we believe in partnership with Medicaid through clinics like Federal Qualified Health Centers that focus on the Medicaid population, which 38% of all kids fall under, those are ideal partners for us. It's a longer, harder slog and a long road. But we believe there's a lot that we can offer at that level as well as more ACO and value-based payer type of model.

+ +

VICTORIA: Oh, wonderful. Well, thank you so much, Hans, for coming on and sharing your story with us. Do you have anything that you would like to promote?

+ +

HANS: I know we didn't get a chance to speak about it, but the children's book I've written very near and dear to my heart is called Baby Aviva, Orangutan Diva. You can get that out on Amazon, anywhere. But it's A-V-I-V-A. If you're a parent and if you have a kid under the age of five, feel free to check out our app called Pathfinder Health. And Pathfinder is just one word on the App Store and Play Store. But thank you, Will, and thank you, Victoria.

+ +

WILL: Thank you. It was great talking to you. And I'm going to go download the app.

+ +

HANS: Absolutely. Thanks so much. And I really appreciate it.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on X or Twitter [laughs] @victori_ousg or on Mastodon @thoughtbotsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Victoria Guido are joined by Hans Kullberg, Co-Founder and Head of Product at Pathfinder Health. Pathfinder Health is an early-stage startup that provides objective insights into children's developmental health to pediatric clinics. Hans shares his journey, starting with his career on Wall Street, moving through various startup experiences, and finally, his pivotal role at Visa, which was significantly shaped by the tragic loss of his daughter, Aviva. This loss inspired him to focus on helping families get timely and accurate developmental diagnoses for their children.

+ +

The episode highlights pediatricians' challenges in monitoring developmental health due to time constraints during appointments and the lack of detailed observation that these brief interactions afford. Hans explains how Pathfinder Health aims to address these challenges by enhancing the collaboration between parents and pediatricians through technology, providing detailed tracking and insights into a child's development outside of clinical visits. This includes innovative approaches like using machine learning to analyze video data of children in their natural environments, helping to pinpoint developmental milestones more accurately.

+ +

Hans also discusses the broader implications of early and accurate developmental diagnosis by emphasizing the importance of using data to overcome the limitations of current medical practices. By integrating detailed developmental data into health records, Pathfinder Health hopes to transform pediatric care by being able to allow for earlier interventions for its patients.

+ + + +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Hans Kullberg, Co-Founder and Head of Product at Pathfinder Health, an early-stage pediatric developmental health tech startup focused on bringing objective insights on children's developmental health to pediatric clinics everywhere. Hans, thank you for joining us.

+ +

HANS: Thank you, Will. Thank you, Victoria. It's really awesome to be here.

+ +

VICTORIA: Great. Well, I met you at the San Diego Founders Hike at probably 7:30 in the morning on a Friday [laughs] a couple of weeks ago. So, tell me just a little bit more about what do you do for fun around San Diego?

+ +

HANS: Yeah, I do a lot of fun. First of all, I'm a dad of four kids, so that keeps me busy, and it keeps my fun time relegated to the windows that I can do it. But I love to start morning surf right out here in Mission Beach in San Diego. I love to cook for a lot of people, house parties, and as well as hunger suppers. And then, I love playing saxophone when I can.

+ +

VICTORIA: What's your favorite song to play on the saxophone?

+ +

HANS: So, I'm messing around with it right now. I'm not great, but I'm learning Happy Birthday right now.

+ +

VICTORIA: That's a great song, and you have a lot of birthdays to celebrate, it sounds like, over there. So, good to have that handy.

+ +

HANS: Mm-hmm. Yep.

+ +

VICTORIA: Well, awesome. Well, why don't you tell us a little bit more about your background and how it led to Pathfinder Health?

+ +

HANS: My background is in data science and economics, and started my career actually on Wall Street, really looking at economic data, things like GDP and inflation, and macroeconomic variables like employment nonfarm payrolls. And I really tried to figure out a way to understand how to predict those at a very high degree of accuracy. That kind of led to my very first startup called, EconoCast, which was fairly successful. And that was exited back in 2013.

+ +

Then I did a few other things, some startups that were successful, others that were not. But then I really wanted to kind of chop my teeth into product and really learn product from the inside out at a much bigger company. So, I joined the innovation team at Visa. I was working on Visa Acceptance Cloud, which is really kind of a point-of-sale solution in the cloud. So, if you're familiar with Apple Pay and Google Pay, it was pretty much the mirror image of that for receiving payments and accepting payments. And that really helps a lot of long-tail merchants, if you will, kind of in places like India, and Nigeria, Brazil, et cetera, that are traditionally accepting cash payments to be able to accept credit and debit payments.

+ +

However, life took a turn. And while I was at Visa, my third child, Aviva, passed away. And there's, you know, a lot of backstory on that side, but she still doesn't have a diagnosis to this day. It was certainly the hardest part of my life and time of my life for my wife, my family. And I took some time off, really embraced the grieving process, but really tried to figure out what I wanted to do next. And really, that centered around a promise that I made to my daughter was to really try to get parents and families the answers that they deserve to really understand their diagnosis.

+ +

So, I talked to a lot of different people in the healthcare community, trying to figure out what I wanted to do with my particular background in data science and technology and building products to be able to kind of marry that with getting parents the answers that they need. And so, that's where I really came in contact with my co-founders at Pathfinder Health to really build what we believe is the most advanced way to really help pediatricians and providers understand how children are developing outside the clinic by collaborating, having parents and pediatricians really collaborate to understand the development across social, emotional, language, cognitive, and movement, all of those things that happen that require observation where pediatricians just have very little time.

+ +

And we really kind of package that in a way to give them a snapshot of how they're developing relative to the peer group, to really kind of clarify a lot of these gray areas, if you will, and not take that wait-and-see approach, but rather to make that referral or diagnosis or get them on any kind of therapy that they need as soon as possible. And really, that's the diagnosis that this problem. The meta-problem that we're trying to solve is 25% of all children have some type of developmental delay, yet only 3% get diagnosed before the age of 3. And so, that's, you know, something very near and dear to my heart and something I'm working on every single day. That's how I got to where I am.

+ +

WILL: Wow. I am so sorry to hear about your daughter. And I'll just be totally honest: that's one of my biggest fears as a dad. So yeah, I am so sorry to hear that about your daughter. What was that situation like? How long ago was it? And kind of not having to answer, like, where are you at with that?

+ +

HANS: My daughter was born in January of 2020. Aviva lived for over ten months, and she passed away here in San Diego in November of 2020. I won't get into the background of it, but the short end of it is she never really had a diagnosis. But she had some anomalies that really created a condition called bradycardia, which is slow heart rate, only intermittently. It happened every couple of months. So, it wasn't really even a daily thing. Doctors didn't have any answers for it. We saw teams of specialists and I'm talking about cardiologists, neurologists, mitochondrial specialists, pulmonologists, every single type of specialist under the sun.

+ +

But throughout six different hospitalizations and then the autopsy afterwards, they never figured out what the root cause was. And she had some signs that were different, but, you know, we live in this world where data is abundance. Generative AI is huge, right? We have all these tools and everything else, but yet when it comes to medicine, a lot of times we rely on the human knowledge of the physicians that we see. I'm not saying that they did anything wrong because they did the best they could.

+ +

But what really upset me was that, you know, we go through this differential diagnosis of A, B, C, D, and this and the other, and they all strike out. You know, what's the backup plan? And that's where, you know, we should be using a lot more data at the big data level to really understand, you know, these anomalies. And maybe someone out there had something similar that she did or maybe a doctor in New York, or Boston, or Atlanta, or Miami somewhere would have known what to do. Unfortunately, that wasn't the case.

+ +

And really, that set me off my journey, really trying to understand that problem, in particular. There's a lot of things that kind of stand in the way from real AI being used in medicine. Of course, radiology is one exception. But when it comes down to interoperability of electronic health records as well as HIPAA, and privacy, and all the data silos they're in, Google's tried at this for a while to get to a place where you can have more precise type of data from a diagnostic perspective. Similar to the way that Facebook, and Amazon, and the Googles of the world know precisely how likely you are to click a button, I think medicine should be moving in that form and fashion. And so, yeah, that's really where I came across this journey.

+ +

And the grieving process that's a whole 'nother subject as well, but I'm a very big believer in embracing that. Each of us took a year off and really just made sure that we were taking a lot of self-care and healing. And I went to therapy for the first time in my life, did a lot of writing and a lot of other therapeutic activities, including writing children's books. So, I'm a children's book author. And that's kind of what led me to finding out what I wanted to do on a day-in, day-out basis to help parents get the answers they need, knowing that, you know, mom and dad play a very big role in this, those first five years of life which, in my opinion, are the most critical and crucial and also the most precious years of your life.

+ +

VICTORIA: You know, I really admire how you took such a painful moment and turned it into, how do I solve this problem for other people and really build community off of that as well? I don't have kids myself, but I have a niece and nephew who's two and four now. And I remember watching my sister-in-law try to keep track of all of the things that are happening for her child in the first year of their life, and it's not easy. And how do you identify if something has gone wrong? And I'm curious, like, what you learned from that process, or if you've learned anything about that process that's shifted your direction with Pathfinder.

+ +

HANS: I mean, the biggest takeaway from my own personal experience is knowing that parents can play a very proactive role, an important role in the care for their child. And so, when you look at the pediatric visit, and, Will, you probably can relate to this, you know, for 15 minutes, you know, they're checking your eyes, ears, throat, heart, giving you your vaccines, et cetera. And there's a lot of different things they have to do to check off on their task list.

+ +

But yeah, when it comes down to developmental health, we're talking about social, emotional cues, movement, cognitive, and language; it really requires observation. And they have very little time for that. Plus, you know, kids never [inaudible 08:49] themselves. There's well-child visits as well. It sort of leads to a lot of these gray areas. You know, on average, a pediatrician sees about 20 to 24 different kiddos a day, which is quite a heavy burden. They're definitely the most overworked and underpaid specialists across the whole healthcare system.

+ +

But when you think about it, you know, what they do after the well-child visits is they give usually mom or dad a two-page handout of "This is..." you know, "Your child is two years old, and here's what you can do." A lot of times those handouts just, you know, get lost, and they're very not personalized.

+ +

So, what we're doing we're a team of developmental-behavioral pediatricians, as well as early childhood specialist. We're talking about occupational therapists, physical therapists, child psychologists, and speech therapists. We're really combining all our interdisciplinary skills as well as machine learning experts on our team to be able to give parents the type of knowledge that's packaged in a way, on a parent level, that they really can understand how to track, monitor their child's growth and development. But also, if they're falling behind, or even if they're ahead, be able to enhance their development through daily activities that are tailored and customized to each individual's unique developmental trajectory.

+ +

And so, we've come up with what's called developmental biomarkers, similar to what you know as height and weight charts, to really measure and monitor a child's progress versus peers. On the physical side, we're doing that across all of those developmental domains and being able to make those conversations, and insights, and visits with the doctor a lot more comprehensive in scope, including video-based data, where we kind of isolate the milestones. We call it smart detection, really show the parents what those milestones are happening.

+ +

Parents know a lot about walking, talking, sitting, rolling over, but there's over 400 milestones that happen in the first five years of life. And so, being able to kind of understand pincer grip, you know, picking up a cheerio or looking when you call their name those are really big milestones that are very significant when it comes to determining where that child stands relative to their peers. So, yeah, that's a little how it works at a high level.

+ +

WILL: Yeah. Wow. I want to go back and tell you this just so that...I try to whenever I think of something, especially positive, I just try to tell people. And so, like, your inspiration of how you dealt with your child's passing away and everything...because I think the statistics and what I've heard is most people hit a downward spiral. Most marriages don't make it. So, it's very inspiring to hear that you grieved and you worked through the process. So, I just want you to know that, like, that's super, even for me, that's super inspiring to know that that is even possible in that situation. So, I just want you to know that.

+ +

HANS: Yeah. And I'm glad that you brought up that point. You're absolutely correct. I think over 50% of couples do get divorced after a death of a child. And a lot of times, it's not the event itself. Certainly, losing a child is very, very painful. But the cause of that separation is really the differences in the way that each other grieve, you know, the spouses grieve. And that's something that, honestly, you don't learn until you're going through it.

+ +

And so, what we did was, just like other things in our life, we were very intentional about it and really sought out as much help and support through books. Books were fantastic, also grieving groups. There's a lot of great different grieving groups out there to really understand that, hey, you're not necessarily alone. Certainly, the pain of losing a child is definitely, in my opinion, the hardest thing that anyone can go through. But in terms of being able to empathize and even commiserate, but even to hear other people's stories, you start to learn, you know, what that journey looks like five years, ten years, 20 years down the road.

+ +

But you also, you know, one of the things that I say is there's no right way to grieve at all. You can't tell someone how to grieve. But there is a wrong way to grieve. And I know that sounds like an oxymoron. But the wrong way to grieve is not doing it at all. And that's usually where we saw a lot of people kind of turn to negative addiction, or self-inflicted behaviors, or a lot of other things where they try to bottle it up, put it away, lock it in the closet and not think about it, you know, maybe bury their heads in work or any other kinds of addictions.

+ +

That's something we learned very, very early on that we try to be conscientious of and try to really steer clear from. But, again, it's a very individually unique path, and I'm definitely not an expert at all, but have certainly learned, you know, tenfold what I didn't know about grief beforehand. And so, you really don't know grief until you actually go through it.

+ +

In terms of being able to kind of parlay that into motivation to help others...and really, for me, that's my North star is really helping others, if that's helping detect diagnosis, or even, you know, just smiling to the person on the street, you know, that's what really gives me a lot of fulfillment. And so, in terms of that motivation, where does that come from, and how do you actually take that grief and transcend that into something productive like that?

+ +

The only thing I can actually say to all the parents that are listening out there it's akin to when you hold your firstborn, especially when you become a new parent. And you have that magical feeling where you're holding that small, little infant in your arms. And you have this great burden of responsibility as well. And you start thinking to yourself, man, now it's not just my life that I'm in charge of. I'm in charge of this little human being's life, who you have to do everything for them.

+ +

And so, that inspiration to be the better parent or better person that you feel as a new parent is only correlated, I would describe, to actually losing a child where that same feeling is, I would say, magnified times 3. And that's, you know, for me, I know my daughter's looking down on us, and I know that she's behind a lot of things that I'm doing, but I'm certainly inspired in a whole 'nother way apart from being just a parent.

+ +

WILL: Yeah, definitely. You said something that really caught my attention. Like, it was around how when you're holding your child, like, you're responsible for your child. I have a background in sports medicine, spent four years doing it. I still have no idea a lot of medical history when it comes to a kid. I feel like majority of the items that you're supposed to be looking for or even thinking about is totally different with a kid.

+ +

I don't know how to say this, but, like, the healthcare, the more that I have my kids, I'm seeing that there's different sides of healthcare. So, we moved from North Carolina. Our first pediatrician we loved. Every time we had an appointment, probably spent 30 to 40 minutes just talking us through, hanging out with our kids, asking questions. You know, they always gave us this list beforehand to say, "Hey, look out for these things. When you come in the office, we're going to ask you, 'Have you noticed it, or how are they doing with that?'"

+ +

And then, we moved to South Florida, and it's been totally different. Totally different. We had to fire one pediatrician because it wasn't the same care. The pediatrician we're at now is a lot better, but it's nowhere near what North Carolina was. And so, there's a lot of times that we're questioning ourselves. It's like, what does the development of our kid look like?

+ +

My oldest he had a tongue tie where he couldn't touch the top of his mouth, and we didn't know how important that was to take care of. We finally got it taken care of, but he is delayed in speech because he couldn't touch the top of his mouth. So, whenever I saw that we were going to have this podcast interview, I was just so excited because this is a huge issue. As a parent of three, this is a huge issue because you just don't know. And even when I didn't have kids, the knowledge that I had of even being a parent, yeah, I didn't know anything [laughs], and it's just learning on the go. So, everything you're doing is just speaking to me, and you are helping people. It's needed out there. So, I am so excited that you're doing it.

+ +

HANS: That warms my heart. Thank you, Will, for saying that because I didn't realize that you're actually from North Carolina. I'm from North Carolina myself from a little town called Gastonia. But when it comes to, you know, developmental health, it is the biggest gray area in all of pediatrics. And we know that pediatricians just don't have the time. That's a very big burden.

+ +

In addition, when it comes to specialists, we're talking about, you know, autism, for instance. You know, they have to be diagnosed through developmental-behavioral pediatricians or a child psychologist, and there's just a very big dearth of them. There's long waiting lines. It could be 12 to 18 months to actually get in front of them and get that evaluation, and then another 6 to 9 months to actually get therapy. And by that time, there's a lot of time lost, which is absolutely precious when it comes to the child.

+ +

90% of your child's brain, actually, develops by the time they're three years old. Another stat that parents actually don't know is that there's centers called Early Intervention Service Centers across the U.S. There's over 4,000. Their specific remit, their mandate is actually to go out and find children in their community, in the region, that do have developmental delay. And, you know, it's a very labor-intensive process to do that. I've actually done it here with my fourth child here in San Diego.

+ +

They send out two therapists. They come in, do an evaluation, talk to the parent, see how they're doing, jot down some notes, you know, it's at least an hour of their time, driving included, but it's a very kind of manually intensive process. And what we can do is really be able to preempt that and really give parents the fidelity and advocacy to speak on behalf of their child. And I would say that's the number one thing that our parents say is they thought there was a concern. They knew there was some kind of gray area.

+ +

And we know that there's a lot of stigma and denial around delays. What we're trying to do is actually lower that barrier so they have the wherewithal to actually have that conversation with their pediatrician. And simply to ask that question from a clinical-based evidence perspective, you know, that could do wonders, you know. If a kid's not speaking by the time they're two years old, if they're not saying a word, that's a big red flag. And a lot of the de facto status quo, a pediatrician will say, "Well, let's just wait till the next visit because every single child develops uniquely," which they do. But their next visit is at three years old, 12 months later. And that's time that's lost in that process.

+ +

Apart from the evaluation, they can actually do at-home interventions. There are a lot of different activities and modules that we have for parents to actually be more proactive in enhancing that child's development along the way. And so, yeah, at the end of the day, we're committed to making sure parents have those tools and knowledge that's necessary.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: As a head of product, how do you approach the design for the app you're building given just how complex it is? And you said there's 400 milestones in the first 5 years to track. How do you prioritize which one to do first?

+ +

[chuckles]

+ +

HANS: Yeah, that's a good question. And now I get into the nitty-gritty. But there's certainly been a lot of focus, and it really starts with the users, and so that's both parents as well as pediatricians. And so, personally, I've visited, even in six months, I've visited over 70 different pediatric clinics here in Southern California as well as New York and Washington State, you know, really talking to pediatricians and really understanding what would actually help, you know, make it a lot more useful and helpful for them in their own day to day.

+ +

You know, the biggest capacity constraint is really their time crunch. And so, can you get me those answers immediately? And they tell us they don't want to go to some other system. So, we've integrated directly into almost a hundred different EHRs (Electronic Health Records) across the board to the point where parents can actually just search for their pediatrician on our app and then be able to send their data directly to the pediatrician. Because when it comes down to trust, in healthcare, it's all about trust. Parents really trust the pediatrician the most at the end of the day, and so getting them on board and making sure that they're the biggest advocates for our platform will speak a lot more than just having our app in the App Store, which it is.

+ +

But in terms of the parent's side, we want them to have a really great and engaging experience where they're getting a lot of joy. We could talk about this concept called burst of joy from watching their child grow and develop. And so, there's a fine line between creating too much anxiety versus giving more information. And when it comes to development [chuckles], there's a very fine line on that. But being able to kind of track those milestones on a continuous basis, not just that point in time, you know, that one time, you know, every three, six months that they're in the doctor's office, but even on a weekly basis, kind of seeing that growth that actually happens organically on a day-to-day basis is a huge part of the parent experience.

+ +

Being able to kind of look and see what that is, why it's important, and oh, by the way, if the child's not doing that, here's some activities that you can do to really help them excel and get to the next level, you know, that's the type of thought process. And if you do have concerns, here's resources. We put together these 4,000 early intervention centers, where on the web, you have to go to each individual website. We basically just took all the information and just put it right there in one place where it's just a zip code lookup functionality.

+ +

And so, a lot of those types of approaches is really great. I think, in the future, being able to connect directly with therapists and providers might be another step because we know that the gaps in care is really one of the most critical problem. Right now, we're trying to solve that through that parent-led approach. But even reducing that 6 to 9 months down to 1 or 2 weeks, I think, that's actually a possibility.

+ +

VICTORIA: I love how you described it as what you're going for is a burst of joy and that you want to focus on having it be a joyful experience for parents. And it should be because I have also seen the anxiety part and how anxiety-inducing it can be when you're trying to keep track of all these different milestones. And, like you said, you have a handout from your doctor, or maybe you're looking up things on TikTok or Instagram [laughs]. How do you work those emotions into your design? Can you say a little bit more about that?

+ +

HANS: Yeah. So, for example, after completing an activity...so, we have all these daily activities that you can do. We start the app. We've got inspired from Headspace in terms of what they ask you to do. Here's 2 or 3 things that you can do with your child. We start with an activity, and it takes nothing more than items lying around in your home.

+ +

We believe in this concept of serve and return approach when it comes to that parent-child interaction. And so, you have those materials. You have the 10, 15 minutes that you have with your child. You're asking yourself, like, "What can I actually do to really stimulate development?" We want to meet them where they are. So, we have even at bath time, or on the playground, or in a car ride, or while you're doing laundry, sorting socks, right? Any place in time could actually have that really great approach.

+ +

And then, after completion of the activity, we have this kind of pop-up that it's almost like an accomplishment, like, we did it as a joint team, as a joint effort, with a little celebration and kind of that approach. And then, also, when you're checking off milestones, and when you check off frequently on our app, there's little hearts that kind of come out of the button to celebrate this little...we call them smilestones, but it's a small part of that celebration that happens day in, day out.

+ +

VICTORIA: I'm definitely going to say smilestones to my team next week. That's how we're going to rebrand our milestones as as well. I love it.

+ +

HANS: Yeah. I don't think that's copyrighted, so go ahead. Take it away.

+ +

WILL: What is your, I'll use that, smilestone for the next six months or, you know, next year? What's in the future? I saw on your website you're incorporating some AI into it. So, can you talk about that and anything else that you have coming up?

+ +

HANS: Yeah. So, one of the places where we're really, you know, focusing on is really getting objective about the data. So, we want to take a lot of the subjectivity, a lot of the guesswork, a lot of the recall bias, even misinterpretation of milestones, as well as language barriers of milestones. And so, just really being able to not just have the parent kind of fill out, you know, the checklist, but also, being able to incorporate the videos component as well. And so, being able to upload any kind of video of the child at the dinner table, playing with friends in the playground, playing at home in the living room. Parents have tons of these videos, right?

+ +

We're able to kind of spot and detect where those milestones are actually taking place. And so, we can isolate that three to five seconds of, here's where their child's doing the pincer grip, which is basically picking up a cheerio between your forefinger and thumb, and really being able to kind of give that validation and confirmation to the parents so they can actually say, "Oh, wow, my child actually did this new thing that I actually didn't even know about."

+ +

But on top of that, being able to turn that into a highlight reel, you know, similar to like SportsCenter highlight reel. Like, you're taking all of those different clips and turn that into maybe a 60-second highlight reel of everything that happened that transpired in between the last visit. So, when you talk about going from, like, a 12-month visit to an 18-month visit, here's all the things, in 60 seconds, that the kid's been doing to give a lot more comprehensive evaluation for their pediatrician to make better decisions at the end of the day.

+ +

Again, we are clinical decision support. We're not making the diagnosis ourselves. We leave that to the providers. But what we believe in our ethos is really giving all that information and packaging it up so that those decisions can be much better made at the end of the day. So, that's one use case of AI.

+ +

But there's still a human element to it right now, but we want to be able to kind of transpire that to a fully autonomous computer vision, which, when you look at generative AI, understanding videos and being able to detect that when you think about all of the different angles, shapes, lighting, et cetera, it's the, I would say, the last frontier of being able to kind of get data insights out of videos itself. It's very easy to go from having a text prompt and generating a video from it. It's much harder to take a video and spitting back out what we have as milestones. So, that's one part.

+ +

And the other is developmental biomarkers which is another...what we think is groundbreaking in the pediatric space.

+ +

VICTORIA: Can you explain what developmental biomarker is?

+ +

HANS: Yeah. So, it's a concept similar to what we know as the height and weight chart. And when I first became a parent, a lot of times you're speaking with other new parents, and you are, you know, on the playground, right? And they're saying that "Hey, my kid is on the 90th percentile in height or weight," or "Hey, they're 80th percentile on head circumference," because that's literally, like, as a new parent, like, that's the only basis you have other than their sleep habits, which, Will, I know you can probably attest to most parents track a lot.

+ +

But similar to that, like, in terms of, you know, how developmental tracking is done right now, the status quo is using developmental screeners. And so, that's, again, point in time, static approach while you're in the well-child visit. But the problem with developmental screeners is it has what's called a low sensitivity and specificity in terms of really over-detecting or over-failing basically one side of the distribution. So, it's typically 40% to 50% of kids would fail a screener when, in reality it should be around 20 to 25.

+ +

To really get more granular and very objective about understanding a child's developmental trend, one has to kind of be able to, we believe, understand both the right and the left side of the distribution and being able to understand, hey, is this child actually tracking ahead of the curve or behind the curve relative to everyone else?

+ +

And so, we've developed an algorithm. It's fairly complex, but it uses a lot of the underlying data sets that we have to kind of give a much more high-fidelity picture of, hey, your child's in the 60th to 65th percentile. At the end of the day, we want to be able to identify delays. And so, anything below 20% or so, you know, parents should be more informed about that and looking at it on a domain-by-domain specific level.

+ +

So, it's very common for a kid to be accelerated on 3 of the four domains, but maybe they're behind on speech. And so, what does the doctor do with that? If they're at 15th percentile in speech, they can then come in the clinic and say, "Hey, I see the screening results, but I also see this Pathfinder report. Let's spend the next 5 to 10 minutes actually seeing how you verbalize and how you're able to speak and express yourself." So, that's really what we're talking about when it comes to developmental biomarkers.

+ +

VICTORIA: Gotcha. Okay. Yeah. I think I knew what you were referring to, but I wanted to make sure [laughs], but that makes sense. So, it's like whatever the data that helps the parent identify where there might be an area that some intervention or some more time might need to be taken to help move them forward.

+ +

HANS: It is on a longitudinal basis, which, if you're in healthcare, you know longitudinal trend. Really understanding what that looks like is hugely important versus point in time. And so, we're able to see it not just at the sixth month and nine month, but every day in between as well. And we believe, you know, the early results are kind of showing that we're able to even preempt what those potential red flags will look like, or a failed screening result will look like at an earlier rate as well.

+ +

VICTORIA: That's really interesting. I'm curious if you have other statistics like that or some results from the first year, almost two years of data that you have now, on how people are interacting with the app. And what kind of outcomes are you getting?

+ +

HANS: Yeah, as I said, you know, the biggest outcome is really being able to give parents a really highly objective look at how their children are developing, and so giving them the level of advocacy to speak on the child's behalf with clinical evidence. If you look at our testimonials, that's probably the number one thing. We have different personas for different types of moms.

+ +

But there's some moms that are the Nervous Nellies, the ones that are concerned about every single cut, scrape, and bruise. There's also the Inkling Ingrids, the ones that think there might be something there, but they're not necessarily sure. But then there's also the Ambitious Amandas, these types of moms that want to put their kids in every single type of advanced activity, right? Music classes, Legos, et cetera. And then, the Brand New Brendas, the ones that are brand new to parenting and want to know, learn, explore, and track the child's development.

+ +

So yeah, there's different things for different types of personas that we have. By and large, it's really giving that information in a very parent-friendly way so it's not overwhelming them with too much anxiety or, you know, going over their heads as a lot of times medical jargon does as well.

+ +

VICTORIA: Wow. That's great. Thank you for sharing that. And I wonder, actually, Hans, I wanted to ask you a question about bias and about bias in AI and in health tech. And how do you approach that in Pathfinder and making sure that everyone's getting equitable health incomes and recommendations within the app?

+ +

HANS: Yeah, bias and accessibility are two big topics that we think a lot about, you know, first of all, on the underlying data bias, you know, that could present itself. Right now, our app is available on App Store and Play Store. We have over 50,000 parents, you know, still small but growing in about 120 different countries, mainly English-speaking ones, because right now the app is completely in English. That's about to change. We're about to go multilingual, starting with Spanish, which is definitely the biggest request.

+ +

But so, when it comes to, like, being able to compare across different groups and subsets, you know, we do believe we have a fairly heterogeneous group. Only about 50% of our users are actually here in the U.S. In terms of the actual milestones themselves, there could be, you know, some differences in cultures. Something like "Eats with a fork" is a milestone that happens, I think, around two or three years old. You know, in cultures like India, for instance, they usually eat with their hands for a lot of time. So, that would be obviously a difference. That milestone wouldn't necessarily apply as much.

+ +

But then when you talk about accessibility, one of the things that we screen for in our standard screening that we do have, and I forgot to mention this earlier up front, we almost have, like, a four-legged stool, if you will, in terms of the underlying data that we capture. One is standard screeners because that is status quo. That is reimbursed on the pediatrician's side. And the biggest value prop to pediatricians to adopt our platform is, hey, we can help you get towards 100% developmental screen adherence, which right now it's only about 60 or even less than 50% across the board. So, that's a reimbursable event. So, that's layer 1.

+ +

Layer 2 is parent concerns, caption that in a good, valid way, and then continuous milestone tracking. And then, finally, the videos as well. So, certainly, some parents don't submit videos for privacy reasons, which is okay. We still have all of the other 3. So, going back to social determinants of health and health equity, that's one of the things that we screen for as well, knowing that the more vulnerable populations and minorities, lower socioeconomic classes, actually do have a higher prevalence of delays. And so, we want to be able to be accessible to them as much as we can but also, raise those things to the surface when it comes to getting those answers to pediatricians.

+ +

There's another big movement happening called Adverse Childhood Experiences screeners (ACEs) that really looks at, you know, how the child's been developing and what their background, their environment actually looks like. So, looking at those questions of, is that child being raised in an environment of neglect, or abuse, or a broken home, or drug addictions in the home? Those can really have an effect, not just on the early part of life, but even later in life when you talk about physical as well as mental well-being. And so, just having that awareness and that insight into how that child's been developing is really important on the background side.

+ +

And so, at the end of the day, when we're talking about who actually holds the bag, if you will, in terms of this big gap that we're trying to solve, at the end of the day, it's really the government. If the child does have a delay that doesn't get addressed at an early age, doesn't get, you know, therapy, a lot of times, it leads on to run-on consequences, whether that's mental issues or maybe not being able to be self-sufficient, independent, job seeking, tax-paying, delinquencies. There's a lot of different ramifications from things that happen at a very early age.

+ +

That's where we believe in partnership with Medicaid through clinics like Federal Qualified Health Centers that focus on the Medicaid population, which 38% of all kids fall under, those are ideal partners for us. It's a longer, harder slog and a long road. But we believe there's a lot that we can offer at that level as well as more ACO and value-based payer type of model.

+ +

VICTORIA: Oh, wonderful. Well, thank you so much, Hans, for coming on and sharing your story with us. Do you have anything that you would like to promote?

+ +

HANS: I know we didn't get a chance to speak about it, but the children's book I've written very near and dear to my heart is called Baby Aviva, Orangutan Diva. You can get that out on Amazon, anywhere. But it's A-V-I-V-A. If you're a parent and if you have a kid under the age of five, feel free to check out our app called Pathfinder Health. And Pathfinder is just one word on the App Store and Play Store. But thank you, Will, and thank you, Victoria.

+ +

WILL: Thank you. It was great talking to you. And I'm going to go download the app.

+ +

HANS: Absolutely. Thanks so much. And I really appreciate it.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on X or Twitter [laughs] @victori_ousg or on Mastodon @thoughtbotsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+6JyMXreO + + ]]> + + Will Larry + Victoria Guido + + + 523: The Art of Leadership with Francis Lacoste + https://podcast.thoughtbot.com/523 + 4898a0f1-729e-485a-9c9b-db47db041286 + Thu, 02 May 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido chats with Francis Lacoste, a seasoned VPE and CTO coach, who recounts his unexpected journey from cinema to tech leadership and his dedication to developing engineering management talent and fostering strong organizational cultures. He delves into the psychological aspects of leadership, emphasizing the importance of psychological safety, trust, and the critical soft skills required for effective strategic leadership. + 34:19 + no + + + Host Victoria Guido connects with Francis Lacoste, a seasoned VPE and CTO coach. He details his unexpected journey from an aspiring cinema professional to a key player in the tech industry after honing his remote-first work culture skills. He delves into his move toward coaching, emphasizing his commitment to developing engineering management talent and his dedication to building strong engineering cultures and leadership within organizations. +Francis discusses the psychological aspects of leadership, such as the importance of psychological safety and the role of trust in organizational effectiveness. He also reflects on the nuances of transitioning from hands-on technical work to strategic leadership roles, emphasizing the critical soft skills necessary for effective leadership. +Follow Francis Lacoste on LinkedIn (https://www.linkedin.com/in/francislacoste/). Visit his website: thevpe.coach (https://thevpe.coach/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Francis Lacoste, VPE and CTO coach. Francis, thank you for joining me. +FRANCIS: My pleasure, Victoria. Thanks for having me. +VICTORIA: Thank you. Well, it's a beautiful spring day today. And just to get us started and warmed up a little bit, I wonder if you could tell me about what is your favorite winter activity? +FRANCIS: Cross-country skiing without doubt. I did a lot of alpine skiing when I was a kid. Could still do it, but really I found alpine, just skiing through parks and the calm of winter, is a very relaxing activity. And I use that as basically my workout. There's a park nearby the school of one of my kids. So, I drop him at school, then go do a few laps in the park near the river. It's beautiful. Unfortunately, this was a winter without almost any snow. So, I could only do four outings this year, which I need to do other workouts because that's not enough. +VICTORIA: Wow. That's really cool. How long have you been cross-country skiing then? +FRANCIS: I started doing that as a kid, but regularly only in the past, I'd say, four or five years. I bought some skis. Before that, I would only rent. So, that allowed me to do it more regularly. +VICTORIA: That's interesting. I am cross-country ski curious because I've tried regular skiing the last couple of years, and I've found that it's way too fast for me personally [laughter]. So, I'm not sure. I think I might like it. +FRANCIS: Yeah. I mean, cross-country skiing is more like jogging in a way because it's very cardio, unlike Alpine skiing, downhill skiing, where if you don't work hard, you can go very fast. You know, if you want to go slow, it's actually...you have to put in a lot of effort in downhill skiing, but cross-country skiing it's kind of like jogging. You're gliding on the snow and getting some momentum. I mean, if it's not flat, then it becomes a little bit more fiddly, but I do mostly flat courses because if you have, like, some slope, then it requires other technique, and it's actually harder to control than Alpine skiing. +VICTORIA: Ooh. Well, I was going to say it sounds like my type of thing until the last part you said there [laughter]. I was like, oh, that's the part that I'm scared of. Well, I don't know, I don't get a chance to go skiing too often down here in San Diego, but I should go up to, like, Mammoth Mountain and things like that more often. But we got a ton of snow this year, so you'll have to come West and visit us sometime. +FRANCIS: [laughs] +VICTORIA: Well, wonderful. Well, Francis, tell me a little bit about your background and what led you to your coaching career here. +FRANCIS: I've been working in software forever, basically. Fun fact: I wanted to go into cinema, and that's what I studied at university, but kept ending up in programming job basically, or programming endeavors. And this was, like, the beginning of the commercial internet, end of the '90s, and was very much into free software and open source, and that's how I got started as a software engineer. And eventually ended up at Canonical, which is still is; they celebrated their 20 years this year; the company that founded Ubuntu, the Linux distribution, which was very popular and still is to a large extent. +That's where I kind of left, transitioned into software management, engineering management over there. I didn't know at all what I was getting into. I was on parental leave at the time, and my boss left a message to say, "Hey, we're thinking of creating teams, and we think you'd be a good fit for one of the team lead. Let me know what you think." And I said, "Yes," really, not knowing that this was a totally different job. +Fortunately, I got good mentors and found out I enjoyed that. And then, after Canonical, I moved to Heroku, which I joined to help build a remote culture there because, at that point, the company was hiring more and more remote. And Canonical was a remote-first company. I mean, I've been working remotely for 25 years, almost, at this point. So, kind of had a good experience there, and at Heroku, really that, I kind of discovered coaching. +I joined as a director, and then a few years in, there was a reorg. I ended up again with a single team to manage, which was, okay, I can do that. That's fine. Fortunately, I mean, by coincidence or luck, there was a guy on the team who wanted to become an engineering manager. He was already running most of the ceremonies of the team. And I said, "Oh, great [laughs]. What I love about being a director is growing engineering managers. So, I'm going to mentor you and help you de facto run the team, do the things that you're not in a position to do yet but eventually will transition that," which left me with a lot of time. +My VP was supportive of this, and we had a lot of new first-time engineering managers at the time, so we didn't have a lot of people who had experience as engineering managers. So, I offered to mentor and coach internally. A lot of people took me up on that offer. So, I ended up doing that and eventually ended up with, like, running a large org again, but continuing doing that part. And this was the part that I kind of enjoyed the most [laughs] in my role, in a way. +So, I think it was 2019. So, five years ago, I was running seven teams. It was the largest department, engineering department at Heroku. Things were fine, you know. But when I was stopping for summer vacation or winter vacation, I realized that the day before going back to work, I was kind of not looking forward to it. That was kind of a sign. And it was very subtle because, like, a week later, everything was fine again, you know, loved the people and the company and what we were doing. But there was something, like, deep down, I was not, like, fulfilled by the role. +I did some soul searching and then realized, okay, what I really like is not running the organization but more, like, the mentoring, the nurturing of the culture. I was also doing a training at the time, working with groups, group facilitation, and so, like, working more, like, with advising leadership teams, that sort of thing. +I went to my VP and told him, "Look, I realize this is not fulfilling for me. Don't freak out. I'm not quitting [laughs] yet, you know. I can do this for a year again. But if there is...then my next role is going to be consulting around engineering culture. But if there's a role, you know, where an organization is large, more aligned with this, I'd be happy to continue working at Heroku and Salesforce," because Heroku was part of Salesforce ever since I joined. +So, he and the SVP were kind of thrilled by that idea. So, I became Chief of Staff for Heroku and start working with the whole engineering exec team. And that was great for six months. And then Salesforce did a big reorg, and I ended up...all the exec left, and Heroku engineering was kind of split apart and refactored into the normal Salesforce engineering. Fortunately for me, the EVP I had a relationship with him, and he knew what I was doing. And he took my role and said, like, "We like what you did with Heroku culture. Can you help us do that across all of platform?" So, I ended up doing culture work for one of the largest departments at Salesforce. At the time, it was 1,500 people. +It was very scary in a way, in the sense that I knew this was the next step, you know, after Heroku, but I went from 150 engineers to 150. There were more engineering managers in platform than there were engineers at Heroku. So it was kind of, okay, I need to rethink my strategy and stuff like that. +And then, that lasted until last year, and then there were the layoffs at Salesforce, and culture is one of the first thing that is usually cut. So, I got cut, which was fine because I kind of knew, okay, my next step after Salesforce was consulting around engineering culture. So, that's when I launched my business and decided to focus on coaching because that's what I had continued doing in the meantime and was finding the most fulfilling. +VICTORIA: That's really interesting. Thank you for sharing all of that context. I have a lot of questions to follow up, but to recap a little bit, it sounds like you started as a software developer. You worked your way up to engineering management and then focused on coaching other leaders throughout your career. And now you're doing that as part of your own business. So, you founded your own company to just do that, which sounds super interesting. +FRANCIS: Exactly. Yes. So, my focus is on I coach VP of engineering and CTOs at scaling startup. Like I said, I started coaching engineering managers at Heroku, and a lot of them eventually became directors. And at a large organization like Salesforce, after director, the next steps up there are a few opportunities in a way. So, you need to be at the right place at the right time, but otherwise, there's not just a lot of opportunities. +And meanwhile, they get hit every week by recruiters on LinkedIn say, "Hey, come join our startup as VP of engineering," or CTO and things like that. A lot of them actually jumped ship to such role, and I continue coaching them in that capacity. And that was really just rewarding seeing the impact that these people have. +So, last year when I started, I had a question around, okay, what is my offer? I want great engineering culture, but what is the offer? Then, looking at what I did, it's kind of, oh, well, this work I've done with all of these folks, this was always pleasurable and fulfilling to me. And coaching is a known offering, so there's probably something there. So, this was kind of what's kind of the business aspect of it. +And the mission aspect is that...and I do other things than coaching. I do workshops and things like that. But my experience is that unless the executive, you know, the founder, the top leaders are not committed and bought in in creating a great culture and personally working on themselves, because that's required, you can bring, like, workshops to the team. You can...great process in place. You can do a lot of great things, which has an impact, but then it's not built on solid ground in a way because at the first reorg or the first, like, change [inaudible 10:31], then all of this work becomes very shaky ground. So, to me, it was kind of, oh yes, I need to start with coaching the CTOs and VPs, and that will ensure that there's actually potential for a great culture there. +VICTORIA: That's really interesting. So, yeah, the coaching part is the key part and, like, the culture is number one. So, if you were talking to a new CTO, what kind of questions would you ask them to kind of gauge where they're at with their engineering culture? +FRANCIS: The first question I always ask is, well, do you have, like, principles or values around that? And it's surprising. I come from Salesforce, which is a value-driven company, and there's a lot of startups that [inaudible 11:11]. It's kind of the playbook, you know, defining your company values. But still, there's a lot of people who've done it or who've not done it or done it, but it's kind of more like an exercise, and it's not, like, integrated. +So, really, this is where usually I start when we're looking at culture is kind of what are your values, and are these values enacted, you know, manifested in your organization? Are they part of the day-to-day decision-making, the hiring process, the performance evaluation? And not just that, you know, also, when you're designing something internally, we're putting in place, like, a code review process. Well, how is that related to our values or not? +And this is something I was fortunate because Salesforce it's a huge corporation, but still, they're serious about values there. And it is used, and they are living their values, not perfectly, I mean, it's still humans, and it's still a business. But these day-to-day decision-making values are definitely taken care of, and it's not just words on the wall. +VICTORIA: Yeah. I think the second part of what you said there is the hardest part, not just what are your values, but how do you use those values in your everyday decision-making? +FRANCIS: Yes. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: I'm interested in what it takes to be a CTO and go from that startup mentality into starting to think about how you're going to scale this organization. Because what I see a lot of times a CTO in an early-stage startup is the main developer also [chuckles] and has built the whole app. So, how do you think about that? What kinds of things do you start to delve into after the values, and how a CTO can transition into that role, into the scaling and leading larger teams? +FRANCIS: Yeah, no, you're totally spot on here, Victoria, because CTO is one of these...somebody asked me once why the VPE coach and not the CTO coach. And, to me, it was, well, actually, because CTO is one of these multi-dimensional variable scope word, which means a very different thing. And often, at a startup, the CTO is basically the founding engineer. He is the person writing the code, building the product. And that's good. +But as you grow, then the role change, and many of my clients are technical co-founders who actually want to scale with the org and not become, like, a chief architect, even though many of them will still keep the CTO title. And then, they will hire a VPE to actually build the organization and do what the role of the CTO is from my perspective. +The CTO role, if we define it, it's really you're part of the exec team, and the exec team whose responsibility is to align technology to the business objective. So, can we use technology or build a product to actually deliver our product objective? So, it's kind of a strategic role, and at some point, you don't necessarily run the day-to-day of the org. But at a transition point, you need to focus on the org management and the org building. +So, I often say, one, my ideal clients are these technical co-founders who want to switch from a product builder identity to a product development organization builder identity. That's the transition point. And then, it requires all the leadership skills somebody who leads an org needs, which are, like, being able to...empathy being one of the most important one, you know, being able to understand people, to inspire them, everything like that [chuckles]. +VICTORIA: Yeah. All the easy stuff, right [chuckles]? +FRANCIS: Yes [chuckles]. Yeah. It's called the soft skills [laughs], but we all know that it's not because they're easy [laughs]. +VICTORIA: Right. Yeah, they're hard. +FRANCIS: It's actually more because they are nebulous, which is very hard for somebody who's technically minded, you know, people; it's not like there's an on and an off, and logic gate is not what this is about. +VICTORIA: Yeah. And, mentally, it must be challenging for someone who has poured their heart and soul, and time, and energy into this product to then turn around and say, "Okay, I'm going to let a bunch of other people get in there and start doing stuff [laughs]. +FRANCIS: Yes. +VICTORIA: And take it over. And, like, I'll just be involved from..." like, you know, when you say executive position, what does that mean? Is it, like, budget and strategy? And, you know, sometimes it's really hard to be effective in those conversations, and it really becomes about educating other people in your organization more than anything else. +FRANCIS: Yeah, I mean, a lot of it is about budget and that sort of thing. To me, it's more like boring, and it's not the most critical part. I mean, your role as a leader is really to set the context for the people to execute them, you know, so that they have, like, the clarity of direction but not the control of the execution. You need to let go of control. You need to move much more on the influence side than the controlling side, especially the larger the org gets. You probably have managed folks. You need to lose the idea that you're in charge and you're making the decisions because otherwise, you get frustrated very fast. +VICTORIA: Yeah. How would you refer to that? Is that like the inner game, like a mental game you have to shift into? +FRANCIS: Yeah, I mean, to me, the inner game is all about the self-awareness, emotional intelligence, developing these capacities, which enables you to be a more effective leader. It's not just about being an effective leader. It's also about feeling good about your role and who you are in this context, you know, and that's the inner game. What happens externally, how you act, is a reflection of these inner capacities in a way. +VICTORIA: That makes sense. And if you want to create a culture of psychological safety, you may want to start within yourself, right? +FRANCIS: Yes. I mean, psychological safety it's one of the essential dimension of team performance. There's the Aristotle study that was done at Google, which they analyzed Agile teams and, okay, what is the most important factor in team performance? And what they came out with is, oh, it's this thing called psychological safety. +Psychological safety as a name, as a concept was kind of coined by Amy C. Edmondson. I'm not fond of the term because I think it leads to some. I mean, it's a technical term, but because psychological safety and safety has a lot of, like, day-to-day meaning, it skews a little bit what it is. I much prefer...this is the same thing what Patrick Lencioni was calling out as the first dysfunction of a team, you know, the lack of trust. And it was defining trust as vulnerability-based trust, which goes with the technical definition of psychological safety, which is the perception that the team is safe for interpersonal risk-taking. +So, it's kind of, A, here I'm not sure how this is going to go. This is risky a bit. I'm being vulnerable. But I perceive that the team...I trust that the team will receive that respectfully in a way. And that connection to the inner game is...as a manager, if you want to create psychological safety, you need to lead by example, which means you need to show that you can be vulnerable, you know, that you trust the team that they're not going to hang you to dry if you show a weakness or say, "Hey, I don't know here," or things like that. And this is very hard as leaders because we want to instill confidence and things like that. But that often comes with, like, masking our vulnerabilities, and that's actually detrimental in fostering psychological safety. +VICTORIA: Yeah, we actually did a facilitated exercise on psychological safety at thoughtbot last year. And I brought up an idea I'd had where I wanted to see if I could say something obviously wrong on my team calls [laughter] and see if they would correct me. Like, are they going to correct me? Do they feel safe enough to, like, give me that correction? Like, you know. And I can say that my team does feel comfortable [laughs]. They crack me a lot [laughs]. +FRANCIS: Awesome. +VICTORIA: But that's great. You hire people who hopefully have, you know, expertise and security that might be greater and deeper or more recent, and yours that you have to do that. So, that's really interesting. +Talking about all the reports, it reminds me as well as, like, the DevOps research, DORA report, where they say that security as well, like, the biggest indicator for a high-security organization is trust as well. So, it's really interesting to think about, like, how you as a CTO create that culture and create that culture of, like, trust, and compassion, and empathy, and vulnerability, and that will lead to performance, which may seem counterintuitive to some people. +FRANCIS: Yeah. So, I'm kind of a model collector. I'm someone who loves different models. They're all good, you know, and that's the problem [laughs]. All models are good, but none of them actually exhaust reality. In one model, in a way, it's kind of simplification of The Five Dysfunctions Model and others. But there's two dimensions that are really important for team performance. So, the first one is kind of the, to me, this is kind of the ground, the horizontal layer. It's kind of how people relate to each other, so psychological safety. And then the vertical dimension is the clarity of the North Star and the mission. +We all can relate to each other as human beings and trust each other, but we're here to do some work. And what is this work about? What is unifying us that we're here and not someplace else? And that's kind of the clarity of what we're trying to achieve, the North Star or the mission. And those two create the space for high performance because if you just have psychological safety but there is no clear mission and accountability to that mission...once you know clearly what we're here to do, we can hold each other accountable to delivering on it. And if you're the only person holding accountability as the leader, then you're far from high performance. +Really, you get high performance when everyone is in it together. That's given by the clarity of what is it we're trying to achieve. And if that's not there, you have, like, a great group of people, but there's no direction. And if you have only direction and, you know, a mission, then you can get, like, in a very authoritarian thing, which, I mean, everybody's aligned to do something, but everybody is kind of afraid and not showing up fully. And you're not getting the full engagement of everyone, so there's a lot of heat and friction that's being lost. +VICTORIA: Yeah. And you mentioned accountability. And I'm curious, what does that look like in your experience, like, holding each other accountable? What kind of ways can leaders do that? +FRANCIS: To me, the most interesting question is how can leaders foster shared accountability on the team, mutual accountability? And how it looks like...and I'm a big fan of...it's kind of the virtuous cycle between team agreements and retrospective, you know, in agile, another word that can mean many things. But this idea of continuous improvement after every sprint or regularly the team gets together and reflects on what went well. What could we improve? Those sorts of things. This is kind of the collective space of where the teams exist as a team, you know, really kind of where there's something very important in the retrospective where we're showing up as a team and reflecting on the team. +And what I like to do is use that moment to not only, like, how do we reflect about the first layer of, okay, we missed that feature or that sort of thing but also reflect on the norms of the team, which can be written down ideally, you know? And this is a team agreement part. And the output of the retrospective is modification or experiment around "Oh, we could try this or this other way of working." But the idea of team agreements is this is how we are holding each other accountable, too. +And how it manifests in practice is you know you have, like, mutual accountability when it's not only the manager that is reminding people of, hey, this is our norm, you know? So, for instance, I don't know, example could be trivial, but still, you know, we said we need two reviews to commit code, and then, like, somebody didn't do it or something like that. The manager could go and say, "Hey, you forgot about this agreement." +But really, where you want to be is that it's other people on the team say, "Hey, Joe, why didn't you ask me for a review here? You know, I could have been that second review you needed," or things like that. And that really means that everyone is kind of bought in on the norms. So, that, to me, what is mutual accountability about is when it feels confident enough to challenge each other and remind themselves accountable to the team norms. +VICTORIA: Right. And facilitating that development of the team norms together, too, right? +FRANCIS: Yes. +VICTORIA: Wonderful. Do you have any questions for me? +FRANCIS: So, I'm interested to hear about your story this time where you got called out [laughs]. You said okay...I love the test you did, you know. I'm going to say something here that I know is wrong and see if people feel confident enough to...so, how did you achieve that, you know? +VICTORIA: Lucky for me, I don't have to test it because it just happens naturally [laughs]. So, in my role of managing director, I have to talk to clients, come up with estimates for the work, when will the work start, who is the right person for the team. And so, sometimes, you know, I'll put the proposal together, and I'll hear my team members say like, "Why are we doing it like this [laughs]? Do it this way instead. Like, I think this person's a better fit." +And, you know, when I see them engaging in the proposal and not just saying, "Yeah, it looks good," that means that we're doing a good job, and they're actually reading it, and processing it, and thinking about the client's requirements and yeah, giving me real feedback. That's what I want, so that's what I like to see. +And, you know, when I do my one on ones with my team members, at least every three months, I try to do a retrospective style where I ask, "In my role, what should I continue doing that's helping you? What should I start doing, and then what should I stop?" I do it in that order specifically, so we start with the nice stuff [laughs]. +But yeah, and then I make sure that when I give that feedback back to my team members, I say like, "Make sure you feel like you can speak up and share and hear your voice. Like, it's maybe more of a start than a stop or a continue. Just try to, like, get your feedback in there. I want to hear from you. I want to make sure you feel comfortable giving feedback to me also." +FRANCIS: Right. So, that's kind of demonstrating listening and enacting a feedback culture because you are asking for feedback and listening to it, and that fosters trust, you know, vulnerability-based trust. So, anything else you did that helped create that psychological safety on your team? +VICTORIA: It's really important how you react to things in meetings, like in retrospectives, especially if, like, you're trying to...like, in my role a lot, I'm trying to represent the business and talk to my team about what's the strategy and what we're trying to do. Like, if someone asks you a question like, "Well, why are we doing it right that way? Like, I think that's, like, what [laughs], you know, like, what are you guys even thinking? That seems random." +I think the emotional work, like you mentioned, like, taking a breath myself and, like, calming down. Because, like, part of me could get really annoyed and be like, "Well, we've been talking about this for three months, guys [chuckles], you know, like, this isn't new information." But then, you know, thinking about it, like, you know, taking the time to calm your own emotions and put yourself in their shoes and think about, well, how much time have they really had to, like, look at any of this stuff? And, like, maybe they need it in a different format, or in a different way, or, like, written up somewhere else and not just, like, briefly covered in a call. +So, opening yourself up to alternatives and staying curious about, well, what is this feeling behind? Like, what's really needed to clear? So, it's, again, coming back to listening and acting on it. So, maybe that's part of it. So, to create more psychological safety on the team is that part about managing your own emotions and not overreacting if somebody doesn't like your idea is a really important part of it. +FRANCIS: Yes, so true. You said something very interesting there, which is how you react to things. And this is true, you know, you want to be graceful in your reaction and not react from a place of frustration or anger. There's the saying that psychological safety is fragile, you know, trust can be lost easily and easy to lose. And I think this is actually, while there is some truth to it, it's actually just partially true. From my perspective, when you have psychological safety, basically, there's an anti-fragile aspect to it in the sense that you self-heal. But to self-heal, you need to recognize the breakage and heal. +So, I see the occasions where we want to be reacting gracefully listening to feedback. And then, somebody asks a question, like, say, "Why are we doing this?" You know, and then, well, because [laughs] and you answer, "Yes, well, because we've been talking for three months about this, you know, get to the page." If you stop there, yes, this is detrimental. I mean, people will say, "Oh, this was weird, and I'll think twice next time before asking that question." +But if you are committed to psychological safety, you realize that, or somebody might make you realize that. And then, you can repair saying, "Hey. Hey, sorry. I messed up here. This is really not in line with our value of listening to feedback. I'm sorry. I'm under..." and that's the healing part, and that actually strengthen psychological safety more than it was. I mean, this is the idea of antifragility, you know, a bone breaks, and when it rebuilds, it rebuilds stronger because you've shown vulnerability and kind of, okay, yes, when they make a mistake, I can see that they are able to correct in the moment. +And that's the safety part that I don't like, you know, the common day word meaning of safety that I feel is misleading is that it makes the thing...it seems very fragile. People walk on eggs. You know, we have this sentiment that, oh, I should be cautious about what I'm saying and things like that, where, actually, if you have a psychological safety culture, you can be a little bit more spontaneous and candid. And if you mess up, well, there's enough safety that you can repair and recover from there. +VICTORIA: Yeah, I actually, I mean, I did say that in the moment. And the way I recovered was that I said, "You know, I didn't want it to come across as an admonishment, like, why haven't you been listening? But more about back to our values, how can I make you all more bought into our goals from the beginning and make sure that you're connected and we're on the same page? Because it felt a little disconnected for me [laughs]," right? +But yeah, no, I like that you put it that way. Like it's also about how you repair. And I think that's true as well. When I think about whether or not you're safe with someone, it's also like, are you safe enough to tell me when I made a mistake? And the way you're going to feel safe is if someone tells you that they make a mistake, they're going to apologize, and repair, and figure out how to do better next time. +FRANCIS: Yeah, totally. +VICTORIA: And then, I think about how much my, like, leadership learning fits into my, like, regular personal life [laughs] also, right? Yeah, that's wonderful. If you could go back in time to maybe when you were that engineer about to take your engineering management position, what advice would you give yourself if you could? +FRANCIS: Hey, you do realize this is a totally different path. You're going to need to develop different skills that you add to. That was fine, you know because I kind of navigated that very seamlessly in many ways. But what I didn't highlight is that there was a transition, actually. And I think this is where the advice would come in. +So, I was an engineer, so thinking with systems and system thinking. And I realized very rapidly this is a different role. I'm not programming code anymore, you know. And what I told myself was I'm programming the system in which code is being written. And I think that's a good working metaphor or thinking for a while. And that's where the advice would come in. It's kind of, A, this is not, like, an engineering system. This is about humans. +So, in a way, I would kind of nudge myself toward developing the soft skills much more rapidly because I think it took me a while to really grok that, hey, I need to understand how to relate individually and personally to people and not just to ideas, roles, and process. Because you can have, like, an engineering perspective on management but that's lacking in empathy and...mainly the empathy [laughs]. So, do pay attention to empathy. I think that would be the fifth advice [laughs]. +VICTORIA: Isn't that great advice for all of us all the time, right [laughs]? +FRANCIS: Yes. +VICTORIA: I love that. Yeah, wonderful. +FRANCIS: I'm always happy to connect with people. You can find me on LinkedIn, Francis Lacoste. I think we don't talk to each other enough in these digital times. And so, we all network a lot, you know, on Slack and LinkedIn. And one day, I was connecting with someone on LinkedIn, and the guy offered me...said, "Hey, happy to connect. Are you interested in doing, like, a short call just to get acquainted?" And I said, "Oh, that's actually a good idea." I talked with the guy and decided to do the same thing myself. So, I'm always happy to have a conversation with folks. So, I invite you to try it out, you know, there's a lot of people out there, interesting people, and have interesting conversations. +VICTORIA: I love that so much. That's really nice. And people can do that to me, too. You can always...people talk to me, come talk to me on my podcast [laughs]. Thank you so much for being with us here today, Francis. I really enjoyed our conversation. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on thoughtbotmastodonsocial@vguido. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + Francis Lacoste, tech leadership, coaching, engineering culture, software development, cross-country skiing, remote work, Ubuntu, Heroku, Salesforce, tech management, leadership skills, psychological safety, team performance, CTO coaching, engineering management + + Host Victoria Guido connects with Francis Lacoste, a seasoned VPE and CTO coach. He details his unexpected journey from an aspiring cinema professional to a key player in the tech industry after honing his remote-first work culture skills. He delves into his move toward coaching, emphasizing his commitment to developing engineering management talent and his dedication to building strong engineering cultures and leadership within organizations.

+ +

Francis discusses the psychological aspects of leadership, such as the importance of psychological safety and the role of trust in organizational effectiveness. He also reflects on the nuances of transitioning from hands-on technical work to strategic leadership roles, emphasizing the critical soft skills necessary for effective leadership.

+ + + +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Francis Lacoste, VPE and CTO coach. Francis, thank you for joining me.

+ +

FRANCIS: My pleasure, Victoria. Thanks for having me.

+ +

VICTORIA: Thank you. Well, it's a beautiful spring day today. And just to get us started and warmed up a little bit, I wonder if you could tell me about what is your favorite winter activity?

+ +

FRANCIS: Cross-country skiing without doubt. I did a lot of alpine skiing when I was a kid. Could still do it, but really I found alpine, just skiing through parks and the calm of winter, is a very relaxing activity. And I use that as basically my workout. There's a park nearby the school of one of my kids. So, I drop him at school, then go do a few laps in the park near the river. It's beautiful. Unfortunately, this was a winter without almost any snow. So, I could only do four outings this year, which I need to do other workouts because that's not enough.

+ +

VICTORIA: Wow. That's really cool. How long have you been cross-country skiing then?

+ +

FRANCIS: I started doing that as a kid, but regularly only in the past, I'd say, four or five years. I bought some skis. Before that, I would only rent. So, that allowed me to do it more regularly.

+ +

VICTORIA: That's interesting. I am cross-country ski curious because I've tried regular skiing the last couple of years, and I've found that it's way too fast for me personally [laughter]. So, I'm not sure. I think I might like it.

+ +

FRANCIS: Yeah. I mean, cross-country skiing is more like jogging in a way because it's very cardio, unlike Alpine skiing, downhill skiing, where if you don't work hard, you can go very fast. You know, if you want to go slow, it's actually...you have to put in a lot of effort in downhill skiing, but cross-country skiing it's kind of like jogging. You're gliding on the snow and getting some momentum. I mean, if it's not flat, then it becomes a little bit more fiddly, but I do mostly flat courses because if you have, like, some slope, then it requires other technique, and it's actually harder to control than Alpine skiing.

+ +

VICTORIA: Ooh. Well, I was going to say it sounds like my type of thing until the last part you said there [laughter]. I was like, oh, that's the part that I'm scared of. Well, I don't know, I don't get a chance to go skiing too often down here in San Diego, but I should go up to, like, Mammoth Mountain and things like that more often. But we got a ton of snow this year, so you'll have to come West and visit us sometime.

+ +

FRANCIS: [laughs]

+ +

VICTORIA: Well, wonderful. Well, Francis, tell me a little bit about your background and what led you to your coaching career here.

+ +

FRANCIS: I've been working in software forever, basically. Fun fact: I wanted to go into cinema, and that's what I studied at university, but kept ending up in programming job basically, or programming endeavors. And this was, like, the beginning of the commercial internet, end of the '90s, and was very much into free software and open source, and that's how I got started as a software engineer. And eventually ended up at Canonical, which is still is; they celebrated their 20 years this year; the company that founded Ubuntu, the Linux distribution, which was very popular and still is to a large extent.

+ +

That's where I kind of left, transitioned into software management, engineering management over there. I didn't know at all what I was getting into. I was on parental leave at the time, and my boss left a message to say, "Hey, we're thinking of creating teams, and we think you'd be a good fit for one of the team lead. Let me know what you think." And I said, "Yes," really, not knowing that this was a totally different job.

+ +

Fortunately, I got good mentors and found out I enjoyed that. And then, after Canonical, I moved to Heroku, which I joined to help build a remote culture there because, at that point, the company was hiring more and more remote. And Canonical was a remote-first company. I mean, I've been working remotely for 25 years, almost, at this point. So, kind of had a good experience there, and at Heroku, really that, I kind of discovered coaching.

+ +

I joined as a director, and then a few years in, there was a reorg. I ended up again with a single team to manage, which was, okay, I can do that. That's fine. Fortunately, I mean, by coincidence or luck, there was a guy on the team who wanted to become an engineering manager. He was already running most of the ceremonies of the team. And I said, "Oh, great [laughs]. What I love about being a director is growing engineering managers. So, I'm going to mentor you and help you de facto run the team, do the things that you're not in a position to do yet but eventually will transition that," which left me with a lot of time.

+ +

My VP was supportive of this, and we had a lot of new first-time engineering managers at the time, so we didn't have a lot of people who had experience as engineering managers. So, I offered to mentor and coach internally. A lot of people took me up on that offer. So, I ended up doing that and eventually ended up with, like, running a large org again, but continuing doing that part. And this was the part that I kind of enjoyed the most [laughs] in my role, in a way.

+ +

So, I think it was 2019. So, five years ago, I was running seven teams. It was the largest department, engineering department at Heroku. Things were fine, you know. But when I was stopping for summer vacation or winter vacation, I realized that the day before going back to work, I was kind of not looking forward to it. That was kind of a sign. And it was very subtle because, like, a week later, everything was fine again, you know, loved the people and the company and what we were doing. But there was something, like, deep down, I was not, like, fulfilled by the role.

+ +

I did some soul searching and then realized, okay, what I really like is not running the organization but more, like, the mentoring, the nurturing of the culture. I was also doing a training at the time, working with groups, group facilitation, and so, like, working more, like, with advising leadership teams, that sort of thing.

+ +

I went to my VP and told him, "Look, I realize this is not fulfilling for me. Don't freak out. I'm not quitting [laughs] yet, you know. I can do this for a year again. But if there is...then my next role is going to be consulting around engineering culture. But if there's a role, you know, where an organization is large, more aligned with this, I'd be happy to continue working at Heroku and Salesforce," because Heroku was part of Salesforce ever since I joined.

+ +

So, he and the SVP were kind of thrilled by that idea. So, I became Chief of Staff for Heroku and start working with the whole engineering exec team. And that was great for six months. And then Salesforce did a big reorg, and I ended up...all the exec left, and Heroku engineering was kind of split apart and refactored into the normal Salesforce engineering. Fortunately for me, the EVP I had a relationship with him, and he knew what I was doing. And he took my role and said, like, "We like what you did with Heroku culture. Can you help us do that across all of platform?" So, I ended up doing culture work for one of the largest departments at Salesforce. At the time, it was 1,500 people.

+ +

It was very scary in a way, in the sense that I knew this was the next step, you know, after Heroku, but I went from 150 engineers to 150. There were more engineering managers in platform than there were engineers at Heroku. So it was kind of, okay, I need to rethink my strategy and stuff like that.

+ +

And then, that lasted until last year, and then there were the layoffs at Salesforce, and culture is one of the first thing that is usually cut. So, I got cut, which was fine because I kind of knew, okay, my next step after Salesforce was consulting around engineering culture. So, that's when I launched my business and decided to focus on coaching because that's what I had continued doing in the meantime and was finding the most fulfilling.

+ +

VICTORIA: That's really interesting. Thank you for sharing all of that context. I have a lot of questions to follow up, but to recap a little bit, it sounds like you started as a software developer. You worked your way up to engineering management and then focused on coaching other leaders throughout your career. And now you're doing that as part of your own business. So, you founded your own company to just do that, which sounds super interesting.

+ +

FRANCIS: Exactly. Yes. So, my focus is on I coach VP of engineering and CTOs at scaling startup. Like I said, I started coaching engineering managers at Heroku, and a lot of them eventually became directors. And at a large organization like Salesforce, after director, the next steps up there are a few opportunities in a way. So, you need to be at the right place at the right time, but otherwise, there's not just a lot of opportunities.

+ +

And meanwhile, they get hit every week by recruiters on LinkedIn say, "Hey, come join our startup as VP of engineering," or CTO and things like that. A lot of them actually jumped ship to such role, and I continue coaching them in that capacity. And that was really just rewarding seeing the impact that these people have.

+ +

So, last year when I started, I had a question around, okay, what is my offer? I want great engineering culture, but what is the offer? Then, looking at what I did, it's kind of, oh, well, this work I've done with all of these folks, this was always pleasurable and fulfilling to me. And coaching is a known offering, so there's probably something there. So, this was kind of what's kind of the business aspect of it.

+ +

And the mission aspect is that...and I do other things than coaching. I do workshops and things like that. But my experience is that unless the executive, you know, the founder, the top leaders are not committed and bought in in creating a great culture and personally working on themselves, because that's required, you can bring, like, workshops to the team. You can...great process in place. You can do a lot of great things, which has an impact, but then it's not built on solid ground in a way because at the first reorg or the first, like, change [inaudible 10:31], then all of this work becomes very shaky ground. So, to me, it was kind of, oh yes, I need to start with coaching the CTOs and VPs, and that will ensure that there's actually potential for a great culture there.

+ +

VICTORIA: That's really interesting. So, yeah, the coaching part is the key part and, like, the culture is number one. So, if you were talking to a new CTO, what kind of questions would you ask them to kind of gauge where they're at with their engineering culture?

+ +

FRANCIS: The first question I always ask is, well, do you have, like, principles or values around that? And it's surprising. I come from Salesforce, which is a value-driven company, and there's a lot of startups that [inaudible 11:11]. It's kind of the playbook, you know, defining your company values. But still, there's a lot of people who've done it or who've not done it or done it, but it's kind of more like an exercise, and it's not, like, integrated.

+ +

So, really, this is where usually I start when we're looking at culture is kind of what are your values, and are these values enacted, you know, manifested in your organization? Are they part of the day-to-day decision-making, the hiring process, the performance evaluation? And not just that, you know, also, when you're designing something internally, we're putting in place, like, a code review process. Well, how is that related to our values or not?

+ +

And this is something I was fortunate because Salesforce it's a huge corporation, but still, they're serious about values there. And it is used, and they are living their values, not perfectly, I mean, it's still humans, and it's still a business. But these day-to-day decision-making values are definitely taken care of, and it's not just words on the wall.

+ +

VICTORIA: Yeah. I think the second part of what you said there is the hardest part, not just what are your values, but how do you use those values in your everyday decision-making?

+ +

FRANCIS: Yes.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: I'm interested in what it takes to be a CTO and go from that startup mentality into starting to think about how you're going to scale this organization. Because what I see a lot of times a CTO in an early-stage startup is the main developer also [chuckles] and has built the whole app. So, how do you think about that? What kinds of things do you start to delve into after the values, and how a CTO can transition into that role, into the scaling and leading larger teams?

+ +

FRANCIS: Yeah, no, you're totally spot on here, Victoria, because CTO is one of these...somebody asked me once why the VPE coach and not the CTO coach. And, to me, it was, well, actually, because CTO is one of these multi-dimensional variable scope word, which means a very different thing. And often, at a startup, the CTO is basically the founding engineer. He is the person writing the code, building the product. And that's good.

+ +

But as you grow, then the role change, and many of my clients are technical co-founders who actually want to scale with the org and not become, like, a chief architect, even though many of them will still keep the CTO title. And then, they will hire a VPE to actually build the organization and do what the role of the CTO is from my perspective.

+ +

The CTO role, if we define it, it's really you're part of the exec team, and the exec team whose responsibility is to align technology to the business objective. So, can we use technology or build a product to actually deliver our product objective? So, it's kind of a strategic role, and at some point, you don't necessarily run the day-to-day of the org. But at a transition point, you need to focus on the org management and the org building.

+ +

So, I often say, one, my ideal clients are these technical co-founders who want to switch from a product builder identity to a product development organization builder identity. That's the transition point. And then, it requires all the leadership skills somebody who leads an org needs, which are, like, being able to...empathy being one of the most important one, you know, being able to understand people, to inspire them, everything like that [chuckles].

+ +

VICTORIA: Yeah. All the easy stuff, right [chuckles]?

+ +

FRANCIS: Yes [chuckles]. Yeah. It's called the soft skills [laughs], but we all know that it's not because they're easy [laughs].

+ +

VICTORIA: Right. Yeah, they're hard.

+ +

FRANCIS: It's actually more because they are nebulous, which is very hard for somebody who's technically minded, you know, people; it's not like there's an on and an off, and logic gate is not what this is about.

+ +

VICTORIA: Yeah. And, mentally, it must be challenging for someone who has poured their heart and soul, and time, and energy into this product to then turn around and say, "Okay, I'm going to let a bunch of other people get in there and start doing stuff [laughs].

+ +

FRANCIS: Yes.

+ +

VICTORIA: And take it over. And, like, I'll just be involved from..." like, you know, when you say executive position, what does that mean? Is it, like, budget and strategy? And, you know, sometimes it's really hard to be effective in those conversations, and it really becomes about educating other people in your organization more than anything else.

+ +

FRANCIS: Yeah, I mean, a lot of it is about budget and that sort of thing. To me, it's more like boring, and it's not the most critical part. I mean, your role as a leader is really to set the context for the people to execute them, you know, so that they have, like, the clarity of direction but not the control of the execution. You need to let go of control. You need to move much more on the influence side than the controlling side, especially the larger the org gets. You probably have managed folks. You need to lose the idea that you're in charge and you're making the decisions because otherwise, you get frustrated very fast.

+ +

VICTORIA: Yeah. How would you refer to that? Is that like the inner game, like a mental game you have to shift into?

+ +

FRANCIS: Yeah, I mean, to me, the inner game is all about the self-awareness, emotional intelligence, developing these capacities, which enables you to be a more effective leader. It's not just about being an effective leader. It's also about feeling good about your role and who you are in this context, you know, and that's the inner game. What happens externally, how you act, is a reflection of these inner capacities in a way.

+ +

VICTORIA: That makes sense. And if you want to create a culture of psychological safety, you may want to start within yourself, right?

+ +

FRANCIS: Yes. I mean, psychological safety it's one of the essential dimension of team performance. There's the Aristotle study that was done at Google, which they analyzed Agile teams and, okay, what is the most important factor in team performance? And what they came out with is, oh, it's this thing called psychological safety.

+ +

Psychological safety as a name, as a concept was kind of coined by Amy C. Edmondson. I'm not fond of the term because I think it leads to some. I mean, it's a technical term, but because psychological safety and safety has a lot of, like, day-to-day meaning, it skews a little bit what it is. I much prefer...this is the same thing what Patrick Lencioni was calling out as the first dysfunction of a team, you know, the lack of trust. And it was defining trust as vulnerability-based trust, which goes with the technical definition of psychological safety, which is the perception that the team is safe for interpersonal risk-taking.

+ +

So, it's kind of, A, here I'm not sure how this is going to go. This is risky a bit. I'm being vulnerable. But I perceive that the team...I trust that the team will receive that respectfully in a way. And that connection to the inner game is...as a manager, if you want to create psychological safety, you need to lead by example, which means you need to show that you can be vulnerable, you know, that you trust the team that they're not going to hang you to dry if you show a weakness or say, "Hey, I don't know here," or things like that. And this is very hard as leaders because we want to instill confidence and things like that. But that often comes with, like, masking our vulnerabilities, and that's actually detrimental in fostering psychological safety.

+ +

VICTORIA: Yeah, we actually did a facilitated exercise on psychological safety at thoughtbot last year. And I brought up an idea I'd had where I wanted to see if I could say something obviously wrong on my team calls [laughter] and see if they would correct me. Like, are they going to correct me? Do they feel safe enough to, like, give me that correction? Like, you know. And I can say that my team does feel comfortable [laughs]. They crack me a lot [laughs].

+ +

FRANCIS: Awesome.

+ +

VICTORIA: But that's great. You hire people who hopefully have, you know, expertise and security that might be greater and deeper or more recent, and yours that you have to do that. So, that's really interesting.

+ +

Talking about all the reports, it reminds me as well as, like, the DevOps research, DORA report, where they say that security as well, like, the biggest indicator for a high-security organization is trust as well. So, it's really interesting to think about, like, how you as a CTO create that culture and create that culture of, like, trust, and compassion, and empathy, and vulnerability, and that will lead to performance, which may seem counterintuitive to some people.

+ +

FRANCIS: Yeah. So, I'm kind of a model collector. I'm someone who loves different models. They're all good, you know, and that's the problem [laughs]. All models are good, but none of them actually exhaust reality. In one model, in a way, it's kind of simplification of The Five Dysfunctions Model and others. But there's two dimensions that are really important for team performance. So, the first one is kind of the, to me, this is kind of the ground, the horizontal layer. It's kind of how people relate to each other, so psychological safety. And then the vertical dimension is the clarity of the North Star and the mission.

+ +

We all can relate to each other as human beings and trust each other, but we're here to do some work. And what is this work about? What is unifying us that we're here and not someplace else? And that's kind of the clarity of what we're trying to achieve, the North Star or the mission. And those two create the space for high performance because if you just have psychological safety but there is no clear mission and accountability to that mission...once you know clearly what we're here to do, we can hold each other accountable to delivering on it. And if you're the only person holding accountability as the leader, then you're far from high performance.

+ +

Really, you get high performance when everyone is in it together. That's given by the clarity of what is it we're trying to achieve. And if that's not there, you have, like, a great group of people, but there's no direction. And if you have only direction and, you know, a mission, then you can get, like, in a very authoritarian thing, which, I mean, everybody's aligned to do something, but everybody is kind of afraid and not showing up fully. And you're not getting the full engagement of everyone, so there's a lot of heat and friction that's being lost.

+ +

VICTORIA: Yeah. And you mentioned accountability. And I'm curious, what does that look like in your experience, like, holding each other accountable? What kind of ways can leaders do that?

+ +

FRANCIS: To me, the most interesting question is how can leaders foster shared accountability on the team, mutual accountability? And how it looks like...and I'm a big fan of...it's kind of the virtuous cycle between team agreements and retrospective, you know, in agile, another word that can mean many things. But this idea of continuous improvement after every sprint or regularly the team gets together and reflects on what went well. What could we improve? Those sorts of things. This is kind of the collective space of where the teams exist as a team, you know, really kind of where there's something very important in the retrospective where we're showing up as a team and reflecting on the team.

+ +

And what I like to do is use that moment to not only, like, how do we reflect about the first layer of, okay, we missed that feature or that sort of thing but also reflect on the norms of the team, which can be written down ideally, you know? And this is a team agreement part. And the output of the retrospective is modification or experiment around "Oh, we could try this or this other way of working." But the idea of team agreements is this is how we are holding each other accountable, too.

+ +

And how it manifests in practice is you know you have, like, mutual accountability when it's not only the manager that is reminding people of, hey, this is our norm, you know? So, for instance, I don't know, example could be trivial, but still, you know, we said we need two reviews to commit code, and then, like, somebody didn't do it or something like that. The manager could go and say, "Hey, you forgot about this agreement."

+ +

But really, where you want to be is that it's other people on the team say, "Hey, Joe, why didn't you ask me for a review here? You know, I could have been that second review you needed," or things like that. And that really means that everyone is kind of bought in on the norms. So, that, to me, what is mutual accountability about is when it feels confident enough to challenge each other and remind themselves accountable to the team norms.

+ +

VICTORIA: Right. And facilitating that development of the team norms together, too, right?

+ +

FRANCIS: Yes.

+ +

VICTORIA: Wonderful. Do you have any questions for me?

+ +

FRANCIS: So, I'm interested to hear about your story this time where you got called out [laughs]. You said okay...I love the test you did, you know. I'm going to say something here that I know is wrong and see if people feel confident enough to...so, how did you achieve that, you know?

+ +

VICTORIA: Lucky for me, I don't have to test it because it just happens naturally [laughs]. So, in my role of managing director, I have to talk to clients, come up with estimates for the work, when will the work start, who is the right person for the team. And so, sometimes, you know, I'll put the proposal together, and I'll hear my team members say like, "Why are we doing it like this [laughs]? Do it this way instead. Like, I think this person's a better fit."

+ +

And, you know, when I see them engaging in the proposal and not just saying, "Yeah, it looks good," that means that we're doing a good job, and they're actually reading it, and processing it, and thinking about the client's requirements and yeah, giving me real feedback. That's what I want, so that's what I like to see.

+ +

And, you know, when I do my one on ones with my team members, at least every three months, I try to do a retrospective style where I ask, "In my role, what should I continue doing that's helping you? What should I start doing, and then what should I stop?" I do it in that order specifically, so we start with the nice stuff [laughs].

+ +

But yeah, and then I make sure that when I give that feedback back to my team members, I say like, "Make sure you feel like you can speak up and share and hear your voice. Like, it's maybe more of a start than a stop or a continue. Just try to, like, get your feedback in there. I want to hear from you. I want to make sure you feel comfortable giving feedback to me also."

+ +

FRANCIS: Right. So, that's kind of demonstrating listening and enacting a feedback culture because you are asking for feedback and listening to it, and that fosters trust, you know, vulnerability-based trust. So, anything else you did that helped create that psychological safety on your team?

+ +

VICTORIA: It's really important how you react to things in meetings, like in retrospectives, especially if, like, you're trying to...like, in my role a lot, I'm trying to represent the business and talk to my team about what's the strategy and what we're trying to do. Like, if someone asks you a question like, "Well, why are we doing it right that way? Like, I think that's, like, what [laughs], you know, like, what are you guys even thinking? That seems random."

+ +

I think the emotional work, like you mentioned, like, taking a breath myself and, like, calming down. Because, like, part of me could get really annoyed and be like, "Well, we've been talking about this for three months, guys [chuckles], you know, like, this isn't new information." But then, you know, thinking about it, like, you know, taking the time to calm your own emotions and put yourself in their shoes and think about, well, how much time have they really had to, like, look at any of this stuff? And, like, maybe they need it in a different format, or in a different way, or, like, written up somewhere else and not just, like, briefly covered in a call.

+ +

So, opening yourself up to alternatives and staying curious about, well, what is this feeling behind? Like, what's really needed to clear? So, it's, again, coming back to listening and acting on it. So, maybe that's part of it. So, to create more psychological safety on the team is that part about managing your own emotions and not overreacting if somebody doesn't like your idea is a really important part of it.

+ +

FRANCIS: Yes, so true. You said something very interesting there, which is how you react to things. And this is true, you know, you want to be graceful in your reaction and not react from a place of frustration or anger. There's the saying that psychological safety is fragile, you know, trust can be lost easily and easy to lose. And I think this is actually, while there is some truth to it, it's actually just partially true. From my perspective, when you have psychological safety, basically, there's an anti-fragile aspect to it in the sense that you self-heal. But to self-heal, you need to recognize the breakage and heal.

+ +

So, I see the occasions where we want to be reacting gracefully listening to feedback. And then, somebody asks a question, like, say, "Why are we doing this?" You know, and then, well, because [laughs] and you answer, "Yes, well, because we've been talking for three months about this, you know, get to the page." If you stop there, yes, this is detrimental. I mean, people will say, "Oh, this was weird, and I'll think twice next time before asking that question."

+ +

But if you are committed to psychological safety, you realize that, or somebody might make you realize that. And then, you can repair saying, "Hey. Hey, sorry. I messed up here. This is really not in line with our value of listening to feedback. I'm sorry. I'm under..." and that's the healing part, and that actually strengthen psychological safety more than it was. I mean, this is the idea of antifragility, you know, a bone breaks, and when it rebuilds, it rebuilds stronger because you've shown vulnerability and kind of, okay, yes, when they make a mistake, I can see that they are able to correct in the moment.

+ +

And that's the safety part that I don't like, you know, the common day word meaning of safety that I feel is misleading is that it makes the thing...it seems very fragile. People walk on eggs. You know, we have this sentiment that, oh, I should be cautious about what I'm saying and things like that, where, actually, if you have a psychological safety culture, you can be a little bit more spontaneous and candid. And if you mess up, well, there's enough safety that you can repair and recover from there.

+ +

VICTORIA: Yeah, I actually, I mean, I did say that in the moment. And the way I recovered was that I said, "You know, I didn't want it to come across as an admonishment, like, why haven't you been listening? But more about back to our values, how can I make you all more bought into our goals from the beginning and make sure that you're connected and we're on the same page? Because it felt a little disconnected for me [laughs]," right?

+ +

But yeah, no, I like that you put it that way. Like it's also about how you repair. And I think that's true as well. When I think about whether or not you're safe with someone, it's also like, are you safe enough to tell me when I made a mistake? And the way you're going to feel safe is if someone tells you that they make a mistake, they're going to apologize, and repair, and figure out how to do better next time.

+ +

FRANCIS: Yeah, totally.

+ +

VICTORIA: And then, I think about how much my, like, leadership learning fits into my, like, regular personal life [laughs] also, right? Yeah, that's wonderful. If you could go back in time to maybe when you were that engineer about to take your engineering management position, what advice would you give yourself if you could?

+ +

FRANCIS: Hey, you do realize this is a totally different path. You're going to need to develop different skills that you add to. That was fine, you know because I kind of navigated that very seamlessly in many ways. But what I didn't highlight is that there was a transition, actually. And I think this is where the advice would come in.

+ +

So, I was an engineer, so thinking with systems and system thinking. And I realized very rapidly this is a different role. I'm not programming code anymore, you know. And what I told myself was I'm programming the system in which code is being written. And I think that's a good working metaphor or thinking for a while. And that's where the advice would come in. It's kind of, A, this is not, like, an engineering system. This is about humans.

+ +

So, in a way, I would kind of nudge myself toward developing the soft skills much more rapidly because I think it took me a while to really grok that, hey, I need to understand how to relate individually and personally to people and not just to ideas, roles, and process. Because you can have, like, an engineering perspective on management but that's lacking in empathy and...mainly the empathy [laughs]. So, do pay attention to empathy. I think that would be the fifth advice [laughs].

+ +

VICTORIA: Isn't that great advice for all of us all the time, right [laughs]?

+ +

FRANCIS: Yes.

+ +

VICTORIA: I love that. Yeah, wonderful.

+ +

FRANCIS: I'm always happy to connect with people. You can find me on LinkedIn, Francis Lacoste. I think we don't talk to each other enough in these digital times. And so, we all network a lot, you know, on Slack and LinkedIn. And one day, I was connecting with someone on LinkedIn, and the guy offered me...said, "Hey, happy to connect. Are you interested in doing, like, a short call just to get acquainted?" And I said, "Oh, that's actually a good idea." I talked with the guy and decided to do the same thing myself. So, I'm always happy to have a conversation with folks. So, I invite you to try it out, you know, there's a lot of people out there, interesting people, and have interesting conversations.

+ +

VICTORIA: I love that so much. That's really nice. And people can do that to me, too. You can always...people talk to me, come talk to me on my podcast [laughs]. Thank you so much for being with us here today, Francis. I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on thoughtbotmastodonsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido connects with Francis Lacoste, a seasoned VPE and CTO coach. He details his unexpected journey from an aspiring cinema professional to a key player in the tech industry after honing his remote-first work culture skills. He delves into his move toward coaching, emphasizing his commitment to developing engineering management talent and his dedication to building strong engineering cultures and leadership within organizations.

+ +

Francis discusses the psychological aspects of leadership, such as the importance of psychological safety and the role of trust in organizational effectiveness. He also reflects on the nuances of transitioning from hands-on technical work to strategic leadership roles, emphasizing the critical soft skills necessary for effective leadership.

+ + + +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Francis Lacoste, VPE and CTO coach. Francis, thank you for joining me.

+ +

FRANCIS: My pleasure, Victoria. Thanks for having me.

+ +

VICTORIA: Thank you. Well, it's a beautiful spring day today. And just to get us started and warmed up a little bit, I wonder if you could tell me about what is your favorite winter activity?

+ +

FRANCIS: Cross-country skiing without doubt. I did a lot of alpine skiing when I was a kid. Could still do it, but really I found alpine, just skiing through parks and the calm of winter, is a very relaxing activity. And I use that as basically my workout. There's a park nearby the school of one of my kids. So, I drop him at school, then go do a few laps in the park near the river. It's beautiful. Unfortunately, this was a winter without almost any snow. So, I could only do four outings this year, which I need to do other workouts because that's not enough.

+ +

VICTORIA: Wow. That's really cool. How long have you been cross-country skiing then?

+ +

FRANCIS: I started doing that as a kid, but regularly only in the past, I'd say, four or five years. I bought some skis. Before that, I would only rent. So, that allowed me to do it more regularly.

+ +

VICTORIA: That's interesting. I am cross-country ski curious because I've tried regular skiing the last couple of years, and I've found that it's way too fast for me personally [laughter]. So, I'm not sure. I think I might like it.

+ +

FRANCIS: Yeah. I mean, cross-country skiing is more like jogging in a way because it's very cardio, unlike Alpine skiing, downhill skiing, where if you don't work hard, you can go very fast. You know, if you want to go slow, it's actually...you have to put in a lot of effort in downhill skiing, but cross-country skiing it's kind of like jogging. You're gliding on the snow and getting some momentum. I mean, if it's not flat, then it becomes a little bit more fiddly, but I do mostly flat courses because if you have, like, some slope, then it requires other technique, and it's actually harder to control than Alpine skiing.

+ +

VICTORIA: Ooh. Well, I was going to say it sounds like my type of thing until the last part you said there [laughter]. I was like, oh, that's the part that I'm scared of. Well, I don't know, I don't get a chance to go skiing too often down here in San Diego, but I should go up to, like, Mammoth Mountain and things like that more often. But we got a ton of snow this year, so you'll have to come West and visit us sometime.

+ +

FRANCIS: [laughs]

+ +

VICTORIA: Well, wonderful. Well, Francis, tell me a little bit about your background and what led you to your coaching career here.

+ +

FRANCIS: I've been working in software forever, basically. Fun fact: I wanted to go into cinema, and that's what I studied at university, but kept ending up in programming job basically, or programming endeavors. And this was, like, the beginning of the commercial internet, end of the '90s, and was very much into free software and open source, and that's how I got started as a software engineer. And eventually ended up at Canonical, which is still is; they celebrated their 20 years this year; the company that founded Ubuntu, the Linux distribution, which was very popular and still is to a large extent.

+ +

That's where I kind of left, transitioned into software management, engineering management over there. I didn't know at all what I was getting into. I was on parental leave at the time, and my boss left a message to say, "Hey, we're thinking of creating teams, and we think you'd be a good fit for one of the team lead. Let me know what you think." And I said, "Yes," really, not knowing that this was a totally different job.

+ +

Fortunately, I got good mentors and found out I enjoyed that. And then, after Canonical, I moved to Heroku, which I joined to help build a remote culture there because, at that point, the company was hiring more and more remote. And Canonical was a remote-first company. I mean, I've been working remotely for 25 years, almost, at this point. So, kind of had a good experience there, and at Heroku, really that, I kind of discovered coaching.

+ +

I joined as a director, and then a few years in, there was a reorg. I ended up again with a single team to manage, which was, okay, I can do that. That's fine. Fortunately, I mean, by coincidence or luck, there was a guy on the team who wanted to become an engineering manager. He was already running most of the ceremonies of the team. And I said, "Oh, great [laughs]. What I love about being a director is growing engineering managers. So, I'm going to mentor you and help you de facto run the team, do the things that you're not in a position to do yet but eventually will transition that," which left me with a lot of time.

+ +

My VP was supportive of this, and we had a lot of new first-time engineering managers at the time, so we didn't have a lot of people who had experience as engineering managers. So, I offered to mentor and coach internally. A lot of people took me up on that offer. So, I ended up doing that and eventually ended up with, like, running a large org again, but continuing doing that part. And this was the part that I kind of enjoyed the most [laughs] in my role, in a way.

+ +

So, I think it was 2019. So, five years ago, I was running seven teams. It was the largest department, engineering department at Heroku. Things were fine, you know. But when I was stopping for summer vacation or winter vacation, I realized that the day before going back to work, I was kind of not looking forward to it. That was kind of a sign. And it was very subtle because, like, a week later, everything was fine again, you know, loved the people and the company and what we were doing. But there was something, like, deep down, I was not, like, fulfilled by the role.

+ +

I did some soul searching and then realized, okay, what I really like is not running the organization but more, like, the mentoring, the nurturing of the culture. I was also doing a training at the time, working with groups, group facilitation, and so, like, working more, like, with advising leadership teams, that sort of thing.

+ +

I went to my VP and told him, "Look, I realize this is not fulfilling for me. Don't freak out. I'm not quitting [laughs] yet, you know. I can do this for a year again. But if there is...then my next role is going to be consulting around engineering culture. But if there's a role, you know, where an organization is large, more aligned with this, I'd be happy to continue working at Heroku and Salesforce," because Heroku was part of Salesforce ever since I joined.

+ +

So, he and the SVP were kind of thrilled by that idea. So, I became Chief of Staff for Heroku and start working with the whole engineering exec team. And that was great for six months. And then Salesforce did a big reorg, and I ended up...all the exec left, and Heroku engineering was kind of split apart and refactored into the normal Salesforce engineering. Fortunately for me, the EVP I had a relationship with him, and he knew what I was doing. And he took my role and said, like, "We like what you did with Heroku culture. Can you help us do that across all of platform?" So, I ended up doing culture work for one of the largest departments at Salesforce. At the time, it was 1,500 people.

+ +

It was very scary in a way, in the sense that I knew this was the next step, you know, after Heroku, but I went from 150 engineers to 150. There were more engineering managers in platform than there were engineers at Heroku. So it was kind of, okay, I need to rethink my strategy and stuff like that.

+ +

And then, that lasted until last year, and then there were the layoffs at Salesforce, and culture is one of the first thing that is usually cut. So, I got cut, which was fine because I kind of knew, okay, my next step after Salesforce was consulting around engineering culture. So, that's when I launched my business and decided to focus on coaching because that's what I had continued doing in the meantime and was finding the most fulfilling.

+ +

VICTORIA: That's really interesting. Thank you for sharing all of that context. I have a lot of questions to follow up, but to recap a little bit, it sounds like you started as a software developer. You worked your way up to engineering management and then focused on coaching other leaders throughout your career. And now you're doing that as part of your own business. So, you founded your own company to just do that, which sounds super interesting.

+ +

FRANCIS: Exactly. Yes. So, my focus is on I coach VP of engineering and CTOs at scaling startup. Like I said, I started coaching engineering managers at Heroku, and a lot of them eventually became directors. And at a large organization like Salesforce, after director, the next steps up there are a few opportunities in a way. So, you need to be at the right place at the right time, but otherwise, there's not just a lot of opportunities.

+ +

And meanwhile, they get hit every week by recruiters on LinkedIn say, "Hey, come join our startup as VP of engineering," or CTO and things like that. A lot of them actually jumped ship to such role, and I continue coaching them in that capacity. And that was really just rewarding seeing the impact that these people have.

+ +

So, last year when I started, I had a question around, okay, what is my offer? I want great engineering culture, but what is the offer? Then, looking at what I did, it's kind of, oh, well, this work I've done with all of these folks, this was always pleasurable and fulfilling to me. And coaching is a known offering, so there's probably something there. So, this was kind of what's kind of the business aspect of it.

+ +

And the mission aspect is that...and I do other things than coaching. I do workshops and things like that. But my experience is that unless the executive, you know, the founder, the top leaders are not committed and bought in in creating a great culture and personally working on themselves, because that's required, you can bring, like, workshops to the team. You can...great process in place. You can do a lot of great things, which has an impact, but then it's not built on solid ground in a way because at the first reorg or the first, like, change [inaudible 10:31], then all of this work becomes very shaky ground. So, to me, it was kind of, oh yes, I need to start with coaching the CTOs and VPs, and that will ensure that there's actually potential for a great culture there.

+ +

VICTORIA: That's really interesting. So, yeah, the coaching part is the key part and, like, the culture is number one. So, if you were talking to a new CTO, what kind of questions would you ask them to kind of gauge where they're at with their engineering culture?

+ +

FRANCIS: The first question I always ask is, well, do you have, like, principles or values around that? And it's surprising. I come from Salesforce, which is a value-driven company, and there's a lot of startups that [inaudible 11:11]. It's kind of the playbook, you know, defining your company values. But still, there's a lot of people who've done it or who've not done it or done it, but it's kind of more like an exercise, and it's not, like, integrated.

+ +

So, really, this is where usually I start when we're looking at culture is kind of what are your values, and are these values enacted, you know, manifested in your organization? Are they part of the day-to-day decision-making, the hiring process, the performance evaluation? And not just that, you know, also, when you're designing something internally, we're putting in place, like, a code review process. Well, how is that related to our values or not?

+ +

And this is something I was fortunate because Salesforce it's a huge corporation, but still, they're serious about values there. And it is used, and they are living their values, not perfectly, I mean, it's still humans, and it's still a business. But these day-to-day decision-making values are definitely taken care of, and it's not just words on the wall.

+ +

VICTORIA: Yeah. I think the second part of what you said there is the hardest part, not just what are your values, but how do you use those values in your everyday decision-making?

+ +

FRANCIS: Yes.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: I'm interested in what it takes to be a CTO and go from that startup mentality into starting to think about how you're going to scale this organization. Because what I see a lot of times a CTO in an early-stage startup is the main developer also [chuckles] and has built the whole app. So, how do you think about that? What kinds of things do you start to delve into after the values, and how a CTO can transition into that role, into the scaling and leading larger teams?

+ +

FRANCIS: Yeah, no, you're totally spot on here, Victoria, because CTO is one of these...somebody asked me once why the VPE coach and not the CTO coach. And, to me, it was, well, actually, because CTO is one of these multi-dimensional variable scope word, which means a very different thing. And often, at a startup, the CTO is basically the founding engineer. He is the person writing the code, building the product. And that's good.

+ +

But as you grow, then the role change, and many of my clients are technical co-founders who actually want to scale with the org and not become, like, a chief architect, even though many of them will still keep the CTO title. And then, they will hire a VPE to actually build the organization and do what the role of the CTO is from my perspective.

+ +

The CTO role, if we define it, it's really you're part of the exec team, and the exec team whose responsibility is to align technology to the business objective. So, can we use technology or build a product to actually deliver our product objective? So, it's kind of a strategic role, and at some point, you don't necessarily run the day-to-day of the org. But at a transition point, you need to focus on the org management and the org building.

+ +

So, I often say, one, my ideal clients are these technical co-founders who want to switch from a product builder identity to a product development organization builder identity. That's the transition point. And then, it requires all the leadership skills somebody who leads an org needs, which are, like, being able to...empathy being one of the most important one, you know, being able to understand people, to inspire them, everything like that [chuckles].

+ +

VICTORIA: Yeah. All the easy stuff, right [chuckles]?

+ +

FRANCIS: Yes [chuckles]. Yeah. It's called the soft skills [laughs], but we all know that it's not because they're easy [laughs].

+ +

VICTORIA: Right. Yeah, they're hard.

+ +

FRANCIS: It's actually more because they are nebulous, which is very hard for somebody who's technically minded, you know, people; it's not like there's an on and an off, and logic gate is not what this is about.

+ +

VICTORIA: Yeah. And, mentally, it must be challenging for someone who has poured their heart and soul, and time, and energy into this product to then turn around and say, "Okay, I'm going to let a bunch of other people get in there and start doing stuff [laughs].

+ +

FRANCIS: Yes.

+ +

VICTORIA: And take it over. And, like, I'll just be involved from..." like, you know, when you say executive position, what does that mean? Is it, like, budget and strategy? And, you know, sometimes it's really hard to be effective in those conversations, and it really becomes about educating other people in your organization more than anything else.

+ +

FRANCIS: Yeah, I mean, a lot of it is about budget and that sort of thing. To me, it's more like boring, and it's not the most critical part. I mean, your role as a leader is really to set the context for the people to execute them, you know, so that they have, like, the clarity of direction but not the control of the execution. You need to let go of control. You need to move much more on the influence side than the controlling side, especially the larger the org gets. You probably have managed folks. You need to lose the idea that you're in charge and you're making the decisions because otherwise, you get frustrated very fast.

+ +

VICTORIA: Yeah. How would you refer to that? Is that like the inner game, like a mental game you have to shift into?

+ +

FRANCIS: Yeah, I mean, to me, the inner game is all about the self-awareness, emotional intelligence, developing these capacities, which enables you to be a more effective leader. It's not just about being an effective leader. It's also about feeling good about your role and who you are in this context, you know, and that's the inner game. What happens externally, how you act, is a reflection of these inner capacities in a way.

+ +

VICTORIA: That makes sense. And if you want to create a culture of psychological safety, you may want to start within yourself, right?

+ +

FRANCIS: Yes. I mean, psychological safety it's one of the essential dimension of team performance. There's the Aristotle study that was done at Google, which they analyzed Agile teams and, okay, what is the most important factor in team performance? And what they came out with is, oh, it's this thing called psychological safety.

+ +

Psychological safety as a name, as a concept was kind of coined by Amy C. Edmondson. I'm not fond of the term because I think it leads to some. I mean, it's a technical term, but because psychological safety and safety has a lot of, like, day-to-day meaning, it skews a little bit what it is. I much prefer...this is the same thing what Patrick Lencioni was calling out as the first dysfunction of a team, you know, the lack of trust. And it was defining trust as vulnerability-based trust, which goes with the technical definition of psychological safety, which is the perception that the team is safe for interpersonal risk-taking.

+ +

So, it's kind of, A, here I'm not sure how this is going to go. This is risky a bit. I'm being vulnerable. But I perceive that the team...I trust that the team will receive that respectfully in a way. And that connection to the inner game is...as a manager, if you want to create psychological safety, you need to lead by example, which means you need to show that you can be vulnerable, you know, that you trust the team that they're not going to hang you to dry if you show a weakness or say, "Hey, I don't know here," or things like that. And this is very hard as leaders because we want to instill confidence and things like that. But that often comes with, like, masking our vulnerabilities, and that's actually detrimental in fostering psychological safety.

+ +

VICTORIA: Yeah, we actually did a facilitated exercise on psychological safety at thoughtbot last year. And I brought up an idea I'd had where I wanted to see if I could say something obviously wrong on my team calls [laughter] and see if they would correct me. Like, are they going to correct me? Do they feel safe enough to, like, give me that correction? Like, you know. And I can say that my team does feel comfortable [laughs]. They crack me a lot [laughs].

+ +

FRANCIS: Awesome.

+ +

VICTORIA: But that's great. You hire people who hopefully have, you know, expertise and security that might be greater and deeper or more recent, and yours that you have to do that. So, that's really interesting.

+ +

Talking about all the reports, it reminds me as well as, like, the DevOps research, DORA report, where they say that security as well, like, the biggest indicator for a high-security organization is trust as well. So, it's really interesting to think about, like, how you as a CTO create that culture and create that culture of, like, trust, and compassion, and empathy, and vulnerability, and that will lead to performance, which may seem counterintuitive to some people.

+ +

FRANCIS: Yeah. So, I'm kind of a model collector. I'm someone who loves different models. They're all good, you know, and that's the problem [laughs]. All models are good, but none of them actually exhaust reality. In one model, in a way, it's kind of simplification of The Five Dysfunctions Model and others. But there's two dimensions that are really important for team performance. So, the first one is kind of the, to me, this is kind of the ground, the horizontal layer. It's kind of how people relate to each other, so psychological safety. And then the vertical dimension is the clarity of the North Star and the mission.

+ +

We all can relate to each other as human beings and trust each other, but we're here to do some work. And what is this work about? What is unifying us that we're here and not someplace else? And that's kind of the clarity of what we're trying to achieve, the North Star or the mission. And those two create the space for high performance because if you just have psychological safety but there is no clear mission and accountability to that mission...once you know clearly what we're here to do, we can hold each other accountable to delivering on it. And if you're the only person holding accountability as the leader, then you're far from high performance.

+ +

Really, you get high performance when everyone is in it together. That's given by the clarity of what is it we're trying to achieve. And if that's not there, you have, like, a great group of people, but there's no direction. And if you have only direction and, you know, a mission, then you can get, like, in a very authoritarian thing, which, I mean, everybody's aligned to do something, but everybody is kind of afraid and not showing up fully. And you're not getting the full engagement of everyone, so there's a lot of heat and friction that's being lost.

+ +

VICTORIA: Yeah. And you mentioned accountability. And I'm curious, what does that look like in your experience, like, holding each other accountable? What kind of ways can leaders do that?

+ +

FRANCIS: To me, the most interesting question is how can leaders foster shared accountability on the team, mutual accountability? And how it looks like...and I'm a big fan of...it's kind of the virtuous cycle between team agreements and retrospective, you know, in agile, another word that can mean many things. But this idea of continuous improvement after every sprint or regularly the team gets together and reflects on what went well. What could we improve? Those sorts of things. This is kind of the collective space of where the teams exist as a team, you know, really kind of where there's something very important in the retrospective where we're showing up as a team and reflecting on the team.

+ +

And what I like to do is use that moment to not only, like, how do we reflect about the first layer of, okay, we missed that feature or that sort of thing but also reflect on the norms of the team, which can be written down ideally, you know? And this is a team agreement part. And the output of the retrospective is modification or experiment around "Oh, we could try this or this other way of working." But the idea of team agreements is this is how we are holding each other accountable, too.

+ +

And how it manifests in practice is you know you have, like, mutual accountability when it's not only the manager that is reminding people of, hey, this is our norm, you know? So, for instance, I don't know, example could be trivial, but still, you know, we said we need two reviews to commit code, and then, like, somebody didn't do it or something like that. The manager could go and say, "Hey, you forgot about this agreement."

+ +

But really, where you want to be is that it's other people on the team say, "Hey, Joe, why didn't you ask me for a review here? You know, I could have been that second review you needed," or things like that. And that really means that everyone is kind of bought in on the norms. So, that, to me, what is mutual accountability about is when it feels confident enough to challenge each other and remind themselves accountable to the team norms.

+ +

VICTORIA: Right. And facilitating that development of the team norms together, too, right?

+ +

FRANCIS: Yes.

+ +

VICTORIA: Wonderful. Do you have any questions for me?

+ +

FRANCIS: So, I'm interested to hear about your story this time where you got called out [laughs]. You said okay...I love the test you did, you know. I'm going to say something here that I know is wrong and see if people feel confident enough to...so, how did you achieve that, you know?

+ +

VICTORIA: Lucky for me, I don't have to test it because it just happens naturally [laughs]. So, in my role of managing director, I have to talk to clients, come up with estimates for the work, when will the work start, who is the right person for the team. And so, sometimes, you know, I'll put the proposal together, and I'll hear my team members say like, "Why are we doing it like this [laughs]? Do it this way instead. Like, I think this person's a better fit."

+ +

And, you know, when I see them engaging in the proposal and not just saying, "Yeah, it looks good," that means that we're doing a good job, and they're actually reading it, and processing it, and thinking about the client's requirements and yeah, giving me real feedback. That's what I want, so that's what I like to see.

+ +

And, you know, when I do my one on ones with my team members, at least every three months, I try to do a retrospective style where I ask, "In my role, what should I continue doing that's helping you? What should I start doing, and then what should I stop?" I do it in that order specifically, so we start with the nice stuff [laughs].

+ +

But yeah, and then I make sure that when I give that feedback back to my team members, I say like, "Make sure you feel like you can speak up and share and hear your voice. Like, it's maybe more of a start than a stop or a continue. Just try to, like, get your feedback in there. I want to hear from you. I want to make sure you feel comfortable giving feedback to me also."

+ +

FRANCIS: Right. So, that's kind of demonstrating listening and enacting a feedback culture because you are asking for feedback and listening to it, and that fosters trust, you know, vulnerability-based trust. So, anything else you did that helped create that psychological safety on your team?

+ +

VICTORIA: It's really important how you react to things in meetings, like in retrospectives, especially if, like, you're trying to...like, in my role a lot, I'm trying to represent the business and talk to my team about what's the strategy and what we're trying to do. Like, if someone asks you a question like, "Well, why are we doing it right that way? Like, I think that's, like, what [laughs], you know, like, what are you guys even thinking? That seems random."

+ +

I think the emotional work, like you mentioned, like, taking a breath myself and, like, calming down. Because, like, part of me could get really annoyed and be like, "Well, we've been talking about this for three months, guys [chuckles], you know, like, this isn't new information." But then, you know, thinking about it, like, you know, taking the time to calm your own emotions and put yourself in their shoes and think about, well, how much time have they really had to, like, look at any of this stuff? And, like, maybe they need it in a different format, or in a different way, or, like, written up somewhere else and not just, like, briefly covered in a call.

+ +

So, opening yourself up to alternatives and staying curious about, well, what is this feeling behind? Like, what's really needed to clear? So, it's, again, coming back to listening and acting on it. So, maybe that's part of it. So, to create more psychological safety on the team is that part about managing your own emotions and not overreacting if somebody doesn't like your idea is a really important part of it.

+ +

FRANCIS: Yes, so true. You said something very interesting there, which is how you react to things. And this is true, you know, you want to be graceful in your reaction and not react from a place of frustration or anger. There's the saying that psychological safety is fragile, you know, trust can be lost easily and easy to lose. And I think this is actually, while there is some truth to it, it's actually just partially true. From my perspective, when you have psychological safety, basically, there's an anti-fragile aspect to it in the sense that you self-heal. But to self-heal, you need to recognize the breakage and heal.

+ +

So, I see the occasions where we want to be reacting gracefully listening to feedback. And then, somebody asks a question, like, say, "Why are we doing this?" You know, and then, well, because [laughs] and you answer, "Yes, well, because we've been talking for three months about this, you know, get to the page." If you stop there, yes, this is detrimental. I mean, people will say, "Oh, this was weird, and I'll think twice next time before asking that question."

+ +

But if you are committed to psychological safety, you realize that, or somebody might make you realize that. And then, you can repair saying, "Hey. Hey, sorry. I messed up here. This is really not in line with our value of listening to feedback. I'm sorry. I'm under..." and that's the healing part, and that actually strengthen psychological safety more than it was. I mean, this is the idea of antifragility, you know, a bone breaks, and when it rebuilds, it rebuilds stronger because you've shown vulnerability and kind of, okay, yes, when they make a mistake, I can see that they are able to correct in the moment.

+ +

And that's the safety part that I don't like, you know, the common day word meaning of safety that I feel is misleading is that it makes the thing...it seems very fragile. People walk on eggs. You know, we have this sentiment that, oh, I should be cautious about what I'm saying and things like that, where, actually, if you have a psychological safety culture, you can be a little bit more spontaneous and candid. And if you mess up, well, there's enough safety that you can repair and recover from there.

+ +

VICTORIA: Yeah, I actually, I mean, I did say that in the moment. And the way I recovered was that I said, "You know, I didn't want it to come across as an admonishment, like, why haven't you been listening? But more about back to our values, how can I make you all more bought into our goals from the beginning and make sure that you're connected and we're on the same page? Because it felt a little disconnected for me [laughs]," right?

+ +

But yeah, no, I like that you put it that way. Like it's also about how you repair. And I think that's true as well. When I think about whether or not you're safe with someone, it's also like, are you safe enough to tell me when I made a mistake? And the way you're going to feel safe is if someone tells you that they make a mistake, they're going to apologize, and repair, and figure out how to do better next time.

+ +

FRANCIS: Yeah, totally.

+ +

VICTORIA: And then, I think about how much my, like, leadership learning fits into my, like, regular personal life [laughs] also, right? Yeah, that's wonderful. If you could go back in time to maybe when you were that engineer about to take your engineering management position, what advice would you give yourself if you could?

+ +

FRANCIS: Hey, you do realize this is a totally different path. You're going to need to develop different skills that you add to. That was fine, you know because I kind of navigated that very seamlessly in many ways. But what I didn't highlight is that there was a transition, actually. And I think this is where the advice would come in.

+ +

So, I was an engineer, so thinking with systems and system thinking. And I realized very rapidly this is a different role. I'm not programming code anymore, you know. And what I told myself was I'm programming the system in which code is being written. And I think that's a good working metaphor or thinking for a while. And that's where the advice would come in. It's kind of, A, this is not, like, an engineering system. This is about humans.

+ +

So, in a way, I would kind of nudge myself toward developing the soft skills much more rapidly because I think it took me a while to really grok that, hey, I need to understand how to relate individually and personally to people and not just to ideas, roles, and process. Because you can have, like, an engineering perspective on management but that's lacking in empathy and...mainly the empathy [laughs]. So, do pay attention to empathy. I think that would be the fifth advice [laughs].

+ +

VICTORIA: Isn't that great advice for all of us all the time, right [laughs]?

+ +

FRANCIS: Yes.

+ +

VICTORIA: I love that. Yeah, wonderful.

+ +

FRANCIS: I'm always happy to connect with people. You can find me on LinkedIn, Francis Lacoste. I think we don't talk to each other enough in these digital times. And so, we all network a lot, you know, on Slack and LinkedIn. And one day, I was connecting with someone on LinkedIn, and the guy offered me...said, "Hey, happy to connect. Are you interested in doing, like, a short call just to get acquainted?" And I said, "Oh, that's actually a good idea." I talked with the guy and decided to do the same thing myself. So, I'm always happy to have a conversation with folks. So, I invite you to try it out, you know, there's a lot of people out there, interesting people, and have interesting conversations.

+ +

VICTORIA: I love that so much. That's really nice. And people can do that to me, too. You can always...people talk to me, come talk to me on my podcast [laughs]. Thank you so much for being with us here today, Francis. I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on thoughtbotmastodonsocial@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Ko8J3B1Y + + ]]> + + Victoria Guido + + + 522: Turning Passions into Therapy with Hobi's Hamidah Nalwoga + https://podcast.thoughtbot.com/522 + aa4befb4-22e5-45d1-abf5-4adeafee9188 + Thu, 25 Apr 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido explores the intersection of hobbies and mental health therapy with Hamidah Nalwoga, founder of Hobi. Hamidah recounts her journey from costly circus school hula hooping lessons to creating Hobi, a platform that turns hobbies into tools for personal therapy and community engagement. She talks about the operational challenges of managing a dual-sided market and the broader societal impacts, emphasizing how Hobi offers affordable, creative sessions in arts, dance, and writing to foster mental well-being and tackle the mental health crisis through community support and technological innovation. + 28:51 + no + + + Host Victoria Guido discusses the therapeutic and community-building aspects of converting hobbies into mental health therapy with special guest Hamidah Nalwoga. Hamidah shares how attempting to learn hula hooping through expensive circus school lessons made her realize a need for a more accessible form of skill sharing. Meet Hobi—a platform where people can learn various skills not as a means of professionalization but for personal therapy and community building. +Hamidah explains the challenges and insights from starting Hobi, particularly the hurdles of managing a two-sided marketplace and the importance of community support in the mental health space. While aiming to foster both skill development and mental well-being by providing affordable and engaging group sessions in arts, dance, and writing therapy, the platform also offers these sessions at minimal costs. +Hamidah and Victoria also talk about the broader impacts of community-focused initiatives on mental health. With an increasing number of people facing mental health issues and lacking adequate support, platforms like Hobi are envisioned as a bridge to accessible mental health care. Sharing the value of creative expression in mental wellness, Hamidah advocates for a shift towards more community-centric and engaging therapeutic practices and highlights the potential for using innovative tech solutions to address the mental health crisis. +Hobi (https://gethobi.com/) +Follow Hobi on LinkedIn (https://www.linkedin.com/company/hobi-making-your-hobbies-therapy/), Instagram (https://www.instagram.com/hobiplatform/), or Facebook (https://www.facebook.com/Hobiplatform). +Follow Hamidah Nalwoga on LinkedIn (https://www.linkedin.com/in/hamidah-nalwoga-78143a255/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Transcript: +VICTORIA:  This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Hamidah Nalwoga, Founder of Hobi, showing you how to turn your hobbies into a form of therapy. Hamidah, thank you for joining me. +HAMIDAH: Yeah, you're welcome. Thank you so much for having me. +VICTORIA: Well, great. Well, why don't you tell me something that's going on in your world outside of work, just to intro yourself? What are your interests outside of your startup and your job? +HAMIDAH: Yeah, my interests outside of, like, work and business, I would say the biggest one is digital art. I used to be really, really into it, but then I took a break, but now I'm finding it again. So yeah, I've been doing that a lot recently. Also, I'm trying to get into, like, audible books. +VICTORIA: Ooh. +HAMIDAH: I tried reading, but I can't stand it. So, I'm back to audible books [laughs]. +VICTORIA: Oh, nice. Audible books, and you said digital art? +HAMIDAH: Yeah, digital art. +VICTORIA: What kind of digital art do you bank? +HAMIDAH: I'm using Krita. It's a software. I use, like, a Wacom tablet and draw stuff like flowers, sunsets, stuff like that. +VICTORIA: That sounds really nice. I love that. I've got a little art project myself coming up on Wednesday this week. +HAMIDAH: Aw, that's nice. +VICTORIA: I'm a big sister of, you know, Big Sister Little Sister. And so, me and my little sister are going to do these, like, oil paint by number kits. So, it's like a mentorship program in San Diego. So, it's a lot of fun for me and for my little, so yeah, I'm excited about that. +And I love your idea of your company. So, you know, a lot of people when you tell them you have a hobby, sometimes they think about, oh, you should monetize it, and you should, like, make money off of it. But I like that your take is, oh, you should make therapy out of it. You should get emotional well-being out of your hobby. So, tell me a little bit more about, like, what led you to that idea? +HAMIDAH: Originally, I wanted to learn how to hula hoop. I saw this music video, you know, and this person was, like, looking super cool, doing all these tricks, you know, like, it looked amazing to me. So, I was like, you know what? I want to be able to do that. So, that's how my journey started. I tried the YouTube videos, but it wasn't really helping me as much. I'm more of a person who learns in person, like, someone shows me what I'm doing wrong exactly. So, that's why I tried to find an in-person teacher. But I found a circus school that was charging $80 per lesson, which is just about an hour. That was, like, too expensive for me. +VICTORIA: Eight dollars for a hula hoop lesson? +HAMIDAH: Yeah. +VICTORIA: Wow. +HAMIDAH: Because they were charging, like, the rate of the circus school. Like, if you want to have any aerial lessons, hula hoop, it would all go into one thing, so it's like $80 an hour. That's why I was like, you know what? I know somebody in Boston who knows how to hula hoop enough that they could teach me how to do it. They may not be a professional hula hooper, but they can at least show me the basics. So, that's where the idea came from of trying to learn skills from your neighbor that isn't really a professional at it. +VICTORIA: So, it all circles back to hula hooping. +HAMIDAH: Exactly. Yeah. +[laughter] +VICTORIA: Well, that's awesome. It makes so much sense, right? Like, yeah, you don't necessarily need a professional circus performer to teach you how to hula hoop. There's someone who'd be willing to do it. So, yeah, so you went from that idea, and what was kind of your first step where you knew, oh, maybe I could make something out of this? How did you get there? +HAMIDAH: Yeah, and I was looking around, and I couldn't find, like, a good solution to, like, this whole skill-sharing thing. The best thing I found was Skillshare, and it was, like, an online platform where you could learn, like, animation, you know, Photoshop, that type of stuff, but it didn't really cater to, like, the softcore skills, like skating, that type of stuff. So, I was like, you know what? I'm going to do this, you know, like, be like an Uber, but for skills. +Yeah, and doing that was extremely difficult, like, resource-wise. And, like, in general, it was a very hard task to tackle. And when I went to startup forums, like, groups, they would tell me that, "You have to be specific. Like, this is not going to work because you have to worry about, like, the two-sided marketplace, you know? And if you add, like, different locations in that, it's going to be very, very difficult." +So yeah, I tried doing that for about a year, and I was seeing some growth doing, like, a few skills, mainly like art, cooking. But after a while, I started getting burnt out, mainly because I didn't really have a huge passion for that. By trade, I'm a mental health nurse. I've been one for the past five years. So, I took a break for about a month, and I was thinking, okay, what do I enjoy doing? And if it was to fail, what would I not regret spending a lot of my hours doing? And that was mental health. So, that's where the idea came to me: to make your hobbies a form of therapy. +VICTORIA: I love that. And I'm curious what else about your background helped kind of inform your ideas around the therapy side of it. +HAMIDAH: I guess this kind of goes into my background. As a nurse, I worked in this emergency room and then also inpatient psych. And I was seeing a lot of patients that come back again and again. They lack a couple of things in their environment outside of, like, a psych unit, for example. On the psych unit, they have a structure. Like, you go to group art therapy, then you talk about your feelings. You have support there around you, you know. +And then once they get discharged and back into the community, most people don't have this thing. That's probably why they're in the hospital in the first place, you know. And so, I was thinking, like, what if someone can have this type of structure on the outside without having to be in the hospital? I mean, some people do, but you have to have insurance, you know, it costs a lot of money. +So, that's where Hobi was trying to come in to be a structure, you know, like a fun thing that's not just okay...and I'm not putting down psychotherapy at all, but sometimes people don't want to talk about their feelings all the time. You know, sometimes people want to do something fun, like, while also, like, having a mental health professional around to, like, guide them. +VICTORIA: Yeah, I totally get that. Like, I had been doing some of the talk therapy, like, apps, you know, like, BetterHelp and things like that. And it was fine, but then I kind of switched to just doing the tarot deck app instead because it's more fun, and it's less, like, just deep thinking about your feelings. It's kind of, like, expressive. And I think the interesting part about your journey here and, like, what I've heard as a repeating theme so far this year on the podcast is that, like, the real answer to a lot of problems is community and having those connections between people. +HAMIDAH: Yes. +VICTORIA: And, like, I love that you're working on how can tech solve that, and how can you make it affordable for people to build those communities and have access to those support networks and structure? Let me recap a little bit. So, you wanted to learn how to hula hoop, and then you wanted to find someone to teach you, and then you wanted to build an app to get that skill sharing going, but you thought you maybe wanted to make it a little more specific. So, you wanted to kind of bring it in as, like, hobbies as therapy, and that's where you are today, right? +HAMIDAH: Yes. It was a long journey. When you say it, it sounds like it's been a couple of months, you know, but it's actually been [laughs]...it's a span of years [laughs]. +VICTORIA: So, how would you describe where you're at now in your customer discovery journey and finding your product-market fit? +HAMIDAH: Yeah, right now, I would say I have found my customer, but I am in a place where I'm making income from Hobi. It's not enough to, like, be profit. Obviously, I'm still starting out because this...I pivoted about eight months ago to go to, like, the hobbies as a form of therapy niche. And I have found some customers. I have some repeating customers, people who actually enjoy this that, like, you know, "This is actually amazing. This has helped me a lot with my life," yeah. And the way I find these people is by providing community. +VICTORIA: So, you found users through your existing community connections and through the group that you're running. Is that right? +HAMIDAH: Yeah. +VICTORIA: And so, you kind of found that, like, the traditional marketing models where you put out an ad and people click through, like, it wasn't a good enough management of expectations from, like, end to end. So, like, kind of going to the groups first and forming the connection and then being like, "We can use Hobi to facilitate this connection," worked more for you. +HAMIDAH: Yes. And also, the other thing, too, that worked for me...because, like, the issue with Hobi it's a two-sided marketplace. So, I have to worry about, like, the therapists that are going to be offering these sessions, as well as the people who are going to be paying to have the sessions. So, it was very tricky to try and balance those two sides, but I did find a medium. +Like, the key, if I was to take away from this, if I was to tell anybody the main thing to focus on, is to build, like, a strong relationship with...it doesn't have to be a lot of people. Start with one person and just make sure that you give them what they need, you know, like, they feel like this is something that's worth it to them. And then, from there, trying to replicate that if you can to a second person, and then a third person, like, something like that because you have to personalize it as much as you can. +VICTORIA: And what were some of the unique needs of therapy providers and people who would be participating in these community groups that was surprising to you when you started this process? +HAMIDAH: Was it surprising to me? I don't know if it was really surprising. When I started, I was trying to find, like, whoever needed the app the most, you know, in terms of both mentors and the student side. And I found, like, there's a lot of people out there that are trying to make money teaching what they know. I found a lot of art therapists that wanted to join Hobi, and it wasn't very difficult to do. +But I guess the tricky part or, like, the surprise that I found was not just finding someone who wants to make the money but is willing to take a loss a little bit for you or, like, for that cause. I don't know if that at all answers the question. Because I was finding people that were like, "Yes, I want to make money teaching, like, art therapy to a group of people." But then when they had a class, for example, and nobody showed up, it was, like, a huge blow to them. They're like, "No, I don't want to do this." And that was when I just started with this niche. +But then I was lucky enough to find a couple of art therapists that were willing to give it time and actually volunteer their time, like, one hour a month and just give, like, a free session or, yeah, stuff like that. And then, I noticed that over the months, now that mentor...well, like, those that I'm working with are actually now getting a profit. +VICTORIA: That's interesting, right? Because you're providing a platform. It's not a guarantee that people are going to make money right away. And you have to have a similar kind of community mindset that you're going to need to put in the time and start showing up regularly, and not everyone's going to be a good fit for that. So, that's really interesting. Yeah, I really like that. Tell us a little bit more about it. What kind of things can you get into on the app or on the website? +HAMIDAH: We offer art therapy, dance therapy, and writing therapy, or journaling, and then some cooking classes. So, those are, like, the main things I can get into. And then, for people who are new to this type of, you know, like, therapy, mental wellness, we do have a category called mental wellness skills. They can join there and learn, like, basic coping skills, emotional regulation, and stuff like that. +VICTORIA: I love that. I saw all those services, and I was like, oh, this sounds really nice [laughter]. Like, maybe I should sign up. But how do people access the app? Because I know you're trying to balance making that profit and also providing services to people who can't afford it. So, how did you strike that balance? +HAMIDAH: Yeah, I'll be super honest. I am still trying to get that balance, but, again, like I said, it depends on finding someone whose priorities fit your priorities. Like for example, I'm not going to go to an art therapist who has, like, ten years of experience used to, like, charging $200 a session and ask them, "Hey, could you join Hobi and take this huge pay cut for me [laughs]?" Like, that's not going to work out. +The balance I found through getting the right person to work with me, because, to this person, they actually see a lot of potential, and they actually are making more than they would have without Hobi. And to the user coming to the platform, they're getting someone who is very enthusiastic about what they're doing. And it's actually helping them out a lot at a fraction of the cost of what they would get elsewhere. +VICTORIA: Gotcha. Yeah. And I saw you had some different pricing points, too. You could pay just, like, per session that you wanted and join for free, or you could get, like, a regular amount of sessions per month, and things like that. Both sides of the marketplace. I love that. +Ooh. So, tell me more about, like, what's the impact that you're seeing? Now that you've gotten some traction and you're starting to see people really use it, tell me more about those stories where people are saying, "You know, it makes my life so much better." +HAMIDAH: I didn't really start seeing the impact, again, like, until a couple of months started rolling by because it would take some time, again, to get used to something. First, they go check it out. You know, they're like, "Oh, actually, this is kind of nice, you know." Then they go back again. They're like, "Oh, actually, maybe it's actually really good for me." Then, as they start using it over and over again, they start seeing the value of it, and that's what happened. +So, a lot of the good reviews that I was getting are from users who have been using it for, like, three months now. And they like it a lot, again, because of the two main reasons. The instructors are usually very enthusiastic and are wanting to help them, and they can feel that. The other thing is, like, they get a community because it is mostly, like, group sessions. +So, people have an option to do one-on-one sessions if they want with the instructors. But, usually, it's just group sessions, and the cost is the same, $5 for all the sessions. So, it's, like, very, very affordable. And people keep coming back. "I'm only paying $5. I get a group that I talk to, make some friends. I have a therapist that I can talk to, you know." It combines and adds up over a couple of months of doing it. +VICTORIA: I can imagine that'd be really stabilizing for a lot of people, especially for people who maybe aren't able or can't afford to travel in person to these types of sessions. +HAMIDAH: Yeah, I think it's stabilizing, and that's what I was keeping in mind when I was making the platform and talking with the mentors. I try to ask them to create, like, a structure to their sessions, not just, like, random, like, days, you know? +So, like, it's usually the same day every week, you know, and the same time every week. So, you know, like, okay, every Monday, I have a support group that I go to to, like, do art journaling, and then talk about how I feel, you know, like, check-in with people, they check in with me, stuff like that. +VICTORIA: That's really wonderful. And so, that's an incredible thing to be working on. So, how do you think about what success looks like for you this year or five years from now? +HAMIDAH: Yeah. What does success look like? What success would look like, for me, I would say, since this is, like, a self-funded platform and right now I am bootstrapping and I'm kind of in the negative...although I have been steadily, you know, like, the app is growing. I'm very happy for that. I'm getting more users coming back over and over again. I'm getting good reviews. I'm getting new mentors joining, so it is heading in the right trajectory, but it's, like, a slow but steady growth. And I want to keep it that way because we run into some blunders sometimes. And I can't imagine having a whole bunch of people in the app and then having a blunder, you know, and how I would deal with that. But anyway, I digress. +What success would look like, for me, is if I am in a profit margin, so, like, not being in the negatives but in the green. You know, I don't have to have, like, a lot of money, but as long as I'm not working in the negatives, that would be success for me. And in terms of the platform in general, success would look like, again, like steady growth, just keep going up, keep going up, and, hopefully, have less blunders along the way. +Like, for example, I mean, I'm sure many founders have dealt with this, especially in tech. Like, you build this platform, you know, things were going smooth, then boom, the website crashes, you know. And it's like, people get pissed off, and it's like, "What's happening?" you know. And it's a lot of stress to deal with sometimes. But in that aspect, too, success would look like having less of that happen and having more of the good stuff happen. +VICTORIA: Yeah. So, steady profits, steady performance of the application. Those are two great goals. I love it. How did you approach building the tech side of the company? And was there things from your own background that you found were helpful, or did you find people to help you with parts of it? Or how'd you do it? +HAMIDAH: That was a very huge huddle for me because my background, again, is in nursing. I don't have any friends who are in tech. I went to a pharmacy college school, like a healthcare university, so they did not have any, like, developing computer science programs. When I had this idea, I was like, how the heck am I going to do this? Because I don't have any connections. You know, I didn't even have a LinkedIn. Yeah, so it was a lot of, like, searching online. +I did get scammed twice trying to do this, but I was thankful that because of my job, I'm able to have a steady income. I was able to, like, eat up those losses and learn from my mistakes. And I found a development company that I worked with, and I've been working with for a while now, and they're very good. So, they have been helping me. Like, price-wise, they're great, and product-wise, they're also great. +VICTORIA: Yeah, it can be really hard to navigate when you don't have experience or any connections to the community. But I appreciate you sharing that because I think it's a really common story that happens to people, and not a lot of people talk about it. +HAMIDAH: Yeah. The other thing, too, that I should warn any new founders out there or people in the community as well, watch out for who you work with, you know, like, really, really do your due diligence because I learned the hard way twice. It was different times, and it was different ways that I got scammed, not the same way, but yeah, people will approach you, and they'll give you a great price point. And if you're, like, really desperate, you know, and you really don't have the money and want to see, like, the results right away, you might get sucked into it, but just always do your due diligence and try to find other options. +VICTORIA: Yeah. And, you know, talk to companies like thoughtbot who won't scam you [laughter]. But yeah, no, I'm sorry to hear. And there's, you know, don't feel bad. Also, like, those companies that do that, that's what they do, and they're really good at it, and it could happen to anybody. And same with, like, mental health, and, you know, wanting more connections and struggling with it, it sounds like you could use Hobi to find connection now and find people to help you get through that. So, I really think that's important. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +VICTORIA: [inaudible 19:28] think about, what core values drive your everyday decisions? +HAMIDAH: Do things leaner. You know, like, I saw this lecture, like, The Lean Startup. Start as lean as possible and get the fundamental idea running without having to put a lot of money into it. And then, for my core values, I would say, like, integrity, doing what makes me happy, so it doesn't feel like I'm pushing, like, a heavy rock, just doing what feels like...something that just flows. +VICTORIA: I like that. Yeah, I think The Lean Startup is really smart. And it is funny when people ask me about app ideas. Like it's so tempting to just want to go build something and just see if people like it. But the answer is always, like, "Well, go talk to people first [laughs] before you, like, spend a lot of time building something," which is a lot harder and scarier to do. And that is why I really appreciate you sharing that. +And then, I liked your values: integrity, and, like, a self-fulfillment, self-actualizing feeling, not just, like, being repetitive loops. But yeah, no, that's really nice. And then, what are the biggest challenges in your horizon that you see? +HAMIDAH: The blunders that I talked about earlier, whereby something that you didn't expect to happen happens, and something that's usually bad that you didn't expect to happen happens. That's one of the biggest challenges that I'm trying to face. Yeah, I guess, like, how do you plan for the unexpected, you know? And how do you, like, do, like, a backup plan? In case something fails, how do you handle it, you know? Stuff like that. +VICTORIA: Yeah, now you're getting into, like, resilience engineering. I love it. Yeah, you're working with your development partner. Have you all talked about service-level objectives or any kind of, like, application monitoring, or anything like that? +HAMIDAH: Yeah, we have, yeah. And when I do say blunders, I don't mean, like, the app is crashing every, like, day. It's in terms of...like, one example was what happened. We use this video calling software, and it's not with Hobi. It's through a different third-party video calling software. And we just added their API into our website. And one of the mentors was giving a session one day, and the camera just stopped working, and it happened, like, twice. And it's like, how do you deal with that? Because it's not even, like, the app itself. So, it's not my developers that are causing the issue. It's the third party that we worked with that's causing the issue, you know. +And it's like, so I had to go and find a different third-party person to work with and hope that that doesn't happen with them. Yeah, it's just, like, stuff like that. How do you predict the unpredictable? You know, like, I guess sitting down and thinking about all the bad possible things that could happen, I don't know [chuckles]. +VICTORIA: Yeah. Like, there's a balance between there are some things you could put a lot of structure and process around, and then, like, is that necessary? Like, is that the highest priority use of your time right now? Because yeah, lots of things can go wrong: APIs can break, you know, people push updates; DDoS attacks are happening more and more, ransomware attacks. There's all kinds of things that can happen that, yeah, it's pretty tough. +But I think what you've done, where you've built a really strong relationship with your service providers and with your users, will help you in the long run because everyone has issues like that. Like, no app is perfect. So, if you're providing a really good service and the majority of the time it's working, then [laughs], like, you're probably fine. It's like, when do you make that choice between, like, really investing in, like, the application monitoring piece and things like what you're kind of talking? Like, it might be a major architectural change in the app that you would have to, like, invest in. +So, that's something that I think about a lot is, like, how are leaders making these decisions? And, like, do you have someone to go to to, like, bounce ideas off of? I'm sure you have mentors in the startup community in Boston that you can, like, go to for advice on those things now. And I actually know that you know Jordyn through the Boston startup network area. How has that community been for you? +HAMIDAH: Oh, it's been good. It was a great community. I was there in the accelerator, Prepare 4 VC. I was there from July till September, and I learned a lot from them. They left their arms open. They're like, "If you ever need to come back, you can always come back. Like, we're always here; just reach out. We can always have a meeting anytime you need one." So, it's been very great. And I really, really appreciate being a part of it. +VICTORIA: That's awesome. What's the wind in your sails? What keeps you going? +HAMIDAH: I don't know if I talked about this, but I remember, like, where I faced a crash at some point where I was like, this is not working [chuckles]. Because I was like, I don't know if I can do this, you know. And that's when I sat with myself, and I was like, what do you see yourself doing forever, whereby you don't care if it pans out or not? It was this, the mental health aspect. +And I'm an artist. I like art, you know, I like creative expression. I like dancing, you know, like, with a hula hoop, like we talked about earlier. You know, I like that type of stuff. So, I was like, okay, how do I mix the two together? And this is where this came about making your hobbies therapy. And also, like, community, like, community building. It really all came together. And just knowing that I am building that slowly but steadily, that's what keeps me going. +VICTORIA: I really love that. That's really amazing. And did we talk enough about mental health on the episode? I know we wanted to really get into it a little bit about there's a mental health crisis in the United States right now, and I'm sure in other countries as well across the board. So, maybe you wanted to say a little bit more about that and how art could be a part of it. +HAMIDAH: Oh yeah, I saw this study that 1 in 5 Americans suffers from mental illness. Half of the people that have mental illness don't actually get treated, and it's for a lot of factors. And, you know, it's expensive if you don't have insurance, especially. There's no access, lack of education around it. So, it's a lot of reasons. That's where Hobi comes in, like, you know, like, it's trying to help a little bit where it can. So, in terms of, like, the financial aspect, sessions are $5. And in terms of accessibility, if you have Wi-Fi and you have a phone, you know, you can access it. And I know, like, not everybody has that, but, like, we're trying to help in that aspect. +In terms of community, there's groups, support groups on Hobi based on interests. So, if you like art, you can find an art group. And I'm not going to lie; they're not huge groups, you know? I mean, it's a new concept. It's eight months since the pivot, so it's growing. But there is people in the groups, and people chat sometimes. I remember, like, somebody had posted, like, a cry for help, and somebody else actually replied them. They were actually talking together and then helping each other out. And it made me be like, okay, you know what? I should keep going with this. Like, this is why you're doing this. +The aspect in art and mental health is it brings what is in your head on the outside, and that helps take the emotional weight off of you. The best way to explain this, for example, is with journaling. You have all these mini-thoughts going up in your head, you know, like your anxieties, your fears, all these things going on that you internalize, like, you know, you just keep pushing in the back of your head, and then you think about it all day. +But if you take the time, for example, you sit down, and you write out how you're feeling, you know, with purpose, you know, like a gratitude journal, you, like, paint what you're feeling, like, express what you're feeling, and if you do this enough, you start to see a pattern. You stop internalizing all these things, and they become an actual thing that you can look at and analyze. So, like, that's the whole point of art and mental health. Like, it helps you bring it out of your head and onto, like, a piece of paper. +VICTORIA: That's great, yeah. I think I took a psychology 101 class in college, and she's like, "If you're having circular thoughts, just, like, put them on paper, and then go to bed [laughs]." But yeah, I think that's a really beautiful way to put it. So, thank you for sharing that. Is there anything else you'd like to promote? +HAMIDAH: I'm here to talk about Hobi, and so that's what I would like to promote. You can go check out the app. We have a website and an app now. Because I'm a mental health person, you know, don't forget to take care of yourself, and don't forget to be kind to yourself. And it doesn't have to be through Hobi, but try to use art as a form of mental wellness. +My task to you, listener, is, try journaling, for example. Try [inaudible 27:46] your feelings. Try dancing out that stress and see if you feel a difference after. +VICTORIA: What a wonderful way to end the episode. Thank you so much for coming on and telling us your story and talking about Hobi. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. +And you can find me on thoughtbot.social@vguido. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + hobbies as therapy, mental health, creative hobbies, Hamidah Nalwoga, Hobi founder, therapeutic hobbies, community building, skill sharing, mental wellness, creative therapies, hobby therapy, mental health innovation, therapy through hobbies, mental health support, Hobi app, Giant Robots Podcast, health and hobbies, personal therapy, community and mental health, therapy and creativity + + Host Victoria Guido discusses the therapeutic and community-building aspects of converting hobbies into mental health therapy with special guest Hamidah Nalwoga. Hamidah shares how attempting to learn hula hooping through expensive circus school lessons made her realize a need for a more accessible form of skill sharing. Meet Hobi—a platform where people can learn various skills not as a means of professionalization but for personal therapy and community building.

+ +

Hamidah explains the challenges and insights from starting Hobi, particularly the hurdles of managing a two-sided marketplace and the importance of community support in the mental health space. While aiming to foster both skill development and mental well-being by providing affordable and engaging group sessions in arts, dance, and writing therapy, the platform also offers these sessions at minimal costs.

+ +

Hamidah and Victoria also talk about the broader impacts of community-focused initiatives on mental health. With an increasing number of people facing mental health issues and lacking adequate support, platforms like Hobi are envisioned as a bridge to accessible mental health care. Sharing the value of creative expression in mental wellness, Hamidah advocates for a shift towards more community-centric and engaging therapeutic practices and highlights the potential for using innovative tech solutions to address the mental health crisis.

+ + + +

Transcript:

+ +

VICTORIA:  This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Hamidah Nalwoga, Founder of Hobi, showing you how to turn your hobbies into a form of therapy. Hamidah, thank you for joining me.

+ +

HAMIDAH: Yeah, you're welcome. Thank you so much for having me.

+ +

VICTORIA: Well, great. Well, why don't you tell me something that's going on in your world outside of work, just to intro yourself? What are your interests outside of your startup and your job?

+ +

HAMIDAH: Yeah, my interests outside of, like, work and business, I would say the biggest one is digital art. I used to be really, really into it, but then I took a break, but now I'm finding it again. So yeah, I've been doing that a lot recently. Also, I'm trying to get into, like, audible books.

+ +

VICTORIA: Ooh.

+ +

HAMIDAH: I tried reading, but I can't stand it. So, I'm back to audible books [laughs].

+ +

VICTORIA: Oh, nice. Audible books, and you said digital art?

+ +

HAMIDAH: Yeah, digital art.

+ +

VICTORIA: What kind of digital art do you bank?

+ +

HAMIDAH: I'm using Krita. It's a software. I use, like, a Wacom tablet and draw stuff like flowers, sunsets, stuff like that.

+ +

VICTORIA: That sounds really nice. I love that. I've got a little art project myself coming up on Wednesday this week.

+ +

HAMIDAH: Aw, that's nice.

+ +

VICTORIA: I'm a big sister of, you know, Big Sister Little Sister. And so, me and my little sister are going to do these, like, oil paint by number kits. So, it's like a mentorship program in San Diego. So, it's a lot of fun for me and for my little, so yeah, I'm excited about that.

+ +

And I love your idea of your company. So, you know, a lot of people when you tell them you have a hobby, sometimes they think about, oh, you should monetize it, and you should, like, make money off of it. But I like that your take is, oh, you should make therapy out of it. You should get emotional well-being out of your hobby. So, tell me a little bit more about, like, what led you to that idea?

+ +

HAMIDAH: Originally, I wanted to learn how to hula hoop. I saw this music video, you know, and this person was, like, looking super cool, doing all these tricks, you know, like, it looked amazing to me. So, I was like, you know what? I want to be able to do that. So, that's how my journey started. I tried the YouTube videos, but it wasn't really helping me as much. I'm more of a person who learns in person, like, someone shows me what I'm doing wrong exactly. So, that's why I tried to find an in-person teacher. But I found a circus school that was charging $80 per lesson, which is just about an hour. That was, like, too expensive for me.

+ +

VICTORIA: Eight dollars for a hula hoop lesson?

+ +

HAMIDAH: Yeah.

+ +

VICTORIA: Wow.

+ +

HAMIDAH: Because they were charging, like, the rate of the circus school. Like, if you want to have any aerial lessons, hula hoop, it would all go into one thing, so it's like $80 an hour. That's why I was like, you know what? I know somebody in Boston who knows how to hula hoop enough that they could teach me how to do it. They may not be a professional hula hooper, but they can at least show me the basics. So, that's where the idea came from of trying to learn skills from your neighbor that isn't really a professional at it.

+ +

VICTORIA: So, it all circles back to hula hooping.

+ +

HAMIDAH: Exactly. Yeah.

+ +

[laughter]

+ +

VICTORIA: Well, that's awesome. It makes so much sense, right? Like, yeah, you don't necessarily need a professional circus performer to teach you how to hula hoop. There's someone who'd be willing to do it. So, yeah, so you went from that idea, and what was kind of your first step where you knew, oh, maybe I could make something out of this? How did you get there?

+ +

HAMIDAH: Yeah, and I was looking around, and I couldn't find, like, a good solution to, like, this whole skill-sharing thing. The best thing I found was Skillshare, and it was, like, an online platform where you could learn, like, animation, you know, Photoshop, that type of stuff, but it didn't really cater to, like, the softcore skills, like skating, that type of stuff. So, I was like, you know what? I'm going to do this, you know, like, be like an Uber, but for skills.

+ +

Yeah, and doing that was extremely difficult, like, resource-wise. And, like, in general, it was a very hard task to tackle. And when I went to startup forums, like, groups, they would tell me that, "You have to be specific. Like, this is not going to work because you have to worry about, like, the two-sided marketplace, you know? And if you add, like, different locations in that, it's going to be very, very difficult."

+ +

So yeah, I tried doing that for about a year, and I was seeing some growth doing, like, a few skills, mainly like art, cooking. But after a while, I started getting burnt out, mainly because I didn't really have a huge passion for that. By trade, I'm a mental health nurse. I've been one for the past five years. So, I took a break for about a month, and I was thinking, okay, what do I enjoy doing? And if it was to fail, what would I not regret spending a lot of my hours doing? And that was mental health. So, that's where the idea came to me: to make your hobbies a form of therapy.

+ +

VICTORIA: I love that. And I'm curious what else about your background helped kind of inform your ideas around the therapy side of it.

+ +

HAMIDAH: I guess this kind of goes into my background. As a nurse, I worked in this emergency room and then also inpatient psych. And I was seeing a lot of patients that come back again and again. They lack a couple of things in their environment outside of, like, a psych unit, for example. On the psych unit, they have a structure. Like, you go to group art therapy, then you talk about your feelings. You have support there around you, you know.

+ +

And then once they get discharged and back into the community, most people don't have this thing. That's probably why they're in the hospital in the first place, you know. And so, I was thinking, like, what if someone can have this type of structure on the outside without having to be in the hospital? I mean, some people do, but you have to have insurance, you know, it costs a lot of money.

+ +

So, that's where Hobi was trying to come in to be a structure, you know, like a fun thing that's not just okay...and I'm not putting down psychotherapy at all, but sometimes people don't want to talk about their feelings all the time. You know, sometimes people want to do something fun, like, while also, like, having a mental health professional around to, like, guide them.

+ +

VICTORIA: Yeah, I totally get that. Like, I had been doing some of the talk therapy, like, apps, you know, like, BetterHelp and things like that. And it was fine, but then I kind of switched to just doing the tarot deck app instead because it's more fun, and it's less, like, just deep thinking about your feelings. It's kind of, like, expressive. And I think the interesting part about your journey here and, like, what I've heard as a repeating theme so far this year on the podcast is that, like, the real answer to a lot of problems is community and having those connections between people.

+ +

HAMIDAH: Yes.

+ +

VICTORIA: And, like, I love that you're working on how can tech solve that, and how can you make it affordable for people to build those communities and have access to those support networks and structure? Let me recap a little bit. So, you wanted to learn how to hula hoop, and then you wanted to find someone to teach you, and then you wanted to build an app to get that skill sharing going, but you thought you maybe wanted to make it a little more specific. So, you wanted to kind of bring it in as, like, hobbies as therapy, and that's where you are today, right?

+ +

HAMIDAH: Yes. It was a long journey. When you say it, it sounds like it's been a couple of months, you know, but it's actually been [laughs]...it's a span of years [laughs].

+ +

VICTORIA: So, how would you describe where you're at now in your customer discovery journey and finding your product-market fit?

+ +

HAMIDAH: Yeah, right now, I would say I have found my customer, but I am in a place where I'm making income from Hobi. It's not enough to, like, be profit. Obviously, I'm still starting out because this...I pivoted about eight months ago to go to, like, the hobbies as a form of therapy niche. And I have found some customers. I have some repeating customers, people who actually enjoy this that, like, you know, "This is actually amazing. This has helped me a lot with my life," yeah. And the way I find these people is by providing community.

+ +

VICTORIA: So, you found users through your existing community connections and through the group that you're running. Is that right?

+ +

HAMIDAH: Yeah.

+ +

VICTORIA: And so, you kind of found that, like, the traditional marketing models where you put out an ad and people click through, like, it wasn't a good enough management of expectations from, like, end to end. So, like, kind of going to the groups first and forming the connection and then being like, "We can use Hobi to facilitate this connection," worked more for you.

+ +

HAMIDAH: Yes. And also, the other thing, too, that worked for me...because, like, the issue with Hobi it's a two-sided marketplace. So, I have to worry about, like, the therapists that are going to be offering these sessions, as well as the people who are going to be paying to have the sessions. So, it was very tricky to try and balance those two sides, but I did find a medium.

+ +

Like, the key, if I was to take away from this, if I was to tell anybody the main thing to focus on, is to build, like, a strong relationship with...it doesn't have to be a lot of people. Start with one person and just make sure that you give them what they need, you know, like, they feel like this is something that's worth it to them. And then, from there, trying to replicate that if you can to a second person, and then a third person, like, something like that because you have to personalize it as much as you can.

+ +

VICTORIA: And what were some of the unique needs of therapy providers and people who would be participating in these community groups that was surprising to you when you started this process?

+ +

HAMIDAH: Was it surprising to me? I don't know if it was really surprising. When I started, I was trying to find, like, whoever needed the app the most, you know, in terms of both mentors and the student side. And I found, like, there's a lot of people out there that are trying to make money teaching what they know. I found a lot of art therapists that wanted to join Hobi, and it wasn't very difficult to do.

+ +

But I guess the tricky part or, like, the surprise that I found was not just finding someone who wants to make the money but is willing to take a loss a little bit for you or, like, for that cause. I don't know if that at all answers the question. Because I was finding people that were like, "Yes, I want to make money teaching, like, art therapy to a group of people." But then when they had a class, for example, and nobody showed up, it was, like, a huge blow to them. They're like, "No, I don't want to do this." And that was when I just started with this niche.

+ +

But then I was lucky enough to find a couple of art therapists that were willing to give it time and actually volunteer their time, like, one hour a month and just give, like, a free session or, yeah, stuff like that. And then, I noticed that over the months, now that mentor...well, like, those that I'm working with are actually now getting a profit.

+ +

VICTORIA: That's interesting, right? Because you're providing a platform. It's not a guarantee that people are going to make money right away. And you have to have a similar kind of community mindset that you're going to need to put in the time and start showing up regularly, and not everyone's going to be a good fit for that. So, that's really interesting. Yeah, I really like that. Tell us a little bit more about it. What kind of things can you get into on the app or on the website?

+ +

HAMIDAH: We offer art therapy, dance therapy, and writing therapy, or journaling, and then some cooking classes. So, those are, like, the main things I can get into. And then, for people who are new to this type of, you know, like, therapy, mental wellness, we do have a category called mental wellness skills. They can join there and learn, like, basic coping skills, emotional regulation, and stuff like that.

+ +

VICTORIA: I love that. I saw all those services, and I was like, oh, this sounds really nice [laughter]. Like, maybe I should sign up. But how do people access the app? Because I know you're trying to balance making that profit and also providing services to people who can't afford it. So, how did you strike that balance?

+ +

HAMIDAH: Yeah, I'll be super honest. I am still trying to get that balance, but, again, like I said, it depends on finding someone whose priorities fit your priorities. Like for example, I'm not going to go to an art therapist who has, like, ten years of experience used to, like, charging $200 a session and ask them, "Hey, could you join Hobi and take this huge pay cut for me [laughs]?" Like, that's not going to work out.

+ +

The balance I found through getting the right person to work with me, because, to this person, they actually see a lot of potential, and they actually are making more than they would have without Hobi. And to the user coming to the platform, they're getting someone who is very enthusiastic about what they're doing. And it's actually helping them out a lot at a fraction of the cost of what they would get elsewhere.

+ +

VICTORIA: Gotcha. Yeah. And I saw you had some different pricing points, too. You could pay just, like, per session that you wanted and join for free, or you could get, like, a regular amount of sessions per month, and things like that. Both sides of the marketplace. I love that.

+ +

Ooh. So, tell me more about, like, what's the impact that you're seeing? Now that you've gotten some traction and you're starting to see people really use it, tell me more about those stories where people are saying, "You know, it makes my life so much better."

+ +

HAMIDAH: I didn't really start seeing the impact, again, like, until a couple of months started rolling by because it would take some time, again, to get used to something. First, they go check it out. You know, they're like, "Oh, actually, this is kind of nice, you know." Then they go back again. They're like, "Oh, actually, maybe it's actually really good for me." Then, as they start using it over and over again, they start seeing the value of it, and that's what happened.

+ +

So, a lot of the good reviews that I was getting are from users who have been using it for, like, three months now. And they like it a lot, again, because of the two main reasons. The instructors are usually very enthusiastic and are wanting to help them, and they can feel that. The other thing is, like, they get a community because it is mostly, like, group sessions.

+ +

So, people have an option to do one-on-one sessions if they want with the instructors. But, usually, it's just group sessions, and the cost is the same, $5 for all the sessions. So, it's, like, very, very affordable. And people keep coming back. "I'm only paying $5. I get a group that I talk to, make some friends. I have a therapist that I can talk to, you know." It combines and adds up over a couple of months of doing it.

+ +

VICTORIA: I can imagine that'd be really stabilizing for a lot of people, especially for people who maybe aren't able or can't afford to travel in person to these types of sessions.

+ +

HAMIDAH: Yeah, I think it's stabilizing, and that's what I was keeping in mind when I was making the platform and talking with the mentors. I try to ask them to create, like, a structure to their sessions, not just, like, random, like, days, you know?

+ +

So, like, it's usually the same day every week, you know, and the same time every week. So, you know, like, okay, every Monday, I have a support group that I go to to, like, do art journaling, and then talk about how I feel, you know, like, check-in with people, they check in with me, stuff like that.

+ +

VICTORIA: That's really wonderful. And so, that's an incredible thing to be working on. So, how do you think about what success looks like for you this year or five years from now?

+ +

HAMIDAH: Yeah. What does success look like? What success would look like, for me, I would say, since this is, like, a self-funded platform and right now I am bootstrapping and I'm kind of in the negative...although I have been steadily, you know, like, the app is growing. I'm very happy for that. I'm getting more users coming back over and over again. I'm getting good reviews. I'm getting new mentors joining, so it is heading in the right trajectory, but it's, like, a slow but steady growth. And I want to keep it that way because we run into some blunders sometimes. And I can't imagine having a whole bunch of people in the app and then having a blunder, you know, and how I would deal with that. But anyway, I digress.

+ +

What success would look like, for me, is if I am in a profit margin, so, like, not being in the negatives but in the green. You know, I don't have to have, like, a lot of money, but as long as I'm not working in the negatives, that would be success for me. And in terms of the platform in general, success would look like, again, like steady growth, just keep going up, keep going up, and, hopefully, have less blunders along the way.

+ +

Like, for example, I mean, I'm sure many founders have dealt with this, especially in tech. Like, you build this platform, you know, things were going smooth, then boom, the website crashes, you know. And it's like, people get pissed off, and it's like, "What's happening?" you know. And it's a lot of stress to deal with sometimes. But in that aspect, too, success would look like having less of that happen and having more of the good stuff happen.

+ +

VICTORIA: Yeah. So, steady profits, steady performance of the application. Those are two great goals. I love it. How did you approach building the tech side of the company? And was there things from your own background that you found were helpful, or did you find people to help you with parts of it? Or how'd you do it?

+ +

HAMIDAH: That was a very huge huddle for me because my background, again, is in nursing. I don't have any friends who are in tech. I went to a pharmacy college school, like a healthcare university, so they did not have any, like, developing computer science programs. When I had this idea, I was like, how the heck am I going to do this? Because I don't have any connections. You know, I didn't even have a LinkedIn. Yeah, so it was a lot of, like, searching online.

+ +

I did get scammed twice trying to do this, but I was thankful that because of my job, I'm able to have a steady income. I was able to, like, eat up those losses and learn from my mistakes. And I found a development company that I worked with, and I've been working with for a while now, and they're very good. So, they have been helping me. Like, price-wise, they're great, and product-wise, they're also great.

+ +

VICTORIA: Yeah, it can be really hard to navigate when you don't have experience or any connections to the community. But I appreciate you sharing that because I think it's a really common story that happens to people, and not a lot of people talk about it.

+ +

HAMIDAH: Yeah. The other thing, too, that I should warn any new founders out there or people in the community as well, watch out for who you work with, you know, like, really, really do your due diligence because I learned the hard way twice. It was different times, and it was different ways that I got scammed, not the same way, but yeah, people will approach you, and they'll give you a great price point. And if you're, like, really desperate, you know, and you really don't have the money and want to see, like, the results right away, you might get sucked into it, but just always do your due diligence and try to find other options.

+ +

VICTORIA: Yeah. And, you know, talk to companies like thoughtbot who won't scam you [laughter]. But yeah, no, I'm sorry to hear. And there's, you know, don't feel bad. Also, like, those companies that do that, that's what they do, and they're really good at it, and it could happen to anybody. And same with, like, mental health, and, you know, wanting more connections and struggling with it, it sounds like you could use Hobi to find connection now and find people to help you get through that. So, I really think that's important.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: [inaudible 19:28] think about, what core values drive your everyday decisions?

+ +

HAMIDAH: Do things leaner. You know, like, I saw this lecture, like, The Lean Startup. Start as lean as possible and get the fundamental idea running without having to put a lot of money into it. And then, for my core values, I would say, like, integrity, doing what makes me happy, so it doesn't feel like I'm pushing, like, a heavy rock, just doing what feels like...something that just flows.

+ +

VICTORIA: I like that. Yeah, I think The Lean Startup is really smart. And it is funny when people ask me about app ideas. Like it's so tempting to just want to go build something and just see if people like it. But the answer is always, like, "Well, go talk to people first [laughs] before you, like, spend a lot of time building something," which is a lot harder and scarier to do. And that is why I really appreciate you sharing that.

+ +

And then, I liked your values: integrity, and, like, a self-fulfillment, self-actualizing feeling, not just, like, being repetitive loops. But yeah, no, that's really nice. And then, what are the biggest challenges in your horizon that you see?

+ +

HAMIDAH: The blunders that I talked about earlier, whereby something that you didn't expect to happen happens, and something that's usually bad that you didn't expect to happen happens. That's one of the biggest challenges that I'm trying to face. Yeah, I guess, like, how do you plan for the unexpected, you know? And how do you, like, do, like, a backup plan? In case something fails, how do you handle it, you know? Stuff like that.

+ +

VICTORIA: Yeah, now you're getting into, like, resilience engineering. I love it. Yeah, you're working with your development partner. Have you all talked about service-level objectives or any kind of, like, application monitoring, or anything like that?

+ +

HAMIDAH: Yeah, we have, yeah. And when I do say blunders, I don't mean, like, the app is crashing every, like, day. It's in terms of...like, one example was what happened. We use this video calling software, and it's not with Hobi. It's through a different third-party video calling software. And we just added their API into our website. And one of the mentors was giving a session one day, and the camera just stopped working, and it happened, like, twice. And it's like, how do you deal with that? Because it's not even, like, the app itself. So, it's not my developers that are causing the issue. It's the third party that we worked with that's causing the issue, you know.

+ +

And it's like, so I had to go and find a different third-party person to work with and hope that that doesn't happen with them. Yeah, it's just, like, stuff like that. How do you predict the unpredictable? You know, like, I guess sitting down and thinking about all the bad possible things that could happen, I don't know [chuckles].

+ +

VICTORIA: Yeah. Like, there's a balance between there are some things you could put a lot of structure and process around, and then, like, is that necessary? Like, is that the highest priority use of your time right now? Because yeah, lots of things can go wrong: APIs can break, you know, people push updates; DDoS attacks are happening more and more, ransomware attacks. There's all kinds of things that can happen that, yeah, it's pretty tough.

+ +

But I think what you've done, where you've built a really strong relationship with your service providers and with your users, will help you in the long run because everyone has issues like that. Like, no app is perfect. So, if you're providing a really good service and the majority of the time it's working, then [laughs], like, you're probably fine. It's like, when do you make that choice between, like, really investing in, like, the application monitoring piece and things like what you're kind of talking? Like, it might be a major architectural change in the app that you would have to, like, invest in.

+ +

So, that's something that I think about a lot is, like, how are leaders making these decisions? And, like, do you have someone to go to to, like, bounce ideas off of? I'm sure you have mentors in the startup community in Boston that you can, like, go to for advice on those things now. And I actually know that you know Jordyn through the Boston startup network area. How has that community been for you?

+ +

HAMIDAH: Oh, it's been good. It was a great community. I was there in the accelerator, Prepare 4 VC. I was there from July till September, and I learned a lot from them. They left their arms open. They're like, "If you ever need to come back, you can always come back. Like, we're always here; just reach out. We can always have a meeting anytime you need one." So, it's been very great. And I really, really appreciate being a part of it.

+ +

VICTORIA: That's awesome. What's the wind in your sails? What keeps you going?

+ +

HAMIDAH: I don't know if I talked about this, but I remember, like, where I faced a crash at some point where I was like, this is not working [chuckles]. Because I was like, I don't know if I can do this, you know. And that's when I sat with myself, and I was like, what do you see yourself doing forever, whereby you don't care if it pans out or not? It was this, the mental health aspect.

+ +

And I'm an artist. I like art, you know, I like creative expression. I like dancing, you know, like, with a hula hoop, like we talked about earlier. You know, I like that type of stuff. So, I was like, okay, how do I mix the two together? And this is where this came about making your hobbies therapy. And also, like, community, like, community building. It really all came together. And just knowing that I am building that slowly but steadily, that's what keeps me going.

+ +

VICTORIA: I really love that. That's really amazing. And did we talk enough about mental health on the episode? I know we wanted to really get into it a little bit about there's a mental health crisis in the United States right now, and I'm sure in other countries as well across the board. So, maybe you wanted to say a little bit more about that and how art could be a part of it.

+ +

HAMIDAH: Oh yeah, I saw this study that 1 in 5 Americans suffers from mental illness. Half of the people that have mental illness don't actually get treated, and it's for a lot of factors. And, you know, it's expensive if you don't have insurance, especially. There's no access, lack of education around it. So, it's a lot of reasons. That's where Hobi comes in, like, you know, like, it's trying to help a little bit where it can. So, in terms of, like, the financial aspect, sessions are $5. And in terms of accessibility, if you have Wi-Fi and you have a phone, you know, you can access it. And I know, like, not everybody has that, but, like, we're trying to help in that aspect.

+ +

In terms of community, there's groups, support groups on Hobi based on interests. So, if you like art, you can find an art group. And I'm not going to lie; they're not huge groups, you know? I mean, it's a new concept. It's eight months since the pivot, so it's growing. But there is people in the groups, and people chat sometimes. I remember, like, somebody had posted, like, a cry for help, and somebody else actually replied them. They were actually talking together and then helping each other out. And it made me be like, okay, you know what? I should keep going with this. Like, this is why you're doing this.

+ +

The aspect in art and mental health is it brings what is in your head on the outside, and that helps take the emotional weight off of you. The best way to explain this, for example, is with journaling. You have all these mini-thoughts going up in your head, you know, like your anxieties, your fears, all these things going on that you internalize, like, you know, you just keep pushing in the back of your head, and then you think about it all day.

+ +

But if you take the time, for example, you sit down, and you write out how you're feeling, you know, with purpose, you know, like a gratitude journal, you, like, paint what you're feeling, like, express what you're feeling, and if you do this enough, you start to see a pattern. You stop internalizing all these things, and they become an actual thing that you can look at and analyze. So, like, that's the whole point of art and mental health. Like, it helps you bring it out of your head and onto, like, a piece of paper.

+ +

VICTORIA: That's great, yeah. I think I took a psychology 101 class in college, and she's like, "If you're having circular thoughts, just, like, put them on paper, and then go to bed [laughs]." But yeah, I think that's a really beautiful way to put it. So, thank you for sharing that. Is there anything else you'd like to promote?

+ +

HAMIDAH: I'm here to talk about Hobi, and so that's what I would like to promote. You can go check out the app. We have a website and an app now. Because I'm a mental health person, you know, don't forget to take care of yourself, and don't forget to be kind to yourself. And it doesn't have to be through Hobi, but try to use art as a form of mental wellness.

+ +

My task to you, listener, is, try journaling, for example. Try [inaudible 27:46] your feelings. Try dancing out that stress and see if you feel a difference after.

+ +

VICTORIA: What a wonderful way to end the episode. Thank you so much for coming on and telling us your story and talking about Hobi.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

And you can find me on thoughtbot.social@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido discusses the therapeutic and community-building aspects of converting hobbies into mental health therapy with special guest Hamidah Nalwoga. Hamidah shares how attempting to learn hula hooping through expensive circus school lessons made her realize a need for a more accessible form of skill sharing. Meet Hobi—a platform where people can learn various skills not as a means of professionalization but for personal therapy and community building.

+ +

Hamidah explains the challenges and insights from starting Hobi, particularly the hurdles of managing a two-sided marketplace and the importance of community support in the mental health space. While aiming to foster both skill development and mental well-being by providing affordable and engaging group sessions in arts, dance, and writing therapy, the platform also offers these sessions at minimal costs.

+ +

Hamidah and Victoria also talk about the broader impacts of community-focused initiatives on mental health. With an increasing number of people facing mental health issues and lacking adequate support, platforms like Hobi are envisioned as a bridge to accessible mental health care. Sharing the value of creative expression in mental wellness, Hamidah advocates for a shift towards more community-centric and engaging therapeutic practices and highlights the potential for using innovative tech solutions to address the mental health crisis.

+ + + +

Transcript:

+ +

VICTORIA:  This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Hamidah Nalwoga, Founder of Hobi, showing you how to turn your hobbies into a form of therapy. Hamidah, thank you for joining me.

+ +

HAMIDAH: Yeah, you're welcome. Thank you so much for having me.

+ +

VICTORIA: Well, great. Well, why don't you tell me something that's going on in your world outside of work, just to intro yourself? What are your interests outside of your startup and your job?

+ +

HAMIDAH: Yeah, my interests outside of, like, work and business, I would say the biggest one is digital art. I used to be really, really into it, but then I took a break, but now I'm finding it again. So yeah, I've been doing that a lot recently. Also, I'm trying to get into, like, audible books.

+ +

VICTORIA: Ooh.

+ +

HAMIDAH: I tried reading, but I can't stand it. So, I'm back to audible books [laughs].

+ +

VICTORIA: Oh, nice. Audible books, and you said digital art?

+ +

HAMIDAH: Yeah, digital art.

+ +

VICTORIA: What kind of digital art do you bank?

+ +

HAMIDAH: I'm using Krita. It's a software. I use, like, a Wacom tablet and draw stuff like flowers, sunsets, stuff like that.

+ +

VICTORIA: That sounds really nice. I love that. I've got a little art project myself coming up on Wednesday this week.

+ +

HAMIDAH: Aw, that's nice.

+ +

VICTORIA: I'm a big sister of, you know, Big Sister Little Sister. And so, me and my little sister are going to do these, like, oil paint by number kits. So, it's like a mentorship program in San Diego. So, it's a lot of fun for me and for my little, so yeah, I'm excited about that.

+ +

And I love your idea of your company. So, you know, a lot of people when you tell them you have a hobby, sometimes they think about, oh, you should monetize it, and you should, like, make money off of it. But I like that your take is, oh, you should make therapy out of it. You should get emotional well-being out of your hobby. So, tell me a little bit more about, like, what led you to that idea?

+ +

HAMIDAH: Originally, I wanted to learn how to hula hoop. I saw this music video, you know, and this person was, like, looking super cool, doing all these tricks, you know, like, it looked amazing to me. So, I was like, you know what? I want to be able to do that. So, that's how my journey started. I tried the YouTube videos, but it wasn't really helping me as much. I'm more of a person who learns in person, like, someone shows me what I'm doing wrong exactly. So, that's why I tried to find an in-person teacher. But I found a circus school that was charging $80 per lesson, which is just about an hour. That was, like, too expensive for me.

+ +

VICTORIA: Eight dollars for a hula hoop lesson?

+ +

HAMIDAH: Yeah.

+ +

VICTORIA: Wow.

+ +

HAMIDAH: Because they were charging, like, the rate of the circus school. Like, if you want to have any aerial lessons, hula hoop, it would all go into one thing, so it's like $80 an hour. That's why I was like, you know what? I know somebody in Boston who knows how to hula hoop enough that they could teach me how to do it. They may not be a professional hula hooper, but they can at least show me the basics. So, that's where the idea came from of trying to learn skills from your neighbor that isn't really a professional at it.

+ +

VICTORIA: So, it all circles back to hula hooping.

+ +

HAMIDAH: Exactly. Yeah.

+ +

[laughter]

+ +

VICTORIA: Well, that's awesome. It makes so much sense, right? Like, yeah, you don't necessarily need a professional circus performer to teach you how to hula hoop. There's someone who'd be willing to do it. So, yeah, so you went from that idea, and what was kind of your first step where you knew, oh, maybe I could make something out of this? How did you get there?

+ +

HAMIDAH: Yeah, and I was looking around, and I couldn't find, like, a good solution to, like, this whole skill-sharing thing. The best thing I found was Skillshare, and it was, like, an online platform where you could learn, like, animation, you know, Photoshop, that type of stuff, but it didn't really cater to, like, the softcore skills, like skating, that type of stuff. So, I was like, you know what? I'm going to do this, you know, like, be like an Uber, but for skills.

+ +

Yeah, and doing that was extremely difficult, like, resource-wise. And, like, in general, it was a very hard task to tackle. And when I went to startup forums, like, groups, they would tell me that, "You have to be specific. Like, this is not going to work because you have to worry about, like, the two-sided marketplace, you know? And if you add, like, different locations in that, it's going to be very, very difficult."

+ +

So yeah, I tried doing that for about a year, and I was seeing some growth doing, like, a few skills, mainly like art, cooking. But after a while, I started getting burnt out, mainly because I didn't really have a huge passion for that. By trade, I'm a mental health nurse. I've been one for the past five years. So, I took a break for about a month, and I was thinking, okay, what do I enjoy doing? And if it was to fail, what would I not regret spending a lot of my hours doing? And that was mental health. So, that's where the idea came to me: to make your hobbies a form of therapy.

+ +

VICTORIA: I love that. And I'm curious what else about your background helped kind of inform your ideas around the therapy side of it.

+ +

HAMIDAH: I guess this kind of goes into my background. As a nurse, I worked in this emergency room and then also inpatient psych. And I was seeing a lot of patients that come back again and again. They lack a couple of things in their environment outside of, like, a psych unit, for example. On the psych unit, they have a structure. Like, you go to group art therapy, then you talk about your feelings. You have support there around you, you know.

+ +

And then once they get discharged and back into the community, most people don't have this thing. That's probably why they're in the hospital in the first place, you know. And so, I was thinking, like, what if someone can have this type of structure on the outside without having to be in the hospital? I mean, some people do, but you have to have insurance, you know, it costs a lot of money.

+ +

So, that's where Hobi was trying to come in to be a structure, you know, like a fun thing that's not just okay...and I'm not putting down psychotherapy at all, but sometimes people don't want to talk about their feelings all the time. You know, sometimes people want to do something fun, like, while also, like, having a mental health professional around to, like, guide them.

+ +

VICTORIA: Yeah, I totally get that. Like, I had been doing some of the talk therapy, like, apps, you know, like, BetterHelp and things like that. And it was fine, but then I kind of switched to just doing the tarot deck app instead because it's more fun, and it's less, like, just deep thinking about your feelings. It's kind of, like, expressive. And I think the interesting part about your journey here and, like, what I've heard as a repeating theme so far this year on the podcast is that, like, the real answer to a lot of problems is community and having those connections between people.

+ +

HAMIDAH: Yes.

+ +

VICTORIA: And, like, I love that you're working on how can tech solve that, and how can you make it affordable for people to build those communities and have access to those support networks and structure? Let me recap a little bit. So, you wanted to learn how to hula hoop, and then you wanted to find someone to teach you, and then you wanted to build an app to get that skill sharing going, but you thought you maybe wanted to make it a little more specific. So, you wanted to kind of bring it in as, like, hobbies as therapy, and that's where you are today, right?

+ +

HAMIDAH: Yes. It was a long journey. When you say it, it sounds like it's been a couple of months, you know, but it's actually been [laughs]...it's a span of years [laughs].

+ +

VICTORIA: So, how would you describe where you're at now in your customer discovery journey and finding your product-market fit?

+ +

HAMIDAH: Yeah, right now, I would say I have found my customer, but I am in a place where I'm making income from Hobi. It's not enough to, like, be profit. Obviously, I'm still starting out because this...I pivoted about eight months ago to go to, like, the hobbies as a form of therapy niche. And I have found some customers. I have some repeating customers, people who actually enjoy this that, like, you know, "This is actually amazing. This has helped me a lot with my life," yeah. And the way I find these people is by providing community.

+ +

VICTORIA: So, you found users through your existing community connections and through the group that you're running. Is that right?

+ +

HAMIDAH: Yeah.

+ +

VICTORIA: And so, you kind of found that, like, the traditional marketing models where you put out an ad and people click through, like, it wasn't a good enough management of expectations from, like, end to end. So, like, kind of going to the groups first and forming the connection and then being like, "We can use Hobi to facilitate this connection," worked more for you.

+ +

HAMIDAH: Yes. And also, the other thing, too, that worked for me...because, like, the issue with Hobi it's a two-sided marketplace. So, I have to worry about, like, the therapists that are going to be offering these sessions, as well as the people who are going to be paying to have the sessions. So, it was very tricky to try and balance those two sides, but I did find a medium.

+ +

Like, the key, if I was to take away from this, if I was to tell anybody the main thing to focus on, is to build, like, a strong relationship with...it doesn't have to be a lot of people. Start with one person and just make sure that you give them what they need, you know, like, they feel like this is something that's worth it to them. And then, from there, trying to replicate that if you can to a second person, and then a third person, like, something like that because you have to personalize it as much as you can.

+ +

VICTORIA: And what were some of the unique needs of therapy providers and people who would be participating in these community groups that was surprising to you when you started this process?

+ +

HAMIDAH: Was it surprising to me? I don't know if it was really surprising. When I started, I was trying to find, like, whoever needed the app the most, you know, in terms of both mentors and the student side. And I found, like, there's a lot of people out there that are trying to make money teaching what they know. I found a lot of art therapists that wanted to join Hobi, and it wasn't very difficult to do.

+ +

But I guess the tricky part or, like, the surprise that I found was not just finding someone who wants to make the money but is willing to take a loss a little bit for you or, like, for that cause. I don't know if that at all answers the question. Because I was finding people that were like, "Yes, I want to make money teaching, like, art therapy to a group of people." But then when they had a class, for example, and nobody showed up, it was, like, a huge blow to them. They're like, "No, I don't want to do this." And that was when I just started with this niche.

+ +

But then I was lucky enough to find a couple of art therapists that were willing to give it time and actually volunteer their time, like, one hour a month and just give, like, a free session or, yeah, stuff like that. And then, I noticed that over the months, now that mentor...well, like, those that I'm working with are actually now getting a profit.

+ +

VICTORIA: That's interesting, right? Because you're providing a platform. It's not a guarantee that people are going to make money right away. And you have to have a similar kind of community mindset that you're going to need to put in the time and start showing up regularly, and not everyone's going to be a good fit for that. So, that's really interesting. Yeah, I really like that. Tell us a little bit more about it. What kind of things can you get into on the app or on the website?

+ +

HAMIDAH: We offer art therapy, dance therapy, and writing therapy, or journaling, and then some cooking classes. So, those are, like, the main things I can get into. And then, for people who are new to this type of, you know, like, therapy, mental wellness, we do have a category called mental wellness skills. They can join there and learn, like, basic coping skills, emotional regulation, and stuff like that.

+ +

VICTORIA: I love that. I saw all those services, and I was like, oh, this sounds really nice [laughter]. Like, maybe I should sign up. But how do people access the app? Because I know you're trying to balance making that profit and also providing services to people who can't afford it. So, how did you strike that balance?

+ +

HAMIDAH: Yeah, I'll be super honest. I am still trying to get that balance, but, again, like I said, it depends on finding someone whose priorities fit your priorities. Like for example, I'm not going to go to an art therapist who has, like, ten years of experience used to, like, charging $200 a session and ask them, "Hey, could you join Hobi and take this huge pay cut for me [laughs]?" Like, that's not going to work out.

+ +

The balance I found through getting the right person to work with me, because, to this person, they actually see a lot of potential, and they actually are making more than they would have without Hobi. And to the user coming to the platform, they're getting someone who is very enthusiastic about what they're doing. And it's actually helping them out a lot at a fraction of the cost of what they would get elsewhere.

+ +

VICTORIA: Gotcha. Yeah. And I saw you had some different pricing points, too. You could pay just, like, per session that you wanted and join for free, or you could get, like, a regular amount of sessions per month, and things like that. Both sides of the marketplace. I love that.

+ +

Ooh. So, tell me more about, like, what's the impact that you're seeing? Now that you've gotten some traction and you're starting to see people really use it, tell me more about those stories where people are saying, "You know, it makes my life so much better."

+ +

HAMIDAH: I didn't really start seeing the impact, again, like, until a couple of months started rolling by because it would take some time, again, to get used to something. First, they go check it out. You know, they're like, "Oh, actually, this is kind of nice, you know." Then they go back again. They're like, "Oh, actually, maybe it's actually really good for me." Then, as they start using it over and over again, they start seeing the value of it, and that's what happened.

+ +

So, a lot of the good reviews that I was getting are from users who have been using it for, like, three months now. And they like it a lot, again, because of the two main reasons. The instructors are usually very enthusiastic and are wanting to help them, and they can feel that. The other thing is, like, they get a community because it is mostly, like, group sessions.

+ +

So, people have an option to do one-on-one sessions if they want with the instructors. But, usually, it's just group sessions, and the cost is the same, $5 for all the sessions. So, it's, like, very, very affordable. And people keep coming back. "I'm only paying $5. I get a group that I talk to, make some friends. I have a therapist that I can talk to, you know." It combines and adds up over a couple of months of doing it.

+ +

VICTORIA: I can imagine that'd be really stabilizing for a lot of people, especially for people who maybe aren't able or can't afford to travel in person to these types of sessions.

+ +

HAMIDAH: Yeah, I think it's stabilizing, and that's what I was keeping in mind when I was making the platform and talking with the mentors. I try to ask them to create, like, a structure to their sessions, not just, like, random, like, days, you know?

+ +

So, like, it's usually the same day every week, you know, and the same time every week. So, you know, like, okay, every Monday, I have a support group that I go to to, like, do art journaling, and then talk about how I feel, you know, like, check-in with people, they check in with me, stuff like that.

+ +

VICTORIA: That's really wonderful. And so, that's an incredible thing to be working on. So, how do you think about what success looks like for you this year or five years from now?

+ +

HAMIDAH: Yeah. What does success look like? What success would look like, for me, I would say, since this is, like, a self-funded platform and right now I am bootstrapping and I'm kind of in the negative...although I have been steadily, you know, like, the app is growing. I'm very happy for that. I'm getting more users coming back over and over again. I'm getting good reviews. I'm getting new mentors joining, so it is heading in the right trajectory, but it's, like, a slow but steady growth. And I want to keep it that way because we run into some blunders sometimes. And I can't imagine having a whole bunch of people in the app and then having a blunder, you know, and how I would deal with that. But anyway, I digress.

+ +

What success would look like, for me, is if I am in a profit margin, so, like, not being in the negatives but in the green. You know, I don't have to have, like, a lot of money, but as long as I'm not working in the negatives, that would be success for me. And in terms of the platform in general, success would look like, again, like steady growth, just keep going up, keep going up, and, hopefully, have less blunders along the way.

+ +

Like, for example, I mean, I'm sure many founders have dealt with this, especially in tech. Like, you build this platform, you know, things were going smooth, then boom, the website crashes, you know. And it's like, people get pissed off, and it's like, "What's happening?" you know. And it's a lot of stress to deal with sometimes. But in that aspect, too, success would look like having less of that happen and having more of the good stuff happen.

+ +

VICTORIA: Yeah. So, steady profits, steady performance of the application. Those are two great goals. I love it. How did you approach building the tech side of the company? And was there things from your own background that you found were helpful, or did you find people to help you with parts of it? Or how'd you do it?

+ +

HAMIDAH: That was a very huge huddle for me because my background, again, is in nursing. I don't have any friends who are in tech. I went to a pharmacy college school, like a healthcare university, so they did not have any, like, developing computer science programs. When I had this idea, I was like, how the heck am I going to do this? Because I don't have any connections. You know, I didn't even have a LinkedIn. Yeah, so it was a lot of, like, searching online.

+ +

I did get scammed twice trying to do this, but I was thankful that because of my job, I'm able to have a steady income. I was able to, like, eat up those losses and learn from my mistakes. And I found a development company that I worked with, and I've been working with for a while now, and they're very good. So, they have been helping me. Like, price-wise, they're great, and product-wise, they're also great.

+ +

VICTORIA: Yeah, it can be really hard to navigate when you don't have experience or any connections to the community. But I appreciate you sharing that because I think it's a really common story that happens to people, and not a lot of people talk about it.

+ +

HAMIDAH: Yeah. The other thing, too, that I should warn any new founders out there or people in the community as well, watch out for who you work with, you know, like, really, really do your due diligence because I learned the hard way twice. It was different times, and it was different ways that I got scammed, not the same way, but yeah, people will approach you, and they'll give you a great price point. And if you're, like, really desperate, you know, and you really don't have the money and want to see, like, the results right away, you might get sucked into it, but just always do your due diligence and try to find other options.

+ +

VICTORIA: Yeah. And, you know, talk to companies like thoughtbot who won't scam you [laughter]. But yeah, no, I'm sorry to hear. And there's, you know, don't feel bad. Also, like, those companies that do that, that's what they do, and they're really good at it, and it could happen to anybody. And same with, like, mental health, and, you know, wanting more connections and struggling with it, it sounds like you could use Hobi to find connection now and find people to help you get through that. So, I really think that's important.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: [inaudible 19:28] think about, what core values drive your everyday decisions?

+ +

HAMIDAH: Do things leaner. You know, like, I saw this lecture, like, The Lean Startup. Start as lean as possible and get the fundamental idea running without having to put a lot of money into it. And then, for my core values, I would say, like, integrity, doing what makes me happy, so it doesn't feel like I'm pushing, like, a heavy rock, just doing what feels like...something that just flows.

+ +

VICTORIA: I like that. Yeah, I think The Lean Startup is really smart. And it is funny when people ask me about app ideas. Like it's so tempting to just want to go build something and just see if people like it. But the answer is always, like, "Well, go talk to people first [laughs] before you, like, spend a lot of time building something," which is a lot harder and scarier to do. And that is why I really appreciate you sharing that.

+ +

And then, I liked your values: integrity, and, like, a self-fulfillment, self-actualizing feeling, not just, like, being repetitive loops. But yeah, no, that's really nice. And then, what are the biggest challenges in your horizon that you see?

+ +

HAMIDAH: The blunders that I talked about earlier, whereby something that you didn't expect to happen happens, and something that's usually bad that you didn't expect to happen happens. That's one of the biggest challenges that I'm trying to face. Yeah, I guess, like, how do you plan for the unexpected, you know? And how do you, like, do, like, a backup plan? In case something fails, how do you handle it, you know? Stuff like that.

+ +

VICTORIA: Yeah, now you're getting into, like, resilience engineering. I love it. Yeah, you're working with your development partner. Have you all talked about service-level objectives or any kind of, like, application monitoring, or anything like that?

+ +

HAMIDAH: Yeah, we have, yeah. And when I do say blunders, I don't mean, like, the app is crashing every, like, day. It's in terms of...like, one example was what happened. We use this video calling software, and it's not with Hobi. It's through a different third-party video calling software. And we just added their API into our website. And one of the mentors was giving a session one day, and the camera just stopped working, and it happened, like, twice. And it's like, how do you deal with that? Because it's not even, like, the app itself. So, it's not my developers that are causing the issue. It's the third party that we worked with that's causing the issue, you know.

+ +

And it's like, so I had to go and find a different third-party person to work with and hope that that doesn't happen with them. Yeah, it's just, like, stuff like that. How do you predict the unpredictable? You know, like, I guess sitting down and thinking about all the bad possible things that could happen, I don't know [chuckles].

+ +

VICTORIA: Yeah. Like, there's a balance between there are some things you could put a lot of structure and process around, and then, like, is that necessary? Like, is that the highest priority use of your time right now? Because yeah, lots of things can go wrong: APIs can break, you know, people push updates; DDoS attacks are happening more and more, ransomware attacks. There's all kinds of things that can happen that, yeah, it's pretty tough.

+ +

But I think what you've done, where you've built a really strong relationship with your service providers and with your users, will help you in the long run because everyone has issues like that. Like, no app is perfect. So, if you're providing a really good service and the majority of the time it's working, then [laughs], like, you're probably fine. It's like, when do you make that choice between, like, really investing in, like, the application monitoring piece and things like what you're kind of talking? Like, it might be a major architectural change in the app that you would have to, like, invest in.

+ +

So, that's something that I think about a lot is, like, how are leaders making these decisions? And, like, do you have someone to go to to, like, bounce ideas off of? I'm sure you have mentors in the startup community in Boston that you can, like, go to for advice on those things now. And I actually know that you know Jordyn through the Boston startup network area. How has that community been for you?

+ +

HAMIDAH: Oh, it's been good. It was a great community. I was there in the accelerator, Prepare 4 VC. I was there from July till September, and I learned a lot from them. They left their arms open. They're like, "If you ever need to come back, you can always come back. Like, we're always here; just reach out. We can always have a meeting anytime you need one." So, it's been very great. And I really, really appreciate being a part of it.

+ +

VICTORIA: That's awesome. What's the wind in your sails? What keeps you going?

+ +

HAMIDAH: I don't know if I talked about this, but I remember, like, where I faced a crash at some point where I was like, this is not working [chuckles]. Because I was like, I don't know if I can do this, you know. And that's when I sat with myself, and I was like, what do you see yourself doing forever, whereby you don't care if it pans out or not? It was this, the mental health aspect.

+ +

And I'm an artist. I like art, you know, I like creative expression. I like dancing, you know, like, with a hula hoop, like we talked about earlier. You know, I like that type of stuff. So, I was like, okay, how do I mix the two together? And this is where this came about making your hobbies therapy. And also, like, community, like, community building. It really all came together. And just knowing that I am building that slowly but steadily, that's what keeps me going.

+ +

VICTORIA: I really love that. That's really amazing. And did we talk enough about mental health on the episode? I know we wanted to really get into it a little bit about there's a mental health crisis in the United States right now, and I'm sure in other countries as well across the board. So, maybe you wanted to say a little bit more about that and how art could be a part of it.

+ +

HAMIDAH: Oh yeah, I saw this study that 1 in 5 Americans suffers from mental illness. Half of the people that have mental illness don't actually get treated, and it's for a lot of factors. And, you know, it's expensive if you don't have insurance, especially. There's no access, lack of education around it. So, it's a lot of reasons. That's where Hobi comes in, like, you know, like, it's trying to help a little bit where it can. So, in terms of, like, the financial aspect, sessions are $5. And in terms of accessibility, if you have Wi-Fi and you have a phone, you know, you can access it. And I know, like, not everybody has that, but, like, we're trying to help in that aspect.

+ +

In terms of community, there's groups, support groups on Hobi based on interests. So, if you like art, you can find an art group. And I'm not going to lie; they're not huge groups, you know? I mean, it's a new concept. It's eight months since the pivot, so it's growing. But there is people in the groups, and people chat sometimes. I remember, like, somebody had posted, like, a cry for help, and somebody else actually replied them. They were actually talking together and then helping each other out. And it made me be like, okay, you know what? I should keep going with this. Like, this is why you're doing this.

+ +

The aspect in art and mental health is it brings what is in your head on the outside, and that helps take the emotional weight off of you. The best way to explain this, for example, is with journaling. You have all these mini-thoughts going up in your head, you know, like your anxieties, your fears, all these things going on that you internalize, like, you know, you just keep pushing in the back of your head, and then you think about it all day.

+ +

But if you take the time, for example, you sit down, and you write out how you're feeling, you know, with purpose, you know, like a gratitude journal, you, like, paint what you're feeling, like, express what you're feeling, and if you do this enough, you start to see a pattern. You stop internalizing all these things, and they become an actual thing that you can look at and analyze. So, like, that's the whole point of art and mental health. Like, it helps you bring it out of your head and onto, like, a piece of paper.

+ +

VICTORIA: That's great, yeah. I think I took a psychology 101 class in college, and she's like, "If you're having circular thoughts, just, like, put them on paper, and then go to bed [laughs]." But yeah, I think that's a really beautiful way to put it. So, thank you for sharing that. Is there anything else you'd like to promote?

+ +

HAMIDAH: I'm here to talk about Hobi, and so that's what I would like to promote. You can go check out the app. We have a website and an app now. Because I'm a mental health person, you know, don't forget to take care of yourself, and don't forget to be kind to yourself. And it doesn't have to be through Hobi, but try to use art as a form of mental wellness.

+ +

My task to you, listener, is, try journaling, for example. Try [inaudible 27:46] your feelings. Try dancing out that stress and see if you feel a difference after.

+ +

VICTORIA: What a wonderful way to end the episode. Thank you so much for coming on and telling us your story and talking about Hobi.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

And you can find me on thoughtbot.social@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+nIF-UTH4 + + ]]> + + Victoria Guido + + + 521: Insusty: Pioneering Sustainability Rewards for Environmental Action + https://podcast.thoughtbot.com/521 + 6874fe6c-8965-47b8-8e41-cb6940553652 + Thu, 18 Apr 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Will Larry and Victoria Guido talk with Sanghmitra Bhardwaj, CEO of Insusty, about her journey from a Himalayan village to founding a company in France that drives sustainable actions through a rewards program. They explore how Insusty fosters environmental stewardship by rewarding actions like volunteering and donating to overcome the high costs of sustainable living. The discussion also covers the broader impacts of sustainable practices in technology and business, Sanghmitra's experiences as a solo female founder, and her plans for enhancing Insusty's platform. + 39:12 + no + + + Hosts Will Larry and Victoria Guido chat with Sanghmitra Bhardwaj, CEO and Founder of Insusty. Sanghmitra shares her journey from a small village in the foothills of the Himalayas to becoming a founder in France, driven by firsthand experiences with climate disasters and a passion for sustainable living. Insusty, a sustainability loyalty program, is a platform incentivizing individuals to adopt climate-positive actions through rewards, thereby fostering a community motivated towards environmental stewardship. +The show digs into the mechanics and vision of Insusty, highlighting how the platform rewards eco-friendly actions like volunteering and donating, rather than purchases. This approach aims to bridge the gap between the desire for sustainable living and the practical challenges individuals face, such as the perceived high costs of sustainable products. Sanghmitra reveals the evolution of Insusty, including strategic pivots towards niche markets within the circular economy and the importance of transparency and impact measurement in building trust with consumers. +Towards the episode's conclusion, the conversation shifts to broader implications of sustainability in technology and business. Sanghmitra expresses curiosity about future expansions of Insusty, particularly in tracking and rewarding individual daily eco-actions more effectively. She also touches upon the challenges and triumphs of being a solo female founder in the tech and sustainability sectors, underscoring the significance of community, perseverance, and innovation in driving change. +Insusty (https://www.insusty.info/) +Follow Insusty on LinkedIn (https://www.linkedin.com/company/insusty/), Instagram (https://www.instagram.com/theinsusty/), or X (https://twitter.com/the_insusty). +Follow Sanghmitra Bhardwaj on LinkedIn (https://www.linkedin.com/in/sanghmitra-bhardwaj-515428236/) or X (https://twitter.com/sustainwithsan). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. With me today is Sanghmitra Bhardwaj, CEO and Founder of Insusty, a sustainability loyalty program for individuals. Sanghmitra, thank you for joining us. +SANGHMITRA: Thank you so much for having me here. I'm super excited for the podcast and to discuss various topics that we are about to. And I'm sure that it's going to be a learning experience, not just for the audience, but also for me. So, thank you for this opportunity. +VICTORIA: Why don't we just start off getting to know you a little bit? Tell us something exciting going on in your life, maybe outside of work. +SANGHMITRA: Okay, so, well, recently, I joined a pole dancing class. I wanted to challenge myself and see if I have the core strength that I need to be strong. And I also feel that it's something that I always wanted to do to come out of my comfort zone. So, it's been fun so far. +VICTORIA: I tried that, and I thought that I would naturally be good at it because I'm a rock climber. And so, I thought I'd have all the right muscle groups, but the coordination and [laughs], like, expression of it is still challenging if you've never done it before. +SANGHMITRA: Yeah, definitely. And I think there are some techniques and if you don't do it right, like, you will not get it at all, those poses and, like, how you climb the pole and everything. So, I completely relate to your experience here. +VICTORIA: I want to do more dance, actually, because the mind-body connection and getting into that feeling of flow is really interesting for me. And I think it's like expressing through your body, which 80% of communication is non-verbal, which is really interesting. +SANGHMITRA: Yeah, that's true. Just to add to it, I wanted to also share with you that I used to do modeling back in India, and I really love expressing myself with my body. And it's been super interesting to see that. And also, when I have conversations with other people, these are the things that I observe a lot. Is it the same for you? Do you also observe other people's body language when they are talking to you and probably change some topics that you are trying to discuss? +VICTORIA: Yeah, absolutely. You can tell if people are listening to what you're saying. They, like, lean in a little bit, or if they're not really wanting to relate to what you're saying, they're, like, crossing their arms in front of you. So, as someone who works in business development, I definitely pay a lot of attention [laughs] to all that stuff. But I'm curious, how did you go from being a model in India to founder and CEO where you are today? +SANGHMITRA: That's something that I would love to talk about, and also, it has to do from where I come from. So, I come from a very small village in the foothills of the Himalayas. There, I witnessed climate disasters firsthand. In 2013, there were a lot of cloudbursts happening in those areas. An entire village next to my village disappeared completely without a trace. And those were some moments in my life where I really felt like we live in a world where you can be far from Europe...for example, currently, I live in France, and here, when heat wave happens, we all suffer and people talk about it. But I have seen, like, the adverse effect of what it can lead to. +So, there was a part of me that always wanted to do something in terms of the impact that I create, like, with my work. So, I started doing modeling, which was something for myself as well to gain some confidence. At the same time, I worked with sustainable brands in India. I modeled for them, and then I discovered their work. I got inspired by it, and I realized that it's something that interests me a lot, and I wanted to pursue my studies in it to know more about it. So, that's when I came to France to pursue my master's in sustainable finance to discover more about this field and to see where I belong. +And finally, I founded Insusty, where I could see that I could bring my inspiration from the sustainable brands that I worked with. Whether it's from the fashion or, the food industry, or the travel industry, I could see the inspiration coming from there. At the same time, I could see how we need to create mass adoption through incentivizing climate action, which was something that I explored during my studies. And I kind of went with Insusty, and that was the beginning of my founder journey. +WILL: I have a question about the way you grew up, and you're saying in a village. Can you expound a little bit on that? Because you said, climate change wiped out an entire village. And so, when I saw that in the email, I was like, I don't think I've ever had a chance to actually talk to someone that lived in a village. I grew up in the United States. So, like, help paint that picture. When you say you grew up in a village, what do you mean by that? What was it like growing up in a village, and also, what do you mean by the next village got entirely wiped out? +SANGHMITRA: Yeah. Living in a village it's like being a part of a tiny, well-knitted community, and it's, like, everyone knows everyone. And sometimes it's good, sometimes it's bad because when people gossip, of course, it spreads like a wildfire. As well as when you need support and when you need help, this community is always there, too. So, the part of belonging to such a community and to kind of engage with people is something that I really enjoy about coming from a small village. And that's something that I oftentimes search in France, where I can be a part of such communities as well, where people inspire each other. +For example, currently, I'm a part of a wonderful community of women of color founders living in Europe. It's called Founderland. And it's thanks to Founderland that I found you then I could join this podcast. So, when it comes to the small village, this is what I really really love about it is the small knitted community we have. +When I say that the entire village next to my village disappeared, I mean that when there was the cloudburst in the mountain, the soil and everything drowned the entire village. So, there was a school, and we used to hear a story about the school, where the kids were told by the teachers to run because there is a cloudburst, and "We are about to die if we stay in this place." +And as a student, as a kid, what do you think first? You think about packing your bags instead of running. So, the kids ended up packing their bags before they could run, and by that time, it was too late. So, this is just one of the heartbreaking stories that I'm sharing with you right now, but it had been something that really left a mark in my life. +VICTORIA: I really appreciate you sharing that story because when I talk to people about climate change, I think it's really easy to get this nihilistic attitude about, well, climate change is going to kill us all in 20 years. So, why bother doing anything about it? And what I usually answer back is that climate change is already killing people. +And then, it's happening in your own neighborhood, even, like, you know, I live here in San Diego, and it's always between, like, 60 and 80 degrees every single day [chuckles], but our beaches are collapsing. There are neighborhoods that are more impacted by pollution than others and are experiencing environmental impacts from that and their health, and everything like that. So, I'm curious how it all comes together with what you're doing with Insusty and how you're inspiring people to take action towards sustainability in the here and now. +SANGHMITRA: Actually, I have a question for you and Will. I wanted to understand, for example, if you purchase something in terms of, for example, it's related to fashion, or it's related to food products, what is the criteria that's most important to you? And maybe probably you can tell me, like, the top three criteria that are most important for you when you buy something. And then, I would love to share how Insusty can help you buy better. +VICTORIA: When I'm looking to buy things, I look for, like, price. I want it to be reasonable, but I also don't want it to be so cheap that it means it's a really poor quality. So, I want to find that balance between, like, quality and price. And I do also care about sustainability, and, like, what is the background of the company that I'm buying it from? You know, what's their reputation? What's their, like, practices? +Like one example is, like, the rugs for your house. So, I like to buy rugs that are made from sustainable fabrics and dyes and that I can wash them because I have a dog. And so, that's kind of, like, what I think through when I buy things. But it's not always easy, especially with clothing, because it seems like anyone who makes clothing, there's just always this risk of it being sourced at some part in the manufacturing pipeline having to do with either child labor or really terrible sustainability practices. +WILL: Yeah. I would say, for me, early on, especially when I was growing up, we didn't have a lot of money, so it was just whatever is the cheapest, whatever we could afford at that moment. It wasn't really looking into the quality, or sustainability, or any of those items. Some of the stuff I look back on that I ate often, I'm like, whoa, man, that was not the best thing. But it was the cheapest, and it was what we ate and things like that. +So, now that I'm older, my wife has been talking to me about some of that stuff, and it's like, oh, I had no idea, because of the environment I grew up in, that, like, that's even affecting me. And that was kind of why I asked you about the village thing is because I feel like we can get in a bubble sometimes and not even be aware of what's happening to other people. +And I think, Victoria, you said something about people not understanding climate change. It's kind of tough at times to talk about climate change when you live in...where I'm at in Florida, it's like, okay, it gets hot, and then it gets cold. And yeah, we have a hurricane every now and then, but whenever you told the story about the village, it's like, oh, wow, like, that's a different game. That's a different level. I didn't even know about that. +So, I think that's kind of my journey now is I am starting to understand sustainability. I think a lot of times I still have that I grew up with nothing mindset and want to get the cheapest thing because sometimes buying sustainability is super expensive. So, that's why I'm glad that I'm talking to you, so maybe I can learn some of those things. So yeah, that's kind of been my journey with it. +SANGHMITRA: That's really wonderful to get your insights because now I can tell you confidently what we do. Basically, when I talk to people, it was generally the same thing that I asked them, "What's the most important thing when you buy, like, the top three most important things?" Sustainability was definitely one of them, but cost was always there. Regardless of the background that they are from, cost was something that they all thought about. +So, what we do at Insusty is that we incentivize individuals to do something good for the planet. It can be, for example, you want to volunteer at an NGO next to your place. You want to get rewarded. So, what we do is we offer you loyalty points that help you to buy from sustainable brands. So, you try these products because, oftentimes, as Will also mentioned, there is a perception, and it's also a reality, that sustainable products tend to be more expensive. So, we try to deal with that by offering a loyalty program that incentivizes climate action. +And in terms of the sustainable brands, they get new customer base. They get to interact with these customers. They get to see their product and sites. What is something that the customers really like? What is something that can be improved? How can they improve in terms of their own sustainability and their impact? For example, their supply chain operations and so on. So, it's something that we provide them and help them also with insights as well as new customer base. We try to support them with that. +At the same time, on an individual level, we help with the cost factor, which is one of the most important things. When we want people to change, when we want people to adopt sustainable lifestyle, we kind of need to incentivize that so that mass adoption can be possible. +VICTORIA: So, I'm imagining, like, I want to know a new brand that I want to buy clothes from, like essential clothes. I could go into the app and, like, find companies that produce the thing that I want, and then I could get points and rewards for buying consistently from that brand. +SANGHMITRA: So, we are not like an actual loyalty program. So, you only receive points when you do something good for the planet. You don't receive points when you purchase from brands. This is a loyalty program where we give you points when you do something good for the planet, for example, donations. For NGOs, we have volunteer programs that individuals can participate in and receive loyalty points. But in the future, we are ambitious, and we want to go far. And we think that each and every activity of an individual can be tracked in terms of sustainability, how they are segregating their waste at home, how they're managing that, and so on, and give them points for each of their eco actions. +VICTORIA: Awesome. Yeah. Okay. I love that. Yeah. So, what kind of things would earn me points, like, in my home ownership here? +SANGHMITRA: If you volunteer with an NGO nearby or if you would like to participate in an event, for example, if you want to donate clothes, all these eco actions can give you loyalty points for the moment. And in the future, we want to also track the actions that you do at home. You save electricity, for example. You want to walk to the office instead of taking a cab, and all these activities, so that we can kind of make the experience also for the user a bit more like a game so that they enjoy doing it at the same time they receive rewards. And they can make purchases as well with the sustainable brands on our platform. +VICTORIA: I like that because I've been talking with my partner about how do we live more sustainably, or how do we, like, reduce our consumption or give back. And I think if it was gamified and we got points for it, it's more motivating because then you also see that other people are doing it as well. And so, you're part of a community that's all trying to take the same action. And that will have a bigger impact than just one individual, right? +SANGHMITRA: Yes, definitely. And we do have that feature on our platform where you could see near your area who donated and who is working in a particular NGO, so based on the fact that if the individual is comfortable in sharing that. Most of the time, when someone does something good for the planet, they would love to show it to the rest of the world. So, we have seen that people love to share their experiences and their badges, saying that, okay, they donated, for example, five euros to this NGO, and so on. So, they really love that. And it feels also really good to see this community and to get inspired by it. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +WILL: I think it's going to take all of us doing something to help with climate change and to make a difference. So, I like how you're incentivizing. You're making a difference. You say you get reward points. So, once I do an item or an action and I get reward points, what does that look like on the backend of it? +SANGHMITRA: For the individuals they have a dashboard to track their actions. They have a dashboard to also track what they are purchasing. So, if they're purchasing food or they're purchasing more items related to fashion, they can also check that. They can check the total number of points that they have received so far, where they have used it, and so on. And at the backend, for us, we see it as the total number of transactions that are taking place, so, for example, how the loyalty point is being used. +So, we have APIs that are in place between our platform and the platforms of other sustainable brands in our network. So, in our backend, we can see the transactions; for example, an individual used 100 points to get 10% off from one of the sustainable brands on our platform. And in terms of the sustainable brand side, even they have their own dashboard. They can also track how many individuals are using their points on their platform, and so on. So, they also have access to their own analytics dashboard. And through the same application, they can also provide us the payments through subscription and transaction fees. +VICTORIA: Yeah, that's really interesting. And so, I understand that you've been in the journey for a little while now. And I'm curious: if you go back to when you first got started, what was surprising to you in the discovery phase and maybe caused you to pivot and change strategy? +SANGHMITRA: So, one thing that I pivoted with was the type of brands that we wanted to onboard. Before, we had a very open approach; for example, we want brands that are sustainable, or if they are upcycling, or if they have, like, a particular social impact attached to it or an environmental impact attached to it. So, we were focusing on having the horizons a bit like the aspects of choosing a sustainable brand to be a partner. It was a bit broader for us. +But when we talked with the people, they wanted a niche. For example, they wanted upcycle products. They wanted more brands in the circular economy domain. And that's when we realized that we need to have a niche. So, we focus on the brands that are more linked towards circular economy that are promoting the values of recycling, upcycling, and reusing the products. +So, that was when we pivoted with the idea that we should not be open to all sustainable brands. However, we need to be really accurate with our approach. We need to focus on a particular niche. At the same time, we need to also make sure that we measure their impact and report it to our customers to ensure transparency on our platform. So, that became a priority more than having more and more brands on our platform. +WILL: Yeah, I really...that was actually one of my questions I was going to ask you because I like how you are vetting them because I've, especially here in the States, I've seen, like, companies, like, slap 'non-GMO' or 'gluten-free.' And it's like, well, it doesn't even have wheat in it, so, like, yeah, it's gluten-free. So, it's like, it's more of a marketing thing than actually, like, helping out. So, I'm glad you're vetting that. How has that process going for you? +SANGHMITRA: It's actually going really well, and we have established a five-step onboarding process. And in the first two steps, we also focus on measuring their impact. We have a self-evaluation form. We also check if they have some existing certificates. We also make sure that we have enough data about their supply chain and how they are working. And these are some of the information that we also share with our consumers, the one who would be interested to buy products from these brands, to make sure that we are transparent in our approach. +There's also one more thing that we do. It's the quarterly reporting. So, every three months, we also report the individuals who are buying from sustainable brands on our platform that, okay, this brand did better this quarter because they implemented a process that, for example, is reducing a certain amount of emissions from their supply chain, or any other departments. So, these are some of the information that we also share with the individuals. +VICTORIA: And what does success look like now versus six months from now or five years from now? +SANGHMITRA: For the moment, success would look like for me to have more connections, more people who support our project and our initiative, and the more people joining us. In terms of the next six months, I think it would be linked to fundraising. But I wouldn't go so far at the moment because, for me, I take one day at a time. And this is something that has been super helpful for me to streamline my tasks. So, I take one day at a time, and it's working really well for me. +WILL: What are some of your upcoming hurdles that you see? +SANGHMITRA: When I talk about hurdles, I often see it in two parts, one being the internal hurdles and the other one being external. So, in terms of the internal hurdles, it can be something like I'm putting myself in a box that, okay, I'm a single woman founder. How can I do something good? And just doubting myself and things like that. These are some of the internal hurdles that I'm working on every day [chuckles]. I'm also talking to executive coaches to get their advice on how I can improve myself as well to overcome these internal hurdles. +However, in terms of the external hurdles, these are some things that are not in my control, but I try my best to make the most of it. Currently, in terms of the external hurdles, I would say that I live in a country where I used to not even speak the language. So, initially, the hurdle that I experienced was mostly the cultural hurdle. But now it's more related to the fact that I am a single female founder, and there are perceptions around it that you need to have a co-founder. And there are a lot of different noises everywhere that doesn't allow you to grow. +VICTORIA: And you're not just a founder, but you're also an author. And I wanted to ask you a little bit about your book, the Sustainability Pendulum. Can you share a little bit about what it is and why you wrote it? +SANGHMITRA: So, Sustainability Pendulum is the book that I wrote last year, and I always wanted to write it. And last year, I put myself to work, and I was like, at least every day, I'm going to try and write one page, and probably by the end of the year, I can finish the book [chuckles], and that's what I did. I had to be super consistent. But I came up with Sustainability Pendulum, and it's about the stories from the past and the sustainable approaches that we had in the past, how we used to...in different religions, we have some stories written in the scriptures related to sustainable practices. +And oftentimes, when we talk about sustainability today, we talk about the future. We talk about implementing different technologies and, doing a lot of innovations, and so on. However, we don't look into the past and see how efficiently things were handled when it came to sustainability in the past. And these are some of the stories from the past, from different religions, and how it transcends to today's sustainability issues and solutions. So, that's what the book is about. And why it's called the pendulum, it's because how the pendulum moves. I think it's obvious [laughs], so the pendulum's to and fro motion. It goes to the past, and it goes to the future. So, that was the whole concept behind the sustainability pendulum. +WILL: That's amazing that you wrote a book, much, much respect on that. I am not an author, so...And I also know because my wife she's been talking about writing a book and the different challenges with that. So, kudos on writing a book. Would you write another one? +SANGHMITRA: Actually, I would love to. I'm just looking for something that equally inspires me how it did for the last one. But I think once you come out of that space and you're consistent with writing the book or consistently working to achieve something, I think eventually it comes to you. So, I don't know what are the challenges that your wife mentions that she faced in writing the book. +WILL: Like, having enough to write about, like you said, just sitting down each day writing a book. And I think publishing a book is tough. I know we've come a long ways, like, you can self-publish now instead of going through publishing companies, and just those different avenues of how many steps it takes. It's not just writing a book, sitting down and writing a book, and sharing with everyone. It's multiple steps that you have to go through. +SANGHMITRA: Definitely. I couldn't agree more with you on this one. Just to add to it, how I managed to do this was also because I structured the book earlier. And in order to also publish it, I realized that I don't want to wait. And I self-published the book as soon as I found out that, okay, this is perfect, and it's ready. I need to just move forward with it. What helped me as well was the way I structured the book earlier. And then, I was like, okay, every day, this is what I'm going to work on. And it kind of helped me to get to the end of it. +WILL: That's awesome. I like how you had forethought and how it made it easier for you to come up with ideas and write it. So, that's awesome. +SANGHMITRA: I wish the best to your wife as well for her book. And I hope that once it's ready, you will let me know about it. +WILL: Yes, I definitely will. You're talking about being a woman founder who is single. I don't want to assume. So, why is it tough for you to be a woman founder who's single? +SANGHMITRA: When I say single female founder, it means that I don't have a co-founder. It's not, like, my relationship status but just [laughs] the fact that... +WILL: Yes. Yes. +[laughter] +SANGHMITRA: Just that I am a single founder, like, then I don't have a co-founder, which oftentimes poses as a risk, especially when you talk to an investor. This is what I feel based on my experience. But I think the times are changing, and I feel that the more the project is growing, the better it is getting in terms of the people who are interested as well to be a part of Insusty as an investor or as a partner. Things have become better now than they were a few years ago. So, I can see the change. +But, initially, I did used to feel low about it that, okay, I'm a single female founder, and oftentimes, it was considered as a challenge. But if you take my perspective, I think, for me personally, it possibly was also one of my biggest strengths because I could be that one person going to the meetings, and I felt that people were more open to share things. They did not feel threatened by me. And that was something that really helped me to also form connections with people. +VICTORIA: I love how you connect having a small community in your village where you grew up to creating a community around yourself as a founder and having a village that supports you, and you feel comfortable around the community as well, and as part of that community. If you could go back in time and give yourself some advice when you were first getting started with Insusty, what advice would you give yourself? +SANGHMITRA: Slow is good. When I say that, I mean that every time we talk about different startups and different companies, and it's always about how rapidly the startup is growing, how exponentially they are growing, and so on. But I feel that in terms of when you really want to create an impact, and you are in the green tech space as well, being slow and getting somewhere is better than going fast and then having a burnout. So, one of the things that I would tell myself when I just started would be slow is good. +WILL: Even with coding and a lot of things in life, I feel like that's really good advice: slow is good. Slow down––enjoy the moment. So, I like that advice. +VICTORIA: I was going to say, it sounds like a more sustainable pace for yourself also [laughs]. +SANGHMITRA: Exactly. +VICTORIA: Sustainability in the environment, and also in our own energy, and emotions, and motivation to get things done. So, I love that. +WILL: I see what you did there [laughter]. +VICTORIA: Yeah, [inaudible 30:40] all back. Do you have anything else that you'd like to promote? +SANGHMITRA: I would really love to also tell people that I'm very open to communication. So, if anyone would like to reach out to me on LinkedIn, it would be really awesome, and we can get on a call as well. I have my Calendly link right on my profile, and I'm very open to communication. So, if there is someone who would like to talk to me about any of the things that interest them or probably something that they could advise me or I could learn from them, I'm more than open to do so. +VICTORIA: Love that. And then, do you have any questions for me or Will? +SANGHMITRA: So, in terms of the development part, I do have some questions, like, in the technical side. So, when it comes to the fact that we have to kind of calculate the eco actions of individuals in the future, we want to also see if we can calculate the daily actions that they do, for example, walking instead of taking a cab, or segregating their waste, et cetera. I wanted to know, in the future, I want to implement these features, but can we actually get a perfect product around it? Is that possible where we can track everything? +WILL: Yeah. So, when you say track everything, like, I know you talked about walking and some of the different actions. Can you expound on that? +SANGHMITRA: For example, instead of IoTs...because I know that some hotels they do use IoT devices to track the water consumption, and so on. However, on an individual level, how can we just track it through the smartphone or through the app that they have? Because, okay, walking can be tracked. This is actually one of the challenges I'm facing, so I want to just be open about it, and I'm very open to ideas also. If you have some ideas that I could experiment around, I would really love to. In terms of the activities like walking, waste disposal, and so on, do you think that there are some kind of features that we could implement to track these actions? +One of the things that I was thinking about was we let people take a photo of how they are segregating the waste in the end, and through that, we can tell them, "Okay, this is great," and we give them the points. But how can we do it and also automate it at the same time? +VICTORIA: So, one approach that I know when people work at thoughtbot on these types of issues and trying to figure out, like, what is the right feature? How are we going to implement this? Going through a product design sprint where you spend a week with a product designer and someone who can, you know, really quickly create MVPs. And you go through this process of figuring out what's the most important feature. And you're talking to users, and you're trying to...you're going through that discovery process in a short period. And we actually have a video series where we walk through every step of that process. +But, like, for me personally, things that I can think of in my life that I would want to track one thing I've been trying to do more is actually electronic recycling, which in the U.S. my neighborhood is different. It's only open on, like, Thursdays and Saturdays. And I have to, like, really remember to go out there and, like, put my electronics out there. And I don't think it's very, like, well-known. So, I think that would be something interesting to, like, promote as possible. +And we also have the green bins now, which are new, which allow you in California to, like, have composting. So, you have now your regular trash, your recycling, and your compost bins. So, actually, like, trying to use those and track them. Otherwise, one of the things I think about is, like, reducing the amount of plastic consumption, which includes things like, you know, when you buy toilet paper, it comes wrapped in plastic. How can I incentivize myself and my partner and even my family to, like, switch away from those types of products and get more into, you know, using towels instead of paper towels or finding alternative methods for getting those products while reducing the amount of plastic that comes with it? +SANGHMITRA: That's super interesting. I'm really, really glad to have your insights as well. I do have a question for you. Have you worked with startups in the field of impact? And if so, what have been some of the ideas that you really loved to implement? +VICTORIA: Yeah, actually, we had another guest on the Giant Robots podcast who I think you're connected with as well who created essentially, like, a GoFundMe but for environmental projects and in areas that, you know, a 5,000 grant to help do a beach cleanup could have a really big impact. Like funding programs and marketplace for those types of green projects in areas that are the most impacted by climate change and have the fewest resources to actually do anything about it. +So, I thought that was really exciting in trying to figure out how can we use tech to solve problems for real people, and for people that don't typically get the focus or the majority of the funding, or the majority of time spent in those communities. So, that, I think, is what is really exciting: to see people come from those communities and then figure out how to build solutions to serve them. +SANGHMITRA: That's really wonderful. Is there, like, a specific market where you have seen growth of such startups and companies more? The companies especially you have worked with in the past and in there in the field of impact, are they mostly from the U.S., or which are the markets they are from essentially? +VICTORIA: Yeah. So, I mean, I'm from the U.S., so that's where I see the most. I'm in San Diego. So, when I go to, like, startup weeks and things like that, that's where I'm getting the majority of my exposure. I do also know that there is a Bloomberg Center focusing on excellence and data in the governments. And that's not just U.S.-based but going more global as well, so trying to teach civic leaders how they can use the data about whether it's sustainability or other issues that they're facing too, like, figure out how to prioritize their funding and in what projects they're going to invest in from there. So, I think that's really interesting. +I don't know, I don't know what the answer is, but I know that there are some countries that are hoping to make the investments in sustainability and ecotourism, as opposed to allowing industry to come in and do whatever they want [laughs]. So, I don't know if that answers your question or not. +SANGHMITRA: Yeah, I think it completely answers my question. Thank you for sharing that and also a bit more. +WILL: There's so many things that I've learned through the podcast. So, I'm excited to see the impact it has. And I think you're doing an amazing job. +VICTORIA: Thank you so much for coming on and being with us here today and sharing your story. +SANGHMITRA: Thank you. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@ giantrobots.fm. And you can find me on Twitter @will23larry. +VICTORIA: And you can find me on Mastodon @thoughtbot.social@vguido. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. + AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + Sustainable Living, Climate Action, Insusty, Eco-Friendly Rewards, Green Tech Innovations, Climate Change Solutions, Sustainability Incentives, Environmental Stewardship, Reward Programs, Green Technology, Sustainable Development, Eco Actions, Sustainability Rewards, Green Living, Climate Positive Actions, Sustainable Brands, Eco-Friendly Shopping, Environmental Impact, Sustainability Strategies, Climate Action Rewards, Green Initiatives, Eco-Friendly Living, Sustainable Choices, Green Innovation, Sustainability Incentives, Sustainable Lifestyle, Eco Rewards Program, Green Rewards, Climate Change Mitigation, Environmental Solutions, Green Tech Startup + + Hosts Will Larry and Victoria Guido chat with Sanghmitra Bhardwaj, CEO and Founder of Insusty. Sanghmitra shares her journey from a small village in the foothills of the Himalayas to becoming a founder in France, driven by firsthand experiences with climate disasters and a passion for sustainable living. Insusty, a sustainability loyalty program, is a platform incentivizing individuals to adopt climate-positive actions through rewards, thereby fostering a community motivated towards environmental stewardship.

+ +

The show digs into the mechanics and vision of Insusty, highlighting how the platform rewards eco-friendly actions like volunteering and donating, rather than purchases. This approach aims to bridge the gap between the desire for sustainable living and the practical challenges individuals face, such as the perceived high costs of sustainable products. Sanghmitra reveals the evolution of Insusty, including strategic pivots towards niche markets within the circular economy and the importance of transparency and impact measurement in building trust with consumers.

+ +

Towards the episode's conclusion, the conversation shifts to broader implications of sustainability in technology and business. Sanghmitra expresses curiosity about future expansions of Insusty, particularly in tracking and rewarding individual daily eco-actions more effectively. She also touches upon the challenges and triumphs of being a solo female founder in the tech and sustainability sectors, underscoring the significance of community, perseverance, and innovation in driving change.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. With me today is Sanghmitra Bhardwaj, CEO and Founder of Insusty, a sustainability loyalty program for individuals. Sanghmitra, thank you for joining us.

+ +

SANGHMITRA: Thank you so much for having me here. I'm super excited for the podcast and to discuss various topics that we are about to. And I'm sure that it's going to be a learning experience, not just for the audience, but also for me. So, thank you for this opportunity.

+ +

VICTORIA: Why don't we just start off getting to know you a little bit? Tell us something exciting going on in your life, maybe outside of work.

+ +

SANGHMITRA: Okay, so, well, recently, I joined a pole dancing class. I wanted to challenge myself and see if I have the core strength that I need to be strong. And I also feel that it's something that I always wanted to do to come out of my comfort zone. So, it's been fun so far.

+ +

VICTORIA: I tried that, and I thought that I would naturally be good at it because I'm a rock climber. And so, I thought I'd have all the right muscle groups, but the coordination and [laughs], like, expression of it is still challenging if you've never done it before.

+ +

SANGHMITRA: Yeah, definitely. And I think there are some techniques and if you don't do it right, like, you will not get it at all, those poses and, like, how you climb the pole and everything. So, I completely relate to your experience here.

+ +

VICTORIA: I want to do more dance, actually, because the mind-body connection and getting into that feeling of flow is really interesting for me. And I think it's like expressing through your body, which 80% of communication is non-verbal, which is really interesting.

+ +

SANGHMITRA: Yeah, that's true. Just to add to it, I wanted to also share with you that I used to do modeling back in India, and I really love expressing myself with my body. And it's been super interesting to see that. And also, when I have conversations with other people, these are the things that I observe a lot. Is it the same for you? Do you also observe other people's body language when they are talking to you and probably change some topics that you are trying to discuss?

+ +

VICTORIA: Yeah, absolutely. You can tell if people are listening to what you're saying. They, like, lean in a little bit, or if they're not really wanting to relate to what you're saying, they're, like, crossing their arms in front of you. So, as someone who works in business development, I definitely pay a lot of attention [laughs] to all that stuff. But I'm curious, how did you go from being a model in India to founder and CEO where you are today?

+ +

SANGHMITRA: That's something that I would love to talk about, and also, it has to do from where I come from. So, I come from a very small village in the foothills of the Himalayas. There, I witnessed climate disasters firsthand. In 2013, there were a lot of cloudbursts happening in those areas. An entire village next to my village disappeared completely without a trace. And those were some moments in my life where I really felt like we live in a world where you can be far from Europe...for example, currently, I live in France, and here, when heat wave happens, we all suffer and people talk about it. But I have seen, like, the adverse effect of what it can lead to.

+ +

So, there was a part of me that always wanted to do something in terms of the impact that I create, like, with my work. So, I started doing modeling, which was something for myself as well to gain some confidence. At the same time, I worked with sustainable brands in India. I modeled for them, and then I discovered their work. I got inspired by it, and I realized that it's something that interests me a lot, and I wanted to pursue my studies in it to know more about it. So, that's when I came to France to pursue my master's in sustainable finance to discover more about this field and to see where I belong.

+ +

And finally, I founded Insusty, where I could see that I could bring my inspiration from the sustainable brands that I worked with. Whether it's from the fashion or, the food industry, or the travel industry, I could see the inspiration coming from there. At the same time, I could see how we need to create mass adoption through incentivizing climate action, which was something that I explored during my studies. And I kind of went with Insusty, and that was the beginning of my founder journey.

+ +

WILL: I have a question about the way you grew up, and you're saying in a village. Can you expound a little bit on that? Because you said, climate change wiped out an entire village. And so, when I saw that in the email, I was like, I don't think I've ever had a chance to actually talk to someone that lived in a village. I grew up in the United States. So, like, help paint that picture. When you say you grew up in a village, what do you mean by that? What was it like growing up in a village, and also, what do you mean by the next village got entirely wiped out?

+ +

SANGHMITRA: Yeah. Living in a village it's like being a part of a tiny, well-knitted community, and it's, like, everyone knows everyone. And sometimes it's good, sometimes it's bad because when people gossip, of course, it spreads like a wildfire. As well as when you need support and when you need help, this community is always there, too. So, the part of belonging to such a community and to kind of engage with people is something that I really enjoy about coming from a small village. And that's something that I oftentimes search in France, where I can be a part of such communities as well, where people inspire each other.

+ +

For example, currently, I'm a part of a wonderful community of women of color founders living in Europe. It's called Founderland. And it's thanks to Founderland that I found you then I could join this podcast. So, when it comes to the small village, this is what I really really love about it is the small knitted community we have.

+ +

When I say that the entire village next to my village disappeared, I mean that when there was the cloudburst in the mountain, the soil and everything drowned the entire village. So, there was a school, and we used to hear a story about the school, where the kids were told by the teachers to run because there is a cloudburst, and "We are about to die if we stay in this place."

+ +

And as a student, as a kid, what do you think first? You think about packing your bags instead of running. So, the kids ended up packing their bags before they could run, and by that time, it was too late. So, this is just one of the heartbreaking stories that I'm sharing with you right now, but it had been something that really left a mark in my life.

+ +

VICTORIA: I really appreciate you sharing that story because when I talk to people about climate change, I think it's really easy to get this nihilistic attitude about, well, climate change is going to kill us all in 20 years. So, why bother doing anything about it? And what I usually answer back is that climate change is already killing people.

+ +

And then, it's happening in your own neighborhood, even, like, you know, I live here in San Diego, and it's always between, like, 60 and 80 degrees every single day [chuckles], but our beaches are collapsing. There are neighborhoods that are more impacted by pollution than others and are experiencing environmental impacts from that and their health, and everything like that. So, I'm curious how it all comes together with what you're doing with Insusty and how you're inspiring people to take action towards sustainability in the here and now.

+ +

SANGHMITRA: Actually, I have a question for you and Will. I wanted to understand, for example, if you purchase something in terms of, for example, it's related to fashion, or it's related to food products, what is the criteria that's most important to you? And maybe probably you can tell me, like, the top three criteria that are most important for you when you buy something. And then, I would love to share how Insusty can help you buy better.

+ +

VICTORIA: When I'm looking to buy things, I look for, like, price. I want it to be reasonable, but I also don't want it to be so cheap that it means it's a really poor quality. So, I want to find that balance between, like, quality and price. And I do also care about sustainability, and, like, what is the background of the company that I'm buying it from? You know, what's their reputation? What's their, like, practices?

+ +

Like one example is, like, the rugs for your house. So, I like to buy rugs that are made from sustainable fabrics and dyes and that I can wash them because I have a dog. And so, that's kind of, like, what I think through when I buy things. But it's not always easy, especially with clothing, because it seems like anyone who makes clothing, there's just always this risk of it being sourced at some part in the manufacturing pipeline having to do with either child labor or really terrible sustainability practices.

+ +

WILL: Yeah. I would say, for me, early on, especially when I was growing up, we didn't have a lot of money, so it was just whatever is the cheapest, whatever we could afford at that moment. It wasn't really looking into the quality, or sustainability, or any of those items. Some of the stuff I look back on that I ate often, I'm like, whoa, man, that was not the best thing. But it was the cheapest, and it was what we ate and things like that.

+ +

So, now that I'm older, my wife has been talking to me about some of that stuff, and it's like, oh, I had no idea, because of the environment I grew up in, that, like, that's even affecting me. And that was kind of why I asked you about the village thing is because I feel like we can get in a bubble sometimes and not even be aware of what's happening to other people.

+ +

And I think, Victoria, you said something about people not understanding climate change. It's kind of tough at times to talk about climate change when you live in...where I'm at in Florida, it's like, okay, it gets hot, and then it gets cold. And yeah, we have a hurricane every now and then, but whenever you told the story about the village, it's like, oh, wow, like, that's a different game. That's a different level. I didn't even know about that.

+ +

So, I think that's kind of my journey now is I am starting to understand sustainability. I think a lot of times I still have that I grew up with nothing mindset and want to get the cheapest thing because sometimes buying sustainability is super expensive. So, that's why I'm glad that I'm talking to you, so maybe I can learn some of those things. So yeah, that's kind of been my journey with it.

+ +

SANGHMITRA: That's really wonderful to get your insights because now I can tell you confidently what we do. Basically, when I talk to people, it was generally the same thing that I asked them, "What's the most important thing when you buy, like, the top three most important things?" Sustainability was definitely one of them, but cost was always there. Regardless of the background that they are from, cost was something that they all thought about.

+ +

So, what we do at Insusty is that we incentivize individuals to do something good for the planet. It can be, for example, you want to volunteer at an NGO next to your place. You want to get rewarded. So, what we do is we offer you loyalty points that help you to buy from sustainable brands. So, you try these products because, oftentimes, as Will also mentioned, there is a perception, and it's also a reality, that sustainable products tend to be more expensive. So, we try to deal with that by offering a loyalty program that incentivizes climate action.

+ +

And in terms of the sustainable brands, they get new customer base. They get to interact with these customers. They get to see their product and sites. What is something that the customers really like? What is something that can be improved? How can they improve in terms of their own sustainability and their impact? For example, their supply chain operations and so on. So, it's something that we provide them and help them also with insights as well as new customer base. We try to support them with that.

+ +

At the same time, on an individual level, we help with the cost factor, which is one of the most important things. When we want people to change, when we want people to adopt sustainable lifestyle, we kind of need to incentivize that so that mass adoption can be possible.

+ +

VICTORIA: So, I'm imagining, like, I want to know a new brand that I want to buy clothes from, like essential clothes. I could go into the app and, like, find companies that produce the thing that I want, and then I could get points and rewards for buying consistently from that brand.

+ +

SANGHMITRA: So, we are not like an actual loyalty program. So, you only receive points when you do something good for the planet. You don't receive points when you purchase from brands. This is a loyalty program where we give you points when you do something good for the planet, for example, donations. For NGOs, we have volunteer programs that individuals can participate in and receive loyalty points. But in the future, we are ambitious, and we want to go far. And we think that each and every activity of an individual can be tracked in terms of sustainability, how they are segregating their waste at home, how they're managing that, and so on, and give them points for each of their eco actions.

+ +

VICTORIA: Awesome. Yeah. Okay. I love that. Yeah. So, what kind of things would earn me points, like, in my home ownership here?

+ +

SANGHMITRA: If you volunteer with an NGO nearby or if you would like to participate in an event, for example, if you want to donate clothes, all these eco actions can give you loyalty points for the moment. And in the future, we want to also track the actions that you do at home. You save electricity, for example. You want to walk to the office instead of taking a cab, and all these activities, so that we can kind of make the experience also for the user a bit more like a game so that they enjoy doing it at the same time they receive rewards. And they can make purchases as well with the sustainable brands on our platform.

+ +

VICTORIA: I like that because I've been talking with my partner about how do we live more sustainably, or how do we, like, reduce our consumption or give back. And I think if it was gamified and we got points for it, it's more motivating because then you also see that other people are doing it as well. And so, you're part of a community that's all trying to take the same action. And that will have a bigger impact than just one individual, right?

+ +

SANGHMITRA: Yes, definitely. And we do have that feature on our platform where you could see near your area who donated and who is working in a particular NGO, so based on the fact that if the individual is comfortable in sharing that. Most of the time, when someone does something good for the planet, they would love to show it to the rest of the world. So, we have seen that people love to share their experiences and their badges, saying that, okay, they donated, for example, five euros to this NGO, and so on. So, they really love that. And it feels also really good to see this community and to get inspired by it.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

WILL: I think it's going to take all of us doing something to help with climate change and to make a difference. So, I like how you're incentivizing. You're making a difference. You say you get reward points. So, once I do an item or an action and I get reward points, what does that look like on the backend of it?

+ +

SANGHMITRA: For the individuals they have a dashboard to track their actions. They have a dashboard to also track what they are purchasing. So, if they're purchasing food or they're purchasing more items related to fashion, they can also check that. They can check the total number of points that they have received so far, where they have used it, and so on. And at the backend, for us, we see it as the total number of transactions that are taking place, so, for example, how the loyalty point is being used.

+ +

So, we have APIs that are in place between our platform and the platforms of other sustainable brands in our network. So, in our backend, we can see the transactions; for example, an individual used 100 points to get 10% off from one of the sustainable brands on our platform. And in terms of the sustainable brand side, even they have their own dashboard. They can also track how many individuals are using their points on their platform, and so on. So, they also have access to their own analytics dashboard. And through the same application, they can also provide us the payments through subscription and transaction fees.

+ +

VICTORIA: Yeah, that's really interesting. And so, I understand that you've been in the journey for a little while now. And I'm curious: if you go back to when you first got started, what was surprising to you in the discovery phase and maybe caused you to pivot and change strategy?

+ +

SANGHMITRA: So, one thing that I pivoted with was the type of brands that we wanted to onboard. Before, we had a very open approach; for example, we want brands that are sustainable, or if they are upcycling, or if they have, like, a particular social impact attached to it or an environmental impact attached to it. So, we were focusing on having the horizons a bit like the aspects of choosing a sustainable brand to be a partner. It was a bit broader for us.

+ +

But when we talked with the people, they wanted a niche. For example, they wanted upcycle products. They wanted more brands in the circular economy domain. And that's when we realized that we need to have a niche. So, we focus on the brands that are more linked towards circular economy that are promoting the values of recycling, upcycling, and reusing the products.

+ +

So, that was when we pivoted with the idea that we should not be open to all sustainable brands. However, we need to be really accurate with our approach. We need to focus on a particular niche. At the same time, we need to also make sure that we measure their impact and report it to our customers to ensure transparency on our platform. So, that became a priority more than having more and more brands on our platform.

+ +

WILL: Yeah, I really...that was actually one of my questions I was going to ask you because I like how you are vetting them because I've, especially here in the States, I've seen, like, companies, like, slap 'non-GMO' or 'gluten-free.' And it's like, well, it doesn't even have wheat in it, so, like, yeah, it's gluten-free. So, it's like, it's more of a marketing thing than actually, like, helping out. So, I'm glad you're vetting that. How has that process going for you?

+ +

SANGHMITRA: It's actually going really well, and we have established a five-step onboarding process. And in the first two steps, we also focus on measuring their impact. We have a self-evaluation form. We also check if they have some existing certificates. We also make sure that we have enough data about their supply chain and how they are working. And these are some of the information that we also share with our consumers, the one who would be interested to buy products from these brands, to make sure that we are transparent in our approach.

+ +

There's also one more thing that we do. It's the quarterly reporting. So, every three months, we also report the individuals who are buying from sustainable brands on our platform that, okay, this brand did better this quarter because they implemented a process that, for example, is reducing a certain amount of emissions from their supply chain, or any other departments. So, these are some of the information that we also share with the individuals.

+ +

VICTORIA: And what does success look like now versus six months from now or five years from now?

+ +

SANGHMITRA: For the moment, success would look like for me to have more connections, more people who support our project and our initiative, and the more people joining us. In terms of the next six months, I think it would be linked to fundraising. But I wouldn't go so far at the moment because, for me, I take one day at a time. And this is something that has been super helpful for me to streamline my tasks. So, I take one day at a time, and it's working really well for me.

+ +

WILL: What are some of your upcoming hurdles that you see?

+ +

SANGHMITRA: When I talk about hurdles, I often see it in two parts, one being the internal hurdles and the other one being external. So, in terms of the internal hurdles, it can be something like I'm putting myself in a box that, okay, I'm a single woman founder. How can I do something good? And just doubting myself and things like that. These are some of the internal hurdles that I'm working on every day [chuckles]. I'm also talking to executive coaches to get their advice on how I can improve myself as well to overcome these internal hurdles.

+ +

However, in terms of the external hurdles, these are some things that are not in my control, but I try my best to make the most of it. Currently, in terms of the external hurdles, I would say that I live in a country where I used to not even speak the language. So, initially, the hurdle that I experienced was mostly the cultural hurdle. But now it's more related to the fact that I am a single female founder, and there are perceptions around it that you need to have a co-founder. And there are a lot of different noises everywhere that doesn't allow you to grow.

+ +

VICTORIA: And you're not just a founder, but you're also an author. And I wanted to ask you a little bit about your book, the Sustainability Pendulum. Can you share a little bit about what it is and why you wrote it?

+ +

SANGHMITRA: So, Sustainability Pendulum is the book that I wrote last year, and I always wanted to write it. And last year, I put myself to work, and I was like, at least every day, I'm going to try and write one page, and probably by the end of the year, I can finish the book [chuckles], and that's what I did. I had to be super consistent. But I came up with Sustainability Pendulum, and it's about the stories from the past and the sustainable approaches that we had in the past, how we used to...in different religions, we have some stories written in the scriptures related to sustainable practices.

+ +

And oftentimes, when we talk about sustainability today, we talk about the future. We talk about implementing different technologies and, doing a lot of innovations, and so on. However, we don't look into the past and see how efficiently things were handled when it came to sustainability in the past. And these are some of the stories from the past, from different religions, and how it transcends to today's sustainability issues and solutions. So, that's what the book is about. And why it's called the pendulum, it's because how the pendulum moves. I think it's obvious [laughs], so the pendulum's to and fro motion. It goes to the past, and it goes to the future. So, that was the whole concept behind the sustainability pendulum.

+ +

WILL: That's amazing that you wrote a book, much, much respect on that. I am not an author, so...And I also know because my wife she's been talking about writing a book and the different challenges with that. So, kudos on writing a book. Would you write another one?

+ +

SANGHMITRA: Actually, I would love to. I'm just looking for something that equally inspires me how it did for the last one. But I think once you come out of that space and you're consistent with writing the book or consistently working to achieve something, I think eventually it comes to you. So, I don't know what are the challenges that your wife mentions that she faced in writing the book.

+ +

WILL: Like, having enough to write about, like you said, just sitting down each day writing a book. And I think publishing a book is tough. I know we've come a long ways, like, you can self-publish now instead of going through publishing companies, and just those different avenues of how many steps it takes. It's not just writing a book, sitting down and writing a book, and sharing with everyone. It's multiple steps that you have to go through.

+ +

SANGHMITRA: Definitely. I couldn't agree more with you on this one. Just to add to it, how I managed to do this was also because I structured the book earlier. And in order to also publish it, I realized that I don't want to wait. And I self-published the book as soon as I found out that, okay, this is perfect, and it's ready. I need to just move forward with it. What helped me as well was the way I structured the book earlier. And then, I was like, okay, every day, this is what I'm going to work on. And it kind of helped me to get to the end of it.

+ +

WILL: That's awesome. I like how you had forethought and how it made it easier for you to come up with ideas and write it. So, that's awesome.

+ +

SANGHMITRA: I wish the best to your wife as well for her book. And I hope that once it's ready, you will let me know about it.

+ +

WILL: Yes, I definitely will. You're talking about being a woman founder who is single. I don't want to assume. So, why is it tough for you to be a woman founder who's single?

+ +

SANGHMITRA: When I say single female founder, it means that I don't have a co-founder. It's not, like, my relationship status but just [laughs] the fact that...

+ +

WILL: Yes. Yes.

+ +

[laughter]

+ +

SANGHMITRA: Just that I am a single founder, like, then I don't have a co-founder, which oftentimes poses as a risk, especially when you talk to an investor. This is what I feel based on my experience. But I think the times are changing, and I feel that the more the project is growing, the better it is getting in terms of the people who are interested as well to be a part of Insusty as an investor or as a partner. Things have become better now than they were a few years ago. So, I can see the change.

+ +

But, initially, I did used to feel low about it that, okay, I'm a single female founder, and oftentimes, it was considered as a challenge. But if you take my perspective, I think, for me personally, it possibly was also one of my biggest strengths because I could be that one person going to the meetings, and I felt that people were more open to share things. They did not feel threatened by me. And that was something that really helped me to also form connections with people.

+ +

VICTORIA: I love how you connect having a small community in your village where you grew up to creating a community around yourself as a founder and having a village that supports you, and you feel comfortable around the community as well, and as part of that community. If you could go back in time and give yourself some advice when you were first getting started with Insusty, what advice would you give yourself?

+ +

SANGHMITRA: Slow is good. When I say that, I mean that every time we talk about different startups and different companies, and it's always about how rapidly the startup is growing, how exponentially they are growing, and so on. But I feel that in terms of when you really want to create an impact, and you are in the green tech space as well, being slow and getting somewhere is better than going fast and then having a burnout. So, one of the things that I would tell myself when I just started would be slow is good.

+ +

WILL: Even with coding and a lot of things in life, I feel like that's really good advice: slow is good. Slow down––enjoy the moment. So, I like that advice.

+ +

VICTORIA: I was going to say, it sounds like a more sustainable pace for yourself also [laughs].

+ +

SANGHMITRA: Exactly.

+ +

VICTORIA: Sustainability in the environment, and also in our own energy, and emotions, and motivation to get things done. So, I love that.

+ +

WILL: I see what you did there [laughter].

+ +

VICTORIA: Yeah, [inaudible 30:40] all back. Do you have anything else that you'd like to promote?

+ +

SANGHMITRA: I would really love to also tell people that I'm very open to communication. So, if anyone would like to reach out to me on LinkedIn, it would be really awesome, and we can get on a call as well. I have my Calendly link right on my profile, and I'm very open to communication. So, if there is someone who would like to talk to me about any of the things that interest them or probably something that they could advise me or I could learn from them, I'm more than open to do so.

+ +

VICTORIA: Love that. And then, do you have any questions for me or Will?

+ +

SANGHMITRA: So, in terms of the development part, I do have some questions, like, in the technical side. So, when it comes to the fact that we have to kind of calculate the eco actions of individuals in the future, we want to also see if we can calculate the daily actions that they do, for example, walking instead of taking a cab, or segregating their waste, et cetera. I wanted to know, in the future, I want to implement these features, but can we actually get a perfect product around it? Is that possible where we can track everything?

+ +

WILL: Yeah. So, when you say track everything, like, I know you talked about walking and some of the different actions. Can you expound on that?

+ +

SANGHMITRA: For example, instead of IoTs...because I know that some hotels they do use IoT devices to track the water consumption, and so on. However, on an individual level, how can we just track it through the smartphone or through the app that they have? Because, okay, walking can be tracked. This is actually one of the challenges I'm facing, so I want to just be open about it, and I'm very open to ideas also. If you have some ideas that I could experiment around, I would really love to. In terms of the activities like walking, waste disposal, and so on, do you think that there are some kind of features that we could implement to track these actions?

+ +

One of the things that I was thinking about was we let people take a photo of how they are segregating the waste in the end, and through that, we can tell them, "Okay, this is great," and we give them the points. But how can we do it and also automate it at the same time?

+ +

VICTORIA: So, one approach that I know when people work at thoughtbot on these types of issues and trying to figure out, like, what is the right feature? How are we going to implement this? Going through a product design sprint where you spend a week with a product designer and someone who can, you know, really quickly create MVPs. And you go through this process of figuring out what's the most important feature. And you're talking to users, and you're trying to...you're going through that discovery process in a short period. And we actually have a video series where we walk through every step of that process.

+ +

But, like, for me personally, things that I can think of in my life that I would want to track one thing I've been trying to do more is actually electronic recycling, which in the U.S. my neighborhood is different. It's only open on, like, Thursdays and Saturdays. And I have to, like, really remember to go out there and, like, put my electronics out there. And I don't think it's very, like, well-known. So, I think that would be something interesting to, like, promote as possible.

+ +

And we also have the green bins now, which are new, which allow you in California to, like, have composting. So, you have now your regular trash, your recycling, and your compost bins. So, actually, like, trying to use those and track them. Otherwise, one of the things I think about is, like, reducing the amount of plastic consumption, which includes things like, you know, when you buy toilet paper, it comes wrapped in plastic. How can I incentivize myself and my partner and even my family to, like, switch away from those types of products and get more into, you know, using towels instead of paper towels or finding alternative methods for getting those products while reducing the amount of plastic that comes with it?

+ +

SANGHMITRA: That's super interesting. I'm really, really glad to have your insights as well. I do have a question for you. Have you worked with startups in the field of impact? And if so, what have been some of the ideas that you really loved to implement?

+ +

VICTORIA: Yeah, actually, we had another guest on the Giant Robots podcast who I think you're connected with as well who created essentially, like, a GoFundMe but for environmental projects and in areas that, you know, a 5,000 grant to help do a beach cleanup could have a really big impact. Like funding programs and marketplace for those types of green projects in areas that are the most impacted by climate change and have the fewest resources to actually do anything about it.

+ +

So, I thought that was really exciting in trying to figure out how can we use tech to solve problems for real people, and for people that don't typically get the focus or the majority of the funding, or the majority of time spent in those communities. So, that, I think, is what is really exciting: to see people come from those communities and then figure out how to build solutions to serve them.

+ +

SANGHMITRA: That's really wonderful. Is there, like, a specific market where you have seen growth of such startups and companies more? The companies especially you have worked with in the past and in there in the field of impact, are they mostly from the U.S., or which are the markets they are from essentially?

+ +

VICTORIA: Yeah. So, I mean, I'm from the U.S., so that's where I see the most. I'm in San Diego. So, when I go to, like, startup weeks and things like that, that's where I'm getting the majority of my exposure. I do also know that there is a Bloomberg Center focusing on excellence and data in the governments. And that's not just U.S.-based but going more global as well, so trying to teach civic leaders how they can use the data about whether it's sustainability or other issues that they're facing too, like, figure out how to prioritize their funding and in what projects they're going to invest in from there. So, I think that's really interesting.

+ +

I don't know, I don't know what the answer is, but I know that there are some countries that are hoping to make the investments in sustainability and ecotourism, as opposed to allowing industry to come in and do whatever they want [laughs]. So, I don't know if that answers your question or not.

+ +

SANGHMITRA: Yeah, I think it completely answers my question. Thank you for sharing that and also a bit more.

+ +

WILL: There's so many things that I've learned through the podcast. So, I'm excited to see the impact it has. And I think you're doing an amazing job.

+ +

VICTORIA: Thank you so much for coming on and being with us here today and sharing your story.

+ +

SANGHMITRA: Thank you.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@ giantrobots.fm. And you can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Mastodon @thoughtbot.social@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Victoria Guido chat with Sanghmitra Bhardwaj, CEO and Founder of Insusty. Sanghmitra shares her journey from a small village in the foothills of the Himalayas to becoming a founder in France, driven by firsthand experiences with climate disasters and a passion for sustainable living. Insusty, a sustainability loyalty program, is a platform incentivizing individuals to adopt climate-positive actions through rewards, thereby fostering a community motivated towards environmental stewardship.

+ +

The show digs into the mechanics and vision of Insusty, highlighting how the platform rewards eco-friendly actions like volunteering and donating, rather than purchases. This approach aims to bridge the gap between the desire for sustainable living and the practical challenges individuals face, such as the perceived high costs of sustainable products. Sanghmitra reveals the evolution of Insusty, including strategic pivots towards niche markets within the circular economy and the importance of transparency and impact measurement in building trust with consumers.

+ +

Towards the episode's conclusion, the conversation shifts to broader implications of sustainability in technology and business. Sanghmitra expresses curiosity about future expansions of Insusty, particularly in tracking and rewarding individual daily eco-actions more effectively. She also touches upon the challenges and triumphs of being a solo female founder in the tech and sustainability sectors, underscoring the significance of community, perseverance, and innovation in driving change.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. With me today is Sanghmitra Bhardwaj, CEO and Founder of Insusty, a sustainability loyalty program for individuals. Sanghmitra, thank you for joining us.

+ +

SANGHMITRA: Thank you so much for having me here. I'm super excited for the podcast and to discuss various topics that we are about to. And I'm sure that it's going to be a learning experience, not just for the audience, but also for me. So, thank you for this opportunity.

+ +

VICTORIA: Why don't we just start off getting to know you a little bit? Tell us something exciting going on in your life, maybe outside of work.

+ +

SANGHMITRA: Okay, so, well, recently, I joined a pole dancing class. I wanted to challenge myself and see if I have the core strength that I need to be strong. And I also feel that it's something that I always wanted to do to come out of my comfort zone. So, it's been fun so far.

+ +

VICTORIA: I tried that, and I thought that I would naturally be good at it because I'm a rock climber. And so, I thought I'd have all the right muscle groups, but the coordination and [laughs], like, expression of it is still challenging if you've never done it before.

+ +

SANGHMITRA: Yeah, definitely. And I think there are some techniques and if you don't do it right, like, you will not get it at all, those poses and, like, how you climb the pole and everything. So, I completely relate to your experience here.

+ +

VICTORIA: I want to do more dance, actually, because the mind-body connection and getting into that feeling of flow is really interesting for me. And I think it's like expressing through your body, which 80% of communication is non-verbal, which is really interesting.

+ +

SANGHMITRA: Yeah, that's true. Just to add to it, I wanted to also share with you that I used to do modeling back in India, and I really love expressing myself with my body. And it's been super interesting to see that. And also, when I have conversations with other people, these are the things that I observe a lot. Is it the same for you? Do you also observe other people's body language when they are talking to you and probably change some topics that you are trying to discuss?

+ +

VICTORIA: Yeah, absolutely. You can tell if people are listening to what you're saying. They, like, lean in a little bit, or if they're not really wanting to relate to what you're saying, they're, like, crossing their arms in front of you. So, as someone who works in business development, I definitely pay a lot of attention [laughs] to all that stuff. But I'm curious, how did you go from being a model in India to founder and CEO where you are today?

+ +

SANGHMITRA: That's something that I would love to talk about, and also, it has to do from where I come from. So, I come from a very small village in the foothills of the Himalayas. There, I witnessed climate disasters firsthand. In 2013, there were a lot of cloudbursts happening in those areas. An entire village next to my village disappeared completely without a trace. And those were some moments in my life where I really felt like we live in a world where you can be far from Europe...for example, currently, I live in France, and here, when heat wave happens, we all suffer and people talk about it. But I have seen, like, the adverse effect of what it can lead to.

+ +

So, there was a part of me that always wanted to do something in terms of the impact that I create, like, with my work. So, I started doing modeling, which was something for myself as well to gain some confidence. At the same time, I worked with sustainable brands in India. I modeled for them, and then I discovered their work. I got inspired by it, and I realized that it's something that interests me a lot, and I wanted to pursue my studies in it to know more about it. So, that's when I came to France to pursue my master's in sustainable finance to discover more about this field and to see where I belong.

+ +

And finally, I founded Insusty, where I could see that I could bring my inspiration from the sustainable brands that I worked with. Whether it's from the fashion or, the food industry, or the travel industry, I could see the inspiration coming from there. At the same time, I could see how we need to create mass adoption through incentivizing climate action, which was something that I explored during my studies. And I kind of went with Insusty, and that was the beginning of my founder journey.

+ +

WILL: I have a question about the way you grew up, and you're saying in a village. Can you expound a little bit on that? Because you said, climate change wiped out an entire village. And so, when I saw that in the email, I was like, I don't think I've ever had a chance to actually talk to someone that lived in a village. I grew up in the United States. So, like, help paint that picture. When you say you grew up in a village, what do you mean by that? What was it like growing up in a village, and also, what do you mean by the next village got entirely wiped out?

+ +

SANGHMITRA: Yeah. Living in a village it's like being a part of a tiny, well-knitted community, and it's, like, everyone knows everyone. And sometimes it's good, sometimes it's bad because when people gossip, of course, it spreads like a wildfire. As well as when you need support and when you need help, this community is always there, too. So, the part of belonging to such a community and to kind of engage with people is something that I really enjoy about coming from a small village. And that's something that I oftentimes search in France, where I can be a part of such communities as well, where people inspire each other.

+ +

For example, currently, I'm a part of a wonderful community of women of color founders living in Europe. It's called Founderland. And it's thanks to Founderland that I found you then I could join this podcast. So, when it comes to the small village, this is what I really really love about it is the small knitted community we have.

+ +

When I say that the entire village next to my village disappeared, I mean that when there was the cloudburst in the mountain, the soil and everything drowned the entire village. So, there was a school, and we used to hear a story about the school, where the kids were told by the teachers to run because there is a cloudburst, and "We are about to die if we stay in this place."

+ +

And as a student, as a kid, what do you think first? You think about packing your bags instead of running. So, the kids ended up packing their bags before they could run, and by that time, it was too late. So, this is just one of the heartbreaking stories that I'm sharing with you right now, but it had been something that really left a mark in my life.

+ +

VICTORIA: I really appreciate you sharing that story because when I talk to people about climate change, I think it's really easy to get this nihilistic attitude about, well, climate change is going to kill us all in 20 years. So, why bother doing anything about it? And what I usually answer back is that climate change is already killing people.

+ +

And then, it's happening in your own neighborhood, even, like, you know, I live here in San Diego, and it's always between, like, 60 and 80 degrees every single day [chuckles], but our beaches are collapsing. There are neighborhoods that are more impacted by pollution than others and are experiencing environmental impacts from that and their health, and everything like that. So, I'm curious how it all comes together with what you're doing with Insusty and how you're inspiring people to take action towards sustainability in the here and now.

+ +

SANGHMITRA: Actually, I have a question for you and Will. I wanted to understand, for example, if you purchase something in terms of, for example, it's related to fashion, or it's related to food products, what is the criteria that's most important to you? And maybe probably you can tell me, like, the top three criteria that are most important for you when you buy something. And then, I would love to share how Insusty can help you buy better.

+ +

VICTORIA: When I'm looking to buy things, I look for, like, price. I want it to be reasonable, but I also don't want it to be so cheap that it means it's a really poor quality. So, I want to find that balance between, like, quality and price. And I do also care about sustainability, and, like, what is the background of the company that I'm buying it from? You know, what's their reputation? What's their, like, practices?

+ +

Like one example is, like, the rugs for your house. So, I like to buy rugs that are made from sustainable fabrics and dyes and that I can wash them because I have a dog. And so, that's kind of, like, what I think through when I buy things. But it's not always easy, especially with clothing, because it seems like anyone who makes clothing, there's just always this risk of it being sourced at some part in the manufacturing pipeline having to do with either child labor or really terrible sustainability practices.

+ +

WILL: Yeah. I would say, for me, early on, especially when I was growing up, we didn't have a lot of money, so it was just whatever is the cheapest, whatever we could afford at that moment. It wasn't really looking into the quality, or sustainability, or any of those items. Some of the stuff I look back on that I ate often, I'm like, whoa, man, that was not the best thing. But it was the cheapest, and it was what we ate and things like that.

+ +

So, now that I'm older, my wife has been talking to me about some of that stuff, and it's like, oh, I had no idea, because of the environment I grew up in, that, like, that's even affecting me. And that was kind of why I asked you about the village thing is because I feel like we can get in a bubble sometimes and not even be aware of what's happening to other people.

+ +

And I think, Victoria, you said something about people not understanding climate change. It's kind of tough at times to talk about climate change when you live in...where I'm at in Florida, it's like, okay, it gets hot, and then it gets cold. And yeah, we have a hurricane every now and then, but whenever you told the story about the village, it's like, oh, wow, like, that's a different game. That's a different level. I didn't even know about that.

+ +

So, I think that's kind of my journey now is I am starting to understand sustainability. I think a lot of times I still have that I grew up with nothing mindset and want to get the cheapest thing because sometimes buying sustainability is super expensive. So, that's why I'm glad that I'm talking to you, so maybe I can learn some of those things. So yeah, that's kind of been my journey with it.

+ +

SANGHMITRA: That's really wonderful to get your insights because now I can tell you confidently what we do. Basically, when I talk to people, it was generally the same thing that I asked them, "What's the most important thing when you buy, like, the top three most important things?" Sustainability was definitely one of them, but cost was always there. Regardless of the background that they are from, cost was something that they all thought about.

+ +

So, what we do at Insusty is that we incentivize individuals to do something good for the planet. It can be, for example, you want to volunteer at an NGO next to your place. You want to get rewarded. So, what we do is we offer you loyalty points that help you to buy from sustainable brands. So, you try these products because, oftentimes, as Will also mentioned, there is a perception, and it's also a reality, that sustainable products tend to be more expensive. So, we try to deal with that by offering a loyalty program that incentivizes climate action.

+ +

And in terms of the sustainable brands, they get new customer base. They get to interact with these customers. They get to see their product and sites. What is something that the customers really like? What is something that can be improved? How can they improve in terms of their own sustainability and their impact? For example, their supply chain operations and so on. So, it's something that we provide them and help them also with insights as well as new customer base. We try to support them with that.

+ +

At the same time, on an individual level, we help with the cost factor, which is one of the most important things. When we want people to change, when we want people to adopt sustainable lifestyle, we kind of need to incentivize that so that mass adoption can be possible.

+ +

VICTORIA: So, I'm imagining, like, I want to know a new brand that I want to buy clothes from, like essential clothes. I could go into the app and, like, find companies that produce the thing that I want, and then I could get points and rewards for buying consistently from that brand.

+ +

SANGHMITRA: So, we are not like an actual loyalty program. So, you only receive points when you do something good for the planet. You don't receive points when you purchase from brands. This is a loyalty program where we give you points when you do something good for the planet, for example, donations. For NGOs, we have volunteer programs that individuals can participate in and receive loyalty points. But in the future, we are ambitious, and we want to go far. And we think that each and every activity of an individual can be tracked in terms of sustainability, how they are segregating their waste at home, how they're managing that, and so on, and give them points for each of their eco actions.

+ +

VICTORIA: Awesome. Yeah. Okay. I love that. Yeah. So, what kind of things would earn me points, like, in my home ownership here?

+ +

SANGHMITRA: If you volunteer with an NGO nearby or if you would like to participate in an event, for example, if you want to donate clothes, all these eco actions can give you loyalty points for the moment. And in the future, we want to also track the actions that you do at home. You save electricity, for example. You want to walk to the office instead of taking a cab, and all these activities, so that we can kind of make the experience also for the user a bit more like a game so that they enjoy doing it at the same time they receive rewards. And they can make purchases as well with the sustainable brands on our platform.

+ +

VICTORIA: I like that because I've been talking with my partner about how do we live more sustainably, or how do we, like, reduce our consumption or give back. And I think if it was gamified and we got points for it, it's more motivating because then you also see that other people are doing it as well. And so, you're part of a community that's all trying to take the same action. And that will have a bigger impact than just one individual, right?

+ +

SANGHMITRA: Yes, definitely. And we do have that feature on our platform where you could see near your area who donated and who is working in a particular NGO, so based on the fact that if the individual is comfortable in sharing that. Most of the time, when someone does something good for the planet, they would love to show it to the rest of the world. So, we have seen that people love to share their experiences and their badges, saying that, okay, they donated, for example, five euros to this NGO, and so on. So, they really love that. And it feels also really good to see this community and to get inspired by it.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

WILL: I think it's going to take all of us doing something to help with climate change and to make a difference. So, I like how you're incentivizing. You're making a difference. You say you get reward points. So, once I do an item or an action and I get reward points, what does that look like on the backend of it?

+ +

SANGHMITRA: For the individuals they have a dashboard to track their actions. They have a dashboard to also track what they are purchasing. So, if they're purchasing food or they're purchasing more items related to fashion, they can also check that. They can check the total number of points that they have received so far, where they have used it, and so on. And at the backend, for us, we see it as the total number of transactions that are taking place, so, for example, how the loyalty point is being used.

+ +

So, we have APIs that are in place between our platform and the platforms of other sustainable brands in our network. So, in our backend, we can see the transactions; for example, an individual used 100 points to get 10% off from one of the sustainable brands on our platform. And in terms of the sustainable brand side, even they have their own dashboard. They can also track how many individuals are using their points on their platform, and so on. So, they also have access to their own analytics dashboard. And through the same application, they can also provide us the payments through subscription and transaction fees.

+ +

VICTORIA: Yeah, that's really interesting. And so, I understand that you've been in the journey for a little while now. And I'm curious: if you go back to when you first got started, what was surprising to you in the discovery phase and maybe caused you to pivot and change strategy?

+ +

SANGHMITRA: So, one thing that I pivoted with was the type of brands that we wanted to onboard. Before, we had a very open approach; for example, we want brands that are sustainable, or if they are upcycling, or if they have, like, a particular social impact attached to it or an environmental impact attached to it. So, we were focusing on having the horizons a bit like the aspects of choosing a sustainable brand to be a partner. It was a bit broader for us.

+ +

But when we talked with the people, they wanted a niche. For example, they wanted upcycle products. They wanted more brands in the circular economy domain. And that's when we realized that we need to have a niche. So, we focus on the brands that are more linked towards circular economy that are promoting the values of recycling, upcycling, and reusing the products.

+ +

So, that was when we pivoted with the idea that we should not be open to all sustainable brands. However, we need to be really accurate with our approach. We need to focus on a particular niche. At the same time, we need to also make sure that we measure their impact and report it to our customers to ensure transparency on our platform. So, that became a priority more than having more and more brands on our platform.

+ +

WILL: Yeah, I really...that was actually one of my questions I was going to ask you because I like how you are vetting them because I've, especially here in the States, I've seen, like, companies, like, slap 'non-GMO' or 'gluten-free.' And it's like, well, it doesn't even have wheat in it, so, like, yeah, it's gluten-free. So, it's like, it's more of a marketing thing than actually, like, helping out. So, I'm glad you're vetting that. How has that process going for you?

+ +

SANGHMITRA: It's actually going really well, and we have established a five-step onboarding process. And in the first two steps, we also focus on measuring their impact. We have a self-evaluation form. We also check if they have some existing certificates. We also make sure that we have enough data about their supply chain and how they are working. And these are some of the information that we also share with our consumers, the one who would be interested to buy products from these brands, to make sure that we are transparent in our approach.

+ +

There's also one more thing that we do. It's the quarterly reporting. So, every three months, we also report the individuals who are buying from sustainable brands on our platform that, okay, this brand did better this quarter because they implemented a process that, for example, is reducing a certain amount of emissions from their supply chain, or any other departments. So, these are some of the information that we also share with the individuals.

+ +

VICTORIA: And what does success look like now versus six months from now or five years from now?

+ +

SANGHMITRA: For the moment, success would look like for me to have more connections, more people who support our project and our initiative, and the more people joining us. In terms of the next six months, I think it would be linked to fundraising. But I wouldn't go so far at the moment because, for me, I take one day at a time. And this is something that has been super helpful for me to streamline my tasks. So, I take one day at a time, and it's working really well for me.

+ +

WILL: What are some of your upcoming hurdles that you see?

+ +

SANGHMITRA: When I talk about hurdles, I often see it in two parts, one being the internal hurdles and the other one being external. So, in terms of the internal hurdles, it can be something like I'm putting myself in a box that, okay, I'm a single woman founder. How can I do something good? And just doubting myself and things like that. These are some of the internal hurdles that I'm working on every day [chuckles]. I'm also talking to executive coaches to get their advice on how I can improve myself as well to overcome these internal hurdles.

+ +

However, in terms of the external hurdles, these are some things that are not in my control, but I try my best to make the most of it. Currently, in terms of the external hurdles, I would say that I live in a country where I used to not even speak the language. So, initially, the hurdle that I experienced was mostly the cultural hurdle. But now it's more related to the fact that I am a single female founder, and there are perceptions around it that you need to have a co-founder. And there are a lot of different noises everywhere that doesn't allow you to grow.

+ +

VICTORIA: And you're not just a founder, but you're also an author. And I wanted to ask you a little bit about your book, the Sustainability Pendulum. Can you share a little bit about what it is and why you wrote it?

+ +

SANGHMITRA: So, Sustainability Pendulum is the book that I wrote last year, and I always wanted to write it. And last year, I put myself to work, and I was like, at least every day, I'm going to try and write one page, and probably by the end of the year, I can finish the book [chuckles], and that's what I did. I had to be super consistent. But I came up with Sustainability Pendulum, and it's about the stories from the past and the sustainable approaches that we had in the past, how we used to...in different religions, we have some stories written in the scriptures related to sustainable practices.

+ +

And oftentimes, when we talk about sustainability today, we talk about the future. We talk about implementing different technologies and, doing a lot of innovations, and so on. However, we don't look into the past and see how efficiently things were handled when it came to sustainability in the past. And these are some of the stories from the past, from different religions, and how it transcends to today's sustainability issues and solutions. So, that's what the book is about. And why it's called the pendulum, it's because how the pendulum moves. I think it's obvious [laughs], so the pendulum's to and fro motion. It goes to the past, and it goes to the future. So, that was the whole concept behind the sustainability pendulum.

+ +

WILL: That's amazing that you wrote a book, much, much respect on that. I am not an author, so...And I also know because my wife she's been talking about writing a book and the different challenges with that. So, kudos on writing a book. Would you write another one?

+ +

SANGHMITRA: Actually, I would love to. I'm just looking for something that equally inspires me how it did for the last one. But I think once you come out of that space and you're consistent with writing the book or consistently working to achieve something, I think eventually it comes to you. So, I don't know what are the challenges that your wife mentions that she faced in writing the book.

+ +

WILL: Like, having enough to write about, like you said, just sitting down each day writing a book. And I think publishing a book is tough. I know we've come a long ways, like, you can self-publish now instead of going through publishing companies, and just those different avenues of how many steps it takes. It's not just writing a book, sitting down and writing a book, and sharing with everyone. It's multiple steps that you have to go through.

+ +

SANGHMITRA: Definitely. I couldn't agree more with you on this one. Just to add to it, how I managed to do this was also because I structured the book earlier. And in order to also publish it, I realized that I don't want to wait. And I self-published the book as soon as I found out that, okay, this is perfect, and it's ready. I need to just move forward with it. What helped me as well was the way I structured the book earlier. And then, I was like, okay, every day, this is what I'm going to work on. And it kind of helped me to get to the end of it.

+ +

WILL: That's awesome. I like how you had forethought and how it made it easier for you to come up with ideas and write it. So, that's awesome.

+ +

SANGHMITRA: I wish the best to your wife as well for her book. And I hope that once it's ready, you will let me know about it.

+ +

WILL: Yes, I definitely will. You're talking about being a woman founder who is single. I don't want to assume. So, why is it tough for you to be a woman founder who's single?

+ +

SANGHMITRA: When I say single female founder, it means that I don't have a co-founder. It's not, like, my relationship status but just [laughs] the fact that...

+ +

WILL: Yes. Yes.

+ +

[laughter]

+ +

SANGHMITRA: Just that I am a single founder, like, then I don't have a co-founder, which oftentimes poses as a risk, especially when you talk to an investor. This is what I feel based on my experience. But I think the times are changing, and I feel that the more the project is growing, the better it is getting in terms of the people who are interested as well to be a part of Insusty as an investor or as a partner. Things have become better now than they were a few years ago. So, I can see the change.

+ +

But, initially, I did used to feel low about it that, okay, I'm a single female founder, and oftentimes, it was considered as a challenge. But if you take my perspective, I think, for me personally, it possibly was also one of my biggest strengths because I could be that one person going to the meetings, and I felt that people were more open to share things. They did not feel threatened by me. And that was something that really helped me to also form connections with people.

+ +

VICTORIA: I love how you connect having a small community in your village where you grew up to creating a community around yourself as a founder and having a village that supports you, and you feel comfortable around the community as well, and as part of that community. If you could go back in time and give yourself some advice when you were first getting started with Insusty, what advice would you give yourself?

+ +

SANGHMITRA: Slow is good. When I say that, I mean that every time we talk about different startups and different companies, and it's always about how rapidly the startup is growing, how exponentially they are growing, and so on. But I feel that in terms of when you really want to create an impact, and you are in the green tech space as well, being slow and getting somewhere is better than going fast and then having a burnout. So, one of the things that I would tell myself when I just started would be slow is good.

+ +

WILL: Even with coding and a lot of things in life, I feel like that's really good advice: slow is good. Slow down––enjoy the moment. So, I like that advice.

+ +

VICTORIA: I was going to say, it sounds like a more sustainable pace for yourself also [laughs].

+ +

SANGHMITRA: Exactly.

+ +

VICTORIA: Sustainability in the environment, and also in our own energy, and emotions, and motivation to get things done. So, I love that.

+ +

WILL: I see what you did there [laughter].

+ +

VICTORIA: Yeah, [inaudible 30:40] all back. Do you have anything else that you'd like to promote?

+ +

SANGHMITRA: I would really love to also tell people that I'm very open to communication. So, if anyone would like to reach out to me on LinkedIn, it would be really awesome, and we can get on a call as well. I have my Calendly link right on my profile, and I'm very open to communication. So, if there is someone who would like to talk to me about any of the things that interest them or probably something that they could advise me or I could learn from them, I'm more than open to do so.

+ +

VICTORIA: Love that. And then, do you have any questions for me or Will?

+ +

SANGHMITRA: So, in terms of the development part, I do have some questions, like, in the technical side. So, when it comes to the fact that we have to kind of calculate the eco actions of individuals in the future, we want to also see if we can calculate the daily actions that they do, for example, walking instead of taking a cab, or segregating their waste, et cetera. I wanted to know, in the future, I want to implement these features, but can we actually get a perfect product around it? Is that possible where we can track everything?

+ +

WILL: Yeah. So, when you say track everything, like, I know you talked about walking and some of the different actions. Can you expound on that?

+ +

SANGHMITRA: For example, instead of IoTs...because I know that some hotels they do use IoT devices to track the water consumption, and so on. However, on an individual level, how can we just track it through the smartphone or through the app that they have? Because, okay, walking can be tracked. This is actually one of the challenges I'm facing, so I want to just be open about it, and I'm very open to ideas also. If you have some ideas that I could experiment around, I would really love to. In terms of the activities like walking, waste disposal, and so on, do you think that there are some kind of features that we could implement to track these actions?

+ +

One of the things that I was thinking about was we let people take a photo of how they are segregating the waste in the end, and through that, we can tell them, "Okay, this is great," and we give them the points. But how can we do it and also automate it at the same time?

+ +

VICTORIA: So, one approach that I know when people work at thoughtbot on these types of issues and trying to figure out, like, what is the right feature? How are we going to implement this? Going through a product design sprint where you spend a week with a product designer and someone who can, you know, really quickly create MVPs. And you go through this process of figuring out what's the most important feature. And you're talking to users, and you're trying to...you're going through that discovery process in a short period. And we actually have a video series where we walk through every step of that process.

+ +

But, like, for me personally, things that I can think of in my life that I would want to track one thing I've been trying to do more is actually electronic recycling, which in the U.S. my neighborhood is different. It's only open on, like, Thursdays and Saturdays. And I have to, like, really remember to go out there and, like, put my electronics out there. And I don't think it's very, like, well-known. So, I think that would be something interesting to, like, promote as possible.

+ +

And we also have the green bins now, which are new, which allow you in California to, like, have composting. So, you have now your regular trash, your recycling, and your compost bins. So, actually, like, trying to use those and track them. Otherwise, one of the things I think about is, like, reducing the amount of plastic consumption, which includes things like, you know, when you buy toilet paper, it comes wrapped in plastic. How can I incentivize myself and my partner and even my family to, like, switch away from those types of products and get more into, you know, using towels instead of paper towels or finding alternative methods for getting those products while reducing the amount of plastic that comes with it?

+ +

SANGHMITRA: That's super interesting. I'm really, really glad to have your insights as well. I do have a question for you. Have you worked with startups in the field of impact? And if so, what have been some of the ideas that you really loved to implement?

+ +

VICTORIA: Yeah, actually, we had another guest on the Giant Robots podcast who I think you're connected with as well who created essentially, like, a GoFundMe but for environmental projects and in areas that, you know, a 5,000 grant to help do a beach cleanup could have a really big impact. Like funding programs and marketplace for those types of green projects in areas that are the most impacted by climate change and have the fewest resources to actually do anything about it.

+ +

So, I thought that was really exciting in trying to figure out how can we use tech to solve problems for real people, and for people that don't typically get the focus or the majority of the funding, or the majority of time spent in those communities. So, that, I think, is what is really exciting: to see people come from those communities and then figure out how to build solutions to serve them.

+ +

SANGHMITRA: That's really wonderful. Is there, like, a specific market where you have seen growth of such startups and companies more? The companies especially you have worked with in the past and in there in the field of impact, are they mostly from the U.S., or which are the markets they are from essentially?

+ +

VICTORIA: Yeah. So, I mean, I'm from the U.S., so that's where I see the most. I'm in San Diego. So, when I go to, like, startup weeks and things like that, that's where I'm getting the majority of my exposure. I do also know that there is a Bloomberg Center focusing on excellence and data in the governments. And that's not just U.S.-based but going more global as well, so trying to teach civic leaders how they can use the data about whether it's sustainability or other issues that they're facing too, like, figure out how to prioritize their funding and in what projects they're going to invest in from there. So, I think that's really interesting.

+ +

I don't know, I don't know what the answer is, but I know that there are some countries that are hoping to make the investments in sustainability and ecotourism, as opposed to allowing industry to come in and do whatever they want [laughs]. So, I don't know if that answers your question or not.

+ +

SANGHMITRA: Yeah, I think it completely answers my question. Thank you for sharing that and also a bit more.

+ +

WILL: There's so many things that I've learned through the podcast. So, I'm excited to see the impact it has. And I think you're doing an amazing job.

+ +

VICTORIA: Thank you so much for coming on and being with us here today and sharing your story.

+ +

SANGHMITRA: Thank you.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@ giantrobots.fm. And you can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Mastodon @thoughtbot.social@vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

 AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+J9zqOYX- + + ]]> + + Will Larry + Victoria Guido + + + 520: Breaking New Ground in Maternal Mental Health with Mevi + https://podcast.thoughtbot.com/520 + a365b63a-b4d4-49bf-a43c-b08b27956996 + Thu, 11 Apr 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Will Larry and Victoria Guido chat with Zamina Karim, CEO and Founder of Mevi, about her innovative community-driven motherhood wellness app designed to revolutionize maternal health by addressing new mothers' emotional and practical needs. Zamina discusses her journey of overcoming postpartum anxiety and depression, the challenges of solo entrepreneurship, and the critical role of empathy in creating supportive communities for mothers. The conversation also explores the changing landscape of startup funding, the significance of adaptability, and the potential of technology to improve maternal health outcomes significantly. + 41:13 + no + + + Hosts Will Larry and Victoria Guido are joined by Zamina Karim, the CEO and Founder of Mevi, a community-driven motherhood wellness app designed to address the unique challenges of motherhood, especially in the context of the pandemic. Zamina shares her journey from experiencing postpartum anxiety and depression to founding Mevi. She discusses the lack of understanding and support for new mothers, especially during the pandemic when traditional support structures were unavailable. The conversation also touches on parenting challenges in the current era, underscoring the need for community and support. +The app aims to revolutionize maternal health by fostering connections among mothers and providing support for the challenges of motherhood beyond medical visits. Zamina's approach to building Mevi is rooted in empathy, aiming to address new mothers' emotional and practical needs and fill a significant gap in current maternal health support. +Zamina also talks about the broader implications of Mevi's mission, the evolving startup funding landscape, and the importance of pivoting and adapting in the entrepreneurial journey. She emphasizes the role of empathy in building inclusive experiences for parents and the potential of technology to improve maternal health outcomes. +Mevi (https://www.getmevi.com/) +Follow Mevi on LinkedIn (https://www.linkedin.com/company/getmevi/). +Follow Zamina Karim on LinkedIn (https://www.linkedin.com/in/zaminasunderjikarim/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: + WILL: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Zamina Karim, CEO and Founder of Mevi, the first-ever community-driven motherhood wellness app. Zamina, thank you for joining us. +ZAMINA: Thank you so much for having me. +VICTORIA: Well, outside of founding Mevi, what keeps you going? What's exciting for you right now in your world? +ZAMINA: Well, I have a toddler. She is two turning three, and she keeps me incredibly active and stimulated throughout the day. And I have my hands full with her throughout the day. And outside of that, I've just jumped into the business full-time. So, I'm navigating solo foundership and recognizing how different of an experience that is when you have been working in a team environment for the last 15 years or so. So, that's kind of what's been keeping me busy the last few months. +WILL: You mentioned your daughter. When you became a parent, I know there's something surprising; there's plenty. But what was the most surprising thing that you went through when you became a parent? +ZAMINA: Oh my gosh, there were so many things. You're totally right, Will. But I think, for me, it was a really big emphasis that I noticed on the products that I would need to have. And if I had all of those products, I would be ready and I would be well on my way, and parenting would be a breeze. And it kicked me on my butt when I realized that having the perfect car seat and the perfect stroller was not setting me up for success. +And there was a lot that I didn't know and didn't realize, even though I had done so much research and had a lot of other parents in my network. I think it's one of those things that you don't truly understand until you have experienced it yourself and you are living through it. +VICTORIA: So, then, what led you to start Mevi? +ZAMINA: Mevi was started because my baby was born during the pandemic, and I experienced a ton of challenges during that time. I struggled with symptoms of anxiety and depression for over a year. But I didn't really need any clinical diagnosis, and so no one knew how to help me in my family. And I did not know how to help myself either. And I really felt the Western sort of pressure of having to do it all. And I was quite frankly embarrassed by the struggles that I was experiencing. +And, you know, you never really go back to your old self. But once she turned one, I started to feel a little bit more balanced. And I came out of my shell, and I started speaking with other women from all over the world really. And I learned very quickly that my experience was the norm and not the exception. And that really was the inspiration to go ahead and try to solve that problem. +WILL: Yeah. I remember we had my middle child at the very beginning of July 2020. And the first thing that was rough is that was whenever they were like, "If you have COVID, we may have to separate you from your child when you have birth," and it was terrifying. And they ended up not doing that. We didn't have COVID or anything. But I remember, because we have three now, and I remember thinking, like, if I was a parent of a single child, it would have to be rough because, like, the child is not playing with anyone, and you're also by yourself. So, I totally relate with what you're saying. +ZAMINA: Yeah, absolutely. And then, beyond that, all of those kinds of traditional childcare centers or places where people would congregate were shut down. And up here in Canada, a lot of those places haven't really opened back up, and so there was no real bounce back to a pre-pandemic norm. A lot of families are now just navigating with this as the new normal. So, I think it's really important to recognize that parenting in 2021 and beyond is really different from what it was pre-pandemic. +VICTORIA: So, you had this acute need yourself to build a community to survive [laughs]. What in your background led you to think, oh, I could start a company around this; I could build the solution for this problem? +ZAMINA: Yeah, it's actually a really interesting mix of personal and more technical and career-driven. So, on a personal level, I was born in India, and my parents are from East Africa. So, that cultural element really bleeds into my perspectives and my values on life, as well as what's missing in healthcare today, so this idea of taking a prevention-focused approach or addressing root causes rather than addressing symptoms, which is a lot more common in today's kind of healthcare context. +And then, on a more career-based side, my background is in consumer tech, growth marketing. And I studied psychology and human development when I was in school. So, all of these areas really came together as the perfect combination for starting Mevi because I had this hard tech background. I know how to code. I self-taught Ruby on Rails about ten years ago. And then I'd worked in this consumer space, kind of selling things for companies like Masterclass, and Uber, and Lululemon, and Aritzia. And I had this experience on the paid acquisition side as well. +So, all of those things really came together for me to feel equipped to step into this journey of building Mevi. But I think no matter what technical or kind of soft skills you have, it is still a huge climb when building a company from scratch and, in particular, when you're doing it as a solo founder. +WILL: Wow, that's so amazing. I love your background, and I love especially talking to founders who have a technical background and kind of seeing how their journey was. Did your technical background help you in anything, or did you code your app? +ZAMINA: I did not code the app. Because I was on the tech side over a decade ago, so I was building apps about ten years ago; it's one of those muscles where it can very quickly atrophy. And things now are developing at such a rapid pace compared to when I was in the space that I'm no longer someone who would be best suited to actually code the app. I would be spending a lot of time relearning versus just delegating that to somebody else. +But I do possess the ability to talk to engineers and to be able to navigate some of the architecture and the fundamentals with them and that, for me, has been a really big game changer because I'm not completely lost when chatting with technical folks. And I can kind of navigate my way around with a little bit more ease than I would be able to if I didn't have that background. +VICTORIA: Yeah. I want to talk about how you're thinking about building your team for the future and filling in those gaps that you may have since you have such a well-rounded background. But first, I wanted to go back to, what stage do you feel like you are in your product life cycle? Are you still in the discovery phase or you have an MVP? What's the phase you're at right now? +ZAMINA: We are getting our MVP built right now. So, I've done about a year's worth of user interviews, research, chatting with folks all over the world, and really doing my best at validating the concept, and the idea, and the problem space. And one thing I will say is that the problem space is super clear. Famtech and femtech are places where there's a lot of capital being invested, and there's a lot of incredible innovation happening. But the solution is something that I think is always going to be evolving as needs of parents evolve. But right now, I have a pretty solid idea of what the product should be in its first iteration, and that is what we'll be launching with in 2024. And we'll be testing with some select partners. +WILL: I'm so excited for you. Can you explain what is Mevi? What's the problem that you're looking to solve with it? +ZAMINA: We are rooted in this belief that all of the negative symptoms, the stress, the mental health disorders that are experienced by moms stem from the isolation and lack of connection that they have to their communities. So, our mission is to really revolutionize maternal health by caring for the life that happens in between doctor's visits. Really, that is where life happens. And in doing so, we want to solve for those two specific root cause factors, emotional support and social isolation, that contribute the most to postpartum disorder. +So, from a practical standpoint, what Mevi is really going to do is connect moms to their personalized support networks so that they can delegate things like critical care tasks, activities of daily living, support with things at home, as well as emotional and mental health support to their support network so that they can basically show up for them in the way that they most need. +VICTORIA: That's really exciting. And to play that back a bit, it's interesting from your research and from your own experience that the thing that was missing was that element of community and connection to other people. Can you tell us more about that? +ZAMINA: In today's world, moms are expected to do it all, and we're kind of conditioned to that regard in every aspect of our lives. And there's a lot of support lacking for moms from a childcare perspective, from a systemic support perspective around things like maternity leave. And, ultimately, I think we're kind of given these signals that we should be able to do it alone, so we should just go ahead and do that. +And I think, for that reason, a lot of women really struggle because when they do ultimately step into parenthood, particularly in a post-pandemic context, they are incredibly overwhelmed, but they're getting all of these signals that they should be able to do it. And so, then they feel incredibly isolated and really struggle with those feelings. +And so, what Mevi and what I, as a person and as a founder I'm really trying to address and bring attention to is this idea that women absolutely cannot do it alone. And that over the last, you know, 10,000 years, we have raised children, and we have also raised mothers with the support of villages. And those villages look different for different people, but that's really the case across the entire planet. And so, what I really want to do is to bring attention back to the fact that it's important to build your personal village and to be able to request support from them in the ways you need. +WILL: Yeah. So, I was looking at your website when I was doing some research, and the very first, I guess, banner, you can call it, with a text message in it, there's a text message that's sent to the mom, and I'm guessing it's AI-driven. It's asking, "Hey. Out of these three options, what exactly do you need help in?" Can you walk me through what that looks like? Is it AI-driven that sends the text out and it has a list of friends and family that sends the text to, or how does that work? +ZAMINA: Yeah. So, first big disclaimer is that what you see on the website was actually our alpha product that we tested up here in Canada with a cohort of new moms. And that was really built to validate the problem space and to understand if a solution like this would be impactful. And that was actually not AI-driven, believe it or not. It was largely built through automation tools and a database of text messages that yours truly wrote and connected with Twilio. So, it was really kind of strung together on the back-end prototype that we used to understand if getting help on tasks like this would be beneficial. +We also were sending regular kind of positive reinforcement messages, just like, you know, resources, notes, things like that, to those moms just to give them kind of a daily positive reminder. But those text messages were also being sent, yes, to their support networks that they would sign up, so their partner, perhaps their mother, their mother-in-law, their sisters, their friends, so on and so forth. And we would determine which messages would go to whom. +And through that test, we realized that there was kind of a really positive response to what this was trying to achieve but that it was quite limited in its functionality because it was hard coded on the backend, and there wasn't really a lot of AI leveraged. So, we are now moving into building out an MVP, which will be a mobile app. +WILL: Wow. I can definitely see how this is beneficial because we have three kids, and my oldest and my youngest share the same birthday, so three kids in three years. And it seems like, oh, why are you asking that simple question? Sometimes, the simple question is exactly what you need. "Hey, how can I help?" And given choices, that is huge just to nudge what you need help. +Because, like, I love my sleep and [chuckles] with kids, you don't really get sleep sometimes. And I used to remember everything, but my youngest has been dealing with earaches probably over the last month, and I am forgetting a lot just because [chuckles] I haven't been getting sleep. So, I love what you're doing. And the purpose and the problem you're trying to solve, I think is much needed. +ZAMINA: Yeah, thank you so much. That point that you made about giving options is really important because, especially when you're encountering motherhood for the first time, it's quite daunting, and you don't really know what you don't know. And so, people will say, "Oh, you know, I'm here for you. Let me know how I can help." But that in and of itself is a huge barrier because you don't really know what to ask. You don't want to infringe on them. You don't want to make it inconvenient for them. And there's also boundaries that you want to set in terms of who you want to let into your home and let into your personal space and that kind of thing. +So, I think it's really important to provide a little bit of education for new mothers around what kinds of things they can typically benefit from getting support with, particularly in the home in those early days. As an example, a lot of moms feel hesitant about letting others come into their home to hold their child. They actually would prefer that others come into the home and support them with the dishes or making a meal so that they can stay close to their baby, particularly in those early days when babies are feeding around the clock, and skin-to-skin contact is really important. +And so, it's really important to provide that guidance, especially to new moms, so that they can share that with their support networks. But then also sharing that information with their support network so that they don't feel insulted or they don't feel bad when their requests for support are directed in a different way. So, through Mevi, we also hope to provide that education and that guidance to everybody that's in the network so that they understand how to be helpful. Because I think at the end of the day, a lot of our friends and our families genuinely want to be there for us, but they just don't know how. And so, we're really there to be those coaches for them. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +VICTORIA: I'm curious about...I think it's a hashtag on your LinkedIn profile for empathetic tech. Based on what you're describing, how does that relate to what you're building and how you build empathy into the technology and products? +ZAMINA: I am so committed to proving that we can build great businesses that do good in the world, that support women's health outcomes but are still businesses at the end of the day and make great revenue and great profits. When I came out into the space, and I kind of said, "Okay, I'm here, and I'm building this thing," particularly because I'm solving a problem for mothers, I often got met with this question of "Well, is it a nonprofit?" And no, absolutely not. It is not a nonprofit. It is intended to be a scalable business. +But I think a lot of people have a misunderstanding that if you're building something that is good for the world, that it won't generate revenue and profit. And so, from an empathetic tech standpoint, that's really something that I am kind of on a mission to prove through Mevi and through my own kind of personal endeavors. It's something that's really close to my heart. And I really, really want to put femtech on the map for that reason. And from a product standpoint, I mean, we have lots of ideas about how we can build that empathy directly into the product. +But I think the biggest thing is coaching moms to be vulnerable in ways that feel accessible to them. Again, back to this idea that women are expected to do it all and moms are expected to do it all, I think if we can start to nudge moms to sharing with their closed private networks of, you know, the handpicked people that they've put into their support networks about how they're feeling, what they need help with, you know, their mood day to day, those kinds of things, we can start to build more empathy, both in the context of that particular family, but in the broader context of motherhood as a whole. +WILL: Why do you think they automatically go to, "Oh, it's a nonprofit business," when you're talking about the mental health of women and anything in that category? +ZAMINA: I haven't figured it out yet [laughs], but in part, it feels like it's a social endeavor. "Oh, you're here to solve your own problem." And yes, I'm here to solve my own problem, but really, this is the problem of women across Canada, and the States, parts of Europe, and in Australia, and New Zealand. And so, it's not just a small niche problem. +But I think a lot of people who I've encountered, particularly in the earlier days of when I had just kind of come up on the scene, I was talking with a lot of people who didn't resonate because either they were male. They didn't have children. They weren't familiar with healthtech or femtech. And so, for them, they were like, "I don't understand this space. It must not be very big. It must not be very important," but it's quite the contrary. +VICTORIA: What other challenges have you faced so far on your journey? +ZAMINA: The other big one, honestly, is the fact that I'm a solo founder. For the last 15, 20 years, I have been working with people day in and day out, and, you know, whether it's in office or remotely, I had the option to kind of jam with them throughout the day on different problems. And in this particular journey, I don't really have that in the same way that I have been familiar with for, you know, my entire career. So, that has been a huge learning curve for me. +And I have really recognized that the journey of entrepreneurship is just as much of a mental one as it is everything else, and finding ways to cope with the kind of emotional ups and downs as you get lots of wins. But you also get doors closed in your face. All of those things require an immense amount of grit and resilience. And when you are going at it alone, it can be a little bit harder to navigate that. +But I'm slowly starting to really find my rhythm. And I've really managed to do that, I think, in large part due to an advisory board that I have built of people who are really looking to support me, who are bullish on the mission, who believe that this is a really big problem that deserves to be solved, and are helping to clear roadblocks and obstacles, both, you know, in the environment, but also for me when I get in my own head about things. And that has been really, really powerful for me is, kind of building that advisory board of people. +WILL: Since we're talking about hurdles, what are some of the hurdles you see in the future? Since we talked about your past ones and your current ones, do you see any on the future—on the horizon? +ZAMINA: Yeah, I mean, obviously, there's the kind of traditional ones of finding product-market fit and landing the product with that ideal customer. And so, I'm really excited about the work that's being done right now to get there. But, obviously, it's going to be a constant, you know, road of iteration and evolution on the product space. And that is one that I'm really excited about. +But I think the other bigger one is just the consumer landscape right now is a tough one to be in. Capital is drying up from an investment standpoint. And I've seen a lot of founders who are farther ahead in their journey, who have incredible results, that are growing rapidly year on year, and they are struggling to raise money. And they've got traction, really, really great traction. +So, at this stage, it's really important for me to find ways to self-fund and bootstrap through this period, which ultimately, I think is going to give me a competitive advantage. It's going to give every founder who's doing the same thing a competitive advantage in the long run because I believe that if you can get traction in this environment, you're truly building a really great business. But I do see that this area of capital being one that founders are really going to have to navigate for the next year or two. +VICTORIA: That resonates with some stories that we've heard as well. And I'm curious to hear you talk about the discovery process a little bit more. Was there anything that you discovered early on that caused you to pivot in strategy? +ZAMINA: So, I joined a pre-accelerator in San Francisco late 2023. And we built this vision of the MVP that I was really excited about. And as I was getting ready to think about actually building it out, what I realized was that in the feature set that we had built out, we were trying to do way too much. I had this vision of what Mevi could be ten years from now, and I was almost trying to build that in in an MVP. +And so, one of the big pivots that I made from a product perspective was really, really dialing it back and simplifying the feature set to really what I believed and what I had heard from folks would be the most impactful for them rather than, you know, squeezing in a bunch of other things that would be kind of beneficial or a value-add in the long run. I really wanted to ensure that when we did launch and when we do launch that, people really understand what we're here to do. And then, over time, as we get more and more consumer feedback, of course, we can continue to build the product in the direction that folks are desiring. But that was an early pivot. +And another one was more on the business model side, and this is one that I'm still kind of workshopping and working through with different folks. But this idea of going direct to consumer versus actually going to other companies and other businesses who serve this population of new mothers and actually selling the product to them, and then having them use it in their different contexts as they serve their clients. +And so, we've kind of pivoted our business model from B2C to B2B2C, which, even in doing so over the last month, has really, really gotten a lot of very positive signals that that is kind of the right approach to be making in the short term. And then, of course, you know, again, once we launch and we get that consumer feedback, we will continue to explore and expand other business models. But early on, I was just trying to do a lot. And in both of those pivots, I found some focus, and I'm really, really excited by that. +WILL: That's awesome. I love how you said pivoting. I think that's probably the core to having a successful business, knowing when to pivot, knowing when not to. What does success look like for you in, like, the next six months, you know, five years, especially when...I know you have a launch coming up. You're talking about raising capital. You kind of pivot on your business plans a little. What does it look like to be successful in that timeframe? +ZAMINA: In the next few months, success is really just going to be doing what we say we're going to do and putting an app out into the market and having it really be tested with some hand-picked partners who are also innovating in the maternal health space. I really believe in aligning with people who believe deeply in solving this problem. And I think that's just the low-hanging fruit as well from a business standpoint. And so, over the next six months, that's really what I'll be prioritizing. +And then, over the next, gosh, five, seven years, I really want it to be a full suite of features and tools that moms can leverage through a mobile platform. I really want it to be kind of, like, the Flo app [chuckles] for mothering, a household name that is doled out, you know, from OBGYNs who are saying, "Oh, hey, you should check this out now that you're pregnant," used by doula practices or midwife institutes, circulated among friends as the must-have app to have on your phone when you find out that you're pregnant. Obviously, that is a really, really lofty goal. But I do believe that there is a pretty big gap in this market, and I'm excited to try to fill it. +VICTORIA: How do you balance having ambitious goals against also needing to maintain your life and your life as a parent? +ZAMINA: I have a really incredible support system. My husband is an entrepreneur as well. And really, my career over the last ten years allowed him to pursue his entrepreneurial dreams, and he's absolutely killing it. And so, he kind of said to me, "Hey, it's your turn. I really want to give you the space to try this thing out and see where it can go. I really believe in it." I have him kind of in my corner every day, cheering me on and giving me a lot of space to learn and, grow and pivot from time to time. +But I also think that he's really great from a financial standpoint and helping me kind of navigate, you know, these goals and understanding kind of the revenue potential of the business and those kinds of things. And so, I have a really great balance of, you know, me being kind of pie in the sky, head in the clouds, really, really aspirational about what I'm building. And he does two things really great. He kind of brings me back to earth sometimes, but he also has a really, really great financial acumen that he lends to the business. And so, he's really kind of my champion and has allowed me to pursue this. +WILL: I'm so glad that you have a supportive partner. That could be a make-it or break-it a lot of times. It's just someone in your corner that you can trust and know that they have your back. I think that's just huge. +ZAMINA: Yeah, absolutely. I'm super lucky. +WILL: What motivates you? What makes you...because being an entrepreneur is not easy. It's a lot of long hours, a lot of sleepless nights at times. So, what motivates you to want to be an entrepreneur? +ZAMINA: I really want to leave the world in a better place than I found it. I spent a lot of time in my career, particularly on the marketing side, selling people things. And some of those things were great, and some of those things were absolutely things that they did not need. And I think once I became a parent, my perspective on life really shifted. And I realized that I wanted to spend my time doing something that I could be proud of but that would also, you know, do good in the world. +I'm fueled by this idea that I'm building in a space that has kind of been underserved for decades and, that I'm solving a real-world tangible problem, and that I have a lot of people who have provided some incredible guidance, feedback, support along the way, who are validating the journey that we're on. And so, all of those things kind of, you know, fuel me in that way. +And then, I think from a practical standpoint, just being able to build and design my life in the way that, you know, excites me, being able to spend time with my family, to have that flexibility. You know, in these early days, I don't have a lot of that because I'm spending a lot of time in the business, but I'm excited by the opportunity that it will present in the long run. +VICTORIA: That's really exciting. And it reminds me just about what are your core values, and what values drive your everyday decisions? +ZAMINA: I think it's really the one around the desire to leave the world in a better place. Again, when my daughter was born, I just saw things in a really different way. You know, I think I had been largely ignorant to a lot of that and not to the fault of my own. I think it's just one of those things that you don't really understand until you become a parent. +You see how difficult it is to obtain childcare. You see how predatory it can be when it comes to consumption around toys, and products, and nutrition. And there's just a lot of things that become apparent to you that you don't really realize. And so, anything that I do and anyone that I align myself with is really centered around this idea and this desire to leave the world in a better place than I found it. +WILL: Yeah, I totally agree with that. And I wish there were so many more resources out there because it's a hard thing to do. So, I really am glad that you're doing this. And it kind of leads into my next question. Do you have any advice for building an inclusive experience for parents? +ZAMINA: If you spend any time on social media, you will see that people are very quick to dole out advice and to have comments on how other people choose to do things in their families, particularly in the context of, you know, female and motherhood-based content creators. And, honestly, the biggest thing that's missing when those kinds of things happen is empathy. +A lot of the times, we feel maybe a little bit insecure, or we feel worried that decisions that we're making are not good, or we feel worried about being judged. And so, maybe we shift that onto other people. We project that onto other people. And what I've just seen come up time and time again is if everyone could just see the fact that everyone's struggle is very unique to their individual context. You never know what other families might be dealing with. You don't understand, you know, what difficulties they might be having at work, what difficulties they might be having with childcare, what their financial situation is. And all of that informs their decision-making, and everyone's just doing the best that they can. +You know, when it comes to how we engage with other parents on social media, how we engage with other parents in real life, at work, in products, it's really just about trying to bridge the gap through empathy. And that's obviously way, way easier said than done. But I think it's really important because sometimes we just need that window to get the glance into other people's lives to really understand, oh, I should maybe, you know, keep that particular opinion to myself or maybe not be so judgmental in this particular context? And so, yeah, I think that's the biggest piece of advice that I have just for anyone that is navigating life in any context with a parent. +VICTORIA: That's really helpful. Thank you. And it's, like, leading with empathy again, right? +ZAMINA: Absolutely. Yeah [laughs]. The commonality here is absolutely leading with empathy. +VICTORIA: Well, wonderful. I've really enjoyed our conversation so far. Is there anything else that you would like to promote? +ZAMINA: Two quick things. Like I said, we are getting ready to launch in the middle of the year, so I'm really excited for that. And if anyone listening is excited by the mission, you can sign up for our waitlist at getmevi.com. Again, disclaimer, the website is a little bit out of date. It needs some work. But the wait list is very much active and works just fine. So, it'd be great to capture your intention there. And then, you can also follow us on Instagram @getmevi. +VICTORIA: Wonderful. And also, do you have any questions for me or Will? +ZAMINA: Gosh, yeah, I mean, I would love to understand kind of what patterns are you seeing in terms of what founders are building right now? Have you noticed kind of any underlying trends that you think would be valuable to share? +VICTORIA: Well, I can talk about my experience connecting to the San Diego community, startup and founders community. So, it is interesting. I think what you mentioned earlier about trying to bootstrap as much as you can and do it yourself as much as you can. I've seen founders show an interest in learning more about low-code tools and using those to prove out their MVP and prove out their concept and go from there. +There's always shifts in the investment, right? So, people, I think, are even more going to fall into their similar patterns for what they choose to invest in and take less risks. It's trending upward again, and we're starting to see some signs of investment picking up again. +You know, being in San Diego is an interesting place because we're right next to Tijuana, and you can be in Mexico in 30 minutes from my house or 45, depending on traffic. And there's just a lot of opportunity to do all different types of startups around here: biotech startups and startups that help you predict if breast cancer is going to come back. And there's also just all kinds of interesting things going on with actual physical products as well and treating products as more of a startup-type model. So, that's what I see going around here. But, Will, what do you think? +WILL: Yeah, I was actually thinking about probably the last two or three podcast episodes that I recorded, it was around parenting and motherhood. So, I think that's a good thing because, like you said, it's an underserved area, but it's amazing to see what that community is doing. And I think it's going to be so good, especially in the next couple of years. After talking to those founders and even yourself, the pandemic, I think, encouraged a lot of that growth in that area. So, I think we're going to see a lot of growth in that area, and I'm excited about it. +ZAMINA: Yeah, absolutely. I totally agree with both of those things. And I think the no-code one is one in particular that will fuel a lot of innovation, not only in this industry but across tech as a whole. I'm seeing some really, really great advancements happening and making it a lot easier for solo non-technical founders or just non-technical people in general to prototype things very, very quickly. +VICTORIA: Absolutely. And then, the tools to build products that are really compliant and mature and ready for healthtech and FinTech. There's also so much more out there available to give people the resources they need to do it right. So, it's really interesting. And yeah, I think, like you said, with COVID, too, the acceptance of virtual healthcare and the need for virtual communities, and that's not gone away [laughs]. There are still some people who won't want to re-engage in-person events and community building, so... +ZAMINA: Yeah, this is kind of the new normal for us, and we've got to figure out how do we maintain our well-being and how do we maintain different types of social connectivity in this world that is becoming increasingly interpersonally independent? So, I think even AI and, you know, the Apple Vision Pro has really sparked conversations around what's going to happen to in-person interaction if everyone is wearing these massive devices on their faces? And I think, at this point, we can only imagine. But I do think it's a very practical and real thing that we should be solving for today and not just be waiting until we're all wearing these massive devices to recognize that we need to solve for that connectivity between all of us. +VICTORIA: Have you tried out a Vision Pro yet? +ZAMINA: I have not. Have you? +VICTORIA: No, I haven't tried it. And I haven't ever talked to anyone who is using it. So, I'm curious. One of these days. +ZAMINA: I've met a few people, or I know a few people who have tried it, mixed reviews. Obviously, the cost is a big prohibitive factor at the moment. But I think that there's the novelty around the device, which makes it really exciting right now. But I don't really see, like, in my life any practical use cases. You know, even if it was cheaper, if it was the product that it is today and the price was even half of what it is, I still don't really understand how I would benefit from it, but I'm definitely curious to see where it goes. +VICTORIA: Yeah. Like, I want the ability to, like, have a big screen without having a physical screen, but I don't want to wear goggles. +ZAMINA: Totally. +VICTORIA: I also get nauseous. Like, I actually tried to do a virtual hangout during COVID, and I got some 3D, whatever, virtual glasses. And I got so [chuckles] nauseous so fast. I was like, this isn't...why does anyone enjoy this? And apparently, that's something that happens to women more than men because of hormones. +ZAMINA: Oh, that is so interesting. I did not know that. +VICTORIA: But I really enjoyed our conversation today. Thank you again so much for joining us. +WILL: I'm so excited for your launch and your product. I think it's going to make a huge impact in that area. And I just can't wait to see where it goes. And thank you for building it and stepping out and taking that leap to do it. +ZAMINA: Oh yeah. Thank you both so much. It was a really great conversation, and yeah, I'm excited to get launched and excited to stay in touch and see what we do from here. +VICTORIA: Yeah, we'll have to bring you back in a year and see how things have progressed. +ZAMINA: Yeah. Let's do it. Let's pencil that in [laughs]. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +VICTORIA: And you can find me @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + motherhood wellness app, Mevi, maternal health technology, postpartum support, parenting during pandemic, solo founder journey, female entrepreneurship, community-driven support for mothers, mental health for new moms, femtech innovation, navigating motherhood, maternal wellness solutions, empowering mothers, startup challenges and solutions, building empathetic tech, motherhood in the digital age + + Hosts Will Larry and Victoria Guido are joined by Zamina Karim, the CEO and Founder of Mevi, a community-driven motherhood wellness app designed to address the unique challenges of motherhood, especially in the context of the pandemic. Zamina shares her journey from experiencing postpartum anxiety and depression to founding Mevi. She discusses the lack of understanding and support for new mothers, especially during the pandemic when traditional support structures were unavailable. The conversation also touches on parenting challenges in the current era, underscoring the need for community and support.

+ +

The app aims to revolutionize maternal health by fostering connections among mothers and providing support for the challenges of motherhood beyond medical visits. Zamina's approach to building Mevi is rooted in empathy, aiming to address new mothers' emotional and practical needs and fill a significant gap in current maternal health support.

+ +

Zamina also talks about the broader implications of Mevi's mission, the evolving startup funding landscape, and the importance of pivoting and adapting in the entrepreneurial journey. She emphasizes the role of empathy in building inclusive experiences for parents and the potential of technology to improve maternal health outcomes.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 WILL: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Zamina Karim, CEO and Founder of Mevi, the first-ever community-driven motherhood wellness app. Zamina, thank you for joining us.

+ +

ZAMINA: Thank you so much for having me.

+ +

VICTORIA: Well, outside of founding Mevi, what keeps you going? What's exciting for you right now in your world?

+ +

ZAMINA: Well, I have a toddler. She is two turning three, and she keeps me incredibly active and stimulated throughout the day. And I have my hands full with her throughout the day. And outside of that, I've just jumped into the business full-time. So, I'm navigating solo foundership and recognizing how different of an experience that is when you have been working in a team environment for the last 15 years or so. So, that's kind of what's been keeping me busy the last few months.

+ +

WILL: You mentioned your daughter. When you became a parent, I know there's something surprising; there's plenty. But what was the most surprising thing that you went through when you became a parent?

+ +

ZAMINA: Oh my gosh, there were so many things. You're totally right, Will. But I think, for me, it was a really big emphasis that I noticed on the products that I would need to have. And if I had all of those products, I would be ready and I would be well on my way, and parenting would be a breeze. And it kicked me on my butt when I realized that having the perfect car seat and the perfect stroller was not setting me up for success.

+ +

And there was a lot that I didn't know and didn't realize, even though I had done so much research and had a lot of other parents in my network. I think it's one of those things that you don't truly understand until you have experienced it yourself and you are living through it.

+ +

VICTORIA: So, then, what led you to start Mevi?

+ +

ZAMINA: Mevi was started because my baby was born during the pandemic, and I experienced a ton of challenges during that time. I struggled with symptoms of anxiety and depression for over a year. But I didn't really need any clinical diagnosis, and so no one knew how to help me in my family. And I did not know how to help myself either. And I really felt the Western sort of pressure of having to do it all. And I was quite frankly embarrassed by the struggles that I was experiencing.

+ +

And, you know, you never really go back to your old self. But once she turned one, I started to feel a little bit more balanced. And I came out of my shell, and I started speaking with other women from all over the world really. And I learned very quickly that my experience was the norm and not the exception. And that really was the inspiration to go ahead and try to solve that problem.

+ +

WILL: Yeah. I remember we had my middle child at the very beginning of July 2020. And the first thing that was rough is that was whenever they were like, "If you have COVID, we may have to separate you from your child when you have birth," and it was terrifying. And they ended up not doing that. We didn't have COVID or anything. But I remember, because we have three now, and I remember thinking, like, if I was a parent of a single child, it would have to be rough because, like, the child is not playing with anyone, and you're also by yourself. So, I totally relate with what you're saying.

+ +

ZAMINA: Yeah, absolutely. And then, beyond that, all of those kinds of traditional childcare centers or places where people would congregate were shut down. And up here in Canada, a lot of those places haven't really opened back up, and so there was no real bounce back to a pre-pandemic norm. A lot of families are now just navigating with this as the new normal. So, I think it's really important to recognize that parenting in 2021 and beyond is really different from what it was pre-pandemic.

+ +

VICTORIA: So, you had this acute need yourself to build a community to survive [laughs]. What in your background led you to think, oh, I could start a company around this; I could build the solution for this problem?

+ +

ZAMINA: Yeah, it's actually a really interesting mix of personal and more technical and career-driven. So, on a personal level, I was born in India, and my parents are from East Africa. So, that cultural element really bleeds into my perspectives and my values on life, as well as what's missing in healthcare today, so this idea of taking a prevention-focused approach or addressing root causes rather than addressing symptoms, which is a lot more common in today's kind of healthcare context.

+ +

And then, on a more career-based side, my background is in consumer tech, growth marketing. And I studied psychology and human development when I was in school. So, all of these areas really came together as the perfect combination for starting Mevi because I had this hard tech background. I know how to code. I self-taught Ruby on Rails about ten years ago. And then I'd worked in this consumer space, kind of selling things for companies like Masterclass, and Uber, and Lululemon, and Aritzia. And I had this experience on the paid acquisition side as well.

+ +

So, all of those things really came together for me to feel equipped to step into this journey of building Mevi. But I think no matter what technical or kind of soft skills you have, it is still a huge climb when building a company from scratch and, in particular, when you're doing it as a solo founder.

+ +

WILL: Wow, that's so amazing. I love your background, and I love especially talking to founders who have a technical background and kind of seeing how their journey was. Did your technical background help you in anything, or did you code your app?

+ +

ZAMINA: I did not code the app. Because I was on the tech side over a decade ago, so I was building apps about ten years ago; it's one of those muscles where it can very quickly atrophy. And things now are developing at such a rapid pace compared to when I was in the space that I'm no longer someone who would be best suited to actually code the app. I would be spending a lot of time relearning versus just delegating that to somebody else.

+ +

But I do possess the ability to talk to engineers and to be able to navigate some of the architecture and the fundamentals with them and that, for me, has been a really big game changer because I'm not completely lost when chatting with technical folks. And I can kind of navigate my way around with a little bit more ease than I would be able to if I didn't have that background.

+ +

VICTORIA: Yeah. I want to talk about how you're thinking about building your team for the future and filling in those gaps that you may have since you have such a well-rounded background. But first, I wanted to go back to, what stage do you feel like you are in your product life cycle? Are you still in the discovery phase or you have an MVP? What's the phase you're at right now?

+ +

ZAMINA: We are getting our MVP built right now. So, I've done about a year's worth of user interviews, research, chatting with folks all over the world, and really doing my best at validating the concept, and the idea, and the problem space. And one thing I will say is that the problem space is super clear. Famtech and femtech are places where there's a lot of capital being invested, and there's a lot of incredible innovation happening. But the solution is something that I think is always going to be evolving as needs of parents evolve. But right now, I have a pretty solid idea of what the product should be in its first iteration, and that is what we'll be launching with in 2024. And we'll be testing with some select partners.

+ +

WILL: I'm so excited for you. Can you explain what is Mevi? What's the problem that you're looking to solve with it?

+ +

ZAMINA: We are rooted in this belief that all of the negative symptoms, the stress, the mental health disorders that are experienced by moms stem from the isolation and lack of connection that they have to their communities. So, our mission is to really revolutionize maternal health by caring for the life that happens in between doctor's visits. Really, that is where life happens. And in doing so, we want to solve for those two specific root cause factors, emotional support and social isolation, that contribute the most to postpartum disorder.

+ +

So, from a practical standpoint, what Mevi is really going to do is connect moms to their personalized support networks so that they can delegate things like critical care tasks, activities of daily living, support with things at home, as well as emotional and mental health support to their support network so that they can basically show up for them in the way that they most need.

+ +

VICTORIA: That's really exciting. And to play that back a bit, it's interesting from your research and from your own experience that the thing that was missing was that element of community and connection to other people. Can you tell us more about that?

+ +

ZAMINA: In today's world, moms are expected to do it all, and we're kind of conditioned to that regard in every aspect of our lives. And there's a lot of support lacking for moms from a childcare perspective, from a systemic support perspective around things like maternity leave. And, ultimately, I think we're kind of given these signals that we should be able to do it alone, so we should just go ahead and do that.

+ +

And I think, for that reason, a lot of women really struggle because when they do ultimately step into parenthood, particularly in a post-pandemic context, they are incredibly overwhelmed, but they're getting all of these signals that they should be able to do it. And so, then they feel incredibly isolated and really struggle with those feelings.

+ +

And so, what Mevi and what I, as a person and as a founder I'm really trying to address and bring attention to is this idea that women absolutely cannot do it alone. And that over the last, you know, 10,000 years, we have raised children, and we have also raised mothers with the support of villages. And those villages look different for different people, but that's really the case across the entire planet. And so, what I really want to do is to bring attention back to the fact that it's important to build your personal village and to be able to request support from them in the ways you need.

+ +

WILL: Yeah. So, I was looking at your website when I was doing some research, and the very first, I guess, banner, you can call it, with a text message in it, there's a text message that's sent to the mom, and I'm guessing it's AI-driven. It's asking, "Hey. Out of these three options, what exactly do you need help in?" Can you walk me through what that looks like? Is it AI-driven that sends the text out and it has a list of friends and family that sends the text to, or how does that work?

+ +

ZAMINA: Yeah. So, first big disclaimer is that what you see on the website was actually our alpha product that we tested up here in Canada with a cohort of new moms. And that was really built to validate the problem space and to understand if a solution like this would be impactful. And that was actually not AI-driven, believe it or not. It was largely built through automation tools and a database of text messages that yours truly wrote and connected with Twilio. So, it was really kind of strung together on the back-end prototype that we used to understand if getting help on tasks like this would be beneficial.

+ +

We also were sending regular kind of positive reinforcement messages, just like, you know, resources, notes, things like that, to those moms just to give them kind of a daily positive reminder. But those text messages were also being sent, yes, to their support networks that they would sign up, so their partner, perhaps their mother, their mother-in-law, their sisters, their friends, so on and so forth. And we would determine which messages would go to whom.

+ +

And through that test, we realized that there was kind of a really positive response to what this was trying to achieve but that it was quite limited in its functionality because it was hard coded on the backend, and there wasn't really a lot of AI leveraged. So, we are now moving into building out an MVP, which will be a mobile app.

+ +

WILL: Wow. I can definitely see how this is beneficial because we have three kids, and my oldest and my youngest share the same birthday, so three kids in three years. And it seems like, oh, why are you asking that simple question? Sometimes, the simple question is exactly what you need. "Hey, how can I help?" And given choices, that is huge just to nudge what you need help.

+ +

Because, like, I love my sleep and [chuckles] with kids, you don't really get sleep sometimes. And I used to remember everything, but my youngest has been dealing with earaches probably over the last month, and I am forgetting a lot just because [chuckles] I haven't been getting sleep. So, I love what you're doing. And the purpose and the problem you're trying to solve, I think is much needed.

+ +

ZAMINA: Yeah, thank you so much. That point that you made about giving options is really important because, especially when you're encountering motherhood for the first time, it's quite daunting, and you don't really know what you don't know. And so, people will say, "Oh, you know, I'm here for you. Let me know how I can help." But that in and of itself is a huge barrier because you don't really know what to ask. You don't want to infringe on them. You don't want to make it inconvenient for them. And there's also boundaries that you want to set in terms of who you want to let into your home and let into your personal space and that kind of thing.

+ +

So, I think it's really important to provide a little bit of education for new mothers around what kinds of things they can typically benefit from getting support with, particularly in the home in those early days. As an example, a lot of moms feel hesitant about letting others come into their home to hold their child. They actually would prefer that others come into the home and support them with the dishes or making a meal so that they can stay close to their baby, particularly in those early days when babies are feeding around the clock, and skin-to-skin contact is really important.

+ +

And so, it's really important to provide that guidance, especially to new moms, so that they can share that with their support networks. But then also sharing that information with their support network so that they don't feel insulted or they don't feel bad when their requests for support are directed in a different way. So, through Mevi, we also hope to provide that education and that guidance to everybody that's in the network so that they understand how to be helpful. Because I think at the end of the day, a lot of our friends and our families genuinely want to be there for us, but they just don't know how. And so, we're really there to be those coaches for them.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: I'm curious about...I think it's a hashtag on your LinkedIn profile for empathetic tech. Based on what you're describing, how does that relate to what you're building and how you build empathy into the technology and products?

+ +

ZAMINA: I am so committed to proving that we can build great businesses that do good in the world, that support women's health outcomes but are still businesses at the end of the day and make great revenue and great profits. When I came out into the space, and I kind of said, "Okay, I'm here, and I'm building this thing," particularly because I'm solving a problem for mothers, I often got met with this question of "Well, is it a nonprofit?" And no, absolutely not. It is not a nonprofit. It is intended to be a scalable business.

+ +

But I think a lot of people have a misunderstanding that if you're building something that is good for the world, that it won't generate revenue and profit. And so, from an empathetic tech standpoint, that's really something that I am kind of on a mission to prove through Mevi and through my own kind of personal endeavors. It's something that's really close to my heart. And I really, really want to put femtech on the map for that reason. And from a product standpoint, I mean, we have lots of ideas about how we can build that empathy directly into the product.

+ +

But I think the biggest thing is coaching moms to be vulnerable in ways that feel accessible to them. Again, back to this idea that women are expected to do it all and moms are expected to do it all, I think if we can start to nudge moms to sharing with their closed private networks of, you know, the handpicked people that they've put into their support networks about how they're feeling, what they need help with, you know, their mood day to day, those kinds of things, we can start to build more empathy, both in the context of that particular family, but in the broader context of motherhood as a whole.

+ +

WILL: Why do you think they automatically go to, "Oh, it's a nonprofit business," when you're talking about the mental health of women and anything in that category?

+ +

ZAMINA: I haven't figured it out yet [laughs], but in part, it feels like it's a social endeavor. "Oh, you're here to solve your own problem." And yes, I'm here to solve my own problem, but really, this is the problem of women across Canada, and the States, parts of Europe, and in Australia, and New Zealand. And so, it's not just a small niche problem.

+ +

But I think a lot of people who I've encountered, particularly in the earlier days of when I had just kind of come up on the scene, I was talking with a lot of people who didn't resonate because either they were male. They didn't have children. They weren't familiar with healthtech or femtech. And so, for them, they were like, "I don't understand this space. It must not be very big. It must not be very important," but it's quite the contrary.

+ +

VICTORIA: What other challenges have you faced so far on your journey?

+ +

ZAMINA: The other big one, honestly, is the fact that I'm a solo founder. For the last 15, 20 years, I have been working with people day in and day out, and, you know, whether it's in office or remotely, I had the option to kind of jam with them throughout the day on different problems. And in this particular journey, I don't really have that in the same way that I have been familiar with for, you know, my entire career. So, that has been a huge learning curve for me.

+ +

And I have really recognized that the journey of entrepreneurship is just as much of a mental one as it is everything else, and finding ways to cope with the kind of emotional ups and downs as you get lots of wins. But you also get doors closed in your face. All of those things require an immense amount of grit and resilience. And when you are going at it alone, it can be a little bit harder to navigate that.

+ +

But I'm slowly starting to really find my rhythm. And I've really managed to do that, I think, in large part due to an advisory board that I have built of people who are really looking to support me, who are bullish on the mission, who believe that this is a really big problem that deserves to be solved, and are helping to clear roadblocks and obstacles, both, you know, in the environment, but also for me when I get in my own head about things. And that has been really, really powerful for me is, kind of building that advisory board of people.

+ +

WILL: Since we're talking about hurdles, what are some of the hurdles you see in the future? Since we talked about your past ones and your current ones, do you see any on the future—on the horizon?

+ +

ZAMINA: Yeah, I mean, obviously, there's the kind of traditional ones of finding product-market fit and landing the product with that ideal customer. And so, I'm really excited about the work that's being done right now to get there. But, obviously, it's going to be a constant, you know, road of iteration and evolution on the product space. And that is one that I'm really excited about.

+ +

But I think the other bigger one is just the consumer landscape right now is a tough one to be in. Capital is drying up from an investment standpoint. And I've seen a lot of founders who are farther ahead in their journey, who have incredible results, that are growing rapidly year on year, and they are struggling to raise money. And they've got traction, really, really great traction.

+ +

So, at this stage, it's really important for me to find ways to self-fund and bootstrap through this period, which ultimately, I think is going to give me a competitive advantage. It's going to give every founder who's doing the same thing a competitive advantage in the long run because I believe that if you can get traction in this environment, you're truly building a really great business. But I do see that this area of capital being one that founders are really going to have to navigate for the next year or two.

+ +

VICTORIA: That resonates with some stories that we've heard as well. And I'm curious to hear you talk about the discovery process a little bit more. Was there anything that you discovered early on that caused you to pivot in strategy?

+ +

ZAMINA: So, I joined a pre-accelerator in San Francisco late 2023. And we built this vision of the MVP that I was really excited about. And as I was getting ready to think about actually building it out, what I realized was that in the feature set that we had built out, we were trying to do way too much. I had this vision of what Mevi could be ten years from now, and I was almost trying to build that in in an MVP.

+ +

And so, one of the big pivots that I made from a product perspective was really, really dialing it back and simplifying the feature set to really what I believed and what I had heard from folks would be the most impactful for them rather than, you know, squeezing in a bunch of other things that would be kind of beneficial or a value-add in the long run. I really wanted to ensure that when we did launch and when we do launch that, people really understand what we're here to do. And then, over time, as we get more and more consumer feedback, of course, we can continue to build the product in the direction that folks are desiring. But that was an early pivot.

+ +

And another one was more on the business model side, and this is one that I'm still kind of workshopping and working through with different folks. But this idea of going direct to consumer versus actually going to other companies and other businesses who serve this population of new mothers and actually selling the product to them, and then having them use it in their different contexts as they serve their clients.

+ +

And so, we've kind of pivoted our business model from B2C to B2B2C, which, even in doing so over the last month, has really, really gotten a lot of very positive signals that that is kind of the right approach to be making in the short term. And then, of course, you know, again, once we launch and we get that consumer feedback, we will continue to explore and expand other business models. But early on, I was just trying to do a lot. And in both of those pivots, I found some focus, and I'm really, really excited by that.

+ +

WILL: That's awesome. I love how you said pivoting. I think that's probably the core to having a successful business, knowing when to pivot, knowing when not to. What does success look like for you in, like, the next six months, you know, five years, especially when...I know you have a launch coming up. You're talking about raising capital. You kind of pivot on your business plans a little. What does it look like to be successful in that timeframe?

+ +

ZAMINA: In the next few months, success is really just going to be doing what we say we're going to do and putting an app out into the market and having it really be tested with some hand-picked partners who are also innovating in the maternal health space. I really believe in aligning with people who believe deeply in solving this problem. And I think that's just the low-hanging fruit as well from a business standpoint. And so, over the next six months, that's really what I'll be prioritizing.

+ +

And then, over the next, gosh, five, seven years, I really want it to be a full suite of features and tools that moms can leverage through a mobile platform. I really want it to be kind of, like, the Flo app [chuckles] for mothering, a household name that is doled out, you know, from OBGYNs who are saying, "Oh, hey, you should check this out now that you're pregnant," used by doula practices or midwife institutes, circulated among friends as the must-have app to have on your phone when you find out that you're pregnant. Obviously, that is a really, really lofty goal. But I do believe that there is a pretty big gap in this market, and I'm excited to try to fill it.

+ +

VICTORIA: How do you balance having ambitious goals against also needing to maintain your life and your life as a parent?

+ +

ZAMINA: I have a really incredible support system. My husband is an entrepreneur as well. And really, my career over the last ten years allowed him to pursue his entrepreneurial dreams, and he's absolutely killing it. And so, he kind of said to me, "Hey, it's your turn. I really want to give you the space to try this thing out and see where it can go. I really believe in it." I have him kind of in my corner every day, cheering me on and giving me a lot of space to learn and, grow and pivot from time to time.

+ +

But I also think that he's really great from a financial standpoint and helping me kind of navigate, you know, these goals and understanding kind of the revenue potential of the business and those kinds of things. And so, I have a really great balance of, you know, me being kind of pie in the sky, head in the clouds, really, really aspirational about what I'm building. And he does two things really great. He kind of brings me back to earth sometimes, but he also has a really, really great financial acumen that he lends to the business. And so, he's really kind of my champion and has allowed me to pursue this.

+ +

WILL: I'm so glad that you have a supportive partner. That could be a make-it or break-it a lot of times. It's just someone in your corner that you can trust and know that they have your back. I think that's just huge.

+ +

ZAMINA: Yeah, absolutely. I'm super lucky.

+ +

WILL: What motivates you? What makes you...because being an entrepreneur is not easy. It's a lot of long hours, a lot of sleepless nights at times. So, what motivates you to want to be an entrepreneur?

+ +

ZAMINA: I really want to leave the world in a better place than I found it. I spent a lot of time in my career, particularly on the marketing side, selling people things. And some of those things were great, and some of those things were absolutely things that they did not need. And I think once I became a parent, my perspective on life really shifted. And I realized that I wanted to spend my time doing something that I could be proud of but that would also, you know, do good in the world.

+ +

I'm fueled by this idea that I'm building in a space that has kind of been underserved for decades and, that I'm solving a real-world tangible problem, and that I have a lot of people who have provided some incredible guidance, feedback, support along the way, who are validating the journey that we're on. And so, all of those things kind of, you know, fuel me in that way.

+ +

And then, I think from a practical standpoint, just being able to build and design my life in the way that, you know, excites me, being able to spend time with my family, to have that flexibility. You know, in these early days, I don't have a lot of that because I'm spending a lot of time in the business, but I'm excited by the opportunity that it will present in the long run.

+ +

VICTORIA: That's really exciting. And it reminds me just about what are your core values, and what values drive your everyday decisions?

+ +

ZAMINA: I think it's really the one around the desire to leave the world in a better place. Again, when my daughter was born, I just saw things in a really different way. You know, I think I had been largely ignorant to a lot of that and not to the fault of my own. I think it's just one of those things that you don't really understand until you become a parent.

+ +

You see how difficult it is to obtain childcare. You see how predatory it can be when it comes to consumption around toys, and products, and nutrition. And there's just a lot of things that become apparent to you that you don't really realize. And so, anything that I do and anyone that I align myself with is really centered around this idea and this desire to leave the world in a better place than I found it.

+ +

WILL: Yeah, I totally agree with that. And I wish there were so many more resources out there because it's a hard thing to do. So, I really am glad that you're doing this. And it kind of leads into my next question. Do you have any advice for building an inclusive experience for parents?

+ +

ZAMINA: If you spend any time on social media, you will see that people are very quick to dole out advice and to have comments on how other people choose to do things in their families, particularly in the context of, you know, female and motherhood-based content creators. And, honestly, the biggest thing that's missing when those kinds of things happen is empathy.

+ +

A lot of the times, we feel maybe a little bit insecure, or we feel worried that decisions that we're making are not good, or we feel worried about being judged. And so, maybe we shift that onto other people. We project that onto other people. And what I've just seen come up time and time again is if everyone could just see the fact that everyone's struggle is very unique to their individual context. You never know what other families might be dealing with. You don't understand, you know, what difficulties they might be having at work, what difficulties they might be having with childcare, what their financial situation is. And all of that informs their decision-making, and everyone's just doing the best that they can.

+ +

You know, when it comes to how we engage with other parents on social media, how we engage with other parents in real life, at work, in products, it's really just about trying to bridge the gap through empathy. And that's obviously way, way easier said than done. But I think it's really important because sometimes we just need that window to get the glance into other people's lives to really understand, oh, I should maybe, you know, keep that particular opinion to myself or maybe not be so judgmental in this particular context? And so, yeah, I think that's the biggest piece of advice that I have just for anyone that is navigating life in any context with a parent.

+ +

VICTORIA: That's really helpful. Thank you. And it's, like, leading with empathy again, right?

+ +

ZAMINA: Absolutely. Yeah [laughs]. The commonality here is absolutely leading with empathy.

+ +

VICTORIA: Well, wonderful. I've really enjoyed our conversation so far. Is there anything else that you would like to promote?

+ +

ZAMINA: Two quick things. Like I said, we are getting ready to launch in the middle of the year, so I'm really excited for that. And if anyone listening is excited by the mission, you can sign up for our waitlist at getmevi.com. Again, disclaimer, the website is a little bit out of date. It needs some work. But the wait list is very much active and works just fine. So, it'd be great to capture your intention there. And then, you can also follow us on Instagram @getmevi.

+ +

VICTORIA: Wonderful. And also, do you have any questions for me or Will?

+ +

ZAMINA: Gosh, yeah, I mean, I would love to understand kind of what patterns are you seeing in terms of what founders are building right now? Have you noticed kind of any underlying trends that you think would be valuable to share?

+ +

VICTORIA: Well, I can talk about my experience connecting to the San Diego community, startup and founders community. So, it is interesting. I think what you mentioned earlier about trying to bootstrap as much as you can and do it yourself as much as you can. I've seen founders show an interest in learning more about low-code tools and using those to prove out their MVP and prove out their concept and go from there.

+ +

There's always shifts in the investment, right? So, people, I think, are even more going to fall into their similar patterns for what they choose to invest in and take less risks. It's trending upward again, and we're starting to see some signs of investment picking up again.

+ +

You know, being in San Diego is an interesting place because we're right next to Tijuana, and you can be in Mexico in 30 minutes from my house or 45, depending on traffic. And there's just a lot of opportunity to do all different types of startups around here: biotech startups and startups that help you predict if breast cancer is going to come back. And there's also just all kinds of interesting things going on with actual physical products as well and treating products as more of a startup-type model. So, that's what I see going around here. But, Will, what do you think?

+ +

WILL: Yeah, I was actually thinking about probably the last two or three podcast episodes that I recorded, it was around parenting and motherhood. So, I think that's a good thing because, like you said, it's an underserved area, but it's amazing to see what that community is doing. And I think it's going to be so good, especially in the next couple of years. After talking to those founders and even yourself, the pandemic, I think, encouraged a lot of that growth in that area. So, I think we're going to see a lot of growth in that area, and I'm excited about it.

+ +

ZAMINA: Yeah, absolutely. I totally agree with both of those things. And I think the no-code one is one in particular that will fuel a lot of innovation, not only in this industry but across tech as a whole. I'm seeing some really, really great advancements happening and making it a lot easier for solo non-technical founders or just non-technical people in general to prototype things very, very quickly.

+ +

VICTORIA: Absolutely. And then, the tools to build products that are really compliant and mature and ready for healthtech and FinTech. There's also so much more out there available to give people the resources they need to do it right. So, it's really interesting. And yeah, I think, like you said, with COVID, too, the acceptance of virtual healthcare and the need for virtual communities, and that's not gone away [laughs]. There are still some people who won't want to re-engage in-person events and community building, so...

+ +

ZAMINA: Yeah, this is kind of the new normal for us, and we've got to figure out how do we maintain our well-being and how do we maintain different types of social connectivity in this world that is becoming increasingly interpersonally independent? So, I think even AI and, you know, the Apple Vision Pro has really sparked conversations around what's going to happen to in-person interaction if everyone is wearing these massive devices on their faces? And I think, at this point, we can only imagine. But I do think it's a very practical and real thing that we should be solving for today and not just be waiting until we're all wearing these massive devices to recognize that we need to solve for that connectivity between all of us.

+ +

VICTORIA: Have you tried out a Vision Pro yet?

+ +

ZAMINA: I have not. Have you?

+ +

VICTORIA: No, I haven't tried it. And I haven't ever talked to anyone who is using it. So, I'm curious. One of these days.

+ +

ZAMINA: I've met a few people, or I know a few people who have tried it, mixed reviews. Obviously, the cost is a big prohibitive factor at the moment. But I think that there's the novelty around the device, which makes it really exciting right now. But I don't really see, like, in my life any practical use cases. You know, even if it was cheaper, if it was the product that it is today and the price was even half of what it is, I still don't really understand how I would benefit from it, but I'm definitely curious to see where it goes.

+ +

VICTORIA: Yeah. Like, I want the ability to, like, have a big screen without having a physical screen, but I don't want to wear goggles.

+ +

ZAMINA: Totally.

+ +

VICTORIA: I also get nauseous. Like, I actually tried to do a virtual hangout during COVID, and I got some 3D, whatever, virtual glasses. And I got so [chuckles] nauseous so fast. I was like, this isn't...why does anyone enjoy this? And apparently, that's something that happens to women more than men because of hormones.

+ +

ZAMINA: Oh, that is so interesting. I did not know that.

+ +

VICTORIA: But I really enjoyed our conversation today. Thank you again so much for joining us.

+ +

WILL: I'm so excited for your launch and your product. I think it's going to make a huge impact in that area. And I just can't wait to see where it goes. And thank you for building it and stepping out and taking that leap to do it.

+ +

ZAMINA: Oh yeah. Thank you both so much. It was a really great conversation, and yeah, I'm excited to get launched and excited to stay in touch and see what we do from here.

+ +

VICTORIA: Yeah, we'll have to bring you back in a year and see how things have progressed.

+ +

ZAMINA: Yeah. Let's do it. Let's pencil that in [laughs].

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Victoria Guido are joined by Zamina Karim, the CEO and Founder of Mevi, a community-driven motherhood wellness app designed to address the unique challenges of motherhood, especially in the context of the pandemic. Zamina shares her journey from experiencing postpartum anxiety and depression to founding Mevi. She discusses the lack of understanding and support for new mothers, especially during the pandemic when traditional support structures were unavailable. The conversation also touches on parenting challenges in the current era, underscoring the need for community and support.

+ +

The app aims to revolutionize maternal health by fostering connections among mothers and providing support for the challenges of motherhood beyond medical visits. Zamina's approach to building Mevi is rooted in empathy, aiming to address new mothers' emotional and practical needs and fill a significant gap in current maternal health support.

+ +

Zamina also talks about the broader implications of Mevi's mission, the evolving startup funding landscape, and the importance of pivoting and adapting in the entrepreneurial journey. She emphasizes the role of empathy in building inclusive experiences for parents and the potential of technology to improve maternal health outcomes.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 WILL: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Zamina Karim, CEO and Founder of Mevi, the first-ever community-driven motherhood wellness app. Zamina, thank you for joining us.

+ +

ZAMINA: Thank you so much for having me.

+ +

VICTORIA: Well, outside of founding Mevi, what keeps you going? What's exciting for you right now in your world?

+ +

ZAMINA: Well, I have a toddler. She is two turning three, and she keeps me incredibly active and stimulated throughout the day. And I have my hands full with her throughout the day. And outside of that, I've just jumped into the business full-time. So, I'm navigating solo foundership and recognizing how different of an experience that is when you have been working in a team environment for the last 15 years or so. So, that's kind of what's been keeping me busy the last few months.

+ +

WILL: You mentioned your daughter. When you became a parent, I know there's something surprising; there's plenty. But what was the most surprising thing that you went through when you became a parent?

+ +

ZAMINA: Oh my gosh, there were so many things. You're totally right, Will. But I think, for me, it was a really big emphasis that I noticed on the products that I would need to have. And if I had all of those products, I would be ready and I would be well on my way, and parenting would be a breeze. And it kicked me on my butt when I realized that having the perfect car seat and the perfect stroller was not setting me up for success.

+ +

And there was a lot that I didn't know and didn't realize, even though I had done so much research and had a lot of other parents in my network. I think it's one of those things that you don't truly understand until you have experienced it yourself and you are living through it.

+ +

VICTORIA: So, then, what led you to start Mevi?

+ +

ZAMINA: Mevi was started because my baby was born during the pandemic, and I experienced a ton of challenges during that time. I struggled with symptoms of anxiety and depression for over a year. But I didn't really need any clinical diagnosis, and so no one knew how to help me in my family. And I did not know how to help myself either. And I really felt the Western sort of pressure of having to do it all. And I was quite frankly embarrassed by the struggles that I was experiencing.

+ +

And, you know, you never really go back to your old self. But once she turned one, I started to feel a little bit more balanced. And I came out of my shell, and I started speaking with other women from all over the world really. And I learned very quickly that my experience was the norm and not the exception. And that really was the inspiration to go ahead and try to solve that problem.

+ +

WILL: Yeah. I remember we had my middle child at the very beginning of July 2020. And the first thing that was rough is that was whenever they were like, "If you have COVID, we may have to separate you from your child when you have birth," and it was terrifying. And they ended up not doing that. We didn't have COVID or anything. But I remember, because we have three now, and I remember thinking, like, if I was a parent of a single child, it would have to be rough because, like, the child is not playing with anyone, and you're also by yourself. So, I totally relate with what you're saying.

+ +

ZAMINA: Yeah, absolutely. And then, beyond that, all of those kinds of traditional childcare centers or places where people would congregate were shut down. And up here in Canada, a lot of those places haven't really opened back up, and so there was no real bounce back to a pre-pandemic norm. A lot of families are now just navigating with this as the new normal. So, I think it's really important to recognize that parenting in 2021 and beyond is really different from what it was pre-pandemic.

+ +

VICTORIA: So, you had this acute need yourself to build a community to survive [laughs]. What in your background led you to think, oh, I could start a company around this; I could build the solution for this problem?

+ +

ZAMINA: Yeah, it's actually a really interesting mix of personal and more technical and career-driven. So, on a personal level, I was born in India, and my parents are from East Africa. So, that cultural element really bleeds into my perspectives and my values on life, as well as what's missing in healthcare today, so this idea of taking a prevention-focused approach or addressing root causes rather than addressing symptoms, which is a lot more common in today's kind of healthcare context.

+ +

And then, on a more career-based side, my background is in consumer tech, growth marketing. And I studied psychology and human development when I was in school. So, all of these areas really came together as the perfect combination for starting Mevi because I had this hard tech background. I know how to code. I self-taught Ruby on Rails about ten years ago. And then I'd worked in this consumer space, kind of selling things for companies like Masterclass, and Uber, and Lululemon, and Aritzia. And I had this experience on the paid acquisition side as well.

+ +

So, all of those things really came together for me to feel equipped to step into this journey of building Mevi. But I think no matter what technical or kind of soft skills you have, it is still a huge climb when building a company from scratch and, in particular, when you're doing it as a solo founder.

+ +

WILL: Wow, that's so amazing. I love your background, and I love especially talking to founders who have a technical background and kind of seeing how their journey was. Did your technical background help you in anything, or did you code your app?

+ +

ZAMINA: I did not code the app. Because I was on the tech side over a decade ago, so I was building apps about ten years ago; it's one of those muscles where it can very quickly atrophy. And things now are developing at such a rapid pace compared to when I was in the space that I'm no longer someone who would be best suited to actually code the app. I would be spending a lot of time relearning versus just delegating that to somebody else.

+ +

But I do possess the ability to talk to engineers and to be able to navigate some of the architecture and the fundamentals with them and that, for me, has been a really big game changer because I'm not completely lost when chatting with technical folks. And I can kind of navigate my way around with a little bit more ease than I would be able to if I didn't have that background.

+ +

VICTORIA: Yeah. I want to talk about how you're thinking about building your team for the future and filling in those gaps that you may have since you have such a well-rounded background. But first, I wanted to go back to, what stage do you feel like you are in your product life cycle? Are you still in the discovery phase or you have an MVP? What's the phase you're at right now?

+ +

ZAMINA: We are getting our MVP built right now. So, I've done about a year's worth of user interviews, research, chatting with folks all over the world, and really doing my best at validating the concept, and the idea, and the problem space. And one thing I will say is that the problem space is super clear. Famtech and femtech are places where there's a lot of capital being invested, and there's a lot of incredible innovation happening. But the solution is something that I think is always going to be evolving as needs of parents evolve. But right now, I have a pretty solid idea of what the product should be in its first iteration, and that is what we'll be launching with in 2024. And we'll be testing with some select partners.

+ +

WILL: I'm so excited for you. Can you explain what is Mevi? What's the problem that you're looking to solve with it?

+ +

ZAMINA: We are rooted in this belief that all of the negative symptoms, the stress, the mental health disorders that are experienced by moms stem from the isolation and lack of connection that they have to their communities. So, our mission is to really revolutionize maternal health by caring for the life that happens in between doctor's visits. Really, that is where life happens. And in doing so, we want to solve for those two specific root cause factors, emotional support and social isolation, that contribute the most to postpartum disorder.

+ +

So, from a practical standpoint, what Mevi is really going to do is connect moms to their personalized support networks so that they can delegate things like critical care tasks, activities of daily living, support with things at home, as well as emotional and mental health support to their support network so that they can basically show up for them in the way that they most need.

+ +

VICTORIA: That's really exciting. And to play that back a bit, it's interesting from your research and from your own experience that the thing that was missing was that element of community and connection to other people. Can you tell us more about that?

+ +

ZAMINA: In today's world, moms are expected to do it all, and we're kind of conditioned to that regard in every aspect of our lives. And there's a lot of support lacking for moms from a childcare perspective, from a systemic support perspective around things like maternity leave. And, ultimately, I think we're kind of given these signals that we should be able to do it alone, so we should just go ahead and do that.

+ +

And I think, for that reason, a lot of women really struggle because when they do ultimately step into parenthood, particularly in a post-pandemic context, they are incredibly overwhelmed, but they're getting all of these signals that they should be able to do it. And so, then they feel incredibly isolated and really struggle with those feelings.

+ +

And so, what Mevi and what I, as a person and as a founder I'm really trying to address and bring attention to is this idea that women absolutely cannot do it alone. And that over the last, you know, 10,000 years, we have raised children, and we have also raised mothers with the support of villages. And those villages look different for different people, but that's really the case across the entire planet. And so, what I really want to do is to bring attention back to the fact that it's important to build your personal village and to be able to request support from them in the ways you need.

+ +

WILL: Yeah. So, I was looking at your website when I was doing some research, and the very first, I guess, banner, you can call it, with a text message in it, there's a text message that's sent to the mom, and I'm guessing it's AI-driven. It's asking, "Hey. Out of these three options, what exactly do you need help in?" Can you walk me through what that looks like? Is it AI-driven that sends the text out and it has a list of friends and family that sends the text to, or how does that work?

+ +

ZAMINA: Yeah. So, first big disclaimer is that what you see on the website was actually our alpha product that we tested up here in Canada with a cohort of new moms. And that was really built to validate the problem space and to understand if a solution like this would be impactful. And that was actually not AI-driven, believe it or not. It was largely built through automation tools and a database of text messages that yours truly wrote and connected with Twilio. So, it was really kind of strung together on the back-end prototype that we used to understand if getting help on tasks like this would be beneficial.

+ +

We also were sending regular kind of positive reinforcement messages, just like, you know, resources, notes, things like that, to those moms just to give them kind of a daily positive reminder. But those text messages were also being sent, yes, to their support networks that they would sign up, so their partner, perhaps their mother, their mother-in-law, their sisters, their friends, so on and so forth. And we would determine which messages would go to whom.

+ +

And through that test, we realized that there was kind of a really positive response to what this was trying to achieve but that it was quite limited in its functionality because it was hard coded on the backend, and there wasn't really a lot of AI leveraged. So, we are now moving into building out an MVP, which will be a mobile app.

+ +

WILL: Wow. I can definitely see how this is beneficial because we have three kids, and my oldest and my youngest share the same birthday, so three kids in three years. And it seems like, oh, why are you asking that simple question? Sometimes, the simple question is exactly what you need. "Hey, how can I help?" And given choices, that is huge just to nudge what you need help.

+ +

Because, like, I love my sleep and [chuckles] with kids, you don't really get sleep sometimes. And I used to remember everything, but my youngest has been dealing with earaches probably over the last month, and I am forgetting a lot just because [chuckles] I haven't been getting sleep. So, I love what you're doing. And the purpose and the problem you're trying to solve, I think is much needed.

+ +

ZAMINA: Yeah, thank you so much. That point that you made about giving options is really important because, especially when you're encountering motherhood for the first time, it's quite daunting, and you don't really know what you don't know. And so, people will say, "Oh, you know, I'm here for you. Let me know how I can help." But that in and of itself is a huge barrier because you don't really know what to ask. You don't want to infringe on them. You don't want to make it inconvenient for them. And there's also boundaries that you want to set in terms of who you want to let into your home and let into your personal space and that kind of thing.

+ +

So, I think it's really important to provide a little bit of education for new mothers around what kinds of things they can typically benefit from getting support with, particularly in the home in those early days. As an example, a lot of moms feel hesitant about letting others come into their home to hold their child. They actually would prefer that others come into the home and support them with the dishes or making a meal so that they can stay close to their baby, particularly in those early days when babies are feeding around the clock, and skin-to-skin contact is really important.

+ +

And so, it's really important to provide that guidance, especially to new moms, so that they can share that with their support networks. But then also sharing that information with their support network so that they don't feel insulted or they don't feel bad when their requests for support are directed in a different way. So, through Mevi, we also hope to provide that education and that guidance to everybody that's in the network so that they understand how to be helpful. Because I think at the end of the day, a lot of our friends and our families genuinely want to be there for us, but they just don't know how. And so, we're really there to be those coaches for them.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: I'm curious about...I think it's a hashtag on your LinkedIn profile for empathetic tech. Based on what you're describing, how does that relate to what you're building and how you build empathy into the technology and products?

+ +

ZAMINA: I am so committed to proving that we can build great businesses that do good in the world, that support women's health outcomes but are still businesses at the end of the day and make great revenue and great profits. When I came out into the space, and I kind of said, "Okay, I'm here, and I'm building this thing," particularly because I'm solving a problem for mothers, I often got met with this question of "Well, is it a nonprofit?" And no, absolutely not. It is not a nonprofit. It is intended to be a scalable business.

+ +

But I think a lot of people have a misunderstanding that if you're building something that is good for the world, that it won't generate revenue and profit. And so, from an empathetic tech standpoint, that's really something that I am kind of on a mission to prove through Mevi and through my own kind of personal endeavors. It's something that's really close to my heart. And I really, really want to put femtech on the map for that reason. And from a product standpoint, I mean, we have lots of ideas about how we can build that empathy directly into the product.

+ +

But I think the biggest thing is coaching moms to be vulnerable in ways that feel accessible to them. Again, back to this idea that women are expected to do it all and moms are expected to do it all, I think if we can start to nudge moms to sharing with their closed private networks of, you know, the handpicked people that they've put into their support networks about how they're feeling, what they need help with, you know, their mood day to day, those kinds of things, we can start to build more empathy, both in the context of that particular family, but in the broader context of motherhood as a whole.

+ +

WILL: Why do you think they automatically go to, "Oh, it's a nonprofit business," when you're talking about the mental health of women and anything in that category?

+ +

ZAMINA: I haven't figured it out yet [laughs], but in part, it feels like it's a social endeavor. "Oh, you're here to solve your own problem." And yes, I'm here to solve my own problem, but really, this is the problem of women across Canada, and the States, parts of Europe, and in Australia, and New Zealand. And so, it's not just a small niche problem.

+ +

But I think a lot of people who I've encountered, particularly in the earlier days of when I had just kind of come up on the scene, I was talking with a lot of people who didn't resonate because either they were male. They didn't have children. They weren't familiar with healthtech or femtech. And so, for them, they were like, "I don't understand this space. It must not be very big. It must not be very important," but it's quite the contrary.

+ +

VICTORIA: What other challenges have you faced so far on your journey?

+ +

ZAMINA: The other big one, honestly, is the fact that I'm a solo founder. For the last 15, 20 years, I have been working with people day in and day out, and, you know, whether it's in office or remotely, I had the option to kind of jam with them throughout the day on different problems. And in this particular journey, I don't really have that in the same way that I have been familiar with for, you know, my entire career. So, that has been a huge learning curve for me.

+ +

And I have really recognized that the journey of entrepreneurship is just as much of a mental one as it is everything else, and finding ways to cope with the kind of emotional ups and downs as you get lots of wins. But you also get doors closed in your face. All of those things require an immense amount of grit and resilience. And when you are going at it alone, it can be a little bit harder to navigate that.

+ +

But I'm slowly starting to really find my rhythm. And I've really managed to do that, I think, in large part due to an advisory board that I have built of people who are really looking to support me, who are bullish on the mission, who believe that this is a really big problem that deserves to be solved, and are helping to clear roadblocks and obstacles, both, you know, in the environment, but also for me when I get in my own head about things. And that has been really, really powerful for me is, kind of building that advisory board of people.

+ +

WILL: Since we're talking about hurdles, what are some of the hurdles you see in the future? Since we talked about your past ones and your current ones, do you see any on the future—on the horizon?

+ +

ZAMINA: Yeah, I mean, obviously, there's the kind of traditional ones of finding product-market fit and landing the product with that ideal customer. And so, I'm really excited about the work that's being done right now to get there. But, obviously, it's going to be a constant, you know, road of iteration and evolution on the product space. And that is one that I'm really excited about.

+ +

But I think the other bigger one is just the consumer landscape right now is a tough one to be in. Capital is drying up from an investment standpoint. And I've seen a lot of founders who are farther ahead in their journey, who have incredible results, that are growing rapidly year on year, and they are struggling to raise money. And they've got traction, really, really great traction.

+ +

So, at this stage, it's really important for me to find ways to self-fund and bootstrap through this period, which ultimately, I think is going to give me a competitive advantage. It's going to give every founder who's doing the same thing a competitive advantage in the long run because I believe that if you can get traction in this environment, you're truly building a really great business. But I do see that this area of capital being one that founders are really going to have to navigate for the next year or two.

+ +

VICTORIA: That resonates with some stories that we've heard as well. And I'm curious to hear you talk about the discovery process a little bit more. Was there anything that you discovered early on that caused you to pivot in strategy?

+ +

ZAMINA: So, I joined a pre-accelerator in San Francisco late 2023. And we built this vision of the MVP that I was really excited about. And as I was getting ready to think about actually building it out, what I realized was that in the feature set that we had built out, we were trying to do way too much. I had this vision of what Mevi could be ten years from now, and I was almost trying to build that in in an MVP.

+ +

And so, one of the big pivots that I made from a product perspective was really, really dialing it back and simplifying the feature set to really what I believed and what I had heard from folks would be the most impactful for them rather than, you know, squeezing in a bunch of other things that would be kind of beneficial or a value-add in the long run. I really wanted to ensure that when we did launch and when we do launch that, people really understand what we're here to do. And then, over time, as we get more and more consumer feedback, of course, we can continue to build the product in the direction that folks are desiring. But that was an early pivot.

+ +

And another one was more on the business model side, and this is one that I'm still kind of workshopping and working through with different folks. But this idea of going direct to consumer versus actually going to other companies and other businesses who serve this population of new mothers and actually selling the product to them, and then having them use it in their different contexts as they serve their clients.

+ +

And so, we've kind of pivoted our business model from B2C to B2B2C, which, even in doing so over the last month, has really, really gotten a lot of very positive signals that that is kind of the right approach to be making in the short term. And then, of course, you know, again, once we launch and we get that consumer feedback, we will continue to explore and expand other business models. But early on, I was just trying to do a lot. And in both of those pivots, I found some focus, and I'm really, really excited by that.

+ +

WILL: That's awesome. I love how you said pivoting. I think that's probably the core to having a successful business, knowing when to pivot, knowing when not to. What does success look like for you in, like, the next six months, you know, five years, especially when...I know you have a launch coming up. You're talking about raising capital. You kind of pivot on your business plans a little. What does it look like to be successful in that timeframe?

+ +

ZAMINA: In the next few months, success is really just going to be doing what we say we're going to do and putting an app out into the market and having it really be tested with some hand-picked partners who are also innovating in the maternal health space. I really believe in aligning with people who believe deeply in solving this problem. And I think that's just the low-hanging fruit as well from a business standpoint. And so, over the next six months, that's really what I'll be prioritizing.

+ +

And then, over the next, gosh, five, seven years, I really want it to be a full suite of features and tools that moms can leverage through a mobile platform. I really want it to be kind of, like, the Flo app [chuckles] for mothering, a household name that is doled out, you know, from OBGYNs who are saying, "Oh, hey, you should check this out now that you're pregnant," used by doula practices or midwife institutes, circulated among friends as the must-have app to have on your phone when you find out that you're pregnant. Obviously, that is a really, really lofty goal. But I do believe that there is a pretty big gap in this market, and I'm excited to try to fill it.

+ +

VICTORIA: How do you balance having ambitious goals against also needing to maintain your life and your life as a parent?

+ +

ZAMINA: I have a really incredible support system. My husband is an entrepreneur as well. And really, my career over the last ten years allowed him to pursue his entrepreneurial dreams, and he's absolutely killing it. And so, he kind of said to me, "Hey, it's your turn. I really want to give you the space to try this thing out and see where it can go. I really believe in it." I have him kind of in my corner every day, cheering me on and giving me a lot of space to learn and, grow and pivot from time to time.

+ +

But I also think that he's really great from a financial standpoint and helping me kind of navigate, you know, these goals and understanding kind of the revenue potential of the business and those kinds of things. And so, I have a really great balance of, you know, me being kind of pie in the sky, head in the clouds, really, really aspirational about what I'm building. And he does two things really great. He kind of brings me back to earth sometimes, but he also has a really, really great financial acumen that he lends to the business. And so, he's really kind of my champion and has allowed me to pursue this.

+ +

WILL: I'm so glad that you have a supportive partner. That could be a make-it or break-it a lot of times. It's just someone in your corner that you can trust and know that they have your back. I think that's just huge.

+ +

ZAMINA: Yeah, absolutely. I'm super lucky.

+ +

WILL: What motivates you? What makes you...because being an entrepreneur is not easy. It's a lot of long hours, a lot of sleepless nights at times. So, what motivates you to want to be an entrepreneur?

+ +

ZAMINA: I really want to leave the world in a better place than I found it. I spent a lot of time in my career, particularly on the marketing side, selling people things. And some of those things were great, and some of those things were absolutely things that they did not need. And I think once I became a parent, my perspective on life really shifted. And I realized that I wanted to spend my time doing something that I could be proud of but that would also, you know, do good in the world.

+ +

I'm fueled by this idea that I'm building in a space that has kind of been underserved for decades and, that I'm solving a real-world tangible problem, and that I have a lot of people who have provided some incredible guidance, feedback, support along the way, who are validating the journey that we're on. And so, all of those things kind of, you know, fuel me in that way.

+ +

And then, I think from a practical standpoint, just being able to build and design my life in the way that, you know, excites me, being able to spend time with my family, to have that flexibility. You know, in these early days, I don't have a lot of that because I'm spending a lot of time in the business, but I'm excited by the opportunity that it will present in the long run.

+ +

VICTORIA: That's really exciting. And it reminds me just about what are your core values, and what values drive your everyday decisions?

+ +

ZAMINA: I think it's really the one around the desire to leave the world in a better place. Again, when my daughter was born, I just saw things in a really different way. You know, I think I had been largely ignorant to a lot of that and not to the fault of my own. I think it's just one of those things that you don't really understand until you become a parent.

+ +

You see how difficult it is to obtain childcare. You see how predatory it can be when it comes to consumption around toys, and products, and nutrition. And there's just a lot of things that become apparent to you that you don't really realize. And so, anything that I do and anyone that I align myself with is really centered around this idea and this desire to leave the world in a better place than I found it.

+ +

WILL: Yeah, I totally agree with that. And I wish there were so many more resources out there because it's a hard thing to do. So, I really am glad that you're doing this. And it kind of leads into my next question. Do you have any advice for building an inclusive experience for parents?

+ +

ZAMINA: If you spend any time on social media, you will see that people are very quick to dole out advice and to have comments on how other people choose to do things in their families, particularly in the context of, you know, female and motherhood-based content creators. And, honestly, the biggest thing that's missing when those kinds of things happen is empathy.

+ +

A lot of the times, we feel maybe a little bit insecure, or we feel worried that decisions that we're making are not good, or we feel worried about being judged. And so, maybe we shift that onto other people. We project that onto other people. And what I've just seen come up time and time again is if everyone could just see the fact that everyone's struggle is very unique to their individual context. You never know what other families might be dealing with. You don't understand, you know, what difficulties they might be having at work, what difficulties they might be having with childcare, what their financial situation is. And all of that informs their decision-making, and everyone's just doing the best that they can.

+ +

You know, when it comes to how we engage with other parents on social media, how we engage with other parents in real life, at work, in products, it's really just about trying to bridge the gap through empathy. And that's obviously way, way easier said than done. But I think it's really important because sometimes we just need that window to get the glance into other people's lives to really understand, oh, I should maybe, you know, keep that particular opinion to myself or maybe not be so judgmental in this particular context? And so, yeah, I think that's the biggest piece of advice that I have just for anyone that is navigating life in any context with a parent.

+ +

VICTORIA: That's really helpful. Thank you. And it's, like, leading with empathy again, right?

+ +

ZAMINA: Absolutely. Yeah [laughs]. The commonality here is absolutely leading with empathy.

+ +

VICTORIA: Well, wonderful. I've really enjoyed our conversation so far. Is there anything else that you would like to promote?

+ +

ZAMINA: Two quick things. Like I said, we are getting ready to launch in the middle of the year, so I'm really excited for that. And if anyone listening is excited by the mission, you can sign up for our waitlist at getmevi.com. Again, disclaimer, the website is a little bit out of date. It needs some work. But the wait list is very much active and works just fine. So, it'd be great to capture your intention there. And then, you can also follow us on Instagram @getmevi.

+ +

VICTORIA: Wonderful. And also, do you have any questions for me or Will?

+ +

ZAMINA: Gosh, yeah, I mean, I would love to understand kind of what patterns are you seeing in terms of what founders are building right now? Have you noticed kind of any underlying trends that you think would be valuable to share?

+ +

VICTORIA: Well, I can talk about my experience connecting to the San Diego community, startup and founders community. So, it is interesting. I think what you mentioned earlier about trying to bootstrap as much as you can and do it yourself as much as you can. I've seen founders show an interest in learning more about low-code tools and using those to prove out their MVP and prove out their concept and go from there.

+ +

There's always shifts in the investment, right? So, people, I think, are even more going to fall into their similar patterns for what they choose to invest in and take less risks. It's trending upward again, and we're starting to see some signs of investment picking up again.

+ +

You know, being in San Diego is an interesting place because we're right next to Tijuana, and you can be in Mexico in 30 minutes from my house or 45, depending on traffic. And there's just a lot of opportunity to do all different types of startups around here: biotech startups and startups that help you predict if breast cancer is going to come back. And there's also just all kinds of interesting things going on with actual physical products as well and treating products as more of a startup-type model. So, that's what I see going around here. But, Will, what do you think?

+ +

WILL: Yeah, I was actually thinking about probably the last two or three podcast episodes that I recorded, it was around parenting and motherhood. So, I think that's a good thing because, like you said, it's an underserved area, but it's amazing to see what that community is doing. And I think it's going to be so good, especially in the next couple of years. After talking to those founders and even yourself, the pandemic, I think, encouraged a lot of that growth in that area. So, I think we're going to see a lot of growth in that area, and I'm excited about it.

+ +

ZAMINA: Yeah, absolutely. I totally agree with both of those things. And I think the no-code one is one in particular that will fuel a lot of innovation, not only in this industry but across tech as a whole. I'm seeing some really, really great advancements happening and making it a lot easier for solo non-technical founders or just non-technical people in general to prototype things very, very quickly.

+ +

VICTORIA: Absolutely. And then, the tools to build products that are really compliant and mature and ready for healthtech and FinTech. There's also so much more out there available to give people the resources they need to do it right. So, it's really interesting. And yeah, I think, like you said, with COVID, too, the acceptance of virtual healthcare and the need for virtual communities, and that's not gone away [laughs]. There are still some people who won't want to re-engage in-person events and community building, so...

+ +

ZAMINA: Yeah, this is kind of the new normal for us, and we've got to figure out how do we maintain our well-being and how do we maintain different types of social connectivity in this world that is becoming increasingly interpersonally independent? So, I think even AI and, you know, the Apple Vision Pro has really sparked conversations around what's going to happen to in-person interaction if everyone is wearing these massive devices on their faces? And I think, at this point, we can only imagine. But I do think it's a very practical and real thing that we should be solving for today and not just be waiting until we're all wearing these massive devices to recognize that we need to solve for that connectivity between all of us.

+ +

VICTORIA: Have you tried out a Vision Pro yet?

+ +

ZAMINA: I have not. Have you?

+ +

VICTORIA: No, I haven't tried it. And I haven't ever talked to anyone who is using it. So, I'm curious. One of these days.

+ +

ZAMINA: I've met a few people, or I know a few people who have tried it, mixed reviews. Obviously, the cost is a big prohibitive factor at the moment. But I think that there's the novelty around the device, which makes it really exciting right now. But I don't really see, like, in my life any practical use cases. You know, even if it was cheaper, if it was the product that it is today and the price was even half of what it is, I still don't really understand how I would benefit from it, but I'm definitely curious to see where it goes.

+ +

VICTORIA: Yeah. Like, I want the ability to, like, have a big screen without having a physical screen, but I don't want to wear goggles.

+ +

ZAMINA: Totally.

+ +

VICTORIA: I also get nauseous. Like, I actually tried to do a virtual hangout during COVID, and I got some 3D, whatever, virtual glasses. And I got so [chuckles] nauseous so fast. I was like, this isn't...why does anyone enjoy this? And apparently, that's something that happens to women more than men because of hormones.

+ +

ZAMINA: Oh, that is so interesting. I did not know that.

+ +

VICTORIA: But I really enjoyed our conversation today. Thank you again so much for joining us.

+ +

WILL: I'm so excited for your launch and your product. I think it's going to make a huge impact in that area. And I just can't wait to see where it goes. And thank you for building it and stepping out and taking that leap to do it.

+ +

ZAMINA: Oh yeah. Thank you both so much. It was a really great conversation, and yeah, I'm excited to get launched and excited to stay in touch and see what we do from here.

+ +

VICTORIA: Yeah, we'll have to bring you back in a year and see how things have progressed.

+ +

ZAMINA: Yeah. Let's do it. Let's pencil that in [laughs].

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Sy1WX5uU + + ]]> + + Will Larry + Victoria Guido + + + 519: Ammi's Mission to Empower Parents + https://podcast.thoughtbot.com/519 + c3df4252-f725-403a-b15c-7ef80e1cbe4a + Thu, 04 Apr 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Will Larry talks with Priyanka Mahajan, founder of Ammi, about the startup's mission to support new and expectant parents through expert advice, community, and digital resources. They delve into the unique challenges of parenting, including the transition to motherhood, mental health, and the concept of "matrescence." Priyanka shares her personal journey and the inspiration behind Ammi, highlighting the need for a tailored support system for parents in the early stages of parenthood. + 42:47 + no + + + Host Will Larry is joined by Priyanka Mahajan, the founder of Ammi, a startup dedicated to supporting new and expectant parents with expertise, support, and community. The conversation highlights the challenges of parenting, the absence of a universal parenting manual, and how Ammi seeks to provide a personalized co-pilot for parents navigating the early stages of parenthood. Priyanka shares her journey from a career in strategy consulting and corporate roles across different countries to founding Ammi, driven by personal experiences and the desire to make a meaningful impact on parents' lives. +Priyanka discusses the core challenges she faced as a parent, such as dealing with the loss of control, the transition to motherhood, and the importance of acknowledging and navigating the mental and emotional shifts that come with it. She introduces the concept of "matrescence," likening it to adolescence, as a significant, yet underdiscussed, transition into parenthood. Priyanka's personal struggles with anxiety and the impact on her parenting led to the realization of the need for support and resources for parents, particularly in the areas of mental health and emotional well-being. +Ammi's mission is to fill the gaps in the current parenting support ecosystem by providing accessible expert advice and resources. Priyanka emphasizes the importance of mental health, the creation of a supportive community, and the development of a digital platform tailored to modern parents' needs. Finally, she outlines the challenges and opportunities ahead, including fundraising, product development, and establishing trust with parents. +Ammi (https://www.joinammi.com/) +Follow Ammi on LinkedIn (https://www.linkedin.com/company/joinammi/), YouTube (https://www.youtube.com/@joinammi), Facebook (https://www.facebook.com/Join.Ammi/), or Instagram (https://www.instagram.com/join_ammi). +Follow Priyanka Mahajan on LinkedIn (https://www.linkedin.com/in/priyanka-mahajan-0167852/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Priyanka Mahajan, Founder of Ammi, a startup that provides expertise, support, and community to new and expectant parents. Priyanka, thank you for joining me today. +PRIYANKA: Will, thanks for having me. It's great to be here. +WILL: Yeah. I'm so excited to talk to you about parenting. Anytime I get to talk about parenting, I light up, so I can't wait to talk to you about it, pick your brain, and just hear any advice you have for me. +PRIYANKA: [laughs] That's great. It's always nice to talk to people who get the challenges, so very happy to dive into it. +WILL: Yeah, definitely. Me and my wife we always talk about we wish kids came with a manual because you just don't know what you're going to get. Out of my three kids, they're all not even close to being similar in any way. +PRIYANKA: No, that's totally right. You know, this manual that most people or most parents wish for after their kids are born doesn't quite exist. And it's also deeply personal, and that's exactly what you mentioned about your kids being different. But each parenting experience and, you know, giving birth is different. Each birth is different. Your body is different. So, all of that is quite deeply personal. And that's essentially what we want to do with Ammi is be able to provide this co-pilot to expectant and new parents to guide and help them through that early phase. +WILL: Yeah, oh, I can't wait. Before we dive in too deep, can you tell us a little bit about who you are, your background, and kind of how you got to this place? +PRIYANKA: So, first thing, I suppose, is I am Indian. I was born and raised in India, and I've lived in about four countries, including the U.S., and now live in London. I started my career in the strategy consulting area and then moved into internal strategy roles for telecoms and tech industry. And I had my children through that period of working for big corporates and essentially, you know, was busy climbing the corporate ladder or moved into different roles. +I have headed teams in marketing, in commercial, in other areas like operations. And eventually ended up being a director of strategy for the EMEA region for this large American telecoms company. And it was then that COVID struck and essentially that's basically where there were big, large life events, which I'm happy to get into later. But essentially, I resigned from my role and decided to focus on more meaningful ventures. So, here I am [laughs]. +WILL: Yeah. So, were there any challenges having a career and having children? There were challenges. +PRIYANKA: That's right. +WILL: What were some of the challenges that you faced? +PRIYANKA: I had my kids really close together. I had a very difficult birth the first time around. I had a very easy pregnancy but a difficult birth. And especially for parents and, you know, women who are mothers, who are giving birth and previously have had this illusion of control, and, you know, being organized and in control and being on top of everything to suddenly not having anything in your control because that's what kids are like. +And not having that acknowledged and, you know, you still expect to do everything in a certain way, and you want to sort of do everything right. And that's just not how parenting is. There's no one right way, and it's okay to make mistakes, but also, equally, it's important to not know that you're failing. And I think that was a challenge that I had equally. +You know, I went back into work part-time. And here in the UK, I had a fairly generous maternity leave policy, which was great. But also, having to sort of think about putting my career on a bit of a back burner while my kids took priority was a transition. And just making that transition mentally, emotionally, physically in your life and making space for this new world is quite challenging as, you know, you're sort of grieving the life you had. But you're also embracing what's here and being surprised by it and figuring out who you are. +And that the term, actually, is known as matrescence, right? So, it's this process as we have adolescence. It's becoming a parent. It's, you know, its own transition. And I don't think that's been talked about enough, certainly not when I had my kids. So, I wasn't actually aware that that's what I was going through. I just kept thinking that I'm failing. And I think those memories and that experience was deeply embedded in my sort of process. And I went on to, you know, sort of do other things and go back into my career. And I never really dealt with the emotions that I felt at that stage of my early parenting journey. +And it really all came to light sort of when Ammi was born and hatched in the incubator that I did after I resigned from my corporate role at ZINC, where, you know, the focus was on children and young people's mental health. And in that, I sort of, like, started to research the space and go like, where do you actually start with children and young people? And you start with the parents at that very early stage. +So, that's sort of, like, what led me to almost kind of revisit my own experiences in that phase and think, you know, there was something there. And if we had probably done things differently, maybe the outcomes might have been different for our family, the way that we did things or the way that we dealt with each other in those early years. +Because the other thing I learned as well while I was doing my research in that space, which I didn't know at the time when I had my kids, is that children have their emotional development take place pretty much by the time from zero to three years of age. So, it's a very significant period of sort of secure attachment, as we call it, and things. So, that's, again, a lot of concepts that I wasn't familiar with, and I wish that I was kinder to myself. And that's basically what I want to do for the community that I'm supporting through Ammi. +WILL: That is such a good point because my oldest son he has a lot of tendecies that are like mine. So, we're a lot alike, and I find that mental health aspect of that, like, how can I help him the most? How can I help him to where he doesn't have the same failures I have? Like, it's not easy being a parent because it's like, do I step in? Do I not? Do I let him fail? Do I not let him fail? +So, like, and like you said, I think parenting is probably one of the most lonely things you can go through at times, depending on who's around you, if you have family around you, friends that have children, or not. So, I'm so glad that you said that you're diving into that mental health aspect also. +PRIYANKA: Yeah, that's a key pillar of what we do and what we're building essentially at Ammi. So, the mental health aspect is one that isn't really talked about, and there's a lot of stigma and shame associated with that, in that early stage especially. And the figures itself are astounding, you know, in the UK itself, it's 1 in 3 mothers experience perinatal mental health issues. In the U.S., I think it's 1 in 5. And 1 in 10 dads experience mental health issues. And there is a certain shame in addressing that. You're meant to be happy, and you're meant to be blessed. And which is true, you are blessed, and, you know, there are moments of happiness. But this is a massive transition that you're going through. +And it's an interesting word you used as well: lonely. So, in our research and interviews with the countless scores of, you know, tens of moms that we have interviewed, the most common word was isolation. It's exactly that. Like, it can feel like a very isolating experience without the village or the community that kids were meant to be raised under and parents were meant to be supported through that. But that is no longer the case in the way that we live today. And that's where there's an opportunity to provide that to parents in a way that works with our modern lives as well. +So, for example, what we're doing at Ammi with the mental health particularly is we have developed an evidence-based solution based on acceptance and commitment therapy, which is essentially an incredible sort of modality of therapy that addresses life changes in particular. It helps you figure out your values and your parenting values and helps you set goals and actions in line with those values. So, you feel like you have meaning even though your life is changing, and it still feels significant. And now, of course, you're in charge of a child. So, how do you ensure that you're not losing yourself but equally you're bringing your own values to your parenting? I just found it fascinating. +And we're doing this in a digital way. We're doing this in a way that works for the modern parent. So, it's bite-sized. It's on your phone. You can interact with it in the middle of the night when you're feeding the baby, or you're, you know, sort of up at the odd hours of the morning with your child. That's essentially, like, what we're doing with that particular mental health piece. +WILL: That is so good because I think even you said the values, like, I think we forget about that easily. And that is everything we do, like, the way we talk to our kids, the way we're raising them, the way we discipline them, what school they're going to. But I think so many times we run out of mental headspace to even talk about those things and to write them down. So, oh, that's so good that you go through that, and you help them discover what their values are because I think sometimes, as parents, you can lose that. Even if you had the values before you had kids, it's easy to lose those values and to remember why you're doing it. +PRIYANKA: That's right. And, you know, in some cases, you know, you forget, and you don't even know really what your values might be, right? Like, you're just kind of doing things because you think you should. And should is a dangerous word as well because it's sort of, how do you uncover what it is that you really want to do as well? And what's authentic to you as an individual and as a parent? +So, for example, I'll give you one, like, structure, right? Like, I, as a parent, can get so hung up on structure as a value. I forget about connection. And, actually, if I had to, like, sort of rank these, you know, connection would be higher on my list, personally. And it's like, why am I not acting on that? And so, what values essentially do is give you this compass in terms of, like, deciding what course of action to take and how you prioritize things. +And, equally, it's also important to note that, you know, values do shift and change. So, we say in this world that it's imagine that you're looking at a globe, and a globe sort of, like, spins. And there may be some values that are topical now, but others that come to fore. So, you've got to, like, hold them lightly as well and acknowledge that they do shift. And all of this may seem sort of a bit indulgent to talk and think about, but, actually, it's really relevant in your day-to-day and also in the way that you live, you work, you parent. It's all very relevant. And I think it's important to bring light to that in the parenting context as well. +WILL: That's really, really good. So, I wanted to kind of dive deeper into those pillars you're talking about. I know you said mental health was one. What are some of the other pillars that you cover? +PRIYANKA: You know, the other thing that I've lived through and I've discovered in my, you know, research with my community and with my parents is it's one thing to sort of work on yourself, right? But if the system around you is a bit broken, it's not all in your control. So, what we want to do as well is, like, fill some of those gaps that currently exist in the system. +So, for example, you know, here in the UK, since COVID especially, and for a few years before then, you know, we rely on the public healthcare system. And there have been significant challenges with funding there, which means that a lot of the support that was available to birthing parents, to birthing people are just not available anymore. There's no continuity of care, the kind of support you could expect in terms of checks and, you know, seeing the same person, for example, seeing the same midwife. That just doesn't exist anymore. +So, what you end up having is a lot of parents who are trying to do their best, but essentially scrambling around looking for solutions, whether that's, like, for sleep, or breastfeeding, or nutrition and taking care of their baby. And that is what essentially results in those feelings of failure. +So, what we want to do at Ammi is actually provide that practical expertise as well in the most accessible way. For example, here you could go private. You could see these experts privately, but that's really expensive. And there's nothing really available in the middle, I mean, apart from, like, the free Instagram reels and things. So, what we want to do is be able to provide, again, convenient formats where you can directly access these experts. And what I mean by that is, and what we already do here at Ammi, is we run online workshops with these experts, and these are currently actually free for parents to join. +So, we rope in experts who are equally passionate about this. So, they could be experts in pediatrics, or they could be experts in physical and maternal health and wellness, but also infant health and wellness. And they run these sessions for us, and parents can join and essentially interacting live. It happens usually after bedtime, so when parents can attend. And that's one format. +What we also want to build within our digital solution is a way for parents to access these experts on chat, text messaging, as well as book appointments with them, but, like, they may be shorter form appointments, so they're not as expensive. And it's virtual, which, again, cuts out the cost of actually having to see the expert in an office or in a space that is charged, so that helps with some of the cost. Equally, it helps to have experts who can do this on their downtime on chat format. So, that also helps with the cost. +So, we're trying to experiment with these different formats that also work from a parent standpoint of convenience. So, you're not taking time off work to see these experts. So, you're not doing that in, like, daytime hours or when your baby's sleeping. So, it's really about convenience and accessibility. +WILL: That sounds really good. I like the access to the people that know what they're talking about, especially late at night and things like that. That sounds so amazing because there's so many times that, like, I remember whenever, Cruz, he's my oldest, he just wasn't feeding with Katie. And we were like, we don't know why. And the first couple of weeks, I think we went into a doctor's office, like, three or four times just to make sure that he got back up to his birth weight. And it was scary. It was like, are we doing anything wrong? Like, what do we have to do to get him to this place and stuff like that? +So, I think sometimes it's just like, "Hey, you're doing the right thing." Like we had one pediatrician...we moved from North Carolina to Florida, and we kind of miss our old pediatrician. Because when we walked in, she was just like, "Hey, he's healthy. I could tell he's healthy, and you're doing all the things right." It was almost like a weight lifted off our backs just to hear like, "Hey. You're doing okay." So, that's good to hear that you're providing that to parents and stuff. You say you're based in London. +PRIYANKA: Right. +WILL: And I'm just being honest; I have no idea what the medical situation looks like there. Can you explain what that looks like? Because I know what it looks like in the U.S. But I don't want to be naive and say, "Oh, it's the same." What does it look like when you say someone can't have access to a private provider? +PRIYANKA: So, it's not that they can't have access. So, historically, in a lot of countries in Europe and here in the UK, we have what is called the National Healthcare System or the NHS. And, essentially, what that means is that your healthcare is covered by the state, which is incredible, actually that, you know, you don't really need to spend on private insurance or private healthcare. +So, for most parents, including myself, I gave birth both times through the NHS. What that means is that, you know, you sort of, like, you get into the system. You go to your GP. You don't actually get a pediatrician, which is also something that I wasn't used to in India, but there's no pediatricians. And they have a system that you go through. So, you know, you get assigned a hospital, or you can choose a hospital that's local, but generally, you get assigned to a hospital. And you sort of give birth there under their condition. +So, there's not a lot of agency and that, I guess, is the key word because you are under the healthcare system. And essentially, that is the majority. The overwhelming majority of people give birth that way in the UK. I think 12% of the UK has private insurance cover. But equally, even if you have private insurance cover, which means that you can choose your medical care or you can, you know, sort of reimburse, get reimbursed, and things, a lot of them don't actually cover giving birth because it's not a medical condition. So, you have to pay for that privately, and it does cost quite a significant sum of money if you want to go private. +And there's just a few hospitals, actually, in London. There's not that many hospitals outside of London that do this either. So, it's not a very accessible option for most people because it's expensive, and there just aren't enough places that do that. So, in terms of that continuity of care, you have your GP, but, you know, the GP, essentially, has 10 minutes per appointment. So, you don't get a lot of time with your healthcare provider. +And equally, when you have your midwife appointments to the NHS now, you don't see the same person, so, you know, through your scan. So, it's generally someone different. You might get lucky and see the same person. So, it's quite intimidating, I have to say, you know, you don't know really, like, what you can, cannot ask for. It's not very clear what your rights are, even though, you know, they do try their best. But because of the funding shortages now and the way that the system is going, people really are struggling to access care to the level. +I mean, even, you know, the midwives are leaving the NHS. There's 29 out of 30 midwives leave the NHS after two years of training, which is shocking given, you know, the investment that they make in time. So, it is getting pretty dire, and people's birth stories are just getting quite horrific. And it's become commonplace. It's not unusual anymore, where it used to be quite unusual. +You know, there's this perfect storm building right now here in the UK of people who are struggling to get the care they need. And paternity services, in particular, are also suffering quite a lot. And there's this dearth of services, right? And people are starting, like, there are a lot of, like, sort of, like, now smaller companies coming up, trying to, like, fill in this gap through employee benefits, which is one of the routes that we plan to take to market as well. +But also, birth coaches is, you have the birthing coaches and doulas. And this is a very small market here in the UK, but it's growing in, like, triple digits year on year. So, it's really interesting to see the private world is stepping up or is trying to step up to the challenges of what the public system isn't able to do anymore. Does that help, or [chuckles] does it sort of give you some context? +WILL: Yes, that helps tremendously because here, where I'm at, it's mostly employee benefits, and it's more private. We still have so many issues because I was thinking what you're doing. I was like, oh, that's so helpful, even with what we're dealing with, but it sounds like even next level. +Like, I can't imagine taking my kid to the doctor and seeing a different doctor every single time because sometimes that's part of the helpfulness is they're like, "Oh, we know your kid. We know what they're going through. And, actually, I probably treated them the last time they were in here, so I kind of know." Because even if you have notes, it's tough to understand exactly what you saw. Yeah, I could see the benefits of what you're doing. So, that's amazing. +PRIYANKA: Yeah, that's right. And equally, like, with the employee benefits now, this is one of the benefits. The top five benefits that employees want from their employers is more family support and more time around that. And we're also seeing in terms of, you know, employee retention, right? And keeping the gender pay gap at the minimum. It's about retaining also your, you know, female employees, especially mothers who tend to leave the workforce after having children, even here in the UK. I know it's actually a lot worse in the U.S., is my understanding. +But even here in the UK where you do get more benefits in terms of maternity leave, it's still the cost of childcare. And there are so many other issues about just not having that support system that completely sort of overwhelm the families for one of them to have to drop their career, which is unfortunate. So, I think there is definitely a play here for employers to step up here in the UK and in Europe to this challenge of retaining their employees through benefits such as this. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +WILL: What are some other ideas that you have? What does success look like in the next six months, five years for you? Where are y'all going? +PRIYANKA: Well, in the next six months, I think it's really about getting the product to market, like, getting our MVP and product out there. You know, we're doing things in a very scrappy way at the moment. I am, for all practical purposes, a solo founder, and I've been bootstrapping. What we have developed, you know, with my fractional team of clinicians and my CTO is we have a really high-spec figma prototype of what our solution would look like. We have our content ready and the mental health, the evidence-based mental health program ready. +It's now about getting that on a platform, and that is going to require some funding. So, I'm in the process of fundraising. So, ideally, in six months, we would have raised enough money to get that MVP out and to get this product in the hands of our customers, our customers being potentially employers. But also, you know, within the Ammi community, I've also been building a community as I've been running these online sessions and creating that side of content as well on the practical expertise side. +And we've got about 500-plus parents around London who have attended our workshops, and most of them are part of this community. And, you know, they're the ones that we've sort of tapped on for our testing. For also the content that we developed, we handed it over to them and, you know, we ran a trial and with some great results. So, that's basically the kind of work that we've done so far over the last year. And, really, in the next six months, it's about getting the product out, raising some money, and, yeah, hopefully, being revenue-generating. So [laughs], it's a lot to look forward to, a lot to do. +WILL: It sounds like that's that next heel, the next step, so...and it sounds fun. You help parents with their core values. What are some of the core values that you use and that you have that you make decisions through every day? +PRIYANKA: It's about authenticity. That's the guiding principle. It's about being authentic to our mission, being authentic to what the customer wants, you know, first and foremost, and authentic to what my vision for Ammi is, which is to be that co-pilot in those early years. And how that sort of helps me is even when I look at funding, and I look at the type of funding or who we, you know, want money from, I know that, you know, sort of, we can't really dictate that at this point. But I really don't want there to be a risk of mission drift from what we're trying to do here. I've lived that life before where I've done things to just sort of tick the boxes. +And I do genuinely think that there is a commercial opportunity here as well within the mission that we're trying to achieve because, you know, from employers to parents themselves, they're spending money on this now, and, you know, the tide is turning. So, for me, authenticity is number one. And, generally, like, you know, when I am faced with any decisions, whether that's a product-based decision, I'm like, right, like, what's more important to our community? What do they really want? +So, it's all about going back there and seeing, like, what is going to give them most value? It's about understanding when we look at the development or getting team members on board, it's, you know, who believes in the mission? So, that generally is what guides me in my day-to-day decision-making process. +WILL: Yeah, I really like that because I feel like, especially with social media, there's a lack of authenticity sometimes. Sometimes, I feel like society wants you to be this superhero as parents. And sometimes it's like, I think I have some of my best moments with my kids and some of my worst times with my kids. Just, like, I think sometimes just being honest about this is where you're at as a parent. You're doing okay. Maybe you need to tweak this, this, and this, but I think that's a good thing to go by. So, I really like that you said that. +PRIYANKA: Well, there's lots of ways to make money. Entrepreneurship that might be one of the things you do to make money, right? But it's not the easiest way. You know, I gave up my corporate career for a good reason, and I want to remember that. It was to sort of achieve big things but being authentic. So, that's really, like, where we are at. +WILL: I love it. Love it. I usually ask this question around careers, but I'm going to ask it for parenting. So, if you can go back in time and give yourself advice on your parenting, what advice would you give? +PRIYANKA: I would just say chill out [laughs]. You know, I think I was so hard on myself, right? So, for example, like, you know, when my son was born, my firstborn, I was so hell-bent on breastfeeding and, like, every bottle I had to give him a bottle day three because, you know, like you, like, my son as well he lost a lot of his weight, and we got worried. And he wasn't feeding. I didn't have a supply. So, it was so hard, and I felt like I failed. Every time he didn't sleep through the night, it felt like I failed. +So, I sort of took responsibility for all of it. Like, you know, this is, you know, that I'm failing this next project. But I wish I could just, you know, sort of go back and be like, this is all part of the journey. And this is a, you know, sort of a small person that you're trying to raise, and they have different rhythms, and it doesn't go by the book. So, those are some of the things I would tell myself is just to be kinder. +And, you know, actually, that's another thing that we do at Ammi is, like, just that self-compassion in our program about, like, just being easy on yourself for those years. I had to sort of come back and, you know, as you said, bounce back. And, again, all of that there's just incredible amounts of pressure on parents. Yeah, I think I would just tell myself to be kinder and be patient through all of that and things will work out. +WILL: I appreciate you saying that because I needed to hear that, to be honest with you. [laughter] Yeah. Just, I think, my kids are 4, 3, and almost 2, so, like, 22 months. So, "It's going to be okay, and chill out" is really good advice for me to hear at this time. So, I appreciate you saying that. +PRIYANKA: Yeah. And it will be, you know, I mean, I know it's hard. Like, it's as they say, the days are, you know, long, and the years are short. But when you're in it and when you haven't slept in a week [laughs], it can feel like it's just dragging on forever [laughter]. And that's one of the hardest challenges, right? Sleep deprivation. So, sleep workshops are the most popular, as you would expect. You know, we get sleep experts to come in and talk about it. And, generally, you know, what's really interesting is, like, through a lot of these workshops, what they all end up really saying is that everything is normal [laughs]. +So, it's not like one sort of thing is normal. And just having an expert say that to you and say that to our parents who join these calls is just incredibly relieving for them that they're not, you know, in some race and competition to see whose kid has slept through the night or, like, what's, you know, what I'm doing wrong, whose kid is eating the most variety of fruit and veg, you know, that's not what it's about. It's all normal. And they just go away and sleep well that night, right? Like, after a workshop because they're like, this is great. I'm doing it okay [laughter]. +WILL: Well, once again, that's good to hear because, like, last night, I think I got five hours of sleep because of my son. +PRIYANKA: Ooh. +WILL: Thank you for saying even that because, like, you question yourself a lot. Like, I know I do. I question myself a lot. Am I doing the right thing? Is this what I'm supposed to be doing? So yeah, that's really good to hear. +PRIYANKA: Yeah, it's a common ailment that [laughs], you know, sort of goes around the parents of our generation, I think. +WILL: Yes, definitely. What are some of the biggest hurdles you see coming up? +PRIYANKA: As a startup, there's hurdles every day. You know, there's things sort of that we're...challenges that we're facing, but really in, you know, in the current climate, I think it's about securing the right kind of funding and the amount of funding we think we need in order to get the product developed and go to market. That is a big hurdle. I have, you know, sort of some plan B set up in terms of how we could, you know, sort of test our solution in other ways and in scrappier ways. And we're kind of working on that alongside it. +But it's a difficult environment for startups right now, as you might have been aware. And especially with healthcare and wellness, in particular, it's been pretty hard over the last couple of years. The problem hasn't gone away, you know, so mental health and, you know, sort of wellness was a thing two, three years ago. And then, you know, it's all shifted to climate and sort of climate tech, which is great because that is also a problem, but equally, we haven't fixed any of this yet. And there are, I think, opportunities to do things in this area that might be missed if the funding doesn't come along. So, funding is definitely one thing. +Yeah, in terms of hurdles, if we do get the funding, it's about making sure that we get the right team together. As I said, I'm a solo founder, so that in itself is a hurdle every day as I try to sort of juggle the bootstrapping and the endless to-do list that I have with Ammi. So, I'd say, yeah, I think those are really the big things that I'm focusing on. +WILL: Yeah, I love that. And yeah, I agree. Funding is probably, yeah, that's a big hurdle. And as a parent, it's much needed just to hear those things. So, I hope it all works out and it goes well. +PRIYANKA: Yeah, no, thank you. And sort of showing that it's a need, but also, it's a commercial opportunity, right? Like, parents now in the UK, the spending that parents do in that first couple of years that their baby is born has skyrocketed. And more and more, you know, as we see, like, parents coming into sort of this journey now, are aware of the impact that poor sort of mental state can have on their children. It's not like how it was when I gave birth. Like, I think a lot of parents now are well aware, and they want to sort of be fit, not just physically, but also mentally for this journey. +So, there's a lot of trends that are in our favor. So, you know, when it comes to things like spending on services rather than goods, you know, that's going up, the awareness around mental health. Unfortunately, the incidence of poor mental health is also going up. And so, people are coming into this, and there are multiple challenges, you know, that contribute to that as well. And the risk factors, unfortunately, is another thing. +So, for example, a lot more parents are getting into parenting after having a difficult fertility journey or having experienced loss or, you know, neonatal ICU moments. So, all of that is really stressful to deal with. And then, you know, then have this child to sort of look after when you're barely healing yourself. So, I think people are recognizing the need for this, certainly, the parents are. It's about making sure that investors see that now as well as a commercial opportunity. +WILL: Yeah, I really like that. Yeah, I totally agree with that. What motivated you to start your company? Like, was it just the experience that you went through when you were raising your kids, or was there a certain thing that motivated you? Because, like you said, entrepreneurship is not easy at all. So, what motivated you to want to start your company? +PRIYANKA: You know, as I mentioned, I was, you know, sort of on that sort of corporate ladder for many years. And while I was, you know, even doing that, I think there was a certain restlessness inside of me. Am I living my most authentic life? Like, is this how I want to spend my days? You know, and I have a family now. Is this what I want to be doing when I'm not at home? And that was sort of bothering me. +And then, you know, 2020 happened, right? And I'm a statistic of the great resignation, but, like, it really was triggered by some significant life events. So, very, very early, like, almost before any of the lockdowns and start of the pandemic, in February 2020, my husband got really sick with COVID and was on a ventilator for ten days. They didn't even know really what COVID was at the time. He was one of the first, like, maybe 20, 30 patients in London in hospital. And yeah, we almost lost him. So, that was big. +And, you know, at the time, I was dealing with a high-pressure job and very young kids at home, you know, sort of at the end of my sort of mental space as well. And I took some time off and just decided then, like, I think I need to sort of pivot now. I need to, you know, life is too short. So, I resigned from my role a few months in and decided to focus on more meaningful ventures. And that's when I stumbled upon ZINC venture capital. So, ZINC venture capital is an incubator accelerator program here in the UK. And they invest in mission-based businesses, and their '21, '22 cohort was actually, as I said earlier, you know, on children and young people's mental health. +And within that, you know, while I was researching it, I think it just brought up these memories of being, like, in that early phase of parenting. And I started meeting a lot of moms who were in that phase and just realizing that these are, you know, capable women who are at their most vulnerable physically and emotionally at this time, and they're being let down. You know, these families are being let down by the system, by the environment that we live in, and, essentially, feeling like they're failing. And I recognized that in my own experiences. I had a lot of anxiety, as I, you know, sort of mentioned with my firstborn. And I think that did impact. +And, to date, we're sort of probably dealing with the impact of the way that we were as parents, you know, with him. And I just wish I had done things differently or I knew different. And that's really, like, what has motivated me. And I see, you know, these moms, like, looking for solutions and these dads as well, like, sort of more aware of these issues, but they don't have the support. So, that's really, like, where Ammi was born was, you know, during my time there. +And it was also a process of, like, finding my own personal mission, you know. And I feel deeply motivated by this, by solving the problem really. I'm not so married to the solutions. It really, for me, is about the problem and making sure that we get the right solution in people's hands. +WILL: Yeah, I really like that. I think 2020 was rough for everyone. I think it was really, really rough. It was rough for me. Like you said, it was rough for you. But I'm hoping that we're going to start seeing...because someone was telling me about trends that happen. Like, we usually go through a really rough time, but then that's usually when we get creative solutions afterwards. +And so, I'm hoping that's what we're seeing, you know, with your company and many others, which is those creative solutions from 2020. All that that happened I'm hoping that we're starting to see more and more creative solutions. So, I'm so glad that you're starting this and that you stepped out and that you're doing this because I think it's going to benefit a lot of people. +PRIYANKA: Oh, thank you. I appreciate that. It's good to hear as well [laughs]. +WILL: Yeah, definitely. So, clearly, there's a need for your solution. So, what are you hearing from the investor side, and what does that look like? +PRIYANKA: It's interesting. With things that have to do with wellness or sort of parenting, and, you know, as we now call it, like, femtech, there seems to be this perception that it's a crowded space. I can see why people say that, you know, maybe there is this sort of influx of, you know, your Instagram feed full of, like, momfluencers or messages that are coming across on parenting and things. +But if you really ask parents if they feel supported and they have access to what they need, they're still struggling. And they're still finding it difficult because every parent's journey is a little different, and they need that direct access. That's still quite hard to get. Like, you could do your research, but equally, that takes up time. +So, I think what we're doing differently at Ammi and what we're really doing here is to make that access to experts as easy, convenient, and affordable as possible, and I think there's definitely a space and market for that. Making that access sort of affordable and easy but equally, like, having that support, having the coaching support and continuity of care, which doesn't exist anymore, and not a lot of people are doing that yet. +There are a few startups that are sort of entering the space. In the U.S. I think, actually, there's been more proof of this concept working with the incredible work that Maven Clinic has done, for example. But in the UK, it's still pretty niche, and in Europe. So, I think there's a potential for a big player to come in and take up that space. And that's what I'd like investors to know is that: the commercial opportunity is not to be understated here in terms of what that is. +There's, you know, 600,000 new parents in the UK every year. And if you think about it, if even 10% of those are spending what is the average on the baby's first few years of life, which is anywhere between 8,000 to 15,000 in that year, a percentage of that does go to services. That already is a huge annual market that one could be looking at entering, sorting, and de-fragmentizing or...well, that's not the word but organizing because it is a very, very fragmented space. And there is opportunity to make that a lot easier for parents. That's kind of the message I'd like to get out there. +WILL: As a parent, I'm glad you said that because one thing I keep hearing you saying is experts, experts. I like that your platform has experts, and I can trust their info. Because I get some info from social media, but sometimes I'm like, can I trust this information? Is it real? Is it AI? Whatever it is. So, I like yours that it's like, we've added these solutions, and they're experts. So, that's, yeah, I can see how that's so beneficial. +PRIYANKA: Right. And that is what most parents tell us is: trust is such a big factor. Parenting is, like, one of the biggest things that you'll do in your life, you know, and trust is essential because you don't just want to be trying things at random or, you know, sort of sometimes you do that, but it's not ideal. And most parents will pay for that, too, you know, they will pay to talk to an expert. They will pay for that. They might not pay for the free information that comes in their way. +And this is why, like, content is one part of a strategy, but it's not core to it. It really is about creating those personalized journeys. And maybe this is another conversation as well for next time, but it really is about, like, scaling that. And that's really interesting in how we plan to do that as well. How do you scale personalized solutions? And I think that could be really interesting. +WILL: Yeah. Oh, yeah. I could definitely see if you could figure that out, wow, it opens up so many avenues for you. So, that's amazing. So, with your solutions, how have you validated that this is what your users want and this is what they need so that they're successful? +PRIYANKA: We've been doing a process of validation right from the beginning. You know, I've run ideation sessions—co-creation sessions. I've done maybe 20-plus interviews with mums and run surveys with over a hundred parents to really understand what it is they need. So, we developed, like, the version one of our prototype based on the top problems that parents told us they were having, the kind of ways in which they wanted to access help. +So that's where, you know, sort of the creative ideas around text chat and workshops and ways to make it more accessible came about, even things like having all of that on your phone because most parents will be on their phone in those early years and not so much on desktop. So, that was another thing that informed all of that. So, we did two rounds of testing, and then we did another third round as well to ensure that we were, like, tweaking our prototype to really make it exciting for parents. +And once we developed our mental health or sort of a mental health coaching platform, we also ran that on a two-week trial with a bunch of Ammi sort of community members. And the results were, like, really reassuring and almost overwhelming to some extent with, you know, some moms saying that, you know, doing some of those exercises help them sleep at night. And some others said, "Oh, wow, these sections really speak to me on values and goal setting." Some others said that "You know, it really helped me provide that moment of calm and stop my ruminating thoughts." And all of this is really encouraging to hear from people directly as they've used your content and your platform. +So, that's sort of, like, the validation we've been through. And I think it's always going to be a process. You know, even when we come out with version 1, we're going to learn what people are interacting with most. And, you know, I'm really interested to see how they react and their behaviors around the text chat particularly. So yeah, it's one of the best parts about building something is that interaction with your users and community. Like I said, it's 500-plus moms who are part of this community now and who've been informing the solution at every step of the way. +WILL: I love that you took that step to validate it. Priyanka, thank you for joining me today. +You can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. + + ChatGPT parenting support, new parents, expectant parents, motherhood transition, parenting challenges, mental health for parents, early parenting guide, maternity care, parenting community, digital parenting resources + + Host Will Larry is joined by Priyanka Mahajan, the founder of Ammi, a startup dedicated to supporting new and expectant parents with expertise, support, and community. The conversation highlights the challenges of parenting, the absence of a universal parenting manual, and how Ammi seeks to provide a personalized co-pilot for parents navigating the early stages of parenthood. Priyanka shares her journey from a career in strategy consulting and corporate roles across different countries to founding Ammi, driven by personal experiences and the desire to make a meaningful impact on parents' lives.

+ +

Priyanka discusses the core challenges she faced as a parent, such as dealing with the loss of control, the transition to motherhood, and the importance of acknowledging and navigating the mental and emotional shifts that come with it. She introduces the concept of "matrescence," likening it to adolescence, as a significant, yet underdiscussed, transition into parenthood. Priyanka's personal struggles with anxiety and the impact on her parenting led to the realization of the need for support and resources for parents, particularly in the areas of mental health and emotional well-being.

+ +

Ammi's mission is to fill the gaps in the current parenting support ecosystem by providing accessible expert advice and resources. Priyanka emphasizes the importance of mental health, the creation of a supportive community, and the development of a digital platform tailored to modern parents' needs. Finally, she outlines the challenges and opportunities ahead, including fundraising, product development, and establishing trust with parents.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Priyanka Mahajan, Founder of Ammi, a startup that provides expertise, support, and community to new and expectant parents. Priyanka, thank you for joining me today.

+ +

PRIYANKA: Will, thanks for having me. It's great to be here.

+ +

WILL: Yeah. I'm so excited to talk to you about parenting. Anytime I get to talk about parenting, I light up, so I can't wait to talk to you about it, pick your brain, and just hear any advice you have for me.

+ +

PRIYANKA: [laughs] That's great. It's always nice to talk to people who get the challenges, so very happy to dive into it.

+ +

WILL: Yeah, definitely. Me and my wife we always talk about we wish kids came with a manual because you just don't know what you're going to get. Out of my three kids, they're all not even close to being similar in any way.

+ +

PRIYANKA: No, that's totally right. You know, this manual that most people or most parents wish for after their kids are born doesn't quite exist. And it's also deeply personal, and that's exactly what you mentioned about your kids being different. But each parenting experience and, you know, giving birth is different. Each birth is different. Your body is different. So, all of that is quite deeply personal. And that's essentially what we want to do with Ammi is be able to provide this co-pilot to expectant and new parents to guide and help them through that early phase.

+ +

WILL: Yeah, oh, I can't wait. Before we dive in too deep, can you tell us a little bit about who you are, your background, and kind of how you got to this place?

+ +

PRIYANKA: So, first thing, I suppose, is I am Indian. I was born and raised in India, and I've lived in about four countries, including the U.S., and now live in London. I started my career in the strategy consulting area and then moved into internal strategy roles for telecoms and tech industry. And I had my children through that period of working for big corporates and essentially, you know, was busy climbing the corporate ladder or moved into different roles.

+ +

I have headed teams in marketing, in commercial, in other areas like operations. And eventually ended up being a director of strategy for the EMEA region for this large American telecoms company. And it was then that COVID struck and essentially that's basically where there were big, large life events, which I'm happy to get into later. But essentially, I resigned from my role and decided to focus on more meaningful ventures. So, here I am [laughs].

+ +

WILL: Yeah. So, were there any challenges having a career and having children? There were challenges.

+ +

PRIYANKA: That's right.

+ +

WILL: What were some of the challenges that you faced?

+ +

PRIYANKA: I had my kids really close together. I had a very difficult birth the first time around. I had a very easy pregnancy but a difficult birth. And especially for parents and, you know, women who are mothers, who are giving birth and previously have had this illusion of control, and, you know, being organized and in control and being on top of everything to suddenly not having anything in your control because that's what kids are like.

+ +

And not having that acknowledged and, you know, you still expect to do everything in a certain way, and you want to sort of do everything right. And that's just not how parenting is. There's no one right way, and it's okay to make mistakes, but also, equally, it's important to not know that you're failing. And I think that was a challenge that I had equally.

+ +

You know, I went back into work part-time. And here in the UK, I had a fairly generous maternity leave policy, which was great. But also, having to sort of think about putting my career on a bit of a back burner while my kids took priority was a transition. And just making that transition mentally, emotionally, physically in your life and making space for this new world is quite challenging as, you know, you're sort of grieving the life you had. But you're also embracing what's here and being surprised by it and figuring out who you are.

+ +

And that the term, actually, is known as matrescence, right? So, it's this process as we have adolescence. It's becoming a parent. It's, you know, its own transition. And I don't think that's been talked about enough, certainly not when I had my kids. So, I wasn't actually aware that that's what I was going through. I just kept thinking that I'm failing. And I think those memories and that experience was deeply embedded in my sort of process. And I went on to, you know, sort of do other things and go back into my career. And I never really dealt with the emotions that I felt at that stage of my early parenting journey.

+ +

And it really all came to light sort of when Ammi was born and hatched in the incubator that I did after I resigned from my corporate role at ZINC, where, you know, the focus was on children and young people's mental health. And in that, I sort of, like, started to research the space and go like, where do you actually start with children and young people? And you start with the parents at that very early stage.

+ +

So, that's sort of, like, what led me to almost kind of revisit my own experiences in that phase and think, you know, there was something there. And if we had probably done things differently, maybe the outcomes might have been different for our family, the way that we did things or the way that we dealt with each other in those early years.

+ +

Because the other thing I learned as well while I was doing my research in that space, which I didn't know at the time when I had my kids, is that children have their emotional development take place pretty much by the time from zero to three years of age. So, it's a very significant period of sort of secure attachment, as we call it, and things. So, that's, again, a lot of concepts that I wasn't familiar with, and I wish that I was kinder to myself. And that's basically what I want to do for the community that I'm supporting through Ammi.

+ +

WILL: That is such a good point because my oldest son he has a lot of tendecies that are like mine. So, we're a lot alike, and I find that mental health aspect of that, like, how can I help him the most? How can I help him to where he doesn't have the same failures I have? Like, it's not easy being a parent because it's like, do I step in? Do I not? Do I let him fail? Do I not let him fail?

+ +

So, like, and like you said, I think parenting is probably one of the most lonely things you can go through at times, depending on who's around you, if you have family around you, friends that have children, or not. So, I'm so glad that you said that you're diving into that mental health aspect also.

+ +

PRIYANKA: Yeah, that's a key pillar of what we do and what we're building essentially at Ammi. So, the mental health aspect is one that isn't really talked about, and there's a lot of stigma and shame associated with that, in that early stage especially. And the figures itself are astounding, you know, in the UK itself, it's 1 in 3 mothers experience perinatal mental health issues. In the U.S., I think it's 1 in 5. And 1 in 10 dads experience mental health issues. And there is a certain shame in addressing that. You're meant to be happy, and you're meant to be blessed. And which is true, you are blessed, and, you know, there are moments of happiness. But this is a massive transition that you're going through.

+ +

And it's an interesting word you used as well: lonely. So, in our research and interviews with the countless scores of, you know, tens of moms that we have interviewed, the most common word was isolation. It's exactly that. Like, it can feel like a very isolating experience without the village or the community that kids were meant to be raised under and parents were meant to be supported through that. But that is no longer the case in the way that we live today. And that's where there's an opportunity to provide that to parents in a way that works with our modern lives as well.

+ +

So, for example, what we're doing at Ammi with the mental health particularly is we have developed an evidence-based solution based on acceptance and commitment therapy, which is essentially an incredible sort of modality of therapy that addresses life changes in particular. It helps you figure out your values and your parenting values and helps you set goals and actions in line with those values. So, you feel like you have meaning even though your life is changing, and it still feels significant. And now, of course, you're in charge of a child. So, how do you ensure that you're not losing yourself but equally you're bringing your own values to your parenting? I just found it fascinating.

+ +

And we're doing this in a digital way. We're doing this in a way that works for the modern parent. So, it's bite-sized. It's on your phone. You can interact with it in the middle of the night when you're feeding the baby, or you're, you know, sort of up at the odd hours of the morning with your child. That's essentially, like, what we're doing with that particular mental health piece.

+ +

WILL: That is so good because I think even you said the values, like, I think we forget about that easily. And that is everything we do, like, the way we talk to our kids, the way we're raising them, the way we discipline them, what school they're going to. But I think so many times we run out of mental headspace to even talk about those things and to write them down. So, oh, that's so good that you go through that, and you help them discover what their values are because I think sometimes, as parents, you can lose that. Even if you had the values before you had kids, it's easy to lose those values and to remember why you're doing it.

+ +

PRIYANKA: That's right. And, you know, in some cases, you know, you forget, and you don't even know really what your values might be, right? Like, you're just kind of doing things because you think you should. And should is a dangerous word as well because it's sort of, how do you uncover what it is that you really want to do as well? And what's authentic to you as an individual and as a parent?

+ +

So, for example, I'll give you one, like, structure, right? Like, I, as a parent, can get so hung up on structure as a value. I forget about connection. And, actually, if I had to, like, sort of rank these, you know, connection would be higher on my list, personally. And it's like, why am I not acting on that? And so, what values essentially do is give you this compass in terms of, like, deciding what course of action to take and how you prioritize things.

+ +

And, equally, it's also important to note that, you know, values do shift and change. So, we say in this world that it's imagine that you're looking at a globe, and a globe sort of, like, spins. And there may be some values that are topical now, but others that come to fore. So, you've got to, like, hold them lightly as well and acknowledge that they do shift. And all of this may seem sort of a bit indulgent to talk and think about, but, actually, it's really relevant in your day-to-day and also in the way that you live, you work, you parent. It's all very relevant. And I think it's important to bring light to that in the parenting context as well.

+ +

WILL: That's really, really good. So, I wanted to kind of dive deeper into those pillars you're talking about. I know you said mental health was one. What are some of the other pillars that you cover?

+ +

PRIYANKA: You know, the other thing that I've lived through and I've discovered in my, you know, research with my community and with my parents is it's one thing to sort of work on yourself, right? But if the system around you is a bit broken, it's not all in your control. So, what we want to do as well is, like, fill some of those gaps that currently exist in the system.

+ +

So, for example, you know, here in the UK, since COVID especially, and for a few years before then, you know, we rely on the public healthcare system. And there have been significant challenges with funding there, which means that a lot of the support that was available to birthing parents, to birthing people are just not available anymore. There's no continuity of care, the kind of support you could expect in terms of checks and, you know, seeing the same person, for example, seeing the same midwife. That just doesn't exist anymore.

+ +

So, what you end up having is a lot of parents who are trying to do their best, but essentially scrambling around looking for solutions, whether that's, like, for sleep, or breastfeeding, or nutrition and taking care of their baby. And that is what essentially results in those feelings of failure.

+ +

So, what we want to do at Ammi is actually provide that practical expertise as well in the most accessible way. For example, here you could go private. You could see these experts privately, but that's really expensive. And there's nothing really available in the middle, I mean, apart from, like, the free Instagram reels and things. So, what we want to do is be able to provide, again, convenient formats where you can directly access these experts. And what I mean by that is, and what we already do here at Ammi, is we run online workshops with these experts, and these are currently actually free for parents to join.

+ +

So, we rope in experts who are equally passionate about this. So, they could be experts in pediatrics, or they could be experts in physical and maternal health and wellness, but also infant health and wellness. And they run these sessions for us, and parents can join and essentially interacting live. It happens usually after bedtime, so when parents can attend. And that's one format.

+ +

What we also want to build within our digital solution is a way for parents to access these experts on chat, text messaging, as well as book appointments with them, but, like, they may be shorter form appointments, so they're not as expensive. And it's virtual, which, again, cuts out the cost of actually having to see the expert in an office or in a space that is charged, so that helps with some of the cost. Equally, it helps to have experts who can do this on their downtime on chat format. So, that also helps with the cost.

+ +

So, we're trying to experiment with these different formats that also work from a parent standpoint of convenience. So, you're not taking time off work to see these experts. So, you're not doing that in, like, daytime hours or when your baby's sleeping. So, it's really about convenience and accessibility.

+ +

WILL: That sounds really good. I like the access to the people that know what they're talking about, especially late at night and things like that. That sounds so amazing because there's so many times that, like, I remember whenever, Cruz, he's my oldest, he just wasn't feeding with Katie. And we were like, we don't know why. And the first couple of weeks, I think we went into a doctor's office, like, three or four times just to make sure that he got back up to his birth weight. And it was scary. It was like, are we doing anything wrong? Like, what do we have to do to get him to this place and stuff like that?

+ +

So, I think sometimes it's just like, "Hey, you're doing the right thing." Like we had one pediatrician...we moved from North Carolina to Florida, and we kind of miss our old pediatrician. Because when we walked in, she was just like, "Hey, he's healthy. I could tell he's healthy, and you're doing all the things right." It was almost like a weight lifted off our backs just to hear like, "Hey. You're doing okay." So, that's good to hear that you're providing that to parents and stuff. You say you're based in London.

+ +

PRIYANKA: Right.

+ +

WILL: And I'm just being honest; I have no idea what the medical situation looks like there. Can you explain what that looks like? Because I know what it looks like in the U.S. But I don't want to be naive and say, "Oh, it's the same." What does it look like when you say someone can't have access to a private provider?

+ +

PRIYANKA: So, it's not that they can't have access. So, historically, in a lot of countries in Europe and here in the UK, we have what is called the National Healthcare System or the NHS. And, essentially, what that means is that your healthcare is covered by the state, which is incredible, actually that, you know, you don't really need to spend on private insurance or private healthcare.

+ +

So, for most parents, including myself, I gave birth both times through the NHS. What that means is that, you know, you sort of, like, you get into the system. You go to your GP. You don't actually get a pediatrician, which is also something that I wasn't used to in India, but there's no pediatricians. And they have a system that you go through. So, you know, you get assigned a hospital, or you can choose a hospital that's local, but generally, you get assigned to a hospital. And you sort of give birth there under their condition.

+ +

So, there's not a lot of agency and that, I guess, is the key word because you are under the healthcare system. And essentially, that is the majority. The overwhelming majority of people give birth that way in the UK. I think 12% of the UK has private insurance cover. But equally, even if you have private insurance cover, which means that you can choose your medical care or you can, you know, sort of reimburse, get reimbursed, and things, a lot of them don't actually cover giving birth because it's not a medical condition. So, you have to pay for that privately, and it does cost quite a significant sum of money if you want to go private.

+ +

And there's just a few hospitals, actually, in London. There's not that many hospitals outside of London that do this either. So, it's not a very accessible option for most people because it's expensive, and there just aren't enough places that do that. So, in terms of that continuity of care, you have your GP, but, you know, the GP, essentially, has 10 minutes per appointment. So, you don't get a lot of time with your healthcare provider.

+ +

And equally, when you have your midwife appointments to the NHS now, you don't see the same person, so, you know, through your scan. So, it's generally someone different. You might get lucky and see the same person. So, it's quite intimidating, I have to say, you know, you don't know really, like, what you can, cannot ask for. It's not very clear what your rights are, even though, you know, they do try their best. But because of the funding shortages now and the way that the system is going, people really are struggling to access care to the level.

+ +

I mean, even, you know, the midwives are leaving the NHS. There's 29 out of 30 midwives leave the NHS after two years of training, which is shocking given, you know, the investment that they make in time. So, it is getting pretty dire, and people's birth stories are just getting quite horrific. And it's become commonplace. It's not unusual anymore, where it used to be quite unusual.

+ +

You know, there's this perfect storm building right now here in the UK of people who are struggling to get the care they need. And paternity services, in particular, are also suffering quite a lot. And there's this dearth of services, right? And people are starting, like, there are a lot of, like, sort of, like, now smaller companies coming up, trying to, like, fill in this gap through employee benefits, which is one of the routes that we plan to take to market as well.

+ +

But also, birth coaches is, you have the birthing coaches and doulas. And this is a very small market here in the UK, but it's growing in, like, triple digits year on year. So, it's really interesting to see the private world is stepping up or is trying to step up to the challenges of what the public system isn't able to do anymore. Does that help, or [chuckles] does it sort of give you some context?

+ +

WILL: Yes, that helps tremendously because here, where I'm at, it's mostly employee benefits, and it's more private. We still have so many issues because I was thinking what you're doing. I was like, oh, that's so helpful, even with what we're dealing with, but it sounds like even next level.

+ +

Like, I can't imagine taking my kid to the doctor and seeing a different doctor every single time because sometimes that's part of the helpfulness is they're like, "Oh, we know your kid. We know what they're going through. And, actually, I probably treated them the last time they were in here, so I kind of know." Because even if you have notes, it's tough to understand exactly what you saw. Yeah, I could see the benefits of what you're doing. So, that's amazing.

+ +

PRIYANKA: Yeah, that's right. And equally, like, with the employee benefits now, this is one of the benefits. The top five benefits that employees want from their employers is more family support and more time around that. And we're also seeing in terms of, you know, employee retention, right? And keeping the gender pay gap at the minimum. It's about retaining also your, you know, female employees, especially mothers who tend to leave the workforce after having children, even here in the UK. I know it's actually a lot worse in the U.S., is my understanding.

+ +

But even here in the UK where you do get more benefits in terms of maternity leave, it's still the cost of childcare. And there are so many other issues about just not having that support system that completely sort of overwhelm the families for one of them to have to drop their career, which is unfortunate. So, I think there is definitely a play here for employers to step up here in the UK and in Europe to this challenge of retaining their employees through benefits such as this.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

WILL: What are some other ideas that you have? What does success look like in the next six months, five years for you? Where are y'all going?

+ +

PRIYANKA: Well, in the next six months, I think it's really about getting the product to market, like, getting our MVP and product out there. You know, we're doing things in a very scrappy way at the moment. I am, for all practical purposes, a solo founder, and I've been bootstrapping. What we have developed, you know, with my fractional team of clinicians and my CTO is we have a really high-spec figma prototype of what our solution would look like. We have our content ready and the mental health, the evidence-based mental health program ready.

+ +

It's now about getting that on a platform, and that is going to require some funding. So, I'm in the process of fundraising. So, ideally, in six months, we would have raised enough money to get that MVP out and to get this product in the hands of our customers, our customers being potentially employers. But also, you know, within the Ammi community, I've also been building a community as I've been running these online sessions and creating that side of content as well on the practical expertise side.

+ +

And we've got about 500-plus parents around London who have attended our workshops, and most of them are part of this community. And, you know, they're the ones that we've sort of tapped on for our testing. For also the content that we developed, we handed it over to them and, you know, we ran a trial and with some great results. So, that's basically the kind of work that we've done so far over the last year. And, really, in the next six months, it's about getting the product out, raising some money, and, yeah, hopefully, being revenue-generating. So [laughs], it's a lot to look forward to, a lot to do.

+ +

WILL: It sounds like that's that next heel, the next step, so...and it sounds fun. You help parents with their core values. What are some of the core values that you use and that you have that you make decisions through every day?

+ +

PRIYANKA: It's about authenticity. That's the guiding principle. It's about being authentic to our mission, being authentic to what the customer wants, you know, first and foremost, and authentic to what my vision for Ammi is, which is to be that co-pilot in those early years. And how that sort of helps me is even when I look at funding, and I look at the type of funding or who we, you know, want money from, I know that, you know, sort of, we can't really dictate that at this point. But I really don't want there to be a risk of mission drift from what we're trying to do here. I've lived that life before where I've done things to just sort of tick the boxes.

+ +

And I do genuinely think that there is a commercial opportunity here as well within the mission that we're trying to achieve because, you know, from employers to parents themselves, they're spending money on this now, and, you know, the tide is turning. So, for me, authenticity is number one. And, generally, like, you know, when I am faced with any decisions, whether that's a product-based decision, I'm like, right, like, what's more important to our community? What do they really want?

+ +

So, it's all about going back there and seeing, like, what is going to give them most value? It's about understanding when we look at the development or getting team members on board, it's, you know, who believes in the mission? So, that generally is what guides me in my day-to-day decision-making process.

+ +

WILL: Yeah, I really like that because I feel like, especially with social media, there's a lack of authenticity sometimes. Sometimes, I feel like society wants you to be this superhero as parents. And sometimes it's like, I think I have some of my best moments with my kids and some of my worst times with my kids. Just, like, I think sometimes just being honest about this is where you're at as a parent. You're doing okay. Maybe you need to tweak this, this, and this, but I think that's a good thing to go by. So, I really like that you said that.

+ +

PRIYANKA: Well, there's lots of ways to make money. Entrepreneurship that might be one of the things you do to make money, right? But it's not the easiest way. You know, I gave up my corporate career for a good reason, and I want to remember that. It was to sort of achieve big things but being authentic. So, that's really, like, where we are at.

+ +

WILL: I love it. Love it. I usually ask this question around careers, but I'm going to ask it for parenting. So, if you can go back in time and give yourself advice on your parenting, what advice would you give?

+ +

PRIYANKA: I would just say chill out [laughs]. You know, I think I was so hard on myself, right? So, for example, like, you know, when my son was born, my firstborn, I was so hell-bent on breastfeeding and, like, every bottle I had to give him a bottle day three because, you know, like you, like, my son as well he lost a lot of his weight, and we got worried. And he wasn't feeding. I didn't have a supply. So, it was so hard, and I felt like I failed. Every time he didn't sleep through the night, it felt like I failed.

+ +

So, I sort of took responsibility for all of it. Like, you know, this is, you know, that I'm failing this next project. But I wish I could just, you know, sort of go back and be like, this is all part of the journey. And this is a, you know, sort of a small person that you're trying to raise, and they have different rhythms, and it doesn't go by the book. So, those are some of the things I would tell myself is just to be kinder.

+ +

And, you know, actually, that's another thing that we do at Ammi is, like, just that self-compassion in our program about, like, just being easy on yourself for those years. I had to sort of come back and, you know, as you said, bounce back. And, again, all of that there's just incredible amounts of pressure on parents. Yeah, I think I would just tell myself to be kinder and be patient through all of that and things will work out.

+ +

WILL: I appreciate you saying that because I needed to hear that, to be honest with you. [laughter] Yeah. Just, I think, my kids are 4, 3, and almost 2, so, like, 22 months. So, "It's going to be okay, and chill out" is really good advice for me to hear at this time. So, I appreciate you saying that.

+ +

PRIYANKA: Yeah. And it will be, you know, I mean, I know it's hard. Like, it's as they say, the days are, you know, long, and the years are short. But when you're in it and when you haven't slept in a week [laughs], it can feel like it's just dragging on forever [laughter]. And that's one of the hardest challenges, right? Sleep deprivation. So, sleep workshops are the most popular, as you would expect. You know, we get sleep experts to come in and talk about it. And, generally, you know, what's really interesting is, like, through a lot of these workshops, what they all end up really saying is that everything is normal [laughs].

+ +

So, it's not like one sort of thing is normal. And just having an expert say that to you and say that to our parents who join these calls is just incredibly relieving for them that they're not, you know, in some race and competition to see whose kid has slept through the night or, like, what's, you know, what I'm doing wrong, whose kid is eating the most variety of fruit and veg, you know, that's not what it's about. It's all normal. And they just go away and sleep well that night, right? Like, after a workshop because they're like, this is great. I'm doing it okay [laughter].

+ +

WILL: Well, once again, that's good to hear because, like, last night, I think I got five hours of sleep because of my son.

+ +

PRIYANKA: Ooh.

+ +

WILL: Thank you for saying even that because, like, you question yourself a lot. Like, I know I do. I question myself a lot. Am I doing the right thing? Is this what I'm supposed to be doing? So yeah, that's really good to hear.

+ +

PRIYANKA: Yeah, it's a common ailment that [laughs], you know, sort of goes around the parents of our generation, I think.

+ +

WILL: Yes, definitely. What are some of the biggest hurdles you see coming up?

+ +

PRIYANKA: As a startup, there's hurdles every day. You know, there's things sort of that we're...challenges that we're facing, but really in, you know, in the current climate, I think it's about securing the right kind of funding and the amount of funding we think we need in order to get the product developed and go to market. That is a big hurdle. I have, you know, sort of some plan B set up in terms of how we could, you know, sort of test our solution in other ways and in scrappier ways. And we're kind of working on that alongside it.

+ +

But it's a difficult environment for startups right now, as you might have been aware. And especially with healthcare and wellness, in particular, it's been pretty hard over the last couple of years. The problem hasn't gone away, you know, so mental health and, you know, sort of wellness was a thing two, three years ago. And then, you know, it's all shifted to climate and sort of climate tech, which is great because that is also a problem, but equally, we haven't fixed any of this yet. And there are, I think, opportunities to do things in this area that might be missed if the funding doesn't come along. So, funding is definitely one thing.

+ +

Yeah, in terms of hurdles, if we do get the funding, it's about making sure that we get the right team together. As I said, I'm a solo founder, so that in itself is a hurdle every day as I try to sort of juggle the bootstrapping and the endless to-do list that I have with Ammi. So, I'd say, yeah, I think those are really the big things that I'm focusing on.

+ +

WILL: Yeah, I love that. And yeah, I agree. Funding is probably, yeah, that's a big hurdle. And as a parent, it's much needed just to hear those things. So, I hope it all works out and it goes well.

+ +

PRIYANKA: Yeah, no, thank you. And sort of showing that it's a need, but also, it's a commercial opportunity, right? Like, parents now in the UK, the spending that parents do in that first couple of years that their baby is born has skyrocketed. And more and more, you know, as we see, like, parents coming into sort of this journey now, are aware of the impact that poor sort of mental state can have on their children. It's not like how it was when I gave birth. Like, I think a lot of parents now are well aware, and they want to sort of be fit, not just physically, but also mentally for this journey.

+ +

So, there's a lot of trends that are in our favor. So, you know, when it comes to things like spending on services rather than goods, you know, that's going up, the awareness around mental health. Unfortunately, the incidence of poor mental health is also going up. And so, people are coming into this, and there are multiple challenges, you know, that contribute to that as well. And the risk factors, unfortunately, is another thing.

+ +

So, for example, a lot more parents are getting into parenting after having a difficult fertility journey or having experienced loss or, you know, neonatal ICU moments. So, all of that is really stressful to deal with. And then, you know, then have this child to sort of look after when you're barely healing yourself. So, I think people are recognizing the need for this, certainly, the parents are. It's about making sure that investors see that now as well as a commercial opportunity.

+ +

WILL: Yeah, I really like that. Yeah, I totally agree with that. What motivated you to start your company? Like, was it just the experience that you went through when you were raising your kids, or was there a certain thing that motivated you? Because, like you said, entrepreneurship is not easy at all. So, what motivated you to want to start your company?

+ +

PRIYANKA: You know, as I mentioned, I was, you know, sort of on that sort of corporate ladder for many years. And while I was, you know, even doing that, I think there was a certain restlessness inside of me. Am I living my most authentic life? Like, is this how I want to spend my days? You know, and I have a family now. Is this what I want to be doing when I'm not at home? And that was sort of bothering me.

+ +

And then, you know, 2020 happened, right? And I'm a statistic of the great resignation, but, like, it really was triggered by some significant life events. So, very, very early, like, almost before any of the lockdowns and start of the pandemic, in February 2020, my husband got really sick with COVID and was on a ventilator for ten days. They didn't even know really what COVID was at the time. He was one of the first, like, maybe 20, 30 patients in London in hospital. And yeah, we almost lost him. So, that was big.

+ +

And, you know, at the time, I was dealing with a high-pressure job and very young kids at home, you know, sort of at the end of my sort of mental space as well. And I took some time off and just decided then, like, I think I need to sort of pivot now. I need to, you know, life is too short. So, I resigned from my role a few months in and decided to focus on more meaningful ventures. And that's when I stumbled upon ZINC venture capital. So, ZINC venture capital is an incubator accelerator program here in the UK. And they invest in mission-based businesses, and their '21, '22 cohort was actually, as I said earlier, you know, on children and young people's mental health.

+ +

And within that, you know, while I was researching it, I think it just brought up these memories of being, like, in that early phase of parenting. And I started meeting a lot of moms who were in that phase and just realizing that these are, you know, capable women who are at their most vulnerable physically and emotionally at this time, and they're being let down. You know, these families are being let down by the system, by the environment that we live in, and, essentially, feeling like they're failing. And I recognized that in my own experiences. I had a lot of anxiety, as I, you know, sort of mentioned with my firstborn. And I think that did impact.

+ +

And, to date, we're sort of probably dealing with the impact of the way that we were as parents, you know, with him. And I just wish I had done things differently or I knew different. And that's really, like, what has motivated me. And I see, you know, these moms, like, looking for solutions and these dads as well, like, sort of more aware of these issues, but they don't have the support. So, that's really, like, where Ammi was born was, you know, during my time there.

+ +

And it was also a process of, like, finding my own personal mission, you know. And I feel deeply motivated by this, by solving the problem really. I'm not so married to the solutions. It really, for me, is about the problem and making sure that we get the right solution in people's hands.

+ +

WILL: Yeah, I really like that. I think 2020 was rough for everyone. I think it was really, really rough. It was rough for me. Like you said, it was rough for you. But I'm hoping that we're going to start seeing...because someone was telling me about trends that happen. Like, we usually go through a really rough time, but then that's usually when we get creative solutions afterwards.

+ +

And so, I'm hoping that's what we're seeing, you know, with your company and many others, which is those creative solutions from 2020. All that that happened I'm hoping that we're starting to see more and more creative solutions. So, I'm so glad that you're starting this and that you stepped out and that you're doing this because I think it's going to benefit a lot of people.

+ +

PRIYANKA: Oh, thank you. I appreciate that. It's good to hear as well [laughs].

+ +

WILL: Yeah, definitely. So, clearly, there's a need for your solution. So, what are you hearing from the investor side, and what does that look like?

+ +

PRIYANKA: It's interesting. With things that have to do with wellness or sort of parenting, and, you know, as we now call it, like, femtech, there seems to be this perception that it's a crowded space. I can see why people say that, you know, maybe there is this sort of influx of, you know, your Instagram feed full of, like, momfluencers or messages that are coming across on parenting and things.

+ +

But if you really ask parents if they feel supported and they have access to what they need, they're still struggling. And they're still finding it difficult because every parent's journey is a little different, and they need that direct access. That's still quite hard to get. Like, you could do your research, but equally, that takes up time.

+ +

So, I think what we're doing differently at Ammi and what we're really doing here is to make that access to experts as easy, convenient, and affordable as possible, and I think there's definitely a space and market for that. Making that access sort of affordable and easy but equally, like, having that support, having the coaching support and continuity of care, which doesn't exist anymore, and not a lot of people are doing that yet.

+ +

There are a few startups that are sort of entering the space. In the U.S. I think, actually, there's been more proof of this concept working with the incredible work that Maven Clinic has done, for example. But in the UK, it's still pretty niche, and in Europe. So, I think there's a potential for a big player to come in and take up that space. And that's what I'd like investors to know is that: the commercial opportunity is not to be understated here in terms of what that is.

+ +

There's, you know, 600,000 new parents in the UK every year. And if you think about it, if even 10% of those are spending what is the average on the baby's first few years of life, which is anywhere between 8,000 to 15,000 in that year, a percentage of that does go to services. That already is a huge annual market that one could be looking at entering, sorting, and de-fragmentizing or...well, that's not the word but organizing because it is a very, very fragmented space. And there is opportunity to make that a lot easier for parents. That's kind of the message I'd like to get out there.

+ +

WILL: As a parent, I'm glad you said that because one thing I keep hearing you saying is experts, experts. I like that your platform has experts, and I can trust their info. Because I get some info from social media, but sometimes I'm like, can I trust this information? Is it real? Is it AI? Whatever it is. So, I like yours that it's like, we've added these solutions, and they're experts. So, that's, yeah, I can see how that's so beneficial.

+ +

PRIYANKA: Right. And that is what most parents tell us is: trust is such a big factor. Parenting is, like, one of the biggest things that you'll do in your life, you know, and trust is essential because you don't just want to be trying things at random or, you know, sort of sometimes you do that, but it's not ideal. And most parents will pay for that, too, you know, they will pay to talk to an expert. They will pay for that. They might not pay for the free information that comes in their way.

+ +

And this is why, like, content is one part of a strategy, but it's not core to it. It really is about creating those personalized journeys. And maybe this is another conversation as well for next time, but it really is about, like, scaling that. And that's really interesting in how we plan to do that as well. How do you scale personalized solutions? And I think that could be really interesting.

+ +

WILL: Yeah. Oh, yeah. I could definitely see if you could figure that out, wow, it opens up so many avenues for you. So, that's amazing. So, with your solutions, how have you validated that this is what your users want and this is what they need so that they're successful?

+ +

PRIYANKA: We've been doing a process of validation right from the beginning. You know, I've run ideation sessions—co-creation sessions. I've done maybe 20-plus interviews with mums and run surveys with over a hundred parents to really understand what it is they need. So, we developed, like, the version one of our prototype based on the top problems that parents told us they were having, the kind of ways in which they wanted to access help.

+ +

So that's where, you know, sort of the creative ideas around text chat and workshops and ways to make it more accessible came about, even things like having all of that on your phone because most parents will be on their phone in those early years and not so much on desktop. So, that was another thing that informed all of that. So, we did two rounds of testing, and then we did another third round as well to ensure that we were, like, tweaking our prototype to really make it exciting for parents.

+ +

And once we developed our mental health or sort of a mental health coaching platform, we also ran that on a two-week trial with a bunch of Ammi sort of community members. And the results were, like, really reassuring and almost overwhelming to some extent with, you know, some moms saying that, you know, doing some of those exercises help them sleep at night. And some others said, "Oh, wow, these sections really speak to me on values and goal setting." Some others said that "You know, it really helped me provide that moment of calm and stop my ruminating thoughts." And all of this is really encouraging to hear from people directly as they've used your content and your platform.

+ +

So, that's sort of, like, the validation we've been through. And I think it's always going to be a process. You know, even when we come out with version 1, we're going to learn what people are interacting with most. And, you know, I'm really interested to see how they react and their behaviors around the text chat particularly. So yeah, it's one of the best parts about building something is that interaction with your users and community. Like I said, it's 500-plus moms who are part of this community now and who've been informing the solution at every step of the way.

+ +

WILL: I love that you took that step to validate it. Priyanka, thank you for joining me today.

+ +

You can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Will Larry is joined by Priyanka Mahajan, the founder of Ammi, a startup dedicated to supporting new and expectant parents with expertise, support, and community. The conversation highlights the challenges of parenting, the absence of a universal parenting manual, and how Ammi seeks to provide a personalized co-pilot for parents navigating the early stages of parenthood. Priyanka shares her journey from a career in strategy consulting and corporate roles across different countries to founding Ammi, driven by personal experiences and the desire to make a meaningful impact on parents' lives.

+ +

Priyanka discusses the core challenges she faced as a parent, such as dealing with the loss of control, the transition to motherhood, and the importance of acknowledging and navigating the mental and emotional shifts that come with it. She introduces the concept of "matrescence," likening it to adolescence, as a significant, yet underdiscussed, transition into parenthood. Priyanka's personal struggles with anxiety and the impact on her parenting led to the realization of the need for support and resources for parents, particularly in the areas of mental health and emotional well-being.

+ +

Ammi's mission is to fill the gaps in the current parenting support ecosystem by providing accessible expert advice and resources. Priyanka emphasizes the importance of mental health, the creation of a supportive community, and the development of a digital platform tailored to modern parents' needs. Finally, she outlines the challenges and opportunities ahead, including fundraising, product development, and establishing trust with parents.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Priyanka Mahajan, Founder of Ammi, a startup that provides expertise, support, and community to new and expectant parents. Priyanka, thank you for joining me today.

+ +

PRIYANKA: Will, thanks for having me. It's great to be here.

+ +

WILL: Yeah. I'm so excited to talk to you about parenting. Anytime I get to talk about parenting, I light up, so I can't wait to talk to you about it, pick your brain, and just hear any advice you have for me.

+ +

PRIYANKA: [laughs] That's great. It's always nice to talk to people who get the challenges, so very happy to dive into it.

+ +

WILL: Yeah, definitely. Me and my wife we always talk about we wish kids came with a manual because you just don't know what you're going to get. Out of my three kids, they're all not even close to being similar in any way.

+ +

PRIYANKA: No, that's totally right. You know, this manual that most people or most parents wish for after their kids are born doesn't quite exist. And it's also deeply personal, and that's exactly what you mentioned about your kids being different. But each parenting experience and, you know, giving birth is different. Each birth is different. Your body is different. So, all of that is quite deeply personal. And that's essentially what we want to do with Ammi is be able to provide this co-pilot to expectant and new parents to guide and help them through that early phase.

+ +

WILL: Yeah, oh, I can't wait. Before we dive in too deep, can you tell us a little bit about who you are, your background, and kind of how you got to this place?

+ +

PRIYANKA: So, first thing, I suppose, is I am Indian. I was born and raised in India, and I've lived in about four countries, including the U.S., and now live in London. I started my career in the strategy consulting area and then moved into internal strategy roles for telecoms and tech industry. And I had my children through that period of working for big corporates and essentially, you know, was busy climbing the corporate ladder or moved into different roles.

+ +

I have headed teams in marketing, in commercial, in other areas like operations. And eventually ended up being a director of strategy for the EMEA region for this large American telecoms company. And it was then that COVID struck and essentially that's basically where there were big, large life events, which I'm happy to get into later. But essentially, I resigned from my role and decided to focus on more meaningful ventures. So, here I am [laughs].

+ +

WILL: Yeah. So, were there any challenges having a career and having children? There were challenges.

+ +

PRIYANKA: That's right.

+ +

WILL: What were some of the challenges that you faced?

+ +

PRIYANKA: I had my kids really close together. I had a very difficult birth the first time around. I had a very easy pregnancy but a difficult birth. And especially for parents and, you know, women who are mothers, who are giving birth and previously have had this illusion of control, and, you know, being organized and in control and being on top of everything to suddenly not having anything in your control because that's what kids are like.

+ +

And not having that acknowledged and, you know, you still expect to do everything in a certain way, and you want to sort of do everything right. And that's just not how parenting is. There's no one right way, and it's okay to make mistakes, but also, equally, it's important to not know that you're failing. And I think that was a challenge that I had equally.

+ +

You know, I went back into work part-time. And here in the UK, I had a fairly generous maternity leave policy, which was great. But also, having to sort of think about putting my career on a bit of a back burner while my kids took priority was a transition. And just making that transition mentally, emotionally, physically in your life and making space for this new world is quite challenging as, you know, you're sort of grieving the life you had. But you're also embracing what's here and being surprised by it and figuring out who you are.

+ +

And that the term, actually, is known as matrescence, right? So, it's this process as we have adolescence. It's becoming a parent. It's, you know, its own transition. And I don't think that's been talked about enough, certainly not when I had my kids. So, I wasn't actually aware that that's what I was going through. I just kept thinking that I'm failing. And I think those memories and that experience was deeply embedded in my sort of process. And I went on to, you know, sort of do other things and go back into my career. And I never really dealt with the emotions that I felt at that stage of my early parenting journey.

+ +

And it really all came to light sort of when Ammi was born and hatched in the incubator that I did after I resigned from my corporate role at ZINC, where, you know, the focus was on children and young people's mental health. And in that, I sort of, like, started to research the space and go like, where do you actually start with children and young people? And you start with the parents at that very early stage.

+ +

So, that's sort of, like, what led me to almost kind of revisit my own experiences in that phase and think, you know, there was something there. And if we had probably done things differently, maybe the outcomes might have been different for our family, the way that we did things or the way that we dealt with each other in those early years.

+ +

Because the other thing I learned as well while I was doing my research in that space, which I didn't know at the time when I had my kids, is that children have their emotional development take place pretty much by the time from zero to three years of age. So, it's a very significant period of sort of secure attachment, as we call it, and things. So, that's, again, a lot of concepts that I wasn't familiar with, and I wish that I was kinder to myself. And that's basically what I want to do for the community that I'm supporting through Ammi.

+ +

WILL: That is such a good point because my oldest son he has a lot of tendecies that are like mine. So, we're a lot alike, and I find that mental health aspect of that, like, how can I help him the most? How can I help him to where he doesn't have the same failures I have? Like, it's not easy being a parent because it's like, do I step in? Do I not? Do I let him fail? Do I not let him fail?

+ +

So, like, and like you said, I think parenting is probably one of the most lonely things you can go through at times, depending on who's around you, if you have family around you, friends that have children, or not. So, I'm so glad that you said that you're diving into that mental health aspect also.

+ +

PRIYANKA: Yeah, that's a key pillar of what we do and what we're building essentially at Ammi. So, the mental health aspect is one that isn't really talked about, and there's a lot of stigma and shame associated with that, in that early stage especially. And the figures itself are astounding, you know, in the UK itself, it's 1 in 3 mothers experience perinatal mental health issues. In the U.S., I think it's 1 in 5. And 1 in 10 dads experience mental health issues. And there is a certain shame in addressing that. You're meant to be happy, and you're meant to be blessed. And which is true, you are blessed, and, you know, there are moments of happiness. But this is a massive transition that you're going through.

+ +

And it's an interesting word you used as well: lonely. So, in our research and interviews with the countless scores of, you know, tens of moms that we have interviewed, the most common word was isolation. It's exactly that. Like, it can feel like a very isolating experience without the village or the community that kids were meant to be raised under and parents were meant to be supported through that. But that is no longer the case in the way that we live today. And that's where there's an opportunity to provide that to parents in a way that works with our modern lives as well.

+ +

So, for example, what we're doing at Ammi with the mental health particularly is we have developed an evidence-based solution based on acceptance and commitment therapy, which is essentially an incredible sort of modality of therapy that addresses life changes in particular. It helps you figure out your values and your parenting values and helps you set goals and actions in line with those values. So, you feel like you have meaning even though your life is changing, and it still feels significant. And now, of course, you're in charge of a child. So, how do you ensure that you're not losing yourself but equally you're bringing your own values to your parenting? I just found it fascinating.

+ +

And we're doing this in a digital way. We're doing this in a way that works for the modern parent. So, it's bite-sized. It's on your phone. You can interact with it in the middle of the night when you're feeding the baby, or you're, you know, sort of up at the odd hours of the morning with your child. That's essentially, like, what we're doing with that particular mental health piece.

+ +

WILL: That is so good because I think even you said the values, like, I think we forget about that easily. And that is everything we do, like, the way we talk to our kids, the way we're raising them, the way we discipline them, what school they're going to. But I think so many times we run out of mental headspace to even talk about those things and to write them down. So, oh, that's so good that you go through that, and you help them discover what their values are because I think sometimes, as parents, you can lose that. Even if you had the values before you had kids, it's easy to lose those values and to remember why you're doing it.

+ +

PRIYANKA: That's right. And, you know, in some cases, you know, you forget, and you don't even know really what your values might be, right? Like, you're just kind of doing things because you think you should. And should is a dangerous word as well because it's sort of, how do you uncover what it is that you really want to do as well? And what's authentic to you as an individual and as a parent?

+ +

So, for example, I'll give you one, like, structure, right? Like, I, as a parent, can get so hung up on structure as a value. I forget about connection. And, actually, if I had to, like, sort of rank these, you know, connection would be higher on my list, personally. And it's like, why am I not acting on that? And so, what values essentially do is give you this compass in terms of, like, deciding what course of action to take and how you prioritize things.

+ +

And, equally, it's also important to note that, you know, values do shift and change. So, we say in this world that it's imagine that you're looking at a globe, and a globe sort of, like, spins. And there may be some values that are topical now, but others that come to fore. So, you've got to, like, hold them lightly as well and acknowledge that they do shift. And all of this may seem sort of a bit indulgent to talk and think about, but, actually, it's really relevant in your day-to-day and also in the way that you live, you work, you parent. It's all very relevant. And I think it's important to bring light to that in the parenting context as well.

+ +

WILL: That's really, really good. So, I wanted to kind of dive deeper into those pillars you're talking about. I know you said mental health was one. What are some of the other pillars that you cover?

+ +

PRIYANKA: You know, the other thing that I've lived through and I've discovered in my, you know, research with my community and with my parents is it's one thing to sort of work on yourself, right? But if the system around you is a bit broken, it's not all in your control. So, what we want to do as well is, like, fill some of those gaps that currently exist in the system.

+ +

So, for example, you know, here in the UK, since COVID especially, and for a few years before then, you know, we rely on the public healthcare system. And there have been significant challenges with funding there, which means that a lot of the support that was available to birthing parents, to birthing people are just not available anymore. There's no continuity of care, the kind of support you could expect in terms of checks and, you know, seeing the same person, for example, seeing the same midwife. That just doesn't exist anymore.

+ +

So, what you end up having is a lot of parents who are trying to do their best, but essentially scrambling around looking for solutions, whether that's, like, for sleep, or breastfeeding, or nutrition and taking care of their baby. And that is what essentially results in those feelings of failure.

+ +

So, what we want to do at Ammi is actually provide that practical expertise as well in the most accessible way. For example, here you could go private. You could see these experts privately, but that's really expensive. And there's nothing really available in the middle, I mean, apart from, like, the free Instagram reels and things. So, what we want to do is be able to provide, again, convenient formats where you can directly access these experts. And what I mean by that is, and what we already do here at Ammi, is we run online workshops with these experts, and these are currently actually free for parents to join.

+ +

So, we rope in experts who are equally passionate about this. So, they could be experts in pediatrics, or they could be experts in physical and maternal health and wellness, but also infant health and wellness. And they run these sessions for us, and parents can join and essentially interacting live. It happens usually after bedtime, so when parents can attend. And that's one format.

+ +

What we also want to build within our digital solution is a way for parents to access these experts on chat, text messaging, as well as book appointments with them, but, like, they may be shorter form appointments, so they're not as expensive. And it's virtual, which, again, cuts out the cost of actually having to see the expert in an office or in a space that is charged, so that helps with some of the cost. Equally, it helps to have experts who can do this on their downtime on chat format. So, that also helps with the cost.

+ +

So, we're trying to experiment with these different formats that also work from a parent standpoint of convenience. So, you're not taking time off work to see these experts. So, you're not doing that in, like, daytime hours or when your baby's sleeping. So, it's really about convenience and accessibility.

+ +

WILL: That sounds really good. I like the access to the people that know what they're talking about, especially late at night and things like that. That sounds so amazing because there's so many times that, like, I remember whenever, Cruz, he's my oldest, he just wasn't feeding with Katie. And we were like, we don't know why. And the first couple of weeks, I think we went into a doctor's office, like, three or four times just to make sure that he got back up to his birth weight. And it was scary. It was like, are we doing anything wrong? Like, what do we have to do to get him to this place and stuff like that?

+ +

So, I think sometimes it's just like, "Hey, you're doing the right thing." Like we had one pediatrician...we moved from North Carolina to Florida, and we kind of miss our old pediatrician. Because when we walked in, she was just like, "Hey, he's healthy. I could tell he's healthy, and you're doing all the things right." It was almost like a weight lifted off our backs just to hear like, "Hey. You're doing okay." So, that's good to hear that you're providing that to parents and stuff. You say you're based in London.

+ +

PRIYANKA: Right.

+ +

WILL: And I'm just being honest; I have no idea what the medical situation looks like there. Can you explain what that looks like? Because I know what it looks like in the U.S. But I don't want to be naive and say, "Oh, it's the same." What does it look like when you say someone can't have access to a private provider?

+ +

PRIYANKA: So, it's not that they can't have access. So, historically, in a lot of countries in Europe and here in the UK, we have what is called the National Healthcare System or the NHS. And, essentially, what that means is that your healthcare is covered by the state, which is incredible, actually that, you know, you don't really need to spend on private insurance or private healthcare.

+ +

So, for most parents, including myself, I gave birth both times through the NHS. What that means is that, you know, you sort of, like, you get into the system. You go to your GP. You don't actually get a pediatrician, which is also something that I wasn't used to in India, but there's no pediatricians. And they have a system that you go through. So, you know, you get assigned a hospital, or you can choose a hospital that's local, but generally, you get assigned to a hospital. And you sort of give birth there under their condition.

+ +

So, there's not a lot of agency and that, I guess, is the key word because you are under the healthcare system. And essentially, that is the majority. The overwhelming majority of people give birth that way in the UK. I think 12% of the UK has private insurance cover. But equally, even if you have private insurance cover, which means that you can choose your medical care or you can, you know, sort of reimburse, get reimbursed, and things, a lot of them don't actually cover giving birth because it's not a medical condition. So, you have to pay for that privately, and it does cost quite a significant sum of money if you want to go private.

+ +

And there's just a few hospitals, actually, in London. There's not that many hospitals outside of London that do this either. So, it's not a very accessible option for most people because it's expensive, and there just aren't enough places that do that. So, in terms of that continuity of care, you have your GP, but, you know, the GP, essentially, has 10 minutes per appointment. So, you don't get a lot of time with your healthcare provider.

+ +

And equally, when you have your midwife appointments to the NHS now, you don't see the same person, so, you know, through your scan. So, it's generally someone different. You might get lucky and see the same person. So, it's quite intimidating, I have to say, you know, you don't know really, like, what you can, cannot ask for. It's not very clear what your rights are, even though, you know, they do try their best. But because of the funding shortages now and the way that the system is going, people really are struggling to access care to the level.

+ +

I mean, even, you know, the midwives are leaving the NHS. There's 29 out of 30 midwives leave the NHS after two years of training, which is shocking given, you know, the investment that they make in time. So, it is getting pretty dire, and people's birth stories are just getting quite horrific. And it's become commonplace. It's not unusual anymore, where it used to be quite unusual.

+ +

You know, there's this perfect storm building right now here in the UK of people who are struggling to get the care they need. And paternity services, in particular, are also suffering quite a lot. And there's this dearth of services, right? And people are starting, like, there are a lot of, like, sort of, like, now smaller companies coming up, trying to, like, fill in this gap through employee benefits, which is one of the routes that we plan to take to market as well.

+ +

But also, birth coaches is, you have the birthing coaches and doulas. And this is a very small market here in the UK, but it's growing in, like, triple digits year on year. So, it's really interesting to see the private world is stepping up or is trying to step up to the challenges of what the public system isn't able to do anymore. Does that help, or [chuckles] does it sort of give you some context?

+ +

WILL: Yes, that helps tremendously because here, where I'm at, it's mostly employee benefits, and it's more private. We still have so many issues because I was thinking what you're doing. I was like, oh, that's so helpful, even with what we're dealing with, but it sounds like even next level.

+ +

Like, I can't imagine taking my kid to the doctor and seeing a different doctor every single time because sometimes that's part of the helpfulness is they're like, "Oh, we know your kid. We know what they're going through. And, actually, I probably treated them the last time they were in here, so I kind of know." Because even if you have notes, it's tough to understand exactly what you saw. Yeah, I could see the benefits of what you're doing. So, that's amazing.

+ +

PRIYANKA: Yeah, that's right. And equally, like, with the employee benefits now, this is one of the benefits. The top five benefits that employees want from their employers is more family support and more time around that. And we're also seeing in terms of, you know, employee retention, right? And keeping the gender pay gap at the minimum. It's about retaining also your, you know, female employees, especially mothers who tend to leave the workforce after having children, even here in the UK. I know it's actually a lot worse in the U.S., is my understanding.

+ +

But even here in the UK where you do get more benefits in terms of maternity leave, it's still the cost of childcare. And there are so many other issues about just not having that support system that completely sort of overwhelm the families for one of them to have to drop their career, which is unfortunate. So, I think there is definitely a play here for employers to step up here in the UK and in Europe to this challenge of retaining their employees through benefits such as this.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

WILL: What are some other ideas that you have? What does success look like in the next six months, five years for you? Where are y'all going?

+ +

PRIYANKA: Well, in the next six months, I think it's really about getting the product to market, like, getting our MVP and product out there. You know, we're doing things in a very scrappy way at the moment. I am, for all practical purposes, a solo founder, and I've been bootstrapping. What we have developed, you know, with my fractional team of clinicians and my CTO is we have a really high-spec figma prototype of what our solution would look like. We have our content ready and the mental health, the evidence-based mental health program ready.

+ +

It's now about getting that on a platform, and that is going to require some funding. So, I'm in the process of fundraising. So, ideally, in six months, we would have raised enough money to get that MVP out and to get this product in the hands of our customers, our customers being potentially employers. But also, you know, within the Ammi community, I've also been building a community as I've been running these online sessions and creating that side of content as well on the practical expertise side.

+ +

And we've got about 500-plus parents around London who have attended our workshops, and most of them are part of this community. And, you know, they're the ones that we've sort of tapped on for our testing. For also the content that we developed, we handed it over to them and, you know, we ran a trial and with some great results. So, that's basically the kind of work that we've done so far over the last year. And, really, in the next six months, it's about getting the product out, raising some money, and, yeah, hopefully, being revenue-generating. So [laughs], it's a lot to look forward to, a lot to do.

+ +

WILL: It sounds like that's that next heel, the next step, so...and it sounds fun. You help parents with their core values. What are some of the core values that you use and that you have that you make decisions through every day?

+ +

PRIYANKA: It's about authenticity. That's the guiding principle. It's about being authentic to our mission, being authentic to what the customer wants, you know, first and foremost, and authentic to what my vision for Ammi is, which is to be that co-pilot in those early years. And how that sort of helps me is even when I look at funding, and I look at the type of funding or who we, you know, want money from, I know that, you know, sort of, we can't really dictate that at this point. But I really don't want there to be a risk of mission drift from what we're trying to do here. I've lived that life before where I've done things to just sort of tick the boxes.

+ +

And I do genuinely think that there is a commercial opportunity here as well within the mission that we're trying to achieve because, you know, from employers to parents themselves, they're spending money on this now, and, you know, the tide is turning. So, for me, authenticity is number one. And, generally, like, you know, when I am faced with any decisions, whether that's a product-based decision, I'm like, right, like, what's more important to our community? What do they really want?

+ +

So, it's all about going back there and seeing, like, what is going to give them most value? It's about understanding when we look at the development or getting team members on board, it's, you know, who believes in the mission? So, that generally is what guides me in my day-to-day decision-making process.

+ +

WILL: Yeah, I really like that because I feel like, especially with social media, there's a lack of authenticity sometimes. Sometimes, I feel like society wants you to be this superhero as parents. And sometimes it's like, I think I have some of my best moments with my kids and some of my worst times with my kids. Just, like, I think sometimes just being honest about this is where you're at as a parent. You're doing okay. Maybe you need to tweak this, this, and this, but I think that's a good thing to go by. So, I really like that you said that.

+ +

PRIYANKA: Well, there's lots of ways to make money. Entrepreneurship that might be one of the things you do to make money, right? But it's not the easiest way. You know, I gave up my corporate career for a good reason, and I want to remember that. It was to sort of achieve big things but being authentic. So, that's really, like, where we are at.

+ +

WILL: I love it. Love it. I usually ask this question around careers, but I'm going to ask it for parenting. So, if you can go back in time and give yourself advice on your parenting, what advice would you give?

+ +

PRIYANKA: I would just say chill out [laughs]. You know, I think I was so hard on myself, right? So, for example, like, you know, when my son was born, my firstborn, I was so hell-bent on breastfeeding and, like, every bottle I had to give him a bottle day three because, you know, like you, like, my son as well he lost a lot of his weight, and we got worried. And he wasn't feeding. I didn't have a supply. So, it was so hard, and I felt like I failed. Every time he didn't sleep through the night, it felt like I failed.

+ +

So, I sort of took responsibility for all of it. Like, you know, this is, you know, that I'm failing this next project. But I wish I could just, you know, sort of go back and be like, this is all part of the journey. And this is a, you know, sort of a small person that you're trying to raise, and they have different rhythms, and it doesn't go by the book. So, those are some of the things I would tell myself is just to be kinder.

+ +

And, you know, actually, that's another thing that we do at Ammi is, like, just that self-compassion in our program about, like, just being easy on yourself for those years. I had to sort of come back and, you know, as you said, bounce back. And, again, all of that there's just incredible amounts of pressure on parents. Yeah, I think I would just tell myself to be kinder and be patient through all of that and things will work out.

+ +

WILL: I appreciate you saying that because I needed to hear that, to be honest with you. [laughter] Yeah. Just, I think, my kids are 4, 3, and almost 2, so, like, 22 months. So, "It's going to be okay, and chill out" is really good advice for me to hear at this time. So, I appreciate you saying that.

+ +

PRIYANKA: Yeah. And it will be, you know, I mean, I know it's hard. Like, it's as they say, the days are, you know, long, and the years are short. But when you're in it and when you haven't slept in a week [laughs], it can feel like it's just dragging on forever [laughter]. And that's one of the hardest challenges, right? Sleep deprivation. So, sleep workshops are the most popular, as you would expect. You know, we get sleep experts to come in and talk about it. And, generally, you know, what's really interesting is, like, through a lot of these workshops, what they all end up really saying is that everything is normal [laughs].

+ +

So, it's not like one sort of thing is normal. And just having an expert say that to you and say that to our parents who join these calls is just incredibly relieving for them that they're not, you know, in some race and competition to see whose kid has slept through the night or, like, what's, you know, what I'm doing wrong, whose kid is eating the most variety of fruit and veg, you know, that's not what it's about. It's all normal. And they just go away and sleep well that night, right? Like, after a workshop because they're like, this is great. I'm doing it okay [laughter].

+ +

WILL: Well, once again, that's good to hear because, like, last night, I think I got five hours of sleep because of my son.

+ +

PRIYANKA: Ooh.

+ +

WILL: Thank you for saying even that because, like, you question yourself a lot. Like, I know I do. I question myself a lot. Am I doing the right thing? Is this what I'm supposed to be doing? So yeah, that's really good to hear.

+ +

PRIYANKA: Yeah, it's a common ailment that [laughs], you know, sort of goes around the parents of our generation, I think.

+ +

WILL: Yes, definitely. What are some of the biggest hurdles you see coming up?

+ +

PRIYANKA: As a startup, there's hurdles every day. You know, there's things sort of that we're...challenges that we're facing, but really in, you know, in the current climate, I think it's about securing the right kind of funding and the amount of funding we think we need in order to get the product developed and go to market. That is a big hurdle. I have, you know, sort of some plan B set up in terms of how we could, you know, sort of test our solution in other ways and in scrappier ways. And we're kind of working on that alongside it.

+ +

But it's a difficult environment for startups right now, as you might have been aware. And especially with healthcare and wellness, in particular, it's been pretty hard over the last couple of years. The problem hasn't gone away, you know, so mental health and, you know, sort of wellness was a thing two, three years ago. And then, you know, it's all shifted to climate and sort of climate tech, which is great because that is also a problem, but equally, we haven't fixed any of this yet. And there are, I think, opportunities to do things in this area that might be missed if the funding doesn't come along. So, funding is definitely one thing.

+ +

Yeah, in terms of hurdles, if we do get the funding, it's about making sure that we get the right team together. As I said, I'm a solo founder, so that in itself is a hurdle every day as I try to sort of juggle the bootstrapping and the endless to-do list that I have with Ammi. So, I'd say, yeah, I think those are really the big things that I'm focusing on.

+ +

WILL: Yeah, I love that. And yeah, I agree. Funding is probably, yeah, that's a big hurdle. And as a parent, it's much needed just to hear those things. So, I hope it all works out and it goes well.

+ +

PRIYANKA: Yeah, no, thank you. And sort of showing that it's a need, but also, it's a commercial opportunity, right? Like, parents now in the UK, the spending that parents do in that first couple of years that their baby is born has skyrocketed. And more and more, you know, as we see, like, parents coming into sort of this journey now, are aware of the impact that poor sort of mental state can have on their children. It's not like how it was when I gave birth. Like, I think a lot of parents now are well aware, and they want to sort of be fit, not just physically, but also mentally for this journey.

+ +

So, there's a lot of trends that are in our favor. So, you know, when it comes to things like spending on services rather than goods, you know, that's going up, the awareness around mental health. Unfortunately, the incidence of poor mental health is also going up. And so, people are coming into this, and there are multiple challenges, you know, that contribute to that as well. And the risk factors, unfortunately, is another thing.

+ +

So, for example, a lot more parents are getting into parenting after having a difficult fertility journey or having experienced loss or, you know, neonatal ICU moments. So, all of that is really stressful to deal with. And then, you know, then have this child to sort of look after when you're barely healing yourself. So, I think people are recognizing the need for this, certainly, the parents are. It's about making sure that investors see that now as well as a commercial opportunity.

+ +

WILL: Yeah, I really like that. Yeah, I totally agree with that. What motivated you to start your company? Like, was it just the experience that you went through when you were raising your kids, or was there a certain thing that motivated you? Because, like you said, entrepreneurship is not easy at all. So, what motivated you to want to start your company?

+ +

PRIYANKA: You know, as I mentioned, I was, you know, sort of on that sort of corporate ladder for many years. And while I was, you know, even doing that, I think there was a certain restlessness inside of me. Am I living my most authentic life? Like, is this how I want to spend my days? You know, and I have a family now. Is this what I want to be doing when I'm not at home? And that was sort of bothering me.

+ +

And then, you know, 2020 happened, right? And I'm a statistic of the great resignation, but, like, it really was triggered by some significant life events. So, very, very early, like, almost before any of the lockdowns and start of the pandemic, in February 2020, my husband got really sick with COVID and was on a ventilator for ten days. They didn't even know really what COVID was at the time. He was one of the first, like, maybe 20, 30 patients in London in hospital. And yeah, we almost lost him. So, that was big.

+ +

And, you know, at the time, I was dealing with a high-pressure job and very young kids at home, you know, sort of at the end of my sort of mental space as well. And I took some time off and just decided then, like, I think I need to sort of pivot now. I need to, you know, life is too short. So, I resigned from my role a few months in and decided to focus on more meaningful ventures. And that's when I stumbled upon ZINC venture capital. So, ZINC venture capital is an incubator accelerator program here in the UK. And they invest in mission-based businesses, and their '21, '22 cohort was actually, as I said earlier, you know, on children and young people's mental health.

+ +

And within that, you know, while I was researching it, I think it just brought up these memories of being, like, in that early phase of parenting. And I started meeting a lot of moms who were in that phase and just realizing that these are, you know, capable women who are at their most vulnerable physically and emotionally at this time, and they're being let down. You know, these families are being let down by the system, by the environment that we live in, and, essentially, feeling like they're failing. And I recognized that in my own experiences. I had a lot of anxiety, as I, you know, sort of mentioned with my firstborn. And I think that did impact.

+ +

And, to date, we're sort of probably dealing with the impact of the way that we were as parents, you know, with him. And I just wish I had done things differently or I knew different. And that's really, like, what has motivated me. And I see, you know, these moms, like, looking for solutions and these dads as well, like, sort of more aware of these issues, but they don't have the support. So, that's really, like, where Ammi was born was, you know, during my time there.

+ +

And it was also a process of, like, finding my own personal mission, you know. And I feel deeply motivated by this, by solving the problem really. I'm not so married to the solutions. It really, for me, is about the problem and making sure that we get the right solution in people's hands.

+ +

WILL: Yeah, I really like that. I think 2020 was rough for everyone. I think it was really, really rough. It was rough for me. Like you said, it was rough for you. But I'm hoping that we're going to start seeing...because someone was telling me about trends that happen. Like, we usually go through a really rough time, but then that's usually when we get creative solutions afterwards.

+ +

And so, I'm hoping that's what we're seeing, you know, with your company and many others, which is those creative solutions from 2020. All that that happened I'm hoping that we're starting to see more and more creative solutions. So, I'm so glad that you're starting this and that you stepped out and that you're doing this because I think it's going to benefit a lot of people.

+ +

PRIYANKA: Oh, thank you. I appreciate that. It's good to hear as well [laughs].

+ +

WILL: Yeah, definitely. So, clearly, there's a need for your solution. So, what are you hearing from the investor side, and what does that look like?

+ +

PRIYANKA: It's interesting. With things that have to do with wellness or sort of parenting, and, you know, as we now call it, like, femtech, there seems to be this perception that it's a crowded space. I can see why people say that, you know, maybe there is this sort of influx of, you know, your Instagram feed full of, like, momfluencers or messages that are coming across on parenting and things.

+ +

But if you really ask parents if they feel supported and they have access to what they need, they're still struggling. And they're still finding it difficult because every parent's journey is a little different, and they need that direct access. That's still quite hard to get. Like, you could do your research, but equally, that takes up time.

+ +

So, I think what we're doing differently at Ammi and what we're really doing here is to make that access to experts as easy, convenient, and affordable as possible, and I think there's definitely a space and market for that. Making that access sort of affordable and easy but equally, like, having that support, having the coaching support and continuity of care, which doesn't exist anymore, and not a lot of people are doing that yet.

+ +

There are a few startups that are sort of entering the space. In the U.S. I think, actually, there's been more proof of this concept working with the incredible work that Maven Clinic has done, for example. But in the UK, it's still pretty niche, and in Europe. So, I think there's a potential for a big player to come in and take up that space. And that's what I'd like investors to know is that: the commercial opportunity is not to be understated here in terms of what that is.

+ +

There's, you know, 600,000 new parents in the UK every year. And if you think about it, if even 10% of those are spending what is the average on the baby's first few years of life, which is anywhere between 8,000 to 15,000 in that year, a percentage of that does go to services. That already is a huge annual market that one could be looking at entering, sorting, and de-fragmentizing or...well, that's not the word but organizing because it is a very, very fragmented space. And there is opportunity to make that a lot easier for parents. That's kind of the message I'd like to get out there.

+ +

WILL: As a parent, I'm glad you said that because one thing I keep hearing you saying is experts, experts. I like that your platform has experts, and I can trust their info. Because I get some info from social media, but sometimes I'm like, can I trust this information? Is it real? Is it AI? Whatever it is. So, I like yours that it's like, we've added these solutions, and they're experts. So, that's, yeah, I can see how that's so beneficial.

+ +

PRIYANKA: Right. And that is what most parents tell us is: trust is such a big factor. Parenting is, like, one of the biggest things that you'll do in your life, you know, and trust is essential because you don't just want to be trying things at random or, you know, sort of sometimes you do that, but it's not ideal. And most parents will pay for that, too, you know, they will pay to talk to an expert. They will pay for that. They might not pay for the free information that comes in their way.

+ +

And this is why, like, content is one part of a strategy, but it's not core to it. It really is about creating those personalized journeys. And maybe this is another conversation as well for next time, but it really is about, like, scaling that. And that's really interesting in how we plan to do that as well. How do you scale personalized solutions? And I think that could be really interesting.

+ +

WILL: Yeah. Oh, yeah. I could definitely see if you could figure that out, wow, it opens up so many avenues for you. So, that's amazing. So, with your solutions, how have you validated that this is what your users want and this is what they need so that they're successful?

+ +

PRIYANKA: We've been doing a process of validation right from the beginning. You know, I've run ideation sessions—co-creation sessions. I've done maybe 20-plus interviews with mums and run surveys with over a hundred parents to really understand what it is they need. So, we developed, like, the version one of our prototype based on the top problems that parents told us they were having, the kind of ways in which they wanted to access help.

+ +

So that's where, you know, sort of the creative ideas around text chat and workshops and ways to make it more accessible came about, even things like having all of that on your phone because most parents will be on their phone in those early years and not so much on desktop. So, that was another thing that informed all of that. So, we did two rounds of testing, and then we did another third round as well to ensure that we were, like, tweaking our prototype to really make it exciting for parents.

+ +

And once we developed our mental health or sort of a mental health coaching platform, we also ran that on a two-week trial with a bunch of Ammi sort of community members. And the results were, like, really reassuring and almost overwhelming to some extent with, you know, some moms saying that, you know, doing some of those exercises help them sleep at night. And some others said, "Oh, wow, these sections really speak to me on values and goal setting." Some others said that "You know, it really helped me provide that moment of calm and stop my ruminating thoughts." And all of this is really encouraging to hear from people directly as they've used your content and your platform.

+ +

So, that's sort of, like, the validation we've been through. And I think it's always going to be a process. You know, even when we come out with version 1, we're going to learn what people are interacting with most. And, you know, I'm really interested to see how they react and their behaviors around the text chat particularly. So yeah, it's one of the best parts about building something is that interaction with your users and community. Like I said, it's 500-plus moms who are part of this community now and who've been informing the solution at every step of the way.

+ +

WILL: I love that you took that step to validate it. Priyanka, thank you for joining me today.

+ +

You can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+2vHNTzgM + + ]]> + + Will Larry + + + 518: The Standard of Self-Care: Unlocking Personal Growth with Chris Pallatroni + https://podcast.thoughtbot.com/518 + 6d944711-fec8-4c20-8e27-514a366f8454 + Thu, 28 Mar 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido chats with Chris Pallatroni, who unveils the journey behind creating The Standard, a unique platform for sharing self-care stories. Chris highlights how his love for gardening and dedication to mental wellness shaped the platform's ethos and addresses the challenges of melding technology with human connection to foster a community of support and growth. The Standard aims to inspire and connect individuals by sharing personal triumphs to make mental health struggles feel less isolating. + 41:20 + no + + + In this episode, host Victoria Guido interviews Chris Pallatroni, creator of The Standard, a platform dedicated to sharing self-care stories. Chris shares how his interests in gardening and mental wellness fueled the inception of The Standard, which was initially intended to be a landscaping venture. +He delves into the hurdles faced while developing the platform, highlighting the struggle for product-market fit and the critical role of integrating technology with human connection to enable meaningful support and interactions. +Chris underscores storytelling's pivotal role in enhancing mental health, advocating for the sharing of personal triumphs over adversity to motivate and assist others facing similar challenges. He envisions The Standard as a vast collection of genuine, relatable self-care narratives aimed at reducing the feeling of isolation among individuals. Through inviting users to share their experiences, Chris seeks to leverage human connections to cultivate a community supportive of mental health and personal development. +The Standard (https://thestandardapp.com/) +Follow The Standard on LinkedIn (https://www.linkedin.com/company/thestandardapp/), YouTube (https://www.youtube.com/@__thestandard__), or Instagram (https://www.instagram.com/__thestandard__/). +Follow Chris Pallatroni on LinkedIn (https://www.linkedin.com/in/chris-pallatroni-9bba3b22/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: + VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Chris Pallatroni, Founder of The Standard, a storytelling platform where people share stories about self-care. Chris, thank you for joining me. +CHRIS: Yeah. Thanks for having me on. It's a pleasure. +VICTORIA: Wonderful. So, before we dive into all about The Standard, why don't you just tell me a little bit about what's going on in your world outside of work? Anything fun? Anything exciting? +CHRIS: Yeah. Well, first of all, I've got two boys, so for anybody that's listening that has kids, I mean, let's be honest, your life is completely chaotic. So, I've got two boys, one's almost 12, one's almost 10, so all boy, all the time. That's just another way of saying our house is really loud, and there's just tons of stuff happening, sports, whatnot. I also have a wife, a beautiful wife. She's my better half. I've been with her for 24 years. So, between that, I got three cats, not that they take a lot of energy, but there's just a lot of love in our household. So, that's sort of, like, the family side of things. +And then I'm an avid gardener. I'm really big into mental health and wellness, which, as we start to talk about The Standard, will become really evident. So, I'm all about just doing the things that you need to do to take care of yourself, so lots of running, lots of working out, lots of just being in nature. I know you're a surfer, so, I mean, let's be honest, water is amazing. So yeah, anything I can do to, like, duck out into nature and spend time with my family. Honestly, there's just not enough time in the day. +VICTORIA: What is growing in your garden that you're the most proud of? +CHRIS: You don't want to get me started on gardening. So, before I started The Standard, honestly, I thought I was going to be a landscaper, and the name of The Standard actually was going to be applied to a landscaping company. So, I am a professional landscaper. I took all the classes: soil, science, irrigation. I got the degree in design and maintenance. +I have a tiny, little property, but I have about 700 plants on my property. So, I know everything on the roses, and grass, and camellias. I mean, I'm that guy that, like, likes to see...nature is just amazing, first of all. And it also has very therapeutic qualities when we start to talk about mental health and well-being, birdsong, water, greenery, sunsets, sunrises. +I'm also developing a piece of land. We have a house we're building, and it's three acres. So, I'm in the process of building out, like, what I'm going to just describe as the most amazing garden anybody's ever seen. I really take a lot of pride in gardening. I'm very disciplined and very specific on how things grow. And so, I've got a property that's about an acre and a half I'm planting, which will probably have, like, 20,000 plants on it when it's all said and done. +VICTORIA: So, you have 700 plants now, and you plan to have 20,000, so you don't want to choose favorites. There's nothing...you got to, like, spread the love around. +CHRIS: God, it's like saying, which child do you love more? I mean, right now on my property the ones that currently stand out is I've got a couple of these Eden Rose bushes that I've trained to climb up. I've got three of them. The one in the front of my house is about 20 feet tall at this point. So, I've trained it to grow up the entire side of my house. In full bloom, it will have about 300 roses on it in full bloom. And so, an Eden Rose has about a 220 petal count. So, it's a very dense rose. They are a pain in the butt to prune, but they're pretty spectacular in full bloom. +VICTORIA: That sounds really beautiful. And I hope you send me some pictures [laughs] after the show. Send them to me in an email because I want to see...I love growing, but I do not have a green thumb. I usually try to pick what is most likely to survive [laughs]. +CHRIS: That's my wife's strategy. She's like, what can I not kill? And, surprisingly, even with, like, cactuses, she still finds a way to kill some of them, so...[laughs] +VICTORIA: Some people have it, some people don't. I do agree on the therapeutic side. And I'm curious, too, having this background, how did you go from landscape and this interest in growing things to starting businesses? +CHRIS: Yeah, you know, the landscaping actually picked up at a much later stage. So, if I rewind my entrepreneurial journey, it started in 2004. I got mixed up with some guys as I was finishing up my degree in economics and finance. I was like, look, I don't have, like, a 4.9 GPA, so I'll probably need some sort of internship that starts to separate me. Anyways, got mixed up with some guys that were running a franchise painting company, took part in that, really loved the idea of seeing something grow. Did really well on that internship. You really ran, like, a mini-painting division of this larger company, so knocking on doors, producing painting jobs, so forth, and so on. +At the end of that, which was a really intense about a year internship, they said, "Hey, we're going to build this marketing company. Do you want in?" And I was like, "Let's do it." And so, what I really wanted...and that was, like, my first major let's start a business. And I loved the idea of taking something from an idea to...the idea was, could we sell it for a hundred million dollars? So, the money was attributed to it, but I wanted to see something grow. +And so, we went at it for, like, 15 years. We did end up selling, not at a hundred. We sold it for, like, 70 million. But we did really well. It was a bootstrapped company. We built this massive national marketing company. It's sort of like match.com for contracting. You can take a consumer that's interested in remodeling their house and connect them to a local contractor. And we built that all from, like, a bedroom with plyboard and literally rotary phones all the way to a national brand that's...I think we became the second largest in the space. +It's still the company I still work for. As I build this other business, I'm still working at that. We're pushing 250 million now. But the concept of building something and selling it I thought was really intriguing. Landscaping was just a hobby that came in much later in my life. Thought that was going to be my next venture. I decided to pivot after getting all of the education, mainly because I wanted to build something that had application for everybody. +And what I started to realize in landscaping is the average consumer doesn't have $50,000 to dump on their backyard. And what I didn't want to do is work for rich people and wineries. I really wanted to build a magical, little space for the average person. But I also started to realize most people don't have that type of income, which then pivoted me to The Standard, which I thought had more universal application. +VICTORIA: That's really interesting. So, I love that because there's, like, a common phrase you hear about tech where every company is also a tech company now. So, it's really interesting to hear and, like, to hear about you think about growth and how it applies to businesses and that care that you put into it as well. +CHRIS: Yeah. I mean, I think everything is tech-related in a lot of different ways. I don't know, I think at least with The Standard, like, there's such a human element, and I still need to figure out so much about it. But as tech-driven as we get, we're still a social species. We still want human connection. And maybe at one point far off in the future, like, a robot can replace some of that, but the human connection, the human story, the ability to feel connected and not isolated or alone has very profound impacts on people's mental health and well-being. +And so, as much as I still have to figure out, I try not to over-index on too much tech and try to keep things very authentic and organic. Because I think when you do that right and you can do the matching of a consumer that's interested in a specific story with someone that has gone through that experience who can share that story, that connection is very profound. So, I do think it is a blend of tech, but I try not to dive too deep into the tech side of things. +VICTORIA: Right. It's more that you need technology as a tool to solve the problems of the people that you're trying to work for or trying to, like, provide services for. So, it sounds like, to recap a little bit, you were part of growing this company. You were able to build it and sell it for 70 million. And then, you decided to, like, keep doing it. You're like, that was fun. Let's do another one [laughs]. +CHRIS: Well, I mean, in all honesty, I think some of the challenges become when you're starting a company, which is incredibly invigorating. But if you're starting a company in an area that you don't have expertise...so, although I know a lot about mental health and wellness, I've read hundreds of books. I interviewed lots of people. I hired you guys to do some market research for me. So, I'm not naive, but I've never built a platform that does what I'm trying to do. And in all my research, I haven't exactly even seen a platform that does exactly what I do. So, it's hard to have that perfect measuring stick. +And so, you know, what I've realized along the journey is it's really easy to spend money, and it's really hard to find product-market fit. And so, what I've chosen to do, and maybe it takes a little bit longer to get there, is rather than, like, go all in, quit my day job, and really just financially stress the crap out of myself and my wife, I still have a day job. I get paid exceptionally well. I'm very senior in my company. It's not overly stressful, but it also pays the bills. +And so, I think one of the things I've learned about being an entrepreneur is you've got to enjoy the journey. And so, I do enjoy what I still do, and it serves a very valuable purpose. And it gives me still the freedom to play around with The Standard, to still do the things that I want to do. Sure, I can't burn as many hours on it, but at the same time, if I quit this job, my runway would highly compress, and maybe that's good for some people, but there's still just so much I have to figure out. So, I need the runway. +VICTORIA: I can relate to that, and I think that's a really common story for people who have a great idea, and they need the time and space to find the right product-market fit to move forward and then make the big investment with your time and all the, like, other financial investments you would need. So, maybe to go back to the beginning a little bit, what led you to think of starting The Standard in the first place? +CHRIS: So, I'll try to say this as succinctly as possible. Life is really hard for a lot of people, you know, and you can dice it up in a lot of different ways, whether we're talking about, like, you know, global events that happen, be it war, be it COVID, you know, anything on a very large level. But even on an individual level, like, we lose people. People are dealing with weight issues, how to eat healthy, stress. There's a lot. +When we start to think about the concept of mental health and well-being, it is overwhelming. And I'm built for discipline. I've always been that way. I'm incredibly disciplined as a person. Some things may feel like they come a little easier to me, but I also look at like, oh my God, I got to worry about like, how do I sleep right? And how do I eat right? And then, how do I exercise? And then you got to be grateful for stuff, and then have social friends, and then be with your family. Like, I mean, adulting is tough; let's just be honest. +And so, a lot of the concept behind The Standard was I have the freedom to explore a lot of this stuff. I've had the luxury to read hundreds of books and, meet so many people, and really invest a lot as to educating myself about these various topics that I think are important. +I also have the luxury to deploy a lot of these strategies in my personal life, and it's a privilege to be able to do that. And a lot of people don't have that. They're struggling. They're working multiple jobs. They don't have a lot of time in the day. Maybe they're commuting. They don't have the luxury to take care of themselves. And that's just the Western world. Do you want to, like, dive into the Global South or start to look at, like, Ukraine or stuff like that? Like, there's just people, like, literally just trying to make it through the day, let alone be grateful about something or eat healthy. +And so, I started to realize, like, God, if I think this is even remotely challenging, what does somebody else feel about their mental health and well-being? And so, that was sort of the jump off of, like, it is tough to maintain your sanity. It is tough to do all of those things. Is there a way that I can make that process easier for people? And so, that just led to a rabbit hole that started about six months before COVID hit, so late 2019. I spent a lot of time researching. +I read several hundred books on habit formation and neuroscience and all these different topics. And, I mean, to the point where I was reading every morning, typing notes of these books, mind mapping this out, looking for the connection of all these topics. And what I was trying to figure out is what is the least amount of information somebody needs to know to have the most profound effect on their life? And what I came to as a conclusion was most people will not read a book or listen to a podcast. Some will, but the average person won't. They don't have the time, the desire. +But everybody's got a problem they're trying to solve, whatever that problem may be, and if you could take somebody that has a problem and you could find a way to connect them to somebody who had that problem but is a little farther down the road. So, let's pick something pretty simple, like weight loss. I've interviewed a lot of people on my podcast this year that have lost 100 pounds, which is a really big number. And even if it's not a hundred pounds, you want to lose 20 pounds. The point being is that weight is a big issue for a lot of people. It affects their self-esteem, their body image. There's a number of things that, like, impact that. +But if you could connect somebody who's really struggling to lose weight with somebody who has lost that weight and could share their story, how they felt, the habits they've deployed, and most importantly, they could talk about that experience, what would happen is the person that's been through that issue, if you will, would use a set of language that would be very specific and would resonate with the person that hasn't overcome the challenge yet. +And this is what's so unique about it is: I don't know what that particular challenge is like. I've never had that particular issue. I won't know the language to use. But if you've ever talked to somebody who has lost a significant amount of weight, they will use words, and they will give examples that only somebody who's struggling with it would resonate with. +I remember doing an interview, and a lady was like, "God, you know," she's like, "I was so overweight. I would be very thoughtful of getting on the ground because I wasn't sure if I could get back up. Or I'd be very thoughtful of the chair I sat on in case it broke." I mean, these are the things I'm like, unless you're overweight, you don't think about that. +And so, my idea was like, could I take somebody who's overcome some of these problems, get them to share some of those self-care stories that they used to solve whatever that problem was, and then create a mechanism in which somebody who was struggling with, in this case, weight loss, that they could type in, "How do you deal with weight loss?" and they could connect to other people that have developed the habits and the mindsets that helped them through that? And weight loss is just an example, but you could pick anything from racism to depression to domestic violence and so forth and so on. +The caveat there is you need a mechanism to connect the person that's overcome the challenge with the person that's still going through it. So, you got to get a lot of people on the other side of the tunnel to share their story and to know that they're doing it maybe not to monetize it but to do it for the benefit of other people who were like them at one point. +VICTORIA: Yeah, if I can try to summarize what you meant when you said, like, what's the least amount of information to have the most profound realization on how to impact your life? It sounds like what you discovered was that it's human connection to other humans who have had the same experience and survived it and overcome those challenges. +CHRIS: Yeah, without a doubt, because I think when you're struggling with an issue, you tend to think you're alone. You tend to think the way you're thinking about your addiction to something, or your weight loss, or your body image; you tend to think, oh, this is just me. And what motivates somebody who's in that mindset is to hear somebody else who can use a certain set of language that helps them realize, wow, I'm not alone. There is other people that have gone through this particular issue. And what that does is it starts to open up the door, open up their mind in a way of, wow, change can happen. +Now, you can't copy other people's habits. It doesn't exactly work that way. But what it can do is at least give you a starting place to say, "Here's somebody who I feel is like me in some ways, and they've made it to the other side. Here's some of the habits, and the mindsets, routines that they specifically have that have helped them get through this. Maybe I can try some of those on, at least as a starting place, and then I can modify them as time..." +So, it really starts with the mindset and the clarity of I'm not alone and maybe there is some hope. And I think that's a really big thing when you're talking about some of these very large issues that people run into on a day-to-day basis. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: So, what lessons did you learn from your previous experience in starting a business are you taking into what you're doing now with The Standard? +CHRIS: Oh my God, so many lessons. Well, I mean, here's the brutal reality is: I've chosen to go in an industry that doesn't exactly have carryover effects. I was in marketing, dealing with homeowners and contractors, and now I'm diving into mental health. So, I, unfortunately, don't get to, like, flex my black book and, you know, voilà myself into, like, success here. I've also chosen to go from marketing and generating leads to now I'm trying to build a platform, which apparently is one of the hardest things you could possibly do. +But here's one that I really do take away, and it's probably not in the way that you actually intended that I would answer, but here's the biggest lesson I've taken away. When I built the first company, Jason Polka was our CEO, and Gabe Luna...it was three of us that really started it. So much of that entire journey...especially after the first five years of building the infrastructure, and you started to move out of the basement, and you had a corporate office, and, you know, you felt a little bit more legit. You started generating 10, 20 million dollars a year in revenue. +I'd say from year, like, five through the time we sold it, I just wanted to sell the company. So much of the conversation became around, when is this going to happen? And it was always a grind. I mean, building a company is just tough. I mean, maybe some people, it works out, and everything's great, but it's really tough. A lot of businesses don't succeed, and we were very lucky that we did. +But so much of it was me just trying to check off that final box of, like, I just want them to say, "We did it." It wasn't even really the payout. It was, just, I want to know that we were capable of doing it. And what happened is there was so much of that ten years where I wasn't enjoying the journey. I mean, don't get me wrong, like, I love the people I worked with, some great friendships. But it was so much of like, how do we fast forward this a little bit? +And so, once the day happened that it was sold, and especially as I started to embark on this other side, I said, look, I'm now in my, like, early 40s. Like, that can't happen again. I mean, maybe I never sell the next company. Maybe I'm working on this for a decade or two decades. I need to enjoy the journey. Like, my kids are young once. Like, I've got this wife. I've got this life. Like, selling a company is great, but it is not the defining thing of your life. Like, you still need to live your life. +And so, the big lesson I took away from it is how do I enjoy the journey as I go through this process? And I'll be honest, that is a big mind f, if you will, like, it's not an easy thing to do because as entrepreneurs, you're very much like, well, what metrics, and what's the next milestone? And dah, dah, dah, dah. And, like, dude, it's brutal. So, I'm really trying to, like, enjoy the process, even if the process is a struggle. +VICTORIA: What are your top strategies for enjoying the process or making it fun? +CHRIS: Well, one, take care of your mental health and your well-being [laughs], whatever that is for you. I do a lot of weekly planning. And so, when I do my weekly planning, it literally will come down to I look at my schedule, and I make sure I get my runs in there. I get my gardening in there. I get my time at my kids' events, my time with my wife. I get my workouts. I make sure I eat healthy. I do everything that I can to take as good of care of Chris as I possibly can. You know, a cliché is to say, but you can't pour from an empty cup. +So, if you want to give your best to your company, your family, your friends, your community, whatever, like, you really do need to prioritize yourself. Self-care is not selfish. So, that's the number one thing I do. +I'd say the other thing, too, is how do you deal with anxiety? How do you deal with this constant...and anxiety is one of the most pronounced mental health issues on our planet. 350 million people deal with this annually. It's easy to start to think about the future and to fill in the gap with the worst-case scenario, to get anxiety of, like, oh my God, I didn't do this, or I shouldn't be doing that. +And so, learning to just take a deep breath, do the best job you can. Let your intuition carry you, and not be so judgmental when it doesn't turn out the way you want it. Like, I wish I had much more success at this stage of the business than I do. But I'm still making forward progress, and I'm enjoying the process, and I'm learning stuff. And could I be faster? Yeah, probably. +So, I try not to over-index on what I'm not doing, and I try to just take the best next step possible and just trust it will all work out but be okay if it didn't. That's easier said than done sometimes, especially if you've never had success. I think part of it is the fact that I've been successful in selling a company. I mean, in a lot of ways, like, hey, I know I could. Maybe I can do it again. Maybe I can't. And I'm okay either way that that pans out. +VICTORIA: I think that part about being okay if it doesn't is so important. And tying that together to what you mentioned earlier about being financially stable enough to invest in what you want to invest in, like, it's a really big, important thing for founders. And I think if you're constantly worried about how am I going to pay myself? How am I going to pay my bills? You're not really going to be focused on building the best product, or actually solving the problem, or being willing to pivot in a way you need to to create something that is going to last and be really impactful for people. I think that's really interesting. +In climbing, there's some...it teaches me that because I have some projects that probably I might never complete them [laughs]. They're really hard. The people who actually create videos of themselves climbing it are, like, six feet tall, and I'm never going to be six feet tall, but I just try to enjoy the hike up to the climb. I enjoy going up to this little boulder and just, like, touching it and feeling it. +So, I'm curious if you could say more about how are you thinking The Standard will solve that problem and, like, create that connection for you and, like, solve your anxieties as, like, a founder about, is this company working well enough? Do you connect people in that same way as well? +CHRIS: There's a famous quote that says, "It takes seven years to become an overnight success." I mean, maybe in some ways, it even takes longer, depending on what you're trying to build here. And, I don't know, success is somewhat arbitrary. You know, like, I remember when I got the call that we sold our first company, which was the moment I was waiting for, I remember getting the call. I was driving home. "Hey, we did this. Here's your payout." I did not feel any more successful in that moment. Like, it wasn't like that checked off the box. I'm like, well, there I go. I'm super successful now. It was like, now what? +You know, my kids didn't, like, hug me and be like, "Oh, successful dad sold companies," you know, it wasn't. It was like, you know, life continued. And it was just such a powerful reminder of so much of the significance that we put on things is like, it's us. Like, I don't want to say nobody else cares because, you know, a lot of entrepreneurs are trying to build products that, you know, change the world, make a meaningful difference to people's lives. And we do put a disproportionate burden on ourselves of, like, God, if I don't do this, maybe it just doesn't get done. +I think, for me, when I'm building The Standard, I try to, one, I always try to think of like, enjoy the journey. Am I doing things that I enjoy doing? So, we started a podcast last year. I mean, The Standard, like, so just a quick on timeframe, I mean, I spent a year building it. So, I did all this research for about two years, including hiring you guys. +I got to the place where I'm like, okay, I think I got a concept, not product-market fit. I just got a concept, and I want to start to build that out into reality. Hired a designer, really great designer. Found him, you know, cold-called him, got him involved. Took us six months to build literally, like, a wireframe of like, it could look like this. +And then I was like, okay, great. Now I'm going to go sell that to a VC and, like, convince him to give me millions of dollars. And I was like, and then I quickly realized, like, you absolutely have nothing at the moment, Chris. Like, there's nothing here. There's, like, you think you got something, like, you've got nothing. Like, there's no users. I mean, you got literally nothing here. And I was like, okay, great, so nobody's going to give me any money for this. Where do I go from here? +And then I was like, well, I need to build something to see how people interact with it. So, then I decided to go through a no-code platform when I spent ten months teaching myself how to build something using no-code. So, I used bubble.io, which was a really great product. Now, that was a big mind cluster right there because I'm not a coder. I'm sort of the visionary of a product. That's, like, I'm not the technical expertise. But I didn't have a CTO. So, I was like, I need to solve for this problem. So, I taught myself how to use this. +That was incredibly painful but incredibly rewarding because I know how to build something. So, then I built this, and then we beta test the launch, but now I'm like, okay, [inaudible 24:46] I built this, but I don't even know if it's a product-market fit. I don't even know if I built the right thing yet. Now, I got to see people who will interact with it. And then I was like, well, then how do you even get this thing to be exposed to the world? Like, it is just every step along the way; there's some mountain that seems insurmountable. You find a way to get to the peak, and then you realize there's a larger mountain that's [laughs] right behind it. +And so, then it led down to, like, how do I get people to be aware of what I built? Played around with that for six months. And then, I was like, I got to start a podcast, like, now I'll interview people. And so, it's just a constant iteration of, like, toying around with some stuff. And look, there's plenty of things I do that I'm like, that clearly fails. +And I think the question I ask myself a lot with the things that don't work is, did you give them enough time to be successful? Did you go about them in the right way and then decide to pivot? And, like, you won't always know all the answers to that. So, I think the point in giving sort of that timeline right there is it's a constant evolution, and you just do the best job you can and be okay with how the sort of the cards fall. +VICTORIA: Yeah. And if you fail or it doesn't work how you expect it, it's like, well, did I learn something? And did I have fun doing it? [laughs] +CHRIS: And if you take care of yourself along the way and you haven't sacrificed your own mental health and your well-being, your relationships with your kids, your partner, whoever it is, then at least you, like, if you fail, you're not like, and now I'm 30 pounds overweight. I'm miserable. My mental health is suffering. Like, you've got to balance that out. And so, I think that's going back to enjoying the journey as like, don't lose sight of the things that are really important. Building a company, yes, important, and for some people, it is really important. But at the end of the day, your health, your sanity are the most important things that you have. +And so, I see all too often that a lot of entrepreneurs and just people in general are willing to literally kick that to the curb to chase some prestige, some recognition, some financial gain. And look, man, like, you know, there's plenty of rich people out there that are completely miserable, that are unhappy. +I always think of Steve Jobs a lot. He had really lot of good...he did a commencement speech at Stanford when he was diagnosed with cancer. And, I mean, this is one of the most successful business people on our planet. Apple is the most successful company today at three trillion dollars or so market cap. And here's the visionary of the company. And when he was diagnosed with cancer, all he wanted was more time. It wasn't like, oh, I need more time to build another product. It's like the dude just wanted to be around longer. It didn't matter how many billions of dollars he had or products. Those were things that sort of fell to the wayside. It was all about his health. +So, point being is like, just over-indexing on success and not really looking at what is success; success is your mental health, your well-being. That is real success. +VICTORIA: Yeah. Wow. I can relate to that, too. I had, like, at a very young age, decided, oh, I'm going to be, like, an IT project manager. And then I got my PMP certification and I was like, oh, well, what do I do now? [laughs] What's the next thing? And it's just like, keep going and going and going. So, enjoy the moment, you know, love the journey, and prioritize that above those things. And that includes, like, learning, learning all these different parts of, like, how to build a business and how to build product. +It reminds me of a journey that we hear where you could have a great idea and you're like, oh, I need to design it, and then I need to build it. And then, like, a year later, you're like, wow, I haven't talked to any users yet [laughs]. It's like, I don't actually know anything about what people want. And that's a really difficult thing to do. +And it's a very emotional journey as well to go out and talk to people and try to ask questions in a way that doesn't give you false positives or false negatives and being able to leave your ego to the side and actually connect with people and hear about their problems. So, how has that been for you? Has there been anything in your discovery process that has surprised you and caused you to pivot in direction? +CHRIS: And although you didn't ask the question in this way, a recommendation I would have for a lot of people and, you know, if you read The Lean Startup, it's a good book. It's one worth reading. I read a lot of product books and stuff. I would say, like, imagine you have no money. How will you test your concept? Like, so, like, I came into building this with some capital behind me, my own capital. And it's just easy to spend money, and not that I was naive to think spending money you do need to invest in some things, but I wish I had a lot less money than I did coming into it because I would have spent a lot less money. +And I think you don't need a tremendous amount of money to start to get that user feedback that you're suggesting. I think there's some very organic ways that you could do it. And you really got to imagine, like, you have nothing. Like, how will you test this with $100? I was listening to a podcast episode the other day on the founder of Boston Dynamics. He was being interviewed, and it was a really cool one. Boston Dynamics is one of the leading robotic companies out there. +And this guy had, you know, started the company 30 years ago, and he was walking through some of his early days. And he's like, he was talking about building the pogo stick robot and how he only had, like, I think it was, like, it was either a hundred or a thousand dollars to, like, build this robot, or maybe it was 3,000. It was a really, really low amount. And he basically was trying to build a robot that, like, jumped up and down on, like, a benign budget himself. +It was a complete failure, but he learned some things through it. But he had enough success in that that when he then pitched that concept to the next person, I think it was, like, some congressional person, they gave him, like, a $250,000 budget, which was, like, back in 1980. But the point being is like, he had so little to start with, but he was still able to get some success. Versus if he had had 250,000, I don't know that he would have figured it out at that moment. He would have spent a lot more money. +And so, I think for entrepreneurs that are starting something out, you're so right: the product-market fit is huge. It's hard not to get false positives. It's hard not to just hear what you want to hear. And so, what I've learned is that, like, there's a difference between what people say and what people do. And what you need to be doing is paying attention to what people actually do, not what people say. +I interviewed lots of coaches across the planet. I'd share this idea. And, I mean, I had a phenomenal, like, 90% of them were like, "Chris, this is amazing." They would share some of their personal videos with me. And I'm like, wow, God, like, everybody thinks this is a great idea. And then, I started to realize like, it's probably because I'm decently looking. I can talk to people well. Like, there's a little bit of a me factor. I was like, well, what happens when I take me out of the equation? Will still 90% of people still think it's a good idea? And the answer was like, no. It completely changes. +If I'm not there to navigate or provide the narrative, which, as entrepreneurs and founders, we're typically the storyteller, but if you remove me and I just show you it, you'll be like, "Ah, it's cool." But, I don't have enough of the expertise in product design and the sticky factor. I haven't found the right combination for somebody just to interact with and be like, "This is pretty sweet. I want to use it." +So, going back to your original question, is like, you need to do more of that, and you need to learn how to do that stuff. I am still like you at surfing. I'm a novice at this. Like, I'm out there trying, but I am crashing all the time. And I am constantly trying to get back up and figure out how can I do this better and not provide an illusion that I'm getting it right, really paying attention to what do users actually like and not like? I am far from figuring that out. I'm still dedicated to doing it, but by no means have I hit a home run here. +VICTORIA: What keeps you motivated? What keeps you going and trying to solve that question? +CHRIS: You know, it goes back to an original statement I made with you is like, life is so hard for so many people. I jokingly will tell people, I said this a lot when I was interviewing coaches, is like, look, I'm very aware of my privilege. I'm a white, male who lives in Northern California in the U.S. I was born in the '80s. Like, I did not grow up with, like, this insurmountable, you know, adversity that I had to overcome. Like, there's a lot that was easier for me to obtain in my life. +And look, I work really hard. I am incredibly focused. I put in a lot of work. I'm very focused in that way. But I also just recognize, like, it might have been different if I was born somewhere else, if I looked a different way, if I didn't have access to the resources that I did. And so, my point with that statement is that I am a massive believer that whatever excess currencies you have, time, capital, energy, whatever it is, it is our obligation to help as many people on this planet in whatever way we think we can help them. +There are 800 million people on our planet that don't have clean drinking water, which is mind-boggling to me, considering the age we live in. I mean, we take it for granted you turn on the faucet and water comes out. That is a luxury that we have in living in the United States and in the Western Hemisphere. I mean, when you think about 800 million, that's almost 1 out of 8 people that don't have clean drinking water. And that's just drinking water, let alone access to vaccines or whatever you may choose. +And so, the point that I'm making is that for those of us that have excess of anything, and maybe it's just time, or maybe it is you have a lot of money, we should be doing the best job we can to help other people in the ways that we think would help them. For me, I'm focused on mental health and well-being. For somebody else, that might be providing good food, or medicine, or whatever it may be, and that's okay. We just need more people contributing to, hopefully, you know, lift as many people up to the point that we all have good lives. That's what keeps me going is the fact that, like, I don't take for granted for one second how easy my life is. +VICTORIA: I love that. And I like that you're trying to build technology that helps people and isn't just trying to, like, make the most money you can, or try to, like [laughs], flip it around or just share something that, you know, is really personal to you and, like, really is meaningful to you. So, I really appreciate you sharing that with me. What does success look like six months from now or even five years from now? +CHRIS: Look, success for me is pretty much what I've stated this whole episode is, like, I'm taking good care of myself. I'm very present in my life with my wife, my kids, my friends doing things that make Chris happy. That's what success looks like. +Now, clearly, we're here talking about The Standard and growing, and so I'd love to see more progress being made. I'd love to see more users on the platform. I'd like to be learning and figuring out, how do I help people share their story in a way that empowers them to share that story? How do I get people to want to share their story that don't feel like they have to be paid to do so? +You know, what I find so interesting when I talk to so many people and, you know, I ran 45 episodes of our podcast this year. So, I talked to a lot of people that have gone through some adversity, and they'll all say the same thing, "Dude, I will help anybody that is going through what I've..." Like, nobody wants to see somebody struggle, especially when you know how hard adversity is, whatever that may be for you. You don't want to see other people struggle because you know how painful that is. +I want to see people who are willing to quote, unquote, "give back" and say, "Look, if I can share a few things about how I've navigated my adversity, whatever that adversity is, because it will benefit other people going through this, I don't need to be paid for that. I just want to share it because it's sort of the right thing to do. It's sort of a pay it forward." I think in today's age, like, in the creator economy, like, everybody's like, "Well, I'm not going to help out unless I get paid." And, like, look, that might be a very privileged statement that I'm making, that I have the luxury. +But when I build The Standard, right or wrong, and some people would argue, "This is, like, the dumbest business model ever, Chris," is like, I don't think about monetization. Like, I'm not like, how do I get paid on this? Is it ads? Do I charge people? Like, I'm just trying to build something that I think actually will help people, and I'm trying to do it for the right reason. So, it's people before profit. But, at one point, there has to be money involved to some extent. But I don't put the money part first. I put the people. How do I get that right? +So, my hope would be, in 5, 3 years, whatever the time would be, is that more people buy into the message and they're like, look, if all it takes is me to spend 20, 30 minutes to create a couple of videos on my habits and share a little bit of my story, and there's a way to memorialize some of the things that I've learned for the benefit of other people going through it, that's great. That's a drop in the bucket of my time. That if enough people started to do that, it would send a signal to a wider swatch of our community, or people, or species that it's okay to share some of the things that make you who you are. And if you did that, it lets somebody else do that. +And if you get enough people doing that, you build a phenomenal habit bank, if you will, of just stories that other people can leverage for their own benefit. That would be success from my perspective. I try not to attach a certain amount of users. It's really just like, can I start to convince more and more people that you probably already have some information that would be really valuable to other people? +I'm just trying to organize it in a way that someone can find it, but I need people to share their story because the platform is not about me. Although I'm on it, it's not about Chris Pallatroni. It's about you. I mean, I'm sure you've gone through things in your life that you've learned, and you've navigated that. If you could share that in a way that was authentic and easily organized, other people would hear your story and be like, God damn, that's me too. I'm just trying to get more people to do that. That would be success in my mind. +VICTORIA: Well, it reminds me of a program I'm involved with. You might have heard of Big Sister, Little Sister, or Big Brother, Little Brother. It's a mentorship program. So, you have a one-on-one relationship with someone who's...like, the little sister I have really reminds me of myself when I was that age, like, you know, early high school awkwardness, trying to figure out how to navigate friendships and family life and getting a lot of pressure on, like, what are you going to do with your career? Even though you're still, like, really young. +So, it's interesting to think about how could you scale that and, like, have more content, like, take some of the little bits of conversations we have and, like, share that with other people who are going through the same thing. +CHRIS: Yeah, it's exactly that. And there's lots of stuff out there. I mean, you think of, like, you know, Alcoholics Anonymous like, in a lot of ways, that is it. Or people that have gone through school shootings, like, they find a lot of comfort in talking to other people that have navigated that. Like, there is no topic that does not touch mental health and well-being. Like, there's none. Like, I mean, I've read them all. +And so, it's just about taking people...and this is the beauty of it, like, sure, there are experts out there, Mel Robbins, Tony Robbins, you know, they've read. Their whole life is about self-development and empowerment. But if you take an average person somewhere in the world and maybe they have read notebooks on self-development or any of that, and you just start to dissect their experience as a human, what I know to be true is that they'll say, "I went through this," whatever this may be. And if you start to unravel the, how'd you cope with it? What did you learn? What habits did you develop? What mindsets did you develop? There is profound wisdom. +It may not be textbook. They may not understand the science behind it, but what they will share is something that is very real and that it's said in a very authentic way. And the words they use are incredibly powerful that if you could just capture that in a very authentic way and store it, and most importantly, find a way to organize it so it's easy for somebody to find, that's what this is about. And so, there's lots of this that exist out there. There's just no central mechanism that tries to tie this all together. And so, that's sort of what I'm attempting to do. +VICTORIA: That's really cool. Thank you so much for coming on and sharing your story and talking about what you've been building. Is there anything else that you would like to promote? +CHRIS: No, not at all. I mean, I would just say, like, if anybody's interested, like, the platform that we have is thestandardapp.com. It's not an app; that's just the URL for it. Or you can find us on pretty much any social channel. It's just The Standard. We do run a podcast, which is The Standard Podcast, where we interview a lot of the coaches. But any one of those things will give you a really good idea of what we're trying to do. And if you feel like you've got something of value, we'd always love for more people to come on and just share their story in a way that's authentic to them. And that's really what we're about. +VICTORIA: Awesome. Thank you so much. +You can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + Chris Pallatroni, The Standard, self-care stories, mental health, personal growth, entrepreneurship journey, gardening and wellness, storytelling platform, human connection, overcoming challenges, mental well-being, product-market fit, community support, inspirational narratives, life struggles + + In this episode, host Victoria Guido interviews Chris Pallatroni, creator of The Standard, a platform dedicated to sharing self-care stories. Chris shares how his interests in gardening and mental wellness fueled the inception of The Standard, which was initially intended to be a landscaping venture.

+ +

He delves into the hurdles faced while developing the platform, highlighting the struggle for product-market fit and the critical role of integrating technology with human connection to enable meaningful support and interactions.

+ +

Chris underscores storytelling's pivotal role in enhancing mental health, advocating for the sharing of personal triumphs over adversity to motivate and assist others facing similar challenges. He envisions The Standard as a vast collection of genuine, relatable self-care narratives aimed at reducing the feeling of isolation among individuals. Through inviting users to share their experiences, Chris seeks to leverage human connections to cultivate a community supportive of mental health and personal development.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Chris Pallatroni, Founder of The Standard, a storytelling platform where people share stories about self-care. Chris, thank you for joining me.

+ +

CHRIS: Yeah. Thanks for having me on. It's a pleasure.

+ +

VICTORIA: Wonderful. So, before we dive into all about The Standard, why don't you just tell me a little bit about what's going on in your world outside of work? Anything fun? Anything exciting?

+ +

CHRIS: Yeah. Well, first of all, I've got two boys, so for anybody that's listening that has kids, I mean, let's be honest, your life is completely chaotic. So, I've got two boys, one's almost 12, one's almost 10, so all boy, all the time. That's just another way of saying our house is really loud, and there's just tons of stuff happening, sports, whatnot. I also have a wife, a beautiful wife. She's my better half. I've been with her for 24 years. So, between that, I got three cats, not that they take a lot of energy, but there's just a lot of love in our household. So, that's sort of, like, the family side of things.

+ +

And then I'm an avid gardener. I'm really big into mental health and wellness, which, as we start to talk about The Standard, will become really evident. So, I'm all about just doing the things that you need to do to take care of yourself, so lots of running, lots of working out, lots of just being in nature. I know you're a surfer, so, I mean, let's be honest, water is amazing. So yeah, anything I can do to, like, duck out into nature and spend time with my family. Honestly, there's just not enough time in the day.

+ +

VICTORIA: What is growing in your garden that you're the most proud of?

+ +

CHRIS: You don't want to get me started on gardening. So, before I started The Standard, honestly, I thought I was going to be a landscaper, and the name of The Standard actually was going to be applied to a landscaping company. So, I am a professional landscaper. I took all the classes: soil, science, irrigation. I got the degree in design and maintenance.

+ +

I have a tiny, little property, but I have about 700 plants on my property. So, I know everything on the roses, and grass, and camellias. I mean, I'm that guy that, like, likes to see...nature is just amazing, first of all. And it also has very therapeutic qualities when we start to talk about mental health and well-being, birdsong, water, greenery, sunsets, sunrises.

+ +

I'm also developing a piece of land. We have a house we're building, and it's three acres. So, I'm in the process of building out, like, what I'm going to just describe as the most amazing garden anybody's ever seen. I really take a lot of pride in gardening. I'm very disciplined and very specific on how things grow. And so, I've got a property that's about an acre and a half I'm planting, which will probably have, like, 20,000 plants on it when it's all said and done.

+ +

VICTORIA: So, you have 700 plants now, and you plan to have 20,000, so you don't want to choose favorites. There's nothing...you got to, like, spread the love around.

+ +

CHRIS: God, it's like saying, which child do you love more? I mean, right now on my property the ones that currently stand out is I've got a couple of these Eden Rose bushes that I've trained to climb up. I've got three of them. The one in the front of my house is about 20 feet tall at this point. So, I've trained it to grow up the entire side of my house. In full bloom, it will have about 300 roses on it in full bloom. And so, an Eden Rose has about a 220 petal count. So, it's a very dense rose. They are a pain in the butt to prune, but they're pretty spectacular in full bloom.

+ +

VICTORIA: That sounds really beautiful. And I hope you send me some pictures [laughs] after the show. Send them to me in an email because I want to see...I love growing, but I do not have a green thumb. I usually try to pick what is most likely to survive [laughs].

+ +

CHRIS: That's my wife's strategy. She's like, what can I not kill? And, surprisingly, even with, like, cactuses, she still finds a way to kill some of them, so...[laughs]

+ +

VICTORIA: Some people have it, some people don't. I do agree on the therapeutic side. And I'm curious, too, having this background, how did you go from landscape and this interest in growing things to starting businesses?

+ +

CHRIS: Yeah, you know, the landscaping actually picked up at a much later stage. So, if I rewind my entrepreneurial journey, it started in 2004. I got mixed up with some guys as I was finishing up my degree in economics and finance. I was like, look, I don't have, like, a 4.9 GPA, so I'll probably need some sort of internship that starts to separate me. Anyways, got mixed up with some guys that were running a franchise painting company, took part in that, really loved the idea of seeing something grow. Did really well on that internship. You really ran, like, a mini-painting division of this larger company, so knocking on doors, producing painting jobs, so forth, and so on.

+ +

At the end of that, which was a really intense about a year internship, they said, "Hey, we're going to build this marketing company. Do you want in?" And I was like, "Let's do it." And so, what I really wanted...and that was, like, my first major let's start a business. And I loved the idea of taking something from an idea to...the idea was, could we sell it for a hundred million dollars? So, the money was attributed to it, but I wanted to see something grow.

+ +

And so, we went at it for, like, 15 years. We did end up selling, not at a hundred. We sold it for, like, 70 million. But we did really well. It was a bootstrapped company. We built this massive national marketing company. It's sort of like match.com for contracting. You can take a consumer that's interested in remodeling their house and connect them to a local contractor. And we built that all from, like, a bedroom with plyboard and literally rotary phones all the way to a national brand that's...I think we became the second largest in the space.

+ +

It's still the company I still work for. As I build this other business, I'm still working at that. We're pushing 250 million now. But the concept of building something and selling it I thought was really intriguing. Landscaping was just a hobby that came in much later in my life. Thought that was going to be my next venture. I decided to pivot after getting all of the education, mainly because I wanted to build something that had application for everybody.

+ +

And what I started to realize in landscaping is the average consumer doesn't have $50,000 to dump on their backyard. And what I didn't want to do is work for rich people and wineries. I really wanted to build a magical, little space for the average person. But I also started to realize most people don't have that type of income, which then pivoted me to The Standard, which I thought had more universal application.

+ +

VICTORIA: That's really interesting. So, I love that because there's, like, a common phrase you hear about tech where every company is also a tech company now. So, it's really interesting to hear and, like, to hear about you think about growth and how it applies to businesses and that care that you put into it as well.

+ +

CHRIS: Yeah. I mean, I think everything is tech-related in a lot of different ways. I don't know, I think at least with The Standard, like, there's such a human element, and I still need to figure out so much about it. But as tech-driven as we get, we're still a social species. We still want human connection. And maybe at one point far off in the future, like, a robot can replace some of that, but the human connection, the human story, the ability to feel connected and not isolated or alone has very profound impacts on people's mental health and well-being.

+ +

And so, as much as I still have to figure out, I try not to over-index on too much tech and try to keep things very authentic and organic. Because I think when you do that right and you can do the matching of a consumer that's interested in a specific story with someone that has gone through that experience who can share that story, that connection is very profound. So, I do think it is a blend of tech, but I try not to dive too deep into the tech side of things.

+ +

VICTORIA: Right. It's more that you need technology as a tool to solve the problems of the people that you're trying to work for or trying to, like, provide services for. So, it sounds like, to recap a little bit, you were part of growing this company. You were able to build it and sell it for 70 million. And then, you decided to, like, keep doing it. You're like, that was fun. Let's do another one [laughs].

+ +

CHRIS: Well, I mean, in all honesty, I think some of the challenges become when you're starting a company, which is incredibly invigorating. But if you're starting a company in an area that you don't have expertise...so, although I know a lot about mental health and wellness, I've read hundreds of books. I interviewed lots of people. I hired you guys to do some market research for me. So, I'm not naive, but I've never built a platform that does what I'm trying to do. And in all my research, I haven't exactly even seen a platform that does exactly what I do. So, it's hard to have that perfect measuring stick.

+ +

And so, you know, what I've realized along the journey is it's really easy to spend money, and it's really hard to find product-market fit. And so, what I've chosen to do, and maybe it takes a little bit longer to get there, is rather than, like, go all in, quit my day job, and really just financially stress the crap out of myself and my wife, I still have a day job. I get paid exceptionally well. I'm very senior in my company. It's not overly stressful, but it also pays the bills.

+ +

And so, I think one of the things I've learned about being an entrepreneur is you've got to enjoy the journey. And so, I do enjoy what I still do, and it serves a very valuable purpose. And it gives me still the freedom to play around with The Standard, to still do the things that I want to do. Sure, I can't burn as many hours on it, but at the same time, if I quit this job, my runway would highly compress, and maybe that's good for some people, but there's still just so much I have to figure out. So, I need the runway.

+ +

VICTORIA: I can relate to that, and I think that's a really common story for people who have a great idea, and they need the time and space to find the right product-market fit to move forward and then make the big investment with your time and all the, like, other financial investments you would need. So, maybe to go back to the beginning a little bit, what led you to think of starting The Standard in the first place?

+ +

CHRIS: So, I'll try to say this as succinctly as possible. Life is really hard for a lot of people, you know, and you can dice it up in a lot of different ways, whether we're talking about, like, you know, global events that happen, be it war, be it COVID, you know, anything on a very large level. But even on an individual level, like, we lose people. People are dealing with weight issues, how to eat healthy, stress. There's a lot.

+ +

When we start to think about the concept of mental health and well-being, it is overwhelming. And I'm built for discipline. I've always been that way. I'm incredibly disciplined as a person. Some things may feel like they come a little easier to me, but I also look at like, oh my God, I got to worry about like, how do I sleep right? And how do I eat right? And then, how do I exercise? And then you got to be grateful for stuff, and then have social friends, and then be with your family. Like, I mean, adulting is tough; let's just be honest.

+ +

And so, a lot of the concept behind The Standard was I have the freedom to explore a lot of this stuff. I've had the luxury to read hundreds of books and, meet so many people, and really invest a lot as to educating myself about these various topics that I think are important.

+ +

I also have the luxury to deploy a lot of these strategies in my personal life, and it's a privilege to be able to do that. And a lot of people don't have that. They're struggling. They're working multiple jobs. They don't have a lot of time in the day. Maybe they're commuting. They don't have the luxury to take care of themselves. And that's just the Western world. Do you want to, like, dive into the Global South or start to look at, like, Ukraine or stuff like that? Like, there's just people, like, literally just trying to make it through the day, let alone be grateful about something or eat healthy.

+ +

And so, I started to realize, like, God, if I think this is even remotely challenging, what does somebody else feel about their mental health and well-being? And so, that was sort of the jump off of, like, it is tough to maintain your sanity. It is tough to do all of those things. Is there a way that I can make that process easier for people? And so, that just led to a rabbit hole that started about six months before COVID hit, so late 2019. I spent a lot of time researching.

+ +

I read several hundred books on habit formation and neuroscience and all these different topics. And, I mean, to the point where I was reading every morning, typing notes of these books, mind mapping this out, looking for the connection of all these topics. And what I was trying to figure out is what is the least amount of information somebody needs to know to have the most profound effect on their life? And what I came to as a conclusion was most people will not read a book or listen to a podcast. Some will, but the average person won't. They don't have the time, the desire.

+ +

But everybody's got a problem they're trying to solve, whatever that problem may be, and if you could take somebody that has a problem and you could find a way to connect them to somebody who had that problem but is a little farther down the road. So, let's pick something pretty simple, like weight loss. I've interviewed a lot of people on my podcast this year that have lost 100 pounds, which is a really big number. And even if it's not a hundred pounds, you want to lose 20 pounds. The point being is that weight is a big issue for a lot of people. It affects their self-esteem, their body image. There's a number of things that, like, impact that.

+ +

But if you could connect somebody who's really struggling to lose weight with somebody who has lost that weight and could share their story, how they felt, the habits they've deployed, and most importantly, they could talk about that experience, what would happen is the person that's been through that issue, if you will, would use a set of language that would be very specific and would resonate with the person that hasn't overcome the challenge yet.

+ +

And this is what's so unique about it is: I don't know what that particular challenge is like. I've never had that particular issue. I won't know the language to use. But if you've ever talked to somebody who has lost a significant amount of weight, they will use words, and they will give examples that only somebody who's struggling with it would resonate with.

+ +

I remember doing an interview, and a lady was like, "God, you know," she's like, "I was so overweight. I would be very thoughtful of getting on the ground because I wasn't sure if I could get back up. Or I'd be very thoughtful of the chair I sat on in case it broke." I mean, these are the things I'm like, unless you're overweight, you don't think about that.

+ +

And so, my idea was like, could I take somebody who's overcome some of these problems, get them to share some of those self-care stories that they used to solve whatever that problem was, and then create a mechanism in which somebody who was struggling with, in this case, weight loss, that they could type in, "How do you deal with weight loss?" and they could connect to other people that have developed the habits and the mindsets that helped them through that? And weight loss is just an example, but you could pick anything from racism to depression to domestic violence and so forth and so on.

+ +

The caveat there is you need a mechanism to connect the person that's overcome the challenge with the person that's still going through it. So, you got to get a lot of people on the other side of the tunnel to share their story and to know that they're doing it maybe not to monetize it but to do it for the benefit of other people who were like them at one point.

+ +

VICTORIA: Yeah, if I can try to summarize what you meant when you said, like, what's the least amount of information to have the most profound realization on how to impact your life? It sounds like what you discovered was that it's human connection to other humans who have had the same experience and survived it and overcome those challenges.

+ +

CHRIS: Yeah, without a doubt, because I think when you're struggling with an issue, you tend to think you're alone. You tend to think the way you're thinking about your addiction to something, or your weight loss, or your body image; you tend to think, oh, this is just me. And what motivates somebody who's in that mindset is to hear somebody else who can use a certain set of language that helps them realize, wow, I'm not alone. There is other people that have gone through this particular issue. And what that does is it starts to open up the door, open up their mind in a way of, wow, change can happen.

+ +

Now, you can't copy other people's habits. It doesn't exactly work that way. But what it can do is at least give you a starting place to say, "Here's somebody who I feel is like me in some ways, and they've made it to the other side. Here's some of the habits, and the mindsets, routines that they specifically have that have helped them get through this. Maybe I can try some of those on, at least as a starting place, and then I can modify them as time..."

+ +

So, it really starts with the mindset and the clarity of I'm not alone and maybe there is some hope. And I think that's a really big thing when you're talking about some of these very large issues that people run into on a day-to-day basis.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So, what lessons did you learn from your previous experience in starting a business are you taking into what you're doing now with The Standard?

+ +

CHRIS: Oh my God, so many lessons. Well, I mean, here's the brutal reality is: I've chosen to go in an industry that doesn't exactly have carryover effects. I was in marketing, dealing with homeowners and contractors, and now I'm diving into mental health. So, I, unfortunately, don't get to, like, flex my black book and, you know, voilà myself into, like, success here. I've also chosen to go from marketing and generating leads to now I'm trying to build a platform, which apparently is one of the hardest things you could possibly do.

+ +

But here's one that I really do take away, and it's probably not in the way that you actually intended that I would answer, but here's the biggest lesson I've taken away. When I built the first company, Jason Polka was our CEO, and Gabe Luna...it was three of us that really started it. So much of that entire journey...especially after the first five years of building the infrastructure, and you started to move out of the basement, and you had a corporate office, and, you know, you felt a little bit more legit. You started generating 10, 20 million dollars a year in revenue.

+ +

I'd say from year, like, five through the time we sold it, I just wanted to sell the company. So much of the conversation became around, when is this going to happen? And it was always a grind. I mean, building a company is just tough. I mean, maybe some people, it works out, and everything's great, but it's really tough. A lot of businesses don't succeed, and we were very lucky that we did.

+ +

But so much of it was me just trying to check off that final box of, like, I just want them to say, "We did it." It wasn't even really the payout. It was, just, I want to know that we were capable of doing it. And what happened is there was so much of that ten years where I wasn't enjoying the journey. I mean, don't get me wrong, like, I love the people I worked with, some great friendships. But it was so much of like, how do we fast forward this a little bit?

+ +

And so, once the day happened that it was sold, and especially as I started to embark on this other side, I said, look, I'm now in my, like, early 40s. Like, that can't happen again. I mean, maybe I never sell the next company. Maybe I'm working on this for a decade or two decades. I need to enjoy the journey. Like, my kids are young once. Like, I've got this wife. I've got this life. Like, selling a company is great, but it is not the defining thing of your life. Like, you still need to live your life.

+ +

And so, the big lesson I took away from it is how do I enjoy the journey as I go through this process? And I'll be honest, that is a big mind f, if you will, like, it's not an easy thing to do because as entrepreneurs, you're very much like, well, what metrics, and what's the next milestone? And dah, dah, dah, dah. And, like, dude, it's brutal. So, I'm really trying to, like, enjoy the process, even if the process is a struggle.

+ +

VICTORIA: What are your top strategies for enjoying the process or making it fun?

+ +

CHRIS: Well, one, take care of your mental health and your well-being [laughs], whatever that is for you. I do a lot of weekly planning. And so, when I do my weekly planning, it literally will come down to I look at my schedule, and I make sure I get my runs in there. I get my gardening in there. I get my time at my kids' events, my time with my wife. I get my workouts. I make sure I eat healthy. I do everything that I can to take as good of care of Chris as I possibly can. You know, a cliché is to say, but you can't pour from an empty cup.

+ +

So, if you want to give your best to your company, your family, your friends, your community, whatever, like, you really do need to prioritize yourself. Self-care is not selfish. So, that's the number one thing I do.

+ +

I'd say the other thing, too, is how do you deal with anxiety? How do you deal with this constant...and anxiety is one of the most pronounced mental health issues on our planet. 350 million people deal with this annually. It's easy to start to think about the future and to fill in the gap with the worst-case scenario, to get anxiety of, like, oh my God, I didn't do this, or I shouldn't be doing that.

+ +

And so, learning to just take a deep breath, do the best job you can. Let your intuition carry you, and not be so judgmental when it doesn't turn out the way you want it. Like, I wish I had much more success at this stage of the business than I do. But I'm still making forward progress, and I'm enjoying the process, and I'm learning stuff. And could I be faster? Yeah, probably.

+ +

So, I try not to over-index on what I'm not doing, and I try to just take the best next step possible and just trust it will all work out but be okay if it didn't. That's easier said than done sometimes, especially if you've never had success. I think part of it is the fact that I've been successful in selling a company. I mean, in a lot of ways, like, hey, I know I could. Maybe I can do it again. Maybe I can't. And I'm okay either way that that pans out.

+ +

VICTORIA: I think that part about being okay if it doesn't is so important. And tying that together to what you mentioned earlier about being financially stable enough to invest in what you want to invest in, like, it's a really big, important thing for founders. And I think if you're constantly worried about how am I going to pay myself? How am I going to pay my bills? You're not really going to be focused on building the best product, or actually solving the problem, or being willing to pivot in a way you need to to create something that is going to last and be really impactful for people. I think that's really interesting.

+ +

In climbing, there's some...it teaches me that because I have some projects that probably I might never complete them [laughs]. They're really hard. The people who actually create videos of themselves climbing it are, like, six feet tall, and I'm never going to be six feet tall, but I just try to enjoy the hike up to the climb. I enjoy going up to this little boulder and just, like, touching it and feeling it.

+ +

So, I'm curious if you could say more about how are you thinking The Standard will solve that problem and, like, create that connection for you and, like, solve your anxieties as, like, a founder about, is this company working well enough? Do you connect people in that same way as well?

+ +

CHRIS: There's a famous quote that says, "It takes seven years to become an overnight success." I mean, maybe in some ways, it even takes longer, depending on what you're trying to build here. And, I don't know, success is somewhat arbitrary. You know, like, I remember when I got the call that we sold our first company, which was the moment I was waiting for, I remember getting the call. I was driving home. "Hey, we did this. Here's your payout." I did not feel any more successful in that moment. Like, it wasn't like that checked off the box. I'm like, well, there I go. I'm super successful now. It was like, now what?

+ +

You know, my kids didn't, like, hug me and be like, "Oh, successful dad sold companies," you know, it wasn't. It was like, you know, life continued. And it was just such a powerful reminder of so much of the significance that we put on things is like, it's us. Like, I don't want to say nobody else cares because, you know, a lot of entrepreneurs are trying to build products that, you know, change the world, make a meaningful difference to people's lives. And we do put a disproportionate burden on ourselves of, like, God, if I don't do this, maybe it just doesn't get done.

+ +

I think, for me, when I'm building The Standard, I try to, one, I always try to think of like, enjoy the journey. Am I doing things that I enjoy doing? So, we started a podcast last year. I mean, The Standard, like, so just a quick on timeframe, I mean, I spent a year building it. So, I did all this research for about two years, including hiring you guys.

+ +

I got to the place where I'm like, okay, I think I got a concept, not product-market fit. I just got a concept, and I want to start to build that out into reality. Hired a designer, really great designer. Found him, you know, cold-called him, got him involved. Took us six months to build literally, like, a wireframe of like, it could look like this.

+ +

And then I was like, okay, great. Now I'm going to go sell that to a VC and, like, convince him to give me millions of dollars. And I was like, and then I quickly realized, like, you absolutely have nothing at the moment, Chris. Like, there's nothing here. There's, like, you think you got something, like, you've got nothing. Like, there's no users. I mean, you got literally nothing here. And I was like, okay, great, so nobody's going to give me any money for this. Where do I go from here?

+ +

And then I was like, well, I need to build something to see how people interact with it. So, then I decided to go through a no-code platform when I spent ten months teaching myself how to build something using no-code. So, I used bubble.io, which was a really great product. Now, that was a big mind cluster right there because I'm not a coder. I'm sort of the visionary of a product. That's, like, I'm not the technical expertise. But I didn't have a CTO. So, I was like, I need to solve for this problem. So, I taught myself how to use this.

+ +

That was incredibly painful but incredibly rewarding because I know how to build something. So, then I built this, and then we beta test the launch, but now I'm like, okay, [inaudible 24:46] I built this, but I don't even know if it's a product-market fit. I don't even know if I built the right thing yet. Now, I got to see people who will interact with it. And then I was like, well, then how do you even get this thing to be exposed to the world? Like, it is just every step along the way; there's some mountain that seems insurmountable. You find a way to get to the peak, and then you realize there's a larger mountain that's [laughs] right behind it.

+ +

And so, then it led down to, like, how do I get people to be aware of what I built? Played around with that for six months. And then, I was like, I got to start a podcast, like, now I'll interview people. And so, it's just a constant iteration of, like, toying around with some stuff. And look, there's plenty of things I do that I'm like, that clearly fails.

+ +

And I think the question I ask myself a lot with the things that don't work is, did you give them enough time to be successful? Did you go about them in the right way and then decide to pivot? And, like, you won't always know all the answers to that. So, I think the point in giving sort of that timeline right there is it's a constant evolution, and you just do the best job you can and be okay with how the sort of the cards fall.

+ +

VICTORIA: Yeah. And if you fail or it doesn't work how you expect it, it's like, well, did I learn something? And did I have fun doing it? [laughs]

+ +

CHRIS: And if you take care of yourself along the way and you haven't sacrificed your own mental health and your well-being, your relationships with your kids, your partner, whoever it is, then at least you, like, if you fail, you're not like, and now I'm 30 pounds overweight. I'm miserable. My mental health is suffering. Like, you've got to balance that out. And so, I think that's going back to enjoying the journey as like, don't lose sight of the things that are really important. Building a company, yes, important, and for some people, it is really important. But at the end of the day, your health, your sanity are the most important things that you have.

+ +

And so, I see all too often that a lot of entrepreneurs and just people in general are willing to literally kick that to the curb to chase some prestige, some recognition, some financial gain. And look, man, like, you know, there's plenty of rich people out there that are completely miserable, that are unhappy.

+ +

I always think of Steve Jobs a lot. He had really lot of good...he did a commencement speech at Stanford when he was diagnosed with cancer. And, I mean, this is one of the most successful business people on our planet. Apple is the most successful company today at three trillion dollars or so market cap. And here's the visionary of the company. And when he was diagnosed with cancer, all he wanted was more time. It wasn't like, oh, I need more time to build another product. It's like the dude just wanted to be around longer. It didn't matter how many billions of dollars he had or products. Those were things that sort of fell to the wayside. It was all about his health.

+ +

So, point being is like, just over-indexing on success and not really looking at what is success; success is your mental health, your well-being. That is real success.

+ +

VICTORIA: Yeah. Wow. I can relate to that, too. I had, like, at a very young age, decided, oh, I'm going to be, like, an IT project manager. And then I got my PMP certification and I was like, oh, well, what do I do now? [laughs] What's the next thing? And it's just like, keep going and going and going. So, enjoy the moment, you know, love the journey, and prioritize that above those things. And that includes, like, learning, learning all these different parts of, like, how to build a business and how to build product.

+ +

It reminds me of a journey that we hear where you could have a great idea and you're like, oh, I need to design it, and then I need to build it. And then, like, a year later, you're like, wow, I haven't talked to any users yet [laughs]. It's like, I don't actually know anything about what people want. And that's a really difficult thing to do.

+ +

And it's a very emotional journey as well to go out and talk to people and try to ask questions in a way that doesn't give you false positives or false negatives and being able to leave your ego to the side and actually connect with people and hear about their problems. So, how has that been for you? Has there been anything in your discovery process that has surprised you and caused you to pivot in direction?

+ +

CHRIS: And although you didn't ask the question in this way, a recommendation I would have for a lot of people and, you know, if you read The Lean Startup, it's a good book. It's one worth reading. I read a lot of product books and stuff. I would say, like, imagine you have no money. How will you test your concept? Like, so, like, I came into building this with some capital behind me, my own capital. And it's just easy to spend money, and not that I was naive to think spending money you do need to invest in some things, but I wish I had a lot less money than I did coming into it because I would have spent a lot less money.

+ +

And I think you don't need a tremendous amount of money to start to get that user feedback that you're suggesting. I think there's some very organic ways that you could do it. And you really got to imagine, like, you have nothing. Like, how will you test this with $100? I was listening to a podcast episode the other day on the founder of Boston Dynamics. He was being interviewed, and it was a really cool one. Boston Dynamics is one of the leading robotic companies out there.

+ +

And this guy had, you know, started the company 30 years ago, and he was walking through some of his early days. And he's like, he was talking about building the pogo stick robot and how he only had, like, I think it was, like, it was either a hundred or a thousand dollars to, like, build this robot, or maybe it was 3,000. It was a really, really low amount. And he basically was trying to build a robot that, like, jumped up and down on, like, a benign budget himself.

+ +

It was a complete failure, but he learned some things through it. But he had enough success in that that when he then pitched that concept to the next person, I think it was, like, some congressional person, they gave him, like, a $250,000 budget, which was, like, back in 1980. But the point being is like, he had so little to start with, but he was still able to get some success. Versus if he had had 250,000, I don't know that he would have figured it out at that moment. He would have spent a lot more money.

+ +

And so, I think for entrepreneurs that are starting something out, you're so right: the product-market fit is huge. It's hard not to get false positives. It's hard not to just hear what you want to hear. And so, what I've learned is that, like, there's a difference between what people say and what people do. And what you need to be doing is paying attention to what people actually do, not what people say.

+ +

I interviewed lots of coaches across the planet. I'd share this idea. And, I mean, I had a phenomenal, like, 90% of them were like, "Chris, this is amazing." They would share some of their personal videos with me. And I'm like, wow, God, like, everybody thinks this is a great idea. And then, I started to realize like, it's probably because I'm decently looking. I can talk to people well. Like, there's a little bit of a me factor. I was like, well, what happens when I take me out of the equation? Will still 90% of people still think it's a good idea? And the answer was like, no. It completely changes.

+ +

If I'm not there to navigate or provide the narrative, which, as entrepreneurs and founders, we're typically the storyteller, but if you remove me and I just show you it, you'll be like, "Ah, it's cool." But, I don't have enough of the expertise in product design and the sticky factor. I haven't found the right combination for somebody just to interact with and be like, "This is pretty sweet. I want to use it."

+ +

So, going back to your original question, is like, you need to do more of that, and you need to learn how to do that stuff. I am still like you at surfing. I'm a novice at this. Like, I'm out there trying, but I am crashing all the time. And I am constantly trying to get back up and figure out how can I do this better and not provide an illusion that I'm getting it right, really paying attention to what do users actually like and not like? I am far from figuring that out. I'm still dedicated to doing it, but by no means have I hit a home run here.

+ +

VICTORIA: What keeps you motivated? What keeps you going and trying to solve that question?

+ +

CHRIS: You know, it goes back to an original statement I made with you is like, life is so hard for so many people. I jokingly will tell people, I said this a lot when I was interviewing coaches, is like, look, I'm very aware of my privilege. I'm a white, male who lives in Northern California in the U.S. I was born in the '80s. Like, I did not grow up with, like, this insurmountable, you know, adversity that I had to overcome. Like, there's a lot that was easier for me to obtain in my life.

+ +

And look, I work really hard. I am incredibly focused. I put in a lot of work. I'm very focused in that way. But I also just recognize, like, it might have been different if I was born somewhere else, if I looked a different way, if I didn't have access to the resources that I did. And so, my point with that statement is that I am a massive believer that whatever excess currencies you have, time, capital, energy, whatever it is, it is our obligation to help as many people on this planet in whatever way we think we can help them.

+ +

There are 800 million people on our planet that don't have clean drinking water, which is mind-boggling to me, considering the age we live in. I mean, we take it for granted you turn on the faucet and water comes out. That is a luxury that we have in living in the United States and in the Western Hemisphere. I mean, when you think about 800 million, that's almost 1 out of 8 people that don't have clean drinking water. And that's just drinking water, let alone access to vaccines or whatever you may choose.

+ +

And so, the point that I'm making is that for those of us that have excess of anything, and maybe it's just time, or maybe it is you have a lot of money, we should be doing the best job we can to help other people in the ways that we think would help them. For me, I'm focused on mental health and well-being. For somebody else, that might be providing good food, or medicine, or whatever it may be, and that's okay. We just need more people contributing to, hopefully, you know, lift as many people up to the point that we all have good lives. That's what keeps me going is the fact that, like, I don't take for granted for one second how easy my life is.

+ +

VICTORIA: I love that. And I like that you're trying to build technology that helps people and isn't just trying to, like, make the most money you can, or try to, like [laughs], flip it around or just share something that, you know, is really personal to you and, like, really is meaningful to you. So, I really appreciate you sharing that with me. What does success look like six months from now or even five years from now?

+ +

CHRIS: Look, success for me is pretty much what I've stated this whole episode is, like, I'm taking good care of myself. I'm very present in my life with my wife, my kids, my friends doing things that make Chris happy. That's what success looks like.

+ +

Now, clearly, we're here talking about The Standard and growing, and so I'd love to see more progress being made. I'd love to see more users on the platform. I'd like to be learning and figuring out, how do I help people share their story in a way that empowers them to share that story? How do I get people to want to share their story that don't feel like they have to be paid to do so?

+ +

You know, what I find so interesting when I talk to so many people and, you know, I ran 45 episodes of our podcast this year. So, I talked to a lot of people that have gone through some adversity, and they'll all say the same thing, "Dude, I will help anybody that is going through what I've..." Like, nobody wants to see somebody struggle, especially when you know how hard adversity is, whatever that may be for you. You don't want to see other people struggle because you know how painful that is.

+ +

I want to see people who are willing to quote, unquote, "give back" and say, "Look, if I can share a few things about how I've navigated my adversity, whatever that adversity is, because it will benefit other people going through this, I don't need to be paid for that. I just want to share it because it's sort of the right thing to do. It's sort of a pay it forward." I think in today's age, like, in the creator economy, like, everybody's like, "Well, I'm not going to help out unless I get paid." And, like, look, that might be a very privileged statement that I'm making, that I have the luxury.

+ +

But when I build The Standard, right or wrong, and some people would argue, "This is, like, the dumbest business model ever, Chris," is like, I don't think about monetization. Like, I'm not like, how do I get paid on this? Is it ads? Do I charge people? Like, I'm just trying to build something that I think actually will help people, and I'm trying to do it for the right reason. So, it's people before profit. But, at one point, there has to be money involved to some extent. But I don't put the money part first. I put the people. How do I get that right?

+ +

So, my hope would be, in 5, 3 years, whatever the time would be, is that more people buy into the message and they're like, look, if all it takes is me to spend 20, 30 minutes to create a couple of videos on my habits and share a little bit of my story, and there's a way to memorialize some of the things that I've learned for the benefit of other people going through it, that's great. That's a drop in the bucket of my time. That if enough people started to do that, it would send a signal to a wider swatch of our community, or people, or species that it's okay to share some of the things that make you who you are. And if you did that, it lets somebody else do that.

+ +

And if you get enough people doing that, you build a phenomenal habit bank, if you will, of just stories that other people can leverage for their own benefit. That would be success from my perspective. I try not to attach a certain amount of users. It's really just like, can I start to convince more and more people that you probably already have some information that would be really valuable to other people?

+ +

I'm just trying to organize it in a way that someone can find it, but I need people to share their story because the platform is not about me. Although I'm on it, it's not about Chris Pallatroni. It's about you. I mean, I'm sure you've gone through things in your life that you've learned, and you've navigated that. If you could share that in a way that was authentic and easily organized, other people would hear your story and be like, God damn, that's me too. I'm just trying to get more people to do that. That would be success in my mind.

+ +

VICTORIA: Well, it reminds me of a program I'm involved with. You might have heard of Big Sister, Little Sister, or Big Brother, Little Brother. It's a mentorship program. So, you have a one-on-one relationship with someone who's...like, the little sister I have really reminds me of myself when I was that age, like, you know, early high school awkwardness, trying to figure out how to navigate friendships and family life and getting a lot of pressure on, like, what are you going to do with your career? Even though you're still, like, really young.

+ +

So, it's interesting to think about how could you scale that and, like, have more content, like, take some of the little bits of conversations we have and, like, share that with other people who are going through the same thing.

+ +

CHRIS: Yeah, it's exactly that. And there's lots of stuff out there. I mean, you think of, like, you know, Alcoholics Anonymous like, in a lot of ways, that is it. Or people that have gone through school shootings, like, they find a lot of comfort in talking to other people that have navigated that. Like, there is no topic that does not touch mental health and well-being. Like, there's none. Like, I mean, I've read them all.

+ +

And so, it's just about taking people...and this is the beauty of it, like, sure, there are experts out there, Mel Robbins, Tony Robbins, you know, they've read. Their whole life is about self-development and empowerment. But if you take an average person somewhere in the world and maybe they have read notebooks on self-development or any of that, and you just start to dissect their experience as a human, what I know to be true is that they'll say, "I went through this," whatever this may be. And if you start to unravel the, how'd you cope with it? What did you learn? What habits did you develop? What mindsets did you develop? There is profound wisdom.

+ +

It may not be textbook. They may not understand the science behind it, but what they will share is something that is very real and that it's said in a very authentic way. And the words they use are incredibly powerful that if you could just capture that in a very authentic way and store it, and most importantly, find a way to organize it so it's easy for somebody to find, that's what this is about. And so, there's lots of this that exist out there. There's just no central mechanism that tries to tie this all together. And so, that's sort of what I'm attempting to do.

+ +

VICTORIA: That's really cool. Thank you so much for coming on and sharing your story and talking about what you've been building. Is there anything else that you would like to promote?

+ +

CHRIS: No, not at all. I mean, I would just say, like, if anybody's interested, like, the platform that we have is thestandardapp.com. It's not an app; that's just the URL for it. Or you can find us on pretty much any social channel. It's just The Standard. We do run a podcast, which is The Standard Podcast, where we interview a lot of the coaches. But any one of those things will give you a really good idea of what we're trying to do. And if you feel like you've got something of value, we'd always love for more people to come on and just share their story in a way that's authentic to them. And that's really what we're about.

+ +

VICTORIA: Awesome. Thank you so much.

+ +

You can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, host Victoria Guido interviews Chris Pallatroni, creator of The Standard, a platform dedicated to sharing self-care stories. Chris shares how his interests in gardening and mental wellness fueled the inception of The Standard, which was initially intended to be a landscaping venture.

+ +

He delves into the hurdles faced while developing the platform, highlighting the struggle for product-market fit and the critical role of integrating technology with human connection to enable meaningful support and interactions.

+ +

Chris underscores storytelling's pivotal role in enhancing mental health, advocating for the sharing of personal triumphs over adversity to motivate and assist others facing similar challenges. He envisions The Standard as a vast collection of genuine, relatable self-care narratives aimed at reducing the feeling of isolation among individuals. Through inviting users to share their experiences, Chris seeks to leverage human connections to cultivate a community supportive of mental health and personal development.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Chris Pallatroni, Founder of The Standard, a storytelling platform where people share stories about self-care. Chris, thank you for joining me.

+ +

CHRIS: Yeah. Thanks for having me on. It's a pleasure.

+ +

VICTORIA: Wonderful. So, before we dive into all about The Standard, why don't you just tell me a little bit about what's going on in your world outside of work? Anything fun? Anything exciting?

+ +

CHRIS: Yeah. Well, first of all, I've got two boys, so for anybody that's listening that has kids, I mean, let's be honest, your life is completely chaotic. So, I've got two boys, one's almost 12, one's almost 10, so all boy, all the time. That's just another way of saying our house is really loud, and there's just tons of stuff happening, sports, whatnot. I also have a wife, a beautiful wife. She's my better half. I've been with her for 24 years. So, between that, I got three cats, not that they take a lot of energy, but there's just a lot of love in our household. So, that's sort of, like, the family side of things.

+ +

And then I'm an avid gardener. I'm really big into mental health and wellness, which, as we start to talk about The Standard, will become really evident. So, I'm all about just doing the things that you need to do to take care of yourself, so lots of running, lots of working out, lots of just being in nature. I know you're a surfer, so, I mean, let's be honest, water is amazing. So yeah, anything I can do to, like, duck out into nature and spend time with my family. Honestly, there's just not enough time in the day.

+ +

VICTORIA: What is growing in your garden that you're the most proud of?

+ +

CHRIS: You don't want to get me started on gardening. So, before I started The Standard, honestly, I thought I was going to be a landscaper, and the name of The Standard actually was going to be applied to a landscaping company. So, I am a professional landscaper. I took all the classes: soil, science, irrigation. I got the degree in design and maintenance.

+ +

I have a tiny, little property, but I have about 700 plants on my property. So, I know everything on the roses, and grass, and camellias. I mean, I'm that guy that, like, likes to see...nature is just amazing, first of all. And it also has very therapeutic qualities when we start to talk about mental health and well-being, birdsong, water, greenery, sunsets, sunrises.

+ +

I'm also developing a piece of land. We have a house we're building, and it's three acres. So, I'm in the process of building out, like, what I'm going to just describe as the most amazing garden anybody's ever seen. I really take a lot of pride in gardening. I'm very disciplined and very specific on how things grow. And so, I've got a property that's about an acre and a half I'm planting, which will probably have, like, 20,000 plants on it when it's all said and done.

+ +

VICTORIA: So, you have 700 plants now, and you plan to have 20,000, so you don't want to choose favorites. There's nothing...you got to, like, spread the love around.

+ +

CHRIS: God, it's like saying, which child do you love more? I mean, right now on my property the ones that currently stand out is I've got a couple of these Eden Rose bushes that I've trained to climb up. I've got three of them. The one in the front of my house is about 20 feet tall at this point. So, I've trained it to grow up the entire side of my house. In full bloom, it will have about 300 roses on it in full bloom. And so, an Eden Rose has about a 220 petal count. So, it's a very dense rose. They are a pain in the butt to prune, but they're pretty spectacular in full bloom.

+ +

VICTORIA: That sounds really beautiful. And I hope you send me some pictures [laughs] after the show. Send them to me in an email because I want to see...I love growing, but I do not have a green thumb. I usually try to pick what is most likely to survive [laughs].

+ +

CHRIS: That's my wife's strategy. She's like, what can I not kill? And, surprisingly, even with, like, cactuses, she still finds a way to kill some of them, so...[laughs]

+ +

VICTORIA: Some people have it, some people don't. I do agree on the therapeutic side. And I'm curious, too, having this background, how did you go from landscape and this interest in growing things to starting businesses?

+ +

CHRIS: Yeah, you know, the landscaping actually picked up at a much later stage. So, if I rewind my entrepreneurial journey, it started in 2004. I got mixed up with some guys as I was finishing up my degree in economics and finance. I was like, look, I don't have, like, a 4.9 GPA, so I'll probably need some sort of internship that starts to separate me. Anyways, got mixed up with some guys that were running a franchise painting company, took part in that, really loved the idea of seeing something grow. Did really well on that internship. You really ran, like, a mini-painting division of this larger company, so knocking on doors, producing painting jobs, so forth, and so on.

+ +

At the end of that, which was a really intense about a year internship, they said, "Hey, we're going to build this marketing company. Do you want in?" And I was like, "Let's do it." And so, what I really wanted...and that was, like, my first major let's start a business. And I loved the idea of taking something from an idea to...the idea was, could we sell it for a hundred million dollars? So, the money was attributed to it, but I wanted to see something grow.

+ +

And so, we went at it for, like, 15 years. We did end up selling, not at a hundred. We sold it for, like, 70 million. But we did really well. It was a bootstrapped company. We built this massive national marketing company. It's sort of like match.com for contracting. You can take a consumer that's interested in remodeling their house and connect them to a local contractor. And we built that all from, like, a bedroom with plyboard and literally rotary phones all the way to a national brand that's...I think we became the second largest in the space.

+ +

It's still the company I still work for. As I build this other business, I'm still working at that. We're pushing 250 million now. But the concept of building something and selling it I thought was really intriguing. Landscaping was just a hobby that came in much later in my life. Thought that was going to be my next venture. I decided to pivot after getting all of the education, mainly because I wanted to build something that had application for everybody.

+ +

And what I started to realize in landscaping is the average consumer doesn't have $50,000 to dump on their backyard. And what I didn't want to do is work for rich people and wineries. I really wanted to build a magical, little space for the average person. But I also started to realize most people don't have that type of income, which then pivoted me to The Standard, which I thought had more universal application.

+ +

VICTORIA: That's really interesting. So, I love that because there's, like, a common phrase you hear about tech where every company is also a tech company now. So, it's really interesting to hear and, like, to hear about you think about growth and how it applies to businesses and that care that you put into it as well.

+ +

CHRIS: Yeah. I mean, I think everything is tech-related in a lot of different ways. I don't know, I think at least with The Standard, like, there's such a human element, and I still need to figure out so much about it. But as tech-driven as we get, we're still a social species. We still want human connection. And maybe at one point far off in the future, like, a robot can replace some of that, but the human connection, the human story, the ability to feel connected and not isolated or alone has very profound impacts on people's mental health and well-being.

+ +

And so, as much as I still have to figure out, I try not to over-index on too much tech and try to keep things very authentic and organic. Because I think when you do that right and you can do the matching of a consumer that's interested in a specific story with someone that has gone through that experience who can share that story, that connection is very profound. So, I do think it is a blend of tech, but I try not to dive too deep into the tech side of things.

+ +

VICTORIA: Right. It's more that you need technology as a tool to solve the problems of the people that you're trying to work for or trying to, like, provide services for. So, it sounds like, to recap a little bit, you were part of growing this company. You were able to build it and sell it for 70 million. And then, you decided to, like, keep doing it. You're like, that was fun. Let's do another one [laughs].

+ +

CHRIS: Well, I mean, in all honesty, I think some of the challenges become when you're starting a company, which is incredibly invigorating. But if you're starting a company in an area that you don't have expertise...so, although I know a lot about mental health and wellness, I've read hundreds of books. I interviewed lots of people. I hired you guys to do some market research for me. So, I'm not naive, but I've never built a platform that does what I'm trying to do. And in all my research, I haven't exactly even seen a platform that does exactly what I do. So, it's hard to have that perfect measuring stick.

+ +

And so, you know, what I've realized along the journey is it's really easy to spend money, and it's really hard to find product-market fit. And so, what I've chosen to do, and maybe it takes a little bit longer to get there, is rather than, like, go all in, quit my day job, and really just financially stress the crap out of myself and my wife, I still have a day job. I get paid exceptionally well. I'm very senior in my company. It's not overly stressful, but it also pays the bills.

+ +

And so, I think one of the things I've learned about being an entrepreneur is you've got to enjoy the journey. And so, I do enjoy what I still do, and it serves a very valuable purpose. And it gives me still the freedom to play around with The Standard, to still do the things that I want to do. Sure, I can't burn as many hours on it, but at the same time, if I quit this job, my runway would highly compress, and maybe that's good for some people, but there's still just so much I have to figure out. So, I need the runway.

+ +

VICTORIA: I can relate to that, and I think that's a really common story for people who have a great idea, and they need the time and space to find the right product-market fit to move forward and then make the big investment with your time and all the, like, other financial investments you would need. So, maybe to go back to the beginning a little bit, what led you to think of starting The Standard in the first place?

+ +

CHRIS: So, I'll try to say this as succinctly as possible. Life is really hard for a lot of people, you know, and you can dice it up in a lot of different ways, whether we're talking about, like, you know, global events that happen, be it war, be it COVID, you know, anything on a very large level. But even on an individual level, like, we lose people. People are dealing with weight issues, how to eat healthy, stress. There's a lot.

+ +

When we start to think about the concept of mental health and well-being, it is overwhelming. And I'm built for discipline. I've always been that way. I'm incredibly disciplined as a person. Some things may feel like they come a little easier to me, but I also look at like, oh my God, I got to worry about like, how do I sleep right? And how do I eat right? And then, how do I exercise? And then you got to be grateful for stuff, and then have social friends, and then be with your family. Like, I mean, adulting is tough; let's just be honest.

+ +

And so, a lot of the concept behind The Standard was I have the freedom to explore a lot of this stuff. I've had the luxury to read hundreds of books and, meet so many people, and really invest a lot as to educating myself about these various topics that I think are important.

+ +

I also have the luxury to deploy a lot of these strategies in my personal life, and it's a privilege to be able to do that. And a lot of people don't have that. They're struggling. They're working multiple jobs. They don't have a lot of time in the day. Maybe they're commuting. They don't have the luxury to take care of themselves. And that's just the Western world. Do you want to, like, dive into the Global South or start to look at, like, Ukraine or stuff like that? Like, there's just people, like, literally just trying to make it through the day, let alone be grateful about something or eat healthy.

+ +

And so, I started to realize, like, God, if I think this is even remotely challenging, what does somebody else feel about their mental health and well-being? And so, that was sort of the jump off of, like, it is tough to maintain your sanity. It is tough to do all of those things. Is there a way that I can make that process easier for people? And so, that just led to a rabbit hole that started about six months before COVID hit, so late 2019. I spent a lot of time researching.

+ +

I read several hundred books on habit formation and neuroscience and all these different topics. And, I mean, to the point where I was reading every morning, typing notes of these books, mind mapping this out, looking for the connection of all these topics. And what I was trying to figure out is what is the least amount of information somebody needs to know to have the most profound effect on their life? And what I came to as a conclusion was most people will not read a book or listen to a podcast. Some will, but the average person won't. They don't have the time, the desire.

+ +

But everybody's got a problem they're trying to solve, whatever that problem may be, and if you could take somebody that has a problem and you could find a way to connect them to somebody who had that problem but is a little farther down the road. So, let's pick something pretty simple, like weight loss. I've interviewed a lot of people on my podcast this year that have lost 100 pounds, which is a really big number. And even if it's not a hundred pounds, you want to lose 20 pounds. The point being is that weight is a big issue for a lot of people. It affects their self-esteem, their body image. There's a number of things that, like, impact that.

+ +

But if you could connect somebody who's really struggling to lose weight with somebody who has lost that weight and could share their story, how they felt, the habits they've deployed, and most importantly, they could talk about that experience, what would happen is the person that's been through that issue, if you will, would use a set of language that would be very specific and would resonate with the person that hasn't overcome the challenge yet.

+ +

And this is what's so unique about it is: I don't know what that particular challenge is like. I've never had that particular issue. I won't know the language to use. But if you've ever talked to somebody who has lost a significant amount of weight, they will use words, and they will give examples that only somebody who's struggling with it would resonate with.

+ +

I remember doing an interview, and a lady was like, "God, you know," she's like, "I was so overweight. I would be very thoughtful of getting on the ground because I wasn't sure if I could get back up. Or I'd be very thoughtful of the chair I sat on in case it broke." I mean, these are the things I'm like, unless you're overweight, you don't think about that.

+ +

And so, my idea was like, could I take somebody who's overcome some of these problems, get them to share some of those self-care stories that they used to solve whatever that problem was, and then create a mechanism in which somebody who was struggling with, in this case, weight loss, that they could type in, "How do you deal with weight loss?" and they could connect to other people that have developed the habits and the mindsets that helped them through that? And weight loss is just an example, but you could pick anything from racism to depression to domestic violence and so forth and so on.

+ +

The caveat there is you need a mechanism to connect the person that's overcome the challenge with the person that's still going through it. So, you got to get a lot of people on the other side of the tunnel to share their story and to know that they're doing it maybe not to monetize it but to do it for the benefit of other people who were like them at one point.

+ +

VICTORIA: Yeah, if I can try to summarize what you meant when you said, like, what's the least amount of information to have the most profound realization on how to impact your life? It sounds like what you discovered was that it's human connection to other humans who have had the same experience and survived it and overcome those challenges.

+ +

CHRIS: Yeah, without a doubt, because I think when you're struggling with an issue, you tend to think you're alone. You tend to think the way you're thinking about your addiction to something, or your weight loss, or your body image; you tend to think, oh, this is just me. And what motivates somebody who's in that mindset is to hear somebody else who can use a certain set of language that helps them realize, wow, I'm not alone. There is other people that have gone through this particular issue. And what that does is it starts to open up the door, open up their mind in a way of, wow, change can happen.

+ +

Now, you can't copy other people's habits. It doesn't exactly work that way. But what it can do is at least give you a starting place to say, "Here's somebody who I feel is like me in some ways, and they've made it to the other side. Here's some of the habits, and the mindsets, routines that they specifically have that have helped them get through this. Maybe I can try some of those on, at least as a starting place, and then I can modify them as time..."

+ +

So, it really starts with the mindset and the clarity of I'm not alone and maybe there is some hope. And I think that's a really big thing when you're talking about some of these very large issues that people run into on a day-to-day basis.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So, what lessons did you learn from your previous experience in starting a business are you taking into what you're doing now with The Standard?

+ +

CHRIS: Oh my God, so many lessons. Well, I mean, here's the brutal reality is: I've chosen to go in an industry that doesn't exactly have carryover effects. I was in marketing, dealing with homeowners and contractors, and now I'm diving into mental health. So, I, unfortunately, don't get to, like, flex my black book and, you know, voilà myself into, like, success here. I've also chosen to go from marketing and generating leads to now I'm trying to build a platform, which apparently is one of the hardest things you could possibly do.

+ +

But here's one that I really do take away, and it's probably not in the way that you actually intended that I would answer, but here's the biggest lesson I've taken away. When I built the first company, Jason Polka was our CEO, and Gabe Luna...it was three of us that really started it. So much of that entire journey...especially after the first five years of building the infrastructure, and you started to move out of the basement, and you had a corporate office, and, you know, you felt a little bit more legit. You started generating 10, 20 million dollars a year in revenue.

+ +

I'd say from year, like, five through the time we sold it, I just wanted to sell the company. So much of the conversation became around, when is this going to happen? And it was always a grind. I mean, building a company is just tough. I mean, maybe some people, it works out, and everything's great, but it's really tough. A lot of businesses don't succeed, and we were very lucky that we did.

+ +

But so much of it was me just trying to check off that final box of, like, I just want them to say, "We did it." It wasn't even really the payout. It was, just, I want to know that we were capable of doing it. And what happened is there was so much of that ten years where I wasn't enjoying the journey. I mean, don't get me wrong, like, I love the people I worked with, some great friendships. But it was so much of like, how do we fast forward this a little bit?

+ +

And so, once the day happened that it was sold, and especially as I started to embark on this other side, I said, look, I'm now in my, like, early 40s. Like, that can't happen again. I mean, maybe I never sell the next company. Maybe I'm working on this for a decade or two decades. I need to enjoy the journey. Like, my kids are young once. Like, I've got this wife. I've got this life. Like, selling a company is great, but it is not the defining thing of your life. Like, you still need to live your life.

+ +

And so, the big lesson I took away from it is how do I enjoy the journey as I go through this process? And I'll be honest, that is a big mind f, if you will, like, it's not an easy thing to do because as entrepreneurs, you're very much like, well, what metrics, and what's the next milestone? And dah, dah, dah, dah. And, like, dude, it's brutal. So, I'm really trying to, like, enjoy the process, even if the process is a struggle.

+ +

VICTORIA: What are your top strategies for enjoying the process or making it fun?

+ +

CHRIS: Well, one, take care of your mental health and your well-being [laughs], whatever that is for you. I do a lot of weekly planning. And so, when I do my weekly planning, it literally will come down to I look at my schedule, and I make sure I get my runs in there. I get my gardening in there. I get my time at my kids' events, my time with my wife. I get my workouts. I make sure I eat healthy. I do everything that I can to take as good of care of Chris as I possibly can. You know, a cliché is to say, but you can't pour from an empty cup.

+ +

So, if you want to give your best to your company, your family, your friends, your community, whatever, like, you really do need to prioritize yourself. Self-care is not selfish. So, that's the number one thing I do.

+ +

I'd say the other thing, too, is how do you deal with anxiety? How do you deal with this constant...and anxiety is one of the most pronounced mental health issues on our planet. 350 million people deal with this annually. It's easy to start to think about the future and to fill in the gap with the worst-case scenario, to get anxiety of, like, oh my God, I didn't do this, or I shouldn't be doing that.

+ +

And so, learning to just take a deep breath, do the best job you can. Let your intuition carry you, and not be so judgmental when it doesn't turn out the way you want it. Like, I wish I had much more success at this stage of the business than I do. But I'm still making forward progress, and I'm enjoying the process, and I'm learning stuff. And could I be faster? Yeah, probably.

+ +

So, I try not to over-index on what I'm not doing, and I try to just take the best next step possible and just trust it will all work out but be okay if it didn't. That's easier said than done sometimes, especially if you've never had success. I think part of it is the fact that I've been successful in selling a company. I mean, in a lot of ways, like, hey, I know I could. Maybe I can do it again. Maybe I can't. And I'm okay either way that that pans out.

+ +

VICTORIA: I think that part about being okay if it doesn't is so important. And tying that together to what you mentioned earlier about being financially stable enough to invest in what you want to invest in, like, it's a really big, important thing for founders. And I think if you're constantly worried about how am I going to pay myself? How am I going to pay my bills? You're not really going to be focused on building the best product, or actually solving the problem, or being willing to pivot in a way you need to to create something that is going to last and be really impactful for people. I think that's really interesting.

+ +

In climbing, there's some...it teaches me that because I have some projects that probably I might never complete them [laughs]. They're really hard. The people who actually create videos of themselves climbing it are, like, six feet tall, and I'm never going to be six feet tall, but I just try to enjoy the hike up to the climb. I enjoy going up to this little boulder and just, like, touching it and feeling it.

+ +

So, I'm curious if you could say more about how are you thinking The Standard will solve that problem and, like, create that connection for you and, like, solve your anxieties as, like, a founder about, is this company working well enough? Do you connect people in that same way as well?

+ +

CHRIS: There's a famous quote that says, "It takes seven years to become an overnight success." I mean, maybe in some ways, it even takes longer, depending on what you're trying to build here. And, I don't know, success is somewhat arbitrary. You know, like, I remember when I got the call that we sold our first company, which was the moment I was waiting for, I remember getting the call. I was driving home. "Hey, we did this. Here's your payout." I did not feel any more successful in that moment. Like, it wasn't like that checked off the box. I'm like, well, there I go. I'm super successful now. It was like, now what?

+ +

You know, my kids didn't, like, hug me and be like, "Oh, successful dad sold companies," you know, it wasn't. It was like, you know, life continued. And it was just such a powerful reminder of so much of the significance that we put on things is like, it's us. Like, I don't want to say nobody else cares because, you know, a lot of entrepreneurs are trying to build products that, you know, change the world, make a meaningful difference to people's lives. And we do put a disproportionate burden on ourselves of, like, God, if I don't do this, maybe it just doesn't get done.

+ +

I think, for me, when I'm building The Standard, I try to, one, I always try to think of like, enjoy the journey. Am I doing things that I enjoy doing? So, we started a podcast last year. I mean, The Standard, like, so just a quick on timeframe, I mean, I spent a year building it. So, I did all this research for about two years, including hiring you guys.

+ +

I got to the place where I'm like, okay, I think I got a concept, not product-market fit. I just got a concept, and I want to start to build that out into reality. Hired a designer, really great designer. Found him, you know, cold-called him, got him involved. Took us six months to build literally, like, a wireframe of like, it could look like this.

+ +

And then I was like, okay, great. Now I'm going to go sell that to a VC and, like, convince him to give me millions of dollars. And I was like, and then I quickly realized, like, you absolutely have nothing at the moment, Chris. Like, there's nothing here. There's, like, you think you got something, like, you've got nothing. Like, there's no users. I mean, you got literally nothing here. And I was like, okay, great, so nobody's going to give me any money for this. Where do I go from here?

+ +

And then I was like, well, I need to build something to see how people interact with it. So, then I decided to go through a no-code platform when I spent ten months teaching myself how to build something using no-code. So, I used bubble.io, which was a really great product. Now, that was a big mind cluster right there because I'm not a coder. I'm sort of the visionary of a product. That's, like, I'm not the technical expertise. But I didn't have a CTO. So, I was like, I need to solve for this problem. So, I taught myself how to use this.

+ +

That was incredibly painful but incredibly rewarding because I know how to build something. So, then I built this, and then we beta test the launch, but now I'm like, okay, [inaudible 24:46] I built this, but I don't even know if it's a product-market fit. I don't even know if I built the right thing yet. Now, I got to see people who will interact with it. And then I was like, well, then how do you even get this thing to be exposed to the world? Like, it is just every step along the way; there's some mountain that seems insurmountable. You find a way to get to the peak, and then you realize there's a larger mountain that's [laughs] right behind it.

+ +

And so, then it led down to, like, how do I get people to be aware of what I built? Played around with that for six months. And then, I was like, I got to start a podcast, like, now I'll interview people. And so, it's just a constant iteration of, like, toying around with some stuff. And look, there's plenty of things I do that I'm like, that clearly fails.

+ +

And I think the question I ask myself a lot with the things that don't work is, did you give them enough time to be successful? Did you go about them in the right way and then decide to pivot? And, like, you won't always know all the answers to that. So, I think the point in giving sort of that timeline right there is it's a constant evolution, and you just do the best job you can and be okay with how the sort of the cards fall.

+ +

VICTORIA: Yeah. And if you fail or it doesn't work how you expect it, it's like, well, did I learn something? And did I have fun doing it? [laughs]

+ +

CHRIS: And if you take care of yourself along the way and you haven't sacrificed your own mental health and your well-being, your relationships with your kids, your partner, whoever it is, then at least you, like, if you fail, you're not like, and now I'm 30 pounds overweight. I'm miserable. My mental health is suffering. Like, you've got to balance that out. And so, I think that's going back to enjoying the journey as like, don't lose sight of the things that are really important. Building a company, yes, important, and for some people, it is really important. But at the end of the day, your health, your sanity are the most important things that you have.

+ +

And so, I see all too often that a lot of entrepreneurs and just people in general are willing to literally kick that to the curb to chase some prestige, some recognition, some financial gain. And look, man, like, you know, there's plenty of rich people out there that are completely miserable, that are unhappy.

+ +

I always think of Steve Jobs a lot. He had really lot of good...he did a commencement speech at Stanford when he was diagnosed with cancer. And, I mean, this is one of the most successful business people on our planet. Apple is the most successful company today at three trillion dollars or so market cap. And here's the visionary of the company. And when he was diagnosed with cancer, all he wanted was more time. It wasn't like, oh, I need more time to build another product. It's like the dude just wanted to be around longer. It didn't matter how many billions of dollars he had or products. Those were things that sort of fell to the wayside. It was all about his health.

+ +

So, point being is like, just over-indexing on success and not really looking at what is success; success is your mental health, your well-being. That is real success.

+ +

VICTORIA: Yeah. Wow. I can relate to that, too. I had, like, at a very young age, decided, oh, I'm going to be, like, an IT project manager. And then I got my PMP certification and I was like, oh, well, what do I do now? [laughs] What's the next thing? And it's just like, keep going and going and going. So, enjoy the moment, you know, love the journey, and prioritize that above those things. And that includes, like, learning, learning all these different parts of, like, how to build a business and how to build product.

+ +

It reminds me of a journey that we hear where you could have a great idea and you're like, oh, I need to design it, and then I need to build it. And then, like, a year later, you're like, wow, I haven't talked to any users yet [laughs]. It's like, I don't actually know anything about what people want. And that's a really difficult thing to do.

+ +

And it's a very emotional journey as well to go out and talk to people and try to ask questions in a way that doesn't give you false positives or false negatives and being able to leave your ego to the side and actually connect with people and hear about their problems. So, how has that been for you? Has there been anything in your discovery process that has surprised you and caused you to pivot in direction?

+ +

CHRIS: And although you didn't ask the question in this way, a recommendation I would have for a lot of people and, you know, if you read The Lean Startup, it's a good book. It's one worth reading. I read a lot of product books and stuff. I would say, like, imagine you have no money. How will you test your concept? Like, so, like, I came into building this with some capital behind me, my own capital. And it's just easy to spend money, and not that I was naive to think spending money you do need to invest in some things, but I wish I had a lot less money than I did coming into it because I would have spent a lot less money.

+ +

And I think you don't need a tremendous amount of money to start to get that user feedback that you're suggesting. I think there's some very organic ways that you could do it. And you really got to imagine, like, you have nothing. Like, how will you test this with $100? I was listening to a podcast episode the other day on the founder of Boston Dynamics. He was being interviewed, and it was a really cool one. Boston Dynamics is one of the leading robotic companies out there.

+ +

And this guy had, you know, started the company 30 years ago, and he was walking through some of his early days. And he's like, he was talking about building the pogo stick robot and how he only had, like, I think it was, like, it was either a hundred or a thousand dollars to, like, build this robot, or maybe it was 3,000. It was a really, really low amount. And he basically was trying to build a robot that, like, jumped up and down on, like, a benign budget himself.

+ +

It was a complete failure, but he learned some things through it. But he had enough success in that that when he then pitched that concept to the next person, I think it was, like, some congressional person, they gave him, like, a $250,000 budget, which was, like, back in 1980. But the point being is like, he had so little to start with, but he was still able to get some success. Versus if he had had 250,000, I don't know that he would have figured it out at that moment. He would have spent a lot more money.

+ +

And so, I think for entrepreneurs that are starting something out, you're so right: the product-market fit is huge. It's hard not to get false positives. It's hard not to just hear what you want to hear. And so, what I've learned is that, like, there's a difference between what people say and what people do. And what you need to be doing is paying attention to what people actually do, not what people say.

+ +

I interviewed lots of coaches across the planet. I'd share this idea. And, I mean, I had a phenomenal, like, 90% of them were like, "Chris, this is amazing." They would share some of their personal videos with me. And I'm like, wow, God, like, everybody thinks this is a great idea. And then, I started to realize like, it's probably because I'm decently looking. I can talk to people well. Like, there's a little bit of a me factor. I was like, well, what happens when I take me out of the equation? Will still 90% of people still think it's a good idea? And the answer was like, no. It completely changes.

+ +

If I'm not there to navigate or provide the narrative, which, as entrepreneurs and founders, we're typically the storyteller, but if you remove me and I just show you it, you'll be like, "Ah, it's cool." But, I don't have enough of the expertise in product design and the sticky factor. I haven't found the right combination for somebody just to interact with and be like, "This is pretty sweet. I want to use it."

+ +

So, going back to your original question, is like, you need to do more of that, and you need to learn how to do that stuff. I am still like you at surfing. I'm a novice at this. Like, I'm out there trying, but I am crashing all the time. And I am constantly trying to get back up and figure out how can I do this better and not provide an illusion that I'm getting it right, really paying attention to what do users actually like and not like? I am far from figuring that out. I'm still dedicated to doing it, but by no means have I hit a home run here.

+ +

VICTORIA: What keeps you motivated? What keeps you going and trying to solve that question?

+ +

CHRIS: You know, it goes back to an original statement I made with you is like, life is so hard for so many people. I jokingly will tell people, I said this a lot when I was interviewing coaches, is like, look, I'm very aware of my privilege. I'm a white, male who lives in Northern California in the U.S. I was born in the '80s. Like, I did not grow up with, like, this insurmountable, you know, adversity that I had to overcome. Like, there's a lot that was easier for me to obtain in my life.

+ +

And look, I work really hard. I am incredibly focused. I put in a lot of work. I'm very focused in that way. But I also just recognize, like, it might have been different if I was born somewhere else, if I looked a different way, if I didn't have access to the resources that I did. And so, my point with that statement is that I am a massive believer that whatever excess currencies you have, time, capital, energy, whatever it is, it is our obligation to help as many people on this planet in whatever way we think we can help them.

+ +

There are 800 million people on our planet that don't have clean drinking water, which is mind-boggling to me, considering the age we live in. I mean, we take it for granted you turn on the faucet and water comes out. That is a luxury that we have in living in the United States and in the Western Hemisphere. I mean, when you think about 800 million, that's almost 1 out of 8 people that don't have clean drinking water. And that's just drinking water, let alone access to vaccines or whatever you may choose.

+ +

And so, the point that I'm making is that for those of us that have excess of anything, and maybe it's just time, or maybe it is you have a lot of money, we should be doing the best job we can to help other people in the ways that we think would help them. For me, I'm focused on mental health and well-being. For somebody else, that might be providing good food, or medicine, or whatever it may be, and that's okay. We just need more people contributing to, hopefully, you know, lift as many people up to the point that we all have good lives. That's what keeps me going is the fact that, like, I don't take for granted for one second how easy my life is.

+ +

VICTORIA: I love that. And I like that you're trying to build technology that helps people and isn't just trying to, like, make the most money you can, or try to, like [laughs], flip it around or just share something that, you know, is really personal to you and, like, really is meaningful to you. So, I really appreciate you sharing that with me. What does success look like six months from now or even five years from now?

+ +

CHRIS: Look, success for me is pretty much what I've stated this whole episode is, like, I'm taking good care of myself. I'm very present in my life with my wife, my kids, my friends doing things that make Chris happy. That's what success looks like.

+ +

Now, clearly, we're here talking about The Standard and growing, and so I'd love to see more progress being made. I'd love to see more users on the platform. I'd like to be learning and figuring out, how do I help people share their story in a way that empowers them to share that story? How do I get people to want to share their story that don't feel like they have to be paid to do so?

+ +

You know, what I find so interesting when I talk to so many people and, you know, I ran 45 episodes of our podcast this year. So, I talked to a lot of people that have gone through some adversity, and they'll all say the same thing, "Dude, I will help anybody that is going through what I've..." Like, nobody wants to see somebody struggle, especially when you know how hard adversity is, whatever that may be for you. You don't want to see other people struggle because you know how painful that is.

+ +

I want to see people who are willing to quote, unquote, "give back" and say, "Look, if I can share a few things about how I've navigated my adversity, whatever that adversity is, because it will benefit other people going through this, I don't need to be paid for that. I just want to share it because it's sort of the right thing to do. It's sort of a pay it forward." I think in today's age, like, in the creator economy, like, everybody's like, "Well, I'm not going to help out unless I get paid." And, like, look, that might be a very privileged statement that I'm making, that I have the luxury.

+ +

But when I build The Standard, right or wrong, and some people would argue, "This is, like, the dumbest business model ever, Chris," is like, I don't think about monetization. Like, I'm not like, how do I get paid on this? Is it ads? Do I charge people? Like, I'm just trying to build something that I think actually will help people, and I'm trying to do it for the right reason. So, it's people before profit. But, at one point, there has to be money involved to some extent. But I don't put the money part first. I put the people. How do I get that right?

+ +

So, my hope would be, in 5, 3 years, whatever the time would be, is that more people buy into the message and they're like, look, if all it takes is me to spend 20, 30 minutes to create a couple of videos on my habits and share a little bit of my story, and there's a way to memorialize some of the things that I've learned for the benefit of other people going through it, that's great. That's a drop in the bucket of my time. That if enough people started to do that, it would send a signal to a wider swatch of our community, or people, or species that it's okay to share some of the things that make you who you are. And if you did that, it lets somebody else do that.

+ +

And if you get enough people doing that, you build a phenomenal habit bank, if you will, of just stories that other people can leverage for their own benefit. That would be success from my perspective. I try not to attach a certain amount of users. It's really just like, can I start to convince more and more people that you probably already have some information that would be really valuable to other people?

+ +

I'm just trying to organize it in a way that someone can find it, but I need people to share their story because the platform is not about me. Although I'm on it, it's not about Chris Pallatroni. It's about you. I mean, I'm sure you've gone through things in your life that you've learned, and you've navigated that. If you could share that in a way that was authentic and easily organized, other people would hear your story and be like, God damn, that's me too. I'm just trying to get more people to do that. That would be success in my mind.

+ +

VICTORIA: Well, it reminds me of a program I'm involved with. You might have heard of Big Sister, Little Sister, or Big Brother, Little Brother. It's a mentorship program. So, you have a one-on-one relationship with someone who's...like, the little sister I have really reminds me of myself when I was that age, like, you know, early high school awkwardness, trying to figure out how to navigate friendships and family life and getting a lot of pressure on, like, what are you going to do with your career? Even though you're still, like, really young.

+ +

So, it's interesting to think about how could you scale that and, like, have more content, like, take some of the little bits of conversations we have and, like, share that with other people who are going through the same thing.

+ +

CHRIS: Yeah, it's exactly that. And there's lots of stuff out there. I mean, you think of, like, you know, Alcoholics Anonymous like, in a lot of ways, that is it. Or people that have gone through school shootings, like, they find a lot of comfort in talking to other people that have navigated that. Like, there is no topic that does not touch mental health and well-being. Like, there's none. Like, I mean, I've read them all.

+ +

And so, it's just about taking people...and this is the beauty of it, like, sure, there are experts out there, Mel Robbins, Tony Robbins, you know, they've read. Their whole life is about self-development and empowerment. But if you take an average person somewhere in the world and maybe they have read notebooks on self-development or any of that, and you just start to dissect their experience as a human, what I know to be true is that they'll say, "I went through this," whatever this may be. And if you start to unravel the, how'd you cope with it? What did you learn? What habits did you develop? What mindsets did you develop? There is profound wisdom.

+ +

It may not be textbook. They may not understand the science behind it, but what they will share is something that is very real and that it's said in a very authentic way. And the words they use are incredibly powerful that if you could just capture that in a very authentic way and store it, and most importantly, find a way to organize it so it's easy for somebody to find, that's what this is about. And so, there's lots of this that exist out there. There's just no central mechanism that tries to tie this all together. And so, that's sort of what I'm attempting to do.

+ +

VICTORIA: That's really cool. Thank you so much for coming on and sharing your story and talking about what you've been building. Is there anything else that you would like to promote?

+ +

CHRIS: No, not at all. I mean, I would just say, like, if anybody's interested, like, the platform that we have is thestandardapp.com. It's not an app; that's just the URL for it. Or you can find us on pretty much any social channel. It's just The Standard. We do run a podcast, which is The Standard Podcast, where we interview a lot of the coaches. But any one of those things will give you a really good idea of what we're trying to do. And if you feel like you've got something of value, we'd always love for more people to come on and just share their story in a way that's authentic to them. And that's really what we're about.

+ +

VICTORIA: Awesome. Thank you so much.

+ +

You can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+s_6eA21L + + ]]> + + Victoria Guido + + + 517: Building Better Design Systems with Luro's Trent Walton + https://podcast.thoughtbot.com/517 + a5569f5e-d5e9-47de-956f-cb2b1d00a33b + Thu, 21 Mar 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Trent Walton, CEO of Luro, joins hosts Victoria Guido and Will Larry to discuss his transition from a typography enthusiast to co-founding Paravel and eventually creating Luro. This no-code platform enhances design systems for better adoption, collaboration, and organizational alignment. Emphasizing a holistic approach that merges design and development, Luro addresses the challenges of traditional design systems by making them more accessible and integrated with performance and accessibility metrics. This solution fosters a more collaborative and efficient team environment, streamlining product building and maintenance across disciplines. + 44:59 + no + + + Hosts Victoria Guido and Will Larry are joined by Trent Walton, CEO of Luro. Trent shares his journey into the design world, from his early fascination with typography and logos to co-founding Paravel. This agency later evolved into creating Luro, a no-code solution for building design systems and tracking their adoption across products. +Trent emphasizes the importance of understanding the materials one works with in design and development and stresses the need for a holistic approach to product building. This approach blurs the lines between disciplines, encouraging a generalist mindset over specialization. Luro, as a product, stemmed from the realization that existing design systems often fell short in adoption and application, leading to a search for a more integrated and comprehensive solution. +Trent outlines the functionality and vision behind Luro, explaining how it serves not just designers and developers but entire organizations by fostering better collaboration, documentation, and understanding of design decisions. Luro aims to streamline the creation and maintenance of design systems, making them more accessible and manageable, even for teams facing resource constraints. By incorporating performance, accessibility metrics, and the ability to track component adoption and integration, Luro provides a platform for continuous improvement and alignment with organizational goals. +Luro (https://luroapp.com/) +Follow Luro on LinkedIn (https://www.linkedin.com/company/luroapp/), YouTube (https://www.youtube.com/channel/UCsS9BEmX1NPBXkbaLGcMZlw), Discord (https://discord.com/invite/aNEdjnR6A5), or Instagram (https://www.instagram.com/luroapp/). +Follow Trent Walton on LinkedIn (https://www.linkedin.com/in/trent-walton/). Visit his website at trentwalton.com (https://trentwalton.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: + VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. And with me today is Trent Walton, CEO of Luro. Luro is a no-code solution to build your design system and track adoption across your entire product. Trent, thank you for joining me. +TRENT: Oh, thanks for having me. It's great to be here. +WILL: Yeah, I can't wait to dive into Luro and get to know more about the product. But before we go into that, tell us a little bit about yourself. I know you're based out of Texas. +TRENT: Yeah, I grew up, lived here my whole life. I'm in Austin with the other co-founders, Dave and Reagan. Been a designer probably all my life, always been interested in, like, typography and fonts. When I was little, I used to buy badges for cars from swap meets and take them home, not because I needed, like, I had a car I was building and had any interest in, like, sandblasting or building an engine. I just liked the typography, and the design of the icons, and the logos, and all that kind of thing. +And so, now it's evolved into me just being, like, a type aficionado and a graphic design aficionado, and then that evolved into, especially when I discovered the web in the early 2000s, building and designing websites with Dave and Reagan, who I mentioned. And so, we had an agency called Paravel early on and had a lot of time putting into practice kind of that design and development and building for the web. +VICTORIA: So, your first interest in design came from, is it a car engine? Is that what I heard? +TRENT: Well, yeah, my father is a mechanical engineer, and so is my brother. And they work on cars, have classic, like, old Mustangs and Cobras and things that they build in their spare time. And I have no interest in that kind of work [laughs] but grew up in that environment. And, you know, pre-internet growing up in the '80s, one of the things that really got me was the aesthetic and the design around those kinds of muscle cars, so, like, old Shelby or Cobra or Mustang Ford ads, just, I really got into that. +So, I'd buy, like, car manuals for a few bucks, or if there's a Mustang Cobra and there's a cool, like, chrome snake logo with a condensed uppercase typeface or some sort of lettering that says, you know, "Shelby Cobra." And that's when I realized [laughs] where my interests lie. You know, engines are cool. They sound cool. Fast cars are cool. But I was just totally, you know, enamored with the typography and the design aspect that surrounded those things, and then it just kind of evolved from there. Anything else I could get my hooks into, I picked up on. +VICTORIA: I love that because when I talk to people about design, for folks who don't have a background in it, they kind of think, oh, design, that's logos. You know, I'm redesigning my house right now. My husband is like, "Oh, it's picking the tiles and the colors. We can do that." And I'm like, "No, like, design, there's a lot more to it. Design is everywhere." Like, you can find design inspiration from car manuals [laughs], it's so funny that you bought those, or from random logo design and actually, like, really good design. If it's something that's designed well, you probably don't even notice it. You just flow and use the space or use the app as you're intended to. +TRENT: Yeah. And I also think that getting inspiration or starting ideas out from anywhere but the medium you're working in might be a nice little trick to bring some, like, naïve, fresh perspective to things. So, I try to go back to that stuff as much as possible. I have heaps of manuals I've bought off of eBay in recent years, yeah, things you wouldn't think you'd find on, like, you know, whatever, a graphic designer's bookcase, just anything to sort of break the monotony or break my own little lenses of what a website should look like, or what a logo or a brand should look like, how to step outside of that a little bit. +But it's funny because it really does go back to that initial sense of wonder I experienced at those really just, you know, we're talking, like, in a gross, swampy field in Texas with, like, funnel cakes being served at every corner, like, not the most slick, rad graphic designy vibe, but that's where it all started for me. So, I go back there as often as I can [laughs]. +VICTORIA: So, how do you talk to founders or people who are thinking about building products? How do you talk to them about design and give them a where to get started approach? +TRENT: I don't know that I ever specifically talk about design or even maybe, like, engineering or about performance. I talk about all those things, accessibility, et cetera. I try to blur those lines as much as possible. It's maybe an idyllic thing that I've had for years. But going back to the agency days, I'll call them the agency days, but up until, like, you know, 2015, '16, Dave, Reagan, and I ran an agency called Paravel. And by nature, the three of us are some sort of a hybrid between a designer, maybe, like, a front-end developer. You know, Dave's more of an engineer now. +But we've all been very careful to make sure that we're generalists, which I don't know that that, like, career-wise that, might pay off long term, but I cannot work on the web any other way or talk about the web any other way. I've always felt like, I mean, there was the old, which we don't have to get into, gosh, but the debate on should designers code? But I think the essence of that is really, like, should we be familiar with the materials we're working on? +So, anytime I start to talk about designing for the web or designing a product, you want to make sure everyone has a clear understanding of the environment that they're working with. So, is it, you know, a website? And is performance important? And is our site that we're redesigning is it performant now? Is it fast or slow? Or am I a designer who only cares, and this is a thing that I have to fight inside of myself all the time? +So, I'm not trash-talking anybody, but, like, do I want to load a bunch of fonts and cool images, and is that my KPI is how interesting and engaging the visuals are? Which is a great one to have, but it also, you know, while you're talking about design, you have to consider all of these other things that can define quality for an experience. Maybe those other things don't matter as much from one person to the next. But the more they are in front of me, the more they evolve the way I perceive what I work on. +And so, I try to never really isolate any kind of aspect into maybe, like, a stage or a sprint that we're doing as a team. It's just sort of this holistic kind of hippie vibey way to look at sites, but I want to make sure that it's always, like, we're always starting from a very, very broad place that involves every aspect, and all team members and stuff like that. +VICTORIA: Well, I love that because I try to think about that in the same way from the other end, like, on the operations perspective when you're talking about site performance. And, you know, like, is the site responding fast enough? And it comes back to the question of, like, well, what is the experience, expectations of the user? And what's important to get done on the site? [laughs] And having those conversations, like, early on and integrating all these different teams from the design and development and operation side to have that conversation so everyone knows what is the goal of the site and what is the important aspects of the user experience that the system needs to be able to support? +So, I also like that you said that it's like, well, should you be familiar with the materials that you're using? [laughs] Thought that that was really cool. Like, I'm actually...my husband and I are renovating our home. And I'm talking about why we should invest in design [laughs], and part of it's because there's things to know about the materials. Like, if you're choosing a floor for your house, like, the designers will know, like, what's the durable ones? What's the ones that are going to fit your need, and your cost, and your budget? And so, like, they don't necessarily need to be a person who's going to lay the floors [laughs], but they need to know what to expect out of what you decide to use. +TRENT: Yeah, it's, like, all of these constraints. And so, being familiar with the real-world implications of the decisions we make, you know, inform that. So, yeah, I mean, I think that's pretty similar, too. It's like, well, you need this floor because it's more durable in this climate or whatever, same thing for, you know, the websites that we build. It's all contingent upon the outcomes that, hopefully, we can mutually agree on. You know, there's kind of a general sense of, like, performance is important, and accessibility is paramount and extremely important. But then there's some nuance to that as you get into some smaller decisions. +So, having these kinds of discussions early on and frequently and almost...the way I like to think about it is rather than, like, a check-in where we say, "Okay, this is it," but having a place where we can all look to check in and find information and share information that's maybe not so fast. One thing I like to think about is things get lost in chats and maybe even tickets, so as you're closing tickets and opening tickets. There's a bug. I solved it. It's gone. Can you send me this logo? Can we tweak this? These micro changes they open and close very, very quickly. And so, there's this firehose that happens. +And so, I find that having a place separate from that for discussing these things and remembering these things, and referencing these things while we are in our code editors or inside of our Figma or any kind of design tool that we use to sort of cross-reference and simmer on things as we think about the decisions that we have to make, as opposed to just knocking them out super quick, always being mindful of those constraints. And again, yeah, the [chuckles] materials we're working with, whether it's just, you know, HTML, CSS, and JavaScript or whatever, but all of those things. It's good to be mindful of that. +WILL: I know you said that you've been in design for a while, and so I love just picking the brain of someone who's been into it a while and see how far we've come from, especially just the 2000s. So, in your opinion, with design, how do you feel about where we've come since the beginning of tech to where we're at now and, also, I guess, where we're going with the design? +TRENT: Yeah. So, I guess I can really just frame...this is going to help me remember just framing [laughs] where we were. I started off on Homestead, which is sort of like GeoCities. I was in college. I graduated, and I think it was 2001, maybe 2000, anyways. And it was mainly just taking images...I didn't even have Photoshop at this point. And you realize you could, like, tile a background for a build your own website. Homestead was one of those kinds of deals. And I thought that was very interesting. So, I had this cheap digital camera. It took a lot of cords to figure out how to, like, port that onto this old, crappy Hewlett Packard computer that was, like, a hand-me-down. +Fast forward a couple of years, I had graduated, did not study design, so I'm all kind of self-taught or just taught by the web, the peers, the information that has been shared and been influenced by. But Dreamweaver was out, and Macromedia was huge, and I loved Fireworks. And so, Dave Rupert, I paid him $80 to teach me HTML [laughs], and so we've been together ever since. This is right out of college. +And so, the tools that we used there were pretty rudimentary, but Fireworks was rad. Like, it was kind of web-based. It felt like it made more sense. I love Photoshop, and that's kind of, like, a primary graphic design tool that I still use to this day. But early on, it just felt like everything was so harshly limited. +So, if you had any kind of idea that you wanted to execute that you could just draw on a piece of paper, mock it up in Photoshop, the amount of work that you had to do to get that to happen was either extremely high, or it was just impossible. And then, if it was impossible, I bet you can guess what we did. We went to Flash, and we made, like, a crappy video of a web page that was not accessible and really hard to use. I was heavy into Flash for, like, two or three years until kind of, as I had been warned by Dave that, you know, HTML and CSS are going to be the way the web works. +But when I came back to that, there was this wonderful time where it felt like we were charting out every single...it was just new territory. It's like we had come to this other planet or this other world, and everything that needed to be done, we had to figure out how, like, getting web fonts onto pages, rounding borders. I mean, getting that done aside from slicing images in Fireworks felt like this new monumental discovery that changed the lives of many. Maybe it did, maybe it didn't, but in my world, it felt like that. +And so, early on, you can look back on it and go, gosh, everything was a pain in the ass, like, living with all of these limitations. But for me, I do look back at it like that, but I also look back on it as this wonderful time where we were building the web that we're working on now. So, all these things that make designing easier and quicker come with some sort of a, you know, an evolution of your perception, and [inaudible 13:14] fond memories of work along the way. +For me, it's sort of I've just always sort of been around working on the web and watching design evolve, and every little step maybe feels like a tiny one or a large one. But these days, it just seems like, oh, this is exactly how it should have [laughs] always been, like, convenient grids and convenient box shadow and all that kind of stuff. +But yeah, it's been nice to sort of grow up only being a web designer. Like, I mean, I've done graphic design. I've done brochures and, print design, and logo design for sure. But, I have always been anchored to and centered around web design and thinking about things in the context of how they will be applied to the web first and foremost. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +VICTORIA: So, what was the turning point for you that led you to found Luro? How did it all get started? +TRENT: With Paravel, the agency days, we had a lot of fun. I think, for us, our big agency spike was when responsive web design came out. Ethan coined the term. There was a lot of people on the web, you know, a lot of agencies or a lot of teams, a lot of companies that needed to pivot into that. And so, we found this great working relationship with companies where we would come in and sort of had a little bit more practice just because we got in early learning kind of how to do that well, I think. +And it was a sort of we're going to redesign a page, a homepage perhaps, or, like, a marketing page. You'll do that project; three to six months go by. And then the next thing turns into, well, we have this giant network of e-commerce stores. We have this giant network of pages with, like, download centers and support documents. And now, we need to make everything responsive, and it can be anything. We need to make everything accessible. We need to make everything performant. We need to update the brand on everything. +And I don't think we're alone in this. I think this is the beginning of the greater design system discussion as it applies to the web. Obviously, design systems predate the web; design systems pre-date, like, 2012 or '13 or whenever we got into it. But projects started to migrate from, "Hey, can you design this really amazing, responsive marketing page," to "We have a system, and we need you to solve these problems." We love working on those problems. I still do to this day. +But the reason why we switched from kind of being a, you know, individual contributor-type agency consultant type roles to building a SaaS product was because we were realizing that things got complicated...is a very, like, boring way to say it. But to get a little deeper, it was, we would see things not ship. So, like, our morale went down. The teams that we were working with morale kind of went down. And as I was digging into why things weren't shipping...and when I mean ship, I think, like, pages would ship, of course. Like, here's a page. It just needs to be built, somebody decided, or a new feature needs to be built. Of course, those went out. +But the idea of, is our design system or the system that we're designing launched? Is it applied? Is it fully adopted? Is it partially adopted? It never felt like the amount of traction that we were promising or that we were being asked for. And I don't mean we, as in just the three of us, but the entire team or the entire organization who, in many cases, all were bought into the idea of design systems. +So, what we found was, when things got real, and we had to give up things, and we had to work on things and prioritize things, it became much more difficult to work in that capacity, probably partially because of the cross-discipline nature of those things. So, as opposed to what I consider maybe a miserable way to work in many cases, is the classic; here's my Photoshop comp. And I have a red line document JPEG that I will give you, whatever engineer I'm working with, or it's myself, and I'm just giving myself a red line document, but you're just going through and trying to make those things match. +And that is sort of not fun for the team because now we're just sort of chiseling each other and sort of, like, going through and critiquing our work over and over versus really kind of in the spirit of prototyping and inventing together. I find that products are diminished when you do that. +So, as you try to get into this design system part, it requires a lot more insight into what everyone around us is doing, kind of, as I was saying at the beginning, how to have this cross-discipline view of what we are actually working on. And that view is what we thought, and we still believe in many cases, is absolutely missing. So, you can spin up a design system. And Luro is not the only design system tool. Of course, you can spin up your own. And what I mean by that is, like...I'm maybe going to answer, like, three questions in one. Maybe you haven't even asked them yet. +But just to kind of frame this, if you ask anyone what a design system is, it might be a different answer. It might be these are my Figma components that I've created and I've shared out, and there's a public link. You know, an engineer might say, "Well, it's the GitHub repo of components that I'm actually using." So, the design is helpful as documentation. But the design system is the code, or the design system is the actual...or the actual components that are live that users see, which I would argue probably is the most accurate, just because we're talking about user experience impacting whatever business objectives we may have. +So, those components need to make their way into live sites or products. So, finding out what that answer is, what's the source of truth? What is our design system? What are our components? What are our standards? You have to have multiple sources for that, just because there's multiple people with multiple opinions and multiple measures of success involved in those. And all of those opinions and measures of success, I would say, are valid. So, accounting for those and kind of crossing the streams, if you will, in one sort of central UI, we believed was crucial enough that we should jump out of the agency days and into a product-building scenario. +VICTORIA: That's really interesting. So, you saw this pattern in the delivery of your work as an agency that made you want to build a solution to create better outcomes for a potentially exponential number of clients, right? [chuckles] +TRENT: Yeah, hopefully. I think that working on how you work together as a team is vitally important, and if you can find the right environment, then the actual product will benefit. I mean, and I'm not even just thinking about these maybe soft things like, oh yeah, if engineers and designers can work together, the typography will be a little bit better, and the site will feel a little bit more cohesive, and it'll be maybe a little bit easier to digest. I believe that. +But I also believe that there are people in organizations doing research, financial analysis, customer analysis, A/B testing, you know, all sorts of work that contributes to the decisions that we make about our sites and products that sort of just gets lost in the shuffle, in the firehose of the day to day. So, having something that takes not only a, I guess, what you could classify as the what for a design system, it could be the design of a component. Maybe it's actually even, too, as well, the code that makes up that component. But then there's this giant why. Why does the button look the way that it does? Why does a card have a border around it? Why? Why? Why? Why? Why? +These things maybe they come up during meetings. Maybe there's something that, as a designer or an engineer, I found maybe on the company's shared OneDrive or somebody mentioned in passing. Those things are vitally important, and they need to be, again, back to the morale and perception evolving; they need to be accessible to everyone. But it's a needle-in-a haystack situation. +It's funny. We would consult. And one of my favorite stories is we were building this prototype. We were hired to build a prototype for a startup in Austin. They were on a big, open floor-plan office with the glass meeting rooms. And we were showing off our prototype, and we just felt really clever and witty about the way we were going to solve this and the pages that we were going to build. +And who is a friend now, a person named Angela walks by, and she's like, "What are you working on?" And we told her what it was. And she says, "Oh, wow, you know, six months before you started contracting with the startup, we did this all, and we've user-tested it. Everybody's been reorged, and nobody remembers. But I have this PowerPoint I can send you, and it will show you the results. Some of these things you're doing are probably going to be great. The other things you should absolutely not be repeating these mistakes." +And I thought about how likely it was that she walked by and happened to see that through the window and happened to look on the sharp television on the wall. And it's probably not very likely, and as we become, you know, we're remote and working remote the likelihood of those things happening maybe goes down. The idea of building a product that increases the likelihood or almost makes it seamless that you can find information relevant to what you were working on, even if you're new to that project or you haven't worked on it for a long time, is very, very key. +So, within Luro, you can build a design system. You can add your styles. You can add your components, configure your tokens, and do all that, but you can also integrate those things that I was mentioning: prototyping, research, and testing. We also do an accessibility and performance through Lighthouse and give you metrics there. All of those things are associated to the pages that your site is comprised of. They're associated to the components that you use to build everything. So, we're sort of crossing the streams here. +So, if you're going into imagine a button component and you're like, okay, the border-radius is four pixels. The type size is 16 pixels, and here's how you code it. We're putting in an actual button. The class is dot btn. That's all great. It's helping us build the button. But if you are asked by leadership or anyone, "Why did you decide this?" Or "What is the impact of design?" Or "What is the impact of the product team on our bottom line? How are you moving the needle? How are you helping us as an organization achieve?" The answer isn't, "Well, we made the border four pixels just like the design [chuckles] said." That's great. Good job. +But I think having all of this information associated with design and associated with engineering not only makes us more informed as contributors to teams but it helps us to articulate the value of what we do on the daily in a much more broad organizational sense. +So, you can say, "Well, we user-tested this, and we realized that if we took out these form elements from a signup flow, we get more signups by having fewer steps. And so we removed a step. We user-tested it before and after, and signups went up 30%." That's a much cooler answer than, "Well, our design system helps us be consistent," even though we know that that is vitally important, and it makes our app or our site feel much more cohesive, and it contributes to that sign up metric or a sales metric just as much. +But having this data and associating it with a component so it's not something that you have to sort of...I guess it almost sounds subjective if you bring it up and say, "Well, we're moving faster, and we're selling more stuff." That's not great. But if you can link and say, "Well, here's a PowerPoint before," or "Here's a summary of a user test before and after. Here's real numbers," it helps you to portray yourself as the designer or engineer or product team member who thinks very deeply about these things, and it helps you to accurately portray yourself in that way. +So, I went on a real tangent, but actually just there, I think I just was describing sort of the nuts and bolts of why we built Luro to not only be a design system tool but, like, what we kind of also call a product development tool, a product development system. So, it's extending the idea of design systems to the practice of building a product with an entire organization. +WILL: That's really, really cool, and you did a great job explaining it. I'm excited to see it and see where it's going. I felt like a lot of what you were saying was the why you're doing stuff, why you chose, you know, X, Y, Z. Is that where the analytics and the tracking portion of Luro comes into play? +TRENT: Yeah. I think that one thing we heard a lot from agencies or even just teams within an organization that are working on design systems is back to that articulating the value of maybe a design system or articulating the value of the work that we do as designers or product builders and similar to we've done a user test and these are the results, and sales or signups, or whatever the case may be, have improved. I think one of the key metrics for a design system is, is the component adopted? There are other ones, and people will mention those, things like, is it helping a team be quicker? +So, if there's a design system team, and then there's multiple product teams within an organization, and they all want to work together, and they want to be able to take the components that they need and build their ideas quicker, prototype quicker, that's a great metric as well. But one that we find vitally important is, are the components live to users? And so, being able to track that has a lot of value. One, obviously, is that communicating that to the greater organization, saying, "You know, we've spun up a design system team. The card component is on 49% of pages. The button is on 100% of pages." +And then if you're trying to be more tactical about how to improve the product or even just track down, you know, which components or which pages or which experiences aren't, I guess, consistent with the design system, you can say, well, "There's 49%, and there's 51% of pages that may or may not have the card component." And so, you can go find outdated components if you're trying to phase new ones in, and all of those sorts of things as well. +So, the metrics are sort of great from a thematic sense, saying, this is the value that our design system is, you know, affording us as a business and the users are experiencing while they're using our app or our site. But then, also, you can drill down into these metrics and see, okay, the button is appearing here. I can click into pages and see views where it's being used on the page level and see, is it being used properly? Those kinds of things. +You can track legacy components as well, so, for example, if we've rebranded the site that we all work on together and our old button was, like, dot button and the new button is dot BTN or however we would want to class those things. And you can use classes. You can use data attributes, all those kinds of things. But I would say we can track legacy along that. +So, if your goal is to completely adopt the new design system across the entire network and products within six months or whatever the case may be, you know, month over month, week over week, you can check our, you know, line graphs and see, hopefully, the legacy occurrences of that going down over time. So, if, like, the button is being used less and less and then the dot BTN is being used more and more, you can see those sort of swap places. +And so, what we have found is talking about things in sort of an objective or fuzzy way, saying, well, we're trying to ship this, and we're doing these inventories, and we're going through all the pages. And we're clicking around trying to find old things, or we're redesigning pages. But it's very, very difficult. This is just an instant quantification of where our components are manifesting in the product. +So, what we do is, with Luro, you can give us...whether it's behind an authentication layer or not, we crawl web pages, first and foremost. So, you can give us a site. And this is all optional. You can spin out a design system without this. But we crawl the site, and then we will go ahead and do performance and accessibility scores for there. +So, that's one way to itemize work, where you can just say, well, as an agency, we're going to work with this company, and we want to show them, like, the starting point and expose weak points on where we might be paying a lot of attention to. In the design or engineering phase, we need to improve the speed here. We have accessibility violations we need to think about, all that kind of stuff. +And then, once you crawl those, you can add your design system, and then you can cross-reference those, and I kind of mentioned that. You can use CSS classes to do that. And so, you'd enter in dot BTN for button. We've already crawled your pages. And so, we can tell you every time that that class appears inside of any page inside of the network. So, it's this very, like, two-minute way to get a wealth of information that's shared and communicated with...the entire organization will benefit. Like I said, like, leadership they can get a sense of how the design system is being used and adopted, but also, the active teams working on things so that they can go find outliers and work on replacing those. +VICTORIA: It's been over a year in your journey with Luro. What challenges do you see on the horizon? +TRENT: I still think it is an adoption challenge. I think that, you know, one thing that we found is that a lot of teams, and this is going back to our agency days, but I sort of sort of still see this happening now is that building the design system, you know, let me separate these two things. I think designing components and building the design system in the sense of picking styles, and choosing fonts, and iterating upon something like a search box or, a footer, or a modal that's a lot of work. That's just design and product design and product development in general. +But the act of, you know, creating the design system, maybe it's the documentation site, or however, we're communicating these standards across the organization. That part, to me, it's always kind of taken too much time and effort. And to be really candid, the amount of budget that's being allocated for those tasks is less. So, we're having a lot of users who are saying, "Well, I wasn't in charge of a design system. We had a team for that. We don't anymore. And now I'm responsible for it," or "The team's been combined, and I'm working on, like, three things at once." +And so, something that's very, very crucial to us at Luro is to help with the struggle of spinning up a design system. For us, I fully believe that there are design systems that can be fully custom available to the public and need to have, you know, every page and view needs to be unique unto itself. But for Luro, the starting place that we get you with, you know, you can link in your Storybook. You can link in Figma components. You can add components manually and all those sorts of things. Where we can get you in a few minutes is really close. +And then, if you started to fold in, you know, the idea of performance, accessibility, and then all of the other insights that you can then integrate, so if you're doing A/B testing or user testing and doing research, and you want to make sure that that's all involved inside of your design system, then it becomes a really attractive option. So, I think that decreasing the time it takes to get started and to spin up a design system is the number one thing we see people struggling with and the number one thing we want to bring. +I kind of like to compare it to services like Netlify. Like, I remember I used to have to set up servers to demo things for clients, and it would take an hour, and I don't know what I'm doing. And I would break stuff, and they would have to help me fix it. So, then I'm bothering him. And then, now I'm just, you know, will either link to a CodePen or drag and drop a deployed URL from something like Netlify. And it's this amazing, almost like it feels like deploying is just as difficult as, like, sketching something out on a napkin. +We want spinning up a design system to kind of feel that way so it's not so precious. You're not worried about...it is just easy to get started. And so, we're kind of integrating all these other tools that you use to make that easier and quicker because if you do have other things that you're working on and you need to move beyond that so that you can focus on prototyping, or designing, and building the actual components, you can do that. And you have that option as opposed to having to be mired in some of these other details. +VICTORIA: It seems like change management and integrating change into larger organizations is always the biggest challenge [laughs], even for great innovations. And I'm curious: what types of people or groups have you found are quick to adopt this new method and really the right group for you to center your message on? +TRENT: Yeah, it is...I was joking, I think, maybe before the podcast started, but it's, like, very ambitious because it's easy, I think, to say, "This tool is for designers. And if you're a designer, you can integrate your Figma, and then you'll have your components published to your team so that they can use them." And that's absolutely true. Like, if you're a designer, Luro is for you. If you're an engineer and you have just received components, and you need a way to document that and show your coded version alongside the design version and be able to collaborate with people in that sense, it is absolutely for you as well. +So, you can see how it's almost like you almost have to frame Luro for individuals across the organization. So, it's one of those deals where...and we've kind of experimented with this with the marketing. And the way we've discussed it, we talked to lots of, you know, leadership, heads of product, CMOs, even CTOs, things like that. And so, it's like, if you're trying to get your entire organization to work better, to ship, you know, more effectively, then Luro is the tool for that as well because we're getting into knowledge retention via uploading. +Like, my favorite story there is if you're an A/B tester, probably, and this is what we've experienced, is you run these tests. A lot of time and effort goes into building the prototypes for the test, whether that's you or an engineering team that's doing those things. This is one of the things we used to do as an agency. We would be brought on to prototype something totally new. We would test that alongside the existing experience. And an A/B tester, we'd work with them, and they would create, like, a PowerPoint or something that would explain the pros and cons and what should happen next and summarize the test. +And that would live on that person's hard drive, whether it's on their computer or, like, a Dropbox or a OneDrive account. And no one ever thought about it ever again. You would just move on to the next test. But the amount of money spent on us to build the prototype and the amount of money spent on the SaaS to spin up the, like, A/B testing environment and all of these things, and then the time spent on the A/B tester to analyze the results and generate a PowerPoint it's not nothing. +And so, one of the things that we find pretty appealing for leadership within Luro is the idea of integrating all of these tools and all this work that you do in mapping them to components so that when you pull up, for example, a button component, you'll see all the user tests that have been added over any period of time. So, if you were a new hire and you're trying to onboard, you can go interview everybody in the organization and ask them about the history of a button or a card component or the history of a sign-up page. +But then, also, in a self-service way, you can just click into Luro, click a button, click a card, click to the sign-up page, any of those things, and find all that stuff I was mentioning earlier, whether it's a test, or research, or prototyping, or any kind of documents that have been written. These aren't the arguments that Dave or I might have around the actual border-radius value. Those are small things that probably should be lost in the firehose. +But if we have learned an outline button with a stroke is performing way better than a solid-filled button or vice versa, that's important information that doesn't need to disappear in six weeks. So, that's the other kind of metric there is explaining kind of the holistic version, telling the holistic story of Luro to those types. And so, yeah, navigating that and trying to get, like, buy-in on a broad level is kind of what we're working on these days now. +WILL: Sweet. So, I actually really like how it's almost like version control. You can see the history of what you've been working on. And I really like that because so many times...you're correct. When I go to Figma or anything, I'm like, why are we doing it this way? Oh, we made these decisions. Maybe in comments, you can kind of do it, but I think maybe that's the only place you can see the version control. So, I like that feature. Like you said, you can see the history of why you did something like that. +TRENT: Yeah. And think about that, so if I am a front-end engineer and I receive a design and everyone thinks that, why are we doing it this way? I would hate to code something...I can do it. It's my job. But if I don't understand why, my feeling about work and maybe the quality of my work goes down, you know what I mean? I guess what I'm trying to say is, like, feeling like you understand, and you're lockstep with the entire team, and you understand what the goal is...what are we trying to do? What are we trying to achieve? Like, what have we reviewed that has made us believe this? +And if you don't have that information, or if I don't have that information, like, there's some traction within the team, whether it's actual momentum forward and the amount of tickets that are being closed, or just the spirit of what we're doing, that the product is going to be diminished. These are all these little things that add up, up, up, up, up over time. So, being able to show this information to be able to access this information kind of passively. +So, for example, if you got VS Code open and Luro open and you can see here's the user test from six weeks ago that shows us why we went with option B, you'll say, "Okay, cool. Even better." You know, you can review those things way before you get things handed to you. You know, it's much more kind of this utopian vision of an open, collaborative deal. +And the way I would say that is it's, you know, we all kind of hand things off. So, of course, like, there's some version, even if it's like a micro waterfall that happens on a daily basis. We're all doing that. Like, somebody needs to be done with something to hand it off to something else, so we're not all up in each other's space all the time. +But one thing that we like about Luro, whether we use Teams, or Slack, or whatever, it's not a real-time thing where I have to say, "Stop, look what I'm doing [laughs]. Come over here and look because I need you to know this." You can get notifications from Luro, but it's not something that is a context-switching demand type of a situation. +So, the idea is if you're like, I'm wondering what's going on. I know this is coming up. I'd like to review. Or I could let you know and tell you, and just on your own time, you can go see this. So, separate from, like, the firehose of tickets and chats, you can see the actual product evolving and some of these, like, key milestone decisions on your own time and review them. And if they've happened before you even started on the project, then you can do that as well. +WILL: I think that's probably where the breakdown between developers and designers that collab that's where it probably breaks down, whenever you're trying to get your tickets out as a developer. And then there's a change while you're working on it, and it's a complicated change, but you're still responsible for trying to get that ticket out in time. So, I think, like, what you're saying, you can get it beforehand. +So, it sounds like, to me, Luro would be a huge help because you have to have developers and designers working together; if you don't, you're just in trouble in general. But anything that can help the relationship between the two I think, is amazing, and that's what I'm hearing whenever you're talking about Luro. It helps. It benefits that relationship. +TRENT: Yeah, that even makes me think a little bit about the ongoing collaboration aspect. So, it's like, if something is shipped...or maybe let's go the agency scenario here. You've launched a site. You've launched a product. How do we know how it's performing? Of course, you'll have everybody...they're going to have analytics, and we'll be talking about that. And are signups up or down? But Luro will run tests. It'll continue to run component analytics. So, you can sense whether, like, somebody is changing a component. Or, you know, is the fully adopted design system not being utilized or being utilized less or more over time? +But then, also, we're running, again, performance and accessibility metrics. So, we've seen it where we've shipped a product for a client. You know, we've had Luro running. We've sort of used that as our hub to collaborate over time. And then we'll notice that there's a giant performance spike and that, like, the page speed has gone way down. And we itemize issues and can point you to exactly the page that it's happening on and give you some insight into that. Of course, you could go through after you've worked with the client and run Lighthouse on every single page in your own time for fun, but that's not reality or fun. +So, you'll get this information. And so, you almost...before we were telling people who were using Luro, we were kind of using it ourselves just to help ourselves do a better job. About a month into a project, we were able to email a customer, a former client, and say, "Hey, site's looking great. Amazing to see this. There's a 3-megabyte, 50-pixel avatar. Someone uploaded a giant image. It displays as 50 pixels. But somebody must have uploaded the full one to your homepage, and your page speed score tanked." +They're like, "Oh, wow, they must [laughs] be monitoring us and checking in on us every day." We love them dearly, but we were not doing that. We were using Luro off to the side. So, there is this other aspect of just sort of monitoring and making sure things stay, you know, as they were or better once we ship things and move forward to the next. +VICTORIA: That's really interesting. And I'm excited to explore more on my own about Luro. As we're coming towards the end of our time today, I wanted to give you one last chance to shout out anything else that you would like to promote today. +TRENT: Oh, that's it [laughs], luroapp.com, you know, that's the main thing. Check out component analytics. We have a YouTube channel, and I would say that's probably the easiest, a lot of effort, even though the videos maybe I'd give myself an A-minus or a solid A, not an A-plus on video production. I'm trying to get better. But explaining just, like, how to set things up. There's, like, a one-minute, like, what is all this? +So, if you want to see all the things that I've been trying to describe, hopefully well on the podcast [chuckles], you can see that really well. So, I'd say Luro App and then the YouTube channel. We've got, like, five, six videos or so that really kind of help get you into maybe what your use case would be and to show you how easily things are set up. +VICTORIA: Great. Thank you so much for joining us today, Trent, and for sharing about your story and about the product that you've been building. +TRENT: Yeah. Thank you for having me. This has been great fun. +VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + Luro, design systems, no-code solutions, typography, web design, Trent Walton, Paravel, product development, design and development integration, holistic approach, collaboration, accessibility metrics, performance tracking, organizational alignment, design innovation, cross-discipline collaboration + + Hosts Victoria Guido and Will Larry are joined by Trent Walton, CEO of Luro. Trent shares his journey into the design world, from his early fascination with typography and logos to co-founding Paravel. This agency later evolved into creating Luro, a no-code solution for building design systems and tracking their adoption across products.

+ +

Trent emphasizes the importance of understanding the materials one works with in design and development and stresses the need for a holistic approach to product building. This approach blurs the lines between disciplines, encouraging a generalist mindset over specialization. Luro, as a product, stemmed from the realization that existing design systems often fell short in adoption and application, leading to a search for a more integrated and comprehensive solution.

+ +

Trent outlines the functionality and vision behind Luro, explaining how it serves not just designers and developers but entire organizations by fostering better collaboration, documentation, and understanding of design decisions. Luro aims to streamline the creation and maintenance of design systems, making them more accessible and manageable, even for teams facing resource constraints. By incorporating performance, accessibility metrics, and the ability to track component adoption and integration, Luro provides a platform for continuous improvement and alignment with organizational goals.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with me today is Trent Walton, CEO of Luro. Luro is a no-code solution to build your design system and track adoption across your entire product. Trent, thank you for joining me.

+ +

TRENT: Oh, thanks for having me. It's great to be here.

+ +

WILL: Yeah, I can't wait to dive into Luro and get to know more about the product. But before we go into that, tell us a little bit about yourself. I know you're based out of Texas.

+ +

TRENT: Yeah, I grew up, lived here my whole life. I'm in Austin with the other co-founders, Dave and Reagan. Been a designer probably all my life, always been interested in, like, typography and fonts. When I was little, I used to buy badges for cars from swap meets and take them home, not because I needed, like, I had a car I was building and had any interest in, like, sandblasting or building an engine. I just liked the typography, and the design of the icons, and the logos, and all that kind of thing.

+ +

And so, now it's evolved into me just being, like, a type aficionado and a graphic design aficionado, and then that evolved into, especially when I discovered the web in the early 2000s, building and designing websites with Dave and Reagan, who I mentioned. And so, we had an agency called Paravel early on and had a lot of time putting into practice kind of that design and development and building for the web.

+ +

VICTORIA: So, your first interest in design came from, is it a car engine? Is that what I heard?

+ +

TRENT: Well, yeah, my father is a mechanical engineer, and so is my brother. And they work on cars, have classic, like, old Mustangs and Cobras and things that they build in their spare time. And I have no interest in that kind of work [laughs] but grew up in that environment. And, you know, pre-internet growing up in the '80s, one of the things that really got me was the aesthetic and the design around those kinds of muscle cars, so, like, old Shelby or Cobra or Mustang Ford ads, just, I really got into that.

+ +

So, I'd buy, like, car manuals for a few bucks, or if there's a Mustang Cobra and there's a cool, like, chrome snake logo with a condensed uppercase typeface or some sort of lettering that says, you know, "Shelby Cobra." And that's when I realized [laughs] where my interests lie. You know, engines are cool. They sound cool. Fast cars are cool. But I was just totally, you know, enamored with the typography and the design aspect that surrounded those things, and then it just kind of evolved from there. Anything else I could get my hooks into, I picked up on.

+ +

VICTORIA: I love that because when I talk to people about design, for folks who don't have a background in it, they kind of think, oh, design, that's logos. You know, I'm redesigning my house right now. My husband is like, "Oh, it's picking the tiles and the colors. We can do that." And I'm like, "No, like, design, there's a lot more to it. Design is everywhere." Like, you can find design inspiration from car manuals [laughs], it's so funny that you bought those, or from random logo design and actually, like, really good design. If it's something that's designed well, you probably don't even notice it. You just flow and use the space or use the app as you're intended to.

+ +

TRENT: Yeah. And I also think that getting inspiration or starting ideas out from anywhere but the medium you're working in might be a nice little trick to bring some, like, naïve, fresh perspective to things. So, I try to go back to that stuff as much as possible. I have heaps of manuals I've bought off of eBay in recent years, yeah, things you wouldn't think you'd find on, like, you know, whatever, a graphic designer's bookcase, just anything to sort of break the monotony or break my own little lenses of what a website should look like, or what a logo or a brand should look like, how to step outside of that a little bit.

+ +

But it's funny because it really does go back to that initial sense of wonder I experienced at those really just, you know, we're talking, like, in a gross, swampy field in Texas with, like, funnel cakes being served at every corner, like, not the most slick, rad graphic designy vibe, but that's where it all started for me. So, I go back there as often as I can [laughs].

+ +

VICTORIA: So, how do you talk to founders or people who are thinking about building products? How do you talk to them about design and give them a where to get started approach?

+ +

TRENT: I don't know that I ever specifically talk about design or even maybe, like, engineering or about performance. I talk about all those things, accessibility, et cetera. I try to blur those lines as much as possible. It's maybe an idyllic thing that I've had for years. But going back to the agency days, I'll call them the agency days, but up until, like, you know, 2015, '16, Dave, Reagan, and I ran an agency called Paravel. And by nature, the three of us are some sort of a hybrid between a designer, maybe, like, a front-end developer. You know, Dave's more of an engineer now.

+ +

But we've all been very careful to make sure that we're generalists, which I don't know that that, like, career-wise that, might pay off long term, but I cannot work on the web any other way or talk about the web any other way. I've always felt like, I mean, there was the old, which we don't have to get into, gosh, but the debate on should designers code? But I think the essence of that is really, like, should we be familiar with the materials we're working on?

+ +

So, anytime I start to talk about designing for the web or designing a product, you want to make sure everyone has a clear understanding of the environment that they're working with. So, is it, you know, a website? And is performance important? And is our site that we're redesigning is it performant now? Is it fast or slow? Or am I a designer who only cares, and this is a thing that I have to fight inside of myself all the time?

+ +

So, I'm not trash-talking anybody, but, like, do I want to load a bunch of fonts and cool images, and is that my KPI is how interesting and engaging the visuals are? Which is a great one to have, but it also, you know, while you're talking about design, you have to consider all of these other things that can define quality for an experience. Maybe those other things don't matter as much from one person to the next. But the more they are in front of me, the more they evolve the way I perceive what I work on.

+ +

And so, I try to never really isolate any kind of aspect into maybe, like, a stage or a sprint that we're doing as a team. It's just sort of this holistic kind of hippie vibey way to look at sites, but I want to make sure that it's always, like, we're always starting from a very, very broad place that involves every aspect, and all team members and stuff like that.

+ +

VICTORIA: Well, I love that because I try to think about that in the same way from the other end, like, on the operations perspective when you're talking about site performance. And, you know, like, is the site responding fast enough? And it comes back to the question of, like, well, what is the experience, expectations of the user? And what's important to get done on the site? [laughs] And having those conversations, like, early on and integrating all these different teams from the design and development and operation side to have that conversation so everyone knows what is the goal of the site and what is the important aspects of the user experience that the system needs to be able to support?

+ +

So, I also like that you said that it's like, well, should you be familiar with the materials that you're using? [laughs] Thought that that was really cool. Like, I'm actually...my husband and I are renovating our home. And I'm talking about why we should invest in design [laughs], and part of it's because there's things to know about the materials. Like, if you're choosing a floor for your house, like, the designers will know, like, what's the durable ones? What's the ones that are going to fit your need, and your cost, and your budget? And so, like, they don't necessarily need to be a person who's going to lay the floors [laughs], but they need to know what to expect out of what you decide to use.

+ +

TRENT: Yeah, it's, like, all of these constraints. And so, being familiar with the real-world implications of the decisions we make, you know, inform that. So, yeah, I mean, I think that's pretty similar, too. It's like, well, you need this floor because it's more durable in this climate or whatever, same thing for, you know, the websites that we build. It's all contingent upon the outcomes that, hopefully, we can mutually agree on. You know, there's kind of a general sense of, like, performance is important, and accessibility is paramount and extremely important. But then there's some nuance to that as you get into some smaller decisions.

+ +

So, having these kinds of discussions early on and frequently and almost...the way I like to think about it is rather than, like, a check-in where we say, "Okay, this is it," but having a place where we can all look to check in and find information and share information that's maybe not so fast. One thing I like to think about is things get lost in chats and maybe even tickets, so as you're closing tickets and opening tickets. There's a bug. I solved it. It's gone. Can you send me this logo? Can we tweak this? These micro changes they open and close very, very quickly. And so, there's this firehose that happens.

+ +

And so, I find that having a place separate from that for discussing these things and remembering these things, and referencing these things while we are in our code editors or inside of our Figma or any kind of design tool that we use to sort of cross-reference and simmer on things as we think about the decisions that we have to make, as opposed to just knocking them out super quick, always being mindful of those constraints. And again, yeah, the [chuckles] materials we're working with, whether it's just, you know, HTML, CSS, and JavaScript or whatever, but all of those things. It's good to be mindful of that.

+ +

WILL: I know you said that you've been in design for a while, and so I love just picking the brain of someone who's been into it a while and see how far we've come from, especially just the 2000s. So, in your opinion, with design, how do you feel about where we've come since the beginning of tech to where we're at now and, also, I guess, where we're going with the design?

+ +

TRENT: Yeah. So, I guess I can really just frame...this is going to help me remember just framing [laughs] where we were. I started off on Homestead, which is sort of like GeoCities. I was in college. I graduated, and I think it was 2001, maybe 2000, anyways. And it was mainly just taking images...I didn't even have Photoshop at this point. And you realize you could, like, tile a background for a build your own website. Homestead was one of those kinds of deals. And I thought that was very interesting. So, I had this cheap digital camera. It took a lot of cords to figure out how to, like, port that onto this old, crappy Hewlett Packard computer that was, like, a hand-me-down.

+ +

Fast forward a couple of years, I had graduated, did not study design, so I'm all kind of self-taught or just taught by the web, the peers, the information that has been shared and been influenced by. But Dreamweaver was out, and Macromedia was huge, and I loved Fireworks. And so, Dave Rupert, I paid him $80 to teach me HTML [laughs], and so we've been together ever since. This is right out of college.

+ +

And so, the tools that we used there were pretty rudimentary, but Fireworks was rad. Like, it was kind of web-based. It felt like it made more sense. I love Photoshop, and that's kind of, like, a primary graphic design tool that I still use to this day. But early on, it just felt like everything was so harshly limited.

+ +

So, if you had any kind of idea that you wanted to execute that you could just draw on a piece of paper, mock it up in Photoshop, the amount of work that you had to do to get that to happen was either extremely high, or it was just impossible. And then, if it was impossible, I bet you can guess what we did. We went to Flash, and we made, like, a crappy video of a web page that was not accessible and really hard to use. I was heavy into Flash for, like, two or three years until kind of, as I had been warned by Dave that, you know, HTML and CSS are going to be the way the web works.

+ +

But when I came back to that, there was this wonderful time where it felt like we were charting out every single...it was just new territory. It's like we had come to this other planet or this other world, and everything that needed to be done, we had to figure out how, like, getting web fonts onto pages, rounding borders. I mean, getting that done aside from slicing images in Fireworks felt like this new monumental discovery that changed the lives of many. Maybe it did, maybe it didn't, but in my world, it felt like that.

+ +

And so, early on, you can look back on it and go, gosh, everything was a pain in the ass, like, living with all of these limitations. But for me, I do look back at it like that, but I also look back on it as this wonderful time where we were building the web that we're working on now. So, all these things that make designing easier and quicker come with some sort of a, you know, an evolution of your perception, and [inaudible 13:14] fond memories of work along the way.

+ +

For me, it's sort of I've just always sort of been around working on the web and watching design evolve, and every little step maybe feels like a tiny one or a large one. But these days, it just seems like, oh, this is exactly how it should have [laughs] always been, like, convenient grids and convenient box shadow and all that kind of stuff.

+ +

But yeah, it's been nice to sort of grow up only being a web designer. Like, I mean, I've done graphic design. I've done brochures and, print design, and logo design for sure. But, I have always been anchored to and centered around web design and thinking about things in the context of how they will be applied to the web first and foremost.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: So, what was the turning point for you that led you to found Luro? How did it all get started?

+ +

TRENT: With Paravel, the agency days, we had a lot of fun. I think, for us, our big agency spike was when responsive web design came out. Ethan coined the term. There was a lot of people on the web, you know, a lot of agencies or a lot of teams, a lot of companies that needed to pivot into that. And so, we found this great working relationship with companies where we would come in and sort of had a little bit more practice just because we got in early learning kind of how to do that well, I think.

+ +

And it was a sort of we're going to redesign a page, a homepage perhaps, or, like, a marketing page. You'll do that project; three to six months go by. And then the next thing turns into, well, we have this giant network of e-commerce stores. We have this giant network of pages with, like, download centers and support documents. And now, we need to make everything responsive, and it can be anything. We need to make everything accessible. We need to make everything performant. We need to update the brand on everything.

+ +

And I don't think we're alone in this. I think this is the beginning of the greater design system discussion as it applies to the web. Obviously, design systems predate the web; design systems pre-date, like, 2012 or '13 or whenever we got into it. But projects started to migrate from, "Hey, can you design this really amazing, responsive marketing page," to "We have a system, and we need you to solve these problems." We love working on those problems. I still do to this day.

+ +

But the reason why we switched from kind of being a, you know, individual contributor-type agency consultant type roles to building a SaaS product was because we were realizing that things got complicated...is a very, like, boring way to say it. But to get a little deeper, it was, we would see things not ship. So, like, our morale went down. The teams that we were working with morale kind of went down. And as I was digging into why things weren't shipping...and when I mean ship, I think, like, pages would ship, of course. Like, here's a page. It just needs to be built, somebody decided, or a new feature needs to be built. Of course, those went out.

+ +

But the idea of, is our design system or the system that we're designing launched? Is it applied? Is it fully adopted? Is it partially adopted? It never felt like the amount of traction that we were promising or that we were being asked for. And I don't mean we, as in just the three of us, but the entire team or the entire organization who, in many cases, all were bought into the idea of design systems.

+ +

So, what we found was, when things got real, and we had to give up things, and we had to work on things and prioritize things, it became much more difficult to work in that capacity, probably partially because of the cross-discipline nature of those things. So, as opposed to what I consider maybe a miserable way to work in many cases, is the classic; here's my Photoshop comp. And I have a red line document JPEG that I will give you, whatever engineer I'm working with, or it's myself, and I'm just giving myself a red line document, but you're just going through and trying to make those things match.

+ +

And that is sort of not fun for the team because now we're just sort of chiseling each other and sort of, like, going through and critiquing our work over and over versus really kind of in the spirit of prototyping and inventing together. I find that products are diminished when you do that.

+ +

So, as you try to get into this design system part, it requires a lot more insight into what everyone around us is doing, kind of, as I was saying at the beginning, how to have this cross-discipline view of what we are actually working on. And that view is what we thought, and we still believe in many cases, is absolutely missing. So, you can spin up a design system. And Luro is not the only design system tool. Of course, you can spin up your own. And what I mean by that is, like...I'm maybe going to answer, like, three questions in one. Maybe you haven't even asked them yet.

+ +

But just to kind of frame this, if you ask anyone what a design system is, it might be a different answer. It might be these are my Figma components that I've created and I've shared out, and there's a public link. You know, an engineer might say, "Well, it's the GitHub repo of components that I'm actually using." So, the design is helpful as documentation. But the design system is the code, or the design system is the actual...or the actual components that are live that users see, which I would argue probably is the most accurate, just because we're talking about user experience impacting whatever business objectives we may have.

+ +

So, those components need to make their way into live sites or products. So, finding out what that answer is, what's the source of truth? What is our design system? What are our components? What are our standards? You have to have multiple sources for that, just because there's multiple people with multiple opinions and multiple measures of success involved in those. And all of those opinions and measures of success, I would say, are valid. So, accounting for those and kind of crossing the streams, if you will, in one sort of central UI, we believed was crucial enough that we should jump out of the agency days and into a product-building scenario.

+ +

VICTORIA: That's really interesting. So, you saw this pattern in the delivery of your work as an agency that made you want to build a solution to create better outcomes for a potentially exponential number of clients, right? [chuckles]

+ +

TRENT: Yeah, hopefully. I think that working on how you work together as a team is vitally important, and if you can find the right environment, then the actual product will benefit. I mean, and I'm not even just thinking about these maybe soft things like, oh yeah, if engineers and designers can work together, the typography will be a little bit better, and the site will feel a little bit more cohesive, and it'll be maybe a little bit easier to digest. I believe that.

+ +

But I also believe that there are people in organizations doing research, financial analysis, customer analysis, A/B testing, you know, all sorts of work that contributes to the decisions that we make about our sites and products that sort of just gets lost in the shuffle, in the firehose of the day to day. So, having something that takes not only a, I guess, what you could classify as the what for a design system, it could be the design of a component. Maybe it's actually even, too, as well, the code that makes up that component. But then there's this giant why. Why does the button look the way that it does? Why does a card have a border around it? Why? Why? Why? Why? Why?

+ +

These things maybe they come up during meetings. Maybe there's something that, as a designer or an engineer, I found maybe on the company's shared OneDrive or somebody mentioned in passing. Those things are vitally important, and they need to be, again, back to the morale and perception evolving; they need to be accessible to everyone. But it's a needle-in-a haystack situation.

+ +

It's funny. We would consult. And one of my favorite stories is we were building this prototype. We were hired to build a prototype for a startup in Austin. They were on a big, open floor-plan office with the glass meeting rooms. And we were showing off our prototype, and we just felt really clever and witty about the way we were going to solve this and the pages that we were going to build.

+ +

And who is a friend now, a person named Angela walks by, and she's like, "What are you working on?" And we told her what it was. And she says, "Oh, wow, you know, six months before you started contracting with the startup, we did this all, and we've user-tested it. Everybody's been reorged, and nobody remembers. But I have this PowerPoint I can send you, and it will show you the results. Some of these things you're doing are probably going to be great. The other things you should absolutely not be repeating these mistakes."

+ +

And I thought about how likely it was that she walked by and happened to see that through the window and happened to look on the sharp television on the wall. And it's probably not very likely, and as we become, you know, we're remote and working remote the likelihood of those things happening maybe goes down. The idea of building a product that increases the likelihood or almost makes it seamless that you can find information relevant to what you were working on, even if you're new to that project or you haven't worked on it for a long time, is very, very key.

+ +

So, within Luro, you can build a design system. You can add your styles. You can add your components, configure your tokens, and do all that, but you can also integrate those things that I was mentioning: prototyping, research, and testing. We also do an accessibility and performance through Lighthouse and give you metrics there. All of those things are associated to the pages that your site is comprised of. They're associated to the components that you use to build everything. So, we're sort of crossing the streams here.

+ +

So, if you're going into imagine a button component and you're like, okay, the border-radius is four pixels. The type size is 16 pixels, and here's how you code it. We're putting in an actual button. The class is dot btn. That's all great. It's helping us build the button. But if you are asked by leadership or anyone, "Why did you decide this?" Or "What is the impact of design?" Or "What is the impact of the product team on our bottom line? How are you moving the needle? How are you helping us as an organization achieve?" The answer isn't, "Well, we made the border four pixels just like the design [chuckles] said." That's great. Good job.

+ +

But I think having all of this information associated with design and associated with engineering not only makes us more informed as contributors to teams but it helps us to articulate the value of what we do on the daily in a much more broad organizational sense.

+ +

So, you can say, "Well, we user-tested this, and we realized that if we took out these form elements from a signup flow, we get more signups by having fewer steps. And so we removed a step. We user-tested it before and after, and signups went up 30%." That's a much cooler answer than, "Well, our design system helps us be consistent," even though we know that that is vitally important, and it makes our app or our site feel much more cohesive, and it contributes to that sign up metric or a sales metric just as much.

+ +

But having this data and associating it with a component so it's not something that you have to sort of...I guess it almost sounds subjective if you bring it up and say, "Well, we're moving faster, and we're selling more stuff." That's not great. But if you can link and say, "Well, here's a PowerPoint before," or "Here's a summary of a user test before and after. Here's real numbers," it helps you to portray yourself as the designer or engineer or product team member who thinks very deeply about these things, and it helps you to accurately portray yourself in that way.

+ +

So, I went on a real tangent, but actually just there, I think I just was describing sort of the nuts and bolts of why we built Luro to not only be a design system tool but, like, what we kind of also call a product development tool, a product development system. So, it's extending the idea of design systems to the practice of building a product with an entire organization.

+ +

WILL: That's really, really cool, and you did a great job explaining it. I'm excited to see it and see where it's going. I felt like a lot of what you were saying was the why you're doing stuff, why you chose, you know, X, Y, Z. Is that where the analytics and the tracking portion of Luro comes into play?

+ +

TRENT: Yeah. I think that one thing we heard a lot from agencies or even just teams within an organization that are working on design systems is back to that articulating the value of maybe a design system or articulating the value of the work that we do as designers or product builders and similar to we've done a user test and these are the results, and sales or signups, or whatever the case may be, have improved. I think one of the key metrics for a design system is, is the component adopted? There are other ones, and people will mention those, things like, is it helping a team be quicker?

+ +

So, if there's a design system team, and then there's multiple product teams within an organization, and they all want to work together, and they want to be able to take the components that they need and build their ideas quicker, prototype quicker, that's a great metric as well. But one that we find vitally important is, are the components live to users? And so, being able to track that has a lot of value. One, obviously, is that communicating that to the greater organization, saying, "You know, we've spun up a design system team. The card component is on 49% of pages. The button is on 100% of pages."

+ +

And then if you're trying to be more tactical about how to improve the product or even just track down, you know, which components or which pages or which experiences aren't, I guess, consistent with the design system, you can say, well, "There's 49%, and there's 51% of pages that may or may not have the card component." And so, you can go find outdated components if you're trying to phase new ones in, and all of those sorts of things as well.

+ +

So, the metrics are sort of great from a thematic sense, saying, this is the value that our design system is, you know, affording us as a business and the users are experiencing while they're using our app or our site. But then, also, you can drill down into these metrics and see, okay, the button is appearing here. I can click into pages and see views where it's being used on the page level and see, is it being used properly? Those kinds of things.

+ +

You can track legacy components as well, so, for example, if we've rebranded the site that we all work on together and our old button was, like, dot button and the new button is dot BTN or however we would want to class those things. And you can use classes. You can use data attributes, all those kinds of things. But I would say we can track legacy along that.

+ +

So, if your goal is to completely adopt the new design system across the entire network and products within six months or whatever the case may be, you know, month over month, week over week, you can check our, you know, line graphs and see, hopefully, the legacy occurrences of that going down over time. So, if, like, the button is being used less and less and then the dot BTN is being used more and more, you can see those sort of swap places.

+ +

And so, what we have found is talking about things in sort of an objective or fuzzy way, saying, well, we're trying to ship this, and we're doing these inventories, and we're going through all the pages. And we're clicking around trying to find old things, or we're redesigning pages. But it's very, very difficult. This is just an instant quantification of where our components are manifesting in the product.

+ +

So, what we do is, with Luro, you can give us...whether it's behind an authentication layer or not, we crawl web pages, first and foremost. So, you can give us a site. And this is all optional. You can spin out a design system without this. But we crawl the site, and then we will go ahead and do performance and accessibility scores for there.

+ +

So, that's one way to itemize work, where you can just say, well, as an agency, we're going to work with this company, and we want to show them, like, the starting point and expose weak points on where we might be paying a lot of attention to. In the design or engineering phase, we need to improve the speed here. We have accessibility violations we need to think about, all that kind of stuff.

+ +

And then, once you crawl those, you can add your design system, and then you can cross-reference those, and I kind of mentioned that. You can use CSS classes to do that. And so, you'd enter in dot BTN for button. We've already crawled your pages. And so, we can tell you every time that that class appears inside of any page inside of the network. So, it's this very, like, two-minute way to get a wealth of information that's shared and communicated with...the entire organization will benefit. Like I said, like, leadership they can get a sense of how the design system is being used and adopted, but also, the active teams working on things so that they can go find outliers and work on replacing those.

+ +

VICTORIA: It's been over a year in your journey with Luro. What challenges do you see on the horizon?

+ +

TRENT: I still think it is an adoption challenge. I think that, you know, one thing that we found is that a lot of teams, and this is going back to our agency days, but I sort of sort of still see this happening now is that building the design system, you know, let me separate these two things. I think designing components and building the design system in the sense of picking styles, and choosing fonts, and iterating upon something like a search box or, a footer, or a modal that's a lot of work. That's just design and product design and product development in general.

+ +

But the act of, you know, creating the design system, maybe it's the documentation site, or however, we're communicating these standards across the organization. That part, to me, it's always kind of taken too much time and effort. And to be really candid, the amount of budget that's being allocated for those tasks is less. So, we're having a lot of users who are saying, "Well, I wasn't in charge of a design system. We had a team for that. We don't anymore. And now I'm responsible for it," or "The team's been combined, and I'm working on, like, three things at once."

+ +

And so, something that's very, very crucial to us at Luro is to help with the struggle of spinning up a design system. For us, I fully believe that there are design systems that can be fully custom available to the public and need to have, you know, every page and view needs to be unique unto itself. But for Luro, the starting place that we get you with, you know, you can link in your Storybook. You can link in Figma components. You can add components manually and all those sorts of things. Where we can get you in a few minutes is really close.

+ +

And then, if you started to fold in, you know, the idea of performance, accessibility, and then all of the other insights that you can then integrate, so if you're doing A/B testing or user testing and doing research, and you want to make sure that that's all involved inside of your design system, then it becomes a really attractive option. So, I think that decreasing the time it takes to get started and to spin up a design system is the number one thing we see people struggling with and the number one thing we want to bring.

+ +

I kind of like to compare it to services like Netlify. Like, I remember I used to have to set up servers to demo things for clients, and it would take an hour, and I don't know what I'm doing. And I would break stuff, and they would have to help me fix it. So, then I'm bothering him. And then, now I'm just, you know, will either link to a CodePen or drag and drop a deployed URL from something like Netlify. And it's this amazing, almost like it feels like deploying is just as difficult as, like, sketching something out on a napkin.

+ +

We want spinning up a design system to kind of feel that way so it's not so precious. You're not worried about...it is just easy to get started. And so, we're kind of integrating all these other tools that you use to make that easier and quicker because if you do have other things that you're working on and you need to move beyond that so that you can focus on prototyping, or designing, and building the actual components, you can do that. And you have that option as opposed to having to be mired in some of these other details.

+ +

VICTORIA: It seems like change management and integrating change into larger organizations is always the biggest challenge [laughs], even for great innovations. And I'm curious: what types of people or groups have you found are quick to adopt this new method and really the right group for you to center your message on?

+ +

TRENT: Yeah, it is...I was joking, I think, maybe before the podcast started, but it's, like, very ambitious because it's easy, I think, to say, "This tool is for designers. And if you're a designer, you can integrate your Figma, and then you'll have your components published to your team so that they can use them." And that's absolutely true. Like, if you're a designer, Luro is for you. If you're an engineer and you have just received components, and you need a way to document that and show your coded version alongside the design version and be able to collaborate with people in that sense, it is absolutely for you as well.

+ +

So, you can see how it's almost like you almost have to frame Luro for individuals across the organization. So, it's one of those deals where...and we've kind of experimented with this with the marketing. And the way we've discussed it, we talked to lots of, you know, leadership, heads of product, CMOs, even CTOs, things like that. And so, it's like, if you're trying to get your entire organization to work better, to ship, you know, more effectively, then Luro is the tool for that as well because we're getting into knowledge retention via uploading.

+ +

Like, my favorite story there is if you're an A/B tester, probably, and this is what we've experienced, is you run these tests. A lot of time and effort goes into building the prototypes for the test, whether that's you or an engineering team that's doing those things. This is one of the things we used to do as an agency. We would be brought on to prototype something totally new. We would test that alongside the existing experience. And an A/B tester, we'd work with them, and they would create, like, a PowerPoint or something that would explain the pros and cons and what should happen next and summarize the test.

+ +

And that would live on that person's hard drive, whether it's on their computer or, like, a Dropbox or a OneDrive account. And no one ever thought about it ever again. You would just move on to the next test. But the amount of money spent on us to build the prototype and the amount of money spent on the SaaS to spin up the, like, A/B testing environment and all of these things, and then the time spent on the A/B tester to analyze the results and generate a PowerPoint it's not nothing.

+ +

And so, one of the things that we find pretty appealing for leadership within Luro is the idea of integrating all of these tools and all this work that you do in mapping them to components so that when you pull up, for example, a button component, you'll see all the user tests that have been added over any period of time. So, if you were a new hire and you're trying to onboard, you can go interview everybody in the organization and ask them about the history of a button or a card component or the history of a sign-up page.

+ +

But then, also, in a self-service way, you can just click into Luro, click a button, click a card, click to the sign-up page, any of those things, and find all that stuff I was mentioning earlier, whether it's a test, or research, or prototyping, or any kind of documents that have been written. These aren't the arguments that Dave or I might have around the actual border-radius value. Those are small things that probably should be lost in the firehose.

+ +

But if we have learned an outline button with a stroke is performing way better than a solid-filled button or vice versa, that's important information that doesn't need to disappear in six weeks. So, that's the other kind of metric there is explaining kind of the holistic version, telling the holistic story of Luro to those types. And so, yeah, navigating that and trying to get, like, buy-in on a broad level is kind of what we're working on these days now.

+ +

WILL: Sweet. So, I actually really like how it's almost like version control. You can see the history of what you've been working on. And I really like that because so many times...you're correct. When I go to Figma or anything, I'm like, why are we doing it this way? Oh, we made these decisions. Maybe in comments, you can kind of do it, but I think maybe that's the only place you can see the version control. So, I like that feature. Like you said, you can see the history of why you did something like that.

+ +

TRENT: Yeah. And think about that, so if I am a front-end engineer and I receive a design and everyone thinks that, why are we doing it this way? I would hate to code something...I can do it. It's my job. But if I don't understand why, my feeling about work and maybe the quality of my work goes down, you know what I mean? I guess what I'm trying to say is, like, feeling like you understand, and you're lockstep with the entire team, and you understand what the goal is...what are we trying to do? What are we trying to achieve? Like, what have we reviewed that has made us believe this?

+ +

And if you don't have that information, or if I don't have that information, like, there's some traction within the team, whether it's actual momentum forward and the amount of tickets that are being closed, or just the spirit of what we're doing, that the product is going to be diminished. These are all these little things that add up, up, up, up, up over time. So, being able to show this information to be able to access this information kind of passively.

+ +

So, for example, if you got VS Code open and Luro open and you can see here's the user test from six weeks ago that shows us why we went with option B, you'll say, "Okay, cool. Even better." You know, you can review those things way before you get things handed to you. You know, it's much more kind of this utopian vision of an open, collaborative deal.

+ +

And the way I would say that is it's, you know, we all kind of hand things off. So, of course, like, there's some version, even if it's like a micro waterfall that happens on a daily basis. We're all doing that. Like, somebody needs to be done with something to hand it off to something else, so we're not all up in each other's space all the time.

+ +

But one thing that we like about Luro, whether we use Teams, or Slack, or whatever, it's not a real-time thing where I have to say, "Stop, look what I'm doing [laughs]. Come over here and look because I need you to know this." You can get notifications from Luro, but it's not something that is a context-switching demand type of a situation.

+ +

So, the idea is if you're like, I'm wondering what's going on. I know this is coming up. I'd like to review. Or I could let you know and tell you, and just on your own time, you can go see this. So, separate from, like, the firehose of tickets and chats, you can see the actual product evolving and some of these, like, key milestone decisions on your own time and review them. And if they've happened before you even started on the project, then you can do that as well.

+ +

WILL: I think that's probably where the breakdown between developers and designers that collab that's where it probably breaks down, whenever you're trying to get your tickets out as a developer. And then there's a change while you're working on it, and it's a complicated change, but you're still responsible for trying to get that ticket out in time. So, I think, like, what you're saying, you can get it beforehand.

+ +

So, it sounds like, to me, Luro would be a huge help because you have to have developers and designers working together; if you don't, you're just in trouble in general. But anything that can help the relationship between the two I think, is amazing, and that's what I'm hearing whenever you're talking about Luro. It helps. It benefits that relationship.

+ +

TRENT: Yeah, that even makes me think a little bit about the ongoing collaboration aspect. So, it's like, if something is shipped...or maybe let's go the agency scenario here. You've launched a site. You've launched a product. How do we know how it's performing? Of course, you'll have everybody...they're going to have analytics, and we'll be talking about that. And are signups up or down? But Luro will run tests. It'll continue to run component analytics. So, you can sense whether, like, somebody is changing a component. Or, you know, is the fully adopted design system not being utilized or being utilized less or more over time?

+ +

But then, also, we're running, again, performance and accessibility metrics. So, we've seen it where we've shipped a product for a client. You know, we've had Luro running. We've sort of used that as our hub to collaborate over time. And then we'll notice that there's a giant performance spike and that, like, the page speed has gone way down. And we itemize issues and can point you to exactly the page that it's happening on and give you some insight into that. Of course, you could go through after you've worked with the client and run Lighthouse on every single page in your own time for fun, but that's not reality or fun.

+ +

So, you'll get this information. And so, you almost...before we were telling people who were using Luro, we were kind of using it ourselves just to help ourselves do a better job. About a month into a project, we were able to email a customer, a former client, and say, "Hey, site's looking great. Amazing to see this. There's a 3-megabyte, 50-pixel avatar. Someone uploaded a giant image. It displays as 50 pixels. But somebody must have uploaded the full one to your homepage, and your page speed score tanked."

+ +

They're like, "Oh, wow, they must [laughs] be monitoring us and checking in on us every day." We love them dearly, but we were not doing that. We were using Luro off to the side. So, there is this other aspect of just sort of monitoring and making sure things stay, you know, as they were or better once we ship things and move forward to the next.

+ +

VICTORIA: That's really interesting. And I'm excited to explore more on my own about Luro. As we're coming towards the end of our time today, I wanted to give you one last chance to shout out anything else that you would like to promote today.

+ +

TRENT: Oh, that's it [laughs], luroapp.com, you know, that's the main thing. Check out component analytics. We have a YouTube channel, and I would say that's probably the easiest, a lot of effort, even though the videos maybe I'd give myself an A-minus or a solid A, not an A-plus on video production. I'm trying to get better. But explaining just, like, how to set things up. There's, like, a one-minute, like, what is all this?

+ +

So, if you want to see all the things that I've been trying to describe, hopefully well on the podcast [chuckles], you can see that really well. So, I'd say Luro App and then the YouTube channel. We've got, like, five, six videos or so that really kind of help get you into maybe what your use case would be and to show you how easily things are set up.

+ +

VICTORIA: Great. Thank you so much for joining us today, Trent, and for sharing about your story and about the product that you've been building.

+ +

TRENT: Yeah. Thank you for having me. This has been great fun.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Victoria Guido and Will Larry are joined by Trent Walton, CEO of Luro. Trent shares his journey into the design world, from his early fascination with typography and logos to co-founding Paravel. This agency later evolved into creating Luro, a no-code solution for building design systems and tracking their adoption across products.

+ +

Trent emphasizes the importance of understanding the materials one works with in design and development and stresses the need for a holistic approach to product building. This approach blurs the lines between disciplines, encouraging a generalist mindset over specialization. Luro, as a product, stemmed from the realization that existing design systems often fell short in adoption and application, leading to a search for a more integrated and comprehensive solution.

+ +

Trent outlines the functionality and vision behind Luro, explaining how it serves not just designers and developers but entire organizations by fostering better collaboration, documentation, and understanding of design decisions. Luro aims to streamline the creation and maintenance of design systems, making them more accessible and manageable, even for teams facing resource constraints. By incorporating performance, accessibility metrics, and the ability to track component adoption and integration, Luro provides a platform for continuous improvement and alignment with organizational goals.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with me today is Trent Walton, CEO of Luro. Luro is a no-code solution to build your design system and track adoption across your entire product. Trent, thank you for joining me.

+ +

TRENT: Oh, thanks for having me. It's great to be here.

+ +

WILL: Yeah, I can't wait to dive into Luro and get to know more about the product. But before we go into that, tell us a little bit about yourself. I know you're based out of Texas.

+ +

TRENT: Yeah, I grew up, lived here my whole life. I'm in Austin with the other co-founders, Dave and Reagan. Been a designer probably all my life, always been interested in, like, typography and fonts. When I was little, I used to buy badges for cars from swap meets and take them home, not because I needed, like, I had a car I was building and had any interest in, like, sandblasting or building an engine. I just liked the typography, and the design of the icons, and the logos, and all that kind of thing.

+ +

And so, now it's evolved into me just being, like, a type aficionado and a graphic design aficionado, and then that evolved into, especially when I discovered the web in the early 2000s, building and designing websites with Dave and Reagan, who I mentioned. And so, we had an agency called Paravel early on and had a lot of time putting into practice kind of that design and development and building for the web.

+ +

VICTORIA: So, your first interest in design came from, is it a car engine? Is that what I heard?

+ +

TRENT: Well, yeah, my father is a mechanical engineer, and so is my brother. And they work on cars, have classic, like, old Mustangs and Cobras and things that they build in their spare time. And I have no interest in that kind of work [laughs] but grew up in that environment. And, you know, pre-internet growing up in the '80s, one of the things that really got me was the aesthetic and the design around those kinds of muscle cars, so, like, old Shelby or Cobra or Mustang Ford ads, just, I really got into that.

+ +

So, I'd buy, like, car manuals for a few bucks, or if there's a Mustang Cobra and there's a cool, like, chrome snake logo with a condensed uppercase typeface or some sort of lettering that says, you know, "Shelby Cobra." And that's when I realized [laughs] where my interests lie. You know, engines are cool. They sound cool. Fast cars are cool. But I was just totally, you know, enamored with the typography and the design aspect that surrounded those things, and then it just kind of evolved from there. Anything else I could get my hooks into, I picked up on.

+ +

VICTORIA: I love that because when I talk to people about design, for folks who don't have a background in it, they kind of think, oh, design, that's logos. You know, I'm redesigning my house right now. My husband is like, "Oh, it's picking the tiles and the colors. We can do that." And I'm like, "No, like, design, there's a lot more to it. Design is everywhere." Like, you can find design inspiration from car manuals [laughs], it's so funny that you bought those, or from random logo design and actually, like, really good design. If it's something that's designed well, you probably don't even notice it. You just flow and use the space or use the app as you're intended to.

+ +

TRENT: Yeah. And I also think that getting inspiration or starting ideas out from anywhere but the medium you're working in might be a nice little trick to bring some, like, naïve, fresh perspective to things. So, I try to go back to that stuff as much as possible. I have heaps of manuals I've bought off of eBay in recent years, yeah, things you wouldn't think you'd find on, like, you know, whatever, a graphic designer's bookcase, just anything to sort of break the monotony or break my own little lenses of what a website should look like, or what a logo or a brand should look like, how to step outside of that a little bit.

+ +

But it's funny because it really does go back to that initial sense of wonder I experienced at those really just, you know, we're talking, like, in a gross, swampy field in Texas with, like, funnel cakes being served at every corner, like, not the most slick, rad graphic designy vibe, but that's where it all started for me. So, I go back there as often as I can [laughs].

+ +

VICTORIA: So, how do you talk to founders or people who are thinking about building products? How do you talk to them about design and give them a where to get started approach?

+ +

TRENT: I don't know that I ever specifically talk about design or even maybe, like, engineering or about performance. I talk about all those things, accessibility, et cetera. I try to blur those lines as much as possible. It's maybe an idyllic thing that I've had for years. But going back to the agency days, I'll call them the agency days, but up until, like, you know, 2015, '16, Dave, Reagan, and I ran an agency called Paravel. And by nature, the three of us are some sort of a hybrid between a designer, maybe, like, a front-end developer. You know, Dave's more of an engineer now.

+ +

But we've all been very careful to make sure that we're generalists, which I don't know that that, like, career-wise that, might pay off long term, but I cannot work on the web any other way or talk about the web any other way. I've always felt like, I mean, there was the old, which we don't have to get into, gosh, but the debate on should designers code? But I think the essence of that is really, like, should we be familiar with the materials we're working on?

+ +

So, anytime I start to talk about designing for the web or designing a product, you want to make sure everyone has a clear understanding of the environment that they're working with. So, is it, you know, a website? And is performance important? And is our site that we're redesigning is it performant now? Is it fast or slow? Or am I a designer who only cares, and this is a thing that I have to fight inside of myself all the time?

+ +

So, I'm not trash-talking anybody, but, like, do I want to load a bunch of fonts and cool images, and is that my KPI is how interesting and engaging the visuals are? Which is a great one to have, but it also, you know, while you're talking about design, you have to consider all of these other things that can define quality for an experience. Maybe those other things don't matter as much from one person to the next. But the more they are in front of me, the more they evolve the way I perceive what I work on.

+ +

And so, I try to never really isolate any kind of aspect into maybe, like, a stage or a sprint that we're doing as a team. It's just sort of this holistic kind of hippie vibey way to look at sites, but I want to make sure that it's always, like, we're always starting from a very, very broad place that involves every aspect, and all team members and stuff like that.

+ +

VICTORIA: Well, I love that because I try to think about that in the same way from the other end, like, on the operations perspective when you're talking about site performance. And, you know, like, is the site responding fast enough? And it comes back to the question of, like, well, what is the experience, expectations of the user? And what's important to get done on the site? [laughs] And having those conversations, like, early on and integrating all these different teams from the design and development and operation side to have that conversation so everyone knows what is the goal of the site and what is the important aspects of the user experience that the system needs to be able to support?

+ +

So, I also like that you said that it's like, well, should you be familiar with the materials that you're using? [laughs] Thought that that was really cool. Like, I'm actually...my husband and I are renovating our home. And I'm talking about why we should invest in design [laughs], and part of it's because there's things to know about the materials. Like, if you're choosing a floor for your house, like, the designers will know, like, what's the durable ones? What's the ones that are going to fit your need, and your cost, and your budget? And so, like, they don't necessarily need to be a person who's going to lay the floors [laughs], but they need to know what to expect out of what you decide to use.

+ +

TRENT: Yeah, it's, like, all of these constraints. And so, being familiar with the real-world implications of the decisions we make, you know, inform that. So, yeah, I mean, I think that's pretty similar, too. It's like, well, you need this floor because it's more durable in this climate or whatever, same thing for, you know, the websites that we build. It's all contingent upon the outcomes that, hopefully, we can mutually agree on. You know, there's kind of a general sense of, like, performance is important, and accessibility is paramount and extremely important. But then there's some nuance to that as you get into some smaller decisions.

+ +

So, having these kinds of discussions early on and frequently and almost...the way I like to think about it is rather than, like, a check-in where we say, "Okay, this is it," but having a place where we can all look to check in and find information and share information that's maybe not so fast. One thing I like to think about is things get lost in chats and maybe even tickets, so as you're closing tickets and opening tickets. There's a bug. I solved it. It's gone. Can you send me this logo? Can we tweak this? These micro changes they open and close very, very quickly. And so, there's this firehose that happens.

+ +

And so, I find that having a place separate from that for discussing these things and remembering these things, and referencing these things while we are in our code editors or inside of our Figma or any kind of design tool that we use to sort of cross-reference and simmer on things as we think about the decisions that we have to make, as opposed to just knocking them out super quick, always being mindful of those constraints. And again, yeah, the [chuckles] materials we're working with, whether it's just, you know, HTML, CSS, and JavaScript or whatever, but all of those things. It's good to be mindful of that.

+ +

WILL: I know you said that you've been in design for a while, and so I love just picking the brain of someone who's been into it a while and see how far we've come from, especially just the 2000s. So, in your opinion, with design, how do you feel about where we've come since the beginning of tech to where we're at now and, also, I guess, where we're going with the design?

+ +

TRENT: Yeah. So, I guess I can really just frame...this is going to help me remember just framing [laughs] where we were. I started off on Homestead, which is sort of like GeoCities. I was in college. I graduated, and I think it was 2001, maybe 2000, anyways. And it was mainly just taking images...I didn't even have Photoshop at this point. And you realize you could, like, tile a background for a build your own website. Homestead was one of those kinds of deals. And I thought that was very interesting. So, I had this cheap digital camera. It took a lot of cords to figure out how to, like, port that onto this old, crappy Hewlett Packard computer that was, like, a hand-me-down.

+ +

Fast forward a couple of years, I had graduated, did not study design, so I'm all kind of self-taught or just taught by the web, the peers, the information that has been shared and been influenced by. But Dreamweaver was out, and Macromedia was huge, and I loved Fireworks. And so, Dave Rupert, I paid him $80 to teach me HTML [laughs], and so we've been together ever since. This is right out of college.

+ +

And so, the tools that we used there were pretty rudimentary, but Fireworks was rad. Like, it was kind of web-based. It felt like it made more sense. I love Photoshop, and that's kind of, like, a primary graphic design tool that I still use to this day. But early on, it just felt like everything was so harshly limited.

+ +

So, if you had any kind of idea that you wanted to execute that you could just draw on a piece of paper, mock it up in Photoshop, the amount of work that you had to do to get that to happen was either extremely high, or it was just impossible. And then, if it was impossible, I bet you can guess what we did. We went to Flash, and we made, like, a crappy video of a web page that was not accessible and really hard to use. I was heavy into Flash for, like, two or three years until kind of, as I had been warned by Dave that, you know, HTML and CSS are going to be the way the web works.

+ +

But when I came back to that, there was this wonderful time where it felt like we were charting out every single...it was just new territory. It's like we had come to this other planet or this other world, and everything that needed to be done, we had to figure out how, like, getting web fonts onto pages, rounding borders. I mean, getting that done aside from slicing images in Fireworks felt like this new monumental discovery that changed the lives of many. Maybe it did, maybe it didn't, but in my world, it felt like that.

+ +

And so, early on, you can look back on it and go, gosh, everything was a pain in the ass, like, living with all of these limitations. But for me, I do look back at it like that, but I also look back on it as this wonderful time where we were building the web that we're working on now. So, all these things that make designing easier and quicker come with some sort of a, you know, an evolution of your perception, and [inaudible 13:14] fond memories of work along the way.

+ +

For me, it's sort of I've just always sort of been around working on the web and watching design evolve, and every little step maybe feels like a tiny one or a large one. But these days, it just seems like, oh, this is exactly how it should have [laughs] always been, like, convenient grids and convenient box shadow and all that kind of stuff.

+ +

But yeah, it's been nice to sort of grow up only being a web designer. Like, I mean, I've done graphic design. I've done brochures and, print design, and logo design for sure. But, I have always been anchored to and centered around web design and thinking about things in the context of how they will be applied to the web first and foremost.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: So, what was the turning point for you that led you to found Luro? How did it all get started?

+ +

TRENT: With Paravel, the agency days, we had a lot of fun. I think, for us, our big agency spike was when responsive web design came out. Ethan coined the term. There was a lot of people on the web, you know, a lot of agencies or a lot of teams, a lot of companies that needed to pivot into that. And so, we found this great working relationship with companies where we would come in and sort of had a little bit more practice just because we got in early learning kind of how to do that well, I think.

+ +

And it was a sort of we're going to redesign a page, a homepage perhaps, or, like, a marketing page. You'll do that project; three to six months go by. And then the next thing turns into, well, we have this giant network of e-commerce stores. We have this giant network of pages with, like, download centers and support documents. And now, we need to make everything responsive, and it can be anything. We need to make everything accessible. We need to make everything performant. We need to update the brand on everything.

+ +

And I don't think we're alone in this. I think this is the beginning of the greater design system discussion as it applies to the web. Obviously, design systems predate the web; design systems pre-date, like, 2012 or '13 or whenever we got into it. But projects started to migrate from, "Hey, can you design this really amazing, responsive marketing page," to "We have a system, and we need you to solve these problems." We love working on those problems. I still do to this day.

+ +

But the reason why we switched from kind of being a, you know, individual contributor-type agency consultant type roles to building a SaaS product was because we were realizing that things got complicated...is a very, like, boring way to say it. But to get a little deeper, it was, we would see things not ship. So, like, our morale went down. The teams that we were working with morale kind of went down. And as I was digging into why things weren't shipping...and when I mean ship, I think, like, pages would ship, of course. Like, here's a page. It just needs to be built, somebody decided, or a new feature needs to be built. Of course, those went out.

+ +

But the idea of, is our design system or the system that we're designing launched? Is it applied? Is it fully adopted? Is it partially adopted? It never felt like the amount of traction that we were promising or that we were being asked for. And I don't mean we, as in just the three of us, but the entire team or the entire organization who, in many cases, all were bought into the idea of design systems.

+ +

So, what we found was, when things got real, and we had to give up things, and we had to work on things and prioritize things, it became much more difficult to work in that capacity, probably partially because of the cross-discipline nature of those things. So, as opposed to what I consider maybe a miserable way to work in many cases, is the classic; here's my Photoshop comp. And I have a red line document JPEG that I will give you, whatever engineer I'm working with, or it's myself, and I'm just giving myself a red line document, but you're just going through and trying to make those things match.

+ +

And that is sort of not fun for the team because now we're just sort of chiseling each other and sort of, like, going through and critiquing our work over and over versus really kind of in the spirit of prototyping and inventing together. I find that products are diminished when you do that.

+ +

So, as you try to get into this design system part, it requires a lot more insight into what everyone around us is doing, kind of, as I was saying at the beginning, how to have this cross-discipline view of what we are actually working on. And that view is what we thought, and we still believe in many cases, is absolutely missing. So, you can spin up a design system. And Luro is not the only design system tool. Of course, you can spin up your own. And what I mean by that is, like...I'm maybe going to answer, like, three questions in one. Maybe you haven't even asked them yet.

+ +

But just to kind of frame this, if you ask anyone what a design system is, it might be a different answer. It might be these are my Figma components that I've created and I've shared out, and there's a public link. You know, an engineer might say, "Well, it's the GitHub repo of components that I'm actually using." So, the design is helpful as documentation. But the design system is the code, or the design system is the actual...or the actual components that are live that users see, which I would argue probably is the most accurate, just because we're talking about user experience impacting whatever business objectives we may have.

+ +

So, those components need to make their way into live sites or products. So, finding out what that answer is, what's the source of truth? What is our design system? What are our components? What are our standards? You have to have multiple sources for that, just because there's multiple people with multiple opinions and multiple measures of success involved in those. And all of those opinions and measures of success, I would say, are valid. So, accounting for those and kind of crossing the streams, if you will, in one sort of central UI, we believed was crucial enough that we should jump out of the agency days and into a product-building scenario.

+ +

VICTORIA: That's really interesting. So, you saw this pattern in the delivery of your work as an agency that made you want to build a solution to create better outcomes for a potentially exponential number of clients, right? [chuckles]

+ +

TRENT: Yeah, hopefully. I think that working on how you work together as a team is vitally important, and if you can find the right environment, then the actual product will benefit. I mean, and I'm not even just thinking about these maybe soft things like, oh yeah, if engineers and designers can work together, the typography will be a little bit better, and the site will feel a little bit more cohesive, and it'll be maybe a little bit easier to digest. I believe that.

+ +

But I also believe that there are people in organizations doing research, financial analysis, customer analysis, A/B testing, you know, all sorts of work that contributes to the decisions that we make about our sites and products that sort of just gets lost in the shuffle, in the firehose of the day to day. So, having something that takes not only a, I guess, what you could classify as the what for a design system, it could be the design of a component. Maybe it's actually even, too, as well, the code that makes up that component. But then there's this giant why. Why does the button look the way that it does? Why does a card have a border around it? Why? Why? Why? Why? Why?

+ +

These things maybe they come up during meetings. Maybe there's something that, as a designer or an engineer, I found maybe on the company's shared OneDrive or somebody mentioned in passing. Those things are vitally important, and they need to be, again, back to the morale and perception evolving; they need to be accessible to everyone. But it's a needle-in-a haystack situation.

+ +

It's funny. We would consult. And one of my favorite stories is we were building this prototype. We were hired to build a prototype for a startup in Austin. They were on a big, open floor-plan office with the glass meeting rooms. And we were showing off our prototype, and we just felt really clever and witty about the way we were going to solve this and the pages that we were going to build.

+ +

And who is a friend now, a person named Angela walks by, and she's like, "What are you working on?" And we told her what it was. And she says, "Oh, wow, you know, six months before you started contracting with the startup, we did this all, and we've user-tested it. Everybody's been reorged, and nobody remembers. But I have this PowerPoint I can send you, and it will show you the results. Some of these things you're doing are probably going to be great. The other things you should absolutely not be repeating these mistakes."

+ +

And I thought about how likely it was that she walked by and happened to see that through the window and happened to look on the sharp television on the wall. And it's probably not very likely, and as we become, you know, we're remote and working remote the likelihood of those things happening maybe goes down. The idea of building a product that increases the likelihood or almost makes it seamless that you can find information relevant to what you were working on, even if you're new to that project or you haven't worked on it for a long time, is very, very key.

+ +

So, within Luro, you can build a design system. You can add your styles. You can add your components, configure your tokens, and do all that, but you can also integrate those things that I was mentioning: prototyping, research, and testing. We also do an accessibility and performance through Lighthouse and give you metrics there. All of those things are associated to the pages that your site is comprised of. They're associated to the components that you use to build everything. So, we're sort of crossing the streams here.

+ +

So, if you're going into imagine a button component and you're like, okay, the border-radius is four pixels. The type size is 16 pixels, and here's how you code it. We're putting in an actual button. The class is dot btn. That's all great. It's helping us build the button. But if you are asked by leadership or anyone, "Why did you decide this?" Or "What is the impact of design?" Or "What is the impact of the product team on our bottom line? How are you moving the needle? How are you helping us as an organization achieve?" The answer isn't, "Well, we made the border four pixels just like the design [chuckles] said." That's great. Good job.

+ +

But I think having all of this information associated with design and associated with engineering not only makes us more informed as contributors to teams but it helps us to articulate the value of what we do on the daily in a much more broad organizational sense.

+ +

So, you can say, "Well, we user-tested this, and we realized that if we took out these form elements from a signup flow, we get more signups by having fewer steps. And so we removed a step. We user-tested it before and after, and signups went up 30%." That's a much cooler answer than, "Well, our design system helps us be consistent," even though we know that that is vitally important, and it makes our app or our site feel much more cohesive, and it contributes to that sign up metric or a sales metric just as much.

+ +

But having this data and associating it with a component so it's not something that you have to sort of...I guess it almost sounds subjective if you bring it up and say, "Well, we're moving faster, and we're selling more stuff." That's not great. But if you can link and say, "Well, here's a PowerPoint before," or "Here's a summary of a user test before and after. Here's real numbers," it helps you to portray yourself as the designer or engineer or product team member who thinks very deeply about these things, and it helps you to accurately portray yourself in that way.

+ +

So, I went on a real tangent, but actually just there, I think I just was describing sort of the nuts and bolts of why we built Luro to not only be a design system tool but, like, what we kind of also call a product development tool, a product development system. So, it's extending the idea of design systems to the practice of building a product with an entire organization.

+ +

WILL: That's really, really cool, and you did a great job explaining it. I'm excited to see it and see where it's going. I felt like a lot of what you were saying was the why you're doing stuff, why you chose, you know, X, Y, Z. Is that where the analytics and the tracking portion of Luro comes into play?

+ +

TRENT: Yeah. I think that one thing we heard a lot from agencies or even just teams within an organization that are working on design systems is back to that articulating the value of maybe a design system or articulating the value of the work that we do as designers or product builders and similar to we've done a user test and these are the results, and sales or signups, or whatever the case may be, have improved. I think one of the key metrics for a design system is, is the component adopted? There are other ones, and people will mention those, things like, is it helping a team be quicker?

+ +

So, if there's a design system team, and then there's multiple product teams within an organization, and they all want to work together, and they want to be able to take the components that they need and build their ideas quicker, prototype quicker, that's a great metric as well. But one that we find vitally important is, are the components live to users? And so, being able to track that has a lot of value. One, obviously, is that communicating that to the greater organization, saying, "You know, we've spun up a design system team. The card component is on 49% of pages. The button is on 100% of pages."

+ +

And then if you're trying to be more tactical about how to improve the product or even just track down, you know, which components or which pages or which experiences aren't, I guess, consistent with the design system, you can say, well, "There's 49%, and there's 51% of pages that may or may not have the card component." And so, you can go find outdated components if you're trying to phase new ones in, and all of those sorts of things as well.

+ +

So, the metrics are sort of great from a thematic sense, saying, this is the value that our design system is, you know, affording us as a business and the users are experiencing while they're using our app or our site. But then, also, you can drill down into these metrics and see, okay, the button is appearing here. I can click into pages and see views where it's being used on the page level and see, is it being used properly? Those kinds of things.

+ +

You can track legacy components as well, so, for example, if we've rebranded the site that we all work on together and our old button was, like, dot button and the new button is dot BTN or however we would want to class those things. And you can use classes. You can use data attributes, all those kinds of things. But I would say we can track legacy along that.

+ +

So, if your goal is to completely adopt the new design system across the entire network and products within six months or whatever the case may be, you know, month over month, week over week, you can check our, you know, line graphs and see, hopefully, the legacy occurrences of that going down over time. So, if, like, the button is being used less and less and then the dot BTN is being used more and more, you can see those sort of swap places.

+ +

And so, what we have found is talking about things in sort of an objective or fuzzy way, saying, well, we're trying to ship this, and we're doing these inventories, and we're going through all the pages. And we're clicking around trying to find old things, or we're redesigning pages. But it's very, very difficult. This is just an instant quantification of where our components are manifesting in the product.

+ +

So, what we do is, with Luro, you can give us...whether it's behind an authentication layer or not, we crawl web pages, first and foremost. So, you can give us a site. And this is all optional. You can spin out a design system without this. But we crawl the site, and then we will go ahead and do performance and accessibility scores for there.

+ +

So, that's one way to itemize work, where you can just say, well, as an agency, we're going to work with this company, and we want to show them, like, the starting point and expose weak points on where we might be paying a lot of attention to. In the design or engineering phase, we need to improve the speed here. We have accessibility violations we need to think about, all that kind of stuff.

+ +

And then, once you crawl those, you can add your design system, and then you can cross-reference those, and I kind of mentioned that. You can use CSS classes to do that. And so, you'd enter in dot BTN for button. We've already crawled your pages. And so, we can tell you every time that that class appears inside of any page inside of the network. So, it's this very, like, two-minute way to get a wealth of information that's shared and communicated with...the entire organization will benefit. Like I said, like, leadership they can get a sense of how the design system is being used and adopted, but also, the active teams working on things so that they can go find outliers and work on replacing those.

+ +

VICTORIA: It's been over a year in your journey with Luro. What challenges do you see on the horizon?

+ +

TRENT: I still think it is an adoption challenge. I think that, you know, one thing that we found is that a lot of teams, and this is going back to our agency days, but I sort of sort of still see this happening now is that building the design system, you know, let me separate these two things. I think designing components and building the design system in the sense of picking styles, and choosing fonts, and iterating upon something like a search box or, a footer, or a modal that's a lot of work. That's just design and product design and product development in general.

+ +

But the act of, you know, creating the design system, maybe it's the documentation site, or however, we're communicating these standards across the organization. That part, to me, it's always kind of taken too much time and effort. And to be really candid, the amount of budget that's being allocated for those tasks is less. So, we're having a lot of users who are saying, "Well, I wasn't in charge of a design system. We had a team for that. We don't anymore. And now I'm responsible for it," or "The team's been combined, and I'm working on, like, three things at once."

+ +

And so, something that's very, very crucial to us at Luro is to help with the struggle of spinning up a design system. For us, I fully believe that there are design systems that can be fully custom available to the public and need to have, you know, every page and view needs to be unique unto itself. But for Luro, the starting place that we get you with, you know, you can link in your Storybook. You can link in Figma components. You can add components manually and all those sorts of things. Where we can get you in a few minutes is really close.

+ +

And then, if you started to fold in, you know, the idea of performance, accessibility, and then all of the other insights that you can then integrate, so if you're doing A/B testing or user testing and doing research, and you want to make sure that that's all involved inside of your design system, then it becomes a really attractive option. So, I think that decreasing the time it takes to get started and to spin up a design system is the number one thing we see people struggling with and the number one thing we want to bring.

+ +

I kind of like to compare it to services like Netlify. Like, I remember I used to have to set up servers to demo things for clients, and it would take an hour, and I don't know what I'm doing. And I would break stuff, and they would have to help me fix it. So, then I'm bothering him. And then, now I'm just, you know, will either link to a CodePen or drag and drop a deployed URL from something like Netlify. And it's this amazing, almost like it feels like deploying is just as difficult as, like, sketching something out on a napkin.

+ +

We want spinning up a design system to kind of feel that way so it's not so precious. You're not worried about...it is just easy to get started. And so, we're kind of integrating all these other tools that you use to make that easier and quicker because if you do have other things that you're working on and you need to move beyond that so that you can focus on prototyping, or designing, and building the actual components, you can do that. And you have that option as opposed to having to be mired in some of these other details.

+ +

VICTORIA: It seems like change management and integrating change into larger organizations is always the biggest challenge [laughs], even for great innovations. And I'm curious: what types of people or groups have you found are quick to adopt this new method and really the right group for you to center your message on?

+ +

TRENT: Yeah, it is...I was joking, I think, maybe before the podcast started, but it's, like, very ambitious because it's easy, I think, to say, "This tool is for designers. And if you're a designer, you can integrate your Figma, and then you'll have your components published to your team so that they can use them." And that's absolutely true. Like, if you're a designer, Luro is for you. If you're an engineer and you have just received components, and you need a way to document that and show your coded version alongside the design version and be able to collaborate with people in that sense, it is absolutely for you as well.

+ +

So, you can see how it's almost like you almost have to frame Luro for individuals across the organization. So, it's one of those deals where...and we've kind of experimented with this with the marketing. And the way we've discussed it, we talked to lots of, you know, leadership, heads of product, CMOs, even CTOs, things like that. And so, it's like, if you're trying to get your entire organization to work better, to ship, you know, more effectively, then Luro is the tool for that as well because we're getting into knowledge retention via uploading.

+ +

Like, my favorite story there is if you're an A/B tester, probably, and this is what we've experienced, is you run these tests. A lot of time and effort goes into building the prototypes for the test, whether that's you or an engineering team that's doing those things. This is one of the things we used to do as an agency. We would be brought on to prototype something totally new. We would test that alongside the existing experience. And an A/B tester, we'd work with them, and they would create, like, a PowerPoint or something that would explain the pros and cons and what should happen next and summarize the test.

+ +

And that would live on that person's hard drive, whether it's on their computer or, like, a Dropbox or a OneDrive account. And no one ever thought about it ever again. You would just move on to the next test. But the amount of money spent on us to build the prototype and the amount of money spent on the SaaS to spin up the, like, A/B testing environment and all of these things, and then the time spent on the A/B tester to analyze the results and generate a PowerPoint it's not nothing.

+ +

And so, one of the things that we find pretty appealing for leadership within Luro is the idea of integrating all of these tools and all this work that you do in mapping them to components so that when you pull up, for example, a button component, you'll see all the user tests that have been added over any period of time. So, if you were a new hire and you're trying to onboard, you can go interview everybody in the organization and ask them about the history of a button or a card component or the history of a sign-up page.

+ +

But then, also, in a self-service way, you can just click into Luro, click a button, click a card, click to the sign-up page, any of those things, and find all that stuff I was mentioning earlier, whether it's a test, or research, or prototyping, or any kind of documents that have been written. These aren't the arguments that Dave or I might have around the actual border-radius value. Those are small things that probably should be lost in the firehose.

+ +

But if we have learned an outline button with a stroke is performing way better than a solid-filled button or vice versa, that's important information that doesn't need to disappear in six weeks. So, that's the other kind of metric there is explaining kind of the holistic version, telling the holistic story of Luro to those types. And so, yeah, navigating that and trying to get, like, buy-in on a broad level is kind of what we're working on these days now.

+ +

WILL: Sweet. So, I actually really like how it's almost like version control. You can see the history of what you've been working on. And I really like that because so many times...you're correct. When I go to Figma or anything, I'm like, why are we doing it this way? Oh, we made these decisions. Maybe in comments, you can kind of do it, but I think maybe that's the only place you can see the version control. So, I like that feature. Like you said, you can see the history of why you did something like that.

+ +

TRENT: Yeah. And think about that, so if I am a front-end engineer and I receive a design and everyone thinks that, why are we doing it this way? I would hate to code something...I can do it. It's my job. But if I don't understand why, my feeling about work and maybe the quality of my work goes down, you know what I mean? I guess what I'm trying to say is, like, feeling like you understand, and you're lockstep with the entire team, and you understand what the goal is...what are we trying to do? What are we trying to achieve? Like, what have we reviewed that has made us believe this?

+ +

And if you don't have that information, or if I don't have that information, like, there's some traction within the team, whether it's actual momentum forward and the amount of tickets that are being closed, or just the spirit of what we're doing, that the product is going to be diminished. These are all these little things that add up, up, up, up, up over time. So, being able to show this information to be able to access this information kind of passively.

+ +

So, for example, if you got VS Code open and Luro open and you can see here's the user test from six weeks ago that shows us why we went with option B, you'll say, "Okay, cool. Even better." You know, you can review those things way before you get things handed to you. You know, it's much more kind of this utopian vision of an open, collaborative deal.

+ +

And the way I would say that is it's, you know, we all kind of hand things off. So, of course, like, there's some version, even if it's like a micro waterfall that happens on a daily basis. We're all doing that. Like, somebody needs to be done with something to hand it off to something else, so we're not all up in each other's space all the time.

+ +

But one thing that we like about Luro, whether we use Teams, or Slack, or whatever, it's not a real-time thing where I have to say, "Stop, look what I'm doing [laughs]. Come over here and look because I need you to know this." You can get notifications from Luro, but it's not something that is a context-switching demand type of a situation.

+ +

So, the idea is if you're like, I'm wondering what's going on. I know this is coming up. I'd like to review. Or I could let you know and tell you, and just on your own time, you can go see this. So, separate from, like, the firehose of tickets and chats, you can see the actual product evolving and some of these, like, key milestone decisions on your own time and review them. And if they've happened before you even started on the project, then you can do that as well.

+ +

WILL: I think that's probably where the breakdown between developers and designers that collab that's where it probably breaks down, whenever you're trying to get your tickets out as a developer. And then there's a change while you're working on it, and it's a complicated change, but you're still responsible for trying to get that ticket out in time. So, I think, like, what you're saying, you can get it beforehand.

+ +

So, it sounds like, to me, Luro would be a huge help because you have to have developers and designers working together; if you don't, you're just in trouble in general. But anything that can help the relationship between the two I think, is amazing, and that's what I'm hearing whenever you're talking about Luro. It helps. It benefits that relationship.

+ +

TRENT: Yeah, that even makes me think a little bit about the ongoing collaboration aspect. So, it's like, if something is shipped...or maybe let's go the agency scenario here. You've launched a site. You've launched a product. How do we know how it's performing? Of course, you'll have everybody...they're going to have analytics, and we'll be talking about that. And are signups up or down? But Luro will run tests. It'll continue to run component analytics. So, you can sense whether, like, somebody is changing a component. Or, you know, is the fully adopted design system not being utilized or being utilized less or more over time?

+ +

But then, also, we're running, again, performance and accessibility metrics. So, we've seen it where we've shipped a product for a client. You know, we've had Luro running. We've sort of used that as our hub to collaborate over time. And then we'll notice that there's a giant performance spike and that, like, the page speed has gone way down. And we itemize issues and can point you to exactly the page that it's happening on and give you some insight into that. Of course, you could go through after you've worked with the client and run Lighthouse on every single page in your own time for fun, but that's not reality or fun.

+ +

So, you'll get this information. And so, you almost...before we were telling people who were using Luro, we were kind of using it ourselves just to help ourselves do a better job. About a month into a project, we were able to email a customer, a former client, and say, "Hey, site's looking great. Amazing to see this. There's a 3-megabyte, 50-pixel avatar. Someone uploaded a giant image. It displays as 50 pixels. But somebody must have uploaded the full one to your homepage, and your page speed score tanked."

+ +

They're like, "Oh, wow, they must [laughs] be monitoring us and checking in on us every day." We love them dearly, but we were not doing that. We were using Luro off to the side. So, there is this other aspect of just sort of monitoring and making sure things stay, you know, as they were or better once we ship things and move forward to the next.

+ +

VICTORIA: That's really interesting. And I'm excited to explore more on my own about Luro. As we're coming towards the end of our time today, I wanted to give you one last chance to shout out anything else that you would like to promote today.

+ +

TRENT: Oh, that's it [laughs], luroapp.com, you know, that's the main thing. Check out component analytics. We have a YouTube channel, and I would say that's probably the easiest, a lot of effort, even though the videos maybe I'd give myself an A-minus or a solid A, not an A-plus on video production. I'm trying to get better. But explaining just, like, how to set things up. There's, like, a one-minute, like, what is all this?

+ +

So, if you want to see all the things that I've been trying to describe, hopefully well on the podcast [chuckles], you can see that really well. So, I'd say Luro App and then the YouTube channel. We've got, like, five, six videos or so that really kind of help get you into maybe what your use case would be and to show you how easily things are set up.

+ +

VICTORIA: Great. Thank you so much for joining us today, Trent, and for sharing about your story and about the product that you've been building.

+ +

TRENT: Yeah. Thank you for having me. This has been great fun.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9rF1-zDP + + ]]> + + Will Larry + Victoria Guido + + + 516: Innovating Fashion: Charlotte Holt's Tech-Driven Approach + https://podcast.thoughtbot.com/516 + 8de46d6e-8c71-40b2-b7f7-4510e9bca199 + Thu, 14 Mar 2024 00:15:00 -0400 + thoughtbot + + full + 14 + thoughtbot + Hosts Will and Victoria interview Charlotte Holt, Founder of The Fashion Library, a London-based wardrobe rental resource for stylists. Charlotte discusses her journey from stylist to entrepreneur, highlighting The Fashion Library's mission to address environmental and financial challenges in the fashion industry by offering a rental platform. She emphasizes the importance of technology in driving sustainability and outlines her vision for the future growth of The Fashion Library. + 28:17 + no + + + Hosts Will and Victoria sit down with Charlotte Holt, the Founder and Creator of The Fashion Library. Based in London, The Fashion Library is a contemporary wardrobe rental resource tailored for stylists. Charlotte opens up about her diverse background, spanning various countries, and shares the transformative journey that led her from being a stylist to establishing her own venture. +Charlotte sheds light on the formidable challenges stylists encounter, from the environmental repercussions of fashion production to the financial constraints of traditional shopping methods. She articulates how The Fashion Library is poised to confront these obstacles head-on by offering a platform that enables stylists to rent clothing, fostering sustainability while saving valuable resources like time and money. +Delving into the realm of technology, Charlotte underscores its pivotal role in streamlining operations and catalyzing a paradigm shift towards a more sustainable fashion industry. She outlines her ambitious vision for The Fashion Library's future, encompassing the archive, broadening the user base, and creating a robust marketplace and working platform. +The Fashion Library (https://thefashionlibrary.co/) +Follow The Fashion Library on LinkedIn (https://www.linkedin.com/company/thefashionlibrary/), TikTok (https://www.tiktok.com/@thefashionlibrary.co), Facebook (https://www.facebook.com/thefashionlibrary.co), or Instagram (https://www.instagram.com/thefashionlibrary.co). +Follow Charlotte Holt on LinkedIn (https://www.linkedin.com/in/charlotte-holt-82343628/). Visit her website at charlotteholt.co.uk (http://charlotteholt.co.uk/) +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: + WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Charlotte Holt, Founder and Creator of The Fashion Library, London's newest contemporary wardrobe rental resource for stylists. Charlotte, thank you for joining me. +CHARLOTTE: Thank you for having me. I never ever thought I would be talking on a podcast. +VICTORIA: You never thought that? Why? What did you think would happen? [laughs] +CHARLOTTE: As in, like, I never thought I would be on a podcast, me personally. So, like, this is a new experience for me. +VICTORIA: Wonderful. Well, I know you're speaking with us today, and just to warm us up a little bit, I'm curious: what other languages could you be speaking to us in? What's your...I heard you learn multiple. +CHARLOTTE: So, I actually went to school in the south of France when I was younger. And for the last couple of years, I've been living in Mexico, so I've been trying to learn Spanish. I am pretty proficient in French and getting there in Spanish. +VICTORIA: Very cool. I live in San Diego, and I've also been learning Spanish for a long time and love to practice sometimes, so... What about you, Will? Do you speak any other languages? +WILL: I used to speak Spanish, but it's so hard when you don't live in that culture to keep it up. Because I've been to, like, Peru a couple of times and some other South American places, but I always pick it up when I go back in there and kind of get the feel for it, but it's kind of hard. I need to pick it back up. But Spanish is the one that I feel the most comfortable in outside of English. +VICTORIA: Right. We're a bilingual nation. And so, I love that opportunity to get to meet other people and speak in other languages and practice that. So, Charlotte, coming back to your journey, it sounds like you've lived in all these interesting places. Why don't you tell us just a little bit more about your background? +CHARLOTTE: I am from Scotland originally. I know I don't sound like it. And then I went to school in the South of France for two years, like, to finish high school. Then I ended up back in the UK, living in London for 12, 14 years. And then, just as COVID was happening, I was actually supposed to kind of relocate or start working more in the U.S., and I actually ended up in Mexico [chuckles], of all places, and that's where I stayed for two years. I was living the good life. +I had a pretty good COVID experience. I was at the beach every day surfing, so I can't complain about that. And then I've been living in the U.S. on the West Coast in Los Angeles before I decided to set up my new business, which has brought me back to London. +VICTORIA: Wow, full circle. Well, what beach were you surfing on in Mexico, or did you go to a bunch of different ones? +CHARLOTTE: I've been to a bunch, but I was living in Sayulita. I've still got a place there that I keep because I love to be in the ocean. It's one of my favorite things to do. Surfing is definitely a good lifestyle choice of mine. +VICTORIA: There's not much surfing in London now, so your desire to start your new company must be really powerful [chuckles], very strong. +CHARLOTTE: Yeah, I actually have questioned myself, especially over the last few months when it's been full, mid-winter here: cold, dark, raining. Like, what am I doing? Why did I give up my kind of dream life working between LA and Mexico, being able to surf, you know, at least two, three, four times a month to come back here to do this? But the bigger picture is, hopefully, I will be able to go and surf wherever I like after I've built this business. So, that's kind of the end goal for me. +VICTORIA: Yeah. Tell me more about what led you to start your own business. +CHARLOTTE: I have been working as a stylist for the last 12-plus years. And then, obviously, my work took me to the U.S. A friend of mine gave me his little black book contacts of where I should go and places I should use in LA. And I walked into a rental house there that was for industry only and got a lightbulb moment. I was like, oh my God, why is this not happening back in London? And it kind of didn't make sense to me because the productions back in the UK are, well, they seem more sustainable. Everyone's hitting their kind of green quotas and targets. +So, it just made sense to me, but not just from, like, the sustainability point of renting clothes, but also having an industry-only place that you can go to and basically prep most of your job in one go. So, it was, like, saving time on the start of the job but also on the end, which is the return side, which people don't always realize. +Everyone's like, "Oh, it's so glamorous working in fashion and styling." But we are bag ladies. I will often have minimum six, eight cases with me, rails and rails, racks and racks of clothes. I'm always the first one there. I'm the last one there because we're packing away. It's lots of steaming, just lots of stuff. So, to me, it just made perfect sense to recreate the same thing in London. But then I started getting into it a little bit more and started looking at tech and how that can transform what we're doing, too. +WILL: Before we get too deep into The Fashion Library, I want to, one, explain what a stylist does because, like I said, I am not fashion-forward or friendly. So, tell me kind of what that looks like to do. And also, how did you become a stylist? Was it a dream of yours always, or what did that look like? +CHARLOTTE: I just love clothes. So, I actually was going to be a lawyer, and I went to school to study law [chuckles], and I ended up being a stylist. So, there's different kind of realms and levels of a stylist. You can be a personal stylist where you work in the consumer realm, helping people dress themselves. Then, you have your editorial stylists who create beautiful imagery for magazines. Then there's the commercial stylists who work on advertising, film, TV production. Then you've got your celebrity stylists. There's different kind of layers within being a stylist. +I actually work across a broad range of that. I do editorials, so magazines. I've worked with some talent, music videos, TV commercials, short films, stills, and advertising campaigns. And what I really love is how different every job is. It's never the same. You're never with the same crew of people. Every job is different. Sometimes, you might be on set for just one day. Sometimes, you're on set for a week. There's weeks and weeks of prep that goes into the job. There's also a lot of work on the backend doing returns, and budgeting, and reconciling everything. You literally have to love clothes. +WILL: Where did your love for clothes come from? +CHARLOTTE: [chuckles] That's a good question. I always thought it was my mum, but, actually, it was definitely my dad. I look at pictures of him from the '70s, '80s. He's got some wild outfits on. And I've got some of his pieces. I've got this floral jacket that we all used to get dressed up in when we were younger because it's the most outrageous piece. I have it now. It's actually amazing. I actually had it on the other week with just a little black vest and some jeans. And because it's such a statement piece, it looks super cool, but it's classic '60s. So yeah, definitely from my dad. He had a wild penchant for clothes. +VICTORIA: I loved how you brought up, in the beginning, that the role of a stylist is often portrayed as being very glamorous and being very just so fun and creative and how the reality of it is that it's more carrying bags around, and picking up at the end of the day, and getting the clothes ready, and how tedious that can be. And you discovered technology could take some of that tedious out of the process and allow stylists to focus their time on the creative aspects. +CHARLOTTE: Yeah. So, originally, my plan with The Fashion Library was just to kind of replicate what was happening in the U.S. with the rental house models and just bring it here. And I have a friend who I met surfing in Mexico. He's in his 50s, very successful tech entrepreneur. And I wanted to run my business past him just to kind of get some outsider knowledge but someone who's been there and done it. +And he actually said to me, he was like, "This is great, but you should really, like, start to look at tech and how that is going to really transform businesses in the future." And he flicked that switch on, and that was it. Then, I think a couple of weeks later, I started sending him all my brain dumps about tech and what I was thinking in my mind. And he actually turned around and said to me, "If you can see it in your mind, you can build it." +So, I started to look at my pain points as a stylist. And I work differently in every city because you have to adapt. Like, in LA, I'm often out and about compared to London, where I work a lot online. So, I started to look at, like, the pain points of everywhere and what would really be beneficial. It always kind of dialed back to that question of, what would help me as a stylist? So, that's how I've built the business, by looking at that aspect and what's helpful, what's not. +WILL: Yeah, I like that view because I totally agree. Tech is in pretty much everything. It's all about, how can you see it to help you with your pain points? So, that's amazing that you sat back; you saw the pain points, and it helped you create what you're doing. So, that's really, really amazing. Can you tell me more about The Fashion Library? What does that look like? What did you create? What was your pain points? +CHARLOTTE: We launched in mid-July last year with a physical showroom of around 500 pieces, which was just my archive. And then I'd built out a very rough and ready Shopify to kind of replicate what was going on in the physical realm but in the virtual realm. I hadn't shot all those pieces, so it was maybe only 200 pieces online. And then, within two weeks, I'd managed to grow the archive to well over a thousand pieces, and then I was like, ugh, I need to get all this shot now. +And it's me doing all of this. I'm working with a friend who's a photographer. And I style all the pieces on a ghost mannequin. I've already thought about some techie idea in my head about how to get around that in the future. I don't know if it's possible, but I can see it in my mind. We can build it. So, I just wanted them both to kind of work in the physical and virtual realm, but then, obviously, always going back to John's advice from Mexico that, you know, really start to look more into the tech. +And the tech's definitely taken over. We haven't built any yet. We are currently about to start raising because we want to build a fully functional marketplace that's industry-only. There's going to be a phase three, which will be a whole working platform that will streamline the working process from start to finish with lots of clever little things thrown in. +And I don't want to give too much away on this because it is just in my mind right now. Obviously, it's on paper, too, but I've just been looking at what else is going on in the fashion realm, in the fashion tech realm, and there's lots of exciting things. There was a stylist who reached out to me just before Christmas. She's actually an avatar stylist. So, I was really interested to speak to her. They're currently creating avatars from humans. So, soon, everyone's going to be able to have their own avatar if they want. +But there's some really, really interesting and innovative stuff happening within the tech space, and there's definitely exciting things. And I can see a lot of scope in the future for The Fashion Library in terms of how we build the tech and adapt and how we kind of disrupt the industry, not just here in the UK, but globally. +VICTORIA: Thank you for sharing all of that. I think that's so interesting. And I also really love that you made the connection from surfing that got you excited about tech and excited about all these possibilities that you're describing. I'm just imagining, like, a little side conversation while you're paddling around out in the ocean [laughs]. But I don't know if that's how it really happened. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +VICTORIA: What's your method for engaging with the industry on this issue and building your customer discovery process? +CHARLOTTE: Obviously, it's something I'm really passionate about. I knew that there would be others out there, too. We've been hunting for the stylists currently, so LinkedIn, this platform called The Dots here, Instagram, obviously, and then also connecting, like, higher up the food chain with production companies, ad agencies, really kind of targeting it from the top bottom down. +And then, the last couple of months, we've been focused on finding some founding members who are busy working commercial stylists who love the idea of sustainability and rental and want to be early adopters and users of The Fashion Library. We've had great feedback from them. So, having that feedback from people and it being positive is like a driving force behind what we're trying to create and creating. +VICTORIA: Has there been anything surprising in your conversations that has caused you to maybe pivot in your strategy? +CHARLOTTE: I mean, definitely, when I first took the idea to my surfing friend in Mexico, he really made me pivot from bricks and mortar into tech. I was always going to build out a tech platform, but it was literally just going to be online rental, just because of how I like to work in the UK. I think talking to him that really opened my eyes. +And then, also, kind of going off and launching really then understanding what he'd said to me. Because I think after I launched, I realized that actually the bricks and mortar is nice, and it's really nice to have that space and the showroom as a showcase, but it's not where I want to be. I'm really excited and really focused to get the tech going. It's really exciting. And if we can create what I'm envisaging, I think it's going to be so useful. +VICTORIA: Yeah. And I love that you're really focused on a specific group and creating something for the industry that you're in. Can you share any other specific problems or challenges that a stylist may have with a wardrobe rental app versus a person like me who's just trying to, like, rent a dress for the weekend or something? +CHARLOTTE: Yeah. Well, that's the thing. I mean, rental is trending as a whole globally. So, there are a lot of consumer-facing rental apps and businesses out there. But the thing about stylists is it's quite a lonely career. Yes, you have your assistants, but until you're on set or with your clients, you're pretty much on your own. And I think after COVID, there was that real push for community. +And also, as stylists, we tend to sit on big archives that we've collected from jobs, or we've had custom pieces made that actually never went to set or got used. And we don't want to get rid of them because they're special to us, but at the same time, they're just kind of sitting there gathering dust. So, being able to put those out to your peers and know that they're, like, going to go onto an advertising job or a TV commercial, or, I don't know, a short film, or a feature film, or on talent is kind of exciting because they're almost getting repurposed for what they were originally purposed for. +And also, being able to make money from your dormant archive that's kind of a cool thing; it's a first. And knowing that it's not in the customer consumer realm, so you don't really have to worry too much about your amazing couture dress that you had for this artist and it was never worn going to a wedding and getting trashed. +WILL: I think I understand kind of what the flow is. So, for example, if tomorrow I want to become a stylist, before The Fashion Library, would I have to own all my pieces to even get into the space? +CHARLOTTE: It really depends what kind of realm you're working in. Obviously, if you're working on editorial and with celebrities, you tend to get pieces from brands because they give you pieces or loan you pieces for publicity, so it's kind of a two-way deal. However, when you're working on film, TV, commercials, advertising, you get given production budgets, like, wardrobe budgets. +So, the current way that we work is we go out and shop, and we shop a lot. And we also fuel the fast fashion monster because a lot of the time, we have minimal budgets. We have this store in the UK, and it's called Primark. It's very, very, like, cheap and not good for the environment, and there's also ASOS as well. There's all this kind of online fast fashion places. And it's, like, you get the budget, and they want Prada, or they want designer and luxury. However, you've only got the budget to afford Primark or ASOS. +And, actually, what a lot of people don't realize is that stylists spend a lot. Say they get given a £2,000 or $2,000 budget; they will spend £6,000 or $6,000, and what isn't used, they then return. But because they're buying into the fast fashion brands, a lot of the time, once they do those returns, especially the online stores, it goes back, and it's actually landfilled or incinerated because the price point for them to repackage it is so minimal that it's actually cheaper for them to just get rid of it. So, we are actually really adding to the problem of fashion being a massive pollutant globally. +WILL: I didn't even catch that part, but yeah, that sounds amazing that not only, you know, if you said, "I had a budget for this movie or whatever. Can I get more pieces?" Because I'm looking at your website right now, and it looks cheaper to rent them than if I was buying them outright. So, I have more choices, but also, I'm saving the world. That sounds, yeah, that's a win, win, win. +CHARLOTTE: Yeah, that's so right. One of our slogans is, 'Saves time, money, and the planet.' +VICTORIA: It sounds like a core value that drives your everyday decisions. Are there any other values that help guide you as a founder as you're building your business? +CHARLOTTE: Just the positive feedback from everyone in the industry, whether that's from the producers, production companies, stylists, just everyone getting it because it is such a simple idea. So, it's just having that recognition and just knowing that what you've envisaged and you're creating is valued. That's a huge driving factor for me. +VICTORIA: And what does success Look like in six months or in five years from now? +CHARLOTTE: I think in six months, it will be to have a business that is growing and really living up to its foundations of helping stylists, making their lives easier, saving time, money, and the planet, growing the archive to double what it is currently. So, it's currently around 2,000 pieces. It'd be great to have 4,000-plus in the next six months. Continue to grow our user base, and just expand on that, and grow the connections that we're already creating within the industry with our affiliations with the green sustainability companies. +There's some exciting things happening. I don't want to talk about them just because until they're, like, done, I'm always a bit like, oh, I don't know if I should put that out there yet. But yeah, generally, just, like, expanding and building the business and also completing the first raise and starting to build and develop the tech. That's something I'm really ready and excited to do. It's scary, but it's also super exciting. +WILL: Yeah. I can't wait to see what comes out of it because it seems like you can go so many directions with this. Because, like you were saying, like, brick and mortar versus tech and, like, that means you can reach anywhere that you can ship products to, instead of having to come to one location. Even nowadays, like, Amazon does a little bit of it, but like, when you're trying to buy furniture or something, you can put it in the room and see how it sits there and stuff. +So, it's so many things because I know, like, fashion, the one thing I do know about fashion is how it looks on the person, so, like, you know, seeing how it looks on that person through technology. I'm so excited because I can see so many directions you can go with it. +CHARLOTTE: Will, you are right on the money there. I'm not going to say too much more, but yeah, you're definitely getting my vision a little bit. There's so much scope for it, too. And also, I mean, what you've kind of touched on is what I've envisaged. But, again, it's also, like, just keeping focused and keeping on that path for now because there's also so many different avenues further down that you can go into, too. Like, the potential and possibility with this is endless. +VICTORIA: What advice do you have for other founders out there who are building products in the fashion industry? +CHARLOTTE: That it's okay to make mistakes. You've actually just got to start. That's one of the things. You know, I worked on this for almost a year and a half before I brought it live. And I think I wanted to be as ready as possible. And knowing that it's okay to not have all the answers and, also, being able to learn really quickly and ask for help from people that you trust, and that age-old saying of trust your gut. If something with someone doesn't feel right, it's probably not, so just trusting that. +And also, just being able to pivot. You can't be so focused and rigid with what you're trying to create because it's going to, I mean, mine's changed so much from what I initially envisaged to where I'm at now, and it's going to keep changing. And that's okay because it needs to be adaptable in order to succeed and survive, I think. +And also, you're going to get a lot of people who are going to promise so much. At the end of the day, no one's going to work on it as hard as you are, and that's okay. But don't trust everyone who says they're going to do X, Y, Z for you because, usually, they're not. And they're always the ones that fall at the first hurdle. +WILL: One thing I love about doing this podcast is listening to entrepreneurs and their mindset and how they got to the place to even, like you said, start something. I feel like that's one of the biggest hurdles is just starting something. I want to understand more about your mindset. What is your wind in your sails? What motivates you? +CHARLOTTE: I got this idea. I've always had ideas but just generally just spoken about them and never really took them to fruition, whereas with this one, I was adamant I was going to do it. I actually ended up having my heart and soul ripped out of me and was, like, rock bottom, and this was already after I'd had this idea about this. And it was that need to, like, just heal and grow that I really just threw my all into it and was like, you know what? I'm going to try this. Like, I just suddenly found my path, and I just got so focused and determined on building this, so I haven't looked back yet. +Trusting your idea, knowing that it's okay to, like, make mistakes from time to time. But just being a little bit naïve, I've definitely learned a lot. But yeah, just having that determination and discipline to just keep going. Even when people who've promised you the world, like, ghost you or disappear on you, if it's your baby and it's your vision and you believe in it, you can make it happen. +VICTORIA: Thank you. That's really wonderful advice, and I think will really resonate with our listeners. Do you have anything else that you'd like to promote today? +CHARLOTTE: Yeah, so anyone involved in film, TV, and advertising production, or any stylists and costume designers, follow us on Instagram. Join our mailing list via our website, even if you're not London and UK-based, because we've got some really big, big things coming over the next 12 months. So, I know we're only London and the UK at the moment, but the vision is global. So, join us on our mission. +VICTORIA: That's so exciting. Thank you so much for coming on to the show and sharing your story with us. +CHARLOTTE: Thank you for having me. +VICTORIA: You're welcome. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + Fashion industry, Wardrobe rental, Stylist, Sustainability, Entrepreneurship, Innovation, Environmental impact, Technology, Business journey, London, Podcast interview, Fashion library, Entrepreneurial mindset, Sustainable fashion, Rental platform + + Hosts Will and Victoria sit down with Charlotte Holt, the Founder and Creator of The Fashion Library. Based in London, The Fashion Library is a contemporary wardrobe rental resource tailored for stylists. Charlotte opens up about her diverse background, spanning various countries, and shares the transformative journey that led her from being a stylist to establishing her own venture.

+ +

Charlotte sheds light on the formidable challenges stylists encounter, from the environmental repercussions of fashion production to the financial constraints of traditional shopping methods. She articulates how The Fashion Library is poised to confront these obstacles head-on by offering a platform that enables stylists to rent clothing, fostering sustainability while saving valuable resources like time and money.

+ +

Delving into the realm of technology, Charlotte underscores its pivotal role in streamlining operations and catalyzing a paradigm shift towards a more sustainable fashion industry. She outlines her ambitious vision for The Fashion Library's future, encompassing the archive, broadening the user base, and creating a robust marketplace and working platform.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Charlotte Holt, Founder and Creator of The Fashion Library, London's newest contemporary wardrobe rental resource for stylists. Charlotte, thank you for joining me.

+ +

CHARLOTTE: Thank you for having me. I never ever thought I would be talking on a podcast.

+ +

VICTORIA: You never thought that? Why? What did you think would happen? [laughs]

+ +

CHARLOTTE: As in, like, I never thought I would be on a podcast, me personally. So, like, this is a new experience for me.

+ +

VICTORIA: Wonderful. Well, I know you're speaking with us today, and just to warm us up a little bit, I'm curious: what other languages could you be speaking to us in? What's your...I heard you learn multiple.

+ +

CHARLOTTE: So, I actually went to school in the south of France when I was younger. And for the last couple of years, I've been living in Mexico, so I've been trying to learn Spanish. I am pretty proficient in French and getting there in Spanish.

+ +

VICTORIA: Very cool. I live in San Diego, and I've also been learning Spanish for a long time and love to practice sometimes, so... What about you, Will? Do you speak any other languages?

+ +

WILL: I used to speak Spanish, but it's so hard when you don't live in that culture to keep it up. Because I've been to, like, Peru a couple of times and some other South American places, but I always pick it up when I go back in there and kind of get the feel for it, but it's kind of hard. I need to pick it back up. But Spanish is the one that I feel the most comfortable in outside of English.

+ +

VICTORIA: Right. We're a bilingual nation. And so, I love that opportunity to get to meet other people and speak in other languages and practice that. So, Charlotte, coming back to your journey, it sounds like you've lived in all these interesting places. Why don't you tell us just a little bit more about your background?

+ +

CHARLOTTE: I am from Scotland originally. I know I don't sound like it. And then I went to school in the South of France for two years, like, to finish high school. Then I ended up back in the UK, living in London for 12, 14 years. And then, just as COVID was happening, I was actually supposed to kind of relocate or start working more in the U.S., and I actually ended up in Mexico [chuckles], of all places, and that's where I stayed for two years. I was living the good life.

+ +

I had a pretty good COVID experience. I was at the beach every day surfing, so I can't complain about that. And then I've been living in the U.S. on the West Coast in Los Angeles before I decided to set up my new business, which has brought me back to London.

+ +

VICTORIA: Wow, full circle. Well, what beach were you surfing on in Mexico, or did you go to a bunch of different ones?

+ +

CHARLOTTE: I've been to a bunch, but I was living in Sayulita. I've still got a place there that I keep because I love to be in the ocean. It's one of my favorite things to do. Surfing is definitely a good lifestyle choice of mine.

+ +

VICTORIA: There's not much surfing in London now, so your desire to start your new company must be really powerful [chuckles], very strong.

+ +

CHARLOTTE: Yeah, I actually have questioned myself, especially over the last few months when it's been full, mid-winter here: cold, dark, raining. Like, what am I doing? Why did I give up my kind of dream life working between LA and Mexico, being able to surf, you know, at least two, three, four times a month to come back here to do this? But the bigger picture is, hopefully, I will be able to go and surf wherever I like after I've built this business. So, that's kind of the end goal for me.

+ +

VICTORIA: Yeah. Tell me more about what led you to start your own business.

+ +

CHARLOTTE: I have been working as a stylist for the last 12-plus years. And then, obviously, my work took me to the U.S. A friend of mine gave me his little black book contacts of where I should go and places I should use in LA. And I walked into a rental house there that was for industry only and got a lightbulb moment. I was like, oh my God, why is this not happening back in London? And it kind of didn't make sense to me because the productions back in the UK are, well, they seem more sustainable. Everyone's hitting their kind of green quotas and targets.

+ +

So, it just made sense to me, but not just from, like, the sustainability point of renting clothes, but also having an industry-only place that you can go to and basically prep most of your job in one go. So, it was, like, saving time on the start of the job but also on the end, which is the return side, which people don't always realize.

+ +

Everyone's like, "Oh, it's so glamorous working in fashion and styling." But we are bag ladies. I will often have minimum six, eight cases with me, rails and rails, racks and racks of clothes. I'm always the first one there. I'm the last one there because we're packing away. It's lots of steaming, just lots of stuff. So, to me, it just made perfect sense to recreate the same thing in London. But then I started getting into it a little bit more and started looking at tech and how that can transform what we're doing, too.

+ +

WILL: Before we get too deep into The Fashion Library, I want to, one, explain what a stylist does because, like I said, I am not fashion-forward or friendly. So, tell me kind of what that looks like to do. And also, how did you become a stylist? Was it a dream of yours always, or what did that look like?

+ +

CHARLOTTE: I just love clothes. So, I actually was going to be a lawyer, and I went to school to study law [chuckles], and I ended up being a stylist. So, there's different kind of realms and levels of a stylist. You can be a personal stylist where you work in the consumer realm, helping people dress themselves. Then, you have your editorial stylists who create beautiful imagery for magazines. Then there's the commercial stylists who work on advertising, film, TV production. Then you've got your celebrity stylists. There's different kind of layers within being a stylist.

+ +

I actually work across a broad range of that. I do editorials, so magazines. I've worked with some talent, music videos, TV commercials, short films, stills, and advertising campaigns. And what I really love is how different every job is. It's never the same. You're never with the same crew of people. Every job is different. Sometimes, you might be on set for just one day. Sometimes, you're on set for a week. There's weeks and weeks of prep that goes into the job. There's also a lot of work on the backend doing returns, and budgeting, and reconciling everything. You literally have to love clothes.

+ +

WILL: Where did your love for clothes come from?

+ +

CHARLOTTE: [chuckles] That's a good question. I always thought it was my mum, but, actually, it was definitely my dad. I look at pictures of him from the '70s, '80s. He's got some wild outfits on. And I've got some of his pieces. I've got this floral jacket that we all used to get dressed up in when we were younger because it's the most outrageous piece. I have it now. It's actually amazing. I actually had it on the other week with just a little black vest and some jeans. And because it's such a statement piece, it looks super cool, but it's classic '60s. So yeah, definitely from my dad. He had a wild penchant for clothes.

+ +

VICTORIA: I loved how you brought up, in the beginning, that the role of a stylist is often portrayed as being very glamorous and being very just so fun and creative and how the reality of it is that it's more carrying bags around, and picking up at the end of the day, and getting the clothes ready, and how tedious that can be. And you discovered technology could take some of that tedious out of the process and allow stylists to focus their time on the creative aspects.

+ +

CHARLOTTE: Yeah. So, originally, my plan with The Fashion Library was just to kind of replicate what was happening in the U.S. with the rental house models and just bring it here. And I have a friend who I met surfing in Mexico. He's in his 50s, very successful tech entrepreneur. And I wanted to run my business past him just to kind of get some outsider knowledge but someone who's been there and done it.

+ +

And he actually said to me, he was like, "This is great, but you should really, like, start to look at tech and how that is going to really transform businesses in the future." And he flicked that switch on, and that was it. Then, I think a couple of weeks later, I started sending him all my brain dumps about tech and what I was thinking in my mind. And he actually turned around and said to me, "If you can see it in your mind, you can build it."

+ +

So, I started to look at my pain points as a stylist. And I work differently in every city because you have to adapt. Like, in LA, I'm often out and about compared to London, where I work a lot online. So, I started to look at, like, the pain points of everywhere and what would really be beneficial. It always kind of dialed back to that question of, what would help me as a stylist? So, that's how I've built the business, by looking at that aspect and what's helpful, what's not.

+ +

WILL: Yeah, I like that view because I totally agree. Tech is in pretty much everything. It's all about, how can you see it to help you with your pain points? So, that's amazing that you sat back; you saw the pain points, and it helped you create what you're doing. So, that's really, really amazing. Can you tell me more about The Fashion Library? What does that look like? What did you create? What was your pain points?

+ +

CHARLOTTE: We launched in mid-July last year with a physical showroom of around 500 pieces, which was just my archive. And then I'd built out a very rough and ready Shopify to kind of replicate what was going on in the physical realm but in the virtual realm. I hadn't shot all those pieces, so it was maybe only 200 pieces online. And then, within two weeks, I'd managed to grow the archive to well over a thousand pieces, and then I was like, ugh, I need to get all this shot now.

+ +

And it's me doing all of this. I'm working with a friend who's a photographer. And I style all the pieces on a ghost mannequin. I've already thought about some techie idea in my head about how to get around that in the future. I don't know if it's possible, but I can see it in my mind. We can build it. So, I just wanted them both to kind of work in the physical and virtual realm, but then, obviously, always going back to John's advice from Mexico that, you know, really start to look more into the tech.

+ +

And the tech's definitely taken over. We haven't built any yet. We are currently about to start raising because we want to build a fully functional marketplace that's industry-only. There's going to be a phase three, which will be a whole working platform that will streamline the working process from start to finish with lots of clever little things thrown in.

+ +

And I don't want to give too much away on this because it is just in my mind right now. Obviously, it's on paper, too, but I've just been looking at what else is going on in the fashion realm, in the fashion tech realm, and there's lots of exciting things. There was a stylist who reached out to me just before Christmas. She's actually an avatar stylist. So, I was really interested to speak to her. They're currently creating avatars from humans. So, soon, everyone's going to be able to have their own avatar if they want.

+ +

But there's some really, really interesting and innovative stuff happening within the tech space, and there's definitely exciting things. And I can see a lot of scope in the future for The Fashion Library in terms of how we build the tech and adapt and how we kind of disrupt the industry, not just here in the UK, but globally.

+ +

VICTORIA: Thank you for sharing all of that. I think that's so interesting. And I also really love that you made the connection from surfing that got you excited about tech and excited about all these possibilities that you're describing. I'm just imagining, like, a little side conversation while you're paddling around out in the ocean [laughs]. But I don't know if that's how it really happened.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: What's your method for engaging with the industry on this issue and building your customer discovery process?

+ +

CHARLOTTE: Obviously, it's something I'm really passionate about. I knew that there would be others out there, too. We've been hunting for the stylists currently, so LinkedIn, this platform called The Dots here, Instagram, obviously, and then also connecting, like, higher up the food chain with production companies, ad agencies, really kind of targeting it from the top bottom down.

+ +

And then, the last couple of months, we've been focused on finding some founding members who are busy working commercial stylists who love the idea of sustainability and rental and want to be early adopters and users of The Fashion Library. We've had great feedback from them. So, having that feedback from people and it being positive is like a driving force behind what we're trying to create and creating.

+ +

VICTORIA: Has there been anything surprising in your conversations that has caused you to maybe pivot in your strategy?

+ +

CHARLOTTE: I mean, definitely, when I first took the idea to my surfing friend in Mexico, he really made me pivot from bricks and mortar into tech. I was always going to build out a tech platform, but it was literally just going to be online rental, just because of how I like to work in the UK. I think talking to him that really opened my eyes.

+ +

And then, also, kind of going off and launching really then understanding what he'd said to me. Because I think after I launched, I realized that actually the bricks and mortar is nice, and it's really nice to have that space and the showroom as a showcase, but it's not where I want to be. I'm really excited and really focused to get the tech going. It's really exciting. And if we can create what I'm envisaging, I think it's going to be so useful.

+ +

VICTORIA: Yeah. And I love that you're really focused on a specific group and creating something for the industry that you're in. Can you share any other specific problems or challenges that a stylist may have with a wardrobe rental app versus a person like me who's just trying to, like, rent a dress for the weekend or something?

+ +

CHARLOTTE: Yeah. Well, that's the thing. I mean, rental is trending as a whole globally. So, there are a lot of consumer-facing rental apps and businesses out there. But the thing about stylists is it's quite a lonely career. Yes, you have your assistants, but until you're on set or with your clients, you're pretty much on your own. And I think after COVID, there was that real push for community.

+ +

And also, as stylists, we tend to sit on big archives that we've collected from jobs, or we've had custom pieces made that actually never went to set or got used. And we don't want to get rid of them because they're special to us, but at the same time, they're just kind of sitting there gathering dust. So, being able to put those out to your peers and know that they're, like, going to go onto an advertising job or a TV commercial, or, I don't know, a short film, or a feature film, or on talent is kind of exciting because they're almost getting repurposed for what they were originally purposed for.

+ +

And also, being able to make money from your dormant archive that's kind of a cool thing; it's a first. And knowing that it's not in the customer consumer realm, so you don't really have to worry too much about your amazing couture dress that you had for this artist and it was never worn going to a wedding and getting trashed.

+ +

WILL: I think I understand kind of what the flow is. So, for example, if tomorrow I want to become a stylist, before The Fashion Library, would I have to own all my pieces to even get into the space?

+ +

CHARLOTTE: It really depends what kind of realm you're working in. Obviously, if you're working on editorial and with celebrities, you tend to get pieces from brands because they give you pieces or loan you pieces for publicity, so it's kind of a two-way deal. However, when you're working on film, TV, commercials, advertising, you get given production budgets, like, wardrobe budgets.

+ +

So, the current way that we work is we go out and shop, and we shop a lot. And we also fuel the fast fashion monster because a lot of the time, we have minimal budgets. We have this store in the UK, and it's called Primark. It's very, very, like, cheap and not good for the environment, and there's also ASOS as well. There's all this kind of online fast fashion places. And it's, like, you get the budget, and they want Prada, or they want designer and luxury. However, you've only got the budget to afford Primark or ASOS.

+ +

And, actually, what a lot of people don't realize is that stylists spend a lot. Say they get given a £2,000 or $2,000 budget; they will spend £6,000 or $6,000, and what isn't used, they then return. But because they're buying into the fast fashion brands, a lot of the time, once they do those returns, especially the online stores, it goes back, and it's actually landfilled or incinerated because the price point for them to repackage it is so minimal that it's actually cheaper for them to just get rid of it. So, we are actually really adding to the problem of fashion being a massive pollutant globally.

+ +

WILL: I didn't even catch that part, but yeah, that sounds amazing that not only, you know, if you said, "I had a budget for this movie or whatever. Can I get more pieces?" Because I'm looking at your website right now, and it looks cheaper to rent them than if I was buying them outright. So, I have more choices, but also, I'm saving the world. That sounds, yeah, that's a win, win, win.

+ +

CHARLOTTE: Yeah, that's so right. One of our slogans is, 'Saves time, money, and the planet.'

+ +

VICTORIA: It sounds like a core value that drives your everyday decisions. Are there any other values that help guide you as a founder as you're building your business?

+ +

CHARLOTTE: Just the positive feedback from everyone in the industry, whether that's from the producers, production companies, stylists, just everyone getting it because it is such a simple idea. So, it's just having that recognition and just knowing that what you've envisaged and you're creating is valued. That's a huge driving factor for me.

+ +

VICTORIA: And what does success Look like in six months or in five years from now?

+ +

CHARLOTTE: I think in six months, it will be to have a business that is growing and really living up to its foundations of helping stylists, making their lives easier, saving time, money, and the planet, growing the archive to double what it is currently. So, it's currently around 2,000 pieces. It'd be great to have 4,000-plus in the next six months. Continue to grow our user base, and just expand on that, and grow the connections that we're already creating within the industry with our affiliations with the green sustainability companies.

+ +

There's some exciting things happening. I don't want to talk about them just because until they're, like, done, I'm always a bit like, oh, I don't know if I should put that out there yet. But yeah, generally, just, like, expanding and building the business and also completing the first raise and starting to build and develop the tech. That's something I'm really ready and excited to do. It's scary, but it's also super exciting.

+ +

WILL: Yeah. I can't wait to see what comes out of it because it seems like you can go so many directions with this. Because, like you were saying, like, brick and mortar versus tech and, like, that means you can reach anywhere that you can ship products to, instead of having to come to one location. Even nowadays, like, Amazon does a little bit of it, but like, when you're trying to buy furniture or something, you can put it in the room and see how it sits there and stuff.

+ +

So, it's so many things because I know, like, fashion, the one thing I do know about fashion is how it looks on the person, so, like, you know, seeing how it looks on that person through technology. I'm so excited because I can see so many directions you can go with it.

+ +

CHARLOTTE: Will, you are right on the money there. I'm not going to say too much more, but yeah, you're definitely getting my vision a little bit. There's so much scope for it, too. And also, I mean, what you've kind of touched on is what I've envisaged. But, again, it's also, like, just keeping focused and keeping on that path for now because there's also so many different avenues further down that you can go into, too. Like, the potential and possibility with this is endless.

+ +

VICTORIA: What advice do you have for other founders out there who are building products in the fashion industry?

+ +

CHARLOTTE: That it's okay to make mistakes. You've actually just got to start. That's one of the things. You know, I worked on this for almost a year and a half before I brought it live. And I think I wanted to be as ready as possible. And knowing that it's okay to not have all the answers and, also, being able to learn really quickly and ask for help from people that you trust, and that age-old saying of trust your gut. If something with someone doesn't feel right, it's probably not, so just trusting that.

+ +

And also, just being able to pivot. You can't be so focused and rigid with what you're trying to create because it's going to, I mean, mine's changed so much from what I initially envisaged to where I'm at now, and it's going to keep changing. And that's okay because it needs to be adaptable in order to succeed and survive, I think.

+ +

And also, you're going to get a lot of people who are going to promise so much. At the end of the day, no one's going to work on it as hard as you are, and that's okay. But don't trust everyone who says they're going to do X, Y, Z for you because, usually, they're not. And they're always the ones that fall at the first hurdle.

+ +

WILL: One thing I love about doing this podcast is listening to entrepreneurs and their mindset and how they got to the place to even, like you said, start something. I feel like that's one of the biggest hurdles is just starting something. I want to understand more about your mindset. What is your wind in your sails? What motivates you?

+ +

CHARLOTTE: I got this idea. I've always had ideas but just generally just spoken about them and never really took them to fruition, whereas with this one, I was adamant I was going to do it. I actually ended up having my heart and soul ripped out of me and was, like, rock bottom, and this was already after I'd had this idea about this. And it was that need to, like, just heal and grow that I really just threw my all into it and was like, you know what? I'm going to try this. Like, I just suddenly found my path, and I just got so focused and determined on building this, so I haven't looked back yet.

+ +

Trusting your idea, knowing that it's okay to, like, make mistakes from time to time. But just being a little bit naïve, I've definitely learned a lot. But yeah, just having that determination and discipline to just keep going. Even when people who've promised you the world, like, ghost you or disappear on you, if it's your baby and it's your vision and you believe in it, you can make it happen.

+ +

VICTORIA: Thank you. That's really wonderful advice, and I think will really resonate with our listeners. Do you have anything else that you'd like to promote today?

+ +

CHARLOTTE: Yeah, so anyone involved in film, TV, and advertising production, or any stylists and costume designers, follow us on Instagram. Join our mailing list via our website, even if you're not London and UK-based, because we've got some really big, big things coming over the next 12 months. So, I know we're only London and the UK at the moment, but the vision is global. So, join us on our mission.

+ +

VICTORIA: That's so exciting. Thank you so much for coming on to the show and sharing your story with us.

+ +

CHARLOTTE: Thank you for having me.

+ +

VICTORIA: You're welcome.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will and Victoria sit down with Charlotte Holt, the Founder and Creator of The Fashion Library. Based in London, The Fashion Library is a contemporary wardrobe rental resource tailored for stylists. Charlotte opens up about her diverse background, spanning various countries, and shares the transformative journey that led her from being a stylist to establishing her own venture.

+ +

Charlotte sheds light on the formidable challenges stylists encounter, from the environmental repercussions of fashion production to the financial constraints of traditional shopping methods. She articulates how The Fashion Library is poised to confront these obstacles head-on by offering a platform that enables stylists to rent clothing, fostering sustainability while saving valuable resources like time and money.

+ +

Delving into the realm of technology, Charlotte underscores its pivotal role in streamlining operations and catalyzing a paradigm shift towards a more sustainable fashion industry. She outlines her ambitious vision for The Fashion Library's future, encompassing the archive, broadening the user base, and creating a robust marketplace and working platform.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Charlotte Holt, Founder and Creator of The Fashion Library, London's newest contemporary wardrobe rental resource for stylists. Charlotte, thank you for joining me.

+ +

CHARLOTTE: Thank you for having me. I never ever thought I would be talking on a podcast.

+ +

VICTORIA: You never thought that? Why? What did you think would happen? [laughs]

+ +

CHARLOTTE: As in, like, I never thought I would be on a podcast, me personally. So, like, this is a new experience for me.

+ +

VICTORIA: Wonderful. Well, I know you're speaking with us today, and just to warm us up a little bit, I'm curious: what other languages could you be speaking to us in? What's your...I heard you learn multiple.

+ +

CHARLOTTE: So, I actually went to school in the south of France when I was younger. And for the last couple of years, I've been living in Mexico, so I've been trying to learn Spanish. I am pretty proficient in French and getting there in Spanish.

+ +

VICTORIA: Very cool. I live in San Diego, and I've also been learning Spanish for a long time and love to practice sometimes, so... What about you, Will? Do you speak any other languages?

+ +

WILL: I used to speak Spanish, but it's so hard when you don't live in that culture to keep it up. Because I've been to, like, Peru a couple of times and some other South American places, but I always pick it up when I go back in there and kind of get the feel for it, but it's kind of hard. I need to pick it back up. But Spanish is the one that I feel the most comfortable in outside of English.

+ +

VICTORIA: Right. We're a bilingual nation. And so, I love that opportunity to get to meet other people and speak in other languages and practice that. So, Charlotte, coming back to your journey, it sounds like you've lived in all these interesting places. Why don't you tell us just a little bit more about your background?

+ +

CHARLOTTE: I am from Scotland originally. I know I don't sound like it. And then I went to school in the South of France for two years, like, to finish high school. Then I ended up back in the UK, living in London for 12, 14 years. And then, just as COVID was happening, I was actually supposed to kind of relocate or start working more in the U.S., and I actually ended up in Mexico [chuckles], of all places, and that's where I stayed for two years. I was living the good life.

+ +

I had a pretty good COVID experience. I was at the beach every day surfing, so I can't complain about that. And then I've been living in the U.S. on the West Coast in Los Angeles before I decided to set up my new business, which has brought me back to London.

+ +

VICTORIA: Wow, full circle. Well, what beach were you surfing on in Mexico, or did you go to a bunch of different ones?

+ +

CHARLOTTE: I've been to a bunch, but I was living in Sayulita. I've still got a place there that I keep because I love to be in the ocean. It's one of my favorite things to do. Surfing is definitely a good lifestyle choice of mine.

+ +

VICTORIA: There's not much surfing in London now, so your desire to start your new company must be really powerful [chuckles], very strong.

+ +

CHARLOTTE: Yeah, I actually have questioned myself, especially over the last few months when it's been full, mid-winter here: cold, dark, raining. Like, what am I doing? Why did I give up my kind of dream life working between LA and Mexico, being able to surf, you know, at least two, three, four times a month to come back here to do this? But the bigger picture is, hopefully, I will be able to go and surf wherever I like after I've built this business. So, that's kind of the end goal for me.

+ +

VICTORIA: Yeah. Tell me more about what led you to start your own business.

+ +

CHARLOTTE: I have been working as a stylist for the last 12-plus years. And then, obviously, my work took me to the U.S. A friend of mine gave me his little black book contacts of where I should go and places I should use in LA. And I walked into a rental house there that was for industry only and got a lightbulb moment. I was like, oh my God, why is this not happening back in London? And it kind of didn't make sense to me because the productions back in the UK are, well, they seem more sustainable. Everyone's hitting their kind of green quotas and targets.

+ +

So, it just made sense to me, but not just from, like, the sustainability point of renting clothes, but also having an industry-only place that you can go to and basically prep most of your job in one go. So, it was, like, saving time on the start of the job but also on the end, which is the return side, which people don't always realize.

+ +

Everyone's like, "Oh, it's so glamorous working in fashion and styling." But we are bag ladies. I will often have minimum six, eight cases with me, rails and rails, racks and racks of clothes. I'm always the first one there. I'm the last one there because we're packing away. It's lots of steaming, just lots of stuff. So, to me, it just made perfect sense to recreate the same thing in London. But then I started getting into it a little bit more and started looking at tech and how that can transform what we're doing, too.

+ +

WILL: Before we get too deep into The Fashion Library, I want to, one, explain what a stylist does because, like I said, I am not fashion-forward or friendly. So, tell me kind of what that looks like to do. And also, how did you become a stylist? Was it a dream of yours always, or what did that look like?

+ +

CHARLOTTE: I just love clothes. So, I actually was going to be a lawyer, and I went to school to study law [chuckles], and I ended up being a stylist. So, there's different kind of realms and levels of a stylist. You can be a personal stylist where you work in the consumer realm, helping people dress themselves. Then, you have your editorial stylists who create beautiful imagery for magazines. Then there's the commercial stylists who work on advertising, film, TV production. Then you've got your celebrity stylists. There's different kind of layers within being a stylist.

+ +

I actually work across a broad range of that. I do editorials, so magazines. I've worked with some talent, music videos, TV commercials, short films, stills, and advertising campaigns. And what I really love is how different every job is. It's never the same. You're never with the same crew of people. Every job is different. Sometimes, you might be on set for just one day. Sometimes, you're on set for a week. There's weeks and weeks of prep that goes into the job. There's also a lot of work on the backend doing returns, and budgeting, and reconciling everything. You literally have to love clothes.

+ +

WILL: Where did your love for clothes come from?

+ +

CHARLOTTE: [chuckles] That's a good question. I always thought it was my mum, but, actually, it was definitely my dad. I look at pictures of him from the '70s, '80s. He's got some wild outfits on. And I've got some of his pieces. I've got this floral jacket that we all used to get dressed up in when we were younger because it's the most outrageous piece. I have it now. It's actually amazing. I actually had it on the other week with just a little black vest and some jeans. And because it's such a statement piece, it looks super cool, but it's classic '60s. So yeah, definitely from my dad. He had a wild penchant for clothes.

+ +

VICTORIA: I loved how you brought up, in the beginning, that the role of a stylist is often portrayed as being very glamorous and being very just so fun and creative and how the reality of it is that it's more carrying bags around, and picking up at the end of the day, and getting the clothes ready, and how tedious that can be. And you discovered technology could take some of that tedious out of the process and allow stylists to focus their time on the creative aspects.

+ +

CHARLOTTE: Yeah. So, originally, my plan with The Fashion Library was just to kind of replicate what was happening in the U.S. with the rental house models and just bring it here. And I have a friend who I met surfing in Mexico. He's in his 50s, very successful tech entrepreneur. And I wanted to run my business past him just to kind of get some outsider knowledge but someone who's been there and done it.

+ +

And he actually said to me, he was like, "This is great, but you should really, like, start to look at tech and how that is going to really transform businesses in the future." And he flicked that switch on, and that was it. Then, I think a couple of weeks later, I started sending him all my brain dumps about tech and what I was thinking in my mind. And he actually turned around and said to me, "If you can see it in your mind, you can build it."

+ +

So, I started to look at my pain points as a stylist. And I work differently in every city because you have to adapt. Like, in LA, I'm often out and about compared to London, where I work a lot online. So, I started to look at, like, the pain points of everywhere and what would really be beneficial. It always kind of dialed back to that question of, what would help me as a stylist? So, that's how I've built the business, by looking at that aspect and what's helpful, what's not.

+ +

WILL: Yeah, I like that view because I totally agree. Tech is in pretty much everything. It's all about, how can you see it to help you with your pain points? So, that's amazing that you sat back; you saw the pain points, and it helped you create what you're doing. So, that's really, really amazing. Can you tell me more about The Fashion Library? What does that look like? What did you create? What was your pain points?

+ +

CHARLOTTE: We launched in mid-July last year with a physical showroom of around 500 pieces, which was just my archive. And then I'd built out a very rough and ready Shopify to kind of replicate what was going on in the physical realm but in the virtual realm. I hadn't shot all those pieces, so it was maybe only 200 pieces online. And then, within two weeks, I'd managed to grow the archive to well over a thousand pieces, and then I was like, ugh, I need to get all this shot now.

+ +

And it's me doing all of this. I'm working with a friend who's a photographer. And I style all the pieces on a ghost mannequin. I've already thought about some techie idea in my head about how to get around that in the future. I don't know if it's possible, but I can see it in my mind. We can build it. So, I just wanted them both to kind of work in the physical and virtual realm, but then, obviously, always going back to John's advice from Mexico that, you know, really start to look more into the tech.

+ +

And the tech's definitely taken over. We haven't built any yet. We are currently about to start raising because we want to build a fully functional marketplace that's industry-only. There's going to be a phase three, which will be a whole working platform that will streamline the working process from start to finish with lots of clever little things thrown in.

+ +

And I don't want to give too much away on this because it is just in my mind right now. Obviously, it's on paper, too, but I've just been looking at what else is going on in the fashion realm, in the fashion tech realm, and there's lots of exciting things. There was a stylist who reached out to me just before Christmas. She's actually an avatar stylist. So, I was really interested to speak to her. They're currently creating avatars from humans. So, soon, everyone's going to be able to have their own avatar if they want.

+ +

But there's some really, really interesting and innovative stuff happening within the tech space, and there's definitely exciting things. And I can see a lot of scope in the future for The Fashion Library in terms of how we build the tech and adapt and how we kind of disrupt the industry, not just here in the UK, but globally.

+ +

VICTORIA: Thank you for sharing all of that. I think that's so interesting. And I also really love that you made the connection from surfing that got you excited about tech and excited about all these possibilities that you're describing. I'm just imagining, like, a little side conversation while you're paddling around out in the ocean [laughs]. But I don't know if that's how it really happened.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: What's your method for engaging with the industry on this issue and building your customer discovery process?

+ +

CHARLOTTE: Obviously, it's something I'm really passionate about. I knew that there would be others out there, too. We've been hunting for the stylists currently, so LinkedIn, this platform called The Dots here, Instagram, obviously, and then also connecting, like, higher up the food chain with production companies, ad agencies, really kind of targeting it from the top bottom down.

+ +

And then, the last couple of months, we've been focused on finding some founding members who are busy working commercial stylists who love the idea of sustainability and rental and want to be early adopters and users of The Fashion Library. We've had great feedback from them. So, having that feedback from people and it being positive is like a driving force behind what we're trying to create and creating.

+ +

VICTORIA: Has there been anything surprising in your conversations that has caused you to maybe pivot in your strategy?

+ +

CHARLOTTE: I mean, definitely, when I first took the idea to my surfing friend in Mexico, he really made me pivot from bricks and mortar into tech. I was always going to build out a tech platform, but it was literally just going to be online rental, just because of how I like to work in the UK. I think talking to him that really opened my eyes.

+ +

And then, also, kind of going off and launching really then understanding what he'd said to me. Because I think after I launched, I realized that actually the bricks and mortar is nice, and it's really nice to have that space and the showroom as a showcase, but it's not where I want to be. I'm really excited and really focused to get the tech going. It's really exciting. And if we can create what I'm envisaging, I think it's going to be so useful.

+ +

VICTORIA: Yeah. And I love that you're really focused on a specific group and creating something for the industry that you're in. Can you share any other specific problems or challenges that a stylist may have with a wardrobe rental app versus a person like me who's just trying to, like, rent a dress for the weekend or something?

+ +

CHARLOTTE: Yeah. Well, that's the thing. I mean, rental is trending as a whole globally. So, there are a lot of consumer-facing rental apps and businesses out there. But the thing about stylists is it's quite a lonely career. Yes, you have your assistants, but until you're on set or with your clients, you're pretty much on your own. And I think after COVID, there was that real push for community.

+ +

And also, as stylists, we tend to sit on big archives that we've collected from jobs, or we've had custom pieces made that actually never went to set or got used. And we don't want to get rid of them because they're special to us, but at the same time, they're just kind of sitting there gathering dust. So, being able to put those out to your peers and know that they're, like, going to go onto an advertising job or a TV commercial, or, I don't know, a short film, or a feature film, or on talent is kind of exciting because they're almost getting repurposed for what they were originally purposed for.

+ +

And also, being able to make money from your dormant archive that's kind of a cool thing; it's a first. And knowing that it's not in the customer consumer realm, so you don't really have to worry too much about your amazing couture dress that you had for this artist and it was never worn going to a wedding and getting trashed.

+ +

WILL: I think I understand kind of what the flow is. So, for example, if tomorrow I want to become a stylist, before The Fashion Library, would I have to own all my pieces to even get into the space?

+ +

CHARLOTTE: It really depends what kind of realm you're working in. Obviously, if you're working on editorial and with celebrities, you tend to get pieces from brands because they give you pieces or loan you pieces for publicity, so it's kind of a two-way deal. However, when you're working on film, TV, commercials, advertising, you get given production budgets, like, wardrobe budgets.

+ +

So, the current way that we work is we go out and shop, and we shop a lot. And we also fuel the fast fashion monster because a lot of the time, we have minimal budgets. We have this store in the UK, and it's called Primark. It's very, very, like, cheap and not good for the environment, and there's also ASOS as well. There's all this kind of online fast fashion places. And it's, like, you get the budget, and they want Prada, or they want designer and luxury. However, you've only got the budget to afford Primark or ASOS.

+ +

And, actually, what a lot of people don't realize is that stylists spend a lot. Say they get given a £2,000 or $2,000 budget; they will spend £6,000 or $6,000, and what isn't used, they then return. But because they're buying into the fast fashion brands, a lot of the time, once they do those returns, especially the online stores, it goes back, and it's actually landfilled or incinerated because the price point for them to repackage it is so minimal that it's actually cheaper for them to just get rid of it. So, we are actually really adding to the problem of fashion being a massive pollutant globally.

+ +

WILL: I didn't even catch that part, but yeah, that sounds amazing that not only, you know, if you said, "I had a budget for this movie or whatever. Can I get more pieces?" Because I'm looking at your website right now, and it looks cheaper to rent them than if I was buying them outright. So, I have more choices, but also, I'm saving the world. That sounds, yeah, that's a win, win, win.

+ +

CHARLOTTE: Yeah, that's so right. One of our slogans is, 'Saves time, money, and the planet.'

+ +

VICTORIA: It sounds like a core value that drives your everyday decisions. Are there any other values that help guide you as a founder as you're building your business?

+ +

CHARLOTTE: Just the positive feedback from everyone in the industry, whether that's from the producers, production companies, stylists, just everyone getting it because it is such a simple idea. So, it's just having that recognition and just knowing that what you've envisaged and you're creating is valued. That's a huge driving factor for me.

+ +

VICTORIA: And what does success Look like in six months or in five years from now?

+ +

CHARLOTTE: I think in six months, it will be to have a business that is growing and really living up to its foundations of helping stylists, making their lives easier, saving time, money, and the planet, growing the archive to double what it is currently. So, it's currently around 2,000 pieces. It'd be great to have 4,000-plus in the next six months. Continue to grow our user base, and just expand on that, and grow the connections that we're already creating within the industry with our affiliations with the green sustainability companies.

+ +

There's some exciting things happening. I don't want to talk about them just because until they're, like, done, I'm always a bit like, oh, I don't know if I should put that out there yet. But yeah, generally, just, like, expanding and building the business and also completing the first raise and starting to build and develop the tech. That's something I'm really ready and excited to do. It's scary, but it's also super exciting.

+ +

WILL: Yeah. I can't wait to see what comes out of it because it seems like you can go so many directions with this. Because, like you were saying, like, brick and mortar versus tech and, like, that means you can reach anywhere that you can ship products to, instead of having to come to one location. Even nowadays, like, Amazon does a little bit of it, but like, when you're trying to buy furniture or something, you can put it in the room and see how it sits there and stuff.

+ +

So, it's so many things because I know, like, fashion, the one thing I do know about fashion is how it looks on the person, so, like, you know, seeing how it looks on that person through technology. I'm so excited because I can see so many directions you can go with it.

+ +

CHARLOTTE: Will, you are right on the money there. I'm not going to say too much more, but yeah, you're definitely getting my vision a little bit. There's so much scope for it, too. And also, I mean, what you've kind of touched on is what I've envisaged. But, again, it's also, like, just keeping focused and keeping on that path for now because there's also so many different avenues further down that you can go into, too. Like, the potential and possibility with this is endless.

+ +

VICTORIA: What advice do you have for other founders out there who are building products in the fashion industry?

+ +

CHARLOTTE: That it's okay to make mistakes. You've actually just got to start. That's one of the things. You know, I worked on this for almost a year and a half before I brought it live. And I think I wanted to be as ready as possible. And knowing that it's okay to not have all the answers and, also, being able to learn really quickly and ask for help from people that you trust, and that age-old saying of trust your gut. If something with someone doesn't feel right, it's probably not, so just trusting that.

+ +

And also, just being able to pivot. You can't be so focused and rigid with what you're trying to create because it's going to, I mean, mine's changed so much from what I initially envisaged to where I'm at now, and it's going to keep changing. And that's okay because it needs to be adaptable in order to succeed and survive, I think.

+ +

And also, you're going to get a lot of people who are going to promise so much. At the end of the day, no one's going to work on it as hard as you are, and that's okay. But don't trust everyone who says they're going to do X, Y, Z for you because, usually, they're not. And they're always the ones that fall at the first hurdle.

+ +

WILL: One thing I love about doing this podcast is listening to entrepreneurs and their mindset and how they got to the place to even, like you said, start something. I feel like that's one of the biggest hurdles is just starting something. I want to understand more about your mindset. What is your wind in your sails? What motivates you?

+ +

CHARLOTTE: I got this idea. I've always had ideas but just generally just spoken about them and never really took them to fruition, whereas with this one, I was adamant I was going to do it. I actually ended up having my heart and soul ripped out of me and was, like, rock bottom, and this was already after I'd had this idea about this. And it was that need to, like, just heal and grow that I really just threw my all into it and was like, you know what? I'm going to try this. Like, I just suddenly found my path, and I just got so focused and determined on building this, so I haven't looked back yet.

+ +

Trusting your idea, knowing that it's okay to, like, make mistakes from time to time. But just being a little bit naïve, I've definitely learned a lot. But yeah, just having that determination and discipline to just keep going. Even when people who've promised you the world, like, ghost you or disappear on you, if it's your baby and it's your vision and you believe in it, you can make it happen.

+ +

VICTORIA: Thank you. That's really wonderful advice, and I think will really resonate with our listeners. Do you have anything else that you'd like to promote today?

+ +

CHARLOTTE: Yeah, so anyone involved in film, TV, and advertising production, or any stylists and costume designers, follow us on Instagram. Join our mailing list via our website, even if you're not London and UK-based, because we've got some really big, big things coming over the next 12 months. So, I know we're only London and the UK at the moment, but the vision is global. So, join us on our mission.

+ +

VICTORIA: That's so exciting. Thank you so much for coming on to the show and sharing your story with us.

+ +

CHARLOTTE: Thank you for having me.

+ +

VICTORIA: You're welcome.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+1ojEH6lU + + ]]> + + Will Larry + Victoria Guido + + + 515: Healing Minds, Changing Lives: The Meru Health Experience + https://podcast.thoughtbot.com/515 + 89ccb778-8d1d-4c5e-be64-60f1135900d8 + Thu, 07 Mar 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Kristian Ranta, the founder of Meru Health, shares insights into the company's transition from wellness to healthcare, emphasizing the role of intuition in entrepreneurship. He discusses challenges in regulatory compliance and insurance reimbursements while highlighting Meru Health's holistic mental health approach and plans for global expansion. + 36:42 + no + + + Kristian Ranta, the founder of Meru Health, shares the company's journey from its inception to its current status as a leading provider of mental health solutions. Kristian reflects on the decision to pivot Meru Health from a wellness-focused to a healthcare-centered company, emphasizing the importance of overcoming fears and listening to intuition in entrepreneurial pursuits. He discusses the challenges and rewards of building a healthcare startup, highlighting the complexities of navigating regulatory frameworks and securing insurance reimbursements. +Throughout the conversation, Kristian elaborates on Meru Health's unique approach to mental healthcare, which integrates therapy, coaching, and app-based interventions to offer users a holistic and personalized experience. He underscores the significance of community support in mental health treatment and explains how Meru Health's platform fosters connection among individuals facing similar challenges. Kristian also delves into the company's plans for expansion, both within the United States and globally, while addressing ongoing challenges such as securing insurance reimbursements and maintaining high standards for talent acquisition. +Meru Health (https://www.meruhealth.com/) +Follow Meru Health on LinkedIn (https://www.linkedin.com/company/meru-health/), X (https://twitter.com/meruhealth), Facebook (https://www.facebook.com/meruhealth/), or Instagram (https://www.instagram.com/meru_health/). +Follow Kristian Ranta on LinkedIn (https://www.linkedin.com/in/kristian-ranta/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Kristian Ranta, CEO and Founder for Meru Health, a new standard for mental health care. Kristian, thank you for joining me. +KRISTIAN: Thanks, Victoria. Great to be here today. Appreciate it. +VICTORIA: Wonderful. To break the ice a little bit to get us started in the conversation here, I don't know if you can hear it, but I have a slight cold and congestion going on. And since you're a healthcare startup, I thought I would ask you, what is your favorite comfort food when you're sick? +KRISTIAN: I don't know whether it's a comfort food or not, but I think kind of what I always consume if I get, like, some flu symptoms or stuff like that it's ginger, honey, and then garlic. I try to combine these things, and it's semi-tasty. Like, it depends on, like, how strong you make it, but it's definitely effective. So, it's been my go-to thing when I get sick. +VICTORIA: Me too. I like to try to put all those things into a soup of some kind [laughs], some chicken soup. I've learned how to make some sort of version of congee, which is, like, a rice porridge, which I love because you can kind of just sit it on the stove, and it cooks all day. And you could add in all those flavors, and it comes together really nicely. +For me, I think that's really nice to think about what you like to eat when you're sick because when you're sick, it affects everything else going on in your body. So, I'm sure you have some personal experiences about how your mental health and your physical health are all interrelated. +KRISTIAN: I mean, totally. Actually, like, I've been a biohacker for quite a while. So, I've been, like, just trying a bunch of things, like, on the physical health side and, like, exercise. And I'm from Finland originally, so a lot of cold exposure, sauna, swimming in the icy water, stuff like that. And then, of course, a lot of, like, different dietary tests that I've done over the years. And I think there's, yeah, I've recognized that there's a huge connection, and it's like the mind and the body are not, like, disconnected. They're in a way the same. +Personally, also, like, a big piece kind of for me in this regard has been my journey of meditation. So, I started maybe, like, 10, 12 years ago, started meditating every day, and then I've done a bunch of different retreats and kind of dug deeper. Especially through meditation, I've learned very [inaudible 02:15] to experience the connectedness of my thoughts, and my emotions, and feelings, and the body. So, anyway, that's, like, one of my favorite topics, so... +VICTORIA: So, it sounds like you've always had this interest in the mind-body connection and how to optimize your health. How did that lead you, or what about your background led you to found Meru Health? +KRISTIAN: I'm from Finland originally. So, I moved to the States in 2018 with Meru Health with my current company. But way back, I studied computer science, did my undergraduate and graduate studies in Finland. And then I kind of, like, ended up working at a healthcare company, a startup company, while I was still studying. And I worked there for a couple of years. And this company was a clinical trial software company, so making it easier for pharmaceutical companies to collect data in patient trials for, like, new drugs, and new developments, and stuff like that. +I was basically at that company for a couple of years, and that was my first dip into healthcare and technology, the intersection. And I got so excited, and I realized that, hey, this is a place where I can use my excitement for technology and my skills and all that stuff. But I can also then, like, see the immediate improvement in people's lives and how we can help others, and that kind of resonated with me. +So, I quit after two years and then founded my first own business, which was in diabetes, so one of my co-founders back then is a diabetic. And that's kind of, like, how I went into healthcare. And, for me, then learning the mind and body connection started at the same time. Pretty much I kind of, you know, again, mentioned that I've been meditating for a while. So, I started meditating, and I started just learning about these things and just, like, became super curious to understand the human experience on a more broad basis. So, that's how I started. +VICTORIA: I love that. And I'm curious if you could talk more about the mind-body connection and also maybe to describe, like, how these issues are treated currently. Being in the United States, it's like, you have a doctor for your body, and then one for your brain, and one for your teeth, and one for your feet. And it's kind of interesting that it's broken up that way. But what's your take on how healthcare treats people now for mental health versus physical health symptoms, and what would be the ideal state? +KRISTIAN: I think that's one of the fundamental challenges of our time, that there's all these silos in healthcare. Because, again, what we know already today is that, like, your emotions and your thoughts have a huge impact on your physical body, and, you know, you can experience that yourself. Everyone can experience that by doing meditation, and yoga, and things like this. And you can start learning and feeling and seeing that, like, very concretely in your own ways. +There's also something called biofeedback, which you can do with some of the apps like Aura and, like, Headspace and others. And then you can you do it with some wearables like with Fitbits and others, where through your breathing, you can, like, instantly see, actually, the changes in your heart rate variability, meaning that your nervous system state changes in real-time. So, some of these things were, like, eye-openers for me. +And I realized that if we, like, keep on focusing on some areas separately, that's going to be challenging because, you know, we're not going to see the full picture. And that's exactly what Western medicine is doing today. On the other hand, I think there's hope because, you know, there's more and more interest and more and more, like, bridging the gap here going on with companies like Meru, but also with, like, many, many other companies and many other providers and practitioners that are working in this domain. +That's kind of, like, fundamentally the challenge that if we, let's say, we go to a physical doctor, like, a primary care doctor, they never, almost never, address any of the mental health things, although we all know that they have a huge impact on your physical health. Like, there's a ton of research that stress has a big impact on your diabetes, as an example, and your glucose balance if you're a diabetic. +Like, usually, no doctor, you know, your endocrinologist or diabetes doctor will not talk about the stress or will not really, like, address the mental side of your diabetes. So, I think still, like, disconnected, but there are numerous areas where reconnecting these things better will be beneficial. And that's, again, one of my sort of personal goals in life and my mission to, like, drive this change [inaudible 06:06] in the future. +VICTORIA: Well, that makes sense to me as someone...I grew up with a parent who had type 1 diabetes their entire life. And what's also, like what you're saying, what's not discussed is if you get a diagnosis like diabetes, that also has an effect on your mental health. And you can stress about it. It can lead to depression. It can kind of make everything a lot worse. Do you also have any personal experience that led you to be really motivated in solving this problem? +KRISTIAN: One thing that I've openly shared is that I, unfortunately, I lost my oldest brother, Peter, to suicide. You know, the story with him, he was struggling with mental health challenges for a long time. He got access to care in terms of, like, he got medication. And, you know, prescription medications, unfortunately, for him, just made it worse. And he ended up, like, not really, like, benefiting, but just actually, like, struggling more and more. +And that's actually one of the things, also, what I realized when I founded Meru Health after my, you know, I used to be in diabetes with my first ventures. But now building my third healthcare business, Meru Health; it got started from my realization that the mental health industry is broken. Like, most people are only getting access to psychiatric drugs, as an example, as a sole remedy. Like, you know, they don't have access to a therapist. They don't have access to any kind of support. +They just see a PCP for 10 minutes, and they get a prescription, and off you go. And then the PCP, you may not see the PCP anymore at all, or maybe in, like, three months, you have, like, a phone call with them or whatever. So, like, that's kind of the experience also with my brother through which I realized this is not adequate. This is crazy. Like, if that's the way we're trying to treat these conditions, it's not going to work. +And through that, I did a lot of research and a lot of investigations in my early days before founding Meru Health after I had sold my last company. And what I realized, there's roughly, like, two-thirds of people that get access to mental health care, like, either psychiatric medication or maybe some therapy. Two-thirds of people still they don't respond to that care at all. One-third will respond, and only one-sixth will actually reach full remission of symptoms, meaning that they are completely in the clear with their symptoms. +So, that was kind of a crazy revelation for me that, like, two-thirds, like, are not getting anything out of these treatments. So, that's how I kind of eventually then realized that, okay, we got to rethink this model. Like, this model isn't working. Like, if we are only giving people mainly access to these two remedies and only, like, one-third's getting any benefits, then this is, like, really bad. Like, we got to do something about it. +And that's again why, you know, I founded Meru Health and Meru Health being about a more holistic approach, not just about, like, talk therapy or psychological aspects, but also sleep, nutrition, biofeedback, learning to regulate your body, your nervous system. There's a community, peer support community, and there are providers. You work with providers as well. But that's on the background why I kind of became super passionate about mental health care and what were some of the insights that I gained where I realized that this system is, like, so broken; we got to do something about it. +VICTORIA: Well, I have so many questions about Meru Health. But before we get into that, you mentioned you had started two other healthcare companies before this one. So, as a serial entrepreneur, what lessons were the most important that you took from those previous experience going into starting Meru Health? +KRISTIAN: There's many. So, I mean, like, first of all, when I founded my first company, I was, like, straight out of school, like, pretty young. And, I mean, like, I struggle so bad. Oh, it was such a hard journey. Like, it was a medical device company, glucose monitoring. So, founding a medical device company in Finland back in the day straight out of school was, like, a huge struggle. Eventually, we, you know, we sold the business after, like, seven years or so, but it was, like, a big learning curve for me, a lot of blood, sweat, and tears [laughs] for sure. +I think few learnings from that first business were it's extremely important to design your culture, and, like, culture is everything. Like, culture eats strategy for breakfast. So, if you don't have a culture that's clearly thought through and designed, it's going to end up being whatever. Like, I mean, like, every organization has a culture, but, like, mostly, the culture has not been intentionally designed. +And why that's important is that if you just let it grow weeds, whatever, it will grow in various different directions, but it does not necessarily serve its purpose that you may have had in mind. And, again, what I realized is that when you hire people, and you start growing the company, it's extremely important to, like, calibrate the values of, like, why are you doing this? What's important for this culture? Like, how do you want to work? Why do you want to work? And then, like, what are the kind of different rules and rituals and, like, habits of the organization that will make it successful in its mission? +I never knew that when I founded my first company, and the culture became, whatever, erratic. Like, you know, it was just, like, really hard, also, because of that. And we were not able to recruit the best people or the right kind of people for the right roles because we weren't clear on, like, what are the values? Like, why would someone want to work with us? And how to streamline these things. +So, I think that's the single biggest learning for me so far on my entrepreneurial journey that you got to very intentionally think about why do you want to build a company, whatever company you're founding. Why do you want to do it? What's going to get you up from bed every day to do your thing? And then, like, how do you want to work? Like, how do you want to work, yourself, accountability? You know, all these things. And what do you expect from others? Like, how do you want to work with other people? +So, that's kind of, like, what we actually...with my current business, Meru Health, like, we had, like, a value workshop with my co-founders before we founded the company. And we actually spent a lot of time in aligning and thinking about, like, these questions. Like, why do we want to do this? And with Meru's case, all of us founders we have mental health struggles in our family, so we all kind of came together because of that. We wanted to, like, help fix, at least make a dent in the system. +And then, you know, we kind of spend a lot of time thinking about also, like, how do we want to work with each other? The listeners thinking of founding a company, it's just really, really important to think about, like, also, how do you work? Like, what's the level of accountability with each other? And then, how do you, like, if you hire the first employees, how do you also translate these things to them as well so that there's cohesion, that there's, like, alignment in the team? +Because if all the arrows, so to speak, if they all point out in different directions, you're not going to create momentum, which you'll need to be able to break through and get to your first milestones as a company. So, I think that's the most important. I could, you know, talk about that for a day or so, but that's, like, the most essential learning for me personally, which I've applied, like, carefully after that. +VICTORIA: Well, I can imagine that having a clear vision and a set of values that you all know you're working together helps create a good emotional environment for everyone who's at the company, including you who's going to be repeating what the values are, and what the purpose is, and what you're trying to get done as the CEO. +KRISTIAN: Totally, yeah. Yeah, and, I mean, like, I can also, like, maybe continue on one more point there. One of the values for Meru Health we actually chose compassion and kind of kindness. Why did we do that? Like, many people have asked us like, "Why do you have, like, compassion or kind...like, why is it relevant for your startup?" Well, I think it's extremely relevant because, like, there's not enough kindness in the world. If you're kind of intentionally building kindness into your organization, you know, you're also going to enjoy the journey so much more yourself. +Because myself and my co-founders, we all figured that, like, we've all been part of other startups and being in, you know, at consulting firms, and we've been grinding like hell at different places. And, you know, it can be exciting. It can be fun. But it also can be pretty, like, challenging sometimes. But we figured that if we are able to instill or kind of, like, inject kindness into this kind of founding spirit of our company, into the culture of our company, Meru Health, you know, it's going to be so much more fun for us and also for all the future employees. +We know it's going to be hard. Like, building healthcare businesses and healthcare companies is really, really hard. It can take, like, a long time. It's a marathon. It's not a sprint. So, you kind of, like, need to do it for a long time and be committed and hold yourself and the team accountable. But you can do it in a way that's fun, and you can do it in a way that's, like, kind. You can be respectful, and you can be kind towards others. And it's going to be much more of a pleasant journey. So, that's one concrete example of, like, what came out of our value workshop and why we chose kindness or compassion as one of our values. +VICTORIA: I think that's so important and a really great foundation to build your team on and to really find the best talent that fits what you're trying to do. So, once you founded the company, you had your values workshop. What were some of the early discoveries in your process for founding Meru Health that maybe led to a pivot or a change in the way you were approaching the problem? +KRISTIAN: I had a pretty good sense of, like, what the problem was. So, as I described, like, I did a lot of research on the problem and, like, really understanding what are the caveats in the current mental health care system? Like, what's not working? So, I had a pretty clear understanding. And, again, like, having built other healthcare businesses before, I kind of, like, had a lot of experience already in general, like, how to build healthcare businesses. So, that was kind of a helpful starting point for me. +But what happened, actually, in the early days was that we first started from a more preventative perspective. So, actually, our first product was more of kind of a coach-led or a kind of a...it was more, like, a coach-led approach to workplace wellness and prevention of mental health problems. And we kind of built an app-based program where, you know, we'd have a coach work with you through video calls and through chat, and then you'd have, like, different lessons and different activities in the app on a week-by-week basis. And, in many ways, like, that worked pretty well. Like, people were excited. We got engagement, and we sold that to, like, a bunch of enterprise customers. And there was excitement. +But we realized a couple of things in the early days, which is really important, and this was, like, the first half [inaudible 15:57] when we had founded the company, that a lot of people didn't really have a clear problem when they came to us. Thus, the engagement wasn't there. So, people were kind of, like, just "surfing," quote, unquote. They were coming in and testing and trying it out. But they maybe were stressed and stuff, but they weren't really, like, having a real problem that they wanted to solve so that they would actually spend time with the product and, actually, like, learning skills, changing behavior, things like this. So, that was one big realization for us. +The other thing we realized was that in our societies, unfortunately, prevention is not yet valued, meaning that there's no money in prevention. There's no...it's really hard to build a business when there's no, like, existing payment pathways or existing reimbursement from insurance companies. Many of these structures are missing in our environment or in our society, meaning that then we kind of realized that it's really hard to scale this kind of a business because it's really hard to make an impact because no one's willing to pay for prevention. +Even though we had, like, great results already, and there's some good evidence already out there, but still, it's not the same as, like, the healthcare industry definitely exists and is working. And there's a problem, and you need to fix the problem. And whatever sickness or illness it is, there's kind of reasons and investments for fixing this problem. +So, we pivoted this to be a healthcare company, not a wellness company. We actually applied...pretty much applied the same product idea. We just replaced the coach with a therapist. And then we basically still had the app-based experience for, like, learning, like, homework, things like this. And that's kind of how it, like, structurally changed. So, that was our pivot. +We've actually only pivoted once, and I'd say, like, fairly minor pivot even because the same product, same idea is still there. It's more just, like, a little bit of a twist on, like, okay, we're not trying to, like, prevent things in a way. We're not trying to sell it as a preventative, but we started selling it as a healthcare intervention. +And maybe one more thing I think it's going to be essential or maybe interesting for everyone listening. I actually had the idea of building the healthcare intervention from the beginning, but I was too afraid to, actually, like, pursue it. I was too afraid because I felt that, oh, like, if we're going to build a healthcare company, like, it's harder, you know, it's going to be, like, complicated. We have, like, this new approach, the mind and body approach. It's going to be, like, novel. It's, like, hard, you know. So, I had all these fears in my head, which kind of prevented me from, like, really jumping. +My intuition was already telling me that this is the way to go, but I pushed it aside. And I was kind of like, hey, it's going to be easier to just, like, start with this preventative angle with, like, you know, you don't need clinical providers. You can have, like, coaches. It's going to be easier, you know? So, I was kind of, like, taking the easy path. I was kind of, like, too much listening to my fears, not my intuition. +And, eventually, we ended up pivoting, and we ended up where I had actually imagined the whole thing being from the beginning. But I wanted to tell this because, at least for me, on my journey, it's been, like, many times that I realized that sometimes these things are, like, if you distill them to the essence, like, what's the essential question here, it's like, is it the choice of fear or choice of love? And is your choice in life in, you know, being a founder, in life in general, is it coming from a place of fear, or is it coming from a place of love? +That's something which I think was kind of another key learning for me that I was so often making decisions that were based off of a fear. And I was kind of, you know, choosing things because I was afraid of something versus not being, like, excited about something or believing in something. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +VICTORIA: Well, one thing I've heard from therapy is that the feeling of fear, the answer is more information. And maybe you could tell me a little bit more and our listeners, like, what makes creating healthcare apps scary? [laughs] What are some of those challenges that are different from what you might expect just building a wellness app that's not having health data involved? +KRISTIAN: Yeah. Healthcare is, of course, like, regulated, and there's, like, you know, there are certain standards for care depending on whether it's mental health care, diabetes, or cardiology, or other areas. Like, there are certain things, like, you know, you need to have licensed providers who can practice medicine. Or if you have a medical device, you need to get FDA approvals. So, it's, like, a way, way heavier, you know, process. And it, like, has a lot more regulations and rules and different legal implications, data security implications, patient health information, you know, HIPAA, all these other things. +So, it's just a much, much more regulated space in general, and what that means is that it's slower. It's going to be slower to build. It's going to be slower to validate. The feedback loop is going to be slower. It's going to be more resource-intensive. You're going to need to invest in more resources. It's going to need more, like, expertise. You're going to need, like, regulatory expertise, like medical, clinical, all these other things that you don't need when you're building a wellness company or a product. So, it's just a lot heavier and just, like, way more regulated. +And the risks are also much more prominent in a way that you, as the CEO or the founder, or you as an operator, may end up being challenged even in court if something goes wrong. So, there's just more risks, and you got to think about, like, insurance. And, like, that's broadly speaking, like, some of the challenges of building a healthcare company versus building a wellness company. +VICTORIA: So, as a founder of previous healthcare companies, you might have already built those networks to get access to people who can help you with those things. But if you were a new founder and you know you want to start a health tech company, how would you go about building your team to fill in some of those gaps around the areas you need help in? +KRISTIAN: It's going to be a learning curve. There's, like, no single book or no single place where you can learn all these things. But I'd encourage, like, there's some great materials online for sure in, like, learning, like, what to consider when building a healthcare company. ChatGPT or Google will help you kind of get started on some of the essentials. +But then I would, like, pretty quickly, I would try to, like, immerse myself in the different circles or communities where there are other healthcare founders, where there are people who've already been building healthcare businesses, where there are maybe advisors or maybe, like, accelerators for startup companies. You want to learn these things from people who've already been doing these things. You don't want to try to, like, learn everything from books. It's going to be too slow, and you don't know what you don't know. So, you don't know how to, like, ask the right questions. +If you talk to people who've already been doing these things, they will be able to tell you, "Hey, you're not asking this and that question. Like, that's an important thing. Like, you should consider A, B, or C." So, I would say that, like, surround yourself with people who've been building healthcare businesses before and maybe try to get into an accelerator or just, like, find advisors, more, like, experienced people. +VICTORIA: That's great. It's all about community, which brings me back to the question I had about Meru Health. You mentioned there's a community aspect built into the app, and I was wondering if you could talk a little bit more about that feature and how it plays into the whole model. +KRISTIAN: Community is important. So, a lot of the people who struggle with mental health problems also very often feel that they are very much alone, so that was the case with my brother. Like, he also felt very much alone with his depression that, like, no one will understand me. Like, I'm the only one who's feeling like this. I'm feeling isolated. But there are so many people who are struggling with the same kind of thing or same kinds of emotions and feelings and symptoms. +And through our community feature, we have, like, people who are experiencing similar issues going through the Meru, you know, intervention. They can now, like, connect with each other, and they can, like, reflect with each other and see what's going on. It's a moderated kind of a forum type of a thing. So, licensed providers are always moderating and, you know, also being part of the discussions there. So, they're also contributing. +But it's very much of a place for people to reflect and see that, like, these struggles that I'm going through are not just...it's not just me. Like, there's also other people. You don't need to feel so alone. And you can share with others and see that, hey, there's ways to heal. There's ways to get better. You know, you're not alone struggling with these things. +VICTORIA: I think that's a really powerful point about making that connection, making that community, and feeling like you're not alone. What other features make the Meru Health app unique in solving this problem? +KRISTIAN: We are basically a clinic, like, you know, we call it a virtual clinic. So, we have providers. There are, like, licensed therapists. We have doctors, psychiatrists. We have coaches. We have care coordinators. So, these are all real human beings that are actually practicing medicine and supporting our members or our patients. +And then, we have an app-based program, and the app is basically your home for accessing the Meru services. So, whether you're doing video calls or whether, you know, you can do them through the app. Or you can be chatting with your providers, or you can get access to, like, you know, support from the care coordinators if you need to navigate your insurance benefits or things like this. +And then, basically, in the app, you're going through different modalities of care. So, one of the unique things about Meru, like, why we built the company, why the company exists, is to kind of make this more holistic or more, like, a lifestyle medicine approach to mental health care, make it available for people. And it includes not only talk therapy or cognitive behavioral therapy, which is the normal typical way of, like, doing talk therapy. It also includes a lot of, like, mindfulness practices, a lot of...sleep kind of is a big topic where we help people understand that, like, there's no mental health without proper sleep. And it's also a physical health issue if you're not sleeping. So, sleep is essential. +There are many things that you can learn, you know, like some sleep hygiene things, meaning that, like, you shouldn't do, like, blue lights just before bed. You shouldn't do, like, exercise just before bed. You shouldn't eat big meals before bed. So, there's many, many things that you kind of, like, once you learn to know, you'll improve, like, your sleep dramatically. And once you improve your sleep, you improve your health. Like, it's a direct correlation. So, these are things that we teach people as part of one of the modules there. +Then there's, like, nutrition, as we call it, food and mood. So, there's a huge connection between, like, certain nutrients or diets with, like, mental health. I'll just give you a really quick example. Processed foods are really detrimental to brain health and, mental health, and also physical health. But, like, most doctors, if you're talking to most healthcare professionals, most, like, primary care doctors, if you go to see a primary care doctor about any mental health concerns you may have, like, 99% of them won't tell you anything about your diet. They won't tell you anything about processed foods being very detrimental. +And, again, so we are kind of including things like these, which are all based on science. Like, there's a ton of research behind these things. And we've also, ourselves, done a lot of research with Stanford, with Harvard, with other universities. But that's kind of another example of, like, some of the essentials that go beyond just the standard talk therapy in helping people more holistically learn skills, learn knowledge to help them get better. +VICTORIA: That's really cool. So, what does success look like six months from now or five years from now? It's a long process, so... +KRISTIAN: We're now, like, 130 people at the moment at Meru Health. So, we've kind of, like, come quite far from the early days of, like, just building the product, getting the first customers, doing the first validation, publishing the first research studies, first clinical studies showing that this is effective, so forth. But there's still...it feels like it's day one still because we're going to feel that we're just getting started with, like, you know, we work mainly with insurance companies. So, there's a lot of insurance companies like Cigna, and Aetna, and United, Optum, some of these ones that we work with, some Blue Shield Blue Cross. But there's so much opportunity. +So, we're now available for, like, 30,000,000 Americans. Obviously, there's way more many Americans we could be available for. So, we're constantly working in making our footprint bigger so that more and more insurance companies would reimburse for Meru's services so that people in different states and different areas can also, like, access these services if they want to. +And, like, I mean, as I mentioned earlier, building a healthcare company is a marathon. It's not a sprint. So, we've now been building, like, six-plus years, you know, probably, like, another five, six years until we'll be, like, fully, like, reaching all the people in the U.S., hopefully, and so forth. And then, you know, we actually founded the company...initially, we founded from a place of, like, we want to build a global company. +We want to democratize access to these kinds of, like, new healthcare services also, beyond just being in the U.S. The U.S. is just a really great place to start these kinds of companies, in many ways, the perfect place. But we also are, you know, we're looking at expanding into some European countries in the future and, hopefully, even beyond that. But that's something what's happening now and what we're thinking about for the future. +VICTORIA: Great. So, it's getting to expand your footprint with who has access to it in the United States and then even looking beyond, globally, and seeing how wide you can reach. +KRISTIAN: Yep. Exactly. +VICTORIA: I love that. Okay. And then, what are the challenges that you see? What are those blockers or issues on the horizon that would prevent you from reaching your goals? +KRISTIAN: I guess one challenge we're facing is that, as I mentioned, we work with insurance companies quite a lot, so some of these big names that I talked about and some more, like, regional smaller insurance companies. But one of the things is that since our care philosophy and the modalities of care we offer, like the sleep and nutrition, the biofeedback wearable, some of these other things that are not typical to mental health care, that are not conventional mental health care, getting reimbursements and getting this kind of a more comprehensive approach, getting it reimbursed by insurance companies is actually quite a challenge. +Because insurance companies typically reimburse for very select standardized and kind of known services and, like, standard types of care. And it's harder for them to reimburse for something which is, like, novel and very different, even though we've published now 14 clinical studies, including, like, randomized control studies, which is the gold standard in clinical research, and then also, like, large, large, like, thousands of people, single-arm trials, which are, like, more like population trials. +So, we have, like, a ton of evidence to show that this is very effective, actually, roughly 2 times more effective than standard of mental health care. So, it's very much more effective, and people are maintaining the gains. We've published also our, like, one-year and our two-year data. So, there's a ton of that evidence there, but it's still hard to bring in this kind of innovation into the market. That's one of the challenges that we're working on. +Then, it's always a challenge to find the best talent, to hire great talent. I've learned over my career to always challenge myself in, like, making sure that we always think through, like, how can we hire the best talent for every role and not let your standards, like, drop. If you're growing fast, you got to hire more people. That is extremely, extremely important. And it happens so easily that when you start growing faster, you got to hire for multiple roles. You actually start, like, lowering your standards because you face pressures on, like, hiring people faster and growing faster. +VICTORIA: And I wanted to ask you, too, about your background in computer science. And as you're thinking about scaling and expanding globally, what are you thinking about on the infrastructure platform side for the technology that you've built? +KRISTIAN: What we've built so far is the patient-facing app, so that's the home for the patient to kind of access our services. For our providers, we have a network of providers that we also built them an electronic medical record. So, we kind of, you know, from the start realized that there's not an electronic medical record product out there that would fit our different way of providing care. So, we actually built that in-house by ourselves, so we have that now. +And then, we also have a kind of a dashboard for our providers where there's, like, traffic lights. So, the system actually, like, sorts people based on different data inputs and places them in order of priority. Like, if someone's reporting suicidality as an example, that's going to be a red flag on a provider's dashboard. These different, like, categories, like, the red flags and then, like, more, like, amber and then green. So, that system is something we're constantly developing and fine-tuning on, like, improving the algorithms of detecting issues. +And then, on the other hand, helping our providers to focus their time on the right patient at the right time because that's also really critical in care. So, there's plenty of work going on there. We're also working on our SOC 2, which is kind of this security standard in IT. So, we're working on our SOC 2 project currently internally. So, that's a pretty big one for us to mature into that. And yeah, so the platform is kind of evolving. We're kind of building more features. +We're also building more of these different kinds of modules for people who are struggling with different kinds of issues. So, a concrete example, how can we better support people with post-traumatic stress disorder or people who have, like, panic attacks? And so, there's these kinds of more, like, nuanced areas of mental health where we can double down on by building different modularity and more individualized care pathways for people. +VICTORIA: That's wonderful. I love that. Thank you for sharing all of it. Is there anything else that you would like to promote today? +KRISTIAN: Yeah. Well, hey, thanks so much. I really appreciate you having me on this podcast today. What I, again, found useful as a founder, as an operator, is to take good care of yourself. Like, it's really important to also remember not to exhaust your resources constantly, but, like, try to kind of find ways to take care of yourself as a founder, as an entrepreneur, and also kind of, like, nurture yourself. Because, otherwise, I have lots of founder friends, lots of entrepreneur friends, and so many times people are, like, exhausting themselves. And they are kind of, like, running too fast or, like, trying to do this and that more and, you know, just do more and more all the time. +You know, while that's important, it's important to be running. It's important to be kind of productive as a founder. It's also like a trap, you know. People also fall into a trap if they're trying to do too much at the same time. It's really important to focus on rather fewer things, and it's also very important to take care of yourself. So, self-care, self-compassion, I think, those are important themes that are not too often talked about when it comes to entrepreneurship, but I think that's something I've learned to be important. +VICTORIA: It sounds like the value that you said as a company also applies for you as an individual, like, having compassion towards yourself and kindness. I think that's a really beautiful way to wrap the episode here unless...do you have any questions for me or thoughtbot? +KRISTIAN: I've been following you a bit. And just curious, like, what's coming up for you? +VICTORIA: For me personally, well, I bought a new house, so we're, like, renovating that in California. So, I'm actually switching to, like, maybe trying to do a little bit less travel compared to what I did last year, but going to more local things and getting, like, our San Diego CTO Lunches spun up again and meeting people here who are building really cool things. Lots of great health tech companies in San Diego also. +What else do we have going on? I'm definitely going to be climbing. I'm going climbing on Saturday. And then probably in LA, I'll go up and do some climbing the next couple of weeks. So, I'm looking forward to having a little bit more balance to life this year [chuckles], the best-laid plans. But yeah, that's what's coming up and, just trying to, like, enjoy where I live, enjoy my family and friends and the companies that I work at, and do a good job. That's it. +KRISTIAN: Great. Well, hey, appreciate it. +VICTORIA: Yeah. Wonderful. Well, thank you so much for coming on, and being a part of the show, and sharing your story. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg, or on Mastodon @thoughtbot.social/vguido. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Kristian Ranta, the founder of Meru Health, shares the company's journey from its inception to its current status as a leading provider of mental health solutions. Kristian reflects on the decision to pivot Meru Health from a wellness-focused to a healthcare-centered company, emphasizing the importance of overcoming fears and listening to intuition in entrepreneurial pursuits. He discusses the challenges and rewards of building a healthcare startup, highlighting the complexities of navigating regulatory frameworks and securing insurance reimbursements.

+ +

Throughout the conversation, Kristian elaborates on Meru Health's unique approach to mental healthcare, which integrates therapy, coaching, and app-based interventions to offer users a holistic and personalized experience. He underscores the significance of community support in mental health treatment and explains how Meru Health's platform fosters connection among individuals facing similar challenges. Kristian also delves into the company's plans for expansion, both within the United States and globally, while addressing ongoing challenges such as securing insurance reimbursements and maintaining high standards for talent acquisition.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Kristian Ranta, CEO and Founder for Meru Health, a new standard for mental health care. Kristian, thank you for joining me.

+ +

KRISTIAN: Thanks, Victoria. Great to be here today. Appreciate it.

+ +

VICTORIA: Wonderful. To break the ice a little bit to get us started in the conversation here, I don't know if you can hear it, but I have a slight cold and congestion going on. And since you're a healthcare startup, I thought I would ask you, what is your favorite comfort food when you're sick?

+ +

KRISTIAN: I don't know whether it's a comfort food or not, but I think kind of what I always consume if I get, like, some flu symptoms or stuff like that it's ginger, honey, and then garlic. I try to combine these things, and it's semi-tasty. Like, it depends on, like, how strong you make it, but it's definitely effective. So, it's been my go-to thing when I get sick.

+ +

VICTORIA: Me too. I like to try to put all those things into a soup of some kind [laughs], some chicken soup. I've learned how to make some sort of version of congee, which is, like, a rice porridge, which I love because you can kind of just sit it on the stove, and it cooks all day. And you could add in all those flavors, and it comes together really nicely.

+ +

For me, I think that's really nice to think about what you like to eat when you're sick because when you're sick, it affects everything else going on in your body. So, I'm sure you have some personal experiences about how your mental health and your physical health are all interrelated.

+ +

KRISTIAN: I mean, totally. Actually, like, I've been a biohacker for quite a while. So, I've been, like, just trying a bunch of things, like, on the physical health side and, like, exercise. And I'm from Finland originally, so a lot of cold exposure, sauna, swimming in the icy water, stuff like that. And then, of course, a lot of, like, different dietary tests that I've done over the years. And I think there's, yeah, I've recognized that there's a huge connection, and it's like the mind and the body are not, like, disconnected. They're in a way the same.

+ +

Personally, also, like, a big piece kind of for me in this regard has been my journey of meditation. So, I started maybe, like, 10, 12 years ago, started meditating every day, and then I've done a bunch of different retreats and kind of dug deeper. Especially through meditation, I've learned very [inaudible 02:15] to experience the connectedness of my thoughts, and my emotions, and feelings, and the body. So, anyway, that's, like, one of my favorite topics, so...

+ +

VICTORIA: So, it sounds like you've always had this interest in the mind-body connection and how to optimize your health. How did that lead you, or what about your background led you to found Meru Health?

+ +

KRISTIAN: I'm from Finland originally. So, I moved to the States in 2018 with Meru Health with my current company. But way back, I studied computer science, did my undergraduate and graduate studies in Finland. And then I kind of, like, ended up working at a healthcare company, a startup company, while I was still studying. And I worked there for a couple of years. And this company was a clinical trial software company, so making it easier for pharmaceutical companies to collect data in patient trials for, like, new drugs, and new developments, and stuff like that.

+ +

I was basically at that company for a couple of years, and that was my first dip into healthcare and technology, the intersection. And I got so excited, and I realized that, hey, this is a place where I can use my excitement for technology and my skills and all that stuff. But I can also then, like, see the immediate improvement in people's lives and how we can help others, and that kind of resonated with me.

+ +

So, I quit after two years and then founded my first own business, which was in diabetes, so one of my co-founders back then is a diabetic. And that's kind of, like, how I went into healthcare. And, for me, then learning the mind and body connection started at the same time. Pretty much I kind of, you know, again, mentioned that I've been meditating for a while. So, I started meditating, and I started just learning about these things and just, like, became super curious to understand the human experience on a more broad basis. So, that's how I started.

+ +

VICTORIA: I love that. And I'm curious if you could talk more about the mind-body connection and also maybe to describe, like, how these issues are treated currently. Being in the United States, it's like, you have a doctor for your body, and then one for your brain, and one for your teeth, and one for your feet. And it's kind of interesting that it's broken up that way. But what's your take on how healthcare treats people now for mental health versus physical health symptoms, and what would be the ideal state?

+ +

KRISTIAN: I think that's one of the fundamental challenges of our time, that there's all these silos in healthcare. Because, again, what we know already today is that, like, your emotions and your thoughts have a huge impact on your physical body, and, you know, you can experience that yourself. Everyone can experience that by doing meditation, and yoga, and things like this. And you can start learning and feeling and seeing that, like, very concretely in your own ways.

+ +

There's also something called biofeedback, which you can do with some of the apps like Aura and, like, Headspace and others. And then you can you do it with some wearables like with Fitbits and others, where through your breathing, you can, like, instantly see, actually, the changes in your heart rate variability, meaning that your nervous system state changes in real-time. So, some of these things were, like, eye-openers for me.

+ +

And I realized that if we, like, keep on focusing on some areas separately, that's going to be challenging because, you know, we're not going to see the full picture. And that's exactly what Western medicine is doing today. On the other hand, I think there's hope because, you know, there's more and more interest and more and more, like, bridging the gap here going on with companies like Meru, but also with, like, many, many other companies and many other providers and practitioners that are working in this domain.

+ +

That's kind of, like, fundamentally the challenge that if we, let's say, we go to a physical doctor, like, a primary care doctor, they never, almost never, address any of the mental health things, although we all know that they have a huge impact on your physical health. Like, there's a ton of research that stress has a big impact on your diabetes, as an example, and your glucose balance if you're a diabetic.

+ +

Like, usually, no doctor, you know, your endocrinologist or diabetes doctor will not talk about the stress or will not really, like, address the mental side of your diabetes. So, I think still, like, disconnected, but there are numerous areas where reconnecting these things better will be beneficial. And that's, again, one of my sort of personal goals in life and my mission to, like, drive this change [inaudible 06:06] in the future.

+ +

VICTORIA: Well, that makes sense to me as someone...I grew up with a parent who had type 1 diabetes their entire life. And what's also, like what you're saying, what's not discussed is if you get a diagnosis like diabetes, that also has an effect on your mental health. And you can stress about it. It can lead to depression. It can kind of make everything a lot worse. Do you also have any personal experience that led you to be really motivated in solving this problem?

+ +

KRISTIAN: One thing that I've openly shared is that I, unfortunately, I lost my oldest brother, Peter, to suicide. You know, the story with him, he was struggling with mental health challenges for a long time. He got access to care in terms of, like, he got medication. And, you know, prescription medications, unfortunately, for him, just made it worse. And he ended up, like, not really, like, benefiting, but just actually, like, struggling more and more.

+ +

And that's actually one of the things, also, what I realized when I founded Meru Health after my, you know, I used to be in diabetes with my first ventures. But now building my third healthcare business, Meru Health; it got started from my realization that the mental health industry is broken. Like, most people are only getting access to psychiatric drugs, as an example, as a sole remedy. Like, you know, they don't have access to a therapist. They don't have access to any kind of support.

+ +

They just see a PCP for 10 minutes, and they get a prescription, and off you go. And then the PCP, you may not see the PCP anymore at all, or maybe in, like, three months, you have, like, a phone call with them or whatever. So, like, that's kind of the experience also with my brother through which I realized this is not adequate. This is crazy. Like, if that's the way we're trying to treat these conditions, it's not going to work.

+ +

And through that, I did a lot of research and a lot of investigations in my early days before founding Meru Health after I had sold my last company. And what I realized, there's roughly, like, two-thirds of people that get access to mental health care, like, either psychiatric medication or maybe some therapy. Two-thirds of people still they don't respond to that care at all. One-third will respond, and only one-sixth will actually reach full remission of symptoms, meaning that they are completely in the clear with their symptoms.

+ +

So, that was kind of a crazy revelation for me that, like, two-thirds, like, are not getting anything out of these treatments. So, that's how I kind of eventually then realized that, okay, we got to rethink this model. Like, this model isn't working. Like, if we are only giving people mainly access to these two remedies and only, like, one-third's getting any benefits, then this is, like, really bad. Like, we got to do something about it.

+ +

And that's again why, you know, I founded Meru Health and Meru Health being about a more holistic approach, not just about, like, talk therapy or psychological aspects, but also sleep, nutrition, biofeedback, learning to regulate your body, your nervous system. There's a community, peer support community, and there are providers. You work with providers as well. But that's on the background why I kind of became super passionate about mental health care and what were some of the insights that I gained where I realized that this system is, like, so broken; we got to do something about it.

+ +

VICTORIA: Well, I have so many questions about Meru Health. But before we get into that, you mentioned you had started two other healthcare companies before this one. So, as a serial entrepreneur, what lessons were the most important that you took from those previous experience going into starting Meru Health?

+ +

KRISTIAN: There's many. So, I mean, like, first of all, when I founded my first company, I was, like, straight out of school, like, pretty young. And, I mean, like, I struggle so bad. Oh, it was such a hard journey. Like, it was a medical device company, glucose monitoring. So, founding a medical device company in Finland back in the day straight out of school was, like, a huge struggle. Eventually, we, you know, we sold the business after, like, seven years or so, but it was, like, a big learning curve for me, a lot of blood, sweat, and tears [laughs] for sure.

+ +

I think few learnings from that first business were it's extremely important to design your culture, and, like, culture is everything. Like, culture eats strategy for breakfast. So, if you don't have a culture that's clearly thought through and designed, it's going to end up being whatever. Like, I mean, like, every organization has a culture, but, like, mostly, the culture has not been intentionally designed.

+ +

And why that's important is that if you just let it grow weeds, whatever, it will grow in various different directions, but it does not necessarily serve its purpose that you may have had in mind. And, again, what I realized is that when you hire people, and you start growing the company, it's extremely important to, like, calibrate the values of, like, why are you doing this? What's important for this culture? Like, how do you want to work? Why do you want to work? And then, like, what are the kind of different rules and rituals and, like, habits of the organization that will make it successful in its mission?

+ +

I never knew that when I founded my first company, and the culture became, whatever, erratic. Like, you know, it was just, like, really hard, also, because of that. And we were not able to recruit the best people or the right kind of people for the right roles because we weren't clear on, like, what are the values? Like, why would someone want to work with us? And how to streamline these things.

+ +

So, I think that's the single biggest learning for me so far on my entrepreneurial journey that you got to very intentionally think about why do you want to build a company, whatever company you're founding. Why do you want to do it? What's going to get you up from bed every day to do your thing? And then, like, how do you want to work? Like, how do you want to work, yourself, accountability? You know, all these things. And what do you expect from others? Like, how do you want to work with other people?

+ +

So, that's kind of, like, what we actually...with my current business, Meru Health, like, we had, like, a value workshop with my co-founders before we founded the company. And we actually spent a lot of time in aligning and thinking about, like, these questions. Like, why do we want to do this? And with Meru's case, all of us founders we have mental health struggles in our family, so we all kind of came together because of that. We wanted to, like, help fix, at least make a dent in the system.

+ +

And then, you know, we kind of spend a lot of time thinking about also, like, how do we want to work with each other? The listeners thinking of founding a company, it's just really, really important to think about, like, also, how do you work? Like, what's the level of accountability with each other? And then, how do you, like, if you hire the first employees, how do you also translate these things to them as well so that there's cohesion, that there's, like, alignment in the team?

+ +

Because if all the arrows, so to speak, if they all point out in different directions, you're not going to create momentum, which you'll need to be able to break through and get to your first milestones as a company. So, I think that's the most important. I could, you know, talk about that for a day or so, but that's, like, the most essential learning for me personally, which I've applied, like, carefully after that.

+ +

VICTORIA: Well, I can imagine that having a clear vision and a set of values that you all know you're working together helps create a good emotional environment for everyone who's at the company, including you who's going to be repeating what the values are, and what the purpose is, and what you're trying to get done as the CEO.

+ +

KRISTIAN: Totally, yeah. Yeah, and, I mean, like, I can also, like, maybe continue on one more point there. One of the values for Meru Health we actually chose compassion and kind of kindness. Why did we do that? Like, many people have asked us like, "Why do you have, like, compassion or kind...like, why is it relevant for your startup?" Well, I think it's extremely relevant because, like, there's not enough kindness in the world. If you're kind of intentionally building kindness into your organization, you know, you're also going to enjoy the journey so much more yourself.

+ +

Because myself and my co-founders, we all figured that, like, we've all been part of other startups and being in, you know, at consulting firms, and we've been grinding like hell at different places. And, you know, it can be exciting. It can be fun. But it also can be pretty, like, challenging sometimes. But we figured that if we are able to instill or kind of, like, inject kindness into this kind of founding spirit of our company, into the culture of our company, Meru Health, you know, it's going to be so much more fun for us and also for all the future employees.

+ +

We know it's going to be hard. Like, building healthcare businesses and healthcare companies is really, really hard. It can take, like, a long time. It's a marathon. It's not a sprint. So, you kind of, like, need to do it for a long time and be committed and hold yourself and the team accountable. But you can do it in a way that's fun, and you can do it in a way that's, like, kind. You can be respectful, and you can be kind towards others. And it's going to be much more of a pleasant journey. So, that's one concrete example of, like, what came out of our value workshop and why we chose kindness or compassion as one of our values.

+ +

VICTORIA: I think that's so important and a really great foundation to build your team on and to really find the best talent that fits what you're trying to do. So, once you founded the company, you had your values workshop. What were some of the early discoveries in your process for founding Meru Health that maybe led to a pivot or a change in the way you were approaching the problem?

+ +

KRISTIAN: I had a pretty good sense of, like, what the problem was. So, as I described, like, I did a lot of research on the problem and, like, really understanding what are the caveats in the current mental health care system? Like, what's not working? So, I had a pretty clear understanding. And, again, like, having built other healthcare businesses before, I kind of, like, had a lot of experience already in general, like, how to build healthcare businesses. So, that was kind of a helpful starting point for me.

+ +

But what happened, actually, in the early days was that we first started from a more preventative perspective. So, actually, our first product was more of kind of a coach-led or a kind of a...it was more, like, a coach-led approach to workplace wellness and prevention of mental health problems. And we kind of built an app-based program where, you know, we'd have a coach work with you through video calls and through chat, and then you'd have, like, different lessons and different activities in the app on a week-by-week basis. And, in many ways, like, that worked pretty well. Like, people were excited. We got engagement, and we sold that to, like, a bunch of enterprise customers. And there was excitement.

+ +

But we realized a couple of things in the early days, which is really important, and this was, like, the first half [inaudible 15:57] when we had founded the company, that a lot of people didn't really have a clear problem when they came to us. Thus, the engagement wasn't there. So, people were kind of, like, just "surfing," quote, unquote. They were coming in and testing and trying it out. But they maybe were stressed and stuff, but they weren't really, like, having a real problem that they wanted to solve so that they would actually spend time with the product and, actually, like, learning skills, changing behavior, things like this. So, that was one big realization for us.

+ +

The other thing we realized was that in our societies, unfortunately, prevention is not yet valued, meaning that there's no money in prevention. There's no...it's really hard to build a business when there's no, like, existing payment pathways or existing reimbursement from insurance companies. Many of these structures are missing in our environment or in our society, meaning that then we kind of realized that it's really hard to scale this kind of a business because it's really hard to make an impact because no one's willing to pay for prevention.

+ +

Even though we had, like, great results already, and there's some good evidence already out there, but still, it's not the same as, like, the healthcare industry definitely exists and is working. And there's a problem, and you need to fix the problem. And whatever sickness or illness it is, there's kind of reasons and investments for fixing this problem.

+ +

So, we pivoted this to be a healthcare company, not a wellness company. We actually applied...pretty much applied the same product idea. We just replaced the coach with a therapist. And then we basically still had the app-based experience for, like, learning, like, homework, things like this. And that's kind of how it, like, structurally changed. So, that was our pivot.

+ +

We've actually only pivoted once, and I'd say, like, fairly minor pivot even because the same product, same idea is still there. It's more just, like, a little bit of a twist on, like, okay, we're not trying to, like, prevent things in a way. We're not trying to sell it as a preventative, but we started selling it as a healthcare intervention.

+ +

And maybe one more thing I think it's going to be essential or maybe interesting for everyone listening. I actually had the idea of building the healthcare intervention from the beginning, but I was too afraid to, actually, like, pursue it. I was too afraid because I felt that, oh, like, if we're going to build a healthcare company, like, it's harder, you know, it's going to be, like, complicated. We have, like, this new approach, the mind and body approach. It's going to be, like, novel. It's, like, hard, you know. So, I had all these fears in my head, which kind of prevented me from, like, really jumping.

+ +

My intuition was already telling me that this is the way to go, but I pushed it aside. And I was kind of like, hey, it's going to be easier to just, like, start with this preventative angle with, like, you know, you don't need clinical providers. You can have, like, coaches. It's going to be easier, you know? So, I was kind of, like, taking the easy path. I was kind of, like, too much listening to my fears, not my intuition.

+ +

And, eventually, we ended up pivoting, and we ended up where I had actually imagined the whole thing being from the beginning. But I wanted to tell this because, at least for me, on my journey, it's been, like, many times that I realized that sometimes these things are, like, if you distill them to the essence, like, what's the essential question here, it's like, is it the choice of fear or choice of love? And is your choice in life in, you know, being a founder, in life in general, is it coming from a place of fear, or is it coming from a place of love?

+ +

That's something which I think was kind of another key learning for me that I was so often making decisions that were based off of a fear. And I was kind of, you know, choosing things because I was afraid of something versus not being, like, excited about something or believing in something.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: Well, one thing I've heard from therapy is that the feeling of fear, the answer is more information. And maybe you could tell me a little bit more and our listeners, like, what makes creating healthcare apps scary? [laughs] What are some of those challenges that are different from what you might expect just building a wellness app that's not having health data involved?

+ +

KRISTIAN: Yeah. Healthcare is, of course, like, regulated, and there's, like, you know, there are certain standards for care depending on whether it's mental health care, diabetes, or cardiology, or other areas. Like, there are certain things, like, you know, you need to have licensed providers who can practice medicine. Or if you have a medical device, you need to get FDA approvals. So, it's, like, a way, way heavier, you know, process. And it, like, has a lot more regulations and rules and different legal implications, data security implications, patient health information, you know, HIPAA, all these other things.

+ +

So, it's just a much, much more regulated space in general, and what that means is that it's slower. It's going to be slower to build. It's going to be slower to validate. The feedback loop is going to be slower. It's going to be more resource-intensive. You're going to need to invest in more resources. It's going to need more, like, expertise. You're going to need, like, regulatory expertise, like medical, clinical, all these other things that you don't need when you're building a wellness company or a product. So, it's just a lot heavier and just, like, way more regulated.

+ +

And the risks are also much more prominent in a way that you, as the CEO or the founder, or you as an operator, may end up being challenged even in court if something goes wrong. So, there's just more risks, and you got to think about, like, insurance. And, like, that's broadly speaking, like, some of the challenges of building a healthcare company versus building a wellness company.

+ +

VICTORIA: So, as a founder of previous healthcare companies, you might have already built those networks to get access to people who can help you with those things. But if you were a new founder and you know you want to start a health tech company, how would you go about building your team to fill in some of those gaps around the areas you need help in?

+ +

KRISTIAN: It's going to be a learning curve. There's, like, no single book or no single place where you can learn all these things. But I'd encourage, like, there's some great materials online for sure in, like, learning, like, what to consider when building a healthcare company. ChatGPT or Google will help you kind of get started on some of the essentials.

+ +

But then I would, like, pretty quickly, I would try to, like, immerse myself in the different circles or communities where there are other healthcare founders, where there are people who've already been building healthcare businesses, where there are maybe advisors or maybe, like, accelerators for startup companies. You want to learn these things from people who've already been doing these things. You don't want to try to, like, learn everything from books. It's going to be too slow, and you don't know what you don't know. So, you don't know how to, like, ask the right questions.

+ +

If you talk to people who've already been doing these things, they will be able to tell you, "Hey, you're not asking this and that question. Like, that's an important thing. Like, you should consider A, B, or C." So, I would say that, like, surround yourself with people who've been building healthcare businesses before and maybe try to get into an accelerator or just, like, find advisors, more, like, experienced people.

+ +

VICTORIA: That's great. It's all about community, which brings me back to the question I had about Meru Health. You mentioned there's a community aspect built into the app, and I was wondering if you could talk a little bit more about that feature and how it plays into the whole model.

+ +

KRISTIAN: Community is important. So, a lot of the people who struggle with mental health problems also very often feel that they are very much alone, so that was the case with my brother. Like, he also felt very much alone with his depression that, like, no one will understand me. Like, I'm the only one who's feeling like this. I'm feeling isolated. But there are so many people who are struggling with the same kind of thing or same kinds of emotions and feelings and symptoms.

+ +

And through our community feature, we have, like, people who are experiencing similar issues going through the Meru, you know, intervention. They can now, like, connect with each other, and they can, like, reflect with each other and see what's going on. It's a moderated kind of a forum type of a thing. So, licensed providers are always moderating and, you know, also being part of the discussions there. So, they're also contributing.

+ +

But it's very much of a place for people to reflect and see that, like, these struggles that I'm going through are not just...it's not just me. Like, there's also other people. You don't need to feel so alone. And you can share with others and see that, hey, there's ways to heal. There's ways to get better. You know, you're not alone struggling with these things.

+ +

VICTORIA: I think that's a really powerful point about making that connection, making that community, and feeling like you're not alone. What other features make the Meru Health app unique in solving this problem?

+ +

KRISTIAN: We are basically a clinic, like, you know, we call it a virtual clinic. So, we have providers. There are, like, licensed therapists. We have doctors, psychiatrists. We have coaches. We have care coordinators. So, these are all real human beings that are actually practicing medicine and supporting our members or our patients.

+ +

And then, we have an app-based program, and the app is basically your home for accessing the Meru services. So, whether you're doing video calls or whether, you know, you can do them through the app. Or you can be chatting with your providers, or you can get access to, like, you know, support from the care coordinators if you need to navigate your insurance benefits or things like this.

+ +

And then, basically, in the app, you're going through different modalities of care. So, one of the unique things about Meru, like, why we built the company, why the company exists, is to kind of make this more holistic or more, like, a lifestyle medicine approach to mental health care, make it available for people. And it includes not only talk therapy or cognitive behavioral therapy, which is the normal typical way of, like, doing talk therapy. It also includes a lot of, like, mindfulness practices, a lot of...sleep kind of is a big topic where we help people understand that, like, there's no mental health without proper sleep. And it's also a physical health issue if you're not sleeping. So, sleep is essential.

+ +

There are many things that you can learn, you know, like some sleep hygiene things, meaning that, like, you shouldn't do, like, blue lights just before bed. You shouldn't do, like, exercise just before bed. You shouldn't eat big meals before bed. So, there's many, many things that you kind of, like, once you learn to know, you'll improve, like, your sleep dramatically. And once you improve your sleep, you improve your health. Like, it's a direct correlation. So, these are things that we teach people as part of one of the modules there.

+ +

Then there's, like, nutrition, as we call it, food and mood. So, there's a huge connection between, like, certain nutrients or diets with, like, mental health. I'll just give you a really quick example. Processed foods are really detrimental to brain health and, mental health, and also physical health. But, like, most doctors, if you're talking to most healthcare professionals, most, like, primary care doctors, if you go to see a primary care doctor about any mental health concerns you may have, like, 99% of them won't tell you anything about your diet. They won't tell you anything about processed foods being very detrimental.

+ +

And, again, so we are kind of including things like these, which are all based on science. Like, there's a ton of research behind these things. And we've also, ourselves, done a lot of research with Stanford, with Harvard, with other universities. But that's kind of another example of, like, some of the essentials that go beyond just the standard talk therapy in helping people more holistically learn skills, learn knowledge to help them get better.

+ +

VICTORIA: That's really cool. So, what does success look like six months from now or five years from now? It's a long process, so...

+ +

KRISTIAN: We're now, like, 130 people at the moment at Meru Health. So, we've kind of, like, come quite far from the early days of, like, just building the product, getting the first customers, doing the first validation, publishing the first research studies, first clinical studies showing that this is effective, so forth. But there's still...it feels like it's day one still because we're going to feel that we're just getting started with, like, you know, we work mainly with insurance companies. So, there's a lot of insurance companies like Cigna, and Aetna, and United, Optum, some of these ones that we work with, some Blue Shield Blue Cross. But there's so much opportunity.

+ +

So, we're now available for, like, 30,000,000 Americans. Obviously, there's way more many Americans we could be available for. So, we're constantly working in making our footprint bigger so that more and more insurance companies would reimburse for Meru's services so that people in different states and different areas can also, like, access these services if they want to.

+ +

And, like, I mean, as I mentioned earlier, building a healthcare company is a marathon. It's not a sprint. So, we've now been building, like, six-plus years, you know, probably, like, another five, six years until we'll be, like, fully, like, reaching all the people in the U.S., hopefully, and so forth. And then, you know, we actually founded the company...initially, we founded from a place of, like, we want to build a global company.

+ +

We want to democratize access to these kinds of, like, new healthcare services also, beyond just being in the U.S. The U.S. is just a really great place to start these kinds of companies, in many ways, the perfect place. But we also are, you know, we're looking at expanding into some European countries in the future and, hopefully, even beyond that. But that's something what's happening now and what we're thinking about for the future.

+ +

VICTORIA: Great. So, it's getting to expand your footprint with who has access to it in the United States and then even looking beyond, globally, and seeing how wide you can reach.

+ +

KRISTIAN: Yep. Exactly.

+ +

VICTORIA: I love that. Okay. And then, what are the challenges that you see? What are those blockers or issues on the horizon that would prevent you from reaching your goals?

+ +

KRISTIAN: I guess one challenge we're facing is that, as I mentioned, we work with insurance companies quite a lot, so some of these big names that I talked about and some more, like, regional smaller insurance companies. But one of the things is that since our care philosophy and the modalities of care we offer, like the sleep and nutrition, the biofeedback wearable, some of these other things that are not typical to mental health care, that are not conventional mental health care, getting reimbursements and getting this kind of a more comprehensive approach, getting it reimbursed by insurance companies is actually quite a challenge.

+ +

Because insurance companies typically reimburse for very select standardized and kind of known services and, like, standard types of care. And it's harder for them to reimburse for something which is, like, novel and very different, even though we've published now 14 clinical studies, including, like, randomized control studies, which is the gold standard in clinical research, and then also, like, large, large, like, thousands of people, single-arm trials, which are, like, more like population trials.

+ +

So, we have, like, a ton of evidence to show that this is very effective, actually, roughly 2 times more effective than standard of mental health care. So, it's very much more effective, and people are maintaining the gains. We've published also our, like, one-year and our two-year data. So, there's a ton of that evidence there, but it's still hard to bring in this kind of innovation into the market. That's one of the challenges that we're working on.

+ +

Then, it's always a challenge to find the best talent, to hire great talent. I've learned over my career to always challenge myself in, like, making sure that we always think through, like, how can we hire the best talent for every role and not let your standards, like, drop. If you're growing fast, you got to hire more people. That is extremely, extremely important. And it happens so easily that when you start growing faster, you got to hire for multiple roles. You actually start, like, lowering your standards because you face pressures on, like, hiring people faster and growing faster.

+ +

VICTORIA: And I wanted to ask you, too, about your background in computer science. And as you're thinking about scaling and expanding globally, what are you thinking about on the infrastructure platform side for the technology that you've built?

+ +

KRISTIAN: What we've built so far is the patient-facing app, so that's the home for the patient to kind of access our services. For our providers, we have a network of providers that we also built them an electronic medical record. So, we kind of, you know, from the start realized that there's not an electronic medical record product out there that would fit our different way of providing care. So, we actually built that in-house by ourselves, so we have that now.

+ +

And then, we also have a kind of a dashboard for our providers where there's, like, traffic lights. So, the system actually, like, sorts people based on different data inputs and places them in order of priority. Like, if someone's reporting suicidality as an example, that's going to be a red flag on a provider's dashboard. These different, like, categories, like, the red flags and then, like, more, like, amber and then green. So, that system is something we're constantly developing and fine-tuning on, like, improving the algorithms of detecting issues.

+ +

And then, on the other hand, helping our providers to focus their time on the right patient at the right time because that's also really critical in care. So, there's plenty of work going on there. We're also working on our SOC 2, which is kind of this security standard in IT. So, we're working on our SOC 2 project currently internally. So, that's a pretty big one for us to mature into that. And yeah, so the platform is kind of evolving. We're kind of building more features.

+ +

We're also building more of these different kinds of modules for people who are struggling with different kinds of issues. So, a concrete example, how can we better support people with post-traumatic stress disorder or people who have, like, panic attacks? And so, there's these kinds of more, like, nuanced areas of mental health where we can double down on by building different modularity and more individualized care pathways for people.

+ +

VICTORIA: That's wonderful. I love that. Thank you for sharing all of it. Is there anything else that you would like to promote today?

+ +

KRISTIAN: Yeah. Well, hey, thanks so much. I really appreciate you having me on this podcast today. What I, again, found useful as a founder, as an operator, is to take good care of yourself. Like, it's really important to also remember not to exhaust your resources constantly, but, like, try to kind of find ways to take care of yourself as a founder, as an entrepreneur, and also kind of, like, nurture yourself. Because, otherwise, I have lots of founder friends, lots of entrepreneur friends, and so many times people are, like, exhausting themselves. And they are kind of, like, running too fast or, like, trying to do this and that more and, you know, just do more and more all the time.

+ +

You know, while that's important, it's important to be running. It's important to be kind of productive as a founder. It's also like a trap, you know. People also fall into a trap if they're trying to do too much at the same time. It's really important to focus on rather fewer things, and it's also very important to take care of yourself. So, self-care, self-compassion, I think, those are important themes that are not too often talked about when it comes to entrepreneurship, but I think that's something I've learned to be important.

+ +

VICTORIA: It sounds like the value that you said as a company also applies for you as an individual, like, having compassion towards yourself and kindness. I think that's a really beautiful way to wrap the episode here unless...do you have any questions for me or thoughtbot?

+ +

KRISTIAN: I've been following you a bit. And just curious, like, what's coming up for you?

+ +

VICTORIA: For me personally, well, I bought a new house, so we're, like, renovating that in California. So, I'm actually switching to, like, maybe trying to do a little bit less travel compared to what I did last year, but going to more local things and getting, like, our San Diego CTO Lunches spun up again and meeting people here who are building really cool things. Lots of great health tech companies in San Diego also.

+ +

What else do we have going on? I'm definitely going to be climbing. I'm going climbing on Saturday. And then probably in LA, I'll go up and do some climbing the next couple of weeks. So, I'm looking forward to having a little bit more balance to life this year [chuckles], the best-laid plans. But yeah, that's what's coming up and, just trying to, like, enjoy where I live, enjoy my family and friends and the companies that I work at, and do a good job. That's it.

+ +

KRISTIAN: Great. Well, hey, appreciate it.

+ +

VICTORIA: Yeah. Wonderful. Well, thank you so much for coming on, and being a part of the show, and sharing your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg, or on Mastodon @thoughtbot.social/vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Kristian Ranta, the founder of Meru Health, shares the company's journey from its inception to its current status as a leading provider of mental health solutions. Kristian reflects on the decision to pivot Meru Health from a wellness-focused to a healthcare-centered company, emphasizing the importance of overcoming fears and listening to intuition in entrepreneurial pursuits. He discusses the challenges and rewards of building a healthcare startup, highlighting the complexities of navigating regulatory frameworks and securing insurance reimbursements.

+ +

Throughout the conversation, Kristian elaborates on Meru Health's unique approach to mental healthcare, which integrates therapy, coaching, and app-based interventions to offer users a holistic and personalized experience. He underscores the significance of community support in mental health treatment and explains how Meru Health's platform fosters connection among individuals facing similar challenges. Kristian also delves into the company's plans for expansion, both within the United States and globally, while addressing ongoing challenges such as securing insurance reimbursements and maintaining high standards for talent acquisition.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Kristian Ranta, CEO and Founder for Meru Health, a new standard for mental health care. Kristian, thank you for joining me.

+ +

KRISTIAN: Thanks, Victoria. Great to be here today. Appreciate it.

+ +

VICTORIA: Wonderful. To break the ice a little bit to get us started in the conversation here, I don't know if you can hear it, but I have a slight cold and congestion going on. And since you're a healthcare startup, I thought I would ask you, what is your favorite comfort food when you're sick?

+ +

KRISTIAN: I don't know whether it's a comfort food or not, but I think kind of what I always consume if I get, like, some flu symptoms or stuff like that it's ginger, honey, and then garlic. I try to combine these things, and it's semi-tasty. Like, it depends on, like, how strong you make it, but it's definitely effective. So, it's been my go-to thing when I get sick.

+ +

VICTORIA: Me too. I like to try to put all those things into a soup of some kind [laughs], some chicken soup. I've learned how to make some sort of version of congee, which is, like, a rice porridge, which I love because you can kind of just sit it on the stove, and it cooks all day. And you could add in all those flavors, and it comes together really nicely.

+ +

For me, I think that's really nice to think about what you like to eat when you're sick because when you're sick, it affects everything else going on in your body. So, I'm sure you have some personal experiences about how your mental health and your physical health are all interrelated.

+ +

KRISTIAN: I mean, totally. Actually, like, I've been a biohacker for quite a while. So, I've been, like, just trying a bunch of things, like, on the physical health side and, like, exercise. And I'm from Finland originally, so a lot of cold exposure, sauna, swimming in the icy water, stuff like that. And then, of course, a lot of, like, different dietary tests that I've done over the years. And I think there's, yeah, I've recognized that there's a huge connection, and it's like the mind and the body are not, like, disconnected. They're in a way the same.

+ +

Personally, also, like, a big piece kind of for me in this regard has been my journey of meditation. So, I started maybe, like, 10, 12 years ago, started meditating every day, and then I've done a bunch of different retreats and kind of dug deeper. Especially through meditation, I've learned very [inaudible 02:15] to experience the connectedness of my thoughts, and my emotions, and feelings, and the body. So, anyway, that's, like, one of my favorite topics, so...

+ +

VICTORIA: So, it sounds like you've always had this interest in the mind-body connection and how to optimize your health. How did that lead you, or what about your background led you to found Meru Health?

+ +

KRISTIAN: I'm from Finland originally. So, I moved to the States in 2018 with Meru Health with my current company. But way back, I studied computer science, did my undergraduate and graduate studies in Finland. And then I kind of, like, ended up working at a healthcare company, a startup company, while I was still studying. And I worked there for a couple of years. And this company was a clinical trial software company, so making it easier for pharmaceutical companies to collect data in patient trials for, like, new drugs, and new developments, and stuff like that.

+ +

I was basically at that company for a couple of years, and that was my first dip into healthcare and technology, the intersection. And I got so excited, and I realized that, hey, this is a place where I can use my excitement for technology and my skills and all that stuff. But I can also then, like, see the immediate improvement in people's lives and how we can help others, and that kind of resonated with me.

+ +

So, I quit after two years and then founded my first own business, which was in diabetes, so one of my co-founders back then is a diabetic. And that's kind of, like, how I went into healthcare. And, for me, then learning the mind and body connection started at the same time. Pretty much I kind of, you know, again, mentioned that I've been meditating for a while. So, I started meditating, and I started just learning about these things and just, like, became super curious to understand the human experience on a more broad basis. So, that's how I started.

+ +

VICTORIA: I love that. And I'm curious if you could talk more about the mind-body connection and also maybe to describe, like, how these issues are treated currently. Being in the United States, it's like, you have a doctor for your body, and then one for your brain, and one for your teeth, and one for your feet. And it's kind of interesting that it's broken up that way. But what's your take on how healthcare treats people now for mental health versus physical health symptoms, and what would be the ideal state?

+ +

KRISTIAN: I think that's one of the fundamental challenges of our time, that there's all these silos in healthcare. Because, again, what we know already today is that, like, your emotions and your thoughts have a huge impact on your physical body, and, you know, you can experience that yourself. Everyone can experience that by doing meditation, and yoga, and things like this. And you can start learning and feeling and seeing that, like, very concretely in your own ways.

+ +

There's also something called biofeedback, which you can do with some of the apps like Aura and, like, Headspace and others. And then you can you do it with some wearables like with Fitbits and others, where through your breathing, you can, like, instantly see, actually, the changes in your heart rate variability, meaning that your nervous system state changes in real-time. So, some of these things were, like, eye-openers for me.

+ +

And I realized that if we, like, keep on focusing on some areas separately, that's going to be challenging because, you know, we're not going to see the full picture. And that's exactly what Western medicine is doing today. On the other hand, I think there's hope because, you know, there's more and more interest and more and more, like, bridging the gap here going on with companies like Meru, but also with, like, many, many other companies and many other providers and practitioners that are working in this domain.

+ +

That's kind of, like, fundamentally the challenge that if we, let's say, we go to a physical doctor, like, a primary care doctor, they never, almost never, address any of the mental health things, although we all know that they have a huge impact on your physical health. Like, there's a ton of research that stress has a big impact on your diabetes, as an example, and your glucose balance if you're a diabetic.

+ +

Like, usually, no doctor, you know, your endocrinologist or diabetes doctor will not talk about the stress or will not really, like, address the mental side of your diabetes. So, I think still, like, disconnected, but there are numerous areas where reconnecting these things better will be beneficial. And that's, again, one of my sort of personal goals in life and my mission to, like, drive this change [inaudible 06:06] in the future.

+ +

VICTORIA: Well, that makes sense to me as someone...I grew up with a parent who had type 1 diabetes their entire life. And what's also, like what you're saying, what's not discussed is if you get a diagnosis like diabetes, that also has an effect on your mental health. And you can stress about it. It can lead to depression. It can kind of make everything a lot worse. Do you also have any personal experience that led you to be really motivated in solving this problem?

+ +

KRISTIAN: One thing that I've openly shared is that I, unfortunately, I lost my oldest brother, Peter, to suicide. You know, the story with him, he was struggling with mental health challenges for a long time. He got access to care in terms of, like, he got medication. And, you know, prescription medications, unfortunately, for him, just made it worse. And he ended up, like, not really, like, benefiting, but just actually, like, struggling more and more.

+ +

And that's actually one of the things, also, what I realized when I founded Meru Health after my, you know, I used to be in diabetes with my first ventures. But now building my third healthcare business, Meru Health; it got started from my realization that the mental health industry is broken. Like, most people are only getting access to psychiatric drugs, as an example, as a sole remedy. Like, you know, they don't have access to a therapist. They don't have access to any kind of support.

+ +

They just see a PCP for 10 minutes, and they get a prescription, and off you go. And then the PCP, you may not see the PCP anymore at all, or maybe in, like, three months, you have, like, a phone call with them or whatever. So, like, that's kind of the experience also with my brother through which I realized this is not adequate. This is crazy. Like, if that's the way we're trying to treat these conditions, it's not going to work.

+ +

And through that, I did a lot of research and a lot of investigations in my early days before founding Meru Health after I had sold my last company. And what I realized, there's roughly, like, two-thirds of people that get access to mental health care, like, either psychiatric medication or maybe some therapy. Two-thirds of people still they don't respond to that care at all. One-third will respond, and only one-sixth will actually reach full remission of symptoms, meaning that they are completely in the clear with their symptoms.

+ +

So, that was kind of a crazy revelation for me that, like, two-thirds, like, are not getting anything out of these treatments. So, that's how I kind of eventually then realized that, okay, we got to rethink this model. Like, this model isn't working. Like, if we are only giving people mainly access to these two remedies and only, like, one-third's getting any benefits, then this is, like, really bad. Like, we got to do something about it.

+ +

And that's again why, you know, I founded Meru Health and Meru Health being about a more holistic approach, not just about, like, talk therapy or psychological aspects, but also sleep, nutrition, biofeedback, learning to regulate your body, your nervous system. There's a community, peer support community, and there are providers. You work with providers as well. But that's on the background why I kind of became super passionate about mental health care and what were some of the insights that I gained where I realized that this system is, like, so broken; we got to do something about it.

+ +

VICTORIA: Well, I have so many questions about Meru Health. But before we get into that, you mentioned you had started two other healthcare companies before this one. So, as a serial entrepreneur, what lessons were the most important that you took from those previous experience going into starting Meru Health?

+ +

KRISTIAN: There's many. So, I mean, like, first of all, when I founded my first company, I was, like, straight out of school, like, pretty young. And, I mean, like, I struggle so bad. Oh, it was such a hard journey. Like, it was a medical device company, glucose monitoring. So, founding a medical device company in Finland back in the day straight out of school was, like, a huge struggle. Eventually, we, you know, we sold the business after, like, seven years or so, but it was, like, a big learning curve for me, a lot of blood, sweat, and tears [laughs] for sure.

+ +

I think few learnings from that first business were it's extremely important to design your culture, and, like, culture is everything. Like, culture eats strategy for breakfast. So, if you don't have a culture that's clearly thought through and designed, it's going to end up being whatever. Like, I mean, like, every organization has a culture, but, like, mostly, the culture has not been intentionally designed.

+ +

And why that's important is that if you just let it grow weeds, whatever, it will grow in various different directions, but it does not necessarily serve its purpose that you may have had in mind. And, again, what I realized is that when you hire people, and you start growing the company, it's extremely important to, like, calibrate the values of, like, why are you doing this? What's important for this culture? Like, how do you want to work? Why do you want to work? And then, like, what are the kind of different rules and rituals and, like, habits of the organization that will make it successful in its mission?

+ +

I never knew that when I founded my first company, and the culture became, whatever, erratic. Like, you know, it was just, like, really hard, also, because of that. And we were not able to recruit the best people or the right kind of people for the right roles because we weren't clear on, like, what are the values? Like, why would someone want to work with us? And how to streamline these things.

+ +

So, I think that's the single biggest learning for me so far on my entrepreneurial journey that you got to very intentionally think about why do you want to build a company, whatever company you're founding. Why do you want to do it? What's going to get you up from bed every day to do your thing? And then, like, how do you want to work? Like, how do you want to work, yourself, accountability? You know, all these things. And what do you expect from others? Like, how do you want to work with other people?

+ +

So, that's kind of, like, what we actually...with my current business, Meru Health, like, we had, like, a value workshop with my co-founders before we founded the company. And we actually spent a lot of time in aligning and thinking about, like, these questions. Like, why do we want to do this? And with Meru's case, all of us founders we have mental health struggles in our family, so we all kind of came together because of that. We wanted to, like, help fix, at least make a dent in the system.

+ +

And then, you know, we kind of spend a lot of time thinking about also, like, how do we want to work with each other? The listeners thinking of founding a company, it's just really, really important to think about, like, also, how do you work? Like, what's the level of accountability with each other? And then, how do you, like, if you hire the first employees, how do you also translate these things to them as well so that there's cohesion, that there's, like, alignment in the team?

+ +

Because if all the arrows, so to speak, if they all point out in different directions, you're not going to create momentum, which you'll need to be able to break through and get to your first milestones as a company. So, I think that's the most important. I could, you know, talk about that for a day or so, but that's, like, the most essential learning for me personally, which I've applied, like, carefully after that.

+ +

VICTORIA: Well, I can imagine that having a clear vision and a set of values that you all know you're working together helps create a good emotional environment for everyone who's at the company, including you who's going to be repeating what the values are, and what the purpose is, and what you're trying to get done as the CEO.

+ +

KRISTIAN: Totally, yeah. Yeah, and, I mean, like, I can also, like, maybe continue on one more point there. One of the values for Meru Health we actually chose compassion and kind of kindness. Why did we do that? Like, many people have asked us like, "Why do you have, like, compassion or kind...like, why is it relevant for your startup?" Well, I think it's extremely relevant because, like, there's not enough kindness in the world. If you're kind of intentionally building kindness into your organization, you know, you're also going to enjoy the journey so much more yourself.

+ +

Because myself and my co-founders, we all figured that, like, we've all been part of other startups and being in, you know, at consulting firms, and we've been grinding like hell at different places. And, you know, it can be exciting. It can be fun. But it also can be pretty, like, challenging sometimes. But we figured that if we are able to instill or kind of, like, inject kindness into this kind of founding spirit of our company, into the culture of our company, Meru Health, you know, it's going to be so much more fun for us and also for all the future employees.

+ +

We know it's going to be hard. Like, building healthcare businesses and healthcare companies is really, really hard. It can take, like, a long time. It's a marathon. It's not a sprint. So, you kind of, like, need to do it for a long time and be committed and hold yourself and the team accountable. But you can do it in a way that's fun, and you can do it in a way that's, like, kind. You can be respectful, and you can be kind towards others. And it's going to be much more of a pleasant journey. So, that's one concrete example of, like, what came out of our value workshop and why we chose kindness or compassion as one of our values.

+ +

VICTORIA: I think that's so important and a really great foundation to build your team on and to really find the best talent that fits what you're trying to do. So, once you founded the company, you had your values workshop. What were some of the early discoveries in your process for founding Meru Health that maybe led to a pivot or a change in the way you were approaching the problem?

+ +

KRISTIAN: I had a pretty good sense of, like, what the problem was. So, as I described, like, I did a lot of research on the problem and, like, really understanding what are the caveats in the current mental health care system? Like, what's not working? So, I had a pretty clear understanding. And, again, like, having built other healthcare businesses before, I kind of, like, had a lot of experience already in general, like, how to build healthcare businesses. So, that was kind of a helpful starting point for me.

+ +

But what happened, actually, in the early days was that we first started from a more preventative perspective. So, actually, our first product was more of kind of a coach-led or a kind of a...it was more, like, a coach-led approach to workplace wellness and prevention of mental health problems. And we kind of built an app-based program where, you know, we'd have a coach work with you through video calls and through chat, and then you'd have, like, different lessons and different activities in the app on a week-by-week basis. And, in many ways, like, that worked pretty well. Like, people were excited. We got engagement, and we sold that to, like, a bunch of enterprise customers. And there was excitement.

+ +

But we realized a couple of things in the early days, which is really important, and this was, like, the first half [inaudible 15:57] when we had founded the company, that a lot of people didn't really have a clear problem when they came to us. Thus, the engagement wasn't there. So, people were kind of, like, just "surfing," quote, unquote. They were coming in and testing and trying it out. But they maybe were stressed and stuff, but they weren't really, like, having a real problem that they wanted to solve so that they would actually spend time with the product and, actually, like, learning skills, changing behavior, things like this. So, that was one big realization for us.

+ +

The other thing we realized was that in our societies, unfortunately, prevention is not yet valued, meaning that there's no money in prevention. There's no...it's really hard to build a business when there's no, like, existing payment pathways or existing reimbursement from insurance companies. Many of these structures are missing in our environment or in our society, meaning that then we kind of realized that it's really hard to scale this kind of a business because it's really hard to make an impact because no one's willing to pay for prevention.

+ +

Even though we had, like, great results already, and there's some good evidence already out there, but still, it's not the same as, like, the healthcare industry definitely exists and is working. And there's a problem, and you need to fix the problem. And whatever sickness or illness it is, there's kind of reasons and investments for fixing this problem.

+ +

So, we pivoted this to be a healthcare company, not a wellness company. We actually applied...pretty much applied the same product idea. We just replaced the coach with a therapist. And then we basically still had the app-based experience for, like, learning, like, homework, things like this. And that's kind of how it, like, structurally changed. So, that was our pivot.

+ +

We've actually only pivoted once, and I'd say, like, fairly minor pivot even because the same product, same idea is still there. It's more just, like, a little bit of a twist on, like, okay, we're not trying to, like, prevent things in a way. We're not trying to sell it as a preventative, but we started selling it as a healthcare intervention.

+ +

And maybe one more thing I think it's going to be essential or maybe interesting for everyone listening. I actually had the idea of building the healthcare intervention from the beginning, but I was too afraid to, actually, like, pursue it. I was too afraid because I felt that, oh, like, if we're going to build a healthcare company, like, it's harder, you know, it's going to be, like, complicated. We have, like, this new approach, the mind and body approach. It's going to be, like, novel. It's, like, hard, you know. So, I had all these fears in my head, which kind of prevented me from, like, really jumping.

+ +

My intuition was already telling me that this is the way to go, but I pushed it aside. And I was kind of like, hey, it's going to be easier to just, like, start with this preventative angle with, like, you know, you don't need clinical providers. You can have, like, coaches. It's going to be easier, you know? So, I was kind of, like, taking the easy path. I was kind of, like, too much listening to my fears, not my intuition.

+ +

And, eventually, we ended up pivoting, and we ended up where I had actually imagined the whole thing being from the beginning. But I wanted to tell this because, at least for me, on my journey, it's been, like, many times that I realized that sometimes these things are, like, if you distill them to the essence, like, what's the essential question here, it's like, is it the choice of fear or choice of love? And is your choice in life in, you know, being a founder, in life in general, is it coming from a place of fear, or is it coming from a place of love?

+ +

That's something which I think was kind of another key learning for me that I was so often making decisions that were based off of a fear. And I was kind of, you know, choosing things because I was afraid of something versus not being, like, excited about something or believing in something.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: Well, one thing I've heard from therapy is that the feeling of fear, the answer is more information. And maybe you could tell me a little bit more and our listeners, like, what makes creating healthcare apps scary? [laughs] What are some of those challenges that are different from what you might expect just building a wellness app that's not having health data involved?

+ +

KRISTIAN: Yeah. Healthcare is, of course, like, regulated, and there's, like, you know, there are certain standards for care depending on whether it's mental health care, diabetes, or cardiology, or other areas. Like, there are certain things, like, you know, you need to have licensed providers who can practice medicine. Or if you have a medical device, you need to get FDA approvals. So, it's, like, a way, way heavier, you know, process. And it, like, has a lot more regulations and rules and different legal implications, data security implications, patient health information, you know, HIPAA, all these other things.

+ +

So, it's just a much, much more regulated space in general, and what that means is that it's slower. It's going to be slower to build. It's going to be slower to validate. The feedback loop is going to be slower. It's going to be more resource-intensive. You're going to need to invest in more resources. It's going to need more, like, expertise. You're going to need, like, regulatory expertise, like medical, clinical, all these other things that you don't need when you're building a wellness company or a product. So, it's just a lot heavier and just, like, way more regulated.

+ +

And the risks are also much more prominent in a way that you, as the CEO or the founder, or you as an operator, may end up being challenged even in court if something goes wrong. So, there's just more risks, and you got to think about, like, insurance. And, like, that's broadly speaking, like, some of the challenges of building a healthcare company versus building a wellness company.

+ +

VICTORIA: So, as a founder of previous healthcare companies, you might have already built those networks to get access to people who can help you with those things. But if you were a new founder and you know you want to start a health tech company, how would you go about building your team to fill in some of those gaps around the areas you need help in?

+ +

KRISTIAN: It's going to be a learning curve. There's, like, no single book or no single place where you can learn all these things. But I'd encourage, like, there's some great materials online for sure in, like, learning, like, what to consider when building a healthcare company. ChatGPT or Google will help you kind of get started on some of the essentials.

+ +

But then I would, like, pretty quickly, I would try to, like, immerse myself in the different circles or communities where there are other healthcare founders, where there are people who've already been building healthcare businesses, where there are maybe advisors or maybe, like, accelerators for startup companies. You want to learn these things from people who've already been doing these things. You don't want to try to, like, learn everything from books. It's going to be too slow, and you don't know what you don't know. So, you don't know how to, like, ask the right questions.

+ +

If you talk to people who've already been doing these things, they will be able to tell you, "Hey, you're not asking this and that question. Like, that's an important thing. Like, you should consider A, B, or C." So, I would say that, like, surround yourself with people who've been building healthcare businesses before and maybe try to get into an accelerator or just, like, find advisors, more, like, experienced people.

+ +

VICTORIA: That's great. It's all about community, which brings me back to the question I had about Meru Health. You mentioned there's a community aspect built into the app, and I was wondering if you could talk a little bit more about that feature and how it plays into the whole model.

+ +

KRISTIAN: Community is important. So, a lot of the people who struggle with mental health problems also very often feel that they are very much alone, so that was the case with my brother. Like, he also felt very much alone with his depression that, like, no one will understand me. Like, I'm the only one who's feeling like this. I'm feeling isolated. But there are so many people who are struggling with the same kind of thing or same kinds of emotions and feelings and symptoms.

+ +

And through our community feature, we have, like, people who are experiencing similar issues going through the Meru, you know, intervention. They can now, like, connect with each other, and they can, like, reflect with each other and see what's going on. It's a moderated kind of a forum type of a thing. So, licensed providers are always moderating and, you know, also being part of the discussions there. So, they're also contributing.

+ +

But it's very much of a place for people to reflect and see that, like, these struggles that I'm going through are not just...it's not just me. Like, there's also other people. You don't need to feel so alone. And you can share with others and see that, hey, there's ways to heal. There's ways to get better. You know, you're not alone struggling with these things.

+ +

VICTORIA: I think that's a really powerful point about making that connection, making that community, and feeling like you're not alone. What other features make the Meru Health app unique in solving this problem?

+ +

KRISTIAN: We are basically a clinic, like, you know, we call it a virtual clinic. So, we have providers. There are, like, licensed therapists. We have doctors, psychiatrists. We have coaches. We have care coordinators. So, these are all real human beings that are actually practicing medicine and supporting our members or our patients.

+ +

And then, we have an app-based program, and the app is basically your home for accessing the Meru services. So, whether you're doing video calls or whether, you know, you can do them through the app. Or you can be chatting with your providers, or you can get access to, like, you know, support from the care coordinators if you need to navigate your insurance benefits or things like this.

+ +

And then, basically, in the app, you're going through different modalities of care. So, one of the unique things about Meru, like, why we built the company, why the company exists, is to kind of make this more holistic or more, like, a lifestyle medicine approach to mental health care, make it available for people. And it includes not only talk therapy or cognitive behavioral therapy, which is the normal typical way of, like, doing talk therapy. It also includes a lot of, like, mindfulness practices, a lot of...sleep kind of is a big topic where we help people understand that, like, there's no mental health without proper sleep. And it's also a physical health issue if you're not sleeping. So, sleep is essential.

+ +

There are many things that you can learn, you know, like some sleep hygiene things, meaning that, like, you shouldn't do, like, blue lights just before bed. You shouldn't do, like, exercise just before bed. You shouldn't eat big meals before bed. So, there's many, many things that you kind of, like, once you learn to know, you'll improve, like, your sleep dramatically. And once you improve your sleep, you improve your health. Like, it's a direct correlation. So, these are things that we teach people as part of one of the modules there.

+ +

Then there's, like, nutrition, as we call it, food and mood. So, there's a huge connection between, like, certain nutrients or diets with, like, mental health. I'll just give you a really quick example. Processed foods are really detrimental to brain health and, mental health, and also physical health. But, like, most doctors, if you're talking to most healthcare professionals, most, like, primary care doctors, if you go to see a primary care doctor about any mental health concerns you may have, like, 99% of them won't tell you anything about your diet. They won't tell you anything about processed foods being very detrimental.

+ +

And, again, so we are kind of including things like these, which are all based on science. Like, there's a ton of research behind these things. And we've also, ourselves, done a lot of research with Stanford, with Harvard, with other universities. But that's kind of another example of, like, some of the essentials that go beyond just the standard talk therapy in helping people more holistically learn skills, learn knowledge to help them get better.

+ +

VICTORIA: That's really cool. So, what does success look like six months from now or five years from now? It's a long process, so...

+ +

KRISTIAN: We're now, like, 130 people at the moment at Meru Health. So, we've kind of, like, come quite far from the early days of, like, just building the product, getting the first customers, doing the first validation, publishing the first research studies, first clinical studies showing that this is effective, so forth. But there's still...it feels like it's day one still because we're going to feel that we're just getting started with, like, you know, we work mainly with insurance companies. So, there's a lot of insurance companies like Cigna, and Aetna, and United, Optum, some of these ones that we work with, some Blue Shield Blue Cross. But there's so much opportunity.

+ +

So, we're now available for, like, 30,000,000 Americans. Obviously, there's way more many Americans we could be available for. So, we're constantly working in making our footprint bigger so that more and more insurance companies would reimburse for Meru's services so that people in different states and different areas can also, like, access these services if they want to.

+ +

And, like, I mean, as I mentioned earlier, building a healthcare company is a marathon. It's not a sprint. So, we've now been building, like, six-plus years, you know, probably, like, another five, six years until we'll be, like, fully, like, reaching all the people in the U.S., hopefully, and so forth. And then, you know, we actually founded the company...initially, we founded from a place of, like, we want to build a global company.

+ +

We want to democratize access to these kinds of, like, new healthcare services also, beyond just being in the U.S. The U.S. is just a really great place to start these kinds of companies, in many ways, the perfect place. But we also are, you know, we're looking at expanding into some European countries in the future and, hopefully, even beyond that. But that's something what's happening now and what we're thinking about for the future.

+ +

VICTORIA: Great. So, it's getting to expand your footprint with who has access to it in the United States and then even looking beyond, globally, and seeing how wide you can reach.

+ +

KRISTIAN: Yep. Exactly.

+ +

VICTORIA: I love that. Okay. And then, what are the challenges that you see? What are those blockers or issues on the horizon that would prevent you from reaching your goals?

+ +

KRISTIAN: I guess one challenge we're facing is that, as I mentioned, we work with insurance companies quite a lot, so some of these big names that I talked about and some more, like, regional smaller insurance companies. But one of the things is that since our care philosophy and the modalities of care we offer, like the sleep and nutrition, the biofeedback wearable, some of these other things that are not typical to mental health care, that are not conventional mental health care, getting reimbursements and getting this kind of a more comprehensive approach, getting it reimbursed by insurance companies is actually quite a challenge.

+ +

Because insurance companies typically reimburse for very select standardized and kind of known services and, like, standard types of care. And it's harder for them to reimburse for something which is, like, novel and very different, even though we've published now 14 clinical studies, including, like, randomized control studies, which is the gold standard in clinical research, and then also, like, large, large, like, thousands of people, single-arm trials, which are, like, more like population trials.

+ +

So, we have, like, a ton of evidence to show that this is very effective, actually, roughly 2 times more effective than standard of mental health care. So, it's very much more effective, and people are maintaining the gains. We've published also our, like, one-year and our two-year data. So, there's a ton of that evidence there, but it's still hard to bring in this kind of innovation into the market. That's one of the challenges that we're working on.

+ +

Then, it's always a challenge to find the best talent, to hire great talent. I've learned over my career to always challenge myself in, like, making sure that we always think through, like, how can we hire the best talent for every role and not let your standards, like, drop. If you're growing fast, you got to hire more people. That is extremely, extremely important. And it happens so easily that when you start growing faster, you got to hire for multiple roles. You actually start, like, lowering your standards because you face pressures on, like, hiring people faster and growing faster.

+ +

VICTORIA: And I wanted to ask you, too, about your background in computer science. And as you're thinking about scaling and expanding globally, what are you thinking about on the infrastructure platform side for the technology that you've built?

+ +

KRISTIAN: What we've built so far is the patient-facing app, so that's the home for the patient to kind of access our services. For our providers, we have a network of providers that we also built them an electronic medical record. So, we kind of, you know, from the start realized that there's not an electronic medical record product out there that would fit our different way of providing care. So, we actually built that in-house by ourselves, so we have that now.

+ +

And then, we also have a kind of a dashboard for our providers where there's, like, traffic lights. So, the system actually, like, sorts people based on different data inputs and places them in order of priority. Like, if someone's reporting suicidality as an example, that's going to be a red flag on a provider's dashboard. These different, like, categories, like, the red flags and then, like, more, like, amber and then green. So, that system is something we're constantly developing and fine-tuning on, like, improving the algorithms of detecting issues.

+ +

And then, on the other hand, helping our providers to focus their time on the right patient at the right time because that's also really critical in care. So, there's plenty of work going on there. We're also working on our SOC 2, which is kind of this security standard in IT. So, we're working on our SOC 2 project currently internally. So, that's a pretty big one for us to mature into that. And yeah, so the platform is kind of evolving. We're kind of building more features.

+ +

We're also building more of these different kinds of modules for people who are struggling with different kinds of issues. So, a concrete example, how can we better support people with post-traumatic stress disorder or people who have, like, panic attacks? And so, there's these kinds of more, like, nuanced areas of mental health where we can double down on by building different modularity and more individualized care pathways for people.

+ +

VICTORIA: That's wonderful. I love that. Thank you for sharing all of it. Is there anything else that you would like to promote today?

+ +

KRISTIAN: Yeah. Well, hey, thanks so much. I really appreciate you having me on this podcast today. What I, again, found useful as a founder, as an operator, is to take good care of yourself. Like, it's really important to also remember not to exhaust your resources constantly, but, like, try to kind of find ways to take care of yourself as a founder, as an entrepreneur, and also kind of, like, nurture yourself. Because, otherwise, I have lots of founder friends, lots of entrepreneur friends, and so many times people are, like, exhausting themselves. And they are kind of, like, running too fast or, like, trying to do this and that more and, you know, just do more and more all the time.

+ +

You know, while that's important, it's important to be running. It's important to be kind of productive as a founder. It's also like a trap, you know. People also fall into a trap if they're trying to do too much at the same time. It's really important to focus on rather fewer things, and it's also very important to take care of yourself. So, self-care, self-compassion, I think, those are important themes that are not too often talked about when it comes to entrepreneurship, but I think that's something I've learned to be important.

+ +

VICTORIA: It sounds like the value that you said as a company also applies for you as an individual, like, having compassion towards yourself and kindness. I think that's a really beautiful way to wrap the episode here unless...do you have any questions for me or thoughtbot?

+ +

KRISTIAN: I've been following you a bit. And just curious, like, what's coming up for you?

+ +

VICTORIA: For me personally, well, I bought a new house, so we're, like, renovating that in California. So, I'm actually switching to, like, maybe trying to do a little bit less travel compared to what I did last year, but going to more local things and getting, like, our San Diego CTO Lunches spun up again and meeting people here who are building really cool things. Lots of great health tech companies in San Diego also.

+ +

What else do we have going on? I'm definitely going to be climbing. I'm going climbing on Saturday. And then probably in LA, I'll go up and do some climbing the next couple of weeks. So, I'm looking forward to having a little bit more balance to life this year [chuckles], the best-laid plans. But yeah, that's what's coming up and, just trying to, like, enjoy where I live, enjoy my family and friends and the companies that I work at, and do a good job. That's it.

+ +

KRISTIAN: Great. Well, hey, appreciate it.

+ +

VICTORIA: Yeah. Wonderful. Well, thank you so much for coming on, and being a part of the show, and sharing your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg, or on Mastodon @thoughtbot.social/vguido.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GxhPQii3 + + ]]> + + Victoria Guido + + + 514: The New Frontier of Fertility Treatment: Technology, Telemedicine, and Hera Fertility + https://podcast.thoughtbot.com/514 + c849d559-026b-481a-a804-265ac7c6cd5c + Thu, 29 Feb 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + In this episode, Will Larry explores Hera Fertility's mission to transform fertility care through telemedicine with Founder and CEO Thiv Paramsothy. Addressing the challenges of traditional fertility treatments, including high costs and long wait times, Hera Fertility offers affordable, accessible, and less invasive alternatives. Thiv's approach leverages technology to enhance patient care and experience, making fertility care more accessible, especially in underserved areas, marking a significant shift towards a more patient-centered fertility treatment landscape. + 32:48 + no + + + Host Will Larry delves into the innovative world of Hera Fertility with its Founder and CEO, Thiv Paramsothy. Hera Fertility emerges as a telemedicine-first provider aimed at revolutionizing the fertility journey for couples. Thiv shares his journey from a tech enthusiast in Toronto to a healthcare entrepreneur driven by a desire to make healthcare more accessible and efficient. His ventures, including Hera Fertility, are born out of personal observations and frustrations with the existing healthcare system, particularly its inefficiencies and the barriers to accessing necessary care. +Thiv noticed a significant gap in the fertility treatment landscape—long waiting times for appointments, excessive costs, and the overall inconvenience and emotional toll of traditional fertility treatments. Hera Fertility aims to address these issues by offering affordable, convenient, and less invasive alternatives to IVF, leveraging telemedicine to provide immediate access to care, diagnostics, and medication. +The episode also highlights Hera Fertility's unique business model and focus on enhancing patient care through technology and personalized support. Thiv explains how the company can offer services at a fraction of the cost of traditional IVF while improving the quality of care and patient experience. By employing a telemedicine-first approach, Hera Fertility democratizes access to fertility care, especially in underserved areas, and introduces a more supportive and patient-centered approach to fertility treatment. +Hera Fertility (https://herafertility.co/) +Follow Hera Fertility on LinkedIn (https://www.linkedin.com/company/herafertility/), X (https://twitter.com/herafertility), Facebook (https://www.facebook.com/herafertillity), or Instagram (https://www.instagram.com/herafertility?igshid=MzRlODBiNWFlZA%3D%3D). +Follow Thiv Paramsothy on LinkedIn (https://www.linkedin.com/in/thivparam/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: + WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry, and with me today is Thiv Paramsothy, Founder and CEO of Hera Fertility. Hera Fertility is a telemedicine-first provider for couples who want to boost their chances of conceiving. They deliver convenient testing, affordable at-home meds, and concierge care, helping patients overcome infertility with better odds and faster turnaround time at only a tenth of the cost of IVF. Thiv, thank you for joining me. +THIV: Thank you for having me. Super excited. +WILL: Yeah, I'm excited to talk about this. And I know this is a huge issue, so I'm excited to hear kind of your heart behind it, why you started the company. But before we dive in that, tell me a little bit about you. +THIV: So, I was born and raised in Toronto, always loved technology and looking at different softwares and all that, but never good enough to code. But went to Waterloo, which is a fancy tech school up in Canada. That's where I really developed my passion for healthcare and tech. So, at that point, it was called, like, something nerdy like health informatics, but now people call it digital health. From there, I kind of learned what was going on in the health system, what could be better about it, and that's kind of where I wanted to focus on in my career. +And then, after college, I was realizing quickly that I wasn't a corporate guy, did it for a bit, and I realized I was very much an entrepreneur. So, I started doing startups after that, and I'm now in my third one. But all my startups really focus on how do we better the healthcare system and how do we make it better for patients? +WILL: I absolutely love that because I have three young kids, and it's absolutely frustrating at times dealing with the healthcare system because, I'm just going, to be honest–sometimes it's who you know or what type of money you have and things like that. And it's frustrating that it feels like, at times, you have to be at this right spot at the right time to get the certain healthcare, so I really appreciate that you are diving into this and trying to solve a huge issue. +THIV: Yeah, I hear you because I see that so often. That's a lot of times what inspires me to go off and do my startup. At that time, like, Hera, exactly that was one of the reasons why we started Hera. +But the way I look at it is that if you look at the healthcare system we have, it's incredible the miracles we could do and the solutions that we have and how we can save people's lives, how we can treat them to live longer. But a lot of times just getting your foot into it and finding the right care is the difficult part. And don't get me started on the barriers and obstacles that are there, from cost to just pure access. So, that's what really motivates me because, in my mind, I'm like, oh, this should be available to the masses, and that way, you know, society grows. Everyone is happier. And I think then we move along and become better. +WILL: Yeah, definitely. Were there friends, family that were going through this that kind of helped you, like, say, "I need to create this company to help the healthcare?" or what was the reason behind starting Hera? +THIV: Yeah. So, with Hera, what happened was I was at that age where all my friends and family were moving to the next chapter of their life and wanting to build a family. A lot of them were coming to me and talking to me and telling me this. And I've become that person where a lot of times, if they need any advice on where to go, what clinic to attend, or what doctor, I try to help there because that's kind of where my mind goes to. I'll know where the right doctor is or which is the best one, even though I'm not a doctor. I've just worked with so many of them. +And so, many of my friends would come to me and share those stories. And I started to hear it more and more. And then, as I was following along in their journey, I realized, like, how hard it is for them to even enter in and get seen by someone; a lot of times, it's like a 6, 12-month wait. Then, on top of that, being able to pay for a lot of these treatments, $20,000, $50,000; if surrogacy, it can go all the way to $100,000. And then, lastly, like, just how inconvenient it is. +One of the things that I was shocked by was, like, how many people had to quit their jobs to go through treatment; 1 in 5 is the latest stat to go through something like IVF. So, all these things are against them, but what really stood out to me was the people that needed help for fertility were probably the most driven and resilient people. And, look, I'm an entrepreneur. I have to be resilient, but I think these people are even more resilient. And so, for me, I was like, there's got to be a better way for people that are going through infertility. That's really what drove me to start a company, quit my job, do the whole shebang there. +WILL: I wanted to paint a picture because I'm kind of tearing up already thinking of some of the people who've gone through that journey because, like you said, it is not an easy journey. Can you paint the picture of kind of what that journey looks like? Because, from my experience, I know it's not like, oh, I need to go get IVF. It starts way before that, many doctors' appointments. It's a whole thing. I want the audience to kind of hear the whole story and paint that picture of what someone who needs IVF or anything in that category what they're going through. +THIV: Where my mind goes to is think of a couple who, like, just got married or been in a long-term relationship, and now they've decided that they want to start having kids. What typically happens is, you know, usually, you just go, yeah, we're going to try, and then that's what they do for that time. And so, they're happy. They're excited because this is, like, a new chapter. And what I picture is as they're trying, they just keep trying. And they're, like, constantly every month or every so often when they're checking, using pregnancy tests, they're just seeing the negative result, negative result, negative result. And so, that just keeps happening over and over again. +After that point is when they go, okay, maybe we need to seek some help. What ends up happening is they go to a doc, and a doc goes, "Hey, just keep trying." That's literally the advice you have to give. That's based on the guidelines. So, no test. Nothing. It's just the fact that it will happen on its own. Don't stress. And so, they keep doing that, and they keep seeing negative results. And that happens for a long time. Most people end up doing is they spend about three to four years on this journey. +And where it really tests you, it tests your, you know, relationship with one another. It really questions yourself. You know, on the woman's side, like, they feel lonely. They feel like when they go to events, they see other people celebrating. They're getting pregnant. They're frustrated as to why. So, it puts emotional toll there. And then, also, for the man, it puts a lot of pressure and makes them question their masculinity. This ends up happening. +From there, they start getting testing done. It just becomes very clinical. They start understanding, okay, they may need to now do some sort of treatment. It becomes like a job, another job for a lot of times. And that's what we kept seeing with people, and I saw for many people as I was helping them on their journey. +It's really a stark contrast to what, I think, most of us have in our head of, like, when you want to build a family where it should be joyful, and loving, and exciting, and easy. It's not. It's a hard path for people where you have to be resilient. So, I hope that that paints a picture. That's what I feel, and that's what motivates me to keep trying to figure out a better way and why we started Hera. +WILL: Yeah. The people I've talked to and been around that's kind of the same story. And you're spot on when you say they start questioning themselves. Like, "Is it me? Did I do something wrong?" And it's heartbreaking because you're like, "No, you did nothing wrong." And so, yes, I am so glad that you shared that and that you're doing something about it. So, can you kind of go into what is Hera doing to help the situation? +THIV: What we are doing we're a telemedicine-first provider. So, what we do is, one, is that through our app, you're able to access the care you need right away. So, that means if you are being told, "Keep trying," but you want to know if there's something wrong, we have testing there. If you want to know, is there things that I could do or take that will improve my chances? We have our supplements and medications that we can provide to you and deliver to you and have you follow a treatment plan. If there are more things that we need to do, like go to a clinic and get IVF, through our app, you're able to do that. We're able to find you and coordinate all that. +But really, we're a companion as you go along in this journey to sift through and provide the solutions that you need. The big thing that we've been really focused on, because we've learned this through our research, and my co-founder ran a fertility clinic for 20 years, is that most people think if you are having trouble, you have to go through something invasive like IVF, or you have to keep trying. But really, what's happening is that only 5% of infertility cases need something like IVF. And what you actually can do is that with a special set of medications taken in a certain way with our plan that spells it out for you, you can be successful. Improve your odds two to three times is what we've been seeing. +So, that's really where we're honing in on: Can we improve your chances of getting pregnant? And that has all these different pieces to it. And so, I think that's what our members really like is that, one, they get educated on what's going on and what they can do and pick options. But then they know that if they're with us and they're following our instructions and taking the medications and everything, it will improve their chances. And so, then, hopefully, they can get pregnant. +WILL: I love that because there's nothing more frustrating than knowing your body and knowing, hey, something's wrong, and someone's telling you, "Oh, just keep trying, like, just keep doing it." So, I love that you're stepping in and educating them because I feel like, especially in our healthcare, a lot of issues that I've seen is because people are not educated on, hey, that's not the right path to be going down, or there's another way to do it, and you just didn't know that. So, I'm glad that you're offering that next step. That sounds amazing. +THIV: Thank you. I think you said it the best right there. It's that next step. People want to do something. The most frustrating that we kept seeing and hearing from people is just being told to do the same thing. Isn't that the definition of insanity? +WILL: Yeah [laughs]. +THIV: For us, we want to provide something so they could take that's safe, reliable, and has shown effectiveness. And along that, they could talk to someone and make sure and be reassured as they go along in this journey, as they have more and more questions, what else can they do, and just really feel empowered on this infertility journey. +WILL: That's awesome. So, how long have you been around? How long have you been a company? +THIV: We're getting up to two years. Our two-year anniversary is coming up. So, we started in April 2022 really testing out what could be the right solution here. You know, as someone who has done a few startups in my past, the first rule I would say is you never fall in love with the first idea, but you go off and test it, and find out, and interview, and keep iterating. And so, we did that for some time and learned so much. I think I've talked to now thousands of people on their fertility journey. +And, you know, as we were going along, we realized we had something special with this telemedicine-first approach. And so, we launched officially in August, I believe it was 2023, our app with the clinicians and everything after beta testing it for some time. And now, we have a group of patients going through our program in about 12 states, and we are expanding as we go along. We'll hopefully get to the 50 states by the end of the year. +WILL: Wow. By the end of the year, that's amazing. +THIV: Yeah. Because we're getting a lot of people wanting it in all parts of the country, but we wanted to really focus on the areas where you won't have that access. So, to your point earlier, you know, a lot of people we've seen so far were telling us, "Hey, I don't have a fertility doctor near me. It takes me five hours to get to one, let's say. And so, I feel hopeless. I feel like I have to do that, and I shouldn't have to." And so, that's where it's this piece of, like, knowing where you're supposed to be going or getting access and not having these barriers in front of you. +And so, for us, we're really focused on those states where access is a big issue for these services. And so, we're in Texas. We're in Kansas. We're launching in New Mexico now, places like that where you won't see too many fertility clinics in a lot of areas. +WILL: That's very interesting, and I'm glad you brought it up because I was going to ask you about that because I know you kind of specialize in the telemedicine portion of it. And I'm from Louisiana, so kind of familiar with Texas, and I used to live in Kansas. And so, those places are not the most...there's parts that are rural, but not the most rural parts, so it's interesting that a fertility doctor can be five hours away. That just blows my mind that like, you know, you're not talking about Montana or anything. You're talking about, like, Texas and Kansas that, you know, five hours is a long time. And the amount of times you have to visit the doctor for that, yeah. +THIV: For fertility, there's a lot of visits. You're going there pretty often. Especially if you're going to do IVF and having to do multiple rounds of it, you could be going there for months. And so, yeah, there's just...the reason behind this, and this is fascinating to me as well, is there are only, like, about 550 clinics that specialize, like, fertility clinics in the U.S. And most of them are actually concentrated in the metropolitan areas, and I think the stat is, like, 50% of those are in 6 states. So, the remaining states really get a few of them. I think New Mexico has, like, two or three fertility clinics. +And so, these clinics have the specialists, and they do as much as they can. But if you're not nearby one, it's really hard to do that consultation, to learn from them, to find out if there is something wrong. And so, now you still are in this gap of like, is there something wrong with me? Because it could be a simple solution, right? And if you overcome it, you can get pregnant. So, that's where we see–can we be hyper-focused on those areas where someone is maybe two hours or more away from the nearest fertility clinic? +And we really want to focus on that access piece because people should get access to this. So, that's why, with our telehealth solution, we have our own clinicians who will be able to assess. For the testing, we'll send you kits to be done at home, or you can go to a nearby lab, and we'll get the results that way. Give you a set of medications or treatments [inaudible 16:11] we'll actually send it to you. +WILL: Oh, wow. +THIV: That's how we're trying to be much more convenient and accessible because that way, you're doing a lot more at home, and these barriers that are currently in front of you are gone. And people are able to get care. +WILL: That's amazing. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration, or click the link in the show notes for this episode. +WILL: Let me ask you this because it kind of sounds like the concierge portion of it, which is amazing. How are you able to do that portion of it but do it cheaper than the streamlined way of doing it? +THIV: So, I like to look at this in two ways; one is the business, right? How do we make sure the economics make sense? And then the other is how do we make it so that the patient experience and care is optimal and satisfactory, right? Or excellent, I should say. So, the way that we thought about it, and I went around and interviewed and observed so many different care models, like, the ways that these different clinics are working, so be it in a hospital, in a traditional clinic. In the earlier days, I would go and do all of that. +You really have to think about is there a better way that we can do it but still have the same success and outcomes? And so, the first thing I noticed is that technology needs to be at the core of all of this. It checks off both of those buckets. The economics and the business will thrive because of that because you can introduce efficiencies, you know, streamline a lot of the operations, do automation. So, that was core to us. So, we were very careful and selected a good vendor to work with on the EMR side and then built on top of that. +And then, from there, technology also helps from the patient side because of all the places, like, I was interviewing, none of the clinics really had, like, an app, or they kind of had something where you would email someone. You would still call, and it was very old school. But what we heard is that patients had so many questions after, before, middle of the night. And so, we were like, how do we make it so that they feel like they can reach out to us, talk to us at any point? And so, that's why we created the app. And you can message us at any point, and then there'll be someone there to help if you need anything or to answer any questions. So, that's on the technology. +Then staff people wise the thought, and other companies have done this, but concierge care, you know, people have thoughts about it, but what's really good is that it's really about, how do I make sure that the patient is getting the best experience and getting the answers that they need? And really, it's about making sure you have the right team there who's available around the clock to answer those questions who are fully trained. +So, we hired a lot of people that had gone and worked in the fertility space. Like, my co-founder knows so much about fertility because she's worked there from the beginning. And so, that's really helpful and is able to answer a lot of these questions that come up immediately. But then we staffed it so they're available around the clock so we can be available for the patient. +And then from there, I think the business model makes sense because we're providing this extra support; patients are willing to pay for it. We've built it so that it's not transactional. And it's more about a long-term engagement so that way people pay us on a membership basis for certain services. +And so, at the end of the day, we've, essentially, and I hope this makes sense, is that we try to not replicate what a typical clinic would do and, which is, like, bill for each service. And we try to think about it: how can we build a long-term relationship with this person who probably will be here for some time and then build pricing and a business model around that? I think that's why it's working. You know what I mean? +WILL: Mmm-hmm. +THIV: And I think that's so important because if we just replicated it, it wouldn't have worked. Things would fall apart. The economics wouldn't make sense. +And then the last thing I'll say is that clinicians-wise, we didn't want to have doctors just there like everyone else thinks, but we actually have nurse practitioners or APPs. And we did this because there was more and more research, and we tested this out for long-term engagement; patients love the nurse practitioners. The doctors are great. They play a role. But I think the quarterback in all of this is that nurse practitioner. So, that's where, I think, I'm super excited. We're hiring a bunch right now. They are really the quarterback. +And we have a good clinical team to make sure everyone feels equipped. And if they have questions, they're able to answer it with docs. But we take cues from these nurse practitioners. So, I think that really helped on the business side and the patient experience side. And that's why we, you know, we have five stars on our satisfaction. People love us. Yeah, it's a long-winded answer to that, but we really thought about how to build this properly. +WILL: That's perfect because...and I'm thankful that you explained it because what I got from what you said was not only are we able to do it cheaper, but we're able to increase the amount and the quality of care that they're getting. Like, 2:00 in the morning, you have a question; you can get it answered. Like, you can't get that anywhere else. Like, sometimes you have a question, and it may take 12 to 24 hours to even get that answer. So, that's amazing that you're staffed around the clock. So, it sounds like, hey, not only are we going to do it cheaper, but we're going to be better at the quality that we give you. So, that sounds amazing. +THIV: Yeah, exactly. And I think that way, what's key here is, currently, in the market for this kind of services, you're paying so much money. A lot of times, insurance doesn't even cover this. So, I've seen people who couldn't get their dream, which, in reality, people's dreams is to have that family, to have that child. And they couldn't do it because of money, you know, maybe it's the Canadian me, but I hate that fact of, like, money stopping you from getting the care you need. +WILL: Same. I'm with you 100%, yeah. +THIV: Right? +WILL: Yeah. +THIV: And so, for us, it's like, if we can make this cheaper, we can make the prices cheaper, too, and people can pay and afford it and get their dream. And so, that's really why we did it this way. It's not so that we make more money. It's so that, you know, we build a sustainable business. But now, patients have an affordable option in front of them. +WILL: Yeah. Can you, and just ballpark it, like, what is the normal cost usually for this versus what Hera provides it for? Can you explain that? +THIV: Normally, people who are going through this would have to spend, ballpark, 15,000 to maybe 25,000. The upper end is, I would say, 50,000, and I'm not including surrogacy in this. But it's a lot of money. People are getting their second mortgage. They're getting, you know, GoFundMes. There's so much that they're doing for this. The worst is when money is blocking you from that dream. So, that amount is typically what we've seen. And that's what my co-founder has told me she would be seeing that from each of her patients and when she was at that clinic. But the way that we've approached it and how much we charge, patients are typically paying us at most around $1,000 to $2,000. +WILL: Wow. +THIV: And so, we're able to effectively do it and at least be an alternative option for them, and that's affordable. And so, I'm always excited when I see patients who come to me, and they're like, "Oh, it was so expensive." or "I thought it was going to be so expensive, and this is so doable for us." That's the difference right there. +WILL: Wow. That's a huge difference. Wow. +THIV: [chuckles] Yeah. And I hope that this changes, like, the conversation. I've seen other markets or in the past where, you know, things were so expensive, and then these new startups were coming in and really making it so that it becomes competitive. And the incumbents have to change their prices, too, and get innovative. +My goal is to bring down that, you know, current average cost of 10,000, 20,000 and so that it becomes much more affordable. And so, that could be done by improved technology, more competitors, all those things that we know about. That way, you know, as more and more people are having these issues with infertility...it used to be 1 in 8. Now it's like 1 in 5 or 1 in 6, even. We need more and more of this kind of care so that people can live out their dream, and let's make it affordable so that they can do that. +WILL: That's amazing. And I really hope you reach that goal because I think especially in healthcare, we need more of that. We need the competitors that are driving the price down instead of driving it up. So, that's amazing that you're creating that. +THIV: Thank you. That's why, you know, we have competitors, but I love it because a couple of years ago, there wasn't as many people in this space. And it keeps growing more and more. As more and more people put their attention to this, I think we'll see really good solutions so that people have options. Obviously, I'm biased. I would love for in 5 years or ten years, you know, if someone is having trouble, they're going to think of Hera. And they're going to download our app and talk to someone right away and know what they can do so they can be closer to that dream of theirs. +WILL: Yeah, definitely. And I'm glad you mentioned the 5 to 10 years. So, I know you mentioned, hopefully, by the end of the year, you're going to be in all 50 states. What's the next step? What's the next goal for Hera? +THIV: Yeah, it's a great, great question. I think about it all the time. I think for us, what we wanted to do is really, like, right now, we are early days, and we're learning from every patient we see. What else can we do? How can we help you? Fifty states is one target or milestone. I think there's a lot more we can do on the product side. For instance, we're going to be launching a male infertility program. That's probably the first of its kind out there where we specialize on the men side of things and bring them into the conversation and have them be actively involved. So, that's a big one. +But we're going to keep doing more and more of solutions and products, so really strengthen the solution that we have here so that you come to us, and we have everything that you need. +I would say next after that is really partnering with more and more of the clinics that are already there. And I say this because we're part of the health system. Yeah, business tells us to be competitive, and that makes sense. But you also are taking care of patients, and you need to partner where maybe you don't have the services for, but someone else does, or for continuity of care. And so, you need to be part of the system. And I think that's key for any kind of healthcare company that's starting up. And so, that's, I would say, level two. I like to think of, like, in games, like, the different levels. +I would say after that, as we grow and become integral to the system and be that solution that people go to when they're in need; we'll evolve to, like, going into the employer and health plan side of things and then be able to say that it's part of your insurance and health plan. And then it's a no-brainer now to sign up with us because someone else is paying for it, which is great. +So, that's kind of how we're evolving, but I want to make sure...and I think something that I've heard in your other episodes, but I'm a big believer of talking to the people that are using your solution and learning from them, and identifying where there may be gaps that you can help address. And so, as we evolve, we're going to keep talking to them. I always give out my cell phone number and tell any of our user who wants I'm like, "If there's something we could do better, let me know. Tell me directly." And so, I want to make sure that's clear that we'll see what our users tell us, what we should be focusing on. +WILL: Wow. I love that. That's amazing. Let me ask you this in kind of closing it out is, like, so that's kind of five years. Do you have anything that you want to promote, like, what you're doing right now? +THIV: Yeah. No, I think the big thing is we are constantly working on our product. What I would say is if there is anyone who is either fertility curious, or going through their own journey, or who has gone through this in the past, please reach out to me or, use our solution, talk to our clinician. I think it's so empowering once you meet with our clinician to understand what your options are and what you should do. +If you're not in one of our states, then let us know, and we'll put it on the list and bump it up. So yeah, like, please come to our website, check it out, join us, try it out as well. We're all about trying to help people get to that goal of theirs, their dream. +WILL: I love it. And we'll include it in the show notes, but in case they don't have the show notes in front of them, tell them how to get to your website, how to contact you, how to get the information. +THIV: Yeah, for sure. So, you can go on our website. It's herafertility.co. And on there, you can sign up for our services and sign up for our app. But if you have any questions before signing up, you can schedule time to talk to one of our fertility advisors, and then, yeah, you can always reach out to me. I'm on LinkedIn under Thiv. And Twitter I check every so often or X. And you can email me at any point at thiv@herafertility.co. +WILL: Awesome. Well, it was great chatting with you, and I've learned so much. Keep doing what you're doing. And I hope that you're successful because you're doing some amazing things. +THIV: I really appreciate that. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Host Will Larry delves into the innovative world of Hera Fertility with its Founder and CEO, Thiv Paramsothy. Hera Fertility emerges as a telemedicine-first provider aimed at revolutionizing the fertility journey for couples. Thiv shares his journey from a tech enthusiast in Toronto to a healthcare entrepreneur driven by a desire to make healthcare more accessible and efficient. His ventures, including Hera Fertility, are born out of personal observations and frustrations with the existing healthcare system, particularly its inefficiencies and the barriers to accessing necessary care.

+ +

Thiv noticed a significant gap in the fertility treatment landscape—long waiting times for appointments, excessive costs, and the overall inconvenience and emotional toll of traditional fertility treatments. Hera Fertility aims to address these issues by offering affordable, convenient, and less invasive alternatives to IVF, leveraging telemedicine to provide immediate access to care, diagnostics, and medication.

+ +

The episode also highlights Hera Fertility's unique business model and focus on enhancing patient care through technology and personalized support. Thiv explains how the company can offer services at a fraction of the cost of traditional IVF while improving the quality of care and patient experience. By employing a telemedicine-first approach, Hera Fertility democratizes access to fertility care, especially in underserved areas, and introduces a more supportive and patient-centered approach to fertility treatment.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry, and with me today is Thiv Paramsothy, Founder and CEO of Hera Fertility. Hera Fertility is a telemedicine-first provider for couples who want to boost their chances of conceiving. They deliver convenient testing, affordable at-home meds, and concierge care, helping patients overcome infertility with better odds and faster turnaround time at only a tenth of the cost of IVF. Thiv, thank you for joining me.

+ +

THIV: Thank you for having me. Super excited.

+ +

WILL: Yeah, I'm excited to talk about this. And I know this is a huge issue, so I'm excited to hear kind of your heart behind it, why you started the company. But before we dive in that, tell me a little bit about you.

+ +

THIV: So, I was born and raised in Toronto, always loved technology and looking at different softwares and all that, but never good enough to code. But went to Waterloo, which is a fancy tech school up in Canada. That's where I really developed my passion for healthcare and tech. So, at that point, it was called, like, something nerdy like health informatics, but now people call it digital health. From there, I kind of learned what was going on in the health system, what could be better about it, and that's kind of where I wanted to focus on in my career.

+ +

And then, after college, I was realizing quickly that I wasn't a corporate guy, did it for a bit, and I realized I was very much an entrepreneur. So, I started doing startups after that, and I'm now in my third one. But all my startups really focus on how do we better the healthcare system and how do we make it better for patients?

+ +

WILL: I absolutely love that because I have three young kids, and it's absolutely frustrating at times dealing with the healthcare system because, I'm just going, to be honest–sometimes it's who you know or what type of money you have and things like that. And it's frustrating that it feels like, at times, you have to be at this right spot at the right time to get the certain healthcare, so I really appreciate that you are diving into this and trying to solve a huge issue.

+ +

THIV: Yeah, I hear you because I see that so often. That's a lot of times what inspires me to go off and do my startup. At that time, like, Hera, exactly that was one of the reasons why we started Hera.

+ +

But the way I look at it is that if you look at the healthcare system we have, it's incredible the miracles we could do and the solutions that we have and how we can save people's lives, how we can treat them to live longer. But a lot of times just getting your foot into it and finding the right care is the difficult part. And don't get me started on the barriers and obstacles that are there, from cost to just pure access. So, that's what really motivates me because, in my mind, I'm like, oh, this should be available to the masses, and that way, you know, society grows. Everyone is happier. And I think then we move along and become better.

+ +

WILL: Yeah, definitely. Were there friends, family that were going through this that kind of helped you, like, say, "I need to create this company to help the healthcare?" or what was the reason behind starting Hera?

+ +

THIV: Yeah. So, with Hera, what happened was I was at that age where all my friends and family were moving to the next chapter of their life and wanting to build a family. A lot of them were coming to me and talking to me and telling me this. And I've become that person where a lot of times, if they need any advice on where to go, what clinic to attend, or what doctor, I try to help there because that's kind of where my mind goes to. I'll know where the right doctor is or which is the best one, even though I'm not a doctor. I've just worked with so many of them.

+ +

And so, many of my friends would come to me and share those stories. And I started to hear it more and more. And then, as I was following along in their journey, I realized, like, how hard it is for them to even enter in and get seen by someone; a lot of times, it's like a 6, 12-month wait. Then, on top of that, being able to pay for a lot of these treatments, $20,000, $50,000; if surrogacy, it can go all the way to $100,000. And then, lastly, like, just how inconvenient it is.

+ +

One of the things that I was shocked by was, like, how many people had to quit their jobs to go through treatment; 1 in 5 is the latest stat to go through something like IVF. So, all these things are against them, but what really stood out to me was the people that needed help for fertility were probably the most driven and resilient people. And, look, I'm an entrepreneur. I have to be resilient, but I think these people are even more resilient. And so, for me, I was like, there's got to be a better way for people that are going through infertility. That's really what drove me to start a company, quit my job, do the whole shebang there.

+ +

WILL: I wanted to paint a picture because I'm kind of tearing up already thinking of some of the people who've gone through that journey because, like you said, it is not an easy journey. Can you paint the picture of kind of what that journey looks like? Because, from my experience, I know it's not like, oh, I need to go get IVF. It starts way before that, many doctors' appointments. It's a whole thing. I want the audience to kind of hear the whole story and paint that picture of what someone who needs IVF or anything in that category what they're going through.

+ +

THIV: Where my mind goes to is think of a couple who, like, just got married or been in a long-term relationship, and now they've decided that they want to start having kids. What typically happens is, you know, usually, you just go, yeah, we're going to try, and then that's what they do for that time. And so, they're happy. They're excited because this is, like, a new chapter. And what I picture is as they're trying, they just keep trying. And they're, like, constantly every month or every so often when they're checking, using pregnancy tests, they're just seeing the negative result, negative result, negative result. And so, that just keeps happening over and over again.

+ +

After that point is when they go, okay, maybe we need to seek some help. What ends up happening is they go to a doc, and a doc goes, "Hey, just keep trying." That's literally the advice you have to give. That's based on the guidelines. So, no test. Nothing. It's just the fact that it will happen on its own. Don't stress. And so, they keep doing that, and they keep seeing negative results. And that happens for a long time. Most people end up doing is they spend about three to four years on this journey.

+ +

And where it really tests you, it tests your, you know, relationship with one another. It really questions yourself. You know, on the woman's side, like, they feel lonely. They feel like when they go to events, they see other people celebrating. They're getting pregnant. They're frustrated as to why. So, it puts emotional toll there. And then, also, for the man, it puts a lot of pressure and makes them question their masculinity. This ends up happening.

+ +

From there, they start getting testing done. It just becomes very clinical. They start understanding, okay, they may need to now do some sort of treatment. It becomes like a job, another job for a lot of times. And that's what we kept seeing with people, and I saw for many people as I was helping them on their journey.

+ +

It's really a stark contrast to what, I think, most of us have in our head of, like, when you want to build a family where it should be joyful, and loving, and exciting, and easy. It's not. It's a hard path for people where you have to be resilient. So, I hope that that paints a picture. That's what I feel, and that's what motivates me to keep trying to figure out a better way and why we started Hera.

+ +

WILL: Yeah. The people I've talked to and been around that's kind of the same story. And you're spot on when you say they start questioning themselves. Like, "Is it me? Did I do something wrong?" And it's heartbreaking because you're like, "No, you did nothing wrong." And so, yes, I am so glad that you shared that and that you're doing something about it. So, can you kind of go into what is Hera doing to help the situation?

+ +

THIV: What we are doing we're a telemedicine-first provider. So, what we do is, one, is that through our app, you're able to access the care you need right away. So, that means if you are being told, "Keep trying," but you want to know if there's something wrong, we have testing there. If you want to know, is there things that I could do or take that will improve my chances? We have our supplements and medications that we can provide to you and deliver to you and have you follow a treatment plan. If there are more things that we need to do, like go to a clinic and get IVF, through our app, you're able to do that. We're able to find you and coordinate all that.

+ +

But really, we're a companion as you go along in this journey to sift through and provide the solutions that you need. The big thing that we've been really focused on, because we've learned this through our research, and my co-founder ran a fertility clinic for 20 years, is that most people think if you are having trouble, you have to go through something invasive like IVF, or you have to keep trying. But really, what's happening is that only 5% of infertility cases need something like IVF. And what you actually can do is that with a special set of medications taken in a certain way with our plan that spells it out for you, you can be successful. Improve your odds two to three times is what we've been seeing.

+ +

So, that's really where we're honing in on: Can we improve your chances of getting pregnant? And that has all these different pieces to it. And so, I think that's what our members really like is that, one, they get educated on what's going on and what they can do and pick options. But then they know that if they're with us and they're following our instructions and taking the medications and everything, it will improve their chances. And so, then, hopefully, they can get pregnant.

+ +

WILL: I love that because there's nothing more frustrating than knowing your body and knowing, hey, something's wrong, and someone's telling you, "Oh, just keep trying, like, just keep doing it." So, I love that you're stepping in and educating them because I feel like, especially in our healthcare, a lot of issues that I've seen is because people are not educated on, hey, that's not the right path to be going down, or there's another way to do it, and you just didn't know that. So, I'm glad that you're offering that next step. That sounds amazing.

+ +

THIV: Thank you. I think you said it the best right there. It's that next step. People want to do something. The most frustrating that we kept seeing and hearing from people is just being told to do the same thing. Isn't that the definition of insanity?

+ +

WILL: Yeah [laughs].

+ +

THIV: For us, we want to provide something so they could take that's safe, reliable, and has shown effectiveness. And along that, they could talk to someone and make sure and be reassured as they go along in this journey, as they have more and more questions, what else can they do, and just really feel empowered on this infertility journey.

+ +

WILL: That's awesome. So, how long have you been around? How long have you been a company?

+ +

THIV: We're getting up to two years. Our two-year anniversary is coming up. So, we started in April 2022 really testing out what could be the right solution here. You know, as someone who has done a few startups in my past, the first rule I would say is you never fall in love with the first idea, but you go off and test it, and find out, and interview, and keep iterating. And so, we did that for some time and learned so much. I think I've talked to now thousands of people on their fertility journey.

+ +

And, you know, as we were going along, we realized we had something special with this telemedicine-first approach. And so, we launched officially in August, I believe it was 2023, our app with the clinicians and everything after beta testing it for some time. And now, we have a group of patients going through our program in about 12 states, and we are expanding as we go along. We'll hopefully get to the 50 states by the end of the year.

+ +

WILL: Wow. By the end of the year, that's amazing.

+ +

THIV: Yeah. Because we're getting a lot of people wanting it in all parts of the country, but we wanted to really focus on the areas where you won't have that access. So, to your point earlier, you know, a lot of people we've seen so far were telling us, "Hey, I don't have a fertility doctor near me. It takes me five hours to get to one, let's say. And so, I feel hopeless. I feel like I have to do that, and I shouldn't have to." And so, that's where it's this piece of, like, knowing where you're supposed to be going or getting access and not having these barriers in front of you.

+ +

And so, for us, we're really focused on those states where access is a big issue for these services. And so, we're in Texas. We're in Kansas. We're launching in New Mexico now, places like that where you won't see too many fertility clinics in a lot of areas.

+ +

WILL: That's very interesting, and I'm glad you brought it up because I was going to ask you about that because I know you kind of specialize in the telemedicine portion of it. And I'm from Louisiana, so kind of familiar with Texas, and I used to live in Kansas. And so, those places are not the most...there's parts that are rural, but not the most rural parts, so it's interesting that a fertility doctor can be five hours away. That just blows my mind that like, you know, you're not talking about Montana or anything. You're talking about, like, Texas and Kansas that, you know, five hours is a long time. And the amount of times you have to visit the doctor for that, yeah.

+ +

THIV: For fertility, there's a lot of visits. You're going there pretty often. Especially if you're going to do IVF and having to do multiple rounds of it, you could be going there for months. And so, yeah, there's just...the reason behind this, and this is fascinating to me as well, is there are only, like, about 550 clinics that specialize, like, fertility clinics in the U.S. And most of them are actually concentrated in the metropolitan areas, and I think the stat is, like, 50% of those are in 6 states. So, the remaining states really get a few of them. I think New Mexico has, like, two or three fertility clinics.

+ +

And so, these clinics have the specialists, and they do as much as they can. But if you're not nearby one, it's really hard to do that consultation, to learn from them, to find out if there is something wrong. And so, now you still are in this gap of like, is there something wrong with me? Because it could be a simple solution, right? And if you overcome it, you can get pregnant. So, that's where we see–can we be hyper-focused on those areas where someone is maybe two hours or more away from the nearest fertility clinic?

+ +

And we really want to focus on that access piece because people should get access to this. So, that's why, with our telehealth solution, we have our own clinicians who will be able to assess. For the testing, we'll send you kits to be done at home, or you can go to a nearby lab, and we'll get the results that way. Give you a set of medications or treatments [inaudible 16:11] we'll actually send it to you.

+ +

WILL: Oh, wow.

+ +

THIV: That's how we're trying to be much more convenient and accessible because that way, you're doing a lot more at home, and these barriers that are currently in front of you are gone. And people are able to get care.

+ +

WILL: That's amazing.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration, or click the link in the show notes for this episode.

+ +

WILL: Let me ask you this because it kind of sounds like the concierge portion of it, which is amazing. How are you able to do that portion of it but do it cheaper than the streamlined way of doing it?

+ +

THIV: So, I like to look at this in two ways; one is the business, right? How do we make sure the economics make sense? And then the other is how do we make it so that the patient experience and care is optimal and satisfactory, right? Or excellent, I should say. So, the way that we thought about it, and I went around and interviewed and observed so many different care models, like, the ways that these different clinics are working, so be it in a hospital, in a traditional clinic. In the earlier days, I would go and do all of that.

+ +

You really have to think about is there a better way that we can do it but still have the same success and outcomes? And so, the first thing I noticed is that technology needs to be at the core of all of this. It checks off both of those buckets. The economics and the business will thrive because of that because you can introduce efficiencies, you know, streamline a lot of the operations, do automation. So, that was core to us. So, we were very careful and selected a good vendor to work with on the EMR side and then built on top of that.

+ +

And then, from there, technology also helps from the patient side because of all the places, like, I was interviewing, none of the clinics really had, like, an app, or they kind of had something where you would email someone. You would still call, and it was very old school. But what we heard is that patients had so many questions after, before, middle of the night. And so, we were like, how do we make it so that they feel like they can reach out to us, talk to us at any point? And so, that's why we created the app. And you can message us at any point, and then there'll be someone there to help if you need anything or to answer any questions. So, that's on the technology.

+ +

Then staff people wise the thought, and other companies have done this, but concierge care, you know, people have thoughts about it, but what's really good is that it's really about, how do I make sure that the patient is getting the best experience and getting the answers that they need? And really, it's about making sure you have the right team there who's available around the clock to answer those questions who are fully trained.

+ +

So, we hired a lot of people that had gone and worked in the fertility space. Like, my co-founder knows so much about fertility because she's worked there from the beginning. And so, that's really helpful and is able to answer a lot of these questions that come up immediately. But then we staffed it so they're available around the clock so we can be available for the patient.

+ +

And then from there, I think the business model makes sense because we're providing this extra support; patients are willing to pay for it. We've built it so that it's not transactional. And it's more about a long-term engagement so that way people pay us on a membership basis for certain services.

+ +

And so, at the end of the day, we've, essentially, and I hope this makes sense, is that we try to not replicate what a typical clinic would do and, which is, like, bill for each service. And we try to think about it: how can we build a long-term relationship with this person who probably will be here for some time and then build pricing and a business model around that? I think that's why it's working. You know what I mean?

+ +

WILL: Mmm-hmm.

+ +

THIV: And I think that's so important because if we just replicated it, it wouldn't have worked. Things would fall apart. The economics wouldn't make sense.

+ +

And then the last thing I'll say is that clinicians-wise, we didn't want to have doctors just there like everyone else thinks, but we actually have nurse practitioners or APPs. And we did this because there was more and more research, and we tested this out for long-term engagement; patients love the nurse practitioners. The doctors are great. They play a role. But I think the quarterback in all of this is that nurse practitioner. So, that's where, I think, I'm super excited. We're hiring a bunch right now. They are really the quarterback.

+ +

And we have a good clinical team to make sure everyone feels equipped. And if they have questions, they're able to answer it with docs. But we take cues from these nurse practitioners. So, I think that really helped on the business side and the patient experience side. And that's why we, you know, we have five stars on our satisfaction. People love us. Yeah, it's a long-winded answer to that, but we really thought about how to build this properly.

+ +

WILL: That's perfect because...and I'm thankful that you explained it because what I got from what you said was not only are we able to do it cheaper, but we're able to increase the amount and the quality of care that they're getting. Like, 2:00 in the morning, you have a question; you can get it answered. Like, you can't get that anywhere else. Like, sometimes you have a question, and it may take 12 to 24 hours to even get that answer. So, that's amazing that you're staffed around the clock. So, it sounds like, hey, not only are we going to do it cheaper, but we're going to be better at the quality that we give you. So, that sounds amazing.

+ +

THIV: Yeah, exactly. And I think that way, what's key here is, currently, in the market for this kind of services, you're paying so much money. A lot of times, insurance doesn't even cover this. So, I've seen people who couldn't get their dream, which, in reality, people's dreams is to have that family, to have that child. And they couldn't do it because of money, you know, maybe it's the Canadian me, but I hate that fact of, like, money stopping you from getting the care you need.

+ +

WILL: Same. I'm with you 100%, yeah.

+ +

THIV: Right?

+ +

WILL: Yeah.

+ +

THIV: And so, for us, it's like, if we can make this cheaper, we can make the prices cheaper, too, and people can pay and afford it and get their dream. And so, that's really why we did it this way. It's not so that we make more money. It's so that, you know, we build a sustainable business. But now, patients have an affordable option in front of them.

+ +

WILL: Yeah. Can you, and just ballpark it, like, what is the normal cost usually for this versus what Hera provides it for? Can you explain that?

+ +

THIV: Normally, people who are going through this would have to spend, ballpark, 15,000 to maybe 25,000. The upper end is, I would say, 50,000, and I'm not including surrogacy in this. But it's a lot of money. People are getting their second mortgage. They're getting, you know, GoFundMes. There's so much that they're doing for this. The worst is when money is blocking you from that dream. So, that amount is typically what we've seen. And that's what my co-founder has told me she would be seeing that from each of her patients and when she was at that clinic. But the way that we've approached it and how much we charge, patients are typically paying us at most around $1,000 to $2,000.

+ +

WILL: Wow.

+ +

THIV: And so, we're able to effectively do it and at least be an alternative option for them, and that's affordable. And so, I'm always excited when I see patients who come to me, and they're like, "Oh, it was so expensive." or "I thought it was going to be so expensive, and this is so doable for us." That's the difference right there.

+ +

WILL: Wow. That's a huge difference. Wow.

+ +

THIV: [chuckles] Yeah. And I hope that this changes, like, the conversation. I've seen other markets or in the past where, you know, things were so expensive, and then these new startups were coming in and really making it so that it becomes competitive. And the incumbents have to change their prices, too, and get innovative.

+ +

My goal is to bring down that, you know, current average cost of 10,000, 20,000 and so that it becomes much more affordable. And so, that could be done by improved technology, more competitors, all those things that we know about. That way, you know, as more and more people are having these issues with infertility...it used to be 1 in 8. Now it's like 1 in 5 or 1 in 6, even. We need more and more of this kind of care so that people can live out their dream, and let's make it affordable so that they can do that.

+ +

WILL: That's amazing. And I really hope you reach that goal because I think especially in healthcare, we need more of that. We need the competitors that are driving the price down instead of driving it up. So, that's amazing that you're creating that.

+ +

THIV: Thank you. That's why, you know, we have competitors, but I love it because a couple of years ago, there wasn't as many people in this space. And it keeps growing more and more. As more and more people put their attention to this, I think we'll see really good solutions so that people have options. Obviously, I'm biased. I would love for in 5 years or ten years, you know, if someone is having trouble, they're going to think of Hera. And they're going to download our app and talk to someone right away and know what they can do so they can be closer to that dream of theirs.

+ +

WILL: Yeah, definitely. And I'm glad you mentioned the 5 to 10 years. So, I know you mentioned, hopefully, by the end of the year, you're going to be in all 50 states. What's the next step? What's the next goal for Hera?

+ +

THIV: Yeah, it's a great, great question. I think about it all the time. I think for us, what we wanted to do is really, like, right now, we are early days, and we're learning from every patient we see. What else can we do? How can we help you? Fifty states is one target or milestone. I think there's a lot more we can do on the product side. For instance, we're going to be launching a male infertility program. That's probably the first of its kind out there where we specialize on the men side of things and bring them into the conversation and have them be actively involved. So, that's a big one.

+ +

But we're going to keep doing more and more of solutions and products, so really strengthen the solution that we have here so that you come to us, and we have everything that you need.

+ +

I would say next after that is really partnering with more and more of the clinics that are already there. And I say this because we're part of the health system. Yeah, business tells us to be competitive, and that makes sense. But you also are taking care of patients, and you need to partner where maybe you don't have the services for, but someone else does, or for continuity of care. And so, you need to be part of the system. And I think that's key for any kind of healthcare company that's starting up. And so, that's, I would say, level two. I like to think of, like, in games, like, the different levels.

+ +

I would say after that, as we grow and become integral to the system and be that solution that people go to when they're in need; we'll evolve to, like, going into the employer and health plan side of things and then be able to say that it's part of your insurance and health plan. And then it's a no-brainer now to sign up with us because someone else is paying for it, which is great.

+ +

So, that's kind of how we're evolving, but I want to make sure...and I think something that I've heard in your other episodes, but I'm a big believer of talking to the people that are using your solution and learning from them, and identifying where there may be gaps that you can help address. And so, as we evolve, we're going to keep talking to them. I always give out my cell phone number and tell any of our user who wants I'm like, "If there's something we could do better, let me know. Tell me directly." And so, I want to make sure that's clear that we'll see what our users tell us, what we should be focusing on.

+ +

WILL: Wow. I love that. That's amazing. Let me ask you this in kind of closing it out is, like, so that's kind of five years. Do you have anything that you want to promote, like, what you're doing right now?

+ +

THIV: Yeah. No, I think the big thing is we are constantly working on our product. What I would say is if there is anyone who is either fertility curious, or going through their own journey, or who has gone through this in the past, please reach out to me or, use our solution, talk to our clinician. I think it's so empowering once you meet with our clinician to understand what your options are and what you should do.

+ +

If you're not in one of our states, then let us know, and we'll put it on the list and bump it up. So yeah, like, please come to our website, check it out, join us, try it out as well. We're all about trying to help people get to that goal of theirs, their dream.

+ +

WILL: I love it. And we'll include it in the show notes, but in case they don't have the show notes in front of them, tell them how to get to your website, how to contact you, how to get the information.

+ +

THIV: Yeah, for sure. So, you can go on our website. It's herafertility.co. And on there, you can sign up for our services and sign up for our app. But if you have any questions before signing up, you can schedule time to talk to one of our fertility advisors, and then, yeah, you can always reach out to me. I'm on LinkedIn under Thiv. And Twitter I check every so often or X. And you can email me at any point at thiv@herafertility.co.

+ +

WILL: Awesome. Well, it was great chatting with you, and I've learned so much. Keep doing what you're doing. And I hope that you're successful because you're doing some amazing things.

+ +

THIV: I really appreciate that.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Will Larry delves into the innovative world of Hera Fertility with its Founder and CEO, Thiv Paramsothy. Hera Fertility emerges as a telemedicine-first provider aimed at revolutionizing the fertility journey for couples. Thiv shares his journey from a tech enthusiast in Toronto to a healthcare entrepreneur driven by a desire to make healthcare more accessible and efficient. His ventures, including Hera Fertility, are born out of personal observations and frustrations with the existing healthcare system, particularly its inefficiencies and the barriers to accessing necessary care.

+ +

Thiv noticed a significant gap in the fertility treatment landscape—long waiting times for appointments, excessive costs, and the overall inconvenience and emotional toll of traditional fertility treatments. Hera Fertility aims to address these issues by offering affordable, convenient, and less invasive alternatives to IVF, leveraging telemedicine to provide immediate access to care, diagnostics, and medication.

+ +

The episode also highlights Hera Fertility's unique business model and focus on enhancing patient care through technology and personalized support. Thiv explains how the company can offer services at a fraction of the cost of traditional IVF while improving the quality of care and patient experience. By employing a telemedicine-first approach, Hera Fertility democratizes access to fertility care, especially in underserved areas, and introduces a more supportive and patient-centered approach to fertility treatment.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry, and with me today is Thiv Paramsothy, Founder and CEO of Hera Fertility. Hera Fertility is a telemedicine-first provider for couples who want to boost their chances of conceiving. They deliver convenient testing, affordable at-home meds, and concierge care, helping patients overcome infertility with better odds and faster turnaround time at only a tenth of the cost of IVF. Thiv, thank you for joining me.

+ +

THIV: Thank you for having me. Super excited.

+ +

WILL: Yeah, I'm excited to talk about this. And I know this is a huge issue, so I'm excited to hear kind of your heart behind it, why you started the company. But before we dive in that, tell me a little bit about you.

+ +

THIV: So, I was born and raised in Toronto, always loved technology and looking at different softwares and all that, but never good enough to code. But went to Waterloo, which is a fancy tech school up in Canada. That's where I really developed my passion for healthcare and tech. So, at that point, it was called, like, something nerdy like health informatics, but now people call it digital health. From there, I kind of learned what was going on in the health system, what could be better about it, and that's kind of where I wanted to focus on in my career.

+ +

And then, after college, I was realizing quickly that I wasn't a corporate guy, did it for a bit, and I realized I was very much an entrepreneur. So, I started doing startups after that, and I'm now in my third one. But all my startups really focus on how do we better the healthcare system and how do we make it better for patients?

+ +

WILL: I absolutely love that because I have three young kids, and it's absolutely frustrating at times dealing with the healthcare system because, I'm just going, to be honest–sometimes it's who you know or what type of money you have and things like that. And it's frustrating that it feels like, at times, you have to be at this right spot at the right time to get the certain healthcare, so I really appreciate that you are diving into this and trying to solve a huge issue.

+ +

THIV: Yeah, I hear you because I see that so often. That's a lot of times what inspires me to go off and do my startup. At that time, like, Hera, exactly that was one of the reasons why we started Hera.

+ +

But the way I look at it is that if you look at the healthcare system we have, it's incredible the miracles we could do and the solutions that we have and how we can save people's lives, how we can treat them to live longer. But a lot of times just getting your foot into it and finding the right care is the difficult part. And don't get me started on the barriers and obstacles that are there, from cost to just pure access. So, that's what really motivates me because, in my mind, I'm like, oh, this should be available to the masses, and that way, you know, society grows. Everyone is happier. And I think then we move along and become better.

+ +

WILL: Yeah, definitely. Were there friends, family that were going through this that kind of helped you, like, say, "I need to create this company to help the healthcare?" or what was the reason behind starting Hera?

+ +

THIV: Yeah. So, with Hera, what happened was I was at that age where all my friends and family were moving to the next chapter of their life and wanting to build a family. A lot of them were coming to me and talking to me and telling me this. And I've become that person where a lot of times, if they need any advice on where to go, what clinic to attend, or what doctor, I try to help there because that's kind of where my mind goes to. I'll know where the right doctor is or which is the best one, even though I'm not a doctor. I've just worked with so many of them.

+ +

And so, many of my friends would come to me and share those stories. And I started to hear it more and more. And then, as I was following along in their journey, I realized, like, how hard it is for them to even enter in and get seen by someone; a lot of times, it's like a 6, 12-month wait. Then, on top of that, being able to pay for a lot of these treatments, $20,000, $50,000; if surrogacy, it can go all the way to $100,000. And then, lastly, like, just how inconvenient it is.

+ +

One of the things that I was shocked by was, like, how many people had to quit their jobs to go through treatment; 1 in 5 is the latest stat to go through something like IVF. So, all these things are against them, but what really stood out to me was the people that needed help for fertility were probably the most driven and resilient people. And, look, I'm an entrepreneur. I have to be resilient, but I think these people are even more resilient. And so, for me, I was like, there's got to be a better way for people that are going through infertility. That's really what drove me to start a company, quit my job, do the whole shebang there.

+ +

WILL: I wanted to paint a picture because I'm kind of tearing up already thinking of some of the people who've gone through that journey because, like you said, it is not an easy journey. Can you paint the picture of kind of what that journey looks like? Because, from my experience, I know it's not like, oh, I need to go get IVF. It starts way before that, many doctors' appointments. It's a whole thing. I want the audience to kind of hear the whole story and paint that picture of what someone who needs IVF or anything in that category what they're going through.

+ +

THIV: Where my mind goes to is think of a couple who, like, just got married or been in a long-term relationship, and now they've decided that they want to start having kids. What typically happens is, you know, usually, you just go, yeah, we're going to try, and then that's what they do for that time. And so, they're happy. They're excited because this is, like, a new chapter. And what I picture is as they're trying, they just keep trying. And they're, like, constantly every month or every so often when they're checking, using pregnancy tests, they're just seeing the negative result, negative result, negative result. And so, that just keeps happening over and over again.

+ +

After that point is when they go, okay, maybe we need to seek some help. What ends up happening is they go to a doc, and a doc goes, "Hey, just keep trying." That's literally the advice you have to give. That's based on the guidelines. So, no test. Nothing. It's just the fact that it will happen on its own. Don't stress. And so, they keep doing that, and they keep seeing negative results. And that happens for a long time. Most people end up doing is they spend about three to four years on this journey.

+ +

And where it really tests you, it tests your, you know, relationship with one another. It really questions yourself. You know, on the woman's side, like, they feel lonely. They feel like when they go to events, they see other people celebrating. They're getting pregnant. They're frustrated as to why. So, it puts emotional toll there. And then, also, for the man, it puts a lot of pressure and makes them question their masculinity. This ends up happening.

+ +

From there, they start getting testing done. It just becomes very clinical. They start understanding, okay, they may need to now do some sort of treatment. It becomes like a job, another job for a lot of times. And that's what we kept seeing with people, and I saw for many people as I was helping them on their journey.

+ +

It's really a stark contrast to what, I think, most of us have in our head of, like, when you want to build a family where it should be joyful, and loving, and exciting, and easy. It's not. It's a hard path for people where you have to be resilient. So, I hope that that paints a picture. That's what I feel, and that's what motivates me to keep trying to figure out a better way and why we started Hera.

+ +

WILL: Yeah. The people I've talked to and been around that's kind of the same story. And you're spot on when you say they start questioning themselves. Like, "Is it me? Did I do something wrong?" And it's heartbreaking because you're like, "No, you did nothing wrong." And so, yes, I am so glad that you shared that and that you're doing something about it. So, can you kind of go into what is Hera doing to help the situation?

+ +

THIV: What we are doing we're a telemedicine-first provider. So, what we do is, one, is that through our app, you're able to access the care you need right away. So, that means if you are being told, "Keep trying," but you want to know if there's something wrong, we have testing there. If you want to know, is there things that I could do or take that will improve my chances? We have our supplements and medications that we can provide to you and deliver to you and have you follow a treatment plan. If there are more things that we need to do, like go to a clinic and get IVF, through our app, you're able to do that. We're able to find you and coordinate all that.

+ +

But really, we're a companion as you go along in this journey to sift through and provide the solutions that you need. The big thing that we've been really focused on, because we've learned this through our research, and my co-founder ran a fertility clinic for 20 years, is that most people think if you are having trouble, you have to go through something invasive like IVF, or you have to keep trying. But really, what's happening is that only 5% of infertility cases need something like IVF. And what you actually can do is that with a special set of medications taken in a certain way with our plan that spells it out for you, you can be successful. Improve your odds two to three times is what we've been seeing.

+ +

So, that's really where we're honing in on: Can we improve your chances of getting pregnant? And that has all these different pieces to it. And so, I think that's what our members really like is that, one, they get educated on what's going on and what they can do and pick options. But then they know that if they're with us and they're following our instructions and taking the medications and everything, it will improve their chances. And so, then, hopefully, they can get pregnant.

+ +

WILL: I love that because there's nothing more frustrating than knowing your body and knowing, hey, something's wrong, and someone's telling you, "Oh, just keep trying, like, just keep doing it." So, I love that you're stepping in and educating them because I feel like, especially in our healthcare, a lot of issues that I've seen is because people are not educated on, hey, that's not the right path to be going down, or there's another way to do it, and you just didn't know that. So, I'm glad that you're offering that next step. That sounds amazing.

+ +

THIV: Thank you. I think you said it the best right there. It's that next step. People want to do something. The most frustrating that we kept seeing and hearing from people is just being told to do the same thing. Isn't that the definition of insanity?

+ +

WILL: Yeah [laughs].

+ +

THIV: For us, we want to provide something so they could take that's safe, reliable, and has shown effectiveness. And along that, they could talk to someone and make sure and be reassured as they go along in this journey, as they have more and more questions, what else can they do, and just really feel empowered on this infertility journey.

+ +

WILL: That's awesome. So, how long have you been around? How long have you been a company?

+ +

THIV: We're getting up to two years. Our two-year anniversary is coming up. So, we started in April 2022 really testing out what could be the right solution here. You know, as someone who has done a few startups in my past, the first rule I would say is you never fall in love with the first idea, but you go off and test it, and find out, and interview, and keep iterating. And so, we did that for some time and learned so much. I think I've talked to now thousands of people on their fertility journey.

+ +

And, you know, as we were going along, we realized we had something special with this telemedicine-first approach. And so, we launched officially in August, I believe it was 2023, our app with the clinicians and everything after beta testing it for some time. And now, we have a group of patients going through our program in about 12 states, and we are expanding as we go along. We'll hopefully get to the 50 states by the end of the year.

+ +

WILL: Wow. By the end of the year, that's amazing.

+ +

THIV: Yeah. Because we're getting a lot of people wanting it in all parts of the country, but we wanted to really focus on the areas where you won't have that access. So, to your point earlier, you know, a lot of people we've seen so far were telling us, "Hey, I don't have a fertility doctor near me. It takes me five hours to get to one, let's say. And so, I feel hopeless. I feel like I have to do that, and I shouldn't have to." And so, that's where it's this piece of, like, knowing where you're supposed to be going or getting access and not having these barriers in front of you.

+ +

And so, for us, we're really focused on those states where access is a big issue for these services. And so, we're in Texas. We're in Kansas. We're launching in New Mexico now, places like that where you won't see too many fertility clinics in a lot of areas.

+ +

WILL: That's very interesting, and I'm glad you brought it up because I was going to ask you about that because I know you kind of specialize in the telemedicine portion of it. And I'm from Louisiana, so kind of familiar with Texas, and I used to live in Kansas. And so, those places are not the most...there's parts that are rural, but not the most rural parts, so it's interesting that a fertility doctor can be five hours away. That just blows my mind that like, you know, you're not talking about Montana or anything. You're talking about, like, Texas and Kansas that, you know, five hours is a long time. And the amount of times you have to visit the doctor for that, yeah.

+ +

THIV: For fertility, there's a lot of visits. You're going there pretty often. Especially if you're going to do IVF and having to do multiple rounds of it, you could be going there for months. And so, yeah, there's just...the reason behind this, and this is fascinating to me as well, is there are only, like, about 550 clinics that specialize, like, fertility clinics in the U.S. And most of them are actually concentrated in the metropolitan areas, and I think the stat is, like, 50% of those are in 6 states. So, the remaining states really get a few of them. I think New Mexico has, like, two or three fertility clinics.

+ +

And so, these clinics have the specialists, and they do as much as they can. But if you're not nearby one, it's really hard to do that consultation, to learn from them, to find out if there is something wrong. And so, now you still are in this gap of like, is there something wrong with me? Because it could be a simple solution, right? And if you overcome it, you can get pregnant. So, that's where we see–can we be hyper-focused on those areas where someone is maybe two hours or more away from the nearest fertility clinic?

+ +

And we really want to focus on that access piece because people should get access to this. So, that's why, with our telehealth solution, we have our own clinicians who will be able to assess. For the testing, we'll send you kits to be done at home, or you can go to a nearby lab, and we'll get the results that way. Give you a set of medications or treatments [inaudible 16:11] we'll actually send it to you.

+ +

WILL: Oh, wow.

+ +

THIV: That's how we're trying to be much more convenient and accessible because that way, you're doing a lot more at home, and these barriers that are currently in front of you are gone. And people are able to get care.

+ +

WILL: That's amazing.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration, or click the link in the show notes for this episode.

+ +

WILL: Let me ask you this because it kind of sounds like the concierge portion of it, which is amazing. How are you able to do that portion of it but do it cheaper than the streamlined way of doing it?

+ +

THIV: So, I like to look at this in two ways; one is the business, right? How do we make sure the economics make sense? And then the other is how do we make it so that the patient experience and care is optimal and satisfactory, right? Or excellent, I should say. So, the way that we thought about it, and I went around and interviewed and observed so many different care models, like, the ways that these different clinics are working, so be it in a hospital, in a traditional clinic. In the earlier days, I would go and do all of that.

+ +

You really have to think about is there a better way that we can do it but still have the same success and outcomes? And so, the first thing I noticed is that technology needs to be at the core of all of this. It checks off both of those buckets. The economics and the business will thrive because of that because you can introduce efficiencies, you know, streamline a lot of the operations, do automation. So, that was core to us. So, we were very careful and selected a good vendor to work with on the EMR side and then built on top of that.

+ +

And then, from there, technology also helps from the patient side because of all the places, like, I was interviewing, none of the clinics really had, like, an app, or they kind of had something where you would email someone. You would still call, and it was very old school. But what we heard is that patients had so many questions after, before, middle of the night. And so, we were like, how do we make it so that they feel like they can reach out to us, talk to us at any point? And so, that's why we created the app. And you can message us at any point, and then there'll be someone there to help if you need anything or to answer any questions. So, that's on the technology.

+ +

Then staff people wise the thought, and other companies have done this, but concierge care, you know, people have thoughts about it, but what's really good is that it's really about, how do I make sure that the patient is getting the best experience and getting the answers that they need? And really, it's about making sure you have the right team there who's available around the clock to answer those questions who are fully trained.

+ +

So, we hired a lot of people that had gone and worked in the fertility space. Like, my co-founder knows so much about fertility because she's worked there from the beginning. And so, that's really helpful and is able to answer a lot of these questions that come up immediately. But then we staffed it so they're available around the clock so we can be available for the patient.

+ +

And then from there, I think the business model makes sense because we're providing this extra support; patients are willing to pay for it. We've built it so that it's not transactional. And it's more about a long-term engagement so that way people pay us on a membership basis for certain services.

+ +

And so, at the end of the day, we've, essentially, and I hope this makes sense, is that we try to not replicate what a typical clinic would do and, which is, like, bill for each service. And we try to think about it: how can we build a long-term relationship with this person who probably will be here for some time and then build pricing and a business model around that? I think that's why it's working. You know what I mean?

+ +

WILL: Mmm-hmm.

+ +

THIV: And I think that's so important because if we just replicated it, it wouldn't have worked. Things would fall apart. The economics wouldn't make sense.

+ +

And then the last thing I'll say is that clinicians-wise, we didn't want to have doctors just there like everyone else thinks, but we actually have nurse practitioners or APPs. And we did this because there was more and more research, and we tested this out for long-term engagement; patients love the nurse practitioners. The doctors are great. They play a role. But I think the quarterback in all of this is that nurse practitioner. So, that's where, I think, I'm super excited. We're hiring a bunch right now. They are really the quarterback.

+ +

And we have a good clinical team to make sure everyone feels equipped. And if they have questions, they're able to answer it with docs. But we take cues from these nurse practitioners. So, I think that really helped on the business side and the patient experience side. And that's why we, you know, we have five stars on our satisfaction. People love us. Yeah, it's a long-winded answer to that, but we really thought about how to build this properly.

+ +

WILL: That's perfect because...and I'm thankful that you explained it because what I got from what you said was not only are we able to do it cheaper, but we're able to increase the amount and the quality of care that they're getting. Like, 2:00 in the morning, you have a question; you can get it answered. Like, you can't get that anywhere else. Like, sometimes you have a question, and it may take 12 to 24 hours to even get that answer. So, that's amazing that you're staffed around the clock. So, it sounds like, hey, not only are we going to do it cheaper, but we're going to be better at the quality that we give you. So, that sounds amazing.

+ +

THIV: Yeah, exactly. And I think that way, what's key here is, currently, in the market for this kind of services, you're paying so much money. A lot of times, insurance doesn't even cover this. So, I've seen people who couldn't get their dream, which, in reality, people's dreams is to have that family, to have that child. And they couldn't do it because of money, you know, maybe it's the Canadian me, but I hate that fact of, like, money stopping you from getting the care you need.

+ +

WILL: Same. I'm with you 100%, yeah.

+ +

THIV: Right?

+ +

WILL: Yeah.

+ +

THIV: And so, for us, it's like, if we can make this cheaper, we can make the prices cheaper, too, and people can pay and afford it and get their dream. And so, that's really why we did it this way. It's not so that we make more money. It's so that, you know, we build a sustainable business. But now, patients have an affordable option in front of them.

+ +

WILL: Yeah. Can you, and just ballpark it, like, what is the normal cost usually for this versus what Hera provides it for? Can you explain that?

+ +

THIV: Normally, people who are going through this would have to spend, ballpark, 15,000 to maybe 25,000. The upper end is, I would say, 50,000, and I'm not including surrogacy in this. But it's a lot of money. People are getting their second mortgage. They're getting, you know, GoFundMes. There's so much that they're doing for this. The worst is when money is blocking you from that dream. So, that amount is typically what we've seen. And that's what my co-founder has told me she would be seeing that from each of her patients and when she was at that clinic. But the way that we've approached it and how much we charge, patients are typically paying us at most around $1,000 to $2,000.

+ +

WILL: Wow.

+ +

THIV: And so, we're able to effectively do it and at least be an alternative option for them, and that's affordable. And so, I'm always excited when I see patients who come to me, and they're like, "Oh, it was so expensive." or "I thought it was going to be so expensive, and this is so doable for us." That's the difference right there.

+ +

WILL: Wow. That's a huge difference. Wow.

+ +

THIV: [chuckles] Yeah. And I hope that this changes, like, the conversation. I've seen other markets or in the past where, you know, things were so expensive, and then these new startups were coming in and really making it so that it becomes competitive. And the incumbents have to change their prices, too, and get innovative.

+ +

My goal is to bring down that, you know, current average cost of 10,000, 20,000 and so that it becomes much more affordable. And so, that could be done by improved technology, more competitors, all those things that we know about. That way, you know, as more and more people are having these issues with infertility...it used to be 1 in 8. Now it's like 1 in 5 or 1 in 6, even. We need more and more of this kind of care so that people can live out their dream, and let's make it affordable so that they can do that.

+ +

WILL: That's amazing. And I really hope you reach that goal because I think especially in healthcare, we need more of that. We need the competitors that are driving the price down instead of driving it up. So, that's amazing that you're creating that.

+ +

THIV: Thank you. That's why, you know, we have competitors, but I love it because a couple of years ago, there wasn't as many people in this space. And it keeps growing more and more. As more and more people put their attention to this, I think we'll see really good solutions so that people have options. Obviously, I'm biased. I would love for in 5 years or ten years, you know, if someone is having trouble, they're going to think of Hera. And they're going to download our app and talk to someone right away and know what they can do so they can be closer to that dream of theirs.

+ +

WILL: Yeah, definitely. And I'm glad you mentioned the 5 to 10 years. So, I know you mentioned, hopefully, by the end of the year, you're going to be in all 50 states. What's the next step? What's the next goal for Hera?

+ +

THIV: Yeah, it's a great, great question. I think about it all the time. I think for us, what we wanted to do is really, like, right now, we are early days, and we're learning from every patient we see. What else can we do? How can we help you? Fifty states is one target or milestone. I think there's a lot more we can do on the product side. For instance, we're going to be launching a male infertility program. That's probably the first of its kind out there where we specialize on the men side of things and bring them into the conversation and have them be actively involved. So, that's a big one.

+ +

But we're going to keep doing more and more of solutions and products, so really strengthen the solution that we have here so that you come to us, and we have everything that you need.

+ +

I would say next after that is really partnering with more and more of the clinics that are already there. And I say this because we're part of the health system. Yeah, business tells us to be competitive, and that makes sense. But you also are taking care of patients, and you need to partner where maybe you don't have the services for, but someone else does, or for continuity of care. And so, you need to be part of the system. And I think that's key for any kind of healthcare company that's starting up. And so, that's, I would say, level two. I like to think of, like, in games, like, the different levels.

+ +

I would say after that, as we grow and become integral to the system and be that solution that people go to when they're in need; we'll evolve to, like, going into the employer and health plan side of things and then be able to say that it's part of your insurance and health plan. And then it's a no-brainer now to sign up with us because someone else is paying for it, which is great.

+ +

So, that's kind of how we're evolving, but I want to make sure...and I think something that I've heard in your other episodes, but I'm a big believer of talking to the people that are using your solution and learning from them, and identifying where there may be gaps that you can help address. And so, as we evolve, we're going to keep talking to them. I always give out my cell phone number and tell any of our user who wants I'm like, "If there's something we could do better, let me know. Tell me directly." And so, I want to make sure that's clear that we'll see what our users tell us, what we should be focusing on.

+ +

WILL: Wow. I love that. That's amazing. Let me ask you this in kind of closing it out is, like, so that's kind of five years. Do you have anything that you want to promote, like, what you're doing right now?

+ +

THIV: Yeah. No, I think the big thing is we are constantly working on our product. What I would say is if there is anyone who is either fertility curious, or going through their own journey, or who has gone through this in the past, please reach out to me or, use our solution, talk to our clinician. I think it's so empowering once you meet with our clinician to understand what your options are and what you should do.

+ +

If you're not in one of our states, then let us know, and we'll put it on the list and bump it up. So yeah, like, please come to our website, check it out, join us, try it out as well. We're all about trying to help people get to that goal of theirs, their dream.

+ +

WILL: I love it. And we'll include it in the show notes, but in case they don't have the show notes in front of them, tell them how to get to your website, how to contact you, how to get the information.

+ +

THIV: Yeah, for sure. So, you can go on our website. It's herafertility.co. And on there, you can sign up for our services and sign up for our app. But if you have any questions before signing up, you can schedule time to talk to one of our fertility advisors, and then, yeah, you can always reach out to me. I'm on LinkedIn under Thiv. And Twitter I check every so often or X. And you can email me at any point at thiv@herafertility.co.

+ +

WILL: Awesome. Well, it was great chatting with you, and I've learned so much. Keep doing what you're doing. And I hope that you're successful because you're doing some amazing things.

+ +

THIV: I really appreciate that.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+qWR0Xeyx + + ]]> + + Will Larry + + + 513: Custom Fit, Global Impact: MADE TECH's Apparel Innovation with Dustin Butcher + https://podcast.thoughtbot.com/513 + dc216af3-6b65-4ee5-abad-58bb57620b31 + Thu, 22 Feb 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + In this episode, Victoria Guido chats with Dustin Butcher, CEO and Co-Founder of MADE TECH, about revolutionizing performance apparel with custom and made-to-measure automation technology. From personal frustrations with ill-fitting gear to pioneering a technology that offers 100% size inclusivity, Dustin shares how MADE TECH is enhancing individual performance and comfort and pushing the industry towards more inclusive and sustainable practices by partnering with established brands. + 37:11 + no + + + Host Victoria Guido interviews Dustin Butcher, CEO and Co-Founder of MADE TECH, a company revolutionizing the performance apparel industry through custom and made-to-measure automation technology. Dustin shares his journey from working in the outdoor industry and running a creative agency to founding MADE TECH. The company's mission is to provide performance apparel that perfectly fits the wearer's body, addressing a common issue where standard sizes fail to accommodate individual body shapes and sizes, particularly in sports where fit and movement are crucial. +Dustin discusses the inspiration behind MADE TECH, which stemmed from personal experiences with ill-fitting outdoor apparel during activities like ski touring. He highlights the company's focus on inclusivity, allowing for 100% size inclusivity and addressing the needs of a broad spectrum of body shapes and sizes. This initiative caters to individuals who traditionally struggle to find performance gear that fits and opens the door for brands to offer more inclusive product lines. Dustin's background in the outdoor industry and encounters with the limitations of standard sizing in apparel led to the development of a technology-driven solution that customizes clothing to the individual's measurements, enhancing performance and comfort. +The conversation also touches on the industry's broader implications of custom and made-to-measure apparel, including sustainability and waste reduction. Dustin elaborates on MADE TECH's business model, which initially targeted direct-to-consumer sales but has pivoted towards partnering with established brands to offer custom-fit options. This strategic shift aims to leverage brand trust and reach a wider audience, promoting inclusivity and personalization in the performance apparel market. +MADE TECH (https://www.made-custom.com/) +Follow MADE TECH on LinkedIn (https://www.linkedin.com/company/made-tech/). +Follow Dustin Butcher on LinkedIn (https://www.linkedin.com/in/dustin-butcher/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: + VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dustin Butcher, CEO and Co-Founder of MADE TECH, powering the future of performance apparel with custom and made-to-measure automation. Dustin, thank you for joining me. +DUSTIN: Oh, thank you so much for having me, and I'm excited to be here. +VICTORIA: Wonderful. Yeah. So, why don't you just introduce yourself a little bit more and tell me about your background? +DUSTIN: Yeah, of course. So, as you mentioned, I'm one of the co-founders of MADE. We have built technology that enables the automation of custom and made-to-measure performance apparel. So, similar to how you could, like, you know, go online and design a custom suit or something like that and get it made to fit your body, we do that for performance apparel so that the product that really matters if it fits you properly and that sort of thing, and, you know, so that might be outdoor apparel, motocross, yoga. Whatever sport it is that you're into that, you need your apparel to move with you; that's what we fuel. And so, we're working with a bunch of different brands in that space to do that. +My background, I came from the outdoor industry; always been in the outdoor industry since I was able to hold a job, originally just at ski resorts and stuff as a lifty and as a waiter, and all those types of classic, you know, teenage jobs. And then I worked in-house at a bunch of outdoor companies, Voilé, a little backcountry ski company here in Salt Lake, and then Black Diamond, and Gregory Packs, and Petzl, and kind of worked around the industry a bit. +And then for the last 12 years, I ran a creative agency, specifically in the outdoor industry, working with a lot of those same brands and other brands in kind of communicating their value to the outdoor customer. And so, and then we kind of rolled into MADE, had this idea, connected with my co-founders, and really built it from there. +VICTORIA: I love hearing about people building careers in the outdoor industry, something really close to me personally. I also got my first few jobs from rock climbing and having competed as a young adult and then walking up to businesses and saying, "Hey, you have a climbing wall. Like, you should hire me, and I'll run your climbing wall." And they're like, "Okay." [laughs] So, it just, like, brings you so much confidence and such a great community to be a part of. +And so, you're talking about creating clothes that move with you. Can you tell me a time when you were doing something, some kind of performance sport activity, and you were like, "Wow, whatever I'm wearing does not fit me. This is really affecting my performance and my ability to do this sport"? +DUSTIN: Yeah, I probably have too many of these stories. And what's interesting about that is I'm a pretty traditionally medium guy. I'm 5'11. I'm 170 pounds. Like, I should generally fit into mediums, but I'm just in that weird spot where I always kind of feel like, am I a medium or a large in this? My torso is a bit long. So, my primary sport is ski touring, like, backcountry skiing. That's what I love to do. That's where I spend my time and my focus and a lot of that kind of stuff. +So, I've had lots of experiences where I might be climbing up a [inaudible 03:08], and my jacket comes up a bit on my lower back and exposes my lower back, and it's cold. And so, then I got into defaulting where I wear, like, one-piece base layers, so I can never expose my skin directly. But it's like, the ultimate solution really was to have properly fitting stuff. +The original concept for MADE came from I was out on a ski tour with some friends, and I was wearing a pair of pants, some soft shell pants that I loved the fit of. But the feature set wasn't there, and they were, like, Alpine climbing pants. They're not even designed for ski touring. They didn't fit over my ski boot. They looked a little bit silly, but I loved the fit, like, in the leg. And they didn't have like, you know, a beacon pocket and those types of things that I would want. +But I do have this other pair of ski touring soft shell pants that I wear most of the time that fit terribly but have all the features that I want. And it was like, ah, man, I wish I could, like, determine exactly what I need as a skier and then, you know, would have the confidence that it was going to fit me perfectly, that sort of thing. And that's really where it kind of started. It was a very selfish, like, how can I get the thing that I want? +You know, I connected with my co-founders, both of whom came from Arc'teryx to start this with me. And we really got to thinking, and it's like, wow, with this type of system, we can make a really big impact as far as like, we can be 100% size-inclusive. There's not body shapes or sizes we can't meet with this type of system. And so, then it really opened a lot of doors as far as, like, what we can do and how we can connect this. And that's when we all kind of came together on this idea and said, like, "This matters, and we're the ones to build it." +VICTORIA: I love that you're trying to fit something that works for you, and you realize having that ability could make it inclusive for everyone. And I wonder if you could share more about what you know about sizing in the clothing industry and, how that's developed over time, and how it may be really limiting who has access to the products that you're selling and the activity that those products allow you to do. +DUSTIN: It might sound like a crappy, little history lesson, but, you know, the further back we go...before the industrial revolution, clothing was made to fit the individual, you know, you'd go to a tailor, and you'd tell them what you need the product to do for you, and they'd measure you and make the product. And then we got into this mass manufactured thing, which is great as far as, like, efficiencies and economies of scale, and all that kind of stuff. And so, we can get stuff cheaper and still, like, high-level product, but we got into this standardized system. +And then companies deal with this challenge of like, okay, what is our small? What is our medium? What is our large? And finding those things and trying to meet the needs of the bell curve but also knowing that for every individual person, they're not meeting that person's fit needs, right? They're trying to fit as many people within the primary sizes as they can, and that's part of the challenge. +One of the things that we've run into in performance product, especially, is that, like, there are massive swaths of people that simply cannot get good performance product in their size. 68% of North American women are over a size 14, and it's really hard to find good ski outerwear, as an example, for a plus-size individual like that. And that's not even that plus size. That's an average, like, that's 68%. Like, we're not talking about like, oh, these are the ends of the bell curve. These are people who want to get out and do things, and they've been unable to do it because of clothing. +What a silly reason to not be able to do the sport that you're excited about, or even to go spend time with your friends and family, or whatever it might be, like, your motivation, but, like, what a bummer of a reason to not be able to do it. So, those are the things we're trying to solve through our system is saying, like, "Hey, we can work with these existing brands, and they can now offer stuff that is fully inclusive, meets all of their quality expectations, all of this, and still comes in with a very reasonably priced product." +You know, it's not what you think custom would be where it's like, oh, it's going to be five times the cost of the ready-to-wear product. No, we can come in at the same price or very similar with these brands and allow them to make options that meet the needs of all different shapes and sizes. +VICTORIA: Well, I can really relate to that because some of the clothes that I would wear for climbing or even yoga are coming in at a very high price point already. And I recently tried on a set of clothing from a retailer who's normally, like, known for yoga and outdoors equipment. And I was just surprised at how it seemed that they wanted the person who fit these clothes to be very narrow all the way through [laughs]. And I was like, wow, I'm struggling to fit in these clothes. +And, like you said, like, I feel like I'm pretty average, and that was frustrating, and especially, like, getting clothes like that it can really deter people from participating in the sport and participating in outdoor activities altogether. So, I think it's really cool that you are going down that journey. +Let me ask you, how did you get the original idea for MADE TECH, specifically? +DUSTIN: So, first, we had to determine, is it possible? Can you make a system that would automate the creation of a custom pattern, all of that kind of stuff in really technical product, right? We know it can be done in suits and jeans and that sort of category that's more of a simple cut-and-sew. Whereas when you get into technical product where you're dealing with waterproof fabrics and seam sealing, you know, in a ski jacket, there's, like, 200 pieces of that product versus two pieces that get, like, pushed together and sewn between, right? Like, it's really, really complicated stuff. +So, we started with that kind of hypothesis is, yes, we can figure this out, and we did that under a D2C brand, MADE Outdoor. It's madeoutdoor.com. It's now been live for almost two winters, and we've made a bunch of product and a bunch of people happy. And, you know, we had some really early success with really tall, thin dudes, you know, like, that 6'6, you know, I'm sub 200 pounds or something. I'm really thin. And that person has been kind of forced into wearing a triple XL jacket for so long. So, they're pretty psyched. And so, like, we've had some of those early wins, and that was really kind of like, okay, we tested it. We've proven this system works. +And so, it's really just been in the last six months that we've said, like, okay, now where do we make the biggest impact? How do we make that change in the industry and in these opportunities to participate in these sports? And that's not through our own brand. That is one piece of it. Sure. But the larger opportunity is for us to work with existing brands that have that consumer trust already that, you know, like, "Oh yeah, I've worn this brand for however many years, and I have that trust, and I love the brand. And now I can get something that fits me perfectly." +Or it's that person that's like, "Oh, I've always worn this brand because it fits me, but I really would love to wear this other brand, but I know it doesn't fit me properly." And so, it opens doors for people to kind of like say like, "Okay, what's the brand? What are the materials? What's the brand ethos that really connects with me? And be able to go there and not have fit be the reason that I can go with one or the other." +VICTORIA: That's really interesting. So, you started with originally direct-to-consumer custom ski and snowboard wear and, found your initial success, and then identified a pivot point where you could expand and do direct business-to-business and make other brands more inclusive as well. +DUSTIN: Yeah, that's the big idea, right? And it doesn't need to be my name or our brand name on the thing. Like, what we've built, like, there's just an opportunity for an impact here that's bigger than just us. +VICTORIA: I love that. And it makes me want to ask you, what other core values drive your everyday decisions as you go about your process here? +DUSTIN: Yeah, the three kind of pillars we think about anytime we are working on something, and really that kind of drive our whole system at MADE, is inclusivity, sustainability, and personalization. I should come up with a better way to say that, but it's those three, right? +So, on the personal side, we want you to have the thing that you need. Your setup for some climbing clothing is going to be different than mine. You're going to want to set things up differently. And maybe you are a boulderer, and I am a big wall climber. Yeah, we have different needs for what we have. And so, we want you to be able to kind of define that rather than just being a designer in some boardroom somewhere. So, that's the personalization side. +The second is the sustainability side. 30%, and this sounds outrageous, but 30% of apparel is never sold to an end consumer. And it eventually gets destroyed or sent to the landfill, which obviously has a massive sustainability impact, not only for that product to how do you dispose of that kind of thing, but also just, like, we made it, and it took time, and it took money, and it took human hours and all that kind of stuff. +So, that's a huge opportunity for us because everything that is made through the MADE system it already has a home. Like, we never make a thing...if any of our brands are using our system, they only make things that already have a home. So, that's a huge win. We immediately take off that 30% of overproduction, right? +And then the inclusivity stuff we've talked about already, but it's like, we just want people to be able to do the things that makes them happy. And it's a bummer when you can't do those things, whether it's climbing, or yoga, or whatever. Like, you know, there are some big brands that have had a hard time with size inclusivity, which is totally understandable. It's really hard to make product that fits everybody. +And so, you know, we create these standardized systems, and then we knowingly leave people off. But we know that because it's like, well, not that many people in this size have bought from us, and we have to hit our MOQs, and we have to do X and Y and that sort of thing. But with this type of system, they can hit everybody, and they're not taking those, like, big risks as far as like, oh yeah, we have to set place this big order, and then all this product is going to sit in a warehouse for three years before it'll finally sell through. +VICTORIA: It reminds me of a classic story you hear in software design about how they tried to make the first Air Force pilot chair; I don't know if you've heard this one, where they, like, took all the measurements of all the pilots and then they, like, averaged out all the, like, heights and widths and everything. So, they made this chair that fit no one. +DUSTIN: Yeah [laughs]. +VICTORIA: Because no one is perfectly average. Like, you know, everyone has variations in their size and their measurements. And so, I think that's really cool. It's interesting. I hadn't thought about the conservation impact or the impact on the environment; it takes just to have to have so much error in your sizing, which is naturally part of what's going to happen when you try to make an average size. +DUSTIN: I've not been on the product design side of apparel. I don't envy them. Like, their job is hard to find that fit story that, okay, this is what the average consumer looks like. But what does our consumer look like, and then how do we find something that meets them? And what is our medium? And then, do we have to make a different medium for different markets in the world? And there's so much, like, level of detail in there. +That's one of the beauties of us working with other brands now is that, like, their level of knowledge in that stuff is huge. And so, pulling from that and being able to say like, "For your product, how should this jacket fit somebody? How do you want it to move?" So, then, when our system pulls in the 3D measurements of that individual, it can say like, "Okay, this jacket needs to sit this far off of the shoulder. It needs to have this much room around the bicep." Like, those types of things are all part of how it works and gives those opportunities for, like, an individualized fit that is determined by how the brand wants it to perform. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at tbot.io/devops. +VICTORIA: How did you go about, like, what was your first step when you said, "Oh, I need a system to do this type of automation and to be able to do this kind of customization"? How did you approach solving that problem? +DUSTIN: Well, we started to figure it out, and we realized that the system didn't exist [laughs]. So, that's really what it was. It was out of necessity more than anything. So, we wanted to build our custom and made-to-measure brand, and none of the systems existed to do it. So, we got to work on building those systems. You know, that was, over the last year, it's like, okay, we built all these systems. Do we just use them for ourselves, or can we have that bigger impact if we work with other brands? +VICTORIA: So, did you have the skills to build the technology already in-house, or did you have to develop that within your company? +DUSTIN: Oh, man. So, my co-founders are amazing. I started this with two co-founders, Cheryl LeBarr and Capri Philip, both came from Arc'teryx to start this with me. Arc'teryx, if people don't know, is one of the big outerwear brands in the outdoor space, a beautiful, beautiful product. They understand fit and, form and function, and they make an amazing product. And I have connections over there, and so I made a few phone calls and really, like, found the right people. +So, we got to work on it. None of us are coders. We kind of scrambled through our MVP. We figured out how we could do it with...if you look at our MVP backend, it's messy, like every startup's MVP is. And it's like, okay, this system is connecting to this system over here, and it's talking to this. And it's sending this data from here and that sort of thing. And it's like, but we figured it out, and that was the key. +You know, so the automation of this stuff really came from the pattern design side, which was Capri's specialty. And then the automation of the, like, tech pack and all of the factory details that they need to produce the garment came from Cheryl's side, from the product development side. And mine was more on the brand and kind of communication of the value and that sort of thing. We were scrappy. And we figured out how to build something that worked. +And then the next step was to bring on a proper CTO and then really build the, like, scalable system that's like, okay, now it can plug into existing systems. And, oh, you have these expectations of your enterprise-level software. Yes, this is how it works, that sort of thing. So, it's been tiered in that way. And that, honestly, is part of the fun. Like, part of the fun is finding these new problems to solve and then coming up with creative ways to solve them. +VICTORIA: That's really cool. So, you all were able to build your MVP together within your existing co-founding team. I'm curious about, like, what platforms you chose to do that in. Did you pick, like, a programming language or some sort of, like, ClickOps or some kind of, like, other tool that you could use, like low-code tool, to develop it at first? +DUSTIN: I mean, it's very low code. It's Google Docs, Google Sheets that speak to each other and, like, can share data between them kind of thing within our secret backend, obviously. We have a really great relationship with our measurement partner. We didn't build the measurement technology. That's a whole different business model and that sort of thing. So, we work with this great group called 3DLOOK that does our measurements, and it just uses a customer's phone to take a front and a side photo, and then we get a full 3D model that goes into our thing. It's super cool. +We tried to pull some things off the shelf that existed that we could use without having to build it ourselves. With my agency business, like, I have a developer that I work with a lot. And so, like, we called on them to help us build a few pieces, but for the most part, it really was just, like, getting scrappy and creative together. And, like, we built the MADE Outdoor platform on Shopify. It's like all these systems that are just kind of like, yeah, we know how these systems work. Let's use those to start, and then if it works, then we build it into a bigger framework. +VICTORIA: I'm glad you mentioned that there's take a picture because I was going to say, whenever I even have to do, like, a sizing guide chart on a website to buy clothes and you have to, like, measure your waist, I'm like, I don't want to do that [laughs]. I'm just, like, too lazy. I don't want to check that right now. So, taking a picture would be so much easier. +DUSTIN: People are so bad at that [laughs]. Like, when we first got started, and we were asking people to send in their measurements, and here's a video on how to do it, even the same person, like, with three different people measuring them, you'd get wildly different information. And so, we definitely knew early on, okay, we need to eliminate the human error aspect and get this as digital as possible. So, that's where we found the right partner. And it really is, it's, like, a two-minute thing. +You stand in front of your phone. It takes photos. The photos aren't even saved anywhere, like; they're AI, like, looks at the photos and then gives us the model. We're not sitting on a bunch of pictures of people in their base layers and underwear or anything like that. It's like, all of this is just kind of like, we have your 3D model, and now we can build the product, and we can even do digital test fits on that person, your actual body, before it even gets made, and stuff. +So, we have systems for redundancy and everything that we can test everything. And that's just the beauty of, like, the modern technology that exists. Like, we didn't build that either, but we are using the heck out of it to make sure that we can make the best product for people. +VICTORIA: That's really cool. I love that. So, you've maybe answered this question already a little bit, but was there anything else in your product discovery process, and especially as you shifted into marketing directly to businesses, anything that was in your discovery process that surprised you and had you pivot in your strategy? +DUSTIN: You know, you start with your own experience, right? So, we are sitting in our meetings, and it's like, oh man, here's all the products we want to make. And we're like, we've got this list of 40 things that we want. Oh, I need soft-shell pants. And we started in hard shell for our own brand. So, then it's like, "I live in the Wasatch. I don't wear hard shell, like, while I'm ski touring, at least. Like, I need soft shell." And then it's like, okay, well, let's start working on soft shell stuff. +Then it's like, okay, we also need mid-layers, and we need base layers. And then we need mountain bike, and we need trail run, and we need climbing, and we need hiking. And it's like, oh man, you know what would be easier? If we just worked with, like, one of the or all of the big brands in this space. And there's some really great examples of, like, smaller companies that have created really compelling systems to work with these brands, like the same group that does the secondary market stuff, so the Worn Wear program for Patagonia and the ReGear thing for Arc'teryx. +And they built that same structure for, like, two dozen different brands. And it's like, man, that is the model for us. That's where we can really connect is they've created so much value in the secondary market, and we've created a bunch of value in this custom and made-to-measure market. That's what we want to do. And we want motocross...like, the MADE brand isn't going to make motocross stuff. The MADE brand isn't going to make fly fishing necessarily. But we want these markets and these people to be able to have that solution. And we also, like, we're early in the space. +Like, we want them to use us rather than, like, take the time and money and everything to build it themselves. Like, come to us, like, that's our whole idea. We want to have that bigger, larger impact. So, I guess it's us just trying to say like, "What do we want?" And we're users. We know the market. How do we get there the fastest? And how do we have that impact quicker than just necessarily, like, okay, well, in 25 years, we'll have all those products that we want? +VICTORIA: Yeah, yeah, I could see that, how it went from, well, yeah, I would want this for every product, and then you're like, well, I can't build every product [laughs]. So, I like that pivot in your strategy. And what challenges do you see in being able to make that impact as quickly as you want? +DUSTIN: One of our biggest challenges right now, I think, is that this is a totally new idea in this space. Nobody's done this in this space. Like, in suiting, custom suits have been a thing for a long time, and it used to just be for rich people. And now because of, like, modern technology and stuff, it's become more approachable. Awesome. That's great. And so, like, in that kind of category, people are more used to the idea of, like, yeah, I place an order, and it takes time, and they make a thing, and then it comes to me. +Whereas with outdoor apparel and sports apparel and that sort of stuff, you go to your local shop. You try on six different things, and you walk out with the one that meets your needs the best. That's what people are used to. So, it's a little bit of a shift in the thought process. You know, we've had our early adopters, and now we're kind of moving into more people who are like, "Okay, I get it now." And so, we're seeing more of that where it's like, yes, if I give some time, then I really see the value of having something that fits me perfectly. +And in the MADE Outdoor brand, it's not an inexpensive product. We make a really premium hard shell product. Now, it's comparable in price to the other brands that make comparably featured and whatever product, but still, you're spending money, and you want something that's going to last for a while. And so, to have that perfect fit, to have that perfect feature set, to know that when I ski, I totally need a left chest pocket, and I don't need a right chest pocket, whatever it might be, like, your details, that matters, right? +So, that's probably our biggest challenge right now. That's not an unsolvable problem. We can manage that. We can get the communication out. And especially as we're onboarding these existing brands, that gives us the opportunity to have a much larger mouthpiece and be able to kind of say like, "Hey, this exists, and you should care." Yes, it's going to be amazing for individuals who have traditionally been off-size. But it's also amazing for you people who think you've always been just, "Yeah, I'm a medium, and everything fits me just fine." You'd be surprised. +Like, having something that fits you perfectly is a different world, and the ability to then move in that sport and, like, be able to do your thing, it's like, oh yeah, I guess that, like, extra fabric in my shoulders was kind of, like, limiting my movement while ice climbing or, you know, oh yeah, my sleeves were always coming up while I was climbing, or whatever it might be. Like, there's things that I think people will really kind of be psyched about when they start to experience that custom aspect of it. +VICTORIA: Yeah. I can speak to some of that, too, as, like, a climber. And you mentioned it even when you talked earlier about, well, if you're bouldering at the gym, that's a totally different experience than if you're out all day on a multi-pitch, and you're on the wall, and you're, you know, you're vertical for, like, six hours of the day [laughs]. And I think it's really interesting to be able to provide that customization. +And how are you defining success for the company? So, you just made this pivot about six months ago. Did you immediately create some goals that you wanted to achieve in three months, six months, or five years? +DUSTIN: Yeah, I mean, we have our, like, target, our sales targets and stuff that we are looking at as far as we want these many brands on board this year. And we want to bring on like, you know, as I step back a little bit, as, like, the bigger thoughts behind the company, that's more of, like, where we're trying to target multiple different categories at the same time. So, like, if we can get one big outdoor brand, great, that's what we want to do. +Now, we want all the outdoor brands. We totally want them all. But if we can just get one, then we're going to have a start of an impact in the outdoor sector. Then we want the motocross brand, and we want to be able to make the impact in that sector. And we want the fly fishing brand, and we want the yoga brand, and we want the traditional, like, team sports brands and those types of things. +Like, we want to kind of, like, spread and have an impact across categories and as kind of a first attack. And then to really kind of go from there and say like, "Okay, now let's build out, like, oh, fly fishing really is connecting with this, or the yoga community is loving the, like, idea of a really custom fit product." So, like, those types of things are where we can kind of go from there. +But as we begin, it's really like, can we make an impact across these different categories? And those are a lot of our goals as we start out. It's like, how can we connect with surf? How can we connect with hike? How can we, you know, like, and it's just looking at each of these little categories because we know there's people being stuck that can't get out in each of those things, and we know we can help. But we're not going to design the product personally. So, how can we make that impact with the right partners? +VICTORIA: Oh, that's great. And I'm even thinking about surfing and getting a wetsuit. And there's just so few women wetsuits, period, in the store. And it's very limited in range and can be really challenging. And I took a friend surfing last year and did not enjoy that process. She did not like it [laughter]. She liked the surfing part, but the getting the wetsuit on and trying them on was not great [laughs]. +DUSTIN: I can only imagine, yeah. And there's some really cool, like, in surf, there are some great small brands, like, new brands that are doing custom fit. I don't know their systems. I don't know if it's an automated process or if it's a manual process, but the reality is it's not readily available enough to the general public. And that's where it's like, oh man, our system makes it readily available. +And so, then it's like a simple kind of like, okay, I go online. I fill in this information. I decide, do I want a hood on my wetsuit? Do I not want a hood? Do I want this kind of entry? Do I want...Like, you decide the details that you want, and then the product is made for you. That's the beauty of it, right? +VICTORIA: Yeah. And I'm curious to kind of get back to marketing to existing businesses because you not only have to sell them on this is the art of the possible. Here's, like, what you could do to get the same performance with these custom measurements of your existing high-performing apparel. But you also have to encounter this change management process where they have a way of doing things. You'd be a new product. They'd have to figure out how to change up all their operations. So, I'm curious: what's your strategy for getting involved in that and working through it? +DUSTIN: Oh man, some of these companies are giant ships with tiny rudders, right? So, to get them to shift any direction or the other is tricky. A lot of our current sales pipeline is more medium-sized brands that have a little bit more of a nimble; yeah, we can jump on this. But one advantage we have is that some of these categories do have some custom programs, like I mentioned, the custom wetsuit stuff, like, that is in the market. So, like, wetsuit companies are aware that this needs to exist. Fly fishing waders: there are some custom fly fishing waders, now, not necessarily made-to-measure, but you don't make them in a 4XL or something. You could order a 4XL from a certain company. +So, like, there are systems like that. So, they've actually already kind of figured out the manufacturing side, which is one of the challenges of it that we can help the brands figure out those details because we've done it, and we know how to, like, take advantage of the efficiencies that they have in place with their current supply chain, or they can use our supply chain that we've built out. So, it depends. But that is one of the challenges is to get them to just kind of commit to say like, "Yes, this is worth putting in the time." +So, we do have...actually, the secondary market company I mentioned earlier, the way that they do it is it's, like, a separate site. And so, it's not run through their existing site. And so, they get around some of the ways of not necessarily having to be tied directly into a lot of their internal systems, and it's run as, like, a secondary system. Like, there are guitar manufacturers that make custom that they don't even produce them. They basically license out their shapes and stuff to custom builders. +So, we're trying to take a lot of the learnings from these other categories that do something kind of similar to what we're doing and learn from them and say like, "Okay, that's one approach we could take, or that's an approach we could take." +And then, really, we're going to the sales conversations with those brands and saying, "What do you need? Because we can be flexible." We're the opposite of the giant ship with a tiny rudder. We're that tiny, little motorboat that can, you know, like, spin circles and stuff. Like, we can do whatever is really needed at this point for these brands to be able to tie into them. So, we are flexible, and we try to learn as much from them as possible to be able to build the right solution. +VICTORIA: Yeah, I think that is the draw of you get your foot in the door with the middle businesses, and you can prove out that it works, and then maybe eventually the bigger brands start to take notice and pick it up as well. But it is going to take time. That's really cool. I think it provides that, you know, for those mid-size businesses, it gives them an advantage that a larger enterprise wouldn't be able to offer. +DUSTIN: Yeah, no, I think, at first, especially, like, the idea to be kind of first to market-ish with something totally new and exciting and to create that brand value with their customer in a way that they haven't been able to before. +VICTORIA: Right. And you mentioned fly fishing a few times, and I feel like it's one of those sports that I've done it when I was, like, really small, like, maybe with my grandfather, like, fishing in the river. And as I get older, I'm like, it does sound nice. +DUSTIN: Right? [laughs] +VICTORIA: Like, sitting alone in, like, a beautiful place. Like, maybe you get a fish, maybe you don't. I think I like the idea of it more than the reality of it, but will try it out some...I have enough other sports [inaudible 33:02]. +DUSTIN: I think you'd be psyched if you gave it a shot. Like, fly fishing is something that, like, if you like being outside, it's something else. There's a beauty to it, for sure. And there's a beauty to all of these sports. And, honestly, if people are being active, whatever it is that you're doing, good for you. And that's part of it is, like, we are trying to be as sport agnostic as we can in all of this because, yeah, we don't care if you are a diehard snowmobiler, right? Amazing. Great. Let's get you some product that fits so you can get out and do your diehard thing. +Or, you know, maybe you're a mountain biker or a road cyclist, or, like, you know, there's so many things that we wear clothing that we hope allows us to perform in that sport, and yet so much of it is holding us back, even maybe to a degree that we don't even know. Professional athletes and stuff, much of their product is made-to-measure. Olympic speed skaters, like, it's not like they had to just choose a medium or a large type of product. Like, it's made to fit their body so that they can perform at their pinnacle level. That's awesome. +Where that stops is in the, like, general consumer, and, like, I want to get out and do my sport. It's not about being the best at this thing. It's just about being my best at this thing and having the most fun that I want to have in it. The fit and the details of your product matter just as much as it does for the Olympian as far as I'm concerned. +VICTORIA: Absolutely. And it reminds me of a story that happened to me. I was climbing in this very popular pant that is known as their climbing pant from this particular brand. And it was maybe the fifth time I'd worn these pants and just ripped the inseam while climbing. +DUSTIN: [laughs] +VICTORIA: You know, lucky it wasn't that cold that day or anything, but it's just [inaudible 34:50] +DUSTIN: Your belayer got a kick out of it, I'm sure. +VICTORIA: Yeah, there was a layer to this, right? Yeah. +DUSTIN: [laughs] +VICTORIA: And I've heard that happens to lots of climbers who wear those same pants. Like, they're known for that because it's really hard to get that measurement right, especially with that kind of material, which was great. It's like this material that was supposed to not rip, right? [laughter] [inaudible 35:09] what is this? Yeah. Maybe I do want to go outside, and I want to go fly fishing, or I want to go skiing or snowboarding, but, oh, they don't even have pants in my size. Like, I'm not even going to try. And that's really demoralizing. So, I think it's great to be working on that problem. +Oh, wonderful. Thank you so much for joining. Is there anything else that you would like to promote today? +DUSTIN: No, I mean, I think I love having these conversations, and chatting with you has been so great. It's fun to talk about what we're working on and to, you know, get the word out a bit more. There's not really other things to promote other than, like, you know, if you're a smaller or medium-sized or a large apparel brand hearing this, like, please reach out to me. I want to talk to you. +We've built a system that really can help both the brand and the customer. It helps the brand with revenue and with margins and reduced waste and all of these things, but it also just helps the customer have a better product and a better experience. And ultimately, that's, in theory, what we are trying to do when we make product. So yeah, that's my focus, and that's what I want to talk to everybody I can about right now. +VICTORIA: I love that. Thank you so much for sharing your story and for coming on the show today. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Host Victoria Guido interviews Dustin Butcher, CEO and Co-Founder of MADE TECH, a company revolutionizing the performance apparel industry through custom and made-to-measure automation technology. Dustin shares his journey from working in the outdoor industry and running a creative agency to founding MADE TECH. The company's mission is to provide performance apparel that perfectly fits the wearer's body, addressing a common issue where standard sizes fail to accommodate individual body shapes and sizes, particularly in sports where fit and movement are crucial.

+ +

Dustin discusses the inspiration behind MADE TECH, which stemmed from personal experiences with ill-fitting outdoor apparel during activities like ski touring. He highlights the company's focus on inclusivity, allowing for 100% size inclusivity and addressing the needs of a broad spectrum of body shapes and sizes. This initiative caters to individuals who traditionally struggle to find performance gear that fits and opens the door for brands to offer more inclusive product lines. Dustin's background in the outdoor industry and encounters with the limitations of standard sizing in apparel led to the development of a technology-driven solution that customizes clothing to the individual's measurements, enhancing performance and comfort.

+ +

The conversation also touches on the industry's broader implications of custom and made-to-measure apparel, including sustainability and waste reduction. Dustin elaborates on MADE TECH's business model, which initially targeted direct-to-consumer sales but has pivoted towards partnering with established brands to offer custom-fit options. This strategic shift aims to leverage brand trust and reach a wider audience, promoting inclusivity and personalization in the performance apparel market.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dustin Butcher, CEO and Co-Founder of MADE TECH, powering the future of performance apparel with custom and made-to-measure automation. Dustin, thank you for joining me.

+ +

DUSTIN: Oh, thank you so much for having me, and I'm excited to be here.

+ +

VICTORIA: Wonderful. Yeah. So, why don't you just introduce yourself a little bit more and tell me about your background?

+ +

DUSTIN: Yeah, of course. So, as you mentioned, I'm one of the co-founders of MADE. We have built technology that enables the automation of custom and made-to-measure performance apparel. So, similar to how you could, like, you know, go online and design a custom suit or something like that and get it made to fit your body, we do that for performance apparel so that the product that really matters if it fits you properly and that sort of thing, and, you know, so that might be outdoor apparel, motocross, yoga. Whatever sport it is that you're into that, you need your apparel to move with you; that's what we fuel. And so, we're working with a bunch of different brands in that space to do that.

+ +

My background, I came from the outdoor industry; always been in the outdoor industry since I was able to hold a job, originally just at ski resorts and stuff as a lifty and as a waiter, and all those types of classic, you know, teenage jobs. And then I worked in-house at a bunch of outdoor companies, Voilé, a little backcountry ski company here in Salt Lake, and then Black Diamond, and Gregory Packs, and Petzl, and kind of worked around the industry a bit.

+ +

And then for the last 12 years, I ran a creative agency, specifically in the outdoor industry, working with a lot of those same brands and other brands in kind of communicating their value to the outdoor customer. And so, and then we kind of rolled into MADE, had this idea, connected with my co-founders, and really built it from there.

+ +

VICTORIA: I love hearing about people building careers in the outdoor industry, something really close to me personally. I also got my first few jobs from rock climbing and having competed as a young adult and then walking up to businesses and saying, "Hey, you have a climbing wall. Like, you should hire me, and I'll run your climbing wall." And they're like, "Okay." [laughs] So, it just, like, brings you so much confidence and such a great community to be a part of.

+ +

And so, you're talking about creating clothes that move with you. Can you tell me a time when you were doing something, some kind of performance sport activity, and you were like, "Wow, whatever I'm wearing does not fit me. This is really affecting my performance and my ability to do this sport"?

+ +

DUSTIN: Yeah, I probably have too many of these stories. And what's interesting about that is I'm a pretty traditionally medium guy. I'm 5'11. I'm 170 pounds. Like, I should generally fit into mediums, but I'm just in that weird spot where I always kind of feel like, am I a medium or a large in this? My torso is a bit long. So, my primary sport is ski touring, like, backcountry skiing. That's what I love to do. That's where I spend my time and my focus and a lot of that kind of stuff.

+ +

So, I've had lots of experiences where I might be climbing up a [inaudible 03:08], and my jacket comes up a bit on my lower back and exposes my lower back, and it's cold. And so, then I got into defaulting where I wear, like, one-piece base layers, so I can never expose my skin directly. But it's like, the ultimate solution really was to have properly fitting stuff.

+ +

The original concept for MADE came from I was out on a ski tour with some friends, and I was wearing a pair of pants, some soft shell pants that I loved the fit of. But the feature set wasn't there, and they were, like, Alpine climbing pants. They're not even designed for ski touring. They didn't fit over my ski boot. They looked a little bit silly, but I loved the fit, like, in the leg. And they didn't have like, you know, a beacon pocket and those types of things that I would want.

+ +

But I do have this other pair of ski touring soft shell pants that I wear most of the time that fit terribly but have all the features that I want. And it was like, ah, man, I wish I could, like, determine exactly what I need as a skier and then, you know, would have the confidence that it was going to fit me perfectly, that sort of thing. And that's really where it kind of started. It was a very selfish, like, how can I get the thing that I want?

+ +

You know, I connected with my co-founders, both of whom came from Arc'teryx to start this with me. And we really got to thinking, and it's like, wow, with this type of system, we can make a really big impact as far as like, we can be 100% size-inclusive. There's not body shapes or sizes we can't meet with this type of system. And so, then it really opened a lot of doors as far as, like, what we can do and how we can connect this. And that's when we all kind of came together on this idea and said, like, "This matters, and we're the ones to build it."

+ +

VICTORIA: I love that you're trying to fit something that works for you, and you realize having that ability could make it inclusive for everyone. And I wonder if you could share more about what you know about sizing in the clothing industry and, how that's developed over time, and how it may be really limiting who has access to the products that you're selling and the activity that those products allow you to do.

+ +

DUSTIN: It might sound like a crappy, little history lesson, but, you know, the further back we go...before the industrial revolution, clothing was made to fit the individual, you know, you'd go to a tailor, and you'd tell them what you need the product to do for you, and they'd measure you and make the product. And then we got into this mass manufactured thing, which is great as far as, like, efficiencies and economies of scale, and all that kind of stuff. And so, we can get stuff cheaper and still, like, high-level product, but we got into this standardized system.

+ +

And then companies deal with this challenge of like, okay, what is our small? What is our medium? What is our large? And finding those things and trying to meet the needs of the bell curve but also knowing that for every individual person, they're not meeting that person's fit needs, right? They're trying to fit as many people within the primary sizes as they can, and that's part of the challenge.

+ +

One of the things that we've run into in performance product, especially, is that, like, there are massive swaths of people that simply cannot get good performance product in their size. 68% of North American women are over a size 14, and it's really hard to find good ski outerwear, as an example, for a plus-size individual like that. And that's not even that plus size. That's an average, like, that's 68%. Like, we're not talking about like, oh, these are the ends of the bell curve. These are people who want to get out and do things, and they've been unable to do it because of clothing.

+ +

What a silly reason to not be able to do the sport that you're excited about, or even to go spend time with your friends and family, or whatever it might be, like, your motivation, but, like, what a bummer of a reason to not be able to do it. So, those are the things we're trying to solve through our system is saying, like, "Hey, we can work with these existing brands, and they can now offer stuff that is fully inclusive, meets all of their quality expectations, all of this, and still comes in with a very reasonably priced product."

+ +

You know, it's not what you think custom would be where it's like, oh, it's going to be five times the cost of the ready-to-wear product. No, we can come in at the same price or very similar with these brands and allow them to make options that meet the needs of all different shapes and sizes.

+ +

VICTORIA: Well, I can really relate to that because some of the clothes that I would wear for climbing or even yoga are coming in at a very high price point already. And I recently tried on a set of clothing from a retailer who's normally, like, known for yoga and outdoors equipment. And I was just surprised at how it seemed that they wanted the person who fit these clothes to be very narrow all the way through [laughs]. And I was like, wow, I'm struggling to fit in these clothes.

+ +

And, like you said, like, I feel like I'm pretty average, and that was frustrating, and especially, like, getting clothes like that it can really deter people from participating in the sport and participating in outdoor activities altogether. So, I think it's really cool that you are going down that journey.

+ +

Let me ask you, how did you get the original idea for MADE TECH, specifically?

+ +

DUSTIN: So, first, we had to determine, is it possible? Can you make a system that would automate the creation of a custom pattern, all of that kind of stuff in really technical product, right? We know it can be done in suits and jeans and that sort of category that's more of a simple cut-and-sew. Whereas when you get into technical product where you're dealing with waterproof fabrics and seam sealing, you know, in a ski jacket, there's, like, 200 pieces of that product versus two pieces that get, like, pushed together and sewn between, right? Like, it's really, really complicated stuff.

+ +

So, we started with that kind of hypothesis is, yes, we can figure this out, and we did that under a D2C brand, MADE Outdoor. It's madeoutdoor.com. It's now been live for almost two winters, and we've made a bunch of product and a bunch of people happy. And, you know, we had some really early success with really tall, thin dudes, you know, like, that 6'6, you know, I'm sub 200 pounds or something. I'm really thin. And that person has been kind of forced into wearing a triple XL jacket for so long. So, they're pretty psyched. And so, like, we've had some of those early wins, and that was really kind of like, okay, we tested it. We've proven this system works.

+ +

And so, it's really just been in the last six months that we've said, like, okay, now where do we make the biggest impact? How do we make that change in the industry and in these opportunities to participate in these sports? And that's not through our own brand. That is one piece of it. Sure. But the larger opportunity is for us to work with existing brands that have that consumer trust already that, you know, like, "Oh yeah, I've worn this brand for however many years, and I have that trust, and I love the brand. And now I can get something that fits me perfectly."

+ +

Or it's that person that's like, "Oh, I've always worn this brand because it fits me, but I really would love to wear this other brand, but I know it doesn't fit me properly." And so, it opens doors for people to kind of like say like, "Okay, what's the brand? What are the materials? What's the brand ethos that really connects with me? And be able to go there and not have fit be the reason that I can go with one or the other."

+ +

VICTORIA: That's really interesting. So, you started with originally direct-to-consumer custom ski and snowboard wear and, found your initial success, and then identified a pivot point where you could expand and do direct business-to-business and make other brands more inclusive as well.

+ +

DUSTIN: Yeah, that's the big idea, right? And it doesn't need to be my name or our brand name on the thing. Like, what we've built, like, there's just an opportunity for an impact here that's bigger than just us.

+ +

VICTORIA: I love that. And it makes me want to ask you, what other core values drive your everyday decisions as you go about your process here?

+ +

DUSTIN: Yeah, the three kind of pillars we think about anytime we are working on something, and really that kind of drive our whole system at MADE, is inclusivity, sustainability, and personalization. I should come up with a better way to say that, but it's those three, right?

+ +

So, on the personal side, we want you to have the thing that you need. Your setup for some climbing clothing is going to be different than mine. You're going to want to set things up differently. And maybe you are a boulderer, and I am a big wall climber. Yeah, we have different needs for what we have. And so, we want you to be able to kind of define that rather than just being a designer in some boardroom somewhere. So, that's the personalization side.

+ +

The second is the sustainability side. 30%, and this sounds outrageous, but 30% of apparel is never sold to an end consumer. And it eventually gets destroyed or sent to the landfill, which obviously has a massive sustainability impact, not only for that product to how do you dispose of that kind of thing, but also just, like, we made it, and it took time, and it took money, and it took human hours and all that kind of stuff.

+ +

So, that's a huge opportunity for us because everything that is made through the MADE system it already has a home. Like, we never make a thing...if any of our brands are using our system, they only make things that already have a home. So, that's a huge win. We immediately take off that 30% of overproduction, right?

+ +

And then the inclusivity stuff we've talked about already, but it's like, we just want people to be able to do the things that makes them happy. And it's a bummer when you can't do those things, whether it's climbing, or yoga, or whatever. Like, you know, there are some big brands that have had a hard time with size inclusivity, which is totally understandable. It's really hard to make product that fits everybody.

+ +

And so, you know, we create these standardized systems, and then we knowingly leave people off. But we know that because it's like, well, not that many people in this size have bought from us, and we have to hit our MOQs, and we have to do X and Y and that sort of thing. But with this type of system, they can hit everybody, and they're not taking those, like, big risks as far as like, oh yeah, we have to set place this big order, and then all this product is going to sit in a warehouse for three years before it'll finally sell through.

+ +

VICTORIA: It reminds me of a classic story you hear in software design about how they tried to make the first Air Force pilot chair; I don't know if you've heard this one, where they, like, took all the measurements of all the pilots and then they, like, averaged out all the, like, heights and widths and everything. So, they made this chair that fit no one.

+ +

DUSTIN: Yeah [laughs].

+ +

VICTORIA: Because no one is perfectly average. Like, you know, everyone has variations in their size and their measurements. And so, I think that's really cool. It's interesting. I hadn't thought about the conservation impact or the impact on the environment; it takes just to have to have so much error in your sizing, which is naturally part of what's going to happen when you try to make an average size.

+ +

DUSTIN: I've not been on the product design side of apparel. I don't envy them. Like, their job is hard to find that fit story that, okay, this is what the average consumer looks like. But what does our consumer look like, and then how do we find something that meets them? And what is our medium? And then, do we have to make a different medium for different markets in the world? And there's so much, like, level of detail in there.

+ +

That's one of the beauties of us working with other brands now is that, like, their level of knowledge in that stuff is huge. And so, pulling from that and being able to say like, "For your product, how should this jacket fit somebody? How do you want it to move?" So, then, when our system pulls in the 3D measurements of that individual, it can say like, "Okay, this jacket needs to sit this far off of the shoulder. It needs to have this much room around the bicep." Like, those types of things are all part of how it works and gives those opportunities for, like, an individualized fit that is determined by how the brand wants it to perform.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at tbot.io/devops.

+ +

VICTORIA: How did you go about, like, what was your first step when you said, "Oh, I need a system to do this type of automation and to be able to do this kind of customization"? How did you approach solving that problem?

+ +

DUSTIN: Well, we started to figure it out, and we realized that the system didn't exist [laughs]. So, that's really what it was. It was out of necessity more than anything. So, we wanted to build our custom and made-to-measure brand, and none of the systems existed to do it. So, we got to work on building those systems. You know, that was, over the last year, it's like, okay, we built all these systems. Do we just use them for ourselves, or can we have that bigger impact if we work with other brands?

+ +

VICTORIA: So, did you have the skills to build the technology already in-house, or did you have to develop that within your company?

+ +

DUSTIN: Oh, man. So, my co-founders are amazing. I started this with two co-founders, Cheryl LeBarr and Capri Philip, both came from Arc'teryx to start this with me. Arc'teryx, if people don't know, is one of the big outerwear brands in the outdoor space, a beautiful, beautiful product. They understand fit and, form and function, and they make an amazing product. And I have connections over there, and so I made a few phone calls and really, like, found the right people.

+ +

So, we got to work on it. None of us are coders. We kind of scrambled through our MVP. We figured out how we could do it with...if you look at our MVP backend, it's messy, like every startup's MVP is. And it's like, okay, this system is connecting to this system over here, and it's talking to this. And it's sending this data from here and that sort of thing. And it's like, but we figured it out, and that was the key.

+ +

You know, so the automation of this stuff really came from the pattern design side, which was Capri's specialty. And then the automation of the, like, tech pack and all of the factory details that they need to produce the garment came from Cheryl's side, from the product development side. And mine was more on the brand and kind of communication of the value and that sort of thing. We were scrappy. And we figured out how to build something that worked.

+ +

And then the next step was to bring on a proper CTO and then really build the, like, scalable system that's like, okay, now it can plug into existing systems. And, oh, you have these expectations of your enterprise-level software. Yes, this is how it works, that sort of thing. So, it's been tiered in that way. And that, honestly, is part of the fun. Like, part of the fun is finding these new problems to solve and then coming up with creative ways to solve them.

+ +

VICTORIA: That's really cool. So, you all were able to build your MVP together within your existing co-founding team. I'm curious about, like, what platforms you chose to do that in. Did you pick, like, a programming language or some sort of, like, ClickOps or some kind of, like, other tool that you could use, like low-code tool, to develop it at first?

+ +

DUSTIN: I mean, it's very low code. It's Google Docs, Google Sheets that speak to each other and, like, can share data between them kind of thing within our secret backend, obviously. We have a really great relationship with our measurement partner. We didn't build the measurement technology. That's a whole different business model and that sort of thing. So, we work with this great group called 3DLOOK that does our measurements, and it just uses a customer's phone to take a front and a side photo, and then we get a full 3D model that goes into our thing. It's super cool.

+ +

We tried to pull some things off the shelf that existed that we could use without having to build it ourselves. With my agency business, like, I have a developer that I work with a lot. And so, like, we called on them to help us build a few pieces, but for the most part, it really was just, like, getting scrappy and creative together. And, like, we built the MADE Outdoor platform on Shopify. It's like all these systems that are just kind of like, yeah, we know how these systems work. Let's use those to start, and then if it works, then we build it into a bigger framework.

+ +

VICTORIA: I'm glad you mentioned that there's take a picture because I was going to say, whenever I even have to do, like, a sizing guide chart on a website to buy clothes and you have to, like, measure your waist, I'm like, I don't want to do that [laughs]. I'm just, like, too lazy. I don't want to check that right now. So, taking a picture would be so much easier.

+ +

DUSTIN: People are so bad at that [laughs]. Like, when we first got started, and we were asking people to send in their measurements, and here's a video on how to do it, even the same person, like, with three different people measuring them, you'd get wildly different information. And so, we definitely knew early on, okay, we need to eliminate the human error aspect and get this as digital as possible. So, that's where we found the right partner. And it really is, it's, like, a two-minute thing.

+ +

You stand in front of your phone. It takes photos. The photos aren't even saved anywhere, like; they're AI, like, looks at the photos and then gives us the model. We're not sitting on a bunch of pictures of people in their base layers and underwear or anything like that. It's like, all of this is just kind of like, we have your 3D model, and now we can build the product, and we can even do digital test fits on that person, your actual body, before it even gets made, and stuff.

+ +

So, we have systems for redundancy and everything that we can test everything. And that's just the beauty of, like, the modern technology that exists. Like, we didn't build that either, but we are using the heck out of it to make sure that we can make the best product for people.

+ +

VICTORIA: That's really cool. I love that. So, you've maybe answered this question already a little bit, but was there anything else in your product discovery process, and especially as you shifted into marketing directly to businesses, anything that was in your discovery process that surprised you and had you pivot in your strategy?

+ +

DUSTIN: You know, you start with your own experience, right? So, we are sitting in our meetings, and it's like, oh man, here's all the products we want to make. And we're like, we've got this list of 40 things that we want. Oh, I need soft-shell pants. And we started in hard shell for our own brand. So, then it's like, "I live in the Wasatch. I don't wear hard shell, like, while I'm ski touring, at least. Like, I need soft shell." And then it's like, okay, well, let's start working on soft shell stuff.

+ +

Then it's like, okay, we also need mid-layers, and we need base layers. And then we need mountain bike, and we need trail run, and we need climbing, and we need hiking. And it's like, oh man, you know what would be easier? If we just worked with, like, one of the or all of the big brands in this space. And there's some really great examples of, like, smaller companies that have created really compelling systems to work with these brands, like the same group that does the secondary market stuff, so the Worn Wear program for Patagonia and the ReGear thing for Arc'teryx.

+ +

And they built that same structure for, like, two dozen different brands. And it's like, man, that is the model for us. That's where we can really connect is they've created so much value in the secondary market, and we've created a bunch of value in this custom and made-to-measure market. That's what we want to do. And we want motocross...like, the MADE brand isn't going to make motocross stuff. The MADE brand isn't going to make fly fishing necessarily. But we want these markets and these people to be able to have that solution. And we also, like, we're early in the space.

+ +

Like, we want them to use us rather than, like, take the time and money and everything to build it themselves. Like, come to us, like, that's our whole idea. We want to have that bigger, larger impact. So, I guess it's us just trying to say like, "What do we want?" And we're users. We know the market. How do we get there the fastest? And how do we have that impact quicker than just necessarily, like, okay, well, in 25 years, we'll have all those products that we want?

+ +

VICTORIA: Yeah, yeah, I could see that, how it went from, well, yeah, I would want this for every product, and then you're like, well, I can't build every product [laughs]. So, I like that pivot in your strategy. And what challenges do you see in being able to make that impact as quickly as you want?

+ +

DUSTIN: One of our biggest challenges right now, I think, is that this is a totally new idea in this space. Nobody's done this in this space. Like, in suiting, custom suits have been a thing for a long time, and it used to just be for rich people. And now because of, like, modern technology and stuff, it's become more approachable. Awesome. That's great. And so, like, in that kind of category, people are more used to the idea of, like, yeah, I place an order, and it takes time, and they make a thing, and then it comes to me.

+ +

Whereas with outdoor apparel and sports apparel and that sort of stuff, you go to your local shop. You try on six different things, and you walk out with the one that meets your needs the best. That's what people are used to. So, it's a little bit of a shift in the thought process. You know, we've had our early adopters, and now we're kind of moving into more people who are like, "Okay, I get it now." And so, we're seeing more of that where it's like, yes, if I give some time, then I really see the value of having something that fits me perfectly.

+ +

And in the MADE Outdoor brand, it's not an inexpensive product. We make a really premium hard shell product. Now, it's comparable in price to the other brands that make comparably featured and whatever product, but still, you're spending money, and you want something that's going to last for a while. And so, to have that perfect fit, to have that perfect feature set, to know that when I ski, I totally need a left chest pocket, and I don't need a right chest pocket, whatever it might be, like, your details, that matters, right?

+ +

So, that's probably our biggest challenge right now. That's not an unsolvable problem. We can manage that. We can get the communication out. And especially as we're onboarding these existing brands, that gives us the opportunity to have a much larger mouthpiece and be able to kind of say like, "Hey, this exists, and you should care." Yes, it's going to be amazing for individuals who have traditionally been off-size. But it's also amazing for you people who think you've always been just, "Yeah, I'm a medium, and everything fits me just fine." You'd be surprised.

+ +

Like, having something that fits you perfectly is a different world, and the ability to then move in that sport and, like, be able to do your thing, it's like, oh yeah, I guess that, like, extra fabric in my shoulders was kind of, like, limiting my movement while ice climbing or, you know, oh yeah, my sleeves were always coming up while I was climbing, or whatever it might be. Like, there's things that I think people will really kind of be psyched about when they start to experience that custom aspect of it.

+ +

VICTORIA: Yeah. I can speak to some of that, too, as, like, a climber. And you mentioned it even when you talked earlier about, well, if you're bouldering at the gym, that's a totally different experience than if you're out all day on a multi-pitch, and you're on the wall, and you're, you know, you're vertical for, like, six hours of the day [laughs]. And I think it's really interesting to be able to provide that customization.

+ +

And how are you defining success for the company? So, you just made this pivot about six months ago. Did you immediately create some goals that you wanted to achieve in three months, six months, or five years?

+ +

DUSTIN: Yeah, I mean, we have our, like, target, our sales targets and stuff that we are looking at as far as we want these many brands on board this year. And we want to bring on like, you know, as I step back a little bit, as, like, the bigger thoughts behind the company, that's more of, like, where we're trying to target multiple different categories at the same time. So, like, if we can get one big outdoor brand, great, that's what we want to do.

+ +

Now, we want all the outdoor brands. We totally want them all. But if we can just get one, then we're going to have a start of an impact in the outdoor sector. Then we want the motocross brand, and we want to be able to make the impact in that sector. And we want the fly fishing brand, and we want the yoga brand, and we want the traditional, like, team sports brands and those types of things.

+ +

Like, we want to kind of, like, spread and have an impact across categories and as kind of a first attack. And then to really kind of go from there and say like, "Okay, now let's build out, like, oh, fly fishing really is connecting with this, or the yoga community is loving the, like, idea of a really custom fit product." So, like, those types of things are where we can kind of go from there.

+ +

But as we begin, it's really like, can we make an impact across these different categories? And those are a lot of our goals as we start out. It's like, how can we connect with surf? How can we connect with hike? How can we, you know, like, and it's just looking at each of these little categories because we know there's people being stuck that can't get out in each of those things, and we know we can help. But we're not going to design the product personally. So, how can we make that impact with the right partners?

+ +

VICTORIA: Oh, that's great. And I'm even thinking about surfing and getting a wetsuit. And there's just so few women wetsuits, period, in the store. And it's very limited in range and can be really challenging. And I took a friend surfing last year and did not enjoy that process. She did not like it [laughter]. She liked the surfing part, but the getting the wetsuit on and trying them on was not great [laughs].

+ +

DUSTIN: I can only imagine, yeah. And there's some really cool, like, in surf, there are some great small brands, like, new brands that are doing custom fit. I don't know their systems. I don't know if it's an automated process or if it's a manual process, but the reality is it's not readily available enough to the general public. And that's where it's like, oh man, our system makes it readily available.

+ +

And so, then it's like a simple kind of like, okay, I go online. I fill in this information. I decide, do I want a hood on my wetsuit? Do I not want a hood? Do I want this kind of entry? Do I want...Like, you decide the details that you want, and then the product is made for you. That's the beauty of it, right?

+ +

VICTORIA: Yeah. And I'm curious to kind of get back to marketing to existing businesses because you not only have to sell them on this is the art of the possible. Here's, like, what you could do to get the same performance with these custom measurements of your existing high-performing apparel. But you also have to encounter this change management process where they have a way of doing things. You'd be a new product. They'd have to figure out how to change up all their operations. So, I'm curious: what's your strategy for getting involved in that and working through it?

+ +

DUSTIN: Oh man, some of these companies are giant ships with tiny rudders, right? So, to get them to shift any direction or the other is tricky. A lot of our current sales pipeline is more medium-sized brands that have a little bit more of a nimble; yeah, we can jump on this. But one advantage we have is that some of these categories do have some custom programs, like I mentioned, the custom wetsuit stuff, like, that is in the market. So, like, wetsuit companies are aware that this needs to exist. Fly fishing waders: there are some custom fly fishing waders, now, not necessarily made-to-measure, but you don't make them in a 4XL or something. You could order a 4XL from a certain company.

+ +

So, like, there are systems like that. So, they've actually already kind of figured out the manufacturing side, which is one of the challenges of it that we can help the brands figure out those details because we've done it, and we know how to, like, take advantage of the efficiencies that they have in place with their current supply chain, or they can use our supply chain that we've built out. So, it depends. But that is one of the challenges is to get them to just kind of commit to say like, "Yes, this is worth putting in the time."

+ +

So, we do have...actually, the secondary market company I mentioned earlier, the way that they do it is it's, like, a separate site. And so, it's not run through their existing site. And so, they get around some of the ways of not necessarily having to be tied directly into a lot of their internal systems, and it's run as, like, a secondary system. Like, there are guitar manufacturers that make custom that they don't even produce them. They basically license out their shapes and stuff to custom builders.

+ +

So, we're trying to take a lot of the learnings from these other categories that do something kind of similar to what we're doing and learn from them and say like, "Okay, that's one approach we could take, or that's an approach we could take."

+ +

And then, really, we're going to the sales conversations with those brands and saying, "What do you need? Because we can be flexible." We're the opposite of the giant ship with a tiny rudder. We're that tiny, little motorboat that can, you know, like, spin circles and stuff. Like, we can do whatever is really needed at this point for these brands to be able to tie into them. So, we are flexible, and we try to learn as much from them as possible to be able to build the right solution.

+ +

VICTORIA: Yeah, I think that is the draw of you get your foot in the door with the middle businesses, and you can prove out that it works, and then maybe eventually the bigger brands start to take notice and pick it up as well. But it is going to take time. That's really cool. I think it provides that, you know, for those mid-size businesses, it gives them an advantage that a larger enterprise wouldn't be able to offer.

+ +

DUSTIN: Yeah, no, I think, at first, especially, like, the idea to be kind of first to market-ish with something totally new and exciting and to create that brand value with their customer in a way that they haven't been able to before.

+ +

VICTORIA: Right. And you mentioned fly fishing a few times, and I feel like it's one of those sports that I've done it when I was, like, really small, like, maybe with my grandfather, like, fishing in the river. And as I get older, I'm like, it does sound nice.

+ +

DUSTIN: Right? [laughs]

+ +

VICTORIA: Like, sitting alone in, like, a beautiful place. Like, maybe you get a fish, maybe you don't. I think I like the idea of it more than the reality of it, but will try it out some...I have enough other sports [inaudible 33:02].

+ +

DUSTIN: I think you'd be psyched if you gave it a shot. Like, fly fishing is something that, like, if you like being outside, it's something else. There's a beauty to it, for sure. And there's a beauty to all of these sports. And, honestly, if people are being active, whatever it is that you're doing, good for you. And that's part of it is, like, we are trying to be as sport agnostic as we can in all of this because, yeah, we don't care if you are a diehard snowmobiler, right? Amazing. Great. Let's get you some product that fits so you can get out and do your diehard thing.

+ +

Or, you know, maybe you're a mountain biker or a road cyclist, or, like, you know, there's so many things that we wear clothing that we hope allows us to perform in that sport, and yet so much of it is holding us back, even maybe to a degree that we don't even know. Professional athletes and stuff, much of their product is made-to-measure. Olympic speed skaters, like, it's not like they had to just choose a medium or a large type of product. Like, it's made to fit their body so that they can perform at their pinnacle level. That's awesome.

+ +

Where that stops is in the, like, general consumer, and, like, I want to get out and do my sport. It's not about being the best at this thing. It's just about being my best at this thing and having the most fun that I want to have in it. The fit and the details of your product matter just as much as it does for the Olympian as far as I'm concerned.

+ +

VICTORIA: Absolutely. And it reminds me of a story that happened to me. I was climbing in this very popular pant that is known as their climbing pant from this particular brand. And it was maybe the fifth time I'd worn these pants and just ripped the inseam while climbing.

+ +

DUSTIN: [laughs]

+ +

VICTORIA: You know, lucky it wasn't that cold that day or anything, but it's just [inaudible 34:50]

+ +

DUSTIN: Your belayer got a kick out of it, I'm sure.

+ +

VICTORIA: Yeah, there was a layer to this, right? Yeah.

+ +

DUSTIN: [laughs]

+ +

VICTORIA: And I've heard that happens to lots of climbers who wear those same pants. Like, they're known for that because it's really hard to get that measurement right, especially with that kind of material, which was great. It's like this material that was supposed to not rip, right? [laughter] [inaudible 35:09] what is this? Yeah. Maybe I do want to go outside, and I want to go fly fishing, or I want to go skiing or snowboarding, but, oh, they don't even have pants in my size. Like, I'm not even going to try. And that's really demoralizing. So, I think it's great to be working on that problem.

+ +

Oh, wonderful. Thank you so much for joining. Is there anything else that you would like to promote today?

+ +

DUSTIN: No, I mean, I think I love having these conversations, and chatting with you has been so great. It's fun to talk about what we're working on and to, you know, get the word out a bit more. There's not really other things to promote other than, like, you know, if you're a smaller or medium-sized or a large apparel brand hearing this, like, please reach out to me. I want to talk to you.

+ +

We've built a system that really can help both the brand and the customer. It helps the brand with revenue and with margins and reduced waste and all of these things, but it also just helps the customer have a better product and a better experience. And ultimately, that's, in theory, what we are trying to do when we make product. So yeah, that's my focus, and that's what I want to talk to everybody I can about right now.

+ +

VICTORIA: I love that. Thank you so much for sharing your story and for coming on the show today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido interviews Dustin Butcher, CEO and Co-Founder of MADE TECH, a company revolutionizing the performance apparel industry through custom and made-to-measure automation technology. Dustin shares his journey from working in the outdoor industry and running a creative agency to founding MADE TECH. The company's mission is to provide performance apparel that perfectly fits the wearer's body, addressing a common issue where standard sizes fail to accommodate individual body shapes and sizes, particularly in sports where fit and movement are crucial.

+ +

Dustin discusses the inspiration behind MADE TECH, which stemmed from personal experiences with ill-fitting outdoor apparel during activities like ski touring. He highlights the company's focus on inclusivity, allowing for 100% size inclusivity and addressing the needs of a broad spectrum of body shapes and sizes. This initiative caters to individuals who traditionally struggle to find performance gear that fits and opens the door for brands to offer more inclusive product lines. Dustin's background in the outdoor industry and encounters with the limitations of standard sizing in apparel led to the development of a technology-driven solution that customizes clothing to the individual's measurements, enhancing performance and comfort.

+ +

The conversation also touches on the industry's broader implications of custom and made-to-measure apparel, including sustainability and waste reduction. Dustin elaborates on MADE TECH's business model, which initially targeted direct-to-consumer sales but has pivoted towards partnering with established brands to offer custom-fit options. This strategic shift aims to leverage brand trust and reach a wider audience, promoting inclusivity and personalization in the performance apparel market.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

 VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dustin Butcher, CEO and Co-Founder of MADE TECH, powering the future of performance apparel with custom and made-to-measure automation. Dustin, thank you for joining me.

+ +

DUSTIN: Oh, thank you so much for having me, and I'm excited to be here.

+ +

VICTORIA: Wonderful. Yeah. So, why don't you just introduce yourself a little bit more and tell me about your background?

+ +

DUSTIN: Yeah, of course. So, as you mentioned, I'm one of the co-founders of MADE. We have built technology that enables the automation of custom and made-to-measure performance apparel. So, similar to how you could, like, you know, go online and design a custom suit or something like that and get it made to fit your body, we do that for performance apparel so that the product that really matters if it fits you properly and that sort of thing, and, you know, so that might be outdoor apparel, motocross, yoga. Whatever sport it is that you're into that, you need your apparel to move with you; that's what we fuel. And so, we're working with a bunch of different brands in that space to do that.

+ +

My background, I came from the outdoor industry; always been in the outdoor industry since I was able to hold a job, originally just at ski resorts and stuff as a lifty and as a waiter, and all those types of classic, you know, teenage jobs. And then I worked in-house at a bunch of outdoor companies, Voilé, a little backcountry ski company here in Salt Lake, and then Black Diamond, and Gregory Packs, and Petzl, and kind of worked around the industry a bit.

+ +

And then for the last 12 years, I ran a creative agency, specifically in the outdoor industry, working with a lot of those same brands and other brands in kind of communicating their value to the outdoor customer. And so, and then we kind of rolled into MADE, had this idea, connected with my co-founders, and really built it from there.

+ +

VICTORIA: I love hearing about people building careers in the outdoor industry, something really close to me personally. I also got my first few jobs from rock climbing and having competed as a young adult and then walking up to businesses and saying, "Hey, you have a climbing wall. Like, you should hire me, and I'll run your climbing wall." And they're like, "Okay." [laughs] So, it just, like, brings you so much confidence and such a great community to be a part of.

+ +

And so, you're talking about creating clothes that move with you. Can you tell me a time when you were doing something, some kind of performance sport activity, and you were like, "Wow, whatever I'm wearing does not fit me. This is really affecting my performance and my ability to do this sport"?

+ +

DUSTIN: Yeah, I probably have too many of these stories. And what's interesting about that is I'm a pretty traditionally medium guy. I'm 5'11. I'm 170 pounds. Like, I should generally fit into mediums, but I'm just in that weird spot where I always kind of feel like, am I a medium or a large in this? My torso is a bit long. So, my primary sport is ski touring, like, backcountry skiing. That's what I love to do. That's where I spend my time and my focus and a lot of that kind of stuff.

+ +

So, I've had lots of experiences where I might be climbing up a [inaudible 03:08], and my jacket comes up a bit on my lower back and exposes my lower back, and it's cold. And so, then I got into defaulting where I wear, like, one-piece base layers, so I can never expose my skin directly. But it's like, the ultimate solution really was to have properly fitting stuff.

+ +

The original concept for MADE came from I was out on a ski tour with some friends, and I was wearing a pair of pants, some soft shell pants that I loved the fit of. But the feature set wasn't there, and they were, like, Alpine climbing pants. They're not even designed for ski touring. They didn't fit over my ski boot. They looked a little bit silly, but I loved the fit, like, in the leg. And they didn't have like, you know, a beacon pocket and those types of things that I would want.

+ +

But I do have this other pair of ski touring soft shell pants that I wear most of the time that fit terribly but have all the features that I want. And it was like, ah, man, I wish I could, like, determine exactly what I need as a skier and then, you know, would have the confidence that it was going to fit me perfectly, that sort of thing. And that's really where it kind of started. It was a very selfish, like, how can I get the thing that I want?

+ +

You know, I connected with my co-founders, both of whom came from Arc'teryx to start this with me. And we really got to thinking, and it's like, wow, with this type of system, we can make a really big impact as far as like, we can be 100% size-inclusive. There's not body shapes or sizes we can't meet with this type of system. And so, then it really opened a lot of doors as far as, like, what we can do and how we can connect this. And that's when we all kind of came together on this idea and said, like, "This matters, and we're the ones to build it."

+ +

VICTORIA: I love that you're trying to fit something that works for you, and you realize having that ability could make it inclusive for everyone. And I wonder if you could share more about what you know about sizing in the clothing industry and, how that's developed over time, and how it may be really limiting who has access to the products that you're selling and the activity that those products allow you to do.

+ +

DUSTIN: It might sound like a crappy, little history lesson, but, you know, the further back we go...before the industrial revolution, clothing was made to fit the individual, you know, you'd go to a tailor, and you'd tell them what you need the product to do for you, and they'd measure you and make the product. And then we got into this mass manufactured thing, which is great as far as, like, efficiencies and economies of scale, and all that kind of stuff. And so, we can get stuff cheaper and still, like, high-level product, but we got into this standardized system.

+ +

And then companies deal with this challenge of like, okay, what is our small? What is our medium? What is our large? And finding those things and trying to meet the needs of the bell curve but also knowing that for every individual person, they're not meeting that person's fit needs, right? They're trying to fit as many people within the primary sizes as they can, and that's part of the challenge.

+ +

One of the things that we've run into in performance product, especially, is that, like, there are massive swaths of people that simply cannot get good performance product in their size. 68% of North American women are over a size 14, and it's really hard to find good ski outerwear, as an example, for a plus-size individual like that. And that's not even that plus size. That's an average, like, that's 68%. Like, we're not talking about like, oh, these are the ends of the bell curve. These are people who want to get out and do things, and they've been unable to do it because of clothing.

+ +

What a silly reason to not be able to do the sport that you're excited about, or even to go spend time with your friends and family, or whatever it might be, like, your motivation, but, like, what a bummer of a reason to not be able to do it. So, those are the things we're trying to solve through our system is saying, like, "Hey, we can work with these existing brands, and they can now offer stuff that is fully inclusive, meets all of their quality expectations, all of this, and still comes in with a very reasonably priced product."

+ +

You know, it's not what you think custom would be where it's like, oh, it's going to be five times the cost of the ready-to-wear product. No, we can come in at the same price or very similar with these brands and allow them to make options that meet the needs of all different shapes and sizes.

+ +

VICTORIA: Well, I can really relate to that because some of the clothes that I would wear for climbing or even yoga are coming in at a very high price point already. And I recently tried on a set of clothing from a retailer who's normally, like, known for yoga and outdoors equipment. And I was just surprised at how it seemed that they wanted the person who fit these clothes to be very narrow all the way through [laughs]. And I was like, wow, I'm struggling to fit in these clothes.

+ +

And, like you said, like, I feel like I'm pretty average, and that was frustrating, and especially, like, getting clothes like that it can really deter people from participating in the sport and participating in outdoor activities altogether. So, I think it's really cool that you are going down that journey.

+ +

Let me ask you, how did you get the original idea for MADE TECH, specifically?

+ +

DUSTIN: So, first, we had to determine, is it possible? Can you make a system that would automate the creation of a custom pattern, all of that kind of stuff in really technical product, right? We know it can be done in suits and jeans and that sort of category that's more of a simple cut-and-sew. Whereas when you get into technical product where you're dealing with waterproof fabrics and seam sealing, you know, in a ski jacket, there's, like, 200 pieces of that product versus two pieces that get, like, pushed together and sewn between, right? Like, it's really, really complicated stuff.

+ +

So, we started with that kind of hypothesis is, yes, we can figure this out, and we did that under a D2C brand, MADE Outdoor. It's madeoutdoor.com. It's now been live for almost two winters, and we've made a bunch of product and a bunch of people happy. And, you know, we had some really early success with really tall, thin dudes, you know, like, that 6'6, you know, I'm sub 200 pounds or something. I'm really thin. And that person has been kind of forced into wearing a triple XL jacket for so long. So, they're pretty psyched. And so, like, we've had some of those early wins, and that was really kind of like, okay, we tested it. We've proven this system works.

+ +

And so, it's really just been in the last six months that we've said, like, okay, now where do we make the biggest impact? How do we make that change in the industry and in these opportunities to participate in these sports? And that's not through our own brand. That is one piece of it. Sure. But the larger opportunity is for us to work with existing brands that have that consumer trust already that, you know, like, "Oh yeah, I've worn this brand for however many years, and I have that trust, and I love the brand. And now I can get something that fits me perfectly."

+ +

Or it's that person that's like, "Oh, I've always worn this brand because it fits me, but I really would love to wear this other brand, but I know it doesn't fit me properly." And so, it opens doors for people to kind of like say like, "Okay, what's the brand? What are the materials? What's the brand ethos that really connects with me? And be able to go there and not have fit be the reason that I can go with one or the other."

+ +

VICTORIA: That's really interesting. So, you started with originally direct-to-consumer custom ski and snowboard wear and, found your initial success, and then identified a pivot point where you could expand and do direct business-to-business and make other brands more inclusive as well.

+ +

DUSTIN: Yeah, that's the big idea, right? And it doesn't need to be my name or our brand name on the thing. Like, what we've built, like, there's just an opportunity for an impact here that's bigger than just us.

+ +

VICTORIA: I love that. And it makes me want to ask you, what other core values drive your everyday decisions as you go about your process here?

+ +

DUSTIN: Yeah, the three kind of pillars we think about anytime we are working on something, and really that kind of drive our whole system at MADE, is inclusivity, sustainability, and personalization. I should come up with a better way to say that, but it's those three, right?

+ +

So, on the personal side, we want you to have the thing that you need. Your setup for some climbing clothing is going to be different than mine. You're going to want to set things up differently. And maybe you are a boulderer, and I am a big wall climber. Yeah, we have different needs for what we have. And so, we want you to be able to kind of define that rather than just being a designer in some boardroom somewhere. So, that's the personalization side.

+ +

The second is the sustainability side. 30%, and this sounds outrageous, but 30% of apparel is never sold to an end consumer. And it eventually gets destroyed or sent to the landfill, which obviously has a massive sustainability impact, not only for that product to how do you dispose of that kind of thing, but also just, like, we made it, and it took time, and it took money, and it took human hours and all that kind of stuff.

+ +

So, that's a huge opportunity for us because everything that is made through the MADE system it already has a home. Like, we never make a thing...if any of our brands are using our system, they only make things that already have a home. So, that's a huge win. We immediately take off that 30% of overproduction, right?

+ +

And then the inclusivity stuff we've talked about already, but it's like, we just want people to be able to do the things that makes them happy. And it's a bummer when you can't do those things, whether it's climbing, or yoga, or whatever. Like, you know, there are some big brands that have had a hard time with size inclusivity, which is totally understandable. It's really hard to make product that fits everybody.

+ +

And so, you know, we create these standardized systems, and then we knowingly leave people off. But we know that because it's like, well, not that many people in this size have bought from us, and we have to hit our MOQs, and we have to do X and Y and that sort of thing. But with this type of system, they can hit everybody, and they're not taking those, like, big risks as far as like, oh yeah, we have to set place this big order, and then all this product is going to sit in a warehouse for three years before it'll finally sell through.

+ +

VICTORIA: It reminds me of a classic story you hear in software design about how they tried to make the first Air Force pilot chair; I don't know if you've heard this one, where they, like, took all the measurements of all the pilots and then they, like, averaged out all the, like, heights and widths and everything. So, they made this chair that fit no one.

+ +

DUSTIN: Yeah [laughs].

+ +

VICTORIA: Because no one is perfectly average. Like, you know, everyone has variations in their size and their measurements. And so, I think that's really cool. It's interesting. I hadn't thought about the conservation impact or the impact on the environment; it takes just to have to have so much error in your sizing, which is naturally part of what's going to happen when you try to make an average size.

+ +

DUSTIN: I've not been on the product design side of apparel. I don't envy them. Like, their job is hard to find that fit story that, okay, this is what the average consumer looks like. But what does our consumer look like, and then how do we find something that meets them? And what is our medium? And then, do we have to make a different medium for different markets in the world? And there's so much, like, level of detail in there.

+ +

That's one of the beauties of us working with other brands now is that, like, their level of knowledge in that stuff is huge. And so, pulling from that and being able to say like, "For your product, how should this jacket fit somebody? How do you want it to move?" So, then, when our system pulls in the 3D measurements of that individual, it can say like, "Okay, this jacket needs to sit this far off of the shoulder. It needs to have this much room around the bicep." Like, those types of things are all part of how it works and gives those opportunities for, like, an individualized fit that is determined by how the brand wants it to perform.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at tbot.io/devops.

+ +

VICTORIA: How did you go about, like, what was your first step when you said, "Oh, I need a system to do this type of automation and to be able to do this kind of customization"? How did you approach solving that problem?

+ +

DUSTIN: Well, we started to figure it out, and we realized that the system didn't exist [laughs]. So, that's really what it was. It was out of necessity more than anything. So, we wanted to build our custom and made-to-measure brand, and none of the systems existed to do it. So, we got to work on building those systems. You know, that was, over the last year, it's like, okay, we built all these systems. Do we just use them for ourselves, or can we have that bigger impact if we work with other brands?

+ +

VICTORIA: So, did you have the skills to build the technology already in-house, or did you have to develop that within your company?

+ +

DUSTIN: Oh, man. So, my co-founders are amazing. I started this with two co-founders, Cheryl LeBarr and Capri Philip, both came from Arc'teryx to start this with me. Arc'teryx, if people don't know, is one of the big outerwear brands in the outdoor space, a beautiful, beautiful product. They understand fit and, form and function, and they make an amazing product. And I have connections over there, and so I made a few phone calls and really, like, found the right people.

+ +

So, we got to work on it. None of us are coders. We kind of scrambled through our MVP. We figured out how we could do it with...if you look at our MVP backend, it's messy, like every startup's MVP is. And it's like, okay, this system is connecting to this system over here, and it's talking to this. And it's sending this data from here and that sort of thing. And it's like, but we figured it out, and that was the key.

+ +

You know, so the automation of this stuff really came from the pattern design side, which was Capri's specialty. And then the automation of the, like, tech pack and all of the factory details that they need to produce the garment came from Cheryl's side, from the product development side. And mine was more on the brand and kind of communication of the value and that sort of thing. We were scrappy. And we figured out how to build something that worked.

+ +

And then the next step was to bring on a proper CTO and then really build the, like, scalable system that's like, okay, now it can plug into existing systems. And, oh, you have these expectations of your enterprise-level software. Yes, this is how it works, that sort of thing. So, it's been tiered in that way. And that, honestly, is part of the fun. Like, part of the fun is finding these new problems to solve and then coming up with creative ways to solve them.

+ +

VICTORIA: That's really cool. So, you all were able to build your MVP together within your existing co-founding team. I'm curious about, like, what platforms you chose to do that in. Did you pick, like, a programming language or some sort of, like, ClickOps or some kind of, like, other tool that you could use, like low-code tool, to develop it at first?

+ +

DUSTIN: I mean, it's very low code. It's Google Docs, Google Sheets that speak to each other and, like, can share data between them kind of thing within our secret backend, obviously. We have a really great relationship with our measurement partner. We didn't build the measurement technology. That's a whole different business model and that sort of thing. So, we work with this great group called 3DLOOK that does our measurements, and it just uses a customer's phone to take a front and a side photo, and then we get a full 3D model that goes into our thing. It's super cool.

+ +

We tried to pull some things off the shelf that existed that we could use without having to build it ourselves. With my agency business, like, I have a developer that I work with a lot. And so, like, we called on them to help us build a few pieces, but for the most part, it really was just, like, getting scrappy and creative together. And, like, we built the MADE Outdoor platform on Shopify. It's like all these systems that are just kind of like, yeah, we know how these systems work. Let's use those to start, and then if it works, then we build it into a bigger framework.

+ +

VICTORIA: I'm glad you mentioned that there's take a picture because I was going to say, whenever I even have to do, like, a sizing guide chart on a website to buy clothes and you have to, like, measure your waist, I'm like, I don't want to do that [laughs]. I'm just, like, too lazy. I don't want to check that right now. So, taking a picture would be so much easier.

+ +

DUSTIN: People are so bad at that [laughs]. Like, when we first got started, and we were asking people to send in their measurements, and here's a video on how to do it, even the same person, like, with three different people measuring them, you'd get wildly different information. And so, we definitely knew early on, okay, we need to eliminate the human error aspect and get this as digital as possible. So, that's where we found the right partner. And it really is, it's, like, a two-minute thing.

+ +

You stand in front of your phone. It takes photos. The photos aren't even saved anywhere, like; they're AI, like, looks at the photos and then gives us the model. We're not sitting on a bunch of pictures of people in their base layers and underwear or anything like that. It's like, all of this is just kind of like, we have your 3D model, and now we can build the product, and we can even do digital test fits on that person, your actual body, before it even gets made, and stuff.

+ +

So, we have systems for redundancy and everything that we can test everything. And that's just the beauty of, like, the modern technology that exists. Like, we didn't build that either, but we are using the heck out of it to make sure that we can make the best product for people.

+ +

VICTORIA: That's really cool. I love that. So, you've maybe answered this question already a little bit, but was there anything else in your product discovery process, and especially as you shifted into marketing directly to businesses, anything that was in your discovery process that surprised you and had you pivot in your strategy?

+ +

DUSTIN: You know, you start with your own experience, right? So, we are sitting in our meetings, and it's like, oh man, here's all the products we want to make. And we're like, we've got this list of 40 things that we want. Oh, I need soft-shell pants. And we started in hard shell for our own brand. So, then it's like, "I live in the Wasatch. I don't wear hard shell, like, while I'm ski touring, at least. Like, I need soft shell." And then it's like, okay, well, let's start working on soft shell stuff.

+ +

Then it's like, okay, we also need mid-layers, and we need base layers. And then we need mountain bike, and we need trail run, and we need climbing, and we need hiking. And it's like, oh man, you know what would be easier? If we just worked with, like, one of the or all of the big brands in this space. And there's some really great examples of, like, smaller companies that have created really compelling systems to work with these brands, like the same group that does the secondary market stuff, so the Worn Wear program for Patagonia and the ReGear thing for Arc'teryx.

+ +

And they built that same structure for, like, two dozen different brands. And it's like, man, that is the model for us. That's where we can really connect is they've created so much value in the secondary market, and we've created a bunch of value in this custom and made-to-measure market. That's what we want to do. And we want motocross...like, the MADE brand isn't going to make motocross stuff. The MADE brand isn't going to make fly fishing necessarily. But we want these markets and these people to be able to have that solution. And we also, like, we're early in the space.

+ +

Like, we want them to use us rather than, like, take the time and money and everything to build it themselves. Like, come to us, like, that's our whole idea. We want to have that bigger, larger impact. So, I guess it's us just trying to say like, "What do we want?" And we're users. We know the market. How do we get there the fastest? And how do we have that impact quicker than just necessarily, like, okay, well, in 25 years, we'll have all those products that we want?

+ +

VICTORIA: Yeah, yeah, I could see that, how it went from, well, yeah, I would want this for every product, and then you're like, well, I can't build every product [laughs]. So, I like that pivot in your strategy. And what challenges do you see in being able to make that impact as quickly as you want?

+ +

DUSTIN: One of our biggest challenges right now, I think, is that this is a totally new idea in this space. Nobody's done this in this space. Like, in suiting, custom suits have been a thing for a long time, and it used to just be for rich people. And now because of, like, modern technology and stuff, it's become more approachable. Awesome. That's great. And so, like, in that kind of category, people are more used to the idea of, like, yeah, I place an order, and it takes time, and they make a thing, and then it comes to me.

+ +

Whereas with outdoor apparel and sports apparel and that sort of stuff, you go to your local shop. You try on six different things, and you walk out with the one that meets your needs the best. That's what people are used to. So, it's a little bit of a shift in the thought process. You know, we've had our early adopters, and now we're kind of moving into more people who are like, "Okay, I get it now." And so, we're seeing more of that where it's like, yes, if I give some time, then I really see the value of having something that fits me perfectly.

+ +

And in the MADE Outdoor brand, it's not an inexpensive product. We make a really premium hard shell product. Now, it's comparable in price to the other brands that make comparably featured and whatever product, but still, you're spending money, and you want something that's going to last for a while. And so, to have that perfect fit, to have that perfect feature set, to know that when I ski, I totally need a left chest pocket, and I don't need a right chest pocket, whatever it might be, like, your details, that matters, right?

+ +

So, that's probably our biggest challenge right now. That's not an unsolvable problem. We can manage that. We can get the communication out. And especially as we're onboarding these existing brands, that gives us the opportunity to have a much larger mouthpiece and be able to kind of say like, "Hey, this exists, and you should care." Yes, it's going to be amazing for individuals who have traditionally been off-size. But it's also amazing for you people who think you've always been just, "Yeah, I'm a medium, and everything fits me just fine." You'd be surprised.

+ +

Like, having something that fits you perfectly is a different world, and the ability to then move in that sport and, like, be able to do your thing, it's like, oh yeah, I guess that, like, extra fabric in my shoulders was kind of, like, limiting my movement while ice climbing or, you know, oh yeah, my sleeves were always coming up while I was climbing, or whatever it might be. Like, there's things that I think people will really kind of be psyched about when they start to experience that custom aspect of it.

+ +

VICTORIA: Yeah. I can speak to some of that, too, as, like, a climber. And you mentioned it even when you talked earlier about, well, if you're bouldering at the gym, that's a totally different experience than if you're out all day on a multi-pitch, and you're on the wall, and you're, you know, you're vertical for, like, six hours of the day [laughs]. And I think it's really interesting to be able to provide that customization.

+ +

And how are you defining success for the company? So, you just made this pivot about six months ago. Did you immediately create some goals that you wanted to achieve in three months, six months, or five years?

+ +

DUSTIN: Yeah, I mean, we have our, like, target, our sales targets and stuff that we are looking at as far as we want these many brands on board this year. And we want to bring on like, you know, as I step back a little bit, as, like, the bigger thoughts behind the company, that's more of, like, where we're trying to target multiple different categories at the same time. So, like, if we can get one big outdoor brand, great, that's what we want to do.

+ +

Now, we want all the outdoor brands. We totally want them all. But if we can just get one, then we're going to have a start of an impact in the outdoor sector. Then we want the motocross brand, and we want to be able to make the impact in that sector. And we want the fly fishing brand, and we want the yoga brand, and we want the traditional, like, team sports brands and those types of things.

+ +

Like, we want to kind of, like, spread and have an impact across categories and as kind of a first attack. And then to really kind of go from there and say like, "Okay, now let's build out, like, oh, fly fishing really is connecting with this, or the yoga community is loving the, like, idea of a really custom fit product." So, like, those types of things are where we can kind of go from there.

+ +

But as we begin, it's really like, can we make an impact across these different categories? And those are a lot of our goals as we start out. It's like, how can we connect with surf? How can we connect with hike? How can we, you know, like, and it's just looking at each of these little categories because we know there's people being stuck that can't get out in each of those things, and we know we can help. But we're not going to design the product personally. So, how can we make that impact with the right partners?

+ +

VICTORIA: Oh, that's great. And I'm even thinking about surfing and getting a wetsuit. And there's just so few women wetsuits, period, in the store. And it's very limited in range and can be really challenging. And I took a friend surfing last year and did not enjoy that process. She did not like it [laughter]. She liked the surfing part, but the getting the wetsuit on and trying them on was not great [laughs].

+ +

DUSTIN: I can only imagine, yeah. And there's some really cool, like, in surf, there are some great small brands, like, new brands that are doing custom fit. I don't know their systems. I don't know if it's an automated process or if it's a manual process, but the reality is it's not readily available enough to the general public. And that's where it's like, oh man, our system makes it readily available.

+ +

And so, then it's like a simple kind of like, okay, I go online. I fill in this information. I decide, do I want a hood on my wetsuit? Do I not want a hood? Do I want this kind of entry? Do I want...Like, you decide the details that you want, and then the product is made for you. That's the beauty of it, right?

+ +

VICTORIA: Yeah. And I'm curious to kind of get back to marketing to existing businesses because you not only have to sell them on this is the art of the possible. Here's, like, what you could do to get the same performance with these custom measurements of your existing high-performing apparel. But you also have to encounter this change management process where they have a way of doing things. You'd be a new product. They'd have to figure out how to change up all their operations. So, I'm curious: what's your strategy for getting involved in that and working through it?

+ +

DUSTIN: Oh man, some of these companies are giant ships with tiny rudders, right? So, to get them to shift any direction or the other is tricky. A lot of our current sales pipeline is more medium-sized brands that have a little bit more of a nimble; yeah, we can jump on this. But one advantage we have is that some of these categories do have some custom programs, like I mentioned, the custom wetsuit stuff, like, that is in the market. So, like, wetsuit companies are aware that this needs to exist. Fly fishing waders: there are some custom fly fishing waders, now, not necessarily made-to-measure, but you don't make them in a 4XL or something. You could order a 4XL from a certain company.

+ +

So, like, there are systems like that. So, they've actually already kind of figured out the manufacturing side, which is one of the challenges of it that we can help the brands figure out those details because we've done it, and we know how to, like, take advantage of the efficiencies that they have in place with their current supply chain, or they can use our supply chain that we've built out. So, it depends. But that is one of the challenges is to get them to just kind of commit to say like, "Yes, this is worth putting in the time."

+ +

So, we do have...actually, the secondary market company I mentioned earlier, the way that they do it is it's, like, a separate site. And so, it's not run through their existing site. And so, they get around some of the ways of not necessarily having to be tied directly into a lot of their internal systems, and it's run as, like, a secondary system. Like, there are guitar manufacturers that make custom that they don't even produce them. They basically license out their shapes and stuff to custom builders.

+ +

So, we're trying to take a lot of the learnings from these other categories that do something kind of similar to what we're doing and learn from them and say like, "Okay, that's one approach we could take, or that's an approach we could take."

+ +

And then, really, we're going to the sales conversations with those brands and saying, "What do you need? Because we can be flexible." We're the opposite of the giant ship with a tiny rudder. We're that tiny, little motorboat that can, you know, like, spin circles and stuff. Like, we can do whatever is really needed at this point for these brands to be able to tie into them. So, we are flexible, and we try to learn as much from them as possible to be able to build the right solution.

+ +

VICTORIA: Yeah, I think that is the draw of you get your foot in the door with the middle businesses, and you can prove out that it works, and then maybe eventually the bigger brands start to take notice and pick it up as well. But it is going to take time. That's really cool. I think it provides that, you know, for those mid-size businesses, it gives them an advantage that a larger enterprise wouldn't be able to offer.

+ +

DUSTIN: Yeah, no, I think, at first, especially, like, the idea to be kind of first to market-ish with something totally new and exciting and to create that brand value with their customer in a way that they haven't been able to before.

+ +

VICTORIA: Right. And you mentioned fly fishing a few times, and I feel like it's one of those sports that I've done it when I was, like, really small, like, maybe with my grandfather, like, fishing in the river. And as I get older, I'm like, it does sound nice.

+ +

DUSTIN: Right? [laughs]

+ +

VICTORIA: Like, sitting alone in, like, a beautiful place. Like, maybe you get a fish, maybe you don't. I think I like the idea of it more than the reality of it, but will try it out some...I have enough other sports [inaudible 33:02].

+ +

DUSTIN: I think you'd be psyched if you gave it a shot. Like, fly fishing is something that, like, if you like being outside, it's something else. There's a beauty to it, for sure. And there's a beauty to all of these sports. And, honestly, if people are being active, whatever it is that you're doing, good for you. And that's part of it is, like, we are trying to be as sport agnostic as we can in all of this because, yeah, we don't care if you are a diehard snowmobiler, right? Amazing. Great. Let's get you some product that fits so you can get out and do your diehard thing.

+ +

Or, you know, maybe you're a mountain biker or a road cyclist, or, like, you know, there's so many things that we wear clothing that we hope allows us to perform in that sport, and yet so much of it is holding us back, even maybe to a degree that we don't even know. Professional athletes and stuff, much of their product is made-to-measure. Olympic speed skaters, like, it's not like they had to just choose a medium or a large type of product. Like, it's made to fit their body so that they can perform at their pinnacle level. That's awesome.

+ +

Where that stops is in the, like, general consumer, and, like, I want to get out and do my sport. It's not about being the best at this thing. It's just about being my best at this thing and having the most fun that I want to have in it. The fit and the details of your product matter just as much as it does for the Olympian as far as I'm concerned.

+ +

VICTORIA: Absolutely. And it reminds me of a story that happened to me. I was climbing in this very popular pant that is known as their climbing pant from this particular brand. And it was maybe the fifth time I'd worn these pants and just ripped the inseam while climbing.

+ +

DUSTIN: [laughs]

+ +

VICTORIA: You know, lucky it wasn't that cold that day or anything, but it's just [inaudible 34:50]

+ +

DUSTIN: Your belayer got a kick out of it, I'm sure.

+ +

VICTORIA: Yeah, there was a layer to this, right? Yeah.

+ +

DUSTIN: [laughs]

+ +

VICTORIA: And I've heard that happens to lots of climbers who wear those same pants. Like, they're known for that because it's really hard to get that measurement right, especially with that kind of material, which was great. It's like this material that was supposed to not rip, right? [laughter] [inaudible 35:09] what is this? Yeah. Maybe I do want to go outside, and I want to go fly fishing, or I want to go skiing or snowboarding, but, oh, they don't even have pants in my size. Like, I'm not even going to try. And that's really demoralizing. So, I think it's great to be working on that problem.

+ +

Oh, wonderful. Thank you so much for joining. Is there anything else that you would like to promote today?

+ +

DUSTIN: No, I mean, I think I love having these conversations, and chatting with you has been so great. It's fun to talk about what we're working on and to, you know, get the word out a bit more. There's not really other things to promote other than, like, you know, if you're a smaller or medium-sized or a large apparel brand hearing this, like, please reach out to me. I want to talk to you.

+ +

We've built a system that really can help both the brand and the customer. It helps the brand with revenue and with margins and reduced waste and all of these things, but it also just helps the customer have a better product and a better experience. And ultimately, that's, in theory, what we are trying to do when we make product. So yeah, that's my focus, and that's what I want to talk to everybody I can about right now.

+ +

VICTORIA: I love that. Thank you so much for sharing your story and for coming on the show today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+h4hCuLc6 + + ]]> + + Victoria Guido + + + 512: Unboxing thoughtbot's Revolutionary Design Sprint Kit + https://podcast.thoughtbot.com/512 + 4d1373f3-9ba2-4a61-a462-c813c2efd99f + Thu, 15 Feb 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + In this episode of the Giant Robots Smashing Into Other Giant Robots podcast, hosts Will Larry and Victoria Guido are joined by thoughtbot's senior designers, Rami Taibah and Ferdia Kenny, to discuss the innovative Product Design Sprint Kit. This tool compresses the design process into a focused five-day sprint, facilitating the efficient transition from idea to user-tested prototype. The conversation highlights the kit's development, its open accessibility, and its impact on product strategy through iterative design and user feedback. Real-world examples illustrate how these design sprints can lead to crucial product refinements, showcasing the critical role of user testing in product development. + 34:33 + no + + + In this episode of the Giant Robots Smashing Into Other Giant Robots podcast, hosts Will Larry and Victoria Guido discuss the intricacies of product design with thoughtbot's Senior Designers, Rami Taibah and Ferdia Kenny. They delve into the newly launched Product Design Sprint Kit by thoughtbot, which is designed to streamline and enhance product development. +Ferdia and Rami explain how the kit aims to compress the design process into a focused five-day sprint, allowing teams to move from idea to user-tested prototype efficiently. They discuss the genesis of the kit, its components, and the rationale behind making it openly available. +Towards the end of the episode, the conversation shifts towards the broader implications of design in product development, the iterative nature of design sprints, and the value of user feedback in guiding product decisions. Rami and Ferdia share real-world examples where product design sprints led to significant pivots or refinements in product strategy, emphasizing the critical role of user testing in uncovering genuine user needs versus presumed functionalities. +Follow Rami Taibah on LinkedIn (https://www.linkedin.com/in/ramitaibah/). +Follow Ferdia Kenny on LinkedIn (https://www.linkedin.com/in/ferdiakenny/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your co-host, Victoria Guido. And with us today are Rami Taibah, Senior Designer at thoughtbot, and Ferdia Kenny, Senior Designer at thoughtbot, here to talk to us about the newly released Product Design Sprint Kit from thoughtbot. Ferdia and Rami, thank you for joining us. Why don't you introduce yourselves a little bit, tell us a little bit about each of your background while we get started? +FERDIA: I'm Ferdia. I'm a product designer at thoughtbot. I've been with the company for nearly three years now. I'm based in Dublin in Ireland, but I'm from the West Coast of Ireland. Happy to be on the podcast. It's my first time coming on, so that'll be a new experience. +RAMI: Yeah, so I'm Rami Taibah, and I am also a senior designer at thoughtbot for nearly two years. I'm also from the West Coast, like Ferdia, but I didn't move. I'm still where I'm from [laughs]. +VICTORIA: Yeah, so just to get us warmed up here, why don't you tell us something interesting going on in your lives outside of work you want to share with the group? +FERDIA: For me, I'm trying to do a bit of traveling at the moment. So, one of the benefits, obviously, of working with thoughtbot is that we are a fully remote company. As long as we're kind of staying roughly within our time zones, we can kind of travel around a little bit. So, I'm actually in France at the moment and going to Spain in March. So yeah, I'll be working from a couple of different spots, which is really cool and a lot of fun. +RAMI: Yeah, it's pretty cool. I always see Ferdia, like, having these meetings in, like, these different locations. Just a few months ago, you were in Italy, right? +FERDIA: Yeah. Yeah [laughs], that's right, yeah. +RAMI: Yeah. So, for me, well, first of all, I got a new baby, new baby girl, exactly on New Year's Day, so that's interesting, going back home every day and seeing how they evolve very quickly at this age. Another thing is I've been doing a lot of Olympic weightlifting. It's probably one of the consistent things in my life since COVID. I was a CrossFitter. I got out of that, thankfully. But coming back into, like, after quarantine, weightlifting seemed like a good choice because it doesn't have the social aspect of CrossFit, and I can just do it on my own. +WILL: How is your sleep? +RAMI: I'm a heavy sleeper, and I feel guilty about it, so no problems here [laughs]. +WILL: Yeah, that was one thing I'm still trying to recover from–sleep. I love my sleep. And so, I know some people can do with little sleep, but I like sleep. And so, I'm just now recovering, and we're almost two years since my baby boy, so [chuckles]... +RAMI: Yeah, I'm a heavy sleeper. And I tell my wife, like, we have this understanding, like, if you ever need anything from me besides...because she has to be up for, like, breastfeeding, just kick me. I'll wake up. I'll do whatever you need [laughs]. +WILL: That's awesome. +VICTORIA: So, my understanding is that if you want to get better at any sport, if you get better at deadlifting, that will help you progress in your sport pretty much. That's my [laughs] understanding. I don't know if you all feel that way as well. +RAMI: Oh, I never heard that. But I do know that these three, like, three or four basic lifts just basically boosts you in everything else, like, deadlifts, back squats. And what was the third one? Bench press, I guess. +FERDIA: And pull-ups as well, I think, is a compound exercise. I just hate like this. I look for an excuse to skip them, so...[chuckles] +VICTORIA: Yeah, the four essential exercises, but it doesn't mean that they're fun, right? +FERDIA: [chuckles] +VICTORIA: Yeah. And then, Will, I heard you were also training for a new activity, the 5k. +WILL: Yeah, I'm going to run a 5k with my best friend. He's coming into town. So, I'm excited about it. I've always tried to do running, but my form was horrible, and I'll get injured, tried to do too much. And I think I finally figured it out, taking it slow, stretching, making sure my form is correct. So, it's been good. I've enjoyed it. And it's interesting looking at what I'm doing now versus when I first started. And I was like, whoa, like, when I first started, I couldn't even run a mile, and I'd be out of breath and dying and just like, ah, and then now it's like, oh, okay, now I'm recovered, and I can walk it off. +So, one thing it's taught me is just consistent, being consistent because I feel like with working out and running, you have this, like, two-week period that it's just hard. Everything hurts. Your body is aching. But then after that, your body is like, okay, you're serious. Okay, then, like, I can adjust and do that. And then once you get over that two weeks, it's like, oh, okay, like, still, like, sometimes I still push it and get sore, but for the most part, my body is like, okay, I get it. Let's do this. +And then now, compared to before, now I'm just like, I can't stop because I don't want to go back through that two weeks of pain that I started at, at the very beginning. So, yeah, it's been a very good journey. I don't know how far I'm going to go with it. I don't know if I'm going to go a full marathon or a half marathon. I will increase it and do multiple races, but yeah, I don't know how far I'm going to go with it. +VICTORIA: Well, it's interesting. It reminds me how, like, anytime you do something new, you're forming new neural pathways in your brain, then you can get in a routine, and it becomes easier and easier every time you do it. So, I'm going to try to relate this back to our Product Design Sprint Kit. It's like a set of exercises you can learn how to do that might be difficult at first, but then it becomes a part of the way that you work and how you build products, right? So, why don't you tell me a little bit about it? Like, what is it? What is the product design kit that you just came out with? +FERDIA: The PDS kit or the Product Design Sprint Kit it was something that I'd kind of been playing around with in investment time for a while, and then spoke to Rami about it a couple of months ago, and he got on board. And it really accelerated what we were doing. And it was basically, like, a product design sprint is a known process in design and product design and product development. I think it was started by Google. +And, essentially, the concept is that you can take an idea that you have for something new and, in five days, go from that idea to creating something that can be user tested, and so getting real kind of validated feedback on your idea. Yeah, so try to do it in a compressed timeframe. That's why it's called a sprint. So, you're trying to do it within five days. +And the concept for kind of creating a kit that we could share to people beyond thoughtbot was that we tend to repeat a lot of the same instructions in each sprint, so we're running very similar exercises. The outcomes are slightly different, obviously, depending on the customer, but the exercises themselves are pretty similar. So, the [inaudible 06:42] kind of when we're talking to the customer are often very much the same. +And we just thought that we get a lot of inquiries from start-ups, I think probably maybe even more so in Europe, before they're funded and looking kind of for the first step. Like, what can they do? So, a lot of them, if they're not in a position to, say, pay for some of our design team to come on with them and run a sprint with them, we thought it'd be cool to be able to give them, well, you know, this is something free that you can run yourself with your team and will kind of get you on the ladder. It will hopefully give you something that you can then take to an investor or somebody that could potentially fund a kind of bigger sprint or maybe even an MVP build. +WILL: Let me ask you this: Why is design so important? So, if I'm a developer, or a CTO, or a CEO of whatever, why should I be an advocate for design? +RAMI: Well, over here at thoughtbot, we do a lot of iterative design. I think that's a key factor that we should take into consideration. With iterative design, it's the idea of designing something based on a validation or based on a user and doing it quickly and testing it to get feedback from the user or from the market and adjust from there, instead of just designing something in, like, a silo and releasing it after six months and then discovering that you went off course four months ago. And that will cost you a lot of time, a lot of money, a lot of agony, I guess [laughs]. And it just generally will become a very frustrating process. +I've seen clients before thoughtbot where they come in and they've been working on this thing for six months, and they're just not releasing and pushing the release for month on month just because the CEO does not feel like it's at par with what he's using on, like, everyday apps. And he's, like, looking at, oh, I want to look like Instagram, or feel like Instagram, or feel like whatever they like when, in reality, products don't evolve that way. +And Instagram has already, I don't know, 12 years of development and design behind it. And you can't possibly expect your app that you're launching for your startup to feel the same, look the same, and all that stuff. That's why design is important. So, you just discover early on that you are on the right path and always correcting course with different design techniques, including the PDS. +FERDIA: What you're talking about there just de-risks a lot of stuff for people when they're trying to create something new. You could have the, you know, a really, really impressive product under the hood that can do a lot of really technical stuff. But if it's very hard to use, or if it's very hard to kind of tap into that magic that you've built on the development side, people just won't use it, and you won't be able to generate the revenue you want. So yeah, the user experience and kind of the design around that is really important to get people actually using your product. +VICTORIA: Yeah, I can relate to what you all have said. I've talked with founders before, who they maybe have a lot of experience in the industry and the problem that they are trying to solve. They think I know what it should look like. I just need developers to build it. But the activities you described about the product design sprint and creating something where you can go out and test that theory, and then incorporate that feedback into your product, and doing it within five days, it seems like a really powerful tool to be able to get you on the right path and avoid hundreds of thousands of dollars of development spend, right? +FERDIA: Yeah, 100%, yeah. And, like, a typical outcome for a product design sprint will never be a fully polished, like, perfect design. That's just...it's not realistic. But what you will hopefully have by the end of that five days is you will know, okay, these are, like, five or six things that we're doing right, and these are things we should keep going with. And maybe here are three or four things that we thought users would like, or potential customers would like, and we are actually wrong about those. So, we need to change those things and maybe focus on something else. +So, as Rami said, design is an iterative process that is like your first iteration. But getting that feedback is so helpful because, as Rami said, if you spend six months developing something and figure out that 4 of the ten things that you built weren't needed or were wrong, or customers just didn't want them, that's a really, really expensive exercise. So, a design sprint, kind of if you're to do them on a continuous basis or every couple of months, can be a really helpful way to check in with users to make sure what you're committing your resources to is actually going to benefit them in the long run. +RAMI: Yeah. And I would also like to add, like, one of the outputs of a design sprint is a prototype. To me, I'm always like, seeing is believing. It's just better to have a prototype as a communication tool within the team with clients, with customers, with users, instead of having, like, a document or even just wireframes. It just doesn't really deliver what you're trying to do, like a prototype. +FERDIA: Yeah, 100%, Rami. And, like, on the prototype, like, a good comparison that people, if they're not in product development, might have seen it's like if you're building a house, like yourself, Victoria, a lot of architects will give you two-dimensional plans. And for people that aren't in the building industry, plans can be difficult to read or difficult to visualize what those actually look like. +But if you can give someone a 3D representation of the house, you know, they can see, oh yeah, this is what it's going to kind of look like and what it's going to feel like. And the prototype that Rami is talking about gives you exactly that. So, it's not just this is our idea; it's, this is actually what the thing could look like, and what do you think of that? So yeah, it's definitely a valuable output. +VICTORIA: We're having this debate about whether or not we need a designer for our renovation project. And I'm very much pro [laughs] designer. And maybe that's from my background and being in software development and, like, let's get an expert in here, and they will help us figure it out [laughs], and then we'll make less mistakes and less expensive mistakes going forward. So, I think there's a lot of analogies there. +So, this product design sprint is a service that we offer at thoughtbot as well, right? We do workshops and meetings together with the client, and you all have this idea to record the videos and put all the content out there for free. So, I'm curious how that conversation went within management at thoughtbot and how did the idea really get started and get some traction going. +FERDIA: The benefit of the Product Design Sprint Kit what you get out of it won't replace, say, doing a product design sprint with thoughtbot because you will have expert product designers or developers in the room with you to kind of share their ideas and their experience. So, the output you're going to get from running a sprint with thoughtbot will be more beneficial, definitely. +But what we were trying to, I suppose, cater for was people that fall in the gap, that they're not quite ready to bring thoughtbot on board, or they don't have enough funding to bring thoughtbot on board to do a product design sprint, or a longer discovery sprint, or something like that. But we want to be able to give those people in kind of the software community something actionable that they can actually take and use. +So, the first three days, I think, of the Product Design Sprint Kit will be really, really valuable to people. It'll really help them identify the problem that they're trying to solve and then to come up with a lot of different solutions and to try to pick one of those. And probably where it's going to be a bit more challenging if you don't have experience in design or in development will be around the prototype, which Rami had spoken about. You can kind of do some offline things, and there are ways to test things without, say, a high-fidelity prototype, but those high-fidelity prototypes, again, are something that could be helpful. +But thoughtbot has always had an approach of kind of giving stuff for free to the community, either open source or just letting people, yeah, letting people learn from our resources and from what we know. And so, yeah, this is just a way to, hopefully, cater to people that we currently can't work with for a variety of reasons but that this is something that they could maybe use in the meantime. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +WILL: So, can you break down...you said it's five days. Can you break down what is walking you through, like, each day? And, like, what experience do I have? Because I know, I've tried to get in Figma sometimes, and it's not easy. It's a pain at times. You're trying to maneuver and stuff like that. So, what do I have to do? Like, do you show me how Figma? Do you give me a template with Figma? Like, how do you help me with those things? And I know Miro and those things. So, like, walk me through each step of the sprint. +RAMI: Yeah, well, I mean, Figma and Miro are just tools that just became popular, I guess, after COVID. Design sprints used to be physical, in the same room as sprints. You would get the clients or the stakeholders in a room and do all that stuff. But Figma, FigJam, and, you know, kind of...I don't know if this was part of their, like, product thinking, but it kind of allowed doing full-on design sprints in their tools. +So, the first step or the first day would be, like, the understanding day where basically we gather information about the product, the users, what's out there, and just come up with a general plan on how to go forward. +And the second day would be divergent where we just look at what's out there and come up with these crazy ideas, kind of, like, a brainstorming thing but in a more inclusive, I guess, way and in a more organized way. So, you don't have people shouting over each other. Like, being anonymous also is important on this day, so nobody really knows what you're doing or saying. It's just ideas to remove bias. +Then, we'd have a converge day where we take all these ideas and consolidate them, which will be an input into the prototype phase. +And the last day is the test phase. I mean, each of these days you can talk...have a full podcast. +VICTORIA: I'm curious about when you're testing and when you're, like, I'll say thoughtbot is a global company, right? And so, there's lots of different types of users and groups that you might be wanting to use your app. I'm thinking, you know, sometimes, in particular, some of the applications I've been looking at are targeting people who maybe they don't have an iPhone. They maybe have lower income or less means and access to get products and services. So, how does your design sprint talk to designing for different types of communities? +FERDIA: I think that's a great question, Victoria. I would say the first thing on it is that we'd often get a lot of people with a startup idea, and they would come in and say, "You know, this app could be used by everybody. So, like, we have kind of no beachhead market or no target market. Like, this would be great for the whole world." That's a very nice thought to have if it is something that could potentially be used by everyone. +But we would generally say you should pick a smaller niche to try to establish yourself in first and hit a home run basically with that niche first, and then kind of grow from there. We would normally say to people as, like, again, this is going back to what Rami said about the iterative process. If at the end of the five days, you've picked the wrong beachhead market and it doesn't hit home with them, that's fine. You can just do another sprint next week or next month on a different kind of subsection of the market. +So, I think picking a fairly niche sector of the market is a good starting point. You then run your product design sprint with that niche in mind and try to talk to five users from that. And, generally, we say five because, generally, if you have less than or fewer than five people contributing, you probably won't get enough data. You know that you could...if you only test with two people, you probably wouldn't get a thorough enough data set. And then, normally, once you go over five, you kind of start seeing the patterns repeating themselves. You get kind of diminishing returns, I guess, after five. +So, that would generally be the approach. Try to identify your beachhead market, the one you want to go into first, and then you will try to talk to five people generally from the founding team's network that match the criteria of that beachhead market. And, in some ways, just the final point, I guess, is the fact that you have to pull them from your network is actually beneficial to kind of make you narrow down and pick a niche market that's accessible to you because you know people in it. +RAMI: And maybe if you don't know anybody, then maybe you're in the wrong industry. +FERDIA: Yeah. Great point. Great point because, yeah, it makes it a lot easier. It's nice to have loads of industries that you could go into, but it makes it so much easier if the founding team have contacts in an industry. Yeah, it makes a big difference. +WILL: Yeah, I was going through the different days and kind of what you were talking about. So, like, one day is brainstorming, then converge, and then prototyping, and user testing kind of on that last day. It seems like it's completely laid out. Like, you're giving away all the keys except experience from the actual designer. It seems like it's all laid out. Was that the goal to, like, really have them fully laid out? Hey, you can do this from point A to point B, and this is what it looks like. +Is that something that you're...because that's what it looks like as my experience with designers and stuff. And if that's the case, what was your reasoning behind that, to give it away? For someone, like you said, like a startup they can do this because you pretty much laid it all out. I'm not a designer, and I don't claim to, but it looks like I can do this from what you laid out. +RAMI: Well, first of all, like, at thoughtbot, we're really big into open source, and open source is not always just development. It can be these kinds of things, right? It's not a trade secret. It's not something we came up with. We maybe evolved it a little bit from Google, I think it was Google Ventures, but we just evolved it. +And, at the end of the day, it's something that anybody can do. But, actually, taking the output from it is something that we do as thoughtbot. Like, okay, you have a prototype. That's great. You tested it, but okay, now we want to make it happen. If you can make it happen, then great, but the reality is that a lot of people can't, and that's why there are, like, a gazillion agencies out there that do these things. +So, the reasoning, I guess, and Ferdia can expand on, is, like, if somebody takes this and comes up with a great prototype and feels confident that they actually want to develop this idea, who else would be better than thoughtbot who actually gave them the keys to everything? +FERDIA: Yeah, 100%, Rami. Yeah, it's essentially just helping people get on the first rung of the product development ladder with fewer barriers to entry, so you don't have to have a couple of thousand dollars saved up to run a sprint. This kind of gives you a really, really low entry point. +And I guess there's another use case for it where you would often have potentially founders or even companies that want to release a new product or feature. And they might reach out to thoughtbot because they want to develop something, and they're very sure that this is what we want to develop. And, you know, maybe they don't want to engage with a product design sprint or something like that if they think they know their market well enough. +And this could be a handy tool just to say to them, "Okay, if you can go away, take this free resource for a week, run a product design sprint with your team, and come back to us and tell us that nothing has changed, you know that you've correctly identified the right market and that you've validated your theories with them," then we can kind of jump into development from there. +But yeah, it can be a good way, I suppose, to show the value of doing a product design sprint. As I said, a lot of people come in, and they have great ideas, and they can be fairly certain that this is going to work. But a product design sprint is really, really valuable to validate those before you dive into building. +VICTORIA: And can you give us an example from your experience of a client who went through a product design sprint and decided to pivot maybe their main idea and go in a different direction? +FERDIA: I'm not sure off the top of my head, Victoria, if I can pick one that pivoted in a completely different direction, but definitely, like, some of the clients that we worked with on the Fusion team in thoughtbot ended up changing direction or changing the customer that they were going after. So, some people might have had an idea in their head of who they wanted to tackle and might have had a particular, say, feature prioritized for that person. And through the product design sprint, we were able to validate that, actually, this feature is not that important. This other feature is more important, and it's more important to a different group than kind of what you initially thought. That would happen fairly regularly on a product design sprint. +Like, I think if you look at the potential outcomes, one being that everything's exactly as you thought it was and you can proceed as planned, or the opposite end of the spectrum where nothing is as you thought it was and, you know, you kind of have to go back to the drawing board, it's very rare that you're on either end of those after a product design sprint. Most of the time, you're somewhere in the middle. You've changed a few things, and you're able to keep a few things, and that's kind of normally where they land. So, I would say nearly every customer that we've done a product design sprint with has changed some things, but never kind of gone back to the drawing board and started from scratch. +RAMI: It's usually prioritization and just understanding what to do and also, like, get into the details of how to do it. That's where the value comes in. But, like, completely pivoting from a food delivery app to, I don't know, NFTs [laughs] never really happened. +VICTORIA: Yeah, and it doesn't have to necessarily be a big pivot but looking for, like, a real-world example, like, maybe you're building an e-commerce site for a plant marketplace or something like that. +RAMI: Yeah. Well, we had a self-help app where they already had the app in the market. It was a progressive web app, and they were really keen on improving this mood tracker feature. But then we did a product design sprint, and they had a bunch of other features, and that exercise kind of reprioritized. And the mood tracker ended up not being released in the first version of the actual mobile app because we were also developing a native app. +VICTORIA: Gotcha. So, they were pretty convinced that this was an important feature that people wanted to track their mood in their app. And then, when they went through and tested it, users were actually like, "There's this other feature that's more important to me." +FERDIA: One example of another client that we did, which was a kind of a wellness app, they wanted it to feel like a friend in your pocket. So, they were looking at ways to integrate with WhatsApp that you'd get notifications via WhatsApp. So, they would kind of be, like, friendly messages to people as if it's your friend, you know, texting you to check in. And that was kind of an idea going into it, and users did not like that at all. Like, they really didn't like that. +So, we ditched that [inaudible 25:49] completely. But, again, that could have been something that they would have spent a long time developing to try to implement, and then to have users say this would have been a very, very costly waste of time. So, we figured that out in a few days, which was a money saver for the team. +VICTORIA: And it must be pretty emotional to have that feedback, right? Like, it's better to get it early on so that you don't invest all the money and time into it. But as a founder, I'm sure you're so passionate about your ideas, and you really think you have the answers from your experience, most likely. So, I'm curious if there's any kind of emotional management you do with clients during this product design sprint. +FERDIA: I think it definitely is. I think people, as I said, often come in with very strong opinions of what they feel will work. And it might even be a product that they specifically want, or they might be one of those potential users. And I actually think, say, engaging an agency like thoughtbot to design something like that, if we felt that they were going down the wrong path, that could be actually quite difficult to do. But because of product design sprints, you are user-testing it. The founders are hearing this feedback from the horse's mouth, so to speak. They're hearing it directly from potential customers. So, it's a lot more black and white. +Now, sometimes, it might still be a case that a founder then doesn't want to proceed with that idea if it's not kind of going to be the way that they wanted it to be, and that's fair enough as well. But the feedback, as I said, it tends not to be that the idea is completely scrapped. It just means that you move a couple of things around. As Rami said, you deprioritize some things and prioritize other things for the first version, and that tends to be the outcome of it. +VICTORIA: Are the users always right, or is it sometimes you can have an idea that persist, despite the early feedback from users? +RAMI: Interesting question. Like, I see the parallels you're doing with the customer is always right, yeah. But the thing is, like, that's just my opinion, I think. We tested with users, and we kind of observe how they react to it and how they use the prototype. +So, it's not like an opinion session or, like, a focus group where they're actually giving...a user can say something and do something else or react in a different way. But yeah, it's a fine line, I think. But I would be really surprised if ten users would agree on something and say something, and their behavior also would reflect that, and we won't pick up on. +VICTORIA: Yes, I like the distinction you're making between what they say and then what the behavior shows, right? +FERDIA: I think something important there as well, like you'll often hear it in design communities, is that you should listen to the feedback from customers but maybe not the solutions that they're proposing. Because, at the end of the day, like, thoughtbot have experts in product design and product development, so we want to figure out from the user's perspective what they want to achieve and maybe what their problems are, but not necessarily take into account or just, I suppose, not necessarily just follow exactly what they say the solution should be. +You're kind of looking for the problems and the things that they're struggling with. You're trying to pick those up rather than just to do the solution that the customer is telling you. And you'll see that in a lot of startups as well that, you know, it's the famous Henry Ford quote about, you know, "If I'd listened to my customers, I'd have designed a faster horse." Sometimes, you need to listen to the problem, and the problem is getting from A to B faster, and then you come up with a solution for that rather than the solution that's been recommended to you. +WILL: I want to pivot a little bit and ask you both, why did you get into design? +FERDIA: I actually did architecture in university, and there were aspects of that I liked. Funnily enough, it's a fairly similar process to designing for software, and then it's an iterative approach. You're given a brief and yet you kind of take a concept forward. But then, when you apply for planning, you have to make changes. And when you kind of put [inaudible 29:41], you make changes. So, you're constantly, I suppose, designing iteratively. +And then I got into startups and was kind of wearing a lot of different hats in that startup sort of world. But the product was the one area that always kind of got me excited. So, you know, if you tried to make a sale with a particular customer and they didn't want to go over something, like, coming home and trying to figure out, okay, how can I fix that problem with the product so that next time when I go to a customer, and they'll say, "Yes"? That was kind of what always gave me the adrenaline. +So yeah, comparatively, between architecture and software, the turnaround times in software is so much faster that I think it's more enjoyable than architecture. You kind of can really see progress. Product design sprint in five days. You can kind of take something a long way whereas designing a building is a bit slower, but it's always kind of been some area of interest. Well, what about you, Rami? +RAMI: Well, I wanted to become a hacker, but I ended up to be a designer [laughs]. No, really, when, like, in middle school, I really wanted to be a hacker and kept looking up what is it. Like, I see it in all these movies really cool, and I wanted to understand, like, how it's done online. And I saw, like, everybody is talking about this weird, little thing called command line. And it turns out, like, all these hacking, quote, unquote, "hacking tutorials" were done on Linux. So, I started looking into Linux and got into Linux. +From there, I started blogging about Linux, and then I just really got into technology. I was in marketing. By then, I was a marketing major. So, that got me into blogging into, like, Linux and open source, which kind of triggered in my head, okay, I need to maybe pivot to a different career path. So, I did a master's degree in information management. Over there, I stumbled into design. The information management school that I was in, like, it was an interdisciplinary school at, like, design, coding, and business all mixed in. So, I stumbled in design there. +VICTORIA: That's how you all got started. And now you've put this product out there pretty recently. I'm curious if you have thought about how you would measure the success of this effort. So, how do you know that what you put out there in the product designs kit is helping people or achieving the goals that you had originally set out to? +FERDIA: Initially, Victoria, we obviously like to see the view counts going up on YouTube, and we're always open to feedback. So, like, at the end of each video and in the resources and stuff, we've got contact us kind of links and stuff. So, if people have feedback on how we could make it better or more useful, that would be really, really welcome. So, do feel free to reach out to us. +And kind of the ultimate success metric for us would be to have somebody come to us in future and say, "Oh, we used that Product Design Sprint Kit that you produced before, and we either got funding or, you know, we got so much value out of it that we'd like to do a full product design sprint or an MVP build, or something like that." +And the equivalent that we would kind of have a lot of in thoughtbot would be, say, gems in development where we would get people reaching out and say, "We use that gem all the time. We know about thoughtbot because of that." That kind of is a way to establish trust with potential customers. So, we're hoping that this is somewhat of an equivalent on the design side. +WILL: Oh, it's been great chatting with both of you about design and what you came up with this. I really like it. I'm going to look more into it. +VICTORIA: Yes. Thank you both for joining us. And I had one question. So, the sprint is the short-term. What would be, like, a product design marathon? Like, what's [chuckles] the big picture for people who are building products? Maybe that's a silly question, but... +RAMI: No, it's not, I mean, but I would guess it's actually building the product and having a successful product in the market and iterate over it for years and years. +VICTORIA: Yeah. So, it's a one-week sprint, and you could do it over and over again for many years just to fine-tune and really make sure that your product is meeting the needs of the people you were hoping to reach. Wonderful. +All right. Well, thank you both so much for joining us. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +VICTORIA: And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + In this episode of the Giant Robots Smashing Into Other Giant Robots podcast, hosts Will Larry and Victoria Guido discuss the intricacies of product design with thoughtbot's Senior Designers, Rami Taibah and Ferdia Kenny. They delve into the newly launched Product Design Sprint Kit by thoughtbot, which is designed to streamline and enhance product development.

+ +

Ferdia and Rami explain how the kit aims to compress the design process into a focused five-day sprint, allowing teams to move from idea to user-tested prototype efficiently. They discuss the genesis of the kit, its components, and the rationale behind making it openly available.

+ +

Towards the end of the episode, the conversation shifts towards the broader implications of design in product development, the iterative nature of design sprints, and the value of user feedback in guiding product decisions. Rami and Ferdia share real-world examples where product design sprints led to significant pivots or refinements in product strategy, emphasizing the critical role of user testing in uncovering genuine user needs versus presumed functionalities.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your co-host, Victoria Guido. And with us today are Rami Taibah, Senior Designer at thoughtbot, and Ferdia Kenny, Senior Designer at thoughtbot, here to talk to us about the newly released Product Design Sprint Kit from thoughtbot. Ferdia and Rami, thank you for joining us. Why don't you introduce yourselves a little bit, tell us a little bit about each of your background while we get started?

+ +

FERDIA: I'm Ferdia. I'm a product designer at thoughtbot. I've been with the company for nearly three years now. I'm based in Dublin in Ireland, but I'm from the West Coast of Ireland. Happy to be on the podcast. It's my first time coming on, so that'll be a new experience.

+ +

RAMI: Yeah, so I'm Rami Taibah, and I am also a senior designer at thoughtbot for nearly two years. I'm also from the West Coast, like Ferdia, but I didn't move. I'm still where I'm from [laughs].

+ +

VICTORIA: Yeah, so just to get us warmed up here, why don't you tell us something interesting going on in your lives outside of work you want to share with the group?

+ +

FERDIA: For me, I'm trying to do a bit of traveling at the moment. So, one of the benefits, obviously, of working with thoughtbot is that we are a fully remote company. As long as we're kind of staying roughly within our time zones, we can kind of travel around a little bit. So, I'm actually in France at the moment and going to Spain in March. So yeah, I'll be working from a couple of different spots, which is really cool and a lot of fun.

+ +

RAMI: Yeah, it's pretty cool. I always see Ferdia, like, having these meetings in, like, these different locations. Just a few months ago, you were in Italy, right?

+ +

FERDIA: Yeah. Yeah [laughs], that's right, yeah.

+ +

RAMI: Yeah. So, for me, well, first of all, I got a new baby, new baby girl, exactly on New Year's Day, so that's interesting, going back home every day and seeing how they evolve very quickly at this age. Another thing is I've been doing a lot of Olympic weightlifting. It's probably one of the consistent things in my life since COVID. I was a CrossFitter. I got out of that, thankfully. But coming back into, like, after quarantine, weightlifting seemed like a good choice because it doesn't have the social aspect of CrossFit, and I can just do it on my own.

+ +

WILL: How is your sleep?

+ +

RAMI: I'm a heavy sleeper, and I feel guilty about it, so no problems here [laughs].

+ +

WILL: Yeah, that was one thing I'm still trying to recover from–sleep. I love my sleep. And so, I know some people can do with little sleep, but I like sleep. And so, I'm just now recovering, and we're almost two years since my baby boy, so [chuckles]...

+ +

RAMI: Yeah, I'm a heavy sleeper. And I tell my wife, like, we have this understanding, like, if you ever need anything from me besides...because she has to be up for, like, breastfeeding, just kick me. I'll wake up. I'll do whatever you need [laughs].

+ +

WILL: That's awesome.

+ +

VICTORIA: So, my understanding is that if you want to get better at any sport, if you get better at deadlifting, that will help you progress in your sport pretty much. That's my [laughs] understanding. I don't know if you all feel that way as well.

+ +

RAMI: Oh, I never heard that. But I do know that these three, like, three or four basic lifts just basically boosts you in everything else, like, deadlifts, back squats. And what was the third one? Bench press, I guess.

+ +

FERDIA: And pull-ups as well, I think, is a compound exercise. I just hate like this. I look for an excuse to skip them, so...[chuckles]

+ +

VICTORIA: Yeah, the four essential exercises, but it doesn't mean that they're fun, right?

+ +

FERDIA: [chuckles]

+ +

VICTORIA: Yeah. And then, Will, I heard you were also training for a new activity, the 5k.

+ +

WILL: Yeah, I'm going to run a 5k with my best friend. He's coming into town. So, I'm excited about it. I've always tried to do running, but my form was horrible, and I'll get injured, tried to do too much. And I think I finally figured it out, taking it slow, stretching, making sure my form is correct. So, it's been good. I've enjoyed it. And it's interesting looking at what I'm doing now versus when I first started. And I was like, whoa, like, when I first started, I couldn't even run a mile, and I'd be out of breath and dying and just like, ah, and then now it's like, oh, okay, now I'm recovered, and I can walk it off.

+ +

So, one thing it's taught me is just consistent, being consistent because I feel like with working out and running, you have this, like, two-week period that it's just hard. Everything hurts. Your body is aching. But then after that, your body is like, okay, you're serious. Okay, then, like, I can adjust and do that. And then once you get over that two weeks, it's like, oh, okay, like, still, like, sometimes I still push it and get sore, but for the most part, my body is like, okay, I get it. Let's do this.

+ +

And then now, compared to before, now I'm just like, I can't stop because I don't want to go back through that two weeks of pain that I started at, at the very beginning. So, yeah, it's been a very good journey. I don't know how far I'm going to go with it. I don't know if I'm going to go a full marathon or a half marathon. I will increase it and do multiple races, but yeah, I don't know how far I'm going to go with it.

+ +

VICTORIA: Well, it's interesting. It reminds me how, like, anytime you do something new, you're forming new neural pathways in your brain, then you can get in a routine, and it becomes easier and easier every time you do it. So, I'm going to try to relate this back to our Product Design Sprint Kit. It's like a set of exercises you can learn how to do that might be difficult at first, but then it becomes a part of the way that you work and how you build products, right? So, why don't you tell me a little bit about it? Like, what is it? What is the product design kit that you just came out with?

+ +

FERDIA: The PDS kit or the Product Design Sprint Kit it was something that I'd kind of been playing around with in investment time for a while, and then spoke to Rami about it a couple of months ago, and he got on board. And it really accelerated what we were doing. And it was basically, like, a product design sprint is a known process in design and product design and product development. I think it was started by Google.

+ +

And, essentially, the concept is that you can take an idea that you have for something new and, in five days, go from that idea to creating something that can be user tested, and so getting real kind of validated feedback on your idea. Yeah, so try to do it in a compressed timeframe. That's why it's called a sprint. So, you're trying to do it within five days.

+ +

And the concept for kind of creating a kit that we could share to people beyond thoughtbot was that we tend to repeat a lot of the same instructions in each sprint, so we're running very similar exercises. The outcomes are slightly different, obviously, depending on the customer, but the exercises themselves are pretty similar. So, the [inaudible 06:42] kind of when we're talking to the customer are often very much the same.

+ +

And we just thought that we get a lot of inquiries from start-ups, I think probably maybe even more so in Europe, before they're funded and looking kind of for the first step. Like, what can they do? So, a lot of them, if they're not in a position to, say, pay for some of our design team to come on with them and run a sprint with them, we thought it'd be cool to be able to give them, well, you know, this is something free that you can run yourself with your team and will kind of get you on the ladder. It will hopefully give you something that you can then take to an investor or somebody that could potentially fund a kind of bigger sprint or maybe even an MVP build.

+ +

WILL: Let me ask you this: Why is design so important? So, if I'm a developer, or a CTO, or a CEO of whatever, why should I be an advocate for design?

+ +

RAMI: Well, over here at thoughtbot, we do a lot of iterative design. I think that's a key factor that we should take into consideration. With iterative design, it's the idea of designing something based on a validation or based on a user and doing it quickly and testing it to get feedback from the user or from the market and adjust from there, instead of just designing something in, like, a silo and releasing it after six months and then discovering that you went off course four months ago. And that will cost you a lot of time, a lot of money, a lot of agony, I guess [laughs]. And it just generally will become a very frustrating process.

+ +

I've seen clients before thoughtbot where they come in and they've been working on this thing for six months, and they're just not releasing and pushing the release for month on month just because the CEO does not feel like it's at par with what he's using on, like, everyday apps. And he's, like, looking at, oh, I want to look like Instagram, or feel like Instagram, or feel like whatever they like when, in reality, products don't evolve that way.

+ +

And Instagram has already, I don't know, 12 years of development and design behind it. And you can't possibly expect your app that you're launching for your startup to feel the same, look the same, and all that stuff. That's why design is important. So, you just discover early on that you are on the right path and always correcting course with different design techniques, including the PDS.

+ +

FERDIA: What you're talking about there just de-risks a lot of stuff for people when they're trying to create something new. You could have the, you know, a really, really impressive product under the hood that can do a lot of really technical stuff. But if it's very hard to use, or if it's very hard to kind of tap into that magic that you've built on the development side, people just won't use it, and you won't be able to generate the revenue you want. So yeah, the user experience and kind of the design around that is really important to get people actually using your product.

+ +

VICTORIA: Yeah, I can relate to what you all have said. I've talked with founders before, who they maybe have a lot of experience in the industry and the problem that they are trying to solve. They think I know what it should look like. I just need developers to build it. But the activities you described about the product design sprint and creating something where you can go out and test that theory, and then incorporate that feedback into your product, and doing it within five days, it seems like a really powerful tool to be able to get you on the right path and avoid hundreds of thousands of dollars of development spend, right?

+ +

FERDIA: Yeah, 100%, yeah. And, like, a typical outcome for a product design sprint will never be a fully polished, like, perfect design. That's just...it's not realistic. But what you will hopefully have by the end of that five days is you will know, okay, these are, like, five or six things that we're doing right, and these are things we should keep going with. And maybe here are three or four things that we thought users would like, or potential customers would like, and we are actually wrong about those. So, we need to change those things and maybe focus on something else.

+ +

So, as Rami said, design is an iterative process that is like your first iteration. But getting that feedback is so helpful because, as Rami said, if you spend six months developing something and figure out that 4 of the ten things that you built weren't needed or were wrong, or customers just didn't want them, that's a really, really expensive exercise. So, a design sprint, kind of if you're to do them on a continuous basis or every couple of months, can be a really helpful way to check in with users to make sure what you're committing your resources to is actually going to benefit them in the long run.

+ +

RAMI: Yeah. And I would also like to add, like, one of the outputs of a design sprint is a prototype. To me, I'm always like, seeing is believing. It's just better to have a prototype as a communication tool within the team with clients, with customers, with users, instead of having, like, a document or even just wireframes. It just doesn't really deliver what you're trying to do, like a prototype.

+ +

FERDIA: Yeah, 100%, Rami. And, like, on the prototype, like, a good comparison that people, if they're not in product development, might have seen it's like if you're building a house, like yourself, Victoria, a lot of architects will give you two-dimensional plans. And for people that aren't in the building industry, plans can be difficult to read or difficult to visualize what those actually look like.

+ +

But if you can give someone a 3D representation of the house, you know, they can see, oh yeah, this is what it's going to kind of look like and what it's going to feel like. And the prototype that Rami is talking about gives you exactly that. So, it's not just this is our idea; it's, this is actually what the thing could look like, and what do you think of that? So yeah, it's definitely a valuable output.

+ +

VICTORIA: We're having this debate about whether or not we need a designer for our renovation project. And I'm very much pro [laughs] designer. And maybe that's from my background and being in software development and, like, let's get an expert in here, and they will help us figure it out [laughs], and then we'll make less mistakes and less expensive mistakes going forward. So, I think there's a lot of analogies there.

+ +

So, this product design sprint is a service that we offer at thoughtbot as well, right? We do workshops and meetings together with the client, and you all have this idea to record the videos and put all the content out there for free. So, I'm curious how that conversation went within management at thoughtbot and how did the idea really get started and get some traction going.

+ +

FERDIA: The benefit of the Product Design Sprint Kit what you get out of it won't replace, say, doing a product design sprint with thoughtbot because you will have expert product designers or developers in the room with you to kind of share their ideas and their experience. So, the output you're going to get from running a sprint with thoughtbot will be more beneficial, definitely.

+ +

But what we were trying to, I suppose, cater for was people that fall in the gap, that they're not quite ready to bring thoughtbot on board, or they don't have enough funding to bring thoughtbot on board to do a product design sprint, or a longer discovery sprint, or something like that. But we want to be able to give those people in kind of the software community something actionable that they can actually take and use.

+ +

So, the first three days, I think, of the Product Design Sprint Kit will be really, really valuable to people. It'll really help them identify the problem that they're trying to solve and then to come up with a lot of different solutions and to try to pick one of those. And probably where it's going to be a bit more challenging if you don't have experience in design or in development will be around the prototype, which Rami had spoken about. You can kind of do some offline things, and there are ways to test things without, say, a high-fidelity prototype, but those high-fidelity prototypes, again, are something that could be helpful.

+ +

But thoughtbot has always had an approach of kind of giving stuff for free to the community, either open source or just letting people, yeah, letting people learn from our resources and from what we know. And so, yeah, this is just a way to, hopefully, cater to people that we currently can't work with for a variety of reasons but that this is something that they could maybe use in the meantime.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

WILL: So, can you break down...you said it's five days. Can you break down what is walking you through, like, each day? And, like, what experience do I have? Because I know, I've tried to get in Figma sometimes, and it's not easy. It's a pain at times. You're trying to maneuver and stuff like that. So, what do I have to do? Like, do you show me how Figma? Do you give me a template with Figma? Like, how do you help me with those things? And I know Miro and those things. So, like, walk me through each step of the sprint.

+ +

RAMI: Yeah, well, I mean, Figma and Miro are just tools that just became popular, I guess, after COVID. Design sprints used to be physical, in the same room as sprints. You would get the clients or the stakeholders in a room and do all that stuff. But Figma, FigJam, and, you know, kind of...I don't know if this was part of their, like, product thinking, but it kind of allowed doing full-on design sprints in their tools.

+ +

So, the first step or the first day would be, like, the understanding day where basically we gather information about the product, the users, what's out there, and just come up with a general plan on how to go forward.

+ +

And the second day would be divergent where we just look at what's out there and come up with these crazy ideas, kind of, like, a brainstorming thing but in a more inclusive, I guess, way and in a more organized way. So, you don't have people shouting over each other. Like, being anonymous also is important on this day, so nobody really knows what you're doing or saying. It's just ideas to remove bias.

+ +

Then, we'd have a converge day where we take all these ideas and consolidate them, which will be an input into the prototype phase.

+ +

And the last day is the test phase. I mean, each of these days you can talk...have a full podcast.

+ +

VICTORIA: I'm curious about when you're testing and when you're, like, I'll say thoughtbot is a global company, right? And so, there's lots of different types of users and groups that you might be wanting to use your app. I'm thinking, you know, sometimes, in particular, some of the applications I've been looking at are targeting people who maybe they don't have an iPhone. They maybe have lower income or less means and access to get products and services. So, how does your design sprint talk to designing for different types of communities?

+ +

FERDIA: I think that's a great question, Victoria. I would say the first thing on it is that we'd often get a lot of people with a startup idea, and they would come in and say, "You know, this app could be used by everybody. So, like, we have kind of no beachhead market or no target market. Like, this would be great for the whole world." That's a very nice thought to have if it is something that could potentially be used by everyone.

+ +

But we would generally say you should pick a smaller niche to try to establish yourself in first and hit a home run basically with that niche first, and then kind of grow from there. We would normally say to people as, like, again, this is going back to what Rami said about the iterative process. If at the end of the five days, you've picked the wrong beachhead market and it doesn't hit home with them, that's fine. You can just do another sprint next week or next month on a different kind of subsection of the market.

+ +

So, I think picking a fairly niche sector of the market is a good starting point. You then run your product design sprint with that niche in mind and try to talk to five users from that. And, generally, we say five because, generally, if you have less than or fewer than five people contributing, you probably won't get enough data. You know that you could...if you only test with two people, you probably wouldn't get a thorough enough data set. And then, normally, once you go over five, you kind of start seeing the patterns repeating themselves. You get kind of diminishing returns, I guess, after five.

+ +

So, that would generally be the approach. Try to identify your beachhead market, the one you want to go into first, and then you will try to talk to five people generally from the founding team's network that match the criteria of that beachhead market. And, in some ways, just the final point, I guess, is the fact that you have to pull them from your network is actually beneficial to kind of make you narrow down and pick a niche market that's accessible to you because you know people in it.

+ +

RAMI: And maybe if you don't know anybody, then maybe you're in the wrong industry.

+ +

FERDIA: Yeah. Great point. Great point because, yeah, it makes it a lot easier. It's nice to have loads of industries that you could go into, but it makes it so much easier if the founding team have contacts in an industry. Yeah, it makes a big difference.

+ +

WILL: Yeah, I was going through the different days and kind of what you were talking about. So, like, one day is brainstorming, then converge, and then prototyping, and user testing kind of on that last day. It seems like it's completely laid out. Like, you're giving away all the keys except experience from the actual designer. It seems like it's all laid out. Was that the goal to, like, really have them fully laid out? Hey, you can do this from point A to point B, and this is what it looks like.

+ +

Is that something that you're...because that's what it looks like as my experience with designers and stuff. And if that's the case, what was your reasoning behind that, to give it away? For someone, like you said, like a startup they can do this because you pretty much laid it all out. I'm not a designer, and I don't claim to, but it looks like I can do this from what you laid out.

+ +

RAMI: Well, first of all, like, at thoughtbot, we're really big into open source, and open source is not always just development. It can be these kinds of things, right? It's not a trade secret. It's not something we came up with. We maybe evolved it a little bit from Google, I think it was Google Ventures, but we just evolved it.

+ +

And, at the end of the day, it's something that anybody can do. But, actually, taking the output from it is something that we do as thoughtbot. Like, okay, you have a prototype. That's great. You tested it, but okay, now we want to make it happen. If you can make it happen, then great, but the reality is that a lot of people can't, and that's why there are, like, a gazillion agencies out there that do these things.

+ +

So, the reasoning, I guess, and Ferdia can expand on, is, like, if somebody takes this and comes up with a great prototype and feels confident that they actually want to develop this idea, who else would be better than thoughtbot who actually gave them the keys to everything?

+ +

FERDIA: Yeah, 100%, Rami. Yeah, it's essentially just helping people get on the first rung of the product development ladder with fewer barriers to entry, so you don't have to have a couple of thousand dollars saved up to run a sprint. This kind of gives you a really, really low entry point.

+ +

And I guess there's another use case for it where you would often have potentially founders or even companies that want to release a new product or feature. And they might reach out to thoughtbot because they want to develop something, and they're very sure that this is what we want to develop. And, you know, maybe they don't want to engage with a product design sprint or something like that if they think they know their market well enough.

+ +

And this could be a handy tool just to say to them, "Okay, if you can go away, take this free resource for a week, run a product design sprint with your team, and come back to us and tell us that nothing has changed, you know that you've correctly identified the right market and that you've validated your theories with them," then we can kind of jump into development from there.

+ +

But yeah, it can be a good way, I suppose, to show the value of doing a product design sprint. As I said, a lot of people come in, and they have great ideas, and they can be fairly certain that this is going to work. But a product design sprint is really, really valuable to validate those before you dive into building.

+ +

VICTORIA: And can you give us an example from your experience of a client who went through a product design sprint and decided to pivot maybe their main idea and go in a different direction?

+ +

FERDIA: I'm not sure off the top of my head, Victoria, if I can pick one that pivoted in a completely different direction, but definitely, like, some of the clients that we worked with on the Fusion team in thoughtbot ended up changing direction or changing the customer that they were going after. So, some people might have had an idea in their head of who they wanted to tackle and might have had a particular, say, feature prioritized for that person. And through the product design sprint, we were able to validate that, actually, this feature is not that important. This other feature is more important, and it's more important to a different group than kind of what you initially thought. That would happen fairly regularly on a product design sprint.

+ +

Like, I think if you look at the potential outcomes, one being that everything's exactly as you thought it was and you can proceed as planned, or the opposite end of the spectrum where nothing is as you thought it was and, you know, you kind of have to go back to the drawing board, it's very rare that you're on either end of those after a product design sprint. Most of the time, you're somewhere in the middle. You've changed a few things, and you're able to keep a few things, and that's kind of normally where they land. So, I would say nearly every customer that we've done a product design sprint with has changed some things, but never kind of gone back to the drawing board and started from scratch.

+ +

RAMI: It's usually prioritization and just understanding what to do and also, like, get into the details of how to do it. That's where the value comes in. But, like, completely pivoting from a food delivery app to, I don't know, NFTs [laughs] never really happened.

+ +

VICTORIA: Yeah, and it doesn't have to necessarily be a big pivot but looking for, like, a real-world example, like, maybe you're building an e-commerce site for a plant marketplace or something like that.

+ +

RAMI: Yeah. Well, we had a self-help app where they already had the app in the market. It was a progressive web app, and they were really keen on improving this mood tracker feature. But then we did a product design sprint, and they had a bunch of other features, and that exercise kind of reprioritized. And the mood tracker ended up not being released in the first version of the actual mobile app because we were also developing a native app.

+ +

VICTORIA: Gotcha. So, they were pretty convinced that this was an important feature that people wanted to track their mood in their app. And then, when they went through and tested it, users were actually like, "There's this other feature that's more important to me."

+ +

FERDIA: One example of another client that we did, which was a kind of a wellness app, they wanted it to feel like a friend in your pocket. So, they were looking at ways to integrate with WhatsApp that you'd get notifications via WhatsApp. So, they would kind of be, like, friendly messages to people as if it's your friend, you know, texting you to check in. And that was kind of an idea going into it, and users did not like that at all. Like, they really didn't like that.

+ +

So, we ditched that [inaudible 25:49] completely. But, again, that could have been something that they would have spent a long time developing to try to implement, and then to have users say this would have been a very, very costly waste of time. So, we figured that out in a few days, which was a money saver for the team.

+ +

VICTORIA: And it must be pretty emotional to have that feedback, right? Like, it's better to get it early on so that you don't invest all the money and time into it. But as a founder, I'm sure you're so passionate about your ideas, and you really think you have the answers from your experience, most likely. So, I'm curious if there's any kind of emotional management you do with clients during this product design sprint.

+ +

FERDIA: I think it definitely is. I think people, as I said, often come in with very strong opinions of what they feel will work. And it might even be a product that they specifically want, or they might be one of those potential users. And I actually think, say, engaging an agency like thoughtbot to design something like that, if we felt that they were going down the wrong path, that could be actually quite difficult to do. But because of product design sprints, you are user-testing it. The founders are hearing this feedback from the horse's mouth, so to speak. They're hearing it directly from potential customers. So, it's a lot more black and white.

+ +

Now, sometimes, it might still be a case that a founder then doesn't want to proceed with that idea if it's not kind of going to be the way that they wanted it to be, and that's fair enough as well. But the feedback, as I said, it tends not to be that the idea is completely scrapped. It just means that you move a couple of things around. As Rami said, you deprioritize some things and prioritize other things for the first version, and that tends to be the outcome of it.

+ +

VICTORIA: Are the users always right, or is it sometimes you can have an idea that persist, despite the early feedback from users?

+ +

RAMI: Interesting question. Like, I see the parallels you're doing with the customer is always right, yeah. But the thing is, like, that's just my opinion, I think. We tested with users, and we kind of observe how they react to it and how they use the prototype.

+ +

So, it's not like an opinion session or, like, a focus group where they're actually giving...a user can say something and do something else or react in a different way. But yeah, it's a fine line, I think. But I would be really surprised if ten users would agree on something and say something, and their behavior also would reflect that, and we won't pick up on.

+ +

VICTORIA: Yes, I like the distinction you're making between what they say and then what the behavior shows, right?

+ +

FERDIA: I think something important there as well, like you'll often hear it in design communities, is that you should listen to the feedback from customers but maybe not the solutions that they're proposing. Because, at the end of the day, like, thoughtbot have experts in product design and product development, so we want to figure out from the user's perspective what they want to achieve and maybe what their problems are, but not necessarily take into account or just, I suppose, not necessarily just follow exactly what they say the solution should be.

+ +

You're kind of looking for the problems and the things that they're struggling with. You're trying to pick those up rather than just to do the solution that the customer is telling you. And you'll see that in a lot of startups as well that, you know, it's the famous Henry Ford quote about, you know, "If I'd listened to my customers, I'd have designed a faster horse." Sometimes, you need to listen to the problem, and the problem is getting from A to B faster, and then you come up with a solution for that rather than the solution that's been recommended to you.

+ +

WILL: I want to pivot a little bit and ask you both, why did you get into design?

+ +

FERDIA: I actually did architecture in university, and there were aspects of that I liked. Funnily enough, it's a fairly similar process to designing for software, and then it's an iterative approach. You're given a brief and yet you kind of take a concept forward. But then, when you apply for planning, you have to make changes. And when you kind of put [inaudible 29:41], you make changes. So, you're constantly, I suppose, designing iteratively.

+ +

And then I got into startups and was kind of wearing a lot of different hats in that startup sort of world. But the product was the one area that always kind of got me excited. So, you know, if you tried to make a sale with a particular customer and they didn't want to go over something, like, coming home and trying to figure out, okay, how can I fix that problem with the product so that next time when I go to a customer, and they'll say, "Yes"? That was kind of what always gave me the adrenaline.

+ +

So yeah, comparatively, between architecture and software, the turnaround times in software is so much faster that I think it's more enjoyable than architecture. You kind of can really see progress. Product design sprint in five days. You can kind of take something a long way whereas designing a building is a bit slower, but it's always kind of been some area of interest. Well, what about you, Rami?

+ +

RAMI: Well, I wanted to become a hacker, but I ended up to be a designer [laughs]. No, really, when, like, in middle school, I really wanted to be a hacker and kept looking up what is it. Like, I see it in all these movies really cool, and I wanted to understand, like, how it's done online. And I saw, like, everybody is talking about this weird, little thing called command line. And it turns out, like, all these hacking, quote, unquote, "hacking tutorials" were done on Linux. So, I started looking into Linux and got into Linux.

+ +

From there, I started blogging about Linux, and then I just really got into technology. I was in marketing. By then, I was a marketing major. So, that got me into blogging into, like, Linux and open source, which kind of triggered in my head, okay, I need to maybe pivot to a different career path. So, I did a master's degree in information management. Over there, I stumbled into design. The information management school that I was in, like, it was an interdisciplinary school at, like, design, coding, and business all mixed in. So, I stumbled in design there.

+ +

VICTORIA: That's how you all got started. And now you've put this product out there pretty recently. I'm curious if you have thought about how you would measure the success of this effort. So, how do you know that what you put out there in the product designs kit is helping people or achieving the goals that you had originally set out to?

+ +

FERDIA: Initially, Victoria, we obviously like to see the view counts going up on YouTube, and we're always open to feedback. So, like, at the end of each video and in the resources and stuff, we've got contact us kind of links and stuff. So, if people have feedback on how we could make it better or more useful, that would be really, really welcome. So, do feel free to reach out to us.

+ +

And kind of the ultimate success metric for us would be to have somebody come to us in future and say, "Oh, we used that Product Design Sprint Kit that you produced before, and we either got funding or, you know, we got so much value out of it that we'd like to do a full product design sprint or an MVP build, or something like that."

+ +

And the equivalent that we would kind of have a lot of in thoughtbot would be, say, gems in development where we would get people reaching out and say, "We use that gem all the time. We know about thoughtbot because of that." That kind of is a way to establish trust with potential customers. So, we're hoping that this is somewhat of an equivalent on the design side.

+ +

WILL: Oh, it's been great chatting with both of you about design and what you came up with this. I really like it. I'm going to look more into it.

+ +

VICTORIA: Yes. Thank you both for joining us. And I had one question. So, the sprint is the short-term. What would be, like, a product design marathon? Like, what's [chuckles] the big picture for people who are building products? Maybe that's a silly question, but...

+ +

RAMI: No, it's not, I mean, but I would guess it's actually building the product and having a successful product in the market and iterate over it for years and years.

+ +

VICTORIA: Yeah. So, it's a one-week sprint, and you could do it over and over again for many years just to fine-tune and really make sure that your product is meeting the needs of the people you were hoping to reach. Wonderful.

+ +

All right. Well, thank you both so much for joining us.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.
+Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode of the Giant Robots Smashing Into Other Giant Robots podcast, hosts Will Larry and Victoria Guido discuss the intricacies of product design with thoughtbot's Senior Designers, Rami Taibah and Ferdia Kenny. They delve into the newly launched Product Design Sprint Kit by thoughtbot, which is designed to streamline and enhance product development.

+ +

Ferdia and Rami explain how the kit aims to compress the design process into a focused five-day sprint, allowing teams to move from idea to user-tested prototype efficiently. They discuss the genesis of the kit, its components, and the rationale behind making it openly available.

+ +

Towards the end of the episode, the conversation shifts towards the broader implications of design in product development, the iterative nature of design sprints, and the value of user feedback in guiding product decisions. Rami and Ferdia share real-world examples where product design sprints led to significant pivots or refinements in product strategy, emphasizing the critical role of user testing in uncovering genuine user needs versus presumed functionalities.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL:  This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your co-host, Victoria Guido. And with us today are Rami Taibah, Senior Designer at thoughtbot, and Ferdia Kenny, Senior Designer at thoughtbot, here to talk to us about the newly released Product Design Sprint Kit from thoughtbot. Ferdia and Rami, thank you for joining us. Why don't you introduce yourselves a little bit, tell us a little bit about each of your background while we get started?

+ +

FERDIA: I'm Ferdia. I'm a product designer at thoughtbot. I've been with the company for nearly three years now. I'm based in Dublin in Ireland, but I'm from the West Coast of Ireland. Happy to be on the podcast. It's my first time coming on, so that'll be a new experience.

+ +

RAMI: Yeah, so I'm Rami Taibah, and I am also a senior designer at thoughtbot for nearly two years. I'm also from the West Coast, like Ferdia, but I didn't move. I'm still where I'm from [laughs].

+ +

VICTORIA: Yeah, so just to get us warmed up here, why don't you tell us something interesting going on in your lives outside of work you want to share with the group?

+ +

FERDIA: For me, I'm trying to do a bit of traveling at the moment. So, one of the benefits, obviously, of working with thoughtbot is that we are a fully remote company. As long as we're kind of staying roughly within our time zones, we can kind of travel around a little bit. So, I'm actually in France at the moment and going to Spain in March. So yeah, I'll be working from a couple of different spots, which is really cool and a lot of fun.

+ +

RAMI: Yeah, it's pretty cool. I always see Ferdia, like, having these meetings in, like, these different locations. Just a few months ago, you were in Italy, right?

+ +

FERDIA: Yeah. Yeah [laughs], that's right, yeah.

+ +

RAMI: Yeah. So, for me, well, first of all, I got a new baby, new baby girl, exactly on New Year's Day, so that's interesting, going back home every day and seeing how they evolve very quickly at this age. Another thing is I've been doing a lot of Olympic weightlifting. It's probably one of the consistent things in my life since COVID. I was a CrossFitter. I got out of that, thankfully. But coming back into, like, after quarantine, weightlifting seemed like a good choice because it doesn't have the social aspect of CrossFit, and I can just do it on my own.

+ +

WILL: How is your sleep?

+ +

RAMI: I'm a heavy sleeper, and I feel guilty about it, so no problems here [laughs].

+ +

WILL: Yeah, that was one thing I'm still trying to recover from–sleep. I love my sleep. And so, I know some people can do with little sleep, but I like sleep. And so, I'm just now recovering, and we're almost two years since my baby boy, so [chuckles]...

+ +

RAMI: Yeah, I'm a heavy sleeper. And I tell my wife, like, we have this understanding, like, if you ever need anything from me besides...because she has to be up for, like, breastfeeding, just kick me. I'll wake up. I'll do whatever you need [laughs].

+ +

WILL: That's awesome.

+ +

VICTORIA: So, my understanding is that if you want to get better at any sport, if you get better at deadlifting, that will help you progress in your sport pretty much. That's my [laughs] understanding. I don't know if you all feel that way as well.

+ +

RAMI: Oh, I never heard that. But I do know that these three, like, three or four basic lifts just basically boosts you in everything else, like, deadlifts, back squats. And what was the third one? Bench press, I guess.

+ +

FERDIA: And pull-ups as well, I think, is a compound exercise. I just hate like this. I look for an excuse to skip them, so...[chuckles]

+ +

VICTORIA: Yeah, the four essential exercises, but it doesn't mean that they're fun, right?

+ +

FERDIA: [chuckles]

+ +

VICTORIA: Yeah. And then, Will, I heard you were also training for a new activity, the 5k.

+ +

WILL: Yeah, I'm going to run a 5k with my best friend. He's coming into town. So, I'm excited about it. I've always tried to do running, but my form was horrible, and I'll get injured, tried to do too much. And I think I finally figured it out, taking it slow, stretching, making sure my form is correct. So, it's been good. I've enjoyed it. And it's interesting looking at what I'm doing now versus when I first started. And I was like, whoa, like, when I first started, I couldn't even run a mile, and I'd be out of breath and dying and just like, ah, and then now it's like, oh, okay, now I'm recovered, and I can walk it off.

+ +

So, one thing it's taught me is just consistent, being consistent because I feel like with working out and running, you have this, like, two-week period that it's just hard. Everything hurts. Your body is aching. But then after that, your body is like, okay, you're serious. Okay, then, like, I can adjust and do that. And then once you get over that two weeks, it's like, oh, okay, like, still, like, sometimes I still push it and get sore, but for the most part, my body is like, okay, I get it. Let's do this.

+ +

And then now, compared to before, now I'm just like, I can't stop because I don't want to go back through that two weeks of pain that I started at, at the very beginning. So, yeah, it's been a very good journey. I don't know how far I'm going to go with it. I don't know if I'm going to go a full marathon or a half marathon. I will increase it and do multiple races, but yeah, I don't know how far I'm going to go with it.

+ +

VICTORIA: Well, it's interesting. It reminds me how, like, anytime you do something new, you're forming new neural pathways in your brain, then you can get in a routine, and it becomes easier and easier every time you do it. So, I'm going to try to relate this back to our Product Design Sprint Kit. It's like a set of exercises you can learn how to do that might be difficult at first, but then it becomes a part of the way that you work and how you build products, right? So, why don't you tell me a little bit about it? Like, what is it? What is the product design kit that you just came out with?

+ +

FERDIA: The PDS kit or the Product Design Sprint Kit it was something that I'd kind of been playing around with in investment time for a while, and then spoke to Rami about it a couple of months ago, and he got on board. And it really accelerated what we were doing. And it was basically, like, a product design sprint is a known process in design and product design and product development. I think it was started by Google.

+ +

And, essentially, the concept is that you can take an idea that you have for something new and, in five days, go from that idea to creating something that can be user tested, and so getting real kind of validated feedback on your idea. Yeah, so try to do it in a compressed timeframe. That's why it's called a sprint. So, you're trying to do it within five days.

+ +

And the concept for kind of creating a kit that we could share to people beyond thoughtbot was that we tend to repeat a lot of the same instructions in each sprint, so we're running very similar exercises. The outcomes are slightly different, obviously, depending on the customer, but the exercises themselves are pretty similar. So, the [inaudible 06:42] kind of when we're talking to the customer are often very much the same.

+ +

And we just thought that we get a lot of inquiries from start-ups, I think probably maybe even more so in Europe, before they're funded and looking kind of for the first step. Like, what can they do? So, a lot of them, if they're not in a position to, say, pay for some of our design team to come on with them and run a sprint with them, we thought it'd be cool to be able to give them, well, you know, this is something free that you can run yourself with your team and will kind of get you on the ladder. It will hopefully give you something that you can then take to an investor or somebody that could potentially fund a kind of bigger sprint or maybe even an MVP build.

+ +

WILL: Let me ask you this: Why is design so important? So, if I'm a developer, or a CTO, or a CEO of whatever, why should I be an advocate for design?

+ +

RAMI: Well, over here at thoughtbot, we do a lot of iterative design. I think that's a key factor that we should take into consideration. With iterative design, it's the idea of designing something based on a validation or based on a user and doing it quickly and testing it to get feedback from the user or from the market and adjust from there, instead of just designing something in, like, a silo and releasing it after six months and then discovering that you went off course four months ago. And that will cost you a lot of time, a lot of money, a lot of agony, I guess [laughs]. And it just generally will become a very frustrating process.

+ +

I've seen clients before thoughtbot where they come in and they've been working on this thing for six months, and they're just not releasing and pushing the release for month on month just because the CEO does not feel like it's at par with what he's using on, like, everyday apps. And he's, like, looking at, oh, I want to look like Instagram, or feel like Instagram, or feel like whatever they like when, in reality, products don't evolve that way.

+ +

And Instagram has already, I don't know, 12 years of development and design behind it. And you can't possibly expect your app that you're launching for your startup to feel the same, look the same, and all that stuff. That's why design is important. So, you just discover early on that you are on the right path and always correcting course with different design techniques, including the PDS.

+ +

FERDIA: What you're talking about there just de-risks a lot of stuff for people when they're trying to create something new. You could have the, you know, a really, really impressive product under the hood that can do a lot of really technical stuff. But if it's very hard to use, or if it's very hard to kind of tap into that magic that you've built on the development side, people just won't use it, and you won't be able to generate the revenue you want. So yeah, the user experience and kind of the design around that is really important to get people actually using your product.

+ +

VICTORIA: Yeah, I can relate to what you all have said. I've talked with founders before, who they maybe have a lot of experience in the industry and the problem that they are trying to solve. They think I know what it should look like. I just need developers to build it. But the activities you described about the product design sprint and creating something where you can go out and test that theory, and then incorporate that feedback into your product, and doing it within five days, it seems like a really powerful tool to be able to get you on the right path and avoid hundreds of thousands of dollars of development spend, right?

+ +

FERDIA: Yeah, 100%, yeah. And, like, a typical outcome for a product design sprint will never be a fully polished, like, perfect design. That's just...it's not realistic. But what you will hopefully have by the end of that five days is you will know, okay, these are, like, five or six things that we're doing right, and these are things we should keep going with. And maybe here are three or four things that we thought users would like, or potential customers would like, and we are actually wrong about those. So, we need to change those things and maybe focus on something else.

+ +

So, as Rami said, design is an iterative process that is like your first iteration. But getting that feedback is so helpful because, as Rami said, if you spend six months developing something and figure out that 4 of the ten things that you built weren't needed or were wrong, or customers just didn't want them, that's a really, really expensive exercise. So, a design sprint, kind of if you're to do them on a continuous basis or every couple of months, can be a really helpful way to check in with users to make sure what you're committing your resources to is actually going to benefit them in the long run.

+ +

RAMI: Yeah. And I would also like to add, like, one of the outputs of a design sprint is a prototype. To me, I'm always like, seeing is believing. It's just better to have a prototype as a communication tool within the team with clients, with customers, with users, instead of having, like, a document or even just wireframes. It just doesn't really deliver what you're trying to do, like a prototype.

+ +

FERDIA: Yeah, 100%, Rami. And, like, on the prototype, like, a good comparison that people, if they're not in product development, might have seen it's like if you're building a house, like yourself, Victoria, a lot of architects will give you two-dimensional plans. And for people that aren't in the building industry, plans can be difficult to read or difficult to visualize what those actually look like.

+ +

But if you can give someone a 3D representation of the house, you know, they can see, oh yeah, this is what it's going to kind of look like and what it's going to feel like. And the prototype that Rami is talking about gives you exactly that. So, it's not just this is our idea; it's, this is actually what the thing could look like, and what do you think of that? So yeah, it's definitely a valuable output.

+ +

VICTORIA: We're having this debate about whether or not we need a designer for our renovation project. And I'm very much pro [laughs] designer. And maybe that's from my background and being in software development and, like, let's get an expert in here, and they will help us figure it out [laughs], and then we'll make less mistakes and less expensive mistakes going forward. So, I think there's a lot of analogies there.

+ +

So, this product design sprint is a service that we offer at thoughtbot as well, right? We do workshops and meetings together with the client, and you all have this idea to record the videos and put all the content out there for free. So, I'm curious how that conversation went within management at thoughtbot and how did the idea really get started and get some traction going.

+ +

FERDIA: The benefit of the Product Design Sprint Kit what you get out of it won't replace, say, doing a product design sprint with thoughtbot because you will have expert product designers or developers in the room with you to kind of share their ideas and their experience. So, the output you're going to get from running a sprint with thoughtbot will be more beneficial, definitely.

+ +

But what we were trying to, I suppose, cater for was people that fall in the gap, that they're not quite ready to bring thoughtbot on board, or they don't have enough funding to bring thoughtbot on board to do a product design sprint, or a longer discovery sprint, or something like that. But we want to be able to give those people in kind of the software community something actionable that they can actually take and use.

+ +

So, the first three days, I think, of the Product Design Sprint Kit will be really, really valuable to people. It'll really help them identify the problem that they're trying to solve and then to come up with a lot of different solutions and to try to pick one of those. And probably where it's going to be a bit more challenging if you don't have experience in design or in development will be around the prototype, which Rami had spoken about. You can kind of do some offline things, and there are ways to test things without, say, a high-fidelity prototype, but those high-fidelity prototypes, again, are something that could be helpful.

+ +

But thoughtbot has always had an approach of kind of giving stuff for free to the community, either open source or just letting people, yeah, letting people learn from our resources and from what we know. And so, yeah, this is just a way to, hopefully, cater to people that we currently can't work with for a variety of reasons but that this is something that they could maybe use in the meantime.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

WILL: So, can you break down...you said it's five days. Can you break down what is walking you through, like, each day? And, like, what experience do I have? Because I know, I've tried to get in Figma sometimes, and it's not easy. It's a pain at times. You're trying to maneuver and stuff like that. So, what do I have to do? Like, do you show me how Figma? Do you give me a template with Figma? Like, how do you help me with those things? And I know Miro and those things. So, like, walk me through each step of the sprint.

+ +

RAMI: Yeah, well, I mean, Figma and Miro are just tools that just became popular, I guess, after COVID. Design sprints used to be physical, in the same room as sprints. You would get the clients or the stakeholders in a room and do all that stuff. But Figma, FigJam, and, you know, kind of...I don't know if this was part of their, like, product thinking, but it kind of allowed doing full-on design sprints in their tools.

+ +

So, the first step or the first day would be, like, the understanding day where basically we gather information about the product, the users, what's out there, and just come up with a general plan on how to go forward.

+ +

And the second day would be divergent where we just look at what's out there and come up with these crazy ideas, kind of, like, a brainstorming thing but in a more inclusive, I guess, way and in a more organized way. So, you don't have people shouting over each other. Like, being anonymous also is important on this day, so nobody really knows what you're doing or saying. It's just ideas to remove bias.

+ +

Then, we'd have a converge day where we take all these ideas and consolidate them, which will be an input into the prototype phase.

+ +

And the last day is the test phase. I mean, each of these days you can talk...have a full podcast.

+ +

VICTORIA: I'm curious about when you're testing and when you're, like, I'll say thoughtbot is a global company, right? And so, there's lots of different types of users and groups that you might be wanting to use your app. I'm thinking, you know, sometimes, in particular, some of the applications I've been looking at are targeting people who maybe they don't have an iPhone. They maybe have lower income or less means and access to get products and services. So, how does your design sprint talk to designing for different types of communities?

+ +

FERDIA: I think that's a great question, Victoria. I would say the first thing on it is that we'd often get a lot of people with a startup idea, and they would come in and say, "You know, this app could be used by everybody. So, like, we have kind of no beachhead market or no target market. Like, this would be great for the whole world." That's a very nice thought to have if it is something that could potentially be used by everyone.

+ +

But we would generally say you should pick a smaller niche to try to establish yourself in first and hit a home run basically with that niche first, and then kind of grow from there. We would normally say to people as, like, again, this is going back to what Rami said about the iterative process. If at the end of the five days, you've picked the wrong beachhead market and it doesn't hit home with them, that's fine. You can just do another sprint next week or next month on a different kind of subsection of the market.

+ +

So, I think picking a fairly niche sector of the market is a good starting point. You then run your product design sprint with that niche in mind and try to talk to five users from that. And, generally, we say five because, generally, if you have less than or fewer than five people contributing, you probably won't get enough data. You know that you could...if you only test with two people, you probably wouldn't get a thorough enough data set. And then, normally, once you go over five, you kind of start seeing the patterns repeating themselves. You get kind of diminishing returns, I guess, after five.

+ +

So, that would generally be the approach. Try to identify your beachhead market, the one you want to go into first, and then you will try to talk to five people generally from the founding team's network that match the criteria of that beachhead market. And, in some ways, just the final point, I guess, is the fact that you have to pull them from your network is actually beneficial to kind of make you narrow down and pick a niche market that's accessible to you because you know people in it.

+ +

RAMI: And maybe if you don't know anybody, then maybe you're in the wrong industry.

+ +

FERDIA: Yeah. Great point. Great point because, yeah, it makes it a lot easier. It's nice to have loads of industries that you could go into, but it makes it so much easier if the founding team have contacts in an industry. Yeah, it makes a big difference.

+ +

WILL: Yeah, I was going through the different days and kind of what you were talking about. So, like, one day is brainstorming, then converge, and then prototyping, and user testing kind of on that last day. It seems like it's completely laid out. Like, you're giving away all the keys except experience from the actual designer. It seems like it's all laid out. Was that the goal to, like, really have them fully laid out? Hey, you can do this from point A to point B, and this is what it looks like.

+ +

Is that something that you're...because that's what it looks like as my experience with designers and stuff. And if that's the case, what was your reasoning behind that, to give it away? For someone, like you said, like a startup they can do this because you pretty much laid it all out. I'm not a designer, and I don't claim to, but it looks like I can do this from what you laid out.

+ +

RAMI: Well, first of all, like, at thoughtbot, we're really big into open source, and open source is not always just development. It can be these kinds of things, right? It's not a trade secret. It's not something we came up with. We maybe evolved it a little bit from Google, I think it was Google Ventures, but we just evolved it.

+ +

And, at the end of the day, it's something that anybody can do. But, actually, taking the output from it is something that we do as thoughtbot. Like, okay, you have a prototype. That's great. You tested it, but okay, now we want to make it happen. If you can make it happen, then great, but the reality is that a lot of people can't, and that's why there are, like, a gazillion agencies out there that do these things.

+ +

So, the reasoning, I guess, and Ferdia can expand on, is, like, if somebody takes this and comes up with a great prototype and feels confident that they actually want to develop this idea, who else would be better than thoughtbot who actually gave them the keys to everything?

+ +

FERDIA: Yeah, 100%, Rami. Yeah, it's essentially just helping people get on the first rung of the product development ladder with fewer barriers to entry, so you don't have to have a couple of thousand dollars saved up to run a sprint. This kind of gives you a really, really low entry point.

+ +

And I guess there's another use case for it where you would often have potentially founders or even companies that want to release a new product or feature. And they might reach out to thoughtbot because they want to develop something, and they're very sure that this is what we want to develop. And, you know, maybe they don't want to engage with a product design sprint or something like that if they think they know their market well enough.

+ +

And this could be a handy tool just to say to them, "Okay, if you can go away, take this free resource for a week, run a product design sprint with your team, and come back to us and tell us that nothing has changed, you know that you've correctly identified the right market and that you've validated your theories with them," then we can kind of jump into development from there.

+ +

But yeah, it can be a good way, I suppose, to show the value of doing a product design sprint. As I said, a lot of people come in, and they have great ideas, and they can be fairly certain that this is going to work. But a product design sprint is really, really valuable to validate those before you dive into building.

+ +

VICTORIA: And can you give us an example from your experience of a client who went through a product design sprint and decided to pivot maybe their main idea and go in a different direction?

+ +

FERDIA: I'm not sure off the top of my head, Victoria, if I can pick one that pivoted in a completely different direction, but definitely, like, some of the clients that we worked with on the Fusion team in thoughtbot ended up changing direction or changing the customer that they were going after. So, some people might have had an idea in their head of who they wanted to tackle and might have had a particular, say, feature prioritized for that person. And through the product design sprint, we were able to validate that, actually, this feature is not that important. This other feature is more important, and it's more important to a different group than kind of what you initially thought. That would happen fairly regularly on a product design sprint.

+ +

Like, I think if you look at the potential outcomes, one being that everything's exactly as you thought it was and you can proceed as planned, or the opposite end of the spectrum where nothing is as you thought it was and, you know, you kind of have to go back to the drawing board, it's very rare that you're on either end of those after a product design sprint. Most of the time, you're somewhere in the middle. You've changed a few things, and you're able to keep a few things, and that's kind of normally where they land. So, I would say nearly every customer that we've done a product design sprint with has changed some things, but never kind of gone back to the drawing board and started from scratch.

+ +

RAMI: It's usually prioritization and just understanding what to do and also, like, get into the details of how to do it. That's where the value comes in. But, like, completely pivoting from a food delivery app to, I don't know, NFTs [laughs] never really happened.

+ +

VICTORIA: Yeah, and it doesn't have to necessarily be a big pivot but looking for, like, a real-world example, like, maybe you're building an e-commerce site for a plant marketplace or something like that.

+ +

RAMI: Yeah. Well, we had a self-help app where they already had the app in the market. It was a progressive web app, and they were really keen on improving this mood tracker feature. But then we did a product design sprint, and they had a bunch of other features, and that exercise kind of reprioritized. And the mood tracker ended up not being released in the first version of the actual mobile app because we were also developing a native app.

+ +

VICTORIA: Gotcha. So, they were pretty convinced that this was an important feature that people wanted to track their mood in their app. And then, when they went through and tested it, users were actually like, "There's this other feature that's more important to me."

+ +

FERDIA: One example of another client that we did, which was a kind of a wellness app, they wanted it to feel like a friend in your pocket. So, they were looking at ways to integrate with WhatsApp that you'd get notifications via WhatsApp. So, they would kind of be, like, friendly messages to people as if it's your friend, you know, texting you to check in. And that was kind of an idea going into it, and users did not like that at all. Like, they really didn't like that.

+ +

So, we ditched that [inaudible 25:49] completely. But, again, that could have been something that they would have spent a long time developing to try to implement, and then to have users say this would have been a very, very costly waste of time. So, we figured that out in a few days, which was a money saver for the team.

+ +

VICTORIA: And it must be pretty emotional to have that feedback, right? Like, it's better to get it early on so that you don't invest all the money and time into it. But as a founder, I'm sure you're so passionate about your ideas, and you really think you have the answers from your experience, most likely. So, I'm curious if there's any kind of emotional management you do with clients during this product design sprint.

+ +

FERDIA: I think it definitely is. I think people, as I said, often come in with very strong opinions of what they feel will work. And it might even be a product that they specifically want, or they might be one of those potential users. And I actually think, say, engaging an agency like thoughtbot to design something like that, if we felt that they were going down the wrong path, that could be actually quite difficult to do. But because of product design sprints, you are user-testing it. The founders are hearing this feedback from the horse's mouth, so to speak. They're hearing it directly from potential customers. So, it's a lot more black and white.

+ +

Now, sometimes, it might still be a case that a founder then doesn't want to proceed with that idea if it's not kind of going to be the way that they wanted it to be, and that's fair enough as well. But the feedback, as I said, it tends not to be that the idea is completely scrapped. It just means that you move a couple of things around. As Rami said, you deprioritize some things and prioritize other things for the first version, and that tends to be the outcome of it.

+ +

VICTORIA: Are the users always right, or is it sometimes you can have an idea that persist, despite the early feedback from users?

+ +

RAMI: Interesting question. Like, I see the parallels you're doing with the customer is always right, yeah. But the thing is, like, that's just my opinion, I think. We tested with users, and we kind of observe how they react to it and how they use the prototype.

+ +

So, it's not like an opinion session or, like, a focus group where they're actually giving...a user can say something and do something else or react in a different way. But yeah, it's a fine line, I think. But I would be really surprised if ten users would agree on something and say something, and their behavior also would reflect that, and we won't pick up on.

+ +

VICTORIA: Yes, I like the distinction you're making between what they say and then what the behavior shows, right?

+ +

FERDIA: I think something important there as well, like you'll often hear it in design communities, is that you should listen to the feedback from customers but maybe not the solutions that they're proposing. Because, at the end of the day, like, thoughtbot have experts in product design and product development, so we want to figure out from the user's perspective what they want to achieve and maybe what their problems are, but not necessarily take into account or just, I suppose, not necessarily just follow exactly what they say the solution should be.

+ +

You're kind of looking for the problems and the things that they're struggling with. You're trying to pick those up rather than just to do the solution that the customer is telling you. And you'll see that in a lot of startups as well that, you know, it's the famous Henry Ford quote about, you know, "If I'd listened to my customers, I'd have designed a faster horse." Sometimes, you need to listen to the problem, and the problem is getting from A to B faster, and then you come up with a solution for that rather than the solution that's been recommended to you.

+ +

WILL: I want to pivot a little bit and ask you both, why did you get into design?

+ +

FERDIA: I actually did architecture in university, and there were aspects of that I liked. Funnily enough, it's a fairly similar process to designing for software, and then it's an iterative approach. You're given a brief and yet you kind of take a concept forward. But then, when you apply for planning, you have to make changes. And when you kind of put [inaudible 29:41], you make changes. So, you're constantly, I suppose, designing iteratively.

+ +

And then I got into startups and was kind of wearing a lot of different hats in that startup sort of world. But the product was the one area that always kind of got me excited. So, you know, if you tried to make a sale with a particular customer and they didn't want to go over something, like, coming home and trying to figure out, okay, how can I fix that problem with the product so that next time when I go to a customer, and they'll say, "Yes"? That was kind of what always gave me the adrenaline.

+ +

So yeah, comparatively, between architecture and software, the turnaround times in software is so much faster that I think it's more enjoyable than architecture. You kind of can really see progress. Product design sprint in five days. You can kind of take something a long way whereas designing a building is a bit slower, but it's always kind of been some area of interest. Well, what about you, Rami?

+ +

RAMI: Well, I wanted to become a hacker, but I ended up to be a designer [laughs]. No, really, when, like, in middle school, I really wanted to be a hacker and kept looking up what is it. Like, I see it in all these movies really cool, and I wanted to understand, like, how it's done online. And I saw, like, everybody is talking about this weird, little thing called command line. And it turns out, like, all these hacking, quote, unquote, "hacking tutorials" were done on Linux. So, I started looking into Linux and got into Linux.

+ +

From there, I started blogging about Linux, and then I just really got into technology. I was in marketing. By then, I was a marketing major. So, that got me into blogging into, like, Linux and open source, which kind of triggered in my head, okay, I need to maybe pivot to a different career path. So, I did a master's degree in information management. Over there, I stumbled into design. The information management school that I was in, like, it was an interdisciplinary school at, like, design, coding, and business all mixed in. So, I stumbled in design there.

+ +

VICTORIA: That's how you all got started. And now you've put this product out there pretty recently. I'm curious if you have thought about how you would measure the success of this effort. So, how do you know that what you put out there in the product designs kit is helping people or achieving the goals that you had originally set out to?

+ +

FERDIA: Initially, Victoria, we obviously like to see the view counts going up on YouTube, and we're always open to feedback. So, like, at the end of each video and in the resources and stuff, we've got contact us kind of links and stuff. So, if people have feedback on how we could make it better or more useful, that would be really, really welcome. So, do feel free to reach out to us.

+ +

And kind of the ultimate success metric for us would be to have somebody come to us in future and say, "Oh, we used that Product Design Sprint Kit that you produced before, and we either got funding or, you know, we got so much value out of it that we'd like to do a full product design sprint or an MVP build, or something like that."

+ +

And the equivalent that we would kind of have a lot of in thoughtbot would be, say, gems in development where we would get people reaching out and say, "We use that gem all the time. We know about thoughtbot because of that." That kind of is a way to establish trust with potential customers. So, we're hoping that this is somewhat of an equivalent on the design side.

+ +

WILL: Oh, it's been great chatting with both of you about design and what you came up with this. I really like it. I'm going to look more into it.

+ +

VICTORIA: Yes. Thank you both for joining us. And I had one question. So, the sprint is the short-term. What would be, like, a product design marathon? Like, what's [chuckles] the big picture for people who are building products? Maybe that's a silly question, but...

+ +

RAMI: No, it's not, I mean, but I would guess it's actually building the product and having a successful product in the market and iterate over it for years and years.

+ +

VICTORIA: Yeah. So, it's a one-week sprint, and you could do it over and over again for many years just to fine-tune and really make sure that your product is meeting the needs of the people you were hoping to reach. Wonderful.

+ +

All right. Well, thank you both so much for joining us.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.
+Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9Tu_hfjK + + ]]> + + Will Larry + Victoria Guido + + + 511: Tele911: Pioneering Remote Emergency Care with Dr. Ramon Lizardo + https://podcast.thoughtbot.com/511 + e35f2cfe-330e-4429-93c5-8092e40fc85c + Thu, 08 Feb 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido dives into the transformative world of Tele911 with its CEO, Dr. Ramon Lizardo. They explore how Tele911 is revolutionizing emergency healthcare by enabling paramedics to provide on-site treatments with remote guidance from doctors via iPads, significantly reducing the need for hospital visits. Dr. Lizardo discusses his motivations, the challenges of innovating within digital health, and how the COVID-19 pandemic catalyzed the acceptance and growth of Tele911, emphasizing the importance of a values-driven approach in navigating the expansion and ensuring data privacy. + 35:59 + no + + + Victoria Guido hosts Dr. Ramon Lizardo, CEO of Tele911, to discuss his company's innovative approach to emergency room diversion. Dr. Lizardo shares his journey from being a physician frustrated with the inefficiencies in emergency care to leveraging technology for better healthcare delivery. Tele911 is a service that transforms how emergency responses are handled. Rather than transporting patients to hospitals for non-critical care, Tele911 facilitates on-site treatments through paramedics equipped with iPads, allowing doctors to provide remote consultations, streamlining emergency services, and reducing unnecessary hospital visits and costs. +Dr. Lizardo's motivation for founding Tele911 was driven by personal experiences and the desire to improve emergency healthcare delivery. He recounts the challenges of pioneering in digital health, particularly the initial skepticism from investors and potential users about remote medical services. The COVID-19 pandemic became a turning point, accelerating acceptance and demand for Tele911's services, and Dr. Lizardo discusses the challenges of scaling the service, maintaining data privacy, and the importance of a values-driven approach to business. +Tele911 (https://www.tele911.com/) +Follow Tele911 on LinkedIn (https://www.linkedin.com/company/tele911/), X (https://twitter.com/tele911_), Instagram (https://www.instagram.com/tele911_/), or YouTube (https://www.youtube.com/@Tele911). +Follow Dr. Ramon Lizardo on LinkedIn (https://www.linkedin.com/in/ramonlizardomd/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA:  This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dr. Ramon Lizardo, CEO of Tele911, the leader in emergency room diversion. Dr. Lizardo, thank you for joining me. +DR. LIZARDO: Hey, Victoria. Good to connect with you once again. How are you? +VICTORIA: I'm good. It's raining in San Diego, so, unlike the song, it does happen sometimes in Southern California. +DR. LIZARDO: [laughs] But I love San Diego, by the way. It's one of those places where I feel like you have literally the perfect weather and perfect access to food. I'm a fan of Mexican food. And you can literally get the best Mexican food from, like, all of the trucks in San Diego. I truly believe that. +VICTORIA: That's true. The only better place to get Mexican food in San Diego is just to go to Mexico. You -- +DR. LIZARDO: There you go [laughter]. +VICTORIA: Yeah. I actually went to a startup event that was in Tijuana on a Tuesday night and just walked over the border and walked back, and it was great. +DR. LIZARDO: That is awesome. +VICTORIA: [laughs] +DR. LIZARDO: You know, there's a lot of expats living there now. It's really interesting, in Baja, California. +VICTORIA: Yeah, there's some back and forth there. And yeah, so just give me a little bit about your background and a little bit more about Tele911. +DR. LIZARDO: I'm a physician by training, but I've been in tech for about 15 years now. Tele911 is basically the child of a parent that was really frustrated with their specialty. So, I signed up for emergency medicine, and I realized a lot of what was happening was primary care. That led me to pursue a career in consulting. I worked at one of the Big Fours, interned at McKinsey, worked at Deloitte. Then, I started or joined a series of other startups that were very successful. +About three exits in, I said, hey, remember that idea that actually got me out? Being frustrated in ER because a lot of these patients didn't need to go to the hospital but were there. Well, this is how this comes about. Tele911 is basically the product of a lot of frustration, but a lot of innovation. And now we're pretty much reshaping history. In California, Texas, or Florida, when a patient calls 911 now, an ambulance shows up, but instead of being taken to the hospital, they're actually seen at home in something called treatment in place. We're the doctor on the iPad of the paramedic. +VICTORIA: So, thank you. That's a great interest. So, you had this background in consulting, and you had this experience as a physician, and then you decided to solve this really big problem with the cost around emergency rooms. So, before we dive into more around Tele911 and what you're doing with it, I thought we could warm up a little bit by just telling me, what gets you up in the morning? +DR. LIZARDO: [laughs] What gets me up in the morning? Well, I'm blessed because I have a two and a six-year-old. So [laughs], the truth is they're the ones that get me up. They usually wake up way before I do. So, if you come to this house about 5:15, 5:30, I feel like everyone's awake, and if you come to this house at 9:00 p.m., we're fast asleep. But what gets me up in the morning is that, above all, I'm a father and a husband. +I also run the nation's largest ER diversion company, which operates 24/7, and emergencies happen throughout the night. So, depending on what's happening throughout the night, I'm either up at 2:00, 4:00, 6:00 a.m. But what fuels me, though, every day is two things. One is I want to be an excellent husband and father, and I want to be present for everything that I can, especially when I'm home what's happening in my family's life. +But two, I'm part of this company that's changing the landscape of healthcare. You know, I've been part of other companies, but this is really one of those legacy events in life where I'm building something that's really changing the way healthcare is being delivered. And I understand that's my personal mission, and that's something that I strive for every day, and because of that, that drive just comes naturally. +I'm working on something that's way bigger than me, something that my kids are going to be reading about 10, 20, 30, 40 years from now, and probably they're going to say, "Yeah, that was innovative back then [laughs], but now this is how we receive healthcare, which is awesome." +VICTORIA: That's cool. So, it's like the impact your company's having and the drive to be a part of your family and, of course, your kids waking you up in the morning. And is it all of that, or is it also the chickens? Because I had chickens growing up. +DR. LIZARDO: [laughs] +VICTORIA: And they would always, like, crow, like, really early in the morning. +DR. LIZARDO: [laughs] Yeah, Victoria, that's awesome. If you come to this house at 5:45, what you're going to see is me in a robe in the middle of a snowstorm, at least for now, going out and changing the water of the chickens. So, one of the things that we've done with our household is made it more of a sustainable household. There's a living thing in every one of these rooms in our house. There's a guava tree growing in our living room, literally, a tree from the tropics growing in Princeton. There are citrus trees growing in our dining rooms. We grow about 30 different types of vegetables and fruits on our property. +And we also have livestock like chickens, which, honestly, I think we've learned that when we see things grow, we're more inclined to try them and taste them. You know, over the weekend, we had our neighbors, and one of the neighbors was like, "You have an actual olive tree from Italy growing in your..." it's about eight feet in our family room...sorry, in the kids' playroom. They were like, "I've never seen that before." I basically told them, "You should come back in a few months and pick some olives." +We love this ecosystem that we've built around sustainability, and it basically has brought our family together in order to work on things like trying to figure out how to grow these trees inside our house and outside our house. +VICTORIA: It must be such a cool experience for your kids to see something grow from a seed into something they can eat and, interact with and enjoy. And to bring it all back, I'm wondering, what was the seed for you to decide to focus on 911 or emergency services and solving that problem that people face? And maybe describe even a little bit of, like, what is the impact of divergent and emergency room services. +DR. LIZARDO: I feel like every great leader has something personal that's attached to what's fueling them, and, in my case, it's my dad. So, my dad has a heart condition, and, you know, there's been times where they've had to call 911. In the nation right now, 911 is a very antiquated and struggling system. As a matter of fact, ambulances have become very expensive Uber drivers. +Eight out of every ten calls that's medically related to a 911 does not need an ambulance and yet uses one to go to the hospitals. Most people in the U.S. believe that if they call 911 and they get an ambulance, they're going to be expedited at the hospital, which is not true. So, I know, unfortunately, that one day, my dad's going to call 911 because he really needs it, or someone in my family will. And I'm basically building a system that when he calls, he's going to get a faster response. By doing that, by basically doing what we do, we actually take care of the low-level emergency so when the real emergencies come, they actually are able to go through. +You know, Tele911 really tackles three things, three major problems in the industry. One is basically the pipes into 911 are overflooded. Sometimes, you're put on hold. Sometimes, you call 911, and they transfer you to another state because they're just so overrun. And basically, now we're creating pipes that actually allow them to take the real emergencies. +Two, the health plans. Every health plan in the United States 80% of what they do is actually try to figure out how to keep you out of the hospital. It's called utilization management. And it's just crazy how if you look at these monster health plans, their number one rule is, 'Please don't go to the hospital,' and that's the number one thing people actually do. And, for them, what we're solving is a huge problem because now they're able to take risk and actually control their budgets a lot better and, in effect, give better rates because they know that if they call 911 unnecessarily, they're going to be treated in place. +But lastly, it's because the people that are calling 911...medical debts is the number one reason for bankruptcy in the U.S. right now, and these people that are calling 911 they're going bankrupt. If you call 911 in California, in certain counties, the ambulance is $6,000, again, 6,000, even if you use it unnecessarily, let's say for a paper cut. And what I've done is basically created a company that solves for all three: for patients that need the care and basically think 911 is the only resource, for health plans that want to control these costs, but both fall for our lines. I want our lines to be free for the true emergencies. +VICTORIA: So, it was a personal experience with your father and the need for that. And I can relate to that, as well as having elderly family members who have conditions, who regularly need support. A lot of trouble is even just getting people to the hospital, and they can have services delivered right there in their home. +Anything in the early discovery phase of trying to solve this problem that caused you to pivot your strategy in your approach? +DR. LIZARDO: Absolutely. So, Tele911 right now is the product of, you know, an idea that was written on the back of a greasy napkin [laughs] at a Bojangles in South Carolina at a medical conference. But what you see today as the nation's leading ER diversion company and one of the most successful companies in digital healthcare is a product of three failures. We actually tried this multiple times and failed. And it wasn't until COVID happened, and we realized there was an acceleration and an acceptance for video calls, that we noticed that, hey, this is actually a better way, and it can happen now. +The irony of this [chuckles] is that we didn't think it was going to work so well. When we went commercial last year, we were like, maybe we could just do 300 calls. And in exchange, we started doing this by the thousands. A few months in, we're in the several thousands, and we're like, oh my God, this is working. And then, by the end of the year, we covered over 5 million lives by geography, and I realized we're on to something. Legislations passed with our name on it. So, you know, this idea that struggled, and we had to restart multiple times, we did not give up. And in exchange, I mean, we're literally making history. +VICTORIA: I love that. Yeah, so pre-COVID the idea of having medical services delivered virtually, I wonder what feedback you got from investors or from people interested in the idea at that time. +DR. LIZARDO: [laughs] No one wanted it [laughs]. No one wanted, you know, you show up to someone's house, and they're like, "Yeah, we're not going to take you to the hospital. We're going to have you see a doctor on the screen." They would be like, "No, I'm going," right? [laughs] Like, "This is not working." Also, even the counties, they were like, "This is too risky. What do you mean the doctor's going to be on the screen?" There wasn't a high level of adoption for something like this, and, you know, it struggled a lot. +I recall pitching the idea and people coming back to me and saying, "Well, you know, I love this. Tell me when it works. Tell me when you have enough traction." You know, it's funny because those are the same people now that are on our waitlist who now basically really need this, really want this, but we let them know there are 35 million more lives in coverage based on the counties just in our waitlist. It's a testament to just how awesome this product is and how fast it's adopted, but also the true need for something like this as part of the healthcare delivery continuum. +VICTORIA: Wow. Yeah. That's incredible that once you found the right fit, it became acceptable and even necessary to receive care virtually during the pandemic, and it really took off. So, now that you've gotten some initial traction and more than enough, what are your challenges that you see on the horizon? +DR. LIZARDO: So, a few challenges. Let's talk about how this went from, hey, a good idea to now a standard across different states. So, for example, in certain counties, and, I mean, this happens in every state as well. I'll give you an example of Florida. The hospitals are literally two hours away. Florida is incredibly rural. They either are able to see a doctor through our telemedicine platform, or they have to go on an ambulance for two hours, and that ambulance is away for six hours, like an entire shift. +So, one of the things that I've seen is a huge challenge is our product has grown expansively. So, what we do is we're basically building a larger network to be able to deliver for a larger volume. By the way, every time someone presses that button, within 40 seconds, on average, you get an emergency medicine physician that's board-certified in that state. And, I mean, that number used to be 2 minutes, then 1 minute, and now we're at 40 seconds. Eventually, it's going to be 10 seconds. +I'm pretty sure myself, someone who worked in emergency medicine, can't reach my friend in 10 seconds [chuckles], but this product does, which is what's fascinating about it, that high level of care. But with that same issue, we're now doing this for the tens of thousands. And within the next two years, we're going to be doing this for the hundreds, you know, we're forecasting hundreds of thousands of calls. +So, how do we prepare for that? How many emergency medicine physicians are in the U.S.? Can we cover those amount of lives? You know, do we continue to expand across auxiliary like APNs and higher tiers below MDs? So, these are the kind of things that I have to constantly think about. These are the kind of things that the government now reaches out to me to just get some advice on. Everyone's approved this. Now it's more, how do we scale this as we continue to make this the gold standard? +VICTORIA: The scaling becomes a top priority. And as a CEO who needs to build a management team around yourself, how do you identify where you have needs and where to find the people to perform the task you need to scale? +DR. LIZARDO: That really does depend on the role. One of the good things...so I used to sit on clinical boards for about 16 health plans, which allows me to have a very expansive network, particularly within healthcare and products. So, I know that the people are out there. The thing is, working at Tele911 is a very different type of environment than most people are used to. Here, we really fall fast collectively, lick our wounds, and redirect together. +Everyone has access to me. There's no hierarchy. It's more of a matrix environment, at least at this level. And then I tend to hire people at the management level that don't look like people that you would generally hire, and the reason is that there are two factors in order to be successful here at Tele911. You have to have that human component; to me, that's important. A lot of the people here...actually, I was sharing this with someone, but for the majority of my tenure here at Tele911, I was actually the youngest person at the company. I hire people with tenure and wisdom. +But a lot of the types of people that I hire here are actually outside of the industry, people who can bring in those thought processes over to Tele911 across repeatability, monetization, and scalability. Some of them are from manufacturing. Some of them...it really does depend. But when I look around the team, and I'm like, wow, you know, we are a team of misfits, but we produce amazing results. I mean, Tele911 in the last year alone, 3x volume and 5x just billing. So, we understand that we are part of something unique, and people just bring their ideas into that and adapt to it. +VICTORIA: Your approach, it sounds like, to play it back a little bit, is to find people who are smarter than you [laughs] about some things and then, yeah, really reach for wisdom and not fall into the same pattern that other organizations may be advised to follow to build their team because you have that insight into your market and your industry, and you can navigate what you need in order to scale. +DR. LIZARDO: Yeah. Also, at Tele911, this is innovation. So, there's really nowhere else to look for talent who have done this before. So, we really have to outsource from different industries. You know that adaptability is key, but what I really look for is repeatability. Has this person been ingrained with figuring out the pieces that make it whole and basically integrating them into our process, repeatable, monetizable, and scalable? +VICTORIA: Right. And maybe that answers my next question, but what core values drive your everyday decisions? +DR. LIZARDO: As I said before, and I think I said it at the beginning of the call, people know me as a father and a husband. That's who I am, and above all, that's my number one job. So, that human component is so critical in order for you to succeed here. Life happens while you're at Tele911. Parents get sick; kids have the flu; like, life happens. +And we have to understand that this is an empathetic environment. Someone in the management team had a baby today, and we were at a debrief meeting. And in the middle of a meeting, someone said, "The baby is here," [laughs] and everyone was rejoicing. If someone externally would have been in that meeting, they're like, "Who's baby, and why are we announcing it in the middle of a management meeting?" But, to us, is we function as a family, which is critical. +Another value that we really stress here is integrity. Because we're part of innovation, we have to be very clear about our numbers and very clear about how we're achieving our traction [inaudible 18:24]. I'm not really interested in the goal. I'm more interested in the process, but be very, very clear. You have to be creative. You know, I spent some time studying quantitative methodology over at Harvard, and repeatability is important, but being able to think outside the box because, again, this has never been done before. So, you have to look at this from an angle of, like, the art of the impossible, and then go and try it. +VICTORIA: Right, yeah. And I think it's really interesting, too, like, you know, when you think about making art or innovation, you can sometimes look and see how other people have done it. But then you have to decide what's your path. And, like, how do you solve for this particular problem? And, like, what can you learn from these [inaudible 19:08] this is the way you should or shouldn't do that; practice is really interesting, I think. +DR. LIZARDO: You know what? And I think that's probably been the most exciting part about this. I've never been in a situation where there was nothing to look back to reference. Like this is the first time in history that this is going, and it's accelerated so fast. We don't have a, hey, this is what good looks like. We basically have us, and we've had to adapt to that. +And along the way, what we've done is we've basically done basic, like, micro-moments of learning, adding on to those and saying, "Okay, this is what good looks like. But then what would great look like?" And I think that that's the example of...remember when I mentioned earlier, you know, it used to be 2 minutes, and 1 minute, you know, then 50 seconds, now 40 seconds. And we're like, "Hey, what if we could do 10 seconds where people press a button and get a board-certified doctor upon a 911 call?" And you're just like, yeah, that sounds impossible, but so did this idea now. So, we know the art of the impossible is just a few stone throws away as we continue to make traction. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint +VICTORIA: You know, there's the impact for the person experiencing an emergency and having it be able to resolve within their home. It also opens up that possibility of remote work for doctors and nurses, which I'm sure you know more than me about the current state of the strain on our medical system and the people who are working in it and how you think about the impact on them as well. +DR. LIZARDO: Just for context, my wife is a physician. And during COVID, we ended up having two kids, one right before and one during. And because of our–one–our parenting style but also our life choices, what we basically is we took turns at different points in order to stay home with our kids. But one of the things that, you know, have always bugged me is we saw every specialty practice virtually, but emergency medicine had to be practiced in the hospital. And unfortunately, because of that force and that strain in the system, less than 50% of the spots in emergency medicines were filled last year. People don't want to do it. +So, what we did is we went out to a lot of these parents and said, "Hey, do you want to join this network where you're able to see patients while you take a nap virtually?" And they're like, "Whoa, let me try that." And, Victoria, within three weeks, dads and moms were showing up in droves with their babies to the interviews, saying, "This is what my life looks like. He takes a nap between 2:00 and 4:00. Can I grab a shift for those 2 hours?" +And along the way, we ended up building the nation's largest virtual emergency medicine practice. Out of that pain point in us and just asking questions, we built this awesome system that now propels people to basically press a button and within 40 seconds, get a doctor. And I think that's the art of the impossible. We actually look at it and say, "Well, we could probably do something better on that." +But we've also now reshaped emergency medicine to the point that now we're the ones that are writing the fellowship for virtual emergency medicine. We are now creating the protocols and our data now is in journals as, hey, this is what the specialty should look like, and this is what they're able to do. So, we're equally as excited about that and just on the outcome. And it's just a huge honor. +VICTORIA: Wow, that's incredible that it would go in that direction, and you'd have this opportunity to really reshape an industry and define how even people learn how to perform emergency services and medicine. +DR. LIZARDO: [laughs] You know what the most amazing thing is? It's actually a lot easier than what other specialties have done because cardiologists have been able to, you know, see patients virtually, but they can't do an EKG. But our team can because the medics are on-site within 8 to 10 minutes of that call, and they're able to do an EKG. They're able to do a pulse ox. They're able to even do an IV drip. So, it's actually a new way to practice emergency medicine, where the medic is your hands, eyes, ears, but the doctor's basically working in conjunction with them, guiding them to best do the assessment. +VICTORIA: That's, like, such a revolutionary idea, and I think it's so cool. I'm curious: how do you perform user research and design for patients and for emergency responders? +DR. LIZARDO: [laughs] That's a question that we're actually working through right now. So, emergency responders they actually all have an iPad or a computer on them when they show up at your house. But that looks a lot more like the Nokia phone, the blue phone from back in the day. There's very little interaction on that iPad. And what we've done is we've put an app that's dynamic that allows them to basically best assess the patient, understand their protocol. So, it actually has its enhancer experience. +Also, remember, these medics are some of the smartest people on earth. I mean, they see patients more than doctors do. They know where they live. They know what their house looks like, and they've seen them thousands of times. So, what they're really good at is interacting with the iPad in a way that actually shows the surrounding, shows the patient, and shows what's important. +When it comes to our doctors, particularly in emergency medicine, they've been dying to basically practice virtual emergency medicine. So, what we've done is we've basically provided the initial data set of what they need, along with a video. But now we're actually augmenting that with additional data sets that allow them just to have a more comprehensive picture of the patient, including some look back data, what happened before, what should be happening afterwards, integration with their health plan. They actually have more data and a better experience with practicing in their home than if they were at the hospital. +VICTORIA: I appreciate that viewpoint. And I can understand how interesting it must be to design for those two different user personas. I'm curious; you mentioned data. What's your strategy around data privacy, and protection, and security in your application when you're at the same time trying to be very innovative and move very quickly? +DR. LIZARDO: Well, you know, I've always believed data is on a need-to-know basis, particularly because we're dealing with PHI. We're dealing with clinical data. I always tell people it's one thing for someone to walk into a hospital and tell you their name, last name, phone numbers. It's a whole other thing for you to go to their home and start gathering information. So, that is basically one of our key standards here. +We understand the gravity of the data that we're collecting and how critical it is, not only to health plans, health systems, but, above all, the member and how that privacy should be kept. And it's such a critical component to the company. As we continue to grow and mature, we've added additional layers in order to best protect the company–but above all, best protect the member in situations like this. +VICTORIA: Yeah, well, I appreciate that viewpoint. And starting, you know, probably your background as a consultant and also working as a doctor, you have a really deep understanding of the type of data you're dealing with and how sensitive it is. So, I appreciate that that's a priority for you within the company. What is the wind in your sails? What keeps you going? What keeps you committed to doing this work? +DR. LIZARDO: So, at this point, we are reshaping an entire history. We're literally going in the books now. So, now we can't stop this. I remember going through medical school and reading through some books. I was joining part of a community of doctors. Now, I'm rewriting and creating a new version of how this entire industry is being practiced. And understanding the gravity of such a monumental place in society that keeps me going. We can't stop it now. And that, to me, is what's monumental in all of this. +VICTORIA: That's great. So, it's that big overall vision of the impact you're making on not just a few people, a few million people, but really the whole industry and for many years to come. +DR LIZARDO: Exactly. Exactly. So, just so you know, for example, our patients aren't just...we don't just do emergency medicine. Some of our patients have psychiatric needs, and some of our patients have, you know, oncological needs. So, we are actually the largest lead generator of patients into the right system for the United States because we're capturing them at the 911 call. So, there are so many great companies out there, and their number one problem is not how to solve for the things that they build; it's who's going to use it. How do you find more customers to actually use it? +And what a lot of these companies have realized is, hey, we've been trying to find these people for years, and yet they're walking into Tele911's front door. How do we partner up with them, and how do we basically show Tele911 the services that differentiate us in order for them to walk the patients towards us? +VICTORIA: That's such a cool stat to have that you're really putting people into the right path. And you have these great things that you all have achieved. I wonder, do you write key objectives and results? Because some of those it sounds like, well, I don't know you would ever be able to dream up that result [laughs], right? +DR. LIZARDO: Yeah. Well, yeah, we do function. We actually have a KPI doc that we use. We all track, and everyone at the company has visibility into them. It's super critical for everyone to be aligned no matter the level for that. I always say KPIs should not be unachievable, but they should be a stretch. Tele911 expects to grow 10x on its second year; very, very, very few companies in the history of digital health have grown 10x. And we are not only with foresight of, like, how we're going to achieve that; we're actually executing on a trajectory for that 10x. +That's a dangerous number to say for me as a CEO. And I look at the KPIs, and I'm like, well, we did 5x last year and cut almost a million in operating costs, so we can do 10x this year. Any consultant outside would be like, "Yeah, that's crazy," and then they look at our model, and they're like, "Yeah, these people might be crazy enough to actually do it [laughs]." +VICTORIA: Well, that's great. I mean, and, I guess, it's, like, all about how do you picture it? Like, are you trying to make a goal that gets everyone excited and gets everyone motivated and dreaming of the art of the possible, or are you just trying to make it so that you can check it off at the end of the year [laughs], right? +DR. LIZARDO: No. Actually, checking things off is...listen, at the end of the year, we're looking at the following year's list, right? We're not just checking things off. What we're doing is, we understand our mission, and because of our mission, what we're saying is, how aligned with our mission are we? I don't know if that's a circle or a checkpoint, but it's more about alignment for that mission of democratizing access to the best care as fast as possible upon a 911 call. +VICTORIA: I love that. That makes a lot of sense to me, just bringing it all back to the mission and the impact and why we're all here in the first place, right? +DR. LIZARDO: Exactly. +VICTORIA: I love that. Wonderful. Do you have any questions for me? +DR. LIZARDO: No. I mean, it was excellent to, one, just to be able to connect with you, two, to be...actually, as I was talking through these questions with you, you know, I realized how...just for context, my favorite author is Walter Isaacson. If you ever have the chance, please read one of his books. I'm reading Benjamin Franklin, and I read Steve Jobs' book. There's actually a few books. My favorite book in the whole world is Da Vinci by Walter Isaacson. +And, you know, I hope that people listening to this they can do two things. One, they can get to know me just a little bit and the things that we're doing, but two, they can be inspired because I think that's what we really need. There's a lot of people starting companies just because someone's doing something they could do it better. I mean, that's cool and all, but just so you know, most of those things actually fail. There's a reason why 9 out of 10 companies actually fail today. We don't need more copycats. Think of the art of the impossible and create that, and then pursue it as if nothing's holding you back. And if you do so, you just might find yourself with a Tele911 company. +VICTORIA: Well, that gets me fired up. I'm excited. I really love that advice. I appreciate you sharing that with us. Is there anything else that you would like to promote today? +DR. LIZARDO: Yes. If I could just take a second to share about this, I know that a lot of people who listen to this podcast want to start companies. A lot of people are trying to figure out, how do I get my idea started? But I also realized a lot of these people really haven't written down their ideas. They're basically pursuing things that haven't really been written down. +And one of the things that I shared, if we go back to this podcast, I said, this idea was written on the back of a greasy napkin in South Carolina during a storm at a Bojangles. I literally recall seasoned fries, dipping it in the grease of the chicken, which is terrible for you, by the way, cleaning my hands, and writing on the back: What if people call 911 and this and this and this happened? +And if I could leave you with one thing is, please write your ideas down. Send me photos of your napkins [chuckles], like, share napkins with people on a plane, people on a train, share these ideas, write them down. Because the ideas that write them down basically have an opportunity to go back and reestablish, to modify. But one of the things that I know is these ideas eventually echo in eternity at one place or another. And when I leave, just with an encouragement, please just write your ideas down. +VICTORIA: Great advice. I really appreciate that. You know, everything in moderation. I'm not going to say fried chicken or fries is bad for you [laughter] because I like it. +DR. LIZARDO: [laughs] +VICTORIA: But yeah, no, thank you so much. I loved sharing with that and, hopefully, people will share your ideas. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Victoria Guido hosts Dr. Ramon Lizardo, CEO of Tele911, to discuss his company's innovative approach to emergency room diversion. Dr. Lizardo shares his journey from being a physician frustrated with the inefficiencies in emergency care to leveraging technology for better healthcare delivery. Tele911 is a service that transforms how emergency responses are handled. Rather than transporting patients to hospitals for non-critical care, Tele911 facilitates on-site treatments through paramedics equipped with iPads, allowing doctors to provide remote consultations, streamlining emergency services, and reducing unnecessary hospital visits and costs.

+ +

Dr. Lizardo's motivation for founding Tele911 was driven by personal experiences and the desire to improve emergency healthcare delivery. He recounts the challenges of pioneering in digital health, particularly the initial skepticism from investors and potential users about remote medical services. The COVID-19 pandemic became a turning point, accelerating acceptance and demand for Tele911's services, and Dr. Lizardo discusses the challenges of scaling the service, maintaining data privacy, and the importance of a values-driven approach to business.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA:  This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dr. Ramon Lizardo, CEO of Tele911, the leader in emergency room diversion. Dr. Lizardo, thank you for joining me.

+ +

DR. LIZARDO: Hey, Victoria. Good to connect with you once again. How are you?

+ +

VICTORIA: I'm good. It's raining in San Diego, so, unlike the song, it does happen sometimes in Southern California.

+ +

DR. LIZARDO: [laughs] But I love San Diego, by the way. It's one of those places where I feel like you have literally the perfect weather and perfect access to food. I'm a fan of Mexican food. And you can literally get the best Mexican food from, like, all of the trucks in San Diego. I truly believe that.

+ +

VICTORIA: That's true. The only better place to get Mexican food in San Diego is just to go to Mexico. You --

+ +

DR. LIZARDO: There you go [laughter].

+ +

VICTORIA: Yeah. I actually went to a startup event that was in Tijuana on a Tuesday night and just walked over the border and walked back, and it was great.

+ +

DR. LIZARDO: That is awesome.

+ +

VICTORIA: [laughs]

+ +

DR. LIZARDO: You know, there's a lot of expats living there now. It's really interesting, in Baja, California.

+ +

VICTORIA: Yeah, there's some back and forth there. And yeah, so just give me a little bit about your background and a little bit more about Tele911.

+ +

DR. LIZARDO: I'm a physician by training, but I've been in tech for about 15 years now. Tele911 is basically the child of a parent that was really frustrated with their specialty. So, I signed up for emergency medicine, and I realized a lot of what was happening was primary care. That led me to pursue a career in consulting. I worked at one of the Big Fours, interned at McKinsey, worked at Deloitte. Then, I started or joined a series of other startups that were very successful.

+ +

About three exits in, I said, hey, remember that idea that actually got me out? Being frustrated in ER because a lot of these patients didn't need to go to the hospital but were there. Well, this is how this comes about. Tele911 is basically the product of a lot of frustration, but a lot of innovation. And now we're pretty much reshaping history. In California, Texas, or Florida, when a patient calls 911 now, an ambulance shows up, but instead of being taken to the hospital, they're actually seen at home in something called treatment in place. We're the doctor on the iPad of the paramedic.

+ +

VICTORIA: So, thank you. That's a great interest. So, you had this background in consulting, and you had this experience as a physician, and then you decided to solve this really big problem with the cost around emergency rooms. So, before we dive into more around Tele911 and what you're doing with it, I thought we could warm up a little bit by just telling me, what gets you up in the morning?

+ +

DR. LIZARDO: [laughs] What gets me up in the morning? Well, I'm blessed because I have a two and a six-year-old. So [laughs], the truth is they're the ones that get me up. They usually wake up way before I do. So, if you come to this house about 5:15, 5:30, I feel like everyone's awake, and if you come to this house at 9:00 p.m., we're fast asleep. But what gets me up in the morning is that, above all, I'm a father and a husband.

+ +

I also run the nation's largest ER diversion company, which operates 24/7, and emergencies happen throughout the night. So, depending on what's happening throughout the night, I'm either up at 2:00, 4:00, 6:00 a.m. But what fuels me, though, every day is two things. One is I want to be an excellent husband and father, and I want to be present for everything that I can, especially when I'm home what's happening in my family's life.

+ +

But two, I'm part of this company that's changing the landscape of healthcare. You know, I've been part of other companies, but this is really one of those legacy events in life where I'm building something that's really changing the way healthcare is being delivered. And I understand that's my personal mission, and that's something that I strive for every day, and because of that, that drive just comes naturally.

+ +

I'm working on something that's way bigger than me, something that my kids are going to be reading about 10, 20, 30, 40 years from now, and probably they're going to say, "Yeah, that was innovative back then [laughs], but now this is how we receive healthcare, which is awesome."

+ +

VICTORIA: That's cool. So, it's like the impact your company's having and the drive to be a part of your family and, of course, your kids waking you up in the morning. And is it all of that, or is it also the chickens? Because I had chickens growing up.

+ +

DR. LIZARDO: [laughs]

+ +

VICTORIA: And they would always, like, crow, like, really early in the morning.

+ +

DR. LIZARDO: [laughs] Yeah, Victoria, that's awesome. If you come to this house at 5:45, what you're going to see is me in a robe in the middle of a snowstorm, at least for now, going out and changing the water of the chickens. So, one of the things that we've done with our household is made it more of a sustainable household. There's a living thing in every one of these rooms in our house. There's a guava tree growing in our living room, literally, a tree from the tropics growing in Princeton. There are citrus trees growing in our dining rooms. We grow about 30 different types of vegetables and fruits on our property.

+ +

And we also have livestock like chickens, which, honestly, I think we've learned that when we see things grow, we're more inclined to try them and taste them. You know, over the weekend, we had our neighbors, and one of the neighbors was like, "You have an actual olive tree from Italy growing in your..." it's about eight feet in our family room...sorry, in the kids' playroom. They were like, "I've never seen that before." I basically told them, "You should come back in a few months and pick some olives."

+ +

We love this ecosystem that we've built around sustainability, and it basically has brought our family together in order to work on things like trying to figure out how to grow these trees inside our house and outside our house.

+ +

VICTORIA: It must be such a cool experience for your kids to see something grow from a seed into something they can eat and, interact with and enjoy. And to bring it all back, I'm wondering, what was the seed for you to decide to focus on 911 or emergency services and solving that problem that people face? And maybe describe even a little bit of, like, what is the impact of divergent and emergency room services.

+ +

DR. LIZARDO: I feel like every great leader has something personal that's attached to what's fueling them, and, in my case, it's my dad. So, my dad has a heart condition, and, you know, there's been times where they've had to call 911. In the nation right now, 911 is a very antiquated and struggling system. As a matter of fact, ambulances have become very expensive Uber drivers.

+ +

Eight out of every ten calls that's medically related to a 911 does not need an ambulance and yet uses one to go to the hospitals. Most people in the U.S. believe that if they call 911 and they get an ambulance, they're going to be expedited at the hospital, which is not true. So, I know, unfortunately, that one day, my dad's going to call 911 because he really needs it, or someone in my family will. And I'm basically building a system that when he calls, he's going to get a faster response. By doing that, by basically doing what we do, we actually take care of the low-level emergency so when the real emergencies come, they actually are able to go through.

+ +

You know, Tele911 really tackles three things, three major problems in the industry. One is basically the pipes into 911 are overflooded. Sometimes, you're put on hold. Sometimes, you call 911, and they transfer you to another state because they're just so overrun. And basically, now we're creating pipes that actually allow them to take the real emergencies.

+ +

Two, the health plans. Every health plan in the United States 80% of what they do is actually try to figure out how to keep you out of the hospital. It's called utilization management. And it's just crazy how if you look at these monster health plans, their number one rule is, 'Please don't go to the hospital,' and that's the number one thing people actually do. And, for them, what we're solving is a huge problem because now they're able to take risk and actually control their budgets a lot better and, in effect, give better rates because they know that if they call 911 unnecessarily, they're going to be treated in place.

+ +

But lastly, it's because the people that are calling 911...medical debts is the number one reason for bankruptcy in the U.S. right now, and these people that are calling 911 they're going bankrupt. If you call 911 in California, in certain counties, the ambulance is $6,000, again, 6,000, even if you use it unnecessarily, let's say for a paper cut. And what I've done is basically created a company that solves for all three: for patients that need the care and basically think 911 is the only resource, for health plans that want to control these costs, but both fall for our lines. I want our lines to be free for the true emergencies.

+ +

VICTORIA: So, it was a personal experience with your father and the need for that. And I can relate to that, as well as having elderly family members who have conditions, who regularly need support. A lot of trouble is even just getting people to the hospital, and they can have services delivered right there in their home.

+ +

Anything in the early discovery phase of trying to solve this problem that caused you to pivot your strategy in your approach?

+ +

DR. LIZARDO: Absolutely. So, Tele911 right now is the product of, you know, an idea that was written on the back of a greasy napkin [laughs] at a Bojangles in South Carolina at a medical conference. But what you see today as the nation's leading ER diversion company and one of the most successful companies in digital healthcare is a product of three failures. We actually tried this multiple times and failed. And it wasn't until COVID happened, and we realized there was an acceleration and an acceptance for video calls, that we noticed that, hey, this is actually a better way, and it can happen now.

+ +

The irony of this [chuckles] is that we didn't think it was going to work so well. When we went commercial last year, we were like, maybe we could just do 300 calls. And in exchange, we started doing this by the thousands. A few months in, we're in the several thousands, and we're like, oh my God, this is working. And then, by the end of the year, we covered over 5 million lives by geography, and I realized we're on to something. Legislations passed with our name on it. So, you know, this idea that struggled, and we had to restart multiple times, we did not give up. And in exchange, I mean, we're literally making history.

+ +

VICTORIA: I love that. Yeah, so pre-COVID the idea of having medical services delivered virtually, I wonder what feedback you got from investors or from people interested in the idea at that time.

+ +

DR. LIZARDO: [laughs] No one wanted it [laughs]. No one wanted, you know, you show up to someone's house, and they're like, "Yeah, we're not going to take you to the hospital. We're going to have you see a doctor on the screen." They would be like, "No, I'm going," right? [laughs] Like, "This is not working." Also, even the counties, they were like, "This is too risky. What do you mean the doctor's going to be on the screen?" There wasn't a high level of adoption for something like this, and, you know, it struggled a lot.

+ +

I recall pitching the idea and people coming back to me and saying, "Well, you know, I love this. Tell me when it works. Tell me when you have enough traction." You know, it's funny because those are the same people now that are on our waitlist who now basically really need this, really want this, but we let them know there are 35 million more lives in coverage based on the counties just in our waitlist. It's a testament to just how awesome this product is and how fast it's adopted, but also the true need for something like this as part of the healthcare delivery continuum.

+ +

VICTORIA: Wow. Yeah. That's incredible that once you found the right fit, it became acceptable and even necessary to receive care virtually during the pandemic, and it really took off. So, now that you've gotten some initial traction and more than enough, what are your challenges that you see on the horizon?

+ +

DR. LIZARDO: So, a few challenges. Let's talk about how this went from, hey, a good idea to now a standard across different states. So, for example, in certain counties, and, I mean, this happens in every state as well. I'll give you an example of Florida. The hospitals are literally two hours away. Florida is incredibly rural. They either are able to see a doctor through our telemedicine platform, or they have to go on an ambulance for two hours, and that ambulance is away for six hours, like an entire shift.

+ +

So, one of the things that I've seen is a huge challenge is our product has grown expansively. So, what we do is we're basically building a larger network to be able to deliver for a larger volume. By the way, every time someone presses that button, within 40 seconds, on average, you get an emergency medicine physician that's board-certified in that state. And, I mean, that number used to be 2 minutes, then 1 minute, and now we're at 40 seconds. Eventually, it's going to be 10 seconds.

+ +

I'm pretty sure myself, someone who worked in emergency medicine, can't reach my friend in 10 seconds [chuckles], but this product does, which is what's fascinating about it, that high level of care. But with that same issue, we're now doing this for the tens of thousands. And within the next two years, we're going to be doing this for the hundreds, you know, we're forecasting hundreds of thousands of calls.

+ +

So, how do we prepare for that? How many emergency medicine physicians are in the U.S.? Can we cover those amount of lives? You know, do we continue to expand across auxiliary like APNs and higher tiers below MDs? So, these are the kind of things that I have to constantly think about. These are the kind of things that the government now reaches out to me to just get some advice on. Everyone's approved this. Now it's more, how do we scale this as we continue to make this the gold standard?

+ +

VICTORIA: The scaling becomes a top priority. And as a CEO who needs to build a management team around yourself, how do you identify where you have needs and where to find the people to perform the task you need to scale?

+ +

DR. LIZARDO: That really does depend on the role. One of the good things...so I used to sit on clinical boards for about 16 health plans, which allows me to have a very expansive network, particularly within healthcare and products. So, I know that the people are out there. The thing is, working at Tele911 is a very different type of environment than most people are used to. Here, we really fall fast collectively, lick our wounds, and redirect together.

+ +

Everyone has access to me. There's no hierarchy. It's more of a matrix environment, at least at this level. And then I tend to hire people at the management level that don't look like people that you would generally hire, and the reason is that there are two factors in order to be successful here at Tele911. You have to have that human component; to me, that's important. A lot of the people here...actually, I was sharing this with someone, but for the majority of my tenure here at Tele911, I was actually the youngest person at the company. I hire people with tenure and wisdom.

+ +

But a lot of the types of people that I hire here are actually outside of the industry, people who can bring in those thought processes over to Tele911 across repeatability, monetization, and scalability. Some of them are from manufacturing. Some of them...it really does depend. But when I look around the team, and I'm like, wow, you know, we are a team of misfits, but we produce amazing results. I mean, Tele911 in the last year alone, 3x volume and 5x just billing. So, we understand that we are part of something unique, and people just bring their ideas into that and adapt to it.

+ +

VICTORIA: Your approach, it sounds like, to play it back a little bit, is to find people who are smarter than you [laughs] about some things and then, yeah, really reach for wisdom and not fall into the same pattern that other organizations may be advised to follow to build their team because you have that insight into your market and your industry, and you can navigate what you need in order to scale.

+ +

DR. LIZARDO: Yeah. Also, at Tele911, this is innovation. So, there's really nowhere else to look for talent who have done this before. So, we really have to outsource from different industries. You know that adaptability is key, but what I really look for is repeatability. Has this person been ingrained with figuring out the pieces that make it whole and basically integrating them into our process, repeatable, monetizable, and scalable?

+ +

VICTORIA: Right. And maybe that answers my next question, but what core values drive your everyday decisions?

+ +

DR. LIZARDO: As I said before, and I think I said it at the beginning of the call, people know me as a father and a husband. That's who I am, and above all, that's my number one job. So, that human component is so critical in order for you to succeed here. Life happens while you're at Tele911. Parents get sick; kids have the flu; like, life happens.

+ +

And we have to understand that this is an empathetic environment. Someone in the management team had a baby today, and we were at a debrief meeting. And in the middle of a meeting, someone said, "The baby is here," [laughs] and everyone was rejoicing. If someone externally would have been in that meeting, they're like, "Who's baby, and why are we announcing it in the middle of a management meeting?" But, to us, is we function as a family, which is critical.

+ +

Another value that we really stress here is integrity. Because we're part of innovation, we have to be very clear about our numbers and very clear about how we're achieving our traction [inaudible 18:24]. I'm not really interested in the goal. I'm more interested in the process, but be very, very clear. You have to be creative. You know, I spent some time studying quantitative methodology over at Harvard, and repeatability is important, but being able to think outside the box because, again, this has never been done before. So, you have to look at this from an angle of, like, the art of the impossible, and then go and try it.

+ +

VICTORIA: Right, yeah. And I think it's really interesting, too, like, you know, when you think about making art or innovation, you can sometimes look and see how other people have done it. But then you have to decide what's your path. And, like, how do you solve for this particular problem? And, like, what can you learn from these [inaudible 19:08] this is the way you should or shouldn't do that; practice is really interesting, I think.

+ +

DR. LIZARDO: You know what? And I think that's probably been the most exciting part about this. I've never been in a situation where there was nothing to look back to reference. Like this is the first time in history that this is going, and it's accelerated so fast. We don't have a, hey, this is what good looks like. We basically have us, and we've had to adapt to that.

+ +

And along the way, what we've done is we've basically done basic, like, micro-moments of learning, adding on to those and saying, "Okay, this is what good looks like. But then what would great look like?" And I think that that's the example of...remember when I mentioned earlier, you know, it used to be 2 minutes, and 1 minute, you know, then 50 seconds, now 40 seconds. And we're like, "Hey, what if we could do 10 seconds where people press a button and get a board-certified doctor upon a 911 call?" And you're just like, yeah, that sounds impossible, but so did this idea now. So, we know the art of the impossible is just a few stone throws away as we continue to make traction.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: You know, there's the impact for the person experiencing an emergency and having it be able to resolve within their home. It also opens up that possibility of remote work for doctors and nurses, which I'm sure you know more than me about the current state of the strain on our medical system and the people who are working in it and how you think about the impact on them as well.

+ +

DR. LIZARDO: Just for context, my wife is a physician. And during COVID, we ended up having two kids, one right before and one during. And because of our–one–our parenting style but also our life choices, what we basically is we took turns at different points in order to stay home with our kids. But one of the things that, you know, have always bugged me is we saw every specialty practice virtually, but emergency medicine had to be practiced in the hospital. And unfortunately, because of that force and that strain in the system, less than 50% of the spots in emergency medicines were filled last year. People don't want to do it.

+ +

So, what we did is we went out to a lot of these parents and said, "Hey, do you want to join this network where you're able to see patients while you take a nap virtually?" And they're like, "Whoa, let me try that." And, Victoria, within three weeks, dads and moms were showing up in droves with their babies to the interviews, saying, "This is what my life looks like. He takes a nap between 2:00 and 4:00. Can I grab a shift for those 2 hours?"

+ +

And along the way, we ended up building the nation's largest virtual emergency medicine practice. Out of that pain point in us and just asking questions, we built this awesome system that now propels people to basically press a button and within 40 seconds, get a doctor. And I think that's the art of the impossible. We actually look at it and say, "Well, we could probably do something better on that."

+ +

But we've also now reshaped emergency medicine to the point that now we're the ones that are writing the fellowship for virtual emergency medicine. We are now creating the protocols and our data now is in journals as, hey, this is what the specialty should look like, and this is what they're able to do. So, we're equally as excited about that and just on the outcome. And it's just a huge honor.

+ +

VICTORIA: Wow, that's incredible that it would go in that direction, and you'd have this opportunity to really reshape an industry and define how even people learn how to perform emergency services and medicine.

+ +

DR. LIZARDO: [laughs] You know what the most amazing thing is? It's actually a lot easier than what other specialties have done because cardiologists have been able to, you know, see patients virtually, but they can't do an EKG. But our team can because the medics are on-site within 8 to 10 minutes of that call, and they're able to do an EKG. They're able to do a pulse ox. They're able to even do an IV drip. So, it's actually a new way to practice emergency medicine, where the medic is your hands, eyes, ears, but the doctor's basically working in conjunction with them, guiding them to best do the assessment.

+ +

VICTORIA: That's, like, such a revolutionary idea, and I think it's so cool. I'm curious: how do you perform user research and design for patients and for emergency responders?

+ +

DR. LIZARDO: [laughs] That's a question that we're actually working through right now. So, emergency responders they actually all have an iPad or a computer on them when they show up at your house. But that looks a lot more like the Nokia phone, the blue phone from back in the day. There's very little interaction on that iPad. And what we've done is we've put an app that's dynamic that allows them to basically best assess the patient, understand their protocol. So, it actually has its enhancer experience.

+ +

Also, remember, these medics are some of the smartest people on earth. I mean, they see patients more than doctors do. They know where they live. They know what their house looks like, and they've seen them thousands of times. So, what they're really good at is interacting with the iPad in a way that actually shows the surrounding, shows the patient, and shows what's important.

+ +

When it comes to our doctors, particularly in emergency medicine, they've been dying to basically practice virtual emergency medicine. So, what we've done is we've basically provided the initial data set of what they need, along with a video. But now we're actually augmenting that with additional data sets that allow them just to have a more comprehensive picture of the patient, including some look back data, what happened before, what should be happening afterwards, integration with their health plan. They actually have more data and a better experience with practicing in their home than if they were at the hospital.

+ +

VICTORIA: I appreciate that viewpoint. And I can understand how interesting it must be to design for those two different user personas. I'm curious; you mentioned data. What's your strategy around data privacy, and protection, and security in your application when you're at the same time trying to be very innovative and move very quickly?

+ +

DR. LIZARDO: Well, you know, I've always believed data is on a need-to-know basis, particularly because we're dealing with PHI. We're dealing with clinical data. I always tell people it's one thing for someone to walk into a hospital and tell you their name, last name, phone numbers. It's a whole other thing for you to go to their home and start gathering information. So, that is basically one of our key standards here.

+ +

We understand the gravity of the data that we're collecting and how critical it is, not only to health plans, health systems, but, above all, the member and how that privacy should be kept. And it's such a critical component to the company. As we continue to grow and mature, we've added additional layers in order to best protect the company–but above all, best protect the member in situations like this.

+ +

VICTORIA: Yeah, well, I appreciate that viewpoint. And starting, you know, probably your background as a consultant and also working as a doctor, you have a really deep understanding of the type of data you're dealing with and how sensitive it is. So, I appreciate that that's a priority for you within the company. What is the wind in your sails? What keeps you going? What keeps you committed to doing this work?

+ +

DR. LIZARDO: So, at this point, we are reshaping an entire history. We're literally going in the books now. So, now we can't stop this. I remember going through medical school and reading through some books. I was joining part of a community of doctors. Now, I'm rewriting and creating a new version of how this entire industry is being practiced. And understanding the gravity of such a monumental place in society that keeps me going. We can't stop it now. And that, to me, is what's monumental in all of this.

+ +

VICTORIA: That's great. So, it's that big overall vision of the impact you're making on not just a few people, a few million people, but really the whole industry and for many years to come.

+ +

DR LIZARDO: Exactly. Exactly. So, just so you know, for example, our patients aren't just...we don't just do emergency medicine. Some of our patients have psychiatric needs, and some of our patients have, you know, oncological needs. So, we are actually the largest lead generator of patients into the right system for the United States because we're capturing them at the 911 call. So, there are so many great companies out there, and their number one problem is not how to solve for the things that they build; it's who's going to use it. How do you find more customers to actually use it?

+ +

And what a lot of these companies have realized is, hey, we've been trying to find these people for years, and yet they're walking into Tele911's front door. How do we partner up with them, and how do we basically show Tele911 the services that differentiate us in order for them to walk the patients towards us?

+ +

VICTORIA: That's such a cool stat to have that you're really putting people into the right path. And you have these great things that you all have achieved. I wonder, do you write key objectives and results? Because some of those it sounds like, well, I don't know you would ever be able to dream up that result [laughs], right?

+ +

DR. LIZARDO: Yeah. Well, yeah, we do function. We actually have a KPI doc that we use. We all track, and everyone at the company has visibility into them. It's super critical for everyone to be aligned no matter the level for that. I always say KPIs should not be unachievable, but they should be a stretch. Tele911 expects to grow 10x on its second year; very, very, very few companies in the history of digital health have grown 10x. And we are not only with foresight of, like, how we're going to achieve that; we're actually executing on a trajectory for that 10x.

+ +

That's a dangerous number to say for me as a CEO. And I look at the KPIs, and I'm like, well, we did 5x last year and cut almost a million in operating costs, so we can do 10x this year. Any consultant outside would be like, "Yeah, that's crazy," and then they look at our model, and they're like, "Yeah, these people might be crazy enough to actually do it [laughs]."

+ +

VICTORIA: Well, that's great. I mean, and, I guess, it's, like, all about how do you picture it? Like, are you trying to make a goal that gets everyone excited and gets everyone motivated and dreaming of the art of the possible, or are you just trying to make it so that you can check it off at the end of the year [laughs], right?

+ +

DR. LIZARDO: No. Actually, checking things off is...listen, at the end of the year, we're looking at the following year's list, right? We're not just checking things off. What we're doing is, we understand our mission, and because of our mission, what we're saying is, how aligned with our mission are we? I don't know if that's a circle or a checkpoint, but it's more about alignment for that mission of democratizing access to the best care as fast as possible upon a 911 call.

+ +

VICTORIA: I love that. That makes a lot of sense to me, just bringing it all back to the mission and the impact and why we're all here in the first place, right?

+ +

DR. LIZARDO: Exactly.

+ +

VICTORIA: I love that. Wonderful. Do you have any questions for me?

+ +

DR. LIZARDO: No. I mean, it was excellent to, one, just to be able to connect with you, two, to be...actually, as I was talking through these questions with you, you know, I realized how...just for context, my favorite author is Walter Isaacson. If you ever have the chance, please read one of his books. I'm reading Benjamin Franklin, and I read Steve Jobs' book. There's actually a few books. My favorite book in the whole world is Da Vinci by Walter Isaacson.

+ +

And, you know, I hope that people listening to this they can do two things. One, they can get to know me just a little bit and the things that we're doing, but two, they can be inspired because I think that's what we really need. There's a lot of people starting companies just because someone's doing something they could do it better. I mean, that's cool and all, but just so you know, most of those things actually fail. There's a reason why 9 out of 10 companies actually fail today. We don't need more copycats. Think of the art of the impossible and create that, and then pursue it as if nothing's holding you back. And if you do so, you just might find yourself with a Tele911 company.

+ +

VICTORIA: Well, that gets me fired up. I'm excited. I really love that advice. I appreciate you sharing that with us. Is there anything else that you would like to promote today?

+ +

DR. LIZARDO: Yes. If I could just take a second to share about this, I know that a lot of people who listen to this podcast want to start companies. A lot of people are trying to figure out, how do I get my idea started? But I also realized a lot of these people really haven't written down their ideas. They're basically pursuing things that haven't really been written down.

+ +

And one of the things that I shared, if we go back to this podcast, I said, this idea was written on the back of a greasy napkin in South Carolina during a storm at a Bojangles. I literally recall seasoned fries, dipping it in the grease of the chicken, which is terrible for you, by the way, cleaning my hands, and writing on the back: What if people call 911 and this and this and this happened?

+ +

And if I could leave you with one thing is, please write your ideas down. Send me photos of your napkins [chuckles], like, share napkins with people on a plane, people on a train, share these ideas, write them down. Because the ideas that write them down basically have an opportunity to go back and reestablish, to modify. But one of the things that I know is these ideas eventually echo in eternity at one place or another. And when I leave, just with an encouragement, please just write your ideas down.

+ +

VICTORIA: Great advice. I really appreciate that. You know, everything in moderation. I'm not going to say fried chicken or fries is bad for you [laughter] because I like it.

+ +

DR. LIZARDO: [laughs]

+ +

VICTORIA: But yeah, no, thank you so much. I loved sharing with that and, hopefully, people will share your ideas.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Victoria Guido hosts Dr. Ramon Lizardo, CEO of Tele911, to discuss his company's innovative approach to emergency room diversion. Dr. Lizardo shares his journey from being a physician frustrated with the inefficiencies in emergency care to leveraging technology for better healthcare delivery. Tele911 is a service that transforms how emergency responses are handled. Rather than transporting patients to hospitals for non-critical care, Tele911 facilitates on-site treatments through paramedics equipped with iPads, allowing doctors to provide remote consultations, streamlining emergency services, and reducing unnecessary hospital visits and costs.

+ +

Dr. Lizardo's motivation for founding Tele911 was driven by personal experiences and the desire to improve emergency healthcare delivery. He recounts the challenges of pioneering in digital health, particularly the initial skepticism from investors and potential users about remote medical services. The COVID-19 pandemic became a turning point, accelerating acceptance and demand for Tele911's services, and Dr. Lizardo discusses the challenges of scaling the service, maintaining data privacy, and the importance of a values-driven approach to business.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA:  This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dr. Ramon Lizardo, CEO of Tele911, the leader in emergency room diversion. Dr. Lizardo, thank you for joining me.

+ +

DR. LIZARDO: Hey, Victoria. Good to connect with you once again. How are you?

+ +

VICTORIA: I'm good. It's raining in San Diego, so, unlike the song, it does happen sometimes in Southern California.

+ +

DR. LIZARDO: [laughs] But I love San Diego, by the way. It's one of those places where I feel like you have literally the perfect weather and perfect access to food. I'm a fan of Mexican food. And you can literally get the best Mexican food from, like, all of the trucks in San Diego. I truly believe that.

+ +

VICTORIA: That's true. The only better place to get Mexican food in San Diego is just to go to Mexico. You --

+ +

DR. LIZARDO: There you go [laughter].

+ +

VICTORIA: Yeah. I actually went to a startup event that was in Tijuana on a Tuesday night and just walked over the border and walked back, and it was great.

+ +

DR. LIZARDO: That is awesome.

+ +

VICTORIA: [laughs]

+ +

DR. LIZARDO: You know, there's a lot of expats living there now. It's really interesting, in Baja, California.

+ +

VICTORIA: Yeah, there's some back and forth there. And yeah, so just give me a little bit about your background and a little bit more about Tele911.

+ +

DR. LIZARDO: I'm a physician by training, but I've been in tech for about 15 years now. Tele911 is basically the child of a parent that was really frustrated with their specialty. So, I signed up for emergency medicine, and I realized a lot of what was happening was primary care. That led me to pursue a career in consulting. I worked at one of the Big Fours, interned at McKinsey, worked at Deloitte. Then, I started or joined a series of other startups that were very successful.

+ +

About three exits in, I said, hey, remember that idea that actually got me out? Being frustrated in ER because a lot of these patients didn't need to go to the hospital but were there. Well, this is how this comes about. Tele911 is basically the product of a lot of frustration, but a lot of innovation. And now we're pretty much reshaping history. In California, Texas, or Florida, when a patient calls 911 now, an ambulance shows up, but instead of being taken to the hospital, they're actually seen at home in something called treatment in place. We're the doctor on the iPad of the paramedic.

+ +

VICTORIA: So, thank you. That's a great interest. So, you had this background in consulting, and you had this experience as a physician, and then you decided to solve this really big problem with the cost around emergency rooms. So, before we dive into more around Tele911 and what you're doing with it, I thought we could warm up a little bit by just telling me, what gets you up in the morning?

+ +

DR. LIZARDO: [laughs] What gets me up in the morning? Well, I'm blessed because I have a two and a six-year-old. So [laughs], the truth is they're the ones that get me up. They usually wake up way before I do. So, if you come to this house about 5:15, 5:30, I feel like everyone's awake, and if you come to this house at 9:00 p.m., we're fast asleep. But what gets me up in the morning is that, above all, I'm a father and a husband.

+ +

I also run the nation's largest ER diversion company, which operates 24/7, and emergencies happen throughout the night. So, depending on what's happening throughout the night, I'm either up at 2:00, 4:00, 6:00 a.m. But what fuels me, though, every day is two things. One is I want to be an excellent husband and father, and I want to be present for everything that I can, especially when I'm home what's happening in my family's life.

+ +

But two, I'm part of this company that's changing the landscape of healthcare. You know, I've been part of other companies, but this is really one of those legacy events in life where I'm building something that's really changing the way healthcare is being delivered. And I understand that's my personal mission, and that's something that I strive for every day, and because of that, that drive just comes naturally.

+ +

I'm working on something that's way bigger than me, something that my kids are going to be reading about 10, 20, 30, 40 years from now, and probably they're going to say, "Yeah, that was innovative back then [laughs], but now this is how we receive healthcare, which is awesome."

+ +

VICTORIA: That's cool. So, it's like the impact your company's having and the drive to be a part of your family and, of course, your kids waking you up in the morning. And is it all of that, or is it also the chickens? Because I had chickens growing up.

+ +

DR. LIZARDO: [laughs]

+ +

VICTORIA: And they would always, like, crow, like, really early in the morning.

+ +

DR. LIZARDO: [laughs] Yeah, Victoria, that's awesome. If you come to this house at 5:45, what you're going to see is me in a robe in the middle of a snowstorm, at least for now, going out and changing the water of the chickens. So, one of the things that we've done with our household is made it more of a sustainable household. There's a living thing in every one of these rooms in our house. There's a guava tree growing in our living room, literally, a tree from the tropics growing in Princeton. There are citrus trees growing in our dining rooms. We grow about 30 different types of vegetables and fruits on our property.

+ +

And we also have livestock like chickens, which, honestly, I think we've learned that when we see things grow, we're more inclined to try them and taste them. You know, over the weekend, we had our neighbors, and one of the neighbors was like, "You have an actual olive tree from Italy growing in your..." it's about eight feet in our family room...sorry, in the kids' playroom. They were like, "I've never seen that before." I basically told them, "You should come back in a few months and pick some olives."

+ +

We love this ecosystem that we've built around sustainability, and it basically has brought our family together in order to work on things like trying to figure out how to grow these trees inside our house and outside our house.

+ +

VICTORIA: It must be such a cool experience for your kids to see something grow from a seed into something they can eat and, interact with and enjoy. And to bring it all back, I'm wondering, what was the seed for you to decide to focus on 911 or emergency services and solving that problem that people face? And maybe describe even a little bit of, like, what is the impact of divergent and emergency room services.

+ +

DR. LIZARDO: I feel like every great leader has something personal that's attached to what's fueling them, and, in my case, it's my dad. So, my dad has a heart condition, and, you know, there's been times where they've had to call 911. In the nation right now, 911 is a very antiquated and struggling system. As a matter of fact, ambulances have become very expensive Uber drivers.

+ +

Eight out of every ten calls that's medically related to a 911 does not need an ambulance and yet uses one to go to the hospitals. Most people in the U.S. believe that if they call 911 and they get an ambulance, they're going to be expedited at the hospital, which is not true. So, I know, unfortunately, that one day, my dad's going to call 911 because he really needs it, or someone in my family will. And I'm basically building a system that when he calls, he's going to get a faster response. By doing that, by basically doing what we do, we actually take care of the low-level emergency so when the real emergencies come, they actually are able to go through.

+ +

You know, Tele911 really tackles three things, three major problems in the industry. One is basically the pipes into 911 are overflooded. Sometimes, you're put on hold. Sometimes, you call 911, and they transfer you to another state because they're just so overrun. And basically, now we're creating pipes that actually allow them to take the real emergencies.

+ +

Two, the health plans. Every health plan in the United States 80% of what they do is actually try to figure out how to keep you out of the hospital. It's called utilization management. And it's just crazy how if you look at these monster health plans, their number one rule is, 'Please don't go to the hospital,' and that's the number one thing people actually do. And, for them, what we're solving is a huge problem because now they're able to take risk and actually control their budgets a lot better and, in effect, give better rates because they know that if they call 911 unnecessarily, they're going to be treated in place.

+ +

But lastly, it's because the people that are calling 911...medical debts is the number one reason for bankruptcy in the U.S. right now, and these people that are calling 911 they're going bankrupt. If you call 911 in California, in certain counties, the ambulance is $6,000, again, 6,000, even if you use it unnecessarily, let's say for a paper cut. And what I've done is basically created a company that solves for all three: for patients that need the care and basically think 911 is the only resource, for health plans that want to control these costs, but both fall for our lines. I want our lines to be free for the true emergencies.

+ +

VICTORIA: So, it was a personal experience with your father and the need for that. And I can relate to that, as well as having elderly family members who have conditions, who regularly need support. A lot of trouble is even just getting people to the hospital, and they can have services delivered right there in their home.

+ +

Anything in the early discovery phase of trying to solve this problem that caused you to pivot your strategy in your approach?

+ +

DR. LIZARDO: Absolutely. So, Tele911 right now is the product of, you know, an idea that was written on the back of a greasy napkin [laughs] at a Bojangles in South Carolina at a medical conference. But what you see today as the nation's leading ER diversion company and one of the most successful companies in digital healthcare is a product of three failures. We actually tried this multiple times and failed. And it wasn't until COVID happened, and we realized there was an acceleration and an acceptance for video calls, that we noticed that, hey, this is actually a better way, and it can happen now.

+ +

The irony of this [chuckles] is that we didn't think it was going to work so well. When we went commercial last year, we were like, maybe we could just do 300 calls. And in exchange, we started doing this by the thousands. A few months in, we're in the several thousands, and we're like, oh my God, this is working. And then, by the end of the year, we covered over 5 million lives by geography, and I realized we're on to something. Legislations passed with our name on it. So, you know, this idea that struggled, and we had to restart multiple times, we did not give up. And in exchange, I mean, we're literally making history.

+ +

VICTORIA: I love that. Yeah, so pre-COVID the idea of having medical services delivered virtually, I wonder what feedback you got from investors or from people interested in the idea at that time.

+ +

DR. LIZARDO: [laughs] No one wanted it [laughs]. No one wanted, you know, you show up to someone's house, and they're like, "Yeah, we're not going to take you to the hospital. We're going to have you see a doctor on the screen." They would be like, "No, I'm going," right? [laughs] Like, "This is not working." Also, even the counties, they were like, "This is too risky. What do you mean the doctor's going to be on the screen?" There wasn't a high level of adoption for something like this, and, you know, it struggled a lot.

+ +

I recall pitching the idea and people coming back to me and saying, "Well, you know, I love this. Tell me when it works. Tell me when you have enough traction." You know, it's funny because those are the same people now that are on our waitlist who now basically really need this, really want this, but we let them know there are 35 million more lives in coverage based on the counties just in our waitlist. It's a testament to just how awesome this product is and how fast it's adopted, but also the true need for something like this as part of the healthcare delivery continuum.

+ +

VICTORIA: Wow. Yeah. That's incredible that once you found the right fit, it became acceptable and even necessary to receive care virtually during the pandemic, and it really took off. So, now that you've gotten some initial traction and more than enough, what are your challenges that you see on the horizon?

+ +

DR. LIZARDO: So, a few challenges. Let's talk about how this went from, hey, a good idea to now a standard across different states. So, for example, in certain counties, and, I mean, this happens in every state as well. I'll give you an example of Florida. The hospitals are literally two hours away. Florida is incredibly rural. They either are able to see a doctor through our telemedicine platform, or they have to go on an ambulance for two hours, and that ambulance is away for six hours, like an entire shift.

+ +

So, one of the things that I've seen is a huge challenge is our product has grown expansively. So, what we do is we're basically building a larger network to be able to deliver for a larger volume. By the way, every time someone presses that button, within 40 seconds, on average, you get an emergency medicine physician that's board-certified in that state. And, I mean, that number used to be 2 minutes, then 1 minute, and now we're at 40 seconds. Eventually, it's going to be 10 seconds.

+ +

I'm pretty sure myself, someone who worked in emergency medicine, can't reach my friend in 10 seconds [chuckles], but this product does, which is what's fascinating about it, that high level of care. But with that same issue, we're now doing this for the tens of thousands. And within the next two years, we're going to be doing this for the hundreds, you know, we're forecasting hundreds of thousands of calls.

+ +

So, how do we prepare for that? How many emergency medicine physicians are in the U.S.? Can we cover those amount of lives? You know, do we continue to expand across auxiliary like APNs and higher tiers below MDs? So, these are the kind of things that I have to constantly think about. These are the kind of things that the government now reaches out to me to just get some advice on. Everyone's approved this. Now it's more, how do we scale this as we continue to make this the gold standard?

+ +

VICTORIA: The scaling becomes a top priority. And as a CEO who needs to build a management team around yourself, how do you identify where you have needs and where to find the people to perform the task you need to scale?

+ +

DR. LIZARDO: That really does depend on the role. One of the good things...so I used to sit on clinical boards for about 16 health plans, which allows me to have a very expansive network, particularly within healthcare and products. So, I know that the people are out there. The thing is, working at Tele911 is a very different type of environment than most people are used to. Here, we really fall fast collectively, lick our wounds, and redirect together.

+ +

Everyone has access to me. There's no hierarchy. It's more of a matrix environment, at least at this level. And then I tend to hire people at the management level that don't look like people that you would generally hire, and the reason is that there are two factors in order to be successful here at Tele911. You have to have that human component; to me, that's important. A lot of the people here...actually, I was sharing this with someone, but for the majority of my tenure here at Tele911, I was actually the youngest person at the company. I hire people with tenure and wisdom.

+ +

But a lot of the types of people that I hire here are actually outside of the industry, people who can bring in those thought processes over to Tele911 across repeatability, monetization, and scalability. Some of them are from manufacturing. Some of them...it really does depend. But when I look around the team, and I'm like, wow, you know, we are a team of misfits, but we produce amazing results. I mean, Tele911 in the last year alone, 3x volume and 5x just billing. So, we understand that we are part of something unique, and people just bring their ideas into that and adapt to it.

+ +

VICTORIA: Your approach, it sounds like, to play it back a little bit, is to find people who are smarter than you [laughs] about some things and then, yeah, really reach for wisdom and not fall into the same pattern that other organizations may be advised to follow to build their team because you have that insight into your market and your industry, and you can navigate what you need in order to scale.

+ +

DR. LIZARDO: Yeah. Also, at Tele911, this is innovation. So, there's really nowhere else to look for talent who have done this before. So, we really have to outsource from different industries. You know that adaptability is key, but what I really look for is repeatability. Has this person been ingrained with figuring out the pieces that make it whole and basically integrating them into our process, repeatable, monetizable, and scalable?

+ +

VICTORIA: Right. And maybe that answers my next question, but what core values drive your everyday decisions?

+ +

DR. LIZARDO: As I said before, and I think I said it at the beginning of the call, people know me as a father and a husband. That's who I am, and above all, that's my number one job. So, that human component is so critical in order for you to succeed here. Life happens while you're at Tele911. Parents get sick; kids have the flu; like, life happens.

+ +

And we have to understand that this is an empathetic environment. Someone in the management team had a baby today, and we were at a debrief meeting. And in the middle of a meeting, someone said, "The baby is here," [laughs] and everyone was rejoicing. If someone externally would have been in that meeting, they're like, "Who's baby, and why are we announcing it in the middle of a management meeting?" But, to us, is we function as a family, which is critical.

+ +

Another value that we really stress here is integrity. Because we're part of innovation, we have to be very clear about our numbers and very clear about how we're achieving our traction [inaudible 18:24]. I'm not really interested in the goal. I'm more interested in the process, but be very, very clear. You have to be creative. You know, I spent some time studying quantitative methodology over at Harvard, and repeatability is important, but being able to think outside the box because, again, this has never been done before. So, you have to look at this from an angle of, like, the art of the impossible, and then go and try it.

+ +

VICTORIA: Right, yeah. And I think it's really interesting, too, like, you know, when you think about making art or innovation, you can sometimes look and see how other people have done it. But then you have to decide what's your path. And, like, how do you solve for this particular problem? And, like, what can you learn from these [inaudible 19:08] this is the way you should or shouldn't do that; practice is really interesting, I think.

+ +

DR. LIZARDO: You know what? And I think that's probably been the most exciting part about this. I've never been in a situation where there was nothing to look back to reference. Like this is the first time in history that this is going, and it's accelerated so fast. We don't have a, hey, this is what good looks like. We basically have us, and we've had to adapt to that.

+ +

And along the way, what we've done is we've basically done basic, like, micro-moments of learning, adding on to those and saying, "Okay, this is what good looks like. But then what would great look like?" And I think that that's the example of...remember when I mentioned earlier, you know, it used to be 2 minutes, and 1 minute, you know, then 50 seconds, now 40 seconds. And we're like, "Hey, what if we could do 10 seconds where people press a button and get a board-certified doctor upon a 911 call?" And you're just like, yeah, that sounds impossible, but so did this idea now. So, we know the art of the impossible is just a few stone throws away as we continue to make traction.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: You know, there's the impact for the person experiencing an emergency and having it be able to resolve within their home. It also opens up that possibility of remote work for doctors and nurses, which I'm sure you know more than me about the current state of the strain on our medical system and the people who are working in it and how you think about the impact on them as well.

+ +

DR. LIZARDO: Just for context, my wife is a physician. And during COVID, we ended up having two kids, one right before and one during. And because of our–one–our parenting style but also our life choices, what we basically is we took turns at different points in order to stay home with our kids. But one of the things that, you know, have always bugged me is we saw every specialty practice virtually, but emergency medicine had to be practiced in the hospital. And unfortunately, because of that force and that strain in the system, less than 50% of the spots in emergency medicines were filled last year. People don't want to do it.

+ +

So, what we did is we went out to a lot of these parents and said, "Hey, do you want to join this network where you're able to see patients while you take a nap virtually?" And they're like, "Whoa, let me try that." And, Victoria, within three weeks, dads and moms were showing up in droves with their babies to the interviews, saying, "This is what my life looks like. He takes a nap between 2:00 and 4:00. Can I grab a shift for those 2 hours?"

+ +

And along the way, we ended up building the nation's largest virtual emergency medicine practice. Out of that pain point in us and just asking questions, we built this awesome system that now propels people to basically press a button and within 40 seconds, get a doctor. And I think that's the art of the impossible. We actually look at it and say, "Well, we could probably do something better on that."

+ +

But we've also now reshaped emergency medicine to the point that now we're the ones that are writing the fellowship for virtual emergency medicine. We are now creating the protocols and our data now is in journals as, hey, this is what the specialty should look like, and this is what they're able to do. So, we're equally as excited about that and just on the outcome. And it's just a huge honor.

+ +

VICTORIA: Wow, that's incredible that it would go in that direction, and you'd have this opportunity to really reshape an industry and define how even people learn how to perform emergency services and medicine.

+ +

DR. LIZARDO: [laughs] You know what the most amazing thing is? It's actually a lot easier than what other specialties have done because cardiologists have been able to, you know, see patients virtually, but they can't do an EKG. But our team can because the medics are on-site within 8 to 10 minutes of that call, and they're able to do an EKG. They're able to do a pulse ox. They're able to even do an IV drip. So, it's actually a new way to practice emergency medicine, where the medic is your hands, eyes, ears, but the doctor's basically working in conjunction with them, guiding them to best do the assessment.

+ +

VICTORIA: That's, like, such a revolutionary idea, and I think it's so cool. I'm curious: how do you perform user research and design for patients and for emergency responders?

+ +

DR. LIZARDO: [laughs] That's a question that we're actually working through right now. So, emergency responders they actually all have an iPad or a computer on them when they show up at your house. But that looks a lot more like the Nokia phone, the blue phone from back in the day. There's very little interaction on that iPad. And what we've done is we've put an app that's dynamic that allows them to basically best assess the patient, understand their protocol. So, it actually has its enhancer experience.

+ +

Also, remember, these medics are some of the smartest people on earth. I mean, they see patients more than doctors do. They know where they live. They know what their house looks like, and they've seen them thousands of times. So, what they're really good at is interacting with the iPad in a way that actually shows the surrounding, shows the patient, and shows what's important.

+ +

When it comes to our doctors, particularly in emergency medicine, they've been dying to basically practice virtual emergency medicine. So, what we've done is we've basically provided the initial data set of what they need, along with a video. But now we're actually augmenting that with additional data sets that allow them just to have a more comprehensive picture of the patient, including some look back data, what happened before, what should be happening afterwards, integration with their health plan. They actually have more data and a better experience with practicing in their home than if they were at the hospital.

+ +

VICTORIA: I appreciate that viewpoint. And I can understand how interesting it must be to design for those two different user personas. I'm curious; you mentioned data. What's your strategy around data privacy, and protection, and security in your application when you're at the same time trying to be very innovative and move very quickly?

+ +

DR. LIZARDO: Well, you know, I've always believed data is on a need-to-know basis, particularly because we're dealing with PHI. We're dealing with clinical data. I always tell people it's one thing for someone to walk into a hospital and tell you their name, last name, phone numbers. It's a whole other thing for you to go to their home and start gathering information. So, that is basically one of our key standards here.

+ +

We understand the gravity of the data that we're collecting and how critical it is, not only to health plans, health systems, but, above all, the member and how that privacy should be kept. And it's such a critical component to the company. As we continue to grow and mature, we've added additional layers in order to best protect the company–but above all, best protect the member in situations like this.

+ +

VICTORIA: Yeah, well, I appreciate that viewpoint. And starting, you know, probably your background as a consultant and also working as a doctor, you have a really deep understanding of the type of data you're dealing with and how sensitive it is. So, I appreciate that that's a priority for you within the company. What is the wind in your sails? What keeps you going? What keeps you committed to doing this work?

+ +

DR. LIZARDO: So, at this point, we are reshaping an entire history. We're literally going in the books now. So, now we can't stop this. I remember going through medical school and reading through some books. I was joining part of a community of doctors. Now, I'm rewriting and creating a new version of how this entire industry is being practiced. And understanding the gravity of such a monumental place in society that keeps me going. We can't stop it now. And that, to me, is what's monumental in all of this.

+ +

VICTORIA: That's great. So, it's that big overall vision of the impact you're making on not just a few people, a few million people, but really the whole industry and for many years to come.

+ +

DR LIZARDO: Exactly. Exactly. So, just so you know, for example, our patients aren't just...we don't just do emergency medicine. Some of our patients have psychiatric needs, and some of our patients have, you know, oncological needs. So, we are actually the largest lead generator of patients into the right system for the United States because we're capturing them at the 911 call. So, there are so many great companies out there, and their number one problem is not how to solve for the things that they build; it's who's going to use it. How do you find more customers to actually use it?

+ +

And what a lot of these companies have realized is, hey, we've been trying to find these people for years, and yet they're walking into Tele911's front door. How do we partner up with them, and how do we basically show Tele911 the services that differentiate us in order for them to walk the patients towards us?

+ +

VICTORIA: That's such a cool stat to have that you're really putting people into the right path. And you have these great things that you all have achieved. I wonder, do you write key objectives and results? Because some of those it sounds like, well, I don't know you would ever be able to dream up that result [laughs], right?

+ +

DR. LIZARDO: Yeah. Well, yeah, we do function. We actually have a KPI doc that we use. We all track, and everyone at the company has visibility into them. It's super critical for everyone to be aligned no matter the level for that. I always say KPIs should not be unachievable, but they should be a stretch. Tele911 expects to grow 10x on its second year; very, very, very few companies in the history of digital health have grown 10x. And we are not only with foresight of, like, how we're going to achieve that; we're actually executing on a trajectory for that 10x.

+ +

That's a dangerous number to say for me as a CEO. And I look at the KPIs, and I'm like, well, we did 5x last year and cut almost a million in operating costs, so we can do 10x this year. Any consultant outside would be like, "Yeah, that's crazy," and then they look at our model, and they're like, "Yeah, these people might be crazy enough to actually do it [laughs]."

+ +

VICTORIA: Well, that's great. I mean, and, I guess, it's, like, all about how do you picture it? Like, are you trying to make a goal that gets everyone excited and gets everyone motivated and dreaming of the art of the possible, or are you just trying to make it so that you can check it off at the end of the year [laughs], right?

+ +

DR. LIZARDO: No. Actually, checking things off is...listen, at the end of the year, we're looking at the following year's list, right? We're not just checking things off. What we're doing is, we understand our mission, and because of our mission, what we're saying is, how aligned with our mission are we? I don't know if that's a circle or a checkpoint, but it's more about alignment for that mission of democratizing access to the best care as fast as possible upon a 911 call.

+ +

VICTORIA: I love that. That makes a lot of sense to me, just bringing it all back to the mission and the impact and why we're all here in the first place, right?

+ +

DR. LIZARDO: Exactly.

+ +

VICTORIA: I love that. Wonderful. Do you have any questions for me?

+ +

DR. LIZARDO: No. I mean, it was excellent to, one, just to be able to connect with you, two, to be...actually, as I was talking through these questions with you, you know, I realized how...just for context, my favorite author is Walter Isaacson. If you ever have the chance, please read one of his books. I'm reading Benjamin Franklin, and I read Steve Jobs' book. There's actually a few books. My favorite book in the whole world is Da Vinci by Walter Isaacson.

+ +

And, you know, I hope that people listening to this they can do two things. One, they can get to know me just a little bit and the things that we're doing, but two, they can be inspired because I think that's what we really need. There's a lot of people starting companies just because someone's doing something they could do it better. I mean, that's cool and all, but just so you know, most of those things actually fail. There's a reason why 9 out of 10 companies actually fail today. We don't need more copycats. Think of the art of the impossible and create that, and then pursue it as if nothing's holding you back. And if you do so, you just might find yourself with a Tele911 company.

+ +

VICTORIA: Well, that gets me fired up. I'm excited. I really love that advice. I appreciate you sharing that with us. Is there anything else that you would like to promote today?

+ +

DR. LIZARDO: Yes. If I could just take a second to share about this, I know that a lot of people who listen to this podcast want to start companies. A lot of people are trying to figure out, how do I get my idea started? But I also realized a lot of these people really haven't written down their ideas. They're basically pursuing things that haven't really been written down.

+ +

And one of the things that I shared, if we go back to this podcast, I said, this idea was written on the back of a greasy napkin in South Carolina during a storm at a Bojangles. I literally recall seasoned fries, dipping it in the grease of the chicken, which is terrible for you, by the way, cleaning my hands, and writing on the back: What if people call 911 and this and this and this happened?

+ +

And if I could leave you with one thing is, please write your ideas down. Send me photos of your napkins [chuckles], like, share napkins with people on a plane, people on a train, share these ideas, write them down. Because the ideas that write them down basically have an opportunity to go back and reestablish, to modify. But one of the things that I know is these ideas eventually echo in eternity at one place or another. And when I leave, just with an encouragement, please just write your ideas down.

+ +

VICTORIA: Great advice. I really appreciate that. You know, everything in moderation. I'm not going to say fried chicken or fries is bad for you [laughter] because I like it.

+ +

DR. LIZARDO: [laughs]

+ +

VICTORIA: But yeah, no, thank you so much. I loved sharing with that and, hopefully, people will share your ideas.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+p1JOHkmG + + ]]> + + Victoria Guido + + + 510: The Forecastr Formula :Steven Plappert’s Path to Startup Success + https://podcast.thoughtbot.com/510 + 3ef2d000-257f-4ce1-9ad1-760e39158209 + Thu, 01 Feb 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Victoria Guido interviews the CEO of Forecastr, Steven Plappert, about the company's journey and mission to assist non-finance savvy founders with financial modeling. Steven shares insights on balancing growth with financial health and the strategic introduction of a human element into Forecastr's software. He also discusses the company's goals, including cultural strength, profitability, and growth, as well as the crucial role of work-life balance in entrepreneurship. He and Victoria discuss how Forecasts and Thoughtbot integrate this philosophy into their culture. + 32:04 + no + + + Host Victoria Guido sits down with Steven Plappert, CEO of Forecastr, an online software designed to aid founders in financial modeling, which was born to help non-finance savvy founders understand and communicate their company's financial health. Despite the pandemic beginning right after Forecastr's launch in 2020, the company didn't pivot significantly thanks to extensive preparation and customer discovery before the launch. +Steven delves into the operational and strategic aspects of Forecastr, highlighting the importance of balancing growth with financial sustainability, a consistent theme in their business strategy. Forecastr's significant development was integrating a strong human element into their software service, a move very well-received by their customers. Steven also outlines the company's key objectives, including cultivating a solid culture, achieving profitability, and exploring opportunities for exponential growth. +Additionally, Steven discusses the importance of work-life balance, reflecting on his previous startup experience and emphasizing the necessity of balance for longevity and effectiveness in entrepreneurship. Victoria and Steven further explore how companies, including Forecastr and thoughtbot, incorporate these philosophies into their operations and culture. +Forecastr (https://www.forecastr.co/) +Follow Forecastr on LinkedIn (https://www.linkedin.com/company/forecastr/), X (https://twitter.com/forecastr), Instagram (https://www.instagram.com/forecastrco/), Facebook (https://www.facebook.com/ForecastrHQ), YouTube (https://www.youtube.com/forecastr), or TikTok (https://www.tiktok.com/@forecastrco). +Follow Steven Plappert on LinkedIn (https://www.linkedin.com/in/steven-plappert-59477b3b/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant R¬obots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Steven Plappert, CEO of Forecastr, an online software that helps founders who hate building financial models in Excel actually understand their numbers, predict runway, and get funded. Steven, thank you for joining us. +STEVEN: Hey, yeah, Victoria, thanks for having me. I'm stoked to be here. What's up, guys? +VICTORIA: Just to get us warmed up here a little bit, can you tell me what's going on in your world? +STEVEN: Well, you know, what is going on in my world? I had a great year last year, very healthy. I have a loving fiancé, and I'm getting married this year, which is going to be super fun. And, obviously, running a business, which takes up more than its fair share of my life. But yeah, it's early Jan, so I've been kind of reflecting on my life, and I got a lot to be grateful for, Victoria, I really do. +VICTORIA: That's wonderful. You know, I used to work with a VP of strategic growth who likened forming partnerships with companies as getting into a marriage and building that relationship and that level of trust and communication that you have, which I think is really interesting. +STEVEN: Oh, for sure. Emily always, Emily is my fiancé, she always says that, you know, Forecastr is essentially my mistress, if you will, you know what I mean? Because, like, that's [laughs] where the rest of my time goes, isn't it? Between hanging out with her and working on the company, you know, so... +VICTORIA: So, how long have you been in a relationship with your business around Forecastr? [laughs] +STEVEN: Yeah, right? Yeah [laughs]. Four years with this one. So, you know, we started it actually January 1st of 2020, going into the pandemic, although we didn't know it at the time. And so, we just celebrated our four-year anniversary a few weeks ago. +VICTORIA: Well, that's really exciting. So, I'm curious about when you started Forecastr, what was the essential problem that you were trying to solve that you had identified in the market? +STEVEN: I'd say the main problem we were trying to solve is that, like, specifically founders, you know, startup founders, really struggle to get, like, a clear picture of their financial health or, like, just the financial aspect of their business. And then they also struggle to communicate that to investors because most founders aren't finance people. You know, like, most people that start a company they don't do it because they're excellent in even, like, business or finance or anything like that. They usually do it because, like, they've identified some problem; they've lived it; they've breathed it, you know what I mean? They're some kind of subject matter expert. They may be good at sales, or marketing, or product. +But a lot of times, finance is, like, a weak part for them, you know, it's not something that they're strong in. And so, they really have a hard time, like, understanding the viability of the business and communicating the financial outcome of the company to investors and stuff like that. And my co-founder Logan and I live that because all we did all day was built financial models in Excel for startup founders working for a CFO shop called Venture First. So, that's what we really saw. +We really saw that just, you know, it's really hard for folks to get this clear picture. And we thought a big part of that, at least, was just the fact that, you know, there's no great software for it. It was just like, people are using Excel, which, you know, for people that are great in finance, you know, works but for most people, doesn't. And so, yeah, I think that that's what kind of inspired Logan and I to fly the coop there at Venture First and start a company. +VICTORIA: No, that's really interesting. So, you found this problem. You knew that this was an issue for founders, and you built this hypothesis and started it. I think you said, like, right before 2020, right before the pandemic. So, were there any decisions you made that once you got more information or once you got started, you decided to pivot? And, like, what were those pivot points for you early on? +STEVEN: There wasn't a lot of pivoting early on, I will say. And a part of that is because, like, this isn't my first company. I started a company right out of college back in 2013 called FantasyHub. In that company, we pivoted a lot and, largely because we didn't really put a lot of forethought into that company when we launched it, you know, we didn't do any customer discovery. We just launched the company. And then we skinned our knees a bunch of times [laughs] as we scaled that company up and had to change gears a lot of times. +In Forecastr, you know, we had actually been kind of building towards starting the company for 18 months. So, Logan and I actually had the idea originally in middle of 2018. And we decided at that time, look, like, we're not going to go launch this company right away because we got full-time jobs, and we might as well de-risk it. So, we spent about 12 to 18 months just doing a lot of customer discovery, kind of in stealth mode while at Venture First. +After about six months, we brought it up to Venture First and said, "Hey, here's this idea for a company we have. We want to go do it." You know, to Venture First's credit, you know, rather than viewing that territorially and saying, "Hey, you know, there's a great new product line for our company," they really inspired us to go forward with it. They said, "Hey, this is great. We want to support you guys." They put some money in. We did some more discovery. We built a prototype. +So, long-winded way of saying that by the time we actually got to the starting line in 2020, you know, we had 18 months' worth of really clear thought put into this thing. And we had been building in this space for years, you know, building financial models and Excel for founders. So, I think we had a great understanding of the customer. We had a great understanding of the market and the needs. We'd done our diligence in terms of distribution and figuring out how we wanted to generate, you know, a good, healthy funnel for the business. And so, it was really just kind of a matter of execution at that point. +And, you know, here we are four years in, and there really hasn't been anything that we've done that's really pivoted the business that much across those four years, except for one moment, which was actually six months ago. So, in July of 2023, we did finally have our first kind of pivot moment where one of the interesting things about Forecastr versus some other solutions in the market is that we're not just a product, just a SaaS platform. There's a real strong human layer to our solution. We've always felt like a SaaS plus human model was the right model for financial modeling for startups because a lot of these startup founders don't have finance expertise on staff or inherently. +And about six months ago, it wasn't as much of a pivot as it was a double down. You know, we really doubled down on that human element, you know, and now that human element isn't just through, like, a white glove onboarding and some email support. But we actually do give our customers an analyst in addition to the software that's with them for the lifetime of their subscription and is with them every step of the way. And so, that's the only time that we really made, like, a significant change into what we were doing. And it was just, I think, off the back of three years of saying, "Hey, like [chuckles], people really love the human element, you know, let's lean into that." +VICTORIA: I love that you saw that you couldn't solve this problem with just technology and that you planned for and grew the people element as well. And I'm curious: what other decisions did you have to make as you were growing the business, how to scale the tech side or the people side? +STEVEN: So many decisions, right? And that's why I tell people all the time, I'm like, you know, I've been a founder for 11 years now. And, in my opinion, by far, the hardest part about being a founder is that all day, every day, you have to make a bunch of decisions. And you hardly ever have enough data to, like, know, you're making the right decision. So, you got to make a bunch of judgment calls, and ultimately, these are judgment calls that could make or break your company. And it's really taxing. It's taxing on the mind. It's stressful, you know. It is not easy. So, you know, I think it's one of the really hard things about being an entrepreneur. +I would say one of the most consistent decisions that we've had to make at the highest level is decisions around kind of capital preservation, fiscal responsibility, and investing in the growth. So, categorically, it's like, on the one hand, you have a desire to build the company kind of sustainably, to get to profitability, to have a healthy working model, you know, where you have some real staying power, you know. And that line of thinking leads you to, you know, be conscientious about investments that you're making that, you know, increase the burn. +On the other hand, you have a desire to grow the company very quickly. You know, you have certain benchmarks you need to meet, you know, in order to be attractive to venture capitalists. And so, you have decisions that you want to make, you know, to invest in that growth. And so, I think that's a very consistent theme that's played out across the four years is Logan and I trying to walk that tightrope between growing 2 to 3X year over year and being really mindful of the company's burn, you know, both for equity preservation and just to build the company in a more sustainable way. +And I think as financial professionals and founders, the finance person in Logan and I a lot of times wants to be more conservative. The founder in Logan and I, a lot of times, wants to be more aggressive. And so, we kind of just, like, let those two forces kind of play themselves out. And I think it creates, like, a nice, healthy tension. +VICTORIA: That is really interesting, yeah. And sometimes you have to make a guess [chuckles] and go with it and then see the results of what happens. So, you're a financial forecasting company. What kind of, like, key results or objectives are you working towards this year with Forecastr? +STEVEN: Yeah, great question. So, we're really mindful of this kind of stuff. I'd say, you know, it's something that we really consider at a deep level is, like, you have to ultimately set objectives, which are very aligning and clarifying, you know, at an executive level, and then those should kind of filter all the way down through the organization. +Because so much, I think, of building a company is you have to kind of punch above your weight. You have to grow faster than [chuckles] the resources that you're putting into it might expect or whatever. I mean, you have limited resources, limited time, but you got to go really quickly. I think alignment is a big part of that, and that starts with setting clear objectives. +So, we actually have three very clear objectives, really four. The first one is living up to our cultural values. You know, we're a culture-first organization. We believe that, like, culture, you know, kind of eats strategy for breakfast, that age-old kind of cliché, but it's true. It's just like, I think, you know, if you build a really good culture, people are just...they're happier. They're more productive. You get more done. So, that is our number one strategic objective. +Number two is to become profitable. Like I mentioned, we want to become profitable. We want to build a sustainable company. So, by setting that objective, it kind of forces us to be conscientious about spend and only invest in areas that we think is, like, a one plus one equals three. +Our third strategic objective is reach 5 million in annual recurring revenue by the end of the year. We're at 2.4 right now. We want to at least double year over year. That's kind of, like, the minimum threshold to keep playing the venture game. +And then number four is unlock exponential growth opportunities. So, we definitely adopt the philosophy of, like, hey, we've got a model. It's working. We've got 700 customers, you know, we've got two and a half million in annual recurring revenue. So, like, 80% of our focus should be on becoming profitable and hitting $5 million in annual recurring revenue. Like, that's, like, the bread and butter there, just keep doing what's working. But 20% of our attention should be paid to, well, what could we be doing to, like, triple down on that, you know, to really start to create an exponential growth curve? +And, for us, that stuff and, like, kind of the data in investor space, like, there's a lot of interesting things that we could do, of course, as long as it's consensual, anonymized, et cetera, safe and secure, you know, with the kind of data that we have on private companies, you know, anonymously benchmarking companies against their peers, things like that. And I think there's a really big opportunity that we have to serve investors as well, you know, and to create a better investor experience when it comes to financial reporting, also something that we think can unlock exponential growth. So, those are the four objectives that we have going into this year. +VICTORIA: Well, I really appreciate that you had culture at number one, and it reminds me, you know, you said it's old adage, but it's true, and you can verify that in reports like the State of DevOps Report. The number one indicator of a high-security environment is the level of trust and culture that you have within your company, not necessarily the technology or tools that you're using. So, being a financial company, I think you're in a good position [chuckles] to have, like, you know, protect all those assets and protect your data. +And yeah, I'm curious to hear more about what you said about just unlocking, like, exponential growth. It's hard to keep both the let's keep the lights on and keep running with what we have, and make room for these bigger strategic initiatives that are really going to help us grow as a company and be more sustainable over time. So, how do you make room for both of those things in a limited team? +STEVEN: Yeah, it's a great question. And it's not easy, I would say. I mean, I think the way we make room for it probably on the frontend is just, like, being intentional about creating that space. I mean, ultimately, putting unlocking exponential growth opportunities on the strategic company roadmap, which is the document that kind of memorializes the four objectives that I just went through, that creates space inherently. It's one of four objectives on the board. +And that's not just, like, a resource that sits, you know, in a folder somewhere. We use the OKR system, you know, which is a system for setting quarterly objectives and things like that. And these strategic objectives they make it on our OKR board, which filters down into our work. So, I think a big piece of creating the space is just as an executive and as a leader, you know, being intentional about [chuckles] putting it on the board and creating that space. +The thing that you have to do, though, to be mindful is you have to make sure that you don't get carried away with it. I mean, like you said, at the end of the day, succeeding in a business requires a proper balancing of short-term and long-term priorities. You know, if you're focused too much on the short term, you know, you can kind of hamstring yourself in the long run. Yeah, maybe you build, like, a decent business, but you don't quite, you know, reach your highest potential because you're not investing in some of those things that take a while to develop and come to play in the long run. +But if you're too focused on the long run, which is what these exponential opportunities really are, you know, it's very easy to lose your way [laughs] in the short term, and it's very easy to die along the way. You know, I do think of startups as much of a game of survival as anything. I always say survive until you thrive. And so, that's where the 80/20 comes in, you know, where we just kind of say, "Hey, look, like, 80% of our time and energy needs to be devoted to kind of short-term and less risky priorities, such as doubling down on what's already working. 20% of our time, thereabouts, can be devoted to some of these more long-term strategic objectives, like unlocking exponential growth. +And I think it just takes a certain mindfulness and a certain intentionality to, like, every week when you're organizing your calendar, and you're, like, talking with your team and stuff like that, you're just always trying to make sure, hey, am I roughly fitting into that framework, you know? And it doesn't have to be exact. Some weeks, it may be more or less. But I think that's kind of how we approach it, you know, conceptually. +VICTORIA: Oh, what a great perspective. I think that I really like hearing those words about, like, balance and, like, being intentional. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +VICTORIA: You mentioned earlier that you're getting married, so, like, maybe you can talk about how are you intentional with your own time and balancing your personal life and making room for these, you know, big life changes while dealing with also the stress of being in kind of a survivor mode with the company. +STEVEN: Like I mentioned, this is my second company, and Emily, bless her heart, my fiancé, she's been with me my entire entrepreneurial career. We started dating the first month that I started my first company, FantasyHub. And in that company, I ran that company for three years. We took it through Techstars down in Austin. It was a consumer gaming company. Interesting company. It ended up being a failure but, like, super interesting and set me on my path. Yeah, I was a complete and total workaholic. I worked around the clock. It was a fantasy sports company, so weekends were our big time, and I worked seven days a week. I worked, like, a lot of 80-hour-plus weeks. +And, you know, looking back on it, it was a lot of fun, but it was also miserable. And I also burned out, you know, about six months before the company failed. And had the company not failed when it did, you know, I don't know what the future would have held for us. I was really out of balance. You know, I had deprioritized physical health. I hadn't worked out in years. I wasn't healthy. I had deprioritized mental health. Emily almost left me as a part of that company because I wasn't giving her any attention. +And so, you know, when that company failed, and I was left with nothing, you know, and I just was kind of, like, sitting there licking my wounds [laughs], you know, in my childhood bedroom at my parents' house, you know, I was like, you know what? Like, I don't know that that was really worth it, and I don't know that that was the right approach. And I kind of vowed...in that moment, I was like, you know, look, I'm a startup founder. I love building these companies, so I'm, like, definitely going to do it again, but I'm not going to give it my entire life. +Like, regardless of your religious beliefs, like, we at least have one life to live. And in my opinion, there's a lot more to life than [chuckles] just cranking out work and building companies. Like, there's a whole world to explore, you know, and there's lots of things that I'm interested in. So, this time around, I'm very thoughtful about creating that balance in my life. +I set hard guidelines. There's hard, like, guardrails, I guess I should say, when I start and end work, you know, and I really hold myself accountable to that. Emily holds me accountable to that. And I make sure that, like, I work really hard when I'm at work, but I take the mask off, you know, so to speak, when I'm at home. And I just kind of...I don't deprioritize the rest of my life like I did when I was running FantasyHub. So, I think it's super important. +I think it's a marathon building companies. I think you got to do that. I think it's what's in the best interest of the company and you as an individual. So, I think it's something I do a lot better this time around. And I think we're all better off for it, not the least of which is, like, one of our six cultural values is live with balance, and that's why. +You know, because, like, we adopt the philosophy that you don't have to work yourself to death to build a great company. You can build a great company working a pretty reasonable workload, you know what I mean? It's not easy. It is kind of a pressure cooker trying to get that much done in that little time, but I think we're living proof that it works. +VICTORIA: And if you don't make time to rest, then your ability to make good decisions and build high-quality products really starts to suffer eventually, like, I think, is what you saw at the end there. So, I really appreciate you sharing that and that personal experience. And I'm glad to see the learning from that, and making sure that's a core part of your company values the next time you start a company makes a lot of sense to me. +STEVEN: Yeah, totally, you know, yeah. And I've always remembered, although this might be an extreme and a privileged extreme, but, you know, J.P. Morgan, the person, was famous for saying, "I get more done in 9 months than I get in 12," in relationship to the fact that he would take his family over to Europe for, like, three months of the year and, like, summer in Europe and not work. And so, while that's probably an unrealistic, you know, ideal for a startup founder, there's some truth to it, you know what I mean? Like you said, like, you got to rest. +And, in fact, if you rest more, you know, yeah, you might be working less hours. You'll actually get more done. You're a lot clearer while you're at work. It's a mindset game. It's a headspace game. And the better you can put yourself in that good mindset, that good headspace, the more effective you are. Yeah, there's just a lot of wisdom to that approach. +VICTORIA: Right. And, you know, thoughtbot is a global company, so we have employees all over the world. And I think what's interesting about U.S-based companies, I'm interested in how Forecastr might even help you with this, is that when you start a company, you basically form, like, a mini-government for your employees. +And you have input over to how much they paid, how much healthcare they get. You have input over their hours and how much leave and everything. And so, trying to balance all those costs and create a good environment for your employees and make sure they have enough time for rest and for personal care. How does Forecastr kind of help you also imagine all of those costs [laughs] and make sense of what you can offer as a company? +STEVEN: I would say the main way that we help folks do that, and we really do play in that space, is just by giving you a clear picture of what the future holds for your company from a financial perspective. I mean, it's one of the things that I think is such a superpower when it comes to financial modeling, you know, it can really help you make better decisions along these lines because, like, what does a financial model do? +A financial model just simulates your business into the future, specifically anything related to the cash flow of your business, you know, cash in, cash out, revenue expenses, and the like. And so, your people are in there, and what they're paid is in there and, you know, your revenue and your expenses, your cash flow, your runway, all that's in the model. +One of the things I feel like we do really help people do is just get a clearer picture of like, hey, what do the next 3, 6, 12, you know, 24 months look like for my company? What is my runway? When am I going to run out of money? What do I need to do about that? Can I afford to give everybody a raise, or can I afford to max out my benefits plan or whatever that is? It's like, you can make those assessments more easily. +You know, if you have a financial model that actually makes sense to you that you can look at and say, oh, okay, cool. Yeah, I can offer that, like, Rolls Royce benefits plan and still have 18 months' worth of runway, or maybe I can't [laughs]. And I have to say, "Sorry, guys, you know, like, we're cash-constrained, and this is all we can do for now. But maybe when we raise that next round and when we hit these growth milestones, you know, we can expand that." +So yeah, I think it's all, for us, about just, like, helping founders make better decisions, whether they be your decisions around employees and benefits, et cetera, or growth, or fundraising, you know, through the power of, like, financial health and hygiene. +VICTORIA: Great. Thank you. I appreciate you letting me bring it all the way back [laughs]. Yeah, let me see. Let me go through my list of questions and see what else we have here. Do you have any questions for me or thoughtbot? +STEVEN: Yeah. I mean, so, like, how do you guys think about this kind of stuff? Like, you know, you said thoughtbot's a global company at this point, but the name would imply, you know, a very thoughtful one. So, I'd be curious in y'alls kind of approach to just, like, culture and balance and some of these things that we're talking about kind of, like, straddling that line, you know, between, like, working really hard, which you have to do to build a great company but, you know, being mindful of everything else that life has to offer. +VICTORIA: Yeah. Well, I think thoughtbot, more than any other company I've ever worked for, really emphasizes the value of just, like, people really want you to have a work-life balance and to be able to take time off. And, you know, I think that for a company that does consulting and we're delivering at a certain quality, that means that we're delivering at the quality where if someone needs to take a week off for a vacation, there's enough documentation; there's enough backup support for that service to not be impacted. So, that gives us confidence to be able to take the time off [chuckles], and it also just ends up being a better product for our clients. +Like, our team needs to be well-rested. They need to have time to invest in themselves and learning the latest technology, the latest upgrades, contributing to open source, and writing about the problems they're seeing, and contributing back to the community. So, we actually make time every Friday to spend on those types of projects. It's kind of like you were saying before, like, you get as much done in four days as many companies get in five because that time is very highly focused. And then you're getting the benefit of, you know, continually investing in new skills and making sure the people you're working with are at the level that you're paying for [laughs]. +STEVEN: Yeah, right. No, that's super cool. That's super cool. +VICTORIA: Yeah, and, actually, so we're all remote. We're a fully remote company, and we do offer some in-person events twice a year, so that's been a lot of fun for me. And also, getting to, like, go to conferences like RubyConf and RailsConf and meeting the community has been fantastic. Yeah, you have a lot of value of self-management. So, you have the ability to really adjust your schedule and communicate and work with what meets your needs. It's been really great. +STEVEN: Yeah, I love that, too. And we're also a remote company, and I think getting together in person, like you just talked about it, is so important. We can only afford to do it once a year right now as an earlier-stage company. But as amazing as, you know, Zoom and things like this are, it's like, there's not really a perfect replacement for that in-person experience, you know. +VICTORIA: I agree, and I also agree that, like, once a year is probably enough [laughter]. That's a great amount of time. Like, it really does help because there are so many ways to build relationships remotely, but sometimes, at least just meeting in person once is enough to be like, oh yeah, like, you build a stronger connection, and I think that's great. +Okay. Let me see. What other questions do we have? Final question: is there anything else that you would like to promote? +STEVEN: I guess it's my job to say we are a really awesome financial modeling platform and team in general. So, if you are a startup founder or you know a startup founder out there that just could use some help with their financial model, you know, it is definitely something that we'd love to do. And we do a ton of education and a ton of help. We've got a ton of resources that are even freely available as well. So, our role in the market is just to get out there and help folks build great financial models, whether that be on Forecastr or otherwise, and that's kind of the approach that we take to it. +And our philosophy is like, if we can get out there and do that, you know, if we can be kind of the go-to resource for folks to build great models regardless, you know, of what that means for them, a rising tide will float all boats, and our boat the most of which, hopefully. So [laughs], if you need a model, I'm your guy. +VICTORIA: Thank you so much for sharing that. And I have a fun question for you at the end. What is your favorite hike that you've been on in the last three years or ever, however long you want to go back? [laughs] +STEVEN: Well, I would say, you know, I did have the great pleasure this year of returning to the Appalachian Trail to hike the Roan Highlands with a friend of mine who was doing a thru-hike. So, a friend of mine did a southbound thru-hike on the A.T. this year, went from Maine to Georgia. Good friend of mine. And I had not been on the Appalachian Trail since I did a thru-hike in 2017. So, I had not returned to the trail or to that whole community. It's just a very special community. It really is a group of, like, really awesome, eclectic people. +And so, yeah, this last year, I got to go down to the Roan Highlands in Tennessee. It's a beautiful, beautiful area of Tennessee and in the Southeast, rolling hills and that kind of thing. And hike, for him, for, like, three or four days and just be a part of his journey. Had a ton of fun, met some awesome people, you know, great nature, and totally destroyed my body because I was not prepared to return to the grueling nature of the Appalachian Trail. So yeah, I'd have to say that one, Victoria. I'd have to say that was my favorite in the last couple of years for sure. +VICTORIA: Yeah, it's beautiful there. I've hiked certain parts of it. So, I've heard that obviously the Appalachian Trail, which is the eastern side of the United States, was the earlier trail that was developed because of the dislocation of people over time and that they would create the trail by getting to a peak and then looking to another peak and being like, "Okay, that's where I'm going to go." So, when you say it's grueling, I was, like, a lot of up and down hills. +And then what I've heard is that the Pacific Trail on the western part of the United States, they did more of figuring out how to get from place to place with minimizing the elevation change, and so it's a much more, like, sustainable hike. Have you ever heard that? +STEVEN: Oh yeah, that is 100% true. In terms of, like, the absolute change in elevation, not, like, the highest elevation and the lowest, just, like, the change up and down, there's twice as much going up and down on the A.T. as there is on the Pacific Crest Trail. And the Pacific Crest Trail is graded for park animals, so it never gets steeper than, like, a 15% grade. +So, it's real groovy, you know, on the PCT where you can just get into a groove, and you can just hike and hike and hike and hike for hours, you know, versus the A.T. where you're going straight up, straight down, straight up, straight down, a lot of big movements, very exhausting. I've hiked a good chunk of the PCT and then, obviously, the whole A.T., so I can attest, yes, that is absolutely true. +VICTORIA: I feel like there's an analogy behind that and what Forecastr does for you. Like, you'll be able [laughs] to, like, smooth out your hills a little bit more [laughs] with your finances, yeah. +STEVEN: [laughs] Oh, I love that. Absolutely. Well, and I've honestly, like, I've often likened, you know, building a company and hiking the Appalachian Trail because it is one of those things where one of the most clarifying things about hiking a long trail is you just have this one monster goal that's, you know, that's months and months ahead of you. But you just got to get up every day, and you just got to grind it out. And every day is grindy, and it's hard, you know, but every day you just get one step closer to this goal. +And it's one of the cool things about a trail is that you kind of steep yourself in that one goal, you know, one-track mind. And, you know, like we were saying earlier, there's so much more to life. So, you can't and probably shouldn't do that with your startup. You should continue to invest in other aspects of your life. But maybe while you're within the four walls of your office or when you open up that laptop and get to work on your computer, you know, if you take that kind of similar approach where you got this big goal that's, you know, months or years away but every day you just got to grind it out; you just got to work hard; you got to do what you can to get 1 step closer. And, you know, one day you'll wake up and you'll be like, oh shit, like, I'm [laughs] pretty close, you know what I mean? Yeah, I think there's definitely some similarities to the two experiences. +VICTORIA: I appreciate that, yeah. And my team is actually it's more like starting up a business within thoughtbot. So, I'm putting together, like, my three-year plan. It's very exciting. And I think, like, those are the types of things you want to have. It's the high-level goal. Where are we going? [chuckles] Are we on our track to get there? But then day to day, it's like, okay, like, let's get these little actions done that we need to do this week [laughs] to build towards that ultimate goal. +Well, thank you so much for joining us today, Steven. I really enjoyed our conversation. Is there anything final you want to say? +STEVEN: I just want to thank you, Victoria. I think it's a wonderful podcast that you guys put on, and I really appreciate the opportunity to be here and to chat with you. You're lovely to talk to. I enjoyed the conversation as well, and I hope everyone out there did, also. So, let's make it a great 2024. +VICTORIA: Thank you so much. Yeah, this is actually my second podcast recording of the year, so very exciting for me. I appreciate it. Thanks so much for joining again. +So, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg. +And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Host Victoria Guido sits down with Steven Plappert, CEO of Forecastr, an online software designed to aid founders in financial modeling, which was born to help non-finance savvy founders understand and communicate their company's financial health. Despite the pandemic beginning right after Forecastr's launch in 2020, the company didn't pivot significantly thanks to extensive preparation and customer discovery before the launch.

+ +

Steven delves into the operational and strategic aspects of Forecastr, highlighting the importance of balancing growth with financial sustainability, a consistent theme in their business strategy. Forecastr's significant development was integrating a strong human element into their software service, a move very well-received by their customers. Steven also outlines the company's key objectives, including cultivating a solid culture, achieving profitability, and exploring opportunities for exponential growth.

+ +

Additionally, Steven discusses the importance of work-life balance, reflecting on his previous startup experience and emphasizing the necessity of balance for longevity and effectiveness in entrepreneurship. Victoria and Steven further explore how companies, including Forecastr and thoughtbot, incorporate these philosophies into their operations and culture.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant R¬obots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Steven Plappert, CEO of Forecastr, an online software that helps founders who hate building financial models in Excel actually understand their numbers, predict runway, and get funded. Steven, thank you for joining us.

+ +

STEVEN: Hey, yeah, Victoria, thanks for having me. I'm stoked to be here. What's up, guys?

+ +

VICTORIA: Just to get us warmed up here a little bit, can you tell me what's going on in your world?

+ +

STEVEN: Well, you know, what is going on in my world? I had a great year last year, very healthy. I have a loving fiancé, and I'm getting married this year, which is going to be super fun. And, obviously, running a business, which takes up more than its fair share of my life. But yeah, it's early Jan, so I've been kind of reflecting on my life, and I got a lot to be grateful for, Victoria, I really do.

+ +

VICTORIA: That's wonderful. You know, I used to work with a VP of strategic growth who likened forming partnerships with companies as getting into a marriage and building that relationship and that level of trust and communication that you have, which I think is really interesting.

+ +

STEVEN: Oh, for sure. Emily always, Emily is my fiancé, she always says that, you know, Forecastr is essentially my mistress, if you will, you know what I mean? Because, like, that's [laughs] where the rest of my time goes, isn't it? Between hanging out with her and working on the company, you know, so...

+ +

VICTORIA: So, how long have you been in a relationship with your business around Forecastr? [laughs]

+ +

STEVEN: Yeah, right? Yeah [laughs]. Four years with this one. So, you know, we started it actually January 1st of 2020, going into the pandemic, although we didn't know it at the time. And so, we just celebrated our four-year anniversary a few weeks ago.

+ +

VICTORIA: Well, that's really exciting. So, I'm curious about when you started Forecastr, what was the essential problem that you were trying to solve that you had identified in the market?

+ +

STEVEN: I'd say the main problem we were trying to solve is that, like, specifically founders, you know, startup founders, really struggle to get, like, a clear picture of their financial health or, like, just the financial aspect of their business. And then they also struggle to communicate that to investors because most founders aren't finance people. You know, like, most people that start a company they don't do it because they're excellent in even, like, business or finance or anything like that. They usually do it because, like, they've identified some problem; they've lived it; they've breathed it, you know what I mean? They're some kind of subject matter expert. They may be good at sales, or marketing, or product.

+ +

But a lot of times, finance is, like, a weak part for them, you know, it's not something that they're strong in. And so, they really have a hard time, like, understanding the viability of the business and communicating the financial outcome of the company to investors and stuff like that. And my co-founder Logan and I live that because all we did all day was built financial models in Excel for startup founders working for a CFO shop called Venture First. So, that's what we really saw.

+ +

We really saw that just, you know, it's really hard for folks to get this clear picture. And we thought a big part of that, at least, was just the fact that, you know, there's no great software for it. It was just like, people are using Excel, which, you know, for people that are great in finance, you know, works but for most people, doesn't. And so, yeah, I think that that's what kind of inspired Logan and I to fly the coop there at Venture First and start a company.

+ +

VICTORIA: No, that's really interesting. So, you found this problem. You knew that this was an issue for founders, and you built this hypothesis and started it. I think you said, like, right before 2020, right before the pandemic. So, were there any decisions you made that once you got more information or once you got started, you decided to pivot? And, like, what were those pivot points for you early on?

+ +

STEVEN: There wasn't a lot of pivoting early on, I will say. And a part of that is because, like, this isn't my first company. I started a company right out of college back in 2013 called FantasyHub. In that company, we pivoted a lot and, largely because we didn't really put a lot of forethought into that company when we launched it, you know, we didn't do any customer discovery. We just launched the company. And then we skinned our knees a bunch of times [laughs] as we scaled that company up and had to change gears a lot of times.

+ +

In Forecastr, you know, we had actually been kind of building towards starting the company for 18 months. So, Logan and I actually had the idea originally in middle of 2018. And we decided at that time, look, like, we're not going to go launch this company right away because we got full-time jobs, and we might as well de-risk it. So, we spent about 12 to 18 months just doing a lot of customer discovery, kind of in stealth mode while at Venture First.

+ +

After about six months, we brought it up to Venture First and said, "Hey, here's this idea for a company we have. We want to go do it." You know, to Venture First's credit, you know, rather than viewing that territorially and saying, "Hey, you know, there's a great new product line for our company," they really inspired us to go forward with it. They said, "Hey, this is great. We want to support you guys." They put some money in. We did some more discovery. We built a prototype.

+ +

So, long-winded way of saying that by the time we actually got to the starting line in 2020, you know, we had 18 months' worth of really clear thought put into this thing. And we had been building in this space for years, you know, building financial models and Excel for founders. So, I think we had a great understanding of the customer. We had a great understanding of the market and the needs. We'd done our diligence in terms of distribution and figuring out how we wanted to generate, you know, a good, healthy funnel for the business. And so, it was really just kind of a matter of execution at that point.

+ +

And, you know, here we are four years in, and there really hasn't been anything that we've done that's really pivoted the business that much across those four years, except for one moment, which was actually six months ago. So, in July of 2023, we did finally have our first kind of pivot moment where one of the interesting things about Forecastr versus some other solutions in the market is that we're not just a product, just a SaaS platform. There's a real strong human layer to our solution. We've always felt like a SaaS plus human model was the right model for financial modeling for startups because a lot of these startup founders don't have finance expertise on staff or inherently.

+ +

And about six months ago, it wasn't as much of a pivot as it was a double down. You know, we really doubled down on that human element, you know, and now that human element isn't just through, like, a white glove onboarding and some email support. But we actually do give our customers an analyst in addition to the software that's with them for the lifetime of their subscription and is with them every step of the way. And so, that's the only time that we really made, like, a significant change into what we were doing. And it was just, I think, off the back of three years of saying, "Hey, like [chuckles], people really love the human element, you know, let's lean into that."

+ +

VICTORIA: I love that you saw that you couldn't solve this problem with just technology and that you planned for and grew the people element as well. And I'm curious: what other decisions did you have to make as you were growing the business, how to scale the tech side or the people side?

+ +

STEVEN: So many decisions, right? And that's why I tell people all the time, I'm like, you know, I've been a founder for 11 years now. And, in my opinion, by far, the hardest part about being a founder is that all day, every day, you have to make a bunch of decisions. And you hardly ever have enough data to, like, know, you're making the right decision. So, you got to make a bunch of judgment calls, and ultimately, these are judgment calls that could make or break your company. And it's really taxing. It's taxing on the mind. It's stressful, you know. It is not easy. So, you know, I think it's one of the really hard things about being an entrepreneur.

+ +

I would say one of the most consistent decisions that we've had to make at the highest level is decisions around kind of capital preservation, fiscal responsibility, and investing in the growth. So, categorically, it's like, on the one hand, you have a desire to build the company kind of sustainably, to get to profitability, to have a healthy working model, you know, where you have some real staying power, you know. And that line of thinking leads you to, you know, be conscientious about investments that you're making that, you know, increase the burn.

+ +

On the other hand, you have a desire to grow the company very quickly. You know, you have certain benchmarks you need to meet, you know, in order to be attractive to venture capitalists. And so, you have decisions that you want to make, you know, to invest in that growth. And so, I think that's a very consistent theme that's played out across the four years is Logan and I trying to walk that tightrope between growing 2 to 3X year over year and being really mindful of the company's burn, you know, both for equity preservation and just to build the company in a more sustainable way.

+ +

And I think as financial professionals and founders, the finance person in Logan and I a lot of times wants to be more conservative. The founder in Logan and I, a lot of times, wants to be more aggressive. And so, we kind of just, like, let those two forces kind of play themselves out. And I think it creates, like, a nice, healthy tension.

+ +

VICTORIA: That is really interesting, yeah. And sometimes you have to make a guess [chuckles] and go with it and then see the results of what happens. So, you're a financial forecasting company. What kind of, like, key results or objectives are you working towards this year with Forecastr?

+ +

STEVEN: Yeah, great question. So, we're really mindful of this kind of stuff. I'd say, you know, it's something that we really consider at a deep level is, like, you have to ultimately set objectives, which are very aligning and clarifying, you know, at an executive level, and then those should kind of filter all the way down through the organization.

+ +

Because so much, I think, of building a company is you have to kind of punch above your weight. You have to grow faster than [chuckles] the resources that you're putting into it might expect or whatever. I mean, you have limited resources, limited time, but you got to go really quickly. I think alignment is a big part of that, and that starts with setting clear objectives.

+ +

So, we actually have three very clear objectives, really four. The first one is living up to our cultural values. You know, we're a culture-first organization. We believe that, like, culture, you know, kind of eats strategy for breakfast, that age-old kind of cliché, but it's true. It's just like, I think, you know, if you build a really good culture, people are just...they're happier. They're more productive. You get more done. So, that is our number one strategic objective.

+ +

Number two is to become profitable. Like I mentioned, we want to become profitable. We want to build a sustainable company. So, by setting that objective, it kind of forces us to be conscientious about spend and only invest in areas that we think is, like, a one plus one equals three.

+ +

Our third strategic objective is reach 5 million in annual recurring revenue by the end of the year. We're at 2.4 right now. We want to at least double year over year. That's kind of, like, the minimum threshold to keep playing the venture game.

+ +

And then number four is unlock exponential growth opportunities. So, we definitely adopt the philosophy of, like, hey, we've got a model. It's working. We've got 700 customers, you know, we've got two and a half million in annual recurring revenue. So, like, 80% of our focus should be on becoming profitable and hitting $5 million in annual recurring revenue. Like, that's, like, the bread and butter there, just keep doing what's working. But 20% of our attention should be paid to, well, what could we be doing to, like, triple down on that, you know, to really start to create an exponential growth curve?

+ +

And, for us, that stuff and, like, kind of the data in investor space, like, there's a lot of interesting things that we could do, of course, as long as it's consensual, anonymized, et cetera, safe and secure, you know, with the kind of data that we have on private companies, you know, anonymously benchmarking companies against their peers, things like that. And I think there's a really big opportunity that we have to serve investors as well, you know, and to create a better investor experience when it comes to financial reporting, also something that we think can unlock exponential growth. So, those are the four objectives that we have going into this year.

+ +

VICTORIA: Well, I really appreciate that you had culture at number one, and it reminds me, you know, you said it's old adage, but it's true, and you can verify that in reports like the State of DevOps Report. The number one indicator of a high-security environment is the level of trust and culture that you have within your company, not necessarily the technology or tools that you're using. So, being a financial company, I think you're in a good position [chuckles] to have, like, you know, protect all those assets and protect your data.

+ +

And yeah, I'm curious to hear more about what you said about just unlocking, like, exponential growth. It's hard to keep both the let's keep the lights on and keep running with what we have, and make room for these bigger strategic initiatives that are really going to help us grow as a company and be more sustainable over time. So, how do you make room for both of those things in a limited team?

+ +

STEVEN: Yeah, it's a great question. And it's not easy, I would say. I mean, I think the way we make room for it probably on the frontend is just, like, being intentional about creating that space. I mean, ultimately, putting unlocking exponential growth opportunities on the strategic company roadmap, which is the document that kind of memorializes the four objectives that I just went through, that creates space inherently. It's one of four objectives on the board.

+ +

And that's not just, like, a resource that sits, you know, in a folder somewhere. We use the OKR system, you know, which is a system for setting quarterly objectives and things like that. And these strategic objectives they make it on our OKR board, which filters down into our work. So, I think a big piece of creating the space is just as an executive and as a leader, you know, being intentional about [chuckles] putting it on the board and creating that space.

+ +

The thing that you have to do, though, to be mindful is you have to make sure that you don't get carried away with it. I mean, like you said, at the end of the day, succeeding in a business requires a proper balancing of short-term and long-term priorities. You know, if you're focused too much on the short term, you know, you can kind of hamstring yourself in the long run. Yeah, maybe you build, like, a decent business, but you don't quite, you know, reach your highest potential because you're not investing in some of those things that take a while to develop and come to play in the long run.

+ +

But if you're too focused on the long run, which is what these exponential opportunities really are, you know, it's very easy to lose your way [laughs] in the short term, and it's very easy to die along the way. You know, I do think of startups as much of a game of survival as anything. I always say survive until you thrive. And so, that's where the 80/20 comes in, you know, where we just kind of say, "Hey, look, like, 80% of our time and energy needs to be devoted to kind of short-term and less risky priorities, such as doubling down on what's already working. 20% of our time, thereabouts, can be devoted to some of these more long-term strategic objectives, like unlocking exponential growth.

+ +

And I think it just takes a certain mindfulness and a certain intentionality to, like, every week when you're organizing your calendar, and you're, like, talking with your team and stuff like that, you're just always trying to make sure, hey, am I roughly fitting into that framework, you know? And it doesn't have to be exact. Some weeks, it may be more or less. But I think that's kind of how we approach it, you know, conceptually.

+ +

VICTORIA: Oh, what a great perspective. I think that I really like hearing those words about, like, balance and, like, being intentional.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: You mentioned earlier that you're getting married, so, like, maybe you can talk about how are you intentional with your own time and balancing your personal life and making room for these, you know, big life changes while dealing with also the stress of being in kind of a survivor mode with the company.

+ +

STEVEN: Like I mentioned, this is my second company, and Emily, bless her heart, my fiancé, she's been with me my entire entrepreneurial career. We started dating the first month that I started my first company, FantasyHub. And in that company, I ran that company for three years. We took it through Techstars down in Austin. It was a consumer gaming company. Interesting company. It ended up being a failure but, like, super interesting and set me on my path. Yeah, I was a complete and total workaholic. I worked around the clock. It was a fantasy sports company, so weekends were our big time, and I worked seven days a week. I worked, like, a lot of 80-hour-plus weeks.

+ +

And, you know, looking back on it, it was a lot of fun, but it was also miserable. And I also burned out, you know, about six months before the company failed. And had the company not failed when it did, you know, I don't know what the future would have held for us. I was really out of balance. You know, I had deprioritized physical health. I hadn't worked out in years. I wasn't healthy. I had deprioritized mental health. Emily almost left me as a part of that company because I wasn't giving her any attention.

+ +

And so, you know, when that company failed, and I was left with nothing, you know, and I just was kind of, like, sitting there licking my wounds [laughs], you know, in my childhood bedroom at my parents' house, you know, I was like, you know what? Like, I don't know that that was really worth it, and I don't know that that was the right approach. And I kind of vowed...in that moment, I was like, you know, look, I'm a startup founder. I love building these companies, so I'm, like, definitely going to do it again, but I'm not going to give it my entire life.

+ +

Like, regardless of your religious beliefs, like, we at least have one life to live. And in my opinion, there's a lot more to life than [chuckles] just cranking out work and building companies. Like, there's a whole world to explore, you know, and there's lots of things that I'm interested in. So, this time around, I'm very thoughtful about creating that balance in my life.

+ +

I set hard guidelines. There's hard, like, guardrails, I guess I should say, when I start and end work, you know, and I really hold myself accountable to that. Emily holds me accountable to that. And I make sure that, like, I work really hard when I'm at work, but I take the mask off, you know, so to speak, when I'm at home. And I just kind of...I don't deprioritize the rest of my life like I did when I was running FantasyHub. So, I think it's super important.

+ +

I think it's a marathon building companies. I think you got to do that. I think it's what's in the best interest of the company and you as an individual. So, I think it's something I do a lot better this time around. And I think we're all better off for it, not the least of which is, like, one of our six cultural values is live with balance, and that's why.

+ +

You know, because, like, we adopt the philosophy that you don't have to work yourself to death to build a great company. You can build a great company working a pretty reasonable workload, you know what I mean? It's not easy. It is kind of a pressure cooker trying to get that much done in that little time, but I think we're living proof that it works.

+ +

VICTORIA: And if you don't make time to rest, then your ability to make good decisions and build high-quality products really starts to suffer eventually, like, I think, is what you saw at the end there. So, I really appreciate you sharing that and that personal experience. And I'm glad to see the learning from that, and making sure that's a core part of your company values the next time you start a company makes a lot of sense to me.

+ +

STEVEN: Yeah, totally, you know, yeah. And I've always remembered, although this might be an extreme and a privileged extreme, but, you know, J.P. Morgan, the person, was famous for saying, "I get more done in 9 months than I get in 12," in relationship to the fact that he would take his family over to Europe for, like, three months of the year and, like, summer in Europe and not work. And so, while that's probably an unrealistic, you know, ideal for a startup founder, there's some truth to it, you know what I mean? Like you said, like, you got to rest.

+ +

And, in fact, if you rest more, you know, yeah, you might be working less hours. You'll actually get more done. You're a lot clearer while you're at work. It's a mindset game. It's a headspace game. And the better you can put yourself in that good mindset, that good headspace, the more effective you are. Yeah, there's just a lot of wisdom to that approach.

+ +

VICTORIA: Right. And, you know, thoughtbot is a global company, so we have employees all over the world. And I think what's interesting about U.S-based companies, I'm interested in how Forecastr might even help you with this, is that when you start a company, you basically form, like, a mini-government for your employees.

+ +

And you have input over to how much they paid, how much healthcare they get. You have input over their hours and how much leave and everything. And so, trying to balance all those costs and create a good environment for your employees and make sure they have enough time for rest and for personal care. How does Forecastr kind of help you also imagine all of those costs [laughs] and make sense of what you can offer as a company?

+ +

STEVEN: I would say the main way that we help folks do that, and we really do play in that space, is just by giving you a clear picture of what the future holds for your company from a financial perspective. I mean, it's one of the things that I think is such a superpower when it comes to financial modeling, you know, it can really help you make better decisions along these lines because, like, what does a financial model do?

+ +

A financial model just simulates your business into the future, specifically anything related to the cash flow of your business, you know, cash in, cash out, revenue expenses, and the like. And so, your people are in there, and what they're paid is in there and, you know, your revenue and your expenses, your cash flow, your runway, all that's in the model.

+ +

One of the things I feel like we do really help people do is just get a clearer picture of like, hey, what do the next 3, 6, 12, you know, 24 months look like for my company? What is my runway? When am I going to run out of money? What do I need to do about that? Can I afford to give everybody a raise, or can I afford to max out my benefits plan or whatever that is? It's like, you can make those assessments more easily.

+ +

You know, if you have a financial model that actually makes sense to you that you can look at and say, oh, okay, cool. Yeah, I can offer that, like, Rolls Royce benefits plan and still have 18 months' worth of runway, or maybe I can't [laughs]. And I have to say, "Sorry, guys, you know, like, we're cash-constrained, and this is all we can do for now. But maybe when we raise that next round and when we hit these growth milestones, you know, we can expand that."

+ +

So yeah, I think it's all, for us, about just, like, helping founders make better decisions, whether they be your decisions around employees and benefits, et cetera, or growth, or fundraising, you know, through the power of, like, financial health and hygiene.

+ +

VICTORIA: Great. Thank you. I appreciate you letting me bring it all the way back [laughs]. Yeah, let me see. Let me go through my list of questions and see what else we have here. Do you have any questions for me or thoughtbot?

+ +

STEVEN: Yeah. I mean, so, like, how do you guys think about this kind of stuff? Like, you know, you said thoughtbot's a global company at this point, but the name would imply, you know, a very thoughtful one. So, I'd be curious in y'alls kind of approach to just, like, culture and balance and some of these things that we're talking about kind of, like, straddling that line, you know, between, like, working really hard, which you have to do to build a great company but, you know, being mindful of everything else that life has to offer.

+ +

VICTORIA: Yeah. Well, I think thoughtbot, more than any other company I've ever worked for, really emphasizes the value of just, like, people really want you to have a work-life balance and to be able to take time off. And, you know, I think that for a company that does consulting and we're delivering at a certain quality, that means that we're delivering at the quality where if someone needs to take a week off for a vacation, there's enough documentation; there's enough backup support for that service to not be impacted. So, that gives us confidence to be able to take the time off [chuckles], and it also just ends up being a better product for our clients.

+ +

Like, our team needs to be well-rested. They need to have time to invest in themselves and learning the latest technology, the latest upgrades, contributing to open source, and writing about the problems they're seeing, and contributing back to the community. So, we actually make time every Friday to spend on those types of projects. It's kind of like you were saying before, like, you get as much done in four days as many companies get in five because that time is very highly focused. And then you're getting the benefit of, you know, continually investing in new skills and making sure the people you're working with are at the level that you're paying for [laughs].

+ +

STEVEN: Yeah, right. No, that's super cool. That's super cool.

+ +

VICTORIA: Yeah, and, actually, so we're all remote. We're a fully remote company, and we do offer some in-person events twice a year, so that's been a lot of fun for me. And also, getting to, like, go to conferences like RubyConf and RailsConf and meeting the community has been fantastic. Yeah, you have a lot of value of self-management. So, you have the ability to really adjust your schedule and communicate and work with what meets your needs. It's been really great.

+ +

STEVEN: Yeah, I love that, too. And we're also a remote company, and I think getting together in person, like you just talked about it, is so important. We can only afford to do it once a year right now as an earlier-stage company. But as amazing as, you know, Zoom and things like this are, it's like, there's not really a perfect replacement for that in-person experience, you know.

+ +

VICTORIA: I agree, and I also agree that, like, once a year is probably enough [laughter]. That's a great amount of time. Like, it really does help because there are so many ways to build relationships remotely, but sometimes, at least just meeting in person once is enough to be like, oh yeah, like, you build a stronger connection, and I think that's great.

+ +

Okay. Let me see. What other questions do we have? Final question: is there anything else that you would like to promote?

+ +

STEVEN: I guess it's my job to say we are a really awesome financial modeling platform and team in general. So, if you are a startup founder or you know a startup founder out there that just could use some help with their financial model, you know, it is definitely something that we'd love to do. And we do a ton of education and a ton of help. We've got a ton of resources that are even freely available as well. So, our role in the market is just to get out there and help folks build great financial models, whether that be on Forecastr or otherwise, and that's kind of the approach that we take to it.

+ +

And our philosophy is like, if we can get out there and do that, you know, if we can be kind of the go-to resource for folks to build great models regardless, you know, of what that means for them, a rising tide will float all boats, and our boat the most of which, hopefully. So [laughs], if you need a model, I'm your guy.

+ +

VICTORIA: Thank you so much for sharing that. And I have a fun question for you at the end. What is your favorite hike that you've been on in the last three years or ever, however long you want to go back? [laughs]

+ +

STEVEN: Well, I would say, you know, I did have the great pleasure this year of returning to the Appalachian Trail to hike the Roan Highlands with a friend of mine who was doing a thru-hike. So, a friend of mine did a southbound thru-hike on the A.T. this year, went from Maine to Georgia. Good friend of mine. And I had not been on the Appalachian Trail since I did a thru-hike in 2017. So, I had not returned to the trail or to that whole community. It's just a very special community. It really is a group of, like, really awesome, eclectic people.

+ +

And so, yeah, this last year, I got to go down to the Roan Highlands in Tennessee. It's a beautiful, beautiful area of Tennessee and in the Southeast, rolling hills and that kind of thing. And hike, for him, for, like, three or four days and just be a part of his journey. Had a ton of fun, met some awesome people, you know, great nature, and totally destroyed my body because I was not prepared to return to the grueling nature of the Appalachian Trail. So yeah, I'd have to say that one, Victoria. I'd have to say that was my favorite in the last couple of years for sure.

+ +

VICTORIA: Yeah, it's beautiful there. I've hiked certain parts of it. So, I've heard that obviously the Appalachian Trail, which is the eastern side of the United States, was the earlier trail that was developed because of the dislocation of people over time and that they would create the trail by getting to a peak and then looking to another peak and being like, "Okay, that's where I'm going to go." So, when you say it's grueling, I was, like, a lot of up and down hills.

+ +

And then what I've heard is that the Pacific Trail on the western part of the United States, they did more of figuring out how to get from place to place with minimizing the elevation change, and so it's a much more, like, sustainable hike. Have you ever heard that?

+ +

STEVEN: Oh yeah, that is 100% true. In terms of, like, the absolute change in elevation, not, like, the highest elevation and the lowest, just, like, the change up and down, there's twice as much going up and down on the A.T. as there is on the Pacific Crest Trail. And the Pacific Crest Trail is graded for park animals, so it never gets steeper than, like, a 15% grade.

+ +

So, it's real groovy, you know, on the PCT where you can just get into a groove, and you can just hike and hike and hike and hike for hours, you know, versus the A.T. where you're going straight up, straight down, straight up, straight down, a lot of big movements, very exhausting. I've hiked a good chunk of the PCT and then, obviously, the whole A.T., so I can attest, yes, that is absolutely true.

+ +

VICTORIA: I feel like there's an analogy behind that and what Forecastr does for you. Like, you'll be able [laughs] to, like, smooth out your hills a little bit more [laughs] with your finances, yeah.

+ +

STEVEN: [laughs] Oh, I love that. Absolutely. Well, and I've honestly, like, I've often likened, you know, building a company and hiking the Appalachian Trail because it is one of those things where one of the most clarifying things about hiking a long trail is you just have this one monster goal that's, you know, that's months and months ahead of you. But you just got to get up every day, and you just got to grind it out. And every day is grindy, and it's hard, you know, but every day you just get one step closer to this goal.

+ +

And it's one of the cool things about a trail is that you kind of steep yourself in that one goal, you know, one-track mind. And, you know, like we were saying earlier, there's so much more to life. So, you can't and probably shouldn't do that with your startup. You should continue to invest in other aspects of your life. But maybe while you're within the four walls of your office or when you open up that laptop and get to work on your computer, you know, if you take that kind of similar approach where you got this big goal that's, you know, months or years away but every day you just got to grind it out; you just got to work hard; you got to do what you can to get 1 step closer. And, you know, one day you'll wake up and you'll be like, oh shit, like, I'm [laughs] pretty close, you know what I mean? Yeah, I think there's definitely some similarities to the two experiences.

+ +

VICTORIA: I appreciate that, yeah. And my team is actually it's more like starting up a business within thoughtbot. So, I'm putting together, like, my three-year plan. It's very exciting. And I think, like, those are the types of things you want to have. It's the high-level goal. Where are we going? [chuckles] Are we on our track to get there? But then day to day, it's like, okay, like, let's get these little actions done that we need to do this week [laughs] to build towards that ultimate goal.

+ +

Well, thank you so much for joining us today, Steven. I really enjoyed our conversation. Is there anything final you want to say?

+ +

STEVEN: I just want to thank you, Victoria. I think it's a wonderful podcast that you guys put on, and I really appreciate the opportunity to be here and to chat with you. You're lovely to talk to. I enjoyed the conversation as well, and I hope everyone out there did, also. So, let's make it a great 2024.

+ +

VICTORIA: Thank you so much. Yeah, this is actually my second podcast recording of the year, so very exciting for me. I appreciate it. Thanks so much for joining again.

+ +

So, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg.

+ +

And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido sits down with Steven Plappert, CEO of Forecastr, an online software designed to aid founders in financial modeling, which was born to help non-finance savvy founders understand and communicate their company's financial health. Despite the pandemic beginning right after Forecastr's launch in 2020, the company didn't pivot significantly thanks to extensive preparation and customer discovery before the launch.

+ +

Steven delves into the operational and strategic aspects of Forecastr, highlighting the importance of balancing growth with financial sustainability, a consistent theme in their business strategy. Forecastr's significant development was integrating a strong human element into their software service, a move very well-received by their customers. Steven also outlines the company's key objectives, including cultivating a solid culture, achieving profitability, and exploring opportunities for exponential growth.

+ +

Additionally, Steven discusses the importance of work-life balance, reflecting on his previous startup experience and emphasizing the necessity of balance for longevity and effectiveness in entrepreneurship. Victoria and Steven further explore how companies, including Forecastr and thoughtbot, incorporate these philosophies into their operations and culture.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant R¬obots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Steven Plappert, CEO of Forecastr, an online software that helps founders who hate building financial models in Excel actually understand their numbers, predict runway, and get funded. Steven, thank you for joining us.

+ +

STEVEN: Hey, yeah, Victoria, thanks for having me. I'm stoked to be here. What's up, guys?

+ +

VICTORIA: Just to get us warmed up here a little bit, can you tell me what's going on in your world?

+ +

STEVEN: Well, you know, what is going on in my world? I had a great year last year, very healthy. I have a loving fiancé, and I'm getting married this year, which is going to be super fun. And, obviously, running a business, which takes up more than its fair share of my life. But yeah, it's early Jan, so I've been kind of reflecting on my life, and I got a lot to be grateful for, Victoria, I really do.

+ +

VICTORIA: That's wonderful. You know, I used to work with a VP of strategic growth who likened forming partnerships with companies as getting into a marriage and building that relationship and that level of trust and communication that you have, which I think is really interesting.

+ +

STEVEN: Oh, for sure. Emily always, Emily is my fiancé, she always says that, you know, Forecastr is essentially my mistress, if you will, you know what I mean? Because, like, that's [laughs] where the rest of my time goes, isn't it? Between hanging out with her and working on the company, you know, so...

+ +

VICTORIA: So, how long have you been in a relationship with your business around Forecastr? [laughs]

+ +

STEVEN: Yeah, right? Yeah [laughs]. Four years with this one. So, you know, we started it actually January 1st of 2020, going into the pandemic, although we didn't know it at the time. And so, we just celebrated our four-year anniversary a few weeks ago.

+ +

VICTORIA: Well, that's really exciting. So, I'm curious about when you started Forecastr, what was the essential problem that you were trying to solve that you had identified in the market?

+ +

STEVEN: I'd say the main problem we were trying to solve is that, like, specifically founders, you know, startup founders, really struggle to get, like, a clear picture of their financial health or, like, just the financial aspect of their business. And then they also struggle to communicate that to investors because most founders aren't finance people. You know, like, most people that start a company they don't do it because they're excellent in even, like, business or finance or anything like that. They usually do it because, like, they've identified some problem; they've lived it; they've breathed it, you know what I mean? They're some kind of subject matter expert. They may be good at sales, or marketing, or product.

+ +

But a lot of times, finance is, like, a weak part for them, you know, it's not something that they're strong in. And so, they really have a hard time, like, understanding the viability of the business and communicating the financial outcome of the company to investors and stuff like that. And my co-founder Logan and I live that because all we did all day was built financial models in Excel for startup founders working for a CFO shop called Venture First. So, that's what we really saw.

+ +

We really saw that just, you know, it's really hard for folks to get this clear picture. And we thought a big part of that, at least, was just the fact that, you know, there's no great software for it. It was just like, people are using Excel, which, you know, for people that are great in finance, you know, works but for most people, doesn't. And so, yeah, I think that that's what kind of inspired Logan and I to fly the coop there at Venture First and start a company.

+ +

VICTORIA: No, that's really interesting. So, you found this problem. You knew that this was an issue for founders, and you built this hypothesis and started it. I think you said, like, right before 2020, right before the pandemic. So, were there any decisions you made that once you got more information or once you got started, you decided to pivot? And, like, what were those pivot points for you early on?

+ +

STEVEN: There wasn't a lot of pivoting early on, I will say. And a part of that is because, like, this isn't my first company. I started a company right out of college back in 2013 called FantasyHub. In that company, we pivoted a lot and, largely because we didn't really put a lot of forethought into that company when we launched it, you know, we didn't do any customer discovery. We just launched the company. And then we skinned our knees a bunch of times [laughs] as we scaled that company up and had to change gears a lot of times.

+ +

In Forecastr, you know, we had actually been kind of building towards starting the company for 18 months. So, Logan and I actually had the idea originally in middle of 2018. And we decided at that time, look, like, we're not going to go launch this company right away because we got full-time jobs, and we might as well de-risk it. So, we spent about 12 to 18 months just doing a lot of customer discovery, kind of in stealth mode while at Venture First.

+ +

After about six months, we brought it up to Venture First and said, "Hey, here's this idea for a company we have. We want to go do it." You know, to Venture First's credit, you know, rather than viewing that territorially and saying, "Hey, you know, there's a great new product line for our company," they really inspired us to go forward with it. They said, "Hey, this is great. We want to support you guys." They put some money in. We did some more discovery. We built a prototype.

+ +

So, long-winded way of saying that by the time we actually got to the starting line in 2020, you know, we had 18 months' worth of really clear thought put into this thing. And we had been building in this space for years, you know, building financial models and Excel for founders. So, I think we had a great understanding of the customer. We had a great understanding of the market and the needs. We'd done our diligence in terms of distribution and figuring out how we wanted to generate, you know, a good, healthy funnel for the business. And so, it was really just kind of a matter of execution at that point.

+ +

And, you know, here we are four years in, and there really hasn't been anything that we've done that's really pivoted the business that much across those four years, except for one moment, which was actually six months ago. So, in July of 2023, we did finally have our first kind of pivot moment where one of the interesting things about Forecastr versus some other solutions in the market is that we're not just a product, just a SaaS platform. There's a real strong human layer to our solution. We've always felt like a SaaS plus human model was the right model for financial modeling for startups because a lot of these startup founders don't have finance expertise on staff or inherently.

+ +

And about six months ago, it wasn't as much of a pivot as it was a double down. You know, we really doubled down on that human element, you know, and now that human element isn't just through, like, a white glove onboarding and some email support. But we actually do give our customers an analyst in addition to the software that's with them for the lifetime of their subscription and is with them every step of the way. And so, that's the only time that we really made, like, a significant change into what we were doing. And it was just, I think, off the back of three years of saying, "Hey, like [chuckles], people really love the human element, you know, let's lean into that."

+ +

VICTORIA: I love that you saw that you couldn't solve this problem with just technology and that you planned for and grew the people element as well. And I'm curious: what other decisions did you have to make as you were growing the business, how to scale the tech side or the people side?

+ +

STEVEN: So many decisions, right? And that's why I tell people all the time, I'm like, you know, I've been a founder for 11 years now. And, in my opinion, by far, the hardest part about being a founder is that all day, every day, you have to make a bunch of decisions. And you hardly ever have enough data to, like, know, you're making the right decision. So, you got to make a bunch of judgment calls, and ultimately, these are judgment calls that could make or break your company. And it's really taxing. It's taxing on the mind. It's stressful, you know. It is not easy. So, you know, I think it's one of the really hard things about being an entrepreneur.

+ +

I would say one of the most consistent decisions that we've had to make at the highest level is decisions around kind of capital preservation, fiscal responsibility, and investing in the growth. So, categorically, it's like, on the one hand, you have a desire to build the company kind of sustainably, to get to profitability, to have a healthy working model, you know, where you have some real staying power, you know. And that line of thinking leads you to, you know, be conscientious about investments that you're making that, you know, increase the burn.

+ +

On the other hand, you have a desire to grow the company very quickly. You know, you have certain benchmarks you need to meet, you know, in order to be attractive to venture capitalists. And so, you have decisions that you want to make, you know, to invest in that growth. And so, I think that's a very consistent theme that's played out across the four years is Logan and I trying to walk that tightrope between growing 2 to 3X year over year and being really mindful of the company's burn, you know, both for equity preservation and just to build the company in a more sustainable way.

+ +

And I think as financial professionals and founders, the finance person in Logan and I a lot of times wants to be more conservative. The founder in Logan and I, a lot of times, wants to be more aggressive. And so, we kind of just, like, let those two forces kind of play themselves out. And I think it creates, like, a nice, healthy tension.

+ +

VICTORIA: That is really interesting, yeah. And sometimes you have to make a guess [chuckles] and go with it and then see the results of what happens. So, you're a financial forecasting company. What kind of, like, key results or objectives are you working towards this year with Forecastr?

+ +

STEVEN: Yeah, great question. So, we're really mindful of this kind of stuff. I'd say, you know, it's something that we really consider at a deep level is, like, you have to ultimately set objectives, which are very aligning and clarifying, you know, at an executive level, and then those should kind of filter all the way down through the organization.

+ +

Because so much, I think, of building a company is you have to kind of punch above your weight. You have to grow faster than [chuckles] the resources that you're putting into it might expect or whatever. I mean, you have limited resources, limited time, but you got to go really quickly. I think alignment is a big part of that, and that starts with setting clear objectives.

+ +

So, we actually have three very clear objectives, really four. The first one is living up to our cultural values. You know, we're a culture-first organization. We believe that, like, culture, you know, kind of eats strategy for breakfast, that age-old kind of cliché, but it's true. It's just like, I think, you know, if you build a really good culture, people are just...they're happier. They're more productive. You get more done. So, that is our number one strategic objective.

+ +

Number two is to become profitable. Like I mentioned, we want to become profitable. We want to build a sustainable company. So, by setting that objective, it kind of forces us to be conscientious about spend and only invest in areas that we think is, like, a one plus one equals three.

+ +

Our third strategic objective is reach 5 million in annual recurring revenue by the end of the year. We're at 2.4 right now. We want to at least double year over year. That's kind of, like, the minimum threshold to keep playing the venture game.

+ +

And then number four is unlock exponential growth opportunities. So, we definitely adopt the philosophy of, like, hey, we've got a model. It's working. We've got 700 customers, you know, we've got two and a half million in annual recurring revenue. So, like, 80% of our focus should be on becoming profitable and hitting $5 million in annual recurring revenue. Like, that's, like, the bread and butter there, just keep doing what's working. But 20% of our attention should be paid to, well, what could we be doing to, like, triple down on that, you know, to really start to create an exponential growth curve?

+ +

And, for us, that stuff and, like, kind of the data in investor space, like, there's a lot of interesting things that we could do, of course, as long as it's consensual, anonymized, et cetera, safe and secure, you know, with the kind of data that we have on private companies, you know, anonymously benchmarking companies against their peers, things like that. And I think there's a really big opportunity that we have to serve investors as well, you know, and to create a better investor experience when it comes to financial reporting, also something that we think can unlock exponential growth. So, those are the four objectives that we have going into this year.

+ +

VICTORIA: Well, I really appreciate that you had culture at number one, and it reminds me, you know, you said it's old adage, but it's true, and you can verify that in reports like the State of DevOps Report. The number one indicator of a high-security environment is the level of trust and culture that you have within your company, not necessarily the technology or tools that you're using. So, being a financial company, I think you're in a good position [chuckles] to have, like, you know, protect all those assets and protect your data.

+ +

And yeah, I'm curious to hear more about what you said about just unlocking, like, exponential growth. It's hard to keep both the let's keep the lights on and keep running with what we have, and make room for these bigger strategic initiatives that are really going to help us grow as a company and be more sustainable over time. So, how do you make room for both of those things in a limited team?

+ +

STEVEN: Yeah, it's a great question. And it's not easy, I would say. I mean, I think the way we make room for it probably on the frontend is just, like, being intentional about creating that space. I mean, ultimately, putting unlocking exponential growth opportunities on the strategic company roadmap, which is the document that kind of memorializes the four objectives that I just went through, that creates space inherently. It's one of four objectives on the board.

+ +

And that's not just, like, a resource that sits, you know, in a folder somewhere. We use the OKR system, you know, which is a system for setting quarterly objectives and things like that. And these strategic objectives they make it on our OKR board, which filters down into our work. So, I think a big piece of creating the space is just as an executive and as a leader, you know, being intentional about [chuckles] putting it on the board and creating that space.

+ +

The thing that you have to do, though, to be mindful is you have to make sure that you don't get carried away with it. I mean, like you said, at the end of the day, succeeding in a business requires a proper balancing of short-term and long-term priorities. You know, if you're focused too much on the short term, you know, you can kind of hamstring yourself in the long run. Yeah, maybe you build, like, a decent business, but you don't quite, you know, reach your highest potential because you're not investing in some of those things that take a while to develop and come to play in the long run.

+ +

But if you're too focused on the long run, which is what these exponential opportunities really are, you know, it's very easy to lose your way [laughs] in the short term, and it's very easy to die along the way. You know, I do think of startups as much of a game of survival as anything. I always say survive until you thrive. And so, that's where the 80/20 comes in, you know, where we just kind of say, "Hey, look, like, 80% of our time and energy needs to be devoted to kind of short-term and less risky priorities, such as doubling down on what's already working. 20% of our time, thereabouts, can be devoted to some of these more long-term strategic objectives, like unlocking exponential growth.

+ +

And I think it just takes a certain mindfulness and a certain intentionality to, like, every week when you're organizing your calendar, and you're, like, talking with your team and stuff like that, you're just always trying to make sure, hey, am I roughly fitting into that framework, you know? And it doesn't have to be exact. Some weeks, it may be more or less. But I think that's kind of how we approach it, you know, conceptually.

+ +

VICTORIA: Oh, what a great perspective. I think that I really like hearing those words about, like, balance and, like, being intentional.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: You mentioned earlier that you're getting married, so, like, maybe you can talk about how are you intentional with your own time and balancing your personal life and making room for these, you know, big life changes while dealing with also the stress of being in kind of a survivor mode with the company.

+ +

STEVEN: Like I mentioned, this is my second company, and Emily, bless her heart, my fiancé, she's been with me my entire entrepreneurial career. We started dating the first month that I started my first company, FantasyHub. And in that company, I ran that company for three years. We took it through Techstars down in Austin. It was a consumer gaming company. Interesting company. It ended up being a failure but, like, super interesting and set me on my path. Yeah, I was a complete and total workaholic. I worked around the clock. It was a fantasy sports company, so weekends were our big time, and I worked seven days a week. I worked, like, a lot of 80-hour-plus weeks.

+ +

And, you know, looking back on it, it was a lot of fun, but it was also miserable. And I also burned out, you know, about six months before the company failed. And had the company not failed when it did, you know, I don't know what the future would have held for us. I was really out of balance. You know, I had deprioritized physical health. I hadn't worked out in years. I wasn't healthy. I had deprioritized mental health. Emily almost left me as a part of that company because I wasn't giving her any attention.

+ +

And so, you know, when that company failed, and I was left with nothing, you know, and I just was kind of, like, sitting there licking my wounds [laughs], you know, in my childhood bedroom at my parents' house, you know, I was like, you know what? Like, I don't know that that was really worth it, and I don't know that that was the right approach. And I kind of vowed...in that moment, I was like, you know, look, I'm a startup founder. I love building these companies, so I'm, like, definitely going to do it again, but I'm not going to give it my entire life.

+ +

Like, regardless of your religious beliefs, like, we at least have one life to live. And in my opinion, there's a lot more to life than [chuckles] just cranking out work and building companies. Like, there's a whole world to explore, you know, and there's lots of things that I'm interested in. So, this time around, I'm very thoughtful about creating that balance in my life.

+ +

I set hard guidelines. There's hard, like, guardrails, I guess I should say, when I start and end work, you know, and I really hold myself accountable to that. Emily holds me accountable to that. And I make sure that, like, I work really hard when I'm at work, but I take the mask off, you know, so to speak, when I'm at home. And I just kind of...I don't deprioritize the rest of my life like I did when I was running FantasyHub. So, I think it's super important.

+ +

I think it's a marathon building companies. I think you got to do that. I think it's what's in the best interest of the company and you as an individual. So, I think it's something I do a lot better this time around. And I think we're all better off for it, not the least of which is, like, one of our six cultural values is live with balance, and that's why.

+ +

You know, because, like, we adopt the philosophy that you don't have to work yourself to death to build a great company. You can build a great company working a pretty reasonable workload, you know what I mean? It's not easy. It is kind of a pressure cooker trying to get that much done in that little time, but I think we're living proof that it works.

+ +

VICTORIA: And if you don't make time to rest, then your ability to make good decisions and build high-quality products really starts to suffer eventually, like, I think, is what you saw at the end there. So, I really appreciate you sharing that and that personal experience. And I'm glad to see the learning from that, and making sure that's a core part of your company values the next time you start a company makes a lot of sense to me.

+ +

STEVEN: Yeah, totally, you know, yeah. And I've always remembered, although this might be an extreme and a privileged extreme, but, you know, J.P. Morgan, the person, was famous for saying, "I get more done in 9 months than I get in 12," in relationship to the fact that he would take his family over to Europe for, like, three months of the year and, like, summer in Europe and not work. And so, while that's probably an unrealistic, you know, ideal for a startup founder, there's some truth to it, you know what I mean? Like you said, like, you got to rest.

+ +

And, in fact, if you rest more, you know, yeah, you might be working less hours. You'll actually get more done. You're a lot clearer while you're at work. It's a mindset game. It's a headspace game. And the better you can put yourself in that good mindset, that good headspace, the more effective you are. Yeah, there's just a lot of wisdom to that approach.

+ +

VICTORIA: Right. And, you know, thoughtbot is a global company, so we have employees all over the world. And I think what's interesting about U.S-based companies, I'm interested in how Forecastr might even help you with this, is that when you start a company, you basically form, like, a mini-government for your employees.

+ +

And you have input over to how much they paid, how much healthcare they get. You have input over their hours and how much leave and everything. And so, trying to balance all those costs and create a good environment for your employees and make sure they have enough time for rest and for personal care. How does Forecastr kind of help you also imagine all of those costs [laughs] and make sense of what you can offer as a company?

+ +

STEVEN: I would say the main way that we help folks do that, and we really do play in that space, is just by giving you a clear picture of what the future holds for your company from a financial perspective. I mean, it's one of the things that I think is such a superpower when it comes to financial modeling, you know, it can really help you make better decisions along these lines because, like, what does a financial model do?

+ +

A financial model just simulates your business into the future, specifically anything related to the cash flow of your business, you know, cash in, cash out, revenue expenses, and the like. And so, your people are in there, and what they're paid is in there and, you know, your revenue and your expenses, your cash flow, your runway, all that's in the model.

+ +

One of the things I feel like we do really help people do is just get a clearer picture of like, hey, what do the next 3, 6, 12, you know, 24 months look like for my company? What is my runway? When am I going to run out of money? What do I need to do about that? Can I afford to give everybody a raise, or can I afford to max out my benefits plan or whatever that is? It's like, you can make those assessments more easily.

+ +

You know, if you have a financial model that actually makes sense to you that you can look at and say, oh, okay, cool. Yeah, I can offer that, like, Rolls Royce benefits plan and still have 18 months' worth of runway, or maybe I can't [laughs]. And I have to say, "Sorry, guys, you know, like, we're cash-constrained, and this is all we can do for now. But maybe when we raise that next round and when we hit these growth milestones, you know, we can expand that."

+ +

So yeah, I think it's all, for us, about just, like, helping founders make better decisions, whether they be your decisions around employees and benefits, et cetera, or growth, or fundraising, you know, through the power of, like, financial health and hygiene.

+ +

VICTORIA: Great. Thank you. I appreciate you letting me bring it all the way back [laughs]. Yeah, let me see. Let me go through my list of questions and see what else we have here. Do you have any questions for me or thoughtbot?

+ +

STEVEN: Yeah. I mean, so, like, how do you guys think about this kind of stuff? Like, you know, you said thoughtbot's a global company at this point, but the name would imply, you know, a very thoughtful one. So, I'd be curious in y'alls kind of approach to just, like, culture and balance and some of these things that we're talking about kind of, like, straddling that line, you know, between, like, working really hard, which you have to do to build a great company but, you know, being mindful of everything else that life has to offer.

+ +

VICTORIA: Yeah. Well, I think thoughtbot, more than any other company I've ever worked for, really emphasizes the value of just, like, people really want you to have a work-life balance and to be able to take time off. And, you know, I think that for a company that does consulting and we're delivering at a certain quality, that means that we're delivering at the quality where if someone needs to take a week off for a vacation, there's enough documentation; there's enough backup support for that service to not be impacted. So, that gives us confidence to be able to take the time off [chuckles], and it also just ends up being a better product for our clients.

+ +

Like, our team needs to be well-rested. They need to have time to invest in themselves and learning the latest technology, the latest upgrades, contributing to open source, and writing about the problems they're seeing, and contributing back to the community. So, we actually make time every Friday to spend on those types of projects. It's kind of like you were saying before, like, you get as much done in four days as many companies get in five because that time is very highly focused. And then you're getting the benefit of, you know, continually investing in new skills and making sure the people you're working with are at the level that you're paying for [laughs].

+ +

STEVEN: Yeah, right. No, that's super cool. That's super cool.

+ +

VICTORIA: Yeah, and, actually, so we're all remote. We're a fully remote company, and we do offer some in-person events twice a year, so that's been a lot of fun for me. And also, getting to, like, go to conferences like RubyConf and RailsConf and meeting the community has been fantastic. Yeah, you have a lot of value of self-management. So, you have the ability to really adjust your schedule and communicate and work with what meets your needs. It's been really great.

+ +

STEVEN: Yeah, I love that, too. And we're also a remote company, and I think getting together in person, like you just talked about it, is so important. We can only afford to do it once a year right now as an earlier-stage company. But as amazing as, you know, Zoom and things like this are, it's like, there's not really a perfect replacement for that in-person experience, you know.

+ +

VICTORIA: I agree, and I also agree that, like, once a year is probably enough [laughter]. That's a great amount of time. Like, it really does help because there are so many ways to build relationships remotely, but sometimes, at least just meeting in person once is enough to be like, oh yeah, like, you build a stronger connection, and I think that's great.

+ +

Okay. Let me see. What other questions do we have? Final question: is there anything else that you would like to promote?

+ +

STEVEN: I guess it's my job to say we are a really awesome financial modeling platform and team in general. So, if you are a startup founder or you know a startup founder out there that just could use some help with their financial model, you know, it is definitely something that we'd love to do. And we do a ton of education and a ton of help. We've got a ton of resources that are even freely available as well. So, our role in the market is just to get out there and help folks build great financial models, whether that be on Forecastr or otherwise, and that's kind of the approach that we take to it.

+ +

And our philosophy is like, if we can get out there and do that, you know, if we can be kind of the go-to resource for folks to build great models regardless, you know, of what that means for them, a rising tide will float all boats, and our boat the most of which, hopefully. So [laughs], if you need a model, I'm your guy.

+ +

VICTORIA: Thank you so much for sharing that. And I have a fun question for you at the end. What is your favorite hike that you've been on in the last three years or ever, however long you want to go back? [laughs]

+ +

STEVEN: Well, I would say, you know, I did have the great pleasure this year of returning to the Appalachian Trail to hike the Roan Highlands with a friend of mine who was doing a thru-hike. So, a friend of mine did a southbound thru-hike on the A.T. this year, went from Maine to Georgia. Good friend of mine. And I had not been on the Appalachian Trail since I did a thru-hike in 2017. So, I had not returned to the trail or to that whole community. It's just a very special community. It really is a group of, like, really awesome, eclectic people.

+ +

And so, yeah, this last year, I got to go down to the Roan Highlands in Tennessee. It's a beautiful, beautiful area of Tennessee and in the Southeast, rolling hills and that kind of thing. And hike, for him, for, like, three or four days and just be a part of his journey. Had a ton of fun, met some awesome people, you know, great nature, and totally destroyed my body because I was not prepared to return to the grueling nature of the Appalachian Trail. So yeah, I'd have to say that one, Victoria. I'd have to say that was my favorite in the last couple of years for sure.

+ +

VICTORIA: Yeah, it's beautiful there. I've hiked certain parts of it. So, I've heard that obviously the Appalachian Trail, which is the eastern side of the United States, was the earlier trail that was developed because of the dislocation of people over time and that they would create the trail by getting to a peak and then looking to another peak and being like, "Okay, that's where I'm going to go." So, when you say it's grueling, I was, like, a lot of up and down hills.

+ +

And then what I've heard is that the Pacific Trail on the western part of the United States, they did more of figuring out how to get from place to place with minimizing the elevation change, and so it's a much more, like, sustainable hike. Have you ever heard that?

+ +

STEVEN: Oh yeah, that is 100% true. In terms of, like, the absolute change in elevation, not, like, the highest elevation and the lowest, just, like, the change up and down, there's twice as much going up and down on the A.T. as there is on the Pacific Crest Trail. And the Pacific Crest Trail is graded for park animals, so it never gets steeper than, like, a 15% grade.

+ +

So, it's real groovy, you know, on the PCT where you can just get into a groove, and you can just hike and hike and hike and hike for hours, you know, versus the A.T. where you're going straight up, straight down, straight up, straight down, a lot of big movements, very exhausting. I've hiked a good chunk of the PCT and then, obviously, the whole A.T., so I can attest, yes, that is absolutely true.

+ +

VICTORIA: I feel like there's an analogy behind that and what Forecastr does for you. Like, you'll be able [laughs] to, like, smooth out your hills a little bit more [laughs] with your finances, yeah.

+ +

STEVEN: [laughs] Oh, I love that. Absolutely. Well, and I've honestly, like, I've often likened, you know, building a company and hiking the Appalachian Trail because it is one of those things where one of the most clarifying things about hiking a long trail is you just have this one monster goal that's, you know, that's months and months ahead of you. But you just got to get up every day, and you just got to grind it out. And every day is grindy, and it's hard, you know, but every day you just get one step closer to this goal.

+ +

And it's one of the cool things about a trail is that you kind of steep yourself in that one goal, you know, one-track mind. And, you know, like we were saying earlier, there's so much more to life. So, you can't and probably shouldn't do that with your startup. You should continue to invest in other aspects of your life. But maybe while you're within the four walls of your office or when you open up that laptop and get to work on your computer, you know, if you take that kind of similar approach where you got this big goal that's, you know, months or years away but every day you just got to grind it out; you just got to work hard; you got to do what you can to get 1 step closer. And, you know, one day you'll wake up and you'll be like, oh shit, like, I'm [laughs] pretty close, you know what I mean? Yeah, I think there's definitely some similarities to the two experiences.

+ +

VICTORIA: I appreciate that, yeah. And my team is actually it's more like starting up a business within thoughtbot. So, I'm putting together, like, my three-year plan. It's very exciting. And I think, like, those are the types of things you want to have. It's the high-level goal. Where are we going? [chuckles] Are we on our track to get there? But then day to day, it's like, okay, like, let's get these little actions done that we need to do this week [laughs] to build towards that ultimate goal.

+ +

Well, thank you so much for joining us today, Steven. I really enjoyed our conversation. Is there anything final you want to say?

+ +

STEVEN: I just want to thank you, Victoria. I think it's a wonderful podcast that you guys put on, and I really appreciate the opportunity to be here and to chat with you. You're lovely to talk to. I enjoyed the conversation as well, and I hope everyone out there did, also. So, let's make it a great 2024.

+ +

VICTORIA: Thank you so much. Yeah, this is actually my second podcast recording of the year, so very exciting for me. I appreciate it. Thanks so much for joining again.

+ +

So, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg.

+ +

And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mu5_3GEa + + ]]> + + Victoria Guido + + + 509: Revolutionizing Learning in Web Development with Wes Bos + https://podcast.thoughtbot.com/509 + 60b69c0c-fd35-47bf-8484-5b62ccf2ebcb + Thu, 25 Jan 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Hosts Will Larry and Victoria Guido are joined by Wes Bos, a full-stack developer, course creator, and podcaster. Wes shares his web development journey, from blogging and creating a successful book on Sublime Text to developing his popular online courses and hosting the Syntax podcast. He talks about the spontaneous start of his teaching career, his approach to creating content that is both approachable and practical, and the importance of making web development accessible to all learners. + 37:48 + no + + + Hosts Will Larry and Victoria Guido are joined by Wes Bos, a full-stack developer, course creator, and podcaster. Wes shares his web development journey, from blogging and creating a successful book on Sublime Text to developing his popular online courses and hosting the Syntax podcast. He talks about the spontaneous start of his teaching career, his approach to creating content that is both approachable and practical, and the importance of making web development accessible to all learners. +Wes discusses the evolution of his career, detailing his experiences in teaching at Ladies Learning Code and HackerYou and how he transitioned into selling online courses. He emphasizes the significance of offering quality content in his free and paid courses, ensuring his teachings are relatable and helpful for real-world applications. Wes also delves into the technical aspects of managing his course platform, discussing the benefits of having complete control over his content and the challenges he faces, such as content theft and logistical issues in distributing his popular sticker packs. +The conversation shifts to the role of AI in web development, where Wes highlights its impact on coding efficiency and the need for developers to adapt to AI integration in applications. He advises beginners in web development to be wary of over-relying on AI, emphasizing the importance of understanding the fundamentals of coding. The episode concludes with Wes offering advice for content creators in the tech space, stressing the importance of sharing knowledge and its positive impact on the community. He encourages listeners to stay passionate and continuously learn in the ever-evolving field of web development. +Wes' Online Courses (https://wesbos.com/courses) +Sublime Text Power User Book (https://wesbos.com/sublime-text-book) +Syntax Podcast (https://syntax.fm/) +Ladies Learning Code (https://www.canadalearningcode.ca/) +HackerYou (Now Juno College) (https://junocollege.com/) +Follow Wes Bos on LinkedIn (https://www.linkedin.com/in/wesbos/) or X (https://twitter.com/wesbos). Visit his website: wesbos.com (https://wesbos.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giants Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with me today is Wes Bos, a Full-Stack Developer, Coursemaker, and Podcaster. Wes, thank you for joining us. +WES: Thanks for having me; stoked to be here. +VICTORIA: Can you tell me, you know, on top of all of these skills that you have, podcasting, you're making courses; you're also doing development full-time; I heard that you've also picked up a new hobby in making stickers and, like, designing merch for aligning with some of your marketing goals. +WES: Yeah. All right. So, my name is Wes Bos. I'm a full-stack developer from Canada, and I do primarily two things: I make web development training courses, and I have a podcast called Syntax in which we release three episodes a week and talk about everything related to HTML, CSS, JavaScript, Node, just web development and things that surround it. +WILL: I want to see how you started in those courses. I know a little bit about your story because I remember when I first started in development. I think it's gotten a little better, but I was the only junior at one of the first companies I started at. And I went through a bootcamp and then became a junior. And I was like, how do I develop? Like, how do I get better? And they were like, "Wes Bos, his course. +WES: [laughs] +WILL: Go to Wes Bos." [laughs] And so, I did that, and it helped me tremendously. But it's interesting. I just want to see how you started. I know some of your background with ladies who code, and I think HackerYou. So yeah, wherever you want to start, bring us into the beginning of Wes Bos. +WES: So, I've been a web developer forever, a good chunk of my life. And back in, like, the blogging days, I was doing a lot of posting blog posts and whatnot. And I had a couple of the blog posts do super well. And back in the day, it was like, you get tons of traffic, and you try to, like, seize the moment. Like, oh, there's, like, 50, 000 people on my website right now. Like, how do I, like, take advantage of that? +So, what I did was I threw up a quick, little...it was a blog post about Sublime Text, which was the hot, new editor at the time. And I threw up a little thing. I'm like, I'm writing a book about Sublime Text. And I threw up a little sign-up where people could pop their email in and hear a little bit more about it. And I got, like, 2,000 signups for that in a matter of a couple of days. And I thought like, oh, all right, well, now I got to make this thing, you know, like, I just [chuckles] I didn't have any plans to make it. +I had kind of been going around in my head, but I decided to write the book. And then as part of the book, I gave a bunch of videos, and I realized I liked the video part a lot better. And it makes a lot of sense to show people what you are doing when you're talking about code and code-related things. So, I came out with a bunch of videos for that as well. People loved the videos, and I thought, oh, let's just keep doing this. So, I made a bunch of free courses, a bunch of paid courses. +And kind of at the same time as well, I was teaching at this thing called Ladies Learning Code, which kind of transitioned into a bootcamp that I did the initial content for, which was called HackerYou. And, like, people kept giving me the same feedback into like, I'm not a traditional teacher. I'm just a web developer that has learned on his own and figured things out. And a lot of people said, like, " I really like the way that you explain things. Like, it makes so much sense the way that you explain it." +And I figured out that, at least for some people, they really like the way that I explain something, and I will continue to do that. So, that's pretty much how I got into it. It's just explaining how it works in my head, putting it onto video, and putting it out there for web developers to learn from. +WILL: Yeah. And that was one of the reasons why I think I was so successful in my career is because there's a...Just learning development is hard; let's be honest. It's just hard. And I would run into people that would honestly just talk over my head, and I was like, I have no idea what you're saying, but okay. +But your courses, it was like, oh, okay, I understand that. That makes sense. Like, I can't remember the name of it, but the React beginner course I've been to that one probably three times just because I'm like, it's making sense. And every time, I get more and more and more out of it. So, I can definitely agree that the way you teach your courses it brings it down to earth. Like, I think maybe anybody could pick it up, I would say, because it's like you're talking to them, so yeah. +WES: It's really important to me that everything is approachable. And I will often explain things, like, I'm the same as you. There's extremely smart people out there, and they'll just talk at you about all of these things. And it's just like, I have no idea what you're talking about. Those words don't make any sense to me. +And it's not that I dumb it down. It's just like, the way that it makes sense in my brain is not the same way that they're talking. So, the way that I explain it is just how it makes sense to me, and people tend to really enjoy that type of thing. And I really hope that I can make a lot of this web development stuff approachable. And sometimes it's not the, like, exact perfect explanation of how something really works, the explanation you need to understand how these pieces fit together and when you would actually use something. +That's the other part of a lot of the stuff that I teach as well is that I have this big thing on one of my course websites, which is like, no foo bar baz. Because when you're learning to code, you stumble across all these foo bar baz where people are making functions and passing the values in, and they're called meta-syntactic variables. +The whole idea is that because foo bar baz mean nothing, you're able to take it out of context and focus on what is happening, and I'm quite the opposite. Show me a real example of a bunch of dogs, or a sandwich, or a button that you can click on that fetches data. And I always try to make my examples something that is real world enough that you could understand, okay, I see where this might be used rather than something in isolation because I find that myself very frustrating. +VICTORIA: What's one of your favorite examples or, like, example scenarios that you use when you're designing a code problem to teach people? +WES: It really comes down to, like, what you're teaching, but the ongoing joke on the podcast that we have is that I always use sandwiches because a sandwich is a great metaphor for a lot of things in life. So, for example, when we talk about streaming versus buffering, and we talk about, like, you're eating the sandwich as it's coming into your house versus you're cutting it into pieces and eating it. +Or in my upcoming TypeScript course, I have a bunch of examples where there can be multiple types of food, and a sandwich can be one of them, and a pizza can be another one. And that kind of shows how to use generics, right? Like, you might have a database entry that is a food entry, but you want to further that to be a sandwich or a pizza, and not all of them are that simple, right? +Like, a lot of them are also just related to web development, which is like, here's buttons that you need to click on, and here's data that you need to fetch, and here's a database schema that needs to happen. And if that's the case, I try to, like, make it real world enough where you can say, okay, I understand that this is how it works. Now, how can I apply that to my own idea? Because often, people learning to code have their own ideas. They just want to make something to solve their own problems. +WILL: How did you learn to code? Because I don't think you did a traditional route. I remember on one of your podcasts, you said your dad was in IT, but I don't think you went to a traditional route. So, how did you learn to code? +WES: It's a really long story. But the story is that I got into computers at an early age. I got into designing T-shirts and CD art for a lot of, like, hardcore bands in the music scene when I was in high school, and that parlayed into Myspace. Myspace taught me CSS. And then I've always been, like, fairly entrepreneurial, so that I parlayed into running my own business, making websites. And I've just been at it for so long that I've sort of taught myself all the pieces that I need over the years. +I do have a degree in what's called business technology management, which is, it's a business degree but no coding or things involved. It was more, like, higher level. There was some, like, networking IP addresses, and then there was a lot more, like, business management teams, procurement, SAP, things like that, so none of the web development stuff I have learned comes from that degree. It's all self-taught. +VICTORIA: So, you found that you had the skill around explaining web development concepts, and then that led to you creating your own business and having your own, like, coursework out there and everything through your podcast. So, maybe you could share a little bit what that journey has been like. +WES: It's been a very long journey. I'm not sure which part you want to hear about, but I've been selling courses for probably about nine years. And I have sold quite a bit because I also offer about half of them for free. So, I have a bunch of free ones where people take it, and they're like, "Oh, this is amazing. I'm going to take the paid one that he has as well." And I spend a lot of time making sure that the free ones and the paid ones are the same quality. Like, it's not just some crappy 10-minute course that I'm using as a lead magnet to get you in the door. Like, they're actually pretty good. +So, it's been really fun. Like, I've built a whole course platform that sells all of my courses, and you can view them and stream them, and there's invoicing and checkouts built into it. So, like now, if somebody wants to get into selling courses, there's lots of options out there where you can sign up for some SaaS and upload your course, and you're up and running. But at the time when I had done it, there was nothing like that out there, so I had to build my own whole course platform. And I've really enjoyed working on that over the years and upgrading it, and changing it, and rewriting, and adding features to it. +VICTORIA: Yeah, that's really interesting. I like that you kept the quality the same on the free and the paid versions. That's a really interesting, I think, like, a reflection of your own values. And then, I'm curious: now that there are other hosting options out there, is there anything that would make you decide to switch to one of those platforms? Because it also sounds like you're getting a lot of enjoyment about managing the one you have yourself, and there might be some other benefits to that. +WES: Yeah, probably not. First, because they take a cut, and a lot of these course platforms are not there to promote your business. They're there to promote their own business. And it's the same thing with YouTube. When your YouTube video ends, what does YouTube recommend? They usually recommend what you think you're going to watch, which is sometimes somebody else's video, right? And not having full control over how the courses are sold and consumed, to me, can be a little bit frustrating because you can't do different ideas that you have. +So, like, one of the ideas I had early on is I was getting lots of email from people in different countries, you know, in Argentina, and in Brazil, and in India. And they say, "Hey, like, I would love to take your course, but the cost of the course is a day, a week's wages, and that's way too expensive for me." So, I implemented this thing called parity purchasing power. I didn't come up with the economic concept of it, but I was the first person to offer different prices based on the country that the user was coming from. And, A, that's a cool thing to do for people, and B, it helps sales tremendously. +And if I was using some course platform, some of the course platforms now have that in place; it's table stakes, right? But at the time, I don't think I would have done as well if I hadn't coded that in myself. So, having full control over absolutely everything is really important to me. And also, like, nobody wants a teacher who doesn't actually build stuff, you know? No one wants to learn from the guy who just, like, skimmed the docs and came up with a crappy, little example. Like, you want to learn from people who are daily writing code and building real-world applications that, like, I have to support my family on this application, you know, it's pretty important, and it's pretty real world. +WILL: Yeah, and just following you, I think...and I don't know if you would describe yourself like that, but I think you're, like, a tinkerer. Like, you just...some of the ideas you have is just like, let me just try it out and see if it works. And so, that's amazing that you're able to do that. Where does that side come from? Was it from your dad being in IT, or where did that come from? +WES: Probably. Apart from growing up and seeing my dad just fix stuff and do stuff, but I'm just a constantly curious and hungry guy. And I absolutely love dipping into different tech and not even just tech but, like, I built this whole recording studio that's soundproofed. I built the whole thing myself just because I love to learn new things and to dive deep and learn how everything works. +And I think a lot of developers very easily burn out. And I always like to say, like, my competitive advantage is not burning out. So, I'm very cognizant of that might happen at some point. And part of the cure for me is I need to be excited about this type of stuff, and I need to be using it. And being able to build new things, and dip into tech, and learn constantly is what keeps me excited and motivated about web development. +WILL: Wow. So, you say you built your office. So, you built the entire, like, from concrete up? +WES: Not concrete up. So, this was like a...I'm in a basement right now, and I put up some walls. And I talked to a bunch of sound engineers about soundproofing. So, the whole ceiling is not mechanically fastened to the actual ceiling. It's like kind of, like, a floating ceiling, which is pretty cool. And then there's soundproofing material in the walls and outside the walls, and special drywall, and all kinds of interesting stuff to make it sound as good as possible and be as quiet as possible in here because I have three kids. +WILL: [laughs] I totally understand the three kids... +WES: [laughs] +WILL: And the noise that that brings. So, that's amazing. And I think you bring up something that we don't talk about enough in development is that mental health side. Like, just trying to figure out, what do you like to do outside of your computer, away from your computer? So, that's neat that you're working on that, and that that's probably why you haven't burnt out compared to other people. But yeah, kudos to you. That's yeah, that's pretty interesting that you have hobbies outside of that. +WES: Yeah, I find that pretty important to sort of keep that balance. Otherwise, if you're doing it day in, day out, especially if you're working on the same thing...like, another benefit I have is I'm always dipping into new stuff, and that keeps it really interesting. But there's plenty of other creators out there that go too hard, and they go 24/7 on it, and then you don't hear from them for six months. And it's because they got burnt out on it, which is very scary to me that that might happen to me at some point. So, I try...I don't know if I've got it figured out, but I try to combat that as much as possible. +VICTORIA: And I'm wondering how you balance just that need to create content because it seems to me that web development is constantly changing, right? And so, content that you created a year ago, maybe you got to go back and update everything. So, how do you manage that and keep your content fresh with all the ongoing changes in web development? +WES: Yeah, unfortunately, sometimes it means you just have to deprecate content, or you say, "Hey, this is not the content you should be taking right now," because some of the courses take four or five months to record, and after a year or two, they can be out of date. So, I'll mark them as deprecated if they need to be. +But I'm just kind of always working on something new, both with my courses as well as, like, the podcast. We always just have...that's the kind of the benefit of the job as well is that, like, yeah, it changes all the time, but there's always new stuff to talk about. As somebody who makes a living explaining how new things work, it's kind of nice. +VICTORIA: That's great. You got a good pipeline of content to talk about [laughs] and to update for, so that's great. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: You know, you're creating this content for web developers, and you have this kind of global audience now. What's on the horizon for you? What are you planning for in the next couple of months or in the next five years? +WES: Yeah, next couple of months, I have a TypeScript course I've been working on for over a year now. I've been sort of cranking on it, and that will be out. And then we have a podcast that we are going to be launching a video version of pretty soon, which I'm pretty excited about. We've been kind of going pretty hard. We just hired a producer. We've been going pretty hard on, like, the social clips type of thing. So, that's coming down the pipeline as well. +And five years, I have no idea. I think I always say, like, a five-year plan is a five-year guess. You know, like, you can plan ahead for six months, a year, and have some good goals. But in web development, like, a year ago, AI, maybe a year, like, 13 months ago, the AI stuff was nothing but a murmur, right? And now, the AI stuff is a good chunk of what I talk about and what I teach. So, you just kind of got to react to it; otherwise, if you have a five-year plan, then you're not going to be able to catch these new things that pop up. +WILL: How do you pick? Because I know you said you have a TypeScript course coming out. How do you pick new topics to talk about? Because there are so many. There's testing you can talk about. There's React Native. There are so many areas you can go to. How do you pick and choose that? +WES: It's actually pretty easy because it's what I'm excited about and what I want to tell people and teach people, like, what they should be learning. So, like, every single one of my courses is tech that I myself am using and that I want to help teach other people, so it's pretty straightforward. +It's not like I have some sort of, like, stats of, like, what is the most popular framework out there, and, like, obviously, that does play into it like a Next.js course. I've used Next.js in a couple of my courses. I'll probably do another Next.js course. But that's both because I enjoy it and because it's stable enough and popular enough that people would want to buy it. I'm not going to be creating a Java course or a Rust course or something like that because I know that's popular right now, and it would probably sell well. It's just not something I know enough about, or I'm excited about. +VICTORIA: Yeah, and I'm curious to go back to your comment about AI and just ask you, how are you talking about it in your courses? What are, like, the things you think it's really important for developers to know right now about AI and web development? +WES: There's kind of, like, two parts to it. First, there's the part of, like, using AI to help you code. So, there's all these, like, coding assistants that get in your editor, and you can send them your code, and it can help you decipher it, and it can scaffold out code. Those things are really, really good. +And I know a lot of developers are hesitant about it because, like, "Who knows what kind of code it's generating? And you still have to be able to understand it. And I prefer to write it by hand." And that's a valid opinion, but, like, I don't think that that's going forward. And I think that this AI stuff is making us so much more efficient in writing code that if you're not picking it up, I think that you might be at a little bit of a disadvantage there. So, there's that [SP] hunk. +And then there's also the, like, we're going to have to start implementing this stuff into the apps that we build, and whether it's just pinging in an AI service and getting data back or creating a bunch of embeddings so you can have related, like, for a blog post or for a podcast, we want related podcasts. Or if you want to use AI to, like...group tagging on a blog is a really annoying thing. Nobody uses tags well enough. But, like, what if the tags could just be automatically generated based on the words in the post or the words that we speak on the podcast? +So, there's just, like, so many, like, new features that will make it better. Your product is going to be better for your end user. And even starting now and, like, when those features are not enabled, like, it's not, like, necessarily an AI feature, but it's like, wow, I wish this had better grouping of podcasts, or I wish that you had better tagging, or that your search is not very good because it's just a text match whereas there's a lot more depth that could be added with AI. So, integrating AI into our websites and our applications that we're building is going to become just another skill that you, as a web developer, have. +VICTORIA: No, I think that's a really interesting take on it. And I'm curious if you've also seen AI used to even, like, suggest better standards for code or certain design patterns and, like, tools that help you, like what you said, kind of get better at coding faster. +WES: That's the thing people are talking about. Like, if you're learning to code, should you use these types of things? Because, like, you can just hit Tab a couple of times, and it might look good. And it certainly can bite you. Especially if you need to be able to go back and edit that code to fix it, you need to understand how it works, so there's that part of it. But, man, does it make you faster for doing a lot of common things that you will be doing over again. It just really helps you out, so I'm a big fan of it. I have lots of complaints about it as well, but I think it's here to stay. +VICTORIA: [laughs] Yeah, it's here to stay. And I've talked to founders who are really excited about it, and maybe they weren't, you know, they don't have years and years of React development experience, but they know the functions that their app needs to do. And they're able to use coding prompts and tools to kind of create at least a minimal product of what they want to build, so it's really exciting. +WILL: I totally agree with AI because I use some, especially with the coding, and it makes it so much faster, but I do think you still have to know what you're doing. Because I think you posted on it, like, in one of the coding helpers that I use in VS Code, it still doesn't know how to close out the end of the line. You have these extra backticks or whatever. And it is like, so, as a new developer, you still have to understand your code, or that's going to drive you crazy every time that you use it [chuckles]. +WES: Yeah, that's extremely frustrating, the backticks. I've had an issue open on GitHub Copilot for about a year now. They've said they fixed it, and a couple of little situations, it's been fixed. But I would love to, like, talk to somebody about, like, the actual issue because if you give the broken code back to the AI and say, "Fix it," it fixes it. So [laughs], it knows what's wrong. I just, I don't know. Yeah, you still have to know these things. +WILL: You taught at Ladies Learning Code and then HackerYou. Did that help you overcome the imposter syndrome of teaching? I don't know if you knew how big your courses were going to become. But what did the imposter syndrome look like for you during that time, or did you even have it? +WES: To a certain point, yeah. I think everybody has imposter syndrome, and that's good. Because if you're so confident that you're so amazing and blessed at this specific thing, then your head is probably too big, and [chuckles] you probably don't know what you don't know. +But with a lot of my stuff, I'll often just ask people who know better than me. Like, that's a big part of what it is, is you can just consult experts or like, "Hey, what do you think about this?" Or "Is this the best approach?" Or "Here's my code. Do you mind running through it really quickly and see if there's anything that sticks out?" People are often, like, you can pay them, or people are often willing to help, so there's that. +And like, also, you have to just know that this is for the people who enjoy it. Like, I'm not making courses for people who are better developers than I am. I'm making courses for people who like the way that I explain specific things. +And then, like, another thing that probably really helped me is that I have, like, a 100% money back, no time limit on it. And that just makes me feel good about like, hey, like, if this is not actually good, if you do not think that this is good, or if you just don't jive with the way that I explain things, no sweat, you know, here's your money back. You keep going. And that makes me feel a lot better because it's not like I'm trying to fleece somebody for money and trick them into buying the course. Like, I feel pretty good about it, and if you feel pretty good about it, then we're both happy. +WILL: Yeah, that's amazing because I feel like there's certain things that I would love to get started, but that imposter syndrome and also, like, the opinionated developers out there, like, you know what we are talking about. But it just seems like it would be hard to start with that. So, that's why I asked that question. +WES: Yeah, I've learned that, like, a lot of these people that have these extremely harsh opinions are, A, they lack all the social skills, so there's something with them that they just don't have it. And you have to understand that that's just something that they have, and they may not be trying to be a jerk. That's just kind of the way they are. +And if people are overly opinionated, it's usually because they're, like, covering for their own insecurity of what they want, not always. But a lot of times, I feel pretty good about people telling me, "Oh, you could do it this way," or "No, why are you doing it this way?" Like, I feel pretty confident in my skillset, but I also am always willing to learn and always willing to be corrected and learn new tips and techniques because that's how you get better. +So, the people that are constantly being angry online and throwing around opinions and saying things are garbage, that's very scary for beginners because they think, oh, like, am I learning the wrong thing? I don't want to waste my time here. Like, am I going to lose my job if I don't learn it? And the reality is it's not that cut and dry, you know, it's a lot more easygoing. So, I try to convey that as well. And I don't put too much into these silly people who get really angry at semicolons or something silly like that. +WILL: That's good advice. That's good advice. Because I think there's been some stuff that I want to do, that's held me back. So, that's really good advice. I appreciate it. +WES: Yeah, just do it, like, you never know. Like, if someone's calling you out for putting yourself out there, like, that's a really big jerk thing to do. And I've called people out as well. Like, I don't get it as much anymore, and that probably has to do something with the fact that I've sort of established myself. But several times in the early days, people would be, like, mean. And I would just be like, "Hey, like, just call people out, like, nicely, but, like, hey, you don't have to be mean about it. I'm just trying to share what I've learned here." And that usually gets them. +VICTORIA: Yeah. It's like, what are your intentions with providing this feedback to me right now? Like, are you trying to help? [laughs] Because it doesn't really feel that way. No, I appreciate that. And, you know, I'm also...part of thoughbot we've traditionally put out a lot of trainings, a lot of, you know, Upcase things on Ruby on Rails. And with my team, I'm looking at putting together some workshops around site reliability engineering and things that would be helpful for developers to learn how to instrument their code. +So, speaking of advice that you would give to maybe any engineer or any developer who's looking to share their expertise, or put together a course, or even a blog post about what they're learning, like, what would you advise someone who's trying to create content like that? +WES: Put it out there. When I released my Sublime textbook, keep in mind, a book about Sublime Text that's a pretty niche thing, there was already two books out there on that exact topic. And a couple of times, I was like, is anyone going to want this? There's already one of them out there. Should I even write this blog post? There's 70 out there. And just keep in mind that, like, the way that you explain it or the specific issue that you hit or whatever, it might be the way that really clicks for somebody else. +So, I always tell people just put it out there. You never know what is going to come of it. It's likely going to be a net positive for the web development world in general. So, don't ever feel that you shouldn't put yourself out there because you might not know absolutely everything about it. Just share what you know. That's how we get better. +VICTORIA: Yeah, I had a friend many years ago who we used to organize Women Who Code, and she said, "Do you think anyone would really be interested in, like, a cloud series of these topics?" And we're like, "Oh, maybe not." In the first event we had around Cloud for Women Who Code, I think, like, 30 people showed up. So yeah, put it out there, see who's interested, and go from there. That's great advice. +WES: Yeah. On the same topic, is like, 'Will somebody want this?' is a huge question. People always come to me and they say, "Hey, do you think if I make a course on X, Y, and Z, will people buy it?" Or they'll put out a tweet that says, "Hey, would you buy this, or would you attend this?" And everybody's always like, "Yes, yes, yes," just trying to be supportive. But at the end of the day, you have to test these things by actually putting things out there. +So, for me, how did I know the first thing I wanted to do was Sublime Text? It's because I put out blog posts on probably 20 different topics, and those were the posts that just hit really well, and they really resonated with people. So, like, if you're trying to understand, like, will it work? You can test those things very easily by putting a YouTube video up, putting a couple of TikToks up, write a blog post, put a couple of tweets up. And, eventually, when you put out enough content, you're going to start to see a trend in a specific area, and that will give you a little bit of guidance as to what it is you should pursue. +WILL: That's great advice. Have you had any hurdles through your journey of online courses and the podcast, releasing podcasts? +WES: I feel like I'm always, like, course-correcting. I've never had, like, a flop. And, like, I've had courses I've shelved. Early on, after Sublime Text, I was like, I'm going to do a gulp course, which was, like, a build tool for JavaScript. And then webpack started to get a little bit more popular, and I was like, okay, well, maybe I'll just make a tooling course in general, but I was like, ah, that's kind of way too big. And after, like, working on it for a couple of weeks, I was like, you know what? Like, I'm going to scrap this because I don't think that this is it, you know? +So, just kind of always listening, always feedback, and course correcting is probably my biggest advice there for the hurdles. There's stuff that comes up, like people stealing the courses. And, like, I had early access to one of my courses once, and somebody bought it with a stolen credit card and then put it up online. And, like, that's incredibly deflating because now there's your unfinished course out there before people could even buy it. And people will spam you and run DDoS attacks on you and lots of stuff like that, where people are just...they see that. And that's always really frustrating, but you kind of roll with the punches and kind of keep working on it. +WILL: Wow. That's interesting. So, someone bought the course with a stolen credit card, and they released it early to the public? +WES: Yeah. I don't know if I should say this or not, but there's a very large Russian website that is...literally, they have a paid membership, and the whole point is that you pay for the membership, and you get access to every course ever. Sometimes, they use paid cards, and sometimes it's stolen cards. +WILL: Oh, wow. +WES: They just buy every course by every creator, and they put it up on this thing. And you can get it for free for the first, like, three months, and then it goes under their paid thing. And that stuff was really frustrating to me at first, but I've learned just to...the web development community is incredibly supportive, and I have nothing to complain about, really. People who do want to support you will support you. +WILL: That's neat. That's really neat. +VICTORIA: Yeah. And speaking of the web development community, are there events or conferences you go to or different, like, places where you really connect to the web development community? +WES: Yeah. Conferences are fantastic. I really enjoy that those are back. So, React Miami is coming up. It's going to be a really fun one. But I go to a couple of conferences a year, and I usually speak at them. We also do meetups every now and then with Syntax where we'll rent out a bar and get a bunch of merch and stickers and just kind of chit-chat with everybody. That's honestly, my favorite is just going to a meetup where there's no talks or anything. It's just a bunch of interesting people in a room, and you get to talk with all kinds of cool people. +VICTORIA: That's fun, yeah. I've been organizing a monthly CTO lunch down here in San Diego, and it's like, we just get together and have lunch and, like, talk about different stuff [laughs]. +WES: Love it. +VICTORIA: And it's really great. I used to organize those meetups with, like, two speakers, and then there was pizza and drinks and all that stuff to coordinate. And it's a lot easier just to kind of get everyone together and talk, which is what most people want anyways [laughs]. +WES: I'm always bummed when you go to a conference and the, like, after party has, like, a band or, like, music is bumping. It's like, I just want a quiet room with some drinks that I can talk to people and have a good conversation, you know. +VICTORIA: Yeah, I go to a lot of events, a lot of conferences, a lot of events. I see a lot of different types of stickers and design and anything like that. So, I thought it might be fun to ask you about that. Like, you know, I don't know if you can share us a link of what your stickers look like. Or how do you make it fun and interesting for you to have that kind of thing to hand out? +WES: Once a year, once a year and a half, I make these sticker packs, and they have, I don't know, 15 or so stickers in it, various web development things. And it's a pretty big production because I get a lot of them done. So, the last time I sold 11,000 packages of them, and I sell them for five bucks shipped anywhere in the world. And it's, like, a huge logistical hurdle to try to make that happen because there's so much to it. +But it's really fun for me because I'm able to do something that is fun. A lot of people aren't able to go to conferences and get the stickers, and they want that. They want to feel part of a community, and everybody loves getting a pack of stickers. So, I've been doing that for probably seven years now. Just right now, I'm just doing a little bit of research into what the next pack is going to look like and some new materials that have hit the sticker world [laughs], so it's pretty fun. +The website is bos.af with, like, bos.af. That might not work anymore. I got note that the people who I registered the dot AF domain name from have lost contact with the Afghanistan domain authorities. So, it's possible I might just lose that domain name, which is a bit of a bummer because that's a really cool domain name, but that's where I sell them once a year. And, usually, they're only for sale for about a week, and then they're done selling, and I do the whole shipping thing around the world. +VICTORIA: Wow. I did not think you were going to say, "Sold 11,000" sticker packs. That's really impressive [laughs]. +WES: Yeah, it's crazy. It's almost 200,000 stickers if you think about it. +VICTORIA: That's, like, a major production. I bet when you got into web development, you didn't think you'd also have a side hustle making stickers off of it [laughs]. +WES: Yeah, it's crazy. Like, I was, like, sending them out with stamps, and it's just like, I was holding in one single hand, like, $4,000 worth of stamps. It's crazy to think. +VICTORIA: I can imagine going into the post office and being like, "I need $4,000 worth of stamps [laughs]," but that's great. +WES: The first time I just started dumping them into mail, I would cross the border because I'm in Canada, and the USPS is much cheaper. So, we would just cross the border, and then we just dumped them into mailboxes. And it was okay. But they were like, "Hey, like, next time, just, like, bring it to the post office, and, like, we have processes for this much mail." I don't mail them out of the U.S. anymore because there's some weird stuff around crossing the border. You have to do all this crazy stuff. But it's pretty crazy buying that many stamps. They usually look at you funny when you go to the store and say, "Hey, I need this many stamps." +[laughter] +VICTORIA: They're like, "Well, what are you doing?" [laughs] Well, great. I think, let's see, we're coming up at the end of our time here. So, are there any final takeaways for our listeners today? +WES: Check me out. I'm at wesbos.com; podcast is at syntax.fm if you want to give it a listen. We post three times a week. And I just encourage everyone keep learning, keep excited about web development because it's a pretty cool industry. +VICTORIA: Awesome. Thank you so much for taking time to chat with us today. I really enjoyed our conversation. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg. +WILL: And you could find me on X @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + Hosts Will Larry and Victoria Guido are joined by Wes Bos, a full-stack developer, course creator, and podcaster. Wes shares his web development journey, from blogging and creating a successful book on Sublime Text to developing his popular online courses and hosting the Syntax podcast. He talks about the spontaneous start of his teaching career, his approach to creating content that is both approachable and practical, and the importance of making web development accessible to all learners.

+ +

Wes discusses the evolution of his career, detailing his experiences in teaching at Ladies Learning Code and HackerYou and how he transitioned into selling online courses. He emphasizes the significance of offering quality content in his free and paid courses, ensuring his teachings are relatable and helpful for real-world applications. Wes also delves into the technical aspects of managing his course platform, discussing the benefits of having complete control over his content and the challenges he faces, such as content theft and logistical issues in distributing his popular sticker packs.

+ +

The conversation shifts to the role of AI in web development, where Wes highlights its impact on coding efficiency and the need for developers to adapt to AI integration in applications. He advises beginners in web development to be wary of over-relying on AI, emphasizing the importance of understanding the fundamentals of coding. The episode concludes with Wes offering advice for content creators in the tech space, stressing the importance of sharing knowledge and its positive impact on the community. He encourages listeners to stay passionate and continuously learn in the ever-evolving field of web development.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giants Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Wes Bos, a Full-Stack Developer, Coursemaker, and Podcaster. Wes, thank you for joining us.

+ +

WES: Thanks for having me; stoked to be here.

+ +

VICTORIA: Can you tell me, you know, on top of all of these skills that you have, podcasting, you're making courses; you're also doing development full-time; I heard that you've also picked up a new hobby in making stickers and, like, designing merch for aligning with some of your marketing goals.

+ +

WES: Yeah. All right. So, my name is Wes Bos. I'm a full-stack developer from Canada, and I do primarily two things: I make web development training courses, and I have a podcast called Syntax in which we release three episodes a week and talk about everything related to HTML, CSS, JavaScript, Node, just web development and things that surround it.

+ +

WILL: I want to see how you started in those courses. I know a little bit about your story because I remember when I first started in development. I think it's gotten a little better, but I was the only junior at one of the first companies I started at. And I went through a bootcamp and then became a junior. And I was like, how do I develop? Like, how do I get better? And they were like, "Wes Bos, his course.

+ +

WES: [laughs]

+ +

WILL: Go to Wes Bos." [laughs] And so, I did that, and it helped me tremendously. But it's interesting. I just want to see how you started. I know some of your background with ladies who code, and I think HackerYou. So yeah, wherever you want to start, bring us into the beginning of Wes Bos.

+ +

WES: So, I've been a web developer forever, a good chunk of my life. And back in, like, the blogging days, I was doing a lot of posting blog posts and whatnot. And I had a couple of the blog posts do super well. And back in the day, it was like, you get tons of traffic, and you try to, like, seize the moment. Like, oh, there's, like, 50, 000 people on my website right now. Like, how do I, like, take advantage of that?

+ +

So, what I did was I threw up a quick, little...it was a blog post about Sublime Text, which was the hot, new editor at the time. And I threw up a little thing. I'm like, I'm writing a book about Sublime Text. And I threw up a little sign-up where people could pop their email in and hear a little bit more about it. And I got, like, 2,000 signups for that in a matter of a couple of days. And I thought like, oh, all right, well, now I got to make this thing, you know, like, I just [chuckles] I didn't have any plans to make it.

+ +

I had kind of been going around in my head, but I decided to write the book. And then as part of the book, I gave a bunch of videos, and I realized I liked the video part a lot better. And it makes a lot of sense to show people what you are doing when you're talking about code and code-related things. So, I came out with a bunch of videos for that as well. People loved the videos, and I thought, oh, let's just keep doing this. So, I made a bunch of free courses, a bunch of paid courses.

+ +

And kind of at the same time as well, I was teaching at this thing called Ladies Learning Code, which kind of transitioned into a bootcamp that I did the initial content for, which was called HackerYou. And, like, people kept giving me the same feedback into like, I'm not a traditional teacher. I'm just a web developer that has learned on his own and figured things out. And a lot of people said, like, " I really like the way that you explain things. Like, it makes so much sense the way that you explain it."

+ +

And I figured out that, at least for some people, they really like the way that I explain something, and I will continue to do that. So, that's pretty much how I got into it. It's just explaining how it works in my head, putting it onto video, and putting it out there for web developers to learn from.

+ +

WILL: Yeah. And that was one of the reasons why I think I was so successful in my career is because there's a...Just learning development is hard; let's be honest. It's just hard. And I would run into people that would honestly just talk over my head, and I was like, I have no idea what you're saying, but okay.

+ +

But your courses, it was like, oh, okay, I understand that. That makes sense. Like, I can't remember the name of it, but the React beginner course I've been to that one probably three times just because I'm like, it's making sense. And every time, I get more and more and more out of it. So, I can definitely agree that the way you teach your courses it brings it down to earth. Like, I think maybe anybody could pick it up, I would say, because it's like you're talking to them, so yeah.

+ +

WES: It's really important to me that everything is approachable. And I will often explain things, like, I'm the same as you. There's extremely smart people out there, and they'll just talk at you about all of these things. And it's just like, I have no idea what you're talking about. Those words don't make any sense to me.

+ +

And it's not that I dumb it down. It's just like, the way that it makes sense in my brain is not the same way that they're talking. So, the way that I explain it is just how it makes sense to me, and people tend to really enjoy that type of thing. And I really hope that I can make a lot of this web development stuff approachable. And sometimes it's not the, like, exact perfect explanation of how something really works, the explanation you need to understand how these pieces fit together and when you would actually use something.

+ +

That's the other part of a lot of the stuff that I teach as well is that I have this big thing on one of my course websites, which is like, no foo bar baz. Because when you're learning to code, you stumble across all these foo bar baz where people are making functions and passing the values in, and they're called meta-syntactic variables.

+ +

The whole idea is that because foo bar baz mean nothing, you're able to take it out of context and focus on what is happening, and I'm quite the opposite. Show me a real example of a bunch of dogs, or a sandwich, or a button that you can click on that fetches data. And I always try to make my examples something that is real world enough that you could understand, okay, I see where this might be used rather than something in isolation because I find that myself very frustrating.

+ +

VICTORIA: What's one of your favorite examples or, like, example scenarios that you use when you're designing a code problem to teach people?

+ +

WES: It really comes down to, like, what you're teaching, but the ongoing joke on the podcast that we have is that I always use sandwiches because a sandwich is a great metaphor for a lot of things in life. So, for example, when we talk about streaming versus buffering, and we talk about, like, you're eating the sandwich as it's coming into your house versus you're cutting it into pieces and eating it.

+ +

Or in my upcoming TypeScript course, I have a bunch of examples where there can be multiple types of food, and a sandwich can be one of them, and a pizza can be another one. And that kind of shows how to use generics, right? Like, you might have a database entry that is a food entry, but you want to further that to be a sandwich or a pizza, and not all of them are that simple, right?

+ +

Like, a lot of them are also just related to web development, which is like, here's buttons that you need to click on, and here's data that you need to fetch, and here's a database schema that needs to happen. And if that's the case, I try to, like, make it real world enough where you can say, okay, I understand that this is how it works. Now, how can I apply that to my own idea? Because often, people learning to code have their own ideas. They just want to make something to solve their own problems.

+ +

WILL: How did you learn to code? Because I don't think you did a traditional route. I remember on one of your podcasts, you said your dad was in IT, but I don't think you went to a traditional route. So, how did you learn to code?

+ +

WES: It's a really long story. But the story is that I got into computers at an early age. I got into designing T-shirts and CD art for a lot of, like, hardcore bands in the music scene when I was in high school, and that parlayed into Myspace. Myspace taught me CSS. And then I've always been, like, fairly entrepreneurial, so that I parlayed into running my own business, making websites. And I've just been at it for so long that I've sort of taught myself all the pieces that I need over the years.

+ +

I do have a degree in what's called business technology management, which is, it's a business degree but no coding or things involved. It was more, like, higher level. There was some, like, networking IP addresses, and then there was a lot more, like, business management teams, procurement, SAP, things like that, so none of the web development stuff I have learned comes from that degree. It's all self-taught.

+ +

VICTORIA: So, you found that you had the skill around explaining web development concepts, and then that led to you creating your own business and having your own, like, coursework out there and everything through your podcast. So, maybe you could share a little bit what that journey has been like.

+ +

WES: It's been a very long journey. I'm not sure which part you want to hear about, but I've been selling courses for probably about nine years. And I have sold quite a bit because I also offer about half of them for free. So, I have a bunch of free ones where people take it, and they're like, "Oh, this is amazing. I'm going to take the paid one that he has as well." And I spend a lot of time making sure that the free ones and the paid ones are the same quality. Like, it's not just some crappy 10-minute course that I'm using as a lead magnet to get you in the door. Like, they're actually pretty good.

+ +

So, it's been really fun. Like, I've built a whole course platform that sells all of my courses, and you can view them and stream them, and there's invoicing and checkouts built into it. So, like now, if somebody wants to get into selling courses, there's lots of options out there where you can sign up for some SaaS and upload your course, and you're up and running. But at the time when I had done it, there was nothing like that out there, so I had to build my own whole course platform. And I've really enjoyed working on that over the years and upgrading it, and changing it, and rewriting, and adding features to it.

+ +

VICTORIA: Yeah, that's really interesting. I like that you kept the quality the same on the free and the paid versions. That's a really interesting, I think, like, a reflection of your own values. And then, I'm curious: now that there are other hosting options out there, is there anything that would make you decide to switch to one of those platforms? Because it also sounds like you're getting a lot of enjoyment about managing the one you have yourself, and there might be some other benefits to that.

+ +

WES: Yeah, probably not. First, because they take a cut, and a lot of these course platforms are not there to promote your business. They're there to promote their own business. And it's the same thing with YouTube. When your YouTube video ends, what does YouTube recommend? They usually recommend what you think you're going to watch, which is sometimes somebody else's video, right? And not having full control over how the courses are sold and consumed, to me, can be a little bit frustrating because you can't do different ideas that you have.

+ +

So, like, one of the ideas I had early on is I was getting lots of email from people in different countries, you know, in Argentina, and in Brazil, and in India. And they say, "Hey, like, I would love to take your course, but the cost of the course is a day, a week's wages, and that's way too expensive for me." So, I implemented this thing called parity purchasing power. I didn't come up with the economic concept of it, but I was the first person to offer different prices based on the country that the user was coming from. And, A, that's a cool thing to do for people, and B, it helps sales tremendously.

+ +

And if I was using some course platform, some of the course platforms now have that in place; it's table stakes, right? But at the time, I don't think I would have done as well if I hadn't coded that in myself. So, having full control over absolutely everything is really important to me. And also, like, nobody wants a teacher who doesn't actually build stuff, you know? No one wants to learn from the guy who just, like, skimmed the docs and came up with a crappy, little example. Like, you want to learn from people who are daily writing code and building real-world applications that, like, I have to support my family on this application, you know, it's pretty important, and it's pretty real world.

+ +

WILL: Yeah, and just following you, I think...and I don't know if you would describe yourself like that, but I think you're, like, a tinkerer. Like, you just...some of the ideas you have is just like, let me just try it out and see if it works. And so, that's amazing that you're able to do that. Where does that side come from? Was it from your dad being in IT, or where did that come from?

+ +

WES: Probably. Apart from growing up and seeing my dad just fix stuff and do stuff, but I'm just a constantly curious and hungry guy. And I absolutely love dipping into different tech and not even just tech but, like, I built this whole recording studio that's soundproofed. I built the whole thing myself just because I love to learn new things and to dive deep and learn how everything works.

+ +

And I think a lot of developers very easily burn out. And I always like to say, like, my competitive advantage is not burning out. So, I'm very cognizant of that might happen at some point. And part of the cure for me is I need to be excited about this type of stuff, and I need to be using it. And being able to build new things, and dip into tech, and learn constantly is what keeps me excited and motivated about web development.

+ +

WILL: Wow. So, you say you built your office. So, you built the entire, like, from concrete up?

+ +

WES: Not concrete up. So, this was like a...I'm in a basement right now, and I put up some walls. And I talked to a bunch of sound engineers about soundproofing. So, the whole ceiling is not mechanically fastened to the actual ceiling. It's like kind of, like, a floating ceiling, which is pretty cool. And then there's soundproofing material in the walls and outside the walls, and special drywall, and all kinds of interesting stuff to make it sound as good as possible and be as quiet as possible in here because I have three kids.

+ +

WILL: [laughs] I totally understand the three kids...

+ +

WES: [laughs]

+ +

WILL: And the noise that that brings. So, that's amazing. And I think you bring up something that we don't talk about enough in development is that mental health side. Like, just trying to figure out, what do you like to do outside of your computer, away from your computer? So, that's neat that you're working on that, and that that's probably why you haven't burnt out compared to other people. But yeah, kudos to you. That's yeah, that's pretty interesting that you have hobbies outside of that.

+ +

WES: Yeah, I find that pretty important to sort of keep that balance. Otherwise, if you're doing it day in, day out, especially if you're working on the same thing...like, another benefit I have is I'm always dipping into new stuff, and that keeps it really interesting. But there's plenty of other creators out there that go too hard, and they go 24/7 on it, and then you don't hear from them for six months. And it's because they got burnt out on it, which is very scary to me that that might happen to me at some point. So, I try...I don't know if I've got it figured out, but I try to combat that as much as possible.

+ +

VICTORIA: And I'm wondering how you balance just that need to create content because it seems to me that web development is constantly changing, right? And so, content that you created a year ago, maybe you got to go back and update everything. So, how do you manage that and keep your content fresh with all the ongoing changes in web development?

+ +

WES: Yeah, unfortunately, sometimes it means you just have to deprecate content, or you say, "Hey, this is not the content you should be taking right now," because some of the courses take four or five months to record, and after a year or two, they can be out of date. So, I'll mark them as deprecated if they need to be.

+ +

But I'm just kind of always working on something new, both with my courses as well as, like, the podcast. We always just have...that's the kind of the benefit of the job as well is that, like, yeah, it changes all the time, but there's always new stuff to talk about. As somebody who makes a living explaining how new things work, it's kind of nice.

+ +

VICTORIA: That's great. You got a good pipeline of content to talk about [laughs] and to update for, so that's great.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: You know, you're creating this content for web developers, and you have this kind of global audience now. What's on the horizon for you? What are you planning for in the next couple of months or in the next five years?

+ +

WES: Yeah, next couple of months, I have a TypeScript course I've been working on for over a year now. I've been sort of cranking on it, and that will be out. And then we have a podcast that we are going to be launching a video version of pretty soon, which I'm pretty excited about. We've been kind of going pretty hard. We just hired a producer. We've been going pretty hard on, like, the social clips type of thing. So, that's coming down the pipeline as well.

+ +

And five years, I have no idea. I think I always say, like, a five-year plan is a five-year guess. You know, like, you can plan ahead for six months, a year, and have some good goals. But in web development, like, a year ago, AI, maybe a year, like, 13 months ago, the AI stuff was nothing but a murmur, right? And now, the AI stuff is a good chunk of what I talk about and what I teach. So, you just kind of got to react to it; otherwise, if you have a five-year plan, then you're not going to be able to catch these new things that pop up.

+ +

WILL: How do you pick? Because I know you said you have a TypeScript course coming out. How do you pick new topics to talk about? Because there are so many. There's testing you can talk about. There's React Native. There are so many areas you can go to. How do you pick and choose that?

+ +

WES: It's actually pretty easy because it's what I'm excited about and what I want to tell people and teach people, like, what they should be learning. So, like, every single one of my courses is tech that I myself am using and that I want to help teach other people, so it's pretty straightforward.

+ +

It's not like I have some sort of, like, stats of, like, what is the most popular framework out there, and, like, obviously, that does play into it like a Next.js course. I've used Next.js in a couple of my courses. I'll probably do another Next.js course. But that's both because I enjoy it and because it's stable enough and popular enough that people would want to buy it. I'm not going to be creating a Java course or a Rust course or something like that because I know that's popular right now, and it would probably sell well. It's just not something I know enough about, or I'm excited about.

+ +

VICTORIA: Yeah, and I'm curious to go back to your comment about AI and just ask you, how are you talking about it in your courses? What are, like, the things you think it's really important for developers to know right now about AI and web development?

+ +

WES: There's kind of, like, two parts to it. First, there's the part of, like, using AI to help you code. So, there's all these, like, coding assistants that get in your editor, and you can send them your code, and it can help you decipher it, and it can scaffold out code. Those things are really, really good.

+ +

And I know a lot of developers are hesitant about it because, like, "Who knows what kind of code it's generating? And you still have to be able to understand it. And I prefer to write it by hand." And that's a valid opinion, but, like, I don't think that that's going forward. And I think that this AI stuff is making us so much more efficient in writing code that if you're not picking it up, I think that you might be at a little bit of a disadvantage there. So, there's that [SP] hunk.

+ +

And then there's also the, like, we're going to have to start implementing this stuff into the apps that we build, and whether it's just pinging in an AI service and getting data back or creating a bunch of embeddings so you can have related, like, for a blog post or for a podcast, we want related podcasts. Or if you want to use AI to, like...group tagging on a blog is a really annoying thing. Nobody uses tags well enough. But, like, what if the tags could just be automatically generated based on the words in the post or the words that we speak on the podcast?

+ +

So, there's just, like, so many, like, new features that will make it better. Your product is going to be better for your end user. And even starting now and, like, when those features are not enabled, like, it's not, like, necessarily an AI feature, but it's like, wow, I wish this had better grouping of podcasts, or I wish that you had better tagging, or that your search is not very good because it's just a text match whereas there's a lot more depth that could be added with AI. So, integrating AI into our websites and our applications that we're building is going to become just another skill that you, as a web developer, have.

+ +

VICTORIA: No, I think that's a really interesting take on it. And I'm curious if you've also seen AI used to even, like, suggest better standards for code or certain design patterns and, like, tools that help you, like what you said, kind of get better at coding faster.

+ +

WES: That's the thing people are talking about. Like, if you're learning to code, should you use these types of things? Because, like, you can just hit Tab a couple of times, and it might look good. And it certainly can bite you. Especially if you need to be able to go back and edit that code to fix it, you need to understand how it works, so there's that part of it. But, man, does it make you faster for doing a lot of common things that you will be doing over again. It just really helps you out, so I'm a big fan of it. I have lots of complaints about it as well, but I think it's here to stay.

+ +

VICTORIA: [laughs] Yeah, it's here to stay. And I've talked to founders who are really excited about it, and maybe they weren't, you know, they don't have years and years of React development experience, but they know the functions that their app needs to do. And they're able to use coding prompts and tools to kind of create at least a minimal product of what they want to build, so it's really exciting.

+ +

WILL: I totally agree with AI because I use some, especially with the coding, and it makes it so much faster, but I do think you still have to know what you're doing. Because I think you posted on it, like, in one of the coding helpers that I use in VS Code, it still doesn't know how to close out the end of the line. You have these extra backticks or whatever. And it is like, so, as a new developer, you still have to understand your code, or that's going to drive you crazy every time that you use it [chuckles].

+ +

WES: Yeah, that's extremely frustrating, the backticks. I've had an issue open on GitHub Copilot for about a year now. They've said they fixed it, and a couple of little situations, it's been fixed. But I would love to, like, talk to somebody about, like, the actual issue because if you give the broken code back to the AI and say, "Fix it," it fixes it. So [laughs], it knows what's wrong. I just, I don't know. Yeah, you still have to know these things.

+ +

WILL: You taught at Ladies Learning Code and then HackerYou. Did that help you overcome the imposter syndrome of teaching? I don't know if you knew how big your courses were going to become. But what did the imposter syndrome look like for you during that time, or did you even have it?

+ +

WES: To a certain point, yeah. I think everybody has imposter syndrome, and that's good. Because if you're so confident that you're so amazing and blessed at this specific thing, then your head is probably too big, and [chuckles] you probably don't know what you don't know.

+ +

But with a lot of my stuff, I'll often just ask people who know better than me. Like, that's a big part of what it is, is you can just consult experts or like, "Hey, what do you think about this?" Or "Is this the best approach?" Or "Here's my code. Do you mind running through it really quickly and see if there's anything that sticks out?" People are often, like, you can pay them, or people are often willing to help, so there's that.

+ +

And like, also, you have to just know that this is for the people who enjoy it. Like, I'm not making courses for people who are better developers than I am. I'm making courses for people who like the way that I explain specific things.

+ +

And then, like, another thing that probably really helped me is that I have, like, a 100% money back, no time limit on it. And that just makes me feel good about like, hey, like, if this is not actually good, if you do not think that this is good, or if you just don't jive with the way that I explain things, no sweat, you know, here's your money back. You keep going. And that makes me feel a lot better because it's not like I'm trying to fleece somebody for money and trick them into buying the course. Like, I feel pretty good about it, and if you feel pretty good about it, then we're both happy.

+ +

WILL: Yeah, that's amazing because I feel like there's certain things that I would love to get started, but that imposter syndrome and also, like, the opinionated developers out there, like, you know what we are talking about. But it just seems like it would be hard to start with that. So, that's why I asked that question.

+ +

WES: Yeah, I've learned that, like, a lot of these people that have these extremely harsh opinions are, A, they lack all the social skills, so there's something with them that they just don't have it. And you have to understand that that's just something that they have, and they may not be trying to be a jerk. That's just kind of the way they are.

+ +

And if people are overly opinionated, it's usually because they're, like, covering for their own insecurity of what they want, not always. But a lot of times, I feel pretty good about people telling me, "Oh, you could do it this way," or "No, why are you doing it this way?" Like, I feel pretty confident in my skillset, but I also am always willing to learn and always willing to be corrected and learn new tips and techniques because that's how you get better.

+ +

So, the people that are constantly being angry online and throwing around opinions and saying things are garbage, that's very scary for beginners because they think, oh, like, am I learning the wrong thing? I don't want to waste my time here. Like, am I going to lose my job if I don't learn it? And the reality is it's not that cut and dry, you know, it's a lot more easygoing. So, I try to convey that as well. And I don't put too much into these silly people who get really angry at semicolons or something silly like that.

+ +

WILL: That's good advice. That's good advice. Because I think there's been some stuff that I want to do, that's held me back. So, that's really good advice. I appreciate it.

+ +

WES: Yeah, just do it, like, you never know. Like, if someone's calling you out for putting yourself out there, like, that's a really big jerk thing to do. And I've called people out as well. Like, I don't get it as much anymore, and that probably has to do something with the fact that I've sort of established myself. But several times in the early days, people would be, like, mean. And I would just be like, "Hey, like, just call people out, like, nicely, but, like, hey, you don't have to be mean about it. I'm just trying to share what I've learned here." And that usually gets them.

+ +

VICTORIA: Yeah. It's like, what are your intentions with providing this feedback to me right now? Like, are you trying to help? [laughs] Because it doesn't really feel that way. No, I appreciate that. And, you know, I'm also...part of thoughbot we've traditionally put out a lot of trainings, a lot of, you know, Upcase things on Ruby on Rails. And with my team, I'm looking at putting together some workshops around site reliability engineering and things that would be helpful for developers to learn how to instrument their code.

+ +

So, speaking of advice that you would give to maybe any engineer or any developer who's looking to share their expertise, or put together a course, or even a blog post about what they're learning, like, what would you advise someone who's trying to create content like that?

+ +

WES: Put it out there. When I released my Sublime textbook, keep in mind, a book about Sublime Text that's a pretty niche thing, there was already two books out there on that exact topic. And a couple of times, I was like, is anyone going to want this? There's already one of them out there. Should I even write this blog post? There's 70 out there. And just keep in mind that, like, the way that you explain it or the specific issue that you hit or whatever, it might be the way that really clicks for somebody else.

+ +

So, I always tell people just put it out there. You never know what is going to come of it. It's likely going to be a net positive for the web development world in general. So, don't ever feel that you shouldn't put yourself out there because you might not know absolutely everything about it. Just share what you know. That's how we get better.

+ +

VICTORIA: Yeah, I had a friend many years ago who we used to organize Women Who Code, and she said, "Do you think anyone would really be interested in, like, a cloud series of these topics?" And we're like, "Oh, maybe not." In the first event we had around Cloud for Women Who Code, I think, like, 30 people showed up. So yeah, put it out there, see who's interested, and go from there. That's great advice.

+ +

WES: Yeah. On the same topic, is like, 'Will somebody want this?' is a huge question. People always come to me and they say, "Hey, do you think if I make a course on X, Y, and Z, will people buy it?" Or they'll put out a tweet that says, "Hey, would you buy this, or would you attend this?" And everybody's always like, "Yes, yes, yes," just trying to be supportive. But at the end of the day, you have to test these things by actually putting things out there.

+ +

So, for me, how did I know the first thing I wanted to do was Sublime Text? It's because I put out blog posts on probably 20 different topics, and those were the posts that just hit really well, and they really resonated with people. So, like, if you're trying to understand, like, will it work? You can test those things very easily by putting a YouTube video up, putting a couple of TikToks up, write a blog post, put a couple of tweets up. And, eventually, when you put out enough content, you're going to start to see a trend in a specific area, and that will give you a little bit of guidance as to what it is you should pursue.

+ +

WILL: That's great advice. Have you had any hurdles through your journey of online courses and the podcast, releasing podcasts?

+ +

WES: I feel like I'm always, like, course-correcting. I've never had, like, a flop. And, like, I've had courses I've shelved. Early on, after Sublime Text, I was like, I'm going to do a gulp course, which was, like, a build tool for JavaScript. And then webpack started to get a little bit more popular, and I was like, okay, well, maybe I'll just make a tooling course in general, but I was like, ah, that's kind of way too big. And after, like, working on it for a couple of weeks, I was like, you know what? Like, I'm going to scrap this because I don't think that this is it, you know?

+ +

So, just kind of always listening, always feedback, and course correcting is probably my biggest advice there for the hurdles. There's stuff that comes up, like people stealing the courses. And, like, I had early access to one of my courses once, and somebody bought it with a stolen credit card and then put it up online. And, like, that's incredibly deflating because now there's your unfinished course out there before people could even buy it. And people will spam you and run DDoS attacks on you and lots of stuff like that, where people are just...they see that. And that's always really frustrating, but you kind of roll with the punches and kind of keep working on it.

+ +

WILL: Wow. That's interesting. So, someone bought the course with a stolen credit card, and they released it early to the public?

+ +

WES: Yeah. I don't know if I should say this or not, but there's a very large Russian website that is...literally, they have a paid membership, and the whole point is that you pay for the membership, and you get access to every course ever. Sometimes, they use paid cards, and sometimes it's stolen cards.

+ +

WILL: Oh, wow.

+ +

WES: They just buy every course by every creator, and they put it up on this thing. And you can get it for free for the first, like, three months, and then it goes under their paid thing. And that stuff was really frustrating to me at first, but I've learned just to...the web development community is incredibly supportive, and I have nothing to complain about, really. People who do want to support you will support you.

+ +

WILL: That's neat. That's really neat.

+ +

VICTORIA: Yeah. And speaking of the web development community, are there events or conferences you go to or different, like, places where you really connect to the web development community?

+ +

WES: Yeah. Conferences are fantastic. I really enjoy that those are back. So, React Miami is coming up. It's going to be a really fun one. But I go to a couple of conferences a year, and I usually speak at them. We also do meetups every now and then with Syntax where we'll rent out a bar and get a bunch of merch and stickers and just kind of chit-chat with everybody. That's honestly, my favorite is just going to a meetup where there's no talks or anything. It's just a bunch of interesting people in a room, and you get to talk with all kinds of cool people.

+ +

VICTORIA: That's fun, yeah. I've been organizing a monthly CTO lunch down here in San Diego, and it's like, we just get together and have lunch and, like, talk about different stuff [laughs].

+ +

WES: Love it.

+ +

VICTORIA: And it's really great. I used to organize those meetups with, like, two speakers, and then there was pizza and drinks and all that stuff to coordinate. And it's a lot easier just to kind of get everyone together and talk, which is what most people want anyways [laughs].

+ +

WES: I'm always bummed when you go to a conference and the, like, after party has, like, a band or, like, music is bumping. It's like, I just want a quiet room with some drinks that I can talk to people and have a good conversation, you know.

+ +

VICTORIA: Yeah, I go to a lot of events, a lot of conferences, a lot of events. I see a lot of different types of stickers and design and anything like that. So, I thought it might be fun to ask you about that. Like, you know, I don't know if you can share us a link of what your stickers look like. Or how do you make it fun and interesting for you to have that kind of thing to hand out?

+ +

WES: Once a year, once a year and a half, I make these sticker packs, and they have, I don't know, 15 or so stickers in it, various web development things. And it's a pretty big production because I get a lot of them done. So, the last time I sold 11,000 packages of them, and I sell them for five bucks shipped anywhere in the world. And it's, like, a huge logistical hurdle to try to make that happen because there's so much to it.

+ +

But it's really fun for me because I'm able to do something that is fun. A lot of people aren't able to go to conferences and get the stickers, and they want that. They want to feel part of a community, and everybody loves getting a pack of stickers. So, I've been doing that for probably seven years now. Just right now, I'm just doing a little bit of research into what the next pack is going to look like and some new materials that have hit the sticker world [laughs], so it's pretty fun.

+ +

The website is bos.af with, like, bos.af. That might not work anymore. I got note that the people who I registered the dot AF domain name from have lost contact with the Afghanistan domain authorities. So, it's possible I might just lose that domain name, which is a bit of a bummer because that's a really cool domain name, but that's where I sell them once a year. And, usually, they're only for sale for about a week, and then they're done selling, and I do the whole shipping thing around the world.

+ +

VICTORIA: Wow. I did not think you were going to say, "Sold 11,000" sticker packs. That's really impressive [laughs].

+ +

WES: Yeah, it's crazy. It's almost 200,000 stickers if you think about it.

+ +

VICTORIA: That's, like, a major production. I bet when you got into web development, you didn't think you'd also have a side hustle making stickers off of it [laughs].

+ +

WES: Yeah, it's crazy. Like, I was, like, sending them out with stamps, and it's just like, I was holding in one single hand, like, $4,000 worth of stamps. It's crazy to think.

+ +

VICTORIA: I can imagine going into the post office and being like, "I need $4,000 worth of stamps [laughs]," but that's great.

+ +

WES: The first time I just started dumping them into mail, I would cross the border because I'm in Canada, and the USPS is much cheaper. So, we would just cross the border, and then we just dumped them into mailboxes. And it was okay. But they were like, "Hey, like, next time, just, like, bring it to the post office, and, like, we have processes for this much mail." I don't mail them out of the U.S. anymore because there's some weird stuff around crossing the border. You have to do all this crazy stuff. But it's pretty crazy buying that many stamps. They usually look at you funny when you go to the store and say, "Hey, I need this many stamps."

+ +

[laughter]

+ +

VICTORIA: They're like, "Well, what are you doing?" [laughs] Well, great. I think, let's see, we're coming up at the end of our time here. So, are there any final takeaways for our listeners today?

+ +

WES: Check me out. I'm at wesbos.com; podcast is at syntax.fm if you want to give it a listen. We post three times a week. And I just encourage everyone keep learning, keep excited about web development because it's a pretty cool industry.

+ +

VICTORIA: Awesome. Thank you so much for taking time to chat with us today. I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg.

+ +

WILL: And you could find me on X @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Victoria Guido are joined by Wes Bos, a full-stack developer, course creator, and podcaster. Wes shares his web development journey, from blogging and creating a successful book on Sublime Text to developing his popular online courses and hosting the Syntax podcast. He talks about the spontaneous start of his teaching career, his approach to creating content that is both approachable and practical, and the importance of making web development accessible to all learners.

+ +

Wes discusses the evolution of his career, detailing his experiences in teaching at Ladies Learning Code and HackerYou and how he transitioned into selling online courses. He emphasizes the significance of offering quality content in his free and paid courses, ensuring his teachings are relatable and helpful for real-world applications. Wes also delves into the technical aspects of managing his course platform, discussing the benefits of having complete control over his content and the challenges he faces, such as content theft and logistical issues in distributing his popular sticker packs.

+ +

The conversation shifts to the role of AI in web development, where Wes highlights its impact on coding efficiency and the need for developers to adapt to AI integration in applications. He advises beginners in web development to be wary of over-relying on AI, emphasizing the importance of understanding the fundamentals of coding. The episode concludes with Wes offering advice for content creators in the tech space, stressing the importance of sharing knowledge and its positive impact on the community. He encourages listeners to stay passionate and continuously learn in the ever-evolving field of web development.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giants Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Wes Bos, a Full-Stack Developer, Coursemaker, and Podcaster. Wes, thank you for joining us.

+ +

WES: Thanks for having me; stoked to be here.

+ +

VICTORIA: Can you tell me, you know, on top of all of these skills that you have, podcasting, you're making courses; you're also doing development full-time; I heard that you've also picked up a new hobby in making stickers and, like, designing merch for aligning with some of your marketing goals.

+ +

WES: Yeah. All right. So, my name is Wes Bos. I'm a full-stack developer from Canada, and I do primarily two things: I make web development training courses, and I have a podcast called Syntax in which we release three episodes a week and talk about everything related to HTML, CSS, JavaScript, Node, just web development and things that surround it.

+ +

WILL: I want to see how you started in those courses. I know a little bit about your story because I remember when I first started in development. I think it's gotten a little better, but I was the only junior at one of the first companies I started at. And I went through a bootcamp and then became a junior. And I was like, how do I develop? Like, how do I get better? And they were like, "Wes Bos, his course.

+ +

WES: [laughs]

+ +

WILL: Go to Wes Bos." [laughs] And so, I did that, and it helped me tremendously. But it's interesting. I just want to see how you started. I know some of your background with ladies who code, and I think HackerYou. So yeah, wherever you want to start, bring us into the beginning of Wes Bos.

+ +

WES: So, I've been a web developer forever, a good chunk of my life. And back in, like, the blogging days, I was doing a lot of posting blog posts and whatnot. And I had a couple of the blog posts do super well. And back in the day, it was like, you get tons of traffic, and you try to, like, seize the moment. Like, oh, there's, like, 50, 000 people on my website right now. Like, how do I, like, take advantage of that?

+ +

So, what I did was I threw up a quick, little...it was a blog post about Sublime Text, which was the hot, new editor at the time. And I threw up a little thing. I'm like, I'm writing a book about Sublime Text. And I threw up a little sign-up where people could pop their email in and hear a little bit more about it. And I got, like, 2,000 signups for that in a matter of a couple of days. And I thought like, oh, all right, well, now I got to make this thing, you know, like, I just [chuckles] I didn't have any plans to make it.

+ +

I had kind of been going around in my head, but I decided to write the book. And then as part of the book, I gave a bunch of videos, and I realized I liked the video part a lot better. And it makes a lot of sense to show people what you are doing when you're talking about code and code-related things. So, I came out with a bunch of videos for that as well. People loved the videos, and I thought, oh, let's just keep doing this. So, I made a bunch of free courses, a bunch of paid courses.

+ +

And kind of at the same time as well, I was teaching at this thing called Ladies Learning Code, which kind of transitioned into a bootcamp that I did the initial content for, which was called HackerYou. And, like, people kept giving me the same feedback into like, I'm not a traditional teacher. I'm just a web developer that has learned on his own and figured things out. And a lot of people said, like, " I really like the way that you explain things. Like, it makes so much sense the way that you explain it."

+ +

And I figured out that, at least for some people, they really like the way that I explain something, and I will continue to do that. So, that's pretty much how I got into it. It's just explaining how it works in my head, putting it onto video, and putting it out there for web developers to learn from.

+ +

WILL: Yeah. And that was one of the reasons why I think I was so successful in my career is because there's a...Just learning development is hard; let's be honest. It's just hard. And I would run into people that would honestly just talk over my head, and I was like, I have no idea what you're saying, but okay.

+ +

But your courses, it was like, oh, okay, I understand that. That makes sense. Like, I can't remember the name of it, but the React beginner course I've been to that one probably three times just because I'm like, it's making sense. And every time, I get more and more and more out of it. So, I can definitely agree that the way you teach your courses it brings it down to earth. Like, I think maybe anybody could pick it up, I would say, because it's like you're talking to them, so yeah.

+ +

WES: It's really important to me that everything is approachable. And I will often explain things, like, I'm the same as you. There's extremely smart people out there, and they'll just talk at you about all of these things. And it's just like, I have no idea what you're talking about. Those words don't make any sense to me.

+ +

And it's not that I dumb it down. It's just like, the way that it makes sense in my brain is not the same way that they're talking. So, the way that I explain it is just how it makes sense to me, and people tend to really enjoy that type of thing. And I really hope that I can make a lot of this web development stuff approachable. And sometimes it's not the, like, exact perfect explanation of how something really works, the explanation you need to understand how these pieces fit together and when you would actually use something.

+ +

That's the other part of a lot of the stuff that I teach as well is that I have this big thing on one of my course websites, which is like, no foo bar baz. Because when you're learning to code, you stumble across all these foo bar baz where people are making functions and passing the values in, and they're called meta-syntactic variables.

+ +

The whole idea is that because foo bar baz mean nothing, you're able to take it out of context and focus on what is happening, and I'm quite the opposite. Show me a real example of a bunch of dogs, or a sandwich, or a button that you can click on that fetches data. And I always try to make my examples something that is real world enough that you could understand, okay, I see where this might be used rather than something in isolation because I find that myself very frustrating.

+ +

VICTORIA: What's one of your favorite examples or, like, example scenarios that you use when you're designing a code problem to teach people?

+ +

WES: It really comes down to, like, what you're teaching, but the ongoing joke on the podcast that we have is that I always use sandwiches because a sandwich is a great metaphor for a lot of things in life. So, for example, when we talk about streaming versus buffering, and we talk about, like, you're eating the sandwich as it's coming into your house versus you're cutting it into pieces and eating it.

+ +

Or in my upcoming TypeScript course, I have a bunch of examples where there can be multiple types of food, and a sandwich can be one of them, and a pizza can be another one. And that kind of shows how to use generics, right? Like, you might have a database entry that is a food entry, but you want to further that to be a sandwich or a pizza, and not all of them are that simple, right?

+ +

Like, a lot of them are also just related to web development, which is like, here's buttons that you need to click on, and here's data that you need to fetch, and here's a database schema that needs to happen. And if that's the case, I try to, like, make it real world enough where you can say, okay, I understand that this is how it works. Now, how can I apply that to my own idea? Because often, people learning to code have their own ideas. They just want to make something to solve their own problems.

+ +

WILL: How did you learn to code? Because I don't think you did a traditional route. I remember on one of your podcasts, you said your dad was in IT, but I don't think you went to a traditional route. So, how did you learn to code?

+ +

WES: It's a really long story. But the story is that I got into computers at an early age. I got into designing T-shirts and CD art for a lot of, like, hardcore bands in the music scene when I was in high school, and that parlayed into Myspace. Myspace taught me CSS. And then I've always been, like, fairly entrepreneurial, so that I parlayed into running my own business, making websites. And I've just been at it for so long that I've sort of taught myself all the pieces that I need over the years.

+ +

I do have a degree in what's called business technology management, which is, it's a business degree but no coding or things involved. It was more, like, higher level. There was some, like, networking IP addresses, and then there was a lot more, like, business management teams, procurement, SAP, things like that, so none of the web development stuff I have learned comes from that degree. It's all self-taught.

+ +

VICTORIA: So, you found that you had the skill around explaining web development concepts, and then that led to you creating your own business and having your own, like, coursework out there and everything through your podcast. So, maybe you could share a little bit what that journey has been like.

+ +

WES: It's been a very long journey. I'm not sure which part you want to hear about, but I've been selling courses for probably about nine years. And I have sold quite a bit because I also offer about half of them for free. So, I have a bunch of free ones where people take it, and they're like, "Oh, this is amazing. I'm going to take the paid one that he has as well." And I spend a lot of time making sure that the free ones and the paid ones are the same quality. Like, it's not just some crappy 10-minute course that I'm using as a lead magnet to get you in the door. Like, they're actually pretty good.

+ +

So, it's been really fun. Like, I've built a whole course platform that sells all of my courses, and you can view them and stream them, and there's invoicing and checkouts built into it. So, like now, if somebody wants to get into selling courses, there's lots of options out there where you can sign up for some SaaS and upload your course, and you're up and running. But at the time when I had done it, there was nothing like that out there, so I had to build my own whole course platform. And I've really enjoyed working on that over the years and upgrading it, and changing it, and rewriting, and adding features to it.

+ +

VICTORIA: Yeah, that's really interesting. I like that you kept the quality the same on the free and the paid versions. That's a really interesting, I think, like, a reflection of your own values. And then, I'm curious: now that there are other hosting options out there, is there anything that would make you decide to switch to one of those platforms? Because it also sounds like you're getting a lot of enjoyment about managing the one you have yourself, and there might be some other benefits to that.

+ +

WES: Yeah, probably not. First, because they take a cut, and a lot of these course platforms are not there to promote your business. They're there to promote their own business. And it's the same thing with YouTube. When your YouTube video ends, what does YouTube recommend? They usually recommend what you think you're going to watch, which is sometimes somebody else's video, right? And not having full control over how the courses are sold and consumed, to me, can be a little bit frustrating because you can't do different ideas that you have.

+ +

So, like, one of the ideas I had early on is I was getting lots of email from people in different countries, you know, in Argentina, and in Brazil, and in India. And they say, "Hey, like, I would love to take your course, but the cost of the course is a day, a week's wages, and that's way too expensive for me." So, I implemented this thing called parity purchasing power. I didn't come up with the economic concept of it, but I was the first person to offer different prices based on the country that the user was coming from. And, A, that's a cool thing to do for people, and B, it helps sales tremendously.

+ +

And if I was using some course platform, some of the course platforms now have that in place; it's table stakes, right? But at the time, I don't think I would have done as well if I hadn't coded that in myself. So, having full control over absolutely everything is really important to me. And also, like, nobody wants a teacher who doesn't actually build stuff, you know? No one wants to learn from the guy who just, like, skimmed the docs and came up with a crappy, little example. Like, you want to learn from people who are daily writing code and building real-world applications that, like, I have to support my family on this application, you know, it's pretty important, and it's pretty real world.

+ +

WILL: Yeah, and just following you, I think...and I don't know if you would describe yourself like that, but I think you're, like, a tinkerer. Like, you just...some of the ideas you have is just like, let me just try it out and see if it works. And so, that's amazing that you're able to do that. Where does that side come from? Was it from your dad being in IT, or where did that come from?

+ +

WES: Probably. Apart from growing up and seeing my dad just fix stuff and do stuff, but I'm just a constantly curious and hungry guy. And I absolutely love dipping into different tech and not even just tech but, like, I built this whole recording studio that's soundproofed. I built the whole thing myself just because I love to learn new things and to dive deep and learn how everything works.

+ +

And I think a lot of developers very easily burn out. And I always like to say, like, my competitive advantage is not burning out. So, I'm very cognizant of that might happen at some point. And part of the cure for me is I need to be excited about this type of stuff, and I need to be using it. And being able to build new things, and dip into tech, and learn constantly is what keeps me excited and motivated about web development.

+ +

WILL: Wow. So, you say you built your office. So, you built the entire, like, from concrete up?

+ +

WES: Not concrete up. So, this was like a...I'm in a basement right now, and I put up some walls. And I talked to a bunch of sound engineers about soundproofing. So, the whole ceiling is not mechanically fastened to the actual ceiling. It's like kind of, like, a floating ceiling, which is pretty cool. And then there's soundproofing material in the walls and outside the walls, and special drywall, and all kinds of interesting stuff to make it sound as good as possible and be as quiet as possible in here because I have three kids.

+ +

WILL: [laughs] I totally understand the three kids...

+ +

WES: [laughs]

+ +

WILL: And the noise that that brings. So, that's amazing. And I think you bring up something that we don't talk about enough in development is that mental health side. Like, just trying to figure out, what do you like to do outside of your computer, away from your computer? So, that's neat that you're working on that, and that that's probably why you haven't burnt out compared to other people. But yeah, kudos to you. That's yeah, that's pretty interesting that you have hobbies outside of that.

+ +

WES: Yeah, I find that pretty important to sort of keep that balance. Otherwise, if you're doing it day in, day out, especially if you're working on the same thing...like, another benefit I have is I'm always dipping into new stuff, and that keeps it really interesting. But there's plenty of other creators out there that go too hard, and they go 24/7 on it, and then you don't hear from them for six months. And it's because they got burnt out on it, which is very scary to me that that might happen to me at some point. So, I try...I don't know if I've got it figured out, but I try to combat that as much as possible.

+ +

VICTORIA: And I'm wondering how you balance just that need to create content because it seems to me that web development is constantly changing, right? And so, content that you created a year ago, maybe you got to go back and update everything. So, how do you manage that and keep your content fresh with all the ongoing changes in web development?

+ +

WES: Yeah, unfortunately, sometimes it means you just have to deprecate content, or you say, "Hey, this is not the content you should be taking right now," because some of the courses take four or five months to record, and after a year or two, they can be out of date. So, I'll mark them as deprecated if they need to be.

+ +

But I'm just kind of always working on something new, both with my courses as well as, like, the podcast. We always just have...that's the kind of the benefit of the job as well is that, like, yeah, it changes all the time, but there's always new stuff to talk about. As somebody who makes a living explaining how new things work, it's kind of nice.

+ +

VICTORIA: That's great. You got a good pipeline of content to talk about [laughs] and to update for, so that's great.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: You know, you're creating this content for web developers, and you have this kind of global audience now. What's on the horizon for you? What are you planning for in the next couple of months or in the next five years?

+ +

WES: Yeah, next couple of months, I have a TypeScript course I've been working on for over a year now. I've been sort of cranking on it, and that will be out. And then we have a podcast that we are going to be launching a video version of pretty soon, which I'm pretty excited about. We've been kind of going pretty hard. We just hired a producer. We've been going pretty hard on, like, the social clips type of thing. So, that's coming down the pipeline as well.

+ +

And five years, I have no idea. I think I always say, like, a five-year plan is a five-year guess. You know, like, you can plan ahead for six months, a year, and have some good goals. But in web development, like, a year ago, AI, maybe a year, like, 13 months ago, the AI stuff was nothing but a murmur, right? And now, the AI stuff is a good chunk of what I talk about and what I teach. So, you just kind of got to react to it; otherwise, if you have a five-year plan, then you're not going to be able to catch these new things that pop up.

+ +

WILL: How do you pick? Because I know you said you have a TypeScript course coming out. How do you pick new topics to talk about? Because there are so many. There's testing you can talk about. There's React Native. There are so many areas you can go to. How do you pick and choose that?

+ +

WES: It's actually pretty easy because it's what I'm excited about and what I want to tell people and teach people, like, what they should be learning. So, like, every single one of my courses is tech that I myself am using and that I want to help teach other people, so it's pretty straightforward.

+ +

It's not like I have some sort of, like, stats of, like, what is the most popular framework out there, and, like, obviously, that does play into it like a Next.js course. I've used Next.js in a couple of my courses. I'll probably do another Next.js course. But that's both because I enjoy it and because it's stable enough and popular enough that people would want to buy it. I'm not going to be creating a Java course or a Rust course or something like that because I know that's popular right now, and it would probably sell well. It's just not something I know enough about, or I'm excited about.

+ +

VICTORIA: Yeah, and I'm curious to go back to your comment about AI and just ask you, how are you talking about it in your courses? What are, like, the things you think it's really important for developers to know right now about AI and web development?

+ +

WES: There's kind of, like, two parts to it. First, there's the part of, like, using AI to help you code. So, there's all these, like, coding assistants that get in your editor, and you can send them your code, and it can help you decipher it, and it can scaffold out code. Those things are really, really good.

+ +

And I know a lot of developers are hesitant about it because, like, "Who knows what kind of code it's generating? And you still have to be able to understand it. And I prefer to write it by hand." And that's a valid opinion, but, like, I don't think that that's going forward. And I think that this AI stuff is making us so much more efficient in writing code that if you're not picking it up, I think that you might be at a little bit of a disadvantage there. So, there's that [SP] hunk.

+ +

And then there's also the, like, we're going to have to start implementing this stuff into the apps that we build, and whether it's just pinging in an AI service and getting data back or creating a bunch of embeddings so you can have related, like, for a blog post or for a podcast, we want related podcasts. Or if you want to use AI to, like...group tagging on a blog is a really annoying thing. Nobody uses tags well enough. But, like, what if the tags could just be automatically generated based on the words in the post or the words that we speak on the podcast?

+ +

So, there's just, like, so many, like, new features that will make it better. Your product is going to be better for your end user. And even starting now and, like, when those features are not enabled, like, it's not, like, necessarily an AI feature, but it's like, wow, I wish this had better grouping of podcasts, or I wish that you had better tagging, or that your search is not very good because it's just a text match whereas there's a lot more depth that could be added with AI. So, integrating AI into our websites and our applications that we're building is going to become just another skill that you, as a web developer, have.

+ +

VICTORIA: No, I think that's a really interesting take on it. And I'm curious if you've also seen AI used to even, like, suggest better standards for code or certain design patterns and, like, tools that help you, like what you said, kind of get better at coding faster.

+ +

WES: That's the thing people are talking about. Like, if you're learning to code, should you use these types of things? Because, like, you can just hit Tab a couple of times, and it might look good. And it certainly can bite you. Especially if you need to be able to go back and edit that code to fix it, you need to understand how it works, so there's that part of it. But, man, does it make you faster for doing a lot of common things that you will be doing over again. It just really helps you out, so I'm a big fan of it. I have lots of complaints about it as well, but I think it's here to stay.

+ +

VICTORIA: [laughs] Yeah, it's here to stay. And I've talked to founders who are really excited about it, and maybe they weren't, you know, they don't have years and years of React development experience, but they know the functions that their app needs to do. And they're able to use coding prompts and tools to kind of create at least a minimal product of what they want to build, so it's really exciting.

+ +

WILL: I totally agree with AI because I use some, especially with the coding, and it makes it so much faster, but I do think you still have to know what you're doing. Because I think you posted on it, like, in one of the coding helpers that I use in VS Code, it still doesn't know how to close out the end of the line. You have these extra backticks or whatever. And it is like, so, as a new developer, you still have to understand your code, or that's going to drive you crazy every time that you use it [chuckles].

+ +

WES: Yeah, that's extremely frustrating, the backticks. I've had an issue open on GitHub Copilot for about a year now. They've said they fixed it, and a couple of little situations, it's been fixed. But I would love to, like, talk to somebody about, like, the actual issue because if you give the broken code back to the AI and say, "Fix it," it fixes it. So [laughs], it knows what's wrong. I just, I don't know. Yeah, you still have to know these things.

+ +

WILL: You taught at Ladies Learning Code and then HackerYou. Did that help you overcome the imposter syndrome of teaching? I don't know if you knew how big your courses were going to become. But what did the imposter syndrome look like for you during that time, or did you even have it?

+ +

WES: To a certain point, yeah. I think everybody has imposter syndrome, and that's good. Because if you're so confident that you're so amazing and blessed at this specific thing, then your head is probably too big, and [chuckles] you probably don't know what you don't know.

+ +

But with a lot of my stuff, I'll often just ask people who know better than me. Like, that's a big part of what it is, is you can just consult experts or like, "Hey, what do you think about this?" Or "Is this the best approach?" Or "Here's my code. Do you mind running through it really quickly and see if there's anything that sticks out?" People are often, like, you can pay them, or people are often willing to help, so there's that.

+ +

And like, also, you have to just know that this is for the people who enjoy it. Like, I'm not making courses for people who are better developers than I am. I'm making courses for people who like the way that I explain specific things.

+ +

And then, like, another thing that probably really helped me is that I have, like, a 100% money back, no time limit on it. And that just makes me feel good about like, hey, like, if this is not actually good, if you do not think that this is good, or if you just don't jive with the way that I explain things, no sweat, you know, here's your money back. You keep going. And that makes me feel a lot better because it's not like I'm trying to fleece somebody for money and trick them into buying the course. Like, I feel pretty good about it, and if you feel pretty good about it, then we're both happy.

+ +

WILL: Yeah, that's amazing because I feel like there's certain things that I would love to get started, but that imposter syndrome and also, like, the opinionated developers out there, like, you know what we are talking about. But it just seems like it would be hard to start with that. So, that's why I asked that question.

+ +

WES: Yeah, I've learned that, like, a lot of these people that have these extremely harsh opinions are, A, they lack all the social skills, so there's something with them that they just don't have it. And you have to understand that that's just something that they have, and they may not be trying to be a jerk. That's just kind of the way they are.

+ +

And if people are overly opinionated, it's usually because they're, like, covering for their own insecurity of what they want, not always. But a lot of times, I feel pretty good about people telling me, "Oh, you could do it this way," or "No, why are you doing it this way?" Like, I feel pretty confident in my skillset, but I also am always willing to learn and always willing to be corrected and learn new tips and techniques because that's how you get better.

+ +

So, the people that are constantly being angry online and throwing around opinions and saying things are garbage, that's very scary for beginners because they think, oh, like, am I learning the wrong thing? I don't want to waste my time here. Like, am I going to lose my job if I don't learn it? And the reality is it's not that cut and dry, you know, it's a lot more easygoing. So, I try to convey that as well. And I don't put too much into these silly people who get really angry at semicolons or something silly like that.

+ +

WILL: That's good advice. That's good advice. Because I think there's been some stuff that I want to do, that's held me back. So, that's really good advice. I appreciate it.

+ +

WES: Yeah, just do it, like, you never know. Like, if someone's calling you out for putting yourself out there, like, that's a really big jerk thing to do. And I've called people out as well. Like, I don't get it as much anymore, and that probably has to do something with the fact that I've sort of established myself. But several times in the early days, people would be, like, mean. And I would just be like, "Hey, like, just call people out, like, nicely, but, like, hey, you don't have to be mean about it. I'm just trying to share what I've learned here." And that usually gets them.

+ +

VICTORIA: Yeah. It's like, what are your intentions with providing this feedback to me right now? Like, are you trying to help? [laughs] Because it doesn't really feel that way. No, I appreciate that. And, you know, I'm also...part of thoughbot we've traditionally put out a lot of trainings, a lot of, you know, Upcase things on Ruby on Rails. And with my team, I'm looking at putting together some workshops around site reliability engineering and things that would be helpful for developers to learn how to instrument their code.

+ +

So, speaking of advice that you would give to maybe any engineer or any developer who's looking to share their expertise, or put together a course, or even a blog post about what they're learning, like, what would you advise someone who's trying to create content like that?

+ +

WES: Put it out there. When I released my Sublime textbook, keep in mind, a book about Sublime Text that's a pretty niche thing, there was already two books out there on that exact topic. And a couple of times, I was like, is anyone going to want this? There's already one of them out there. Should I even write this blog post? There's 70 out there. And just keep in mind that, like, the way that you explain it or the specific issue that you hit or whatever, it might be the way that really clicks for somebody else.

+ +

So, I always tell people just put it out there. You never know what is going to come of it. It's likely going to be a net positive for the web development world in general. So, don't ever feel that you shouldn't put yourself out there because you might not know absolutely everything about it. Just share what you know. That's how we get better.

+ +

VICTORIA: Yeah, I had a friend many years ago who we used to organize Women Who Code, and she said, "Do you think anyone would really be interested in, like, a cloud series of these topics?" And we're like, "Oh, maybe not." In the first event we had around Cloud for Women Who Code, I think, like, 30 people showed up. So yeah, put it out there, see who's interested, and go from there. That's great advice.

+ +

WES: Yeah. On the same topic, is like, 'Will somebody want this?' is a huge question. People always come to me and they say, "Hey, do you think if I make a course on X, Y, and Z, will people buy it?" Or they'll put out a tweet that says, "Hey, would you buy this, or would you attend this?" And everybody's always like, "Yes, yes, yes," just trying to be supportive. But at the end of the day, you have to test these things by actually putting things out there.

+ +

So, for me, how did I know the first thing I wanted to do was Sublime Text? It's because I put out blog posts on probably 20 different topics, and those were the posts that just hit really well, and they really resonated with people. So, like, if you're trying to understand, like, will it work? You can test those things very easily by putting a YouTube video up, putting a couple of TikToks up, write a blog post, put a couple of tweets up. And, eventually, when you put out enough content, you're going to start to see a trend in a specific area, and that will give you a little bit of guidance as to what it is you should pursue.

+ +

WILL: That's great advice. Have you had any hurdles through your journey of online courses and the podcast, releasing podcasts?

+ +

WES: I feel like I'm always, like, course-correcting. I've never had, like, a flop. And, like, I've had courses I've shelved. Early on, after Sublime Text, I was like, I'm going to do a gulp course, which was, like, a build tool for JavaScript. And then webpack started to get a little bit more popular, and I was like, okay, well, maybe I'll just make a tooling course in general, but I was like, ah, that's kind of way too big. And after, like, working on it for a couple of weeks, I was like, you know what? Like, I'm going to scrap this because I don't think that this is it, you know?

+ +

So, just kind of always listening, always feedback, and course correcting is probably my biggest advice there for the hurdles. There's stuff that comes up, like people stealing the courses. And, like, I had early access to one of my courses once, and somebody bought it with a stolen credit card and then put it up online. And, like, that's incredibly deflating because now there's your unfinished course out there before people could even buy it. And people will spam you and run DDoS attacks on you and lots of stuff like that, where people are just...they see that. And that's always really frustrating, but you kind of roll with the punches and kind of keep working on it.

+ +

WILL: Wow. That's interesting. So, someone bought the course with a stolen credit card, and they released it early to the public?

+ +

WES: Yeah. I don't know if I should say this or not, but there's a very large Russian website that is...literally, they have a paid membership, and the whole point is that you pay for the membership, and you get access to every course ever. Sometimes, they use paid cards, and sometimes it's stolen cards.

+ +

WILL: Oh, wow.

+ +

WES: They just buy every course by every creator, and they put it up on this thing. And you can get it for free for the first, like, three months, and then it goes under their paid thing. And that stuff was really frustrating to me at first, but I've learned just to...the web development community is incredibly supportive, and I have nothing to complain about, really. People who do want to support you will support you.

+ +

WILL: That's neat. That's really neat.

+ +

VICTORIA: Yeah. And speaking of the web development community, are there events or conferences you go to or different, like, places where you really connect to the web development community?

+ +

WES: Yeah. Conferences are fantastic. I really enjoy that those are back. So, React Miami is coming up. It's going to be a really fun one. But I go to a couple of conferences a year, and I usually speak at them. We also do meetups every now and then with Syntax where we'll rent out a bar and get a bunch of merch and stickers and just kind of chit-chat with everybody. That's honestly, my favorite is just going to a meetup where there's no talks or anything. It's just a bunch of interesting people in a room, and you get to talk with all kinds of cool people.

+ +

VICTORIA: That's fun, yeah. I've been organizing a monthly CTO lunch down here in San Diego, and it's like, we just get together and have lunch and, like, talk about different stuff [laughs].

+ +

WES: Love it.

+ +

VICTORIA: And it's really great. I used to organize those meetups with, like, two speakers, and then there was pizza and drinks and all that stuff to coordinate. And it's a lot easier just to kind of get everyone together and talk, which is what most people want anyways [laughs].

+ +

WES: I'm always bummed when you go to a conference and the, like, after party has, like, a band or, like, music is bumping. It's like, I just want a quiet room with some drinks that I can talk to people and have a good conversation, you know.

+ +

VICTORIA: Yeah, I go to a lot of events, a lot of conferences, a lot of events. I see a lot of different types of stickers and design and anything like that. So, I thought it might be fun to ask you about that. Like, you know, I don't know if you can share us a link of what your stickers look like. Or how do you make it fun and interesting for you to have that kind of thing to hand out?

+ +

WES: Once a year, once a year and a half, I make these sticker packs, and they have, I don't know, 15 or so stickers in it, various web development things. And it's a pretty big production because I get a lot of them done. So, the last time I sold 11,000 packages of them, and I sell them for five bucks shipped anywhere in the world. And it's, like, a huge logistical hurdle to try to make that happen because there's so much to it.

+ +

But it's really fun for me because I'm able to do something that is fun. A lot of people aren't able to go to conferences and get the stickers, and they want that. They want to feel part of a community, and everybody loves getting a pack of stickers. So, I've been doing that for probably seven years now. Just right now, I'm just doing a little bit of research into what the next pack is going to look like and some new materials that have hit the sticker world [laughs], so it's pretty fun.

+ +

The website is bos.af with, like, bos.af. That might not work anymore. I got note that the people who I registered the dot AF domain name from have lost contact with the Afghanistan domain authorities. So, it's possible I might just lose that domain name, which is a bit of a bummer because that's a really cool domain name, but that's where I sell them once a year. And, usually, they're only for sale for about a week, and then they're done selling, and I do the whole shipping thing around the world.

+ +

VICTORIA: Wow. I did not think you were going to say, "Sold 11,000" sticker packs. That's really impressive [laughs].

+ +

WES: Yeah, it's crazy. It's almost 200,000 stickers if you think about it.

+ +

VICTORIA: That's, like, a major production. I bet when you got into web development, you didn't think you'd also have a side hustle making stickers off of it [laughs].

+ +

WES: Yeah, it's crazy. Like, I was, like, sending them out with stamps, and it's just like, I was holding in one single hand, like, $4,000 worth of stamps. It's crazy to think.

+ +

VICTORIA: I can imagine going into the post office and being like, "I need $4,000 worth of stamps [laughs]," but that's great.

+ +

WES: The first time I just started dumping them into mail, I would cross the border because I'm in Canada, and the USPS is much cheaper. So, we would just cross the border, and then we just dumped them into mailboxes. And it was okay. But they were like, "Hey, like, next time, just, like, bring it to the post office, and, like, we have processes for this much mail." I don't mail them out of the U.S. anymore because there's some weird stuff around crossing the border. You have to do all this crazy stuff. But it's pretty crazy buying that many stamps. They usually look at you funny when you go to the store and say, "Hey, I need this many stamps."

+ +

[laughter]

+ +

VICTORIA: They're like, "Well, what are you doing?" [laughs] Well, great. I think, let's see, we're coming up at the end of our time here. So, are there any final takeaways for our listeners today?

+ +

WES: Check me out. I'm at wesbos.com; podcast is at syntax.fm if you want to give it a listen. We post three times a week. And I just encourage everyone keep learning, keep excited about web development because it's a pretty cool industry.

+ +

VICTORIA: Awesome. Thank you so much for taking time to chat with us today. I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on X, formerly known as Twitter, @victori_ousg.

+ +

WILL: And you could find me on X @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ubFEOoi4 + + ]]> + + Will Larry + Victoria Guido + + + thoughtbot's Incubator Program Mini Session 3: Episode 08: Goodz with Mike Rosenthal and Chris Cerrito + https://podcast.thoughtbot.com/s3e8incubatorgoodz + 80146747-4e95-4d15-9c04-d76f95b4e676 + Tue, 23 Jan 2024 00:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + Lindsey Christensen and Jordyn Bonds catch up with the co-founders of Goodz, Chris Cerrito and Mike Rosenthal, where they share insights from their journey during the Incubator program, including the usefulness of the application process in aligning their vision and the challenges and benefits of user interviews and the importance of not overreacting to single user feedback and finding a balance in responding to diverse opinions. They reveal the varied reactions of users to Goodz's product, highlighting the different market segments interested in it. + +As the Incubator program nears its end for Goodz, Chris and Mike reflect on their achievements and future plans. They've made significant progress, such as setting up an e-commerce site and conducting successful user interviews. The co-founders discuss their excitement about the potential of their product and the validation they received from users. Mike mentions the importance of focusing on B2B sales and the possibility of upcoming events like South by Southwest and Record Store Day. + 28:35 + no + + + If you missed the other episodes with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can listen to the first episode (https://podcast.thoughtbot.com/s3e2incubatorgoodz) and the second episode (https://podcast.thoughtbot.com/s3e4incubatorgoodz), and the third episode (https://podcast.thoughtbot.com/s3e6incubatorgoodz) to catch up! +Lindsey Christensen and Jordyn Bonds catch up with the co-founders of Goodz, Chris Cerrito and Mike Rosenthal, where they share insights from their journey during the Incubator program, including the usefulness of the application process in aligning their vision and the challenges and benefits of user interviews and the importance of not overreacting to single user feedback and finding a balance in responding to diverse opinions. They reveal the varied reactions of users to Goodz's product, highlighting the different market segments interested in it. +As the Incubator program nears its end for Goodz, Chris and Mike reflect on their achievements and future plans. They've made significant progress, such as setting up an e-commerce site and conducting successful user interviews. The co-founders discuss their excitement about the potential of their product and the validation they received from users. Mike mentions the importance of focusing on B2B sales and the possibility of upcoming events like South by Southwest and Record Store Day. +Transcript: +LINDSEY: Thanks for being here. My name's Lindsey. I head up marketing at thoughtbot. If you haven't joined one of these before, we are checking in with two of the founders who are going through the thoughtbot Startup Incubator to learn how it's going, what's new, what challenges they're hitting, and what they're learning along the way. +If you're not familiar with thoughtbot, we're a product design and development consultancy, and we hope your team and your product become a success. And one way we do that is through our startup incubator. +So, today, we are joined by our co-founders, Mike Rosenthal and Chris Cerrito, Co-Founders of the startup Goodz. And we also have another special guest today, Danny Kim, from the thoughtbot side, Senior Product Manager at thoughtbot. So, I think, to start off, we'll head over to the new face, the new voice that we've got with us today. Danny, tell us a little bit about your role at thoughtbot and, specifically, the incubator. +DANNY: Yeah, sure. First of all, thanks for having me on, and thanks for letting me join in on all the fun. I'm one of the product managers at thoughtbot. I typically work for the Lift-Off team. We usually work with companies that are looking to, like, go into market with their first version MVP. They might have a product that exists and that they're already kind of doing well with, and they kind of want to jump into a new segment. We'll typically work with companies like that to kind of get them kicked off the ground. +But it's been really awesome being part of the incubator program. It's my first time in helping with the market validation side. Definitely also, like, learning a lot from this experience [laughs] for myself. Coming at it specifically from a PM perspective, there's, like, so much variation usually in product management across the industry, depending on, like, what stage of the product that you're working in. And so, I'm definitely feeling my fair share of impostor syndrome here. +But it's been really fun to stretch my brand and, like, approach problems from, like, a completely different perspective and also using different tools. But, you know, working with Mike and Chris makes it so much easier because they really make it feel like you're part of their team, and so that definitely goes a long way. +LINDSEY: It just goes to show everyone gets impostor syndrome sometimes [laughter], even senior product managers at thoughtbot [laughter]. Thanks for that intro. It's, you know, the thoughtbot team learns along the way, too, you know, especially if usually you're focused on a different stage of product development. +Mike, it's been only three weeks or a very long three weeks since last we checked in with you, kind of forever in startup time. So, I think the last time, we were just getting to know you two. And you were walking us through the concept, this merging of the digital and physical world of music, and how we interact with music keepsakes or merchandise. How's my pitch? +MIKE: Good. Great. You're killing it. +[laughter] +LINDSEY: And has anything major changed to that concept in the last three weeks? +MIKE: No. I mean, I can't believe it's only been three weeks. It feels like it's been a long time since we last talked. It's been an intense three weeks, for sure. No, it's been going really well. I mean, we launched all sorts of stuff. I'm trying to think of anything that's sort of fundamentally changed in terms of the plan itself or kind of our, yeah, what we've been working on. And I think we've pretty much stayed the course to sort of get to where we are now. But it's been really intensive. +I think also having sort of Thanksgiving in there, and we were kind of pushing to get something live right before the Thanksgiving break. And so, that week just felt, I mean, I was just dead by, you know, like, Thursday of Thanksgiving. I think we all were. So, it's been intense, I would say, is the short answer. And I'm happy, yeah, to get into kind of where things are at. But big picture, it's been an intense three weeks. +LINDSEY: That's cool. And when we talked, you were, you know, definitely getting into research and user interviews. Have those influenced any, you know, changes along the way in the plan? +MIKE: Yeah. They've been really helpful. You know, we'd never really done that before in any of the sort of past projects that we've worked on together. And so, I think just being able to, you know, read through some of those scripts and then sit through some of the interviews and just kind of hearing people's honest assessment of some things has been really interesting. I'm trying to think if it's materially affected anything. +I guess, you know, at first, we were, like, we kind of had some assumptions around, okay, let's try to find, like...adult gift-givers sounds like the wrong thing, adults who give gifts as, like, a persona. The idea that, like, you know, maybe you gift your siblings gifts, and then maybe this could be a good gift idea. And I think, you know, we had a hard time kind of finding people to talk in an interesting way about that. And I think we've kind of realized it's kind of a hard persona to kind of chop up and talk about, right, Chris? I don't know [crosstalk 04:55] +CHRIS: Well, it also seemed to, from my understanding of it, it seemed to, like, genuinely stress out the people who were being interviewed... +MIKE: [laughs] +CHRIS: Because it's kind of about a stressful topic [inaudible 05:03], you know, and, like, especially -- +LINDSEY: Why? [laughs] +CHRIS: Well, I think, I don't know, now I'm making assumptions. Maybe because we're close to the holiday season, and that's a topic in the back of everybody's mind. But yeah, Danny, would you disagree with that? Those folks, from what we heard, seemed like they were the most difficult to kind of extract answers from. But then, if the subject changed and we treated them as a different persona, several of those interviews proved to be quite fruitful. So, it's just really interesting. +DANNY: Yeah. It really started, like, you kind of try to get some answers out of people, and there's, like, some level of people trying to please you to some extent. That's just, like, naturally, how it starts. And you just, like, keep trying to drill into the answers. And you just keep asking people like, "So, what kind of gifts do you give?" And they're just like, "Oh my goodness, like, I haven't thought about buying gifts for my sister in [laughs], like, you know, in forever. And now, like [laughs], I don't know where to go." And they get, like, pretty stressed out about it. +But then we just kind of started shifting into like, "All right, cool, never mind about that. Like, do you like listening to music?" And they're like, "Yes." And then it just kind of explodes from there. And they're like, "This last concert that I went to..." and all of this stuff. And it was much more fruitful kind of leaning more towards that, actually, yeah. +LINDSEY: That's fascinating. I guess that speaks to, especially at this stage and the speed and the amount of interviews you're doing, the need for being, like, really agile in those interviews, and then, like, really quickly applying what you're learning to making the next one even more valuable. +MIKE: Yeah. And I think, you know, like, we launched just a little sort of website experiment or, like, an e-commerce experiment right before Thanksgiving. And I think now, you know, we're able to sort of take some of those learnings from those interviews and apply them to both sort of our ad copy itself but also just different landing pages in different language on the different kind of versions of the site and see if we can find some resonance with some of these audience groups. So, it's been interesting. +LINDSEY: Are you still trying to figure out who that early adopter audience is, who that niche persona is? +MIKE: I think we -- +CHRIS: Yes, we are. I think we have a good idea of who it is. And I think right now we're just trying to figure out really how to reach those people. That, I think, is the biggest challenge right now for us. +MIKE: Yeah. With the e-commerce experiment it was sort of a very specific niche thing that is a little bit adjacent to what I think we want to be doing longer term with Goodz. And so, it's weird. It's like, we're in a place we're like, oh, we really want to find the people that want this thing. But also, this thing isn't necessarily the thing that we think we're going to make longer term, so let's not worry too hard about finding them. You know what I mean? It's been an interesting sort of back and forth with that. +CHRIS: From the interviews that we conducted, you know, we identified three key personas. Most of them have come up, but I'll just relist them. There's the sibling gift giver. There was the merch buyers; these are people who go to concerts and buy merchandise, you know, T-shirts, albums, records, things along those lines to support the artists that they love. And then the final one that was identified we gave the title of the 'Proud Playlister'. And these are people who are really into their digital media platforms, love making playlists, and love sharing those playlists with their friends. +And that, I would say, the proud playlister is really the one that we have focused on in terms of the storefront that we launched, like, the product is pretty much specifically for them. But the lessons that we're learning while making this product and trying to get this into the hands of the proud playlisters will feed into kind of the merch buyers. +MIKE: Yeah. And I think that, you know, it's funny, like, this week is kind of a poignant week for this, right? Because it's the week that Spotify Wrapped launched, right? So, it's like, in the course of any given year, it's probably, like, the one week of the year that lots and lots and lots of people are thinking about playlists all of a sudden, so trying a little bit to see if we can ride that wave or just kind of dovetail with that a bit, too. +LINDSEY: Absolutely. And do you want to give just, like, the really quick reminder of what the product experience is like? +MIKE: Oh yeah [laughs], good call. +CHRIS: This is a prototype of it. It's called the Goodz Mixtape. Basically, the idea is that you purchase one of these from us. You give us a playlist URL. We program that URL onto the NFC chip that's embedded in the Good itself. And then when you scan this Good, that playlist will come up. So, it's a really great way of you make a playlist for somebody, and you want to gift it to them; this is a great way to do that. You have a special playlist, maybe between you and a friend or you and a partner. This is a good way to commemorate that playlist, turn it into a physical thing, give that digital file value and presence in the physical world. +LINDSEY: Great. Okay, so you casually mentioned this launch of an e-commerce store that happened last week. +MIKE: It didn't feel casual. +LINDSEY: Yeah. Why [laughter]...[inaudible 09:45] real casual. Why did you launch it? How's it going? +MIKE: I don't know. Why did we launch it? I mean, well, we wanted to be able to test some assumptions. I think, you know, we wanted to get the brand out there a little bit, get our website out there, kind of introduce the concept. You know, this is a very...not that we've invented this product category, but it is a pretty obscure product category, right? And so, there's a lot of sort of consumer education that I think that has to go on for people to wrap their heads around this and why they'd want this. +So, I think we wanted to start that process a little bit correctly, sort of in advance of a larger launch next year, and see if we could find some early community around this. You know, if we can find those core people who just absolutely love this, and connect with it, and go wild around it, then those are the people that we're going to be able to get a ton of information from and build for that persona, right? It's like, cool, these are the people who love this. Let's build more for them and go find other people like this. So, I think, for us, it was that. +And then, honestly, it was also just, you know, let's test our manufacturing and fulfillment and logistics capabilities, right? I mean, this is...as much as we are a B2B, you know, SaaS platform or that's what we envision the future of Goodz being, there is a physical component of this. And, you know, we do have that part basically done at this point. But we just, you know, what is it like to order 1,000 of these? +What is it like to put these in the mail to people and, you know, actually take orders? And just some of that processing because we do envision a more wholesale future where we're doing, you know, thousands or tens of thousands of this at a time. And so, I think we just want to button up and do some dry runs before we get to those kinds of numbers. +CHRIS: I think it also it's important to remember that we are talking in startup time. And while this last week seems like an eternity, it's been a week [laughs] that we've had this in place. So, we're just starting to learn these things, and we plan on continuing to do so. +MIKE: Yeah. But I think we thought that getting a website up would be a good way to just start kind of testing everything more. +LINDSEY: Great. Danny, what went into deciding what would be in this first version of the site and the e-commerce offering? +DANNY: I mean, a lot of it was kind of mostly driven by Chris and Mike. They kind of had a vision and an idea of what they wanted to sell. Obviously, from the user interviews, we were starting to hone in a little bit more and, like, we had some assumptions going into it. I think we ultimately did kind of feel like, yeah, I think, like, the playlisters seem to be, like, the target market. But just hearing it more and hearing more excitement from them was definitely just kind of like, yeah, I think we can double down on this piece. +But, ultimately, like, in terms of launching the e-commerce platform, and the storefront, and the website, like, just literally looking at the user journey and being like, how does a user get from getting onto a site, like, as soon as they land there to, like, finishing a purchase? And what points do they need? What are the key things that they need to think through and typically will run into? And a lot of it is just kind of reflecting on our own personal buyer behavior. +And, also, as we were getting closer to the launch, starting to work through some of those assumptions about buyer behavior. As we got there, we obviously had some prototypes. We had some screenshots that we were already working with. Like, the design team was already starting to build out some of the site. And so, we would just kind of show it to them, show it to our users, and just be like, hey, like, how do you expect to purchase this? Like, what's the next step that you expect to take? And we'd just kind of, like, continue to iterate on that piece. And so... +LINDSEY: Okay. So you were, before launching, even showing some of those mockups and starting to incorporate them in the user interviews. +DANNY: Yeah, yeah. I mean, we tried to get it in there in front of them as early as possible, partially because, like, at some point in the user interviews, like, you're mostly just trying to first understand, like, who are our target customers? Who are these people? And we have an assumption of or an idea of who we think they are. But really, like, once you start talking to people, you kind of are, like, okay, like, this thing that I thought maybe it wasn't so accurate, or, like, the way that they're kind of talking about these products doesn't 100% match what I originally walked into this, you know, experiment with. And so, we, like, start to hone in on that. +But after a certain point, you kind of get that idea and now you're just like, okay, you seem to be, like, the right person to talk to. And so, if I were to show you this thing, do you get it, right? Like, do you understand what's happening? Like, how to use this thing, what this product even does. And then also, like, does the checkout experience feel intuitive for you? Is it as simple as, like, I just want to buy a T-shirt? So, like, I'm just going to go by the T-shirt, pick a size, and, you know, move on with my life. Can we make it as seamless as that? +LINDSEY: And so, you mentioned it's only been a week since it's been live. Have you been able to learn anything from it yet? And how are you trying to drive people to it today? +MIKE: Yeah, I think we learned that sales is hard [laughs] and slow, and it takes some time. But it's good, and we're learning a lot. I mean, it's been a while since I've really dug deep in, like, the analytics and marketing kind of metrics. And so, we've got all the Google Tag Manager stuff, you know, hooked up and just, you know, connecting with just exploring, honestly, like the TikTok advertising platform, and the YouTube Pre-Rolls, and Shorts. And, like, a lot of stuff that I actually, since the last time I was heavily involved in this stuff, is just totally new and different. +And so, it's been super interesting to see the funnel and sort of see where people are getting in the site, where people are dropping off. You know, we had an interesting conversation in our thoughtbot sync yesterday or the day before, where we were seeing how, you know, we're getting lots of people to the front page and, actually, a good number of people to the product page, and, actually, like, you know, not the worst number of people to the cart. But then you were seeing really high cart abandonment rates. +And then, you know, when you start Googling, and you're like, oh, actually, everybody sees very high cart abandonment rates; that's just a thing. But we were seeing, like, the people were viewing their cart seven or eight times, and they were on there sort of five times as long as they were on any other page. And it's this problem that I think Danny is talking about where, you know, we need to actually get a playlist URL. This gets into the minutiae of what we're building, but basically like, we need to get them to give us a playlist URL in order to check out, right? +And so, you sort of have to, like, put yourself back in the mind of someone who's scrolling on Instagram, and they see this as an ad, and they click it, and they're like, oh, that thing was cool. Sure, I will buy one of those. And then it's like, no, actually, you need to, you know, leave this, go into a different app, find a play...like, it suddenly just puts a lot of the mental strain. But it's a lot. It's a cognitive load, greater than, as you said, just buying a T-shirt and telling what size you want. +So, thinking through ways to really trim that down, shore up the amount of time people are spending on a cart. All that stuff has been fascinating. And then just, like, the different demographic kind of work that we're using, all the social ads platforms to kind of identify has been really interesting. It's still early. +But, actually, like, Chris and I were just noticing...we were just talking right before this call. Like, we're actually starting to get, just in the last 12 hours, a bunch more, a bunch, but more people signing up to our email newsletter, probably in the last 12 hours that we have in the whole of last week. Yeah, I don't know, just even that sort of learning, it's like, oh, do people just need time with a thing, or they come back and they think about it? +CHRIS: Yeah. Could these people be working on their playlists? That's a question that I have. +MIKE: [chuckles] Yeah, me too. +CHRIS: It's like, you know, I'm making a playlist to drop into this product. It's really interesting. And I think it gives insight to kind of, you know, how personal this product could be, that this is something that takes effort on the part of the consumer because they're making something to give or to keep for themselves, which is, I think, really interesting but definitely hard, too. +DANNY: Yeah. And I also want to also clarify, like, Chris just kind of said it, like, especially for viewers and listeners, like, that's something that we've been hearing a lot from user interviews, too, right? Like, the language that they're using is, like, this is a thing that I care about. Like it's a representation of who I am. It's a representation of, like, the relationship that I have with this person that I'm going to be giving, you know, this gift to or this playlist to, specifically, like, people who feel, like, really passionate about these things. And, I mean, like, I did, too. +Like, when I was first trying to, like, date, my wife, like, I spent, like, hours, hours trying to pick the coolest songs that I thought, you know, were like, oh, like, she's going to think I'm so cool because, like, I listen to these, like, super low-key indie rock bands, and, like, you know, so many more hours than she probably spent listening to it. But that's [laughs] kind of, like, honestly, what we heard a lot in a lot of these interviews, so... +LINDSEY: Yeah, same. No, totally resonates. And I also went to the site this week, and I was like, oh damn, this is cool. Like, and immediately it was like, oh, you know, I've got these three, you know, music friends that we go to shows together. I'm like, oh, this would be so cool to get them, you know, playlists of, like, music we've seen together. So, you might see me in the cart. I won't abandon it. +MIKE: Please. I would love that. +CHRIS: Don't think about it too long if you could -- [laughter]. +LINDSEY: I won't. I won't. +CHRIS: I mean, I would say I'm really excited about having the site not only as a vehicle for selling some of these things but also as a vehicle for just honing our message. It's like another tool that we have in our arsenal. During the user interviews themselves, we were talking in abstract terms, and now we have something concrete that we can bounce off people, which is, I think, going to be a huge boon to our toolset as we continue to refine and define this product. +MIKE: Yeah, that's a good point. +LINDSEY: Yeah. You mentioned that they're signing up for, like, email updates. Do you have something you're sending out? Or are you kind of just creating a list? Totally fine, just building a list. +MIKE: [laughs] No. +CHRIS: It's a picture of Mike and I giving a big thumbs up. That's, yeah. [laughter] +MIKE: No. But maybe...that was the thing; I was like, oh great, they're signing up. And I was like, gosh, they're signing up. Okay [laughter], now we got to write something. But we will. +LINDSEY: Tips to making your playlist [crosstalk 19:11] playing your playlist -- +MIKE: Yeah [crosstalk 19:13]. +CHRIS: Right. And then also...tips to making your playlists. Also, we're advancing on the collectible side of things, too. We are, hopefully, going to have two pilot programs in place, one with a major label and one with a major artist. And we're really excited about that. +LINDSEY: Okay. That's cool. I assume you can't tell us very much. What can you tell us? +MIKE: Yeah. We won't mention names [chuckles] in case it just goes away, as these things sometimes do. But yeah, there's a great band who's super excited about these, been around for a long time, some good name recognition, and a very loyal fan base. They want to do sort of a collection of these. I think maybe we showed the little...I can't remember if we showed the little crates that we make or not, but basically, [inaudible 19:52] +LINDSEY: The last time, yeah. +MIKE: So, they want to sell online a package that's, you know, five or six Goodz in a crate, which I think will be cool and a great sort of sales experiment. And then there's a couple of artists that we're going to do an experiment with that's through their label that's more about tour...basically, giving things away on tour. So, they're going to do some giveaway fan club street team-style experiments with some of these on the road. +So, first, it's ideal, provided both those things happen, because we definitely want to be exploring on the road and online stuff. And so, this kind of lets us do both at once and get some real learnings as to kind of how people...because we still don't know. We haven't really put these in people's hands yet. And it's just, like, are people scanning these a lot? Are they not? Is this sort of an object that's sitting on their shelf? Is it...yeah, it's just, like, there's so much we're going to learn once we get these into people's hands. +LINDSEY: Do you have the infrastructure to sort of see how many times the cards are scanned? +CHRIS: Mm-hmm. Yep, we do. +MIKE: Yeah. So, we can see how many times each one is scanned, where they're scanned, that sort of thing. +CHRIS: Kind of our next step, and something we were just talking about today with the thoughtbot team, is building out kind of what the backend will be for this, both for users and also for labels and artists. That it will allow them to go in and post updates to the Goodz, to allow them to use these for promotion as people, you know, scan into them to give them links to other sites related to the artists that they might be interested in before they move on to the actual musical playlist. So, that's kind of the next step for us. And knowing how users use these collectibles, both the kind of consumer Good and the artist collectibles that we were just talking about, will help inform how we build that platform. +LINDSEY: Very cool. And right now, the online store itself that's built in Shopify? +MIKE: Yeah. The homepage is Webflow that Kevin from the thoughtbot team really spearheaded in building for us. And then, yeah, the e-commerce is Shopify. +LINDSEY: Y'all have been busy. +MIKE: [laughs] +LINDSEY: Is there anything else maybe that I haven't asked about yet that we should touch on in terms of updates or things going on with the product? +MIKE: I don't know. I don't think so. I think, like Chris said, I mean, we're just...like, now that the site has kind of stood up and we're really switched over to kind of marketing and advertising on that, definitely digging into the backend of this kind of SaaS platform that's going to probably be a big focus for the rest of the, you know, the program, to be honest. Yeah, just some other things we can do on the next front that could eventually build into the backend that I think can be interesting. No, I guess [laughs] the short answer is no, nothing, like, substantial. Those are the big [crosstalk 22:26] +LINDSEY: Yeah. Well, that was my next question, too, which is kind of like, what's next, or what's the next chunk of work? So, it's obviously lots more optimization and learning on the e-commerce platform, and then this other mega area, which is, you know, what does this look like as a SaaS solution? What's the vision? But also, where do we start? Which I'm sure, Danny, is a lot of work that you specialize in as far as, like, scoping how to approach these kinds of projects. +DANNY: Yeah. And it's interesting because, I mean, we were just talking about this today. Like, part of it is, like, we can, like, really dig into, like, the e-commerce site and, like, really nailing it down to get it to the place where it's like, we're driving tons more traffic and also getting as low of a, like, cart abandonment rate as possible, right? But also, considering the fact that this is in the future, like, large-scale vision. +And there's, like, also, like, we're starting to, I think, now iron out a lot of those, like, milestones where we're kind of like, okay, like, we got, like, a short-term vision, which is, like, the e-commerce site. We got a mid-term vision and a potential long-term vision. How do we validate this long-term vision while also still like, keeping this short-term vision moving forward? +And, like, this mid-term vision is also going to, like, help potentially, either, like, steer us towards that long-term or maybe even, like, pivot us, like, into a completely different direction. So, like, where do you put your card, right? Like, how much energy and time do we put into, like, each of these areas? And that's kind of, like, the interesting part of this is starting to talk through that, starting to kind of prioritize, like, how we can maximize on our effort, like, our development and design effort so that things just kind of line up more naturally and organically for our future visioning, so... +MIKE: Yeah. A lot of different things to juggle. I saw there was a question. Somebody asked what the URL is, but I don't seem to be able to [crosstalk 24:10]. +LINDSEY: The same question as me. We got to drop the link for this thing. +MIKE: Yeah, getthegoodz.com. +CHRIS: That's G-O-O-D-Z. +LINDSEY: Get in there, folks +MIKE: Yeah, get [crosstalk 24:23]. +LINDSEY: And let us know how it goes. +MIKE: Yeah, please [laughs]. Any bugs? Let us know. Yeah. I think that those...yeah, I mean, it's a good point, Danny, in terms of juggling kind of the near-term and longer-term stuff. You know, it's a good kind of reminder our big focus, you know, in the new year is going to be fundraising, right? We're already talking to some investors and things like that. +So, it's like, okay, yes, as you said, we could tweak the cart. We could tweak the e-commerce. Or, like, can we paint the big picture of what the longer-term version of this company is going to be in a way that makes it compelling for investment to come in so that there can be a long-term version of this company? And then we can build those things. So yeah, it's definitely a balance between the two. +LINDSEY: Oh, also, just casual fundraising as well. +[crosstalk 25:06] +MIKE: Yeah, yeah. +LINDSEY: [laughs] +MIKE: But it's hard. It's like, you wake up in the morning. It's like, do I want to, like, write cold emails to investors? Or do I want to, like, look at Google Analytics and, like, tweak ad copy? That's actually more fun. So, yes. +LINDSEY: Yeah, life of the founder, for sure. All right. So, that's getthegoodz (Goodz with a z) .com. Check it out. We'll tune in and see what happens with the e-commerce site, what happens with the SaaS planning the next time that we check in. +But Chris, Mike, Danny, thank you so much for joining today and sharing what's been going on over the last few weeks: the good, the bad, the challenge, the cart abandonment. And, you know, best of luck to you over the next few weeks, and we'll be sure to check in and see how it's going. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. +Transcript: + LINDSEY: Thank you to our viewers and listeners. We are catching up once again with one of the startups going through the thoughtbot Incubator. My name is Lindsey Christensen. I'm joined today by Jordyn Bonds, who heads up the thoughtbot incubator, as well as our Co-Founders of Goodz, Chris Cerrito and Mike Rosenthal. Welcome, everybody. +MIKE: Thanks, Lindsey. +LINDSEY: Before we get started, before we put Chris and Mike back in the hot seat, at the top here, Jordyn, we have a special announcement for our viewers and listeners. +JORDYN: Application window is open for session 1 of 2024, folks. You can go to thoughtbot.com/incubator and apply. And Chris and Mike can tell you how easy or hard applying was. +MIKE: It was easy. It was totally easy. It's a very straightforward process. +CHRIS: Yeah, it was way more straightforward than a lot of applications that we've dealt with in the past, for sure. +JORDYN: Ha-ha. And if you've got a business idea that involves software but you haven't gotten anything out there yet, come talk to us. We will help you make sure that it's a good idea and that there are people who might buy it, and maybe get you even a little further than that. +MIKE: We actually have a friend who's considering applying. I'll tell him applications are open. He's worried his idea is not big enough to actually be a business idea, so we'll see. +CHRIS: Even the process of doing the application was really helpful for us because it helped us get aligned on exactly what we were doing, yeah. +JORDYN: I love that. And I found that to be true when I was a founder applying to some of these things, in particular, applying for an SBIR grant was one of the most challenging things that we did, but it was so productive. I was so annoyed by it at the time, and then I cribbed from that thing. It actually sort of forced us to make a business plan [laughs], and then, basically, we ran it, and it was great [laughs]. +CHRIS: Yeah. I think that was, for us, that was our point where we were like, "Is this idea fleshed out enough to move forward?" And we were like, "Yes, it is. Let's go. Let's do this." +JORDYN: So, use the application as a forcing function, everybody. It will help you clarify your thinking. +LINDSEY: Yeah. Jordyn, what would you say to Mike's friend who's questioning if their idea is big enough? How do you respond to that sentiment? +JORDYN: That is a fascinating sentiment because I feel like so much more often, I am trying to help founders with the opposite problem where they think this thing is so big that they are not thinking about what step 1 is going to look like. They're just, like, in 10 years, we're going to be the next Amazon, and I'm like, "Maybe [laughter]. Let me help you figure out how to get to that giant vision." So, I don't come across the "Is this big enough to be a business?" question as often. And, I don't know, what would I say? I guess I need the details. +LINDSEY: It could be a perfect fit +MIKE: It could be. +JORDYN: It could be a perfect fit. +LINDSEY: In a way, that's what you're answering, right? +MIKE: Right. +LINDSEY: In some of this work. +MIKE: That is true. So, yeah, you guys would certainly...just thinking through the process we've gone through the last two months, it would definitely help them flesh that out. +LINDSEY: Which is a great segue. +MIKE: Great segue. +LINDSEY: Chris and Mike, we're actually coming up to the end of your incubator time. +CHRIS: It's so sad. +LINDSEY: Can you believe it? +MIKE: It's gone by really fast. I mean, eight weeks is not a long time, but it has gone by very, very fast. +CHRIS: It felt like a very long time in the middle of it. +MIKE: [laughs] +CHRIS: But now that it's over, it feels like a blink that it's coming to a close. +MIKE: I don't know. It's funny. I think we had some note in our retro today that was like, maybe the very end of the year is not the best time to do an accelerator just because you have, like, the holidays kind of jumping in here in the end. So, that might have helped make it feel like a... I feel like the end of the year always feels like a rush anyway. So, I think just life gets a little bit busier this time of year, too, but yeah. +CHRIS: Yeah, my gingerbread man decorating game is, like, really down this season because we've been so busy. Tragic. +LINDSEY: Chris, can you remind our viewers and listeners who might not be familiar what was the idea that you and Mike have been exploring with the incubator or, like, what did you come in with? +CHRIS: So, with Goodz, what we're trying to do is make little, physical collectibles objects that connect back to the digital content that a user loves. The idea being that today, we are awash in these digital files, links, so many things on our desktops, on our phones, on our devices, and it's really hard to tell which part of those are really, really important to us. So, by giving them a presence in the physical world, that denotes that's something that's really important, worth keeping, worth sharing, and showing off to your friends and family. +And to start this off, mostly because Mike and I are both kind of music nerds, we're starting off with a music focus, but at some point, we're hoping to move into other realms, too. +LINDSEY: And a lot of the incubator, as repeat listeners will know, is focused on really kind of evolving user interviews all the way through and narrowing in on, you know, a core audience, a core market. Mike, how has that evolution been? I think the last time we chatted was around three weeks ago. What has the latest iteration of user interviews looked like in terms of the people you're talking to and even what you're asking them? +MIKE: It's been a really fascinating process. I mean, I'm trying to think of where we were exactly the last time we talked to you, but I think we'd probably just launched the e-commerce site that we had been experimenting with putting up. +LINDSEY: Yeah, exactly. +MIKE: And so, and we really then started cranking on user interviews kind of once that was live. And so, moving away from the conceptual and more into like, "Okay, share your screen. Here's the link. Like, tell me what you think is going on here," and really sort of getting users who had never, you know, never heard our pitch, never been involved with us to sort of try to wrap their heads around what we are and what we're doing just based on that website and trying to sort of make iterative changes based on that. +You know, for me, because I had not done user interviews very much in the past, like, it's very tempting, like, you get sort of 1 note from 1 person in 1 interview, and you're like, oh, we need to change this word. That word didn't make any sense to them, or this thing needs to be blue instead of pink. I think, for me, it was like, all right, how do we kind of synthesize this data in a responsible way? +And it emerged naturally, which, I mean, Jordyn and all thoughtbot folks said that it would, but you sort of started hearing the same things again and again. And we never really got to a place where, like, you heard the exact same things from everyone. But there were enough buckets, I feel like, where we're like, okay, like, this part really isn't making that much sense to people, or, like, we do really need to, you know, structure this differently to convey. +So, it was a bunch of that kind of work over the last three weeks or so and sort of just getting a sense of like, are we conveying our message? It's hard. I mean, it's a new, like, we're not the only people making physical products with NFC chips in them, but it is not the most common, like, product. Like, it is kind of a new category out there. And so, really trying to understand just right off the bat, do people get it? And you get wildly different answers [laughs] as to whether they get it or they don't, which has been fascinating, too. +JORDYN: Yeah. [crosstalk 7:12] +LINDSEY: Chris or Jordyn, anything to add there? +JORDYN: Yeah. You get the best, like, bootcamp in the don't overreact to a single user interview experience in some ways because we [laughs]...it would literally be like, interview in the morning someone says this thing. Interview in the afternoon, someone says the exact opposite thing [laughter]. And you're like, okay [laughs], like, which one of these things are we going to respond to, if either of them? +CHRIS: Yeah. It's hard. As somebody with, like, a strong desire to please, it's hard to reign yourself in and want to change things immediately, but it definitely makes sense to do so in the long run. +MIKE: But yeah, but, I mean, like I said, I do feel like it kind of came down to buckets. It's like, okay, you're that. I can, like, categorize you with all those other people and you with all those other people. And yeah, I hear you. I'm like, yeah, it's tempting to want to please them all. +But I think with this one, we're fighting hard to be like...or we sort of have a philosophy that this product is emphatically not for everyone because, at the end of the day, you get a lot of people who are like, "Wait, you're just putting a link to a streaming playlist on a physical object? Why don't I just text someone the link?" And sometimes that breaks down by age group, like, 18-year-olds being like, "What are you talking about, old man? +LINDSEY: [laughs] +MIKE: Like, why the hell would I do that? It makes no sense." But it sort of skews all over the age ranges. But then there'll be other people who are 18 or 20 years old who are like, "Wow, I never had cassettes when I was growing up," or "I never got to make, you know, mixtapes or CD-Rs for people." And like, you know, so it's, yeah, it's about finding the people who are the early adopters. As Jordyn has said a lot, it's like, we need to find those early adopters and, like, make them love us, and then other people will come later. +CHRIS: I mean, some of the most gratifying moments, I think, are there's been some interviews where people have been so excited that after the interview, they've gone and purchased our products, which is just, like, the coolest feeling ever. +LINDSEY: Wow. +MIKE: Yeah, it's pretty cool. +LINDSEY: Are you open to sharing a little bit more about what those buckets or what those segments look like? +CHRIS: I mean, I think there's folks who outright just get it almost immediately, and I think those people tend to be hardcore music collectors, hardcore music fans, Jordyn and Mike, please feel free to jump in if you disagree with any of this. They just get it right off the bat. +Then I think there's, in my experience, there's another bucket of people who are a little more hesitant, and maybe they wouldn't buy it, but they seemed really excited about the idea of getting one as a gift, which is really interesting. They're like, "I don't know if I'd buy this, but I'd really like to have one." And then there is another segment, like, which Mike just mentioned, of folks who just don't see the value in this whatsoever, which is totally fair. +MIKE: Yeah, totally. I think it's also...I see it almost as, like, a matrix. There's, like, desirability, and, like, technical understanding because people were like, "I technically understand what this is, and I do not want it in my life." Or like, "I get what this is and, oh my God, I have to have that," or like, "I don't really understand what you're talking about, but, man, I love physical stuff. Like, sure I want..." you know, it's like, it goes across those two planes, I think. +JORDYN: I will say that it, I think you alluded to this before, Mike, but, like, we're going to run a whole analysis of...because we did a ton of interviews, and we haven't actually done that, like, sort of data-driven thing of like, are there trends in the demographics somewhere that we're not getting? Because the pattern has not been there. Like, someone will talk to an 18-year-old, you know, at 1:00 p.m. who is just, like, "Why on earth would I ever want this?" And then I, like, you know, will talk to a 21-year-old who is like, "I love this." +And it's like, why? Like, this is the answer. The thing we're trying to get out now is, like, what is the difference between those two people? It's not a demographic thing that we can see from the outside, so what is it instead? But with consumer stuff like this, often, you don't necessarily...you don't need that in such great detail when you're starting. You just kind of, like, throw it out there and see who grabs it, and then you start to build sort of cohorts around that. +And that is kind of what these interviews have shown us is that there are people who will grab it, and that was part of what we were trying to validate. Are there people who Mike and Chris do not know personally who will, like, get this and be psyched about it immediately? And that is, you know, check unequivocally true. Like Chris said, there are people that we were, you know, that we had recruited on this user interviews platform [chuckles] who then just turned around and bought the product because they were so psyched about it. One of the guys I interviewed was like, "Can I invest in your company right now?" Like, during the interview, and I was like, "Maybe?" [laughs] +CHRIS: There was, like, another person who wanted to work for us immediately... +JORDYN: Yes, great. +CHRIS: Which was really interesting and kind of awesome. +JORDYN: Yeah, they're like, "Are you hiring?" You're just like, okay. So, it's validating that there are people all over that spectrum. Like, where those trends lie, though, which is, I think, what you were asking, Lindsey, not as straightforward and in a fascinating way. So, we still have a little more, like, number crunching to do on that, and we may have an answer for you later. +LINDSEY: That's exciting. Exactly. I'm curious: what are the connecting dots between the folks who are really into it, and how might that impact how you approach the business? +MIKE: Yeah, it's hard. It's definitely going to be a niche to start. And so, we got to figure out kind of got to crack the code on how we find those people. +LINDSEY: And, Mike, I think you had also mentioned last time that, you know, you or both of you have a network kind of in the music industry, and you've been floating the idea past some people there. Have you been having more of those conversations over the last few weeks, too? +MIKE: We have, yeah. Well, so yeah, we've had a couple more just kind of straight-up pitch calls versus like, "Hey, there's this cool thing we're doing," and having those people be like, "Cool. Let's do a pilot." And so, they're ordering, you know, 500 or 1,000 units at a time, which is rad. +LINDSEY: Whoa. +MIKE: For the first...yeah. +LINDSEY: Okay, very cool. +MIKE: Yeah. The first two or three of those should happen in January or maybe early February, but yeah, those are done and in production and arriving soon. So, that's really exciting with some cool bands. We won't say the names in case it doesn't [laughs] work out, but it does look like it's going to work out. +LINDSEY: And so, it's specific bands that are creating merch for their fans. +MIKE: Yeah, yeah. So, we're working with one artist manager on a band that he manages, and then we're working with a record label. And they're going to try with a couple of smaller artists. And so, yeah, it's actually really good for us. One is going to be straight-up sales, most likely, and it's, like, selling these things. And the other ones will be given away as kind of promo items on tour artists, which is also a really interesting use case for us, too, that we're excited about and using them as a way to sort of get email addresses and, like, fans engaged and stuff, so... +And then yeah, then I had another conversation, and they want to talk about doing some pilots. So far, like, that side of things is going great. We're sort of 3 for 4 in terms of initial calls leading to pilots right off the bat, which is kind of unheard of from [laughs] my experience. +LINDSEY: Yeah, I'd say so. No, a lot of very good signals. +MIKE: Really good signals. But then we were able to turn some of those into user interview conversations, actually, as well over the course of the last couple of weeks, which has been really helpful, like, talking to manager and label-type people about what they might want out of a software product that is associated with this because we're not just thinking about making physical products but sort of coupling that with an online toolset. And that part, we haven't gotten as far along as we did with the direct-to-consumer e-commerce, but it's been fascinating. +LINDSEY: So, what has been happening with the online shop? As you noted the last time we talked, it was just a baby less than a week-old Shopify site getting, you know, some first hits of people going around maybe putting things in their basket. I'm sure a lot has happened over the last few weeks. What kind of work, what kind of insights have you seen around the site? +CHRIS: We've been, I mean, we've been selling stuff at a slow but steady pace. It's been great because it's enough to, you know, because our product really straddles the line between physical and digital; there's a lot of physical aspects to this that we need to figure out and kind of the level of orders that we've been getting have been really...it's, like, the perfect number to think about fulfillment issues, things like what kind of package does this go in? How do we mail this out? Things along those lines, just very basic, practical questions that needed to be answered. +But yeah, it's been great. We actually, I mean, we hit our goal for the amount of these that we wanted to get in people's hands before Christmas, which is pretty awesome. And we continue now with the lessons learned. I think our plan is to try and make a push for Valentine's Day because these seem like they would be a great Valentine's Day present: make a playlist; share it with your loved one; share it with a friend; share it with somebody you don't like at all. Who knows? +LINDSEY: [laughs] +CHRIS: But yeah, that's kind of our next sales push, we think. +LINDSEY: The hate playlist. +CHRIS: [inaudible 15:40] hate playlist. +MIKE: Yeah, perfect. Real passive-aggressive. +CHRIS: Just Blue Monday, like, by New Order, like, 14 times. +LINDSEY: [laughs] Yeah, every song is just like a sub-tweet... +MIKE: [laughs] +LINDSEY: About something they've done and [inaudible 15:53] Have you updated the site? Like, how do you decide what gets updated on the site? [laughter] Everyone laughed. +MIKE: It was a little haphazard, I would say, there for a minute. But -- +CHRIS: We got the site up very, very quickly. And from my perspective, I've been dealing a lot with the physical side of things, just getting great product photos up there, which is, like, something that thoughtbot has actually been super helpful with. You know, everybody on the team is starting to submit photos of their Goodz in the real world and using their Goodz, which is great. +And we continued to update the site with that but also making sure our text made sense, refining copy in response to things that people said during user interviews. The checkout process, the process of adding the URL that we point the Good to that, we did a bunch of experimentation there based on what people were saying during user interviews. So, it has been a little haphazard, but we have made a bunch of changes. +LINDSEY: Jordyn, has there been any experiment, like, structured experimentation around the site or how you're getting people to the site? +JORDYN: Mike actually did a little bit of ad funnel work that I don't think we've, like, even remotely scratched the surface of. So, I wish I could say that was conclusive, but I think we've found a little bit more...here are plenty of sales that are from people that nobody here knows. +MIKE: True. +JORDYN: So, people are finding out about this somehow [laughs]. But I think it's a little bit, like, word-of-mouth sort of chain of events is our sense so far. I wanted to say, though, about the site, we did get what Chris was saying about, like, this experiment was, in part, about fulfillment and figuring out how fulfillment would work and packaging, and not just messaging and not just closing the sale with consumers, but also, just, like, how do you fulfill these? +But one of the really fun things we've managed to do in the last, since we talked last time, which I can't even believe...I feel like this wasn't even a gleam in our eyes for this project, but we managed to get out, like, stood up and out the door, and working in production in the last few weeks is a way for folks to actually assign the URL to their mixtape themselves. Previously, the plan had just been for Chris and Mike to do that, which is fine but a little bit unscalable, right? +CHRIS: That was a huge dream or, like, that was high on our wish list. And we didn't think we'd get to it. And it's been pretty amazing that we have, yeah. +JORDYN: Yeah, so that was one thing that is an update to the site. So, then we had to do a little bit of, like, micro iterating, on, like, the messaging around that. Like, how do you communicate to people? This is, like, a little bit of an abstract challenge, right? Like, here's this object. It's going to point to a digital thing. How do you tell the physical object which digital thing it's pointing to [laughs]? +So, a lot of our recent interviewing has been to sort of get inside the mind of the consumer about how they're thinking about that and how we can best communicate that to them. So that's been a lot of the, like, recent iteration is getting that mechanism stood up and then the messaging around it. +CHRIS: It's also really cool because it adds to the utility of the object itself in the sense that now our Goodz, when a user gets one, they can add a URL to their Good themselves, but they can also change that URL. So, it's much more malleable. +JORDYN: Which is something that in one of our early user interviews was, like, a hot request [laughs], and we were like, "Someday, someday." And it's, you know, I should actually go back to her and be like, "Someday is today." +[laughter] +MIKE: Well, yeah, and just as Chris was saying, it just makes it so much easier to ship these out without having to manually load them, and you could sell them, and yeah, retail outlets, like, it just opens up a lot of opportunities for us for them. +LINDSEY: And Mike mentioned that some of the, like, kind of future looking aspirations for the solution are, you know, how might you figure out the B2B, like, SaaS aspect of it? Jordyn, is that something that's been explored at all at this point, or is it early? +JORDYN: That experiment I just described is actually sort of the link between the two projects. It sort of proves the concept and proves the value in some ways, and it has given us a little bit more visibility into sort of how we're going to execute some of this technical stuff. Like, how easy, how difficult is it going to be? These little experiments all build your confidence around your ability to do those things and what it's going to look like. And so, this experiment absolutely feeds into that question. +But I would say it was really this week where we got to have a really fun brainstorming sort of blue sky conversation about that that I don't think would have been nearly as both creative and blue sky or rooted in reality as it was if we hadn't done these experiments and hadn't talked to so many...we had so much work...we could participate in a conversation like that so much more confidently and creatively because all of us had a lot more shared context. +So, we really got to dream big, like, what is a SaaS platform built around these physical objects? And I don't want to, you know, I'm not going to give it away at this moment because we had a lot of, like, really cool ideas. It's one part talking to the B2B customer, which, you know, you mentioned earlier, getting what their pain points are, and what they're looking for, what they need, but then also dreaming big about now we understand the technology a little bit more and how it feels to use it. What does that unlock in our brains? +The analogy I used in that conversation and that I use all the time is like, the users of Twitter invented hashtags, right? Twitter did not invent hashtags. And so, hey, everybody out there, newsflash: users invented hashtags, not Twitter or something else, if you didn't realize that Twitter was where those things kind of emerged. But there was just a user behavior that was happening in the wild, and Twitter was just very good at making that easier for them, looking at that and being like, "Oh, hey, is this a thing you all want to do? Here, we'll make that even more useful for you." And it was part of Twitter's early success that they were able to do that. +And so, that was the kind of thinking we were trying to employ here is, like, now that we have these objects and we understand a little bit more how it feels to use them, you get these second order effects. What does that then make us think of? What is then possible to us that we wouldn't have been able to dream of previously because we didn't quite get it? So, that was really happening this week. +LINDSEY: So, as the incubator time wraps up, what are the kind of final activities or deliverables, one, that Goodz wants and you know that they're going to get? What are the parting gifts as we send you out into the next phase? +MIKE: Yeah, well, loads of stuff. I mean, we're getting all that code that [SP] Guillermo and the guys worked on to let people set their own playlist settings. And we've got that up in a GitHub repository now. And we've got a bunch of great design work that's all being handed over, like Chris was saying, product shots that a bunch of the team members were taking, synthesizing all the user interviews. We're actually sort of making some kind of final reports on those, so it's kind of more usable, actionable data for us. The whole website, you know, that didn't exist before. And that will sort of continue to grow as the entire website for Goodz moving forward. I don't know. That's a lot. What else was there, Chris? +CHRIS: As a result of all that, I mean, one of the things I'm most excited about is now we have a small user base who actually has the physical products that, hopefully, we can get them to answer questions. That's huge for what's coming next. Starting the path towards the SaaS platform, too, it's really helped narrow our scope and think about, you know, how to make that successful or if it will be successful. +LINDSEY: Yeah, that sounded like a big discussion this week that I know has been on your minds from the beginning. Wait, the last time, also, you said you were starting to get emails, too. Have you emailed anyone yet, or are you still holding on to them? +MIKE: Oh. No, I still haven't sent a newsletter out [laughs], actually, but we have Mailchimp set up. Yeah, no, we've got a good kind of core of our, yeah, early folks on there. We'll start getting a newsletter out with some sort of regularity. We're building up the socials very slowly just focusing on Instagram mostly right now and trying to get back into that game. +It's been a long time since I've had to do kind of social marketing stuff. And so, it's a lot of work, as it turns out, but we'll get all that cooking. I think this was just such a sprint, working with the thoughtbot folks and trying to get all this stuff done. Before the end of the year, now we can sort of take a breath and start engaging folks in the new year. +LINDSEY: Yeah. Well, so, do you know what you want to do next or what the next phase looks like? Are you going to do fundraising? +MIKE: We're certainly going to continue to have some fundraising conversations. We've had some conversations emerge over the last, you know, since we've been in thoughtbot, again, not the greatest time of year to try to be raising a round. But we're also not, like, desperately, urgently needing to do that right this second. I think, you know, part of it is the fundraising landscape, you know, doesn't look amazing. And we're still sort of building out a lot of traction, and sort of every week, there's some new, exciting thing, or we've got some new, big artists who wants to do something. +So, I think, in some ways, to the extent that we can bootstrap for a little while, I think we will, yeah. So, we will focus on...I'd like to get back to focusing on, like, B2B sales. I'd like to hit the ground in January and just start talking to a bunch of music industry folks. +And thinking ahead a little bit, sort of Q1 and Q2, like, what are the big tentpole events? You know, you got South by Southwest coming up in March. You got Record Store Day in April, or whenever it is. But, you know, there's, like, a bunch of those sorts of things that it's like, oh, let's not let those things suddenly be tomorrow. Like, right now, they're all still two or three/four months out. Like, let's make sure we're queued up for those things and see what happens. +And Jordyn has been giving really good advice on the fundraising side where it's just like, just keep getting cool stuff like that and just do almost like little drip campaigns with funders who aren't maybe giving you the time of day or think it's too early, and just kind of keep going back to them. Like, the best excuse to go back to funders is like, "Hey, we just closed this new thing. We just launched this new thing. We just got this thing working. Hey, we're launching with this major band," Like, enough of those happen, and I think the fundraising will happen more organically. It's a strategy. +CHRIS: I think we're really lucky in the fact that, you know, now, at this point, we're not talking about vapourware, you know, like, these are actual things that actually exist that, like, anybody could go onto our site right now and buy, which is awesome. And because of that, the product's going to continue to evolve, and, hopefully, our sales record will continue to evolve, too. +LINDSEY: Amazing. Well, that feels like a good place to wrap up, maybe. Are you going to hang around in our incubator Slack, the thoughtbot incubator Slack for all our past founders? +MIKE: Yes. Emphatically, yes. +LINDSEY: Okay. We're holding you to it then [laughs]. +CHRIS: I'm excited about that. We met with the other founders yesterday for the first time, and it was a really great and interesting conversation. It was cool seeing how diverse all these projects are and how folks are working on things that we had no idea about and how we're working on stuff that they have no idea about, and it was really great. It felt like a good cross-pollination. +MIKE: Agreed. +LINDSEY: That's awesome to hear. Jordyn, any final thoughts? +JORDYN: [inaudible 26:58] out there listening and watching and want to join this community of founders [laughs], don't you want to have office hours with Chris and Mike? +LINDSEY: All right, thoughtbot.com/incubator. You can apply for session 1 of the 2024 incubator program. And yeah, you two, if you have more recommendations, referrals, definitely send them our way. Chris, Mike, Jordyn, thank you so much once again for joining and catching us up on all the exciting developments for Goodz. +MIKE: Thank you. +LINDSEY: A lot of really cool milestones. +JORDYN: I got to say, so much good stuff. And like, you know, just wrapping it all up almost diminishes the impact of any single one of those things that we just talked about, but it's, like, pretty amazing. People out there, apply to the incubator but also go buy yourself a Goodz mixtape. It's cool with playlists on it. +MIKE: It's a good point. +JORDYN: Give it to your BFF. Come on. +LINDSEY: Getthegoodz.com. +MIKE: Getthegoodz.com. Awesome. +LINDSEY: All right. Thanks, Chris and Mike. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Chris Cerrito, Jordyn Bonds, and Mike Rosenthal. + + + If you missed the other episodes with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can listen to the first episode and the second episode, and the third episode to catch up!

+ +
+ +

Lindsey Christensen and Jordyn Bonds catch up with the co-founders of Goodz, Chris Cerrito and Mike Rosenthal, where they share insights from their journey during the Incubator program, including the usefulness of the application process in aligning their vision and the challenges and benefits of user interviews and the importance of not overreacting to single user feedback and finding a balance in responding to diverse opinions. They reveal the varied reactions of users to Goodz's product, highlighting the different market segments interested in it.

+ +

As the Incubator program nears its end for Goodz, Chris and Mike reflect on their achievements and future plans. They've made significant progress, such as setting up an e-commerce site and conducting successful user interviews. The co-founders discuss their excitement about the potential of their product and the validation they received from users. Mike mentions the importance of focusing on B2B sales and the possibility of upcoming events like South by Southwest and Record Store Day.

+ +

Transcript:

+ +

LINDSEY: Thanks for being here. My name's Lindsey. I head up marketing at thoughtbot. If you haven't joined one of these before, we are checking in with two of the founders who are going through the thoughtbot Startup Incubator to learn how it's going, what's new, what challenges they're hitting, and what they're learning along the way.

+ +

If you're not familiar with thoughtbot, we're a product design and development consultancy, and we hope your team and your product become a success. And one way we do that is through our startup incubator.

+ +

So, today, we are joined by our co-founders, Mike Rosenthal and Chris Cerrito, Co-Founders of the startup Goodz. And we also have another special guest today, Danny Kim, from the thoughtbot side, Senior Product Manager at thoughtbot. So, I think, to start off, we'll head over to the new face, the new voice that we've got with us today. Danny, tell us a little bit about your role at thoughtbot and, specifically, the incubator.

+ +

DANNY: Yeah, sure. First of all, thanks for having me on, and thanks for letting me join in on all the fun. I'm one of the product managers at thoughtbot. I typically work for the Lift-Off team. We usually work with companies that are looking to, like, go into market with their first version MVP. They might have a product that exists and that they're already kind of doing well with, and they kind of want to jump into a new segment. We'll typically work with companies like that to kind of get them kicked off the ground.

+ +

But it's been really awesome being part of the incubator program. It's my first time in helping with the market validation side. Definitely also, like, learning a lot from this experience [laughs] for myself. Coming at it specifically from a PM perspective, there's, like, so much variation usually in product management across the industry, depending on, like, what stage of the product that you're working in. And so, I'm definitely feeling my fair share of impostor syndrome here.

+ +

But it's been really fun to stretch my brand and, like, approach problems from, like, a completely different perspective and also using different tools. But, you know, working with Mike and Chris makes it so much easier because they really make it feel like you're part of their team, and so that definitely goes a long way.

+ +

LINDSEY: It just goes to show everyone gets impostor syndrome sometimes [laughter], even senior product managers at thoughtbot [laughter]. Thanks for that intro. It's, you know, the thoughtbot team learns along the way, too, you know, especially if usually you're focused on a different stage of product development.

+ +

Mike, it's been only three weeks or a very long three weeks since last we checked in with you, kind of forever in startup time. So, I think the last time, we were just getting to know you two. And you were walking us through the concept, this merging of the digital and physical world of music, and how we interact with music keepsakes or merchandise. How's my pitch?

+ +

MIKE: Good. Great. You're killing it.

+ +

[laughter]

+ +

LINDSEY: And has anything major changed to that concept in the last three weeks?

+ +

MIKE: No. I mean, I can't believe it's only been three weeks. It feels like it's been a long time since we last talked. It's been an intense three weeks, for sure. No, it's been going really well. I mean, we launched all sorts of stuff. I'm trying to think of anything that's sort of fundamentally changed in terms of the plan itself or kind of our, yeah, what we've been working on. And I think we've pretty much stayed the course to sort of get to where we are now. But it's been really intensive.

+ +

I think also having sort of Thanksgiving in there, and we were kind of pushing to get something live right before the Thanksgiving break. And so, that week just felt, I mean, I was just dead by, you know, like, Thursday of Thanksgiving. I think we all were. So, it's been intense, I would say, is the short answer. And I'm happy, yeah, to get into kind of where things are at. But big picture, it's been an intense three weeks.

+ +

LINDSEY: That's cool. And when we talked, you were, you know, definitely getting into research and user interviews. Have those influenced any, you know, changes along the way in the plan?

+ +

MIKE: Yeah. They've been really helpful. You know, we'd never really done that before in any of the sort of past projects that we've worked on together. And so, I think just being able to, you know, read through some of those scripts and then sit through some of the interviews and just kind of hearing people's honest assessment of some things has been really interesting. I'm trying to think if it's materially affected anything.

+ +

I guess, you know, at first, we were, like, we kind of had some assumptions around, okay, let's try to find, like...adult gift-givers sounds like the wrong thing, adults who give gifts as, like, a persona. The idea that, like, you know, maybe you gift your siblings gifts, and then maybe this could be a good gift idea. And I think, you know, we had a hard time kind of finding people to talk in an interesting way about that. And I think we've kind of realized it's kind of a hard persona to kind of chop up and talk about, right, Chris? I don't know [crosstalk 04:55]

+ +

CHRIS: Well, it also seemed to, from my understanding of it, it seemed to, like, genuinely stress out the people who were being interviewed...

+ +

MIKE: [laughs]

+ +

CHRIS: Because it's kind of about a stressful topic [inaudible 05:03], you know, and, like, especially --

+ +

LINDSEY: Why? [laughs]

+ +

CHRIS: Well, I think, I don't know, now I'm making assumptions. Maybe because we're close to the holiday season, and that's a topic in the back of everybody's mind. But yeah, Danny, would you disagree with that? Those folks, from what we heard, seemed like they were the most difficult to kind of extract answers from. But then, if the subject changed and we treated them as a different persona, several of those interviews proved to be quite fruitful. So, it's just really interesting.

+ +

DANNY: Yeah. It really started, like, you kind of try to get some answers out of people, and there's, like, some level of people trying to please you to some extent. That's just, like, naturally, how it starts. And you just, like, keep trying to drill into the answers. And you just keep asking people like, "So, what kind of gifts do you give?" And they're just like, "Oh my goodness, like, I haven't thought about buying gifts for my sister in [laughs], like, you know, in forever. And now, like [laughs], I don't know where to go." And they get, like, pretty stressed out about it.

+ +

But then we just kind of started shifting into like, "All right, cool, never mind about that. Like, do you like listening to music?" And they're like, "Yes." And then it just kind of explodes from there. And they're like, "This last concert that I went to..." and all of this stuff. And it was much more fruitful kind of leaning more towards that, actually, yeah.

+ +

LINDSEY: That's fascinating. I guess that speaks to, especially at this stage and the speed and the amount of interviews you're doing, the need for being, like, really agile in those interviews, and then, like, really quickly applying what you're learning to making the next one even more valuable.

+ +

MIKE: Yeah. And I think, you know, like, we launched just a little sort of website experiment or, like, an e-commerce experiment right before Thanksgiving. And I think now, you know, we're able to sort of take some of those learnings from those interviews and apply them to both sort of our ad copy itself but also just different landing pages in different language on the different kind of versions of the site and see if we can find some resonance with some of these audience groups. So, it's been interesting.

+ +

LINDSEY: Are you still trying to figure out who that early adopter audience is, who that niche persona is?

+ +

MIKE: I think we --

+ +

CHRIS: Yes, we are. I think we have a good idea of who it is. And I think right now we're just trying to figure out really how to reach those people. That, I think, is the biggest challenge right now for us.

+ +

MIKE: Yeah. With the e-commerce experiment it was sort of a very specific niche thing that is a little bit adjacent to what I think we want to be doing longer term with Goodz. And so, it's weird. It's like, we're in a place we're like, oh, we really want to find the people that want this thing. But also, this thing isn't necessarily the thing that we think we're going to make longer term, so let's not worry too hard about finding them. You know what I mean? It's been an interesting sort of back and forth with that.

+ +

CHRIS: From the interviews that we conducted, you know, we identified three key personas. Most of them have come up, but I'll just relist them. There's the sibling gift giver. There was the merch buyers; these are people who go to concerts and buy merchandise, you know, T-shirts, albums, records, things along those lines to support the artists that they love. And then the final one that was identified we gave the title of the 'Proud Playlister'. And these are people who are really into their digital media platforms, love making playlists, and love sharing those playlists with their friends.

+ +

And that, I would say, the proud playlister is really the one that we have focused on in terms of the storefront that we launched, like, the product is pretty much specifically for them. But the lessons that we're learning while making this product and trying to get this into the hands of the proud playlisters will feed into kind of the merch buyers.

+ +

MIKE: Yeah. And I think that, you know, it's funny, like, this week is kind of a poignant week for this, right? Because it's the week that Spotify Wrapped launched, right? So, it's like, in the course of any given year, it's probably, like, the one week of the year that lots and lots and lots of people are thinking about playlists all of a sudden, so trying a little bit to see if we can ride that wave or just kind of dovetail with that a bit, too.

+ +

LINDSEY: Absolutely. And do you want to give just, like, the really quick reminder of what the product experience is like?

+ +

MIKE: Oh yeah [laughs], good call.

+ +

CHRIS: This is a prototype of it. It's called the Goodz Mixtape. Basically, the idea is that you purchase one of these from us. You give us a playlist URL. We program that URL onto the NFC chip that's embedded in the Good itself. And then when you scan this Good, that playlist will come up. So, it's a really great way of you make a playlist for somebody, and you want to gift it to them; this is a great way to do that. You have a special playlist, maybe between you and a friend or you and a partner. This is a good way to commemorate that playlist, turn it into a physical thing, give that digital file value and presence in the physical world.

+ +

LINDSEY: Great. Okay, so you casually mentioned this launch of an e-commerce store that happened last week.

+ +

MIKE: It didn't feel casual.

+ +

LINDSEY: Yeah. Why [laughter]...[inaudible 09:45] real casual. Why did you launch it? How's it going?

+ +

MIKE: I don't know. Why did we launch it? I mean, well, we wanted to be able to test some assumptions. I think, you know, we wanted to get the brand out there a little bit, get our website out there, kind of introduce the concept. You know, this is a very...not that we've invented this product category, but it is a pretty obscure product category, right? And so, there's a lot of sort of consumer education that I think that has to go on for people to wrap their heads around this and why they'd want this.

+ +

So, I think we wanted to start that process a little bit correctly, sort of in advance of a larger launch next year, and see if we could find some early community around this. You know, if we can find those core people who just absolutely love this, and connect with it, and go wild around it, then those are the people that we're going to be able to get a ton of information from and build for that persona, right? It's like, cool, these are the people who love this. Let's build more for them and go find other people like this. So, I think, for us, it was that.

+ +

And then, honestly, it was also just, you know, let's test our manufacturing and fulfillment and logistics capabilities, right? I mean, this is...as much as we are a B2B, you know, SaaS platform or that's what we envision the future of Goodz being, there is a physical component of this. And, you know, we do have that part basically done at this point. But we just, you know, what is it like to order 1,000 of these?

+ +

What is it like to put these in the mail to people and, you know, actually take orders? And just some of that processing because we do envision a more wholesale future where we're doing, you know, thousands or tens of thousands of this at a time. And so, I think we just want to button up and do some dry runs before we get to those kinds of numbers.

+ +

CHRIS: I think it also it's important to remember that we are talking in startup time. And while this last week seems like an eternity, it's been a week [laughs] that we've had this in place. So, we're just starting to learn these things, and we plan on continuing to do so.

+ +

MIKE: Yeah. But I think we thought that getting a website up would be a good way to just start kind of testing everything more.

+ +

LINDSEY: Great. Danny, what went into deciding what would be in this first version of the site and the e-commerce offering?

+ +

DANNY: I mean, a lot of it was kind of mostly driven by Chris and Mike. They kind of had a vision and an idea of what they wanted to sell. Obviously, from the user interviews, we were starting to hone in a little bit more and, like, we had some assumptions going into it. I think we ultimately did kind of feel like, yeah, I think, like, the playlisters seem to be, like, the target market. But just hearing it more and hearing more excitement from them was definitely just kind of like, yeah, I think we can double down on this piece.

+ +

But, ultimately, like, in terms of launching the e-commerce platform, and the storefront, and the website, like, just literally looking at the user journey and being like, how does a user get from getting onto a site, like, as soon as they land there to, like, finishing a purchase? And what points do they need? What are the key things that they need to think through and typically will run into? And a lot of it is just kind of reflecting on our own personal buyer behavior.

+ +

And, also, as we were getting closer to the launch, starting to work through some of those assumptions about buyer behavior. As we got there, we obviously had some prototypes. We had some screenshots that we were already working with. Like, the design team was already starting to build out some of the site. And so, we would just kind of show it to them, show it to our users, and just be like, hey, like, how do you expect to purchase this? Like, what's the next step that you expect to take? And we'd just kind of, like, continue to iterate on that piece. And so...

+ +

LINDSEY: Okay. So you were, before launching, even showing some of those mockups and starting to incorporate them in the user interviews.

+ +

DANNY: Yeah, yeah. I mean, we tried to get it in there in front of them as early as possible, partially because, like, at some point in the user interviews, like, you're mostly just trying to first understand, like, who are our target customers? Who are these people? And we have an assumption of or an idea of who we think they are. But really, like, once you start talking to people, you kind of are, like, okay, like, this thing that I thought maybe it wasn't so accurate, or, like, the way that they're kind of talking about these products doesn't 100% match what I originally walked into this, you know, experiment with. And so, we, like, start to hone in on that.

+ +

But after a certain point, you kind of get that idea and now you're just like, okay, you seem to be, like, the right person to talk to. And so, if I were to show you this thing, do you get it, right? Like, do you understand what's happening? Like, how to use this thing, what this product even does. And then also, like, does the checkout experience feel intuitive for you? Is it as simple as, like, I just want to buy a T-shirt? So, like, I'm just going to go by the T-shirt, pick a size, and, you know, move on with my life. Can we make it as seamless as that?

+ +

LINDSEY: And so, you mentioned it's only been a week since it's been live. Have you been able to learn anything from it yet? And how are you trying to drive people to it today?

+ +

MIKE: Yeah, I think we learned that sales is hard [laughs] and slow, and it takes some time. But it's good, and we're learning a lot. I mean, it's been a while since I've really dug deep in, like, the analytics and marketing kind of metrics. And so, we've got all the Google Tag Manager stuff, you know, hooked up and just, you know, connecting with just exploring, honestly, like the TikTok advertising platform, and the YouTube Pre-Rolls, and Shorts. And, like, a lot of stuff that I actually, since the last time I was heavily involved in this stuff, is just totally new and different.

+ +

And so, it's been super interesting to see the funnel and sort of see where people are getting in the site, where people are dropping off. You know, we had an interesting conversation in our thoughtbot sync yesterday or the day before, where we were seeing how, you know, we're getting lots of people to the front page and, actually, a good number of people to the product page, and, actually, like, you know, not the worst number of people to the cart. But then you were seeing really high cart abandonment rates.

+ +

And then, you know, when you start Googling, and you're like, oh, actually, everybody sees very high cart abandonment rates; that's just a thing. But we were seeing, like, the people were viewing their cart seven or eight times, and they were on there sort of five times as long as they were on any other page. And it's this problem that I think Danny is talking about where, you know, we need to actually get a playlist URL. This gets into the minutiae of what we're building, but basically like, we need to get them to give us a playlist URL in order to check out, right?

+ +

And so, you sort of have to, like, put yourself back in the mind of someone who's scrolling on Instagram, and they see this as an ad, and they click it, and they're like, oh, that thing was cool. Sure, I will buy one of those. And then it's like, no, actually, you need to, you know, leave this, go into a different app, find a play...like, it suddenly just puts a lot of the mental strain. But it's a lot. It's a cognitive load, greater than, as you said, just buying a T-shirt and telling what size you want.

+ +

So, thinking through ways to really trim that down, shore up the amount of time people are spending on a cart. All that stuff has been fascinating. And then just, like, the different demographic kind of work that we're using, all the social ads platforms to kind of identify has been really interesting. It's still early.

+ +

But, actually, like, Chris and I were just noticing...we were just talking right before this call. Like, we're actually starting to get, just in the last 12 hours, a bunch more, a bunch, but more people signing up to our email newsletter, probably in the last 12 hours that we have in the whole of last week. Yeah, I don't know, just even that sort of learning, it's like, oh, do people just need time with a thing, or they come back and they think about it?

+ +

CHRIS: Yeah. Could these people be working on their playlists? That's a question that I have.

+ +

MIKE: [chuckles] Yeah, me too.

+ +

CHRIS: It's like, you know, I'm making a playlist to drop into this product. It's really interesting. And I think it gives insight to kind of, you know, how personal this product could be, that this is something that takes effort on the part of the consumer because they're making something to give or to keep for themselves, which is, I think, really interesting but definitely hard, too.

+ +

DANNY: Yeah. And I also want to also clarify, like, Chris just kind of said it, like, especially for viewers and listeners, like, that's something that we've been hearing a lot from user interviews, too, right? Like, the language that they're using is, like, this is a thing that I care about. Like it's a representation of who I am. It's a representation of, like, the relationship that I have with this person that I'm going to be giving, you know, this gift to or this playlist to, specifically, like, people who feel, like, really passionate about these things. And, I mean, like, I did, too.

+ +

Like, when I was first trying to, like, date, my wife, like, I spent, like, hours, hours trying to pick the coolest songs that I thought, you know, were like, oh, like, she's going to think I'm so cool because, like, I listen to these, like, super low-key indie rock bands, and, like, you know, so many more hours than she probably spent listening to it. But that's [laughs] kind of, like, honestly, what we heard a lot in a lot of these interviews, so...

+ +

LINDSEY: Yeah, same. No, totally resonates. And I also went to the site this week, and I was like, oh damn, this is cool. Like, and immediately it was like, oh, you know, I've got these three, you know, music friends that we go to shows together. I'm like, oh, this would be so cool to get them, you know, playlists of, like, music we've seen together. So, you might see me in the cart. I won't abandon it.

+ +

MIKE: Please. I would love that.

+ +

CHRIS: Don't think about it too long if you could -- [laughter].

+ +

LINDSEY: I won't. I won't.

+ +

CHRIS: I mean, I would say I'm really excited about having the site not only as a vehicle for selling some of these things but also as a vehicle for just honing our message. It's like another tool that we have in our arsenal. During the user interviews themselves, we were talking in abstract terms, and now we have something concrete that we can bounce off people, which is, I think, going to be a huge boon to our toolset as we continue to refine and define this product.

+ +

MIKE: Yeah, that's a good point.

+ +

LINDSEY: Yeah. You mentioned that they're signing up for, like, email updates. Do you have something you're sending out? Or are you kind of just creating a list? Totally fine, just building a list.

+ +

MIKE: [laughs] No.

+ +

CHRIS: It's a picture of Mike and I giving a big thumbs up. That's, yeah. [laughter]

+ +

MIKE: No. But maybe...that was the thing; I was like, oh great, they're signing up. And I was like, gosh, they're signing up. Okay [laughter], now we got to write something. But we will.

+ +

LINDSEY: Tips to making your playlist [crosstalk 19:11] playing your playlist --

+ +

MIKE: Yeah [crosstalk 19:13].

+ +

CHRIS: Right. And then also...tips to making your playlists. Also, we're advancing on the collectible side of things, too. We are, hopefully, going to have two pilot programs in place, one with a major label and one with a major artist. And we're really excited about that.

+ +

LINDSEY: Okay. That's cool. I assume you can't tell us very much. What can you tell us?

+ +

MIKE: Yeah. We won't mention names [chuckles] in case it just goes away, as these things sometimes do. But yeah, there's a great band who's super excited about these, been around for a long time, some good name recognition, and a very loyal fan base. They want to do sort of a collection of these. I think maybe we showed the little...I can't remember if we showed the little crates that we make or not, but basically, [inaudible 19:52]

+ +

LINDSEY: The last time, yeah.

+ +

MIKE: So, they want to sell online a package that's, you know, five or six Goodz in a crate, which I think will be cool and a great sort of sales experiment. And then there's a couple of artists that we're going to do an experiment with that's through their label that's more about tour...basically, giving things away on tour. So, they're going to do some giveaway fan club street team-style experiments with some of these on the road.

+ +

So, first, it's ideal, provided both those things happen, because we definitely want to be exploring on the road and online stuff. And so, this kind of lets us do both at once and get some real learnings as to kind of how people...because we still don't know. We haven't really put these in people's hands yet. And it's just, like, are people scanning these a lot? Are they not? Is this sort of an object that's sitting on their shelf? Is it...yeah, it's just, like, there's so much we're going to learn once we get these into people's hands.

+ +

LINDSEY: Do you have the infrastructure to sort of see how many times the cards are scanned?

+ +

CHRIS: Mm-hmm. Yep, we do.

+ +

MIKE: Yeah. So, we can see how many times each one is scanned, where they're scanned, that sort of thing.

+ +

CHRIS: Kind of our next step, and something we were just talking about today with the thoughtbot team, is building out kind of what the backend will be for this, both for users and also for labels and artists. That it will allow them to go in and post updates to the Goodz, to allow them to use these for promotion as people, you know, scan into them to give them links to other sites related to the artists that they might be interested in before they move on to the actual musical playlist. So, that's kind of the next step for us. And knowing how users use these collectibles, both the kind of consumer Good and the artist collectibles that we were just talking about, will help inform how we build that platform.

+ +

LINDSEY: Very cool. And right now, the online store itself that's built in Shopify?

+ +

MIKE: Yeah. The homepage is Webflow that Kevin from the thoughtbot team really spearheaded in building for us. And then, yeah, the e-commerce is Shopify.

+ +

LINDSEY: Y'all have been busy.

+ +

MIKE: [laughs]

+ +

LINDSEY: Is there anything else maybe that I haven't asked about yet that we should touch on in terms of updates or things going on with the product?

+ +

MIKE: I don't know. I don't think so. I think, like Chris said, I mean, we're just...like, now that the site has kind of stood up and we're really switched over to kind of marketing and advertising on that, definitely digging into the backend of this kind of SaaS platform that's going to probably be a big focus for the rest of the, you know, the program, to be honest. Yeah, just some other things we can do on the next front that could eventually build into the backend that I think can be interesting. No, I guess [laughs] the short answer is no, nothing, like, substantial. Those are the big [crosstalk 22:26]

+ +

LINDSEY: Yeah. Well, that was my next question, too, which is kind of like, what's next, or what's the next chunk of work? So, it's obviously lots more optimization and learning on the e-commerce platform, and then this other mega area, which is, you know, what does this look like as a SaaS solution? What's the vision? But also, where do we start? Which I'm sure, Danny, is a lot of work that you specialize in as far as, like, scoping how to approach these kinds of projects.

+ +

DANNY: Yeah. And it's interesting because, I mean, we were just talking about this today. Like, part of it is, like, we can, like, really dig into, like, the e-commerce site and, like, really nailing it down to get it to the place where it's like, we're driving tons more traffic and also getting as low of a, like, cart abandonment rate as possible, right? But also, considering the fact that this is in the future, like, large-scale vision.

+ +

And there's, like, also, like, we're starting to, I think, now iron out a lot of those, like, milestones where we're kind of like, okay, like, we got, like, a short-term vision, which is, like, the e-commerce site. We got a mid-term vision and a potential long-term vision. How do we validate this long-term vision while also still like, keeping this short-term vision moving forward?

+ +

And, like, this mid-term vision is also going to, like, help potentially, either, like, steer us towards that long-term or maybe even, like, pivot us, like, into a completely different direction. So, like, where do you put your card, right? Like, how much energy and time do we put into, like, each of these areas? And that's kind of, like, the interesting part of this is starting to talk through that, starting to kind of prioritize, like, how we can maximize on our effort, like, our development and design effort so that things just kind of line up more naturally and organically for our future visioning, so...

+ +

MIKE: Yeah. A lot of different things to juggle. I saw there was a question. Somebody asked what the URL is, but I don't seem to be able to [crosstalk 24:10].

+ +

LINDSEY: The same question as me. We got to drop the link for this thing.

+ +

MIKE: Yeah, getthegoodz.com.

+ +

CHRIS: That's G-O-O-D-Z.

+ +

LINDSEY: Get in there, folks

+ +

MIKE: Yeah, get [crosstalk 24:23].

+ +

LINDSEY: And let us know how it goes.

+ +

MIKE: Yeah, please [laughs]. Any bugs? Let us know. Yeah. I think that those...yeah, I mean, it's a good point, Danny, in terms of juggling kind of the near-term and longer-term stuff. You know, it's a good kind of reminder our big focus, you know, in the new year is going to be fundraising, right? We're already talking to some investors and things like that.

+ +

So, it's like, okay, yes, as you said, we could tweak the cart. We could tweak the e-commerce. Or, like, can we paint the big picture of what the longer-term version of this company is going to be in a way that makes it compelling for investment to come in so that there can be a long-term version of this company? And then we can build those things. So yeah, it's definitely a balance between the two.

+ +

LINDSEY: Oh, also, just casual fundraising as well.

+ +

[crosstalk 25:06]

+ +

MIKE: Yeah, yeah.

+ +

LINDSEY: [laughs]

+ +

MIKE: But it's hard. It's like, you wake up in the morning. It's like, do I want to, like, write cold emails to investors? Or do I want to, like, look at Google Analytics and, like, tweak ad copy? That's actually more fun. So, yes.

+ +

LINDSEY: Yeah, life of the founder, for sure. All right. So, that's getthegoodz (Goodz with a z) .com. Check it out. We'll tune in and see what happens with the e-commerce site, what happens with the SaaS planning the next time that we check in.

+ +

But Chris, Mike, Danny, thank you so much for joining today and sharing what's been going on over the last few weeks: the good, the bad, the challenge, the cart abandonment. And, you know, best of luck to you over the next few weeks, and we'll be sure to check in and see how it's going.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

+ +

Transcript:

+ +

 LINDSEY: Thank you to our viewers and listeners. We are catching up once again with one of the startups going through the thoughtbot Incubator. My name is Lindsey Christensen. I'm joined today by Jordyn Bonds, who heads up the thoughtbot incubator, as well as our Co-Founders of Goodz, Chris Cerrito and Mike Rosenthal. Welcome, everybody.

+ +

MIKE: Thanks, Lindsey.

+ +

LINDSEY: Before we get started, before we put Chris and Mike back in the hot seat, at the top here, Jordyn, we have a special announcement for our viewers and listeners.

+ +

JORDYN: Application window is open for session 1 of 2024, folks. You can go to thoughtbot.com/incubator and apply. And Chris and Mike can tell you how easy or hard applying was.

+ +

MIKE: It was easy. It was totally easy. It's a very straightforward process.

+ +

CHRIS: Yeah, it was way more straightforward than a lot of applications that we've dealt with in the past, for sure.

+ +

JORDYN: Ha-ha. And if you've got a business idea that involves software but you haven't gotten anything out there yet, come talk to us. We will help you make sure that it's a good idea and that there are people who might buy it, and maybe get you even a little further than that.

+ +

MIKE: We actually have a friend who's considering applying. I'll tell him applications are open. He's worried his idea is not big enough to actually be a business idea, so we'll see.

+ +

CHRIS: Even the process of doing the application was really helpful for us because it helped us get aligned on exactly what we were doing, yeah.

+ +

JORDYN: I love that. And I found that to be true when I was a founder applying to some of these things, in particular, applying for an SBIR grant was one of the most challenging things that we did, but it was so productive. I was so annoyed by it at the time, and then I cribbed from that thing. It actually sort of forced us to make a business plan [laughs], and then, basically, we ran it, and it was great [laughs].

+ +

CHRIS: Yeah. I think that was, for us, that was our point where we were like, "Is this idea fleshed out enough to move forward?" And we were like, "Yes, it is. Let's go. Let's do this."

+ +

JORDYN: So, use the application as a forcing function, everybody. It will help you clarify your thinking.

+ +

LINDSEY: Yeah. Jordyn, what would you say to Mike's friend who's questioning if their idea is big enough? How do you respond to that sentiment?

+ +

JORDYN: That is a fascinating sentiment because I feel like so much more often, I am trying to help founders with the opposite problem where they think this thing is so big that they are not thinking about what step 1 is going to look like. They're just, like, in 10 years, we're going to be the next Amazon, and I'm like, "Maybe [laughter]. Let me help you figure out how to get to that giant vision." So, I don't come across the "Is this big enough to be a business?" question as often. And, I don't know, what would I say? I guess I need the details.

+ +

LINDSEY: It could be a perfect fit

+ +

MIKE: It could be.

+ +

JORDYN: It could be a perfect fit.

+ +

LINDSEY: In a way, that's what you're answering, right?

+ +

MIKE: Right.

+ +

LINDSEY: In some of this work.

+ +

MIKE: That is true. So, yeah, you guys would certainly...just thinking through the process we've gone through the last two months, it would definitely help them flesh that out.

+ +

LINDSEY: Which is a great segue.

+ +

MIKE: Great segue.

+ +

LINDSEY: Chris and Mike, we're actually coming up to the end of your incubator time.

+ +

CHRIS: It's so sad.

+ +

LINDSEY: Can you believe it?

+ +

MIKE: It's gone by really fast. I mean, eight weeks is not a long time, but it has gone by very, very fast.

+ +

CHRIS: It felt like a very long time in the middle of it.

+ +

MIKE: [laughs]

+ +

CHRIS: But now that it's over, it feels like a blink that it's coming to a close.

+ +

MIKE: I don't know. It's funny. I think we had some note in our retro today that was like, maybe the very end of the year is not the best time to do an accelerator just because you have, like, the holidays kind of jumping in here in the end. So, that might have helped make it feel like a... I feel like the end of the year always feels like a rush anyway. So, I think just life gets a little bit busier this time of year, too, but yeah.

+ +

CHRIS: Yeah, my gingerbread man decorating game is, like, really down this season because we've been so busy. Tragic.

+ +

LINDSEY: Chris, can you remind our viewers and listeners who might not be familiar what was the idea that you and Mike have been exploring with the incubator or, like, what did you come in with?

+ +

CHRIS: So, with Goodz, what we're trying to do is make little, physical collectibles objects that connect back to the digital content that a user loves. The idea being that today, we are awash in these digital files, links, so many things on our desktops, on our phones, on our devices, and it's really hard to tell which part of those are really, really important to us. So, by giving them a presence in the physical world, that denotes that's something that's really important, worth keeping, worth sharing, and showing off to your friends and family.

+ +

And to start this off, mostly because Mike and I are both kind of music nerds, we're starting off with a music focus, but at some point, we're hoping to move into other realms, too.

+ +

LINDSEY: And a lot of the incubator, as repeat listeners will know, is focused on really kind of evolving user interviews all the way through and narrowing in on, you know, a core audience, a core market. Mike, how has that evolution been? I think the last time we chatted was around three weeks ago. What has the latest iteration of user interviews looked like in terms of the people you're talking to and even what you're asking them?

+ +

MIKE: It's been a really fascinating process. I mean, I'm trying to think of where we were exactly the last time we talked to you, but I think we'd probably just launched the e-commerce site that we had been experimenting with putting up.

+ +

LINDSEY: Yeah, exactly.

+ +

MIKE: And so, and we really then started cranking on user interviews kind of once that was live. And so, moving away from the conceptual and more into like, "Okay, share your screen. Here's the link. Like, tell me what you think is going on here," and really sort of getting users who had never, you know, never heard our pitch, never been involved with us to sort of try to wrap their heads around what we are and what we're doing just based on that website and trying to sort of make iterative changes based on that.

+ +

You know, for me, because I had not done user interviews very much in the past, like, it's very tempting, like, you get sort of 1 note from 1 person in 1 interview, and you're like, oh, we need to change this word. That word didn't make any sense to them, or this thing needs to be blue instead of pink. I think, for me, it was like, all right, how do we kind of synthesize this data in a responsible way?

+ +

And it emerged naturally, which, I mean, Jordyn and all thoughtbot folks said that it would, but you sort of started hearing the same things again and again. And we never really got to a place where, like, you heard the exact same things from everyone. But there were enough buckets, I feel like, where we're like, okay, like, this part really isn't making that much sense to people, or, like, we do really need to, you know, structure this differently to convey.

+ +

So, it was a bunch of that kind of work over the last three weeks or so and sort of just getting a sense of like, are we conveying our message? It's hard. I mean, it's a new, like, we're not the only people making physical products with NFC chips in them, but it is not the most common, like, product. Like, it is kind of a new category out there. And so, really trying to understand just right off the bat, do people get it? And you get wildly different answers [laughs] as to whether they get it or they don't, which has been fascinating, too.

+ +

JORDYN: Yeah. [crosstalk 7:12]

+ +

LINDSEY: Chris or Jordyn, anything to add there?

+ +

JORDYN: Yeah. You get the best, like, bootcamp in the don't overreact to a single user interview experience in some ways because we [laughs]...it would literally be like, interview in the morning someone says this thing. Interview in the afternoon, someone says the exact opposite thing [laughter]. And you're like, okay [laughs], like, which one of these things are we going to respond to, if either of them?

+ +

CHRIS: Yeah. It's hard. As somebody with, like, a strong desire to please, it's hard to reign yourself in and want to change things immediately, but it definitely makes sense to do so in the long run.

+ +

MIKE: But yeah, but, I mean, like I said, I do feel like it kind of came down to buckets. It's like, okay, you're that. I can, like, categorize you with all those other people and you with all those other people. And yeah, I hear you. I'm like, yeah, it's tempting to want to please them all.

+ +

But I think with this one, we're fighting hard to be like...or we sort of have a philosophy that this product is emphatically not for everyone because, at the end of the day, you get a lot of people who are like, "Wait, you're just putting a link to a streaming playlist on a physical object? Why don't I just text someone the link?" And sometimes that breaks down by age group, like, 18-year-olds being like, "What are you talking about, old man?

+ +

LINDSEY: [laughs]

+ +

MIKE: Like, why the hell would I do that? It makes no sense." But it sort of skews all over the age ranges. But then there'll be other people who are 18 or 20 years old who are like, "Wow, I never had cassettes when I was growing up," or "I never got to make, you know, mixtapes or CD-Rs for people." And like, you know, so it's, yeah, it's about finding the people who are the early adopters. As Jordyn has said a lot, it's like, we need to find those early adopters and, like, make them love us, and then other people will come later.

+ +

CHRIS: I mean, some of the most gratifying moments, I think, are there's been some interviews where people have been so excited that after the interview, they've gone and purchased our products, which is just, like, the coolest feeling ever.

+ +

LINDSEY: Wow.

+ +

MIKE: Yeah, it's pretty cool.

+ +

LINDSEY: Are you open to sharing a little bit more about what those buckets or what those segments look like?

+ +

CHRIS: I mean, I think there's folks who outright just get it almost immediately, and I think those people tend to be hardcore music collectors, hardcore music fans, Jordyn and Mike, please feel free to jump in if you disagree with any of this. They just get it right off the bat.

+ +

Then I think there's, in my experience, there's another bucket of people who are a little more hesitant, and maybe they wouldn't buy it, but they seemed really excited about the idea of getting one as a gift, which is really interesting. They're like, "I don't know if I'd buy this, but I'd really like to have one." And then there is another segment, like, which Mike just mentioned, of folks who just don't see the value in this whatsoever, which is totally fair.

+ +

MIKE: Yeah, totally. I think it's also...I see it almost as, like, a matrix. There's, like, desirability, and, like, technical understanding because people were like, "I technically understand what this is, and I do not want it in my life." Or like, "I get what this is and, oh my God, I have to have that," or like, "I don't really understand what you're talking about, but, man, I love physical stuff. Like, sure I want..." you know, it's like, it goes across those two planes, I think.

+ +

JORDYN: I will say that it, I think you alluded to this before, Mike, but, like, we're going to run a whole analysis of...because we did a ton of interviews, and we haven't actually done that, like, sort of data-driven thing of like, are there trends in the demographics somewhere that we're not getting? Because the pattern has not been there. Like, someone will talk to an 18-year-old, you know, at 1:00 p.m. who is just, like, "Why on earth would I ever want this?" And then I, like, you know, will talk to a 21-year-old who is like, "I love this."

+ +

And it's like, why? Like, this is the answer. The thing we're trying to get out now is, like, what is the difference between those two people? It's not a demographic thing that we can see from the outside, so what is it instead? But with consumer stuff like this, often, you don't necessarily...you don't need that in such great detail when you're starting. You just kind of, like, throw it out there and see who grabs it, and then you start to build sort of cohorts around that.

+ +

And that is kind of what these interviews have shown us is that there are people who will grab it, and that was part of what we were trying to validate. Are there people who Mike and Chris do not know personally who will, like, get this and be psyched about it immediately? And that is, you know, check unequivocally true. Like Chris said, there are people that we were, you know, that we had recruited on this user interviews platform [chuckles] who then just turned around and bought the product because they were so psyched about it. One of the guys I interviewed was like, "Can I invest in your company right now?" Like, during the interview, and I was like, "Maybe?" [laughs]

+ +

CHRIS: There was, like, another person who wanted to work for us immediately...

+ +

JORDYN: Yes, great.

+ +

CHRIS: Which was really interesting and kind of awesome.

+ +

JORDYN: Yeah, they're like, "Are you hiring?" You're just like, okay. So, it's validating that there are people all over that spectrum. Like, where those trends lie, though, which is, I think, what you were asking, Lindsey, not as straightforward and in a fascinating way. So, we still have a little more, like, number crunching to do on that, and we may have an answer for you later.

+ +

LINDSEY: That's exciting. Exactly. I'm curious: what are the connecting dots between the folks who are really into it, and how might that impact how you approach the business?

+ +

MIKE: Yeah, it's hard. It's definitely going to be a niche to start. And so, we got to figure out kind of got to crack the code on how we find those people.

+ +

LINDSEY: And, Mike, I think you had also mentioned last time that, you know, you or both of you have a network kind of in the music industry, and you've been floating the idea past some people there. Have you been having more of those conversations over the last few weeks, too?

+ +

MIKE: We have, yeah. Well, so yeah, we've had a couple more just kind of straight-up pitch calls versus like, "Hey, there's this cool thing we're doing," and having those people be like, "Cool. Let's do a pilot." And so, they're ordering, you know, 500 or 1,000 units at a time, which is rad.

+ +

LINDSEY: Whoa.

+ +

MIKE: For the first...yeah.

+ +

LINDSEY: Okay, very cool.

+ +

MIKE: Yeah. The first two or three of those should happen in January or maybe early February, but yeah, those are done and in production and arriving soon. So, that's really exciting with some cool bands. We won't say the names in case it doesn't [laughs] work out, but it does look like it's going to work out.

+ +

LINDSEY: And so, it's specific bands that are creating merch for their fans.

+ +

MIKE: Yeah, yeah. So, we're working with one artist manager on a band that he manages, and then we're working with a record label. And they're going to try with a couple of smaller artists. And so, yeah, it's actually really good for us. One is going to be straight-up sales, most likely, and it's, like, selling these things. And the other ones will be given away as kind of promo items on tour artists, which is also a really interesting use case for us, too, that we're excited about and using them as a way to sort of get email addresses and, like, fans engaged and stuff, so...

+ +

And then yeah, then I had another conversation, and they want to talk about doing some pilots. So far, like, that side of things is going great. We're sort of 3 for 4 in terms of initial calls leading to pilots right off the bat, which is kind of unheard of from [laughs] my experience.

+ +

LINDSEY: Yeah, I'd say so. No, a lot of very good signals.

+ +

MIKE: Really good signals. But then we were able to turn some of those into user interview conversations, actually, as well over the course of the last couple of weeks, which has been really helpful, like, talking to manager and label-type people about what they might want out of a software product that is associated with this because we're not just thinking about making physical products but sort of coupling that with an online toolset. And that part, we haven't gotten as far along as we did with the direct-to-consumer e-commerce, but it's been fascinating.

+ +

LINDSEY: So, what has been happening with the online shop? As you noted the last time we talked, it was just a baby less than a week-old Shopify site getting, you know, some first hits of people going around maybe putting things in their basket. I'm sure a lot has happened over the last few weeks. What kind of work, what kind of insights have you seen around the site?

+ +

CHRIS: We've been, I mean, we've been selling stuff at a slow but steady pace. It's been great because it's enough to, you know, because our product really straddles the line between physical and digital; there's a lot of physical aspects to this that we need to figure out and kind of the level of orders that we've been getting have been really...it's, like, the perfect number to think about fulfillment issues, things like what kind of package does this go in? How do we mail this out? Things along those lines, just very basic, practical questions that needed to be answered.

+ +

But yeah, it's been great. We actually, I mean, we hit our goal for the amount of these that we wanted to get in people's hands before Christmas, which is pretty awesome. And we continue now with the lessons learned. I think our plan is to try and make a push for Valentine's Day because these seem like they would be a great Valentine's Day present: make a playlist; share it with your loved one; share it with a friend; share it with somebody you don't like at all. Who knows?

+ +

LINDSEY: [laughs]

+ +

CHRIS: But yeah, that's kind of our next sales push, we think.

+ +

LINDSEY: The hate playlist.

+ +

CHRIS: [inaudible 15:40] hate playlist.

+ +

MIKE: Yeah, perfect. Real passive-aggressive.

+ +

CHRIS: Just Blue Monday, like, by New Order, like, 14 times.

+ +

LINDSEY: [laughs] Yeah, every song is just like a sub-tweet...

+ +

MIKE: [laughs]

+ +

LINDSEY: About something they've done and [inaudible 15:53] Have you updated the site? Like, how do you decide what gets updated on the site? [laughter] Everyone laughed.

+ +

MIKE: It was a little haphazard, I would say, there for a minute. But --

+ +

CHRIS: We got the site up very, very quickly. And from my perspective, I've been dealing a lot with the physical side of things, just getting great product photos up there, which is, like, something that thoughtbot has actually been super helpful with. You know, everybody on the team is starting to submit photos of their Goodz in the real world and using their Goodz, which is great.

+ +

And we continued to update the site with that but also making sure our text made sense, refining copy in response to things that people said during user interviews. The checkout process, the process of adding the URL that we point the Good to that, we did a bunch of experimentation there based on what people were saying during user interviews. So, it has been a little haphazard, but we have made a bunch of changes.

+ +

LINDSEY: Jordyn, has there been any experiment, like, structured experimentation around the site or how you're getting people to the site?

+ +

JORDYN: Mike actually did a little bit of ad funnel work that I don't think we've, like, even remotely scratched the surface of. So, I wish I could say that was conclusive, but I think we've found a little bit more...here are plenty of sales that are from people that nobody here knows.

+ +

MIKE: True.

+ +

JORDYN: So, people are finding out about this somehow [laughs]. But I think it's a little bit, like, word-of-mouth sort of chain of events is our sense so far. I wanted to say, though, about the site, we did get what Chris was saying about, like, this experiment was, in part, about fulfillment and figuring out how fulfillment would work and packaging, and not just messaging and not just closing the sale with consumers, but also, just, like, how do you fulfill these?

+ +

But one of the really fun things we've managed to do in the last, since we talked last time, which I can't even believe...I feel like this wasn't even a gleam in our eyes for this project, but we managed to get out, like, stood up and out the door, and working in production in the last few weeks is a way for folks to actually assign the URL to their mixtape themselves. Previously, the plan had just been for Chris and Mike to do that, which is fine but a little bit unscalable, right?

+ +

CHRIS: That was a huge dream or, like, that was high on our wish list. And we didn't think we'd get to it. And it's been pretty amazing that we have, yeah.

+ +

JORDYN: Yeah, so that was one thing that is an update to the site. So, then we had to do a little bit of, like, micro iterating, on, like, the messaging around that. Like, how do you communicate to people? This is, like, a little bit of an abstract challenge, right? Like, here's this object. It's going to point to a digital thing. How do you tell the physical object which digital thing it's pointing to [laughs]?

+ +

So, a lot of our recent interviewing has been to sort of get inside the mind of the consumer about how they're thinking about that and how we can best communicate that to them. So that's been a lot of the, like, recent iteration is getting that mechanism stood up and then the messaging around it.

+ +

CHRIS: It's also really cool because it adds to the utility of the object itself in the sense that now our Goodz, when a user gets one, they can add a URL to their Good themselves, but they can also change that URL. So, it's much more malleable.

+ +

JORDYN: Which is something that in one of our early user interviews was, like, a hot request [laughs], and we were like, "Someday, someday." And it's, you know, I should actually go back to her and be like, "Someday is today."

+ +

[laughter]

+ +

MIKE: Well, yeah, and just as Chris was saying, it just makes it so much easier to ship these out without having to manually load them, and you could sell them, and yeah, retail outlets, like, it just opens up a lot of opportunities for us for them.

+ +

LINDSEY: And Mike mentioned that some of the, like, kind of future looking aspirations for the solution are, you know, how might you figure out the B2B, like, SaaS aspect of it? Jordyn, is that something that's been explored at all at this point, or is it early?

+ +

JORDYN: That experiment I just described is actually sort of the link between the two projects. It sort of proves the concept and proves the value in some ways, and it has given us a little bit more visibility into sort of how we're going to execute some of this technical stuff. Like, how easy, how difficult is it going to be? These little experiments all build your confidence around your ability to do those things and what it's going to look like. And so, this experiment absolutely feeds into that question.

+ +

But I would say it was really this week where we got to have a really fun brainstorming sort of blue sky conversation about that that I don't think would have been nearly as both creative and blue sky or rooted in reality as it was if we hadn't done these experiments and hadn't talked to so many...we had so much work...we could participate in a conversation like that so much more confidently and creatively because all of us had a lot more shared context.

+ +

So, we really got to dream big, like, what is a SaaS platform built around these physical objects? And I don't want to, you know, I'm not going to give it away at this moment because we had a lot of, like, really cool ideas. It's one part talking to the B2B customer, which, you know, you mentioned earlier, getting what their pain points are, and what they're looking for, what they need, but then also dreaming big about now we understand the technology a little bit more and how it feels to use it. What does that unlock in our brains?

+ +

The analogy I used in that conversation and that I use all the time is like, the users of Twitter invented hashtags, right? Twitter did not invent hashtags. And so, hey, everybody out there, newsflash: users invented hashtags, not Twitter or something else, if you didn't realize that Twitter was where those things kind of emerged. But there was just a user behavior that was happening in the wild, and Twitter was just very good at making that easier for them, looking at that and being like, "Oh, hey, is this a thing you all want to do? Here, we'll make that even more useful for you." And it was part of Twitter's early success that they were able to do that.

+ +

And so, that was the kind of thinking we were trying to employ here is, like, now that we have these objects and we understand a little bit more how it feels to use them, you get these second order effects. What does that then make us think of? What is then possible to us that we wouldn't have been able to dream of previously because we didn't quite get it? So, that was really happening this week.

+ +

LINDSEY: So, as the incubator time wraps up, what are the kind of final activities or deliverables, one, that Goodz wants and you know that they're going to get? What are the parting gifts as we send you out into the next phase?

+ +

MIKE: Yeah, well, loads of stuff. I mean, we're getting all that code that [SP] Guillermo and the guys worked on to let people set their own playlist settings. And we've got that up in a GitHub repository now. And we've got a bunch of great design work that's all being handed over, like Chris was saying, product shots that a bunch of the team members were taking, synthesizing all the user interviews. We're actually sort of making some kind of final reports on those, so it's kind of more usable, actionable data for us. The whole website, you know, that didn't exist before. And that will sort of continue to grow as the entire website for Goodz moving forward. I don't know. That's a lot. What else was there, Chris?

+ +

CHRIS: As a result of all that, I mean, one of the things I'm most excited about is now we have a small user base who actually has the physical products that, hopefully, we can get them to answer questions. That's huge for what's coming next. Starting the path towards the SaaS platform, too, it's really helped narrow our scope and think about, you know, how to make that successful or if it will be successful.

+ +

LINDSEY: Yeah, that sounded like a big discussion this week that I know has been on your minds from the beginning. Wait, the last time, also, you said you were starting to get emails, too. Have you emailed anyone yet, or are you still holding on to them?

+ +

MIKE: Oh. No, I still haven't sent a newsletter out [laughs], actually, but we have Mailchimp set up. Yeah, no, we've got a good kind of core of our, yeah, early folks on there. We'll start getting a newsletter out with some sort of regularity. We're building up the socials very slowly just focusing on Instagram mostly right now and trying to get back into that game.

+ +

It's been a long time since I've had to do kind of social marketing stuff. And so, it's a lot of work, as it turns out, but we'll get all that cooking. I think this was just such a sprint, working with the thoughtbot folks and trying to get all this stuff done. Before the end of the year, now we can sort of take a breath and start engaging folks in the new year.

+ +

LINDSEY: Yeah. Well, so, do you know what you want to do next or what the next phase looks like? Are you going to do fundraising?

+ +

MIKE: We're certainly going to continue to have some fundraising conversations. We've had some conversations emerge over the last, you know, since we've been in thoughtbot, again, not the greatest time of year to try to be raising a round. But we're also not, like, desperately, urgently needing to do that right this second. I think, you know, part of it is the fundraising landscape, you know, doesn't look amazing. And we're still sort of building out a lot of traction, and sort of every week, there's some new, exciting thing, or we've got some new, big artists who wants to do something.

+ +

So, I think, in some ways, to the extent that we can bootstrap for a little while, I think we will, yeah. So, we will focus on...I'd like to get back to focusing on, like, B2B sales. I'd like to hit the ground in January and just start talking to a bunch of music industry folks.

+ +

And thinking ahead a little bit, sort of Q1 and Q2, like, what are the big tentpole events? You know, you got South by Southwest coming up in March. You got Record Store Day in April, or whenever it is. But, you know, there's, like, a bunch of those sorts of things that it's like, oh, let's not let those things suddenly be tomorrow. Like, right now, they're all still two or three/four months out. Like, let's make sure we're queued up for those things and see what happens.

+ +

And Jordyn has been giving really good advice on the fundraising side where it's just like, just keep getting cool stuff like that and just do almost like little drip campaigns with funders who aren't maybe giving you the time of day or think it's too early, and just kind of keep going back to them. Like, the best excuse to go back to funders is like, "Hey, we just closed this new thing. We just launched this new thing. We just got this thing working. Hey, we're launching with this major band," Like, enough of those happen, and I think the fundraising will happen more organically. It's a strategy.

+ +

CHRIS: I think we're really lucky in the fact that, you know, now, at this point, we're not talking about vapourware, you know, like, these are actual things that actually exist that, like, anybody could go onto our site right now and buy, which is awesome. And because of that, the product's going to continue to evolve, and, hopefully, our sales record will continue to evolve, too.

+ +

LINDSEY: Amazing. Well, that feels like a good place to wrap up, maybe. Are you going to hang around in our incubator Slack, the thoughtbot incubator Slack for all our past founders?

+ +

MIKE: Yes. Emphatically, yes.

+ +

LINDSEY: Okay. We're holding you to it then [laughs].

+ +

CHRIS: I'm excited about that. We met with the other founders yesterday for the first time, and it was a really great and interesting conversation. It was cool seeing how diverse all these projects are and how folks are working on things that we had no idea about and how we're working on stuff that they have no idea about, and it was really great. It felt like a good cross-pollination.

+ +

MIKE: Agreed.

+ +

LINDSEY: That's awesome to hear. Jordyn, any final thoughts?

+ +

JORDYN: [inaudible 26:58] out there listening and watching and want to join this community of founders [laughs], don't you want to have office hours with Chris and Mike?

+ +

LINDSEY: All right, thoughtbot.com/incubator. You can apply for session 1 of the 2024 incubator program. And yeah, you two, if you have more recommendations, referrals, definitely send them our way. Chris, Mike, Jordyn, thank you so much once again for joining and catching us up on all the exciting developments for Goodz.

+ +

MIKE: Thank you.

+ +

LINDSEY: A lot of really cool milestones.

+ +

JORDYN: I got to say, so much good stuff. And like, you know, just wrapping it all up almost diminishes the impact of any single one of those things that we just talked about, but it's, like, pretty amazing. People out there, apply to the incubator but also go buy yourself a Goodz mixtape. It's cool with playlists on it.

+ +

MIKE: It's a good point.

+ +

JORDYN: Give it to your BFF. Come on.

+ +

LINDSEY: Getthegoodz.com.

+ +

MIKE: Getthegoodz.com. Awesome.

+ +

LINDSEY: All right. Thanks, Chris and Mike.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Chris Cerrito, Jordyn Bonds, and Mike Rosenthal.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + If you missed the other episodes with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can listen to the first episode and the second episode, and the third episode to catch up!

+ +
+ +

Lindsey Christensen and Jordyn Bonds catch up with the co-founders of Goodz, Chris Cerrito and Mike Rosenthal, where they share insights from their journey during the Incubator program, including the usefulness of the application process in aligning their vision and the challenges and benefits of user interviews and the importance of not overreacting to single user feedback and finding a balance in responding to diverse opinions. They reveal the varied reactions of users to Goodz's product, highlighting the different market segments interested in it.

+ +

As the Incubator program nears its end for Goodz, Chris and Mike reflect on their achievements and future plans. They've made significant progress, such as setting up an e-commerce site and conducting successful user interviews. The co-founders discuss their excitement about the potential of their product and the validation they received from users. Mike mentions the importance of focusing on B2B sales and the possibility of upcoming events like South by Southwest and Record Store Day.

+ +

Transcript:

+ +

LINDSEY: Thanks for being here. My name's Lindsey. I head up marketing at thoughtbot. If you haven't joined one of these before, we are checking in with two of the founders who are going through the thoughtbot Startup Incubator to learn how it's going, what's new, what challenges they're hitting, and what they're learning along the way.

+ +

If you're not familiar with thoughtbot, we're a product design and development consultancy, and we hope your team and your product become a success. And one way we do that is through our startup incubator.

+ +

So, today, we are joined by our co-founders, Mike Rosenthal and Chris Cerrito, Co-Founders of the startup Goodz. And we also have another special guest today, Danny Kim, from the thoughtbot side, Senior Product Manager at thoughtbot. So, I think, to start off, we'll head over to the new face, the new voice that we've got with us today. Danny, tell us a little bit about your role at thoughtbot and, specifically, the incubator.

+ +

DANNY: Yeah, sure. First of all, thanks for having me on, and thanks for letting me join in on all the fun. I'm one of the product managers at thoughtbot. I typically work for the Lift-Off team. We usually work with companies that are looking to, like, go into market with their first version MVP. They might have a product that exists and that they're already kind of doing well with, and they kind of want to jump into a new segment. We'll typically work with companies like that to kind of get them kicked off the ground.

+ +

But it's been really awesome being part of the incubator program. It's my first time in helping with the market validation side. Definitely also, like, learning a lot from this experience [laughs] for myself. Coming at it specifically from a PM perspective, there's, like, so much variation usually in product management across the industry, depending on, like, what stage of the product that you're working in. And so, I'm definitely feeling my fair share of impostor syndrome here.

+ +

But it's been really fun to stretch my brand and, like, approach problems from, like, a completely different perspective and also using different tools. But, you know, working with Mike and Chris makes it so much easier because they really make it feel like you're part of their team, and so that definitely goes a long way.

+ +

LINDSEY: It just goes to show everyone gets impostor syndrome sometimes [laughter], even senior product managers at thoughtbot [laughter]. Thanks for that intro. It's, you know, the thoughtbot team learns along the way, too, you know, especially if usually you're focused on a different stage of product development.

+ +

Mike, it's been only three weeks or a very long three weeks since last we checked in with you, kind of forever in startup time. So, I think the last time, we were just getting to know you two. And you were walking us through the concept, this merging of the digital and physical world of music, and how we interact with music keepsakes or merchandise. How's my pitch?

+ +

MIKE: Good. Great. You're killing it.

+ +

[laughter]

+ +

LINDSEY: And has anything major changed to that concept in the last three weeks?

+ +

MIKE: No. I mean, I can't believe it's only been three weeks. It feels like it's been a long time since we last talked. It's been an intense three weeks, for sure. No, it's been going really well. I mean, we launched all sorts of stuff. I'm trying to think of anything that's sort of fundamentally changed in terms of the plan itself or kind of our, yeah, what we've been working on. And I think we've pretty much stayed the course to sort of get to where we are now. But it's been really intensive.

+ +

I think also having sort of Thanksgiving in there, and we were kind of pushing to get something live right before the Thanksgiving break. And so, that week just felt, I mean, I was just dead by, you know, like, Thursday of Thanksgiving. I think we all were. So, it's been intense, I would say, is the short answer. And I'm happy, yeah, to get into kind of where things are at. But big picture, it's been an intense three weeks.

+ +

LINDSEY: That's cool. And when we talked, you were, you know, definitely getting into research and user interviews. Have those influenced any, you know, changes along the way in the plan?

+ +

MIKE: Yeah. They've been really helpful. You know, we'd never really done that before in any of the sort of past projects that we've worked on together. And so, I think just being able to, you know, read through some of those scripts and then sit through some of the interviews and just kind of hearing people's honest assessment of some things has been really interesting. I'm trying to think if it's materially affected anything.

+ +

I guess, you know, at first, we were, like, we kind of had some assumptions around, okay, let's try to find, like...adult gift-givers sounds like the wrong thing, adults who give gifts as, like, a persona. The idea that, like, you know, maybe you gift your siblings gifts, and then maybe this could be a good gift idea. And I think, you know, we had a hard time kind of finding people to talk in an interesting way about that. And I think we've kind of realized it's kind of a hard persona to kind of chop up and talk about, right, Chris? I don't know [crosstalk 04:55]

+ +

CHRIS: Well, it also seemed to, from my understanding of it, it seemed to, like, genuinely stress out the people who were being interviewed...

+ +

MIKE: [laughs]

+ +

CHRIS: Because it's kind of about a stressful topic [inaudible 05:03], you know, and, like, especially --

+ +

LINDSEY: Why? [laughs]

+ +

CHRIS: Well, I think, I don't know, now I'm making assumptions. Maybe because we're close to the holiday season, and that's a topic in the back of everybody's mind. But yeah, Danny, would you disagree with that? Those folks, from what we heard, seemed like they were the most difficult to kind of extract answers from. But then, if the subject changed and we treated them as a different persona, several of those interviews proved to be quite fruitful. So, it's just really interesting.

+ +

DANNY: Yeah. It really started, like, you kind of try to get some answers out of people, and there's, like, some level of people trying to please you to some extent. That's just, like, naturally, how it starts. And you just, like, keep trying to drill into the answers. And you just keep asking people like, "So, what kind of gifts do you give?" And they're just like, "Oh my goodness, like, I haven't thought about buying gifts for my sister in [laughs], like, you know, in forever. And now, like [laughs], I don't know where to go." And they get, like, pretty stressed out about it.

+ +

But then we just kind of started shifting into like, "All right, cool, never mind about that. Like, do you like listening to music?" And they're like, "Yes." And then it just kind of explodes from there. And they're like, "This last concert that I went to..." and all of this stuff. And it was much more fruitful kind of leaning more towards that, actually, yeah.

+ +

LINDSEY: That's fascinating. I guess that speaks to, especially at this stage and the speed and the amount of interviews you're doing, the need for being, like, really agile in those interviews, and then, like, really quickly applying what you're learning to making the next one even more valuable.

+ +

MIKE: Yeah. And I think, you know, like, we launched just a little sort of website experiment or, like, an e-commerce experiment right before Thanksgiving. And I think now, you know, we're able to sort of take some of those learnings from those interviews and apply them to both sort of our ad copy itself but also just different landing pages in different language on the different kind of versions of the site and see if we can find some resonance with some of these audience groups. So, it's been interesting.

+ +

LINDSEY: Are you still trying to figure out who that early adopter audience is, who that niche persona is?

+ +

MIKE: I think we --

+ +

CHRIS: Yes, we are. I think we have a good idea of who it is. And I think right now we're just trying to figure out really how to reach those people. That, I think, is the biggest challenge right now for us.

+ +

MIKE: Yeah. With the e-commerce experiment it was sort of a very specific niche thing that is a little bit adjacent to what I think we want to be doing longer term with Goodz. And so, it's weird. It's like, we're in a place we're like, oh, we really want to find the people that want this thing. But also, this thing isn't necessarily the thing that we think we're going to make longer term, so let's not worry too hard about finding them. You know what I mean? It's been an interesting sort of back and forth with that.

+ +

CHRIS: From the interviews that we conducted, you know, we identified three key personas. Most of them have come up, but I'll just relist them. There's the sibling gift giver. There was the merch buyers; these are people who go to concerts and buy merchandise, you know, T-shirts, albums, records, things along those lines to support the artists that they love. And then the final one that was identified we gave the title of the 'Proud Playlister'. And these are people who are really into their digital media platforms, love making playlists, and love sharing those playlists with their friends.

+ +

And that, I would say, the proud playlister is really the one that we have focused on in terms of the storefront that we launched, like, the product is pretty much specifically for them. But the lessons that we're learning while making this product and trying to get this into the hands of the proud playlisters will feed into kind of the merch buyers.

+ +

MIKE: Yeah. And I think that, you know, it's funny, like, this week is kind of a poignant week for this, right? Because it's the week that Spotify Wrapped launched, right? So, it's like, in the course of any given year, it's probably, like, the one week of the year that lots and lots and lots of people are thinking about playlists all of a sudden, so trying a little bit to see if we can ride that wave or just kind of dovetail with that a bit, too.

+ +

LINDSEY: Absolutely. And do you want to give just, like, the really quick reminder of what the product experience is like?

+ +

MIKE: Oh yeah [laughs], good call.

+ +

CHRIS: This is a prototype of it. It's called the Goodz Mixtape. Basically, the idea is that you purchase one of these from us. You give us a playlist URL. We program that URL onto the NFC chip that's embedded in the Good itself. And then when you scan this Good, that playlist will come up. So, it's a really great way of you make a playlist for somebody, and you want to gift it to them; this is a great way to do that. You have a special playlist, maybe between you and a friend or you and a partner. This is a good way to commemorate that playlist, turn it into a physical thing, give that digital file value and presence in the physical world.

+ +

LINDSEY: Great. Okay, so you casually mentioned this launch of an e-commerce store that happened last week.

+ +

MIKE: It didn't feel casual.

+ +

LINDSEY: Yeah. Why [laughter]...[inaudible 09:45] real casual. Why did you launch it? How's it going?

+ +

MIKE: I don't know. Why did we launch it? I mean, well, we wanted to be able to test some assumptions. I think, you know, we wanted to get the brand out there a little bit, get our website out there, kind of introduce the concept. You know, this is a very...not that we've invented this product category, but it is a pretty obscure product category, right? And so, there's a lot of sort of consumer education that I think that has to go on for people to wrap their heads around this and why they'd want this.

+ +

So, I think we wanted to start that process a little bit correctly, sort of in advance of a larger launch next year, and see if we could find some early community around this. You know, if we can find those core people who just absolutely love this, and connect with it, and go wild around it, then those are the people that we're going to be able to get a ton of information from and build for that persona, right? It's like, cool, these are the people who love this. Let's build more for them and go find other people like this. So, I think, for us, it was that.

+ +

And then, honestly, it was also just, you know, let's test our manufacturing and fulfillment and logistics capabilities, right? I mean, this is...as much as we are a B2B, you know, SaaS platform or that's what we envision the future of Goodz being, there is a physical component of this. And, you know, we do have that part basically done at this point. But we just, you know, what is it like to order 1,000 of these?

+ +

What is it like to put these in the mail to people and, you know, actually take orders? And just some of that processing because we do envision a more wholesale future where we're doing, you know, thousands or tens of thousands of this at a time. And so, I think we just want to button up and do some dry runs before we get to those kinds of numbers.

+ +

CHRIS: I think it also it's important to remember that we are talking in startup time. And while this last week seems like an eternity, it's been a week [laughs] that we've had this in place. So, we're just starting to learn these things, and we plan on continuing to do so.

+ +

MIKE: Yeah. But I think we thought that getting a website up would be a good way to just start kind of testing everything more.

+ +

LINDSEY: Great. Danny, what went into deciding what would be in this first version of the site and the e-commerce offering?

+ +

DANNY: I mean, a lot of it was kind of mostly driven by Chris and Mike. They kind of had a vision and an idea of what they wanted to sell. Obviously, from the user interviews, we were starting to hone in a little bit more and, like, we had some assumptions going into it. I think we ultimately did kind of feel like, yeah, I think, like, the playlisters seem to be, like, the target market. But just hearing it more and hearing more excitement from them was definitely just kind of like, yeah, I think we can double down on this piece.

+ +

But, ultimately, like, in terms of launching the e-commerce platform, and the storefront, and the website, like, just literally looking at the user journey and being like, how does a user get from getting onto a site, like, as soon as they land there to, like, finishing a purchase? And what points do they need? What are the key things that they need to think through and typically will run into? And a lot of it is just kind of reflecting on our own personal buyer behavior.

+ +

And, also, as we were getting closer to the launch, starting to work through some of those assumptions about buyer behavior. As we got there, we obviously had some prototypes. We had some screenshots that we were already working with. Like, the design team was already starting to build out some of the site. And so, we would just kind of show it to them, show it to our users, and just be like, hey, like, how do you expect to purchase this? Like, what's the next step that you expect to take? And we'd just kind of, like, continue to iterate on that piece. And so...

+ +

LINDSEY: Okay. So you were, before launching, even showing some of those mockups and starting to incorporate them in the user interviews.

+ +

DANNY: Yeah, yeah. I mean, we tried to get it in there in front of them as early as possible, partially because, like, at some point in the user interviews, like, you're mostly just trying to first understand, like, who are our target customers? Who are these people? And we have an assumption of or an idea of who we think they are. But really, like, once you start talking to people, you kind of are, like, okay, like, this thing that I thought maybe it wasn't so accurate, or, like, the way that they're kind of talking about these products doesn't 100% match what I originally walked into this, you know, experiment with. And so, we, like, start to hone in on that.

+ +

But after a certain point, you kind of get that idea and now you're just like, okay, you seem to be, like, the right person to talk to. And so, if I were to show you this thing, do you get it, right? Like, do you understand what's happening? Like, how to use this thing, what this product even does. And then also, like, does the checkout experience feel intuitive for you? Is it as simple as, like, I just want to buy a T-shirt? So, like, I'm just going to go by the T-shirt, pick a size, and, you know, move on with my life. Can we make it as seamless as that?

+ +

LINDSEY: And so, you mentioned it's only been a week since it's been live. Have you been able to learn anything from it yet? And how are you trying to drive people to it today?

+ +

MIKE: Yeah, I think we learned that sales is hard [laughs] and slow, and it takes some time. But it's good, and we're learning a lot. I mean, it's been a while since I've really dug deep in, like, the analytics and marketing kind of metrics. And so, we've got all the Google Tag Manager stuff, you know, hooked up and just, you know, connecting with just exploring, honestly, like the TikTok advertising platform, and the YouTube Pre-Rolls, and Shorts. And, like, a lot of stuff that I actually, since the last time I was heavily involved in this stuff, is just totally new and different.

+ +

And so, it's been super interesting to see the funnel and sort of see where people are getting in the site, where people are dropping off. You know, we had an interesting conversation in our thoughtbot sync yesterday or the day before, where we were seeing how, you know, we're getting lots of people to the front page and, actually, a good number of people to the product page, and, actually, like, you know, not the worst number of people to the cart. But then you were seeing really high cart abandonment rates.

+ +

And then, you know, when you start Googling, and you're like, oh, actually, everybody sees very high cart abandonment rates; that's just a thing. But we were seeing, like, the people were viewing their cart seven or eight times, and they were on there sort of five times as long as they were on any other page. And it's this problem that I think Danny is talking about where, you know, we need to actually get a playlist URL. This gets into the minutiae of what we're building, but basically like, we need to get them to give us a playlist URL in order to check out, right?

+ +

And so, you sort of have to, like, put yourself back in the mind of someone who's scrolling on Instagram, and they see this as an ad, and they click it, and they're like, oh, that thing was cool. Sure, I will buy one of those. And then it's like, no, actually, you need to, you know, leave this, go into a different app, find a play...like, it suddenly just puts a lot of the mental strain. But it's a lot. It's a cognitive load, greater than, as you said, just buying a T-shirt and telling what size you want.

+ +

So, thinking through ways to really trim that down, shore up the amount of time people are spending on a cart. All that stuff has been fascinating. And then just, like, the different demographic kind of work that we're using, all the social ads platforms to kind of identify has been really interesting. It's still early.

+ +

But, actually, like, Chris and I were just noticing...we were just talking right before this call. Like, we're actually starting to get, just in the last 12 hours, a bunch more, a bunch, but more people signing up to our email newsletter, probably in the last 12 hours that we have in the whole of last week. Yeah, I don't know, just even that sort of learning, it's like, oh, do people just need time with a thing, or they come back and they think about it?

+ +

CHRIS: Yeah. Could these people be working on their playlists? That's a question that I have.

+ +

MIKE: [chuckles] Yeah, me too.

+ +

CHRIS: It's like, you know, I'm making a playlist to drop into this product. It's really interesting. And I think it gives insight to kind of, you know, how personal this product could be, that this is something that takes effort on the part of the consumer because they're making something to give or to keep for themselves, which is, I think, really interesting but definitely hard, too.

+ +

DANNY: Yeah. And I also want to also clarify, like, Chris just kind of said it, like, especially for viewers and listeners, like, that's something that we've been hearing a lot from user interviews, too, right? Like, the language that they're using is, like, this is a thing that I care about. Like it's a representation of who I am. It's a representation of, like, the relationship that I have with this person that I'm going to be giving, you know, this gift to or this playlist to, specifically, like, people who feel, like, really passionate about these things. And, I mean, like, I did, too.

+ +

Like, when I was first trying to, like, date, my wife, like, I spent, like, hours, hours trying to pick the coolest songs that I thought, you know, were like, oh, like, she's going to think I'm so cool because, like, I listen to these, like, super low-key indie rock bands, and, like, you know, so many more hours than she probably spent listening to it. But that's [laughs] kind of, like, honestly, what we heard a lot in a lot of these interviews, so...

+ +

LINDSEY: Yeah, same. No, totally resonates. And I also went to the site this week, and I was like, oh damn, this is cool. Like, and immediately it was like, oh, you know, I've got these three, you know, music friends that we go to shows together. I'm like, oh, this would be so cool to get them, you know, playlists of, like, music we've seen together. So, you might see me in the cart. I won't abandon it.

+ +

MIKE: Please. I would love that.

+ +

CHRIS: Don't think about it too long if you could -- [laughter].

+ +

LINDSEY: I won't. I won't.

+ +

CHRIS: I mean, I would say I'm really excited about having the site not only as a vehicle for selling some of these things but also as a vehicle for just honing our message. It's like another tool that we have in our arsenal. During the user interviews themselves, we were talking in abstract terms, and now we have something concrete that we can bounce off people, which is, I think, going to be a huge boon to our toolset as we continue to refine and define this product.

+ +

MIKE: Yeah, that's a good point.

+ +

LINDSEY: Yeah. You mentioned that they're signing up for, like, email updates. Do you have something you're sending out? Or are you kind of just creating a list? Totally fine, just building a list.

+ +

MIKE: [laughs] No.

+ +

CHRIS: It's a picture of Mike and I giving a big thumbs up. That's, yeah. [laughter]

+ +

MIKE: No. But maybe...that was the thing; I was like, oh great, they're signing up. And I was like, gosh, they're signing up. Okay [laughter], now we got to write something. But we will.

+ +

LINDSEY: Tips to making your playlist [crosstalk 19:11] playing your playlist --

+ +

MIKE: Yeah [crosstalk 19:13].

+ +

CHRIS: Right. And then also...tips to making your playlists. Also, we're advancing on the collectible side of things, too. We are, hopefully, going to have two pilot programs in place, one with a major label and one with a major artist. And we're really excited about that.

+ +

LINDSEY: Okay. That's cool. I assume you can't tell us very much. What can you tell us?

+ +

MIKE: Yeah. We won't mention names [chuckles] in case it just goes away, as these things sometimes do. But yeah, there's a great band who's super excited about these, been around for a long time, some good name recognition, and a very loyal fan base. They want to do sort of a collection of these. I think maybe we showed the little...I can't remember if we showed the little crates that we make or not, but basically, [inaudible 19:52]

+ +

LINDSEY: The last time, yeah.

+ +

MIKE: So, they want to sell online a package that's, you know, five or six Goodz in a crate, which I think will be cool and a great sort of sales experiment. And then there's a couple of artists that we're going to do an experiment with that's through their label that's more about tour...basically, giving things away on tour. So, they're going to do some giveaway fan club street team-style experiments with some of these on the road.

+ +

So, first, it's ideal, provided both those things happen, because we definitely want to be exploring on the road and online stuff. And so, this kind of lets us do both at once and get some real learnings as to kind of how people...because we still don't know. We haven't really put these in people's hands yet. And it's just, like, are people scanning these a lot? Are they not? Is this sort of an object that's sitting on their shelf? Is it...yeah, it's just, like, there's so much we're going to learn once we get these into people's hands.

+ +

LINDSEY: Do you have the infrastructure to sort of see how many times the cards are scanned?

+ +

CHRIS: Mm-hmm. Yep, we do.

+ +

MIKE: Yeah. So, we can see how many times each one is scanned, where they're scanned, that sort of thing.

+ +

CHRIS: Kind of our next step, and something we were just talking about today with the thoughtbot team, is building out kind of what the backend will be for this, both for users and also for labels and artists. That it will allow them to go in and post updates to the Goodz, to allow them to use these for promotion as people, you know, scan into them to give them links to other sites related to the artists that they might be interested in before they move on to the actual musical playlist. So, that's kind of the next step for us. And knowing how users use these collectibles, both the kind of consumer Good and the artist collectibles that we were just talking about, will help inform how we build that platform.

+ +

LINDSEY: Very cool. And right now, the online store itself that's built in Shopify?

+ +

MIKE: Yeah. The homepage is Webflow that Kevin from the thoughtbot team really spearheaded in building for us. And then, yeah, the e-commerce is Shopify.

+ +

LINDSEY: Y'all have been busy.

+ +

MIKE: [laughs]

+ +

LINDSEY: Is there anything else maybe that I haven't asked about yet that we should touch on in terms of updates or things going on with the product?

+ +

MIKE: I don't know. I don't think so. I think, like Chris said, I mean, we're just...like, now that the site has kind of stood up and we're really switched over to kind of marketing and advertising on that, definitely digging into the backend of this kind of SaaS platform that's going to probably be a big focus for the rest of the, you know, the program, to be honest. Yeah, just some other things we can do on the next front that could eventually build into the backend that I think can be interesting. No, I guess [laughs] the short answer is no, nothing, like, substantial. Those are the big [crosstalk 22:26]

+ +

LINDSEY: Yeah. Well, that was my next question, too, which is kind of like, what's next, or what's the next chunk of work? So, it's obviously lots more optimization and learning on the e-commerce platform, and then this other mega area, which is, you know, what does this look like as a SaaS solution? What's the vision? But also, where do we start? Which I'm sure, Danny, is a lot of work that you specialize in as far as, like, scoping how to approach these kinds of projects.

+ +

DANNY: Yeah. And it's interesting because, I mean, we were just talking about this today. Like, part of it is, like, we can, like, really dig into, like, the e-commerce site and, like, really nailing it down to get it to the place where it's like, we're driving tons more traffic and also getting as low of a, like, cart abandonment rate as possible, right? But also, considering the fact that this is in the future, like, large-scale vision.

+ +

And there's, like, also, like, we're starting to, I think, now iron out a lot of those, like, milestones where we're kind of like, okay, like, we got, like, a short-term vision, which is, like, the e-commerce site. We got a mid-term vision and a potential long-term vision. How do we validate this long-term vision while also still like, keeping this short-term vision moving forward?

+ +

And, like, this mid-term vision is also going to, like, help potentially, either, like, steer us towards that long-term or maybe even, like, pivot us, like, into a completely different direction. So, like, where do you put your card, right? Like, how much energy and time do we put into, like, each of these areas? And that's kind of, like, the interesting part of this is starting to talk through that, starting to kind of prioritize, like, how we can maximize on our effort, like, our development and design effort so that things just kind of line up more naturally and organically for our future visioning, so...

+ +

MIKE: Yeah. A lot of different things to juggle. I saw there was a question. Somebody asked what the URL is, but I don't seem to be able to [crosstalk 24:10].

+ +

LINDSEY: The same question as me. We got to drop the link for this thing.

+ +

MIKE: Yeah, getthegoodz.com.

+ +

CHRIS: That's G-O-O-D-Z.

+ +

LINDSEY: Get in there, folks

+ +

MIKE: Yeah, get [crosstalk 24:23].

+ +

LINDSEY: And let us know how it goes.

+ +

MIKE: Yeah, please [laughs]. Any bugs? Let us know. Yeah. I think that those...yeah, I mean, it's a good point, Danny, in terms of juggling kind of the near-term and longer-term stuff. You know, it's a good kind of reminder our big focus, you know, in the new year is going to be fundraising, right? We're already talking to some investors and things like that.

+ +

So, it's like, okay, yes, as you said, we could tweak the cart. We could tweak the e-commerce. Or, like, can we paint the big picture of what the longer-term version of this company is going to be in a way that makes it compelling for investment to come in so that there can be a long-term version of this company? And then we can build those things. So yeah, it's definitely a balance between the two.

+ +

LINDSEY: Oh, also, just casual fundraising as well.

+ +

[crosstalk 25:06]

+ +

MIKE: Yeah, yeah.

+ +

LINDSEY: [laughs]

+ +

MIKE: But it's hard. It's like, you wake up in the morning. It's like, do I want to, like, write cold emails to investors? Or do I want to, like, look at Google Analytics and, like, tweak ad copy? That's actually more fun. So, yes.

+ +

LINDSEY: Yeah, life of the founder, for sure. All right. So, that's getthegoodz (Goodz with a z) .com. Check it out. We'll tune in and see what happens with the e-commerce site, what happens with the SaaS planning the next time that we check in.

+ +

But Chris, Mike, Danny, thank you so much for joining today and sharing what's been going on over the last few weeks: the good, the bad, the challenge, the cart abandonment. And, you know, best of luck to you over the next few weeks, and we'll be sure to check in and see how it's going.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

+ +

Transcript:

+ +

 LINDSEY: Thank you to our viewers and listeners. We are catching up once again with one of the startups going through the thoughtbot Incubator. My name is Lindsey Christensen. I'm joined today by Jordyn Bonds, who heads up the thoughtbot incubator, as well as our Co-Founders of Goodz, Chris Cerrito and Mike Rosenthal. Welcome, everybody.

+ +

MIKE: Thanks, Lindsey.

+ +

LINDSEY: Before we get started, before we put Chris and Mike back in the hot seat, at the top here, Jordyn, we have a special announcement for our viewers and listeners.

+ +

JORDYN: Application window is open for session 1 of 2024, folks. You can go to thoughtbot.com/incubator and apply. And Chris and Mike can tell you how easy or hard applying was.

+ +

MIKE: It was easy. It was totally easy. It's a very straightforward process.

+ +

CHRIS: Yeah, it was way more straightforward than a lot of applications that we've dealt with in the past, for sure.

+ +

JORDYN: Ha-ha. And if you've got a business idea that involves software but you haven't gotten anything out there yet, come talk to us. We will help you make sure that it's a good idea and that there are people who might buy it, and maybe get you even a little further than that.

+ +

MIKE: We actually have a friend who's considering applying. I'll tell him applications are open. He's worried his idea is not big enough to actually be a business idea, so we'll see.

+ +

CHRIS: Even the process of doing the application was really helpful for us because it helped us get aligned on exactly what we were doing, yeah.

+ +

JORDYN: I love that. And I found that to be true when I was a founder applying to some of these things, in particular, applying for an SBIR grant was one of the most challenging things that we did, but it was so productive. I was so annoyed by it at the time, and then I cribbed from that thing. It actually sort of forced us to make a business plan [laughs], and then, basically, we ran it, and it was great [laughs].

+ +

CHRIS: Yeah. I think that was, for us, that was our point where we were like, "Is this idea fleshed out enough to move forward?" And we were like, "Yes, it is. Let's go. Let's do this."

+ +

JORDYN: So, use the application as a forcing function, everybody. It will help you clarify your thinking.

+ +

LINDSEY: Yeah. Jordyn, what would you say to Mike's friend who's questioning if their idea is big enough? How do you respond to that sentiment?

+ +

JORDYN: That is a fascinating sentiment because I feel like so much more often, I am trying to help founders with the opposite problem where they think this thing is so big that they are not thinking about what step 1 is going to look like. They're just, like, in 10 years, we're going to be the next Amazon, and I'm like, "Maybe [laughter]. Let me help you figure out how to get to that giant vision." So, I don't come across the "Is this big enough to be a business?" question as often. And, I don't know, what would I say? I guess I need the details.

+ +

LINDSEY: It could be a perfect fit

+ +

MIKE: It could be.

+ +

JORDYN: It could be a perfect fit.

+ +

LINDSEY: In a way, that's what you're answering, right?

+ +

MIKE: Right.

+ +

LINDSEY: In some of this work.

+ +

MIKE: That is true. So, yeah, you guys would certainly...just thinking through the process we've gone through the last two months, it would definitely help them flesh that out.

+ +

LINDSEY: Which is a great segue.

+ +

MIKE: Great segue.

+ +

LINDSEY: Chris and Mike, we're actually coming up to the end of your incubator time.

+ +

CHRIS: It's so sad.

+ +

LINDSEY: Can you believe it?

+ +

MIKE: It's gone by really fast. I mean, eight weeks is not a long time, but it has gone by very, very fast.

+ +

CHRIS: It felt like a very long time in the middle of it.

+ +

MIKE: [laughs]

+ +

CHRIS: But now that it's over, it feels like a blink that it's coming to a close.

+ +

MIKE: I don't know. It's funny. I think we had some note in our retro today that was like, maybe the very end of the year is not the best time to do an accelerator just because you have, like, the holidays kind of jumping in here in the end. So, that might have helped make it feel like a... I feel like the end of the year always feels like a rush anyway. So, I think just life gets a little bit busier this time of year, too, but yeah.

+ +

CHRIS: Yeah, my gingerbread man decorating game is, like, really down this season because we've been so busy. Tragic.

+ +

LINDSEY: Chris, can you remind our viewers and listeners who might not be familiar what was the idea that you and Mike have been exploring with the incubator or, like, what did you come in with?

+ +

CHRIS: So, with Goodz, what we're trying to do is make little, physical collectibles objects that connect back to the digital content that a user loves. The idea being that today, we are awash in these digital files, links, so many things on our desktops, on our phones, on our devices, and it's really hard to tell which part of those are really, really important to us. So, by giving them a presence in the physical world, that denotes that's something that's really important, worth keeping, worth sharing, and showing off to your friends and family.

+ +

And to start this off, mostly because Mike and I are both kind of music nerds, we're starting off with a music focus, but at some point, we're hoping to move into other realms, too.

+ +

LINDSEY: And a lot of the incubator, as repeat listeners will know, is focused on really kind of evolving user interviews all the way through and narrowing in on, you know, a core audience, a core market. Mike, how has that evolution been? I think the last time we chatted was around three weeks ago. What has the latest iteration of user interviews looked like in terms of the people you're talking to and even what you're asking them?

+ +

MIKE: It's been a really fascinating process. I mean, I'm trying to think of where we were exactly the last time we talked to you, but I think we'd probably just launched the e-commerce site that we had been experimenting with putting up.

+ +

LINDSEY: Yeah, exactly.

+ +

MIKE: And so, and we really then started cranking on user interviews kind of once that was live. And so, moving away from the conceptual and more into like, "Okay, share your screen. Here's the link. Like, tell me what you think is going on here," and really sort of getting users who had never, you know, never heard our pitch, never been involved with us to sort of try to wrap their heads around what we are and what we're doing just based on that website and trying to sort of make iterative changes based on that.

+ +

You know, for me, because I had not done user interviews very much in the past, like, it's very tempting, like, you get sort of 1 note from 1 person in 1 interview, and you're like, oh, we need to change this word. That word didn't make any sense to them, or this thing needs to be blue instead of pink. I think, for me, it was like, all right, how do we kind of synthesize this data in a responsible way?

+ +

And it emerged naturally, which, I mean, Jordyn and all thoughtbot folks said that it would, but you sort of started hearing the same things again and again. And we never really got to a place where, like, you heard the exact same things from everyone. But there were enough buckets, I feel like, where we're like, okay, like, this part really isn't making that much sense to people, or, like, we do really need to, you know, structure this differently to convey.

+ +

So, it was a bunch of that kind of work over the last three weeks or so and sort of just getting a sense of like, are we conveying our message? It's hard. I mean, it's a new, like, we're not the only people making physical products with NFC chips in them, but it is not the most common, like, product. Like, it is kind of a new category out there. And so, really trying to understand just right off the bat, do people get it? And you get wildly different answers [laughs] as to whether they get it or they don't, which has been fascinating, too.

+ +

JORDYN: Yeah. [crosstalk 7:12]

+ +

LINDSEY: Chris or Jordyn, anything to add there?

+ +

JORDYN: Yeah. You get the best, like, bootcamp in the don't overreact to a single user interview experience in some ways because we [laughs]...it would literally be like, interview in the morning someone says this thing. Interview in the afternoon, someone says the exact opposite thing [laughter]. And you're like, okay [laughs], like, which one of these things are we going to respond to, if either of them?

+ +

CHRIS: Yeah. It's hard. As somebody with, like, a strong desire to please, it's hard to reign yourself in and want to change things immediately, but it definitely makes sense to do so in the long run.

+ +

MIKE: But yeah, but, I mean, like I said, I do feel like it kind of came down to buckets. It's like, okay, you're that. I can, like, categorize you with all those other people and you with all those other people. And yeah, I hear you. I'm like, yeah, it's tempting to want to please them all.

+ +

But I think with this one, we're fighting hard to be like...or we sort of have a philosophy that this product is emphatically not for everyone because, at the end of the day, you get a lot of people who are like, "Wait, you're just putting a link to a streaming playlist on a physical object? Why don't I just text someone the link?" And sometimes that breaks down by age group, like, 18-year-olds being like, "What are you talking about, old man?

+ +

LINDSEY: [laughs]

+ +

MIKE: Like, why the hell would I do that? It makes no sense." But it sort of skews all over the age ranges. But then there'll be other people who are 18 or 20 years old who are like, "Wow, I never had cassettes when I was growing up," or "I never got to make, you know, mixtapes or CD-Rs for people." And like, you know, so it's, yeah, it's about finding the people who are the early adopters. As Jordyn has said a lot, it's like, we need to find those early adopters and, like, make them love us, and then other people will come later.

+ +

CHRIS: I mean, some of the most gratifying moments, I think, are there's been some interviews where people have been so excited that after the interview, they've gone and purchased our products, which is just, like, the coolest feeling ever.

+ +

LINDSEY: Wow.

+ +

MIKE: Yeah, it's pretty cool.

+ +

LINDSEY: Are you open to sharing a little bit more about what those buckets or what those segments look like?

+ +

CHRIS: I mean, I think there's folks who outright just get it almost immediately, and I think those people tend to be hardcore music collectors, hardcore music fans, Jordyn and Mike, please feel free to jump in if you disagree with any of this. They just get it right off the bat.

+ +

Then I think there's, in my experience, there's another bucket of people who are a little more hesitant, and maybe they wouldn't buy it, but they seemed really excited about the idea of getting one as a gift, which is really interesting. They're like, "I don't know if I'd buy this, but I'd really like to have one." And then there is another segment, like, which Mike just mentioned, of folks who just don't see the value in this whatsoever, which is totally fair.

+ +

MIKE: Yeah, totally. I think it's also...I see it almost as, like, a matrix. There's, like, desirability, and, like, technical understanding because people were like, "I technically understand what this is, and I do not want it in my life." Or like, "I get what this is and, oh my God, I have to have that," or like, "I don't really understand what you're talking about, but, man, I love physical stuff. Like, sure I want..." you know, it's like, it goes across those two planes, I think.

+ +

JORDYN: I will say that it, I think you alluded to this before, Mike, but, like, we're going to run a whole analysis of...because we did a ton of interviews, and we haven't actually done that, like, sort of data-driven thing of like, are there trends in the demographics somewhere that we're not getting? Because the pattern has not been there. Like, someone will talk to an 18-year-old, you know, at 1:00 p.m. who is just, like, "Why on earth would I ever want this?" And then I, like, you know, will talk to a 21-year-old who is like, "I love this."

+ +

And it's like, why? Like, this is the answer. The thing we're trying to get out now is, like, what is the difference between those two people? It's not a demographic thing that we can see from the outside, so what is it instead? But with consumer stuff like this, often, you don't necessarily...you don't need that in such great detail when you're starting. You just kind of, like, throw it out there and see who grabs it, and then you start to build sort of cohorts around that.

+ +

And that is kind of what these interviews have shown us is that there are people who will grab it, and that was part of what we were trying to validate. Are there people who Mike and Chris do not know personally who will, like, get this and be psyched about it immediately? And that is, you know, check unequivocally true. Like Chris said, there are people that we were, you know, that we had recruited on this user interviews platform [chuckles] who then just turned around and bought the product because they were so psyched about it. One of the guys I interviewed was like, "Can I invest in your company right now?" Like, during the interview, and I was like, "Maybe?" [laughs]

+ +

CHRIS: There was, like, another person who wanted to work for us immediately...

+ +

JORDYN: Yes, great.

+ +

CHRIS: Which was really interesting and kind of awesome.

+ +

JORDYN: Yeah, they're like, "Are you hiring?" You're just like, okay. So, it's validating that there are people all over that spectrum. Like, where those trends lie, though, which is, I think, what you were asking, Lindsey, not as straightforward and in a fascinating way. So, we still have a little more, like, number crunching to do on that, and we may have an answer for you later.

+ +

LINDSEY: That's exciting. Exactly. I'm curious: what are the connecting dots between the folks who are really into it, and how might that impact how you approach the business?

+ +

MIKE: Yeah, it's hard. It's definitely going to be a niche to start. And so, we got to figure out kind of got to crack the code on how we find those people.

+ +

LINDSEY: And, Mike, I think you had also mentioned last time that, you know, you or both of you have a network kind of in the music industry, and you've been floating the idea past some people there. Have you been having more of those conversations over the last few weeks, too?

+ +

MIKE: We have, yeah. Well, so yeah, we've had a couple more just kind of straight-up pitch calls versus like, "Hey, there's this cool thing we're doing," and having those people be like, "Cool. Let's do a pilot." And so, they're ordering, you know, 500 or 1,000 units at a time, which is rad.

+ +

LINDSEY: Whoa.

+ +

MIKE: For the first...yeah.

+ +

LINDSEY: Okay, very cool.

+ +

MIKE: Yeah. The first two or three of those should happen in January or maybe early February, but yeah, those are done and in production and arriving soon. So, that's really exciting with some cool bands. We won't say the names in case it doesn't [laughs] work out, but it does look like it's going to work out.

+ +

LINDSEY: And so, it's specific bands that are creating merch for their fans.

+ +

MIKE: Yeah, yeah. So, we're working with one artist manager on a band that he manages, and then we're working with a record label. And they're going to try with a couple of smaller artists. And so, yeah, it's actually really good for us. One is going to be straight-up sales, most likely, and it's, like, selling these things. And the other ones will be given away as kind of promo items on tour artists, which is also a really interesting use case for us, too, that we're excited about and using them as a way to sort of get email addresses and, like, fans engaged and stuff, so...

+ +

And then yeah, then I had another conversation, and they want to talk about doing some pilots. So far, like, that side of things is going great. We're sort of 3 for 4 in terms of initial calls leading to pilots right off the bat, which is kind of unheard of from [laughs] my experience.

+ +

LINDSEY: Yeah, I'd say so. No, a lot of very good signals.

+ +

MIKE: Really good signals. But then we were able to turn some of those into user interview conversations, actually, as well over the course of the last couple of weeks, which has been really helpful, like, talking to manager and label-type people about what they might want out of a software product that is associated with this because we're not just thinking about making physical products but sort of coupling that with an online toolset. And that part, we haven't gotten as far along as we did with the direct-to-consumer e-commerce, but it's been fascinating.

+ +

LINDSEY: So, what has been happening with the online shop? As you noted the last time we talked, it was just a baby less than a week-old Shopify site getting, you know, some first hits of people going around maybe putting things in their basket. I'm sure a lot has happened over the last few weeks. What kind of work, what kind of insights have you seen around the site?

+ +

CHRIS: We've been, I mean, we've been selling stuff at a slow but steady pace. It's been great because it's enough to, you know, because our product really straddles the line between physical and digital; there's a lot of physical aspects to this that we need to figure out and kind of the level of orders that we've been getting have been really...it's, like, the perfect number to think about fulfillment issues, things like what kind of package does this go in? How do we mail this out? Things along those lines, just very basic, practical questions that needed to be answered.

+ +

But yeah, it's been great. We actually, I mean, we hit our goal for the amount of these that we wanted to get in people's hands before Christmas, which is pretty awesome. And we continue now with the lessons learned. I think our plan is to try and make a push for Valentine's Day because these seem like they would be a great Valentine's Day present: make a playlist; share it with your loved one; share it with a friend; share it with somebody you don't like at all. Who knows?

+ +

LINDSEY: [laughs]

+ +

CHRIS: But yeah, that's kind of our next sales push, we think.

+ +

LINDSEY: The hate playlist.

+ +

CHRIS: [inaudible 15:40] hate playlist.

+ +

MIKE: Yeah, perfect. Real passive-aggressive.

+ +

CHRIS: Just Blue Monday, like, by New Order, like, 14 times.

+ +

LINDSEY: [laughs] Yeah, every song is just like a sub-tweet...

+ +

MIKE: [laughs]

+ +

LINDSEY: About something they've done and [inaudible 15:53] Have you updated the site? Like, how do you decide what gets updated on the site? [laughter] Everyone laughed.

+ +

MIKE: It was a little haphazard, I would say, there for a minute. But --

+ +

CHRIS: We got the site up very, very quickly. And from my perspective, I've been dealing a lot with the physical side of things, just getting great product photos up there, which is, like, something that thoughtbot has actually been super helpful with. You know, everybody on the team is starting to submit photos of their Goodz in the real world and using their Goodz, which is great.

+ +

And we continued to update the site with that but also making sure our text made sense, refining copy in response to things that people said during user interviews. The checkout process, the process of adding the URL that we point the Good to that, we did a bunch of experimentation there based on what people were saying during user interviews. So, it has been a little haphazard, but we have made a bunch of changes.

+ +

LINDSEY: Jordyn, has there been any experiment, like, structured experimentation around the site or how you're getting people to the site?

+ +

JORDYN: Mike actually did a little bit of ad funnel work that I don't think we've, like, even remotely scratched the surface of. So, I wish I could say that was conclusive, but I think we've found a little bit more...here are plenty of sales that are from people that nobody here knows.

+ +

MIKE: True.

+ +

JORDYN: So, people are finding out about this somehow [laughs]. But I think it's a little bit, like, word-of-mouth sort of chain of events is our sense so far. I wanted to say, though, about the site, we did get what Chris was saying about, like, this experiment was, in part, about fulfillment and figuring out how fulfillment would work and packaging, and not just messaging and not just closing the sale with consumers, but also, just, like, how do you fulfill these?

+ +

But one of the really fun things we've managed to do in the last, since we talked last time, which I can't even believe...I feel like this wasn't even a gleam in our eyes for this project, but we managed to get out, like, stood up and out the door, and working in production in the last few weeks is a way for folks to actually assign the URL to their mixtape themselves. Previously, the plan had just been for Chris and Mike to do that, which is fine but a little bit unscalable, right?

+ +

CHRIS: That was a huge dream or, like, that was high on our wish list. And we didn't think we'd get to it. And it's been pretty amazing that we have, yeah.

+ +

JORDYN: Yeah, so that was one thing that is an update to the site. So, then we had to do a little bit of, like, micro iterating, on, like, the messaging around that. Like, how do you communicate to people? This is, like, a little bit of an abstract challenge, right? Like, here's this object. It's going to point to a digital thing. How do you tell the physical object which digital thing it's pointing to [laughs]?

+ +

So, a lot of our recent interviewing has been to sort of get inside the mind of the consumer about how they're thinking about that and how we can best communicate that to them. So that's been a lot of the, like, recent iteration is getting that mechanism stood up and then the messaging around it.

+ +

CHRIS: It's also really cool because it adds to the utility of the object itself in the sense that now our Goodz, when a user gets one, they can add a URL to their Good themselves, but they can also change that URL. So, it's much more malleable.

+ +

JORDYN: Which is something that in one of our early user interviews was, like, a hot request [laughs], and we were like, "Someday, someday." And it's, you know, I should actually go back to her and be like, "Someday is today."

+ +

[laughter]

+ +

MIKE: Well, yeah, and just as Chris was saying, it just makes it so much easier to ship these out without having to manually load them, and you could sell them, and yeah, retail outlets, like, it just opens up a lot of opportunities for us for them.

+ +

LINDSEY: And Mike mentioned that some of the, like, kind of future looking aspirations for the solution are, you know, how might you figure out the B2B, like, SaaS aspect of it? Jordyn, is that something that's been explored at all at this point, or is it early?

+ +

JORDYN: That experiment I just described is actually sort of the link between the two projects. It sort of proves the concept and proves the value in some ways, and it has given us a little bit more visibility into sort of how we're going to execute some of this technical stuff. Like, how easy, how difficult is it going to be? These little experiments all build your confidence around your ability to do those things and what it's going to look like. And so, this experiment absolutely feeds into that question.

+ +

But I would say it was really this week where we got to have a really fun brainstorming sort of blue sky conversation about that that I don't think would have been nearly as both creative and blue sky or rooted in reality as it was if we hadn't done these experiments and hadn't talked to so many...we had so much work...we could participate in a conversation like that so much more confidently and creatively because all of us had a lot more shared context.

+ +

So, we really got to dream big, like, what is a SaaS platform built around these physical objects? And I don't want to, you know, I'm not going to give it away at this moment because we had a lot of, like, really cool ideas. It's one part talking to the B2B customer, which, you know, you mentioned earlier, getting what their pain points are, and what they're looking for, what they need, but then also dreaming big about now we understand the technology a little bit more and how it feels to use it. What does that unlock in our brains?

+ +

The analogy I used in that conversation and that I use all the time is like, the users of Twitter invented hashtags, right? Twitter did not invent hashtags. And so, hey, everybody out there, newsflash: users invented hashtags, not Twitter or something else, if you didn't realize that Twitter was where those things kind of emerged. But there was just a user behavior that was happening in the wild, and Twitter was just very good at making that easier for them, looking at that and being like, "Oh, hey, is this a thing you all want to do? Here, we'll make that even more useful for you." And it was part of Twitter's early success that they were able to do that.

+ +

And so, that was the kind of thinking we were trying to employ here is, like, now that we have these objects and we understand a little bit more how it feels to use them, you get these second order effects. What does that then make us think of? What is then possible to us that we wouldn't have been able to dream of previously because we didn't quite get it? So, that was really happening this week.

+ +

LINDSEY: So, as the incubator time wraps up, what are the kind of final activities or deliverables, one, that Goodz wants and you know that they're going to get? What are the parting gifts as we send you out into the next phase?

+ +

MIKE: Yeah, well, loads of stuff. I mean, we're getting all that code that [SP] Guillermo and the guys worked on to let people set their own playlist settings. And we've got that up in a GitHub repository now. And we've got a bunch of great design work that's all being handed over, like Chris was saying, product shots that a bunch of the team members were taking, synthesizing all the user interviews. We're actually sort of making some kind of final reports on those, so it's kind of more usable, actionable data for us. The whole website, you know, that didn't exist before. And that will sort of continue to grow as the entire website for Goodz moving forward. I don't know. That's a lot. What else was there, Chris?

+ +

CHRIS: As a result of all that, I mean, one of the things I'm most excited about is now we have a small user base who actually has the physical products that, hopefully, we can get them to answer questions. That's huge for what's coming next. Starting the path towards the SaaS platform, too, it's really helped narrow our scope and think about, you know, how to make that successful or if it will be successful.

+ +

LINDSEY: Yeah, that sounded like a big discussion this week that I know has been on your minds from the beginning. Wait, the last time, also, you said you were starting to get emails, too. Have you emailed anyone yet, or are you still holding on to them?

+ +

MIKE: Oh. No, I still haven't sent a newsletter out [laughs], actually, but we have Mailchimp set up. Yeah, no, we've got a good kind of core of our, yeah, early folks on there. We'll start getting a newsletter out with some sort of regularity. We're building up the socials very slowly just focusing on Instagram mostly right now and trying to get back into that game.

+ +

It's been a long time since I've had to do kind of social marketing stuff. And so, it's a lot of work, as it turns out, but we'll get all that cooking. I think this was just such a sprint, working with the thoughtbot folks and trying to get all this stuff done. Before the end of the year, now we can sort of take a breath and start engaging folks in the new year.

+ +

LINDSEY: Yeah. Well, so, do you know what you want to do next or what the next phase looks like? Are you going to do fundraising?

+ +

MIKE: We're certainly going to continue to have some fundraising conversations. We've had some conversations emerge over the last, you know, since we've been in thoughtbot, again, not the greatest time of year to try to be raising a round. But we're also not, like, desperately, urgently needing to do that right this second. I think, you know, part of it is the fundraising landscape, you know, doesn't look amazing. And we're still sort of building out a lot of traction, and sort of every week, there's some new, exciting thing, or we've got some new, big artists who wants to do something.

+ +

So, I think, in some ways, to the extent that we can bootstrap for a little while, I think we will, yeah. So, we will focus on...I'd like to get back to focusing on, like, B2B sales. I'd like to hit the ground in January and just start talking to a bunch of music industry folks.

+ +

And thinking ahead a little bit, sort of Q1 and Q2, like, what are the big tentpole events? You know, you got South by Southwest coming up in March. You got Record Store Day in April, or whenever it is. But, you know, there's, like, a bunch of those sorts of things that it's like, oh, let's not let those things suddenly be tomorrow. Like, right now, they're all still two or three/four months out. Like, let's make sure we're queued up for those things and see what happens.

+ +

And Jordyn has been giving really good advice on the fundraising side where it's just like, just keep getting cool stuff like that and just do almost like little drip campaigns with funders who aren't maybe giving you the time of day or think it's too early, and just kind of keep going back to them. Like, the best excuse to go back to funders is like, "Hey, we just closed this new thing. We just launched this new thing. We just got this thing working. Hey, we're launching with this major band," Like, enough of those happen, and I think the fundraising will happen more organically. It's a strategy.

+ +

CHRIS: I think we're really lucky in the fact that, you know, now, at this point, we're not talking about vapourware, you know, like, these are actual things that actually exist that, like, anybody could go onto our site right now and buy, which is awesome. And because of that, the product's going to continue to evolve, and, hopefully, our sales record will continue to evolve, too.

+ +

LINDSEY: Amazing. Well, that feels like a good place to wrap up, maybe. Are you going to hang around in our incubator Slack, the thoughtbot incubator Slack for all our past founders?

+ +

MIKE: Yes. Emphatically, yes.

+ +

LINDSEY: Okay. We're holding you to it then [laughs].

+ +

CHRIS: I'm excited about that. We met with the other founders yesterday for the first time, and it was a really great and interesting conversation. It was cool seeing how diverse all these projects are and how folks are working on things that we had no idea about and how we're working on stuff that they have no idea about, and it was really great. It felt like a good cross-pollination.

+ +

MIKE: Agreed.

+ +

LINDSEY: That's awesome to hear. Jordyn, any final thoughts?

+ +

JORDYN: [inaudible 26:58] out there listening and watching and want to join this community of founders [laughs], don't you want to have office hours with Chris and Mike?

+ +

LINDSEY: All right, thoughtbot.com/incubator. You can apply for session 1 of the 2024 incubator program. And yeah, you two, if you have more recommendations, referrals, definitely send them our way. Chris, Mike, Jordyn, thank you so much once again for joining and catching us up on all the exciting developments for Goodz.

+ +

MIKE: Thank you.

+ +

LINDSEY: A lot of really cool milestones.

+ +

JORDYN: I got to say, so much good stuff. And like, you know, just wrapping it all up almost diminishes the impact of any single one of those things that we just talked about, but it's, like, pretty amazing. People out there, apply to the incubator but also go buy yourself a Goodz mixtape. It's cool with playlists on it.

+ +

MIKE: It's a good point.

+ +

JORDYN: Give it to your BFF. Come on.

+ +

LINDSEY: Getthegoodz.com.

+ +

MIKE: Getthegoodz.com. Awesome.

+ +

LINDSEY: All right. Thanks, Chris and Mike.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Chris Cerrito, Jordyn Bonds, and Mike Rosenthal.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dK3NXHjM + + ]]> + + Lindsey Christensen + Chris Cerrito + Mike Rosenthal + Jordyn Bonds + + + 508: Drumming Up Connections: Jessica Wallace on Networking in Real-Time + https://podcast.thoughtbot.com/508 + eb21085f-2917-4270-bc0e-9415413fc8d0 + Thu, 18 Jan 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido talks with Jessica Wallace, CEO of Flok22, about her journey from hairdressing to tech entrepreneurship and the creation of Flok22, an app for real-time networking. They share a mutual passion for music and discuss the challenges and successes in developing Flok22, emphasizing its impact on modern networking and personal connections in the tech world. + 30:13 + no + + + In this episode, host Victoria Guido talks with Jessica Wallace, the CEO of Flok22, an innovative app designed to enhance real-time social networking. Victoria delves into Jessica's unique journey from her roots as a hairdresser to becoming a tech entrepreneur. They explore how Jessica's personal experiences and challenges, including being a military wife and navigating life post-divorce with three children, fueled her drive to create Flok22. Jessica's desire to connect people in real-time, especially in the post-COVID era, led to the birth of this groundbreaking app. +Victoria and Jessica discuss their mutual passion for music, revealing how their hobbies provide a creative outlet from the demanding world of startups. Jessica shares her aspirations to return to playing the drums, a skill inspired by her family's musical background, and her journey in learning the instrument during the pandemic. +On technology and entrepreneurship, Jessica dives into the challenges and triumphs of developing and marketing Flok22. She reflects on the importance of networking, particularly in the startup community, and how her app addresses the inefficiencies and awkwardness often encountered at networking events. Victoria and Jessica discuss the evolution of Flok22, emphasizing its focus on enhancing in-person connections and its pivot towards a more event-centric approach, as well as the future of networking, the potential of Flok22, and their shared enthusiasm for making meaningful connections, both professionally and musically. +Flok22 (https://flok22.com/) +Follow Flok22 on Facebook (https://www.facebook.com/flok22?mibextid=ZbWKwL), Linkedin (https://www.linkedin.com/company/flok22/), or Instagram (https://www.instagram.com/flok22app/). +Follow Jessica Wallace on LinkedIn (https://www.linkedin.com/in/jessica-wallace-b9526361/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jessica Wallace, CEO of Flok22, the app that helps you make friends and grow your network in real-time situations. Jessica, thank you for joining us. +JESSICA: Thank you for having me. +VICTORIA: Yeah. Well, just to get us started and warm up here, Jessica, is there any new skill or any skill you've come back to to practice more recently to kind of take your mind off of all the founder stuff that's happening? +JESSICA: Yeah. It's been a busy past two months of events and things like that. So, I've kind of been taking a little bit of downtime. I am hoping to start practicing the drums. I play those, and I haven't been doing that in a while. They've been kind of staring me down, so... +VICTORIA: So, were you a drummer before? Were you in a band, or? +JESSICA: No, never was in a band. Actually, my dad and my uncle were drummers in a band. And as a kid, I would kind of pick up the drumsticks. And I remember my uncle kind of saying like, "Hey, is that Jessica down there?" Because I would sound like I was playing [laughs] something. Yeah, it took me a while to get into it. But during COVID, I picked it up and started practicing. +VICTORIA: I love that. So, do you have a whole drum set at home, or do you have one of those, like, electric? +JESSICA: I have both. I have the electric one, which I think I'm going to kind of get out and mess with. But I have an actual full drum set. It's like a TAMA light blue little set. +VICTORIA: That's so fun. I like playing the drums, but I never made the leap to actually own my own drum set. So, whenever my friends have it, though, I can play, like, maybe one or two beats on [laughs] it. Nothing that impressive, but yeah, it's a lot of fun. +JESSICA: Do you play any other instruments? +VICTORIA: Yeah, I've always...I played piano when I was younger, and then clarinet and bass guitar through, like, middle school and high school. I did have a band in college. We played two shows, and they were both at my house, which was a lot of fun. +JESSICA: [laughs] +VICTORIA: I had kind of stopped playing music, and then when COVID happened, it was like, well [laughs], I guess I need to find another hobby again. So, I picked up piano again. And now I've been playing keyboard and trying to sing at the same time, which has been entertaining for everyone in my household, so...[laughs] +JESSICA: Very cool. Too bad we didn't, like, catch up during COVID time. We could have started a band. +VICTORIA: Yes. Yeah. I'm trying to think of a way to get more disciplined about practicing, actually, because that's...I know people who practice for, like, three hours a day every day. And I'm just like, how do you make yourself sit there for that long [laughs]? +JESSICA: That's definitely been the challenge with me. And then, of course, being in a startup, and then, you know, that kind of got put on the backburner, but I hope to pick it up. +VICTORIA: Yeah, right? So, we met at San Diego Startup Week, which was a fantastic event here in San Diego; a different location every night and, different speakers, and all of these really interesting people to meet. So, why don't you tell me a little bit about what brought you to San Diego Startup Week? +JESSICA: Well, first things first is being a startup here in San Diego, so that made me go. And I knew it's very important, the more I'm realizing, to build your network and connect with people, and especially just within the community, getting yourself out there to be known, talking to other companies, even just showing your support to other startups. It's such an important thing to do. +VICTORIA: And your app, Flok22, specifically, solves some problems people might have with going to an event like that and trying to make friends and network with people. So, can you tell me a little bit more about the initial problem you had when you just came up with the idea for the app? +JESSICA: So, the initial problem was kind of around COVID time when everything opened back up. And there was this plethora of meetup apps that everybody was on trying to make these connections. And I would start to go out with friends, and as I'm looking around, it was that weird, awkward time where you couldn't talk to anybody you didn't come with. +And I would literally see people, including my friends, swiping on matching apps while they were sitting at the table, but nobody was talking to one another. And that's when I realized we needed something that was more venue-based, where it was like, hey, I'm here. I'm out. Let me see who's available to connect. And that's where the concept came about. +And then, during a lot of these networking events, I started to realize the same thing. It was people trying to network, and we're still doing the old-school name tags and signing our name on a paper. And it would just be so much more easier to have everybody on that one platform to connect with a little bit more effective and efficiently. +VICTORIA: And so, how long has it been since you had this idea and you've been in this journey with Flok22? +JESSICA: Well, it's been a little over two years. Right around COVID is when I got the idea. I was a hairdresser for, like, 20-plus years and wasn't working and at home with my three kids. And the idea just was kind of pricking at me. And it took me a while to try and figure out, you know, how can I do this? How can I, with no funds, you know, newly divorced, three kids, how am I going to start an app? And I just kept pushing on trying to connect with the right people and build a product. +VICTORIA: I love that. What inspired you? Like, you had this idea for an app. And you're like, you know what? I'm going to make it work. Like, what kept you going? What made you think this is a thing I can put my time and energy into and be successful? +JESSICA: You know, there's a lot of factors. I feel like it's just one of those things where you kind of just...you know how you just get that instinct and idea, and you're like, I just can't let it go? And I remember hitting a low point because I had tried to call different development teams. I had tried to do it on my own. And I felt like I wasn't getting anywhere. +And I was literally walking on a treadmill, and a friend gave me this YouTube thing to listen to, and it was Les Brown. And he was talking about if you were on your deathbed, you know, these ideas and these dreams, they're just staring you with angry eyes because they came to you for life. And it, like, hit me, like, very intensely to where I was like, I have to do this. I can't just look back in my life and be like, I had this idea. I know somebody's going to do it because everybody would be like, "This is a great idea." So, it's just a matter of you just got to keep going. +VICTORIA: Well, I'm glad that you're working on this because I can totally relate to that experience of, you know, for me, I came from Washington, D.C., and moved to San Diego. When I was in D.C., I had spent years in the meetup community and organizing meetups. And so, it got to the point where anytime I went to a meetup, I would know at least one person there. +And now coming to San Diego, like, starting it all over again, was very daunting. And, like, walking into...what was it? San Diego tech event where there's, like, 100 people in this beautiful Balboa Park location and just being so nervous [laughs]. I'm like, who do I talk to? Like, how do I get started? And you immediately think I should just leave and go home [laughs]. But let me get a glass of Chardonnay and go over to the craft makers table and make some art and then I'll, like, feel a little bit better. +So yeah, I'm curious, like, so you had this great idea. Like, you knew you wanted to put your effort into it. As you started going through the process of figuring out how to get started or how to find that market fit, was there anything that surprised you in your early stages that made you pivot into a new direction? +JESSICA: Well, I would say just, like, hearing your story, so many of us have been in that boat. I used to be a military wife, so I was always picking up and moving. And the older we get, it's hard to build and start up your network again. And I see a lot of people posting on Facebook or, you know, Instagram, and they're, like, putting their profile out there trying to make friends. So, there's definitely a need for it. +Originally, I wanted it more for the social aspect, which was coffee shops, bars, restaurants, being able to just check in and see who's there that is open to connect. One thing we did kind of start to realize is a lot of people, even though they want to make those connections, people are still nervous to claim that they're trying to, like, make a friend. So, the biggest thing that we learned in the product-market fit was people were more inclined to use it for networking. They felt a little bit more secure and safer that way. So, I would say that would be a thing that we kind of picked up on. +VICTORIA: Yeah, that makes sense. Because when I'm going to networking, like, of course, I would love to find leads for people who need consulting work from thoughtbot or software development or platform engineering. But if you go in with that intention, it's disingenuous, and it's not very effective. Whereas if you go into a networking event with the intention to make friends and just to learn about people and to find common interest, it's, like, indirectly aiming at your target is the best way to actually get there [laughs]. So, it makes sense. And so, you pivoted into more events and networking. Has there been anything that you've found about that experience or that group of people that's surprised you, or? +JESSICA: I do feel like the social side will pick up on it. I just think it's going to take a little bit more time. But with the networking, I wasn't really doing any of that until I got into this startup. So, I didn't even see the need for it until I got in there. And then here I am, you know, going to a table, trying to find my name tag, and everything's still very much old school when it comes to that. And so, that was what surprised me is just was, like, this would be perfect. Everybody's trying to exchange their LinkedIns. Everybody is trying to find the right person. +And sometimes you get stuck in a conversation with somebody for 20 minutes, and it's some sales guy from who knows where, and you're just like, uh, I'm not really looking for that. You know what I mean? Great to connect, but got to go. So, it's so much better to just find the right people that you're looking for and network more efficiently. +VICTORIA: Yeah, I don't know if this is that exact experience, but what I've kind of heard from other founders is sometimes you go to a networking event, and maybe you're looking for, like, mentors or people to help you or your own [inaudible 10:09]. And then there's more people trying to sell things to you [laughs] than there are, like, those actual people you're looking for who would help you. So, that's really interesting. So, now you've started to kind of really get involved in the networking. And I'm curious: how many events have you gone to so far this year? Do you have a rough estimate? +JESSICA: I'm, like, trying to think. It's, like, such a blur because I really have been going to so many. And also, I've been a part of the SDAC E-track, which is the Angel Conference, San Diego Angel Conference that's coming up. So, we're hoping to get accepted in that. I'm going to say, at least this month, probably 12, I would suspect. +VICTORIA: Wait, 12 this month? +JESSICA: I think so, yeah. And some of them have been little ones. Like, I've done some happy hour events. There's these really cool, like, social happy hour events I've been trying to kind of partner up with. So, definitely some smaller ones, and then some bigger ones, and then including my E-track. So, that's kind of the calculation I have. +VICTORIA: Wow, I mean, there's only been 15 days so far this month, so 13 events that's quite a lot [laughs]. I hope you do get some time to rest and play the drums later this month. But that's really exciting. So, I'm curious: as a founder, obviously, you have an event space networking app. But have you found other benefits from growing your network as an early-stage founder? +JESSICA: Definitely. The biggest impact is connecting with these people. And whether you read that book, "Rich Dad, Poor Dad," they say, you know, "Poor people look for work, and rich people build networks." And it's true because I'm noticing that for myself. You get around these people, and most of the time, they really do want to help, or you just need to have the ask, you know, ask what you're looking for. And they're more than willing to set you up with other people to get partnerships. +I ended up meeting somebody at the MIC Conference, which was in Vegas last month. And they connected me with somebody who now we are going to be partnering with them to have our app be used at their conference. So, it's as simple as that, just once you're in front of them and you get that more personal touch, and then they kind of refer you to other people. +VICTORIA: Oh, that's great. And how does your app compare to the existing apps that are out there for networking at events or for managing attendees at events? +JESSICA: Well, currently, there's not anything that's doing it in real-time. There is some conference events they have, like Cvent, Whova app. Personally, to me, it was just there's so much going on. You have the event, you know, vendors. You have the schedule. You have so much going on. And for us, our main thing is just connecting you to the right person. So, it's a more simplistic version of just being able to simply check in, see the profiles of the people that are there, see what it is that you're looking for, and know that you want to connect with them. +Also, the other feature that we have is allowing you to see anybody that you may have missed when you leave. So, you can kind of easily filter through those profiles and decide who to reach out to. I mean, similar to maybe, like, a meetup, but it's more just on demand. There quite hasn't been anything that's doing it right instantaneously. +VICTORIA: Yeah, and I can agree. I've used some of those apps before. And what I've noticed there's just not a ton of activity or user activity on the day of. And I'm curious to see...I really want to try out Flok, too. I know I'm like [laughs], I haven't had a chance to actually get in there yet, but it is on my to-do list. +So, I'm curious, you know, as someone who didn't have a background in technology or building applications, like, how did you go about getting up to speed and finding the people you needed to help you actually build the app? +JESSICA: Yeah, I mean, being a hairstylist, I was not tech at all. So, it's pretty interesting that here I am, you know, in this app development world. The main thing was just getting out there. I knew I had already been on so many apps just, whether it was some of the dating apps, meetup apps, so I knew how they operated and what I was looking for as a customer that I wanted to fix. +Most of the time, it was heavily with all these pictures, and prompts, and things like that, and I would get bored of setting it up. It would take me, like, you know, 30-plus minutes. Not to mention, I call it, like, adding people to your cart. It's just very impersonal. You got so many people just piling people to their cart. You might talk to them for a little bit, then stop. And I think people are just kind of getting over it. It's time-consuming. It's a lot of time and planning, and sometimes you plan something and then...even with the girls meeting a friend, it's like they plan something for Thursday, and somebody cancels, and then you're SOL, you know? +VICTORIA: Oh yeah. So, you had experience with using different apps for, like, networking or meeting people and making friends, and you saw that there was this gap. And then, how did you go to actually building the app? And were there any lessons that you learned in that process? +JESSICA: That was my experience and why I was doing that. The main thing I did after that was I started hitting up events to find and recruit. That was how I started finding...I met my co-founder through a mutual friend. She's been wonderful. She's, like, complete opposite of me. She's, like, the business-organized one. Like, hey, we need an LLC. We need this. We need that. I'm more just the idea and brains and kind of behind the scenes. Then I started going to some tech events, met our UI UX designer, Laura, who's been fantastic. +So, that would be my advice to people. If you're looking to build and you're trying to find the right people, of course, LinkedIn could be a good spot. Y Combinator could be a good spot. For me, I think going out there and actually making the personal connections and meeting the people and ask them and find what you're looking for. +VICTORIA: And you could now even use Flok22 to find your early founder team [laughs]. +JESSICA: Exactly. See? +VICTORIA: That's awesome. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: So, you went out, and you just met people, and you had this compelling vision of what you wanted to build and were able to recruit them onto your team. Was there anything...you know, you've been at this for two years now. Through the development process, was there anything you learned about what to do or what not to do in how you engage with your designers and developers? +JESSICA: You know, it's like, we dove out there, like, headfirst. And then there was a period of time where we needed to pause and re-calibrate, and that was due to the fact that you have to be very diligent in looking for development if you're outsourcing. If you know a CTO or you have somebody in-house that, you know, you're working with, you may not have the problems that we ran into. But with outsourcing, there's still very much a gray area. And we ended up getting a product that was not really functional and had a lot of issues, which caused a huge setback for us. It was a great, you know, lesson learned if that. But you have to be really particular on who you're finding. +I would suggest heavily on finding somebody that is a referral from somebody that you know, as a matter of fact, that they use. Because nowadays, there's times that they can almost, like, fake what they have. I mean, they might have references. They'll put stuff up on their website showcasing products that they did, and those aren't even products that they did. So, we ran into a huge deal with that. But it made us take a step back. We re-honed in on our user persona, had our UI UX designer redesign everything, and came back out here again. +VICTORIA: Yes, because people will let you pay them to build anything [laughs]. +JESSICA: Oh yeah. +VICTORIA: But it may not be exactly what you wanted. And what you said, going with someone who is a referral, going with someone who, I think, clearly demonstrates that they need to understand the underlying issue, as opposed to just being willing to take whatever requirements you have and build it. That's a big differentiator for companies. +And it can be frustrating because I think, you know, for thoughtbot, sometimes people come to us, and they're like, "We already have the designs. We already know what we want. You just build it for us." And we [inaudible 19:21], like, coach them around that. Like, are you sure? Like, let's look at your market validation, and let's look at your product fit. And, you know, let's go back and make sure that we're all aligned and that you're actually getting value out of something, and showing you the results on a regular basis, as opposed to it'll be done in three months, and you just wait until then. Sometimes, that can be $150,000 later, and, at the end, you're not actually getting a product that you really wanted. +JESSICA: Exactly. And like I said, there's still a big, gray area in that where, you know, you can be given a product, and it's not even barely working, or it looks like garbage. And you're kind of stuck because trying to go after these people to get your money back it's most likely not going to happen. And then you just lost out on all that money you put into that product. So, it can be very frustrating for people. +I hope to eventually kind of shed light on that and maybe help people along the way, so they don't fall trap to those type of kind of scammers that are out there for development. And I'm sure you, being CTO, you've seen a lot of that [chuckles]. +VICTORIA: Yeah, that's something we work really hard to kind of coach clients around and figure out to make sure because we don't want to end in that situation where our founder feels like we built something for them that doesn't work or doesn't look great, or what they're happy with [chuckles]. So yeah, I think it's very common. It happens to a lot of people. But I'm happy that you didn't get discouraged and you said, you know what? We can go for round two. Let's take what we learned and put it into the next version of the app. +And one of my favorite phrases from doing this podcast that I've heard is, "If the first product you build if you're proud of it, you didn't do it fast enough" [laughs]. So, like, usually, the first thing you build is not pretty, but you had to push through and build something. And that's the first application you've ever built. So, how did you feel about the second time going around? What did you do differently to be happier with and prouder of the product version that you put out there? +JESSICA: Yeah, I like that phrase, too, and sometimes I'm the same. It's kind of like, you know, fail fast and get out there. But the second build was definitely so much more smoother and better. But, actually, we are in transition to a newer, bigger development team because there's still some things that we're just not completely set on. And I do think that moving along to this next development team, there's a more better fit. +And then, we also received a grant from AWS to build a better back-end infrastructure, so when we do scale up, and there is more people on there, that it can withhold that capacity. So, I'm definitely happy with it right now. And I know that getting it out there—and you know this, too—is just getting it out there with all the users, you know, there may be some different feedback coming in and out. We plan on, you know, making any changes necessary if need be, and just kind of always making it a little better each time. +VICTORIA: Is that the AWS Activate program? +JESSICA: It's not the Activate, but it's just we're actually working with a company, and it was AWS. They had filled everything out for us, you know, they want to help startups getting out into the app world because, again, if we're making money, they're making money, too, with it being on their servers. So, it's kind of a win-win. And we can store all of that data and be able to scale up properly. +VICTORIA: Absolutely, yeah. And so, for those who don't know, the AWS Activate program, you can apply for up to $100,000 in free credits, and other cloud providers have similar programs where you can get free money [chuckles]. But, no, that's really cool that you're a part of that. So, what challenges do you see on the horizon for Flok22? +JESSICA: Of course, I hope there's going to be none, but we know in this entrepreneurial world, it's always there. I think, you know, the hard part are always going to be kind of those situations where maybe people aren't using the app properly or things of that sort happening. Other app companies have dealt with that. It's like, you could be out somewhere, and a situation happens. +So, that's kind of the only thing that I would be worried about is just ensuring the safety of all of our users, making sure that everybody is understanding. And I guess when that time comes and if there are things that, you know, come at you, it's just a matter of handling it. So, I hope it's not anything too heavy, but I guess we'll see. +VICTORIA: Yeah. Well, I appreciate you having that concern early on. Because I do feel like sometimes people create apps for networking and collaboration without thinking about the safety of their users. And it's more common from founders who have never been in a situation where they're unsafe [laughs]. So, like, maybe from your unique perspective, you, like, know that that is an issue that you might need to solve or that will come up, and having a plan for it makes sense. +JESSICA: We definitely have a plan for it. I mean, a lot of people don't realize with these apps that are out there, there's actually been a pretty high increase in, like, sex trafficking and different things. And most people don't know that because they're not the ones going in there and doing the market research. +So, our main thing is getting people out there to meet in public places, which is much safer. You're not, you know, getting lured and unsure if that's even the person who that they say they are, or you're going to someone's house or on a hike. It just makes it for a much safer environment. And then we're working on some other added features where, you know, you can kind of validate the people just to ensure that. +VICTORIA: Yeah, that makes sense. And what is the wind in your sails? What keeps you going and keeps you excited about working on this? +JESSICA: It's my passion. It's kind of like now; this has been my baby for a couple of years. So, of course, my family is always number one. I have three kids, a rat, two dogs, and a lizard. I adore my family, but I just have a passion for this. And I know that it's just a matter of time before this becomes a thing. And so, I just push myself on the daily trying to figure out the solutions and just keep moving forward with it. +VICTORIA: And what does success look like in six months, or even beyond that, in five years? +JESSICA: I think, for us, it will just be getting that heavy adoption of users, getting known out here in San Diego or in other parts. We plan on trying to hit more of the major cities where you got a lot of newcomers coming in and traveling, whether that's Chicago, New York, Miami, Vegas. As we get that adoption, just growing as a company and see where it goes from there. +VICTORIA: That's great. Yeah, I look forward to when I can go to a conference and just identify who are all the rock climbers in the room, and I can go bug and talk about [laughs], like, climbing with. I love that. +JESSICA: And, two, going to these conferences, also, not only your...you get to connect with the people that are there, but it's the people in the surrounding city, too. It's like a lot of people leave the conference, and they want to go to a bar or a coffee shop. And the fact that you have the option or opportunity to connect with the people who are there as well is a win-win. +VICTORIA: I love that, yeah. And do you have any questions for me about thoughtbot, or the podcast, or anything like that? +JESSICA: For me, you being, like, a CTO, I know you've maybe...have you seen apps like this become successful? I would love your take on kind of getting out there in the market for something like this because we are at that stage where we're trying to hit the market pretty heavily. We're hitting college campuses, you know, bigger conferences, trying to get that adoption in small clusters for it to be, you know, fun and usable for users. But I would love your take on that. +VICTORIA: Yeah, and, actually, I'm a managing director. Our CTO is Joe Ferris, who's currently my acting dev director for my team. But from my experience, you know, there might be a lot of competing apps who try to aim for similar things. But if you're very closely understanding your users and their needs and focusing on solving their problems, then you will find your niche, and you'll be able to be successful and grow that from there. So, if you have a strong vision for what the problem is and you're willing to actually listen to your users and pivot based off of that, that will set you up to be successful. +Yeah, and I've talked about this with other friends who are really into networking and meeting up with people. And there continues to be this gap of, like, how people communicate and how we actually connect. So, I think you're on the right track [chuckles], and you're doing a lot of great things. +And I think the only other advice I would say is what you've already kind of pointed out is to make sure you're not burning out early on and that you're taking that time and space to be with your family and to do your hobbies, and having a strong rest ethic as you do a work ethic and making sure you're still a whole person. And you'll make better decisions if you're giving your brain a little bit of downtime. +JESSICA: Definitely. I so agree with you. That's very important to have that balance. And we just hope that we can fill that gap when it comes to the networking. So, I hope that everyone can give it a try and see what they think. +VICTORIA: I love that, yeah. Is there anything else that you would like to promote? +JESSICA: I mean, honestly, this is not so much about me. I'm really passionate about this app and networking and connecting people together and getting it, so it's just more easy for everybody to connect out in person without wasting that time and energy. Just be out doing you and meet the right people. That's what Flok22 is all about. +VICTORIA: I love that. And we'll have to get together and play some music. I'll tell you the two songs I have memorized on piano right now are Kiss from a Rose by Seal and Someone Like You by Adele, so...[laughs] +JESSICA: Oooh. +VICTORIA: But we do have a bit of a girls' band going in San Diego, so we'll connect on that, too [laughs]. +JESSICA: Yeah, we'll have to link up. Add some drums to your... +VICTORIA: We don't have a drummer, so that's perfect, yeah [laughs]. +JESSICA: See? It's networking at its best [laughs]. +VICTORIA: Yes, yeah. I love it. Well, thank you so much for joining us today. I really appreciate hearing your story. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + In this episode, host Victoria Guido talks with Jessica Wallace, the CEO of Flok22, an innovative app designed to enhance real-time social networking. Victoria delves into Jessica's unique journey from her roots as a hairdresser to becoming a tech entrepreneur. They explore how Jessica's personal experiences and challenges, including being a military wife and navigating life post-divorce with three children, fueled her drive to create Flok22. Jessica's desire to connect people in real-time, especially in the post-COVID era, led to the birth of this groundbreaking app.

+ +

Victoria and Jessica discuss their mutual passion for music, revealing how their hobbies provide a creative outlet from the demanding world of startups. Jessica shares her aspirations to return to playing the drums, a skill inspired by her family's musical background, and her journey in learning the instrument during the pandemic.

+ +

On technology and entrepreneurship, Jessica dives into the challenges and triumphs of developing and marketing Flok22. She reflects on the importance of networking, particularly in the startup community, and how her app addresses the inefficiencies and awkwardness often encountered at networking events. Victoria and Jessica discuss the evolution of Flok22, emphasizing its focus on enhancing in-person connections and its pivot towards a more event-centric approach, as well as the future of networking, the potential of Flok22, and their shared enthusiasm for making meaningful connections, both professionally and musically.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jessica Wallace, CEO of Flok22, the app that helps you make friends and grow your network in real-time situations. Jessica, thank you for joining us.

+ +

JESSICA: Thank you for having me.

+ +

VICTORIA: Yeah. Well, just to get us started and warm up here, Jessica, is there any new skill or any skill you've come back to to practice more recently to kind of take your mind off of all the founder stuff that's happening?

+ +

JESSICA: Yeah. It's been a busy past two months of events and things like that. So, I've kind of been taking a little bit of downtime. I am hoping to start practicing the drums. I play those, and I haven't been doing that in a while. They've been kind of staring me down, so...

+ +

VICTORIA: So, were you a drummer before? Were you in a band, or?

+ +

JESSICA: No, never was in a band. Actually, my dad and my uncle were drummers in a band. And as a kid, I would kind of pick up the drumsticks. And I remember my uncle kind of saying like, "Hey, is that Jessica down there?" Because I would sound like I was playing [laughs] something. Yeah, it took me a while to get into it. But during COVID, I picked it up and started practicing.

+ +

VICTORIA: I love that. So, do you have a whole drum set at home, or do you have one of those, like, electric?

+ +

JESSICA: I have both. I have the electric one, which I think I'm going to kind of get out and mess with. But I have an actual full drum set. It's like a TAMA light blue little set.

+ +

VICTORIA: That's so fun. I like playing the drums, but I never made the leap to actually own my own drum set. So, whenever my friends have it, though, I can play, like, maybe one or two beats on [laughs] it. Nothing that impressive, but yeah, it's a lot of fun.

+ +

JESSICA: Do you play any other instruments?

+ +

VICTORIA: Yeah, I've always...I played piano when I was younger, and then clarinet and bass guitar through, like, middle school and high school. I did have a band in college. We played two shows, and they were both at my house, which was a lot of fun.

+ +

JESSICA: [laughs]

+ +

VICTORIA: I had kind of stopped playing music, and then when COVID happened, it was like, well [laughs], I guess I need to find another hobby again. So, I picked up piano again. And now I've been playing keyboard and trying to sing at the same time, which has been entertaining for everyone in my household, so...[laughs]

+ +

JESSICA: Very cool. Too bad we didn't, like, catch up during COVID time. We could have started a band.

+ +

VICTORIA: Yes. Yeah. I'm trying to think of a way to get more disciplined about practicing, actually, because that's...I know people who practice for, like, three hours a day every day. And I'm just like, how do you make yourself sit there for that long [laughs]?

+ +

JESSICA: That's definitely been the challenge with me. And then, of course, being in a startup, and then, you know, that kind of got put on the backburner, but I hope to pick it up.

+ +

VICTORIA: Yeah, right? So, we met at San Diego Startup Week, which was a fantastic event here in San Diego; a different location every night and, different speakers, and all of these really interesting people to meet. So, why don't you tell me a little bit about what brought you to San Diego Startup Week?

+ +

JESSICA: Well, first things first is being a startup here in San Diego, so that made me go. And I knew it's very important, the more I'm realizing, to build your network and connect with people, and especially just within the community, getting yourself out there to be known, talking to other companies, even just showing your support to other startups. It's such an important thing to do.

+ +

VICTORIA: And your app, Flok22, specifically, solves some problems people might have with going to an event like that and trying to make friends and network with people. So, can you tell me a little bit more about the initial problem you had when you just came up with the idea for the app?

+ +

JESSICA: So, the initial problem was kind of around COVID time when everything opened back up. And there was this plethora of meetup apps that everybody was on trying to make these connections. And I would start to go out with friends, and as I'm looking around, it was that weird, awkward time where you couldn't talk to anybody you didn't come with.

+ +

And I would literally see people, including my friends, swiping on matching apps while they were sitting at the table, but nobody was talking to one another. And that's when I realized we needed something that was more venue-based, where it was like, hey, I'm here. I'm out. Let me see who's available to connect. And that's where the concept came about.

+ +

And then, during a lot of these networking events, I started to realize the same thing. It was people trying to network, and we're still doing the old-school name tags and signing our name on a paper. And it would just be so much more easier to have everybody on that one platform to connect with a little bit more effective and efficiently.

+ +

VICTORIA: And so, how long has it been since you had this idea and you've been in this journey with Flok22?

+ +

JESSICA: Well, it's been a little over two years. Right around COVID is when I got the idea. I was a hairdresser for, like, 20-plus years and wasn't working and at home with my three kids. And the idea just was kind of pricking at me. And it took me a while to try and figure out, you know, how can I do this? How can I, with no funds, you know, newly divorced, three kids, how am I going to start an app? And I just kept pushing on trying to connect with the right people and build a product.

+ +

VICTORIA: I love that. What inspired you? Like, you had this idea for an app. And you're like, you know what? I'm going to make it work. Like, what kept you going? What made you think this is a thing I can put my time and energy into and be successful?

+ +

JESSICA: You know, there's a lot of factors. I feel like it's just one of those things where you kind of just...you know how you just get that instinct and idea, and you're like, I just can't let it go? And I remember hitting a low point because I had tried to call different development teams. I had tried to do it on my own. And I felt like I wasn't getting anywhere.

+ +

And I was literally walking on a treadmill, and a friend gave me this YouTube thing to listen to, and it was Les Brown. And he was talking about if you were on your deathbed, you know, these ideas and these dreams, they're just staring you with angry eyes because they came to you for life. And it, like, hit me, like, very intensely to where I was like, I have to do this. I can't just look back in my life and be like, I had this idea. I know somebody's going to do it because everybody would be like, "This is a great idea." So, it's just a matter of you just got to keep going.

+ +

VICTORIA: Well, I'm glad that you're working on this because I can totally relate to that experience of, you know, for me, I came from Washington, D.C., and moved to San Diego. When I was in D.C., I had spent years in the meetup community and organizing meetups. And so, it got to the point where anytime I went to a meetup, I would know at least one person there.

+ +

And now coming to San Diego, like, starting it all over again, was very daunting. And, like, walking into...what was it? San Diego tech event where there's, like, 100 people in this beautiful Balboa Park location and just being so nervous [laughs]. I'm like, who do I talk to? Like, how do I get started? And you immediately think I should just leave and go home [laughs]. But let me get a glass of Chardonnay and go over to the craft makers table and make some art and then I'll, like, feel a little bit better.

+ +

So yeah, I'm curious, like, so you had this great idea. Like, you knew you wanted to put your effort into it. As you started going through the process of figuring out how to get started or how to find that market fit, was there anything that surprised you in your early stages that made you pivot into a new direction?

+ +

JESSICA: Well, I would say just, like, hearing your story, so many of us have been in that boat. I used to be a military wife, so I was always picking up and moving. And the older we get, it's hard to build and start up your network again. And I see a lot of people posting on Facebook or, you know, Instagram, and they're, like, putting their profile out there trying to make friends. So, there's definitely a need for it.

+ +

Originally, I wanted it more for the social aspect, which was coffee shops, bars, restaurants, being able to just check in and see who's there that is open to connect. One thing we did kind of start to realize is a lot of people, even though they want to make those connections, people are still nervous to claim that they're trying to, like, make a friend. So, the biggest thing that we learned in the product-market fit was people were more inclined to use it for networking. They felt a little bit more secure and safer that way. So, I would say that would be a thing that we kind of picked up on.

+ +

VICTORIA: Yeah, that makes sense. Because when I'm going to networking, like, of course, I would love to find leads for people who need consulting work from thoughtbot or software development or platform engineering. But if you go in with that intention, it's disingenuous, and it's not very effective. Whereas if you go into a networking event with the intention to make friends and just to learn about people and to find common interest, it's, like, indirectly aiming at your target is the best way to actually get there [laughs]. So, it makes sense. And so, you pivoted into more events and networking. Has there been anything that you've found about that experience or that group of people that's surprised you, or?

+ +

JESSICA: I do feel like the social side will pick up on it. I just think it's going to take a little bit more time. But with the networking, I wasn't really doing any of that until I got into this startup. So, I didn't even see the need for it until I got in there. And then here I am, you know, going to a table, trying to find my name tag, and everything's still very much old school when it comes to that. And so, that was what surprised me is just was, like, this would be perfect. Everybody's trying to exchange their LinkedIns. Everybody is trying to find the right person.

+ +

And sometimes you get stuck in a conversation with somebody for 20 minutes, and it's some sales guy from who knows where, and you're just like, uh, I'm not really looking for that. You know what I mean? Great to connect, but got to go. So, it's so much better to just find the right people that you're looking for and network more efficiently.

+ +

VICTORIA: Yeah, I don't know if this is that exact experience, but what I've kind of heard from other founders is sometimes you go to a networking event, and maybe you're looking for, like, mentors or people to help you or your own [inaudible 10:09]. And then there's more people trying to sell things to you [laughs] than there are, like, those actual people you're looking for who would help you. So, that's really interesting. So, now you've started to kind of really get involved in the networking. And I'm curious: how many events have you gone to so far this year? Do you have a rough estimate?

+ +

JESSICA: I'm, like, trying to think. It's, like, such a blur because I really have been going to so many. And also, I've been a part of the SDAC E-track, which is the Angel Conference, San Diego Angel Conference that's coming up. So, we're hoping to get accepted in that. I'm going to say, at least this month, probably 12, I would suspect.

+ +

VICTORIA: Wait, 12 this month?

+ +

JESSICA: I think so, yeah. And some of them have been little ones. Like, I've done some happy hour events. There's these really cool, like, social happy hour events I've been trying to kind of partner up with. So, definitely some smaller ones, and then some bigger ones, and then including my E-track. So, that's kind of the calculation I have.

+ +

VICTORIA: Wow, I mean, there's only been 15 days so far this month, so 13 events that's quite a lot [laughs]. I hope you do get some time to rest and play the drums later this month. But that's really exciting. So, I'm curious: as a founder, obviously, you have an event space networking app. But have you found other benefits from growing your network as an early-stage founder?

+ +

JESSICA: Definitely. The biggest impact is connecting with these people. And whether you read that book, "Rich Dad, Poor Dad," they say, you know, "Poor people look for work, and rich people build networks." And it's true because I'm noticing that for myself. You get around these people, and most of the time, they really do want to help, or you just need to have the ask, you know, ask what you're looking for. And they're more than willing to set you up with other people to get partnerships.

+ +

I ended up meeting somebody at the MIC Conference, which was in Vegas last month. And they connected me with somebody who now we are going to be partnering with them to have our app be used at their conference. So, it's as simple as that, just once you're in front of them and you get that more personal touch, and then they kind of refer you to other people.

+ +

VICTORIA: Oh, that's great. And how does your app compare to the existing apps that are out there for networking at events or for managing attendees at events?

+ +

JESSICA: Well, currently, there's not anything that's doing it in real-time. There is some conference events they have, like Cvent, Whova app. Personally, to me, it was just there's so much going on. You have the event, you know, vendors. You have the schedule. You have so much going on. And for us, our main thing is just connecting you to the right person. So, it's a more simplistic version of just being able to simply check in, see the profiles of the people that are there, see what it is that you're looking for, and know that you want to connect with them.

+ +

Also, the other feature that we have is allowing you to see anybody that you may have missed when you leave. So, you can kind of easily filter through those profiles and decide who to reach out to. I mean, similar to maybe, like, a meetup, but it's more just on demand. There quite hasn't been anything that's doing it right instantaneously.

+ +

VICTORIA: Yeah, and I can agree. I've used some of those apps before. And what I've noticed there's just not a ton of activity or user activity on the day of. And I'm curious to see...I really want to try out Flok, too. I know I'm like [laughs], I haven't had a chance to actually get in there yet, but it is on my to-do list.

+ +

So, I'm curious, you know, as someone who didn't have a background in technology or building applications, like, how did you go about getting up to speed and finding the people you needed to help you actually build the app?

+ +

JESSICA: Yeah, I mean, being a hairstylist, I was not tech at all. So, it's pretty interesting that here I am, you know, in this app development world. The main thing was just getting out there. I knew I had already been on so many apps just, whether it was some of the dating apps, meetup apps, so I knew how they operated and what I was looking for as a customer that I wanted to fix.

+ +

Most of the time, it was heavily with all these pictures, and prompts, and things like that, and I would get bored of setting it up. It would take me, like, you know, 30-plus minutes. Not to mention, I call it, like, adding people to your cart. It's just very impersonal. You got so many people just piling people to their cart. You might talk to them for a little bit, then stop. And I think people are just kind of getting over it. It's time-consuming. It's a lot of time and planning, and sometimes you plan something and then...even with the girls meeting a friend, it's like they plan something for Thursday, and somebody cancels, and then you're SOL, you know?

+ +

VICTORIA: Oh yeah. So, you had experience with using different apps for, like, networking or meeting people and making friends, and you saw that there was this gap. And then, how did you go to actually building the app? And were there any lessons that you learned in that process?

+ +

JESSICA: That was my experience and why I was doing that. The main thing I did after that was I started hitting up events to find and recruit. That was how I started finding...I met my co-founder through a mutual friend. She's been wonderful. She's, like, complete opposite of me. She's, like, the business-organized one. Like, hey, we need an LLC. We need this. We need that. I'm more just the idea and brains and kind of behind the scenes. Then I started going to some tech events, met our UI UX designer, Laura, who's been fantastic.

+ +

So, that would be my advice to people. If you're looking to build and you're trying to find the right people, of course, LinkedIn could be a good spot. Y Combinator could be a good spot. For me, I think going out there and actually making the personal connections and meeting the people and ask them and find what you're looking for.

+ +

VICTORIA: And you could now even use Flok22 to find your early founder team [laughs].

+ +

JESSICA: Exactly. See?

+ +

VICTORIA: That's awesome.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So, you went out, and you just met people, and you had this compelling vision of what you wanted to build and were able to recruit them onto your team. Was there anything...you know, you've been at this for two years now. Through the development process, was there anything you learned about what to do or what not to do in how you engage with your designers and developers?

+ +

JESSICA: You know, it's like, we dove out there, like, headfirst. And then there was a period of time where we needed to pause and re-calibrate, and that was due to the fact that you have to be very diligent in looking for development if you're outsourcing. If you know a CTO or you have somebody in-house that, you know, you're working with, you may not have the problems that we ran into. But with outsourcing, there's still very much a gray area. And we ended up getting a product that was not really functional and had a lot of issues, which caused a huge setback for us. It was a great, you know, lesson learned if that. But you have to be really particular on who you're finding.

+ +

I would suggest heavily on finding somebody that is a referral from somebody that you know, as a matter of fact, that they use. Because nowadays, there's times that they can almost, like, fake what they have. I mean, they might have references. They'll put stuff up on their website showcasing products that they did, and those aren't even products that they did. So, we ran into a huge deal with that. But it made us take a step back. We re-honed in on our user persona, had our UI UX designer redesign everything, and came back out here again.

+ +

VICTORIA: Yes, because people will let you pay them to build anything [laughs].

+ +

JESSICA: Oh yeah.

+ +

VICTORIA: But it may not be exactly what you wanted. And what you said, going with someone who is a referral, going with someone who, I think, clearly demonstrates that they need to understand the underlying issue, as opposed to just being willing to take whatever requirements you have and build it. That's a big differentiator for companies.

+ +

And it can be frustrating because I think, you know, for thoughtbot, sometimes people come to us, and they're like, "We already have the designs. We already know what we want. You just build it for us." And we [inaudible 19:21], like, coach them around that. Like, are you sure? Like, let's look at your market validation, and let's look at your product fit. And, you know, let's go back and make sure that we're all aligned and that you're actually getting value out of something, and showing you the results on a regular basis, as opposed to it'll be done in three months, and you just wait until then. Sometimes, that can be $150,000 later, and, at the end, you're not actually getting a product that you really wanted.

+ +

JESSICA: Exactly. And like I said, there's still a big, gray area in that where, you know, you can be given a product, and it's not even barely working, or it looks like garbage. And you're kind of stuck because trying to go after these people to get your money back it's most likely not going to happen. And then you just lost out on all that money you put into that product. So, it can be very frustrating for people.

+ +

I hope to eventually kind of shed light on that and maybe help people along the way, so they don't fall trap to those type of kind of scammers that are out there for development. And I'm sure you, being CTO, you've seen a lot of that [chuckles].

+ +

VICTORIA: Yeah, that's something we work really hard to kind of coach clients around and figure out to make sure because we don't want to end in that situation where our founder feels like we built something for them that doesn't work or doesn't look great, or what they're happy with [chuckles]. So yeah, I think it's very common. It happens to a lot of people. But I'm happy that you didn't get discouraged and you said, you know what? We can go for round two. Let's take what we learned and put it into the next version of the app.

+ +

And one of my favorite phrases from doing this podcast that I've heard is, "If the first product you build if you're proud of it, you didn't do it fast enough" [laughs]. So, like, usually, the first thing you build is not pretty, but you had to push through and build something. And that's the first application you've ever built. So, how did you feel about the second time going around? What did you do differently to be happier with and prouder of the product version that you put out there?

+ +

JESSICA: Yeah, I like that phrase, too, and sometimes I'm the same. It's kind of like, you know, fail fast and get out there. But the second build was definitely so much more smoother and better. But, actually, we are in transition to a newer, bigger development team because there's still some things that we're just not completely set on. And I do think that moving along to this next development team, there's a more better fit.

+ +

And then, we also received a grant from AWS to build a better back-end infrastructure, so when we do scale up, and there is more people on there, that it can withhold that capacity. So, I'm definitely happy with it right now. And I know that getting it out there—and you know this, too—is just getting it out there with all the users, you know, there may be some different feedback coming in and out. We plan on, you know, making any changes necessary if need be, and just kind of always making it a little better each time.

+ +

VICTORIA: Is that the AWS Activate program?

+ +

JESSICA: It's not the Activate, but it's just we're actually working with a company, and it was AWS. They had filled everything out for us, you know, they want to help startups getting out into the app world because, again, if we're making money, they're making money, too, with it being on their servers. So, it's kind of a win-win. And we can store all of that data and be able to scale up properly.

+ +

VICTORIA: Absolutely, yeah. And so, for those who don't know, the AWS Activate program, you can apply for up to $100,000 in free credits, and other cloud providers have similar programs where you can get free money [chuckles]. But, no, that's really cool that you're a part of that. So, what challenges do you see on the horizon for Flok22?

+ +

JESSICA: Of course, I hope there's going to be none, but we know in this entrepreneurial world, it's always there. I think, you know, the hard part are always going to be kind of those situations where maybe people aren't using the app properly or things of that sort happening. Other app companies have dealt with that. It's like, you could be out somewhere, and a situation happens.

+ +

So, that's kind of the only thing that I would be worried about is just ensuring the safety of all of our users, making sure that everybody is understanding. And I guess when that time comes and if there are things that, you know, come at you, it's just a matter of handling it. So, I hope it's not anything too heavy, but I guess we'll see.

+ +

VICTORIA: Yeah. Well, I appreciate you having that concern early on. Because I do feel like sometimes people create apps for networking and collaboration without thinking about the safety of their users. And it's more common from founders who have never been in a situation where they're unsafe [laughs]. So, like, maybe from your unique perspective, you, like, know that that is an issue that you might need to solve or that will come up, and having a plan for it makes sense.

+ +

JESSICA: We definitely have a plan for it. I mean, a lot of people don't realize with these apps that are out there, there's actually been a pretty high increase in, like, sex trafficking and different things. And most people don't know that because they're not the ones going in there and doing the market research.

+ +

So, our main thing is getting people out there to meet in public places, which is much safer. You're not, you know, getting lured and unsure if that's even the person who that they say they are, or you're going to someone's house or on a hike. It just makes it for a much safer environment. And then we're working on some other added features where, you know, you can kind of validate the people just to ensure that.

+ +

VICTORIA: Yeah, that makes sense. And what is the wind in your sails? What keeps you going and keeps you excited about working on this?

+ +

JESSICA: It's my passion. It's kind of like now; this has been my baby for a couple of years. So, of course, my family is always number one. I have three kids, a rat, two dogs, and a lizard. I adore my family, but I just have a passion for this. And I know that it's just a matter of time before this becomes a thing. And so, I just push myself on the daily trying to figure out the solutions and just keep moving forward with it.

+ +

VICTORIA: And what does success look like in six months, or even beyond that, in five years?

+ +

JESSICA: I think, for us, it will just be getting that heavy adoption of users, getting known out here in San Diego or in other parts. We plan on trying to hit more of the major cities where you got a lot of newcomers coming in and traveling, whether that's Chicago, New York, Miami, Vegas. As we get that adoption, just growing as a company and see where it goes from there.

+ +

VICTORIA: That's great. Yeah, I look forward to when I can go to a conference and just identify who are all the rock climbers in the room, and I can go bug and talk about [laughs], like, climbing with. I love that.

+ +

JESSICA: And, two, going to these conferences, also, not only your...you get to connect with the people that are there, but it's the people in the surrounding city, too. It's like a lot of people leave the conference, and they want to go to a bar or a coffee shop. And the fact that you have the option or opportunity to connect with the people who are there as well is a win-win.

+ +

VICTORIA: I love that, yeah. And do you have any questions for me about thoughtbot, or the podcast, or anything like that?

+ +

JESSICA: For me, you being, like, a CTO, I know you've maybe...have you seen apps like this become successful? I would love your take on kind of getting out there in the market for something like this because we are at that stage where we're trying to hit the market pretty heavily. We're hitting college campuses, you know, bigger conferences, trying to get that adoption in small clusters for it to be, you know, fun and usable for users. But I would love your take on that.

+ +

VICTORIA: Yeah, and, actually, I'm a managing director. Our CTO is Joe Ferris, who's currently my acting dev director for my team. But from my experience, you know, there might be a lot of competing apps who try to aim for similar things. But if you're very closely understanding your users and their needs and focusing on solving their problems, then you will find your niche, and you'll be able to be successful and grow that from there. So, if you have a strong vision for what the problem is and you're willing to actually listen to your users and pivot based off of that, that will set you up to be successful.

+ +

Yeah, and I've talked about this with other friends who are really into networking and meeting up with people. And there continues to be this gap of, like, how people communicate and how we actually connect. So, I think you're on the right track [chuckles], and you're doing a lot of great things.

+ +

And I think the only other advice I would say is what you've already kind of pointed out is to make sure you're not burning out early on and that you're taking that time and space to be with your family and to do your hobbies, and having a strong rest ethic as you do a work ethic and making sure you're still a whole person. And you'll make better decisions if you're giving your brain a little bit of downtime.

+ +

JESSICA: Definitely. I so agree with you. That's very important to have that balance. And we just hope that we can fill that gap when it comes to the networking. So, I hope that everyone can give it a try and see what they think.

+ +

VICTORIA: I love that, yeah. Is there anything else that you would like to promote?

+ +

JESSICA: I mean, honestly, this is not so much about me. I'm really passionate about this app and networking and connecting people together and getting it, so it's just more easy for everybody to connect out in person without wasting that time and energy. Just be out doing you and meet the right people. That's what Flok22 is all about.

+ +

VICTORIA: I love that. And we'll have to get together and play some music. I'll tell you the two songs I have memorized on piano right now are Kiss from a Rose by Seal and Someone Like You by Adele, so...[laughs]

+ +

JESSICA: Oooh.

+ +

VICTORIA: But we do have a bit of a girls' band going in San Diego, so we'll connect on that, too [laughs].

+ +

JESSICA: Yeah, we'll have to link up. Add some drums to your...

+ +

VICTORIA: We don't have a drummer, so that's perfect, yeah [laughs].

+ +

JESSICA: See? It's networking at its best [laughs].

+ +

VICTORIA: Yes, yeah. I love it. Well, thank you so much for joining us today. I really appreciate hearing your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, host Victoria Guido talks with Jessica Wallace, the CEO of Flok22, an innovative app designed to enhance real-time social networking. Victoria delves into Jessica's unique journey from her roots as a hairdresser to becoming a tech entrepreneur. They explore how Jessica's personal experiences and challenges, including being a military wife and navigating life post-divorce with three children, fueled her drive to create Flok22. Jessica's desire to connect people in real-time, especially in the post-COVID era, led to the birth of this groundbreaking app.

+ +

Victoria and Jessica discuss their mutual passion for music, revealing how their hobbies provide a creative outlet from the demanding world of startups. Jessica shares her aspirations to return to playing the drums, a skill inspired by her family's musical background, and her journey in learning the instrument during the pandemic.

+ +

On technology and entrepreneurship, Jessica dives into the challenges and triumphs of developing and marketing Flok22. She reflects on the importance of networking, particularly in the startup community, and how her app addresses the inefficiencies and awkwardness often encountered at networking events. Victoria and Jessica discuss the evolution of Flok22, emphasizing its focus on enhancing in-person connections and its pivot towards a more event-centric approach, as well as the future of networking, the potential of Flok22, and their shared enthusiasm for making meaningful connections, both professionally and musically.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jessica Wallace, CEO of Flok22, the app that helps you make friends and grow your network in real-time situations. Jessica, thank you for joining us.

+ +

JESSICA: Thank you for having me.

+ +

VICTORIA: Yeah. Well, just to get us started and warm up here, Jessica, is there any new skill or any skill you've come back to to practice more recently to kind of take your mind off of all the founder stuff that's happening?

+ +

JESSICA: Yeah. It's been a busy past two months of events and things like that. So, I've kind of been taking a little bit of downtime. I am hoping to start practicing the drums. I play those, and I haven't been doing that in a while. They've been kind of staring me down, so...

+ +

VICTORIA: So, were you a drummer before? Were you in a band, or?

+ +

JESSICA: No, never was in a band. Actually, my dad and my uncle were drummers in a band. And as a kid, I would kind of pick up the drumsticks. And I remember my uncle kind of saying like, "Hey, is that Jessica down there?" Because I would sound like I was playing [laughs] something. Yeah, it took me a while to get into it. But during COVID, I picked it up and started practicing.

+ +

VICTORIA: I love that. So, do you have a whole drum set at home, or do you have one of those, like, electric?

+ +

JESSICA: I have both. I have the electric one, which I think I'm going to kind of get out and mess with. But I have an actual full drum set. It's like a TAMA light blue little set.

+ +

VICTORIA: That's so fun. I like playing the drums, but I never made the leap to actually own my own drum set. So, whenever my friends have it, though, I can play, like, maybe one or two beats on [laughs] it. Nothing that impressive, but yeah, it's a lot of fun.

+ +

JESSICA: Do you play any other instruments?

+ +

VICTORIA: Yeah, I've always...I played piano when I was younger, and then clarinet and bass guitar through, like, middle school and high school. I did have a band in college. We played two shows, and they were both at my house, which was a lot of fun.

+ +

JESSICA: [laughs]

+ +

VICTORIA: I had kind of stopped playing music, and then when COVID happened, it was like, well [laughs], I guess I need to find another hobby again. So, I picked up piano again. And now I've been playing keyboard and trying to sing at the same time, which has been entertaining for everyone in my household, so...[laughs]

+ +

JESSICA: Very cool. Too bad we didn't, like, catch up during COVID time. We could have started a band.

+ +

VICTORIA: Yes. Yeah. I'm trying to think of a way to get more disciplined about practicing, actually, because that's...I know people who practice for, like, three hours a day every day. And I'm just like, how do you make yourself sit there for that long [laughs]?

+ +

JESSICA: That's definitely been the challenge with me. And then, of course, being in a startup, and then, you know, that kind of got put on the backburner, but I hope to pick it up.

+ +

VICTORIA: Yeah, right? So, we met at San Diego Startup Week, which was a fantastic event here in San Diego; a different location every night and, different speakers, and all of these really interesting people to meet. So, why don't you tell me a little bit about what brought you to San Diego Startup Week?

+ +

JESSICA: Well, first things first is being a startup here in San Diego, so that made me go. And I knew it's very important, the more I'm realizing, to build your network and connect with people, and especially just within the community, getting yourself out there to be known, talking to other companies, even just showing your support to other startups. It's such an important thing to do.

+ +

VICTORIA: And your app, Flok22, specifically, solves some problems people might have with going to an event like that and trying to make friends and network with people. So, can you tell me a little bit more about the initial problem you had when you just came up with the idea for the app?

+ +

JESSICA: So, the initial problem was kind of around COVID time when everything opened back up. And there was this plethora of meetup apps that everybody was on trying to make these connections. And I would start to go out with friends, and as I'm looking around, it was that weird, awkward time where you couldn't talk to anybody you didn't come with.

+ +

And I would literally see people, including my friends, swiping on matching apps while they were sitting at the table, but nobody was talking to one another. And that's when I realized we needed something that was more venue-based, where it was like, hey, I'm here. I'm out. Let me see who's available to connect. And that's where the concept came about.

+ +

And then, during a lot of these networking events, I started to realize the same thing. It was people trying to network, and we're still doing the old-school name tags and signing our name on a paper. And it would just be so much more easier to have everybody on that one platform to connect with a little bit more effective and efficiently.

+ +

VICTORIA: And so, how long has it been since you had this idea and you've been in this journey with Flok22?

+ +

JESSICA: Well, it's been a little over two years. Right around COVID is when I got the idea. I was a hairdresser for, like, 20-plus years and wasn't working and at home with my three kids. And the idea just was kind of pricking at me. And it took me a while to try and figure out, you know, how can I do this? How can I, with no funds, you know, newly divorced, three kids, how am I going to start an app? And I just kept pushing on trying to connect with the right people and build a product.

+ +

VICTORIA: I love that. What inspired you? Like, you had this idea for an app. And you're like, you know what? I'm going to make it work. Like, what kept you going? What made you think this is a thing I can put my time and energy into and be successful?

+ +

JESSICA: You know, there's a lot of factors. I feel like it's just one of those things where you kind of just...you know how you just get that instinct and idea, and you're like, I just can't let it go? And I remember hitting a low point because I had tried to call different development teams. I had tried to do it on my own. And I felt like I wasn't getting anywhere.

+ +

And I was literally walking on a treadmill, and a friend gave me this YouTube thing to listen to, and it was Les Brown. And he was talking about if you were on your deathbed, you know, these ideas and these dreams, they're just staring you with angry eyes because they came to you for life. And it, like, hit me, like, very intensely to where I was like, I have to do this. I can't just look back in my life and be like, I had this idea. I know somebody's going to do it because everybody would be like, "This is a great idea." So, it's just a matter of you just got to keep going.

+ +

VICTORIA: Well, I'm glad that you're working on this because I can totally relate to that experience of, you know, for me, I came from Washington, D.C., and moved to San Diego. When I was in D.C., I had spent years in the meetup community and organizing meetups. And so, it got to the point where anytime I went to a meetup, I would know at least one person there.

+ +

And now coming to San Diego, like, starting it all over again, was very daunting. And, like, walking into...what was it? San Diego tech event where there's, like, 100 people in this beautiful Balboa Park location and just being so nervous [laughs]. I'm like, who do I talk to? Like, how do I get started? And you immediately think I should just leave and go home [laughs]. But let me get a glass of Chardonnay and go over to the craft makers table and make some art and then I'll, like, feel a little bit better.

+ +

So yeah, I'm curious, like, so you had this great idea. Like, you knew you wanted to put your effort into it. As you started going through the process of figuring out how to get started or how to find that market fit, was there anything that surprised you in your early stages that made you pivot into a new direction?

+ +

JESSICA: Well, I would say just, like, hearing your story, so many of us have been in that boat. I used to be a military wife, so I was always picking up and moving. And the older we get, it's hard to build and start up your network again. And I see a lot of people posting on Facebook or, you know, Instagram, and they're, like, putting their profile out there trying to make friends. So, there's definitely a need for it.

+ +

Originally, I wanted it more for the social aspect, which was coffee shops, bars, restaurants, being able to just check in and see who's there that is open to connect. One thing we did kind of start to realize is a lot of people, even though they want to make those connections, people are still nervous to claim that they're trying to, like, make a friend. So, the biggest thing that we learned in the product-market fit was people were more inclined to use it for networking. They felt a little bit more secure and safer that way. So, I would say that would be a thing that we kind of picked up on.

+ +

VICTORIA: Yeah, that makes sense. Because when I'm going to networking, like, of course, I would love to find leads for people who need consulting work from thoughtbot or software development or platform engineering. But if you go in with that intention, it's disingenuous, and it's not very effective. Whereas if you go into a networking event with the intention to make friends and just to learn about people and to find common interest, it's, like, indirectly aiming at your target is the best way to actually get there [laughs]. So, it makes sense. And so, you pivoted into more events and networking. Has there been anything that you've found about that experience or that group of people that's surprised you, or?

+ +

JESSICA: I do feel like the social side will pick up on it. I just think it's going to take a little bit more time. But with the networking, I wasn't really doing any of that until I got into this startup. So, I didn't even see the need for it until I got in there. And then here I am, you know, going to a table, trying to find my name tag, and everything's still very much old school when it comes to that. And so, that was what surprised me is just was, like, this would be perfect. Everybody's trying to exchange their LinkedIns. Everybody is trying to find the right person.

+ +

And sometimes you get stuck in a conversation with somebody for 20 minutes, and it's some sales guy from who knows where, and you're just like, uh, I'm not really looking for that. You know what I mean? Great to connect, but got to go. So, it's so much better to just find the right people that you're looking for and network more efficiently.

+ +

VICTORIA: Yeah, I don't know if this is that exact experience, but what I've kind of heard from other founders is sometimes you go to a networking event, and maybe you're looking for, like, mentors or people to help you or your own [inaudible 10:09]. And then there's more people trying to sell things to you [laughs] than there are, like, those actual people you're looking for who would help you. So, that's really interesting. So, now you've started to kind of really get involved in the networking. And I'm curious: how many events have you gone to so far this year? Do you have a rough estimate?

+ +

JESSICA: I'm, like, trying to think. It's, like, such a blur because I really have been going to so many. And also, I've been a part of the SDAC E-track, which is the Angel Conference, San Diego Angel Conference that's coming up. So, we're hoping to get accepted in that. I'm going to say, at least this month, probably 12, I would suspect.

+ +

VICTORIA: Wait, 12 this month?

+ +

JESSICA: I think so, yeah. And some of them have been little ones. Like, I've done some happy hour events. There's these really cool, like, social happy hour events I've been trying to kind of partner up with. So, definitely some smaller ones, and then some bigger ones, and then including my E-track. So, that's kind of the calculation I have.

+ +

VICTORIA: Wow, I mean, there's only been 15 days so far this month, so 13 events that's quite a lot [laughs]. I hope you do get some time to rest and play the drums later this month. But that's really exciting. So, I'm curious: as a founder, obviously, you have an event space networking app. But have you found other benefits from growing your network as an early-stage founder?

+ +

JESSICA: Definitely. The biggest impact is connecting with these people. And whether you read that book, "Rich Dad, Poor Dad," they say, you know, "Poor people look for work, and rich people build networks." And it's true because I'm noticing that for myself. You get around these people, and most of the time, they really do want to help, or you just need to have the ask, you know, ask what you're looking for. And they're more than willing to set you up with other people to get partnerships.

+ +

I ended up meeting somebody at the MIC Conference, which was in Vegas last month. And they connected me with somebody who now we are going to be partnering with them to have our app be used at their conference. So, it's as simple as that, just once you're in front of them and you get that more personal touch, and then they kind of refer you to other people.

+ +

VICTORIA: Oh, that's great. And how does your app compare to the existing apps that are out there for networking at events or for managing attendees at events?

+ +

JESSICA: Well, currently, there's not anything that's doing it in real-time. There is some conference events they have, like Cvent, Whova app. Personally, to me, it was just there's so much going on. You have the event, you know, vendors. You have the schedule. You have so much going on. And for us, our main thing is just connecting you to the right person. So, it's a more simplistic version of just being able to simply check in, see the profiles of the people that are there, see what it is that you're looking for, and know that you want to connect with them.

+ +

Also, the other feature that we have is allowing you to see anybody that you may have missed when you leave. So, you can kind of easily filter through those profiles and decide who to reach out to. I mean, similar to maybe, like, a meetup, but it's more just on demand. There quite hasn't been anything that's doing it right instantaneously.

+ +

VICTORIA: Yeah, and I can agree. I've used some of those apps before. And what I've noticed there's just not a ton of activity or user activity on the day of. And I'm curious to see...I really want to try out Flok, too. I know I'm like [laughs], I haven't had a chance to actually get in there yet, but it is on my to-do list.

+ +

So, I'm curious, you know, as someone who didn't have a background in technology or building applications, like, how did you go about getting up to speed and finding the people you needed to help you actually build the app?

+ +

JESSICA: Yeah, I mean, being a hairstylist, I was not tech at all. So, it's pretty interesting that here I am, you know, in this app development world. The main thing was just getting out there. I knew I had already been on so many apps just, whether it was some of the dating apps, meetup apps, so I knew how they operated and what I was looking for as a customer that I wanted to fix.

+ +

Most of the time, it was heavily with all these pictures, and prompts, and things like that, and I would get bored of setting it up. It would take me, like, you know, 30-plus minutes. Not to mention, I call it, like, adding people to your cart. It's just very impersonal. You got so many people just piling people to their cart. You might talk to them for a little bit, then stop. And I think people are just kind of getting over it. It's time-consuming. It's a lot of time and planning, and sometimes you plan something and then...even with the girls meeting a friend, it's like they plan something for Thursday, and somebody cancels, and then you're SOL, you know?

+ +

VICTORIA: Oh yeah. So, you had experience with using different apps for, like, networking or meeting people and making friends, and you saw that there was this gap. And then, how did you go to actually building the app? And were there any lessons that you learned in that process?

+ +

JESSICA: That was my experience and why I was doing that. The main thing I did after that was I started hitting up events to find and recruit. That was how I started finding...I met my co-founder through a mutual friend. She's been wonderful. She's, like, complete opposite of me. She's, like, the business-organized one. Like, hey, we need an LLC. We need this. We need that. I'm more just the idea and brains and kind of behind the scenes. Then I started going to some tech events, met our UI UX designer, Laura, who's been fantastic.

+ +

So, that would be my advice to people. If you're looking to build and you're trying to find the right people, of course, LinkedIn could be a good spot. Y Combinator could be a good spot. For me, I think going out there and actually making the personal connections and meeting the people and ask them and find what you're looking for.

+ +

VICTORIA: And you could now even use Flok22 to find your early founder team [laughs].

+ +

JESSICA: Exactly. See?

+ +

VICTORIA: That's awesome.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So, you went out, and you just met people, and you had this compelling vision of what you wanted to build and were able to recruit them onto your team. Was there anything...you know, you've been at this for two years now. Through the development process, was there anything you learned about what to do or what not to do in how you engage with your designers and developers?

+ +

JESSICA: You know, it's like, we dove out there, like, headfirst. And then there was a period of time where we needed to pause and re-calibrate, and that was due to the fact that you have to be very diligent in looking for development if you're outsourcing. If you know a CTO or you have somebody in-house that, you know, you're working with, you may not have the problems that we ran into. But with outsourcing, there's still very much a gray area. And we ended up getting a product that was not really functional and had a lot of issues, which caused a huge setback for us. It was a great, you know, lesson learned if that. But you have to be really particular on who you're finding.

+ +

I would suggest heavily on finding somebody that is a referral from somebody that you know, as a matter of fact, that they use. Because nowadays, there's times that they can almost, like, fake what they have. I mean, they might have references. They'll put stuff up on their website showcasing products that they did, and those aren't even products that they did. So, we ran into a huge deal with that. But it made us take a step back. We re-honed in on our user persona, had our UI UX designer redesign everything, and came back out here again.

+ +

VICTORIA: Yes, because people will let you pay them to build anything [laughs].

+ +

JESSICA: Oh yeah.

+ +

VICTORIA: But it may not be exactly what you wanted. And what you said, going with someone who is a referral, going with someone who, I think, clearly demonstrates that they need to understand the underlying issue, as opposed to just being willing to take whatever requirements you have and build it. That's a big differentiator for companies.

+ +

And it can be frustrating because I think, you know, for thoughtbot, sometimes people come to us, and they're like, "We already have the designs. We already know what we want. You just build it for us." And we [inaudible 19:21], like, coach them around that. Like, are you sure? Like, let's look at your market validation, and let's look at your product fit. And, you know, let's go back and make sure that we're all aligned and that you're actually getting value out of something, and showing you the results on a regular basis, as opposed to it'll be done in three months, and you just wait until then. Sometimes, that can be $150,000 later, and, at the end, you're not actually getting a product that you really wanted.

+ +

JESSICA: Exactly. And like I said, there's still a big, gray area in that where, you know, you can be given a product, and it's not even barely working, or it looks like garbage. And you're kind of stuck because trying to go after these people to get your money back it's most likely not going to happen. And then you just lost out on all that money you put into that product. So, it can be very frustrating for people.

+ +

I hope to eventually kind of shed light on that and maybe help people along the way, so they don't fall trap to those type of kind of scammers that are out there for development. And I'm sure you, being CTO, you've seen a lot of that [chuckles].

+ +

VICTORIA: Yeah, that's something we work really hard to kind of coach clients around and figure out to make sure because we don't want to end in that situation where our founder feels like we built something for them that doesn't work or doesn't look great, or what they're happy with [chuckles]. So yeah, I think it's very common. It happens to a lot of people. But I'm happy that you didn't get discouraged and you said, you know what? We can go for round two. Let's take what we learned and put it into the next version of the app.

+ +

And one of my favorite phrases from doing this podcast that I've heard is, "If the first product you build if you're proud of it, you didn't do it fast enough" [laughs]. So, like, usually, the first thing you build is not pretty, but you had to push through and build something. And that's the first application you've ever built. So, how did you feel about the second time going around? What did you do differently to be happier with and prouder of the product version that you put out there?

+ +

JESSICA: Yeah, I like that phrase, too, and sometimes I'm the same. It's kind of like, you know, fail fast and get out there. But the second build was definitely so much more smoother and better. But, actually, we are in transition to a newer, bigger development team because there's still some things that we're just not completely set on. And I do think that moving along to this next development team, there's a more better fit.

+ +

And then, we also received a grant from AWS to build a better back-end infrastructure, so when we do scale up, and there is more people on there, that it can withhold that capacity. So, I'm definitely happy with it right now. And I know that getting it out there—and you know this, too—is just getting it out there with all the users, you know, there may be some different feedback coming in and out. We plan on, you know, making any changes necessary if need be, and just kind of always making it a little better each time.

+ +

VICTORIA: Is that the AWS Activate program?

+ +

JESSICA: It's not the Activate, but it's just we're actually working with a company, and it was AWS. They had filled everything out for us, you know, they want to help startups getting out into the app world because, again, if we're making money, they're making money, too, with it being on their servers. So, it's kind of a win-win. And we can store all of that data and be able to scale up properly.

+ +

VICTORIA: Absolutely, yeah. And so, for those who don't know, the AWS Activate program, you can apply for up to $100,000 in free credits, and other cloud providers have similar programs where you can get free money [chuckles]. But, no, that's really cool that you're a part of that. So, what challenges do you see on the horizon for Flok22?

+ +

JESSICA: Of course, I hope there's going to be none, but we know in this entrepreneurial world, it's always there. I think, you know, the hard part are always going to be kind of those situations where maybe people aren't using the app properly or things of that sort happening. Other app companies have dealt with that. It's like, you could be out somewhere, and a situation happens.

+ +

So, that's kind of the only thing that I would be worried about is just ensuring the safety of all of our users, making sure that everybody is understanding. And I guess when that time comes and if there are things that, you know, come at you, it's just a matter of handling it. So, I hope it's not anything too heavy, but I guess we'll see.

+ +

VICTORIA: Yeah. Well, I appreciate you having that concern early on. Because I do feel like sometimes people create apps for networking and collaboration without thinking about the safety of their users. And it's more common from founders who have never been in a situation where they're unsafe [laughs]. So, like, maybe from your unique perspective, you, like, know that that is an issue that you might need to solve or that will come up, and having a plan for it makes sense.

+ +

JESSICA: We definitely have a plan for it. I mean, a lot of people don't realize with these apps that are out there, there's actually been a pretty high increase in, like, sex trafficking and different things. And most people don't know that because they're not the ones going in there and doing the market research.

+ +

So, our main thing is getting people out there to meet in public places, which is much safer. You're not, you know, getting lured and unsure if that's even the person who that they say they are, or you're going to someone's house or on a hike. It just makes it for a much safer environment. And then we're working on some other added features where, you know, you can kind of validate the people just to ensure that.

+ +

VICTORIA: Yeah, that makes sense. And what is the wind in your sails? What keeps you going and keeps you excited about working on this?

+ +

JESSICA: It's my passion. It's kind of like now; this has been my baby for a couple of years. So, of course, my family is always number one. I have three kids, a rat, two dogs, and a lizard. I adore my family, but I just have a passion for this. And I know that it's just a matter of time before this becomes a thing. And so, I just push myself on the daily trying to figure out the solutions and just keep moving forward with it.

+ +

VICTORIA: And what does success look like in six months, or even beyond that, in five years?

+ +

JESSICA: I think, for us, it will just be getting that heavy adoption of users, getting known out here in San Diego or in other parts. We plan on trying to hit more of the major cities where you got a lot of newcomers coming in and traveling, whether that's Chicago, New York, Miami, Vegas. As we get that adoption, just growing as a company and see where it goes from there.

+ +

VICTORIA: That's great. Yeah, I look forward to when I can go to a conference and just identify who are all the rock climbers in the room, and I can go bug and talk about [laughs], like, climbing with. I love that.

+ +

JESSICA: And, two, going to these conferences, also, not only your...you get to connect with the people that are there, but it's the people in the surrounding city, too. It's like a lot of people leave the conference, and they want to go to a bar or a coffee shop. And the fact that you have the option or opportunity to connect with the people who are there as well is a win-win.

+ +

VICTORIA: I love that, yeah. And do you have any questions for me about thoughtbot, or the podcast, or anything like that?

+ +

JESSICA: For me, you being, like, a CTO, I know you've maybe...have you seen apps like this become successful? I would love your take on kind of getting out there in the market for something like this because we are at that stage where we're trying to hit the market pretty heavily. We're hitting college campuses, you know, bigger conferences, trying to get that adoption in small clusters for it to be, you know, fun and usable for users. But I would love your take on that.

+ +

VICTORIA: Yeah, and, actually, I'm a managing director. Our CTO is Joe Ferris, who's currently my acting dev director for my team. But from my experience, you know, there might be a lot of competing apps who try to aim for similar things. But if you're very closely understanding your users and their needs and focusing on solving their problems, then you will find your niche, and you'll be able to be successful and grow that from there. So, if you have a strong vision for what the problem is and you're willing to actually listen to your users and pivot based off of that, that will set you up to be successful.

+ +

Yeah, and I've talked about this with other friends who are really into networking and meeting up with people. And there continues to be this gap of, like, how people communicate and how we actually connect. So, I think you're on the right track [chuckles], and you're doing a lot of great things.

+ +

And I think the only other advice I would say is what you've already kind of pointed out is to make sure you're not burning out early on and that you're taking that time and space to be with your family and to do your hobbies, and having a strong rest ethic as you do a work ethic and making sure you're still a whole person. And you'll make better decisions if you're giving your brain a little bit of downtime.

+ +

JESSICA: Definitely. I so agree with you. That's very important to have that balance. And we just hope that we can fill that gap when it comes to the networking. So, I hope that everyone can give it a try and see what they think.

+ +

VICTORIA: I love that, yeah. Is there anything else that you would like to promote?

+ +

JESSICA: I mean, honestly, this is not so much about me. I'm really passionate about this app and networking and connecting people together and getting it, so it's just more easy for everybody to connect out in person without wasting that time and energy. Just be out doing you and meet the right people. That's what Flok22 is all about.

+ +

VICTORIA: I love that. And we'll have to get together and play some music. I'll tell you the two songs I have memorized on piano right now are Kiss from a Rose by Seal and Someone Like You by Adele, so...[laughs]

+ +

JESSICA: Oooh.

+ +

VICTORIA: But we do have a bit of a girls' band going in San Diego, so we'll connect on that, too [laughs].

+ +

JESSICA: Yeah, we'll have to link up. Add some drums to your...

+ +

VICTORIA: We don't have a drummer, so that's perfect, yeah [laughs].

+ +

JESSICA: See? It's networking at its best [laughs].

+ +

VICTORIA: Yes, yeah. I love it. Well, thank you so much for joining us today. I really appreciate hearing your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+68YHwO23 + + ]]> + + Victoria Guido + + + thoughtbot's Incubator Program Mini Session 3: Episode 07: Knect with Josh Herzig-Marx + https://podcast.thoughtbot.com/s3e7incubatorknect + 58e20919-712f-47e0-8cd0-023ad905707f + Tue, 16 Jan 2024 00:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + Josh Herzig-Marx, founder of Knect, discusses the latest developments in his startup journey since his last appearance on the show. He emphasizes the program's value in helping founders like himself refine ideas and strategies. He particularly notes the program's effectiveness in addressing challenges unique to startups, such as managing professional networks and dealing with the rapid growth of online presence. + +The conversation also delves into AI's technical aspects and potential applications and the practicalities and ethical considerations of using it in professional networking. Josh and Jordyn explore various AI use cases, distinguishing between beneficial applications and those they deem undesirable. + 38:23 + no + + + If you missed the other episodes with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can listen to Josh's first episode (https://www.giantrobots.fm/incubators3e1josh), his second (https://www.giantrobots.fm/s3e3incubatorjosh), an his third (https://podcast.thoughtbot.com/s3e5incubatorknect) to catch up. +Josh Herzig-Marx, founder of Knect, discusses the latest developments in his startup journey since his last appearance on the show. He emphasizes the program's value in helping founders like himself refine ideas and strategies. He particularly notes the program's effectiveness in addressing challenges unique to startups, such as managing professional networks and dealing with the rapid growth of online presence. +The conversation also delves into AI's technical aspects and potential applications and the practicalities and ethical considerations of using it in professional networking. Josh and Jordyn explore various AI use cases, distinguishing between beneficial applications and those they deem undesirable. +Transcript: +LINDSEY: We are back for our Incubator update with Josh Herzig-Marx and his startup, Knect. I'm Lindsey Christensen. I do marketing things at thoughtbot. We are also joined by Jordyn Bonds, who runs our incubator and does product strategy for thoughtbot. And today, we're going to be catching up with Josh and learn what's new since last we checked in. But before we get to that, we have an exciting incubator update: our application window has just reopened. +JORDYN: Yes. +LINDSEY: You could be the next Josh. +JORDYN: You could. +JOSH: Don't be me. You should join the incubator. +[laughter] +JORDYN: Go to thoughtbot.com/incubator and apply. It's just that easy. The application doesn't take long, even though it's in Typeform, and we have gotten some feedback, including from Josh, that it's challenging to plan your application efforts because, as you all probably know, Typeform just gives you one question at a time. So, sorry, maybe we'll update that. But it won't take you very long. It's a pretty brief application. And we are looking for pre-product folks, so you don't have to have a lot. Don't worry about what you do or don't have. Just apply. +LINDSEY: Pre-product founder trying to figure out, is this problem worth solving? Who is it for? Jordyn and the team can help you out. thoughtbot.com/incubator. +JOSH: And me. +LINDSEY: And Josh. +JOSH: And if, for some reason, you want to ask somebody about the program who isn't directly affiliated with thoughtbot, you should reach out to me. I'd be happy to talk about my experience. +LINDSEY: You should. +JOSH: I'd be happy to tell you what I think would be some reasons to join and some reasons that it might not be a good fit for you. And I'd be happy to chat about any of those things. It'd be my pleasure, in fact. +LINDSEY: That is a great offer. +JORDYN: It is a great offer. You all should take Josh up on that offer. He is an excellent sounding board and mentor. And additionally, if you get into the incubator, you'll just be in a Slack channel with Josh for the rest of time, inside of thoughtbot's Slack. So, that's another [crosstalk 02:05] +JOSH: Statistically, there's a good chance you already are. +[laughter] +JORDYN: You mean in a slack with you. That's true. Josh is in a lot of Slacks, not [crosstalk 02:14]. +LINDSEY: Yeah. Once you go through the incubator, you're family for life. +JORDYN: You're family. You're here. You're with us. You can't get rid of us. +LINDSEY: And you're able to hit us up with the questions, talk to the other founders, so that's another great benefit of participating. All right, but topic of the hour, Josh, hey, how are you? How you doing? +JOSH: Lindsey, I am floating right now. We had our end of incubator session last official meeting. And we reviewed how we started, what we hope to accomplish, what we actually did accomplish, and next steps, and it feels really awesome. +LINDSEY: It does. That's so great to hear. And can you, at the top here, maybe remind folks who haven't listened before, you know, what was that beginning point that you came in the incubator or the problem that you were looking to solve? +JOSH: So, I had this Josh problem, which is that I am overwhelmed by the number of places that I am online and by the rapid increase in my professional network, professional social network, I guess you could say, but in my professional network, you know, see that comment a few minutes ago about how we're probably already in multiple Slacks together, whoever you happen to be online. Plus, if you're on LinkedIn, we're probably at least secondary connections on LinkedIn. Like, there's an awful lot of people, and it's growing really, really fast. +And as somebody with a whopping case of ADD, which just feels like making an excuse, as somebody in, like, this modern world, I was feeling overwhelmed, and I felt like I was dropping the ball. And my problem was somebody must have a solution to this. I cannot be the only one. I could not find a solution myself. And I thought, well, maybe if there is no existing solution, maybe we should just go ahead and build it. And that was the genesis of my application to the thoughtbot incubator, which was that even though I've done this once before, I had never done this alone. I don't want to do this alone. +And I thought that, you know, because of my experience with thoughtbot in the past and my understanding of, like, thoughtbot's unique organizational skills and capacities, this would be a particularly good fit for the thing that I wanted to figure out. And when I say figure it out, there was really four things I was hoping to get from this program. Let's see if I can remember them all in order. Number one, is this a Josh problem, or is this a broader problem affecting more people? Number two, this is, like, a ladder of problems, right? Like a cascading set. +Number two thing I was trying to figure out: if this isn't just a Josh problem, is there at least one identifiable and addressable set of people who think about this problem in a similar way with whom I could engage? Number three, if there is such a group, are they willing, ready, and able to, like, spend money on solving this problem? And then number four, which I guess is kind of orthogonal to the other ones, it's kind of alongside, is this thing to solve even technically feasible, right? +Because you can have this, like, amazing opportunity, but you just can't build it. And, you know, is this a thing that we could build or that I could get built within the resources that I might have? And I came in with some hypotheses, with some ideas. It's not like I had never done any research in this at all. But coming out of it, we have four pretty good answers. And I would not have been able to reach those answers with the same level of confidence, certainly not within eight weeks, if I hadn't gone through the incubator, and it's a really nice way to end the year. +LINDSEY: With a bow on it. The last time we talked, you had narrowed in, I think, on your starting target market. And you had also recently introduced a prototype into the mix. How has the prototype evolved? +JOSH: It's...and this is going to be no surprise to either of you or anybody who's listening. But, like, the difference between, like, talking about something in the abstract and actually having, like, a thing in your hand is night and day. So, the prototype actually evolved pretty rapidly. You know, it allowed us to try using it, like, to put on our own empathetic user analog hats and try it ourselves and be like, "Well, this doesn't quite make sense." This doesn't actually flow right. And it allowed us to show it to a lot of people. +I'll say, we are, by far, our own strongest critics, which is good. Mostly, when we showed it to people, people are like, "This is amazing." And they would ask us, like, really specific, weird questions like, "Where's, you know, your about page? Could I see your privacy policy?" which is, like, a really, really good thing to hear. Because if the only thing...one way to interpret that is the only thing keeping them from maybe, like, diving in and using it right now, besides it doesn't actually exist as a product, is, like, some questions around privacy because it seems maybe too good to be true. Like, that's a pretty good buy sign. +You know, we were expecting, like, "The screen makes no sense. Why are we swiping here? Where does this data come from? Is this really complete?" They're like, "No, I'm pretty much ready to go." So, that was good, helpful feedback, though we evolved it ourselves a lot internally. It's really nice having a thing. Do we use the term Pinocchio prototype or Pinocchio test [crosstalk 06:58]? +LINDSEY: Yes, I did hear that. +JOSH: Yeah, I like that. If this was like, you know, this wooden toy wanted to be a real boy, like, two weeks ago, it really, really wants...I don't know, Lindsey, we should, you know, get you in front of it. You're going to be like, "Why can't I use this today?" +[laughter] +JORDYN: That's definitely what we're hearing from people. +JOSH: And my answer would be, "Well, you can't, but maybe in a couple of weeks." [laughs] +JORDYN: Yeah, exactly. I will say I want to say for anyone listening in, though, that that was not, getting to what Josh just described where folks weren't really...they didn't have any hang-ups about the functionality or the value prop. They were basically just like, "What's your privacy policy? And when is it going to be ready for me to use?" It's not like the first draft of this prototype that was what we jumped to. I want to be clear. +The first time we showed someone, there was this interesting problem, which is that we were still talking to the wrong people, somewhat. And the prototype hadn't evolved to be the slam dunk that it is now. So, at first, it was like, we'd have these kinds of muddled conversations where people were like, "Well, I don't really understand what this is supposed to be, and I'm not sure about that. And this seems interesting," but then their interpretation of what that thing was would be, like, wildly off from what it was intended to be. I just want to make it clear: this was work and effort. +And the team did a really great job of iterating quickly based on, like, every time we talked to someone and showed it to them, we'd come back and say, "Here's what I heard." And it really pushed our thinking forward. Like Josh said, like, we are our toughest critics, so, like, every new version unlocked some new insights in ourselves about what it was we were actually driving toward. Really, just there's nothing like having a thing to look at and bang on to, like, clarify your thinking. +LINDSEY: There's nothing like having a thing. Jordyn, you touched on you were talking to the wrong people, maybe. How has that exploration of the core market evolved? Is it still the startup enthusiasts? Are you even more narrow in that? What are the updates there as our chief market focus get everyone thinking about this all the time, officer? +JORDYN: Yes. So, you know, startup enthusiasts is still the umbrella. What you're looking for with this is that you can guarantee pretty much every time you talk to someone in a segment or a sub-segment you will know how the conversation is going to go. And we've gotten there with two sub-segments of startup enthusiasts, which is repeat founders, key, key kind of nuance there. Founders, sure, but repeat founders really have this problem, for reasons we could talk about, and then chiefs of staff at startups, which is a relatively new role that's sort of emerged over the last sort of several years. +But those folks are really the people that you ask them about this pain point, and they immediately are, like, yes. They use the same words to talk about the pain point. That's another really strong signal. When folks are using the same vocabulary, and they say the same sentences in the same order, and you start to feel a little bit creeped out, like, you're like, "Did you see these questions before I...? What? Did someone pay you to say that?" is, like, how you start to feel [laughs] [crosstalk 09:59] +LINDSEY: Also, a marketer's dream. Oh my gosh, here comes the messaging, right? +JORDYN: Exactly. +LINDSEY: [inaudible 10:04] +JORDYN: It feels like a cheat code because you just get to reflect their language back to them. You don't have to write copy. They wrote the copy. You just show them it, and they're like, yes. And everyone's like, "Yes," and it works. +LINDSEY: Any thoughts to add to that, Josh? +JOSH: It's really good. I would say the bummer or the good thing about this point is we're getting diminishing returns from testing everything other than the actual product, which is good that we got there in eight weeks. But we're not going to learn, you know, keep on adjusting the prototype and making little tweaks and more user research. But the truth is, we're not going to get anything substantial until we get this into some users' hands. +JORDYN: Like you say, this is sort of bad news, but it's good news. +JOSH: Right. +JORDYN: It's how you know, right? When you get to the point where the thing is so clear, and the way to talk about it with folks is so clear that you're not learning as much anymore, diminishing returns is the right way to frame it. You really just need people to get in there and use it. That's the only way you're going to keep learning. That's the moment to build. Hey, everyone out there, don't build before that. That's when you build. And then you really build the smallest thing you can conceive of building, and then whatever that thing is that you've conceived of building that's very small, scope it back by 50% [laughs]. Do it. +JOSH: And it's a little humbling as someone who considers himself a founder but who had reasonable success as a founder and who has had pretty good success as, like a very, very early-stage, you know, zero to one and 1 to 10 product leader, has done this a bunch of times and actually coaches people in doing this, and came in with, I'm not going to lie, a pretty good vision in my head for how this stuff was supposed to work together. And it's so much better now. +Going through a process actually makes things better. This wasn't just, like, wasting time. Like, going through a process, a thoughtful process actually makes us much better. Like, the thing we're talking about building is much more likely to be successful than the thing I was originally thinking about building, right, Jordyn? +JORDYN: Yes. I guess it bears sort of diving into that a little bit, which is, you know, for all the founders out there or folks with a product idea kicking around your head, you're apt to have a little bit of everything we've talked about already. You have an idea of the solution you want to build. You have an idea of who it's for. You have an idea of what their pain points are. And you might be sitting there thinking to yourself, I don't need to do eight weeks of discovery. I already know the answers to all of these questions. +And it's possible Josh felt that way coming into the incubator, but doing the work, gathering the data, talking to a ton of people, what you can't understand before doing that is how much more confident and at ease you will feel once you have done it and how much clarity you'll have about what it is you need to build first because likely, you're sitting there with a vision in your head for this product that is fully featured, fully formed. +It is the 18th month. We just went into a hidey hole and built a really complex thing, thing. Cool, don't throw that out. But you got to begin somewhere, and you got to begin somewhere meaningful and valuable. And it's really hard to know where to begin without this discovery, without focusing on a specific person, talking to as many of those folks as you can. And really, it sort of writes itself. It does feel easy. But you've got to set aside the time and the effort to do the research, market research, whatever we call this, customer discovery. +And it thrills me to no end, Josh, to hear that that is how it felt for you, that you probably felt like you already knew the answer. But it just feels different, having talked to, I mean, how many people, 100-plus people? We were looking at the stats. +JOSH: Well over 100. +LINDSEY: Josh was talking to a bunch of people before he came to the incubator, and all the founders that we accept have been doing that. Like, we want to know that you've been doing that research. But then, I guess, coming into the incubator, you're continuing that process and maybe in a more structured or a differently structured way where the thoughtbot team is helping you, maybe zero in far deeper on the segment. Is that accurate to say? Just kind of the difference between, like, maybe some of the pre-research and then the thoughtbot-specific user interviews that happen. +JOSH: Yeah. I think they were more focused. They're both more focused from the audience, but also more focused from if it's not just you doing it; it forces you to have a more clear, here's the questions we're asking, and here's what we're trying to learn, all these conversations. +It's also really nice to have some diversity in who's asking the questions. As good or bad as I am at user research and user discovery, I am only one person. And having people with different backgrounds professionally, who live in different countries, who have different feelings about social media, basically, who are not me in a variety of really interesting ways, I think, made the entire process more interesting. +Caro, who is our lead designer on the project, handed off basically the summary document of, like, everything we learned, and she pulled out, like, little snippets from the interviews. First of all, that is not something I would have done had it been just me, like, let's be very, very clear. This is an incredibly valuable document, particularly as we consider adding additional people onto this project to be able to, like, translate insights. But also, like, this is, like, summarized in a way that, like, takes some real expertise. And I would have walked away with vibes, and instead, we walked away with like, structured learning. +LINDSEY: Awesome. So, the last time we checked in, also, you were very excited because you had just maybe started a technical spike and were starting to dig into the, okay, like, how technically feasible is this product? And I think, at that point, you all were looking at circling around this target market. Here are the main tools they use to communicate. What does it even look like to connect with those APIs? How possible is it? Can you give us an update on some of that work? +JOSH: The way that I framed the question in the very beginning was, is this a science project, or is this going to be engineering? And, for the most part, the answer is, it's going to be engineering, right? Some are a little bit easier; some are a little bit harder. But it isn't, like, reinventing new stuff, with one exception, and that is connecting up with iMessages, which has been in the news a little bit. And I honestly just hope the ghost of Steve Jobs comes back and haunts, you know, the Apple headquarters at Cupertino because, come on, guys, interoperability is sort of the future, and you're ruining it for everybody. +But other than that, I think we have a pretty clear path. I'd like to test out some of these. Like, you don't really know until you do it. I think that's kind of the next step of what we're doing is to, like, demonstrate that it is possible for a person to connect up a couple of different accounts. It is possible for us to extract data and turn that into information and insights in the kinds of ways we thought we could and then present that back in a meaningful way. I think that would be the next step for us to do. Mostly, everything seems feasible, except for iMessages. +LINDSEY: I've also, I think, heard some whispers of artificial intelligence for Knect. Is that true? Have you all looked at, you know, what AI's role could be in the solution? And how does that research look? +JORDYN: We assume it will be part of the mix. That said, I don't know how to frame it exactly. It's not like it's not an essential ingredient. I think the work with large language models and the democratization of that work recently is absolutely going to make this product way better than it would have otherwise been. But there are a lot of heuristics we've, like, been able to, you know, draw out and come up with that are, frankly, algorithmic, and they're not AI necessarily. Now, the line between big data plus an algorithm and AI in the popular lexicon, like, there's a big difference between those two things. But, like, as people talk about it, yeah, where does one end and the other begin? +But we definitely will be making use of a lot of the newest technologies, and we've dabbled in them. I've dabbled in them. I know, Josh, you've been playing around with some of them, too, to the point where we're like, okay, yeah, we can make use of this stuff. It will be a valuable kind of tool in our toolkit, but it will not be the sole basis of value. I guess that's the sort of nuanced answer. But maybe Josh has a more bite-sized hype machine answer to this. Yeah, AI to the moon, right? +JOSH: Um, no. My only answer would be more cynical. Would anybody rightfully start a company in 2023 without having AI in there someplace? Maybe I'll say something different. One of the things that we've wondered is, there's more than a handful of companies that are adjacent to what we're doing that are definitely looking at similar kinds of problems and that aren't building the solution that, clearly, some market is, like, desperate for. And these are not, like, wildly successful companies that have grown astronomically and changed the market. And, like, trying to figure out, like, why is that? +And one of the reasons is...I sound like a tech bro, right? There has been a paradigm shift in the technology world, but there really has been. What do, you know, publicly available LLMs like, you know, OpenAI's ChatGPT, like, what have they done? They have taken a whole set of problems that were once really, really complicated and allowed you to do a reasonable job of solving them much more easily than you ever could before. +And it takes some amount of imagination, to realize that, to realize that these things are more than just, I mean, every product I have on my computer has some kind of OpenAI ChatGPT-style thing in there, right? It's, like, 16 different variations on give me a prompt, and I'll write your essay for you, and they all kind of suck. But those aren't the really exciting uses that I've seen. It's the more subtle things. +There's a company called Booklet, which tries to replace, like, noisy email lists or noisy communities to something more calm. And one of its features is it'll send you a summary of what's been going on in the community since, like, the last time you checked in. And it gives you, like, two paragraphs to read, and they're really chill and really informative, and they don't make you feel FOMO. They don't make you feel stressed up. Like, okay, stuff's happened in the community. This is really neat. And it's all powered by OpenAI's APIs. And it's really kind of magical. And, like, you have to have a slightly different perspective to imagine these kinds of magical moments. So, that's what I'm excited about. +There's a set of things that we would have had to do with, like, terrible, complicated queries and, like, pattern matching, and freaking grep, or whatever old-school tools we would have had, you know, for doing things in the past. And now you just get to, like, shove text in one end, and say how you want the results structured and get the results back in the other end. And it doesn't have to be perfect, but that's okay. Like, we're talking about human relationships, which are inherently imperfect. So, I'm fine with this. And it's kind of exciting. +But we'll see in, you know, if we end up continuing going down this path. Like, that's the goal of the next stage is to be, like, okay, what are the easy things which we can generate out of this? Is there an intersection between, like, easy and meaningful? And if there is, this is pretty exciting. +JORDYN: Can I add something to that? Which is that the problem Knect is trying to solve and the way that we're trying to solve it, the way we've thought of solving it that's differentiated, lends itself really well to the current landscape of AI tools in that, and you were kind of getting at this, Josh, but I feel like it bears drilling into a little bit, in that what we are proposing here is not a set of deterministic things. We're not going to give you a to-do list. It's not, like, a linear...deterministic is really the right word. Like, there's a to-do list. There are things that make the cut. You got to go address them, et cetera. +We're way more trying to approximate the way a slightly more put-together person with more time would approach nurturing their relationships, which is just to remember more of it more of the time. It doesn't mean we need to remember all of it every time. That's not the kind of task this is, which makes it a really good task for the place that AI is at right now. +And I think where folks have failed in the past is that they've either tried to turn it into a deterministic set of tasks, which then just feels like another to-do list, another inbox in a series of to-do lists and inboxes that you have in your life that just make you feel guilty and inadequate. That doesn't seem fun to us. We don't think you need another one of those. Or other places we've seen this fall down, which is that it takes the current sort of state of AI and tries to actually do the deterministic thing for you, but it doesn't do a good enough job right now. +But where we've kind of landed in the middle is that, again, what we're trying to solve for is solvable in a way more probabilistic way. Like, can we get more of this accomplished more easily for you? It's never going to, like, completely, you know, do the task in this perfect deterministic way. But it is going to make you feel more confident and more relaxed à la Booklet, it sounds like, how to do that for this particular problem, which is a different bar and one we think we can clear. And that really does provide value. People are really longing for this. +LINDSEY: Jordyn and Josh, building on those descriptions of, like, kind of maybe bad AI use case, good AI use case, could you give some specific examples of, like, what that might look like for Knect, like, how AI could be used in a good way or maybe what you're trying to avoid, more specifically? +JOSH: Yeah. First, I'm going to start with what I want to avoid, which is, there are tools out there, and these may be interesting to some people listening, and if so, go find them. Good luck. But there are tools out there that say things like, "Keep in touch with your network at scale." And will use AI to write a message which you can send out to people without you ever having to, like, review it. That seems like creepy, futuristic sort of, you know, there's, like, a Black Mirror episode about that. +Like, the whole point of having, like, a professional network of people who you care about is actually interacting with them. And having some service, like, write some prompt, maybe in its own voice, maybe if it's really good in your voice to, like, let them know that you care about them, let them know that you're thinking about them is, like, that's just bad. I think that's bad. And we don't have any plans to do that kind of thing, even though most uses for AI in the products that I use are writing three or four paragraphs in response to, like, a prompt. So, certainly, that's the common use case. +It's not very appealing to us, and, frankly, in the people we were talking to, that wasn't one of the things that anybody ever suggested. It's obvious, but as far as we can tell, uninteresting, right? Just because it's obvious and just because it's straightforward doesn't mean it's interesting. +The things we're imagining, for example, is, talk about Jordyn. Jordyn and I have known each other since 2020, I think. And we have, like, a whole history of text messages going back and forth, which, by the way, we actually could integrate because we both have Android phones, you know, shout-out for Open Internet. It might be interesting to, you know, summarize some of that, like, I know Jordyn pretty well, but other people who I might have not talked with in a while, sure, you could present me with a whole timeline of our communication. But that isn't necessarily useful. I'll have to read every bit of it. +Why not, like, take all that and summarize, here's things you guys talk about. Here's things that, like, prompted your past few conversations: job change, got laid off, started a company, got a cat. Whatever those topics happen to be like, share some of those things. Bring me up to speed a little bit faster without having to literally review every word that could have been going back multiple years. That's a pretty good use of it. +If you think about the way that messages work, right? Like, my kids are now at the age where they have phones, and I can now text my kids during the day. I will just tell you, like, this is, like, an incredibly joyful thing for me to be able to send, like, stupid memes to my kids or, like, what's exactly the right emoji to, like, send to them or for them to send to me. +If every one of these things were, like, pushed to some kind of timeline, and I'm like, "What's going on with my kids?" Like, that's just, like, going back and reading through, like, your WhatsApp thread, which is something that isn't interesting necessarily, at least not from, like, a professional perspective. And there's, like, thousands of these things. +Like, why do I want, like, a record in my, like, database of people who I talk to that says, "OMG," or "K," or "lol," or those sorts of things? Like, that's, like, a phrase. It isn't a conversation. And we could use an LLM to go summarize what the conversation was all about, which is, by the way, a way more interesting thing to persist over time than, like, my daughter typing "JK, JK, JK," which I think is 15-year-old for laughing at me, but I'm not entirely sure. +LINDSEY: [laughs] Okay, so as you are...you mentioned wrapping up, and you did your last meeting, and you've got your kind of takeaway docs. You know, one, I'm curious, like, if there's, for your last, you know, days, hours of the program, if there's any final morsels you're trying to get out of it, and then how that kind of leads you into, like, what's next. What are you planning? +JOSH: Let's do another one of these things in two weeks. +[laughter] +LINDSEY: Oh, okay. +JOSH: Yeah. I'm inviting myself back on your show. We have one more day of school then, like so many folks, we get in a plane or get in a car and go do some travel and try to disconnect a little bit from our professional networks. So, I'm consciously not trying to say what's going to happen next. I would love to have this conversation again, maybe in two weeks, in the new year, about what comes next. I don't know that I could have a meaningful one right now. +JORDYN: I will say what we are trying to send Josh off with into his R&R is what's it going to take to get to a viable MVP, not merely viable, but actually viable? Given what we know, given all this, you know, work that we've done in the last eight weeks, we now have, you know, the ability to envision what version one of something might be. And so, making that kind of argument: here's why it is what we're imagining it to be; here's what it is; here's what it would take to build that thing, gives Josh a lot of stuff to think about in the meantime in terms of how to accomplish that. +And the thing that will happen in two weeks is understanding a little bit more about, like, the actual, okay, here's the actual plan. But the ingredients are there, which is super valuable and is a thing we have done every time at the end of every incubator we've done. It's essentially a...it is that what's next plan and why, why that thing. What's the ultimate upside of pursuing this product, and what's the near-term upside? And what's it going to take to get there? +Because that's often a thing that founders, especially for some founders, which Josh is not, but what they often can't get their heads around is there's this little feeling if you've got this big vision over here, and you've got, like, the set of things you could do tomorrow, really tasky things really, like, operational things, oh, I need to, like, set up a C Corp, but I need to...whatever those things are, right? What's in between? What's that near-term path that's going to directionally head in the direction of that big vision? It's, so far, always, what we have sent founders off with. +LINDSEY: So, if you weren't here at the very beginning of our session, we mentioned that the applications are now open for session 1 of 2024. I'm curious, Josh, what kind of founders would you recommend for the thoughtbot incubator? What's the profile of someone you might send our way? +JOSH: I'm going to say something, and I don't think I match that profile, which is interesting, and folks should think about that, what that means. But I would say that if I had to, like, pick a profile, having gone through this, I would say somebody with an idea, of course; ideally, it's one that they have some connection to. They have some personal passion for but, not just because it's an abstract idea but a personal passion that comes from their own experience. +And it's really great for somebody who hasn't been inside of a tech company before, at least on the tech, half the business. Tech companies have three halves: one half is, you know, the product building side of bit of it or the tech half, which is engineers, and product designers, and product managers. And the other half of that is the go-to-market side, like sales, and marketing, and customer success. And the third half would be, like, operations like HR and finance. +So, if you have experience in, like, the sales, or the marketing, or the customer success side, or the HR, or the finance, or corporate operations or that part of it, and, you know, you're familiar with tech coming from that perspective but maybe haven't been on the actually building stuff side of them before, this is a really, really good process. Because what does thoughtbot do? It does the building in tech side of things: designers, product managers, and especially engineers. +And it has this, like, legacy and this history and expertise, therefore, with, like, the journeyman program where they help, like, level people up in those areas and now are applying this to founders. Because as the founder, you do need to develop some ability to converse around engineering and technical stuff. And you really, really, really, really need to get good at the discovery side, especially of, like, product design and product management. And those are the things you're going to get to do and you're going to get to do with people who are themselves really, really good at it. And that's awesome. +The flip side is if you're, you know, a founder who is super attached to every bit of your vision, and you think you have the strategy all laid out and you're just looking for, like, warm bodies to build it, I mean, is it the insight team? What's the right level at thoughtbot? I forget the names of things, but, like, thoughtbot has, like, a startup program where you can give thoughtbot money, and they will build things for you. And they're also really, really good at that, but that's not the incubator program. The incubator program is probably a step earlier. +So, I think it is worth thinking, are you at the I'm so confident of my vision; I'm so confident in my strategy that I just want to get this thing built, then maybe don't sign up for the Incubator. +But if you're at the stage of I think this is a problem; I'm pretty sure this is a problem; I really want it to get solved; I have some vision, but I know it's going to change, then I think the incubator is really ideal, especially if you're looking to upskill yourself, too, because you're going to walk away with the ability to be conversant around the technology stuff. And you're going to walk away with a crap ton of experience with the discovery, qualitative discovery, like user interviews, quantitative discovery, like, you know, running ads, and landing pages, and all that stuff. Like, you're going to be really solid with that stuff after eight weeks because you will have done it. +LINDSEY: Jordyn, any thoughts? +JORDYN: I love all that. I think it's accurate. I would only say to those of you sitting out there who are thinking, I'm in that other camp; I'm very confident about what it is I want to build; I would ask you to do a little soul-searching as to whether that's actually true. Like, what evidence do you have? If you needed to stand up in court and defend your conclusions and your vision, could you? +And I say that as the person who, as a first-time founder, was deluded in that way. I thought I knew exactly what I was doing and for whom and why. And, boy, howdy, could I have used a program like this to actually get me to sit down and, like, talk to people, listen to them, figure out what was valuable and what wasn't, what a valuable, you know, initial market offering was going to be like. Ah, I wish really, really badly that I'd had something like this because I was pretty deluded. I don't even know, like, what the right word is. I just didn't know what I didn't know. +So, like the way you described it, Josh, I know Jordyn of 2017 would have been like, "That's me. I know this thing that I need to do. +LINDSEY: [laughs] +JORDYN: So, I don't need to apply to this program because I don't need to do any of that discovery work." But I was wrong [laughs]. I was absolutely wrong. I was wrong to the tune of, you know, two years and $150,000 of angel investment. So, consider, it is not idly that I say this to you, person sitting out there who feels very confident in your vision right now. Perhaps you have done all those things already; in that case, [inaudible 33:43] you don't need this. And you just need to [inaudible 33:46] with the thing you already know to be true. But ask yourself, how do you know what you know? +LINDSEY: Yeah, even if you...we can help you build the thing. But we're probably, also, still going to push you on [laughs] some of those things we [crosstalk 34:01]. +JORDYN: Yeah, we're still going to ask. We're going to ask to see the receipts. +LINDSEY: Yeah [laughs]. +JORDYN: And maybe you have the receipts, which is great, but we're still going to ask you for them, I guess, is my point. Every team at thoughtbot will ask you for the receipts, by the way, not just mine [laughs]. +LINDSEY: The other interesting thing you touched on, Josh, was, I think, where we kind of started the incubator was with that target profile that you just described, which is, like, the less technical founder, and maybe even, like, a first-time founder. And then over time and seeing, like, applications, we broadened that as we saw, like, oh, you know, actually, also, technical founders and repeat founders do still need, like, help with this and can use guidance. So, we've expanded a bit, and maybe that is still, like, the person who gets the most value at the end of the day is the non-technical who hasn't really done this before. But yeah, we've kind of expanded to those other profiles as well. +JOSH: There's a reason that repeat founders are no more successful on average than first-time founders, and it's something really important that Jordyn said, which is, you may think you've done all this, but we're going to ask you for the receipts. Just because you've done this before doesn't mean you're going to be good at it. Chances are, if you've done this before, it's mostly because you got really, really lucky; ask me how I know. +So, it's nice to have. I mean, I described a profile, and I said that wasn't me. But I'll just tell you, as somebody who, like, spent his entire career, almost his entire career, in the tech side of tech companies, and I think I'm pretty good at it, I'm certainly not the worst at it, thinks I'm pretty good at it, it's still really nice to have a team backing you up in this early moment. It's really nice to have a team. +JORDYN: Yeah, I will say another thing that we've heard from every founder we've worked with is just how much more real and actionable their idea feels when they have a team sitting there with them taking them seriously, which is another thing, you know, I really would have benefited from is, like, suddenly, when you've got three or more industry professionals sitting there in a Zoom call with you, like, okay, what are we doing? Why are we doing this? How do we know? +The feeling of being taken seriously in that way and then having a bunch of people working full-time with you for eight weeks, they're in it with you; they're asking the questions; they're talking to people; they're coming back and saying, "I just had the most amazing conversation with someone. Here's what I learned," it just takes your project to a different level of reality. +Like, we're humans. We're social beings. We create reality together. And when you're working alone, you know, through force of will, you can do a lot, but with a group, it really feels like you're creating something together. And, like Josh said, having those other brains with other experiences in other contexts percolating on your idea it's like bringing a team to bear on something. There's just nothing quite like it, and it's a huge value of the program. Like, we can give you the programming and, in fact, you can go run the programming. It is published in our handbook. The things that we do together you can go do, but it is a whole other matter to do them with a team. It just feels different. +LINDSEY: Great. Well, I think that's where we're going to end today. I mean, Josh is leaving us hanging a little bit. So, we might need to...we're going to figure out a way to get your final thoughts, conclusions in a few weeks because I know everyone would love to hear what the plan is for Knect. Josh and Jordyn, as always, thank you so much. Any final thoughts or farewells from you today? +JOSH: I've really enjoyed it. I'm going to miss these folks. Though, apparently, I get to hang out in a special Slack channel forever. +LINDSEY: Yeah, you get to hang out. +JOSH: Which is nice. +LINDSEY: Exactly. You can't get rid of us just yet. +JOSH: Good. I wouldn't want to. +LINDSEY: All right. Thanks, y'all. And thanks, everyone, for tuning in. Special Guests: Jordyn Bonds and Josh Herzig-Marx . + + + If you missed the other episodes with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can listen to Josh's first episode, his second, an his third to catch up.

+ +

Josh Herzig-Marx, founder of Knect, discusses the latest developments in his startup journey since his last appearance on the show. He emphasizes the program's value in helping founders like himself refine ideas and strategies. He particularly notes the program's effectiveness in addressing challenges unique to startups, such as managing professional networks and dealing with the rapid growth of online presence.

+ +

The conversation also delves into AI's technical aspects and potential applications and the practicalities and ethical considerations of using it in professional networking. Josh and Jordyn explore various AI use cases, distinguishing between beneficial applications and those they deem undesirable.

+ +

Transcript:

+ +

LINDSEY: We are back for our Incubator update with Josh Herzig-Marx and his startup, Knect. I'm Lindsey Christensen. I do marketing things at thoughtbot. We are also joined by Jordyn Bonds, who runs our incubator and does product strategy for thoughtbot. And today, we're going to be catching up with Josh and learn what's new since last we checked in. But before we get to that, we have an exciting incubator update: our application window has just reopened.

+ +

JORDYN: Yes.

+ +

LINDSEY: You could be the next Josh.

+ +

JORDYN: You could.

+ +

JOSH: Don't be me. You should join the incubator.

+ +

[laughter]

+ +

JORDYN: Go to thoughtbot.com/incubator and apply. It's just that easy. The application doesn't take long, even though it's in Typeform, and we have gotten some feedback, including from Josh, that it's challenging to plan your application efforts because, as you all probably know, Typeform just gives you one question at a time. So, sorry, maybe we'll update that. But it won't take you very long. It's a pretty brief application. And we are looking for pre-product folks, so you don't have to have a lot. Don't worry about what you do or don't have. Just apply.

+ +

LINDSEY: Pre-product founder trying to figure out, is this problem worth solving? Who is it for? Jordyn and the team can help you out. thoughtbot.com/incubator.

+ +

JOSH: And me.

+ +

LINDSEY: And Josh.

+ +

JOSH: And if, for some reason, you want to ask somebody about the program who isn't directly affiliated with thoughtbot, you should reach out to me. I'd be happy to talk about my experience.

+ +

LINDSEY: You should.

+ +

JOSH: I'd be happy to tell you what I think would be some reasons to join and some reasons that it might not be a good fit for you. And I'd be happy to chat about any of those things. It'd be my pleasure, in fact.

+ +

LINDSEY: That is a great offer.

+ +

JORDYN: It is a great offer. You all should take Josh up on that offer. He is an excellent sounding board and mentor. And additionally, if you get into the incubator, you'll just be in a Slack channel with Josh for the rest of time, inside of thoughtbot's Slack. So, that's another [crosstalk 02:05]

+ +

JOSH: Statistically, there's a good chance you already are.

+ +

[laughter]

+ +

JORDYN: You mean in a slack with you. That's true. Josh is in a lot of Slacks, not [crosstalk 02:14].

+ +

LINDSEY: Yeah. Once you go through the incubator, you're family for life.

+ +

JORDYN: You're family. You're here. You're with us. You can't get rid of us.

+ +

LINDSEY: And you're able to hit us up with the questions, talk to the other founders, so that's another great benefit of participating. All right, but topic of the hour, Josh, hey, how are you? How you doing?

+ +

JOSH: Lindsey, I am floating right now. We had our end of incubator session last official meeting. And we reviewed how we started, what we hope to accomplish, what we actually did accomplish, and next steps, and it feels really awesome.

+ +

LINDSEY: It does. That's so great to hear. And can you, at the top here, maybe remind folks who haven't listened before, you know, what was that beginning point that you came in the incubator or the problem that you were looking to solve?

+ +

JOSH: So, I had this Josh problem, which is that I am overwhelmed by the number of places that I am online and by the rapid increase in my professional network, professional social network, I guess you could say, but in my professional network, you know, see that comment a few minutes ago about how we're probably already in multiple Slacks together, whoever you happen to be online. Plus, if you're on LinkedIn, we're probably at least secondary connections on LinkedIn. Like, there's an awful lot of people, and it's growing really, really fast.

+ +

And as somebody with a whopping case of ADD, which just feels like making an excuse, as somebody in, like, this modern world, I was feeling overwhelmed, and I felt like I was dropping the ball. And my problem was somebody must have a solution to this. I cannot be the only one. I could not find a solution myself. And I thought, well, maybe if there is no existing solution, maybe we should just go ahead and build it. And that was the genesis of my application to the thoughtbot incubator, which was that even though I've done this once before, I had never done this alone. I don't want to do this alone.

+ +

And I thought that, you know, because of my experience with thoughtbot in the past and my understanding of, like, thoughtbot's unique organizational skills and capacities, this would be a particularly good fit for the thing that I wanted to figure out. And when I say figure it out, there was really four things I was hoping to get from this program. Let's see if I can remember them all in order. Number one, is this a Josh problem, or is this a broader problem affecting more people? Number two, this is, like, a ladder of problems, right? Like a cascading set.

+ +

Number two thing I was trying to figure out: if this isn't just a Josh problem, is there at least one identifiable and addressable set of people who think about this problem in a similar way with whom I could engage? Number three, if there is such a group, are they willing, ready, and able to, like, spend money on solving this problem? And then number four, which I guess is kind of orthogonal to the other ones, it's kind of alongside, is this thing to solve even technically feasible, right?

+ +

Because you can have this, like, amazing opportunity, but you just can't build it. And, you know, is this a thing that we could build or that I could get built within the resources that I might have? And I came in with some hypotheses, with some ideas. It's not like I had never done any research in this at all. But coming out of it, we have four pretty good answers. And I would not have been able to reach those answers with the same level of confidence, certainly not within eight weeks, if I hadn't gone through the incubator, and it's a really nice way to end the year.

+ +

LINDSEY: With a bow on it. The last time we talked, you had narrowed in, I think, on your starting target market. And you had also recently introduced a prototype into the mix. How has the prototype evolved?

+ +

JOSH: It's...and this is going to be no surprise to either of you or anybody who's listening. But, like, the difference between, like, talking about something in the abstract and actually having, like, a thing in your hand is night and day. So, the prototype actually evolved pretty rapidly. You know, it allowed us to try using it, like, to put on our own empathetic user analog hats and try it ourselves and be like, "Well, this doesn't quite make sense." This doesn't actually flow right. And it allowed us to show it to a lot of people.

+ +

I'll say, we are, by far, our own strongest critics, which is good. Mostly, when we showed it to people, people are like, "This is amazing." And they would ask us, like, really specific, weird questions like, "Where's, you know, your about page? Could I see your privacy policy?" which is, like, a really, really good thing to hear. Because if the only thing...one way to interpret that is the only thing keeping them from maybe, like, diving in and using it right now, besides it doesn't actually exist as a product, is, like, some questions around privacy because it seems maybe too good to be true. Like, that's a pretty good buy sign.

+ +

You know, we were expecting, like, "The screen makes no sense. Why are we swiping here? Where does this data come from? Is this really complete?" They're like, "No, I'm pretty much ready to go." So, that was good, helpful feedback, though we evolved it ourselves a lot internally. It's really nice having a thing. Do we use the term Pinocchio prototype or Pinocchio test [crosstalk 06:58]?

+ +

LINDSEY: Yes, I did hear that.

+ +

JOSH: Yeah, I like that. If this was like, you know, this wooden toy wanted to be a real boy, like, two weeks ago, it really, really wants...I don't know, Lindsey, we should, you know, get you in front of it. You're going to be like, "Why can't I use this today?"
+[laughter]

+ +

JORDYN: That's definitely what we're hearing from people.

+ +

JOSH: And my answer would be, "Well, you can't, but maybe in a couple of weeks." [laughs]

+ +

JORDYN: Yeah, exactly. I will say I want to say for anyone listening in, though, that that was not, getting to what Josh just described where folks weren't really...they didn't have any hang-ups about the functionality or the value prop. They were basically just like, "What's your privacy policy? And when is it going to be ready for me to use?" It's not like the first draft of this prototype that was what we jumped to. I want to be clear.

+ +

The first time we showed someone, there was this interesting problem, which is that we were still talking to the wrong people, somewhat. And the prototype hadn't evolved to be the slam dunk that it is now. So, at first, it was like, we'd have these kinds of muddled conversations where people were like, "Well, I don't really understand what this is supposed to be, and I'm not sure about that. And this seems interesting," but then their interpretation of what that thing was would be, like, wildly off from what it was intended to be. I just want to make it clear: this was work and effort.

+ +

And the team did a really great job of iterating quickly based on, like, every time we talked to someone and showed it to them, we'd come back and say, "Here's what I heard." And it really pushed our thinking forward. Like Josh said, like, we are our toughest critics, so, like, every new version unlocked some new insights in ourselves about what it was we were actually driving toward. Really, just there's nothing like having a thing to look at and bang on to, like, clarify your thinking.

+ +

LINDSEY: There's nothing like having a thing. Jordyn, you touched on you were talking to the wrong people, maybe. How has that exploration of the core market evolved? Is it still the startup enthusiasts? Are you even more narrow in that? What are the updates there as our chief market focus get everyone thinking about this all the time, officer?

+ +

JORDYN: Yes. So, you know, startup enthusiasts is still the umbrella. What you're looking for with this is that you can guarantee pretty much every time you talk to someone in a segment or a sub-segment you will know how the conversation is going to go. And we've gotten there with two sub-segments of startup enthusiasts, which is repeat founders, key, key kind of nuance there. Founders, sure, but repeat founders really have this problem, for reasons we could talk about, and then chiefs of staff at startups, which is a relatively new role that's sort of emerged over the last sort of several years.

+ +

But those folks are really the people that you ask them about this pain point, and they immediately are, like, yes. They use the same words to talk about the pain point. That's another really strong signal. When folks are using the same vocabulary, and they say the same sentences in the same order, and you start to feel a little bit creeped out, like, you're like, "Did you see these questions before I...? What? Did someone pay you to say that?" is, like, how you start to feel [laughs] [crosstalk 09:59]

+ +

LINDSEY: Also, a marketer's dream. Oh my gosh, here comes the messaging, right?

+ +

JORDYN: Exactly.

+ +

LINDSEY: [inaudible 10:04]

+ +

JORDYN: It feels like a cheat code because you just get to reflect their language back to them. You don't have to write copy. They wrote the copy. You just show them it, and they're like, yes. And everyone's like, "Yes," and it works.

+ +

LINDSEY: Any thoughts to add to that, Josh?

+ +

JOSH: It's really good. I would say the bummer or the good thing about this point is we're getting diminishing returns from testing everything other than the actual product, which is good that we got there in eight weeks. But we're not going to learn, you know, keep on adjusting the prototype and making little tweaks and more user research. But the truth is, we're not going to get anything substantial until we get this into some users' hands.

+ +

JORDYN: Like you say, this is sort of bad news, but it's good news.

+ +

JOSH: Right.

+ +

JORDYN: It's how you know, right? When you get to the point where the thing is so clear, and the way to talk about it with folks is so clear that you're not learning as much anymore, diminishing returns is the right way to frame it. You really just need people to get in there and use it. That's the only way you're going to keep learning. That's the moment to build. Hey, everyone out there, don't build before that. That's when you build. And then you really build the smallest thing you can conceive of building, and then whatever that thing is that you've conceived of building that's very small, scope it back by 50% [laughs]. Do it.

+ +

JOSH: And it's a little humbling as someone who considers himself a founder but who had reasonable success as a founder and who has had pretty good success as, like a very, very early-stage, you know, zero to one and 1 to 10 product leader, has done this a bunch of times and actually coaches people in doing this, and came in with, I'm not going to lie, a pretty good vision in my head for how this stuff was supposed to work together. And it's so much better now.

+ +

Going through a process actually makes things better. This wasn't just, like, wasting time. Like, going through a process, a thoughtful process actually makes us much better. Like, the thing we're talking about building is much more likely to be successful than the thing I was originally thinking about building, right, Jordyn?

+ +

JORDYN: Yes. I guess it bears sort of diving into that a little bit, which is, you know, for all the founders out there or folks with a product idea kicking around your head, you're apt to have a little bit of everything we've talked about already. You have an idea of the solution you want to build. You have an idea of who it's for. You have an idea of what their pain points are. And you might be sitting there thinking to yourself, I don't need to do eight weeks of discovery. I already know the answers to all of these questions.

+ +

And it's possible Josh felt that way coming into the incubator, but doing the work, gathering the data, talking to a ton of people, what you can't understand before doing that is how much more confident and at ease you will feel once you have done it and how much clarity you'll have about what it is you need to build first because likely, you're sitting there with a vision in your head for this product that is fully featured, fully formed.

+ +

It is the 18th month. We just went into a hidey hole and built a really complex thing, thing. Cool, don't throw that out. But you got to begin somewhere, and you got to begin somewhere meaningful and valuable. And it's really hard to know where to begin without this discovery, without focusing on a specific person, talking to as many of those folks as you can. And really, it sort of writes itself. It does feel easy. But you've got to set aside the time and the effort to do the research, market research, whatever we call this, customer discovery.

+ +

And it thrills me to no end, Josh, to hear that that is how it felt for you, that you probably felt like you already knew the answer. But it just feels different, having talked to, I mean, how many people, 100-plus people? We were looking at the stats.

+ +

JOSH: Well over 100.

+ +

LINDSEY: Josh was talking to a bunch of people before he came to the incubator, and all the founders that we accept have been doing that. Like, we want to know that you've been doing that research. But then, I guess, coming into the incubator, you're continuing that process and maybe in a more structured or a differently structured way where the thoughtbot team is helping you, maybe zero in far deeper on the segment. Is that accurate to say? Just kind of the difference between, like, maybe some of the pre-research and then the thoughtbot-specific user interviews that happen.

+ +

JOSH: Yeah. I think they were more focused. They're both more focused from the audience, but also more focused from if it's not just you doing it; it forces you to have a more clear, here's the questions we're asking, and here's what we're trying to learn, all these conversations.

+ +

It's also really nice to have some diversity in who's asking the questions. As good or bad as I am at user research and user discovery, I am only one person. And having people with different backgrounds professionally, who live in different countries, who have different feelings about social media, basically, who are not me in a variety of really interesting ways, I think, made the entire process more interesting.

+ +

Caro, who is our lead designer on the project, handed off basically the summary document of, like, everything we learned, and she pulled out, like, little snippets from the interviews. First of all, that is not something I would have done had it been just me, like, let's be very, very clear. This is an incredibly valuable document, particularly as we consider adding additional people onto this project to be able to, like, translate insights. But also, like, this is, like, summarized in a way that, like, takes some real expertise. And I would have walked away with vibes, and instead, we walked away with like, structured learning.

+ +

LINDSEY: Awesome. So, the last time we checked in, also, you were very excited because you had just maybe started a technical spike and were starting to dig into the, okay, like, how technically feasible is this product? And I think, at that point, you all were looking at circling around this target market. Here are the main tools they use to communicate. What does it even look like to connect with those APIs? How possible is it? Can you give us an update on some of that work?

+ +

JOSH: The way that I framed the question in the very beginning was, is this a science project, or is this going to be engineering? And, for the most part, the answer is, it's going to be engineering, right? Some are a little bit easier; some are a little bit harder. But it isn't, like, reinventing new stuff, with one exception, and that is connecting up with iMessages, which has been in the news a little bit. And I honestly just hope the ghost of Steve Jobs comes back and haunts, you know, the Apple headquarters at Cupertino because, come on, guys, interoperability is sort of the future, and you're ruining it for everybody.

+ +

But other than that, I think we have a pretty clear path. I'd like to test out some of these. Like, you don't really know until you do it. I think that's kind of the next step of what we're doing is to, like, demonstrate that it is possible for a person to connect up a couple of different accounts. It is possible for us to extract data and turn that into information and insights in the kinds of ways we thought we could and then present that back in a meaningful way. I think that would be the next step for us to do. Mostly, everything seems feasible, except for iMessages.

+ +

LINDSEY: I've also, I think, heard some whispers of artificial intelligence for Knect. Is that true? Have you all looked at, you know, what AI's role could be in the solution? And how does that research look?

+ +

JORDYN: We assume it will be part of the mix. That said, I don't know how to frame it exactly. It's not like it's not an essential ingredient. I think the work with large language models and the democratization of that work recently is absolutely going to make this product way better than it would have otherwise been. But there are a lot of heuristics we've, like, been able to, you know, draw out and come up with that are, frankly, algorithmic, and they're not AI necessarily. Now, the line between big data plus an algorithm and AI in the popular lexicon, like, there's a big difference between those two things. But, like, as people talk about it, yeah, where does one end and the other begin?

+ +

But we definitely will be making use of a lot of the newest technologies, and we've dabbled in them. I've dabbled in them. I know, Josh, you've been playing around with some of them, too, to the point where we're like, okay, yeah, we can make use of this stuff. It will be a valuable kind of tool in our toolkit, but it will not be the sole basis of value. I guess that's the sort of nuanced answer. But maybe Josh has a more bite-sized hype machine answer to this. Yeah, AI to the moon, right?

+ +

JOSH: Um, no. My only answer would be more cynical. Would anybody rightfully start a company in 2023 without having AI in there someplace? Maybe I'll say something different. One of the things that we've wondered is, there's more than a handful of companies that are adjacent to what we're doing that are definitely looking at similar kinds of problems and that aren't building the solution that, clearly, some market is, like, desperate for. And these are not, like, wildly successful companies that have grown astronomically and changed the market. And, like, trying to figure out, like, why is that?

+ +

And one of the reasons is...I sound like a tech bro, right? There has been a paradigm shift in the technology world, but there really has been. What do, you know, publicly available LLMs like, you know, OpenAI's ChatGPT, like, what have they done? They have taken a whole set of problems that were once really, really complicated and allowed you to do a reasonable job of solving them much more easily than you ever could before.

+ +

And it takes some amount of imagination, to realize that, to realize that these things are more than just, I mean, every product I have on my computer has some kind of OpenAI ChatGPT-style thing in there, right? It's, like, 16 different variations on give me a prompt, and I'll write your essay for you, and they all kind of suck. But those aren't the really exciting uses that I've seen. It's the more subtle things.

+ +

There's a company called Booklet, which tries to replace, like, noisy email lists or noisy communities to something more calm. And one of its features is it'll send you a summary of what's been going on in the community since, like, the last time you checked in. And it gives you, like, two paragraphs to read, and they're really chill and really informative, and they don't make you feel FOMO. They don't make you feel stressed up. Like, okay, stuff's happened in the community. This is really neat. And it's all powered by OpenAI's APIs. And it's really kind of magical. And, like, you have to have a slightly different perspective to imagine these kinds of magical moments. So, that's what I'm excited about.

+ +

There's a set of things that we would have had to do with, like, terrible, complicated queries and, like, pattern matching, and freaking grep, or whatever old-school tools we would have had, you know, for doing things in the past. And now you just get to, like, shove text in one end, and say how you want the results structured and get the results back in the other end. And it doesn't have to be perfect, but that's okay. Like, we're talking about human relationships, which are inherently imperfect. So, I'm fine with this. And it's kind of exciting.

+ +

But we'll see in, you know, if we end up continuing going down this path. Like, that's the goal of the next stage is to be, like, okay, what are the easy things which we can generate out of this? Is there an intersection between, like, easy and meaningful? And if there is, this is pretty exciting.

+ +

JORDYN: Can I add something to that? Which is that the problem Knect is trying to solve and the way that we're trying to solve it, the way we've thought of solving it that's differentiated, lends itself really well to the current landscape of AI tools in that, and you were kind of getting at this, Josh, but I feel like it bears drilling into a little bit, in that what we are proposing here is not a set of deterministic things. We're not going to give you a to-do list. It's not, like, a linear...deterministic is really the right word. Like, there's a to-do list. There are things that make the cut. You got to go address them, et cetera.

+ +

We're way more trying to approximate the way a slightly more put-together person with more time would approach nurturing their relationships, which is just to remember more of it more of the time. It doesn't mean we need to remember all of it every time. That's not the kind of task this is, which makes it a really good task for the place that AI is at right now.

+ +

And I think where folks have failed in the past is that they've either tried to turn it into a deterministic set of tasks, which then just feels like another to-do list, another inbox in a series of to-do lists and inboxes that you have in your life that just make you feel guilty and inadequate. That doesn't seem fun to us. We don't think you need another one of those. Or other places we've seen this fall down, which is that it takes the current sort of state of AI and tries to actually do the deterministic thing for you, but it doesn't do a good enough job right now.

+ +

But where we've kind of landed in the middle is that, again, what we're trying to solve for is solvable in a way more probabilistic way. Like, can we get more of this accomplished more easily for you? It's never going to, like, completely, you know, do the task in this perfect deterministic way. But it is going to make you feel more confident and more relaxed à la Booklet, it sounds like, how to do that for this particular problem, which is a different bar and one we think we can clear. And that really does provide value. People are really longing for this.

+ +

LINDSEY: Jordyn and Josh, building on those descriptions of, like, kind of maybe bad AI use case, good AI use case, could you give some specific examples of, like, what that might look like for Knect, like, how AI could be used in a good way or maybe what you're trying to avoid, more specifically?

+ +

JOSH: Yeah. First, I'm going to start with what I want to avoid, which is, there are tools out there, and these may be interesting to some people listening, and if so, go find them. Good luck. But there are tools out there that say things like, "Keep in touch with your network at scale." And will use AI to write a message which you can send out to people without you ever having to, like, review it. That seems like creepy, futuristic sort of, you know, there's, like, a Black Mirror episode about that.

+ +

Like, the whole point of having, like, a professional network of people who you care about is actually interacting with them. And having some service, like, write some prompt, maybe in its own voice, maybe if it's really good in your voice to, like, let them know that you care about them, let them know that you're thinking about them is, like, that's just bad. I think that's bad. And we don't have any plans to do that kind of thing, even though most uses for AI in the products that I use are writing three or four paragraphs in response to, like, a prompt. So, certainly, that's the common use case.

+ +

It's not very appealing to us, and, frankly, in the people we were talking to, that wasn't one of the things that anybody ever suggested. It's obvious, but as far as we can tell, uninteresting, right? Just because it's obvious and just because it's straightforward doesn't mean it's interesting.

+ +

The things we're imagining, for example, is, talk about Jordyn. Jordyn and I have known each other since 2020, I think. And we have, like, a whole history of text messages going back and forth, which, by the way, we actually could integrate because we both have Android phones, you know, shout-out for Open Internet. It might be interesting to, you know, summarize some of that, like, I know Jordyn pretty well, but other people who I might have not talked with in a while, sure, you could present me with a whole timeline of our communication. But that isn't necessarily useful. I'll have to read every bit of it.

+ +

Why not, like, take all that and summarize, here's things you guys talk about. Here's things that, like, prompted your past few conversations: job change, got laid off, started a company, got a cat. Whatever those topics happen to be like, share some of those things. Bring me up to speed a little bit faster without having to literally review every word that could have been going back multiple years. That's a pretty good use of it.

+ +

If you think about the way that messages work, right? Like, my kids are now at the age where they have phones, and I can now text my kids during the day. I will just tell you, like, this is, like, an incredibly joyful thing for me to be able to send, like, stupid memes to my kids or, like, what's exactly the right emoji to, like, send to them or for them to send to me.

+ +

If every one of these things were, like, pushed to some kind of timeline, and I'm like, "What's going on with my kids?" Like, that's just, like, going back and reading through, like, your WhatsApp thread, which is something that isn't interesting necessarily, at least not from, like, a professional perspective. And there's, like, thousands of these things.

+ +

Like, why do I want, like, a record in my, like, database of people who I talk to that says, "OMG," or "K," or "lol," or those sorts of things? Like, that's, like, a phrase. It isn't a conversation. And we could use an LLM to go summarize what the conversation was all about, which is, by the way, a way more interesting thing to persist over time than, like, my daughter typing "JK, JK, JK," which I think is 15-year-old for laughing at me, but I'm not entirely sure.

+ +

LINDSEY: [laughs] Okay, so as you are...you mentioned wrapping up, and you did your last meeting, and you've got your kind of takeaway docs. You know, one, I'm curious, like, if there's, for your last, you know, days, hours of the program, if there's any final morsels you're trying to get out of it, and then how that kind of leads you into, like, what's next. What are you planning?

+ +

JOSH: Let's do another one of these things in two weeks.

+ +

[laughter]

+ +

LINDSEY: Oh, okay.

+ +

JOSH: Yeah. I'm inviting myself back on your show. We have one more day of school then, like so many folks, we get in a plane or get in a car and go do some travel and try to disconnect a little bit from our professional networks. So, I'm consciously not trying to say what's going to happen next. I would love to have this conversation again, maybe in two weeks, in the new year, about what comes next. I don't know that I could have a meaningful one right now.

+ +

JORDYN: I will say what we are trying to send Josh off with into his R&R is what's it going to take to get to a viable MVP, not merely viable, but actually viable? Given what we know, given all this, you know, work that we've done in the last eight weeks, we now have, you know, the ability to envision what version one of something might be. And so, making that kind of argument: here's why it is what we're imagining it to be; here's what it is; here's what it would take to build that thing, gives Josh a lot of stuff to think about in the meantime in terms of how to accomplish that.

+ +

And the thing that will happen in two weeks is understanding a little bit more about, like, the actual, okay, here's the actual plan. But the ingredients are there, which is super valuable and is a thing we have done every time at the end of every incubator we've done. It's essentially a...it is that what's next plan and why, why that thing. What's the ultimate upside of pursuing this product, and what's the near-term upside? And what's it going to take to get there?

+ +

Because that's often a thing that founders, especially for some founders, which Josh is not, but what they often can't get their heads around is there's this little feeling if you've got this big vision over here, and you've got, like, the set of things you could do tomorrow, really tasky things really, like, operational things, oh, I need to, like, set up a C Corp, but I need to...whatever those things are, right? What's in between? What's that near-term path that's going to directionally head in the direction of that big vision? It's, so far, always, what we have sent founders off with.

+ +

LINDSEY: So, if you weren't here at the very beginning of our session, we mentioned that the applications are now open for session 1 of 2024. I'm curious, Josh, what kind of founders would you recommend for the thoughtbot incubator? What's the profile of someone you might send our way?

+ +

JOSH: I'm going to say something, and I don't think I match that profile, which is interesting, and folks should think about that, what that means. But I would say that if I had to, like, pick a profile, having gone through this, I would say somebody with an idea, of course; ideally, it's one that they have some connection to. They have some personal passion for but, not just because it's an abstract idea but a personal passion that comes from their own experience.

+ +

And it's really great for somebody who hasn't been inside of a tech company before, at least on the tech, half the business. Tech companies have three halves: one half is, you know, the product building side of bit of it or the tech half, which is engineers, and product designers, and product managers. And the other half of that is the go-to-market side, like sales, and marketing, and customer success. And the third half would be, like, operations like HR and finance.

+ +

So, if you have experience in, like, the sales, or the marketing, or the customer success side, or the HR, or the finance, or corporate operations or that part of it, and, you know, you're familiar with tech coming from that perspective but maybe haven't been on the actually building stuff side of them before, this is a really, really good process. Because what does thoughtbot do? It does the building in tech side of things: designers, product managers, and especially engineers.

+ +

And it has this, like, legacy and this history and expertise, therefore, with, like, the journeyman program where they help, like, level people up in those areas and now are applying this to founders. Because as the founder, you do need to develop some ability to converse around engineering and technical stuff. And you really, really, really, really need to get good at the discovery side, especially of, like, product design and product management. And those are the things you're going to get to do and you're going to get to do with people who are themselves really, really good at it. And that's awesome.

+ +

The flip side is if you're, you know, a founder who is super attached to every bit of your vision, and you think you have the strategy all laid out and you're just looking for, like, warm bodies to build it, I mean, is it the insight team? What's the right level at thoughtbot? I forget the names of things, but, like, thoughtbot has, like, a startup program where you can give thoughtbot money, and they will build things for you. And they're also really, really good at that, but that's not the incubator program. The incubator program is probably a step earlier.

+ +

So, I think it is worth thinking, are you at the I'm so confident of my vision; I'm so confident in my strategy that I just want to get this thing built, then maybe don't sign up for the Incubator.

+ +

But if you're at the stage of I think this is a problem; I'm pretty sure this is a problem; I really want it to get solved; I have some vision, but I know it's going to change, then I think the incubator is really ideal, especially if you're looking to upskill yourself, too, because you're going to walk away with the ability to be conversant around the technology stuff. And you're going to walk away with a crap ton of experience with the discovery, qualitative discovery, like user interviews, quantitative discovery, like, you know, running ads, and landing pages, and all that stuff. Like, you're going to be really solid with that stuff after eight weeks because you will have done it.

+ +

LINDSEY: Jordyn, any thoughts?

+ +

JORDYN: I love all that. I think it's accurate. I would only say to those of you sitting out there who are thinking, I'm in that other camp; I'm very confident about what it is I want to build; I would ask you to do a little soul-searching as to whether that's actually true. Like, what evidence do you have? If you needed to stand up in court and defend your conclusions and your vision, could you?

+ +

And I say that as the person who, as a first-time founder, was deluded in that way. I thought I knew exactly what I was doing and for whom and why. And, boy, howdy, could I have used a program like this to actually get me to sit down and, like, talk to people, listen to them, figure out what was valuable and what wasn't, what a valuable, you know, initial market offering was going to be like. Ah, I wish really, really badly that I'd had something like this because I was pretty deluded. I don't even know, like, what the right word is. I just didn't know what I didn't know.

+ +

So, like the way you described it, Josh, I know Jordyn of 2017 would have been like, "That's me. I know this thing that I need to do.

+ +

LINDSEY: [laughs]

+ +

JORDYN: So, I don't need to apply to this program because I don't need to do any of that discovery work." But I was wrong [laughs]. I was absolutely wrong. I was wrong to the tune of, you know, two years and $150,000 of angel investment. So, consider, it is not idly that I say this to you, person sitting out there who feels very confident in your vision right now. Perhaps you have done all those things already; in that case, [inaudible 33:43] you don't need this. And you just need to [inaudible 33:46] with the thing you already know to be true. But ask yourself, how do you know what you know?

+ +

LINDSEY: Yeah, even if you...we can help you build the thing. But we're probably, also, still going to push you on [laughs] some of those things we [crosstalk 34:01].

+ +

JORDYN: Yeah, we're still going to ask. We're going to ask to see the receipts.

+ +

LINDSEY: Yeah [laughs].

+ +

JORDYN: And maybe you have the receipts, which is great, but we're still going to ask you for them, I guess, is my point. Every team at thoughtbot will ask you for the receipts, by the way, not just mine [laughs].

+ +

LINDSEY: The other interesting thing you touched on, Josh, was, I think, where we kind of started the incubator was with that target profile that you just described, which is, like, the less technical founder, and maybe even, like, a first-time founder. And then over time and seeing, like, applications, we broadened that as we saw, like, oh, you know, actually, also, technical founders and repeat founders do still need, like, help with this and can use guidance. So, we've expanded a bit, and maybe that is still, like, the person who gets the most value at the end of the day is the non-technical who hasn't really done this before. But yeah, we've kind of expanded to those other profiles as well.

+ +

JOSH: There's a reason that repeat founders are no more successful on average than first-time founders, and it's something really important that Jordyn said, which is, you may think you've done all this, but we're going to ask you for the receipts. Just because you've done this before doesn't mean you're going to be good at it. Chances are, if you've done this before, it's mostly because you got really, really lucky; ask me how I know.

+ +

So, it's nice to have. I mean, I described a profile, and I said that wasn't me. But I'll just tell you, as somebody who, like, spent his entire career, almost his entire career, in the tech side of tech companies, and I think I'm pretty good at it, I'm certainly not the worst at it, thinks I'm pretty good at it, it's still really nice to have a team backing you up in this early moment. It's really nice to have a team.

+ +

JORDYN: Yeah, I will say another thing that we've heard from every founder we've worked with is just how much more real and actionable their idea feels when they have a team sitting there with them taking them seriously, which is another thing, you know, I really would have benefited from is, like, suddenly, when you've got three or more industry professionals sitting there in a Zoom call with you, like, okay, what are we doing? Why are we doing this? How do we know?

+ +

The feeling of being taken seriously in that way and then having a bunch of people working full-time with you for eight weeks, they're in it with you; they're asking the questions; they're talking to people; they're coming back and saying, "I just had the most amazing conversation with someone. Here's what I learned," it just takes your project to a different level of reality.

+ +

Like, we're humans. We're social beings. We create reality together. And when you're working alone, you know, through force of will, you can do a lot, but with a group, it really feels like you're creating something together. And, like Josh said, having those other brains with other experiences in other contexts percolating on your idea it's like bringing a team to bear on something. There's just nothing quite like it, and it's a huge value of the program. Like, we can give you the programming and, in fact, you can go run the programming. It is published in our handbook. The things that we do together you can go do, but it is a whole other matter to do them with a team. It just feels different.

+ +

LINDSEY: Great. Well, I think that's where we're going to end today. I mean, Josh is leaving us hanging a little bit. So, we might need to...we're going to figure out a way to get your final thoughts, conclusions in a few weeks because I know everyone would love to hear what the plan is for Knect. Josh and Jordyn, as always, thank you so much. Any final thoughts or farewells from you today?

+ +

JOSH: I've really enjoyed it. I'm going to miss these folks. Though, apparently, I get to hang out in a special Slack channel forever.

+ +

LINDSEY: Yeah, you get to hang out.

+ +

JOSH: Which is nice.

+ +

LINDSEY: Exactly. You can't get rid of us just yet.

+ +

JOSH: Good. I wouldn't want to.

+ +

LINDSEY: All right. Thanks, y'all. And thanks, everyone, for tuning in.

Special Guests: Jordyn Bonds and Josh Herzig-Marx .

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + If you missed the other episodes with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can listen to Josh's first episode, his second, an his third to catch up.

+ +

Josh Herzig-Marx, founder of Knect, discusses the latest developments in his startup journey since his last appearance on the show. He emphasizes the program's value in helping founders like himself refine ideas and strategies. He particularly notes the program's effectiveness in addressing challenges unique to startups, such as managing professional networks and dealing with the rapid growth of online presence.

+ +

The conversation also delves into AI's technical aspects and potential applications and the practicalities and ethical considerations of using it in professional networking. Josh and Jordyn explore various AI use cases, distinguishing between beneficial applications and those they deem undesirable.

+ +

Transcript:

+ +

LINDSEY: We are back for our Incubator update with Josh Herzig-Marx and his startup, Knect. I'm Lindsey Christensen. I do marketing things at thoughtbot. We are also joined by Jordyn Bonds, who runs our incubator and does product strategy for thoughtbot. And today, we're going to be catching up with Josh and learn what's new since last we checked in. But before we get to that, we have an exciting incubator update: our application window has just reopened.

+ +

JORDYN: Yes.

+ +

LINDSEY: You could be the next Josh.

+ +

JORDYN: You could.

+ +

JOSH: Don't be me. You should join the incubator.

+ +

[laughter]

+ +

JORDYN: Go to thoughtbot.com/incubator and apply. It's just that easy. The application doesn't take long, even though it's in Typeform, and we have gotten some feedback, including from Josh, that it's challenging to plan your application efforts because, as you all probably know, Typeform just gives you one question at a time. So, sorry, maybe we'll update that. But it won't take you very long. It's a pretty brief application. And we are looking for pre-product folks, so you don't have to have a lot. Don't worry about what you do or don't have. Just apply.

+ +

LINDSEY: Pre-product founder trying to figure out, is this problem worth solving? Who is it for? Jordyn and the team can help you out. thoughtbot.com/incubator.

+ +

JOSH: And me.

+ +

LINDSEY: And Josh.

+ +

JOSH: And if, for some reason, you want to ask somebody about the program who isn't directly affiliated with thoughtbot, you should reach out to me. I'd be happy to talk about my experience.

+ +

LINDSEY: You should.

+ +

JOSH: I'd be happy to tell you what I think would be some reasons to join and some reasons that it might not be a good fit for you. And I'd be happy to chat about any of those things. It'd be my pleasure, in fact.

+ +

LINDSEY: That is a great offer.

+ +

JORDYN: It is a great offer. You all should take Josh up on that offer. He is an excellent sounding board and mentor. And additionally, if you get into the incubator, you'll just be in a Slack channel with Josh for the rest of time, inside of thoughtbot's Slack. So, that's another [crosstalk 02:05]

+ +

JOSH: Statistically, there's a good chance you already are.

+ +

[laughter]

+ +

JORDYN: You mean in a slack with you. That's true. Josh is in a lot of Slacks, not [crosstalk 02:14].

+ +

LINDSEY: Yeah. Once you go through the incubator, you're family for life.

+ +

JORDYN: You're family. You're here. You're with us. You can't get rid of us.

+ +

LINDSEY: And you're able to hit us up with the questions, talk to the other founders, so that's another great benefit of participating. All right, but topic of the hour, Josh, hey, how are you? How you doing?

+ +

JOSH: Lindsey, I am floating right now. We had our end of incubator session last official meeting. And we reviewed how we started, what we hope to accomplish, what we actually did accomplish, and next steps, and it feels really awesome.

+ +

LINDSEY: It does. That's so great to hear. And can you, at the top here, maybe remind folks who haven't listened before, you know, what was that beginning point that you came in the incubator or the problem that you were looking to solve?

+ +

JOSH: So, I had this Josh problem, which is that I am overwhelmed by the number of places that I am online and by the rapid increase in my professional network, professional social network, I guess you could say, but in my professional network, you know, see that comment a few minutes ago about how we're probably already in multiple Slacks together, whoever you happen to be online. Plus, if you're on LinkedIn, we're probably at least secondary connections on LinkedIn. Like, there's an awful lot of people, and it's growing really, really fast.

+ +

And as somebody with a whopping case of ADD, which just feels like making an excuse, as somebody in, like, this modern world, I was feeling overwhelmed, and I felt like I was dropping the ball. And my problem was somebody must have a solution to this. I cannot be the only one. I could not find a solution myself. And I thought, well, maybe if there is no existing solution, maybe we should just go ahead and build it. And that was the genesis of my application to the thoughtbot incubator, which was that even though I've done this once before, I had never done this alone. I don't want to do this alone.

+ +

And I thought that, you know, because of my experience with thoughtbot in the past and my understanding of, like, thoughtbot's unique organizational skills and capacities, this would be a particularly good fit for the thing that I wanted to figure out. And when I say figure it out, there was really four things I was hoping to get from this program. Let's see if I can remember them all in order. Number one, is this a Josh problem, or is this a broader problem affecting more people? Number two, this is, like, a ladder of problems, right? Like a cascading set.

+ +

Number two thing I was trying to figure out: if this isn't just a Josh problem, is there at least one identifiable and addressable set of people who think about this problem in a similar way with whom I could engage? Number three, if there is such a group, are they willing, ready, and able to, like, spend money on solving this problem? And then number four, which I guess is kind of orthogonal to the other ones, it's kind of alongside, is this thing to solve even technically feasible, right?

+ +

Because you can have this, like, amazing opportunity, but you just can't build it. And, you know, is this a thing that we could build or that I could get built within the resources that I might have? And I came in with some hypotheses, with some ideas. It's not like I had never done any research in this at all. But coming out of it, we have four pretty good answers. And I would not have been able to reach those answers with the same level of confidence, certainly not within eight weeks, if I hadn't gone through the incubator, and it's a really nice way to end the year.

+ +

LINDSEY: With a bow on it. The last time we talked, you had narrowed in, I think, on your starting target market. And you had also recently introduced a prototype into the mix. How has the prototype evolved?

+ +

JOSH: It's...and this is going to be no surprise to either of you or anybody who's listening. But, like, the difference between, like, talking about something in the abstract and actually having, like, a thing in your hand is night and day. So, the prototype actually evolved pretty rapidly. You know, it allowed us to try using it, like, to put on our own empathetic user analog hats and try it ourselves and be like, "Well, this doesn't quite make sense." This doesn't actually flow right. And it allowed us to show it to a lot of people.

+ +

I'll say, we are, by far, our own strongest critics, which is good. Mostly, when we showed it to people, people are like, "This is amazing." And they would ask us, like, really specific, weird questions like, "Where's, you know, your about page? Could I see your privacy policy?" which is, like, a really, really good thing to hear. Because if the only thing...one way to interpret that is the only thing keeping them from maybe, like, diving in and using it right now, besides it doesn't actually exist as a product, is, like, some questions around privacy because it seems maybe too good to be true. Like, that's a pretty good buy sign.

+ +

You know, we were expecting, like, "The screen makes no sense. Why are we swiping here? Where does this data come from? Is this really complete?" They're like, "No, I'm pretty much ready to go." So, that was good, helpful feedback, though we evolved it ourselves a lot internally. It's really nice having a thing. Do we use the term Pinocchio prototype or Pinocchio test [crosstalk 06:58]?

+ +

LINDSEY: Yes, I did hear that.

+ +

JOSH: Yeah, I like that. If this was like, you know, this wooden toy wanted to be a real boy, like, two weeks ago, it really, really wants...I don't know, Lindsey, we should, you know, get you in front of it. You're going to be like, "Why can't I use this today?"
+[laughter]

+ +

JORDYN: That's definitely what we're hearing from people.

+ +

JOSH: And my answer would be, "Well, you can't, but maybe in a couple of weeks." [laughs]

+ +

JORDYN: Yeah, exactly. I will say I want to say for anyone listening in, though, that that was not, getting to what Josh just described where folks weren't really...they didn't have any hang-ups about the functionality or the value prop. They were basically just like, "What's your privacy policy? And when is it going to be ready for me to use?" It's not like the first draft of this prototype that was what we jumped to. I want to be clear.

+ +

The first time we showed someone, there was this interesting problem, which is that we were still talking to the wrong people, somewhat. And the prototype hadn't evolved to be the slam dunk that it is now. So, at first, it was like, we'd have these kinds of muddled conversations where people were like, "Well, I don't really understand what this is supposed to be, and I'm not sure about that. And this seems interesting," but then their interpretation of what that thing was would be, like, wildly off from what it was intended to be. I just want to make it clear: this was work and effort.

+ +

And the team did a really great job of iterating quickly based on, like, every time we talked to someone and showed it to them, we'd come back and say, "Here's what I heard." And it really pushed our thinking forward. Like Josh said, like, we are our toughest critics, so, like, every new version unlocked some new insights in ourselves about what it was we were actually driving toward. Really, just there's nothing like having a thing to look at and bang on to, like, clarify your thinking.

+ +

LINDSEY: There's nothing like having a thing. Jordyn, you touched on you were talking to the wrong people, maybe. How has that exploration of the core market evolved? Is it still the startup enthusiasts? Are you even more narrow in that? What are the updates there as our chief market focus get everyone thinking about this all the time, officer?

+ +

JORDYN: Yes. So, you know, startup enthusiasts is still the umbrella. What you're looking for with this is that you can guarantee pretty much every time you talk to someone in a segment or a sub-segment you will know how the conversation is going to go. And we've gotten there with two sub-segments of startup enthusiasts, which is repeat founders, key, key kind of nuance there. Founders, sure, but repeat founders really have this problem, for reasons we could talk about, and then chiefs of staff at startups, which is a relatively new role that's sort of emerged over the last sort of several years.

+ +

But those folks are really the people that you ask them about this pain point, and they immediately are, like, yes. They use the same words to talk about the pain point. That's another really strong signal. When folks are using the same vocabulary, and they say the same sentences in the same order, and you start to feel a little bit creeped out, like, you're like, "Did you see these questions before I...? What? Did someone pay you to say that?" is, like, how you start to feel [laughs] [crosstalk 09:59]

+ +

LINDSEY: Also, a marketer's dream. Oh my gosh, here comes the messaging, right?

+ +

JORDYN: Exactly.

+ +

LINDSEY: [inaudible 10:04]

+ +

JORDYN: It feels like a cheat code because you just get to reflect their language back to them. You don't have to write copy. They wrote the copy. You just show them it, and they're like, yes. And everyone's like, "Yes," and it works.

+ +

LINDSEY: Any thoughts to add to that, Josh?

+ +

JOSH: It's really good. I would say the bummer or the good thing about this point is we're getting diminishing returns from testing everything other than the actual product, which is good that we got there in eight weeks. But we're not going to learn, you know, keep on adjusting the prototype and making little tweaks and more user research. But the truth is, we're not going to get anything substantial until we get this into some users' hands.

+ +

JORDYN: Like you say, this is sort of bad news, but it's good news.

+ +

JOSH: Right.

+ +

JORDYN: It's how you know, right? When you get to the point where the thing is so clear, and the way to talk about it with folks is so clear that you're not learning as much anymore, diminishing returns is the right way to frame it. You really just need people to get in there and use it. That's the only way you're going to keep learning. That's the moment to build. Hey, everyone out there, don't build before that. That's when you build. And then you really build the smallest thing you can conceive of building, and then whatever that thing is that you've conceived of building that's very small, scope it back by 50% [laughs]. Do it.

+ +

JOSH: And it's a little humbling as someone who considers himself a founder but who had reasonable success as a founder and who has had pretty good success as, like a very, very early-stage, you know, zero to one and 1 to 10 product leader, has done this a bunch of times and actually coaches people in doing this, and came in with, I'm not going to lie, a pretty good vision in my head for how this stuff was supposed to work together. And it's so much better now.

+ +

Going through a process actually makes things better. This wasn't just, like, wasting time. Like, going through a process, a thoughtful process actually makes us much better. Like, the thing we're talking about building is much more likely to be successful than the thing I was originally thinking about building, right, Jordyn?

+ +

JORDYN: Yes. I guess it bears sort of diving into that a little bit, which is, you know, for all the founders out there or folks with a product idea kicking around your head, you're apt to have a little bit of everything we've talked about already. You have an idea of the solution you want to build. You have an idea of who it's for. You have an idea of what their pain points are. And you might be sitting there thinking to yourself, I don't need to do eight weeks of discovery. I already know the answers to all of these questions.

+ +

And it's possible Josh felt that way coming into the incubator, but doing the work, gathering the data, talking to a ton of people, what you can't understand before doing that is how much more confident and at ease you will feel once you have done it and how much clarity you'll have about what it is you need to build first because likely, you're sitting there with a vision in your head for this product that is fully featured, fully formed.

+ +

It is the 18th month. We just went into a hidey hole and built a really complex thing, thing. Cool, don't throw that out. But you got to begin somewhere, and you got to begin somewhere meaningful and valuable. And it's really hard to know where to begin without this discovery, without focusing on a specific person, talking to as many of those folks as you can. And really, it sort of writes itself. It does feel easy. But you've got to set aside the time and the effort to do the research, market research, whatever we call this, customer discovery.

+ +

And it thrills me to no end, Josh, to hear that that is how it felt for you, that you probably felt like you already knew the answer. But it just feels different, having talked to, I mean, how many people, 100-plus people? We were looking at the stats.

+ +

JOSH: Well over 100.

+ +

LINDSEY: Josh was talking to a bunch of people before he came to the incubator, and all the founders that we accept have been doing that. Like, we want to know that you've been doing that research. But then, I guess, coming into the incubator, you're continuing that process and maybe in a more structured or a differently structured way where the thoughtbot team is helping you, maybe zero in far deeper on the segment. Is that accurate to say? Just kind of the difference between, like, maybe some of the pre-research and then the thoughtbot-specific user interviews that happen.

+ +

JOSH: Yeah. I think they were more focused. They're both more focused from the audience, but also more focused from if it's not just you doing it; it forces you to have a more clear, here's the questions we're asking, and here's what we're trying to learn, all these conversations.

+ +

It's also really nice to have some diversity in who's asking the questions. As good or bad as I am at user research and user discovery, I am only one person. And having people with different backgrounds professionally, who live in different countries, who have different feelings about social media, basically, who are not me in a variety of really interesting ways, I think, made the entire process more interesting.

+ +

Caro, who is our lead designer on the project, handed off basically the summary document of, like, everything we learned, and she pulled out, like, little snippets from the interviews. First of all, that is not something I would have done had it been just me, like, let's be very, very clear. This is an incredibly valuable document, particularly as we consider adding additional people onto this project to be able to, like, translate insights. But also, like, this is, like, summarized in a way that, like, takes some real expertise. And I would have walked away with vibes, and instead, we walked away with like, structured learning.

+ +

LINDSEY: Awesome. So, the last time we checked in, also, you were very excited because you had just maybe started a technical spike and were starting to dig into the, okay, like, how technically feasible is this product? And I think, at that point, you all were looking at circling around this target market. Here are the main tools they use to communicate. What does it even look like to connect with those APIs? How possible is it? Can you give us an update on some of that work?

+ +

JOSH: The way that I framed the question in the very beginning was, is this a science project, or is this going to be engineering? And, for the most part, the answer is, it's going to be engineering, right? Some are a little bit easier; some are a little bit harder. But it isn't, like, reinventing new stuff, with one exception, and that is connecting up with iMessages, which has been in the news a little bit. And I honestly just hope the ghost of Steve Jobs comes back and haunts, you know, the Apple headquarters at Cupertino because, come on, guys, interoperability is sort of the future, and you're ruining it for everybody.

+ +

But other than that, I think we have a pretty clear path. I'd like to test out some of these. Like, you don't really know until you do it. I think that's kind of the next step of what we're doing is to, like, demonstrate that it is possible for a person to connect up a couple of different accounts. It is possible for us to extract data and turn that into information and insights in the kinds of ways we thought we could and then present that back in a meaningful way. I think that would be the next step for us to do. Mostly, everything seems feasible, except for iMessages.

+ +

LINDSEY: I've also, I think, heard some whispers of artificial intelligence for Knect. Is that true? Have you all looked at, you know, what AI's role could be in the solution? And how does that research look?

+ +

JORDYN: We assume it will be part of the mix. That said, I don't know how to frame it exactly. It's not like it's not an essential ingredient. I think the work with large language models and the democratization of that work recently is absolutely going to make this product way better than it would have otherwise been. But there are a lot of heuristics we've, like, been able to, you know, draw out and come up with that are, frankly, algorithmic, and they're not AI necessarily. Now, the line between big data plus an algorithm and AI in the popular lexicon, like, there's a big difference between those two things. But, like, as people talk about it, yeah, where does one end and the other begin?

+ +

But we definitely will be making use of a lot of the newest technologies, and we've dabbled in them. I've dabbled in them. I know, Josh, you've been playing around with some of them, too, to the point where we're like, okay, yeah, we can make use of this stuff. It will be a valuable kind of tool in our toolkit, but it will not be the sole basis of value. I guess that's the sort of nuanced answer. But maybe Josh has a more bite-sized hype machine answer to this. Yeah, AI to the moon, right?

+ +

JOSH: Um, no. My only answer would be more cynical. Would anybody rightfully start a company in 2023 without having AI in there someplace? Maybe I'll say something different. One of the things that we've wondered is, there's more than a handful of companies that are adjacent to what we're doing that are definitely looking at similar kinds of problems and that aren't building the solution that, clearly, some market is, like, desperate for. And these are not, like, wildly successful companies that have grown astronomically and changed the market. And, like, trying to figure out, like, why is that?

+ +

And one of the reasons is...I sound like a tech bro, right? There has been a paradigm shift in the technology world, but there really has been. What do, you know, publicly available LLMs like, you know, OpenAI's ChatGPT, like, what have they done? They have taken a whole set of problems that were once really, really complicated and allowed you to do a reasonable job of solving them much more easily than you ever could before.

+ +

And it takes some amount of imagination, to realize that, to realize that these things are more than just, I mean, every product I have on my computer has some kind of OpenAI ChatGPT-style thing in there, right? It's, like, 16 different variations on give me a prompt, and I'll write your essay for you, and they all kind of suck. But those aren't the really exciting uses that I've seen. It's the more subtle things.

+ +

There's a company called Booklet, which tries to replace, like, noisy email lists or noisy communities to something more calm. And one of its features is it'll send you a summary of what's been going on in the community since, like, the last time you checked in. And it gives you, like, two paragraphs to read, and they're really chill and really informative, and they don't make you feel FOMO. They don't make you feel stressed up. Like, okay, stuff's happened in the community. This is really neat. And it's all powered by OpenAI's APIs. And it's really kind of magical. And, like, you have to have a slightly different perspective to imagine these kinds of magical moments. So, that's what I'm excited about.

+ +

There's a set of things that we would have had to do with, like, terrible, complicated queries and, like, pattern matching, and freaking grep, or whatever old-school tools we would have had, you know, for doing things in the past. And now you just get to, like, shove text in one end, and say how you want the results structured and get the results back in the other end. And it doesn't have to be perfect, but that's okay. Like, we're talking about human relationships, which are inherently imperfect. So, I'm fine with this. And it's kind of exciting.

+ +

But we'll see in, you know, if we end up continuing going down this path. Like, that's the goal of the next stage is to be, like, okay, what are the easy things which we can generate out of this? Is there an intersection between, like, easy and meaningful? And if there is, this is pretty exciting.

+ +

JORDYN: Can I add something to that? Which is that the problem Knect is trying to solve and the way that we're trying to solve it, the way we've thought of solving it that's differentiated, lends itself really well to the current landscape of AI tools in that, and you were kind of getting at this, Josh, but I feel like it bears drilling into a little bit, in that what we are proposing here is not a set of deterministic things. We're not going to give you a to-do list. It's not, like, a linear...deterministic is really the right word. Like, there's a to-do list. There are things that make the cut. You got to go address them, et cetera.

+ +

We're way more trying to approximate the way a slightly more put-together person with more time would approach nurturing their relationships, which is just to remember more of it more of the time. It doesn't mean we need to remember all of it every time. That's not the kind of task this is, which makes it a really good task for the place that AI is at right now.

+ +

And I think where folks have failed in the past is that they've either tried to turn it into a deterministic set of tasks, which then just feels like another to-do list, another inbox in a series of to-do lists and inboxes that you have in your life that just make you feel guilty and inadequate. That doesn't seem fun to us. We don't think you need another one of those. Or other places we've seen this fall down, which is that it takes the current sort of state of AI and tries to actually do the deterministic thing for you, but it doesn't do a good enough job right now.

+ +

But where we've kind of landed in the middle is that, again, what we're trying to solve for is solvable in a way more probabilistic way. Like, can we get more of this accomplished more easily for you? It's never going to, like, completely, you know, do the task in this perfect deterministic way. But it is going to make you feel more confident and more relaxed à la Booklet, it sounds like, how to do that for this particular problem, which is a different bar and one we think we can clear. And that really does provide value. People are really longing for this.

+ +

LINDSEY: Jordyn and Josh, building on those descriptions of, like, kind of maybe bad AI use case, good AI use case, could you give some specific examples of, like, what that might look like for Knect, like, how AI could be used in a good way or maybe what you're trying to avoid, more specifically?

+ +

JOSH: Yeah. First, I'm going to start with what I want to avoid, which is, there are tools out there, and these may be interesting to some people listening, and if so, go find them. Good luck. But there are tools out there that say things like, "Keep in touch with your network at scale." And will use AI to write a message which you can send out to people without you ever having to, like, review it. That seems like creepy, futuristic sort of, you know, there's, like, a Black Mirror episode about that.

+ +

Like, the whole point of having, like, a professional network of people who you care about is actually interacting with them. And having some service, like, write some prompt, maybe in its own voice, maybe if it's really good in your voice to, like, let them know that you care about them, let them know that you're thinking about them is, like, that's just bad. I think that's bad. And we don't have any plans to do that kind of thing, even though most uses for AI in the products that I use are writing three or four paragraphs in response to, like, a prompt. So, certainly, that's the common use case.

+ +

It's not very appealing to us, and, frankly, in the people we were talking to, that wasn't one of the things that anybody ever suggested. It's obvious, but as far as we can tell, uninteresting, right? Just because it's obvious and just because it's straightforward doesn't mean it's interesting.

+ +

The things we're imagining, for example, is, talk about Jordyn. Jordyn and I have known each other since 2020, I think. And we have, like, a whole history of text messages going back and forth, which, by the way, we actually could integrate because we both have Android phones, you know, shout-out for Open Internet. It might be interesting to, you know, summarize some of that, like, I know Jordyn pretty well, but other people who I might have not talked with in a while, sure, you could present me with a whole timeline of our communication. But that isn't necessarily useful. I'll have to read every bit of it.

+ +

Why not, like, take all that and summarize, here's things you guys talk about. Here's things that, like, prompted your past few conversations: job change, got laid off, started a company, got a cat. Whatever those topics happen to be like, share some of those things. Bring me up to speed a little bit faster without having to literally review every word that could have been going back multiple years. That's a pretty good use of it.

+ +

If you think about the way that messages work, right? Like, my kids are now at the age where they have phones, and I can now text my kids during the day. I will just tell you, like, this is, like, an incredibly joyful thing for me to be able to send, like, stupid memes to my kids or, like, what's exactly the right emoji to, like, send to them or for them to send to me.

+ +

If every one of these things were, like, pushed to some kind of timeline, and I'm like, "What's going on with my kids?" Like, that's just, like, going back and reading through, like, your WhatsApp thread, which is something that isn't interesting necessarily, at least not from, like, a professional perspective. And there's, like, thousands of these things.

+ +

Like, why do I want, like, a record in my, like, database of people who I talk to that says, "OMG," or "K," or "lol," or those sorts of things? Like, that's, like, a phrase. It isn't a conversation. And we could use an LLM to go summarize what the conversation was all about, which is, by the way, a way more interesting thing to persist over time than, like, my daughter typing "JK, JK, JK," which I think is 15-year-old for laughing at me, but I'm not entirely sure.

+ +

LINDSEY: [laughs] Okay, so as you are...you mentioned wrapping up, and you did your last meeting, and you've got your kind of takeaway docs. You know, one, I'm curious, like, if there's, for your last, you know, days, hours of the program, if there's any final morsels you're trying to get out of it, and then how that kind of leads you into, like, what's next. What are you planning?

+ +

JOSH: Let's do another one of these things in two weeks.

+ +

[laughter]

+ +

LINDSEY: Oh, okay.

+ +

JOSH: Yeah. I'm inviting myself back on your show. We have one more day of school then, like so many folks, we get in a plane or get in a car and go do some travel and try to disconnect a little bit from our professional networks. So, I'm consciously not trying to say what's going to happen next. I would love to have this conversation again, maybe in two weeks, in the new year, about what comes next. I don't know that I could have a meaningful one right now.

+ +

JORDYN: I will say what we are trying to send Josh off with into his R&R is what's it going to take to get to a viable MVP, not merely viable, but actually viable? Given what we know, given all this, you know, work that we've done in the last eight weeks, we now have, you know, the ability to envision what version one of something might be. And so, making that kind of argument: here's why it is what we're imagining it to be; here's what it is; here's what it would take to build that thing, gives Josh a lot of stuff to think about in the meantime in terms of how to accomplish that.

+ +

And the thing that will happen in two weeks is understanding a little bit more about, like, the actual, okay, here's the actual plan. But the ingredients are there, which is super valuable and is a thing we have done every time at the end of every incubator we've done. It's essentially a...it is that what's next plan and why, why that thing. What's the ultimate upside of pursuing this product, and what's the near-term upside? And what's it going to take to get there?

+ +

Because that's often a thing that founders, especially for some founders, which Josh is not, but what they often can't get their heads around is there's this little feeling if you've got this big vision over here, and you've got, like, the set of things you could do tomorrow, really tasky things really, like, operational things, oh, I need to, like, set up a C Corp, but I need to...whatever those things are, right? What's in between? What's that near-term path that's going to directionally head in the direction of that big vision? It's, so far, always, what we have sent founders off with.

+ +

LINDSEY: So, if you weren't here at the very beginning of our session, we mentioned that the applications are now open for session 1 of 2024. I'm curious, Josh, what kind of founders would you recommend for the thoughtbot incubator? What's the profile of someone you might send our way?

+ +

JOSH: I'm going to say something, and I don't think I match that profile, which is interesting, and folks should think about that, what that means. But I would say that if I had to, like, pick a profile, having gone through this, I would say somebody with an idea, of course; ideally, it's one that they have some connection to. They have some personal passion for but, not just because it's an abstract idea but a personal passion that comes from their own experience.

+ +

And it's really great for somebody who hasn't been inside of a tech company before, at least on the tech, half the business. Tech companies have three halves: one half is, you know, the product building side of bit of it or the tech half, which is engineers, and product designers, and product managers. And the other half of that is the go-to-market side, like sales, and marketing, and customer success. And the third half would be, like, operations like HR and finance.

+ +

So, if you have experience in, like, the sales, or the marketing, or the customer success side, or the HR, or the finance, or corporate operations or that part of it, and, you know, you're familiar with tech coming from that perspective but maybe haven't been on the actually building stuff side of them before, this is a really, really good process. Because what does thoughtbot do? It does the building in tech side of things: designers, product managers, and especially engineers.

+ +

And it has this, like, legacy and this history and expertise, therefore, with, like, the journeyman program where they help, like, level people up in those areas and now are applying this to founders. Because as the founder, you do need to develop some ability to converse around engineering and technical stuff. And you really, really, really, really need to get good at the discovery side, especially of, like, product design and product management. And those are the things you're going to get to do and you're going to get to do with people who are themselves really, really good at it. And that's awesome.

+ +

The flip side is if you're, you know, a founder who is super attached to every bit of your vision, and you think you have the strategy all laid out and you're just looking for, like, warm bodies to build it, I mean, is it the insight team? What's the right level at thoughtbot? I forget the names of things, but, like, thoughtbot has, like, a startup program where you can give thoughtbot money, and they will build things for you. And they're also really, really good at that, but that's not the incubator program. The incubator program is probably a step earlier.

+ +

So, I think it is worth thinking, are you at the I'm so confident of my vision; I'm so confident in my strategy that I just want to get this thing built, then maybe don't sign up for the Incubator.

+ +

But if you're at the stage of I think this is a problem; I'm pretty sure this is a problem; I really want it to get solved; I have some vision, but I know it's going to change, then I think the incubator is really ideal, especially if you're looking to upskill yourself, too, because you're going to walk away with the ability to be conversant around the technology stuff. And you're going to walk away with a crap ton of experience with the discovery, qualitative discovery, like user interviews, quantitative discovery, like, you know, running ads, and landing pages, and all that stuff. Like, you're going to be really solid with that stuff after eight weeks because you will have done it.

+ +

LINDSEY: Jordyn, any thoughts?

+ +

JORDYN: I love all that. I think it's accurate. I would only say to those of you sitting out there who are thinking, I'm in that other camp; I'm very confident about what it is I want to build; I would ask you to do a little soul-searching as to whether that's actually true. Like, what evidence do you have? If you needed to stand up in court and defend your conclusions and your vision, could you?

+ +

And I say that as the person who, as a first-time founder, was deluded in that way. I thought I knew exactly what I was doing and for whom and why. And, boy, howdy, could I have used a program like this to actually get me to sit down and, like, talk to people, listen to them, figure out what was valuable and what wasn't, what a valuable, you know, initial market offering was going to be like. Ah, I wish really, really badly that I'd had something like this because I was pretty deluded. I don't even know, like, what the right word is. I just didn't know what I didn't know.

+ +

So, like the way you described it, Josh, I know Jordyn of 2017 would have been like, "That's me. I know this thing that I need to do.

+ +

LINDSEY: [laughs]

+ +

JORDYN: So, I don't need to apply to this program because I don't need to do any of that discovery work." But I was wrong [laughs]. I was absolutely wrong. I was wrong to the tune of, you know, two years and $150,000 of angel investment. So, consider, it is not idly that I say this to you, person sitting out there who feels very confident in your vision right now. Perhaps you have done all those things already; in that case, [inaudible 33:43] you don't need this. And you just need to [inaudible 33:46] with the thing you already know to be true. But ask yourself, how do you know what you know?

+ +

LINDSEY: Yeah, even if you...we can help you build the thing. But we're probably, also, still going to push you on [laughs] some of those things we [crosstalk 34:01].

+ +

JORDYN: Yeah, we're still going to ask. We're going to ask to see the receipts.

+ +

LINDSEY: Yeah [laughs].

+ +

JORDYN: And maybe you have the receipts, which is great, but we're still going to ask you for them, I guess, is my point. Every team at thoughtbot will ask you for the receipts, by the way, not just mine [laughs].

+ +

LINDSEY: The other interesting thing you touched on, Josh, was, I think, where we kind of started the incubator was with that target profile that you just described, which is, like, the less technical founder, and maybe even, like, a first-time founder. And then over time and seeing, like, applications, we broadened that as we saw, like, oh, you know, actually, also, technical founders and repeat founders do still need, like, help with this and can use guidance. So, we've expanded a bit, and maybe that is still, like, the person who gets the most value at the end of the day is the non-technical who hasn't really done this before. But yeah, we've kind of expanded to those other profiles as well.

+ +

JOSH: There's a reason that repeat founders are no more successful on average than first-time founders, and it's something really important that Jordyn said, which is, you may think you've done all this, but we're going to ask you for the receipts. Just because you've done this before doesn't mean you're going to be good at it. Chances are, if you've done this before, it's mostly because you got really, really lucky; ask me how I know.

+ +

So, it's nice to have. I mean, I described a profile, and I said that wasn't me. But I'll just tell you, as somebody who, like, spent his entire career, almost his entire career, in the tech side of tech companies, and I think I'm pretty good at it, I'm certainly not the worst at it, thinks I'm pretty good at it, it's still really nice to have a team backing you up in this early moment. It's really nice to have a team.

+ +

JORDYN: Yeah, I will say another thing that we've heard from every founder we've worked with is just how much more real and actionable their idea feels when they have a team sitting there with them taking them seriously, which is another thing, you know, I really would have benefited from is, like, suddenly, when you've got three or more industry professionals sitting there in a Zoom call with you, like, okay, what are we doing? Why are we doing this? How do we know?

+ +

The feeling of being taken seriously in that way and then having a bunch of people working full-time with you for eight weeks, they're in it with you; they're asking the questions; they're talking to people; they're coming back and saying, "I just had the most amazing conversation with someone. Here's what I learned," it just takes your project to a different level of reality.

+ +

Like, we're humans. We're social beings. We create reality together. And when you're working alone, you know, through force of will, you can do a lot, but with a group, it really feels like you're creating something together. And, like Josh said, having those other brains with other experiences in other contexts percolating on your idea it's like bringing a team to bear on something. There's just nothing quite like it, and it's a huge value of the program. Like, we can give you the programming and, in fact, you can go run the programming. It is published in our handbook. The things that we do together you can go do, but it is a whole other matter to do them with a team. It just feels different.

+ +

LINDSEY: Great. Well, I think that's where we're going to end today. I mean, Josh is leaving us hanging a little bit. So, we might need to...we're going to figure out a way to get your final thoughts, conclusions in a few weeks because I know everyone would love to hear what the plan is for Knect. Josh and Jordyn, as always, thank you so much. Any final thoughts or farewells from you today?

+ +

JOSH: I've really enjoyed it. I'm going to miss these folks. Though, apparently, I get to hang out in a special Slack channel forever.

+ +

LINDSEY: Yeah, you get to hang out.

+ +

JOSH: Which is nice.

+ +

LINDSEY: Exactly. You can't get rid of us just yet.

+ +

JOSH: Good. I wouldn't want to.

+ +

LINDSEY: All right. Thanks, y'all. And thanks, everyone, for tuning in.

Special Guests: Jordyn Bonds and Josh Herzig-Marx .

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+WDd2cgu- + + ]]> + + Lindsey Christensen + Josh Herzig-Marx + Jordyn Bonds + + + 507: Scaling New Heights: Innovating in Software Development with Merico's Founders Henry Yin and Maxim Wheatley + https://podcast.thoughtbot.com/507 + 9d66b23f-8306-4c3b-8d28-cafd34df7676 + Thu, 11 Jan 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Host Victoria Guido, Henry Yin, and Maxim Wheatley of Merico, with special guest co-host Joe Ferris of thoughtbot, delve into Merico's evolution from focusing on open-source funding to creating Apache DevLake, emphasizing community-driven development and transparency. They also explore the integration of AI in software engineering, underscoring AI's role in enhancing productivity and the significance of data-driven approaches in team management and software delivery. + 44:42 + no + + + In this episode of the "Giant Robots Smashing Into Other Giant Robots" podcast, host Victoria Guido delves into the intersection of technology, product development, and personal passions with her guests Henry Yin, Co-Founder and CTO of Merico, and Maxim Wheatley, the company's first employee and Community Leader. They are joined by Joe Ferris, CTO of thoughtbot, as a special guest co-host. The conversation begins with a casual exchange about rock climbing, revealing that both Henry and Victoria share this hobby, which provides a unique perspective on their professional roles in software development. +Throughout the podcast, Henry and Maxim discuss the journey and evolution of Merico, a company specializing in data-driven tools for developers. They explore the early stages of Merico, highlighting the challenges and surprises encountered while seeking product-market fit and the strategic pivot from focusing on open-source funding allocation to developing a comprehensive engineering metric platform. This shift in focus led to the creation of Apache DevLake, an open-source project contributed to by Merico and later donated to the Apache Software Foundation, reflecting the company's commitment to transparency and community-driven development. +The episode also touches on future challenges and opportunities in the field of software engineering, particularly the integration of AI and machine learning tools in the development process. Henry and Maxim emphasize the potential of AI to enhance developer productivity and the importance of data-driven insights in improving team collaboration and software delivery performance. Joe contributes to the discussion with his own experiences and perspectives, particularly on the importance of process over individual metrics in team management. +Merico (https://www.merico.dev/) +Follow Merico on GitHub (https://github.com/merico-dev), Linkedin (https://www.linkedin.com/company/merico-dev/), or X (https://twitter.com/MericoDev). +Apache DevLake (https://devlake.apache.org/) +Follow Henry Yin on LinkedIn (https://www.linkedin.com/in/henry-hezheng-yin-88116a52/). +Follow Maxim Wheatley on LinkedIn (https://www.linkedin.com/in/maximwheatley/) or X (https://twitter.com/MaximWheatley). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Henry Yin, Co-Founder and CTO of Merico, and Maxim Wheatley, the first employee and Community Leader of Merico, creating data-driven developer tools for forward-thinking devs. Thank you for joining us. +HENRY: Thanks for having us. +MAXIM: Glad to be here, Victoria. Thank you. +VICTORIA: And we also have a special guest co-host today, the CTO of thoughtbot, Joe Ferris. +JOE: Hello. +VICTORIA: Okay. All right. So, I met Henry and Maxim at the 7CTOs Conference in San Diego back in November. And I understand that Henry, you are also an avid rock climber. +HENRY: Yes. I know you were also in Vegas during Thanksgiving. And I sort of have [inaudible 00:49] of a tradition to go to Vegas every Thanksgiving to Red Rock National Park. Yeah, I'd love to know more about how was your trip to Vegas this Thanksgiving. +VICTORIA: Yes. I got to go to Vegas as well. We had a bit of rain, actually. So, we try not to climb on sandstone after the rain and ended up doing some sport climbing on limestone around the Blue Diamond Valley area; a little bit light on climbing for me, actually, but still beautiful out there. I loved being in Red Rock Canyon outside of Las Vegas. +And I do find that there's just a lot of developers and engineers who have an affinity for climbing. I'm not sure what exactly that connection is. But I know, Joe, you also have a little bit of climbing and mountaineering experience, right? +JOE: Yeah. I used to climb a good deal. I actually went climbing for the first time in, like, three years this past weekend, and it was truly pathetic. But you have to [laughs] start somewhere. +VICTORIA: That's right. And, Henry, how long have you been climbing for? +HENRY: For about five years. I like to spend my time in nature when I'm not working: hiking, climbing, skiing, scuba diving, all of the good outdoor activities. +VICTORIA: That's great. And I understand you were bouldering in Vegas, right? Did you go to Kraft Boulders? +HENRY: Yeah, we went to Kraft also Red Spring. It was a surprise for me. I was able to upgrade my outdoor bouldering grade to B7 this year at Red Spring and Monkey Wrench. There was always some surprises for me. When I went to Red Rock National Park last year, I met Alex Honnold there who was shooting a documentary, and he was really, really friendly. So, really enjoying every Thanksgiving trip to Vegas. +VICTORIA: That's awesome. Yeah, well, congratulations on B7. That's great. It's always good to get a new grade. And I'm kind of in the same boat with Joe, where I'm just constantly restarting my climbing career. So [laughs], I haven't had a chance to push a grade like that in a little while. But that sounds like a lot of fun. +HENRY: Yeah, it's really hard to be consistent on climbing when you have, like, a full-time job, and then there's so much going on in life. It's always a challenge. +VICTORIA: Yeah. But a great way to like, connect with other people, and make friends, and spend time outdoors. So, I still really appreciate it, even if I'm not maybe progressing as much as I could be. That's wonderful. So, tell me, how did you and Maxim actually meet? Did you meet through climbing or the outdoors? +MAXIM: We actually met through AngelList, which I really recommend to anyone who's really looking to get into startups. When Henry and I met, Merico was essentially just starting. I had this eagerness to explore something really early stage where I'd get to do all of the interesting kind of cross-functional things that come with that territory, touching on product and marketing, on fundraising, kind of being a bit of everything. And I was eager to look into something that was applying, you know, machine learning, data analytics in some really practical way. +And I came across what Hezheng Henry and the team were doing in terms of just extracting useful insights from codebases. And we ended up connecting really well. And I think the previous experience I had was a good fit for the team, and the rest was history. And we've had a great time building together for the last five years. +VICTORIA: Yeah. And tell me a little bit more about your background and what you've been bringing to the Merico team. +MAXIM: I think, like a lot of people in startups, consider myself a member of the Island of Misfit Toys in the sense that no kind of clear-cut linear pathway through my journey but a really exciting and productive one nonetheless. So, I began studying neuroscience at Georgetown University in Washington, D.C. I was about to go to medical school and, in my high school years had explored entrepreneurship in a really basic way. I think, like many people do, finding ways to monetize my hobbies and really kind of getting infected with that bug that I could create something, make money from it, and kind of be the master of my own destiny, for lack of less cliché terms. +So, not long after graduating, I started my first job that recruited me into a seed-stage venture capital, and from there, I had the opportunity to help early-stage startups, invest in them. I was managing a startup accelerator out there. From there, produced a documentary that followed those startups. Not long after all of that, I ended up co-founding a consumer electronics company where I was leading product, so doing lots of mechanical, electrical, and a bit of software engineering. +And without taking too long, those were certainly kind of two of the more formative things. But one way or another, I've spent my whole career now in startups and, especially early-stage ones. It was something I was eager to do was kind of take some of the high-level abstract science that I had learned in my undergraduate and kind of apply some of those frameworks to some of the things that I do today. +VICTORIA: That's super interesting. And now I'm curious about you, Henry, and your background. And what led you to get the idea for Merico? +HENRY: Yeah. My professional career is actually much simpler because Merico was my first company and my first job. Before Merico, I was a PhD student at UC Berkeley studying computer science. My research was an intersection of software engineering and machine learning. And back then, we were tackling this research problem of how do we fairly measure the developer contributions in a software project? +And the reason we are interested in this project has to do with the open-source funding problem. So, let's say an open-source project gets 100k donations from Google. How does the maintainers can automatically distribute all of the donations to sometimes hundreds or thousands of contributors according to their varying level of contributions? So, that was the problem we were interested in. We did research on this for about a year. We published a paper. And later on, you know, we started the company with my, you know, co-authors. And that's how the story began for Merico. +VICTORIA: I really love that. And maybe you could tell me just a little bit more about what Merico is and why a company may be interested in trying out your services. +HENRY: The product we're currently offering actually is a little bit different from what we set out to build. At the very beginning, we were building this platform for open-source funding problem that we can give an open-source project. We can automatically, using algorithm, measure developer contributions and automatically distribute donations to all developers. But then we encountered some technical and business challenges. +So, we took out the metrics component from the previous idea and launched this new product in the engineering metric space. And this time, we focus on helping engineering leaders better understand the health of their engineering work. So, this is the Merico analytics platform that we're currently offering to software engineering teams. +JOE: It's interesting. I've seen some products that try to judge the health of a codebase, but it sounds like this is more trying to judge the health of the team. +MAXIM: Yeah, I think that's generally fair to say. As we've evolved, we've certainly liked to describe ourselves as, you know, I think a lot of people are familiar with observability tools, which help ultimately ascertain, like, the performance of the technology, right? Like, it's assessing, visualizing, chopping up the machine-generated data. And we thought there would be a tremendous amount of value in being, essentially, observability for the human-generated data. +And I think, ultimately, what we found on our journey is that there's a tremendous amount of frustration, especially in larger teams, not in looking to use a tool like that for any kind of, like, policing type thing, right? Like, no one's looking if they're doing it right, at least looking to figure out, like, oh, who's underperforming, or who do we need to yell at? But really trying to figure out, like, where are the strengths? Like, how can we improve our processes? How can we make sure we're delivering better software more reliably, more sustainably? Like how are we balancing that trade-off between new features, upgrades and managing tech debt and bugs? +We've ultimately just worked tirelessly to, hopefully, fill in those blind spots for people. And so far, I'm pleased to say that the reception has been really positive. We've, I think, tapped into a somewhat subtle but nonetheless really important pain point for a lot of teams around the world. +VICTORIA: Yeah. And, Henry, you said that you started it based on some of the research that you did at UC Berkeley. I also understand you leaned on the research from the DevOps research from DORA. Can you tell me a little bit more about that and what you found insightful from the research that was out there and already existed? +MAXIM: So, I think what's really funny, and it really speaks to, I think, the importance in product development of just getting out there and speaking with your potential users or actual users, and despite all of the deep, deep research we had done on the topic of understanding engineering, we really hadn't touched on DORA too much. And this is probably going back about five years now. +Henry and I were taking a customer meeting with an engineering leader at Yahoo out in the Bay Area. He kind of revealed this to us basically where he's like, "Oh, you guys should really look at incorporating DORA into this thing. Like, all of the metrics, all of the analytics you're building super cool, super interesting, but DORA really has this great framework, and you guys should look into it." +And in hindsight, I think we can now [chuckles], honestly, admit to ourselves, even if it maybe was a bit embarrassing at the time where both Henry and I were like, "What? What is that? Like, what's Dora?" And we ended up looking into it and since then, have really become evangelists for the framework. And I'll pass it to Henry to talk about, like, what that journey has looked like. +HENRY: Thanks, Maxim. I think what's cool about DORA is in terms of using metrics, there's always this challenge called Goodhart's Law, right? So, whenever a metric becomes a target, the metric cease to be a good metric because people are going to find ways to game the metric. So, I think what's cool about DORA is that it actually offers not just one metric but four key metrics that bring balance to covering both the stability and velocity. +So, when you look at DORA metrics, you can't just optimize for velocity and sacrificing your stability. But you have to look at all four metrics at the same time, and that's harder to game. So, I think that's why it's become more and more popular in the industry as the starting point for using metrics for data-driven engineering. +VICTORIA: Yeah. And I like how DORA also represents it as the metrics and how they apply to where you are in the lifecycle of your product. So, I'm curious: with Merico, what kind of insights do you think engineering leaders can gain from having this data that will unlock some of their team's potential? +MAXIM: So, I think one of the most foundational things before we get into any detailed metrics is I think it's more important than ever, especially given that so many of us are remote, right? Where the general processes of software engineering are generally difficult to understand, right? They're nuanced. They tend to kind of happen in relative isolation until a PR is reviewed and merged. And it can be challenging, of course, to understand what's being done, how consistently, how well, like, where are the good parts, where are the bad parts. And I think that problem gets really exasperated, especially in a remote setting where no one is necessarily in the same place. +So, on a foundational level, I think we've really worked hard to solve that challenge, where just being able to see, like, how are we doing? And to that point, I think what we've found before anyone even dives too deep into all of the insights that we can deliver, I think there's a tremendous amount of appetite for anyone who's looking to get into that practice of constant improvement and figuring out how to level up the work they're doing, just setting close benchmarks, figuring out, like, okay, when we talk about more nebulous or maybe subjective terms like speed, or quality, what does good look like? What does consistent look like? +Being able to just tie those things to something that really kind of unifies the vocabulary is something I always like to say, where, okay, now, even if we're not focused on a specific metric, or we don't have a really particular goal in mind that we want to assess, now we're at least starting the conversation as a team from a place where when we talk about quality, we have something that's shared between us. We understand what we're referring to. And when we're talking about speed, we can also have something consistent to talk about there. +And within all of that, I think one of the most powerful things is it helps to really kind of ground the conversations around the trade-offs, right? There's always that common saying: the triangle of trade-offs is where it's, like, you can have it cheap; you can have it fast, and you can have it good, but you can only have two. And I think with DORA, with all of these different frameworks with many metrics, it helps to really solidify what those trade-offs look like. And that's, for me at least, been one of the most impactful things to watch: is our global users have really started evolving their practices with it. +HENRY: Yeah. And I want to add to Maxim's answer. But before that, I just want to quickly mention how our products are structured. So, Merico actually has an open-source component and a proprietary component. So, the open-source component is called Apache DevLake. It's an open-source project we created first within Merico and later on donated to Apache Software Foundation. And now, it's one of the most popular engineering metrics tool out there. +And then, on top of that, we built a SaaS offering called DevInsight Cloud, which is powered by Apache DevLake. So, with DevLake, the open-source project, you can set up your data connections, connect DevLake to all of the dev tools you're using, and then we collect data. And then we provide many different flavors of dashboards for our users. +And many of those dashboards are structured, and there are different questions engineering teams might want to ask. For example, like, how fast are we responding to our customer requirement? For that question, we will look at like, metrics like change lead time, or, like, for a question, how accurate is our planning for the sprint? In that case, the dashboard will show metrics relating to the percentage of issues we can deliver for every sprint for our plan. So, that's sort of, you know, based on the questions that the team wants to answer, we provide different dashboards that help them extract insights using the data from their DevOps tools. +JOE: It's really interesting you donated it to Apache. And I feel like the hybrid SaaS open-source model is really common. And I've become more and more skeptical of it over the years as companies start out open source, and then once they start getting competitors, they change the license. But by donating it to Apache, you sort of sidestep that potential trust issue. +MAXIM: Yeah, you've hit the nail on the head with that one because, in many ways, for us, engaging with Apache in the way that we have was, I think, ultimately born out of the observations we had about the shortcomings of other products in the space where, for one, very practical. We realized quickly that if we wanted to offer the most complete visibility possible, it would require connections to so many different products, right? +I think anyone can look at their engineering toolchain and identify perhaps 7, 9, 10 different things they're using on a day-to-day basis. Oftentimes, those aren't shared between companies, too. So, I think part one was just figuring out like, okay, how do we build a framework that makes it easy for developers to build a plugin and contribute to the project if there's something they want to incorporate that isn't already supported? And I think that was kind of part one. +Part two is, I think, much more important and far more profound, which is developer trust, right? Where we saw so many different products out there that claimed to deliver these insights but really had this kind of black-box approach, right? Where data goes in, something happens, insights come out. How's it doing that? How's it weighting things? What's it calculating? What variables are incorporated? All of that is a mystery. And that really leads to developers, rightfully, not having a basis to trust what's actually being shown to them. +So, for us, it was this perspective of what's the maximum amount of transparency that we could possibly offer? Well, open source is probably the best answer to that question. We made sure the entirety of the codebase is something they can take a look at, they can modify. They can dive into the underlying queries and algorithms and how everything is working to gain a total sense of trust in how is this thing working? And if I need to modify something to account for some nuanced details of how our team works, we can also do that. +And to your point, you know, I think it's definitely something I would agree with that one of the worst things we see in the open-source community is that companies will be kind of open source in name only, right? Where it's really more of marketing or kind of sales thing than anything, where it's like, oh, let's tap into the good faith of open source. But really, somehow or another, through bait and switch, through partial open source, through license changes, whatever it is, we're open source in name only but really, a proprietary, closed-source product. +So, for us, donating the core of DevLake to the Apache Foundation was essentially our way of really, like, putting, you know, walking the talk, right? Where no one can doubt at this point, like, oh, is this thing suddenly going to have the license changed? Is this suddenly going to go closed-source? Like, the answer to that now is a definitive no because it is now part of that ecosystem. +And I think with the aspirations we've had to build something that is not just a tool but, hopefully, long-term becomes, like, foundational technology, I think that gives people confidence and faith that this is something they can really invest in. They can really plumb into their processes in a deep and meaningful way with no concerns whatsoever that something is suddenly going to change that makes all of that work, you know, something that they didn't expect. +JOE: I think a lot of companies guard their source code like it's their secret sauce, but my experience has been more that it's the secret shame [laughs]. +HENRY: [laughs] +MAXIM: There's no doubt in my role with, especially our open-source product driving our community we've really seen the magic of what a community-driven product can be. And open source, I think, is the most kind of a true expression of a community-driven product, where we have a Slack community with nearly 1,000 developers in it now. Naturally, right? Some of those developers are in there just to ask questions and answer questions. Some are intensely involved, right? They're suggesting improvements. They're suggesting new features. They're finding ways to refine things. +And it really is that, like, fantastic culture that I'm really proud that we've cultivated where best idea ships, right? If you've got a good idea, throw it into a GitHub issue or a comment. Let's see how the community responds to it. Let's see if someone wants to pick it up. Let's see if someone wants to submit a PR. If it's good, it goes into production, and then the entire community benefits. And, for me, that's something I've found endlessly exciting. +HENRY: Yeah. I think Joe made a really good point on the secret sauce part because I don't think the source code is our secret sauce. There's no rocket science in DevLake. If we break it down, it's really just some UI UX plus data pipelines. I think what's making DevLake successful is really the trust and collaboration that we're building with the open-source community. When it comes to trust, I think there are two aspects. First of all, trust on the metric accuracy, right? Because with a lot of proprietary software, you don't know how they are calculating the metrics. If people don't know how the metrics are calculated, they can't really trust it and use it. +And secondly, is the trust that they can always use this software, and there's no vendor lock-in. And when it comes to collaboration, we were seeing many of our data sources and dashboards they were contributed not by our core developers but by the community. And the communities really, you know, bring in their insights and their use cases into DevLake and make DevLake, you know, more successful and more applicable to more teams in different areas of soft engineering. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +VICTORIA: I understand you've taken some innovative approaches on using AI in your open-source repositories to respond to issues and questions from your developers. So, can you tell me a little bit more about that? +HENRY: Absolutely. I self-identify as a builder. And one characteristic of builder is to always chase after the dream of building infinite things within the finite lifespan. So, I was always thinking about how we can be more productive, how we can, you know, get better at getting better. And so, this year, you know, AI is huge, and there are so many AI-powered tools that can help us achieve more in terms of delivering software. +And then, internally, we had a hackathon, and there's one project, which is an AI-powered coding assistant coming out of it called DevChat. And we have made it public at devchat.ai. But we've been closely following, you know, what are the other AI-powered tools that can make, you know, software developers' or open-source maintainers' lives easier? And we've been observing that there are more and more open-source projects adopting AI chatbots to help them handle, you know, respond to GitHub issues. +So, I recently did a case study on a pretty popular open-source project called LangChain. So, it's the hot kid right now in the AI space right now. And it's using a chatbot called Dosu to help respond to issues. I had some interesting findings from the case study. +VICTORIA: In what ways was that chatbot really helpful, and in what ways did it not really work that well? +HENRY: Yeah, I was thinking of how to measure the effectiveness of that chatbot. And I realized that there is a feature that's built in GitHub, which is the reaction to comment. So, how the chatbot works is whenever there is a new issue, the chatbot would basically retrieval-augmented generation pipeline and then using ORM to generate a response to the issue. And then there's people leave reactions to that comment by the chatbot, but mostly, it's thumbs up and thumbs down. +So, what I did is I collect all of the issues from the LangChain repository and look at how many thumbs up and thumbs down Dosu chatbot got, you know, from all of the comments they left with the issues. So, what I found is that over across 2,600 issues that Dosu chatbot helped with, it got around 900 thumbs ups and 1,300 thumbs down. So, then it comes to how do we interpret this data, right? Because it got more thumbs down than thumbs up doesn't mean that it's actually not useful or harmful to the developers. +So, to answer that question, I actually looked at some examples of thumbs-up and thumb-down comments. And what I found is the thumb down doesn't mean that the chatbot is harmful. It's mostly the developers are signaling to the open-source maintainers that your chatbot is not helping in this case, and we need human intervention. But with the thumbs up, the chatbot is actually helping a lot. +There's one issue where people post a question, and the chatbot just wrote the code and then basically made a suggestion on how to resolve the issue. And the human response is, "Damn, it worked." And that was very surprising to me, and it made me consider, you know, adopting similar technology and AI-powered tools for our own open-source project. +VICTORIA: That's very cool. Well, I want to go back to the beginning of Merico. And when you first got started, and you were trying to understand your customers and what they need, was there anything surprising in that early discovery process that made you change your strategy? +HENRY: So, one challenge we faced when we first explored open-source funding allocation problem space is that our algorithm looks at the Git repository. But with software engineering, especially with open-source collaboration, there are so many activities that are happening outside of open-source repos on GitHub. For example, I might be an evangelist, and my day-to-day work might be, you know, engaging in community work, talking about the open-source project conference. And all of those things were not captured by our algorithm, which was only looking at the GitHub repository at the time. So, that was one of the technical challenge that we faced and led us to switch over to more of the system-driven metrics side. +VICTORIA: Gotcha. Over the years, how has Merico grown? What has changed between when you first started and today? +HENRY: So, one thing is the team size. When we just got started, we only have, you know, the three co-founders and Maxim. And now we have grown to a team of 70 team members, and we have a fully distributed team across multiple continents. So, that's pretty interesting dynamics to handle. And we learned a lot of how to build effective team and a cohesive team along the way. +And in terms of product, DevLake now, you know, has more than 900 developers in our Slack community, and we track over 360 companies using DevLake. So, definitely, went a long way since we started the journey. And yeah, tomorrow we...actually, Maxim and I are going to host our end-of-year Apache DevLake Community Meetup and featuring Nathen Harvey, the Google's DORA team lead. Yeah, definitely made some progress since we've been working on Merico for four years. +VICTORIA: Well, that's exciting. Well, say hi to Nathen for me. I helped takeover DevOps DC with some of the other organizers that he was running way back in the day, so [laughs] that's great. What challenges do you see on the horizon for Merico and DevLake? +MAXIM: One of the challenges I think about a lot, and I think it's front of mind for many people, especially with software engineering, but at this point, nearly every profession, is what does AI mean for everything we're doing? What does the future look like where developers are maybe producing the majority of their code through prompt-based approaches versus code-based approaches, right? How do we start thinking about how we coherently assess that? +Like, how do you maybe redefine what the value is when there's a scenario where perhaps all coders, you know, if we maybe fast forward a few years, like, what if the AI is so good that the code is essentially perfect? What does success look like then? How do you start thinking about what is a good team if everyone is shooting out 9 out of 10 PRs nearly every time because they're all using a unified framework supported by AI? So, I think that's certainly kind of one of the challenges I envision in the future. +I think, really, practically, too, many startups have been contending with the macroclimate within the fundraising climates. You know, I think many of the companies out there, us included, had better conditions in 2019, 2020 to raise funds at more favorable valuations, perhaps more relaxed terms, given the climate of the public markets and, you know, monetary policy. I think that's, obviously, we're all experiencing and has tightened things up like revenue expectations or now higher kind of expectations on getting into a highly profitable place or, you know, the benchmark is set a lot higher there. +So, I think it's not a challenge that's unique to us in any way at all. I think it's true for almost every company that's out there. It's now kind of thinking in a more disciplined way about how do you kind of meet the market demands without compromising on the product vision and without compromising on the roadmap and the strategies that you've put in place that are working but are maybe coming under a little bit more pressure, given kind of the new set of rules that have been laid out for all of us? +VICTORIA: Yeah, that is going to be a challenge. And do you see the company and the product solving some of those challenges in a unique way? +HENRY: I've been thinking about how AI can fulfill the promise of making developers 10x developer. I'm an early adopter and big fan of GitHub Copilot. I think it really helps with writing, like, the boilerplate code. But I think it's improving maybe my productivity by 20% to 30%. It's still pretty far away from 10x. So, I'm thinking how Merico's solutions can help fill the gap a little bit. +In terms of Apache DevLake and its SaaS offering, I think we are helping with, like, the team collaboration and measuring, like, software delivery performance, how can the team improve as a whole. And then, recently, we had a spin-off, which is the AI-powered coding assistant DevChat. And that's sort of more on the empowering individual developers with, like, testing, refactoring these common workflows. +And one big thing for us in the future is how we can combine these two components, you know, team collaboration and improvement tool, DevLake, with the individual coding assistant, DevChat, how they can be integrated together to empower developers. I think that's the big question for Merico ahead. +JOE: Have you used Merico to judge the contributions of AI to a project? +HENRY: [laughs] So, actually, after we pivot to engineering metrics, we focus now less on individual contribution because that sometimes can be counterproductive. Because whenever you visualize that, then people will sometimes become defensive and try to optimize for the metrics that measure individual contributions. So, we sort of...nowadays, we no longer offer that kind of metrics within DevLake, if that makes sense. +MAXIM: And that kind of goes back to one of Victoria's earlier questions about, like, what surprised us in the journey. Early on, we had this very benevolent perspective, you know, I would want to kind of underline that, that we never sought to be judging individuals in a negative way. We were looking to find ways to make it useful, even to a point of finding ways...like, we explored different ways to give developers badges and different kind of accomplishment milestones, like, things to kind of signal their strengths and accomplishments. +But I think what we've found in that journey is that...and I would really kind of say this strongly. I think the only way that metrics of any kind serve an organization is when they support a healthy culture. And to that end, what we found is that we always like to preach, like, it's processes, not people. It's figuring out if you're hiring correctly, if you're making smart decisions about who's on the team. I think you have to operate with a default assumption within reason that those people are doing their best work. They're trying to move the company forward. They're trying to make good decisions to better serve the customers, better serve the company and the product. +With that in mind, what you're really looking to do is figure out what is happening within the underlying processes that get something from thought to production. And how do you clear the way for people? And I think that's really been a big kind of, you know, almost like a tectonic shift for our company over the years is really kind of fully transitioning to that. And I think, in some ways, DORA has represented kind of almost, like, a best practice for, like, processes over people, right? +It's figuring out between quality and speed; how are you doing? Where are those trade-offs? And then, within the processes that account for those outcomes, how can you really be improving things? So, I would say, for us, that's, like, been kind of the number one thing there is figuring out, like, how do we keep doubling down on processes, not people? And how do we really make sure that we're not just telling people that we're on their side and we're taking a, you know, a very humanistic perspective on wanting to improve the lives of people but actually doing it with the product? +HENRY: But putting the challenge on measuring individual contributions aside, I'm as curious as Joe about AI's role in software engineering. I expect to see more and more involvement of AI and gradually, you know, replacing low-level and medium-level and, in the future, even high-level tasks for humans so we can just focus on, like, the objective instead of the implementation. +VICTORIA: I can imagine, especially if you're starting to integrate AI tools into your systems and if you're growing your company at scale, some of the ability to have a natural intuition about what's going on it really becomes a challenge, and the data that you can derive from some of these products could help you make better decisions and all different types of things. +So, I'm kind of curious to hear from Joe; with your history of open-source contribution and being a part of many different development teams, what kind of information do you wish that you had to help you make decisions in your role? +JOE: Yeah, that's an interesting question. I've used some tools that try to identify problem spots in the code. But it'd be interesting to see the results of tools that analyze problem spots in the process. Like, I'd like to learn more about how that works. +HENRY: I'm curious; one question for Joe. What is your favorite non-AI-powered code scanning tool that you find useful for yourself or for your team? +JOE: I think the most common static analysis tool I use is something to find the Git churn in a repository. Some of this probably is because I've worked mostly on projects these days with dynamic languages. So, there's kind of a limit to how much static analysis you can do of, you know, a Ruby or a Python codebase. But just by analyzing which parts of the application changed the most, help you find which parts are likely to be the buggiest and the most complex. +I think every application tends to involve some central model. Like, if you're making an e-commerce site, then probably products are going to have a lot of the core logic, purchases will have a lot of the core logic. And identifying those centers of gravity just through the Git statistics has helped me find places that need to be reworked. +HENRY: That's really interesting. Is it something like a hotspot analysis? And when you find a hotspot, then would you invest more resources in, like, refactoring the hotspot to make it more maintainable? +JOE: Right, exactly. Like, you can use the statistics to see which files you should look at. And then, usually, when you actually go into the files, especially if you look at some of the changes to the files, it's pretty clear that it's become, you know, for example, a class has become too large, something has become too tightly coupled. +HENRY: Gotcha. +VICTORIA: Yeah. And so, if you could go back in time, five years ago and give yourself some advice when you first started along this journey, what advice would you give yourself? +MAXIM: I'll answer the question in two ways: first for the company and then for myself personally. I think for the company, what I would say is, especially when you're in that kind of pre-product market fit space, and you're maybe struggling to figure out how to solve a challenge that really matters, I think you need to really think carefully about, like, how would you yourself be using your product? And if you're finding reasons, you wouldn't, like, really, really pay careful attention to those. +And I think, for us, like, early on in our journey, we ultimately kind of found ourselves asking, we're like, okay, we're a smaller earlier stage team. Perhaps, like, small improvements in productivity or quality aren't going to necessarily move the needle. That's one of the reasons maybe we're not using this. Maybe our developers are already at bandwidth. So, it's not a question of unlocking more bandwidth or figuring out where there's kind of weak points or bottlenecks at that level, but maybe how can we dial in our own processes to let the whole team function more effectively. +And I think, for us, like, the more we started thinking through that lens of, like, what's useful to us, like, what's solving a pain point for us, I think, in many ways, DevLake was born out of that exact thinking. And now DevLake is used by hundreds of companies around the world and has, you know, this near thousand developer community that supports it. And I think that's testament to the power of that. +For me, personally, if I were to kind of go back five years, you know, I'm grateful to say there isn't a whole lot I would necessarily change. But I think if there's anything that I would, it would just to be consistently more brave in sharing ideas, right? I think Merico has done a great job, and it's something I'm so proud of for us as a team of really embracing new ideas and really kind of making sure, like, best idea ships, right? There isn't a title. There isn't a level of seniority that determines whether or not someone has a right to suggest something or improve something. +And I think with that in mind, for me as a technical person but not a member of technical staff, so to speak, I think there was many occasions, for me personally, where I felt like, okay, maybe because of that, I shouldn't necessarily weigh in on certain things. And I think what I've found, and it's a trust-building thing as well, is, like, even if you're wrong, even if your suggestion may be misunderstands something or isn't quite on target, there's still a tremendous amount of value in just being able to share a perspective and share a recommendation and push it out there. +And I think with that in mind, like, it's something I would encourage myself and encourage everybody else in a healthy company to feel comfortable to just keep sharing because, ultimately, it's an accuracy-by-volume game to a certain degree, right? Where if I come up with one idea, then I've got one swing at the bat. But if us as a collective come up with 100 ideas that we consider intelligently, we've got a much higher chance of maybe a handful of those really pushing us forward. So, for me, that would be advice I would give myself and to anybody else. +HENRY: I'll follow the same structure, so I'll start by the advice in terms of company and advice to myself as an individual. So, for a company level, I think my advice would be fail fast because every company needs to go through this exploration phase trying to find their product-market fit, and then they will have to test, you know, a couple of ideas before they find the right fit for themselves, the same for us. And I wish that we actually had more in terms of structure in exploring these ideas and set deadlines, you know, set milestones for us to quickly test and filter out bad ideas and then accelerate the exploration process. So, fail fast would be my suggestion at the company level. +From an individual level, I would say it's more adapting to my CTO role because when I started the company, I still had that, you know, graduate student hustle mindset. I love writing code myself. And it's okay if I spent 100% of my time writing code when the company was, you know, at five people, right? But it's not okay [chuckles] when we have, you know, a team of 40 engineers. So, I wish I had that realization earlier, and I transitioned to a real CTO role earlier, focusing more, like, on technical evangelism or building out the technical and non-technical infrastructure to help my engineering teams be successful. +VICTORIA: Well, I really appreciate that. And is there anything else that you all would like to promote today? +HENRY: So if you're, you know, engineering leaders who are looking to measure, you know, some metrics and adopt a more data-driven approach to improving your software delivery performance, check out Apache DevLake. It's open-source project, free to use, and it has some great dashboards, support, various data resources. And join our community. We have a pretty vibrant community on Slack. And there are a lot of developers and engineering leaders discussing how they can get more value out of data and metrics and improve software delivery performance. +MAXIM: Yeah. And I think to add to that, something I think we've found consistently is there's plenty of data skeptics out there, rightfully so. I think a lot of analytics of every kind are really not very good, right? And so, I think people are rightfully frustrated or even traumatized by them. +And for the data skeptics out there, I would invite them to dive into the DevLake community and pose your challenges, right? If you think this stuff doesn't make sense or you have concerns about it, come join the conversation because I think that's really where the most productive discussions end up coming from is not from people mutually high-fiving each other for a successful implementation of DORA. +But the really exciting moments come from the people in the community who are challenging it and saying like, "You know what? Like, here's where I don't necessarily think something is useful or I think could be improved." And it's something that's not up to us as individuals to either bless or to deny. That's where the community gets really exciting is those discussions. So, I would say, if you're a data skeptic, come and dive in, and so long as you're respectful, challenge it. And by doing so, you'll hopefully not only help yourself but really help everybody, which is what I love about this stuff so much. +JOE: I'm curious, does Merico use Merico? +HENRY: Yes. We've been dogfooding ourself a lot. And a lot of the product improvement ideas actually come from our own dogfooding process. For example, there was one time that we look at a dashboard that has this issue change lead time. And then we found our issue, change lead time, you know, went up in the past few month. And then, we were trying to interpret whether that's a good thing or a bad thing because just looking at a single metric doesn't tell us the story behind the change in the metrics. So, we actually improved the dashboard to include some, you know, covariates of the metrics, some other related metrics to help explain the trend of the metric. So yeah, dogfooding is always useful in improving product. +VICTORIA: That's great. Well, thank you all so much for joining. I really enjoyed our conversation. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. + + + In this episode of the "Giant Robots Smashing Into Other Giant Robots" podcast, host Victoria Guido delves into the intersection of technology, product development, and personal passions with her guests Henry Yin, Co-Founder and CTO of Merico, and Maxim Wheatley, the company's first employee and Community Leader. They are joined by Joe Ferris, CTO of thoughtbot, as a special guest co-host. The conversation begins with a casual exchange about rock climbing, revealing that both Henry and Victoria share this hobby, which provides a unique perspective on their professional roles in software development.

+ +

Throughout the podcast, Henry and Maxim discuss the journey and evolution of Merico, a company specializing in data-driven tools for developers. They explore the early stages of Merico, highlighting the challenges and surprises encountered while seeking product-market fit and the strategic pivot from focusing on open-source funding allocation to developing a comprehensive engineering metric platform. This shift in focus led to the creation of Apache DevLake, an open-source project contributed to by Merico and later donated to the Apache Software Foundation, reflecting the company's commitment to transparency and community-driven development.

+ +

The episode also touches on future challenges and opportunities in the field of software engineering, particularly the integration of AI and machine learning tools in the development process. Henry and Maxim emphasize the potential of AI to enhance developer productivity and the importance of data-driven insights in improving team collaboration and software delivery performance. Joe contributes to the discussion with his own experiences and perspectives, particularly on the importance of process over individual metrics in team management.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Henry Yin, Co-Founder and CTO of Merico, and Maxim Wheatley, the first employee and Community Leader of Merico, creating data-driven developer tools for forward-thinking devs. Thank you for joining us.

+ +

HENRY: Thanks for having us.

+ +

MAXIM: Glad to be here, Victoria. Thank you.

+ +

VICTORIA: And we also have a special guest co-host today, the CTO of thoughtbot, Joe Ferris.

+ +

JOE: Hello.

+ +

VICTORIA: Okay. All right. So, I met Henry and Maxim at the 7CTOs Conference in San Diego back in November. And I understand that Henry, you are also an avid rock climber.

+ +

HENRY: Yes. I know you were also in Vegas during Thanksgiving. And I sort of have [inaudible 00:49] of a tradition to go to Vegas every Thanksgiving to Red Rock National Park. Yeah, I'd love to know more about how was your trip to Vegas this Thanksgiving.

+ +

VICTORIA: Yes. I got to go to Vegas as well. We had a bit of rain, actually. So, we try not to climb on sandstone after the rain and ended up doing some sport climbing on limestone around the Blue Diamond Valley area; a little bit light on climbing for me, actually, but still beautiful out there. I loved being in Red Rock Canyon outside of Las Vegas.

+ +

And I do find that there's just a lot of developers and engineers who have an affinity for climbing. I'm not sure what exactly that connection is. But I know, Joe, you also have a little bit of climbing and mountaineering experience, right?

+ +

JOE: Yeah. I used to climb a good deal. I actually went climbing for the first time in, like, three years this past weekend, and it was truly pathetic. But you have to [laughs] start somewhere.

+ +

VICTORIA: That's right. And, Henry, how long have you been climbing for?

+ +

HENRY: For about five years. I like to spend my time in nature when I'm not working: hiking, climbing, skiing, scuba diving, all of the good outdoor activities.

+ +

VICTORIA: That's great. And I understand you were bouldering in Vegas, right? Did you go to Kraft Boulders?

+ +

HENRY: Yeah, we went to Kraft also Red Spring. It was a surprise for me. I was able to upgrade my outdoor bouldering grade to B7 this year at Red Spring and Monkey Wrench. There was always some surprises for me. When I went to Red Rock National Park last year, I met Alex Honnold there who was shooting a documentary, and he was really, really friendly. So, really enjoying every Thanksgiving trip to Vegas.

+ +

VICTORIA: That's awesome. Yeah, well, congratulations on B7. That's great. It's always good to get a new grade. And I'm kind of in the same boat with Joe, where I'm just constantly restarting my climbing career. So [laughs], I haven't had a chance to push a grade like that in a little while. But that sounds like a lot of fun.

+ +

HENRY: Yeah, it's really hard to be consistent on climbing when you have, like, a full-time job, and then there's so much going on in life. It's always a challenge.

+ +

VICTORIA: Yeah. But a great way to like, connect with other people, and make friends, and spend time outdoors. So, I still really appreciate it, even if I'm not maybe progressing as much as I could be. That's wonderful. So, tell me, how did you and Maxim actually meet? Did you meet through climbing or the outdoors?

+ +

MAXIM: We actually met through AngelList, which I really recommend to anyone who's really looking to get into startups. When Henry and I met, Merico was essentially just starting. I had this eagerness to explore something really early stage where I'd get to do all of the interesting kind of cross-functional things that come with that territory, touching on product and marketing, on fundraising, kind of being a bit of everything. And I was eager to look into something that was applying, you know, machine learning, data analytics in some really practical way.

+ +

And I came across what Hezheng Henry and the team were doing in terms of just extracting useful insights from codebases. And we ended up connecting really well. And I think the previous experience I had was a good fit for the team, and the rest was history. And we've had a great time building together for the last five years.

+ +

VICTORIA: Yeah. And tell me a little bit more about your background and what you've been bringing to the Merico team.

+ +

MAXIM: I think, like a lot of people in startups, consider myself a member of the Island of Misfit Toys in the sense that no kind of clear-cut linear pathway through my journey but a really exciting and productive one nonetheless. So, I began studying neuroscience at Georgetown University in Washington, D.C. I was about to go to medical school and, in my high school years had explored entrepreneurship in a really basic way. I think, like many people do, finding ways to monetize my hobbies and really kind of getting infected with that bug that I could create something, make money from it, and kind of be the master of my own destiny, for lack of less cliché terms.

+ +

So, not long after graduating, I started my first job that recruited me into a seed-stage venture capital, and from there, I had the opportunity to help early-stage startups, invest in them. I was managing a startup accelerator out there. From there, produced a documentary that followed those startups. Not long after all of that, I ended up co-founding a consumer electronics company where I was leading product, so doing lots of mechanical, electrical, and a bit of software engineering.

+ +

And without taking too long, those were certainly kind of two of the more formative things. But one way or another, I've spent my whole career now in startups and, especially early-stage ones. It was something I was eager to do was kind of take some of the high-level abstract science that I had learned in my undergraduate and kind of apply some of those frameworks to some of the things that I do today.

+ +

VICTORIA: That's super interesting. And now I'm curious about you, Henry, and your background. And what led you to get the idea for Merico?

+ +

HENRY: Yeah. My professional career is actually much simpler because Merico was my first company and my first job. Before Merico, I was a PhD student at UC Berkeley studying computer science. My research was an intersection of software engineering and machine learning. And back then, we were tackling this research problem of how do we fairly measure the developer contributions in a software project?

+ +

And the reason we are interested in this project has to do with the open-source funding problem. So, let's say an open-source project gets 100k donations from Google. How does the maintainers can automatically distribute all of the donations to sometimes hundreds or thousands of contributors according to their varying level of contributions? So, that was the problem we were interested in. We did research on this for about a year. We published a paper. And later on, you know, we started the company with my, you know, co-authors. And that's how the story began for Merico.

+ +

VICTORIA: I really love that. And maybe you could tell me just a little bit more about what Merico is and why a company may be interested in trying out your services.

+ +

HENRY: The product we're currently offering actually is a little bit different from what we set out to build. At the very beginning, we were building this platform for open-source funding problem that we can give an open-source project. We can automatically, using algorithm, measure developer contributions and automatically distribute donations to all developers. But then we encountered some technical and business challenges.

+ +

So, we took out the metrics component from the previous idea and launched this new product in the engineering metric space. And this time, we focus on helping engineering leaders better understand the health of their engineering work. So, this is the Merico analytics platform that we're currently offering to software engineering teams.

+ +

JOE: It's interesting. I've seen some products that try to judge the health of a codebase, but it sounds like this is more trying to judge the health of the team.

+ +

MAXIM: Yeah, I think that's generally fair to say. As we've evolved, we've certainly liked to describe ourselves as, you know, I think a lot of people are familiar with observability tools, which help ultimately ascertain, like, the performance of the technology, right? Like, it's assessing, visualizing, chopping up the machine-generated data. And we thought there would be a tremendous amount of value in being, essentially, observability for the human-generated data.

+ +

And I think, ultimately, what we found on our journey is that there's a tremendous amount of frustration, especially in larger teams, not in looking to use a tool like that for any kind of, like, policing type thing, right? Like, no one's looking if they're doing it right, at least looking to figure out, like, oh, who's underperforming, or who do we need to yell at? But really trying to figure out, like, where are the strengths? Like, how can we improve our processes? How can we make sure we're delivering better software more reliably, more sustainably? Like how are we balancing that trade-off between new features, upgrades and managing tech debt and bugs?

+ +

We've ultimately just worked tirelessly to, hopefully, fill in those blind spots for people. And so far, I'm pleased to say that the reception has been really positive. We've, I think, tapped into a somewhat subtle but nonetheless really important pain point for a lot of teams around the world.

+ +

VICTORIA: Yeah. And, Henry, you said that you started it based on some of the research that you did at UC Berkeley. I also understand you leaned on the research from the DevOps research from DORA. Can you tell me a little bit more about that and what you found insightful from the research that was out there and already existed?

+ +

MAXIM: So, I think what's really funny, and it really speaks to, I think, the importance in product development of just getting out there and speaking with your potential users or actual users, and despite all of the deep, deep research we had done on the topic of understanding engineering, we really hadn't touched on DORA too much. And this is probably going back about five years now.

+ +

Henry and I were taking a customer meeting with an engineering leader at Yahoo out in the Bay Area. He kind of revealed this to us basically where he's like, "Oh, you guys should really look at incorporating DORA into this thing. Like, all of the metrics, all of the analytics you're building super cool, super interesting, but DORA really has this great framework, and you guys should look into it."

+ +

And in hindsight, I think we can now [chuckles], honestly, admit to ourselves, even if it maybe was a bit embarrassing at the time where both Henry and I were like, "What? What is that? Like, what's Dora?" And we ended up looking into it and since then, have really become evangelists for the framework. And I'll pass it to Henry to talk about, like, what that journey has looked like.

+ +

HENRY: Thanks, Maxim. I think what's cool about DORA is in terms of using metrics, there's always this challenge called Goodhart's Law, right? So, whenever a metric becomes a target, the metric cease to be a good metric because people are going to find ways to game the metric. So, I think what's cool about DORA is that it actually offers not just one metric but four key metrics that bring balance to covering both the stability and velocity.

+ +

So, when you look at DORA metrics, you can't just optimize for velocity and sacrificing your stability. But you have to look at all four metrics at the same time, and that's harder to game. So, I think that's why it's become more and more popular in the industry as the starting point for using metrics for data-driven engineering.

+ +

VICTORIA: Yeah. And I like how DORA also represents it as the metrics and how they apply to where you are in the lifecycle of your product. So, I'm curious: with Merico, what kind of insights do you think engineering leaders can gain from having this data that will unlock some of their team's potential?

+ +

MAXIM: So, I think one of the most foundational things before we get into any detailed metrics is I think it's more important than ever, especially given that so many of us are remote, right? Where the general processes of software engineering are generally difficult to understand, right? They're nuanced. They tend to kind of happen in relative isolation until a PR is reviewed and merged. And it can be challenging, of course, to understand what's being done, how consistently, how well, like, where are the good parts, where are the bad parts. And I think that problem gets really exasperated, especially in a remote setting where no one is necessarily in the same place.

+ +

So, on a foundational level, I think we've really worked hard to solve that challenge, where just being able to see, like, how are we doing? And to that point, I think what we've found before anyone even dives too deep into all of the insights that we can deliver, I think there's a tremendous amount of appetite for anyone who's looking to get into that practice of constant improvement and figuring out how to level up the work they're doing, just setting close benchmarks, figuring out, like, okay, when we talk about more nebulous or maybe subjective terms like speed, or quality, what does good look like? What does consistent look like?

+ +

Being able to just tie those things to something that really kind of unifies the vocabulary is something I always like to say, where, okay, now, even if we're not focused on a specific metric, or we don't have a really particular goal in mind that we want to assess, now we're at least starting the conversation as a team from a place where when we talk about quality, we have something that's shared between us. We understand what we're referring to. And when we're talking about speed, we can also have something consistent to talk about there.

+ +

And within all of that, I think one of the most powerful things is it helps to really kind of ground the conversations around the trade-offs, right? There's always that common saying: the triangle of trade-offs is where it's, like, you can have it cheap; you can have it fast, and you can have it good, but you can only have two. And I think with DORA, with all of these different frameworks with many metrics, it helps to really solidify what those trade-offs look like. And that's, for me at least, been one of the most impactful things to watch: is our global users have really started evolving their practices with it.

+ +

HENRY: Yeah. And I want to add to Maxim's answer. But before that, I just want to quickly mention how our products are structured. So, Merico actually has an open-source component and a proprietary component. So, the open-source component is called Apache DevLake. It's an open-source project we created first within Merico and later on donated to Apache Software Foundation. And now, it's one of the most popular engineering metrics tool out there.

+ +

And then, on top of that, we built a SaaS offering called DevInsight Cloud, which is powered by Apache DevLake. So, with DevLake, the open-source project, you can set up your data connections, connect DevLake to all of the dev tools you're using, and then we collect data. And then we provide many different flavors of dashboards for our users.

+ +

And many of those dashboards are structured, and there are different questions engineering teams might want to ask. For example, like, how fast are we responding to our customer requirement? For that question, we will look at like, metrics like change lead time, or, like, for a question, how accurate is our planning for the sprint? In that case, the dashboard will show metrics relating to the percentage of issues we can deliver for every sprint for our plan. So, that's sort of, you know, based on the questions that the team wants to answer, we provide different dashboards that help them extract insights using the data from their DevOps tools.

+ +

JOE: It's really interesting you donated it to Apache. And I feel like the hybrid SaaS open-source model is really common. And I've become more and more skeptical of it over the years as companies start out open source, and then once they start getting competitors, they change the license. But by donating it to Apache, you sort of sidestep that potential trust issue.

+ +

MAXIM: Yeah, you've hit the nail on the head with that one because, in many ways, for us, engaging with Apache in the way that we have was, I think, ultimately born out of the observations we had about the shortcomings of other products in the space where, for one, very practical. We realized quickly that if we wanted to offer the most complete visibility possible, it would require connections to so many different products, right?

+ +

I think anyone can look at their engineering toolchain and identify perhaps 7, 9, 10 different things they're using on a day-to-day basis. Oftentimes, those aren't shared between companies, too. So, I think part one was just figuring out like, okay, how do we build a framework that makes it easy for developers to build a plugin and contribute to the project if there's something they want to incorporate that isn't already supported? And I think that was kind of part one.

+ +

Part two is, I think, much more important and far more profound, which is developer trust, right? Where we saw so many different products out there that claimed to deliver these insights but really had this kind of black-box approach, right? Where data goes in, something happens, insights come out. How's it doing that? How's it weighting things? What's it calculating? What variables are incorporated? All of that is a mystery. And that really leads to developers, rightfully, not having a basis to trust what's actually being shown to them.

+ +

So, for us, it was this perspective of what's the maximum amount of transparency that we could possibly offer? Well, open source is probably the best answer to that question. We made sure the entirety of the codebase is something they can take a look at, they can modify. They can dive into the underlying queries and algorithms and how everything is working to gain a total sense of trust in how is this thing working? And if I need to modify something to account for some nuanced details of how our team works, we can also do that.

+ +

And to your point, you know, I think it's definitely something I would agree with that one of the worst things we see in the open-source community is that companies will be kind of open source in name only, right? Where it's really more of marketing or kind of sales thing than anything, where it's like, oh, let's tap into the good faith of open source. But really, somehow or another, through bait and switch, through partial open source, through license changes, whatever it is, we're open source in name only but really, a proprietary, closed-source product.

+ +

So, for us, donating the core of DevLake to the Apache Foundation was essentially our way of really, like, putting, you know, walking the talk, right? Where no one can doubt at this point, like, oh, is this thing suddenly going to have the license changed? Is this suddenly going to go closed-source? Like, the answer to that now is a definitive no because it is now part of that ecosystem.

+ +

And I think with the aspirations we've had to build something that is not just a tool but, hopefully, long-term becomes, like, foundational technology, I think that gives people confidence and faith that this is something they can really invest in. They can really plumb into their processes in a deep and meaningful way with no concerns whatsoever that something is suddenly going to change that makes all of that work, you know, something that they didn't expect.

+ +

JOE: I think a lot of companies guard their source code like it's their secret sauce, but my experience has been more that it's the secret shame [laughs].

+ +

HENRY: [laughs]

+ +

MAXIM: There's no doubt in my role with, especially our open-source product driving our community we've really seen the magic of what a community-driven product can be. And open source, I think, is the most kind of a true expression of a community-driven product, where we have a Slack community with nearly 1,000 developers in it now. Naturally, right? Some of those developers are in there just to ask questions and answer questions. Some are intensely involved, right? They're suggesting improvements. They're suggesting new features. They're finding ways to refine things.

+ +

And it really is that, like, fantastic culture that I'm really proud that we've cultivated where best idea ships, right? If you've got a good idea, throw it into a GitHub issue or a comment. Let's see how the community responds to it. Let's see if someone wants to pick it up. Let's see if someone wants to submit a PR. If it's good, it goes into production, and then the entire community benefits. And, for me, that's something I've found endlessly exciting.

+ +

HENRY: Yeah. I think Joe made a really good point on the secret sauce part because I don't think the source code is our secret sauce. There's no rocket science in DevLake. If we break it down, it's really just some UI UX plus data pipelines. I think what's making DevLake successful is really the trust and collaboration that we're building with the open-source community. When it comes to trust, I think there are two aspects. First of all, trust on the metric accuracy, right? Because with a lot of proprietary software, you don't know how they are calculating the metrics. If people don't know how the metrics are calculated, they can't really trust it and use it.

+ +

And secondly, is the trust that they can always use this software, and there's no vendor lock-in. And when it comes to collaboration, we were seeing many of our data sources and dashboards they were contributed not by our core developers but by the community. And the communities really, you know, bring in their insights and their use cases into DevLake and make DevLake, you know, more successful and more applicable to more teams in different areas of soft engineering.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: I understand you've taken some innovative approaches on using AI in your open-source repositories to respond to issues and questions from your developers. So, can you tell me a little bit more about that?

+ +

HENRY: Absolutely. I self-identify as a builder. And one characteristic of builder is to always chase after the dream of building infinite things within the finite lifespan. So, I was always thinking about how we can be more productive, how we can, you know, get better at getting better. And so, this year, you know, AI is huge, and there are so many AI-powered tools that can help us achieve more in terms of delivering software.

+ +

And then, internally, we had a hackathon, and there's one project, which is an AI-powered coding assistant coming out of it called DevChat. And we have made it public at devchat.ai. But we've been closely following, you know, what are the other AI-powered tools that can make, you know, software developers' or open-source maintainers' lives easier? And we've been observing that there are more and more open-source projects adopting AI chatbots to help them handle, you know, respond to GitHub issues.

+ +

So, I recently did a case study on a pretty popular open-source project called LangChain. So, it's the hot kid right now in the AI space right now. And it's using a chatbot called Dosu to help respond to issues. I had some interesting findings from the case study.

+ +

VICTORIA: In what ways was that chatbot really helpful, and in what ways did it not really work that well?

+ +

HENRY: Yeah, I was thinking of how to measure the effectiveness of that chatbot. And I realized that there is a feature that's built in GitHub, which is the reaction to comment. So, how the chatbot works is whenever there is a new issue, the chatbot would basically retrieval-augmented generation pipeline and then using ORM to generate a response to the issue. And then there's people leave reactions to that comment by the chatbot, but mostly, it's thumbs up and thumbs down.

+ +

So, what I did is I collect all of the issues from the LangChain repository and look at how many thumbs up and thumbs down Dosu chatbot got, you know, from all of the comments they left with the issues. So, what I found is that over across 2,600 issues that Dosu chatbot helped with, it got around 900 thumbs ups and 1,300 thumbs down. So, then it comes to how do we interpret this data, right? Because it got more thumbs down than thumbs up doesn't mean that it's actually not useful or harmful to the developers.

+ +

So, to answer that question, I actually looked at some examples of thumbs-up and thumb-down comments. And what I found is the thumb down doesn't mean that the chatbot is harmful. It's mostly the developers are signaling to the open-source maintainers that your chatbot is not helping in this case, and we need human intervention. But with the thumbs up, the chatbot is actually helping a lot.

+ +

There's one issue where people post a question, and the chatbot just wrote the code and then basically made a suggestion on how to resolve the issue. And the human response is, "Damn, it worked." And that was very surprising to me, and it made me consider, you know, adopting similar technology and AI-powered tools for our own open-source project.

+ +

VICTORIA: That's very cool. Well, I want to go back to the beginning of Merico. And when you first got started, and you were trying to understand your customers and what they need, was there anything surprising in that early discovery process that made you change your strategy?

+ +

HENRY: So, one challenge we faced when we first explored open-source funding allocation problem space is that our algorithm looks at the Git repository. But with software engineering, especially with open-source collaboration, there are so many activities that are happening outside of open-source repos on GitHub. For example, I might be an evangelist, and my day-to-day work might be, you know, engaging in community work, talking about the open-source project conference. And all of those things were not captured by our algorithm, which was only looking at the GitHub repository at the time. So, that was one of the technical challenge that we faced and led us to switch over to more of the system-driven metrics side.

+ +

VICTORIA: Gotcha. Over the years, how has Merico grown? What has changed between when you first started and today?

+ +

HENRY: So, one thing is the team size. When we just got started, we only have, you know, the three co-founders and Maxim. And now we have grown to a team of 70 team members, and we have a fully distributed team across multiple continents. So, that's pretty interesting dynamics to handle. And we learned a lot of how to build effective team and a cohesive team along the way.

+ +

And in terms of product, DevLake now, you know, has more than 900 developers in our Slack community, and we track over 360 companies using DevLake. So, definitely, went a long way since we started the journey. And yeah, tomorrow we...actually, Maxim and I are going to host our end-of-year Apache DevLake Community Meetup and featuring Nathen Harvey, the Google's DORA team lead. Yeah, definitely made some progress since we've been working on Merico for four years.

+ +

VICTORIA: Well, that's exciting. Well, say hi to Nathen for me. I helped takeover DevOps DC with some of the other organizers that he was running way back in the day, so [laughs] that's great. What challenges do you see on the horizon for Merico and DevLake?

+ +

MAXIM: One of the challenges I think about a lot, and I think it's front of mind for many people, especially with software engineering, but at this point, nearly every profession, is what does AI mean for everything we're doing? What does the future look like where developers are maybe producing the majority of their code through prompt-based approaches versus code-based approaches, right? How do we start thinking about how we coherently assess that?

+ +

Like, how do you maybe redefine what the value is when there's a scenario where perhaps all coders, you know, if we maybe fast forward a few years, like, what if the AI is so good that the code is essentially perfect? What does success look like then? How do you start thinking about what is a good team if everyone is shooting out 9 out of 10 PRs nearly every time because they're all using a unified framework supported by AI? So, I think that's certainly kind of one of the challenges I envision in the future.

+ +

I think, really, practically, too, many startups have been contending with the macroclimate within the fundraising climates. You know, I think many of the companies out there, us included, had better conditions in 2019, 2020 to raise funds at more favorable valuations, perhaps more relaxed terms, given the climate of the public markets and, you know, monetary policy. I think that's, obviously, we're all experiencing and has tightened things up like revenue expectations or now higher kind of expectations on getting into a highly profitable place or, you know, the benchmark is set a lot higher there.

+ +

So, I think it's not a challenge that's unique to us in any way at all. I think it's true for almost every company that's out there. It's now kind of thinking in a more disciplined way about how do you kind of meet the market demands without compromising on the product vision and without compromising on the roadmap and the strategies that you've put in place that are working but are maybe coming under a little bit more pressure, given kind of the new set of rules that have been laid out for all of us?

+ +

VICTORIA: Yeah, that is going to be a challenge. And do you see the company and the product solving some of those challenges in a unique way?

+ +

HENRY: I've been thinking about how AI can fulfill the promise of making developers 10x developer. I'm an early adopter and big fan of GitHub Copilot. I think it really helps with writing, like, the boilerplate code. But I think it's improving maybe my productivity by 20% to 30%. It's still pretty far away from 10x. So, I'm thinking how Merico's solutions can help fill the gap a little bit.

+ +

In terms of Apache DevLake and its SaaS offering, I think we are helping with, like, the team collaboration and measuring, like, software delivery performance, how can the team improve as a whole. And then, recently, we had a spin-off, which is the AI-powered coding assistant DevChat. And that's sort of more on the empowering individual developers with, like, testing, refactoring these common workflows.

+ +

And one big thing for us in the future is how we can combine these two components, you know, team collaboration and improvement tool, DevLake, with the individual coding assistant, DevChat, how they can be integrated together to empower developers. I think that's the big question for Merico ahead.

+ +

JOE: Have you used Merico to judge the contributions of AI to a project?

+ +

HENRY: [laughs] So, actually, after we pivot to engineering metrics, we focus now less on individual contribution because that sometimes can be counterproductive. Because whenever you visualize that, then people will sometimes become defensive and try to optimize for the metrics that measure individual contributions. So, we sort of...nowadays, we no longer offer that kind of metrics within DevLake, if that makes sense.

+ +

MAXIM: And that kind of goes back to one of Victoria's earlier questions about, like, what surprised us in the journey. Early on, we had this very benevolent perspective, you know, I would want to kind of underline that, that we never sought to be judging individuals in a negative way. We were looking to find ways to make it useful, even to a point of finding ways...like, we explored different ways to give developers badges and different kind of accomplishment milestones, like, things to kind of signal their strengths and accomplishments.

+ +

But I think what we've found in that journey is that...and I would really kind of say this strongly. I think the only way that metrics of any kind serve an organization is when they support a healthy culture. And to that end, what we found is that we always like to preach, like, it's processes, not people. It's figuring out if you're hiring correctly, if you're making smart decisions about who's on the team. I think you have to operate with a default assumption within reason that those people are doing their best work. They're trying to move the company forward. They're trying to make good decisions to better serve the customers, better serve the company and the product.

+ +

With that in mind, what you're really looking to do is figure out what is happening within the underlying processes that get something from thought to production. And how do you clear the way for people? And I think that's really been a big kind of, you know, almost like a tectonic shift for our company over the years is really kind of fully transitioning to that. And I think, in some ways, DORA has represented kind of almost, like, a best practice for, like, processes over people, right?

+ +

It's figuring out between quality and speed; how are you doing? Where are those trade-offs? And then, within the processes that account for those outcomes, how can you really be improving things? So, I would say, for us, that's, like, been kind of the number one thing there is figuring out, like, how do we keep doubling down on processes, not people? And how do we really make sure that we're not just telling people that we're on their side and we're taking a, you know, a very humanistic perspective on wanting to improve the lives of people but actually doing it with the product?

+ +

HENRY: But putting the challenge on measuring individual contributions aside, I'm as curious as Joe about AI's role in software engineering. I expect to see more and more involvement of AI and gradually, you know, replacing low-level and medium-level and, in the future, even high-level tasks for humans so we can just focus on, like, the objective instead of the implementation.

+ +

VICTORIA: I can imagine, especially if you're starting to integrate AI tools into your systems and if you're growing your company at scale, some of the ability to have a natural intuition about what's going on it really becomes a challenge, and the data that you can derive from some of these products could help you make better decisions and all different types of things.

+ +

So, I'm kind of curious to hear from Joe; with your history of open-source contribution and being a part of many different development teams, what kind of information do you wish that you had to help you make decisions in your role?

+ +

JOE: Yeah, that's an interesting question. I've used some tools that try to identify problem spots in the code. But it'd be interesting to see the results of tools that analyze problem spots in the process. Like, I'd like to learn more about how that works.

+ +

HENRY: I'm curious; one question for Joe. What is your favorite non-AI-powered code scanning tool that you find useful for yourself or for your team?

+ +

JOE: I think the most common static analysis tool I use is something to find the Git churn in a repository. Some of this probably is because I've worked mostly on projects these days with dynamic languages. So, there's kind of a limit to how much static analysis you can do of, you know, a Ruby or a Python codebase. But just by analyzing which parts of the application changed the most, help you find which parts are likely to be the buggiest and the most complex.

+ +

I think every application tends to involve some central model. Like, if you're making an e-commerce site, then probably products are going to have a lot of the core logic, purchases will have a lot of the core logic. And identifying those centers of gravity just through the Git statistics has helped me find places that need to be reworked.

+ +

HENRY: That's really interesting. Is it something like a hotspot analysis? And when you find a hotspot, then would you invest more resources in, like, refactoring the hotspot to make it more maintainable?

+ +

JOE: Right, exactly. Like, you can use the statistics to see which files you should look at. And then, usually, when you actually go into the files, especially if you look at some of the changes to the files, it's pretty clear that it's become, you know, for example, a class has become too large, something has become too tightly coupled.

+ +

HENRY: Gotcha.

+ +

VICTORIA: Yeah. And so, if you could go back in time, five years ago and give yourself some advice when you first started along this journey, what advice would you give yourself?

+ +

MAXIM: I'll answer the question in two ways: first for the company and then for myself personally. I think for the company, what I would say is, especially when you're in that kind of pre-product market fit space, and you're maybe struggling to figure out how to solve a challenge that really matters, I think you need to really think carefully about, like, how would you yourself be using your product? And if you're finding reasons, you wouldn't, like, really, really pay careful attention to those.

+ +

And I think, for us, like, early on in our journey, we ultimately kind of found ourselves asking, we're like, okay, we're a smaller earlier stage team. Perhaps, like, small improvements in productivity or quality aren't going to necessarily move the needle. That's one of the reasons maybe we're not using this. Maybe our developers are already at bandwidth. So, it's not a question of unlocking more bandwidth or figuring out where there's kind of weak points or bottlenecks at that level, but maybe how can we dial in our own processes to let the whole team function more effectively.

+ +

And I think, for us, like, the more we started thinking through that lens of, like, what's useful to us, like, what's solving a pain point for us, I think, in many ways, DevLake was born out of that exact thinking. And now DevLake is used by hundreds of companies around the world and has, you know, this near thousand developer community that supports it. And I think that's testament to the power of that.

+ +

For me, personally, if I were to kind of go back five years, you know, I'm grateful to say there isn't a whole lot I would necessarily change. But I think if there's anything that I would, it would just to be consistently more brave in sharing ideas, right? I think Merico has done a great job, and it's something I'm so proud of for us as a team of really embracing new ideas and really kind of making sure, like, best idea ships, right? There isn't a title. There isn't a level of seniority that determines whether or not someone has a right to suggest something or improve something.

+ +

And I think with that in mind, for me as a technical person but not a member of technical staff, so to speak, I think there was many occasions, for me personally, where I felt like, okay, maybe because of that, I shouldn't necessarily weigh in on certain things. And I think what I've found, and it's a trust-building thing as well, is, like, even if you're wrong, even if your suggestion may be misunderstands something or isn't quite on target, there's still a tremendous amount of value in just being able to share a perspective and share a recommendation and push it out there.

+ +

And I think with that in mind, like, it's something I would encourage myself and encourage everybody else in a healthy company to feel comfortable to just keep sharing because, ultimately, it's an accuracy-by-volume game to a certain degree, right? Where if I come up with one idea, then I've got one swing at the bat. But if us as a collective come up with 100 ideas that we consider intelligently, we've got a much higher chance of maybe a handful of those really pushing us forward. So, for me, that would be advice I would give myself and to anybody else.

+ +

HENRY: I'll follow the same structure, so I'll start by the advice in terms of company and advice to myself as an individual. So, for a company level, I think my advice would be fail fast because every company needs to go through this exploration phase trying to find their product-market fit, and then they will have to test, you know, a couple of ideas before they find the right fit for themselves, the same for us. And I wish that we actually had more in terms of structure in exploring these ideas and set deadlines, you know, set milestones for us to quickly test and filter out bad ideas and then accelerate the exploration process. So, fail fast would be my suggestion at the company level.

+ +

From an individual level, I would say it's more adapting to my CTO role because when I started the company, I still had that, you know, graduate student hustle mindset. I love writing code myself. And it's okay if I spent 100% of my time writing code when the company was, you know, at five people, right? But it's not okay [chuckles] when we have, you know, a team of 40 engineers. So, I wish I had that realization earlier, and I transitioned to a real CTO role earlier, focusing more, like, on technical evangelism or building out the technical and non-technical infrastructure to help my engineering teams be successful.

+ +

VICTORIA: Well, I really appreciate that. And is there anything else that you all would like to promote today?

+ +

HENRY: So if you're, you know, engineering leaders who are looking to measure, you know, some metrics and adopt a more data-driven approach to improving your software delivery performance, check out Apache DevLake. It's open-source project, free to use, and it has some great dashboards, support, various data resources. And join our community. We have a pretty vibrant community on Slack. And there are a lot of developers and engineering leaders discussing how they can get more value out of data and metrics and improve software delivery performance.

+ +

MAXIM: Yeah. And I think to add to that, something I think we've found consistently is there's plenty of data skeptics out there, rightfully so. I think a lot of analytics of every kind are really not very good, right? And so, I think people are rightfully frustrated or even traumatized by them.

+ +

And for the data skeptics out there, I would invite them to dive into the DevLake community and pose your challenges, right? If you think this stuff doesn't make sense or you have concerns about it, come join the conversation because I think that's really where the most productive discussions end up coming from is not from people mutually high-fiving each other for a successful implementation of DORA.

+ +

But the really exciting moments come from the people in the community who are challenging it and saying like, "You know what? Like, here's where I don't necessarily think something is useful or I think could be improved." And it's something that's not up to us as individuals to either bless or to deny. That's where the community gets really exciting is those discussions. So, I would say, if you're a data skeptic, come and dive in, and so long as you're respectful, challenge it. And by doing so, you'll hopefully not only help yourself but really help everybody, which is what I love about this stuff so much.

+ +

JOE: I'm curious, does Merico use Merico?

+ +

HENRY: Yes. We've been dogfooding ourself a lot. And a lot of the product improvement ideas actually come from our own dogfooding process. For example, there was one time that we look at a dashboard that has this issue change lead time. And then we found our issue, change lead time, you know, went up in the past few month. And then, we were trying to interpret whether that's a good thing or a bad thing because just looking at a single metric doesn't tell us the story behind the change in the metrics. So, we actually improved the dashboard to include some, you know, covariates of the metrics, some other related metrics to help explain the trend of the metric. So yeah, dogfooding is always useful in improving product.

+ +

VICTORIA: That's great. Well, thank you all so much for joining. I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode of the "Giant Robots Smashing Into Other Giant Robots" podcast, host Victoria Guido delves into the intersection of technology, product development, and personal passions with her guests Henry Yin, Co-Founder and CTO of Merico, and Maxim Wheatley, the company's first employee and Community Leader. They are joined by Joe Ferris, CTO of thoughtbot, as a special guest co-host. The conversation begins with a casual exchange about rock climbing, revealing that both Henry and Victoria share this hobby, which provides a unique perspective on their professional roles in software development.

+ +

Throughout the podcast, Henry and Maxim discuss the journey and evolution of Merico, a company specializing in data-driven tools for developers. They explore the early stages of Merico, highlighting the challenges and surprises encountered while seeking product-market fit and the strategic pivot from focusing on open-source funding allocation to developing a comprehensive engineering metric platform. This shift in focus led to the creation of Apache DevLake, an open-source project contributed to by Merico and later donated to the Apache Software Foundation, reflecting the company's commitment to transparency and community-driven development.

+ +

The episode also touches on future challenges and opportunities in the field of software engineering, particularly the integration of AI and machine learning tools in the development process. Henry and Maxim emphasize the potential of AI to enhance developer productivity and the importance of data-driven insights in improving team collaboration and software delivery performance. Joe contributes to the discussion with his own experiences and perspectives, particularly on the importance of process over individual metrics in team management.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Henry Yin, Co-Founder and CTO of Merico, and Maxim Wheatley, the first employee and Community Leader of Merico, creating data-driven developer tools for forward-thinking devs. Thank you for joining us.

+ +

HENRY: Thanks for having us.

+ +

MAXIM: Glad to be here, Victoria. Thank you.

+ +

VICTORIA: And we also have a special guest co-host today, the CTO of thoughtbot, Joe Ferris.

+ +

JOE: Hello.

+ +

VICTORIA: Okay. All right. So, I met Henry and Maxim at the 7CTOs Conference in San Diego back in November. And I understand that Henry, you are also an avid rock climber.

+ +

HENRY: Yes. I know you were also in Vegas during Thanksgiving. And I sort of have [inaudible 00:49] of a tradition to go to Vegas every Thanksgiving to Red Rock National Park. Yeah, I'd love to know more about how was your trip to Vegas this Thanksgiving.

+ +

VICTORIA: Yes. I got to go to Vegas as well. We had a bit of rain, actually. So, we try not to climb on sandstone after the rain and ended up doing some sport climbing on limestone around the Blue Diamond Valley area; a little bit light on climbing for me, actually, but still beautiful out there. I loved being in Red Rock Canyon outside of Las Vegas.

+ +

And I do find that there's just a lot of developers and engineers who have an affinity for climbing. I'm not sure what exactly that connection is. But I know, Joe, you also have a little bit of climbing and mountaineering experience, right?

+ +

JOE: Yeah. I used to climb a good deal. I actually went climbing for the first time in, like, three years this past weekend, and it was truly pathetic. But you have to [laughs] start somewhere.

+ +

VICTORIA: That's right. And, Henry, how long have you been climbing for?

+ +

HENRY: For about five years. I like to spend my time in nature when I'm not working: hiking, climbing, skiing, scuba diving, all of the good outdoor activities.

+ +

VICTORIA: That's great. And I understand you were bouldering in Vegas, right? Did you go to Kraft Boulders?

+ +

HENRY: Yeah, we went to Kraft also Red Spring. It was a surprise for me. I was able to upgrade my outdoor bouldering grade to B7 this year at Red Spring and Monkey Wrench. There was always some surprises for me. When I went to Red Rock National Park last year, I met Alex Honnold there who was shooting a documentary, and he was really, really friendly. So, really enjoying every Thanksgiving trip to Vegas.

+ +

VICTORIA: That's awesome. Yeah, well, congratulations on B7. That's great. It's always good to get a new grade. And I'm kind of in the same boat with Joe, where I'm just constantly restarting my climbing career. So [laughs], I haven't had a chance to push a grade like that in a little while. But that sounds like a lot of fun.

+ +

HENRY: Yeah, it's really hard to be consistent on climbing when you have, like, a full-time job, and then there's so much going on in life. It's always a challenge.

+ +

VICTORIA: Yeah. But a great way to like, connect with other people, and make friends, and spend time outdoors. So, I still really appreciate it, even if I'm not maybe progressing as much as I could be. That's wonderful. So, tell me, how did you and Maxim actually meet? Did you meet through climbing or the outdoors?

+ +

MAXIM: We actually met through AngelList, which I really recommend to anyone who's really looking to get into startups. When Henry and I met, Merico was essentially just starting. I had this eagerness to explore something really early stage where I'd get to do all of the interesting kind of cross-functional things that come with that territory, touching on product and marketing, on fundraising, kind of being a bit of everything. And I was eager to look into something that was applying, you know, machine learning, data analytics in some really practical way.

+ +

And I came across what Hezheng Henry and the team were doing in terms of just extracting useful insights from codebases. And we ended up connecting really well. And I think the previous experience I had was a good fit for the team, and the rest was history. And we've had a great time building together for the last five years.

+ +

VICTORIA: Yeah. And tell me a little bit more about your background and what you've been bringing to the Merico team.

+ +

MAXIM: I think, like a lot of people in startups, consider myself a member of the Island of Misfit Toys in the sense that no kind of clear-cut linear pathway through my journey but a really exciting and productive one nonetheless. So, I began studying neuroscience at Georgetown University in Washington, D.C. I was about to go to medical school and, in my high school years had explored entrepreneurship in a really basic way. I think, like many people do, finding ways to monetize my hobbies and really kind of getting infected with that bug that I could create something, make money from it, and kind of be the master of my own destiny, for lack of less cliché terms.

+ +

So, not long after graduating, I started my first job that recruited me into a seed-stage venture capital, and from there, I had the opportunity to help early-stage startups, invest in them. I was managing a startup accelerator out there. From there, produced a documentary that followed those startups. Not long after all of that, I ended up co-founding a consumer electronics company where I was leading product, so doing lots of mechanical, electrical, and a bit of software engineering.

+ +

And without taking too long, those were certainly kind of two of the more formative things. But one way or another, I've spent my whole career now in startups and, especially early-stage ones. It was something I was eager to do was kind of take some of the high-level abstract science that I had learned in my undergraduate and kind of apply some of those frameworks to some of the things that I do today.

+ +

VICTORIA: That's super interesting. And now I'm curious about you, Henry, and your background. And what led you to get the idea for Merico?

+ +

HENRY: Yeah. My professional career is actually much simpler because Merico was my first company and my first job. Before Merico, I was a PhD student at UC Berkeley studying computer science. My research was an intersection of software engineering and machine learning. And back then, we were tackling this research problem of how do we fairly measure the developer contributions in a software project?

+ +

And the reason we are interested in this project has to do with the open-source funding problem. So, let's say an open-source project gets 100k donations from Google. How does the maintainers can automatically distribute all of the donations to sometimes hundreds or thousands of contributors according to their varying level of contributions? So, that was the problem we were interested in. We did research on this for about a year. We published a paper. And later on, you know, we started the company with my, you know, co-authors. And that's how the story began for Merico.

+ +

VICTORIA: I really love that. And maybe you could tell me just a little bit more about what Merico is and why a company may be interested in trying out your services.

+ +

HENRY: The product we're currently offering actually is a little bit different from what we set out to build. At the very beginning, we were building this platform for open-source funding problem that we can give an open-source project. We can automatically, using algorithm, measure developer contributions and automatically distribute donations to all developers. But then we encountered some technical and business challenges.

+ +

So, we took out the metrics component from the previous idea and launched this new product in the engineering metric space. And this time, we focus on helping engineering leaders better understand the health of their engineering work. So, this is the Merico analytics platform that we're currently offering to software engineering teams.

+ +

JOE: It's interesting. I've seen some products that try to judge the health of a codebase, but it sounds like this is more trying to judge the health of the team.

+ +

MAXIM: Yeah, I think that's generally fair to say. As we've evolved, we've certainly liked to describe ourselves as, you know, I think a lot of people are familiar with observability tools, which help ultimately ascertain, like, the performance of the technology, right? Like, it's assessing, visualizing, chopping up the machine-generated data. And we thought there would be a tremendous amount of value in being, essentially, observability for the human-generated data.

+ +

And I think, ultimately, what we found on our journey is that there's a tremendous amount of frustration, especially in larger teams, not in looking to use a tool like that for any kind of, like, policing type thing, right? Like, no one's looking if they're doing it right, at least looking to figure out, like, oh, who's underperforming, or who do we need to yell at? But really trying to figure out, like, where are the strengths? Like, how can we improve our processes? How can we make sure we're delivering better software more reliably, more sustainably? Like how are we balancing that trade-off between new features, upgrades and managing tech debt and bugs?

+ +

We've ultimately just worked tirelessly to, hopefully, fill in those blind spots for people. And so far, I'm pleased to say that the reception has been really positive. We've, I think, tapped into a somewhat subtle but nonetheless really important pain point for a lot of teams around the world.

+ +

VICTORIA: Yeah. And, Henry, you said that you started it based on some of the research that you did at UC Berkeley. I also understand you leaned on the research from the DevOps research from DORA. Can you tell me a little bit more about that and what you found insightful from the research that was out there and already existed?

+ +

MAXIM: So, I think what's really funny, and it really speaks to, I think, the importance in product development of just getting out there and speaking with your potential users or actual users, and despite all of the deep, deep research we had done on the topic of understanding engineering, we really hadn't touched on DORA too much. And this is probably going back about five years now.

+ +

Henry and I were taking a customer meeting with an engineering leader at Yahoo out in the Bay Area. He kind of revealed this to us basically where he's like, "Oh, you guys should really look at incorporating DORA into this thing. Like, all of the metrics, all of the analytics you're building super cool, super interesting, but DORA really has this great framework, and you guys should look into it."

+ +

And in hindsight, I think we can now [chuckles], honestly, admit to ourselves, even if it maybe was a bit embarrassing at the time where both Henry and I were like, "What? What is that? Like, what's Dora?" And we ended up looking into it and since then, have really become evangelists for the framework. And I'll pass it to Henry to talk about, like, what that journey has looked like.

+ +

HENRY: Thanks, Maxim. I think what's cool about DORA is in terms of using metrics, there's always this challenge called Goodhart's Law, right? So, whenever a metric becomes a target, the metric cease to be a good metric because people are going to find ways to game the metric. So, I think what's cool about DORA is that it actually offers not just one metric but four key metrics that bring balance to covering both the stability and velocity.

+ +

So, when you look at DORA metrics, you can't just optimize for velocity and sacrificing your stability. But you have to look at all four metrics at the same time, and that's harder to game. So, I think that's why it's become more and more popular in the industry as the starting point for using metrics for data-driven engineering.

+ +

VICTORIA: Yeah. And I like how DORA also represents it as the metrics and how they apply to where you are in the lifecycle of your product. So, I'm curious: with Merico, what kind of insights do you think engineering leaders can gain from having this data that will unlock some of their team's potential?

+ +

MAXIM: So, I think one of the most foundational things before we get into any detailed metrics is I think it's more important than ever, especially given that so many of us are remote, right? Where the general processes of software engineering are generally difficult to understand, right? They're nuanced. They tend to kind of happen in relative isolation until a PR is reviewed and merged. And it can be challenging, of course, to understand what's being done, how consistently, how well, like, where are the good parts, where are the bad parts. And I think that problem gets really exasperated, especially in a remote setting where no one is necessarily in the same place.

+ +

So, on a foundational level, I think we've really worked hard to solve that challenge, where just being able to see, like, how are we doing? And to that point, I think what we've found before anyone even dives too deep into all of the insights that we can deliver, I think there's a tremendous amount of appetite for anyone who's looking to get into that practice of constant improvement and figuring out how to level up the work they're doing, just setting close benchmarks, figuring out, like, okay, when we talk about more nebulous or maybe subjective terms like speed, or quality, what does good look like? What does consistent look like?

+ +

Being able to just tie those things to something that really kind of unifies the vocabulary is something I always like to say, where, okay, now, even if we're not focused on a specific metric, or we don't have a really particular goal in mind that we want to assess, now we're at least starting the conversation as a team from a place where when we talk about quality, we have something that's shared between us. We understand what we're referring to. And when we're talking about speed, we can also have something consistent to talk about there.

+ +

And within all of that, I think one of the most powerful things is it helps to really kind of ground the conversations around the trade-offs, right? There's always that common saying: the triangle of trade-offs is where it's, like, you can have it cheap; you can have it fast, and you can have it good, but you can only have two. And I think with DORA, with all of these different frameworks with many metrics, it helps to really solidify what those trade-offs look like. And that's, for me at least, been one of the most impactful things to watch: is our global users have really started evolving their practices with it.

+ +

HENRY: Yeah. And I want to add to Maxim's answer. But before that, I just want to quickly mention how our products are structured. So, Merico actually has an open-source component and a proprietary component. So, the open-source component is called Apache DevLake. It's an open-source project we created first within Merico and later on donated to Apache Software Foundation. And now, it's one of the most popular engineering metrics tool out there.

+ +

And then, on top of that, we built a SaaS offering called DevInsight Cloud, which is powered by Apache DevLake. So, with DevLake, the open-source project, you can set up your data connections, connect DevLake to all of the dev tools you're using, and then we collect data. And then we provide many different flavors of dashboards for our users.

+ +

And many of those dashboards are structured, and there are different questions engineering teams might want to ask. For example, like, how fast are we responding to our customer requirement? For that question, we will look at like, metrics like change lead time, or, like, for a question, how accurate is our planning for the sprint? In that case, the dashboard will show metrics relating to the percentage of issues we can deliver for every sprint for our plan. So, that's sort of, you know, based on the questions that the team wants to answer, we provide different dashboards that help them extract insights using the data from their DevOps tools.

+ +

JOE: It's really interesting you donated it to Apache. And I feel like the hybrid SaaS open-source model is really common. And I've become more and more skeptical of it over the years as companies start out open source, and then once they start getting competitors, they change the license. But by donating it to Apache, you sort of sidestep that potential trust issue.

+ +

MAXIM: Yeah, you've hit the nail on the head with that one because, in many ways, for us, engaging with Apache in the way that we have was, I think, ultimately born out of the observations we had about the shortcomings of other products in the space where, for one, very practical. We realized quickly that if we wanted to offer the most complete visibility possible, it would require connections to so many different products, right?

+ +

I think anyone can look at their engineering toolchain and identify perhaps 7, 9, 10 different things they're using on a day-to-day basis. Oftentimes, those aren't shared between companies, too. So, I think part one was just figuring out like, okay, how do we build a framework that makes it easy for developers to build a plugin and contribute to the project if there's something they want to incorporate that isn't already supported? And I think that was kind of part one.

+ +

Part two is, I think, much more important and far more profound, which is developer trust, right? Where we saw so many different products out there that claimed to deliver these insights but really had this kind of black-box approach, right? Where data goes in, something happens, insights come out. How's it doing that? How's it weighting things? What's it calculating? What variables are incorporated? All of that is a mystery. And that really leads to developers, rightfully, not having a basis to trust what's actually being shown to them.

+ +

So, for us, it was this perspective of what's the maximum amount of transparency that we could possibly offer? Well, open source is probably the best answer to that question. We made sure the entirety of the codebase is something they can take a look at, they can modify. They can dive into the underlying queries and algorithms and how everything is working to gain a total sense of trust in how is this thing working? And if I need to modify something to account for some nuanced details of how our team works, we can also do that.

+ +

And to your point, you know, I think it's definitely something I would agree with that one of the worst things we see in the open-source community is that companies will be kind of open source in name only, right? Where it's really more of marketing or kind of sales thing than anything, where it's like, oh, let's tap into the good faith of open source. But really, somehow or another, through bait and switch, through partial open source, through license changes, whatever it is, we're open source in name only but really, a proprietary, closed-source product.

+ +

So, for us, donating the core of DevLake to the Apache Foundation was essentially our way of really, like, putting, you know, walking the talk, right? Where no one can doubt at this point, like, oh, is this thing suddenly going to have the license changed? Is this suddenly going to go closed-source? Like, the answer to that now is a definitive no because it is now part of that ecosystem.

+ +

And I think with the aspirations we've had to build something that is not just a tool but, hopefully, long-term becomes, like, foundational technology, I think that gives people confidence and faith that this is something they can really invest in. They can really plumb into their processes in a deep and meaningful way with no concerns whatsoever that something is suddenly going to change that makes all of that work, you know, something that they didn't expect.

+ +

JOE: I think a lot of companies guard their source code like it's their secret sauce, but my experience has been more that it's the secret shame [laughs].

+ +

HENRY: [laughs]

+ +

MAXIM: There's no doubt in my role with, especially our open-source product driving our community we've really seen the magic of what a community-driven product can be. And open source, I think, is the most kind of a true expression of a community-driven product, where we have a Slack community with nearly 1,000 developers in it now. Naturally, right? Some of those developers are in there just to ask questions and answer questions. Some are intensely involved, right? They're suggesting improvements. They're suggesting new features. They're finding ways to refine things.

+ +

And it really is that, like, fantastic culture that I'm really proud that we've cultivated where best idea ships, right? If you've got a good idea, throw it into a GitHub issue or a comment. Let's see how the community responds to it. Let's see if someone wants to pick it up. Let's see if someone wants to submit a PR. If it's good, it goes into production, and then the entire community benefits. And, for me, that's something I've found endlessly exciting.

+ +

HENRY: Yeah. I think Joe made a really good point on the secret sauce part because I don't think the source code is our secret sauce. There's no rocket science in DevLake. If we break it down, it's really just some UI UX plus data pipelines. I think what's making DevLake successful is really the trust and collaboration that we're building with the open-source community. When it comes to trust, I think there are two aspects. First of all, trust on the metric accuracy, right? Because with a lot of proprietary software, you don't know how they are calculating the metrics. If people don't know how the metrics are calculated, they can't really trust it and use it.

+ +

And secondly, is the trust that they can always use this software, and there's no vendor lock-in. And when it comes to collaboration, we were seeing many of our data sources and dashboards they were contributed not by our core developers but by the community. And the communities really, you know, bring in their insights and their use cases into DevLake and make DevLake, you know, more successful and more applicable to more teams in different areas of soft engineering.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: I understand you've taken some innovative approaches on using AI in your open-source repositories to respond to issues and questions from your developers. So, can you tell me a little bit more about that?

+ +

HENRY: Absolutely. I self-identify as a builder. And one characteristic of builder is to always chase after the dream of building infinite things within the finite lifespan. So, I was always thinking about how we can be more productive, how we can, you know, get better at getting better. And so, this year, you know, AI is huge, and there are so many AI-powered tools that can help us achieve more in terms of delivering software.

+ +

And then, internally, we had a hackathon, and there's one project, which is an AI-powered coding assistant coming out of it called DevChat. And we have made it public at devchat.ai. But we've been closely following, you know, what are the other AI-powered tools that can make, you know, software developers' or open-source maintainers' lives easier? And we've been observing that there are more and more open-source projects adopting AI chatbots to help them handle, you know, respond to GitHub issues.

+ +

So, I recently did a case study on a pretty popular open-source project called LangChain. So, it's the hot kid right now in the AI space right now. And it's using a chatbot called Dosu to help respond to issues. I had some interesting findings from the case study.

+ +

VICTORIA: In what ways was that chatbot really helpful, and in what ways did it not really work that well?

+ +

HENRY: Yeah, I was thinking of how to measure the effectiveness of that chatbot. And I realized that there is a feature that's built in GitHub, which is the reaction to comment. So, how the chatbot works is whenever there is a new issue, the chatbot would basically retrieval-augmented generation pipeline and then using ORM to generate a response to the issue. And then there's people leave reactions to that comment by the chatbot, but mostly, it's thumbs up and thumbs down.

+ +

So, what I did is I collect all of the issues from the LangChain repository and look at how many thumbs up and thumbs down Dosu chatbot got, you know, from all of the comments they left with the issues. So, what I found is that over across 2,600 issues that Dosu chatbot helped with, it got around 900 thumbs ups and 1,300 thumbs down. So, then it comes to how do we interpret this data, right? Because it got more thumbs down than thumbs up doesn't mean that it's actually not useful or harmful to the developers.

+ +

So, to answer that question, I actually looked at some examples of thumbs-up and thumb-down comments. And what I found is the thumb down doesn't mean that the chatbot is harmful. It's mostly the developers are signaling to the open-source maintainers that your chatbot is not helping in this case, and we need human intervention. But with the thumbs up, the chatbot is actually helping a lot.

+ +

There's one issue where people post a question, and the chatbot just wrote the code and then basically made a suggestion on how to resolve the issue. And the human response is, "Damn, it worked." And that was very surprising to me, and it made me consider, you know, adopting similar technology and AI-powered tools for our own open-source project.

+ +

VICTORIA: That's very cool. Well, I want to go back to the beginning of Merico. And when you first got started, and you were trying to understand your customers and what they need, was there anything surprising in that early discovery process that made you change your strategy?

+ +

HENRY: So, one challenge we faced when we first explored open-source funding allocation problem space is that our algorithm looks at the Git repository. But with software engineering, especially with open-source collaboration, there are so many activities that are happening outside of open-source repos on GitHub. For example, I might be an evangelist, and my day-to-day work might be, you know, engaging in community work, talking about the open-source project conference. And all of those things were not captured by our algorithm, which was only looking at the GitHub repository at the time. So, that was one of the technical challenge that we faced and led us to switch over to more of the system-driven metrics side.

+ +

VICTORIA: Gotcha. Over the years, how has Merico grown? What has changed between when you first started and today?

+ +

HENRY: So, one thing is the team size. When we just got started, we only have, you know, the three co-founders and Maxim. And now we have grown to a team of 70 team members, and we have a fully distributed team across multiple continents. So, that's pretty interesting dynamics to handle. And we learned a lot of how to build effective team and a cohesive team along the way.

+ +

And in terms of product, DevLake now, you know, has more than 900 developers in our Slack community, and we track over 360 companies using DevLake. So, definitely, went a long way since we started the journey. And yeah, tomorrow we...actually, Maxim and I are going to host our end-of-year Apache DevLake Community Meetup and featuring Nathen Harvey, the Google's DORA team lead. Yeah, definitely made some progress since we've been working on Merico for four years.

+ +

VICTORIA: Well, that's exciting. Well, say hi to Nathen for me. I helped takeover DevOps DC with some of the other organizers that he was running way back in the day, so [laughs] that's great. What challenges do you see on the horizon for Merico and DevLake?

+ +

MAXIM: One of the challenges I think about a lot, and I think it's front of mind for many people, especially with software engineering, but at this point, nearly every profession, is what does AI mean for everything we're doing? What does the future look like where developers are maybe producing the majority of their code through prompt-based approaches versus code-based approaches, right? How do we start thinking about how we coherently assess that?

+ +

Like, how do you maybe redefine what the value is when there's a scenario where perhaps all coders, you know, if we maybe fast forward a few years, like, what if the AI is so good that the code is essentially perfect? What does success look like then? How do you start thinking about what is a good team if everyone is shooting out 9 out of 10 PRs nearly every time because they're all using a unified framework supported by AI? So, I think that's certainly kind of one of the challenges I envision in the future.

+ +

I think, really, practically, too, many startups have been contending with the macroclimate within the fundraising climates. You know, I think many of the companies out there, us included, had better conditions in 2019, 2020 to raise funds at more favorable valuations, perhaps more relaxed terms, given the climate of the public markets and, you know, monetary policy. I think that's, obviously, we're all experiencing and has tightened things up like revenue expectations or now higher kind of expectations on getting into a highly profitable place or, you know, the benchmark is set a lot higher there.

+ +

So, I think it's not a challenge that's unique to us in any way at all. I think it's true for almost every company that's out there. It's now kind of thinking in a more disciplined way about how do you kind of meet the market demands without compromising on the product vision and without compromising on the roadmap and the strategies that you've put in place that are working but are maybe coming under a little bit more pressure, given kind of the new set of rules that have been laid out for all of us?

+ +

VICTORIA: Yeah, that is going to be a challenge. And do you see the company and the product solving some of those challenges in a unique way?

+ +

HENRY: I've been thinking about how AI can fulfill the promise of making developers 10x developer. I'm an early adopter and big fan of GitHub Copilot. I think it really helps with writing, like, the boilerplate code. But I think it's improving maybe my productivity by 20% to 30%. It's still pretty far away from 10x. So, I'm thinking how Merico's solutions can help fill the gap a little bit.

+ +

In terms of Apache DevLake and its SaaS offering, I think we are helping with, like, the team collaboration and measuring, like, software delivery performance, how can the team improve as a whole. And then, recently, we had a spin-off, which is the AI-powered coding assistant DevChat. And that's sort of more on the empowering individual developers with, like, testing, refactoring these common workflows.

+ +

And one big thing for us in the future is how we can combine these two components, you know, team collaboration and improvement tool, DevLake, with the individual coding assistant, DevChat, how they can be integrated together to empower developers. I think that's the big question for Merico ahead.

+ +

JOE: Have you used Merico to judge the contributions of AI to a project?

+ +

HENRY: [laughs] So, actually, after we pivot to engineering metrics, we focus now less on individual contribution because that sometimes can be counterproductive. Because whenever you visualize that, then people will sometimes become defensive and try to optimize for the metrics that measure individual contributions. So, we sort of...nowadays, we no longer offer that kind of metrics within DevLake, if that makes sense.

+ +

MAXIM: And that kind of goes back to one of Victoria's earlier questions about, like, what surprised us in the journey. Early on, we had this very benevolent perspective, you know, I would want to kind of underline that, that we never sought to be judging individuals in a negative way. We were looking to find ways to make it useful, even to a point of finding ways...like, we explored different ways to give developers badges and different kind of accomplishment milestones, like, things to kind of signal their strengths and accomplishments.

+ +

But I think what we've found in that journey is that...and I would really kind of say this strongly. I think the only way that metrics of any kind serve an organization is when they support a healthy culture. And to that end, what we found is that we always like to preach, like, it's processes, not people. It's figuring out if you're hiring correctly, if you're making smart decisions about who's on the team. I think you have to operate with a default assumption within reason that those people are doing their best work. They're trying to move the company forward. They're trying to make good decisions to better serve the customers, better serve the company and the product.

+ +

With that in mind, what you're really looking to do is figure out what is happening within the underlying processes that get something from thought to production. And how do you clear the way for people? And I think that's really been a big kind of, you know, almost like a tectonic shift for our company over the years is really kind of fully transitioning to that. And I think, in some ways, DORA has represented kind of almost, like, a best practice for, like, processes over people, right?

+ +

It's figuring out between quality and speed; how are you doing? Where are those trade-offs? And then, within the processes that account for those outcomes, how can you really be improving things? So, I would say, for us, that's, like, been kind of the number one thing there is figuring out, like, how do we keep doubling down on processes, not people? And how do we really make sure that we're not just telling people that we're on their side and we're taking a, you know, a very humanistic perspective on wanting to improve the lives of people but actually doing it with the product?

+ +

HENRY: But putting the challenge on measuring individual contributions aside, I'm as curious as Joe about AI's role in software engineering. I expect to see more and more involvement of AI and gradually, you know, replacing low-level and medium-level and, in the future, even high-level tasks for humans so we can just focus on, like, the objective instead of the implementation.

+ +

VICTORIA: I can imagine, especially if you're starting to integrate AI tools into your systems and if you're growing your company at scale, some of the ability to have a natural intuition about what's going on it really becomes a challenge, and the data that you can derive from some of these products could help you make better decisions and all different types of things.

+ +

So, I'm kind of curious to hear from Joe; with your history of open-source contribution and being a part of many different development teams, what kind of information do you wish that you had to help you make decisions in your role?

+ +

JOE: Yeah, that's an interesting question. I've used some tools that try to identify problem spots in the code. But it'd be interesting to see the results of tools that analyze problem spots in the process. Like, I'd like to learn more about how that works.

+ +

HENRY: I'm curious; one question for Joe. What is your favorite non-AI-powered code scanning tool that you find useful for yourself or for your team?

+ +

JOE: I think the most common static analysis tool I use is something to find the Git churn in a repository. Some of this probably is because I've worked mostly on projects these days with dynamic languages. So, there's kind of a limit to how much static analysis you can do of, you know, a Ruby or a Python codebase. But just by analyzing which parts of the application changed the most, help you find which parts are likely to be the buggiest and the most complex.

+ +

I think every application tends to involve some central model. Like, if you're making an e-commerce site, then probably products are going to have a lot of the core logic, purchases will have a lot of the core logic. And identifying those centers of gravity just through the Git statistics has helped me find places that need to be reworked.

+ +

HENRY: That's really interesting. Is it something like a hotspot analysis? And when you find a hotspot, then would you invest more resources in, like, refactoring the hotspot to make it more maintainable?

+ +

JOE: Right, exactly. Like, you can use the statistics to see which files you should look at. And then, usually, when you actually go into the files, especially if you look at some of the changes to the files, it's pretty clear that it's become, you know, for example, a class has become too large, something has become too tightly coupled.

+ +

HENRY: Gotcha.

+ +

VICTORIA: Yeah. And so, if you could go back in time, five years ago and give yourself some advice when you first started along this journey, what advice would you give yourself?

+ +

MAXIM: I'll answer the question in two ways: first for the company and then for myself personally. I think for the company, what I would say is, especially when you're in that kind of pre-product market fit space, and you're maybe struggling to figure out how to solve a challenge that really matters, I think you need to really think carefully about, like, how would you yourself be using your product? And if you're finding reasons, you wouldn't, like, really, really pay careful attention to those.

+ +

And I think, for us, like, early on in our journey, we ultimately kind of found ourselves asking, we're like, okay, we're a smaller earlier stage team. Perhaps, like, small improvements in productivity or quality aren't going to necessarily move the needle. That's one of the reasons maybe we're not using this. Maybe our developers are already at bandwidth. So, it's not a question of unlocking more bandwidth or figuring out where there's kind of weak points or bottlenecks at that level, but maybe how can we dial in our own processes to let the whole team function more effectively.

+ +

And I think, for us, like, the more we started thinking through that lens of, like, what's useful to us, like, what's solving a pain point for us, I think, in many ways, DevLake was born out of that exact thinking. And now DevLake is used by hundreds of companies around the world and has, you know, this near thousand developer community that supports it. And I think that's testament to the power of that.

+ +

For me, personally, if I were to kind of go back five years, you know, I'm grateful to say there isn't a whole lot I would necessarily change. But I think if there's anything that I would, it would just to be consistently more brave in sharing ideas, right? I think Merico has done a great job, and it's something I'm so proud of for us as a team of really embracing new ideas and really kind of making sure, like, best idea ships, right? There isn't a title. There isn't a level of seniority that determines whether or not someone has a right to suggest something or improve something.

+ +

And I think with that in mind, for me as a technical person but not a member of technical staff, so to speak, I think there was many occasions, for me personally, where I felt like, okay, maybe because of that, I shouldn't necessarily weigh in on certain things. And I think what I've found, and it's a trust-building thing as well, is, like, even if you're wrong, even if your suggestion may be misunderstands something or isn't quite on target, there's still a tremendous amount of value in just being able to share a perspective and share a recommendation and push it out there.

+ +

And I think with that in mind, like, it's something I would encourage myself and encourage everybody else in a healthy company to feel comfortable to just keep sharing because, ultimately, it's an accuracy-by-volume game to a certain degree, right? Where if I come up with one idea, then I've got one swing at the bat. But if us as a collective come up with 100 ideas that we consider intelligently, we've got a much higher chance of maybe a handful of those really pushing us forward. So, for me, that would be advice I would give myself and to anybody else.

+ +

HENRY: I'll follow the same structure, so I'll start by the advice in terms of company and advice to myself as an individual. So, for a company level, I think my advice would be fail fast because every company needs to go through this exploration phase trying to find their product-market fit, and then they will have to test, you know, a couple of ideas before they find the right fit for themselves, the same for us. And I wish that we actually had more in terms of structure in exploring these ideas and set deadlines, you know, set milestones for us to quickly test and filter out bad ideas and then accelerate the exploration process. So, fail fast would be my suggestion at the company level.

+ +

From an individual level, I would say it's more adapting to my CTO role because when I started the company, I still had that, you know, graduate student hustle mindset. I love writing code myself. And it's okay if I spent 100% of my time writing code when the company was, you know, at five people, right? But it's not okay [chuckles] when we have, you know, a team of 40 engineers. So, I wish I had that realization earlier, and I transitioned to a real CTO role earlier, focusing more, like, on technical evangelism or building out the technical and non-technical infrastructure to help my engineering teams be successful.

+ +

VICTORIA: Well, I really appreciate that. And is there anything else that you all would like to promote today?

+ +

HENRY: So if you're, you know, engineering leaders who are looking to measure, you know, some metrics and adopt a more data-driven approach to improving your software delivery performance, check out Apache DevLake. It's open-source project, free to use, and it has some great dashboards, support, various data resources. And join our community. We have a pretty vibrant community on Slack. And there are a lot of developers and engineering leaders discussing how they can get more value out of data and metrics and improve software delivery performance.

+ +

MAXIM: Yeah. And I think to add to that, something I think we've found consistently is there's plenty of data skeptics out there, rightfully so. I think a lot of analytics of every kind are really not very good, right? And so, I think people are rightfully frustrated or even traumatized by them.

+ +

And for the data skeptics out there, I would invite them to dive into the DevLake community and pose your challenges, right? If you think this stuff doesn't make sense or you have concerns about it, come join the conversation because I think that's really where the most productive discussions end up coming from is not from people mutually high-fiving each other for a successful implementation of DORA.

+ +

But the really exciting moments come from the people in the community who are challenging it and saying like, "You know what? Like, here's where I don't necessarily think something is useful or I think could be improved." And it's something that's not up to us as individuals to either bless or to deny. That's where the community gets really exciting is those discussions. So, I would say, if you're a data skeptic, come and dive in, and so long as you're respectful, challenge it. And by doing so, you'll hopefully not only help yourself but really help everybody, which is what I love about this stuff so much.

+ +

JOE: I'm curious, does Merico use Merico?

+ +

HENRY: Yes. We've been dogfooding ourself a lot. And a lot of the product improvement ideas actually come from our own dogfooding process. For example, there was one time that we look at a dashboard that has this issue change lead time. And then we found our issue, change lead time, you know, went up in the past few month. And then, we were trying to interpret whether that's a good thing or a bad thing because just looking at a single metric doesn't tell us the story behind the change in the metrics. So, we actually improved the dashboard to include some, you know, covariates of the metrics, some other related metrics to help explain the trend of the metric. So yeah, dogfooding is always useful in improving product.

+ +

VICTORIA: That's great. Well, thank you all so much for joining. I really enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YX9mddvI + + ]]> + + Victoria Guido + + + thoughtbot's Incubator Program Mini Season 3 - Episode 06: Goodz with Mike Rosenthal and Chris Cerrito + https://podcast.thoughtbot.com/s3e6incubatorgoodz + 53db0bee-026e-46d0-a53d-d5e72fd7bdc3 + Tue, 09 Jan 2024 00:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + Mike Rosenthal and Chris Cirrito discuss the progress of Goodz, focusing on the recent intense weeks they've had. Goodz, a startup merging the digital and physical worlds of music, has stayed on course with its initial concept. Mike details their approach to Thanksgiving and the launch of their e-commerce experiment. He shares insights from recent user interviews, which have influenced their approach and understanding of their target audience. + +When the discussion turns to the challenges of launching and maintaining their e-commerce platform, Mike and Chris talk about learning from analytics, marketing strategies, and the importance of understanding consumer behavior. They discuss the challenges in balancing short-term and long-term goals, and the upcoming fundraising efforts. + 26:27 + no + + + If you missed the first and second episodes with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can listen to the first episode (https://podcast.thoughtbot.com/s3e2incubatorgoodz) and the second episode (https://podcast.thoughtbot.com/s3e4incubatorgoodz) to catch up! +Lindsey Christensen, head of marketing at thoughtbot is joined by Mike Rosenthal and Chris Cerrito, co-founders of the startup Goodz, and Danny Kim, Senior Product Manager at thoughtbot. +Mike and Chris discuss the progress of Goodz, focusing on the recent intense weeks they've had. Goodz, a startup merging the digital and physical worlds of music, has stayed on course with its initial concept. Mike details their approach to Thanksgiving and the launch of their e-commerce experiment. He shares insights from recent user interviews, which have influenced their approach and understanding of their target audience. +When the discussion turns to the challenges of launching and maintaining their e-commerce platform, Mike and Chris talk about learning from analytics, marketing strategies, and the importance of understanding consumer behavior. They discuss the challenges in balancing short-term and long-term goals, and the upcoming fundraising efforts. +Transcript: +LINDSEY: Thanks for being here. My name's Lindsey. I head up marketing at thoughtbot. If you haven't joined one of these before, we are checking in with two of the founders who are going through the thoughtbot Startup Incubator to learn how it's going, what's new, what challenges they're hitting, and what they're learning along the way. +If you're not familiar with thoughtbot, we're a product design and development consultancy, and we hope your team and your product become a success. And one way we do that is through our startup incubator. +So, today, we are joined by our co-founders, Mike Rosenthal and Chris Cerrito, Co-Founders of the startup Goodz. And we also have another special guest today, Danny Kim, from the thoughtbot side, Senior Product Manager at thoughtbot. So, I think, to start off, we'll head over to the new face, the new voice that we've got with us today. Danny, tell us a little bit about your role at thoughtbot and, specifically, the incubator. +DANNY: Yeah, sure. First of all, thanks for having me on, and thanks for letting me join in on all the fun. I'm one of the product managers at thoughtbot. I typically work for the Lift-Off team. We usually work with companies that are looking to, like, go into market with their first version MVP. They might have a product that exists and that they're already kind of doing well with, and they kind of want to jump into a new segment. We'll typically work with companies like that to kind of get them kicked off the ground. +But it's been really awesome being part of the incubator program. It's my first time in helping with the market validation side. Definitely also, like, learning a lot from this experience [laughs] for myself. Coming at it specifically from a PM perspective, there's, like, so much variation usually in product management across the industry, depending on, like, what stage of the product that you're working in. And so, I'm definitely feeling my fair share of impostor syndrome here. +But it's been really fun to stretch my brand and, like, approach problems from, like, a completely different perspective and also using different tools. But, you know, working with Mike and Chris makes it so much easier because they really make it feel like you're part of their team, and so that definitely goes a long way. +LINDSEY: It just goes to show everyone gets impostor syndrome sometimes [laughter], even senior product managers at thoughtbot [laughter]. Thanks for that intro. It's, you know, the thoughtbot team learns along the way, too, you know, especially if usually you're focused on a different stage of product development. +Mike, it's been only three weeks or a very long three weeks since last we checked in with you, kind of forever in startup time. So, I think the last time, we were just getting to know you two. And you were walking us through the concept, this merging of the digital and physical world of music, and how we interact with music keepsakes or merchandise. How's my pitch? +MIKE: Good. Great. You're killing it. +[laughter] +LINDSEY: And has anything major changed to that concept in the last three weeks? +MIKE: No. I mean, I can't believe it's only been three weeks. It feels like it's been a long time since we last talked. It's been an intense three weeks, for sure. No, it's been going really well. I mean, we launched all sorts of stuff. I'm trying to think of anything that's sort of fundamentally changed in terms of the plan itself or kind of our, yeah, what we've been working on. And I think we've pretty much stayed the course to sort of get to where we are now. But it's been really intensive. +I think also having sort of Thanksgiving in there, and we were kind of pushing to get something live right before the Thanksgiving break. And so, that week just felt, I mean, I was just dead by, you know, like, Thursday of Thanksgiving. I think we all were. So, it's been intense, I would say, is the short answer. And I'm happy, yeah, to get into kind of where things are at. But big picture, it's been an intense three weeks. +LINDSEY: That's cool. And when we talked, you were, you know, definitely getting into research and user interviews. Have those influenced any, you know, changes along the way in the plan? +MIKE: Yeah. They've been really helpful. You know, we'd never really done that before in any of the sort of past projects that we've worked on together. And so, I think just being able to, you know, read through some of those scripts and then sit through some of the interviews and just kind of hearing people's honest assessment of some things has been really interesting. I'm trying to think if it's materially affected anything. +I guess, you know, at first, we were, like, we kind of had some assumptions around, okay, let's try to find, like...adult gift-givers sounds like the wrong thing, adults who give gifts as, like, a persona. The idea that, like, you know, maybe you gift your siblings gifts, and then maybe this could be a good gift idea. And I think, you know, we had a hard time kind of finding people to talk in an interesting way about that. And I think we've kind of realized it's kind of a hard persona to kind of chop up and talk about, right, Chris? I don't know [crosstalk 04:55] +CHRIS: Well, it also seemed to, from my understanding of it, it seemed to, like, genuinely stress out the people who were being interviewed... +MIKE: [laughs] +CHRIS: Because it's kind of about a stressful topic [inaudible 05:03], you know, and, like, especially -- +LINDSEY: Why? [laughs] +CHRIS: Well, I think, I don't know, now I'm making assumptions. Maybe because we're close to the holiday season, and that's a topic in the back of everybody's mind. But yeah, Danny, would you disagree with that? Those folks, from what we heard, seemed like they were the most difficult to kind of extract answers from. But then, if the subject changed and we treated them as a different persona, several of those interviews proved to be quite fruitful. So, it's just really interesting. +DANNY: Yeah. It really started, like, you kind of try to get some answers out of people, and there's, like, some level of people trying to please you to some extent. That's just, like, naturally, how it starts. And you just, like, keep trying to drill into the answers. And you just keep asking people like, "So, what kind of gifts do you give?" And they're just like, "Oh my goodness, like, I haven't thought about buying gifts for my sister in [laughs], like, you know, in forever. And now, like [laughs], I don't know where to go." And they get, like, pretty stressed out about it. +But then we just kind of started shifting into like, "All right, cool, never mind about that. Like, do you like listening to music?" And they're like, "Yes." And then it just kind of explodes from there. And they're like, "This last concert that I went to..." and all of this stuff. And it was much more fruitful kind of leaning more towards that, actually, yeah. +LINDSEY: That's fascinating. I guess that speaks to, especially at this stage and the speed and the amount of interviews you're doing, the need for being, like, really agile in those interviews, and then, like, really quickly applying what you're learning to making the next one even more valuable. +MIKE: Yeah. And I think, you know, like, we launched just a little sort of website experiment or, like, an e-commerce experiment right before Thanksgiving. And I think now, you know, we're able to sort of take some of those learnings from those interviews and apply them to both sort of our ad copy itself but also just different landing pages in different language on the different kind of versions of the site and see if we can find some resonance with some of these audience groups. So, it's been interesting. +LINDSEY: Are you still trying to figure out who that early adopter audience is, who that niche persona is? +MIKE: I think we -- +CHRIS: Yes, we are. I think we have a good idea of who it is. And I think right now we're just trying to figure out really how to reach those people. That, I think, is the biggest challenge right now for us. +MIKE: Yeah. With the e-commerce experiment it was sort of a very specific niche thing that is a little bit adjacent to what I think we want to be doing longer term with Goodz. And so, it's weird. It's like, we're in a place we're like, oh, we really want to find the people that want this thing. But also, this thing isn't necessarily the thing that we think we're going to make longer term, so let's not worry too hard about finding them. You know what I mean? It's been an interesting sort of back and forth with that. +CHRIS: From the interviews that we conducted, you know, we identified three key personas. Most of them have come up, but I'll just relist them. There's the sibling gift giver. There was the merch buyers; these are people who go to concerts and buy merchandise, you know, T-shirts, albums, records, things along those lines to support the artists that they love. And then the final one that was identified we gave the title of the 'Proud Playlister'. And these are people who are really into their digital media platforms, love making playlists, and love sharing those playlists with their friends. +And that, I would say, the proud playlister is really the one that we have focused on in terms of the storefront that we launched, like, the product is pretty much specifically for them. But the lessons that we're learning while making this product and trying to get this into the hands of the proud playlisters will feed into kind of the merch buyers. +MIKE: Yeah. And I think that, you know, it's funny, like, this week is kind of a poignant week for this, right? Because it's the week that Spotify Wrapped launched, right? So, it's like, in the course of any given year, it's probably, like, the one week of the year that lots and lots and lots of people are thinking about playlists all of a sudden, so trying a little bit to see if we can ride that wave or just kind of dovetail with that a bit, too. +LINDSEY: Absolutely. And do you want to give just, like, the really quick reminder of what the product experience is like? +MIKE: Oh yeah [laughs], good call. +CHRIS: This is a prototype of it. It's called the Goodz Mixtape. Basically, the idea is that you purchase one of these from us. You give us a playlist URL. We program that URL onto the NFC chip that's embedded in the Good itself. And then when you scan this Good, that playlist will come up. So, it's a really great way of you make a playlist for somebody, and you want to gift it to them; this is a great way to do that. You have a special playlist, maybe between you and a friend or you and a partner. This is a good way to commemorate that playlist, turn it into a physical thing, give that digital file value and presence in the physical world. +LINDSEY: Great. Okay, so you casually mentioned this launch of an e-commerce store that happened last week. +MIKE: It didn't feel casual. +LINDSEY: Yeah. Why [laughter]...[inaudible 09:45] real casual. Why did you launch it? How's it going? +MIKE: I don't know. Why did we launch it? I mean, well, we wanted to be able to test some assumptions. I think, you know, we wanted to get the brand out there a little bit, get our website out there, kind of introduce the concept. You know, this is a very...not that we've invented this product category, but it is a pretty obscure product category, right? And so, there's a lot of sort of consumer education that I think that has to go on for people to wrap their heads around this and why they'd want this. +So, I think we wanted to start that process a little bit correctly, sort of in advance of a larger launch next year, and see if we could find some early community around this. You know, if we can find those core people who just absolutely love this, and connect with it, and go wild around it, then those are the people that we're going to be able to get a ton of information from and build for that persona, right? It's like, cool, these are the people who love this. Let's build more for them and go find other people like this. So, I think, for us, it was that. +And then, honestly, it was also just, you know, let's test our manufacturing and fulfillment and logistics capabilities, right? I mean, this is...as much as we are a B2B, you know, SaaS platform or that's what we envision the future of Goodz being, there is a physical component of this. And, you know, we do have that part basically done at this point. But we just, you know, what is it like to order 1,000 of these? +What is it like to put these in the mail to people and, you know, actually take orders? And just some of that processing because we do envision a more wholesale future where we're doing, you know, thousands or tens of thousands of this at a time. And so, I think we just want to button up and do some dry runs before we get to those kinds of numbers. +CHRIS: I think it also it's important to remember that we are talking in startup time. And while this last week seems like an eternity, it's been a week [laughs] that we've had this in place. So, we're just starting to learn these things, and we plan on continuing to do so. +MIKE: Yeah. But I think we thought that getting a website up would be a good way to just start kind of testing everything more. +LINDSEY: Great. Danny, what went into deciding what would be in this first version of the site and the e-commerce offering? +DANNY: I mean, a lot of it was kind of mostly driven by Chris and Mike. They kind of had a vision and an idea of what they wanted to sell. Obviously, from the user interviews, we were starting to hone in a little bit more and, like, we had some assumptions going into it. I think we ultimately did kind of feel like, yeah, I think, like, the playlisters seem to be, like, the target market. But just hearing it more and hearing more excitement from them was definitely just kind of like, yeah, I think we can double down on this piece. +But, ultimately, like, in terms of launching the e-commerce platform, and the storefront, and the website, like, just literally looking at the user journey and being like, how does a user get from getting onto a site, like, as soon as they land there to, like, finishing a purchase? And what points do they need? What are the key things that they need to think through and typically will run into? And a lot of it is just kind of reflecting on our own personal buyer behavior. +And, also, as we were getting closer to the launch, starting to work through some of those assumptions about buyer behavior. As we got there, we obviously had some prototypes. We had some screenshots that we were already working with. Like, the design team was already starting to build out some of the site. And so, we would just kind of show it to them, show it to our users, and just be like, hey, like, how do you expect to purchase this? Like, what's the next step that you expect to take? And we'd just kind of, like, continue to iterate on that piece. And so... +LINDSEY: Okay. So you were, before launching, even showing some of those mockups and starting to incorporate them in the user interviews. +DANNY: Yeah, yeah. I mean, we tried to get it in there in front of them as early as possible, partially because, like, at some point in the user interviews, like, you're mostly just trying to first understand, like, who are our target customers? Who are these people? And we have an assumption of or an idea of who we think they are. But really, like, once you start talking to people, you kind of are, like, okay, like, this thing that I thought maybe it wasn't so accurate, or, like, the way that they're kind of talking about these products doesn't 100% match what I originally walked into this, you know, experiment with. And so, we, like, start to hone in on that. +But after a certain point, you kind of get that idea and now you're just like, okay, you seem to be, like, the right person to talk to. And so, if I were to show you this thing, do you get it, right? Like, do you understand what's happening? Like, how to use this thing, what this product even does. And then also, like, does the checkout experience feel intuitive for you? Is it as simple as, like, I just want to buy a T-shirt? So, like, I'm just going to go by the T-shirt, pick a size, and, you know, move on with my life. Can we make it as seamless as that? +LINDSEY: And so, you mentioned it's only been a week since it's been live. Have you been able to learn anything from it yet? And how are you trying to drive people to it today? +MIKE: Yeah, I think we learned that sales is hard [laughs] and slow, and it takes some time. But it's good, and we're learning a lot. I mean, it's been a while since I've really dug deep in, like, the analytics and marketing kind of metrics. And so, we've got all the Google Tag Manager stuff, you know, hooked up and just, you know, connecting with just exploring, honestly, like the TikTok advertising platform, and the YouTube Pre-Rolls, and Shorts. And, like, a lot of stuff that I actually, since the last time I was heavily involved in this stuff, is just totally new and different. +And so, it's been super interesting to see the funnel and sort of see where people are getting in the site, where people are dropping off. You know, we had an interesting conversation in our thoughtbot sync yesterday or the day before, where we were seeing how, you know, we're getting lots of people to the front page and, actually, a good number of people to the product page, and, actually, like, you know, not the worst number of people to the cart. But then you were seeing really high cart abandonment rates. +And then, you know, when you start Googling, and you're like, oh, actually, everybody sees very high cart abandonment rates; that's just a thing. But we were seeing, like, the people were viewing their cart seven or eight times, and they were on there sort of five times as long as they were on any other page. And it's this problem that I think Danny is talking about where, you know, we need to actually get a playlist URL. This gets into the minutiae of what we're building, but basically like, we need to get them to give us a playlist URL in order to check out, right? +And so, you sort of have to, like, put yourself back in the mind of someone who's scrolling on Instagram, and they see this as an ad, and they click it, and they're like, oh, that thing was cool. Sure, I will buy one of those. And then it's like, no, actually, you need to, you know, leave this, go into a different app, find a play...like, it suddenly just puts a lot of the mental strain. But it's a lot. It's a cognitive load, greater than, as you said, just buying a T-shirt and telling what size you want. +So, thinking through ways to really trim that down, shore up the amount of time people are spending on a cart. All that stuff has been fascinating. And then just, like, the different demographic kind of work that we're using, all the social ads platforms to kind of identify has been really interesting. It's still early. +But, actually, like, Chris and I were just noticing...we were just talking right before this call. Like, we're actually starting to get, just in the last 12 hours, a bunch more, a bunch, but more people signing up to our email newsletter, probably in the last 12 hours that we have in the whole of last week. Yeah, I don't know, just even that sort of learning, it's like, oh, do people just need time with a thing, or they come back and they think about it? +CHRIS: Yeah. Could these people be working on their playlists? That's a question that I have. +MIKE: [chuckles] Yeah, me too. +CHRIS: It's like, you know, I'm making a playlist to drop into this product. It's really interesting. And I think it gives insight to kind of, you know, how personal this product could be, that this is something that takes effort on the part of the consumer because they're making something to give or to keep for themselves, which is, I think, really interesting but definitely hard, too. +DANNY: Yeah. And I also want to also clarify, like, Chris just kind of said it, like, especially for viewers and listeners, like, that's something that we've been hearing a lot from user interviews, too, right? Like, the language that they're using is, like, this is a thing that I care about. Like it's a representation of who I am. It's a representation of, like, the relationship that I have with this person that I'm going to be giving, you know, this gift to or this playlist to, specifically, like, people who feel, like, really passionate about these things. And, I mean, like, I did, too. +Like, when I was first trying to, like, date, my wife, like, I spent, like, hours, hours trying to pick the coolest songs that I thought, you know, were like, oh, like, she's going to think I'm so cool because, like, I listen to these, like, super low-key indie rock bands, and, like, you know, so many more hours than she probably spent listening to it. But that's [laughs] kind of, like, honestly, what we heard a lot in a lot of these interviews, so... +LINDSEY: Yeah, same. No, totally resonates. And I also went to the site this week, and I was like, oh damn, this is cool. Like, and immediately it was like, oh, you know, I've got these three, you know, music friends that we go to shows together. I'm like, oh, this would be so cool to get them, you know, playlists of, like, music we've seen together. So, you might see me in the cart. I won't abandon it. +MIKE: Please. I would love that. +CHRIS: Don't think about it too long if you could -- [laughter]. +LINDSEY: I won't. I won't. +CHRIS: I mean, I would say I'm really excited about having the site not only as a vehicle for selling some of these things but also as a vehicle for just honing our message. It's like another tool that we have in our arsenal. During the user interviews themselves, we were talking in abstract terms, and now we have something concrete that we can bounce off people, which is, I think, going to be a huge boon to our toolset as we continue to refine and define this product. +MIKE: Yeah, that's a good point. +LINDSEY: Yeah. You mentioned that they're signing up for, like, email updates. Do you have something you're sending out? Or are you kind of just creating a list? Totally fine, just building a list. +MIKE: [laughs] No. +CHRIS: It's a picture of Mike and I giving a big thumbs up. That's, yeah. [laughter] +MIKE: No. But maybe...that was the thing; I was like, oh great, they're signing up. And I was like, gosh, they're signing up. Okay [laughter], now we got to write something. But we will. +LINDSEY: Tips to making your playlist [crosstalk 19:11] playing your playlist -- +MIKE: Yeah [crosstalk 19:13]. +CHRIS: Right. And then also...tips to making your playlists. Also, we're advancing on the collectible side of things, too. We are, hopefully, going to have two pilot programs in place, one with a major label and one with a major artist. And we're really excited about that. +LINDSEY: Okay. That's cool. I assume you can't tell us very much. What can you tell us? +MIKE: Yeah. We won't mention names [chuckles] in case it just goes away, as these things sometimes do. But yeah, there's a great band who's super excited about these, been around for a long time, some good name recognition, and a very loyal fan base. They want to do sort of a collection of these. I think maybe we showed the little...I can't remember if we showed the little crates that we make or not, but basically, [inaudible 19:52] +LINDSEY: The last time, yeah. +MIKE: So, they want to sell online a package that's, you know, five or six Goodz in a crate, which I think will be cool and a great sort of sales experiment. And then there's a couple of artists that we're going to do an experiment with that's through their label that's more about tour...basically, giving things away on tour. So, they're going to do some giveaway fan club street team-style experiments with some of these on the road. +So, first, it's ideal, provided both those things happen, because we definitely want to be exploring on the road and online stuff. And so, this kind of lets us do both at once and get some real learnings as to kind of how people...because we still don't know. We haven't really put these in people's hands yet. And it's just, like, are people scanning these a lot? Are they not? Is this sort of an object that's sitting on their shelf? Is it...yeah, it's just, like, there's so much we're going to learn once we get these into people's hands. +LINDSEY: Do you have the infrastructure to sort of see how many times the cards are scanned? +CHRIS: Mm-hmm. Yep, we do. +MIKE: Yeah. So, we can see how many times each one is scanned, where they're scanned, that sort of thing. +CHRIS: Kind of our next step, and something we were just talking about today with the thoughtbot team, is building out kind of what the backend will be for this, both for users and also for labels and artists. That it will allow them to go in and post updates to the Goodz, to allow them to use these for promotion as people, you know, scan into them to give them links to other sites related to the artists that they might be interested in before they move on to the actual musical playlist. So, that's kind of the next step for us. And knowing how users use these collectibles, both the kind of consumer Good and the artist collectibles that we were just talking about, will help inform how we build that platform. +LINDSEY: Very cool. And right now, the online store itself that's built in Shopify? +MIKE: Yeah. The homepage is Webflow that Kevin from the thoughtbot team really spearheaded in building for us. And then, yeah, the e-commerce is Shopify. +LINDSEY: Y'all have been busy. +MIKE: [laughs] +LINDSEY: Is there anything else maybe that I haven't asked about yet that we should touch on in terms of updates or things going on with the product? +MIKE: I don't know. I don't think so. I think, like Chris said, I mean, we're just...like, now that the site has kind of stood up and we're really switched over to kind of marketing and advertising on that, definitely digging into the backend of this kind of SaaS platform that's going to probably be a big focus for the rest of the, you know, the program, to be honest. Yeah, just some other things we can do on the next front that could eventually build into the backend that I think can be interesting. No, I guess [laughs] the short answer is no, nothing, like, substantial. Those are the big [crosstalk 22:26] +LINDSEY: Yeah. Well, that was my next question, too, which is kind of like, what's next, or what's the next chunk of work? So, it's obviously lots more optimization and learning on the e-commerce platform, and then this other mega area, which is, you know, what does this look like as a SaaS solution? What's the vision? But also, where do we start? Which I'm sure, Danny, is a lot of work that you specialize in as far as, like, scoping how to approach these kinds of projects. +DANNY: Yeah. And it's interesting because, I mean, we were just talking about this today. Like, part of it is, like, we can, like, really dig into, like, the e-commerce site and, like, really nailing it down to get it to the place where it's like, we're driving tons more traffic and also getting as low of a, like, cart abandonment rate as possible, right? But also, considering the fact that this is in the future, like, large-scale vision. +And there's, like, also, like, we're starting to, I think, now iron out a lot of those, like, milestones where we're kind of like, okay, like, we got, like, a short-term vision, which is, like, the e-commerce site. We got a mid-term vision and a potential long-term vision. How do we validate this long-term vision while also still like, keeping this short-term vision moving forward? +And, like, this mid-term vision is also going to, like, help potentially, either, like, steer us towards that long-term or maybe even, like, pivot us, like, into a completely different direction. So, like, where do you put your card, right? Like, how much energy and time do we put into, like, each of these areas? And that's kind of, like, the interesting part of this is starting to talk through that, starting to kind of prioritize, like, how we can maximize on our effort, like, our development and design effort so that things just kind of line up more naturally and organically for our future visioning, so... +MIKE: Yeah. A lot of different things to juggle. I saw there was a question. Somebody asked what the URL is, but I don't seem to be able to [crosstalk 24:10]. +LINDSEY: The same question as me. We got to drop the link for this thing. +MIKE: Yeah, getthegoodz.com. +CHRIS: That's G-O-O-D-Z. +LINDSEY: Get in there, folks +MIKE: Yeah, get [crosstalk 24:23]. +LINDSEY: And let us know how it goes. +MIKE: Yeah, please [laughs]. Any bugs? Let us know. Yeah. I think that those...yeah, I mean, it's a good point, Danny, in terms of juggling kind of the near-term and longer-term stuff. You know, it's a good kind of reminder our big focus, you know, in the new year is going to be fundraising, right? We're already talking to some investors and things like that. +So, it's like, okay, yes, as you said, we could tweak the cart. We could tweak the e-commerce. Or, like, can we paint the big picture of what the longer-term version of this company is going to be in a way that makes it compelling for investment to come in so that there can be a long-term version of this company? And then we can build those things. So yeah, it's definitely a balance between the two. +LINDSEY: Oh, also, just casual fundraising as well. +[crosstalk 25:06] +MIKE: Yeah, yeah. +LINDSEY: [laughs] +MIKE: But it's hard. It's like, you wake up in the morning. It's like, do I want to, like, write cold emails to investors? Or do I want to, like, look at Google Analytics and, like, tweak ad copy? That's actually more fun. So, yes. +LINDSEY: Yeah, life of the founder, for sure. All right. So, that's getthegoodz (Goodz with a z) .com. Check it out. We'll tune in and see what happens with the e-commerce site, what happens with the SaaS planning the next time that we check in. +But Chris, Mike, Danny, thank you so much for joining today and sharing what's been going on over the last few weeks: the good, the bad, the challenge, the cart abandonment. And, you know, best of luck to you over the next few weeks, and we'll be sure to check in and see how it's going. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Chris Cerrito, Joe Ferris, Jordyn Bonds, and Mike Rosenthal. + + + If you missed the first and second episodes with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can listen to the first episode and the second episode to catch up!

+ +
+ +

Lindsey Christensen, head of marketing at thoughtbot is joined by Mike Rosenthal and Chris Cerrito, co-founders of the startup Goodz, and Danny Kim, Senior Product Manager at thoughtbot.

+ +

Mike and Chris discuss the progress of Goodz, focusing on the recent intense weeks they've had. Goodz, a startup merging the digital and physical worlds of music, has stayed on course with its initial concept. Mike details their approach to Thanksgiving and the launch of their e-commerce experiment. He shares insights from recent user interviews, which have influenced their approach and understanding of their target audience.

+ +

When the discussion turns to the challenges of launching and maintaining their e-commerce platform, Mike and Chris talk about learning from analytics, marketing strategies, and the importance of understanding consumer behavior. They discuss the challenges in balancing short-term and long-term goals, and the upcoming fundraising efforts.

+ +

Transcript:

+ +

LINDSEY: Thanks for being here. My name's Lindsey. I head up marketing at thoughtbot. If you haven't joined one of these before, we are checking in with two of the founders who are going through the thoughtbot Startup Incubator to learn how it's going, what's new, what challenges they're hitting, and what they're learning along the way.

+ +

If you're not familiar with thoughtbot, we're a product design and development consultancy, and we hope your team and your product become a success. And one way we do that is through our startup incubator.

+ +

So, today, we are joined by our co-founders, Mike Rosenthal and Chris Cerrito, Co-Founders of the startup Goodz. And we also have another special guest today, Danny Kim, from the thoughtbot side, Senior Product Manager at thoughtbot. So, I think, to start off, we'll head over to the new face, the new voice that we've got with us today. Danny, tell us a little bit about your role at thoughtbot and, specifically, the incubator.

+ +

DANNY: Yeah, sure. First of all, thanks for having me on, and thanks for letting me join in on all the fun. I'm one of the product managers at thoughtbot. I typically work for the Lift-Off team. We usually work with companies that are looking to, like, go into market with their first version MVP. They might have a product that exists and that they're already kind of doing well with, and they kind of want to jump into a new segment. We'll typically work with companies like that to kind of get them kicked off the ground.

+ +

But it's been really awesome being part of the incubator program. It's my first time in helping with the market validation side. Definitely also, like, learning a lot from this experience [laughs] for myself. Coming at it specifically from a PM perspective, there's, like, so much variation usually in product management across the industry, depending on, like, what stage of the product that you're working in. And so, I'm definitely feeling my fair share of impostor syndrome here.

+ +

But it's been really fun to stretch my brand and, like, approach problems from, like, a completely different perspective and also using different tools. But, you know, working with Mike and Chris makes it so much easier because they really make it feel like you're part of their team, and so that definitely goes a long way.

+ +

LINDSEY: It just goes to show everyone gets impostor syndrome sometimes [laughter], even senior product managers at thoughtbot [laughter]. Thanks for that intro. It's, you know, the thoughtbot team learns along the way, too, you know, especially if usually you're focused on a different stage of product development.

+ +

Mike, it's been only three weeks or a very long three weeks since last we checked in with you, kind of forever in startup time. So, I think the last time, we were just getting to know you two. And you were walking us through the concept, this merging of the digital and physical world of music, and how we interact with music keepsakes or merchandise. How's my pitch?

+ +

MIKE: Good. Great. You're killing it.

+ +

[laughter]

+ +

LINDSEY: And has anything major changed to that concept in the last three weeks?

+ +

MIKE: No. I mean, I can't believe it's only been three weeks. It feels like it's been a long time since we last talked. It's been an intense three weeks, for sure. No, it's been going really well. I mean, we launched all sorts of stuff. I'm trying to think of anything that's sort of fundamentally changed in terms of the plan itself or kind of our, yeah, what we've been working on. And I think we've pretty much stayed the course to sort of get to where we are now. But it's been really intensive.

+ +

I think also having sort of Thanksgiving in there, and we were kind of pushing to get something live right before the Thanksgiving break. And so, that week just felt, I mean, I was just dead by, you know, like, Thursday of Thanksgiving. I think we all were. So, it's been intense, I would say, is the short answer. And I'm happy, yeah, to get into kind of where things are at. But big picture, it's been an intense three weeks.

+ +

LINDSEY: That's cool. And when we talked, you were, you know, definitely getting into research and user interviews. Have those influenced any, you know, changes along the way in the plan?

+ +

MIKE: Yeah. They've been really helpful. You know, we'd never really done that before in any of the sort of past projects that we've worked on together. And so, I think just being able to, you know, read through some of those scripts and then sit through some of the interviews and just kind of hearing people's honest assessment of some things has been really interesting. I'm trying to think if it's materially affected anything.

+ +

I guess, you know, at first, we were, like, we kind of had some assumptions around, okay, let's try to find, like...adult gift-givers sounds like the wrong thing, adults who give gifts as, like, a persona. The idea that, like, you know, maybe you gift your siblings gifts, and then maybe this could be a good gift idea. And I think, you know, we had a hard time kind of finding people to talk in an interesting way about that. And I think we've kind of realized it's kind of a hard persona to kind of chop up and talk about, right, Chris? I don't know [crosstalk 04:55]

+ +

CHRIS: Well, it also seemed to, from my understanding of it, it seemed to, like, genuinely stress out the people who were being interviewed...

+ +

MIKE: [laughs]

+ +

CHRIS: Because it's kind of about a stressful topic [inaudible 05:03], you know, and, like, especially --

+ +

LINDSEY: Why? [laughs]

+ +

CHRIS: Well, I think, I don't know, now I'm making assumptions. Maybe because we're close to the holiday season, and that's a topic in the back of everybody's mind. But yeah, Danny, would you disagree with that? Those folks, from what we heard, seemed like they were the most difficult to kind of extract answers from. But then, if the subject changed and we treated them as a different persona, several of those interviews proved to be quite fruitful. So, it's just really interesting.

+ +

DANNY: Yeah. It really started, like, you kind of try to get some answers out of people, and there's, like, some level of people trying to please you to some extent. That's just, like, naturally, how it starts. And you just, like, keep trying to drill into the answers. And you just keep asking people like, "So, what kind of gifts do you give?" And they're just like, "Oh my goodness, like, I haven't thought about buying gifts for my sister in [laughs], like, you know, in forever. And now, like [laughs], I don't know where to go." And they get, like, pretty stressed out about it.

+ +

But then we just kind of started shifting into like, "All right, cool, never mind about that. Like, do you like listening to music?" And they're like, "Yes." And then it just kind of explodes from there. And they're like, "This last concert that I went to..." and all of this stuff. And it was much more fruitful kind of leaning more towards that, actually, yeah.

+ +

LINDSEY: That's fascinating. I guess that speaks to, especially at this stage and the speed and the amount of interviews you're doing, the need for being, like, really agile in those interviews, and then, like, really quickly applying what you're learning to making the next one even more valuable.

+ +

MIKE: Yeah. And I think, you know, like, we launched just a little sort of website experiment or, like, an e-commerce experiment right before Thanksgiving. And I think now, you know, we're able to sort of take some of those learnings from those interviews and apply them to both sort of our ad copy itself but also just different landing pages in different language on the different kind of versions of the site and see if we can find some resonance with some of these audience groups. So, it's been interesting.

+ +

LINDSEY: Are you still trying to figure out who that early adopter audience is, who that niche persona is?

+ +

MIKE: I think we --

+ +

CHRIS: Yes, we are. I think we have a good idea of who it is. And I think right now we're just trying to figure out really how to reach those people. That, I think, is the biggest challenge right now for us.

+ +

MIKE: Yeah. With the e-commerce experiment it was sort of a very specific niche thing that is a little bit adjacent to what I think we want to be doing longer term with Goodz. And so, it's weird. It's like, we're in a place we're like, oh, we really want to find the people that want this thing. But also, this thing isn't necessarily the thing that we think we're going to make longer term, so let's not worry too hard about finding them. You know what I mean? It's been an interesting sort of back and forth with that.

+ +

CHRIS: From the interviews that we conducted, you know, we identified three key personas. Most of them have come up, but I'll just relist them. There's the sibling gift giver. There was the merch buyers; these are people who go to concerts and buy merchandise, you know, T-shirts, albums, records, things along those lines to support the artists that they love. And then the final one that was identified we gave the title of the 'Proud Playlister'. And these are people who are really into their digital media platforms, love making playlists, and love sharing those playlists with their friends.

+ +

And that, I would say, the proud playlister is really the one that we have focused on in terms of the storefront that we launched, like, the product is pretty much specifically for them. But the lessons that we're learning while making this product and trying to get this into the hands of the proud playlisters will feed into kind of the merch buyers.

+ +

MIKE: Yeah. And I think that, you know, it's funny, like, this week is kind of a poignant week for this, right? Because it's the week that Spotify Wrapped launched, right? So, it's like, in the course of any given year, it's probably, like, the one week of the year that lots and lots and lots of people are thinking about playlists all of a sudden, so trying a little bit to see if we can ride that wave or just kind of dovetail with that a bit, too.

+ +

LINDSEY: Absolutely. And do you want to give just, like, the really quick reminder of what the product experience is like?

+ +

MIKE: Oh yeah [laughs], good call.

+ +

CHRIS: This is a prototype of it. It's called the Goodz Mixtape. Basically, the idea is that you purchase one of these from us. You give us a playlist URL. We program that URL onto the NFC chip that's embedded in the Good itself. And then when you scan this Good, that playlist will come up. So, it's a really great way of you make a playlist for somebody, and you want to gift it to them; this is a great way to do that. You have a special playlist, maybe between you and a friend or you and a partner. This is a good way to commemorate that playlist, turn it into a physical thing, give that digital file value and presence in the physical world.

+ +

LINDSEY: Great. Okay, so you casually mentioned this launch of an e-commerce store that happened last week.

+ +

MIKE: It didn't feel casual.

+ +

LINDSEY: Yeah. Why [laughter]...[inaudible 09:45] real casual. Why did you launch it? How's it going?

+ +

MIKE: I don't know. Why did we launch it? I mean, well, we wanted to be able to test some assumptions. I think, you know, we wanted to get the brand out there a little bit, get our website out there, kind of introduce the concept. You know, this is a very...not that we've invented this product category, but it is a pretty obscure product category, right? And so, there's a lot of sort of consumer education that I think that has to go on for people to wrap their heads around this and why they'd want this.

+ +

So, I think we wanted to start that process a little bit correctly, sort of in advance of a larger launch next year, and see if we could find some early community around this. You know, if we can find those core people who just absolutely love this, and connect with it, and go wild around it, then those are the people that we're going to be able to get a ton of information from and build for that persona, right? It's like, cool, these are the people who love this. Let's build more for them and go find other people like this. So, I think, for us, it was that.

+ +

And then, honestly, it was also just, you know, let's test our manufacturing and fulfillment and logistics capabilities, right? I mean, this is...as much as we are a B2B, you know, SaaS platform or that's what we envision the future of Goodz being, there is a physical component of this. And, you know, we do have that part basically done at this point. But we just, you know, what is it like to order 1,000 of these?

+ +

What is it like to put these in the mail to people and, you know, actually take orders? And just some of that processing because we do envision a more wholesale future where we're doing, you know, thousands or tens of thousands of this at a time. And so, I think we just want to button up and do some dry runs before we get to those kinds of numbers.

+ +

CHRIS: I think it also it's important to remember that we are talking in startup time. And while this last week seems like an eternity, it's been a week [laughs] that we've had this in place. So, we're just starting to learn these things, and we plan on continuing to do so.

+ +

MIKE: Yeah. But I think we thought that getting a website up would be a good way to just start kind of testing everything more.

+ +

LINDSEY: Great. Danny, what went into deciding what would be in this first version of the site and the e-commerce offering?

+ +

DANNY: I mean, a lot of it was kind of mostly driven by Chris and Mike. They kind of had a vision and an idea of what they wanted to sell. Obviously, from the user interviews, we were starting to hone in a little bit more and, like, we had some assumptions going into it. I think we ultimately did kind of feel like, yeah, I think, like, the playlisters seem to be, like, the target market. But just hearing it more and hearing more excitement from them was definitely just kind of like, yeah, I think we can double down on this piece.

+ +

But, ultimately, like, in terms of launching the e-commerce platform, and the storefront, and the website, like, just literally looking at the user journey and being like, how does a user get from getting onto a site, like, as soon as they land there to, like, finishing a purchase? And what points do they need? What are the key things that they need to think through and typically will run into? And a lot of it is just kind of reflecting on our own personal buyer behavior.

+ +

And, also, as we were getting closer to the launch, starting to work through some of those assumptions about buyer behavior. As we got there, we obviously had some prototypes. We had some screenshots that we were already working with. Like, the design team was already starting to build out some of the site. And so, we would just kind of show it to them, show it to our users, and just be like, hey, like, how do you expect to purchase this? Like, what's the next step that you expect to take? And we'd just kind of, like, continue to iterate on that piece. And so...

+ +

LINDSEY: Okay. So you were, before launching, even showing some of those mockups and starting to incorporate them in the user interviews.

+ +

DANNY: Yeah, yeah. I mean, we tried to get it in there in front of them as early as possible, partially because, like, at some point in the user interviews, like, you're mostly just trying to first understand, like, who are our target customers? Who are these people? And we have an assumption of or an idea of who we think they are. But really, like, once you start talking to people, you kind of are, like, okay, like, this thing that I thought maybe it wasn't so accurate, or, like, the way that they're kind of talking about these products doesn't 100% match what I originally walked into this, you know, experiment with. And so, we, like, start to hone in on that.

+ +

But after a certain point, you kind of get that idea and now you're just like, okay, you seem to be, like, the right person to talk to. And so, if I were to show you this thing, do you get it, right? Like, do you understand what's happening? Like, how to use this thing, what this product even does. And then also, like, does the checkout experience feel intuitive for you? Is it as simple as, like, I just want to buy a T-shirt? So, like, I'm just going to go by the T-shirt, pick a size, and, you know, move on with my life. Can we make it as seamless as that?

+ +

LINDSEY: And so, you mentioned it's only been a week since it's been live. Have you been able to learn anything from it yet? And how are you trying to drive people to it today?

+ +

MIKE: Yeah, I think we learned that sales is hard [laughs] and slow, and it takes some time. But it's good, and we're learning a lot. I mean, it's been a while since I've really dug deep in, like, the analytics and marketing kind of metrics. And so, we've got all the Google Tag Manager stuff, you know, hooked up and just, you know, connecting with just exploring, honestly, like the TikTok advertising platform, and the YouTube Pre-Rolls, and Shorts. And, like, a lot of stuff that I actually, since the last time I was heavily involved in this stuff, is just totally new and different.

+ +

And so, it's been super interesting to see the funnel and sort of see where people are getting in the site, where people are dropping off. You know, we had an interesting conversation in our thoughtbot sync yesterday or the day before, where we were seeing how, you know, we're getting lots of people to the front page and, actually, a good number of people to the product page, and, actually, like, you know, not the worst number of people to the cart. But then you were seeing really high cart abandonment rates.

+ +

And then, you know, when you start Googling, and you're like, oh, actually, everybody sees very high cart abandonment rates; that's just a thing. But we were seeing, like, the people were viewing their cart seven or eight times, and they were on there sort of five times as long as they were on any other page. And it's this problem that I think Danny is talking about where, you know, we need to actually get a playlist URL. This gets into the minutiae of what we're building, but basically like, we need to get them to give us a playlist URL in order to check out, right?

+ +

And so, you sort of have to, like, put yourself back in the mind of someone who's scrolling on Instagram, and they see this as an ad, and they click it, and they're like, oh, that thing was cool. Sure, I will buy one of those. And then it's like, no, actually, you need to, you know, leave this, go into a different app, find a play...like, it suddenly just puts a lot of the mental strain. But it's a lot. It's a cognitive load, greater than, as you said, just buying a T-shirt and telling what size you want.

+ +

So, thinking through ways to really trim that down, shore up the amount of time people are spending on a cart. All that stuff has been fascinating. And then just, like, the different demographic kind of work that we're using, all the social ads platforms to kind of identify has been really interesting. It's still early.

+ +

But, actually, like, Chris and I were just noticing...we were just talking right before this call. Like, we're actually starting to get, just in the last 12 hours, a bunch more, a bunch, but more people signing up to our email newsletter, probably in the last 12 hours that we have in the whole of last week. Yeah, I don't know, just even that sort of learning, it's like, oh, do people just need time with a thing, or they come back and they think about it?

+ +

CHRIS: Yeah. Could these people be working on their playlists? That's a question that I have.

+ +

MIKE: [chuckles] Yeah, me too.

+ +

CHRIS: It's like, you know, I'm making a playlist to drop into this product. It's really interesting. And I think it gives insight to kind of, you know, how personal this product could be, that this is something that takes effort on the part of the consumer because they're making something to give or to keep for themselves, which is, I think, really interesting but definitely hard, too.

+ +

DANNY: Yeah. And I also want to also clarify, like, Chris just kind of said it, like, especially for viewers and listeners, like, that's something that we've been hearing a lot from user interviews, too, right? Like, the language that they're using is, like, this is a thing that I care about. Like it's a representation of who I am. It's a representation of, like, the relationship that I have with this person that I'm going to be giving, you know, this gift to or this playlist to, specifically, like, people who feel, like, really passionate about these things. And, I mean, like, I did, too.

+ +

Like, when I was first trying to, like, date, my wife, like, I spent, like, hours, hours trying to pick the coolest songs that I thought, you know, were like, oh, like, she's going to think I'm so cool because, like, I listen to these, like, super low-key indie rock bands, and, like, you know, so many more hours than she probably spent listening to it. But that's [laughs] kind of, like, honestly, what we heard a lot in a lot of these interviews, so...

+ +

LINDSEY: Yeah, same. No, totally resonates. And I also went to the site this week, and I was like, oh damn, this is cool. Like, and immediately it was like, oh, you know, I've got these three, you know, music friends that we go to shows together. I'm like, oh, this would be so cool to get them, you know, playlists of, like, music we've seen together. So, you might see me in the cart. I won't abandon it.

+ +

MIKE: Please. I would love that.

+ +

CHRIS: Don't think about it too long if you could -- [laughter].

+ +

LINDSEY: I won't. I won't.

+ +

CHRIS: I mean, I would say I'm really excited about having the site not only as a vehicle for selling some of these things but also as a vehicle for just honing our message. It's like another tool that we have in our arsenal. During the user interviews themselves, we were talking in abstract terms, and now we have something concrete that we can bounce off people, which is, I think, going to be a huge boon to our toolset as we continue to refine and define this product.

+ +

MIKE: Yeah, that's a good point.

+ +

LINDSEY: Yeah. You mentioned that they're signing up for, like, email updates. Do you have something you're sending out? Or are you kind of just creating a list? Totally fine, just building a list.

+ +

MIKE: [laughs] No.

+ +

CHRIS: It's a picture of Mike and I giving a big thumbs up. That's, yeah. [laughter]

+ +

MIKE: No. But maybe...that was the thing; I was like, oh great, they're signing up. And I was like, gosh, they're signing up. Okay [laughter], now we got to write something. But we will.

+ +

LINDSEY: Tips to making your playlist [crosstalk 19:11] playing your playlist --

+ +

MIKE: Yeah [crosstalk 19:13].

+ +

CHRIS: Right. And then also...tips to making your playlists. Also, we're advancing on the collectible side of things, too. We are, hopefully, going to have two pilot programs in place, one with a major label and one with a major artist. And we're really excited about that.

+ +

LINDSEY: Okay. That's cool. I assume you can't tell us very much. What can you tell us?

+ +

MIKE: Yeah. We won't mention names [chuckles] in case it just goes away, as these things sometimes do. But yeah, there's a great band who's super excited about these, been around for a long time, some good name recognition, and a very loyal fan base. They want to do sort of a collection of these. I think maybe we showed the little...I can't remember if we showed the little crates that we make or not, but basically, [inaudible 19:52]

+ +

LINDSEY: The last time, yeah.

+ +

MIKE: So, they want to sell online a package that's, you know, five or six Goodz in a crate, which I think will be cool and a great sort of sales experiment. And then there's a couple of artists that we're going to do an experiment with that's through their label that's more about tour...basically, giving things away on tour. So, they're going to do some giveaway fan club street team-style experiments with some of these on the road.

+ +

So, first, it's ideal, provided both those things happen, because we definitely want to be exploring on the road and online stuff. And so, this kind of lets us do both at once and get some real learnings as to kind of how people...because we still don't know. We haven't really put these in people's hands yet. And it's just, like, are people scanning these a lot? Are they not? Is this sort of an object that's sitting on their shelf? Is it...yeah, it's just, like, there's so much we're going to learn once we get these into people's hands.

+ +

LINDSEY: Do you have the infrastructure to sort of see how many times the cards are scanned?

+ +

CHRIS: Mm-hmm. Yep, we do.

+ +

MIKE: Yeah. So, we can see how many times each one is scanned, where they're scanned, that sort of thing.

+ +

CHRIS: Kind of our next step, and something we were just talking about today with the thoughtbot team, is building out kind of what the backend will be for this, both for users and also for labels and artists. That it will allow them to go in and post updates to the Goodz, to allow them to use these for promotion as people, you know, scan into them to give them links to other sites related to the artists that they might be interested in before they move on to the actual musical playlist. So, that's kind of the next step for us. And knowing how users use these collectibles, both the kind of consumer Good and the artist collectibles that we were just talking about, will help inform how we build that platform.

+ +

LINDSEY: Very cool. And right now, the online store itself that's built in Shopify?

+ +

MIKE: Yeah. The homepage is Webflow that Kevin from the thoughtbot team really spearheaded in building for us. And then, yeah, the e-commerce is Shopify.

+ +

LINDSEY: Y'all have been busy.

+ +

MIKE: [laughs]

+ +

LINDSEY: Is there anything else maybe that I haven't asked about yet that we should touch on in terms of updates or things going on with the product?

+ +

MIKE: I don't know. I don't think so. I think, like Chris said, I mean, we're just...like, now that the site has kind of stood up and we're really switched over to kind of marketing and advertising on that, definitely digging into the backend of this kind of SaaS platform that's going to probably be a big focus for the rest of the, you know, the program, to be honest. Yeah, just some other things we can do on the next front that could eventually build into the backend that I think can be interesting. No, I guess [laughs] the short answer is no, nothing, like, substantial. Those are the big [crosstalk 22:26]

+ +

LINDSEY: Yeah. Well, that was my next question, too, which is kind of like, what's next, or what's the next chunk of work? So, it's obviously lots more optimization and learning on the e-commerce platform, and then this other mega area, which is, you know, what does this look like as a SaaS solution? What's the vision? But also, where do we start? Which I'm sure, Danny, is a lot of work that you specialize in as far as, like, scoping how to approach these kinds of projects.

+ +

DANNY: Yeah. And it's interesting because, I mean, we were just talking about this today. Like, part of it is, like, we can, like, really dig into, like, the e-commerce site and, like, really nailing it down to get it to the place where it's like, we're driving tons more traffic and also getting as low of a, like, cart abandonment rate as possible, right? But also, considering the fact that this is in the future, like, large-scale vision.

+ +

And there's, like, also, like, we're starting to, I think, now iron out a lot of those, like, milestones where we're kind of like, okay, like, we got, like, a short-term vision, which is, like, the e-commerce site. We got a mid-term vision and a potential long-term vision. How do we validate this long-term vision while also still like, keeping this short-term vision moving forward?

+ +

And, like, this mid-term vision is also going to, like, help potentially, either, like, steer us towards that long-term or maybe even, like, pivot us, like, into a completely different direction. So, like, where do you put your card, right? Like, how much energy and time do we put into, like, each of these areas? And that's kind of, like, the interesting part of this is starting to talk through that, starting to kind of prioritize, like, how we can maximize on our effort, like, our development and design effort so that things just kind of line up more naturally and organically for our future visioning, so...

+ +

MIKE: Yeah. A lot of different things to juggle. I saw there was a question. Somebody asked what the URL is, but I don't seem to be able to [crosstalk 24:10].

+ +

LINDSEY: The same question as me. We got to drop the link for this thing.

+ +

MIKE: Yeah, getthegoodz.com.

+ +

CHRIS: That's G-O-O-D-Z.

+ +

LINDSEY: Get in there, folks

+ +

MIKE: Yeah, get [crosstalk 24:23].

+ +

LINDSEY: And let us know how it goes.

+ +

MIKE: Yeah, please [laughs]. Any bugs? Let us know. Yeah. I think that those...yeah, I mean, it's a good point, Danny, in terms of juggling kind of the near-term and longer-term stuff. You know, it's a good kind of reminder our big focus, you know, in the new year is going to be fundraising, right? We're already talking to some investors and things like that.

+ +

So, it's like, okay, yes, as you said, we could tweak the cart. We could tweak the e-commerce. Or, like, can we paint the big picture of what the longer-term version of this company is going to be in a way that makes it compelling for investment to come in so that there can be a long-term version of this company? And then we can build those things. So yeah, it's definitely a balance between the two.

+ +

LINDSEY: Oh, also, just casual fundraising as well.

+ +

[crosstalk 25:06]

+ +

MIKE: Yeah, yeah.

+ +

LINDSEY: [laughs]

+ +

MIKE: But it's hard. It's like, you wake up in the morning. It's like, do I want to, like, write cold emails to investors? Or do I want to, like, look at Google Analytics and, like, tweak ad copy? That's actually more fun. So, yes.

+ +

LINDSEY: Yeah, life of the founder, for sure. All right. So, that's getthegoodz (Goodz with a z) .com. Check it out. We'll tune in and see what happens with the e-commerce site, what happens with the SaaS planning the next time that we check in.

+ +

But Chris, Mike, Danny, thank you so much for joining today and sharing what's been going on over the last few weeks: the good, the bad, the challenge, the cart abandonment. And, you know, best of luck to you over the next few weeks, and we'll be sure to check in and see how it's going.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Chris Cerrito, Joe Ferris, Jordyn Bonds, and Mike Rosenthal.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + If you missed the first and second episodes with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can listen to the first episode and the second episode to catch up!

+ +
+ +

Lindsey Christensen, head of marketing at thoughtbot is joined by Mike Rosenthal and Chris Cerrito, co-founders of the startup Goodz, and Danny Kim, Senior Product Manager at thoughtbot.

+ +

Mike and Chris discuss the progress of Goodz, focusing on the recent intense weeks they've had. Goodz, a startup merging the digital and physical worlds of music, has stayed on course with its initial concept. Mike details their approach to Thanksgiving and the launch of their e-commerce experiment. He shares insights from recent user interviews, which have influenced their approach and understanding of their target audience.

+ +

When the discussion turns to the challenges of launching and maintaining their e-commerce platform, Mike and Chris talk about learning from analytics, marketing strategies, and the importance of understanding consumer behavior. They discuss the challenges in balancing short-term and long-term goals, and the upcoming fundraising efforts.

+ +

Transcript:

+ +

LINDSEY: Thanks for being here. My name's Lindsey. I head up marketing at thoughtbot. If you haven't joined one of these before, we are checking in with two of the founders who are going through the thoughtbot Startup Incubator to learn how it's going, what's new, what challenges they're hitting, and what they're learning along the way.

+ +

If you're not familiar with thoughtbot, we're a product design and development consultancy, and we hope your team and your product become a success. And one way we do that is through our startup incubator.

+ +

So, today, we are joined by our co-founders, Mike Rosenthal and Chris Cerrito, Co-Founders of the startup Goodz. And we also have another special guest today, Danny Kim, from the thoughtbot side, Senior Product Manager at thoughtbot. So, I think, to start off, we'll head over to the new face, the new voice that we've got with us today. Danny, tell us a little bit about your role at thoughtbot and, specifically, the incubator.

+ +

DANNY: Yeah, sure. First of all, thanks for having me on, and thanks for letting me join in on all the fun. I'm one of the product managers at thoughtbot. I typically work for the Lift-Off team. We usually work with companies that are looking to, like, go into market with their first version MVP. They might have a product that exists and that they're already kind of doing well with, and they kind of want to jump into a new segment. We'll typically work with companies like that to kind of get them kicked off the ground.

+ +

But it's been really awesome being part of the incubator program. It's my first time in helping with the market validation side. Definitely also, like, learning a lot from this experience [laughs] for myself. Coming at it specifically from a PM perspective, there's, like, so much variation usually in product management across the industry, depending on, like, what stage of the product that you're working in. And so, I'm definitely feeling my fair share of impostor syndrome here.

+ +

But it's been really fun to stretch my brand and, like, approach problems from, like, a completely different perspective and also using different tools. But, you know, working with Mike and Chris makes it so much easier because they really make it feel like you're part of their team, and so that definitely goes a long way.

+ +

LINDSEY: It just goes to show everyone gets impostor syndrome sometimes [laughter], even senior product managers at thoughtbot [laughter]. Thanks for that intro. It's, you know, the thoughtbot team learns along the way, too, you know, especially if usually you're focused on a different stage of product development.

+ +

Mike, it's been only three weeks or a very long three weeks since last we checked in with you, kind of forever in startup time. So, I think the last time, we were just getting to know you two. And you were walking us through the concept, this merging of the digital and physical world of music, and how we interact with music keepsakes or merchandise. How's my pitch?

+ +

MIKE: Good. Great. You're killing it.

+ +

[laughter]

+ +

LINDSEY: And has anything major changed to that concept in the last three weeks?

+ +

MIKE: No. I mean, I can't believe it's only been three weeks. It feels like it's been a long time since we last talked. It's been an intense three weeks, for sure. No, it's been going really well. I mean, we launched all sorts of stuff. I'm trying to think of anything that's sort of fundamentally changed in terms of the plan itself or kind of our, yeah, what we've been working on. And I think we've pretty much stayed the course to sort of get to where we are now. But it's been really intensive.

+ +

I think also having sort of Thanksgiving in there, and we were kind of pushing to get something live right before the Thanksgiving break. And so, that week just felt, I mean, I was just dead by, you know, like, Thursday of Thanksgiving. I think we all were. So, it's been intense, I would say, is the short answer. And I'm happy, yeah, to get into kind of where things are at. But big picture, it's been an intense three weeks.

+ +

LINDSEY: That's cool. And when we talked, you were, you know, definitely getting into research and user interviews. Have those influenced any, you know, changes along the way in the plan?

+ +

MIKE: Yeah. They've been really helpful. You know, we'd never really done that before in any of the sort of past projects that we've worked on together. And so, I think just being able to, you know, read through some of those scripts and then sit through some of the interviews and just kind of hearing people's honest assessment of some things has been really interesting. I'm trying to think if it's materially affected anything.

+ +

I guess, you know, at first, we were, like, we kind of had some assumptions around, okay, let's try to find, like...adult gift-givers sounds like the wrong thing, adults who give gifts as, like, a persona. The idea that, like, you know, maybe you gift your siblings gifts, and then maybe this could be a good gift idea. And I think, you know, we had a hard time kind of finding people to talk in an interesting way about that. And I think we've kind of realized it's kind of a hard persona to kind of chop up and talk about, right, Chris? I don't know [crosstalk 04:55]

+ +

CHRIS: Well, it also seemed to, from my understanding of it, it seemed to, like, genuinely stress out the people who were being interviewed...

+ +

MIKE: [laughs]

+ +

CHRIS: Because it's kind of about a stressful topic [inaudible 05:03], you know, and, like, especially --

+ +

LINDSEY: Why? [laughs]

+ +

CHRIS: Well, I think, I don't know, now I'm making assumptions. Maybe because we're close to the holiday season, and that's a topic in the back of everybody's mind. But yeah, Danny, would you disagree with that? Those folks, from what we heard, seemed like they were the most difficult to kind of extract answers from. But then, if the subject changed and we treated them as a different persona, several of those interviews proved to be quite fruitful. So, it's just really interesting.

+ +

DANNY: Yeah. It really started, like, you kind of try to get some answers out of people, and there's, like, some level of people trying to please you to some extent. That's just, like, naturally, how it starts. And you just, like, keep trying to drill into the answers. And you just keep asking people like, "So, what kind of gifts do you give?" And they're just like, "Oh my goodness, like, I haven't thought about buying gifts for my sister in [laughs], like, you know, in forever. And now, like [laughs], I don't know where to go." And they get, like, pretty stressed out about it.

+ +

But then we just kind of started shifting into like, "All right, cool, never mind about that. Like, do you like listening to music?" And they're like, "Yes." And then it just kind of explodes from there. And they're like, "This last concert that I went to..." and all of this stuff. And it was much more fruitful kind of leaning more towards that, actually, yeah.

+ +

LINDSEY: That's fascinating. I guess that speaks to, especially at this stage and the speed and the amount of interviews you're doing, the need for being, like, really agile in those interviews, and then, like, really quickly applying what you're learning to making the next one even more valuable.

+ +

MIKE: Yeah. And I think, you know, like, we launched just a little sort of website experiment or, like, an e-commerce experiment right before Thanksgiving. And I think now, you know, we're able to sort of take some of those learnings from those interviews and apply them to both sort of our ad copy itself but also just different landing pages in different language on the different kind of versions of the site and see if we can find some resonance with some of these audience groups. So, it's been interesting.

+ +

LINDSEY: Are you still trying to figure out who that early adopter audience is, who that niche persona is?

+ +

MIKE: I think we --

+ +

CHRIS: Yes, we are. I think we have a good idea of who it is. And I think right now we're just trying to figure out really how to reach those people. That, I think, is the biggest challenge right now for us.

+ +

MIKE: Yeah. With the e-commerce experiment it was sort of a very specific niche thing that is a little bit adjacent to what I think we want to be doing longer term with Goodz. And so, it's weird. It's like, we're in a place we're like, oh, we really want to find the people that want this thing. But also, this thing isn't necessarily the thing that we think we're going to make longer term, so let's not worry too hard about finding them. You know what I mean? It's been an interesting sort of back and forth with that.

+ +

CHRIS: From the interviews that we conducted, you know, we identified three key personas. Most of them have come up, but I'll just relist them. There's the sibling gift giver. There was the merch buyers; these are people who go to concerts and buy merchandise, you know, T-shirts, albums, records, things along those lines to support the artists that they love. And then the final one that was identified we gave the title of the 'Proud Playlister'. And these are people who are really into their digital media platforms, love making playlists, and love sharing those playlists with their friends.

+ +

And that, I would say, the proud playlister is really the one that we have focused on in terms of the storefront that we launched, like, the product is pretty much specifically for them. But the lessons that we're learning while making this product and trying to get this into the hands of the proud playlisters will feed into kind of the merch buyers.

+ +

MIKE: Yeah. And I think that, you know, it's funny, like, this week is kind of a poignant week for this, right? Because it's the week that Spotify Wrapped launched, right? So, it's like, in the course of any given year, it's probably, like, the one week of the year that lots and lots and lots of people are thinking about playlists all of a sudden, so trying a little bit to see if we can ride that wave or just kind of dovetail with that a bit, too.

+ +

LINDSEY: Absolutely. And do you want to give just, like, the really quick reminder of what the product experience is like?

+ +

MIKE: Oh yeah [laughs], good call.

+ +

CHRIS: This is a prototype of it. It's called the Goodz Mixtape. Basically, the idea is that you purchase one of these from us. You give us a playlist URL. We program that URL onto the NFC chip that's embedded in the Good itself. And then when you scan this Good, that playlist will come up. So, it's a really great way of you make a playlist for somebody, and you want to gift it to them; this is a great way to do that. You have a special playlist, maybe between you and a friend or you and a partner. This is a good way to commemorate that playlist, turn it into a physical thing, give that digital file value and presence in the physical world.

+ +

LINDSEY: Great. Okay, so you casually mentioned this launch of an e-commerce store that happened last week.

+ +

MIKE: It didn't feel casual.

+ +

LINDSEY: Yeah. Why [laughter]...[inaudible 09:45] real casual. Why did you launch it? How's it going?

+ +

MIKE: I don't know. Why did we launch it? I mean, well, we wanted to be able to test some assumptions. I think, you know, we wanted to get the brand out there a little bit, get our website out there, kind of introduce the concept. You know, this is a very...not that we've invented this product category, but it is a pretty obscure product category, right? And so, there's a lot of sort of consumer education that I think that has to go on for people to wrap their heads around this and why they'd want this.

+ +

So, I think we wanted to start that process a little bit correctly, sort of in advance of a larger launch next year, and see if we could find some early community around this. You know, if we can find those core people who just absolutely love this, and connect with it, and go wild around it, then those are the people that we're going to be able to get a ton of information from and build for that persona, right? It's like, cool, these are the people who love this. Let's build more for them and go find other people like this. So, I think, for us, it was that.

+ +

And then, honestly, it was also just, you know, let's test our manufacturing and fulfillment and logistics capabilities, right? I mean, this is...as much as we are a B2B, you know, SaaS platform or that's what we envision the future of Goodz being, there is a physical component of this. And, you know, we do have that part basically done at this point. But we just, you know, what is it like to order 1,000 of these?

+ +

What is it like to put these in the mail to people and, you know, actually take orders? And just some of that processing because we do envision a more wholesale future where we're doing, you know, thousands or tens of thousands of this at a time. And so, I think we just want to button up and do some dry runs before we get to those kinds of numbers.

+ +

CHRIS: I think it also it's important to remember that we are talking in startup time. And while this last week seems like an eternity, it's been a week [laughs] that we've had this in place. So, we're just starting to learn these things, and we plan on continuing to do so.

+ +

MIKE: Yeah. But I think we thought that getting a website up would be a good way to just start kind of testing everything more.

+ +

LINDSEY: Great. Danny, what went into deciding what would be in this first version of the site and the e-commerce offering?

+ +

DANNY: I mean, a lot of it was kind of mostly driven by Chris and Mike. They kind of had a vision and an idea of what they wanted to sell. Obviously, from the user interviews, we were starting to hone in a little bit more and, like, we had some assumptions going into it. I think we ultimately did kind of feel like, yeah, I think, like, the playlisters seem to be, like, the target market. But just hearing it more and hearing more excitement from them was definitely just kind of like, yeah, I think we can double down on this piece.

+ +

But, ultimately, like, in terms of launching the e-commerce platform, and the storefront, and the website, like, just literally looking at the user journey and being like, how does a user get from getting onto a site, like, as soon as they land there to, like, finishing a purchase? And what points do they need? What are the key things that they need to think through and typically will run into? And a lot of it is just kind of reflecting on our own personal buyer behavior.

+ +

And, also, as we were getting closer to the launch, starting to work through some of those assumptions about buyer behavior. As we got there, we obviously had some prototypes. We had some screenshots that we were already working with. Like, the design team was already starting to build out some of the site. And so, we would just kind of show it to them, show it to our users, and just be like, hey, like, how do you expect to purchase this? Like, what's the next step that you expect to take? And we'd just kind of, like, continue to iterate on that piece. And so...

+ +

LINDSEY: Okay. So you were, before launching, even showing some of those mockups and starting to incorporate them in the user interviews.

+ +

DANNY: Yeah, yeah. I mean, we tried to get it in there in front of them as early as possible, partially because, like, at some point in the user interviews, like, you're mostly just trying to first understand, like, who are our target customers? Who are these people? And we have an assumption of or an idea of who we think they are. But really, like, once you start talking to people, you kind of are, like, okay, like, this thing that I thought maybe it wasn't so accurate, or, like, the way that they're kind of talking about these products doesn't 100% match what I originally walked into this, you know, experiment with. And so, we, like, start to hone in on that.

+ +

But after a certain point, you kind of get that idea and now you're just like, okay, you seem to be, like, the right person to talk to. And so, if I were to show you this thing, do you get it, right? Like, do you understand what's happening? Like, how to use this thing, what this product even does. And then also, like, does the checkout experience feel intuitive for you? Is it as simple as, like, I just want to buy a T-shirt? So, like, I'm just going to go by the T-shirt, pick a size, and, you know, move on with my life. Can we make it as seamless as that?

+ +

LINDSEY: And so, you mentioned it's only been a week since it's been live. Have you been able to learn anything from it yet? And how are you trying to drive people to it today?

+ +

MIKE: Yeah, I think we learned that sales is hard [laughs] and slow, and it takes some time. But it's good, and we're learning a lot. I mean, it's been a while since I've really dug deep in, like, the analytics and marketing kind of metrics. And so, we've got all the Google Tag Manager stuff, you know, hooked up and just, you know, connecting with just exploring, honestly, like the TikTok advertising platform, and the YouTube Pre-Rolls, and Shorts. And, like, a lot of stuff that I actually, since the last time I was heavily involved in this stuff, is just totally new and different.

+ +

And so, it's been super interesting to see the funnel and sort of see where people are getting in the site, where people are dropping off. You know, we had an interesting conversation in our thoughtbot sync yesterday or the day before, where we were seeing how, you know, we're getting lots of people to the front page and, actually, a good number of people to the product page, and, actually, like, you know, not the worst number of people to the cart. But then you were seeing really high cart abandonment rates.

+ +

And then, you know, when you start Googling, and you're like, oh, actually, everybody sees very high cart abandonment rates; that's just a thing. But we were seeing, like, the people were viewing their cart seven or eight times, and they were on there sort of five times as long as they were on any other page. And it's this problem that I think Danny is talking about where, you know, we need to actually get a playlist URL. This gets into the minutiae of what we're building, but basically like, we need to get them to give us a playlist URL in order to check out, right?

+ +

And so, you sort of have to, like, put yourself back in the mind of someone who's scrolling on Instagram, and they see this as an ad, and they click it, and they're like, oh, that thing was cool. Sure, I will buy one of those. And then it's like, no, actually, you need to, you know, leave this, go into a different app, find a play...like, it suddenly just puts a lot of the mental strain. But it's a lot. It's a cognitive load, greater than, as you said, just buying a T-shirt and telling what size you want.

+ +

So, thinking through ways to really trim that down, shore up the amount of time people are spending on a cart. All that stuff has been fascinating. And then just, like, the different demographic kind of work that we're using, all the social ads platforms to kind of identify has been really interesting. It's still early.

+ +

But, actually, like, Chris and I were just noticing...we were just talking right before this call. Like, we're actually starting to get, just in the last 12 hours, a bunch more, a bunch, but more people signing up to our email newsletter, probably in the last 12 hours that we have in the whole of last week. Yeah, I don't know, just even that sort of learning, it's like, oh, do people just need time with a thing, or they come back and they think about it?

+ +

CHRIS: Yeah. Could these people be working on their playlists? That's a question that I have.

+ +

MIKE: [chuckles] Yeah, me too.

+ +

CHRIS: It's like, you know, I'm making a playlist to drop into this product. It's really interesting. And I think it gives insight to kind of, you know, how personal this product could be, that this is something that takes effort on the part of the consumer because they're making something to give or to keep for themselves, which is, I think, really interesting but definitely hard, too.

+ +

DANNY: Yeah. And I also want to also clarify, like, Chris just kind of said it, like, especially for viewers and listeners, like, that's something that we've been hearing a lot from user interviews, too, right? Like, the language that they're using is, like, this is a thing that I care about. Like it's a representation of who I am. It's a representation of, like, the relationship that I have with this person that I'm going to be giving, you know, this gift to or this playlist to, specifically, like, people who feel, like, really passionate about these things. And, I mean, like, I did, too.

+ +

Like, when I was first trying to, like, date, my wife, like, I spent, like, hours, hours trying to pick the coolest songs that I thought, you know, were like, oh, like, she's going to think I'm so cool because, like, I listen to these, like, super low-key indie rock bands, and, like, you know, so many more hours than she probably spent listening to it. But that's [laughs] kind of, like, honestly, what we heard a lot in a lot of these interviews, so...

+ +

LINDSEY: Yeah, same. No, totally resonates. And I also went to the site this week, and I was like, oh damn, this is cool. Like, and immediately it was like, oh, you know, I've got these three, you know, music friends that we go to shows together. I'm like, oh, this would be so cool to get them, you know, playlists of, like, music we've seen together. So, you might see me in the cart. I won't abandon it.

+ +

MIKE: Please. I would love that.

+ +

CHRIS: Don't think about it too long if you could -- [laughter].

+ +

LINDSEY: I won't. I won't.

+ +

CHRIS: I mean, I would say I'm really excited about having the site not only as a vehicle for selling some of these things but also as a vehicle for just honing our message. It's like another tool that we have in our arsenal. During the user interviews themselves, we were talking in abstract terms, and now we have something concrete that we can bounce off people, which is, I think, going to be a huge boon to our toolset as we continue to refine and define this product.

+ +

MIKE: Yeah, that's a good point.

+ +

LINDSEY: Yeah. You mentioned that they're signing up for, like, email updates. Do you have something you're sending out? Or are you kind of just creating a list? Totally fine, just building a list.

+ +

MIKE: [laughs] No.

+ +

CHRIS: It's a picture of Mike and I giving a big thumbs up. That's, yeah. [laughter]

+ +

MIKE: No. But maybe...that was the thing; I was like, oh great, they're signing up. And I was like, gosh, they're signing up. Okay [laughter], now we got to write something. But we will.

+ +

LINDSEY: Tips to making your playlist [crosstalk 19:11] playing your playlist --

+ +

MIKE: Yeah [crosstalk 19:13].

+ +

CHRIS: Right. And then also...tips to making your playlists. Also, we're advancing on the collectible side of things, too. We are, hopefully, going to have two pilot programs in place, one with a major label and one with a major artist. And we're really excited about that.

+ +

LINDSEY: Okay. That's cool. I assume you can't tell us very much. What can you tell us?

+ +

MIKE: Yeah. We won't mention names [chuckles] in case it just goes away, as these things sometimes do. But yeah, there's a great band who's super excited about these, been around for a long time, some good name recognition, and a very loyal fan base. They want to do sort of a collection of these. I think maybe we showed the little...I can't remember if we showed the little crates that we make or not, but basically, [inaudible 19:52]

+ +

LINDSEY: The last time, yeah.

+ +

MIKE: So, they want to sell online a package that's, you know, five or six Goodz in a crate, which I think will be cool and a great sort of sales experiment. And then there's a couple of artists that we're going to do an experiment with that's through their label that's more about tour...basically, giving things away on tour. So, they're going to do some giveaway fan club street team-style experiments with some of these on the road.

+ +

So, first, it's ideal, provided both those things happen, because we definitely want to be exploring on the road and online stuff. And so, this kind of lets us do both at once and get some real learnings as to kind of how people...because we still don't know. We haven't really put these in people's hands yet. And it's just, like, are people scanning these a lot? Are they not? Is this sort of an object that's sitting on their shelf? Is it...yeah, it's just, like, there's so much we're going to learn once we get these into people's hands.

+ +

LINDSEY: Do you have the infrastructure to sort of see how many times the cards are scanned?

+ +

CHRIS: Mm-hmm. Yep, we do.

+ +

MIKE: Yeah. So, we can see how many times each one is scanned, where they're scanned, that sort of thing.

+ +

CHRIS: Kind of our next step, and something we were just talking about today with the thoughtbot team, is building out kind of what the backend will be for this, both for users and also for labels and artists. That it will allow them to go in and post updates to the Goodz, to allow them to use these for promotion as people, you know, scan into them to give them links to other sites related to the artists that they might be interested in before they move on to the actual musical playlist. So, that's kind of the next step for us. And knowing how users use these collectibles, both the kind of consumer Good and the artist collectibles that we were just talking about, will help inform how we build that platform.

+ +

LINDSEY: Very cool. And right now, the online store itself that's built in Shopify?

+ +

MIKE: Yeah. The homepage is Webflow that Kevin from the thoughtbot team really spearheaded in building for us. And then, yeah, the e-commerce is Shopify.

+ +

LINDSEY: Y'all have been busy.

+ +

MIKE: [laughs]

+ +

LINDSEY: Is there anything else maybe that I haven't asked about yet that we should touch on in terms of updates or things going on with the product?

+ +

MIKE: I don't know. I don't think so. I think, like Chris said, I mean, we're just...like, now that the site has kind of stood up and we're really switched over to kind of marketing and advertising on that, definitely digging into the backend of this kind of SaaS platform that's going to probably be a big focus for the rest of the, you know, the program, to be honest. Yeah, just some other things we can do on the next front that could eventually build into the backend that I think can be interesting. No, I guess [laughs] the short answer is no, nothing, like, substantial. Those are the big [crosstalk 22:26]

+ +

LINDSEY: Yeah. Well, that was my next question, too, which is kind of like, what's next, or what's the next chunk of work? So, it's obviously lots more optimization and learning on the e-commerce platform, and then this other mega area, which is, you know, what does this look like as a SaaS solution? What's the vision? But also, where do we start? Which I'm sure, Danny, is a lot of work that you specialize in as far as, like, scoping how to approach these kinds of projects.

+ +

DANNY: Yeah. And it's interesting because, I mean, we were just talking about this today. Like, part of it is, like, we can, like, really dig into, like, the e-commerce site and, like, really nailing it down to get it to the place where it's like, we're driving tons more traffic and also getting as low of a, like, cart abandonment rate as possible, right? But also, considering the fact that this is in the future, like, large-scale vision.

+ +

And there's, like, also, like, we're starting to, I think, now iron out a lot of those, like, milestones where we're kind of like, okay, like, we got, like, a short-term vision, which is, like, the e-commerce site. We got a mid-term vision and a potential long-term vision. How do we validate this long-term vision while also still like, keeping this short-term vision moving forward?

+ +

And, like, this mid-term vision is also going to, like, help potentially, either, like, steer us towards that long-term or maybe even, like, pivot us, like, into a completely different direction. So, like, where do you put your card, right? Like, how much energy and time do we put into, like, each of these areas? And that's kind of, like, the interesting part of this is starting to talk through that, starting to kind of prioritize, like, how we can maximize on our effort, like, our development and design effort so that things just kind of line up more naturally and organically for our future visioning, so...

+ +

MIKE: Yeah. A lot of different things to juggle. I saw there was a question. Somebody asked what the URL is, but I don't seem to be able to [crosstalk 24:10].

+ +

LINDSEY: The same question as me. We got to drop the link for this thing.

+ +

MIKE: Yeah, getthegoodz.com.

+ +

CHRIS: That's G-O-O-D-Z.

+ +

LINDSEY: Get in there, folks

+ +

MIKE: Yeah, get [crosstalk 24:23].

+ +

LINDSEY: And let us know how it goes.

+ +

MIKE: Yeah, please [laughs]. Any bugs? Let us know. Yeah. I think that those...yeah, I mean, it's a good point, Danny, in terms of juggling kind of the near-term and longer-term stuff. You know, it's a good kind of reminder our big focus, you know, in the new year is going to be fundraising, right? We're already talking to some investors and things like that.

+ +

So, it's like, okay, yes, as you said, we could tweak the cart. We could tweak the e-commerce. Or, like, can we paint the big picture of what the longer-term version of this company is going to be in a way that makes it compelling for investment to come in so that there can be a long-term version of this company? And then we can build those things. So yeah, it's definitely a balance between the two.

+ +

LINDSEY: Oh, also, just casual fundraising as well.

+ +

[crosstalk 25:06]

+ +

MIKE: Yeah, yeah.

+ +

LINDSEY: [laughs]

+ +

MIKE: But it's hard. It's like, you wake up in the morning. It's like, do I want to, like, write cold emails to investors? Or do I want to, like, look at Google Analytics and, like, tweak ad copy? That's actually more fun. So, yes.

+ +

LINDSEY: Yeah, life of the founder, for sure. All right. So, that's getthegoodz (Goodz with a z) .com. Check it out. We'll tune in and see what happens with the e-commerce site, what happens with the SaaS planning the next time that we check in.

+ +

But Chris, Mike, Danny, thank you so much for joining today and sharing what's been going on over the last few weeks: the good, the bad, the challenge, the cart abandonment. And, you know, best of luck to you over the next few weeks, and we'll be sure to check in and see how it's going.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Chris Cerrito, Joe Ferris, Jordyn Bonds, and Mike Rosenthal.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+TFpeg-yo + + ]]> + + Lindsey Christensen + Chris Cerrito + Mike Rosenthal + Joe Ferris + Jordyn Bonds + + + 506: A Breath of Fresh Air: Wendy Lawson's Mission for Accessible Lung Care + https://podcast.thoughtbot.com/506 + 696cee9f-c2b9-4692-8f68-3124dcd79d0a + Thu, 04 Jan 2024 00:15:00 -0500 + thoughtbot + + full + 14 + thoughtbot + Wendy Lawson is the Founder and CEO of Exhale Lung Rehabilitation, a company offering online lung rehabilitation and remote therapeutic monitoring services. She explains her background in chronic disease epidemiology, her dedication to helping those with lung disease, and highlights the challenges in making lung rehabilitation accessible and effective, especially in remote or rural areas. The pandemic created a demand for online medical services, and Exhale took the opportunity to address this need by leveraging technology to provide remote services to those who needed them most. + 35:08 + no + + + Wendy Lawson is the Founder and CEO of Exhale Lung Rehabilitation, a company offering online lung rehabilitation and remote therapeutic monitoring services. Wendy's extensive background in chronic disease epidemiology, respiratory therapy, and her role with the American Lung Association have been pivotal in her mission to address the gaps in lung rehabilitation accessibility. She discusses the challenges faced in making lung rehabilitation widely available, especially in rural areas, and the exacerbated need for such services during the COVID-19 pandemic. Exhale leverages technology to offer personalized rehabilitation programs, making them accessible to a wider audience regardless of their geographic location. This approach has significantly impacted the quality of life for individuals with lung diseases, especially in a time when remote services have become more crucial than ever. +The conversation also touches upon the technical and business aspects of running Exhale where Wendy candidly shares the challenges and pivots in the early stages of the company, from developing proprietary algorithms to realizing the need for a scalable and efficient technological platform. This journey of continuous improvement and adaptation is a testament to her commitment to her mission. The episode concludes with a discussion on the future of lung rehabilitation, the potential changes in healthcare policies, and Wendy's unwavering commitment to improving the lives of those with lung diseases. +Exhale Lung Rehabilitation (https://joinexhale.com/home) +Follow Exhale Lung Rehabilitation on Facebook (https://www.facebook.com/Joinexhale), Instagram (https://www.instagram.com/join.exhale/), or X (https://twitter.com/join_exhale). +Follow Wendy Lawson on LinkedIn (https://www.linkedin.com/in/wendylawson-joinexhale/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Wendy Lawson, Founder and CEO of Exhale Lung Rehabilitation, which provides online lung rehabilitation and remote therapeutic monitoring services. Wendy, thank you for joining us. +WENDY: Thank you so much for having me. +VICTORIA: Wonderful. And we like to start the show with a little warm-up introduction about ourselves. Is there anything exciting happening in your life recently that you'd like to share with our audience? +WENDY: You know, I think the biggest event that has happened for my husband and I and our son and daughter is the marriage of our daughter a couple of weekends ago. So, we're really coming down off of all of the events that surrounded that wedding, and we're so excited for them to start their new life. +VICTORIA: That sounds like a big activity, lots of family life all happening at a time when you are also founder and CEO. So, within that time for your wedding, did you make time or have to learn any new skills for putting on these events? +WENDY: You know, it was really interesting. I did have to do a couple of skills. First of all, planning a wedding is just madness. I knew that it was going to be a big task, but after really having hands on and doing it, it was a lot. It was really fun to learn some new things. +And one of the new things that I learned is really flower arrangements. I did some flower arrangements for some of the tables in a couple of the events that surrounded the wedding. And so, that was really fun, new skill. I love to learn new things. That was enlightening and fun. And I'm glad I don't have to do that as a job. +[laughter] +VICTORIA: Yeah, so I'm curious, how did you approach learning this new skill? What was your method? +WENDY: My entire life I've loved to learn new things. And I probably approach each of those the same way, and that is get a vision for what I want, or what I want to learn, or what I want it to look like, and then do some research, find people who have done it themselves. Ask advice. +Of course, YouTube is fantastic now for things like DIY. So, I definitely went to YouTube and found some experts and watched what they did and tried to mimic it, and so, I'm not sure that I got it as well as they did. But it was certainly enlightening and a lot of fun to learn. +VICTORIA: I appreciate that being a lifelong learner, being excited and loving to learn new things. How has that value of loving to learn new things and being a lifelong learner served you as founder and CEO at Exhale? +WENDY: Being a lifelong learner is something that, I think, started early for me, not just in my career but in my life. I've loved to learn new things. Being a founder comes with lots of unexpected pivots and turns. And I think being open and available to learn new things really furthers your business as a founder and ensures that your business is placed in a position where if you need to pivot, you can learn something new, pivot in that direction, and move on. So, I think learning not just as a founder but in any profession that you do is really a key to success for a long and successful career. +VICTORIA: That makes a lot of sense to me. And I'm going to ask you about your pivots. But first, tell me just how did it all get started? So, what led you to decide to start Exhale? +WENDY: Yeah, well, I have a background...my graduate degree is in chronic disease epidemiology. I'm a registered respiratory therapist. I'm also a board member for the National Board of the American Lung Association. And I have really dedicated my life to dealing with those with lung disease. It is interesting in the clinical realm that you cross things that, scientifically, we know are beneficial to individuals with certain diseases. However, getting that thing out to the general population is challenging, and lung rehabilitation is one of those things. +We've known for a very long time that lung rehabilitation helps people with lung disease live a more successful life and a more enjoyable life and with less symptoms. But the availability of lung rehabilitation to people that really need it is few and far between. If you live in a big city, you usually can find an in-person rehabilitation program, but due to constraints with insurance not approving people until late stages or the inability of a program to get people in because they have long waiting lists, it really has been a struggle for physicians, for clinicians, for individuals with lung disease to actually find a program and do it. +And so, I really wanted to solve that problem, solve the problem of the accessibility, availability, affordability of lung rehabilitation because it's so important to people with lung disease. So, really how I started is identifying the problem of here's a big problem. We can't seem to get people effectively into lung rehabilitation. So, why don't we take use of technology and create a program that is all online and available to a person in their home, on their timeline, no matter where they live? If they live in a rural community and don't have access to a big city hospital, that it's available to them. +VICTORIA: Wow, that's a really fascinating story about your background and how you discovered this problem. And, of course, you know, looking at the timeline, to me, you know, September 2020 is when you're founded. Certainly, something was happening in the world that created an even larger need for lung rehabilitation than before, right? +WENDY: Yeah, I had identified the problem probably...a couple of years before that; I thought, there's got to be a way, you know, there's got to be a way that we can solve this issue of people not having access. Really, the perfect storm of people being cooped up inside—they were quarantined; people couldn't get out. All of the sudden, technology was really our means to be doing a lot of things, and seeing our physicians was one of those things. +Individuals who did not have faith in online technology, or seeing physicians virtually, or going to programs virtually, all of a sudden, those fears were gone because that was really the way that you had to do things in 2020. It was the majority of the way that we talked with our loved ones. It was how we interacted with individuals, whether it was work or medical, lots of different things. +And so, I really felt like the timing was right to go ahead and pull the trigger on this. And let's see if we can find a way...now that people are using technology in a very different way than they were two years prior to that, let's see if we can make this work and get this out to people who need it. +And at the same time, there was a major pandemic with a viral illness that affected the lungs specifically. And so, we were going to have that many more patients that were going to need pulmonary rehabilitation on the flip side of being ill and coming out of this pandemic. So, I think it was, like I said, a perfect storm of individuals in the community receiving technology in a positive manner and then also having a pandemic that affected people with lung disease. +VICTORIA: Wow, that's incredible. So, you already had identified a problem about lack of access to rehabilitation, especially in rural areas. And if people don't know that, you know, hospitals are really, even more, and so as time goes by, getting around major metropolitan areas, so people don't have access to hospitals or doctors in rural areas. And those are also probably the people who maybe need more lung rehabilitation. And then the perfect storm happened, and the pandemic and everything. It became not only the way of doing business and care–a very acceptable way of doing medical care, and also very critical in terms of, like, our national health infrastructure. +WENDY: Yes, absolutely. And, you know, one other component that really propelled me into going ahead and founding this company and then figuring out a way for technology to aid us was that individual programs, even if you did live close to a program, the pandemic shut those programs down completely. Things like cardiac rehab, pulmonary rehab, were all stopped because you could not put a large amount of people in a small space together, working out, breathing hard, learning in classroom environments when they were also immunocompromised. So, the risk to the patient was very high. +And so, those programs, even if you did live close to a program, in 2020, they were completely shut down. And due to individual struggles of hospitals as hospitals opened back up, financial struggles, clinical struggles on having enough staffing is still a really big problem in the medical community. And so, a lot of pulmonary rehabs did not come back, even if you lived in a large city. +So, there are some rehabs that are opening back up now, but there's still that initial problem that we had, even before the pandemic, of there were not enough programs. Only about 2% of the population that can use pulmonary rehab ever got to a pulmonary rehab. And then we shut some down, and it became even worse. So, we estimate now that it's less than 2% that actually get to a pulmonary rehab if they have lung disease, and certainly, because so many more people have lung disease now on this side of the pandemic. +VICTORIA: Wow, yeah. That's a really incredible story, so thank you so much for sharing that. I'm curious now to get into, like, you made the decision. You found the problem. You started the company. What were some early pivots you had to make, and what surprised you about it early in the process? +WENDY: I put together a team of...I have a couple of physicians that are intensivists and focused on lung disease, a pharmacist, a couple of respiratory therapists, physical therapists, Yoga expert, nurse practitioner. So, my whole team really got together, and we decided, okay, we have to make this as close to in-person rehab as humanly possible. +And the problem initially in getting pulmonary rehab out to people, is that anyone that has attempted it before did not have that initial assessment in the program that was really based on algorithms that gave them a personalized experience so that the yoga classes or the strength training classes, or the breathing classes were specific to, one, their lung disease, because there are 26, 7 different lung diseases, and, two, that was very specific to their exercise tolerance of themselves and their lung disease. +Some people are on oxygen 24/7 and can't make it from the bathroom to the kitchen without sitting down in between and catching their breath. And then, other people with lung disease they can walk a mile. So, how do you make sure that the program is based on you and you're really gaining those strides based on your exercise tolerance? So, that was probably the biggest hurdle that we had to make or really decisions surrounding that, like, how do we do this? +And so, creating proprietary algorithms that were then going to help us was a daunting task. It began as a bunch of sticky notes on my office wall and me staring at it going, okay, how do we figure this out? I know we can figure this out. And just having iterations of that algorithm until I got it right. +The next hurdle for me was really how technology could be used to create this experience that was beneficial to the users and the clients and also that we could be proud of as clinicians because we knew that it was providing solid advice and goals, care plans for those individuals that needed it. I came from a clinical background. And so, I was not privy to all of what technology could do. And so, I had to really go out and research, how do we incorporate these things? And how do I envision, you know, the program working and maneuvering around? +I initially hired a company that I thought I was communicating well what I wanted. And they were developers, so they did what I asked, but it was not scalable. And so, me I think that combination of maybe I didn't hire the right company. And then, the second thing was me not really being able to speak the technology terms and understand everything that was available so that I could outline it a little bit better. Created a product that I wasn't proud of and I knew was not scalable. +And so, we had to really pivot and start again, hire a new company, and really sit down with them and say, "Okay, I want you to understand my sticky notes on my office wall. And let's really get this down before we begin to build." So, I would say probably that was my first big pivot moment. And the ups and downs of being a founder are endless. And that was definitely one of those, like, really high points where we're, okay, you know, we're at a point where I believe we can launch and then the low of realizing it is not what I wanted it to be. So, I think that was the first one. +VICTORIA: I appreciate you sharing that. And I think that if the first product you build is something you're not proud of, then you're at least doing it right. You got something out there [laughs]. And you probably learned so much from that process, and it sounds like you applied those learnings to your next phase of the project. And now you've built something that you are proud of. +WENDY: Yeah. I think a founder will continue no matter...and technology certainly is this. But I think this applies to really any business, whether it's a brick-and-mortar or anything online business. I believe that you are constantly improving. You're constantly thinking of, you know, what's version 2 going to look like? What's version 3 going to look like? What's version 25 going to look like? It's definitely a work in progress. +And, you know, having something that you're very proud of, that you worked hard on, and collaborated, and really researched a lot I think that's where we are right now. We're very proud of...I am very proud of this program. And we're seeing some fantastic results. And people who have very severe lung disease and, all of a sudden, they can sit in the floor and play with their grandchildren, or they can go out and get the mail. Just to walk to the end of the block was a big deal for them but now they can do that. +I hear stories all the time. Our clients love to talk to us about, "Hey, guess what I did?" And I love to hear those stories because it means what we created did the job that we created it for. And so, that's very satisfying. It doesn't mean that we won't do pivoting in the future. We certainly will. But as we see those roadblocks, or as we see the hurdles that we have to cross to make sure that this program stays true to what we want it to be, we certainly will find a way over, around, or through those roadblocks to make that happen. +VICTORIA: You can hear your commitment to your mission and your drive to solve this problem in the way that you talk about it and the iterations that you're willing to keep solving it. And you mentioned that, you know, one of the issues you saw in the first iteration was about scaling. So, I was wondering if you could share more about that. Like, what did you see that made you think, oh, this isn't going to scale? Was it a technical issue? Was it the algorithm the way it was working? Or was there something else that made you think, oh, we got to redo this whole thing? [laughs] +WENDY: Yeah, you know, the algorithm was working great, fantastic. It places individuals in classes that they need to be. It's very beneficial. The beta tests on our clients were actually coming out with individuals that were at least doubling their strength in a 12-week period of time, which is really unheard of. Usually, you shoot for 20 to 25% increase in their strength and ability to do things. And so, early on, we were so excited because we thought this is working. And coming out of the gates, out of our beta tests, we thought it is doing clinically what we want it to do. +Now, what we saw was that the process was time-consuming on our side, on the business side, so ensuring that those clients that we looked at what they were doing, that we made sure and contacted them, and did those things. Our system was very labor-intensive. So, to get into the system and actually see what an individual person was doing, was difficult. We didn't have auto alerts that alerted our team, "Hey, this person is struggling today and probably needs a call." +So, those types of things were what we really decided this is not going to be scalable. And they were not easy fixes in the system that we had created. And so, that's really why we chose to pivot and go a different direction because there was just no way to scale it because each individual client was taking so much time that it really was not feasible to be able to gain a lot of clientele without putting more resources in place than we were actually being paid. +VICTORIA: That makes a lot of sense. Like, we are providers. You need to be able to make it less work for them [chuckles] and still be able to provide that quality of care to the individuals. So, it's really interesting you were able to solve for that in your next iteration. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint +VICTORIA: As a company providing health and medical services, how have you navigated the industry? Clearly, you have a big background in health. But how did you get to make your business viable, considering all the bureaucratic nature of the American healthcare system? +WENDY: [chuckles] Really, a part of our mission at Exhale is making pulmonary rehab accessible and affordable, and those two things are difficult in our healthcare system right now. Affordability for pulmonary rehab...just a background in what happens if you go to an in-person program, in-person programs, if you are lucky enough to have one available, and get through the waiting list, and your insurance approves you, then each time you go in, which is usually 2 to 3 times a week over an 8 to 12 week period of time, insurance will pay a portion of that, but you will have a copay each time. And a lot of times, the copays range between $15 and $30 time period. +So, individuals who are on a fixed income, because we're dealing with a lot of people who are older and on Medicare, probably have a very fixed income, they cannot afford that. And often, the attrition in those programs is a big problem because, one, getting a lung patient who is carting oxygen and can't walk very far, can't walk to the end of the block, but you're asking them to park in a parking lot, walk all the way into a hospital, up the stairs, and get into the program. They're exhausted by the time or can't do that. And then they have to pay a copay each time they go in. +And so, we wanted our program to be affordable and accessible. So, we created it where we did not accept insurance at first at all. Insurance does not cover online programs right now. And so we priced ours at the price of a copay per month. So, for the cost of an individual to go one week at an in-person program, they can do our 12-week program and get all the way through. So, that was really important to us to ensure that accessibility, and availability, affordability were all a part of our program and our mission. +VICTORIA: Yeah, it's interesting that insurance doesn't cover online services in a time when a lot of things are [laughs] online. +WENDY: It is really confounding that a service like this is not covered by insurance. Now, we did recently...there is a remote therapeutic monitoring that was available through CMS, added it to their care in 2022, to their fee schedule. We have just implemented our remote therapeutic monitoring side of our lung program. And it is specifically for those with lung disease. +We help their offices, the patient's physician's office, to monitor these patients on a daily basis and then give them feedback on whether or not the patients are taking their medication, and how well they slept, and whether or not they're feeling well that day. And that way, the physician's office can intervene faster, and it keeps those individuals out of the hospital. +A bonus of the Exhale program is that our lung rehab comes free to those who are enrolled in remote therapeutic monitoring. So, if you are a part of our program, then you will receive that service and the benefits of having a rehab program to you. And that's just one more way that we're making it accessible, available, and affordable to people. +VICTORIA: That's really interesting and leads me to my next question, which is, what are some of the biggest hurdles that you see ahead of you in the next six months? +WENDY: The biggest hurdle probably is, where is insurance going? Will it begin to cover it in the future? Because that is super important to getting people the care that they need. And then, how will Medicare and other insurance providers decide to change things? Usually, January 1st of every single year, they put out their new fee schedules. In some years, they just completely cut off services altogether. +And so, what I would like to see is expansion of online services becoming reimbursable through insurance companies, and certainly that they see the value of having a service like this that is incredibly affordable, that is getting fantastic outcomes for people with severe lung disease, and giving them a better life, and keeping them out of the hospital, that they see the value in reimbursing programs like ours so that we are sustainable in the future. +VICTORIA: Yeah. It seems like a win-win for everyone because it keeps your healthcare costs down when you're not going to the hospital and probably helps with all other kinds of health...like you mentioned before, how if your lungs are healthy and you're able to move, it makes your overall body much more healthier. So, what is the wind in your sails? What keeps you going with the program? +WENDY: As a founder, there are always times whenever you're like, okay, what are we doing here? Like, this is so hard. It's [laughs], you know, the ups and downs. And what are we doing? Maybe I just stop this and go back to the clinic. But ultimately, I think what keeps me going is hearing the stories of our clients and how much this program has affected their day-to-day life, and how appreciative they are that we have created something that they can do from home and when they did not have this service available to them previously. +I spoke to someone just on Monday, and he was talking about how he had been in a difficult position. And he said, "I just channeled those lessons that you taught us, and I did my breathing techniques. And I got through it. And I just am so thankful that you guys had taught me how to do that because I don't know if I would have gotten through that situation." And those are the stories that we love to hear. +We love hearing, "Hey, I was able to play with my grandchildren on Thanksgiving because of your program," or "I was able to cook for myself, and that's the first time that I have cooked for myself in three years because I can't stand there that long without being too short of breath." Those stories and talking to our clients it's why I keep doing this. It's why I get up every day and go, okay, whatever problem that we find, we're going to solve it and make this company viable long term because of those outcomes that we're seeing. +VICTORIA: And what a great way to know that it does matter when you're hearing those stories. And for those individual people, that's a huge life-changing difference. +WENDY: Yeah, it certainly is. And it, really, you know, in the grand scheme of things, you don't think about how important it is to just be able to walk from one room to another or be able to clean your bathtub or go get groceries. I mean, those little tasks you don't think about until you are so sick or debilitated that you can't do those things. And it means the difference in having a life that they love to live and having, you know, the resources that they need to be able to live that life. +Those stories definitely keep us going and will keep us going as long as we possibly can. Because we really truly, for those that are utilizing our service, believe that we're helping them reach their goals and beyond and live the best life that they can possibly live with lung disease. +VICTORIA: Oh, that's really awesome. I really appreciate you coming on and sharing that with us today. Do you have any questions for me or for thoughtbot about anything? +WENDY: You know, I think the big question for us is, do you have any users out there? Do you have anyone that is listening to this program right now that needs lung rehabilitation? Or are you a clinician, or do you know a clinician that deals with people with lung disease? We would absolutely love to talk to them and provide our services, and tell you how our outcomes are looking with the patients that we've served so far. So, I guess the big question is, do you know anyone with lung disease, and would you be willing to send them our way? +VICTORIA: Oh, that's incredible. I certainly have some people in my mind who I'm like, oh, you should really introduce to this group of folks over here. I love that that's what you're working on. And is there anything else that you'd like to promote today? +WENDY: Just in general, pulmonary rehabilitation is so important. And if you have an in-person program that's near you, I want to promote them, too. I want you to know that pulmonary rehab is an incredible service. And the outcomes, we have so much research that says if you do an 8 to 12-week program, that you will gain benefits from going through the program. So, whether it's our program, whether it's an in-person program, or a program at a clinic that you go to, I would just encourage anybody to take part in pulmonary rehab if you have lung disease. +And certainly, if you're new to lung disease, if you're a COVID recoverer that has some fibrotic changes in your lungs that you need help navigating, then reach out to those professionals that are in pulmonary rehabilitation because they can help you definitely. And Exhale would always love to serve those, whether post-COVID, or asthma, COPD, fibrosis, pulmonary hypertension, all of those lung diseases. We are here for you, as well as other clinicians that are in this arena. +VICTORIA: One person I'm thinking of works with people who are vaping a lot, really high vaping community. And I'm sure [inaudible 30:48] [laughs], yeah, I hear that in your voice. +WENDY: Yeah. [laughs] +VICTORIA: So that's someone I was like, maybe that'd be a good program for her to share with the people she works with because yeah...and the other...this might be, you know, I know this is a disease issue, but in San Diego, we have a lot of freedivers and people who train holding their breath for a long time. And they've been trying to get me to do that. And so, I was like, well, maybe [chuckles] I could try it and just increase my lung capacity and overall be healthy, too. +WENDY: Yeah, that's a great program, too. It is interesting, too, to see a person's lung function. We have pulmonary lung function diagnostic tests that can be done in a clinic. In the pre and post-diver training, yeah, lung function changes quite a bit in your ability to expand your lungs, hold your breath, and maneuver that oxygen across the membrane so that you are able to sustain longer. So yeah, that's really interesting. +And your point of vape, certainly, we have smoking cessation programs that are involved in our lung rehabilitation. If you smoke, then you get some of those classes about how do I quit smoking? But vaping is becoming a really large issue. I have given several talks in high schools recently. And certainly, with my work with the American Lung Association, American Lung Association does a fantastic job of creating supplemental materials for individuals who, you know, are working with people in that arena. And so, they've really focused on the vape epidemic recently. +And so, if you are dealing with anybody, and especially the youth population, there is a wonderful toolkit that the American Lung Association has available. You can download it. There are some videos or some, like, handouts and stuff like that. Those programs are helping, especially in our schools, because there is a true epidemic with vaping right now. And, unfortunately, when the vape industry created those items, they kind of took a key out of the book from the cigarette companies and promoted it as some, you know, health benefit. +And what we're finding on the flip side in all of the diagnostic testing is it's just as bad as cigarettes. And it's creating a really big problem, especially if they're starting early, 14-15 years old, and their lungs are not developed all the way yet. It is not just water vapor, like they say. It is some very serious, toxic chemicals that they're inhaling, and it has some long-term effects that are going to create some fibrotic changes in the lungs long term. So, as you mentioned, you know, the vape industry, I'm definitely a proponent of preventing people from getting vape products and preventing youth from having access to that. +VICTORIA: Yeah, absolutely. It's a big problem. And I'm excited to see how Exhale and other people are working together to kind of get that message out and solve those problems. So, I appreciate you coming on this show today and sharing all of that with me. +WENDY: I would really love to say thank you so much for considering me and considering Exhale for your program. I always love an opportunity to talk about it. You can tell that I'm very passionate about Exhale and what we're providing, and so thanks so much for letting me come on today. I really appreciate it. It was wonderful to meet you. +VICTORIA: Wonderful to meet you as well. And I really enjoyed hearing your story and hearing all about the great work you're doing. +So, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Wendy Lawson. + + + Wendy Lawson is the Founder and CEO of Exhale Lung Rehabilitation, a company offering online lung rehabilitation and remote therapeutic monitoring services. Wendy's extensive background in chronic disease epidemiology, respiratory therapy, and her role with the American Lung Association have been pivotal in her mission to address the gaps in lung rehabilitation accessibility. She discusses the challenges faced in making lung rehabilitation widely available, especially in rural areas, and the exacerbated need for such services during the COVID-19 pandemic. Exhale leverages technology to offer personalized rehabilitation programs, making them accessible to a wider audience regardless of their geographic location. This approach has significantly impacted the quality of life for individuals with lung diseases, especially in a time when remote services have become more crucial than ever.

+ +

The conversation also touches upon the technical and business aspects of running Exhale where Wendy candidly shares the challenges and pivots in the early stages of the company, from developing proprietary algorithms to realizing the need for a scalable and efficient technological platform. This journey of continuous improvement and adaptation is a testament to her commitment to her mission. The episode concludes with a discussion on the future of lung rehabilitation, the potential changes in healthcare policies, and Wendy's unwavering commitment to improving the lives of those with lung diseases.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Wendy Lawson, Founder and CEO of Exhale Lung Rehabilitation, which provides online lung rehabilitation and remote therapeutic monitoring services. Wendy, thank you for joining us.

+ +

WENDY: Thank you so much for having me.

+ +

VICTORIA: Wonderful. And we like to start the show with a little warm-up introduction about ourselves. Is there anything exciting happening in your life recently that you'd like to share with our audience?

+ +

WENDY: You know, I think the biggest event that has happened for my husband and I and our son and daughter is the marriage of our daughter a couple of weekends ago. So, we're really coming down off of all of the events that surrounded that wedding, and we're so excited for them to start their new life.

+ +

VICTORIA: That sounds like a big activity, lots of family life all happening at a time when you are also founder and CEO. So, within that time for your wedding, did you make time or have to learn any new skills for putting on these events?

+ +

WENDY: You know, it was really interesting. I did have to do a couple of skills. First of all, planning a wedding is just madness. I knew that it was going to be a big task, but after really having hands on and doing it, it was a lot. It was really fun to learn some new things.

+ +

And one of the new things that I learned is really flower arrangements. I did some flower arrangements for some of the tables in a couple of the events that surrounded the wedding. And so, that was really fun, new skill. I love to learn new things. That was enlightening and fun. And I'm glad I don't have to do that as a job.

+ +

[laughter]

+ +

VICTORIA: Yeah, so I'm curious, how did you approach learning this new skill? What was your method?

+ +

WENDY: My entire life I've loved to learn new things. And I probably approach each of those the same way, and that is get a vision for what I want, or what I want to learn, or what I want it to look like, and then do some research, find people who have done it themselves. Ask advice.

+ +

Of course, YouTube is fantastic now for things like DIY. So, I definitely went to YouTube and found some experts and watched what they did and tried to mimic it, and so, I'm not sure that I got it as well as they did. But it was certainly enlightening and a lot of fun to learn.

+ +

VICTORIA: I appreciate that being a lifelong learner, being excited and loving to learn new things. How has that value of loving to learn new things and being a lifelong learner served you as founder and CEO at Exhale?

+ +

WENDY: Being a lifelong learner is something that, I think, started early for me, not just in my career but in my life. I've loved to learn new things. Being a founder comes with lots of unexpected pivots and turns. And I think being open and available to learn new things really furthers your business as a founder and ensures that your business is placed in a position where if you need to pivot, you can learn something new, pivot in that direction, and move on. So, I think learning not just as a founder but in any profession that you do is really a key to success for a long and successful career.

+ +

VICTORIA: That makes a lot of sense to me. And I'm going to ask you about your pivots. But first, tell me just how did it all get started? So, what led you to decide to start Exhale?

+ +

WENDY: Yeah, well, I have a background...my graduate degree is in chronic disease epidemiology. I'm a registered respiratory therapist. I'm also a board member for the National Board of the American Lung Association. And I have really dedicated my life to dealing with those with lung disease. It is interesting in the clinical realm that you cross things that, scientifically, we know are beneficial to individuals with certain diseases. However, getting that thing out to the general population is challenging, and lung rehabilitation is one of those things.

+ +

We've known for a very long time that lung rehabilitation helps people with lung disease live a more successful life and a more enjoyable life and with less symptoms. But the availability of lung rehabilitation to people that really need it is few and far between. If you live in a big city, you usually can find an in-person rehabilitation program, but due to constraints with insurance not approving people until late stages or the inability of a program to get people in because they have long waiting lists, it really has been a struggle for physicians, for clinicians, for individuals with lung disease to actually find a program and do it.

+ +

And so, I really wanted to solve that problem, solve the problem of the accessibility, availability, affordability of lung rehabilitation because it's so important to people with lung disease. So, really how I started is identifying the problem of here's a big problem. We can't seem to get people effectively into lung rehabilitation. So, why don't we take use of technology and create a program that is all online and available to a person in their home, on their timeline, no matter where they live? If they live in a rural community and don't have access to a big city hospital, that it's available to them.

+ +

VICTORIA: Wow, that's a really fascinating story about your background and how you discovered this problem. And, of course, you know, looking at the timeline, to me, you know, September 2020 is when you're founded. Certainly, something was happening in the world that created an even larger need for lung rehabilitation than before, right?

+ +

WENDY: Yeah, I had identified the problem probably...a couple of years before that; I thought, there's got to be a way, you know, there's got to be a way that we can solve this issue of people not having access. Really, the perfect storm of people being cooped up inside—they were quarantined; people couldn't get out. All of the sudden, technology was really our means to be doing a lot of things, and seeing our physicians was one of those things.

+ +

Individuals who did not have faith in online technology, or seeing physicians virtually, or going to programs virtually, all of a sudden, those fears were gone because that was really the way that you had to do things in 2020. It was the majority of the way that we talked with our loved ones. It was how we interacted with individuals, whether it was work or medical, lots of different things.

+ +

And so, I really felt like the timing was right to go ahead and pull the trigger on this. And let's see if we can find a way...now that people are using technology in a very different way than they were two years prior to that, let's see if we can make this work and get this out to people who need it.

+ +

And at the same time, there was a major pandemic with a viral illness that affected the lungs specifically. And so, we were going to have that many more patients that were going to need pulmonary rehabilitation on the flip side of being ill and coming out of this pandemic. So, I think it was, like I said, a perfect storm of individuals in the community receiving technology in a positive manner and then also having a pandemic that affected people with lung disease.

+ +

VICTORIA: Wow, that's incredible. So, you already had identified a problem about lack of access to rehabilitation, especially in rural areas. And if people don't know that, you know, hospitals are really, even more, and so as time goes by, getting around major metropolitan areas, so people don't have access to hospitals or doctors in rural areas. And those are also probably the people who maybe need more lung rehabilitation. And then the perfect storm happened, and the pandemic and everything. It became not only the way of doing business and care–a very acceptable way of doing medical care, and also very critical in terms of, like, our national health infrastructure.

+ +

WENDY: Yes, absolutely. And, you know, one other component that really propelled me into going ahead and founding this company and then figuring out a way for technology to aid us was that individual programs, even if you did live close to a program, the pandemic shut those programs down completely. Things like cardiac rehab, pulmonary rehab, were all stopped because you could not put a large amount of people in a small space together, working out, breathing hard, learning in classroom environments when they were also immunocompromised. So, the risk to the patient was very high.

+ +

And so, those programs, even if you did live close to a program, in 2020, they were completely shut down. And due to individual struggles of hospitals as hospitals opened back up, financial struggles, clinical struggles on having enough staffing is still a really big problem in the medical community. And so, a lot of pulmonary rehabs did not come back, even if you lived in a large city.

+ +

So, there are some rehabs that are opening back up now, but there's still that initial problem that we had, even before the pandemic, of there were not enough programs. Only about 2% of the population that can use pulmonary rehab ever got to a pulmonary rehab. And then we shut some down, and it became even worse. So, we estimate now that it's less than 2% that actually get to a pulmonary rehab if they have lung disease, and certainly, because so many more people have lung disease now on this side of the pandemic.

+ +

VICTORIA: Wow, yeah. That's a really incredible story, so thank you so much for sharing that. I'm curious now to get into, like, you made the decision. You found the problem. You started the company. What were some early pivots you had to make, and what surprised you about it early in the process?

+ +

WENDY: I put together a team of...I have a couple of physicians that are intensivists and focused on lung disease, a pharmacist, a couple of respiratory therapists, physical therapists, Yoga expert, nurse practitioner. So, my whole team really got together, and we decided, okay, we have to make this as close to in-person rehab as humanly possible.

+ +

And the problem initially in getting pulmonary rehab out to people, is that anyone that has attempted it before did not have that initial assessment in the program that was really based on algorithms that gave them a personalized experience so that the yoga classes or the strength training classes, or the breathing classes were specific to, one, their lung disease, because there are 26, 7 different lung diseases, and, two, that was very specific to their exercise tolerance of themselves and their lung disease.

+ +

Some people are on oxygen 24/7 and can't make it from the bathroom to the kitchen without sitting down in between and catching their breath. And then, other people with lung disease they can walk a mile. So, how do you make sure that the program is based on you and you're really gaining those strides based on your exercise tolerance? So, that was probably the biggest hurdle that we had to make or really decisions surrounding that, like, how do we do this?

+ +

And so, creating proprietary algorithms that were then going to help us was a daunting task. It began as a bunch of sticky notes on my office wall and me staring at it going, okay, how do we figure this out? I know we can figure this out. And just having iterations of that algorithm until I got it right.

+ +

The next hurdle for me was really how technology could be used to create this experience that was beneficial to the users and the clients and also that we could be proud of as clinicians because we knew that it was providing solid advice and goals, care plans for those individuals that needed it. I came from a clinical background. And so, I was not privy to all of what technology could do. And so, I had to really go out and research, how do we incorporate these things? And how do I envision, you know, the program working and maneuvering around?

+ +

I initially hired a company that I thought I was communicating well what I wanted. And they were developers, so they did what I asked, but it was not scalable. And so, me I think that combination of maybe I didn't hire the right company. And then, the second thing was me not really being able to speak the technology terms and understand everything that was available so that I could outline it a little bit better. Created a product that I wasn't proud of and I knew was not scalable.

+ +

And so, we had to really pivot and start again, hire a new company, and really sit down with them and say, "Okay, I want you to understand my sticky notes on my office wall. And let's really get this down before we begin to build." So, I would say probably that was my first big pivot moment. And the ups and downs of being a founder are endless. And that was definitely one of those, like, really high points where we're, okay, you know, we're at a point where I believe we can launch and then the low of realizing it is not what I wanted it to be. So, I think that was the first one.

+ +

VICTORIA: I appreciate you sharing that. And I think that if the first product you build is something you're not proud of, then you're at least doing it right. You got something out there [laughs]. And you probably learned so much from that process, and it sounds like you applied those learnings to your next phase of the project. And now you've built something that you are proud of.

+ +

WENDY: Yeah. I think a founder will continue no matter...and technology certainly is this. But I think this applies to really any business, whether it's a brick-and-mortar or anything online business. I believe that you are constantly improving. You're constantly thinking of, you know, what's version 2 going to look like? What's version 3 going to look like? What's version 25 going to look like? It's definitely a work in progress.

+ +

And, you know, having something that you're very proud of, that you worked hard on, and collaborated, and really researched a lot I think that's where we are right now. We're very proud of...I am very proud of this program. And we're seeing some fantastic results. And people who have very severe lung disease and, all of a sudden, they can sit in the floor and play with their grandchildren, or they can go out and get the mail. Just to walk to the end of the block was a big deal for them but now they can do that.

+ +

I hear stories all the time. Our clients love to talk to us about, "Hey, guess what I did?" And I love to hear those stories because it means what we created did the job that we created it for. And so, that's very satisfying. It doesn't mean that we won't do pivoting in the future. We certainly will. But as we see those roadblocks, or as we see the hurdles that we have to cross to make sure that this program stays true to what we want it to be, we certainly will find a way over, around, or through those roadblocks to make that happen.

+ +

VICTORIA: You can hear your commitment to your mission and your drive to solve this problem in the way that you talk about it and the iterations that you're willing to keep solving it. And you mentioned that, you know, one of the issues you saw in the first iteration was about scaling. So, I was wondering if you could share more about that. Like, what did you see that made you think, oh, this isn't going to scale? Was it a technical issue? Was it the algorithm the way it was working? Or was there something else that made you think, oh, we got to redo this whole thing? [laughs]

+ +

WENDY: Yeah, you know, the algorithm was working great, fantastic. It places individuals in classes that they need to be. It's very beneficial. The beta tests on our clients were actually coming out with individuals that were at least doubling their strength in a 12-week period of time, which is really unheard of. Usually, you shoot for 20 to 25% increase in their strength and ability to do things. And so, early on, we were so excited because we thought this is working. And coming out of the gates, out of our beta tests, we thought it is doing clinically what we want it to do.

+ +

Now, what we saw was that the process was time-consuming on our side, on the business side, so ensuring that those clients that we looked at what they were doing, that we made sure and contacted them, and did those things. Our system was very labor-intensive. So, to get into the system and actually see what an individual person was doing, was difficult. We didn't have auto alerts that alerted our team, "Hey, this person is struggling today and probably needs a call."

+ +

So, those types of things were what we really decided this is not going to be scalable. And they were not easy fixes in the system that we had created. And so, that's really why we chose to pivot and go a different direction because there was just no way to scale it because each individual client was taking so much time that it really was not feasible to be able to gain a lot of clientele without putting more resources in place than we were actually being paid.

+ +

VICTORIA: That makes a lot of sense. Like, we are providers. You need to be able to make it less work for them [chuckles] and still be able to provide that quality of care to the individuals. So, it's really interesting you were able to solve for that in your next iteration.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: As a company providing health and medical services, how have you navigated the industry? Clearly, you have a big background in health. But how did you get to make your business viable, considering all the bureaucratic nature of the American healthcare system?

+ +

WENDY: [chuckles] Really, a part of our mission at Exhale is making pulmonary rehab accessible and affordable, and those two things are difficult in our healthcare system right now. Affordability for pulmonary rehab...just a background in what happens if you go to an in-person program, in-person programs, if you are lucky enough to have one available, and get through the waiting list, and your insurance approves you, then each time you go in, which is usually 2 to 3 times a week over an 8 to 12 week period of time, insurance will pay a portion of that, but you will have a copay each time. And a lot of times, the copays range between $15 and $30 time period.

+ +

So, individuals who are on a fixed income, because we're dealing with a lot of people who are older and on Medicare, probably have a very fixed income, they cannot afford that. And often, the attrition in those programs is a big problem because, one, getting a lung patient who is carting oxygen and can't walk very far, can't walk to the end of the block, but you're asking them to park in a parking lot, walk all the way into a hospital, up the stairs, and get into the program. They're exhausted by the time or can't do that. And then they have to pay a copay each time they go in.

+ +

And so, we wanted our program to be affordable and accessible. So, we created it where we did not accept insurance at first at all. Insurance does not cover online programs right now. And so we priced ours at the price of a copay per month. So, for the cost of an individual to go one week at an in-person program, they can do our 12-week program and get all the way through. So, that was really important to us to ensure that accessibility, and availability, affordability were all a part of our program and our mission.

+ +

VICTORIA: Yeah, it's interesting that insurance doesn't cover online services in a time when a lot of things are [laughs] online.

+ +

WENDY: It is really confounding that a service like this is not covered by insurance. Now, we did recently...there is a remote therapeutic monitoring that was available through CMS, added it to their care in 2022, to their fee schedule. We have just implemented our remote therapeutic monitoring side of our lung program. And it is specifically for those with lung disease.

+ +

We help their offices, the patient's physician's office, to monitor these patients on a daily basis and then give them feedback on whether or not the patients are taking their medication, and how well they slept, and whether or not they're feeling well that day. And that way, the physician's office can intervene faster, and it keeps those individuals out of the hospital.

+ +

A bonus of the Exhale program is that our lung rehab comes free to those who are enrolled in remote therapeutic monitoring. So, if you are a part of our program, then you will receive that service and the benefits of having a rehab program to you. And that's just one more way that we're making it accessible, available, and affordable to people.

+ +

VICTORIA: That's really interesting and leads me to my next question, which is, what are some of the biggest hurdles that you see ahead of you in the next six months?

+ +

WENDY: The biggest hurdle probably is, where is insurance going? Will it begin to cover it in the future? Because that is super important to getting people the care that they need. And then, how will Medicare and other insurance providers decide to change things? Usually, January 1st of every single year, they put out their new fee schedules. In some years, they just completely cut off services altogether.

+ +

And so, what I would like to see is expansion of online services becoming reimbursable through insurance companies, and certainly that they see the value of having a service like this that is incredibly affordable, that is getting fantastic outcomes for people with severe lung disease, and giving them a better life, and keeping them out of the hospital, that they see the value in reimbursing programs like ours so that we are sustainable in the future.

+ +

VICTORIA: Yeah. It seems like a win-win for everyone because it keeps your healthcare costs down when you're not going to the hospital and probably helps with all other kinds of health...like you mentioned before, how if your lungs are healthy and you're able to move, it makes your overall body much more healthier. So, what is the wind in your sails? What keeps you going with the program?

+ +

WENDY: As a founder, there are always times whenever you're like, okay, what are we doing here? Like, this is so hard. It's [laughs], you know, the ups and downs. And what are we doing? Maybe I just stop this and go back to the clinic. But ultimately, I think what keeps me going is hearing the stories of our clients and how much this program has affected their day-to-day life, and how appreciative they are that we have created something that they can do from home and when they did not have this service available to them previously.

+ +

I spoke to someone just on Monday, and he was talking about how he had been in a difficult position. And he said, "I just channeled those lessons that you taught us, and I did my breathing techniques. And I got through it. And I just am so thankful that you guys had taught me how to do that because I don't know if I would have gotten through that situation." And those are the stories that we love to hear.

+ +

We love hearing, "Hey, I was able to play with my grandchildren on Thanksgiving because of your program," or "I was able to cook for myself, and that's the first time that I have cooked for myself in three years because I can't stand there that long without being too short of breath." Those stories and talking to our clients it's why I keep doing this. It's why I get up every day and go, okay, whatever problem that we find, we're going to solve it and make this company viable long term because of those outcomes that we're seeing.

+ +

VICTORIA: And what a great way to know that it does matter when you're hearing those stories. And for those individual people, that's a huge life-changing difference.

+ +

WENDY: Yeah, it certainly is. And it, really, you know, in the grand scheme of things, you don't think about how important it is to just be able to walk from one room to another or be able to clean your bathtub or go get groceries. I mean, those little tasks you don't think about until you are so sick or debilitated that you can't do those things. And it means the difference in having a life that they love to live and having, you know, the resources that they need to be able to live that life.

+ +

Those stories definitely keep us going and will keep us going as long as we possibly can. Because we really truly, for those that are utilizing our service, believe that we're helping them reach their goals and beyond and live the best life that they can possibly live with lung disease.

+ +

VICTORIA: Oh, that's really awesome. I really appreciate you coming on and sharing that with us today. Do you have any questions for me or for thoughtbot about anything?

+ +

WENDY: You know, I think the big question for us is, do you have any users out there? Do you have anyone that is listening to this program right now that needs lung rehabilitation? Or are you a clinician, or do you know a clinician that deals with people with lung disease? We would absolutely love to talk to them and provide our services, and tell you how our outcomes are looking with the patients that we've served so far. So, I guess the big question is, do you know anyone with lung disease, and would you be willing to send them our way?

+ +

VICTORIA: Oh, that's incredible. I certainly have some people in my mind who I'm like, oh, you should really introduce to this group of folks over here. I love that that's what you're working on. And is there anything else that you'd like to promote today?

+ +

WENDY: Just in general, pulmonary rehabilitation is so important. And if you have an in-person program that's near you, I want to promote them, too. I want you to know that pulmonary rehab is an incredible service. And the outcomes, we have so much research that says if you do an 8 to 12-week program, that you will gain benefits from going through the program. So, whether it's our program, whether it's an in-person program, or a program at a clinic that you go to, I would just encourage anybody to take part in pulmonary rehab if you have lung disease.

+ +

And certainly, if you're new to lung disease, if you're a COVID recoverer that has some fibrotic changes in your lungs that you need help navigating, then reach out to those professionals that are in pulmonary rehabilitation because they can help you definitely. And Exhale would always love to serve those, whether post-COVID, or asthma, COPD, fibrosis, pulmonary hypertension, all of those lung diseases. We are here for you, as well as other clinicians that are in this arena.

+ +

VICTORIA: One person I'm thinking of works with people who are vaping a lot, really high vaping community. And I'm sure [inaudible 30:48] [laughs], yeah, I hear that in your voice.

+ +

WENDY: Yeah. [laughs]

+ +

VICTORIA: So that's someone I was like, maybe that'd be a good program for her to share with the people she works with because yeah...and the other...this might be, you know, I know this is a disease issue, but in San Diego, we have a lot of freedivers and people who train holding their breath for a long time. And they've been trying to get me to do that. And so, I was like, well, maybe [chuckles] I could try it and just increase my lung capacity and overall be healthy, too.

+ +

WENDY: Yeah, that's a great program, too. It is interesting, too, to see a person's lung function. We have pulmonary lung function diagnostic tests that can be done in a clinic. In the pre and post-diver training, yeah, lung function changes quite a bit in your ability to expand your lungs, hold your breath, and maneuver that oxygen across the membrane so that you are able to sustain longer. So yeah, that's really interesting.

+ +

And your point of vape, certainly, we have smoking cessation programs that are involved in our lung rehabilitation. If you smoke, then you get some of those classes about how do I quit smoking? But vaping is becoming a really large issue. I have given several talks in high schools recently. And certainly, with my work with the American Lung Association, American Lung Association does a fantastic job of creating supplemental materials for individuals who, you know, are working with people in that arena. And so, they've really focused on the vape epidemic recently.

+ +

And so, if you are dealing with anybody, and especially the youth population, there is a wonderful toolkit that the American Lung Association has available. You can download it. There are some videos or some, like, handouts and stuff like that. Those programs are helping, especially in our schools, because there is a true epidemic with vaping right now. And, unfortunately, when the vape industry created those items, they kind of took a key out of the book from the cigarette companies and promoted it as some, you know, health benefit.

+ +

And what we're finding on the flip side in all of the diagnostic testing is it's just as bad as cigarettes. And it's creating a really big problem, especially if they're starting early, 14-15 years old, and their lungs are not developed all the way yet. It is not just water vapor, like they say. It is some very serious, toxic chemicals that they're inhaling, and it has some long-term effects that are going to create some fibrotic changes in the lungs long term. So, as you mentioned, you know, the vape industry, I'm definitely a proponent of preventing people from getting vape products and preventing youth from having access to that.

+ +

VICTORIA: Yeah, absolutely. It's a big problem. And I'm excited to see how Exhale and other people are working together to kind of get that message out and solve those problems. So, I appreciate you coming on this show today and sharing all of that with me.

+ +

WENDY: I would really love to say thank you so much for considering me and considering Exhale for your program. I always love an opportunity to talk about it. You can tell that I'm very passionate about Exhale and what we're providing, and so thanks so much for letting me come on today. I really appreciate it. It was wonderful to meet you.

+ +

VICTORIA: Wonderful to meet you as well. And I really enjoyed hearing your story and hearing all about the great work you're doing.

+ +

So, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Wendy Lawson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Wendy Lawson is the Founder and CEO of Exhale Lung Rehabilitation, a company offering online lung rehabilitation and remote therapeutic monitoring services. Wendy's extensive background in chronic disease epidemiology, respiratory therapy, and her role with the American Lung Association have been pivotal in her mission to address the gaps in lung rehabilitation accessibility. She discusses the challenges faced in making lung rehabilitation widely available, especially in rural areas, and the exacerbated need for such services during the COVID-19 pandemic. Exhale leverages technology to offer personalized rehabilitation programs, making them accessible to a wider audience regardless of their geographic location. This approach has significantly impacted the quality of life for individuals with lung diseases, especially in a time when remote services have become more crucial than ever.

+ +

The conversation also touches upon the technical and business aspects of running Exhale where Wendy candidly shares the challenges and pivots in the early stages of the company, from developing proprietary algorithms to realizing the need for a scalable and efficient technological platform. This journey of continuous improvement and adaptation is a testament to her commitment to her mission. The episode concludes with a discussion on the future of lung rehabilitation, the potential changes in healthcare policies, and Wendy's unwavering commitment to improving the lives of those with lung diseases.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Wendy Lawson, Founder and CEO of Exhale Lung Rehabilitation, which provides online lung rehabilitation and remote therapeutic monitoring services. Wendy, thank you for joining us.

+ +

WENDY: Thank you so much for having me.

+ +

VICTORIA: Wonderful. And we like to start the show with a little warm-up introduction about ourselves. Is there anything exciting happening in your life recently that you'd like to share with our audience?

+ +

WENDY: You know, I think the biggest event that has happened for my husband and I and our son and daughter is the marriage of our daughter a couple of weekends ago. So, we're really coming down off of all of the events that surrounded that wedding, and we're so excited for them to start their new life.

+ +

VICTORIA: That sounds like a big activity, lots of family life all happening at a time when you are also founder and CEO. So, within that time for your wedding, did you make time or have to learn any new skills for putting on these events?

+ +

WENDY: You know, it was really interesting. I did have to do a couple of skills. First of all, planning a wedding is just madness. I knew that it was going to be a big task, but after really having hands on and doing it, it was a lot. It was really fun to learn some new things.

+ +

And one of the new things that I learned is really flower arrangements. I did some flower arrangements for some of the tables in a couple of the events that surrounded the wedding. And so, that was really fun, new skill. I love to learn new things. That was enlightening and fun. And I'm glad I don't have to do that as a job.

+ +

[laughter]

+ +

VICTORIA: Yeah, so I'm curious, how did you approach learning this new skill? What was your method?

+ +

WENDY: My entire life I've loved to learn new things. And I probably approach each of those the same way, and that is get a vision for what I want, or what I want to learn, or what I want it to look like, and then do some research, find people who have done it themselves. Ask advice.

+ +

Of course, YouTube is fantastic now for things like DIY. So, I definitely went to YouTube and found some experts and watched what they did and tried to mimic it, and so, I'm not sure that I got it as well as they did. But it was certainly enlightening and a lot of fun to learn.

+ +

VICTORIA: I appreciate that being a lifelong learner, being excited and loving to learn new things. How has that value of loving to learn new things and being a lifelong learner served you as founder and CEO at Exhale?

+ +

WENDY: Being a lifelong learner is something that, I think, started early for me, not just in my career but in my life. I've loved to learn new things. Being a founder comes with lots of unexpected pivots and turns. And I think being open and available to learn new things really furthers your business as a founder and ensures that your business is placed in a position where if you need to pivot, you can learn something new, pivot in that direction, and move on. So, I think learning not just as a founder but in any profession that you do is really a key to success for a long and successful career.

+ +

VICTORIA: That makes a lot of sense to me. And I'm going to ask you about your pivots. But first, tell me just how did it all get started? So, what led you to decide to start Exhale?

+ +

WENDY: Yeah, well, I have a background...my graduate degree is in chronic disease epidemiology. I'm a registered respiratory therapist. I'm also a board member for the National Board of the American Lung Association. And I have really dedicated my life to dealing with those with lung disease. It is interesting in the clinical realm that you cross things that, scientifically, we know are beneficial to individuals with certain diseases. However, getting that thing out to the general population is challenging, and lung rehabilitation is one of those things.

+ +

We've known for a very long time that lung rehabilitation helps people with lung disease live a more successful life and a more enjoyable life and with less symptoms. But the availability of lung rehabilitation to people that really need it is few and far between. If you live in a big city, you usually can find an in-person rehabilitation program, but due to constraints with insurance not approving people until late stages or the inability of a program to get people in because they have long waiting lists, it really has been a struggle for physicians, for clinicians, for individuals with lung disease to actually find a program and do it.

+ +

And so, I really wanted to solve that problem, solve the problem of the accessibility, availability, affordability of lung rehabilitation because it's so important to people with lung disease. So, really how I started is identifying the problem of here's a big problem. We can't seem to get people effectively into lung rehabilitation. So, why don't we take use of technology and create a program that is all online and available to a person in their home, on their timeline, no matter where they live? If they live in a rural community and don't have access to a big city hospital, that it's available to them.

+ +

VICTORIA: Wow, that's a really fascinating story about your background and how you discovered this problem. And, of course, you know, looking at the timeline, to me, you know, September 2020 is when you're founded. Certainly, something was happening in the world that created an even larger need for lung rehabilitation than before, right?

+ +

WENDY: Yeah, I had identified the problem probably...a couple of years before that; I thought, there's got to be a way, you know, there's got to be a way that we can solve this issue of people not having access. Really, the perfect storm of people being cooped up inside—they were quarantined; people couldn't get out. All of the sudden, technology was really our means to be doing a lot of things, and seeing our physicians was one of those things.

+ +

Individuals who did not have faith in online technology, or seeing physicians virtually, or going to programs virtually, all of a sudden, those fears were gone because that was really the way that you had to do things in 2020. It was the majority of the way that we talked with our loved ones. It was how we interacted with individuals, whether it was work or medical, lots of different things.

+ +

And so, I really felt like the timing was right to go ahead and pull the trigger on this. And let's see if we can find a way...now that people are using technology in a very different way than they were two years prior to that, let's see if we can make this work and get this out to people who need it.

+ +

And at the same time, there was a major pandemic with a viral illness that affected the lungs specifically. And so, we were going to have that many more patients that were going to need pulmonary rehabilitation on the flip side of being ill and coming out of this pandemic. So, I think it was, like I said, a perfect storm of individuals in the community receiving technology in a positive manner and then also having a pandemic that affected people with lung disease.

+ +

VICTORIA: Wow, that's incredible. So, you already had identified a problem about lack of access to rehabilitation, especially in rural areas. And if people don't know that, you know, hospitals are really, even more, and so as time goes by, getting around major metropolitan areas, so people don't have access to hospitals or doctors in rural areas. And those are also probably the people who maybe need more lung rehabilitation. And then the perfect storm happened, and the pandemic and everything. It became not only the way of doing business and care–a very acceptable way of doing medical care, and also very critical in terms of, like, our national health infrastructure.

+ +

WENDY: Yes, absolutely. And, you know, one other component that really propelled me into going ahead and founding this company and then figuring out a way for technology to aid us was that individual programs, even if you did live close to a program, the pandemic shut those programs down completely. Things like cardiac rehab, pulmonary rehab, were all stopped because you could not put a large amount of people in a small space together, working out, breathing hard, learning in classroom environments when they were also immunocompromised. So, the risk to the patient was very high.

+ +

And so, those programs, even if you did live close to a program, in 2020, they were completely shut down. And due to individual struggles of hospitals as hospitals opened back up, financial struggles, clinical struggles on having enough staffing is still a really big problem in the medical community. And so, a lot of pulmonary rehabs did not come back, even if you lived in a large city.

+ +

So, there are some rehabs that are opening back up now, but there's still that initial problem that we had, even before the pandemic, of there were not enough programs. Only about 2% of the population that can use pulmonary rehab ever got to a pulmonary rehab. And then we shut some down, and it became even worse. So, we estimate now that it's less than 2% that actually get to a pulmonary rehab if they have lung disease, and certainly, because so many more people have lung disease now on this side of the pandemic.

+ +

VICTORIA: Wow, yeah. That's a really incredible story, so thank you so much for sharing that. I'm curious now to get into, like, you made the decision. You found the problem. You started the company. What were some early pivots you had to make, and what surprised you about it early in the process?

+ +

WENDY: I put together a team of...I have a couple of physicians that are intensivists and focused on lung disease, a pharmacist, a couple of respiratory therapists, physical therapists, Yoga expert, nurse practitioner. So, my whole team really got together, and we decided, okay, we have to make this as close to in-person rehab as humanly possible.

+ +

And the problem initially in getting pulmonary rehab out to people, is that anyone that has attempted it before did not have that initial assessment in the program that was really based on algorithms that gave them a personalized experience so that the yoga classes or the strength training classes, or the breathing classes were specific to, one, their lung disease, because there are 26, 7 different lung diseases, and, two, that was very specific to their exercise tolerance of themselves and their lung disease.

+ +

Some people are on oxygen 24/7 and can't make it from the bathroom to the kitchen without sitting down in between and catching their breath. And then, other people with lung disease they can walk a mile. So, how do you make sure that the program is based on you and you're really gaining those strides based on your exercise tolerance? So, that was probably the biggest hurdle that we had to make or really decisions surrounding that, like, how do we do this?

+ +

And so, creating proprietary algorithms that were then going to help us was a daunting task. It began as a bunch of sticky notes on my office wall and me staring at it going, okay, how do we figure this out? I know we can figure this out. And just having iterations of that algorithm until I got it right.

+ +

The next hurdle for me was really how technology could be used to create this experience that was beneficial to the users and the clients and also that we could be proud of as clinicians because we knew that it was providing solid advice and goals, care plans for those individuals that needed it. I came from a clinical background. And so, I was not privy to all of what technology could do. And so, I had to really go out and research, how do we incorporate these things? And how do I envision, you know, the program working and maneuvering around?

+ +

I initially hired a company that I thought I was communicating well what I wanted. And they were developers, so they did what I asked, but it was not scalable. And so, me I think that combination of maybe I didn't hire the right company. And then, the second thing was me not really being able to speak the technology terms and understand everything that was available so that I could outline it a little bit better. Created a product that I wasn't proud of and I knew was not scalable.

+ +

And so, we had to really pivot and start again, hire a new company, and really sit down with them and say, "Okay, I want you to understand my sticky notes on my office wall. And let's really get this down before we begin to build." So, I would say probably that was my first big pivot moment. And the ups and downs of being a founder are endless. And that was definitely one of those, like, really high points where we're, okay, you know, we're at a point where I believe we can launch and then the low of realizing it is not what I wanted it to be. So, I think that was the first one.

+ +

VICTORIA: I appreciate you sharing that. And I think that if the first product you build is something you're not proud of, then you're at least doing it right. You got something out there [laughs]. And you probably learned so much from that process, and it sounds like you applied those learnings to your next phase of the project. And now you've built something that you are proud of.

+ +

WENDY: Yeah. I think a founder will continue no matter...and technology certainly is this. But I think this applies to really any business, whether it's a brick-and-mortar or anything online business. I believe that you are constantly improving. You're constantly thinking of, you know, what's version 2 going to look like? What's version 3 going to look like? What's version 25 going to look like? It's definitely a work in progress.

+ +

And, you know, having something that you're very proud of, that you worked hard on, and collaborated, and really researched a lot I think that's where we are right now. We're very proud of...I am very proud of this program. And we're seeing some fantastic results. And people who have very severe lung disease and, all of a sudden, they can sit in the floor and play with their grandchildren, or they can go out and get the mail. Just to walk to the end of the block was a big deal for them but now they can do that.

+ +

I hear stories all the time. Our clients love to talk to us about, "Hey, guess what I did?" And I love to hear those stories because it means what we created did the job that we created it for. And so, that's very satisfying. It doesn't mean that we won't do pivoting in the future. We certainly will. But as we see those roadblocks, or as we see the hurdles that we have to cross to make sure that this program stays true to what we want it to be, we certainly will find a way over, around, or through those roadblocks to make that happen.

+ +

VICTORIA: You can hear your commitment to your mission and your drive to solve this problem in the way that you talk about it and the iterations that you're willing to keep solving it. And you mentioned that, you know, one of the issues you saw in the first iteration was about scaling. So, I was wondering if you could share more about that. Like, what did you see that made you think, oh, this isn't going to scale? Was it a technical issue? Was it the algorithm the way it was working? Or was there something else that made you think, oh, we got to redo this whole thing? [laughs]

+ +

WENDY: Yeah, you know, the algorithm was working great, fantastic. It places individuals in classes that they need to be. It's very beneficial. The beta tests on our clients were actually coming out with individuals that were at least doubling their strength in a 12-week period of time, which is really unheard of. Usually, you shoot for 20 to 25% increase in their strength and ability to do things. And so, early on, we were so excited because we thought this is working. And coming out of the gates, out of our beta tests, we thought it is doing clinically what we want it to do.

+ +

Now, what we saw was that the process was time-consuming on our side, on the business side, so ensuring that those clients that we looked at what they were doing, that we made sure and contacted them, and did those things. Our system was very labor-intensive. So, to get into the system and actually see what an individual person was doing, was difficult. We didn't have auto alerts that alerted our team, "Hey, this person is struggling today and probably needs a call."

+ +

So, those types of things were what we really decided this is not going to be scalable. And they were not easy fixes in the system that we had created. And so, that's really why we chose to pivot and go a different direction because there was just no way to scale it because each individual client was taking so much time that it really was not feasible to be able to gain a lot of clientele without putting more resources in place than we were actually being paid.

+ +

VICTORIA: That makes a lot of sense. Like, we are providers. You need to be able to make it less work for them [chuckles] and still be able to provide that quality of care to the individuals. So, it's really interesting you were able to solve for that in your next iteration.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: As a company providing health and medical services, how have you navigated the industry? Clearly, you have a big background in health. But how did you get to make your business viable, considering all the bureaucratic nature of the American healthcare system?

+ +

WENDY: [chuckles] Really, a part of our mission at Exhale is making pulmonary rehab accessible and affordable, and those two things are difficult in our healthcare system right now. Affordability for pulmonary rehab...just a background in what happens if you go to an in-person program, in-person programs, if you are lucky enough to have one available, and get through the waiting list, and your insurance approves you, then each time you go in, which is usually 2 to 3 times a week over an 8 to 12 week period of time, insurance will pay a portion of that, but you will have a copay each time. And a lot of times, the copays range between $15 and $30 time period.

+ +

So, individuals who are on a fixed income, because we're dealing with a lot of people who are older and on Medicare, probably have a very fixed income, they cannot afford that. And often, the attrition in those programs is a big problem because, one, getting a lung patient who is carting oxygen and can't walk very far, can't walk to the end of the block, but you're asking them to park in a parking lot, walk all the way into a hospital, up the stairs, and get into the program. They're exhausted by the time or can't do that. And then they have to pay a copay each time they go in.

+ +

And so, we wanted our program to be affordable and accessible. So, we created it where we did not accept insurance at first at all. Insurance does not cover online programs right now. And so we priced ours at the price of a copay per month. So, for the cost of an individual to go one week at an in-person program, they can do our 12-week program and get all the way through. So, that was really important to us to ensure that accessibility, and availability, affordability were all a part of our program and our mission.

+ +

VICTORIA: Yeah, it's interesting that insurance doesn't cover online services in a time when a lot of things are [laughs] online.

+ +

WENDY: It is really confounding that a service like this is not covered by insurance. Now, we did recently...there is a remote therapeutic monitoring that was available through CMS, added it to their care in 2022, to their fee schedule. We have just implemented our remote therapeutic monitoring side of our lung program. And it is specifically for those with lung disease.

+ +

We help their offices, the patient's physician's office, to monitor these patients on a daily basis and then give them feedback on whether or not the patients are taking their medication, and how well they slept, and whether or not they're feeling well that day. And that way, the physician's office can intervene faster, and it keeps those individuals out of the hospital.

+ +

A bonus of the Exhale program is that our lung rehab comes free to those who are enrolled in remote therapeutic monitoring. So, if you are a part of our program, then you will receive that service and the benefits of having a rehab program to you. And that's just one more way that we're making it accessible, available, and affordable to people.

+ +

VICTORIA: That's really interesting and leads me to my next question, which is, what are some of the biggest hurdles that you see ahead of you in the next six months?

+ +

WENDY: The biggest hurdle probably is, where is insurance going? Will it begin to cover it in the future? Because that is super important to getting people the care that they need. And then, how will Medicare and other insurance providers decide to change things? Usually, January 1st of every single year, they put out their new fee schedules. In some years, they just completely cut off services altogether.

+ +

And so, what I would like to see is expansion of online services becoming reimbursable through insurance companies, and certainly that they see the value of having a service like this that is incredibly affordable, that is getting fantastic outcomes for people with severe lung disease, and giving them a better life, and keeping them out of the hospital, that they see the value in reimbursing programs like ours so that we are sustainable in the future.

+ +

VICTORIA: Yeah. It seems like a win-win for everyone because it keeps your healthcare costs down when you're not going to the hospital and probably helps with all other kinds of health...like you mentioned before, how if your lungs are healthy and you're able to move, it makes your overall body much more healthier. So, what is the wind in your sails? What keeps you going with the program?

+ +

WENDY: As a founder, there are always times whenever you're like, okay, what are we doing here? Like, this is so hard. It's [laughs], you know, the ups and downs. And what are we doing? Maybe I just stop this and go back to the clinic. But ultimately, I think what keeps me going is hearing the stories of our clients and how much this program has affected their day-to-day life, and how appreciative they are that we have created something that they can do from home and when they did not have this service available to them previously.

+ +

I spoke to someone just on Monday, and he was talking about how he had been in a difficult position. And he said, "I just channeled those lessons that you taught us, and I did my breathing techniques. And I got through it. And I just am so thankful that you guys had taught me how to do that because I don't know if I would have gotten through that situation." And those are the stories that we love to hear.

+ +

We love hearing, "Hey, I was able to play with my grandchildren on Thanksgiving because of your program," or "I was able to cook for myself, and that's the first time that I have cooked for myself in three years because I can't stand there that long without being too short of breath." Those stories and talking to our clients it's why I keep doing this. It's why I get up every day and go, okay, whatever problem that we find, we're going to solve it and make this company viable long term because of those outcomes that we're seeing.

+ +

VICTORIA: And what a great way to know that it does matter when you're hearing those stories. And for those individual people, that's a huge life-changing difference.

+ +

WENDY: Yeah, it certainly is. And it, really, you know, in the grand scheme of things, you don't think about how important it is to just be able to walk from one room to another or be able to clean your bathtub or go get groceries. I mean, those little tasks you don't think about until you are so sick or debilitated that you can't do those things. And it means the difference in having a life that they love to live and having, you know, the resources that they need to be able to live that life.

+ +

Those stories definitely keep us going and will keep us going as long as we possibly can. Because we really truly, for those that are utilizing our service, believe that we're helping them reach their goals and beyond and live the best life that they can possibly live with lung disease.

+ +

VICTORIA: Oh, that's really awesome. I really appreciate you coming on and sharing that with us today. Do you have any questions for me or for thoughtbot about anything?

+ +

WENDY: You know, I think the big question for us is, do you have any users out there? Do you have anyone that is listening to this program right now that needs lung rehabilitation? Or are you a clinician, or do you know a clinician that deals with people with lung disease? We would absolutely love to talk to them and provide our services, and tell you how our outcomes are looking with the patients that we've served so far. So, I guess the big question is, do you know anyone with lung disease, and would you be willing to send them our way?

+ +

VICTORIA: Oh, that's incredible. I certainly have some people in my mind who I'm like, oh, you should really introduce to this group of folks over here. I love that that's what you're working on. And is there anything else that you'd like to promote today?

+ +

WENDY: Just in general, pulmonary rehabilitation is so important. And if you have an in-person program that's near you, I want to promote them, too. I want you to know that pulmonary rehab is an incredible service. And the outcomes, we have so much research that says if you do an 8 to 12-week program, that you will gain benefits from going through the program. So, whether it's our program, whether it's an in-person program, or a program at a clinic that you go to, I would just encourage anybody to take part in pulmonary rehab if you have lung disease.

+ +

And certainly, if you're new to lung disease, if you're a COVID recoverer that has some fibrotic changes in your lungs that you need help navigating, then reach out to those professionals that are in pulmonary rehabilitation because they can help you definitely. And Exhale would always love to serve those, whether post-COVID, or asthma, COPD, fibrosis, pulmonary hypertension, all of those lung diseases. We are here for you, as well as other clinicians that are in this arena.

+ +

VICTORIA: One person I'm thinking of works with people who are vaping a lot, really high vaping community. And I'm sure [inaudible 30:48] [laughs], yeah, I hear that in your voice.

+ +

WENDY: Yeah. [laughs]

+ +

VICTORIA: So that's someone I was like, maybe that'd be a good program for her to share with the people she works with because yeah...and the other...this might be, you know, I know this is a disease issue, but in San Diego, we have a lot of freedivers and people who train holding their breath for a long time. And they've been trying to get me to do that. And so, I was like, well, maybe [chuckles] I could try it and just increase my lung capacity and overall be healthy, too.

+ +

WENDY: Yeah, that's a great program, too. It is interesting, too, to see a person's lung function. We have pulmonary lung function diagnostic tests that can be done in a clinic. In the pre and post-diver training, yeah, lung function changes quite a bit in your ability to expand your lungs, hold your breath, and maneuver that oxygen across the membrane so that you are able to sustain longer. So yeah, that's really interesting.

+ +

And your point of vape, certainly, we have smoking cessation programs that are involved in our lung rehabilitation. If you smoke, then you get some of those classes about how do I quit smoking? But vaping is becoming a really large issue. I have given several talks in high schools recently. And certainly, with my work with the American Lung Association, American Lung Association does a fantastic job of creating supplemental materials for individuals who, you know, are working with people in that arena. And so, they've really focused on the vape epidemic recently.

+ +

And so, if you are dealing with anybody, and especially the youth population, there is a wonderful toolkit that the American Lung Association has available. You can download it. There are some videos or some, like, handouts and stuff like that. Those programs are helping, especially in our schools, because there is a true epidemic with vaping right now. And, unfortunately, when the vape industry created those items, they kind of took a key out of the book from the cigarette companies and promoted it as some, you know, health benefit.

+ +

And what we're finding on the flip side in all of the diagnostic testing is it's just as bad as cigarettes. And it's creating a really big problem, especially if they're starting early, 14-15 years old, and their lungs are not developed all the way yet. It is not just water vapor, like they say. It is some very serious, toxic chemicals that they're inhaling, and it has some long-term effects that are going to create some fibrotic changes in the lungs long term. So, as you mentioned, you know, the vape industry, I'm definitely a proponent of preventing people from getting vape products and preventing youth from having access to that.

+ +

VICTORIA: Yeah, absolutely. It's a big problem. And I'm excited to see how Exhale and other people are working together to kind of get that message out and solve those problems. So, I appreciate you coming on this show today and sharing all of that with me.

+ +

WENDY: I would really love to say thank you so much for considering me and considering Exhale for your program. I always love an opportunity to talk about it. You can tell that I'm very passionate about Exhale and what we're providing, and so thanks so much for letting me come on today. I really appreciate it. It was wonderful to meet you.

+ +

VICTORIA: Wonderful to meet you as well. And I really enjoyed hearing your story and hearing all about the great work you're doing.

+ +

So, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Wendy Lawson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7RzkGOA5 + + ]]> + + Victoria Guido + Wendy Lawson + + + 505: Commsor with Mac Reddin + https://podcast.thoughtbot.com/505 + 12238c97-eb3e-4924-a94d-5815ac7482f9 + Thu, 21 Dec 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Mac Reddin is the CEO of Commsor. He discusses Commsor's evolution from community-led growth software to a go-to-network model, emphasizing the importance of various overlapping networks in a company's ecosystem. He shares his journey from running a Minecraft-based company as a teenager to founding Commsor, which initially began as a newsletter and evolved into a community and then a product. + +Mac stresses the effectiveness of authentic community building and relationship-based growth over traditional sales and marketing strategies. He criticizes cold calling and email tactics, advocating for genuine interactions and relationship-building. Commsor’s approach, including personal onboarding of every user and fostering a company culture where employees are encouraged to express their individuality and interests, has shown success and satisfaction internally and in the market. + +Chad reflects on his experiences at thoughtbot, aligning with Reddin's perspective on community and user-centric approaches. He emphasizes trust and freedom within his team, allowing for authentic individual contributions to the company's growth and reputation. Together, they discuss the importance of personal connections in business and how modern sales tactics might need reevaluation in favor of more genuine, relationship-based approaches. + 40:48 + no + + + Mac Reddin is the CEO of Commsor. He discusses Commsor's evolution from community-led growth software to a go-to-network model, emphasizing the importance of various overlapping networks in a company's ecosystem. He shares his journey from running a Minecraft-based company as a teenager to founding Commsor, which initially began as a newsletter and evolved into a community and then a product. +Mac stresses the effectiveness of authentic community building and relationship-based growth over traditional sales and marketing strategies. He criticizes cold calling and email tactics, advocating for genuine interactions and relationship-building. Commsor’s approach, including personal onboarding of every user and fostering a company culture where employees are encouraged to express their individuality and interests, has shown success and satisfaction internally and in the market. +Chad reflects on his experiences at thoughtbot, aligning with Reddin's perspective on community and user-centric approaches. He emphasizes trust and freedom within his team, allowing for authentic individual contributions to the company's growth and reputation. Together, they discuss the importance of personal connections in business and how modern sales tactics might need reevaluation in favor of more genuine, relationship-based approaches. +Commsor (https://www.commsor.com/) +Follow Commsor on LinkedIn (https://www.linkedin.com/company/commsor/) or X (https://twitter.com/Commsor). +Follow Mac Reddin on LinkedIn (https://www.linkedin.com/in/mac-reddin/), GitHub (https://github.com/teaguns), or X (https://twitter.com/TheTeaGuns). Visit his website at macredd.in (https://macredd.in/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me as co-host today is Sally Ladrach, Revenue Enablement Manager at thoughtbot, great company I've heard of. Sally, thank you for joining. +SALLY: Yeah, thanks for having me on. +CHAD: And also joining us today is Mac Reddin, Founder and CEO of Commsor, which builds tools to help individuals and companies of all sizes grow faster, more authentically, and more sustainably through the power of go-to-network. Mac, thanks for joining us. +MAC: Thanks for having me. +CHAD: Mac, can you tell us a little bit more about what Commsor is and how you sort of arrived at creating it? +MAC: I struggle to do that every time someone asks me. It's always, like, a slightly different answer. So, we're about four years old now. But we kind of pivoted, soft pivoted, depending on how you want to look at it, into what we're doing now at the beginning of this year. So, we're kind of not that new and very new, depending on what perspective you look at. +We were originally building what we called community-led growth software. So, we were helping companies measure their community as an intentional part of their go-to-market initiative. And there's a whole rabbit hole on why we changed, and how we changed, and how we ended up where we are now. +But I think go-to-network is sort of an evolution of community-led from this realization that companies don't have a singular community. They might have a, you know, a forum, or a Slack, or a community manager, and there's, like, it's very easy to be like, that is their community. But in reality, there's influencers, investors, creators, advisors, personal brands, executives, champions, customers, community members, like, all these different overlapping networks, hence go-to-network, that actually make up this sort of ecosystem that enables a company to thrive. +CHAD: Now, did you have a community, or, like, did it grow from something, or did you just have the idea? +MAC: I started my first company when I was 17; built on top of Minecraft, and it was very community-centric, and I didn't really realize at the time. But I got lucky enough to sell that business. And, you know, after looking back at all the hats I've worn running a, you know, a tiny, bootstrapped company, I realized the community management part had been what I enjoyed the most and that the community part had been the kind of competitive advantage of that business. And that sent me down a path of thinking about community and business more intentionally after having kind of stumbled into it as a, I guess, late teenager. +So, Commsor started...originally, I knew I wanted to build something in the community space. So, we actually started...it started as a newsletter, actually. It was a substack called Community Chat Weekly, which was just, like, an aggregation newsletter as I was, like, doing research into the more professional community world. And then it became a small Slack community, which then became the community club. And Commsor, as a product, was born out of building a community for community people and just diving headfirst into that world. +SALLY: So much community, I love it [laughs]. +MAC: Yeah. I try to say, like, a couple of different words, like world or something instead of community. +SALLY: [laughs] +MAC: And just, like, we used to joke that we were a community company for community people, by community people, with a community of community people. +CHAD: [laughs] +MAC: I was, like, just too much of the same word [laughs]. +SALLY: I love that. So, it's interesting. One of the reasons why I really wanted to get you and Chad together, in particular, is because the whole go-to-network motion that you're so passionate about and that you've built this product around very closely aligns with how Chad has really led and grown thoughtbot over the last 20 years. And I thought it would be so cool to bring those perspectives together. +And one of the things that you mentioned around community was that it gave you a competitive advantage. I'm curious to know, Chad, does that resonate with you? Have you seen that in thoughtbot over the last, you know, couple of decades as you've been doing this? +CHAD: Yeah, definitely. I mean, one of the things that is my sort of go-to talking points, both at conferences and that kind of thing, is that one thing that has been really a big part of thoughtbot's success is being willing to be clear about who we were and what we believe. And when we do that, then the people who want what we have and believe what we believe and are excited by that can find us and, you know, follow us. And, eventually, when they're in a position to need help, we're top of mind. +And this idea, I think, holds back a lot of companies because you think your market is the total addressable market. And the reality is you're never going to work with the total addressable market. So, you're better off finding the people who believe what you believe in your niche and your community. And being that big fish in that small pond has been really beneficial for us. +SALLY: That's awesome. Yeah, I think it was kind of a culture shock, honestly, coming to thoughtbot because I had been so immersed in sort of the SaaS world and the mass outreach, cold outreach, sort of, I want to say, traditional go-to-market motion that's been used over the last ten years. And I came here, and there were so many things that thoughtbot did or didn't do that I just was honestly kind of shocked, you know, as an example, not using third-party cookies on our website [laughs]. +And, Mac, when we were talking, it sounded like you're also doing some of those things that we joked might make a CRO cry [laughs]. So, I was curious to ask what some of those things were and see how that kind of matches up to what thoughtbot is doing in our approach, too. I'd be curious to know. +MAC: There are so many things. I mean, I get CROs all the time, not, like, yelling at me, but I get the whole like, "Young man, you don't understand how sales works," type comments all the time. I got one recently that was, "Don't talk about sales until you've sold in a recession." It was like, what do you think we've [laughter] been doing the last 18 months? But okay. But yeah, so we don't do cold calls. We don't do cold emails. We don't do any of that traditional stuff that software companies do. +And I guess you all as a, you know, more of a, like, service-based product, as a founder building a software-based product, more than half of the cold outbound I get is, like, developer agencies and stuff like that. It's, like, the classic scourge of outbound in a lot of ways, right? So, there's an element of, like, zigging when everyone else zags. And one of my favorite stats...I can't remember the exact number, so don't fully quote me on it. But -- +CHAD: It's not like we're recording or anything. It's totally fine. +[laughter] +MAC: Yeah, well, I mean, I think the gist of the message is more important than the exact number. And it was a stat that there's been a 100x increase in prospecting activities over the last decade. So, for every cold email, cold call, in-mail ad impression that you would have seen ten years ago, you now get 100 as a buyer. +And I always say this thing to people; I'm like, it doesn't matter how good your outreach is. You can have the best well-crafted cold email, cold call; your timing can be perfect; everything could be right: relevance, timing, everything. The problem is, increasingly, buyers have been so pissed off at the deluge of shit they've gotten for ten years that it doesn't matter. Like, my phone does not ring if I don't have your number. I am physically uncoldcallable. +And I've talked to a lot of CROs, and they're like, "Well, we'll just, you know, marketing will get your lead some other way. And then they'll pass it over to us, and we'll still get to you." And it's like, okay, like, that doesn't really solve the problem. So, like, there's a lot of these weird things where sales and marketing aren't aligned. They expect each other to solve the problem for each other. They're pure volume-based, and we don't do any of that. And a lot of CROs and a lot of VPs of sales love to point out how wrong we are for that, but it's working so far. +And also, it's so much more enjoyable to build a company that way. Like, our salespeople, our SDRs, and all that stuff, they don't hate their jobs. They're not, like, sticking their face to the grindstone every morning and being like, "Oh yeah, I got to play pump-up music before I go to work. Otherwise, I'm not going to get through the day." It just creates a better work environment. It's better for us. It's better for the buyers. It's better all the way around. +CHAD: So, for thoughtbot, I know that a lot of this has come naturally for us because, as developers and designers, we've produced a lot of open source that flows from our work that then builds community around it. We write on a blog, which we're very fortunate to have a lot of people read over the years, which fosters reputation for us and community around it. But what does that look like for other companies who maybe aren't, like, an agency like us doing that kind of thing? What are the kinds of things that it looks like? +MAC: I think you hit the nail on the head earlier when you said it's about, like, showing off who you are and what you believe in and creating space so people can come to you. But in the, you know, the high growth SaaS world, the last ten years, people have not been a fan of waiting for people to come to you. It's, like, grow at all costs, blitzscale, all that sort of mentality. +For us, the way it looks is...I guess an example–so, we did this sort of semi-accidental campaign on LinkedIn over the last, I guess, two and a half months with these purple hoodies. And there's a whole backstory. They were an accident, and we were like, "Shit, we have too many hoodies. What do we do with them?" So, we made a thing out of them. And we thought we were going to get 25. We ended up getting 250 [laughter]. It's a whole thing. +We just started, like, we sent them to a few folks, and someone posted a photo without us asking being like, "Look at this awesome hoodie Commsor sent me." And their post went, like, insane. Like, by LinkedIn standards, it went insane. It was, like, 100 comments. Like, "How do I get one? Oh my God, I love it. It's so cool. Can I get one?" +So, we just started sending them to people, like, no goals, no intention, just brand building, just building connections, building relationships. I personally, from hoodies that I can attribute, have booked over 200 calls about our product with our ICP doing that without trying to. There's almost this element of, like, by not trying to sell, it's become easier to sell. There's, like, an element of like, I'm just sending you a hoodie because I think you're cool, and I want to get to know you. +And it's a fine line because I think a lot of companies try to do that. But you can always tell there's an undertone of, yeah, I'm sending you these cookies because, like, I'm really hoping you get on a sales call with me. But we genuinely were, like, we have too many hoodies. We're just trying to get rid of them. I don't want to pay to store them. Like, please, I'm begging you, please take our hoodie. +SALLY: [laughs] +MAC: And then, it just turned into this, like, whole FOMO game. It's like the authenticity was purely there. All in all, we spent about, including shipping, everything, like, $8,000 on hoodies, so not a tiny amount of money but also not huge by marketing budget standards. And I had a conversation with a CMO recently. He was like, "You should have just spent LinkedIn ads. That's such a waste of money. You can't track it. It's not attributable," et cetera. I was like, "We've gotten, I think, close to a million impressions on LinkedIn of people posting our hoodies talking about us. We couldn't have paid for that." +So, there's, like, this whole area where it's like, if you actually just go out there and build relationships, build community, get to know people, tell them what you believe in, yeah, people will not agree with you. Like, when I say I think modern go-to-market is broken and the way people sell is broken, I get a lot of sales leaders who are like, "You're an idiot. Like, that's wrong. You objectively don't know what you're doing. You've never been a salesperson by title. Don't spread this shit." +But then you get a lot of people who are like, "Yeah, you're right. It's not working. I want to hear what you have to say. I want to talk to you. I want to brainstorm with you." The amount of times that I get DMs from salespeople who are like, "Hey, I totally agree with that post you just wrote, but I can't publicly because my VP of sales is going to read me out if they see me agreeing with you. But like, yeah, this shit doesn't work anymore," like, 10 to 20 times a day, I get messages like that. +SALLY: And as a consumer of LinkedIn feed, you know, I've been following Mac for a while, but also follow a couple of other folks at Commsor and people who are in their networks. I can 100% validate that the Dino Hoodie is, in fact, now a status symbol on LinkedIn. So [laughs], I thought that was, you know, brilliant. And I'm not going to lie; I had some FOMO, too. I was like, where's my Dino Hoodie? And, in fact, when I talked to Mac, I was like -- +CHAD: [laughs] +SALLY: I know that we just met, but can I get one of those? [laughs] +CHAD: I see now. This was just a ploy to get a hoodie. +MAC: I've gotten, like, reverse sales now. It's like, you know, you get pitch slapped on LinkedIn, or someone adds you, and right away, they're trying to sell to you. I've gotten that. [laughter] But they're trying to convince me to give them a hoodie. Like, somehow, we've created the reverse thing where, like, salespeople are reaching out to me to reverse pitch–so I can give them something. +SALLY: That is hilarious. And I promise that was not my intention; was just to get a hoodie from you. But there's so much there that I think would be interesting to unpack. Chad, I'm just kind of curious to know your impression of what Mac has shared around the sort of flak that he's gotten around, you know, what you're doing isn't going to work, or whatever. Have you gotten any of that over the years? Are you surprised to hear that? Just interested to hear your thoughts. +CHAD: No, I think it happens when you are willing to put yourself out there with an opinion, with a belief. And it's going to resonate with the people that it resonates with. And the flip side of that is there are going to be people who believe that you're wrong. You know, when we were doing very early on with test-driven development, for example, it was not an established industry practice. You could find blog posts from people out there saying. "It's bad. We tried it at my startup and our product failed, and it was too slow. It held us back from being successful." +But the people who believe in it...if we were the only company in Boston who was doing it and a company that believes in test-driven development was never going to work with a company that didn't do test-driven development, so we were the one company that they could work with because we believed in the same practices. +And that's the hard thing in that is, usually, if you're on the right track to finding the right niche or to the right belief that's going to really resonate with a group of people, the people that you're turning off is probably going to be a louder, more vocal group. And so, being strong in the face of that is really important. +And I'll also just call out that, like, this is one area where it's easy to say, "Well, this works because you've been successful." There are other founders probably who, like, they have a legitimately bad idea. And they ignore all the sort of haters, and they say, "Oh, those are just the haters." And yet they don't get the success because there wasn't the people out there who actually did believe what they believe or had a need for the product that they were creating, or something like that. +And I think it's important to ignore the noise or to push past the noise, but you do need to let it in a little bit so that you understand whether you're on the right track at all, I've found. What about you, Mac? +MAC: Yeah, it's a never-ending battle to know what to listen to, and what to ignore, and how to apply it or if to apply it, and things like that. I agree. I think there is an element of, like, it's like, what's that [inaudible 14:47] saying? Like, if no one thinks you're crazy or wrong, you're probably too late as well with your idea, right? Like, if you're like, "Here's my idea," and everyone's like, "That's a great idea," It's been done. You're very late to the party at that point. +There's no, like, right or wrong answer because there's always context. You always know your idea and your business, hopefully, better than anybody else does. So, you can't just, like, take other people's advice. I actually went through a whole period (It's like sort of a sidebar.), but where I was, like, impostor syndrome as a, you know, venture-backed CEO. I was like, oh, I got to, like, be the founder and run the company the way other people run companies at this stage. And it, like, objectively, almost killed us as a company. +I have lived both sides of that extreme of like, being like, "No, I'm not going to listen to anybody's advice," and the negatives and positives of that, and the "I'm just going to follow everyone's advice and do what they say," and the negatives and positives of that. And now somewhere, maybe not quite in the middle, maybe a little bit leaning towards the ignore the advice because I believe in what we're doing. +CHAD: And you need to actually believe what you're saying. I think this is the wrong tactic to take if you don't actually believe it. +SALLY: [laughs] +CHAD: Because if it's not authentic to you, it's going to be really hard to build an authentic community and message and those kinds of things, yeah. +MAC: People can tell. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +SALLY: One of the things that you had mentioned before was sort of the technology that you've built Commsor on. And it was an interesting choice to me because it's not one of the more, you know, flashy or hot, new sort of programming languages that's out there. So, I was just kind of wondering, what is it? And why did you make the decision to build out the actual tool the way that you did? +MAC: So, I definitely have to, like, put a giant asterisk over everything I'm about to say. I am not a technical founder [laughs]. So, like, anything I say here is just potentially wrong [laughter]. [inaudible 17:20] The decision was made because I had, you know, a great team that we put together and trusted them to make the decision, and that's the decision we've made. So, I mean, the bulk of the app is built on just, like, Ruby and React. It's pretty straightforward. +We have had people be like, "Well, you should be using this," you know, whatever "Next.js, plus this, plus this, you know, it's better." But, like, the team we have, they've worked together in the past. So, they actually came into an acquihire. So, we're like, basically, like, you know, they'd worked together for three years in a company. They have systems in place. +And at this stage, it's, like, debating what tool you're going to use when you start, like, just 99.9% of the time does not matter. There's no idea...you don't even know if it's going to work, the product, right? It's, like, and your customers don't care. Your customers don't care. Unless you're building a dev tool and it's, like, hyper-specific, but even then, they probably don't really care that much. So yeah, we have a good team. I trust them to make the decision. And it's what they know and what they're familiar with. So, instead of trying to reinvent the wheel, we just went with the thing that would let us get things done the fastest. +SALLY: Chad, I'm interested to know...the trust factor that you mentioned, Mac, is really key to a lot of thoughtbot's success. I think that one of the things that Chad has done well as he's grown the company is hired great people and then trusted them to get the job done however [laughs] they thought that it might best be done. So, Chad, I'm curious to know: whether you're deciding on a tech stack or how you're going to go to market or anything like that, what has the impact of trust been at thoughtbot as you've grown and scaled the company? +CHAD: I think trust is one of [laughs]...I think it's very important. It's one of our core values. And, for us, that comes from not just trust being a nice thing to have. It's the one value that I can also point to and say I intentionally created an environment of trust. +I've been doing freelancing and consulting for a long time, even before thoughtbot. And I knew that at thoughtbot, we were going to continually form and reform teams of people that hadn't necessarily worked together closely before. And that if every time we did that, we were going to have to be building trust with each other, that it would detract from the success of the product that we were trying to create and from the relationship that we were needing to build trust on urgently which was with our new client. +And so I tried really hard to create an environment where when people show up on day one, everyone inherently trusts that they belong there and trusts them. It's not easy, and it's not perfect. But I think we've made a lot of progress on that. And then, when you have that kind of environment, recognizing that it changes the way that you work with each other. And so, when it comes to, like, technology decisions and everything, I mean, that is essentially how we work is understanding that everyone has trust of each other and that when you are put in a position to make a decision, it is your decision to make. +But part of making decisions and part of having a trusting environment is communicating with each other. So, even if you're responsible for making the decision, part of your responsibility, then, is for bringing everyone else along with you. And sometimes that means setting up an environment where, okay, the results speak for themselves. But other times, it means educating people about, "Here's what we're going to do, and here's why," even if it is as simple as "This is what we know. We've been doing it for three years, and let's just get right to it." +I don't know if that directly answers your question. But it's a big part of how we've done things and tried to create the culture that we've created. And I happen to be biased, but Ruby is a great choice. +SALLY: [laughs] +CHAD: I think it's taken for granted because it has been around for so long. But I talk about strong beliefs. I am up to speed on lots of web development frameworks and the ways that you build applications across a variety of different platforms, and tech stacks, and that kind of thing. +We didn't choose Ruby on Rails because we thought it was going to be popular back in 2005. We chose it because it fundamentally was the best way that we could see, out of all the platforms at the time, to build web applications. It allowed us to do things in one line that normally would have, at the time, taken 20. And that allowed us to be faster and work the ways that we wanted to work. And embedded in that culture is things like testing and test-driven development, which we also believe in. +The simple fact of the matter is there hasn't been a paradigm shift in web frameworks that is actually fundamentally better in the way that Ruby on Rails was better in the early 2000s. So, you can choose something else, but it's not going to be significantly better than Rails in terms of productivity, in terms of what it can do for your early-stage product. +It basically just then comes down to there's choices you can make that will slow you down, definitely, in terms of architecture and everything in other platforms. But yeah, you can't go wrong with Rails, and you can't really go wrong with Ruby. And you can't go wrong with choosing what you know and what you're comfortable with, especially in the early days. +SALLY: Yeah, I love that. One of the themes that I'm sort of hearing from both of you in how you've approached building tools; building your business is putting users at the center. And, Mac, I know you were saying, you know, I have all these CROs coming at me, right? Like VPs of sales being like, "The way you're approaching things isn't going to work. It's dumb; it's stupid." +But then you also have these salespeople DMing you like, "Hey, I agree with you. I just can't say it out loud because I might get in trouble." And, ultimately, that salesperson really is your user, right? Because they're the ones that are building their network, that are leveraging it to then go get the sales for the company. +So, I thought it was interesting that sort of that user-centered approach was something that was coming out with both because I know for Ruby, in particular, it's very well-loved by developers that use it. It's, like, a very developer-friendly sort of language. And so, I'm just wondering, you know, how do you, Mac, continue to keep users at the center when you have voices coming at you, when you have [laughs], you know, people telling you you're doing it wrong? What are some things that you do tactically to make sure that you stay aligned? +MAC: I mean, the simple answer is talk to them all the time. We actually...every single user who gets onboarded to our product right now gets an introduction to me directly. That's part of, like, seeing how the product works as well. But every single user ends up speaking to me. Who knows if that'll scale? But right now, it's like, I have spoken for at least 30 minutes with every single person we've onboarded to our product. We onboard every user by hand right now, which is totally counterintuitive for the price point our product's at. +But it's been really helpful to build that relationship, build that trust, get the research and the understanding of what we need to do next really quickly, have tight feedback loops. We have, like, I Dm users all the time. Like, I [inaudible 24:28] I probably have 50 to 60 unique DMs on LinkedIn per day. And someone was telling me like, "That's a waste of time as CEO and founder." I'm like, it's literally the only thing that matters. I'm talking to users, hearing what the market is saying, like, hearing all that live, not hearing it from people. +We're also working on, right now, enabling anyone on our team to do an onboarding so that when we do scale, my goal would be that every person on our team, from an engineer to a success person to the CEO, would be onboarding a customer at least once every few weeks just to maintain that closeness and that connectedness. We're also working on things... I'm a huge fan of...do you know Arc browser? +SALLY: I'm not familiar, no. +CHAD: I haven't used it, but I am familiar with it, yeah. +MAC: I'm using it right now. +CHAD: [laughs] +MAC: Highly recommend. Not an ad, I promise; just a fan. But they do, like, little things that they do, for example, like, when they would change log, instead of being written or instead of being just a CEO, it'll be like, "Here are the four new things released." And the first thing is, "Oh, here's Mac, the developer who worked on this feature sharing it. And here's, you know, this person who worked on this feature." +So, it's like, each individual person becomes the face of the thing they worked on, rather than just like, oh, it's the faceless company, or it's, like, it's always the same, like, spokesperson who's always talking about it. So, enabling it to not just be me who talks to users all the time but the whole company enables the whole company to be more user-centric. +SALLY: That's so interesting. Again, there's, like, so many parallels between how I've seen thoughtbot approach things and how you're approaching things with Commsor. When you mentioned that your goal is to sort of make it so that several different people are the face, and it's not just like, oh, Commsor is Mac only [laughs], that's something that I think I've seen Chad do throughout the years. +So, Chad, do you have any examples of sort of how you've tried to scale the company, putting different faces and putting our experts out there, trying to make it so that thoughtbot is not, like, the Chad show? Because I feel like that's one of the things that, you know, you're great [laughs]. But I think that the fact that we have so many contributors to communities and people speaking at events has been really, you know, just good for business and good for the company. So, what are some ways that you've done that? And what benefits have you seen of doing sort of what Mac is trying to do right now within Commsor? +CHAD: I don't know that I've been super intentional about this. It just came naturally, as we're all people who would do this, right? Like, you can't stop us from doing it. And so, I mostly just try to create an environment where you're not stopping people from doing things that they would normally want to do anyway. And to then recognize when, you know, someone else goes and creates open source, or a blog post, or speaks at a conference, or whatever. That comes back to benefit us through the reputation that it builds and the community that it builds. +And I think a lot of organizations and teams and everything do a really good job of getting in people's way from doing things [laughs] that they would want to do. And so, that's really all I've tried to do is not get in people's way. +MAC: I've spoken to a lot of people who are, like, under the impression that their company owns their LinkedIn account, which I always think is super interesting, or companies who, like, go out of their way to be like, "No, you can't speak about, I don't know, that you like barbecuing," or, like, well, you can't, like, be a person. You have to, like, you are just a representative of the company. And it's so stupid. +It's, like, 90% of the growth we have is either word of mouth or people referencing that they've, like, built a relation or a connection with someone on our team, not just me, but, like, Ben or Katrine on our team, like, people like them. And then they want to learn about Commsor because they get to know them. +And I think there's this old model where, like, if you just draw, like, circles, right? Like, here's the company, and here's people. It used to be here's the company, and then all the people are inside of it. But more and more, like, the way we're trying to build it is, like, you have, like, the people are a ring around the bubble that is the company. It's like, the people actually are the kind of that first interface, which is always what it is anyways, whether companies act that way or not. +At the end of the day, people are the interface. But so many companies try to control that and, like, you know, put everyone through this, like, brand voice funnel that just...it just doesn't work. Yeah. +SALLY: Yeah. Well, and it's ironic because I've heard so many sales leaders harping on people buy from people. People buy from people. And then they don't allow their salespeople to actually go be a human being and a person in any sort of a public [laughs] forum like LinkedIn. I've had that same conversation with so many sales folks that I've worked with, you know, over the years, especially the last few years, where like, oh, I feel like I could really put some great stuff out on LinkedIn, build some relationships, but I just I feel sort of stifled from doing that for fear of reprimand, or losing my job, or whatever it is. +So, I definitely appreciate that, at thoughtbot, I don't feel that. I have felt that in the past in some roles, but I don't feel that here. And I'm just so grateful that I feel empowered to go share my thought leadership and things like that on LinkedIn. And it's interesting because that has yielded opportunities that I wasn't even looking for. So, yeah, I'm curious, Chad, if you've also seen things that we weren't necessarily looking for happening that way. +CHAD: I do. As you were talking, though, I was just thinking, this is harder than it was before. Like, you may be excited to talk on LinkedIn [laughs], but I would say the number of people at thoughtbot who are actually excited to do authentic stuff on social media these days is way, way down. And it's been trending down for years, and it's particularly bad these last couple. And, you know, we have the kind of culture where we don't force people to do it. +Is that something that you've seen, Mac? It's, like, individuals' sort of engagement, willingness? I think a lot of social media is just a mess right now, that kind of thing. And how is that affecting what you see in your strategy? +MAC: Yeah, I don't think...it doesn't have to necessarily be social media, like, once again, the browser company example of, like, the update videos including people in it, right? It's like it's...there's ways that the company can intentionally elevate their people first, rather than being like, "Oh, yeah, here's social media, like, have fun. Go build a brand. Please do free marketing for us." Because that's kind of, like, what you're subtly hoping happens if one of your team members builds an audience on Twitter or LinkedIn. You're like, cool, we'll get, like, the splashover effect. +I would say, right now, about 25% of our team is doing it really well without us prompting. Like, they just want to do it, and they're leaning into it and enjoying it. 25% want to do it but maybe aren't sure how or where. And we've actually, like, built systems internally to help, like, build, like, you know, give them the space to do it and whatnot. And then, half are just like, yeah, I'm not doing that. I don't have any interest at all. +CHAD: For me, it's more that you don't need to do that just because someone else is doing it. But that doesn't mean you shouldn't try to find the thing that you're passionate about and the way that you can find your voice or a thing to contribute to, even if it's an external sort of open-source project or something like that. +MAC: Yeah, I mean, we have things like it doesn't have to be tied to the company. Like, a great example...so, Katrine, who's our head of sales, and my sister [laughter]...I guess I should -- + CHAD: Full disclosure. +MAC: Like, put a little asterisk, you know, on there as well, yeah. Not why she has the job, but just happens to be that way. So, she actually started running this, like, Women in Revenue meetup with Gong, another company, with this other woman Ashley, like, almost two years ago, like, after she started Commsor. It wasn't tied to Commsor or, like, it wasn't tied to our business or anything like that. And then she came to me, like, a year ago and was like, "Oh, me and Ashley want to start our own podcast. What do you think?" +And we ended up actually, like, funding the podcast. Like, we pay for the editing, the hosting, like, all of a sudden, they need to, like, do it. And yeah, so we get to [inaudible 32:30], like, yeah, this podcast is, like, presented by Commsor, even though it's like Katrine and Ashley's podcast. We're, like, the permanent sponsor of it, basically. But it's been interesting. +And now it's like, and now she's involved in this group called Wednesday Women where it's like, she wants to elevate other women in revenue roles. That's not what Commsor's mission is. I'm not saying we don't believe in it but, like, that's not the reason Commsor exists, right? But we were like, yeah, we gave her the space to do it. There has been so much good that has come to Commsor from that, from her running her own meetups, hosting her podcast, building a brand around that, elevating other women. +Like, the amount of people who come to us and want to learn more about Commsor or [inaudible 33:05] want to work with us, whatever, because of the stuff she has done on a thing she cares about outside of work, I mean, it's obviously very tied to her work still, but it's not. It's not Commsor marketing. It's not for Commsor. It's not backed by Commsor, like, in an official capacity. +So, there are ways that, like, if people have those passions, like you said, it'll bring people who are like-minded, who will get to know them, who then inherently want to be like, "Oh, well, I love what Katrine is doing. What does Katrine do at Commsor? Oh, cool. What does Commsor do?" Like, you know, it's like, there's a funnel. Like, not everybody will follow that path. But a not insignificant portion of the people that are aware of our brand have come in through that path. +CHAD: And this is a good example of something that I talk a lot about is, is that the most effective thing that could probably happen? Probably not. But I would rather someone do the thing that is 60% effective and 100% fulfilling to them than doing something that is soul draining that they don't want to do that's 99%. +MAC: Well, I'll also counter that they will show up and be a better employee and team member because they're...it's like, so even if they're, like, doing less by the numbers, long term, they'll do more, like, especially in sales, right? Like, SDR culture has been this, like, you basically grind it out for 12 months, maybe 18 months as an SDR, and you hope that you make it to the AE role, and if you don't, not very many people...you don't become an SDR for ten years. It is not a career. It is a stepping stone of, like, I'm going to stick my face in the boiling water. I'm going to deal with it. I'm going to suck it up, and hopefully it pays off in the long term. +And, like, a huge percent of those folks end up churning out into customer success roles or completely different industries or whatever because it's, like, no one wants to keep their face on the grindstone for that long. But by, like, building a sales and a marketing system that's actually enjoyable for the people that are doing it, one, they bring their authentic selves to work, which means they're more likely to do it. They're more likely to stick around. They're more likely to have fun with it. And when they're having more fun with it, that also reflects on the people in the market because people can tell. People can tell that Commsor is having fun. +Like, it sounds kind of dumb, but I think especially in B2B, like, having fun is actually kind of a competitive advantage. And I don't mean fun in the sense of, like, oh, we post memes on our LinkedIn account. Like, that's not, like, corporate fun, but, like, actually, like, real people personalities showing through the work fun, like the dinosaur thing, right? +Like, I think my entire LinkedIn personality now is, like, anti-bad sales tactics, and dinosaurs are cool, which is also sad and kind of counterintuitive because, like, bad sales tactics are also things that dinosaurs [inaudible 35:40] [laughter], sort of a, like, sort of a funny play on things. But, like, I think my LinkedIn bio is: DM me for a fun fact about dinosaurs. It's not what we do at Commsor. It's not trying to pitch you on anything. +And I have had so many conversations where someone's just like, "I want a fun fact about dinosaurs." I'm like, "Sure. All right, cool. Like, here you go." And sometimes, it ends up going further. And, you know, maybe Commsor comes up naturally. Other times, they're like, "Cool. That's an awesome fact that made my day, thanks," and then that's it. That's the end of it. But when you can enable those personalities, and that authenticity, and that fun to show through the work, both sides benefit. +And when you're talking about things that don't scale, whatever, that's one of the classic pushbacks I get. - It's like, "Well, how does this, like, go-to-network relationship selling, how does it scale?" They're like, "I need to close 100 deals this year. I got to scale." It's like, I did a graphic...I can't remember the exact numbers, but looked at, like, you know, the stats on cold calling, for example. And it was like, to get one deal, you need five meetings because, on average, industry-wide in SaaS, 20% of those meetings become deals. +To get five meetings, you have to cold call 250 or more individual accounts because that's how many, on average, it takes with cold call rates. But on average, it takes seven to eight cold calls to actually get someone to answer. So, I have to call Sally eight times to get an answer. So, I have to make over 2,000 cold calls to end up with one meeting. It's just insane. Whereas if you look at like relationship selling, warm intros, and warm paths like that, they close at a 78% rate across the board. +So, it's actually like, okay, I can go out and get a pool of 250, 500, 1,000 contacts and try to get four leads, or I can go build relationships with ten people and get four deals that way. It's like, you don't need it to scale in the same way if you're building with that. The problem is that sales and marketing over the last decade have been built on the predictable revenue model. If I make X cold calls, I'll get X meetings, and I'll book Y deals. So, everyone is like, okay, it's scalable. If I want to close twice as much revenue, I need twice as many SDRs making twice as many cold calls to close twice as much. That just doesn't work anymore. +The whole model that startup growth has been built on for ten years it doesn't work. I mean, even if you look at, like, the IPOs of tech companies over the last decade, it's like less than 5% of them have been consistently profitable for the last three years. So, if we're all trying to build our companies and everyone's like, ooh, look at the way that XYZ, Uber, or WeWork, whatever, did over the last ten years, they actually haven't worked. +We've been trained and tricked on this system for 10, 15 years of, like, growth is everything. But, like, I don't know, just look at WeWork over the last month, right? Like, that's the shining star of, like, does it matter? Like, you can grow to a billion dollars in revenue. But if you're losing a billion to make a billion, the company making 20 million and spending 5 million to make that is actually a better company. +CHAD: Yeah. It's totally...some people that is what they want. But it does change your motivation when what you're trying to do is create a company that you enjoy working at that maybe isn't taking over the world but making a positive contribution to it. That changes your approach. +MAC: Yeah, you're not trying to consume everything in sight. There's a lot of different ways to do it. And yeah, I think the last ten years, especially in startup and SaaS land, have tricked a lot of people into thinking there's only one way to do things, and it's throw money in a grinder and hope to God that you get more money at the bottom of it than you put in the top of it, even though 99% of the time that's never the case. +CHAD: Well, Mac, thank you so much for joining and sharing with us. If folks want to find out more about Commsor or get in touch with you, what are all the different ways that they can do that? +MAC: Well, they can DM me on LinkedIn for a fun fact about dinosaurs before they ask what their real question is. It's just Mac Reddin. I think I'm the only one on LinkedIn with that name, so it shouldn't be too hard to find me. I'm the guy with the dinosaur emoji next to my name, just to really lean into it. +Yeah, and then Commsor, it's commsor.com. We're, like, just now starting to reveal what we've been building over the last six or nine months with our pivot into this go-to-network world. So, we're early on that front. But you can keep your eyes peeled, and there'll be more to see over the next few months. +CHAD: And Sally, thanks so much for joining today and help facilitating the conversation. I really appreciate it. +SALLY: Absolutely. It's been really fun. +CHAD: If folks want to get in touch with you or follow along, where are the places they can do that? +SALLY: I am all up in LinkedIn, so feel free to hit me up there. That's probably the best place. Also, if anybody out there ends up using Commsor, you can also find me in the Herd, which is the community that Mac has built, so feel free to find me there as well. +CHAD: And you, listener, can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon at cpytel@thoughtbot.social. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and see you next time. Special Guest: Mac Reddin. + + + Mac Reddin is the CEO of Commsor. He discusses Commsor's evolution from community-led growth software to a go-to-network model, emphasizing the importance of various overlapping networks in a company's ecosystem. He shares his journey from running a Minecraft-based company as a teenager to founding Commsor, which initially began as a newsletter and evolved into a community and then a product.

+ +

Mac stresses the effectiveness of authentic community building and relationship-based growth over traditional sales and marketing strategies. He criticizes cold calling and email tactics, advocating for genuine interactions and relationship-building. Commsor’s approach, including personal onboarding of every user and fostering a company culture where employees are encouraged to express their individuality and interests, has shown success and satisfaction internally and in the market.

+ +

Chad reflects on his experiences at thoughtbot, aligning with Reddin's perspective on community and user-centric approaches. He emphasizes trust and freedom within his team, allowing for authentic individual contributions to the company's growth and reputation. Together, they discuss the importance of personal connections in business and how modern sales tactics might need reevaluation in favor of more genuine, relationship-based approaches.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me as co-host today is Sally Ladrach, Revenue Enablement Manager at thoughtbot, great company I've heard of. Sally, thank you for joining.

+ +

SALLY: Yeah, thanks for having me on.

+ +

CHAD: And also joining us today is Mac Reddin, Founder and CEO of Commsor, which builds tools to help individuals and companies of all sizes grow faster, more authentically, and more sustainably through the power of go-to-network. Mac, thanks for joining us.

+ +

MAC: Thanks for having me.

+ +

CHAD: Mac, can you tell us a little bit more about what Commsor is and how you sort of arrived at creating it?

+ +

MAC: I struggle to do that every time someone asks me. It's always, like, a slightly different answer. So, we're about four years old now. But we kind of pivoted, soft pivoted, depending on how you want to look at it, into what we're doing now at the beginning of this year. So, we're kind of not that new and very new, depending on what perspective you look at.

+ +

We were originally building what we called community-led growth software. So, we were helping companies measure their community as an intentional part of their go-to-market initiative. And there's a whole rabbit hole on why we changed, and how we changed, and how we ended up where we are now.

+ +

But I think go-to-network is sort of an evolution of community-led from this realization that companies don't have a singular community. They might have a, you know, a forum, or a Slack, or a community manager, and there's, like, it's very easy to be like, that is their community. But in reality, there's influencers, investors, creators, advisors, personal brands, executives, champions, customers, community members, like, all these different overlapping networks, hence go-to-network, that actually make up this sort of ecosystem that enables a company to thrive.

+ +

CHAD: Now, did you have a community, or, like, did it grow from something, or did you just have the idea?

+ +

MAC: I started my first company when I was 17; built on top of Minecraft, and it was very community-centric, and I didn't really realize at the time. But I got lucky enough to sell that business. And, you know, after looking back at all the hats I've worn running a, you know, a tiny, bootstrapped company, I realized the community management part had been what I enjoyed the most and that the community part had been the kind of competitive advantage of that business. And that sent me down a path of thinking about community and business more intentionally after having kind of stumbled into it as a, I guess, late teenager.

+ +

So, Commsor started...originally, I knew I wanted to build something in the community space. So, we actually started...it started as a newsletter, actually. It was a substack called Community Chat Weekly, which was just, like, an aggregation newsletter as I was, like, doing research into the more professional community world. And then it became a small Slack community, which then became the community club. And Commsor, as a product, was born out of building a community for community people and just diving headfirst into that world.

+ +

SALLY: So much community, I love it [laughs].

+ +

MAC: Yeah. I try to say, like, a couple of different words, like world or something instead of community.

+ +

SALLY: [laughs]

+ +

MAC: And just, like, we used to joke that we were a community company for community people, by community people, with a community of community people.

+ +

CHAD: [laughs]

+ +

MAC: I was, like, just too much of the same word [laughs].

+ +

SALLY: I love that. So, it's interesting. One of the reasons why I really wanted to get you and Chad together, in particular, is because the whole go-to-network motion that you're so passionate about and that you've built this product around very closely aligns with how Chad has really led and grown thoughtbot over the last 20 years. And I thought it would be so cool to bring those perspectives together.

+ +

And one of the things that you mentioned around community was that it gave you a competitive advantage. I'm curious to know, Chad, does that resonate with you? Have you seen that in thoughtbot over the last, you know, couple of decades as you've been doing this?

+ +

CHAD: Yeah, definitely. I mean, one of the things that is my sort of go-to talking points, both at conferences and that kind of thing, is that one thing that has been really a big part of thoughtbot's success is being willing to be clear about who we were and what we believe. And when we do that, then the people who want what we have and believe what we believe and are excited by that can find us and, you know, follow us. And, eventually, when they're in a position to need help, we're top of mind.

+ +

And this idea, I think, holds back a lot of companies because you think your market is the total addressable market. And the reality is you're never going to work with the total addressable market. So, you're better off finding the people who believe what you believe in your niche and your community. And being that big fish in that small pond has been really beneficial for us.

+ +

SALLY: That's awesome. Yeah, I think it was kind of a culture shock, honestly, coming to thoughtbot because I had been so immersed in sort of the SaaS world and the mass outreach, cold outreach, sort of, I want to say, traditional go-to-market motion that's been used over the last ten years. And I came here, and there were so many things that thoughtbot did or didn't do that I just was honestly kind of shocked, you know, as an example, not using third-party cookies on our website [laughs].

+ +

And, Mac, when we were talking, it sounded like you're also doing some of those things that we joked might make a CRO cry [laughs]. So, I was curious to ask what some of those things were and see how that kind of matches up to what thoughtbot is doing in our approach, too. I'd be curious to know.

+ +

MAC: There are so many things. I mean, I get CROs all the time, not, like, yelling at me, but I get the whole like, "Young man, you don't understand how sales works," type comments all the time. I got one recently that was, "Don't talk about sales until you've sold in a recession." It was like, what do you think we've [laughter] been doing the last 18 months? But okay. But yeah, so we don't do cold calls. We don't do cold emails. We don't do any of that traditional stuff that software companies do.

+ +

And I guess you all as a, you know, more of a, like, service-based product, as a founder building a software-based product, more than half of the cold outbound I get is, like, developer agencies and stuff like that. It's, like, the classic scourge of outbound in a lot of ways, right? So, there's an element of, like, zigging when everyone else zags. And one of my favorite stats...I can't remember the exact number, so don't fully quote me on it. But --

+ +

CHAD: It's not like we're recording or anything. It's totally fine.

+ +

[laughter]

+ +

MAC: Yeah, well, I mean, I think the gist of the message is more important than the exact number. And it was a stat that there's been a 100x increase in prospecting activities over the last decade. So, for every cold email, cold call, in-mail ad impression that you would have seen ten years ago, you now get 100 as a buyer.

+ +

And I always say this thing to people; I'm like, it doesn't matter how good your outreach is. You can have the best well-crafted cold email, cold call; your timing can be perfect; everything could be right: relevance, timing, everything. The problem is, increasingly, buyers have been so pissed off at the deluge of shit they've gotten for ten years that it doesn't matter. Like, my phone does not ring if I don't have your number. I am physically uncoldcallable.

+ +

And I've talked to a lot of CROs, and they're like, "Well, we'll just, you know, marketing will get your lead some other way. And then they'll pass it over to us, and we'll still get to you." And it's like, okay, like, that doesn't really solve the problem. So, like, there's a lot of these weird things where sales and marketing aren't aligned. They expect each other to solve the problem for each other. They're pure volume-based, and we don't do any of that. And a lot of CROs and a lot of VPs of sales love to point out how wrong we are for that, but it's working so far.

+ +

And also, it's so much more enjoyable to build a company that way. Like, our salespeople, our SDRs, and all that stuff, they don't hate their jobs. They're not, like, sticking their face to the grindstone every morning and being like, "Oh yeah, I got to play pump-up music before I go to work. Otherwise, I'm not going to get through the day." It just creates a better work environment. It's better for us. It's better for the buyers. It's better all the way around.

+ +

CHAD: So, for thoughtbot, I know that a lot of this has come naturally for us because, as developers and designers, we've produced a lot of open source that flows from our work that then builds community around it. We write on a blog, which we're very fortunate to have a lot of people read over the years, which fosters reputation for us and community around it. But what does that look like for other companies who maybe aren't, like, an agency like us doing that kind of thing? What are the kinds of things that it looks like?

+ +

MAC: I think you hit the nail on the head earlier when you said it's about, like, showing off who you are and what you believe in and creating space so people can come to you. But in the, you know, the high growth SaaS world, the last ten years, people have not been a fan of waiting for people to come to you. It's, like, grow at all costs, blitzscale, all that sort of mentality.

+ +

For us, the way it looks is...I guess an example–so, we did this sort of semi-accidental campaign on LinkedIn over the last, I guess, two and a half months with these purple hoodies. And there's a whole backstory. They were an accident, and we were like, "Shit, we have too many hoodies. What do we do with them?" So, we made a thing out of them. And we thought we were going to get 25. We ended up getting 250 [laughter]. It's a whole thing.

+ +

We just started, like, we sent them to a few folks, and someone posted a photo without us asking being like, "Look at this awesome hoodie Commsor sent me." And their post went, like, insane. Like, by LinkedIn standards, it went insane. It was, like, 100 comments. Like, "How do I get one? Oh my God, I love it. It's so cool. Can I get one?"

+ +

So, we just started sending them to people, like, no goals, no intention, just brand building, just building connections, building relationships. I personally, from hoodies that I can attribute, have booked over 200 calls about our product with our ICP doing that without trying to. There's almost this element of, like, by not trying to sell, it's become easier to sell. There's, like, an element of like, I'm just sending you a hoodie because I think you're cool, and I want to get to know you.

+ +

And it's a fine line because I think a lot of companies try to do that. But you can always tell there's an undertone of, yeah, I'm sending you these cookies because, like, I'm really hoping you get on a sales call with me. But we genuinely were, like, we have too many hoodies. We're just trying to get rid of them. I don't want to pay to store them. Like, please, I'm begging you, please take our hoodie.

+ +

SALLY: [laughs]

+ +

MAC: And then, it just turned into this, like, whole FOMO game. It's like the authenticity was purely there. All in all, we spent about, including shipping, everything, like, $8,000 on hoodies, so not a tiny amount of money but also not huge by marketing budget standards. And I had a conversation with a CMO recently. He was like, "You should have just spent LinkedIn ads. That's such a waste of money. You can't track it. It's not attributable," et cetera. I was like, "We've gotten, I think, close to a million impressions on LinkedIn of people posting our hoodies talking about us. We couldn't have paid for that."

+ +

So, there's, like, this whole area where it's like, if you actually just go out there and build relationships, build community, get to know people, tell them what you believe in, yeah, people will not agree with you. Like, when I say I think modern go-to-market is broken and the way people sell is broken, I get a lot of sales leaders who are like, "You're an idiot. Like, that's wrong. You objectively don't know what you're doing. You've never been a salesperson by title. Don't spread this shit."

+ +

But then you get a lot of people who are like, "Yeah, you're right. It's not working. I want to hear what you have to say. I want to talk to you. I want to brainstorm with you." The amount of times that I get DMs from salespeople who are like, "Hey, I totally agree with that post you just wrote, but I can't publicly because my VP of sales is going to read me out if they see me agreeing with you. But like, yeah, this shit doesn't work anymore," like, 10 to 20 times a day, I get messages like that.

+ +

SALLY: And as a consumer of LinkedIn feed, you know, I've been following Mac for a while, but also follow a couple of other folks at Commsor and people who are in their networks. I can 100% validate that the Dino Hoodie is, in fact, now a status symbol on LinkedIn. So [laughs], I thought that was, you know, brilliant. And I'm not going to lie; I had some FOMO, too. I was like, where's my Dino Hoodie? And, in fact, when I talked to Mac, I was like --

+ +

CHAD: [laughs]

+ +

SALLY: I know that we just met, but can I get one of those? [laughs]

+ +

CHAD: I see now. This was just a ploy to get a hoodie.

+ +

MAC: I've gotten, like, reverse sales now. It's like, you know, you get pitch slapped on LinkedIn, or someone adds you, and right away, they're trying to sell to you. I've gotten that. [laughter] But they're trying to convince me to give them a hoodie. Like, somehow, we've created the reverse thing where, like, salespeople are reaching out to me to reverse pitch–so I can give them something.

+ +

SALLY: That is hilarious. And I promise that was not my intention; was just to get a hoodie from you. But there's so much there that I think would be interesting to unpack. Chad, I'm just kind of curious to know your impression of what Mac has shared around the sort of flak that he's gotten around, you know, what you're doing isn't going to work, or whatever. Have you gotten any of that over the years? Are you surprised to hear that? Just interested to hear your thoughts.

+ +

CHAD: No, I think it happens when you are willing to put yourself out there with an opinion, with a belief. And it's going to resonate with the people that it resonates with. And the flip side of that is there are going to be people who believe that you're wrong. You know, when we were doing very early on with test-driven development, for example, it was not an established industry practice. You could find blog posts from people out there saying. "It's bad. We tried it at my startup and our product failed, and it was too slow. It held us back from being successful."

+ +

But the people who believe in it...if we were the only company in Boston who was doing it and a company that believes in test-driven development was never going to work with a company that didn't do test-driven development, so we were the one company that they could work with because we believed in the same practices.

+ +

And that's the hard thing in that is, usually, if you're on the right track to finding the right niche or to the right belief that's going to really resonate with a group of people, the people that you're turning off is probably going to be a louder, more vocal group. And so, being strong in the face of that is really important.

+ +

And I'll also just call out that, like, this is one area where it's easy to say, "Well, this works because you've been successful." There are other founders probably who, like, they have a legitimately bad idea. And they ignore all the sort of haters, and they say, "Oh, those are just the haters." And yet they don't get the success because there wasn't the people out there who actually did believe what they believe or had a need for the product that they were creating, or something like that.

+ +

And I think it's important to ignore the noise or to push past the noise, but you do need to let it in a little bit so that you understand whether you're on the right track at all, I've found. What about you, Mac?

+ +

MAC: Yeah, it's a never-ending battle to know what to listen to, and what to ignore, and how to apply it or if to apply it, and things like that. I agree. I think there is an element of, like, it's like, what's that [inaudible 14:47] saying? Like, if no one thinks you're crazy or wrong, you're probably too late as well with your idea, right? Like, if you're like, "Here's my idea," and everyone's like, "That's a great idea," It's been done. You're very late to the party at that point.

+ +

There's no, like, right or wrong answer because there's always context. You always know your idea and your business, hopefully, better than anybody else does. So, you can't just, like, take other people's advice. I actually went through a whole period (It's like sort of a sidebar.), but where I was, like, impostor syndrome as a, you know, venture-backed CEO. I was like, oh, I got to, like, be the founder and run the company the way other people run companies at this stage. And it, like, objectively, almost killed us as a company.

+ +

I have lived both sides of that extreme of like, being like, "No, I'm not going to listen to anybody's advice," and the negatives and positives of that, and the "I'm just going to follow everyone's advice and do what they say," and the negatives and positives of that. And now somewhere, maybe not quite in the middle, maybe a little bit leaning towards the ignore the advice because I believe in what we're doing.

+ +

CHAD: And you need to actually believe what you're saying. I think this is the wrong tactic to take if you don't actually believe it.

+ +

SALLY: [laughs]

+ +

CHAD: Because if it's not authentic to you, it's going to be really hard to build an authentic community and message and those kinds of things, yeah.

+ +

MAC: People can tell.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

SALLY: One of the things that you had mentioned before was sort of the technology that you've built Commsor on. And it was an interesting choice to me because it's not one of the more, you know, flashy or hot, new sort of programming languages that's out there. So, I was just kind of wondering, what is it? And why did you make the decision to build out the actual tool the way that you did?

+ +

MAC: So, I definitely have to, like, put a giant asterisk over everything I'm about to say. I am not a technical founder [laughs]. So, like, anything I say here is just potentially wrong [laughter]. [inaudible 17:20] The decision was made because I had, you know, a great team that we put together and trusted them to make the decision, and that's the decision we've made. So, I mean, the bulk of the app is built on just, like, Ruby and React. It's pretty straightforward.

+ +

We have had people be like, "Well, you should be using this," you know, whatever "Next.js, plus this, plus this, you know, it's better." But, like, the team we have, they've worked together in the past. So, they actually came into an acquihire. So, we're like, basically, like, you know, they'd worked together for three years in a company. They have systems in place.

+ +

And at this stage, it's, like, debating what tool you're going to use when you start, like, just 99.9% of the time does not matter. There's no idea...you don't even know if it's going to work, the product, right? It's, like, and your customers don't care. Your customers don't care. Unless you're building a dev tool and it's, like, hyper-specific, but even then, they probably don't really care that much. So yeah, we have a good team. I trust them to make the decision. And it's what they know and what they're familiar with. So, instead of trying to reinvent the wheel, we just went with the thing that would let us get things done the fastest.

+ +

SALLY: Chad, I'm interested to know...the trust factor that you mentioned, Mac, is really key to a lot of thoughtbot's success. I think that one of the things that Chad has done well as he's grown the company is hired great people and then trusted them to get the job done however [laughs] they thought that it might best be done. So, Chad, I'm curious to know: whether you're deciding on a tech stack or how you're going to go to market or anything like that, what has the impact of trust been at thoughtbot as you've grown and scaled the company?

+ +

CHAD: I think trust is one of [laughs]...I think it's very important. It's one of our core values. And, for us, that comes from not just trust being a nice thing to have. It's the one value that I can also point to and say I intentionally created an environment of trust.

+ +

I've been doing freelancing and consulting for a long time, even before thoughtbot. And I knew that at thoughtbot, we were going to continually form and reform teams of people that hadn't necessarily worked together closely before. And that if every time we did that, we were going to have to be building trust with each other, that it would detract from the success of the product that we were trying to create and from the relationship that we were needing to build trust on urgently which was with our new client.

+ +

And so I tried really hard to create an environment where when people show up on day one, everyone inherently trusts that they belong there and trusts them. It's not easy, and it's not perfect. But I think we've made a lot of progress on that. And then, when you have that kind of environment, recognizing that it changes the way that you work with each other. And so, when it comes to, like, technology decisions and everything, I mean, that is essentially how we work is understanding that everyone has trust of each other and that when you are put in a position to make a decision, it is your decision to make.

+ +

But part of making decisions and part of having a trusting environment is communicating with each other. So, even if you're responsible for making the decision, part of your responsibility, then, is for bringing everyone else along with you. And sometimes that means setting up an environment where, okay, the results speak for themselves. But other times, it means educating people about, "Here's what we're going to do, and here's why," even if it is as simple as "This is what we know. We've been doing it for three years, and let's just get right to it."

+ +

I don't know if that directly answers your question. But it's a big part of how we've done things and tried to create the culture that we've created. And I happen to be biased, but Ruby is a great choice.

+ +

SALLY: [laughs]

+ +

CHAD: I think it's taken for granted because it has been around for so long. But I talk about strong beliefs. I am up to speed on lots of web development frameworks and the ways that you build applications across a variety of different platforms, and tech stacks, and that kind of thing.

+ +

We didn't choose Ruby on Rails because we thought it was going to be popular back in 2005. We chose it because it fundamentally was the best way that we could see, out of all the platforms at the time, to build web applications. It allowed us to do things in one line that normally would have, at the time, taken 20. And that allowed us to be faster and work the ways that we wanted to work. And embedded in that culture is things like testing and test-driven development, which we also believe in.

+ +

The simple fact of the matter is there hasn't been a paradigm shift in web frameworks that is actually fundamentally better in the way that Ruby on Rails was better in the early 2000s. So, you can choose something else, but it's not going to be significantly better than Rails in terms of productivity, in terms of what it can do for your early-stage product.

+ +

It basically just then comes down to there's choices you can make that will slow you down, definitely, in terms of architecture and everything in other platforms. But yeah, you can't go wrong with Rails, and you can't really go wrong with Ruby. And you can't go wrong with choosing what you know and what you're comfortable with, especially in the early days.

+ +

SALLY: Yeah, I love that. One of the themes that I'm sort of hearing from both of you in how you've approached building tools; building your business is putting users at the center. And, Mac, I know you were saying, you know, I have all these CROs coming at me, right? Like VPs of sales being like, "The way you're approaching things isn't going to work. It's dumb; it's stupid."

+ +

But then you also have these salespeople DMing you like, "Hey, I agree with you. I just can't say it out loud because I might get in trouble." And, ultimately, that salesperson really is your user, right? Because they're the ones that are building their network, that are leveraging it to then go get the sales for the company.

+ +

So, I thought it was interesting that sort of that user-centered approach was something that was coming out with both because I know for Ruby, in particular, it's very well-loved by developers that use it. It's, like, a very developer-friendly sort of language. And so, I'm just wondering, you know, how do you, Mac, continue to keep users at the center when you have voices coming at you, when you have [laughs], you know, people telling you you're doing it wrong? What are some things that you do tactically to make sure that you stay aligned?

+ +

MAC: I mean, the simple answer is talk to them all the time. We actually...every single user who gets onboarded to our product right now gets an introduction to me directly. That's part of, like, seeing how the product works as well. But every single user ends up speaking to me. Who knows if that'll scale? But right now, it's like, I have spoken for at least 30 minutes with every single person we've onboarded to our product. We onboard every user by hand right now, which is totally counterintuitive for the price point our product's at.

+ +

But it's been really helpful to build that relationship, build that trust, get the research and the understanding of what we need to do next really quickly, have tight feedback loops. We have, like, I Dm users all the time. Like, I [inaudible 24:28] I probably have 50 to 60 unique DMs on LinkedIn per day. And someone was telling me like, "That's a waste of time as CEO and founder." I'm like, it's literally the only thing that matters. I'm talking to users, hearing what the market is saying, like, hearing all that live, not hearing it from people.

+ +

We're also working on, right now, enabling anyone on our team to do an onboarding so that when we do scale, my goal would be that every person on our team, from an engineer to a success person to the CEO, would be onboarding a customer at least once every few weeks just to maintain that closeness and that connectedness. We're also working on things... I'm a huge fan of...do you know Arc browser?

+ +

SALLY: I'm not familiar, no.

+ +

CHAD: I haven't used it, but I am familiar with it, yeah.

+ +

MAC: I'm using it right now.

+ +

CHAD: [laughs]

+ +

MAC: Highly recommend. Not an ad, I promise; just a fan. But they do, like, little things that they do, for example, like, when they would change log, instead of being written or instead of being just a CEO, it'll be like, "Here are the four new things released." And the first thing is, "Oh, here's Mac, the developer who worked on this feature sharing it. And here's, you know, this person who worked on this feature."

+ +

So, it's like, each individual person becomes the face of the thing they worked on, rather than just like, oh, it's the faceless company, or it's, like, it's always the same, like, spokesperson who's always talking about it. So, enabling it to not just be me who talks to users all the time but the whole company enables the whole company to be more user-centric.

+ +

SALLY: That's so interesting. Again, there's, like, so many parallels between how I've seen thoughtbot approach things and how you're approaching things with Commsor. When you mentioned that your goal is to sort of make it so that several different people are the face, and it's not just like, oh, Commsor is Mac only [laughs], that's something that I think I've seen Chad do throughout the years.

+ +

So, Chad, do you have any examples of sort of how you've tried to scale the company, putting different faces and putting our experts out there, trying to make it so that thoughtbot is not, like, the Chad show? Because I feel like that's one of the things that, you know, you're great [laughs]. But I think that the fact that we have so many contributors to communities and people speaking at events has been really, you know, just good for business and good for the company. So, what are some ways that you've done that? And what benefits have you seen of doing sort of what Mac is trying to do right now within Commsor?

+ +

CHAD: I don't know that I've been super intentional about this. It just came naturally, as we're all people who would do this, right? Like, you can't stop us from doing it. And so, I mostly just try to create an environment where you're not stopping people from doing things that they would normally want to do anyway. And to then recognize when, you know, someone else goes and creates open source, or a blog post, or speaks at a conference, or whatever. That comes back to benefit us through the reputation that it builds and the community that it builds.

+ +

And I think a lot of organizations and teams and everything do a really good job of getting in people's way from doing things [laughs] that they would want to do. And so, that's really all I've tried to do is not get in people's way.

+ +

MAC: I've spoken to a lot of people who are, like, under the impression that their company owns their LinkedIn account, which I always think is super interesting, or companies who, like, go out of their way to be like, "No, you can't speak about, I don't know, that you like barbecuing," or, like, well, you can't, like, be a person. You have to, like, you are just a representative of the company. And it's so stupid.

+ +

It's, like, 90% of the growth we have is either word of mouth or people referencing that they've, like, built a relation or a connection with someone on our team, not just me, but, like, Ben or Katrine on our team, like, people like them. And then they want to learn about Commsor because they get to know them.

+ +

And I think there's this old model where, like, if you just draw, like, circles, right? Like, here's the company, and here's people. It used to be here's the company, and then all the people are inside of it. But more and more, like, the way we're trying to build it is, like, you have, like, the people are a ring around the bubble that is the company. It's like, the people actually are the kind of that first interface, which is always what it is anyways, whether companies act that way or not.

+ +

At the end of the day, people are the interface. But so many companies try to control that and, like, you know, put everyone through this, like, brand voice funnel that just...it just doesn't work. Yeah.

+ +

SALLY: Yeah. Well, and it's ironic because I've heard so many sales leaders harping on people buy from people. People buy from people. And then they don't allow their salespeople to actually go be a human being and a person in any sort of a public [laughs] forum like LinkedIn. I've had that same conversation with so many sales folks that I've worked with, you know, over the years, especially the last few years, where like, oh, I feel like I could really put some great stuff out on LinkedIn, build some relationships, but I just I feel sort of stifled from doing that for fear of reprimand, or losing my job, or whatever it is.

+ +

So, I definitely appreciate that, at thoughtbot, I don't feel that. I have felt that in the past in some roles, but I don't feel that here. And I'm just so grateful that I feel empowered to go share my thought leadership and things like that on LinkedIn. And it's interesting because that has yielded opportunities that I wasn't even looking for. So, yeah, I'm curious, Chad, if you've also seen things that we weren't necessarily looking for happening that way.

+ +

CHAD: I do. As you were talking, though, I was just thinking, this is harder than it was before. Like, you may be excited to talk on LinkedIn [laughs], but I would say the number of people at thoughtbot who are actually excited to do authentic stuff on social media these days is way, way down. And it's been trending down for years, and it's particularly bad these last couple. And, you know, we have the kind of culture where we don't force people to do it.

+ +

Is that something that you've seen, Mac? It's, like, individuals' sort of engagement, willingness? I think a lot of social media is just a mess right now, that kind of thing. And how is that affecting what you see in your strategy?

+ +

MAC: Yeah, I don't think...it doesn't have to necessarily be social media, like, once again, the browser company example of, like, the update videos including people in it, right? It's like it's...there's ways that the company can intentionally elevate their people first, rather than being like, "Oh, yeah, here's social media, like, have fun. Go build a brand. Please do free marketing for us." Because that's kind of, like, what you're subtly hoping happens if one of your team members builds an audience on Twitter or LinkedIn. You're like, cool, we'll get, like, the splashover effect.

+ +

I would say, right now, about 25% of our team is doing it really well without us prompting. Like, they just want to do it, and they're leaning into it and enjoying it. 25% want to do it but maybe aren't sure how or where. And we've actually, like, built systems internally to help, like, build, like, you know, give them the space to do it and whatnot. And then, half are just like, yeah, I'm not doing that. I don't have any interest at all.

+ +

CHAD: For me, it's more that you don't need to do that just because someone else is doing it. But that doesn't mean you shouldn't try to find the thing that you're passionate about and the way that you can find your voice or a thing to contribute to, even if it's an external sort of open-source project or something like that.

+ +

MAC: Yeah, I mean, we have things like it doesn't have to be tied to the company. Like, a great example...so, Katrine, who's our head of sales, and my sister [laughter]...I guess I should --

+ +

CHAD: Full disclosure.

+ +

MAC: Like, put a little asterisk, you know, on there as well, yeah. Not why she has the job, but just happens to be that way. So, she actually started running this, like, Women in Revenue meetup with Gong, another company, with this other woman Ashley, like, almost two years ago, like, after she started Commsor. It wasn't tied to Commsor or, like, it wasn't tied to our business or anything like that. And then she came to me, like, a year ago and was like, "Oh, me and Ashley want to start our own podcast. What do you think?"

+ +

And we ended up actually, like, funding the podcast. Like, we pay for the editing, the hosting, like, all of a sudden, they need to, like, do it. And yeah, so we get to [inaudible 32:30], like, yeah, this podcast is, like, presented by Commsor, even though it's like Katrine and Ashley's podcast. We're, like, the permanent sponsor of it, basically. But it's been interesting.

+ +

And now it's like, and now she's involved in this group called Wednesday Women where it's like, she wants to elevate other women in revenue roles. That's not what Commsor's mission is. I'm not saying we don't believe in it but, like, that's not the reason Commsor exists, right? But we were like, yeah, we gave her the space to do it. There has been so much good that has come to Commsor from that, from her running her own meetups, hosting her podcast, building a brand around that, elevating other women.

+ +

Like, the amount of people who come to us and want to learn more about Commsor or [inaudible 33:05] want to work with us, whatever, because of the stuff she has done on a thing she cares about outside of work, I mean, it's obviously very tied to her work still, but it's not. It's not Commsor marketing. It's not for Commsor. It's not backed by Commsor, like, in an official capacity.

+ +

So, there are ways that, like, if people have those passions, like you said, it'll bring people who are like-minded, who will get to know them, who then inherently want to be like, "Oh, well, I love what Katrine is doing. What does Katrine do at Commsor? Oh, cool. What does Commsor do?" Like, you know, it's like, there's a funnel. Like, not everybody will follow that path. But a not insignificant portion of the people that are aware of our brand have come in through that path.

+ +

CHAD: And this is a good example of something that I talk a lot about is, is that the most effective thing that could probably happen? Probably not. But I would rather someone do the thing that is 60% effective and 100% fulfilling to them than doing something that is soul draining that they don't want to do that's 99%.

+ +

MAC: Well, I'll also counter that they will show up and be a better employee and team member because they're...it's like, so even if they're, like, doing less by the numbers, long term, they'll do more, like, especially in sales, right? Like, SDR culture has been this, like, you basically grind it out for 12 months, maybe 18 months as an SDR, and you hope that you make it to the AE role, and if you don't, not very many people...you don't become an SDR for ten years. It is not a career. It is a stepping stone of, like, I'm going to stick my face in the boiling water. I'm going to deal with it. I'm going to suck it up, and hopefully it pays off in the long term.

+ +

And, like, a huge percent of those folks end up churning out into customer success roles or completely different industries or whatever because it's, like, no one wants to keep their face on the grindstone for that long. But by, like, building a sales and a marketing system that's actually enjoyable for the people that are doing it, one, they bring their authentic selves to work, which means they're more likely to do it. They're more likely to stick around. They're more likely to have fun with it. And when they're having more fun with it, that also reflects on the people in the market because people can tell. People can tell that Commsor is having fun.

+ +

Like, it sounds kind of dumb, but I think especially in B2B, like, having fun is actually kind of a competitive advantage. And I don't mean fun in the sense of, like, oh, we post memes on our LinkedIn account. Like, that's not, like, corporate fun, but, like, actually, like, real people personalities showing through the work fun, like the dinosaur thing, right?

+ +

Like, I think my entire LinkedIn personality now is, like, anti-bad sales tactics, and dinosaurs are cool, which is also sad and kind of counterintuitive because, like, bad sales tactics are also things that dinosaurs [inaudible 35:40] [laughter], sort of a, like, sort of a funny play on things. But, like, I think my LinkedIn bio is: DM me for a fun fact about dinosaurs. It's not what we do at Commsor. It's not trying to pitch you on anything.

+ +

And I have had so many conversations where someone's just like, "I want a fun fact about dinosaurs." I'm like, "Sure. All right, cool. Like, here you go." And sometimes, it ends up going further. And, you know, maybe Commsor comes up naturally. Other times, they're like, "Cool. That's an awesome fact that made my day, thanks," and then that's it. That's the end of it. But when you can enable those personalities, and that authenticity, and that fun to show through the work, both sides benefit.

+ +

And when you're talking about things that don't scale, whatever, that's one of the classic pushbacks I get. - It's like, "Well, how does this, like, go-to-network relationship selling, how does it scale?" They're like, "I need to close 100 deals this year. I got to scale." It's like, I did a graphic...I can't remember the exact numbers, but looked at, like, you know, the stats on cold calling, for example. And it was like, to get one deal, you need five meetings because, on average, industry-wide in SaaS, 20% of those meetings become deals.

+ +

To get five meetings, you have to cold call 250 or more individual accounts because that's how many, on average, it takes with cold call rates. But on average, it takes seven to eight cold calls to actually get someone to answer. So, I have to call Sally eight times to get an answer. So, I have to make over 2,000 cold calls to end up with one meeting. It's just insane. Whereas if you look at like relationship selling, warm intros, and warm paths like that, they close at a 78% rate across the board.

+ +

So, it's actually like, okay, I can go out and get a pool of 250, 500, 1,000 contacts and try to get four leads, or I can go build relationships with ten people and get four deals that way. It's like, you don't need it to scale in the same way if you're building with that. The problem is that sales and marketing over the last decade have been built on the predictable revenue model. If I make X cold calls, I'll get X meetings, and I'll book Y deals. So, everyone is like, okay, it's scalable. If I want to close twice as much revenue, I need twice as many SDRs making twice as many cold calls to close twice as much. That just doesn't work anymore.

+ +

The whole model that startup growth has been built on for ten years it doesn't work. I mean, even if you look at, like, the IPOs of tech companies over the last decade, it's like less than 5% of them have been consistently profitable for the last three years. So, if we're all trying to build our companies and everyone's like, ooh, look at the way that XYZ, Uber, or WeWork, whatever, did over the last ten years, they actually haven't worked.

+ +

We've been trained and tricked on this system for 10, 15 years of, like, growth is everything. But, like, I don't know, just look at WeWork over the last month, right? Like, that's the shining star of, like, does it matter? Like, you can grow to a billion dollars in revenue. But if you're losing a billion to make a billion, the company making 20 million and spending 5 million to make that is actually a better company.

+ +

CHAD: Yeah. It's totally...some people that is what they want. But it does change your motivation when what you're trying to do is create a company that you enjoy working at that maybe isn't taking over the world but making a positive contribution to it. That changes your approach.

+ +

MAC: Yeah, you're not trying to consume everything in sight. There's a lot of different ways to do it. And yeah, I think the last ten years, especially in startup and SaaS land, have tricked a lot of people into thinking there's only one way to do things, and it's throw money in a grinder and hope to God that you get more money at the bottom of it than you put in the top of it, even though 99% of the time that's never the case.

+ +

CHAD: Well, Mac, thank you so much for joining and sharing with us. If folks want to find out more about Commsor or get in touch with you, what are all the different ways that they can do that?

+ +

MAC: Well, they can DM me on LinkedIn for a fun fact about dinosaurs before they ask what their real question is. It's just Mac Reddin. I think I'm the only one on LinkedIn with that name, so it shouldn't be too hard to find me. I'm the guy with the dinosaur emoji next to my name, just to really lean into it.

+ +

Yeah, and then Commsor, it's commsor.com. We're, like, just now starting to reveal what we've been building over the last six or nine months with our pivot into this go-to-network world. So, we're early on that front. But you can keep your eyes peeled, and there'll be more to see over the next few months.

+ +

CHAD: And Sally, thanks so much for joining today and help facilitating the conversation. I really appreciate it.

+ +

SALLY: Absolutely. It's been really fun.

+ +

CHAD: If folks want to get in touch with you or follow along, where are the places they can do that?

+ +

SALLY: I am all up in LinkedIn, so feel free to hit me up there. That's probably the best place. Also, if anybody out there ends up using Commsor, you can also find me in the Herd, which is the community that Mac has built, so feel free to find me there as well.

+ +

CHAD: And you, listener, can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon at cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

Special Guest: Mac Reddin.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Mac Reddin is the CEO of Commsor. He discusses Commsor's evolution from community-led growth software to a go-to-network model, emphasizing the importance of various overlapping networks in a company's ecosystem. He shares his journey from running a Minecraft-based company as a teenager to founding Commsor, which initially began as a newsletter and evolved into a community and then a product.

+ +

Mac stresses the effectiveness of authentic community building and relationship-based growth over traditional sales and marketing strategies. He criticizes cold calling and email tactics, advocating for genuine interactions and relationship-building. Commsor’s approach, including personal onboarding of every user and fostering a company culture where employees are encouraged to express their individuality and interests, has shown success and satisfaction internally and in the market.

+ +

Chad reflects on his experiences at thoughtbot, aligning with Reddin's perspective on community and user-centric approaches. He emphasizes trust and freedom within his team, allowing for authentic individual contributions to the company's growth and reputation. Together, they discuss the importance of personal connections in business and how modern sales tactics might need reevaluation in favor of more genuine, relationship-based approaches.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me as co-host today is Sally Ladrach, Revenue Enablement Manager at thoughtbot, great company I've heard of. Sally, thank you for joining.

+ +

SALLY: Yeah, thanks for having me on.

+ +

CHAD: And also joining us today is Mac Reddin, Founder and CEO of Commsor, which builds tools to help individuals and companies of all sizes grow faster, more authentically, and more sustainably through the power of go-to-network. Mac, thanks for joining us.

+ +

MAC: Thanks for having me.

+ +

CHAD: Mac, can you tell us a little bit more about what Commsor is and how you sort of arrived at creating it?

+ +

MAC: I struggle to do that every time someone asks me. It's always, like, a slightly different answer. So, we're about four years old now. But we kind of pivoted, soft pivoted, depending on how you want to look at it, into what we're doing now at the beginning of this year. So, we're kind of not that new and very new, depending on what perspective you look at.

+ +

We were originally building what we called community-led growth software. So, we were helping companies measure their community as an intentional part of their go-to-market initiative. And there's a whole rabbit hole on why we changed, and how we changed, and how we ended up where we are now.

+ +

But I think go-to-network is sort of an evolution of community-led from this realization that companies don't have a singular community. They might have a, you know, a forum, or a Slack, or a community manager, and there's, like, it's very easy to be like, that is their community. But in reality, there's influencers, investors, creators, advisors, personal brands, executives, champions, customers, community members, like, all these different overlapping networks, hence go-to-network, that actually make up this sort of ecosystem that enables a company to thrive.

+ +

CHAD: Now, did you have a community, or, like, did it grow from something, or did you just have the idea?

+ +

MAC: I started my first company when I was 17; built on top of Minecraft, and it was very community-centric, and I didn't really realize at the time. But I got lucky enough to sell that business. And, you know, after looking back at all the hats I've worn running a, you know, a tiny, bootstrapped company, I realized the community management part had been what I enjoyed the most and that the community part had been the kind of competitive advantage of that business. And that sent me down a path of thinking about community and business more intentionally after having kind of stumbled into it as a, I guess, late teenager.

+ +

So, Commsor started...originally, I knew I wanted to build something in the community space. So, we actually started...it started as a newsletter, actually. It was a substack called Community Chat Weekly, which was just, like, an aggregation newsletter as I was, like, doing research into the more professional community world. And then it became a small Slack community, which then became the community club. And Commsor, as a product, was born out of building a community for community people and just diving headfirst into that world.

+ +

SALLY: So much community, I love it [laughs].

+ +

MAC: Yeah. I try to say, like, a couple of different words, like world or something instead of community.

+ +

SALLY: [laughs]

+ +

MAC: And just, like, we used to joke that we were a community company for community people, by community people, with a community of community people.

+ +

CHAD: [laughs]

+ +

MAC: I was, like, just too much of the same word [laughs].

+ +

SALLY: I love that. So, it's interesting. One of the reasons why I really wanted to get you and Chad together, in particular, is because the whole go-to-network motion that you're so passionate about and that you've built this product around very closely aligns with how Chad has really led and grown thoughtbot over the last 20 years. And I thought it would be so cool to bring those perspectives together.

+ +

And one of the things that you mentioned around community was that it gave you a competitive advantage. I'm curious to know, Chad, does that resonate with you? Have you seen that in thoughtbot over the last, you know, couple of decades as you've been doing this?

+ +

CHAD: Yeah, definitely. I mean, one of the things that is my sort of go-to talking points, both at conferences and that kind of thing, is that one thing that has been really a big part of thoughtbot's success is being willing to be clear about who we were and what we believe. And when we do that, then the people who want what we have and believe what we believe and are excited by that can find us and, you know, follow us. And, eventually, when they're in a position to need help, we're top of mind.

+ +

And this idea, I think, holds back a lot of companies because you think your market is the total addressable market. And the reality is you're never going to work with the total addressable market. So, you're better off finding the people who believe what you believe in your niche and your community. And being that big fish in that small pond has been really beneficial for us.

+ +

SALLY: That's awesome. Yeah, I think it was kind of a culture shock, honestly, coming to thoughtbot because I had been so immersed in sort of the SaaS world and the mass outreach, cold outreach, sort of, I want to say, traditional go-to-market motion that's been used over the last ten years. And I came here, and there were so many things that thoughtbot did or didn't do that I just was honestly kind of shocked, you know, as an example, not using third-party cookies on our website [laughs].

+ +

And, Mac, when we were talking, it sounded like you're also doing some of those things that we joked might make a CRO cry [laughs]. So, I was curious to ask what some of those things were and see how that kind of matches up to what thoughtbot is doing in our approach, too. I'd be curious to know.

+ +

MAC: There are so many things. I mean, I get CROs all the time, not, like, yelling at me, but I get the whole like, "Young man, you don't understand how sales works," type comments all the time. I got one recently that was, "Don't talk about sales until you've sold in a recession." It was like, what do you think we've [laughter] been doing the last 18 months? But okay. But yeah, so we don't do cold calls. We don't do cold emails. We don't do any of that traditional stuff that software companies do.

+ +

And I guess you all as a, you know, more of a, like, service-based product, as a founder building a software-based product, more than half of the cold outbound I get is, like, developer agencies and stuff like that. It's, like, the classic scourge of outbound in a lot of ways, right? So, there's an element of, like, zigging when everyone else zags. And one of my favorite stats...I can't remember the exact number, so don't fully quote me on it. But --

+ +

CHAD: It's not like we're recording or anything. It's totally fine.

+ +

[laughter]

+ +

MAC: Yeah, well, I mean, I think the gist of the message is more important than the exact number. And it was a stat that there's been a 100x increase in prospecting activities over the last decade. So, for every cold email, cold call, in-mail ad impression that you would have seen ten years ago, you now get 100 as a buyer.

+ +

And I always say this thing to people; I'm like, it doesn't matter how good your outreach is. You can have the best well-crafted cold email, cold call; your timing can be perfect; everything could be right: relevance, timing, everything. The problem is, increasingly, buyers have been so pissed off at the deluge of shit they've gotten for ten years that it doesn't matter. Like, my phone does not ring if I don't have your number. I am physically uncoldcallable.

+ +

And I've talked to a lot of CROs, and they're like, "Well, we'll just, you know, marketing will get your lead some other way. And then they'll pass it over to us, and we'll still get to you." And it's like, okay, like, that doesn't really solve the problem. So, like, there's a lot of these weird things where sales and marketing aren't aligned. They expect each other to solve the problem for each other. They're pure volume-based, and we don't do any of that. And a lot of CROs and a lot of VPs of sales love to point out how wrong we are for that, but it's working so far.

+ +

And also, it's so much more enjoyable to build a company that way. Like, our salespeople, our SDRs, and all that stuff, they don't hate their jobs. They're not, like, sticking their face to the grindstone every morning and being like, "Oh yeah, I got to play pump-up music before I go to work. Otherwise, I'm not going to get through the day." It just creates a better work environment. It's better for us. It's better for the buyers. It's better all the way around.

+ +

CHAD: So, for thoughtbot, I know that a lot of this has come naturally for us because, as developers and designers, we've produced a lot of open source that flows from our work that then builds community around it. We write on a blog, which we're very fortunate to have a lot of people read over the years, which fosters reputation for us and community around it. But what does that look like for other companies who maybe aren't, like, an agency like us doing that kind of thing? What are the kinds of things that it looks like?

+ +

MAC: I think you hit the nail on the head earlier when you said it's about, like, showing off who you are and what you believe in and creating space so people can come to you. But in the, you know, the high growth SaaS world, the last ten years, people have not been a fan of waiting for people to come to you. It's, like, grow at all costs, blitzscale, all that sort of mentality.

+ +

For us, the way it looks is...I guess an example–so, we did this sort of semi-accidental campaign on LinkedIn over the last, I guess, two and a half months with these purple hoodies. And there's a whole backstory. They were an accident, and we were like, "Shit, we have too many hoodies. What do we do with them?" So, we made a thing out of them. And we thought we were going to get 25. We ended up getting 250 [laughter]. It's a whole thing.

+ +

We just started, like, we sent them to a few folks, and someone posted a photo without us asking being like, "Look at this awesome hoodie Commsor sent me." And their post went, like, insane. Like, by LinkedIn standards, it went insane. It was, like, 100 comments. Like, "How do I get one? Oh my God, I love it. It's so cool. Can I get one?"

+ +

So, we just started sending them to people, like, no goals, no intention, just brand building, just building connections, building relationships. I personally, from hoodies that I can attribute, have booked over 200 calls about our product with our ICP doing that without trying to. There's almost this element of, like, by not trying to sell, it's become easier to sell. There's, like, an element of like, I'm just sending you a hoodie because I think you're cool, and I want to get to know you.

+ +

And it's a fine line because I think a lot of companies try to do that. But you can always tell there's an undertone of, yeah, I'm sending you these cookies because, like, I'm really hoping you get on a sales call with me. But we genuinely were, like, we have too many hoodies. We're just trying to get rid of them. I don't want to pay to store them. Like, please, I'm begging you, please take our hoodie.

+ +

SALLY: [laughs]

+ +

MAC: And then, it just turned into this, like, whole FOMO game. It's like the authenticity was purely there. All in all, we spent about, including shipping, everything, like, $8,000 on hoodies, so not a tiny amount of money but also not huge by marketing budget standards. And I had a conversation with a CMO recently. He was like, "You should have just spent LinkedIn ads. That's such a waste of money. You can't track it. It's not attributable," et cetera. I was like, "We've gotten, I think, close to a million impressions on LinkedIn of people posting our hoodies talking about us. We couldn't have paid for that."

+ +

So, there's, like, this whole area where it's like, if you actually just go out there and build relationships, build community, get to know people, tell them what you believe in, yeah, people will not agree with you. Like, when I say I think modern go-to-market is broken and the way people sell is broken, I get a lot of sales leaders who are like, "You're an idiot. Like, that's wrong. You objectively don't know what you're doing. You've never been a salesperson by title. Don't spread this shit."

+ +

But then you get a lot of people who are like, "Yeah, you're right. It's not working. I want to hear what you have to say. I want to talk to you. I want to brainstorm with you." The amount of times that I get DMs from salespeople who are like, "Hey, I totally agree with that post you just wrote, but I can't publicly because my VP of sales is going to read me out if they see me agreeing with you. But like, yeah, this shit doesn't work anymore," like, 10 to 20 times a day, I get messages like that.

+ +

SALLY: And as a consumer of LinkedIn feed, you know, I've been following Mac for a while, but also follow a couple of other folks at Commsor and people who are in their networks. I can 100% validate that the Dino Hoodie is, in fact, now a status symbol on LinkedIn. So [laughs], I thought that was, you know, brilliant. And I'm not going to lie; I had some FOMO, too. I was like, where's my Dino Hoodie? And, in fact, when I talked to Mac, I was like --

+ +

CHAD: [laughs]

+ +

SALLY: I know that we just met, but can I get one of those? [laughs]

+ +

CHAD: I see now. This was just a ploy to get a hoodie.

+ +

MAC: I've gotten, like, reverse sales now. It's like, you know, you get pitch slapped on LinkedIn, or someone adds you, and right away, they're trying to sell to you. I've gotten that. [laughter] But they're trying to convince me to give them a hoodie. Like, somehow, we've created the reverse thing where, like, salespeople are reaching out to me to reverse pitch–so I can give them something.

+ +

SALLY: That is hilarious. And I promise that was not my intention; was just to get a hoodie from you. But there's so much there that I think would be interesting to unpack. Chad, I'm just kind of curious to know your impression of what Mac has shared around the sort of flak that he's gotten around, you know, what you're doing isn't going to work, or whatever. Have you gotten any of that over the years? Are you surprised to hear that? Just interested to hear your thoughts.

+ +

CHAD: No, I think it happens when you are willing to put yourself out there with an opinion, with a belief. And it's going to resonate with the people that it resonates with. And the flip side of that is there are going to be people who believe that you're wrong. You know, when we were doing very early on with test-driven development, for example, it was not an established industry practice. You could find blog posts from people out there saying. "It's bad. We tried it at my startup and our product failed, and it was too slow. It held us back from being successful."

+ +

But the people who believe in it...if we were the only company in Boston who was doing it and a company that believes in test-driven development was never going to work with a company that didn't do test-driven development, so we were the one company that they could work with because we believed in the same practices.

+ +

And that's the hard thing in that is, usually, if you're on the right track to finding the right niche or to the right belief that's going to really resonate with a group of people, the people that you're turning off is probably going to be a louder, more vocal group. And so, being strong in the face of that is really important.

+ +

And I'll also just call out that, like, this is one area where it's easy to say, "Well, this works because you've been successful." There are other founders probably who, like, they have a legitimately bad idea. And they ignore all the sort of haters, and they say, "Oh, those are just the haters." And yet they don't get the success because there wasn't the people out there who actually did believe what they believe or had a need for the product that they were creating, or something like that.

+ +

And I think it's important to ignore the noise or to push past the noise, but you do need to let it in a little bit so that you understand whether you're on the right track at all, I've found. What about you, Mac?

+ +

MAC: Yeah, it's a never-ending battle to know what to listen to, and what to ignore, and how to apply it or if to apply it, and things like that. I agree. I think there is an element of, like, it's like, what's that [inaudible 14:47] saying? Like, if no one thinks you're crazy or wrong, you're probably too late as well with your idea, right? Like, if you're like, "Here's my idea," and everyone's like, "That's a great idea," It's been done. You're very late to the party at that point.

+ +

There's no, like, right or wrong answer because there's always context. You always know your idea and your business, hopefully, better than anybody else does. So, you can't just, like, take other people's advice. I actually went through a whole period (It's like sort of a sidebar.), but where I was, like, impostor syndrome as a, you know, venture-backed CEO. I was like, oh, I got to, like, be the founder and run the company the way other people run companies at this stage. And it, like, objectively, almost killed us as a company.

+ +

I have lived both sides of that extreme of like, being like, "No, I'm not going to listen to anybody's advice," and the negatives and positives of that, and the "I'm just going to follow everyone's advice and do what they say," and the negatives and positives of that. And now somewhere, maybe not quite in the middle, maybe a little bit leaning towards the ignore the advice because I believe in what we're doing.

+ +

CHAD: And you need to actually believe what you're saying. I think this is the wrong tactic to take if you don't actually believe it.

+ +

SALLY: [laughs]

+ +

CHAD: Because if it's not authentic to you, it's going to be really hard to build an authentic community and message and those kinds of things, yeah.

+ +

MAC: People can tell.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

SALLY: One of the things that you had mentioned before was sort of the technology that you've built Commsor on. And it was an interesting choice to me because it's not one of the more, you know, flashy or hot, new sort of programming languages that's out there. So, I was just kind of wondering, what is it? And why did you make the decision to build out the actual tool the way that you did?

+ +

MAC: So, I definitely have to, like, put a giant asterisk over everything I'm about to say. I am not a technical founder [laughs]. So, like, anything I say here is just potentially wrong [laughter]. [inaudible 17:20] The decision was made because I had, you know, a great team that we put together and trusted them to make the decision, and that's the decision we've made. So, I mean, the bulk of the app is built on just, like, Ruby and React. It's pretty straightforward.

+ +

We have had people be like, "Well, you should be using this," you know, whatever "Next.js, plus this, plus this, you know, it's better." But, like, the team we have, they've worked together in the past. So, they actually came into an acquihire. So, we're like, basically, like, you know, they'd worked together for three years in a company. They have systems in place.

+ +

And at this stage, it's, like, debating what tool you're going to use when you start, like, just 99.9% of the time does not matter. There's no idea...you don't even know if it's going to work, the product, right? It's, like, and your customers don't care. Your customers don't care. Unless you're building a dev tool and it's, like, hyper-specific, but even then, they probably don't really care that much. So yeah, we have a good team. I trust them to make the decision. And it's what they know and what they're familiar with. So, instead of trying to reinvent the wheel, we just went with the thing that would let us get things done the fastest.

+ +

SALLY: Chad, I'm interested to know...the trust factor that you mentioned, Mac, is really key to a lot of thoughtbot's success. I think that one of the things that Chad has done well as he's grown the company is hired great people and then trusted them to get the job done however [laughs] they thought that it might best be done. So, Chad, I'm curious to know: whether you're deciding on a tech stack or how you're going to go to market or anything like that, what has the impact of trust been at thoughtbot as you've grown and scaled the company?

+ +

CHAD: I think trust is one of [laughs]...I think it's very important. It's one of our core values. And, for us, that comes from not just trust being a nice thing to have. It's the one value that I can also point to and say I intentionally created an environment of trust.

+ +

I've been doing freelancing and consulting for a long time, even before thoughtbot. And I knew that at thoughtbot, we were going to continually form and reform teams of people that hadn't necessarily worked together closely before. And that if every time we did that, we were going to have to be building trust with each other, that it would detract from the success of the product that we were trying to create and from the relationship that we were needing to build trust on urgently which was with our new client.

+ +

And so I tried really hard to create an environment where when people show up on day one, everyone inherently trusts that they belong there and trusts them. It's not easy, and it's not perfect. But I think we've made a lot of progress on that. And then, when you have that kind of environment, recognizing that it changes the way that you work with each other. And so, when it comes to, like, technology decisions and everything, I mean, that is essentially how we work is understanding that everyone has trust of each other and that when you are put in a position to make a decision, it is your decision to make.

+ +

But part of making decisions and part of having a trusting environment is communicating with each other. So, even if you're responsible for making the decision, part of your responsibility, then, is for bringing everyone else along with you. And sometimes that means setting up an environment where, okay, the results speak for themselves. But other times, it means educating people about, "Here's what we're going to do, and here's why," even if it is as simple as "This is what we know. We've been doing it for three years, and let's just get right to it."

+ +

I don't know if that directly answers your question. But it's a big part of how we've done things and tried to create the culture that we've created. And I happen to be biased, but Ruby is a great choice.

+ +

SALLY: [laughs]

+ +

CHAD: I think it's taken for granted because it has been around for so long. But I talk about strong beliefs. I am up to speed on lots of web development frameworks and the ways that you build applications across a variety of different platforms, and tech stacks, and that kind of thing.

+ +

We didn't choose Ruby on Rails because we thought it was going to be popular back in 2005. We chose it because it fundamentally was the best way that we could see, out of all the platforms at the time, to build web applications. It allowed us to do things in one line that normally would have, at the time, taken 20. And that allowed us to be faster and work the ways that we wanted to work. And embedded in that culture is things like testing and test-driven development, which we also believe in.

+ +

The simple fact of the matter is there hasn't been a paradigm shift in web frameworks that is actually fundamentally better in the way that Ruby on Rails was better in the early 2000s. So, you can choose something else, but it's not going to be significantly better than Rails in terms of productivity, in terms of what it can do for your early-stage product.

+ +

It basically just then comes down to there's choices you can make that will slow you down, definitely, in terms of architecture and everything in other platforms. But yeah, you can't go wrong with Rails, and you can't really go wrong with Ruby. And you can't go wrong with choosing what you know and what you're comfortable with, especially in the early days.

+ +

SALLY: Yeah, I love that. One of the themes that I'm sort of hearing from both of you in how you've approached building tools; building your business is putting users at the center. And, Mac, I know you were saying, you know, I have all these CROs coming at me, right? Like VPs of sales being like, "The way you're approaching things isn't going to work. It's dumb; it's stupid."

+ +

But then you also have these salespeople DMing you like, "Hey, I agree with you. I just can't say it out loud because I might get in trouble." And, ultimately, that salesperson really is your user, right? Because they're the ones that are building their network, that are leveraging it to then go get the sales for the company.

+ +

So, I thought it was interesting that sort of that user-centered approach was something that was coming out with both because I know for Ruby, in particular, it's very well-loved by developers that use it. It's, like, a very developer-friendly sort of language. And so, I'm just wondering, you know, how do you, Mac, continue to keep users at the center when you have voices coming at you, when you have [laughs], you know, people telling you you're doing it wrong? What are some things that you do tactically to make sure that you stay aligned?

+ +

MAC: I mean, the simple answer is talk to them all the time. We actually...every single user who gets onboarded to our product right now gets an introduction to me directly. That's part of, like, seeing how the product works as well. But every single user ends up speaking to me. Who knows if that'll scale? But right now, it's like, I have spoken for at least 30 minutes with every single person we've onboarded to our product. We onboard every user by hand right now, which is totally counterintuitive for the price point our product's at.

+ +

But it's been really helpful to build that relationship, build that trust, get the research and the understanding of what we need to do next really quickly, have tight feedback loops. We have, like, I Dm users all the time. Like, I [inaudible 24:28] I probably have 50 to 60 unique DMs on LinkedIn per day. And someone was telling me like, "That's a waste of time as CEO and founder." I'm like, it's literally the only thing that matters. I'm talking to users, hearing what the market is saying, like, hearing all that live, not hearing it from people.

+ +

We're also working on, right now, enabling anyone on our team to do an onboarding so that when we do scale, my goal would be that every person on our team, from an engineer to a success person to the CEO, would be onboarding a customer at least once every few weeks just to maintain that closeness and that connectedness. We're also working on things... I'm a huge fan of...do you know Arc browser?

+ +

SALLY: I'm not familiar, no.

+ +

CHAD: I haven't used it, but I am familiar with it, yeah.

+ +

MAC: I'm using it right now.

+ +

CHAD: [laughs]

+ +

MAC: Highly recommend. Not an ad, I promise; just a fan. But they do, like, little things that they do, for example, like, when they would change log, instead of being written or instead of being just a CEO, it'll be like, "Here are the four new things released." And the first thing is, "Oh, here's Mac, the developer who worked on this feature sharing it. And here's, you know, this person who worked on this feature."

+ +

So, it's like, each individual person becomes the face of the thing they worked on, rather than just like, oh, it's the faceless company, or it's, like, it's always the same, like, spokesperson who's always talking about it. So, enabling it to not just be me who talks to users all the time but the whole company enables the whole company to be more user-centric.

+ +

SALLY: That's so interesting. Again, there's, like, so many parallels between how I've seen thoughtbot approach things and how you're approaching things with Commsor. When you mentioned that your goal is to sort of make it so that several different people are the face, and it's not just like, oh, Commsor is Mac only [laughs], that's something that I think I've seen Chad do throughout the years.

+ +

So, Chad, do you have any examples of sort of how you've tried to scale the company, putting different faces and putting our experts out there, trying to make it so that thoughtbot is not, like, the Chad show? Because I feel like that's one of the things that, you know, you're great [laughs]. But I think that the fact that we have so many contributors to communities and people speaking at events has been really, you know, just good for business and good for the company. So, what are some ways that you've done that? And what benefits have you seen of doing sort of what Mac is trying to do right now within Commsor?

+ +

CHAD: I don't know that I've been super intentional about this. It just came naturally, as we're all people who would do this, right? Like, you can't stop us from doing it. And so, I mostly just try to create an environment where you're not stopping people from doing things that they would normally want to do anyway. And to then recognize when, you know, someone else goes and creates open source, or a blog post, or speaks at a conference, or whatever. That comes back to benefit us through the reputation that it builds and the community that it builds.

+ +

And I think a lot of organizations and teams and everything do a really good job of getting in people's way from doing things [laughs] that they would want to do. And so, that's really all I've tried to do is not get in people's way.

+ +

MAC: I've spoken to a lot of people who are, like, under the impression that their company owns their LinkedIn account, which I always think is super interesting, or companies who, like, go out of their way to be like, "No, you can't speak about, I don't know, that you like barbecuing," or, like, well, you can't, like, be a person. You have to, like, you are just a representative of the company. And it's so stupid.

+ +

It's, like, 90% of the growth we have is either word of mouth or people referencing that they've, like, built a relation or a connection with someone on our team, not just me, but, like, Ben or Katrine on our team, like, people like them. And then they want to learn about Commsor because they get to know them.

+ +

And I think there's this old model where, like, if you just draw, like, circles, right? Like, here's the company, and here's people. It used to be here's the company, and then all the people are inside of it. But more and more, like, the way we're trying to build it is, like, you have, like, the people are a ring around the bubble that is the company. It's like, the people actually are the kind of that first interface, which is always what it is anyways, whether companies act that way or not.

+ +

At the end of the day, people are the interface. But so many companies try to control that and, like, you know, put everyone through this, like, brand voice funnel that just...it just doesn't work. Yeah.

+ +

SALLY: Yeah. Well, and it's ironic because I've heard so many sales leaders harping on people buy from people. People buy from people. And then they don't allow their salespeople to actually go be a human being and a person in any sort of a public [laughs] forum like LinkedIn. I've had that same conversation with so many sales folks that I've worked with, you know, over the years, especially the last few years, where like, oh, I feel like I could really put some great stuff out on LinkedIn, build some relationships, but I just I feel sort of stifled from doing that for fear of reprimand, or losing my job, or whatever it is.

+ +

So, I definitely appreciate that, at thoughtbot, I don't feel that. I have felt that in the past in some roles, but I don't feel that here. And I'm just so grateful that I feel empowered to go share my thought leadership and things like that on LinkedIn. And it's interesting because that has yielded opportunities that I wasn't even looking for. So, yeah, I'm curious, Chad, if you've also seen things that we weren't necessarily looking for happening that way.

+ +

CHAD: I do. As you were talking, though, I was just thinking, this is harder than it was before. Like, you may be excited to talk on LinkedIn [laughs], but I would say the number of people at thoughtbot who are actually excited to do authentic stuff on social media these days is way, way down. And it's been trending down for years, and it's particularly bad these last couple. And, you know, we have the kind of culture where we don't force people to do it.

+ +

Is that something that you've seen, Mac? It's, like, individuals' sort of engagement, willingness? I think a lot of social media is just a mess right now, that kind of thing. And how is that affecting what you see in your strategy?

+ +

MAC: Yeah, I don't think...it doesn't have to necessarily be social media, like, once again, the browser company example of, like, the update videos including people in it, right? It's like it's...there's ways that the company can intentionally elevate their people first, rather than being like, "Oh, yeah, here's social media, like, have fun. Go build a brand. Please do free marketing for us." Because that's kind of, like, what you're subtly hoping happens if one of your team members builds an audience on Twitter or LinkedIn. You're like, cool, we'll get, like, the splashover effect.

+ +

I would say, right now, about 25% of our team is doing it really well without us prompting. Like, they just want to do it, and they're leaning into it and enjoying it. 25% want to do it but maybe aren't sure how or where. And we've actually, like, built systems internally to help, like, build, like, you know, give them the space to do it and whatnot. And then, half are just like, yeah, I'm not doing that. I don't have any interest at all.

+ +

CHAD: For me, it's more that you don't need to do that just because someone else is doing it. But that doesn't mean you shouldn't try to find the thing that you're passionate about and the way that you can find your voice or a thing to contribute to, even if it's an external sort of open-source project or something like that.

+ +

MAC: Yeah, I mean, we have things like it doesn't have to be tied to the company. Like, a great example...so, Katrine, who's our head of sales, and my sister [laughter]...I guess I should --

+ +

CHAD: Full disclosure.

+ +

MAC: Like, put a little asterisk, you know, on there as well, yeah. Not why she has the job, but just happens to be that way. So, she actually started running this, like, Women in Revenue meetup with Gong, another company, with this other woman Ashley, like, almost two years ago, like, after she started Commsor. It wasn't tied to Commsor or, like, it wasn't tied to our business or anything like that. And then she came to me, like, a year ago and was like, "Oh, me and Ashley want to start our own podcast. What do you think?"

+ +

And we ended up actually, like, funding the podcast. Like, we pay for the editing, the hosting, like, all of a sudden, they need to, like, do it. And yeah, so we get to [inaudible 32:30], like, yeah, this podcast is, like, presented by Commsor, even though it's like Katrine and Ashley's podcast. We're, like, the permanent sponsor of it, basically. But it's been interesting.

+ +

And now it's like, and now she's involved in this group called Wednesday Women where it's like, she wants to elevate other women in revenue roles. That's not what Commsor's mission is. I'm not saying we don't believe in it but, like, that's not the reason Commsor exists, right? But we were like, yeah, we gave her the space to do it. There has been so much good that has come to Commsor from that, from her running her own meetups, hosting her podcast, building a brand around that, elevating other women.

+ +

Like, the amount of people who come to us and want to learn more about Commsor or [inaudible 33:05] want to work with us, whatever, because of the stuff she has done on a thing she cares about outside of work, I mean, it's obviously very tied to her work still, but it's not. It's not Commsor marketing. It's not for Commsor. It's not backed by Commsor, like, in an official capacity.

+ +

So, there are ways that, like, if people have those passions, like you said, it'll bring people who are like-minded, who will get to know them, who then inherently want to be like, "Oh, well, I love what Katrine is doing. What does Katrine do at Commsor? Oh, cool. What does Commsor do?" Like, you know, it's like, there's a funnel. Like, not everybody will follow that path. But a not insignificant portion of the people that are aware of our brand have come in through that path.

+ +

CHAD: And this is a good example of something that I talk a lot about is, is that the most effective thing that could probably happen? Probably not. But I would rather someone do the thing that is 60% effective and 100% fulfilling to them than doing something that is soul draining that they don't want to do that's 99%.

+ +

MAC: Well, I'll also counter that they will show up and be a better employee and team member because they're...it's like, so even if they're, like, doing less by the numbers, long term, they'll do more, like, especially in sales, right? Like, SDR culture has been this, like, you basically grind it out for 12 months, maybe 18 months as an SDR, and you hope that you make it to the AE role, and if you don't, not very many people...you don't become an SDR for ten years. It is not a career. It is a stepping stone of, like, I'm going to stick my face in the boiling water. I'm going to deal with it. I'm going to suck it up, and hopefully it pays off in the long term.

+ +

And, like, a huge percent of those folks end up churning out into customer success roles or completely different industries or whatever because it's, like, no one wants to keep their face on the grindstone for that long. But by, like, building a sales and a marketing system that's actually enjoyable for the people that are doing it, one, they bring their authentic selves to work, which means they're more likely to do it. They're more likely to stick around. They're more likely to have fun with it. And when they're having more fun with it, that also reflects on the people in the market because people can tell. People can tell that Commsor is having fun.

+ +

Like, it sounds kind of dumb, but I think especially in B2B, like, having fun is actually kind of a competitive advantage. And I don't mean fun in the sense of, like, oh, we post memes on our LinkedIn account. Like, that's not, like, corporate fun, but, like, actually, like, real people personalities showing through the work fun, like the dinosaur thing, right?

+ +

Like, I think my entire LinkedIn personality now is, like, anti-bad sales tactics, and dinosaurs are cool, which is also sad and kind of counterintuitive because, like, bad sales tactics are also things that dinosaurs [inaudible 35:40] [laughter], sort of a, like, sort of a funny play on things. But, like, I think my LinkedIn bio is: DM me for a fun fact about dinosaurs. It's not what we do at Commsor. It's not trying to pitch you on anything.

+ +

And I have had so many conversations where someone's just like, "I want a fun fact about dinosaurs." I'm like, "Sure. All right, cool. Like, here you go." And sometimes, it ends up going further. And, you know, maybe Commsor comes up naturally. Other times, they're like, "Cool. That's an awesome fact that made my day, thanks," and then that's it. That's the end of it. But when you can enable those personalities, and that authenticity, and that fun to show through the work, both sides benefit.

+ +

And when you're talking about things that don't scale, whatever, that's one of the classic pushbacks I get. - It's like, "Well, how does this, like, go-to-network relationship selling, how does it scale?" They're like, "I need to close 100 deals this year. I got to scale." It's like, I did a graphic...I can't remember the exact numbers, but looked at, like, you know, the stats on cold calling, for example. And it was like, to get one deal, you need five meetings because, on average, industry-wide in SaaS, 20% of those meetings become deals.

+ +

To get five meetings, you have to cold call 250 or more individual accounts because that's how many, on average, it takes with cold call rates. But on average, it takes seven to eight cold calls to actually get someone to answer. So, I have to call Sally eight times to get an answer. So, I have to make over 2,000 cold calls to end up with one meeting. It's just insane. Whereas if you look at like relationship selling, warm intros, and warm paths like that, they close at a 78% rate across the board.

+ +

So, it's actually like, okay, I can go out and get a pool of 250, 500, 1,000 contacts and try to get four leads, or I can go build relationships with ten people and get four deals that way. It's like, you don't need it to scale in the same way if you're building with that. The problem is that sales and marketing over the last decade have been built on the predictable revenue model. If I make X cold calls, I'll get X meetings, and I'll book Y deals. So, everyone is like, okay, it's scalable. If I want to close twice as much revenue, I need twice as many SDRs making twice as many cold calls to close twice as much. That just doesn't work anymore.

+ +

The whole model that startup growth has been built on for ten years it doesn't work. I mean, even if you look at, like, the IPOs of tech companies over the last decade, it's like less than 5% of them have been consistently profitable for the last three years. So, if we're all trying to build our companies and everyone's like, ooh, look at the way that XYZ, Uber, or WeWork, whatever, did over the last ten years, they actually haven't worked.

+ +

We've been trained and tricked on this system for 10, 15 years of, like, growth is everything. But, like, I don't know, just look at WeWork over the last month, right? Like, that's the shining star of, like, does it matter? Like, you can grow to a billion dollars in revenue. But if you're losing a billion to make a billion, the company making 20 million and spending 5 million to make that is actually a better company.

+ +

CHAD: Yeah. It's totally...some people that is what they want. But it does change your motivation when what you're trying to do is create a company that you enjoy working at that maybe isn't taking over the world but making a positive contribution to it. That changes your approach.

+ +

MAC: Yeah, you're not trying to consume everything in sight. There's a lot of different ways to do it. And yeah, I think the last ten years, especially in startup and SaaS land, have tricked a lot of people into thinking there's only one way to do things, and it's throw money in a grinder and hope to God that you get more money at the bottom of it than you put in the top of it, even though 99% of the time that's never the case.

+ +

CHAD: Well, Mac, thank you so much for joining and sharing with us. If folks want to find out more about Commsor or get in touch with you, what are all the different ways that they can do that?

+ +

MAC: Well, they can DM me on LinkedIn for a fun fact about dinosaurs before they ask what their real question is. It's just Mac Reddin. I think I'm the only one on LinkedIn with that name, so it shouldn't be too hard to find me. I'm the guy with the dinosaur emoji next to my name, just to really lean into it.

+ +

Yeah, and then Commsor, it's commsor.com. We're, like, just now starting to reveal what we've been building over the last six or nine months with our pivot into this go-to-network world. So, we're early on that front. But you can keep your eyes peeled, and there'll be more to see over the next few months.

+ +

CHAD: And Sally, thanks so much for joining today and help facilitating the conversation. I really appreciate it.

+ +

SALLY: Absolutely. It's been really fun.

+ +

CHAD: If folks want to get in touch with you or follow along, where are the places they can do that?

+ +

SALLY: I am all up in LinkedIn, so feel free to hit me up there. That's probably the best place. Also, if anybody out there ends up using Commsor, you can also find me in the Herd, which is the community that Mac has built, so feel free to find me there as well.

+ +

CHAD: And you, listener, can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon at cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

Special Guest: Mac Reddin.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+c4IIkQSq + + ]]> + + Chad Pytel + Mac Reddin + + + 504: Spare with D'ontra Hughes + https://podcast.thoughtbot.com/504 + 436d071c-7726-482c-84de-344bdd26d8a8 + Thu, 14 Dec 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + D'ontra Hughes is the Founder and CEO of Spare, which uses tech to solve cash management problems for unbanked small businesses and enterprises. D'ontra shares his entrepreneurship journey, driven by realizing the financial industry's impact on less privileged individuals. + +D'ontra highlights a significant issue in the banking sector where the poorest people are often charged the most in fees, perpetuating poverty. Spare addresses the high fees unbanked individuals face when accessing their money. D'ontra's entrepreneurial journey involved various challenges, including learning from customer feedback, understanding the importance of data-driven decisions, and navigating the competitive startup environment. + +The conversation also covers the impact of the COVID-19 pandemic on Spare, leading to a strategic shift and a focus on regions with high cash circulation. D'ontra emphasizes the importance of strategic planning, data analysis, and a systematic approach to business growth. He also discusses the personal aspects of being a CEO, stressing the importance of maintaining personal relationships and self-care. + 32:57 + no + + + D'ontra Hughes is the Founder and CEO of Spare, which uses tech to solve cash management problems for unbanked small businesses and enterprises. D'ontra shares his entrepreneurship journey, driven by realizing the financial industry's impact on less privileged individuals. +D'ontra highlights a significant issue in the banking sector where the poorest people are often charged the most in fees, perpetuating poverty. Spare addresses the high fees unbanked individuals face when accessing their money. D'ontra's entrepreneurial journey involved various challenges, including learning from customer feedback, understanding the importance of data-driven decisions, and navigating the competitive startup environment. +The conversation also covers the impact of the COVID-19 pandemic on Spare, leading to a strategic shift and a focus on regions with high cash circulation. D'ontra emphasizes the importance of strategic planning, data analysis, and a systematic approach to business growth. He also discusses the personal aspects of being a CEO, stressing the importance of maintaining personal relationships and self-care. +Spare (https://www.gotspare.com/) +Follow Spare on LinkedIn (https://www.linkedin.com/company/spare-cs/), Facebook (https://www.facebook.com/SPAREapp/), Instagram (https://www.instagram.com/gotspare/), or X (https://twitter.com/gotSPARE). +Follow D'ontra Hughes on LinkedIn (https://www.linkedin.com/in/dontrahughes/) or X (https://twitter.com/dontrahughes). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is D'ontra Hughes, Founder and CEO of Spare, which uses tech to solve cash management problems for the unbanked small businesses and enterprise. D'ontra, thank you for joining us. +D'ONTRA: Well, thank you for having me. +VICTORIA: Well, wonderful. So, we met at San Diego Startup Week a few weeks ago. So, I'm excited to have you on the podcast today. Why don't you tell me what was your experience of San Diego Startup Week? And how did you come to be one of the speakers on a panel there? +D'ONTRA: Yeah, well, it's always a really nice thing to take part in, you know, kind of those innovative startup week events because you get to see a lot of what people are working on or what they're doing. So, we've been working very closely with the County of San Diego, especially with the city of Oceanside with our latest technology. +And, you know, there came this opportunity where I could get on the stage and kind of tell people about our journey a little bit, I think because we're becoming a little bit more successful or something [laughs]; I don't know what to say. We're getting better at what we're doing, apparently, and so folks wanted to hear what I had to say. +VICTORIA: I was able to catch your talk, and I thought what was really inspiring about it was that you came from the background of working in the financial industry and saw an opportunity to solve a problem that was common for other people and to be more fulfilled by the work you were doing. So, can you share a little bit about that? +D'ONTRA: I came out of a background in finance, as you said. I used to work for JPMorgan. It feels like a long, long time ago. And that was my last corporate job until I became an entrepreneur. You know, one of the things that I learned at that time...and not that the bank was doing anything wrong, but in the nature of finance, it's a business, right? It's got customers. It's got clients. It's got shareholders. And the most important thing is it's designed to make money. +There's always someone that loses, right? And sometimes you could say that that's the nature of business. But in this regard, it was a lot of people who lost that couldn't recover or wouldn't be able to recover from the financial waste that was left. +You know, I went on my entrepreneurial journey wanting to learn how to build a business and, you know, try to solve problems for myself or for other people. And specifically for this endeavor with Spare, which we launched back in 2015, we looked at the subset of the population, roughly about 25% of the U.S. population, 90-something million households of folks that were basically spending about 7% of their own income every year just accessing their own money. And, like, that's wild, right? Because if I came to you and I said, "Hey, if you got 100 bucks in your pocket, in order to pull that money out of your pocket, you got to give me $7," you'd be furious. +And so, the unfortunate thing is that this kind of tax on the poor was being facilitated by the ATM industry. At the time when we began the company, you had consumers out there going to an ATM roughly about seven times per month, withdrawing roughly about $60 per transaction. And the average fee at that time was $4.09. And today, the average fee is just about $4.80, something cents, depending on where you're at in the country. +And so, it's unfortunate the difference in these fees for these folks. It might sound absurd to say this, but it makes a difference between eating and not eating for some of these folks. And anyone who's a struggling college student or lives on the low end of the economic spectrum they understand what I mean by that, where the extra $30 or $40 in their pocket per month actually matters. It's an extra tank of gas or two tanks of gas, depending on what kind of car you're driving. And so, it matters. +We wanted to really take a really clean look, an assertive look at the relationship that, not just the ATM, but just cash management services or cash management on a local level the impact that it actually has. +VICTORIA: Yeah. And to kind of play that back a little bit, let's say you have a bank or you're not able even to get an account in a traditional bank. Maybe your bank doesn't have an ATM in your neighborhood, and you need to always go to a different ATM to get money out of your bank. And you're just constantly paying those fees. You're more likely taking out smaller sums of money, and then you have to do that over and over again. And it becomes a really high percentage of your income that goes just towards getting money out of the ATM. +D'ONTRA: Yeah, absolutely. So, when you consider even during the pandemic, right? Everyone's at home, but businesses were trying to figure out how to cut costs. And banks, just like any other business, when they have a retail bank branch that's in a neighborhood that's perhaps low income, they may not keep that bank branch around. And that's unfortunate because it creates an additional hurdle for folks to be able to become banked. +You may hear this term of banking deserts, and that's partially because folks have to travel too far, which is an external cost of time, and money, and resources, just to be able to put their money inside of a bank. Now, the additional cost for this particular demographic is that fees tend to add up. And we all know that the bank says, "Hey, as long as you keep $1,200 in your bank account, we're not going to charge you any fees." Well, that's really great, except for the person who is living paycheck to paycheck, right? +And so, this fee tax that's placed on them simply because they don't have enough money when you look at it, it's actually pretty rough [laughs]. I look at it, and sometimes I kind of laugh because it's absolutely absurd when you actually look at it on its face where the poorest people you're generating the most profits from. And unfortunately, those fees keep them in the cycle of being poor. +And so, it's been really great. Over the past few years, you've seen really great applications or neobanks come up that have acted as, you know, somewhat shields against all of these arbitrary fees, like, hey, no overdraft fees, and no account fees, ever, no monthly fees, and things of that nature, right? But they still aren't solving the other issues, some of the major issues. +So, it's really great that I have your debit card. But if you're a neobank, that means I either have to use your co-op ATM network, which is only going to allow me to withdraw cash so many times per month for free, or I have to use some other third-party ATM network. The unfortunate thing about that is they're still paying that fee [laughs]. At some point, they're still going to pay that fee, and when that money is better in their pockets, it's just a little rough. It's a little hard to digest. And so, we wanted to make sure we were doing something about it. +VICTORIA: Right. It reminds me of a phrase I come back to sometimes is that being poor is actually very expensive [laughs]. +D'ONTRA: It is. +VICTORIA: There's a lot of fees, a lot of extra stuff you have to pay for that other people don't. I'm curious: how did you narrow in on this problem? Was it through doing some market research? Was it a personal experience that led you to wanting to work for these types of users? +D'ONTRA: Even though JPMorgan was my last, like, corporate job, I went out into the world to be an entrepreneur. Being an entrepreneur is expensive because you got to figure out how to pay bills. And so, one of the side gigs I had is I worked for a hotel in Santa Monica by the name of the Fairmont, and I was managing valet. For anyone who's been to the Fairmont in Santa Monica, it's not for the cheap folks, right? +But what would happen is, you know, patrons would show up, and they'd say, "Hey, I'm going to valet my car. I'm going to come back and pick it up." I'm going to go ahead and settle this up. But, you know, where's the nearest ATM so I can give the valet person cash?" And the most often answer was, "Well, there's one inside the lobby of the hotel, and then there's one across this very busy street." Both of these ATMs had a fee of...the one across the street was about $3.75 if you weren't a bank customer, and, of course, it wasn't a national bank. And then the one in the lobby was about $4.75, I think is what the fee was. +And so, here's the person who doesn't really carry cash that often being told that they have to pay a premium just to help this person out. And you could almost guess what the most likely outcome was is, unfortunately, that valet person just didn't get tipped. But the thing is, is there was actually a third source of cash, and it was actually in the valet's pocket or at the valet stand. So, there was money there in closer proximity. There just wasn't a mechanism of extracting it. +And so, our first look was, well, hey, can we monetize a transaction between, say, the valet stand and this consumer where, basically, the valet stand is selling these folks their cash for much cheaper than the ATM? So, it's going to save everyone time, energy, money, and it ensures that the valet folks get cash in their pocket. I can remember when we initially launched this; I thought it was such a brilliant idea. We created an app in which we would populate a map with all the people around you that had cash on them. So, when you say it out loud, -- +VICTORIA: [laughs] Yeah. I could see how that might be problematic. +[laughter] +D'ONTRA: So, we're super stoked. We're, like, "Hey, we got this app, and it's really great. And, you know, look at all the people here that have money on them." So, we go to submit this thing to the App Store, and the legal team's like, "Absolutely not [laughs]." So, we spent about six months working back and forth with their legal team to come up with a model. +And it's somewhat similar to what you see today, where we're sending consumers to regular brick-and-mortar businesses that have spare cash on hand. That's it. Nothing glamorous about that. But the mechanism and the usefulness does some real overall good, not just for the consumers but for the businesses and for the local economy. +VICTORIA: Right. So, I was going to ask you, like, what surprised you in the early phases: the discovery process? It sounds like you had at least [laughs] at least one big strategic turn. But I'm curious if there was anything else that came up in your early-stage journey where you realized you had to make a pivot and change up what you were doing based on the feedback you got from users. +D'ONTRA: I'd love to be able to tell the story that we got it all right the first time around, but we didn't. I think we almost hit the checklist of things that you should not do. So, like [laughs], one example is you actually really truly shouldn't listen to your customer to some degree, right? So, you have the vision for this thing, but every customer has their idea of how your app should be better or something you should add. +And we went through phases where we were adding features then that people just weren't using. You know, it might have worked for, you know, 10% of the user base, but we had spent two or three weeks with the dev team putting in this new feature. And it was somewhat of a departure from the core. It's adjacent, and so we could justify it. So, we did it, but we shouldn't have. So [laughs], then we had to, like, backtrack on that. We had lots of these moments. +But I would say one of the most defining moments, and it was actually one of the first ones that came, was this moment in which one of early entrepreneurs' fear is that someone is going to steal your idea. So, we try to, you know, wrap folks up in NDAs, and secrecy, and things of that nature. You know, if you have a really solid idea, like, we all know that it has major potential to change your life. +And so, I can remember, you know, we went out, and we pitched this business to a venture capital company. It was very early on. That was my first lesson: people don't steal things that are worthless. And the second being that just because they steal, it doesn't mean they can build it. I can remember, you know, it took us six and a half months to get Spare in the App Store the first time around. +And during that time, we had met with this venture capital company looking for investors, angel investors. And it happened to be that this company gave us an offer to buy the company, and we said "No." But then were like, "Hey, why don't you come in and consult us, and let's see if we can work together to do a deal?" And me being super naive at that time, went in, and I said, "Hey, yeah. Like, this is how we would change the app, and this is what we would do." +And after two or three hours chatting with them, I had designed my competitor. And I didn't know that until a week later where they made their announcement, and, you know, I had Google Alerts on. And so, this app comes out and, you know, they're posting to see what people think about it. And they had gotten their app in the App Store, same business model, mind you. And I was just blown away [laughs]. Like, I think, at that time, I think I lost all composure. I was, like, sick to my stomach. I was furious. +When you asked about, like, the major pivot, it would have been in, like, my mindset because I went in thinking that we have this really great idea and how could anyone want to take something from an entrepreneur because starting is tough enough, especially the people that fund this stuff, right? And [laughs] I learned that, no, opportunities are opportunities, and people take them when they can. +And the bigger you become or depending on where your industry is, people are just looking for a shot. They're looking for an opportunity. No one really cares whether or not they're copying someone else's tech, right? If you were destined to do it, you would do it, and you would do it well, and you'd be one of the top ones to do it, right? +That was a major change in how I saw this journey, which allowed me to kind of reframe what we were doing and how I was approaching the market, how we collected data, how we dealt with our consumers, and how we ran our business in general. And then, we had to go in and pivot back to the conversation around the customer. So, we go back, and we're going back to build this thing. And so, at that time, I'm feeling, okay, I have to, like, do any and everything I can once we're in the App Store to get users and retain them. +And that's when I learned the lesson of, like, don't listen to all of your users. Like, know what your thing is, and do that thing really, really well. And try not to build features that aren't central to your core because, honestly, that can just get you in a lot of trouble. And you can waste a lot of time for no reason. +But I think the most important thing out of that is listen to the data, the information, and what I mean by that is where people go on a webpage, or where they go in your app, where they spend the most time. Listen to those things, and pay attention to the data, and somewhat become obsessed about utilizing the data to make your decisions. I think that'll save everyone a bit of heartache and, you know, pain as they go down that journey. +VICTORIA: Yeah, I really love that. There's a couple of, like, interesting points. I feel like when you said it can be daunting, like, oh, there's a million apps in there that already do this or, like, somebody else has already started this. Like, sometimes that means, well, it's a good idea because clearly somebody was willing to try and put it together, and they found a market. But you can always do it better, and you can always have a unique angle and try if you think there's a strong enough idea. +And I'm curious to, like, get more into, like, the data question and understand what do you use to understand how people are behaving in your app? And kind of metrics you look at to see how you're tracking and whether those are, like, key success measures or other ways that you think about that data. +D'ONTRA: For our application, you know, our KPIs were pretty simple very early on. It was like, do we have, like, the keywords that people respond to to find the application? And is it cash? Is cash the keyword? Is ATM the keyword? How do people find us, ultimately, at the end of the day? Because if you can solve that, solving what keywords are most attractive to your company, then what you're going to be able to do is organic traffic is going to be a lot easier to come by. +So, you don't have to spend a whole lot of money trying to get advertisements. There's going to be natural search traffic that drive people toward your platform. In addition to that, it was really paying attention to where the customer complaints were coming from because that told us a lot about the application. Even still, today, we have one very consistent customer complaint that, like, the unfortunate thing is, like, it's really difficult for us to solve this thing because it's actually more in the hands of the business than it is us. +And that major customer complaint is when I went into this active location, the person at the cash register didn't necessarily know what I was talking about, and there's a myriad of different reasons for that. But the primary one is that these locations typically have high turnover for the person that's working at the counter. And so Spare has to be an integral part of their onboarding this person so that when someone walks off the street, they can get the service that they need. +To some degree, listening or paying attention to the feedback that you're getting about the effectiveness of the service or being able to deliver the technology is actually a very useful data point. In addition to that, looking at where your app is available in cross-section with where the people are that are going to use your app. And this is one of the lessons, I think, we learned the hard way, where, you know, we came out the gate and said, "Hey, anybody and everybody can use this app. It doesn't matter if you're in New York, if you're in Texas, Midwest. It doesn't make a difference, right? Any and everyone can use it." +And the unfortunate thing is, when you do that, like, you're going to new users, which is really fun. It starts off that way. So, you go out, and you get merchants and things of that nature. And the mentality that we used was, well, we'll build it. The users will come, and the users will tell us where the businesses are or where we need to place businesses. So, we had a new person or a group of individuals show up in downtown Los Angeles. It was like, okay, cool, there's a concentration of people in Downtown LA. Let's go make sure we put businesses there. Well, that's faulty thinking in and of itself. +Even though you're getting the data points and the useful bits of data, you're actually doing it in pretty much, like, the wrong order [laughs]. We didn't really realize that, and Spare was my first tech company. And so, you know, when you think about things like that, like, you think, oh, users, they're important. But how you get them, and how you service them, and when you service them must be a strategic plan. You have to have that process thought out so that the user audience follows your plan, not you responding to them or following their informal plan. +VICTORIA: Yeah, that makes sense. And I love that, you know, focusing on the users and really focusing, like, on all of their unique needs like location [laughs] and other things like that. And I talk about that, you know, in my role as managing director at thoughtbot, I work on our DevOps and platform engineering team. I often talk about it in terms of, you know, very early in the process; you know enough about your user to tell you a lot about what their needs are going to be like on the infrastructure side, like their regional location, the sensitivity of the data, you know, that can tell you a lot about what you need to build [laughs]. +So, I'm curious, you know, you're working on a financial app here. Have you also had to consider that from a regional perspective and from an infrastructure perspective how that affects your users? +D'ONTRA: Going into COVID and how we got there, was that we thought we were actually doing really well, right? So, we officially launched our platform to the marketplace in Q4 of 2018. And we did well for the initial launch without any marketing. And then a year later, we had done 3x the volume and had a strategic partner in place that would have grown our network by 30 times by the end of the next year, you know, we were moving. +And then COVID came along, right? In which, you know, huge event that no one planned for. It kind of put the company on halt while businesses were shut down, and we lost about 98% of our network at that time. So, we had to go back to the drawing board and kind of, like, figure out, well, one, if this company is really truly something that we know that there's a thing, we're going to continue to build it, but let's do it better this time around, like, what did we miss the first time? +And the first place that we went when we were trying to make this decision is we went to look up, like, cash effectively, like cash in circulation. And to our surprise, actually, there was more cash put into [laughs] circulation during COVID than there was at any other time in the past, like, decade, and so that was shocking. And so, we said, okay, cool. We know that cash is in circulation, perfect. Where is cash in circulation? And in addition to that, where should we start with the base of our technology? And how do we want to reconfigure this? And to be honest, we need help. +So, you know, we applied to Techstars, and we were super fortunate that we got into the Techstars Anywhere program. I think it was a lifesaver and a reboot for us and the company primarily because, you know, during the pandemic, we had lost, you know, over 70% of the folks that worked for the company at that time. So, going through that program helped us rethink a lot about strategy infrastructurel...how exactly we need to rebuild and reconfigure the company for success this next time around. +I think very early on, you know, we were just trying to do the business. We were just doing it rather than actually strategically building it. You know, that's the major difference between where we were versus where we are now is that everything that we do now is more methodical. When we look at, okay, where do we build merchant networks? Well, we're building them in a very strategic location. That particular location has this value to not only us as a company, the merchants in that area, but also the user base. +When we were able to take this more strategic position around, you know, how exactly we're building this business, we were actually able to see much larger opportunities that have always been there, but we just didn't see them. And so [laughs], I'm super grateful for, like, us kind of doing that recalibration because we were able to build a business that is ten times bigger than we initially thought that we were building. +VICTORIA: That's super interesting. So, yeah, like, pre-COVID, you're like, we'll get users, and then we'll figure out where to build. And then you had to, like, go through this full recalibration and focus on strategic regions, and that really opened up more opportunities and more growth than you had expected. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration, or click the link in the show notes for this episode. +VICTORIA: What does success look like for you six months from now or five years from now? +D'ONTRA: So, six months from now. We're hitting this hot streak with new clients and things of that nature. And we're going out, and we're pitching contracts that are bigger than I ever thought we would be able to pitch, honestly. And sometimes when I see the zeros on the proposals that we're sending out, there's part [laughs] of me that's like, oh, they're never going to say yes to this thing, but, one, they are, which is still shocking, even though we've gotten a few of these in. +And six months from now, I just want us to be doing it right. I know that sounds so arbitrary, and it sounds, like, so whimsical. But there are so many things that we're adjusting to in the marketplace and with our tech. Some of this is kind of new frontier for us. But what I would like to have happen is for the results in the next six months to indicate that we're doing it the right way and meaning that we have clients sticking around, we're still getting contracts signed, the network is growing, consumers are actually getting their needs met by our technology, and the company is growing at a rapid pace. That's what I'd like to see. +And granted, you know, we've, in the past, you know, few weeks here, we've doubled the size of the team, which is something that feels really great. But I want us to not lose sight of making sure that the team itself always has a common goal in mind, even as we're growing. And whether that's six months from now, 2, 5, 10 years from now, I want that to kind of be the core of the expectations of what I want this company to be able to do and to deliver. +VICTORIA: That's exactly the right attitude to have [laughs], right? It's like I want it to work. I want us [laughs] to, yeah, be successful. I think it all makes sense. You know, it's easy to come on a podcast, like, you know, you're eight years into the startup now, and you're starting to see some success. And it's like, here's how I did it. Everything sounds great. So, I'm glad you've also shared some mistakes or some things that you maybe would have reconsidered or done [laughs] differently before. +I'm curious: if you could travel back in time to when you first started, what advice would you give yourself, now that you've had this experience, to set your mind right from the very beginning? +D'ONTRA: Oh God, there's so much. There's so [laughs] much. One of the major things that I would do differently is I would read more. And what I mean by that is there are lots of lots of people that have been here in this position and done that thing already. I think in the past year, I would say probably one of the most influential books that I've read is Zero to IPO by Frederic Kerrest. And I happened to listen to it in Audible. +But when you talk about, like, just things being pivotal, or like [laughs], going, "Oh, that makes sense," yeah, you get that because being an entrepreneur isn't new. And there are folks that have already kind of cracked the code in some regards. So, if you don't have the existing network around you already, go get the materials. Go read the books or listen to the audios of people who have been there, done that. It's going to save you so much time. So, that would be the number one thing that I would change is I would really truly read more and ingest other people's experiences more, and reach out and get mentors and advisors as you're going down this journey. +The second thing that I would do is–it's important to move fast when you're building a company. It's important to respond to the market and all that stuff. That's all super important. That's how you live or die, right? You treat it like there's a fire behind you, and you have to lead it. You have this really hot thing. You've got to be in front of it always, or you'll lose it. And sometimes what we miss is we miss the opportunity to do it faster or better by just slowing down just a little bit. And what I mean by that is, like, I mentioned earlier about looking at the data and things of that nature. +There may be things in the data that are making suggestions that you should go a different direction. But because of how you've built this thing, you and your co-founders, and how you guys have built these things in your head, that piece of data may not seem like it's very relevant. Sometimes, it's good to take a breath and take an assessment of where you're at. +So, when you're with your team, whether you're setting this up monthly, quarterly, whatever it is, make sure that you're taking some time to make sure that you guys are aligned around where your company is, the industry is, and the signs that you're getting inside the space that you're operating in. It's going to save you a lot of time. +And I think the last thing that is probably the most important is for those out there who are listening to this that are CEOs, one of my board members/life mentors/ CEO mentors, a friend, and almost like a father figure to me at this point, one of the things that he said to me and that I've never gotten out of my mind is that the CEO position is the loneliest position inside of an organization. And the reason why is even though you may start a business with your friends or people who aren't your friends, whatever it might be, whatever those relationships might be, those folks will never quite understand what it's like to sit in your seat because everything must end with you. It has to. +Every successful organization is going to rise or fall by the person that sits at the top. And because that burden is so heavy, oftentimes, we don't want to go and talk to people when things are going bad. We don't want to admit when, like, hey [laughs], this thing that we've sunk all these resources into isn't really working. And just the sheer pressure of being that person sucks sometimes. +With that being said, take care of yourself and your key relationships. And I'm not talking about key as in, like, strategic. I'm talking about the people that love you. Make sure even though you're going down this journey, you're making time for your friends, your family, your significant others, your kids, whatever it might be. Because business stuff aside, and we're all chasing the–Man, this is going to be really successful one day, and I'll be able to change everyone's life. Sure, we're all chasing that. +But there is a now moment. There is a person right now that might want your love or your attention, and do not rob them of that. Make sure that you're still making time for those things that are important. Because you could very easily start building a business and five years later, look up and go, oh, this thing didn't work. And then turn around, and there's a wasteland of relationships that you just didn't pay attention to. That's not worth it. So, make sure that you're not only showing, you know, the folks that support you some love but show yourself love by still nurturing those relationships. +VICTORIA: That reminds me I heard something about like, your rest ethic should be as good as your work ethic. And your rest ethic includes that time that you spend with family, or whether it's your religion, or your hobbies, or anything like that that makes you feel whole and like yourself, which I know can be a difficult thing to do when you're balancing starting a new business and thinking about the growth and the future all the time. So, I really appreciate that. +You know, you mentioned mentorship and these networking and relationships. Bringing it all the way back to Start Up San Diego Week, I'm curious if you have thoughts on how founders could get the most out of those types of events. And what draws you back to Startup San Diego or startup weeks in general? +D'ONTRA: Just as a caveat to all this, even though I'm on the podcast and stuff like that, and I'm sure if you Googled my name, you'll see that I've been on TV and stuff, I generally don't like networking [laughs]. I'm a major introvert. So, like, when you put me in an event like that, it's very hard for me to talk to people. Like, when we met, it seems that would be contrary to what I'm saying because we were strangers, and I came over, and we started chatting and stuff like that. And by and large, like, that's not always, like, an easy thing for me to do. +The reason why I'm saying that is that if you're that kind of person, do what you have to do to be more extroverted because sometimes that extroverted or that more open or welcoming side of you will allow for spontaneous interactions to occur. And so, when we think about events like, you know, Innovation Week or something like that, there's a lot of opportunity for you to either meet people that are on your journey or a similar journey like you who've been there done that, or even just to offer a different perspective. +And if you're in a place where you're open and constantly seeking, amazing things can happen, right? You could end up with your next co-founder. You could end up, you know, with your next investor. Or you could end up talking on a podcast with a stranger that you met just a few weeks ago, right? So, anything can happen. Keeping yourself open to the opportunity and the ability to extract as much value as you can out of those events. +It's really interesting to kind of have your pulse on what's going on, even if it's outside your industry. We're a FinTech, but I go, and I pay attention to things that are going on in aerospace or in health because it's always good to, one, not completely have yourself submerged in just your industry, even though that might sound really great. +People like folks that can talk about a myriad of different topics [laughs]. So, it might be useful if you can go and have a chat with a stranger about, you know, what's the latest in aerospace, right? It gets you out of the brain drain of what it is that you do on a daily basis. But also, you get to learn some new things and cultivate some new relationships. +VICTORIA: I love that. Yeah, I listened to...I think it's Happiness Lab episode where they talk about random conversations with people those, like, sparks of innovation or things like ideas you never would have thought of if you hadn't run into this random person [laughs] and talked to them for five minutes about, you know, what they do in health tech, or what they do for their consumer product that they're building. So yeah, I think that's great. +And I've been excited to be here in Southern California for the last three years and starting to grow that network and meet people like yourself who are doing really interesting things. I'm curious if you have any questions for myself or about thoughtbot, or the podcast, or anything. +D'ONTRA: Yeah. So, you say that you've been here for three years. Tell me a little bit about your journey, how'd you get here, and why you chose the podcast life, right? As one of your many things. +VICTORIA: That is one of my many things, right? So, I grew up in Washington, D.C., And my career was in tech and civic tech. I was working for big three-letter agencies and some pseudo-federal banks like FDIC, and Fannie Mae, and PBGC, all the acronyms all the time. And we got an opportunity in early 2020 to move here for my husband's job. And we moved out here, and I decided to take a switch out of the federal space and get into more commercial consulting. +And I was lucky enough to find thoughtbot; they had a position that just looked great for me. And when I joined, you know, we have an internal collaboration thing called Hub that I think our CEO wrote and writes with the other people. All the developers on our team all contribute to it. But he posted a message about this Giant Robots podcast and if anybody wanted to be a new co-host. And I was like, "Sure, I've done a little podcasting here and there, and I have a microphone, so I'm ready to go." +And little did I realize just how popular the [chuckles] podcast was. And it ended up being a really great avenue for me to meet people and, learn more about their stories, and build relationships in a way that has been really impactful and meaningful. And like I said, you know, you never know how someone you meet might help you [laughs]. So, sometimes I'll interview people, and I'll get an idea about something that is, like, exactly relevant to the work that I am doing that week, just total kismet however it came about. So, that's how I got into podcasting and how I'm in thoughtbot and here in Southern California. +And so, I'm super lucky that I live in a place where there's lots of events going on all the time and lots of great people to meet. Between LA and San Diego, you could go to a different event every single day, probably [laughs], and meet people who are working on cool stuff. +So, my background was really in operations and maintenance and taking federal agencies into more modern practices with digital services, and agile development, and DevOps. And now I'm taking kind of a similar lens but to commercial partners who are much faster and can make change quicker. And, in some cases, are doing things in even cooler ways than I could have thought and trying to think about how to move them forward with their infrastructure and how they deploy software. +D'ONTRA: That's fascinating. And, you know, it's difficult to be in Southern California, right? New events every day. +VICTORIA: And then yeah, I'll go walk my dog in the morning-- +D'ONTRA: [laughs] +VICTORIA: And people are out there surfing. And I'm like, I could surf all day. I don't have to work [laughs]. +D'ONTRA: Right? +VICTORIA: But I do. I got to work. +D'ONTRA: It feels like the world of limitless possibility, right? [laughs] +VICTORIA: Yeah. You almost feel, like, a pressure. Like, everyone else is starting their own company. Why am I not starting my company? Everyone's doing cool stuff all the time. So, you get motivated that way by being around a great group of people who are...everyone is very happy and sunny and [laughs] for the most part, the people are so nice. +D'ONTRA: Definitely a departure from the East Coast, right? And, like, I'm sure you came here with, like, that hustle mindset, where you're like, got to get it done, which is probably why you do, like, a million things. But then also, you have all of these people [laughs] that, like, I don't know, like, cares to the wind when they need to, right? Although you've got lots of successful people. But, sure, like, more or less down here, it's like, hey, you know, like, let's live life first and [laughs] make the dollars second. +VICTORIA: It's very casual. I got rid of all of my blazers. There's no more of that anymore [laughs]. People when they found out that I was moving to California, they were like, "That makes sense for you [laughs]," like, just the general, like, vibe. +D'ONTRA: [laughs] +VICTORIA: And I'm a rock climber. So, they're like, of course, you're going to go somewhere where the outdoors is prioritized, yeah. Versus when you live in D.C., it's like the news is happening to you. +D'ONTRA: Yes [laughs]. +VICTORIA: And it's very, very close. So yeah, it's interesting. I love it, though. And it's cool to take experience from that and then apply it to this world and how people might think about stuff. So, I was worried that, like, my experience might not translate, but it has. It's been very helpful [laughs] in some cases, right? +Is there anything else that you would like to promote today? +D'ONTRA: Yeah, so, you know, maybe for a future conversation, but in line with, you know, your background and what you're talking about, I would love to have a discussion around CRA, the Community Reinvestment Act, for those who don't understand the lingo, right? Because Spare's latest, like, golden nugget that we've really been just, like, kind of moving on and we're talking to federal regulators about is actually our impact on banks and the Community Reinvestment Act. +For those who follow the news and know, you know, the time and space that we're in right now, there are some changes that are taking place inside of CRA. And it's very fascinating because when you say about your background of helping agencies kind of modernize things with digital, that's effectively what we're doing with our tech, and we're getting a lot of support from the government. +And so, you know, I think that we're really doing some very interesting things that are starting to get some really great attention. We recently partnered with Visa on one of our initiatives, and we're talking to a few other really large organizations and government organizations so that this technology can really be used at a scale, honestly, far beyond what I ever imagined. But when we talk about, like, actually helping people, we're doing it [laughs]. We're doing it in this very unique way, which I'm super stoked about. But maybe we'll have a chat about that in the future. +But I think, you know, for those of you that are listening to this and you're curious, you know, what it is that we're working on, feel free to reach out. It's gotspare.com. Feel free to email me: ceo@gotspare.com. I'm generally in that email box every day. Or even just checking out our service, you know, searching Spare on the App Store or Google Play, and just going in and giving it a test drive. And, you know, we're happy to hear your thoughts. +And for those of you who are out there that may be looking for a new experience, we are definitely growing this team, and we want to expand as quickly as we can. We have some really aggressive initiatives for the organization over the next 12-18 months. And so, we're not going to do it on our own. I'm super stoked to where we're, like, we're at a place where we're like, we're actively building [laughs]. We're actively moving. And so, if there was a [inaudible 38:44] for us, whether it's supporting us as someone who uses the application or supporting us as a merchant who's in our community. +There's lots of value that we're adding that we're turning back around to reach all small businesses. We're really working on combating inflation with our tech. And we've been able to do that, which is one of those really, like, refreshing byproducts of a tech company, or at least of our services. Like, we're actually adding real, true value to folks, and I'm super stoked about that. +VICTORIA: That's wonderful, and it's really close to my heart as someone who wants to see tech with purpose and who loves tech solving problems for people, especially groups of people that usually aren't the focus of founders who are trying to turn a quick buck, right [laughs]? The people who have real problems there's a real market there. It is a business, and it makes sense to start solving those problems. So, I'm really happy that you're working on it. +Thank you so much for coming in today and being a guest on the show. We will include all those links and wonderful ways to reach out and get connected with you in the show notes. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: D'ontra Hughes. + + + D'ontra Hughes is the Founder and CEO of Spare, which uses tech to solve cash management problems for unbanked small businesses and enterprises. D'ontra shares his entrepreneurship journey, driven by realizing the financial industry's impact on less privileged individuals.

+ +

D'ontra highlights a significant issue in the banking sector where the poorest people are often charged the most in fees, perpetuating poverty. Spare addresses the high fees unbanked individuals face when accessing their money. D'ontra's entrepreneurial journey involved various challenges, including learning from customer feedback, understanding the importance of data-driven decisions, and navigating the competitive startup environment.

+ +

The conversation also covers the impact of the COVID-19 pandemic on Spare, leading to a strategic shift and a focus on regions with high cash circulation. D'ontra emphasizes the importance of strategic planning, data analysis, and a systematic approach to business growth. He also discusses the personal aspects of being a CEO, stressing the importance of maintaining personal relationships and self-care.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is D'ontra Hughes, Founder and CEO of Spare, which uses tech to solve cash management problems for the unbanked small businesses and enterprise. D'ontra, thank you for joining us.

+ +

D'ONTRA: Well, thank you for having me.

+ +

VICTORIA: Well, wonderful. So, we met at San Diego Startup Week a few weeks ago. So, I'm excited to have you on the podcast today. Why don't you tell me what was your experience of San Diego Startup Week? And how did you come to be one of the speakers on a panel there?

+ +

D'ONTRA: Yeah, well, it's always a really nice thing to take part in, you know, kind of those innovative startup week events because you get to see a lot of what people are working on or what they're doing. So, we've been working very closely with the County of San Diego, especially with the city of Oceanside with our latest technology.

+ +

And, you know, there came this opportunity where I could get on the stage and kind of tell people about our journey a little bit, I think because we're becoming a little bit more successful or something [laughs]; I don't know what to say. We're getting better at what we're doing, apparently, and so folks wanted to hear what I had to say.

+ +

VICTORIA: I was able to catch your talk, and I thought what was really inspiring about it was that you came from the background of working in the financial industry and saw an opportunity to solve a problem that was common for other people and to be more fulfilled by the work you were doing. So, can you share a little bit about that?

+ +

D'ONTRA: I came out of a background in finance, as you said. I used to work for JPMorgan. It feels like a long, long time ago. And that was my last corporate job until I became an entrepreneur. You know, one of the things that I learned at that time...and not that the bank was doing anything wrong, but in the nature of finance, it's a business, right? It's got customers. It's got clients. It's got shareholders. And the most important thing is it's designed to make money.

+ +

There's always someone that loses, right? And sometimes you could say that that's the nature of business. But in this regard, it was a lot of people who lost that couldn't recover or wouldn't be able to recover from the financial waste that was left.

+ +

You know, I went on my entrepreneurial journey wanting to learn how to build a business and, you know, try to solve problems for myself or for other people. And specifically for this endeavor with Spare, which we launched back in 2015, we looked at the subset of the population, roughly about 25% of the U.S. population, 90-something million households of folks that were basically spending about 7% of their own income every year just accessing their own money. And, like, that's wild, right? Because if I came to you and I said, "Hey, if you got 100 bucks in your pocket, in order to pull that money out of your pocket, you got to give me $7," you'd be furious.

+ +

And so, the unfortunate thing is that this kind of tax on the poor was being facilitated by the ATM industry. At the time when we began the company, you had consumers out there going to an ATM roughly about seven times per month, withdrawing roughly about $60 per transaction. And the average fee at that time was $4.09. And today, the average fee is just about $4.80, something cents, depending on where you're at in the country.

+ +

And so, it's unfortunate the difference in these fees for these folks. It might sound absurd to say this, but it makes a difference between eating and not eating for some of these folks. And anyone who's a struggling college student or lives on the low end of the economic spectrum they understand what I mean by that, where the extra $30 or $40 in their pocket per month actually matters. It's an extra tank of gas or two tanks of gas, depending on what kind of car you're driving. And so, it matters.

+ +

We wanted to really take a really clean look, an assertive look at the relationship that, not just the ATM, but just cash management services or cash management on a local level the impact that it actually has.

+ +

VICTORIA: Yeah. And to kind of play that back a little bit, let's say you have a bank or you're not able even to get an account in a traditional bank. Maybe your bank doesn't have an ATM in your neighborhood, and you need to always go to a different ATM to get money out of your bank. And you're just constantly paying those fees. You're more likely taking out smaller sums of money, and then you have to do that over and over again. And it becomes a really high percentage of your income that goes just towards getting money out of the ATM.

+ +

D'ONTRA: Yeah, absolutely. So, when you consider even during the pandemic, right? Everyone's at home, but businesses were trying to figure out how to cut costs. And banks, just like any other business, when they have a retail bank branch that's in a neighborhood that's perhaps low income, they may not keep that bank branch around. And that's unfortunate because it creates an additional hurdle for folks to be able to become banked.

+ +

You may hear this term of banking deserts, and that's partially because folks have to travel too far, which is an external cost of time, and money, and resources, just to be able to put their money inside of a bank. Now, the additional cost for this particular demographic is that fees tend to add up. And we all know that the bank says, "Hey, as long as you keep $1,200 in your bank account, we're not going to charge you any fees." Well, that's really great, except for the person who is living paycheck to paycheck, right?

+ +

And so, this fee tax that's placed on them simply because they don't have enough money when you look at it, it's actually pretty rough [laughs]. I look at it, and sometimes I kind of laugh because it's absolutely absurd when you actually look at it on its face where the poorest people you're generating the most profits from. And unfortunately, those fees keep them in the cycle of being poor.

+ +

And so, it's been really great. Over the past few years, you've seen really great applications or neobanks come up that have acted as, you know, somewhat shields against all of these arbitrary fees, like, hey, no overdraft fees, and no account fees, ever, no monthly fees, and things of that nature, right? But they still aren't solving the other issues, some of the major issues.

+ +

So, it's really great that I have your debit card. But if you're a neobank, that means I either have to use your co-op ATM network, which is only going to allow me to withdraw cash so many times per month for free, or I have to use some other third-party ATM network. The unfortunate thing about that is they're still paying that fee [laughs]. At some point, they're still going to pay that fee, and when that money is better in their pockets, it's just a little rough. It's a little hard to digest. And so, we wanted to make sure we were doing something about it.

+ +

VICTORIA: Right. It reminds me of a phrase I come back to sometimes is that being poor is actually very expensive [laughs].

+ +

D'ONTRA: It is.

+ +

VICTORIA: There's a lot of fees, a lot of extra stuff you have to pay for that other people don't. I'm curious: how did you narrow in on this problem? Was it through doing some market research? Was it a personal experience that led you to wanting to work for these types of users?

+ +

D'ONTRA: Even though JPMorgan was my last, like, corporate job, I went out into the world to be an entrepreneur. Being an entrepreneur is expensive because you got to figure out how to pay bills. And so, one of the side gigs I had is I worked for a hotel in Santa Monica by the name of the Fairmont, and I was managing valet. For anyone who's been to the Fairmont in Santa Monica, it's not for the cheap folks, right?

+ +

But what would happen is, you know, patrons would show up, and they'd say, "Hey, I'm going to valet my car. I'm going to come back and pick it up." I'm going to go ahead and settle this up. But, you know, where's the nearest ATM so I can give the valet person cash?" And the most often answer was, "Well, there's one inside the lobby of the hotel, and then there's one across this very busy street." Both of these ATMs had a fee of...the one across the street was about $3.75 if you weren't a bank customer, and, of course, it wasn't a national bank. And then the one in the lobby was about $4.75, I think is what the fee was.

+ +

And so, here's the person who doesn't really carry cash that often being told that they have to pay a premium just to help this person out. And you could almost guess what the most likely outcome was is, unfortunately, that valet person just didn't get tipped. But the thing is, is there was actually a third source of cash, and it was actually in the valet's pocket or at the valet stand. So, there was money there in closer proximity. There just wasn't a mechanism of extracting it.

+ +

And so, our first look was, well, hey, can we monetize a transaction between, say, the valet stand and this consumer where, basically, the valet stand is selling these folks their cash for much cheaper than the ATM? So, it's going to save everyone time, energy, money, and it ensures that the valet folks get cash in their pocket. I can remember when we initially launched this; I thought it was such a brilliant idea. We created an app in which we would populate a map with all the people around you that had cash on them. So, when you say it out loud, --

+ +

VICTORIA: [laughs] Yeah. I could see how that might be problematic.

+ +

[laughter]

+ +

D'ONTRA: So, we're super stoked. We're, like, "Hey, we got this app, and it's really great. And, you know, look at all the people here that have money on them." So, we go to submit this thing to the App Store, and the legal team's like, "Absolutely not [laughs]." So, we spent about six months working back and forth with their legal team to come up with a model.

+ +

And it's somewhat similar to what you see today, where we're sending consumers to regular brick-and-mortar businesses that have spare cash on hand. That's it. Nothing glamorous about that. But the mechanism and the usefulness does some real overall good, not just for the consumers but for the businesses and for the local economy.

+ +

VICTORIA: Right. So, I was going to ask you, like, what surprised you in the early phases: the discovery process? It sounds like you had at least [laughs] at least one big strategic turn. But I'm curious if there was anything else that came up in your early-stage journey where you realized you had to make a pivot and change up what you were doing based on the feedback you got from users.

+ +

D'ONTRA: I'd love to be able to tell the story that we got it all right the first time around, but we didn't. I think we almost hit the checklist of things that you should not do. So, like [laughs], one example is you actually really truly shouldn't listen to your customer to some degree, right? So, you have the vision for this thing, but every customer has their idea of how your app should be better or something you should add.

+ +

And we went through phases where we were adding features then that people just weren't using. You know, it might have worked for, you know, 10% of the user base, but we had spent two or three weeks with the dev team putting in this new feature. And it was somewhat of a departure from the core. It's adjacent, and so we could justify it. So, we did it, but we shouldn't have. So [laughs], then we had to, like, backtrack on that. We had lots of these moments.

+ +

But I would say one of the most defining moments, and it was actually one of the first ones that came, was this moment in which one of early entrepreneurs' fear is that someone is going to steal your idea. So, we try to, you know, wrap folks up in NDAs, and secrecy, and things of that nature. You know, if you have a really solid idea, like, we all know that it has major potential to change your life.

+ +

And so, I can remember, you know, we went out, and we pitched this business to a venture capital company. It was very early on. That was my first lesson: people don't steal things that are worthless. And the second being that just because they steal, it doesn't mean they can build it. I can remember, you know, it took us six and a half months to get Spare in the App Store the first time around.

+ +

And during that time, we had met with this venture capital company looking for investors, angel investors. And it happened to be that this company gave us an offer to buy the company, and we said "No." But then were like, "Hey, why don't you come in and consult us, and let's see if we can work together to do a deal?" And me being super naive at that time, went in, and I said, "Hey, yeah. Like, this is how we would change the app, and this is what we would do."

+ +

And after two or three hours chatting with them, I had designed my competitor. And I didn't know that until a week later where they made their announcement, and, you know, I had Google Alerts on. And so, this app comes out and, you know, they're posting to see what people think about it. And they had gotten their app in the App Store, same business model, mind you. And I was just blown away [laughs]. Like, I think, at that time, I think I lost all composure. I was, like, sick to my stomach. I was furious.

+ +

When you asked about, like, the major pivot, it would have been in, like, my mindset because I went in thinking that we have this really great idea and how could anyone want to take something from an entrepreneur because starting is tough enough, especially the people that fund this stuff, right? And [laughs] I learned that, no, opportunities are opportunities, and people take them when they can.

+ +

And the bigger you become or depending on where your industry is, people are just looking for a shot. They're looking for an opportunity. No one really cares whether or not they're copying someone else's tech, right? If you were destined to do it, you would do it, and you would do it well, and you'd be one of the top ones to do it, right?

+ +

That was a major change in how I saw this journey, which allowed me to kind of reframe what we were doing and how I was approaching the market, how we collected data, how we dealt with our consumers, and how we ran our business in general. And then, we had to go in and pivot back to the conversation around the customer. So, we go back, and we're going back to build this thing. And so, at that time, I'm feeling, okay, I have to, like, do any and everything I can once we're in the App Store to get users and retain them.

+ +

And that's when I learned the lesson of, like, don't listen to all of your users. Like, know what your thing is, and do that thing really, really well. And try not to build features that aren't central to your core because, honestly, that can just get you in a lot of trouble. And you can waste a lot of time for no reason.

+ +

But I think the most important thing out of that is listen to the data, the information, and what I mean by that is where people go on a webpage, or where they go in your app, where they spend the most time. Listen to those things, and pay attention to the data, and somewhat become obsessed about utilizing the data to make your decisions. I think that'll save everyone a bit of heartache and, you know, pain as they go down that journey.

+ +

VICTORIA: Yeah, I really love that. There's a couple of, like, interesting points. I feel like when you said it can be daunting, like, oh, there's a million apps in there that already do this or, like, somebody else has already started this. Like, sometimes that means, well, it's a good idea because clearly somebody was willing to try and put it together, and they found a market. But you can always do it better, and you can always have a unique angle and try if you think there's a strong enough idea.

+ +

And I'm curious to, like, get more into, like, the data question and understand what do you use to understand how people are behaving in your app? And kind of metrics you look at to see how you're tracking and whether those are, like, key success measures or other ways that you think about that data.

+ +

D'ONTRA: For our application, you know, our KPIs were pretty simple very early on. It was like, do we have, like, the keywords that people respond to to find the application? And is it cash? Is cash the keyword? Is ATM the keyword? How do people find us, ultimately, at the end of the day? Because if you can solve that, solving what keywords are most attractive to your company, then what you're going to be able to do is organic traffic is going to be a lot easier to come by.

+ +

So, you don't have to spend a whole lot of money trying to get advertisements. There's going to be natural search traffic that drive people toward your platform. In addition to that, it was really paying attention to where the customer complaints were coming from because that told us a lot about the application. Even still, today, we have one very consistent customer complaint that, like, the unfortunate thing is, like, it's really difficult for us to solve this thing because it's actually more in the hands of the business than it is us.

+ +

And that major customer complaint is when I went into this active location, the person at the cash register didn't necessarily know what I was talking about, and there's a myriad of different reasons for that. But the primary one is that these locations typically have high turnover for the person that's working at the counter. And so Spare has to be an integral part of their onboarding this person so that when someone walks off the street, they can get the service that they need.

+ +

To some degree, listening or paying attention to the feedback that you're getting about the effectiveness of the service or being able to deliver the technology is actually a very useful data point. In addition to that, looking at where your app is available in cross-section with where the people are that are going to use your app. And this is one of the lessons, I think, we learned the hard way, where, you know, we came out the gate and said, "Hey, anybody and everybody can use this app. It doesn't matter if you're in New York, if you're in Texas, Midwest. It doesn't make a difference, right? Any and everyone can use it."

+ +

And the unfortunate thing is, when you do that, like, you're going to new users, which is really fun. It starts off that way. So, you go out, and you get merchants and things of that nature. And the mentality that we used was, well, we'll build it. The users will come, and the users will tell us where the businesses are or where we need to place businesses. So, we had a new person or a group of individuals show up in downtown Los Angeles. It was like, okay, cool, there's a concentration of people in Downtown LA. Let's go make sure we put businesses there. Well, that's faulty thinking in and of itself.

+ +

Even though you're getting the data points and the useful bits of data, you're actually doing it in pretty much, like, the wrong order [laughs]. We didn't really realize that, and Spare was my first tech company. And so, you know, when you think about things like that, like, you think, oh, users, they're important. But how you get them, and how you service them, and when you service them must be a strategic plan. You have to have that process thought out so that the user audience follows your plan, not you responding to them or following their informal plan.

+ +

VICTORIA: Yeah, that makes sense. And I love that, you know, focusing on the users and really focusing, like, on all of their unique needs like location [laughs] and other things like that. And I talk about that, you know, in my role as managing director at thoughtbot, I work on our DevOps and platform engineering team. I often talk about it in terms of, you know, very early in the process; you know enough about your user to tell you a lot about what their needs are going to be like on the infrastructure side, like their regional location, the sensitivity of the data, you know, that can tell you a lot about what you need to build [laughs].

+ +

So, I'm curious, you know, you're working on a financial app here. Have you also had to consider that from a regional perspective and from an infrastructure perspective how that affects your users?

+ +

D'ONTRA: Going into COVID and how we got there, was that we thought we were actually doing really well, right? So, we officially launched our platform to the marketplace in Q4 of 2018. And we did well for the initial launch without any marketing. And then a year later, we had done 3x the volume and had a strategic partner in place that would have grown our network by 30 times by the end of the next year, you know, we were moving.

+ +

And then COVID came along, right? In which, you know, huge event that no one planned for. It kind of put the company on halt while businesses were shut down, and we lost about 98% of our network at that time. So, we had to go back to the drawing board and kind of, like, figure out, well, one, if this company is really truly something that we know that there's a thing, we're going to continue to build it, but let's do it better this time around, like, what did we miss the first time?

+ +

And the first place that we went when we were trying to make this decision is we went to look up, like, cash effectively, like cash in circulation. And to our surprise, actually, there was more cash put into [laughs] circulation during COVID than there was at any other time in the past, like, decade, and so that was shocking. And so, we said, okay, cool. We know that cash is in circulation, perfect. Where is cash in circulation? And in addition to that, where should we start with the base of our technology? And how do we want to reconfigure this? And to be honest, we need help.

+ +

So, you know, we applied to Techstars, and we were super fortunate that we got into the Techstars Anywhere program. I think it was a lifesaver and a reboot for us and the company primarily because, you know, during the pandemic, we had lost, you know, over 70% of the folks that worked for the company at that time. So, going through that program helped us rethink a lot about strategy infrastructurel...how exactly we need to rebuild and reconfigure the company for success this next time around.

+ +

I think very early on, you know, we were just trying to do the business. We were just doing it rather than actually strategically building it. You know, that's the major difference between where we were versus where we are now is that everything that we do now is more methodical. When we look at, okay, where do we build merchant networks? Well, we're building them in a very strategic location. That particular location has this value to not only us as a company, the merchants in that area, but also the user base.

+ +

When we were able to take this more strategic position around, you know, how exactly we're building this business, we were actually able to see much larger opportunities that have always been there, but we just didn't see them. And so [laughs], I'm super grateful for, like, us kind of doing that recalibration because we were able to build a business that is ten times bigger than we initially thought that we were building.

+ +

VICTORIA: That's super interesting. So, yeah, like, pre-COVID, you're like, we'll get users, and then we'll figure out where to build. And then you had to, like, go through this full recalibration and focus on strategic regions, and that really opened up more opportunities and more growth than you had expected.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration, or click the link in the show notes for this episode.

+ +

VICTORIA: What does success look like for you six months from now or five years from now?

+ +

D'ONTRA: So, six months from now. We're hitting this hot streak with new clients and things of that nature. And we're going out, and we're pitching contracts that are bigger than I ever thought we would be able to pitch, honestly. And sometimes when I see the zeros on the proposals that we're sending out, there's part [laughs] of me that's like, oh, they're never going to say yes to this thing, but, one, they are, which is still shocking, even though we've gotten a few of these in.

+ +

And six months from now, I just want us to be doing it right. I know that sounds so arbitrary, and it sounds, like, so whimsical. But there are so many things that we're adjusting to in the marketplace and with our tech. Some of this is kind of new frontier for us. But what I would like to have happen is for the results in the next six months to indicate that we're doing it the right way and meaning that we have clients sticking around, we're still getting contracts signed, the network is growing, consumers are actually getting their needs met by our technology, and the company is growing at a rapid pace. That's what I'd like to see.

+ +

And granted, you know, we've, in the past, you know, few weeks here, we've doubled the size of the team, which is something that feels really great. But I want us to not lose sight of making sure that the team itself always has a common goal in mind, even as we're growing. And whether that's six months from now, 2, 5, 10 years from now, I want that to kind of be the core of the expectations of what I want this company to be able to do and to deliver.

+ +

VICTORIA: That's exactly the right attitude to have [laughs], right? It's like I want it to work. I want us [laughs] to, yeah, be successful. I think it all makes sense. You know, it's easy to come on a podcast, like, you know, you're eight years into the startup now, and you're starting to see some success. And it's like, here's how I did it. Everything sounds great. So, I'm glad you've also shared some mistakes or some things that you maybe would have reconsidered or done [laughs] differently before.

+ +

I'm curious: if you could travel back in time to when you first started, what advice would you give yourself, now that you've had this experience, to set your mind right from the very beginning?

+ +

D'ONTRA: Oh God, there's so much. There's so [laughs] much. One of the major things that I would do differently is I would read more. And what I mean by that is there are lots of lots of people that have been here in this position and done that thing already. I think in the past year, I would say probably one of the most influential books that I've read is Zero to IPO by Frederic Kerrest. And I happened to listen to it in Audible.

+ +

But when you talk about, like, just things being pivotal, or like [laughs], going, "Oh, that makes sense," yeah, you get that because being an entrepreneur isn't new. And there are folks that have already kind of cracked the code in some regards. So, if you don't have the existing network around you already, go get the materials. Go read the books or listen to the audios of people who have been there, done that. It's going to save you so much time. So, that would be the number one thing that I would change is I would really truly read more and ingest other people's experiences more, and reach out and get mentors and advisors as you're going down this journey.

+ +

The second thing that I would do is–it's important to move fast when you're building a company. It's important to respond to the market and all that stuff. That's all super important. That's how you live or die, right? You treat it like there's a fire behind you, and you have to lead it. You have this really hot thing. You've got to be in front of it always, or you'll lose it. And sometimes what we miss is we miss the opportunity to do it faster or better by just slowing down just a little bit. And what I mean by that is, like, I mentioned earlier about looking at the data and things of that nature.

+ +

There may be things in the data that are making suggestions that you should go a different direction. But because of how you've built this thing, you and your co-founders, and how you guys have built these things in your head, that piece of data may not seem like it's very relevant. Sometimes, it's good to take a breath and take an assessment of where you're at.

+ +

So, when you're with your team, whether you're setting this up monthly, quarterly, whatever it is, make sure that you're taking some time to make sure that you guys are aligned around where your company is, the industry is, and the signs that you're getting inside the space that you're operating in. It's going to save you a lot of time.

+ +

And I think the last thing that is probably the most important is for those out there who are listening to this that are CEOs, one of my board members/life mentors/ CEO mentors, a friend, and almost like a father figure to me at this point, one of the things that he said to me and that I've never gotten out of my mind is that the CEO position is the loneliest position inside of an organization. And the reason why is even though you may start a business with your friends or people who aren't your friends, whatever it might be, whatever those relationships might be, those folks will never quite understand what it's like to sit in your seat because everything must end with you. It has to.

+ +

Every successful organization is going to rise or fall by the person that sits at the top. And because that burden is so heavy, oftentimes, we don't want to go and talk to people when things are going bad. We don't want to admit when, like, hey [laughs], this thing that we've sunk all these resources into isn't really working. And just the sheer pressure of being that person sucks sometimes.

+ +

With that being said, take care of yourself and your key relationships. And I'm not talking about key as in, like, strategic. I'm talking about the people that love you. Make sure even though you're going down this journey, you're making time for your friends, your family, your significant others, your kids, whatever it might be. Because business stuff aside, and we're all chasing the–Man, this is going to be really successful one day, and I'll be able to change everyone's life. Sure, we're all chasing that.

+ +

But there is a now moment. There is a person right now that might want your love or your attention, and do not rob them of that. Make sure that you're still making time for those things that are important. Because you could very easily start building a business and five years later, look up and go, oh, this thing didn't work. And then turn around, and there's a wasteland of relationships that you just didn't pay attention to. That's not worth it. So, make sure that you're not only showing, you know, the folks that support you some love but show yourself love by still nurturing those relationships.

+ +

VICTORIA: That reminds me I heard something about like, your rest ethic should be as good as your work ethic. And your rest ethic includes that time that you spend with family, or whether it's your religion, or your hobbies, or anything like that that makes you feel whole and like yourself, which I know can be a difficult thing to do when you're balancing starting a new business and thinking about the growth and the future all the time. So, I really appreciate that.

+ +

You know, you mentioned mentorship and these networking and relationships. Bringing it all the way back to Start Up San Diego Week, I'm curious if you have thoughts on how founders could get the most out of those types of events. And what draws you back to Startup San Diego or startup weeks in general?

+ +

D'ONTRA: Just as a caveat to all this, even though I'm on the podcast and stuff like that, and I'm sure if you Googled my name, you'll see that I've been on TV and stuff, I generally don't like networking [laughs]. I'm a major introvert. So, like, when you put me in an event like that, it's very hard for me to talk to people. Like, when we met, it seems that would be contrary to what I'm saying because we were strangers, and I came over, and we started chatting and stuff like that. And by and large, like, that's not always, like, an easy thing for me to do.

+ +

The reason why I'm saying that is that if you're that kind of person, do what you have to do to be more extroverted because sometimes that extroverted or that more open or welcoming side of you will allow for spontaneous interactions to occur. And so, when we think about events like, you know, Innovation Week or something like that, there's a lot of opportunity for you to either meet people that are on your journey or a similar journey like you who've been there done that, or even just to offer a different perspective.

+ +

And if you're in a place where you're open and constantly seeking, amazing things can happen, right? You could end up with your next co-founder. You could end up, you know, with your next investor. Or you could end up talking on a podcast with a stranger that you met just a few weeks ago, right? So, anything can happen. Keeping yourself open to the opportunity and the ability to extract as much value as you can out of those events.

+ +

It's really interesting to kind of have your pulse on what's going on, even if it's outside your industry. We're a FinTech, but I go, and I pay attention to things that are going on in aerospace or in health because it's always good to, one, not completely have yourself submerged in just your industry, even though that might sound really great.

+ +

People like folks that can talk about a myriad of different topics [laughs]. So, it might be useful if you can go and have a chat with a stranger about, you know, what's the latest in aerospace, right? It gets you out of the brain drain of what it is that you do on a daily basis. But also, you get to learn some new things and cultivate some new relationships.

+ +

VICTORIA: I love that. Yeah, I listened to...I think it's Happiness Lab episode where they talk about random conversations with people those, like, sparks of innovation or things like ideas you never would have thought of if you hadn't run into this random person [laughs] and talked to them for five minutes about, you know, what they do in health tech, or what they do for their consumer product that they're building. So yeah, I think that's great.

+ +

And I've been excited to be here in Southern California for the last three years and starting to grow that network and meet people like yourself who are doing really interesting things. I'm curious if you have any questions for myself or about thoughtbot, or the podcast, or anything.

+ +

D'ONTRA: Yeah. So, you say that you've been here for three years. Tell me a little bit about your journey, how'd you get here, and why you chose the podcast life, right? As one of your many things.

+ +

VICTORIA: That is one of my many things, right? So, I grew up in Washington, D.C., And my career was in tech and civic tech. I was working for big three-letter agencies and some pseudo-federal banks like FDIC, and Fannie Mae, and PBGC, all the acronyms all the time. And we got an opportunity in early 2020 to move here for my husband's job. And we moved out here, and I decided to take a switch out of the federal space and get into more commercial consulting.

+ +

And I was lucky enough to find thoughtbot; they had a position that just looked great for me. And when I joined, you know, we have an internal collaboration thing called Hub that I think our CEO wrote and writes with the other people. All the developers on our team all contribute to it. But he posted a message about this Giant Robots podcast and if anybody wanted to be a new co-host. And I was like, "Sure, I've done a little podcasting here and there, and I have a microphone, so I'm ready to go."

+ +

And little did I realize just how popular the [chuckles] podcast was. And it ended up being a really great avenue for me to meet people and, learn more about their stories, and build relationships in a way that has been really impactful and meaningful. And like I said, you know, you never know how someone you meet might help you [laughs]. So, sometimes I'll interview people, and I'll get an idea about something that is, like, exactly relevant to the work that I am doing that week, just total kismet however it came about. So, that's how I got into podcasting and how I'm in thoughtbot and here in Southern California.

+ +

And so, I'm super lucky that I live in a place where there's lots of events going on all the time and lots of great people to meet. Between LA and San Diego, you could go to a different event every single day, probably [laughs], and meet people who are working on cool stuff.

+ +

So, my background was really in operations and maintenance and taking federal agencies into more modern practices with digital services, and agile development, and DevOps. And now I'm taking kind of a similar lens but to commercial partners who are much faster and can make change quicker. And, in some cases, are doing things in even cooler ways than I could have thought and trying to think about how to move them forward with their infrastructure and how they deploy software.

+ +

D'ONTRA: That's fascinating. And, you know, it's difficult to be in Southern California, right? New events every day.

+ +

VICTORIA: And then yeah, I'll go walk my dog in the morning--

+ +

D'ONTRA: [laughs]

+ +

VICTORIA: And people are out there surfing. And I'm like, I could surf all day. I don't have to work [laughs].

+ +

D'ONTRA: Right?

+ +

VICTORIA: But I do. I got to work.

+ +

D'ONTRA: It feels like the world of limitless possibility, right? [laughs]

+ +

VICTORIA: Yeah. You almost feel, like, a pressure. Like, everyone else is starting their own company. Why am I not starting my company? Everyone's doing cool stuff all the time. So, you get motivated that way by being around a great group of people who are...everyone is very happy and sunny and [laughs] for the most part, the people are so nice.

+ +

D'ONTRA: Definitely a departure from the East Coast, right? And, like, I'm sure you came here with, like, that hustle mindset, where you're like, got to get it done, which is probably why you do, like, a million things. But then also, you have all of these people [laughs] that, like, I don't know, like, cares to the wind when they need to, right? Although you've got lots of successful people. But, sure, like, more or less down here, it's like, hey, you know, like, let's live life first and [laughs] make the dollars second.

+ +

VICTORIA: It's very casual. I got rid of all of my blazers. There's no more of that anymore [laughs]. People when they found out that I was moving to California, they were like, "That makes sense for you [laughs]," like, just the general, like, vibe.

+ +

D'ONTRA: [laughs]

+ +

VICTORIA: And I'm a rock climber. So, they're like, of course, you're going to go somewhere where the outdoors is prioritized, yeah. Versus when you live in D.C., it's like the news is happening to you.

+ +

D'ONTRA: Yes [laughs].

+ +

VICTORIA: And it's very, very close. So yeah, it's interesting. I love it, though. And it's cool to take experience from that and then apply it to this world and how people might think about stuff. So, I was worried that, like, my experience might not translate, but it has. It's been very helpful [laughs] in some cases, right?

+ +

Is there anything else that you would like to promote today?

+ +

D'ONTRA: Yeah, so, you know, maybe for a future conversation, but in line with, you know, your background and what you're talking about, I would love to have a discussion around CRA, the Community Reinvestment Act, for those who don't understand the lingo, right? Because Spare's latest, like, golden nugget that we've really been just, like, kind of moving on and we're talking to federal regulators about is actually our impact on banks and the Community Reinvestment Act.

+ +

For those who follow the news and know, you know, the time and space that we're in right now, there are some changes that are taking place inside of CRA. And it's very fascinating because when you say about your background of helping agencies kind of modernize things with digital, that's effectively what we're doing with our tech, and we're getting a lot of support from the government.

+ +

And so, you know, I think that we're really doing some very interesting things that are starting to get some really great attention. We recently partnered with Visa on one of our initiatives, and we're talking to a few other really large organizations and government organizations so that this technology can really be used at a scale, honestly, far beyond what I ever imagined. But when we talk about, like, actually helping people, we're doing it [laughs]. We're doing it in this very unique way, which I'm super stoked about. But maybe we'll have a chat about that in the future.

+ +

But I think, you know, for those of you that are listening to this and you're curious, you know, what it is that we're working on, feel free to reach out. It's gotspare.com. Feel free to email me: ceo@gotspare.com. I'm generally in that email box every day. Or even just checking out our service, you know, searching Spare on the App Store or Google Play, and just going in and giving it a test drive. And, you know, we're happy to hear your thoughts.

+ +

And for those of you who are out there that may be looking for a new experience, we are definitely growing this team, and we want to expand as quickly as we can. We have some really aggressive initiatives for the organization over the next 12-18 months. And so, we're not going to do it on our own. I'm super stoked to where we're, like, we're at a place where we're like, we're actively building [laughs]. We're actively moving. And so, if there was a [inaudible 38:44] for us, whether it's supporting us as someone who uses the application or supporting us as a merchant who's in our community.

+ +

There's lots of value that we're adding that we're turning back around to reach all small businesses. We're really working on combating inflation with our tech. And we've been able to do that, which is one of those really, like, refreshing byproducts of a tech company, or at least of our services. Like, we're actually adding real, true value to folks, and I'm super stoked about that.

+ +

VICTORIA: That's wonderful, and it's really close to my heart as someone who wants to see tech with purpose and who loves tech solving problems for people, especially groups of people that usually aren't the focus of founders who are trying to turn a quick buck, right [laughs]? The people who have real problems there's a real market there. It is a business, and it makes sense to start solving those problems. So, I'm really happy that you're working on it.

+ +

Thank you so much for coming in today and being a guest on the show. We will include all those links and wonderful ways to reach out and get connected with you in the show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: D'ontra Hughes.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + D'ontra Hughes is the Founder and CEO of Spare, which uses tech to solve cash management problems for unbanked small businesses and enterprises. D'ontra shares his entrepreneurship journey, driven by realizing the financial industry's impact on less privileged individuals.

+ +

D'ontra highlights a significant issue in the banking sector where the poorest people are often charged the most in fees, perpetuating poverty. Spare addresses the high fees unbanked individuals face when accessing their money. D'ontra's entrepreneurial journey involved various challenges, including learning from customer feedback, understanding the importance of data-driven decisions, and navigating the competitive startup environment.

+ +

The conversation also covers the impact of the COVID-19 pandemic on Spare, leading to a strategic shift and a focus on regions with high cash circulation. D'ontra emphasizes the importance of strategic planning, data analysis, and a systematic approach to business growth. He also discusses the personal aspects of being a CEO, stressing the importance of maintaining personal relationships and self-care.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is D'ontra Hughes, Founder and CEO of Spare, which uses tech to solve cash management problems for the unbanked small businesses and enterprise. D'ontra, thank you for joining us.

+ +

D'ONTRA: Well, thank you for having me.

+ +

VICTORIA: Well, wonderful. So, we met at San Diego Startup Week a few weeks ago. So, I'm excited to have you on the podcast today. Why don't you tell me what was your experience of San Diego Startup Week? And how did you come to be one of the speakers on a panel there?

+ +

D'ONTRA: Yeah, well, it's always a really nice thing to take part in, you know, kind of those innovative startup week events because you get to see a lot of what people are working on or what they're doing. So, we've been working very closely with the County of San Diego, especially with the city of Oceanside with our latest technology.

+ +

And, you know, there came this opportunity where I could get on the stage and kind of tell people about our journey a little bit, I think because we're becoming a little bit more successful or something [laughs]; I don't know what to say. We're getting better at what we're doing, apparently, and so folks wanted to hear what I had to say.

+ +

VICTORIA: I was able to catch your talk, and I thought what was really inspiring about it was that you came from the background of working in the financial industry and saw an opportunity to solve a problem that was common for other people and to be more fulfilled by the work you were doing. So, can you share a little bit about that?

+ +

D'ONTRA: I came out of a background in finance, as you said. I used to work for JPMorgan. It feels like a long, long time ago. And that was my last corporate job until I became an entrepreneur. You know, one of the things that I learned at that time...and not that the bank was doing anything wrong, but in the nature of finance, it's a business, right? It's got customers. It's got clients. It's got shareholders. And the most important thing is it's designed to make money.

+ +

There's always someone that loses, right? And sometimes you could say that that's the nature of business. But in this regard, it was a lot of people who lost that couldn't recover or wouldn't be able to recover from the financial waste that was left.

+ +

You know, I went on my entrepreneurial journey wanting to learn how to build a business and, you know, try to solve problems for myself or for other people. And specifically for this endeavor with Spare, which we launched back in 2015, we looked at the subset of the population, roughly about 25% of the U.S. population, 90-something million households of folks that were basically spending about 7% of their own income every year just accessing their own money. And, like, that's wild, right? Because if I came to you and I said, "Hey, if you got 100 bucks in your pocket, in order to pull that money out of your pocket, you got to give me $7," you'd be furious.

+ +

And so, the unfortunate thing is that this kind of tax on the poor was being facilitated by the ATM industry. At the time when we began the company, you had consumers out there going to an ATM roughly about seven times per month, withdrawing roughly about $60 per transaction. And the average fee at that time was $4.09. And today, the average fee is just about $4.80, something cents, depending on where you're at in the country.

+ +

And so, it's unfortunate the difference in these fees for these folks. It might sound absurd to say this, but it makes a difference between eating and not eating for some of these folks. And anyone who's a struggling college student or lives on the low end of the economic spectrum they understand what I mean by that, where the extra $30 or $40 in their pocket per month actually matters. It's an extra tank of gas or two tanks of gas, depending on what kind of car you're driving. And so, it matters.

+ +

We wanted to really take a really clean look, an assertive look at the relationship that, not just the ATM, but just cash management services or cash management on a local level the impact that it actually has.

+ +

VICTORIA: Yeah. And to kind of play that back a little bit, let's say you have a bank or you're not able even to get an account in a traditional bank. Maybe your bank doesn't have an ATM in your neighborhood, and you need to always go to a different ATM to get money out of your bank. And you're just constantly paying those fees. You're more likely taking out smaller sums of money, and then you have to do that over and over again. And it becomes a really high percentage of your income that goes just towards getting money out of the ATM.

+ +

D'ONTRA: Yeah, absolutely. So, when you consider even during the pandemic, right? Everyone's at home, but businesses were trying to figure out how to cut costs. And banks, just like any other business, when they have a retail bank branch that's in a neighborhood that's perhaps low income, they may not keep that bank branch around. And that's unfortunate because it creates an additional hurdle for folks to be able to become banked.

+ +

You may hear this term of banking deserts, and that's partially because folks have to travel too far, which is an external cost of time, and money, and resources, just to be able to put their money inside of a bank. Now, the additional cost for this particular demographic is that fees tend to add up. And we all know that the bank says, "Hey, as long as you keep $1,200 in your bank account, we're not going to charge you any fees." Well, that's really great, except for the person who is living paycheck to paycheck, right?

+ +

And so, this fee tax that's placed on them simply because they don't have enough money when you look at it, it's actually pretty rough [laughs]. I look at it, and sometimes I kind of laugh because it's absolutely absurd when you actually look at it on its face where the poorest people you're generating the most profits from. And unfortunately, those fees keep them in the cycle of being poor.

+ +

And so, it's been really great. Over the past few years, you've seen really great applications or neobanks come up that have acted as, you know, somewhat shields against all of these arbitrary fees, like, hey, no overdraft fees, and no account fees, ever, no monthly fees, and things of that nature, right? But they still aren't solving the other issues, some of the major issues.

+ +

So, it's really great that I have your debit card. But if you're a neobank, that means I either have to use your co-op ATM network, which is only going to allow me to withdraw cash so many times per month for free, or I have to use some other third-party ATM network. The unfortunate thing about that is they're still paying that fee [laughs]. At some point, they're still going to pay that fee, and when that money is better in their pockets, it's just a little rough. It's a little hard to digest. And so, we wanted to make sure we were doing something about it.

+ +

VICTORIA: Right. It reminds me of a phrase I come back to sometimes is that being poor is actually very expensive [laughs].

+ +

D'ONTRA: It is.

+ +

VICTORIA: There's a lot of fees, a lot of extra stuff you have to pay for that other people don't. I'm curious: how did you narrow in on this problem? Was it through doing some market research? Was it a personal experience that led you to wanting to work for these types of users?

+ +

D'ONTRA: Even though JPMorgan was my last, like, corporate job, I went out into the world to be an entrepreneur. Being an entrepreneur is expensive because you got to figure out how to pay bills. And so, one of the side gigs I had is I worked for a hotel in Santa Monica by the name of the Fairmont, and I was managing valet. For anyone who's been to the Fairmont in Santa Monica, it's not for the cheap folks, right?

+ +

But what would happen is, you know, patrons would show up, and they'd say, "Hey, I'm going to valet my car. I'm going to come back and pick it up." I'm going to go ahead and settle this up. But, you know, where's the nearest ATM so I can give the valet person cash?" And the most often answer was, "Well, there's one inside the lobby of the hotel, and then there's one across this very busy street." Both of these ATMs had a fee of...the one across the street was about $3.75 if you weren't a bank customer, and, of course, it wasn't a national bank. And then the one in the lobby was about $4.75, I think is what the fee was.

+ +

And so, here's the person who doesn't really carry cash that often being told that they have to pay a premium just to help this person out. And you could almost guess what the most likely outcome was is, unfortunately, that valet person just didn't get tipped. But the thing is, is there was actually a third source of cash, and it was actually in the valet's pocket or at the valet stand. So, there was money there in closer proximity. There just wasn't a mechanism of extracting it.

+ +

And so, our first look was, well, hey, can we monetize a transaction between, say, the valet stand and this consumer where, basically, the valet stand is selling these folks their cash for much cheaper than the ATM? So, it's going to save everyone time, energy, money, and it ensures that the valet folks get cash in their pocket. I can remember when we initially launched this; I thought it was such a brilliant idea. We created an app in which we would populate a map with all the people around you that had cash on them. So, when you say it out loud, --

+ +

VICTORIA: [laughs] Yeah. I could see how that might be problematic.

+ +

[laughter]

+ +

D'ONTRA: So, we're super stoked. We're, like, "Hey, we got this app, and it's really great. And, you know, look at all the people here that have money on them." So, we go to submit this thing to the App Store, and the legal team's like, "Absolutely not [laughs]." So, we spent about six months working back and forth with their legal team to come up with a model.

+ +

And it's somewhat similar to what you see today, where we're sending consumers to regular brick-and-mortar businesses that have spare cash on hand. That's it. Nothing glamorous about that. But the mechanism and the usefulness does some real overall good, not just for the consumers but for the businesses and for the local economy.

+ +

VICTORIA: Right. So, I was going to ask you, like, what surprised you in the early phases: the discovery process? It sounds like you had at least [laughs] at least one big strategic turn. But I'm curious if there was anything else that came up in your early-stage journey where you realized you had to make a pivot and change up what you were doing based on the feedback you got from users.

+ +

D'ONTRA: I'd love to be able to tell the story that we got it all right the first time around, but we didn't. I think we almost hit the checklist of things that you should not do. So, like [laughs], one example is you actually really truly shouldn't listen to your customer to some degree, right? So, you have the vision for this thing, but every customer has their idea of how your app should be better or something you should add.

+ +

And we went through phases where we were adding features then that people just weren't using. You know, it might have worked for, you know, 10% of the user base, but we had spent two or three weeks with the dev team putting in this new feature. And it was somewhat of a departure from the core. It's adjacent, and so we could justify it. So, we did it, but we shouldn't have. So [laughs], then we had to, like, backtrack on that. We had lots of these moments.

+ +

But I would say one of the most defining moments, and it was actually one of the first ones that came, was this moment in which one of early entrepreneurs' fear is that someone is going to steal your idea. So, we try to, you know, wrap folks up in NDAs, and secrecy, and things of that nature. You know, if you have a really solid idea, like, we all know that it has major potential to change your life.

+ +

And so, I can remember, you know, we went out, and we pitched this business to a venture capital company. It was very early on. That was my first lesson: people don't steal things that are worthless. And the second being that just because they steal, it doesn't mean they can build it. I can remember, you know, it took us six and a half months to get Spare in the App Store the first time around.

+ +

And during that time, we had met with this venture capital company looking for investors, angel investors. And it happened to be that this company gave us an offer to buy the company, and we said "No." But then were like, "Hey, why don't you come in and consult us, and let's see if we can work together to do a deal?" And me being super naive at that time, went in, and I said, "Hey, yeah. Like, this is how we would change the app, and this is what we would do."

+ +

And after two or three hours chatting with them, I had designed my competitor. And I didn't know that until a week later where they made their announcement, and, you know, I had Google Alerts on. And so, this app comes out and, you know, they're posting to see what people think about it. And they had gotten their app in the App Store, same business model, mind you. And I was just blown away [laughs]. Like, I think, at that time, I think I lost all composure. I was, like, sick to my stomach. I was furious.

+ +

When you asked about, like, the major pivot, it would have been in, like, my mindset because I went in thinking that we have this really great idea and how could anyone want to take something from an entrepreneur because starting is tough enough, especially the people that fund this stuff, right? And [laughs] I learned that, no, opportunities are opportunities, and people take them when they can.

+ +

And the bigger you become or depending on where your industry is, people are just looking for a shot. They're looking for an opportunity. No one really cares whether or not they're copying someone else's tech, right? If you were destined to do it, you would do it, and you would do it well, and you'd be one of the top ones to do it, right?

+ +

That was a major change in how I saw this journey, which allowed me to kind of reframe what we were doing and how I was approaching the market, how we collected data, how we dealt with our consumers, and how we ran our business in general. And then, we had to go in and pivot back to the conversation around the customer. So, we go back, and we're going back to build this thing. And so, at that time, I'm feeling, okay, I have to, like, do any and everything I can once we're in the App Store to get users and retain them.

+ +

And that's when I learned the lesson of, like, don't listen to all of your users. Like, know what your thing is, and do that thing really, really well. And try not to build features that aren't central to your core because, honestly, that can just get you in a lot of trouble. And you can waste a lot of time for no reason.

+ +

But I think the most important thing out of that is listen to the data, the information, and what I mean by that is where people go on a webpage, or where they go in your app, where they spend the most time. Listen to those things, and pay attention to the data, and somewhat become obsessed about utilizing the data to make your decisions. I think that'll save everyone a bit of heartache and, you know, pain as they go down that journey.

+ +

VICTORIA: Yeah, I really love that. There's a couple of, like, interesting points. I feel like when you said it can be daunting, like, oh, there's a million apps in there that already do this or, like, somebody else has already started this. Like, sometimes that means, well, it's a good idea because clearly somebody was willing to try and put it together, and they found a market. But you can always do it better, and you can always have a unique angle and try if you think there's a strong enough idea.

+ +

And I'm curious to, like, get more into, like, the data question and understand what do you use to understand how people are behaving in your app? And kind of metrics you look at to see how you're tracking and whether those are, like, key success measures or other ways that you think about that data.

+ +

D'ONTRA: For our application, you know, our KPIs were pretty simple very early on. It was like, do we have, like, the keywords that people respond to to find the application? And is it cash? Is cash the keyword? Is ATM the keyword? How do people find us, ultimately, at the end of the day? Because if you can solve that, solving what keywords are most attractive to your company, then what you're going to be able to do is organic traffic is going to be a lot easier to come by.

+ +

So, you don't have to spend a whole lot of money trying to get advertisements. There's going to be natural search traffic that drive people toward your platform. In addition to that, it was really paying attention to where the customer complaints were coming from because that told us a lot about the application. Even still, today, we have one very consistent customer complaint that, like, the unfortunate thing is, like, it's really difficult for us to solve this thing because it's actually more in the hands of the business than it is us.

+ +

And that major customer complaint is when I went into this active location, the person at the cash register didn't necessarily know what I was talking about, and there's a myriad of different reasons for that. But the primary one is that these locations typically have high turnover for the person that's working at the counter. And so Spare has to be an integral part of their onboarding this person so that when someone walks off the street, they can get the service that they need.

+ +

To some degree, listening or paying attention to the feedback that you're getting about the effectiveness of the service or being able to deliver the technology is actually a very useful data point. In addition to that, looking at where your app is available in cross-section with where the people are that are going to use your app. And this is one of the lessons, I think, we learned the hard way, where, you know, we came out the gate and said, "Hey, anybody and everybody can use this app. It doesn't matter if you're in New York, if you're in Texas, Midwest. It doesn't make a difference, right? Any and everyone can use it."

+ +

And the unfortunate thing is, when you do that, like, you're going to new users, which is really fun. It starts off that way. So, you go out, and you get merchants and things of that nature. And the mentality that we used was, well, we'll build it. The users will come, and the users will tell us where the businesses are or where we need to place businesses. So, we had a new person or a group of individuals show up in downtown Los Angeles. It was like, okay, cool, there's a concentration of people in Downtown LA. Let's go make sure we put businesses there. Well, that's faulty thinking in and of itself.

+ +

Even though you're getting the data points and the useful bits of data, you're actually doing it in pretty much, like, the wrong order [laughs]. We didn't really realize that, and Spare was my first tech company. And so, you know, when you think about things like that, like, you think, oh, users, they're important. But how you get them, and how you service them, and when you service them must be a strategic plan. You have to have that process thought out so that the user audience follows your plan, not you responding to them or following their informal plan.

+ +

VICTORIA: Yeah, that makes sense. And I love that, you know, focusing on the users and really focusing, like, on all of their unique needs like location [laughs] and other things like that. And I talk about that, you know, in my role as managing director at thoughtbot, I work on our DevOps and platform engineering team. I often talk about it in terms of, you know, very early in the process; you know enough about your user to tell you a lot about what their needs are going to be like on the infrastructure side, like their regional location, the sensitivity of the data, you know, that can tell you a lot about what you need to build [laughs].

+ +

So, I'm curious, you know, you're working on a financial app here. Have you also had to consider that from a regional perspective and from an infrastructure perspective how that affects your users?

+ +

D'ONTRA: Going into COVID and how we got there, was that we thought we were actually doing really well, right? So, we officially launched our platform to the marketplace in Q4 of 2018. And we did well for the initial launch without any marketing. And then a year later, we had done 3x the volume and had a strategic partner in place that would have grown our network by 30 times by the end of the next year, you know, we were moving.

+ +

And then COVID came along, right? In which, you know, huge event that no one planned for. It kind of put the company on halt while businesses were shut down, and we lost about 98% of our network at that time. So, we had to go back to the drawing board and kind of, like, figure out, well, one, if this company is really truly something that we know that there's a thing, we're going to continue to build it, but let's do it better this time around, like, what did we miss the first time?

+ +

And the first place that we went when we were trying to make this decision is we went to look up, like, cash effectively, like cash in circulation. And to our surprise, actually, there was more cash put into [laughs] circulation during COVID than there was at any other time in the past, like, decade, and so that was shocking. And so, we said, okay, cool. We know that cash is in circulation, perfect. Where is cash in circulation? And in addition to that, where should we start with the base of our technology? And how do we want to reconfigure this? And to be honest, we need help.

+ +

So, you know, we applied to Techstars, and we were super fortunate that we got into the Techstars Anywhere program. I think it was a lifesaver and a reboot for us and the company primarily because, you know, during the pandemic, we had lost, you know, over 70% of the folks that worked for the company at that time. So, going through that program helped us rethink a lot about strategy infrastructurel...how exactly we need to rebuild and reconfigure the company for success this next time around.

+ +

I think very early on, you know, we were just trying to do the business. We were just doing it rather than actually strategically building it. You know, that's the major difference between where we were versus where we are now is that everything that we do now is more methodical. When we look at, okay, where do we build merchant networks? Well, we're building them in a very strategic location. That particular location has this value to not only us as a company, the merchants in that area, but also the user base.

+ +

When we were able to take this more strategic position around, you know, how exactly we're building this business, we were actually able to see much larger opportunities that have always been there, but we just didn't see them. And so [laughs], I'm super grateful for, like, us kind of doing that recalibration because we were able to build a business that is ten times bigger than we initially thought that we were building.

+ +

VICTORIA: That's super interesting. So, yeah, like, pre-COVID, you're like, we'll get users, and then we'll figure out where to build. And then you had to, like, go through this full recalibration and focus on strategic regions, and that really opened up more opportunities and more growth than you had expected.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration, or click the link in the show notes for this episode.

+ +

VICTORIA: What does success look like for you six months from now or five years from now?

+ +

D'ONTRA: So, six months from now. We're hitting this hot streak with new clients and things of that nature. And we're going out, and we're pitching contracts that are bigger than I ever thought we would be able to pitch, honestly. And sometimes when I see the zeros on the proposals that we're sending out, there's part [laughs] of me that's like, oh, they're never going to say yes to this thing, but, one, they are, which is still shocking, even though we've gotten a few of these in.

+ +

And six months from now, I just want us to be doing it right. I know that sounds so arbitrary, and it sounds, like, so whimsical. But there are so many things that we're adjusting to in the marketplace and with our tech. Some of this is kind of new frontier for us. But what I would like to have happen is for the results in the next six months to indicate that we're doing it the right way and meaning that we have clients sticking around, we're still getting contracts signed, the network is growing, consumers are actually getting their needs met by our technology, and the company is growing at a rapid pace. That's what I'd like to see.

+ +

And granted, you know, we've, in the past, you know, few weeks here, we've doubled the size of the team, which is something that feels really great. But I want us to not lose sight of making sure that the team itself always has a common goal in mind, even as we're growing. And whether that's six months from now, 2, 5, 10 years from now, I want that to kind of be the core of the expectations of what I want this company to be able to do and to deliver.

+ +

VICTORIA: That's exactly the right attitude to have [laughs], right? It's like I want it to work. I want us [laughs] to, yeah, be successful. I think it all makes sense. You know, it's easy to come on a podcast, like, you know, you're eight years into the startup now, and you're starting to see some success. And it's like, here's how I did it. Everything sounds great. So, I'm glad you've also shared some mistakes or some things that you maybe would have reconsidered or done [laughs] differently before.

+ +

I'm curious: if you could travel back in time to when you first started, what advice would you give yourself, now that you've had this experience, to set your mind right from the very beginning?

+ +

D'ONTRA: Oh God, there's so much. There's so [laughs] much. One of the major things that I would do differently is I would read more. And what I mean by that is there are lots of lots of people that have been here in this position and done that thing already. I think in the past year, I would say probably one of the most influential books that I've read is Zero to IPO by Frederic Kerrest. And I happened to listen to it in Audible.

+ +

But when you talk about, like, just things being pivotal, or like [laughs], going, "Oh, that makes sense," yeah, you get that because being an entrepreneur isn't new. And there are folks that have already kind of cracked the code in some regards. So, if you don't have the existing network around you already, go get the materials. Go read the books or listen to the audios of people who have been there, done that. It's going to save you so much time. So, that would be the number one thing that I would change is I would really truly read more and ingest other people's experiences more, and reach out and get mentors and advisors as you're going down this journey.

+ +

The second thing that I would do is–it's important to move fast when you're building a company. It's important to respond to the market and all that stuff. That's all super important. That's how you live or die, right? You treat it like there's a fire behind you, and you have to lead it. You have this really hot thing. You've got to be in front of it always, or you'll lose it. And sometimes what we miss is we miss the opportunity to do it faster or better by just slowing down just a little bit. And what I mean by that is, like, I mentioned earlier about looking at the data and things of that nature.

+ +

There may be things in the data that are making suggestions that you should go a different direction. But because of how you've built this thing, you and your co-founders, and how you guys have built these things in your head, that piece of data may not seem like it's very relevant. Sometimes, it's good to take a breath and take an assessment of where you're at.

+ +

So, when you're with your team, whether you're setting this up monthly, quarterly, whatever it is, make sure that you're taking some time to make sure that you guys are aligned around where your company is, the industry is, and the signs that you're getting inside the space that you're operating in. It's going to save you a lot of time.

+ +

And I think the last thing that is probably the most important is for those out there who are listening to this that are CEOs, one of my board members/life mentors/ CEO mentors, a friend, and almost like a father figure to me at this point, one of the things that he said to me and that I've never gotten out of my mind is that the CEO position is the loneliest position inside of an organization. And the reason why is even though you may start a business with your friends or people who aren't your friends, whatever it might be, whatever those relationships might be, those folks will never quite understand what it's like to sit in your seat because everything must end with you. It has to.

+ +

Every successful organization is going to rise or fall by the person that sits at the top. And because that burden is so heavy, oftentimes, we don't want to go and talk to people when things are going bad. We don't want to admit when, like, hey [laughs], this thing that we've sunk all these resources into isn't really working. And just the sheer pressure of being that person sucks sometimes.

+ +

With that being said, take care of yourself and your key relationships. And I'm not talking about key as in, like, strategic. I'm talking about the people that love you. Make sure even though you're going down this journey, you're making time for your friends, your family, your significant others, your kids, whatever it might be. Because business stuff aside, and we're all chasing the–Man, this is going to be really successful one day, and I'll be able to change everyone's life. Sure, we're all chasing that.

+ +

But there is a now moment. There is a person right now that might want your love or your attention, and do not rob them of that. Make sure that you're still making time for those things that are important. Because you could very easily start building a business and five years later, look up and go, oh, this thing didn't work. And then turn around, and there's a wasteland of relationships that you just didn't pay attention to. That's not worth it. So, make sure that you're not only showing, you know, the folks that support you some love but show yourself love by still nurturing those relationships.

+ +

VICTORIA: That reminds me I heard something about like, your rest ethic should be as good as your work ethic. And your rest ethic includes that time that you spend with family, or whether it's your religion, or your hobbies, or anything like that that makes you feel whole and like yourself, which I know can be a difficult thing to do when you're balancing starting a new business and thinking about the growth and the future all the time. So, I really appreciate that.

+ +

You know, you mentioned mentorship and these networking and relationships. Bringing it all the way back to Start Up San Diego Week, I'm curious if you have thoughts on how founders could get the most out of those types of events. And what draws you back to Startup San Diego or startup weeks in general?

+ +

D'ONTRA: Just as a caveat to all this, even though I'm on the podcast and stuff like that, and I'm sure if you Googled my name, you'll see that I've been on TV and stuff, I generally don't like networking [laughs]. I'm a major introvert. So, like, when you put me in an event like that, it's very hard for me to talk to people. Like, when we met, it seems that would be contrary to what I'm saying because we were strangers, and I came over, and we started chatting and stuff like that. And by and large, like, that's not always, like, an easy thing for me to do.

+ +

The reason why I'm saying that is that if you're that kind of person, do what you have to do to be more extroverted because sometimes that extroverted or that more open or welcoming side of you will allow for spontaneous interactions to occur. And so, when we think about events like, you know, Innovation Week or something like that, there's a lot of opportunity for you to either meet people that are on your journey or a similar journey like you who've been there done that, or even just to offer a different perspective.

+ +

And if you're in a place where you're open and constantly seeking, amazing things can happen, right? You could end up with your next co-founder. You could end up, you know, with your next investor. Or you could end up talking on a podcast with a stranger that you met just a few weeks ago, right? So, anything can happen. Keeping yourself open to the opportunity and the ability to extract as much value as you can out of those events.

+ +

It's really interesting to kind of have your pulse on what's going on, even if it's outside your industry. We're a FinTech, but I go, and I pay attention to things that are going on in aerospace or in health because it's always good to, one, not completely have yourself submerged in just your industry, even though that might sound really great.

+ +

People like folks that can talk about a myriad of different topics [laughs]. So, it might be useful if you can go and have a chat with a stranger about, you know, what's the latest in aerospace, right? It gets you out of the brain drain of what it is that you do on a daily basis. But also, you get to learn some new things and cultivate some new relationships.

+ +

VICTORIA: I love that. Yeah, I listened to...I think it's Happiness Lab episode where they talk about random conversations with people those, like, sparks of innovation or things like ideas you never would have thought of if you hadn't run into this random person [laughs] and talked to them for five minutes about, you know, what they do in health tech, or what they do for their consumer product that they're building. So yeah, I think that's great.

+ +

And I've been excited to be here in Southern California for the last three years and starting to grow that network and meet people like yourself who are doing really interesting things. I'm curious if you have any questions for myself or about thoughtbot, or the podcast, or anything.

+ +

D'ONTRA: Yeah. So, you say that you've been here for three years. Tell me a little bit about your journey, how'd you get here, and why you chose the podcast life, right? As one of your many things.

+ +

VICTORIA: That is one of my many things, right? So, I grew up in Washington, D.C., And my career was in tech and civic tech. I was working for big three-letter agencies and some pseudo-federal banks like FDIC, and Fannie Mae, and PBGC, all the acronyms all the time. And we got an opportunity in early 2020 to move here for my husband's job. And we moved out here, and I decided to take a switch out of the federal space and get into more commercial consulting.

+ +

And I was lucky enough to find thoughtbot; they had a position that just looked great for me. And when I joined, you know, we have an internal collaboration thing called Hub that I think our CEO wrote and writes with the other people. All the developers on our team all contribute to it. But he posted a message about this Giant Robots podcast and if anybody wanted to be a new co-host. And I was like, "Sure, I've done a little podcasting here and there, and I have a microphone, so I'm ready to go."

+ +

And little did I realize just how popular the [chuckles] podcast was. And it ended up being a really great avenue for me to meet people and, learn more about their stories, and build relationships in a way that has been really impactful and meaningful. And like I said, you know, you never know how someone you meet might help you [laughs]. So, sometimes I'll interview people, and I'll get an idea about something that is, like, exactly relevant to the work that I am doing that week, just total kismet however it came about. So, that's how I got into podcasting and how I'm in thoughtbot and here in Southern California.

+ +

And so, I'm super lucky that I live in a place where there's lots of events going on all the time and lots of great people to meet. Between LA and San Diego, you could go to a different event every single day, probably [laughs], and meet people who are working on cool stuff.

+ +

So, my background was really in operations and maintenance and taking federal agencies into more modern practices with digital services, and agile development, and DevOps. And now I'm taking kind of a similar lens but to commercial partners who are much faster and can make change quicker. And, in some cases, are doing things in even cooler ways than I could have thought and trying to think about how to move them forward with their infrastructure and how they deploy software.

+ +

D'ONTRA: That's fascinating. And, you know, it's difficult to be in Southern California, right? New events every day.

+ +

VICTORIA: And then yeah, I'll go walk my dog in the morning--

+ +

D'ONTRA: [laughs]

+ +

VICTORIA: And people are out there surfing. And I'm like, I could surf all day. I don't have to work [laughs].

+ +

D'ONTRA: Right?

+ +

VICTORIA: But I do. I got to work.

+ +

D'ONTRA: It feels like the world of limitless possibility, right? [laughs]

+ +

VICTORIA: Yeah. You almost feel, like, a pressure. Like, everyone else is starting their own company. Why am I not starting my company? Everyone's doing cool stuff all the time. So, you get motivated that way by being around a great group of people who are...everyone is very happy and sunny and [laughs] for the most part, the people are so nice.

+ +

D'ONTRA: Definitely a departure from the East Coast, right? And, like, I'm sure you came here with, like, that hustle mindset, where you're like, got to get it done, which is probably why you do, like, a million things. But then also, you have all of these people [laughs] that, like, I don't know, like, cares to the wind when they need to, right? Although you've got lots of successful people. But, sure, like, more or less down here, it's like, hey, you know, like, let's live life first and [laughs] make the dollars second.

+ +

VICTORIA: It's very casual. I got rid of all of my blazers. There's no more of that anymore [laughs]. People when they found out that I was moving to California, they were like, "That makes sense for you [laughs]," like, just the general, like, vibe.

+ +

D'ONTRA: [laughs]

+ +

VICTORIA: And I'm a rock climber. So, they're like, of course, you're going to go somewhere where the outdoors is prioritized, yeah. Versus when you live in D.C., it's like the news is happening to you.

+ +

D'ONTRA: Yes [laughs].

+ +

VICTORIA: And it's very, very close. So yeah, it's interesting. I love it, though. And it's cool to take experience from that and then apply it to this world and how people might think about stuff. So, I was worried that, like, my experience might not translate, but it has. It's been very helpful [laughs] in some cases, right?

+ +

Is there anything else that you would like to promote today?

+ +

D'ONTRA: Yeah, so, you know, maybe for a future conversation, but in line with, you know, your background and what you're talking about, I would love to have a discussion around CRA, the Community Reinvestment Act, for those who don't understand the lingo, right? Because Spare's latest, like, golden nugget that we've really been just, like, kind of moving on and we're talking to federal regulators about is actually our impact on banks and the Community Reinvestment Act.

+ +

For those who follow the news and know, you know, the time and space that we're in right now, there are some changes that are taking place inside of CRA. And it's very fascinating because when you say about your background of helping agencies kind of modernize things with digital, that's effectively what we're doing with our tech, and we're getting a lot of support from the government.

+ +

And so, you know, I think that we're really doing some very interesting things that are starting to get some really great attention. We recently partnered with Visa on one of our initiatives, and we're talking to a few other really large organizations and government organizations so that this technology can really be used at a scale, honestly, far beyond what I ever imagined. But when we talk about, like, actually helping people, we're doing it [laughs]. We're doing it in this very unique way, which I'm super stoked about. But maybe we'll have a chat about that in the future.

+ +

But I think, you know, for those of you that are listening to this and you're curious, you know, what it is that we're working on, feel free to reach out. It's gotspare.com. Feel free to email me: ceo@gotspare.com. I'm generally in that email box every day. Or even just checking out our service, you know, searching Spare on the App Store or Google Play, and just going in and giving it a test drive. And, you know, we're happy to hear your thoughts.

+ +

And for those of you who are out there that may be looking for a new experience, we are definitely growing this team, and we want to expand as quickly as we can. We have some really aggressive initiatives for the organization over the next 12-18 months. And so, we're not going to do it on our own. I'm super stoked to where we're, like, we're at a place where we're like, we're actively building [laughs]. We're actively moving. And so, if there was a [inaudible 38:44] for us, whether it's supporting us as someone who uses the application or supporting us as a merchant who's in our community.

+ +

There's lots of value that we're adding that we're turning back around to reach all small businesses. We're really working on combating inflation with our tech. And we've been able to do that, which is one of those really, like, refreshing byproducts of a tech company, or at least of our services. Like, we're actually adding real, true value to folks, and I'm super stoked about that.

+ +

VICTORIA: That's wonderful, and it's really close to my heart as someone who wants to see tech with purpose and who loves tech solving problems for people, especially groups of people that usually aren't the focus of founders who are trying to turn a quick buck, right [laughs]? The people who have real problems there's a real market there. It is a business, and it makes sense to start solving those problems. So, I'm really happy that you're working on it.

+ +

Thank you so much for coming in today and being a guest on the show. We will include all those links and wonderful ways to reach out and get connected with you in the show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: D'ontra Hughes.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MZhYsonQ + + ]]> + + Victoria Guido + D'ontra Hughes + + + thoughtbot's Incubator Program Mini Season 3 - Episode 05: Knect with Josh Herzig-Marx + https://podcast.thoughtbot.com/s3e5incubatorknect + 5ea26396-39b8-498b-b76b-bec44c3c6016 + Tue, 12 Dec 2023 00:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + In the third interview with Josh, Lindsey Christensen, head of Marketing at thoughtbot, and Jordyn Bonds, head of the Incubator Program at thoughtbot, discuss the progress of Knect in the thoughtbot Incubator Program. Most of the conversation involves identifying and focusing on the right target audience. Initially, they considered startup enthusiasts, but after exploring other segments like journalists, they returned to startup enthusiasts with a more refined focus. Josh also talks about developing a prototype and its usefulness in getting feedback and refining the product concept. + +The technical feasibility of integrating various communication platforms into their solution is a significant focus. They examined different platforms like email, LinkedIn, WhatsApp, Telegram, and SMS to determine which integrations were essential for the minimum viable product. Looking forward, Josh outlines the next steps for the program, which include finalizing high-quality prototypes and making strategic decisions about the scale and funding of the project. + 27:30 + no + + + If you missed the first and second episodes with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can listen to Josh's first episode (https://www.giantrobots.fm/incubators3e1josh) and his second (https://www.giantrobots.fm/s3e3incubatorjosh) to catch up. +In the third interview with Josh, Lindsey Christensen, head of Marketing at thoughtbot, and Jordyn Bonds, head of the Incubator Program at thoughtbot, discuss the progress of Knect in the thoughtbot Incubator Program. Most of the conversation involves identifying and focusing on the right target audience. Initially, they considered startup enthusiasts, but after exploring other segments like journalists, they returned to startup enthusiasts with a more refined focus. Josh also talks about developing a prototype and its usefulness in getting feedback and refining the product concept. +The technical feasibility of integrating various communication platforms into their solution is a significant focus. They examined different platforms like email, LinkedIn, WhatsApp, Telegram, and SMS to determine which integrations were essential for the minimum viable product. Looking forward, Josh outlines the next steps for the program, which include finalizing high-quality prototypes and making strategic decisions about the scale and funding of the project. +Transcript: +LINDSEY: Hi, everyone. +JORDYN: Hi. +LINDSEY: Thanks for tuning in and joining. We're going to be checking in on one of our incubator program participants today. If you haven't joined us before, thoughtbot runs a startup incubator, about an eight-week program for the early, early, early-stage company, idea, founder project to validate that business, find the market, and start thinking about how you build that thing. +So my name is Lindsey Christensen. I head up Marketing here at thoughtbot. And today, I am joined by Jordyn Bonds, who heads up the incubator program at thoughtbot. And our guest of honor checking in once again, Josh Herzig-Marks, Founder of Knect, the company going through the program. Thanks for joining. +JOSH: Super excited. I'm always excited. +LINDSEY: How's it going? How is your founder sentiment this week? +JOSH: This -- +LINDSEY: Are you on a high? Are you on a low? +JOSH: I don't think I'm on a typically high-high. I'm a pretty even-keeled, chill founder. I think it's appropriately enthusiastic but not excessively so, and definitely not at a low trough. +LINDSEY: All right, even-keeled. We love to [crosstalk 01:19]. +JOSH: Appropriately enthusiastic because we're doing really cool stuff. And this is a lot of fun. +LINDSEY: Well, that's great. So, I mean, [inaudible 01:25] that you're working on and especially the last time I checked in with you in the really early stages, trying to find that target niche audience or invalidate, like, the problem with them. How is that going? How's that search for the people with the problem going? +JOSH: Yeah. So just to, like, rewind the clock for the folks who maybe haven't seen every one of these, you know, there's a few things that I was trying to figure out to validate whether this problem that I saw was an opportunity for business. And, Jordyn, help me out if I forget some of these. +So, number one, is this a Josh problem, or is this problem more broad? Question number two is, could we find an audience of people who are reachable, who share the problem, and who'd be willing to actually pay for this thing? And those little asterisks after pay, right? People pay for things with money but also with time or with reputation. Generally, we're thinking about money here, ultimately. But do they pay for this thing even in time? Would they be able to do that? +And the reason we're looking for that kind of a more narrow audience is because you got to build for somebody in the very beginning. This isn't, like, we're limiting ourselves to a narrow audience forever, but we wanted a set of people who we could design this thing for, have prototypes, share it, and hopefully get some consistent feedback so we can build a thing which they would find useful and use that from there. That was two things. +And the third thing: is this actually technically feasible? You know, the first time I was a founder, incidental to building our business, we built the world's fastest online transaction processing database that was processing, like, billions and billions of retail records in, like, the time it takes you to, like, click and drag and change the query that we're doing, which is really cool to say out loud, and it demoed really, really well. But that isn't actually a business. +And what I wanted is part of validating if this idea, if this problem was an opportunity or something that wasn't a science experiment. And I'd love to talk a little bit more about what we've been doing over the past week, maybe a little later on in this. Because I think it's been a big week for the science experiment or not validation stage of this thing. +So, two things we've also done over the past week and a half, two weeks since the last time we chatted, we have a prototype, which looks pretty good, which we can now use to show to people who we think are our core starting audience, our core starting market, and we actually have a core starting market. Both of these things are pretty exciting. I mean, I'm always excited. But we're doing it, like, we're doing the thing that we're supposed to be doing, and I like that. +LINDSEY: That's really exciting. So, core starting market is happening. Do you want to talk about maybe how you got there? +JOSH: One of the reasons why I was excited about doing this program is Jordyn, and I share the understanding of its importance. But when you're, like, actually the founder, it's really hard to see this, right? Jordyn is like the...I don't know quite how to describe it, but Jordyn is the person who, like, made sure we stayed focused on this part of the effort. And, like, it's a really key part of the thoughtbot incubator. And it's one of the reasons why I'm really appreciative of having gone through the program. +JORDYN: So, Josh walked into the program with a problem that he had, which is frequently how products get made and companies get founded. Like, that's fine. It's a great starting place. And as he listed, his question was, is this a Josh problem, or is this a problem for more than just Josh? Because Josh isn't a market segment. Josh is an individual human [laughs]. And a lot of us have product ideas that we would love to have exist so that we can use them, but that doesn't make them good market opportunities. I may or may not be speaking from experience in that regard, ahem. Anyway, so part of the programming here was to figure this out. +And it's great to start with, like, okay, well, if Josh is our primary user, who is Josh? Is there a market of Joshs, right? So, we actually started off talking to those folks. And, you know, we're human beings, and we tend to hang out with people like ourselves. And so, Josh knew a lot of people like Josh. +One of those people that he knew was me. I am like Josh in regard to this pain point. I also had it. And then I was connected to a bunch of people who had this pain point. So, we broadly spoke to a lot of those folks at first. I don't know that we really had a persona name for this. I don't know, how would you frame this? +JOSH: As you know, I only have poor pejorative names for people like us. +JORDYN: [laughs] Pejorative? +JOSH: There's, you know, a class of people who are at tech companies and startups, and sometimes they start their own companies, and sometimes they work at companies. And sometimes they do coaching. And sometimes they do a little bit of an investment. And sometimes they're on advisory boards. And, you know, when you kind of smoothly move from one thing to the next, sort of often doing several of these things all at the same time. +And there's not a really good name for them, but they're kind of people, like I might go so far to say the three of us, and maybe a lot of people who work at thoughtbot and a lot of people we've all worked with in the past and, hopefully, a lot of the people who are listening to this conversation because they, too, could slip into the founding a company stage of this business. +JORDYN: So, we've kind of loosely called those people, most recently, startup enthusiasts is our nickname, and there are a lot of folks under that umbrella. But as we talked to those people at this kind of high level, it was very broad. That maybe sounds fairly specific to some of you out there listening, but it's not specific, nearly specific enough to address with a product. +So, we were talking. We were listening, getting people to talk to us, "Hey, tell us about how you keep in touch with folks. How does that go? What do you do? Have you ever built your own spreadsheet to keep track of people you know? Tell us about that." Broad questions. And we were learning things and hearing about trends. It wasn't coming into focus. We weren't hearing enough repeatable things. And we certainly weren't hearing about red, hot pain points. It was like a, "Yeah, this is kind of a problem sometimes, but not all the time. My system works more or less [inaudible 07:11]. +Then we kind of found this range of personas. Some folks were just like, "I'm awesome at this. It's not a problem. I don't know what to tell you." Okay, well, clearly, that person doesn't need a product because they're feeling good. Great. At the other end of the spectrum, you have people who are just like, "I don't even know what you're talking about [laughs]. Like, this isn't [laughs]..." +There were people who were like, "I know what you're talking about, but I'm good at it." There were people who were like, "I don't know what you're talking about. I don't care to ever do this." And then, there was this broad set of people in the middle who were like, "Yeah, I have a problem with this." But we were hearing a lot of different things. +In the course of that, Rami, one of the folks on the team, ended up talking to a journalist. And that conversation was very interesting because it did seem like way more of a red, hot pain point with, like, something on the line. And we were like, oh, maybe we've been barking up the entire wrong tree and, like, startup enthusiasts aren't our people; journalists are our people. So, then we did a whole sprint with journalists and realized that journalists is a very broad umbrella [laughs]. There's a lot of different kinds of journalists in a lot of different kinds of contexts. And they have widely varying pain points, habits, needs, wants. +We were like, okay, we're hearing some really interesting things in here, but they don't seem like early adopters because they are not the kind of people that just try an app who are just like, "Sure, new app, cool. I'll try that." Startup enthusiasts are people who just, like, try stuff. They're, like, on Product Hunt. They're friends with a bunch of founders, and those founders are, like, "Try this." And then they're like, "Sure, okay. Sure, I'll try it. I'll login." Login to anything once, right? Is kind of the attitude of this group of people, journalists not so much. +And so, it felt like it was going to be a really hard thing to address those folks. But we learned a ton. And we really ended up mapping the emotional train in a lot of detail. And as a group, like, we came to a lot of alignment. There was a lot of, like, really good understanding, deeper understanding having gone on that journey. But where we ended up back was like, okay, startup enthusiasts really actually seem like [laughs] a place to start. And it feels like there's enough of them that they could create some kind of early adopter market. +But now, with the information that we had, the new information we had, we were like, let us sub-segment this group of people. It's not everybody in that umbrella. Doing that whole journey enabled us to kind of come back to the question with renewed focus, but, like, conviction about how valuable it was going to be to do that, right? And sometimes that's what it takes. You kind of have to do the wrong thing for a second to appreciate doing the right thing, and that's totally fine. The fact that we were able to do that in, what, five weeks is, like, fine. +JOSH: And I think the way that we found the sub-segment that made sense was actually pretty simple, right? Once we understood what are the dimensions that are actually important, we did a quick brainstorming session. This wasn't actually a very long process at the end of it, a quick brainstorming session. What are the different kinds of people who fall into this segment? +And we just scored them on all the easy things you'd expect to score people on, namely: are they easy to find and easy for us to reach? Do they advertise this quality of theirs someplace publicly, like, perhaps on LinkedIn? And are they easy to find? Like, do we have enough of them inside of our network so we could, like, search for these kinds of folks? And as it turns out, we've already spoken to a lot of these kinds of folks as well. And primarily, we're talking to repeat founders and/or chiefs of staff at startups. +JORDYN: If you are one of those people, please reach out to us. We'd like to talk to you. +JOSH: We would love it. +LINDSEY: Call to action. So, Josh, you mentioned one of the benefits of the program has been Jordyn's ability to kind of laser-focus on finding the target market. Jordyn, how do you do that? How do you keep the team coming back to that? Especially as sometimes it maybe doesn't take that long—sometimes it might feel like you're kind of circling around and around and still aren't finding anyone—and keeping folks motivated to do that or understanding, you know, when are we going to say, "This is it, you know, we're not finding someone"? +JORDYN: I'll talk about how it worked in this case. And every team is different and is motivated by different things. And this process is a little different every time, so it's hard to make generalizations. But in this case, what was interesting is that after we did our journalist sprint and we were like, we do want to refocus on startup enthusiasts, but we need to understand a little bit better what we're doing, we actually prototyped a little bit given what we knew, which seems like a bad idea [laughs] on the face of it. It seems premature. +The purpose of doing that, then, was to really take a different path to drawing out of each of us what was in our lines. That's, like, so much of the work of a team at this stage is, like, making sure that we're externalizing the things that we're thinking and the assumptions that we have. And it's strange. You would think you would just be like, "Hey, tell me what's in your mind?" But minds don't work that way. You can't just be like, "Hey, mind, what's up?" And then articulate it perfectly in a way that everybody in this group is going to know what you mean. +So, prototyping actually drew a bunch of that stuff out. It really...I think that was the moment...I don't know, Josh, how you feel about it. We had been kind of in the doldrums because we did get to the end of that journalists' sprint. And we were like, what are we doing? What have we learned? And prototyping at that moment enabled us to...it was a different way of understanding what we had learned and what we were all now thinking. And it really drew a bunch of dynamics out that it was super helpful. +JOSH: It brought some real sharpness to what we thought we'd be able to...the kind of value we thought we could deliver in the early versions of this thing, right? Fast forward two years, who knows? But it brought some sharpness to the kinds of problems that we thought we'd be able to fix and the kinds of problems we thought we couldn't solve. And that also clarified for us, certainly for me, why, oh, here's why this isn't really landing with the journalists, right? And here's why this isn't really landing with some other kinds of folks we were talking to. And -- +JORDYN: Biz dev folks. We talked to a bunch of biz dev folks. It wasn't going to land with them, but yeah -- +JOSH: They weren't at all excited about it, and then we can kind of understand why. One of the ways that I think about a prototype and I talk about this a lot, and I love doing this. Somebody called this a Pinocchio prototype, the wooden child who wants to be a real boy. Once we had a prototype, we could actually put it onto our actual phones. +And I'm not sure how many other people did this on the team besides me but, like, I would carry my phone around with a prototype on it. And every time I thought I might use it, I would pull the damn thing out of my pocket and, like, tap away on the phone. It gave me, again, a very clear sense of the kinds of things I thought we were moving towards solving and the kinds of things that we weren't really solving. +LINDSEY: Yeah, Josh, you mentioned there were some exciting developments in the past week. Is that around the prototype? +JOSH: This is one. Having the prototype on there was good. It's also really nice to have this be part of a larger team. I was having a hard time. I had been playing with, like, our design team's paper prototype. I was having a hard time communicating what I was trying to do inside of my head. So, I built my own parallel prototype in Google Slides, which was exactly as awesome looking and as functional as everybody listening is imagining it must have been. If you would like your own copy of my Google Slides app development template, please reach out. I will share it [laughs]. +But it let me think a little bit, again, the same thing, like, here's how these things fit together. And then it started moving really, really fast. Once we were all putting things down in a way that we could play with, and touch, and talk about in a concrete way, it felt like that part of things started to move really fast. And the quality of our conversations improved with people we were talking to as well. I would say that's half of the things that are really exciting. +LINDSEY: Just to continue on the prototype for a second, Jordyn mentioned a major outcome of starting to use the prototype; well, I guess [inaudible 14:37] that you all as a team got better aligned around what you were envisioning for the solution. And then, it also helped you, again, kind of identify the true target market. Are there other things you're already learning from using the prototype and getting it in front of people? +JOSH: Yeah, I think there are. By the way, this shouldn't be surprising. This is, like, the classic diverge-converge model that I know thoughtbot uses all the time with not just startup clients when you're building something new. One of the things which, you know, rewind the clock six and a half weeks ago to when we started this thing. I didn't realize how much intelligence would be required behind the scenes to make this thing actually sensible to the final users. +And the more we show it to people, the more we realize that, like, intelligence to make things look simple is going to equal people actually using the damn thing. I think we started to see that ourselves in playing with it. But it's really important to have that be validated by actual potential users who aren't, like, in this shit themselves. +JORDYN: I mean, immediately, you know, we were able to start showing the prototype to the folks that we were having interviews with, and there's just nothing better than that because they're not going to pull their punches with you. And we got a lot of great immediate sort of spicy feedback [laughs] from people, especially if you're showing them to people who are, like, startup people [laughs], they're just not going to be nice. And so, there was a lot of [crosstalk 15:59]. +JOSH: They're like, "Have you considered making this suck less?" +JORDYN: Yeah, exactly. "I wouldn't use this at all [laughs]." You're just like, "Okay, thanks." Tell me how you really feel [laughs]. But it's great. I mean, like, there's nothing better than that. Like, I would way rather that than a bunch of people trying to be polite. +JOSH: And it also prompts feedback that we wouldn't necessarily have thought of, which is the idea of this. We [inaudible 16:20] thought of this on our own. Like the idea that sometimes you might want to not take an action when you don't really care about a person. But sometimes you really, like, dislike a person so much who you've been talking to you want to never see them again, right? Never show me this person again. It's a thing that we never would have come to, I think, if we hadn't, like, actually been showing the prototype to end users. +LINDSEY: Okay, what is the second half of the exciting thing that happened in the past week? +JOSH: This is very much a thoughtbot thing. thoughtbot is full of really talented engineers. And over the past couple of days, we've been able to bring a lot of those folks to bear on the question of like, is this thing technically feasible or not? Which was one of my big concerns. And it turns out, that was probably too large a question for the team that we started with. +And to be able to, like, do this, like, little discovery spike with, you know, going beyond the three-and-a-half thoughtboter team that we had to some of your most talented, most experienced engineering leads, not forever, but just for, like, a short moment is kind of, for me, at least, like, a real taste of, like, the thoughtbot value is, you know, Jordyn gets to put out a call for assistance, you know, across the company, and people raise their hands and put real-time in. +And, you know, we're able to do something in a couple of days that we probably couldn't have done because we have enough people. And, you know, all those, like, network effects of people coming together that could have taken us, you know, weeks or longer just kind of toiling on our own. +LINDSEY: For those technical challenges, maybe you don't want to get into specifics, but in broad strokes, can you talk about what some of those considerations are? And maybe at this point, maybe it makes sense to also talk a little bit about, like, how the solution, how you're thinking about the evolution of what the solution is and provides. +JOSH: I have an Android phone. I live in the world as a green bubble in a world of blue bubbles. My partner and I are in an interfaith relationship. She has an iPhone. I have an Android phone. And forever, people are accidentally trying to hit up my, like, iMessage account tied to my email address, and the things don't come through. And, all of a sudden, this company someplace in the U.S. figured out some way to, like, reverse engineer the Apple messages iMessages protocol, so I can put iMessages onto my Android phone. They built this thing. It's been, like, all over the tech news recently. +This is the problem, if you're trying to bring together all of somebody's social network, is that there is no, like, handy-dandy API for iMessages. There is no handy-dandy API for regular SMS or RCS or any of those other variations of that. There is no handy-dandy API for WhatsApp, for Telegram, sort of ish, kind of maybe for Slack, not really for Discord. It remains to be seen how mature it is for LinkedIn. By the way, email works great, right? If we just build our entire lives off of email, we'd have none of these problems, but we can't. +And we had some hypotheses about ways that we could make connecting these other accounts easier. And we just took, like, an awful lot of hands, right? More than two hands. It took more than two hands to figure out if these things were possibilities if those things turn out to be true. And the answer is if they are true, which we're still working to figure out, though it's looking better and better, this isn't a science experiment, right? And if it's not true, then step one is an awful lot of engineer hours to go do what those Beeper Mini folks did and reverse engineer a whole bunch of protocols and systems that were never intended to be open in the first place. +JORDYN: I would like to say -- +JOSH: Which is why we should all donate to EFF and promote an open internet so that startups like mine don't need to exist. +JORDYN: To loop back to your earlier question, Lindsey, about how to keep the team focused on who something is for, this conversation seems like it's not about that. But, to me, this conversation is also about that because we have a long list of messaging platforms that we have heard from folks, like from interviewing them would be useful to have brought into a single place. +This was one of the key pain points that Josh has that we heard from other people, which is, like, you connect with people across platforms, right? You might be connected to some on LinkedIn, but you're also emailing with them. Your email history with them is not a complete history of your life with them. None of your online stuff is going to be a complete history because sometimes you actually interact with people [laughs] in reality, which is still, at this moment, not being recorded all the time, but probably not for long. +JOSH: As little as possible. +JORDYN: [laughs] But still, even within the online world, you're communicating with people across platforms. Maybe you text with someone, maybe you message on LinkedIn, whatever. And having complete context for your relationship with them in a way that makes it really easy to kind of, like, boot up that context in order to reach out to them for some reason, like, maybe you haven't talked in six months, and you just want to remember, where did I leave this relationship? What's going on with this person, right? You're like, where was I talking to them? Oh, I was talking to them in these four places that don't have very good protocols for being brought into the same interface, right? So, like, the stuff is, like, all connected. +But to get back to the who question, we have this list of places we'd heard from people, like, in the early interviews and places that Josh was trying to do this connect with people, et cetera. So, it's, like, Slack DMs, and it's email, and it's LinkedIn, whatever. But we also heard Telegram, and we also heard other things. If we don't sufficiently focus on a narrow enough group of people, we risk making the MVP way too big because it needs to connect with every one of these things. And we can't go to market with something that doesn't connect with 12 platforms or something, right? +But because we're sufficiently focused, we could actually do the thing where we're like, okay, well, out of this list of platforms, what are, like, the top five? Where is the line? Where's the minimum viability here with what we can connect with that will actually bring value? And I also am an Android user living in an iPhone world. And Josh and I at least have enough awareness to be like, you know what? Maybe Android isn't necessary, even though we would love [laughs] for it to be there. Nine times out of 10, the people that look like us are using iPhones, right? So great, cool. Let's just do the thing. +JOSH: Obligatory iPhone test device. +JORDYN: Right. I have one, too, but I don't know where it is. So, like, the question of who really matters. Who, like, really helps you focus? If your answer to "Who?" is anybody with a smartphone, well, like, it's going to be really tough to build an actual MVP that's buildable. So, this question that Josh brought in to us, which is, like, "What's technically feasible here?" really intersects very directly with this question of who are we building for? Because you really want to be able to start somewhere. +And, you know, if you have a sufficiently red, hot need and it's not, like, to time travel or something that is, like, probably impossible given the laws of our universe, you can find a way, right? And so, the question was, like, why don't we find that so that we can focus on whether it's worth finding a way? And then that intersection of who it's for, what their pain points are, and what's possible with what amount of effort. It all fits together. No single one of those pieces is sufficient for figuring out a path forward. +LINDSEY: And are you taking the, you know, okay, we've gotten really good sight on these startup enthusiasts, and these are their top four communication methods; let's try to solve them? Is that the approach? +JORDYN: More or less, yeah. Yes. It's like, can we interface with those top...I think for us, it's like a top five, maybe six. +JOSH: Five or six. +JORDYN: But, like, the first one on there is email, and that's not a problem. Like, we don't...that's fine. LinkedIn is also not a problem; one and two are email, and LinkedIn: good. We're cool with that. That's okay. +JOSH: Because every individual has their own thing. So, you know, you may be talking about long tail services, you know, but for the person who uses Telegram as their, like, daily driver, which isn't most people in the U.S., but there's a lot of people abroad, not having Telegram means it isn't useful. And I think that's one of the things hard about this, right? This is a hard business potentially, or it's really easy. We have no idea yet. And that's part of what I find exciting about this is because over the next, you know, week or so, we'll find out how hard a business this is actually, or at least where are the technically difficult parts? +LINDSEY: Great segue. What does the next week look like as we've got market niche, prototype, technical feasibility intersectioning, figuring those things out? What exciting things are on the horizon? What's next? +JOSH: So, we have about two weeks left, and at the end of two weeks, we're going to end up with a set of high-quality prototypes, which, you know, are easy for any of us to have on our phones, and to flash around to rando strangers we meet at the grocery store because there's no better way to make friends than product testing. And we'll have a good sense of how big and complicated, and complicated in what ways might it be to build this thing. +And then, it's time for Josh to make some decisions around, you know, the whole goal of this was to figure out, like, how big of an opportunity is this just to go and do that? What could growth look like? What could pricing look like? Where might the costs be? What would the cost be to build this? Is this, like, a side gig scale thing? Is it a small, you know, angel-funded startup thing? Is this, like, a VC-size thing? I really hope it's not a VC-size thing. +And then to think about, you know, what are the resources that would be required to build it, and where might those resources come from? So, at the end of this, two weeks out from now, I think we'll have all the information, you know, that we need. And then, I know a whole bunch of people inside of thoughtbot who are in a great place to provide their own thoughts and advice and experience and feedback on this. +And I'll take this to my personal board of directors, including my family, but also, you know, other experienced entrepreneurs and investors I know, and we'll talk through this. And we'll have to go make some decisions, which is a little scary and a little bit fun, but a nice way to kick off 2024. +JORDYN: And a lot easier to do after this program. +JOSH: We'll have some real information, right? [laughs] +JORDYN: Yes. +LINDSEY: That's the goal, right? +JOSH: Yeah. +LINDSEY: Of the incubator to get you in that spot where you can make educated decisions and get others up to speed really quickly with all that research. +JOSH: That's right. +LINDSEY: That's great. All right. So, you had a call to action earlier. What was that? Oh, if startup enthusiasts are listening, we want to chat with them and talk to them about the solution. +JOSH: If you're a founder, if you're a multi-time founder and either done it a couple of times in the past or you're still doing it, reach out. If you are a startup chief of staff and you can define that role for yourself, please reach out. We'd love to talk to you there as well. If you would like a copy of Josh's free wireframing template for mobile apps, please reach out, and I will be happy to provide you that as well. +LINDSEY: Amazing. Thank you once again, Josh and Jordyn, for joining and catching us up. It definitely was an exciting update. I can't wait to hear what happens in the final stretch. +JOSH: Me too. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Jordyn Bonds and Josh Herzig-Marx . + + + If you missed the first and second episodes with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can listen to Josh's first episode and his second to catch up.

+ +

In the third interview with Josh, Lindsey Christensen, head of Marketing at thoughtbot, and Jordyn Bonds, head of the Incubator Program at thoughtbot, discuss the progress of Knect in the thoughtbot Incubator Program. Most of the conversation involves identifying and focusing on the right target audience. Initially, they considered startup enthusiasts, but after exploring other segments like journalists, they returned to startup enthusiasts with a more refined focus. Josh also talks about developing a prototype and its usefulness in getting feedback and refining the product concept.

+ +

The technical feasibility of integrating various communication platforms into their solution is a significant focus. They examined different platforms like email, LinkedIn, WhatsApp, Telegram, and SMS to determine which integrations were essential for the minimum viable product. Looking forward, Josh outlines the next steps for the program, which include finalizing high-quality prototypes and making strategic decisions about the scale and funding of the project.

+ +

Transcript:

+ +

LINDSEY: Hi, everyone.

+ +

JORDYN: Hi.

+ +

LINDSEY: Thanks for tuning in and joining. We're going to be checking in on one of our incubator program participants today. If you haven't joined us before, thoughtbot runs a startup incubator, about an eight-week program for the early, early, early-stage company, idea, founder project to validate that business, find the market, and start thinking about how you build that thing.

+ +

So my name is Lindsey Christensen. I head up Marketing here at thoughtbot. And today, I am joined by Jordyn Bonds, who heads up the incubator program at thoughtbot. And our guest of honor checking in once again, Josh Herzig-Marks, Founder of Knect, the company going through the program. Thanks for joining.

+ +

JOSH: Super excited. I'm always excited.

+ +

LINDSEY: How's it going? How is your founder sentiment this week?

+ +

JOSH: This --

+ +

LINDSEY: Are you on a high? Are you on a low?

+ +

JOSH: I don't think I'm on a typically high-high. I'm a pretty even-keeled, chill founder. I think it's appropriately enthusiastic but not excessively so, and definitely not at a low trough.

+ +

LINDSEY: All right, even-keeled. We love to [crosstalk 01:19].

+ +

JOSH: Appropriately enthusiastic because we're doing really cool stuff. And this is a lot of fun.

+ +

LINDSEY: Well, that's great. So, I mean, [inaudible 01:25] that you're working on and especially the last time I checked in with you in the really early stages, trying to find that target niche audience or invalidate, like, the problem with them. How is that going? How's that search for the people with the problem going?

+ +

JOSH: Yeah. So just to, like, rewind the clock for the folks who maybe haven't seen every one of these, you know, there's a few things that I was trying to figure out to validate whether this problem that I saw was an opportunity for business. And, Jordyn, help me out if I forget some of these.

+ +

So, number one, is this a Josh problem, or is this problem more broad? Question number two is, could we find an audience of people who are reachable, who share the problem, and who'd be willing to actually pay for this thing? And those little asterisks after pay, right? People pay for things with money but also with time or with reputation. Generally, we're thinking about money here, ultimately. But do they pay for this thing even in time? Would they be able to do that?

+ +

And the reason we're looking for that kind of a more narrow audience is because you got to build for somebody in the very beginning. This isn't, like, we're limiting ourselves to a narrow audience forever, but we wanted a set of people who we could design this thing for, have prototypes, share it, and hopefully get some consistent feedback so we can build a thing which they would find useful and use that from there. That was two things.

+ +

And the third thing: is this actually technically feasible? You know, the first time I was a founder, incidental to building our business, we built the world's fastest online transaction processing database that was processing, like, billions and billions of retail records in, like, the time it takes you to, like, click and drag and change the query that we're doing, which is really cool to say out loud, and it demoed really, really well. But that isn't actually a business.

+ +

And what I wanted is part of validating if this idea, if this problem was an opportunity or something that wasn't a science experiment. And I'd love to talk a little bit more about what we've been doing over the past week, maybe a little later on in this. Because I think it's been a big week for the science experiment or not validation stage of this thing.

+ +

So, two things we've also done over the past week and a half, two weeks since the last time we chatted, we have a prototype, which looks pretty good, which we can now use to show to people who we think are our core starting audience, our core starting market, and we actually have a core starting market. Both of these things are pretty exciting. I mean, I'm always excited. But we're doing it, like, we're doing the thing that we're supposed to be doing, and I like that.

+ +

LINDSEY: That's really exciting. So, core starting market is happening. Do you want to talk about maybe how you got there?

+ +

JOSH: One of the reasons why I was excited about doing this program is Jordyn, and I share the understanding of its importance. But when you're, like, actually the founder, it's really hard to see this, right? Jordyn is like the...I don't know quite how to describe it, but Jordyn is the person who, like, made sure we stayed focused on this part of the effort. And, like, it's a really key part of the thoughtbot incubator. And it's one of the reasons why I'm really appreciative of having gone through the program.

+ +

JORDYN: So, Josh walked into the program with a problem that he had, which is frequently how products get made and companies get founded. Like, that's fine. It's a great starting place. And as he listed, his question was, is this a Josh problem, or is this a problem for more than just Josh? Because Josh isn't a market segment. Josh is an individual human [laughs]. And a lot of us have product ideas that we would love to have exist so that we can use them, but that doesn't make them good market opportunities. I may or may not be speaking from experience in that regard, ahem. Anyway, so part of the programming here was to figure this out.

+ +

And it's great to start with, like, okay, well, if Josh is our primary user, who is Josh? Is there a market of Joshs, right? So, we actually started off talking to those folks. And, you know, we're human beings, and we tend to hang out with people like ourselves. And so, Josh knew a lot of people like Josh.

+ +

One of those people that he knew was me. I am like Josh in regard to this pain point. I also had it. And then I was connected to a bunch of people who had this pain point. So, we broadly spoke to a lot of those folks at first. I don't know that we really had a persona name for this. I don't know, how would you frame this?

+ +

JOSH: As you know, I only have poor pejorative names for people like us.

+ +

JORDYN: [laughs] Pejorative?

+ +

JOSH: There's, you know, a class of people who are at tech companies and startups, and sometimes they start their own companies, and sometimes they work at companies. And sometimes they do coaching. And sometimes they do a little bit of an investment. And sometimes they're on advisory boards. And, you know, when you kind of smoothly move from one thing to the next, sort of often doing several of these things all at the same time.

+ +

And there's not a really good name for them, but they're kind of people, like I might go so far to say the three of us, and maybe a lot of people who work at thoughtbot and a lot of people we've all worked with in the past and, hopefully, a lot of the people who are listening to this conversation because they, too, could slip into the founding a company stage of this business.

+ +

JORDYN: So, we've kind of loosely called those people, most recently, startup enthusiasts is our nickname, and there are a lot of folks under that umbrella. But as we talked to those people at this kind of high level, it was very broad. That maybe sounds fairly specific to some of you out there listening, but it's not specific, nearly specific enough to address with a product.

+ +

So, we were talking. We were listening, getting people to talk to us, "Hey, tell us about how you keep in touch with folks. How does that go? What do you do? Have you ever built your own spreadsheet to keep track of people you know? Tell us about that." Broad questions. And we were learning things and hearing about trends. It wasn't coming into focus. We weren't hearing enough repeatable things. And we certainly weren't hearing about red, hot pain points. It was like a, "Yeah, this is kind of a problem sometimes, but not all the time. My system works more or less [inaudible 07:11].

+ +

Then we kind of found this range of personas. Some folks were just like, "I'm awesome at this. It's not a problem. I don't know what to tell you." Okay, well, clearly, that person doesn't need a product because they're feeling good. Great. At the other end of the spectrum, you have people who are just like, "I don't even know what you're talking about [laughs]. Like, this isn't [laughs]..."

+ +

There were people who were like, "I know what you're talking about, but I'm good at it." There were people who were like, "I don't know what you're talking about. I don't care to ever do this." And then, there was this broad set of people in the middle who were like, "Yeah, I have a problem with this." But we were hearing a lot of different things.

+ +

In the course of that, Rami, one of the folks on the team, ended up talking to a journalist. And that conversation was very interesting because it did seem like way more of a red, hot pain point with, like, something on the line. And we were like, oh, maybe we've been barking up the entire wrong tree and, like, startup enthusiasts aren't our people; journalists are our people. So, then we did a whole sprint with journalists and realized that journalists is a very broad umbrella [laughs]. There's a lot of different kinds of journalists in a lot of different kinds of contexts. And they have widely varying pain points, habits, needs, wants.

+ +

We were like, okay, we're hearing some really interesting things in here, but they don't seem like early adopters because they are not the kind of people that just try an app who are just like, "Sure, new app, cool. I'll try that." Startup enthusiasts are people who just, like, try stuff. They're, like, on Product Hunt. They're friends with a bunch of founders, and those founders are, like, "Try this." And then they're like, "Sure, okay. Sure, I'll try it. I'll login." Login to anything once, right? Is kind of the attitude of this group of people, journalists not so much.

+ +

And so, it felt like it was going to be a really hard thing to address those folks. But we learned a ton. And we really ended up mapping the emotional train in a lot of detail. And as a group, like, we came to a lot of alignment. There was a lot of, like, really good understanding, deeper understanding having gone on that journey. But where we ended up back was like, okay, startup enthusiasts really actually seem like [laughs] a place to start. And it feels like there's enough of them that they could create some kind of early adopter market.

+ +

But now, with the information that we had, the new information we had, we were like, let us sub-segment this group of people. It's not everybody in that umbrella. Doing that whole journey enabled us to kind of come back to the question with renewed focus, but, like, conviction about how valuable it was going to be to do that, right? And sometimes that's what it takes. You kind of have to do the wrong thing for a second to appreciate doing the right thing, and that's totally fine. The fact that we were able to do that in, what, five weeks is, like, fine.

+ +

JOSH: And I think the way that we found the sub-segment that made sense was actually pretty simple, right? Once we understood what are the dimensions that are actually important, we did a quick brainstorming session. This wasn't actually a very long process at the end of it, a quick brainstorming session. What are the different kinds of people who fall into this segment?

+ +

And we just scored them on all the easy things you'd expect to score people on, namely: are they easy to find and easy for us to reach? Do they advertise this quality of theirs someplace publicly, like, perhaps on LinkedIn? And are they easy to find? Like, do we have enough of them inside of our network so we could, like, search for these kinds of folks? And as it turns out, we've already spoken to a lot of these kinds of folks as well. And primarily, we're talking to repeat founders and/or chiefs of staff at startups.

+ +

JORDYN: If you are one of those people, please reach out to us. We'd like to talk to you.

+ +

JOSH: We would love it.

+ +

LINDSEY: Call to action. So, Josh, you mentioned one of the benefits of the program has been Jordyn's ability to kind of laser-focus on finding the target market. Jordyn, how do you do that? How do you keep the team coming back to that? Especially as sometimes it maybe doesn't take that long—sometimes it might feel like you're kind of circling around and around and still aren't finding anyone—and keeping folks motivated to do that or understanding, you know, when are we going to say, "This is it, you know, we're not finding someone"?

+ +

JORDYN: I'll talk about how it worked in this case. And every team is different and is motivated by different things. And this process is a little different every time, so it's hard to make generalizations. But in this case, what was interesting is that after we did our journalist sprint and we were like, we do want to refocus on startup enthusiasts, but we need to understand a little bit better what we're doing, we actually prototyped a little bit given what we knew, which seems like a bad idea [laughs] on the face of it. It seems premature.

+ +

The purpose of doing that, then, was to really take a different path to drawing out of each of us what was in our lines. That's, like, so much of the work of a team at this stage is, like, making sure that we're externalizing the things that we're thinking and the assumptions that we have. And it's strange. You would think you would just be like, "Hey, tell me what's in your mind?" But minds don't work that way. You can't just be like, "Hey, mind, what's up?" And then articulate it perfectly in a way that everybody in this group is going to know what you mean.

+ +

So, prototyping actually drew a bunch of that stuff out. It really...I think that was the moment...I don't know, Josh, how you feel about it. We had been kind of in the doldrums because we did get to the end of that journalists' sprint. And we were like, what are we doing? What have we learned? And prototyping at that moment enabled us to...it was a different way of understanding what we had learned and what we were all now thinking. And it really drew a bunch of dynamics out that it was super helpful.

+ +

JOSH: It brought some real sharpness to what we thought we'd be able to...the kind of value we thought we could deliver in the early versions of this thing, right? Fast forward two years, who knows? But it brought some sharpness to the kinds of problems that we thought we'd be able to fix and the kinds of problems we thought we couldn't solve. And that also clarified for us, certainly for me, why, oh, here's why this isn't really landing with the journalists, right? And here's why this isn't really landing with some other kinds of folks we were talking to. And --

+ +

JORDYN: Biz dev folks. We talked to a bunch of biz dev folks. It wasn't going to land with them, but yeah --

+ +

JOSH: They weren't at all excited about it, and then we can kind of understand why. One of the ways that I think about a prototype and I talk about this a lot, and I love doing this. Somebody called this a Pinocchio prototype, the wooden child who wants to be a real boy. Once we had a prototype, we could actually put it onto our actual phones.

+ +

And I'm not sure how many other people did this on the team besides me but, like, I would carry my phone around with a prototype on it. And every time I thought I might use it, I would pull the damn thing out of my pocket and, like, tap away on the phone. It gave me, again, a very clear sense of the kinds of things I thought we were moving towards solving and the kinds of things that we weren't really solving.

+ +

LINDSEY: Yeah, Josh, you mentioned there were some exciting developments in the past week. Is that around the prototype?

+ +

JOSH: This is one. Having the prototype on there was good. It's also really nice to have this be part of a larger team. I was having a hard time. I had been playing with, like, our design team's paper prototype. I was having a hard time communicating what I was trying to do inside of my head. So, I built my own parallel prototype in Google Slides, which was exactly as awesome looking and as functional as everybody listening is imagining it must have been. If you would like your own copy of my Google Slides app development template, please reach out. I will share it [laughs].

+ +

But it let me think a little bit, again, the same thing, like, here's how these things fit together. And then it started moving really, really fast. Once we were all putting things down in a way that we could play with, and touch, and talk about in a concrete way, it felt like that part of things started to move really fast. And the quality of our conversations improved with people we were talking to as well. I would say that's half of the things that are really exciting.

+ +

LINDSEY: Just to continue on the prototype for a second, Jordyn mentioned a major outcome of starting to use the prototype; well, I guess [inaudible 14:37] that you all as a team got better aligned around what you were envisioning for the solution. And then, it also helped you, again, kind of identify the true target market. Are there other things you're already learning from using the prototype and getting it in front of people?

+ +

JOSH: Yeah, I think there are. By the way, this shouldn't be surprising. This is, like, the classic diverge-converge model that I know thoughtbot uses all the time with not just startup clients when you're building something new. One of the things which, you know, rewind the clock six and a half weeks ago to when we started this thing. I didn't realize how much intelligence would be required behind the scenes to make this thing actually sensible to the final users.

+ +

And the more we show it to people, the more we realize that, like, intelligence to make things look simple is going to equal people actually using the damn thing. I think we started to see that ourselves in playing with it. But it's really important to have that be validated by actual potential users who aren't, like, in this shit themselves.

+ +

JORDYN: I mean, immediately, you know, we were able to start showing the prototype to the folks that we were having interviews with, and there's just nothing better than that because they're not going to pull their punches with you. And we got a lot of great immediate sort of spicy feedback [laughs] from people, especially if you're showing them to people who are, like, startup people [laughs], they're just not going to be nice. And so, there was a lot of [crosstalk 15:59].

+ +

JOSH: They're like, "Have you considered making this suck less?"

+ +

JORDYN: Yeah, exactly. "I wouldn't use this at all [laughs]." You're just like, "Okay, thanks." Tell me how you really feel [laughs]. But it's great. I mean, like, there's nothing better than that. Like, I would way rather that than a bunch of people trying to be polite.

+ +

JOSH: And it also prompts feedback that we wouldn't necessarily have thought of, which is the idea of this. We [inaudible 16:20] thought of this on our own. Like the idea that sometimes you might want to not take an action when you don't really care about a person. But sometimes you really, like, dislike a person so much who you've been talking to you want to never see them again, right? Never show me this person again. It's a thing that we never would have come to, I think, if we hadn't, like, actually been showing the prototype to end users.

+ +

LINDSEY: Okay, what is the second half of the exciting thing that happened in the past week?

+ +

JOSH: This is very much a thoughtbot thing. thoughtbot is full of really talented engineers. And over the past couple of days, we've been able to bring a lot of those folks to bear on the question of like, is this thing technically feasible or not? Which was one of my big concerns. And it turns out, that was probably too large a question for the team that we started with.

+ +

And to be able to, like, do this, like, little discovery spike with, you know, going beyond the three-and-a-half thoughtboter team that we had to some of your most talented, most experienced engineering leads, not forever, but just for, like, a short moment is kind of, for me, at least, like, a real taste of, like, the thoughtbot value is, you know, Jordyn gets to put out a call for assistance, you know, across the company, and people raise their hands and put real-time in.

+ +

And, you know, we're able to do something in a couple of days that we probably couldn't have done because we have enough people. And, you know, all those, like, network effects of people coming together that could have taken us, you know, weeks or longer just kind of toiling on our own.

+ +

LINDSEY: For those technical challenges, maybe you don't want to get into specifics, but in broad strokes, can you talk about what some of those considerations are? And maybe at this point, maybe it makes sense to also talk a little bit about, like, how the solution, how you're thinking about the evolution of what the solution is and provides.

+ +

JOSH: I have an Android phone. I live in the world as a green bubble in a world of blue bubbles. My partner and I are in an interfaith relationship. She has an iPhone. I have an Android phone. And forever, people are accidentally trying to hit up my, like, iMessage account tied to my email address, and the things don't come through. And, all of a sudden, this company someplace in the U.S. figured out some way to, like, reverse engineer the Apple messages iMessages protocol, so I can put iMessages onto my Android phone. They built this thing. It's been, like, all over the tech news recently.

+ +

This is the problem, if you're trying to bring together all of somebody's social network, is that there is no, like, handy-dandy API for iMessages. There is no handy-dandy API for regular SMS or RCS or any of those other variations of that. There is no handy-dandy API for WhatsApp, for Telegram, sort of ish, kind of maybe for Slack, not really for Discord. It remains to be seen how mature it is for LinkedIn. By the way, email works great, right? If we just build our entire lives off of email, we'd have none of these problems, but we can't.

+ +

And we had some hypotheses about ways that we could make connecting these other accounts easier. And we just took, like, an awful lot of hands, right? More than two hands. It took more than two hands to figure out if these things were possibilities if those things turn out to be true. And the answer is if they are true, which we're still working to figure out, though it's looking better and better, this isn't a science experiment, right? And if it's not true, then step one is an awful lot of engineer hours to go do what those Beeper Mini folks did and reverse engineer a whole bunch of protocols and systems that were never intended to be open in the first place.

+ +

JORDYN: I would like to say --

+ +

JOSH: Which is why we should all donate to EFF and promote an open internet so that startups like mine don't need to exist.

+ +

JORDYN: To loop back to your earlier question, Lindsey, about how to keep the team focused on who something is for, this conversation seems like it's not about that. But, to me, this conversation is also about that because we have a long list of messaging platforms that we have heard from folks, like from interviewing them would be useful to have brought into a single place.

+ +

This was one of the key pain points that Josh has that we heard from other people, which is, like, you connect with people across platforms, right? You might be connected to some on LinkedIn, but you're also emailing with them. Your email history with them is not a complete history of your life with them. None of your online stuff is going to be a complete history because sometimes you actually interact with people [laughs] in reality, which is still, at this moment, not being recorded all the time, but probably not for long.

+ +

JOSH: As little as possible.

+ +

JORDYN: [laughs] But still, even within the online world, you're communicating with people across platforms. Maybe you text with someone, maybe you message on LinkedIn, whatever. And having complete context for your relationship with them in a way that makes it really easy to kind of, like, boot up that context in order to reach out to them for some reason, like, maybe you haven't talked in six months, and you just want to remember, where did I leave this relationship? What's going on with this person, right? You're like, where was I talking to them? Oh, I was talking to them in these four places that don't have very good protocols for being brought into the same interface, right? So, like, the stuff is, like, all connected.

+ +

But to get back to the who question, we have this list of places we'd heard from people, like, in the early interviews and places that Josh was trying to do this connect with people, et cetera. So, it's, like, Slack DMs, and it's email, and it's LinkedIn, whatever. But we also heard Telegram, and we also heard other things. If we don't sufficiently focus on a narrow enough group of people, we risk making the MVP way too big because it needs to connect with every one of these things. And we can't go to market with something that doesn't connect with 12 platforms or something, right?

+ +

But because we're sufficiently focused, we could actually do the thing where we're like, okay, well, out of this list of platforms, what are, like, the top five? Where is the line? Where's the minimum viability here with what we can connect with that will actually bring value? And I also am an Android user living in an iPhone world. And Josh and I at least have enough awareness to be like, you know what? Maybe Android isn't necessary, even though we would love [laughs] for it to be there. Nine times out of 10, the people that look like us are using iPhones, right? So great, cool. Let's just do the thing.

+ +

JOSH: Obligatory iPhone test device.

+ +

JORDYN: Right. I have one, too, but I don't know where it is. So, like, the question of who really matters. Who, like, really helps you focus? If your answer to "Who?" is anybody with a smartphone, well, like, it's going to be really tough to build an actual MVP that's buildable. So, this question that Josh brought in to us, which is, like, "What's technically feasible here?" really intersects very directly with this question of who are we building for? Because you really want to be able to start somewhere.

+ +

And, you know, if you have a sufficiently red, hot need and it's not, like, to time travel or something that is, like, probably impossible given the laws of our universe, you can find a way, right? And so, the question was, like, why don't we find that so that we can focus on whether it's worth finding a way? And then that intersection of who it's for, what their pain points are, and what's possible with what amount of effort. It all fits together. No single one of those pieces is sufficient for figuring out a path forward.

+ +

LINDSEY: And are you taking the, you know, okay, we've gotten really good sight on these startup enthusiasts, and these are their top four communication methods; let's try to solve them? Is that the approach?

+ +

JORDYN: More or less, yeah. Yes. It's like, can we interface with those top...I think for us, it's like a top five, maybe six.

+ +

JOSH: Five or six.

+ +

JORDYN: But, like, the first one on there is email, and that's not a problem. Like, we don't...that's fine. LinkedIn is also not a problem; one and two are email, and LinkedIn: good. We're cool with that. That's okay.

+ +

JOSH: Because every individual has their own thing. So, you know, you may be talking about long tail services, you know, but for the person who uses Telegram as their, like, daily driver, which isn't most people in the U.S., but there's a lot of people abroad, not having Telegram means it isn't useful. And I think that's one of the things hard about this, right? This is a hard business potentially, or it's really easy. We have no idea yet. And that's part of what I find exciting about this is because over the next, you know, week or so, we'll find out how hard a business this is actually, or at least where are the technically difficult parts?

+ +

LINDSEY: Great segue. What does the next week look like as we've got market niche, prototype, technical feasibility intersectioning, figuring those things out? What exciting things are on the horizon? What's next?

+ +

JOSH: So, we have about two weeks left, and at the end of two weeks, we're going to end up with a set of high-quality prototypes, which, you know, are easy for any of us to have on our phones, and to flash around to rando strangers we meet at the grocery store because there's no better way to make friends than product testing. And we'll have a good sense of how big and complicated, and complicated in what ways might it be to build this thing.

+ +

And then, it's time for Josh to make some decisions around, you know, the whole goal of this was to figure out, like, how big of an opportunity is this just to go and do that? What could growth look like? What could pricing look like? Where might the costs be? What would the cost be to build this? Is this, like, a side gig scale thing? Is it a small, you know, angel-funded startup thing? Is this, like, a VC-size thing? I really hope it's not a VC-size thing.

+ +

And then to think about, you know, what are the resources that would be required to build it, and where might those resources come from? So, at the end of this, two weeks out from now, I think we'll have all the information, you know, that we need. And then, I know a whole bunch of people inside of thoughtbot who are in a great place to provide their own thoughts and advice and experience and feedback on this.

+ +

And I'll take this to my personal board of directors, including my family, but also, you know, other experienced entrepreneurs and investors I know, and we'll talk through this. And we'll have to go make some decisions, which is a little scary and a little bit fun, but a nice way to kick off 2024.

+ +

JORDYN: And a lot easier to do after this program.

+ +

JOSH: We'll have some real information, right? [laughs]

+ +

JORDYN: Yes.

+ +

LINDSEY: That's the goal, right?

+ +

JOSH: Yeah.

+ +

LINDSEY: Of the incubator to get you in that spot where you can make educated decisions and get others up to speed really quickly with all that research.

+ +

JOSH: That's right.

+ +

LINDSEY: That's great. All right. So, you had a call to action earlier. What was that? Oh, if startup enthusiasts are listening, we want to chat with them and talk to them about the solution.

+ +

JOSH: If you're a founder, if you're a multi-time founder and either done it a couple of times in the past or you're still doing it, reach out. If you are a startup chief of staff and you can define that role for yourself, please reach out. We'd love to talk to you there as well. If you would like a copy of Josh's free wireframing template for mobile apps, please reach out, and I will be happy to provide you that as well.

+ +

LINDSEY: Amazing. Thank you once again, Josh and Jordyn, for joining and catching us up. It definitely was an exciting update. I can't wait to hear what happens in the final stretch.

+ +

JOSH: Me too.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Jordyn Bonds and Josh Herzig-Marx .

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + If you missed the first and second episodes with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can listen to Josh's first episode and his second to catch up.

+ +

In the third interview with Josh, Lindsey Christensen, head of Marketing at thoughtbot, and Jordyn Bonds, head of the Incubator Program at thoughtbot, discuss the progress of Knect in the thoughtbot Incubator Program. Most of the conversation involves identifying and focusing on the right target audience. Initially, they considered startup enthusiasts, but after exploring other segments like journalists, they returned to startup enthusiasts with a more refined focus. Josh also talks about developing a prototype and its usefulness in getting feedback and refining the product concept.

+ +

The technical feasibility of integrating various communication platforms into their solution is a significant focus. They examined different platforms like email, LinkedIn, WhatsApp, Telegram, and SMS to determine which integrations were essential for the minimum viable product. Looking forward, Josh outlines the next steps for the program, which include finalizing high-quality prototypes and making strategic decisions about the scale and funding of the project.

+ +

Transcript:

+ +

LINDSEY: Hi, everyone.

+ +

JORDYN: Hi.

+ +

LINDSEY: Thanks for tuning in and joining. We're going to be checking in on one of our incubator program participants today. If you haven't joined us before, thoughtbot runs a startup incubator, about an eight-week program for the early, early, early-stage company, idea, founder project to validate that business, find the market, and start thinking about how you build that thing.

+ +

So my name is Lindsey Christensen. I head up Marketing here at thoughtbot. And today, I am joined by Jordyn Bonds, who heads up the incubator program at thoughtbot. And our guest of honor checking in once again, Josh Herzig-Marks, Founder of Knect, the company going through the program. Thanks for joining.

+ +

JOSH: Super excited. I'm always excited.

+ +

LINDSEY: How's it going? How is your founder sentiment this week?

+ +

JOSH: This --

+ +

LINDSEY: Are you on a high? Are you on a low?

+ +

JOSH: I don't think I'm on a typically high-high. I'm a pretty even-keeled, chill founder. I think it's appropriately enthusiastic but not excessively so, and definitely not at a low trough.

+ +

LINDSEY: All right, even-keeled. We love to [crosstalk 01:19].

+ +

JOSH: Appropriately enthusiastic because we're doing really cool stuff. And this is a lot of fun.

+ +

LINDSEY: Well, that's great. So, I mean, [inaudible 01:25] that you're working on and especially the last time I checked in with you in the really early stages, trying to find that target niche audience or invalidate, like, the problem with them. How is that going? How's that search for the people with the problem going?

+ +

JOSH: Yeah. So just to, like, rewind the clock for the folks who maybe haven't seen every one of these, you know, there's a few things that I was trying to figure out to validate whether this problem that I saw was an opportunity for business. And, Jordyn, help me out if I forget some of these.

+ +

So, number one, is this a Josh problem, or is this problem more broad? Question number two is, could we find an audience of people who are reachable, who share the problem, and who'd be willing to actually pay for this thing? And those little asterisks after pay, right? People pay for things with money but also with time or with reputation. Generally, we're thinking about money here, ultimately. But do they pay for this thing even in time? Would they be able to do that?

+ +

And the reason we're looking for that kind of a more narrow audience is because you got to build for somebody in the very beginning. This isn't, like, we're limiting ourselves to a narrow audience forever, but we wanted a set of people who we could design this thing for, have prototypes, share it, and hopefully get some consistent feedback so we can build a thing which they would find useful and use that from there. That was two things.

+ +

And the third thing: is this actually technically feasible? You know, the first time I was a founder, incidental to building our business, we built the world's fastest online transaction processing database that was processing, like, billions and billions of retail records in, like, the time it takes you to, like, click and drag and change the query that we're doing, which is really cool to say out loud, and it demoed really, really well. But that isn't actually a business.

+ +

And what I wanted is part of validating if this idea, if this problem was an opportunity or something that wasn't a science experiment. And I'd love to talk a little bit more about what we've been doing over the past week, maybe a little later on in this. Because I think it's been a big week for the science experiment or not validation stage of this thing.

+ +

So, two things we've also done over the past week and a half, two weeks since the last time we chatted, we have a prototype, which looks pretty good, which we can now use to show to people who we think are our core starting audience, our core starting market, and we actually have a core starting market. Both of these things are pretty exciting. I mean, I'm always excited. But we're doing it, like, we're doing the thing that we're supposed to be doing, and I like that.

+ +

LINDSEY: That's really exciting. So, core starting market is happening. Do you want to talk about maybe how you got there?

+ +

JOSH: One of the reasons why I was excited about doing this program is Jordyn, and I share the understanding of its importance. But when you're, like, actually the founder, it's really hard to see this, right? Jordyn is like the...I don't know quite how to describe it, but Jordyn is the person who, like, made sure we stayed focused on this part of the effort. And, like, it's a really key part of the thoughtbot incubator. And it's one of the reasons why I'm really appreciative of having gone through the program.

+ +

JORDYN: So, Josh walked into the program with a problem that he had, which is frequently how products get made and companies get founded. Like, that's fine. It's a great starting place. And as he listed, his question was, is this a Josh problem, or is this a problem for more than just Josh? Because Josh isn't a market segment. Josh is an individual human [laughs]. And a lot of us have product ideas that we would love to have exist so that we can use them, but that doesn't make them good market opportunities. I may or may not be speaking from experience in that regard, ahem. Anyway, so part of the programming here was to figure this out.

+ +

And it's great to start with, like, okay, well, if Josh is our primary user, who is Josh? Is there a market of Joshs, right? So, we actually started off talking to those folks. And, you know, we're human beings, and we tend to hang out with people like ourselves. And so, Josh knew a lot of people like Josh.

+ +

One of those people that he knew was me. I am like Josh in regard to this pain point. I also had it. And then I was connected to a bunch of people who had this pain point. So, we broadly spoke to a lot of those folks at first. I don't know that we really had a persona name for this. I don't know, how would you frame this?

+ +

JOSH: As you know, I only have poor pejorative names for people like us.

+ +

JORDYN: [laughs] Pejorative?

+ +

JOSH: There's, you know, a class of people who are at tech companies and startups, and sometimes they start their own companies, and sometimes they work at companies. And sometimes they do coaching. And sometimes they do a little bit of an investment. And sometimes they're on advisory boards. And, you know, when you kind of smoothly move from one thing to the next, sort of often doing several of these things all at the same time.

+ +

And there's not a really good name for them, but they're kind of people, like I might go so far to say the three of us, and maybe a lot of people who work at thoughtbot and a lot of people we've all worked with in the past and, hopefully, a lot of the people who are listening to this conversation because they, too, could slip into the founding a company stage of this business.

+ +

JORDYN: So, we've kind of loosely called those people, most recently, startup enthusiasts is our nickname, and there are a lot of folks under that umbrella. But as we talked to those people at this kind of high level, it was very broad. That maybe sounds fairly specific to some of you out there listening, but it's not specific, nearly specific enough to address with a product.

+ +

So, we were talking. We were listening, getting people to talk to us, "Hey, tell us about how you keep in touch with folks. How does that go? What do you do? Have you ever built your own spreadsheet to keep track of people you know? Tell us about that." Broad questions. And we were learning things and hearing about trends. It wasn't coming into focus. We weren't hearing enough repeatable things. And we certainly weren't hearing about red, hot pain points. It was like a, "Yeah, this is kind of a problem sometimes, but not all the time. My system works more or less [inaudible 07:11].

+ +

Then we kind of found this range of personas. Some folks were just like, "I'm awesome at this. It's not a problem. I don't know what to tell you." Okay, well, clearly, that person doesn't need a product because they're feeling good. Great. At the other end of the spectrum, you have people who are just like, "I don't even know what you're talking about [laughs]. Like, this isn't [laughs]..."

+ +

There were people who were like, "I know what you're talking about, but I'm good at it." There were people who were like, "I don't know what you're talking about. I don't care to ever do this." And then, there was this broad set of people in the middle who were like, "Yeah, I have a problem with this." But we were hearing a lot of different things.

+ +

In the course of that, Rami, one of the folks on the team, ended up talking to a journalist. And that conversation was very interesting because it did seem like way more of a red, hot pain point with, like, something on the line. And we were like, oh, maybe we've been barking up the entire wrong tree and, like, startup enthusiasts aren't our people; journalists are our people. So, then we did a whole sprint with journalists and realized that journalists is a very broad umbrella [laughs]. There's a lot of different kinds of journalists in a lot of different kinds of contexts. And they have widely varying pain points, habits, needs, wants.

+ +

We were like, okay, we're hearing some really interesting things in here, but they don't seem like early adopters because they are not the kind of people that just try an app who are just like, "Sure, new app, cool. I'll try that." Startup enthusiasts are people who just, like, try stuff. They're, like, on Product Hunt. They're friends with a bunch of founders, and those founders are, like, "Try this." And then they're like, "Sure, okay. Sure, I'll try it. I'll login." Login to anything once, right? Is kind of the attitude of this group of people, journalists not so much.

+ +

And so, it felt like it was going to be a really hard thing to address those folks. But we learned a ton. And we really ended up mapping the emotional train in a lot of detail. And as a group, like, we came to a lot of alignment. There was a lot of, like, really good understanding, deeper understanding having gone on that journey. But where we ended up back was like, okay, startup enthusiasts really actually seem like [laughs] a place to start. And it feels like there's enough of them that they could create some kind of early adopter market.

+ +

But now, with the information that we had, the new information we had, we were like, let us sub-segment this group of people. It's not everybody in that umbrella. Doing that whole journey enabled us to kind of come back to the question with renewed focus, but, like, conviction about how valuable it was going to be to do that, right? And sometimes that's what it takes. You kind of have to do the wrong thing for a second to appreciate doing the right thing, and that's totally fine. The fact that we were able to do that in, what, five weeks is, like, fine.

+ +

JOSH: And I think the way that we found the sub-segment that made sense was actually pretty simple, right? Once we understood what are the dimensions that are actually important, we did a quick brainstorming session. This wasn't actually a very long process at the end of it, a quick brainstorming session. What are the different kinds of people who fall into this segment?

+ +

And we just scored them on all the easy things you'd expect to score people on, namely: are they easy to find and easy for us to reach? Do they advertise this quality of theirs someplace publicly, like, perhaps on LinkedIn? And are they easy to find? Like, do we have enough of them inside of our network so we could, like, search for these kinds of folks? And as it turns out, we've already spoken to a lot of these kinds of folks as well. And primarily, we're talking to repeat founders and/or chiefs of staff at startups.

+ +

JORDYN: If you are one of those people, please reach out to us. We'd like to talk to you.

+ +

JOSH: We would love it.

+ +

LINDSEY: Call to action. So, Josh, you mentioned one of the benefits of the program has been Jordyn's ability to kind of laser-focus on finding the target market. Jordyn, how do you do that? How do you keep the team coming back to that? Especially as sometimes it maybe doesn't take that long—sometimes it might feel like you're kind of circling around and around and still aren't finding anyone—and keeping folks motivated to do that or understanding, you know, when are we going to say, "This is it, you know, we're not finding someone"?

+ +

JORDYN: I'll talk about how it worked in this case. And every team is different and is motivated by different things. And this process is a little different every time, so it's hard to make generalizations. But in this case, what was interesting is that after we did our journalist sprint and we were like, we do want to refocus on startup enthusiasts, but we need to understand a little bit better what we're doing, we actually prototyped a little bit given what we knew, which seems like a bad idea [laughs] on the face of it. It seems premature.

+ +

The purpose of doing that, then, was to really take a different path to drawing out of each of us what was in our lines. That's, like, so much of the work of a team at this stage is, like, making sure that we're externalizing the things that we're thinking and the assumptions that we have. And it's strange. You would think you would just be like, "Hey, tell me what's in your mind?" But minds don't work that way. You can't just be like, "Hey, mind, what's up?" And then articulate it perfectly in a way that everybody in this group is going to know what you mean.

+ +

So, prototyping actually drew a bunch of that stuff out. It really...I think that was the moment...I don't know, Josh, how you feel about it. We had been kind of in the doldrums because we did get to the end of that journalists' sprint. And we were like, what are we doing? What have we learned? And prototyping at that moment enabled us to...it was a different way of understanding what we had learned and what we were all now thinking. And it really drew a bunch of dynamics out that it was super helpful.

+ +

JOSH: It brought some real sharpness to what we thought we'd be able to...the kind of value we thought we could deliver in the early versions of this thing, right? Fast forward two years, who knows? But it brought some sharpness to the kinds of problems that we thought we'd be able to fix and the kinds of problems we thought we couldn't solve. And that also clarified for us, certainly for me, why, oh, here's why this isn't really landing with the journalists, right? And here's why this isn't really landing with some other kinds of folks we were talking to. And --

+ +

JORDYN: Biz dev folks. We talked to a bunch of biz dev folks. It wasn't going to land with them, but yeah --

+ +

JOSH: They weren't at all excited about it, and then we can kind of understand why. One of the ways that I think about a prototype and I talk about this a lot, and I love doing this. Somebody called this a Pinocchio prototype, the wooden child who wants to be a real boy. Once we had a prototype, we could actually put it onto our actual phones.

+ +

And I'm not sure how many other people did this on the team besides me but, like, I would carry my phone around with a prototype on it. And every time I thought I might use it, I would pull the damn thing out of my pocket and, like, tap away on the phone. It gave me, again, a very clear sense of the kinds of things I thought we were moving towards solving and the kinds of things that we weren't really solving.

+ +

LINDSEY: Yeah, Josh, you mentioned there were some exciting developments in the past week. Is that around the prototype?

+ +

JOSH: This is one. Having the prototype on there was good. It's also really nice to have this be part of a larger team. I was having a hard time. I had been playing with, like, our design team's paper prototype. I was having a hard time communicating what I was trying to do inside of my head. So, I built my own parallel prototype in Google Slides, which was exactly as awesome looking and as functional as everybody listening is imagining it must have been. If you would like your own copy of my Google Slides app development template, please reach out. I will share it [laughs].

+ +

But it let me think a little bit, again, the same thing, like, here's how these things fit together. And then it started moving really, really fast. Once we were all putting things down in a way that we could play with, and touch, and talk about in a concrete way, it felt like that part of things started to move really fast. And the quality of our conversations improved with people we were talking to as well. I would say that's half of the things that are really exciting.

+ +

LINDSEY: Just to continue on the prototype for a second, Jordyn mentioned a major outcome of starting to use the prototype; well, I guess [inaudible 14:37] that you all as a team got better aligned around what you were envisioning for the solution. And then, it also helped you, again, kind of identify the true target market. Are there other things you're already learning from using the prototype and getting it in front of people?

+ +

JOSH: Yeah, I think there are. By the way, this shouldn't be surprising. This is, like, the classic diverge-converge model that I know thoughtbot uses all the time with not just startup clients when you're building something new. One of the things which, you know, rewind the clock six and a half weeks ago to when we started this thing. I didn't realize how much intelligence would be required behind the scenes to make this thing actually sensible to the final users.

+ +

And the more we show it to people, the more we realize that, like, intelligence to make things look simple is going to equal people actually using the damn thing. I think we started to see that ourselves in playing with it. But it's really important to have that be validated by actual potential users who aren't, like, in this shit themselves.

+ +

JORDYN: I mean, immediately, you know, we were able to start showing the prototype to the folks that we were having interviews with, and there's just nothing better than that because they're not going to pull their punches with you. And we got a lot of great immediate sort of spicy feedback [laughs] from people, especially if you're showing them to people who are, like, startup people [laughs], they're just not going to be nice. And so, there was a lot of [crosstalk 15:59].

+ +

JOSH: They're like, "Have you considered making this suck less?"

+ +

JORDYN: Yeah, exactly. "I wouldn't use this at all [laughs]." You're just like, "Okay, thanks." Tell me how you really feel [laughs]. But it's great. I mean, like, there's nothing better than that. Like, I would way rather that than a bunch of people trying to be polite.

+ +

JOSH: And it also prompts feedback that we wouldn't necessarily have thought of, which is the idea of this. We [inaudible 16:20] thought of this on our own. Like the idea that sometimes you might want to not take an action when you don't really care about a person. But sometimes you really, like, dislike a person so much who you've been talking to you want to never see them again, right? Never show me this person again. It's a thing that we never would have come to, I think, if we hadn't, like, actually been showing the prototype to end users.

+ +

LINDSEY: Okay, what is the second half of the exciting thing that happened in the past week?

+ +

JOSH: This is very much a thoughtbot thing. thoughtbot is full of really talented engineers. And over the past couple of days, we've been able to bring a lot of those folks to bear on the question of like, is this thing technically feasible or not? Which was one of my big concerns. And it turns out, that was probably too large a question for the team that we started with.

+ +

And to be able to, like, do this, like, little discovery spike with, you know, going beyond the three-and-a-half thoughtboter team that we had to some of your most talented, most experienced engineering leads, not forever, but just for, like, a short moment is kind of, for me, at least, like, a real taste of, like, the thoughtbot value is, you know, Jordyn gets to put out a call for assistance, you know, across the company, and people raise their hands and put real-time in.

+ +

And, you know, we're able to do something in a couple of days that we probably couldn't have done because we have enough people. And, you know, all those, like, network effects of people coming together that could have taken us, you know, weeks or longer just kind of toiling on our own.

+ +

LINDSEY: For those technical challenges, maybe you don't want to get into specifics, but in broad strokes, can you talk about what some of those considerations are? And maybe at this point, maybe it makes sense to also talk a little bit about, like, how the solution, how you're thinking about the evolution of what the solution is and provides.

+ +

JOSH: I have an Android phone. I live in the world as a green bubble in a world of blue bubbles. My partner and I are in an interfaith relationship. She has an iPhone. I have an Android phone. And forever, people are accidentally trying to hit up my, like, iMessage account tied to my email address, and the things don't come through. And, all of a sudden, this company someplace in the U.S. figured out some way to, like, reverse engineer the Apple messages iMessages protocol, so I can put iMessages onto my Android phone. They built this thing. It's been, like, all over the tech news recently.

+ +

This is the problem, if you're trying to bring together all of somebody's social network, is that there is no, like, handy-dandy API for iMessages. There is no handy-dandy API for regular SMS or RCS or any of those other variations of that. There is no handy-dandy API for WhatsApp, for Telegram, sort of ish, kind of maybe for Slack, not really for Discord. It remains to be seen how mature it is for LinkedIn. By the way, email works great, right? If we just build our entire lives off of email, we'd have none of these problems, but we can't.

+ +

And we had some hypotheses about ways that we could make connecting these other accounts easier. And we just took, like, an awful lot of hands, right? More than two hands. It took more than two hands to figure out if these things were possibilities if those things turn out to be true. And the answer is if they are true, which we're still working to figure out, though it's looking better and better, this isn't a science experiment, right? And if it's not true, then step one is an awful lot of engineer hours to go do what those Beeper Mini folks did and reverse engineer a whole bunch of protocols and systems that were never intended to be open in the first place.

+ +

JORDYN: I would like to say --

+ +

JOSH: Which is why we should all donate to EFF and promote an open internet so that startups like mine don't need to exist.

+ +

JORDYN: To loop back to your earlier question, Lindsey, about how to keep the team focused on who something is for, this conversation seems like it's not about that. But, to me, this conversation is also about that because we have a long list of messaging platforms that we have heard from folks, like from interviewing them would be useful to have brought into a single place.

+ +

This was one of the key pain points that Josh has that we heard from other people, which is, like, you connect with people across platforms, right? You might be connected to some on LinkedIn, but you're also emailing with them. Your email history with them is not a complete history of your life with them. None of your online stuff is going to be a complete history because sometimes you actually interact with people [laughs] in reality, which is still, at this moment, not being recorded all the time, but probably not for long.

+ +

JOSH: As little as possible.

+ +

JORDYN: [laughs] But still, even within the online world, you're communicating with people across platforms. Maybe you text with someone, maybe you message on LinkedIn, whatever. And having complete context for your relationship with them in a way that makes it really easy to kind of, like, boot up that context in order to reach out to them for some reason, like, maybe you haven't talked in six months, and you just want to remember, where did I leave this relationship? What's going on with this person, right? You're like, where was I talking to them? Oh, I was talking to them in these four places that don't have very good protocols for being brought into the same interface, right? So, like, the stuff is, like, all connected.

+ +

But to get back to the who question, we have this list of places we'd heard from people, like, in the early interviews and places that Josh was trying to do this connect with people, et cetera. So, it's, like, Slack DMs, and it's email, and it's LinkedIn, whatever. But we also heard Telegram, and we also heard other things. If we don't sufficiently focus on a narrow enough group of people, we risk making the MVP way too big because it needs to connect with every one of these things. And we can't go to market with something that doesn't connect with 12 platforms or something, right?

+ +

But because we're sufficiently focused, we could actually do the thing where we're like, okay, well, out of this list of platforms, what are, like, the top five? Where is the line? Where's the minimum viability here with what we can connect with that will actually bring value? And I also am an Android user living in an iPhone world. And Josh and I at least have enough awareness to be like, you know what? Maybe Android isn't necessary, even though we would love [laughs] for it to be there. Nine times out of 10, the people that look like us are using iPhones, right? So great, cool. Let's just do the thing.

+ +

JOSH: Obligatory iPhone test device.

+ +

JORDYN: Right. I have one, too, but I don't know where it is. So, like, the question of who really matters. Who, like, really helps you focus? If your answer to "Who?" is anybody with a smartphone, well, like, it's going to be really tough to build an actual MVP that's buildable. So, this question that Josh brought in to us, which is, like, "What's technically feasible here?" really intersects very directly with this question of who are we building for? Because you really want to be able to start somewhere.

+ +

And, you know, if you have a sufficiently red, hot need and it's not, like, to time travel or something that is, like, probably impossible given the laws of our universe, you can find a way, right? And so, the question was, like, why don't we find that so that we can focus on whether it's worth finding a way? And then that intersection of who it's for, what their pain points are, and what's possible with what amount of effort. It all fits together. No single one of those pieces is sufficient for figuring out a path forward.

+ +

LINDSEY: And are you taking the, you know, okay, we've gotten really good sight on these startup enthusiasts, and these are their top four communication methods; let's try to solve them? Is that the approach?

+ +

JORDYN: More or less, yeah. Yes. It's like, can we interface with those top...I think for us, it's like a top five, maybe six.

+ +

JOSH: Five or six.

+ +

JORDYN: But, like, the first one on there is email, and that's not a problem. Like, we don't...that's fine. LinkedIn is also not a problem; one and two are email, and LinkedIn: good. We're cool with that. That's okay.

+ +

JOSH: Because every individual has their own thing. So, you know, you may be talking about long tail services, you know, but for the person who uses Telegram as their, like, daily driver, which isn't most people in the U.S., but there's a lot of people abroad, not having Telegram means it isn't useful. And I think that's one of the things hard about this, right? This is a hard business potentially, or it's really easy. We have no idea yet. And that's part of what I find exciting about this is because over the next, you know, week or so, we'll find out how hard a business this is actually, or at least where are the technically difficult parts?

+ +

LINDSEY: Great segue. What does the next week look like as we've got market niche, prototype, technical feasibility intersectioning, figuring those things out? What exciting things are on the horizon? What's next?

+ +

JOSH: So, we have about two weeks left, and at the end of two weeks, we're going to end up with a set of high-quality prototypes, which, you know, are easy for any of us to have on our phones, and to flash around to rando strangers we meet at the grocery store because there's no better way to make friends than product testing. And we'll have a good sense of how big and complicated, and complicated in what ways might it be to build this thing.

+ +

And then, it's time for Josh to make some decisions around, you know, the whole goal of this was to figure out, like, how big of an opportunity is this just to go and do that? What could growth look like? What could pricing look like? Where might the costs be? What would the cost be to build this? Is this, like, a side gig scale thing? Is it a small, you know, angel-funded startup thing? Is this, like, a VC-size thing? I really hope it's not a VC-size thing.

+ +

And then to think about, you know, what are the resources that would be required to build it, and where might those resources come from? So, at the end of this, two weeks out from now, I think we'll have all the information, you know, that we need. And then, I know a whole bunch of people inside of thoughtbot who are in a great place to provide their own thoughts and advice and experience and feedback on this.

+ +

And I'll take this to my personal board of directors, including my family, but also, you know, other experienced entrepreneurs and investors I know, and we'll talk through this. And we'll have to go make some decisions, which is a little scary and a little bit fun, but a nice way to kick off 2024.

+ +

JORDYN: And a lot easier to do after this program.

+ +

JOSH: We'll have some real information, right? [laughs]

+ +

JORDYN: Yes.

+ +

LINDSEY: That's the goal, right?

+ +

JOSH: Yeah.

+ +

LINDSEY: Of the incubator to get you in that spot where you can make educated decisions and get others up to speed really quickly with all that research.

+ +

JOSH: That's right.

+ +

LINDSEY: That's great. All right. So, you had a call to action earlier. What was that? Oh, if startup enthusiasts are listening, we want to chat with them and talk to them about the solution.

+ +

JOSH: If you're a founder, if you're a multi-time founder and either done it a couple of times in the past or you're still doing it, reach out. If you are a startup chief of staff and you can define that role for yourself, please reach out. We'd love to talk to you there as well. If you would like a copy of Josh's free wireframing template for mobile apps, please reach out, and I will be happy to provide you that as well.

+ +

LINDSEY: Amazing. Thank you once again, Josh and Jordyn, for joining and catching us up. It definitely was an exciting update. I can't wait to hear what happens in the final stretch.

+ +

JOSH: Me too.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Jordyn Bonds and Josh Herzig-Marx .

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+d3JksHj3 + + ]]> + + Lindsey Christensen + Jordyn Bonds + Josh Herzig-Marx + + + 503: Epic Web and Remix with Kent C. Dodds + https://podcast.thoughtbot.com/503 + 635f974a-f575-4a3a-b66a-8cb28cc9aa89 + Thu, 07 Dec 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching. + +Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community. + +An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course. + +This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family. + 1:07:15 + no + + + Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching. +Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community. +An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course. +This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family. +Epic Web (https://www.epicweb.dev/) +Remix (https://remix.run/) +Follow Kent C. Dodds on LinkedIn (https://www.linkedin.com/in/kentcdodds/) or X (https://twitter.com/kentcdodds). Visit his website at kentcdodds.com (https://kentcdodds.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Kent C. Dodds. Kent is a JavaScript engineer and teacher. He has recently released a massive workshop called epicweb.dev. And he is the father of four kids. Kent, thank you for joining me. +KENT: Thank you so much for having me. It's an honor to be here. +WILL: Yeah. And it's an honor for me to have you. I am a huge fan. I think you're the one that taught me how to write tests and the importance of it. So, I'm excited to talk to you and just pick your brain and learn more about you. +KENT: Oh, thank you. +WILL: Yeah. So, I just want to start off just: who is Kent? What do you like to do? Tell us about your family, your hobbies, and things like that. +KENT: Yeah, sure. So, you mentioned I'm the father of four kids. That is true. We are actually expecting our fifth child any day now. So, we are really excited to have our growing family. And when I'm not developing software or material for people to learn how to develop software, I'm spending time with my family. I do have some other hobbies and things, but I try to share those with my family as much as I can. +So, it's starting to snow around here in Utah. And so, the mountains are starting to get white, and I look forward to going up there with my family to go skiing and snowboarding this season. During the summertime, I spend a lot of time on my one-wheel just riding around town and bring my kids with me when I can to ride bikes and stuff, too. So, that's sort of the personal side of my life. +And then, professionally, I have been in this industry developing for the web professionally for over a decade. Yeah, web development has just worked out super well for me. I kind of focused in on JavaScript primarily. And when I graduated with a master's degree in Information Systems at Brigham Young University, I started working in the industry. +I bounced around to a couple of different companies, most of them you don't know, but you'd probably be familiar with PayPal. I was there for a couple of years and then decided to go full-time on teaching, which I had been doing as, like, a part-time thing, or, like, on the side all those years. And yeah, when teaching was able to sustain my family's needs, then I just switched full-time. So, that was a couple of years ago that I did that. I think like, 2018 is when I did that. +I took a 10-month break to help Remix get off the ground, the Remix web framework. They got acquired by Shopify. And so, I went back to full-time teaching, not that I don't like Shopify, but I felt like my work was done, and I could go back to teaching. So, that's what I'm doing now, full-time teacher. +WILL: Wow. Yes, I definitely have questions around that. +KENT: [laughs] Okay. +WILL: So many. But I want to start back...you were saying you have four kids. What are their ages? +KENT: Yeah, my oldest is 11, youngest right now is 6, and then we'll have our fifth one. So, all four of the kids are pretty close in age. And then my wife and I thought we were done. And then last December, we kind of decided, you know what? I don't think we're done. I kind of think we want to do another. So, here we go. We've got a larger gap between my youngest and the next child than we have between my oldest and the youngest child. +WILL: [chuckles] +KENT: So, we're, like, starting a new family, or [laughs] something. +WILL: Yeah [laughs]. I just want to congratulate you on your fifth child. That's amazing. +KENT: Thank you. +WILL: Yeah. How are you feeling about that gap? +KENT: Yeah, we were pretty intentional about having our kids close together because when you do that, they have built-in friends that are always around. And as they grow older, you can do the same sorts of things with them. So, like, earlier this year, we went to Disneyland, and they all had a great time. They're all at the good age for that. And so, they actually will remember things and everything. +Yeah, we were pretty certain that four is a good number for us and everything. But yeah, we just started getting this nagging feeling we wanted another one. So, like, the fact that there's a big gap was definitely not in the plan. But I know a lot of people have big gaps in their families, and it's just fine. So, we're going to be okay; just it's going to change the dynamic and change some plans for us. But we're just super excited to have this next one. +WILL: I totally understand what you mean by having them close together. So, I have three little ones, and my oldest and my youngest share the same exact birthday, so they're exactly three years apart. +KENT: Oh, wow. Yeah, that's actually...that's fun. My current youngest and his next oldest brother are exactly two years apart. They share the same birthday, too [laughs]. +WILL: Wow. You're the first one I've heard that their kids share a birthday. +KENT: Yeah, I've got a sister who shares a birthday with her son. And I think we've got a couple of birthdays that are shared, but I also have 11 brothers and sisters [laughs]. And so, I have got a big family, lots of opportunity for shared birthdays in my family. +WILL: Yeah, I was actually going to ask you about that. How was it? I think you're the 11th. So, you're the youngest of 11? +KENT: I'm the second youngest. So, there are 12 of us total. I'm number 11. +WILL: Okay, how was that growing up with that many siblings? +KENT: I loved it. Being one of the youngest I didn't really...my experience was very different from my older siblings. Where my older siblings probably ended up doing a fair bit of babysitting and helping around the house in that way, I was the one being babysat. And so, like, by the time I got to be, like, a preteen, or whatever, lots of my siblings had already moved out. I was already an uncle by the time I was six. +I vaguely remember all 12 of us being together, but most of my growing up was just every other year; I'd have another sibling move out of the house, which was kind of sad. But they'd always come back and visit. And now I just have an awesome relationship with every one of my family members. And I have something, like, 55 nieces and nephews or more. Yeah, getting all of us together every couple of years for reunions is really a special experience. It's a lot of fun. +WILL: Yeah. My mom, she had 12 brothers and sisters. +KENT: Whoa. +WILL: And I honestly miss it because we used to get together all the time. I used to live a lot closer. Most of them are in Louisiana or around that area, and now I'm in South Florida, so I don't get to see them as often. But yeah, I used to love getting together. I had so many cousins, and we got in so much trouble...and it was -- +KENT: [laughs] +WILL: We loved it [laughs]. +KENT: Yeah, that's wonderful. I love that. +WILL: Yeah. Well, I want to start here, like, how did you get your start? Because I know...I was doing some research, and I saw that, at one point, you were an AV tech. You were a computer technician. You even did maintenance. Like, what was the early start of your career like, and how did you get into web dev? +KENT: I've always been very interested in computers, my interest was largely video games. So, when I was younger, I had a friend who was a computer programmer or, like, would program stuff. We had visions of...I don't know if you're familiar with RuneScape, but it's this game that he used to play, and I would play a little bit. It was just a massive online multiplayer game. And so, we had visions of building one of those and having it just running in the background, making us money, as if that's how that works [laughter]. But he tried to teach me programming, and I just could not get it at all. +And so I realized at some point that playing video games all the time wasn't the most productive use of my time on computers, and if I wanted my parents to allow me to be on computers, I needed to demonstrate that I could be productive in learning, and making things, and stuff. So, I started blogging and making videos and just, like, music videos. +My friend, who was the programmer, he was into anime, or anime, as people incorrectly pronounce it. And [laughs] there was this website called amv.com or .org or something. It's Anime Music Videos. And so, we would watch these music videos. And I'd say, "I want to make a music video with Naruto." And so, I would make a bunch of music videos from the Naruto videos I downloaded, and that was a lot of fun. I also ran around with a camera to do that. +And then, with the blog, I wrote a blog about Google and the stuff that Google was, like, doing because I just thought it was a fascinating company. I always wanted to work at Google. In the process of, like, writing the blog, I got exposed to CSS and HTML, but I really didn't do a whole lot of programming. I also did a little bit of Google Docs. Spreadsheets had some JavaScript macros-type things that you could do. So, I did a little bit of that, but I never really got too far into programming. +Then I go to college, I'm thinking, you know what? I think I want to be a video editor. I really enjoy that. And so, my brother, who at the time was working at Micron, he did quality assurance on the memory they were making. So, he would build test automation, software and hardware for testing the memory they build. And so, he recommended that I go into electrical engineering. Because what he would say is, "If you understand computers at that foundational level, you can do anything with computers." And I'd say, "Well, I like computers. And if I go into video editing, I'm going to need to understand computers, too. So yeah, sure, let's let's do that." +I was also kind of interested in 3D animation and stuff like that, too. Like, I wasn't very good at it, but I was kind of interested in that, too. So, I thought, like, having a really good foundation on computers would be a good thing for me. Well, I was only at school for a semester when I took a break to go on a mission for my church [inaudible 09:42] mission. And when I got back and started getting back into things, I took a math refresher course. That was, like, a half a credit. It wasn't really a big thing, but I did terrible in it. I did so bad. +And it was about that time that I realized, you know what? I've been thinking my whole life that I'm good at math. And just thinking back, I have no idea why or any justification for why I thought I was good at math because in high school, I always struggled with it. I spent so much time with it. And in fact, my senior year, I somehow ended up with a free period of nothing else to do. I don't know how this happened. But, I used that free period to go to an extra edition of my calculus class. So, I was going to twice as much calculus working, like, crazy hard and thinking that I was good at this, and I superduper was not [laughter]. +And so, after getting back from my mission and taking that refresher course, I was like, you know what? Math is a really important part of engineering, and I'm not good at it at all, obviously. And so, I've got to pivot to something else. Well, before my mission, as part of the engineering major, you needed to take some programming classes. So, there was a Java programming class that I took and a computer systems class that included a lot of programming. +The computer systems was very low level, so we were doing zeros and ones. And I wrote a program in zeros and ones. All that it did was it would take input from the keyboard, and then spit that back out to you as output. That was what it did. But still, you know, many lines of zeros and ones and just, like, still, I can't believe I did that [laughter]. And then we upgraded from that to Assembly, and what a godsend that was [laughs], how wonderful Assembly was after working in machine code. But then we upgraded from that to C, and that's as far as that class went. And then, yeah, my Java class, we did a bunch of stuff. +And I just remember thinking or really struggling to find any practicality to what we were doing. Like, in the Java class, we were implementing the link to list data structure. And I was like, I do not care about this. This does not make any sense. Why should I care? We were doing these transistor diagrams in the computer systems class. And why do I care about that? I do not care about this at all. Like, this is not an interesting thing for me. So, I was convinced computer programming was definitely not what I wanted to do. +So, when I'm switching from electrical engineering, I'm thinking, well, what do I do? And my dad convinced me to try accounting. That was his profession. He was a certified public accountant. And so, I said, "Okay, I'll try that." I liked the first class, and so I switched my major to go into the business school for accounting. I needed to take the next accounting class, and I hated that so much. It was just dull and boring. And I'm so glad that I got out of that because [laughs] I can't imagine doing anything like that. +WILL: [laughs] +KENT: But as part of switching over to business school, I discovered information systems. What's really cool about that is that we were doing Excel spreadsheets and building web pages. But it was all, like, with a practical application of business and, like, solving business problems. And then, I was like, oh, okay, so I can do stuff with computers in a practical setting, and that's what got me really interested. So, I switched, finally, to information systems–made it into that program. And I was still not convinced I wanted to do programming. I just wanted to work with computers. +What ended up happening is the same time I got into the information systems program, I got married to my wife, and then I got this part-time job at a company called the More Good Foundation. It's a non-profit organization. And one of my jobs was to rip DVDs and upload those videos to YouTube, and then also download videos from one site and upload those to YouTube as well. And so, I was doing a lot of stuff with YouTube and video stuff. +And as part of my information systems class, I was taking another Java class. At that same time, I was like, you know, what I'm doing at work is super boring. Like, can you imagine your job is to put in a [inaudible 13:45] and then click a couple of buttons? And, like, it was so boring and error-prone, too. Like, okay, now I've got to type this out and, you know, I got to make sure it's the same, try and copy-paste as much as I can. And it was not fun. +And so, I thought, well, I'm pretty sure there are pieces of this that I could automate. And so, with the knowledge that I was getting in my information systems programming class, that was another Java class, I decided to write a program that automated a bunch of my stuff. And so, I asked my boss, like, "Can I automate this with writing software?" And I'm so glad that they said I could. +WILL: [laughs] +KENT: Because by the end of it, I had built software that allowed me to do way more than I ever could have before. I ended up uploading thousands of videos to their YouTube channels, which would have taken years to do. And they ended up actually being so happy with me. They had me present to the board of directors when they were asking for more money [laughs] and stuff. And it was really awesome. But still, I was not interested in being a programmer. Programming, to me, was just a means to an end. +WILL: Oh, wow. +KENT: Yeah, I guess there was just something in me that was like, I am not a programmer. So, anyway, further into the program of information systems, I interned as a business intelligence engineer over that next summer, and I ended up staying on there. And while I was supposed to be a business intelligence engineer, I did learn a lot about SQL, and star schema, and denormalized databases to optimize for read speed and everything. I learned a lot about that. But I just kept finding myself in positions where I would use my programming experience to automate things that were problematic for us in the business realm. And this was all still Java. +It was there that I finally realized, you know what? I think I actually do want to be a programmer. I actually really do enjoy this. And I like that it's practical, and it makes sense for me, so… +WILL: What year was that? +KENT: That would have been 2012. Then I got a new job where my job was actually to be a programmer at a company called Domo, where they do business intelligence, actually. So, it got my foot in the door a little bit since I was a business intelligence engineer already. I got hired on, actually, as a QA engineer doing automated testing, but I never really got into that. And they shifted me over pretty quick into helping with the web app. +And that is when I discovered JavaScript, and the whole, like, everything flooded out from there. I was like, wow, I thought I liked programming, but I had no idea how fun it could be. Because I felt like the chains had been broken. I no longer have to write Java. I can write JavaScript, and this was just so much better. +WILL: [laughs] +KENT: And so, yeah, I was there for a year and a half before I finally graduated. And I took a little break to work at USAA for a summer internship. And when I came back, I had another year and then converted to full-time. And so, yeah, there's my more detail than you were probably looking for, story of how I got into programming [laughs]. +WILL: No, I actually love it because like I said, I've used your software, your teachings, all that. And it's amazing to hear the story of how you got there. Because I feel like a lot of times, we just see the end result, but we don't know the struggle that you went through of even trying to find your way through what your purpose was, what you're trying to do. Because, at one point, you said you were trying to do accounting, then you were trying to do something else. So, it's amazing to see, like, when it clicked for you when you got into JavaScript, so that's amazing. +KENT: Yeah, it is kind of funny to think, like, some people have the story of, like, I knew I wanted to be a programmer from the very beginning, and it's just kind of funny for me to think back and, like, I was pretty certain I didn't want to be a programmer. +WILL: [laughs] +KENT: Like, not only did I, like, lots of people will say, "I never really thought about it, and then I saw it, and it was great." But I had thought about it. And I saw it, and I thought it was awful [laughter]. And so, yeah, I'm really glad that it worked out the way it did, though, because programming has just been a really fun thing. Like, I feel so blessed to be doing something that I actually enjoy doing. +Like so many of our ancestors, they would go to work because they cared about their family and they just wanted to feed their family. I'm so grateful to them for doing that. I am so lucky that I get to go to work to take care of my family, but also, I just love doing it. +WILL: Yeah, I feel the same way, so yeah, totally agree. After you found out about JavaScript, when did you figure out that you want to teach JavaScript? What was that transition like? +KENT: I've been teaching for my whole life. It's ingrained in my religion. Even as a kid, you know, I'd prepare a talk, a five-minute talk, and stand up in front of 30 of my peers. And even when you're an early teenager, you get into speaking in front of the entire congregation. It took a while before I got good enough at something, enough hubris to think that people would care about what I have to say -- +WILL: [laughs] +KENT: Outside of my religion where, like, they're sitting there, and I've been asked to speak, and so they're going to listen to me. And so, when I started getting pretty good at programming, I decided, hey, I want to teach this stuff that I'm learning. And so, when I was still at school and working at Domo, the business intelligence company, one of our co-workers, Dave Geddes, he put together a workshop to teach AngularJS because we were migrating from Backbone to Angular. And I asked him if I could use his workshop material to teach my classmates. +This was, like, soon after ng-conf, the first ng-conf, which my co-workers at Domo actually put on. So, I wasn't involved in the organization, but I was very much present when it was being organized. I attended there and developed a relationship with Firebase with the people there. I was actually...they had a developer evangelist program, which they called Torchbearers or something. And actually, that was my idea to call them Torchbearers. I think they wanted to call us torches, and I'm like, that just doesn't make sense. +WILL: [laughs] +KENT: I developed a relationship with them. And I asked them, "Hey, I want to teach my classmates AngularJS. Would you be interested in sponsoring some pizza and stuff?" And they said, "Yeah, we'll send you stickers, and hot sauce, and [laughs] a bunch of..." Like, they sent us, like, headphones [laughs] and stuff. So, I was like, sweet. I taught my classmates AngularJS in a workshop, brought a bunch of pizza, and it was, you know, just an extracurricular thing. +And actually, the recording is still on my YouTube channel, so if you want to go look at one of my early YouTube videos. I was very into publishing video online. So, if you are diligent, you'll be able to find some of my very early [laughter] videos from my teenage years. +But anyway, so, yes, I've been teaching since the very beginning. As soon as I graduated from college, I started speaking at meetups. I'd never been to a meetup before, and I just saw, oh, they want a speaker. I can talk about something. +WILL: Wow. +KENT: And not realizing that, like, meetups are literally always looking for speakers. This wasn't some special occasion. +WILL: [laughs] +KENT: And one of the meetups I spoke at was recorded and put on YouTube. And the guy who started Egghead io, John Lindquist, he is local here in Utah. And he saw that I spoke at that meetup, but he wasn't able to attend. So, he watched the recording, and he thought it was pretty good. He thought I would do a good job turning that into a video course. And that first video course paid my mortgage. +WILL: Wow. +KENT: And I was blown away. This thing that I had been doing just kind of for fun speaking at meetups, and I realized, oh, I can actually, like, make some legit good money out of this. From there, I just started making more courses on the side after I put the kids to bed. My wife is like, "Hey, I love you, but I want you to stay away for now because I've just been with these tiny babies all day. +WILL: [laughs] +KENT: And I just need some alone time." +WILL: Yes. +KENT: And so, I was like, okay. +WILL: [laughs] +KENT: I'll just go and work on some courses. And so, I spent a lot of time for the next couple of years doing course material on the side. I reached out to Frontend Masters and just told them, "Hey, I've been doing courses for Egghead." I actually met Marc Grabanski at a conference a couple of years before. And so, we established a little bit of relationship. And I just said, "Hey, I want to come and teach there." So, I taught at Frontend Masters. I started putting on my own workshops at conferences. +In fact, just a few months after graduating, I got accepted to speak at a conference. And only after I was accepted did I realize it was in Sweden [laughter]. I didn't think to look where in the world this conference was. So, that was my first international trip, actually, and I ended up speaking there. I gave, actually, two talks. One of them was a three-hour talk. +WILL: Whoa. +KENT: Which was, yeah, that was wild. +WILL: [laughs] +KENT: And then, yeah, I gave a two-day workshop for them. And then, I flew straight from there to Amsterdam to give another talk and also do a live in-person podcast, which I'd been running called ngAir, an Angular podcast. It just kept on building from there until finally, I created testingjavascript.com. And that was when I realized, oh, okay, so this isn't just a thing I can use to pay my mortgage, and that's nice. This is, like, a thing I can do full-time. Because I made more with Testing JavaScript than I made from my PayPal salary. +WILL: Oh wow. +KENT: I was like, oh, I don't need both of these things. I would rather work half as much one full-time job; that's what I want, one full-time job and make enough to take care of my family. And I prefer teaching. So, that's when I left PayPal was when I released Testing JavaScript. +WILL: Wow. So, for me, I think so many times the imposter syndrome comes up whenever I want to teach or do things at the level you're saying you're doing. Because I love teaching. I love mentoring. I remember when I came into development, it was hard. I had to find the right person to help me mentor. So now, I almost made a vow to myself that if someone wants to learn and they're willing to put in the energy, I'm going to sit down however long it takes to help them because I remember how hard it was for me whenever I was doing it. +So, you said in 2014, you were only a couple years doing development. How did you overcome impostor syndrome to stand in front of people, teach, go around the world, and give talks and podcasts? Like, how did you do that portion? +KENT: Part of it is a certain level of hubris like I said. Like, you just have to be willing to believe that somebody's going to care. You know, the other part of it is, it's a secret to getting really, really good at something. They sometimes will say, like, those who can't do teach. That's total baloney because it requires a lot of being able to do to get you in a position where you can teach effectively. But the process of teaching makes you better at the process of doing as well. It's how you solidify your experience as a whatever. So, if you're a cook, you're really good at that; you will get better by teaching other people how to cook. +There's an element of selfishness in what I do. I just want to get really, really good at this, and so I'm going to teach people so that I can. So yeah, I think there's got to be also, like, a little bit of thick skin, too, because people are going to maybe not like what you have to share or think that you're posing or whatever. Learn how to let that slide off you a little bit. +But another thing is, like, as far as that's concerned, just being really honest about what your skill set is. So, if somebody asks me a question about GraphQL, I'm going to tell them, "Well, I did use GraphQL at PayPal, but I was pretty limited. And so, I don't have a lot of experience with that," and then I'll answer their question. And so, like, communicating your limitations of knowledge effectively and being okay being judged by people because they're going to judge you. It just is the way it is. So, you just have to learn how to cope well with that. +There are definitely some times where I felt like I was in over my head on some subjects or I was involved in a conversation I had no business being there. I actually felt that a lot when I was sent as PayPal's delegate to the TC39 meetings. Wow, what am I doing here? I've only been in the industry for, like, two or three years at [laughter] that point. It takes a certain level of confidence in your own abilities. But also, like, being realistic about your inexperience as well, I think, is important too. +WILL: Yeah, I know that you had a lot of success, and I want to cover that next. But were there any failures when you were doing those teaching moments? +KENT: Years ago, Babel was still a new thing that everybody was using to compile their JavaScript with new syntax features down to JavaScript that the browser could run. There was ES Modules that was introduced, and lots of us were doing global window object stuff. And then we moved to, like, defining your dependencies with r.js or RequireJS. And then, there was CommonJS, and Universal Module Definition, and that sort of thing. So, ECMAScript modules were very exciting. Like, people were really interested in that. And so, Babel added support to it. It would compile from the module syntax down to whatever you wanted: CommonJS or...well, I'm pretty sure it could compile to RequireJS, but I compiled it to CommonJS. +And so, there was a...yeah, I would say it's a bug in Babel at that time, where it would allow you to write your ES modules in a way that was not actually spec-compliant. It was incorrect. So, I would say export default some object, and then in another module, I would say import. And then, I'd select properties off of the object that I exported, that default I exported. That was allowed by Babel, but it is superduper, not how ECMAScript modules work. +Well, the problem is that I taught, like, a ton of people how to use ECMAScript modules this way. And when I realized that I was mistaken, it was just, like, a knife to the heart because I was, like, I taught so many people this wrong thing. And so, I wrote a blog post about it. I gave a big, long talk titled “More Than You Want to Know About ECMAScript Modules,” where I talk about that with many other things as well. And so, yeah, just trying to do my part to make up for the mistake that I made. So yes, I definitely have had mistakes like that. +There's also, like, the aspect that technology moves at a rapid pace. And so, I have old things that I would show people how to do, which they still work just as well as they worked back then. But I wouldn't recommend doing it that way because we have better ways now. For some people, the old way to do it is the only way they can do it based on the constraints they have and the tools that they're using and stuff. And so, it's not, like, it's not valuable at all. But it is a struggle to make sure that people understand that, like, this is the way that you do it if you have to do it this way, but, like, we've got better ways. +WILL: I'm glad you shared that because it helps. And I love how you say it: when I make a mistake, I own up to it and let everyone know, "Hey, I made a mistake. Let's correct it and move on." So, I really like that. +KENT: Yeah, 100%. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +WILL: I want to go back to what you were saying. When you left PayPal, you released Testing JavaScript. How did you come up with the idea to write a Testing JavaScript course? And, two, how long did it take to take off and be successful? +KENT: That was a pretty special thing, honestly. In 2018, I had put together a bunch of workshops related to testing. There was this conference called Assert(js) that invited me to come, taught them. In the year prior, I went to Midwest JS and taught how to test React. I had this material about testing. I'd gotten into testing just because of open-source stuff. I didn't want to have to manually go through all my stuff again every time I wanted to check for breakages and stuff, so that got me into testing. And whatever I'm into is what I'm going to teach. So, I started teaching that testing. +And then my friend, Ryan Florence, put together...he separated from Michael Jackson with React Training, and built his own thing called Workshop.me. He asked me to join up with him. And he would, like, put together these workshops for me, and I would just...my job was just to show up and teach. And so, I did that. I have a picture, actually, in this blog post, The 2010s Decade in Review, of me in front of 60 people at a two-day workshop at Trulia in San Francisco. +WILL: Oh, wow. +KENT: And this is where I was teaching my testing workshop. Well, what's interesting about that photo is that two weeks before that, I had gotten really frustrated with the tool that everybody uses or used at the time for testing React, and that was Enzyme. And so I was preparing this workshop or working on it. I had already delivered it a number of times, but I was working on it, improving it, as I always do [laughs] when I'm preparing. +WILL: [laughs] +KENT: I can never give the same workshop twice, I guess. And I was just so frustrated that Enzyme was so difficult to work with. And, like, I was going to prepare this document that said, "Here are all the things you should never do with Enzyme. Like, Enzyme encourages you to do these things; you should not do these things. And let me explain why." And I just hated that I needed a document like that. +And so, I tweeted, "I'm seriously starting to think that I should make my own very small testing lib and drop Enzyme entirely. Most of Enzyme's features are not at all useful and many damaging to my test bases. I'd rather have something smaller that encourages better practices." And so, I tweeted that March 15th, 2018. I did that. I did exactly that. +What I often do in my workshops is I try to build the abstraction that we're going to use so that you can use it better. So, I was, like, building Enzyme, and I realized the jump between what I had built, the little utilities that I had built as part of the workshop, from that to Enzyme was just a huge leap. And so, I thought, you know what? These utilities that I have built to teach Enzyme are actually really good. What if I just turned that into a testing utility? And that became Testing Library, which, fast forward to today, is the number one testing library for React. And it's recommended for testing React, and Vue, and Angular. +The ideas that are in Testing Library got adopted by Playwright. If you're writing tests for anything in the browser, you are very likely using something that was either originally developed by me or inspired by the work that I did. And it all came from that testing workshop that I was working on. So, with that, I had not only that testing workshop; I had a number of other workshops around testing. +And so I approached Joel Hooks from Egghead.io. I say, "Hey, I'm getting ready to record a bunch of Egghead courses. I've got, like, six or seven courses I want to do." And he'd seen my work before, you know, I was a very productive course creator. And he said, "Hey, how about we, you know, we've been thinking about doing this special thing. How about we make a website just dedicated to your courses?" And I said, "That sounds great." +I was a little bit apprehensive because I knew that putting stuff on Egghead meant that I had, like, a built-in audience and everything that was on Egghead, so this would be really the first time of me just branching out with video material on my own. Because, otherwise, if it wasn't Egghead, it was Frontend Masters, and there was the built-in audience there. But yeah, we decided to go for it. And we released it in, I think, November. +And it was that first week...which is always when you make the most is during the launch period. But that launch week, I made more than my PayPal salary for the entire year. And so, that was when I realized, oh, yeah, okay, let's go full-time on this because I don't need two PayPal salaries. I just need one. And then I can spend more time with my family and stuff. And especially as the kids are getting older, they're staying up later, and I want to hang out with them instead of with my computer at night [laughter], and so... +WILL: I love how you explain that because I came in around 2018, 2019. And I remember Enzyme, and it was so confusing, so hard to work with, especially for, you know, a junior dev that's just trying to figure it out. And I remember Testing JavaScript and then using that library, and it was just so much easier to, like, grab whatever you needed to grab. Those utils made the biggest difference, and still today, they make a huge difference. So yes, I just resonate with what you're saying. That's amazing. +KENT: Aw, thank you so much. +WILL: Yeah. You did Testing JavaScript. And then what was your next course that you did? +KENT: I quit PayPal, go full-time teaching. That first year, I actually did an update to Testing JavaScript. There were a couple of changes in Testing Library and other things that I needed to update it for. And then I started working on Epic React. So, while I was doing all this testing stuff, I was also very into React, creating a bunch of workshops around that. I was invited to speak all over the world to talk about React. And I had a couple of workshops already for React. So, I was invited to give workshops at these conferences about React. +And so, I thought, you know, let's do this again, and we'll do it with React this time. The other thing was, I'd never really planned on being the testing guy. It just kind of happened, and I actually didn't really like it either. I wanted to be more broad than just testing. So, that kind of motivated me to say, hey, let's do something with React to be a little bit more broad. +Yeah, so I worked on putting those workshops together and delivered them remotely. And then, yeah, COVID hit, and just really messed everything up [laughs] really bad. So, I had everything done on my end for Epic React by March of 2020, which is, like, immediately after COVID got started, in the U.S. at least. And so, yeah, then we actually didn't end up releasing Epic React until October that year, which, honestly [laughs], was a little bit frustrating for me because I was like, "Hey, guys, I have recorded all the videos and everything. Can we get this released?" But, like, that just was a really rough year for everybody. +But yeah, so Egghead got the site put together. I did a bunch of interviews and stuff. And then we launched in October of 2020. That was way bigger than Testing JavaScript because Testing JavaScript was still very informed by my experience as an Egghead instructor, which, typically, the Egghead courses are, like, a video where watch me do this thing, and then you'll learn something and go apply it to your own stuff. And that's kind of what Testing JavaScript was built as. +But as part of the update of Testing JavaScript in 2019, I added another workshop module called Testing Node Applications. And in that one, I decided, hey, typically, I would have a workshop version of my material and a course version. The workshop version had like instructions and exercises. And the course version was no instructions or anything. It was just, like, watch these videos. And it was just me doing the exercises. +And with the update of Testing JavaScript, I added that Testing Node workshop, and I said, hey, what if we just, like, embrace the fact that these are exercises, and it's just, like, me recording the workshop? How I would deliver the workshop? And so, I tested that out, and that went really well. And so, I doubled down on that with Epic React. And I said, okay, now, this isn't just, like, watch these videos. This is a do the exercise and then watch me do the exercise. +So, Epic React was not only a lot more material but the format of the material was more geared for retention and true practice and learning. And so, Epic React ended up doing much better than Testing JavaScript, and even still, is still doing a remarkable job as far as course material is concerned. And, like, so many people are getting a lot of really great knowledge from Epic React. So yeah, very gratifying to have that. +WILL: Once again, I've used Epic React. It's taught me so many...stretched me. And I do like the format, so yes, I totally agree with that, yeah. The next thing, Remix, correct? +KENT: Yeah. So, how I got into Remix, around the same time we finished recording Epic React videos, I was doing some other stuff kind of to keep content going and stuff while we were waiting to launch Epic React. And around that same time, my friend Ryan Florence and Michael Jackson––they were doing the React training thing. And so, we were technically competitors. Like I said, Ryan and I kind of joined forces temporarily for his Workshop Me thing, but that didn't end up working out very well. And Michael really wanted Ryan back, and so they got back together. +And their React training business went way better than it had before. They were hiring people and all sorts of stuff. And then, a training business that focuses on in-person training just doesn't do very well when COVID comes around. And so, they ended up having to lay off everybody and tried to figure out, okay, now what are we going to do? Our income has gone overnight. This is a bit of a simplification. But they decided to build software and get paid for it like one does. +So, they started building Remix. Ryan, actually, around that time, moved back to Utah. He and I would hang out sometimes, and he would share what he was working on with Michael. We would do, like, Zoom calls and stuff, too. I just got really excited about what they were working on. I could see the foundation was really solid, and I thought it was awesome. But I was still working on Epic React. +I end up launching Epic React. He launches Remix the very next month as a developer preview thing. Yeah, it definitely...it looked a lot like current Remix in some ways but very, very different in lots of others. But I was super hooked on that. And so, I paid for the developer preview and started developing my website with it. And around the next year in August, I was getting close to finishing my website. +My website is, like, pretty legit. If you haven't gone to kentcdodds.com. Yet, it is cooler than you think it is. There's a lot that goes into that website. So, I had a team help me with the product planning and getting illustrations and had somebody help me implement the designs and all that stuff. It was a pretty big project. +And then, by August of 2021, Ryan and I were talking, and I said, "Hey, listen, I want to update Epic React to use Remix because I just think that is the best way to build React applications. But I have this little problem where Remix is a paid framework. That's just going to really reduce the number of people who are interested in learning what I have to teach. And on top of that, like, it just makes it difficult for people to test things out." And so, he, around that time, was like, "Hey, just hold off a little bit. We've got some announcements." +And so, I think it was September when they announced that they'd raised VC money and they were going to make Remix open source. That was when Ryan said, "Hey, listen, Kent, I think that it's awesome you want to update Epic React to use Remix. But the problem is that Remix isn't even 1.0 yet. The community is super small. It needs a lot of help. If you release a course on Remix right now, then you're not going to get any attention because, like, nobody even knows what it is." +So, part of me is like, yeah, that's true. But also, the other part of me is like, how do people find out what it is [laughs] unless there's, like, material about it? But he was right. And he said, "Listen, we've got a bunch of VC money. I've always wanted to work with you. How about we just hire you? And you can be a full-time teacher about Remix. But you don't have to charge anything. You just, like, make a bunch of stuff for free about Remix." I said, "That sounds great. But, you know, to make that worth my while because I'm really happy with what I'm doing with this teaching thing, like, I'm going to need a lot of Remix." +And so, Michael Jackson was like, "How about we just make you a co-founder, and we give you a lot of Remix?" And I said, "Okay, let's do this." And so I jumped on board with them as a year-delayed co-founder. I guess that's pretty common. But, like, that felt kind of weird to me [laughs] to be called a co-founder. But yeah, so I joined up with them. +I worked on documentation a little bit, mostly community building. I ran Remix Conf. Shopify was interested in what we were doing. And we were interested in what Shopify was doing because, at the time, they were working on Hydrogen, which was one of the early adopters of React Server Components. And, of course, everybody was interested in whether Remix was going to be adding support for server components. And Ryan put together a couple of experiments and found out that server components were nowhere near ready. And we could do better than server components could as of, you know, the time that he wrote the blog posts, like, two years ago. +So, Hydrogen was working with server components. And I put us in touch with the Hydrogen team—I think it was me—to, like, talk with the Hydrogen team about, like, "Hey, how about instead of spending all this time building your own framework, you just build on top of Remix then you can, you know, make your Shopify starter projects just, like, a really thin layer on top of Remix and people will love it? And this is very important to us because we need to get users, especially really big and high profile users, so people will take us seriously." +And so, we have this meeting. They fly a bunch of their people out to Salt Lake. They're asking us questions. We're asking them questions and saying, "Hey, listen, this is why server components are just not going to work out for you." Well, apparently, they didn't listen to us. It felt like they were just like, "No, we're highly invested in this. We've already sunk all this cost into this, but we're going to keep going." And they did end up shipping Hydrogen version 1 on top of server components, which I just thought was a big mistake. +And it wasn't too long after that they came back and said, "Hey, we're kind of interested in having you guys join Shopify." So, right after Remix Conf, I go up into Michael's room at the hotel with Ryan. And they say, "Hey, listen, Kent, we're talking with Shopify about selling Remix and joining Shopify," and kind of bounced back and forth on whether we wanted to do it. All of us were just not sure. Because when I joined Remix, I was thinking, okay, we're going to build something, and it's going to be huge. This is going to be bigger than Vercel, like multibillion-dollar company. So, I really kind of struggled with thinking, hey, we're selling out. Like, we're just getting started here. +So, Ryan and I ended up at RenderATL in Atlanta at that conference. We were both speaking there. And Ryan didn't fill out the right form. So, he actually didn't have a hotel room [laughs], and so he ended up staying in my room. I intentionally always get a double bedroom just in case somebody needs to stay with me because somebody did that for me once, and I just...it was really nice of them. So, I've always done that since. And so, I said, "Yeah, Ryan, you can stay with me." +And so, we spent just a ton of time together. And this was all while we were trying to decide what to do with Shopify. And we had a lot of conversations about, like, what do we want for Remix in the future? And it was there that I realized, oh if I want to take this to, like, multi-billion dollar valuation, I've got to do things that I am not at all interested in doing. Like, you've got to build a business that is worth that much money and do business-related things. +On top of all of that, to get any money out of it...because I just had a percentage of the company, not actually any money. There was no stock. So, the only way you can get money out of a situation like that is if you have a liquidation event like an IPO, which sounds, like, awful—I [laughs] would hate to go through an IP0—or you have to be bought. And if you're worth $2 billion, or 3, or whatever, who can buy you? There's almost nobody who can buy you at that valuation. Do you really want to outprice anybody that could possibly buy you? +And then, on top of that, to get there, that's, like, a decade worth of your life of working really superduper hard to get to that point, and there's no guarantee. Ryan would always say a bird in the hand is worth two in the bush. He was saying Shopify is a bird in the hand, and we do not know what the future holds. And so, we were all finally convinced that, yeah, we want to sell, and so we decided, yeah, let's sell. +And as the sale date grew closer, I was getting excited because I was like, oh, I can be back on the TC39 because Shopify is, like, I don't know if they're actually sending delegates to the TC39, but I'm sure that they would be interested if I ask them to, like, "Hey, let's be involved in the evolution of JavaScript." And I know they're on the Web Working Group. Like, they're on a bunch of different committees and stuff. And I just thought it'd be really cool to get involved in the web platform again. And then, on top of that, I just thought, you know what? I'll just spend all my time teaching Shopify developers how to use Remix. That sounds like a lot of fun. +As things drew closer, I got more and more uneasy about that. And I thought, you know, I could probably do just as well for myself by going full-time teacher again. I've done this thing before. I just really like being a teacher and, like, having total control over everything that I do. And if I work at Shopify, they're going to tell me, "Hey, you need to, like, do this, and that, and the other." And I don't know if I want to go back to that. +And so, I decided, this is awesome. Super, super good job, folks. I think I've done everything for you that you need me to do. I'm going to bail out. And so, yeah, Shopify wasn't super jazzed about that. But the deal went through anyway. And that's how I ended my time at Shopify. +WILL: I love it. It's lining up perfectly because you say you left Shopify to go back doing more teaching. And then you released another course; that's Epic Web, correct? +KENT: Right. That was the reason I left Shopify or I didn't join up with Shopify is because I wanted to work on Epic Web. In this 2010s blog post, one of the last things that I mention...toward the bottom, there's a section, KCD EDU, which is basically, like, I wanted to help someone go from zero to my level as an engineer in a single place where I teach just all of the things that I can teach to get somebody there. And so I wanted to call it KCD EDU, but I guess you have to be an accredited university to get that domain or something. But that was the idea. +Erin Fox, back in 2020 she said, "I'm expecting you to announce your online Kent C. Dodds engineering bootcamp." And I replied, "I'm planning on doing this, no joke." So, I've been wanting to do this for a really long time. And so, leaving Remix was like, yeah, this is what I'm going to go do. I'm going to go build KCD EDU. +And I was talking with Ryan at some point about, like, what I was planning on doing in the future. And something he said or something I said in that conversation made me realize, oh, shoot, I want to build Epic Web Dev. So, I've got Epic React. I don't want Epic Remix. I want people to, like, be web developers. Remix is just, like, an implementation detail. And so, I went and I was relieved to find that the domain was still available: epicweb.dev, and so I bought that. And so, I was always planning on, like, even while I was at Remix, eventually, I would leave Remix and go build Epic Web Dev. So, that's what I did. +Starting in August, I decided, okay, how about this: I will build a legit real-world web application, and then I will use that to teach people how to build legit real-world web applications from start to finish. If it's included as, like, knowledge you would need to build this web app, then that's knowledge you need to be able to build a full-stack application. That was the idea. +So, I started live streaming in, like, August or September, and I would live stream almost everyday development of this web app. So, people can go and watch those on my YouTube channel. I would livestream for, like, sometimes six hours at a time with breaks every 45 minutes. So, I'd just put it on a break slide, go for a quick walk, or take a drink, whatever, and then I would come back. And I would just, like, so much development and live streaming for a long time. +Once I got, like, in a pretty good place with that, the app I was building was called Rocket Rental. It's like Airbnb for rocket ships. So, you could rent, like, your own rocket ship to other people to fly. So, it had to be, like, realistic enough that, like, you could relate it to whatever you were building but not realistic enough that people would actually think it was a real product [laughs]. +I worked with Egghead again. They actually have a sister company now called Skill Recordings that's responsible for these types of products. And so, I was working with Skill Recordings on, like, they would get me designs. And then I would, like, work with other people to help implement some of those designs. And then, I started working on turning this stuff into workshops. +And with Epic React, we have this workshop app that you run locally so that you can work in your own editor, in your own environment, and with your own editor plugins and all that stuff. I want you to practice the way that you're going to actually exercise that practice when you're done––when you're working at work. And so we have this workshop app with Epic React. Well, that was built with Create React app, very limited on what you could do. +And so, I started working on a new workshop app that I just called KCD Shop, that was built with Remix. And so, now we've got a bunch of server-side stuff we can do. And this server side is running on your machine. And so, so much stuff that I can do with this thing. +One of the big challenges with Epic React was that the video you watch is on epicreact.dev, but the exercises you run are on localhost. And so, you have to keep those things in sync. You'd see, okay, I'm in exercise one on the videos. Let me go find exercise one in the app and then find the file exercise one. So, you've got, like, three different things you've got to keep in sync. +And so, with the workshop app for Epic Web, I said, how about we make it so that we can embed the video into the app? And so, you just have localhost running, and you see the video right above the instructions for the exercise. And so, you watch the video that kind of introduces the problem that you're going to be doing, and then you read the instructions. And then we can also make it so that we have links you can click or buttons you can click in the app that will open your editor exactly where you're supposed to go. +So you don't have to keep anything in sync. You go to the app, and you watch the video. You read the instructions. You click this button. It opens your editor. And so, that's exactly what I did. And it's an amazing experience. It is phenomenal, not just for the workshop learners but for me, as a workshop developer, like, creating the workshop––it's just been phenomenal. Because, like, we also have this diff view where you can see the difference between your work in progress and the solution. So, if you get stuck, then it's very easy to see where you went wrong. +It also means that we can build even very large applications as part of our workshop and our exercise where there are dozens or hundreds of files. And you don't have to worry about finding them because it'll tell you exactly which ones you need to be working in, so all sorts of really, really cool things. So, this workshop app––actually, took a lot of time and effort to build. But now that it's done, like, people are going through it now, and they're just loving it. +So, I built the workshop app, I put the first workshop of Rocket Rental into this workshop app, and I delivered it. And I found out very quickly that a full application with all the bells and whistles you'd expect, like, tons of different routes and stuff, was just too much. Even with the workshop app, it was just really pretty difficult for people to gain enough context around what they were building to be effective. So, I was concerned about that. +But then, around the same time, I started realizing that I had a marketing problem. And that is that with Testing JavaScript, people know that they're customers because they're like, I'm a JavaScript developer, and I know how to test––boom. I'm a Testing JavaScript customer. With Epic React, I join this company; they're using React; I need to know React, boom. I'm a customer of Epic React. +But with something like Epic Web, it's just so broad that, like, yeah, I am a web developer. I just don't know if I'm a customer to Epic Web. Like, is Epic Web for only really advanced people, or is it only for really beginner people? Or is it only for people who are using this set of tools or... Like, it's just a very difficult thing to, like, identify with. And so I wanted to de-emphasize the fact that we used Remix because the fact is that you can walk away from this material and work in a Next.js app or a SvelteKit app and still use so much of the knowledge that you gained in that environment. +So, I didn't want to focus on the fact that we're using any particular set of tools because the tools themselves I select them, not only because I think that they are really great tools but also because the knowledge you gain from these tools is very transferable. And I'm going to teach it in a way that's very transferable. That was the plan. +But I still had this issue, like, I need people to be able to identify themselves as customers of this thing. So, what I decided to do through some, like, hints and inspiration from other people was how about I turn Rocket Rental into a much simpler app and make that a project starter? And while I was at Remix, actually, I directed the creation of this feature called Remix Stacks. It's basically the CLI allows you to create a Remix app based on a template. I said I can make a Remix Stack out of this, and I called it the Epic Stack. +And so, just took all of the concepts that came from Rocket Rental; applied it to a much simpler app. It's just a note-taking app, but it has, like, all of the features that you would need to build in a typical application. So, it's got a database. It's got deployment, GitHub integration. So, you have GitHub Actions to run tests and stuff. It has the tests. It has authentication already implemented, and even two-factor auth, and third-party auth, and file upload, and, like, just tons and tons of stuff built in. And so, people can start a new project and ship that and have a lot of success, like, skip all the basic stuff. +So, I presented that at Remix Conf. I wasn't working at Remix anymore, but they asked me to run Remix Conf again, so I did. And I told them, "If I'm running it this year, I'm going to select myself to speak." And I spoke and introduced the Epic Stack there. And then that was when I started to create the workshops based on the Epic Stack. +And so, now it was no longer we're going to have workshops to build Rocket Rental; it was we're going to have workshops to build the Epic Stack, with the idea being that if you build the thing, you are able to use it better, like, still following the same pattern I did with Testing JavaScript where we build a framework first. Like, before you start using Jest, we're building Jest and same with Testing Library. We do the same thing with React. Before we bring in React, I teach you how to create DOM nodes yourself and render those to the page and all of that. +And so, here with Epic Web, I'm going to teach you how to build the framework that you can use to build applications. So, that is what Epic Web is, it's effectively we're building the Epic Stack. In the process, you learn all about really basic things, like, how do you get styles onto the page all the way to really complex things like, how do you validate a user's email? Or how do you implement two-factor auth? Or how do you create a test database? So, you don't have to mock out the database, but you can still run your test in isolation. +Around this time was when my wife and I were trying to become pregnant. And we got the news that we were expecting, and we were super excited. And so, I'm thinking, okay, I've got to ship this thing before the baby comes. Because who knows what happens after this baby comes? So, I am talking with Skill Recordings. I'm saying, "We've got to get this done by October." I think it was May. +And so, I was thinking like, okay, I've probably got, like, maybe eight days worth of workshops here. And so, kind of outlined all of the workshops. Like, I know what needs to be included. I know what the end looks like because I've got the Epic Stack. The end is the Epic Stack. The beginning is, like, a brand new create Remix app creation right there. So, I know what the start and the end looks like. I kind of can figure out how much time I need to teach all of that. And I said, "Let's do eight days." +And so, we got that scheduled and started selling tickets. And we sold out 30 tickets in just a couple of days, and that's what we originally planned for. I'm like, well, gosh, I can handle 80 people in a workshop. I've done that before, but that's about as far as I go. I don't really like going that much. In fact, online, especially, I only like to go up to, like, 40. But we said, "Hey, let's knock this out of the park." So, we doubled it, and we sold another 30 seats. And so, it was sold out before even the early bird sale was over. So, that was pretty encouraging. +The problem was that I hadn't actually developed this material. I'd already given one workshop about testing with Rocket Rental, and I'd given one workshop about the fundamentals with Rocket Rental. But I hadn't done anything of the authentication or, the forms, or data modeling. Also, like, Epic Notes app is different from Rocket Rental. So, I got to rebuild those workshops. +Like, the first workshop was going to start in, like, two weeks, maybe three weeks. And so, I'm working on these workshops. And I'm like, I've finished the first workshop, which was going to be a two-day workshop, and so I get that done. And so, that next week, I'm getting close to finished on the forms workshop, and then I start the workshops. +And that was when I started to realize, oh, shoot, I am in huge trouble because I have to not only deliver two workshops a week, so that's two days a week that I'm not able to work on the workshops, really. And then also develop the material as I go, which I don't normally do this at all because I just don't like stressing myself out so much. But, like, I'd had this timeline put together, and I'm like, I need to ship this by October. +For about five weeks, I worked 80 to 100 hours a week, maybe more, in a row to get those workshops created [laughs]. And I do not recommend this, and I will never do it again. I can tell you this now. I didn't tell anybody at the time because I was worried that people would think, well, geez, is that the type of product you create, like, you're just rushing through this stuff? +But I can tell you this safely now because the results speak for themselves. Like, these people loved this stuff. They ate it up. It was so good. I won't do this again. It's not something that I typically do. But it worked. And, like, I put in a crazy amount of work to make this work. People loved it. And yeah, I'm really, really happy with that. +The next step, though, so it was eight days' worth of workshops in four weeks. And I realized, as I almost always realize when I'm presenting workshops, that, like, oh my gosh, I have way more material than I have time for. So, by the end of it, when I was all done, I'm pretty sure we've got around 16 days' worth of workshop material, so twice as much as I thought, which is; honestly, I shouldn't be surprised because this is always how it works. +So, I've got 16 days worth of workshops to record starting in August that needed to get all recorded six weeks before the launch date, which was my birthday. So, I have until, like, the first part of September to get all this stuff recorded. That is a lot to get recorded, but I managed to do that. So, in about four weeks, I recorded 450 videos. Like, anybody go through this material, and you'll be blown away that I was able to do this. So, I'm patting myself on the back, I know. I probably sound super cocky, but I nailed it. And it is so good. +I can credit a lot of my ability to record and get those videos produced, first, to the fact that I wasn't editing the videos. I would export the videos, and an editor would take care of editing it for me. And then, secondly, that I've done this for so long. I've just been creating workshops for a long time. I'm just really practiced at teaching while I'm typing and talking and everything. And then, also, just the level of preparation that I put into this workshop material. It was just a very well-oiled machine by this point. So, it ended up working out super-duper well. +So, I get the videos done. I'm recording a bunch of expert interviews with 25 people during the month of September. Then we launched on my birthday, October 18th. And it went superduper well. +WILL: Wow. That's a lot of video recording and a lot of stuff you have to do. I feel like that's most parents when they're trying to meet a deadline for a kid that you don't know when they're coming. It's like, oh, I got to do this. I got to do that before the baby comes. So, you did it. You were successful with that [laughter]. +KENT: Yeah, thank you. +WILL: Wow, who is this course for? +KENT: The course is for anybody who wants to learn how to build web applications the way I do. I like to focus my building of web applications on the primitives of the web platform as much as possible while acknowledging the practicality of using a framework. +If you want to be able to ship really awesome user experiences on the web platform, regardless of whether you're using the same tools I am, like, if you're not using Prisma, if you're not using Tailwind, if you're not using Remix, you're still going to walk away from this with a lot of really, really practical material. Because I don't really focus on the tools as much as I do on the patterns and the practical application of security practices and various things of that nature. So, anybody who wants to be really good at the web will benefit a lot from Epic Web. +WILL: Okay. And I'll put this in the show notes, but they can find it at epicweb.dev? +KENT: Mm-hmm. +WILL: Perfect. Okay. Is there anything else that you want to talk about around epicweb.dev? +KENT: I'll just reiterate that, like, your learning experience on epicweb.dev will be different from anything you've ever seen before. It will be a little bit similar to Epic React if you've done that before. But even still, the new workshop app is unreal, and people are loving it. +One feature that I really love about it is we try to make it so that you don't feel like you're learning alone because we learn better when we're learning together, and we feel like we're not alone. So, we have a presence feature on Epic Web. So, when you're working through the workshops, you can see all the other people that are currently working on the workshops as well. Of course, you can opt out of this if you don't want your face on there, but, like, it's just, like, a little pile of faces of people who are working on it. And it says where they're working right now. And it's just really, really cool to be able to have that camaraderie. +So, it's really geared toward retention. So, this is nothing like a Udemy course that is, like, a 45-hour thing that you just sit and watch. This is very hands-on. You will remember this stuff, and you will become a better developer when you're done. +WILL: Wow, wow. I love that I have not gotten the course, but I'm definitely looking into it. You've talked me into it. I'm going to go and try to try it out. So yes. +KENT: Cool. +WILL: Well, I want to close out on a couple of things that I saw. And it was just interesting hearing your story. Like, early on, you were talking about your purpose and kind of the things that you love. One thing that I picked up on is, like, you're saying that you love audio and video programming and teaching. It's amazing that that's essentially what you're doing now. +KENT: [laughs] +WILL: Like, that's what you're in right now. You're in teaching with audio and video, and you're teaching programming. +KENT: Hmm. Yeah, it is kind of funny how it, like, comes full circle. +WILL: Yeah, so I really love that. And then I have this thing, whenever I think something, especially positive, I try to tell people. I hate to not share what I'm thinking, especially when it's positive because I feel like if it's negative, we just do it so freely, but we never do the positive. +So, I think, for you, I want to just tell you you had a couple of things you were saying, like your purpose when writing software is the people. You want to teach people how to write awesome software to make the world a better place, and I just want you to know I know, for me, you've done that. You've helped me so much on my journey of coding and development. And I just really appreciate you and what you've done for the space. And I just want to say thank you. +KENT: Aw, Will, thank you. That does mean a lot to me. So, I really appreciate you saying that. +WILL: Yeah, awesome. Well, it was a great conversation. I loved learning more about you and just everything you shared. So, thank you for being a part of the podcast. +KENT: Thank you. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Kent C. Dodds. + + + Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching.

+ +

Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community.

+ +

An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course.

+ +

This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Kent C. Dodds. Kent is a JavaScript engineer and teacher. He has recently released a massive workshop called epicweb.dev. And he is the father of four kids. Kent, thank you for joining me.

+ +

KENT: Thank you so much for having me. It's an honor to be here.

+ +

WILL: Yeah. And it's an honor for me to have you. I am a huge fan. I think you're the one that taught me how to write tests and the importance of it. So, I'm excited to talk to you and just pick your brain and learn more about you.

+ +

KENT: Oh, thank you.

+ +

WILL: Yeah. So, I just want to start off just: who is Kent? What do you like to do? Tell us about your family, your hobbies, and things like that.

+ +

KENT: Yeah, sure. So, you mentioned I'm the father of four kids. That is true. We are actually expecting our fifth child any day now. So, we are really excited to have our growing family. And when I'm not developing software or material for people to learn how to develop software, I'm spending time with my family. I do have some other hobbies and things, but I try to share those with my family as much as I can.

+ +

So, it's starting to snow around here in Utah. And so, the mountains are starting to get white, and I look forward to going up there with my family to go skiing and snowboarding this season. During the summertime, I spend a lot of time on my one-wheel just riding around town and bring my kids with me when I can to ride bikes and stuff, too. So, that's sort of the personal side of my life.

+ +

And then, professionally, I have been in this industry developing for the web professionally for over a decade. Yeah, web development has just worked out super well for me. I kind of focused in on JavaScript primarily. And when I graduated with a master's degree in Information Systems at Brigham Young University, I started working in the industry.

+ +

I bounced around to a couple of different companies, most of them you don't know, but you'd probably be familiar with PayPal. I was there for a couple of years and then decided to go full-time on teaching, which I had been doing as, like, a part-time thing, or, like, on the side all those years. And yeah, when teaching was able to sustain my family's needs, then I just switched full-time. So, that was a couple of years ago that I did that. I think like, 2018 is when I did that.

+ +

I took a 10-month break to help Remix get off the ground, the Remix web framework. They got acquired by Shopify. And so, I went back to full-time teaching, not that I don't like Shopify, but I felt like my work was done, and I could go back to teaching. So, that's what I'm doing now, full-time teacher.

+ +

WILL: Wow. Yes, I definitely have questions around that.

+ +

KENT: [laughs] Okay.

+ +

WILL: So many. But I want to start back...you were saying you have four kids. What are their ages?

+ +

KENT: Yeah, my oldest is 11, youngest right now is 6, and then we'll have our fifth one. So, all four of the kids are pretty close in age. And then my wife and I thought we were done. And then last December, we kind of decided, you know what? I don't think we're done. I kind of think we want to do another. So, here we go. We've got a larger gap between my youngest and the next child than we have between my oldest and the youngest child.

+ +

WILL: [chuckles]

+ +

KENT: So, we're, like, starting a new family, or [laughs] something.

+ +

WILL: Yeah [laughs]. I just want to congratulate you on your fifth child. That's amazing.

+ +

KENT: Thank you.

+ +

WILL: Yeah. How are you feeling about that gap?

+ +

KENT: Yeah, we were pretty intentional about having our kids close together because when you do that, they have built-in friends that are always around. And as they grow older, you can do the same sorts of things with them. So, like, earlier this year, we went to Disneyland, and they all had a great time. They're all at the good age for that. And so, they actually will remember things and everything.

+ +

Yeah, we were pretty certain that four is a good number for us and everything. But yeah, we just started getting this nagging feeling we wanted another one. So, like, the fact that there's a big gap was definitely not in the plan. But I know a lot of people have big gaps in their families, and it's just fine. So, we're going to be okay; just it's going to change the dynamic and change some plans for us. But we're just super excited to have this next one.

+ +

WILL: I totally understand what you mean by having them close together. So, I have three little ones, and my oldest and my youngest share the same exact birthday, so they're exactly three years apart.

+ +

KENT: Oh, wow. Yeah, that's actually...that's fun. My current youngest and his next oldest brother are exactly two years apart. They share the same birthday, too [laughs].

+ +

WILL: Wow. You're the first one I've heard that their kids share a birthday.

+ +

KENT: Yeah, I've got a sister who shares a birthday with her son. And I think we've got a couple of birthdays that are shared, but I also have 11 brothers and sisters [laughs]. And so, I have got a big family, lots of opportunity for shared birthdays in my family.

+ +

WILL: Yeah, I was actually going to ask you about that. How was it? I think you're the 11th. So, you're the youngest of 11?

+ +

KENT: I'm the second youngest. So, there are 12 of us total. I'm number 11.

+ +

WILL: Okay, how was that growing up with that many siblings?

+ +

KENT: I loved it. Being one of the youngest I didn't really...my experience was very different from my older siblings. Where my older siblings probably ended up doing a fair bit of babysitting and helping around the house in that way, I was the one being babysat. And so, like, by the time I got to be, like, a preteen, or whatever, lots of my siblings had already moved out. I was already an uncle by the time I was six.

+ +

I vaguely remember all 12 of us being together, but most of my growing up was just every other year; I'd have another sibling move out of the house, which was kind of sad. But they'd always come back and visit. And now I just have an awesome relationship with every one of my family members. And I have something, like, 55 nieces and nephews or more. Yeah, getting all of us together every couple of years for reunions is really a special experience. It's a lot of fun.

+ +

WILL: Yeah. My mom, she had 12 brothers and sisters.

+ +

KENT: Whoa.

+ +

WILL: And I honestly miss it because we used to get together all the time. I used to live a lot closer. Most of them are in Louisiana or around that area, and now I'm in South Florida, so I don't get to see them as often. But yeah, I used to love getting together. I had so many cousins, and we got in so much trouble...and it was --

+ +

KENT: [laughs]

+ +

WILL: We loved it [laughs].

+ +

KENT: Yeah, that's wonderful. I love that.

+ +

WILL: Yeah. Well, I want to start here, like, how did you get your start? Because I know...I was doing some research, and I saw that, at one point, you were an AV tech. You were a computer technician. You even did maintenance. Like, what was the early start of your career like, and how did you get into web dev?

+ +

KENT: I've always been very interested in computers, my interest was largely video games. So, when I was younger, I had a friend who was a computer programmer or, like, would program stuff. We had visions of...I don't know if you're familiar with RuneScape, but it's this game that he used to play, and I would play a little bit. It was just a massive online multiplayer game. And so, we had visions of building one of those and having it just running in the background, making us money, as if that's how that works [laughter]. But he tried to teach me programming, and I just could not get it at all.

+ +

And so I realized at some point that playing video games all the time wasn't the most productive use of my time on computers, and if I wanted my parents to allow me to be on computers, I needed to demonstrate that I could be productive in learning, and making things, and stuff. So, I started blogging and making videos and just, like, music videos.

+ +

My friend, who was the programmer, he was into anime, or anime, as people incorrectly pronounce it. And [laughs] there was this website called amv.com or .org or something. It's Anime Music Videos. And so, we would watch these music videos. And I'd say, "I want to make a music video with Naruto." And so, I would make a bunch of music videos from the Naruto videos I downloaded, and that was a lot of fun. I also ran around with a camera to do that.

+ +

And then, with the blog, I wrote a blog about Google and the stuff that Google was, like, doing because I just thought it was a fascinating company. I always wanted to work at Google. In the process of, like, writing the blog, I got exposed to CSS and HTML, but I really didn't do a whole lot of programming. I also did a little bit of Google Docs. Spreadsheets had some JavaScript macros-type things that you could do. So, I did a little bit of that, but I never really got too far into programming.

+ +

Then I go to college, I'm thinking, you know what? I think I want to be a video editor. I really enjoy that. And so, my brother, who at the time was working at Micron, he did quality assurance on the memory they were making. So, he would build test automation, software and hardware for testing the memory they build. And so, he recommended that I go into electrical engineering. Because what he would say is, "If you understand computers at that foundational level, you can do anything with computers." And I'd say, "Well, I like computers. And if I go into video editing, I'm going to need to understand computers, too. So yeah, sure, let's let's do that."

+ +

I was also kind of interested in 3D animation and stuff like that, too. Like, I wasn't very good at it, but I was kind of interested in that, too. So, I thought, like, having a really good foundation on computers would be a good thing for me. Well, I was only at school for a semester when I took a break to go on a mission for my church [inaudible 09:42] mission. And when I got back and started getting back into things, I took a math refresher course. That was, like, a half a credit. It wasn't really a big thing, but I did terrible in it. I did so bad.

+ +

And it was about that time that I realized, you know what? I've been thinking my whole life that I'm good at math. And just thinking back, I have no idea why or any justification for why I thought I was good at math because in high school, I always struggled with it. I spent so much time with it. And in fact, my senior year, I somehow ended up with a free period of nothing else to do. I don't know how this happened. But, I used that free period to go to an extra edition of my calculus class. So, I was going to twice as much calculus working, like, crazy hard and thinking that I was good at this, and I superduper was not [laughter].

+ +

And so, after getting back from my mission and taking that refresher course, I was like, you know what? Math is a really important part of engineering, and I'm not good at it at all, obviously. And so, I've got to pivot to something else. Well, before my mission, as part of the engineering major, you needed to take some programming classes. So, there was a Java programming class that I took and a computer systems class that included a lot of programming.

+ +

The computer systems was very low level, so we were doing zeros and ones. And I wrote a program in zeros and ones. All that it did was it would take input from the keyboard, and then spit that back out to you as output. That was what it did. But still, you know, many lines of zeros and ones and just, like, still, I can't believe I did that [laughter]. And then we upgraded from that to Assembly, and what a godsend that was [laughs], how wonderful Assembly was after working in machine code. But then we upgraded from that to C, and that's as far as that class went. And then, yeah, my Java class, we did a bunch of stuff.

+ +

And I just remember thinking or really struggling to find any practicality to what we were doing. Like, in the Java class, we were implementing the link to list data structure. And I was like, I do not care about this. This does not make any sense. Why should I care? We were doing these transistor diagrams in the computer systems class. And why do I care about that? I do not care about this at all. Like, this is not an interesting thing for me. So, I was convinced computer programming was definitely not what I wanted to do.

+ +

So, when I'm switching from electrical engineering, I'm thinking, well, what do I do? And my dad convinced me to try accounting. That was his profession. He was a certified public accountant. And so, I said, "Okay, I'll try that." I liked the first class, and so I switched my major to go into the business school for accounting. I needed to take the next accounting class, and I hated that so much. It was just dull and boring. And I'm so glad that I got out of that because [laughs] I can't imagine doing anything like that.

+ +

WILL: [laughs]

+ +

KENT: But as part of switching over to business school, I discovered information systems. What's really cool about that is that we were doing Excel spreadsheets and building web pages. But it was all, like, with a practical application of business and, like, solving business problems. And then, I was like, oh, okay, so I can do stuff with computers in a practical setting, and that's what got me really interested. So, I switched, finally, to information systems–made it into that program. And I was still not convinced I wanted to do programming. I just wanted to work with computers.

+ +

What ended up happening is the same time I got into the information systems program, I got married to my wife, and then I got this part-time job at a company called the More Good Foundation. It's a non-profit organization. And one of my jobs was to rip DVDs and upload those videos to YouTube, and then also download videos from one site and upload those to YouTube as well. And so, I was doing a lot of stuff with YouTube and video stuff.

+ +

And as part of my information systems class, I was taking another Java class. At that same time, I was like, you know, what I'm doing at work is super boring. Like, can you imagine your job is to put in a [inaudible 13:45] and then click a couple of buttons? And, like, it was so boring and error-prone, too. Like, okay, now I've got to type this out and, you know, I got to make sure it's the same, try and copy-paste as much as I can. And it was not fun.

+ +

And so, I thought, well, I'm pretty sure there are pieces of this that I could automate. And so, with the knowledge that I was getting in my information systems programming class, that was another Java class, I decided to write a program that automated a bunch of my stuff. And so, I asked my boss, like, "Can I automate this with writing software?" And I'm so glad that they said I could.

+ +

WILL: [laughs]

+ +

KENT: Because by the end of it, I had built software that allowed me to do way more than I ever could have before. I ended up uploading thousands of videos to their YouTube channels, which would have taken years to do. And they ended up actually being so happy with me. They had me present to the board of directors when they were asking for more money [laughs] and stuff. And it was really awesome. But still, I was not interested in being a programmer. Programming, to me, was just a means to an end.

+ +

WILL: Oh, wow.

+ +

KENT: Yeah, I guess there was just something in me that was like, I am not a programmer. So, anyway, further into the program of information systems, I interned as a business intelligence engineer over that next summer, and I ended up staying on there. And while I was supposed to be a business intelligence engineer, I did learn a lot about SQL, and star schema, and denormalized databases to optimize for read speed and everything. I learned a lot about that. But I just kept finding myself in positions where I would use my programming experience to automate things that were problematic for us in the business realm. And this was all still Java.

+ +

It was there that I finally realized, you know what? I think I actually do want to be a programmer. I actually really do enjoy this. And I like that it's practical, and it makes sense for me, so…

+ +

WILL: What year was that?

+ +

KENT: That would have been 2012. Then I got a new job where my job was actually to be a programmer at a company called Domo, where they do business intelligence, actually. So, it got my foot in the door a little bit since I was a business intelligence engineer already. I got hired on, actually, as a QA engineer doing automated testing, but I never really got into that. And they shifted me over pretty quick into helping with the web app.

+ +

And that is when I discovered JavaScript, and the whole, like, everything flooded out from there. I was like, wow, I thought I liked programming, but I had no idea how fun it could be. Because I felt like the chains had been broken. I no longer have to write Java. I can write JavaScript, and this was just so much better.

+ +

WILL: [laughs]

+ +

KENT: And so, yeah, I was there for a year and a half before I finally graduated. And I took a little break to work at USAA for a summer internship. And when I came back, I had another year and then converted to full-time. And so, yeah, there's my more detail than you were probably looking for, story of how I got into programming [laughs].

+ +

WILL: No, I actually love it because like I said, I've used your software, your teachings, all that. And it's amazing to hear the story of how you got there. Because I feel like a lot of times, we just see the end result, but we don't know the struggle that you went through of even trying to find your way through what your purpose was, what you're trying to do. Because, at one point, you said you were trying to do accounting, then you were trying to do something else. So, it's amazing to see, like, when it clicked for you when you got into JavaScript, so that's amazing.

+ +

KENT: Yeah, it is kind of funny to think, like, some people have the story of, like, I knew I wanted to be a programmer from the very beginning, and it's just kind of funny for me to think back and, like, I was pretty certain I didn't want to be a programmer.

+ +

WILL: [laughs]

+ +

KENT: Like, not only did I, like, lots of people will say, "I never really thought about it, and then I saw it, and it was great." But I had thought about it. And I saw it, and I thought it was awful [laughter]. And so, yeah, I'm really glad that it worked out the way it did, though, because programming has just been a really fun thing. Like, I feel so blessed to be doing something that I actually enjoy doing.

+ +

Like so many of our ancestors, they would go to work because they cared about their family and they just wanted to feed their family. I'm so grateful to them for doing that. I am so lucky that I get to go to work to take care of my family, but also, I just love doing it.

+ +

WILL: Yeah, I feel the same way, so yeah, totally agree. After you found out about JavaScript, when did you figure out that you want to teach JavaScript? What was that transition like?

+ +

KENT: I've been teaching for my whole life. It's ingrained in my religion. Even as a kid, you know, I'd prepare a talk, a five-minute talk, and stand up in front of 30 of my peers. And even when you're an early teenager, you get into speaking in front of the entire congregation. It took a while before I got good enough at something, enough hubris to think that people would care about what I have to say --

+ +

WILL: [laughs]

+ +

KENT: Outside of my religion where, like, they're sitting there, and I've been asked to speak, and so they're going to listen to me. And so, when I started getting pretty good at programming, I decided, hey, I want to teach this stuff that I'm learning. And so, when I was still at school and working at Domo, the business intelligence company, one of our co-workers, Dave Geddes, he put together a workshop to teach AngularJS because we were migrating from Backbone to Angular. And I asked him if I could use his workshop material to teach my classmates.

+ +

This was, like, soon after ng-conf, the first ng-conf, which my co-workers at Domo actually put on. So, I wasn't involved in the organization, but I was very much present when it was being organized. I attended there and developed a relationship with Firebase with the people there. I was actually...they had a developer evangelist program, which they called Torchbearers or something. And actually, that was my idea to call them Torchbearers. I think they wanted to call us torches, and I'm like, that just doesn't make sense.

+ +

WILL: [laughs]

+ +

KENT: I developed a relationship with them. And I asked them, "Hey, I want to teach my classmates AngularJS. Would you be interested in sponsoring some pizza and stuff?" And they said, "Yeah, we'll send you stickers, and hot sauce, and [laughs] a bunch of..." Like, they sent us, like, headphones [laughs] and stuff. So, I was like, sweet. I taught my classmates AngularJS in a workshop, brought a bunch of pizza, and it was, you know, just an extracurricular thing.

+ +

And actually, the recording is still on my YouTube channel, so if you want to go look at one of my early YouTube videos. I was very into publishing video online. So, if you are diligent, you'll be able to find some of my very early [laughter] videos from my teenage years.

+ +

But anyway, so, yes, I've been teaching since the very beginning. As soon as I graduated from college, I started speaking at meetups. I'd never been to a meetup before, and I just saw, oh, they want a speaker. I can talk about something.

+ +

WILL: Wow.

+ +

KENT: And not realizing that, like, meetups are literally always looking for speakers. This wasn't some special occasion.

+ +

WILL: [laughs]

+ +

KENT: And one of the meetups I spoke at was recorded and put on YouTube. And the guy who started Egghead io, John Lindquist, he is local here in Utah. And he saw that I spoke at that meetup, but he wasn't able to attend. So, he watched the recording, and he thought it was pretty good. He thought I would do a good job turning that into a video course. And that first video course paid my mortgage.

+ +

WILL: Wow.

+ +

KENT: And I was blown away. This thing that I had been doing just kind of for fun speaking at meetups, and I realized, oh, I can actually, like, make some legit good money out of this. From there, I just started making more courses on the side after I put the kids to bed. My wife is like, "Hey, I love you, but I want you to stay away for now because I've just been with these tiny babies all day.

+ +

WILL: [laughs]

+ +

KENT: And I just need some alone time."

+ +

WILL: Yes.

+ +

KENT: And so, I was like, okay.

+ +

WILL: [laughs]

+ +

KENT: I'll just go and work on some courses. And so, I spent a lot of time for the next couple of years doing course material on the side. I reached out to Frontend Masters and just told them, "Hey, I've been doing courses for Egghead." I actually met Marc Grabanski at a conference a couple of years before. And so, we established a little bit of relationship. And I just said, "Hey, I want to come and teach there." So, I taught at Frontend Masters. I started putting on my own workshops at conferences.

+ +

In fact, just a few months after graduating, I got accepted to speak at a conference. And only after I was accepted did I realize it was in Sweden [laughter]. I didn't think to look where in the world this conference was. So, that was my first international trip, actually, and I ended up speaking there. I gave, actually, two talks. One of them was a three-hour talk.

+ +

WILL: Whoa.

+ +

KENT: Which was, yeah, that was wild.

+ +

WILL: [laughs]

+ +

KENT: And then, yeah, I gave a two-day workshop for them. And then, I flew straight from there to Amsterdam to give another talk and also do a live in-person podcast, which I'd been running called ngAir, an Angular podcast. It just kept on building from there until finally, I created testingjavascript.com. And that was when I realized, oh, okay, so this isn't just a thing I can use to pay my mortgage, and that's nice. This is, like, a thing I can do full-time. Because I made more with Testing JavaScript than I made from my PayPal salary.

+ +

WILL: Oh wow.

+ +

KENT: I was like, oh, I don't need both of these things. I would rather work half as much one full-time job; that's what I want, one full-time job and make enough to take care of my family. And I prefer teaching. So, that's when I left PayPal was when I released Testing JavaScript.

+ +

WILL: Wow. So, for me, I think so many times the imposter syndrome comes up whenever I want to teach or do things at the level you're saying you're doing. Because I love teaching. I love mentoring. I remember when I came into development, it was hard. I had to find the right person to help me mentor. So now, I almost made a vow to myself that if someone wants to learn and they're willing to put in the energy, I'm going to sit down however long it takes to help them because I remember how hard it was for me whenever I was doing it.

+ +

So, you said in 2014, you were only a couple years doing development. How did you overcome impostor syndrome to stand in front of people, teach, go around the world, and give talks and podcasts? Like, how did you do that portion?

+ +

KENT: Part of it is a certain level of hubris like I said. Like, you just have to be willing to believe that somebody's going to care. You know, the other part of it is, it's a secret to getting really, really good at something. They sometimes will say, like, those who can't do teach. That's total baloney because it requires a lot of being able to do to get you in a position where you can teach effectively. But the process of teaching makes you better at the process of doing as well. It's how you solidify your experience as a whatever. So, if you're a cook, you're really good at that; you will get better by teaching other people how to cook.

+ +

There's an element of selfishness in what I do. I just want to get really, really good at this, and so I'm going to teach people so that I can. So yeah, I think there's got to be also, like, a little bit of thick skin, too, because people are going to maybe not like what you have to share or think that you're posing or whatever. Learn how to let that slide off you a little bit.

+ +

But another thing is, like, as far as that's concerned, just being really honest about what your skill set is. So, if somebody asks me a question about GraphQL, I'm going to tell them, "Well, I did use GraphQL at PayPal, but I was pretty limited. And so, I don't have a lot of experience with that," and then I'll answer their question. And so, like, communicating your limitations of knowledge effectively and being okay being judged by people because they're going to judge you. It just is the way it is. So, you just have to learn how to cope well with that.

+ +

There are definitely some times where I felt like I was in over my head on some subjects or I was involved in a conversation I had no business being there. I actually felt that a lot when I was sent as PayPal's delegate to the TC39 meetings. Wow, what am I doing here? I've only been in the industry for, like, two or three years at [laughter] that point. It takes a certain level of confidence in your own abilities. But also, like, being realistic about your inexperience as well, I think, is important too.

+ +

WILL: Yeah, I know that you had a lot of success, and I want to cover that next. But were there any failures when you were doing those teaching moments?

+ +

KENT: Years ago, Babel was still a new thing that everybody was using to compile their JavaScript with new syntax features down to JavaScript that the browser could run. There was ES Modules that was introduced, and lots of us were doing global window object stuff. And then we moved to, like, defining your dependencies with r.js or RequireJS. And then, there was CommonJS, and Universal Module Definition, and that sort of thing. So, ECMAScript modules were very exciting. Like, people were really interested in that. And so, Babel added support to it. It would compile from the module syntax down to whatever you wanted: CommonJS or...well, I'm pretty sure it could compile to RequireJS, but I compiled it to CommonJS.

+ +

And so, there was a...yeah, I would say it's a bug in Babel at that time, where it would allow you to write your ES modules in a way that was not actually spec-compliant. It was incorrect. So, I would say export default some object, and then in another module, I would say import. And then, I'd select properties off of the object that I exported, that default I exported. That was allowed by Babel, but it is superduper, not how ECMAScript modules work.

+ +

Well, the problem is that I taught, like, a ton of people how to use ECMAScript modules this way. And when I realized that I was mistaken, it was just, like, a knife to the heart because I was, like, I taught so many people this wrong thing. And so, I wrote a blog post about it. I gave a big, long talk titled “More Than You Want to Know About ECMAScript Modules,” where I talk about that with many other things as well. And so, yeah, just trying to do my part to make up for the mistake that I made. So yes, I definitely have had mistakes like that.

+ +

There's also, like, the aspect that technology moves at a rapid pace. And so, I have old things that I would show people how to do, which they still work just as well as they worked back then. But I wouldn't recommend doing it that way because we have better ways now. For some people, the old way to do it is the only way they can do it based on the constraints they have and the tools that they're using and stuff. And so, it's not, like, it's not valuable at all. But it is a struggle to make sure that people understand that, like, this is the way that you do it if you have to do it this way, but, like, we've got better ways.

+ +

WILL: I'm glad you shared that because it helps. And I love how you say it: when I make a mistake, I own up to it and let everyone know, "Hey, I made a mistake. Let's correct it and move on." So, I really like that.

+ +

KENT: Yeah, 100%.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: I want to go back to what you were saying. When you left PayPal, you released Testing JavaScript. How did you come up with the idea to write a Testing JavaScript course? And, two, how long did it take to take off and be successful?

+ +

KENT: That was a pretty special thing, honestly. In 2018, I had put together a bunch of workshops related to testing. There was this conference called Assert(js) that invited me to come, taught them. In the year prior, I went to Midwest JS and taught how to test React. I had this material about testing. I'd gotten into testing just because of open-source stuff. I didn't want to have to manually go through all my stuff again every time I wanted to check for breakages and stuff, so that got me into testing. And whatever I'm into is what I'm going to teach. So, I started teaching that testing.

+ +

And then my friend, Ryan Florence, put together...he separated from Michael Jackson with React Training, and built his own thing called Workshop.me. He asked me to join up with him. And he would, like, put together these workshops for me, and I would just...my job was just to show up and teach. And so, I did that. I have a picture, actually, in this blog post, The 2010s Decade in Review, of me in front of 60 people at a two-day workshop at Trulia in San Francisco.

+ +

WILL: Oh, wow.

+ +

KENT: And this is where I was teaching my testing workshop. Well, what's interesting about that photo is that two weeks before that, I had gotten really frustrated with the tool that everybody uses or used at the time for testing React, and that was Enzyme. And so I was preparing this workshop or working on it. I had already delivered it a number of times, but I was working on it, improving it, as I always do [laughs] when I'm preparing.

+ +

WILL: [laughs]

+ +

KENT: I can never give the same workshop twice, I guess. And I was just so frustrated that Enzyme was so difficult to work with. And, like, I was going to prepare this document that said, "Here are all the things you should never do with Enzyme. Like, Enzyme encourages you to do these things; you should not do these things. And let me explain why." And I just hated that I needed a document like that.

+ +

And so, I tweeted, "I'm seriously starting to think that I should make my own very small testing lib and drop Enzyme entirely. Most of Enzyme's features are not at all useful and many damaging to my test bases. I'd rather have something smaller that encourages better practices." And so, I tweeted that March 15th, 2018. I did that. I did exactly that.

+ +

What I often do in my workshops is I try to build the abstraction that we're going to use so that you can use it better. So, I was, like, building Enzyme, and I realized the jump between what I had built, the little utilities that I had built as part of the workshop, from that to Enzyme was just a huge leap. And so, I thought, you know what? These utilities that I have built to teach Enzyme are actually really good. What if I just turned that into a testing utility? And that became Testing Library, which, fast forward to today, is the number one testing library for React. And it's recommended for testing React, and Vue, and Angular.

+ +

The ideas that are in Testing Library got adopted by Playwright. If you're writing tests for anything in the browser, you are very likely using something that was either originally developed by me or inspired by the work that I did. And it all came from that testing workshop that I was working on. So, with that, I had not only that testing workshop; I had a number of other workshops around testing.

+ +

And so I approached Joel Hooks from Egghead.io. I say, "Hey, I'm getting ready to record a bunch of Egghead courses. I've got, like, six or seven courses I want to do." And he'd seen my work before, you know, I was a very productive course creator. And he said, "Hey, how about we, you know, we've been thinking about doing this special thing. How about we make a website just dedicated to your courses?" And I said, "That sounds great."

+ +

I was a little bit apprehensive because I knew that putting stuff on Egghead meant that I had, like, a built-in audience and everything that was on Egghead, so this would be really the first time of me just branching out with video material on my own. Because, otherwise, if it wasn't Egghead, it was Frontend Masters, and there was the built-in audience there. But yeah, we decided to go for it. And we released it in, I think, November.

+ +

And it was that first week...which is always when you make the most is during the launch period. But that launch week, I made more than my PayPal salary for the entire year. And so, that was when I realized, oh, yeah, okay, let's go full-time on this because I don't need two PayPal salaries. I just need one. And then I can spend more time with my family and stuff. And especially as the kids are getting older, they're staying up later, and I want to hang out with them instead of with my computer at night [laughter], and so...

+ +

WILL: I love how you explain that because I came in around 2018, 2019. And I remember Enzyme, and it was so confusing, so hard to work with, especially for, you know, a junior dev that's just trying to figure it out. And I remember Testing JavaScript and then using that library, and it was just so much easier to, like, grab whatever you needed to grab. Those utils made the biggest difference, and still today, they make a huge difference. So yes, I just resonate with what you're saying. That's amazing.

+ +

KENT: Aw, thank you so much.

+ +

WILL: Yeah. You did Testing JavaScript. And then what was your next course that you did?

+ +

KENT: I quit PayPal, go full-time teaching. That first year, I actually did an update to Testing JavaScript. There were a couple of changes in Testing Library and other things that I needed to update it for. And then I started working on Epic React. So, while I was doing all this testing stuff, I was also very into React, creating a bunch of workshops around that. I was invited to speak all over the world to talk about React. And I had a couple of workshops already for React. So, I was invited to give workshops at these conferences about React.

+ +

And so, I thought, you know, let's do this again, and we'll do it with React this time. The other thing was, I'd never really planned on being the testing guy. It just kind of happened, and I actually didn't really like it either. I wanted to be more broad than just testing. So, that kind of motivated me to say, hey, let's do something with React to be a little bit more broad.

+ +

Yeah, so I worked on putting those workshops together and delivered them remotely. And then, yeah, COVID hit, and just really messed everything up [laughs] really bad. So, I had everything done on my end for Epic React by March of 2020, which is, like, immediately after COVID got started, in the U.S. at least. And so, yeah, then we actually didn't end up releasing Epic React until October that year, which, honestly [laughs], was a little bit frustrating for me because I was like, "Hey, guys, I have recorded all the videos and everything. Can we get this released?" But, like, that just was a really rough year for everybody.

+ +

But yeah, so Egghead got the site put together. I did a bunch of interviews and stuff. And then we launched in October of 2020. That was way bigger than Testing JavaScript because Testing JavaScript was still very informed by my experience as an Egghead instructor, which, typically, the Egghead courses are, like, a video where watch me do this thing, and then you'll learn something and go apply it to your own stuff. And that's kind of what Testing JavaScript was built as.

+ +

But as part of the update of Testing JavaScript in 2019, I added another workshop module called Testing Node Applications. And in that one, I decided, hey, typically, I would have a workshop version of my material and a course version. The workshop version had like instructions and exercises. And the course version was no instructions or anything. It was just, like, watch these videos. And it was just me doing the exercises.

+ +

And with the update of Testing JavaScript, I added that Testing Node workshop, and I said, hey, what if we just, like, embrace the fact that these are exercises, and it's just, like, me recording the workshop? How I would deliver the workshop? And so, I tested that out, and that went really well. And so, I doubled down on that with Epic React. And I said, okay, now, this isn't just, like, watch these videos. This is a do the exercise and then watch me do the exercise.

+ +

So, Epic React was not only a lot more material but the format of the material was more geared for retention and true practice and learning. And so, Epic React ended up doing much better than Testing JavaScript, and even still, is still doing a remarkable job as far as course material is concerned. And, like, so many people are getting a lot of really great knowledge from Epic React. So yeah, very gratifying to have that.

+ +

WILL: Once again, I've used Epic React. It's taught me so many...stretched me. And I do like the format, so yes, I totally agree with that, yeah. The next thing, Remix, correct?

+ +

KENT: Yeah. So, how I got into Remix, around the same time we finished recording Epic React videos, I was doing some other stuff kind of to keep content going and stuff while we were waiting to launch Epic React. And around that same time, my friend Ryan Florence and Michael Jackson––they were doing the React training thing. And so, we were technically competitors. Like I said, Ryan and I kind of joined forces temporarily for his Workshop Me thing, but that didn't end up working out very well. And Michael really wanted Ryan back, and so they got back together.

+ +

And their React training business went way better than it had before. They were hiring people and all sorts of stuff. And then, a training business that focuses on in-person training just doesn't do very well when COVID comes around. And so, they ended up having to lay off everybody and tried to figure out, okay, now what are we going to do? Our income has gone overnight. This is a bit of a simplification. But they decided to build software and get paid for it like one does.

+ +

So, they started building Remix. Ryan, actually, around that time, moved back to Utah. He and I would hang out sometimes, and he would share what he was working on with Michael. We would do, like, Zoom calls and stuff, too. I just got really excited about what they were working on. I could see the foundation was really solid, and I thought it was awesome. But I was still working on Epic React.

+ +

I end up launching Epic React. He launches Remix the very next month as a developer preview thing. Yeah, it definitely...it looked a lot like current Remix in some ways but very, very different in lots of others. But I was super hooked on that. And so, I paid for the developer preview and started developing my website with it. And around the next year in August, I was getting close to finishing my website.

+ +

My website is, like, pretty legit. If you haven't gone to kentcdodds.com. Yet, it is cooler than you think it is. There's a lot that goes into that website. So, I had a team help me with the product planning and getting illustrations and had somebody help me implement the designs and all that stuff. It was a pretty big project.

+ +

And then, by August of 2021, Ryan and I were talking, and I said, "Hey, listen, I want to update Epic React to use Remix because I just think that is the best way to build React applications. But I have this little problem where Remix is a paid framework. That's just going to really reduce the number of people who are interested in learning what I have to teach. And on top of that, like, it just makes it difficult for people to test things out." And so, he, around that time, was like, "Hey, just hold off a little bit. We've got some announcements."

+ +

And so, I think it was September when they announced that they'd raised VC money and they were going to make Remix open source. That was when Ryan said, "Hey, listen, Kent, I think that it's awesome you want to update Epic React to use Remix. But the problem is that Remix isn't even 1.0 yet. The community is super small. It needs a lot of help. If you release a course on Remix right now, then you're not going to get any attention because, like, nobody even knows what it is."

+ +

So, part of me is like, yeah, that's true. But also, the other part of me is like, how do people find out what it is [laughs] unless there's, like, material about it? But he was right. And he said, "Listen, we've got a bunch of VC money. I've always wanted to work with you. How about we just hire you? And you can be a full-time teacher about Remix. But you don't have to charge anything. You just, like, make a bunch of stuff for free about Remix." I said, "That sounds great. But, you know, to make that worth my while because I'm really happy with what I'm doing with this teaching thing, like, I'm going to need a lot of Remix."

+ +

And so, Michael Jackson was like, "How about we just make you a co-founder, and we give you a lot of Remix?" And I said, "Okay, let's do this." And so I jumped on board with them as a year-delayed co-founder. I guess that's pretty common. But, like, that felt kind of weird to me [laughs] to be called a co-founder. But yeah, so I joined up with them.

+ +

I worked on documentation a little bit, mostly community building. I ran Remix Conf. Shopify was interested in what we were doing. And we were interested in what Shopify was doing because, at the time, they were working on Hydrogen, which was one of the early adopters of React Server Components. And, of course, everybody was interested in whether Remix was going to be adding support for server components. And Ryan put together a couple of experiments and found out that server components were nowhere near ready. And we could do better than server components could as of, you know, the time that he wrote the blog posts, like, two years ago.

+ +

So, Hydrogen was working with server components. And I put us in touch with the Hydrogen team—I think it was me—to, like, talk with the Hydrogen team about, like, "Hey, how about instead of spending all this time building your own framework, you just build on top of Remix then you can, you know, make your Shopify starter projects just, like, a really thin layer on top of Remix and people will love it? And this is very important to us because we need to get users, especially really big and high profile users, so people will take us seriously."

+ +

And so, we have this meeting. They fly a bunch of their people out to Salt Lake. They're asking us questions. We're asking them questions and saying, "Hey, listen, this is why server components are just not going to work out for you." Well, apparently, they didn't listen to us. It felt like they were just like, "No, we're highly invested in this. We've already sunk all this cost into this, but we're going to keep going." And they did end up shipping Hydrogen version 1 on top of server components, which I just thought was a big mistake.

+ +

And it wasn't too long after that they came back and said, "Hey, we're kind of interested in having you guys join Shopify." So, right after Remix Conf, I go up into Michael's room at the hotel with Ryan. And they say, "Hey, listen, Kent, we're talking with Shopify about selling Remix and joining Shopify," and kind of bounced back and forth on whether we wanted to do it. All of us were just not sure. Because when I joined Remix, I was thinking, okay, we're going to build something, and it's going to be huge. This is going to be bigger than Vercel, like multibillion-dollar company. So, I really kind of struggled with thinking, hey, we're selling out. Like, we're just getting started here.

+ +

So, Ryan and I ended up at RenderATL in Atlanta at that conference. We were both speaking there. And Ryan didn't fill out the right form. So, he actually didn't have a hotel room [laughs], and so he ended up staying in my room. I intentionally always get a double bedroom just in case somebody needs to stay with me because somebody did that for me once, and I just...it was really nice of them. So, I've always done that since. And so, I said, "Yeah, Ryan, you can stay with me."

+ +

And so, we spent just a ton of time together. And this was all while we were trying to decide what to do with Shopify. And we had a lot of conversations about, like, what do we want for Remix in the future? And it was there that I realized, oh if I want to take this to, like, multi-billion dollar valuation, I've got to do things that I am not at all interested in doing. Like, you've got to build a business that is worth that much money and do business-related things.

+ +

On top of all of that, to get any money out of it...because I just had a percentage of the company, not actually any money. There was no stock. So, the only way you can get money out of a situation like that is if you have a liquidation event like an IPO, which sounds, like, awful—I [laughs] would hate to go through an IP0—or you have to be bought. And if you're worth $2 billion, or 3, or whatever, who can buy you? There's almost nobody who can buy you at that valuation. Do you really want to outprice anybody that could possibly buy you?

+ +

And then, on top of that, to get there, that's, like, a decade worth of your life of working really superduper hard to get to that point, and there's no guarantee. Ryan would always say a bird in the hand is worth two in the bush. He was saying Shopify is a bird in the hand, and we do not know what the future holds. And so, we were all finally convinced that, yeah, we want to sell, and so we decided, yeah, let's sell.

+ +

And as the sale date grew closer, I was getting excited because I was like, oh, I can be back on the TC39 because Shopify is, like, I don't know if they're actually sending delegates to the TC39, but I'm sure that they would be interested if I ask them to, like, "Hey, let's be involved in the evolution of JavaScript." And I know they're on the Web Working Group. Like, they're on a bunch of different committees and stuff. And I just thought it'd be really cool to get involved in the web platform again. And then, on top of that, I just thought, you know what? I'll just spend all my time teaching Shopify developers how to use Remix. That sounds like a lot of fun.

+ +

As things drew closer, I got more and more uneasy about that. And I thought, you know, I could probably do just as well for myself by going full-time teacher again. I've done this thing before. I just really like being a teacher and, like, having total control over everything that I do. And if I work at Shopify, they're going to tell me, "Hey, you need to, like, do this, and that, and the other." And I don't know if I want to go back to that.

+ +

And so, I decided, this is awesome. Super, super good job, folks. I think I've done everything for you that you need me to do. I'm going to bail out. And so, yeah, Shopify wasn't super jazzed about that. But the deal went through anyway. And that's how I ended my time at Shopify.

+ +

WILL: I love it. It's lining up perfectly because you say you left Shopify to go back doing more teaching. And then you released another course; that's Epic Web, correct?

+ +

KENT: Right. That was the reason I left Shopify or I didn't join up with Shopify is because I wanted to work on Epic Web. In this 2010s blog post, one of the last things that I mention...toward the bottom, there's a section, KCD EDU, which is basically, like, I wanted to help someone go from zero to my level as an engineer in a single place where I teach just all of the things that I can teach to get somebody there. And so I wanted to call it KCD EDU, but I guess you have to be an accredited university to get that domain or something. But that was the idea.

+ +

Erin Fox, back in 2020 she said, "I'm expecting you to announce your online Kent C. Dodds engineering bootcamp." And I replied, "I'm planning on doing this, no joke." So, I've been wanting to do this for a really long time. And so, leaving Remix was like, yeah, this is what I'm going to go do. I'm going to go build KCD EDU.

+ +

And I was talking with Ryan at some point about, like, what I was planning on doing in the future. And something he said or something I said in that conversation made me realize, oh, shoot, I want to build Epic Web Dev. So, I've got Epic React. I don't want Epic Remix. I want people to, like, be web developers. Remix is just, like, an implementation detail. And so, I went and I was relieved to find that the domain was still available: epicweb.dev, and so I bought that. And so, I was always planning on, like, even while I was at Remix, eventually, I would leave Remix and go build Epic Web Dev. So, that's what I did.

+ +

Starting in August, I decided, okay, how about this: I will build a legit real-world web application, and then I will use that to teach people how to build legit real-world web applications from start to finish. If it's included as, like, knowledge you would need to build this web app, then that's knowledge you need to be able to build a full-stack application. That was the idea.

+ +

So, I started live streaming in, like, August or September, and I would live stream almost everyday development of this web app. So, people can go and watch those on my YouTube channel. I would livestream for, like, sometimes six hours at a time with breaks every 45 minutes. So, I'd just put it on a break slide, go for a quick walk, or take a drink, whatever, and then I would come back. And I would just, like, so much development and live streaming for a long time.

+ +

Once I got, like, in a pretty good place with that, the app I was building was called Rocket Rental. It's like Airbnb for rocket ships. So, you could rent, like, your own rocket ship to other people to fly. So, it had to be, like, realistic enough that, like, you could relate it to whatever you were building but not realistic enough that people would actually think it was a real product [laughs].

+ +

I worked with Egghead again. They actually have a sister company now called Skill Recordings that's responsible for these types of products. And so, I was working with Skill Recordings on, like, they would get me designs. And then I would, like, work with other people to help implement some of those designs. And then, I started working on turning this stuff into workshops.

+ +

And with Epic React, we have this workshop app that you run locally so that you can work in your own editor, in your own environment, and with your own editor plugins and all that stuff. I want you to practice the way that you're going to actually exercise that practice when you're done––when you're working at work. And so we have this workshop app with Epic React. Well, that was built with Create React app, very limited on what you could do.

+ +

And so, I started working on a new workshop app that I just called KCD Shop, that was built with Remix. And so, now we've got a bunch of server-side stuff we can do. And this server side is running on your machine. And so, so much stuff that I can do with this thing.

+ +

One of the big challenges with Epic React was that the video you watch is on epicreact.dev, but the exercises you run are on localhost. And so, you have to keep those things in sync. You'd see, okay, I'm in exercise one on the videos. Let me go find exercise one in the app and then find the file exercise one. So, you've got, like, three different things you've got to keep in sync.

+ +

And so, with the workshop app for Epic Web, I said, how about we make it so that we can embed the video into the app? And so, you just have localhost running, and you see the video right above the instructions for the exercise. And so, you watch the video that kind of introduces the problem that you're going to be doing, and then you read the instructions. And then we can also make it so that we have links you can click or buttons you can click in the app that will open your editor exactly where you're supposed to go.

+ +

So you don't have to keep anything in sync. You go to the app, and you watch the video. You read the instructions. You click this button. It opens your editor. And so, that's exactly what I did. And it's an amazing experience. It is phenomenal, not just for the workshop learners but for me, as a workshop developer, like, creating the workshop––it's just been phenomenal. Because, like, we also have this diff view where you can see the difference between your work in progress and the solution. So, if you get stuck, then it's very easy to see where you went wrong.

+ +

It also means that we can build even very large applications as part of our workshop and our exercise where there are dozens or hundreds of files. And you don't have to worry about finding them because it'll tell you exactly which ones you need to be working in, so all sorts of really, really cool things. So, this workshop app––actually, took a lot of time and effort to build. But now that it's done, like, people are going through it now, and they're just loving it.

+ +

So, I built the workshop app, I put the first workshop of Rocket Rental into this workshop app, and I delivered it. And I found out very quickly that a full application with all the bells and whistles you'd expect, like, tons of different routes and stuff, was just too much. Even with the workshop app, it was just really pretty difficult for people to gain enough context around what they were building to be effective. So, I was concerned about that.

+ +

But then, around the same time, I started realizing that I had a marketing problem. And that is that with Testing JavaScript, people know that they're customers because they're like, I'm a JavaScript developer, and I know how to test––boom. I'm a Testing JavaScript customer. With Epic React, I join this company; they're using React; I need to know React, boom. I'm a customer of Epic React.

+ +

But with something like Epic Web, it's just so broad that, like, yeah, I am a web developer. I just don't know if I'm a customer to Epic Web. Like, is Epic Web for only really advanced people, or is it only for really beginner people? Or is it only for people who are using this set of tools or... Like, it's just a very difficult thing to, like, identify with. And so I wanted to de-emphasize the fact that we used Remix because the fact is that you can walk away from this material and work in a Next.js app or a SvelteKit app and still use so much of the knowledge that you gained in that environment.

+ +

So, I didn't want to focus on the fact that we're using any particular set of tools because the tools themselves I select them, not only because I think that they are really great tools but also because the knowledge you gain from these tools is very transferable. And I'm going to teach it in a way that's very transferable. That was the plan.

+ +

But I still had this issue, like, I need people to be able to identify themselves as customers of this thing. So, what I decided to do through some, like, hints and inspiration from other people was how about I turn Rocket Rental into a much simpler app and make that a project starter? And while I was at Remix, actually, I directed the creation of this feature called Remix Stacks. It's basically the CLI allows you to create a Remix app based on a template. I said I can make a Remix Stack out of this, and I called it the Epic Stack.

+ +

And so, just took all of the concepts that came from Rocket Rental; applied it to a much simpler app. It's just a note-taking app, but it has, like, all of the features that you would need to build in a typical application. So, it's got a database. It's got deployment, GitHub integration. So, you have GitHub Actions to run tests and stuff. It has the tests. It has authentication already implemented, and even two-factor auth, and third-party auth, and file upload, and, like, just tons and tons of stuff built in. And so, people can start a new project and ship that and have a lot of success, like, skip all the basic stuff.

+ +

So, I presented that at Remix Conf. I wasn't working at Remix anymore, but they asked me to run Remix Conf again, so I did. And I told them, "If I'm running it this year, I'm going to select myself to speak." And I spoke and introduced the Epic Stack there. And then that was when I started to create the workshops based on the Epic Stack.

+ +

And so, now it was no longer we're going to have workshops to build Rocket Rental; it was we're going to have workshops to build the Epic Stack, with the idea being that if you build the thing, you are able to use it better, like, still following the same pattern I did with Testing JavaScript where we build a framework first. Like, before you start using Jest, we're building Jest and same with Testing Library. We do the same thing with React. Before we bring in React, I teach you how to create DOM nodes yourself and render those to the page and all of that.

+ +

And so, here with Epic Web, I'm going to teach you how to build the framework that you can use to build applications. So, that is what Epic Web is, it's effectively we're building the Epic Stack. In the process, you learn all about really basic things, like, how do you get styles onto the page all the way to really complex things like, how do you validate a user's email? Or how do you implement two-factor auth? Or how do you create a test database? So, you don't have to mock out the database, but you can still run your test in isolation.

+ +

Around this time was when my wife and I were trying to become pregnant. And we got the news that we were expecting, and we were super excited. And so, I'm thinking, okay, I've got to ship this thing before the baby comes. Because who knows what happens after this baby comes? So, I am talking with Skill Recordings. I'm saying, "We've got to get this done by October." I think it was May.

+ +

And so, I was thinking like, okay, I've probably got, like, maybe eight days worth of workshops here. And so, kind of outlined all of the workshops. Like, I know what needs to be included. I know what the end looks like because I've got the Epic Stack. The end is the Epic Stack. The beginning is, like, a brand new create Remix app creation right there. So, I know what the start and the end looks like. I kind of can figure out how much time I need to teach all of that. And I said, "Let's do eight days."

+ +

And so, we got that scheduled and started selling tickets. And we sold out 30 tickets in just a couple of days, and that's what we originally planned for. I'm like, well, gosh, I can handle 80 people in a workshop. I've done that before, but that's about as far as I go. I don't really like going that much. In fact, online, especially, I only like to go up to, like, 40. But we said, "Hey, let's knock this out of the park." So, we doubled it, and we sold another 30 seats. And so, it was sold out before even the early bird sale was over. So, that was pretty encouraging.

+ +

The problem was that I hadn't actually developed this material. I'd already given one workshop about testing with Rocket Rental, and I'd given one workshop about the fundamentals with Rocket Rental. But I hadn't done anything of the authentication or, the forms, or data modeling. Also, like, Epic Notes app is different from Rocket Rental. So, I got to rebuild those workshops.

+ +

Like, the first workshop was going to start in, like, two weeks, maybe three weeks. And so, I'm working on these workshops. And I'm like, I've finished the first workshop, which was going to be a two-day workshop, and so I get that done. And so, that next week, I'm getting close to finished on the forms workshop, and then I start the workshops.

+ +

And that was when I started to realize, oh, shoot, I am in huge trouble because I have to not only deliver two workshops a week, so that's two days a week that I'm not able to work on the workshops, really. And then also develop the material as I go, which I don't normally do this at all because I just don't like stressing myself out so much. But, like, I'd had this timeline put together, and I'm like, I need to ship this by October.

+ +

For about five weeks, I worked 80 to 100 hours a week, maybe more, in a row to get those workshops created [laughs]. And I do not recommend this, and I will never do it again. I can tell you this now. I didn't tell anybody at the time because I was worried that people would think, well, geez, is that the type of product you create, like, you're just rushing through this stuff?

+ +

But I can tell you this safely now because the results speak for themselves. Like, these people loved this stuff. They ate it up. It was so good. I won't do this again. It's not something that I typically do. But it worked. And, like, I put in a crazy amount of work to make this work. People loved it. And yeah, I'm really, really happy with that.

+ +

The next step, though, so it was eight days' worth of workshops in four weeks. And I realized, as I almost always realize when I'm presenting workshops, that, like, oh my gosh, I have way more material than I have time for. So, by the end of it, when I was all done, I'm pretty sure we've got around 16 days' worth of workshop material, so twice as much as I thought, which is; honestly, I shouldn't be surprised because this is always how it works.

+ +

So, I've got 16 days worth of workshops to record starting in August that needed to get all recorded six weeks before the launch date, which was my birthday. So, I have until, like, the first part of September to get all this stuff recorded. That is a lot to get recorded, but I managed to do that. So, in about four weeks, I recorded 450 videos. Like, anybody go through this material, and you'll be blown away that I was able to do this. So, I'm patting myself on the back, I know. I probably sound super cocky, but I nailed it. And it is so good.

+ +

I can credit a lot of my ability to record and get those videos produced, first, to the fact that I wasn't editing the videos. I would export the videos, and an editor would take care of editing it for me. And then, secondly, that I've done this for so long. I've just been creating workshops for a long time. I'm just really practiced at teaching while I'm typing and talking and everything. And then, also, just the level of preparation that I put into this workshop material. It was just a very well-oiled machine by this point. So, it ended up working out super-duper well.

+ +

So, I get the videos done. I'm recording a bunch of expert interviews with 25 people during the month of September. Then we launched on my birthday, October 18th. And it went superduper well.

+ +

WILL: Wow. That's a lot of video recording and a lot of stuff you have to do. I feel like that's most parents when they're trying to meet a deadline for a kid that you don't know when they're coming. It's like, oh, I got to do this. I got to do that before the baby comes. So, you did it. You were successful with that [laughter].

+ +

KENT: Yeah, thank you.

+ +

WILL: Wow, who is this course for?

+ +

KENT: The course is for anybody who wants to learn how to build web applications the way I do. I like to focus my building of web applications on the primitives of the web platform as much as possible while acknowledging the practicality of using a framework.

+ +

If you want to be able to ship really awesome user experiences on the web platform, regardless of whether you're using the same tools I am, like, if you're not using Prisma, if you're not using Tailwind, if you're not using Remix, you're still going to walk away from this with a lot of really, really practical material. Because I don't really focus on the tools as much as I do on the patterns and the practical application of security practices and various things of that nature. So, anybody who wants to be really good at the web will benefit a lot from Epic Web.

+ +

WILL: Okay. And I'll put this in the show notes, but they can find it at epicweb.dev?

+ +

KENT: Mm-hmm.

+ +

WILL: Perfect. Okay. Is there anything else that you want to talk about around epicweb.dev?

+ +

KENT: I'll just reiterate that, like, your learning experience on epicweb.dev will be different from anything you've ever seen before. It will be a little bit similar to Epic React if you've done that before. But even still, the new workshop app is unreal, and people are loving it.

+ +

One feature that I really love about it is we try to make it so that you don't feel like you're learning alone because we learn better when we're learning together, and we feel like we're not alone. So, we have a presence feature on Epic Web. So, when you're working through the workshops, you can see all the other people that are currently working on the workshops as well. Of course, you can opt out of this if you don't want your face on there, but, like, it's just, like, a little pile of faces of people who are working on it. And it says where they're working right now. And it's just really, really cool to be able to have that camaraderie.

+ +

So, it's really geared toward retention. So, this is nothing like a Udemy course that is, like, a 45-hour thing that you just sit and watch. This is very hands-on. You will remember this stuff, and you will become a better developer when you're done.

+ +

WILL: Wow, wow. I love that I have not gotten the course, but I'm definitely looking into it. You've talked me into it. I'm going to go and try to try it out. So yes.

+ +

KENT: Cool.

+ +

WILL: Well, I want to close out on a couple of things that I saw. And it was just interesting hearing your story. Like, early on, you were talking about your purpose and kind of the things that you love. One thing that I picked up on is, like, you're saying that you love audio and video programming and teaching. It's amazing that that's essentially what you're doing now.

+ +

KENT: [laughs]

+ +

WILL: Like, that's what you're in right now. You're in teaching with audio and video, and you're teaching programming.

+ +

KENT: Hmm. Yeah, it is kind of funny how it, like, comes full circle.

+ +

WILL: Yeah, so I really love that. And then I have this thing, whenever I think something, especially positive, I try to tell people. I hate to not share what I'm thinking, especially when it's positive because I feel like if it's negative, we just do it so freely, but we never do the positive.

+ +

So, I think, for you, I want to just tell you you had a couple of things you were saying, like your purpose when writing software is the people. You want to teach people how to write awesome software to make the world a better place, and I just want you to know I know, for me, you've done that. You've helped me so much on my journey of coding and development. And I just really appreciate you and what you've done for the space. And I just want to say thank you.

+ +

KENT: Aw, Will, thank you. That does mean a lot to me. So, I really appreciate you saying that.

+ +

WILL: Yeah, awesome. Well, it was a great conversation. I loved learning more about you and just everything you shared. So, thank you for being a part of the podcast.

+ +

KENT: Thank you.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Kent C. Dodds.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching.

+ +

Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community.

+ +

An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course.

+ +

This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Kent C. Dodds. Kent is a JavaScript engineer and teacher. He has recently released a massive workshop called epicweb.dev. And he is the father of four kids. Kent, thank you for joining me.

+ +

KENT: Thank you so much for having me. It's an honor to be here.

+ +

WILL: Yeah. And it's an honor for me to have you. I am a huge fan. I think you're the one that taught me how to write tests and the importance of it. So, I'm excited to talk to you and just pick your brain and learn more about you.

+ +

KENT: Oh, thank you.

+ +

WILL: Yeah. So, I just want to start off just: who is Kent? What do you like to do? Tell us about your family, your hobbies, and things like that.

+ +

KENT: Yeah, sure. So, you mentioned I'm the father of four kids. That is true. We are actually expecting our fifth child any day now. So, we are really excited to have our growing family. And when I'm not developing software or material for people to learn how to develop software, I'm spending time with my family. I do have some other hobbies and things, but I try to share those with my family as much as I can.

+ +

So, it's starting to snow around here in Utah. And so, the mountains are starting to get white, and I look forward to going up there with my family to go skiing and snowboarding this season. During the summertime, I spend a lot of time on my one-wheel just riding around town and bring my kids with me when I can to ride bikes and stuff, too. So, that's sort of the personal side of my life.

+ +

And then, professionally, I have been in this industry developing for the web professionally for over a decade. Yeah, web development has just worked out super well for me. I kind of focused in on JavaScript primarily. And when I graduated with a master's degree in Information Systems at Brigham Young University, I started working in the industry.

+ +

I bounced around to a couple of different companies, most of them you don't know, but you'd probably be familiar with PayPal. I was there for a couple of years and then decided to go full-time on teaching, which I had been doing as, like, a part-time thing, or, like, on the side all those years. And yeah, when teaching was able to sustain my family's needs, then I just switched full-time. So, that was a couple of years ago that I did that. I think like, 2018 is when I did that.

+ +

I took a 10-month break to help Remix get off the ground, the Remix web framework. They got acquired by Shopify. And so, I went back to full-time teaching, not that I don't like Shopify, but I felt like my work was done, and I could go back to teaching. So, that's what I'm doing now, full-time teacher.

+ +

WILL: Wow. Yes, I definitely have questions around that.

+ +

KENT: [laughs] Okay.

+ +

WILL: So many. But I want to start back...you were saying you have four kids. What are their ages?

+ +

KENT: Yeah, my oldest is 11, youngest right now is 6, and then we'll have our fifth one. So, all four of the kids are pretty close in age. And then my wife and I thought we were done. And then last December, we kind of decided, you know what? I don't think we're done. I kind of think we want to do another. So, here we go. We've got a larger gap between my youngest and the next child than we have between my oldest and the youngest child.

+ +

WILL: [chuckles]

+ +

KENT: So, we're, like, starting a new family, or [laughs] something.

+ +

WILL: Yeah [laughs]. I just want to congratulate you on your fifth child. That's amazing.

+ +

KENT: Thank you.

+ +

WILL: Yeah. How are you feeling about that gap?

+ +

KENT: Yeah, we were pretty intentional about having our kids close together because when you do that, they have built-in friends that are always around. And as they grow older, you can do the same sorts of things with them. So, like, earlier this year, we went to Disneyland, and they all had a great time. They're all at the good age for that. And so, they actually will remember things and everything.

+ +

Yeah, we were pretty certain that four is a good number for us and everything. But yeah, we just started getting this nagging feeling we wanted another one. So, like, the fact that there's a big gap was definitely not in the plan. But I know a lot of people have big gaps in their families, and it's just fine. So, we're going to be okay; just it's going to change the dynamic and change some plans for us. But we're just super excited to have this next one.

+ +

WILL: I totally understand what you mean by having them close together. So, I have three little ones, and my oldest and my youngest share the same exact birthday, so they're exactly three years apart.

+ +

KENT: Oh, wow. Yeah, that's actually...that's fun. My current youngest and his next oldest brother are exactly two years apart. They share the same birthday, too [laughs].

+ +

WILL: Wow. You're the first one I've heard that their kids share a birthday.

+ +

KENT: Yeah, I've got a sister who shares a birthday with her son. And I think we've got a couple of birthdays that are shared, but I also have 11 brothers and sisters [laughs]. And so, I have got a big family, lots of opportunity for shared birthdays in my family.

+ +

WILL: Yeah, I was actually going to ask you about that. How was it? I think you're the 11th. So, you're the youngest of 11?

+ +

KENT: I'm the second youngest. So, there are 12 of us total. I'm number 11.

+ +

WILL: Okay, how was that growing up with that many siblings?

+ +

KENT: I loved it. Being one of the youngest I didn't really...my experience was very different from my older siblings. Where my older siblings probably ended up doing a fair bit of babysitting and helping around the house in that way, I was the one being babysat. And so, like, by the time I got to be, like, a preteen, or whatever, lots of my siblings had already moved out. I was already an uncle by the time I was six.

+ +

I vaguely remember all 12 of us being together, but most of my growing up was just every other year; I'd have another sibling move out of the house, which was kind of sad. But they'd always come back and visit. And now I just have an awesome relationship with every one of my family members. And I have something, like, 55 nieces and nephews or more. Yeah, getting all of us together every couple of years for reunions is really a special experience. It's a lot of fun.

+ +

WILL: Yeah. My mom, she had 12 brothers and sisters.

+ +

KENT: Whoa.

+ +

WILL: And I honestly miss it because we used to get together all the time. I used to live a lot closer. Most of them are in Louisiana or around that area, and now I'm in South Florida, so I don't get to see them as often. But yeah, I used to love getting together. I had so many cousins, and we got in so much trouble...and it was --

+ +

KENT: [laughs]

+ +

WILL: We loved it [laughs].

+ +

KENT: Yeah, that's wonderful. I love that.

+ +

WILL: Yeah. Well, I want to start here, like, how did you get your start? Because I know...I was doing some research, and I saw that, at one point, you were an AV tech. You were a computer technician. You even did maintenance. Like, what was the early start of your career like, and how did you get into web dev?

+ +

KENT: I've always been very interested in computers, my interest was largely video games. So, when I was younger, I had a friend who was a computer programmer or, like, would program stuff. We had visions of...I don't know if you're familiar with RuneScape, but it's this game that he used to play, and I would play a little bit. It was just a massive online multiplayer game. And so, we had visions of building one of those and having it just running in the background, making us money, as if that's how that works [laughter]. But he tried to teach me programming, and I just could not get it at all.

+ +

And so I realized at some point that playing video games all the time wasn't the most productive use of my time on computers, and if I wanted my parents to allow me to be on computers, I needed to demonstrate that I could be productive in learning, and making things, and stuff. So, I started blogging and making videos and just, like, music videos.

+ +

My friend, who was the programmer, he was into anime, or anime, as people incorrectly pronounce it. And [laughs] there was this website called amv.com or .org or something. It's Anime Music Videos. And so, we would watch these music videos. And I'd say, "I want to make a music video with Naruto." And so, I would make a bunch of music videos from the Naruto videos I downloaded, and that was a lot of fun. I also ran around with a camera to do that.

+ +

And then, with the blog, I wrote a blog about Google and the stuff that Google was, like, doing because I just thought it was a fascinating company. I always wanted to work at Google. In the process of, like, writing the blog, I got exposed to CSS and HTML, but I really didn't do a whole lot of programming. I also did a little bit of Google Docs. Spreadsheets had some JavaScript macros-type things that you could do. So, I did a little bit of that, but I never really got too far into programming.

+ +

Then I go to college, I'm thinking, you know what? I think I want to be a video editor. I really enjoy that. And so, my brother, who at the time was working at Micron, he did quality assurance on the memory they were making. So, he would build test automation, software and hardware for testing the memory they build. And so, he recommended that I go into electrical engineering. Because what he would say is, "If you understand computers at that foundational level, you can do anything with computers." And I'd say, "Well, I like computers. And if I go into video editing, I'm going to need to understand computers, too. So yeah, sure, let's let's do that."

+ +

I was also kind of interested in 3D animation and stuff like that, too. Like, I wasn't very good at it, but I was kind of interested in that, too. So, I thought, like, having a really good foundation on computers would be a good thing for me. Well, I was only at school for a semester when I took a break to go on a mission for my church [inaudible 09:42] mission. And when I got back and started getting back into things, I took a math refresher course. That was, like, a half a credit. It wasn't really a big thing, but I did terrible in it. I did so bad.

+ +

And it was about that time that I realized, you know what? I've been thinking my whole life that I'm good at math. And just thinking back, I have no idea why or any justification for why I thought I was good at math because in high school, I always struggled with it. I spent so much time with it. And in fact, my senior year, I somehow ended up with a free period of nothing else to do. I don't know how this happened. But, I used that free period to go to an extra edition of my calculus class. So, I was going to twice as much calculus working, like, crazy hard and thinking that I was good at this, and I superduper was not [laughter].

+ +

And so, after getting back from my mission and taking that refresher course, I was like, you know what? Math is a really important part of engineering, and I'm not good at it at all, obviously. And so, I've got to pivot to something else. Well, before my mission, as part of the engineering major, you needed to take some programming classes. So, there was a Java programming class that I took and a computer systems class that included a lot of programming.

+ +

The computer systems was very low level, so we were doing zeros and ones. And I wrote a program in zeros and ones. All that it did was it would take input from the keyboard, and then spit that back out to you as output. That was what it did. But still, you know, many lines of zeros and ones and just, like, still, I can't believe I did that [laughter]. And then we upgraded from that to Assembly, and what a godsend that was [laughs], how wonderful Assembly was after working in machine code. But then we upgraded from that to C, and that's as far as that class went. And then, yeah, my Java class, we did a bunch of stuff.

+ +

And I just remember thinking or really struggling to find any practicality to what we were doing. Like, in the Java class, we were implementing the link to list data structure. And I was like, I do not care about this. This does not make any sense. Why should I care? We were doing these transistor diagrams in the computer systems class. And why do I care about that? I do not care about this at all. Like, this is not an interesting thing for me. So, I was convinced computer programming was definitely not what I wanted to do.

+ +

So, when I'm switching from electrical engineering, I'm thinking, well, what do I do? And my dad convinced me to try accounting. That was his profession. He was a certified public accountant. And so, I said, "Okay, I'll try that." I liked the first class, and so I switched my major to go into the business school for accounting. I needed to take the next accounting class, and I hated that so much. It was just dull and boring. And I'm so glad that I got out of that because [laughs] I can't imagine doing anything like that.

+ +

WILL: [laughs]

+ +

KENT: But as part of switching over to business school, I discovered information systems. What's really cool about that is that we were doing Excel spreadsheets and building web pages. But it was all, like, with a practical application of business and, like, solving business problems. And then, I was like, oh, okay, so I can do stuff with computers in a practical setting, and that's what got me really interested. So, I switched, finally, to information systems–made it into that program. And I was still not convinced I wanted to do programming. I just wanted to work with computers.

+ +

What ended up happening is the same time I got into the information systems program, I got married to my wife, and then I got this part-time job at a company called the More Good Foundation. It's a non-profit organization. And one of my jobs was to rip DVDs and upload those videos to YouTube, and then also download videos from one site and upload those to YouTube as well. And so, I was doing a lot of stuff with YouTube and video stuff.

+ +

And as part of my information systems class, I was taking another Java class. At that same time, I was like, you know, what I'm doing at work is super boring. Like, can you imagine your job is to put in a [inaudible 13:45] and then click a couple of buttons? And, like, it was so boring and error-prone, too. Like, okay, now I've got to type this out and, you know, I got to make sure it's the same, try and copy-paste as much as I can. And it was not fun.

+ +

And so, I thought, well, I'm pretty sure there are pieces of this that I could automate. And so, with the knowledge that I was getting in my information systems programming class, that was another Java class, I decided to write a program that automated a bunch of my stuff. And so, I asked my boss, like, "Can I automate this with writing software?" And I'm so glad that they said I could.

+ +

WILL: [laughs]

+ +

KENT: Because by the end of it, I had built software that allowed me to do way more than I ever could have before. I ended up uploading thousands of videos to their YouTube channels, which would have taken years to do. And they ended up actually being so happy with me. They had me present to the board of directors when they were asking for more money [laughs] and stuff. And it was really awesome. But still, I was not interested in being a programmer. Programming, to me, was just a means to an end.

+ +

WILL: Oh, wow.

+ +

KENT: Yeah, I guess there was just something in me that was like, I am not a programmer. So, anyway, further into the program of information systems, I interned as a business intelligence engineer over that next summer, and I ended up staying on there. And while I was supposed to be a business intelligence engineer, I did learn a lot about SQL, and star schema, and denormalized databases to optimize for read speed and everything. I learned a lot about that. But I just kept finding myself in positions where I would use my programming experience to automate things that were problematic for us in the business realm. And this was all still Java.

+ +

It was there that I finally realized, you know what? I think I actually do want to be a programmer. I actually really do enjoy this. And I like that it's practical, and it makes sense for me, so…

+ +

WILL: What year was that?

+ +

KENT: That would have been 2012. Then I got a new job where my job was actually to be a programmer at a company called Domo, where they do business intelligence, actually. So, it got my foot in the door a little bit since I was a business intelligence engineer already. I got hired on, actually, as a QA engineer doing automated testing, but I never really got into that. And they shifted me over pretty quick into helping with the web app.

+ +

And that is when I discovered JavaScript, and the whole, like, everything flooded out from there. I was like, wow, I thought I liked programming, but I had no idea how fun it could be. Because I felt like the chains had been broken. I no longer have to write Java. I can write JavaScript, and this was just so much better.

+ +

WILL: [laughs]

+ +

KENT: And so, yeah, I was there for a year and a half before I finally graduated. And I took a little break to work at USAA for a summer internship. And when I came back, I had another year and then converted to full-time. And so, yeah, there's my more detail than you were probably looking for, story of how I got into programming [laughs].

+ +

WILL: No, I actually love it because like I said, I've used your software, your teachings, all that. And it's amazing to hear the story of how you got there. Because I feel like a lot of times, we just see the end result, but we don't know the struggle that you went through of even trying to find your way through what your purpose was, what you're trying to do. Because, at one point, you said you were trying to do accounting, then you were trying to do something else. So, it's amazing to see, like, when it clicked for you when you got into JavaScript, so that's amazing.

+ +

KENT: Yeah, it is kind of funny to think, like, some people have the story of, like, I knew I wanted to be a programmer from the very beginning, and it's just kind of funny for me to think back and, like, I was pretty certain I didn't want to be a programmer.

+ +

WILL: [laughs]

+ +

KENT: Like, not only did I, like, lots of people will say, "I never really thought about it, and then I saw it, and it was great." But I had thought about it. And I saw it, and I thought it was awful [laughter]. And so, yeah, I'm really glad that it worked out the way it did, though, because programming has just been a really fun thing. Like, I feel so blessed to be doing something that I actually enjoy doing.

+ +

Like so many of our ancestors, they would go to work because they cared about their family and they just wanted to feed their family. I'm so grateful to them for doing that. I am so lucky that I get to go to work to take care of my family, but also, I just love doing it.

+ +

WILL: Yeah, I feel the same way, so yeah, totally agree. After you found out about JavaScript, when did you figure out that you want to teach JavaScript? What was that transition like?

+ +

KENT: I've been teaching for my whole life. It's ingrained in my religion. Even as a kid, you know, I'd prepare a talk, a five-minute talk, and stand up in front of 30 of my peers. And even when you're an early teenager, you get into speaking in front of the entire congregation. It took a while before I got good enough at something, enough hubris to think that people would care about what I have to say --

+ +

WILL: [laughs]

+ +

KENT: Outside of my religion where, like, they're sitting there, and I've been asked to speak, and so they're going to listen to me. And so, when I started getting pretty good at programming, I decided, hey, I want to teach this stuff that I'm learning. And so, when I was still at school and working at Domo, the business intelligence company, one of our co-workers, Dave Geddes, he put together a workshop to teach AngularJS because we were migrating from Backbone to Angular. And I asked him if I could use his workshop material to teach my classmates.

+ +

This was, like, soon after ng-conf, the first ng-conf, which my co-workers at Domo actually put on. So, I wasn't involved in the organization, but I was very much present when it was being organized. I attended there and developed a relationship with Firebase with the people there. I was actually...they had a developer evangelist program, which they called Torchbearers or something. And actually, that was my idea to call them Torchbearers. I think they wanted to call us torches, and I'm like, that just doesn't make sense.

+ +

WILL: [laughs]

+ +

KENT: I developed a relationship with them. And I asked them, "Hey, I want to teach my classmates AngularJS. Would you be interested in sponsoring some pizza and stuff?" And they said, "Yeah, we'll send you stickers, and hot sauce, and [laughs] a bunch of..." Like, they sent us, like, headphones [laughs] and stuff. So, I was like, sweet. I taught my classmates AngularJS in a workshop, brought a bunch of pizza, and it was, you know, just an extracurricular thing.

+ +

And actually, the recording is still on my YouTube channel, so if you want to go look at one of my early YouTube videos. I was very into publishing video online. So, if you are diligent, you'll be able to find some of my very early [laughter] videos from my teenage years.

+ +

But anyway, so, yes, I've been teaching since the very beginning. As soon as I graduated from college, I started speaking at meetups. I'd never been to a meetup before, and I just saw, oh, they want a speaker. I can talk about something.

+ +

WILL: Wow.

+ +

KENT: And not realizing that, like, meetups are literally always looking for speakers. This wasn't some special occasion.

+ +

WILL: [laughs]

+ +

KENT: And one of the meetups I spoke at was recorded and put on YouTube. And the guy who started Egghead io, John Lindquist, he is local here in Utah. And he saw that I spoke at that meetup, but he wasn't able to attend. So, he watched the recording, and he thought it was pretty good. He thought I would do a good job turning that into a video course. And that first video course paid my mortgage.

+ +

WILL: Wow.

+ +

KENT: And I was blown away. This thing that I had been doing just kind of for fun speaking at meetups, and I realized, oh, I can actually, like, make some legit good money out of this. From there, I just started making more courses on the side after I put the kids to bed. My wife is like, "Hey, I love you, but I want you to stay away for now because I've just been with these tiny babies all day.

+ +

WILL: [laughs]

+ +

KENT: And I just need some alone time."

+ +

WILL: Yes.

+ +

KENT: And so, I was like, okay.

+ +

WILL: [laughs]

+ +

KENT: I'll just go and work on some courses. And so, I spent a lot of time for the next couple of years doing course material on the side. I reached out to Frontend Masters and just told them, "Hey, I've been doing courses for Egghead." I actually met Marc Grabanski at a conference a couple of years before. And so, we established a little bit of relationship. And I just said, "Hey, I want to come and teach there." So, I taught at Frontend Masters. I started putting on my own workshops at conferences.

+ +

In fact, just a few months after graduating, I got accepted to speak at a conference. And only after I was accepted did I realize it was in Sweden [laughter]. I didn't think to look where in the world this conference was. So, that was my first international trip, actually, and I ended up speaking there. I gave, actually, two talks. One of them was a three-hour talk.

+ +

WILL: Whoa.

+ +

KENT: Which was, yeah, that was wild.

+ +

WILL: [laughs]

+ +

KENT: And then, yeah, I gave a two-day workshop for them. And then, I flew straight from there to Amsterdam to give another talk and also do a live in-person podcast, which I'd been running called ngAir, an Angular podcast. It just kept on building from there until finally, I created testingjavascript.com. And that was when I realized, oh, okay, so this isn't just a thing I can use to pay my mortgage, and that's nice. This is, like, a thing I can do full-time. Because I made more with Testing JavaScript than I made from my PayPal salary.

+ +

WILL: Oh wow.

+ +

KENT: I was like, oh, I don't need both of these things. I would rather work half as much one full-time job; that's what I want, one full-time job and make enough to take care of my family. And I prefer teaching. So, that's when I left PayPal was when I released Testing JavaScript.

+ +

WILL: Wow. So, for me, I think so many times the imposter syndrome comes up whenever I want to teach or do things at the level you're saying you're doing. Because I love teaching. I love mentoring. I remember when I came into development, it was hard. I had to find the right person to help me mentor. So now, I almost made a vow to myself that if someone wants to learn and they're willing to put in the energy, I'm going to sit down however long it takes to help them because I remember how hard it was for me whenever I was doing it.

+ +

So, you said in 2014, you were only a couple years doing development. How did you overcome impostor syndrome to stand in front of people, teach, go around the world, and give talks and podcasts? Like, how did you do that portion?

+ +

KENT: Part of it is a certain level of hubris like I said. Like, you just have to be willing to believe that somebody's going to care. You know, the other part of it is, it's a secret to getting really, really good at something. They sometimes will say, like, those who can't do teach. That's total baloney because it requires a lot of being able to do to get you in a position where you can teach effectively. But the process of teaching makes you better at the process of doing as well. It's how you solidify your experience as a whatever. So, if you're a cook, you're really good at that; you will get better by teaching other people how to cook.

+ +

There's an element of selfishness in what I do. I just want to get really, really good at this, and so I'm going to teach people so that I can. So yeah, I think there's got to be also, like, a little bit of thick skin, too, because people are going to maybe not like what you have to share or think that you're posing or whatever. Learn how to let that slide off you a little bit.

+ +

But another thing is, like, as far as that's concerned, just being really honest about what your skill set is. So, if somebody asks me a question about GraphQL, I'm going to tell them, "Well, I did use GraphQL at PayPal, but I was pretty limited. And so, I don't have a lot of experience with that," and then I'll answer their question. And so, like, communicating your limitations of knowledge effectively and being okay being judged by people because they're going to judge you. It just is the way it is. So, you just have to learn how to cope well with that.

+ +

There are definitely some times where I felt like I was in over my head on some subjects or I was involved in a conversation I had no business being there. I actually felt that a lot when I was sent as PayPal's delegate to the TC39 meetings. Wow, what am I doing here? I've only been in the industry for, like, two or three years at [laughter] that point. It takes a certain level of confidence in your own abilities. But also, like, being realistic about your inexperience as well, I think, is important too.

+ +

WILL: Yeah, I know that you had a lot of success, and I want to cover that next. But were there any failures when you were doing those teaching moments?

+ +

KENT: Years ago, Babel was still a new thing that everybody was using to compile their JavaScript with new syntax features down to JavaScript that the browser could run. There was ES Modules that was introduced, and lots of us were doing global window object stuff. And then we moved to, like, defining your dependencies with r.js or RequireJS. And then, there was CommonJS, and Universal Module Definition, and that sort of thing. So, ECMAScript modules were very exciting. Like, people were really interested in that. And so, Babel added support to it. It would compile from the module syntax down to whatever you wanted: CommonJS or...well, I'm pretty sure it could compile to RequireJS, but I compiled it to CommonJS.

+ +

And so, there was a...yeah, I would say it's a bug in Babel at that time, where it would allow you to write your ES modules in a way that was not actually spec-compliant. It was incorrect. So, I would say export default some object, and then in another module, I would say import. And then, I'd select properties off of the object that I exported, that default I exported. That was allowed by Babel, but it is superduper, not how ECMAScript modules work.

+ +

Well, the problem is that I taught, like, a ton of people how to use ECMAScript modules this way. And when I realized that I was mistaken, it was just, like, a knife to the heart because I was, like, I taught so many people this wrong thing. And so, I wrote a blog post about it. I gave a big, long talk titled “More Than You Want to Know About ECMAScript Modules,” where I talk about that with many other things as well. And so, yeah, just trying to do my part to make up for the mistake that I made. So yes, I definitely have had mistakes like that.

+ +

There's also, like, the aspect that technology moves at a rapid pace. And so, I have old things that I would show people how to do, which they still work just as well as they worked back then. But I wouldn't recommend doing it that way because we have better ways now. For some people, the old way to do it is the only way they can do it based on the constraints they have and the tools that they're using and stuff. And so, it's not, like, it's not valuable at all. But it is a struggle to make sure that people understand that, like, this is the way that you do it if you have to do it this way, but, like, we've got better ways.

+ +

WILL: I'm glad you shared that because it helps. And I love how you say it: when I make a mistake, I own up to it and let everyone know, "Hey, I made a mistake. Let's correct it and move on." So, I really like that.

+ +

KENT: Yeah, 100%.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: I want to go back to what you were saying. When you left PayPal, you released Testing JavaScript. How did you come up with the idea to write a Testing JavaScript course? And, two, how long did it take to take off and be successful?

+ +

KENT: That was a pretty special thing, honestly. In 2018, I had put together a bunch of workshops related to testing. There was this conference called Assert(js) that invited me to come, taught them. In the year prior, I went to Midwest JS and taught how to test React. I had this material about testing. I'd gotten into testing just because of open-source stuff. I didn't want to have to manually go through all my stuff again every time I wanted to check for breakages and stuff, so that got me into testing. And whatever I'm into is what I'm going to teach. So, I started teaching that testing.

+ +

And then my friend, Ryan Florence, put together...he separated from Michael Jackson with React Training, and built his own thing called Workshop.me. He asked me to join up with him. And he would, like, put together these workshops for me, and I would just...my job was just to show up and teach. And so, I did that. I have a picture, actually, in this blog post, The 2010s Decade in Review, of me in front of 60 people at a two-day workshop at Trulia in San Francisco.

+ +

WILL: Oh, wow.

+ +

KENT: And this is where I was teaching my testing workshop. Well, what's interesting about that photo is that two weeks before that, I had gotten really frustrated with the tool that everybody uses or used at the time for testing React, and that was Enzyme. And so I was preparing this workshop or working on it. I had already delivered it a number of times, but I was working on it, improving it, as I always do [laughs] when I'm preparing.

+ +

WILL: [laughs]

+ +

KENT: I can never give the same workshop twice, I guess. And I was just so frustrated that Enzyme was so difficult to work with. And, like, I was going to prepare this document that said, "Here are all the things you should never do with Enzyme. Like, Enzyme encourages you to do these things; you should not do these things. And let me explain why." And I just hated that I needed a document like that.

+ +

And so, I tweeted, "I'm seriously starting to think that I should make my own very small testing lib and drop Enzyme entirely. Most of Enzyme's features are not at all useful and many damaging to my test bases. I'd rather have something smaller that encourages better practices." And so, I tweeted that March 15th, 2018. I did that. I did exactly that.

+ +

What I often do in my workshops is I try to build the abstraction that we're going to use so that you can use it better. So, I was, like, building Enzyme, and I realized the jump between what I had built, the little utilities that I had built as part of the workshop, from that to Enzyme was just a huge leap. And so, I thought, you know what? These utilities that I have built to teach Enzyme are actually really good. What if I just turned that into a testing utility? And that became Testing Library, which, fast forward to today, is the number one testing library for React. And it's recommended for testing React, and Vue, and Angular.

+ +

The ideas that are in Testing Library got adopted by Playwright. If you're writing tests for anything in the browser, you are very likely using something that was either originally developed by me or inspired by the work that I did. And it all came from that testing workshop that I was working on. So, with that, I had not only that testing workshop; I had a number of other workshops around testing.

+ +

And so I approached Joel Hooks from Egghead.io. I say, "Hey, I'm getting ready to record a bunch of Egghead courses. I've got, like, six or seven courses I want to do." And he'd seen my work before, you know, I was a very productive course creator. And he said, "Hey, how about we, you know, we've been thinking about doing this special thing. How about we make a website just dedicated to your courses?" And I said, "That sounds great."

+ +

I was a little bit apprehensive because I knew that putting stuff on Egghead meant that I had, like, a built-in audience and everything that was on Egghead, so this would be really the first time of me just branching out with video material on my own. Because, otherwise, if it wasn't Egghead, it was Frontend Masters, and there was the built-in audience there. But yeah, we decided to go for it. And we released it in, I think, November.

+ +

And it was that first week...which is always when you make the most is during the launch period. But that launch week, I made more than my PayPal salary for the entire year. And so, that was when I realized, oh, yeah, okay, let's go full-time on this because I don't need two PayPal salaries. I just need one. And then I can spend more time with my family and stuff. And especially as the kids are getting older, they're staying up later, and I want to hang out with them instead of with my computer at night [laughter], and so...

+ +

WILL: I love how you explain that because I came in around 2018, 2019. And I remember Enzyme, and it was so confusing, so hard to work with, especially for, you know, a junior dev that's just trying to figure it out. And I remember Testing JavaScript and then using that library, and it was just so much easier to, like, grab whatever you needed to grab. Those utils made the biggest difference, and still today, they make a huge difference. So yes, I just resonate with what you're saying. That's amazing.

+ +

KENT: Aw, thank you so much.

+ +

WILL: Yeah. You did Testing JavaScript. And then what was your next course that you did?

+ +

KENT: I quit PayPal, go full-time teaching. That first year, I actually did an update to Testing JavaScript. There were a couple of changes in Testing Library and other things that I needed to update it for. And then I started working on Epic React. So, while I was doing all this testing stuff, I was also very into React, creating a bunch of workshops around that. I was invited to speak all over the world to talk about React. And I had a couple of workshops already for React. So, I was invited to give workshops at these conferences about React.

+ +

And so, I thought, you know, let's do this again, and we'll do it with React this time. The other thing was, I'd never really planned on being the testing guy. It just kind of happened, and I actually didn't really like it either. I wanted to be more broad than just testing. So, that kind of motivated me to say, hey, let's do something with React to be a little bit more broad.

+ +

Yeah, so I worked on putting those workshops together and delivered them remotely. And then, yeah, COVID hit, and just really messed everything up [laughs] really bad. So, I had everything done on my end for Epic React by March of 2020, which is, like, immediately after COVID got started, in the U.S. at least. And so, yeah, then we actually didn't end up releasing Epic React until October that year, which, honestly [laughs], was a little bit frustrating for me because I was like, "Hey, guys, I have recorded all the videos and everything. Can we get this released?" But, like, that just was a really rough year for everybody.

+ +

But yeah, so Egghead got the site put together. I did a bunch of interviews and stuff. And then we launched in October of 2020. That was way bigger than Testing JavaScript because Testing JavaScript was still very informed by my experience as an Egghead instructor, which, typically, the Egghead courses are, like, a video where watch me do this thing, and then you'll learn something and go apply it to your own stuff. And that's kind of what Testing JavaScript was built as.

+ +

But as part of the update of Testing JavaScript in 2019, I added another workshop module called Testing Node Applications. And in that one, I decided, hey, typically, I would have a workshop version of my material and a course version. The workshop version had like instructions and exercises. And the course version was no instructions or anything. It was just, like, watch these videos. And it was just me doing the exercises.

+ +

And with the update of Testing JavaScript, I added that Testing Node workshop, and I said, hey, what if we just, like, embrace the fact that these are exercises, and it's just, like, me recording the workshop? How I would deliver the workshop? And so, I tested that out, and that went really well. And so, I doubled down on that with Epic React. And I said, okay, now, this isn't just, like, watch these videos. This is a do the exercise and then watch me do the exercise.

+ +

So, Epic React was not only a lot more material but the format of the material was more geared for retention and true practice and learning. And so, Epic React ended up doing much better than Testing JavaScript, and even still, is still doing a remarkable job as far as course material is concerned. And, like, so many people are getting a lot of really great knowledge from Epic React. So yeah, very gratifying to have that.

+ +

WILL: Once again, I've used Epic React. It's taught me so many...stretched me. And I do like the format, so yes, I totally agree with that, yeah. The next thing, Remix, correct?

+ +

KENT: Yeah. So, how I got into Remix, around the same time we finished recording Epic React videos, I was doing some other stuff kind of to keep content going and stuff while we were waiting to launch Epic React. And around that same time, my friend Ryan Florence and Michael Jackson––they were doing the React training thing. And so, we were technically competitors. Like I said, Ryan and I kind of joined forces temporarily for his Workshop Me thing, but that didn't end up working out very well. And Michael really wanted Ryan back, and so they got back together.

+ +

And their React training business went way better than it had before. They were hiring people and all sorts of stuff. And then, a training business that focuses on in-person training just doesn't do very well when COVID comes around. And so, they ended up having to lay off everybody and tried to figure out, okay, now what are we going to do? Our income has gone overnight. This is a bit of a simplification. But they decided to build software and get paid for it like one does.

+ +

So, they started building Remix. Ryan, actually, around that time, moved back to Utah. He and I would hang out sometimes, and he would share what he was working on with Michael. We would do, like, Zoom calls and stuff, too. I just got really excited about what they were working on. I could see the foundation was really solid, and I thought it was awesome. But I was still working on Epic React.

+ +

I end up launching Epic React. He launches Remix the very next month as a developer preview thing. Yeah, it definitely...it looked a lot like current Remix in some ways but very, very different in lots of others. But I was super hooked on that. And so, I paid for the developer preview and started developing my website with it. And around the next year in August, I was getting close to finishing my website.

+ +

My website is, like, pretty legit. If you haven't gone to kentcdodds.com. Yet, it is cooler than you think it is. There's a lot that goes into that website. So, I had a team help me with the product planning and getting illustrations and had somebody help me implement the designs and all that stuff. It was a pretty big project.

+ +

And then, by August of 2021, Ryan and I were talking, and I said, "Hey, listen, I want to update Epic React to use Remix because I just think that is the best way to build React applications. But I have this little problem where Remix is a paid framework. That's just going to really reduce the number of people who are interested in learning what I have to teach. And on top of that, like, it just makes it difficult for people to test things out." And so, he, around that time, was like, "Hey, just hold off a little bit. We've got some announcements."

+ +

And so, I think it was September when they announced that they'd raised VC money and they were going to make Remix open source. That was when Ryan said, "Hey, listen, Kent, I think that it's awesome you want to update Epic React to use Remix. But the problem is that Remix isn't even 1.0 yet. The community is super small. It needs a lot of help. If you release a course on Remix right now, then you're not going to get any attention because, like, nobody even knows what it is."

+ +

So, part of me is like, yeah, that's true. But also, the other part of me is like, how do people find out what it is [laughs] unless there's, like, material about it? But he was right. And he said, "Listen, we've got a bunch of VC money. I've always wanted to work with you. How about we just hire you? And you can be a full-time teacher about Remix. But you don't have to charge anything. You just, like, make a bunch of stuff for free about Remix." I said, "That sounds great. But, you know, to make that worth my while because I'm really happy with what I'm doing with this teaching thing, like, I'm going to need a lot of Remix."

+ +

And so, Michael Jackson was like, "How about we just make you a co-founder, and we give you a lot of Remix?" And I said, "Okay, let's do this." And so I jumped on board with them as a year-delayed co-founder. I guess that's pretty common. But, like, that felt kind of weird to me [laughs] to be called a co-founder. But yeah, so I joined up with them.

+ +

I worked on documentation a little bit, mostly community building. I ran Remix Conf. Shopify was interested in what we were doing. And we were interested in what Shopify was doing because, at the time, they were working on Hydrogen, which was one of the early adopters of React Server Components. And, of course, everybody was interested in whether Remix was going to be adding support for server components. And Ryan put together a couple of experiments and found out that server components were nowhere near ready. And we could do better than server components could as of, you know, the time that he wrote the blog posts, like, two years ago.

+ +

So, Hydrogen was working with server components. And I put us in touch with the Hydrogen team—I think it was me—to, like, talk with the Hydrogen team about, like, "Hey, how about instead of spending all this time building your own framework, you just build on top of Remix then you can, you know, make your Shopify starter projects just, like, a really thin layer on top of Remix and people will love it? And this is very important to us because we need to get users, especially really big and high profile users, so people will take us seriously."

+ +

And so, we have this meeting. They fly a bunch of their people out to Salt Lake. They're asking us questions. We're asking them questions and saying, "Hey, listen, this is why server components are just not going to work out for you." Well, apparently, they didn't listen to us. It felt like they were just like, "No, we're highly invested in this. We've already sunk all this cost into this, but we're going to keep going." And they did end up shipping Hydrogen version 1 on top of server components, which I just thought was a big mistake.

+ +

And it wasn't too long after that they came back and said, "Hey, we're kind of interested in having you guys join Shopify." So, right after Remix Conf, I go up into Michael's room at the hotel with Ryan. And they say, "Hey, listen, Kent, we're talking with Shopify about selling Remix and joining Shopify," and kind of bounced back and forth on whether we wanted to do it. All of us were just not sure. Because when I joined Remix, I was thinking, okay, we're going to build something, and it's going to be huge. This is going to be bigger than Vercel, like multibillion-dollar company. So, I really kind of struggled with thinking, hey, we're selling out. Like, we're just getting started here.

+ +

So, Ryan and I ended up at RenderATL in Atlanta at that conference. We were both speaking there. And Ryan didn't fill out the right form. So, he actually didn't have a hotel room [laughs], and so he ended up staying in my room. I intentionally always get a double bedroom just in case somebody needs to stay with me because somebody did that for me once, and I just...it was really nice of them. So, I've always done that since. And so, I said, "Yeah, Ryan, you can stay with me."

+ +

And so, we spent just a ton of time together. And this was all while we were trying to decide what to do with Shopify. And we had a lot of conversations about, like, what do we want for Remix in the future? And it was there that I realized, oh if I want to take this to, like, multi-billion dollar valuation, I've got to do things that I am not at all interested in doing. Like, you've got to build a business that is worth that much money and do business-related things.

+ +

On top of all of that, to get any money out of it...because I just had a percentage of the company, not actually any money. There was no stock. So, the only way you can get money out of a situation like that is if you have a liquidation event like an IPO, which sounds, like, awful—I [laughs] would hate to go through an IP0—or you have to be bought. And if you're worth $2 billion, or 3, or whatever, who can buy you? There's almost nobody who can buy you at that valuation. Do you really want to outprice anybody that could possibly buy you?

+ +

And then, on top of that, to get there, that's, like, a decade worth of your life of working really superduper hard to get to that point, and there's no guarantee. Ryan would always say a bird in the hand is worth two in the bush. He was saying Shopify is a bird in the hand, and we do not know what the future holds. And so, we were all finally convinced that, yeah, we want to sell, and so we decided, yeah, let's sell.

+ +

And as the sale date grew closer, I was getting excited because I was like, oh, I can be back on the TC39 because Shopify is, like, I don't know if they're actually sending delegates to the TC39, but I'm sure that they would be interested if I ask them to, like, "Hey, let's be involved in the evolution of JavaScript." And I know they're on the Web Working Group. Like, they're on a bunch of different committees and stuff. And I just thought it'd be really cool to get involved in the web platform again. And then, on top of that, I just thought, you know what? I'll just spend all my time teaching Shopify developers how to use Remix. That sounds like a lot of fun.

+ +

As things drew closer, I got more and more uneasy about that. And I thought, you know, I could probably do just as well for myself by going full-time teacher again. I've done this thing before. I just really like being a teacher and, like, having total control over everything that I do. And if I work at Shopify, they're going to tell me, "Hey, you need to, like, do this, and that, and the other." And I don't know if I want to go back to that.

+ +

And so, I decided, this is awesome. Super, super good job, folks. I think I've done everything for you that you need me to do. I'm going to bail out. And so, yeah, Shopify wasn't super jazzed about that. But the deal went through anyway. And that's how I ended my time at Shopify.

+ +

WILL: I love it. It's lining up perfectly because you say you left Shopify to go back doing more teaching. And then you released another course; that's Epic Web, correct?

+ +

KENT: Right. That was the reason I left Shopify or I didn't join up with Shopify is because I wanted to work on Epic Web. In this 2010s blog post, one of the last things that I mention...toward the bottom, there's a section, KCD EDU, which is basically, like, I wanted to help someone go from zero to my level as an engineer in a single place where I teach just all of the things that I can teach to get somebody there. And so I wanted to call it KCD EDU, but I guess you have to be an accredited university to get that domain or something. But that was the idea.

+ +

Erin Fox, back in 2020 she said, "I'm expecting you to announce your online Kent C. Dodds engineering bootcamp." And I replied, "I'm planning on doing this, no joke." So, I've been wanting to do this for a really long time. And so, leaving Remix was like, yeah, this is what I'm going to go do. I'm going to go build KCD EDU.

+ +

And I was talking with Ryan at some point about, like, what I was planning on doing in the future. And something he said or something I said in that conversation made me realize, oh, shoot, I want to build Epic Web Dev. So, I've got Epic React. I don't want Epic Remix. I want people to, like, be web developers. Remix is just, like, an implementation detail. And so, I went and I was relieved to find that the domain was still available: epicweb.dev, and so I bought that. And so, I was always planning on, like, even while I was at Remix, eventually, I would leave Remix and go build Epic Web Dev. So, that's what I did.

+ +

Starting in August, I decided, okay, how about this: I will build a legit real-world web application, and then I will use that to teach people how to build legit real-world web applications from start to finish. If it's included as, like, knowledge you would need to build this web app, then that's knowledge you need to be able to build a full-stack application. That was the idea.

+ +

So, I started live streaming in, like, August or September, and I would live stream almost everyday development of this web app. So, people can go and watch those on my YouTube channel. I would livestream for, like, sometimes six hours at a time with breaks every 45 minutes. So, I'd just put it on a break slide, go for a quick walk, or take a drink, whatever, and then I would come back. And I would just, like, so much development and live streaming for a long time.

+ +

Once I got, like, in a pretty good place with that, the app I was building was called Rocket Rental. It's like Airbnb for rocket ships. So, you could rent, like, your own rocket ship to other people to fly. So, it had to be, like, realistic enough that, like, you could relate it to whatever you were building but not realistic enough that people would actually think it was a real product [laughs].

+ +

I worked with Egghead again. They actually have a sister company now called Skill Recordings that's responsible for these types of products. And so, I was working with Skill Recordings on, like, they would get me designs. And then I would, like, work with other people to help implement some of those designs. And then, I started working on turning this stuff into workshops.

+ +

And with Epic React, we have this workshop app that you run locally so that you can work in your own editor, in your own environment, and with your own editor plugins and all that stuff. I want you to practice the way that you're going to actually exercise that practice when you're done––when you're working at work. And so we have this workshop app with Epic React. Well, that was built with Create React app, very limited on what you could do.

+ +

And so, I started working on a new workshop app that I just called KCD Shop, that was built with Remix. And so, now we've got a bunch of server-side stuff we can do. And this server side is running on your machine. And so, so much stuff that I can do with this thing.

+ +

One of the big challenges with Epic React was that the video you watch is on epicreact.dev, but the exercises you run are on localhost. And so, you have to keep those things in sync. You'd see, okay, I'm in exercise one on the videos. Let me go find exercise one in the app and then find the file exercise one. So, you've got, like, three different things you've got to keep in sync.

+ +

And so, with the workshop app for Epic Web, I said, how about we make it so that we can embed the video into the app? And so, you just have localhost running, and you see the video right above the instructions for the exercise. And so, you watch the video that kind of introduces the problem that you're going to be doing, and then you read the instructions. And then we can also make it so that we have links you can click or buttons you can click in the app that will open your editor exactly where you're supposed to go.

+ +

So you don't have to keep anything in sync. You go to the app, and you watch the video. You read the instructions. You click this button. It opens your editor. And so, that's exactly what I did. And it's an amazing experience. It is phenomenal, not just for the workshop learners but for me, as a workshop developer, like, creating the workshop––it's just been phenomenal. Because, like, we also have this diff view where you can see the difference between your work in progress and the solution. So, if you get stuck, then it's very easy to see where you went wrong.

+ +

It also means that we can build even very large applications as part of our workshop and our exercise where there are dozens or hundreds of files. And you don't have to worry about finding them because it'll tell you exactly which ones you need to be working in, so all sorts of really, really cool things. So, this workshop app––actually, took a lot of time and effort to build. But now that it's done, like, people are going through it now, and they're just loving it.

+ +

So, I built the workshop app, I put the first workshop of Rocket Rental into this workshop app, and I delivered it. And I found out very quickly that a full application with all the bells and whistles you'd expect, like, tons of different routes and stuff, was just too much. Even with the workshop app, it was just really pretty difficult for people to gain enough context around what they were building to be effective. So, I was concerned about that.

+ +

But then, around the same time, I started realizing that I had a marketing problem. And that is that with Testing JavaScript, people know that they're customers because they're like, I'm a JavaScript developer, and I know how to test––boom. I'm a Testing JavaScript customer. With Epic React, I join this company; they're using React; I need to know React, boom. I'm a customer of Epic React.

+ +

But with something like Epic Web, it's just so broad that, like, yeah, I am a web developer. I just don't know if I'm a customer to Epic Web. Like, is Epic Web for only really advanced people, or is it only for really beginner people? Or is it only for people who are using this set of tools or... Like, it's just a very difficult thing to, like, identify with. And so I wanted to de-emphasize the fact that we used Remix because the fact is that you can walk away from this material and work in a Next.js app or a SvelteKit app and still use so much of the knowledge that you gained in that environment.

+ +

So, I didn't want to focus on the fact that we're using any particular set of tools because the tools themselves I select them, not only because I think that they are really great tools but also because the knowledge you gain from these tools is very transferable. And I'm going to teach it in a way that's very transferable. That was the plan.

+ +

But I still had this issue, like, I need people to be able to identify themselves as customers of this thing. So, what I decided to do through some, like, hints and inspiration from other people was how about I turn Rocket Rental into a much simpler app and make that a project starter? And while I was at Remix, actually, I directed the creation of this feature called Remix Stacks. It's basically the CLI allows you to create a Remix app based on a template. I said I can make a Remix Stack out of this, and I called it the Epic Stack.

+ +

And so, just took all of the concepts that came from Rocket Rental; applied it to a much simpler app. It's just a note-taking app, but it has, like, all of the features that you would need to build in a typical application. So, it's got a database. It's got deployment, GitHub integration. So, you have GitHub Actions to run tests and stuff. It has the tests. It has authentication already implemented, and even two-factor auth, and third-party auth, and file upload, and, like, just tons and tons of stuff built in. And so, people can start a new project and ship that and have a lot of success, like, skip all the basic stuff.

+ +

So, I presented that at Remix Conf. I wasn't working at Remix anymore, but they asked me to run Remix Conf again, so I did. And I told them, "If I'm running it this year, I'm going to select myself to speak." And I spoke and introduced the Epic Stack there. And then that was when I started to create the workshops based on the Epic Stack.

+ +

And so, now it was no longer we're going to have workshops to build Rocket Rental; it was we're going to have workshops to build the Epic Stack, with the idea being that if you build the thing, you are able to use it better, like, still following the same pattern I did with Testing JavaScript where we build a framework first. Like, before you start using Jest, we're building Jest and same with Testing Library. We do the same thing with React. Before we bring in React, I teach you how to create DOM nodes yourself and render those to the page and all of that.

+ +

And so, here with Epic Web, I'm going to teach you how to build the framework that you can use to build applications. So, that is what Epic Web is, it's effectively we're building the Epic Stack. In the process, you learn all about really basic things, like, how do you get styles onto the page all the way to really complex things like, how do you validate a user's email? Or how do you implement two-factor auth? Or how do you create a test database? So, you don't have to mock out the database, but you can still run your test in isolation.

+ +

Around this time was when my wife and I were trying to become pregnant. And we got the news that we were expecting, and we were super excited. And so, I'm thinking, okay, I've got to ship this thing before the baby comes. Because who knows what happens after this baby comes? So, I am talking with Skill Recordings. I'm saying, "We've got to get this done by October." I think it was May.

+ +

And so, I was thinking like, okay, I've probably got, like, maybe eight days worth of workshops here. And so, kind of outlined all of the workshops. Like, I know what needs to be included. I know what the end looks like because I've got the Epic Stack. The end is the Epic Stack. The beginning is, like, a brand new create Remix app creation right there. So, I know what the start and the end looks like. I kind of can figure out how much time I need to teach all of that. And I said, "Let's do eight days."

+ +

And so, we got that scheduled and started selling tickets. And we sold out 30 tickets in just a couple of days, and that's what we originally planned for. I'm like, well, gosh, I can handle 80 people in a workshop. I've done that before, but that's about as far as I go. I don't really like going that much. In fact, online, especially, I only like to go up to, like, 40. But we said, "Hey, let's knock this out of the park." So, we doubled it, and we sold another 30 seats. And so, it was sold out before even the early bird sale was over. So, that was pretty encouraging.

+ +

The problem was that I hadn't actually developed this material. I'd already given one workshop about testing with Rocket Rental, and I'd given one workshop about the fundamentals with Rocket Rental. But I hadn't done anything of the authentication or, the forms, or data modeling. Also, like, Epic Notes app is different from Rocket Rental. So, I got to rebuild those workshops.

+ +

Like, the first workshop was going to start in, like, two weeks, maybe three weeks. And so, I'm working on these workshops. And I'm like, I've finished the first workshop, which was going to be a two-day workshop, and so I get that done. And so, that next week, I'm getting close to finished on the forms workshop, and then I start the workshops.

+ +

And that was when I started to realize, oh, shoot, I am in huge trouble because I have to not only deliver two workshops a week, so that's two days a week that I'm not able to work on the workshops, really. And then also develop the material as I go, which I don't normally do this at all because I just don't like stressing myself out so much. But, like, I'd had this timeline put together, and I'm like, I need to ship this by October.

+ +

For about five weeks, I worked 80 to 100 hours a week, maybe more, in a row to get those workshops created [laughs]. And I do not recommend this, and I will never do it again. I can tell you this now. I didn't tell anybody at the time because I was worried that people would think, well, geez, is that the type of product you create, like, you're just rushing through this stuff?

+ +

But I can tell you this safely now because the results speak for themselves. Like, these people loved this stuff. They ate it up. It was so good. I won't do this again. It's not something that I typically do. But it worked. And, like, I put in a crazy amount of work to make this work. People loved it. And yeah, I'm really, really happy with that.

+ +

The next step, though, so it was eight days' worth of workshops in four weeks. And I realized, as I almost always realize when I'm presenting workshops, that, like, oh my gosh, I have way more material than I have time for. So, by the end of it, when I was all done, I'm pretty sure we've got around 16 days' worth of workshop material, so twice as much as I thought, which is; honestly, I shouldn't be surprised because this is always how it works.

+ +

So, I've got 16 days worth of workshops to record starting in August that needed to get all recorded six weeks before the launch date, which was my birthday. So, I have until, like, the first part of September to get all this stuff recorded. That is a lot to get recorded, but I managed to do that. So, in about four weeks, I recorded 450 videos. Like, anybody go through this material, and you'll be blown away that I was able to do this. So, I'm patting myself on the back, I know. I probably sound super cocky, but I nailed it. And it is so good.

+ +

I can credit a lot of my ability to record and get those videos produced, first, to the fact that I wasn't editing the videos. I would export the videos, and an editor would take care of editing it for me. And then, secondly, that I've done this for so long. I've just been creating workshops for a long time. I'm just really practiced at teaching while I'm typing and talking and everything. And then, also, just the level of preparation that I put into this workshop material. It was just a very well-oiled machine by this point. So, it ended up working out super-duper well.

+ +

So, I get the videos done. I'm recording a bunch of expert interviews with 25 people during the month of September. Then we launched on my birthday, October 18th. And it went superduper well.

+ +

WILL: Wow. That's a lot of video recording and a lot of stuff you have to do. I feel like that's most parents when they're trying to meet a deadline for a kid that you don't know when they're coming. It's like, oh, I got to do this. I got to do that before the baby comes. So, you did it. You were successful with that [laughter].

+ +

KENT: Yeah, thank you.

+ +

WILL: Wow, who is this course for?

+ +

KENT: The course is for anybody who wants to learn how to build web applications the way I do. I like to focus my building of web applications on the primitives of the web platform as much as possible while acknowledging the practicality of using a framework.

+ +

If you want to be able to ship really awesome user experiences on the web platform, regardless of whether you're using the same tools I am, like, if you're not using Prisma, if you're not using Tailwind, if you're not using Remix, you're still going to walk away from this with a lot of really, really practical material. Because I don't really focus on the tools as much as I do on the patterns and the practical application of security practices and various things of that nature. So, anybody who wants to be really good at the web will benefit a lot from Epic Web.

+ +

WILL: Okay. And I'll put this in the show notes, but they can find it at epicweb.dev?

+ +

KENT: Mm-hmm.

+ +

WILL: Perfect. Okay. Is there anything else that you want to talk about around epicweb.dev?

+ +

KENT: I'll just reiterate that, like, your learning experience on epicweb.dev will be different from anything you've ever seen before. It will be a little bit similar to Epic React if you've done that before. But even still, the new workshop app is unreal, and people are loving it.

+ +

One feature that I really love about it is we try to make it so that you don't feel like you're learning alone because we learn better when we're learning together, and we feel like we're not alone. So, we have a presence feature on Epic Web. So, when you're working through the workshops, you can see all the other people that are currently working on the workshops as well. Of course, you can opt out of this if you don't want your face on there, but, like, it's just, like, a little pile of faces of people who are working on it. And it says where they're working right now. And it's just really, really cool to be able to have that camaraderie.

+ +

So, it's really geared toward retention. So, this is nothing like a Udemy course that is, like, a 45-hour thing that you just sit and watch. This is very hands-on. You will remember this stuff, and you will become a better developer when you're done.

+ +

WILL: Wow, wow. I love that I have not gotten the course, but I'm definitely looking into it. You've talked me into it. I'm going to go and try to try it out. So yes.

+ +

KENT: Cool.

+ +

WILL: Well, I want to close out on a couple of things that I saw. And it was just interesting hearing your story. Like, early on, you were talking about your purpose and kind of the things that you love. One thing that I picked up on is, like, you're saying that you love audio and video programming and teaching. It's amazing that that's essentially what you're doing now.

+ +

KENT: [laughs]

+ +

WILL: Like, that's what you're in right now. You're in teaching with audio and video, and you're teaching programming.

+ +

KENT: Hmm. Yeah, it is kind of funny how it, like, comes full circle.

+ +

WILL: Yeah, so I really love that. And then I have this thing, whenever I think something, especially positive, I try to tell people. I hate to not share what I'm thinking, especially when it's positive because I feel like if it's negative, we just do it so freely, but we never do the positive.

+ +

So, I think, for you, I want to just tell you you had a couple of things you were saying, like your purpose when writing software is the people. You want to teach people how to write awesome software to make the world a better place, and I just want you to know I know, for me, you've done that. You've helped me so much on my journey of coding and development. And I just really appreciate you and what you've done for the space. And I just want to say thank you.

+ +

KENT: Aw, Will, thank you. That does mean a lot to me. So, I really appreciate you saying that.

+ +

WILL: Yeah, awesome. Well, it was a great conversation. I loved learning more about you and just everything you shared. So, thank you for being a part of the podcast.

+ +

KENT: Thank you.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Kent C. Dodds.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+F-_IncnK + + ]]> + + Will Larry + Kent C. Dodds + + + thoughtbot's Incubator Program Mini Season 3 - Episode 04: Goodz with Mike Rosenthal and Chris Cerrito + https://podcast.thoughtbot.com/s3e4incubatorgoodz + b8340d6f-ec76-417d-8a20-d257b4e03134 + Tue, 05 Dec 2023 00:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + Startup founders Mike Rosenthal and Chris Cerrito are participating in thoughtbot's eight-week incubator program. Mike, with a background in the music industry, and Chris, experienced in physical computing and exhibit development, are collaborating on a startup that creates physical objects linked to digital content, primarily in music. Their goal is to enhance the connection between tangible and digital experiences, starting with a product that resembles a mixtape, using NFC technology for easy access to digital playlists. + +This project is unique within the thoughtbot incubator as it's the first pure consumer product and involves both physical and digital elements. The team is engaged in user interviews and market validation, with the aim of launching a physical product with a digital backend. They are exploring various marketing strategies for the product and are in the process of building its technical backend. + 25:46 + no + + + If you missed the first episode with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can go here first (https://www.giantrobots.fm/s3e2incubatorgoodz) to catch up! +Startup founders Mike Rosenthal and Chris Cerrito are participating in thoughtbot's eight-week incubator program. Mike, with a background in the music industry, and Chris, experienced in physical computing and exhibit development, are collaborating on a startup that creates physical objects linked to digital content, primarily in music. Their goal is to enhance the connection between tangible and digital experiences, starting with a product that resembles a mixtape, using NFC technology for easy access to digital playlists. +This project is unique within the thoughtbot incubator as it's the first pure consumer product and involves both physical and digital elements. The team is engaged in user interviews and market validation, with the aim of launching a physical product with a digital backend. They are exploring various marketing strategies for the product and are in the process of building its technical backend. +Transcript: +LINDSEY: All right. I'm going to kick us off here. Thanks, everyone, for tuning in. We're doing our first update with two founders that are now going through the Startup incubator at thoughtbot. thoughtbot, if you're not familiar, product design and development consultancy. We'll help you on your product and make your team a success. One of the very fun ways we do that is through the startup thoughtbot incubator, which is an eight-week program. +So, with us today, I myself am Lindsey Christensen, marketing for thoughtbot. We also have Jordyn Bonds, who is our Director of Product Strategy and runs the thoughtbot incubator. And then, as I mentioned, we've got two new founders who are going to tell us a little bit about themselves and what they're working on. Mike Rosenthal, let's kick off with you. Can you tell us a little bit about maybe your background and what brings you to present day? +MIKE: Sure. First of, thanks for having us. It's been a lot of fun doing this over the last [inaudible 01:03]; it's only two weeks, two and a half weeks, something like that. It feels like a lot more. I come from a music industry background, so worked in sort of marketing and strategy for artists for a long time; worked with a band called OK Go back, sort of starting in 2009 or so. +I did a lot of early kind of viral music video stuff. And we were sort of early to the idea of sort of leveraging fan engagement and revenue, honestly, kind of beyond sort of just selling their music and touring, so sort of exploring other ways that artists can make money and connect with their fans and was with those guys for five years. +And then, I went on and worked at an artist management company in Brooklyn called Mick Management and ran the marketing department there, so doing similar type of work but for a roster of 2025 major label bands. And so, really got to see fan engagement on all different levels, from really large bands down to baby bands who were just getting started. And then, yeah, started my first startup in 2018, so doing sort of fan engagement work, and NFTs, and blockchain-type stuff working with bands, but then also sports and entertainment properties. Yeah, that kind of brings me here. +So, always been sort of on the music side of things, which ties into a lot of what Chris and I are working on now, but more generally, sort of fan engagement and how to, you know, drive revenue and engagement for artists and deliver value for fans. +LINDSEY: Very interesting. All right, Chris, going to head over to you. Chris Cerrito, can you tell us a bit about your background? And it sounds like yours and Mike's paths; this isn't the first time you've crossed. +CHRIS: No. Mike and I have been working together since 2007, I believe. Yeah, that's a great place to start. I've always been kind of a maker and a tinkerer, always been interested in art materials, how things are put together. And that kind of culminated at grad school, where Mike and I met at NYU, where we both studied physical computing and human-computer interaction, making weird things that kind of changed the way that people interact and play with technology in their day-to-day lives. +I think the first project he and I worked on together was a solar robotic band that we played with light in front of a bunch of people. It was very wonderful and confusing at the same time. After grad school, I was lucky enough to become a resident artist and then an exhibit developer at a museum in San Francisco called the Exploratorium, which is a museum of science, art, and human perception. +I spent ten years there working on exhibits teaching people things ranging from, let's see, I built a dueling water fountain to teach visitors and users about the prisoner's dilemma. I built a photo booth that used computer vision to teach people about the microbiome that lives on their face, like, just all kinds of weird things like that that fuse the digital and the physical worlds. I loved my time there. +And then kind of COVID hit and I realized that everything I had been working on for ten years was locked up in a museum that I no longer had access to. And it really gave me a desire to kind of bring my ideas into the physical world. I wanted to make things that people interact with and use in their lives on a day-to-day basis. And I would say that's really what brought me here to this point. +LINDSEY: Very cool. Very interesting backgrounds, in my opinion. What is the new idea? What is the thing that you're bringing into the incubator? Mike, I'll start with you. Tell us a bit about what you're working on. +MIKE: Chris and I are working on physical objects that connect to digital content is sort of the broadest way that I could describe it. I think, you know, as Chris kind of mentioned, you know, we've both been working on sort of physical things that have interactivity for a lot of our careers. I think we both come from an era of a lot more physical objects in your life, whether that's, you know, VHS cassettes at your parent's house growing up, or records and tape cassettes, and just sort of physical things that remind you of the things that you love. +And I think that, you know, cell phones are great, and the sort of the smartphone era is amazing and having, you know, every single song, and movie, and television show and podcasts, et cetera, in a black box in my pocket is great. But I think we've sort of gotten to a point where it's more of an organizational problem now than anything else. And we sort of forget the actual things that we love in this world. +And so, we're working on basically making physical objects to tie to digital content, and we're starting with music. And that's what we've been working on at thoughtbot is sort of how we can create physical things that basically you can tap, and that will take you to streaming content. One of the first things we're working on literally looks like sort of a little mixtape on a piece of wood, and you can just load that up with any sort of playlist that you might have on Spotify, or Apple Music, or YouTube, or whatever, and tap it, and it will take you there. +And so, it's just sort of that idea of like, oh, we used to be able to sort of flip through a friend's music collection and judge them ruthlessly, or become even better friends with them based on kind of what you saw there. And we think that the time is ripe for, I don't know, a blend of that nostalgia with actual sort of, like, real-world utility that people could be into this right now. Chris, what am I missing there? +CHRIS: I'd say just to expand on that a little bit, it's, you know, we spend so much time in the digital world, but we still exist in the physical. And a lot of the things, like, you might spend a really long time editing a photo for your parents or making a playlist for a friend, and there's, like, a value there that might not translate because it's digital. It's ephemeral. And I think tying these digital assets to a physical thing makes them special. It gives them, like, a permanent place in your life, something to respect, to hold on to, and maybe even pass down at some point. +LINDSEY: Yeah, and I think before we logged on, we actually had Jordyn and Mike grabbing cassette tapes from the room there and to show us -- +MIKE: [inaudible 06:49] +LINDSEY: What [laughs] was some of their collection and to prove some of the power of these physical –- +MIKE: Nothing, like, just old mixtapes. +LINDSEY: Mementos. +MIKE: Yeah. We were just talking about this on our sync with the thoughtbot crew. They're, like, there's sort of two levels of nostalgia. There's nostalgia for people like us who, yeah, [crosstalk 07:09] mixtapes, right? For people who actually grew up with this stuff and still have it lying around or don't but, like, look at something like that that gives you, like, instant flashbacks, right? You're like, oh my God, I remember scrolling on that little j-card or, like, getting a mixtape for my first, you know, boyfriend or girlfriend, and having it just mean everything. So, there's people for whom that was a thing. +And there's, you know, generations of people for whom that is, like, their only connection to that is, you know, Stranger Things or, like, you know, the mixtape exists in pop culture as a reference. So, there's still, like, a very strong attachment there, but it's not a personal one, right? It's a cultural one. But I think everybody has that connection. So, that's kind of why we're starting with the mixtape, just because I think everyone can kind of relate to that in some way. +LINDSEY: Yeah, no, yeah. When I hear mixtape, it goes immediately to crushes. You make a mixtape for your crush. +CHRIS: Exactly. +LINDSEY: It's a huge, powerful market, powerful. +MIKE: Oh my God, so powerful. I mean, yeah, I don't know anybody -- +LINDSEY: What's more motivating? +MIKE: [laughs] Yeah, exactly. +CHRIS: Or even just I have a really good friend who I don't get to see as often as I'd like. And he and I are constantly sending each other, you know, Spotify links and text messages. And it's great. I love that interaction. But at the same time, you know, I might forget to add that to a playlist, and then it's kind of lost. If I had taken the time to make something and send it to him physically or vice versa, it just becomes so much more special and so much more real. +MIKE: Yeah. I mean, honestly, I first made these...I mean, we can go to this origin if we want. But, like, I literally just went on moo.com, right? The business card company. And they let you upload, you know, 50 different images, and they'll send you all of those as business cards. And so, I literally went on and just made business cards of all the album covers of, like, albums that I loved growing up, right? And their cheapest is this little piece of cardboard. But I had 50 of these, and I'd put them all out on my coffee table, just as something I wanted to have around. +And people kept coming, you know, friends would come over, and you would just have these conversations that I haven't had in 10 or 15 years, right? Because no one's going to come to my house and pick up my phone and look at my Spotify collection. But if these things are all just sitting out, they're like, "Oh shit, you're into that? Like, I haven't thought about that album in 15 years." Or like, "Oh, I didn't know you were into that. I'm, like, a crazy super fan of that artist as well." And all of a sudden, we're having these conversations that we just weren't having. Yeah, there's something there where it's all been nostalgia coupled with the kind of prompting of conversation and connection that we've kind of lost, I think. +CHRIS: And I think just to clarify a little bit on what Mike's saying, is, you know, this mixtape will be our first product launch, and then we're hoping to move into collectibles for artists and labels. So, shortly after we launch this tape, we're hoping to launch some kind of pilot with a label where you will be able to buy a version of this for your favorite music artist at a merch table in a concert, possibly online. Our dream is to have these sitting there on the table with T-shirts, and records, and other things that artists sell so you can express for the artists that you love. This is a way of expressing your fandom. +LINDSEY: Jordyn, heading over to you, this feels like maybe the first consumer product that has gone through the incubator, would you say? Or how do you think about it? +JORDYN: Yeah, if you're a consumer -- +LINDSEY: Or is it different than other types of products? +JORDYN: Yeah, the first incubator project we did with Senga was, I think, what you would call prosumer. So, it was sort of a consumer thing but directed at folks who had kind of freelancing in sort of a business context. It's got a lot of dynamics of the consumer. But this one, for sure, is the first pure consumer play. Though now that I'm thinking about it, you know, AvidFirst had some consumer elements to it, but it was, you know, it was, like, more complex tech [laughs] [inaudible 10:46] totally different thing -- +LINDSEY: But definitely the first of the physical, physical [inaudible 10:52] +JORDYN: Oh, sure, the first of the physical thing. Right. Absolutely. +LINDSEY: Does that change any of, like, the approach of the programming, or it's kind of -- +JORDYN: I mean, no, not fundamentally, though it does add this layer of operations that you don't have with a pure software play. So, we have to be, there is a thing that needs to get shipped to people in the world, and that takes timelines, and it takes -- +LINDSEY: Supply chain. +JORDYN: Yeah, exactly. And Chris is doing most of that stuff. I don't want to, you know, this is not, like, the main focus of our team necessarily, but it intersects, right? So, this isn't the first one of these types of products I've worked on personally in my career. But there's something, like, really, for me, very fulfilling about, like, there's software. There's a big component of software. There's also this physical object that needs to exist in the world. +And partly, what's so compelling about Goodz is that it gives you the promise of a physical, like, the sort of good aspects of a physical product, a thing you can hold in your hand and look at and really connect with in that physical way. But it has this dynamic digital, like, essential quality as well. So, it's very compelling as a product because it sort of marries the things that we like about both the physical world and the digital world, which is partly why the team was really excited about working on it [laughs]. +LINDSEY: Well, that was going to be my next question is, you know, what stood out to you about the Goodz application for the incubator and the interview process that made you and the team feel like this was going to be a great project to work on? +JORDYN: Yeah. So, I think just the team really resonated with the sort of idea in general, and it seemed fun. There was, like, it's a very positive thing, right? It isn't so much about solving problems and pain points. And, sometimes the, you know, when you're very focused on solving problems, it can feel a little doomy because you actually have to, like, immerse yourself in the problems of the people that you're making software for. And sometimes, you start to feel like the world is just full of problems. +What Goodz is doing is sort of it is solving a problem in a sense, but not in that kind of way. It's really, like, a fun upside kind of thing, which I think a lot of the folks on the team were very excited about. But, like, the software component, actually, is very interesting to us from a technological standpoint as well. There's a lot of opportunity here to do interesting things on the backend with an object that's essentially functioning as a bookmark out in the world. What all can you do with that? There's something super compelling and technically interesting about it. +And I think, also, the team was just sort of excited by Chris and Mike, you know, the energy and the kind of background they were bringing to the table was also super interesting. And then, above all else, what I say every time you ask me this question, which is stage fit, y'all, good stage fit. They're right at the beginning. They haven't built the product yet [laughs]. Gotta say it. It's a good stage fit. They know who they're building for broadly but not super specifically. Got a good vision but, like, haven't made that first step with the software. Perfect stage fit for us [laughs]. +LINDSEY: Great. So, Chris, we were talking a bit before about how you two have been collaborators in the past, worked on business ideas before. Why bring this idea into the thoughtbot incubator? What are you hoping to, you know, achieve? +CHRIS: One of the main reasons why we wanted to bring this into the incubator was just for support, momentum, and then, also, I would say validation for our idea. I mean, we came to the incubator with a very, yeah, I would say it was a fairly developed idea that needed to be proved, and we, quite frankly, needed help with that. You know, Mike and I have our own expertises, but we don't know how to do everything. We're more than willing to jump in where we need to go. +But having people with expertise to work with has proven to be incredibly helpful and just having kind of fresh faces to bat ideas around with after he and I have been staring at each other for months now on Zoom calls and meetings. And just, you know, being able to talk about these ideas with fresh faces and new people and get new perspectives has been so very, very helpful. +I think something that's also great from the momentum standpoint is that because there's a time limit to this experience, we've got the time that we have with you guys, and we've been able to set goals that I think are very achievable for things we want to occur in the next couple of months, and it feels like we're going to get there. +And I think by the end of this, I mean, our hope, and I think we're on track, is to have a functioning physical product that we're going to offer to consumers with a digital backend to support it, which is, in my mind, amazing. That'll totally validate this idea and prove if we have something or not. +LINDSEY: I was going to ask if you're open to sharing what those goals specifically are. Is that it? Is it that by the end, you have -- +MIKE: Is that it? Lindsey, that's a lot. +[laughter] +CHRIS: It's a lot. I mean, yeah. I mean, we're going to have a physical object in the world that you can buy via an e-commerce site -- +JORDYN: Sounds like we need Lindsey on the team if Lindsey feels like this is so achievable. [laughter] +CHRIS: Yeah, yeah. Lindsey...yeah. We're in the beginning [crosstalk 15:47] +LINDSEY: I meant, is that the goal? +CHRIS: That is the goal. +LINDSEY: Is that all? +CHRIS: I was going to –- +LINDSEY: Is that all you got? +CHRIS: Mike, do you agree? +MIKE: Yeah. Is that the goal? Yes, that is the goal. I mean, you know, when we sat down with the thoughtbot team kind of week one, you know, they're sort of like, "All right, let's define kind of the experiment." So, we refer to them as experiments, which I think is helpful because, like, what are the experiments that we want to be doing during our time here? And, you know, we talked about it a lot. +And yeah, I think it's, you know, having a physical product out in the world, having a website in which to sell it. But also, it's really, like Chris was saying, it's like, it's market validation, and just making sure we actually have something that people want. It's like, you know, running a startup takes so long and, like [laughs], you know, you'll do it for so many years. It's like bands when people say, like, "Oh, that's an overnight sensation." It's like, you know, that band has been slogging it out in tiny, little venues for four years before you ever heard of them. +It's like, that's what so much of the startup world feels like to me, too. It's like, "Oh, you're just getting started as a startup?" It's like, "Well, we've been working on this forever." And I know how long this can take. And so, I think we want to learn as early as possible, like, is this something people actually want? Because if they don't, like, we'll just go do something else. I don't want to spend years making something that people don't want. +So, I think the biggest goal, for me, is just validation, and then that is sort of how we get there is like, okay, how do we validate this? Cool. Let's identify some, you know, assumptions of personas that we think are people who do actually want this and then try to go sell it to them. And all the implications from that are, okay, well, you need a website where somebody can buy it. You need a physical product that somebody can actually buy. So, all those things sort of come out of that, but, for me, it's like, proving that assumption, is this thing real? Do people actually want this? And everything else is like, okay, how do we prove that? +LINDSEY: Jordyn, what does that look like in these first few weeks here? User interviews, I assume, how are the user interviews going? +JORDYN: Always. Always. So, you know, we kick it off by just, like, doing the exercise where we list everybody who might want this. And the team, you know, it's a fun product. Everybody brought their own assumptions and ideas to the table on that. You know, we had a lot of different scenarios we were imagining. It's super fun getting that stuff out of people's heads, just, like, what are we all thinking? +And then, you know, we get to negotiate, like, okay...I always encourage everyone to think, like, if everyone else on the team was on the moon, you had to make a decision about a market segment to pick; which one would you pick? And then we kind of argue about it in a productive way. It really helps us get at, like, what are the dynamics that we think matter upfront? And then we pick one, or, in this case, we have a few. We have a handful. +And we're running interview projects where we just recruit people to talk about people that meet this persona, talk about a specific problem. We're in the middle of that right now. And it's fun, fantastic. These conversations are super interesting. We're validating a lot of the things that Mike and Chris, you know, walked into this with, but we're learning a bunch of new things as well. +And, like, really, part of the aim there is to validate that there's a hole in the market that we might fill but also to hear the language people are using to describe this stuff. So, when people talk about buying music, merch, you know, making playlists, et cetera, like, what language do they use to talk about that? So that we make sure we're speaking the language that our customer uses to describe this stuff. And we're, you know, we're right in the pocket of doing that, learning stuff all the time. +And it helps us kind of hone the messaging. It helps us know where to go talk to people about it, how to talk about it, but it's, you know, it all kind of fits together. And it's just this, really...the early stages. It's just a bunch of us in a room, a virtual room, in this case, sort of, like, tossing ideas around. But out of it crystallizes this sense of alignment about who this is for, how to talk to them about it, and with a goal. +And, you know, Mike and Chris walked in with the exact right mindset about this, which is, yes, it's experiments. We need to validate it. Let's make sure there's a there-there. If there's a there-there, let's figure out where it is [laughs], like, all those things. And we're running these experiments, and it was really [inaudible 19:36]. We got down to business quite quickly here. It was really great. +LINDSEY: Like you said, it's not necessarily a problem or, you know, the typical framing of a problem. How do you start those user interview questions around this? Do you feel a gap between the physical and the digital sound? [laughter] +JORDYN: No, no. +LINDSEY: It's maybe not it [laughs]. +JORDYN: Yeah, no. Well, I can tell you what our startup questions are. One of them is, tell me about the last time you bought music merch. Go for it, Lindsey. Tell us. +LINDSEY: The last time I bought music merch I went to a Tegan and Sara concert a few weeks ago, and I bought a T-shirt. +JORDYN: Tell me about buying that T-shirt. Why'd you buy it? +LINDSEY: Because I wanted to remember the show and my time with my friends, and I wanted to support the artists. I know that buying merch is the best way to support your favorite touring artists. +JORDYN: So, it's just, you know, we could spend the rest of this time talking [laughter] [crosstalk 20:34], and it would be awesome. So, it's really a lot of things like that. +LINDSEY: Gotcha. +JORDYN: You don't ask, "What problem are you trying to solve by buying this t-shirt?" Right? Like, that's not, you know, but we ask you to tell us a bunch of stories about when you did this recently. You know, and if you make playlists for friends, you know, that's a different persona. But we would have asked, you know, like, "Tell me about the last playlist you made. You know, who did you share it with? You know, what happened after that? What happened after that? What happened after that?" It's a lot of questions like that. And there's just nothing better. People love to tell you what's going on with them. And it's great [laughs]. +LINDSEY: Yeah. As you all have been doing these interviews, Mike and Chris, have you been surprised by anything? Any interesting insights that you're seeing already? +CHRIS: I mean, I haven't done really much in the way of user interviews in the past. This is a really new experience for me. And then we're, obviously, not on the calls because that would be weird and probably intimidating for people. But we're getting lots of highlights from folks who are doing them, you know, in our daily sync. +And I'm surprised at how many, like, really intense, like, playlist nerds we have found even just in, like, the few people we've talked to, like, in the best possible way. Like, people who are like, "I make playlists all the time." Like, you're talking about, like, a vinyl fan or, like, a...Jordyn, what's the story? It's, like, the guy who there was so much out-of-print vinyl that he started a vinyl label just to get the albums in vinyl. [crosstalk 21:56] +JORDYN: Yeah. There were a bunch of releases that he feels really passionately about that were never released on vinyl that he knew would never be released on vinyl. And so, he started a vinyl record label. And we just found this guy [laughter]. +CHRIS: Is that indicative that that's, like, an entire persona we're going to, like, target? Absolutely not. But it's just, like, it's amazing that even just in the few user interviews we've done, that we've found so many very passionate people. And it's sent me down, like, a TikTok rabbit hole of, like, TikTok, like, music nerd influencer-type folks who are posting playlists. +And they, like, hundreds of thousands of likes on these videos that are literally just, like, screen with text on it that you're supposed to, like, pause the video [laughs] and, like, look at, like, the songs that they're recommending. And it's like, who does that? And it was like, these people do that. And it's like, so there are...it's been very encouraging to me, actually. I was worried that we were going to find not as much passion as we had suspected, and I think the opposite has proven to be true. So, it's exciting. +CHRIS: Yeah, I completely agree with Mike. It's been so encouraging. I think, for me, what we're doing is an idea that I'm very excited about and have been very excited about for a long time. But hearing the responses that we're getting makes me confident in the idea, too. That's great. I mean, I think that is everything that a founder needs, you know, is excitement and confidence. +MIKE: Well, and just the whole user interview experience has, like, made a lot of my other conversations sort of I've tried to frame parts of them as user interviews because I'm talking to a lot of, like, label folks now, and artists, merch people. And, you know, I ended up just sort of, like, asking them, I mean, yes, trying to explain the product and work on kind of partnership stuff, but a lot of it is really just geeking out with them. And just, like, hearing their thoughts about, like, what they love about merch because these are people that clearly think about this stuff all the time. So, it's definitely kind of, like, tuned my other conversations into trying to get unbiased feedback. +LINDSEY: Yeah. Everything is a little user interview now. +MIKE: Yeah, exactly. +LINDSEY: Get that angle in there. All right, so some early validation and excitement. That's really cool to hear. Any challenges or, you know, other kinds of learnings early on? Anything that's been invalidated? +MIKE: I don't know that we're there yet. [inaudible 24:02] Chris, I don't know. I'm happy to find that some things are invalidated, but I don't really feel...you know, some of the personas that we decided or maybe just one of the personas we decided to pursue, I think we're having a hard time having those user interviews kind of really bear fruit, but that's helpful, too, actually. I mean, it's like, okay, well, maybe that's not a group that we target. +JORDYN: Yeah. It's about, like [inaudible 24:24]. I encourage folks not to think about this like a 'no, not that,' and instead think of it as like a 'not yet.' And that's, I think, the dynamic here with a couple of the personas we were interested in. It's just been turned into kind of, like, a not yet for reasons that we very quickly figured out, but we'll get there. It's just a matter of figuring out we had some other personas take precedence because they're more sort of red, hot in a way, right? It's just easier to get in contact with these people, or it's, like, clear what they're going for or what they need from the market. +So, you know, we have this whole list, and it was not clear at first who was going to kind of stand out. But we've kind of found some focus there, which means, invariably, that there's things that are falling out of the frame for now, and you're kind of de-prioritizing them. But it really is, like, a we'll get to that [laughs]. We'll eventually get to that. +LINDSEY: Yeah. And part of the process, who's going to rise to the top right now? +JORDYN: Yeah, exactly. +LINDSEY: Do you have anything you can show and tell with us today or not yet? +MIKE: So, Chris has been hard at work on all the physical side of this stuff and going back and forth with our manufacturing partner and all that good stuff. But we have a final version of the mixtape product. +LINDSEY: For when this gets pulled into the podcast, Mike's showing us a physical card. +CHRIS: It's a small card, and we call them Goodz. And it's printed on three-millimeter plywood using a UV printing process, super durable. And this is something you can put in your pocket. You're not going to wreck it. I think you could actually (Don't quote me on this.), but I think you can even, like, put it through a washing machine, and it would be fine. Embedded in this card is a chip that can be read by your phone, and that's pretty much what we're working with. +MIKE: Yeah, so the idea is you just sort of tap this, and it'll take you to a streaming version of a playlist. And then Chris has also been making these adorable crates. And [crosstalk 26:10] +LINDSEY: The little crates I love. +MIKE: And we actually have some wooden ones, too, in the testing that's [crosstalk 26:15] +LINDSEY: And then the mixtapes get stored in the little crates [crosstalk 26:19] +MIKE: Yeah. So, you could have -- +LINDSEY: Throw it on your desk. +CHRIS: Each crate can hold about, I think, 15 of these things. What's really cool about this product on the physical side is we are using a tried-and-true technology, which is NFC chips. These are things that make Apple Pay work, make Google Pay work. They are in your E-ZPass when you drive through a toll booth. This is stuff that's been around for years. So, we're just kind of leveraging this technology that's been around for so long in a new way. +MIKE: Yeah, I think it's similar to kind of the evolution of QR codes, right? It's like they were sort of around forever, and then it was, like, COVID and restaurant menus kind of kicked those into mainstream. Like, NFC has been around for a long time. It's very tried and true. It's affordable. But I want to say Apple only turned it on by default, like, the NFC reader in the iPhone in the last, like, 18 to 24 months, right? Like, it started...like, it's been around for a while, but they're sort of slowly kind of...and now you just sort of see it everywhere. People are using it on the subways in New York to scan for tickets or for accessing stuff. +I was also just showing Chris has been prototyping with the ability to sort of keep these on a key ring. So, we have, like, a little chain hole on them. It is [inaudible 27:22] to sort of have this on your backpack or, you know, on a key ring, or something like that. And friends could kind of, like, come up to you and just, like, scan one that looks interesting. +CHRIS: And yeah, something that's awesome about this is you don't need an app. You don't need to download anything. As long as your NFC reader is on when you scan this, it will bring you to the music that it's linked to, which I think is awesome. So, I mean, my dream is to have these, like, hanging off of people's backpacks so I can, like, scan them in the subway or, you know, it's such, like, an easy thing to do. And it requires so little technical time on the user's end to be able to do it. +LINDSEY: Oh, we got a question here. "So, Moo used to offer NFC cards. What made you decide to do the thicker plywood model?" +CHRIS: Durability is really what it comes down to. We wanted something that felt like an object that you can have and treasure. Like, these have weight, you know, these feel like something, not just a piece of paper. This is something that you can have and [inaudible 28:22] your desk, and it's not going to fade in the sunlight. It's not going to disintegrate over time. This is something that's going to last. +MIKE: Yeah, the cards would definitely, like, as I would sort of carry them around and show them to people and stuff, the cards would start, you know, breaking. It's like having a business card in your pocket, right? Eventually, it's going to kind of wear out. And plus, we had, like, the stickers were visible on the back of them. And we were, like, having the sticker just completely disappear inside the wood it just feels a little bit more like magic. +LINDSEY: Well, thanks for demoing there. I put you on the spot a little bit. But they are...I had seen them in the Slack, and they're very cool [laughs]. So, I had to ask if we could show them off a bit. +MIKE: Of course. +CHRIS: I think another thing to think about, too, is we've been talking a lot about the user experience. But if and when we get to the point of making these for artists, artists will be able to collect so much data off of the way that people buy and collect and use these things over time, which is something that we're really, really excited about. And also, you know, we're working on a way to make the link in the object updatable over time. So, artists will be able to change what a card points do to inform their users about the latest and greatest thing. +LINDSEY: Very cool. Jordyn, what's next on the programming agenda for Chris and Mike? +JORDYN: It's really sort of we're in this, like, iterative cycle. So, we're talking to folks. We're working on the website. The conversations we're having with people are informing how we're framing this first experiment with the mixtape, how we're marketing it, who we're marketing it to. I think next up is probably a Google Ad experiment to really see if we can piggyback on some stuff or at least figure out a new consumer product. It's so tough, right? +It's also not a thing people are searching for. So, we have to come up with some experiments for how we get people to that website [laughs]. So, you know, Google Ads funnels is just something you kind of have to do because it's very interesting to figure out what people are responding to, what people are searching for. But we're going to have a bunch of other experiments as well and non-experiments. Outbound experiments: can we go to people? Can we get listed in a gift-buying guide for the holidays? Or, like, we don't know. There's a bunch of experiments we need to do around that, which is really just this iteration. +We won't stop talking to users but, you know, everything we're hearing from them will inform where we go and how we talk to the folks in those places where we end up. And really, it's just about starting...once this is up and, you know, there's, like, an orderable thing, there's, like, a whole data cycle where we start to learn from the stuff we're testing; we actually have some real data for it, and we can start to tweak, iterate and change our strategy. +But the bigger thing, also, is this bigger platform. So, the next thing really, the big next thing, is to sort of start to scope and create an architecture idea. What's it going to take to build the actual backend thing? And it's the thing that thoughtbot really [laughs] excels at, which is software. So, you know, that's the big next kind of project. Once the mixtape experiment is sort of out and in flight and we're getting data, we really need to turn our attention to the technical backend. +LINDSEY: Exciting. Another comment/question from Jeff, who maybe needs a user interview. "Love the crate more than the actual albums. Maybe offer collections of artists." +MIKE: Yeah, that's the plan. +CHRIS: Yeah, definitely. It's a good idea. Yeah, it's, I mean, and labels get to, especially, like, small indie labels get really excited about doing, like, crates worth of collections of different artists or, like, you know, digging through their back catalog, their subscription services. There's a lot of different angles for sure about that idea. +LINDSEY: [inaudible 31:55] Chris and Mike, going into this next section of the programming, for anyone watching right now, or watching the recording, or listening to the recording, any action items from them? You know, are you looking for any user interviews or have any survey or any destinations you'd like to send people yet? +CHRIS: Not quite yet, but soon, I would say. Well -- +MIKE: I mean, [inaudible 32:19] plug the website, I mean, you know, I think we've got, like, an email to sign up from there, right? The URL is getthegoodz.com and I [crosstalk 32:27] +LINDSEY: Goodz with a Z. +MIKE: Goodz with a Z. +CHRIS: With Z. +MIKE: So yeah, if you want to go there, you can sign up. I think there's an email signup on there to learn more. +LINDSEY: Perfect. All right. getthegoodz.com email sign up. To stay up to date on Goodz and the incubator, you can follow along on the thoughtbot blog. You know, as always, send us any questions you might have, and we're happy to get to those. But otherwise, thanks for listening. +And thank you all — Jordyn, Chris, and Mike. Thanks so much for joining today and sharing and being open about your stories so far. +MIKE: Thank you. +CHRIS: Yeah, thank you, Lindsey. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + If you missed the first episode with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can go here first to catch up!

+ +

Startup founders Mike Rosenthal and Chris Cerrito are participating in thoughtbot's eight-week incubator program. Mike, with a background in the music industry, and Chris, experienced in physical computing and exhibit development, are collaborating on a startup that creates physical objects linked to digital content, primarily in music. Their goal is to enhance the connection between tangible and digital experiences, starting with a product that resembles a mixtape, using NFC technology for easy access to digital playlists.

+ +

This project is unique within the thoughtbot incubator as it's the first pure consumer product and involves both physical and digital elements. The team is engaged in user interviews and market validation, with the aim of launching a physical product with a digital backend. They are exploring various marketing strategies for the product and are in the process of building its technical backend.

+ +

Transcript:

+ +

LINDSEY: All right. I'm going to kick us off here. Thanks, everyone, for tuning in. We're doing our first update with two founders that are now going through the Startup incubator at thoughtbot. thoughtbot, if you're not familiar, product design and development consultancy. We'll help you on your product and make your team a success. One of the very fun ways we do that is through the startup thoughtbot incubator, which is an eight-week program.

+ +

So, with us today, I myself am Lindsey Christensen, marketing for thoughtbot. We also have Jordyn Bonds, who is our Director of Product Strategy and runs the thoughtbot incubator. And then, as I mentioned, we've got two new founders who are going to tell us a little bit about themselves and what they're working on. Mike Rosenthal, let's kick off with you. Can you tell us a little bit about maybe your background and what brings you to present day?

+ +

MIKE: Sure. First of, thanks for having us. It's been a lot of fun doing this over the last [inaudible 01:03]; it's only two weeks, two and a half weeks, something like that. It feels like a lot more. I come from a music industry background, so worked in sort of marketing and strategy for artists for a long time; worked with a band called OK Go back, sort of starting in 2009 or so.

+ +

I did a lot of early kind of viral music video stuff. And we were sort of early to the idea of sort of leveraging fan engagement and revenue, honestly, kind of beyond sort of just selling their music and touring, so sort of exploring other ways that artists can make money and connect with their fans and was with those guys for five years.

+ +

And then, I went on and worked at an artist management company in Brooklyn called Mick Management and ran the marketing department there, so doing similar type of work but for a roster of 2025 major label bands. And so, really got to see fan engagement on all different levels, from really large bands down to baby bands who were just getting started. And then, yeah, started my first startup in 2018, so doing sort of fan engagement work, and NFTs, and blockchain-type stuff working with bands, but then also sports and entertainment properties. Yeah, that kind of brings me here.

+ +

So, always been sort of on the music side of things, which ties into a lot of what Chris and I are working on now, but more generally, sort of fan engagement and how to, you know, drive revenue and engagement for artists and deliver value for fans.

+ +

LINDSEY: Very interesting. All right, Chris, going to head over to you. Chris Cerrito, can you tell us a bit about your background? And it sounds like yours and Mike's paths; this isn't the first time you've crossed.

+ +

CHRIS: No. Mike and I have been working together since 2007, I believe. Yeah, that's a great place to start. I've always been kind of a maker and a tinkerer, always been interested in art materials, how things are put together. And that kind of culminated at grad school, where Mike and I met at NYU, where we both studied physical computing and human-computer interaction, making weird things that kind of changed the way that people interact and play with technology in their day-to-day lives.

+ +

I think the first project he and I worked on together was a solar robotic band that we played with light in front of a bunch of people. It was very wonderful and confusing at the same time. After grad school, I was lucky enough to become a resident artist and then an exhibit developer at a museum in San Francisco called the Exploratorium, which is a museum of science, art, and human perception.

+ +

I spent ten years there working on exhibits teaching people things ranging from, let's see, I built a dueling water fountain to teach visitors and users about the prisoner's dilemma. I built a photo booth that used computer vision to teach people about the microbiome that lives on their face, like, just all kinds of weird things like that that fuse the digital and the physical worlds. I loved my time there.

+ +

And then kind of COVID hit and I realized that everything I had been working on for ten years was locked up in a museum that I no longer had access to. And it really gave me a desire to kind of bring my ideas into the physical world. I wanted to make things that people interact with and use in their lives on a day-to-day basis. And I would say that's really what brought me here to this point.

+ +

LINDSEY: Very cool. Very interesting backgrounds, in my opinion. What is the new idea? What is the thing that you're bringing into the incubator? Mike, I'll start with you. Tell us a bit about what you're working on.

+ +

MIKE: Chris and I are working on physical objects that connect to digital content is sort of the broadest way that I could describe it. I think, you know, as Chris kind of mentioned, you know, we've both been working on sort of physical things that have interactivity for a lot of our careers. I think we both come from an era of a lot more physical objects in your life, whether that's, you know, VHS cassettes at your parent's house growing up, or records and tape cassettes, and just sort of physical things that remind you of the things that you love.

+ +

And I think that, you know, cell phones are great, and the sort of the smartphone era is amazing and having, you know, every single song, and movie, and television show and podcasts, et cetera, in a black box in my pocket is great. But I think we've sort of gotten to a point where it's more of an organizational problem now than anything else. And we sort of forget the actual things that we love in this world.

+ +

And so, we're working on basically making physical objects to tie to digital content, and we're starting with music. And that's what we've been working on at thoughtbot is sort of how we can create physical things that basically you can tap, and that will take you to streaming content. One of the first things we're working on literally looks like sort of a little mixtape on a piece of wood, and you can just load that up with any sort of playlist that you might have on Spotify, or Apple Music, or YouTube, or whatever, and tap it, and it will take you there.

+ +

And so, it's just sort of that idea of like, oh, we used to be able to sort of flip through a friend's music collection and judge them ruthlessly, or become even better friends with them based on kind of what you saw there. And we think that the time is ripe for, I don't know, a blend of that nostalgia with actual sort of, like, real-world utility that people could be into this right now. Chris, what am I missing there?

+ +

CHRIS: I'd say just to expand on that a little bit, it's, you know, we spend so much time in the digital world, but we still exist in the physical. And a lot of the things, like, you might spend a really long time editing a photo for your parents or making a playlist for a friend, and there's, like, a value there that might not translate because it's digital. It's ephemeral. And I think tying these digital assets to a physical thing makes them special. It gives them, like, a permanent place in your life, something to respect, to hold on to, and maybe even pass down at some point.

+ +

LINDSEY: Yeah, and I think before we logged on, we actually had Jordyn and Mike grabbing cassette tapes from the room there and to show us --

+ +

MIKE: [inaudible 06:49]

+ +

LINDSEY: What [laughs] was some of their collection and to prove some of the power of these physical –-

+ +

MIKE: Nothing, like, just old mixtapes.

+ +

LINDSEY: Mementos.

+ +

MIKE: Yeah. We were just talking about this on our sync with the thoughtbot crew. They're, like, there's sort of two levels of nostalgia. There's nostalgia for people like us who, yeah, [crosstalk 07:09] mixtapes, right? For people who actually grew up with this stuff and still have it lying around or don't but, like, look at something like that that gives you, like, instant flashbacks, right? You're like, oh my God, I remember scrolling on that little j-card or, like, getting a mixtape for my first, you know, boyfriend or girlfriend, and having it just mean everything. So, there's people for whom that was a thing.

+ +

And there's, you know, generations of people for whom that is, like, their only connection to that is, you know, Stranger Things or, like, you know, the mixtape exists in pop culture as a reference. So, there's still, like, a very strong attachment there, but it's not a personal one, right? It's a cultural one. But I think everybody has that connection. So, that's kind of why we're starting with the mixtape, just because I think everyone can kind of relate to that in some way.

+ +

LINDSEY: Yeah, no, yeah. When I hear mixtape, it goes immediately to crushes. You make a mixtape for your crush.

+ +

CHRIS: Exactly.

+ +

LINDSEY: It's a huge, powerful market, powerful.

+ +

MIKE: Oh my God, so powerful. I mean, yeah, I don't know anybody --

+ +

LINDSEY: What's more motivating?

+ +

MIKE: [laughs] Yeah, exactly.

+ +

CHRIS: Or even just I have a really good friend who I don't get to see as often as I'd like. And he and I are constantly sending each other, you know, Spotify links and text messages. And it's great. I love that interaction. But at the same time, you know, I might forget to add that to a playlist, and then it's kind of lost. If I had taken the time to make something and send it to him physically or vice versa, it just becomes so much more special and so much more real.

+ +

MIKE: Yeah. I mean, honestly, I first made these...I mean, we can go to this origin if we want. But, like, I literally just went on moo.com, right? The business card company. And they let you upload, you know, 50 different images, and they'll send you all of those as business cards. And so, I literally went on and just made business cards of all the album covers of, like, albums that I loved growing up, right? And their cheapest is this little piece of cardboard. But I had 50 of these, and I'd put them all out on my coffee table, just as something I wanted to have around.

+ +

And people kept coming, you know, friends would come over, and you would just have these conversations that I haven't had in 10 or 15 years, right? Because no one's going to come to my house and pick up my phone and look at my Spotify collection. But if these things are all just sitting out, they're like, "Oh shit, you're into that? Like, I haven't thought about that album in 15 years." Or like, "Oh, I didn't know you were into that. I'm, like, a crazy super fan of that artist as well." And all of a sudden, we're having these conversations that we just weren't having. Yeah, there's something there where it's all been nostalgia coupled with the kind of prompting of conversation and connection that we've kind of lost, I think.

+ +

CHRIS: And I think just to clarify a little bit on what Mike's saying, is, you know, this mixtape will be our first product launch, and then we're hoping to move into collectibles for artists and labels. So, shortly after we launch this tape, we're hoping to launch some kind of pilot with a label where you will be able to buy a version of this for your favorite music artist at a merch table in a concert, possibly online. Our dream is to have these sitting there on the table with T-shirts, and records, and other things that artists sell so you can express for the artists that you love. This is a way of expressing your fandom.

+ +

LINDSEY: Jordyn, heading over to you, this feels like maybe the first consumer product that has gone through the incubator, would you say? Or how do you think about it?

+ +

JORDYN: Yeah, if you're a consumer --

+ +

LINDSEY: Or is it different than other types of products?

+ +

JORDYN: Yeah, the first incubator project we did with Senga was, I think, what you would call prosumer. So, it was sort of a consumer thing but directed at folks who had kind of freelancing in sort of a business context. It's got a lot of dynamics of the consumer. But this one, for sure, is the first pure consumer play. Though now that I'm thinking about it, you know, AvidFirst had some consumer elements to it, but it was, you know, it was, like, more complex tech [laughs] [inaudible 10:46] totally different thing --

+ +

LINDSEY: But definitely the first of the physical, physical [inaudible 10:52]

+ +

JORDYN: Oh, sure, the first of the physical thing. Right. Absolutely.

+ +

LINDSEY: Does that change any of, like, the approach of the programming, or it's kind of --

+ +

JORDYN: I mean, no, not fundamentally, though it does add this layer of operations that you don't have with a pure software play. So, we have to be, there is a thing that needs to get shipped to people in the world, and that takes timelines, and it takes --

+ +

LINDSEY: Supply chain.

+ +

JORDYN: Yeah, exactly. And Chris is doing most of that stuff. I don't want to, you know, this is not, like, the main focus of our team necessarily, but it intersects, right? So, this isn't the first one of these types of products I've worked on personally in my career. But there's something, like, really, for me, very fulfilling about, like, there's software. There's a big component of software. There's also this physical object that needs to exist in the world.

+ +

And partly, what's so compelling about Goodz is that it gives you the promise of a physical, like, the sort of good aspects of a physical product, a thing you can hold in your hand and look at and really connect with in that physical way. But it has this dynamic digital, like, essential quality as well. So, it's very compelling as a product because it sort of marries the things that we like about both the physical world and the digital world, which is partly why the team was really excited about working on it [laughs].

+ +

LINDSEY: Well, that was going to be my next question is, you know, what stood out to you about the Goodz application for the incubator and the interview process that made you and the team feel like this was going to be a great project to work on?

+ +

JORDYN: Yeah. So, I think just the team really resonated with the sort of idea in general, and it seemed fun. There was, like, it's a very positive thing, right? It isn't so much about solving problems and pain points. And, sometimes the, you know, when you're very focused on solving problems, it can feel a little doomy because you actually have to, like, immerse yourself in the problems of the people that you're making software for. And sometimes, you start to feel like the world is just full of problems.

+ +

What Goodz is doing is sort of it is solving a problem in a sense, but not in that kind of way. It's really, like, a fun upside kind of thing, which I think a lot of the folks on the team were very excited about. But, like, the software component, actually, is very interesting to us from a technological standpoint as well. There's a lot of opportunity here to do interesting things on the backend with an object that's essentially functioning as a bookmark out in the world. What all can you do with that? There's something super compelling and technically interesting about it.

+ +

And I think, also, the team was just sort of excited by Chris and Mike, you know, the energy and the kind of background they were bringing to the table was also super interesting. And then, above all else, what I say every time you ask me this question, which is stage fit, y'all, good stage fit. They're right at the beginning. They haven't built the product yet [laughs]. Gotta say it. It's a good stage fit. They know who they're building for broadly but not super specifically. Got a good vision but, like, haven't made that first step with the software. Perfect stage fit for us [laughs].

+ +

LINDSEY: Great. So, Chris, we were talking a bit before about how you two have been collaborators in the past, worked on business ideas before. Why bring this idea into the thoughtbot incubator? What are you hoping to, you know, achieve?

+ +

CHRIS: One of the main reasons why we wanted to bring this into the incubator was just for support, momentum, and then, also, I would say validation for our idea. I mean, we came to the incubator with a very, yeah, I would say it was a fairly developed idea that needed to be proved, and we, quite frankly, needed help with that. You know, Mike and I have our own expertises, but we don't know how to do everything. We're more than willing to jump in where we need to go.

+ +

But having people with expertise to work with has proven to be incredibly helpful and just having kind of fresh faces to bat ideas around with after he and I have been staring at each other for months now on Zoom calls and meetings. And just, you know, being able to talk about these ideas with fresh faces and new people and get new perspectives has been so very, very helpful.

+ +

I think something that's also great from the momentum standpoint is that because there's a time limit to this experience, we've got the time that we have with you guys, and we've been able to set goals that I think are very achievable for things we want to occur in the next couple of months, and it feels like we're going to get there.

+ +

And I think by the end of this, I mean, our hope, and I think we're on track, is to have a functioning physical product that we're going to offer to consumers with a digital backend to support it, which is, in my mind, amazing. That'll totally validate this idea and prove if we have something or not.

+ +

LINDSEY: I was going to ask if you're open to sharing what those goals specifically are. Is that it? Is it that by the end, you have --

+ +

MIKE: Is that it? Lindsey, that's a lot.

+ +

[laughter]

+ +

CHRIS: It's a lot. I mean, yeah. I mean, we're going to have a physical object in the world that you can buy via an e-commerce site --

+ +

JORDYN: Sounds like we need Lindsey on the team if Lindsey feels like this is so achievable. [laughter]

+ +

CHRIS: Yeah, yeah. Lindsey...yeah. We're in the beginning [crosstalk 15:47]

+ +

LINDSEY: I meant, is that the goal?

+ +

CHRIS: That is the goal.

+ +

LINDSEY: Is that all?

+ +

CHRIS: I was going to –-

+ +

LINDSEY: Is that all you got?

+ +

CHRIS: Mike, do you agree?

+ +

MIKE: Yeah. Is that the goal? Yes, that is the goal. I mean, you know, when we sat down with the thoughtbot team kind of week one, you know, they're sort of like, "All right, let's define kind of the experiment." So, we refer to them as experiments, which I think is helpful because, like, what are the experiments that we want to be doing during our time here? And, you know, we talked about it a lot.

+ +

And yeah, I think it's, you know, having a physical product out in the world, having a website in which to sell it. But also, it's really, like Chris was saying, it's like, it's market validation, and just making sure we actually have something that people want. It's like, you know, running a startup takes so long and, like [laughs], you know, you'll do it for so many years. It's like bands when people say, like, "Oh, that's an overnight sensation." It's like, you know, that band has been slogging it out in tiny, little venues for four years before you ever heard of them.

+ +

It's like, that's what so much of the startup world feels like to me, too. It's like, "Oh, you're just getting started as a startup?" It's like, "Well, we've been working on this forever." And I know how long this can take. And so, I think we want to learn as early as possible, like, is this something people actually want? Because if they don't, like, we'll just go do something else. I don't want to spend years making something that people don't want.

+ +

So, I think the biggest goal, for me, is just validation, and then that is sort of how we get there is like, okay, how do we validate this? Cool. Let's identify some, you know, assumptions of personas that we think are people who do actually want this and then try to go sell it to them. And all the implications from that are, okay, well, you need a website where somebody can buy it. You need a physical product that somebody can actually buy. So, all those things sort of come out of that, but, for me, it's like, proving that assumption, is this thing real? Do people actually want this? And everything else is like, okay, how do we prove that?

+ +

LINDSEY: Jordyn, what does that look like in these first few weeks here? User interviews, I assume, how are the user interviews going?

+ +

JORDYN: Always. Always. So, you know, we kick it off by just, like, doing the exercise where we list everybody who might want this. And the team, you know, it's a fun product. Everybody brought their own assumptions and ideas to the table on that. You know, we had a lot of different scenarios we were imagining. It's super fun getting that stuff out of people's heads, just, like, what are we all thinking?

+ +

And then, you know, we get to negotiate, like, okay...I always encourage everyone to think, like, if everyone else on the team was on the moon, you had to make a decision about a market segment to pick; which one would you pick? And then we kind of argue about it in a productive way. It really helps us get at, like, what are the dynamics that we think matter upfront? And then we pick one, or, in this case, we have a few. We have a handful.

+ +

And we're running interview projects where we just recruit people to talk about people that meet this persona, talk about a specific problem. We're in the middle of that right now. And it's fun, fantastic. These conversations are super interesting. We're validating a lot of the things that Mike and Chris, you know, walked into this with, but we're learning a bunch of new things as well.

+ +

And, like, really, part of the aim there is to validate that there's a hole in the market that we might fill but also to hear the language people are using to describe this stuff. So, when people talk about buying music, merch, you know, making playlists, et cetera, like, what language do they use to talk about that? So that we make sure we're speaking the language that our customer uses to describe this stuff. And we're, you know, we're right in the pocket of doing that, learning stuff all the time.

+ +

And it helps us kind of hone the messaging. It helps us know where to go talk to people about it, how to talk about it, but it's, you know, it all kind of fits together. And it's just this, really...the early stages. It's just a bunch of us in a room, a virtual room, in this case, sort of, like, tossing ideas around. But out of it crystallizes this sense of alignment about who this is for, how to talk to them about it, and with a goal.

+ +

And, you know, Mike and Chris walked in with the exact right mindset about this, which is, yes, it's experiments. We need to validate it. Let's make sure there's a there-there. If there's a there-there, let's figure out where it is [laughs], like, all those things. And we're running these experiments, and it was really [inaudible 19:36]. We got down to business quite quickly here. It was really great.

+ +

LINDSEY: Like you said, it's not necessarily a problem or, you know, the typical framing of a problem. How do you start those user interview questions around this? Do you feel a gap between the physical and the digital sound? [laughter]

+ +

JORDYN: No, no.

+ +

LINDSEY: It's maybe not it [laughs].

+ +

JORDYN: Yeah, no. Well, I can tell you what our startup questions are. One of them is, tell me about the last time you bought music merch. Go for it, Lindsey. Tell us.

+ +

LINDSEY: The last time I bought music merch I went to a Tegan and Sara concert a few weeks ago, and I bought a T-shirt.

+ +

JORDYN: Tell me about buying that T-shirt. Why'd you buy it?

+ +

LINDSEY: Because I wanted to remember the show and my time with my friends, and I wanted to support the artists. I know that buying merch is the best way to support your favorite touring artists.

+ +

JORDYN: So, it's just, you know, we could spend the rest of this time talking [laughter] [crosstalk 20:34], and it would be awesome. So, it's really a lot of things like that.

+ +

LINDSEY: Gotcha.

+ +

JORDYN: You don't ask, "What problem are you trying to solve by buying this t-shirt?" Right? Like, that's not, you know, but we ask you to tell us a bunch of stories about when you did this recently. You know, and if you make playlists for friends, you know, that's a different persona. But we would have asked, you know, like, "Tell me about the last playlist you made. You know, who did you share it with? You know, what happened after that? What happened after that? What happened after that?" It's a lot of questions like that. And there's just nothing better. People love to tell you what's going on with them. And it's great [laughs].

+ +

LINDSEY: Yeah. As you all have been doing these interviews, Mike and Chris, have you been surprised by anything? Any interesting insights that you're seeing already?

+ +

CHRIS: I mean, I haven't done really much in the way of user interviews in the past. This is a really new experience for me. And then we're, obviously, not on the calls because that would be weird and probably intimidating for people. But we're getting lots of highlights from folks who are doing them, you know, in our daily sync.

+ +

And I'm surprised at how many, like, really intense, like, playlist nerds we have found even just in, like, the few people we've talked to, like, in the best possible way. Like, people who are like, "I make playlists all the time." Like, you're talking about, like, a vinyl fan or, like, a...Jordyn, what's the story? It's, like, the guy who there was so much out-of-print vinyl that he started a vinyl label just to get the albums in vinyl. [crosstalk 21:56]

+ +

JORDYN: Yeah. There were a bunch of releases that he feels really passionately about that were never released on vinyl that he knew would never be released on vinyl. And so, he started a vinyl record label. And we just found this guy [laughter].

+ +

CHRIS: Is that indicative that that's, like, an entire persona we're going to, like, target? Absolutely not. But it's just, like, it's amazing that even just in the few user interviews we've done, that we've found so many very passionate people. And it's sent me down, like, a TikTok rabbit hole of, like, TikTok, like, music nerd influencer-type folks who are posting playlists.

+ +

And they, like, hundreds of thousands of likes on these videos that are literally just, like, screen with text on it that you're supposed to, like, pause the video [laughs] and, like, look at, like, the songs that they're recommending. And it's like, who does that? And it was like, these people do that. And it's like, so there are...it's been very encouraging to me, actually. I was worried that we were going to find not as much passion as we had suspected, and I think the opposite has proven to be true. So, it's exciting.

+ +

CHRIS: Yeah, I completely agree with Mike. It's been so encouraging. I think, for me, what we're doing is an idea that I'm very excited about and have been very excited about for a long time. But hearing the responses that we're getting makes me confident in the idea, too. That's great. I mean, I think that is everything that a founder needs, you know, is excitement and confidence.

+ +

MIKE: Well, and just the whole user interview experience has, like, made a lot of my other conversations sort of I've tried to frame parts of them as user interviews because I'm talking to a lot of, like, label folks now, and artists, merch people. And, you know, I ended up just sort of, like, asking them, I mean, yes, trying to explain the product and work on kind of partnership stuff, but a lot of it is really just geeking out with them. And just, like, hearing their thoughts about, like, what they love about merch because these are people that clearly think about this stuff all the time. So, it's definitely kind of, like, tuned my other conversations into trying to get unbiased feedback.

+ +

LINDSEY: Yeah. Everything is a little user interview now.

+ +

MIKE: Yeah, exactly.

+ +

LINDSEY: Get that angle in there. All right, so some early validation and excitement. That's really cool to hear. Any challenges or, you know, other kinds of learnings early on? Anything that's been invalidated?

+ +

MIKE: I don't know that we're there yet. [inaudible 24:02] Chris, I don't know. I'm happy to find that some things are invalidated, but I don't really feel...you know, some of the personas that we decided or maybe just one of the personas we decided to pursue, I think we're having a hard time having those user interviews kind of really bear fruit, but that's helpful, too, actually. I mean, it's like, okay, well, maybe that's not a group that we target.

+ +

JORDYN: Yeah. It's about, like [inaudible 24:24]. I encourage folks not to think about this like a 'no, not that,' and instead think of it as like a 'not yet.' And that's, I think, the dynamic here with a couple of the personas we were interested in. It's just been turned into kind of, like, a not yet for reasons that we very quickly figured out, but we'll get there. It's just a matter of figuring out we had some other personas take precedence because they're more sort of red, hot in a way, right? It's just easier to get in contact with these people, or it's, like, clear what they're going for or what they need from the market.

+ +

So, you know, we have this whole list, and it was not clear at first who was going to kind of stand out. But we've kind of found some focus there, which means, invariably, that there's things that are falling out of the frame for now, and you're kind of de-prioritizing them. But it really is, like, a we'll get to that [laughs]. We'll eventually get to that.

+ +

LINDSEY: Yeah. And part of the process, who's going to rise to the top right now?

+ +

JORDYN: Yeah, exactly.

+ +

LINDSEY: Do you have anything you can show and tell with us today or not yet?

+ +

MIKE: So, Chris has been hard at work on all the physical side of this stuff and going back and forth with our manufacturing partner and all that good stuff. But we have a final version of the mixtape product.

+ +

LINDSEY: For when this gets pulled into the podcast, Mike's showing us a physical card.

+ +

CHRIS: It's a small card, and we call them Goodz. And it's printed on three-millimeter plywood using a UV printing process, super durable. And this is something you can put in your pocket. You're not going to wreck it. I think you could actually (Don't quote me on this.), but I think you can even, like, put it through a washing machine, and it would be fine. Embedded in this card is a chip that can be read by your phone, and that's pretty much what we're working with.

+ +

MIKE: Yeah, so the idea is you just sort of tap this, and it'll take you to a streaming version of a playlist. And then Chris has also been making these adorable crates. And [crosstalk 26:10]

+ +

LINDSEY: The little crates I love.

+ +

MIKE: And we actually have some wooden ones, too, in the testing that's [crosstalk 26:15]

+ +

LINDSEY: And then the mixtapes get stored in the little crates [crosstalk 26:19]

+ +

MIKE: Yeah. So, you could have --

+ +

LINDSEY: Throw it on your desk.

+ +

CHRIS: Each crate can hold about, I think, 15 of these things. What's really cool about this product on the physical side is we are using a tried-and-true technology, which is NFC chips. These are things that make Apple Pay work, make Google Pay work. They are in your E-ZPass when you drive through a toll booth. This is stuff that's been around for years. So, we're just kind of leveraging this technology that's been around for so long in a new way.

+ +

MIKE: Yeah, I think it's similar to kind of the evolution of QR codes, right? It's like they were sort of around forever, and then it was, like, COVID and restaurant menus kind of kicked those into mainstream. Like, NFC has been around for a long time. It's very tried and true. It's affordable. But I want to say Apple only turned it on by default, like, the NFC reader in the iPhone in the last, like, 18 to 24 months, right? Like, it started...like, it's been around for a while, but they're sort of slowly kind of...and now you just sort of see it everywhere. People are using it on the subways in New York to scan for tickets or for accessing stuff.

+ +

I was also just showing Chris has been prototyping with the ability to sort of keep these on a key ring. So, we have, like, a little chain hole on them. It is [inaudible 27:22] to sort of have this on your backpack or, you know, on a key ring, or something like that. And friends could kind of, like, come up to you and just, like, scan one that looks interesting.

+ +

CHRIS: And yeah, something that's awesome about this is you don't need an app. You don't need to download anything. As long as your NFC reader is on when you scan this, it will bring you to the music that it's linked to, which I think is awesome. So, I mean, my dream is to have these, like, hanging off of people's backpacks so I can, like, scan them in the subway or, you know, it's such, like, an easy thing to do. And it requires so little technical time on the user's end to be able to do it.

+ +

LINDSEY: Oh, we got a question here. "So, Moo used to offer NFC cards. What made you decide to do the thicker plywood model?"

+ +

CHRIS: Durability is really what it comes down to. We wanted something that felt like an object that you can have and treasure. Like, these have weight, you know, these feel like something, not just a piece of paper. This is something that you can have and [inaudible 28:22] your desk, and it's not going to fade in the sunlight. It's not going to disintegrate over time. This is something that's going to last.

+ +

MIKE: Yeah, the cards would definitely, like, as I would sort of carry them around and show them to people and stuff, the cards would start, you know, breaking. It's like having a business card in your pocket, right? Eventually, it's going to kind of wear out. And plus, we had, like, the stickers were visible on the back of them. And we were, like, having the sticker just completely disappear inside the wood it just feels a little bit more like magic.

+ +

LINDSEY: Well, thanks for demoing there. I put you on the spot a little bit. But they are...I had seen them in the Slack, and they're very cool [laughs]. So, I had to ask if we could show them off a bit.

+ +

MIKE: Of course.

+ +

CHRIS: I think another thing to think about, too, is we've been talking a lot about the user experience. But if and when we get to the point of making these for artists, artists will be able to collect so much data off of the way that people buy and collect and use these things over time, which is something that we're really, really excited about. And also, you know, we're working on a way to make the link in the object updatable over time. So, artists will be able to change what a card points do to inform their users about the latest and greatest thing.

+ +

LINDSEY: Very cool. Jordyn, what's next on the programming agenda for Chris and Mike?

+ +

JORDYN: It's really sort of we're in this, like, iterative cycle. So, we're talking to folks. We're working on the website. The conversations we're having with people are informing how we're framing this first experiment with the mixtape, how we're marketing it, who we're marketing it to. I think next up is probably a Google Ad experiment to really see if we can piggyback on some stuff or at least figure out a new consumer product. It's so tough, right?

+ +

It's also not a thing people are searching for. So, we have to come up with some experiments for how we get people to that website [laughs]. So, you know, Google Ads funnels is just something you kind of have to do because it's very interesting to figure out what people are responding to, what people are searching for. But we're going to have a bunch of other experiments as well and non-experiments. Outbound experiments: can we go to people? Can we get listed in a gift-buying guide for the holidays? Or, like, we don't know. There's a bunch of experiments we need to do around that, which is really just this iteration.

+ +

We won't stop talking to users but, you know, everything we're hearing from them will inform where we go and how we talk to the folks in those places where we end up. And really, it's just about starting...once this is up and, you know, there's, like, an orderable thing, there's, like, a whole data cycle where we start to learn from the stuff we're testing; we actually have some real data for it, and we can start to tweak, iterate and change our strategy.

+ +

But the bigger thing, also, is this bigger platform. So, the next thing really, the big next thing, is to sort of start to scope and create an architecture idea. What's it going to take to build the actual backend thing? And it's the thing that thoughtbot really [laughs] excels at, which is software. So, you know, that's the big next kind of project. Once the mixtape experiment is sort of out and in flight and we're getting data, we really need to turn our attention to the technical backend.

+ +

LINDSEY: Exciting. Another comment/question from Jeff, who maybe needs a user interview. "Love the crate more than the actual albums. Maybe offer collections of artists."

+ +

MIKE: Yeah, that's the plan.

+ +

CHRIS: Yeah, definitely. It's a good idea. Yeah, it's, I mean, and labels get to, especially, like, small indie labels get really excited about doing, like, crates worth of collections of different artists or, like, you know, digging through their back catalog, their subscription services. There's a lot of different angles for sure about that idea.

+ +

LINDSEY: [inaudible 31:55] Chris and Mike, going into this next section of the programming, for anyone watching right now, or watching the recording, or listening to the recording, any action items from them? You know, are you looking for any user interviews or have any survey or any destinations you'd like to send people yet?

+ +

CHRIS: Not quite yet, but soon, I would say. Well --

+ +

MIKE: I mean, [inaudible 32:19] plug the website, I mean, you know, I think we've got, like, an email to sign up from there, right? The URL is getthegoodz.com and I [crosstalk 32:27]

+ +

LINDSEY: Goodz with a Z.

+ +

MIKE: Goodz with a Z.

+ +

CHRIS: With Z.

+ +

MIKE: So yeah, if you want to go there, you can sign up. I think there's an email signup on there to learn more.

+ +

LINDSEY: Perfect. All right. getthegoodz.com email sign up. To stay up to date on Goodz and the incubator, you can follow along on the thoughtbot blog. You know, as always, send us any questions you might have, and we're happy to get to those. But otherwise, thanks for listening.

+ +

And thank you all — Jordyn, Chris, and Mike. Thanks so much for joining today and sharing and being open about your stories so far.

+ +

MIKE: Thank you.

+ +

CHRIS: Yeah, thank you, Lindsey.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + If you missed the first episode with thoughtbot Incubator Program partcipants and founders Mike Rosenthal and Chris Cerrito of Goodz, you can go here first to catch up!

+ +

Startup founders Mike Rosenthal and Chris Cerrito are participating in thoughtbot's eight-week incubator program. Mike, with a background in the music industry, and Chris, experienced in physical computing and exhibit development, are collaborating on a startup that creates physical objects linked to digital content, primarily in music. Their goal is to enhance the connection between tangible and digital experiences, starting with a product that resembles a mixtape, using NFC technology for easy access to digital playlists.

+ +

This project is unique within the thoughtbot incubator as it's the first pure consumer product and involves both physical and digital elements. The team is engaged in user interviews and market validation, with the aim of launching a physical product with a digital backend. They are exploring various marketing strategies for the product and are in the process of building its technical backend.

+ +

Transcript:

+ +

LINDSEY: All right. I'm going to kick us off here. Thanks, everyone, for tuning in. We're doing our first update with two founders that are now going through the Startup incubator at thoughtbot. thoughtbot, if you're not familiar, product design and development consultancy. We'll help you on your product and make your team a success. One of the very fun ways we do that is through the startup thoughtbot incubator, which is an eight-week program.

+ +

So, with us today, I myself am Lindsey Christensen, marketing for thoughtbot. We also have Jordyn Bonds, who is our Director of Product Strategy and runs the thoughtbot incubator. And then, as I mentioned, we've got two new founders who are going to tell us a little bit about themselves and what they're working on. Mike Rosenthal, let's kick off with you. Can you tell us a little bit about maybe your background and what brings you to present day?

+ +

MIKE: Sure. First of, thanks for having us. It's been a lot of fun doing this over the last [inaudible 01:03]; it's only two weeks, two and a half weeks, something like that. It feels like a lot more. I come from a music industry background, so worked in sort of marketing and strategy for artists for a long time; worked with a band called OK Go back, sort of starting in 2009 or so.

+ +

I did a lot of early kind of viral music video stuff. And we were sort of early to the idea of sort of leveraging fan engagement and revenue, honestly, kind of beyond sort of just selling their music and touring, so sort of exploring other ways that artists can make money and connect with their fans and was with those guys for five years.

+ +

And then, I went on and worked at an artist management company in Brooklyn called Mick Management and ran the marketing department there, so doing similar type of work but for a roster of 2025 major label bands. And so, really got to see fan engagement on all different levels, from really large bands down to baby bands who were just getting started. And then, yeah, started my first startup in 2018, so doing sort of fan engagement work, and NFTs, and blockchain-type stuff working with bands, but then also sports and entertainment properties. Yeah, that kind of brings me here.

+ +

So, always been sort of on the music side of things, which ties into a lot of what Chris and I are working on now, but more generally, sort of fan engagement and how to, you know, drive revenue and engagement for artists and deliver value for fans.

+ +

LINDSEY: Very interesting. All right, Chris, going to head over to you. Chris Cerrito, can you tell us a bit about your background? And it sounds like yours and Mike's paths; this isn't the first time you've crossed.

+ +

CHRIS: No. Mike and I have been working together since 2007, I believe. Yeah, that's a great place to start. I've always been kind of a maker and a tinkerer, always been interested in art materials, how things are put together. And that kind of culminated at grad school, where Mike and I met at NYU, where we both studied physical computing and human-computer interaction, making weird things that kind of changed the way that people interact and play with technology in their day-to-day lives.

+ +

I think the first project he and I worked on together was a solar robotic band that we played with light in front of a bunch of people. It was very wonderful and confusing at the same time. After grad school, I was lucky enough to become a resident artist and then an exhibit developer at a museum in San Francisco called the Exploratorium, which is a museum of science, art, and human perception.

+ +

I spent ten years there working on exhibits teaching people things ranging from, let's see, I built a dueling water fountain to teach visitors and users about the prisoner's dilemma. I built a photo booth that used computer vision to teach people about the microbiome that lives on their face, like, just all kinds of weird things like that that fuse the digital and the physical worlds. I loved my time there.

+ +

And then kind of COVID hit and I realized that everything I had been working on for ten years was locked up in a museum that I no longer had access to. And it really gave me a desire to kind of bring my ideas into the physical world. I wanted to make things that people interact with and use in their lives on a day-to-day basis. And I would say that's really what brought me here to this point.

+ +

LINDSEY: Very cool. Very interesting backgrounds, in my opinion. What is the new idea? What is the thing that you're bringing into the incubator? Mike, I'll start with you. Tell us a bit about what you're working on.

+ +

MIKE: Chris and I are working on physical objects that connect to digital content is sort of the broadest way that I could describe it. I think, you know, as Chris kind of mentioned, you know, we've both been working on sort of physical things that have interactivity for a lot of our careers. I think we both come from an era of a lot more physical objects in your life, whether that's, you know, VHS cassettes at your parent's house growing up, or records and tape cassettes, and just sort of physical things that remind you of the things that you love.

+ +

And I think that, you know, cell phones are great, and the sort of the smartphone era is amazing and having, you know, every single song, and movie, and television show and podcasts, et cetera, in a black box in my pocket is great. But I think we've sort of gotten to a point where it's more of an organizational problem now than anything else. And we sort of forget the actual things that we love in this world.

+ +

And so, we're working on basically making physical objects to tie to digital content, and we're starting with music. And that's what we've been working on at thoughtbot is sort of how we can create physical things that basically you can tap, and that will take you to streaming content. One of the first things we're working on literally looks like sort of a little mixtape on a piece of wood, and you can just load that up with any sort of playlist that you might have on Spotify, or Apple Music, or YouTube, or whatever, and tap it, and it will take you there.

+ +

And so, it's just sort of that idea of like, oh, we used to be able to sort of flip through a friend's music collection and judge them ruthlessly, or become even better friends with them based on kind of what you saw there. And we think that the time is ripe for, I don't know, a blend of that nostalgia with actual sort of, like, real-world utility that people could be into this right now. Chris, what am I missing there?

+ +

CHRIS: I'd say just to expand on that a little bit, it's, you know, we spend so much time in the digital world, but we still exist in the physical. And a lot of the things, like, you might spend a really long time editing a photo for your parents or making a playlist for a friend, and there's, like, a value there that might not translate because it's digital. It's ephemeral. And I think tying these digital assets to a physical thing makes them special. It gives them, like, a permanent place in your life, something to respect, to hold on to, and maybe even pass down at some point.

+ +

LINDSEY: Yeah, and I think before we logged on, we actually had Jordyn and Mike grabbing cassette tapes from the room there and to show us --

+ +

MIKE: [inaudible 06:49]

+ +

LINDSEY: What [laughs] was some of their collection and to prove some of the power of these physical –-

+ +

MIKE: Nothing, like, just old mixtapes.

+ +

LINDSEY: Mementos.

+ +

MIKE: Yeah. We were just talking about this on our sync with the thoughtbot crew. They're, like, there's sort of two levels of nostalgia. There's nostalgia for people like us who, yeah, [crosstalk 07:09] mixtapes, right? For people who actually grew up with this stuff and still have it lying around or don't but, like, look at something like that that gives you, like, instant flashbacks, right? You're like, oh my God, I remember scrolling on that little j-card or, like, getting a mixtape for my first, you know, boyfriend or girlfriend, and having it just mean everything. So, there's people for whom that was a thing.

+ +

And there's, you know, generations of people for whom that is, like, their only connection to that is, you know, Stranger Things or, like, you know, the mixtape exists in pop culture as a reference. So, there's still, like, a very strong attachment there, but it's not a personal one, right? It's a cultural one. But I think everybody has that connection. So, that's kind of why we're starting with the mixtape, just because I think everyone can kind of relate to that in some way.

+ +

LINDSEY: Yeah, no, yeah. When I hear mixtape, it goes immediately to crushes. You make a mixtape for your crush.

+ +

CHRIS: Exactly.

+ +

LINDSEY: It's a huge, powerful market, powerful.

+ +

MIKE: Oh my God, so powerful. I mean, yeah, I don't know anybody --

+ +

LINDSEY: What's more motivating?

+ +

MIKE: [laughs] Yeah, exactly.

+ +

CHRIS: Or even just I have a really good friend who I don't get to see as often as I'd like. And he and I are constantly sending each other, you know, Spotify links and text messages. And it's great. I love that interaction. But at the same time, you know, I might forget to add that to a playlist, and then it's kind of lost. If I had taken the time to make something and send it to him physically or vice versa, it just becomes so much more special and so much more real.

+ +

MIKE: Yeah. I mean, honestly, I first made these...I mean, we can go to this origin if we want. But, like, I literally just went on moo.com, right? The business card company. And they let you upload, you know, 50 different images, and they'll send you all of those as business cards. And so, I literally went on and just made business cards of all the album covers of, like, albums that I loved growing up, right? And their cheapest is this little piece of cardboard. But I had 50 of these, and I'd put them all out on my coffee table, just as something I wanted to have around.

+ +

And people kept coming, you know, friends would come over, and you would just have these conversations that I haven't had in 10 or 15 years, right? Because no one's going to come to my house and pick up my phone and look at my Spotify collection. But if these things are all just sitting out, they're like, "Oh shit, you're into that? Like, I haven't thought about that album in 15 years." Or like, "Oh, I didn't know you were into that. I'm, like, a crazy super fan of that artist as well." And all of a sudden, we're having these conversations that we just weren't having. Yeah, there's something there where it's all been nostalgia coupled with the kind of prompting of conversation and connection that we've kind of lost, I think.

+ +

CHRIS: And I think just to clarify a little bit on what Mike's saying, is, you know, this mixtape will be our first product launch, and then we're hoping to move into collectibles for artists and labels. So, shortly after we launch this tape, we're hoping to launch some kind of pilot with a label where you will be able to buy a version of this for your favorite music artist at a merch table in a concert, possibly online. Our dream is to have these sitting there on the table with T-shirts, and records, and other things that artists sell so you can express for the artists that you love. This is a way of expressing your fandom.

+ +

LINDSEY: Jordyn, heading over to you, this feels like maybe the first consumer product that has gone through the incubator, would you say? Or how do you think about it?

+ +

JORDYN: Yeah, if you're a consumer --

+ +

LINDSEY: Or is it different than other types of products?

+ +

JORDYN: Yeah, the first incubator project we did with Senga was, I think, what you would call prosumer. So, it was sort of a consumer thing but directed at folks who had kind of freelancing in sort of a business context. It's got a lot of dynamics of the consumer. But this one, for sure, is the first pure consumer play. Though now that I'm thinking about it, you know, AvidFirst had some consumer elements to it, but it was, you know, it was, like, more complex tech [laughs] [inaudible 10:46] totally different thing --

+ +

LINDSEY: But definitely the first of the physical, physical [inaudible 10:52]

+ +

JORDYN: Oh, sure, the first of the physical thing. Right. Absolutely.

+ +

LINDSEY: Does that change any of, like, the approach of the programming, or it's kind of --

+ +

JORDYN: I mean, no, not fundamentally, though it does add this layer of operations that you don't have with a pure software play. So, we have to be, there is a thing that needs to get shipped to people in the world, and that takes timelines, and it takes --

+ +

LINDSEY: Supply chain.

+ +

JORDYN: Yeah, exactly. And Chris is doing most of that stuff. I don't want to, you know, this is not, like, the main focus of our team necessarily, but it intersects, right? So, this isn't the first one of these types of products I've worked on personally in my career. But there's something, like, really, for me, very fulfilling about, like, there's software. There's a big component of software. There's also this physical object that needs to exist in the world.

+ +

And partly, what's so compelling about Goodz is that it gives you the promise of a physical, like, the sort of good aspects of a physical product, a thing you can hold in your hand and look at and really connect with in that physical way. But it has this dynamic digital, like, essential quality as well. So, it's very compelling as a product because it sort of marries the things that we like about both the physical world and the digital world, which is partly why the team was really excited about working on it [laughs].

+ +

LINDSEY: Well, that was going to be my next question is, you know, what stood out to you about the Goodz application for the incubator and the interview process that made you and the team feel like this was going to be a great project to work on?

+ +

JORDYN: Yeah. So, I think just the team really resonated with the sort of idea in general, and it seemed fun. There was, like, it's a very positive thing, right? It isn't so much about solving problems and pain points. And, sometimes the, you know, when you're very focused on solving problems, it can feel a little doomy because you actually have to, like, immerse yourself in the problems of the people that you're making software for. And sometimes, you start to feel like the world is just full of problems.

+ +

What Goodz is doing is sort of it is solving a problem in a sense, but not in that kind of way. It's really, like, a fun upside kind of thing, which I think a lot of the folks on the team were very excited about. But, like, the software component, actually, is very interesting to us from a technological standpoint as well. There's a lot of opportunity here to do interesting things on the backend with an object that's essentially functioning as a bookmark out in the world. What all can you do with that? There's something super compelling and technically interesting about it.

+ +

And I think, also, the team was just sort of excited by Chris and Mike, you know, the energy and the kind of background they were bringing to the table was also super interesting. And then, above all else, what I say every time you ask me this question, which is stage fit, y'all, good stage fit. They're right at the beginning. They haven't built the product yet [laughs]. Gotta say it. It's a good stage fit. They know who they're building for broadly but not super specifically. Got a good vision but, like, haven't made that first step with the software. Perfect stage fit for us [laughs].

+ +

LINDSEY: Great. So, Chris, we were talking a bit before about how you two have been collaborators in the past, worked on business ideas before. Why bring this idea into the thoughtbot incubator? What are you hoping to, you know, achieve?

+ +

CHRIS: One of the main reasons why we wanted to bring this into the incubator was just for support, momentum, and then, also, I would say validation for our idea. I mean, we came to the incubator with a very, yeah, I would say it was a fairly developed idea that needed to be proved, and we, quite frankly, needed help with that. You know, Mike and I have our own expertises, but we don't know how to do everything. We're more than willing to jump in where we need to go.

+ +

But having people with expertise to work with has proven to be incredibly helpful and just having kind of fresh faces to bat ideas around with after he and I have been staring at each other for months now on Zoom calls and meetings. And just, you know, being able to talk about these ideas with fresh faces and new people and get new perspectives has been so very, very helpful.

+ +

I think something that's also great from the momentum standpoint is that because there's a time limit to this experience, we've got the time that we have with you guys, and we've been able to set goals that I think are very achievable for things we want to occur in the next couple of months, and it feels like we're going to get there.

+ +

And I think by the end of this, I mean, our hope, and I think we're on track, is to have a functioning physical product that we're going to offer to consumers with a digital backend to support it, which is, in my mind, amazing. That'll totally validate this idea and prove if we have something or not.

+ +

LINDSEY: I was going to ask if you're open to sharing what those goals specifically are. Is that it? Is it that by the end, you have --

+ +

MIKE: Is that it? Lindsey, that's a lot.

+ +

[laughter]

+ +

CHRIS: It's a lot. I mean, yeah. I mean, we're going to have a physical object in the world that you can buy via an e-commerce site --

+ +

JORDYN: Sounds like we need Lindsey on the team if Lindsey feels like this is so achievable. [laughter]

+ +

CHRIS: Yeah, yeah. Lindsey...yeah. We're in the beginning [crosstalk 15:47]

+ +

LINDSEY: I meant, is that the goal?

+ +

CHRIS: That is the goal.

+ +

LINDSEY: Is that all?

+ +

CHRIS: I was going to –-

+ +

LINDSEY: Is that all you got?

+ +

CHRIS: Mike, do you agree?

+ +

MIKE: Yeah. Is that the goal? Yes, that is the goal. I mean, you know, when we sat down with the thoughtbot team kind of week one, you know, they're sort of like, "All right, let's define kind of the experiment." So, we refer to them as experiments, which I think is helpful because, like, what are the experiments that we want to be doing during our time here? And, you know, we talked about it a lot.

+ +

And yeah, I think it's, you know, having a physical product out in the world, having a website in which to sell it. But also, it's really, like Chris was saying, it's like, it's market validation, and just making sure we actually have something that people want. It's like, you know, running a startup takes so long and, like [laughs], you know, you'll do it for so many years. It's like bands when people say, like, "Oh, that's an overnight sensation." It's like, you know, that band has been slogging it out in tiny, little venues for four years before you ever heard of them.

+ +

It's like, that's what so much of the startup world feels like to me, too. It's like, "Oh, you're just getting started as a startup?" It's like, "Well, we've been working on this forever." And I know how long this can take. And so, I think we want to learn as early as possible, like, is this something people actually want? Because if they don't, like, we'll just go do something else. I don't want to spend years making something that people don't want.

+ +

So, I think the biggest goal, for me, is just validation, and then that is sort of how we get there is like, okay, how do we validate this? Cool. Let's identify some, you know, assumptions of personas that we think are people who do actually want this and then try to go sell it to them. And all the implications from that are, okay, well, you need a website where somebody can buy it. You need a physical product that somebody can actually buy. So, all those things sort of come out of that, but, for me, it's like, proving that assumption, is this thing real? Do people actually want this? And everything else is like, okay, how do we prove that?

+ +

LINDSEY: Jordyn, what does that look like in these first few weeks here? User interviews, I assume, how are the user interviews going?

+ +

JORDYN: Always. Always. So, you know, we kick it off by just, like, doing the exercise where we list everybody who might want this. And the team, you know, it's a fun product. Everybody brought their own assumptions and ideas to the table on that. You know, we had a lot of different scenarios we were imagining. It's super fun getting that stuff out of people's heads, just, like, what are we all thinking?

+ +

And then, you know, we get to negotiate, like, okay...I always encourage everyone to think, like, if everyone else on the team was on the moon, you had to make a decision about a market segment to pick; which one would you pick? And then we kind of argue about it in a productive way. It really helps us get at, like, what are the dynamics that we think matter upfront? And then we pick one, or, in this case, we have a few. We have a handful.

+ +

And we're running interview projects where we just recruit people to talk about people that meet this persona, talk about a specific problem. We're in the middle of that right now. And it's fun, fantastic. These conversations are super interesting. We're validating a lot of the things that Mike and Chris, you know, walked into this with, but we're learning a bunch of new things as well.

+ +

And, like, really, part of the aim there is to validate that there's a hole in the market that we might fill but also to hear the language people are using to describe this stuff. So, when people talk about buying music, merch, you know, making playlists, et cetera, like, what language do they use to talk about that? So that we make sure we're speaking the language that our customer uses to describe this stuff. And we're, you know, we're right in the pocket of doing that, learning stuff all the time.

+ +

And it helps us kind of hone the messaging. It helps us know where to go talk to people about it, how to talk about it, but it's, you know, it all kind of fits together. And it's just this, really...the early stages. It's just a bunch of us in a room, a virtual room, in this case, sort of, like, tossing ideas around. But out of it crystallizes this sense of alignment about who this is for, how to talk to them about it, and with a goal.

+ +

And, you know, Mike and Chris walked in with the exact right mindset about this, which is, yes, it's experiments. We need to validate it. Let's make sure there's a there-there. If there's a there-there, let's figure out where it is [laughs], like, all those things. And we're running these experiments, and it was really [inaudible 19:36]. We got down to business quite quickly here. It was really great.

+ +

LINDSEY: Like you said, it's not necessarily a problem or, you know, the typical framing of a problem. How do you start those user interview questions around this? Do you feel a gap between the physical and the digital sound? [laughter]

+ +

JORDYN: No, no.

+ +

LINDSEY: It's maybe not it [laughs].

+ +

JORDYN: Yeah, no. Well, I can tell you what our startup questions are. One of them is, tell me about the last time you bought music merch. Go for it, Lindsey. Tell us.

+ +

LINDSEY: The last time I bought music merch I went to a Tegan and Sara concert a few weeks ago, and I bought a T-shirt.

+ +

JORDYN: Tell me about buying that T-shirt. Why'd you buy it?

+ +

LINDSEY: Because I wanted to remember the show and my time with my friends, and I wanted to support the artists. I know that buying merch is the best way to support your favorite touring artists.

+ +

JORDYN: So, it's just, you know, we could spend the rest of this time talking [laughter] [crosstalk 20:34], and it would be awesome. So, it's really a lot of things like that.

+ +

LINDSEY: Gotcha.

+ +

JORDYN: You don't ask, "What problem are you trying to solve by buying this t-shirt?" Right? Like, that's not, you know, but we ask you to tell us a bunch of stories about when you did this recently. You know, and if you make playlists for friends, you know, that's a different persona. But we would have asked, you know, like, "Tell me about the last playlist you made. You know, who did you share it with? You know, what happened after that? What happened after that? What happened after that?" It's a lot of questions like that. And there's just nothing better. People love to tell you what's going on with them. And it's great [laughs].

+ +

LINDSEY: Yeah. As you all have been doing these interviews, Mike and Chris, have you been surprised by anything? Any interesting insights that you're seeing already?

+ +

CHRIS: I mean, I haven't done really much in the way of user interviews in the past. This is a really new experience for me. And then we're, obviously, not on the calls because that would be weird and probably intimidating for people. But we're getting lots of highlights from folks who are doing them, you know, in our daily sync.

+ +

And I'm surprised at how many, like, really intense, like, playlist nerds we have found even just in, like, the few people we've talked to, like, in the best possible way. Like, people who are like, "I make playlists all the time." Like, you're talking about, like, a vinyl fan or, like, a...Jordyn, what's the story? It's, like, the guy who there was so much out-of-print vinyl that he started a vinyl label just to get the albums in vinyl. [crosstalk 21:56]

+ +

JORDYN: Yeah. There were a bunch of releases that he feels really passionately about that were never released on vinyl that he knew would never be released on vinyl. And so, he started a vinyl record label. And we just found this guy [laughter].

+ +

CHRIS: Is that indicative that that's, like, an entire persona we're going to, like, target? Absolutely not. But it's just, like, it's amazing that even just in the few user interviews we've done, that we've found so many very passionate people. And it's sent me down, like, a TikTok rabbit hole of, like, TikTok, like, music nerd influencer-type folks who are posting playlists.

+ +

And they, like, hundreds of thousands of likes on these videos that are literally just, like, screen with text on it that you're supposed to, like, pause the video [laughs] and, like, look at, like, the songs that they're recommending. And it's like, who does that? And it was like, these people do that. And it's like, so there are...it's been very encouraging to me, actually. I was worried that we were going to find not as much passion as we had suspected, and I think the opposite has proven to be true. So, it's exciting.

+ +

CHRIS: Yeah, I completely agree with Mike. It's been so encouraging. I think, for me, what we're doing is an idea that I'm very excited about and have been very excited about for a long time. But hearing the responses that we're getting makes me confident in the idea, too. That's great. I mean, I think that is everything that a founder needs, you know, is excitement and confidence.

+ +

MIKE: Well, and just the whole user interview experience has, like, made a lot of my other conversations sort of I've tried to frame parts of them as user interviews because I'm talking to a lot of, like, label folks now, and artists, merch people. And, you know, I ended up just sort of, like, asking them, I mean, yes, trying to explain the product and work on kind of partnership stuff, but a lot of it is really just geeking out with them. And just, like, hearing their thoughts about, like, what they love about merch because these are people that clearly think about this stuff all the time. So, it's definitely kind of, like, tuned my other conversations into trying to get unbiased feedback.

+ +

LINDSEY: Yeah. Everything is a little user interview now.

+ +

MIKE: Yeah, exactly.

+ +

LINDSEY: Get that angle in there. All right, so some early validation and excitement. That's really cool to hear. Any challenges or, you know, other kinds of learnings early on? Anything that's been invalidated?

+ +

MIKE: I don't know that we're there yet. [inaudible 24:02] Chris, I don't know. I'm happy to find that some things are invalidated, but I don't really feel...you know, some of the personas that we decided or maybe just one of the personas we decided to pursue, I think we're having a hard time having those user interviews kind of really bear fruit, but that's helpful, too, actually. I mean, it's like, okay, well, maybe that's not a group that we target.

+ +

JORDYN: Yeah. It's about, like [inaudible 24:24]. I encourage folks not to think about this like a 'no, not that,' and instead think of it as like a 'not yet.' And that's, I think, the dynamic here with a couple of the personas we were interested in. It's just been turned into kind of, like, a not yet for reasons that we very quickly figured out, but we'll get there. It's just a matter of figuring out we had some other personas take precedence because they're more sort of red, hot in a way, right? It's just easier to get in contact with these people, or it's, like, clear what they're going for or what they need from the market.

+ +

So, you know, we have this whole list, and it was not clear at first who was going to kind of stand out. But we've kind of found some focus there, which means, invariably, that there's things that are falling out of the frame for now, and you're kind of de-prioritizing them. But it really is, like, a we'll get to that [laughs]. We'll eventually get to that.

+ +

LINDSEY: Yeah. And part of the process, who's going to rise to the top right now?

+ +

JORDYN: Yeah, exactly.

+ +

LINDSEY: Do you have anything you can show and tell with us today or not yet?

+ +

MIKE: So, Chris has been hard at work on all the physical side of this stuff and going back and forth with our manufacturing partner and all that good stuff. But we have a final version of the mixtape product.

+ +

LINDSEY: For when this gets pulled into the podcast, Mike's showing us a physical card.

+ +

CHRIS: It's a small card, and we call them Goodz. And it's printed on three-millimeter plywood using a UV printing process, super durable. And this is something you can put in your pocket. You're not going to wreck it. I think you could actually (Don't quote me on this.), but I think you can even, like, put it through a washing machine, and it would be fine. Embedded in this card is a chip that can be read by your phone, and that's pretty much what we're working with.

+ +

MIKE: Yeah, so the idea is you just sort of tap this, and it'll take you to a streaming version of a playlist. And then Chris has also been making these adorable crates. And [crosstalk 26:10]

+ +

LINDSEY: The little crates I love.

+ +

MIKE: And we actually have some wooden ones, too, in the testing that's [crosstalk 26:15]

+ +

LINDSEY: And then the mixtapes get stored in the little crates [crosstalk 26:19]

+ +

MIKE: Yeah. So, you could have --

+ +

LINDSEY: Throw it on your desk.

+ +

CHRIS: Each crate can hold about, I think, 15 of these things. What's really cool about this product on the physical side is we are using a tried-and-true technology, which is NFC chips. These are things that make Apple Pay work, make Google Pay work. They are in your E-ZPass when you drive through a toll booth. This is stuff that's been around for years. So, we're just kind of leveraging this technology that's been around for so long in a new way.

+ +

MIKE: Yeah, I think it's similar to kind of the evolution of QR codes, right? It's like they were sort of around forever, and then it was, like, COVID and restaurant menus kind of kicked those into mainstream. Like, NFC has been around for a long time. It's very tried and true. It's affordable. But I want to say Apple only turned it on by default, like, the NFC reader in the iPhone in the last, like, 18 to 24 months, right? Like, it started...like, it's been around for a while, but they're sort of slowly kind of...and now you just sort of see it everywhere. People are using it on the subways in New York to scan for tickets or for accessing stuff.

+ +

I was also just showing Chris has been prototyping with the ability to sort of keep these on a key ring. So, we have, like, a little chain hole on them. It is [inaudible 27:22] to sort of have this on your backpack or, you know, on a key ring, or something like that. And friends could kind of, like, come up to you and just, like, scan one that looks interesting.

+ +

CHRIS: And yeah, something that's awesome about this is you don't need an app. You don't need to download anything. As long as your NFC reader is on when you scan this, it will bring you to the music that it's linked to, which I think is awesome. So, I mean, my dream is to have these, like, hanging off of people's backpacks so I can, like, scan them in the subway or, you know, it's such, like, an easy thing to do. And it requires so little technical time on the user's end to be able to do it.

+ +

LINDSEY: Oh, we got a question here. "So, Moo used to offer NFC cards. What made you decide to do the thicker plywood model?"

+ +

CHRIS: Durability is really what it comes down to. We wanted something that felt like an object that you can have and treasure. Like, these have weight, you know, these feel like something, not just a piece of paper. This is something that you can have and [inaudible 28:22] your desk, and it's not going to fade in the sunlight. It's not going to disintegrate over time. This is something that's going to last.

+ +

MIKE: Yeah, the cards would definitely, like, as I would sort of carry them around and show them to people and stuff, the cards would start, you know, breaking. It's like having a business card in your pocket, right? Eventually, it's going to kind of wear out. And plus, we had, like, the stickers were visible on the back of them. And we were, like, having the sticker just completely disappear inside the wood it just feels a little bit more like magic.

+ +

LINDSEY: Well, thanks for demoing there. I put you on the spot a little bit. But they are...I had seen them in the Slack, and they're very cool [laughs]. So, I had to ask if we could show them off a bit.

+ +

MIKE: Of course.

+ +

CHRIS: I think another thing to think about, too, is we've been talking a lot about the user experience. But if and when we get to the point of making these for artists, artists will be able to collect so much data off of the way that people buy and collect and use these things over time, which is something that we're really, really excited about. And also, you know, we're working on a way to make the link in the object updatable over time. So, artists will be able to change what a card points do to inform their users about the latest and greatest thing.

+ +

LINDSEY: Very cool. Jordyn, what's next on the programming agenda for Chris and Mike?

+ +

JORDYN: It's really sort of we're in this, like, iterative cycle. So, we're talking to folks. We're working on the website. The conversations we're having with people are informing how we're framing this first experiment with the mixtape, how we're marketing it, who we're marketing it to. I think next up is probably a Google Ad experiment to really see if we can piggyback on some stuff or at least figure out a new consumer product. It's so tough, right?

+ +

It's also not a thing people are searching for. So, we have to come up with some experiments for how we get people to that website [laughs]. So, you know, Google Ads funnels is just something you kind of have to do because it's very interesting to figure out what people are responding to, what people are searching for. But we're going to have a bunch of other experiments as well and non-experiments. Outbound experiments: can we go to people? Can we get listed in a gift-buying guide for the holidays? Or, like, we don't know. There's a bunch of experiments we need to do around that, which is really just this iteration.

+ +

We won't stop talking to users but, you know, everything we're hearing from them will inform where we go and how we talk to the folks in those places where we end up. And really, it's just about starting...once this is up and, you know, there's, like, an orderable thing, there's, like, a whole data cycle where we start to learn from the stuff we're testing; we actually have some real data for it, and we can start to tweak, iterate and change our strategy.

+ +

But the bigger thing, also, is this bigger platform. So, the next thing really, the big next thing, is to sort of start to scope and create an architecture idea. What's it going to take to build the actual backend thing? And it's the thing that thoughtbot really [laughs] excels at, which is software. So, you know, that's the big next kind of project. Once the mixtape experiment is sort of out and in flight and we're getting data, we really need to turn our attention to the technical backend.

+ +

LINDSEY: Exciting. Another comment/question from Jeff, who maybe needs a user interview. "Love the crate more than the actual albums. Maybe offer collections of artists."

+ +

MIKE: Yeah, that's the plan.

+ +

CHRIS: Yeah, definitely. It's a good idea. Yeah, it's, I mean, and labels get to, especially, like, small indie labels get really excited about doing, like, crates worth of collections of different artists or, like, you know, digging through their back catalog, their subscription services. There's a lot of different angles for sure about that idea.

+ +

LINDSEY: [inaudible 31:55] Chris and Mike, going into this next section of the programming, for anyone watching right now, or watching the recording, or listening to the recording, any action items from them? You know, are you looking for any user interviews or have any survey or any destinations you'd like to send people yet?

+ +

CHRIS: Not quite yet, but soon, I would say. Well --

+ +

MIKE: I mean, [inaudible 32:19] plug the website, I mean, you know, I think we've got, like, an email to sign up from there, right? The URL is getthegoodz.com and I [crosstalk 32:27]

+ +

LINDSEY: Goodz with a Z.

+ +

MIKE: Goodz with a Z.

+ +

CHRIS: With Z.

+ +

MIKE: So yeah, if you want to go there, you can sign up. I think there's an email signup on there to learn more.

+ +

LINDSEY: Perfect. All right. getthegoodz.com email sign up. To stay up to date on Goodz and the incubator, you can follow along on the thoughtbot blog. You know, as always, send us any questions you might have, and we're happy to get to those. But otherwise, thanks for listening.

+ +

And thank you all — Jordyn, Chris, and Mike. Thanks so much for joining today and sharing and being open about your stories so far.

+ +

MIKE: Thank you.

+ +

CHRIS: Yeah, thank you, Lindsey.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+llgqR4_9 + + ]]> + + Lindsey Christensen + + + 502: OKRs and Business Coaching with Evan Hammer + https://podcast.thoughtbot.com/502 + 49dfece8-8f6a-4ea0-b849-0099a5cb14c6 + Thu, 30 Nov 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Today's conversation revolves around the importance and challenges of goal setting within organizations. It highlights how identifying and articulating real problems can be transformative, turning abstract desires for growth into concrete plans for improvement. Host Victoria Guido and special guest Evan Hammer discuss the nuances of leadership and organizational self-awareness, emphasizing the need for honesty and a growth mindset when addressing weaknesses. They touch on Evan's role as an OKR Coach in fostering alignment, focus, and excitement around goals, particularly in small to mid-sized companies. + +Evan shares his enthusiasm for goal setting and believes his passion can inspire others. He points out the positive outcomes when employees engage with goals that address problems they care about. Victoria and Evan agree that success is not solely measured by hitting OKRs but also by engagement and alignment within the team. They discuss the ideal organizations for Evan's work, which include small to medium-sized companies seeking to improve focus and alignment, as well as start-up teams needing more straightforward goal statements and go-to-market strategies. Evan also recounts his experience as a Techstars mentor, noting that a common issue across companies is the lack of clear goals, and he emphasizes the power of focus as a lever for growth. + 36:53 + no + + + Today's conversation revolves around the importance and challenges of goal setting within organizations. It highlights how identifying and articulating real problems can be transformative, turning abstract desires for growth into concrete plans for improvement. Host Victoria Guido and special guest Evan Hammer discuss the nuances of leadership and organizational self-awareness, emphasizing the need for honesty and a growth mindset when addressing weaknesses. They touch on Evan's role as an OKR Coach in fostering alignment, focus, and excitement around goals, particularly in small to mid-sized companies. +Evan shares his enthusiasm for goal setting and believes his passion can inspire others. He points out the positive outcomes when employees engage with goals that address problems they care about. Victoria and Evan agree that success is not solely measured by hitting OKRs but also by engagement and alignment within the team. They discuss the ideal organizations for Evan's work, which include small to medium-sized companies seeking to improve focus and alignment, as well as start-up teams needing more straightforward goal statements and go-to-market strategies. Evan also recounts his experience as a Techstars mentor, noting that a common issue across companies is the lack of clear goals, and he emphasizes the power of focus as a lever for growth. +Follow Evan Hammer on LinkedIn (https://www.linkedin.com/in/evanhammer/) or X (https://twitter.com/evanhammer). Visit his website at evanhammer.com (https://evanhammer.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Evan Hammer, OKR and personal goals coach. Evan, thank you for joining us. +EVAN: Thank you for having me. I'm excited to be here. +VICTORIA: Wonderful. Me too. And I wanted to ask you first, before we dive into business, tell me a personal goal that you've achieved recently that you're most proud of. +EVAN: I guess a couple of months ago, I did a 100-mile loop of Mount Rainier. So, it was a 10-day backpacking trip. My younger brother, I went with him, and it's the kind of thing he does more regularly. Yeah, it was something I was kind of excited to do but really unsure of, and worked super hard between the gear and the training and just, like, the mindset. But it was also just awesome being out in the woods for ten days. +VICTORIA: I also love being out in the woods for long periods of time. I guess, like, how long did your brother plan this trip for? And how long were you involved before you decided to go? +EVAN: You know, it was something he was planning to do since the spring. He won a lottery to be able to do it. And I was going back and forth for a few months. And I think it was just maybe in the end of June where I was like, okay, I'm doing this. I need to put together a gear list, figure out a training plan. I live in Fort Greene in Brooklyn. And it was a lot of, like, waking up early and going up and down the steps in Fort Greene Park, which is, like, you know, 6, 10 flights of steps, something like that outdoors -- +VICTORIA: [laughs] +EVAN: With a heavy backpack on for two to three hours, like on weekends. +VICTORIA: Oooh. Wow. +EVAN: Yeah, it was one of those things I was like, you know, you don't know when you do something like this how it's going to go until you're there doing it or how your body is going to respond. So, it was a little bit of, like, trying to train as much as possible but also being aware that I just have to deal with whatever will happen on the trip. +VICTORIA: I love that, at first, it sounds sort of, like, fun. Like, "Oh, do you want to go on this trip with me?" And you're like, "Yeah, okay." And then you look at the training plan, and it's like, "We'll wake up at 6:00 a.m. every day and walk up and down ten flights of stairs [laughs] with a heavy backpack on," you know, like, "Oh okay, [laughs] a lot of prep work to have this trip." [laughs] +EVAN: It's fun in that you're doing something amazing, and it's beautiful. And it was just one of the more beautiful places I've ever been. It was really interesting and meaningful to me to kind of be detached from everything that I normally do and just focus on being in the woods and hiking these mountains. But yeah, you don't know how it's going to go. So, it's like you're putting yourself in an extreme physical situation. I think that's anxiety-inducing, and it feels good and is healthy and protective to train for it. +VICTORIA: I agree. Yeah, I mean, I totally relate to that. I'm a rock climber and hiker myself. And sometimes I spend all this time, you know, on gym memberships, climbing in the gym, running up and down hills. And then, I get all the way out to rock, and I'm about to start my climb, and I'm like, why am I doing this? [laughs] This is a lot of work to get to this point. But then it is all fun, and it's super worth it. And I always feel restored whenever I come back from being a long time in nature. It's really great. +I think maybe to get towards, like, a metrics conversation that we talk about a lot in climbing is the type of fun something is. So, there's three types of fun levels. Have you heard this framework before, Evan? +EVAN: I have not. +VICTORIA: Okay, so there's three levels of fun. Level one fun is, like, you're having fun while you're doing it. We're, like, laughing and enjoying recording a podcast together. Like, oh my God, it's so much fun, super easy, not stressful. Maybe it was a little stressful for you, I don't know. [chuckles] It's a little stressful for me. +Level two fun is it's a little difficult while you're doing it, but you're still looking back on it and having fun, but you're never really in any kind of intense danger, right? Like, you're going on a backpacking trip. It's relatively within your health expectations, and the trail is walkable. You're not, like, going to fumble and fall down a cliff. It's level-two fun. So, you're mostly enjoying it. Like, it's kind of difficult, and there's some effort involved, but it's still fun. +Level three fun is when it's very dangerous, and you're really scared the whole time [laughs], and, like, you maybe, like, could have died. But looking back on it, it's fun. So, how would you rate your Mount Rainier trip? +EVAN: It's funny because we actually...we didn't come up with the levels, but we spoke about how when you're hiking, often, in your head, you're just trying to figure out how much longer you have to hike as if the whole point was not to be hiking. And then you finish hiking for the day, and you're like, "Oh, that was so great. I'm so looking forward to waking up tomorrow and hiking some more." +VICTORIA: Yeah [chuckles], exactly. +EVAN: That fits the level two fun pretty explicitly. +VICTORIA: That's great. Yeah, it's a very, you know, I've found it to be pretty useful. And, you know, as I get older, I tend to try to avoid level three fun more often [laughs]. Like, I don't really need to be frightened [laughs]. I have enough stress in my life. I don't need to also endanger myself too aggressively. +But, you know, everyone has their own risk level as well, right? Like, someone else might think the type of climbing and hiking that I'm doing is level three fun, but, for me, it's more...and, like, there's other things like skateboarding and riding a bike where, for me, is level three. I'm scared and [laughs] -- +EVAN: Right. And I think you also frame level three as, like, sort of physical safety. But, you know, people have different risk tolerances and classifications across the board. So, like, for me, I try to stay away from things that I would consider physically dangerous. But I'm very comfortable, like, taking financial or social risk, where I know other people have an inverted kind of spectrum where, like, social risk is, like [laughs], you know, is a terror to them when physical risk doesn't seem that scary to them, you know, so... +VICTORIA: That's so interesting. And especially for me, I do a lot of networking. And I'm, of course, been really active in San Diego Startup Week this week. We're recording this in October. So, for some people, going to an event where there's going to be hundreds of people, you maybe have met some of them before, but you really don't have a buddy that you are coming to this event with. You're on your own. You're going to have to walk up to people, start conversations, figure out who is who, and, like, find your people. That's terrifying for a lot of people. And they're like, "Absolutely not." [laughs] +EVAN: Well, it's interesting how, like, level one and level three can be inverted. I went to a conference last fall by myself, and I actually had some voice issues. So, I couldn't talk for a little bit before this, so it was like...or even that well, during, you know, it was kind of an environment that I think a lot of people might be feeling like, oh, that's level three social experience. And I just remember how much fun I had there. Like, for me, it was totally a level one thing. But, you know, there's definitely moments on this hike where I was like, oh, this is level three. This feels physically scary, even though most of the time it wasn't. +VICTORIA: Yeah, no, I think it's helpful. So, maybe that helps us segue a little bit into telling me more about what you do and how you came to do what you do. What's your background? +EVAN: What do I do? I'll give you, like, a list of the things that I do. I will say I help people focus and maybe communicate better. You know, the list is, like, I am an OKR coach, right? That's objectives and key results, coaching business leaders on how to set goals and get everybody aligned towards the same goals. I do personal goals coaching, and that's, like, helping individual people set goals that are meaningful to them and live more intentionally. I'm a Techstars mentor, where I mentor companies. And I also do, like, a fractional head of product role. +And it's a little all over the place. I mean, it's something that, obviously, a lot of that is, like, business coaching but really focused around focus and how you can use goal setting to accelerate growth for a business or an organization or for yourself personally. +VICTORIA: How did it get started? What led you to be the coach that you are today? +EVAN: Yeah, you know, I get asked this question. And I feel like there's a story about how I kind of tested goal setting. I was a founder. I went to Techstars in, like, 2013. And I was running the company. So, I had to, like, mess around with goal setting and then ended up being at Codecademy and Vimeo. They were doing OKRs. And there were certain things I liked and certain things I didn't. And there was, like, this progression. +But I think the truth is that I just really like systems and organizing things, and I think I've always been like that. And OKRs are a way of taking something that's really messy, which is, like, a group of people running together in some direction and saying, "Oh, well, what if we come up with, like, some agreed plan here, and some rules, and some guidance? And we can split this out between what, like, the company and the organization is doing versus what individual people are doing or what the department's doing." +I think I just find that process comforting. It's just, like, gleeful for me to be working with people on how they're going to focus and organize themselves, and then also how they're going to communicate that focus to each other, which I think is, like, a key part of people staying on the same page. +VICTORIA: I love that. And I really want to dig into some examples of OKRs and maybe even get some free OKR coaching for myself on this episode. But, you know, but with your background, I wanted to start with looking at the founder experience versus being someone in a larger organization. How do you bring in that context of where you are in your journey into how you think about setting goals for an individual? +EVAN: I think it's a hard question for me because my viewpoint on how goal setting and strategy and achievement in organizations has changed over this whole time, right? So, I was a founder, then at these larger organizations. I think I've tried to synthesize some, like, through line rather than difference between them. So, let me start there. +I think when you look at a founder, or a founding team, or a larger organization, the key thing to figure out is where you're going and coming up with really clear goals. And then, depending on the size of the organization, there's different tactics you can use, right? So, if you're a founder, it might be just sitting down with your co-founders once a week, having a clear Northstar metric, and having a clear goal, and then everybody's running, and that works. +Zoom to a 100-person company, which is, like, I probably focus on, like, 20 to 100-person companies. And now you have a lot of confusion between departments because you have people who are working on very different parts of the business. So, I think OKRs, at that point, are really great because it is this, like...and we will talk more about OKRs. But it's this cascading goal-setting technique where you have company goals that everybody understands and agrees to, and then each department is carving out how they're going to support that, which is, like, less necessary for a small company. +But I still think the key thing is to know what you want, what your biggest problem is in getting there, and what your approach is going to be in overcoming that problem, which is, you know, is, like, I guess, strategy 101. +VICTORIA: I like that. And it's funny; it makes me think of a tarot card layout. That's a situation I'll come and approach. Anyways, I wanted to get, like, down to the basics. I think we said OKRs earlier, but what is an OKR, if you can define that? +EVAN: Yeah, so objectives and key results. An objective is any goal you have, so that can be launch a feature, revamp your sales process, or achieve some sort of milestone or some capability, right? So, often, that's, like, build a new department, or come up not just with a specific feature but a new offering, like launch a whole product line. Anything that's important to you can be a goal. It should be clear and inspiring. And that's the objective piece. +Key results answer the question: how will you know if you're successful in reaching that goal? That might be if you're building a new department, a certain number of hires. If you're launching a feature or want to have a new offering, that might be some KPI for the product team, like, you know, onboarding rates or retention rates. +VICTORIA: Yeah, and let's maybe even go into a real example: myself, I'm a managing director here at thoughtbot. People who aren't familiar with thoughtbot...I'm sure everyone listening has [laughs] familiarity with what we do as a product and business consultancy. And our team at Mission Control, the goal was to innovate on our approach to how we were deploying and managing software. +So, over 20 years, the trends and modernization of infrastructure was something we wanted to be a part of, and we wanted to enable and accelerate not just our own development teams but our clients' teams in deploying software securely and efficiently and meeting everything that we need to do. Like, it's an incredibly complex environment. And there's lots of choices to make. So, that's, like, the big vision of what we're trying to do at thoughtbot. It's a new service. It's touching not only our internal processes but also, like, the growth of our business overall. +So, what I've done as a managing director I talk with my team. I work with the CTO of thoughtbot, Joe Ferris. He's my acting director [chuckles] on identifying what is our overall approach? What's our strategy? So, one of the things we do at thoughtbot, one of our strategies, is to put content out there. So, we want to build stuff that works for us, and we want to share and talk about it. +And we believe that by putting good stuff out there, good stuff will come back to us [laughs]. So, really just increasing the amount of blog posts, increasing the amount of open-source contributions and [inaudible 13:03] people we talk to and hear about what their problems are. We think that that will be an indicator for us of whether or not we're being successful in growing this business. So, that's just, like, one small strategy, but I've got five other ones if you want to talk about them. +EVAN: Yeah, I mean, you highlighted a large goal that you have, and then some of the, like, sub-objectives in reaching that goal. And you could imagine key results being metrics along number of blog posts, audience size, number of readers, engagement. I mean, all those have different values, depending on what your goals are. +VICTORIA: Exactly right. Like, there's the overall leading indicators we have of, like, whether or not we're successful as a business [laughs], which is, like, revenue, and, like, margins of profit, which really aren't going to change. And as a company, we don't change our policies or things that often to where those costs are ultimately going to change. It's all about, like, are we bringing in new business? Are we retaining the clients we have? And are we able to sustain, you know, work that centers around this problem area? +So, that kind of, like, makes our goal tracking, like, the numbers month to month somewhat easy. Although those individual strategies and how they all line up to meet, that is something I think I'm curious to hear about how you facilitate those discussions with teams. How would you, like, begin an engagement with a team where you have a company like thoughtbot [laughs]? How are you going to coach us to get better at our goals? +EVAN: Well, one thing I do is I pull apart KPIs, Key Performance Indicators, from OKRs, which you actually implied. KPIs are metrics you use to judge the health of your business, when OKRs are the goals that are going to transform your business. They fit well together. But, you know, for a founding team, they're still trying to figure out, well, how do we actually measure if this is going well? What does that mean? And I have a whole technique for that. +But for a larger company, something like thoughtbot, you probably have pretty clear KPIs for the business and for each department. And you can look each month to make sure that those are in a healthy band or each week. And then, when you go to set goals, one of the things you can say is, "Hey, what's not working well? Why are the KPIs not where they should be?" And there's other ways of coming up with good goals, but I do think that's one of the starting points for goal setting. +Another one, and I'm curious if you all have this here, is, like, a sense of what's holding back your growth. So, if you have a clear goal of growing your business year over year; usually, people in different departments have a sense of what challenges they're facing in executing towards those growth goals. And, fundamentally, there's usually some sort of competitive or market conditions or customer conditions that are concerning to you as a business in terms of where you're currently at. So, do you all have that type of, I guess, angle on thoughtbot's growth at all? +VICTORIA: You know, for me, it's my first year as managing director. And experiencing how thoughtbot does planning, I appreciated our approach this year was to ask each managing director more like a retro style, like, "What should we do more of? What do we like doing? What didn't really work, and what should we do less of? And what other things do we want to start doing?" +So, it's kind of similar to start, stop, continue but, you know, just really reflecting on, like, what's working? What should we do more of? What doesn't work, and we should just stop [laughs], or change, or figure out how to improve? And then, what should we start doing? And what kind of new behaviors do we need to practice and learn to build a better system? +Which I think when you talk about what's holding people back, I think it's difficult to understand in a complex organization of 100 people how all these departments work together and how they contribute and support teams. So, I'm curious, from your experience, and you like to come in and organize and get focused, so if you have that level of complexity in an organization, how do you start to get people organized and understanding how they all work together and what's working and what's not? +EVAN: Yeah, that's a good question. I might punt that to the second half of my answer here and answer an earlier question [inaudible 17:08] how we get started. Because I think that actually comes up as, like, the second piece. I think the first piece is, like, when I start with an organization, I usually sit down with the CEO. Maybe there's a founding team. Maybe it's a leadership team. +And I try to understand their vision for where the company's going and, one, how clear and actionable it is. So, does it feel like, oh, I get exactly how they're going from point A to point B to point C, or is it a little bit murkier? And trying to nail that down. And sometimes I do, like, a strategy workshop around that. +But the next piece is understanding if they have a clear plan for the next quarter, next year. When I come into companies, I'm doing OKRs quarterly. So, even if they don't have a clear strategy, we still need to set goals for the next quarter. I then have them just kind of draft goals with not that much guidance here. I might do some sort of training so everybody, like, understands what OKRs are. And then, you know, I do...and this is a common thing, I think, like, my background is in product, is trying to understand the root cause of things. +So, usually, there's some goal that I can ask. And, usually, there's a goal that's, like, something that seems very strategic, like a new offering, or changing how the business is organized, or it's very growth revenue-oriented. Those are, like, the two types of goals that people usually come up with. +So, there's a lot of just, like, asking why this is valuable, and kind of going up the ladder, down the ladder asking why it's valuable, and understanding what their root motivation is for doing this. And then going the other direction and saying, "Oh, if we did this, then what would happen?" And trying to just understand how they're thinking of this goal and how it fits in a longer chain of events. +And, usually, through that process, we shift the focus point. So, it's rare that somebody comes up with, like, exactly the right goal. I think when they start understanding what would the effect be of that goal, sometimes one of those things is the actual goal. Or if there's a root cause, it doesn't always mean that we go to the root cause, right? +If somebody wants to, like, fix their onboarding, and that's really, like, their whole focus point, you know, when you say, "Why?" and they talk about helping a certain customer get more focused. And then you may say, "Well, why?" And they say, "Oh, well, you know, we have this revenue model that involves helping them, and we make money." And "Why?" "So we can grow our business at a certain clip." And that's the arc that we build. +That doesn't mean we go to, oh, well, you're trying to make more money faster. That might not be really what the focus should be for the quarter. So, we have to always start just trying to, like, dial in with what the right angle is. That's both...I think you want to choose the thing that's the most fundamental to the business that still feels attainable and focusable, if that's a word, in the short term, right? That's like, oh, this is a good target for a quarter or a year, if you're doing it on an annual basis. +So, that's, like, how I usually get started with folks, which, you know, depending on how much thought there is around strategy, like, it goes in different ways. Sometimes, the company has a very, like, clear strategy, and then everything I said works pretty smoothly. And you get to a goal very quickly that you kind of orient the company around. +If the strategy is either not explicit or maybe the CEO has a different vision for it than, you know, CTO or the head of sales, then there's more negotiating between folks and getting on the same page. And I think that's a whole, like, can of worms that we can dive into, but that's, like, a different type of exploration. +VICTORIA: Yes, I love all that. I have so many follow-up things I want to ask. Just to play it back a little bit, too, I really resonated with some of what you're saying around it's kind of better to draft it; just write it. Like, the act of planning is more valuable than the plan itself. Like, get as close as you can as fast as you can [laughs]. That makes sense. Like, something that feels, like, good enough and, like, kind of go with it and, like, see how it goes. +You know, like, I think that's a mindset that can be difficult to implement in an organization, especially if there's been, like, past trauma with, like, not meeting your goals. And how does that flow down to the organization? +EVAN: That's a hard thing. +VICTORIA: And it makes me think of, like, what you started with, like, talking about getting to the root of what's happening. Like, what are the motivations of individual people? Like, what's happened in the past? Like, trying to take an approach that's...I prefer blame-aware to blameless. You can't get away from the tendency to blame people. So, you just have to accept that that happens and kind of move on and, like, quickly go past it [laughs] and just, like, really get to, like, what are the facts? What does the data say about this organization? So, anyways, I think that that was where I went to. I think -- +EVAN: One thing I did...I started with a new company; I guess, two or three quarters ago around the OKR coaching. And, you know, I think there was this expectation. We've been doing OKRs. There's issues we need you to come in and solve and fix everything. And the tone I tried to set was, hey, I'm not here to set great goals for you. You're going to set the best goals you can. And I'm here to help support that process and teach you a lot about goal setting. +And we're going to do this every quarter. And after two or three quarters, things are going to start becoming a lot easier. People are going to communicate better. Everybody's going to be on the same page. And it's going to feel like, oh, we're getting really good at goal setting. +And then, like, I try to set that tone when I start working with the CEO of, like, the point here is to make your whole leadership team good at goal setting so that you have this skill as an organization, rather than set just the right goals with the right language in the right way right now, right? We want to timebox everything. So, we're moving forward using this tool to make progress throughout the quarter, and then each quarter, revisiting it and getting better. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +VICTORIA: And I'm curious if there's anything else when you're evaluating whether or not someone might be a good fit for the work that you want to do with them. Are there, like, some red flag, green flag energy that you check for with executives when you're deciding whether or not to work with them? +EVAN: Yeah, there are two flags that come up; one is, are they clear with what they're saying? I think a lot of leaders want to sound good. So, that doesn't mean that they need to be clear right off the bat. But in a conversation where someone says, "This is our vision," and you say, "Hey, I don't understand X, Y, and Z," or "This part didn't make sense to me. Can we dive into it?" +And yeah, if someone through a conversation can be really clear about what's important to the company and where they're going, I think that's, like, key. Because if someone's talking around issues all the time and when you kind of bring up things they don't really address it, it's very hard to make any progress. It's like, you know, the lack of specificity ends up being a defense towards maybe dealing with some of the difficult conversations. +But, like, at the end of the day, like, one of the major things that happens with goal setting that makes it, I think, feel exciting to people when it does—it always feels exciting to me [laughs]—when it feels exciting to other people is that they say, for the first time, "Oh, this is actually the thing holding us back. This is the problem. Yeah, we want to grow our business." +But when you say, "Well, what are all the things you do to grow your business?" All of a sudden, you start talking through things, and someone says, "Hey, this is the real problem. This is why we're struggling to grow our business." And, you know, that transforms the conversation. People who are avoiding being specific, that can be really hard. That's one thing. +And the other thing is around responding to feedback. And, you know, you can just...and this is a common interview question, right? You can ask somebody, "What do you think the weaknesses of your organization are?" And if somebody doesn't know, but they're, like, open to it, that's, I think, totally fine. But if it seems like they're constantly kind of, like, filibustering the answer there, it's like, hey, the main thing you're bringing me on to do is to make sure that you communicate the weaknesses of your organization to everybody else because that's what goals are about. They're about overcoming the weaknesses of your organization. +So, those are two areas. And they also speak to, like, I think, rapport with the people that I'll be working with. +VICTORIA: I agree. And I like that, you know, you're asking really for people, are you going to be honest about what's happening in your organization? Are you honest with yourself about where you're not doing well? And I think I also pay attention to the language people use to describe those problems. And are they really speaking with a growth mindset or a fixed mindset? Because that's a really hard thing to change [laughs]. Naturally, I think people who are good leaders and run successful companies have a growth mindset. So, I think that's usually there. But that would be some yellow-flag stuff for me. +EVAN: You know, when people are looking to hire an OKR coach, they usually already are looking for improvement. And it's not like they're hiring a product manager, right? You have to be saying to yourself, hey, I believe that if we did better around goals, our company would grow better. We'd have better focus. We'd have better alignment. Like, there's already a belief that people have that is usually pretty self-aware of the limits of both the people there and the organization where it's at today, and they're looking for help. +So, I think I come across what you brought up more in individual people on a leadership team that, like, feel more coachable or less coachable depending on how interested they are around expanding how they think about things and growing. And, you know, obviously, [inaudible 27:01] lots of opinions that are wrong, and I love the disagreement that comes up there. But you want to, you know, you want to be speaking to people that are generally open to learning through a conversational process. +VICTORIA: Right. Yeah, I think it's like a confirming thing. Like, if they're reaching out to a goals coach, they probably do have a growth mindset. And if the top leadership does, then that means that there's an opportunity for other people to come along as well. So, I like opening it up that way and getting people to get specific about their goals as well. I think that's a real challenge. Like, it's either too vague or too specific, not inspiring enough. +Some people still bring up SMART goals with me. I like to prefer HARD goals, but you probably need those. And I'm curious if you're familiar with those acronyms. I can spell them out. And I'm sure you've heard of both of these [laughs]. A lot of people are familiar with the SMART goals and the specific, measurable, actionable. I forget what the Rs and Ts are. +But then HARD goals are heartfelt and more around, like, the big vision. And it's something that you want to get people excited about, which is something that you said earlier. Like, how do you get people excited? And some people would think of a corporate goal-setting event as a level three fun [laughter]. So, how do you make it more like a two or a one? +EVAN: I don't know, a lot of what I hope I offer to folks...and I've gotten good feedback here is that I enjoy goal setting a lot. So, talking through all these problems, talking through challenges, doing workshops, having these conversations. Like, whenever I'm doing that, it's my favorite thing to be doing. So, I think, hopefully, some of my joy just rubs off on the people around me. Because I do think talking to somebody who's excited about what you're talking about is helpful. +The other thing is, usually, at a decently small company, under 100 people, I'm working with the CEO and the leadership team; you know, people are there because they care about the company. They care about the mission of the company. They care about the people in the company, and they care about the growth of the company. +So, I get why goal setting has, I think, can have a bad rap. But if you're fundamentally solving problems that people care about, there should be some, like, glee that comes in when people say, like, "Oh, yeah, I thought this was going to be about, like, how do we grow more? And that felt very generic to me." And it turns out when we actually think about how we grow more, and we talk through what's holding back our growth and what we can do to overcome that, and we have the top few ideas that we've all come up with, usually, those feel really relieving to people. +And there's a company I'm working with now that I think is struggling to shift their target market a bit because...and there's awareness that the target market needs to shift, but there isn't so much knowledge around the new target market. There's a lot more knowledge around the old target market. And so, we're doing a bunch of research and talking to folks. +And I know once we're able to say, "For this target market, we need to do X," there is going to be, like, a huge amount of excitement and relief at the organization because people will feel like, oh, we've crossed that bridge, that bridge that we were kind of in the middle of crossing and didn't really know where the other side was. We now can see that other side, and we're going there. So yeah, I think there can be a lot of excitement around this stuff when it's real, and it's important work that you're doing. +VICTORIA: Right. Like, maybe there's a good factor of, like, how do you measure if what you've done with a company is successful? Is there a glee scale that you [laughs] use to evaluate? +EVAN: You know, for me, it's still probably more subjective than I want it to be. You know, I'd love it to be like, what percentage of people's OKRs did I [laughs] hit each quarter? And when I work with them, it gets better. But I think that's, like, a pretty short-sighted view in terms of my role. So, you know, I'm looking for people who were maybe disengaged to be more engaged, people who didn't see the value of OKRs to see and be able to articulate how their daily work is different because of the OKRs we set. +Yeah, and obviously, there's excitement when we're solving real problems. And we're changing the problems each quarter, and people are seeing growth increase. You know, like, all that stuff, I guess there's, like, a tangible excitement with. But I hope folks can, like, just connect the dots between the work, which can be tedious work around goal setting and negotiating with people. And often, it pulls you out of other day-to-day work that you're doing, especially for a small company, with the excitement towards the end of the quarter of reaching these goals and moving on to the next challenge. +VICTORIA: I think that's great. I think that was a perfect answer. It's kind of not always easy to know what [laughs]...like, sometimes there's a sense of it, like, you have a feeling, and sometimes you can get data to back that up. And other times, you know you're doing the right thing by the people's faces around you at the end of the workshop [laughs]. So, I think that's great. And so, maybe my final question would be is, like, what would be the ideal organization that you would want to work with? Like, who's your ideal customer right now? +EVAN: Yeah, I guess I have two ideal customers based on these, like, two things that I'm doing. In terms of the OKR coaching, I usually look for CEO or founding team of a company that's now, like, 20-plus people who's saying, "Oh, we have these departments," or "We have this leadership team. And we need to really get all on the same page at the beginning of the quarter because then everybody's going to consistently be talking to each other but has other people that they need to organize." That's definitely for the OKR coaching where, like, 20 to 30 people is where that starts. That probably goes up to 100 in terms of where I focus. +For the other work I do as a Techstars mentor and the coaching I do through that, that's really for founding teams. And that's more focused on how do you take your vision and make that a clear goal statement, which is around, like, behavior change, usually, in a certain population you're targeting? How do you turn that into a go-to-market plan? How do you turn that into a product roadmap? So, for that, that's just much smaller teams. +I actually think that work often needs to be done at larger organizations, too. That's, like, a common thing that comes up. And that can bleed into strategy at large organizations. But yeah, I know that's probably a pretty broad bucket, but groups of people that believe that focus is a key lever towards faster growth. +VICTORIA: Thank you for that. And I guess I said that was my final question, but I'll add two more questions. Can you share an anecdote from being a mentor at Techstars that you think will be interesting for our audience? +EVAN: I think I was struck the first time I did the mentoring. They do, like, a Mentor Madness. So, it's like, you know, six companies in a row, and every company they all have different challenges. But a lot of them, it's, like, helping them articulate what they're doing a little bit more clearly. And often, there's a question around sales and growth and maybe fundraising. So, there's just, like, a focus in that direction. And I found that every company, even though they had kind of different questions, I was giving the same answer to, which was, I don't think your goal is clear to you or to me. +And so, there's this framework that I would use with each company that there was, like, this aha moment. And I picked this up from a person named Matt Wallaert. It was a book, "Start at the End." It's called a behavioral statement. And it's when population wants to motivation, and they have limitations, they do behavior as measured by data. And the kind of conceptual version is, oh, you're trying to get some group of people to change their behavior. And that's only going to happen if you can tap into a motivation that happens to them as frequently as the behavior you want to change. So, it's like a formalization of that. +And each group, I'd like bring up the statement; we work on filling it quickly. And there was just, like, a clarity that would develop around what they were doing and how to orient themselves both on the growth and marketing side and on the product development side. I guess it just struck me how much that little framing was transformative to [laughs] accelerating both focus and alignment but, more importantly, like, getting somewhere that they wanted to get to. +VICTORIA: It sounds almost like building a mental model of what you're trying to do [laughs], right? Like, it was a mental model that you referenced in your mind that helps you make decisions every single day. So, I really appreciate that. And we are about out of time. So, let me ask you, is there anything else that you would like to promote today? +EVAN: Sure. Looking for a couple more OKR coaching clients for the new year, and just happy to chat with anybody who has questions around OKRs or goal setting for their organization. +I also do personal goals coaching, which is a little different from the OKR coaching that I help individual people with their goals. But it's also similar. It's a lot of like...it's a lot more, like, reflection, and getting to know oneself, and coming up with goals that are really meaningful. +And then the other half of, like, I think you alluded to this earlier around systems. Like, how do you take a goal that's important to you and actually act every day in ways that move you towards that goal? So yeah, interested in talking to people about both of those. I do some workshops as well, so people can reach out to me at evan@evanhammer.com. I can also put anybody on my mailing list. I do some workshops around both those things. +VICTORIA: Wonderful. Thank you so much, Evan, for joining us today. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thank you for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Evan Hammer. + + + Today's conversation revolves around the importance and challenges of goal setting within organizations. It highlights how identifying and articulating real problems can be transformative, turning abstract desires for growth into concrete plans for improvement. Host Victoria Guido and special guest Evan Hammer discuss the nuances of leadership and organizational self-awareness, emphasizing the need for honesty and a growth mindset when addressing weaknesses. They touch on Evan's role as an OKR Coach in fostering alignment, focus, and excitement around goals, particularly in small to mid-sized companies.

+ +

Evan shares his enthusiasm for goal setting and believes his passion can inspire others. He points out the positive outcomes when employees engage with goals that address problems they care about. Victoria and Evan agree that success is not solely measured by hitting OKRs but also by engagement and alignment within the team. They discuss the ideal organizations for Evan's work, which include small to medium-sized companies seeking to improve focus and alignment, as well as start-up teams needing more straightforward goal statements and go-to-market strategies. Evan also recounts his experience as a Techstars mentor, noting that a common issue across companies is the lack of clear goals, and he emphasizes the power of focus as a lever for growth.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Evan Hammer, OKR and personal goals coach. Evan, thank you for joining us.

+ +

EVAN: Thank you for having me. I'm excited to be here.

+ +

VICTORIA: Wonderful. Me too. And I wanted to ask you first, before we dive into business, tell me a personal goal that you've achieved recently that you're most proud of.

+ +

EVAN: I guess a couple of months ago, I did a 100-mile loop of Mount Rainier. So, it was a 10-day backpacking trip. My younger brother, I went with him, and it's the kind of thing he does more regularly. Yeah, it was something I was kind of excited to do but really unsure of, and worked super hard between the gear and the training and just, like, the mindset. But it was also just awesome being out in the woods for ten days.

+ +

VICTORIA: I also love being out in the woods for long periods of time. I guess, like, how long did your brother plan this trip for? And how long were you involved before you decided to go?

+ +

EVAN: You know, it was something he was planning to do since the spring. He won a lottery to be able to do it. And I was going back and forth for a few months. And I think it was just maybe in the end of June where I was like, okay, I'm doing this. I need to put together a gear list, figure out a training plan. I live in Fort Greene in Brooklyn. And it was a lot of, like, waking up early and going up and down the steps in Fort Greene Park, which is, like, you know, 6, 10 flights of steps, something like that outdoors --

+ +

VICTORIA: [laughs]

+ +

EVAN: With a heavy backpack on for two to three hours, like on weekends.

+ +

VICTORIA: Oooh. Wow.

+ +

EVAN: Yeah, it was one of those things I was like, you know, you don't know when you do something like this how it's going to go until you're there doing it or how your body is going to respond. So, it was a little bit of, like, trying to train as much as possible but also being aware that I just have to deal with whatever will happen on the trip.

+ +

VICTORIA: I love that, at first, it sounds sort of, like, fun. Like, "Oh, do you want to go on this trip with me?" And you're like, "Yeah, okay." And then you look at the training plan, and it's like, "We'll wake up at 6:00 a.m. every day and walk up and down ten flights of stairs [laughs] with a heavy backpack on," you know, like, "Oh okay, [laughs] a lot of prep work to have this trip." [laughs]

+ +

EVAN: It's fun in that you're doing something amazing, and it's beautiful. And it was just one of the more beautiful places I've ever been. It was really interesting and meaningful to me to kind of be detached from everything that I normally do and just focus on being in the woods and hiking these mountains. But yeah, you don't know how it's going to go. So, it's like you're putting yourself in an extreme physical situation. I think that's anxiety-inducing, and it feels good and is healthy and protective to train for it.

+ +

VICTORIA: I agree. Yeah, I mean, I totally relate to that. I'm a rock climber and hiker myself. And sometimes I spend all this time, you know, on gym memberships, climbing in the gym, running up and down hills. And then, I get all the way out to rock, and I'm about to start my climb, and I'm like, why am I doing this? [laughs] This is a lot of work to get to this point. But then it is all fun, and it's super worth it. And I always feel restored whenever I come back from being a long time in nature. It's really great.

+ +

I think maybe to get towards, like, a metrics conversation that we talk about a lot in climbing is the type of fun something is. So, there's three types of fun levels. Have you heard this framework before, Evan?

+ +

EVAN: I have not.

+ +

VICTORIA: Okay, so there's three levels of fun. Level one fun is, like, you're having fun while you're doing it. We're, like, laughing and enjoying recording a podcast together. Like, oh my God, it's so much fun, super easy, not stressful. Maybe it was a little stressful for you, I don't know. [chuckles] It's a little stressful for me.

+ +

Level two fun is it's a little difficult while you're doing it, but you're still looking back on it and having fun, but you're never really in any kind of intense danger, right? Like, you're going on a backpacking trip. It's relatively within your health expectations, and the trail is walkable. You're not, like, going to fumble and fall down a cliff. It's level-two fun. So, you're mostly enjoying it. Like, it's kind of difficult, and there's some effort involved, but it's still fun.

+ +

Level three fun is when it's very dangerous, and you're really scared the whole time [laughs], and, like, you maybe, like, could have died. But looking back on it, it's fun. So, how would you rate your Mount Rainier trip?

+ +

EVAN: It's funny because we actually...we didn't come up with the levels, but we spoke about how when you're hiking, often, in your head, you're just trying to figure out how much longer you have to hike as if the whole point was not to be hiking. And then you finish hiking for the day, and you're like, "Oh, that was so great. I'm so looking forward to waking up tomorrow and hiking some more."

+ +

VICTORIA: Yeah [chuckles], exactly.

+ +

EVAN: That fits the level two fun pretty explicitly.

+ +

VICTORIA: That's great. Yeah, it's a very, you know, I've found it to be pretty useful. And, you know, as I get older, I tend to try to avoid level three fun more often [laughs]. Like, I don't really need to be frightened [laughs]. I have enough stress in my life. I don't need to also endanger myself too aggressively.

+ +

But, you know, everyone has their own risk level as well, right? Like, someone else might think the type of climbing and hiking that I'm doing is level three fun, but, for me, it's more...and, like, there's other things like skateboarding and riding a bike where, for me, is level three. I'm scared and [laughs] --

+ +

EVAN: Right. And I think you also frame level three as, like, sort of physical safety. But, you know, people have different risk tolerances and classifications across the board. So, like, for me, I try to stay away from things that I would consider physically dangerous. But I'm very comfortable, like, taking financial or social risk, where I know other people have an inverted kind of spectrum where, like, social risk is, like [laughs], you know, is a terror to them when physical risk doesn't seem that scary to them, you know, so...

+ +

VICTORIA: That's so interesting. And especially for me, I do a lot of networking. And I'm, of course, been really active in San Diego Startup Week this week. We're recording this in October. So, for some people, going to an event where there's going to be hundreds of people, you maybe have met some of them before, but you really don't have a buddy that you are coming to this event with. You're on your own. You're going to have to walk up to people, start conversations, figure out who is who, and, like, find your people. That's terrifying for a lot of people. And they're like, "Absolutely not." [laughs]

+ +

EVAN: Well, it's interesting how, like, level one and level three can be inverted. I went to a conference last fall by myself, and I actually had some voice issues. So, I couldn't talk for a little bit before this, so it was like...or even that well, during, you know, it was kind of an environment that I think a lot of people might be feeling like, oh, that's level three social experience. And I just remember how much fun I had there. Like, for me, it was totally a level one thing. But, you know, there's definitely moments on this hike where I was like, oh, this is level three. This feels physically scary, even though most of the time it wasn't.

+ +

VICTORIA: Yeah, no, I think it's helpful. So, maybe that helps us segue a little bit into telling me more about what you do and how you came to do what you do. What's your background?

+ +

EVAN: What do I do? I'll give you, like, a list of the things that I do. I will say I help people focus and maybe communicate better. You know, the list is, like, I am an OKR coach, right? That's objectives and key results, coaching business leaders on how to set goals and get everybody aligned towards the same goals. I do personal goals coaching, and that's, like, helping individual people set goals that are meaningful to them and live more intentionally. I'm a Techstars mentor, where I mentor companies. And I also do, like, a fractional head of product role.

+ +

And it's a little all over the place. I mean, it's something that, obviously, a lot of that is, like, business coaching but really focused around focus and how you can use goal setting to accelerate growth for a business or an organization or for yourself personally.

+ +

VICTORIA: How did it get started? What led you to be the coach that you are today?

+ +

EVAN: Yeah, you know, I get asked this question. And I feel like there's a story about how I kind of tested goal setting. I was a founder. I went to Techstars in, like, 2013. And I was running the company. So, I had to, like, mess around with goal setting and then ended up being at Codecademy and Vimeo. They were doing OKRs. And there were certain things I liked and certain things I didn't. And there was, like, this progression.

+ +

But I think the truth is that I just really like systems and organizing things, and I think I've always been like that. And OKRs are a way of taking something that's really messy, which is, like, a group of people running together in some direction and saying, "Oh, well, what if we come up with, like, some agreed plan here, and some rules, and some guidance? And we can split this out between what, like, the company and the organization is doing versus what individual people are doing or what the department's doing."

+ +

I think I just find that process comforting. It's just, like, gleeful for me to be working with people on how they're going to focus and organize themselves, and then also how they're going to communicate that focus to each other, which I think is, like, a key part of people staying on the same page.

+ +

VICTORIA: I love that. And I really want to dig into some examples of OKRs and maybe even get some free OKR coaching for myself on this episode. But, you know, but with your background, I wanted to start with looking at the founder experience versus being someone in a larger organization. How do you bring in that context of where you are in your journey into how you think about setting goals for an individual?

+ +

EVAN: I think it's a hard question for me because my viewpoint on how goal setting and strategy and achievement in organizations has changed over this whole time, right? So, I was a founder, then at these larger organizations. I think I've tried to synthesize some, like, through line rather than difference between them. So, let me start there.

+ +

I think when you look at a founder, or a founding team, or a larger organization, the key thing to figure out is where you're going and coming up with really clear goals. And then, depending on the size of the organization, there's different tactics you can use, right? So, if you're a founder, it might be just sitting down with your co-founders once a week, having a clear Northstar metric, and having a clear goal, and then everybody's running, and that works.

+ +

Zoom to a 100-person company, which is, like, I probably focus on, like, 20 to 100-person companies. And now you have a lot of confusion between departments because you have people who are working on very different parts of the business. So, I think OKRs, at that point, are really great because it is this, like...and we will talk more about OKRs. But it's this cascading goal-setting technique where you have company goals that everybody understands and agrees to, and then each department is carving out how they're going to support that, which is, like, less necessary for a small company.

+ +

But I still think the key thing is to know what you want, what your biggest problem is in getting there, and what your approach is going to be in overcoming that problem, which is, you know, is, like, I guess, strategy 101.

+ +

VICTORIA: I like that. And it's funny; it makes me think of a tarot card layout. That's a situation I'll come and approach. Anyways, I wanted to get, like, down to the basics. I think we said OKRs earlier, but what is an OKR, if you can define that?

+ +

EVAN: Yeah, so objectives and key results. An objective is any goal you have, so that can be launch a feature, revamp your sales process, or achieve some sort of milestone or some capability, right? So, often, that's, like, build a new department, or come up not just with a specific feature but a new offering, like launch a whole product line. Anything that's important to you can be a goal. It should be clear and inspiring. And that's the objective piece.

+ +

Key results answer the question: how will you know if you're successful in reaching that goal? That might be if you're building a new department, a certain number of hires. If you're launching a feature or want to have a new offering, that might be some KPI for the product team, like, you know, onboarding rates or retention rates.

+ +

VICTORIA: Yeah, and let's maybe even go into a real example: myself, I'm a managing director here at thoughtbot. People who aren't familiar with thoughtbot...I'm sure everyone listening has [laughs] familiarity with what we do as a product and business consultancy. And our team at Mission Control, the goal was to innovate on our approach to how we were deploying and managing software.

+ +

So, over 20 years, the trends and modernization of infrastructure was something we wanted to be a part of, and we wanted to enable and accelerate not just our own development teams but our clients' teams in deploying software securely and efficiently and meeting everything that we need to do. Like, it's an incredibly complex environment. And there's lots of choices to make. So, that's, like, the big vision of what we're trying to do at thoughtbot. It's a new service. It's touching not only our internal processes but also, like, the growth of our business overall.

+ +

So, what I've done as a managing director I talk with my team. I work with the CTO of thoughtbot, Joe Ferris. He's my acting director [chuckles] on identifying what is our overall approach? What's our strategy? So, one of the things we do at thoughtbot, one of our strategies, is to put content out there. So, we want to build stuff that works for us, and we want to share and talk about it.

+ +

And we believe that by putting good stuff out there, good stuff will come back to us [laughs]. So, really just increasing the amount of blog posts, increasing the amount of open-source contributions and [inaudible 13:03] people we talk to and hear about what their problems are. We think that that will be an indicator for us of whether or not we're being successful in growing this business. So, that's just, like, one small strategy, but I've got five other ones if you want to talk about them.

+ +

EVAN: Yeah, I mean, you highlighted a large goal that you have, and then some of the, like, sub-objectives in reaching that goal. And you could imagine key results being metrics along number of blog posts, audience size, number of readers, engagement. I mean, all those have different values, depending on what your goals are.

+ +

VICTORIA: Exactly right. Like, there's the overall leading indicators we have of, like, whether or not we're successful as a business [laughs], which is, like, revenue, and, like, margins of profit, which really aren't going to change. And as a company, we don't change our policies or things that often to where those costs are ultimately going to change. It's all about, like, are we bringing in new business? Are we retaining the clients we have? And are we able to sustain, you know, work that centers around this problem area?

+ +

So, that kind of, like, makes our goal tracking, like, the numbers month to month somewhat easy. Although those individual strategies and how they all line up to meet, that is something I think I'm curious to hear about how you facilitate those discussions with teams. How would you, like, begin an engagement with a team where you have a company like thoughtbot [laughs]? How are you going to coach us to get better at our goals?

+ +

EVAN: Well, one thing I do is I pull apart KPIs, Key Performance Indicators, from OKRs, which you actually implied. KPIs are metrics you use to judge the health of your business, when OKRs are the goals that are going to transform your business. They fit well together. But, you know, for a founding team, they're still trying to figure out, well, how do we actually measure if this is going well? What does that mean? And I have a whole technique for that.

+ +

But for a larger company, something like thoughtbot, you probably have pretty clear KPIs for the business and for each department. And you can look each month to make sure that those are in a healthy band or each week. And then, when you go to set goals, one of the things you can say is, "Hey, what's not working well? Why are the KPIs not where they should be?" And there's other ways of coming up with good goals, but I do think that's one of the starting points for goal setting.

+ +

Another one, and I'm curious if you all have this here, is, like, a sense of what's holding back your growth. So, if you have a clear goal of growing your business year over year; usually, people in different departments have a sense of what challenges they're facing in executing towards those growth goals. And, fundamentally, there's usually some sort of competitive or market conditions or customer conditions that are concerning to you as a business in terms of where you're currently at. So, do you all have that type of, I guess, angle on thoughtbot's growth at all?

+ +

VICTORIA: You know, for me, it's my first year as managing director. And experiencing how thoughtbot does planning, I appreciated our approach this year was to ask each managing director more like a retro style, like, "What should we do more of? What do we like doing? What didn't really work, and what should we do less of? And what other things do we want to start doing?"

+ +

So, it's kind of similar to start, stop, continue but, you know, just really reflecting on, like, what's working? What should we do more of? What doesn't work, and we should just stop [laughs], or change, or figure out how to improve? And then, what should we start doing? And what kind of new behaviors do we need to practice and learn to build a better system?

+ +

Which I think when you talk about what's holding people back, I think it's difficult to understand in a complex organization of 100 people how all these departments work together and how they contribute and support teams. So, I'm curious, from your experience, and you like to come in and organize and get focused, so if you have that level of complexity in an organization, how do you start to get people organized and understanding how they all work together and what's working and what's not?

+ +

EVAN: Yeah, that's a good question. I might punt that to the second half of my answer here and answer an earlier question [inaudible 17:08] how we get started. Because I think that actually comes up as, like, the second piece. I think the first piece is, like, when I start with an organization, I usually sit down with the CEO. Maybe there's a founding team. Maybe it's a leadership team.

+ +

And I try to understand their vision for where the company's going and, one, how clear and actionable it is. So, does it feel like, oh, I get exactly how they're going from point A to point B to point C, or is it a little bit murkier? And trying to nail that down. And sometimes I do, like, a strategy workshop around that.

+ +

But the next piece is understanding if they have a clear plan for the next quarter, next year. When I come into companies, I'm doing OKRs quarterly. So, even if they don't have a clear strategy, we still need to set goals for the next quarter. I then have them just kind of draft goals with not that much guidance here. I might do some sort of training so everybody, like, understands what OKRs are. And then, you know, I do...and this is a common thing, I think, like, my background is in product, is trying to understand the root cause of things.

+ +

So, usually, there's some goal that I can ask. And, usually, there's a goal that's, like, something that seems very strategic, like a new offering, or changing how the business is organized, or it's very growth revenue-oriented. Those are, like, the two types of goals that people usually come up with.

+ +

So, there's a lot of just, like, asking why this is valuable, and kind of going up the ladder, down the ladder asking why it's valuable, and understanding what their root motivation is for doing this. And then going the other direction and saying, "Oh, if we did this, then what would happen?" And trying to just understand how they're thinking of this goal and how it fits in a longer chain of events.

+ +

And, usually, through that process, we shift the focus point. So, it's rare that somebody comes up with, like, exactly the right goal. I think when they start understanding what would the effect be of that goal, sometimes one of those things is the actual goal. Or if there's a root cause, it doesn't always mean that we go to the root cause, right?

+ +

If somebody wants to, like, fix their onboarding, and that's really, like, their whole focus point, you know, when you say, "Why?" and they talk about helping a certain customer get more focused. And then you may say, "Well, why?" And they say, "Oh, well, you know, we have this revenue model that involves helping them, and we make money." And "Why?" "So we can grow our business at a certain clip." And that's the arc that we build.

+ +

That doesn't mean we go to, oh, well, you're trying to make more money faster. That might not be really what the focus should be for the quarter. So, we have to always start just trying to, like, dial in with what the right angle is. That's both...I think you want to choose the thing that's the most fundamental to the business that still feels attainable and focusable, if that's a word, in the short term, right? That's like, oh, this is a good target for a quarter or a year, if you're doing it on an annual basis.

+ +

So, that's, like, how I usually get started with folks, which, you know, depending on how much thought there is around strategy, like, it goes in different ways. Sometimes, the company has a very, like, clear strategy, and then everything I said works pretty smoothly. And you get to a goal very quickly that you kind of orient the company around.

+ +

If the strategy is either not explicit or maybe the CEO has a different vision for it than, you know, CTO or the head of sales, then there's more negotiating between folks and getting on the same page. And I think that's a whole, like, can of worms that we can dive into, but that's, like, a different type of exploration.

+ +

VICTORIA: Yes, I love all that. I have so many follow-up things I want to ask. Just to play it back a little bit, too, I really resonated with some of what you're saying around it's kind of better to draft it; just write it. Like, the act of planning is more valuable than the plan itself. Like, get as close as you can as fast as you can [laughs]. That makes sense. Like, something that feels, like, good enough and, like, kind of go with it and, like, see how it goes.

+ +

You know, like, I think that's a mindset that can be difficult to implement in an organization, especially if there's been, like, past trauma with, like, not meeting your goals. And how does that flow down to the organization?

+ +

EVAN: That's a hard thing.

+ +

VICTORIA: And it makes me think of, like, what you started with, like, talking about getting to the root of what's happening. Like, what are the motivations of individual people? Like, what's happened in the past? Like, trying to take an approach that's...I prefer blame-aware to blameless. You can't get away from the tendency to blame people. So, you just have to accept that that happens and kind of move on and, like, quickly go past it [laughs] and just, like, really get to, like, what are the facts? What does the data say about this organization? So, anyways, I think that that was where I went to. I think --

+ +

EVAN: One thing I did...I started with a new company; I guess, two or three quarters ago around the OKR coaching. And, you know, I think there was this expectation. We've been doing OKRs. There's issues we need you to come in and solve and fix everything. And the tone I tried to set was, hey, I'm not here to set great goals for you. You're going to set the best goals you can. And I'm here to help support that process and teach you a lot about goal setting.

+ +

And we're going to do this every quarter. And after two or three quarters, things are going to start becoming a lot easier. People are going to communicate better. Everybody's going to be on the same page. And it's going to feel like, oh, we're getting really good at goal setting.

+ +

And then, like, I try to set that tone when I start working with the CEO of, like, the point here is to make your whole leadership team good at goal setting so that you have this skill as an organization, rather than set just the right goals with the right language in the right way right now, right? We want to timebox everything. So, we're moving forward using this tool to make progress throughout the quarter, and then each quarter, revisiting it and getting better.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: And I'm curious if there's anything else when you're evaluating whether or not someone might be a good fit for the work that you want to do with them. Are there, like, some red flag, green flag energy that you check for with executives when you're deciding whether or not to work with them?

+ +

EVAN: Yeah, there are two flags that come up; one is, are they clear with what they're saying? I think a lot of leaders want to sound good. So, that doesn't mean that they need to be clear right off the bat. But in a conversation where someone says, "This is our vision," and you say, "Hey, I don't understand X, Y, and Z," or "This part didn't make sense to me. Can we dive into it?"

+ +

And yeah, if someone through a conversation can be really clear about what's important to the company and where they're going, I think that's, like, key. Because if someone's talking around issues all the time and when you kind of bring up things they don't really address it, it's very hard to make any progress. It's like, you know, the lack of specificity ends up being a defense towards maybe dealing with some of the difficult conversations.

+ +

But, like, at the end of the day, like, one of the major things that happens with goal setting that makes it, I think, feel exciting to people when it does—it always feels exciting to me [laughs]—when it feels exciting to other people is that they say, for the first time, "Oh, this is actually the thing holding us back. This is the problem. Yeah, we want to grow our business."

+ +

But when you say, "Well, what are all the things you do to grow your business?" All of a sudden, you start talking through things, and someone says, "Hey, this is the real problem. This is why we're struggling to grow our business." And, you know, that transforms the conversation. People who are avoiding being specific, that can be really hard. That's one thing.

+ +

And the other thing is around responding to feedback. And, you know, you can just...and this is a common interview question, right? You can ask somebody, "What do you think the weaknesses of your organization are?" And if somebody doesn't know, but they're, like, open to it, that's, I think, totally fine. But if it seems like they're constantly kind of, like, filibustering the answer there, it's like, hey, the main thing you're bringing me on to do is to make sure that you communicate the weaknesses of your organization to everybody else because that's what goals are about. They're about overcoming the weaknesses of your organization.

+ +

So, those are two areas. And they also speak to, like, I think, rapport with the people that I'll be working with.

+ +

VICTORIA: I agree. And I like that, you know, you're asking really for people, are you going to be honest about what's happening in your organization? Are you honest with yourself about where you're not doing well? And I think I also pay attention to the language people use to describe those problems. And are they really speaking with a growth mindset or a fixed mindset? Because that's a really hard thing to change [laughs]. Naturally, I think people who are good leaders and run successful companies have a growth mindset. So, I think that's usually there. But that would be some yellow-flag stuff for me.

+ +

EVAN: You know, when people are looking to hire an OKR coach, they usually already are looking for improvement. And it's not like they're hiring a product manager, right? You have to be saying to yourself, hey, I believe that if we did better around goals, our company would grow better. We'd have better focus. We'd have better alignment. Like, there's already a belief that people have that is usually pretty self-aware of the limits of both the people there and the organization where it's at today, and they're looking for help.

+ +

So, I think I come across what you brought up more in individual people on a leadership team that, like, feel more coachable or less coachable depending on how interested they are around expanding how they think about things and growing. And, you know, obviously, [inaudible 27:01] lots of opinions that are wrong, and I love the disagreement that comes up there. But you want to, you know, you want to be speaking to people that are generally open to learning through a conversational process.

+ +

VICTORIA: Right. Yeah, I think it's like a confirming thing. Like, if they're reaching out to a goals coach, they probably do have a growth mindset. And if the top leadership does, then that means that there's an opportunity for other people to come along as well. So, I like opening it up that way and getting people to get specific about their goals as well. I think that's a real challenge. Like, it's either too vague or too specific, not inspiring enough.

+ +

Some people still bring up SMART goals with me. I like to prefer HARD goals, but you probably need those. And I'm curious if you're familiar with those acronyms. I can spell them out. And I'm sure you've heard of both of these [laughs]. A lot of people are familiar with the SMART goals and the specific, measurable, actionable. I forget what the Rs and Ts are.

+ +

But then HARD goals are heartfelt and more around, like, the big vision. And it's something that you want to get people excited about, which is something that you said earlier. Like, how do you get people excited? And some people would think of a corporate goal-setting event as a level three fun [laughter]. So, how do you make it more like a two or a one?

+ +

EVAN: I don't know, a lot of what I hope I offer to folks...and I've gotten good feedback here is that I enjoy goal setting a lot. So, talking through all these problems, talking through challenges, doing workshops, having these conversations. Like, whenever I'm doing that, it's my favorite thing to be doing. So, I think, hopefully, some of my joy just rubs off on the people around me. Because I do think talking to somebody who's excited about what you're talking about is helpful.

+ +

The other thing is, usually, at a decently small company, under 100 people, I'm working with the CEO and the leadership team; you know, people are there because they care about the company. They care about the mission of the company. They care about the people in the company, and they care about the growth of the company.

+ +

So, I get why goal setting has, I think, can have a bad rap. But if you're fundamentally solving problems that people care about, there should be some, like, glee that comes in when people say, like, "Oh, yeah, I thought this was going to be about, like, how do we grow more? And that felt very generic to me." And it turns out when we actually think about how we grow more, and we talk through what's holding back our growth and what we can do to overcome that, and we have the top few ideas that we've all come up with, usually, those feel really relieving to people.

+ +

And there's a company I'm working with now that I think is struggling to shift their target market a bit because...and there's awareness that the target market needs to shift, but there isn't so much knowledge around the new target market. There's a lot more knowledge around the old target market. And so, we're doing a bunch of research and talking to folks.

+ +

And I know once we're able to say, "For this target market, we need to do X," there is going to be, like, a huge amount of excitement and relief at the organization because people will feel like, oh, we've crossed that bridge, that bridge that we were kind of in the middle of crossing and didn't really know where the other side was. We now can see that other side, and we're going there. So yeah, I think there can be a lot of excitement around this stuff when it's real, and it's important work that you're doing.

+ +

VICTORIA: Right. Like, maybe there's a good factor of, like, how do you measure if what you've done with a company is successful? Is there a glee scale that you [laughs] use to evaluate?

+ +

EVAN: You know, for me, it's still probably more subjective than I want it to be. You know, I'd love it to be like, what percentage of people's OKRs did I [laughs] hit each quarter? And when I work with them, it gets better. But I think that's, like, a pretty short-sighted view in terms of my role. So, you know, I'm looking for people who were maybe disengaged to be more engaged, people who didn't see the value of OKRs to see and be able to articulate how their daily work is different because of the OKRs we set.

+ +

Yeah, and obviously, there's excitement when we're solving real problems. And we're changing the problems each quarter, and people are seeing growth increase. You know, like, all that stuff, I guess there's, like, a tangible excitement with. But I hope folks can, like, just connect the dots between the work, which can be tedious work around goal setting and negotiating with people. And often, it pulls you out of other day-to-day work that you're doing, especially for a small company, with the excitement towards the end of the quarter of reaching these goals and moving on to the next challenge.

+ +

VICTORIA: I think that's great. I think that was a perfect answer. It's kind of not always easy to know what [laughs]...like, sometimes there's a sense of it, like, you have a feeling, and sometimes you can get data to back that up. And other times, you know you're doing the right thing by the people's faces around you at the end of the workshop [laughs]. So, I think that's great. And so, maybe my final question would be is, like, what would be the ideal organization that you would want to work with? Like, who's your ideal customer right now?

+ +

EVAN: Yeah, I guess I have two ideal customers based on these, like, two things that I'm doing. In terms of the OKR coaching, I usually look for CEO or founding team of a company that's now, like, 20-plus people who's saying, "Oh, we have these departments," or "We have this leadership team. And we need to really get all on the same page at the beginning of the quarter because then everybody's going to consistently be talking to each other but has other people that they need to organize." That's definitely for the OKR coaching where, like, 20 to 30 people is where that starts. That probably goes up to 100 in terms of where I focus.

+ +

For the other work I do as a Techstars mentor and the coaching I do through that, that's really for founding teams. And that's more focused on how do you take your vision and make that a clear goal statement, which is around, like, behavior change, usually, in a certain population you're targeting? How do you turn that into a go-to-market plan? How do you turn that into a product roadmap? So, for that, that's just much smaller teams.

+ +

I actually think that work often needs to be done at larger organizations, too. That's, like, a common thing that comes up. And that can bleed into strategy at large organizations. But yeah, I know that's probably a pretty broad bucket, but groups of people that believe that focus is a key lever towards faster growth.

+ +

VICTORIA: Thank you for that. And I guess I said that was my final question, but I'll add two more questions. Can you share an anecdote from being a mentor at Techstars that you think will be interesting for our audience?

+ +

EVAN: I think I was struck the first time I did the mentoring. They do, like, a Mentor Madness. So, it's like, you know, six companies in a row, and every company they all have different challenges. But a lot of them, it's, like, helping them articulate what they're doing a little bit more clearly. And often, there's a question around sales and growth and maybe fundraising. So, there's just, like, a focus in that direction. And I found that every company, even though they had kind of different questions, I was giving the same answer to, which was, I don't think your goal is clear to you or to me.

+ +

And so, there's this framework that I would use with each company that there was, like, this aha moment. And I picked this up from a person named Matt Wallaert. It was a book, "Start at the End." It's called a behavioral statement. And it's when population wants to motivation, and they have limitations, they do behavior as measured by data. And the kind of conceptual version is, oh, you're trying to get some group of people to change their behavior. And that's only going to happen if you can tap into a motivation that happens to them as frequently as the behavior you want to change. So, it's like a formalization of that.

+ +

And each group, I'd like bring up the statement; we work on filling it quickly. And there was just, like, a clarity that would develop around what they were doing and how to orient themselves both on the growth and marketing side and on the product development side. I guess it just struck me how much that little framing was transformative to [laughs] accelerating both focus and alignment but, more importantly, like, getting somewhere that they wanted to get to.

+ +

VICTORIA: It sounds almost like building a mental model of what you're trying to do [laughs], right? Like, it was a mental model that you referenced in your mind that helps you make decisions every single day. So, I really appreciate that. And we are about out of time. So, let me ask you, is there anything else that you would like to promote today?

+ +

EVAN: Sure. Looking for a couple more OKR coaching clients for the new year, and just happy to chat with anybody who has questions around OKRs or goal setting for their organization.

+ +

I also do personal goals coaching, which is a little different from the OKR coaching that I help individual people with their goals. But it's also similar. It's a lot of like...it's a lot more, like, reflection, and getting to know oneself, and coming up with goals that are really meaningful.

+ +

And then the other half of, like, I think you alluded to this earlier around systems. Like, how do you take a goal that's important to you and actually act every day in ways that move you towards that goal? So yeah, interested in talking to people about both of those. I do some workshops as well, so people can reach out to me at evan@evanhammer.com. I can also put anybody on my mailing list. I do some workshops around both those things.

+ +

VICTORIA: Wonderful. Thank you so much, Evan, for joining us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Evan Hammer.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Today's conversation revolves around the importance and challenges of goal setting within organizations. It highlights how identifying and articulating real problems can be transformative, turning abstract desires for growth into concrete plans for improvement. Host Victoria Guido and special guest Evan Hammer discuss the nuances of leadership and organizational self-awareness, emphasizing the need for honesty and a growth mindset when addressing weaknesses. They touch on Evan's role as an OKR Coach in fostering alignment, focus, and excitement around goals, particularly in small to mid-sized companies.

+ +

Evan shares his enthusiasm for goal setting and believes his passion can inspire others. He points out the positive outcomes when employees engage with goals that address problems they care about. Victoria and Evan agree that success is not solely measured by hitting OKRs but also by engagement and alignment within the team. They discuss the ideal organizations for Evan's work, which include small to medium-sized companies seeking to improve focus and alignment, as well as start-up teams needing more straightforward goal statements and go-to-market strategies. Evan also recounts his experience as a Techstars mentor, noting that a common issue across companies is the lack of clear goals, and he emphasizes the power of focus as a lever for growth.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Evan Hammer, OKR and personal goals coach. Evan, thank you for joining us.

+ +

EVAN: Thank you for having me. I'm excited to be here.

+ +

VICTORIA: Wonderful. Me too. And I wanted to ask you first, before we dive into business, tell me a personal goal that you've achieved recently that you're most proud of.

+ +

EVAN: I guess a couple of months ago, I did a 100-mile loop of Mount Rainier. So, it was a 10-day backpacking trip. My younger brother, I went with him, and it's the kind of thing he does more regularly. Yeah, it was something I was kind of excited to do but really unsure of, and worked super hard between the gear and the training and just, like, the mindset. But it was also just awesome being out in the woods for ten days.

+ +

VICTORIA: I also love being out in the woods for long periods of time. I guess, like, how long did your brother plan this trip for? And how long were you involved before you decided to go?

+ +

EVAN: You know, it was something he was planning to do since the spring. He won a lottery to be able to do it. And I was going back and forth for a few months. And I think it was just maybe in the end of June where I was like, okay, I'm doing this. I need to put together a gear list, figure out a training plan. I live in Fort Greene in Brooklyn. And it was a lot of, like, waking up early and going up and down the steps in Fort Greene Park, which is, like, you know, 6, 10 flights of steps, something like that outdoors --

+ +

VICTORIA: [laughs]

+ +

EVAN: With a heavy backpack on for two to three hours, like on weekends.

+ +

VICTORIA: Oooh. Wow.

+ +

EVAN: Yeah, it was one of those things I was like, you know, you don't know when you do something like this how it's going to go until you're there doing it or how your body is going to respond. So, it was a little bit of, like, trying to train as much as possible but also being aware that I just have to deal with whatever will happen on the trip.

+ +

VICTORIA: I love that, at first, it sounds sort of, like, fun. Like, "Oh, do you want to go on this trip with me?" And you're like, "Yeah, okay." And then you look at the training plan, and it's like, "We'll wake up at 6:00 a.m. every day and walk up and down ten flights of stairs [laughs] with a heavy backpack on," you know, like, "Oh okay, [laughs] a lot of prep work to have this trip." [laughs]

+ +

EVAN: It's fun in that you're doing something amazing, and it's beautiful. And it was just one of the more beautiful places I've ever been. It was really interesting and meaningful to me to kind of be detached from everything that I normally do and just focus on being in the woods and hiking these mountains. But yeah, you don't know how it's going to go. So, it's like you're putting yourself in an extreme physical situation. I think that's anxiety-inducing, and it feels good and is healthy and protective to train for it.

+ +

VICTORIA: I agree. Yeah, I mean, I totally relate to that. I'm a rock climber and hiker myself. And sometimes I spend all this time, you know, on gym memberships, climbing in the gym, running up and down hills. And then, I get all the way out to rock, and I'm about to start my climb, and I'm like, why am I doing this? [laughs] This is a lot of work to get to this point. But then it is all fun, and it's super worth it. And I always feel restored whenever I come back from being a long time in nature. It's really great.

+ +

I think maybe to get towards, like, a metrics conversation that we talk about a lot in climbing is the type of fun something is. So, there's three types of fun levels. Have you heard this framework before, Evan?

+ +

EVAN: I have not.

+ +

VICTORIA: Okay, so there's three levels of fun. Level one fun is, like, you're having fun while you're doing it. We're, like, laughing and enjoying recording a podcast together. Like, oh my God, it's so much fun, super easy, not stressful. Maybe it was a little stressful for you, I don't know. [chuckles] It's a little stressful for me.

+ +

Level two fun is it's a little difficult while you're doing it, but you're still looking back on it and having fun, but you're never really in any kind of intense danger, right? Like, you're going on a backpacking trip. It's relatively within your health expectations, and the trail is walkable. You're not, like, going to fumble and fall down a cliff. It's level-two fun. So, you're mostly enjoying it. Like, it's kind of difficult, and there's some effort involved, but it's still fun.

+ +

Level three fun is when it's very dangerous, and you're really scared the whole time [laughs], and, like, you maybe, like, could have died. But looking back on it, it's fun. So, how would you rate your Mount Rainier trip?

+ +

EVAN: It's funny because we actually...we didn't come up with the levels, but we spoke about how when you're hiking, often, in your head, you're just trying to figure out how much longer you have to hike as if the whole point was not to be hiking. And then you finish hiking for the day, and you're like, "Oh, that was so great. I'm so looking forward to waking up tomorrow and hiking some more."

+ +

VICTORIA: Yeah [chuckles], exactly.

+ +

EVAN: That fits the level two fun pretty explicitly.

+ +

VICTORIA: That's great. Yeah, it's a very, you know, I've found it to be pretty useful. And, you know, as I get older, I tend to try to avoid level three fun more often [laughs]. Like, I don't really need to be frightened [laughs]. I have enough stress in my life. I don't need to also endanger myself too aggressively.

+ +

But, you know, everyone has their own risk level as well, right? Like, someone else might think the type of climbing and hiking that I'm doing is level three fun, but, for me, it's more...and, like, there's other things like skateboarding and riding a bike where, for me, is level three. I'm scared and [laughs] --

+ +

EVAN: Right. And I think you also frame level three as, like, sort of physical safety. But, you know, people have different risk tolerances and classifications across the board. So, like, for me, I try to stay away from things that I would consider physically dangerous. But I'm very comfortable, like, taking financial or social risk, where I know other people have an inverted kind of spectrum where, like, social risk is, like [laughs], you know, is a terror to them when physical risk doesn't seem that scary to them, you know, so...

+ +

VICTORIA: That's so interesting. And especially for me, I do a lot of networking. And I'm, of course, been really active in San Diego Startup Week this week. We're recording this in October. So, for some people, going to an event where there's going to be hundreds of people, you maybe have met some of them before, but you really don't have a buddy that you are coming to this event with. You're on your own. You're going to have to walk up to people, start conversations, figure out who is who, and, like, find your people. That's terrifying for a lot of people. And they're like, "Absolutely not." [laughs]

+ +

EVAN: Well, it's interesting how, like, level one and level three can be inverted. I went to a conference last fall by myself, and I actually had some voice issues. So, I couldn't talk for a little bit before this, so it was like...or even that well, during, you know, it was kind of an environment that I think a lot of people might be feeling like, oh, that's level three social experience. And I just remember how much fun I had there. Like, for me, it was totally a level one thing. But, you know, there's definitely moments on this hike where I was like, oh, this is level three. This feels physically scary, even though most of the time it wasn't.

+ +

VICTORIA: Yeah, no, I think it's helpful. So, maybe that helps us segue a little bit into telling me more about what you do and how you came to do what you do. What's your background?

+ +

EVAN: What do I do? I'll give you, like, a list of the things that I do. I will say I help people focus and maybe communicate better. You know, the list is, like, I am an OKR coach, right? That's objectives and key results, coaching business leaders on how to set goals and get everybody aligned towards the same goals. I do personal goals coaching, and that's, like, helping individual people set goals that are meaningful to them and live more intentionally. I'm a Techstars mentor, where I mentor companies. And I also do, like, a fractional head of product role.

+ +

And it's a little all over the place. I mean, it's something that, obviously, a lot of that is, like, business coaching but really focused around focus and how you can use goal setting to accelerate growth for a business or an organization or for yourself personally.

+ +

VICTORIA: How did it get started? What led you to be the coach that you are today?

+ +

EVAN: Yeah, you know, I get asked this question. And I feel like there's a story about how I kind of tested goal setting. I was a founder. I went to Techstars in, like, 2013. And I was running the company. So, I had to, like, mess around with goal setting and then ended up being at Codecademy and Vimeo. They were doing OKRs. And there were certain things I liked and certain things I didn't. And there was, like, this progression.

+ +

But I think the truth is that I just really like systems and organizing things, and I think I've always been like that. And OKRs are a way of taking something that's really messy, which is, like, a group of people running together in some direction and saying, "Oh, well, what if we come up with, like, some agreed plan here, and some rules, and some guidance? And we can split this out between what, like, the company and the organization is doing versus what individual people are doing or what the department's doing."

+ +

I think I just find that process comforting. It's just, like, gleeful for me to be working with people on how they're going to focus and organize themselves, and then also how they're going to communicate that focus to each other, which I think is, like, a key part of people staying on the same page.

+ +

VICTORIA: I love that. And I really want to dig into some examples of OKRs and maybe even get some free OKR coaching for myself on this episode. But, you know, but with your background, I wanted to start with looking at the founder experience versus being someone in a larger organization. How do you bring in that context of where you are in your journey into how you think about setting goals for an individual?

+ +

EVAN: I think it's a hard question for me because my viewpoint on how goal setting and strategy and achievement in organizations has changed over this whole time, right? So, I was a founder, then at these larger organizations. I think I've tried to synthesize some, like, through line rather than difference between them. So, let me start there.

+ +

I think when you look at a founder, or a founding team, or a larger organization, the key thing to figure out is where you're going and coming up with really clear goals. And then, depending on the size of the organization, there's different tactics you can use, right? So, if you're a founder, it might be just sitting down with your co-founders once a week, having a clear Northstar metric, and having a clear goal, and then everybody's running, and that works.

+ +

Zoom to a 100-person company, which is, like, I probably focus on, like, 20 to 100-person companies. And now you have a lot of confusion between departments because you have people who are working on very different parts of the business. So, I think OKRs, at that point, are really great because it is this, like...and we will talk more about OKRs. But it's this cascading goal-setting technique where you have company goals that everybody understands and agrees to, and then each department is carving out how they're going to support that, which is, like, less necessary for a small company.

+ +

But I still think the key thing is to know what you want, what your biggest problem is in getting there, and what your approach is going to be in overcoming that problem, which is, you know, is, like, I guess, strategy 101.

+ +

VICTORIA: I like that. And it's funny; it makes me think of a tarot card layout. That's a situation I'll come and approach. Anyways, I wanted to get, like, down to the basics. I think we said OKRs earlier, but what is an OKR, if you can define that?

+ +

EVAN: Yeah, so objectives and key results. An objective is any goal you have, so that can be launch a feature, revamp your sales process, or achieve some sort of milestone or some capability, right? So, often, that's, like, build a new department, or come up not just with a specific feature but a new offering, like launch a whole product line. Anything that's important to you can be a goal. It should be clear and inspiring. And that's the objective piece.

+ +

Key results answer the question: how will you know if you're successful in reaching that goal? That might be if you're building a new department, a certain number of hires. If you're launching a feature or want to have a new offering, that might be some KPI for the product team, like, you know, onboarding rates or retention rates.

+ +

VICTORIA: Yeah, and let's maybe even go into a real example: myself, I'm a managing director here at thoughtbot. People who aren't familiar with thoughtbot...I'm sure everyone listening has [laughs] familiarity with what we do as a product and business consultancy. And our team at Mission Control, the goal was to innovate on our approach to how we were deploying and managing software.

+ +

So, over 20 years, the trends and modernization of infrastructure was something we wanted to be a part of, and we wanted to enable and accelerate not just our own development teams but our clients' teams in deploying software securely and efficiently and meeting everything that we need to do. Like, it's an incredibly complex environment. And there's lots of choices to make. So, that's, like, the big vision of what we're trying to do at thoughtbot. It's a new service. It's touching not only our internal processes but also, like, the growth of our business overall.

+ +

So, what I've done as a managing director I talk with my team. I work with the CTO of thoughtbot, Joe Ferris. He's my acting director [chuckles] on identifying what is our overall approach? What's our strategy? So, one of the things we do at thoughtbot, one of our strategies, is to put content out there. So, we want to build stuff that works for us, and we want to share and talk about it.

+ +

And we believe that by putting good stuff out there, good stuff will come back to us [laughs]. So, really just increasing the amount of blog posts, increasing the amount of open-source contributions and [inaudible 13:03] people we talk to and hear about what their problems are. We think that that will be an indicator for us of whether or not we're being successful in growing this business. So, that's just, like, one small strategy, but I've got five other ones if you want to talk about them.

+ +

EVAN: Yeah, I mean, you highlighted a large goal that you have, and then some of the, like, sub-objectives in reaching that goal. And you could imagine key results being metrics along number of blog posts, audience size, number of readers, engagement. I mean, all those have different values, depending on what your goals are.

+ +

VICTORIA: Exactly right. Like, there's the overall leading indicators we have of, like, whether or not we're successful as a business [laughs], which is, like, revenue, and, like, margins of profit, which really aren't going to change. And as a company, we don't change our policies or things that often to where those costs are ultimately going to change. It's all about, like, are we bringing in new business? Are we retaining the clients we have? And are we able to sustain, you know, work that centers around this problem area?

+ +

So, that kind of, like, makes our goal tracking, like, the numbers month to month somewhat easy. Although those individual strategies and how they all line up to meet, that is something I think I'm curious to hear about how you facilitate those discussions with teams. How would you, like, begin an engagement with a team where you have a company like thoughtbot [laughs]? How are you going to coach us to get better at our goals?

+ +

EVAN: Well, one thing I do is I pull apart KPIs, Key Performance Indicators, from OKRs, which you actually implied. KPIs are metrics you use to judge the health of your business, when OKRs are the goals that are going to transform your business. They fit well together. But, you know, for a founding team, they're still trying to figure out, well, how do we actually measure if this is going well? What does that mean? And I have a whole technique for that.

+ +

But for a larger company, something like thoughtbot, you probably have pretty clear KPIs for the business and for each department. And you can look each month to make sure that those are in a healthy band or each week. And then, when you go to set goals, one of the things you can say is, "Hey, what's not working well? Why are the KPIs not where they should be?" And there's other ways of coming up with good goals, but I do think that's one of the starting points for goal setting.

+ +

Another one, and I'm curious if you all have this here, is, like, a sense of what's holding back your growth. So, if you have a clear goal of growing your business year over year; usually, people in different departments have a sense of what challenges they're facing in executing towards those growth goals. And, fundamentally, there's usually some sort of competitive or market conditions or customer conditions that are concerning to you as a business in terms of where you're currently at. So, do you all have that type of, I guess, angle on thoughtbot's growth at all?

+ +

VICTORIA: You know, for me, it's my first year as managing director. And experiencing how thoughtbot does planning, I appreciated our approach this year was to ask each managing director more like a retro style, like, "What should we do more of? What do we like doing? What didn't really work, and what should we do less of? And what other things do we want to start doing?"

+ +

So, it's kind of similar to start, stop, continue but, you know, just really reflecting on, like, what's working? What should we do more of? What doesn't work, and we should just stop [laughs], or change, or figure out how to improve? And then, what should we start doing? And what kind of new behaviors do we need to practice and learn to build a better system?

+ +

Which I think when you talk about what's holding people back, I think it's difficult to understand in a complex organization of 100 people how all these departments work together and how they contribute and support teams. So, I'm curious, from your experience, and you like to come in and organize and get focused, so if you have that level of complexity in an organization, how do you start to get people organized and understanding how they all work together and what's working and what's not?

+ +

EVAN: Yeah, that's a good question. I might punt that to the second half of my answer here and answer an earlier question [inaudible 17:08] how we get started. Because I think that actually comes up as, like, the second piece. I think the first piece is, like, when I start with an organization, I usually sit down with the CEO. Maybe there's a founding team. Maybe it's a leadership team.

+ +

And I try to understand their vision for where the company's going and, one, how clear and actionable it is. So, does it feel like, oh, I get exactly how they're going from point A to point B to point C, or is it a little bit murkier? And trying to nail that down. And sometimes I do, like, a strategy workshop around that.

+ +

But the next piece is understanding if they have a clear plan for the next quarter, next year. When I come into companies, I'm doing OKRs quarterly. So, even if they don't have a clear strategy, we still need to set goals for the next quarter. I then have them just kind of draft goals with not that much guidance here. I might do some sort of training so everybody, like, understands what OKRs are. And then, you know, I do...and this is a common thing, I think, like, my background is in product, is trying to understand the root cause of things.

+ +

So, usually, there's some goal that I can ask. And, usually, there's a goal that's, like, something that seems very strategic, like a new offering, or changing how the business is organized, or it's very growth revenue-oriented. Those are, like, the two types of goals that people usually come up with.

+ +

So, there's a lot of just, like, asking why this is valuable, and kind of going up the ladder, down the ladder asking why it's valuable, and understanding what their root motivation is for doing this. And then going the other direction and saying, "Oh, if we did this, then what would happen?" And trying to just understand how they're thinking of this goal and how it fits in a longer chain of events.

+ +

And, usually, through that process, we shift the focus point. So, it's rare that somebody comes up with, like, exactly the right goal. I think when they start understanding what would the effect be of that goal, sometimes one of those things is the actual goal. Or if there's a root cause, it doesn't always mean that we go to the root cause, right?

+ +

If somebody wants to, like, fix their onboarding, and that's really, like, their whole focus point, you know, when you say, "Why?" and they talk about helping a certain customer get more focused. And then you may say, "Well, why?" And they say, "Oh, well, you know, we have this revenue model that involves helping them, and we make money." And "Why?" "So we can grow our business at a certain clip." And that's the arc that we build.

+ +

That doesn't mean we go to, oh, well, you're trying to make more money faster. That might not be really what the focus should be for the quarter. So, we have to always start just trying to, like, dial in with what the right angle is. That's both...I think you want to choose the thing that's the most fundamental to the business that still feels attainable and focusable, if that's a word, in the short term, right? That's like, oh, this is a good target for a quarter or a year, if you're doing it on an annual basis.

+ +

So, that's, like, how I usually get started with folks, which, you know, depending on how much thought there is around strategy, like, it goes in different ways. Sometimes, the company has a very, like, clear strategy, and then everything I said works pretty smoothly. And you get to a goal very quickly that you kind of orient the company around.

+ +

If the strategy is either not explicit or maybe the CEO has a different vision for it than, you know, CTO or the head of sales, then there's more negotiating between folks and getting on the same page. And I think that's a whole, like, can of worms that we can dive into, but that's, like, a different type of exploration.

+ +

VICTORIA: Yes, I love all that. I have so many follow-up things I want to ask. Just to play it back a little bit, too, I really resonated with some of what you're saying around it's kind of better to draft it; just write it. Like, the act of planning is more valuable than the plan itself. Like, get as close as you can as fast as you can [laughs]. That makes sense. Like, something that feels, like, good enough and, like, kind of go with it and, like, see how it goes.

+ +

You know, like, I think that's a mindset that can be difficult to implement in an organization, especially if there's been, like, past trauma with, like, not meeting your goals. And how does that flow down to the organization?

+ +

EVAN: That's a hard thing.

+ +

VICTORIA: And it makes me think of, like, what you started with, like, talking about getting to the root of what's happening. Like, what are the motivations of individual people? Like, what's happened in the past? Like, trying to take an approach that's...I prefer blame-aware to blameless. You can't get away from the tendency to blame people. So, you just have to accept that that happens and kind of move on and, like, quickly go past it [laughs] and just, like, really get to, like, what are the facts? What does the data say about this organization? So, anyways, I think that that was where I went to. I think --

+ +

EVAN: One thing I did...I started with a new company; I guess, two or three quarters ago around the OKR coaching. And, you know, I think there was this expectation. We've been doing OKRs. There's issues we need you to come in and solve and fix everything. And the tone I tried to set was, hey, I'm not here to set great goals for you. You're going to set the best goals you can. And I'm here to help support that process and teach you a lot about goal setting.

+ +

And we're going to do this every quarter. And after two or three quarters, things are going to start becoming a lot easier. People are going to communicate better. Everybody's going to be on the same page. And it's going to feel like, oh, we're getting really good at goal setting.

+ +

And then, like, I try to set that tone when I start working with the CEO of, like, the point here is to make your whole leadership team good at goal setting so that you have this skill as an organization, rather than set just the right goals with the right language in the right way right now, right? We want to timebox everything. So, we're moving forward using this tool to make progress throughout the quarter, and then each quarter, revisiting it and getting better.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: And I'm curious if there's anything else when you're evaluating whether or not someone might be a good fit for the work that you want to do with them. Are there, like, some red flag, green flag energy that you check for with executives when you're deciding whether or not to work with them?

+ +

EVAN: Yeah, there are two flags that come up; one is, are they clear with what they're saying? I think a lot of leaders want to sound good. So, that doesn't mean that they need to be clear right off the bat. But in a conversation where someone says, "This is our vision," and you say, "Hey, I don't understand X, Y, and Z," or "This part didn't make sense to me. Can we dive into it?"

+ +

And yeah, if someone through a conversation can be really clear about what's important to the company and where they're going, I think that's, like, key. Because if someone's talking around issues all the time and when you kind of bring up things they don't really address it, it's very hard to make any progress. It's like, you know, the lack of specificity ends up being a defense towards maybe dealing with some of the difficult conversations.

+ +

But, like, at the end of the day, like, one of the major things that happens with goal setting that makes it, I think, feel exciting to people when it does—it always feels exciting to me [laughs]—when it feels exciting to other people is that they say, for the first time, "Oh, this is actually the thing holding us back. This is the problem. Yeah, we want to grow our business."

+ +

But when you say, "Well, what are all the things you do to grow your business?" All of a sudden, you start talking through things, and someone says, "Hey, this is the real problem. This is why we're struggling to grow our business." And, you know, that transforms the conversation. People who are avoiding being specific, that can be really hard. That's one thing.

+ +

And the other thing is around responding to feedback. And, you know, you can just...and this is a common interview question, right? You can ask somebody, "What do you think the weaknesses of your organization are?" And if somebody doesn't know, but they're, like, open to it, that's, I think, totally fine. But if it seems like they're constantly kind of, like, filibustering the answer there, it's like, hey, the main thing you're bringing me on to do is to make sure that you communicate the weaknesses of your organization to everybody else because that's what goals are about. They're about overcoming the weaknesses of your organization.

+ +

So, those are two areas. And they also speak to, like, I think, rapport with the people that I'll be working with.

+ +

VICTORIA: I agree. And I like that, you know, you're asking really for people, are you going to be honest about what's happening in your organization? Are you honest with yourself about where you're not doing well? And I think I also pay attention to the language people use to describe those problems. And are they really speaking with a growth mindset or a fixed mindset? Because that's a really hard thing to change [laughs]. Naturally, I think people who are good leaders and run successful companies have a growth mindset. So, I think that's usually there. But that would be some yellow-flag stuff for me.

+ +

EVAN: You know, when people are looking to hire an OKR coach, they usually already are looking for improvement. And it's not like they're hiring a product manager, right? You have to be saying to yourself, hey, I believe that if we did better around goals, our company would grow better. We'd have better focus. We'd have better alignment. Like, there's already a belief that people have that is usually pretty self-aware of the limits of both the people there and the organization where it's at today, and they're looking for help.

+ +

So, I think I come across what you brought up more in individual people on a leadership team that, like, feel more coachable or less coachable depending on how interested they are around expanding how they think about things and growing. And, you know, obviously, [inaudible 27:01] lots of opinions that are wrong, and I love the disagreement that comes up there. But you want to, you know, you want to be speaking to people that are generally open to learning through a conversational process.

+ +

VICTORIA: Right. Yeah, I think it's like a confirming thing. Like, if they're reaching out to a goals coach, they probably do have a growth mindset. And if the top leadership does, then that means that there's an opportunity for other people to come along as well. So, I like opening it up that way and getting people to get specific about their goals as well. I think that's a real challenge. Like, it's either too vague or too specific, not inspiring enough.

+ +

Some people still bring up SMART goals with me. I like to prefer HARD goals, but you probably need those. And I'm curious if you're familiar with those acronyms. I can spell them out. And I'm sure you've heard of both of these [laughs]. A lot of people are familiar with the SMART goals and the specific, measurable, actionable. I forget what the Rs and Ts are.

+ +

But then HARD goals are heartfelt and more around, like, the big vision. And it's something that you want to get people excited about, which is something that you said earlier. Like, how do you get people excited? And some people would think of a corporate goal-setting event as a level three fun [laughter]. So, how do you make it more like a two or a one?

+ +

EVAN: I don't know, a lot of what I hope I offer to folks...and I've gotten good feedback here is that I enjoy goal setting a lot. So, talking through all these problems, talking through challenges, doing workshops, having these conversations. Like, whenever I'm doing that, it's my favorite thing to be doing. So, I think, hopefully, some of my joy just rubs off on the people around me. Because I do think talking to somebody who's excited about what you're talking about is helpful.

+ +

The other thing is, usually, at a decently small company, under 100 people, I'm working with the CEO and the leadership team; you know, people are there because they care about the company. They care about the mission of the company. They care about the people in the company, and they care about the growth of the company.

+ +

So, I get why goal setting has, I think, can have a bad rap. But if you're fundamentally solving problems that people care about, there should be some, like, glee that comes in when people say, like, "Oh, yeah, I thought this was going to be about, like, how do we grow more? And that felt very generic to me." And it turns out when we actually think about how we grow more, and we talk through what's holding back our growth and what we can do to overcome that, and we have the top few ideas that we've all come up with, usually, those feel really relieving to people.

+ +

And there's a company I'm working with now that I think is struggling to shift their target market a bit because...and there's awareness that the target market needs to shift, but there isn't so much knowledge around the new target market. There's a lot more knowledge around the old target market. And so, we're doing a bunch of research and talking to folks.

+ +

And I know once we're able to say, "For this target market, we need to do X," there is going to be, like, a huge amount of excitement and relief at the organization because people will feel like, oh, we've crossed that bridge, that bridge that we were kind of in the middle of crossing and didn't really know where the other side was. We now can see that other side, and we're going there. So yeah, I think there can be a lot of excitement around this stuff when it's real, and it's important work that you're doing.

+ +

VICTORIA: Right. Like, maybe there's a good factor of, like, how do you measure if what you've done with a company is successful? Is there a glee scale that you [laughs] use to evaluate?

+ +

EVAN: You know, for me, it's still probably more subjective than I want it to be. You know, I'd love it to be like, what percentage of people's OKRs did I [laughs] hit each quarter? And when I work with them, it gets better. But I think that's, like, a pretty short-sighted view in terms of my role. So, you know, I'm looking for people who were maybe disengaged to be more engaged, people who didn't see the value of OKRs to see and be able to articulate how their daily work is different because of the OKRs we set.

+ +

Yeah, and obviously, there's excitement when we're solving real problems. And we're changing the problems each quarter, and people are seeing growth increase. You know, like, all that stuff, I guess there's, like, a tangible excitement with. But I hope folks can, like, just connect the dots between the work, which can be tedious work around goal setting and negotiating with people. And often, it pulls you out of other day-to-day work that you're doing, especially for a small company, with the excitement towards the end of the quarter of reaching these goals and moving on to the next challenge.

+ +

VICTORIA: I think that's great. I think that was a perfect answer. It's kind of not always easy to know what [laughs]...like, sometimes there's a sense of it, like, you have a feeling, and sometimes you can get data to back that up. And other times, you know you're doing the right thing by the people's faces around you at the end of the workshop [laughs]. So, I think that's great. And so, maybe my final question would be is, like, what would be the ideal organization that you would want to work with? Like, who's your ideal customer right now?

+ +

EVAN: Yeah, I guess I have two ideal customers based on these, like, two things that I'm doing. In terms of the OKR coaching, I usually look for CEO or founding team of a company that's now, like, 20-plus people who's saying, "Oh, we have these departments," or "We have this leadership team. And we need to really get all on the same page at the beginning of the quarter because then everybody's going to consistently be talking to each other but has other people that they need to organize." That's definitely for the OKR coaching where, like, 20 to 30 people is where that starts. That probably goes up to 100 in terms of where I focus.

+ +

For the other work I do as a Techstars mentor and the coaching I do through that, that's really for founding teams. And that's more focused on how do you take your vision and make that a clear goal statement, which is around, like, behavior change, usually, in a certain population you're targeting? How do you turn that into a go-to-market plan? How do you turn that into a product roadmap? So, for that, that's just much smaller teams.

+ +

I actually think that work often needs to be done at larger organizations, too. That's, like, a common thing that comes up. And that can bleed into strategy at large organizations. But yeah, I know that's probably a pretty broad bucket, but groups of people that believe that focus is a key lever towards faster growth.

+ +

VICTORIA: Thank you for that. And I guess I said that was my final question, but I'll add two more questions. Can you share an anecdote from being a mentor at Techstars that you think will be interesting for our audience?

+ +

EVAN: I think I was struck the first time I did the mentoring. They do, like, a Mentor Madness. So, it's like, you know, six companies in a row, and every company they all have different challenges. But a lot of them, it's, like, helping them articulate what they're doing a little bit more clearly. And often, there's a question around sales and growth and maybe fundraising. So, there's just, like, a focus in that direction. And I found that every company, even though they had kind of different questions, I was giving the same answer to, which was, I don't think your goal is clear to you or to me.

+ +

And so, there's this framework that I would use with each company that there was, like, this aha moment. And I picked this up from a person named Matt Wallaert. It was a book, "Start at the End." It's called a behavioral statement. And it's when population wants to motivation, and they have limitations, they do behavior as measured by data. And the kind of conceptual version is, oh, you're trying to get some group of people to change their behavior. And that's only going to happen if you can tap into a motivation that happens to them as frequently as the behavior you want to change. So, it's like a formalization of that.

+ +

And each group, I'd like bring up the statement; we work on filling it quickly. And there was just, like, a clarity that would develop around what they were doing and how to orient themselves both on the growth and marketing side and on the product development side. I guess it just struck me how much that little framing was transformative to [laughs] accelerating both focus and alignment but, more importantly, like, getting somewhere that they wanted to get to.

+ +

VICTORIA: It sounds almost like building a mental model of what you're trying to do [laughs], right? Like, it was a mental model that you referenced in your mind that helps you make decisions every single day. So, I really appreciate that. And we are about out of time. So, let me ask you, is there anything else that you would like to promote today?

+ +

EVAN: Sure. Looking for a couple more OKR coaching clients for the new year, and just happy to chat with anybody who has questions around OKRs or goal setting for their organization.

+ +

I also do personal goals coaching, which is a little different from the OKR coaching that I help individual people with their goals. But it's also similar. It's a lot of like...it's a lot more, like, reflection, and getting to know oneself, and coming up with goals that are really meaningful.

+ +

And then the other half of, like, I think you alluded to this earlier around systems. Like, how do you take a goal that's important to you and actually act every day in ways that move you towards that goal? So yeah, interested in talking to people about both of those. I do some workshops as well, so people can reach out to me at evan@evanhammer.com. I can also put anybody on my mailing list. I do some workshops around both those things.

+ +

VICTORIA: Wonderful. Thank you so much, Evan, for joining us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Evan Hammer.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+eZXxy26b + + ]]> + + Victoria Guido + Evan Hammer + + + thoughtbot's Incubator Program Mini Season 3 - Episode 03: Knect with Josh Herzig-Marx + https://podcast.thoughtbot.com/s3e3incubatorjosh + c23decc2-4eff-4117-b30b-f343c4b92562 + Tue, 28 Nov 2023 12:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + A key focus of Josh's second episode is the importance of user research and customer discovery. Josh stresses that talking to users is crucial, as it grounds the development process in reality. thoughtbot's Director of Product Strategy, Jordyn Bonds, adds that direct engagement with users builds empathy and understanding within the team, making it more effective. + +They also discuss the challenges of identifying a product's target audience and the importance of iterative customer feedback. Josh and Jordyn highlight the need for founders to be resilient and open to feedback, even when it's negative. + 24:31 + no + + If you missed the first episode with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can go here first (https://www.giantrobots.fm/incubators3e1josh) to catch up. +A key focus of Josh's second episode is the importance of user research and customer discovery. Josh stresses that talking to users is crucial, as it grounds the development process in reality. thoughtbot's Director of Product Strategy, Jordyn Bonds, adds that direct engagement with users builds empathy and understanding within the team, making it more effective. +They also discuss the challenges of identifying a product's target audience and the importance of iterative customer feedback. Josh and Jordyn highlight the need for founders to be resilient and open to feedback, even when it's negative. +Transcript: +JOSH: We're live. +DAWN: Welcome. Thanks, everyone, for joining. I'm Dawn. I am going to be emceeing today, facilitating, really just asking questions and letting these great people talk. Filling in for Lindsey, who is usually here. Thanks for being here. We're excited to talk to everyone and hear your comments and questions. +You might be familiar with thoughtbot. We're a product design and development consultancy. And we like to help people make products or make products better. We are currently in our third incubator session. And today, we're talking to one of two founding teams. +And in case you aren't familiar with the incubator, it's an eight-week program that we run with founders. We pair founders up with a product quad from thoughtbot. And we undergo market research, customer discovery, basically market and product validation exercises to help us hone in on a solution, a potential solution for the problem that we're trying to solve, and build a product plan with the founder, basically set them off on a path for success, hopefully, and next steps. Do you want to kick us off, Jordyn? +JORDYN: Yes. +DAWN: Tell the people about yourself. +JORDYN: I'm Jordyn. I'm the Director of Product Strategy on Dawn's team. Dawn is my boss. And I sort of run the incubator. I have also founded two startups and been the first head of product at two others, so four early-stage startups. +JOSH: I'm Josh. I am the founder part of this who is working with the thoughtbot incubator. I founded a startup. I wasn't very good at it. I was very lucky at it. I was head of product at a whole series of other startups. And I enjoy that a lot. +A few folks have asked me why I wanted to join the thoughtbot incubator if I've done this before. I'm, like, moderately techie for a non-technical person. And I coach other founders in doing the sorts of things that Jordyn and her team are coaching me on. So, I'm doing this thing for a few reasons. One is being a founder is really, really lonely. But the other one is that there's just a huge value in bringing together the diverse set of perspectives. And we're doing that with a company that's really good at getting complicated things out the door, having them be successful through a focus on who the end user is. +It kind of felt like a no-brainer because I felt like—and we talked about this last week—I had the Josh problem that I wanted there to be a solution to. And trying to figure out, is there a larger opportunity that this represents? +DAWN: Thanks. Well, you cued us up well for the topic, at least that we're going to start with today, which is user research or customer discovery. I think it probably goes by several names. That's another interesting topic we [laughs] could get into. But what is this user research that you're doing? Why is it important? What's it doing for this team at this stage? +JOSH: One of the founders I work with asked me a couple of months ago, "Just remind me again, what are the things I have to do to build a product?" And I'm like, "It's actually really easy," right? My, like, standing on one foot advice is talk to users, mostly customers. Bring your engineers along when you can. And if you do those things, mostly everything will work out. But I think it's actually, like, there's some subtlety in all of those things, right? +It's not that talking to users or customers is going to solve all of your problems. It's just that you're not going to make any progress in the absence of doing that, right? Because then you're just talking to yourself. And I don't know about everybody else here in this group or who might be listening, but it's really easy to get yourself all spun up inside of your head if you're only talking to yourself. Users are the ones who ground you, right? And ultimately, users are the ones who could turn to customers. So, why customers, right? As the people you really want to be talking to. Now, we don't have any customers yet, so we can't do that. +But you know something about customers more than anybody else, and that's they're willing to pay for the thing, for the problem you're trying to solve. They could be paying in money. They could be paying in time. They could be paying in reputation. Oftentimes, they'll be paying in all three of those things or two out of three of those things. But they have an expressed willingness to pay. And that's really the magic of, like, having a product and having those conversations. +Now, why do you bring along your engineers? It's because the most effective tech companies...and I think thoughtbot is maybe unusual in design-build firms in really internalizing this, but the most successful tech companies are the ones where the entire organization is aligned around understanding who is our market? Who is our customer? What is their problem, and what does it take to solve that problem for them? +And too often, all that stuff is, like, stuck inside of the founder's head, or the sales team's head, or the marketing team's head, or the product manager's head, or little bits of stories are stuck other places. But when we're all listening to the same conversations, that's when it's most effective to build alignment around who's the customer? What are their needs? What would they pay for? +JORDYN: I agree. And I would add some detail there that why does it work like that? How does having everyone at the organization talk to users and customers build that alignment? And it's one of those things that's kind of, like, it has to be seen to be believed in a certain way. But, like, you can break it down. You know, we can all sit in a room and argue about what reality looks like out there. But it's a lot more efficient if we're all living in that reality together. There's a lot less bringing everyone along. +If you've got skeptics on your team, and I hope that you do because they're very useful people, they want to hear it from the source. So, great, go have them hear it from the source. And there's nothing that's more motivating as an engineer, having been an engineer, than seeing someone live fail to achieve their goal in the piece of software you're working on. You will turn around and go fix that bug right then. A bug that has maybe been sitting at the top of the backlog for, like, six weeks or six months, when you see someone struggling with it [laughs] in action, you'll be like, oh, I see. Okay, this is actually causing a lot of angst out there, and I... +So, anyway, building that empathy, it's always easiest to build it directly. And it's harder if I am here and if I'm having to triangulate empathy through someone else. Like, if only one person on your team is talking to users and listening to users, and then they come back to the team, and they're like, "Here's what I'm hearing," maybe the team believes you. Maybe they hear the same things out of your mouth that they would have heard directly out of the user, but probably not [laughs]. +So, it sounds less efficient. People resist it because it feels intuitively, I think, to a lot of people like a waste of time to have engineers doing user interviews or having anyone else. There's a lot of pushback at organizations for doing this for different reasons. If you're doing, like, an enterprise SaaS thing, sales might really not want anyone else talking to customers because they worry it's going to erode that relationship that they feel like they have. +Nothing could be further from the truth in my experience. Customers feel valued. The more people on your team they talk to, the more they are listened to, the more they are taken seriously, and, like, have people engaging with them, that only bolsters your relationship with them, not the opposite. But either way, it's just much more efficient when everyone is hearing the thing from the people it's impacting directly. I get that that does not intuitively feel true, but I assure you that it is true. +DAWN: So, -- +JOSH: And even more so at this stage where our experience as designers or engineers is much less important than our experience as team members who are trying to find who is that initial audience going to be who is so motivated they will let us build a product for them? +DAWN: That's exactly what my follow-up question was related to, which is there's this sort of perception that you sort of stay in your lane, right? With the different roles that you occupy [laughs] in an organization, whether it's early stage or later stage. And even for people who are participating in that customer discovery, you kind of want to, like, ask questions that are most relevant to your role. +So, how do you, like, prepare teams or, you know, offer guidance to teams to help them sort of get into the right mindset going into those conversations, not so that they execute it perfectly because they have to have some UX design background, but so that you can learn the important things? +JOSH: I think it is totally natural for someone to feel unprepared coming into these, but that's okay, right? Their job is to develop this as a skill, and the only way they're going to do that is by actually doing it. I am certain there were people on the thoughtbot team who felt uncomfortable doing this for the first time, talking to somebody who wasn't even a user, a rando who Josh found on the internet who was willing to chat and go talk to them. +And I know they got better at it because I get to watch everybody's interview recordings, and I get to watch the notes they're taking. And I get to watch my own. And we have, like, a team of five of us who, like, are all getting better at this, and that's good. These things are skills, and you got to practice them, which, putting on my friends of thoughtbot hat, is, I think, one of the reasons why thoughtbot likes to do these things because it's a chance to develop these skills in a really intense way, which we may not otherwise get to. +And it's a thing that, you know, as a founder, I want everybody on my team to be getting good at as quickly as possible. So, sure, prep work. You read a book. It's like baking a cake, right? You know, you can read cookbooks. You can walk up and down the aisle at the supermarket, right? You can go to the bakery and try other people's cakes, but until your arms are deep in flour, butter, and sugar, like, you've no idea what you're really talking about. And I just want to get people making a mess in the kitchen as fast as possible. Nothing bad happens if you have a bad interview. Lots of bad things happen if you never interview. That's my very strong opinion. +JORDYN: I share the opinion and its intensity. That is exactly how I would have answered. +JOSH: [laughs] +JORDYN: There's no substitute for doing the thing. And you can spend your whole life feeling like you're not ready to do the thing. You're not going to learn and get better at it until you just start doing it. It's like...and, Josh, you are right. That is partly what this incubator is for, both internally and externally. +One of the main differentiators of what we're doing here with this incubator from other incubator programs out there is we get into the kitchen with you and get our arms and elbow deep in flour with you so that we can help founders, not necessarily Josh who has brought some skills into this with him, but, like, so that you know what it feels like to do the thing. +There's a lot of content out there about how to start a company, how to do customer discovery, all this stuff, and you can read all of that stuff. You can also listen to people talk about it all the livelong day. There are tons of people out there who do this all the time. They are on podcasts. They are here on this live stream. That's cool [laughs]. Like, listen to them. +But really, there's no substitute for you getting out there and talking to people. And this, I just cannot stress this, like, so many people...given my role here and what I do, people often bring their startup ideas to me. People at thoughtbot, people outside of thoughtbot they say, "I have this idea." I ask, "Who is it for?" They tell me. I say, "Have you talked to those people?" and they say, "I'm not ready to start talking to people yet." +And I'm like, "That is incorrect. You're talking to me. The only way you're going to get to a thing is if you start talking to people, like, yesterday." And they resist. "Well, I still need to figure out." And I'm like, "No, you don't need [laughs] to figure anything out." If you're going to build something for someone, go engage with them, learn what their life is like, what their work is like today. Hello, people listening to this, do this today. +JOSH: Jordyn talks a lot about the emotional labor of being a founder, and I think it's really important. Like, hey, founders out there who hear this and they feel a bit overwhelmed, that's okay, right? The thing which you're going to learn how to do as a founder is talk to people about the thing you're trying to do and have people give you feedback you don't like, and it's not fun. +You know, I work with a lot of very technical founders, and it's amazing the things people will do to avoid that. They will take their savings, their retirement money out of the bank and plow it into design-build firms. They will quit their jobs to build this thing themselves just to avoid having that potentially unpleasant conversation. +So, potential founders, if you want to prepare yourself for being a successful founder or even a mediocre founder, the thing which you need to do is [laughs] improve your frustration tolerance. Get really good at people telling you your idea is bad, or your process is bad, or something else is bad. And maybe they're right, and maybe they're wrong, and it doesn't matter. But you got to be able to tolerate that. +JORDYN: Yes, you have to be able to tolerate that. And you have to be able to actually, like, listen for the relevant feedback that's buried in there. So, the founder Josh just described was me, P.S. +JOSH: [laughs] +JORDYN: The first time. +JOSH: Not just you. +JORDYN: And not just me, not merely me, but it was me. You know, technical background definitely plowed my meager savings—because I'd already been working in startups, which does not pay well, newsflash [laughs]. I don't know if any of you know this; they don't pay well—into a product that I hadn't really spoken to very many people about. But I knew that I needed to start talking about it with people, but I didn't know how to do that well. That's okay. So, I started talking to people about it after the fact. I should have done this sooner. That's cool. +My first company was this product called TallyLab. Like, you can think of it like a data diary app. Basically, it's a place you can go and collect small data to kind of figure out, like, if you think you have a food allergy. Think of it like a food allergy notebook but a digital app for it. I think that when the moon is full, and I eat over a pint of strawberries, I get a stomach ache, whatever it is. So, you need to track the cycles of the moon and how much strawberries you ate and when, and then you can do this analysis. +Anyway, if you're thinking to yourself, that doesn't sound like a business, you are correct. Anyway [laughs], I was describing this to my friend's dad. My friend had just had her first kid. I was over meeting this baby. Her dad was there. And he was just like, "What do you do?" And I was like, "Oh, I have a startup." He's like, "What's your startup do?" And I told him. And he was like, "Sounds like you're just feeding people's OCD to me." +Like, I felt physical pain at that reaction to this. Like, he was like not only...his tone was so derisive [laughs]. But, like, there was information for me in that. First of all, I needed to think about who is this guy. Where is he coming from? Does this have anything to do with his life at all? Should I even listen to this? In fact, maybe he's, like, my anti-ideal customer. And this feedback is great for me because it means my ideal customer is a good fit, whatever. There's information in there, right? +But this was some of the first feedback I was getting on this from someone in the wild [laughs]. So, I had to dig that dagger right out of my heart. So, it's going to happen. It's going to happen, but you got to, like, steel yourself for it, like Josh says. And you also find a way to respond to it with curiosity. +So, if I could go back in time to that conversation...I just changed the subject immediately, I think, at the time. I was like, "Cool. Let's talk about something else [laughs]." What I should have done is been like, "Tell me more. Why does it strike you like that? Tell me more about this problem in your life," right? That was an opportunity for me to have a customer interview, and I just totally whiffed it [laughs]. +DAWN: Hopefully, it didn't harm your relationship with your friend [laughs]. +JORDYN: Not at all. Not at all. I think she felt somewhat aghast. She was like, "Dad, lay off." [laughs] +JOSH: Which is actually the other lesson to take from this, which is these things all feel really important and personal and, like, present to you as the founder. Nobody else gives a shit. +JORDYN: No. And this was a lesson for me. I at least didn't have that problem because I had been in a series of touring rock bands, and I had learned over and over again how little anything I was doing mattered to anyone. Like, you know, you get to the point where, like, you walk offstage, and you're like, "That was the worst set we ever played." No one knows that. No one cares. They were, like, talking to their girlfriend at the bar the whole time, like, whatever, man [laughs]. +Like, whatever is going on with you, you as a human are maybe this big in their purview. What you're doing professionally is even smaller. So, like, don't sweat it. They're not going to be thinking about it again, ever [laughs]. +DAWN: That's the thing. Maybe your startup idea doesn't matter, but you matter. Everyone here matters. Okay? +JORDYN: Yes. +DAWN: So, I want to go back to the users or the particular customers in this case. Have there been any surprises? Have there been any daggers out there or any delights? What have you been learning? +JOSH: Last time we were speaking, we were basically talking to a convenient sample of people who, let's be honest, look a lot like Jordyn and myself, right? They are people in mostly U.S. tech companies, mostly early-stage ones, not necessarily programmers, but maybe they found the company. Maybe they work in product management, or they have other kinds of executive roles. Maybe they change their job every couple of years because that's what people in tech companies do. +Maybe they like, you know, they carry around a smartphone. They live out of their smartphone. They care about building a network. They attend in-person things when they can. They're in a bunch of, like, networking Slacks, and WhatsApp groups, and things like that. And they all kind of look the same. +And I think the last time we spoke two weeks ago, we were noticing that this thing we were trying to work on was a problem for all of them but not necessarily a problem that they were, on average, investing a whole lot of time and energy into. We recognized this as a group largely because everybody was participating in the conversations and getting better and better at it and getting better and better at kind of, like, pulling out the insights. +So, we experimented with a couple of other audiences. And the reminder here is the idea isn't to build a product for one of these audiences; the idea is to build the first version of the product for one of these audiences who feels the need so intensely they're actually going to use the damn thing and give you some feedback. So, the audience has to have a real pain–a willingness to do some work. And we have to be able to find them, so some attribute that allows us to identify where they are. +They all hang out at the playground after recess is, like, a good attribute, or they all search for the same kinds of things using the same language or a comparable language on Google, or they all follow the same people on TikTok. They are all examples of audiences that we could somehow identify and address. People who, you know, deep down, are worried that their second-grade teacher didn't like them enough, right? Probably not an addressable audience, even though you can imagine, you know, all sorts of potential problems and potential solutions you can build for those folks. So, we got to find that. +So, we've experimented with a few other groups. One is we identified early on in kind of our broader conversations that journalists might have a need for this, journalists or folks that have a broad network, and they check in with those people frequently. And the other one was people who do Biz Dev, or partnerships work at tech companies as well. And we reached out to a bunch of people. And we discovered that both those groups are probably also a little bit too big for us to be focused on. +It's not that nobody in those groups had a burning need for the thing that we're trying to do; it's that people in those groups overall didn't. And now we got to go figure out, like, okay, is there, like, a subgroup inside of there that we can identify? Just sports journalists, just investigative journalists, just journalists who don't have a salary who work freelance, just radio journalists, you know, just journalists who went to specific schools. Hard to know what that's going to be, and that's the work that we're doing, like, literally right now. +JORDYN: We actually published our methodology for doing this recently. People should go to thoughtbot.com and look at our Playbook, our Customer Discovery Playbook, if you want to know how to do this. It is not black magic or something. Basically, you just think about the dynamics that matter that create a need for the thing that you're contemplating building, and then you just generate giant lists of the people who might need that thing. +And guess what? It's going to be totally wrong and weird, and a bunch of different shaped groups of people. It is going to be like people who hang out at the playground and also dog walkers, and just, like, some weird random assortment of personas, individuals, groups of people, but that's where you start. And then you start learning. You take what you know about those people today, and you find the best place to start. And then you start talking to them, and then you learn why they are or are not a good fit, and you keep going through the list. So, it's not mysterious, but it is work. It is hard work. +Synthesizing on a team what you're hearing is part of that hard work, but it's really invaluable because everybody, like Josh mentioned earlier, brings something different to the conversation, thinks about it from a different vantage, brings different life experiences. And that is just invaluable to unlocking insights, perspectives, directions to pursue. It really is very much a...I don't know what we would call it. It's like a real...it's the hard work. +You go talk to a bunch of people. You get together as a group, and you talk to each other about what you're hearing from all the other people [laughs]. You go back and talk to more people or the same people if you realized you weren't asking them the things that you needed to be asking them. You come back together. And out of that process, the patterns emerge. +DAWN: This is also kind of meta, the fact that y'all are doing so much customer discovery with potential customers who their entire work lives [laughs] are managing conversations, both the frequency and timing of that, but also, like, what they're learning from those conversations. So, that's super interesting. +It sounds like, obviously, there are still many conversations to be had. But what else is next? I know we're about halfway through the program. So, what are y'all looking into for the next week or two? +JOSH: I mean, we don't yet have that audience, which is, I think, a really important part of this and something which I think about all the time as the founder. What does this mean that it's hard to find the audience? Like, what does that tell about the idea, about the opportunity? But I think we've had enough conversations with enough people who have enough similarities in the problems we're trying to solve that I think we're getting good insights into if we knew who would really want this thing; we have some good ideas about how we might be able to help them out. +So, we're starting to actually go through the process of, you know, the really early sketches, the wireframes. And what might a solution look like? Which I think is doing two things, right? One, it helps us to sharpen our thinking a fair amount, right? There's, like, a thing which we can react to as a group, which is not as amorphous as an interview. Like, a sharp, pointy thing we can react to. The second is we're going to start showing this to people. +And not everybody we talk to is going to be, like, our final audience we're building for. That's okay. They can still, like, give us thoughts and give us feedback. And it'll probably change the tenor of the conversations we're having with them. And that's also okay, too, right? We're going to learn different kinds of things than we would in the absence of this. +JORDYN: Yeah. And that is super exciting. And then the other side of that coin becomes feasibility questions. So, this thing that we're imagining, how would we build it? Can we build it? What do we need in order to build it? And so, those conversations are really starting to fire up as we start to imagine a solution. +DAWN: I know there's a really awesome blog post to come from Jordyn that I reviewed [inaudible 22:27] +JORDYN: Wow. Public nudging. +DAWN: [laughs] +JORDYN: I'm late with this blog post, and I'm being publicly nudged. This is so intense; you're right. +DAWN: [laughs] But it's so relevant to exactly what y'all have been talking about. +JORDYN: I know. I know. [laughs] +DAWN: So, [crosstalk 22:40] retroactively point everyone to it. It's really good stuff. +JORDYN: How would you state the problem, Josh, if anyone out there has the problem? +JOSH: The problem we're looking at is people who have a hard time managing their social network in general but their professional social network in particular. You know, that might be, you know there's people you wish you were keeping in touch with, but you just forget to keep in touch with them. Or, you know, you tell somebody to do something in some thread, or some channel, on some social network, or some direct message, and you just kind of forget about that because you don't go back to it. +Or maybe, you know, you're making friends on Discord. You're making friends on Slack. You're making friends out in the real world, but you don't actually, like, add them into your LinkedIn, something like that. Somebody who's having problems like that that's actually done something about it. Did you go and build yourself, like, a spreadsheet? A baby CRM in Notion, or in Coda, or in Airtable? Do you search out a purpose-built tool? +You know, if you think you've ever tried, whether you've been successful or not, to actually solve this problem for yourself, I'd love to talk to you, or Jordyn would love to talk to you. Dawn would probably love to talk to you also. But reach out to any of us any way you can. I got a super Googleable SEO-compatible name, as does Jordyn. So, like, reach out to one of us, and we'd love to chat. +DAWN: Awesome. Well, thanks, y'all. This has been wonderful, as always. And if anybody has questions for the team, feel free to comment on the post afterwards. And we'll see y'all next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + If you missed the first episode with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can go here first to catch up.

+ +

A key focus of Josh's second episode is the importance of user research and customer discovery. Josh stresses that talking to users is crucial, as it grounds the development process in reality. thoughtbot's Director of Product Strategy, Jordyn Bonds, adds that direct engagement with users builds empathy and understanding within the team, making it more effective.

+ +

They also discuss the challenges of identifying a product's target audience and the importance of iterative customer feedback. Josh and Jordyn highlight the need for founders to be resilient and open to feedback, even when it's negative.

+ +

Transcript:

+ +

JOSH: We're live.

+ +

DAWN: Welcome. Thanks, everyone, for joining. I'm Dawn. I am going to be emceeing today, facilitating, really just asking questions and letting these great people talk. Filling in for Lindsey, who is usually here. Thanks for being here. We're excited to talk to everyone and hear your comments and questions.

+ +

You might be familiar with thoughtbot. We're a product design and development consultancy. And we like to help people make products or make products better. We are currently in our third incubator session. And today, we're talking to one of two founding teams.

+ +

And in case you aren't familiar with the incubator, it's an eight-week program that we run with founders. We pair founders up with a product quad from thoughtbot. And we undergo market research, customer discovery, basically market and product validation exercises to help us hone in on a solution, a potential solution for the problem that we're trying to solve, and build a product plan with the founder, basically set them off on a path for success, hopefully, and next steps. Do you want to kick us off, Jordyn?

+ +

JORDYN: Yes.

+ +

DAWN: Tell the people about yourself.

+ +

JORDYN: I'm Jordyn. I'm the Director of Product Strategy on Dawn's team. Dawn is my boss. And I sort of run the incubator. I have also founded two startups and been the first head of product at two others, so four early-stage startups.

+ +

JOSH: I'm Josh. I am the founder part of this who is working with the thoughtbot incubator. I founded a startup. I wasn't very good at it. I was very lucky at it. I was head of product at a whole series of other startups. And I enjoy that a lot.

+ +

A few folks have asked me why I wanted to join the thoughtbot incubator if I've done this before. I'm, like, moderately techie for a non-technical person. And I coach other founders in doing the sorts of things that Jordyn and her team are coaching me on. So, I'm doing this thing for a few reasons. One is being a founder is really, really lonely. But the other one is that there's just a huge value in bringing together the diverse set of perspectives. And we're doing that with a company that's really good at getting complicated things out the door, having them be successful through a focus on who the end user is.

+ +

It kind of felt like a no-brainer because I felt like—and we talked about this last week—I had the Josh problem that I wanted there to be a solution to. And trying to figure out, is there a larger opportunity that this represents?

+ +

DAWN: Thanks. Well, you cued us up well for the topic, at least that we're going to start with today, which is user research or customer discovery. I think it probably goes by several names. That's another interesting topic we [laughs] could get into. But what is this user research that you're doing? Why is it important? What's it doing for this team at this stage?

+ +

JOSH: One of the founders I work with asked me a couple of months ago, "Just remind me again, what are the things I have to do to build a product?" And I'm like, "It's actually really easy," right? My, like, standing on one foot advice is talk to users, mostly customers. Bring your engineers along when you can. And if you do those things, mostly everything will work out. But I think it's actually, like, there's some subtlety in all of those things, right?

+ +

It's not that talking to users or customers is going to solve all of your problems. It's just that you're not going to make any progress in the absence of doing that, right? Because then you're just talking to yourself. And I don't know about everybody else here in this group or who might be listening, but it's really easy to get yourself all spun up inside of your head if you're only talking to yourself. Users are the ones who ground you, right? And ultimately, users are the ones who could turn to customers. So, why customers, right? As the people you really want to be talking to. Now, we don't have any customers yet, so we can't do that.

+ +

But you know something about customers more than anybody else, and that's they're willing to pay for the thing, for the problem you're trying to solve. They could be paying in money. They could be paying in time. They could be paying in reputation. Oftentimes, they'll be paying in all three of those things or two out of three of those things. But they have an expressed willingness to pay. And that's really the magic of, like, having a product and having those conversations.

+ +

Now, why do you bring along your engineers? It's because the most effective tech companies...and I think thoughtbot is maybe unusual in design-build firms in really internalizing this, but the most successful tech companies are the ones where the entire organization is aligned around understanding who is our market? Who is our customer? What is their problem, and what does it take to solve that problem for them?

+ +

And too often, all that stuff is, like, stuck inside of the founder's head, or the sales team's head, or the marketing team's head, or the product manager's head, or little bits of stories are stuck other places. But when we're all listening to the same conversations, that's when it's most effective to build alignment around who's the customer? What are their needs? What would they pay for?

+ +

JORDYN: I agree. And I would add some detail there that why does it work like that? How does having everyone at the organization talk to users and customers build that alignment? And it's one of those things that's kind of, like, it has to be seen to be believed in a certain way. But, like, you can break it down. You know, we can all sit in a room and argue about what reality looks like out there. But it's a lot more efficient if we're all living in that reality together. There's a lot less bringing everyone along.

+ +

If you've got skeptics on your team, and I hope that you do because they're very useful people, they want to hear it from the source. So, great, go have them hear it from the source. And there's nothing that's more motivating as an engineer, having been an engineer, than seeing someone live fail to achieve their goal in the piece of software you're working on. You will turn around and go fix that bug right then. A bug that has maybe been sitting at the top of the backlog for, like, six weeks or six months, when you see someone struggling with it [laughs] in action, you'll be like, oh, I see. Okay, this is actually causing a lot of angst out there, and I...

+ +

So, anyway, building that empathy, it's always easiest to build it directly. And it's harder if I am here and if I'm having to triangulate empathy through someone else. Like, if only one person on your team is talking to users and listening to users, and then they come back to the team, and they're like, "Here's what I'm hearing," maybe the team believes you. Maybe they hear the same things out of your mouth that they would have heard directly out of the user, but probably not [laughs].

+ +

So, it sounds less efficient. People resist it because it feels intuitively, I think, to a lot of people like a waste of time to have engineers doing user interviews or having anyone else. There's a lot of pushback at organizations for doing this for different reasons. If you're doing, like, an enterprise SaaS thing, sales might really not want anyone else talking to customers because they worry it's going to erode that relationship that they feel like they have.

+ +

Nothing could be further from the truth in my experience. Customers feel valued. The more people on your team they talk to, the more they are listened to, the more they are taken seriously, and, like, have people engaging with them, that only bolsters your relationship with them, not the opposite. But either way, it's just much more efficient when everyone is hearing the thing from the people it's impacting directly. I get that that does not intuitively feel true, but I assure you that it is true.

+ +

DAWN: So, --

+ +

JOSH: And even more so at this stage where our experience as designers or engineers is much less important than our experience as team members who are trying to find who is that initial audience going to be who is so motivated they will let us build a product for them?

+ +

DAWN: That's exactly what my follow-up question was related to, which is there's this sort of perception that you sort of stay in your lane, right? With the different roles that you occupy [laughs] in an organization, whether it's early stage or later stage. And even for people who are participating in that customer discovery, you kind of want to, like, ask questions that are most relevant to your role.

+ +

So, how do you, like, prepare teams or, you know, offer guidance to teams to help them sort of get into the right mindset going into those conversations, not so that they execute it perfectly because they have to have some UX design background, but so that you can learn the important things?

+ +

JOSH: I think it is totally natural for someone to feel unprepared coming into these, but that's okay, right? Their job is to develop this as a skill, and the only way they're going to do that is by actually doing it. I am certain there were people on the thoughtbot team who felt uncomfortable doing this for the first time, talking to somebody who wasn't even a user, a rando who Josh found on the internet who was willing to chat and go talk to them.

+ +

And I know they got better at it because I get to watch everybody's interview recordings, and I get to watch the notes they're taking. And I get to watch my own. And we have, like, a team of five of us who, like, are all getting better at this, and that's good. These things are skills, and you got to practice them, which, putting on my friends of thoughtbot hat, is, I think, one of the reasons why thoughtbot likes to do these things because it's a chance to develop these skills in a really intense way, which we may not otherwise get to.

+ +

And it's a thing that, you know, as a founder, I want everybody on my team to be getting good at as quickly as possible. So, sure, prep work. You read a book. It's like baking a cake, right? You know, you can read cookbooks. You can walk up and down the aisle at the supermarket, right? You can go to the bakery and try other people's cakes, but until your arms are deep in flour, butter, and sugar, like, you've no idea what you're really talking about. And I just want to get people making a mess in the kitchen as fast as possible. Nothing bad happens if you have a bad interview. Lots of bad things happen if you never interview. That's my very strong opinion.

+ +

JORDYN: I share the opinion and its intensity. That is exactly how I would have answered.

+ +

JOSH: [laughs]

+ +

JORDYN: There's no substitute for doing the thing. And you can spend your whole life feeling like you're not ready to do the thing. You're not going to learn and get better at it until you just start doing it. It's like...and, Josh, you are right. That is partly what this incubator is for, both internally and externally.

+ +

One of the main differentiators of what we're doing here with this incubator from other incubator programs out there is we get into the kitchen with you and get our arms and elbow deep in flour with you so that we can help founders, not necessarily Josh who has brought some skills into this with him, but, like, so that you know what it feels like to do the thing.

+ +

There's a lot of content out there about how to start a company, how to do customer discovery, all this stuff, and you can read all of that stuff. You can also listen to people talk about it all the livelong day. There are tons of people out there who do this all the time. They are on podcasts. They are here on this live stream. That's cool [laughs]. Like, listen to them.

+ +

But really, there's no substitute for you getting out there and talking to people. And this, I just cannot stress this, like, so many people...given my role here and what I do, people often bring their startup ideas to me. People at thoughtbot, people outside of thoughtbot they say, "I have this idea." I ask, "Who is it for?" They tell me. I say, "Have you talked to those people?" and they say, "I'm not ready to start talking to people yet."

+ +

And I'm like, "That is incorrect. You're talking to me. The only way you're going to get to a thing is if you start talking to people, like, yesterday." And they resist. "Well, I still need to figure out." And I'm like, "No, you don't need [laughs] to figure anything out." If you're going to build something for someone, go engage with them, learn what their life is like, what their work is like today. Hello, people listening to this, do this today.

+ +

JOSH: Jordyn talks a lot about the emotional labor of being a founder, and I think it's really important. Like, hey, founders out there who hear this and they feel a bit overwhelmed, that's okay, right? The thing which you're going to learn how to do as a founder is talk to people about the thing you're trying to do and have people give you feedback you don't like, and it's not fun.

+ +

You know, I work with a lot of very technical founders, and it's amazing the things people will do to avoid that. They will take their savings, their retirement money out of the bank and plow it into design-build firms. They will quit their jobs to build this thing themselves just to avoid having that potentially unpleasant conversation.

+ +

So, potential founders, if you want to prepare yourself for being a successful founder or even a mediocre founder, the thing which you need to do is [laughs] improve your frustration tolerance. Get really good at people telling you your idea is bad, or your process is bad, or something else is bad. And maybe they're right, and maybe they're wrong, and it doesn't matter. But you got to be able to tolerate that.

+ +

JORDYN: Yes, you have to be able to tolerate that. And you have to be able to actually, like, listen for the relevant feedback that's buried in there. So, the founder Josh just described was me, P.S.

+ +

JOSH: [laughs]

+ +

JORDYN: The first time.

+ +

JOSH: Not just you.

+ +

JORDYN: And not just me, not merely me, but it was me. You know, technical background definitely plowed my meager savings—because I'd already been working in startups, which does not pay well, newsflash [laughs]. I don't know if any of you know this; they don't pay well—into a product that I hadn't really spoken to very many people about. But I knew that I needed to start talking about it with people, but I didn't know how to do that well. That's okay. So, I started talking to people about it after the fact. I should have done this sooner. That's cool.

+ +

My first company was this product called TallyLab. Like, you can think of it like a data diary app. Basically, it's a place you can go and collect small data to kind of figure out, like, if you think you have a food allergy. Think of it like a food allergy notebook but a digital app for it. I think that when the moon is full, and I eat over a pint of strawberries, I get a stomach ache, whatever it is. So, you need to track the cycles of the moon and how much strawberries you ate and when, and then you can do this analysis.

+ +

Anyway, if you're thinking to yourself, that doesn't sound like a business, you are correct. Anyway [laughs], I was describing this to my friend's dad. My friend had just had her first kid. I was over meeting this baby. Her dad was there. And he was just like, "What do you do?" And I was like, "Oh, I have a startup." He's like, "What's your startup do?" And I told him. And he was like, "Sounds like you're just feeding people's OCD to me."

+ +

Like, I felt physical pain at that reaction to this. Like, he was like not only...his tone was so derisive [laughs]. But, like, there was information for me in that. First of all, I needed to think about who is this guy. Where is he coming from? Does this have anything to do with his life at all? Should I even listen to this? In fact, maybe he's, like, my anti-ideal customer. And this feedback is great for me because it means my ideal customer is a good fit, whatever. There's information in there, right?

+ +

But this was some of the first feedback I was getting on this from someone in the wild [laughs]. So, I had to dig that dagger right out of my heart. So, it's going to happen. It's going to happen, but you got to, like, steel yourself for it, like Josh says. And you also find a way to respond to it with curiosity.

+ +

So, if I could go back in time to that conversation...I just changed the subject immediately, I think, at the time. I was like, "Cool. Let's talk about something else [laughs]." What I should have done is been like, "Tell me more. Why does it strike you like that? Tell me more about this problem in your life," right? That was an opportunity for me to have a customer interview, and I just totally whiffed it [laughs].

+ +

DAWN: Hopefully, it didn't harm your relationship with your friend [laughs].

+ +

JORDYN: Not at all. Not at all. I think she felt somewhat aghast. She was like, "Dad, lay off." [laughs]

+ +

JOSH: Which is actually the other lesson to take from this, which is these things all feel really important and personal and, like, present to you as the founder. Nobody else gives a shit.

+ +

JORDYN: No. And this was a lesson for me. I at least didn't have that problem because I had been in a series of touring rock bands, and I had learned over and over again how little anything I was doing mattered to anyone. Like, you know, you get to the point where, like, you walk offstage, and you're like, "That was the worst set we ever played." No one knows that. No one cares. They were, like, talking to their girlfriend at the bar the whole time, like, whatever, man [laughs].

+ +

Like, whatever is going on with you, you as a human are maybe this big in their purview. What you're doing professionally is even smaller. So, like, don't sweat it. They're not going to be thinking about it again, ever [laughs].

+ +

DAWN: That's the thing. Maybe your startup idea doesn't matter, but you matter. Everyone here matters. Okay?

+ +

JORDYN: Yes.

+ +

DAWN: So, I want to go back to the users or the particular customers in this case. Have there been any surprises? Have there been any daggers out there or any delights? What have you been learning?

+ +

JOSH: Last time we were speaking, we were basically talking to a convenient sample of people who, let's be honest, look a lot like Jordyn and myself, right? They are people in mostly U.S. tech companies, mostly early-stage ones, not necessarily programmers, but maybe they found the company. Maybe they work in product management, or they have other kinds of executive roles. Maybe they change their job every couple of years because that's what people in tech companies do.

+ +

Maybe they like, you know, they carry around a smartphone. They live out of their smartphone. They care about building a network. They attend in-person things when they can. They're in a bunch of, like, networking Slacks, and WhatsApp groups, and things like that. And they all kind of look the same.

+ +

And I think the last time we spoke two weeks ago, we were noticing that this thing we were trying to work on was a problem for all of them but not necessarily a problem that they were, on average, investing a whole lot of time and energy into. We recognized this as a group largely because everybody was participating in the conversations and getting better and better at it and getting better and better at kind of, like, pulling out the insights.

+ +

So, we experimented with a couple of other audiences. And the reminder here is the idea isn't to build a product for one of these audiences; the idea is to build the first version of the product for one of these audiences who feels the need so intensely they're actually going to use the damn thing and give you some feedback. So, the audience has to have a real pain–a willingness to do some work. And we have to be able to find them, so some attribute that allows us to identify where they are.

+ +

They all hang out at the playground after recess is, like, a good attribute, or they all search for the same kinds of things using the same language or a comparable language on Google, or they all follow the same people on TikTok. They are all examples of audiences that we could somehow identify and address. People who, you know, deep down, are worried that their second-grade teacher didn't like them enough, right? Probably not an addressable audience, even though you can imagine, you know, all sorts of potential problems and potential solutions you can build for those folks. So, we got to find that.

+ +

So, we've experimented with a few other groups. One is we identified early on in kind of our broader conversations that journalists might have a need for this, journalists or folks that have a broad network, and they check in with those people frequently. And the other one was people who do Biz Dev, or partnerships work at tech companies as well. And we reached out to a bunch of people. And we discovered that both those groups are probably also a little bit too big for us to be focused on.

+ +

It's not that nobody in those groups had a burning need for the thing that we're trying to do; it's that people in those groups overall didn't. And now we got to go figure out, like, okay, is there, like, a subgroup inside of there that we can identify? Just sports journalists, just investigative journalists, just journalists who don't have a salary who work freelance, just radio journalists, you know, just journalists who went to specific schools. Hard to know what that's going to be, and that's the work that we're doing, like, literally right now.

+ +

JORDYN: We actually published our methodology for doing this recently. People should go to thoughtbot.com and look at our Playbook, our Customer Discovery Playbook, if you want to know how to do this. It is not black magic or something. Basically, you just think about the dynamics that matter that create a need for the thing that you're contemplating building, and then you just generate giant lists of the people who might need that thing.

+ +

And guess what? It's going to be totally wrong and weird, and a bunch of different shaped groups of people. It is going to be like people who hang out at the playground and also dog walkers, and just, like, some weird random assortment of personas, individuals, groups of people, but that's where you start. And then you start learning. You take what you know about those people today, and you find the best place to start. And then you start talking to them, and then you learn why they are or are not a good fit, and you keep going through the list. So, it's not mysterious, but it is work. It is hard work.

+ +

Synthesizing on a team what you're hearing is part of that hard work, but it's really invaluable because everybody, like Josh mentioned earlier, brings something different to the conversation, thinks about it from a different vantage, brings different life experiences. And that is just invaluable to unlocking insights, perspectives, directions to pursue. It really is very much a...I don't know what we would call it. It's like a real...it's the hard work.

+ +

You go talk to a bunch of people. You get together as a group, and you talk to each other about what you're hearing from all the other people [laughs]. You go back and talk to more people or the same people if you realized you weren't asking them the things that you needed to be asking them. You come back together. And out of that process, the patterns emerge.

+ +

DAWN: This is also kind of meta, the fact that y'all are doing so much customer discovery with potential customers who their entire work lives [laughs] are managing conversations, both the frequency and timing of that, but also, like, what they're learning from those conversations. So, that's super interesting.

+ +

It sounds like, obviously, there are still many conversations to be had. But what else is next? I know we're about halfway through the program. So, what are y'all looking into for the next week or two?

+ +

JOSH: I mean, we don't yet have that audience, which is, I think, a really important part of this and something which I think about all the time as the founder. What does this mean that it's hard to find the audience? Like, what does that tell about the idea, about the opportunity? But I think we've had enough conversations with enough people who have enough similarities in the problems we're trying to solve that I think we're getting good insights into if we knew who would really want this thing; we have some good ideas about how we might be able to help them out.

+ +

So, we're starting to actually go through the process of, you know, the really early sketches, the wireframes. And what might a solution look like? Which I think is doing two things, right? One, it helps us to sharpen our thinking a fair amount, right? There's, like, a thing which we can react to as a group, which is not as amorphous as an interview. Like, a sharp, pointy thing we can react to. The second is we're going to start showing this to people.

+ +

And not everybody we talk to is going to be, like, our final audience we're building for. That's okay. They can still, like, give us thoughts and give us feedback. And it'll probably change the tenor of the conversations we're having with them. And that's also okay, too, right? We're going to learn different kinds of things than we would in the absence of this.

+ +

JORDYN: Yeah. And that is super exciting. And then the other side of that coin becomes feasibility questions. So, this thing that we're imagining, how would we build it? Can we build it? What do we need in order to build it? And so, those conversations are really starting to fire up as we start to imagine a solution.

+ +

DAWN: I know there's a really awesome blog post to come from Jordyn that I reviewed [inaudible 22:27]

+ +

JORDYN: Wow. Public nudging.

+ +

DAWN: [laughs]

+ +

JORDYN: I'm late with this blog post, and I'm being publicly nudged. This is so intense; you're right.

+ +

DAWN: [laughs] But it's so relevant to exactly what y'all have been talking about.

+ +

JORDYN: I know. I know. [laughs]

+ +

DAWN: So, [crosstalk 22:40] retroactively point everyone to it. It's really good stuff.

+ +

JORDYN: How would you state the problem, Josh, if anyone out there has the problem?

+ +

JOSH: The problem we're looking at is people who have a hard time managing their social network in general but their professional social network in particular. You know, that might be, you know there's people you wish you were keeping in touch with, but you just forget to keep in touch with them. Or, you know, you tell somebody to do something in some thread, or some channel, on some social network, or some direct message, and you just kind of forget about that because you don't go back to it.

+ +

Or maybe, you know, you're making friends on Discord. You're making friends on Slack. You're making friends out in the real world, but you don't actually, like, add them into your LinkedIn, something like that. Somebody who's having problems like that that's actually done something about it. Did you go and build yourself, like, a spreadsheet? A baby CRM in Notion, or in Coda, or in Airtable? Do you search out a purpose-built tool?

+ +

You know, if you think you've ever tried, whether you've been successful or not, to actually solve this problem for yourself, I'd love to talk to you, or Jordyn would love to talk to you. Dawn would probably love to talk to you also. But reach out to any of us any way you can. I got a super Googleable SEO-compatible name, as does Jordyn. So, like, reach out to one of us, and we'd love to chat.

+ +

DAWN: Awesome. Well, thanks, y'all. This has been wonderful, as always. And if anybody has questions for the team, feel free to comment on the post afterwards. And we'll see y'all next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + If you missed the first episode with thoughtbot Incubator Program partcipant and founder Josh Herzig-Marks of Knect, you can go here first to catch up.

+ +

A key focus of Josh's second episode is the importance of user research and customer discovery. Josh stresses that talking to users is crucial, as it grounds the development process in reality. thoughtbot's Director of Product Strategy, Jordyn Bonds, adds that direct engagement with users builds empathy and understanding within the team, making it more effective.

+ +

They also discuss the challenges of identifying a product's target audience and the importance of iterative customer feedback. Josh and Jordyn highlight the need for founders to be resilient and open to feedback, even when it's negative.

+ +

Transcript:

+ +

JOSH: We're live.

+ +

DAWN: Welcome. Thanks, everyone, for joining. I'm Dawn. I am going to be emceeing today, facilitating, really just asking questions and letting these great people talk. Filling in for Lindsey, who is usually here. Thanks for being here. We're excited to talk to everyone and hear your comments and questions.

+ +

You might be familiar with thoughtbot. We're a product design and development consultancy. And we like to help people make products or make products better. We are currently in our third incubator session. And today, we're talking to one of two founding teams.

+ +

And in case you aren't familiar with the incubator, it's an eight-week program that we run with founders. We pair founders up with a product quad from thoughtbot. And we undergo market research, customer discovery, basically market and product validation exercises to help us hone in on a solution, a potential solution for the problem that we're trying to solve, and build a product plan with the founder, basically set them off on a path for success, hopefully, and next steps. Do you want to kick us off, Jordyn?

+ +

JORDYN: Yes.

+ +

DAWN: Tell the people about yourself.

+ +

JORDYN: I'm Jordyn. I'm the Director of Product Strategy on Dawn's team. Dawn is my boss. And I sort of run the incubator. I have also founded two startups and been the first head of product at two others, so four early-stage startups.

+ +

JOSH: I'm Josh. I am the founder part of this who is working with the thoughtbot incubator. I founded a startup. I wasn't very good at it. I was very lucky at it. I was head of product at a whole series of other startups. And I enjoy that a lot.

+ +

A few folks have asked me why I wanted to join the thoughtbot incubator if I've done this before. I'm, like, moderately techie for a non-technical person. And I coach other founders in doing the sorts of things that Jordyn and her team are coaching me on. So, I'm doing this thing for a few reasons. One is being a founder is really, really lonely. But the other one is that there's just a huge value in bringing together the diverse set of perspectives. And we're doing that with a company that's really good at getting complicated things out the door, having them be successful through a focus on who the end user is.

+ +

It kind of felt like a no-brainer because I felt like—and we talked about this last week—I had the Josh problem that I wanted there to be a solution to. And trying to figure out, is there a larger opportunity that this represents?

+ +

DAWN: Thanks. Well, you cued us up well for the topic, at least that we're going to start with today, which is user research or customer discovery. I think it probably goes by several names. That's another interesting topic we [laughs] could get into. But what is this user research that you're doing? Why is it important? What's it doing for this team at this stage?

+ +

JOSH: One of the founders I work with asked me a couple of months ago, "Just remind me again, what are the things I have to do to build a product?" And I'm like, "It's actually really easy," right? My, like, standing on one foot advice is talk to users, mostly customers. Bring your engineers along when you can. And if you do those things, mostly everything will work out. But I think it's actually, like, there's some subtlety in all of those things, right?

+ +

It's not that talking to users or customers is going to solve all of your problems. It's just that you're not going to make any progress in the absence of doing that, right? Because then you're just talking to yourself. And I don't know about everybody else here in this group or who might be listening, but it's really easy to get yourself all spun up inside of your head if you're only talking to yourself. Users are the ones who ground you, right? And ultimately, users are the ones who could turn to customers. So, why customers, right? As the people you really want to be talking to. Now, we don't have any customers yet, so we can't do that.

+ +

But you know something about customers more than anybody else, and that's they're willing to pay for the thing, for the problem you're trying to solve. They could be paying in money. They could be paying in time. They could be paying in reputation. Oftentimes, they'll be paying in all three of those things or two out of three of those things. But they have an expressed willingness to pay. And that's really the magic of, like, having a product and having those conversations.

+ +

Now, why do you bring along your engineers? It's because the most effective tech companies...and I think thoughtbot is maybe unusual in design-build firms in really internalizing this, but the most successful tech companies are the ones where the entire organization is aligned around understanding who is our market? Who is our customer? What is their problem, and what does it take to solve that problem for them?

+ +

And too often, all that stuff is, like, stuck inside of the founder's head, or the sales team's head, or the marketing team's head, or the product manager's head, or little bits of stories are stuck other places. But when we're all listening to the same conversations, that's when it's most effective to build alignment around who's the customer? What are their needs? What would they pay for?

+ +

JORDYN: I agree. And I would add some detail there that why does it work like that? How does having everyone at the organization talk to users and customers build that alignment? And it's one of those things that's kind of, like, it has to be seen to be believed in a certain way. But, like, you can break it down. You know, we can all sit in a room and argue about what reality looks like out there. But it's a lot more efficient if we're all living in that reality together. There's a lot less bringing everyone along.

+ +

If you've got skeptics on your team, and I hope that you do because they're very useful people, they want to hear it from the source. So, great, go have them hear it from the source. And there's nothing that's more motivating as an engineer, having been an engineer, than seeing someone live fail to achieve their goal in the piece of software you're working on. You will turn around and go fix that bug right then. A bug that has maybe been sitting at the top of the backlog for, like, six weeks or six months, when you see someone struggling with it [laughs] in action, you'll be like, oh, I see. Okay, this is actually causing a lot of angst out there, and I...

+ +

So, anyway, building that empathy, it's always easiest to build it directly. And it's harder if I am here and if I'm having to triangulate empathy through someone else. Like, if only one person on your team is talking to users and listening to users, and then they come back to the team, and they're like, "Here's what I'm hearing," maybe the team believes you. Maybe they hear the same things out of your mouth that they would have heard directly out of the user, but probably not [laughs].

+ +

So, it sounds less efficient. People resist it because it feels intuitively, I think, to a lot of people like a waste of time to have engineers doing user interviews or having anyone else. There's a lot of pushback at organizations for doing this for different reasons. If you're doing, like, an enterprise SaaS thing, sales might really not want anyone else talking to customers because they worry it's going to erode that relationship that they feel like they have.

+ +

Nothing could be further from the truth in my experience. Customers feel valued. The more people on your team they talk to, the more they are listened to, the more they are taken seriously, and, like, have people engaging with them, that only bolsters your relationship with them, not the opposite. But either way, it's just much more efficient when everyone is hearing the thing from the people it's impacting directly. I get that that does not intuitively feel true, but I assure you that it is true.

+ +

DAWN: So, --

+ +

JOSH: And even more so at this stage where our experience as designers or engineers is much less important than our experience as team members who are trying to find who is that initial audience going to be who is so motivated they will let us build a product for them?

+ +

DAWN: That's exactly what my follow-up question was related to, which is there's this sort of perception that you sort of stay in your lane, right? With the different roles that you occupy [laughs] in an organization, whether it's early stage or later stage. And even for people who are participating in that customer discovery, you kind of want to, like, ask questions that are most relevant to your role.

+ +

So, how do you, like, prepare teams or, you know, offer guidance to teams to help them sort of get into the right mindset going into those conversations, not so that they execute it perfectly because they have to have some UX design background, but so that you can learn the important things?

+ +

JOSH: I think it is totally natural for someone to feel unprepared coming into these, but that's okay, right? Their job is to develop this as a skill, and the only way they're going to do that is by actually doing it. I am certain there were people on the thoughtbot team who felt uncomfortable doing this for the first time, talking to somebody who wasn't even a user, a rando who Josh found on the internet who was willing to chat and go talk to them.

+ +

And I know they got better at it because I get to watch everybody's interview recordings, and I get to watch the notes they're taking. And I get to watch my own. And we have, like, a team of five of us who, like, are all getting better at this, and that's good. These things are skills, and you got to practice them, which, putting on my friends of thoughtbot hat, is, I think, one of the reasons why thoughtbot likes to do these things because it's a chance to develop these skills in a really intense way, which we may not otherwise get to.

+ +

And it's a thing that, you know, as a founder, I want everybody on my team to be getting good at as quickly as possible. So, sure, prep work. You read a book. It's like baking a cake, right? You know, you can read cookbooks. You can walk up and down the aisle at the supermarket, right? You can go to the bakery and try other people's cakes, but until your arms are deep in flour, butter, and sugar, like, you've no idea what you're really talking about. And I just want to get people making a mess in the kitchen as fast as possible. Nothing bad happens if you have a bad interview. Lots of bad things happen if you never interview. That's my very strong opinion.

+ +

JORDYN: I share the opinion and its intensity. That is exactly how I would have answered.

+ +

JOSH: [laughs]

+ +

JORDYN: There's no substitute for doing the thing. And you can spend your whole life feeling like you're not ready to do the thing. You're not going to learn and get better at it until you just start doing it. It's like...and, Josh, you are right. That is partly what this incubator is for, both internally and externally.

+ +

One of the main differentiators of what we're doing here with this incubator from other incubator programs out there is we get into the kitchen with you and get our arms and elbow deep in flour with you so that we can help founders, not necessarily Josh who has brought some skills into this with him, but, like, so that you know what it feels like to do the thing.

+ +

There's a lot of content out there about how to start a company, how to do customer discovery, all this stuff, and you can read all of that stuff. You can also listen to people talk about it all the livelong day. There are tons of people out there who do this all the time. They are on podcasts. They are here on this live stream. That's cool [laughs]. Like, listen to them.

+ +

But really, there's no substitute for you getting out there and talking to people. And this, I just cannot stress this, like, so many people...given my role here and what I do, people often bring their startup ideas to me. People at thoughtbot, people outside of thoughtbot they say, "I have this idea." I ask, "Who is it for?" They tell me. I say, "Have you talked to those people?" and they say, "I'm not ready to start talking to people yet."

+ +

And I'm like, "That is incorrect. You're talking to me. The only way you're going to get to a thing is if you start talking to people, like, yesterday." And they resist. "Well, I still need to figure out." And I'm like, "No, you don't need [laughs] to figure anything out." If you're going to build something for someone, go engage with them, learn what their life is like, what their work is like today. Hello, people listening to this, do this today.

+ +

JOSH: Jordyn talks a lot about the emotional labor of being a founder, and I think it's really important. Like, hey, founders out there who hear this and they feel a bit overwhelmed, that's okay, right? The thing which you're going to learn how to do as a founder is talk to people about the thing you're trying to do and have people give you feedback you don't like, and it's not fun.

+ +

You know, I work with a lot of very technical founders, and it's amazing the things people will do to avoid that. They will take their savings, their retirement money out of the bank and plow it into design-build firms. They will quit their jobs to build this thing themselves just to avoid having that potentially unpleasant conversation.

+ +

So, potential founders, if you want to prepare yourself for being a successful founder or even a mediocre founder, the thing which you need to do is [laughs] improve your frustration tolerance. Get really good at people telling you your idea is bad, or your process is bad, or something else is bad. And maybe they're right, and maybe they're wrong, and it doesn't matter. But you got to be able to tolerate that.

+ +

JORDYN: Yes, you have to be able to tolerate that. And you have to be able to actually, like, listen for the relevant feedback that's buried in there. So, the founder Josh just described was me, P.S.

+ +

JOSH: [laughs]

+ +

JORDYN: The first time.

+ +

JOSH: Not just you.

+ +

JORDYN: And not just me, not merely me, but it was me. You know, technical background definitely plowed my meager savings—because I'd already been working in startups, which does not pay well, newsflash [laughs]. I don't know if any of you know this; they don't pay well—into a product that I hadn't really spoken to very many people about. But I knew that I needed to start talking about it with people, but I didn't know how to do that well. That's okay. So, I started talking to people about it after the fact. I should have done this sooner. That's cool.

+ +

My first company was this product called TallyLab. Like, you can think of it like a data diary app. Basically, it's a place you can go and collect small data to kind of figure out, like, if you think you have a food allergy. Think of it like a food allergy notebook but a digital app for it. I think that when the moon is full, and I eat over a pint of strawberries, I get a stomach ache, whatever it is. So, you need to track the cycles of the moon and how much strawberries you ate and when, and then you can do this analysis.

+ +

Anyway, if you're thinking to yourself, that doesn't sound like a business, you are correct. Anyway [laughs], I was describing this to my friend's dad. My friend had just had her first kid. I was over meeting this baby. Her dad was there. And he was just like, "What do you do?" And I was like, "Oh, I have a startup." He's like, "What's your startup do?" And I told him. And he was like, "Sounds like you're just feeding people's OCD to me."

+ +

Like, I felt physical pain at that reaction to this. Like, he was like not only...his tone was so derisive [laughs]. But, like, there was information for me in that. First of all, I needed to think about who is this guy. Where is he coming from? Does this have anything to do with his life at all? Should I even listen to this? In fact, maybe he's, like, my anti-ideal customer. And this feedback is great for me because it means my ideal customer is a good fit, whatever. There's information in there, right?

+ +

But this was some of the first feedback I was getting on this from someone in the wild [laughs]. So, I had to dig that dagger right out of my heart. So, it's going to happen. It's going to happen, but you got to, like, steel yourself for it, like Josh says. And you also find a way to respond to it with curiosity.

+ +

So, if I could go back in time to that conversation...I just changed the subject immediately, I think, at the time. I was like, "Cool. Let's talk about something else [laughs]." What I should have done is been like, "Tell me more. Why does it strike you like that? Tell me more about this problem in your life," right? That was an opportunity for me to have a customer interview, and I just totally whiffed it [laughs].

+ +

DAWN: Hopefully, it didn't harm your relationship with your friend [laughs].

+ +

JORDYN: Not at all. Not at all. I think she felt somewhat aghast. She was like, "Dad, lay off." [laughs]

+ +

JOSH: Which is actually the other lesson to take from this, which is these things all feel really important and personal and, like, present to you as the founder. Nobody else gives a shit.

+ +

JORDYN: No. And this was a lesson for me. I at least didn't have that problem because I had been in a series of touring rock bands, and I had learned over and over again how little anything I was doing mattered to anyone. Like, you know, you get to the point where, like, you walk offstage, and you're like, "That was the worst set we ever played." No one knows that. No one cares. They were, like, talking to their girlfriend at the bar the whole time, like, whatever, man [laughs].

+ +

Like, whatever is going on with you, you as a human are maybe this big in their purview. What you're doing professionally is even smaller. So, like, don't sweat it. They're not going to be thinking about it again, ever [laughs].

+ +

DAWN: That's the thing. Maybe your startup idea doesn't matter, but you matter. Everyone here matters. Okay?

+ +

JORDYN: Yes.

+ +

DAWN: So, I want to go back to the users or the particular customers in this case. Have there been any surprises? Have there been any daggers out there or any delights? What have you been learning?

+ +

JOSH: Last time we were speaking, we were basically talking to a convenient sample of people who, let's be honest, look a lot like Jordyn and myself, right? They are people in mostly U.S. tech companies, mostly early-stage ones, not necessarily programmers, but maybe they found the company. Maybe they work in product management, or they have other kinds of executive roles. Maybe they change their job every couple of years because that's what people in tech companies do.

+ +

Maybe they like, you know, they carry around a smartphone. They live out of their smartphone. They care about building a network. They attend in-person things when they can. They're in a bunch of, like, networking Slacks, and WhatsApp groups, and things like that. And they all kind of look the same.

+ +

And I think the last time we spoke two weeks ago, we were noticing that this thing we were trying to work on was a problem for all of them but not necessarily a problem that they were, on average, investing a whole lot of time and energy into. We recognized this as a group largely because everybody was participating in the conversations and getting better and better at it and getting better and better at kind of, like, pulling out the insights.

+ +

So, we experimented with a couple of other audiences. And the reminder here is the idea isn't to build a product for one of these audiences; the idea is to build the first version of the product for one of these audiences who feels the need so intensely they're actually going to use the damn thing and give you some feedback. So, the audience has to have a real pain–a willingness to do some work. And we have to be able to find them, so some attribute that allows us to identify where they are.

+ +

They all hang out at the playground after recess is, like, a good attribute, or they all search for the same kinds of things using the same language or a comparable language on Google, or they all follow the same people on TikTok. They are all examples of audiences that we could somehow identify and address. People who, you know, deep down, are worried that their second-grade teacher didn't like them enough, right? Probably not an addressable audience, even though you can imagine, you know, all sorts of potential problems and potential solutions you can build for those folks. So, we got to find that.

+ +

So, we've experimented with a few other groups. One is we identified early on in kind of our broader conversations that journalists might have a need for this, journalists or folks that have a broad network, and they check in with those people frequently. And the other one was people who do Biz Dev, or partnerships work at tech companies as well. And we reached out to a bunch of people. And we discovered that both those groups are probably also a little bit too big for us to be focused on.

+ +

It's not that nobody in those groups had a burning need for the thing that we're trying to do; it's that people in those groups overall didn't. And now we got to go figure out, like, okay, is there, like, a subgroup inside of there that we can identify? Just sports journalists, just investigative journalists, just journalists who don't have a salary who work freelance, just radio journalists, you know, just journalists who went to specific schools. Hard to know what that's going to be, and that's the work that we're doing, like, literally right now.

+ +

JORDYN: We actually published our methodology for doing this recently. People should go to thoughtbot.com and look at our Playbook, our Customer Discovery Playbook, if you want to know how to do this. It is not black magic or something. Basically, you just think about the dynamics that matter that create a need for the thing that you're contemplating building, and then you just generate giant lists of the people who might need that thing.

+ +

And guess what? It's going to be totally wrong and weird, and a bunch of different shaped groups of people. It is going to be like people who hang out at the playground and also dog walkers, and just, like, some weird random assortment of personas, individuals, groups of people, but that's where you start. And then you start learning. You take what you know about those people today, and you find the best place to start. And then you start talking to them, and then you learn why they are or are not a good fit, and you keep going through the list. So, it's not mysterious, but it is work. It is hard work.

+ +

Synthesizing on a team what you're hearing is part of that hard work, but it's really invaluable because everybody, like Josh mentioned earlier, brings something different to the conversation, thinks about it from a different vantage, brings different life experiences. And that is just invaluable to unlocking insights, perspectives, directions to pursue. It really is very much a...I don't know what we would call it. It's like a real...it's the hard work.

+ +

You go talk to a bunch of people. You get together as a group, and you talk to each other about what you're hearing from all the other people [laughs]. You go back and talk to more people or the same people if you realized you weren't asking them the things that you needed to be asking them. You come back together. And out of that process, the patterns emerge.

+ +

DAWN: This is also kind of meta, the fact that y'all are doing so much customer discovery with potential customers who their entire work lives [laughs] are managing conversations, both the frequency and timing of that, but also, like, what they're learning from those conversations. So, that's super interesting.

+ +

It sounds like, obviously, there are still many conversations to be had. But what else is next? I know we're about halfway through the program. So, what are y'all looking into for the next week or two?

+ +

JOSH: I mean, we don't yet have that audience, which is, I think, a really important part of this and something which I think about all the time as the founder. What does this mean that it's hard to find the audience? Like, what does that tell about the idea, about the opportunity? But I think we've had enough conversations with enough people who have enough similarities in the problems we're trying to solve that I think we're getting good insights into if we knew who would really want this thing; we have some good ideas about how we might be able to help them out.

+ +

So, we're starting to actually go through the process of, you know, the really early sketches, the wireframes. And what might a solution look like? Which I think is doing two things, right? One, it helps us to sharpen our thinking a fair amount, right? There's, like, a thing which we can react to as a group, which is not as amorphous as an interview. Like, a sharp, pointy thing we can react to. The second is we're going to start showing this to people.

+ +

And not everybody we talk to is going to be, like, our final audience we're building for. That's okay. They can still, like, give us thoughts and give us feedback. And it'll probably change the tenor of the conversations we're having with them. And that's also okay, too, right? We're going to learn different kinds of things than we would in the absence of this.

+ +

JORDYN: Yeah. And that is super exciting. And then the other side of that coin becomes feasibility questions. So, this thing that we're imagining, how would we build it? Can we build it? What do we need in order to build it? And so, those conversations are really starting to fire up as we start to imagine a solution.

+ +

DAWN: I know there's a really awesome blog post to come from Jordyn that I reviewed [inaudible 22:27]

+ +

JORDYN: Wow. Public nudging.

+ +

DAWN: [laughs]

+ +

JORDYN: I'm late with this blog post, and I'm being publicly nudged. This is so intense; you're right.

+ +

DAWN: [laughs] But it's so relevant to exactly what y'all have been talking about.

+ +

JORDYN: I know. I know. [laughs]

+ +

DAWN: So, [crosstalk 22:40] retroactively point everyone to it. It's really good stuff.

+ +

JORDYN: How would you state the problem, Josh, if anyone out there has the problem?

+ +

JOSH: The problem we're looking at is people who have a hard time managing their social network in general but their professional social network in particular. You know, that might be, you know there's people you wish you were keeping in touch with, but you just forget to keep in touch with them. Or, you know, you tell somebody to do something in some thread, or some channel, on some social network, or some direct message, and you just kind of forget about that because you don't go back to it.

+ +

Or maybe, you know, you're making friends on Discord. You're making friends on Slack. You're making friends out in the real world, but you don't actually, like, add them into your LinkedIn, something like that. Somebody who's having problems like that that's actually done something about it. Did you go and build yourself, like, a spreadsheet? A baby CRM in Notion, or in Coda, or in Airtable? Do you search out a purpose-built tool?

+ +

You know, if you think you've ever tried, whether you've been successful or not, to actually solve this problem for yourself, I'd love to talk to you, or Jordyn would love to talk to you. Dawn would probably love to talk to you also. But reach out to any of us any way you can. I got a super Googleable SEO-compatible name, as does Jordyn. So, like, reach out to one of us, and we'd love to chat.

+ +

DAWN: Awesome. Well, thanks, y'all. This has been wonderful, as always. And if anybody has questions for the team, feel free to comment on the post afterwards. And we'll see y'all next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8qVh5Fyt + + ]]> + + Lindsey Christensen + + + 501: GNOME and OpenKids Africa with Regina Nkenchor + https://podcast.thoughtbot.com/501 + dc62b129-5109-4017-bd1e-0516f9cb22ff + Wed, 22 Nov 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Host Victoria Guido and special guest Regina Nkenchor discuss the evolution and impact of Regina's work with the GNOME Project and OpenKids Africa. Regina explains how the GNOME Project is advancing its Global Inclusive Initiative, aiming to amplify diverse voices within the community and contribute to GNOME's development. She expresses enthusiasm for OpenKids Africa's efforts to incorporate technology education in rural communities, primarily through engaging early childhood teachers in understanding and teaching tech like virtual reality and robotics. + +Victoria probes into strategies for sparking children's interest in technology, with Regina advocating for a co-creative, experience-based approach that includes real-life applications and interactive participation. They also touch on the challenges of balancing professional and personal commitments. Regina shares her ongoing journey to find balance by prioritizing and delegating while still maintaining her nonprofit work and her role at the GNOME Project. + +They also talk about personal growth and community engagement. Regina advises newcomers to leverage open-source tools and be open to change while encouraging fair treatment within the open-source community. Victoria reflects on her experiences with Women Who Code, highlighting the importance of community involvement and networking for career advancement. Both emphasize the significance of creating safe, welcoming spaces in tech communities to foster inclusion and support, especially for women in tech. + 38:35 + no + + + Host Victoria Guido and special guest Regina Nkenchor discuss the evolution and impact of Regina's work with the GNOME Project and OpenKids Africa. Regina explains how the GNOME Project is advancing its Global Inclusive Initiative, aiming to amplify diverse voices within the community and contribute to GNOME's development. She expresses enthusiasm for OpenKids Africa's efforts to incorporate technology education in rural communities, primarily through engaging early childhood teachers in understanding and teaching tech like virtual reality and robotics. +Victoria probes into strategies for sparking children's interest in technology, with Regina advocating for a co-creative, experience-based approach that includes real-life applications and interactive participation. They also touch on the challenges of balancing professional and personal commitments. Regina shares her ongoing journey to find balance by prioritizing and delegating while still maintaining her nonprofit work and her role at the GNOME Project. +They also talk about personal growth and community engagement. Regina advises newcomers to leverage open-source tools and be open to change while encouraging fair treatment within the open-source community. Victoria reflects on her experiences with Women Who Code, highlighting the importance of community involvement and networking for career advancement. Both emphasize the significance of creating safe, welcoming spaces in tech communities to foster inclusion and support, especially for women in tech. +GNOME (https://www.gnome.org/) +Follow GNOME on X (https://twitter.com/gnome), Facebook (https://www.facebook.com/GNOME/), LinkedIn (https://www.linkedin.com/company/gnome-foundation/), YouTube (https://www.youtube.com/user/GNOMEDesktop), or Mastodon (https://floss.social/@gnome). +OpenKids Africa (https://openkidsafrica.com/) +Follow OpenKids Africa on LinkedIn (https://www.linkedin.com/company/openkidsafrica/), X (https://twitter.com/openkidsafrica), YouTube (https://www.youtube.com/@openkidsafrica), Facebook (https://www.facebook.com/openkidsafrica), or Instagram (https://www.instagram.com/openkidsafrica/). +Follow Regina Nkenchor on LinkedIn (https://www.linkedin.com/in/reginankenchor/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Regina, Board Vice President of the GNOME Foundation and Founder at OpenKids Africa. Regina, thank you for joining me. +REGINA: Thank you so much for having me. It's such a great opportunity to be here today. +VICTORIA: That's wonderful. So, what's going on in your world, anything fun or exciting happening? +REGINA: You know, I actually work in Sweden. And this period is actually one of the...let me say the peak period, beginning of a new year, beginning of a new year for my job. So, there's so much around projects, projects, projects. So, I wouldn't say this is more like a fun period because, after the summer, it's a different time here when you're working in Europe. +VICTORIA: Yes, working in Sweden must be so interesting. I'm wondering if you found any cultural differences that were really surprising about working there. +REGINA: Oh yes. I think there are so many cultural differences, one of it is...I come from Nigeria, and we have more, like, a particular way...we don't have a schedule for having breakfast. So, we can have breakfast anytime we want to, and we don't feel any problem by it. So, I could decide to have my breakfast by 12:00 or by 1:00 and have my lunch by 4:00 p.m., you know, it just depends. But here, it's more like you have to have your breakfast early. And by 11:00, 12:00, 1:00, you should be having your lunch. I'm still trying to get used to that one anyway. +And also, another cultural difference that I've seen here that is very, very obvious to me compared to where I'm coming from, and I think this is basically the work culture around here, so they have, like, a work culture of taking certain timeouts for vacations, which is not the same thing for me when I was working back in Nigeria. I mean, you could just pick your vacations anytime you want to have them. But here, it's more like you have to have them around the summer somehow so that you could basically have much fun and get the time required. So, I think these basic two things are things I've had to adjust to working here now for over two years, so yeah. +VICTORIA: So, more rigid timeframes for lunch, and breakfast, and vacation [laughs]. +REGINA: Yes, yes. And, you know, it's quite funny because even when my colleagues are like, "Let's go and have lunch," and I'm not ready. And they feel like, "Are you okay? Like, you should be having lunch." [laughs] So, it's really rigid timeframe here, I would say that. +VICTORIA: I like that. You know, working in a remote world, it's so easy to just work through lunch or skip breakfast and just go straight to your computer and work. So, I kind of like it. They're looking out for you and making sure that you're taking your breaks. +REGINA: Yes. Yes. And it's actually also making me self-conscious. Because, you know, working daytime as a software engineer, you don't know when to eat. You don't know when to take a break. So, that realization, I'm beginning to more, like, take it more in and adapt to the culture here. Now, I'm always looking out for myself. +And when I wake up in the morning, I remember that I need to, you know, grab something, no matter how small. And then, when it's around lunchtime, I'm also preparing to have something as well. So, I think it's really good. And it also keeps me more healthy, I would say [laughs], compared to me just eating anytime I want to eat. So, I think it's a very good culture. +VICTORIA: That's wonderful. And I really want to hear more about your journey and your career. I first heard about you and invited you to the podcast when you were a speaker for Open Source Festival in Nigeria earlier this year. So, I'm curious how you went from being in Nigeria and how did you get into software engineering and get to where you are today with the GNOME Project and everything else. +REGINA: Well, thank you so much for that. I actually started my technology career path...that's about...I would say around about 10-11 years ago. So, I graduated with a public administration bachelor's, so a bachelor's in public administration. I really did not think that I would be doing what I'm doing today. +But so, when I graduated years ago, that was 2010, I needed more opportunity. And at the time, in Nigeria, technology was not something that was very available to everyone. What I mean is technology was mostly found around those that are privileged, those with more advantage, and all of that. And I wasn't around the set of people that had...those privileged to have computers in their homes or to have parents that has the money to buy these kinds of resources. +But I had always known as a child that I was very good with my hands. And I could remember when I was quite younger, I was the one that my dad would go to to repair his phone when it's not working well. So, I had this thing with my hands that I couldn't really explain that I like to repair things. +And so, when I graduated from the university, I got an opportunity to attend more like a program, a computer program, where they would teach stuff around IT for beginners and all of that. So, I enrolled, and when I enrolled for that particular program, I can remember they would show us more like a slideshow of different programs that you would like to learn, and then give you more like, insight into job opportunities available for those programs. +So, when I sat in that class as a beginner, and I was watching the slideshows, one of the courses that caught my interest was Linux administration and database administration, so I opted in for that particular course. And that was basically how my journey began. When I began to learn about Linux, I began to use it to basically manage databases; then, I was managing databases in Oracle. And I found that one of the things that I needed to learn was basically knowing how to administer the Linux OS. +From there, I began my first job. I worked as a faculty, more like a lecturer teaching Linux administration. So, this time, I had learned, and now I have to help other students learn as well. So, because of this, I began to use more of open-source tools. Now, just to do a little bit of realization check here, at the time when I was basically lecturing years back as a Linux administrator, I did not know that the concept open source existed. I knew that I was using Linux, but I did not really understand the concept of what open source is. +So, going forward now, as I began to use these tools and began to teach students how to administer databases and use more of Linux operating system tools, I somehow, a particular year, stumbled on the GNOME Project. Because GNOME is more like a feature of the Linux OS—it's a desktop application—I was already familiar with it. I just decided to make my contributions there anyway since I had been using the GNOME Project over the years with the Linux operating system. +So, I was basically fascinated to see that everything I had done as a user in my career was basically using open source to basically teach Linux and to teach my students. So, that's, in some way, how I got into technology, how I got into open source, and all of that. +So, going into how I found myself [laughs] in the Open Source Festival and how I found myself in GNOME Project, I chose to contribute to the GNOME Project, one, because GNOME is one of the basic...I'll say a very good feature of the Linux OS. It's a desktop application––allows usability in a way that Linux seems like a Windows operating system. And so, I decided to go into GNOME just to learn more about community, how the community looks like and also contribute my quota to outreach and engagement. +So, what it means is that there are different areas you can contribute to in the GNOME project, one of it is community and engagements, which means you basically help to do outreach, marketing, and events. So, I wanted to basically bring the GNOME project down to my location, and that's Africa, Nigeria. I wanted people to basically see the benefits of what the GNOME Project is to the Linux ecosystem and how they can also contribute to it. So, because of this, I created a chapter of GNOME in Africa. Right now, we have a community of GNOME Africa. And basically, that is how I started. +So, this particular Open Source Festival that just completed for 2023 was not my first, although I was a keynote for this particular one. I had attended Open Source Festival in 2020, where I shared as a workshop speaker, and I shared more about improving Linux experience for African users. And one of the demos I did was basically showcasing the GNOME Project to the users. +VICTORIA: I love that. And maybe you can say more about what the GNOME Project is and the kind of impact it can have on communities like the one that you're from. +REGINA: One of the things with GNOME Project, in some way, it's a desktop application, a desktop application that features in the Linux operating system. So, like you know, we have the Windows operating system, and then we have user-friendly desktop that allows us to be able to basically use Windows without going through command lines all the time. GNOME is like that desktop application to Linux operating system. So, it's a feature of distros of Linux that decides to basically use it. +So, what does it do to a community like mine? I think it is very clear, usability, and allows people as well to be able to contribute to the GNOME shell. Like any other open-source projects, one of the things is that you don't just become a user. But also, you can contribute to the innovation of that particular project, so not just having to be consumers of products but also become creators of those products by contributing to what the community is doing. +So, I think what it has done to a community like mine is basically given people the opportunity and the free will to become creators for something that is quite unique to the Linux operating system and allowing them to also become part of a community, bringing diversity to the global community globally. +VICTORIA: So, how does GNOME benefit as a project from having these additional communities in areas where they may not have had before? +REGINA: I think the key thing here is diverse voices. The key thing here is bringing in people to create more diverse GNOME Projects. And it's not a buzzword. I think creating better technologies is allowing for diverse users' views to be heard. So, before I came into the GNOME project, they had presence around Europe and the U.S. but not so much around Asia and Africa. What this means is that the design, the usability, the culture around the community is not going to be that that is very friendly towards these communities that they are not part of, these communities that doesn't really know what is happening in the GNOME Project. +So, having to bring in diversity, bringing in somebody like myself, community like myself, into the GNOME Project, what this means is that there will be more opportunities for GNOME to evolve around what they have in the previous years into something that is more global, something that is more inclusive, you know, a project that allows people to become contributors and designers of the GNOME shell. +So, I would say this: when I got into the board...this is my second time in the board. We've had several discussions around how to bring in diversity into the GNOME Project and also allow users, newcomers to feel welcomed in the GNOME Project. And that is a discussion and an action that is basically progressive here. +We are having these conversations because I have now come into the project. There is now space for the GNOME Project to see that we need to be more inclusive. We need to be more diverse in our approach, in our design, in the basically way we listen to users right now. So, this was not the case before I came in. So, it's basically just allowing more diversity into the GNOME Project. +VICTORIA: I love that. And I think there's been a lot of studies and evidence that have shown that projects and companies with more inclusive and more diverse voices perform better business-wise afterwards. So, it's not only, like, a moral imperative but just smart business decisions. +REGINA: Yes, yes, yes, yes. Yes. +VICTORIA: And I'm curious, as a community organizer myself [chuckles], what surprised you about the early stages of starting up this community in Africa, or maybe even joining the board of this community now that you've become there? Anything that surprised you in the process there? +REGINA: I think one of the first things that surprised me is that it was more like I was the only one that knows that GNOME exists [laughs]. So, it's me having to first always explain, giving onboarding sections to newcomers to basically explain to them what the GNOME Project is, and doing multiple demos to show how the GNOME desktop works within Linux. +And I thought that people would just know these things and people would just understand how the Linux project works. So, that basically surprised me because I had to always have to...even up until now, I always have to more, like, introduce, guide, and explain what GNOME is and help users to basically or newcomers basically decide if it is something that they will want to contribute to, right? So, that's one thing that surprised me. +And I think the second thing that surprised me was mainly about when I came into the GNOME Project; for a project that global, I thought that there would be some certain level of diversity around the projects. And I thought that I would see more of people like myself or more of people from maybe, you know, Asia or something like that. But I realized that that wasn't the case. +Instead, I remember when I was being introduced to the project, I was introduced to other two Africans, and that made us three. And it was shocking for me that there was less presence for Africans within the GNOME Project. And I think that's one of the basic motivation for me to build a community in Africa and to see that they know that a project like GNOME exists. +VICTORIA: I love that, and it reminds me of when I was running DevOps groups with Women Who Code and DevOps DC, how frequently you have to do just a 101, like, a 101, like, here's the basics. Here's the introduction. And getting really good at that and just knowing you're going to have to keep doing that and to bring in new people. Yeah, that's interesting; that was the point for you. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint +VICTORIA: I'm curious; maybe we can dive more into open source in general and how it can be more inclusive and more diverse. Because I think what I see with open source is, you know, often, it's people doing maintenance on their own free time. They're not getting paid for it. And, of course, there's all the existing access and issues with enabling women to be more into technology careers. So, I'm curious if you have anything else that you think we should talk about with open source and how to make it more inclusive and have more voices at the table. +REGINA: One of the things here is...and I feel like discussion there is a progressive discussion as open-source communities begin to grow, open-source ecosystem continues to grow. So, one of the things here is, basically, having programs that is geared towards under-representation people within the open-source ecosystem. And this program, I feel like, should be a program that encourages some certain level of incentives, you know, stipends for people that are going to be contributing. +Because, like I said, in the past, open source has thrived more within Europe and the U.S. area. But in these areas, there are certain levels of opportunities that is presented. It's either the maintainer has good jobs, or they have projects that pays them on the side. So, they could easily give their free time to open-source contribution. +But looking at the economy side of things and problems we have within areas like Africa and Asia, if you see people contributing or you want people to contribute to open source, there must be some other level of motivations that would get them to basically contribute to your project. So, there are programs like Outreachy. Outreachy is basically a program that helps women to contribute to open source, and they are paid a certain level of stipends at the end of three months, at the end of their contribution. +We need to have more of such programs to encourage inclusive contribution into open source-projects. Because this way, we get more people that would not necessarily have an opportunity to become open-source contributors to come in to contribute. And also, [inaudible 18:29] more diverse voices in the open-source ecosystem. +Another thing here is also that we need to also talk about one of the problems within open source at the moment, which is that we have less women representation, and I'm very glad you're very deep within community and Women Who Code as well. So, you will basically relate with this one. So, there are less women within the open-source ecosystem. And even the women that are contributing––they have challenges within the ways they are treated amongst maintenance. They have challenges even with how to prioritize what they are doing and to be able to also give their time to open source. +So, these all challenges we need to begin to, you know, address them by giving voices to women within open source and helping them to solve some of these problems that they have within, you know, the communities that they are serving in. +Another thing is to have representation in leadership, and I really cannot stress this enough. When I mean representation, it's having more women leaders because this is where the gap is here at the moment. I think the Linux Foundation had a particular research; I'm not very sure about the year. But it shows that we have about 93% of men in the open-source ecosystem, and that tells you what is left of women, you know, the percentage of women that we have within the open-source ecosystem. So, there's a whole lot of work we need to do to bring in more inclusiveness, to bring in more women into the open-source ecosystem. I'm not particularly sure about the exact statistics for that research, but I know it's around that range. +Another thing is that we should encourage communities, open-source communities, to have separate channels where diverse voices can basically have their views about their community, so whether it is having to have a pool of questions geared towards, how do you think we are diverse? How diverse are we in this community? What can we do better? You know, taking metrics of your community is one way we can also bring in inclusivity into the open-source ecosystem. +One of the last thing here that I would mention is events also––open-source events, has to also be conscious around people that are attending their events, around the different races, the different genders. This matrix needs to be taken to basically help to solve and bring more inclusivity into open-source community and open-source events. +VICTORIA: You raised a lot of really great points there. And I won't even try to recap them all because I think I'll miss them [laughs]. But I think you're spot on with everything. It resonates with me, especially, like, working through Women Who Code; what you'll see is there's lots of people interested in joining. There's a drop-off rate around the mid-level of your career because of some of the things that you mentioned, the way that they're treated in the environments and in the communities, and not seeing a path forward to leadership. So, I think you're spot on with everything that you said there. +And I'm curious; I want to make sure we make time to also talk about OpenKids Africa and your founding of that. And what was the goal or the idea behind it? +REGINA: The idea behind it was basically my journey into tech. If you recall, I said I started my journey into tech after my bachelor's degree in public administration. And I felt like I could have done more with technology if I was aware about technology a bit more earlier in life. +So, I wanted to create something and to build something that would give children an opportunity to have better career choices and possibly become technologists, or software engineer, or robotics engineer, or developers in future. But giving them the opportunity to know that this set of careers exist and they could actually make their choices from it. +So, I grew up in Nigeria, like I said. And at the time I grew up, the trending careers were doctors, engineers, lawyers. And my parents actually wanted me to be a lawyer because, at the time, they believed that I was very good at arguments [chuckles]. I could argue a lot. And that basically quickly transcends to I can be a better lawyer. And also because lawyers, in those times, lawyers were very respected in the society. Now, don't get me wrong, lawyers are still respected. But at that time, it felt as though being a lawyer or being a doctor is the only way you're ever going to have a career in Nigeria. +Having to feel like I disappointed my parents because I couldn't get into law...I had a diploma. I did a diploma in law program, but I did not get into my degree. So, I had to do something close, which was the public administration I took. Having to go through those whole process in my career and then finish my bachelor's and realizing that I was a bit better in a technology career, I felt like it was a bit late for me and that I would have taken a better chance at my career choices if I had known about technologies earlier. +So, this is the motivation of creating OpenKids Africa is basically giving children an opportunity to know what they can do with technology, to know how technology cuts across different careers, and to make them realize that technology is no longer an option in your career choices; it's something that needs to be part of your career journey, whether they want to become doctors, whether they want to become technologists in future. Whatever they want to become, they need to have this basic foundation to thrive. So, that's basically what brought about OpenKids Africa. +And my target is basically children in rural communities. And so, we are teaching children in rural communities several skills: how to code, how to understand basically foundational courses within technology. Recently, we went to different schools and giving them an experience of how virtual reality looks like. And it was really fun for these children because, like I said, they are in rural communities. They don't even have these opportunities in the first place, and except it is provided to them here. So, that's basically what we're doing. We're giving children in rural community an opportunity to experience technology and to make better career choices in the future. +VICTORIA: I love that. And so, you found that the kids are really excited about learning about computers. Do you feel that the parents agree that technology is a good path for them to follow and study? +REGINA: Well, I think that that's another part of OpenKids Africa. So, when I started OpenKids Africa, I wanted to explore the rural community and understand, basically, what are the unique cases that we have here? So that's part of those...I was exploring, basically. We found that some of the children would tell us that, "I like this, but my mom or my parent would not allow me to do this. They will not allow me to know how to use computers or to become maybe a technologist in future because my mom or my dad thinks I should be a doctor," and all of that. +So, we had to remodel our strategy in a way that we now go to parents' associations in schools in rural communities. And we talk to them about technology, benefits of technology, and how they can encourage their children to learn technology, and also the future career choices for their children. And when we do this, when we speak to parents, we see the excitement of "Oh, so, my child can actually become this with this technology thing." And we also give them safety measures because, of course, there's so many things on the internet here. And there's safety tips for parents to know about, even if they want to allow their children to basically use computers and all of that, child control and all of those things. +So, by talking to parents, we've realized that we have to have a two-model approach in OpenKids Africa, where we don't just teach the children and encourage the teachers to learn more about technology, but we also have to talk to the parents to allow their children to basically explore technology careers in the future, and also, showing them the opportunities that it will pose to them. So yeah, to be honest, this is one of the surprising things that I found, and it has continued to surprise me as a founder of OpenKids. +VICTORIA: Well, that's, I think, a very common thing for founders is that you think you have one set of users, but there's actually another one [laughs] where it impacts you. +REGINA: Exactly. Exactly [laughs]. +VICTORIA: That's wonderful. Are you excited about on the horizon with either the GNOME Project or OpenKids Africa? +REGINA: I will start with the GNOME Project. Right now, we are looking towards things like the Global Inclusive Initiative. And it's basically an initiative that we are looking to put together all the communities we have globally, giving more voices to diverse users to be able to contribute into GNOME. That is something on the pipeline that we're looking to plan. +And I'm also excited for OpenKids Africa. So, right now, we are exploring how to get teachers in rural communities involved with what we're doing and basically train them separately as well to know the benefit of technology to children. So, the target teachers here are teachers that basically...early child education teachers and helping them to understand how to teach technology to children, and how to inspire children to appreciate technology innovation we have around the world, innovations like virtual reality, you know, robotics, and all of that. +So, I'm really excited about that one because I feel like if you can tell the teachers how these things are and the benefits, and then they can better pass the message across to the children, making our work more easier when we have workshops and demos to do in schools, yeah. +VICTORIA: And I've actually gotten this question quite a few times from people, which is, how do you get kids interested in learning [laughs] technology and learning how to code? +REGINA: I think it's basically having a practice that is more child-friendly, co-creative. So, co-creation is basically, you are not the only one doing it. You're involving the children in it as well, and you give them the real-life experiences. So, for instance, when we went to talk about virtual reality to children, and we showed them what virtual reality does in the presentation, we engage with the kids. We make them give us their own ideas. +We even go as far as allowing them to draw what they see and give us what they think about it. But we don't stop there. We get virtual sets and show them exactly...give them a real-life experience of what virtual reality is. So, children are very, very creative, and they also have a very fast mind to pick pictures. But not only that, they can also store experiences very, very fast. So, we utilize every area that makes children excited in our workshops. After we are done, we do practices, and we give them gifts as well for engaging in those practices. So yeah, we just co-creation [laughs]. +VICTORIA: Wow. And you're doing so much because you have a full-time job. You're on the board for GNOME Project, and you have your non-profit, OpenKids Africa. So, how do you find a right balance in your life of work, and extra stuff, and your regular life [laughs]? +REGINA: Honestly, I would say that the word balance I wouldn't use balance for me at the moment because I feel like I've not basically found the balance I'm looking for, but I've been able to prioritize. So, what that means is that I've been able to know what is important part-time and know when to take certain engagements. So, my full-time job is more, like, a priority right now because, of course, we need a job to be able to sustain our lives. So, I take that as my priority. +And I have different schedule of days for other things like the GNOME community and working with my team in OpenKids Africa. So, I would say I'm quite lucky to have a very good team. And also, being part of GNOME board, the commitments are not as demanding as you would expect, you know, maybe a regular board. There are fixed schedules on things, and they have flexible time for contribution as well. +I'm also part of the GNOME Africa community. And I recently just on-boarded a community manager because I realized that I need more, like, to take a step back so that I don't get burned out and all of that. So, I think it's basically prioritizing for me at the moment to gain the balance that I'm looking for. So, I think if I have a conversation with you maybe months after now, I would be able to know what balance feels like. So, I'm really experimenting with prioritizing at the moment. +VICTORIA: We'll have to check back in in a few months and see how things are going. But I think that's a very honest answer, and I appreciate that. And I think that probably relates to how a lot of people feel, honestly, even having less on their plate that it's hard to find that balance. So, I appreciate you sharing that. And I wonder, too, if you had any advice for yourself. If you could go back in time, either when you were first starting on your journey or when you were first starting on either of these projects, what advice would you give yourself? +REGINA: I think one of the things...I will talk about first starting on my technology career. I didn't have the opportunities that many young people had at the time because I didn't come from a background where my parents had the finances to basically give me the opportunity to learn technology the way I wanted to. But, I was able to make do with the resources I had at the time to learn and to basically grow. +So, an advice I will give to my younger self and to anybody that wants to come into technology that do not have the resources, I would say leverage open-source tools as much as you can because now I realize that that's basically what helped me. And also, allow yourself to grow; it will always get better. +Advice I would give to somebody coming into an open-source project like me at the GNOME Project. I think that one of the things that...understand why you're contributing to that project, and always seek to be treated fairly, always seek to be treated nicely. And also treat other people nicely and fairly as well. I think if we have these both balance, we'll have a better, healthy community within open source. And don't be scared to share your view. Don't be scared to basically be yourself wherever you are found in the community that you're representing. +And if I would like to add: OpenKids Africa, for me, if anyone would be...it's, I would say, it's still young because we are going, I think, about our third year now. So, I will say it's still young. But what I would say to any founder that wants to basically found a non-profit or do something in the society, I think, is just to get your motivation, understand why you're doing them, and be open-minded to what you'll learn along the way. That's it. +VICTORIA: I think that's great. Yeah, I love that. And I like that you mentioned that there are open-source tools out there. I'm trying to use those more, and I think I always try to iterate that for people, too, is, like, there's free training. There's free resources. There's free tools. And there are lots of people who want to see you succeed, no matter your background, or where you're from, or what you look like. So, I think that that's a really powerful message. So, I appreciate that. And do you have anything else that you would like to promote? +REGINA: I think before that, I would like to learn more about the Women Who Code. As a community builder, what basically surprised you the most? +VICTORIA: Yeah. So, what I loved about Women Who Code is that it was really aimed at helping women get started in careers in technology and maintaining careers in technology. So, I think what was interesting for me...I think I started doing it back in 2017 or 2018, and I just loved it. I loved going to a tech meetup with a room where it's all women [laughs]. Because, normally, and I'm sure you've had this experience, you go to a tech meetup, and you're maybe one of two, at the best, of women in the group. I just really enjoyed that. +And I've been really surprised and happy to see how the women, including myself, who started running the meetups, and doing trainings, and helping other women learn how to code have really advanced in their career and become directors, or engineering managers, or really senior contributors in different companies. So, I think that that was a really interesting and surprising thing for people is, like, well, if you want to grow in your career, it helps to be active in your community and to be someone that people know and to have those connections. +And I think it still surprises me to this day how my network that I got from investing in all of those meetups and all that time is still paying off [laughs]. Like, I could still, like, reach back into my network and find someone who is an expert on a particular subject or works at a company that I want to talk to or something like that. So, I think that that's been a really wonderful aspect of it. +REGINA: Wow, that's quite interesting. And I really think, also I agree with you. One of the beautiful things around communities and meetups is basically networks, the people that you get to meet, the people that you get to know along the way. +VICTORIA: Absolutely. Yeah, and those are the people that you want to keep working with. So, it helps you find jobs. It helps you find people to hire if you're hiring. It's worth it. Like [laughs], it can feel like, ugh, am I really going to go to this meetup [laughter], like, after work, after a long day? And, you know, maybe the topic is even something I'm not interested in. But it does pay off if you keep showing up and continue to invest in it. Yeah, I think that's smart. +And make people feel safe, too. I think that was a big part of it is, you know, going to a meetup and meeting someone maybe like me who's nice and friendly and wants to hear your voice. I think that has a big impact for people, especially if they're, you know, the only woman at their company. And now they have a whole set of friends [laughs]. That's, yeah, how powerful that can be for people. +REGINA: Exactly. Exactly. And you just said one of the most important things, and that's basically making people feel safe, making them welcomed as well. Interesting. Thank you for sharing that one because I was quite curious, and I wanted to really learn more. +VICTORIA: Yeah, I'm very lucky. And we actually had the CEO and founder of Women Who Code on our podcast lately. So, you're in good company [laughs]. +REGINA: Nice. +VICTORIA: Yeah, it's wonderful. Do you have any other questions for me? +REGINA: My last question, and I'm going to be asking again that I will be inviting you on my podcast as well [inaudible 37:32] [laughs] +VICTORIA: Yes. Of course, yes. Absolutely. Send me the details. I'd be happy to join. +All right. Well, thank you so much again for joining us. I really appreciate your time. +And for our listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thank you for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Regina Nkenchor. + + + Host Victoria Guido and special guest Regina Nkenchor discuss the evolution and impact of Regina's work with the GNOME Project and OpenKids Africa. Regina explains how the GNOME Project is advancing its Global Inclusive Initiative, aiming to amplify diverse voices within the community and contribute to GNOME's development. She expresses enthusiasm for OpenKids Africa's efforts to incorporate technology education in rural communities, primarily through engaging early childhood teachers in understanding and teaching tech like virtual reality and robotics.

+ +

Victoria probes into strategies for sparking children's interest in technology, with Regina advocating for a co-creative, experience-based approach that includes real-life applications and interactive participation. They also touch on the challenges of balancing professional and personal commitments. Regina shares her ongoing journey to find balance by prioritizing and delegating while still maintaining her nonprofit work and her role at the GNOME Project.

+ +

They also talk about personal growth and community engagement. Regina advises newcomers to leverage open-source tools and be open to change while encouraging fair treatment within the open-source community. Victoria reflects on her experiences with Women Who Code, highlighting the importance of community involvement and networking for career advancement. Both emphasize the significance of creating safe, welcoming spaces in tech communities to foster inclusion and support, especially for women in tech.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Regina, Board Vice President of the GNOME Foundation and Founder at OpenKids Africa. Regina, thank you for joining me.

+ +

REGINA: Thank you so much for having me. It's such a great opportunity to be here today.

+ +

VICTORIA: That's wonderful. So, what's going on in your world, anything fun or exciting happening?

+ +

REGINA: You know, I actually work in Sweden. And this period is actually one of the...let me say the peak period, beginning of a new year, beginning of a new year for my job. So, there's so much around projects, projects, projects. So, I wouldn't say this is more like a fun period because, after the summer, it's a different time here when you're working in Europe.

+ +

VICTORIA: Yes, working in Sweden must be so interesting. I'm wondering if you found any cultural differences that were really surprising about working there.

+ +

REGINA: Oh yes. I think there are so many cultural differences, one of it is...I come from Nigeria, and we have more, like, a particular way...we don't have a schedule for having breakfast. So, we can have breakfast anytime we want to, and we don't feel any problem by it. So, I could decide to have my breakfast by 12:00 or by 1:00 and have my lunch by 4:00 p.m., you know, it just depends. But here, it's more like you have to have your breakfast early. And by 11:00, 12:00, 1:00, you should be having your lunch. I'm still trying to get used to that one anyway.

+ +

And also, another cultural difference that I've seen here that is very, very obvious to me compared to where I'm coming from, and I think this is basically the work culture around here, so they have, like, a work culture of taking certain timeouts for vacations, which is not the same thing for me when I was working back in Nigeria. I mean, you could just pick your vacations anytime you want to have them. But here, it's more like you have to have them around the summer somehow so that you could basically have much fun and get the time required. So, I think these basic two things are things I've had to adjust to working here now for over two years, so yeah.

+ +

VICTORIA: So, more rigid timeframes for lunch, and breakfast, and vacation [laughs].

+ +

REGINA: Yes, yes. And, you know, it's quite funny because even when my colleagues are like, "Let's go and have lunch," and I'm not ready. And they feel like, "Are you okay? Like, you should be having lunch." [laughs] So, it's really rigid timeframe here, I would say that.

+ +

VICTORIA: I like that. You know, working in a remote world, it's so easy to just work through lunch or skip breakfast and just go straight to your computer and work. So, I kind of like it. They're looking out for you and making sure that you're taking your breaks.

+ +

REGINA: Yes. Yes. And it's actually also making me self-conscious. Because, you know, working daytime as a software engineer, you don't know when to eat. You don't know when to take a break. So, that realization, I'm beginning to more, like, take it more in and adapt to the culture here. Now, I'm always looking out for myself.

+ +

And when I wake up in the morning, I remember that I need to, you know, grab something, no matter how small. And then, when it's around lunchtime, I'm also preparing to have something as well. So, I think it's really good. And it also keeps me more healthy, I would say [laughs], compared to me just eating anytime I want to eat. So, I think it's a very good culture.

+ +

VICTORIA: That's wonderful. And I really want to hear more about your journey and your career. I first heard about you and invited you to the podcast when you were a speaker for Open Source Festival in Nigeria earlier this year. So, I'm curious how you went from being in Nigeria and how did you get into software engineering and get to where you are today with the GNOME Project and everything else.

+ +

REGINA: Well, thank you so much for that. I actually started my technology career path...that's about...I would say around about 10-11 years ago. So, I graduated with a public administration bachelor's, so a bachelor's in public administration. I really did not think that I would be doing what I'm doing today.

+ +

But so, when I graduated years ago, that was 2010, I needed more opportunity. And at the time, in Nigeria, technology was not something that was very available to everyone. What I mean is technology was mostly found around those that are privileged, those with more advantage, and all of that. And I wasn't around the set of people that had...those privileged to have computers in their homes or to have parents that has the money to buy these kinds of resources.

+ +

But I had always known as a child that I was very good with my hands. And I could remember when I was quite younger, I was the one that my dad would go to to repair his phone when it's not working well. So, I had this thing with my hands that I couldn't really explain that I like to repair things.

+ +

And so, when I graduated from the university, I got an opportunity to attend more like a program, a computer program, where they would teach stuff around IT for beginners and all of that. So, I enrolled, and when I enrolled for that particular program, I can remember they would show us more like a slideshow of different programs that you would like to learn, and then give you more like, insight into job opportunities available for those programs.

+ +

So, when I sat in that class as a beginner, and I was watching the slideshows, one of the courses that caught my interest was Linux administration and database administration, so I opted in for that particular course. And that was basically how my journey began. When I began to learn about Linux, I began to use it to basically manage databases; then, I was managing databases in Oracle. And I found that one of the things that I needed to learn was basically knowing how to administer the Linux OS.

+ +

From there, I began my first job. I worked as a faculty, more like a lecturer teaching Linux administration. So, this time, I had learned, and now I have to help other students learn as well. So, because of this, I began to use more of open-source tools. Now, just to do a little bit of realization check here, at the time when I was basically lecturing years back as a Linux administrator, I did not know that the concept open source existed. I knew that I was using Linux, but I did not really understand the concept of what open source is.

+ +

So, going forward now, as I began to use these tools and began to teach students how to administer databases and use more of Linux operating system tools, I somehow, a particular year, stumbled on the GNOME Project. Because GNOME is more like a feature of the Linux OS—it's a desktop application—I was already familiar with it. I just decided to make my contributions there anyway since I had been using the GNOME Project over the years with the Linux operating system.

+ +

So, I was basically fascinated to see that everything I had done as a user in my career was basically using open source to basically teach Linux and to teach my students. So, that's, in some way, how I got into technology, how I got into open source, and all of that.

+ +

So, going into how I found myself [laughs] in the Open Source Festival and how I found myself in GNOME Project, I chose to contribute to the GNOME Project, one, because GNOME is one of the basic...I'll say a very good feature of the Linux OS. It's a desktop application––allows usability in a way that Linux seems like a Windows operating system. And so, I decided to go into GNOME just to learn more about community, how the community looks like and also contribute my quota to outreach and engagement.

+ +

So, what it means is that there are different areas you can contribute to in the GNOME project, one of it is community and engagements, which means you basically help to do outreach, marketing, and events. So, I wanted to basically bring the GNOME project down to my location, and that's Africa, Nigeria. I wanted people to basically see the benefits of what the GNOME Project is to the Linux ecosystem and how they can also contribute to it. So, because of this, I created a chapter of GNOME in Africa. Right now, we have a community of GNOME Africa. And basically, that is how I started.

+ +

So, this particular Open Source Festival that just completed for 2023 was not my first, although I was a keynote for this particular one. I had attended Open Source Festival in 2020, where I shared as a workshop speaker, and I shared more about improving Linux experience for African users. And one of the demos I did was basically showcasing the GNOME Project to the users.

+ +

VICTORIA: I love that. And maybe you can say more about what the GNOME Project is and the kind of impact it can have on communities like the one that you're from.

+ +

REGINA: One of the things with GNOME Project, in some way, it's a desktop application, a desktop application that features in the Linux operating system. So, like you know, we have the Windows operating system, and then we have user-friendly desktop that allows us to be able to basically use Windows without going through command lines all the time. GNOME is like that desktop application to Linux operating system. So, it's a feature of distros of Linux that decides to basically use it.

+ +

So, what does it do to a community like mine? I think it is very clear, usability, and allows people as well to be able to contribute to the GNOME shell. Like any other open-source projects, one of the things is that you don't just become a user. But also, you can contribute to the innovation of that particular project, so not just having to be consumers of products but also become creators of those products by contributing to what the community is doing.

+ +

So, I think what it has done to a community like mine is basically given people the opportunity and the free will to become creators for something that is quite unique to the Linux operating system and allowing them to also become part of a community, bringing diversity to the global community globally.

+ +

VICTORIA: So, how does GNOME benefit as a project from having these additional communities in areas where they may not have had before?

+ +

REGINA: I think the key thing here is diverse voices. The key thing here is bringing in people to create more diverse GNOME Projects. And it's not a buzzword. I think creating better technologies is allowing for diverse users' views to be heard. So, before I came into the GNOME project, they had presence around Europe and the U.S. but not so much around Asia and Africa. What this means is that the design, the usability, the culture around the community is not going to be that that is very friendly towards these communities that they are not part of, these communities that doesn't really know what is happening in the GNOME Project.

+ +

So, having to bring in diversity, bringing in somebody like myself, community like myself, into the GNOME Project, what this means is that there will be more opportunities for GNOME to evolve around what they have in the previous years into something that is more global, something that is more inclusive, you know, a project that allows people to become contributors and designers of the GNOME shell.

+ +

So, I would say this: when I got into the board...this is my second time in the board. We've had several discussions around how to bring in diversity into the GNOME Project and also allow users, newcomers to feel welcomed in the GNOME Project. And that is a discussion and an action that is basically progressive here.

+ +

We are having these conversations because I have now come into the project. There is now space for the GNOME Project to see that we need to be more inclusive. We need to be more diverse in our approach, in our design, in the basically way we listen to users right now. So, this was not the case before I came in. So, it's basically just allowing more diversity into the GNOME Project.

+ +

VICTORIA: I love that. And I think there's been a lot of studies and evidence that have shown that projects and companies with more inclusive and more diverse voices perform better business-wise afterwards. So, it's not only, like, a moral imperative but just smart business decisions.

+ +

REGINA: Yes, yes, yes, yes. Yes.

+ +

VICTORIA: And I'm curious, as a community organizer myself [chuckles], what surprised you about the early stages of starting up this community in Africa, or maybe even joining the board of this community now that you've become there? Anything that surprised you in the process there?

+ +

REGINA: I think one of the first things that surprised me is that it was more like I was the only one that knows that GNOME exists [laughs]. So, it's me having to first always explain, giving onboarding sections to newcomers to basically explain to them what the GNOME Project is, and doing multiple demos to show how the GNOME desktop works within Linux.

+ +

And I thought that people would just know these things and people would just understand how the Linux project works. So, that basically surprised me because I had to always have to...even up until now, I always have to more, like, introduce, guide, and explain what GNOME is and help users to basically or newcomers basically decide if it is something that they will want to contribute to, right? So, that's one thing that surprised me.

+ +

And I think the second thing that surprised me was mainly about when I came into the GNOME Project; for a project that global, I thought that there would be some certain level of diversity around the projects. And I thought that I would see more of people like myself or more of people from maybe, you know, Asia or something like that. But I realized that that wasn't the case.

+ +

Instead, I remember when I was being introduced to the project, I was introduced to other two Africans, and that made us three. And it was shocking for me that there was less presence for Africans within the GNOME Project. And I think that's one of the basic motivation for me to build a community in Africa and to see that they know that a project like GNOME exists.

+ +

VICTORIA: I love that, and it reminds me of when I was running DevOps groups with Women Who Code and DevOps DC, how frequently you have to do just a 101, like, a 101, like, here's the basics. Here's the introduction. And getting really good at that and just knowing you're going to have to keep doing that and to bring in new people. Yeah, that's interesting; that was the point for you.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: I'm curious; maybe we can dive more into open source in general and how it can be more inclusive and more diverse. Because I think what I see with open source is, you know, often, it's people doing maintenance on their own free time. They're not getting paid for it. And, of course, there's all the existing access and issues with enabling women to be more into technology careers. So, I'm curious if you have anything else that you think we should talk about with open source and how to make it more inclusive and have more voices at the table.

+ +

REGINA: One of the things here is...and I feel like discussion there is a progressive discussion as open-source communities begin to grow, open-source ecosystem continues to grow. So, one of the things here is, basically, having programs that is geared towards under-representation people within the open-source ecosystem. And this program, I feel like, should be a program that encourages some certain level of incentives, you know, stipends for people that are going to be contributing.

+ +

Because, like I said, in the past, open source has thrived more within Europe and the U.S. area. But in these areas, there are certain levels of opportunities that is presented. It's either the maintainer has good jobs, or they have projects that pays them on the side. So, they could easily give their free time to open-source contribution.

+ +

But looking at the economy side of things and problems we have within areas like Africa and Asia, if you see people contributing or you want people to contribute to open source, there must be some other level of motivations that would get them to basically contribute to your project. So, there are programs like Outreachy. Outreachy is basically a program that helps women to contribute to open source, and they are paid a certain level of stipends at the end of three months, at the end of their contribution.

+ +

We need to have more of such programs to encourage inclusive contribution into open source-projects. Because this way, we get more people that would not necessarily have an opportunity to become open-source contributors to come in to contribute. And also, [inaudible 18:29] more diverse voices in the open-source ecosystem.

+ +

Another thing here is also that we need to also talk about one of the problems within open source at the moment, which is that we have less women representation, and I'm very glad you're very deep within community and Women Who Code as well. So, you will basically relate with this one. So, there are less women within the open-source ecosystem. And even the women that are contributing––they have challenges within the ways they are treated amongst maintenance. They have challenges even with how to prioritize what they are doing and to be able to also give their time to open source.

+ +

So, these all challenges we need to begin to, you know, address them by giving voices to women within open source and helping them to solve some of these problems that they have within, you know, the communities that they are serving in.

+ +

Another thing is to have representation in leadership, and I really cannot stress this enough. When I mean representation, it's having more women leaders because this is where the gap is here at the moment. I think the Linux Foundation had a particular research; I'm not very sure about the year. But it shows that we have about 93% of men in the open-source ecosystem, and that tells you what is left of women, you know, the percentage of women that we have within the open-source ecosystem. So, there's a whole lot of work we need to do to bring in more inclusiveness, to bring in more women into the open-source ecosystem. I'm not particularly sure about the exact statistics for that research, but I know it's around that range.

+ +

Another thing is that we should encourage communities, open-source communities, to have separate channels where diverse voices can basically have their views about their community, so whether it is having to have a pool of questions geared towards, how do you think we are diverse? How diverse are we in this community? What can we do better? You know, taking metrics of your community is one way we can also bring in inclusivity into the open-source ecosystem.

+ +

One of the last thing here that I would mention is events also––open-source events, has to also be conscious around people that are attending their events, around the different races, the different genders. This matrix needs to be taken to basically help to solve and bring more inclusivity into open-source community and open-source events.

+ +

VICTORIA: You raised a lot of really great points there. And I won't even try to recap them all because I think I'll miss them [laughs]. But I think you're spot on with everything. It resonates with me, especially, like, working through Women Who Code; what you'll see is there's lots of people interested in joining. There's a drop-off rate around the mid-level of your career because of some of the things that you mentioned, the way that they're treated in the environments and in the communities, and not seeing a path forward to leadership. So, I think you're spot on with everything that you said there.

+ +

And I'm curious; I want to make sure we make time to also talk about OpenKids Africa and your founding of that. And what was the goal or the idea behind it?

+ +

REGINA: The idea behind it was basically my journey into tech. If you recall, I said I started my journey into tech after my bachelor's degree in public administration. And I felt like I could have done more with technology if I was aware about technology a bit more earlier in life.

+ +

So, I wanted to create something and to build something that would give children an opportunity to have better career choices and possibly become technologists, or software engineer, or robotics engineer, or developers in future. But giving them the opportunity to know that this set of careers exist and they could actually make their choices from it.

+ +

So, I grew up in Nigeria, like I said. And at the time I grew up, the trending careers were doctors, engineers, lawyers. And my parents actually wanted me to be a lawyer because, at the time, they believed that I was very good at arguments [chuckles]. I could argue a lot. And that basically quickly transcends to I can be a better lawyer. And also because lawyers, in those times, lawyers were very respected in the society. Now, don't get me wrong, lawyers are still respected. But at that time, it felt as though being a lawyer or being a doctor is the only way you're ever going to have a career in Nigeria.

+ +

Having to feel like I disappointed my parents because I couldn't get into law...I had a diploma. I did a diploma in law program, but I did not get into my degree. So, I had to do something close, which was the public administration I took. Having to go through those whole process in my career and then finish my bachelor's and realizing that I was a bit better in a technology career, I felt like it was a bit late for me and that I would have taken a better chance at my career choices if I had known about technologies earlier.

+ +

So, this is the motivation of creating OpenKids Africa is basically giving children an opportunity to know what they can do with technology, to know how technology cuts across different careers, and to make them realize that technology is no longer an option in your career choices; it's something that needs to be part of your career journey, whether they want to become doctors, whether they want to become technologists in future. Whatever they want to become, they need to have this basic foundation to thrive. So, that's basically what brought about OpenKids Africa.

+ +

And my target is basically children in rural communities. And so, we are teaching children in rural communities several skills: how to code, how to understand basically foundational courses within technology. Recently, we went to different schools and giving them an experience of how virtual reality looks like. And it was really fun for these children because, like I said, they are in rural communities. They don't even have these opportunities in the first place, and except it is provided to them here. So, that's basically what we're doing. We're giving children in rural community an opportunity to experience technology and to make better career choices in the future.

+ +

VICTORIA: I love that. And so, you found that the kids are really excited about learning about computers. Do you feel that the parents agree that technology is a good path for them to follow and study?

+ +

REGINA: Well, I think that that's another part of OpenKids Africa. So, when I started OpenKids Africa, I wanted to explore the rural community and understand, basically, what are the unique cases that we have here? So that's part of those...I was exploring, basically. We found that some of the children would tell us that, "I like this, but my mom or my parent would not allow me to do this. They will not allow me to know how to use computers or to become maybe a technologist in future because my mom or my dad thinks I should be a doctor," and all of that.

+ +

So, we had to remodel our strategy in a way that we now go to parents' associations in schools in rural communities. And we talk to them about technology, benefits of technology, and how they can encourage their children to learn technology, and also the future career choices for their children. And when we do this, when we speak to parents, we see the excitement of "Oh, so, my child can actually become this with this technology thing." And we also give them safety measures because, of course, there's so many things on the internet here. And there's safety tips for parents to know about, even if they want to allow their children to basically use computers and all of that, child control and all of those things.

+ +

So, by talking to parents, we've realized that we have to have a two-model approach in OpenKids Africa, where we don't just teach the children and encourage the teachers to learn more about technology, but we also have to talk to the parents to allow their children to basically explore technology careers in the future, and also, showing them the opportunities that it will pose to them. So yeah, to be honest, this is one of the surprising things that I found, and it has continued to surprise me as a founder of OpenKids.

+ +

VICTORIA: Well, that's, I think, a very common thing for founders is that you think you have one set of users, but there's actually another one [laughs] where it impacts you.

+ +

REGINA: Exactly. Exactly [laughs].

+ +

VICTORIA: That's wonderful. Are you excited about on the horizon with either the GNOME Project or OpenKids Africa?

+ +

REGINA: I will start with the GNOME Project. Right now, we are looking towards things like the Global Inclusive Initiative. And it's basically an initiative that we are looking to put together all the communities we have globally, giving more voices to diverse users to be able to contribute into GNOME. That is something on the pipeline that we're looking to plan.

+ +

And I'm also excited for OpenKids Africa. So, right now, we are exploring how to get teachers in rural communities involved with what we're doing and basically train them separately as well to know the benefit of technology to children. So, the target teachers here are teachers that basically...early child education teachers and helping them to understand how to teach technology to children, and how to inspire children to appreciate technology innovation we have around the world, innovations like virtual reality, you know, robotics, and all of that.

+ +

So, I'm really excited about that one because I feel like if you can tell the teachers how these things are and the benefits, and then they can better pass the message across to the children, making our work more easier when we have workshops and demos to do in schools, yeah.

+ +

VICTORIA: And I've actually gotten this question quite a few times from people, which is, how do you get kids interested in learning [laughs] technology and learning how to code?

+ +

REGINA: I think it's basically having a practice that is more child-friendly, co-creative. So, co-creation is basically, you are not the only one doing it. You're involving the children in it as well, and you give them the real-life experiences. So, for instance, when we went to talk about virtual reality to children, and we showed them what virtual reality does in the presentation, we engage with the kids. We make them give us their own ideas.

+ +

We even go as far as allowing them to draw what they see and give us what they think about it. But we don't stop there. We get virtual sets and show them exactly...give them a real-life experience of what virtual reality is. So, children are very, very creative, and they also have a very fast mind to pick pictures. But not only that, they can also store experiences very, very fast. So, we utilize every area that makes children excited in our workshops. After we are done, we do practices, and we give them gifts as well for engaging in those practices. So yeah, we just co-creation [laughs].

+ +

VICTORIA: Wow. And you're doing so much because you have a full-time job. You're on the board for GNOME Project, and you have your non-profit, OpenKids Africa. So, how do you find a right balance in your life of work, and extra stuff, and your regular life [laughs]?

+ +

REGINA: Honestly, I would say that the word balance I wouldn't use balance for me at the moment because I feel like I've not basically found the balance I'm looking for, but I've been able to prioritize. So, what that means is that I've been able to know what is important part-time and know when to take certain engagements. So, my full-time job is more, like, a priority right now because, of course, we need a job to be able to sustain our lives. So, I take that as my priority.

+ +

And I have different schedule of days for other things like the GNOME community and working with my team in OpenKids Africa. So, I would say I'm quite lucky to have a very good team. And also, being part of GNOME board, the commitments are not as demanding as you would expect, you know, maybe a regular board. There are fixed schedules on things, and they have flexible time for contribution as well.

+ +

I'm also part of the GNOME Africa community. And I recently just on-boarded a community manager because I realized that I need more, like, to take a step back so that I don't get burned out and all of that. So, I think it's basically prioritizing for me at the moment to gain the balance that I'm looking for. So, I think if I have a conversation with you maybe months after now, I would be able to know what balance feels like. So, I'm really experimenting with prioritizing at the moment.

+ +

VICTORIA: We'll have to check back in in a few months and see how things are going. But I think that's a very honest answer, and I appreciate that. And I think that probably relates to how a lot of people feel, honestly, even having less on their plate that it's hard to find that balance. So, I appreciate you sharing that. And I wonder, too, if you had any advice for yourself. If you could go back in time, either when you were first starting on your journey or when you were first starting on either of these projects, what advice would you give yourself?

+ +

REGINA: I think one of the things...I will talk about first starting on my technology career. I didn't have the opportunities that many young people had at the time because I didn't come from a background where my parents had the finances to basically give me the opportunity to learn technology the way I wanted to. But, I was able to make do with the resources I had at the time to learn and to basically grow.

+ +

So, an advice I will give to my younger self and to anybody that wants to come into technology that do not have the resources, I would say leverage open-source tools as much as you can because now I realize that that's basically what helped me. And also, allow yourself to grow; it will always get better.

+ +

Advice I would give to somebody coming into an open-source project like me at the GNOME Project. I think that one of the things that...understand why you're contributing to that project, and always seek to be treated fairly, always seek to be treated nicely. And also treat other people nicely and fairly as well. I think if we have these both balance, we'll have a better, healthy community within open source. And don't be scared to share your view. Don't be scared to basically be yourself wherever you are found in the community that you're representing.

+ +

And if I would like to add: OpenKids Africa, for me, if anyone would be...it's, I would say, it's still young because we are going, I think, about our third year now. So, I will say it's still young. But what I would say to any founder that wants to basically found a non-profit or do something in the society, I think, is just to get your motivation, understand why you're doing them, and be open-minded to what you'll learn along the way. That's it.

+ +

VICTORIA: I think that's great. Yeah, I love that. And I like that you mentioned that there are open-source tools out there. I'm trying to use those more, and I think I always try to iterate that for people, too, is, like, there's free training. There's free resources. There's free tools. And there are lots of people who want to see you succeed, no matter your background, or where you're from, or what you look like. So, I think that that's a really powerful message. So, I appreciate that. And do you have anything else that you would like to promote?

+ +

REGINA: I think before that, I would like to learn more about the Women Who Code. As a community builder, what basically surprised you the most?

+ +

VICTORIA: Yeah. So, what I loved about Women Who Code is that it was really aimed at helping women get started in careers in technology and maintaining careers in technology. So, I think what was interesting for me...I think I started doing it back in 2017 or 2018, and I just loved it. I loved going to a tech meetup with a room where it's all women [laughs]. Because, normally, and I'm sure you've had this experience, you go to a tech meetup, and you're maybe one of two, at the best, of women in the group. I just really enjoyed that.

+ +

And I've been really surprised and happy to see how the women, including myself, who started running the meetups, and doing trainings, and helping other women learn how to code have really advanced in their career and become directors, or engineering managers, or really senior contributors in different companies. So, I think that that was a really interesting and surprising thing for people is, like, well, if you want to grow in your career, it helps to be active in your community and to be someone that people know and to have those connections.

+ +

And I think it still surprises me to this day how my network that I got from investing in all of those meetups and all that time is still paying off [laughs]. Like, I could still, like, reach back into my network and find someone who is an expert on a particular subject or works at a company that I want to talk to or something like that. So, I think that that's been a really wonderful aspect of it.

+ +

REGINA: Wow, that's quite interesting. And I really think, also I agree with you. One of the beautiful things around communities and meetups is basically networks, the people that you get to meet, the people that you get to know along the way.

+ +

VICTORIA: Absolutely. Yeah, and those are the people that you want to keep working with. So, it helps you find jobs. It helps you find people to hire if you're hiring. It's worth it. Like [laughs], it can feel like, ugh, am I really going to go to this meetup [laughter], like, after work, after a long day? And, you know, maybe the topic is even something I'm not interested in. But it does pay off if you keep showing up and continue to invest in it. Yeah, I think that's smart.

+ +

And make people feel safe, too. I think that was a big part of it is, you know, going to a meetup and meeting someone maybe like me who's nice and friendly and wants to hear your voice. I think that has a big impact for people, especially if they're, you know, the only woman at their company. And now they have a whole set of friends [laughs]. That's, yeah, how powerful that can be for people.

+ +

REGINA: Exactly. Exactly. And you just said one of the most important things, and that's basically making people feel safe, making them welcomed as well. Interesting. Thank you for sharing that one because I was quite curious, and I wanted to really learn more.

+ +

VICTORIA: Yeah, I'm very lucky. And we actually had the CEO and founder of Women Who Code on our podcast lately. So, you're in good company [laughs].

+ +

REGINA: Nice.

+ +

VICTORIA: Yeah, it's wonderful. Do you have any other questions for me?

+ +

REGINA: My last question, and I'm going to be asking again that I will be inviting you on my podcast as well [inaudible 37:32] [laughs]

+ +

VICTORIA: Yes. Of course, yes. Absolutely. Send me the details. I'd be happy to join.

+ +

All right. Well, thank you so much again for joining us. I really appreciate your time.

+ +

And for our listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Regina Nkenchor.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Host Victoria Guido and special guest Regina Nkenchor discuss the evolution and impact of Regina's work with the GNOME Project and OpenKids Africa. Regina explains how the GNOME Project is advancing its Global Inclusive Initiative, aiming to amplify diverse voices within the community and contribute to GNOME's development. She expresses enthusiasm for OpenKids Africa's efforts to incorporate technology education in rural communities, primarily through engaging early childhood teachers in understanding and teaching tech like virtual reality and robotics.

+ +

Victoria probes into strategies for sparking children's interest in technology, with Regina advocating for a co-creative, experience-based approach that includes real-life applications and interactive participation. They also touch on the challenges of balancing professional and personal commitments. Regina shares her ongoing journey to find balance by prioritizing and delegating while still maintaining her nonprofit work and her role at the GNOME Project.

+ +

They also talk about personal growth and community engagement. Regina advises newcomers to leverage open-source tools and be open to change while encouraging fair treatment within the open-source community. Victoria reflects on her experiences with Women Who Code, highlighting the importance of community involvement and networking for career advancement. Both emphasize the significance of creating safe, welcoming spaces in tech communities to foster inclusion and support, especially for women in tech.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Regina, Board Vice President of the GNOME Foundation and Founder at OpenKids Africa. Regina, thank you for joining me.

+ +

REGINA: Thank you so much for having me. It's such a great opportunity to be here today.

+ +

VICTORIA: That's wonderful. So, what's going on in your world, anything fun or exciting happening?

+ +

REGINA: You know, I actually work in Sweden. And this period is actually one of the...let me say the peak period, beginning of a new year, beginning of a new year for my job. So, there's so much around projects, projects, projects. So, I wouldn't say this is more like a fun period because, after the summer, it's a different time here when you're working in Europe.

+ +

VICTORIA: Yes, working in Sweden must be so interesting. I'm wondering if you found any cultural differences that were really surprising about working there.

+ +

REGINA: Oh yes. I think there are so many cultural differences, one of it is...I come from Nigeria, and we have more, like, a particular way...we don't have a schedule for having breakfast. So, we can have breakfast anytime we want to, and we don't feel any problem by it. So, I could decide to have my breakfast by 12:00 or by 1:00 and have my lunch by 4:00 p.m., you know, it just depends. But here, it's more like you have to have your breakfast early. And by 11:00, 12:00, 1:00, you should be having your lunch. I'm still trying to get used to that one anyway.

+ +

And also, another cultural difference that I've seen here that is very, very obvious to me compared to where I'm coming from, and I think this is basically the work culture around here, so they have, like, a work culture of taking certain timeouts for vacations, which is not the same thing for me when I was working back in Nigeria. I mean, you could just pick your vacations anytime you want to have them. But here, it's more like you have to have them around the summer somehow so that you could basically have much fun and get the time required. So, I think these basic two things are things I've had to adjust to working here now for over two years, so yeah.

+ +

VICTORIA: So, more rigid timeframes for lunch, and breakfast, and vacation [laughs].

+ +

REGINA: Yes, yes. And, you know, it's quite funny because even when my colleagues are like, "Let's go and have lunch," and I'm not ready. And they feel like, "Are you okay? Like, you should be having lunch." [laughs] So, it's really rigid timeframe here, I would say that.

+ +

VICTORIA: I like that. You know, working in a remote world, it's so easy to just work through lunch or skip breakfast and just go straight to your computer and work. So, I kind of like it. They're looking out for you and making sure that you're taking your breaks.

+ +

REGINA: Yes. Yes. And it's actually also making me self-conscious. Because, you know, working daytime as a software engineer, you don't know when to eat. You don't know when to take a break. So, that realization, I'm beginning to more, like, take it more in and adapt to the culture here. Now, I'm always looking out for myself.

+ +

And when I wake up in the morning, I remember that I need to, you know, grab something, no matter how small. And then, when it's around lunchtime, I'm also preparing to have something as well. So, I think it's really good. And it also keeps me more healthy, I would say [laughs], compared to me just eating anytime I want to eat. So, I think it's a very good culture.

+ +

VICTORIA: That's wonderful. And I really want to hear more about your journey and your career. I first heard about you and invited you to the podcast when you were a speaker for Open Source Festival in Nigeria earlier this year. So, I'm curious how you went from being in Nigeria and how did you get into software engineering and get to where you are today with the GNOME Project and everything else.

+ +

REGINA: Well, thank you so much for that. I actually started my technology career path...that's about...I would say around about 10-11 years ago. So, I graduated with a public administration bachelor's, so a bachelor's in public administration. I really did not think that I would be doing what I'm doing today.

+ +

But so, when I graduated years ago, that was 2010, I needed more opportunity. And at the time, in Nigeria, technology was not something that was very available to everyone. What I mean is technology was mostly found around those that are privileged, those with more advantage, and all of that. And I wasn't around the set of people that had...those privileged to have computers in their homes or to have parents that has the money to buy these kinds of resources.

+ +

But I had always known as a child that I was very good with my hands. And I could remember when I was quite younger, I was the one that my dad would go to to repair his phone when it's not working well. So, I had this thing with my hands that I couldn't really explain that I like to repair things.

+ +

And so, when I graduated from the university, I got an opportunity to attend more like a program, a computer program, where they would teach stuff around IT for beginners and all of that. So, I enrolled, and when I enrolled for that particular program, I can remember they would show us more like a slideshow of different programs that you would like to learn, and then give you more like, insight into job opportunities available for those programs.

+ +

So, when I sat in that class as a beginner, and I was watching the slideshows, one of the courses that caught my interest was Linux administration and database administration, so I opted in for that particular course. And that was basically how my journey began. When I began to learn about Linux, I began to use it to basically manage databases; then, I was managing databases in Oracle. And I found that one of the things that I needed to learn was basically knowing how to administer the Linux OS.

+ +

From there, I began my first job. I worked as a faculty, more like a lecturer teaching Linux administration. So, this time, I had learned, and now I have to help other students learn as well. So, because of this, I began to use more of open-source tools. Now, just to do a little bit of realization check here, at the time when I was basically lecturing years back as a Linux administrator, I did not know that the concept open source existed. I knew that I was using Linux, but I did not really understand the concept of what open source is.

+ +

So, going forward now, as I began to use these tools and began to teach students how to administer databases and use more of Linux operating system tools, I somehow, a particular year, stumbled on the GNOME Project. Because GNOME is more like a feature of the Linux OS—it's a desktop application—I was already familiar with it. I just decided to make my contributions there anyway since I had been using the GNOME Project over the years with the Linux operating system.

+ +

So, I was basically fascinated to see that everything I had done as a user in my career was basically using open source to basically teach Linux and to teach my students. So, that's, in some way, how I got into technology, how I got into open source, and all of that.

+ +

So, going into how I found myself [laughs] in the Open Source Festival and how I found myself in GNOME Project, I chose to contribute to the GNOME Project, one, because GNOME is one of the basic...I'll say a very good feature of the Linux OS. It's a desktop application––allows usability in a way that Linux seems like a Windows operating system. And so, I decided to go into GNOME just to learn more about community, how the community looks like and also contribute my quota to outreach and engagement.

+ +

So, what it means is that there are different areas you can contribute to in the GNOME project, one of it is community and engagements, which means you basically help to do outreach, marketing, and events. So, I wanted to basically bring the GNOME project down to my location, and that's Africa, Nigeria. I wanted people to basically see the benefits of what the GNOME Project is to the Linux ecosystem and how they can also contribute to it. So, because of this, I created a chapter of GNOME in Africa. Right now, we have a community of GNOME Africa. And basically, that is how I started.

+ +

So, this particular Open Source Festival that just completed for 2023 was not my first, although I was a keynote for this particular one. I had attended Open Source Festival in 2020, where I shared as a workshop speaker, and I shared more about improving Linux experience for African users. And one of the demos I did was basically showcasing the GNOME Project to the users.

+ +

VICTORIA: I love that. And maybe you can say more about what the GNOME Project is and the kind of impact it can have on communities like the one that you're from.

+ +

REGINA: One of the things with GNOME Project, in some way, it's a desktop application, a desktop application that features in the Linux operating system. So, like you know, we have the Windows operating system, and then we have user-friendly desktop that allows us to be able to basically use Windows without going through command lines all the time. GNOME is like that desktop application to Linux operating system. So, it's a feature of distros of Linux that decides to basically use it.

+ +

So, what does it do to a community like mine? I think it is very clear, usability, and allows people as well to be able to contribute to the GNOME shell. Like any other open-source projects, one of the things is that you don't just become a user. But also, you can contribute to the innovation of that particular project, so not just having to be consumers of products but also become creators of those products by contributing to what the community is doing.

+ +

So, I think what it has done to a community like mine is basically given people the opportunity and the free will to become creators for something that is quite unique to the Linux operating system and allowing them to also become part of a community, bringing diversity to the global community globally.

+ +

VICTORIA: So, how does GNOME benefit as a project from having these additional communities in areas where they may not have had before?

+ +

REGINA: I think the key thing here is diverse voices. The key thing here is bringing in people to create more diverse GNOME Projects. And it's not a buzzword. I think creating better technologies is allowing for diverse users' views to be heard. So, before I came into the GNOME project, they had presence around Europe and the U.S. but not so much around Asia and Africa. What this means is that the design, the usability, the culture around the community is not going to be that that is very friendly towards these communities that they are not part of, these communities that doesn't really know what is happening in the GNOME Project.

+ +

So, having to bring in diversity, bringing in somebody like myself, community like myself, into the GNOME Project, what this means is that there will be more opportunities for GNOME to evolve around what they have in the previous years into something that is more global, something that is more inclusive, you know, a project that allows people to become contributors and designers of the GNOME shell.

+ +

So, I would say this: when I got into the board...this is my second time in the board. We've had several discussions around how to bring in diversity into the GNOME Project and also allow users, newcomers to feel welcomed in the GNOME Project. And that is a discussion and an action that is basically progressive here.

+ +

We are having these conversations because I have now come into the project. There is now space for the GNOME Project to see that we need to be more inclusive. We need to be more diverse in our approach, in our design, in the basically way we listen to users right now. So, this was not the case before I came in. So, it's basically just allowing more diversity into the GNOME Project.

+ +

VICTORIA: I love that. And I think there's been a lot of studies and evidence that have shown that projects and companies with more inclusive and more diverse voices perform better business-wise afterwards. So, it's not only, like, a moral imperative but just smart business decisions.

+ +

REGINA: Yes, yes, yes, yes. Yes.

+ +

VICTORIA: And I'm curious, as a community organizer myself [chuckles], what surprised you about the early stages of starting up this community in Africa, or maybe even joining the board of this community now that you've become there? Anything that surprised you in the process there?

+ +

REGINA: I think one of the first things that surprised me is that it was more like I was the only one that knows that GNOME exists [laughs]. So, it's me having to first always explain, giving onboarding sections to newcomers to basically explain to them what the GNOME Project is, and doing multiple demos to show how the GNOME desktop works within Linux.

+ +

And I thought that people would just know these things and people would just understand how the Linux project works. So, that basically surprised me because I had to always have to...even up until now, I always have to more, like, introduce, guide, and explain what GNOME is and help users to basically or newcomers basically decide if it is something that they will want to contribute to, right? So, that's one thing that surprised me.

+ +

And I think the second thing that surprised me was mainly about when I came into the GNOME Project; for a project that global, I thought that there would be some certain level of diversity around the projects. And I thought that I would see more of people like myself or more of people from maybe, you know, Asia or something like that. But I realized that that wasn't the case.

+ +

Instead, I remember when I was being introduced to the project, I was introduced to other two Africans, and that made us three. And it was shocking for me that there was less presence for Africans within the GNOME Project. And I think that's one of the basic motivation for me to build a community in Africa and to see that they know that a project like GNOME exists.

+ +

VICTORIA: I love that, and it reminds me of when I was running DevOps groups with Women Who Code and DevOps DC, how frequently you have to do just a 101, like, a 101, like, here's the basics. Here's the introduction. And getting really good at that and just knowing you're going to have to keep doing that and to bring in new people. Yeah, that's interesting; that was the point for you.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: I'm curious; maybe we can dive more into open source in general and how it can be more inclusive and more diverse. Because I think what I see with open source is, you know, often, it's people doing maintenance on their own free time. They're not getting paid for it. And, of course, there's all the existing access and issues with enabling women to be more into technology careers. So, I'm curious if you have anything else that you think we should talk about with open source and how to make it more inclusive and have more voices at the table.

+ +

REGINA: One of the things here is...and I feel like discussion there is a progressive discussion as open-source communities begin to grow, open-source ecosystem continues to grow. So, one of the things here is, basically, having programs that is geared towards under-representation people within the open-source ecosystem. And this program, I feel like, should be a program that encourages some certain level of incentives, you know, stipends for people that are going to be contributing.

+ +

Because, like I said, in the past, open source has thrived more within Europe and the U.S. area. But in these areas, there are certain levels of opportunities that is presented. It's either the maintainer has good jobs, or they have projects that pays them on the side. So, they could easily give their free time to open-source contribution.

+ +

But looking at the economy side of things and problems we have within areas like Africa and Asia, if you see people contributing or you want people to contribute to open source, there must be some other level of motivations that would get them to basically contribute to your project. So, there are programs like Outreachy. Outreachy is basically a program that helps women to contribute to open source, and they are paid a certain level of stipends at the end of three months, at the end of their contribution.

+ +

We need to have more of such programs to encourage inclusive contribution into open source-projects. Because this way, we get more people that would not necessarily have an opportunity to become open-source contributors to come in to contribute. And also, [inaudible 18:29] more diverse voices in the open-source ecosystem.

+ +

Another thing here is also that we need to also talk about one of the problems within open source at the moment, which is that we have less women representation, and I'm very glad you're very deep within community and Women Who Code as well. So, you will basically relate with this one. So, there are less women within the open-source ecosystem. And even the women that are contributing––they have challenges within the ways they are treated amongst maintenance. They have challenges even with how to prioritize what they are doing and to be able to also give their time to open source.

+ +

So, these all challenges we need to begin to, you know, address them by giving voices to women within open source and helping them to solve some of these problems that they have within, you know, the communities that they are serving in.

+ +

Another thing is to have representation in leadership, and I really cannot stress this enough. When I mean representation, it's having more women leaders because this is where the gap is here at the moment. I think the Linux Foundation had a particular research; I'm not very sure about the year. But it shows that we have about 93% of men in the open-source ecosystem, and that tells you what is left of women, you know, the percentage of women that we have within the open-source ecosystem. So, there's a whole lot of work we need to do to bring in more inclusiveness, to bring in more women into the open-source ecosystem. I'm not particularly sure about the exact statistics for that research, but I know it's around that range.

+ +

Another thing is that we should encourage communities, open-source communities, to have separate channels where diverse voices can basically have their views about their community, so whether it is having to have a pool of questions geared towards, how do you think we are diverse? How diverse are we in this community? What can we do better? You know, taking metrics of your community is one way we can also bring in inclusivity into the open-source ecosystem.

+ +

One of the last thing here that I would mention is events also––open-source events, has to also be conscious around people that are attending their events, around the different races, the different genders. This matrix needs to be taken to basically help to solve and bring more inclusivity into open-source community and open-source events.

+ +

VICTORIA: You raised a lot of really great points there. And I won't even try to recap them all because I think I'll miss them [laughs]. But I think you're spot on with everything. It resonates with me, especially, like, working through Women Who Code; what you'll see is there's lots of people interested in joining. There's a drop-off rate around the mid-level of your career because of some of the things that you mentioned, the way that they're treated in the environments and in the communities, and not seeing a path forward to leadership. So, I think you're spot on with everything that you said there.

+ +

And I'm curious; I want to make sure we make time to also talk about OpenKids Africa and your founding of that. And what was the goal or the idea behind it?

+ +

REGINA: The idea behind it was basically my journey into tech. If you recall, I said I started my journey into tech after my bachelor's degree in public administration. And I felt like I could have done more with technology if I was aware about technology a bit more earlier in life.

+ +

So, I wanted to create something and to build something that would give children an opportunity to have better career choices and possibly become technologists, or software engineer, or robotics engineer, or developers in future. But giving them the opportunity to know that this set of careers exist and they could actually make their choices from it.

+ +

So, I grew up in Nigeria, like I said. And at the time I grew up, the trending careers were doctors, engineers, lawyers. And my parents actually wanted me to be a lawyer because, at the time, they believed that I was very good at arguments [chuckles]. I could argue a lot. And that basically quickly transcends to I can be a better lawyer. And also because lawyers, in those times, lawyers were very respected in the society. Now, don't get me wrong, lawyers are still respected. But at that time, it felt as though being a lawyer or being a doctor is the only way you're ever going to have a career in Nigeria.

+ +

Having to feel like I disappointed my parents because I couldn't get into law...I had a diploma. I did a diploma in law program, but I did not get into my degree. So, I had to do something close, which was the public administration I took. Having to go through those whole process in my career and then finish my bachelor's and realizing that I was a bit better in a technology career, I felt like it was a bit late for me and that I would have taken a better chance at my career choices if I had known about technologies earlier.

+ +

So, this is the motivation of creating OpenKids Africa is basically giving children an opportunity to know what they can do with technology, to know how technology cuts across different careers, and to make them realize that technology is no longer an option in your career choices; it's something that needs to be part of your career journey, whether they want to become doctors, whether they want to become technologists in future. Whatever they want to become, they need to have this basic foundation to thrive. So, that's basically what brought about OpenKids Africa.

+ +

And my target is basically children in rural communities. And so, we are teaching children in rural communities several skills: how to code, how to understand basically foundational courses within technology. Recently, we went to different schools and giving them an experience of how virtual reality looks like. And it was really fun for these children because, like I said, they are in rural communities. They don't even have these opportunities in the first place, and except it is provided to them here. So, that's basically what we're doing. We're giving children in rural community an opportunity to experience technology and to make better career choices in the future.

+ +

VICTORIA: I love that. And so, you found that the kids are really excited about learning about computers. Do you feel that the parents agree that technology is a good path for them to follow and study?

+ +

REGINA: Well, I think that that's another part of OpenKids Africa. So, when I started OpenKids Africa, I wanted to explore the rural community and understand, basically, what are the unique cases that we have here? So that's part of those...I was exploring, basically. We found that some of the children would tell us that, "I like this, but my mom or my parent would not allow me to do this. They will not allow me to know how to use computers or to become maybe a technologist in future because my mom or my dad thinks I should be a doctor," and all of that.

+ +

So, we had to remodel our strategy in a way that we now go to parents' associations in schools in rural communities. And we talk to them about technology, benefits of technology, and how they can encourage their children to learn technology, and also the future career choices for their children. And when we do this, when we speak to parents, we see the excitement of "Oh, so, my child can actually become this with this technology thing." And we also give them safety measures because, of course, there's so many things on the internet here. And there's safety tips for parents to know about, even if they want to allow their children to basically use computers and all of that, child control and all of those things.

+ +

So, by talking to parents, we've realized that we have to have a two-model approach in OpenKids Africa, where we don't just teach the children and encourage the teachers to learn more about technology, but we also have to talk to the parents to allow their children to basically explore technology careers in the future, and also, showing them the opportunities that it will pose to them. So yeah, to be honest, this is one of the surprising things that I found, and it has continued to surprise me as a founder of OpenKids.

+ +

VICTORIA: Well, that's, I think, a very common thing for founders is that you think you have one set of users, but there's actually another one [laughs] where it impacts you.

+ +

REGINA: Exactly. Exactly [laughs].

+ +

VICTORIA: That's wonderful. Are you excited about on the horizon with either the GNOME Project or OpenKids Africa?

+ +

REGINA: I will start with the GNOME Project. Right now, we are looking towards things like the Global Inclusive Initiative. And it's basically an initiative that we are looking to put together all the communities we have globally, giving more voices to diverse users to be able to contribute into GNOME. That is something on the pipeline that we're looking to plan.

+ +

And I'm also excited for OpenKids Africa. So, right now, we are exploring how to get teachers in rural communities involved with what we're doing and basically train them separately as well to know the benefit of technology to children. So, the target teachers here are teachers that basically...early child education teachers and helping them to understand how to teach technology to children, and how to inspire children to appreciate technology innovation we have around the world, innovations like virtual reality, you know, robotics, and all of that.

+ +

So, I'm really excited about that one because I feel like if you can tell the teachers how these things are and the benefits, and then they can better pass the message across to the children, making our work more easier when we have workshops and demos to do in schools, yeah.

+ +

VICTORIA: And I've actually gotten this question quite a few times from people, which is, how do you get kids interested in learning [laughs] technology and learning how to code?

+ +

REGINA: I think it's basically having a practice that is more child-friendly, co-creative. So, co-creation is basically, you are not the only one doing it. You're involving the children in it as well, and you give them the real-life experiences. So, for instance, when we went to talk about virtual reality to children, and we showed them what virtual reality does in the presentation, we engage with the kids. We make them give us their own ideas.

+ +

We even go as far as allowing them to draw what they see and give us what they think about it. But we don't stop there. We get virtual sets and show them exactly...give them a real-life experience of what virtual reality is. So, children are very, very creative, and they also have a very fast mind to pick pictures. But not only that, they can also store experiences very, very fast. So, we utilize every area that makes children excited in our workshops. After we are done, we do practices, and we give them gifts as well for engaging in those practices. So yeah, we just co-creation [laughs].

+ +

VICTORIA: Wow. And you're doing so much because you have a full-time job. You're on the board for GNOME Project, and you have your non-profit, OpenKids Africa. So, how do you find a right balance in your life of work, and extra stuff, and your regular life [laughs]?

+ +

REGINA: Honestly, I would say that the word balance I wouldn't use balance for me at the moment because I feel like I've not basically found the balance I'm looking for, but I've been able to prioritize. So, what that means is that I've been able to know what is important part-time and know when to take certain engagements. So, my full-time job is more, like, a priority right now because, of course, we need a job to be able to sustain our lives. So, I take that as my priority.

+ +

And I have different schedule of days for other things like the GNOME community and working with my team in OpenKids Africa. So, I would say I'm quite lucky to have a very good team. And also, being part of GNOME board, the commitments are not as demanding as you would expect, you know, maybe a regular board. There are fixed schedules on things, and they have flexible time for contribution as well.

+ +

I'm also part of the GNOME Africa community. And I recently just on-boarded a community manager because I realized that I need more, like, to take a step back so that I don't get burned out and all of that. So, I think it's basically prioritizing for me at the moment to gain the balance that I'm looking for. So, I think if I have a conversation with you maybe months after now, I would be able to know what balance feels like. So, I'm really experimenting with prioritizing at the moment.

+ +

VICTORIA: We'll have to check back in in a few months and see how things are going. But I think that's a very honest answer, and I appreciate that. And I think that probably relates to how a lot of people feel, honestly, even having less on their plate that it's hard to find that balance. So, I appreciate you sharing that. And I wonder, too, if you had any advice for yourself. If you could go back in time, either when you were first starting on your journey or when you were first starting on either of these projects, what advice would you give yourself?

+ +

REGINA: I think one of the things...I will talk about first starting on my technology career. I didn't have the opportunities that many young people had at the time because I didn't come from a background where my parents had the finances to basically give me the opportunity to learn technology the way I wanted to. But, I was able to make do with the resources I had at the time to learn and to basically grow.

+ +

So, an advice I will give to my younger self and to anybody that wants to come into technology that do not have the resources, I would say leverage open-source tools as much as you can because now I realize that that's basically what helped me. And also, allow yourself to grow; it will always get better.

+ +

Advice I would give to somebody coming into an open-source project like me at the GNOME Project. I think that one of the things that...understand why you're contributing to that project, and always seek to be treated fairly, always seek to be treated nicely. And also treat other people nicely and fairly as well. I think if we have these both balance, we'll have a better, healthy community within open source. And don't be scared to share your view. Don't be scared to basically be yourself wherever you are found in the community that you're representing.

+ +

And if I would like to add: OpenKids Africa, for me, if anyone would be...it's, I would say, it's still young because we are going, I think, about our third year now. So, I will say it's still young. But what I would say to any founder that wants to basically found a non-profit or do something in the society, I think, is just to get your motivation, understand why you're doing them, and be open-minded to what you'll learn along the way. That's it.

+ +

VICTORIA: I think that's great. Yeah, I love that. And I like that you mentioned that there are open-source tools out there. I'm trying to use those more, and I think I always try to iterate that for people, too, is, like, there's free training. There's free resources. There's free tools. And there are lots of people who want to see you succeed, no matter your background, or where you're from, or what you look like. So, I think that that's a really powerful message. So, I appreciate that. And do you have anything else that you would like to promote?

+ +

REGINA: I think before that, I would like to learn more about the Women Who Code. As a community builder, what basically surprised you the most?

+ +

VICTORIA: Yeah. So, what I loved about Women Who Code is that it was really aimed at helping women get started in careers in technology and maintaining careers in technology. So, I think what was interesting for me...I think I started doing it back in 2017 or 2018, and I just loved it. I loved going to a tech meetup with a room where it's all women [laughs]. Because, normally, and I'm sure you've had this experience, you go to a tech meetup, and you're maybe one of two, at the best, of women in the group. I just really enjoyed that.

+ +

And I've been really surprised and happy to see how the women, including myself, who started running the meetups, and doing trainings, and helping other women learn how to code have really advanced in their career and become directors, or engineering managers, or really senior contributors in different companies. So, I think that that was a really interesting and surprising thing for people is, like, well, if you want to grow in your career, it helps to be active in your community and to be someone that people know and to have those connections.

+ +

And I think it still surprises me to this day how my network that I got from investing in all of those meetups and all that time is still paying off [laughs]. Like, I could still, like, reach back into my network and find someone who is an expert on a particular subject or works at a company that I want to talk to or something like that. So, I think that that's been a really wonderful aspect of it.

+ +

REGINA: Wow, that's quite interesting. And I really think, also I agree with you. One of the beautiful things around communities and meetups is basically networks, the people that you get to meet, the people that you get to know along the way.

+ +

VICTORIA: Absolutely. Yeah, and those are the people that you want to keep working with. So, it helps you find jobs. It helps you find people to hire if you're hiring. It's worth it. Like [laughs], it can feel like, ugh, am I really going to go to this meetup [laughter], like, after work, after a long day? And, you know, maybe the topic is even something I'm not interested in. But it does pay off if you keep showing up and continue to invest in it. Yeah, I think that's smart.

+ +

And make people feel safe, too. I think that was a big part of it is, you know, going to a meetup and meeting someone maybe like me who's nice and friendly and wants to hear your voice. I think that has a big impact for people, especially if they're, you know, the only woman at their company. And now they have a whole set of friends [laughs]. That's, yeah, how powerful that can be for people.

+ +

REGINA: Exactly. Exactly. And you just said one of the most important things, and that's basically making people feel safe, making them welcomed as well. Interesting. Thank you for sharing that one because I was quite curious, and I wanted to really learn more.

+ +

VICTORIA: Yeah, I'm very lucky. And we actually had the CEO and founder of Women Who Code on our podcast lately. So, you're in good company [laughs].

+ +

REGINA: Nice.

+ +

VICTORIA: Yeah, it's wonderful. Do you have any other questions for me?

+ +

REGINA: My last question, and I'm going to be asking again that I will be inviting you on my podcast as well [inaudible 37:32] [laughs]

+ +

VICTORIA: Yes. Of course, yes. Absolutely. Send me the details. I'd be happy to join.

+ +

All right. Well, thank you so much again for joining us. I really appreciate your time.

+ +

And for our listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Regina Nkenchor.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+aKxHaSZn + + ]]> + + Victoria Guido + Regina Nkenchor + + + 500: Giant Robots Smashing Into Other Giant Robots 500th Episode! + https://podcast.thoughtbot.com/500 + 93b83554-267a-4504-8564-08a65c711b0f + Thu, 16 Nov 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + We released episode one of this podcast on June 11, 2012. Now, more than a decade later, we're celebrating the 500th episode of our show. In honor of this milestone, Victoria, Will, and Chad caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen. + +We chatted about what they’re up to now, what they liked and learned from hosting the show, their time at thoughtbot, and more! + 1:12:17 + no + + + We released episode one of this podcast on June 11, 2012. Now, more than a decade later, we're celebrating the 500th episode of our show. In honor of this milestone, Victoria, Will, and Chad caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen. +We chatted about what they’re up to now, what they liked and learned from hosting the show, their time at thoughtbot, and more! +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. +CHAD: And I'm your other host, Chad Pytel. +We released episode one of this podcast on June 11, 2012. Now more than a decade later, were celebrating this: the 500th episode of our show. In honor of this milestone, Victoria, Will, and I caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen. +We chatted about what they’re up to now, what they liked and learned from hosting the show and their time at thoughtbot, and more. First up: Ben Orenstein. Ben was the very first host of the show back in 2012 when he was a developer at thoughtbot. He is now the co-founder and Head of Product at Tuple, a remote pair programming tool for designers and developers. Ben, it's great to talk to you again. It's been a while since you and I talked. How have you been? +BEN: I've been decent, yeah. It's fun to be back to my roots a little bit. I told some folks that I work with that I was coming back to the pod for the 500th Episode, and they were stoked. So, it's kind of a treat to get to be on these airwaves again. +CHAD: What have you been up to since you left this show and thoughtbot? +BEN: Well, I started a company. So, I was at thoughtbot for a while; I think it was seven years. And I eventually sort of struck out to start my own thing–had a false start or two here and there. And then, I ended up starting a company called Tuple, and we still exist today, fortunately. +Tuple is a tool for doing remote pair programming. We started off on macOS and then wrote a Linux client. And we're launching a Windows client now. But it's sort of, like, screen sharing with remote control for developers who are actually writing code and want to have great, low latency remote control and who care about screen share quality and that sort of thing. +I started that about five years ago with two co-founders. Today, we are a team of 11, I think it is. And it's been going well. Our timing was really great, it turned out. We launched a little bit before COVID. So, remote work turned into a lot more of a thing, and we were already in the market. So, that helped us a ton. It was quite a wild ride there for a bit. +But things have calmed down a little lately, but it's still fun. I'm, like, really enjoying being a co-founder of a software company. It was what I've always sort of wanted to do. And it turns out it actually is pretty fun and pretty great. Although there are, of course, the ups and downs of business ownership. It is never quite as calm or relaxing as being an employee somewhere else. +CHAD: You started Tuple instigated by...full disclosure: thoughtbot's an early customer of Tuple. We're still a customer. We use it a lot. +BEN: Woo-hoo. I appreciate that. Thank you. +CHAD: If I remember right, you started and were sort of instigated to create Tuple because there was a prior product that then Slack bought, and then it started to degrade. And now, it no longer exists in the same way that it did before. +BEN: Yeah. So, there was this tool called Screenhero, which I actually started using -- +CHAD: [inaudible 02:14] +BEN: Yeah, first at thoughtbot. Some other thoughtboter introduced me to it, and we would use it for pair programming. And I was like, oh, this is nice. And then yeah, Slack kind of acqui-hired it and more or less ended up shutting the product down. And so, there was this gap in the market. And I would ask my friends, I would ask thoughtboters and other developers, like, "What are you using now that Screenhero is gone?" And no one had a good answer. +And so, after a while of this thing sort of staring me in the face, I was like, we have to try to solve this need. There's clearly a hole in the market. Yeah, so we were heavily inspired by them in the early days. Hopefully, we've charted our own path now. But they were definitely...the initial seed was, you know, let's do Screenhero but try to not get bought early or something. +CHAD: [laughs] How did you or did you feel like you captured a lot of the Screenhero customers and reached them in those early days? +BEN: I think so. The pitch for it was sort of shockingly easy because Screenhero had kind of blazed this trail. Like, I would often just be like, "Oh, we're making a thing. Do you remember Screenhero?" And they'd go, "Oh yeah, I loved Screenhero". I'd be like, "Yeah, we're going to try to do that." And they'd be like, "Nice. Sign me up." So, it for sure helped a ton. I have no idea what percentage of customers we converted. And they were a pretty large success, so probably a small fraction, but it definitely, like, made the initial days much easier. +CHAD: Yeah. And then, like you said, COVID happened. +BEN: COVID happened, yeah. I think we had been around for about a year when COVID hit. So, we were getting our feet underneath us. And we were already, like, the company was already growing at a pretty good rate, and we were feeling pretty good about it. I don't think we had quite hit ramen profitable, but we were probably pretty close or, like, flirting with it. +Yeah, the business, like, I don't know, tripled or quadrupled in a matter of months. We had a few big customers that, like, just told everyone to start using Tuple. So, we had, like, thousands and thousands of new users kind of immediately. So, it was a crazy time. Everything melted, of course. We hadn't quite engineered for that much scale. We had a really rough day or so as we scrambled, but fortunately, we got things under control. And then had this, like, very nice tailwind. +Because we started the company assuming that remote work would grow. We assumed that there would be more remote developers every year. And, you know, it's probably maybe 5% of dev jobs are remote or maybe even less, but we expect to see this number creeping up. We don't think that trend will reverse. And so, COVID just, like, it just yanked it, you know, a decade in the future. +CHAD: You haven't tripled or quadrupled your team size, have you? +BEN: No. Well, I mean, I guess, I mean, we started as 3, and now we're 11, so kind of. +CHAD: [laughs] Yeah, that's true. +BEN: Expenses have not grown as fast as revenue, fortunately. +CHAD: That's good. That's basically what I was asking [laughs]. +BEN: Yeah, yeah. We're still a pretty small team, actually. We have only, like, four or five full-time engineers on the team at the moment, which is kind of wild because we are now, you know, we have three platforms to support: Linux, Windows, and Mac. It's a pretty complicated app doing, like, real-time streaming of audio, webcams, desktops, caring about OS-level intricacies. +So, I think we will be hiring more people soon, although we haven't said that for a long time. We sort of have always had a bit of a hire-slow mentality to try to get the right team members and, like, feel a real pain before we hire someone into it. But we have been getting a bit more aggressive with hiring lately. +VICTORIA: Well, I really appreciate Tuple. I installed it when I first started working here at thoughtbot. And we have random pairings with everyone across the company. So, I'll randomly get to meet someone halfway across the world who's working on similar projects. And I think they really enjoy that I have a tool they like working to share what they're working on. So, I want to thank you for that. +And I'm curious about when you really started to scale during COVID, what were some of the technology architecture trade-offs you came across, and where did you land with it? +BEN: Well, we got fairly...I don't know if it was lucky, but we...for a long time, for years, even through COVID, maybe the first four years of the company, all Tuple calls were purely peer-to-peer. And there was no server that we owned intermediating things. This was, like, kind of one of the keys of, like, not having expenses. The scale of revenue was we could have lots more calls happen. And it wouldn't cost us bandwidth or server capacity. +To this day, still, for any calls with three or fewer participants, they're purely peer-to-peer. And this is nice for latency purposes because it just...we can find the most direct path to the internet between two people. It's also nice from our cost perspective because we don't need to pay to send that data. And that was hugely useful as call volume went up immensely. Didn't have to worry too much about server load and didn't have to worry too much about bandwidth costs. +CHAD: Today, is there a central service that makes the initial connection for people? +BEN: Yes, yeah, yeah. So, there is a signaling server. So, when you launch the app, you sign in, and you see, like, oh, which of my co-workers are online? So, there is actually a Rails app that handles that, actually, increasingly less the Rails app. We have now...I think it's a Go service that actually manages all those. I'm further and further from the code every year. Some of the technical questions might be a little bit beyond me, or I might have slightly out-of-date info. +But back to the architecture question for a second, we did a pretty big refactor when we decided to go from just being a Mac client to supporting other platforms, where we split out a cross-platform real-time communication engine written in C++ so that we could use that for all of the heavy lifting, all the managing of the connections, and the tricky bandwidth estimation, and all this stuff, and use that across different platforms. And so, today, you have the cross-platform engine, and then on top of that is a, like, a less specific layer for each of the operating systems that we support. +CHAD: So, you mentioned you're less and less in the code these days. So, what do you spend your time doing then? +BEN: It's a mix of things. These days, it's basically mostly -- +CHAD: Just cocktails on the beach, right? +BEN: Cocktails, yes [laughs], cocktails on the beach, appearing on podcasts trying to sound important and impressive, yeah. Mostly product work. So, right before this, I just got off a call with some folks from The Browser Company. They are some of our first alpha users for our new Windows clients. So, I hopped on the call with them and, like, watched three of them install the product and inevitably run into some bugs. And, you know, chatted through those with the engineer that was working on it, prioritized some stuff, made some decisions about what's coming up next, and what we're going to ignore. So, mostly product work these days. +For the first five years of the company, I was CEO, so I was doing kind of everything: marketing, and also hiring, and also product. About two months ago, I stepped down as CEO, and one of my other co-founders, Spencer, stepped up. And so, now my focus has narrowed to be mostly just product stuff and much less on the marketing or hiring side. +VICTORIA: Yeah, you mentioned that it was a little more comfortable to be an employee than to be a founder. I don't know if you could say more about that because, certainly, a lot of engineers are smart enough and capable enough to run their own company. But what really informed your choice there, and do you regret it? [laughs] +BEN: I definitely don't regret it. thoughtbot was a close second in terms of wonderful professional experiences. But running my own thing has been the most interesting professional thing I've done by a big margin. It has also been more stressful. And, Chad, I don't know if you remember, I think, like, maybe eight years ago, you tweeted something like, if you want to sleep well at night, and, like, value that, like, peace of mind, like, don't start a company or something. I have experienced that. +CHAD: [laughs] +BEN: A lot more, yeah, like waking up in the middle of the night worrying about things. It feels a little bit like the highs are higher; the lows are lower. Being an employee somewhere, it's like, if this company fails, I know I can go get another job, right? Like, you're a developer. You're extremely employable. But as the owner of the company, if the company fails, like, a huge chunk of your net worth is gone. Like, this thing you poured your life into is gone. It's way more stressful and traumatic to have that happen, or have that threatened to be happening, or just imagine that happening. +So, overall, I have found the trade-off to be totally worth it. It's awesome to make your own decisions and chart your own path. And when it works, it can work in a way that being a salaried employee can't. So, I'm happy with those trade-offs. But I think that is a good question for people to ask themselves as they consider doing something like this is, like: is that the kind of trade-off that you want to make? Because it has significant downsides for sure. +WILL: I am a big fan of Tuple also. I love it. It [inaudible 10:08] easy, especially with remote work. You hit the jackpot with COVID and remote work, so kudos for that [laughs]. Was there anything...because I know from our previous companies, about over...hopefully a lot more of the good stuff than the bad stuff. But was there anything that you learned? Because you were at thoughtbot for seven years. Was there anything that you're like, oh my gosh, I learned that, and it's helped me till this day while I'm running my company? +BEN: Yeah, quite a bit, actually. I think it'd be hard to tease apart exactly which lessons, but I do...so I ran Upcase for thoughtbot and also FormKeep. So, I got a chance to kind of run a small division of the company, while still being a normal employee and, like, having not much of that risk. And I think that was a really wonderful opportunity for me to, like, practice the skills that I was interested in. Just, like, how do you market a thing? How do you design a product and have it be good? How do you prioritize user feedback? +There were a ton of lessons from those days that I feel like made me better at running our company when we actually took a shot at it. So, there were, like, the specific things that I learned by the work I was doing there. But then just, like, I mean, I think I am the programmer I am today because of, like, the weekly dev discussions that happened. +Like, spending so much time with Joe Ferris and, like, trying to copy as much of his brain as possible, like, really, like, imprinted on me as, like, a programmer. And also, just, like, a lot of the sort of cultural things from my time at thoughtbot of, like, you should be sharing the things you're learning. Like, writing blog posts is a great use of time. Like, doing open-source work is a great use of time. +And maybe you can't directly trace how doing, like, working in public or sharing information benefits the company. It's hard to, like, attribute it from a marketing sense. But if you sort of have faith that in the large, it's going to work out, it probably will. That feels like a thoughtbot lesson to me, and I think it has served us really well; where I recorded a weekly podcast for a long time called The Art of Product. I'm recording a new podcast called Hackers Incorporated with Adam Wathan of Tailwind fame. +And I don't ever think, like, hmm, how many new leads do we think we get per episode, and how many hours has that taken? What's the ROI? I just have this sort of reflex that I developed from thoughtbot time of, like, you should be putting stuff out there, or you should be giving back. You should help other people. And that will probably help your business and make it work in the long term. +CHAD: That's a good lesson [laughs]. One of the other things, you know, while you were a host of Giant Robots, you were the first host. I remember, you know, encouraging you to be the first host, and I think we talked about that in one of the episodes along the way. But we also transitioned the format a little bit, especially as you started to work on products here; you know, it was more about the building of those products and following along with those. +And one of the things that sort of half-jokingly defined, I think, your impact on a lot of products was pricing, experimenting with pricing, learning about pricing, increasing prices more than people were maybe comfortable doing so. How has that worked out with Tuple, pricing in particular? +BEN: It's really hard to say. It's hard to know what, like, the other path would have been through the world-. We sort of decided from, like, the early days that we wanted to have, like, a fairly premium price. Like, we wanted to be the product that was really good and was, like, a little bit annoyingly expensive, but you still paid for it because it felt worth it. And I think people could debate in both directions whether we nailed that or not. +We have had a price increase that we ended up rolling back. We went, like, a little too far one time and said, "You know what? I think we're a little bit over," and we reverted that. But I would say even today, we are still a fairly pricey product. I mean, I'm pretty happy with how the company has done. I can't prove to you that, like, if the price were half what it is, we would have, you know, better success or not. +CHAD: I think it'd be very hard to make the argument that if it was half that, you would have double the number of customers. +BEN: Yeah, that's probably not true. +CHAD: Not with the customers that you have, who are companies that will pay for products that they use as much as Tuple. +BEN: Yeah, I'm happy serving the kind of companies, and they end up being mostly tech companies that really value developer happiness. When their developers come to them and they say, "We don't want to pair over Zoom. We like this thing. It's better. It feels nicer to use," they say, "Okay," and they buy the tool for them. There are places where that's not the case. And they say, "We already have a thing that does screen sharing. You're not allowed to buy this." We don't invest a lot of time trying to sell to those people or convince them that they're wrong. And I'm pretty happy serving sort of the first group. +CHAD: So, you've mentioned that you've still been podcasting. To be honest, I didn't realize you were starting something new. Is it live now? +BEN: It is live now, yeah. +CHAD: Awesome. Where can people find that? +BEN: hackersincorporated.com. It's about the transition from developer to founder, which is kind of what we've been touching on here. Yeah, hopefully, the audience is developers who want to start something or have started something who are maybe a little bit further behind progression-wise. +And it's kind of, like, I have some lessons, and Adam has some lessons, and, you know, we don't think that we're experts. But sometimes it's useful to just hear, like, two people's story and sort of see, like, what seemingly has worked for them. So, we've been trying to share things there. And I think people will find it useful. +VICTORIA: I was going to ask you for a lesson, maybe give us a little sample about how would you advise someone who's built a product and wants to market it, and it's targeted towards developers since you mentioned that previously as well. +BEN: Yeah, in a way, the question already contains a problem. It's like, oh, I built the product; now how do I market it? It's a little bit indicative of a very common failure mode for developers, which is that. They sort of assume, okay, after you make the product, you then figure out how you're going to market it. And marketing is sort of a thing you layer on later on when you realize that just, like, throwing it on Twitter or Product Hunt didn't really work. +When we started building Tuple, I was out there marketing it already. So, I had two co-founders, so this is a luxury I had. My two co-founders were writing code, and I was out doing stuff. I was recording podcasts. I was tweeting about things. I was making videos. I was giving conference talks. And I was getting people to hear about our product well before it was done. In fact, I was even selling it. I was taking pre-orders for annual subscriptions to the app while it was still vaporware. +So, I would say, like, you basically can't start marketing too early. If you start marketing early and no one really cares, well, then you don't really have to build it probably. I would actually even go a little further and say, like, I started marketing Tuple before we had a product available. But in reality, I started marketing Tuple seven or so years before that when I started publishing things through thoughtbot. +It's like when I was traveling around giving talks about Ruby, and when I was making screencasts about Vim, and when I was running Upcase, I was, over time, building an audience. And that audience was useful for thoughtbot, and it also was useful for me so that when I left, I had something like 10,000 Twitter followers or something, a few thousand people on our mailing list. +But there were a lot of developers that already sort of knew me and trusted me to make fairly good things. And so, when I said, "Hey, I've made a new thing, and it's for you," I really benefited from those years of making useful content and trying to be useful on the internet. And in the early days, we had people sign up, and they would say, "I don't even really think I'm going to use this. But I've learned so much from you over the years that I want to support you, so I'm going to pay for a subscription." +VICTORIA: I like your answer because I think the same thing when people ask me, like, because I am an organizer for Women Who Code, and I know all these great people from showing up for years in person months over months. And so, then people will ask, "Oh, how do I recruit more women in my company?" I'm like, "Well, you got to start showing up [laughs] now and do that for a couple of years, and then maybe people will trust you," right? So, I really like that answer. +WILL: How has your relationship with Chad continued to grow since you left? Because seven years at the company is a lot. And it seems like you're still on really, really good terms, and you're still friends. And I know that doesn't happen at every company. +BEN: I mean, it was tough deciding to leave. I think, like, both of us felt pretty sad about it. That was the longest I'd ever worked anywhere, and I really enjoyed the experience. So, I think it was tough on both sides, honestly. But we haven't kept in that much touch since then. I think we've emailed a handful of times here and there. We're both sociable people, and we sort of get each other. And there's a long history there. So, I think it's just easy for us to kind of drop back into a friendly vibe is sort of how I feel about it. +CHAD: Yeah. And the way I explain it to people, you know, when you're leading a company, which Ben and I both are, you put a lot of energy into that and to the people who are on that team. If you're doing things right, there's not really hard feelings when someone leaves. But you need to put in a lot of effort to keep in touch with people outside of the company and a lot of energy. And, to be honest, I don't necessarily do as good a job with that as I would like because it's a little bit higher priority to maintain relationships with them, the people who are still at thoughtbot and who are joining. +BEN: What you're saying is I'm dead to you [laughter]. That's CEO, for you're dead to me. +CHAD: No. It's just...no hard feelings. +BEN: Totally. +CHAD: I think one of the things that has been great about the show over the years is that we haven't been afraid to change the format, which I think has been important to keeping it going. So, there is sort of; in fact, the website now is organized into seasons. And I went back and re-categorized all the episodes into seasons. And when the seasons were made up of, like, sort of the format of the show or particular hosts...when we started, it was just an interview show, and it was largely technical topics. +And then we started The Bike Shed, and the technical topics sort of moved over there. But it also went with your interests more under the product and business side. Then you started working on products at thoughtbot, so it started to go even more in that. And I think Chris joined you on the show, and that was sort of all about those topics. +BEN: Yeah, that makes sense. I think if you don't let the hosts kind of follow their interests, they're going to probably burn out on the thing. It's not fun to force yourself, I think, to record a podcast. +CHAD: Yeah. And then when you left, you know, I took over hosting and hosted by myself for a while, went back to the interview format, but then was joined by Lindsey for a little while. We experimented with a few different things: one, interviews, but then we did a whole, just under a year, where we followed along with three companies. And each month, we would have an interview episode where we talked to them, all three companies, about the same topic. +And then, we also did an episode with just Lindsey and I talking about that topic and about what we learned from the startup companies that we were following along with for the year. And now we're back to interview freeform, different guests, different topics. It seems like we're going to stick with that for a little while. But, obviously, as Will and Victoria have said, like, we'll probably change it again in some way, you know, a year, two years, three years from now. +VICTORIA: Yeah, and I'm definitely bringing my interest around DevOps and platform engineering, so you'll see more guests who have that focus in their background. And with that, sometimes my interview style is more; how do I ask a question that I can't read from your developer docs and that I might not understand the answer to? [laughs] That's kind of where I like to go with it. So yeah, I'm really excited about...it's probably one of my favorite parts of my job here at thoughtbot because I get to meet so many interesting people. And, hopefully, that's interesting to everyone else [laughs] and our guests, yeah. +BEN: Totally. Well, I dramatically underestimated how awesome it would be to meet all kinds of cool people in the industry when I started the podcast. I didn't truly connect in my head, like, wait a second, if I have a 45-minute conversation with, like, a lot of prominent, awesome people in our field, that's going to be really interesting and useful for me. So, I think, yeah, it's nice to be in the hosting seat. +VICTORIA: And it's so surprising how I'll meet someone at a conference, and I'll invite them onto the podcast. And the way it winds up is that whatever we're talking about on the show is directly relevant to what I'm working on or a problem that I have. +It's been incredible. And I really appreciate you for coming back for our 500th Episode here. +CHAD: Ben, thanks very much again for joining us, and congratulations on all the success with Tuple. And I wish you the best. +BEN: Thank you so much. Thanks for being a continuing customer. I really appreciate it. +CHAD: Next, we caught up with Chris Toomey, who had a run as co-host of the show with Ben throughout 2016. +CHRIS: Hi there. Thanks for having me. +So, we're talking with all of the past hosts. I know you joined the show, and you were on it with Ben. And then you moved over to The Bike Shed, right? +CHRIS: Yeah. So, I had co-hosted with Ben for about six months. And then I think I was transitioning off of Upcase, and so that ended sort of the Giant Robots “let's talk about business” podcast tour for me. And then, I went back to consulting for a while. And, at some point, after Derek Prior had left, I took over as the host of The Bike Shed. So, I think there was probably, like, a year and a half, two-year gap in between the various hostings. +CHAD: Are you doing any podcasting now? +CHRIS: I'm not, and I miss it. It was a lot of fun. It was, I think, an ideal medium for me. I'm not as good at writing. I tend to over-edit and overthink. But when you get me on a podcast, I just start to say what's in my head, and I tend to not hate it after the fact. So [chuckles], that combination I found to be somewhat perfect for me. But yeah, lacking that in my current day-to-day. +CHAD: Well, what's been taking up your time since you left? +CHRIS: I had decided it was time to sort of go exploring, try and maybe join a startup, that sort of thing. I was sort of called in that direction. So, just after I left thoughtbot, I did a little bit of freelancing, but that was mostly to sort of keep the lights on and start to connect with folks and see if there might be an opportunity out there. +I was able to connect with a former thoughtbot client, Sam Zimmerman, who was looking to start something as well. And so, we put our act together and formed a company called Sagewell, which was trying to build a digital financial platform for seniors, which is a whole bunch of different complicated things to try and string together. So, that was a wonderful experience. I was CTO of that organization. And I think that ran for about two and a half years. Unfortunately, Sagewell couldn't quite find the right sort of sticking point and, unfortunately, shut down a little bit earlier in this year. +But that was, I would say, the lion's share of what I have done since leaving thoughtbot, really wonderful experience, got to learn a ton about all of the different aspects of building a startup. And I think somewhat pointedly learned that, like, it's messy, but I think I do like this startup world. +So, since leaving Sagewell, I've now joined a company called August Health, which has a couple of ex-thoughtboters there as well. And August is post their Series A. They're a little bit further along in their journey. So, it was sort of a nice continuation of the startup experience, getting to see a company a little bit further on but still with lots of the good type of problems, lots of code to write, lots of product to build. So, excited to be joining them. And yeah, that's mostly what's taking up my time these days. +CHAD: So, I know at Sagewell, you made a lot of technical architecture, team decisions. It was Rails in the backend, Svelte in the frontend, if I'm not mistaken. +CHRIS: Yep, that's correct. +CHAD: You know, hindsight is always 2020. Is there anything you learned along the way, or given how things ended up, that you would do differently? +CHRIS: Sure. I was really happy with the tech stack that we were able to put together. Svelte was probably the most out there of the choices, I would say, but even that, it was sort of relegated to the frontend. And so, it was a little bit novel for folks coming into the codebase. Most folks had worked in React before but didn't know Svelte. They were able to pick it up pretty quickly. +But Inertia.js was actually the core sort of architecture of the app, sort of connected the frontend and the backend, and really allowed us to move incredibly quickly. And I was very, very happy with that decision. We even ended up building our mobile applications, both for iOS and Android. So, we had native apps in both of the stores, but the apps were basically wrappers around the Rails application with a technology similar to Turbolinks native–if folks are familiar with that so, sort of a WebView layer but with some native interactions where you want. +And so, like, we introduced a native login screen on both platforms so that we could do biometric login and that sort of thing. But at the end of the day, most of the screens in the app didn't need to be differentiated between a truly native mobile app and what like, mobile WebView would look like. So, we leaned into that. +And it was incredible just how much we were able to do with that stack and how quickly we were able to move, and also how confidently we were able to move, which was really a nice thing. Having the deep integration between the backend and the frontend really allowed a very small team to get a lot done in a short time. +CHAD: Does that code live on in any capacity? +CHRIS: No. +CHAD: Oh. How does that make you feel? +[chuckles] +CHRIS: It makes me feel very sad, I will say. That said, I mean, at the end of the day, code is in service of a business. And so, like, the code...there are, I think, probably a couple of things that we might be able to extract and share. There were some interesting...we did some weird stuff with the serializers and some, like, TypeScript type generation on the frontend that was somewhat novel. +But at the end of the day, you know, code is in service of a business, and, unfortunately, the business is not continuing on. So, the code in the abstract is...it's more, you know, the journey that we had along the way and the friends we made and whatnot. But I think, for me, sort of the learnings of I really appreciate this architecture and will absolutely bring it to any new projects that I'm building from, you know, greenfield moving forward. +VICTORIA: I'm curious what it was like to go from being a consultant to being a big player in a startup and being responsible for the business and the technology. How did that feel for you? +CHRIS: I would say somewhat natural. I think the consulting experience really lent well to trying to think about not just the technical ramifications but, you know, what's the business impact? How do we structure a backlog and communicate about what features we want to build in what order? How do we, you know, scope a minimal MVP? All those sorts of things were, I think, really useful in allowing me to sort of help shape the direction of the company and be as productive of an engineering team as we could be. +CHAD: A lot of the projects you worked on at thoughtbot were if not for startups, helping to launch new products. And then, a lot of the work you did at thoughtbot, too, was on Upcase, which was very much building a business. +CHRIS: Yes. I definitely find myself drawn in that direction, and part of like, as I mentioned, I seem to be inclined towards this startup world. And I think it's that, like, the intersection between tech and business is sort of my sweet spot. I work with a lot of developers who are really interested in getting sort of deeper into the technical layers, or Docker and Kubernetes and orchestration. And I always find myself a little bit resistant to those. I'm like, I mean, whatever. Let's just...let's get something out there so that we can get users on it. And I am so drawn to that side, you know, you need both types of developers critically. +I definitely find myself drawn to that business side a little bit more than many of the folks that I work with, and helping to bridge that gap and communicate about requirements and all those sort of things. So, definitely, the experience as a consultant really informed that and helped me have sort of a vocabulary and a comfort in those sort of conversations. +WILL: How did Upcase come about? Because I know I've talked to numerous people who have gone through Upcase. I actually went through it, and I learned a ton. So, how did that come about? +CHRIS: I think that was a dream in Ben Orenstein's eye. It started as thoughtbot Learn many, many years ago. There was a handful of workshops that had been recorded. And so, there were the video recordings of those workshops that thoughtbot used to provide in person. Ben collected those together and made them sort of an offering on the internet. +I think Chad, you, and I were on some podcast episode where you sort of talked about the pricing models over time and how that went from, like, a high dollar one-time download to, like, $99 a month to $29 a month, and now Upcase is free. And so, it sort of went on this long journey. But it was an interesting exploration of building a content business of sort of really leaning into the thoughtbot ideal of sharing as much information as possible, and took a couple of different shapes over time. +There was the weekly iterations of the video series that would come out each week, as well as the, like, longer format trails, and eventually some exercises and whatnot, but very much an organic sort of evolving thing that started as just a handful of videos and then became much more of a complete platform. I think I hit the high points there. But, Chad, does that all sound accurate to you? +CHAD: Yeah, I led the transition from our workshops to Learn, which brought everything together. And then, I stepped away as product manager, and Ben took it the next step to Upcase and really productized it into a SaaS sort of monthly recurring billing model and took it over from there. But it still exists, and a lot of the stuff there is still really good [laughs]. +CHRIS: Yeah, I remain deeply proud of lots of the videos on that platform. And I'm very glad that they are still out there, and I can point folks at them. +VICTORIA: I love that idea that you said about trying to get as much content out there as possible or, like, really overcommunicate. I'm curious if that's also stayed with you as you've moved on to startups, about just trying to get that influence over, like, what you're doing and how you're promoting your work continues. +CHRIS: I will say one of the experiences that really sticks with me is I had followed thoughtbot for a while before I actually joined. So, I was reading the blog, and I was listening to the podcasts and was really informing a lot of how I thought about building software. And I was so excited when I joined thoughtbot to, like, finally see behind the curtain and see, like, okay, so, what are the insider secrets? +And I was equal parts let down...actually, not equal parts. I was a little bit let down but then also sort of invigorated to see, like, no, no, it's all out there. It's like, the blog and the open-source repos and those sort of...that really is the documentation of how thoughtbot thinks about and builds software. So, that was really foundational for me. But at the same time, I also saw sort of the complexity of it and how much effort goes into it, you know, investment time Fridays, and those sort of things. +Like, a thoughtbot blog post is not a trivial thing to put up into the world. So many different people were collaborating and working on it. And so, I've simultaneously loved the sharing, and where sharing makes sense, I've tried to do that. But I also recognize the deep cost. And I think for thoughtbot, it's always made sense because it's been such a great mechanism for getting the thoughtbot name out there and for getting clients and for hiring developers. +At startups, it becomes a really interesting trade-off of, should we be allocating time to building up sort of a brand in the name and getting ourselves, you know, getting information out there? Versus, should we be just focusing on the work at hand? And most organizations that I've worked with have bias towards certainly less sharing than thoughtbot, but just not much at all. Often, I'll see folks like, "Hey, maybe we should start a blog." And I'm like, "Okay, let's just talk about how much effort that [laughs] actually looks like." And I wonder if I'm actually overcorrected on that, having seen, you know, the high bar that thoughtbot set. +CHAD: I think it's a struggle. This is one of my [laughs] hot topics or spiels that I can go on. You know, in most other companies, that kind of thing only helps...it only helps in hiring or the people being fulfilled in the work. But at most companies, your product is not about that; that's not what your business is. So, having a more fulfilled engineering team who is easier to hire—don't get me wrong, there are advantages to that—but it doesn't also help with your sales. +CHRIS: Yes. +CHAD: And at thoughtbot, our business is totally aligned with the people and what we do as designers and developers. And so, when we improve one, we improve the other, and that's why we can make it work. That is marketing for the product that we actually sell, and that's not the case at a SaaS software company. +CHRIS: Yes, yeah, definitely. That resonates strongly. I will say, though, on the hiring side, hiring at thoughtbot was always...there was...I won't say a cheat code, but just if someone were to come into the hiring process and they're like, "Oh yeah, I've read the blog. I listen to the podcast," this and that, immediately, you were able to skip so much further into the conversation and be like, "Okay, what do you agree with? What do you disagree with? Like, let's talk." But there's so much. +Because thoughtbot put so much out there, it was easy to say, like, "Hey, this is who we are. Do you like that? Is that your vibe?" Whereas most engineering organizations don't have that. And so, you have to try and, like, build that in the context of, you know, a couple of hour conversations in an interview, and it's just so much harder to do. So, again, I've leaned in the direction of not going anywhere near thoughtbot's level of sharing. But the downside when you are hiring, you're like, oh, this is going to be trickier. +CHAD: Yeah. One of the moments that stands out in my mind, and maybe I've told this story before on the podcast, but I'll tell it again. When we opened the New York studio, it was really fast growing and was doing a lot of hiring. And one of the people who had just joined the company a couple of weeks before was doing an interview and rejected the person was able to write an articulate reason why. But it all boiled down to this person is, you know, not a fit for thoughtbot. +Based on what they were able to describe, I felt very confident with the ability or with the fact that they were able to make that call, even though they had been here only a couple of weeks, because they joined knowing who we were, and what we stand for, and what our culture and our values are, and the way that we do things, and all that kind of thing. And so, yeah, that's definitely a huge benefit to us. +VICTORIA: I've certainly enjoyed that as well, as someone who hires developers here and also in meeting new companies and organizations when they already know thoughtbot. That's really nice to have that reputation there, coming from my background—some really more scrappier startup kind of consulting agencies. +But, you know, I wanted to talk a little bit more about your podcasting experience while you're here. So, I know you were on both The Bike Shed and Giant Robots. Which is the better podcast? [laughter] So, what's your...do you have, like, a favorite episode or favorite moment, or maybe, like, a little anecdote you can share from hosting? +CHRIS: Well, I guess there's, like, three different eras for me in the podcasting. So, there's Giant Robots with Ben talking more about business stuff, and I think that was really useful. I think it was more of a forcing function on me because I sort of...Both Ben and I were coming on; we were giving honest, transparent summaries of our, like, MRR and stats and how things were growing, and acted as sort of an accountability backstop, which was super useful but also just kind of nerve-wracking. +Then, when I joined the Bike Shed, the interviewing sequence that I did each week was just a new person that I was chatting with. And I sort of had to ramp them up on, hey, here's a quick summary on how to think about podcasting. Don't worry, it'll be great. Everybody have fun. But I was finding each of the guests. I was sort of finding a topic to talk about with them. So, that ended up being a lot more work. +And then, the last three years chatting with Steph that was by far my favorite. There was just such a natural back-and-forth. It really was just capturing the conversations of two developers at thoughtbot and the questions we would ask each other as we hit something complicated in a piece of code or, "Oh, I saw this, you know, article about a new open-source repository. What do you think about that?" It was so much easier, so much more natural, and, frankly, a lot of fun to do that. +And, two, I actually do have an answer to the favorite podcast episode, which is the first episode that Steph was ever on. It was before she actually joined as a co-host. But it was called “What I Believe About Software.” And it was just this really great, deep conversation about how we think about software. And a lot of it is very much, like, thoughtbot ideals, I would say. But yeah, Steph came in and just brought the heat in that first episode, and I remember just how enjoyable that experience was. And I was like, all right, let's see if I can get her to hang out a little bit more, and, thankfully, she was happy to join. +WILL: What was your favorite position, I guess you can call it? Because you say you like the mixture of business and, you know, development. So, you've been in leadership as development director, CTO. You've been a web developer. You've been over content, like, with Upcase. What was your favorite position [inaudible 16:43] you were doing, and why was it your favorite? +CHRIS: The development director role feels like sort of a cheating answer, but I think that would be my answer because it contained a handful of things within it. Like, as development director, I was still working on client projects three days a week. And then, one day a week was sort of allocated to the manager-type tasks, or having one-on-ones with my team sort of helping to think about strategy and whatnot. And then, ideally, still getting some amount of investment time, although the relative amounts of those always flexed a little bit. Because that one sort of encompassed different facets, I think that's going to be my answer. +And I think, like, some of what drew me to consulting in the first place and kept me in that line of work for seven years was the variety, you know, different clients, as well as, even within thoughtbot, different modes of working in podcasts or video. Or there was a bootcamp that I taught, a session of Metis, which that was a whole other experience. And so, getting that variety was really interesting. +And I think as sort of a tricky answer to your question, the development director role as a singular thing contained a multitude, and so I think that was the one that would stand out to me. It's also the most, you know, the one that I ended on, so [laughs] it might just be recency bias, but yeah. +VICTORIA: Oh, I love that. Is there anything else that you would like to promote on the podcast today? +CHRIS: No, although as you ask the question, I feel like I should, I don't know, make some things to promote, get back into some, I don't know, content generation or something like that. But for now, no. I'm, you know, diving into the startup life, and it's a wonderful and engrossing way to do work, but it does definitely take up a lot of my headspace. So, it's an interesting trade-off. +But right now, I don't know; if folks are online and they want to say hi, most of my contact information is readily available. So, I would love to say hi to folks, anyone that listened in the past or, you know, has any thoughts in the now. Would love to connect with folks. But otherwise, yeah, thank you so much for having me on. +CHAD: In 2017, I took over from Ben as solo host of the show but was joined by Lindsey Christainson as cohost in 2019. After some time away from thoughtbot, Lindsey is back with us and we sat down to catch up with her. +VICTORIA: Why don't you tell me about your current role with thoughtbot? +LINDSEY: I am currently supporting marketing and business development at thoughtbot, as well as working as a marketing consultant for thoughtbot clients. +VICTORIA: Great. And I understand that you had worked with thoughtbot many years ago, and that's when you also came on as a co-host of Giant Robots. Is that right? +LINDSEY: Yeah, a couple of years ago. I left thoughtbot in spring of 2021. And I forget how long my stint was as a co-host of Giant Robots, but over a year, maybe a year and a half, two years? +CHAD: Yeah, I think that's right. I think you started in 2019. +LINDSEY: Yeah. Yeah, that sounds right. And Chad and I were co-hosts, I think, similar to the setup today in which sometimes we hosted together, and sometimes we were conducting interviews separately. +CHAD: And then we sort of introduced a second season, where we followed along with a batch of companies over the course of the entire season. And that was fun, and we learned a lot. And it was nice to have consistent guests. +LINDSEY: Yeah, that was a lot of fun. I really liked that format. I don't know; they almost were, like, more than guests at that point. They were just like other co-hosts [laughs] that we could rely on week in, week out to check in with them as they're working on early-stage companies. So, every time we checked in with them, they usually had some new, exciting developments. +WILL: I really like that idea. How did y'all come up with that? +CHAD: I'm not sure. I think a few years before I had taken over hosting of the show, and I forget...my memory maybe is that I went to Lindsey and said, "You know, let's do something different." But I'm not sure. Does that match your memory, Lindsey? +LINDSEY: Yeah, I think there were two main drivers; one was I think you were feeling like you were having similar conversations in the interviews every time. Like, you couldn't get to a certain depth because every time you were interviewing someone, you were doing, like, the, "Well, tell me your founding story." And, you know, how did you raise funding? It kind of got a little bit repetitive. +And then, on the side, the few we had done together, I think we both really enjoyed. So, we were thinking, like, what's the format in which the two of us could co-host together more regularly? Because I'm a pleasure to talk to [laughter]. I think you were like, I need to talk to Lindsey more. [inaudible 3:13] +VICTORIA: What is your hosting style? How would you describe your approach to hosting a podcast? +LINDSEY: I mean, obviously, it's a podcast about products and business. I think as a marketer, I am, you know, drawn a lot to the marketing side, so tending to ask questions around go-to-market audience, users. That's always just, like, a particular interest of mine. But then also, like, the feelings. I love asking about the feelings of things, you know, how did it feel when you started? How did it feel when you made this tough decision? So, that's another thing I think I noticed in my interviews is asking about some of the emotions behind business decisions. +VICTORIA: And I like hearing about how people felt at the time and then how they felt afterwards [laughs]. And, like, how people around them supported each other and that type of thing. That's really fun. +I'm curious, too, from your marketing background and having to do with podcasts like; some founders, I think, get the advice to just start a podcast to start building a community. But I'm curious on your thoughts about, like, how does podcasting really play into, like, business and marketing development for products? +LINDSEY: Oh yeah. It's become definitely, like, a standard channel in B2B these days. I feel like that it's pretty typical for a company to have a podcast as one way that they engage their audience and their users. In marketing, you're really vying for people's attention, and people's attention span is getting shorter and shorter. So, like, if you have an ad or a blog, you're getting, like, seconds, maybe minutes of someone's attention. And whereas something like a podcast offers a unique channel to have someone's undivided attention for, you know, 30 minutes, an hour, and if you're lucky, you know, checking back in week over week. So, it became a really popular method. +That said, I think you're probably also seeing the market get saturated [laughs] with podcasts now, so some diminishing returns. And, you know, as always, kind of looking for, you know, what's the next way? What's the next thing that people are interested in in ways to capture their attention? +CHAD: What is the next thing? +LINDSEY: I don't know, back to micro-content? TikTok videos -- +CHAD: Yeah, I was going to say TikTok, yeah. +LINDSEY: Yeah, you know, 10-30 seconds, what can you communicate? +VICTORIA: I see people live streaming on Twitch a lot for coding and developer products. +LINDSEY: Yeah, I think we've seen some of that, too. We've been experimenting more at thoughtbot with live streaming as well. It's another interesting mechanism. But yeah, I don't know, it's interesting. It's another form of, like, community and how people engage with their communities. So, it's always evolving. It's always evolving, and sometimes it's not. Sometimes, people just do want to get in a room together, too, which is always interesting. +WILL: What has been, in your experience, the good the bad? Like, how do you feel about the way that it has shifted? Because I think you started in, like, 2000, like, kind of earlier 2000, 2005, something around there. And it was totally different than now like you're saying. Because I feel like, you know, Channel 5 30-second ad, you know, with some of the marketing depending on what you're doing, to now to where you're, like, you're paying influencers to advertise your product, or you're doing an ad. Or it's more social media-driven and tech-driven. What has been your opinion and feelings on the way that it has grown and evolved? +LINDSEY: Marketing, in general, yeah, I graduated college in 2005 and started my marketing career. And yeah, you could, like, actually get people to click on banner ads back then, which was pretty [inaudible 07:14] [laughs]. +WILL: I forgot about banner ads [laughs]. +LINDSEY: I don't know, yeah. I don't know. In order for myself to not just get too frustrated, I think I've got to, like, view it as a game kind of. What new things are we going to try? You know, what do we see work? But it can really depend. And I've always been in B2B side of things. And consumer, I'm sure, has its own kind of evolution around how people engage and how they consume content and byproducts. But in B2B, you know, it can really depend on industry too. +You know, I'm working with a client right now in the senior living space, and they're really big in in-person conferences. So, that's how people consume, get a lot of their information and, make connections, and learn about new products. So, it's been interesting to work in an industry that what might be considered, like, a little bit more old-school channels are still effective. And then just thinking about how you weave in the new channels with the existing ones without ignoring them. They might get information in conferences, but they're still a modern human who will then, you know, search online to learn more, for example. +VICTORIA: It reminds me of a phrase I like to say, which is that, like, technology never dies; you just have more of it. There's just more different options and more different ways to do things. And some people are always, you know, sometimes you have to be flexible and do everything. +CHAD: So, tell us more about what you did in between...after you left thoughtbot, what did you do? +LINDSEY: I was heading up B2B marketing for a company called Flywire, which is headquartered in Boston but is a global company now. And they were just kind of starting their B2B business unit, which, as I mentioned, B2B is my personal specialty. I had been connected to their CMO through the Boston startup community. And yeah, I was helping them kind of launch their go-to-market for B2B. The industries they were in before...they got their start in higher education and then expanded in healthcare and found a niche in luxury travel, and then we were figuring out the B2B piece. But yeah, I was there for about a year and a half. +They actually went public the second week I was there, which was an interesting [laughs] experience. I knew they were, like, on that journey, but it was kind of funny to be there the second week, and people were, like, "Congrats." And I was like, "Well, I definitely didn't have anything to do with it because I just finished my onboarding, but thank you," [laughs]. +CHAD: One of the things that really impressed me when you joined thoughtbot was the way in which you learned about who we were and really internalized that in a way where you were then able to pretty meaningfully understand our market, our positioning in the market, and come up with new strategies for us. I assume that's something you're good at in general [laughs]. How do you approach it? How did you approach it when you joined Flywire, for example? And how was it the same or different than how you approached thoughtbot? +LINDSEY: Ooh, yeah, that's a good question. And I appreciate that comment because it's difficult. But I think, yeah, with any new organization that I'm joining, you know, I think starting out with your kind of mini-listening tour of your key stakeholders across, you know, the different departmental focuses to get a sense of, what are the challenges? What are the opportunities? It's actually like, you know, it's the SWOT analysis, kind of trying to fill in your own mind map of a SWOT analysis of where the company is. What are the major hurdles you're facing? Where are people trying to go? What have they tried that's worked? What have they tried that's failed? +But then, like, I think for the culture component, I think a part of that maybe is, like, feel, and maybe something that I do have a knack for. Again, maybe this is, like, you know, emotional intelligence quotient, where it's like, you know, but it's the company, you know, who is this company? What is important to them? How do they work and go about things? +I know thoughtbot is certainly very unique, I think, in that arena in terms of being, like, a really value-driven company, and one where especially, like, marketing and business work is, like, distributed across teams in a really interesting way. You know, I'm sure the fact that it fascinated me and was something I could get passionate and get behind was something that also helped me understand it quickly. +CHAD: I was excited that...or it was sort of a coincidence because I had reached out to you and without realizing that you had left Flywire. And Kelly, who had been doing a combined sales and marketing role, was going on parental leave. And so, it was fortuitous [laughs] that you were able to come back and help us and provide coverage, like, Kelly was out. +LINDSEY: Yeah, it definitely felt like stars aligned moment, which, you know, I'm pretty woo-woo, so I believe in [laughter]...I believe in that kind of thing. You know, yeah, it was wild. It really did feel like your email came out of nowhere. And, you know, I mentioned it, obviously, to my partner and my friends. And they were like, "Oh, he definitely knows, like, that you left your last company." And I'm like, "I actually don't think he does [laughter]. I actually don't think he does." Yeah, and then we started chatting about me coming back to help. And it was great. thoughtbot makes it hard to work anywhere else [laughs]. So, I was happy to come back. I missed the team. +CHAD: And one of the exciting things, and you've mentioned it, is you're not just doing marketing for thoughtbot now. We have started to offer your services to our clients. +LINDSEY: Yeah, I'm super excited about this. And it's something I'd started thinking about. I had decided to take some time off between Flywire and my next thing and had started thinking about doing marketing, consulting. And as I'm doing that, I'm thinking a lot about how thoughtbot does consulting and, you know, wanting to emulate something like that. +So, I started back up at thoughtbot. That wasn't part of the plan. I was just going to, you know, fill in for Kelly and help with marketing things. But then, you know, a good opportunity arose to work on a client, and I was really excited. When, you know, Chad, you and I chatted through it, we came to the conclusion that this was something worth exploring under the, you know, thoughtbot umbrella. And it's been a really great experience so far. And we now have brought on another client now. And if you're listening and need early-stage B2B marketing support, reach out to lindsey@thoughtbot.com. +CHAD: Definitely. And Lindsey is pretty good, so you're going to like it [laughs]. +LINDSEY: Yeah, you're going to like the way you look. +WILL: Yeah, definitely. Because I can even feel your presence here, you know, coming back. Because even like, you know, the market where it's at now and some of the suggestions that, you know, you've been helping us. For example, like, I do a lot of React Native, and you're like, "Hey, you know, blog posts have done a lot of traction, you know, let's get some more blog posts out in the market to help with the traffic and everything." +So, the question I have with that is, like, thank you for even suggesting that because it's, like, those little things that you don't even think about. It's like, oh yeah, blog posts, that's an easy transition to help the market, clients, things like that. But with the market the way it is, what has been your experience working during this time with the market? I don't know if you want to call it struggling, but whatever you want to call it that, it's doing [laughs]. +LINDSEY: Yeah, I mean, the economy is difficult now. We also went through a really tough spot when I was here last time. During COVID, you know, we faced a major company challenge. And, I mean, I'll let Chad speak to it, but I would imagine it's probably one of the bigger, like, economic inflection points that you faced. Would you say that? +CHAD: Yeah, definitely. The thing about it that made it worse was how quickly it happened. You know, it was something that you didn't see coming, and then, you know, about 40% of our business went away in a single month. That's the kind of thing that was a real shock to the system. +I think the thing that made it difficult, too, was then the aspects of COVID, where we were no longer able to go into our studios. We were all working remotely. We were isolated from each other. And so, that made executing on what needed to be done in order to make the company survive additionally challenging. +LINDSEY: Yeah, so I think, like, going through that experience, also, and seeing how the team and the leadership team rallied together to get through it. And then, you know, ultimately, I think 2021 and 2022 have, like, really good years. That was a really positive experience. And something I'll definitely take with me for a while is just, like, keeping a cool head and just knowing you have, like, really smart, talented folks with you working on it and that you can get through it. +And just, like, doing some, I mean, we relied on what we did best, which was, like, design thinking, using design exercise to think about, like, how we might re-organize the company, or what other services we might try launching, or how might we re-package, you know, larger services into smaller more palatable services when people have, like, kind of tighter purse strings. So, that was, like, a great educational experience, and I think something we just continue to do now: be open to change, be open to changing how we package services, what clients we go after, and coming at it with, like, an agile, experimental mindset and try to find out what works. +VICTORIA: I really appreciate that. And it aligns now with the new service we've developed around you and the marketing that you provide. And I'm curious because I've had founders come up to me who say they need help with marketing or they need to, like, figure out their marketing plans. So, say you've met a founder who has this question, like, what questions do you ask them to kind of narrow down what it is they really need and really want to get out of a marketing plan? +LINDSEY: I've been thinking about this a lot recently. And, like, obviously, I see other marketing leaders in the market. Marketers like to talk about what they do on LinkedIn [laughs], so I get to...I read a lot about different people's approaches to this. And some people kind of go in and are like, okay, this is what you need. This is how we're going to do it, and they start executing on it. +And I really do take a very collaborative approach with founders. I think they're, especially in early stage, they're your most important asset in a way, and a lot of their intuition around the market and the business, you know, it's gotten them to where they're at. And so, I think starting from the point of, like, taking what they view as priorities or challenges, and then helping them better explore them or understand them with my own marketing experience and expertise, to narrow in on work that's going to be valuable for them, is kind of my starting point with early-stage companies. +Again, a little bit of that, like, listening tour kind of attitude of, like, what do you think is important? And there's probably data points behind that. And then helping you as a company frame that into, you know, what's going to be the most valuable? Like, is it an awareness campaign, or a lead-generating campaign, or a content strategy? +Do we actually need to take a look at the data you have and spend a little bit of effort cleaning that up so that we understand what we're working with better? Is it sales enablement? You know, do you have existing salespeople, but maybe they're struggling or don't have unified tools and messaging that they're using? That's how I kind of first approach it with the founder, very much kind of in lockstep. +VICTORIA: I appreciate that little preview of what your services would be like. And I always really appreciate when you help me with my marketing plans around our Mission Control team and platform engineering and how to really refine our message and make sure it reaches the right people. +LINDSEY: Yeah, I think another thing I used at thoughtbot in the previous time that I've taken with me to Flywire and now with clients is, like, the idea of, like, mini-briefs and working on them with the key stakeholder, whether that's you the head of, you know, a business unit or a founder, which is, like, let's just take the, however long, 30 minutes to talk about, who's the audience? What's our goal? You know, what are the elements that might help us achieve that goal? What are some of the metrics that we might use to measure whether or not we were successful in reaching that goal? +And it sounds really basic, but a lot of people can skip it. And I think then there's confusion around who you are targeting, or people have different ideas in mind of, like, what you are actually trying to achieve. +VICTORIA: I like that. And to pivot a little bit, I wonder if you have any thoughts on our podcast here at Giant Robots. What do you think the benefit of it is to thoughtbot, actually? +LINDSEY: I think it's been a brand builder and a way to, again, like, another channel to engage with our audience. It's been so long-standing now, you know. I talked about how most companies have a podcast now. But this is what? The 500th Episode, right? Over years and years, which is really impressive that it's been going that long. So, it's a way to bring the brand to life. +I think one of my first insights coming into the thoughtbot team is, you know, as a consulting organization, when I interviewed clients about what they loved about thoughtbot, I thought they were going to say that they ended up with amazing products. And they did. They did say that. They said they ended up with amazing products. But I said, "You know, what was the biggest benefit, or what stood out to you the most?" And they all said it was the people, you know, they loved the people. They loved learning from thoughtboters. They were, like, you know, teachers and mentors, and so smart, but also, like, very kind and helpful. +So, when you think about it like that, podcasts or videos and ways you're able to, like, better see and hear and feel the person on the other side is a really great way of, you know, continuing to make that connection with folks. +VICTORIA: I love that answer. I wish we had little heart emojis we could share, like in Google Meets with Zencastr. So, what do you think...Maybe this is a question for everyone on here, too, that we're asking is, like, where do you think we should go with the podcast? What should we change? What should we think about for future episodes? +LINDSEY: I think you should ask the listeners if possible. We tried, in the past, surveying. And it's hard because you don't have, like, necessarily an email list of listeners. But there does tend to be some overlap of, like, our newsletter subscribers with podcast listeners. So yeah, I'd go straight to the audience and just learn more about...ask them what they care about and what they want to learn. Because at the end of the day, it's really for them, providing value for them and something they want to come back to listen to week after week. +CHAD: Oh, when we've done the surveys in the past, we've had very few people [laughs] respond. So, you can always email us at hosts@giantrobots.fm if you have feedback on the show, questions for people, questions for the hosts, or opinions on, you know, who would make a great guest or a direction we should take the show. All that is super valuable. And we definitely would take it to heart. +VICTORIA: Yes, please send me your feedback. I will read your emails and incorporate it into the show. So, it'd be great. I wonder, Lindsey, do you have any questions for us? +LINDSEY: How do y'all like hosting the podcast? [laughs] How's it going? +WILL: I feel like I'm starting to find my style and the way that it works best for me, so that's exciting. I do want to engage more with the listener. So, that's one thing that I'm trying to brainstorm on what's the best way to do that. Also, you know, inviting just different types of guests, trying to think through what's some different type, a different angle that we can invite for the podcast? But as far as how do I like doing the podcast, I really enjoy it. It's pushed me out of my comfort zone. But it was a good thing for me. So, I'm really enjoying it. +LINDSEY: How long have you been doing it, Will? +WILL: A little over a year. So, I think I started after I went on parental leave with my youngest child. And then when I came back, I took a couple of weeks, and then I started. So yeah, about a year, a little over a year. +LINDSEY: That's fun. What's your favorite part about doing it? +WILL: I love talking to the guests. And I love learning, like, people's stories. And so, that has been the most exciting thing for me, like, because especially with the founders, like, it's not easy to be a founder. But people they go all out, and they make a difference. And even through the heartache, and the pain, and just all different levels, but they're willing to endure it because they believe in their product. They believe it's going to make a difference. So, I think the stories, the stories, and the people, meeting new people, and hearing their stories is what I love. +VICTORIA: And I'm the same as Will. I've been on the show for about a year now. And the first episode I recorded with Chad, I think afterwards, he said, "Oh, you didn't ask any questions [laughs]. Like, you were too quiet." But then I think I got a hang of it. And now I really like making people feel comfortable and opening up about their story and hearing, yeah, like the emotions and what it really felt like to go through that. Because, you know, if it's interesting for me to hear that, then I think that our audience will also appreciate it and to feel like you're not alone, right? To build that community and hear those same stories and people going through similar things. +Yeah, some of the guests that we've had on have just been really incredible. And they are people who I admire in the industry, and to have them on the show and to be a part of it has been really special. +LINDSEY: Yeah, that's cool. That reminds me another kind of underlying thing I love about the podcast and the interviewing. It's also low-key, like, market research [laughs], which is interesting, like, better understanding the types of people we provide services to and their kind of drivers and challenges. There's, like, an interesting element there. And yeah, at the end of the day, you get really interested and into it, and you're just, like, having a conversation with them, probably makes for the best kind of episode. +VICTORIA: Right. And then afterwards, you have to, like, pace around the room to, like, decompress [laughs] because you're operating at, like, such a level, at least, that happens to me; I don't know about anybody else. +LINDSEY: No, totally. I would also...if we had, like, an episode scheduled and then it got, like, rescheduled at the last second, I would find I had all this, like, pent-up energy that my body was, like, preparing me to, like, go into the interview. +VICTORIA: Yeah, sometimes I have to get hyped. Like, you got to do some movement right before because you got to get into the zone. But I'm curious, Chad, this is, you know, you've been a host for a number of years now, too. Like, how do you feel about the podcast? Do you still like hosting it? +CHAD: No [laughs]. I'm kidding. I have taken a little bit of a break recently from the ongoing continuous hosting because I was really busy. And it was hard to create the time and dedicate the time to it. But I really like hosting the show. I love talking to different people and learning about their stories. I also really like the episodes where it's able to be more of a conversation with people, and I get a lot of enjoyment out of that. +LINDSEY: We've seen, also, some trends in, like, the episodes where Chad will talk about, like, the business of thoughtbot perform well, too. Because I know there's, like, a lot of folks, who listen who also own agencies or consultancies and always appreciate Chad's transparency around how we run thoughtbot. +VICTORIA: That's interesting. And yeah, I think one of the ways that we've been experimenting with getting the episodes to be more conversational is to have more than one host in the episode. So, Chad or Lindsey, if you're ever wanting to rejoin an episode or invite a founder on and be one of the co-hosts, you're always welcome. +LINDSEY: I'm always down. I love talking. That actually...that does remind me we were thinking...we've been doing live streams that cover thoughtbot's new startup incubator. So, we have the second session currently in progress. But repurposing some of those live streams into, like, mini–Giant Robots episodes. So, that may happen soon. We may do a little bit of that and then give some insight into what it's like week in, week out for founders going through the startup incubator. It's super, super interesting if you're a startup nerd like me. +VICTORIA: That would be great, yeah. We did an episode with Agnes for the first incubator round, and I think that was really interesting. And something we've been experimenting with a little bit is having that diverse group of founders. So, there's founders from companies who the company has managed to survive and excel, and they've been around for ten years or so. Then there's other people who are just starting out. And, like, hearing those stories, too, and, like, the things they're thinking about and what challenges they're facing has been super interesting. Anything else you'd like to promote Lindsey? +LINDSEY: Hire me for all your marketing consulting needs. +CHAD: It was great to catch up with everyone in celebration of our 500th episode. Thank you to Ben, Chris, and Lindsey. But most of all, that you to you. We make the show, but you make the show possible. +You can subscribe to the show and find notes, along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. +This podcast is brought to you by thoughtbot, and produced and edited by Mandy Moore. Thanks for listening, and here’s to the next 500 episodes! +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + + + We released episode one of this podcast on June 11, 2012. Now, more than a decade later, we're celebrating the 500th episode of our show. In honor of this milestone, Victoria, Will, and Chad caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen.

+ +

We chatted about what they’re up to now, what they liked and learned from hosting the show, their time at thoughtbot, and more!

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry.

+ +

CHAD: And I'm your other host, Chad Pytel.

+ +

We released episode one of this podcast on June 11, 2012. Now more than a decade later, were celebrating this: the 500th episode of our show. In honor of this milestone, Victoria, Will, and I caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen.

+ +

We chatted about what they’re up to now, what they liked and learned from hosting the show and their time at thoughtbot, and more. First up: Ben Orenstein. Ben was the very first host of the show back in 2012 when he was a developer at thoughtbot. He is now the co-founder and Head of Product at Tuple, a remote pair programming tool for designers and developers. Ben, it's great to talk to you again. It's been a while since you and I talked. How have you been?

+ +

BEN: I've been decent, yeah. It's fun to be back to my roots a little bit. I told some folks that I work with that I was coming back to the pod for the 500th Episode, and they were stoked. So, it's kind of a treat to get to be on these airwaves again.

+ +

CHAD: What have you been up to since you left this show and thoughtbot?

+ +

BEN: Well, I started a company. So, I was at thoughtbot for a while; I think it was seven years. And I eventually sort of struck out to start my own thing–had a false start or two here and there. And then, I ended up starting a company called Tuple, and we still exist today, fortunately.

+ +

Tuple is a tool for doing remote pair programming. We started off on macOS and then wrote a Linux client. And we're launching a Windows client now. But it's sort of, like, screen sharing with remote control for developers who are actually writing code and want to have great, low latency remote control and who care about screen share quality and that sort of thing.

+ +

I started that about five years ago with two co-founders. Today, we are a team of 11, I think it is. And it's been going well. Our timing was really great, it turned out. We launched a little bit before COVID. So, remote work turned into a lot more of a thing, and we were already in the market. So, that helped us a ton. It was quite a wild ride there for a bit.

+ +

But things have calmed down a little lately, but it's still fun. I'm, like, really enjoying being a co-founder of a software company. It was what I've always sort of wanted to do. And it turns out it actually is pretty fun and pretty great. Although there are, of course, the ups and downs of business ownership. It is never quite as calm or relaxing as being an employee somewhere else.

+ +

CHAD: You started Tuple instigated by...full disclosure: thoughtbot's an early customer of Tuple. We're still a customer. We use it a lot.

+ +

BEN: Woo-hoo. I appreciate that. Thank you.

+ +

CHAD: If I remember right, you started and were sort of instigated to create Tuple because there was a prior product that then Slack bought, and then it started to degrade. And now, it no longer exists in the same way that it did before.

+ +

BEN: Yeah. So, there was this tool called Screenhero, which I actually started using --

+ +

CHAD: [inaudible 02:14]

+ +

BEN: Yeah, first at thoughtbot. Some other thoughtboter introduced me to it, and we would use it for pair programming. And I was like, oh, this is nice. And then yeah, Slack kind of acqui-hired it and more or less ended up shutting the product down. And so, there was this gap in the market. And I would ask my friends, I would ask thoughtboters and other developers, like, "What are you using now that Screenhero is gone?" And no one had a good answer.

+ +

And so, after a while of this thing sort of staring me in the face, I was like, we have to try to solve this need. There's clearly a hole in the market. Yeah, so we were heavily inspired by them in the early days. Hopefully, we've charted our own path now. But they were definitely...the initial seed was, you know, let's do Screenhero but try to not get bought early or something.

+ +

CHAD: [laughs] How did you or did you feel like you captured a lot of the Screenhero customers and reached them in those early days?

+ +

BEN: I think so. The pitch for it was sort of shockingly easy because Screenhero had kind of blazed this trail. Like, I would often just be like, "Oh, we're making a thing. Do you remember Screenhero?" And they'd go, "Oh yeah, I loved Screenhero". I'd be like, "Yeah, we're going to try to do that." And they'd be like, "Nice. Sign me up." So, it for sure helped a ton. I have no idea what percentage of customers we converted. And they were a pretty large success, so probably a small fraction, but it definitely, like, made the initial days much easier.

+ +

CHAD: Yeah. And then, like you said, COVID happened.

+ +

BEN: COVID happened, yeah. I think we had been around for about a year when COVID hit. So, we were getting our feet underneath us. And we were already, like, the company was already growing at a pretty good rate, and we were feeling pretty good about it. I don't think we had quite hit ramen profitable, but we were probably pretty close or, like, flirting with it.

+ +

Yeah, the business, like, I don't know, tripled or quadrupled in a matter of months. We had a few big customers that, like, just told everyone to start using Tuple. So, we had, like, thousands and thousands of new users kind of immediately. So, it was a crazy time. Everything melted, of course. We hadn't quite engineered for that much scale. We had a really rough day or so as we scrambled, but fortunately, we got things under control. And then had this, like, very nice tailwind.

+ +

Because we started the company assuming that remote work would grow. We assumed that there would be more remote developers every year. And, you know, it's probably maybe 5% of dev jobs are remote or maybe even less, but we expect to see this number creeping up. We don't think that trend will reverse. And so, COVID just, like, it just yanked it, you know, a decade in the future.

+ +

CHAD: You haven't tripled or quadrupled your team size, have you?

+ +

BEN: No. Well, I mean, I guess, I mean, we started as 3, and now we're 11, so kind of.

+ +

CHAD: [laughs] Yeah, that's true.

+ +

BEN: Expenses have not grown as fast as revenue, fortunately.

+ +

CHAD: That's good. That's basically what I was asking [laughs].

+ +

BEN: Yeah, yeah. We're still a pretty small team, actually. We have only, like, four or five full-time engineers on the team at the moment, which is kind of wild because we are now, you know, we have three platforms to support: Linux, Windows, and Mac. It's a pretty complicated app doing, like, real-time streaming of audio, webcams, desktops, caring about OS-level intricacies.

+ +

So, I think we will be hiring more people soon, although we haven't said that for a long time. We sort of have always had a bit of a hire-slow mentality to try to get the right team members and, like, feel a real pain before we hire someone into it. But we have been getting a bit more aggressive with hiring lately.

+ +

VICTORIA: Well, I really appreciate Tuple. I installed it when I first started working here at thoughtbot. And we have random pairings with everyone across the company. So, I'll randomly get to meet someone halfway across the world who's working on similar projects. And I think they really enjoy that I have a tool they like working to share what they're working on. So, I want to thank you for that.

+ +

And I'm curious about when you really started to scale during COVID, what were some of the technology architecture trade-offs you came across, and where did you land with it?

+ +

BEN: Well, we got fairly...I don't know if it was lucky, but we...for a long time, for years, even through COVID, maybe the first four years of the company, all Tuple calls were purely peer-to-peer. And there was no server that we owned intermediating things. This was, like, kind of one of the keys of, like, not having expenses. The scale of revenue was we could have lots more calls happen. And it wouldn't cost us bandwidth or server capacity.

+ +

To this day, still, for any calls with three or fewer participants, they're purely peer-to-peer. And this is nice for latency purposes because it just...we can find the most direct path to the internet between two people. It's also nice from our cost perspective because we don't need to pay to send that data. And that was hugely useful as call volume went up immensely. Didn't have to worry too much about server load and didn't have to worry too much about bandwidth costs.

+ +

CHAD: Today, is there a central service that makes the initial connection for people?

+ +

BEN: Yes, yeah, yeah. So, there is a signaling server. So, when you launch the app, you sign in, and you see, like, oh, which of my co-workers are online? So, there is actually a Rails app that handles that, actually, increasingly less the Rails app. We have now...I think it's a Go service that actually manages all those. I'm further and further from the code every year. Some of the technical questions might be a little bit beyond me, or I might have slightly out-of-date info.

+ +

But back to the architecture question for a second, we did a pretty big refactor when we decided to go from just being a Mac client to supporting other platforms, where we split out a cross-platform real-time communication engine written in C++ so that we could use that for all of the heavy lifting, all the managing of the connections, and the tricky bandwidth estimation, and all this stuff, and use that across different platforms. And so, today, you have the cross-platform engine, and then on top of that is a, like, a less specific layer for each of the operating systems that we support.

+ +

CHAD: So, you mentioned you're less and less in the code these days. So, what do you spend your time doing then?

+ +

BEN: It's a mix of things. These days, it's basically mostly --

+ +

CHAD: Just cocktails on the beach, right?

+ +

BEN: Cocktails, yes [laughs], cocktails on the beach, appearing on podcasts trying to sound important and impressive, yeah. Mostly product work. So, right before this, I just got off a call with some folks from The Browser Company. They are some of our first alpha users for our new Windows clients. So, I hopped on the call with them and, like, watched three of them install the product and inevitably run into some bugs. And, you know, chatted through those with the engineer that was working on it, prioritized some stuff, made some decisions about what's coming up next, and what we're going to ignore. So, mostly product work these days.

+ +

For the first five years of the company, I was CEO, so I was doing kind of everything: marketing, and also hiring, and also product. About two months ago, I stepped down as CEO, and one of my other co-founders, Spencer, stepped up. And so, now my focus has narrowed to be mostly just product stuff and much less on the marketing or hiring side.

+ +

VICTORIA: Yeah, you mentioned that it was a little more comfortable to be an employee than to be a founder. I don't know if you could say more about that because, certainly, a lot of engineers are smart enough and capable enough to run their own company. But what really informed your choice there, and do you regret it? [laughs]

+ +

BEN: I definitely don't regret it. thoughtbot was a close second in terms of wonderful professional experiences. But running my own thing has been the most interesting professional thing I've done by a big margin. It has also been more stressful. And, Chad, I don't know if you remember, I think, like, maybe eight years ago, you tweeted something like, if you want to sleep well at night, and, like, value that, like, peace of mind, like, don't start a company or something. I have experienced that.

+ +

CHAD: [laughs]

+ +

BEN: A lot more, yeah, like waking up in the middle of the night worrying about things. It feels a little bit like the highs are higher; the lows are lower. Being an employee somewhere, it's like, if this company fails, I know I can go get another job, right? Like, you're a developer. You're extremely employable. But as the owner of the company, if the company fails, like, a huge chunk of your net worth is gone. Like, this thing you poured your life into is gone. It's way more stressful and traumatic to have that happen, or have that threatened to be happening, or just imagine that happening.

+ +

So, overall, I have found the trade-off to be totally worth it. It's awesome to make your own decisions and chart your own path. And when it works, it can work in a way that being a salaried employee can't. So, I'm happy with those trade-offs. But I think that is a good question for people to ask themselves as they consider doing something like this is, like: is that the kind of trade-off that you want to make? Because it has significant downsides for sure.

+ +

WILL: I am a big fan of Tuple also. I love it. It [inaudible 10:08] easy, especially with remote work. You hit the jackpot with COVID and remote work, so kudos for that [laughs]. Was there anything...because I know from our previous companies, about over...hopefully a lot more of the good stuff than the bad stuff. But was there anything that you learned? Because you were at thoughtbot for seven years. Was there anything that you're like, oh my gosh, I learned that, and it's helped me till this day while I'm running my company?

+ +

BEN: Yeah, quite a bit, actually. I think it'd be hard to tease apart exactly which lessons, but I do...so I ran Upcase for thoughtbot and also FormKeep. So, I got a chance to kind of run a small division of the company, while still being a normal employee and, like, having not much of that risk. And I think that was a really wonderful opportunity for me to, like, practice the skills that I was interested in. Just, like, how do you market a thing? How do you design a product and have it be good? How do you prioritize user feedback?

+ +

There were a ton of lessons from those days that I feel like made me better at running our company when we actually took a shot at it. So, there were, like, the specific things that I learned by the work I was doing there. But then just, like, I mean, I think I am the programmer I am today because of, like, the weekly dev discussions that happened.

+ +

Like, spending so much time with Joe Ferris and, like, trying to copy as much of his brain as possible, like, really, like, imprinted on me as, like, a programmer. And also, just, like, a lot of the sort of cultural things from my time at thoughtbot of, like, you should be sharing the things you're learning. Like, writing blog posts is a great use of time. Like, doing open-source work is a great use of time.

+ +

And maybe you can't directly trace how doing, like, working in public or sharing information benefits the company. It's hard to, like, attribute it from a marketing sense. But if you sort of have faith that in the large, it's going to work out, it probably will. That feels like a thoughtbot lesson to me, and I think it has served us really well; where I recorded a weekly podcast for a long time called The Art of Product. I'm recording a new podcast called Hackers Incorporated with Adam Wathan of Tailwind fame.

+ +

And I don't ever think, like, hmm, how many new leads do we think we get per episode, and how many hours has that taken? What's the ROI? I just have this sort of reflex that I developed from thoughtbot time of, like, you should be putting stuff out there, or you should be giving back. You should help other people. And that will probably help your business and make it work in the long term.

+ +

CHAD: That's a good lesson [laughs]. One of the other things, you know, while you were a host of Giant Robots, you were the first host. I remember, you know, encouraging you to be the first host, and I think we talked about that in one of the episodes along the way. But we also transitioned the format a little bit, especially as you started to work on products here; you know, it was more about the building of those products and following along with those.

+ +

And one of the things that sort of half-jokingly defined, I think, your impact on a lot of products was pricing, experimenting with pricing, learning about pricing, increasing prices more than people were maybe comfortable doing so. How has that worked out with Tuple, pricing in particular?

+ +

BEN: It's really hard to say. It's hard to know what, like, the other path would have been through the world-. We sort of decided from, like, the early days that we wanted to have, like, a fairly premium price. Like, we wanted to be the product that was really good and was, like, a little bit annoyingly expensive, but you still paid for it because it felt worth it. And I think people could debate in both directions whether we nailed that or not.

+ +

We have had a price increase that we ended up rolling back. We went, like, a little too far one time and said, "You know what? I think we're a little bit over," and we reverted that. But I would say even today, we are still a fairly pricey product. I mean, I'm pretty happy with how the company has done. I can't prove to you that, like, if the price were half what it is, we would have, you know, better success or not.

+ +

CHAD: I think it'd be very hard to make the argument that if it was half that, you would have double the number of customers.

+ +

BEN: Yeah, that's probably not true.

+ +

CHAD: Not with the customers that you have, who are companies that will pay for products that they use as much as Tuple.

+ +

BEN: Yeah, I'm happy serving the kind of companies, and they end up being mostly tech companies that really value developer happiness. When their developers come to them and they say, "We don't want to pair over Zoom. We like this thing. It's better. It feels nicer to use," they say, "Okay," and they buy the tool for them. There are places where that's not the case. And they say, "We already have a thing that does screen sharing. You're not allowed to buy this." We don't invest a lot of time trying to sell to those people or convince them that they're wrong. And I'm pretty happy serving sort of the first group.

+ +

CHAD: So, you've mentioned that you've still been podcasting. To be honest, I didn't realize you were starting something new. Is it live now?

+ +

BEN: It is live now, yeah.

+ +

CHAD: Awesome. Where can people find that?

+ +

BEN: hackersincorporated.com. It's about the transition from developer to founder, which is kind of what we've been touching on here. Yeah, hopefully, the audience is developers who want to start something or have started something who are maybe a little bit further behind progression-wise.

+ +

And it's kind of, like, I have some lessons, and Adam has some lessons, and, you know, we don't think that we're experts. But sometimes it's useful to just hear, like, two people's story and sort of see, like, what seemingly has worked for them. So, we've been trying to share things there. And I think people will find it useful.

+ +

VICTORIA: I was going to ask you for a lesson, maybe give us a little sample about how would you advise someone who's built a product and wants to market it, and it's targeted towards developers since you mentioned that previously as well.

+ +

BEN: Yeah, in a way, the question already contains a problem. It's like, oh, I built the product; now how do I market it? It's a little bit indicative of a very common failure mode for developers, which is that. They sort of assume, okay, after you make the product, you then figure out how you're going to market it. And marketing is sort of a thing you layer on later on when you realize that just, like, throwing it on Twitter or Product Hunt didn't really work.

+ +

When we started building Tuple, I was out there marketing it already. So, I had two co-founders, so this is a luxury I had. My two co-founders were writing code, and I was out doing stuff. I was recording podcasts. I was tweeting about things. I was making videos. I was giving conference talks. And I was getting people to hear about our product well before it was done. In fact, I was even selling it. I was taking pre-orders for annual subscriptions to the app while it was still vaporware.

+ +

So, I would say, like, you basically can't start marketing too early. If you start marketing early and no one really cares, well, then you don't really have to build it probably. I would actually even go a little further and say, like, I started marketing Tuple before we had a product available. But in reality, I started marketing Tuple seven or so years before that when I started publishing things through thoughtbot.

+ +

It's like when I was traveling around giving talks about Ruby, and when I was making screencasts about Vim, and when I was running Upcase, I was, over time, building an audience. And that audience was useful for thoughtbot, and it also was useful for me so that when I left, I had something like 10,000 Twitter followers or something, a few thousand people on our mailing list.

+ +

But there were a lot of developers that already sort of knew me and trusted me to make fairly good things. And so, when I said, "Hey, I've made a new thing, and it's for you," I really benefited from those years of making useful content and trying to be useful on the internet. And in the early days, we had people sign up, and they would say, "I don't even really think I'm going to use this. But I've learned so much from you over the years that I want to support you, so I'm going to pay for a subscription."

+ +

VICTORIA: I like your answer because I think the same thing when people ask me, like, because I am an organizer for Women Who Code, and I know all these great people from showing up for years in person months over months. And so, then people will ask, "Oh, how do I recruit more women in my company?" I'm like, "Well, you got to start showing up [laughs] now and do that for a couple of years, and then maybe people will trust you," right? So, I really like that answer.

+ +

WILL: How has your relationship with Chad continued to grow since you left? Because seven years at the company is a lot. And it seems like you're still on really, really good terms, and you're still friends. And I know that doesn't happen at every company.

+ +

BEN: I mean, it was tough deciding to leave. I think, like, both of us felt pretty sad about it. That was the longest I'd ever worked anywhere, and I really enjoyed the experience. So, I think it was tough on both sides, honestly. But we haven't kept in that much touch since then. I think we've emailed a handful of times here and there. We're both sociable people, and we sort of get each other. And there's a long history there. So, I think it's just easy for us to kind of drop back into a friendly vibe is sort of how I feel about it.

+ +

CHAD: Yeah. And the way I explain it to people, you know, when you're leading a company, which Ben and I both are, you put a lot of energy into that and to the people who are on that team. If you're doing things right, there's not really hard feelings when someone leaves. But you need to put in a lot of effort to keep in touch with people outside of the company and a lot of energy. And, to be honest, I don't necessarily do as good a job with that as I would like because it's a little bit higher priority to maintain relationships with them, the people who are still at thoughtbot and who are joining.

+ +

BEN: What you're saying is I'm dead to you [laughter]. That's CEO, for you're dead to me.

+ +

CHAD: No. It's just...no hard feelings.

+ +

BEN: Totally.

+ +

CHAD: I think one of the things that has been great about the show over the years is that we haven't been afraid to change the format, which I think has been important to keeping it going. So, there is sort of; in fact, the website now is organized into seasons. And I went back and re-categorized all the episodes into seasons. And when the seasons were made up of, like, sort of the format of the show or particular hosts...when we started, it was just an interview show, and it was largely technical topics.

+ +

And then we started The Bike Shed, and the technical topics sort of moved over there. But it also went with your interests more under the product and business side. Then you started working on products at thoughtbot, so it started to go even more in that. And I think Chris joined you on the show, and that was sort of all about those topics.

+ +

BEN: Yeah, that makes sense. I think if you don't let the hosts kind of follow their interests, they're going to probably burn out on the thing. It's not fun to force yourself, I think, to record a podcast.

+ +

CHAD: Yeah. And then when you left, you know, I took over hosting and hosted by myself for a while, went back to the interview format, but then was joined by Lindsey for a little while. We experimented with a few different things: one, interviews, but then we did a whole, just under a year, where we followed along with three companies. And each month, we would have an interview episode where we talked to them, all three companies, about the same topic.

+ +

And then, we also did an episode with just Lindsey and I talking about that topic and about what we learned from the startup companies that we were following along with for the year. And now we're back to interview freeform, different guests, different topics. It seems like we're going to stick with that for a little while. But, obviously, as Will and Victoria have said, like, we'll probably change it again in some way, you know, a year, two years, three years from now.

+ +

VICTORIA: Yeah, and I'm definitely bringing my interest around DevOps and platform engineering, so you'll see more guests who have that focus in their background. And with that, sometimes my interview style is more; how do I ask a question that I can't read from your developer docs and that I might not understand the answer to? [laughs] That's kind of where I like to go with it. So yeah, I'm really excited about...it's probably one of my favorite parts of my job here at thoughtbot because I get to meet so many interesting people. And, hopefully, that's interesting to everyone else [laughs] and our guests, yeah.

+ +

BEN: Totally. Well, I dramatically underestimated how awesome it would be to meet all kinds of cool people in the industry when I started the podcast. I didn't truly connect in my head, like, wait a second, if I have a 45-minute conversation with, like, a lot of prominent, awesome people in our field, that's going to be really interesting and useful for me. So, I think, yeah, it's nice to be in the hosting seat.

+ +

VICTORIA: And it's so surprising how I'll meet someone at a conference, and I'll invite them onto the podcast. And the way it winds up is that whatever we're talking about on the show is directly relevant to what I'm working on or a problem that I have.

+ +

It's been incredible. And I really appreciate you for coming back for our 500th Episode here.

+ +

CHAD: Ben, thanks very much again for joining us, and congratulations on all the success with Tuple. And I wish you the best.

+ +

BEN: Thank you so much. Thanks for being a continuing customer. I really appreciate it.

+ +

CHAD: Next, we caught up with Chris Toomey, who had a run as co-host of the show with Ben throughout 2016.

+ +

CHRIS: Hi there. Thanks for having me.

+ +

So, we're talking with all of the past hosts. I know you joined the show, and you were on it with Ben. And then you moved over to The Bike Shed, right?

+ +

CHRIS: Yeah. So, I had co-hosted with Ben for about six months. And then I think I was transitioning off of Upcase, and so that ended sort of the Giant Robots “let's talk about business” podcast tour for me. And then, I went back to consulting for a while. And, at some point, after Derek Prior had left, I took over as the host of The Bike Shed. So, I think there was probably, like, a year and a half, two-year gap in between the various hostings.

+ +

CHAD: Are you doing any podcasting now?

+ +

CHRIS: I'm not, and I miss it. It was a lot of fun. It was, I think, an ideal medium for me. I'm not as good at writing. I tend to over-edit and overthink. But when you get me on a podcast, I just start to say what's in my head, and I tend to not hate it after the fact. So [chuckles], that combination I found to be somewhat perfect for me. But yeah, lacking that in my current day-to-day.

+ +

CHAD: Well, what's been taking up your time since you left?

+ +

CHRIS: I had decided it was time to sort of go exploring, try and maybe join a startup, that sort of thing. I was sort of called in that direction. So, just after I left thoughtbot, I did a little bit of freelancing, but that was mostly to sort of keep the lights on and start to connect with folks and see if there might be an opportunity out there.

+ +

I was able to connect with a former thoughtbot client, Sam Zimmerman, who was looking to start something as well. And so, we put our act together and formed a company called Sagewell, which was trying to build a digital financial platform for seniors, which is a whole bunch of different complicated things to try and string together. So, that was a wonderful experience. I was CTO of that organization. And I think that ran for about two and a half years. Unfortunately, Sagewell couldn't quite find the right sort of sticking point and, unfortunately, shut down a little bit earlier in this year.

+ +

But that was, I would say, the lion's share of what I have done since leaving thoughtbot, really wonderful experience, got to learn a ton about all of the different aspects of building a startup. And I think somewhat pointedly learned that, like, it's messy, but I think I do like this startup world.

+ +

So, since leaving Sagewell, I've now joined a company called August Health, which has a couple of ex-thoughtboters there as well. And August is post their Series A. They're a little bit further along in their journey. So, it was sort of a nice continuation of the startup experience, getting to see a company a little bit further on but still with lots of the good type of problems, lots of code to write, lots of product to build. So, excited to be joining them. And yeah, that's mostly what's taking up my time these days.

+ +

CHAD: So, I know at Sagewell, you made a lot of technical architecture, team decisions. It was Rails in the backend, Svelte in the frontend, if I'm not mistaken.

+ +

CHRIS: Yep, that's correct.

+ +

CHAD: You know, hindsight is always 2020. Is there anything you learned along the way, or given how things ended up, that you would do differently?

+ +

CHRIS: Sure. I was really happy with the tech stack that we were able to put together. Svelte was probably the most out there of the choices, I would say, but even that, it was sort of relegated to the frontend. And so, it was a little bit novel for folks coming into the codebase. Most folks had worked in React before but didn't know Svelte. They were able to pick it up pretty quickly.

+ +

But Inertia.js was actually the core sort of architecture of the app, sort of connected the frontend and the backend, and really allowed us to move incredibly quickly. And I was very, very happy with that decision. We even ended up building our mobile applications, both for iOS and Android. So, we had native apps in both of the stores, but the apps were basically wrappers around the Rails application with a technology similar to Turbolinks native–if folks are familiar with that so, sort of a WebView layer but with some native interactions where you want.

+ +

And so, like, we introduced a native login screen on both platforms so that we could do biometric login and that sort of thing. But at the end of the day, most of the screens in the app didn't need to be differentiated between a truly native mobile app and what like, mobile WebView would look like. So, we leaned into that.

+ +

And it was incredible just how much we were able to do with that stack and how quickly we were able to move, and also how confidently we were able to move, which was really a nice thing. Having the deep integration between the backend and the frontend really allowed a very small team to get a lot done in a short time.

+ +

CHAD: Does that code live on in any capacity?

+ +

CHRIS: No.

+ +

CHAD: Oh. How does that make you feel?

+ +

[chuckles]

+ +

CHRIS: It makes me feel very sad, I will say. That said, I mean, at the end of the day, code is in service of a business. And so, like, the code...there are, I think, probably a couple of things that we might be able to extract and share. There were some interesting...we did some weird stuff with the serializers and some, like, TypeScript type generation on the frontend that was somewhat novel.

+ +

But at the end of the day, you know, code is in service of a business, and, unfortunately, the business is not continuing on. So, the code in the abstract is...it's more, you know, the journey that we had along the way and the friends we made and whatnot. But I think, for me, sort of the learnings of I really appreciate this architecture and will absolutely bring it to any new projects that I'm building from, you know, greenfield moving forward.

+ +

VICTORIA: I'm curious what it was like to go from being a consultant to being a big player in a startup and being responsible for the business and the technology. How did that feel for you?

+ +

CHRIS: I would say somewhat natural. I think the consulting experience really lent well to trying to think about not just the technical ramifications but, you know, what's the business impact? How do we structure a backlog and communicate about what features we want to build in what order? How do we, you know, scope a minimal MVP? All those sorts of things were, I think, really useful in allowing me to sort of help shape the direction of the company and be as productive of an engineering team as we could be.

+ +

CHAD: A lot of the projects you worked on at thoughtbot were if not for startups, helping to launch new products. And then, a lot of the work you did at thoughtbot, too, was on Upcase, which was very much building a business.

+ +

CHRIS: Yes. I definitely find myself drawn in that direction, and part of like, as I mentioned, I seem to be inclined towards this startup world. And I think it's that, like, the intersection between tech and business is sort of my sweet spot. I work with a lot of developers who are really interested in getting sort of deeper into the technical layers, or Docker and Kubernetes and orchestration. And I always find myself a little bit resistant to those. I'm like, I mean, whatever. Let's just...let's get something out there so that we can get users on it. And I am so drawn to that side, you know, you need both types of developers critically.

+ +

I definitely find myself drawn to that business side a little bit more than many of the folks that I work with, and helping to bridge that gap and communicate about requirements and all those sort of things. So, definitely, the experience as a consultant really informed that and helped me have sort of a vocabulary and a comfort in those sort of conversations.

+ +

WILL: How did Upcase come about? Because I know I've talked to numerous people who have gone through Upcase. I actually went through it, and I learned a ton. So, how did that come about?

+ +

CHRIS: I think that was a dream in Ben Orenstein's eye. It started as thoughtbot Learn many, many years ago. There was a handful of workshops that had been recorded. And so, there were the video recordings of those workshops that thoughtbot used to provide in person. Ben collected those together and made them sort of an offering on the internet.

+ +

I think Chad, you, and I were on some podcast episode where you sort of talked about the pricing models over time and how that went from, like, a high dollar one-time download to, like, $99 a month to $29 a month, and now Upcase is free. And so, it sort of went on this long journey. But it was an interesting exploration of building a content business of sort of really leaning into the thoughtbot ideal of sharing as much information as possible, and took a couple of different shapes over time.

+ +

There was the weekly iterations of the video series that would come out each week, as well as the, like, longer format trails, and eventually some exercises and whatnot, but very much an organic sort of evolving thing that started as just a handful of videos and then became much more of a complete platform. I think I hit the high points there. But, Chad, does that all sound accurate to you?

+ +

CHAD: Yeah, I led the transition from our workshops to Learn, which brought everything together. And then, I stepped away as product manager, and Ben took it the next step to Upcase and really productized it into a SaaS sort of monthly recurring billing model and took it over from there. But it still exists, and a lot of the stuff there is still really good [laughs].

+ +

CHRIS: Yeah, I remain deeply proud of lots of the videos on that platform. And I'm very glad that they are still out there, and I can point folks at them.

+ +

VICTORIA: I love that idea that you said about trying to get as much content out there as possible or, like, really overcommunicate. I'm curious if that's also stayed with you as you've moved on to startups, about just trying to get that influence over, like, what you're doing and how you're promoting your work continues.

+ +

CHRIS: I will say one of the experiences that really sticks with me is I had followed thoughtbot for a while before I actually joined. So, I was reading the blog, and I was listening to the podcasts and was really informing a lot of how I thought about building software. And I was so excited when I joined thoughtbot to, like, finally see behind the curtain and see, like, okay, so, what are the insider secrets?

+ +

And I was equal parts let down...actually, not equal parts. I was a little bit let down but then also sort of invigorated to see, like, no, no, it's all out there. It's like, the blog and the open-source repos and those sort of...that really is the documentation of how thoughtbot thinks about and builds software. So, that was really foundational for me. But at the same time, I also saw sort of the complexity of it and how much effort goes into it, you know, investment time Fridays, and those sort of things.

+ +

Like, a thoughtbot blog post is not a trivial thing to put up into the world. So many different people were collaborating and working on it. And so, I've simultaneously loved the sharing, and where sharing makes sense, I've tried to do that. But I also recognize the deep cost. And I think for thoughtbot, it's always made sense because it's been such a great mechanism for getting the thoughtbot name out there and for getting clients and for hiring developers.

+ +

At startups, it becomes a really interesting trade-off of, should we be allocating time to building up sort of a brand in the name and getting ourselves, you know, getting information out there? Versus, should we be just focusing on the work at hand? And most organizations that I've worked with have bias towards certainly less sharing than thoughtbot, but just not much at all. Often, I'll see folks like, "Hey, maybe we should start a blog." And I'm like, "Okay, let's just talk about how much effort that [laughs] actually looks like." And I wonder if I'm actually overcorrected on that, having seen, you know, the high bar that thoughtbot set.

+ +

CHAD: I think it's a struggle. This is one of my [laughs] hot topics or spiels that I can go on. You know, in most other companies, that kind of thing only helps...it only helps in hiring or the people being fulfilled in the work. But at most companies, your product is not about that; that's not what your business is. So, having a more fulfilled engineering team who is easier to hire—don't get me wrong, there are advantages to that—but it doesn't also help with your sales.

+ +

CHRIS: Yes.

+ +

CHAD: And at thoughtbot, our business is totally aligned with the people and what we do as designers and developers. And so, when we improve one, we improve the other, and that's why we can make it work. That is marketing for the product that we actually sell, and that's not the case at a SaaS software company.

+ +

CHRIS: Yes, yeah, definitely. That resonates strongly. I will say, though, on the hiring side, hiring at thoughtbot was always...there was...I won't say a cheat code, but just if someone were to come into the hiring process and they're like, "Oh yeah, I've read the blog. I listen to the podcast," this and that, immediately, you were able to skip so much further into the conversation and be like, "Okay, what do you agree with? What do you disagree with? Like, let's talk." But there's so much.

+ +

Because thoughtbot put so much out there, it was easy to say, like, "Hey, this is who we are. Do you like that? Is that your vibe?" Whereas most engineering organizations don't have that. And so, you have to try and, like, build that in the context of, you know, a couple of hour conversations in an interview, and it's just so much harder to do. So, again, I've leaned in the direction of not going anywhere near thoughtbot's level of sharing. But the downside when you are hiring, you're like, oh, this is going to be trickier.

+ +

CHAD: Yeah. One of the moments that stands out in my mind, and maybe I've told this story before on the podcast, but I'll tell it again. When we opened the New York studio, it was really fast growing and was doing a lot of hiring. And one of the people who had just joined the company a couple of weeks before was doing an interview and rejected the person was able to write an articulate reason why. But it all boiled down to this person is, you know, not a fit for thoughtbot.

+ +

Based on what they were able to describe, I felt very confident with the ability or with the fact that they were able to make that call, even though they had been here only a couple of weeks, because they joined knowing who we were, and what we stand for, and what our culture and our values are, and the way that we do things, and all that kind of thing. And so, yeah, that's definitely a huge benefit to us.

+ +

VICTORIA: I've certainly enjoyed that as well, as someone who hires developers here and also in meeting new companies and organizations when they already know thoughtbot. That's really nice to have that reputation there, coming from my background—some really more scrappier startup kind of consulting agencies.

+ +

But, you know, I wanted to talk a little bit more about your podcasting experience while you're here. So, I know you were on both The Bike Shed and Giant Robots. Which is the better podcast? [laughter] So, what's your...do you have, like, a favorite episode or favorite moment, or maybe, like, a little anecdote you can share from hosting?

+ +

CHRIS: Well, I guess there's, like, three different eras for me in the podcasting. So, there's Giant Robots with Ben talking more about business stuff, and I think that was really useful. I think it was more of a forcing function on me because I sort of...Both Ben and I were coming on; we were giving honest, transparent summaries of our, like, MRR and stats and how things were growing, and acted as sort of an accountability backstop, which was super useful but also just kind of nerve-wracking.

+ +

Then, when I joined the Bike Shed, the interviewing sequence that I did each week was just a new person that I was chatting with. And I sort of had to ramp them up on, hey, here's a quick summary on how to think about podcasting. Don't worry, it'll be great. Everybody have fun. But I was finding each of the guests. I was sort of finding a topic to talk about with them. So, that ended up being a lot more work.

+ +

And then, the last three years chatting with Steph that was by far my favorite. There was just such a natural back-and-forth. It really was just capturing the conversations of two developers at thoughtbot and the questions we would ask each other as we hit something complicated in a piece of code or, "Oh, I saw this, you know, article about a new open-source repository. What do you think about that?" It was so much easier, so much more natural, and, frankly, a lot of fun to do that.

+ +

And, two, I actually do have an answer to the favorite podcast episode, which is the first episode that Steph was ever on. It was before she actually joined as a co-host. But it was called “What I Believe About Software.” And it was just this really great, deep conversation about how we think about software. And a lot of it is very much, like, thoughtbot ideals, I would say. But yeah, Steph came in and just brought the heat in that first episode, and I remember just how enjoyable that experience was. And I was like, all right, let's see if I can get her to hang out a little bit more, and, thankfully, she was happy to join.

+ +

WILL: What was your favorite position, I guess you can call it? Because you say you like the mixture of business and, you know, development. So, you've been in leadership as development director, CTO. You've been a web developer. You've been over content, like, with Upcase. What was your favorite position [inaudible 16:43] you were doing, and why was it your favorite?

+ +

CHRIS: The development director role feels like sort of a cheating answer, but I think that would be my answer because it contained a handful of things within it. Like, as development director, I was still working on client projects three days a week. And then, one day a week was sort of allocated to the manager-type tasks, or having one-on-ones with my team sort of helping to think about strategy and whatnot. And then, ideally, still getting some amount of investment time, although the relative amounts of those always flexed a little bit. Because that one sort of encompassed different facets, I think that's going to be my answer.

+ +

And I think, like, some of what drew me to consulting in the first place and kept me in that line of work for seven years was the variety, you know, different clients, as well as, even within thoughtbot, different modes of working in podcasts or video. Or there was a bootcamp that I taught, a session of Metis, which that was a whole other experience. And so, getting that variety was really interesting.

+ +

And I think as sort of a tricky answer to your question, the development director role as a singular thing contained a multitude, and so I think that was the one that would stand out to me. It's also the most, you know, the one that I ended on, so [laughs] it might just be recency bias, but yeah.

+ +

VICTORIA: Oh, I love that. Is there anything else that you would like to promote on the podcast today?

+ +

CHRIS: No, although as you ask the question, I feel like I should, I don't know, make some things to promote, get back into some, I don't know, content generation or something like that. But for now, no. I'm, you know, diving into the startup life, and it's a wonderful and engrossing way to do work, but it does definitely take up a lot of my headspace. So, it's an interesting trade-off.

+ +

But right now, I don't know; if folks are online and they want to say hi, most of my contact information is readily available. So, I would love to say hi to folks, anyone that listened in the past or, you know, has any thoughts in the now. Would love to connect with folks. But otherwise, yeah, thank you so much for having me on.

+ +

CHAD: In 2017, I took over from Ben as solo host of the show but was joined by Lindsey Christainson as cohost in 2019. After some time away from thoughtbot, Lindsey is back with us and we sat down to catch up with her.

+ +

VICTORIA: Why don't you tell me about your current role with thoughtbot?

+ +

LINDSEY: I am currently supporting marketing and business development at thoughtbot, as well as working as a marketing consultant for thoughtbot clients.

+ +

VICTORIA: Great. And I understand that you had worked with thoughtbot many years ago, and that's when you also came on as a co-host of Giant Robots. Is that right?

+ +

LINDSEY: Yeah, a couple of years ago. I left thoughtbot in spring of 2021. And I forget how long my stint was as a co-host of Giant Robots, but over a year, maybe a year and a half, two years?

+ +

CHAD: Yeah, I think that's right. I think you started in 2019.

+ +

LINDSEY: Yeah. Yeah, that sounds right. And Chad and I were co-hosts, I think, similar to the setup today in which sometimes we hosted together, and sometimes we were conducting interviews separately.

+ +

CHAD: And then we sort of introduced a second season, where we followed along with a batch of companies over the course of the entire season. And that was fun, and we learned a lot. And it was nice to have consistent guests.

+ +

LINDSEY: Yeah, that was a lot of fun. I really liked that format. I don't know; they almost were, like, more than guests at that point. They were just like other co-hosts [laughs] that we could rely on week in, week out to check in with them as they're working on early-stage companies. So, every time we checked in with them, they usually had some new, exciting developments.

+ +

WILL: I really like that idea. How did y'all come up with that?

+ +

CHAD: I'm not sure. I think a few years before I had taken over hosting of the show, and I forget...my memory maybe is that I went to Lindsey and said, "You know, let's do something different." But I'm not sure. Does that match your memory, Lindsey?

+ +

LINDSEY: Yeah, I think there were two main drivers; one was I think you were feeling like you were having similar conversations in the interviews every time. Like, you couldn't get to a certain depth because every time you were interviewing someone, you were doing, like, the, "Well, tell me your founding story." And, you know, how did you raise funding? It kind of got a little bit repetitive.

+ +

And then, on the side, the few we had done together, I think we both really enjoyed. So, we were thinking, like, what's the format in which the two of us could co-host together more regularly? Because I'm a pleasure to talk to [laughter]. I think you were like, I need to talk to Lindsey more. [inaudible 3:13]

+ +

VICTORIA: What is your hosting style? How would you describe your approach to hosting a podcast?

+ +

LINDSEY: I mean, obviously, it's a podcast about products and business. I think as a marketer, I am, you know, drawn a lot to the marketing side, so tending to ask questions around go-to-market audience, users. That's always just, like, a particular interest of mine. But then also, like, the feelings. I love asking about the feelings of things, you know, how did it feel when you started? How did it feel when you made this tough decision? So, that's another thing I think I noticed in my interviews is asking about some of the emotions behind business decisions.

+ +

VICTORIA: And I like hearing about how people felt at the time and then how they felt afterwards [laughs]. And, like, how people around them supported each other and that type of thing. That's really fun.

+ +

I'm curious, too, from your marketing background and having to do with podcasts like; some founders, I think, get the advice to just start a podcast to start building a community. But I'm curious on your thoughts about, like, how does podcasting really play into, like, business and marketing development for products?

+ +

LINDSEY: Oh yeah. It's become definitely, like, a standard channel in B2B these days. I feel like that it's pretty typical for a company to have a podcast as one way that they engage their audience and their users. In marketing, you're really vying for people's attention, and people's attention span is getting shorter and shorter. So, like, if you have an ad or a blog, you're getting, like, seconds, maybe minutes of someone's attention. And whereas something like a podcast offers a unique channel to have someone's undivided attention for, you know, 30 minutes, an hour, and if you're lucky, you know, checking back in week over week. So, it became a really popular method.

+ +

That said, I think you're probably also seeing the market get saturated [laughs] with podcasts now, so some diminishing returns. And, you know, as always, kind of looking for, you know, what's the next way? What's the next thing that people are interested in in ways to capture their attention?

+ +

CHAD: What is the next thing?

+ +

LINDSEY: I don't know, back to micro-content? TikTok videos --

+ +

CHAD: Yeah, I was going to say TikTok, yeah.

+ +

LINDSEY: Yeah, you know, 10-30 seconds, what can you communicate?

+ +

VICTORIA: I see people live streaming on Twitch a lot for coding and developer products.

+ +

LINDSEY: Yeah, I think we've seen some of that, too. We've been experimenting more at thoughtbot with live streaming as well. It's another interesting mechanism. But yeah, I don't know, it's interesting. It's another form of, like, community and how people engage with their communities. So, it's always evolving. It's always evolving, and sometimes it's not. Sometimes, people just do want to get in a room together, too, which is always interesting.

+ +

WILL: What has been, in your experience, the good the bad? Like, how do you feel about the way that it has shifted? Because I think you started in, like, 2000, like, kind of earlier 2000, 2005, something around there. And it was totally different than now like you're saying. Because I feel like, you know, Channel 5 30-second ad, you know, with some of the marketing depending on what you're doing, to now to where you're, like, you're paying influencers to advertise your product, or you're doing an ad. Or it's more social media-driven and tech-driven. What has been your opinion and feelings on the way that it has grown and evolved?

+ +

LINDSEY: Marketing, in general, yeah, I graduated college in 2005 and started my marketing career. And yeah, you could, like, actually get people to click on banner ads back then, which was pretty [inaudible 07:14] [laughs].

+ +

WILL: I forgot about banner ads [laughs].

+ +

LINDSEY: I don't know, yeah. I don't know. In order for myself to not just get too frustrated, I think I've got to, like, view it as a game kind of. What new things are we going to try? You know, what do we see work? But it can really depend. And I've always been in B2B side of things. And consumer, I'm sure, has its own kind of evolution around how people engage and how they consume content and byproducts. But in B2B, you know, it can really depend on industry too.

+ +

You know, I'm working with a client right now in the senior living space, and they're really big in in-person conferences. So, that's how people consume, get a lot of their information and, make connections, and learn about new products. So, it's been interesting to work in an industry that what might be considered, like, a little bit more old-school channels are still effective. And then just thinking about how you weave in the new channels with the existing ones without ignoring them. They might get information in conferences, but they're still a modern human who will then, you know, search online to learn more, for example.

+ +

VICTORIA: It reminds me of a phrase I like to say, which is that, like, technology never dies; you just have more of it. There's just more different options and more different ways to do things. And some people are always, you know, sometimes you have to be flexible and do everything.

+ +

CHAD: So, tell us more about what you did in between...after you left thoughtbot, what did you do?

+ +

LINDSEY: I was heading up B2B marketing for a company called Flywire, which is headquartered in Boston but is a global company now. And they were just kind of starting their B2B business unit, which, as I mentioned, B2B is my personal specialty. I had been connected to their CMO through the Boston startup community. And yeah, I was helping them kind of launch their go-to-market for B2B. The industries they were in before...they got their start in higher education and then expanded in healthcare and found a niche in luxury travel, and then we were figuring out the B2B piece. But yeah, I was there for about a year and a half.

+ +

They actually went public the second week I was there, which was an interesting [laughs] experience. I knew they were, like, on that journey, but it was kind of funny to be there the second week, and people were, like, "Congrats." And I was like, "Well, I definitely didn't have anything to do with it because I just finished my onboarding, but thank you," [laughs].

+ +

CHAD: One of the things that really impressed me when you joined thoughtbot was the way in which you learned about who we were and really internalized that in a way where you were then able to pretty meaningfully understand our market, our positioning in the market, and come up with new strategies for us. I assume that's something you're good at in general [laughs]. How do you approach it? How did you approach it when you joined Flywire, for example? And how was it the same or different than how you approached thoughtbot?

+ +

LINDSEY: Ooh, yeah, that's a good question. And I appreciate that comment because it's difficult. But I think, yeah, with any new organization that I'm joining, you know, I think starting out with your kind of mini-listening tour of your key stakeholders across, you know, the different departmental focuses to get a sense of, what are the challenges? What are the opportunities? It's actually like, you know, it's the SWOT analysis, kind of trying to fill in your own mind map of a SWOT analysis of where the company is. What are the major hurdles you're facing? Where are people trying to go? What have they tried that's worked? What have they tried that's failed?

+ +

But then, like, I think for the culture component, I think a part of that maybe is, like, feel, and maybe something that I do have a knack for. Again, maybe this is, like, you know, emotional intelligence quotient, where it's like, you know, but it's the company, you know, who is this company? What is important to them? How do they work and go about things?

+ +

I know thoughtbot is certainly very unique, I think, in that arena in terms of being, like, a really value-driven company, and one where especially, like, marketing and business work is, like, distributed across teams in a really interesting way. You know, I'm sure the fact that it fascinated me and was something I could get passionate and get behind was something that also helped me understand it quickly.

+ +

CHAD: I was excited that...or it was sort of a coincidence because I had reached out to you and without realizing that you had left Flywire. And Kelly, who had been doing a combined sales and marketing role, was going on parental leave. And so, it was fortuitous [laughs] that you were able to come back and help us and provide coverage, like, Kelly was out.

+ +

LINDSEY: Yeah, it definitely felt like stars aligned moment, which, you know, I'm pretty woo-woo, so I believe in [laughter]...I believe in that kind of thing. You know, yeah, it was wild. It really did feel like your email came out of nowhere. And, you know, I mentioned it, obviously, to my partner and my friends. And they were like, "Oh, he definitely knows, like, that you left your last company." And I'm like, "I actually don't think he does [laughter]. I actually don't think he does." Yeah, and then we started chatting about me coming back to help. And it was great. thoughtbot makes it hard to work anywhere else [laughs]. So, I was happy to come back. I missed the team.

+ +

CHAD: And one of the exciting things, and you've mentioned it, is you're not just doing marketing for thoughtbot now. We have started to offer your services to our clients.

+ +

LINDSEY: Yeah, I'm super excited about this. And it's something I'd started thinking about. I had decided to take some time off between Flywire and my next thing and had started thinking about doing marketing, consulting. And as I'm doing that, I'm thinking a lot about how thoughtbot does consulting and, you know, wanting to emulate something like that.

+ +

So, I started back up at thoughtbot. That wasn't part of the plan. I was just going to, you know, fill in for Kelly and help with marketing things. But then, you know, a good opportunity arose to work on a client, and I was really excited. When, you know, Chad, you and I chatted through it, we came to the conclusion that this was something worth exploring under the, you know, thoughtbot umbrella. And it's been a really great experience so far. And we now have brought on another client now. And if you're listening and need early-stage B2B marketing support, reach out to lindsey@thoughtbot.com.

+ +

CHAD: Definitely. And Lindsey is pretty good, so you're going to like it [laughs].

+ +

LINDSEY: Yeah, you're going to like the way you look.

+ +

WILL: Yeah, definitely. Because I can even feel your presence here, you know, coming back. Because even like, you know, the market where it's at now and some of the suggestions that, you know, you've been helping us. For example, like, I do a lot of React Native, and you're like, "Hey, you know, blog posts have done a lot of traction, you know, let's get some more blog posts out in the market to help with the traffic and everything."

+ +

So, the question I have with that is, like, thank you for even suggesting that because it's, like, those little things that you don't even think about. It's like, oh yeah, blog posts, that's an easy transition to help the market, clients, things like that. But with the market the way it is, what has been your experience working during this time with the market? I don't know if you want to call it struggling, but whatever you want to call it that, it's doing [laughs].

+ +

LINDSEY: Yeah, I mean, the economy is difficult now. We also went through a really tough spot when I was here last time. During COVID, you know, we faced a major company challenge. And, I mean, I'll let Chad speak to it, but I would imagine it's probably one of the bigger, like, economic inflection points that you faced. Would you say that?

+ +

CHAD: Yeah, definitely. The thing about it that made it worse was how quickly it happened. You know, it was something that you didn't see coming, and then, you know, about 40% of our business went away in a single month. That's the kind of thing that was a real shock to the system.

+ +

I think the thing that made it difficult, too, was then the aspects of COVID, where we were no longer able to go into our studios. We were all working remotely. We were isolated from each other. And so, that made executing on what needed to be done in order to make the company survive additionally challenging.

+ +

LINDSEY: Yeah, so I think, like, going through that experience, also, and seeing how the team and the leadership team rallied together to get through it. And then, you know, ultimately, I think 2021 and 2022 have, like, really good years. That was a really positive experience. And something I'll definitely take with me for a while is just, like, keeping a cool head and just knowing you have, like, really smart, talented folks with you working on it and that you can get through it.

+ +

And just, like, doing some, I mean, we relied on what we did best, which was, like, design thinking, using design exercise to think about, like, how we might re-organize the company, or what other services we might try launching, or how might we re-package, you know, larger services into smaller more palatable services when people have, like, kind of tighter purse strings. So, that was, like, a great educational experience, and I think something we just continue to do now: be open to change, be open to changing how we package services, what clients we go after, and coming at it with, like, an agile, experimental mindset and try to find out what works.

+ +

VICTORIA: I really appreciate that. And it aligns now with the new service we've developed around you and the marketing that you provide. And I'm curious because I've had founders come up to me who say they need help with marketing or they need to, like, figure out their marketing plans. So, say you've met a founder who has this question, like, what questions do you ask them to kind of narrow down what it is they really need and really want to get out of a marketing plan?

+ +

LINDSEY: I've been thinking about this a lot recently. And, like, obviously, I see other marketing leaders in the market. Marketers like to talk about what they do on LinkedIn [laughs], so I get to...I read a lot about different people's approaches to this. And some people kind of go in and are like, okay, this is what you need. This is how we're going to do it, and they start executing on it.

+ +

And I really do take a very collaborative approach with founders. I think they're, especially in early stage, they're your most important asset in a way, and a lot of their intuition around the market and the business, you know, it's gotten them to where they're at. And so, I think starting from the point of, like, taking what they view as priorities or challenges, and then helping them better explore them or understand them with my own marketing experience and expertise, to narrow in on work that's going to be valuable for them, is kind of my starting point with early-stage companies.

+ +

Again, a little bit of that, like, listening tour kind of attitude of, like, what do you think is important? And there's probably data points behind that. And then helping you as a company frame that into, you know, what's going to be the most valuable? Like, is it an awareness campaign, or a lead-generating campaign, or a content strategy?

+ +

Do we actually need to take a look at the data you have and spend a little bit of effort cleaning that up so that we understand what we're working with better? Is it sales enablement? You know, do you have existing salespeople, but maybe they're struggling or don't have unified tools and messaging that they're using? That's how I kind of first approach it with the founder, very much kind of in lockstep.

+ +

VICTORIA: I appreciate that little preview of what your services would be like. And I always really appreciate when you help me with my marketing plans around our Mission Control team and platform engineering and how to really refine our message and make sure it reaches the right people.

+ +

LINDSEY: Yeah, I think another thing I used at thoughtbot in the previous time that I've taken with me to Flywire and now with clients is, like, the idea of, like, mini-briefs and working on them with the key stakeholder, whether that's you the head of, you know, a business unit or a founder, which is, like, let's just take the, however long, 30 minutes to talk about, who's the audience? What's our goal? You know, what are the elements that might help us achieve that goal? What are some of the metrics that we might use to measure whether or not we were successful in reaching that goal?

+ +

And it sounds really basic, but a lot of people can skip it. And I think then there's confusion around who you are targeting, or people have different ideas in mind of, like, what you are actually trying to achieve.

+ +

VICTORIA: I like that. And to pivot a little bit, I wonder if you have any thoughts on our podcast here at Giant Robots. What do you think the benefit of it is to thoughtbot, actually?

+ +

LINDSEY: I think it's been a brand builder and a way to, again, like, another channel to engage with our audience. It's been so long-standing now, you know. I talked about how most companies have a podcast now. But this is what? The 500th Episode, right? Over years and years, which is really impressive that it's been going that long. So, it's a way to bring the brand to life.

+ +

I think one of my first insights coming into the thoughtbot team is, you know, as a consulting organization, when I interviewed clients about what they loved about thoughtbot, I thought they were going to say that they ended up with amazing products. And they did. They did say that. They said they ended up with amazing products. But I said, "You know, what was the biggest benefit, or what stood out to you the most?" And they all said it was the people, you know, they loved the people. They loved learning from thoughtboters. They were, like, you know, teachers and mentors, and so smart, but also, like, very kind and helpful.

+ +

So, when you think about it like that, podcasts or videos and ways you're able to, like, better see and hear and feel the person on the other side is a really great way of, you know, continuing to make that connection with folks.

+ +

VICTORIA: I love that answer. I wish we had little heart emojis we could share, like in Google Meets with Zencastr. So, what do you think...Maybe this is a question for everyone on here, too, that we're asking is, like, where do you think we should go with the podcast? What should we change? What should we think about for future episodes?

+ +

LINDSEY: I think you should ask the listeners if possible. We tried, in the past, surveying. And it's hard because you don't have, like, necessarily an email list of listeners. But there does tend to be some overlap of, like, our newsletter subscribers with podcast listeners. So yeah, I'd go straight to the audience and just learn more about...ask them what they care about and what they want to learn. Because at the end of the day, it's really for them, providing value for them and something they want to come back to listen to week after week.

+ +

CHAD: Oh, when we've done the surveys in the past, we've had very few people [laughs] respond. So, you can always email us at hosts@giantrobots.fm if you have feedback on the show, questions for people, questions for the hosts, or opinions on, you know, who would make a great guest or a direction we should take the show. All that is super valuable. And we definitely would take it to heart.

+ +

VICTORIA: Yes, please send me your feedback. I will read your emails and incorporate it into the show. So, it'd be great. I wonder, Lindsey, do you have any questions for us?

+ +

LINDSEY: How do y'all like hosting the podcast? [laughs] How's it going?

+ +

WILL: I feel like I'm starting to find my style and the way that it works best for me, so that's exciting. I do want to engage more with the listener. So, that's one thing that I'm trying to brainstorm on what's the best way to do that. Also, you know, inviting just different types of guests, trying to think through what's some different type, a different angle that we can invite for the podcast? But as far as how do I like doing the podcast, I really enjoy it. It's pushed me out of my comfort zone. But it was a good thing for me. So, I'm really enjoying it.

+ +

LINDSEY: How long have you been doing it, Will?

+ +

WILL: A little over a year. So, I think I started after I went on parental leave with my youngest child. And then when I came back, I took a couple of weeks, and then I started. So yeah, about a year, a little over a year.

+ +

LINDSEY: That's fun. What's your favorite part about doing it?

+ +

WILL: I love talking to the guests. And I love learning, like, people's stories. And so, that has been the most exciting thing for me, like, because especially with the founders, like, it's not easy to be a founder. But people they go all out, and they make a difference. And even through the heartache, and the pain, and just all different levels, but they're willing to endure it because they believe in their product. They believe it's going to make a difference. So, I think the stories, the stories, and the people, meeting new people, and hearing their stories is what I love.

+ +

VICTORIA: And I'm the same as Will. I've been on the show for about a year now. And the first episode I recorded with Chad, I think afterwards, he said, "Oh, you didn't ask any questions [laughs]. Like, you were too quiet." But then I think I got a hang of it. And now I really like making people feel comfortable and opening up about their story and hearing, yeah, like the emotions and what it really felt like to go through that. Because, you know, if it's interesting for me to hear that, then I think that our audience will also appreciate it and to feel like you're not alone, right? To build that community and hear those same stories and people going through similar things.

+ +

Yeah, some of the guests that we've had on have just been really incredible. And they are people who I admire in the industry, and to have them on the show and to be a part of it has been really special.

+ +

LINDSEY: Yeah, that's cool. That reminds me another kind of underlying thing I love about the podcast and the interviewing. It's also low-key, like, market research [laughs], which is interesting, like, better understanding the types of people we provide services to and their kind of drivers and challenges. There's, like, an interesting element there. And yeah, at the end of the day, you get really interested and into it, and you're just, like, having a conversation with them, probably makes for the best kind of episode.

+ +

VICTORIA: Right. And then afterwards, you have to, like, pace around the room to, like, decompress [laughs] because you're operating at, like, such a level, at least, that happens to me; I don't know about anybody else.

+ +

LINDSEY: No, totally. I would also...if we had, like, an episode scheduled and then it got, like, rescheduled at the last second, I would find I had all this, like, pent-up energy that my body was, like, preparing me to, like, go into the interview.

+ +

VICTORIA: Yeah, sometimes I have to get hyped. Like, you got to do some movement right before because you got to get into the zone. But I'm curious, Chad, this is, you know, you've been a host for a number of years now, too. Like, how do you feel about the podcast? Do you still like hosting it?

+ +

CHAD: No [laughs]. I'm kidding. I have taken a little bit of a break recently from the ongoing continuous hosting because I was really busy. And it was hard to create the time and dedicate the time to it. But I really like hosting the show. I love talking to different people and learning about their stories. I also really like the episodes where it's able to be more of a conversation with people, and I get a lot of enjoyment out of that.

+ +

LINDSEY: We've seen, also, some trends in, like, the episodes where Chad will talk about, like, the business of thoughtbot perform well, too. Because I know there's, like, a lot of folks, who listen who also own agencies or consultancies and always appreciate Chad's transparency around how we run thoughtbot.

+ +

VICTORIA: That's interesting. And yeah, I think one of the ways that we've been experimenting with getting the episodes to be more conversational is to have more than one host in the episode. So, Chad or Lindsey, if you're ever wanting to rejoin an episode or invite a founder on and be one of the co-hosts, you're always welcome.

+ +

LINDSEY: I'm always down. I love talking. That actually...that does remind me we were thinking...we've been doing live streams that cover thoughtbot's new startup incubator. So, we have the second session currently in progress. But repurposing some of those live streams into, like, mini–Giant Robots episodes. So, that may happen soon. We may do a little bit of that and then give some insight into what it's like week in, week out for founders going through the startup incubator. It's super, super interesting if you're a startup nerd like me.

+ +

VICTORIA: That would be great, yeah. We did an episode with Agnes for the first incubator round, and I think that was really interesting. And something we've been experimenting with a little bit is having that diverse group of founders. So, there's founders from companies who the company has managed to survive and excel, and they've been around for ten years or so. Then there's other people who are just starting out. And, like, hearing those stories, too, and, like, the things they're thinking about and what challenges they're facing has been super interesting. Anything else you'd like to promote Lindsey?

+ +

LINDSEY: Hire me for all your marketing consulting needs.

+ +

CHAD: It was great to catch up with everyone in celebration of our 500th episode. Thank you to Ben, Chris, and Lindsey. But most of all, that you to you. We make the show, but you make the show possible.

+ +

You can subscribe to the show and find notes, along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm.
+This podcast is brought to you by thoughtbot, and produced and edited by Mandy Moore. Thanks for listening, and here’s to the next 500 episodes!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + We released episode one of this podcast on June 11, 2012. Now, more than a decade later, we're celebrating the 500th episode of our show. In honor of this milestone, Victoria, Will, and Chad caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen.

+ +

We chatted about what they’re up to now, what they liked and learned from hosting the show, their time at thoughtbot, and more!

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry.

+ +

CHAD: And I'm your other host, Chad Pytel.

+ +

We released episode one of this podcast on June 11, 2012. Now more than a decade later, were celebrating this: the 500th episode of our show. In honor of this milestone, Victoria, Will, and I caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen.

+ +

We chatted about what they’re up to now, what they liked and learned from hosting the show and their time at thoughtbot, and more. First up: Ben Orenstein. Ben was the very first host of the show back in 2012 when he was a developer at thoughtbot. He is now the co-founder and Head of Product at Tuple, a remote pair programming tool for designers and developers. Ben, it's great to talk to you again. It's been a while since you and I talked. How have you been?

+ +

BEN: I've been decent, yeah. It's fun to be back to my roots a little bit. I told some folks that I work with that I was coming back to the pod for the 500th Episode, and they were stoked. So, it's kind of a treat to get to be on these airwaves again.

+ +

CHAD: What have you been up to since you left this show and thoughtbot?

+ +

BEN: Well, I started a company. So, I was at thoughtbot for a while; I think it was seven years. And I eventually sort of struck out to start my own thing–had a false start or two here and there. And then, I ended up starting a company called Tuple, and we still exist today, fortunately.

+ +

Tuple is a tool for doing remote pair programming. We started off on macOS and then wrote a Linux client. And we're launching a Windows client now. But it's sort of, like, screen sharing with remote control for developers who are actually writing code and want to have great, low latency remote control and who care about screen share quality and that sort of thing.

+ +

I started that about five years ago with two co-founders. Today, we are a team of 11, I think it is. And it's been going well. Our timing was really great, it turned out. We launched a little bit before COVID. So, remote work turned into a lot more of a thing, and we were already in the market. So, that helped us a ton. It was quite a wild ride there for a bit.

+ +

But things have calmed down a little lately, but it's still fun. I'm, like, really enjoying being a co-founder of a software company. It was what I've always sort of wanted to do. And it turns out it actually is pretty fun and pretty great. Although there are, of course, the ups and downs of business ownership. It is never quite as calm or relaxing as being an employee somewhere else.

+ +

CHAD: You started Tuple instigated by...full disclosure: thoughtbot's an early customer of Tuple. We're still a customer. We use it a lot.

+ +

BEN: Woo-hoo. I appreciate that. Thank you.

+ +

CHAD: If I remember right, you started and were sort of instigated to create Tuple because there was a prior product that then Slack bought, and then it started to degrade. And now, it no longer exists in the same way that it did before.

+ +

BEN: Yeah. So, there was this tool called Screenhero, which I actually started using --

+ +

CHAD: [inaudible 02:14]

+ +

BEN: Yeah, first at thoughtbot. Some other thoughtboter introduced me to it, and we would use it for pair programming. And I was like, oh, this is nice. And then yeah, Slack kind of acqui-hired it and more or less ended up shutting the product down. And so, there was this gap in the market. And I would ask my friends, I would ask thoughtboters and other developers, like, "What are you using now that Screenhero is gone?" And no one had a good answer.

+ +

And so, after a while of this thing sort of staring me in the face, I was like, we have to try to solve this need. There's clearly a hole in the market. Yeah, so we were heavily inspired by them in the early days. Hopefully, we've charted our own path now. But they were definitely...the initial seed was, you know, let's do Screenhero but try to not get bought early or something.

+ +

CHAD: [laughs] How did you or did you feel like you captured a lot of the Screenhero customers and reached them in those early days?

+ +

BEN: I think so. The pitch for it was sort of shockingly easy because Screenhero had kind of blazed this trail. Like, I would often just be like, "Oh, we're making a thing. Do you remember Screenhero?" And they'd go, "Oh yeah, I loved Screenhero". I'd be like, "Yeah, we're going to try to do that." And they'd be like, "Nice. Sign me up." So, it for sure helped a ton. I have no idea what percentage of customers we converted. And they were a pretty large success, so probably a small fraction, but it definitely, like, made the initial days much easier.

+ +

CHAD: Yeah. And then, like you said, COVID happened.

+ +

BEN: COVID happened, yeah. I think we had been around for about a year when COVID hit. So, we were getting our feet underneath us. And we were already, like, the company was already growing at a pretty good rate, and we were feeling pretty good about it. I don't think we had quite hit ramen profitable, but we were probably pretty close or, like, flirting with it.

+ +

Yeah, the business, like, I don't know, tripled or quadrupled in a matter of months. We had a few big customers that, like, just told everyone to start using Tuple. So, we had, like, thousands and thousands of new users kind of immediately. So, it was a crazy time. Everything melted, of course. We hadn't quite engineered for that much scale. We had a really rough day or so as we scrambled, but fortunately, we got things under control. And then had this, like, very nice tailwind.

+ +

Because we started the company assuming that remote work would grow. We assumed that there would be more remote developers every year. And, you know, it's probably maybe 5% of dev jobs are remote or maybe even less, but we expect to see this number creeping up. We don't think that trend will reverse. And so, COVID just, like, it just yanked it, you know, a decade in the future.

+ +

CHAD: You haven't tripled or quadrupled your team size, have you?

+ +

BEN: No. Well, I mean, I guess, I mean, we started as 3, and now we're 11, so kind of.

+ +

CHAD: [laughs] Yeah, that's true.

+ +

BEN: Expenses have not grown as fast as revenue, fortunately.

+ +

CHAD: That's good. That's basically what I was asking [laughs].

+ +

BEN: Yeah, yeah. We're still a pretty small team, actually. We have only, like, four or five full-time engineers on the team at the moment, which is kind of wild because we are now, you know, we have three platforms to support: Linux, Windows, and Mac. It's a pretty complicated app doing, like, real-time streaming of audio, webcams, desktops, caring about OS-level intricacies.

+ +

So, I think we will be hiring more people soon, although we haven't said that for a long time. We sort of have always had a bit of a hire-slow mentality to try to get the right team members and, like, feel a real pain before we hire someone into it. But we have been getting a bit more aggressive with hiring lately.

+ +

VICTORIA: Well, I really appreciate Tuple. I installed it when I first started working here at thoughtbot. And we have random pairings with everyone across the company. So, I'll randomly get to meet someone halfway across the world who's working on similar projects. And I think they really enjoy that I have a tool they like working to share what they're working on. So, I want to thank you for that.

+ +

And I'm curious about when you really started to scale during COVID, what were some of the technology architecture trade-offs you came across, and where did you land with it?

+ +

BEN: Well, we got fairly...I don't know if it was lucky, but we...for a long time, for years, even through COVID, maybe the first four years of the company, all Tuple calls were purely peer-to-peer. And there was no server that we owned intermediating things. This was, like, kind of one of the keys of, like, not having expenses. The scale of revenue was we could have lots more calls happen. And it wouldn't cost us bandwidth or server capacity.

+ +

To this day, still, for any calls with three or fewer participants, they're purely peer-to-peer. And this is nice for latency purposes because it just...we can find the most direct path to the internet between two people. It's also nice from our cost perspective because we don't need to pay to send that data. And that was hugely useful as call volume went up immensely. Didn't have to worry too much about server load and didn't have to worry too much about bandwidth costs.

+ +

CHAD: Today, is there a central service that makes the initial connection for people?

+ +

BEN: Yes, yeah, yeah. So, there is a signaling server. So, when you launch the app, you sign in, and you see, like, oh, which of my co-workers are online? So, there is actually a Rails app that handles that, actually, increasingly less the Rails app. We have now...I think it's a Go service that actually manages all those. I'm further and further from the code every year. Some of the technical questions might be a little bit beyond me, or I might have slightly out-of-date info.

+ +

But back to the architecture question for a second, we did a pretty big refactor when we decided to go from just being a Mac client to supporting other platforms, where we split out a cross-platform real-time communication engine written in C++ so that we could use that for all of the heavy lifting, all the managing of the connections, and the tricky bandwidth estimation, and all this stuff, and use that across different platforms. And so, today, you have the cross-platform engine, and then on top of that is a, like, a less specific layer for each of the operating systems that we support.

+ +

CHAD: So, you mentioned you're less and less in the code these days. So, what do you spend your time doing then?

+ +

BEN: It's a mix of things. These days, it's basically mostly --

+ +

CHAD: Just cocktails on the beach, right?

+ +

BEN: Cocktails, yes [laughs], cocktails on the beach, appearing on podcasts trying to sound important and impressive, yeah. Mostly product work. So, right before this, I just got off a call with some folks from The Browser Company. They are some of our first alpha users for our new Windows clients. So, I hopped on the call with them and, like, watched three of them install the product and inevitably run into some bugs. And, you know, chatted through those with the engineer that was working on it, prioritized some stuff, made some decisions about what's coming up next, and what we're going to ignore. So, mostly product work these days.

+ +

For the first five years of the company, I was CEO, so I was doing kind of everything: marketing, and also hiring, and also product. About two months ago, I stepped down as CEO, and one of my other co-founders, Spencer, stepped up. And so, now my focus has narrowed to be mostly just product stuff and much less on the marketing or hiring side.

+ +

VICTORIA: Yeah, you mentioned that it was a little more comfortable to be an employee than to be a founder. I don't know if you could say more about that because, certainly, a lot of engineers are smart enough and capable enough to run their own company. But what really informed your choice there, and do you regret it? [laughs]

+ +

BEN: I definitely don't regret it. thoughtbot was a close second in terms of wonderful professional experiences. But running my own thing has been the most interesting professional thing I've done by a big margin. It has also been more stressful. And, Chad, I don't know if you remember, I think, like, maybe eight years ago, you tweeted something like, if you want to sleep well at night, and, like, value that, like, peace of mind, like, don't start a company or something. I have experienced that.

+ +

CHAD: [laughs]

+ +

BEN: A lot more, yeah, like waking up in the middle of the night worrying about things. It feels a little bit like the highs are higher; the lows are lower. Being an employee somewhere, it's like, if this company fails, I know I can go get another job, right? Like, you're a developer. You're extremely employable. But as the owner of the company, if the company fails, like, a huge chunk of your net worth is gone. Like, this thing you poured your life into is gone. It's way more stressful and traumatic to have that happen, or have that threatened to be happening, or just imagine that happening.

+ +

So, overall, I have found the trade-off to be totally worth it. It's awesome to make your own decisions and chart your own path. And when it works, it can work in a way that being a salaried employee can't. So, I'm happy with those trade-offs. But I think that is a good question for people to ask themselves as they consider doing something like this is, like: is that the kind of trade-off that you want to make? Because it has significant downsides for sure.

+ +

WILL: I am a big fan of Tuple also. I love it. It [inaudible 10:08] easy, especially with remote work. You hit the jackpot with COVID and remote work, so kudos for that [laughs]. Was there anything...because I know from our previous companies, about over...hopefully a lot more of the good stuff than the bad stuff. But was there anything that you learned? Because you were at thoughtbot for seven years. Was there anything that you're like, oh my gosh, I learned that, and it's helped me till this day while I'm running my company?

+ +

BEN: Yeah, quite a bit, actually. I think it'd be hard to tease apart exactly which lessons, but I do...so I ran Upcase for thoughtbot and also FormKeep. So, I got a chance to kind of run a small division of the company, while still being a normal employee and, like, having not much of that risk. And I think that was a really wonderful opportunity for me to, like, practice the skills that I was interested in. Just, like, how do you market a thing? How do you design a product and have it be good? How do you prioritize user feedback?

+ +

There were a ton of lessons from those days that I feel like made me better at running our company when we actually took a shot at it. So, there were, like, the specific things that I learned by the work I was doing there. But then just, like, I mean, I think I am the programmer I am today because of, like, the weekly dev discussions that happened.

+ +

Like, spending so much time with Joe Ferris and, like, trying to copy as much of his brain as possible, like, really, like, imprinted on me as, like, a programmer. And also, just, like, a lot of the sort of cultural things from my time at thoughtbot of, like, you should be sharing the things you're learning. Like, writing blog posts is a great use of time. Like, doing open-source work is a great use of time.

+ +

And maybe you can't directly trace how doing, like, working in public or sharing information benefits the company. It's hard to, like, attribute it from a marketing sense. But if you sort of have faith that in the large, it's going to work out, it probably will. That feels like a thoughtbot lesson to me, and I think it has served us really well; where I recorded a weekly podcast for a long time called The Art of Product. I'm recording a new podcast called Hackers Incorporated with Adam Wathan of Tailwind fame.

+ +

And I don't ever think, like, hmm, how many new leads do we think we get per episode, and how many hours has that taken? What's the ROI? I just have this sort of reflex that I developed from thoughtbot time of, like, you should be putting stuff out there, or you should be giving back. You should help other people. And that will probably help your business and make it work in the long term.

+ +

CHAD: That's a good lesson [laughs]. One of the other things, you know, while you were a host of Giant Robots, you were the first host. I remember, you know, encouraging you to be the first host, and I think we talked about that in one of the episodes along the way. But we also transitioned the format a little bit, especially as you started to work on products here; you know, it was more about the building of those products and following along with those.

+ +

And one of the things that sort of half-jokingly defined, I think, your impact on a lot of products was pricing, experimenting with pricing, learning about pricing, increasing prices more than people were maybe comfortable doing so. How has that worked out with Tuple, pricing in particular?

+ +

BEN: It's really hard to say. It's hard to know what, like, the other path would have been through the world-. We sort of decided from, like, the early days that we wanted to have, like, a fairly premium price. Like, we wanted to be the product that was really good and was, like, a little bit annoyingly expensive, but you still paid for it because it felt worth it. And I think people could debate in both directions whether we nailed that or not.

+ +

We have had a price increase that we ended up rolling back. We went, like, a little too far one time and said, "You know what? I think we're a little bit over," and we reverted that. But I would say even today, we are still a fairly pricey product. I mean, I'm pretty happy with how the company has done. I can't prove to you that, like, if the price were half what it is, we would have, you know, better success or not.

+ +

CHAD: I think it'd be very hard to make the argument that if it was half that, you would have double the number of customers.

+ +

BEN: Yeah, that's probably not true.

+ +

CHAD: Not with the customers that you have, who are companies that will pay for products that they use as much as Tuple.

+ +

BEN: Yeah, I'm happy serving the kind of companies, and they end up being mostly tech companies that really value developer happiness. When their developers come to them and they say, "We don't want to pair over Zoom. We like this thing. It's better. It feels nicer to use," they say, "Okay," and they buy the tool for them. There are places where that's not the case. And they say, "We already have a thing that does screen sharing. You're not allowed to buy this." We don't invest a lot of time trying to sell to those people or convince them that they're wrong. And I'm pretty happy serving sort of the first group.

+ +

CHAD: So, you've mentioned that you've still been podcasting. To be honest, I didn't realize you were starting something new. Is it live now?

+ +

BEN: It is live now, yeah.

+ +

CHAD: Awesome. Where can people find that?

+ +

BEN: hackersincorporated.com. It's about the transition from developer to founder, which is kind of what we've been touching on here. Yeah, hopefully, the audience is developers who want to start something or have started something who are maybe a little bit further behind progression-wise.

+ +

And it's kind of, like, I have some lessons, and Adam has some lessons, and, you know, we don't think that we're experts. But sometimes it's useful to just hear, like, two people's story and sort of see, like, what seemingly has worked for them. So, we've been trying to share things there. And I think people will find it useful.

+ +

VICTORIA: I was going to ask you for a lesson, maybe give us a little sample about how would you advise someone who's built a product and wants to market it, and it's targeted towards developers since you mentioned that previously as well.

+ +

BEN: Yeah, in a way, the question already contains a problem. It's like, oh, I built the product; now how do I market it? It's a little bit indicative of a very common failure mode for developers, which is that. They sort of assume, okay, after you make the product, you then figure out how you're going to market it. And marketing is sort of a thing you layer on later on when you realize that just, like, throwing it on Twitter or Product Hunt didn't really work.

+ +

When we started building Tuple, I was out there marketing it already. So, I had two co-founders, so this is a luxury I had. My two co-founders were writing code, and I was out doing stuff. I was recording podcasts. I was tweeting about things. I was making videos. I was giving conference talks. And I was getting people to hear about our product well before it was done. In fact, I was even selling it. I was taking pre-orders for annual subscriptions to the app while it was still vaporware.

+ +

So, I would say, like, you basically can't start marketing too early. If you start marketing early and no one really cares, well, then you don't really have to build it probably. I would actually even go a little further and say, like, I started marketing Tuple before we had a product available. But in reality, I started marketing Tuple seven or so years before that when I started publishing things through thoughtbot.

+ +

It's like when I was traveling around giving talks about Ruby, and when I was making screencasts about Vim, and when I was running Upcase, I was, over time, building an audience. And that audience was useful for thoughtbot, and it also was useful for me so that when I left, I had something like 10,000 Twitter followers or something, a few thousand people on our mailing list.

+ +

But there were a lot of developers that already sort of knew me and trusted me to make fairly good things. And so, when I said, "Hey, I've made a new thing, and it's for you," I really benefited from those years of making useful content and trying to be useful on the internet. And in the early days, we had people sign up, and they would say, "I don't even really think I'm going to use this. But I've learned so much from you over the years that I want to support you, so I'm going to pay for a subscription."

+ +

VICTORIA: I like your answer because I think the same thing when people ask me, like, because I am an organizer for Women Who Code, and I know all these great people from showing up for years in person months over months. And so, then people will ask, "Oh, how do I recruit more women in my company?" I'm like, "Well, you got to start showing up [laughs] now and do that for a couple of years, and then maybe people will trust you," right? So, I really like that answer.

+ +

WILL: How has your relationship with Chad continued to grow since you left? Because seven years at the company is a lot. And it seems like you're still on really, really good terms, and you're still friends. And I know that doesn't happen at every company.

+ +

BEN: I mean, it was tough deciding to leave. I think, like, both of us felt pretty sad about it. That was the longest I'd ever worked anywhere, and I really enjoyed the experience. So, I think it was tough on both sides, honestly. But we haven't kept in that much touch since then. I think we've emailed a handful of times here and there. We're both sociable people, and we sort of get each other. And there's a long history there. So, I think it's just easy for us to kind of drop back into a friendly vibe is sort of how I feel about it.

+ +

CHAD: Yeah. And the way I explain it to people, you know, when you're leading a company, which Ben and I both are, you put a lot of energy into that and to the people who are on that team. If you're doing things right, there's not really hard feelings when someone leaves. But you need to put in a lot of effort to keep in touch with people outside of the company and a lot of energy. And, to be honest, I don't necessarily do as good a job with that as I would like because it's a little bit higher priority to maintain relationships with them, the people who are still at thoughtbot and who are joining.

+ +

BEN: What you're saying is I'm dead to you [laughter]. That's CEO, for you're dead to me.

+ +

CHAD: No. It's just...no hard feelings.

+ +

BEN: Totally.

+ +

CHAD: I think one of the things that has been great about the show over the years is that we haven't been afraid to change the format, which I think has been important to keeping it going. So, there is sort of; in fact, the website now is organized into seasons. And I went back and re-categorized all the episodes into seasons. And when the seasons were made up of, like, sort of the format of the show or particular hosts...when we started, it was just an interview show, and it was largely technical topics.

+ +

And then we started The Bike Shed, and the technical topics sort of moved over there. But it also went with your interests more under the product and business side. Then you started working on products at thoughtbot, so it started to go even more in that. And I think Chris joined you on the show, and that was sort of all about those topics.

+ +

BEN: Yeah, that makes sense. I think if you don't let the hosts kind of follow their interests, they're going to probably burn out on the thing. It's not fun to force yourself, I think, to record a podcast.

+ +

CHAD: Yeah. And then when you left, you know, I took over hosting and hosted by myself for a while, went back to the interview format, but then was joined by Lindsey for a little while. We experimented with a few different things: one, interviews, but then we did a whole, just under a year, where we followed along with three companies. And each month, we would have an interview episode where we talked to them, all three companies, about the same topic.

+ +

And then, we also did an episode with just Lindsey and I talking about that topic and about what we learned from the startup companies that we were following along with for the year. And now we're back to interview freeform, different guests, different topics. It seems like we're going to stick with that for a little while. But, obviously, as Will and Victoria have said, like, we'll probably change it again in some way, you know, a year, two years, three years from now.

+ +

VICTORIA: Yeah, and I'm definitely bringing my interest around DevOps and platform engineering, so you'll see more guests who have that focus in their background. And with that, sometimes my interview style is more; how do I ask a question that I can't read from your developer docs and that I might not understand the answer to? [laughs] That's kind of where I like to go with it. So yeah, I'm really excited about...it's probably one of my favorite parts of my job here at thoughtbot because I get to meet so many interesting people. And, hopefully, that's interesting to everyone else [laughs] and our guests, yeah.

+ +

BEN: Totally. Well, I dramatically underestimated how awesome it would be to meet all kinds of cool people in the industry when I started the podcast. I didn't truly connect in my head, like, wait a second, if I have a 45-minute conversation with, like, a lot of prominent, awesome people in our field, that's going to be really interesting and useful for me. So, I think, yeah, it's nice to be in the hosting seat.

+ +

VICTORIA: And it's so surprising how I'll meet someone at a conference, and I'll invite them onto the podcast. And the way it winds up is that whatever we're talking about on the show is directly relevant to what I'm working on or a problem that I have.

+ +

It's been incredible. And I really appreciate you for coming back for our 500th Episode here.

+ +

CHAD: Ben, thanks very much again for joining us, and congratulations on all the success with Tuple. And I wish you the best.

+ +

BEN: Thank you so much. Thanks for being a continuing customer. I really appreciate it.

+ +

CHAD: Next, we caught up with Chris Toomey, who had a run as co-host of the show with Ben throughout 2016.

+ +

CHRIS: Hi there. Thanks for having me.

+ +

So, we're talking with all of the past hosts. I know you joined the show, and you were on it with Ben. And then you moved over to The Bike Shed, right?

+ +

CHRIS: Yeah. So, I had co-hosted with Ben for about six months. And then I think I was transitioning off of Upcase, and so that ended sort of the Giant Robots “let's talk about business” podcast tour for me. And then, I went back to consulting for a while. And, at some point, after Derek Prior had left, I took over as the host of The Bike Shed. So, I think there was probably, like, a year and a half, two-year gap in between the various hostings.

+ +

CHAD: Are you doing any podcasting now?

+ +

CHRIS: I'm not, and I miss it. It was a lot of fun. It was, I think, an ideal medium for me. I'm not as good at writing. I tend to over-edit and overthink. But when you get me on a podcast, I just start to say what's in my head, and I tend to not hate it after the fact. So [chuckles], that combination I found to be somewhat perfect for me. But yeah, lacking that in my current day-to-day.

+ +

CHAD: Well, what's been taking up your time since you left?

+ +

CHRIS: I had decided it was time to sort of go exploring, try and maybe join a startup, that sort of thing. I was sort of called in that direction. So, just after I left thoughtbot, I did a little bit of freelancing, but that was mostly to sort of keep the lights on and start to connect with folks and see if there might be an opportunity out there.

+ +

I was able to connect with a former thoughtbot client, Sam Zimmerman, who was looking to start something as well. And so, we put our act together and formed a company called Sagewell, which was trying to build a digital financial platform for seniors, which is a whole bunch of different complicated things to try and string together. So, that was a wonderful experience. I was CTO of that organization. And I think that ran for about two and a half years. Unfortunately, Sagewell couldn't quite find the right sort of sticking point and, unfortunately, shut down a little bit earlier in this year.

+ +

But that was, I would say, the lion's share of what I have done since leaving thoughtbot, really wonderful experience, got to learn a ton about all of the different aspects of building a startup. And I think somewhat pointedly learned that, like, it's messy, but I think I do like this startup world.

+ +

So, since leaving Sagewell, I've now joined a company called August Health, which has a couple of ex-thoughtboters there as well. And August is post their Series A. They're a little bit further along in their journey. So, it was sort of a nice continuation of the startup experience, getting to see a company a little bit further on but still with lots of the good type of problems, lots of code to write, lots of product to build. So, excited to be joining them. And yeah, that's mostly what's taking up my time these days.

+ +

CHAD: So, I know at Sagewell, you made a lot of technical architecture, team decisions. It was Rails in the backend, Svelte in the frontend, if I'm not mistaken.

+ +

CHRIS: Yep, that's correct.

+ +

CHAD: You know, hindsight is always 2020. Is there anything you learned along the way, or given how things ended up, that you would do differently?

+ +

CHRIS: Sure. I was really happy with the tech stack that we were able to put together. Svelte was probably the most out there of the choices, I would say, but even that, it was sort of relegated to the frontend. And so, it was a little bit novel for folks coming into the codebase. Most folks had worked in React before but didn't know Svelte. They were able to pick it up pretty quickly.

+ +

But Inertia.js was actually the core sort of architecture of the app, sort of connected the frontend and the backend, and really allowed us to move incredibly quickly. And I was very, very happy with that decision. We even ended up building our mobile applications, both for iOS and Android. So, we had native apps in both of the stores, but the apps were basically wrappers around the Rails application with a technology similar to Turbolinks native–if folks are familiar with that so, sort of a WebView layer but with some native interactions where you want.

+ +

And so, like, we introduced a native login screen on both platforms so that we could do biometric login and that sort of thing. But at the end of the day, most of the screens in the app didn't need to be differentiated between a truly native mobile app and what like, mobile WebView would look like. So, we leaned into that.

+ +

And it was incredible just how much we were able to do with that stack and how quickly we were able to move, and also how confidently we were able to move, which was really a nice thing. Having the deep integration between the backend and the frontend really allowed a very small team to get a lot done in a short time.

+ +

CHAD: Does that code live on in any capacity?

+ +

CHRIS: No.

+ +

CHAD: Oh. How does that make you feel?

+ +

[chuckles]

+ +

CHRIS: It makes me feel very sad, I will say. That said, I mean, at the end of the day, code is in service of a business. And so, like, the code...there are, I think, probably a couple of things that we might be able to extract and share. There were some interesting...we did some weird stuff with the serializers and some, like, TypeScript type generation on the frontend that was somewhat novel.

+ +

But at the end of the day, you know, code is in service of a business, and, unfortunately, the business is not continuing on. So, the code in the abstract is...it's more, you know, the journey that we had along the way and the friends we made and whatnot. But I think, for me, sort of the learnings of I really appreciate this architecture and will absolutely bring it to any new projects that I'm building from, you know, greenfield moving forward.

+ +

VICTORIA: I'm curious what it was like to go from being a consultant to being a big player in a startup and being responsible for the business and the technology. How did that feel for you?

+ +

CHRIS: I would say somewhat natural. I think the consulting experience really lent well to trying to think about not just the technical ramifications but, you know, what's the business impact? How do we structure a backlog and communicate about what features we want to build in what order? How do we, you know, scope a minimal MVP? All those sorts of things were, I think, really useful in allowing me to sort of help shape the direction of the company and be as productive of an engineering team as we could be.

+ +

CHAD: A lot of the projects you worked on at thoughtbot were if not for startups, helping to launch new products. And then, a lot of the work you did at thoughtbot, too, was on Upcase, which was very much building a business.

+ +

CHRIS: Yes. I definitely find myself drawn in that direction, and part of like, as I mentioned, I seem to be inclined towards this startup world. And I think it's that, like, the intersection between tech and business is sort of my sweet spot. I work with a lot of developers who are really interested in getting sort of deeper into the technical layers, or Docker and Kubernetes and orchestration. And I always find myself a little bit resistant to those. I'm like, I mean, whatever. Let's just...let's get something out there so that we can get users on it. And I am so drawn to that side, you know, you need both types of developers critically.

+ +

I definitely find myself drawn to that business side a little bit more than many of the folks that I work with, and helping to bridge that gap and communicate about requirements and all those sort of things. So, definitely, the experience as a consultant really informed that and helped me have sort of a vocabulary and a comfort in those sort of conversations.

+ +

WILL: How did Upcase come about? Because I know I've talked to numerous people who have gone through Upcase. I actually went through it, and I learned a ton. So, how did that come about?

+ +

CHRIS: I think that was a dream in Ben Orenstein's eye. It started as thoughtbot Learn many, many years ago. There was a handful of workshops that had been recorded. And so, there were the video recordings of those workshops that thoughtbot used to provide in person. Ben collected those together and made them sort of an offering on the internet.

+ +

I think Chad, you, and I were on some podcast episode where you sort of talked about the pricing models over time and how that went from, like, a high dollar one-time download to, like, $99 a month to $29 a month, and now Upcase is free. And so, it sort of went on this long journey. But it was an interesting exploration of building a content business of sort of really leaning into the thoughtbot ideal of sharing as much information as possible, and took a couple of different shapes over time.

+ +

There was the weekly iterations of the video series that would come out each week, as well as the, like, longer format trails, and eventually some exercises and whatnot, but very much an organic sort of evolving thing that started as just a handful of videos and then became much more of a complete platform. I think I hit the high points there. But, Chad, does that all sound accurate to you?

+ +

CHAD: Yeah, I led the transition from our workshops to Learn, which brought everything together. And then, I stepped away as product manager, and Ben took it the next step to Upcase and really productized it into a SaaS sort of monthly recurring billing model and took it over from there. But it still exists, and a lot of the stuff there is still really good [laughs].

+ +

CHRIS: Yeah, I remain deeply proud of lots of the videos on that platform. And I'm very glad that they are still out there, and I can point folks at them.

+ +

VICTORIA: I love that idea that you said about trying to get as much content out there as possible or, like, really overcommunicate. I'm curious if that's also stayed with you as you've moved on to startups, about just trying to get that influence over, like, what you're doing and how you're promoting your work continues.

+ +

CHRIS: I will say one of the experiences that really sticks with me is I had followed thoughtbot for a while before I actually joined. So, I was reading the blog, and I was listening to the podcasts and was really informing a lot of how I thought about building software. And I was so excited when I joined thoughtbot to, like, finally see behind the curtain and see, like, okay, so, what are the insider secrets?

+ +

And I was equal parts let down...actually, not equal parts. I was a little bit let down but then also sort of invigorated to see, like, no, no, it's all out there. It's like, the blog and the open-source repos and those sort of...that really is the documentation of how thoughtbot thinks about and builds software. So, that was really foundational for me. But at the same time, I also saw sort of the complexity of it and how much effort goes into it, you know, investment time Fridays, and those sort of things.

+ +

Like, a thoughtbot blog post is not a trivial thing to put up into the world. So many different people were collaborating and working on it. And so, I've simultaneously loved the sharing, and where sharing makes sense, I've tried to do that. But I also recognize the deep cost. And I think for thoughtbot, it's always made sense because it's been such a great mechanism for getting the thoughtbot name out there and for getting clients and for hiring developers.

+ +

At startups, it becomes a really interesting trade-off of, should we be allocating time to building up sort of a brand in the name and getting ourselves, you know, getting information out there? Versus, should we be just focusing on the work at hand? And most organizations that I've worked with have bias towards certainly less sharing than thoughtbot, but just not much at all. Often, I'll see folks like, "Hey, maybe we should start a blog." And I'm like, "Okay, let's just talk about how much effort that [laughs] actually looks like." And I wonder if I'm actually overcorrected on that, having seen, you know, the high bar that thoughtbot set.

+ +

CHAD: I think it's a struggle. This is one of my [laughs] hot topics or spiels that I can go on. You know, in most other companies, that kind of thing only helps...it only helps in hiring or the people being fulfilled in the work. But at most companies, your product is not about that; that's not what your business is. So, having a more fulfilled engineering team who is easier to hire—don't get me wrong, there are advantages to that—but it doesn't also help with your sales.

+ +

CHRIS: Yes.

+ +

CHAD: And at thoughtbot, our business is totally aligned with the people and what we do as designers and developers. And so, when we improve one, we improve the other, and that's why we can make it work. That is marketing for the product that we actually sell, and that's not the case at a SaaS software company.

+ +

CHRIS: Yes, yeah, definitely. That resonates strongly. I will say, though, on the hiring side, hiring at thoughtbot was always...there was...I won't say a cheat code, but just if someone were to come into the hiring process and they're like, "Oh yeah, I've read the blog. I listen to the podcast," this and that, immediately, you were able to skip so much further into the conversation and be like, "Okay, what do you agree with? What do you disagree with? Like, let's talk." But there's so much.

+ +

Because thoughtbot put so much out there, it was easy to say, like, "Hey, this is who we are. Do you like that? Is that your vibe?" Whereas most engineering organizations don't have that. And so, you have to try and, like, build that in the context of, you know, a couple of hour conversations in an interview, and it's just so much harder to do. So, again, I've leaned in the direction of not going anywhere near thoughtbot's level of sharing. But the downside when you are hiring, you're like, oh, this is going to be trickier.

+ +

CHAD: Yeah. One of the moments that stands out in my mind, and maybe I've told this story before on the podcast, but I'll tell it again. When we opened the New York studio, it was really fast growing and was doing a lot of hiring. And one of the people who had just joined the company a couple of weeks before was doing an interview and rejected the person was able to write an articulate reason why. But it all boiled down to this person is, you know, not a fit for thoughtbot.

+ +

Based on what they were able to describe, I felt very confident with the ability or with the fact that they were able to make that call, even though they had been here only a couple of weeks, because they joined knowing who we were, and what we stand for, and what our culture and our values are, and the way that we do things, and all that kind of thing. And so, yeah, that's definitely a huge benefit to us.

+ +

VICTORIA: I've certainly enjoyed that as well, as someone who hires developers here and also in meeting new companies and organizations when they already know thoughtbot. That's really nice to have that reputation there, coming from my background—some really more scrappier startup kind of consulting agencies.

+ +

But, you know, I wanted to talk a little bit more about your podcasting experience while you're here. So, I know you were on both The Bike Shed and Giant Robots. Which is the better podcast? [laughter] So, what's your...do you have, like, a favorite episode or favorite moment, or maybe, like, a little anecdote you can share from hosting?

+ +

CHRIS: Well, I guess there's, like, three different eras for me in the podcasting. So, there's Giant Robots with Ben talking more about business stuff, and I think that was really useful. I think it was more of a forcing function on me because I sort of...Both Ben and I were coming on; we were giving honest, transparent summaries of our, like, MRR and stats and how things were growing, and acted as sort of an accountability backstop, which was super useful but also just kind of nerve-wracking.

+ +

Then, when I joined the Bike Shed, the interviewing sequence that I did each week was just a new person that I was chatting with. And I sort of had to ramp them up on, hey, here's a quick summary on how to think about podcasting. Don't worry, it'll be great. Everybody have fun. But I was finding each of the guests. I was sort of finding a topic to talk about with them. So, that ended up being a lot more work.

+ +

And then, the last three years chatting with Steph that was by far my favorite. There was just such a natural back-and-forth. It really was just capturing the conversations of two developers at thoughtbot and the questions we would ask each other as we hit something complicated in a piece of code or, "Oh, I saw this, you know, article about a new open-source repository. What do you think about that?" It was so much easier, so much more natural, and, frankly, a lot of fun to do that.

+ +

And, two, I actually do have an answer to the favorite podcast episode, which is the first episode that Steph was ever on. It was before she actually joined as a co-host. But it was called “What I Believe About Software.” And it was just this really great, deep conversation about how we think about software. And a lot of it is very much, like, thoughtbot ideals, I would say. But yeah, Steph came in and just brought the heat in that first episode, and I remember just how enjoyable that experience was. And I was like, all right, let's see if I can get her to hang out a little bit more, and, thankfully, she was happy to join.

+ +

WILL: What was your favorite position, I guess you can call it? Because you say you like the mixture of business and, you know, development. So, you've been in leadership as development director, CTO. You've been a web developer. You've been over content, like, with Upcase. What was your favorite position [inaudible 16:43] you were doing, and why was it your favorite?

+ +

CHRIS: The development director role feels like sort of a cheating answer, but I think that would be my answer because it contained a handful of things within it. Like, as development director, I was still working on client projects three days a week. And then, one day a week was sort of allocated to the manager-type tasks, or having one-on-ones with my team sort of helping to think about strategy and whatnot. And then, ideally, still getting some amount of investment time, although the relative amounts of those always flexed a little bit. Because that one sort of encompassed different facets, I think that's going to be my answer.

+ +

And I think, like, some of what drew me to consulting in the first place and kept me in that line of work for seven years was the variety, you know, different clients, as well as, even within thoughtbot, different modes of working in podcasts or video. Or there was a bootcamp that I taught, a session of Metis, which that was a whole other experience. And so, getting that variety was really interesting.

+ +

And I think as sort of a tricky answer to your question, the development director role as a singular thing contained a multitude, and so I think that was the one that would stand out to me. It's also the most, you know, the one that I ended on, so [laughs] it might just be recency bias, but yeah.

+ +

VICTORIA: Oh, I love that. Is there anything else that you would like to promote on the podcast today?

+ +

CHRIS: No, although as you ask the question, I feel like I should, I don't know, make some things to promote, get back into some, I don't know, content generation or something like that. But for now, no. I'm, you know, diving into the startup life, and it's a wonderful and engrossing way to do work, but it does definitely take up a lot of my headspace. So, it's an interesting trade-off.

+ +

But right now, I don't know; if folks are online and they want to say hi, most of my contact information is readily available. So, I would love to say hi to folks, anyone that listened in the past or, you know, has any thoughts in the now. Would love to connect with folks. But otherwise, yeah, thank you so much for having me on.

+ +

CHAD: In 2017, I took over from Ben as solo host of the show but was joined by Lindsey Christainson as cohost in 2019. After some time away from thoughtbot, Lindsey is back with us and we sat down to catch up with her.

+ +

VICTORIA: Why don't you tell me about your current role with thoughtbot?

+ +

LINDSEY: I am currently supporting marketing and business development at thoughtbot, as well as working as a marketing consultant for thoughtbot clients.

+ +

VICTORIA: Great. And I understand that you had worked with thoughtbot many years ago, and that's when you also came on as a co-host of Giant Robots. Is that right?

+ +

LINDSEY: Yeah, a couple of years ago. I left thoughtbot in spring of 2021. And I forget how long my stint was as a co-host of Giant Robots, but over a year, maybe a year and a half, two years?

+ +

CHAD: Yeah, I think that's right. I think you started in 2019.

+ +

LINDSEY: Yeah. Yeah, that sounds right. And Chad and I were co-hosts, I think, similar to the setup today in which sometimes we hosted together, and sometimes we were conducting interviews separately.

+ +

CHAD: And then we sort of introduced a second season, where we followed along with a batch of companies over the course of the entire season. And that was fun, and we learned a lot. And it was nice to have consistent guests.

+ +

LINDSEY: Yeah, that was a lot of fun. I really liked that format. I don't know; they almost were, like, more than guests at that point. They were just like other co-hosts [laughs] that we could rely on week in, week out to check in with them as they're working on early-stage companies. So, every time we checked in with them, they usually had some new, exciting developments.

+ +

WILL: I really like that idea. How did y'all come up with that?

+ +

CHAD: I'm not sure. I think a few years before I had taken over hosting of the show, and I forget...my memory maybe is that I went to Lindsey and said, "You know, let's do something different." But I'm not sure. Does that match your memory, Lindsey?

+ +

LINDSEY: Yeah, I think there were two main drivers; one was I think you were feeling like you were having similar conversations in the interviews every time. Like, you couldn't get to a certain depth because every time you were interviewing someone, you were doing, like, the, "Well, tell me your founding story." And, you know, how did you raise funding? It kind of got a little bit repetitive.

+ +

And then, on the side, the few we had done together, I think we both really enjoyed. So, we were thinking, like, what's the format in which the two of us could co-host together more regularly? Because I'm a pleasure to talk to [laughter]. I think you were like, I need to talk to Lindsey more. [inaudible 3:13]

+ +

VICTORIA: What is your hosting style? How would you describe your approach to hosting a podcast?

+ +

LINDSEY: I mean, obviously, it's a podcast about products and business. I think as a marketer, I am, you know, drawn a lot to the marketing side, so tending to ask questions around go-to-market audience, users. That's always just, like, a particular interest of mine. But then also, like, the feelings. I love asking about the feelings of things, you know, how did it feel when you started? How did it feel when you made this tough decision? So, that's another thing I think I noticed in my interviews is asking about some of the emotions behind business decisions.

+ +

VICTORIA: And I like hearing about how people felt at the time and then how they felt afterwards [laughs]. And, like, how people around them supported each other and that type of thing. That's really fun.

+ +

I'm curious, too, from your marketing background and having to do with podcasts like; some founders, I think, get the advice to just start a podcast to start building a community. But I'm curious on your thoughts about, like, how does podcasting really play into, like, business and marketing development for products?

+ +

LINDSEY: Oh yeah. It's become definitely, like, a standard channel in B2B these days. I feel like that it's pretty typical for a company to have a podcast as one way that they engage their audience and their users. In marketing, you're really vying for people's attention, and people's attention span is getting shorter and shorter. So, like, if you have an ad or a blog, you're getting, like, seconds, maybe minutes of someone's attention. And whereas something like a podcast offers a unique channel to have someone's undivided attention for, you know, 30 minutes, an hour, and if you're lucky, you know, checking back in week over week. So, it became a really popular method.

+ +

That said, I think you're probably also seeing the market get saturated [laughs] with podcasts now, so some diminishing returns. And, you know, as always, kind of looking for, you know, what's the next way? What's the next thing that people are interested in in ways to capture their attention?

+ +

CHAD: What is the next thing?

+ +

LINDSEY: I don't know, back to micro-content? TikTok videos --

+ +

CHAD: Yeah, I was going to say TikTok, yeah.

+ +

LINDSEY: Yeah, you know, 10-30 seconds, what can you communicate?

+ +

VICTORIA: I see people live streaming on Twitch a lot for coding and developer products.

+ +

LINDSEY: Yeah, I think we've seen some of that, too. We've been experimenting more at thoughtbot with live streaming as well. It's another interesting mechanism. But yeah, I don't know, it's interesting. It's another form of, like, community and how people engage with their communities. So, it's always evolving. It's always evolving, and sometimes it's not. Sometimes, people just do want to get in a room together, too, which is always interesting.

+ +

WILL: What has been, in your experience, the good the bad? Like, how do you feel about the way that it has shifted? Because I think you started in, like, 2000, like, kind of earlier 2000, 2005, something around there. And it was totally different than now like you're saying. Because I feel like, you know, Channel 5 30-second ad, you know, with some of the marketing depending on what you're doing, to now to where you're, like, you're paying influencers to advertise your product, or you're doing an ad. Or it's more social media-driven and tech-driven. What has been your opinion and feelings on the way that it has grown and evolved?

+ +

LINDSEY: Marketing, in general, yeah, I graduated college in 2005 and started my marketing career. And yeah, you could, like, actually get people to click on banner ads back then, which was pretty [inaudible 07:14] [laughs].

+ +

WILL: I forgot about banner ads [laughs].

+ +

LINDSEY: I don't know, yeah. I don't know. In order for myself to not just get too frustrated, I think I've got to, like, view it as a game kind of. What new things are we going to try? You know, what do we see work? But it can really depend. And I've always been in B2B side of things. And consumer, I'm sure, has its own kind of evolution around how people engage and how they consume content and byproducts. But in B2B, you know, it can really depend on industry too.

+ +

You know, I'm working with a client right now in the senior living space, and they're really big in in-person conferences. So, that's how people consume, get a lot of their information and, make connections, and learn about new products. So, it's been interesting to work in an industry that what might be considered, like, a little bit more old-school channels are still effective. And then just thinking about how you weave in the new channels with the existing ones without ignoring them. They might get information in conferences, but they're still a modern human who will then, you know, search online to learn more, for example.

+ +

VICTORIA: It reminds me of a phrase I like to say, which is that, like, technology never dies; you just have more of it. There's just more different options and more different ways to do things. And some people are always, you know, sometimes you have to be flexible and do everything.

+ +

CHAD: So, tell us more about what you did in between...after you left thoughtbot, what did you do?

+ +

LINDSEY: I was heading up B2B marketing for a company called Flywire, which is headquartered in Boston but is a global company now. And they were just kind of starting their B2B business unit, which, as I mentioned, B2B is my personal specialty. I had been connected to their CMO through the Boston startup community. And yeah, I was helping them kind of launch their go-to-market for B2B. The industries they were in before...they got their start in higher education and then expanded in healthcare and found a niche in luxury travel, and then we were figuring out the B2B piece. But yeah, I was there for about a year and a half.

+ +

They actually went public the second week I was there, which was an interesting [laughs] experience. I knew they were, like, on that journey, but it was kind of funny to be there the second week, and people were, like, "Congrats." And I was like, "Well, I definitely didn't have anything to do with it because I just finished my onboarding, but thank you," [laughs].

+ +

CHAD: One of the things that really impressed me when you joined thoughtbot was the way in which you learned about who we were and really internalized that in a way where you were then able to pretty meaningfully understand our market, our positioning in the market, and come up with new strategies for us. I assume that's something you're good at in general [laughs]. How do you approach it? How did you approach it when you joined Flywire, for example? And how was it the same or different than how you approached thoughtbot?

+ +

LINDSEY: Ooh, yeah, that's a good question. And I appreciate that comment because it's difficult. But I think, yeah, with any new organization that I'm joining, you know, I think starting out with your kind of mini-listening tour of your key stakeholders across, you know, the different departmental focuses to get a sense of, what are the challenges? What are the opportunities? It's actually like, you know, it's the SWOT analysis, kind of trying to fill in your own mind map of a SWOT analysis of where the company is. What are the major hurdles you're facing? Where are people trying to go? What have they tried that's worked? What have they tried that's failed?

+ +

But then, like, I think for the culture component, I think a part of that maybe is, like, feel, and maybe something that I do have a knack for. Again, maybe this is, like, you know, emotional intelligence quotient, where it's like, you know, but it's the company, you know, who is this company? What is important to them? How do they work and go about things?

+ +

I know thoughtbot is certainly very unique, I think, in that arena in terms of being, like, a really value-driven company, and one where especially, like, marketing and business work is, like, distributed across teams in a really interesting way. You know, I'm sure the fact that it fascinated me and was something I could get passionate and get behind was something that also helped me understand it quickly.

+ +

CHAD: I was excited that...or it was sort of a coincidence because I had reached out to you and without realizing that you had left Flywire. And Kelly, who had been doing a combined sales and marketing role, was going on parental leave. And so, it was fortuitous [laughs] that you were able to come back and help us and provide coverage, like, Kelly was out.

+ +

LINDSEY: Yeah, it definitely felt like stars aligned moment, which, you know, I'm pretty woo-woo, so I believe in [laughter]...I believe in that kind of thing. You know, yeah, it was wild. It really did feel like your email came out of nowhere. And, you know, I mentioned it, obviously, to my partner and my friends. And they were like, "Oh, he definitely knows, like, that you left your last company." And I'm like, "I actually don't think he does [laughter]. I actually don't think he does." Yeah, and then we started chatting about me coming back to help. And it was great. thoughtbot makes it hard to work anywhere else [laughs]. So, I was happy to come back. I missed the team.

+ +

CHAD: And one of the exciting things, and you've mentioned it, is you're not just doing marketing for thoughtbot now. We have started to offer your services to our clients.

+ +

LINDSEY: Yeah, I'm super excited about this. And it's something I'd started thinking about. I had decided to take some time off between Flywire and my next thing and had started thinking about doing marketing, consulting. And as I'm doing that, I'm thinking a lot about how thoughtbot does consulting and, you know, wanting to emulate something like that.

+ +

So, I started back up at thoughtbot. That wasn't part of the plan. I was just going to, you know, fill in for Kelly and help with marketing things. But then, you know, a good opportunity arose to work on a client, and I was really excited. When, you know, Chad, you and I chatted through it, we came to the conclusion that this was something worth exploring under the, you know, thoughtbot umbrella. And it's been a really great experience so far. And we now have brought on another client now. And if you're listening and need early-stage B2B marketing support, reach out to lindsey@thoughtbot.com.

+ +

CHAD: Definitely. And Lindsey is pretty good, so you're going to like it [laughs].

+ +

LINDSEY: Yeah, you're going to like the way you look.

+ +

WILL: Yeah, definitely. Because I can even feel your presence here, you know, coming back. Because even like, you know, the market where it's at now and some of the suggestions that, you know, you've been helping us. For example, like, I do a lot of React Native, and you're like, "Hey, you know, blog posts have done a lot of traction, you know, let's get some more blog posts out in the market to help with the traffic and everything."

+ +

So, the question I have with that is, like, thank you for even suggesting that because it's, like, those little things that you don't even think about. It's like, oh yeah, blog posts, that's an easy transition to help the market, clients, things like that. But with the market the way it is, what has been your experience working during this time with the market? I don't know if you want to call it struggling, but whatever you want to call it that, it's doing [laughs].

+ +

LINDSEY: Yeah, I mean, the economy is difficult now. We also went through a really tough spot when I was here last time. During COVID, you know, we faced a major company challenge. And, I mean, I'll let Chad speak to it, but I would imagine it's probably one of the bigger, like, economic inflection points that you faced. Would you say that?

+ +

CHAD: Yeah, definitely. The thing about it that made it worse was how quickly it happened. You know, it was something that you didn't see coming, and then, you know, about 40% of our business went away in a single month. That's the kind of thing that was a real shock to the system.

+ +

I think the thing that made it difficult, too, was then the aspects of COVID, where we were no longer able to go into our studios. We were all working remotely. We were isolated from each other. And so, that made executing on what needed to be done in order to make the company survive additionally challenging.

+ +

LINDSEY: Yeah, so I think, like, going through that experience, also, and seeing how the team and the leadership team rallied together to get through it. And then, you know, ultimately, I think 2021 and 2022 have, like, really good years. That was a really positive experience. And something I'll definitely take with me for a while is just, like, keeping a cool head and just knowing you have, like, really smart, talented folks with you working on it and that you can get through it.

+ +

And just, like, doing some, I mean, we relied on what we did best, which was, like, design thinking, using design exercise to think about, like, how we might re-organize the company, or what other services we might try launching, or how might we re-package, you know, larger services into smaller more palatable services when people have, like, kind of tighter purse strings. So, that was, like, a great educational experience, and I think something we just continue to do now: be open to change, be open to changing how we package services, what clients we go after, and coming at it with, like, an agile, experimental mindset and try to find out what works.

+ +

VICTORIA: I really appreciate that. And it aligns now with the new service we've developed around you and the marketing that you provide. And I'm curious because I've had founders come up to me who say they need help with marketing or they need to, like, figure out their marketing plans. So, say you've met a founder who has this question, like, what questions do you ask them to kind of narrow down what it is they really need and really want to get out of a marketing plan?

+ +

LINDSEY: I've been thinking about this a lot recently. And, like, obviously, I see other marketing leaders in the market. Marketers like to talk about what they do on LinkedIn [laughs], so I get to...I read a lot about different people's approaches to this. And some people kind of go in and are like, okay, this is what you need. This is how we're going to do it, and they start executing on it.

+ +

And I really do take a very collaborative approach with founders. I think they're, especially in early stage, they're your most important asset in a way, and a lot of their intuition around the market and the business, you know, it's gotten them to where they're at. And so, I think starting from the point of, like, taking what they view as priorities or challenges, and then helping them better explore them or understand them with my own marketing experience and expertise, to narrow in on work that's going to be valuable for them, is kind of my starting point with early-stage companies.

+ +

Again, a little bit of that, like, listening tour kind of attitude of, like, what do you think is important? And there's probably data points behind that. And then helping you as a company frame that into, you know, what's going to be the most valuable? Like, is it an awareness campaign, or a lead-generating campaign, or a content strategy?

+ +

Do we actually need to take a look at the data you have and spend a little bit of effort cleaning that up so that we understand what we're working with better? Is it sales enablement? You know, do you have existing salespeople, but maybe they're struggling or don't have unified tools and messaging that they're using? That's how I kind of first approach it with the founder, very much kind of in lockstep.

+ +

VICTORIA: I appreciate that little preview of what your services would be like. And I always really appreciate when you help me with my marketing plans around our Mission Control team and platform engineering and how to really refine our message and make sure it reaches the right people.

+ +

LINDSEY: Yeah, I think another thing I used at thoughtbot in the previous time that I've taken with me to Flywire and now with clients is, like, the idea of, like, mini-briefs and working on them with the key stakeholder, whether that's you the head of, you know, a business unit or a founder, which is, like, let's just take the, however long, 30 minutes to talk about, who's the audience? What's our goal? You know, what are the elements that might help us achieve that goal? What are some of the metrics that we might use to measure whether or not we were successful in reaching that goal?

+ +

And it sounds really basic, but a lot of people can skip it. And I think then there's confusion around who you are targeting, or people have different ideas in mind of, like, what you are actually trying to achieve.

+ +

VICTORIA: I like that. And to pivot a little bit, I wonder if you have any thoughts on our podcast here at Giant Robots. What do you think the benefit of it is to thoughtbot, actually?

+ +

LINDSEY: I think it's been a brand builder and a way to, again, like, another channel to engage with our audience. It's been so long-standing now, you know. I talked about how most companies have a podcast now. But this is what? The 500th Episode, right? Over years and years, which is really impressive that it's been going that long. So, it's a way to bring the brand to life.

+ +

I think one of my first insights coming into the thoughtbot team is, you know, as a consulting organization, when I interviewed clients about what they loved about thoughtbot, I thought they were going to say that they ended up with amazing products. And they did. They did say that. They said they ended up with amazing products. But I said, "You know, what was the biggest benefit, or what stood out to you the most?" And they all said it was the people, you know, they loved the people. They loved learning from thoughtboters. They were, like, you know, teachers and mentors, and so smart, but also, like, very kind and helpful.

+ +

So, when you think about it like that, podcasts or videos and ways you're able to, like, better see and hear and feel the person on the other side is a really great way of, you know, continuing to make that connection with folks.

+ +

VICTORIA: I love that answer. I wish we had little heart emojis we could share, like in Google Meets with Zencastr. So, what do you think...Maybe this is a question for everyone on here, too, that we're asking is, like, where do you think we should go with the podcast? What should we change? What should we think about for future episodes?

+ +

LINDSEY: I think you should ask the listeners if possible. We tried, in the past, surveying. And it's hard because you don't have, like, necessarily an email list of listeners. But there does tend to be some overlap of, like, our newsletter subscribers with podcast listeners. So yeah, I'd go straight to the audience and just learn more about...ask them what they care about and what they want to learn. Because at the end of the day, it's really for them, providing value for them and something they want to come back to listen to week after week.

+ +

CHAD: Oh, when we've done the surveys in the past, we've had very few people [laughs] respond. So, you can always email us at hosts@giantrobots.fm if you have feedback on the show, questions for people, questions for the hosts, or opinions on, you know, who would make a great guest or a direction we should take the show. All that is super valuable. And we definitely would take it to heart.

+ +

VICTORIA: Yes, please send me your feedback. I will read your emails and incorporate it into the show. So, it'd be great. I wonder, Lindsey, do you have any questions for us?

+ +

LINDSEY: How do y'all like hosting the podcast? [laughs] How's it going?

+ +

WILL: I feel like I'm starting to find my style and the way that it works best for me, so that's exciting. I do want to engage more with the listener. So, that's one thing that I'm trying to brainstorm on what's the best way to do that. Also, you know, inviting just different types of guests, trying to think through what's some different type, a different angle that we can invite for the podcast? But as far as how do I like doing the podcast, I really enjoy it. It's pushed me out of my comfort zone. But it was a good thing for me. So, I'm really enjoying it.

+ +

LINDSEY: How long have you been doing it, Will?

+ +

WILL: A little over a year. So, I think I started after I went on parental leave with my youngest child. And then when I came back, I took a couple of weeks, and then I started. So yeah, about a year, a little over a year.

+ +

LINDSEY: That's fun. What's your favorite part about doing it?

+ +

WILL: I love talking to the guests. And I love learning, like, people's stories. And so, that has been the most exciting thing for me, like, because especially with the founders, like, it's not easy to be a founder. But people they go all out, and they make a difference. And even through the heartache, and the pain, and just all different levels, but they're willing to endure it because they believe in their product. They believe it's going to make a difference. So, I think the stories, the stories, and the people, meeting new people, and hearing their stories is what I love.

+ +

VICTORIA: And I'm the same as Will. I've been on the show for about a year now. And the first episode I recorded with Chad, I think afterwards, he said, "Oh, you didn't ask any questions [laughs]. Like, you were too quiet." But then I think I got a hang of it. And now I really like making people feel comfortable and opening up about their story and hearing, yeah, like the emotions and what it really felt like to go through that. Because, you know, if it's interesting for me to hear that, then I think that our audience will also appreciate it and to feel like you're not alone, right? To build that community and hear those same stories and people going through similar things.

+ +

Yeah, some of the guests that we've had on have just been really incredible. And they are people who I admire in the industry, and to have them on the show and to be a part of it has been really special.

+ +

LINDSEY: Yeah, that's cool. That reminds me another kind of underlying thing I love about the podcast and the interviewing. It's also low-key, like, market research [laughs], which is interesting, like, better understanding the types of people we provide services to and their kind of drivers and challenges. There's, like, an interesting element there. And yeah, at the end of the day, you get really interested and into it, and you're just, like, having a conversation with them, probably makes for the best kind of episode.

+ +

VICTORIA: Right. And then afterwards, you have to, like, pace around the room to, like, decompress [laughs] because you're operating at, like, such a level, at least, that happens to me; I don't know about anybody else.

+ +

LINDSEY: No, totally. I would also...if we had, like, an episode scheduled and then it got, like, rescheduled at the last second, I would find I had all this, like, pent-up energy that my body was, like, preparing me to, like, go into the interview.

+ +

VICTORIA: Yeah, sometimes I have to get hyped. Like, you got to do some movement right before because you got to get into the zone. But I'm curious, Chad, this is, you know, you've been a host for a number of years now, too. Like, how do you feel about the podcast? Do you still like hosting it?

+ +

CHAD: No [laughs]. I'm kidding. I have taken a little bit of a break recently from the ongoing continuous hosting because I was really busy. And it was hard to create the time and dedicate the time to it. But I really like hosting the show. I love talking to different people and learning about their stories. I also really like the episodes where it's able to be more of a conversation with people, and I get a lot of enjoyment out of that.

+ +

LINDSEY: We've seen, also, some trends in, like, the episodes where Chad will talk about, like, the business of thoughtbot perform well, too. Because I know there's, like, a lot of folks, who listen who also own agencies or consultancies and always appreciate Chad's transparency around how we run thoughtbot.

+ +

VICTORIA: That's interesting. And yeah, I think one of the ways that we've been experimenting with getting the episodes to be more conversational is to have more than one host in the episode. So, Chad or Lindsey, if you're ever wanting to rejoin an episode or invite a founder on and be one of the co-hosts, you're always welcome.

+ +

LINDSEY: I'm always down. I love talking. That actually...that does remind me we were thinking...we've been doing live streams that cover thoughtbot's new startup incubator. So, we have the second session currently in progress. But repurposing some of those live streams into, like, mini–Giant Robots episodes. So, that may happen soon. We may do a little bit of that and then give some insight into what it's like week in, week out for founders going through the startup incubator. It's super, super interesting if you're a startup nerd like me.

+ +

VICTORIA: That would be great, yeah. We did an episode with Agnes for the first incubator round, and I think that was really interesting. And something we've been experimenting with a little bit is having that diverse group of founders. So, there's founders from companies who the company has managed to survive and excel, and they've been around for ten years or so. Then there's other people who are just starting out. And, like, hearing those stories, too, and, like, the things they're thinking about and what challenges they're facing has been super interesting. Anything else you'd like to promote Lindsey?

+ +

LINDSEY: Hire me for all your marketing consulting needs.

+ +

CHAD: It was great to catch up with everyone in celebration of our 500th episode. Thank you to Ben, Chris, and Lindsey. But most of all, that you to you. We make the show, but you make the show possible.

+ +

You can subscribe to the show and find notes, along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm.
+This podcast is brought to you by thoughtbot, and produced and edited by Mandy Moore. Thanks for listening, and here’s to the next 500 episodes!

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rNLHpta7 + + ]]> + + Chad Pytel + Will Larry + Victoria Guido + + + thoughtbot's Incubator Program Mini Season 3 - Episode 02: Goodz with Mike Rosenthal and Chris Cerrito + https://podcast.thoughtbot.com/s3e2incubatorgoodz + b253d984-0f9b-481d-a798-822ae375d449 + Tue, 14 Nov 2023 00:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + This episode introduces the second participants of the season's thoughtbot's Incubator Program, Mike Rosenthal and Chris Cerrito. Mike has a background in music industry marketing, and Chris is a maker and tinkerer with experience in exhibit development. They're developing a product combining physical objects with digital content, starting with music. Their concept involves creating physical items like wooden mixtapes with NFC chips linking to digital playlists. This blend of physical and digital aims to revive the tangible aspects of fan engagement in a digital era. + +Their project, named Goodz, is the first pure consumer product in the Incubator program, adding complexities like supply chain and manufacturing considerations. The team is conducting user interviews to validate market interest and refine their messaging. They aim to have a functioning physical product and a supporting digital backend by the end of the program. Challenges include defining the target market and understanding how to attract customers to a new product type. The thoughtbot team is excited about the project due to its fun nature and technical aspects, offering a fresh perspective compared to problem-focused startups. + +The conversation also explores the broader implications of bridging the digital and physical worlds in fan engagement, with the potential to collect valuable data for artists and create lasting, meaningful connections for fans. + 33:35 + no + + + This episode introduces the second participants of the season's thoughtbot's Incubator Program, Mike Rosenthal and Chris Cerrito. Mike has a background in music industry marketing, and Chris is a maker and tinkerer with experience in exhibit development. They're developing a product combining physical objects with digital content, starting with music. Their concept involves creating physical items like wooden mixtapes with NFC chips linking to digital playlists. This blend of physical and digital aims to revive the tangible aspects of fan engagement in a digital era. +Their project, named Goodz, is the first pure consumer product in the Incubator program, adding complexities like supply chain and manufacturing considerations. The team is conducting user interviews to validate market interest and refine their messaging. They aim to have a functioning physical product and a supporting digital backend by the end of the program. Challenges include defining the target market and understanding how to attract customers to a new product type. The thoughtbot team is excited about the project due to its fun nature and technical aspects, offering a fresh perspective compared to problem-focused startups. +The conversation also explores the broader implications of bridging the digital and physical worlds in fan engagement, with the potential to collect valuable data for artists and create lasting, meaningful connections for fans. +Follow Josh Herzig-Marx on LinkedIn (https://www.linkedin.com/in/joshuaherzigmarx/) or X (https://twitter.com/herzigma). Visit his website at joshua.herzig-marx.com (https://joshua.herzig-marx.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +LINDSEY: All right. I'm going to kick us off here. Thanks, everyone, for tuning in. We're doing our first update with two founders that are now going through the Startup incubator at thoughtbot. thoughtbot, if you're not familiar, product design and development consultancy. We'll help you on your product and make your team a success. One of the very fun ways we do that is through the startup thoughtbot incubator, which is an eight-week program. +So, with us today, I myself am Lindsey Christensen, marketing for thoughtbot. We also have Jordyn Bonds, who is our Director of Product Strategy and runs the thoughtbot incubator. And then, as I mentioned, we've got two new founders who are going to tell us a little bit about themselves and what they're working on. Mike Rosenthal, let's kick off with you. Can you tell us a little bit about maybe your background and what brings you to present day? +MIKE: Sure. First of, thanks for having us. It's been a lot of fun doing this over the last [inaudible 01:03]; it's only two weeks, two and a half weeks, something like that. It feels like a lot more. I come from a music industry background, so worked in sort of marketing and strategy for artists for a long time; worked with a band called OK Go back, sort of starting in 2009 or so. +I did a lot of early kind of viral music video stuff. And we were sort of early to the idea of sort of leveraging fan engagement and revenue, honestly, kind of beyond sort of just selling their music and touring, so sort of exploring other ways that artists can make money and connect with their fans and was with those guys for five years. +And then, I went on and worked at an artist management company in Brooklyn called Mick Management and ran the marketing department there, so doing similar type of work but for a roster of 2025 major label bands. And so, really got to see fan engagement on all different levels, from really large bands down to baby bands who were just getting started. And then, yeah, started my first startup in 2018, so doing sort of fan engagement work, and NFTs, and blockchain-type stuff working with bands, but then also sports and entertainment properties. Yeah, that kind of brings me here. +So, always been sort of on the music side of things, which ties into a lot of what Chris and I are working on now, but more generally, sort of fan engagement and how to, you know, drive revenue and engagement for artists and deliver value for fans. +LINDSEY: Very interesting. All right, Chris, going to head over to you. Chris Cerrito, can you tell us a bit about your background? And it sounds like yours and Mike's paths; this isn't the first time you've crossed. +CHRIS: No. Mike and I have been working together since 2007, I believe. Yeah, that's a great place to start. I've always been kind of a maker and a tinkerer, always been interested in art materials, how things are put together. And that kind of culminated at grad school, where Mike and I met at NYU, where we both studied physical computing and human-computer interaction, making weird things that kind of changed the way that people interact and play with technology in their day-to-day lives. +I think the first project he and I worked on together was a solar robotic band that we played with light in front of a bunch of people. It was very wonderful and confusing at the same time. After grad school, I was lucky enough to become a resident artist and then an exhibit developer at a museum in San Francisco called the Exploratorium, which is a museum of science, art, and human perception. +I spent ten years there working on exhibits, teaching people things ranging from, let's see; I built a dueling water fountain to teach visitors and users about the prisoner's dilemma. I built a photo booth that used computer vision to teach people about the microbiome that lives on their face, like, just all kinds of weird things like that that fuse the digital and the physical worlds. I loved my time there. +And then kind of COVID hit, and I realized that everything I had been working on for ten years was locked up in a museum that I no longer had access to. And it really gave me a desire to kind of bring my ideas into the physical world. I wanted to make things that people interact with and use in their lives on a day-to-day basis. And I would say that's really what brought me here to this point. +LINDSEY: Very cool. Very interesting backgrounds, in my opinion. What is the new idea? What is the thing that you're bringing into the incubator? Mike, I'll start with you. Tell us a bit about what you're working on. +MIKE: Chris and I are working on physical objects that connect to digital content is sort of the broadest way that I could describe it. I think, you know, as Chris kind of mentioned, you know, we've both been working on sort of physical things that have interactivity for a lot of our careers. I think we both come from an era of a lot more physical objects in your life, whether that's, you know, VHS cassettes at your parent's house growing up, or records and tape cassettes, and just sort of physical things that remind you of the things that you love. +And I think that, you know, cell phones are great, and the sort of the smartphone era is amazing and having, you know, every single song, and movie, and television show and podcasts, et cetera, in a black box in my pocket is great. But I think we've sort of gotten to a point where it's more of an organizational problem now than anything else. And we sort of forget the actual things that we love in this world. +And so, we're working on basically making physical objects to tie to digital content, and we're starting with music. And that's what we've been working on at thoughtbot is sort of how we can create physical things that basically you can tap, and that will take you to streaming content. One of the first things we're working on literally looks like sort of a little mixtape on a piece of wood, and you can just load that up with any sort of playlist that you might have on Spotify, or Apple Music, or YouTube, or whatever, and tap it, and it will take you there. +And so, it's just sort of that idea of like, oh, we used to be able to sort of flip through a friend's music collection and judge them ruthlessly, or become even better friends with them based on kind of what you saw there. And we think that the time is ripe for, I don't know, a blend of that nostalgia with actual sort of, like, real-world utility that people could be into this right now. Chris, what am I missing there? +CHRIS: I'd say just to expand on that a little bit, it's, you know, we spend so much time in the digital world, but we still exist in the physical. And a lot of the things, like, you might spend a really long time editing a photo for your parents or making a playlist for a friend, and there's, like, a value there that might not translate because it's digital. It's ephemeral. And I think tying these digital assets to a physical thing makes them special. It gives them, like, a permanent place in your life, something to respect, to hold on to, and maybe even pass down at some point. +LINDSEY: Yeah, and I think before we logged on, we actually had Jordyn and Mike grabbing cassette tapes from the room there and to show us -- +MIKE: [inaudible 06:49] +LINDSEY: What [laughs] was some of their collection and to prove some of the power of these physical –- +MIKE: Nothing, like, just old mixtapes. +LINDSEY: Mementos. +MIKE: Yeah. We were just talking about this on our sync with the thoughtbot crew. They're, like, there's sort of two levels of nostalgia. There's nostalgia for people like us who, yeah, [crosstalk 07:09] mixtapes, right? For people who actually grew up with this stuff and still have it lying around or don't but, like, look at something like that that gives you, like, instant flashbacks, right? You're like, oh my God, I remember scrolling on that little j-card or, like, getting a mixtape for my first, you know, boyfriend or girlfriend, and having it just mean everything. So, there's people for whom that was a thing. +And there's, you know, generations of people for whom that is, like, their only connection to that is, you know, Stranger Things or, like, you know, the mixtape exists in pop culture as a reference. So, there's still, like, a very strong attachment there, but it's not a personal one, right? It's a cultural one. But I think everybody has that connection. So, that's kind of why we're starting with the mixtape, just because I think everyone can kind of relate to that in some way. +LINDSEY: Yeah, no, yeah. When I hear mixtape, it goes immediately to crushes. You make a mixtape for your crush. +CHRIS: Exactly. +LINDSEY: It's a huge, powerful market, powerful. +MIKE: Oh my God, so powerful. I mean, yeah, I don't know anybody -- +LINDSEY: What's more motivating? +MIKE: [laughs] Yeah, exactly. +CHRIS: Or even just I have a really good friend who I don't get to see as often as I'd like. And he and I are constantly sending each other, you know, Spotify links and text messages. And it's great. I love that interaction. But at the same time, you know, I might forget to add that to a playlist, and then it's kind of lost. If I had taken the time to make something and send it to him physically or vice versa, it just becomes so much more special and so much more real. +MIKE: Yeah. I mean, honestly, I first made these...I mean, we can go to this origin if we want. But, like, I literally just went on moo.com, right? The business card company. And they let you upload, you know, 50 different images, and they'll send you all of those as business cards. And so, I literally went on and just made business cards of all the album covers of, like, albums that I loved growing up, right? And their cheapest is this little piece of cardboard. But I had 50 of these, and I'd put them all out on my coffee table, just as something I wanted to have around. +And people kept coming, you know, friends would come over, and you would just have these conversations that I haven't had in 10 or 15 years, right? Because no one's going to come to my house and pick up my phone and look at my Spotify collection. But if these things are all just sitting out, they're like, "Oh shit, you're into that? Like, I haven't thought about that album in 15 years." Or like, "Oh, I didn't know you were into that. I'm, like, a crazy super fan of that artist as well." And all of a sudden, we're having these conversations that we just weren't having. Yeah, there's something there where it's all been nostalgia coupled with the kind of prompting of conversation and connection that we've kind of lost, I think. +CHRIS: And I think just to clarify a little bit on what Mike's saying, is, you know, this mixtape will be our first product launch, and then we're hoping to move into collectibles for artists and labels. So, shortly after we launch this tape, we're hoping to launch some kind of pilot with a label where you will be able to buy a version of this for your favorite music artist at a merch table in a concert, possibly online. Our dream is to have these sitting there on the table with T-shirts, and records, and other things that artists sell so you can express for the artists that you love. This is a way of expressing your fandom. +LINDSEY: Jordyn, heading over to you, this feels like maybe the first consumer product that has gone through the incubator, would you say? Or how do you think about it? +JORDYN: Yeah, if you're a consumer -- +LINDSEY: Or is it different than other types of products? +JORDYN: Yeah, the first incubator project we did with Senga was, I think, what you would call prosumer. So, it was sort of a consumer thing but directed at folks who had kind of freelancing in sort of a business context. It's got a lot of dynamics of the consumer. But this one, for sure, is the first pure consumer play. Though now that I'm thinking about it, you know, AvidFirst had some consumer elements to it, but it was, you know, it was, like, more complex tech [laughs] [inaudible 10:46] totally different thing -- +LINDSEY: But definitely the first of the physical, physical [inaudible 10:52] +JORDYN: Oh, sure, the first of the physical thing. Right. Absolutely. +LINDSEY: Does that change any of, like, the approach of the programming, or it's kind of -- +JORDYN: I mean, no, not fundamentally, though it does add this layer of operations that you don't have with a pure software play. So, we have to be, there is a thing that needs to get shipped to people in the world, and that takes timelines, and it takes -- +LINDSEY: Supply chain. +JORDYN: Yeah, exactly. And Chris is doing most of that stuff. I don't want to, you know, this is not, like, the main focus of our team necessarily, but it intersects, right? So, this isn't the first one of these types of products I've worked on personally in my career. But there's something, like, really, for me, very fulfilling about, like, there's software. There's a big component of software. There's also this physical object that needs to exist in the world. +And partly, what's so compelling about Goodz is that it gives you the promise of a physical, like, the sort of good aspects of a physical product, a thing you can hold in your hand and look at and really connect with in that physical way. But it has this dynamic digital, like, essential quality as well. So, it's very compelling as a product because it sort of marries the things that we like about both the physical world and the digital world, which is partly why the team was really excited about working on it [laughs]. +LINDSEY: Well, that was going to be my next question is, you know, what stood out to you about the Goodz application for the incubator and the interview process that made you and the team feel like this was going to be a great project to work on? +JORDYN: Yeah. So, I think just the team really resonated with the sort of idea in general, and it seemed fun. There was, like, it's a very positive thing, right? It isn't so much about solving problems and pain points. And, sometimes the, you know, when you're very focused on solving problems, it can feel a little doomy because you actually have to, like, immerse yourself in the problems of the people that you're making software for. And sometimes, you start to feel like the world is just full of problems. +What Goodz is doing is sort of it is solving a problem in a sense, but not in that kind of way. It's really, like, a fun upside kind of thing, which I think a lot of the folks on the team were very excited about. But, like, the software component, actually, is very interesting to us from a technological standpoint as well. There's a lot of opportunity here to do interesting things on the backend with an object that's essentially functioning as a bookmark out in the world. What all can you do with that? There's something super compelling and technically interesting about it. +And I think, also, the team was just sort of excited by Chris and Mike, you know, the energy and the kind of background they were bringing to the table was also super interesting. And then, above all else, what I say every time you ask me this question, which is stage fit, y'all, good stage fit. They're right at the beginning. They haven't built the product yet [laughs]. Gotta say it. It's a good stage fit. They know who they're building for broadly but not super specifically. Got a good vision but, like, haven't made that first step with the software. Perfect stage fit for us [laughs]. +LINDSEY: Great. So, Chris, we were talking a bit before about how you two have been collaborators in the past, worked on business ideas before. Why bring this idea into the thoughtbot incubator? What are you hoping to, you know, achieve? +CHRIS: One of the main reasons why we wanted to bring this into the incubator was just for support, momentum, and then, also, I would say, validation for our idea. I mean, we came to the incubator with a very, yeah, I would say it was a fairly developed idea that needed to be proved, and we, quite frankly, needed help with that. You know, Mike and I have our own expertises, but we don't know how to do everything. We're more than willing to jump in where we need to go. +But having people with expertise to work with has proven to be incredibly helpful, and just having kind of fresh faces to bat ideas around with after he and I have been staring at each other for months now on Zoom calls and meetings. And just, you know, being able to talk about these ideas with fresh faces and new people and get new perspectives has been so very, very helpful. +I think something that's also great from the momentum standpoint is that because there's a time limit to this experience, we've got the time that we have with you guys, and we've been able to set goals that I think are very achievable for things we want to occur in the next couple of months, and it feels like we're going to get there. +And I think by the end of this, I mean, our hope, and I think we're on track, is to have a functioning physical product that we're going to offer to consumers with a digital backend to support it, which is, in my mind, amazing. That'll totally validate this idea and prove if we have something or not. +LINDSEY: I was going to ask if you're open to sharing what those goals specifically are. Is that it? Is it that by the end, you have -- +MIKE: Is that it? Lindsey, that's a lot. +[laughter] +CHRIS: It's a lot. I mean, yeah. I mean, we're going to have a physical object in the world that you can buy via an e-commerce site -- +JORDYN: Sounds like we need Lindsey on the team if Lindsey feels like this is so achievable. [laughter] +CHRIS: Yeah, yeah. Lindsey...yeah. We're in the beginning [crosstalk 15:47] +LINDSEY: I meant, is that the goal? +CHRIS: That is the goal. +LINDSEY: Is that all? +CHRIS: I was going to –- +LINDSEY: Is that all you got? +CHRIS: Mike, do you agree? +MIKE: Yeah. Is that the goal? Yes, that is the goal. I mean, you know, when we sat down with the thoughtbot team kind of week one, you know, they're sort of like, "All right, let's define kind of the experiment." So, we refer to them as experiments, which I think is helpful because, like, what are the experiments that we want to be doing during our time here? And, you know, we talked about it a lot. +And yeah, I think it's, you know, having a physical product out in the world, having a website in which to sell it. But also, it's really like Chris was saying, it's like, it's market validation, and just making sure we actually have something that people want. It's like, you know, running a startup takes so long and, like [laughs], you know, you'll do it for so many years. It's like bands when people say, like, "Oh, that's an overnight sensation." It's like, you know, that band has been slogging it out in tiny, little venues for four years before you ever heard of them. +It's like, that's what so much of the startup world feels like to me, too. It's like, "Oh, you're just getting started as a startup?" It's like, "Well, we've been working on this forever." And I know how long this can take. And so, I think we want to learn as early as possible, like, is this something people actually want? Because if they don't, like, we'll just go do something else. I don't want to spend years making something that people don't want. +So, I think the biggest goal, for me, is just validation, and then that is sort of how we get there is like, okay, how do we validate this? Cool. Let's identify some, you know, assumptions of personas that we think are people who do actually want this and then try to go sell it to them. And all the implications from that are, okay, well, you need a website where somebody can buy it. You need a physical product that somebody can actually buy. So, all those things sort of come out of that, but, for me, it's like, proving that assumption, is this thing real? Do people actually want this? And everything else is like, okay, how do we prove that? +LINDSEY: Jordyn, what does that look like in these first few weeks here? User interviews, I assume, how are the user interviews going? +JORDYN: Always. Always. So, you know, we kick it off by just, like, doing the exercise where we list everybody who might want this. And the team, you know, it's a fun product. Everybody brought their own assumptions and ideas to the table on that. You know, we had a lot of different scenarios we were imagining. It's super fun getting that stuff out of people's heads, just, like, what are we all thinking? +And then, you know, we get to negotiate, like, okay...I always encourage everyone to think, like, if everyone else on the team was on the moon, you had to make a decision about a market segment to pick; which one would you pick? And then we kind of argue about it in a productive way. It really helps us get at, like, what are the dynamics that we think matter upfront? And then we pick one, or, in this case, we have a few. We have a handful. +And we're running interview projects where we just recruit people to talk about people that meet this persona, talk about a specific problem. We're in the middle of that right now. And it's fun, fantastic. These conversations are super interesting. We're validating a lot of the things that Mike and Chris, you know, walked into this with, but we're learning a bunch of new things as well. +And, like, really, part of the aim there is to validate that there's a hole in the market that we might fill but also to hear the language people are using to describe this stuff. So, when people talk about buying music, merch, you know, making playlists, et cetera, like, what language do they use to talk about that? So that we make sure we're speaking the language that our customer uses to describe this stuff. And we're, you know, we're right in the pocket of doing that, learning stuff all the time. +And it helps us kind of hone the messaging. It helps us know where to go talk to people about it, how to talk about it, but it's, you know, it all kind of fits together. And it's just this, really...the early stages. It's just a bunch of us in a room, a virtual room, in this case, sort of, like, tossing ideas around. But out of it crystallizes this sense of alignment about who this is for, how to talk to them about it, and with a goal. +And, you know, Mike and Chris walked in with the exact right mindset about this, which is, yes, it's experiments. We need to validate it. Let's make sure there's a there-there. If there's a there-there, let's figure out where it is [laughs], like, all those things. And we're running these experiments, and it was really [inaudible 19:36]. We got down to business quite quickly here. It was really great. +LINDSEY: Like you said, it's not necessarily a problem or, you know, the typical framing of a problem. How do you start those user interview questions around this? Do you feel a gap between the physical and the digital sound? [laughter] +JORDYN: No, no. +LINDSEY: It's maybe not it [laughs]. +JORDYN: Yeah, no. Well, I can tell you what our startup questions are. One of them is, tell me about the last time you bought music merch. Go for it, Lindsey. Tell us. +LINDSEY: The last time I bought music merch, I went to a Tegan and Sara concert a few weeks ago, and I bought a T-shirt. +JORDYN: Tell me about buying that T-shirt. Why'd you buy it? +LINDSEY: Because I wanted to remember the show and my time with my friends, and I wanted to support the artists. I know that buying merch is the best way to support your favorite touring artists. +JORDYN: So, it's just, you know, we could spend the rest of this time talking [laughter] [crosstalk 20:34], and it would be awesome. So, it's really a lot of things like that. +LINDSEY: Gotcha. +JORDYN: You don't ask, "What problem are you trying to solve by buying this t-shirt?" Right? Like, that's not, you know, but we ask you to tell us a bunch of stories about when you did this recently. You know, and if you make playlists for friends, you know, that's a different persona. But we would have asked, you know, like, "Tell me about the last playlist you made. You know, who did you share it with? You know, what happened after that? What happened after that? What happened after that?" It's a lot of questions like that. And there's just nothing better. People love to tell you what's going on with them. And it's great [laughs]. +LINDSEY: Yeah. As you all have been doing these interviews, Mike and Chris, have you been surprised by anything? Any interesting insights that you're seeing already? +CHRIS: I mean, I haven't done really much in the way of user interviews in the past. This is a really new experience for me. And then we're, obviously, not on the calls because that would be weird and probably intimidating for people. But we're getting lots of highlights from folks who are doing them, you know, in our daily sync. +And I'm surprised at how many, like, really intense, like, playlist nerds we have found even just in, like, the few people we've talked to, like, in the best possible way. Like, people who are like, "I make playlists all the time." Like, you're talking about, like, a vinyl fan or, like, a...Jordyn, what's the story? It's, like, the guy who there was so much out-of-print vinyl that he started a vinyl label just to get the albums in vinyl. [crosstalk 21:56] +JORDYN: Yeah. There were a bunch of releases that he feels really passionately about that were never released on vinyl that he knew would never be released on vinyl. And so, he started a vinyl record label. And we just found this guy [laughter]. +CHRIS: Is that indicative that that's, like, an entire persona we're going to, like, target? Absolutely not. But it's just, like, it's amazing that even just in the few user interviews we've done, that we've found so many very passionate people. And it's sent me down, like, a TikTok rabbit hole of, like, TikTok, like, music nerd influencer-type folks who are posting playlists. +And they, like, hundreds of thousands of likes on these videos that are literally just, like, screen with text on it that you're supposed to, like, pause the video [laughs] and, like, look at, like, the songs that they're recommending. And it's like, who does that? And it was like, these people do that. And it's like, so there are...it's been very encouraging to me, actually. I was worried that we were going to find not as much passion as we had suspected, and I think the opposite has proven to be true. So, it's exciting. +CHRIS: Yeah, I completely agree with Mike. It's been so encouraging. I think, for me, what we're doing is an idea that I'm very excited about and have been very excited about for a long time. But hearing the responses that we're getting makes me confident in the idea, too. That's great. I mean, I think that is everything that a founder needs, you know, is excitement and confidence. +MIKE: Well, and just the whole user interview experience has, like, made a lot of my other conversations sort of I've tried to frame parts of them as user interviews because I'm talking to a lot of, like, label folks now, and artists, merch people. And, you know, I ended up just sort of, like, asking them, I mean, yes, trying to explain the product and work on kind of partnership stuff, but a lot of it is really just geeking out with them. And just, like, hearing their thoughts about, like, what they love about merch because these are people that clearly think about this stuff all the time. So, it's definitely kind of, like, tuned my other conversations into trying to get unbiased feedback. +LINDSEY: Yeah. Everything is a little user interview now. +MIKE: Yeah, exactly. +LINDSEY: Get that angle in there. All right, so some early validation and excitement. That's really cool to hear. Any challenges or, you know, other kinds of learnings early on? Anything that's been invalidated? +MIKE: I don't know that we're there yet. [inaudible 24:02] Chris, I don't know. I'm happy to find that some things are invalidated, but I don't really feel...you know, some of the personas that we decided or maybe just one of the personas we decided to pursue, I think we're having a hard time having those user interviews kind of really bear fruit, but that's helpful, too, actually. I mean, it's like, okay, well, maybe that's not a group that we target. +JORDYN: Yeah. It's about, like, [inaudible 24:24]. I encourage folks not to think about this like a 'no, not that,' and instead think of it as like a 'not yet.' And that's, I think, the dynamic here with a couple of the personas we were interested in. It's just been turned into kind of, like, a not yet for reasons that we very quickly figured out, but we'll get there. It's just a matter of figuring out we had some other personas take precedence because they're more sort of red, hot in a way, right? It's just easier to get in contact with these people, or it's, like, clear what they're going for or what they need from the market. +So, you know, we have this whole list, and it was not clear at first who was going to kind of stand out. But we've kind of found some focus there, which means, invariably, that there's things that are falling out of the frame for now, and you're kind of de-prioritizing them. But it really is, like, a we'll get to that [laughs]. We'll eventually get to that. +LINDSEY: Yeah. And part of the process, who's going to rise to the top right now? +JORDYN: Yeah, exactly. +LINDSEY: Do you have anything you can show and tell with us today or not yet? +MIKE: So, Chris has been hard at work on all the physical side of this stuff and going back and forth with our manufacturing partner and all that good stuff. But we have a final version of the mixtape product. +LINDSEY: For when this gets pulled into the podcast, Mike's showing us a physical card. +CHRIS: It's a small card, and we call them Goodz. And it's printed on three-millimeter plywood using a UV printing process, super durable. And this is something you can put in your pocket. You're not going to wreck it. I think you could actually (Don't quote me on this.), but I think you can even, like, put it through a washing machine, and it would be fine. Embedded in this card is a chip that can be read by your phone, and that's pretty much what we're working with. +MIKE: Yeah, so the idea is you just sort of tap this, and it'll take you to a streaming version of a playlist. And then Chris has also been making these adorable crates. And [crosstalk 26:10] +LINDSEY: The little crates I love. +MIKE: And we actually have some wooden ones, too, in the testing that's [crosstalk 26:15] +LINDSEY: And then the mixtapes get stored in the little crates [crosstalk 26:19] +MIKE: Yeah. So, you could have -- +LINDSEY: Throw it on your desk. +CHRIS: Each crate can hold about, I think, 15 of these things. What's really cool about this product on the physical side is we are using a tried-and-true technology, which is NFC chips. These are things that make Apple Pay work, make Google Pay work. They are in your E-ZPass when you drive through a toll booth. This is stuff that's been around for years. So, we're just kind of leveraging this technology that's been around for so long in a new way. +MIKE: Yeah, I think it's similar to kind of the evolution of QR codes, right? It's like they were sort of around forever, and then it was, like, COVID and restaurant menus kind of kicked those into mainstream. Like, NFC has been around for a long time. It's very tried and true. It's affordable. But I want to say Apple only turned it on by default, like, the NFC reader in the iPhone in the last, like, 18 to 24 months, right? Like, it started...like, it's been around for a while, but they're sort of slowly kind of...and now you just sort of see it everywhere. People are using it on the subways in New York to scan for tickets or for accessing stuff. +I was also just showing Chris has been prototyping with the ability to sort of keep these on a key ring. So, we have, like, a little chain hole on them. It is [inaudible 27:22] to sort of have this on your backpack or, you know, on a key ring, or something like that. And friends could kind of, like, come up to you and just, like, scan one that looks interesting. +CHRIS: And yeah, something that's awesome about this is you don't need an app. You don't need to download anything. As long as your NFC reader is on when you scan this, it will bring you to the music that it's linked to, which I think is awesome. So, I mean, my dream is to have these, like, hanging off of people's backpacks so I can, like, scan them in the subway or, you know, it's such, like, an easy thing to do. And it requires so little technical time on the user's end to be able to do it. +LINDSEY: Oh, we got a question here. "So, Moo used to offer NFC cards. What made you decide to do the thicker plywood model?" +CHRIS: Durability is really what it comes down to. We wanted something that felt like an object that you can have and treasure. Like, these have weight, you know, these feel like something, not just a piece of paper. This is something that you can have and [inaudible 28:22] your desk, and it's not going to fade in the sunlight. It's not going to disintegrate over time. This is something that's going to last. +MIKE: Yeah, the cards would definitely, like, as I would sort of carry them around and show them to people and stuff, the cards would start, you know, breaking. It's like having a business card in your pocket, right? Eventually, it's going to kind of wear out. And plus, we had, like, the stickers were visible on the back of them. And we were, like, having the sticker just completely disappear inside the wood; it just feels a little bit more like magic. +LINDSEY: Well, thanks for demoing there. I put you on the spot a little bit. But they are...I had seen them in the Slack, and they're very cool [laughs]. So, I had to ask if we could show them off a bit. +MIKE: Of course. +CHRIS: I think another thing to think about, too, is we've been talking a lot about the user experience. But if and when we get to the point of making these for artists, artists will be able to collect so much data off of the way that people buy and collect and use these things over time, which is something that we're really, really excited about. And also, you know, we're working on a way to make the link in the object updatable over time. So, artists will be able to change what a card points do to inform their users about the latest and greatest thing. +LINDSEY: Very cool. Jordyn, what's next on the programming agenda for Chris and Mike? +JORDYN: It's really sort of we're in this, like, iterative cycle. So, we're talking to folks. We're working on the website. The conversations we're having with people are informing how we're framing this first experiment with the mixtape, how we're marketing it, who we're marketing it to. I think next up is probably a Google Ad experiment to really see if we can piggyback on some stuff or at least figure out a new consumer product. It's so tough, right? +It's also not a thing people are searching for. So, we have to come up with some experiments for how we get people to that website [laughs]. So, you know, Google Ads funnels is just something you kind of have to do because it's very interesting to figure out what people are responding to, what people are searching for. But we're going to have a bunch of other experiments as well and non-experiments. Outbound experiments: can we go to people? Can we get listed in a gift-buying guide for the holidays? Or, like, we don't know. There's a bunch of experiments we need to do around that, which is really just this iteration. +We won't stop talking to users, but, you know, everything we're hearing from them will inform where we go and how we talk to the folks in those places where we end up. And really, it's just about starting...once this is up and, you know, there's, like, an orderable thing, there's, like, a whole data cycle where we start to learn from the stuff we're testing; we actually have some real data for it, and we can start to tweak, iterate and change our strategy. +But the bigger thing, also, is this bigger platform. So, the next thing really, the big next thing, is to sort of start to scope and create an architecture idea. What's it going to take to build the actual backend thing? And it's the thing that thoughtbot really [laughs] excels at, which is software. So, you know, that's the big next kind of project. Once the mixtape experiment is sort of out and in flight and we're getting data, we really need to turn our attention to the technical backend. +LINDSEY: Exciting. Another comment/question from Jeff, who maybe needs a user interview. "Love the crate more than the actual albums. Maybe offer collections of artists." +MIKE: Yeah, that's the plan. +CHRIS: Yeah, definitely. It's a good idea. Yeah, it's, I mean, and labels get to, especially, like, small indie labels get really excited about doing, like, crates worth of collections of different artists or, like, you know, digging through their back catalog, their subscription services. There's a lot of different angles for sure about that idea. +LINDSEY: [inaudible 31:55] Chris and Mike, going into this next section of the programming, for anyone watching right now, or watching the recording, or listening to the recording, any action items from them? You know, are you looking for any user interviews or have any survey or any destinations you'd like to send people yet? +CHRIS: Not quite yet, but soon, I would say. Well -- +MIKE: I mean, [inaudible 32:19] plug the website, I mean, you know, I think we've got, like, an email to sign up from there, right? The URL is getthegoodz.com and I [crosstalk 32:27] +LINDSEY: Goodz with a Z. +MIKE: Goodz with a Z. +CHRIS: With Z. +MIKE: So yeah, if you want to go there, you can sign up. I think there's an email signup on there to learn more. +LINDSEY: Perfect. All right. getthegoodz.com email sign up. To stay up to date on Goodz and the incubator, you can follow along on the thoughtbot blog. You know, as always, send us any questions you might have, and we're happy to get to those. But otherwise, thanks for listening. +And thank you all — Jordyn, Chris, and Mike. Thanks so much for joining today and sharing and being open about your stories so far. +MIKE: Thank you. +CHRIS: Yeah, thank you, Lindsey. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Chris Cerrito and Mike Rosenthal. + + + This episode introduces the second participants of the season's thoughtbot's Incubator Program, Mike Rosenthal and Chris Cerrito. Mike has a background in music industry marketing, and Chris is a maker and tinkerer with experience in exhibit development. They're developing a product combining physical objects with digital content, starting with music. Their concept involves creating physical items like wooden mixtapes with NFC chips linking to digital playlists. This blend of physical and digital aims to revive the tangible aspects of fan engagement in a digital era.

+ +

Their project, named Goodz, is the first pure consumer product in the Incubator program, adding complexities like supply chain and manufacturing considerations. The team is conducting user interviews to validate market interest and refine their messaging. They aim to have a functioning physical product and a supporting digital backend by the end of the program. Challenges include defining the target market and understanding how to attract customers to a new product type. The thoughtbot team is excited about the project due to its fun nature and technical aspects, offering a fresh perspective compared to problem-focused startups.

+ +

The conversation also explores the broader implications of bridging the digital and physical worlds in fan engagement, with the potential to collect valuable data for artists and create lasting, meaningful connections for fans.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: All right. I'm going to kick us off here. Thanks, everyone, for tuning in. We're doing our first update with two founders that are now going through the Startup incubator at thoughtbot. thoughtbot, if you're not familiar, product design and development consultancy. We'll help you on your product and make your team a success. One of the very fun ways we do that is through the startup thoughtbot incubator, which is an eight-week program.

+ +

So, with us today, I myself am Lindsey Christensen, marketing for thoughtbot. We also have Jordyn Bonds, who is our Director of Product Strategy and runs the thoughtbot incubator. And then, as I mentioned, we've got two new founders who are going to tell us a little bit about themselves and what they're working on. Mike Rosenthal, let's kick off with you. Can you tell us a little bit about maybe your background and what brings you to present day?

+ +

MIKE: Sure. First of, thanks for having us. It's been a lot of fun doing this over the last [inaudible 01:03]; it's only two weeks, two and a half weeks, something like that. It feels like a lot more. I come from a music industry background, so worked in sort of marketing and strategy for artists for a long time; worked with a band called OK Go back, sort of starting in 2009 or so.

+ +

I did a lot of early kind of viral music video stuff. And we were sort of early to the idea of sort of leveraging fan engagement and revenue, honestly, kind of beyond sort of just selling their music and touring, so sort of exploring other ways that artists can make money and connect with their fans and was with those guys for five years.

+ +

And then, I went on and worked at an artist management company in Brooklyn called Mick Management and ran the marketing department there, so doing similar type of work but for a roster of 2025 major label bands. And so, really got to see fan engagement on all different levels, from really large bands down to baby bands who were just getting started. And then, yeah, started my first startup in 2018, so doing sort of fan engagement work, and NFTs, and blockchain-type stuff working with bands, but then also sports and entertainment properties. Yeah, that kind of brings me here.

+ +

So, always been sort of on the music side of things, which ties into a lot of what Chris and I are working on now, but more generally, sort of fan engagement and how to, you know, drive revenue and engagement for artists and deliver value for fans.

+ +

LINDSEY: Very interesting. All right, Chris, going to head over to you. Chris Cerrito, can you tell us a bit about your background? And it sounds like yours and Mike's paths; this isn't the first time you've crossed.

+ +

CHRIS: No. Mike and I have been working together since 2007, I believe. Yeah, that's a great place to start. I've always been kind of a maker and a tinkerer, always been interested in art materials, how things are put together. And that kind of culminated at grad school, where Mike and I met at NYU, where we both studied physical computing and human-computer interaction, making weird things that kind of changed the way that people interact and play with technology in their day-to-day lives.

+ +

I think the first project he and I worked on together was a solar robotic band that we played with light in front of a bunch of people. It was very wonderful and confusing at the same time. After grad school, I was lucky enough to become a resident artist and then an exhibit developer at a museum in San Francisco called the Exploratorium, which is a museum of science, art, and human perception.

+ +

I spent ten years there working on exhibits, teaching people things ranging from, let's see; I built a dueling water fountain to teach visitors and users about the prisoner's dilemma. I built a photo booth that used computer vision to teach people about the microbiome that lives on their face, like, just all kinds of weird things like that that fuse the digital and the physical worlds. I loved my time there.

+ +

And then kind of COVID hit, and I realized that everything I had been working on for ten years was locked up in a museum that I no longer had access to. And it really gave me a desire to kind of bring my ideas into the physical world. I wanted to make things that people interact with and use in their lives on a day-to-day basis. And I would say that's really what brought me here to this point.

+ +

LINDSEY: Very cool. Very interesting backgrounds, in my opinion. What is the new idea? What is the thing that you're bringing into the incubator? Mike, I'll start with you. Tell us a bit about what you're working on.

+ +

MIKE: Chris and I are working on physical objects that connect to digital content is sort of the broadest way that I could describe it. I think, you know, as Chris kind of mentioned, you know, we've both been working on sort of physical things that have interactivity for a lot of our careers. I think we both come from an era of a lot more physical objects in your life, whether that's, you know, VHS cassettes at your parent's house growing up, or records and tape cassettes, and just sort of physical things that remind you of the things that you love.

+ +

And I think that, you know, cell phones are great, and the sort of the smartphone era is amazing and having, you know, every single song, and movie, and television show and podcasts, et cetera, in a black box in my pocket is great. But I think we've sort of gotten to a point where it's more of an organizational problem now than anything else. And we sort of forget the actual things that we love in this world.

+ +

And so, we're working on basically making physical objects to tie to digital content, and we're starting with music. And that's what we've been working on at thoughtbot is sort of how we can create physical things that basically you can tap, and that will take you to streaming content. One of the first things we're working on literally looks like sort of a little mixtape on a piece of wood, and you can just load that up with any sort of playlist that you might have on Spotify, or Apple Music, or YouTube, or whatever, and tap it, and it will take you there.

+ +

And so, it's just sort of that idea of like, oh, we used to be able to sort of flip through a friend's music collection and judge them ruthlessly, or become even better friends with them based on kind of what you saw there. And we think that the time is ripe for, I don't know, a blend of that nostalgia with actual sort of, like, real-world utility that people could be into this right now. Chris, what am I missing there?

+ +

CHRIS: I'd say just to expand on that a little bit, it's, you know, we spend so much time in the digital world, but we still exist in the physical. And a lot of the things, like, you might spend a really long time editing a photo for your parents or making a playlist for a friend, and there's, like, a value there that might not translate because it's digital. It's ephemeral. And I think tying these digital assets to a physical thing makes them special. It gives them, like, a permanent place in your life, something to respect, to hold on to, and maybe even pass down at some point.

+ +

LINDSEY: Yeah, and I think before we logged on, we actually had Jordyn and Mike grabbing cassette tapes from the room there and to show us --

+ +

MIKE: [inaudible 06:49]

+ +

LINDSEY: What [laughs] was some of their collection and to prove some of the power of these physical –-

+ +

MIKE: Nothing, like, just old mixtapes.

+ +

LINDSEY: Mementos.

+ +

MIKE: Yeah. We were just talking about this on our sync with the thoughtbot crew. They're, like, there's sort of two levels of nostalgia. There's nostalgia for people like us who, yeah, [crosstalk 07:09] mixtapes, right? For people who actually grew up with this stuff and still have it lying around or don't but, like, look at something like that that gives you, like, instant flashbacks, right? You're like, oh my God, I remember scrolling on that little j-card or, like, getting a mixtape for my first, you know, boyfriend or girlfriend, and having it just mean everything. So, there's people for whom that was a thing.

+ +

And there's, you know, generations of people for whom that is, like, their only connection to that is, you know, Stranger Things or, like, you know, the mixtape exists in pop culture as a reference. So, there's still, like, a very strong attachment there, but it's not a personal one, right? It's a cultural one. But I think everybody has that connection. So, that's kind of why we're starting with the mixtape, just because I think everyone can kind of relate to that in some way.

+ +

LINDSEY: Yeah, no, yeah. When I hear mixtape, it goes immediately to crushes. You make a mixtape for your crush.

+ +

CHRIS: Exactly.

+ +

LINDSEY: It's a huge, powerful market, powerful.

+ +

MIKE: Oh my God, so powerful. I mean, yeah, I don't know anybody --

+ +

LINDSEY: What's more motivating?

+ +

MIKE: [laughs] Yeah, exactly.

+ +

CHRIS: Or even just I have a really good friend who I don't get to see as often as I'd like. And he and I are constantly sending each other, you know, Spotify links and text messages. And it's great. I love that interaction. But at the same time, you know, I might forget to add that to a playlist, and then it's kind of lost. If I had taken the time to make something and send it to him physically or vice versa, it just becomes so much more special and so much more real.

+ +

MIKE: Yeah. I mean, honestly, I first made these...I mean, we can go to this origin if we want. But, like, I literally just went on moo.com, right? The business card company. And they let you upload, you know, 50 different images, and they'll send you all of those as business cards. And so, I literally went on and just made business cards of all the album covers of, like, albums that I loved growing up, right? And their cheapest is this little piece of cardboard. But I had 50 of these, and I'd put them all out on my coffee table, just as something I wanted to have around.

+ +

And people kept coming, you know, friends would come over, and you would just have these conversations that I haven't had in 10 or 15 years, right? Because no one's going to come to my house and pick up my phone and look at my Spotify collection. But if these things are all just sitting out, they're like, "Oh shit, you're into that? Like, I haven't thought about that album in 15 years." Or like, "Oh, I didn't know you were into that. I'm, like, a crazy super fan of that artist as well." And all of a sudden, we're having these conversations that we just weren't having. Yeah, there's something there where it's all been nostalgia coupled with the kind of prompting of conversation and connection that we've kind of lost, I think.

+ +

CHRIS: And I think just to clarify a little bit on what Mike's saying, is, you know, this mixtape will be our first product launch, and then we're hoping to move into collectibles for artists and labels. So, shortly after we launch this tape, we're hoping to launch some kind of pilot with a label where you will be able to buy a version of this for your favorite music artist at a merch table in a concert, possibly online. Our dream is to have these sitting there on the table with T-shirts, and records, and other things that artists sell so you can express for the artists that you love. This is a way of expressing your fandom.

+ +

LINDSEY: Jordyn, heading over to you, this feels like maybe the first consumer product that has gone through the incubator, would you say? Or how do you think about it?

+ +

JORDYN: Yeah, if you're a consumer --

+ +

LINDSEY: Or is it different than other types of products?

+ +

JORDYN: Yeah, the first incubator project we did with Senga was, I think, what you would call prosumer. So, it was sort of a consumer thing but directed at folks who had kind of freelancing in sort of a business context. It's got a lot of dynamics of the consumer. But this one, for sure, is the first pure consumer play. Though now that I'm thinking about it, you know, AvidFirst had some consumer elements to it, but it was, you know, it was, like, more complex tech [laughs] [inaudible 10:46] totally different thing --

+ +

LINDSEY: But definitely the first of the physical, physical [inaudible 10:52]

+ +

JORDYN: Oh, sure, the first of the physical thing. Right. Absolutely.

+ +

LINDSEY: Does that change any of, like, the approach of the programming, or it's kind of --

+ +

JORDYN: I mean, no, not fundamentally, though it does add this layer of operations that you don't have with a pure software play. So, we have to be, there is a thing that needs to get shipped to people in the world, and that takes timelines, and it takes --

+ +

LINDSEY: Supply chain.

+ +

JORDYN: Yeah, exactly. And Chris is doing most of that stuff. I don't want to, you know, this is not, like, the main focus of our team necessarily, but it intersects, right? So, this isn't the first one of these types of products I've worked on personally in my career. But there's something, like, really, for me, very fulfilling about, like, there's software. There's a big component of software. There's also this physical object that needs to exist in the world.

+ +

And partly, what's so compelling about Goodz is that it gives you the promise of a physical, like, the sort of good aspects of a physical product, a thing you can hold in your hand and look at and really connect with in that physical way. But it has this dynamic digital, like, essential quality as well. So, it's very compelling as a product because it sort of marries the things that we like about both the physical world and the digital world, which is partly why the team was really excited about working on it [laughs].

+ +

LINDSEY: Well, that was going to be my next question is, you know, what stood out to you about the Goodz application for the incubator and the interview process that made you and the team feel like this was going to be a great project to work on?

+ +

JORDYN: Yeah. So, I think just the team really resonated with the sort of idea in general, and it seemed fun. There was, like, it's a very positive thing, right? It isn't so much about solving problems and pain points. And, sometimes the, you know, when you're very focused on solving problems, it can feel a little doomy because you actually have to, like, immerse yourself in the problems of the people that you're making software for. And sometimes, you start to feel like the world is just full of problems.

+ +

What Goodz is doing is sort of it is solving a problem in a sense, but not in that kind of way. It's really, like, a fun upside kind of thing, which I think a lot of the folks on the team were very excited about. But, like, the software component, actually, is very interesting to us from a technological standpoint as well. There's a lot of opportunity here to do interesting things on the backend with an object that's essentially functioning as a bookmark out in the world. What all can you do with that? There's something super compelling and technically interesting about it.

+ +

And I think, also, the team was just sort of excited by Chris and Mike, you know, the energy and the kind of background they were bringing to the table was also super interesting. And then, above all else, what I say every time you ask me this question, which is stage fit, y'all, good stage fit. They're right at the beginning. They haven't built the product yet [laughs]. Gotta say it. It's a good stage fit. They know who they're building for broadly but not super specifically. Got a good vision but, like, haven't made that first step with the software. Perfect stage fit for us [laughs].

+ +

LINDSEY: Great. So, Chris, we were talking a bit before about how you two have been collaborators in the past, worked on business ideas before. Why bring this idea into the thoughtbot incubator? What are you hoping to, you know, achieve?

+ +

CHRIS: One of the main reasons why we wanted to bring this into the incubator was just for support, momentum, and then, also, I would say, validation for our idea. I mean, we came to the incubator with a very, yeah, I would say it was a fairly developed idea that needed to be proved, and we, quite frankly, needed help with that. You know, Mike and I have our own expertises, but we don't know how to do everything. We're more than willing to jump in where we need to go.

+ +

But having people with expertise to work with has proven to be incredibly helpful, and just having kind of fresh faces to bat ideas around with after he and I have been staring at each other for months now on Zoom calls and meetings. And just, you know, being able to talk about these ideas with fresh faces and new people and get new perspectives has been so very, very helpful.

+ +

I think something that's also great from the momentum standpoint is that because there's a time limit to this experience, we've got the time that we have with you guys, and we've been able to set goals that I think are very achievable for things we want to occur in the next couple of months, and it feels like we're going to get there.

+ +

And I think by the end of this, I mean, our hope, and I think we're on track, is to have a functioning physical product that we're going to offer to consumers with a digital backend to support it, which is, in my mind, amazing. That'll totally validate this idea and prove if we have something or not.

+ +

LINDSEY: I was going to ask if you're open to sharing what those goals specifically are. Is that it? Is it that by the end, you have --

+ +

MIKE: Is that it? Lindsey, that's a lot.

+ +

[laughter]

+ +

CHRIS: It's a lot. I mean, yeah. I mean, we're going to have a physical object in the world that you can buy via an e-commerce site --

+ +

JORDYN: Sounds like we need Lindsey on the team if Lindsey feels like this is so achievable. [laughter]

+ +

CHRIS: Yeah, yeah. Lindsey...yeah. We're in the beginning [crosstalk 15:47]

+ +

LINDSEY: I meant, is that the goal?

+ +

CHRIS: That is the goal.

+ +

LINDSEY: Is that all?

+ +

CHRIS: I was going to –-

+ +

LINDSEY: Is that all you got?

+ +

CHRIS: Mike, do you agree?

+ +

MIKE: Yeah. Is that the goal? Yes, that is the goal. I mean, you know, when we sat down with the thoughtbot team kind of week one, you know, they're sort of like, "All right, let's define kind of the experiment." So, we refer to them as experiments, which I think is helpful because, like, what are the experiments that we want to be doing during our time here? And, you know, we talked about it a lot.

+ +

And yeah, I think it's, you know, having a physical product out in the world, having a website in which to sell it. But also, it's really like Chris was saying, it's like, it's market validation, and just making sure we actually have something that people want. It's like, you know, running a startup takes so long and, like [laughs], you know, you'll do it for so many years. It's like bands when people say, like, "Oh, that's an overnight sensation." It's like, you know, that band has been slogging it out in tiny, little venues for four years before you ever heard of them.

+ +

It's like, that's what so much of the startup world feels like to me, too. It's like, "Oh, you're just getting started as a startup?" It's like, "Well, we've been working on this forever." And I know how long this can take. And so, I think we want to learn as early as possible, like, is this something people actually want? Because if they don't, like, we'll just go do something else. I don't want to spend years making something that people don't want.

+ +

So, I think the biggest goal, for me, is just validation, and then that is sort of how we get there is like, okay, how do we validate this? Cool. Let's identify some, you know, assumptions of personas that we think are people who do actually want this and then try to go sell it to them. And all the implications from that are, okay, well, you need a website where somebody can buy it. You need a physical product that somebody can actually buy. So, all those things sort of come out of that, but, for me, it's like, proving that assumption, is this thing real? Do people actually want this? And everything else is like, okay, how do we prove that?

+ +

LINDSEY: Jordyn, what does that look like in these first few weeks here? User interviews, I assume, how are the user interviews going?

+ +

JORDYN: Always. Always. So, you know, we kick it off by just, like, doing the exercise where we list everybody who might want this. And the team, you know, it's a fun product. Everybody brought their own assumptions and ideas to the table on that. You know, we had a lot of different scenarios we were imagining. It's super fun getting that stuff out of people's heads, just, like, what are we all thinking?

+ +

And then, you know, we get to negotiate, like, okay...I always encourage everyone to think, like, if everyone else on the team was on the moon, you had to make a decision about a market segment to pick; which one would you pick? And then we kind of argue about it in a productive way. It really helps us get at, like, what are the dynamics that we think matter upfront? And then we pick one, or, in this case, we have a few. We have a handful.

+ +

And we're running interview projects where we just recruit people to talk about people that meet this persona, talk about a specific problem. We're in the middle of that right now. And it's fun, fantastic. These conversations are super interesting. We're validating a lot of the things that Mike and Chris, you know, walked into this with, but we're learning a bunch of new things as well.

+ +

And, like, really, part of the aim there is to validate that there's a hole in the market that we might fill but also to hear the language people are using to describe this stuff. So, when people talk about buying music, merch, you know, making playlists, et cetera, like, what language do they use to talk about that? So that we make sure we're speaking the language that our customer uses to describe this stuff. And we're, you know, we're right in the pocket of doing that, learning stuff all the time.

+ +

And it helps us kind of hone the messaging. It helps us know where to go talk to people about it, how to talk about it, but it's, you know, it all kind of fits together. And it's just this, really...the early stages. It's just a bunch of us in a room, a virtual room, in this case, sort of, like, tossing ideas around. But out of it crystallizes this sense of alignment about who this is for, how to talk to them about it, and with a goal.

+ +

And, you know, Mike and Chris walked in with the exact right mindset about this, which is, yes, it's experiments. We need to validate it. Let's make sure there's a there-there. If there's a there-there, let's figure out where it is [laughs], like, all those things. And we're running these experiments, and it was really [inaudible 19:36]. We got down to business quite quickly here. It was really great.

+ +

LINDSEY: Like you said, it's not necessarily a problem or, you know, the typical framing of a problem. How do you start those user interview questions around this? Do you feel a gap between the physical and the digital sound? [laughter]

+ +

JORDYN: No, no.

+ +

LINDSEY: It's maybe not it [laughs].

+ +

JORDYN: Yeah, no. Well, I can tell you what our startup questions are. One of them is, tell me about the last time you bought music merch. Go for it, Lindsey. Tell us.

+ +

LINDSEY: The last time I bought music merch, I went to a Tegan and Sara concert a few weeks ago, and I bought a T-shirt.

+ +

JORDYN: Tell me about buying that T-shirt. Why'd you buy it?

+ +

LINDSEY: Because I wanted to remember the show and my time with my friends, and I wanted to support the artists. I know that buying merch is the best way to support your favorite touring artists.

+ +

JORDYN: So, it's just, you know, we could spend the rest of this time talking [laughter] [crosstalk 20:34], and it would be awesome. So, it's really a lot of things like that.

+ +

LINDSEY: Gotcha.

+ +

JORDYN: You don't ask, "What problem are you trying to solve by buying this t-shirt?" Right? Like, that's not, you know, but we ask you to tell us a bunch of stories about when you did this recently. You know, and if you make playlists for friends, you know, that's a different persona. But we would have asked, you know, like, "Tell me about the last playlist you made. You know, who did you share it with? You know, what happened after that? What happened after that? What happened after that?" It's a lot of questions like that. And there's just nothing better. People love to tell you what's going on with them. And it's great [laughs].

+ +

LINDSEY: Yeah. As you all have been doing these interviews, Mike and Chris, have you been surprised by anything? Any interesting insights that you're seeing already?

+ +

CHRIS: I mean, I haven't done really much in the way of user interviews in the past. This is a really new experience for me. And then we're, obviously, not on the calls because that would be weird and probably intimidating for people. But we're getting lots of highlights from folks who are doing them, you know, in our daily sync.

+ +

And I'm surprised at how many, like, really intense, like, playlist nerds we have found even just in, like, the few people we've talked to, like, in the best possible way. Like, people who are like, "I make playlists all the time." Like, you're talking about, like, a vinyl fan or, like, a...Jordyn, what's the story? It's, like, the guy who there was so much out-of-print vinyl that he started a vinyl label just to get the albums in vinyl. [crosstalk 21:56]

+ +

JORDYN: Yeah. There were a bunch of releases that he feels really passionately about that were never released on vinyl that he knew would never be released on vinyl. And so, he started a vinyl record label. And we just found this guy [laughter].

+ +

CHRIS: Is that indicative that that's, like, an entire persona we're going to, like, target? Absolutely not. But it's just, like, it's amazing that even just in the few user interviews we've done, that we've found so many very passionate people. And it's sent me down, like, a TikTok rabbit hole of, like, TikTok, like, music nerd influencer-type folks who are posting playlists.

+ +

And they, like, hundreds of thousands of likes on these videos that are literally just, like, screen with text on it that you're supposed to, like, pause the video [laughs] and, like, look at, like, the songs that they're recommending. And it's like, who does that? And it was like, these people do that. And it's like, so there are...it's been very encouraging to me, actually. I was worried that we were going to find not as much passion as we had suspected, and I think the opposite has proven to be true. So, it's exciting.

+ +

CHRIS: Yeah, I completely agree with Mike. It's been so encouraging. I think, for me, what we're doing is an idea that I'm very excited about and have been very excited about for a long time. But hearing the responses that we're getting makes me confident in the idea, too. That's great. I mean, I think that is everything that a founder needs, you know, is excitement and confidence.

+ +

MIKE: Well, and just the whole user interview experience has, like, made a lot of my other conversations sort of I've tried to frame parts of them as user interviews because I'm talking to a lot of, like, label folks now, and artists, merch people. And, you know, I ended up just sort of, like, asking them, I mean, yes, trying to explain the product and work on kind of partnership stuff, but a lot of it is really just geeking out with them. And just, like, hearing their thoughts about, like, what they love about merch because these are people that clearly think about this stuff all the time. So, it's definitely kind of, like, tuned my other conversations into trying to get unbiased feedback.

+ +

LINDSEY: Yeah. Everything is a little user interview now.

+ +

MIKE: Yeah, exactly.

+ +

LINDSEY: Get that angle in there. All right, so some early validation and excitement. That's really cool to hear. Any challenges or, you know, other kinds of learnings early on? Anything that's been invalidated?

+ +

MIKE: I don't know that we're there yet. [inaudible 24:02] Chris, I don't know. I'm happy to find that some things are invalidated, but I don't really feel...you know, some of the personas that we decided or maybe just one of the personas we decided to pursue, I think we're having a hard time having those user interviews kind of really bear fruit, but that's helpful, too, actually. I mean, it's like, okay, well, maybe that's not a group that we target.

+ +

JORDYN: Yeah. It's about, like, [inaudible 24:24]. I encourage folks not to think about this like a 'no, not that,' and instead think of it as like a 'not yet.' And that's, I think, the dynamic here with a couple of the personas we were interested in. It's just been turned into kind of, like, a not yet for reasons that we very quickly figured out, but we'll get there. It's just a matter of figuring out we had some other personas take precedence because they're more sort of red, hot in a way, right? It's just easier to get in contact with these people, or it's, like, clear what they're going for or what they need from the market.

+ +

So, you know, we have this whole list, and it was not clear at first who was going to kind of stand out. But we've kind of found some focus there, which means, invariably, that there's things that are falling out of the frame for now, and you're kind of de-prioritizing them. But it really is, like, a we'll get to that [laughs]. We'll eventually get to that.

+ +

LINDSEY: Yeah. And part of the process, who's going to rise to the top right now?

+ +

JORDYN: Yeah, exactly.

+ +

LINDSEY: Do you have anything you can show and tell with us today or not yet?

+ +

MIKE: So, Chris has been hard at work on all the physical side of this stuff and going back and forth with our manufacturing partner and all that good stuff. But we have a final version of the mixtape product.

+ +

LINDSEY: For when this gets pulled into the podcast, Mike's showing us a physical card.

+ +

CHRIS: It's a small card, and we call them Goodz. And it's printed on three-millimeter plywood using a UV printing process, super durable. And this is something you can put in your pocket. You're not going to wreck it. I think you could actually (Don't quote me on this.), but I think you can even, like, put it through a washing machine, and it would be fine. Embedded in this card is a chip that can be read by your phone, and that's pretty much what we're working with.

+ +

MIKE: Yeah, so the idea is you just sort of tap this, and it'll take you to a streaming version of a playlist. And then Chris has also been making these adorable crates. And [crosstalk 26:10]

+ +

LINDSEY: The little crates I love.

+ +

MIKE: And we actually have some wooden ones, too, in the testing that's [crosstalk 26:15]

+ +

LINDSEY: And then the mixtapes get stored in the little crates [crosstalk 26:19]

+ +

MIKE: Yeah. So, you could have --

+ +

LINDSEY: Throw it on your desk.

+ +

CHRIS: Each crate can hold about, I think, 15 of these things. What's really cool about this product on the physical side is we are using a tried-and-true technology, which is NFC chips. These are things that make Apple Pay work, make Google Pay work. They are in your E-ZPass when you drive through a toll booth. This is stuff that's been around for years. So, we're just kind of leveraging this technology that's been around for so long in a new way.

+ +

MIKE: Yeah, I think it's similar to kind of the evolution of QR codes, right? It's like they were sort of around forever, and then it was, like, COVID and restaurant menus kind of kicked those into mainstream. Like, NFC has been around for a long time. It's very tried and true. It's affordable. But I want to say Apple only turned it on by default, like, the NFC reader in the iPhone in the last, like, 18 to 24 months, right? Like, it started...like, it's been around for a while, but they're sort of slowly kind of...and now you just sort of see it everywhere. People are using it on the subways in New York to scan for tickets or for accessing stuff.

+ +

I was also just showing Chris has been prototyping with the ability to sort of keep these on a key ring. So, we have, like, a little chain hole on them. It is [inaudible 27:22] to sort of have this on your backpack or, you know, on a key ring, or something like that. And friends could kind of, like, come up to you and just, like, scan one that looks interesting.

+ +

CHRIS: And yeah, something that's awesome about this is you don't need an app. You don't need to download anything. As long as your NFC reader is on when you scan this, it will bring you to the music that it's linked to, which I think is awesome. So, I mean, my dream is to have these, like, hanging off of people's backpacks so I can, like, scan them in the subway or, you know, it's such, like, an easy thing to do. And it requires so little technical time on the user's end to be able to do it.

+ +

LINDSEY: Oh, we got a question here. "So, Moo used to offer NFC cards. What made you decide to do the thicker plywood model?"

+ +

CHRIS: Durability is really what it comes down to. We wanted something that felt like an object that you can have and treasure. Like, these have weight, you know, these feel like something, not just a piece of paper. This is something that you can have and [inaudible 28:22] your desk, and it's not going to fade in the sunlight. It's not going to disintegrate over time. This is something that's going to last.

+ +

MIKE: Yeah, the cards would definitely, like, as I would sort of carry them around and show them to people and stuff, the cards would start, you know, breaking. It's like having a business card in your pocket, right? Eventually, it's going to kind of wear out. And plus, we had, like, the stickers were visible on the back of them. And we were, like, having the sticker just completely disappear inside the wood; it just feels a little bit more like magic.

+ +

LINDSEY: Well, thanks for demoing there. I put you on the spot a little bit. But they are...I had seen them in the Slack, and they're very cool [laughs]. So, I had to ask if we could show them off a bit.

+ +

MIKE: Of course.

+ +

CHRIS: I think another thing to think about, too, is we've been talking a lot about the user experience. But if and when we get to the point of making these for artists, artists will be able to collect so much data off of the way that people buy and collect and use these things over time, which is something that we're really, really excited about. And also, you know, we're working on a way to make the link in the object updatable over time. So, artists will be able to change what a card points do to inform their users about the latest and greatest thing.

+ +

LINDSEY: Very cool. Jordyn, what's next on the programming agenda for Chris and Mike?

+ +

JORDYN: It's really sort of we're in this, like, iterative cycle. So, we're talking to folks. We're working on the website. The conversations we're having with people are informing how we're framing this first experiment with the mixtape, how we're marketing it, who we're marketing it to. I think next up is probably a Google Ad experiment to really see if we can piggyback on some stuff or at least figure out a new consumer product. It's so tough, right?

+ +

It's also not a thing people are searching for. So, we have to come up with some experiments for how we get people to that website [laughs]. So, you know, Google Ads funnels is just something you kind of have to do because it's very interesting to figure out what people are responding to, what people are searching for. But we're going to have a bunch of other experiments as well and non-experiments. Outbound experiments: can we go to people? Can we get listed in a gift-buying guide for the holidays? Or, like, we don't know. There's a bunch of experiments we need to do around that, which is really just this iteration.

+ +

We won't stop talking to users, but, you know, everything we're hearing from them will inform where we go and how we talk to the folks in those places where we end up. And really, it's just about starting...once this is up and, you know, there's, like, an orderable thing, there's, like, a whole data cycle where we start to learn from the stuff we're testing; we actually have some real data for it, and we can start to tweak, iterate and change our strategy.

+ +

But the bigger thing, also, is this bigger platform. So, the next thing really, the big next thing, is to sort of start to scope and create an architecture idea. What's it going to take to build the actual backend thing? And it's the thing that thoughtbot really [laughs] excels at, which is software. So, you know, that's the big next kind of project. Once the mixtape experiment is sort of out and in flight and we're getting data, we really need to turn our attention to the technical backend.

+ +

LINDSEY: Exciting. Another comment/question from Jeff, who maybe needs a user interview. "Love the crate more than the actual albums. Maybe offer collections of artists."

+ +

MIKE: Yeah, that's the plan.

+ +

CHRIS: Yeah, definitely. It's a good idea. Yeah, it's, I mean, and labels get to, especially, like, small indie labels get really excited about doing, like, crates worth of collections of different artists or, like, you know, digging through their back catalog, their subscription services. There's a lot of different angles for sure about that idea.

+ +

LINDSEY: [inaudible 31:55] Chris and Mike, going into this next section of the programming, for anyone watching right now, or watching the recording, or listening to the recording, any action items from them? You know, are you looking for any user interviews or have any survey or any destinations you'd like to send people yet?

+ +

CHRIS: Not quite yet, but soon, I would say. Well --

+ +

MIKE: I mean, [inaudible 32:19] plug the website, I mean, you know, I think we've got, like, an email to sign up from there, right? The URL is getthegoodz.com and I [crosstalk 32:27]

+ +

LINDSEY: Goodz with a Z.

+ +

MIKE: Goodz with a Z.

+ +

CHRIS: With Z.

+ +

MIKE: So yeah, if you want to go there, you can sign up. I think there's an email signup on there to learn more.

+ +

LINDSEY: Perfect. All right. getthegoodz.com email sign up. To stay up to date on Goodz and the incubator, you can follow along on the thoughtbot blog. You know, as always, send us any questions you might have, and we're happy to get to those. But otherwise, thanks for listening.

+ +

And thank you all — Jordyn, Chris, and Mike. Thanks so much for joining today and sharing and being open about your stories so far.

+ +

MIKE: Thank you.

+ +

CHRIS: Yeah, thank you, Lindsey.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Chris Cerrito and Mike Rosenthal.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This episode introduces the second participants of the season's thoughtbot's Incubator Program, Mike Rosenthal and Chris Cerrito. Mike has a background in music industry marketing, and Chris is a maker and tinkerer with experience in exhibit development. They're developing a product combining physical objects with digital content, starting with music. Their concept involves creating physical items like wooden mixtapes with NFC chips linking to digital playlists. This blend of physical and digital aims to revive the tangible aspects of fan engagement in a digital era.

+ +

Their project, named Goodz, is the first pure consumer product in the Incubator program, adding complexities like supply chain and manufacturing considerations. The team is conducting user interviews to validate market interest and refine their messaging. They aim to have a functioning physical product and a supporting digital backend by the end of the program. Challenges include defining the target market and understanding how to attract customers to a new product type. The thoughtbot team is excited about the project due to its fun nature and technical aspects, offering a fresh perspective compared to problem-focused startups.

+ +

The conversation also explores the broader implications of bridging the digital and physical worlds in fan engagement, with the potential to collect valuable data for artists and create lasting, meaningful connections for fans.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: All right. I'm going to kick us off here. Thanks, everyone, for tuning in. We're doing our first update with two founders that are now going through the Startup incubator at thoughtbot. thoughtbot, if you're not familiar, product design and development consultancy. We'll help you on your product and make your team a success. One of the very fun ways we do that is through the startup thoughtbot incubator, which is an eight-week program.

+ +

So, with us today, I myself am Lindsey Christensen, marketing for thoughtbot. We also have Jordyn Bonds, who is our Director of Product Strategy and runs the thoughtbot incubator. And then, as I mentioned, we've got two new founders who are going to tell us a little bit about themselves and what they're working on. Mike Rosenthal, let's kick off with you. Can you tell us a little bit about maybe your background and what brings you to present day?

+ +

MIKE: Sure. First of, thanks for having us. It's been a lot of fun doing this over the last [inaudible 01:03]; it's only two weeks, two and a half weeks, something like that. It feels like a lot more. I come from a music industry background, so worked in sort of marketing and strategy for artists for a long time; worked with a band called OK Go back, sort of starting in 2009 or so.

+ +

I did a lot of early kind of viral music video stuff. And we were sort of early to the idea of sort of leveraging fan engagement and revenue, honestly, kind of beyond sort of just selling their music and touring, so sort of exploring other ways that artists can make money and connect with their fans and was with those guys for five years.

+ +

And then, I went on and worked at an artist management company in Brooklyn called Mick Management and ran the marketing department there, so doing similar type of work but for a roster of 2025 major label bands. And so, really got to see fan engagement on all different levels, from really large bands down to baby bands who were just getting started. And then, yeah, started my first startup in 2018, so doing sort of fan engagement work, and NFTs, and blockchain-type stuff working with bands, but then also sports and entertainment properties. Yeah, that kind of brings me here.

+ +

So, always been sort of on the music side of things, which ties into a lot of what Chris and I are working on now, but more generally, sort of fan engagement and how to, you know, drive revenue and engagement for artists and deliver value for fans.

+ +

LINDSEY: Very interesting. All right, Chris, going to head over to you. Chris Cerrito, can you tell us a bit about your background? And it sounds like yours and Mike's paths; this isn't the first time you've crossed.

+ +

CHRIS: No. Mike and I have been working together since 2007, I believe. Yeah, that's a great place to start. I've always been kind of a maker and a tinkerer, always been interested in art materials, how things are put together. And that kind of culminated at grad school, where Mike and I met at NYU, where we both studied physical computing and human-computer interaction, making weird things that kind of changed the way that people interact and play with technology in their day-to-day lives.

+ +

I think the first project he and I worked on together was a solar robotic band that we played with light in front of a bunch of people. It was very wonderful and confusing at the same time. After grad school, I was lucky enough to become a resident artist and then an exhibit developer at a museum in San Francisco called the Exploratorium, which is a museum of science, art, and human perception.

+ +

I spent ten years there working on exhibits, teaching people things ranging from, let's see; I built a dueling water fountain to teach visitors and users about the prisoner's dilemma. I built a photo booth that used computer vision to teach people about the microbiome that lives on their face, like, just all kinds of weird things like that that fuse the digital and the physical worlds. I loved my time there.

+ +

And then kind of COVID hit, and I realized that everything I had been working on for ten years was locked up in a museum that I no longer had access to. And it really gave me a desire to kind of bring my ideas into the physical world. I wanted to make things that people interact with and use in their lives on a day-to-day basis. And I would say that's really what brought me here to this point.

+ +

LINDSEY: Very cool. Very interesting backgrounds, in my opinion. What is the new idea? What is the thing that you're bringing into the incubator? Mike, I'll start with you. Tell us a bit about what you're working on.

+ +

MIKE: Chris and I are working on physical objects that connect to digital content is sort of the broadest way that I could describe it. I think, you know, as Chris kind of mentioned, you know, we've both been working on sort of physical things that have interactivity for a lot of our careers. I think we both come from an era of a lot more physical objects in your life, whether that's, you know, VHS cassettes at your parent's house growing up, or records and tape cassettes, and just sort of physical things that remind you of the things that you love.

+ +

And I think that, you know, cell phones are great, and the sort of the smartphone era is amazing and having, you know, every single song, and movie, and television show and podcasts, et cetera, in a black box in my pocket is great. But I think we've sort of gotten to a point where it's more of an organizational problem now than anything else. And we sort of forget the actual things that we love in this world.

+ +

And so, we're working on basically making physical objects to tie to digital content, and we're starting with music. And that's what we've been working on at thoughtbot is sort of how we can create physical things that basically you can tap, and that will take you to streaming content. One of the first things we're working on literally looks like sort of a little mixtape on a piece of wood, and you can just load that up with any sort of playlist that you might have on Spotify, or Apple Music, or YouTube, or whatever, and tap it, and it will take you there.

+ +

And so, it's just sort of that idea of like, oh, we used to be able to sort of flip through a friend's music collection and judge them ruthlessly, or become even better friends with them based on kind of what you saw there. And we think that the time is ripe for, I don't know, a blend of that nostalgia with actual sort of, like, real-world utility that people could be into this right now. Chris, what am I missing there?

+ +

CHRIS: I'd say just to expand on that a little bit, it's, you know, we spend so much time in the digital world, but we still exist in the physical. And a lot of the things, like, you might spend a really long time editing a photo for your parents or making a playlist for a friend, and there's, like, a value there that might not translate because it's digital. It's ephemeral. And I think tying these digital assets to a physical thing makes them special. It gives them, like, a permanent place in your life, something to respect, to hold on to, and maybe even pass down at some point.

+ +

LINDSEY: Yeah, and I think before we logged on, we actually had Jordyn and Mike grabbing cassette tapes from the room there and to show us --

+ +

MIKE: [inaudible 06:49]

+ +

LINDSEY: What [laughs] was some of their collection and to prove some of the power of these physical –-

+ +

MIKE: Nothing, like, just old mixtapes.

+ +

LINDSEY: Mementos.

+ +

MIKE: Yeah. We were just talking about this on our sync with the thoughtbot crew. They're, like, there's sort of two levels of nostalgia. There's nostalgia for people like us who, yeah, [crosstalk 07:09] mixtapes, right? For people who actually grew up with this stuff and still have it lying around or don't but, like, look at something like that that gives you, like, instant flashbacks, right? You're like, oh my God, I remember scrolling on that little j-card or, like, getting a mixtape for my first, you know, boyfriend or girlfriend, and having it just mean everything. So, there's people for whom that was a thing.

+ +

And there's, you know, generations of people for whom that is, like, their only connection to that is, you know, Stranger Things or, like, you know, the mixtape exists in pop culture as a reference. So, there's still, like, a very strong attachment there, but it's not a personal one, right? It's a cultural one. But I think everybody has that connection. So, that's kind of why we're starting with the mixtape, just because I think everyone can kind of relate to that in some way.

+ +

LINDSEY: Yeah, no, yeah. When I hear mixtape, it goes immediately to crushes. You make a mixtape for your crush.

+ +

CHRIS: Exactly.

+ +

LINDSEY: It's a huge, powerful market, powerful.

+ +

MIKE: Oh my God, so powerful. I mean, yeah, I don't know anybody --

+ +

LINDSEY: What's more motivating?

+ +

MIKE: [laughs] Yeah, exactly.

+ +

CHRIS: Or even just I have a really good friend who I don't get to see as often as I'd like. And he and I are constantly sending each other, you know, Spotify links and text messages. And it's great. I love that interaction. But at the same time, you know, I might forget to add that to a playlist, and then it's kind of lost. If I had taken the time to make something and send it to him physically or vice versa, it just becomes so much more special and so much more real.

+ +

MIKE: Yeah. I mean, honestly, I first made these...I mean, we can go to this origin if we want. But, like, I literally just went on moo.com, right? The business card company. And they let you upload, you know, 50 different images, and they'll send you all of those as business cards. And so, I literally went on and just made business cards of all the album covers of, like, albums that I loved growing up, right? And their cheapest is this little piece of cardboard. But I had 50 of these, and I'd put them all out on my coffee table, just as something I wanted to have around.

+ +

And people kept coming, you know, friends would come over, and you would just have these conversations that I haven't had in 10 or 15 years, right? Because no one's going to come to my house and pick up my phone and look at my Spotify collection. But if these things are all just sitting out, they're like, "Oh shit, you're into that? Like, I haven't thought about that album in 15 years." Or like, "Oh, I didn't know you were into that. I'm, like, a crazy super fan of that artist as well." And all of a sudden, we're having these conversations that we just weren't having. Yeah, there's something there where it's all been nostalgia coupled with the kind of prompting of conversation and connection that we've kind of lost, I think.

+ +

CHRIS: And I think just to clarify a little bit on what Mike's saying, is, you know, this mixtape will be our first product launch, and then we're hoping to move into collectibles for artists and labels. So, shortly after we launch this tape, we're hoping to launch some kind of pilot with a label where you will be able to buy a version of this for your favorite music artist at a merch table in a concert, possibly online. Our dream is to have these sitting there on the table with T-shirts, and records, and other things that artists sell so you can express for the artists that you love. This is a way of expressing your fandom.

+ +

LINDSEY: Jordyn, heading over to you, this feels like maybe the first consumer product that has gone through the incubator, would you say? Or how do you think about it?

+ +

JORDYN: Yeah, if you're a consumer --

+ +

LINDSEY: Or is it different than other types of products?

+ +

JORDYN: Yeah, the first incubator project we did with Senga was, I think, what you would call prosumer. So, it was sort of a consumer thing but directed at folks who had kind of freelancing in sort of a business context. It's got a lot of dynamics of the consumer. But this one, for sure, is the first pure consumer play. Though now that I'm thinking about it, you know, AvidFirst had some consumer elements to it, but it was, you know, it was, like, more complex tech [laughs] [inaudible 10:46] totally different thing --

+ +

LINDSEY: But definitely the first of the physical, physical [inaudible 10:52]

+ +

JORDYN: Oh, sure, the first of the physical thing. Right. Absolutely.

+ +

LINDSEY: Does that change any of, like, the approach of the programming, or it's kind of --

+ +

JORDYN: I mean, no, not fundamentally, though it does add this layer of operations that you don't have with a pure software play. So, we have to be, there is a thing that needs to get shipped to people in the world, and that takes timelines, and it takes --

+ +

LINDSEY: Supply chain.

+ +

JORDYN: Yeah, exactly. And Chris is doing most of that stuff. I don't want to, you know, this is not, like, the main focus of our team necessarily, but it intersects, right? So, this isn't the first one of these types of products I've worked on personally in my career. But there's something, like, really, for me, very fulfilling about, like, there's software. There's a big component of software. There's also this physical object that needs to exist in the world.

+ +

And partly, what's so compelling about Goodz is that it gives you the promise of a physical, like, the sort of good aspects of a physical product, a thing you can hold in your hand and look at and really connect with in that physical way. But it has this dynamic digital, like, essential quality as well. So, it's very compelling as a product because it sort of marries the things that we like about both the physical world and the digital world, which is partly why the team was really excited about working on it [laughs].

+ +

LINDSEY: Well, that was going to be my next question is, you know, what stood out to you about the Goodz application for the incubator and the interview process that made you and the team feel like this was going to be a great project to work on?

+ +

JORDYN: Yeah. So, I think just the team really resonated with the sort of idea in general, and it seemed fun. There was, like, it's a very positive thing, right? It isn't so much about solving problems and pain points. And, sometimes the, you know, when you're very focused on solving problems, it can feel a little doomy because you actually have to, like, immerse yourself in the problems of the people that you're making software for. And sometimes, you start to feel like the world is just full of problems.

+ +

What Goodz is doing is sort of it is solving a problem in a sense, but not in that kind of way. It's really, like, a fun upside kind of thing, which I think a lot of the folks on the team were very excited about. But, like, the software component, actually, is very interesting to us from a technological standpoint as well. There's a lot of opportunity here to do interesting things on the backend with an object that's essentially functioning as a bookmark out in the world. What all can you do with that? There's something super compelling and technically interesting about it.

+ +

And I think, also, the team was just sort of excited by Chris and Mike, you know, the energy and the kind of background they were bringing to the table was also super interesting. And then, above all else, what I say every time you ask me this question, which is stage fit, y'all, good stage fit. They're right at the beginning. They haven't built the product yet [laughs]. Gotta say it. It's a good stage fit. They know who they're building for broadly but not super specifically. Got a good vision but, like, haven't made that first step with the software. Perfect stage fit for us [laughs].

+ +

LINDSEY: Great. So, Chris, we were talking a bit before about how you two have been collaborators in the past, worked on business ideas before. Why bring this idea into the thoughtbot incubator? What are you hoping to, you know, achieve?

+ +

CHRIS: One of the main reasons why we wanted to bring this into the incubator was just for support, momentum, and then, also, I would say, validation for our idea. I mean, we came to the incubator with a very, yeah, I would say it was a fairly developed idea that needed to be proved, and we, quite frankly, needed help with that. You know, Mike and I have our own expertises, but we don't know how to do everything. We're more than willing to jump in where we need to go.

+ +

But having people with expertise to work with has proven to be incredibly helpful, and just having kind of fresh faces to bat ideas around with after he and I have been staring at each other for months now on Zoom calls and meetings. And just, you know, being able to talk about these ideas with fresh faces and new people and get new perspectives has been so very, very helpful.

+ +

I think something that's also great from the momentum standpoint is that because there's a time limit to this experience, we've got the time that we have with you guys, and we've been able to set goals that I think are very achievable for things we want to occur in the next couple of months, and it feels like we're going to get there.

+ +

And I think by the end of this, I mean, our hope, and I think we're on track, is to have a functioning physical product that we're going to offer to consumers with a digital backend to support it, which is, in my mind, amazing. That'll totally validate this idea and prove if we have something or not.

+ +

LINDSEY: I was going to ask if you're open to sharing what those goals specifically are. Is that it? Is it that by the end, you have --

+ +

MIKE: Is that it? Lindsey, that's a lot.

+ +

[laughter]

+ +

CHRIS: It's a lot. I mean, yeah. I mean, we're going to have a physical object in the world that you can buy via an e-commerce site --

+ +

JORDYN: Sounds like we need Lindsey on the team if Lindsey feels like this is so achievable. [laughter]

+ +

CHRIS: Yeah, yeah. Lindsey...yeah. We're in the beginning [crosstalk 15:47]

+ +

LINDSEY: I meant, is that the goal?

+ +

CHRIS: That is the goal.

+ +

LINDSEY: Is that all?

+ +

CHRIS: I was going to –-

+ +

LINDSEY: Is that all you got?

+ +

CHRIS: Mike, do you agree?

+ +

MIKE: Yeah. Is that the goal? Yes, that is the goal. I mean, you know, when we sat down with the thoughtbot team kind of week one, you know, they're sort of like, "All right, let's define kind of the experiment." So, we refer to them as experiments, which I think is helpful because, like, what are the experiments that we want to be doing during our time here? And, you know, we talked about it a lot.

+ +

And yeah, I think it's, you know, having a physical product out in the world, having a website in which to sell it. But also, it's really like Chris was saying, it's like, it's market validation, and just making sure we actually have something that people want. It's like, you know, running a startup takes so long and, like [laughs], you know, you'll do it for so many years. It's like bands when people say, like, "Oh, that's an overnight sensation." It's like, you know, that band has been slogging it out in tiny, little venues for four years before you ever heard of them.

+ +

It's like, that's what so much of the startup world feels like to me, too. It's like, "Oh, you're just getting started as a startup?" It's like, "Well, we've been working on this forever." And I know how long this can take. And so, I think we want to learn as early as possible, like, is this something people actually want? Because if they don't, like, we'll just go do something else. I don't want to spend years making something that people don't want.

+ +

So, I think the biggest goal, for me, is just validation, and then that is sort of how we get there is like, okay, how do we validate this? Cool. Let's identify some, you know, assumptions of personas that we think are people who do actually want this and then try to go sell it to them. And all the implications from that are, okay, well, you need a website where somebody can buy it. You need a physical product that somebody can actually buy. So, all those things sort of come out of that, but, for me, it's like, proving that assumption, is this thing real? Do people actually want this? And everything else is like, okay, how do we prove that?

+ +

LINDSEY: Jordyn, what does that look like in these first few weeks here? User interviews, I assume, how are the user interviews going?

+ +

JORDYN: Always. Always. So, you know, we kick it off by just, like, doing the exercise where we list everybody who might want this. And the team, you know, it's a fun product. Everybody brought their own assumptions and ideas to the table on that. You know, we had a lot of different scenarios we were imagining. It's super fun getting that stuff out of people's heads, just, like, what are we all thinking?

+ +

And then, you know, we get to negotiate, like, okay...I always encourage everyone to think, like, if everyone else on the team was on the moon, you had to make a decision about a market segment to pick; which one would you pick? And then we kind of argue about it in a productive way. It really helps us get at, like, what are the dynamics that we think matter upfront? And then we pick one, or, in this case, we have a few. We have a handful.

+ +

And we're running interview projects where we just recruit people to talk about people that meet this persona, talk about a specific problem. We're in the middle of that right now. And it's fun, fantastic. These conversations are super interesting. We're validating a lot of the things that Mike and Chris, you know, walked into this with, but we're learning a bunch of new things as well.

+ +

And, like, really, part of the aim there is to validate that there's a hole in the market that we might fill but also to hear the language people are using to describe this stuff. So, when people talk about buying music, merch, you know, making playlists, et cetera, like, what language do they use to talk about that? So that we make sure we're speaking the language that our customer uses to describe this stuff. And we're, you know, we're right in the pocket of doing that, learning stuff all the time.

+ +

And it helps us kind of hone the messaging. It helps us know where to go talk to people about it, how to talk about it, but it's, you know, it all kind of fits together. And it's just this, really...the early stages. It's just a bunch of us in a room, a virtual room, in this case, sort of, like, tossing ideas around. But out of it crystallizes this sense of alignment about who this is for, how to talk to them about it, and with a goal.

+ +

And, you know, Mike and Chris walked in with the exact right mindset about this, which is, yes, it's experiments. We need to validate it. Let's make sure there's a there-there. If there's a there-there, let's figure out where it is [laughs], like, all those things. And we're running these experiments, and it was really [inaudible 19:36]. We got down to business quite quickly here. It was really great.

+ +

LINDSEY: Like you said, it's not necessarily a problem or, you know, the typical framing of a problem. How do you start those user interview questions around this? Do you feel a gap between the physical and the digital sound? [laughter]

+ +

JORDYN: No, no.

+ +

LINDSEY: It's maybe not it [laughs].

+ +

JORDYN: Yeah, no. Well, I can tell you what our startup questions are. One of them is, tell me about the last time you bought music merch. Go for it, Lindsey. Tell us.

+ +

LINDSEY: The last time I bought music merch, I went to a Tegan and Sara concert a few weeks ago, and I bought a T-shirt.

+ +

JORDYN: Tell me about buying that T-shirt. Why'd you buy it?

+ +

LINDSEY: Because I wanted to remember the show and my time with my friends, and I wanted to support the artists. I know that buying merch is the best way to support your favorite touring artists.

+ +

JORDYN: So, it's just, you know, we could spend the rest of this time talking [laughter] [crosstalk 20:34], and it would be awesome. So, it's really a lot of things like that.

+ +

LINDSEY: Gotcha.

+ +

JORDYN: You don't ask, "What problem are you trying to solve by buying this t-shirt?" Right? Like, that's not, you know, but we ask you to tell us a bunch of stories about when you did this recently. You know, and if you make playlists for friends, you know, that's a different persona. But we would have asked, you know, like, "Tell me about the last playlist you made. You know, who did you share it with? You know, what happened after that? What happened after that? What happened after that?" It's a lot of questions like that. And there's just nothing better. People love to tell you what's going on with them. And it's great [laughs].

+ +

LINDSEY: Yeah. As you all have been doing these interviews, Mike and Chris, have you been surprised by anything? Any interesting insights that you're seeing already?

+ +

CHRIS: I mean, I haven't done really much in the way of user interviews in the past. This is a really new experience for me. And then we're, obviously, not on the calls because that would be weird and probably intimidating for people. But we're getting lots of highlights from folks who are doing them, you know, in our daily sync.

+ +

And I'm surprised at how many, like, really intense, like, playlist nerds we have found even just in, like, the few people we've talked to, like, in the best possible way. Like, people who are like, "I make playlists all the time." Like, you're talking about, like, a vinyl fan or, like, a...Jordyn, what's the story? It's, like, the guy who there was so much out-of-print vinyl that he started a vinyl label just to get the albums in vinyl. [crosstalk 21:56]

+ +

JORDYN: Yeah. There were a bunch of releases that he feels really passionately about that were never released on vinyl that he knew would never be released on vinyl. And so, he started a vinyl record label. And we just found this guy [laughter].

+ +

CHRIS: Is that indicative that that's, like, an entire persona we're going to, like, target? Absolutely not. But it's just, like, it's amazing that even just in the few user interviews we've done, that we've found so many very passionate people. And it's sent me down, like, a TikTok rabbit hole of, like, TikTok, like, music nerd influencer-type folks who are posting playlists.

+ +

And they, like, hundreds of thousands of likes on these videos that are literally just, like, screen with text on it that you're supposed to, like, pause the video [laughs] and, like, look at, like, the songs that they're recommending. And it's like, who does that? And it was like, these people do that. And it's like, so there are...it's been very encouraging to me, actually. I was worried that we were going to find not as much passion as we had suspected, and I think the opposite has proven to be true. So, it's exciting.

+ +

CHRIS: Yeah, I completely agree with Mike. It's been so encouraging. I think, for me, what we're doing is an idea that I'm very excited about and have been very excited about for a long time. But hearing the responses that we're getting makes me confident in the idea, too. That's great. I mean, I think that is everything that a founder needs, you know, is excitement and confidence.

+ +

MIKE: Well, and just the whole user interview experience has, like, made a lot of my other conversations sort of I've tried to frame parts of them as user interviews because I'm talking to a lot of, like, label folks now, and artists, merch people. And, you know, I ended up just sort of, like, asking them, I mean, yes, trying to explain the product and work on kind of partnership stuff, but a lot of it is really just geeking out with them. And just, like, hearing their thoughts about, like, what they love about merch because these are people that clearly think about this stuff all the time. So, it's definitely kind of, like, tuned my other conversations into trying to get unbiased feedback.

+ +

LINDSEY: Yeah. Everything is a little user interview now.

+ +

MIKE: Yeah, exactly.

+ +

LINDSEY: Get that angle in there. All right, so some early validation and excitement. That's really cool to hear. Any challenges or, you know, other kinds of learnings early on? Anything that's been invalidated?

+ +

MIKE: I don't know that we're there yet. [inaudible 24:02] Chris, I don't know. I'm happy to find that some things are invalidated, but I don't really feel...you know, some of the personas that we decided or maybe just one of the personas we decided to pursue, I think we're having a hard time having those user interviews kind of really bear fruit, but that's helpful, too, actually. I mean, it's like, okay, well, maybe that's not a group that we target.

+ +

JORDYN: Yeah. It's about, like, [inaudible 24:24]. I encourage folks not to think about this like a 'no, not that,' and instead think of it as like a 'not yet.' And that's, I think, the dynamic here with a couple of the personas we were interested in. It's just been turned into kind of, like, a not yet for reasons that we very quickly figured out, but we'll get there. It's just a matter of figuring out we had some other personas take precedence because they're more sort of red, hot in a way, right? It's just easier to get in contact with these people, or it's, like, clear what they're going for or what they need from the market.

+ +

So, you know, we have this whole list, and it was not clear at first who was going to kind of stand out. But we've kind of found some focus there, which means, invariably, that there's things that are falling out of the frame for now, and you're kind of de-prioritizing them. But it really is, like, a we'll get to that [laughs]. We'll eventually get to that.

+ +

LINDSEY: Yeah. And part of the process, who's going to rise to the top right now?

+ +

JORDYN: Yeah, exactly.

+ +

LINDSEY: Do you have anything you can show and tell with us today or not yet?

+ +

MIKE: So, Chris has been hard at work on all the physical side of this stuff and going back and forth with our manufacturing partner and all that good stuff. But we have a final version of the mixtape product.

+ +

LINDSEY: For when this gets pulled into the podcast, Mike's showing us a physical card.

+ +

CHRIS: It's a small card, and we call them Goodz. And it's printed on three-millimeter plywood using a UV printing process, super durable. And this is something you can put in your pocket. You're not going to wreck it. I think you could actually (Don't quote me on this.), but I think you can even, like, put it through a washing machine, and it would be fine. Embedded in this card is a chip that can be read by your phone, and that's pretty much what we're working with.

+ +

MIKE: Yeah, so the idea is you just sort of tap this, and it'll take you to a streaming version of a playlist. And then Chris has also been making these adorable crates. And [crosstalk 26:10]

+ +

LINDSEY: The little crates I love.

+ +

MIKE: And we actually have some wooden ones, too, in the testing that's [crosstalk 26:15]

+ +

LINDSEY: And then the mixtapes get stored in the little crates [crosstalk 26:19]

+ +

MIKE: Yeah. So, you could have --

+ +

LINDSEY: Throw it on your desk.

+ +

CHRIS: Each crate can hold about, I think, 15 of these things. What's really cool about this product on the physical side is we are using a tried-and-true technology, which is NFC chips. These are things that make Apple Pay work, make Google Pay work. They are in your E-ZPass when you drive through a toll booth. This is stuff that's been around for years. So, we're just kind of leveraging this technology that's been around for so long in a new way.

+ +

MIKE: Yeah, I think it's similar to kind of the evolution of QR codes, right? It's like they were sort of around forever, and then it was, like, COVID and restaurant menus kind of kicked those into mainstream. Like, NFC has been around for a long time. It's very tried and true. It's affordable. But I want to say Apple only turned it on by default, like, the NFC reader in the iPhone in the last, like, 18 to 24 months, right? Like, it started...like, it's been around for a while, but they're sort of slowly kind of...and now you just sort of see it everywhere. People are using it on the subways in New York to scan for tickets or for accessing stuff.

+ +

I was also just showing Chris has been prototyping with the ability to sort of keep these on a key ring. So, we have, like, a little chain hole on them. It is [inaudible 27:22] to sort of have this on your backpack or, you know, on a key ring, or something like that. And friends could kind of, like, come up to you and just, like, scan one that looks interesting.

+ +

CHRIS: And yeah, something that's awesome about this is you don't need an app. You don't need to download anything. As long as your NFC reader is on when you scan this, it will bring you to the music that it's linked to, which I think is awesome. So, I mean, my dream is to have these, like, hanging off of people's backpacks so I can, like, scan them in the subway or, you know, it's such, like, an easy thing to do. And it requires so little technical time on the user's end to be able to do it.

+ +

LINDSEY: Oh, we got a question here. "So, Moo used to offer NFC cards. What made you decide to do the thicker plywood model?"

+ +

CHRIS: Durability is really what it comes down to. We wanted something that felt like an object that you can have and treasure. Like, these have weight, you know, these feel like something, not just a piece of paper. This is something that you can have and [inaudible 28:22] your desk, and it's not going to fade in the sunlight. It's not going to disintegrate over time. This is something that's going to last.

+ +

MIKE: Yeah, the cards would definitely, like, as I would sort of carry them around and show them to people and stuff, the cards would start, you know, breaking. It's like having a business card in your pocket, right? Eventually, it's going to kind of wear out. And plus, we had, like, the stickers were visible on the back of them. And we were, like, having the sticker just completely disappear inside the wood; it just feels a little bit more like magic.

+ +

LINDSEY: Well, thanks for demoing there. I put you on the spot a little bit. But they are...I had seen them in the Slack, and they're very cool [laughs]. So, I had to ask if we could show them off a bit.

+ +

MIKE: Of course.

+ +

CHRIS: I think another thing to think about, too, is we've been talking a lot about the user experience. But if and when we get to the point of making these for artists, artists will be able to collect so much data off of the way that people buy and collect and use these things over time, which is something that we're really, really excited about. And also, you know, we're working on a way to make the link in the object updatable over time. So, artists will be able to change what a card points do to inform their users about the latest and greatest thing.

+ +

LINDSEY: Very cool. Jordyn, what's next on the programming agenda for Chris and Mike?

+ +

JORDYN: It's really sort of we're in this, like, iterative cycle. So, we're talking to folks. We're working on the website. The conversations we're having with people are informing how we're framing this first experiment with the mixtape, how we're marketing it, who we're marketing it to. I think next up is probably a Google Ad experiment to really see if we can piggyback on some stuff or at least figure out a new consumer product. It's so tough, right?

+ +

It's also not a thing people are searching for. So, we have to come up with some experiments for how we get people to that website [laughs]. So, you know, Google Ads funnels is just something you kind of have to do because it's very interesting to figure out what people are responding to, what people are searching for. But we're going to have a bunch of other experiments as well and non-experiments. Outbound experiments: can we go to people? Can we get listed in a gift-buying guide for the holidays? Or, like, we don't know. There's a bunch of experiments we need to do around that, which is really just this iteration.

+ +

We won't stop talking to users, but, you know, everything we're hearing from them will inform where we go and how we talk to the folks in those places where we end up. And really, it's just about starting...once this is up and, you know, there's, like, an orderable thing, there's, like, a whole data cycle where we start to learn from the stuff we're testing; we actually have some real data for it, and we can start to tweak, iterate and change our strategy.

+ +

But the bigger thing, also, is this bigger platform. So, the next thing really, the big next thing, is to sort of start to scope and create an architecture idea. What's it going to take to build the actual backend thing? And it's the thing that thoughtbot really [laughs] excels at, which is software. So, you know, that's the big next kind of project. Once the mixtape experiment is sort of out and in flight and we're getting data, we really need to turn our attention to the technical backend.

+ +

LINDSEY: Exciting. Another comment/question from Jeff, who maybe needs a user interview. "Love the crate more than the actual albums. Maybe offer collections of artists."

+ +

MIKE: Yeah, that's the plan.

+ +

CHRIS: Yeah, definitely. It's a good idea. Yeah, it's, I mean, and labels get to, especially, like, small indie labels get really excited about doing, like, crates worth of collections of different artists or, like, you know, digging through their back catalog, their subscription services. There's a lot of different angles for sure about that idea.

+ +

LINDSEY: [inaudible 31:55] Chris and Mike, going into this next section of the programming, for anyone watching right now, or watching the recording, or listening to the recording, any action items from them? You know, are you looking for any user interviews or have any survey or any destinations you'd like to send people yet?

+ +

CHRIS: Not quite yet, but soon, I would say. Well --

+ +

MIKE: I mean, [inaudible 32:19] plug the website, I mean, you know, I think we've got, like, an email to sign up from there, right? The URL is getthegoodz.com and I [crosstalk 32:27]

+ +

LINDSEY: Goodz with a Z.

+ +

MIKE: Goodz with a Z.

+ +

CHRIS: With Z.

+ +

MIKE: So yeah, if you want to go there, you can sign up. I think there's an email signup on there to learn more.

+ +

LINDSEY: Perfect. All right. getthegoodz.com email sign up. To stay up to date on Goodz and the incubator, you can follow along on the thoughtbot blog. You know, as always, send us any questions you might have, and we're happy to get to those. But otherwise, thanks for listening.

+ +

And thank you all — Jordyn, Chris, and Mike. Thanks so much for joining today and sharing and being open about your stories so far.

+ +

MIKE: Thank you.

+ +

CHRIS: Yeah, thank you, Lindsey.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Chris Cerrito and Mike Rosenthal.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ZOjuS_d6 + + ]]> + + Lindsey Christensen + Chris Cerrito + Mike Rosenthal + + + 499: Infinite Red with Jamon Holmgren + https://podcast.thoughtbot.com/499 + f244fe72-ce42-47f8-b563-aee8c44c14ed + Thu, 09 Nov 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Jamon Holmgren is the founder of Infinite Red, a consultancy specializing in React Native. He discusses his journey and insights into technology and leadership and highlights how Infinite Red stands as a testament that businesses can be run ethically while still achieving success. + +The conversation then shifts to leadership styles and the principle of "one-minute praise" from the book "One Minute Manager." Both Jamon and Will agree that acknowledging others' efforts openly can make a significant difference, enhancing leadership skills and building stronger relationships. Will points out how this simple principle has been a game-changer for him in various aspects of life, including his personal relationships. + +Towards the end, the focus turns to motivation and long-term strategy. Jamon is driven by his enthusiasm for learning and the thrill of tackling diverse challenges in his consultancy work. He also shares his philosophy of keeping the company "10 degrees above the horizon," emphasizing steady, sustainable growth rather than erratic leaps and bounds. + 47:46 + no + + + Jamon Holmgren is the founder of Infinite Red, a consultancy specializing in React Native. He discusses his journey and insights into technology and leadership and highlights how Infinite Red stands as a testament that businesses can be run ethically while still achieving success. +The conversation shifts to leadership styles and the principle of "one-minute praise" from the book "One Minute Manager." Both Jamon and Will agree that acknowledging others' efforts openly can make a significant difference, enhancing leadership skills and building stronger relationships. Will points out how this simple principle has been a game-changer for him in various aspects of life, including his personal relationships. +Towards the end, the focus turns to motivation and long-term strategy. Jamon is driven by his enthusiasm for learning and the thrill of tackling diverse challenges in his consultancy work. He also shares his philosophy of keeping the company "10 degrees above the horizon," emphasizing steady, sustainable growth rather than erratic leaps and bounds. +Infinite Red (https://infinite.red/) +Follow Infinite Red on LinkedIn (https://www.linkedin.com/company/infinitered/), X (https://twitter.com/infinite_red), YouTube (https://www.youtube.com/channel/UCwpSzVt7QpLDbCnPXqR97-g), GitHub (https://github.com/infinitered), Facebook (https://www.facebook.com/infiniteredinc/), or Instagram (https://www.instagram.com/infinitered_designers/). +Follow Jamon Holmgren on LinkedIn (https://www.linkedin.com/in/jamonholmgren/) or X (https://twitter.com/jamonholmgren). Visit his website at jamon.dev (https://jamon.dev/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Jamon Holmgren, Co-Founder and CTO of Infinite Red, a software consulting agency that specializes in React Native. Jamon, thank you for joining me. +JAMON: Yeah. Thanks for having me. I really appreciate it. +WILL: So, Jamon, what's going on in your life? How's everything going? +JAMON: You know, things have been obviously very busy, like, I guess, pretty much everybody. You know, school has started. I have four kids, so that keeps me quite busy, going to various school events, going to volleyball, you know, bringing kids here and there, running the company. I have some side projects I'm doing. I am playing hockey. So, it just seems like every waking hour is filled with something. +[laughter] +WILL: I totally understand that. I have three kids of my own. So, they're a little bit younger than yours, so mine is 4, 3, and, like, 17 months, so... +JAMON: Okay. Yeah, so you're just getting started. And you're doing all of the, like, physical labor associated with being a parent. +WILL: Yes, yes, yes. So, I want to start there. Tell me a little bit about your kids. I know their ages are 10 to 18. +JAMON: Yeah, so I have a boy, Cedric. He's actually a programmer as well. He's just starting his career. He is the oldest, and then we have three girls. We have a 15-year-old who's a sophomore in high school. And then we have a 12-year-old who's in middle school and a 10-year-old who is in fifth grade in elementary school. And it's a lot. +My wife and I both came from very large families, so we're kind of used to it. And it's a lot of fun. A lot of challenges at this age, I mean, teenagers especially, you know, as they kind of all come into that same era, you know, it's more of a challenge. I guess the thing that I think about it is a lot of the skills that I learned as a young kid parent don't really translate super well to being a teenager parent. And I'm having to learn a lot of new skills. And I actually talked to a guy the other day. His kids are, I think, 32 and 28, or something like that. And he said, "Yeah, the learning never stops." [laughs] +WILL: So, I'm going to ask you for the secret sauce because I'm still in the temper tantrums and those type of emotions and stuff. So, how is it different in the teenage years from the temper tantrums? +JAMON: Well, I think that they can act like adults in a lot of cases, and you start thinking of them as adults, and you start developing a relationship there. But their brains are also not fully developed. And so, they will also do things that are very inexplicable, like, you'll just be like, why? Why would this be a thing? Like, I don't get it. Like, you act like an adult for half the time, and then the other half, you act like a kid. Navigating that, and the fact that they change all the time, and all the other challenges. +And they're all different. Like, if we had only had one kid, you know, my boy was pretty easy. He was pretty straightforward. It would have been like, well, shoot, being a parent is pretty easy. Like, I don't know what everybody else is complaining about. Like, he never did tantrums. He was just a really quiet, you know, like, well-behaved kid and kind of went through life like that. But then, obviously, developing a relationship with him is more of the challenge because he's quieter, where with my girls, it's easier to develop the relationship, but then you [laughs] deal with a lot more volatility as well. So, they're all different. Every kid's different. It's hard to really apply that directly. +I would say that the thing that I've learned the most in the last few years is just kind of continuing to be, like, even through some of the tougher times, continuing to be there, continuing to develop that relationship. A lot of times, it feels like you're not getting anywhere, but you are. It is actually happening. You just don't see it until later. +WILL: I'm writing that down. That's great advice [laughter]. You mentioned hockey. Tell me about it. I've never played hockey. I grew up in the South, so we didn't have that. So, tell me about it. And you're a goalie also, correct? +JAMON: Yeah, I play goalie. I didn't discover hockey...I played basketball in high school. I played four years of high school basketball. I even played a little bit at college. And I didn't really discover hockey until I moved to Southwest Washington, about an hour away from where I grew up in the coast of Oregon. When I got there, a lot of my friends that I made were playing hockey. And one friend, in particular, he was a goalie, and he had grown up in Upper Michigan. So, you know, like, he grew up playing hockey. He was a very good skater and things like that. +But there was one weekend I was coming to watch him play just rec hockey. And he's like, "You know what? I can't make it. Would you want to jump in and, like, be my sub?" And it was just a pick-up game. So, it wasn't like there was anything on the line. And I was like, "All right, I'll give it a try." You know, put on the gear. He showed me what to do to put on the gear. He kind of gave me some tips. Like, in the living room where we were, he was, like, showing me how to play. +We were, like, I would say, 19, I think. Nineteen years old, something like that. Anyway, I show up, and I put on the gear, and I go out there. And I actually had a decent game, considering I barely knew how to skate and barely knew how to do anything. But I'm kind of big; I'm six foot four, almost six foot five. And having all that gear and everything, I filled up a lot of the net. And it wasn't a very high-level game, so I did pretty well. +And after that, the team was like, "Well, we'd love to have you back." And then my friend really was not interested in continuing, so he was like, "You can have it, like, just roll with it." I kept playing for about three years, and then, I don't know, I took over a decade off. The team dissolved. It wasn't even a league team. It was just, you know, pick-up hockey. +And then a friend called me and was like, "Hey, I'm starting up a game. It's going to be Finnish Americans," because I'm half-Finnish myself. "So, it's going to be all Finnish Americans. We're going to call it the [Foreign language]," which is the Finnish boys in sort of Finnish. It's not exactly supposed to be like that in Finnish. Anybody listening who's Finnish is going to be like, "Yeah, that's bad Finnish." But it kind of means Finnish boys or Finland boys. +And we put together the team, and I've been playing for the last three-plus years. It's been kind of, like, a rec league team. We've won the championship four times, which was really fun. This year, I'm actually playing in two leagues. I'm playing in rec league, and I'm also playing the next league up, so a little bit faster, better skaters, better shooters, things like that. And I just love it. It's so much fun. +WILL: Wow, that's amazing that you started later and that you're still playing it. Because when I look at hockey, I'm like, that's really hard. I don't know if I could do that. I can skate. I can't stop. +JAMON: [laughs] +WILL: Like, I can get a lot of speed [laughs]. But it's just something about turning sideways and thinking I'm going to fly over the skates. +JAMON: [laughs] +WILL: And yeah, it's a whole thing [laughs]. Is goalie harder than playing any of the other positions? +JAMON: I would say it's different. Like, I don't have to be as good of a skater, you know, things like hockey stops are still not supernatural for me. I don't skate backwards super-fast. You know, I'm not a fast skater in general. But the difference is, of course, you have to be reading the flow of the game. You have to know the body language of the players that are coming at you. You have to kind of see what's happening. At the end of the day, lots of things can happen, so you try to put yourself in the best position. +It's a lot of, like, positional, like, where are you in the net? What does your position look like? And then, once they shoot, how do you react? Are you dropping down, or are you staying up? Are you using your glove? Are you using your blocker? Are you just trying to block with your body using your stick? Then, once the puck hits you, then what do you do? How do you control the rebound? Are you trying to cover it up and ice the puck so they do a face-off? Are you trying to kick it out to one of your skaters? +And then, once that happens, you have a little bit of a rest, hopefully, while they're down on the other side. But you're continually alert and watching to see what's going to develop because it could be a breakaway. And then it's just you and the skater and trying to anticipate what they're doing and try to make it so that they have to make a play. Like, just be big, be in position. Don't get out of position. Don't make a mistake. +And I've had really great games where I've, you know, had 45 shots on me, and I've only let one in or something like that. And I've had some bad games too. I know there's one game in a championship where they only had six shots on me. But we ended up losing because I let in two, so that was not a fun game. I only had six opportunities, and I failed on two of them. But that happens, and so you just have to be mentally tough. +WILL: Wow, that's amazing. The limited knowledge of hockey...I'm going to assume here, so I hope it's right. With you being 6'4, 6'5, I'm guessing that the five-hole, if I'm correct, was probably your toughest position to defend. +JAMON: You know, you would think so. And just for the audience, the five-hole is, like, between your legs, you know, the puck going between your legs underneath. But I play a style...a little bit older style of goalie because that's what I watched. You know, in, like, the early 2000s, I watched Patrick Roy of the Colorado Avalanche, one of the greatest goalies of all time, and he played what's called a butterfly style. +So, as the play develops, you're standing, but then you go down fairly early, and you're protecting the bottom. You have your stick in front of you protecting the five-hole, and you have your legs, you know, spread out. So, I used my height really more for blocking as I'm down rather than standing because when I'm standing, I'm above the net. It's better for me to get down. And I think that that's worked out pretty well. +You know, Patrick Roy was a pretty big goalie as well. Most modern goalies play a more hybrid style. But, you know, we could get into all that. I'm a big kind of hockey nerd in this way. But that's what I do. I play butterfly, so most of the time, people don't beat me five-hole; when they do, it's usually they're picking a corner. +WILL: Wow. Now that you've painted the picture, I can see how that's smart because you do have the goal, I mean, the gloves plus the stick and then your height. Yeah, I can see how...that's smart. That's very smart [laughs]. +JAMON: Yeah, that's right. Yeah, that's kind of the goal. And also, because I wasn't a great skater, it sort of played into it as well, playing down on the ice where I was just more comfortable that way. It's worked out. I've had a pretty decent record over my career here [laughs]. +WILL: That's awesome. Well, let's transition a little bit into consultant agencies. You've been doing it for 18 years. Tell me about that. How did you get started? +JAMON: Well, when I started, I was working in construction. I was working for a home builder. And, you know, everybody I knew pretty much worked in construction, including my dad, who owned a business. And I went on my own. I had always dreamed of owning my own business, but I didn't start really thinking about websites. I was coding. I loved coding, and I was coding since I was 12. +So, when I got to 23 years old, I thought, I'll start a business, and I'll do home design because that's what I was doing for the builder was, I was drawing homes. I was designing homes and remodels and things like that. And so, I started it doing that. But I also needed a little bit extra work. I didn't have enough work. Like, I had people, you know, sending me work, you know, home design and whatnot, but I didn't have quite enough. So, I would also build websites on the side, PHP and HTML, MySQL, and JavaScript. And I just sort of continued to do that. +But in 2008, there was the housing crisis, and all of the design work for homes just dried up. There wasn't much there. In fact, it actually really dried up in 2007 because things kind of started a little early for designers. And so, I was like; I got to do something to stay busy. I've got a wife. I've got a young kid (Actually, at that point, I had two kids.), and I need to make sure that I'm staying busy. And so, I really ramped up trying to find work, you know, as a programmer, as a web developer. +And there were plenty of companies at that time that were really trying to drum up business. So, they were putting money into their websites trying to get new projects, and they were all construction companies. And so, that's how I started. And I started doing more things like internal web apps for managing orders and managing sales leads, and that sort of thing. And that led me into web apps and eventually to Ruby on Rails, which became sort of my bread and butter for a while. +As I was doing Ruby on Rails, you know, obviously, the iPhone was out, but the iPad came out. And I was more of an Android guy at that point. But I bought an iPad because it looked really cool, and my dad had one. When I started playing around with it, I'm like, I need to build apps for this. This is super cool. So, I took some Stanford courses online, which you could do back in those days, iTunes U, and learned how to use Objective-C. +This was previous to Automatic Reference Counting and stuff. So, you had to manage your own memory, and this was a lot of manual work; very different environment than JavaScript, and PHP, and Ruby. But I actually enjoyed it quite a bit and then eventually transitioned into React Native later. But really, getting over to mobile and that sort of thing was...once I found mobile, I really didn't want to do web anymore. Mobile is what I really enjoy doing. +WILL: Wow, I love that. If I'm following you correctly, you said in 2007, that's kind of when everything dried up. So, you were almost forced to find something different, correct? +JAMON: Yeah, that's right. I mean, I kind of sat around feeling sorry for myself for a while. And then I was like, well, it's my business. I got to figure out what to do. It's not anybody else's fault. Like, you know, it doesn't matter that this is forces out of my control. I do have control. I have the ability to go in there and figure out, okay, what do I do next? Well, I know how to program, and it seems like people want me to program. So, let's lean into that. +WILL: Wow. I love that. Because it's funny, that's how I got started in programming. I lost my job. And I was working at Buckle, the clothing store. If you know me, that is not me at all, like, at all [laughter]. I love gym shorts and athletic clothes. Like, fashion is not my thing. It's just not. So [laughs], I got into programming because I was just struggling. And it was a very pivotal moment in my life. And I'm thankful that I lost my job. Losing your job is just hard, and I think it makes you rethink things. +JAMON: Yeah, absolutely. It was a growth moment for me as well, one of many. But that was definitely a point that I look back on and say, I mean because I can actually point at almost the day when it all dried up. It was, like, April 2007. And my uncle had been sending me a lot of work, you know, he had extra work. He didn't have barely enough for himself anymore at that point. And I finished up my last project, and he's like, "I don't have anything else." And I had some other clients as well and called them up, and they were like, "No, we don't have anything. Like, nobody is buying right now." And it just kept going like that. +And it was weird because 2005, 2006, most of 2007, it felt like things were really rolling, but it just dried up all at once. And so, I was really lucky that I did end up getting a bunch of web work to do in 2008. I was still doing home design till probably late 2008, 2009. But then I eventually just hung that up and was like, okay, this is over. I'm definitely focusing on programming. +WILL: Wow, how was the initial traction when you moved into ramping up the web development? +JAMON: It was really good because it didn't take much to keep me busy. And I ended up getting some big contracts from, like, a cabinet manufacturer was a big one. I did some other things as well. And I ended up hiring my first employees in 2009. So, really, less than two years later, I was starting to hire employees. And I just hired, like, junior developers who had barely learned to code and taught them to code. So, I hired probably, over the years, next few years, like, ten programmers, many of whom are actually still with me today, and I taught them to code back in the day. +And as time went on, they became senior and really high-level programmers who are now leading projects for big companies that you've heard of. But they started with me building, you know, PHP and MySQL and whatnot for small, like, regional construction companies. And we learned together. So, it was definitely a progression you can go look back and see. +WILL: Yeah, I saw a tweet that you tweeted, and I loved it because I totally understand. +JAMON: [laughs] +WILL: And so, I'm glad you mentioned the junior devs and stuff. The tweet that I'm talking about was, "I got into this industry to code; ended up becoming a founder because I was the only person who would hire me." +JAMON: [laughs] +WILL: I want to ask you about that. +[laughter] +JAMON: Yeah, it's really that I grew up in a small logging town, like, very tiny logging town in Northwest Oregon. I didn't know...I knew one programmer, and the guy was, like, an incredible genius. And I just thought that that was the only way that you could professionally be a programmer was to be an incredible genius. I was coding, but I was, like, coding games, you know, in QBasic. And so, for me, every time I looked around, it was just, like, construction, or logging or, you know, blue collar, like, working at a mill. Like, these were the things that I saw around me. And so, that was the path I went. +And I didn't really think of using this passion that I had for coding to turn it into, like, actual money. And when I did start thinking about it, I was like, I don't know anybody who does software. Like, even when I moved to Southwest Washington, I was closer to Portland. But I thought you had to have a CS degree, and I didn't have a CS degree. So, I was like, okay, well, I'll start my own business then, and that will be the thing that kind of leads me into tech. And that's what ended up happening. +And it's kind of funny because I did go to, you know, one semester of community college for basketball and for...until I got cut. And then I studied some things there. But I never finished for the community college. What's kind of cool, though, is today, I'm actually on their, like, tech advisory committee. Like, they actually have me advising their professors on the current state of tech, which is kind of cool. +WILL: Wow, that is really cool. It is interesting because I remember when I first started out and that feeling of probably over 300 applications just trying to get a job. And it was just hard. And my first job, to be honest, I think it was because of networking is why I got the job. If I didn't know the person that introduced me to the company, I probably wouldn't have gotten the job, if I'm being honest. +But I am very sympathetic for junior devs anytime. If a junior dev asks me a question, I will take time, help them out. Because I remember...it's very hard as a junior dev trying to get that first job. So, when you said that, I was like, yeah, I can see your heart towards junior devs. +JAMON: Absolutely. That's where I started. You know, the first developers that I hired were all juniors. We don't hire juniors anymore because of the style of business that we are. But I miss that. I miss that to some degree. We really can't. And we've looked at it from just about every angle. But I did my time [laughs]. I spent a lot of hours teaching junior developers when I could have done it quicker myself. +WILL: Definitely. Like, you end up losing some money when you do a junior dev and you're hiring for the future. So, like, in a consultant agency, I totally understand that, yeah. +JAMON: Yeah, absolutely. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +WILL: So, I want to ask you about the transition from ClearSight Studio to Infinite Red. How did that happen? +JAMON: ClearSight was my first company. And it sort of evolved from being a, you know, a home design/website company to just a website and web app company, and then mobile apps. And, at a certain time, we had, I think, around 12 employees, something like that. I had a design department. We were building websites and whatnot. And I was really interested in iOS development. That was really my passion. +And so I actually ended up working on some open source with iOS developers across the globe and then got invited to a conference down in San Francisco in 2014. And I went and gave a talk there. It was my first tech conference that I'd ever been to, much less given a talk, and I was the first talk [laughs]. So, that was kind of an interesting little anecdote there. +And as I did it, I got to know some other developers. I had one in particular, Todd Werth, who I really hit it off with, and we ended up chatting a lot after the conference. And it felt like he and I had a very similar outlook. And he had an iOS agency. That's all they did. +Well, 2015 rolls around, and I had had some rough times toward the end of 2014 in terms of the business, and I was kind of complaining to Todd. He had had some issues as well, and we started commiserating. And he's like, you know, he just started joking. I still have this conversation in Slack way back if I go look. And he's like, "Well, maybe we should just merge our businesses together," because it felt like we had maybe complementary skills. And we had a similar outlook on what we wanted from our businesses. And so, we ended up eventually solidifying that. I flew down there, talked to him and his business partner, Ken, at the time. We ended up making that happen later that year. +So, just a few days ago, October 1st was our eighth anniversary running the companies, running the new company, the merged company, which is Infinite Red. So, that was kind of how that all came together. Eventually, Ken left, and we had a new business partner who was our top employee buy-in; that's Gant Laborde. And so, there are still three owners. We have three directors and then the rest of the team. We're about 30 people altogether, and we focus entirely on React Native. +WILL: Wow, congratulations on eight years. That's a lot. That's amazing. +JAMON: Yeah, thank you. I was just thinking the other day that I ran ClearSight for ten years. Infinite Red is getting close to how long I ran my first business. And, like, my youngest is, like I said, 10. So she was only two years old when I merged the company. She does not remember my old company, which is weird to me. +[laughter] +WILL: Wow. So, can you walk me through your decision to go here with React Native and specialize in that? Because it sounds like right around the time when React Native was created, and people started using it in production. +JAMON: That's right. The iOS technology that we had sort of bonded over at that conference was called RubyMotion. But in 2015, the founder ended up going to work for Microsoft for a while and then went back to Apple. He had been from Apple before. So, it was sort of going down. And we were looking for a different technology, both of our companies were, and then, of course, the merged company. +React Native looked interesting, but it didn't have an Android version yet. But then, in September of 2015, Android came out, so it was iOS and Android. So, we were able to take a look at that one month before we ended up solidifying the actual merger. So, basically, day one, October 1st, 2015, we were, like, we are now doing React Native for mobile, but we kept doing web. We kept doing Ruby on Rails. We did some Elixir. We did some Elm. We did some...I think we had some old Ember stuff going on. We had all kinds of things going on. +But over time, we got more and more traction with React Native because that's really where our interest was. And so, we ended up saying, okay, well, this is where we really want to be. It took us a few years. It took us probably five years, six years, something like that, to really develop the confidence to say, "Hey, this is all we want to do," because it's a risk. Like, you put yourself on one technology. We had that before with the other technology that went down. But we had the confidence that we knew we could step off of a sinking ship onto another one if we needed to. So, we said, "You know what? Let's do this." +And I got to give my co-founder, Todd, a lot of credit because he was the first one to say, "Let's go all React Native. Anywhere that React Native is, React Native is on a lot of different platforms. You can do tvOS. You can do Mac. You can do Windows. You can do web with React Native web, all kinds of things. So, let's just focus on React Native. Our team will just focus on that. We will only hire React Native developers. All of our marketing is going to be around React Native. Let's just focus on that." +And it ended up being a great call. We did that. We made that happen. And for probably the last, I would say, three, four years, something like that, that's all we've been doing. +WILL: So, what's your opinion on, I guess, the argument that's being held right now with native iOS and Android, even the Flutter, and I think Ionic is the other one that I've heard of, versus React Native? What's your pitch on React Native over those? +JAMON: There's definitely reasons to use any of those. But I wrote this article a while back. It was specifically about Flutter, but I think it applies to a lot of the other competitors as well. The title of the article was provocatively titled, "Flutter Is Better Than React Native in All the Ways That Don't Matter." And the idea behind this is that, yes, Flutter gets a lot of things very right. A lot of their developer experience is actually better than React Native; some is worse, but, you know, some is better. +But really, when it comes down to it, the things that matter are more business level. React Native is good enough. It's like native views. So, you have the native performance. With Hermes, you have really good performance in JavaScript. So, you know that you can get really high-level JavaScript performance. You can ship JavaScript, which really helps because then you can bring in JavaScript developers, and specifically React developers. +So, a lot of companies already use React. It's a no-brainer to then use React Native if you're already using React Web. It doesn't really make sense to go to Flutter. It makes maybe some sense to write it in native, but then you have to write it twice. And you have three teams. You have a web team. You have an iOS team, and you have an Android team. And you also have three codebases, and one's always lagging behind. That's always what's happening. +Marketing is like, "Okay, when can we announce this?" "Well, iOS isn't done," or "Android is not done," or "Web is not done." Where if you can combine all of those things and combine just the culture of your team, then it becomes more tight-knit because everybody's working on all aspects at one time. You can take a feature, and you can build it in web, and you can build it in iOS, and you can build it Android with all the same skills. +Now, there are some deeper parts of React Native. It goes really deep. But in terms of just being productive out of the gate, a React developer can be productive in week one, and that's, I think, a huge deal. So, it really comes down to is the performance and developer experience good enough? And the answer is absolutely yes. +And then, secondly, like, what's the business case for React Native? Well, you can have the same developers doing iOS, Android, and web, and even if you don't, you can share techniques. You can be like, "Hey, here's this cool JavaScript thing," and the Kotlin developers aren't just like, "Ugh, you know, JavaScript." Or you can be like, "Hey, here's our TypeScript configuration across the whole codebase." You can even have a monorepo with everything in it. It just makes a lot of sense that way. And especially now with Expo, it makes it even more that way because Expo removes a lot of the barriers for web developers that they would have coming into native. +So, with that in mind, I still see React Native dominating the apps that are at the top of the App Store. One of the Expo developers, Evan Bacon, has put out a bunch of tweets about, you know, like, 24 out of the top 100 food and drink apps are written in React Native, as opposed to 8 in all the other options combined other than native, you know. So, it gives a good sense that React Native is still growing and continuing to. It has a lot of steam behind it. +WILL: Yeah, I totally agree with you. I'm a big React Native fan, and I do a lot of React Native work here. So, yes, totally agree with you. And one of the most frustrating things that I've come across is, I'm a big researcher, and so I'll research things, and I'm like, oh, there's an app for this. And I'm a big Android fan, so when I go to them, it's like, oh yes, I can use this app. And then it's like, no, I can't. It's only for iOS. Okay, like, you lost me as a customer. +JAMON: [laughs] +WILL: I was willing to pay whatever on this because I've been looking for it. So yeah, I like how you said that. +JAMON: Yeah. It treats all of the platforms as first-class citizens. +WILL: Yes. Yes, yes, yes. Totally agree. How does your company handle the backend? Do y'all do any of the backend, or how is that handled at Infinite Red? +JAMON: We used to do that, like I mentioned. But a few years ago...we had a very, very small back-end team by then. Most of the time, and now pretty much 100% of the time, when someone comes to us, they already have a back-end team, so we work directly with them. A lot of our developers were back-end developers, and so they understand the backend really well, but they're obviously React Native specialists now. +So, you know, I came from that. I did PHP. I did Ruby, Ruby on Rails, Elixir, Node, all kinds of back-end technology. So, I understand it really well as well. But yeah, we lean on our clients for that. We might partner with an agency like you folks over there at thoughtbot and have them do the backend, or just have the client, you know, come up with their own solution. +WILL: Yeah, I love that, yeah. And we've done that with numerous agencies, so yeah, that's awesome. What does success look like for Infinite Red now versus, you know, six months or five years from now? Do y'all have any goals in mind that you're trying to hit? +JAMON: In the Infinite Red leadership, we are currently reading John Maxwell's 21 indisputable Laws of Leadership, which is a good book. And we had this really great conversation at our first book club meeting in leadership, which John Maxwell defines success in a very different way than we do. You know, he measured it as, like, McDonald's, or Starbucks, or something like that, like, giant, becoming huge, becoming big, making tons of money. And it was sort of just implicit in the book that that was the case. +We had this great talk internally. Why didn't this resonate with us? And that's because we don't really measure success that way. So, I love that question, Will, because measuring success is you really have to start there. Like, you have to start there and say, "What do we want from this?" So, ultimately, we want to build cool things with our friends. I'm a coding nerd. I want to code. I want to be in the code. That's why we're an agency. Like, if we were a product company, if we were building, I don't know, podcasting software or something, we'd have to become experts in podcasting rather than experts in React Native, or experts in TypeScript, or whatever we want to do. +So, we really love code. We want to build that. We want to have an amazing family-first environment. We want to treat everybody super well. We want to have really low turnover, which we've been able to achieve. Hardly anybody leaves Infinite Red. Maybe every other year, we might lose one person. And even with those people, they tend to come back [laughs], which is a great sign. They go out and find out that, yeah, actually, Infinite Red is pretty awesome, and they come back. So, we really look for that. We really focus on that. We want that to happen. +And it's really less about making the most money we can. Obviously, everybody wants to be well paid. And so, we're going to try to make sure we have a successful business in that way and that we want to be around for a long time. But, really, measuring success is less about business success and it's more about life success. It's really more about family success, being with my four kids, being there for them when they need me to be. That's why we're remote, you know, as another example. So, everything really hinges off of that. It's around happiness. It's around fulfillment. It's not around financial success. +WILL: I'm a huge John Maxwell fan, by the way. +JAMON: [laughs] There you go. +WILL: So, yes, I love it. And I love how you explained, you know, because one of my questions I was going to ask you is about the core values, but I'm going to switch it up a little bit. So, I'm just going to say, in my opinion, I feel like there's almost leadership talk void at times, especially in the tech space. Like, we don't talk about leadership a lot. But it plays a huge part in what we do day to day. Like, you named a couple of core values and principles that you're following because of the leadership. So, for you, why is the leadership so important and I guess you can say have a seat at the table at Infinite Red? +JAMON: I'm a strong believer, and I've become more of a strong believer over time, that it all starts at the top. If you don't have buy-in from your top leadership, it does not really matter what happens otherwise because they will continually undermine, and they have the power to continually undermine that. So, these core values have to apply to the top leaders. They have to be held accountable to that. And these leaders also need to be developed. +So, we have three owners. We have three directors. And the three directors who are underneath us were not directors when we hired them; you know, they started out as developers. They started out as designers. They started out as project managers. But they became Director of Operations, Director of Engineering, Director of Communications. And we developed them. We poured a lot of time into them, and we continue to do that. In fact, even reading this book with them and going through that exercise is continuing to invest in them. Not that we as owners don't have growth to do; we also do. And so, we learn from them, and we learn from our team. So, you have to start there. +And on that same vein, we do have some core values. We call them our foundation and our pillars. We have three foundational things, and we have four pillars. So, the three foundations are: one, we control our own destiny. We are not going to be beholden to some other company. We're not going to ride someone else's coattails. We're not going to be in a situation where someone else can kill us. And it can be easily done that way where we're in a position where, you know, we're too reliant on one whale client or something like that. We just won't do it. +The second foundational thing is that we have...it's a word bonitas, which means kindness, friendliness, benevolence, blamelessness. And it's basically just being a good person to everybody and doing the right thing. +And the third one is having a significant positive impact. That's why we do so much media. That's why we try to have an impact outside. And we're only 30 people, but people think we're way bigger because of how we kind of present ourselves in the world. And then our pillars all support those things, so high personal support. We support each other. We have high expectations, but we also support each other not just at work but also as a whole person. +Long-term viewpoint, we think way beyond this year. We think about what is Infinite Red going to be when I retire? You know, I'm 41; that's a ways out, hopefully. But what's that going to look like? +The next one is collaborative creativity. Creativity by yourself is just a solo thing. We're a team, so it has to be collaborative. We have to do it together. All our creative work, whether it's our conference, Chain React, or our work, it's all collaborative, and we love being creative. +And the last thing is being pioneers, pioneering spirit. We like to be pioneers in technology. We put out a lot of open source. And we try to bring that pioneering spirit everywhere we go. And then, there's a lot of different things that kind of come out of that. For example, we have this internal saying, which is, "Don't do hard things alone." +So, you have a hard thing coming up? And it could be hard in various ways. It could be a technically challenging thing. It could just be hard because of the mood you're in that day. But don't do it alone. Ask someone to help you, you know, jump in with you, pair with you. Do it together. And we love that. That's part of the high personal support and the bonitas. So, all these things come out of the foundation and pillars that we have. +WILL: Wow, I love all those. I want to pick one of them out and ask you a question around it. So, you're talking about having an impact. I'm loving this conversation just talking to you. It's just been amazing. So, for you, what do you want the impact on the world to be from your perspective? +JAMON: That's a hard question to answer, and it tends to be something that I think about a lot. I'm more of an opportunistic person. I react more than I plan ahead, that sort of thing. But with that said, I think that we have had significant positive impact through a lot of different ways. So, on Twitter, for example, I try to present a...and this is authentically who I am. But I try to present a positive force out there, someone who's excited and enthusiastic about the technology, who supports other people, even who you might consider competitors, for example. +I just retweeted recently a Callstack thing. I mean, you might consider them a competitor. They're another React Native agency. But I love Callstack. They're great people. And I retweeted one of their really amazing resources, which is the ultimate guide to React Native performance, which, by the way, is really good. And if you do React Native, you should check it out. +So, I think what goes around comes around, and I really want to have that positive impact out there. I want to give talks that inspire people. You know, I'm a nerd, and I'm going to nerd out about stuff. And I feel like that has an impact all of its own. So, that's kind of my personal side of it. And then Infinite Red is a showcase that you can run a company the right way. You can treat people the right way. And the company can be successful along our own metrics of success. +WILL: So, one of my biggest principles that I've learned in life that's changed my leadership 100,000% is from this book called One Minute Manager. And I think it's called one-minute praise. And, essentially, the background behind it is, if you think something, just tell the person because so many times...and I get in my head, and I think amazing things about people, but I never say it. +JAMON: [laughs] +WILL: So, I want to just tell you, like, you said, the impact that you're making. You are doing that. Like, one of the reasons why I invited you on the show was because of your impact that I see that you're having on Twitter and LinkedIn and just everything that you're doing at Infinite Red. So, keep going. I want you to know that you are making a difference. I see you, and it's making a big difference in my life. +JAMON: I love that, and it makes me feel great. And I appreciate you sharing that one-minute praise there. It is something that sometimes you put it out there, and you don't really know what the impact is, you know, it's sort of hidden in maybe the likes, or the replies, or whatever. +As an example, I just reached out to my friend Aaron Francis last night, and I told him, "Hey, I love your videos." I don't even do the tech that he does. But I watch his videos on YouTube because I just love the vibe that he has. And I told him that. I was like, "You're doing a great job. You're being a very good advocate for your company." And I agree with you; I think that just taking the moment to reach out and say, "Hey, I think you're doing good work," it encourages people to do more of it. So, I appreciate it a lot, Will. That's really nice of you to say. +WILL: Yeah, definitely. If you can go back, what is some advice that you would give yourself? We could do both at the beginning when you did ClearSight and whenever you merged and did Infinite Red. Was there any advice that you're like, wow, I learned these lessons, and they were game changers for me? +JAMON: [laughs] Boy, this could be a whole nother podcast, to be honest. There are so many different things that I've kind of learned over the years. I feel like, you know, there's value in, you know, there was actually...I forget exactly where I heard this, but it was about Cloudflare, the company. +And a long time ago, as they were sort of launching, one of the people that worked on the...I think it was their founder, actually. One of their investors told him, "Hey, running a company is sort of like flying an airplane. You want to make sure that it's well-maintained at all times. And then, when you're flying, you keep the wheel steady and the nose 10 degrees above the horizon so you continue to rise. And you don't need to shoot for the moon. We're not a rocket here. Just continue to execute well, make sure that it's well maintained, make sure that you're continually rising." +And Cloudflare is a good example of this, and I think that Infinite Red is as well. Every year, we try to do something where we're continuing to keep that nose 10% above the horizon. That doesn't always mean growing. Like, we don't hire all that often. We don't grow in terms of headcount, but we grow in other ways. And you can see that looking back over the years. Every year, there was something that we continued to, you know, improve, keeping that nose 10 degrees above the horizon. And so, that's a big one. And you can just go do all the little things really well and continue to think long term and where are you headed. And if you do the right things long enough, good things happen. +WILL: I love that because, especially when I'm working out, I try to shoot for the moon. +JAMON: [laughs] +WILL: I go all out. So, that was some amazing advice. I don't even remember who told me, but when I first started programming, I tried to shoot for the moon. And, oh, I crashed and burned so many times [laughs] because it's just something you can't just master it, and just like, I got it, da da da. And I love that advice. That's amazing advice. So, that's perfect. +JAMON: Yeah, it really stuck with me, and I have so many more lessons. I have actually kept a notebook of profound things that I've heard over the years, and I actually really enjoy that minute praising you said. And I'm going to look up the quote after this, and I'm going to put it in my notebook. +[laughter] +WILL: Yeah, yeah. It's been a game-changer because I'm a very straightforward person. And so, a lot of times, like, I don't mind addressing an issue just head-on. But what I found is I'm just always doing that. And I never had equity in the bank at times. This is when I was a very young leader. I didn't have equity. And so, it was just hard to tell people, "Hey, can we tweak this? Can we do that?" +And then I had to sit back and say, okay, what can I change to be a better leader? And it's like, I can connect better. And I see so many things. Like, I'm very observant, I think. To be honest, it's helped me in every area, even with my spouse, with my kids, with friends. It's just saying, "Hey, I see what you did. I see that you made breakfast." Or "My kids, I see that you made this beautiful mud pie for me. And it's amazing. So, thank you. Thank you." And so, yeah, it's been a game changer for me. +JAMON: Yeah, one of my friends, his goal was...and he's a leader. And he said that his goal with everyone on one was to give them one thing to change and highlight one thing they did well like you said, equity in the bank. He was talking about when he was a leader of, like, a call bank. And he said, "No matter how bad the call was, I wouldn't give them more than two things to improve because there was no way that they could take ten critiques and improve. They would just be defeated." And then, he would review and see if they could improve one more thing, avoided negative language, things like that. So, that's a really interesting concept. +WILL: Yeah, definitely, definitely. So, I have one other question for you. What motivates you? What's your wind in your sails? What keeps you going? Because I know running a consultant agency is not easy. What keeps you going? +JAMON: For me, motivation tends to be enthusiasm for learning, really more than anything, like going into something new and, like, exploring. I see it more as exploring even than learning. With a consultancy, there's always so many different...it's never the same, you know, there's always some other challenge. And that's one of the reasons I've loved being, you know, a consultancy owner for so many years. You're never dealing with just the same stuff over and over. So, I would say it's really about the exploration that happens, and just loving code, and talking shop, and being around great people. To me, that continues to motivate me. +WILL: I love that. Do you have anything that you would like to promote — personally, Infinite Red, anything? +JAMON: Well, Infinite Red, of course. If you're looking for React Native, we are all senior-level React Native developers. We've been working together for a long time. So, big companies, the biggest ones you can think of, many of them have hired us to, you know, be the experts with their team. We usually put 2 or 3 people on a project, and then the client will come in with 2 to 10 people or whatever they have on their side. And we work with them side by side, teaching them as well as delivering code. So, that's really our bread and butter. +We also put on the biggest and, I think, only U.S.-based React Native conference, and it's called Chain React. It's in Portland. Next year, it's going to be in July. So, go check it out: chainreactconf.com. We'd love to see you all there. I'd love to see you there, Will. And network with all these different React Native developers. There's people from Meta, and Microsoft, Amazon, all over the world, really. And they're some of the best React Native programmers you're going to ever meet, and some great talks, and great food, and a great city. +WILL: Yeah, I would love to be there. Let me ask you this: how is Portland in July? +JAMON: Portland is amazing in July. Sometimes, it can get hot, but for the most part, it's just beautiful. It'll be like 85 degrees, not really any humidity, nice, little breeze. It's just a beautiful weather pattern around Julyish. That's why we chose that time of year. So, definitely, if you're going to be coming to Oregon, Portland, you know, West Coast, July is a great time to come. It's not going to be super, super hot, usually. Sometimes, I mean, we get over 100 sometimes, but no worries, you know, there's AC as well. But for the most part, it's beautiful. +WILL: You sold me already. +JAMON: [laughs] +WILL: So, I live in South Florida, so...[laughs] +JAMON: Yeah, it's going to be different in South Florida in July. +[laughter] +WILL: Awesome. Well, this has been an amazing chat, and just great getting to know you and learning more about Infinite Red. Thank you for being a part of the podcast. +JAMON: Yeah. Thanks for inviting me, Will. It was a lot of fun, and you're a great host. I appreciate it. +WILL: I appreciate it. +JAMON: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Jamon Holmgren. + + + Jamon Holmgren is the founder of Infinite Red, a consultancy specializing in React Native. He discusses his journey and insights into technology and leadership and highlights how Infinite Red stands as a testament that businesses can be run ethically while still achieving success.

+ +

The conversation shifts to leadership styles and the principle of "one-minute praise" from the book "One Minute Manager." Both Jamon and Will agree that acknowledging others' efforts openly can make a significant difference, enhancing leadership skills and building stronger relationships. Will points out how this simple principle has been a game-changer for him in various aspects of life, including his personal relationships.

+ +

Towards the end, the focus turns to motivation and long-term strategy. Jamon is driven by his enthusiasm for learning and the thrill of tackling diverse challenges in his consultancy work. He also shares his philosophy of keeping the company "10 degrees above the horizon," emphasizing steady, sustainable growth rather than erratic leaps and bounds.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Jamon Holmgren, Co-Founder and CTO of Infinite Red, a software consulting agency that specializes in React Native. Jamon, thank you for joining me.

+ +

JAMON: Yeah. Thanks for having me. I really appreciate it.

+ +

WILL: So, Jamon, what's going on in your life? How's everything going?

+ +

JAMON: You know, things have been obviously very busy, like, I guess, pretty much everybody. You know, school has started. I have four kids, so that keeps me quite busy, going to various school events, going to volleyball, you know, bringing kids here and there, running the company. I have some side projects I'm doing. I am playing hockey. So, it just seems like every waking hour is filled with something.

+ +

[laughter]

+ +

WILL: I totally understand that. I have three kids of my own. So, they're a little bit younger than yours, so mine is 4, 3, and, like, 17 months, so...

+ +

JAMON: Okay. Yeah, so you're just getting started. And you're doing all of the, like, physical labor associated with being a parent.

+ +

WILL: Yes, yes, yes. So, I want to start there. Tell me a little bit about your kids. I know their ages are 10 to 18.

+ +

JAMON: Yeah, so I have a boy, Cedric. He's actually a programmer as well. He's just starting his career. He is the oldest, and then we have three girls. We have a 15-year-old who's a sophomore in high school. And then we have a 12-year-old who's in middle school and a 10-year-old who is in fifth grade in elementary school. And it's a lot.

+ +

My wife and I both came from very large families, so we're kind of used to it. And it's a lot of fun. A lot of challenges at this age, I mean, teenagers especially, you know, as they kind of all come into that same era, you know, it's more of a challenge. I guess the thing that I think about it is a lot of the skills that I learned as a young kid parent don't really translate super well to being a teenager parent. And I'm having to learn a lot of new skills. And I actually talked to a guy the other day. His kids are, I think, 32 and 28, or something like that. And he said, "Yeah, the learning never stops." [laughs]

+ +

WILL: So, I'm going to ask you for the secret sauce because I'm still in the temper tantrums and those type of emotions and stuff. So, how is it different in the teenage years from the temper tantrums?

+ +

JAMON: Well, I think that they can act like adults in a lot of cases, and you start thinking of them as adults, and you start developing a relationship there. But their brains are also not fully developed. And so, they will also do things that are very inexplicable, like, you'll just be like, why? Why would this be a thing? Like, I don't get it. Like, you act like an adult for half the time, and then the other half, you act like a kid. Navigating that, and the fact that they change all the time, and all the other challenges.

+ +

And they're all different. Like, if we had only had one kid, you know, my boy was pretty easy. He was pretty straightforward. It would have been like, well, shoot, being a parent is pretty easy. Like, I don't know what everybody else is complaining about. Like, he never did tantrums. He was just a really quiet, you know, like, well-behaved kid and kind of went through life like that. But then, obviously, developing a relationship with him is more of the challenge because he's quieter, where with my girls, it's easier to develop the relationship, but then you [laughs] deal with a lot more volatility as well. So, they're all different. Every kid's different. It's hard to really apply that directly.

+ +

I would say that the thing that I've learned the most in the last few years is just kind of continuing to be, like, even through some of the tougher times, continuing to be there, continuing to develop that relationship. A lot of times, it feels like you're not getting anywhere, but you are. It is actually happening. You just don't see it until later.

+ +

WILL: I'm writing that down. That's great advice [laughter]. You mentioned hockey. Tell me about it. I've never played hockey. I grew up in the South, so we didn't have that. So, tell me about it. And you're a goalie also, correct?

+ +

JAMON: Yeah, I play goalie. I didn't discover hockey...I played basketball in high school. I played four years of high school basketball. I even played a little bit at college. And I didn't really discover hockey until I moved to Southwest Washington, about an hour away from where I grew up in the coast of Oregon. When I got there, a lot of my friends that I made were playing hockey. And one friend, in particular, he was a goalie, and he had grown up in Upper Michigan. So, you know, like, he grew up playing hockey. He was a very good skater and things like that.

+ +

But there was one weekend I was coming to watch him play just rec hockey. And he's like, "You know what? I can't make it. Would you want to jump in and, like, be my sub?" And it was just a pick-up game. So, it wasn't like there was anything on the line. And I was like, "All right, I'll give it a try." You know, put on the gear. He showed me what to do to put on the gear. He kind of gave me some tips. Like, in the living room where we were, he was, like, showing me how to play.

+ +

We were, like, I would say, 19, I think. Nineteen years old, something like that. Anyway, I show up, and I put on the gear, and I go out there. And I actually had a decent game, considering I barely knew how to skate and barely knew how to do anything. But I'm kind of big; I'm six foot four, almost six foot five. And having all that gear and everything, I filled up a lot of the net. And it wasn't a very high-level game, so I did pretty well.

+ +

And after that, the team was like, "Well, we'd love to have you back." And then my friend really was not interested in continuing, so he was like, "You can have it, like, just roll with it." I kept playing for about three years, and then, I don't know, I took over a decade off. The team dissolved. It wasn't even a league team. It was just, you know, pick-up hockey.

+ +

And then a friend called me and was like, "Hey, I'm starting up a game. It's going to be Finnish Americans," because I'm half-Finnish myself. "So, it's going to be all Finnish Americans. We're going to call it the [Foreign language]," which is the Finnish boys in sort of Finnish. It's not exactly supposed to be like that in Finnish. Anybody listening who's Finnish is going to be like, "Yeah, that's bad Finnish." But it kind of means Finnish boys or Finland boys.

+ +

And we put together the team, and I've been playing for the last three-plus years. It's been kind of, like, a rec league team. We've won the championship four times, which was really fun. This year, I'm actually playing in two leagues. I'm playing in rec league, and I'm also playing the next league up, so a little bit faster, better skaters, better shooters, things like that. And I just love it. It's so much fun.

+ +

WILL: Wow, that's amazing that you started later and that you're still playing it. Because when I look at hockey, I'm like, that's really hard. I don't know if I could do that. I can skate. I can't stop.

+ +

JAMON: [laughs]

+ +

WILL: Like, I can get a lot of speed [laughs]. But it's just something about turning sideways and thinking I'm going to fly over the skates.

+ +

JAMON: [laughs]

+ +

WILL: And yeah, it's a whole thing [laughs]. Is goalie harder than playing any of the other positions?

+ +

JAMON: I would say it's different. Like, I don't have to be as good of a skater, you know, things like hockey stops are still not supernatural for me. I don't skate backwards super-fast. You know, I'm not a fast skater in general. But the difference is, of course, you have to be reading the flow of the game. You have to know the body language of the players that are coming at you. You have to kind of see what's happening. At the end of the day, lots of things can happen, so you try to put yourself in the best position.

+ +

It's a lot of, like, positional, like, where are you in the net? What does your position look like? And then, once they shoot, how do you react? Are you dropping down, or are you staying up? Are you using your glove? Are you using your blocker? Are you just trying to block with your body using your stick? Then, once the puck hits you, then what do you do? How do you control the rebound? Are you trying to cover it up and ice the puck so they do a face-off? Are you trying to kick it out to one of your skaters?

+ +

And then, once that happens, you have a little bit of a rest, hopefully, while they're down on the other side. But you're continually alert and watching to see what's going to develop because it could be a breakaway. And then it's just you and the skater and trying to anticipate what they're doing and try to make it so that they have to make a play. Like, just be big, be in position. Don't get out of position. Don't make a mistake.

+ +

And I've had really great games where I've, you know, had 45 shots on me, and I've only let one in or something like that. And I've had some bad games too. I know there's one game in a championship where they only had six shots on me. But we ended up losing because I let in two, so that was not a fun game. I only had six opportunities, and I failed on two of them. But that happens, and so you just have to be mentally tough.

+ +

WILL: Wow, that's amazing. The limited knowledge of hockey...I'm going to assume here, so I hope it's right. With you being 6'4, 6'5, I'm guessing that the five-hole, if I'm correct, was probably your toughest position to defend.

+ +

JAMON: You know, you would think so. And just for the audience, the five-hole is, like, between your legs, you know, the puck going between your legs underneath. But I play a style...a little bit older style of goalie because that's what I watched. You know, in, like, the early 2000s, I watched Patrick Roy of the Colorado Avalanche, one of the greatest goalies of all time, and he played what's called a butterfly style.

+ +

So, as the play develops, you're standing, but then you go down fairly early, and you're protecting the bottom. You have your stick in front of you protecting the five-hole, and you have your legs, you know, spread out. So, I used my height really more for blocking as I'm down rather than standing because when I'm standing, I'm above the net. It's better for me to get down. And I think that that's worked out pretty well.

+ +

You know, Patrick Roy was a pretty big goalie as well. Most modern goalies play a more hybrid style. But, you know, we could get into all that. I'm a big kind of hockey nerd in this way. But that's what I do. I play butterfly, so most of the time, people don't beat me five-hole; when they do, it's usually they're picking a corner.

+ +

WILL: Wow. Now that you've painted the picture, I can see how that's smart because you do have the goal, I mean, the gloves plus the stick and then your height. Yeah, I can see how...that's smart. That's very smart [laughs].

+ +

JAMON: Yeah, that's right. Yeah, that's kind of the goal. And also, because I wasn't a great skater, it sort of played into it as well, playing down on the ice where I was just more comfortable that way. It's worked out. I've had a pretty decent record over my career here [laughs].

+ +

WILL: That's awesome. Well, let's transition a little bit into consultant agencies. You've been doing it for 18 years. Tell me about that. How did you get started?

+ +

JAMON: Well, when I started, I was working in construction. I was working for a home builder. And, you know, everybody I knew pretty much worked in construction, including my dad, who owned a business. And I went on my own. I had always dreamed of owning my own business, but I didn't start really thinking about websites. I was coding. I loved coding, and I was coding since I was 12.

+ +

So, when I got to 23 years old, I thought, I'll start a business, and I'll do home design because that's what I was doing for the builder was, I was drawing homes. I was designing homes and remodels and things like that. And so, I started it doing that. But I also needed a little bit extra work. I didn't have enough work. Like, I had people, you know, sending me work, you know, home design and whatnot, but I didn't have quite enough. So, I would also build websites on the side, PHP and HTML, MySQL, and JavaScript. And I just sort of continued to do that.

+ +

But in 2008, there was the housing crisis, and all of the design work for homes just dried up. There wasn't much there. In fact, it actually really dried up in 2007 because things kind of started a little early for designers. And so, I was like; I got to do something to stay busy. I've got a wife. I've got a young kid (Actually, at that point, I had two kids.), and I need to make sure that I'm staying busy. And so, I really ramped up trying to find work, you know, as a programmer, as a web developer.

+ +

And there were plenty of companies at that time that were really trying to drum up business. So, they were putting money into their websites trying to get new projects, and they were all construction companies. And so, that's how I started. And I started doing more things like internal web apps for managing orders and managing sales leads, and that sort of thing. And that led me into web apps and eventually to Ruby on Rails, which became sort of my bread and butter for a while.

+ +

As I was doing Ruby on Rails, you know, obviously, the iPhone was out, but the iPad came out. And I was more of an Android guy at that point. But I bought an iPad because it looked really cool, and my dad had one. When I started playing around with it, I'm like, I need to build apps for this. This is super cool. So, I took some Stanford courses online, which you could do back in those days, iTunes U, and learned how to use Objective-C.

+ +

This was previous to Automatic Reference Counting and stuff. So, you had to manage your own memory, and this was a lot of manual work; very different environment than JavaScript, and PHP, and Ruby. But I actually enjoyed it quite a bit and then eventually transitioned into React Native later. But really, getting over to mobile and that sort of thing was...once I found mobile, I really didn't want to do web anymore. Mobile is what I really enjoy doing.

+ +

WILL: Wow, I love that. If I'm following you correctly, you said in 2007, that's kind of when everything dried up. So, you were almost forced to find something different, correct?

+ +

JAMON: Yeah, that's right. I mean, I kind of sat around feeling sorry for myself for a while. And then I was like, well, it's my business. I got to figure out what to do. It's not anybody else's fault. Like, you know, it doesn't matter that this is forces out of my control. I do have control. I have the ability to go in there and figure out, okay, what do I do next? Well, I know how to program, and it seems like people want me to program. So, let's lean into that.

+ +

WILL: Wow. I love that. Because it's funny, that's how I got started in programming. I lost my job. And I was working at Buckle, the clothing store. If you know me, that is not me at all, like, at all [laughter]. I love gym shorts and athletic clothes. Like, fashion is not my thing. It's just not. So [laughs], I got into programming because I was just struggling. And it was a very pivotal moment in my life. And I'm thankful that I lost my job. Losing your job is just hard, and I think it makes you rethink things.

+ +

JAMON: Yeah, absolutely. It was a growth moment for me as well, one of many. But that was definitely a point that I look back on and say, I mean because I can actually point at almost the day when it all dried up. It was, like, April 2007. And my uncle had been sending me a lot of work, you know, he had extra work. He didn't have barely enough for himself anymore at that point. And I finished up my last project, and he's like, "I don't have anything else." And I had some other clients as well and called them up, and they were like, "No, we don't have anything. Like, nobody is buying right now." And it just kept going like that.

+ +

And it was weird because 2005, 2006, most of 2007, it felt like things were really rolling, but it just dried up all at once. And so, I was really lucky that I did end up getting a bunch of web work to do in 2008. I was still doing home design till probably late 2008, 2009. But then I eventually just hung that up and was like, okay, this is over. I'm definitely focusing on programming.

+ +

WILL: Wow, how was the initial traction when you moved into ramping up the web development?

+ +

JAMON: It was really good because it didn't take much to keep me busy. And I ended up getting some big contracts from, like, a cabinet manufacturer was a big one. I did some other things as well. And I ended up hiring my first employees in 2009. So, really, less than two years later, I was starting to hire employees. And I just hired, like, junior developers who had barely learned to code and taught them to code. So, I hired probably, over the years, next few years, like, ten programmers, many of whom are actually still with me today, and I taught them to code back in the day.

+ +

And as time went on, they became senior and really high-level programmers who are now leading projects for big companies that you've heard of. But they started with me building, you know, PHP and MySQL and whatnot for small, like, regional construction companies. And we learned together. So, it was definitely a progression you can go look back and see.

+ +

WILL: Yeah, I saw a tweet that you tweeted, and I loved it because I totally understand.

+ +

JAMON: [laughs]

+ +

WILL: And so, I'm glad you mentioned the junior devs and stuff. The tweet that I'm talking about was, "I got into this industry to code; ended up becoming a founder because I was the only person who would hire me."

+ +

JAMON: [laughs]

+ +

WILL: I want to ask you about that.

+ +

[laughter]

+ +

JAMON: Yeah, it's really that I grew up in a small logging town, like, very tiny logging town in Northwest Oregon. I didn't know...I knew one programmer, and the guy was, like, an incredible genius. And I just thought that that was the only way that you could professionally be a programmer was to be an incredible genius. I was coding, but I was, like, coding games, you know, in QBasic. And so, for me, every time I looked around, it was just, like, construction, or logging or, you know, blue collar, like, working at a mill. Like, these were the things that I saw around me. And so, that was the path I went.

+ +

And I didn't really think of using this passion that I had for coding to turn it into, like, actual money. And when I did start thinking about it, I was like, I don't know anybody who does software. Like, even when I moved to Southwest Washington, I was closer to Portland. But I thought you had to have a CS degree, and I didn't have a CS degree. So, I was like, okay, well, I'll start my own business then, and that will be the thing that kind of leads me into tech. And that's what ended up happening.

+ +

And it's kind of funny because I did go to, you know, one semester of community college for basketball and for...until I got cut. And then I studied some things there. But I never finished for the community college. What's kind of cool, though, is today, I'm actually on their, like, tech advisory committee. Like, they actually have me advising their professors on the current state of tech, which is kind of cool.

+ +

WILL: Wow, that is really cool. It is interesting because I remember when I first started out and that feeling of probably over 300 applications just trying to get a job. And it was just hard. And my first job, to be honest, I think it was because of networking is why I got the job. If I didn't know the person that introduced me to the company, I probably wouldn't have gotten the job, if I'm being honest.

+ +

But I am very sympathetic for junior devs anytime. If a junior dev asks me a question, I will take time, help them out. Because I remember...it's very hard as a junior dev trying to get that first job. So, when you said that, I was like, yeah, I can see your heart towards junior devs.

+ +

JAMON: Absolutely. That's where I started. You know, the first developers that I hired were all juniors. We don't hire juniors anymore because of the style of business that we are. But I miss that. I miss that to some degree. We really can't. And we've looked at it from just about every angle. But I did my time [laughs]. I spent a lot of hours teaching junior developers when I could have done it quicker myself.

+ +

WILL: Definitely. Like, you end up losing some money when you do a junior dev and you're hiring for the future. So, like, in a consultant agency, I totally understand that, yeah.

+ +

JAMON: Yeah, absolutely.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

WILL: So, I want to ask you about the transition from ClearSight Studio to Infinite Red. How did that happen?

+ +

JAMON: ClearSight was my first company. And it sort of evolved from being a, you know, a home design/website company to just a website and web app company, and then mobile apps. And, at a certain time, we had, I think, around 12 employees, something like that. I had a design department. We were building websites and whatnot. And I was really interested in iOS development. That was really my passion.

+ +

And so I actually ended up working on some open source with iOS developers across the globe and then got invited to a conference down in San Francisco in 2014. And I went and gave a talk there. It was my first tech conference that I'd ever been to, much less given a talk, and I was the first talk [laughs]. So, that was kind of an interesting little anecdote there.

+ +

And as I did it, I got to know some other developers. I had one in particular, Todd Werth, who I really hit it off with, and we ended up chatting a lot after the conference. And it felt like he and I had a very similar outlook. And he had an iOS agency. That's all they did.

+ +

Well, 2015 rolls around, and I had had some rough times toward the end of 2014 in terms of the business, and I was kind of complaining to Todd. He had had some issues as well, and we started commiserating. And he's like, you know, he just started joking. I still have this conversation in Slack way back if I go look. And he's like, "Well, maybe we should just merge our businesses together," because it felt like we had maybe complementary skills. And we had a similar outlook on what we wanted from our businesses. And so, we ended up eventually solidifying that. I flew down there, talked to him and his business partner, Ken, at the time. We ended up making that happen later that year.

+ +

So, just a few days ago, October 1st was our eighth anniversary running the companies, running the new company, the merged company, which is Infinite Red. So, that was kind of how that all came together. Eventually, Ken left, and we had a new business partner who was our top employee buy-in; that's Gant Laborde. And so, there are still three owners. We have three directors and then the rest of the team. We're about 30 people altogether, and we focus entirely on React Native.

+ +

WILL: Wow, congratulations on eight years. That's a lot. That's amazing.

+ +

JAMON: Yeah, thank you. I was just thinking the other day that I ran ClearSight for ten years. Infinite Red is getting close to how long I ran my first business. And, like, my youngest is, like I said, 10. So she was only two years old when I merged the company. She does not remember my old company, which is weird to me.

+ +

[laughter]

+ +

WILL: Wow. So, can you walk me through your decision to go here with React Native and specialize in that? Because it sounds like right around the time when React Native was created, and people started using it in production.

+ +

JAMON: That's right. The iOS technology that we had sort of bonded over at that conference was called RubyMotion. But in 2015, the founder ended up going to work for Microsoft for a while and then went back to Apple. He had been from Apple before. So, it was sort of going down. And we were looking for a different technology, both of our companies were, and then, of course, the merged company.

+ +

React Native looked interesting, but it didn't have an Android version yet. But then, in September of 2015, Android came out, so it was iOS and Android. So, we were able to take a look at that one month before we ended up solidifying the actual merger. So, basically, day one, October 1st, 2015, we were, like, we are now doing React Native for mobile, but we kept doing web. We kept doing Ruby on Rails. We did some Elixir. We did some Elm. We did some...I think we had some old Ember stuff going on. We had all kinds of things going on.

+ +

But over time, we got more and more traction with React Native because that's really where our interest was. And so, we ended up saying, okay, well, this is where we really want to be. It took us a few years. It took us probably five years, six years, something like that, to really develop the confidence to say, "Hey, this is all we want to do," because it's a risk. Like, you put yourself on one technology. We had that before with the other technology that went down. But we had the confidence that we knew we could step off of a sinking ship onto another one if we needed to. So, we said, "You know what? Let's do this."

+ +

And I got to give my co-founder, Todd, a lot of credit because he was the first one to say, "Let's go all React Native. Anywhere that React Native is, React Native is on a lot of different platforms. You can do tvOS. You can do Mac. You can do Windows. You can do web with React Native web, all kinds of things. So, let's just focus on React Native. Our team will just focus on that. We will only hire React Native developers. All of our marketing is going to be around React Native. Let's just focus on that."

+ +

And it ended up being a great call. We did that. We made that happen. And for probably the last, I would say, three, four years, something like that, that's all we've been doing.

+ +

WILL: So, what's your opinion on, I guess, the argument that's being held right now with native iOS and Android, even the Flutter, and I think Ionic is the other one that I've heard of, versus React Native? What's your pitch on React Native over those?

+ +

JAMON: There's definitely reasons to use any of those. But I wrote this article a while back. It was specifically about Flutter, but I think it applies to a lot of the other competitors as well. The title of the article was provocatively titled, "Flutter Is Better Than React Native in All the Ways That Don't Matter." And the idea behind this is that, yes, Flutter gets a lot of things very right. A lot of their developer experience is actually better than React Native; some is worse, but, you know, some is better.

+ +

But really, when it comes down to it, the things that matter are more business level. React Native is good enough. It's like native views. So, you have the native performance. With Hermes, you have really good performance in JavaScript. So, you know that you can get really high-level JavaScript performance. You can ship JavaScript, which really helps because then you can bring in JavaScript developers, and specifically React developers.

+ +

So, a lot of companies already use React. It's a no-brainer to then use React Native if you're already using React Web. It doesn't really make sense to go to Flutter. It makes maybe some sense to write it in native, but then you have to write it twice. And you have three teams. You have a web team. You have an iOS team, and you have an Android team. And you also have three codebases, and one's always lagging behind. That's always what's happening.

+ +

Marketing is like, "Okay, when can we announce this?" "Well, iOS isn't done," or "Android is not done," or "Web is not done." Where if you can combine all of those things and combine just the culture of your team, then it becomes more tight-knit because everybody's working on all aspects at one time. You can take a feature, and you can build it in web, and you can build it in iOS, and you can build it Android with all the same skills.

+ +

Now, there are some deeper parts of React Native. It goes really deep. But in terms of just being productive out of the gate, a React developer can be productive in week one, and that's, I think, a huge deal. So, it really comes down to is the performance and developer experience good enough? And the answer is absolutely yes.

+ +

And then, secondly, like, what's the business case for React Native? Well, you can have the same developers doing iOS, Android, and web, and even if you don't, you can share techniques. You can be like, "Hey, here's this cool JavaScript thing," and the Kotlin developers aren't just like, "Ugh, you know, JavaScript." Or you can be like, "Hey, here's our TypeScript configuration across the whole codebase." You can even have a monorepo with everything in it. It just makes a lot of sense that way. And especially now with Expo, it makes it even more that way because Expo removes a lot of the barriers for web developers that they would have coming into native.

+ +

So, with that in mind, I still see React Native dominating the apps that are at the top of the App Store. One of the Expo developers, Evan Bacon, has put out a bunch of tweets about, you know, like, 24 out of the top 100 food and drink apps are written in React Native, as opposed to 8 in all the other options combined other than native, you know. So, it gives a good sense that React Native is still growing and continuing to. It has a lot of steam behind it.

+ +

WILL: Yeah, I totally agree with you. I'm a big React Native fan, and I do a lot of React Native work here. So, yes, totally agree with you. And one of the most frustrating things that I've come across is, I'm a big researcher, and so I'll research things, and I'm like, oh, there's an app for this. And I'm a big Android fan, so when I go to them, it's like, oh yes, I can use this app. And then it's like, no, I can't. It's only for iOS. Okay, like, you lost me as a customer.

+ +

JAMON: [laughs]

+ +

WILL: I was willing to pay whatever on this because I've been looking for it. So yeah, I like how you said that.

+ +

JAMON: Yeah. It treats all of the platforms as first-class citizens.

+ +

WILL: Yes. Yes, yes, yes. Totally agree. How does your company handle the backend? Do y'all do any of the backend, or how is that handled at Infinite Red?

+ +

JAMON: We used to do that, like I mentioned. But a few years ago...we had a very, very small back-end team by then. Most of the time, and now pretty much 100% of the time, when someone comes to us, they already have a back-end team, so we work directly with them. A lot of our developers were back-end developers, and so they understand the backend really well, but they're obviously React Native specialists now.

+ +

So, you know, I came from that. I did PHP. I did Ruby, Ruby on Rails, Elixir, Node, all kinds of back-end technology. So, I understand it really well as well. But yeah, we lean on our clients for that. We might partner with an agency like you folks over there at thoughtbot and have them do the backend, or just have the client, you know, come up with their own solution.

+ +

WILL: Yeah, I love that, yeah. And we've done that with numerous agencies, so yeah, that's awesome. What does success look like for Infinite Red now versus, you know, six months or five years from now? Do y'all have any goals in mind that you're trying to hit?

+ +

JAMON: In the Infinite Red leadership, we are currently reading John Maxwell's 21 indisputable Laws of Leadership, which is a good book. And we had this really great conversation at our first book club meeting in leadership, which John Maxwell defines success in a very different way than we do. You know, he measured it as, like, McDonald's, or Starbucks, or something like that, like, giant, becoming huge, becoming big, making tons of money. And it was sort of just implicit in the book that that was the case.

+ +

We had this great talk internally. Why didn't this resonate with us? And that's because we don't really measure success that way. So, I love that question, Will, because measuring success is you really have to start there. Like, you have to start there and say, "What do we want from this?" So, ultimately, we want to build cool things with our friends. I'm a coding nerd. I want to code. I want to be in the code. That's why we're an agency. Like, if we were a product company, if we were building, I don't know, podcasting software or something, we'd have to become experts in podcasting rather than experts in React Native, or experts in TypeScript, or whatever we want to do.

+ +

So, we really love code. We want to build that. We want to have an amazing family-first environment. We want to treat everybody super well. We want to have really low turnover, which we've been able to achieve. Hardly anybody leaves Infinite Red. Maybe every other year, we might lose one person. And even with those people, they tend to come back [laughs], which is a great sign. They go out and find out that, yeah, actually, Infinite Red is pretty awesome, and they come back. So, we really look for that. We really focus on that. We want that to happen.

+ +

And it's really less about making the most money we can. Obviously, everybody wants to be well paid. And so, we're going to try to make sure we have a successful business in that way and that we want to be around for a long time. But, really, measuring success is less about business success and it's more about life success. It's really more about family success, being with my four kids, being there for them when they need me to be. That's why we're remote, you know, as another example. So, everything really hinges off of that. It's around happiness. It's around fulfillment. It's not around financial success.

+ +

WILL: I'm a huge John Maxwell fan, by the way.

+ +

JAMON: [laughs] There you go.

+ +

WILL: So, yes, I love it. And I love how you explained, you know, because one of my questions I was going to ask you is about the core values, but I'm going to switch it up a little bit. So, I'm just going to say, in my opinion, I feel like there's almost leadership talk void at times, especially in the tech space. Like, we don't talk about leadership a lot. But it plays a huge part in what we do day to day. Like, you named a couple of core values and principles that you're following because of the leadership. So, for you, why is the leadership so important and I guess you can say have a seat at the table at Infinite Red?

+ +

JAMON: I'm a strong believer, and I've become more of a strong believer over time, that it all starts at the top. If you don't have buy-in from your top leadership, it does not really matter what happens otherwise because they will continually undermine, and they have the power to continually undermine that. So, these core values have to apply to the top leaders. They have to be held accountable to that. And these leaders also need to be developed.

+ +

So, we have three owners. We have three directors. And the three directors who are underneath us were not directors when we hired them; you know, they started out as developers. They started out as designers. They started out as project managers. But they became Director of Operations, Director of Engineering, Director of Communications. And we developed them. We poured a lot of time into them, and we continue to do that. In fact, even reading this book with them and going through that exercise is continuing to invest in them. Not that we as owners don't have growth to do; we also do. And so, we learn from them, and we learn from our team. So, you have to start there.

+ +

And on that same vein, we do have some core values. We call them our foundation and our pillars. We have three foundational things, and we have four pillars. So, the three foundations are: one, we control our own destiny. We are not going to be beholden to some other company. We're not going to ride someone else's coattails. We're not going to be in a situation where someone else can kill us. And it can be easily done that way where we're in a position where, you know, we're too reliant on one whale client or something like that. We just won't do it.

+ +

The second foundational thing is that we have...it's a word bonitas, which means kindness, friendliness, benevolence, blamelessness. And it's basically just being a good person to everybody and doing the right thing.

+ +

And the third one is having a significant positive impact. That's why we do so much media. That's why we try to have an impact outside. And we're only 30 people, but people think we're way bigger because of how we kind of present ourselves in the world. And then our pillars all support those things, so high personal support. We support each other. We have high expectations, but we also support each other not just at work but also as a whole person.

+ +

Long-term viewpoint, we think way beyond this year. We think about what is Infinite Red going to be when I retire? You know, I'm 41; that's a ways out, hopefully. But what's that going to look like?

+ +

The next one is collaborative creativity. Creativity by yourself is just a solo thing. We're a team, so it has to be collaborative. We have to do it together. All our creative work, whether it's our conference, Chain React, or our work, it's all collaborative, and we love being creative.

+ +

And the last thing is being pioneers, pioneering spirit. We like to be pioneers in technology. We put out a lot of open source. And we try to bring that pioneering spirit everywhere we go. And then, there's a lot of different things that kind of come out of that. For example, we have this internal saying, which is, "Don't do hard things alone."

+ +

So, you have a hard thing coming up? And it could be hard in various ways. It could be a technically challenging thing. It could just be hard because of the mood you're in that day. But don't do it alone. Ask someone to help you, you know, jump in with you, pair with you. Do it together. And we love that. That's part of the high personal support and the bonitas. So, all these things come out of the foundation and pillars that we have.

+ +

WILL: Wow, I love all those. I want to pick one of them out and ask you a question around it. So, you're talking about having an impact. I'm loving this conversation just talking to you. It's just been amazing. So, for you, what do you want the impact on the world to be from your perspective?

+ +

JAMON: That's a hard question to answer, and it tends to be something that I think about a lot. I'm more of an opportunistic person. I react more than I plan ahead, that sort of thing. But with that said, I think that we have had significant positive impact through a lot of different ways. So, on Twitter, for example, I try to present a...and this is authentically who I am. But I try to present a positive force out there, someone who's excited and enthusiastic about the technology, who supports other people, even who you might consider competitors, for example.

+ +

I just retweeted recently a Callstack thing. I mean, you might consider them a competitor. They're another React Native agency. But I love Callstack. They're great people. And I retweeted one of their really amazing resources, which is the ultimate guide to React Native performance, which, by the way, is really good. And if you do React Native, you should check it out.

+ +

So, I think what goes around comes around, and I really want to have that positive impact out there. I want to give talks that inspire people. You know, I'm a nerd, and I'm going to nerd out about stuff. And I feel like that has an impact all of its own. So, that's kind of my personal side of it. And then Infinite Red is a showcase that you can run a company the right way. You can treat people the right way. And the company can be successful along our own metrics of success.

+ +

WILL: So, one of my biggest principles that I've learned in life that's changed my leadership 100,000% is from this book called One Minute Manager. And I think it's called one-minute praise. And, essentially, the background behind it is, if you think something, just tell the person because so many times...and I get in my head, and I think amazing things about people, but I never say it.

+ +

JAMON: [laughs]

+ +

WILL: So, I want to just tell you, like, you said, the impact that you're making. You are doing that. Like, one of the reasons why I invited you on the show was because of your impact that I see that you're having on Twitter and LinkedIn and just everything that you're doing at Infinite Red. So, keep going. I want you to know that you are making a difference. I see you, and it's making a big difference in my life.

+ +

JAMON: I love that, and it makes me feel great. And I appreciate you sharing that one-minute praise there. It is something that sometimes you put it out there, and you don't really know what the impact is, you know, it's sort of hidden in maybe the likes, or the replies, or whatever.

+ +

As an example, I just reached out to my friend Aaron Francis last night, and I told him, "Hey, I love your videos." I don't even do the tech that he does. But I watch his videos on YouTube because I just love the vibe that he has. And I told him that. I was like, "You're doing a great job. You're being a very good advocate for your company." And I agree with you; I think that just taking the moment to reach out and say, "Hey, I think you're doing good work," it encourages people to do more of it. So, I appreciate it a lot, Will. That's really nice of you to say.

+ +

WILL: Yeah, definitely. If you can go back, what is some advice that you would give yourself? We could do both at the beginning when you did ClearSight and whenever you merged and did Infinite Red. Was there any advice that you're like, wow, I learned these lessons, and they were game changers for me?

+ +

JAMON: [laughs] Boy, this could be a whole nother podcast, to be honest. There are so many different things that I've kind of learned over the years. I feel like, you know, there's value in, you know, there was actually...I forget exactly where I heard this, but it was about Cloudflare, the company.

+ +

And a long time ago, as they were sort of launching, one of the people that worked on the...I think it was their founder, actually. One of their investors told him, "Hey, running a company is sort of like flying an airplane. You want to make sure that it's well-maintained at all times. And then, when you're flying, you keep the wheel steady and the nose 10 degrees above the horizon so you continue to rise. And you don't need to shoot for the moon. We're not a rocket here. Just continue to execute well, make sure that it's well maintained, make sure that you're continually rising."

+ +

And Cloudflare is a good example of this, and I think that Infinite Red is as well. Every year, we try to do something where we're continuing to keep that nose 10% above the horizon. That doesn't always mean growing. Like, we don't hire all that often. We don't grow in terms of headcount, but we grow in other ways. And you can see that looking back over the years. Every year, there was something that we continued to, you know, improve, keeping that nose 10 degrees above the horizon. And so, that's a big one. And you can just go do all the little things really well and continue to think long term and where are you headed. And if you do the right things long enough, good things happen.

+ +

WILL: I love that because, especially when I'm working out, I try to shoot for the moon.

+ +

JAMON: [laughs]

+ +

WILL: I go all out. So, that was some amazing advice. I don't even remember who told me, but when I first started programming, I tried to shoot for the moon. And, oh, I crashed and burned so many times [laughs] because it's just something you can't just master it, and just like, I got it, da da da. And I love that advice. That's amazing advice. So, that's perfect.

+ +

JAMON: Yeah, it really stuck with me, and I have so many more lessons. I have actually kept a notebook of profound things that I've heard over the years, and I actually really enjoy that minute praising you said. And I'm going to look up the quote after this, and I'm going to put it in my notebook.

+ +

[laughter]

+ +

WILL: Yeah, yeah. It's been a game-changer because I'm a very straightforward person. And so, a lot of times, like, I don't mind addressing an issue just head-on. But what I found is I'm just always doing that. And I never had equity in the bank at times. This is when I was a very young leader. I didn't have equity. And so, it was just hard to tell people, "Hey, can we tweak this? Can we do that?"

+ +

And then I had to sit back and say, okay, what can I change to be a better leader? And it's like, I can connect better. And I see so many things. Like, I'm very observant, I think. To be honest, it's helped me in every area, even with my spouse, with my kids, with friends. It's just saying, "Hey, I see what you did. I see that you made breakfast." Or "My kids, I see that you made this beautiful mud pie for me. And it's amazing. So, thank you. Thank you." And so, yeah, it's been a game changer for me.

+ +

JAMON: Yeah, one of my friends, his goal was...and he's a leader. And he said that his goal with everyone on one was to give them one thing to change and highlight one thing they did well like you said, equity in the bank. He was talking about when he was a leader of, like, a call bank. And he said, "No matter how bad the call was, I wouldn't give them more than two things to improve because there was no way that they could take ten critiques and improve. They would just be defeated." And then, he would review and see if they could improve one more thing, avoided negative language, things like that. So, that's a really interesting concept.

+ +

WILL: Yeah, definitely, definitely. So, I have one other question for you. What motivates you? What's your wind in your sails? What keeps you going? Because I know running a consultant agency is not easy. What keeps you going?

+ +

JAMON: For me, motivation tends to be enthusiasm for learning, really more than anything, like going into something new and, like, exploring. I see it more as exploring even than learning. With a consultancy, there's always so many different...it's never the same, you know, there's always some other challenge. And that's one of the reasons I've loved being, you know, a consultancy owner for so many years. You're never dealing with just the same stuff over and over. So, I would say it's really about the exploration that happens, and just loving code, and talking shop, and being around great people. To me, that continues to motivate me.

+ +

WILL: I love that. Do you have anything that you would like to promote — personally, Infinite Red, anything?

+ +

JAMON: Well, Infinite Red, of course. If you're looking for React Native, we are all senior-level React Native developers. We've been working together for a long time. So, big companies, the biggest ones you can think of, many of them have hired us to, you know, be the experts with their team. We usually put 2 or 3 people on a project, and then the client will come in with 2 to 10 people or whatever they have on their side. And we work with them side by side, teaching them as well as delivering code. So, that's really our bread and butter.

+ +

We also put on the biggest and, I think, only U.S.-based React Native conference, and it's called Chain React. It's in Portland. Next year, it's going to be in July. So, go check it out: chainreactconf.com. We'd love to see you all there. I'd love to see you there, Will. And network with all these different React Native developers. There's people from Meta, and Microsoft, Amazon, all over the world, really. And they're some of the best React Native programmers you're going to ever meet, and some great talks, and great food, and a great city.

+ +

WILL: Yeah, I would love to be there. Let me ask you this: how is Portland in July?

+ +

JAMON: Portland is amazing in July. Sometimes, it can get hot, but for the most part, it's just beautiful. It'll be like 85 degrees, not really any humidity, nice, little breeze. It's just a beautiful weather pattern around Julyish. That's why we chose that time of year. So, definitely, if you're going to be coming to Oregon, Portland, you know, West Coast, July is a great time to come. It's not going to be super, super hot, usually. Sometimes, I mean, we get over 100 sometimes, but no worries, you know, there's AC as well. But for the most part, it's beautiful.

+ +

WILL: You sold me already.

+ +

JAMON: [laughs]

+ +

WILL: So, I live in South Florida, so...[laughs]

+ +

JAMON: Yeah, it's going to be different in South Florida in July.

+ +

[laughter]

+ +

WILL: Awesome. Well, this has been an amazing chat, and just great getting to know you and learning more about Infinite Red. Thank you for being a part of the podcast.

+ +

JAMON: Yeah. Thanks for inviting me, Will. It was a lot of fun, and you're a great host. I appreciate it.

+ +

WILL: I appreciate it.

+ +

JAMON: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Jamon Holmgren.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jamon Holmgren is the founder of Infinite Red, a consultancy specializing in React Native. He discusses his journey and insights into technology and leadership and highlights how Infinite Red stands as a testament that businesses can be run ethically while still achieving success.

+ +

The conversation shifts to leadership styles and the principle of "one-minute praise" from the book "One Minute Manager." Both Jamon and Will agree that acknowledging others' efforts openly can make a significant difference, enhancing leadership skills and building stronger relationships. Will points out how this simple principle has been a game-changer for him in various aspects of life, including his personal relationships.

+ +

Towards the end, the focus turns to motivation and long-term strategy. Jamon is driven by his enthusiasm for learning and the thrill of tackling diverse challenges in his consultancy work. He also shares his philosophy of keeping the company "10 degrees above the horizon," emphasizing steady, sustainable growth rather than erratic leaps and bounds.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Jamon Holmgren, Co-Founder and CTO of Infinite Red, a software consulting agency that specializes in React Native. Jamon, thank you for joining me.

+ +

JAMON: Yeah. Thanks for having me. I really appreciate it.

+ +

WILL: So, Jamon, what's going on in your life? How's everything going?

+ +

JAMON: You know, things have been obviously very busy, like, I guess, pretty much everybody. You know, school has started. I have four kids, so that keeps me quite busy, going to various school events, going to volleyball, you know, bringing kids here and there, running the company. I have some side projects I'm doing. I am playing hockey. So, it just seems like every waking hour is filled with something.

+ +

[laughter]

+ +

WILL: I totally understand that. I have three kids of my own. So, they're a little bit younger than yours, so mine is 4, 3, and, like, 17 months, so...

+ +

JAMON: Okay. Yeah, so you're just getting started. And you're doing all of the, like, physical labor associated with being a parent.

+ +

WILL: Yes, yes, yes. So, I want to start there. Tell me a little bit about your kids. I know their ages are 10 to 18.

+ +

JAMON: Yeah, so I have a boy, Cedric. He's actually a programmer as well. He's just starting his career. He is the oldest, and then we have three girls. We have a 15-year-old who's a sophomore in high school. And then we have a 12-year-old who's in middle school and a 10-year-old who is in fifth grade in elementary school. And it's a lot.

+ +

My wife and I both came from very large families, so we're kind of used to it. And it's a lot of fun. A lot of challenges at this age, I mean, teenagers especially, you know, as they kind of all come into that same era, you know, it's more of a challenge. I guess the thing that I think about it is a lot of the skills that I learned as a young kid parent don't really translate super well to being a teenager parent. And I'm having to learn a lot of new skills. And I actually talked to a guy the other day. His kids are, I think, 32 and 28, or something like that. And he said, "Yeah, the learning never stops." [laughs]

+ +

WILL: So, I'm going to ask you for the secret sauce because I'm still in the temper tantrums and those type of emotions and stuff. So, how is it different in the teenage years from the temper tantrums?

+ +

JAMON: Well, I think that they can act like adults in a lot of cases, and you start thinking of them as adults, and you start developing a relationship there. But their brains are also not fully developed. And so, they will also do things that are very inexplicable, like, you'll just be like, why? Why would this be a thing? Like, I don't get it. Like, you act like an adult for half the time, and then the other half, you act like a kid. Navigating that, and the fact that they change all the time, and all the other challenges.

+ +

And they're all different. Like, if we had only had one kid, you know, my boy was pretty easy. He was pretty straightforward. It would have been like, well, shoot, being a parent is pretty easy. Like, I don't know what everybody else is complaining about. Like, he never did tantrums. He was just a really quiet, you know, like, well-behaved kid and kind of went through life like that. But then, obviously, developing a relationship with him is more of the challenge because he's quieter, where with my girls, it's easier to develop the relationship, but then you [laughs] deal with a lot more volatility as well. So, they're all different. Every kid's different. It's hard to really apply that directly.

+ +

I would say that the thing that I've learned the most in the last few years is just kind of continuing to be, like, even through some of the tougher times, continuing to be there, continuing to develop that relationship. A lot of times, it feels like you're not getting anywhere, but you are. It is actually happening. You just don't see it until later.

+ +

WILL: I'm writing that down. That's great advice [laughter]. You mentioned hockey. Tell me about it. I've never played hockey. I grew up in the South, so we didn't have that. So, tell me about it. And you're a goalie also, correct?

+ +

JAMON: Yeah, I play goalie. I didn't discover hockey...I played basketball in high school. I played four years of high school basketball. I even played a little bit at college. And I didn't really discover hockey until I moved to Southwest Washington, about an hour away from where I grew up in the coast of Oregon. When I got there, a lot of my friends that I made were playing hockey. And one friend, in particular, he was a goalie, and he had grown up in Upper Michigan. So, you know, like, he grew up playing hockey. He was a very good skater and things like that.

+ +

But there was one weekend I was coming to watch him play just rec hockey. And he's like, "You know what? I can't make it. Would you want to jump in and, like, be my sub?" And it was just a pick-up game. So, it wasn't like there was anything on the line. And I was like, "All right, I'll give it a try." You know, put on the gear. He showed me what to do to put on the gear. He kind of gave me some tips. Like, in the living room where we were, he was, like, showing me how to play.

+ +

We were, like, I would say, 19, I think. Nineteen years old, something like that. Anyway, I show up, and I put on the gear, and I go out there. And I actually had a decent game, considering I barely knew how to skate and barely knew how to do anything. But I'm kind of big; I'm six foot four, almost six foot five. And having all that gear and everything, I filled up a lot of the net. And it wasn't a very high-level game, so I did pretty well.

+ +

And after that, the team was like, "Well, we'd love to have you back." And then my friend really was not interested in continuing, so he was like, "You can have it, like, just roll with it." I kept playing for about three years, and then, I don't know, I took over a decade off. The team dissolved. It wasn't even a league team. It was just, you know, pick-up hockey.

+ +

And then a friend called me and was like, "Hey, I'm starting up a game. It's going to be Finnish Americans," because I'm half-Finnish myself. "So, it's going to be all Finnish Americans. We're going to call it the [Foreign language]," which is the Finnish boys in sort of Finnish. It's not exactly supposed to be like that in Finnish. Anybody listening who's Finnish is going to be like, "Yeah, that's bad Finnish." But it kind of means Finnish boys or Finland boys.

+ +

And we put together the team, and I've been playing for the last three-plus years. It's been kind of, like, a rec league team. We've won the championship four times, which was really fun. This year, I'm actually playing in two leagues. I'm playing in rec league, and I'm also playing the next league up, so a little bit faster, better skaters, better shooters, things like that. And I just love it. It's so much fun.

+ +

WILL: Wow, that's amazing that you started later and that you're still playing it. Because when I look at hockey, I'm like, that's really hard. I don't know if I could do that. I can skate. I can't stop.

+ +

JAMON: [laughs]

+ +

WILL: Like, I can get a lot of speed [laughs]. But it's just something about turning sideways and thinking I'm going to fly over the skates.

+ +

JAMON: [laughs]

+ +

WILL: And yeah, it's a whole thing [laughs]. Is goalie harder than playing any of the other positions?

+ +

JAMON: I would say it's different. Like, I don't have to be as good of a skater, you know, things like hockey stops are still not supernatural for me. I don't skate backwards super-fast. You know, I'm not a fast skater in general. But the difference is, of course, you have to be reading the flow of the game. You have to know the body language of the players that are coming at you. You have to kind of see what's happening. At the end of the day, lots of things can happen, so you try to put yourself in the best position.

+ +

It's a lot of, like, positional, like, where are you in the net? What does your position look like? And then, once they shoot, how do you react? Are you dropping down, or are you staying up? Are you using your glove? Are you using your blocker? Are you just trying to block with your body using your stick? Then, once the puck hits you, then what do you do? How do you control the rebound? Are you trying to cover it up and ice the puck so they do a face-off? Are you trying to kick it out to one of your skaters?

+ +

And then, once that happens, you have a little bit of a rest, hopefully, while they're down on the other side. But you're continually alert and watching to see what's going to develop because it could be a breakaway. And then it's just you and the skater and trying to anticipate what they're doing and try to make it so that they have to make a play. Like, just be big, be in position. Don't get out of position. Don't make a mistake.

+ +

And I've had really great games where I've, you know, had 45 shots on me, and I've only let one in or something like that. And I've had some bad games too. I know there's one game in a championship where they only had six shots on me. But we ended up losing because I let in two, so that was not a fun game. I only had six opportunities, and I failed on two of them. But that happens, and so you just have to be mentally tough.

+ +

WILL: Wow, that's amazing. The limited knowledge of hockey...I'm going to assume here, so I hope it's right. With you being 6'4, 6'5, I'm guessing that the five-hole, if I'm correct, was probably your toughest position to defend.

+ +

JAMON: You know, you would think so. And just for the audience, the five-hole is, like, between your legs, you know, the puck going between your legs underneath. But I play a style...a little bit older style of goalie because that's what I watched. You know, in, like, the early 2000s, I watched Patrick Roy of the Colorado Avalanche, one of the greatest goalies of all time, and he played what's called a butterfly style.

+ +

So, as the play develops, you're standing, but then you go down fairly early, and you're protecting the bottom. You have your stick in front of you protecting the five-hole, and you have your legs, you know, spread out. So, I used my height really more for blocking as I'm down rather than standing because when I'm standing, I'm above the net. It's better for me to get down. And I think that that's worked out pretty well.

+ +

You know, Patrick Roy was a pretty big goalie as well. Most modern goalies play a more hybrid style. But, you know, we could get into all that. I'm a big kind of hockey nerd in this way. But that's what I do. I play butterfly, so most of the time, people don't beat me five-hole; when they do, it's usually they're picking a corner.

+ +

WILL: Wow. Now that you've painted the picture, I can see how that's smart because you do have the goal, I mean, the gloves plus the stick and then your height. Yeah, I can see how...that's smart. That's very smart [laughs].

+ +

JAMON: Yeah, that's right. Yeah, that's kind of the goal. And also, because I wasn't a great skater, it sort of played into it as well, playing down on the ice where I was just more comfortable that way. It's worked out. I've had a pretty decent record over my career here [laughs].

+ +

WILL: That's awesome. Well, let's transition a little bit into consultant agencies. You've been doing it for 18 years. Tell me about that. How did you get started?

+ +

JAMON: Well, when I started, I was working in construction. I was working for a home builder. And, you know, everybody I knew pretty much worked in construction, including my dad, who owned a business. And I went on my own. I had always dreamed of owning my own business, but I didn't start really thinking about websites. I was coding. I loved coding, and I was coding since I was 12.

+ +

So, when I got to 23 years old, I thought, I'll start a business, and I'll do home design because that's what I was doing for the builder was, I was drawing homes. I was designing homes and remodels and things like that. And so, I started it doing that. But I also needed a little bit extra work. I didn't have enough work. Like, I had people, you know, sending me work, you know, home design and whatnot, but I didn't have quite enough. So, I would also build websites on the side, PHP and HTML, MySQL, and JavaScript. And I just sort of continued to do that.

+ +

But in 2008, there was the housing crisis, and all of the design work for homes just dried up. There wasn't much there. In fact, it actually really dried up in 2007 because things kind of started a little early for designers. And so, I was like; I got to do something to stay busy. I've got a wife. I've got a young kid (Actually, at that point, I had two kids.), and I need to make sure that I'm staying busy. And so, I really ramped up trying to find work, you know, as a programmer, as a web developer.

+ +

And there were plenty of companies at that time that were really trying to drum up business. So, they were putting money into their websites trying to get new projects, and they were all construction companies. And so, that's how I started. And I started doing more things like internal web apps for managing orders and managing sales leads, and that sort of thing. And that led me into web apps and eventually to Ruby on Rails, which became sort of my bread and butter for a while.

+ +

As I was doing Ruby on Rails, you know, obviously, the iPhone was out, but the iPad came out. And I was more of an Android guy at that point. But I bought an iPad because it looked really cool, and my dad had one. When I started playing around with it, I'm like, I need to build apps for this. This is super cool. So, I took some Stanford courses online, which you could do back in those days, iTunes U, and learned how to use Objective-C.

+ +

This was previous to Automatic Reference Counting and stuff. So, you had to manage your own memory, and this was a lot of manual work; very different environment than JavaScript, and PHP, and Ruby. But I actually enjoyed it quite a bit and then eventually transitioned into React Native later. But really, getting over to mobile and that sort of thing was...once I found mobile, I really didn't want to do web anymore. Mobile is what I really enjoy doing.

+ +

WILL: Wow, I love that. If I'm following you correctly, you said in 2007, that's kind of when everything dried up. So, you were almost forced to find something different, correct?

+ +

JAMON: Yeah, that's right. I mean, I kind of sat around feeling sorry for myself for a while. And then I was like, well, it's my business. I got to figure out what to do. It's not anybody else's fault. Like, you know, it doesn't matter that this is forces out of my control. I do have control. I have the ability to go in there and figure out, okay, what do I do next? Well, I know how to program, and it seems like people want me to program. So, let's lean into that.

+ +

WILL: Wow. I love that. Because it's funny, that's how I got started in programming. I lost my job. And I was working at Buckle, the clothing store. If you know me, that is not me at all, like, at all [laughter]. I love gym shorts and athletic clothes. Like, fashion is not my thing. It's just not. So [laughs], I got into programming because I was just struggling. And it was a very pivotal moment in my life. And I'm thankful that I lost my job. Losing your job is just hard, and I think it makes you rethink things.

+ +

JAMON: Yeah, absolutely. It was a growth moment for me as well, one of many. But that was definitely a point that I look back on and say, I mean because I can actually point at almost the day when it all dried up. It was, like, April 2007. And my uncle had been sending me a lot of work, you know, he had extra work. He didn't have barely enough for himself anymore at that point. And I finished up my last project, and he's like, "I don't have anything else." And I had some other clients as well and called them up, and they were like, "No, we don't have anything. Like, nobody is buying right now." And it just kept going like that.

+ +

And it was weird because 2005, 2006, most of 2007, it felt like things were really rolling, but it just dried up all at once. And so, I was really lucky that I did end up getting a bunch of web work to do in 2008. I was still doing home design till probably late 2008, 2009. But then I eventually just hung that up and was like, okay, this is over. I'm definitely focusing on programming.

+ +

WILL: Wow, how was the initial traction when you moved into ramping up the web development?

+ +

JAMON: It was really good because it didn't take much to keep me busy. And I ended up getting some big contracts from, like, a cabinet manufacturer was a big one. I did some other things as well. And I ended up hiring my first employees in 2009. So, really, less than two years later, I was starting to hire employees. And I just hired, like, junior developers who had barely learned to code and taught them to code. So, I hired probably, over the years, next few years, like, ten programmers, many of whom are actually still with me today, and I taught them to code back in the day.

+ +

And as time went on, they became senior and really high-level programmers who are now leading projects for big companies that you've heard of. But they started with me building, you know, PHP and MySQL and whatnot for small, like, regional construction companies. And we learned together. So, it was definitely a progression you can go look back and see.

+ +

WILL: Yeah, I saw a tweet that you tweeted, and I loved it because I totally understand.

+ +

JAMON: [laughs]

+ +

WILL: And so, I'm glad you mentioned the junior devs and stuff. The tweet that I'm talking about was, "I got into this industry to code; ended up becoming a founder because I was the only person who would hire me."

+ +

JAMON: [laughs]

+ +

WILL: I want to ask you about that.

+ +

[laughter]

+ +

JAMON: Yeah, it's really that I grew up in a small logging town, like, very tiny logging town in Northwest Oregon. I didn't know...I knew one programmer, and the guy was, like, an incredible genius. And I just thought that that was the only way that you could professionally be a programmer was to be an incredible genius. I was coding, but I was, like, coding games, you know, in QBasic. And so, for me, every time I looked around, it was just, like, construction, or logging or, you know, blue collar, like, working at a mill. Like, these were the things that I saw around me. And so, that was the path I went.

+ +

And I didn't really think of using this passion that I had for coding to turn it into, like, actual money. And when I did start thinking about it, I was like, I don't know anybody who does software. Like, even when I moved to Southwest Washington, I was closer to Portland. But I thought you had to have a CS degree, and I didn't have a CS degree. So, I was like, okay, well, I'll start my own business then, and that will be the thing that kind of leads me into tech. And that's what ended up happening.

+ +

And it's kind of funny because I did go to, you know, one semester of community college for basketball and for...until I got cut. And then I studied some things there. But I never finished for the community college. What's kind of cool, though, is today, I'm actually on their, like, tech advisory committee. Like, they actually have me advising their professors on the current state of tech, which is kind of cool.

+ +

WILL: Wow, that is really cool. It is interesting because I remember when I first started out and that feeling of probably over 300 applications just trying to get a job. And it was just hard. And my first job, to be honest, I think it was because of networking is why I got the job. If I didn't know the person that introduced me to the company, I probably wouldn't have gotten the job, if I'm being honest.

+ +

But I am very sympathetic for junior devs anytime. If a junior dev asks me a question, I will take time, help them out. Because I remember...it's very hard as a junior dev trying to get that first job. So, when you said that, I was like, yeah, I can see your heart towards junior devs.

+ +

JAMON: Absolutely. That's where I started. You know, the first developers that I hired were all juniors. We don't hire juniors anymore because of the style of business that we are. But I miss that. I miss that to some degree. We really can't. And we've looked at it from just about every angle. But I did my time [laughs]. I spent a lot of hours teaching junior developers when I could have done it quicker myself.

+ +

WILL: Definitely. Like, you end up losing some money when you do a junior dev and you're hiring for the future. So, like, in a consultant agency, I totally understand that, yeah.

+ +

JAMON: Yeah, absolutely.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

WILL: So, I want to ask you about the transition from ClearSight Studio to Infinite Red. How did that happen?

+ +

JAMON: ClearSight was my first company. And it sort of evolved from being a, you know, a home design/website company to just a website and web app company, and then mobile apps. And, at a certain time, we had, I think, around 12 employees, something like that. I had a design department. We were building websites and whatnot. And I was really interested in iOS development. That was really my passion.

+ +

And so I actually ended up working on some open source with iOS developers across the globe and then got invited to a conference down in San Francisco in 2014. And I went and gave a talk there. It was my first tech conference that I'd ever been to, much less given a talk, and I was the first talk [laughs]. So, that was kind of an interesting little anecdote there.

+ +

And as I did it, I got to know some other developers. I had one in particular, Todd Werth, who I really hit it off with, and we ended up chatting a lot after the conference. And it felt like he and I had a very similar outlook. And he had an iOS agency. That's all they did.

+ +

Well, 2015 rolls around, and I had had some rough times toward the end of 2014 in terms of the business, and I was kind of complaining to Todd. He had had some issues as well, and we started commiserating. And he's like, you know, he just started joking. I still have this conversation in Slack way back if I go look. And he's like, "Well, maybe we should just merge our businesses together," because it felt like we had maybe complementary skills. And we had a similar outlook on what we wanted from our businesses. And so, we ended up eventually solidifying that. I flew down there, talked to him and his business partner, Ken, at the time. We ended up making that happen later that year.

+ +

So, just a few days ago, October 1st was our eighth anniversary running the companies, running the new company, the merged company, which is Infinite Red. So, that was kind of how that all came together. Eventually, Ken left, and we had a new business partner who was our top employee buy-in; that's Gant Laborde. And so, there are still three owners. We have three directors and then the rest of the team. We're about 30 people altogether, and we focus entirely on React Native.

+ +

WILL: Wow, congratulations on eight years. That's a lot. That's amazing.

+ +

JAMON: Yeah, thank you. I was just thinking the other day that I ran ClearSight for ten years. Infinite Red is getting close to how long I ran my first business. And, like, my youngest is, like I said, 10. So she was only two years old when I merged the company. She does not remember my old company, which is weird to me.

+ +

[laughter]

+ +

WILL: Wow. So, can you walk me through your decision to go here with React Native and specialize in that? Because it sounds like right around the time when React Native was created, and people started using it in production.

+ +

JAMON: That's right. The iOS technology that we had sort of bonded over at that conference was called RubyMotion. But in 2015, the founder ended up going to work for Microsoft for a while and then went back to Apple. He had been from Apple before. So, it was sort of going down. And we were looking for a different technology, both of our companies were, and then, of course, the merged company.

+ +

React Native looked interesting, but it didn't have an Android version yet. But then, in September of 2015, Android came out, so it was iOS and Android. So, we were able to take a look at that one month before we ended up solidifying the actual merger. So, basically, day one, October 1st, 2015, we were, like, we are now doing React Native for mobile, but we kept doing web. We kept doing Ruby on Rails. We did some Elixir. We did some Elm. We did some...I think we had some old Ember stuff going on. We had all kinds of things going on.

+ +

But over time, we got more and more traction with React Native because that's really where our interest was. And so, we ended up saying, okay, well, this is where we really want to be. It took us a few years. It took us probably five years, six years, something like that, to really develop the confidence to say, "Hey, this is all we want to do," because it's a risk. Like, you put yourself on one technology. We had that before with the other technology that went down. But we had the confidence that we knew we could step off of a sinking ship onto another one if we needed to. So, we said, "You know what? Let's do this."

+ +

And I got to give my co-founder, Todd, a lot of credit because he was the first one to say, "Let's go all React Native. Anywhere that React Native is, React Native is on a lot of different platforms. You can do tvOS. You can do Mac. You can do Windows. You can do web with React Native web, all kinds of things. So, let's just focus on React Native. Our team will just focus on that. We will only hire React Native developers. All of our marketing is going to be around React Native. Let's just focus on that."

+ +

And it ended up being a great call. We did that. We made that happen. And for probably the last, I would say, three, four years, something like that, that's all we've been doing.

+ +

WILL: So, what's your opinion on, I guess, the argument that's being held right now with native iOS and Android, even the Flutter, and I think Ionic is the other one that I've heard of, versus React Native? What's your pitch on React Native over those?

+ +

JAMON: There's definitely reasons to use any of those. But I wrote this article a while back. It was specifically about Flutter, but I think it applies to a lot of the other competitors as well. The title of the article was provocatively titled, "Flutter Is Better Than React Native in All the Ways That Don't Matter." And the idea behind this is that, yes, Flutter gets a lot of things very right. A lot of their developer experience is actually better than React Native; some is worse, but, you know, some is better.

+ +

But really, when it comes down to it, the things that matter are more business level. React Native is good enough. It's like native views. So, you have the native performance. With Hermes, you have really good performance in JavaScript. So, you know that you can get really high-level JavaScript performance. You can ship JavaScript, which really helps because then you can bring in JavaScript developers, and specifically React developers.

+ +

So, a lot of companies already use React. It's a no-brainer to then use React Native if you're already using React Web. It doesn't really make sense to go to Flutter. It makes maybe some sense to write it in native, but then you have to write it twice. And you have three teams. You have a web team. You have an iOS team, and you have an Android team. And you also have three codebases, and one's always lagging behind. That's always what's happening.

+ +

Marketing is like, "Okay, when can we announce this?" "Well, iOS isn't done," or "Android is not done," or "Web is not done." Where if you can combine all of those things and combine just the culture of your team, then it becomes more tight-knit because everybody's working on all aspects at one time. You can take a feature, and you can build it in web, and you can build it in iOS, and you can build it Android with all the same skills.

+ +

Now, there are some deeper parts of React Native. It goes really deep. But in terms of just being productive out of the gate, a React developer can be productive in week one, and that's, I think, a huge deal. So, it really comes down to is the performance and developer experience good enough? And the answer is absolutely yes.

+ +

And then, secondly, like, what's the business case for React Native? Well, you can have the same developers doing iOS, Android, and web, and even if you don't, you can share techniques. You can be like, "Hey, here's this cool JavaScript thing," and the Kotlin developers aren't just like, "Ugh, you know, JavaScript." Or you can be like, "Hey, here's our TypeScript configuration across the whole codebase." You can even have a monorepo with everything in it. It just makes a lot of sense that way. And especially now with Expo, it makes it even more that way because Expo removes a lot of the barriers for web developers that they would have coming into native.

+ +

So, with that in mind, I still see React Native dominating the apps that are at the top of the App Store. One of the Expo developers, Evan Bacon, has put out a bunch of tweets about, you know, like, 24 out of the top 100 food and drink apps are written in React Native, as opposed to 8 in all the other options combined other than native, you know. So, it gives a good sense that React Native is still growing and continuing to. It has a lot of steam behind it.

+ +

WILL: Yeah, I totally agree with you. I'm a big React Native fan, and I do a lot of React Native work here. So, yes, totally agree with you. And one of the most frustrating things that I've come across is, I'm a big researcher, and so I'll research things, and I'm like, oh, there's an app for this. And I'm a big Android fan, so when I go to them, it's like, oh yes, I can use this app. And then it's like, no, I can't. It's only for iOS. Okay, like, you lost me as a customer.

+ +

JAMON: [laughs]

+ +

WILL: I was willing to pay whatever on this because I've been looking for it. So yeah, I like how you said that.

+ +

JAMON: Yeah. It treats all of the platforms as first-class citizens.

+ +

WILL: Yes. Yes, yes, yes. Totally agree. How does your company handle the backend? Do y'all do any of the backend, or how is that handled at Infinite Red?

+ +

JAMON: We used to do that, like I mentioned. But a few years ago...we had a very, very small back-end team by then. Most of the time, and now pretty much 100% of the time, when someone comes to us, they already have a back-end team, so we work directly with them. A lot of our developers were back-end developers, and so they understand the backend really well, but they're obviously React Native specialists now.

+ +

So, you know, I came from that. I did PHP. I did Ruby, Ruby on Rails, Elixir, Node, all kinds of back-end technology. So, I understand it really well as well. But yeah, we lean on our clients for that. We might partner with an agency like you folks over there at thoughtbot and have them do the backend, or just have the client, you know, come up with their own solution.

+ +

WILL: Yeah, I love that, yeah. And we've done that with numerous agencies, so yeah, that's awesome. What does success look like for Infinite Red now versus, you know, six months or five years from now? Do y'all have any goals in mind that you're trying to hit?

+ +

JAMON: In the Infinite Red leadership, we are currently reading John Maxwell's 21 indisputable Laws of Leadership, which is a good book. And we had this really great conversation at our first book club meeting in leadership, which John Maxwell defines success in a very different way than we do. You know, he measured it as, like, McDonald's, or Starbucks, or something like that, like, giant, becoming huge, becoming big, making tons of money. And it was sort of just implicit in the book that that was the case.

+ +

We had this great talk internally. Why didn't this resonate with us? And that's because we don't really measure success that way. So, I love that question, Will, because measuring success is you really have to start there. Like, you have to start there and say, "What do we want from this?" So, ultimately, we want to build cool things with our friends. I'm a coding nerd. I want to code. I want to be in the code. That's why we're an agency. Like, if we were a product company, if we were building, I don't know, podcasting software or something, we'd have to become experts in podcasting rather than experts in React Native, or experts in TypeScript, or whatever we want to do.

+ +

So, we really love code. We want to build that. We want to have an amazing family-first environment. We want to treat everybody super well. We want to have really low turnover, which we've been able to achieve. Hardly anybody leaves Infinite Red. Maybe every other year, we might lose one person. And even with those people, they tend to come back [laughs], which is a great sign. They go out and find out that, yeah, actually, Infinite Red is pretty awesome, and they come back. So, we really look for that. We really focus on that. We want that to happen.

+ +

And it's really less about making the most money we can. Obviously, everybody wants to be well paid. And so, we're going to try to make sure we have a successful business in that way and that we want to be around for a long time. But, really, measuring success is less about business success and it's more about life success. It's really more about family success, being with my four kids, being there for them when they need me to be. That's why we're remote, you know, as another example. So, everything really hinges off of that. It's around happiness. It's around fulfillment. It's not around financial success.

+ +

WILL: I'm a huge John Maxwell fan, by the way.

+ +

JAMON: [laughs] There you go.

+ +

WILL: So, yes, I love it. And I love how you explained, you know, because one of my questions I was going to ask you is about the core values, but I'm going to switch it up a little bit. So, I'm just going to say, in my opinion, I feel like there's almost leadership talk void at times, especially in the tech space. Like, we don't talk about leadership a lot. But it plays a huge part in what we do day to day. Like, you named a couple of core values and principles that you're following because of the leadership. So, for you, why is the leadership so important and I guess you can say have a seat at the table at Infinite Red?

+ +

JAMON: I'm a strong believer, and I've become more of a strong believer over time, that it all starts at the top. If you don't have buy-in from your top leadership, it does not really matter what happens otherwise because they will continually undermine, and they have the power to continually undermine that. So, these core values have to apply to the top leaders. They have to be held accountable to that. And these leaders also need to be developed.

+ +

So, we have three owners. We have three directors. And the three directors who are underneath us were not directors when we hired them; you know, they started out as developers. They started out as designers. They started out as project managers. But they became Director of Operations, Director of Engineering, Director of Communications. And we developed them. We poured a lot of time into them, and we continue to do that. In fact, even reading this book with them and going through that exercise is continuing to invest in them. Not that we as owners don't have growth to do; we also do. And so, we learn from them, and we learn from our team. So, you have to start there.

+ +

And on that same vein, we do have some core values. We call them our foundation and our pillars. We have three foundational things, and we have four pillars. So, the three foundations are: one, we control our own destiny. We are not going to be beholden to some other company. We're not going to ride someone else's coattails. We're not going to be in a situation where someone else can kill us. And it can be easily done that way where we're in a position where, you know, we're too reliant on one whale client or something like that. We just won't do it.

+ +

The second foundational thing is that we have...it's a word bonitas, which means kindness, friendliness, benevolence, blamelessness. And it's basically just being a good person to everybody and doing the right thing.

+ +

And the third one is having a significant positive impact. That's why we do so much media. That's why we try to have an impact outside. And we're only 30 people, but people think we're way bigger because of how we kind of present ourselves in the world. And then our pillars all support those things, so high personal support. We support each other. We have high expectations, but we also support each other not just at work but also as a whole person.

+ +

Long-term viewpoint, we think way beyond this year. We think about what is Infinite Red going to be when I retire? You know, I'm 41; that's a ways out, hopefully. But what's that going to look like?

+ +

The next one is collaborative creativity. Creativity by yourself is just a solo thing. We're a team, so it has to be collaborative. We have to do it together. All our creative work, whether it's our conference, Chain React, or our work, it's all collaborative, and we love being creative.

+ +

And the last thing is being pioneers, pioneering spirit. We like to be pioneers in technology. We put out a lot of open source. And we try to bring that pioneering spirit everywhere we go. And then, there's a lot of different things that kind of come out of that. For example, we have this internal saying, which is, "Don't do hard things alone."

+ +

So, you have a hard thing coming up? And it could be hard in various ways. It could be a technically challenging thing. It could just be hard because of the mood you're in that day. But don't do it alone. Ask someone to help you, you know, jump in with you, pair with you. Do it together. And we love that. That's part of the high personal support and the bonitas. So, all these things come out of the foundation and pillars that we have.

+ +

WILL: Wow, I love all those. I want to pick one of them out and ask you a question around it. So, you're talking about having an impact. I'm loving this conversation just talking to you. It's just been amazing. So, for you, what do you want the impact on the world to be from your perspective?

+ +

JAMON: That's a hard question to answer, and it tends to be something that I think about a lot. I'm more of an opportunistic person. I react more than I plan ahead, that sort of thing. But with that said, I think that we have had significant positive impact through a lot of different ways. So, on Twitter, for example, I try to present a...and this is authentically who I am. But I try to present a positive force out there, someone who's excited and enthusiastic about the technology, who supports other people, even who you might consider competitors, for example.

+ +

I just retweeted recently a Callstack thing. I mean, you might consider them a competitor. They're another React Native agency. But I love Callstack. They're great people. And I retweeted one of their really amazing resources, which is the ultimate guide to React Native performance, which, by the way, is really good. And if you do React Native, you should check it out.

+ +

So, I think what goes around comes around, and I really want to have that positive impact out there. I want to give talks that inspire people. You know, I'm a nerd, and I'm going to nerd out about stuff. And I feel like that has an impact all of its own. So, that's kind of my personal side of it. And then Infinite Red is a showcase that you can run a company the right way. You can treat people the right way. And the company can be successful along our own metrics of success.

+ +

WILL: So, one of my biggest principles that I've learned in life that's changed my leadership 100,000% is from this book called One Minute Manager. And I think it's called one-minute praise. And, essentially, the background behind it is, if you think something, just tell the person because so many times...and I get in my head, and I think amazing things about people, but I never say it.

+ +

JAMON: [laughs]

+ +

WILL: So, I want to just tell you, like, you said, the impact that you're making. You are doing that. Like, one of the reasons why I invited you on the show was because of your impact that I see that you're having on Twitter and LinkedIn and just everything that you're doing at Infinite Red. So, keep going. I want you to know that you are making a difference. I see you, and it's making a big difference in my life.

+ +

JAMON: I love that, and it makes me feel great. And I appreciate you sharing that one-minute praise there. It is something that sometimes you put it out there, and you don't really know what the impact is, you know, it's sort of hidden in maybe the likes, or the replies, or whatever.

+ +

As an example, I just reached out to my friend Aaron Francis last night, and I told him, "Hey, I love your videos." I don't even do the tech that he does. But I watch his videos on YouTube because I just love the vibe that he has. And I told him that. I was like, "You're doing a great job. You're being a very good advocate for your company." And I agree with you; I think that just taking the moment to reach out and say, "Hey, I think you're doing good work," it encourages people to do more of it. So, I appreciate it a lot, Will. That's really nice of you to say.

+ +

WILL: Yeah, definitely. If you can go back, what is some advice that you would give yourself? We could do both at the beginning when you did ClearSight and whenever you merged and did Infinite Red. Was there any advice that you're like, wow, I learned these lessons, and they were game changers for me?

+ +

JAMON: [laughs] Boy, this could be a whole nother podcast, to be honest. There are so many different things that I've kind of learned over the years. I feel like, you know, there's value in, you know, there was actually...I forget exactly where I heard this, but it was about Cloudflare, the company.

+ +

And a long time ago, as they were sort of launching, one of the people that worked on the...I think it was their founder, actually. One of their investors told him, "Hey, running a company is sort of like flying an airplane. You want to make sure that it's well-maintained at all times. And then, when you're flying, you keep the wheel steady and the nose 10 degrees above the horizon so you continue to rise. And you don't need to shoot for the moon. We're not a rocket here. Just continue to execute well, make sure that it's well maintained, make sure that you're continually rising."

+ +

And Cloudflare is a good example of this, and I think that Infinite Red is as well. Every year, we try to do something where we're continuing to keep that nose 10% above the horizon. That doesn't always mean growing. Like, we don't hire all that often. We don't grow in terms of headcount, but we grow in other ways. And you can see that looking back over the years. Every year, there was something that we continued to, you know, improve, keeping that nose 10 degrees above the horizon. And so, that's a big one. And you can just go do all the little things really well and continue to think long term and where are you headed. And if you do the right things long enough, good things happen.

+ +

WILL: I love that because, especially when I'm working out, I try to shoot for the moon.

+ +

JAMON: [laughs]

+ +

WILL: I go all out. So, that was some amazing advice. I don't even remember who told me, but when I first started programming, I tried to shoot for the moon. And, oh, I crashed and burned so many times [laughs] because it's just something you can't just master it, and just like, I got it, da da da. And I love that advice. That's amazing advice. So, that's perfect.

+ +

JAMON: Yeah, it really stuck with me, and I have so many more lessons. I have actually kept a notebook of profound things that I've heard over the years, and I actually really enjoy that minute praising you said. And I'm going to look up the quote after this, and I'm going to put it in my notebook.

+ +

[laughter]

+ +

WILL: Yeah, yeah. It's been a game-changer because I'm a very straightforward person. And so, a lot of times, like, I don't mind addressing an issue just head-on. But what I found is I'm just always doing that. And I never had equity in the bank at times. This is when I was a very young leader. I didn't have equity. And so, it was just hard to tell people, "Hey, can we tweak this? Can we do that?"

+ +

And then I had to sit back and say, okay, what can I change to be a better leader? And it's like, I can connect better. And I see so many things. Like, I'm very observant, I think. To be honest, it's helped me in every area, even with my spouse, with my kids, with friends. It's just saying, "Hey, I see what you did. I see that you made breakfast." Or "My kids, I see that you made this beautiful mud pie for me. And it's amazing. So, thank you. Thank you." And so, yeah, it's been a game changer for me.

+ +

JAMON: Yeah, one of my friends, his goal was...and he's a leader. And he said that his goal with everyone on one was to give them one thing to change and highlight one thing they did well like you said, equity in the bank. He was talking about when he was a leader of, like, a call bank. And he said, "No matter how bad the call was, I wouldn't give them more than two things to improve because there was no way that they could take ten critiques and improve. They would just be defeated." And then, he would review and see if they could improve one more thing, avoided negative language, things like that. So, that's a really interesting concept.

+ +

WILL: Yeah, definitely, definitely. So, I have one other question for you. What motivates you? What's your wind in your sails? What keeps you going? Because I know running a consultant agency is not easy. What keeps you going?

+ +

JAMON: For me, motivation tends to be enthusiasm for learning, really more than anything, like going into something new and, like, exploring. I see it more as exploring even than learning. With a consultancy, there's always so many different...it's never the same, you know, there's always some other challenge. And that's one of the reasons I've loved being, you know, a consultancy owner for so many years. You're never dealing with just the same stuff over and over. So, I would say it's really about the exploration that happens, and just loving code, and talking shop, and being around great people. To me, that continues to motivate me.

+ +

WILL: I love that. Do you have anything that you would like to promote — personally, Infinite Red, anything?

+ +

JAMON: Well, Infinite Red, of course. If you're looking for React Native, we are all senior-level React Native developers. We've been working together for a long time. So, big companies, the biggest ones you can think of, many of them have hired us to, you know, be the experts with their team. We usually put 2 or 3 people on a project, and then the client will come in with 2 to 10 people or whatever they have on their side. And we work with them side by side, teaching them as well as delivering code. So, that's really our bread and butter.

+ +

We also put on the biggest and, I think, only U.S.-based React Native conference, and it's called Chain React. It's in Portland. Next year, it's going to be in July. So, go check it out: chainreactconf.com. We'd love to see you all there. I'd love to see you there, Will. And network with all these different React Native developers. There's people from Meta, and Microsoft, Amazon, all over the world, really. And they're some of the best React Native programmers you're going to ever meet, and some great talks, and great food, and a great city.

+ +

WILL: Yeah, I would love to be there. Let me ask you this: how is Portland in July?

+ +

JAMON: Portland is amazing in July. Sometimes, it can get hot, but for the most part, it's just beautiful. It'll be like 85 degrees, not really any humidity, nice, little breeze. It's just a beautiful weather pattern around Julyish. That's why we chose that time of year. So, definitely, if you're going to be coming to Oregon, Portland, you know, West Coast, July is a great time to come. It's not going to be super, super hot, usually. Sometimes, I mean, we get over 100 sometimes, but no worries, you know, there's AC as well. But for the most part, it's beautiful.

+ +

WILL: You sold me already.

+ +

JAMON: [laughs]

+ +

WILL: So, I live in South Florida, so...[laughs]

+ +

JAMON: Yeah, it's going to be different in South Florida in July.

+ +

[laughter]

+ +

WILL: Awesome. Well, this has been an amazing chat, and just great getting to know you and learning more about Infinite Red. Thank you for being a part of the podcast.

+ +

JAMON: Yeah. Thanks for inviting me, Will. It was a lot of fun, and you're a great host. I appreciate it.

+ +

WILL: I appreciate it.

+ +

JAMON: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Jamon Holmgren.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+l2Z4qBWL + + ]]> + + Will Larry + Jamon Holmgren + + + thoughtbot's Incubator Program Mini Season 3 - Episode 01: Knect with Josh Herzig-Marx + https://podcast.thoughtbot.com/incubators3e1josh + 15095e63-8f13-423e-8ef1-cc6aab6e186e + Tue, 07 Nov 2023 00:15:00 -0500 + thoughtbot + + full + 13 + thoughtbot + thoughtbot's Incubator Program is back for a third round! This episode introduces founder Josh Herzig-Marks of Knect, and he will be sharing his journey from freelance work to joining the program and what happens throughout! So far, he appreciates the deliberate communication practices required for practical remote work, despite remote work already being second nature to him, and he understands the importance of proactive and transparent communication in a team setting. + +One critical insight for Josh so far was the misconception surrounding the term "CRM" in personal relationship management. His moment involved mislabeling a survey, which led to confusion about the project's intent. + +As the Incubator Program progresses and continues to scale, Jordyn expresses excitement about involving more teams with different geographic focuses. The goal is to foster a collaborative environment within the thoughtbot Incubator Slack channel, encouraging past and present participants to share experiences and advice. + +We invite listeners who resonate with any of the challenges heard or have potential solutions to reach out! Our next Incubator episode will introduce our other Session 3 participants, Mike and Chris, founders of Goodz. + 37:28 + no + + + thoughtbot's Incubator Program is back for a third round! This episode introduces founder Josh Herzig-Marks of Knect, and he will be sharing his journey from freelance work to joining the program and what happens throughout! So far, he appreciates the deliberate communication practices required for practical remote work, despite remote work already being second nature to him, and he understands the importance of proactive and transparent communication in a team setting. +One critical insight for Josh so far was the misconception surrounding the term "CRM" in personal relationship management. His moment involved mislabeling a survey, which led to confusion about the project's intent. +As the Incubator Program progresses and continues to scale, Jordyn expresses excitement about involving more teams with different geographic focuses. The goal is to foster a collaborative environment within the thoughtbot Incubator Slack channel, encouraging past and present participants to share experiences and advice. +We invite listeners who resonate with any of the challenges heard or have potential solutions to reach out! Our next Incubator episode will introduce our other Session 3 participants, Mike and Chris, founders of Goodz. +Follow Josh Herzig-Marx on LinkedIn (https://www.linkedin.com/in/joshuaherzigmarx/) or X (https://twitter.com/herzigma). Visit his website at joshua.herzig-marx.com (https://joshua.herzig-marx.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +LINDSEY: My name is Lindsey Christensen, and I head up marketing for thoughtbot. For anyone listening or joining who isn't familiar with thoughtbot, we're a product design and development consultancy that helps you make great products and help make your team a success. +One of the very cool ways we do that is with the thoughtbot Startup Incubator, which is a program that we launched this year and that Jordyn, who's with us today, has been heading up. What's up, Jordyn? And today, what we're going to be doing is catching up with one of the latest founders who's participating in the incubator and seeing what he's been up to since the kickoff over these last two weeks. +JOSH: It's been two weeks. It's been two really fast weeks. +LINDSEY: [laughs] Josh, could you give us a little introduction to yourself? +JOSH: Sure. I'm Josh. Hi. I've been in tech product management for, like, 20-ish years, 15 or so of those were in head-of-product roles. And a bunch of those early on were my own startup, where I discovered I was a pretty mediocre founder but really liked this product leadership thing. I had a very lucky exit, which I leveraged into a series of first product manager, first head of product, first product leader roles at a series of early-stage companies across a ton of domains: B2B, B2C, FinTech, mobile, Revtech. +And then, a little over a year ago, my partner and I got to do this thing we've been talking about for a while, which was we swapped who the primary parent was. We have two kids, two teens, 13 and 15, right now, so that's eighth grade and ninth grade. I wanted to take over primary parenting so that they could focus as much or as little on their career as they wanted to in the same way they had allowed me to do for the first 15-ish years of our kids being kids. +And if I were a better person, I would have found some kind of job that allowed for work-life balance, but I'm not. I have a whopping case of ADD, which we'll probably come back to later on in this conversation. And the way that I knew I'd be able to actually fulfill my responsibility as a primary parent was by retiring from salaried work. So, I did that a little over a year ago, last summer. And kind of keep me busy and occupied in between 8:30 in the morning, you know, school drop off and 3:00 o'clock in the afternoon school pickup. +And when I'm not doing shopping, and cooking, and lunches, and doctor's appointments, and dentist appointments, and orthodontist appointments, and play dates, and soccer practices, and basketball practices, and soccer games, and basketball games, and Bar and Bat Mitzvahs, and all the other things that we do, I built a very small niche coaching mentorship and advisory practice around founders, solo product managers, and first-time heads of product. And that's pretty much up until about two weeks ago what I had been doing with myself. +LINDSEY: That's a great update. I especially liked all the practices that you have to go to. [crosstalk 02:54] +JOSH: I do like practices. We went to a co-ed soccer game for my middle school kid. And it was the first time that the boys' team and the girls' team ever played together, and they got totally clobbered by this other team. And what I loved about it at the end was the kids weren't bummed. They were like, "That was really fun." +And, you know, for a lot of these kids, they've been friends since kindergarten. So, this is, like, nine years of being friends and playing recess soccer together. And they're not very good at soccer, but they just really love all playing together so much. And they just bring so much sportspersonship to the field. It was really a pleasure. +LINDSEY: Okay. So, you're doing all this fun primary parenting and going to all the fun practices. You've got a coaching business that you're working on as well. But there was this idea, this idea that's needling. What brings you to us? +JOSH: I think before it was an idea, it was a problem. And I knew this was a Josh problem. And the Josh problem was that I have a really big network, you know, built over the past, you know, more than 20 years of professional life. And, you know, one of the joke lines I have is that the solution to almost any business problem is found in talking to more people. I really value being able to, you know, call people up, message them, text them, email them, get together with them, ask them lots of questions, listen hard. And I try really hard to reciprocate, doing the same thing. +I don't know what your professional network looks like, Lindsey or Jordyn, over the past, I don't know, couple years, decade, however long it's been, you know. But what used to be email and LinkedIn, maybe, and maybe getting together in some local meetups, has really spiraled what, to me, feels, again, whopping case of ADD, completely out of control, right? +I have my LinkedIn network, which has not gone away, right? And now I'm a member of, I don't know, Jordyn, we share these a lot, a dozen different professional networking Slacks. Those are the ones that Jordyn and I share, probably far, far more than that, right? Product management ones, entrepreneurship ones, product marketing ones, engineering ones, tech company ones, ones geographically based for the Boston area, ones that are focused on things like climate change and climate tech. So, a ridiculous number of these. +And as somebody with some experience and the privilege to have some free time, it feels kind of like, I don't know, an obligation sounds too grandiose, but it feels like a nice way that I can give back is by participating and trying to be helpful inside of these. So, that's happened. +And Discord became a thing, you know, certainly, it had been a thing for gamers since before that. But since the beginning of the pandemic, Discord became a thing. I'm in, like, I don't know, a dozen different similar Discord groups. And I'm in WhatsApp communities, and I'm in Telegram communities. And in-person meetups have started to happen again. +And I found myself kind of losing control. I was telling people, whether, you know, over the phone, or in Zoom calls, or direct messages, that I'd make connections to them, make intros, and it was getting increasingly hard to do that. I was forgetting about people, you know, like, it's hard to remember to stay in touch with all of your colleagues when you move on from past roles. +And, you know, I would try to make connections to people to be like, okay, Lindsey, you know, you wanted to meet somebody else in marketing in the Boston area. And I remember that, like, six years ago, they worked at Rocket, and now they've moved on to something else. I can't remember what it's called. And, like, how do you, like, you know, page through your email and your Slack connections and your LinkedIn to find that person? And that was really hard, too. +So, I have ADD. My family would say that I'm, like, moderately functional. So, how do I achieve that? By creating systems for myself. And I did all the things which other people have tried to do. I built myself, like spreadsheets and Notion databases. I have an awful lot of, like, Notion databases now powered by forms. I'm like, just put your information in, and it'll appear magically into my database where I try to, you know, push the work onto other people. And none of it was really working for me. And that was kind of the genesis of the idea and then trying to figure out, is this a Josh problem, or is this a broader problem? That's kind of how I got started. +LINDSEY: Lots of people, lots of channels, not a lot of tracking or confusing tracking. And we chatted briefly before, you know, you were starting the program. And this really resonated for me. And I also ended up doing a user interview [chuckles] with the team about it. +JOSH: Yeah [laughs]. +LINDSEY: Because yeah, in my role, and moving from different companies or doing mentoring on the side, and being in investor communities and marketing communities, it gets overwhelming for sure. And I feel the pain. And I've had the embarrassing moments of not remembering how I know someone or a conversation we had, or someone I really respect asking me for an intro, and I'm like, I don't remember anything about how I know that person. +JOSH: I mean, that was both gratifying and disappointing. Gratifying, like, oh, it's not just a Josh problem; we all struggle with this, and disappointing, right? And as I've had more of these conversations, just to realize, like, I know almost nobody who doesn't struggle with this. There's a few. There's a few outliers, a few weirdos, a few superheroes who are able to do this really well and who feel in control. And, like, literally, as they describe it, it sounds like...Jordyn, you're nodding, right? It sounds like a superpower as they're describing how they do this, how they kind of manage it. +JORDYN: [laughs] +JOSH: But for the most part, thank goodness it's not a Josh problem. The bummer is, nobody has, like, you know, the magic incantation, right? The spell or the secret or, like, the one weird trick, or the tool or, like, could I just give you money and solve this thing? And none of this really exists today. And that was kind of a bummer. I was hoping for, you know, better news that this was a solved problem. +LINDSEY: [laughs] Yeah. Jordyn, heading over to you for a minute, Josh applied for the incubator with this problem that he was working on. We had a lot of great applications, I think, for this session. What made you think or you and the team land on Josh as one of our session three founders that would be a great fit for the programming? +JORDYN: I'd say it was probably two factors; one is the stage. What's really tough was figuring out who's a good stage fit for us. So, like, what that means is you've identified a specific enough problem. You're not just, like, I want to solve world hunger or something, like, super broad. There's enough of a specific pain point or a problem that you're trying to solve that there's, like, we might conceivably make progress on it in eight weeks. But you're not so far along that you are basically like, "Hey, I've got the specs for an MVP. Can you just build it?" Which is, like, too late for us. +And part of that is a discovery mindset of, "Hey, I've identified this pain point. I think other people have it. But I am very open to how we solve the problem or learning new things about it, learning that it is a bigger need in a market I've never thought about," like being open to the things we might learn together. So those things: stage fit, mindset fit. +But, also, like, it is a problem that is addressable with software, right? thoughtbot's focus is software. Like, yes, we have worked on products that are not software products, but, like, our bread and butter is software. And my personal bread and butter professionally is software. So, is the problem on the table something that, you know, software is a big component in meeting the need? +So, it's, you know, it's stage. So, I guess it's three things: stage, founder mindset, which is this combination of having conviction but being open-minded, a very weird [laughs] thing to find in a person. And then, you know, can we conceive of a way to address this with software without jumping to a solutionizing? That's sort of what we're looking for, and Josh checked all of those boxes. +And I think, also, just had a problem that people really resonated [laughs] with, which is clear from [laughs] what Lindsey was saying and for me personally as well, I think I should [laughter] say. This is a problem I have. So, when Josh and I first talked about it, I was just like, yes, I would love to solve this problem. I also wish there was some spell, or incantation, or weird trick, or existing products, et cetera. +JOSH: We might have spent an hour nerding out over all of the things that we've tried, yeah. +JORDYN: The things that we've tried, emphasis on the nerding. +JOSH: On the nerding part, yeah. +JORDYN: Any of you listening [crosstalk 10:45] +JOSH: Or what if we get sneakier connect Google Sheets to this, like, really weird web query and [laughs] -- +JORDYN: [laughs] Exactly. And then giving up because it's totally unmaintainable or, like, [laughter] impossible, yeah. So... +JOSH: Right. Oh, and it's all crap, too [laughs]. +JORDYN: Right, right. So, if anyone out there listening is like, "Oh yeah, that's me," first of all, you're not alone. Second of all, please reach out to us. We would like to interview you [crosstalk 11:09] +JOSH: Or, if anyone out there is like, "Oh, I have this thing solved," right? If you got the solution, please reach out to us. +JORDYN: [laughs] Yes, also, please. +JOSH: You can save us six more weeks of work [laughs]. +JORDYN: If you know the solution, definitely tell us. Anyway, so to your question, though, Lindsey, that's how this [inaudible 11:23], and it just seemed like a great fit along those lines. +LINDSEY: Yeah. So but, Josh, you mentioned...well, I think you kind of downplayed your founder history a little bit. But you've been a founder who had success, certainly a product team leader who has been very successful in the early-stage teams. What were you looking for from thoughtbot? Like, what attracted you to working with the thoughtbot team on your problem when you have all this kind of past experience already? +JOSH: I think there's probably three parts to it; one is I know a bunch of people in the thoughtbot team pretty well. In past roles, I have actually hired thoughtbot; I think it was twice. And I've referred a bunch of your current and past clients as well. Like, I'm just generally a big thoughtbot fan. I think I've even used thoughtbot products long before I even knew, like, Chad or Jordyn, some of your old products from, like, you know, the early 2000s. So, we're going really OG here. So, I knew thoughtbot really well and think really highly of everybody who I've interacted with there. +Number two is, I know, you say incubator, but, for me, the word that's really been resonating has been accelerator. It can be really slow the early, I don't know, weeks, months, years to go from an idea to, hey, this is really an opportunity. And I didn't want to spend weeks or years at this. I have a full-time job. It's, you know, taking care of the family. Like, that's what I wanted to be focused on. And if this was really an opportunity, I wanted to figure this out relatively quickly. And I love the fact that thoughtbot has this eight-week accelerating program. +And the third one is I had this...and, you know, not every assumption I came in with was one that I'm going to leave the program with. But I came in with the assumption that a lot of the risk was technology risk. I had a rough idea. I was quickly discovering this wasn't just a Josh problem; this was a broader problem, right? There's plenty of challenges beyond that, but it's good to discover that your problem is broad. But is it something which can actually get built and built relatively straightforward? +Jordyn here [inaudible 13:27] this all the time. You know, I don't like science project problems, right? And thoughtbot is really, really good at building software and partnering with somebody who could help to remove that kind of risk as a non-technical founder, as somebody with literally zero technical skills, I find that very, I don't know, comforting, exciting. +LINDSEY: Okay, writes down in marketing notebook: "Accelerator resonating more than incubator." [laughs] +JOSH: I wanted to get to the decision...incubator is a better word for it. But I personally wanted to get to that is this a good opportunity or a bad opportunity decision faster. +LINDSEY: To quickly validate invalidate. +JOSH: Right. I wanted this, like, I wanted to timebox this thing, and eight weeks is a nice chunk of time. +LINDSEY: Love that, yeah. +JORDYN: I want to just, like, flag here that, like, all of these words are very frustrating [laughter]. And we had a really hard time picking one. +LINDSEY: I know [laughs]. +JORDYN: And we really actually, like, in literal terms, I think that program is way more, like, founder bootcamp than anything, but thoughtbot can't run a bootcamp without people thinking it's a Rails bootcamp, right? +JOSH: Yeah. +LINDSEY: [laughs] +JORDYN: Like, if we just said, "thoughtbot bootcamp," people would be like, oh, as a developer, I should go to this bootcamp, and thoughtbot will teach me how to be a better engineer, which would be totally reasonable from a brand standpoint, right? So, we were like, all right, not bootcamp. +And then accelerator typically comes with investment dollars, in my experience as a founder, and we don't invest cash in the companies that we work with yet. So, that was off the list. And that just left incubator, which, eh, like, I don't disagree that it's not the best word, but, whatever, we lack a good one. +JOSH: I'll tell you one thing. So, I'm involved with other things in this space. I'm based in Boston but for Raleigh's brand-new Founder Institute chapter, which I think is a great program. And I'm really proud of the, you know, first cohort of founders that are going to the program down there. And I love them. And I love their energy, and enthusiasm, and focus and that we at Founder Institute are providing them with value. I think we really are, or I wouldn't be participating. +But I wanted people to work alongside me. And I think that's actually one of the things which is really unique about thoughtbot's program. This isn't, like, you know, a bunch of other founders with varying amounts of experience working alongside you. This is, like, actual people who do things: designers and software engineers, developers who are working alongside you and learning alongside you. But it makes it, I would say, less of a lonely process. +This is one of the things I remember. When I founded a company, the one time I did this prior, I did it with my best friend, which is about as unlonely as you can possibly get. And it still is really, really lonely. Having this like, you know, team backing you up and a company backing up that team and organization is nice. +LINDSEY: Thanks for sharing that about the loneliness factor. That kind of reminds me, Jordyn; I know in the last session, you were trying out the idea of, like, this founder emotion tracker. Has that made its way to session 3? +JORDYN: Not really, mostly because both of the teams we're working with, two teams, by the way, not just Josh, have been founders before. And so, the emotional rollercoaster of, like, literally every day, you know, Monday, you feel like a million bucks because you have a really great idea, and you're really excited about it. And then, Tuesday, you talk to a bunch of people who add some complexity to the assumptions that you had [laughs] made on Monday. And then you start to feel like maybe this isn't a thing, oh no. +And then, Wednesday, you learn about some, like, technical thing that you didn't realize was a stumbling block. And so, by the end of Wednesday, you're like, everything is doomed. I shouldn't even be doing this. I've just wasted everyone's time. But then the team wakes up on Thursday and is like, "Actually, there's an easy solution to this. And we've found a new group of people to talk to who have this problem in a really clear way." And then you feel like a million bucks again. And then you just cycle through it. +Like, that cycle is something that Josh and our other founding team have actually felt before. And so, we haven't really been, like, leaning on the emotional roller coaster timeline as much just because it hasn't been as relevant. And that's kind of what's tough about the program we're running, which is that everybody comes to it with different assets in hand. I always think of that scene in The Princess Bride when they're outside the castle, and Westley is like, "What do we have? What are our assets?" +It's like you arrive to this with different assets in hand. You might have already talked to 50 people, but you have no technical background. So, you don't know what on earth to do about the information that you've learned. Or, you know, maybe you do have a technical background. And so, you've done a bunch of solutionizing, but you haven't talked to a single person about [laughs] whether they have the problem you're trying to solve. Anyway, it really runs the gamut. +And so, the programming is designed to help teams find focus and find market message fit. But what people roll up with is very different. In this case, we have a cohort, so to speak, that has some prior startup experience, especially as founders. And so, they know a little bit more about how every day is going to emotionally feel different. And that emotional rollercoaster workstream is on the roadmap. But we don't spend as much time with it as we did with Ashley and with Agnes before in the first two sessions because they were first-time founders and really didn't know how they should be feeling. +And that, to me, is one of the many value adds, including what Josh mentioned, like just having a team diligently focused on your problem space full-time is a huge boost of momentum and confidence. Just, like, people thinking about the same thing you're thinking about with you and bringing their earnest efforts to solving the problem has been one of the main things people have found valuable about it, in addition to the acknowledgement that, like, you're going to have a lot of different emotions. And it doesn't mean anything necessarily. +Like, your day-to-day emotion does not mean that you are a failure or that this is a bad idea or that you're a success, and this is a good idea [laughs]. Like, neither of those things is necessarily true. +LINDSEY: So, let's chat a little bit about what has actually been happening since kickoff. So, two weeks ago, started. Jordyn, maybe I'll start with you. What has the first two weeks of programming looked like? +JORDYN: We have been really heads down on interviewing. Josh rolled up having done a survey, which yielded a bunch of conversations already, conversations [inaudible 19:34]. So, we iterated on the scripts. You know, part of the efforts of the first couple of weeks are really geared toward having our team understand the things that Josh understands already. We need to kind of get on the same page. +And so, we try to talk to as many people as we can because there's nothing...One of our theses here, beliefs, I don't know what the right word is, is that there's really nothing that drives momentum quite like team alignment, and there's nothing quite like talking to customers and hearing for yourself what their pain points are. That drives alignment. So, it's like, everyone's talking to people. I'm sure people out there have been on teams where it's like one person talks to customers, and they're translating to everybody else. "Here's what I'm hearing. So, this is what we need to build." +And it's like if everybody has first-hand experience with the conversations, alignment and conviction sort of grows organically out of it. It's a lot less work to align if everybody's talking to people. So, it's always, like, the first order of business is, how do we talk to people so that we know the things you know to the level that you know them? So, we've been doing a ton of interviewing. And then, that's about driving alignment and understanding, but it's also ultimately about trying to drive focus. +So, as we are talking to people and listening to them, we're really trying to listen for patterns and to map those to the market segments these people inhabit. So, like, every one of us has our own network that we're bringing to this effort, and so we start there. And we start where you are with what you have, right? I think that's, like, a Teddy Roosevelt quote: start where you are with what you have. Somebody said that. Anyway, so we all do that. +But really, ultimately, we want to...building software is all about a repeatable problem that you can address with a one-size-fits-all [laughs] more or less product. What we're trying to find is, like, we're trying to listen for patterns and listen for pain points that are addressable and really focus in on a narrow niche or a situation context that we can address in some repeatable way. And I would say, at this moment, we've done a bunch of that interviewing. And we're now like, okay, we're feeling the need to focus, but we have not quite started that dive. I don't know, Josh, maybe you feel the same or different. +JOSH: No, I think that's right on. I mean, you know, the first thing we all had to do was develop our own [inaudible 21:45] understanding of the problem and the potential user, right? It wasn't going to happen from me talking to people. It was going to happen from us talking to people. And then, the next step is to start to align that empathic understanding, which sounds like a thing that gets finished, but really, it's only a thing that gets started and never really ends. +And then, you know, we got to be willing to make some bets, right? We got to figure out, you know, what is our hypothesis? You know, what do we think are the risky bits? And what are the things that differentiate this from being a problem? Where I think we have broad agreement across the entire team. And, literally, everybody we spoke to, the only people who don't think this is a problem are the ones who have some complicated, ridiculous system they built themselves, which they will acknowledge is not going to apply to anybody else. So, the problem is broad, right? But where exactly is the opportunity? Because at the end of the day, we're looking to build a business. +LINDSEY: Josh, I saw your head nodding during the alignment discussion. How has it been aligning with the team around the problem you've been thinking so much about? +JOSH: I don't know, Jordyn, how you feel about it. I've found it really fun. And it's been fun for a couple of reasons. I think the number one reason that I really like it is this is a really diverse team, right? So, Jordyn and I are in Boston and have; I would say, fairly similar tech company entrepreneurish sort of, you know, hand-wavy, miscellaneous tech people, startup folks background. We have somebody in Denmark, but she's Spanish. We have someone in maybe London right now, but he's Nigerian. And we have a member of our team in Saudi Arabia. That's a lot broader perspective. +And I think that comes to play in, like, at least three different ways. They come with their own perspectives, and their own world experiences, and lived experiences, and values, and ways they talk about those things, right? Number one. They come with their own networks of people to talk to you for whom it's easy to reach. So, it's not just all hand-wavy, tech startupy folks like I'd be talking to. And, like, literally, my entire list is, like, oh, they're all people like me. Like it was really easy to get 60 people to want to talk to me because they're all people I've been talking to for a while, which is awesome and maybe a little bit uninteresting. +But more than that, they all bring different language. Like, we've been struggling. Like, this is what we did. We spent what? Two hours of our hour and a half meeting this morning struggling with, like, are we having a difference, like, meaning or a difference of words? And it's not an efficient way to use your time, but it really is an effective way to use your time. Because, like, that struggle of trying to communicate what we're hearing and try to communicate what we're thinking and what we're feeling, I think, has led to a much better understanding of the problem and maybe even the opportunity than we would have had otherwise. I'm a big fan of struggle. +JORDYN: Definitely. And I do feel like there's an element of this where you can never understand your customers' problems in too much detail. It's like every pass we do at this, we kind of have a deeper, more granular, nuanced sense of the problems. And just in that conversation this morning, we, like, took a problem that we had understood one way and, like, were able to break it down, like, okay, what are the actual pieces of this? Oh, there's, like, many pieces of it, right? Like you said, Josh, it feels inefficient, or sometimes it just feels like you walk out of a call and you're like, what was that about? +And then only later do you find, you know, maybe when we are ideating, like, ways we might solve a problem, that conversation we had that felt really murky and, like, are we just arguing about semantics here? Are we arguing [laughs]...I don't know, like, however, you might frame that, like, actually becomes really important where you're like, oh, well, I'm very glad we took the time to break this problem down because now that we're trying to develop a solution, it becomes clear that there are many, little things we're trying to solve. And we can't solve them all at once. And so, it's great that we all have a fluent understanding of the details of that because it makes those conversations much faster so [inaudible 25:30]. +JOSH: Can I say a nice thing about thoughtbot? I know this isn't, like, the, you know, [crosstalk 25:34] +LINDSEY: Please. Please do. Welcome, Josh. Yeah, the floor is yours. +JOSH: Let me say a nice thing about thoughtbot. The last time I did this, I did this with my best friend, Ben, a person I had literally known since I was six years old, maybe five, I don't know, since first grade. And we were entering a new space. This was, like, grocery marketing. +And we talked to a crap ton of people, a lot of them doing things like going to grocery store headquarters and just talking to people and meeting people who are, like, manufacturers of a grocery product and going to trade shows with 60,000 grocers all in one giant room. Remember those days pre-COVID? We would, like, you know, take the samples with your left hand and shake with your right hand, and don't get those two things mixed up because there's a lot of people in the room with you. +And we talked to easily 1,000 people, and we knew how to establish that, like, shared empathic understanding of the market and the problem really well because we were side by side. We were really well-practiced at having those conversations. And, you know, after the day of, you know, shaking hands, and meeting people, and introducing ourselves was done, we'd go back to the hotel room, shared, of course, because we were young entrepreneurs who couldn't afford to get nice hotel rooms. And we'd spend the next couple of hours, like, talking about it. We, like, talked to each other all the time. +One nice thing about thoughtbot is you're really good at working remotely and working asynchronously. And if, you know, it had been up to me by myself to be like, okay, you know, Josh, you have this, like, remote team in different time zones with, you know, non-overlapping hours. How are you going to, like, work together to establish this common understanding, this common semantic model, this common syntax for talking about the problem, and the users, and the needs, and the opportunity? I'd be like, I don't know, right? +And this is somebody who's, like, worked remotely for the past, I don't know, 5,6, 7 years, I mean, most of his job. But, like, still, that early bit is a thing, which, you know, I've seen a lot of thoughtbot practice and skill around. And it's not an easy skill to master. And it's one that you practiced organizationally. And that's really valuable. And I don't think I fully appreciated that until we got started. +LINDSEY: Oh, thanks. Jordyn, any thoughts on that? Were you thinking about remote setup of the program, or at this point, it's just everything is remote? +JORDYN: Working remotely can really deepen, in good ways, one's communication practices because it forces you to be intentional about communicating in a way that when you are co-located with people, you kind of don't have to because there's people in front of you when you talk to them. So, I agree, Josh, that thoughtbot does a good job of making that work, the work to communicate and stay on the same page, like, tangible, visible, whatever it is. +That's also just something I've given a ton of thought to because I've been working remotely, like, as a primary orientation since 2010. And so, this is just, like, how I work. And it's very; I don't know, organic to my mind now that it's basically, like, if I'm doing something and I don't tell someone about it, it's like a tree falls in the forest, you know, if there's no one around to hear it. If I'm working on something and I don't tell anyone about it, it's like I didn't do anything. +Communication is, like, 60% of the job. And the setpoint is, oh, I did something. Oh, I emailed someone. Maybe I should tell the team about this [laughs]. Just literally because you're not in a situation where I'm going to overhear a phone call that Josh is having because he's at the desk next to mine, or I'm going to, like, ambiently be aware that, like, Carol and Toby went into a conference room to talk about something. Like, while I maybe didn't consciously think about that, it's sort of in my periphery. Like, none of that is happening because we're not in the office together, right? +We don't get to do the thing that you did with Ben, where we just talk about stuff because we're near each other. So, you really have to get into this practice of externalizing very proactively the things going on in your own mind with the team. And it's a challenge. It's work. It doesn't just happen effortlessly, right? +But yeah, to say it's critical or to say it's a critical piece of how we approach the work is an understatement. I don't know, it's like, it is the work [laughs]. The making of the software, whatever, that's easy [laughs]. Communicating about making software that's hard [laughs]. So, I don't know, it's very heartening -- +LINDSEY: Yeah, that makes sense. +JORDYN: To hear, Josh, that you think that we do a good job of that. I think we're constantly trying to do a better job of it, frankly. I don't know if you can do [crosstalk 29:28] +JOSH: That's probably why you do a good job. +LINDSEY: So, I know a lot of the early weeks, days has been around alignment and doing a lot of these user interviews. Have there been any moments yet, Josh, any new, like, light bulbs for you or insights, or are we not quite there yet; it's more kind of setting the scene? +JOSH: I'll share one really embarrassing one. +LINDSEY: Oooh. +JOSH: Which keeps on coming back to bite me. When I sent out the survey and, of course, I [inaudible 29:57] for everybody listening, basically, surveys are useless, except they're really nice lead generation tools for people who are willing to talk to you. But when we sent out the survey, at the top, it says something like, "Personal CRM survey." And I'm pretty sure that when I set up the calendar invite system, which is, by the way, for folks listening out there, like, you want to get your, like, operational side of this thing done before you start sending emails out because you're going to quickly, like, lose the ability to keep track of stuff. +I think the meeting of it also, I said something like personal CRM survey. And it was, I don't know, sometime in the middle of the first week, maybe later on, when, like, I think we all realized on the team that, like, CRM is the wrong framing for this thing, right? Nobody likes CRMS [laughs]. CRMs are transactional. They're tools to sell something to somebody. You know, they are tools for, like, auditing your behavior if you're a salesperson to make sure you're doing what you're supposed to be doing. They're, like, on a cadence. Like, CRMs are tools for a world, which is not what most people aspire for their personal relationships to be. +And I don't think we've quite settled on what this thing actually is. And maybe there isn't a thing yet, right? Maybe that's part of the challenge that we're having, like, this thing doesn't exist, but it's not a CRM. And three-quarters of the way through the interviews is when I asked people like, "So, what question should I have asked you?" They all said, "Well, you didn't ask me about personal CRMs at all." I'm like, "Okay, that's a good point [laughs]." +So, there have been plenty of pivots inside of my head around this and the way that I think about this problem, and some of these things are still embarrassing and still kind of coming back to haunt me and maybe haunt the rest of the team as well. I don't know, Jordyn, what [crosstalk 31:27] +LINDSEY: Honestly, I was hoping for something way more embarrassing, but [laughs] -- +JOSH: Way more embarrassing. +JORDYN: If that's your embarrassing...[laughs] +LINDSEY: Yeah, you're doing great. You're doing great. +JORDYN: You're doing great. +JOSH: Okay, the number of video calls where I'm not wearing pants. +[laughter] +LINDSEY: Okay, onto the next question, Jordyn –- +JOSH: Embarrassing or awkward, I don't know, yeah. +[laughter] +LINDSEY: Jordyn, you mentioned that Josh is not the only participant in this [crosstalk 31:52] +JORDYN: Great question. +LINDSEY: Tell me about, why not just Josh? What's going on? What are the developments there? +JORDYN: Yeah, this is really exciting. So, we wanted to scale this program from the moment that we ran single companies [inaudible 32:08] to start because we wanted to learn as much as we could in a kind of intense, focused way from developing a process and seeing what's valuable about it. So, this was always kind of on our minds to do. +And the way it worked out was just that there were two teams at thoughtbot ready and willing to serve. And we had, you know, anytime we [inaudible 32:28] the application window, we always kind of have a list of folks that we're excited about. We can't take all of them. But in this case, we had the two teams. And it also kind of fell in this nice way where we've got this team with a center of gravity, you know, GMT center of gravity, essentially. And then we have another team, which has more of a, like, U.S. center of gravity. And so, the timing kind of worked out. +And yeah, I don't know, it wasn't anything more complex than that. It's just we'd always been on the lookout for how we could scale this effort––bring it to more folks. And this was the first opportunity where it appeared like it would work out. I mean, TBD if it's working out [laughs]. We can decide at the end [laughs]. But it's very exciting. It's fun. And we're really looking for ways to help these teams collaborate, you know, we'll see how. +Everybody's in a Slack channel together inside of thoughtbot's Slack called thoughbot incubator. And our past participants are in there as well. And we're really trying to create an atmosphere where people can help each other, share tips, talk about what they're working on. There is actually some intersection between what Josh is working on and what the other team is working on, I think, just because, Josh, what you're working on applies [laughs] to a lot of people. I think it applies to these people, too. Anyway, that's [crosstalk 33:42] +LINDSEY: It's fun to see the incubator Slack start to build out and folks talking to each other, and more thoughtboters are trickling in there. Because, Josh, you mentioned you've been a client before and a thoughtbot fan in the past. And now you can officially live in thoughtbot Slack, too, and hang out with us 24/7. +JOSH: Still just a guest. +LINDSEY: [laughs] +JOSH: Only got my two channels. Can't DM you unless you're in one of those two channels. +LINDSEY: One [crosstalk 34:11] +JOSH: But yes, it is very exciting. This is better than snacks at your downtown Boston office. +LINDSEY: Yeah, that's great. +JOSH: I think I even added an emoji to Slack. I was pretty happy with that. +LINDSEY: Oh, nice. We've got a good custom emoji library. +JOSH: I mean, that's what we have for company culture, right? Is company emojis. +LINDSEY: To kind of finish this out here, Josh or Jordyn, do you have any calls to action for our viewers or listeners, maybe interviews or survey participants or anything else? +JORDYN: Well, certainly, if the pain point we described resonates for you [laughs], reach out. We would love to interview you. Or, like Josh said, if you actually have solved this problem [laughs] -- +LINDSEY: Oh yeah, that was a good one. +JORDYN: Please reach out [laughs]. That would be amazing. +JOSH: But I actually meant that. So, like, hey, if you out there are a software developer, an entrepreneur, own a company that you think has really solved this, I would love to learn from that if you want to talk to us. +If you are a person who struggles with this and feels like you've tried really hard to solve this, I'd love to hear from you as well. You know, did you search for a tool? Did you ask your friends? Did you try to build something yourself? Do you still use that thing you built yourself? Did you try one of those CRMs? [crosstalk 35:26] Did you try a personal CRM tool out there, right? Clay, Dex, Monica, folk, if those names resonate with you, like, I want to hear, right? I want to hear about people who feel like they're doing this thing really well or people who don't feel like they're doing as well as they should but who feel like they've put, like, real effort into it. +LINDSEY: Great. Well, we're going to be catching up with Josh here every other week. +JOSH: Great. +LINDSEY: We'll have some updates on the thoughtbot blog. And in our alternating week, we're going to be catching up with the other founders going through the incubator. So, next week, we're going to chat with Mike and Chris. And y'all will get to meet them and hear a little bit about their journey and what's led them to validating their idea in the thoughtbot incubator as well. +JOSH: And strong rec people to tune in for that one. They are extremely photogenic and very funny, and they talk slower than me, too, so a greater chance for people to understand what they're saying. So, all in all, definitely tune in for that. +LINDSEY: That's a great promo. +If you want to stay up to date with the incubator or are thinking about applying for the next session, I think will be in the new year, you can go to thoughtbot.com/incubator. And you can also sign up for email updates. And we can make sure to send you recordings of these interviews as well as the blog updates and then keep you up to date about when applications open and end. +Jordyn and Josh, thank you so much for joining today and sharing what's been going on in the early days. It's really exciting to follow along. All right, have a great day. Thanks, everyone, for watching. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Jordyn Bonds and Josh Herzig-Marx . + + + thoughtbot's Incubator Program is back for a third round! This episode introduces founder Josh Herzig-Marks of Knect, and he will be sharing his journey from freelance work to joining the program and what happens throughout! So far, he appreciates the deliberate communication practices required for practical remote work, despite remote work already being second nature to him, and he understands the importance of proactive and transparent communication in a team setting.

+ +

One critical insight for Josh so far was the misconception surrounding the term "CRM" in personal relationship management. His moment involved mislabeling a survey, which led to confusion about the project's intent.

+ +

As the Incubator Program progresses and continues to scale, Jordyn expresses excitement about involving more teams with different geographic focuses. The goal is to foster a collaborative environment within the thoughtbot Incubator Slack channel, encouraging past and present participants to share experiences and advice.

+ +

We invite listeners who resonate with any of the challenges heard or have potential solutions to reach out! Our next Incubator episode will introduce our other Session 3 participants, Mike and Chris, founders of Goodz.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: My name is Lindsey Christensen, and I head up marketing for thoughtbot. For anyone listening or joining who isn't familiar with thoughtbot, we're a product design and development consultancy that helps you make great products and help make your team a success.

+ +

One of the very cool ways we do that is with the thoughtbot Startup Incubator, which is a program that we launched this year and that Jordyn, who's with us today, has been heading up. What's up, Jordyn? And today, what we're going to be doing is catching up with one of the latest founders who's participating in the incubator and seeing what he's been up to since the kickoff over these last two weeks.

+ +

JOSH: It's been two weeks. It's been two really fast weeks.

+ +

LINDSEY: [laughs] Josh, could you give us a little introduction to yourself?

+ +

JOSH: Sure. I'm Josh. Hi. I've been in tech product management for, like, 20-ish years, 15 or so of those were in head-of-product roles. And a bunch of those early on were my own startup, where I discovered I was a pretty mediocre founder but really liked this product leadership thing. I had a very lucky exit, which I leveraged into a series of first product manager, first head of product, first product leader roles at a series of early-stage companies across a ton of domains: B2B, B2C, FinTech, mobile, Revtech.

+ +

And then, a little over a year ago, my partner and I got to do this thing we've been talking about for a while, which was we swapped who the primary parent was. We have two kids, two teens, 13 and 15, right now, so that's eighth grade and ninth grade. I wanted to take over primary parenting so that they could focus as much or as little on their career as they wanted to in the same way they had allowed me to do for the first 15-ish years of our kids being kids.

+ +

And if I were a better person, I would have found some kind of job that allowed for work-life balance, but I'm not. I have a whopping case of ADD, which we'll probably come back to later on in this conversation. And the way that I knew I'd be able to actually fulfill my responsibility as a primary parent was by retiring from salaried work. So, I did that a little over a year ago, last summer. And kind of keep me busy and occupied in between 8:30 in the morning, you know, school drop off and 3:00 o'clock in the afternoon school pickup.

+ +

And when I'm not doing shopping, and cooking, and lunches, and doctor's appointments, and dentist appointments, and orthodontist appointments, and play dates, and soccer practices, and basketball practices, and soccer games, and basketball games, and Bar and Bat Mitzvahs, and all the other things that we do, I built a very small niche coaching mentorship and advisory practice around founders, solo product managers, and first-time heads of product. And that's pretty much up until about two weeks ago what I had been doing with myself.

+ +

LINDSEY: That's a great update. I especially liked all the practices that you have to go to. [crosstalk 02:54]

+ +

JOSH: I do like practices. We went to a co-ed soccer game for my middle school kid. And it was the first time that the boys' team and the girls' team ever played together, and they got totally clobbered by this other team. And what I loved about it at the end was the kids weren't bummed. They were like, "That was really fun."

+ +

And, you know, for a lot of these kids, they've been friends since kindergarten. So, this is, like, nine years of being friends and playing recess soccer together. And they're not very good at soccer, but they just really love all playing together so much. And they just bring so much sportspersonship to the field. It was really a pleasure.

+ +

LINDSEY: Okay. So, you're doing all this fun primary parenting and going to all the fun practices. You've got a coaching business that you're working on as well. But there was this idea, this idea that's needling. What brings you to us?

+ +

JOSH: I think before it was an idea, it was a problem. And I knew this was a Josh problem. And the Josh problem was that I have a really big network, you know, built over the past, you know, more than 20 years of professional life. And, you know, one of the joke lines I have is that the solution to almost any business problem is found in talking to more people. I really value being able to, you know, call people up, message them, text them, email them, get together with them, ask them lots of questions, listen hard. And I try really hard to reciprocate, doing the same thing.

+ +

I don't know what your professional network looks like, Lindsey or Jordyn, over the past, I don't know, couple years, decade, however long it's been, you know. But what used to be email and LinkedIn, maybe, and maybe getting together in some local meetups, has really spiraled what, to me, feels, again, whopping case of ADD, completely out of control, right?

+ +

I have my LinkedIn network, which has not gone away, right? And now I'm a member of, I don't know, Jordyn, we share these a lot, a dozen different professional networking Slacks. Those are the ones that Jordyn and I share, probably far, far more than that, right? Product management ones, entrepreneurship ones, product marketing ones, engineering ones, tech company ones, ones geographically based for the Boston area, ones that are focused on things like climate change and climate tech. So, a ridiculous number of these.

+ +

And as somebody with some experience and the privilege to have some free time, it feels kind of like, I don't know, an obligation sounds too grandiose, but it feels like a nice way that I can give back is by participating and trying to be helpful inside of these. So, that's happened.

+ +

And Discord became a thing, you know, certainly, it had been a thing for gamers since before that. But since the beginning of the pandemic, Discord became a thing. I'm in, like, I don't know, a dozen different similar Discord groups. And I'm in WhatsApp communities, and I'm in Telegram communities. And in-person meetups have started to happen again.

+ +

And I found myself kind of losing control. I was telling people, whether, you know, over the phone, or in Zoom calls, or direct messages, that I'd make connections to them, make intros, and it was getting increasingly hard to do that. I was forgetting about people, you know, like, it's hard to remember to stay in touch with all of your colleagues when you move on from past roles.

+ +

And, you know, I would try to make connections to people to be like, okay, Lindsey, you know, you wanted to meet somebody else in marketing in the Boston area. And I remember that, like, six years ago, they worked at Rocket, and now they've moved on to something else. I can't remember what it's called. And, like, how do you, like, you know, page through your email and your Slack connections and your LinkedIn to find that person? And that was really hard, too.

+ +

So, I have ADD. My family would say that I'm, like, moderately functional. So, how do I achieve that? By creating systems for myself. And I did all the things which other people have tried to do. I built myself, like spreadsheets and Notion databases. I have an awful lot of, like, Notion databases now powered by forms. I'm like, just put your information in, and it'll appear magically into my database where I try to, you know, push the work onto other people. And none of it was really working for me. And that was kind of the genesis of the idea and then trying to figure out, is this a Josh problem, or is this a broader problem? That's kind of how I got started.

+ +

LINDSEY: Lots of people, lots of channels, not a lot of tracking or confusing tracking. And we chatted briefly before, you know, you were starting the program. And this really resonated for me. And I also ended up doing a user interview [chuckles] with the team about it.

+ +

JOSH: Yeah [laughs].

+ +

LINDSEY: Because yeah, in my role, and moving from different companies or doing mentoring on the side, and being in investor communities and marketing communities, it gets overwhelming for sure. And I feel the pain. And I've had the embarrassing moments of not remembering how I know someone or a conversation we had, or someone I really respect asking me for an intro, and I'm like, I don't remember anything about how I know that person.

+ +

JOSH: I mean, that was both gratifying and disappointing. Gratifying, like, oh, it's not just a Josh problem; we all struggle with this, and disappointing, right? And as I've had more of these conversations, just to realize, like, I know almost nobody who doesn't struggle with this. There's a few. There's a few outliers, a few weirdos, a few superheroes who are able to do this really well and who feel in control. And, like, literally, as they describe it, it sounds like...Jordyn, you're nodding, right? It sounds like a superpower as they're describing how they do this, how they kind of manage it.

+ +

JORDYN: [laughs]

+ +

JOSH: But for the most part, thank goodness it's not a Josh problem. The bummer is, nobody has, like, you know, the magic incantation, right? The spell or the secret or, like, the one weird trick, or the tool or, like, could I just give you money and solve this thing? And none of this really exists today. And that was kind of a bummer. I was hoping for, you know, better news that this was a solved problem.

+ +

LINDSEY: [laughs] Yeah. Jordyn, heading over to you for a minute, Josh applied for the incubator with this problem that he was working on. We had a lot of great applications, I think, for this session. What made you think or you and the team land on Josh as one of our session three founders that would be a great fit for the programming?

+ +

JORDYN: I'd say it was probably two factors; one is the stage. What's really tough was figuring out who's a good stage fit for us. So, like, what that means is you've identified a specific enough problem. You're not just, like, I want to solve world hunger or something, like, super broad. There's enough of a specific pain point or a problem that you're trying to solve that there's, like, we might conceivably make progress on it in eight weeks. But you're not so far along that you are basically like, "Hey, I've got the specs for an MVP. Can you just build it?" Which is, like, too late for us.

+ +

And part of that is a discovery mindset of, "Hey, I've identified this pain point. I think other people have it. But I am very open to how we solve the problem or learning new things about it, learning that it is a bigger need in a market I've never thought about," like being open to the things we might learn together. So those things: stage fit, mindset fit.

+ +

But, also, like, it is a problem that is addressable with software, right? thoughtbot's focus is software. Like, yes, we have worked on products that are not software products, but, like, our bread and butter is software. And my personal bread and butter professionally is software. So, is the problem on the table something that, you know, software is a big component in meeting the need?

+ +

So, it's, you know, it's stage. So, I guess it's three things: stage, founder mindset, which is this combination of having conviction but being open-minded, a very weird [laughs] thing to find in a person. And then, you know, can we conceive of a way to address this with software without jumping to a solutionizing? That's sort of what we're looking for, and Josh checked all of those boxes.

+ +

And I think, also, just had a problem that people really resonated [laughs] with, which is clear from [laughs] what Lindsey was saying and for me personally as well, I think I should [laughter] say. This is a problem I have. So, when Josh and I first talked about it, I was just like, yes, I would love to solve this problem. I also wish there was some spell, or incantation, or weird trick, or existing products, et cetera.

+ +

JOSH: We might have spent an hour nerding out over all of the things that we've tried, yeah.

+ +

JORDYN: The things that we've tried, emphasis on the nerding.

+ +

JOSH: On the nerding part, yeah.

+ +

JORDYN: Any of you listening [crosstalk 10:45]

+ +

JOSH: Or what if we get sneakier connect Google Sheets to this, like, really weird web query and [laughs] --

+ +

JORDYN: [laughs] Exactly. And then giving up because it's totally unmaintainable or, like, [laughter] impossible, yeah. So...

+ +

JOSH: Right. Oh, and it's all crap, too [laughs].

+ +

JORDYN: Right, right. So, if anyone out there listening is like, "Oh yeah, that's me," first of all, you're not alone. Second of all, please reach out to us. We would like to interview you [crosstalk 11:09]

+ +

JOSH: Or, if anyone out there is like, "Oh, I have this thing solved," right? If you got the solution, please reach out to us.

+ +

JORDYN: [laughs] Yes, also, please.

+ +

JOSH: You can save us six more weeks of work [laughs].

+ +

JORDYN: If you know the solution, definitely tell us. Anyway, so to your question, though, Lindsey, that's how this [inaudible 11:23], and it just seemed like a great fit along those lines.

+ +

LINDSEY: Yeah. So but, Josh, you mentioned...well, I think you kind of downplayed your founder history a little bit. But you've been a founder who had success, certainly a product team leader who has been very successful in the early-stage teams. What were you looking for from thoughtbot? Like, what attracted you to working with the thoughtbot team on your problem when you have all this kind of past experience already?

+ +

JOSH: I think there's probably three parts to it; one is I know a bunch of people in the thoughtbot team pretty well. In past roles, I have actually hired thoughtbot; I think it was twice. And I've referred a bunch of your current and past clients as well. Like, I'm just generally a big thoughtbot fan. I think I've even used thoughtbot products long before I even knew, like, Chad or Jordyn, some of your old products from, like, you know, the early 2000s. So, we're going really OG here. So, I knew thoughtbot really well and think really highly of everybody who I've interacted with there.

+ +

Number two is, I know, you say incubator, but, for me, the word that's really been resonating has been accelerator. It can be really slow the early, I don't know, weeks, months, years to go from an idea to, hey, this is really an opportunity. And I didn't want to spend weeks or years at this. I have a full-time job. It's, you know, taking care of the family. Like, that's what I wanted to be focused on. And if this was really an opportunity, I wanted to figure this out relatively quickly. And I love the fact that thoughtbot has this eight-week accelerating program.

+ +

And the third one is I had this...and, you know, not every assumption I came in with was one that I'm going to leave the program with. But I came in with the assumption that a lot of the risk was technology risk. I had a rough idea. I was quickly discovering this wasn't just a Josh problem; this was a broader problem, right? There's plenty of challenges beyond that, but it's good to discover that your problem is broad. But is it something which can actually get built and built relatively straightforward?

+ +

Jordyn here [inaudible 13:27] this all the time. You know, I don't like science project problems, right? And thoughtbot is really, really good at building software and partnering with somebody who could help to remove that kind of risk as a non-technical founder, as somebody with literally zero technical skills, I find that very, I don't know, comforting, exciting.

+ +

LINDSEY: Okay, writes down in marketing notebook: "Accelerator resonating more than incubator." [laughs]

+ +

JOSH: I wanted to get to the decision...incubator is a better word for it. But I personally wanted to get to that is this a good opportunity or a bad opportunity decision faster.

+ +

LINDSEY: To quickly validate invalidate.

+ +

JOSH: Right. I wanted this, like, I wanted to timebox this thing, and eight weeks is a nice chunk of time.

+ +

LINDSEY: Love that, yeah.

+ +

JORDYN: I want to just, like, flag here that, like, all of these words are very frustrating [laughter]. And we had a really hard time picking one.

+ +

LINDSEY: I know [laughs].

+ +

JORDYN: And we really actually, like, in literal terms, I think that program is way more, like, founder bootcamp than anything, but thoughtbot can't run a bootcamp without people thinking it's a Rails bootcamp, right?

+ +

JOSH: Yeah.

+ +

LINDSEY: [laughs]

+ +

JORDYN: Like, if we just said, "thoughtbot bootcamp," people would be like, oh, as a developer, I should go to this bootcamp, and thoughtbot will teach me how to be a better engineer, which would be totally reasonable from a brand standpoint, right? So, we were like, all right, not bootcamp.

+ +

And then accelerator typically comes with investment dollars, in my experience as a founder, and we don't invest cash in the companies that we work with yet. So, that was off the list. And that just left incubator, which, eh, like, I don't disagree that it's not the best word, but, whatever, we lack a good one.

+ +

JOSH: I'll tell you one thing. So, I'm involved with other things in this space. I'm based in Boston but for Raleigh's brand-new Founder Institute chapter, which I think is a great program. And I'm really proud of the, you know, first cohort of founders that are going to the program down there. And I love them. And I love their energy, and enthusiasm, and focus and that we at Founder Institute are providing them with value. I think we really are, or I wouldn't be participating.

+ +

But I wanted people to work alongside me. And I think that's actually one of the things which is really unique about thoughtbot's program. This isn't, like, you know, a bunch of other founders with varying amounts of experience working alongside you. This is, like, actual people who do things: designers and software engineers, developers who are working alongside you and learning alongside you. But it makes it, I would say, less of a lonely process.

+ +

This is one of the things I remember. When I founded a company, the one time I did this prior, I did it with my best friend, which is about as unlonely as you can possibly get. And it still is really, really lonely. Having this like, you know, team backing you up and a company backing up that team and organization is nice.

+ +

LINDSEY: Thanks for sharing that about the loneliness factor. That kind of reminds me, Jordyn; I know in the last session, you were trying out the idea of, like, this founder emotion tracker. Has that made its way to session 3?

+ +

JORDYN: Not really, mostly because both of the teams we're working with, two teams, by the way, not just Josh, have been founders before. And so, the emotional rollercoaster of, like, literally every day, you know, Monday, you feel like a million bucks because you have a really great idea, and you're really excited about it. And then, Tuesday, you talk to a bunch of people who add some complexity to the assumptions that you had [laughs] made on Monday. And then you start to feel like maybe this isn't a thing, oh no.

+ +

And then, Wednesday, you learn about some, like, technical thing that you didn't realize was a stumbling block. And so, by the end of Wednesday, you're like, everything is doomed. I shouldn't even be doing this. I've just wasted everyone's time. But then the team wakes up on Thursday and is like, "Actually, there's an easy solution to this. And we've found a new group of people to talk to who have this problem in a really clear way." And then you feel like a million bucks again. And then you just cycle through it.

+ +

Like, that cycle is something that Josh and our other founding team have actually felt before. And so, we haven't really been, like, leaning on the emotional roller coaster timeline as much just because it hasn't been as relevant. And that's kind of what's tough about the program we're running, which is that everybody comes to it with different assets in hand. I always think of that scene in The Princess Bride when they're outside the castle, and Westley is like, "What do we have? What are our assets?"

+ +

It's like you arrive to this with different assets in hand. You might have already talked to 50 people, but you have no technical background. So, you don't know what on earth to do about the information that you've learned. Or, you know, maybe you do have a technical background. And so, you've done a bunch of solutionizing, but you haven't talked to a single person about [laughs] whether they have the problem you're trying to solve. Anyway, it really runs the gamut.

+ +

And so, the programming is designed to help teams find focus and find market message fit. But what people roll up with is very different. In this case, we have a cohort, so to speak, that has some prior startup experience, especially as founders. And so, they know a little bit more about how every day is going to emotionally feel different. And that emotional rollercoaster workstream is on the roadmap. But we don't spend as much time with it as we did with Ashley and with Agnes before in the first two sessions because they were first-time founders and really didn't know how they should be feeling.

+ +

And that, to me, is one of the many value adds, including what Josh mentioned, like just having a team diligently focused on your problem space full-time is a huge boost of momentum and confidence. Just, like, people thinking about the same thing you're thinking about with you and bringing their earnest efforts to solving the problem has been one of the main things people have found valuable about it, in addition to the acknowledgement that, like, you're going to have a lot of different emotions. And it doesn't mean anything necessarily.

+ +

Like, your day-to-day emotion does not mean that you are a failure or that this is a bad idea or that you're a success, and this is a good idea [laughs]. Like, neither of those things is necessarily true.

+ +

LINDSEY: So, let's chat a little bit about what has actually been happening since kickoff. So, two weeks ago, started. Jordyn, maybe I'll start with you. What has the first two weeks of programming looked like?

+ +

JORDYN: We have been really heads down on interviewing. Josh rolled up having done a survey, which yielded a bunch of conversations already, conversations [inaudible 19:34]. So, we iterated on the scripts. You know, part of the efforts of the first couple of weeks are really geared toward having our team understand the things that Josh understands already. We need to kind of get on the same page.

+ +

And so, we try to talk to as many people as we can because there's nothing...One of our theses here, beliefs, I don't know what the right word is, is that there's really nothing that drives momentum quite like team alignment, and there's nothing quite like talking to customers and hearing for yourself what their pain points are. That drives alignment. So, it's like, everyone's talking to people. I'm sure people out there have been on teams where it's like one person talks to customers, and they're translating to everybody else. "Here's what I'm hearing. So, this is what we need to build."

+ +

And it's like if everybody has first-hand experience with the conversations, alignment and conviction sort of grows organically out of it. It's a lot less work to align if everybody's talking to people. So, it's always, like, the first order of business is, how do we talk to people so that we know the things you know to the level that you know them? So, we've been doing a ton of interviewing. And then, that's about driving alignment and understanding, but it's also ultimately about trying to drive focus.

+ +

So, as we are talking to people and listening to them, we're really trying to listen for patterns and to map those to the market segments these people inhabit. So, like, every one of us has our own network that we're bringing to this effort, and so we start there. And we start where you are with what you have, right? I think that's, like, a Teddy Roosevelt quote: start where you are with what you have. Somebody said that. Anyway, so we all do that.

+ +

But really, ultimately, we want to...building software is all about a repeatable problem that you can address with a one-size-fits-all [laughs] more or less product. What we're trying to find is, like, we're trying to listen for patterns and listen for pain points that are addressable and really focus in on a narrow niche or a situation context that we can address in some repeatable way. And I would say, at this moment, we've done a bunch of that interviewing. And we're now like, okay, we're feeling the need to focus, but we have not quite started that dive. I don't know, Josh, maybe you feel the same or different.

+ +

JOSH: No, I think that's right on. I mean, you know, the first thing we all had to do was develop our own [inaudible 21:45] understanding of the problem and the potential user, right? It wasn't going to happen from me talking to people. It was going to happen from us talking to people. And then, the next step is to start to align that empathic understanding, which sounds like a thing that gets finished, but really, it's only a thing that gets started and never really ends.

+ +

And then, you know, we got to be willing to make some bets, right? We got to figure out, you know, what is our hypothesis? You know, what do we think are the risky bits? And what are the things that differentiate this from being a problem? Where I think we have broad agreement across the entire team. And, literally, everybody we spoke to, the only people who don't think this is a problem are the ones who have some complicated, ridiculous system they built themselves, which they will acknowledge is not going to apply to anybody else. So, the problem is broad, right? But where exactly is the opportunity? Because at the end of the day, we're looking to build a business.

+ +

LINDSEY: Josh, I saw your head nodding during the alignment discussion. How has it been aligning with the team around the problem you've been thinking so much about?

+ +

JOSH: I don't know, Jordyn, how you feel about it. I've found it really fun. And it's been fun for a couple of reasons. I think the number one reason that I really like it is this is a really diverse team, right? So, Jordyn and I are in Boston and have; I would say, fairly similar tech company entrepreneurish sort of, you know, hand-wavy, miscellaneous tech people, startup folks background. We have somebody in Denmark, but she's Spanish. We have someone in maybe London right now, but he's Nigerian. And we have a member of our team in Saudi Arabia. That's a lot broader perspective.

+ +

And I think that comes to play in, like, at least three different ways. They come with their own perspectives, and their own world experiences, and lived experiences, and values, and ways they talk about those things, right? Number one. They come with their own networks of people to talk to you for whom it's easy to reach. So, it's not just all hand-wavy, tech startupy folks like I'd be talking to. And, like, literally, my entire list is, like, oh, they're all people like me. Like it was really easy to get 60 people to want to talk to me because they're all people I've been talking to for a while, which is awesome and maybe a little bit uninteresting.

+ +

But more than that, they all bring different language. Like, we've been struggling. Like, this is what we did. We spent what? Two hours of our hour and a half meeting this morning struggling with, like, are we having a difference, like, meaning or a difference of words? And it's not an efficient way to use your time, but it really is an effective way to use your time. Because, like, that struggle of trying to communicate what we're hearing and try to communicate what we're thinking and what we're feeling, I think, has led to a much better understanding of the problem and maybe even the opportunity than we would have had otherwise. I'm a big fan of struggle.

+ +

JORDYN: Definitely. And I do feel like there's an element of this where you can never understand your customers' problems in too much detail. It's like every pass we do at this, we kind of have a deeper, more granular, nuanced sense of the problems. And just in that conversation this morning, we, like, took a problem that we had understood one way and, like, were able to break it down, like, okay, what are the actual pieces of this? Oh, there's, like, many pieces of it, right? Like you said, Josh, it feels inefficient, or sometimes it just feels like you walk out of a call and you're like, what was that about?

+ +

And then only later do you find, you know, maybe when we are ideating, like, ways we might solve a problem, that conversation we had that felt really murky and, like, are we just arguing about semantics here? Are we arguing [laughs]...I don't know, like, however, you might frame that, like, actually becomes really important where you're like, oh, well, I'm very glad we took the time to break this problem down because now that we're trying to develop a solution, it becomes clear that there are many, little things we're trying to solve. And we can't solve them all at once. And so, it's great that we all have a fluent understanding of the details of that because it makes those conversations much faster so [inaudible 25:30].

+ +

JOSH: Can I say a nice thing about thoughtbot? I know this isn't, like, the, you know, [crosstalk 25:34]

+ +

LINDSEY: Please. Please do. Welcome, Josh. Yeah, the floor is yours.

+ +

JOSH: Let me say a nice thing about thoughtbot. The last time I did this, I did this with my best friend, Ben, a person I had literally known since I was six years old, maybe five, I don't know, since first grade. And we were entering a new space. This was, like, grocery marketing.

+ +

And we talked to a crap ton of people, a lot of them doing things like going to grocery store headquarters and just talking to people and meeting people who are, like, manufacturers of a grocery product and going to trade shows with 60,000 grocers all in one giant room. Remember those days pre-COVID? We would, like, you know, take the samples with your left hand and shake with your right hand, and don't get those two things mixed up because there's a lot of people in the room with you.

+ +

And we talked to easily 1,000 people, and we knew how to establish that, like, shared empathic understanding of the market and the problem really well because we were side by side. We were really well-practiced at having those conversations. And, you know, after the day of, you know, shaking hands, and meeting people, and introducing ourselves was done, we'd go back to the hotel room, shared, of course, because we were young entrepreneurs who couldn't afford to get nice hotel rooms. And we'd spend the next couple of hours, like, talking about it. We, like, talked to each other all the time.

+ +

One nice thing about thoughtbot is you're really good at working remotely and working asynchronously. And if, you know, it had been up to me by myself to be like, okay, you know, Josh, you have this, like, remote team in different time zones with, you know, non-overlapping hours. How are you going to, like, work together to establish this common understanding, this common semantic model, this common syntax for talking about the problem, and the users, and the needs, and the opportunity? I'd be like, I don't know, right?

+ +

And this is somebody who's, like, worked remotely for the past, I don't know, 5,6, 7 years, I mean, most of his job. But, like, still, that early bit is a thing, which, you know, I've seen a lot of thoughtbot practice and skill around. And it's not an easy skill to master. And it's one that you practiced organizationally. And that's really valuable. And I don't think I fully appreciated that until we got started.

+ +

LINDSEY: Oh, thanks. Jordyn, any thoughts on that? Were you thinking about remote setup of the program, or at this point, it's just everything is remote?

+ +

JORDYN: Working remotely can really deepen, in good ways, one's communication practices because it forces you to be intentional about communicating in a way that when you are co-located with people, you kind of don't have to because there's people in front of you when you talk to them. So, I agree, Josh, that thoughtbot does a good job of making that work, the work to communicate and stay on the same page, like, tangible, visible, whatever it is.

+ +

That's also just something I've given a ton of thought to because I've been working remotely, like, as a primary orientation since 2010. And so, this is just, like, how I work. And it's very; I don't know, organic to my mind now that it's basically, like, if I'm doing something and I don't tell someone about it, it's like a tree falls in the forest, you know, if there's no one around to hear it. If I'm working on something and I don't tell anyone about it, it's like I didn't do anything.

+ +

Communication is, like, 60% of the job. And the setpoint is, oh, I did something. Oh, I emailed someone. Maybe I should tell the team about this [laughs]. Just literally because you're not in a situation where I'm going to overhear a phone call that Josh is having because he's at the desk next to mine, or I'm going to, like, ambiently be aware that, like, Carol and Toby went into a conference room to talk about something. Like, while I maybe didn't consciously think about that, it's sort of in my periphery. Like, none of that is happening because we're not in the office together, right?

+ +

We don't get to do the thing that you did with Ben, where we just talk about stuff because we're near each other. So, you really have to get into this practice of externalizing very proactively the things going on in your own mind with the team. And it's a challenge. It's work. It doesn't just happen effortlessly, right?

+ +

But yeah, to say it's critical or to say it's a critical piece of how we approach the work is an understatement. I don't know, it's like, it is the work [laughs]. The making of the software, whatever, that's easy [laughs]. Communicating about making software that's hard [laughs]. So, I don't know, it's very heartening --

+ +

LINDSEY: Yeah, that makes sense.

+ +

JORDYN: To hear, Josh, that you think that we do a good job of that. I think we're constantly trying to do a better job of it, frankly. I don't know if you can do [crosstalk 29:28]

+ +

JOSH: That's probably why you do a good job.

+ +

LINDSEY: So, I know a lot of the early weeks, days has been around alignment and doing a lot of these user interviews. Have there been any moments yet, Josh, any new, like, light bulbs for you or insights, or are we not quite there yet; it's more kind of setting the scene?

+ +

JOSH: I'll share one really embarrassing one.

+ +

LINDSEY: Oooh.

+ +

JOSH: Which keeps on coming back to bite me. When I sent out the survey and, of course, I [inaudible 29:57] for everybody listening, basically, surveys are useless, except they're really nice lead generation tools for people who are willing to talk to you. But when we sent out the survey, at the top, it says something like, "Personal CRM survey." And I'm pretty sure that when I set up the calendar invite system, which is, by the way, for folks listening out there, like, you want to get your, like, operational side of this thing done before you start sending emails out because you're going to quickly, like, lose the ability to keep track of stuff.

+ +

I think the meeting of it also, I said something like personal CRM survey. And it was, I don't know, sometime in the middle of the first week, maybe later on, when, like, I think we all realized on the team that, like, CRM is the wrong framing for this thing, right? Nobody likes CRMS [laughs]. CRMs are transactional. They're tools to sell something to somebody. You know, they are tools for, like, auditing your behavior if you're a salesperson to make sure you're doing what you're supposed to be doing. They're, like, on a cadence. Like, CRMs are tools for a world, which is not what most people aspire for their personal relationships to be.

+ +

And I don't think we've quite settled on what this thing actually is. And maybe there isn't a thing yet, right? Maybe that's part of the challenge that we're having, like, this thing doesn't exist, but it's not a CRM. And three-quarters of the way through the interviews is when I asked people like, "So, what question should I have asked you?" They all said, "Well, you didn't ask me about personal CRMs at all." I'm like, "Okay, that's a good point [laughs]."

+ +

So, there have been plenty of pivots inside of my head around this and the way that I think about this problem, and some of these things are still embarrassing and still kind of coming back to haunt me and maybe haunt the rest of the team as well. I don't know, Jordyn, what [crosstalk 31:27]

+ +

LINDSEY: Honestly, I was hoping for something way more embarrassing, but [laughs] --

+ +

JOSH: Way more embarrassing.

+ +

JORDYN: If that's your embarrassing...[laughs]

+ +

LINDSEY: Yeah, you're doing great. You're doing great.

+ +

JORDYN: You're doing great.

+ +

JOSH: Okay, the number of video calls where I'm not wearing pants.

+ +

[laughter]

+ +

LINDSEY: Okay, onto the next question, Jordyn –-

+ +

JOSH: Embarrassing or awkward, I don't know, yeah.

+ +

[laughter]

+ +

LINDSEY: Jordyn, you mentioned that Josh is not the only participant in this [crosstalk 31:52]

+ +

JORDYN: Great question.

+ +

LINDSEY: Tell me about, why not just Josh? What's going on? What are the developments there?

+ +

JORDYN: Yeah, this is really exciting. So, we wanted to scale this program from the moment that we ran single companies [inaudible 32:08] to start because we wanted to learn as much as we could in a kind of intense, focused way from developing a process and seeing what's valuable about it. So, this was always kind of on our minds to do.

+ +

And the way it worked out was just that there were two teams at thoughtbot ready and willing to serve. And we had, you know, anytime we [inaudible 32:28] the application window, we always kind of have a list of folks that we're excited about. We can't take all of them. But in this case, we had the two teams. And it also kind of fell in this nice way where we've got this team with a center of gravity, you know, GMT center of gravity, essentially. And then we have another team, which has more of a, like, U.S. center of gravity. And so, the timing kind of worked out.

+ +

And yeah, I don't know, it wasn't anything more complex than that. It's just we'd always been on the lookout for how we could scale this effort––bring it to more folks. And this was the first opportunity where it appeared like it would work out. I mean, TBD if it's working out [laughs]. We can decide at the end [laughs]. But it's very exciting. It's fun. And we're really looking for ways to help these teams collaborate, you know, we'll see how.

+ +

Everybody's in a Slack channel together inside of thoughtbot's Slack called thoughbot incubator. And our past participants are in there as well. And we're really trying to create an atmosphere where people can help each other, share tips, talk about what they're working on. There is actually some intersection between what Josh is working on and what the other team is working on, I think, just because, Josh, what you're working on applies [laughs] to a lot of people. I think it applies to these people, too. Anyway, that's [crosstalk 33:42]

+ +

LINDSEY: It's fun to see the incubator Slack start to build out and folks talking to each other, and more thoughtboters are trickling in there. Because, Josh, you mentioned you've been a client before and a thoughtbot fan in the past. And now you can officially live in thoughtbot Slack, too, and hang out with us 24/7.

+ +

JOSH: Still just a guest.

+ +

LINDSEY: [laughs]

+ +

JOSH: Only got my two channels. Can't DM you unless you're in one of those two channels.

+ +

LINDSEY: One [crosstalk 34:11]

+ +

JOSH: But yes, it is very exciting. This is better than snacks at your downtown Boston office.

+ +

LINDSEY: Yeah, that's great.

+ +

JOSH: I think I even added an emoji to Slack. I was pretty happy with that.

+ +

LINDSEY: Oh, nice. We've got a good custom emoji library.

+ +

JOSH: I mean, that's what we have for company culture, right? Is company emojis.

+ +

LINDSEY: To kind of finish this out here, Josh or Jordyn, do you have any calls to action for our viewers or listeners, maybe interviews or survey participants or anything else?

+ +

JORDYN: Well, certainly, if the pain point we described resonates for you [laughs], reach out. We would love to interview you. Or, like Josh said, if you actually have solved this problem [laughs] --

+ +

LINDSEY: Oh yeah, that was a good one.

+ +

JORDYN: Please reach out [laughs]. That would be amazing.

+ +

JOSH: But I actually meant that. So, like, hey, if you out there are a software developer, an entrepreneur, own a company that you think has really solved this, I would love to learn from that if you want to talk to us.

+ +

If you are a person who struggles with this and feels like you've tried really hard to solve this, I'd love to hear from you as well. You know, did you search for a tool? Did you ask your friends? Did you try to build something yourself? Do you still use that thing you built yourself? Did you try one of those CRMs? [crosstalk 35:26] Did you try a personal CRM tool out there, right? Clay, Dex, Monica, folk, if those names resonate with you, like, I want to hear, right? I want to hear about people who feel like they're doing this thing really well or people who don't feel like they're doing as well as they should but who feel like they've put, like, real effort into it.

+ +

LINDSEY: Great. Well, we're going to be catching up with Josh here every other week.

+ +

JOSH: Great.

+ +

LINDSEY: We'll have some updates on the thoughtbot blog. And in our alternating week, we're going to be catching up with the other founders going through the incubator. So, next week, we're going to chat with Mike and Chris. And y'all will get to meet them and hear a little bit about their journey and what's led them to validating their idea in the thoughtbot incubator as well.

+ +

JOSH: And strong rec people to tune in for that one. They are extremely photogenic and very funny, and they talk slower than me, too, so a greater chance for people to understand what they're saying. So, all in all, definitely tune in for that.

+ +

LINDSEY: That's a great promo.

+ +

If you want to stay up to date with the incubator or are thinking about applying for the next session, I think will be in the new year, you can go to thoughtbot.com/incubator. And you can also sign up for email updates. And we can make sure to send you recordings of these interviews as well as the blog updates and then keep you up to date about when applications open and end.

+ +

Jordyn and Josh, thank you so much for joining today and sharing what's been going on in the early days. It's really exciting to follow along. All right, have a great day. Thanks, everyone, for watching.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Jordyn Bonds and Josh Herzig-Marx .

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + thoughtbot's Incubator Program is back for a third round! This episode introduces founder Josh Herzig-Marks of Knect, and he will be sharing his journey from freelance work to joining the program and what happens throughout! So far, he appreciates the deliberate communication practices required for practical remote work, despite remote work already being second nature to him, and he understands the importance of proactive and transparent communication in a team setting.

+ +

One critical insight for Josh so far was the misconception surrounding the term "CRM" in personal relationship management. His moment involved mislabeling a survey, which led to confusion about the project's intent.

+ +

As the Incubator Program progresses and continues to scale, Jordyn expresses excitement about involving more teams with different geographic focuses. The goal is to foster a collaborative environment within the thoughtbot Incubator Slack channel, encouraging past and present participants to share experiences and advice.

+ +

We invite listeners who resonate with any of the challenges heard or have potential solutions to reach out! Our next Incubator episode will introduce our other Session 3 participants, Mike and Chris, founders of Goodz.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: My name is Lindsey Christensen, and I head up marketing for thoughtbot. For anyone listening or joining who isn't familiar with thoughtbot, we're a product design and development consultancy that helps you make great products and help make your team a success.

+ +

One of the very cool ways we do that is with the thoughtbot Startup Incubator, which is a program that we launched this year and that Jordyn, who's with us today, has been heading up. What's up, Jordyn? And today, what we're going to be doing is catching up with one of the latest founders who's participating in the incubator and seeing what he's been up to since the kickoff over these last two weeks.

+ +

JOSH: It's been two weeks. It's been two really fast weeks.

+ +

LINDSEY: [laughs] Josh, could you give us a little introduction to yourself?

+ +

JOSH: Sure. I'm Josh. Hi. I've been in tech product management for, like, 20-ish years, 15 or so of those were in head-of-product roles. And a bunch of those early on were my own startup, where I discovered I was a pretty mediocre founder but really liked this product leadership thing. I had a very lucky exit, which I leveraged into a series of first product manager, first head of product, first product leader roles at a series of early-stage companies across a ton of domains: B2B, B2C, FinTech, mobile, Revtech.

+ +

And then, a little over a year ago, my partner and I got to do this thing we've been talking about for a while, which was we swapped who the primary parent was. We have two kids, two teens, 13 and 15, right now, so that's eighth grade and ninth grade. I wanted to take over primary parenting so that they could focus as much or as little on their career as they wanted to in the same way they had allowed me to do for the first 15-ish years of our kids being kids.

+ +

And if I were a better person, I would have found some kind of job that allowed for work-life balance, but I'm not. I have a whopping case of ADD, which we'll probably come back to later on in this conversation. And the way that I knew I'd be able to actually fulfill my responsibility as a primary parent was by retiring from salaried work. So, I did that a little over a year ago, last summer. And kind of keep me busy and occupied in between 8:30 in the morning, you know, school drop off and 3:00 o'clock in the afternoon school pickup.

+ +

And when I'm not doing shopping, and cooking, and lunches, and doctor's appointments, and dentist appointments, and orthodontist appointments, and play dates, and soccer practices, and basketball practices, and soccer games, and basketball games, and Bar and Bat Mitzvahs, and all the other things that we do, I built a very small niche coaching mentorship and advisory practice around founders, solo product managers, and first-time heads of product. And that's pretty much up until about two weeks ago what I had been doing with myself.

+ +

LINDSEY: That's a great update. I especially liked all the practices that you have to go to. [crosstalk 02:54]

+ +

JOSH: I do like practices. We went to a co-ed soccer game for my middle school kid. And it was the first time that the boys' team and the girls' team ever played together, and they got totally clobbered by this other team. And what I loved about it at the end was the kids weren't bummed. They were like, "That was really fun."

+ +

And, you know, for a lot of these kids, they've been friends since kindergarten. So, this is, like, nine years of being friends and playing recess soccer together. And they're not very good at soccer, but they just really love all playing together so much. And they just bring so much sportspersonship to the field. It was really a pleasure.

+ +

LINDSEY: Okay. So, you're doing all this fun primary parenting and going to all the fun practices. You've got a coaching business that you're working on as well. But there was this idea, this idea that's needling. What brings you to us?

+ +

JOSH: I think before it was an idea, it was a problem. And I knew this was a Josh problem. And the Josh problem was that I have a really big network, you know, built over the past, you know, more than 20 years of professional life. And, you know, one of the joke lines I have is that the solution to almost any business problem is found in talking to more people. I really value being able to, you know, call people up, message them, text them, email them, get together with them, ask them lots of questions, listen hard. And I try really hard to reciprocate, doing the same thing.

+ +

I don't know what your professional network looks like, Lindsey or Jordyn, over the past, I don't know, couple years, decade, however long it's been, you know. But what used to be email and LinkedIn, maybe, and maybe getting together in some local meetups, has really spiraled what, to me, feels, again, whopping case of ADD, completely out of control, right?

+ +

I have my LinkedIn network, which has not gone away, right? And now I'm a member of, I don't know, Jordyn, we share these a lot, a dozen different professional networking Slacks. Those are the ones that Jordyn and I share, probably far, far more than that, right? Product management ones, entrepreneurship ones, product marketing ones, engineering ones, tech company ones, ones geographically based for the Boston area, ones that are focused on things like climate change and climate tech. So, a ridiculous number of these.

+ +

And as somebody with some experience and the privilege to have some free time, it feels kind of like, I don't know, an obligation sounds too grandiose, but it feels like a nice way that I can give back is by participating and trying to be helpful inside of these. So, that's happened.

+ +

And Discord became a thing, you know, certainly, it had been a thing for gamers since before that. But since the beginning of the pandemic, Discord became a thing. I'm in, like, I don't know, a dozen different similar Discord groups. And I'm in WhatsApp communities, and I'm in Telegram communities. And in-person meetups have started to happen again.

+ +

And I found myself kind of losing control. I was telling people, whether, you know, over the phone, or in Zoom calls, or direct messages, that I'd make connections to them, make intros, and it was getting increasingly hard to do that. I was forgetting about people, you know, like, it's hard to remember to stay in touch with all of your colleagues when you move on from past roles.

+ +

And, you know, I would try to make connections to people to be like, okay, Lindsey, you know, you wanted to meet somebody else in marketing in the Boston area. And I remember that, like, six years ago, they worked at Rocket, and now they've moved on to something else. I can't remember what it's called. And, like, how do you, like, you know, page through your email and your Slack connections and your LinkedIn to find that person? And that was really hard, too.

+ +

So, I have ADD. My family would say that I'm, like, moderately functional. So, how do I achieve that? By creating systems for myself. And I did all the things which other people have tried to do. I built myself, like spreadsheets and Notion databases. I have an awful lot of, like, Notion databases now powered by forms. I'm like, just put your information in, and it'll appear magically into my database where I try to, you know, push the work onto other people. And none of it was really working for me. And that was kind of the genesis of the idea and then trying to figure out, is this a Josh problem, or is this a broader problem? That's kind of how I got started.

+ +

LINDSEY: Lots of people, lots of channels, not a lot of tracking or confusing tracking. And we chatted briefly before, you know, you were starting the program. And this really resonated for me. And I also ended up doing a user interview [chuckles] with the team about it.

+ +

JOSH: Yeah [laughs].

+ +

LINDSEY: Because yeah, in my role, and moving from different companies or doing mentoring on the side, and being in investor communities and marketing communities, it gets overwhelming for sure. And I feel the pain. And I've had the embarrassing moments of not remembering how I know someone or a conversation we had, or someone I really respect asking me for an intro, and I'm like, I don't remember anything about how I know that person.

+ +

JOSH: I mean, that was both gratifying and disappointing. Gratifying, like, oh, it's not just a Josh problem; we all struggle with this, and disappointing, right? And as I've had more of these conversations, just to realize, like, I know almost nobody who doesn't struggle with this. There's a few. There's a few outliers, a few weirdos, a few superheroes who are able to do this really well and who feel in control. And, like, literally, as they describe it, it sounds like...Jordyn, you're nodding, right? It sounds like a superpower as they're describing how they do this, how they kind of manage it.

+ +

JORDYN: [laughs]

+ +

JOSH: But for the most part, thank goodness it's not a Josh problem. The bummer is, nobody has, like, you know, the magic incantation, right? The spell or the secret or, like, the one weird trick, or the tool or, like, could I just give you money and solve this thing? And none of this really exists today. And that was kind of a bummer. I was hoping for, you know, better news that this was a solved problem.

+ +

LINDSEY: [laughs] Yeah. Jordyn, heading over to you for a minute, Josh applied for the incubator with this problem that he was working on. We had a lot of great applications, I think, for this session. What made you think or you and the team land on Josh as one of our session three founders that would be a great fit for the programming?

+ +

JORDYN: I'd say it was probably two factors; one is the stage. What's really tough was figuring out who's a good stage fit for us. So, like, what that means is you've identified a specific enough problem. You're not just, like, I want to solve world hunger or something, like, super broad. There's enough of a specific pain point or a problem that you're trying to solve that there's, like, we might conceivably make progress on it in eight weeks. But you're not so far along that you are basically like, "Hey, I've got the specs for an MVP. Can you just build it?" Which is, like, too late for us.

+ +

And part of that is a discovery mindset of, "Hey, I've identified this pain point. I think other people have it. But I am very open to how we solve the problem or learning new things about it, learning that it is a bigger need in a market I've never thought about," like being open to the things we might learn together. So those things: stage fit, mindset fit.

+ +

But, also, like, it is a problem that is addressable with software, right? thoughtbot's focus is software. Like, yes, we have worked on products that are not software products, but, like, our bread and butter is software. And my personal bread and butter professionally is software. So, is the problem on the table something that, you know, software is a big component in meeting the need?

+ +

So, it's, you know, it's stage. So, I guess it's three things: stage, founder mindset, which is this combination of having conviction but being open-minded, a very weird [laughs] thing to find in a person. And then, you know, can we conceive of a way to address this with software without jumping to a solutionizing? That's sort of what we're looking for, and Josh checked all of those boxes.

+ +

And I think, also, just had a problem that people really resonated [laughs] with, which is clear from [laughs] what Lindsey was saying and for me personally as well, I think I should [laughter] say. This is a problem I have. So, when Josh and I first talked about it, I was just like, yes, I would love to solve this problem. I also wish there was some spell, or incantation, or weird trick, or existing products, et cetera.

+ +

JOSH: We might have spent an hour nerding out over all of the things that we've tried, yeah.

+ +

JORDYN: The things that we've tried, emphasis on the nerding.

+ +

JOSH: On the nerding part, yeah.

+ +

JORDYN: Any of you listening [crosstalk 10:45]

+ +

JOSH: Or what if we get sneakier connect Google Sheets to this, like, really weird web query and [laughs] --

+ +

JORDYN: [laughs] Exactly. And then giving up because it's totally unmaintainable or, like, [laughter] impossible, yeah. So...

+ +

JOSH: Right. Oh, and it's all crap, too [laughs].

+ +

JORDYN: Right, right. So, if anyone out there listening is like, "Oh yeah, that's me," first of all, you're not alone. Second of all, please reach out to us. We would like to interview you [crosstalk 11:09]

+ +

JOSH: Or, if anyone out there is like, "Oh, I have this thing solved," right? If you got the solution, please reach out to us.

+ +

JORDYN: [laughs] Yes, also, please.

+ +

JOSH: You can save us six more weeks of work [laughs].

+ +

JORDYN: If you know the solution, definitely tell us. Anyway, so to your question, though, Lindsey, that's how this [inaudible 11:23], and it just seemed like a great fit along those lines.

+ +

LINDSEY: Yeah. So but, Josh, you mentioned...well, I think you kind of downplayed your founder history a little bit. But you've been a founder who had success, certainly a product team leader who has been very successful in the early-stage teams. What were you looking for from thoughtbot? Like, what attracted you to working with the thoughtbot team on your problem when you have all this kind of past experience already?

+ +

JOSH: I think there's probably three parts to it; one is I know a bunch of people in the thoughtbot team pretty well. In past roles, I have actually hired thoughtbot; I think it was twice. And I've referred a bunch of your current and past clients as well. Like, I'm just generally a big thoughtbot fan. I think I've even used thoughtbot products long before I even knew, like, Chad or Jordyn, some of your old products from, like, you know, the early 2000s. So, we're going really OG here. So, I knew thoughtbot really well and think really highly of everybody who I've interacted with there.

+ +

Number two is, I know, you say incubator, but, for me, the word that's really been resonating has been accelerator. It can be really slow the early, I don't know, weeks, months, years to go from an idea to, hey, this is really an opportunity. And I didn't want to spend weeks or years at this. I have a full-time job. It's, you know, taking care of the family. Like, that's what I wanted to be focused on. And if this was really an opportunity, I wanted to figure this out relatively quickly. And I love the fact that thoughtbot has this eight-week accelerating program.

+ +

And the third one is I had this...and, you know, not every assumption I came in with was one that I'm going to leave the program with. But I came in with the assumption that a lot of the risk was technology risk. I had a rough idea. I was quickly discovering this wasn't just a Josh problem; this was a broader problem, right? There's plenty of challenges beyond that, but it's good to discover that your problem is broad. But is it something which can actually get built and built relatively straightforward?

+ +

Jordyn here [inaudible 13:27] this all the time. You know, I don't like science project problems, right? And thoughtbot is really, really good at building software and partnering with somebody who could help to remove that kind of risk as a non-technical founder, as somebody with literally zero technical skills, I find that very, I don't know, comforting, exciting.

+ +

LINDSEY: Okay, writes down in marketing notebook: "Accelerator resonating more than incubator." [laughs]

+ +

JOSH: I wanted to get to the decision...incubator is a better word for it. But I personally wanted to get to that is this a good opportunity or a bad opportunity decision faster.

+ +

LINDSEY: To quickly validate invalidate.

+ +

JOSH: Right. I wanted this, like, I wanted to timebox this thing, and eight weeks is a nice chunk of time.

+ +

LINDSEY: Love that, yeah.

+ +

JORDYN: I want to just, like, flag here that, like, all of these words are very frustrating [laughter]. And we had a really hard time picking one.

+ +

LINDSEY: I know [laughs].

+ +

JORDYN: And we really actually, like, in literal terms, I think that program is way more, like, founder bootcamp than anything, but thoughtbot can't run a bootcamp without people thinking it's a Rails bootcamp, right?

+ +

JOSH: Yeah.

+ +

LINDSEY: [laughs]

+ +

JORDYN: Like, if we just said, "thoughtbot bootcamp," people would be like, oh, as a developer, I should go to this bootcamp, and thoughtbot will teach me how to be a better engineer, which would be totally reasonable from a brand standpoint, right? So, we were like, all right, not bootcamp.

+ +

And then accelerator typically comes with investment dollars, in my experience as a founder, and we don't invest cash in the companies that we work with yet. So, that was off the list. And that just left incubator, which, eh, like, I don't disagree that it's not the best word, but, whatever, we lack a good one.

+ +

JOSH: I'll tell you one thing. So, I'm involved with other things in this space. I'm based in Boston but for Raleigh's brand-new Founder Institute chapter, which I think is a great program. And I'm really proud of the, you know, first cohort of founders that are going to the program down there. And I love them. And I love their energy, and enthusiasm, and focus and that we at Founder Institute are providing them with value. I think we really are, or I wouldn't be participating.

+ +

But I wanted people to work alongside me. And I think that's actually one of the things which is really unique about thoughtbot's program. This isn't, like, you know, a bunch of other founders with varying amounts of experience working alongside you. This is, like, actual people who do things: designers and software engineers, developers who are working alongside you and learning alongside you. But it makes it, I would say, less of a lonely process.

+ +

This is one of the things I remember. When I founded a company, the one time I did this prior, I did it with my best friend, which is about as unlonely as you can possibly get. And it still is really, really lonely. Having this like, you know, team backing you up and a company backing up that team and organization is nice.

+ +

LINDSEY: Thanks for sharing that about the loneliness factor. That kind of reminds me, Jordyn; I know in the last session, you were trying out the idea of, like, this founder emotion tracker. Has that made its way to session 3?

+ +

JORDYN: Not really, mostly because both of the teams we're working with, two teams, by the way, not just Josh, have been founders before. And so, the emotional rollercoaster of, like, literally every day, you know, Monday, you feel like a million bucks because you have a really great idea, and you're really excited about it. And then, Tuesday, you talk to a bunch of people who add some complexity to the assumptions that you had [laughs] made on Monday. And then you start to feel like maybe this isn't a thing, oh no.

+ +

And then, Wednesday, you learn about some, like, technical thing that you didn't realize was a stumbling block. And so, by the end of Wednesday, you're like, everything is doomed. I shouldn't even be doing this. I've just wasted everyone's time. But then the team wakes up on Thursday and is like, "Actually, there's an easy solution to this. And we've found a new group of people to talk to who have this problem in a really clear way." And then you feel like a million bucks again. And then you just cycle through it.

+ +

Like, that cycle is something that Josh and our other founding team have actually felt before. And so, we haven't really been, like, leaning on the emotional roller coaster timeline as much just because it hasn't been as relevant. And that's kind of what's tough about the program we're running, which is that everybody comes to it with different assets in hand. I always think of that scene in The Princess Bride when they're outside the castle, and Westley is like, "What do we have? What are our assets?"

+ +

It's like you arrive to this with different assets in hand. You might have already talked to 50 people, but you have no technical background. So, you don't know what on earth to do about the information that you've learned. Or, you know, maybe you do have a technical background. And so, you've done a bunch of solutionizing, but you haven't talked to a single person about [laughs] whether they have the problem you're trying to solve. Anyway, it really runs the gamut.

+ +

And so, the programming is designed to help teams find focus and find market message fit. But what people roll up with is very different. In this case, we have a cohort, so to speak, that has some prior startup experience, especially as founders. And so, they know a little bit more about how every day is going to emotionally feel different. And that emotional rollercoaster workstream is on the roadmap. But we don't spend as much time with it as we did with Ashley and with Agnes before in the first two sessions because they were first-time founders and really didn't know how they should be feeling.

+ +

And that, to me, is one of the many value adds, including what Josh mentioned, like just having a team diligently focused on your problem space full-time is a huge boost of momentum and confidence. Just, like, people thinking about the same thing you're thinking about with you and bringing their earnest efforts to solving the problem has been one of the main things people have found valuable about it, in addition to the acknowledgement that, like, you're going to have a lot of different emotions. And it doesn't mean anything necessarily.

+ +

Like, your day-to-day emotion does not mean that you are a failure or that this is a bad idea or that you're a success, and this is a good idea [laughs]. Like, neither of those things is necessarily true.

+ +

LINDSEY: So, let's chat a little bit about what has actually been happening since kickoff. So, two weeks ago, started. Jordyn, maybe I'll start with you. What has the first two weeks of programming looked like?

+ +

JORDYN: We have been really heads down on interviewing. Josh rolled up having done a survey, which yielded a bunch of conversations already, conversations [inaudible 19:34]. So, we iterated on the scripts. You know, part of the efforts of the first couple of weeks are really geared toward having our team understand the things that Josh understands already. We need to kind of get on the same page.

+ +

And so, we try to talk to as many people as we can because there's nothing...One of our theses here, beliefs, I don't know what the right word is, is that there's really nothing that drives momentum quite like team alignment, and there's nothing quite like talking to customers and hearing for yourself what their pain points are. That drives alignment. So, it's like, everyone's talking to people. I'm sure people out there have been on teams where it's like one person talks to customers, and they're translating to everybody else. "Here's what I'm hearing. So, this is what we need to build."

+ +

And it's like if everybody has first-hand experience with the conversations, alignment and conviction sort of grows organically out of it. It's a lot less work to align if everybody's talking to people. So, it's always, like, the first order of business is, how do we talk to people so that we know the things you know to the level that you know them? So, we've been doing a ton of interviewing. And then, that's about driving alignment and understanding, but it's also ultimately about trying to drive focus.

+ +

So, as we are talking to people and listening to them, we're really trying to listen for patterns and to map those to the market segments these people inhabit. So, like, every one of us has our own network that we're bringing to this effort, and so we start there. And we start where you are with what you have, right? I think that's, like, a Teddy Roosevelt quote: start where you are with what you have. Somebody said that. Anyway, so we all do that.

+ +

But really, ultimately, we want to...building software is all about a repeatable problem that you can address with a one-size-fits-all [laughs] more or less product. What we're trying to find is, like, we're trying to listen for patterns and listen for pain points that are addressable and really focus in on a narrow niche or a situation context that we can address in some repeatable way. And I would say, at this moment, we've done a bunch of that interviewing. And we're now like, okay, we're feeling the need to focus, but we have not quite started that dive. I don't know, Josh, maybe you feel the same or different.

+ +

JOSH: No, I think that's right on. I mean, you know, the first thing we all had to do was develop our own [inaudible 21:45] understanding of the problem and the potential user, right? It wasn't going to happen from me talking to people. It was going to happen from us talking to people. And then, the next step is to start to align that empathic understanding, which sounds like a thing that gets finished, but really, it's only a thing that gets started and never really ends.

+ +

And then, you know, we got to be willing to make some bets, right? We got to figure out, you know, what is our hypothesis? You know, what do we think are the risky bits? And what are the things that differentiate this from being a problem? Where I think we have broad agreement across the entire team. And, literally, everybody we spoke to, the only people who don't think this is a problem are the ones who have some complicated, ridiculous system they built themselves, which they will acknowledge is not going to apply to anybody else. So, the problem is broad, right? But where exactly is the opportunity? Because at the end of the day, we're looking to build a business.

+ +

LINDSEY: Josh, I saw your head nodding during the alignment discussion. How has it been aligning with the team around the problem you've been thinking so much about?

+ +

JOSH: I don't know, Jordyn, how you feel about it. I've found it really fun. And it's been fun for a couple of reasons. I think the number one reason that I really like it is this is a really diverse team, right? So, Jordyn and I are in Boston and have; I would say, fairly similar tech company entrepreneurish sort of, you know, hand-wavy, miscellaneous tech people, startup folks background. We have somebody in Denmark, but she's Spanish. We have someone in maybe London right now, but he's Nigerian. And we have a member of our team in Saudi Arabia. That's a lot broader perspective.

+ +

And I think that comes to play in, like, at least three different ways. They come with their own perspectives, and their own world experiences, and lived experiences, and values, and ways they talk about those things, right? Number one. They come with their own networks of people to talk to you for whom it's easy to reach. So, it's not just all hand-wavy, tech startupy folks like I'd be talking to. And, like, literally, my entire list is, like, oh, they're all people like me. Like it was really easy to get 60 people to want to talk to me because they're all people I've been talking to for a while, which is awesome and maybe a little bit uninteresting.

+ +

But more than that, they all bring different language. Like, we've been struggling. Like, this is what we did. We spent what? Two hours of our hour and a half meeting this morning struggling with, like, are we having a difference, like, meaning or a difference of words? And it's not an efficient way to use your time, but it really is an effective way to use your time. Because, like, that struggle of trying to communicate what we're hearing and try to communicate what we're thinking and what we're feeling, I think, has led to a much better understanding of the problem and maybe even the opportunity than we would have had otherwise. I'm a big fan of struggle.

+ +

JORDYN: Definitely. And I do feel like there's an element of this where you can never understand your customers' problems in too much detail. It's like every pass we do at this, we kind of have a deeper, more granular, nuanced sense of the problems. And just in that conversation this morning, we, like, took a problem that we had understood one way and, like, were able to break it down, like, okay, what are the actual pieces of this? Oh, there's, like, many pieces of it, right? Like you said, Josh, it feels inefficient, or sometimes it just feels like you walk out of a call and you're like, what was that about?

+ +

And then only later do you find, you know, maybe when we are ideating, like, ways we might solve a problem, that conversation we had that felt really murky and, like, are we just arguing about semantics here? Are we arguing [laughs]...I don't know, like, however, you might frame that, like, actually becomes really important where you're like, oh, well, I'm very glad we took the time to break this problem down because now that we're trying to develop a solution, it becomes clear that there are many, little things we're trying to solve. And we can't solve them all at once. And so, it's great that we all have a fluent understanding of the details of that because it makes those conversations much faster so [inaudible 25:30].

+ +

JOSH: Can I say a nice thing about thoughtbot? I know this isn't, like, the, you know, [crosstalk 25:34]

+ +

LINDSEY: Please. Please do. Welcome, Josh. Yeah, the floor is yours.

+ +

JOSH: Let me say a nice thing about thoughtbot. The last time I did this, I did this with my best friend, Ben, a person I had literally known since I was six years old, maybe five, I don't know, since first grade. And we were entering a new space. This was, like, grocery marketing.

+ +

And we talked to a crap ton of people, a lot of them doing things like going to grocery store headquarters and just talking to people and meeting people who are, like, manufacturers of a grocery product and going to trade shows with 60,000 grocers all in one giant room. Remember those days pre-COVID? We would, like, you know, take the samples with your left hand and shake with your right hand, and don't get those two things mixed up because there's a lot of people in the room with you.

+ +

And we talked to easily 1,000 people, and we knew how to establish that, like, shared empathic understanding of the market and the problem really well because we were side by side. We were really well-practiced at having those conversations. And, you know, after the day of, you know, shaking hands, and meeting people, and introducing ourselves was done, we'd go back to the hotel room, shared, of course, because we were young entrepreneurs who couldn't afford to get nice hotel rooms. And we'd spend the next couple of hours, like, talking about it. We, like, talked to each other all the time.

+ +

One nice thing about thoughtbot is you're really good at working remotely and working asynchronously. And if, you know, it had been up to me by myself to be like, okay, you know, Josh, you have this, like, remote team in different time zones with, you know, non-overlapping hours. How are you going to, like, work together to establish this common understanding, this common semantic model, this common syntax for talking about the problem, and the users, and the needs, and the opportunity? I'd be like, I don't know, right?

+ +

And this is somebody who's, like, worked remotely for the past, I don't know, 5,6, 7 years, I mean, most of his job. But, like, still, that early bit is a thing, which, you know, I've seen a lot of thoughtbot practice and skill around. And it's not an easy skill to master. And it's one that you practiced organizationally. And that's really valuable. And I don't think I fully appreciated that until we got started.

+ +

LINDSEY: Oh, thanks. Jordyn, any thoughts on that? Were you thinking about remote setup of the program, or at this point, it's just everything is remote?

+ +

JORDYN: Working remotely can really deepen, in good ways, one's communication practices because it forces you to be intentional about communicating in a way that when you are co-located with people, you kind of don't have to because there's people in front of you when you talk to them. So, I agree, Josh, that thoughtbot does a good job of making that work, the work to communicate and stay on the same page, like, tangible, visible, whatever it is.

+ +

That's also just something I've given a ton of thought to because I've been working remotely, like, as a primary orientation since 2010. And so, this is just, like, how I work. And it's very; I don't know, organic to my mind now that it's basically, like, if I'm doing something and I don't tell someone about it, it's like a tree falls in the forest, you know, if there's no one around to hear it. If I'm working on something and I don't tell anyone about it, it's like I didn't do anything.

+ +

Communication is, like, 60% of the job. And the setpoint is, oh, I did something. Oh, I emailed someone. Maybe I should tell the team about this [laughs]. Just literally because you're not in a situation where I'm going to overhear a phone call that Josh is having because he's at the desk next to mine, or I'm going to, like, ambiently be aware that, like, Carol and Toby went into a conference room to talk about something. Like, while I maybe didn't consciously think about that, it's sort of in my periphery. Like, none of that is happening because we're not in the office together, right?

+ +

We don't get to do the thing that you did with Ben, where we just talk about stuff because we're near each other. So, you really have to get into this practice of externalizing very proactively the things going on in your own mind with the team. And it's a challenge. It's work. It doesn't just happen effortlessly, right?

+ +

But yeah, to say it's critical or to say it's a critical piece of how we approach the work is an understatement. I don't know, it's like, it is the work [laughs]. The making of the software, whatever, that's easy [laughs]. Communicating about making software that's hard [laughs]. So, I don't know, it's very heartening --

+ +

LINDSEY: Yeah, that makes sense.

+ +

JORDYN: To hear, Josh, that you think that we do a good job of that. I think we're constantly trying to do a better job of it, frankly. I don't know if you can do [crosstalk 29:28]

+ +

JOSH: That's probably why you do a good job.

+ +

LINDSEY: So, I know a lot of the early weeks, days has been around alignment and doing a lot of these user interviews. Have there been any moments yet, Josh, any new, like, light bulbs for you or insights, or are we not quite there yet; it's more kind of setting the scene?

+ +

JOSH: I'll share one really embarrassing one.

+ +

LINDSEY: Oooh.

+ +

JOSH: Which keeps on coming back to bite me. When I sent out the survey and, of course, I [inaudible 29:57] for everybody listening, basically, surveys are useless, except they're really nice lead generation tools for people who are willing to talk to you. But when we sent out the survey, at the top, it says something like, "Personal CRM survey." And I'm pretty sure that when I set up the calendar invite system, which is, by the way, for folks listening out there, like, you want to get your, like, operational side of this thing done before you start sending emails out because you're going to quickly, like, lose the ability to keep track of stuff.

+ +

I think the meeting of it also, I said something like personal CRM survey. And it was, I don't know, sometime in the middle of the first week, maybe later on, when, like, I think we all realized on the team that, like, CRM is the wrong framing for this thing, right? Nobody likes CRMS [laughs]. CRMs are transactional. They're tools to sell something to somebody. You know, they are tools for, like, auditing your behavior if you're a salesperson to make sure you're doing what you're supposed to be doing. They're, like, on a cadence. Like, CRMs are tools for a world, which is not what most people aspire for their personal relationships to be.

+ +

And I don't think we've quite settled on what this thing actually is. And maybe there isn't a thing yet, right? Maybe that's part of the challenge that we're having, like, this thing doesn't exist, but it's not a CRM. And three-quarters of the way through the interviews is when I asked people like, "So, what question should I have asked you?" They all said, "Well, you didn't ask me about personal CRMs at all." I'm like, "Okay, that's a good point [laughs]."

+ +

So, there have been plenty of pivots inside of my head around this and the way that I think about this problem, and some of these things are still embarrassing and still kind of coming back to haunt me and maybe haunt the rest of the team as well. I don't know, Jordyn, what [crosstalk 31:27]

+ +

LINDSEY: Honestly, I was hoping for something way more embarrassing, but [laughs] --

+ +

JOSH: Way more embarrassing.

+ +

JORDYN: If that's your embarrassing...[laughs]

+ +

LINDSEY: Yeah, you're doing great. You're doing great.

+ +

JORDYN: You're doing great.

+ +

JOSH: Okay, the number of video calls where I'm not wearing pants.

+ +

[laughter]

+ +

LINDSEY: Okay, onto the next question, Jordyn –-

+ +

JOSH: Embarrassing or awkward, I don't know, yeah.

+ +

[laughter]

+ +

LINDSEY: Jordyn, you mentioned that Josh is not the only participant in this [crosstalk 31:52]

+ +

JORDYN: Great question.

+ +

LINDSEY: Tell me about, why not just Josh? What's going on? What are the developments there?

+ +

JORDYN: Yeah, this is really exciting. So, we wanted to scale this program from the moment that we ran single companies [inaudible 32:08] to start because we wanted to learn as much as we could in a kind of intense, focused way from developing a process and seeing what's valuable about it. So, this was always kind of on our minds to do.

+ +

And the way it worked out was just that there were two teams at thoughtbot ready and willing to serve. And we had, you know, anytime we [inaudible 32:28] the application window, we always kind of have a list of folks that we're excited about. We can't take all of them. But in this case, we had the two teams. And it also kind of fell in this nice way where we've got this team with a center of gravity, you know, GMT center of gravity, essentially. And then we have another team, which has more of a, like, U.S. center of gravity. And so, the timing kind of worked out.

+ +

And yeah, I don't know, it wasn't anything more complex than that. It's just we'd always been on the lookout for how we could scale this effort––bring it to more folks. And this was the first opportunity where it appeared like it would work out. I mean, TBD if it's working out [laughs]. We can decide at the end [laughs]. But it's very exciting. It's fun. And we're really looking for ways to help these teams collaborate, you know, we'll see how.

+ +

Everybody's in a Slack channel together inside of thoughtbot's Slack called thoughbot incubator. And our past participants are in there as well. And we're really trying to create an atmosphere where people can help each other, share tips, talk about what they're working on. There is actually some intersection between what Josh is working on and what the other team is working on, I think, just because, Josh, what you're working on applies [laughs] to a lot of people. I think it applies to these people, too. Anyway, that's [crosstalk 33:42]

+ +

LINDSEY: It's fun to see the incubator Slack start to build out and folks talking to each other, and more thoughtboters are trickling in there. Because, Josh, you mentioned you've been a client before and a thoughtbot fan in the past. And now you can officially live in thoughtbot Slack, too, and hang out with us 24/7.

+ +

JOSH: Still just a guest.

+ +

LINDSEY: [laughs]

+ +

JOSH: Only got my two channels. Can't DM you unless you're in one of those two channels.

+ +

LINDSEY: One [crosstalk 34:11]

+ +

JOSH: But yes, it is very exciting. This is better than snacks at your downtown Boston office.

+ +

LINDSEY: Yeah, that's great.

+ +

JOSH: I think I even added an emoji to Slack. I was pretty happy with that.

+ +

LINDSEY: Oh, nice. We've got a good custom emoji library.

+ +

JOSH: I mean, that's what we have for company culture, right? Is company emojis.

+ +

LINDSEY: To kind of finish this out here, Josh or Jordyn, do you have any calls to action for our viewers or listeners, maybe interviews or survey participants or anything else?

+ +

JORDYN: Well, certainly, if the pain point we described resonates for you [laughs], reach out. We would love to interview you. Or, like Josh said, if you actually have solved this problem [laughs] --

+ +

LINDSEY: Oh yeah, that was a good one.

+ +

JORDYN: Please reach out [laughs]. That would be amazing.

+ +

JOSH: But I actually meant that. So, like, hey, if you out there are a software developer, an entrepreneur, own a company that you think has really solved this, I would love to learn from that if you want to talk to us.

+ +

If you are a person who struggles with this and feels like you've tried really hard to solve this, I'd love to hear from you as well. You know, did you search for a tool? Did you ask your friends? Did you try to build something yourself? Do you still use that thing you built yourself? Did you try one of those CRMs? [crosstalk 35:26] Did you try a personal CRM tool out there, right? Clay, Dex, Monica, folk, if those names resonate with you, like, I want to hear, right? I want to hear about people who feel like they're doing this thing really well or people who don't feel like they're doing as well as they should but who feel like they've put, like, real effort into it.

+ +

LINDSEY: Great. Well, we're going to be catching up with Josh here every other week.

+ +

JOSH: Great.

+ +

LINDSEY: We'll have some updates on the thoughtbot blog. And in our alternating week, we're going to be catching up with the other founders going through the incubator. So, next week, we're going to chat with Mike and Chris. And y'all will get to meet them and hear a little bit about their journey and what's led them to validating their idea in the thoughtbot incubator as well.

+ +

JOSH: And strong rec people to tune in for that one. They are extremely photogenic and very funny, and they talk slower than me, too, so a greater chance for people to understand what they're saying. So, all in all, definitely tune in for that.

+ +

LINDSEY: That's a great promo.

+ +

If you want to stay up to date with the incubator or are thinking about applying for the next session, I think will be in the new year, you can go to thoughtbot.com/incubator. And you can also sign up for email updates. And we can make sure to send you recordings of these interviews as well as the blog updates and then keep you up to date about when applications open and end.

+ +

Jordyn and Josh, thank you so much for joining today and sharing what's been going on in the early days. It's really exciting to follow along. All right, have a great day. Thanks, everyone, for watching.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Jordyn Bonds and Josh Herzig-Marx .

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8yz6LA3D + + ]]> + + Lindsey Christensen + Jordyn Bonds + Josh Herzig-Marx + + + 498: RubyConf San Diego with Chelsea Kaufman and Allison McMillan + https://podcast.thoughtbot.com/498 + e326142a-87d0-4279-9cbd-2c131506a313 + Thu, 02 Nov 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + In this episode, the focus is on RubyConf, the upcoming conference dedicated to the Ruby programming language. They start by talking about the origin and evolution of RubyConf, highlighting its growth in attendance and its impact on the Ruby community. Chelsea details how the conference has adapted to the digital format due to the COVID-19 pandemic but points out the value of in-person connections. They are looking forward to the Community Day event, which will feature various activities to encourage community interaction and an acknowledgment of scholarships that would help more people attend. + +The event will offer various programming options, workshops, and talks to cater to newcomers and seasoned professionals. There will also be some level of hands-on learning through hacking activities. The conference aims to be inclusive, offering opportunities for mentorship and growth, regardless of one's career stage. + +Towards the end, the discussion shifts to Ruby Central, the organizing body behind RubyConf and RailsConf. Chelsea and Allison describe multiple avenues for community engagement, ranging from board membership to open-source contributions. They also encourage donations and corporate sponsorships. Don't miss your chance to register for RubyConf and engage with the fantastic Ruby community! + 35:07 + no + + + In this episode, the focus is on RubyConf, the upcoming conference dedicated to the Ruby programming language. They start by talking about the origin and evolution of RubyConf, highlighting its growth in attendance and its impact on the Ruby community. Chelsea details how the conference has adapted to the digital format due to the COVID-19 pandemic but points out the value of in-person connections. They are looking forward to the Community Day event, which will feature various activities to encourage community interaction and an acknowledgment of scholarships that would help more people attend. +The event will offer various programming options, workshops, and talks to cater to newcomers and seasoned professionals. There will also be some level of hands-on learning through hacking activities. The conference aims to be inclusive, offering opportunities for mentorship and growth, regardless of one's career stage. +Towards the end, the discussion shifts to Ruby Central, the organizing body behind RubyConf and RailsConf. Chelsea and Allison describe multiple avenues for community engagement, ranging from board membership to open-source contributions. They also encourage donations and corporate sponsorships. Don't miss your chance to register for RubyConf and engage with the fantastic Ruby community! +RubyConf (https://rubyconf.org/) +Follow RubyConf on LinkedIn (https://www.linkedin.com/company/ruby-central-inc/), X (https://twitter.com/rubyconf), YouTube (), or Mastodon (https://ruby.social/@rubyconf). +Learn Academy (https://learnacademy.org/) +Follow Learn Academy on Facebook (https://www.facebook.com/LEARNSD/), X (https://twitter.com/SDLEARN), LinkedIn (https://www.linkedin.com/school/sd-learn/), or Instagram (https://www.instagram.com/sdlearn/). +Follow Chelsea Kaufman on LinkedIn (https://www.linkedin.com/in/chelskaufman/) or X (https://twitter.com/ChelsKaufman). +Follow Allison McMillan on LinkedIn (https://www.linkedin.com/in/apmcmillan/) or X (https://twitter.com/allie_p). Visit her website at daydreamsinruby.com (https://daydreamsinruby.com/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Allison McMillan and Chelsea Kaufman, Board Directors, and RubyConf '23 Co-chairs. Thank you for joining me. +ALLISON: Hi, thanks for having us. +CHELSEA: Thanks for having us. +VICTORIA: Yes, I'm glad that you were able to make time to come on the show today. I understand, Allison, that you've been having very full weeks with family over the last month. Do you want to tell us a little bit more about that? +ALLISON: Yeah, it's...we have just ended what I call the gauntlet of Jewish holidays. But, basically, there are four Jewish holidays starting with Rosh Hashanah, which many folks know that's the Jewish New Year. But what a lot of folks don't know is that there are actually four holidays that are all in a row, each about a week apart. And you do different celebratory things for each of them. +And so, it's been really amazing and fun, and lots of, like, sharing our home with others and meals and seeing lots of people. But it is also exhausting. And they basically all fell on weekends this year, which was nice from sort of a scheduling perspective but was exhausting in the fact that I basically have not had a weekend in over a month. So, it was wonderful and tiring. And I am, I guess, both happy and sad that they're over now. +VICTORIA: Yeah, that does sound like a lot of quality family time, which has its pros and cons [laughs], right? So, after going through that, do you feel more rested? Or what do you feel like you need to do in order to recuperate and return to your normal energy levels after having every weekend full after that? +ALLISON: Oh, that's a great question. I've been looking at my calendar to be like, I should take a day off. I should take a break. I'm working for myself and [inaudible 02:02] entrepreneur consultant. So, I do have the flexibility to do so, but it is hard to look at my calendar and be like, yes, I will take this day off because I deserve it. But, ideally, I would take a day or multiple days off. +VICTORIA: Yes. And some of us are lucky enough to have a reason to travel for work purposes and to sneak in a little vacation and be productive [laughs] in our companies. So, I'm curious, Chelsea, if you can tell me a little bit about the option for people to come to San Diego in November and take a restful vacation by the beach and learn a little bit more about Ruby. +CHELSEA: Yeah, so RubyConf will be in San Diego this year. As a native San-dieagan, I am a bit biased, but November is a beautiful time to be in San Diego. And we're going to be at the Town and Country, which feels a little bit like we're going to be in a, like, Palm Springs resort. They just went through a major renovation. +And there's these really awesome, like, lounge areas with fire pits and just places for people to gather, which really kind of aligns itself with some of the stuff that we're planning because we're really trying to focus in on just connecting Rubyists together. So, to me, it feels like the perfect place because I think San Diego is, one, we're a little bit more low key, a little chill. And it's a great place to just gather and connect and share with people that have, you know, similar interests. +VICTORIA: Yes, I live in San Diego now, but I was from Washington, D.C., And I would come and visit my family in San Diego once a year. And they would always go on about how great it is and how beautiful, and everyone is so happy and chill. And I was like, sure, whatever. And then we [chuckles] had the opportunity to move here, and now I'm one of those people who says that [laughs]. Like, it's great, especially in November. Everywhere else is getting a little cold and fall. And San Diego has a little bit of fall, but it's still 75 degrees out. I forget what that is in Celsius. But yes, I'm also super excited. +CHELSEA: We have, like, fake fall activities that you can go do. Like, Allison, when you're talking about doing all the family activities and things like that, you know, this is when we start thinking about, oh, we need to go to, like, the pumpkin patch and apple picking and do all these things, but it's not cold or, like, fall weather at all. So, you want to get all, like, bundled up in your cute fall clothes or, like, put my kids and bundle them up in cute things. But then they're, like, sweating and trying to do [laughs] all these funny activities. +But I think that there's so many beautiful things to do here that we, like, try and do these, like, fall activities. But then we just end up at the beach and play in the sand [laughs]. +VICTORIA: Yeah, I will go out in, like, shorts and a T-shirt because it's that kind of weather. And my neighbors will be wearing full puffy jackets and [laughs], like, long pants and a hat. And they're like, "You're not from around here, are you?" [laughs]. It's like, you guys are silly. But it's fun. Yeah, there's seasons, I think, you know, in November...I made a list of suggested activities for my team members since thoughtbot is sponsoring RubyConf this year. And we're going to have a couple of speakers at the event. And we'll have other thoughtboters available at our booth for people to come up and chat with us. So, I'm really thrilled to be hosting everyone. +And I made a list of, like, activities, and most of them were about where to see cool animals [laughs]. I was like, of course, there's the zoo, which is the obvious one, but then there's baby leopard sharks, and there's a season for them. I think they will still be around in November; I'm curious if you know, Chelsea, actually. And then there's, like, the safari parks, and whale watching, and the sea lions at La Jolla and, like, just a bunch of cool animals to see that I think it makes San Diego really special. +CHELSEA: I agree. The zoo, the safari park are great places to just hang out and see some really cool exhibits. Balboa Park, the museums there are amazing. Liberty Station is one of my favorite places to go; that it's an old historic naval training center that's been converted into an arts and culture area. So, they have, like, little shops. They have...there's museums. There's brew pubs. There's coffee shops. And then there's beautiful, like, grassy areas, and right by the water, it's one of my favorite places to just go and hang out. +ALLISON: This is great. I've done zero research on San Diego so far. So, just, like, I'm writing notes of what things to do and see while I'm there. +CHELSEA: Yeah, I know the San Diego Ruby group is trying to put together some, like, local events and things that people can gather and do together. I know that there was a talk about doing a taco crawl. I think if I say that on the podcast, it might actually push them to do it because there are some amazing tacos in San Diego to be had. +VICTORIA: Yes, I love that taco crawl. I'll reach out to them because I'll help put something like that together. I'm writing a blog post right now about all of these things and about all the other kind of events that are coming up in San Diego this fall. Great location, great time of year to be here. Tell me a little bit more about RubyConf specifically. And what are you all trying to do different this year than in past events? +ALLISON: There are a bunch of things that we're doing differently. Our goal this year with this RubyConf is really to sort of focus on more ways to bring the community together. I think in the last little bit so much excitement around Ruby and Ruby Central and just sort of the community in general. It's a hard time in tech. I think people need to be sort of choosier about sort of what they attend and why they're attending something. And so, we really wanted to help folks connect with each other, help folks get to know other people, help folks sort of reconnect to ways that they love Ruby and the Ruby community and being a Ruby programmer. +So, one of the things that we're doing differently is we have a three-day conference. And the way that that sort of broken down is the first day is a Community Day. And the first day is comprised of the workshops, as well as sort of this Hack Day, where people can bring their own projects. +We're going to have people there that folks can hack with, sort of open-source projects that folks can work on, all sorts of different stuff. So that people can really sort of get to know one another, work with one another, work with people that they might, you know, admire or have followed in the community for a while, and have that sort of really special experience that doesn't feel as conference-y, right? It feels a little bit more sort of organic in terms of the way that the day will flow and, the options that people have, and sort of what that day looks like. +And then following that, we have two days of sort of RubConf with talks and speakers, et cetera. And I'll let Chelsea add anything to Community Day and then also jump into some of the sort of new and different things we're doing at RubyConf. +CHELSEA: I agree with Allison in that we've really wanted to focus in on the connection side of things. But I think coming out of the last few years, out of even the last year that's been tough in the industry, just finding ways for people to connect, support, lift up each other, I think that that was something we really wanted to do. And we didn't want it to just be about going and seeing speakers. We wanted to find more ways for people to learn from each other, to connect. And so we added in quite a few of these community connection points. +So, on that first day, there's a lot of community aspects to it. We have a lot of learning happening with our workshops and also working on projects, hacking together, showing off what you're working on, connecting with people in the community. It's going to be really focused in on everyone's own skills and talents and coming together and supporting each other in where we're at in our careers, in our learning. +And then, the next couple of days will look a little bit familiar in the way that it is structured with some new aspects kind of woven in. We'll have our Community Room, where we're bringing different community groups together so that people can learn more about what is going on in the community, how they can support, how they can connect. +And in addition to seeing and learning about some of the new things happening in the Ruby community, we'll also have our Career Pathways room again, which will be a place for people to support their own careers. And that room was really set up so that it wasn't just about early career, but also about folks in their mid and senior careers, and finding the advice, finding the resources, finding the mentorship that they might need in whatever stage of their career that they're at, and figuring out how we can together as a community grow as a whole. +VICTORIA: I really appreciate the focus on community. And, for me, as managing director at thoughtbot, in deciding to invest in which conferences we want to attend and sponsor, we find more value in groups that are trying to bring people together around a common passion and purpose versus a particular product. +But I'd like to hear from each of you if you can tell me, what does the community mean to you? And I'm looking for, like, a personal story on how you've benefited or how you've engaged with the Ruby community in the past. And what makes you motivated as CEOs and founders of your own companies [laughs] to spend all this time organizing a conference? +ALLISON: Many, many, many years ago, I did a Rails Girls workshop. It was actually my first introduction into the tech community, into programming in general. And, for me, really, I did Rails Girls. I did not actually expect to like programming. But I was sort of launching a startup, and I wanted to learn more about tech and blah, blah, blah. And at the end of the day, I was, like, so energized and so excited about what I had built and what I had done. +The Ruby community in D.C., who I always think is just a group of really special individuals, was so supportive, was so wonderful, was so, like, "Here's where we co-work on Wednesdays. Come to this coffee shop. Here's how you can keep learning," just was so encouraging. You know, I went to the local Ruby meetup sort of really not knowing anything. And they were excited about, you know, newbies being there and asking questions and, you know, really sort of getting to know folks who are just starting out in their programming journey. +And really, through that, I mean, I went to my first RubyConf as a scholar. Was strongly encouraged to do a lightning talk, did a lightning talk. That's how I, you know, sort of ended up having a whole bunch of informational interviews and having conversations with folks. And really, that's how I got my first real job in tech. And so, you know, I want people that are coming into the industry now to have that same support, to have those same opportunities, to have that same encouragement. +And, for me, sort of planning RubyConf, planning these conferences, being a part of Ruby Central is really me giving back to the community that has gotten me to where I am today, right? And it's amazing, also, to just...I'm still in touch with the people that were at my table, sort of guiding and mentoring at that first Rails Girls session or the people who I met at the first-ever Ruby meetup that I went to. +I still talk to them. I'm still in touch with them. We still get together. I still ask them for, you know, advice and guidance sometimes. And sometimes, they ask me, at this point, for advice and guidance, which is fun. But yeah, it just means so much to me that I have really been able to get to where I'm at because of the support and encouragement of the community. +CHELSEA: I have a similar story. I guess over, gosh, over a decade ago, I also went to my first RailsBridge and got introduced to the community there at RailsBridge. And, you know, at the time, I wasn't in tech. I was in the theater. I come from the performing arts. I had spent a very long time executive leadership in the theater. And I got introduced to this community that was so warm and welcoming to people wanting to learn and grow. And I was so interested in how communities are built and how people connect together that I started getting more and more involved in the Ruby community here in San Diego. +And just like Allison was saying about the welcoming and warmth that she felt from the D.C. community, I felt the same way here in San Diego. Before that, you know, I had spent so many years being the only woman in a room. I had been in an industry that made me feel like my voice was not always heard. And when I walked into this room, I felt like I mattered. I felt like people wanted to hear what I had to say. And they wanted to learn from my experiences. +And in 2014, San Diego hosted RubyConf here. And at that point, my business partner and I launched our business, LEARN Academy, and it's still running strong today. But it was about creating that on-ramp for people and a launchpad into this industry where they could make a difference and they could have their voice heard. And they could be a part of a conversation, even if they hadn't been a part of that community for many, many years, that their background mattered, that their growth mattered. +And helping people find their voice at a table is something that is so important to me that I love being able to bring that into the planning of this conference, into a lot of the work that I've done with Ruby Central, with LEARN academy. And really just helping people understand that just because you don't have the traditional background, maybe you didn't start programming at the age of two, you can have a different background and a different path and still provide so much value. +And I think that that is the thing that I wanted to continue to be a part of and to make sure was a part of the conversation, that we need so many different types of people at the table. And I want to make sure that our community is responsive to that, that it's inclusive to that, that it's equitable as best we can, and just allows people to share their own experiences. And so, you know, I feel like, for me, we're, you know, almost at our 10-year mark at LEARN academy and that we were launching the company at RubyConf in 2014. To have it here again this year is so special to me. +I remember being at the conference many years ago; you know, we spend a lot of time helping companies figure out how to work with early-career developers and to create those pipelines for them so that there's career growth for them. And, you know, I remember sitting around the table and just saying, "Hey, who wants an internship? Who wants to, you know, help these early-career developers?" And everyone raised their hand, and we found some of our very first partners at that conference. And it's always been such a warm and welcoming community that has allowed me to feel like I have a voice and then allows me to help other people find theirs. +VICTORIA: Wow, thank you both for sharing that. I totally relate to that feeling of a welcoming community and just getting the sense that, like, wow, everyone who does Ruby is really nice [laughs]. And I think that you know, for me, same as Allison, starting in D.C., there were quite a few people who were involved in Women Who Code who were running Ruby meetups. And that's where I met Valerie Woolard, who I think is also coming to San Diego for RubyConf. I'm excited to see her again. +And it's interesting for me coming from that perspective and hearing that from both of you because I've also heard a viewpoint on Ruby community as being highly opinionated and causing certain amounts of consternation. So, I'm curious if you have any comments on that. If not, otherwise, I'm grateful that there are people working to bring that better community in the community that I'm more familiar with more to the forefront and making it more inclusive and open for everyone. +So, to, like, bring the question all the way back, it's like [chuckles], do you have any comments on, like, if there's a tendency for Rubyists to be really highly opinionated? Or what else can we do to make it more open and inclusive for people to join the community? +CHELSEA: I mean, I think that people are going to be opinionated about something that they care a lot about. And I think that the thing that I've noticed in the Ruby community is people love this language. They love programming in this language, and I think that there's something very powerful about that. And it does, you know, lend itself to people [laughs] having very strong opinions about what they think needs to be out there. +And, to me, it's not a matter of, like, whether we have strong opinions or not. It has more to do with whether we're listening or not. But I think it's really important for those of us who are leading to be the listeners, and that we should be there to make sure that there is space for people to be heard, whether their opinion is loud or not. And I think that there are people that are going to be louder than others; that is going to be true no matter where we go. +But I think that as long as there is intention around making sure that we are listening to even the quietest voices and that we are creating space for the quietest voices, that's where we're going to find more collaboration. But if we're only going out there and saying, "This is the way it needs to be," and we're not willing to listen to anything else, then I think that growth will stop happening because we need to listen to everyone. We need to be able to create some kind of place for people to come together and share ideas; you know, you don't get the perspectives of all these amazing people in the industry. +So, that's why I feel like, you know, I've been on the board at Ruby Central for about a year now, and the biggest thing that I feel like I can contribute is to simply listen. If I can help in any way of filtering ideas or creating connections with people because I've been putting my ear to the ground and saying, "Okay, these people are talking about this, and we're expanding here." And we just want to make sure that we're doing the best we can at being open to all different kinds of ideas and not closing anyone off. +Maybe your opinion is really strong. It doesn't mean that we should shut you down. It just means that we need to make sure that there's space for other people, too. And I think that that's the part that, you know, as someone who has always been a bit of an introvert, a bit of a wallflower, I understand how hard it is to get my voice out there. And so, I often fight for the quiet people. I think in every language and any space where it's a craft, it's something that we're creating, people get really passionate about it. And that's going to happen. And I think there's something powerful in that because there's going to be change that happens from that. +But if we're not doing our part in the listening and making sure that there isn't just one voice, that there's a collective voice, that's the part that I felt so powerful when I joined the community so many years ago was that, even though I had, you know, months of experience, my questions mattered. And as long as we hold on to that, the community will continue to grow. +But those of us at Ruby Central and some of the other organizations, if we're creating space to allow people to question, allow people to speak their opinions and listen, then I think that the industry, the community will just continue to thrive because of that. But we have to be open, and we have to be compassionate when we're doing our listening. +ALLISON: Yeah, I agree with all of that. And I would just add in safe places, in a way that we're creating sort of safe structures and safe places for folks to communicate. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: What, if you could tell me, what does Ruby really have going for it? Like what makes Ruby a good choice for tech founders or for new companies would make someone decide they want to build with Ruby? +ALLISON: First, it's a little bit about just sort of the ease of the language to jump into and to understand, right? There's a lot that you can get done very quickly with Ruby and Rails. And in addition to sort of individuals being able to work in it, there's a whole community of resources, and support, and podcasts, and tutorials, and all sorts of stuff. +I know that as an engineering leader at any company, when engineers are coming to me with, like, the desire to use a new language or try something new, part of what I look at is, if I'm going to hire, like, what would hiring look like? What does it look like for engineers to have to ramp up in this area? How long does that take? What resources are available? What sort of community am I pulling from and looking at? And that's both community in terms of sort of technical experience, expertise, years, et cetera, but also non-technical skills, right? What does the community look like in terms of some of those ideals around communication, collaboration, just sort of general pieces like that? +And so, I think that, given sort of the strength of open source, strength of community, community contributions, ways to contribute, etcetera, I think that's one of the reasons that it still makes Ruby a really strong choice for folks to build in and to work with. +VICTORIA: What type of people, what personas do you think will be the most interested in attending RubyConf? Is it all just going to be, like, senior or super Ruby developers, or what? +CHELSEA: Oh, I don't think so. I mean, this RubyConf, in particular, is great for anyone on a learning journey. We've worked really hard to make sure there's a good breadth of programming for different folks in different stages of their careers. I think that, you know, those of you that are maybe earlier on there, this is a great opportunity to meet people who are maybe even a step or two ahead of you. I think that the best mentorship that you can find is someone who is only maybe a year ahead of you because they're going to recognize where you're at and help you along the way. And I think that there's a lot of opportunities here for that. +I think that with our Community Day, the hacking that's going to be involved, like, maybe, as a new developer, you wouldn't be able to come in and, like, get your hands really dirty. But you'll get to sit next to somebody who has been through all the different stages and get to watch, and explore, and learn. I think that making those connections could be really great for anyone's career. I think that our mid-level developers, folks that are our management, there's great resources for them to connect with other developers in similar stages. There's great workshops. +Because of our focus on the community, I think that it's going to be a place where you can really connect with other Rubyists. And so, if you are at a stage in your career that you want to figure out what that next spring is, where that next ladder step is, this is a good place to see all the different options because you're going to be surrounded by people in all different stages of their careers. +And what we've, I think, said now quite a few times is so many people there are just so excited to help people continue that growth. And so, I think that no matter what stage you're in, you're going to find people there that are excited to help you along the way. +That being said, I think for our more senior, more advanced, our executive leadership, this is going to be a great place to, one, meet some really great talent, and, two, I think, learn from other folks in the industry of, like, where people are at, what we're struggling with, and how we're changing and doing things differently. +So, I really do think there's going to be a little bit of everything for people. And what I love about that is really that it gets to the core and heart of the Ruby community because we're so excited about new folks coming in that that growth continues, that you have folks like Allison who started out as a scholar and want to give back. +And then because we have folks at all those different stages, you can find people that are, you know, maybe a step or two ahead of you that are going to be able to help bring you up to that next level. So, I think it's an exciting opportunity for people to really meet new people, learn some new things, maybe find a little bit of encouragement, empowerment on where you're going to go next on your career. +VICTORIA: Yeah, absolutely. And it reminds me of an article I read while I was at RailsConf earlier this year about why we do conferences and what's the whole point. And, you know, for me, all of those things are true, like, all those values. As an executive, I'm going to meet a lot of great talent. I'm going to connect with other companies. I'm just going to get to show up and say hi to people and ask them questions in a way that's very informal. And that's so valuable to have that. +I think where I was going to go next with this was with Ruby Central, which I believe organizes both RailsConf and RubyConf. (And you can correct me if I'm wrong on that.) I'm curious if there are anything else you want to talk about with, like how the community can engage in support and how other companies could get involved with the community and show their support. +CHELSEA: I think that there's quite a few different ways for folks to get involved. We are currently recruiting board members. We just finished a round just now. But I know that in our planning, that we're likely going to bring on at least one, maybe two more, in the next six months. So, I definitely...for folks in the community that want to get involved, that is a really great place to really get involved with Ruby Central. +We also have a really strong open-source community. And we're working, oh gosh, with quite a few different companies now that are really helping to support our open-source efforts. And those are also good ways to get involved. You know, we do plan both RailsConf and RubyConf. RailsConf will be in the spring again. And, you know, it takes a village to put on a conference like this and that, you know, we also look for programming committee members to help us shape the program of the conferences. So, if you are interested in any of that, that's also another great way to get involved in the community. +We have an amazing programming committee that's helped us with RubyConf. And I'm excited to see what we do next with RailsConf. And I think that you know if you're one that's going to the conference and are saying, "Man, I wish that they would do this," or "I wish I could see that," come and talk to us because that's the best way for us to learn, that we want to hear all of those pieces. But don't be surprised if we then send you an email and say, "Hey, you want to be on our programming committee with us?" +ALLISON: I'll add that we also, through our website, we take donations. So, if you want to help monetarily, there's the option to do that on the website. And if you're a company, I mean, we're always looking for conference sponsorships. But if your company also is interested in getting involved in sort of more of a corporate sense of sponsoring or supporting Ruby Central, we are always open to those conversations. You can send an email to contact@rubycentral.org. +VICTORIA: That's great. I have a fun question about the conference because I'm leading the event with thoughtbot since I live here. And I'm thinking about some fun swag to give away. Rank your preferences on what kind of swag you'd like to see at the thoughtbot sponsor booth: a thoughtbot-branded surfboard or, a boogie board, a bucket hat, or a pickleball paddle. Any of those interesting for you? +ALLISON: Wait, when you say surfboard, like, how am I going to get a surfboard back to D.C.? +[laughter] +VICTORIA: Okay. I think it's, like, kind of funny because if you win it, it's like, well, what do you do? [laughter] You got to shake it back. That sounds like maybe a boogie board. +CHELSEA: Yeah, I'm down for a boogie board. +VICTORIA: Thank you so [laughs] much for entertaining me on that one. Is there anything else that you would like to promote today? +ALLISON: We would love to see everybody at RubyConf. You can register. Check out the program speakers, et cetera, at rubyconf.org. You can learn more about Ruby Central at rubycentral.org. Those are, I think, the two things that we'd love to make sure everybody knows about. +CHELSEA: And if you're here in San Diego, come say hello. +VICTORIA: Yes, I have met up with a few random people from the internet [laughs] who have said like, "I'm in San Diego. Who should I say hi [inaudible 34:02]?" I was like, "Me, me, me," [laughter]. So, yes, I'm very happy to meet up for drinks. Chelsea, you and I will have to get together sometime soon before the conference. And I'm super excited for RubyConf. And thank you both so much for being here today. +ALLISON: Thanks for having us. +CHELSEA: Thank you. +VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantsrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Allison McMillan and Chelsea Kaufman. + + + In this episode, the focus is on RubyConf, the upcoming conference dedicated to the Ruby programming language. They start by talking about the origin and evolution of RubyConf, highlighting its growth in attendance and its impact on the Ruby community. Chelsea details how the conference has adapted to the digital format due to the COVID-19 pandemic but points out the value of in-person connections. They are looking forward to the Community Day event, which will feature various activities to encourage community interaction and an acknowledgment of scholarships that would help more people attend.

+ +

The event will offer various programming options, workshops, and talks to cater to newcomers and seasoned professionals. There will also be some level of hands-on learning through hacking activities. The conference aims to be inclusive, offering opportunities for mentorship and growth, regardless of one's career stage.

+ +

Towards the end, the discussion shifts to Ruby Central, the organizing body behind RubyConf and RailsConf. Chelsea and Allison describe multiple avenues for community engagement, ranging from board membership to open-source contributions. They also encourage donations and corporate sponsorships. Don't miss your chance to register for RubyConf and engage with the fantastic Ruby community!

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Allison McMillan and Chelsea Kaufman, Board Directors, and RubyConf '23 Co-chairs. Thank you for joining me.

+ +

ALLISON: Hi, thanks for having us.

+ +

CHELSEA: Thanks for having us.

+ +

VICTORIA: Yes, I'm glad that you were able to make time to come on the show today. I understand, Allison, that you've been having very full weeks with family over the last month. Do you want to tell us a little bit more about that?

+ +

ALLISON: Yeah, it's...we have just ended what I call the gauntlet of Jewish holidays. But, basically, there are four Jewish holidays starting with Rosh Hashanah, which many folks know that's the Jewish New Year. But what a lot of folks don't know is that there are actually four holidays that are all in a row, each about a week apart. And you do different celebratory things for each of them.

+ +

And so, it's been really amazing and fun, and lots of, like, sharing our home with others and meals and seeing lots of people. But it is also exhausting. And they basically all fell on weekends this year, which was nice from sort of a scheduling perspective but was exhausting in the fact that I basically have not had a weekend in over a month. So, it was wonderful and tiring. And I am, I guess, both happy and sad that they're over now.

+ +

VICTORIA: Yeah, that does sound like a lot of quality family time, which has its pros and cons [laughs], right? So, after going through that, do you feel more rested? Or what do you feel like you need to do in order to recuperate and return to your normal energy levels after having every weekend full after that?

+ +

ALLISON: Oh, that's a great question. I've been looking at my calendar to be like, I should take a day off. I should take a break. I'm working for myself and [inaudible 02:02] entrepreneur consultant. So, I do have the flexibility to do so, but it is hard to look at my calendar and be like, yes, I will take this day off because I deserve it. But, ideally, I would take a day or multiple days off.

+ +

VICTORIA: Yes. And some of us are lucky enough to have a reason to travel for work purposes and to sneak in a little vacation and be productive [laughs] in our companies. So, I'm curious, Chelsea, if you can tell me a little bit about the option for people to come to San Diego in November and take a restful vacation by the beach and learn a little bit more about Ruby.

+ +

CHELSEA: Yeah, so RubyConf will be in San Diego this year. As a native San-dieagan, I am a bit biased, but November is a beautiful time to be in San Diego. And we're going to be at the Town and Country, which feels a little bit like we're going to be in a, like, Palm Springs resort. They just went through a major renovation.

+ +

And there's these really awesome, like, lounge areas with fire pits and just places for people to gather, which really kind of aligns itself with some of the stuff that we're planning because we're really trying to focus in on just connecting Rubyists together. So, to me, it feels like the perfect place because I think San Diego is, one, we're a little bit more low key, a little chill. And it's a great place to just gather and connect and share with people that have, you know, similar interests.

+ +

VICTORIA: Yes, I live in San Diego now, but I was from Washington, D.C., And I would come and visit my family in San Diego once a year. And they would always go on about how great it is and how beautiful, and everyone is so happy and chill. And I was like, sure, whatever. And then we [chuckles] had the opportunity to move here, and now I'm one of those people who says that [laughs]. Like, it's great, especially in November. Everywhere else is getting a little cold and fall. And San Diego has a little bit of fall, but it's still 75 degrees out. I forget what that is in Celsius. But yes, I'm also super excited.

+ +

CHELSEA: We have, like, fake fall activities that you can go do. Like, Allison, when you're talking about doing all the family activities and things like that, you know, this is when we start thinking about, oh, we need to go to, like, the pumpkin patch and apple picking and do all these things, but it's not cold or, like, fall weather at all. So, you want to get all, like, bundled up in your cute fall clothes or, like, put my kids and bundle them up in cute things. But then they're, like, sweating and trying to do [laughs] all these funny activities.

+ +

But I think that there's so many beautiful things to do here that we, like, try and do these, like, fall activities. But then we just end up at the beach and play in the sand [laughs].

+ +

VICTORIA: Yeah, I will go out in, like, shorts and a T-shirt because it's that kind of weather. And my neighbors will be wearing full puffy jackets and [laughs], like, long pants and a hat. And they're like, "You're not from around here, are you?" [laughs]. It's like, you guys are silly. But it's fun. Yeah, there's seasons, I think, you know, in November...I made a list of suggested activities for my team members since thoughtbot is sponsoring RubyConf this year. And we're going to have a couple of speakers at the event. And we'll have other thoughtboters available at our booth for people to come up and chat with us. So, I'm really thrilled to be hosting everyone.

+ +

And I made a list of, like, activities, and most of them were about where to see cool animals [laughs]. I was like, of course, there's the zoo, which is the obvious one, but then there's baby leopard sharks, and there's a season for them. I think they will still be around in November; I'm curious if you know, Chelsea, actually. And then there's, like, the safari parks, and whale watching, and the sea lions at La Jolla and, like, just a bunch of cool animals to see that I think it makes San Diego really special.

+ +

CHELSEA: I agree. The zoo, the safari park are great places to just hang out and see some really cool exhibits. Balboa Park, the museums there are amazing. Liberty Station is one of my favorite places to go; that it's an old historic naval training center that's been converted into an arts and culture area. So, they have, like, little shops. They have...there's museums. There's brew pubs. There's coffee shops. And then there's beautiful, like, grassy areas, and right by the water, it's one of my favorite places to just go and hang out.

+ +

ALLISON: This is great. I've done zero research on San Diego so far. So, just, like, I'm writing notes of what things to do and see while I'm there.

+ +

CHELSEA: Yeah, I know the San Diego Ruby group is trying to put together some, like, local events and things that people can gather and do together. I know that there was a talk about doing a taco crawl. I think if I say that on the podcast, it might actually push them to do it because there are some amazing tacos in San Diego to be had.

+ +

VICTORIA: Yes, I love that taco crawl. I'll reach out to them because I'll help put something like that together. I'm writing a blog post right now about all of these things and about all the other kind of events that are coming up in San Diego this fall. Great location, great time of year to be here. Tell me a little bit more about RubyConf specifically. And what are you all trying to do different this year than in past events?

+ +

ALLISON: There are a bunch of things that we're doing differently. Our goal this year with this RubyConf is really to sort of focus on more ways to bring the community together. I think in the last little bit so much excitement around Ruby and Ruby Central and just sort of the community in general. It's a hard time in tech. I think people need to be sort of choosier about sort of what they attend and why they're attending something. And so, we really wanted to help folks connect with each other, help folks get to know other people, help folks sort of reconnect to ways that they love Ruby and the Ruby community and being a Ruby programmer.

+ +

So, one of the things that we're doing differently is we have a three-day conference. And the way that that sort of broken down is the first day is a Community Day. And the first day is comprised of the workshops, as well as sort of this Hack Day, where people can bring their own projects.

+ +

We're going to have people there that folks can hack with, sort of open-source projects that folks can work on, all sorts of different stuff. So that people can really sort of get to know one another, work with one another, work with people that they might, you know, admire or have followed in the community for a while, and have that sort of really special experience that doesn't feel as conference-y, right? It feels a little bit more sort of organic in terms of the way that the day will flow and, the options that people have, and sort of what that day looks like.

+ +

And then following that, we have two days of sort of RubConf with talks and speakers, et cetera. And I'll let Chelsea add anything to Community Day and then also jump into some of the sort of new and different things we're doing at RubyConf.

+ +

CHELSEA: I agree with Allison in that we've really wanted to focus in on the connection side of things. But I think coming out of the last few years, out of even the last year that's been tough in the industry, just finding ways for people to connect, support, lift up each other, I think that that was something we really wanted to do. And we didn't want it to just be about going and seeing speakers. We wanted to find more ways for people to learn from each other, to connect. And so we added in quite a few of these community connection points.

+ +

So, on that first day, there's a lot of community aspects to it. We have a lot of learning happening with our workshops and also working on projects, hacking together, showing off what you're working on, connecting with people in the community. It's going to be really focused in on everyone's own skills and talents and coming together and supporting each other in where we're at in our careers, in our learning.

+ +

And then, the next couple of days will look a little bit familiar in the way that it is structured with some new aspects kind of woven in. We'll have our Community Room, where we're bringing different community groups together so that people can learn more about what is going on in the community, how they can support, how they can connect.

+ +

And in addition to seeing and learning about some of the new things happening in the Ruby community, we'll also have our Career Pathways room again, which will be a place for people to support their own careers. And that room was really set up so that it wasn't just about early career, but also about folks in their mid and senior careers, and finding the advice, finding the resources, finding the mentorship that they might need in whatever stage of their career that they're at, and figuring out how we can together as a community grow as a whole.

+ +

VICTORIA: I really appreciate the focus on community. And, for me, as managing director at thoughtbot, in deciding to invest in which conferences we want to attend and sponsor, we find more value in groups that are trying to bring people together around a common passion and purpose versus a particular product.

+ +

But I'd like to hear from each of you if you can tell me, what does the community mean to you? And I'm looking for, like, a personal story on how you've benefited or how you've engaged with the Ruby community in the past. And what makes you motivated as CEOs and founders of your own companies [laughs] to spend all this time organizing a conference?

+ +

ALLISON: Many, many, many years ago, I did a Rails Girls workshop. It was actually my first introduction into the tech community, into programming in general. And, for me, really, I did Rails Girls. I did not actually expect to like programming. But I was sort of launching a startup, and I wanted to learn more about tech and blah, blah, blah. And at the end of the day, I was, like, so energized and so excited about what I had built and what I had done.

+ +

The Ruby community in D.C., who I always think is just a group of really special individuals, was so supportive, was so wonderful, was so, like, "Here's where we co-work on Wednesdays. Come to this coffee shop. Here's how you can keep learning," just was so encouraging. You know, I went to the local Ruby meetup sort of really not knowing anything. And they were excited about, you know, newbies being there and asking questions and, you know, really sort of getting to know folks who are just starting out in their programming journey.

+ +

And really, through that, I mean, I went to my first RubyConf as a scholar. Was strongly encouraged to do a lightning talk, did a lightning talk. That's how I, you know, sort of ended up having a whole bunch of informational interviews and having conversations with folks. And really, that's how I got my first real job in tech. And so, you know, I want people that are coming into the industry now to have that same support, to have those same opportunities, to have that same encouragement.

+ +

And, for me, sort of planning RubyConf, planning these conferences, being a part of Ruby Central is really me giving back to the community that has gotten me to where I am today, right? And it's amazing, also, to just...I'm still in touch with the people that were at my table, sort of guiding and mentoring at that first Rails Girls session or the people who I met at the first-ever Ruby meetup that I went to.

+ +

I still talk to them. I'm still in touch with them. We still get together. I still ask them for, you know, advice and guidance sometimes. And sometimes, they ask me, at this point, for advice and guidance, which is fun. But yeah, it just means so much to me that I have really been able to get to where I'm at because of the support and encouragement of the community.

+ +

CHELSEA: I have a similar story. I guess over, gosh, over a decade ago, I also went to my first RailsBridge and got introduced to the community there at RailsBridge. And, you know, at the time, I wasn't in tech. I was in the theater. I come from the performing arts. I had spent a very long time executive leadership in the theater. And I got introduced to this community that was so warm and welcoming to people wanting to learn and grow. And I was so interested in how communities are built and how people connect together that I started getting more and more involved in the Ruby community here in San Diego.

+ +

And just like Allison was saying about the welcoming and warmth that she felt from the D.C. community, I felt the same way here in San Diego. Before that, you know, I had spent so many years being the only woman in a room. I had been in an industry that made me feel like my voice was not always heard. And when I walked into this room, I felt like I mattered. I felt like people wanted to hear what I had to say. And they wanted to learn from my experiences.

+ +

And in 2014, San Diego hosted RubyConf here. And at that point, my business partner and I launched our business, LEARN Academy, and it's still running strong today. But it was about creating that on-ramp for people and a launchpad into this industry where they could make a difference and they could have their voice heard. And they could be a part of a conversation, even if they hadn't been a part of that community for many, many years, that their background mattered, that their growth mattered.

+ +

And helping people find their voice at a table is something that is so important to me that I love being able to bring that into the planning of this conference, into a lot of the work that I've done with Ruby Central, with LEARN academy. And really just helping people understand that just because you don't have the traditional background, maybe you didn't start programming at the age of two, you can have a different background and a different path and still provide so much value.

+ +

And I think that that is the thing that I wanted to continue to be a part of and to make sure was a part of the conversation, that we need so many different types of people at the table. And I want to make sure that our community is responsive to that, that it's inclusive to that, that it's equitable as best we can, and just allows people to share their own experiences. And so, you know, I feel like, for me, we're, you know, almost at our 10-year mark at LEARN academy and that we were launching the company at RubyConf in 2014. To have it here again this year is so special to me.

+ +

I remember being at the conference many years ago; you know, we spend a lot of time helping companies figure out how to work with early-career developers and to create those pipelines for them so that there's career growth for them. And, you know, I remember sitting around the table and just saying, "Hey, who wants an internship? Who wants to, you know, help these early-career developers?" And everyone raised their hand, and we found some of our very first partners at that conference. And it's always been such a warm and welcoming community that has allowed me to feel like I have a voice and then allows me to help other people find theirs.

+ +

VICTORIA: Wow, thank you both for sharing that. I totally relate to that feeling of a welcoming community and just getting the sense that, like, wow, everyone who does Ruby is really nice [laughs]. And I think that you know, for me, same as Allison, starting in D.C., there were quite a few people who were involved in Women Who Code who were running Ruby meetups. And that's where I met Valerie Woolard, who I think is also coming to San Diego for RubyConf. I'm excited to see her again.

+ +

And it's interesting for me coming from that perspective and hearing that from both of you because I've also heard a viewpoint on Ruby community as being highly opinionated and causing certain amounts of consternation. So, I'm curious if you have any comments on that. If not, otherwise, I'm grateful that there are people working to bring that better community in the community that I'm more familiar with more to the forefront and making it more inclusive and open for everyone.

+ +

So, to, like, bring the question all the way back, it's like [chuckles], do you have any comments on, like, if there's a tendency for Rubyists to be really highly opinionated? Or what else can we do to make it more open and inclusive for people to join the community?

+ +

CHELSEA: I mean, I think that people are going to be opinionated about something that they care a lot about. And I think that the thing that I've noticed in the Ruby community is people love this language. They love programming in this language, and I think that there's something very powerful about that. And it does, you know, lend itself to people [laughs] having very strong opinions about what they think needs to be out there.

+ +

And, to me, it's not a matter of, like, whether we have strong opinions or not. It has more to do with whether we're listening or not. But I think it's really important for those of us who are leading to be the listeners, and that we should be there to make sure that there is space for people to be heard, whether their opinion is loud or not. And I think that there are people that are going to be louder than others; that is going to be true no matter where we go.

+ +

But I think that as long as there is intention around making sure that we are listening to even the quietest voices and that we are creating space for the quietest voices, that's where we're going to find more collaboration. But if we're only going out there and saying, "This is the way it needs to be," and we're not willing to listen to anything else, then I think that growth will stop happening because we need to listen to everyone. We need to be able to create some kind of place for people to come together and share ideas; you know, you don't get the perspectives of all these amazing people in the industry.

+ +

So, that's why I feel like, you know, I've been on the board at Ruby Central for about a year now, and the biggest thing that I feel like I can contribute is to simply listen. If I can help in any way of filtering ideas or creating connections with people because I've been putting my ear to the ground and saying, "Okay, these people are talking about this, and we're expanding here." And we just want to make sure that we're doing the best we can at being open to all different kinds of ideas and not closing anyone off.

+ +

Maybe your opinion is really strong. It doesn't mean that we should shut you down. It just means that we need to make sure that there's space for other people, too. And I think that that's the part that, you know, as someone who has always been a bit of an introvert, a bit of a wallflower, I understand how hard it is to get my voice out there. And so, I often fight for the quiet people. I think in every language and any space where it's a craft, it's something that we're creating, people get really passionate about it. And that's going to happen. And I think there's something powerful in that because there's going to be change that happens from that.

+ +

But if we're not doing our part in the listening and making sure that there isn't just one voice, that there's a collective voice, that's the part that I felt so powerful when I joined the community so many years ago was that, even though I had, you know, months of experience, my questions mattered. And as long as we hold on to that, the community will continue to grow.

+ +

But those of us at Ruby Central and some of the other organizations, if we're creating space to allow people to question, allow people to speak their opinions and listen, then I think that the industry, the community will just continue to thrive because of that. But we have to be open, and we have to be compassionate when we're doing our listening.

+ +

ALLISON: Yeah, I agree with all of that. And I would just add in safe places, in a way that we're creating sort of safe structures and safe places for folks to communicate.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: What, if you could tell me, what does Ruby really have going for it? Like what makes Ruby a good choice for tech founders or for new companies would make someone decide they want to build with Ruby?

+ +

ALLISON: First, it's a little bit about just sort of the ease of the language to jump into and to understand, right? There's a lot that you can get done very quickly with Ruby and Rails. And in addition to sort of individuals being able to work in it, there's a whole community of resources, and support, and podcasts, and tutorials, and all sorts of stuff.

+ +

I know that as an engineering leader at any company, when engineers are coming to me with, like, the desire to use a new language or try something new, part of what I look at is, if I'm going to hire, like, what would hiring look like? What does it look like for engineers to have to ramp up in this area? How long does that take? What resources are available? What sort of community am I pulling from and looking at? And that's both community in terms of sort of technical experience, expertise, years, et cetera, but also non-technical skills, right? What does the community look like in terms of some of those ideals around communication, collaboration, just sort of general pieces like that?

+ +

And so, I think that, given sort of the strength of open source, strength of community, community contributions, ways to contribute, etcetera, I think that's one of the reasons that it still makes Ruby a really strong choice for folks to build in and to work with.

+ +

VICTORIA: What type of people, what personas do you think will be the most interested in attending RubyConf? Is it all just going to be, like, senior or super Ruby developers, or what?

+ +

CHELSEA: Oh, I don't think so. I mean, this RubyConf, in particular, is great for anyone on a learning journey. We've worked really hard to make sure there's a good breadth of programming for different folks in different stages of their careers. I think that, you know, those of you that are maybe earlier on there, this is a great opportunity to meet people who are maybe even a step or two ahead of you. I think that the best mentorship that you can find is someone who is only maybe a year ahead of you because they're going to recognize where you're at and help you along the way. And I think that there's a lot of opportunities here for that.

+ +

I think that with our Community Day, the hacking that's going to be involved, like, maybe, as a new developer, you wouldn't be able to come in and, like, get your hands really dirty. But you'll get to sit next to somebody who has been through all the different stages and get to watch, and explore, and learn. I think that making those connections could be really great for anyone's career. I think that our mid-level developers, folks that are our management, there's great resources for them to connect with other developers in similar stages. There's great workshops.

+ +

Because of our focus on the community, I think that it's going to be a place where you can really connect with other Rubyists. And so, if you are at a stage in your career that you want to figure out what that next spring is, where that next ladder step is, this is a good place to see all the different options because you're going to be surrounded by people in all different stages of their careers.

+ +

And what we've, I think, said now quite a few times is so many people there are just so excited to help people continue that growth. And so, I think that no matter what stage you're in, you're going to find people there that are excited to help you along the way.

+ +

That being said, I think for our more senior, more advanced, our executive leadership, this is going to be a great place to, one, meet some really great talent, and, two, I think, learn from other folks in the industry of, like, where people are at, what we're struggling with, and how we're changing and doing things differently.

+ +

So, I really do think there's going to be a little bit of everything for people. And what I love about that is really that it gets to the core and heart of the Ruby community because we're so excited about new folks coming in that that growth continues, that you have folks like Allison who started out as a scholar and want to give back.

+ +

And then because we have folks at all those different stages, you can find people that are, you know, maybe a step or two ahead of you that are going to be able to help bring you up to that next level. So, I think it's an exciting opportunity for people to really meet new people, learn some new things, maybe find a little bit of encouragement, empowerment on where you're going to go next on your career.

+ +

VICTORIA: Yeah, absolutely. And it reminds me of an article I read while I was at RailsConf earlier this year about why we do conferences and what's the whole point. And, you know, for me, all of those things are true, like, all those values. As an executive, I'm going to meet a lot of great talent. I'm going to connect with other companies. I'm just going to get to show up and say hi to people and ask them questions in a way that's very informal. And that's so valuable to have that.

+ +

I think where I was going to go next with this was with Ruby Central, which I believe organizes both RailsConf and RubyConf. (And you can correct me if I'm wrong on that.) I'm curious if there are anything else you want to talk about with, like how the community can engage in support and how other companies could get involved with the community and show their support.

+ +

CHELSEA: I think that there's quite a few different ways for folks to get involved. We are currently recruiting board members. We just finished a round just now. But I know that in our planning, that we're likely going to bring on at least one, maybe two more, in the next six months. So, I definitely...for folks in the community that want to get involved, that is a really great place to really get involved with Ruby Central.

+ +

We also have a really strong open-source community. And we're working, oh gosh, with quite a few different companies now that are really helping to support our open-source efforts. And those are also good ways to get involved. You know, we do plan both RailsConf and RubyConf. RailsConf will be in the spring again. And, you know, it takes a village to put on a conference like this and that, you know, we also look for programming committee members to help us shape the program of the conferences. So, if you are interested in any of that, that's also another great way to get involved in the community.

+ +

We have an amazing programming committee that's helped us with RubyConf. And I'm excited to see what we do next with RailsConf. And I think that you know if you're one that's going to the conference and are saying, "Man, I wish that they would do this," or "I wish I could see that," come and talk to us because that's the best way for us to learn, that we want to hear all of those pieces. But don't be surprised if we then send you an email and say, "Hey, you want to be on our programming committee with us?"

+ +

ALLISON: I'll add that we also, through our website, we take donations. So, if you want to help monetarily, there's the option to do that on the website. And if you're a company, I mean, we're always looking for conference sponsorships. But if your company also is interested in getting involved in sort of more of a corporate sense of sponsoring or supporting Ruby Central, we are always open to those conversations. You can send an email to contact@rubycentral.org.

+ +

VICTORIA: That's great. I have a fun question about the conference because I'm leading the event with thoughtbot since I live here. And I'm thinking about some fun swag to give away. Rank your preferences on what kind of swag you'd like to see at the thoughtbot sponsor booth: a thoughtbot-branded surfboard or, a boogie board, a bucket hat, or a pickleball paddle. Any of those interesting for you?

+ +

ALLISON: Wait, when you say surfboard, like, how am I going to get a surfboard back to D.C.?

+ +

[laughter]

+ +

VICTORIA: Okay. I think it's, like, kind of funny because if you win it, it's like, well, what do you do? [laughter] You got to shake it back. That sounds like maybe a boogie board.

+ +

CHELSEA: Yeah, I'm down for a boogie board.

+ +

VICTORIA: Thank you so [laughs] much for entertaining me on that one. Is there anything else that you would like to promote today?

+ +

ALLISON: We would love to see everybody at RubyConf. You can register. Check out the program speakers, et cetera, at rubyconf.org. You can learn more about Ruby Central at rubycentral.org. Those are, I think, the two things that we'd love to make sure everybody knows about.

+ +

CHELSEA: And if you're here in San Diego, come say hello.

+ +

VICTORIA: Yes, I have met up with a few random people from the internet [laughs] who have said like, "I'm in San Diego. Who should I say hi [inaudible 34:02]?" I was like, "Me, me, me," [laughter]. So, yes, I'm very happy to meet up for drinks. Chelsea, you and I will have to get together sometime soon before the conference. And I'm super excited for RubyConf. And thank you both so much for being here today.

+ +

ALLISON: Thanks for having us.

+ +

CHELSEA: Thank you.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantsrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Allison McMillan and Chelsea Kaufman.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, the focus is on RubyConf, the upcoming conference dedicated to the Ruby programming language. They start by talking about the origin and evolution of RubyConf, highlighting its growth in attendance and its impact on the Ruby community. Chelsea details how the conference has adapted to the digital format due to the COVID-19 pandemic but points out the value of in-person connections. They are looking forward to the Community Day event, which will feature various activities to encourage community interaction and an acknowledgment of scholarships that would help more people attend.

+ +

The event will offer various programming options, workshops, and talks to cater to newcomers and seasoned professionals. There will also be some level of hands-on learning through hacking activities. The conference aims to be inclusive, offering opportunities for mentorship and growth, regardless of one's career stage.

+ +

Towards the end, the discussion shifts to Ruby Central, the organizing body behind RubyConf and RailsConf. Chelsea and Allison describe multiple avenues for community engagement, ranging from board membership to open-source contributions. They also encourage donations and corporate sponsorships. Don't miss your chance to register for RubyConf and engage with the fantastic Ruby community!

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Allison McMillan and Chelsea Kaufman, Board Directors, and RubyConf '23 Co-chairs. Thank you for joining me.

+ +

ALLISON: Hi, thanks for having us.

+ +

CHELSEA: Thanks for having us.

+ +

VICTORIA: Yes, I'm glad that you were able to make time to come on the show today. I understand, Allison, that you've been having very full weeks with family over the last month. Do you want to tell us a little bit more about that?

+ +

ALLISON: Yeah, it's...we have just ended what I call the gauntlet of Jewish holidays. But, basically, there are four Jewish holidays starting with Rosh Hashanah, which many folks know that's the Jewish New Year. But what a lot of folks don't know is that there are actually four holidays that are all in a row, each about a week apart. And you do different celebratory things for each of them.

+ +

And so, it's been really amazing and fun, and lots of, like, sharing our home with others and meals and seeing lots of people. But it is also exhausting. And they basically all fell on weekends this year, which was nice from sort of a scheduling perspective but was exhausting in the fact that I basically have not had a weekend in over a month. So, it was wonderful and tiring. And I am, I guess, both happy and sad that they're over now.

+ +

VICTORIA: Yeah, that does sound like a lot of quality family time, which has its pros and cons [laughs], right? So, after going through that, do you feel more rested? Or what do you feel like you need to do in order to recuperate and return to your normal energy levels after having every weekend full after that?

+ +

ALLISON: Oh, that's a great question. I've been looking at my calendar to be like, I should take a day off. I should take a break. I'm working for myself and [inaudible 02:02] entrepreneur consultant. So, I do have the flexibility to do so, but it is hard to look at my calendar and be like, yes, I will take this day off because I deserve it. But, ideally, I would take a day or multiple days off.

+ +

VICTORIA: Yes. And some of us are lucky enough to have a reason to travel for work purposes and to sneak in a little vacation and be productive [laughs] in our companies. So, I'm curious, Chelsea, if you can tell me a little bit about the option for people to come to San Diego in November and take a restful vacation by the beach and learn a little bit more about Ruby.

+ +

CHELSEA: Yeah, so RubyConf will be in San Diego this year. As a native San-dieagan, I am a bit biased, but November is a beautiful time to be in San Diego. And we're going to be at the Town and Country, which feels a little bit like we're going to be in a, like, Palm Springs resort. They just went through a major renovation.

+ +

And there's these really awesome, like, lounge areas with fire pits and just places for people to gather, which really kind of aligns itself with some of the stuff that we're planning because we're really trying to focus in on just connecting Rubyists together. So, to me, it feels like the perfect place because I think San Diego is, one, we're a little bit more low key, a little chill. And it's a great place to just gather and connect and share with people that have, you know, similar interests.

+ +

VICTORIA: Yes, I live in San Diego now, but I was from Washington, D.C., And I would come and visit my family in San Diego once a year. And they would always go on about how great it is and how beautiful, and everyone is so happy and chill. And I was like, sure, whatever. And then we [chuckles] had the opportunity to move here, and now I'm one of those people who says that [laughs]. Like, it's great, especially in November. Everywhere else is getting a little cold and fall. And San Diego has a little bit of fall, but it's still 75 degrees out. I forget what that is in Celsius. But yes, I'm also super excited.

+ +

CHELSEA: We have, like, fake fall activities that you can go do. Like, Allison, when you're talking about doing all the family activities and things like that, you know, this is when we start thinking about, oh, we need to go to, like, the pumpkin patch and apple picking and do all these things, but it's not cold or, like, fall weather at all. So, you want to get all, like, bundled up in your cute fall clothes or, like, put my kids and bundle them up in cute things. But then they're, like, sweating and trying to do [laughs] all these funny activities.

+ +

But I think that there's so many beautiful things to do here that we, like, try and do these, like, fall activities. But then we just end up at the beach and play in the sand [laughs].

+ +

VICTORIA: Yeah, I will go out in, like, shorts and a T-shirt because it's that kind of weather. And my neighbors will be wearing full puffy jackets and [laughs], like, long pants and a hat. And they're like, "You're not from around here, are you?" [laughs]. It's like, you guys are silly. But it's fun. Yeah, there's seasons, I think, you know, in November...I made a list of suggested activities for my team members since thoughtbot is sponsoring RubyConf this year. And we're going to have a couple of speakers at the event. And we'll have other thoughtboters available at our booth for people to come up and chat with us. So, I'm really thrilled to be hosting everyone.

+ +

And I made a list of, like, activities, and most of them were about where to see cool animals [laughs]. I was like, of course, there's the zoo, which is the obvious one, but then there's baby leopard sharks, and there's a season for them. I think they will still be around in November; I'm curious if you know, Chelsea, actually. And then there's, like, the safari parks, and whale watching, and the sea lions at La Jolla and, like, just a bunch of cool animals to see that I think it makes San Diego really special.

+ +

CHELSEA: I agree. The zoo, the safari park are great places to just hang out and see some really cool exhibits. Balboa Park, the museums there are amazing. Liberty Station is one of my favorite places to go; that it's an old historic naval training center that's been converted into an arts and culture area. So, they have, like, little shops. They have...there's museums. There's brew pubs. There's coffee shops. And then there's beautiful, like, grassy areas, and right by the water, it's one of my favorite places to just go and hang out.

+ +

ALLISON: This is great. I've done zero research on San Diego so far. So, just, like, I'm writing notes of what things to do and see while I'm there.

+ +

CHELSEA: Yeah, I know the San Diego Ruby group is trying to put together some, like, local events and things that people can gather and do together. I know that there was a talk about doing a taco crawl. I think if I say that on the podcast, it might actually push them to do it because there are some amazing tacos in San Diego to be had.

+ +

VICTORIA: Yes, I love that taco crawl. I'll reach out to them because I'll help put something like that together. I'm writing a blog post right now about all of these things and about all the other kind of events that are coming up in San Diego this fall. Great location, great time of year to be here. Tell me a little bit more about RubyConf specifically. And what are you all trying to do different this year than in past events?

+ +

ALLISON: There are a bunch of things that we're doing differently. Our goal this year with this RubyConf is really to sort of focus on more ways to bring the community together. I think in the last little bit so much excitement around Ruby and Ruby Central and just sort of the community in general. It's a hard time in tech. I think people need to be sort of choosier about sort of what they attend and why they're attending something. And so, we really wanted to help folks connect with each other, help folks get to know other people, help folks sort of reconnect to ways that they love Ruby and the Ruby community and being a Ruby programmer.

+ +

So, one of the things that we're doing differently is we have a three-day conference. And the way that that sort of broken down is the first day is a Community Day. And the first day is comprised of the workshops, as well as sort of this Hack Day, where people can bring their own projects.

+ +

We're going to have people there that folks can hack with, sort of open-source projects that folks can work on, all sorts of different stuff. So that people can really sort of get to know one another, work with one another, work with people that they might, you know, admire or have followed in the community for a while, and have that sort of really special experience that doesn't feel as conference-y, right? It feels a little bit more sort of organic in terms of the way that the day will flow and, the options that people have, and sort of what that day looks like.

+ +

And then following that, we have two days of sort of RubConf with talks and speakers, et cetera. And I'll let Chelsea add anything to Community Day and then also jump into some of the sort of new and different things we're doing at RubyConf.

+ +

CHELSEA: I agree with Allison in that we've really wanted to focus in on the connection side of things. But I think coming out of the last few years, out of even the last year that's been tough in the industry, just finding ways for people to connect, support, lift up each other, I think that that was something we really wanted to do. And we didn't want it to just be about going and seeing speakers. We wanted to find more ways for people to learn from each other, to connect. And so we added in quite a few of these community connection points.

+ +

So, on that first day, there's a lot of community aspects to it. We have a lot of learning happening with our workshops and also working on projects, hacking together, showing off what you're working on, connecting with people in the community. It's going to be really focused in on everyone's own skills and talents and coming together and supporting each other in where we're at in our careers, in our learning.

+ +

And then, the next couple of days will look a little bit familiar in the way that it is structured with some new aspects kind of woven in. We'll have our Community Room, where we're bringing different community groups together so that people can learn more about what is going on in the community, how they can support, how they can connect.

+ +

And in addition to seeing and learning about some of the new things happening in the Ruby community, we'll also have our Career Pathways room again, which will be a place for people to support their own careers. And that room was really set up so that it wasn't just about early career, but also about folks in their mid and senior careers, and finding the advice, finding the resources, finding the mentorship that they might need in whatever stage of their career that they're at, and figuring out how we can together as a community grow as a whole.

+ +

VICTORIA: I really appreciate the focus on community. And, for me, as managing director at thoughtbot, in deciding to invest in which conferences we want to attend and sponsor, we find more value in groups that are trying to bring people together around a common passion and purpose versus a particular product.

+ +

But I'd like to hear from each of you if you can tell me, what does the community mean to you? And I'm looking for, like, a personal story on how you've benefited or how you've engaged with the Ruby community in the past. And what makes you motivated as CEOs and founders of your own companies [laughs] to spend all this time organizing a conference?

+ +

ALLISON: Many, many, many years ago, I did a Rails Girls workshop. It was actually my first introduction into the tech community, into programming in general. And, for me, really, I did Rails Girls. I did not actually expect to like programming. But I was sort of launching a startup, and I wanted to learn more about tech and blah, blah, blah. And at the end of the day, I was, like, so energized and so excited about what I had built and what I had done.

+ +

The Ruby community in D.C., who I always think is just a group of really special individuals, was so supportive, was so wonderful, was so, like, "Here's where we co-work on Wednesdays. Come to this coffee shop. Here's how you can keep learning," just was so encouraging. You know, I went to the local Ruby meetup sort of really not knowing anything. And they were excited about, you know, newbies being there and asking questions and, you know, really sort of getting to know folks who are just starting out in their programming journey.

+ +

And really, through that, I mean, I went to my first RubyConf as a scholar. Was strongly encouraged to do a lightning talk, did a lightning talk. That's how I, you know, sort of ended up having a whole bunch of informational interviews and having conversations with folks. And really, that's how I got my first real job in tech. And so, you know, I want people that are coming into the industry now to have that same support, to have those same opportunities, to have that same encouragement.

+ +

And, for me, sort of planning RubyConf, planning these conferences, being a part of Ruby Central is really me giving back to the community that has gotten me to where I am today, right? And it's amazing, also, to just...I'm still in touch with the people that were at my table, sort of guiding and mentoring at that first Rails Girls session or the people who I met at the first-ever Ruby meetup that I went to.

+ +

I still talk to them. I'm still in touch with them. We still get together. I still ask them for, you know, advice and guidance sometimes. And sometimes, they ask me, at this point, for advice and guidance, which is fun. But yeah, it just means so much to me that I have really been able to get to where I'm at because of the support and encouragement of the community.

+ +

CHELSEA: I have a similar story. I guess over, gosh, over a decade ago, I also went to my first RailsBridge and got introduced to the community there at RailsBridge. And, you know, at the time, I wasn't in tech. I was in the theater. I come from the performing arts. I had spent a very long time executive leadership in the theater. And I got introduced to this community that was so warm and welcoming to people wanting to learn and grow. And I was so interested in how communities are built and how people connect together that I started getting more and more involved in the Ruby community here in San Diego.

+ +

And just like Allison was saying about the welcoming and warmth that she felt from the D.C. community, I felt the same way here in San Diego. Before that, you know, I had spent so many years being the only woman in a room. I had been in an industry that made me feel like my voice was not always heard. And when I walked into this room, I felt like I mattered. I felt like people wanted to hear what I had to say. And they wanted to learn from my experiences.

+ +

And in 2014, San Diego hosted RubyConf here. And at that point, my business partner and I launched our business, LEARN Academy, and it's still running strong today. But it was about creating that on-ramp for people and a launchpad into this industry where they could make a difference and they could have their voice heard. And they could be a part of a conversation, even if they hadn't been a part of that community for many, many years, that their background mattered, that their growth mattered.

+ +

And helping people find their voice at a table is something that is so important to me that I love being able to bring that into the planning of this conference, into a lot of the work that I've done with Ruby Central, with LEARN academy. And really just helping people understand that just because you don't have the traditional background, maybe you didn't start programming at the age of two, you can have a different background and a different path and still provide so much value.

+ +

And I think that that is the thing that I wanted to continue to be a part of and to make sure was a part of the conversation, that we need so many different types of people at the table. And I want to make sure that our community is responsive to that, that it's inclusive to that, that it's equitable as best we can, and just allows people to share their own experiences. And so, you know, I feel like, for me, we're, you know, almost at our 10-year mark at LEARN academy and that we were launching the company at RubyConf in 2014. To have it here again this year is so special to me.

+ +

I remember being at the conference many years ago; you know, we spend a lot of time helping companies figure out how to work with early-career developers and to create those pipelines for them so that there's career growth for them. And, you know, I remember sitting around the table and just saying, "Hey, who wants an internship? Who wants to, you know, help these early-career developers?" And everyone raised their hand, and we found some of our very first partners at that conference. And it's always been such a warm and welcoming community that has allowed me to feel like I have a voice and then allows me to help other people find theirs.

+ +

VICTORIA: Wow, thank you both for sharing that. I totally relate to that feeling of a welcoming community and just getting the sense that, like, wow, everyone who does Ruby is really nice [laughs]. And I think that you know, for me, same as Allison, starting in D.C., there were quite a few people who were involved in Women Who Code who were running Ruby meetups. And that's where I met Valerie Woolard, who I think is also coming to San Diego for RubyConf. I'm excited to see her again.

+ +

And it's interesting for me coming from that perspective and hearing that from both of you because I've also heard a viewpoint on Ruby community as being highly opinionated and causing certain amounts of consternation. So, I'm curious if you have any comments on that. If not, otherwise, I'm grateful that there are people working to bring that better community in the community that I'm more familiar with more to the forefront and making it more inclusive and open for everyone.

+ +

So, to, like, bring the question all the way back, it's like [chuckles], do you have any comments on, like, if there's a tendency for Rubyists to be really highly opinionated? Or what else can we do to make it more open and inclusive for people to join the community?

+ +

CHELSEA: I mean, I think that people are going to be opinionated about something that they care a lot about. And I think that the thing that I've noticed in the Ruby community is people love this language. They love programming in this language, and I think that there's something very powerful about that. And it does, you know, lend itself to people [laughs] having very strong opinions about what they think needs to be out there.

+ +

And, to me, it's not a matter of, like, whether we have strong opinions or not. It has more to do with whether we're listening or not. But I think it's really important for those of us who are leading to be the listeners, and that we should be there to make sure that there is space for people to be heard, whether their opinion is loud or not. And I think that there are people that are going to be louder than others; that is going to be true no matter where we go.

+ +

But I think that as long as there is intention around making sure that we are listening to even the quietest voices and that we are creating space for the quietest voices, that's where we're going to find more collaboration. But if we're only going out there and saying, "This is the way it needs to be," and we're not willing to listen to anything else, then I think that growth will stop happening because we need to listen to everyone. We need to be able to create some kind of place for people to come together and share ideas; you know, you don't get the perspectives of all these amazing people in the industry.

+ +

So, that's why I feel like, you know, I've been on the board at Ruby Central for about a year now, and the biggest thing that I feel like I can contribute is to simply listen. If I can help in any way of filtering ideas or creating connections with people because I've been putting my ear to the ground and saying, "Okay, these people are talking about this, and we're expanding here." And we just want to make sure that we're doing the best we can at being open to all different kinds of ideas and not closing anyone off.

+ +

Maybe your opinion is really strong. It doesn't mean that we should shut you down. It just means that we need to make sure that there's space for other people, too. And I think that that's the part that, you know, as someone who has always been a bit of an introvert, a bit of a wallflower, I understand how hard it is to get my voice out there. And so, I often fight for the quiet people. I think in every language and any space where it's a craft, it's something that we're creating, people get really passionate about it. And that's going to happen. And I think there's something powerful in that because there's going to be change that happens from that.

+ +

But if we're not doing our part in the listening and making sure that there isn't just one voice, that there's a collective voice, that's the part that I felt so powerful when I joined the community so many years ago was that, even though I had, you know, months of experience, my questions mattered. And as long as we hold on to that, the community will continue to grow.

+ +

But those of us at Ruby Central and some of the other organizations, if we're creating space to allow people to question, allow people to speak their opinions and listen, then I think that the industry, the community will just continue to thrive because of that. But we have to be open, and we have to be compassionate when we're doing our listening.

+ +

ALLISON: Yeah, I agree with all of that. And I would just add in safe places, in a way that we're creating sort of safe structures and safe places for folks to communicate.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: What, if you could tell me, what does Ruby really have going for it? Like what makes Ruby a good choice for tech founders or for new companies would make someone decide they want to build with Ruby?

+ +

ALLISON: First, it's a little bit about just sort of the ease of the language to jump into and to understand, right? There's a lot that you can get done very quickly with Ruby and Rails. And in addition to sort of individuals being able to work in it, there's a whole community of resources, and support, and podcasts, and tutorials, and all sorts of stuff.

+ +

I know that as an engineering leader at any company, when engineers are coming to me with, like, the desire to use a new language or try something new, part of what I look at is, if I'm going to hire, like, what would hiring look like? What does it look like for engineers to have to ramp up in this area? How long does that take? What resources are available? What sort of community am I pulling from and looking at? And that's both community in terms of sort of technical experience, expertise, years, et cetera, but also non-technical skills, right? What does the community look like in terms of some of those ideals around communication, collaboration, just sort of general pieces like that?

+ +

And so, I think that, given sort of the strength of open source, strength of community, community contributions, ways to contribute, etcetera, I think that's one of the reasons that it still makes Ruby a really strong choice for folks to build in and to work with.

+ +

VICTORIA: What type of people, what personas do you think will be the most interested in attending RubyConf? Is it all just going to be, like, senior or super Ruby developers, or what?

+ +

CHELSEA: Oh, I don't think so. I mean, this RubyConf, in particular, is great for anyone on a learning journey. We've worked really hard to make sure there's a good breadth of programming for different folks in different stages of their careers. I think that, you know, those of you that are maybe earlier on there, this is a great opportunity to meet people who are maybe even a step or two ahead of you. I think that the best mentorship that you can find is someone who is only maybe a year ahead of you because they're going to recognize where you're at and help you along the way. And I think that there's a lot of opportunities here for that.

+ +

I think that with our Community Day, the hacking that's going to be involved, like, maybe, as a new developer, you wouldn't be able to come in and, like, get your hands really dirty. But you'll get to sit next to somebody who has been through all the different stages and get to watch, and explore, and learn. I think that making those connections could be really great for anyone's career. I think that our mid-level developers, folks that are our management, there's great resources for them to connect with other developers in similar stages. There's great workshops.

+ +

Because of our focus on the community, I think that it's going to be a place where you can really connect with other Rubyists. And so, if you are at a stage in your career that you want to figure out what that next spring is, where that next ladder step is, this is a good place to see all the different options because you're going to be surrounded by people in all different stages of their careers.

+ +

And what we've, I think, said now quite a few times is so many people there are just so excited to help people continue that growth. And so, I think that no matter what stage you're in, you're going to find people there that are excited to help you along the way.

+ +

That being said, I think for our more senior, more advanced, our executive leadership, this is going to be a great place to, one, meet some really great talent, and, two, I think, learn from other folks in the industry of, like, where people are at, what we're struggling with, and how we're changing and doing things differently.

+ +

So, I really do think there's going to be a little bit of everything for people. And what I love about that is really that it gets to the core and heart of the Ruby community because we're so excited about new folks coming in that that growth continues, that you have folks like Allison who started out as a scholar and want to give back.

+ +

And then because we have folks at all those different stages, you can find people that are, you know, maybe a step or two ahead of you that are going to be able to help bring you up to that next level. So, I think it's an exciting opportunity for people to really meet new people, learn some new things, maybe find a little bit of encouragement, empowerment on where you're going to go next on your career.

+ +

VICTORIA: Yeah, absolutely. And it reminds me of an article I read while I was at RailsConf earlier this year about why we do conferences and what's the whole point. And, you know, for me, all of those things are true, like, all those values. As an executive, I'm going to meet a lot of great talent. I'm going to connect with other companies. I'm just going to get to show up and say hi to people and ask them questions in a way that's very informal. And that's so valuable to have that.

+ +

I think where I was going to go next with this was with Ruby Central, which I believe organizes both RailsConf and RubyConf. (And you can correct me if I'm wrong on that.) I'm curious if there are anything else you want to talk about with, like how the community can engage in support and how other companies could get involved with the community and show their support.

+ +

CHELSEA: I think that there's quite a few different ways for folks to get involved. We are currently recruiting board members. We just finished a round just now. But I know that in our planning, that we're likely going to bring on at least one, maybe two more, in the next six months. So, I definitely...for folks in the community that want to get involved, that is a really great place to really get involved with Ruby Central.

+ +

We also have a really strong open-source community. And we're working, oh gosh, with quite a few different companies now that are really helping to support our open-source efforts. And those are also good ways to get involved. You know, we do plan both RailsConf and RubyConf. RailsConf will be in the spring again. And, you know, it takes a village to put on a conference like this and that, you know, we also look for programming committee members to help us shape the program of the conferences. So, if you are interested in any of that, that's also another great way to get involved in the community.

+ +

We have an amazing programming committee that's helped us with RubyConf. And I'm excited to see what we do next with RailsConf. And I think that you know if you're one that's going to the conference and are saying, "Man, I wish that they would do this," or "I wish I could see that," come and talk to us because that's the best way for us to learn, that we want to hear all of those pieces. But don't be surprised if we then send you an email and say, "Hey, you want to be on our programming committee with us?"

+ +

ALLISON: I'll add that we also, through our website, we take donations. So, if you want to help monetarily, there's the option to do that on the website. And if you're a company, I mean, we're always looking for conference sponsorships. But if your company also is interested in getting involved in sort of more of a corporate sense of sponsoring or supporting Ruby Central, we are always open to those conversations. You can send an email to contact@rubycentral.org.

+ +

VICTORIA: That's great. I have a fun question about the conference because I'm leading the event with thoughtbot since I live here. And I'm thinking about some fun swag to give away. Rank your preferences on what kind of swag you'd like to see at the thoughtbot sponsor booth: a thoughtbot-branded surfboard or, a boogie board, a bucket hat, or a pickleball paddle. Any of those interesting for you?

+ +

ALLISON: Wait, when you say surfboard, like, how am I going to get a surfboard back to D.C.?

+ +

[laughter]

+ +

VICTORIA: Okay. I think it's, like, kind of funny because if you win it, it's like, well, what do you do? [laughter] You got to shake it back. That sounds like maybe a boogie board.

+ +

CHELSEA: Yeah, I'm down for a boogie board.

+ +

VICTORIA: Thank you so [laughs] much for entertaining me on that one. Is there anything else that you would like to promote today?

+ +

ALLISON: We would love to see everybody at RubyConf. You can register. Check out the program speakers, et cetera, at rubyconf.org. You can learn more about Ruby Central at rubycentral.org. Those are, I think, the two things that we'd love to make sure everybody knows about.

+ +

CHELSEA: And if you're here in San Diego, come say hello.

+ +

VICTORIA: Yes, I have met up with a few random people from the internet [laughs] who have said like, "I'm in San Diego. Who should I say hi [inaudible 34:02]?" I was like, "Me, me, me," [laughter]. So, yes, I'm very happy to meet up for drinks. Chelsea, you and I will have to get together sometime soon before the conference. And I'm super excited for RubyConf. And thank you both so much for being here today.

+ +

ALLISON: Thanks for having us.

+ +

CHELSEA: Thank you.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantsrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Allison McMillan and Chelsea Kaufman.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+UsYKVEU8 + + ]]> + + Victoria Guido + Allison McMillan + Chelsea Kaufman + + + thoughtbot's Incubator Program Mini Season - Episode 04: AvidFirst with Ashley Sheble + https://podcast.thoughtbot.com/incubatormini4 + f8604f7e-6577-459c-947a-6e8d29496edc + Wed, 01 Nov 2023 00:45:00 -0400 + thoughtbot + + full + 12 + thoughtbot + Dawn Delatte, Vendela Colavecchio, and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product. + +The discussion covers various aspects of the program, including the evolution of the product idea, insights gained from industry conferences, the importance of listening to customers, and the ongoing development of the go-to-market strategy. Everyone emphasizes the value of the Incubator Program in helping founders connect with their market and refine their strategy. + 28:23 + no + + + Dawn Delatte, Vendela Colavecchio, and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product. +The discussion covers various aspects of the program, including the evolution of the product idea, insights gained from industry conferences, the importance of listening to customers, and the ongoing development of the go-to-market strategy. Everyone emphasizes the value of the Incubator Program in helping founders connect with their market and refine their strategy. +Just catching up? Listen to Part I (https://www.giantrobots.fm/498), Part 2 (https://www.giantrobots.fm/499), and Part 3 (https://www.giantrobots.fm/501) of the Mini Incubator Series! +Follow Ashley Sheble on LinkedIn (https://www.linkedin.com/in/ashley-sheble/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +DAWN: Hello, everyone. So, since we have a bigger crew here today, slightly bigger crew, we should just jump right in, right? +If you're not familiar with thoughtbot, we're a design and development consultancy who create and build products from the very earliest stages. +We are currently in our second incubator session. This is actually our final week. We're wrapping up this week our second program with Ashley at AvidFirst. And I'll let everybody go around and say hi and give a little intro. +Today, we're going to be chatting about how the program has been going, any new recent activity, and things that we've learned and done, and, you know, what's going to happen here after the session ends. +I'm Dawn. I am a Managing Director here at thoughtbot. And I will shoot it over to you, Ashley. +ASHLEY: Thanks, Dawn. And my name is Ashley Sheble. I'm the CEO and Founder of AvidFirst. AvidFirst is really focused on helping people save and spend for college in a modern way. We're simplifying the process, modernizing the experience, and really, with the end goal of helping families avoid student debt. +So, I've been working with the thoughtbot team for the past eight weeks, really refining our strategy, and we'll talk about this here in a minute. But pivoting a little bit on the strategy just based on what we learn from the market from talking to users, from talking to experts, from talking to people with just insight around what's needed in the space. And so I'm excited to share more about the past eight weeks. +DAWN: Awesome. Thank you. Jordyn, do you want to hop in? +JORDYN: Sure. I'm Jordyn Bonds. And I'm the Director of Product Strategy on the Ignite team. And I am a two-time former co-founder of tech startups, so whence I come to this work. Vendela, I'll let you go. +VENDELA: I'm Vendela Colavecchio. I'm the Design Director on our team here running the incubators at thoughtbot. And yeah, should I talk about my role on the incubator [chuckles] more? +I guess the incubator is sort of funny because, you know, as a designer, typically, my tasks fall under more of a traditional design category. But I think with the incubator, we're, like, all hands on deck, just trying to get lots of things done and help out in any way that we can. So, definitely some design things, but also just a bunch of participating in discussions and getting all sorts of tasks done. +DAWN: I'm sure we'll dive more into that. As usual, though, we're going to let Ashley kick us off, kick our discussion off with a little bit of an update on what's been going on in these past two weeks since we last chatted and, you know, where we are now. +ASHLEY: Yeah. So, the past couple of weeks have been pretty exciting. I went to an industry conference. It was a 529 and ABLE conference. So, 529s are tax-advantaged savings accounts specific for education expenses. ABLE accounts are tax-advantaged savings accounts, specifically for people who have a disability. And so, spent a week learning from experts in both spaces, hearing from all the different stakeholders, so state agencies, program distributors, you name it, every sort of stakeholder in the whole industry was there. And it was amazing to just be able to go in and learn and meet people and hear their perspectives around what's going well, what's not going well. +It could not have been more well timed because I think had the conference been earlier, I might not have been ready to ask the right questions from the different stakeholders. And had the conference been later, well, we couldn't have used any of that insight and learning to continue working on refining or pivoting the project. So, it was a great experience. People were so collaborative, so helpful. +I think it's interesting that my perspective going in was, oh, people aren't going to want to talk to me. They're not going to want to share their insight. But it was quite the opposite. People were really happy to talk about what they thought could be improved or what they thought seemed to be going well. But it's only from one perspective. So, if you start asking questions around what you've learned from other people's perspectives, you kind of see this, like, aha moment. Like, oh, I hadn't thought about that before. Maybe that's something to consider. So, it was an amazing experience. +So, as a result of that particular event last week, have really been synthesizing what we learned, filling in any gaps. And then just using that to think about a different strategy based on kind of the signals in the room, what people were really excited about, and what people really thought needed some work versus what we went into the conference thinking was the right answer, if that makes sense. +DAWN: That's so exciting. Can you tell us more about this pivot? You mentioned a pivot. +ASHLEY: Yeah. And I wouldn't call it maybe a full pivot. I would say it's more an expansion on the work we've already done, which is good. So, we're not just throwing away all the work we've done for the past seven weeks and saying, "Forget it." +There are a lot of parallels in the 529 space and the ABLE space. A lot of the stakeholders are the same, and it's just a different target market with a little bit different need set. And so, really trying to understand what the differences are, and what the similarities are, and how we can replicate the work that we've already done for one space in the other space, and then build upon that a lot more rapidly than it took us to build the initial work for the 529. +So, there's definitely some advantages that the two industries are really intertwined. But at the same time, there are some differences that we need to be keenly aware of and making sure that we're solving a problem meaningfully. +DAWN: Jordyn and Vendela, how has this, not pivot, but new expansion or new strategy, how has this affected your work? +VENDELA: What I'm thinking about on sort of a meta-level is how it's exciting to see that this new angle doesn't really change how we would approach the problem in terms of just running the incubator. So, it's almost, not in a discouraging way, but it's almost just like starting back from week one and kind of going through, what do we know? What do we need to find out? What kind of questions do we need to ask stakeholders, et cetera? +And just seeing how having done that already together it makes it pretty clear what the path forward would be in terms of the process. In terms of information, who knows what we'll find out? But I think that's been exciting. The pivot doesn't feel so scary as it might sound [laughs]. +JORDYN: Yeah, I would just build on that to say that it's giving us this really awesome opportunity to immediately run the same process that we just ran but, like, to see how much we've learned from doing it the first time. It's like you're starting over, but you're starting over from a better place, right? With more skills, way more understanding of sort of what's important and what's not important. +And, you know, once you've run the process at least once, no part of it feels daunting, right? It just feels like work you know how to do, so it's like, okay, this is a really interesting additional sort of adjacent opportunity. We need to very quickly itemize all the things we don't know about it, and then figure out how to learn about it. Is it research? Is it interviewing? Is it testing? But none of those things feels unknown, right? It just feels like you get to do it faster and better. +This is, like, a thing, you kind of can't convince someone without them having done it. And a lot of folks come to us, come to thoughtbot with a product idea. And we tell them like, "Okay, let's get in there and validate and invalidate things." And they're, like, "Invalidate? [vocalization] I don't want to invalidate my awesome, precious product idea [laughs]." And what we know that they don't know is that there are pieces that we're going to validate and pieces we're going to invalidate, but always you uncover new opportunities in that process. And you're just better and better at ascertaining what's promising about those things. +So, it's only upside, but it feels like we're asking them to let go of something or to lose something, right? There's a feeling of like, it's like a scary...it's a feeling of like, I've built something, a tiny thing of value here, and you're asking me to risk that. And that couldn't be further from the truth. But it's, like, a really hard thing to convince someone until you've done it once. So, it's very fun, anyway, that we're getting to do this within one incubator cycle. Usually, it's, you know, it doesn't happen that quickly. +ASHLEY: I like how you qualified that as fun. I will say...and Vendela and I were talking yesterday, and we were going through the sprints around, not starting over but beginning at the beginning with this new angle. And I was having the emotional rollercoaster of, like, what are we doing? Oh my gosh. And then, oh my gosh, this is so exciting. And then, oh my gosh, what are we doing? +I feel very equipped now, having gone through this process once, to have the tools, the skills, the mindset to know, okay, it's part of the process. Here's what's going to happen. Here's what we'll probably learn. And just have a very structured way of approaching a new idea or a new angle, versus feeling like just thrown into the deep end and trying to figure out how to swim or which way is up. So, that's been pretty encouraging and eye-opening, too, that I developed all these skills that I didn't realize I had developed till we started redoing this, which is exciting. +DAWN: I love that. It's kind of a testament to how valuable time spent is and how important it is to become really, like, more efficient with this process and the value of sort of rapidly being able to validate or invalidate different assumptions. I imagine that this might be a little bit different than what you expected. As Jordyn was saying, [laughs] most founders don't, you know, expect to have to loosen the grip on specific ideas. So, now that you're at week eight, how has this experience been overall for you? +ASHLEY: It's been incredible. First of all, just the talented team that has been working on this project with me, I cannot say enough good, nice, positive things about that. I've heard horror stories about people working with teams that there's just a lot of dissension. There's lack of trust, all those things. And we had none of that, which is incredible. So, I feel very fortunate to have been with the team that I was with. +I will also say that everybody had different strengths. And so, we're looking at an opportunity or a problem from a different lens in four ways, which is amazing because then you can cover so much more ground so much more quickly. I will also say, too, just the process: the thoughtbot program has for the eight-week structure is so intentional because sometimes I would think, well, wouldn't it make sense to do this thing before this thing? But just trusted the process, and the process was right. +So, I would just say anybody that's thinking about going through the incubator or goes through the incubator next, just trust the process because you guys have a portfolio of success. You know what you're doing. I'm a testament to just really endorse the fact that each step is necessary in getting to the next step in a successful way. So, you're not taking two steps forward, one step back. You're constantly making forward progress. +DAWN: That's awesome. What about you, Vendela, and Jordyn, how has this program and this session been this time around? +VENDELA: I can talk about my experience as the first time going through the incubator, and then maybe, Jordyn, you have some insight on comparing the two or how you think it went in general. +But I think one thing that has been really fun to do and participate in, and to Ashley's point about kind of having this environment of trust and just counting on each other that we're all distilling the information that we're hearing, I guess, accurately or in a way that aligns with how the rest of the team would perceive these things, is that we've had these really cool moments of not feeling like we 100% with complete certainty know exactly how something looks, but being creative about how we might get closer to that point. +So, hearing a few tidbits here and there, thinking of ways that we're reading between the lines and interpreting that, and thinking about how we can narrow who we're talking to or approach the conversation slightly differently, so adjusting our script, or running some kind of other experiment, or structure things differently. And then, we might find that that angle wasn't exactly right, but by pursuing that angle, we learned something new that actually did get us closer in some way. And I think a lot of that was subtle throughout the process. +But now, just thinking about this new kind of topic or pivot, whatever you want to call it [laughs], that we're pursuing, I think that lesson is going to be really valuable for Ashley moving forward, too, and just thinking, okay, I feel like what we're trying now isn't getting any closer. What have I heard that I could just grab, like, a small piece of string and pull on it, and see where that goes, and unravel something, and hopefully learn something new? So that there's just consistent kind of learning and not feeling like you're just totally blocked at any point. +JORDYN: Yeah, to build on that a little bit, there's a real quality with this early work of just starting with what you have, where you are. And, you know, you don't have everything you need, like, you just don't, not in life and certainly not in [laughs] startup land. But the question is, like, figuring out what you need and figuring out how to get that from where you are. And that might be validation of a hypothesis you have, or it might be resources that you need that you don't have yet. +And so, a lot of the work that we did together is to identify those things and to figure out ways to get them. And it's a real creative process because every problem is different. It's why it's really hard to talk about the programming in a specific way. It's like, you know, broadly, we're driving at the same outcomes every time. But every problem space, every industry requires a kind of different set of approaches, and, to me, that's really fun. +It's like, okay, imagine as a metaphor, you know, that you are dropped from a helicopter into a jungle in Central America versus into Mongolia. Like, what you're going to need to survive in those two [laughs] environments is probably going to be pretty different, right? But that doesn't mean that your strategy for figuring those things out is going, like, the tactics you employ will be different. Yeah, I'm glad to hear, Vendela; that was a fun aspect of this. +And sort of jumping off from that point, what was different this time? It's always different running this program. And every time, there's something new and different. But this was the first time we've run it with a FinTech product, and just learning about that ecosystem, the players, and the complex landscape of incentives and motivations, et cetera, was just, like, there was a steep learning curve for us at the beginning. And it was just super interesting and helpful to sift through that. +It was like being, you know, dropped from a helicopter into a new sort of ecosystem. And we were like, all right, like, which berries are poisonous here? I don't know. But I also know that I need to eat something to survive [laughs]. So, it's like those kinds of questions, which is just super interesting. +And then, what it always causes me to do is look at my own network anew. So, often, we find ourselves talking about, like, this question of starting with where you are with what you have. That includes with the network you have and the people you know. And it really depends on the problem you're solving, who you tap for what questions, right? And, suddenly, like, every one of these that we run, I get to turn to my own network. And I find new reasons to talk to different people about different things in my own network, which is really fun. +It's like it allows me to get to know people in my own life in a new way. Like, every time this happens like, one of the first things we do is we turn to our own networks. Like, who do we know that has this problem or works in this industry, whatever? But having never worked on a FinTech product before, I didn't really need to do that with this lens. And it's like a whole new set of people lit up for me, and I got to have really interesting conversations with them. So, that was one thing that was different and really kind of fun. +ASHLEY: It's funny to hear your take on the FinTech complexity because I feel like every time Vendela, or Jordyn, or Dave, who's not here, would ask me a question, it was, well, here's the answer, but if this, then that, or if this other thing, then that. It was never just a straightforward answer. +And I was like, oh my gosh, they're just going to throw their hands up in the air at some point, but never did. They were just like, cool, that's fine. We'll figure out these different pathways, and if this, then we'll do that, and if this other thing, then we'll do this other thing. And I was just blown away by how nimble the team was and willing to just embrace the complexity. So, that, for me, was a huge positive. I don't know if you'll ever want to work in a FinTech product again; maybe yes, maybe no. +DAWN: I would argue that we're more prepared now. You know, we've done a lot of FinTech work in the past, but applying this framework to understanding it as quickly as the team needed to, I'm sure, sort of pushed everybody farther, faster. So, Dave -- +JORDYN: Yeah, I should say that was specific to me. thoughtbot has done plenty of FinTech work, Jordyn has not. But also, to your point, Ashley, like, I would love to actually. Now I'm like, oh okay, I kind of understand where the opportunities are here. I feel more prepared now rather than, like, more daunted. +ASHLEY: Well, and you have a huge network in the FinTech space. So, that was something that was hugely helpful to me was talking with other founders who have been successful in the FinTech space, or people who have exited and had a great experience, or maybe people who have exited for, you know, reasons they didn't choose. But it was so important to hear from all those different perspectives and say, okay, here's what I would want to replicate, what I would definitely want to avoid. And so, anyways, just the network that Jordyn and others had and were willing to share with me was so valuable. +DAWN: I was going to quickly shout out to Dave, who was sick this morning and wasn't able to make it. We were going to have him join. He was the senior developer in this sort of product pod that you've been working with. And I'm sure he has some interesting, more technical perspective to share. He did write a blog post, I think, maybe after week four, that I'm sure has some of those insights in it for folks who might be interested in reading from a developer's perspective. Yes, this is all wonderful to hear. +I am curious to know what's next for AvidFirst. +ASHLEY: Yeah, continuing on. There are a couple of things to pilot. And so, that's really the next step, pilot MVP as we think about this new angle. Because we want to make sure that the solution in mind is actually the solution that's needed. And so, those are the next steps, and then capital raise and then off to the races. So, if there's anybody listening that is interested in teaming up or wants to talk or contribute, would love to have a chat. +DAWN: Is there anything that we can help with, anything on your mind, more network connections? [laughs] +ASHLEY: Oh, gosh, offhand, I feel like I would be over-asking at this point because you guys have been beyond helpful. I really think the framework that I have to work with going forward—the team helped build a plan for here's what to do next, here's what to do after that, and here's what to do after that—is really setting me up for success as I think about continuing this journey without the amazing team day in, day out. +JORDYN: Well, you have us as a team for life now, sorry. So, anytime you need something, [laughs] you can call. +VENDELA: I was going to say I hope that you stick around in our Slack channel and update us on what's going on because now we're super invested, and we definitely want to hear how you're doing. +ASHLEY: Yeah, absolutely. +DAWN: Vendela and Jordyn, we've got another application window happening right now about to close for the next incubator session. Who should apply? What should they expect? +JORDYN: Anybody with a business idea that involves software. The earlier, the better. And a lot of people, you know, come to us and are like, "Well, I have this idea that I'm kicking around for years in my head, but I haven't done anything yet. You know, what do I have to do to apply?" And we're like, "Sounds good. Apply." +And then, other folks who are a little later, you know, and they feel like maybe they've hit some doldrums with an idea that they've explored a little bit. But they need a little bit of sort of reinvigorating and, you know, like a spark to get going on it. That's also a good time. We're really sort of excited to hear everybody's ideas. And the only, you know, downside is that we get more applications than folks we can work with. And there's always, like, a lot of great stuff in there. But everyone is encouraged to apply. +You know, we used to have somewhat of a, like, non-technical founder. And when we first started, that was kind of the premise was, like, if you're a non-technical founder, we'll be your technical founding team. But I think we're finding that we kind of round out any skill sets in a way. If you bring a technical background, we can help you with the sales, and the marketing, and the business strategy. And if you come with those things, we can help you with the product and the technology strategy. It's the early-stage work, and the early-stage work is the early-stage work, regardless of your background. We can help fill in those gaps. +ASHLEY: Yeah, I'll just add, too, I came in with this pitch check. I'm like, I'm ready to go, you know, we just need to build this thing. And, wow, the idea has changed so much since eight weeks ago. And so, I would just say, too, like, be open to feedback, be open to where the experience takes you. Even if you do have a really well-researched idea, there's always opportunity for improvement based on what the market says. +And the market is constantly changing. And customer needs are constantly changing. And so, if you're not evolving with that experience, then you're going to get left behind or build a product for no one or, you know, a product for everyone is really a product for no one also. So, being open to the team's input and process is just invaluable no matter what stage somebody is coming into this with. +JORDYN: That makes me just so happy to hear. And I will add that, like, I cannot stress enough that mostly what this program is for is to help folks connect with their market. Like, we actually don't want you to listen to us. We want you to listen to your customer all day, every day. How can you make sure you're moving with those folks, evolving with them, speaking their language, addressing the pain points that they have? Because that's why you're doing this, not because of what you think alone or what we think as your product pod. It's really what the market is doing and what your customer base is doing, and thinking, and feeling. +And really, the programming is sort of geared toward helping people understand how to do that work. Like, you might conceptually understand that you need to do that. As a first-time founder, I certainly, you know, I had read the blogs, man. I knew I needed to be, like, customer-centric or whatever. But, like, I didn't really actually know how to do that. And once I did talk to some folks, it was a whole other new skill set to figure out how to listen for the things that mattered in what they were saying to me, right? +Translating, you know, what folks are telling you and how they talk about their life and their work into product opportunities and innovation, it's a whole skill set that I, even coming into this work, you know, as a first-time founder with the background I had, I didn't have that skill set. You know, most people sitting out there would not argue, like, of course, you need to listen to your customer and move with the market, et cetera. But the question of, like, how to operationalize that [laughs], you know, is a completely opaque thing sometimes. Even for folks who have, like, done it before somewhat, it can still remain challenging. +ASHLEY: Yeah, I feel in a better position now to continue keeping pace with the market. Because if you look at FinTech, historically, there were major innovations every ten years, and then that pace changed to every couple of years, and then it changed to every one year. And now you're seeing FinTech innovation accelerated to every few months; the landscape is different. And so, the solution today may need to be different in six months, or three months, something like that. But I feel like I have the tools now to keep up with that pace of change, whereas before, I would have been left behind. So, I feel really grateful for that. Thank you. +DAWN: That warms my heart. We do have a question. So, does thoughtbot help with go-to-market strategy, or is the incubator more focused on zero to MVP? +JORDYN: You know, I'm full of very spicy takes. Spicy take here: you're always going to market. Zero to MVP is different than go-to-market? I'm sorry, how? So, the answer is, like, absolutely. And really, what you're doing is perennially going to the market [laughs]. You're making a go-to-market strategy. You're keeping that fresh. You're keeping it new in the same way that you're keeping your products and technology strategy fresh and new, given what you're learning and what you're hearing. +So, absolutely, I would say that's actually primarily what the incubator is for [laughs], and then making sure that those strategies are aligned. So, like, one of the things that I've seen in my own work at multiple startups, not just my own, is that those things can become disconnected as your team grows because people have different backgrounds and different...they just have a different focus, right? Your head of marketing has a different focus than your head of product and has a different focus than your head of technology. +And keeping all of those strategically aligned and focused on the same customer and the same problem set is a lot of the work of an early-stage startup. And that's, like, a lot of the work that we kind of help founders figure out how to do. How do you tie your go-to-market to your MVP? Like, how do those two things fit in together, right? And how do you keep them in sync? It's not merely like you do this one time and then everyone goes their separate ways [laughs], and in 18 months, you meet back again and have a conversation about it, like, [laughs] not how this works. So, I mean, absolutely. +VENDELA: I would add to that, too; I think something that we talk about with all these types of projects is just...and, internally, we talk about this a lot, too, like, we kind of hate the term MVP because it's so ambiguous really. Like, what does that mean for any given product? And so, I think, to your point, Jordyn, like, the going to market and the MVP are so tied together because the whole point of an MVP is to learn something so that you can then bring it from a minimum viable product to something more than that. +And we talk a lot with founders about different approaches to MVP. I think some people have maybe a narrow view of what they can be. It's this, you know, maybe slightly lower fidelity but coded custom thing. And there's lots of ways to approach it that don't fit that definition and maybe would work better as a way to experiment and learn something, and then create a new version later on. So, you know, with that first version, you can still go to market, but you're learning something, and then you're maybe building a new MVP after that. And so, making sure that that's not too precious or hard to throw away is something, I think, we tell everybody, too. +DAWN: Yes, that's great. Cool. Well, I think it's about time for us to wrap up. Thank you so much, Ashley. It's always an honor to kind of watch the team work with different founders and see them sort of learning as they go and seeing the product and the opportunities evolve. And it's been really great to be able to participate a little bit more this time and chatting with you and hearing about how things are going. +I'm happy to hear that there was a lot of opportunity for you to continue exploring with AvidFirst. And we'll be here, so please [laughs] come to us as much as possible. Everybody is really excited to see, you know, you and this thing be successful. So, thank you, Vendela and Jordyn, as always, for being a wonderful team. +If you're interested in applying to the incubator, do it. Don't hesitate. You can always visit thoughtbot.com/incubator for more information. And thanks for tuning in. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions. Special Guests: Ashley Sheble, Dawn Delatte, Jordyn Bonds, and Vendela Colavecchio. + + + Dawn Delatte, Vendela Colavecchio, and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product.

+ +

The discussion covers various aspects of the program, including the evolution of the product idea, insights gained from industry conferences, the importance of listening to customers, and the ongoing development of the go-to-market strategy. Everyone emphasizes the value of the Incubator Program in helping founders connect with their market and refine their strategy.

+ +

Just catching up? Listen to Part I, Part 2, and Part 3 of the Mini Incubator Series!

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

DAWN: Hello, everyone. So, since we have a bigger crew here today, slightly bigger crew, we should just jump right in, right?

+ +

If you're not familiar with thoughtbot, we're a design and development consultancy who create and build products from the very earliest stages.

+ +

We are currently in our second incubator session. This is actually our final week. We're wrapping up this week our second program with Ashley at AvidFirst. And I'll let everybody go around and say hi and give a little intro.

+ +

Today, we're going to be chatting about how the program has been going, any new recent activity, and things that we've learned and done, and, you know, what's going to happen here after the session ends.

+ +

I'm Dawn. I am a Managing Director here at thoughtbot. And I will shoot it over to you, Ashley.

+ +

ASHLEY: Thanks, Dawn. And my name is Ashley Sheble. I'm the CEO and Founder of AvidFirst. AvidFirst is really focused on helping people save and spend for college in a modern way. We're simplifying the process, modernizing the experience, and really, with the end goal of helping families avoid student debt.

+ +

So, I've been working with the thoughtbot team for the past eight weeks, really refining our strategy, and we'll talk about this here in a minute. But pivoting a little bit on the strategy just based on what we learn from the market from talking to users, from talking to experts, from talking to people with just insight around what's needed in the space. And so I'm excited to share more about the past eight weeks.

+ +

DAWN: Awesome. Thank you. Jordyn, do you want to hop in?

+ +

JORDYN: Sure. I'm Jordyn Bonds. And I'm the Director of Product Strategy on the Ignite team. And I am a two-time former co-founder of tech startups, so whence I come to this work. Vendela, I'll let you go.

+ +

VENDELA: I'm Vendela Colavecchio. I'm the Design Director on our team here running the incubators at thoughtbot. And yeah, should I talk about my role on the incubator [chuckles] more?

+ +

I guess the incubator is sort of funny because, you know, as a designer, typically, my tasks fall under more of a traditional design category. But I think with the incubator, we're, like, all hands on deck, just trying to get lots of things done and help out in any way that we can. So, definitely some design things, but also just a bunch of participating in discussions and getting all sorts of tasks done.

+ +

DAWN: I'm sure we'll dive more into that. As usual, though, we're going to let Ashley kick us off, kick our discussion off with a little bit of an update on what's been going on in these past two weeks since we last chatted and, you know, where we are now.

+ +

ASHLEY: Yeah. So, the past couple of weeks have been pretty exciting. I went to an industry conference. It was a 529 and ABLE conference. So, 529s are tax-advantaged savings accounts specific for education expenses. ABLE accounts are tax-advantaged savings accounts, specifically for people who have a disability. And so, spent a week learning from experts in both spaces, hearing from all the different stakeholders, so state agencies, program distributors, you name it, every sort of stakeholder in the whole industry was there. And it was amazing to just be able to go in and learn and meet people and hear their perspectives around what's going well, what's not going well.

+ +

It could not have been more well timed because I think had the conference been earlier, I might not have been ready to ask the right questions from the different stakeholders. And had the conference been later, well, we couldn't have used any of that insight and learning to continue working on refining or pivoting the project. So, it was a great experience. People were so collaborative, so helpful.

+ +

I think it's interesting that my perspective going in was, oh, people aren't going to want to talk to me. They're not going to want to share their insight. But it was quite the opposite. People were really happy to talk about what they thought could be improved or what they thought seemed to be going well. But it's only from one perspective. So, if you start asking questions around what you've learned from other people's perspectives, you kind of see this, like, aha moment. Like, oh, I hadn't thought about that before. Maybe that's something to consider. So, it was an amazing experience.

+ +

So, as a result of that particular event last week, have really been synthesizing what we learned, filling in any gaps. And then just using that to think about a different strategy based on kind of the signals in the room, what people were really excited about, and what people really thought needed some work versus what we went into the conference thinking was the right answer, if that makes sense.

+ +

DAWN: That's so exciting. Can you tell us more about this pivot? You mentioned a pivot.

+ +

ASHLEY: Yeah. And I wouldn't call it maybe a full pivot. I would say it's more an expansion on the work we've already done, which is good. So, we're not just throwing away all the work we've done for the past seven weeks and saying, "Forget it."

+ +

There are a lot of parallels in the 529 space and the ABLE space. A lot of the stakeholders are the same, and it's just a different target market with a little bit different need set. And so, really trying to understand what the differences are, and what the similarities are, and how we can replicate the work that we've already done for one space in the other space, and then build upon that a lot more rapidly than it took us to build the initial work for the 529.

+ +

So, there's definitely some advantages that the two industries are really intertwined. But at the same time, there are some differences that we need to be keenly aware of and making sure that we're solving a problem meaningfully.

+ +

DAWN: Jordyn and Vendela, how has this, not pivot, but new expansion or new strategy, how has this affected your work?

+ +

VENDELA: What I'm thinking about on sort of a meta-level is how it's exciting to see that this new angle doesn't really change how we would approach the problem in terms of just running the incubator. So, it's almost, not in a discouraging way, but it's almost just like starting back from week one and kind of going through, what do we know? What do we need to find out? What kind of questions do we need to ask stakeholders, et cetera?

+ +

And just seeing how having done that already together it makes it pretty clear what the path forward would be in terms of the process. In terms of information, who knows what we'll find out? But I think that's been exciting. The pivot doesn't feel so scary as it might sound [laughs].

+ +

JORDYN: Yeah, I would just build on that to say that it's giving us this really awesome opportunity to immediately run the same process that we just ran but, like, to see how much we've learned from doing it the first time. It's like you're starting over, but you're starting over from a better place, right? With more skills, way more understanding of sort of what's important and what's not important.

+ +

And, you know, once you've run the process at least once, no part of it feels daunting, right? It just feels like work you know how to do, so it's like, okay, this is a really interesting additional sort of adjacent opportunity. We need to very quickly itemize all the things we don't know about it, and then figure out how to learn about it. Is it research? Is it interviewing? Is it testing? But none of those things feels unknown, right? It just feels like you get to do it faster and better.

+ +

This is, like, a thing, you kind of can't convince someone without them having done it. And a lot of folks come to us, come to thoughtbot with a product idea. And we tell them like, "Okay, let's get in there and validate and invalidate things." And they're, like, "Invalidate? [vocalization] I don't want to invalidate my awesome, precious product idea [laughs]." And what we know that they don't know is that there are pieces that we're going to validate and pieces we're going to invalidate, but always you uncover new opportunities in that process. And you're just better and better at ascertaining what's promising about those things.

+ +

So, it's only upside, but it feels like we're asking them to let go of something or to lose something, right? There's a feeling of like, it's like a scary...it's a feeling of like, I've built something, a tiny thing of value here, and you're asking me to risk that. And that couldn't be further from the truth. But it's, like, a really hard thing to convince someone until you've done it once. So, it's very fun, anyway, that we're getting to do this within one incubator cycle. Usually, it's, you know, it doesn't happen that quickly.

+ +

ASHLEY: I like how you qualified that as fun. I will say...and Vendela and I were talking yesterday, and we were going through the sprints around, not starting over but beginning at the beginning with this new angle. And I was having the emotional rollercoaster of, like, what are we doing? Oh my gosh. And then, oh my gosh, this is so exciting. And then, oh my gosh, what are we doing?

+ +

I feel very equipped now, having gone through this process once, to have the tools, the skills, the mindset to know, okay, it's part of the process. Here's what's going to happen. Here's what we'll probably learn. And just have a very structured way of approaching a new idea or a new angle, versus feeling like just thrown into the deep end and trying to figure out how to swim or which way is up. So, that's been pretty encouraging and eye-opening, too, that I developed all these skills that I didn't realize I had developed till we started redoing this, which is exciting.

+ +

DAWN: I love that. It's kind of a testament to how valuable time spent is and how important it is to become really, like, more efficient with this process and the value of sort of rapidly being able to validate or invalidate different assumptions. I imagine that this might be a little bit different than what you expected. As Jordyn was saying, [laughs] most founders don't, you know, expect to have to loosen the grip on specific ideas. So, now that you're at week eight, how has this experience been overall for you?

+ +

ASHLEY: It's been incredible. First of all, just the talented team that has been working on this project with me, I cannot say enough good, nice, positive things about that. I've heard horror stories about people working with teams that there's just a lot of dissension. There's lack of trust, all those things. And we had none of that, which is incredible. So, I feel very fortunate to have been with the team that I was with.

+ +

I will also say that everybody had different strengths. And so, we're looking at an opportunity or a problem from a different lens in four ways, which is amazing because then you can cover so much more ground so much more quickly. I will also say, too, just the process: the thoughtbot program has for the eight-week structure is so intentional because sometimes I would think, well, wouldn't it make sense to do this thing before this thing? But just trusted the process, and the process was right.

+ +

So, I would just say anybody that's thinking about going through the incubator or goes through the incubator next, just trust the process because you guys have a portfolio of success. You know what you're doing. I'm a testament to just really endorse the fact that each step is necessary in getting to the next step in a successful way. So, you're not taking two steps forward, one step back. You're constantly making forward progress.

+ +

DAWN: That's awesome. What about you, Vendela, and Jordyn, how has this program and this session been this time around?

+ +

VENDELA: I can talk about my experience as the first time going through the incubator, and then maybe, Jordyn, you have some insight on comparing the two or how you think it went in general.

+ +

But I think one thing that has been really fun to do and participate in, and to Ashley's point about kind of having this environment of trust and just counting on each other that we're all distilling the information that we're hearing, I guess, accurately or in a way that aligns with how the rest of the team would perceive these things, is that we've had these really cool moments of not feeling like we 100% with complete certainty know exactly how something looks, but being creative about how we might get closer to that point.

+ +

So, hearing a few tidbits here and there, thinking of ways that we're reading between the lines and interpreting that, and thinking about how we can narrow who we're talking to or approach the conversation slightly differently, so adjusting our script, or running some kind of other experiment, or structure things differently. And then, we might find that that angle wasn't exactly right, but by pursuing that angle, we learned something new that actually did get us closer in some way. And I think a lot of that was subtle throughout the process.

+ +

But now, just thinking about this new kind of topic or pivot, whatever you want to call it [laughs], that we're pursuing, I think that lesson is going to be really valuable for Ashley moving forward, too, and just thinking, okay, I feel like what we're trying now isn't getting any closer. What have I heard that I could just grab, like, a small piece of string and pull on it, and see where that goes, and unravel something, and hopefully learn something new? So that there's just consistent kind of learning and not feeling like you're just totally blocked at any point.

+ +

JORDYN: Yeah, to build on that a little bit, there's a real quality with this early work of just starting with what you have, where you are. And, you know, you don't have everything you need, like, you just don't, not in life and certainly not in [laughs] startup land. But the question is, like, figuring out what you need and figuring out how to get that from where you are. And that might be validation of a hypothesis you have, or it might be resources that you need that you don't have yet.

+ +

And so, a lot of the work that we did together is to identify those things and to figure out ways to get them. And it's a real creative process because every problem is different. It's why it's really hard to talk about the programming in a specific way. It's like, you know, broadly, we're driving at the same outcomes every time. But every problem space, every industry requires a kind of different set of approaches, and, to me, that's really fun.

+ +

It's like, okay, imagine as a metaphor, you know, that you are dropped from a helicopter into a jungle in Central America versus into Mongolia. Like, what you're going to need to survive in those two [laughs] environments is probably going to be pretty different, right? But that doesn't mean that your strategy for figuring those things out is going, like, the tactics you employ will be different. Yeah, I'm glad to hear, Vendela; that was a fun aspect of this.

+ +

And sort of jumping off from that point, what was different this time? It's always different running this program. And every time, there's something new and different. But this was the first time we've run it with a FinTech product, and just learning about that ecosystem, the players, and the complex landscape of incentives and motivations, et cetera, was just, like, there was a steep learning curve for us at the beginning. And it was just super interesting and helpful to sift through that.

+ +

It was like being, you know, dropped from a helicopter into a new sort of ecosystem. And we were like, all right, like, which berries are poisonous here? I don't know. But I also know that I need to eat something to survive [laughs]. So, it's like those kinds of questions, which is just super interesting.

+ +

And then, what it always causes me to do is look at my own network anew. So, often, we find ourselves talking about, like, this question of starting with where you are with what you have. That includes with the network you have and the people you know. And it really depends on the problem you're solving, who you tap for what questions, right? And, suddenly, like, every one of these that we run, I get to turn to my own network. And I find new reasons to talk to different people about different things in my own network, which is really fun.

+ +

It's like it allows me to get to know people in my own life in a new way. Like, every time this happens like, one of the first things we do is we turn to our own networks. Like, who do we know that has this problem or works in this industry, whatever? But having never worked on a FinTech product before, I didn't really need to do that with this lens. And it's like a whole new set of people lit up for me, and I got to have really interesting conversations with them. So, that was one thing that was different and really kind of fun.

+ +

ASHLEY: It's funny to hear your take on the FinTech complexity because I feel like every time Vendela, or Jordyn, or Dave, who's not here, would ask me a question, it was, well, here's the answer, but if this, then that, or if this other thing, then that. It was never just a straightforward answer.

+ +

And I was like, oh my gosh, they're just going to throw their hands up in the air at some point, but never did. They were just like, cool, that's fine. We'll figure out these different pathways, and if this, then we'll do that, and if this other thing, then we'll do this other thing. And I was just blown away by how nimble the team was and willing to just embrace the complexity. So, that, for me, was a huge positive. I don't know if you'll ever want to work in a FinTech product again; maybe yes, maybe no.

+ +

DAWN: I would argue that we're more prepared now. You know, we've done a lot of FinTech work in the past, but applying this framework to understanding it as quickly as the team needed to, I'm sure, sort of pushed everybody farther, faster. So, Dave --

+ +

JORDYN: Yeah, I should say that was specific to me. thoughtbot has done plenty of FinTech work, Jordyn has not. But also, to your point, Ashley, like, I would love to actually. Now I'm like, oh okay, I kind of understand where the opportunities are here. I feel more prepared now rather than, like, more daunted.

+ +

ASHLEY: Well, and you have a huge network in the FinTech space. So, that was something that was hugely helpful to me was talking with other founders who have been successful in the FinTech space, or people who have exited and had a great experience, or maybe people who have exited for, you know, reasons they didn't choose. But it was so important to hear from all those different perspectives and say, okay, here's what I would want to replicate, what I would definitely want to avoid. And so, anyways, just the network that Jordyn and others had and were willing to share with me was so valuable.

+ +

DAWN: I was going to quickly shout out to Dave, who was sick this morning and wasn't able to make it. We were going to have him join. He was the senior developer in this sort of product pod that you've been working with. And I'm sure he has some interesting, more technical perspective to share. He did write a blog post, I think, maybe after week four, that I'm sure has some of those insights in it for folks who might be interested in reading from a developer's perspective. Yes, this is all wonderful to hear.

+ +

I am curious to know what's next for AvidFirst.

+ +

ASHLEY: Yeah, continuing on. There are a couple of things to pilot. And so, that's really the next step, pilot MVP as we think about this new angle. Because we want to make sure that the solution in mind is actually the solution that's needed. And so, those are the next steps, and then capital raise and then off to the races. So, if there's anybody listening that is interested in teaming up or wants to talk or contribute, would love to have a chat.

+ +

DAWN: Is there anything that we can help with, anything on your mind, more network connections? [laughs]

+ +

ASHLEY: Oh, gosh, offhand, I feel like I would be over-asking at this point because you guys have been beyond helpful. I really think the framework that I have to work with going forward—the team helped build a plan for here's what to do next, here's what to do after that, and here's what to do after that—is really setting me up for success as I think about continuing this journey without the amazing team day in, day out.

+ +

JORDYN: Well, you have us as a team for life now, sorry. So, anytime you need something, [laughs] you can call.

+ +

VENDELA: I was going to say I hope that you stick around in our Slack channel and update us on what's going on because now we're super invested, and we definitely want to hear how you're doing.

+ +

ASHLEY: Yeah, absolutely.

+ +

DAWN: Vendela and Jordyn, we've got another application window happening right now about to close for the next incubator session. Who should apply? What should they expect?

+ +

JORDYN: Anybody with a business idea that involves software. The earlier, the better. And a lot of people, you know, come to us and are like, "Well, I have this idea that I'm kicking around for years in my head, but I haven't done anything yet. You know, what do I have to do to apply?" And we're like, "Sounds good. Apply."

+ +

And then, other folks who are a little later, you know, and they feel like maybe they've hit some doldrums with an idea that they've explored a little bit. But they need a little bit of sort of reinvigorating and, you know, like a spark to get going on it. That's also a good time. We're really sort of excited to hear everybody's ideas. And the only, you know, downside is that we get more applications than folks we can work with. And there's always, like, a lot of great stuff in there. But everyone is encouraged to apply.

+ +

You know, we used to have somewhat of a, like, non-technical founder. And when we first started, that was kind of the premise was, like, if you're a non-technical founder, we'll be your technical founding team. But I think we're finding that we kind of round out any skill sets in a way. If you bring a technical background, we can help you with the sales, and the marketing, and the business strategy. And if you come with those things, we can help you with the product and the technology strategy. It's the early-stage work, and the early-stage work is the early-stage work, regardless of your background. We can help fill in those gaps.

+ +

ASHLEY: Yeah, I'll just add, too, I came in with this pitch check. I'm like, I'm ready to go, you know, we just need to build this thing. And, wow, the idea has changed so much since eight weeks ago. And so, I would just say, too, like, be open to feedback, be open to where the experience takes you. Even if you do have a really well-researched idea, there's always opportunity for improvement based on what the market says.

+ +

And the market is constantly changing. And customer needs are constantly changing. And so, if you're not evolving with that experience, then you're going to get left behind or build a product for no one or, you know, a product for everyone is really a product for no one also. So, being open to the team's input and process is just invaluable no matter what stage somebody is coming into this with.

+ +

JORDYN: That makes me just so happy to hear. And I will add that, like, I cannot stress enough that mostly what this program is for is to help folks connect with their market. Like, we actually don't want you to listen to us. We want you to listen to your customer all day, every day. How can you make sure you're moving with those folks, evolving with them, speaking their language, addressing the pain points that they have? Because that's why you're doing this, not because of what you think alone or what we think as your product pod. It's really what the market is doing and what your customer base is doing, and thinking, and feeling.

+ +

And really, the programming is sort of geared toward helping people understand how to do that work. Like, you might conceptually understand that you need to do that. As a first-time founder, I certainly, you know, I had read the blogs, man. I knew I needed to be, like, customer-centric or whatever. But, like, I didn't really actually know how to do that. And once I did talk to some folks, it was a whole other new skill set to figure out how to listen for the things that mattered in what they were saying to me, right?

+ +

Translating, you know, what folks are telling you and how they talk about their life and their work into product opportunities and innovation, it's a whole skill set that I, even coming into this work, you know, as a first-time founder with the background I had, I didn't have that skill set. You know, most people sitting out there would not argue, like, of course, you need to listen to your customer and move with the market, et cetera. But the question of, like, how to operationalize that [laughs], you know, is a completely opaque thing sometimes. Even for folks who have, like, done it before somewhat, it can still remain challenging.

+ +

ASHLEY: Yeah, I feel in a better position now to continue keeping pace with the market. Because if you look at FinTech, historically, there were major innovations every ten years, and then that pace changed to every couple of years, and then it changed to every one year. And now you're seeing FinTech innovation accelerated to every few months; the landscape is different. And so, the solution today may need to be different in six months, or three months, something like that. But I feel like I have the tools now to keep up with that pace of change, whereas before, I would have been left behind. So, I feel really grateful for that. Thank you.

+ +

DAWN: That warms my heart. We do have a question. So, does thoughtbot help with go-to-market strategy, or is the incubator more focused on zero to MVP?

+ +

JORDYN: You know, I'm full of very spicy takes. Spicy take here: you're always going to market. Zero to MVP is different than go-to-market? I'm sorry, how? So, the answer is, like, absolutely. And really, what you're doing is perennially going to the market [laughs]. You're making a go-to-market strategy. You're keeping that fresh. You're keeping it new in the same way that you're keeping your products and technology strategy fresh and new, given what you're learning and what you're hearing.

+ +

So, absolutely, I would say that's actually primarily what the incubator is for [laughs], and then making sure that those strategies are aligned. So, like, one of the things that I've seen in my own work at multiple startups, not just my own, is that those things can become disconnected as your team grows because people have different backgrounds and different...they just have a different focus, right? Your head of marketing has a different focus than your head of product and has a different focus than your head of technology.

+ +

And keeping all of those strategically aligned and focused on the same customer and the same problem set is a lot of the work of an early-stage startup. And that's, like, a lot of the work that we kind of help founders figure out how to do. How do you tie your go-to-market to your MVP? Like, how do those two things fit in together, right? And how do you keep them in sync? It's not merely like you do this one time and then everyone goes their separate ways [laughs], and in 18 months, you meet back again and have a conversation about it, like, [laughs] not how this works. So, I mean, absolutely.

+ +

VENDELA: I would add to that, too; I think something that we talk about with all these types of projects is just...and, internally, we talk about this a lot, too, like, we kind of hate the term MVP because it's so ambiguous really. Like, what does that mean for any given product? And so, I think, to your point, Jordyn, like, the going to market and the MVP are so tied together because the whole point of an MVP is to learn something so that you can then bring it from a minimum viable product to something more than that.

+ +

And we talk a lot with founders about different approaches to MVP. I think some people have maybe a narrow view of what they can be. It's this, you know, maybe slightly lower fidelity but coded custom thing. And there's lots of ways to approach it that don't fit that definition and maybe would work better as a way to experiment and learn something, and then create a new version later on. So, you know, with that first version, you can still go to market, but you're learning something, and then you're maybe building a new MVP after that. And so, making sure that that's not too precious or hard to throw away is something, I think, we tell everybody, too.

+ +

DAWN: Yes, that's great. Cool. Well, I think it's about time for us to wrap up. Thank you so much, Ashley. It's always an honor to kind of watch the team work with different founders and see them sort of learning as they go and seeing the product and the opportunities evolve. And it's been really great to be able to participate a little bit more this time and chatting with you and hearing about how things are going.

+ +

I'm happy to hear that there was a lot of opportunity for you to continue exploring with AvidFirst. And we'll be here, so please [laughs] come to us as much as possible. Everybody is really excited to see, you know, you and this thing be successful. So, thank you, Vendela and Jordyn, as always, for being a wonderful team.

+ +

If you're interested in applying to the incubator, do it. Don't hesitate. You can always visit thoughtbot.com/incubator for more information. And thanks for tuning in.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble, Dawn Delatte, Jordyn Bonds, and Vendela Colavecchio.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dawn Delatte, Vendela Colavecchio, and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product.

+ +

The discussion covers various aspects of the program, including the evolution of the product idea, insights gained from industry conferences, the importance of listening to customers, and the ongoing development of the go-to-market strategy. Everyone emphasizes the value of the Incubator Program in helping founders connect with their market and refine their strategy.

+ +

Just catching up? Listen to Part I, Part 2, and Part 3 of the Mini Incubator Series!

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

DAWN: Hello, everyone. So, since we have a bigger crew here today, slightly bigger crew, we should just jump right in, right?

+ +

If you're not familiar with thoughtbot, we're a design and development consultancy who create and build products from the very earliest stages.

+ +

We are currently in our second incubator session. This is actually our final week. We're wrapping up this week our second program with Ashley at AvidFirst. And I'll let everybody go around and say hi and give a little intro.

+ +

Today, we're going to be chatting about how the program has been going, any new recent activity, and things that we've learned and done, and, you know, what's going to happen here after the session ends.

+ +

I'm Dawn. I am a Managing Director here at thoughtbot. And I will shoot it over to you, Ashley.

+ +

ASHLEY: Thanks, Dawn. And my name is Ashley Sheble. I'm the CEO and Founder of AvidFirst. AvidFirst is really focused on helping people save and spend for college in a modern way. We're simplifying the process, modernizing the experience, and really, with the end goal of helping families avoid student debt.

+ +

So, I've been working with the thoughtbot team for the past eight weeks, really refining our strategy, and we'll talk about this here in a minute. But pivoting a little bit on the strategy just based on what we learn from the market from talking to users, from talking to experts, from talking to people with just insight around what's needed in the space. And so I'm excited to share more about the past eight weeks.

+ +

DAWN: Awesome. Thank you. Jordyn, do you want to hop in?

+ +

JORDYN: Sure. I'm Jordyn Bonds. And I'm the Director of Product Strategy on the Ignite team. And I am a two-time former co-founder of tech startups, so whence I come to this work. Vendela, I'll let you go.

+ +

VENDELA: I'm Vendela Colavecchio. I'm the Design Director on our team here running the incubators at thoughtbot. And yeah, should I talk about my role on the incubator [chuckles] more?

+ +

I guess the incubator is sort of funny because, you know, as a designer, typically, my tasks fall under more of a traditional design category. But I think with the incubator, we're, like, all hands on deck, just trying to get lots of things done and help out in any way that we can. So, definitely some design things, but also just a bunch of participating in discussions and getting all sorts of tasks done.

+ +

DAWN: I'm sure we'll dive more into that. As usual, though, we're going to let Ashley kick us off, kick our discussion off with a little bit of an update on what's been going on in these past two weeks since we last chatted and, you know, where we are now.

+ +

ASHLEY: Yeah. So, the past couple of weeks have been pretty exciting. I went to an industry conference. It was a 529 and ABLE conference. So, 529s are tax-advantaged savings accounts specific for education expenses. ABLE accounts are tax-advantaged savings accounts, specifically for people who have a disability. And so, spent a week learning from experts in both spaces, hearing from all the different stakeholders, so state agencies, program distributors, you name it, every sort of stakeholder in the whole industry was there. And it was amazing to just be able to go in and learn and meet people and hear their perspectives around what's going well, what's not going well.

+ +

It could not have been more well timed because I think had the conference been earlier, I might not have been ready to ask the right questions from the different stakeholders. And had the conference been later, well, we couldn't have used any of that insight and learning to continue working on refining or pivoting the project. So, it was a great experience. People were so collaborative, so helpful.

+ +

I think it's interesting that my perspective going in was, oh, people aren't going to want to talk to me. They're not going to want to share their insight. But it was quite the opposite. People were really happy to talk about what they thought could be improved or what they thought seemed to be going well. But it's only from one perspective. So, if you start asking questions around what you've learned from other people's perspectives, you kind of see this, like, aha moment. Like, oh, I hadn't thought about that before. Maybe that's something to consider. So, it was an amazing experience.

+ +

So, as a result of that particular event last week, have really been synthesizing what we learned, filling in any gaps. And then just using that to think about a different strategy based on kind of the signals in the room, what people were really excited about, and what people really thought needed some work versus what we went into the conference thinking was the right answer, if that makes sense.

+ +

DAWN: That's so exciting. Can you tell us more about this pivot? You mentioned a pivot.

+ +

ASHLEY: Yeah. And I wouldn't call it maybe a full pivot. I would say it's more an expansion on the work we've already done, which is good. So, we're not just throwing away all the work we've done for the past seven weeks and saying, "Forget it."

+ +

There are a lot of parallels in the 529 space and the ABLE space. A lot of the stakeholders are the same, and it's just a different target market with a little bit different need set. And so, really trying to understand what the differences are, and what the similarities are, and how we can replicate the work that we've already done for one space in the other space, and then build upon that a lot more rapidly than it took us to build the initial work for the 529.

+ +

So, there's definitely some advantages that the two industries are really intertwined. But at the same time, there are some differences that we need to be keenly aware of and making sure that we're solving a problem meaningfully.

+ +

DAWN: Jordyn and Vendela, how has this, not pivot, but new expansion or new strategy, how has this affected your work?

+ +

VENDELA: What I'm thinking about on sort of a meta-level is how it's exciting to see that this new angle doesn't really change how we would approach the problem in terms of just running the incubator. So, it's almost, not in a discouraging way, but it's almost just like starting back from week one and kind of going through, what do we know? What do we need to find out? What kind of questions do we need to ask stakeholders, et cetera?

+ +

And just seeing how having done that already together it makes it pretty clear what the path forward would be in terms of the process. In terms of information, who knows what we'll find out? But I think that's been exciting. The pivot doesn't feel so scary as it might sound [laughs].

+ +

JORDYN: Yeah, I would just build on that to say that it's giving us this really awesome opportunity to immediately run the same process that we just ran but, like, to see how much we've learned from doing it the first time. It's like you're starting over, but you're starting over from a better place, right? With more skills, way more understanding of sort of what's important and what's not important.

+ +

And, you know, once you've run the process at least once, no part of it feels daunting, right? It just feels like work you know how to do, so it's like, okay, this is a really interesting additional sort of adjacent opportunity. We need to very quickly itemize all the things we don't know about it, and then figure out how to learn about it. Is it research? Is it interviewing? Is it testing? But none of those things feels unknown, right? It just feels like you get to do it faster and better.

+ +

This is, like, a thing, you kind of can't convince someone without them having done it. And a lot of folks come to us, come to thoughtbot with a product idea. And we tell them like, "Okay, let's get in there and validate and invalidate things." And they're, like, "Invalidate? [vocalization] I don't want to invalidate my awesome, precious product idea [laughs]." And what we know that they don't know is that there are pieces that we're going to validate and pieces we're going to invalidate, but always you uncover new opportunities in that process. And you're just better and better at ascertaining what's promising about those things.

+ +

So, it's only upside, but it feels like we're asking them to let go of something or to lose something, right? There's a feeling of like, it's like a scary...it's a feeling of like, I've built something, a tiny thing of value here, and you're asking me to risk that. And that couldn't be further from the truth. But it's, like, a really hard thing to convince someone until you've done it once. So, it's very fun, anyway, that we're getting to do this within one incubator cycle. Usually, it's, you know, it doesn't happen that quickly.

+ +

ASHLEY: I like how you qualified that as fun. I will say...and Vendela and I were talking yesterday, and we were going through the sprints around, not starting over but beginning at the beginning with this new angle. And I was having the emotional rollercoaster of, like, what are we doing? Oh my gosh. And then, oh my gosh, this is so exciting. And then, oh my gosh, what are we doing?

+ +

I feel very equipped now, having gone through this process once, to have the tools, the skills, the mindset to know, okay, it's part of the process. Here's what's going to happen. Here's what we'll probably learn. And just have a very structured way of approaching a new idea or a new angle, versus feeling like just thrown into the deep end and trying to figure out how to swim or which way is up. So, that's been pretty encouraging and eye-opening, too, that I developed all these skills that I didn't realize I had developed till we started redoing this, which is exciting.

+ +

DAWN: I love that. It's kind of a testament to how valuable time spent is and how important it is to become really, like, more efficient with this process and the value of sort of rapidly being able to validate or invalidate different assumptions. I imagine that this might be a little bit different than what you expected. As Jordyn was saying, [laughs] most founders don't, you know, expect to have to loosen the grip on specific ideas. So, now that you're at week eight, how has this experience been overall for you?

+ +

ASHLEY: It's been incredible. First of all, just the talented team that has been working on this project with me, I cannot say enough good, nice, positive things about that. I've heard horror stories about people working with teams that there's just a lot of dissension. There's lack of trust, all those things. And we had none of that, which is incredible. So, I feel very fortunate to have been with the team that I was with.

+ +

I will also say that everybody had different strengths. And so, we're looking at an opportunity or a problem from a different lens in four ways, which is amazing because then you can cover so much more ground so much more quickly. I will also say, too, just the process: the thoughtbot program has for the eight-week structure is so intentional because sometimes I would think, well, wouldn't it make sense to do this thing before this thing? But just trusted the process, and the process was right.

+ +

So, I would just say anybody that's thinking about going through the incubator or goes through the incubator next, just trust the process because you guys have a portfolio of success. You know what you're doing. I'm a testament to just really endorse the fact that each step is necessary in getting to the next step in a successful way. So, you're not taking two steps forward, one step back. You're constantly making forward progress.

+ +

DAWN: That's awesome. What about you, Vendela, and Jordyn, how has this program and this session been this time around?

+ +

VENDELA: I can talk about my experience as the first time going through the incubator, and then maybe, Jordyn, you have some insight on comparing the two or how you think it went in general.

+ +

But I think one thing that has been really fun to do and participate in, and to Ashley's point about kind of having this environment of trust and just counting on each other that we're all distilling the information that we're hearing, I guess, accurately or in a way that aligns with how the rest of the team would perceive these things, is that we've had these really cool moments of not feeling like we 100% with complete certainty know exactly how something looks, but being creative about how we might get closer to that point.

+ +

So, hearing a few tidbits here and there, thinking of ways that we're reading between the lines and interpreting that, and thinking about how we can narrow who we're talking to or approach the conversation slightly differently, so adjusting our script, or running some kind of other experiment, or structure things differently. And then, we might find that that angle wasn't exactly right, but by pursuing that angle, we learned something new that actually did get us closer in some way. And I think a lot of that was subtle throughout the process.

+ +

But now, just thinking about this new kind of topic or pivot, whatever you want to call it [laughs], that we're pursuing, I think that lesson is going to be really valuable for Ashley moving forward, too, and just thinking, okay, I feel like what we're trying now isn't getting any closer. What have I heard that I could just grab, like, a small piece of string and pull on it, and see where that goes, and unravel something, and hopefully learn something new? So that there's just consistent kind of learning and not feeling like you're just totally blocked at any point.

+ +

JORDYN: Yeah, to build on that a little bit, there's a real quality with this early work of just starting with what you have, where you are. And, you know, you don't have everything you need, like, you just don't, not in life and certainly not in [laughs] startup land. But the question is, like, figuring out what you need and figuring out how to get that from where you are. And that might be validation of a hypothesis you have, or it might be resources that you need that you don't have yet.

+ +

And so, a lot of the work that we did together is to identify those things and to figure out ways to get them. And it's a real creative process because every problem is different. It's why it's really hard to talk about the programming in a specific way. It's like, you know, broadly, we're driving at the same outcomes every time. But every problem space, every industry requires a kind of different set of approaches, and, to me, that's really fun.

+ +

It's like, okay, imagine as a metaphor, you know, that you are dropped from a helicopter into a jungle in Central America versus into Mongolia. Like, what you're going to need to survive in those two [laughs] environments is probably going to be pretty different, right? But that doesn't mean that your strategy for figuring those things out is going, like, the tactics you employ will be different. Yeah, I'm glad to hear, Vendela; that was a fun aspect of this.

+ +

And sort of jumping off from that point, what was different this time? It's always different running this program. And every time, there's something new and different. But this was the first time we've run it with a FinTech product, and just learning about that ecosystem, the players, and the complex landscape of incentives and motivations, et cetera, was just, like, there was a steep learning curve for us at the beginning. And it was just super interesting and helpful to sift through that.

+ +

It was like being, you know, dropped from a helicopter into a new sort of ecosystem. And we were like, all right, like, which berries are poisonous here? I don't know. But I also know that I need to eat something to survive [laughs]. So, it's like those kinds of questions, which is just super interesting.

+ +

And then, what it always causes me to do is look at my own network anew. So, often, we find ourselves talking about, like, this question of starting with where you are with what you have. That includes with the network you have and the people you know. And it really depends on the problem you're solving, who you tap for what questions, right? And, suddenly, like, every one of these that we run, I get to turn to my own network. And I find new reasons to talk to different people about different things in my own network, which is really fun.

+ +

It's like it allows me to get to know people in my own life in a new way. Like, every time this happens like, one of the first things we do is we turn to our own networks. Like, who do we know that has this problem or works in this industry, whatever? But having never worked on a FinTech product before, I didn't really need to do that with this lens. And it's like a whole new set of people lit up for me, and I got to have really interesting conversations with them. So, that was one thing that was different and really kind of fun.

+ +

ASHLEY: It's funny to hear your take on the FinTech complexity because I feel like every time Vendela, or Jordyn, or Dave, who's not here, would ask me a question, it was, well, here's the answer, but if this, then that, or if this other thing, then that. It was never just a straightforward answer.

+ +

And I was like, oh my gosh, they're just going to throw their hands up in the air at some point, but never did. They were just like, cool, that's fine. We'll figure out these different pathways, and if this, then we'll do that, and if this other thing, then we'll do this other thing. And I was just blown away by how nimble the team was and willing to just embrace the complexity. So, that, for me, was a huge positive. I don't know if you'll ever want to work in a FinTech product again; maybe yes, maybe no.

+ +

DAWN: I would argue that we're more prepared now. You know, we've done a lot of FinTech work in the past, but applying this framework to understanding it as quickly as the team needed to, I'm sure, sort of pushed everybody farther, faster. So, Dave --

+ +

JORDYN: Yeah, I should say that was specific to me. thoughtbot has done plenty of FinTech work, Jordyn has not. But also, to your point, Ashley, like, I would love to actually. Now I'm like, oh okay, I kind of understand where the opportunities are here. I feel more prepared now rather than, like, more daunted.

+ +

ASHLEY: Well, and you have a huge network in the FinTech space. So, that was something that was hugely helpful to me was talking with other founders who have been successful in the FinTech space, or people who have exited and had a great experience, or maybe people who have exited for, you know, reasons they didn't choose. But it was so important to hear from all those different perspectives and say, okay, here's what I would want to replicate, what I would definitely want to avoid. And so, anyways, just the network that Jordyn and others had and were willing to share with me was so valuable.

+ +

DAWN: I was going to quickly shout out to Dave, who was sick this morning and wasn't able to make it. We were going to have him join. He was the senior developer in this sort of product pod that you've been working with. And I'm sure he has some interesting, more technical perspective to share. He did write a blog post, I think, maybe after week four, that I'm sure has some of those insights in it for folks who might be interested in reading from a developer's perspective. Yes, this is all wonderful to hear.

+ +

I am curious to know what's next for AvidFirst.

+ +

ASHLEY: Yeah, continuing on. There are a couple of things to pilot. And so, that's really the next step, pilot MVP as we think about this new angle. Because we want to make sure that the solution in mind is actually the solution that's needed. And so, those are the next steps, and then capital raise and then off to the races. So, if there's anybody listening that is interested in teaming up or wants to talk or contribute, would love to have a chat.

+ +

DAWN: Is there anything that we can help with, anything on your mind, more network connections? [laughs]

+ +

ASHLEY: Oh, gosh, offhand, I feel like I would be over-asking at this point because you guys have been beyond helpful. I really think the framework that I have to work with going forward—the team helped build a plan for here's what to do next, here's what to do after that, and here's what to do after that—is really setting me up for success as I think about continuing this journey without the amazing team day in, day out.

+ +

JORDYN: Well, you have us as a team for life now, sorry. So, anytime you need something, [laughs] you can call.

+ +

VENDELA: I was going to say I hope that you stick around in our Slack channel and update us on what's going on because now we're super invested, and we definitely want to hear how you're doing.

+ +

ASHLEY: Yeah, absolutely.

+ +

DAWN: Vendela and Jordyn, we've got another application window happening right now about to close for the next incubator session. Who should apply? What should they expect?

+ +

JORDYN: Anybody with a business idea that involves software. The earlier, the better. And a lot of people, you know, come to us and are like, "Well, I have this idea that I'm kicking around for years in my head, but I haven't done anything yet. You know, what do I have to do to apply?" And we're like, "Sounds good. Apply."

+ +

And then, other folks who are a little later, you know, and they feel like maybe they've hit some doldrums with an idea that they've explored a little bit. But they need a little bit of sort of reinvigorating and, you know, like a spark to get going on it. That's also a good time. We're really sort of excited to hear everybody's ideas. And the only, you know, downside is that we get more applications than folks we can work with. And there's always, like, a lot of great stuff in there. But everyone is encouraged to apply.

+ +

You know, we used to have somewhat of a, like, non-technical founder. And when we first started, that was kind of the premise was, like, if you're a non-technical founder, we'll be your technical founding team. But I think we're finding that we kind of round out any skill sets in a way. If you bring a technical background, we can help you with the sales, and the marketing, and the business strategy. And if you come with those things, we can help you with the product and the technology strategy. It's the early-stage work, and the early-stage work is the early-stage work, regardless of your background. We can help fill in those gaps.

+ +

ASHLEY: Yeah, I'll just add, too, I came in with this pitch check. I'm like, I'm ready to go, you know, we just need to build this thing. And, wow, the idea has changed so much since eight weeks ago. And so, I would just say, too, like, be open to feedback, be open to where the experience takes you. Even if you do have a really well-researched idea, there's always opportunity for improvement based on what the market says.

+ +

And the market is constantly changing. And customer needs are constantly changing. And so, if you're not evolving with that experience, then you're going to get left behind or build a product for no one or, you know, a product for everyone is really a product for no one also. So, being open to the team's input and process is just invaluable no matter what stage somebody is coming into this with.

+ +

JORDYN: That makes me just so happy to hear. And I will add that, like, I cannot stress enough that mostly what this program is for is to help folks connect with their market. Like, we actually don't want you to listen to us. We want you to listen to your customer all day, every day. How can you make sure you're moving with those folks, evolving with them, speaking their language, addressing the pain points that they have? Because that's why you're doing this, not because of what you think alone or what we think as your product pod. It's really what the market is doing and what your customer base is doing, and thinking, and feeling.

+ +

And really, the programming is sort of geared toward helping people understand how to do that work. Like, you might conceptually understand that you need to do that. As a first-time founder, I certainly, you know, I had read the blogs, man. I knew I needed to be, like, customer-centric or whatever. But, like, I didn't really actually know how to do that. And once I did talk to some folks, it was a whole other new skill set to figure out how to listen for the things that mattered in what they were saying to me, right?

+ +

Translating, you know, what folks are telling you and how they talk about their life and their work into product opportunities and innovation, it's a whole skill set that I, even coming into this work, you know, as a first-time founder with the background I had, I didn't have that skill set. You know, most people sitting out there would not argue, like, of course, you need to listen to your customer and move with the market, et cetera. But the question of, like, how to operationalize that [laughs], you know, is a completely opaque thing sometimes. Even for folks who have, like, done it before somewhat, it can still remain challenging.

+ +

ASHLEY: Yeah, I feel in a better position now to continue keeping pace with the market. Because if you look at FinTech, historically, there were major innovations every ten years, and then that pace changed to every couple of years, and then it changed to every one year. And now you're seeing FinTech innovation accelerated to every few months; the landscape is different. And so, the solution today may need to be different in six months, or three months, something like that. But I feel like I have the tools now to keep up with that pace of change, whereas before, I would have been left behind. So, I feel really grateful for that. Thank you.

+ +

DAWN: That warms my heart. We do have a question. So, does thoughtbot help with go-to-market strategy, or is the incubator more focused on zero to MVP?

+ +

JORDYN: You know, I'm full of very spicy takes. Spicy take here: you're always going to market. Zero to MVP is different than go-to-market? I'm sorry, how? So, the answer is, like, absolutely. And really, what you're doing is perennially going to the market [laughs]. You're making a go-to-market strategy. You're keeping that fresh. You're keeping it new in the same way that you're keeping your products and technology strategy fresh and new, given what you're learning and what you're hearing.

+ +

So, absolutely, I would say that's actually primarily what the incubator is for [laughs], and then making sure that those strategies are aligned. So, like, one of the things that I've seen in my own work at multiple startups, not just my own, is that those things can become disconnected as your team grows because people have different backgrounds and different...they just have a different focus, right? Your head of marketing has a different focus than your head of product and has a different focus than your head of technology.

+ +

And keeping all of those strategically aligned and focused on the same customer and the same problem set is a lot of the work of an early-stage startup. And that's, like, a lot of the work that we kind of help founders figure out how to do. How do you tie your go-to-market to your MVP? Like, how do those two things fit in together, right? And how do you keep them in sync? It's not merely like you do this one time and then everyone goes their separate ways [laughs], and in 18 months, you meet back again and have a conversation about it, like, [laughs] not how this works. So, I mean, absolutely.

+ +

VENDELA: I would add to that, too; I think something that we talk about with all these types of projects is just...and, internally, we talk about this a lot, too, like, we kind of hate the term MVP because it's so ambiguous really. Like, what does that mean for any given product? And so, I think, to your point, Jordyn, like, the going to market and the MVP are so tied together because the whole point of an MVP is to learn something so that you can then bring it from a minimum viable product to something more than that.

+ +

And we talk a lot with founders about different approaches to MVP. I think some people have maybe a narrow view of what they can be. It's this, you know, maybe slightly lower fidelity but coded custom thing. And there's lots of ways to approach it that don't fit that definition and maybe would work better as a way to experiment and learn something, and then create a new version later on. So, you know, with that first version, you can still go to market, but you're learning something, and then you're maybe building a new MVP after that. And so, making sure that that's not too precious or hard to throw away is something, I think, we tell everybody, too.

+ +

DAWN: Yes, that's great. Cool. Well, I think it's about time for us to wrap up. Thank you so much, Ashley. It's always an honor to kind of watch the team work with different founders and see them sort of learning as they go and seeing the product and the opportunities evolve. And it's been really great to be able to participate a little bit more this time and chatting with you and hearing about how things are going.

+ +

I'm happy to hear that there was a lot of opportunity for you to continue exploring with AvidFirst. And we'll be here, so please [laughs] come to us as much as possible. Everybody is really excited to see, you know, you and this thing be successful. So, thank you, Vendela and Jordyn, as always, for being a wonderful team.

+ +

If you're interested in applying to the incubator, do it. Don't hesitate. You can always visit thoughtbot.com/incubator for more information. And thanks for tuning in.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble, Dawn Delatte, Jordyn Bonds, and Vendela Colavecchio.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pnAPAiga + + ]]> + + Ashley Sheble + Dawn Delatte + Jordyn Bonds + Vendela Colavecchio + + + thoughtbot's Incubator Program Mini Season - Episode 03: AvidFirst with Ashley Sheble + https://podcast.thoughtbot.com/incubatormini3 + 8e1e5d51-e60b-4493-8d4e-4af819291e80 + Wed, 01 Nov 2023 00:30:00 -0400 + thoughtbot + + full + 12 + thoughtbot + Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product. + +In the third part of the Mini Incubator Series, they talk about user interviews, data analysis, and prototyping to validate ideas. They emphasize the importance of being open to user signals and adjusting their approach accordingly. They also discuss the upcoming weeks of the program and the goal of refining their story and business strategy. + 23:36 + no + + + Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product. +In the third part of the Mini Incubator Series, they talk about user interviews, data analysis, and prototyping to validate ideas. They emphasize the importance of being open to user signals and adjusting their approach accordingly. They also discuss the upcoming weeks of the program and the goal of refining their story and business strategy. +Just catching up? Listen to Part I (https://www.giantrobots.fm/498) and Part 2 (https://www.giantrobots.fm/499) of the Mini Incubator Series! +Follow Ashley Sheble on LinkedIn (https://www.linkedin.com/in/ashley-sheble/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +DAWN: Thanks, everybody, for joining. We're glad that you're here. If you've tuned in before, great, welcome back. You're probably familiar with thoughtbot; if you're not, we're a product design and development consultancy that helps make you, and your team, and your product successful. +We are currently running the second session of our incubator program, which is an eight-week program that takes you through a lot of different activities and exercises to help you identify market and product opportunities, experiment with them, and ideally come up with a solution that you can move forward with. +I'm Dawn. I'm a Managing Director here at thoughtbot. And I lead a team that works with very early-stage products, and founders, and companies. And I'll hand it over to Jordyn. +JORDYN: I'm Jordyn Bonds, and I'm the Director of Product Strategy on Dawn's team. And I'm kind of the...I don't know what, founder in residence for the incubator trying to bring my experience as a former founder to bear for our participants, in this case, Ashley. +ASHLEY: Okay, my name is Ashley Sheble. I'm the CEO and founder of AvidFirst and have been working with Jordyn and a great team in the second incubator session. So, removing all bias from the statement I'm about to say, but if anybody's thinking about applying to the next incubator, just do it. It's an amazing experience. You're going to learn so much. There are so many smart, helpful people who really care about building cool products that make a difference. And so, do it. +DAWN: I love it. Thanks for the impromptu promo. +JORDYN: Yeah, thank you [laughs]. It's good to hear. +DAWN: Yeah, I'm excited. Cool. Well, Ashley, why don't you maybe kick us off with a little bit of a recap of these past two weeks? What have y'all been working on? +ASHLEY: Yeah, so, just for a little background, in case anybody hasn't been following along, AvidFirst is a technology company aimed at simplifying college saving and spending. Our goal is really to make 529 accounts more usable broadly and then, more specifically, attractive to next-gen consumers. +And for those who aren't familiar with 529 plans, that's okay because neither are about 70% of Americans. But essentially, they are college savings vehicles. They're investment accounts that allow people to contribute money. The money grows tax-free and then can be withdrawn tax-free when used for qualified education expenses. +And over the past few years, the term qualified education expense has really expanded from beyond just tuition and fees to room and board on and off campus, computers, technology, supplies, apprenticeships, K through 12, like, the list is getting longer and longer. And so, our goal is just to really help simplify a really complex system and savings vehicle to make them more appealing and attractive to people. +So, the past few weeks, specifically, we have been aggregating all the data from our user interviews. We've done a lot of user interviews with different stakeholders and have been taking the information and saying, okay, what do we do next? How do we validate the way we're thinking about solving this problem will actually solve the problem in the way that we think it will? And so, through lots of process mapping, brainstorming different pilot initiatives, and then now working through some of the nuances of the industry. The 529 industry, specifically, is a complex animal. I don't really know how else to explain it. It's very complex. And so, we are just navigating these complexities and looking for solutions that will truly simplify the complexity. +JORDYN: I will just dig in a little bit to that analysis of the interviews that we've been conducting. That analysis kind of, like, stepped up a notch in the last week in a really fun way where we, the team, really kind of dug into the dynamics of each interview, sort of the things that we're most curious about, and have been asking and really, like, scored each interview. And then did sort of a cohort analysis, like, where are the trends with which personas? +We had already had some intuitions, and we just wanted to confirm with the data that we weren't deluding ourselves about what the direction was. So, that was a really, like, I think it was a really useful exercise and kind of fun to see. And what doing that helps with is our own conviction, but then it also helps us make sure that we are honing who we're talking to going forward. +Talking to folks is, like, so critical and is so not scalable. It is so time-consuming [laughs]. So, you want to make sure that you're doing it really strategically. So, it's sort of, like, every wave of interviews we do, we do a little more analysis. And it's, like, we finally got to a critical number where we felt like doing this data pass was going to be statistically significant. We had enough interviews to really focus the interviews we're going to do going forward. So, just to give a little, like, lens into how that's worked and how we've been thinking about it. +DAWN: I think we ask this question often, maybe every time, but I'm interested to see how it continues to evolve. But what was something that you learned these past two weeks that really surprised you or maybe even confirmed your hunches? +JORDYN: So, as often happens, when you start talking to a focus group of people who share a lot of pain points in their lives or their work, you end up with, like, a lot of trends. Like, there might be a thing you're asking them about that you're particularly focused on or curious about, and you want to focus your questions on that. But invariably, you're talking to a human being, and they're going to talk about a lot of different things. +And so, early on, and when we started interviewing people at the very beginning of this project in August, you know, we were very focused on college savings and spending. But an interesting thing, like, sort of trend that came up was also how much parents care about imparting, you know, some sense of financial responsibility in their young adults [laughs]. And we were like, well, that's interesting. Okay, let's, like, keep an eye on that. Maybe that's interesting to us. +And what has kind of surprised me in the last couple of weeks is how much of that has sort of solidified. This is not, like, a news flash, by the way, like I think [laughs]. This is, like, a thing. Anyone who has teenagers out there is like, duh, like, why is this shocking to you? But the way that it ties into college savings and spending, I think we found some really interesting connections and threads there that have only gotten stronger with the specific cohorts that we've been talking to. +So, I think that we, at first, had started as just this sort of, like, well, that's interesting, but we'll see where it goes kind of thing. And now it's, like, become a little bit more core to how we're thinking about just broadly what folks are facing, who we're addressing. So, I guess it wasn't, like, a surprise, but, like, the deepening of that signal, you know, in the sense of signal and noise, has been, like, really interesting to us, I think. +ASHLEY: There's a system thinking expert that talks about how changes in a field are rarely made by the experts in the field but rather outsiders looking in. And so, for me, that's amazing because I don't have experience as a technology founder. I'm working with others who are founders in the technology space, which is great. +But it does leave some question marks for us as it relates to building some processes and doing some pilot mapping, which completely overcomable because we're able to draw on resources from within the thoughtbot organization. And then, also, just network, people within our network. Jordyn seems to know everybody. I'll be like, "Do you know somebody in North Dakota?" And she's like, "Actually, yes, my third cousin's sister lives there, and I can get her on the phone." And it's just -- +JORDYN: It's my first cousin. I will tell you, it's my straight-up first cousin. +ASHLEY: Well, there's always someone that Jordyn knows no matter where, it seems like, which is extremely helpful when we're trying to find experts to help us answer some questions. So, it's great to be able to work through problems in a very systematic way, using some of the strategies that thoughtbot has employed, I guess, over and over and can be applied to different industries. But it does help us find, what are the questions we still need answered? And then, who are the people that can help us answer these questions? And be very strategic about that. +JORDYN: I would add to that on the networking score. I think this is one of those things that first-time founders often struggle with. They struggle with recognizing who in their network is a valuable person to talk to in the first place. And then, they struggle with making those connections because it feels like you're asking people to do stuff for you, and that doesn't always feel great. +But really, your network, and where you come from, and the people you know and who care about you are one of your biggest assets going into this work. And it's important to take stock of those folks as early as you can and think about how to involve them. And often, they want to be involved. They're excited to have a way to support you and contribute their expertise or whatever else. +It's actually really transformed some of my relationships, like family relationships that I didn't necessarily have as...people I just discovered in my own sort of extended family who were doing related things to me. And we're much deeper friends now because we get to talk about that stuff all the time. And before I was a founder, we just didn't really talk [laughs]. So, just think through who you know and how they might be able to help you, and chances are they really want to. It's a very useful exercise. And it doesn't have to be super transactional. It can be a real bond builder. +ASHLEY: Yeah, I would say that's completely true, especially from my own experience. I don't like to ask people for help, generally. And so, asking people for their time and for their advice, I'm like, oh my gosh, why are they going to give this to me? What can I do for them? But it's really been amazing how generous people are with their knowledge, and insight, and their time. +I'm attending a conference next week for the 529 industry. And there have been so many helpful, kind people who are just experts in their field, leaders in their companies and are willing to talk to me about their experiences about what challenges they see. Because ultimately, you know, when a company succeeds and helps the industry grow, everybody grows and benefits from that. So, I hadn't really looked at it that way until Jordyn really encouraged me to just be, like, just call that person or just, you know, reach out. And sure enough, they were more than willing to be helpful. +DAWN: I imagine there is a sort of a bit of human factor here in that, you know, what you're giving to them is an opportunity for them to share, like, something that's, like, deeply important to them and that probably not a lot of people ask them about, even their day-to-day work. So, I imagine that can feel good, too, and maybe even sort of help them better understand [laughs], like, what it is they're doing. +So, you've definitely sunk into who to talk to. What about the how? Like, what are y'all doing now to try to continue validating that this is the right opportunity and that there's a product opportunity there? +ASHLEY: Yeah, so, really drilling down on those two cohorts that we mentioned a little earlier, specifically one of them, making sure that we are asking questions now related to this solution that we are thinking about, and more around their experience with similar type of products or similar type of solutions to make sure that we are thinking about building features or building process flows in a way that will integrate into the way they're used to doing things today so it doesn't seem like a new learning curve to, you know, think about adopting our product. +And then, also, just making sure that we are providing value, ultimately, because we don't want to just build something just to build something that we think will work for this group of people who told us that something is hard. We want to make sure that we're actually making something that's hard much easier than it already is. +JORDYN: Yeah. We've really, I mean, to build on that, we've gotten a little bit further into testing messaging, which is we think that we understand folks' problems and how they are talking about them, but we really need to validate that. And, you know, we have created some landing pages and are showing them to folks and getting their reactions. But we've also started doing a little bit of prototyping, which we hope to start showing folks soon. +And this is all just...a prototype, in this case, meaning this isn't, like, a clickable app. This is just, like, sort of a static design that appears clickable [laughs], think of it like a PDF with some links in it, and just showing that to folks and saying, you know, "What would you do here? How would you respond to this?" And it's just a really great way to...it's fast. It's easy to spin one of those up and then get them in front of folks and make sure that how we're thinking about this is sort of broadly in the right direction. +It's so much cheaper to find out that we're thinking about this wrongly with something like that than with an app that we spent six months building and launching, ha-ha. Now, who's done that before? Not me, no, never [laughs]. I've never wasted a year building a thing. So, it's a really fun thing to do. And sometimes you can even...it's not even, like, let's validate what we're thinking. Sometimes, it's really helpful to actually throw some curveballs in there on purpose to make sure we're invalidating the right things. So, it's really fun to be moving into that phase with what we know to be true and really getting closer to testing things out in, like, a real-world situation. +ASHLEY: It's somewhat surprising, too, what people are reacting to or not reacting to. The things that we thought people would be really excited about, they're like, "Eh." And the things that we thought are just kind of, like, filler on the page, they're like, "That's awesome." So, it's really crazy to see that juxtaposition. And then, you've got some people who will be like, "Huh, that's cool." And then, you've got some people who are like, "Can I sign up right now?" And you have to say, "We'll let you know when you can, but not right now." Just the differences are pretty surprising. +JORDYN: Yeah, and I'm glad you brought that up, Ashley, about, like, the stuff that you just kind of put on the page to make it look like a real page, and then people really zero in on it. There's just so much serendipity involved in this work. And part of the skill in making products is being open to the right things at the right time, right? You want to stay focused on your mission and what it is you're trying to accomplish. But you don't want to ignore, you know, if people are reacting really strongly to something that you thought was sort of ancillary, it's important to, like, take a beat and think about that. How does that fit in? Can we use that? +What you want to do is find lightning that you can bottle, and if people are not feeling lightning [laughs] about the primary thing you are working on but they are about something else, that's totally okay. I mean, the recent past of successful applications in software products is littered with stories like that, where people thought they were building one thing, and they just consistently heard about this related thing from their users. And they were like, well, why don't we just invest in that? It takes a lot of courage to stare in the face of that signal, the data that you're getting from people, and let go of the things that are not working and really embrace the things that are. +DAWN: This reminds me a little bit of the conversation we were having when we were together in New York last week around the focus on validating or invalidating. The conversation we were having was kind of trying to shift that away from ideas to assumptions. But this is making me think that it focuses too much on one single thing that you're trying to get an answer for, as opposed to, like you're saying, being open to sort of receiving signals about completely tangential things or things that you may have not been paying attention to before. So, that makes a lot of sense. +ASHLEY: Yeah. Now I'm thinking, like, should we put even more crazy things on the page and just see what happens? Who knows? +JORDYN: I think there's another aspect of this first-time founders often struggle with, which is that feeling that you shouldn't put anything on the page that you're testing that you couldn't actually do. And it's tough. It can feel a little bit like you're misleading people. But there's absolutely ethical ways to do this, where you tell people, "Hey, this is just an idea. We're just trying to get people's gut reactions to this. We have not even put pixel-to-paper here. We don't even know. We just want to get your reaction." +As long as you're transparent with folks about where you're at and about not promising them things you can't actually do, I mean, obviously, if it were as easy as just promising stuff to people of what they want, we could just make a landing page that said, like, "Free bag of money. Who wants free bag of money," right? [laughs] And people would be like, "Why is the bag of money free?" [laughs] Right? And so, you really want to be careful and not necessarily do anything that is misleading. +But on the other hand, there's no better way to get folks' emotional reaction than to put something together and just see how they respond to it. So, there's a lot of, like, sort of nuance to doing this. And, Dawn, to your point, the balancing act between being open and being scattered, right? That's a fine line. I've definitely been on teams before that are just, like, the new hotness every week. "Hey, there's this cool app out. Let's just immediately redesign everything to look just like that." And you're like, "Maybe? [laughs] I don't know if that's, like, the best idea." +So, it's a real balancing act, but it always comes back to who you're building for and what they want and need. And if you're staying very focused on that and measuring, you know, comparing every idea anything that comes your way against those, showing it to them and getting their reaction, you can't fail. Keeping no daylight between yourself and your customer that is the surest path. +DAWN: Yeah, it kind of carries through to the core thing that we're saying, which is don't focus on one thing to validate or invalidate. Be open to receiving signals from other, you know, opportunities. But that's not validating or invalidating something. That's showing you where to focus your time. And then the product experiments and feasibility research and all of that is designed to help you to get closer to validation. +But, in some cases, there's a point at which you have to take a risk, right? And your customers are ultimately going to tell you over time whether or not the solution was the right one. But you get more confidence. You get closer to the right solution the more strategic you are about that process, so...oh, go ahead. +ASHLEY: I think the great thing about technology, too, is it's not set in stone. You can change it. If you learn something new, you can modify what you're doing to fit what you're hearing, and I think that's so incredible. We live in a time where there are so many tools and resources out there to really be nimble. And just to Jordyn's point earlier, I think the hardest part is being willing to take in some of these signals and be like, okay, this is what they want, and being willing to move in that direction versus the path you have already designed in your head. +DAWN: Yeah, we've only got a couple of weeks left in this incubator [laughs]. How are y'all feeling? What are you planning? What are you looking forward to over the next couple of weeks? +ASHLEY: I can't believe that time went by so fast. I thought eight weeks felt like two years when we first started. I was like, oh, we've got so much time. We're going to do so much. We have done a lot. But the time has really flown by. So, I'm just kind of, like, now thinking about how do I make the most of the last few weeks? And just make sure that we check all the boxes that we set out to check in the beginning, and then have a plan from there in terms of continuing the work in a productive and, you know, exciting way. +JORDYN: Yeah, one of the, like, sort of Northstar outcome for us in the incubator is to give the founder confidence in what they're doing and their path, the confidence in that vision, and then enough confidence to articulate it consistently to the folks they need to sort of bring along with them. So, what I'm, like, really looking forward to in the next couple of weeks is honing that story for Ashley. Like, what's your story? What's your why? What's your how? What's your when? And how to make sure that story is just easy to communicate. +I mean, already, Ashley, like, up top of this exact livestream where you articulated sort of, like, what AvidFirst is doing, I think I feel better and better about that articulation given what we know. It feels really good. It feels solid. And as we're going, we're just as skeptical as anyone else, right? But we're trying to anticipate what folks...external stakeholders broadly define what their misgivings are going to be. And we're compiling a kind of list of frequently asked questions about what AvidFirst is doing, like, why 529s? Why next-gen consumers? Et cetera. Just so that that story is so internalized that, like, you can't really be taken off guard necessarily. +I mean, you want to be open to new questions and new ideas. That's not what I'm saying. But just basically, like, being able to thoroughly and deeply, at the drop of a hat, to sort of pitch this to your dentist while they're cleaning your teeth, you know, like that kind of conviction and, like, the solidity of the narrative is really what we're going for in the next few weeks. +And I think we're well on our way there. We have all the pieces. It's about putting it together coherently, I think, at this point. It's really exciting, though. I do feel like we're really zeroing in on a valuable lens on college saving and spending that I think the market is really ripe for, so it's exciting. +DAWN: Yeah, it's been great to see all the progress. We have a comment that I just noticed. +ASHLEY: Oh. +DAWN: Not a question, but I wanted to call it out because it was related to what you were talking about a few minutes ago, Jordyn. Kiran said they totally agree. "We had the same epiphany/pivot this summer. We went from direct-to-consumer to an enterprise model. Try to zoom out with a systems thinking lens, and it will help with a clearer path and tell your story." +JORDYN: Yeah, that's awesome. +DAWN: There are no other questions from the audience. And it seems like maybe there's still a little bit of a lag. So [laughs], we can wrap up. If anybody has questions after this, feel free to comment. We'll be, you know, checking out the posts on LinkedIn and YouTube. And we can follow up there. +You can always, like I said, come and follow along. Check out our thoughtbot.com incubator site. You can both apply to the next incubator session and sign up to hear from us in our weekly newsletter. We write about progress on our blog as well, so thoughtbot.com/blog. There's all kinds of ways to find us and actually talking about the work that we're doing. So, please follow along. +JORDYN: Anyone out there who's wondering, am I right for the incubator? Just apply. It's really, like, nothing is too early if it's just an idea you've been kicking around that's born of your industry experience or your personal experience. The application process is really lightweight. This is not going to take you days to fill out this application. +We've heard from folks that even filling out the application is the first thing they ever did with regard to the idea, helped solidify it, and solidify their thinking for them. So, just go apply. You got something? You got an idea for an app? You see a growing market out there, and you feel like it's underserved with software? Just holler at us. We'd love to hear it. Apply. It's fun [laughs]. +DAWN: Yeah. Thanks, everybody, for tuning in. Thanks, Jordyn and Ashley, for participating. See you again in a couple of weeks, yeah? +JORDYN: Yes. It'll be the last week, so we'll have things to say, no doubt. +DAWN: Yes, tune in. It'll be a good time. All right. Thanks, everybody. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or a development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Ashley Sheble, Dawn Delatte, and Jordyn Bonds. + + + Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product.

+ +

In the third part of the Mini Incubator Series, they talk about user interviews, data analysis, and prototyping to validate ideas. They emphasize the importance of being open to user signals and adjusting their approach accordingly. They also discuss the upcoming weeks of the program and the goal of refining their story and business strategy.

+ +

Just catching up? Listen to Part I and Part 2 of the Mini Incubator Series!

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

DAWN: Thanks, everybody, for joining. We're glad that you're here. If you've tuned in before, great, welcome back. You're probably familiar with thoughtbot; if you're not, we're a product design and development consultancy that helps make you, and your team, and your product successful.

+ +

We are currently running the second session of our incubator program, which is an eight-week program that takes you through a lot of different activities and exercises to help you identify market and product opportunities, experiment with them, and ideally come up with a solution that you can move forward with.

+ +

I'm Dawn. I'm a Managing Director here at thoughtbot. And I lead a team that works with very early-stage products, and founders, and companies. And I'll hand it over to Jordyn.

+ +

JORDYN: I'm Jordyn Bonds, and I'm the Director of Product Strategy on Dawn's team. And I'm kind of the...I don't know what, founder in residence for the incubator trying to bring my experience as a former founder to bear for our participants, in this case, Ashley.

+ +

ASHLEY: Okay, my name is Ashley Sheble. I'm the CEO and founder of AvidFirst and have been working with Jordyn and a great team in the second incubator session. So, removing all bias from the statement I'm about to say, but if anybody's thinking about applying to the next incubator, just do it. It's an amazing experience. You're going to learn so much. There are so many smart, helpful people who really care about building cool products that make a difference. And so, do it.

+ +

DAWN: I love it. Thanks for the impromptu promo.

+ +

JORDYN: Yeah, thank you [laughs]. It's good to hear.

+ +

DAWN: Yeah, I'm excited. Cool. Well, Ashley, why don't you maybe kick us off with a little bit of a recap of these past two weeks? What have y'all been working on?

+ +

ASHLEY: Yeah, so, just for a little background, in case anybody hasn't been following along, AvidFirst is a technology company aimed at simplifying college saving and spending. Our goal is really to make 529 accounts more usable broadly and then, more specifically, attractive to next-gen consumers.

+ +

And for those who aren't familiar with 529 plans, that's okay because neither are about 70% of Americans. But essentially, they are college savings vehicles. They're investment accounts that allow people to contribute money. The money grows tax-free and then can be withdrawn tax-free when used for qualified education expenses.

+ +

And over the past few years, the term qualified education expense has really expanded from beyond just tuition and fees to room and board on and off campus, computers, technology, supplies, apprenticeships, K through 12, like, the list is getting longer and longer. And so, our goal is just to really help simplify a really complex system and savings vehicle to make them more appealing and attractive to people.

+ +

So, the past few weeks, specifically, we have been aggregating all the data from our user interviews. We've done a lot of user interviews with different stakeholders and have been taking the information and saying, okay, what do we do next? How do we validate the way we're thinking about solving this problem will actually solve the problem in the way that we think it will? And so, through lots of process mapping, brainstorming different pilot initiatives, and then now working through some of the nuances of the industry. The 529 industry, specifically, is a complex animal. I don't really know how else to explain it. It's very complex. And so, we are just navigating these complexities and looking for solutions that will truly simplify the complexity.

+ +

JORDYN: I will just dig in a little bit to that analysis of the interviews that we've been conducting. That analysis kind of, like, stepped up a notch in the last week in a really fun way where we, the team, really kind of dug into the dynamics of each interview, sort of the things that we're most curious about, and have been asking and really, like, scored each interview. And then did sort of a cohort analysis, like, where are the trends with which personas?

+ +

We had already had some intuitions, and we just wanted to confirm with the data that we weren't deluding ourselves about what the direction was. So, that was a really, like, I think it was a really useful exercise and kind of fun to see. And what doing that helps with is our own conviction, but then it also helps us make sure that we are honing who we're talking to going forward.

+ +

Talking to folks is, like, so critical and is so not scalable. It is so time-consuming [laughs]. So, you want to make sure that you're doing it really strategically. So, it's sort of, like, every wave of interviews we do, we do a little more analysis. And it's, like, we finally got to a critical number where we felt like doing this data pass was going to be statistically significant. We had enough interviews to really focus the interviews we're going to do going forward. So, just to give a little, like, lens into how that's worked and how we've been thinking about it.

+ +

DAWN: I think we ask this question often, maybe every time, but I'm interested to see how it continues to evolve. But what was something that you learned these past two weeks that really surprised you or maybe even confirmed your hunches?

+ +

JORDYN: So, as often happens, when you start talking to a focus group of people who share a lot of pain points in their lives or their work, you end up with, like, a lot of trends. Like, there might be a thing you're asking them about that you're particularly focused on or curious about, and you want to focus your questions on that. But invariably, you're talking to a human being, and they're going to talk about a lot of different things.

+ +

And so, early on, and when we started interviewing people at the very beginning of this project in August, you know, we were very focused on college savings and spending. But an interesting thing, like, sort of trend that came up was also how much parents care about imparting, you know, some sense of financial responsibility in their young adults [laughs]. And we were like, well, that's interesting. Okay, let's, like, keep an eye on that. Maybe that's interesting to us.

+ +

And what has kind of surprised me in the last couple of weeks is how much of that has sort of solidified. This is not, like, a news flash, by the way, like I think [laughs]. This is, like, a thing. Anyone who has teenagers out there is like, duh, like, why is this shocking to you? But the way that it ties into college savings and spending, I think we found some really interesting connections and threads there that have only gotten stronger with the specific cohorts that we've been talking to.

+ +

So, I think that we, at first, had started as just this sort of, like, well, that's interesting, but we'll see where it goes kind of thing. And now it's, like, become a little bit more core to how we're thinking about just broadly what folks are facing, who we're addressing. So, I guess it wasn't, like, a surprise, but, like, the deepening of that signal, you know, in the sense of signal and noise, has been, like, really interesting to us, I think.

+ +

ASHLEY: There's a system thinking expert that talks about how changes in a field are rarely made by the experts in the field but rather outsiders looking in. And so, for me, that's amazing because I don't have experience as a technology founder. I'm working with others who are founders in the technology space, which is great.

+ +

But it does leave some question marks for us as it relates to building some processes and doing some pilot mapping, which completely overcomable because we're able to draw on resources from within the thoughtbot organization. And then, also, just network, people within our network. Jordyn seems to know everybody. I'll be like, "Do you know somebody in North Dakota?" And she's like, "Actually, yes, my third cousin's sister lives there, and I can get her on the phone." And it's just --

+ +

JORDYN: It's my first cousin. I will tell you, it's my straight-up first cousin.

+ +

ASHLEY: Well, there's always someone that Jordyn knows no matter where, it seems like, which is extremely helpful when we're trying to find experts to help us answer some questions. So, it's great to be able to work through problems in a very systematic way, using some of the strategies that thoughtbot has employed, I guess, over and over and can be applied to different industries. But it does help us find, what are the questions we still need answered? And then, who are the people that can help us answer these questions? And be very strategic about that.

+ +

JORDYN: I would add to that on the networking score. I think this is one of those things that first-time founders often struggle with. They struggle with recognizing who in their network is a valuable person to talk to in the first place. And then, they struggle with making those connections because it feels like you're asking people to do stuff for you, and that doesn't always feel great.

+ +

But really, your network, and where you come from, and the people you know and who care about you are one of your biggest assets going into this work. And it's important to take stock of those folks as early as you can and think about how to involve them. And often, they want to be involved. They're excited to have a way to support you and contribute their expertise or whatever else.

+ +

It's actually really transformed some of my relationships, like family relationships that I didn't necessarily have as...people I just discovered in my own sort of extended family who were doing related things to me. And we're much deeper friends now because we get to talk about that stuff all the time. And before I was a founder, we just didn't really talk [laughs]. So, just think through who you know and how they might be able to help you, and chances are they really want to. It's a very useful exercise. And it doesn't have to be super transactional. It can be a real bond builder.

+ +

ASHLEY: Yeah, I would say that's completely true, especially from my own experience. I don't like to ask people for help, generally. And so, asking people for their time and for their advice, I'm like, oh my gosh, why are they going to give this to me? What can I do for them? But it's really been amazing how generous people are with their knowledge, and insight, and their time.

+ +

I'm attending a conference next week for the 529 industry. And there have been so many helpful, kind people who are just experts in their field, leaders in their companies and are willing to talk to me about their experiences about what challenges they see. Because ultimately, you know, when a company succeeds and helps the industry grow, everybody grows and benefits from that. So, I hadn't really looked at it that way until Jordyn really encouraged me to just be, like, just call that person or just, you know, reach out. And sure enough, they were more than willing to be helpful.

+ +

DAWN: I imagine there is a sort of a bit of human factor here in that, you know, what you're giving to them is an opportunity for them to share, like, something that's, like, deeply important to them and that probably not a lot of people ask them about, even their day-to-day work. So, I imagine that can feel good, too, and maybe even sort of help them better understand [laughs], like, what it is they're doing.

+ +

So, you've definitely sunk into who to talk to. What about the how? Like, what are y'all doing now to try to continue validating that this is the right opportunity and that there's a product opportunity there?

+ +

ASHLEY: Yeah, so, really drilling down on those two cohorts that we mentioned a little earlier, specifically one of them, making sure that we are asking questions now related to this solution that we are thinking about, and more around their experience with similar type of products or similar type of solutions to make sure that we are thinking about building features or building process flows in a way that will integrate into the way they're used to doing things today so it doesn't seem like a new learning curve to, you know, think about adopting our product.

+ +

And then, also, just making sure that we are providing value, ultimately, because we don't want to just build something just to build something that we think will work for this group of people who told us that something is hard. We want to make sure that we're actually making something that's hard much easier than it already is.

+ +

JORDYN: Yeah. We've really, I mean, to build on that, we've gotten a little bit further into testing messaging, which is we think that we understand folks' problems and how they are talking about them, but we really need to validate that. And, you know, we have created some landing pages and are showing them to folks and getting their reactions. But we've also started doing a little bit of prototyping, which we hope to start showing folks soon.

+ +

And this is all just...a prototype, in this case, meaning this isn't, like, a clickable app. This is just, like, sort of a static design that appears clickable [laughs], think of it like a PDF with some links in it, and just showing that to folks and saying, you know, "What would you do here? How would you respond to this?" And it's just a really great way to...it's fast. It's easy to spin one of those up and then get them in front of folks and make sure that how we're thinking about this is sort of broadly in the right direction.

+ +

It's so much cheaper to find out that we're thinking about this wrongly with something like that than with an app that we spent six months building and launching, ha-ha. Now, who's done that before? Not me, no, never [laughs]. I've never wasted a year building a thing. So, it's a really fun thing to do. And sometimes you can even...it's not even, like, let's validate what we're thinking. Sometimes, it's really helpful to actually throw some curveballs in there on purpose to make sure we're invalidating the right things. So, it's really fun to be moving into that phase with what we know to be true and really getting closer to testing things out in, like, a real-world situation.

+ +

ASHLEY: It's somewhat surprising, too, what people are reacting to or not reacting to. The things that we thought people would be really excited about, they're like, "Eh." And the things that we thought are just kind of, like, filler on the page, they're like, "That's awesome." So, it's really crazy to see that juxtaposition. And then, you've got some people who will be like, "Huh, that's cool." And then, you've got some people who are like, "Can I sign up right now?" And you have to say, "We'll let you know when you can, but not right now." Just the differences are pretty surprising.

+ +

JORDYN: Yeah, and I'm glad you brought that up, Ashley, about, like, the stuff that you just kind of put on the page to make it look like a real page, and then people really zero in on it. There's just so much serendipity involved in this work. And part of the skill in making products is being open to the right things at the right time, right? You want to stay focused on your mission and what it is you're trying to accomplish. But you don't want to ignore, you know, if people are reacting really strongly to something that you thought was sort of ancillary, it's important to, like, take a beat and think about that. How does that fit in? Can we use that?

+ +

What you want to do is find lightning that you can bottle, and if people are not feeling lightning [laughs] about the primary thing you are working on but they are about something else, that's totally okay. I mean, the recent past of successful applications in software products is littered with stories like that, where people thought they were building one thing, and they just consistently heard about this related thing from their users. And they were like, well, why don't we just invest in that? It takes a lot of courage to stare in the face of that signal, the data that you're getting from people, and let go of the things that are not working and really embrace the things that are.

+ +

DAWN: This reminds me a little bit of the conversation we were having when we were together in New York last week around the focus on validating or invalidating. The conversation we were having was kind of trying to shift that away from ideas to assumptions. But this is making me think that it focuses too much on one single thing that you're trying to get an answer for, as opposed to, like you're saying, being open to sort of receiving signals about completely tangential things or things that you may have not been paying attention to before. So, that makes a lot of sense.

+ +

ASHLEY: Yeah. Now I'm thinking, like, should we put even more crazy things on the page and just see what happens? Who knows?

+ +

JORDYN: I think there's another aspect of this first-time founders often struggle with, which is that feeling that you shouldn't put anything on the page that you're testing that you couldn't actually do. And it's tough. It can feel a little bit like you're misleading people. But there's absolutely ethical ways to do this, where you tell people, "Hey, this is just an idea. We're just trying to get people's gut reactions to this. We have not even put pixel-to-paper here. We don't even know. We just want to get your reaction."

+ +

As long as you're transparent with folks about where you're at and about not promising them things you can't actually do, I mean, obviously, if it were as easy as just promising stuff to people of what they want, we could just make a landing page that said, like, "Free bag of money. Who wants free bag of money," right? [laughs] And people would be like, "Why is the bag of money free?" [laughs] Right? And so, you really want to be careful and not necessarily do anything that is misleading.

+ +

But on the other hand, there's no better way to get folks' emotional reaction than to put something together and just see how they respond to it. So, there's a lot of, like, sort of nuance to doing this. And, Dawn, to your point, the balancing act between being open and being scattered, right? That's a fine line. I've definitely been on teams before that are just, like, the new hotness every week. "Hey, there's this cool app out. Let's just immediately redesign everything to look just like that." And you're like, "Maybe? [laughs] I don't know if that's, like, the best idea."

+ +

So, it's a real balancing act, but it always comes back to who you're building for and what they want and need. And if you're staying very focused on that and measuring, you know, comparing every idea anything that comes your way against those, showing it to them and getting their reaction, you can't fail. Keeping no daylight between yourself and your customer that is the surest path.

+ +

DAWN: Yeah, it kind of carries through to the core thing that we're saying, which is don't focus on one thing to validate or invalidate. Be open to receiving signals from other, you know, opportunities. But that's not validating or invalidating something. That's showing you where to focus your time. And then the product experiments and feasibility research and all of that is designed to help you to get closer to validation.

+ +

But, in some cases, there's a point at which you have to take a risk, right? And your customers are ultimately going to tell you over time whether or not the solution was the right one. But you get more confidence. You get closer to the right solution the more strategic you are about that process, so...oh, go ahead.

+ +

ASHLEY: I think the great thing about technology, too, is it's not set in stone. You can change it. If you learn something new, you can modify what you're doing to fit what you're hearing, and I think that's so incredible. We live in a time where there are so many tools and resources out there to really be nimble. And just to Jordyn's point earlier, I think the hardest part is being willing to take in some of these signals and be like, okay, this is what they want, and being willing to move in that direction versus the path you have already designed in your head.

+ +

DAWN: Yeah, we've only got a couple of weeks left in this incubator [laughs]. How are y'all feeling? What are you planning? What are you looking forward to over the next couple of weeks?

+ +

ASHLEY: I can't believe that time went by so fast. I thought eight weeks felt like two years when we first started. I was like, oh, we've got so much time. We're going to do so much. We have done a lot. But the time has really flown by. So, I'm just kind of, like, now thinking about how do I make the most of the last few weeks? And just make sure that we check all the boxes that we set out to check in the beginning, and then have a plan from there in terms of continuing the work in a productive and, you know, exciting way.

+ +

JORDYN: Yeah, one of the, like, sort of Northstar outcome for us in the incubator is to give the founder confidence in what they're doing and their path, the confidence in that vision, and then enough confidence to articulate it consistently to the folks they need to sort of bring along with them. So, what I'm, like, really looking forward to in the next couple of weeks is honing that story for Ashley. Like, what's your story? What's your why? What's your how? What's your when? And how to make sure that story is just easy to communicate.

+ +

I mean, already, Ashley, like, up top of this exact livestream where you articulated sort of, like, what AvidFirst is doing, I think I feel better and better about that articulation given what we know. It feels really good. It feels solid. And as we're going, we're just as skeptical as anyone else, right? But we're trying to anticipate what folks...external stakeholders broadly define what their misgivings are going to be. And we're compiling a kind of list of frequently asked questions about what AvidFirst is doing, like, why 529s? Why next-gen consumers? Et cetera. Just so that that story is so internalized that, like, you can't really be taken off guard necessarily.

+ +

I mean, you want to be open to new questions and new ideas. That's not what I'm saying. But just basically, like, being able to thoroughly and deeply, at the drop of a hat, to sort of pitch this to your dentist while they're cleaning your teeth, you know, like that kind of conviction and, like, the solidity of the narrative is really what we're going for in the next few weeks.

+ +

And I think we're well on our way there. We have all the pieces. It's about putting it together coherently, I think, at this point. It's really exciting, though. I do feel like we're really zeroing in on a valuable lens on college saving and spending that I think the market is really ripe for, so it's exciting.

+ +

DAWN: Yeah, it's been great to see all the progress. We have a comment that I just noticed.

+ +

ASHLEY: Oh.

+ +

DAWN: Not a question, but I wanted to call it out because it was related to what you were talking about a few minutes ago, Jordyn. Kiran said they totally agree. "We had the same epiphany/pivot this summer. We went from direct-to-consumer to an enterprise model. Try to zoom out with a systems thinking lens, and it will help with a clearer path and tell your story."

+ +

JORDYN: Yeah, that's awesome.

+ +

DAWN: There are no other questions from the audience. And it seems like maybe there's still a little bit of a lag. So [laughs], we can wrap up. If anybody has questions after this, feel free to comment. We'll be, you know, checking out the posts on LinkedIn and YouTube. And we can follow up there.

+ +

You can always, like I said, come and follow along. Check out our thoughtbot.com incubator site. You can both apply to the next incubator session and sign up to hear from us in our weekly newsletter. We write about progress on our blog as well, so thoughtbot.com/blog. There's all kinds of ways to find us and actually talking about the work that we're doing. So, please follow along.

+ +

JORDYN: Anyone out there who's wondering, am I right for the incubator? Just apply. It's really, like, nothing is too early if it's just an idea you've been kicking around that's born of your industry experience or your personal experience. The application process is really lightweight. This is not going to take you days to fill out this application.

+ +

We've heard from folks that even filling out the application is the first thing they ever did with regard to the idea, helped solidify it, and solidify their thinking for them. So, just go apply. You got something? You got an idea for an app? You see a growing market out there, and you feel like it's underserved with software? Just holler at us. We'd love to hear it. Apply. It's fun [laughs].

+ +

DAWN: Yeah. Thanks, everybody, for tuning in. Thanks, Jordyn and Ashley, for participating. See you again in a couple of weeks, yeah?

+ +

JORDYN: Yes. It'll be the last week, so we'll have things to say, no doubt.

+ +

DAWN: Yes, tune in. It'll be a good time. All right. Thanks, everybody.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or a development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble, Dawn Delatte, and Jordyn Bonds.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product.

+ +

In the third part of the Mini Incubator Series, they talk about user interviews, data analysis, and prototyping to validate ideas. They emphasize the importance of being open to user signals and adjusting their approach accordingly. They also discuss the upcoming weeks of the program and the goal of refining their story and business strategy.

+ +

Just catching up? Listen to Part I and Part 2 of the Mini Incubator Series!

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

DAWN: Thanks, everybody, for joining. We're glad that you're here. If you've tuned in before, great, welcome back. You're probably familiar with thoughtbot; if you're not, we're a product design and development consultancy that helps make you, and your team, and your product successful.

+ +

We are currently running the second session of our incubator program, which is an eight-week program that takes you through a lot of different activities and exercises to help you identify market and product opportunities, experiment with them, and ideally come up with a solution that you can move forward with.

+ +

I'm Dawn. I'm a Managing Director here at thoughtbot. And I lead a team that works with very early-stage products, and founders, and companies. And I'll hand it over to Jordyn.

+ +

JORDYN: I'm Jordyn Bonds, and I'm the Director of Product Strategy on Dawn's team. And I'm kind of the...I don't know what, founder in residence for the incubator trying to bring my experience as a former founder to bear for our participants, in this case, Ashley.

+ +

ASHLEY: Okay, my name is Ashley Sheble. I'm the CEO and founder of AvidFirst and have been working with Jordyn and a great team in the second incubator session. So, removing all bias from the statement I'm about to say, but if anybody's thinking about applying to the next incubator, just do it. It's an amazing experience. You're going to learn so much. There are so many smart, helpful people who really care about building cool products that make a difference. And so, do it.

+ +

DAWN: I love it. Thanks for the impromptu promo.

+ +

JORDYN: Yeah, thank you [laughs]. It's good to hear.

+ +

DAWN: Yeah, I'm excited. Cool. Well, Ashley, why don't you maybe kick us off with a little bit of a recap of these past two weeks? What have y'all been working on?

+ +

ASHLEY: Yeah, so, just for a little background, in case anybody hasn't been following along, AvidFirst is a technology company aimed at simplifying college saving and spending. Our goal is really to make 529 accounts more usable broadly and then, more specifically, attractive to next-gen consumers.

+ +

And for those who aren't familiar with 529 plans, that's okay because neither are about 70% of Americans. But essentially, they are college savings vehicles. They're investment accounts that allow people to contribute money. The money grows tax-free and then can be withdrawn tax-free when used for qualified education expenses.

+ +

And over the past few years, the term qualified education expense has really expanded from beyond just tuition and fees to room and board on and off campus, computers, technology, supplies, apprenticeships, K through 12, like, the list is getting longer and longer. And so, our goal is just to really help simplify a really complex system and savings vehicle to make them more appealing and attractive to people.

+ +

So, the past few weeks, specifically, we have been aggregating all the data from our user interviews. We've done a lot of user interviews with different stakeholders and have been taking the information and saying, okay, what do we do next? How do we validate the way we're thinking about solving this problem will actually solve the problem in the way that we think it will? And so, through lots of process mapping, brainstorming different pilot initiatives, and then now working through some of the nuances of the industry. The 529 industry, specifically, is a complex animal. I don't really know how else to explain it. It's very complex. And so, we are just navigating these complexities and looking for solutions that will truly simplify the complexity.

+ +

JORDYN: I will just dig in a little bit to that analysis of the interviews that we've been conducting. That analysis kind of, like, stepped up a notch in the last week in a really fun way where we, the team, really kind of dug into the dynamics of each interview, sort of the things that we're most curious about, and have been asking and really, like, scored each interview. And then did sort of a cohort analysis, like, where are the trends with which personas?

+ +

We had already had some intuitions, and we just wanted to confirm with the data that we weren't deluding ourselves about what the direction was. So, that was a really, like, I think it was a really useful exercise and kind of fun to see. And what doing that helps with is our own conviction, but then it also helps us make sure that we are honing who we're talking to going forward.

+ +

Talking to folks is, like, so critical and is so not scalable. It is so time-consuming [laughs]. So, you want to make sure that you're doing it really strategically. So, it's sort of, like, every wave of interviews we do, we do a little more analysis. And it's, like, we finally got to a critical number where we felt like doing this data pass was going to be statistically significant. We had enough interviews to really focus the interviews we're going to do going forward. So, just to give a little, like, lens into how that's worked and how we've been thinking about it.

+ +

DAWN: I think we ask this question often, maybe every time, but I'm interested to see how it continues to evolve. But what was something that you learned these past two weeks that really surprised you or maybe even confirmed your hunches?

+ +

JORDYN: So, as often happens, when you start talking to a focus group of people who share a lot of pain points in their lives or their work, you end up with, like, a lot of trends. Like, there might be a thing you're asking them about that you're particularly focused on or curious about, and you want to focus your questions on that. But invariably, you're talking to a human being, and they're going to talk about a lot of different things.

+ +

And so, early on, and when we started interviewing people at the very beginning of this project in August, you know, we were very focused on college savings and spending. But an interesting thing, like, sort of trend that came up was also how much parents care about imparting, you know, some sense of financial responsibility in their young adults [laughs]. And we were like, well, that's interesting. Okay, let's, like, keep an eye on that. Maybe that's interesting to us.

+ +

And what has kind of surprised me in the last couple of weeks is how much of that has sort of solidified. This is not, like, a news flash, by the way, like I think [laughs]. This is, like, a thing. Anyone who has teenagers out there is like, duh, like, why is this shocking to you? But the way that it ties into college savings and spending, I think we found some really interesting connections and threads there that have only gotten stronger with the specific cohorts that we've been talking to.

+ +

So, I think that we, at first, had started as just this sort of, like, well, that's interesting, but we'll see where it goes kind of thing. And now it's, like, become a little bit more core to how we're thinking about just broadly what folks are facing, who we're addressing. So, I guess it wasn't, like, a surprise, but, like, the deepening of that signal, you know, in the sense of signal and noise, has been, like, really interesting to us, I think.

+ +

ASHLEY: There's a system thinking expert that talks about how changes in a field are rarely made by the experts in the field but rather outsiders looking in. And so, for me, that's amazing because I don't have experience as a technology founder. I'm working with others who are founders in the technology space, which is great.

+ +

But it does leave some question marks for us as it relates to building some processes and doing some pilot mapping, which completely overcomable because we're able to draw on resources from within the thoughtbot organization. And then, also, just network, people within our network. Jordyn seems to know everybody. I'll be like, "Do you know somebody in North Dakota?" And she's like, "Actually, yes, my third cousin's sister lives there, and I can get her on the phone." And it's just --

+ +

JORDYN: It's my first cousin. I will tell you, it's my straight-up first cousin.

+ +

ASHLEY: Well, there's always someone that Jordyn knows no matter where, it seems like, which is extremely helpful when we're trying to find experts to help us answer some questions. So, it's great to be able to work through problems in a very systematic way, using some of the strategies that thoughtbot has employed, I guess, over and over and can be applied to different industries. But it does help us find, what are the questions we still need answered? And then, who are the people that can help us answer these questions? And be very strategic about that.

+ +

JORDYN: I would add to that on the networking score. I think this is one of those things that first-time founders often struggle with. They struggle with recognizing who in their network is a valuable person to talk to in the first place. And then, they struggle with making those connections because it feels like you're asking people to do stuff for you, and that doesn't always feel great.

+ +

But really, your network, and where you come from, and the people you know and who care about you are one of your biggest assets going into this work. And it's important to take stock of those folks as early as you can and think about how to involve them. And often, they want to be involved. They're excited to have a way to support you and contribute their expertise or whatever else.

+ +

It's actually really transformed some of my relationships, like family relationships that I didn't necessarily have as...people I just discovered in my own sort of extended family who were doing related things to me. And we're much deeper friends now because we get to talk about that stuff all the time. And before I was a founder, we just didn't really talk [laughs]. So, just think through who you know and how they might be able to help you, and chances are they really want to. It's a very useful exercise. And it doesn't have to be super transactional. It can be a real bond builder.

+ +

ASHLEY: Yeah, I would say that's completely true, especially from my own experience. I don't like to ask people for help, generally. And so, asking people for their time and for their advice, I'm like, oh my gosh, why are they going to give this to me? What can I do for them? But it's really been amazing how generous people are with their knowledge, and insight, and their time.

+ +

I'm attending a conference next week for the 529 industry. And there have been so many helpful, kind people who are just experts in their field, leaders in their companies and are willing to talk to me about their experiences about what challenges they see. Because ultimately, you know, when a company succeeds and helps the industry grow, everybody grows and benefits from that. So, I hadn't really looked at it that way until Jordyn really encouraged me to just be, like, just call that person or just, you know, reach out. And sure enough, they were more than willing to be helpful.

+ +

DAWN: I imagine there is a sort of a bit of human factor here in that, you know, what you're giving to them is an opportunity for them to share, like, something that's, like, deeply important to them and that probably not a lot of people ask them about, even their day-to-day work. So, I imagine that can feel good, too, and maybe even sort of help them better understand [laughs], like, what it is they're doing.

+ +

So, you've definitely sunk into who to talk to. What about the how? Like, what are y'all doing now to try to continue validating that this is the right opportunity and that there's a product opportunity there?

+ +

ASHLEY: Yeah, so, really drilling down on those two cohorts that we mentioned a little earlier, specifically one of them, making sure that we are asking questions now related to this solution that we are thinking about, and more around their experience with similar type of products or similar type of solutions to make sure that we are thinking about building features or building process flows in a way that will integrate into the way they're used to doing things today so it doesn't seem like a new learning curve to, you know, think about adopting our product.

+ +

And then, also, just making sure that we are providing value, ultimately, because we don't want to just build something just to build something that we think will work for this group of people who told us that something is hard. We want to make sure that we're actually making something that's hard much easier than it already is.

+ +

JORDYN: Yeah. We've really, I mean, to build on that, we've gotten a little bit further into testing messaging, which is we think that we understand folks' problems and how they are talking about them, but we really need to validate that. And, you know, we have created some landing pages and are showing them to folks and getting their reactions. But we've also started doing a little bit of prototyping, which we hope to start showing folks soon.

+ +

And this is all just...a prototype, in this case, meaning this isn't, like, a clickable app. This is just, like, sort of a static design that appears clickable [laughs], think of it like a PDF with some links in it, and just showing that to folks and saying, you know, "What would you do here? How would you respond to this?" And it's just a really great way to...it's fast. It's easy to spin one of those up and then get them in front of folks and make sure that how we're thinking about this is sort of broadly in the right direction.

+ +

It's so much cheaper to find out that we're thinking about this wrongly with something like that than with an app that we spent six months building and launching, ha-ha. Now, who's done that before? Not me, no, never [laughs]. I've never wasted a year building a thing. So, it's a really fun thing to do. And sometimes you can even...it's not even, like, let's validate what we're thinking. Sometimes, it's really helpful to actually throw some curveballs in there on purpose to make sure we're invalidating the right things. So, it's really fun to be moving into that phase with what we know to be true and really getting closer to testing things out in, like, a real-world situation.

+ +

ASHLEY: It's somewhat surprising, too, what people are reacting to or not reacting to. The things that we thought people would be really excited about, they're like, "Eh." And the things that we thought are just kind of, like, filler on the page, they're like, "That's awesome." So, it's really crazy to see that juxtaposition. And then, you've got some people who will be like, "Huh, that's cool." And then, you've got some people who are like, "Can I sign up right now?" And you have to say, "We'll let you know when you can, but not right now." Just the differences are pretty surprising.

+ +

JORDYN: Yeah, and I'm glad you brought that up, Ashley, about, like, the stuff that you just kind of put on the page to make it look like a real page, and then people really zero in on it. There's just so much serendipity involved in this work. And part of the skill in making products is being open to the right things at the right time, right? You want to stay focused on your mission and what it is you're trying to accomplish. But you don't want to ignore, you know, if people are reacting really strongly to something that you thought was sort of ancillary, it's important to, like, take a beat and think about that. How does that fit in? Can we use that?

+ +

What you want to do is find lightning that you can bottle, and if people are not feeling lightning [laughs] about the primary thing you are working on but they are about something else, that's totally okay. I mean, the recent past of successful applications in software products is littered with stories like that, where people thought they were building one thing, and they just consistently heard about this related thing from their users. And they were like, well, why don't we just invest in that? It takes a lot of courage to stare in the face of that signal, the data that you're getting from people, and let go of the things that are not working and really embrace the things that are.

+ +

DAWN: This reminds me a little bit of the conversation we were having when we were together in New York last week around the focus on validating or invalidating. The conversation we were having was kind of trying to shift that away from ideas to assumptions. But this is making me think that it focuses too much on one single thing that you're trying to get an answer for, as opposed to, like you're saying, being open to sort of receiving signals about completely tangential things or things that you may have not been paying attention to before. So, that makes a lot of sense.

+ +

ASHLEY: Yeah. Now I'm thinking, like, should we put even more crazy things on the page and just see what happens? Who knows?

+ +

JORDYN: I think there's another aspect of this first-time founders often struggle with, which is that feeling that you shouldn't put anything on the page that you're testing that you couldn't actually do. And it's tough. It can feel a little bit like you're misleading people. But there's absolutely ethical ways to do this, where you tell people, "Hey, this is just an idea. We're just trying to get people's gut reactions to this. We have not even put pixel-to-paper here. We don't even know. We just want to get your reaction."

+ +

As long as you're transparent with folks about where you're at and about not promising them things you can't actually do, I mean, obviously, if it were as easy as just promising stuff to people of what they want, we could just make a landing page that said, like, "Free bag of money. Who wants free bag of money," right? [laughs] And people would be like, "Why is the bag of money free?" [laughs] Right? And so, you really want to be careful and not necessarily do anything that is misleading.

+ +

But on the other hand, there's no better way to get folks' emotional reaction than to put something together and just see how they respond to it. So, there's a lot of, like, sort of nuance to doing this. And, Dawn, to your point, the balancing act between being open and being scattered, right? That's a fine line. I've definitely been on teams before that are just, like, the new hotness every week. "Hey, there's this cool app out. Let's just immediately redesign everything to look just like that." And you're like, "Maybe? [laughs] I don't know if that's, like, the best idea."

+ +

So, it's a real balancing act, but it always comes back to who you're building for and what they want and need. And if you're staying very focused on that and measuring, you know, comparing every idea anything that comes your way against those, showing it to them and getting their reaction, you can't fail. Keeping no daylight between yourself and your customer that is the surest path.

+ +

DAWN: Yeah, it kind of carries through to the core thing that we're saying, which is don't focus on one thing to validate or invalidate. Be open to receiving signals from other, you know, opportunities. But that's not validating or invalidating something. That's showing you where to focus your time. And then the product experiments and feasibility research and all of that is designed to help you to get closer to validation.

+ +

But, in some cases, there's a point at which you have to take a risk, right? And your customers are ultimately going to tell you over time whether or not the solution was the right one. But you get more confidence. You get closer to the right solution the more strategic you are about that process, so...oh, go ahead.

+ +

ASHLEY: I think the great thing about technology, too, is it's not set in stone. You can change it. If you learn something new, you can modify what you're doing to fit what you're hearing, and I think that's so incredible. We live in a time where there are so many tools and resources out there to really be nimble. And just to Jordyn's point earlier, I think the hardest part is being willing to take in some of these signals and be like, okay, this is what they want, and being willing to move in that direction versus the path you have already designed in your head.

+ +

DAWN: Yeah, we've only got a couple of weeks left in this incubator [laughs]. How are y'all feeling? What are you planning? What are you looking forward to over the next couple of weeks?

+ +

ASHLEY: I can't believe that time went by so fast. I thought eight weeks felt like two years when we first started. I was like, oh, we've got so much time. We're going to do so much. We have done a lot. But the time has really flown by. So, I'm just kind of, like, now thinking about how do I make the most of the last few weeks? And just make sure that we check all the boxes that we set out to check in the beginning, and then have a plan from there in terms of continuing the work in a productive and, you know, exciting way.

+ +

JORDYN: Yeah, one of the, like, sort of Northstar outcome for us in the incubator is to give the founder confidence in what they're doing and their path, the confidence in that vision, and then enough confidence to articulate it consistently to the folks they need to sort of bring along with them. So, what I'm, like, really looking forward to in the next couple of weeks is honing that story for Ashley. Like, what's your story? What's your why? What's your how? What's your when? And how to make sure that story is just easy to communicate.

+ +

I mean, already, Ashley, like, up top of this exact livestream where you articulated sort of, like, what AvidFirst is doing, I think I feel better and better about that articulation given what we know. It feels really good. It feels solid. And as we're going, we're just as skeptical as anyone else, right? But we're trying to anticipate what folks...external stakeholders broadly define what their misgivings are going to be. And we're compiling a kind of list of frequently asked questions about what AvidFirst is doing, like, why 529s? Why next-gen consumers? Et cetera. Just so that that story is so internalized that, like, you can't really be taken off guard necessarily.

+ +

I mean, you want to be open to new questions and new ideas. That's not what I'm saying. But just basically, like, being able to thoroughly and deeply, at the drop of a hat, to sort of pitch this to your dentist while they're cleaning your teeth, you know, like that kind of conviction and, like, the solidity of the narrative is really what we're going for in the next few weeks.

+ +

And I think we're well on our way there. We have all the pieces. It's about putting it together coherently, I think, at this point. It's really exciting, though. I do feel like we're really zeroing in on a valuable lens on college saving and spending that I think the market is really ripe for, so it's exciting.

+ +

DAWN: Yeah, it's been great to see all the progress. We have a comment that I just noticed.

+ +

ASHLEY: Oh.

+ +

DAWN: Not a question, but I wanted to call it out because it was related to what you were talking about a few minutes ago, Jordyn. Kiran said they totally agree. "We had the same epiphany/pivot this summer. We went from direct-to-consumer to an enterprise model. Try to zoom out with a systems thinking lens, and it will help with a clearer path and tell your story."

+ +

JORDYN: Yeah, that's awesome.

+ +

DAWN: There are no other questions from the audience. And it seems like maybe there's still a little bit of a lag. So [laughs], we can wrap up. If anybody has questions after this, feel free to comment. We'll be, you know, checking out the posts on LinkedIn and YouTube. And we can follow up there.

+ +

You can always, like I said, come and follow along. Check out our thoughtbot.com incubator site. You can both apply to the next incubator session and sign up to hear from us in our weekly newsletter. We write about progress on our blog as well, so thoughtbot.com/blog. There's all kinds of ways to find us and actually talking about the work that we're doing. So, please follow along.

+ +

JORDYN: Anyone out there who's wondering, am I right for the incubator? Just apply. It's really, like, nothing is too early if it's just an idea you've been kicking around that's born of your industry experience or your personal experience. The application process is really lightweight. This is not going to take you days to fill out this application.

+ +

We've heard from folks that even filling out the application is the first thing they ever did with regard to the idea, helped solidify it, and solidify their thinking for them. So, just go apply. You got something? You got an idea for an app? You see a growing market out there, and you feel like it's underserved with software? Just holler at us. We'd love to hear it. Apply. It's fun [laughs].

+ +

DAWN: Yeah. Thanks, everybody, for tuning in. Thanks, Jordyn and Ashley, for participating. See you again in a couple of weeks, yeah?

+ +

JORDYN: Yes. It'll be the last week, so we'll have things to say, no doubt.

+ +

DAWN: Yes, tune in. It'll be a good time. All right. Thanks, everybody.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or a development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble, Dawn Delatte, and Jordyn Bonds.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Y9fyWn6d + + ]]> + + Ashley Sheble + Dawn Delatte + Jordyn Bonds + + + thoughtbot's Incubator Program Mini Season - Episode 02: AvidFirst with Ashley Sheble + https://podcast.thoughtbot.com/incubatormini2 + 41f151d5-8ded-4707-b991-42677023455f + Wed, 01 Nov 2023 00:15:00 -0400 + thoughtbot + + full + 12 + thoughtbot + In this second conversation in this Mini Incubator Series, Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's incubator program. thoughtbot's Incubator Program aims to help founders like Ashley turn an idea into a viable product. + +The trio talks about Ashley's experiences and progress in the program. She emphasizes the significance of user research and interviews in shaping product strategy and understanding customer needs. She also highlights the need to narrow their focus to specific customer segments to build a product that resonates with a particular group. Additionally, they discuss the complexities of the FinTech industry and how regulatory considerations are an integral part of their product development process. As they gain more insights, they are transitioning into the prototyping and testing phase to validate their product concepts and messaging. + 25:20 + no + + + In this second conversation in this Mini Incubator Series, Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product. +The trio talks about Ashley's experiences and progress in the program. She emphasizes the significance of user research and interviews in shaping product strategy and understanding customer needs. She also highlights the need to narrow their focus to specific customer segments to build a product that resonates with a particular group. Additionally, they discuss the complexities of the FinTech industry and how regulatory considerations are an integral part of their product development process. As they gain more insights, they are transitioning into the prototyping and testing phase to validate their product concepts and messaging. +Just catching up? Listen to Part I (https://www.giantrobots.fm/498) of the Mini Incubator Series. +Follow Ashley Sheble on LinkedIn (https://www.linkedin.com/in/ashley-sheble/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +DAWN: Hello, everyone. I'm Dawn Delatte. I am a Managing Director here at thoughtbot. And I'm filling in for Lindsey. And I'm super excited to be here and chat with Ashley and Jordyn about how the incubator is going so far. +If you are tuning in, you're probably familiar with thoughtbot, but just in case you're not, we are a product design and development consultancy who works with people and products across the entire product lifecycle to make your team and product a success. We are currently running our second incubator session. If you're not familiar with it, we've got a ton of content from our first session that you can check out, or you can follow along in this one. +But our incubator program is an eight-week program that we take a founder through to validate or invalidate their new product ideas through lots of market research, customer discovery, interviews, and such. And then, we come out with a product plan that helps set them on the right path forward. +In the last update, we introduced our incubator founder, who's with us again today. In this session, we'll be talking with Ashley and Jordyn about digging deep into research and plenty of interviews and, you know, what they're learning and what the process is like so far. So, I'm excited to get started. How about y'all kick us off with some introductions? Jordyn? +JORDYN: I'm Jordyn Bonds. I'm the Director of Product Strategy at thoughtbot on Dawn's team, the Ignite team at thoughtbot. I'm a two-time startup founder myself. I've worked with a couple of other early-stage startups, so all about the zero-to-one startup journey over here. +ASHLEY: And I'm Ashley Sheble. I am the Founder of AvidFirst, and I am the second incubator founder. And working with Jordyn and team and thoughtbot to really accelerate the mission of our company, which is focused on simplifying college saving and spending. +DAWN: Ashley, why don't you recap a little bit for us what's happened since the last time? +ASHLEY: Yeah, I'd love to. So, the past three weeks have been really just getting into the weeds on user interviews, talking with different stakeholders as it relates to the problem we're looking to solve. And what we're finding are some key themes. And so, really trying to aggregate the data, focus in on those key themes, and find out where we can really pull at some of those strings to start creating some solutions that are meaningful and specific. +One of the primary trends that we're seeing is just lack of awareness around some of the resources and tools available to people as it relates to saving for college; 529s, for example, are a really great tool. And most people, 70%, aren't aware of them. And so, if you've never heard of them, you're in great company. +So, just really looking at high-level trends, getting more specific on even more granular trends, and trying to pull everything together and create a product that's meaningful. And again, it circles back to our overarching mission of simplifying college saving and spending. +DAWN: Nice. Is there something that has come up either in the process or, you know, from interviews that has been your big sort of aha or eureka moment? +ASHLEY: I feel like there's an aha moment pretty much every day. And sometimes the aha moments are like, oh my gosh, this is amazing. We're really on to something. And then, sometimes the aha moments are like, wow, we're really off course, and we have no idea what this means and what do we do with it. And so, it's kind of this up-and-down experience, like we talked about last time we chatted. +But it is exciting at the same time because no matter what aha moment, all of it means something. And it helps us make forward progress in the right direction versus making forward progress and then hitting a roadblock and realizing, okay, that's as far as we can go, and now we have to start all over. The team has been really good about helping me make sense of some of these findings that we are uncovering and piecing together some solutions that really address some of these aha moments, both shocking and positive. +DAWN: It's really great to hear you articulate that from a founder perspective and someone who, you know, isn't doing this sort of day-to-day product and development thing because, you know, that's a really common experience for us is hearing what's going well and what's not going well and sort of pivoting. But yeah, it's good to hear that directly from you. +So, y'all have been doing a ton of research and a ton of talking to people. Jordyn, tell us how you feel about user research. I know that term, in particular, has some interesting [chuckles] connotations, but dig into that. +JORDYN: Yeah. Well, we kind of talked about this a little bit this week, and I think research is really broad and vague. And so, just talking about research often doesn't feel super sort of actionable to people. User research is really about once you have a product and market and you have users, how they're using your product or not using it, right? So that's user research. +But I find that people often talk about this sort of higher-level strategic research that we're engaged in right now using the same term. And it leads people astray because they think that you need a prototype or you need an app to be able to do user research, which you do. But that's not really the kind of research that we're engaged in yet. Right now, we're doing customer discovery. And that involves researching and interviewing a ton of different personas, some of whom might end up being our customers, some of whom are interested stakeholders or partners. It's a really wide-ranging kind of cast of characters. +And the truth is, we don't know who these people are to us yet, right? So, it's really just sort of interviewing [laughs]. It's a hard thing to kind of characterize. I would love to hear, Ashley, like, how you're finding it. But, like, from where I sit, it really isn't about walking people through an interface yet. It's way more just asking folks about their life and their work and how they're doing things now, I think, is a really critical component. +Like what you're trying to do with these interviews is find out what are the true pain points that people have, not what they think you want to hear, but what the pain points are that they already have and that they are already trying to solve in certain ways and how they're solving them. And it requires a lot of just high-level questions and then closing your mouth and listening. But it's a very different thing, I think, than user research. But often, in product land, we kind of just use user research as this blanket term, but it really is a bunch of different kinds of things. +ASHLEY: Yeah, I would add to what Jordyn is saying, and the use of research, it's really interesting to just hear people's experience and their own background. And we always try to preface, like, there is no right or wrong answer. We just want to hear about the way you're thinking about something or the way you're currently doing something, not how you hypothetically would do something. Because, I don't know, think about your own life, and you think about the way you would do something. It's probably about ten times better than the way you actually do something. +When I get asked like, "Well, how many times a day do you set time to just decompress?" In my mind, I'm like, "Oh, probably, like, five times a day." When in reality, that's never. It's a never. So, if somebody were, like, you know, asking me for user research, you know, "Would you use this thing to decompress?" I'd be like, "Sure." But I wouldn't. I would not use it because I just don't make the time for something like that. So, the point is, is not asking people hypothetically how they would do something but how they're actually doing something now and then using that insight to build around. +And then, beyond just that customer journey, the stakeholder journey. And when you think about building a solution, there are more people involved than just the end user. There are so many different parties that play into a certain product, especially as you think about FinTech or you think about a large segment like the education segment. There are a lot of players, and you have to look at the way each player is looking at a problem and understand how those all tie together. And sometimes that's super obvious, and sometimes it's not obvious at all. And so, thankfully, having a team that has a different lens in the way we're interpreting data allows us to get to a solution faster. +DAWN: Yeah, I like that. Again, it's great to hear you articulating that. And I think we have this old article about not using terms like user research. I think it focuses a little bit more on user testing because that implies the idea of testing a user. But we're not testing people; we're testing our concepts. I think that we use the word usability test as a way to sort of delineate a little bit better. Here's the purpose of this test. We're actually testing the product versus, you know, having a conversation. +When you throw in words like interview or even customer, customer could be presumptive in some ways. But it's difficult to sort of tell people what you're doing when you're like, I'm just having a lot of conversations this week [laughs], just meeting, meeting a lot of people and listening. Meeting and listening, I guess, is the activity [laughs]. So, why is that stuff important? And can there be too much of it? What is this process like, and why are y'all doing it? +JORDYN: It's so funny to have internalized the sort of value of doing this kind of work so thoroughly that sometimes I even have...I'm like, how else do you know what's going on out there? I mean, that's ultimately the purpose of it is that you really don't know how people are living and working until you ask them or, even better, watch them live and work if you can. And what's really critical is that that changes over time. We're all constantly changing our behavior in response to new trends, new tools we might adopt, right? And the research at this level, this high level of, like, how are you living and working, really can never end for that reason, right? +Like, the classic example in sort of software product land is when Netflix really started to invest in online streaming and gradually sunset its DVD-by-mail service. And they did it right at the peak of that service. And so, people were like, this is really wild. Why are they doing this? This is so successful. Why would they, like, stop doing this thing that's really successful? +But they had been talking to their customers, their end users. They had been, as you said, Dawn, more than talking to them, listening to them. And they were looking at the trends. And they were like, there's no future in this. There's a future in online streaming, and we need to get ahead of that future. And we need to dominate that opportunity because we're in a position to do so. And it takes a lot of listening, synthesizing, and then risk-taking. But it doesn't feel like a risk when you've been listening to your customers, I guess, is, like, why this research is so important. +When you know something about the market because there is no daylight between you and how folks are living and what they're doing out there, it doesn't feel very risky. You have, like, complete certainty about what's happening out there because you know. Because you're talking to people. You have relationships with them. It's not merely about some...and when we say research, I don't want it to sound, like, sort of cold and, like, purely numbers-driven. +This is, like, we're having warm, engaging, you know, human conversations with human beings, like, all day, every day. But because of that, we have a really good sense of what's going on out there. And the decisions we make, they feel inevitable or something. You start to see an opportunity out there that just feels obvious. And it's a funny thing to watch that kind of once everybody on the team is aligned around that reality that we're hearing and the sort of inevitability of, like, what you need. You start to get kind of panicked because you're like, who else is seeing this? This is so obvious to us. And you start to kind of be like, who else is it obvious to? +But, you know, sadly, I don't know what the right word is here, but, like, it's hard work. This work of listening it is not very scalable work. You can do some things to operationalize it for sure, but it takes time to engage with humans, to synthesize what you've heard, to share it with your team, to stay on the same page about it. It's not super scalable work, straight up. But it is the most valuable work that you could possibly be doing. So, it's okay that it's not scalable. But yeah, you start to identify these real market insights. And then you kind of have this minute of, like, who else is seeing this? Because this looks really clear to us, right? [laughs] +ASHLEY: And it's interesting because the last time we chatted here a couple of weeks ago, Lindsey was like, "I'm sure you'll be in a different spot next week. And, you know, you'll be thinking about something different than you are right now." And, in my head, I was like, probably not. I've done a lot of research. It'll probably be the same. And she was right. It's very different from where we were a couple of weeks ago, and the way we're thinking about taking a certain path and circling back to having these conversations that are so critical and really shape the way you're thinking about problems from so many different directions. And so, I thought that was funny that she was right. +DAWN: Lindsey is always right. +JORDYN: Another ingredient here that I think is really important that becomes clear when you start doing this work but is a hard thing to describe...and I would kind of love to hear how Ashley has been thinking about this. But if you're not hearing a pattern, if you're out there doing the interviewing and it's just a million different descriptions of reality, that is the surest sign that you are not focused on a small enough addressable group of people. You haven't narrowed into a group of people who are the same. +And that's really the only way to build a product is to find a group of people who are the same. Make something for them that they love, and then think about where you can go from there. You can't please all of the people all of the time, but you can't please all the people at once, right? You're not going to be able to build a product that does that. And I would say, like, even later, you're not, you know, there's like...it just...it totally dilutes your focus. +So, if you are out there doing a bunch of interviewing, a bunch of research, and you're just hearing a bunch of different voices, and it sounds like there's no signal there, it's just that you haven't sufficiently narrowed. So, one of the things we've been doing over the last couple of weeks is really trying to figure out who exactly has the pain point the most that is addressable, in the sense that it's a group of people who are similar, similar enough that we can build a product for them, that is going to work for all of them, and we can speak about it in a way that resonates for them? +And it feels kind of impossible. And it also kind of feels, I don't know, a little bit like cheating. Like, it feels opposite of how I think founders think about making products. It's like, you want to build a thing that appeals to a lot of people. That's the drive, and that is absolutely the correct long-term drive, right? And it feels a little bit about sort of throw the game by choosing the people. It feels a little bit like you're like, well, of course, we can make something for a group of people if we've already pre-selected who they are, but it's like, yeah, exactly, that's a lot easier [laughs]. +So, anyway, I didn't want to move on without sort of mentioning that that focus on a persona is really, really critical. Yes, we're doing a ton of research, or we're talking to a ton of different people. But in each of those categories, we're really trying to figure out who are addressable niches to start? +ASHLEY: Yeah, and I think just getting as specific as possible, like Jordyn has said, has been...in my mind, I was thinking, we don't want to do that because then that really limits the amount of people we can help or the amount of people who could really benefit from a solution. But the good news is that once you solve a problem for a group of people, you can expand upon that and use the learnings from that solution and build something that can help more and more people. Because initially, I was like, "No, we don't want to do that. That's crazy." And she was right. +DAWN: Jordyn is another one of those people that's always right [laughs]. Mostly right. Okay, so you're using what you're finding and hearing in these conversations to help guide, you know, your focus, but especially the space that y'all are operating in, FinTech, in particular, is a very complex space. And so, there's all sorts of other dynamics that have to come into your strategy and direction for the product. So, how are y'all navigating which dynamics to focus on outside of what you're discovering in these conversations, you know, whether that be infrastructure, regulatory things, like, you know, all of those complexities? +ASHLEY: Yeah, I would say, right now, we're focusing on infrastructure. And that will inform the regulatory piece because there are so many nuances in the space as it relates to what type of product you're building for whom and where. And so, once that is more crystallized, the regulatory pieces can be plugged in. And you're right; it's super complex. And we want to make sure that we're being extremely compliant in every possible way. And so, that is highest priority. +But I think, too, to try to boil the ocean with all the different nuances when maybe we're not as crystal clear on the infrastructure would be, I don't know, waste of time is the wrong phrase, but I think it would not be the most efficient use of time. I think getting that infrastructure and then nailing down the regulatory piece around the infrastructure is the best path that we're thinking. +JORDYN: Yeah, I would just add here that this space is really complex. And the image that's kind of emerged most recently is of a giant puzzle we're putting together. There are a lot of pieces to this puzzle. It's not a thousand-piece puzzle, but it feels close [laughs]. But where we're starting out is where you start with any puzzle, which is the corner pieces. Like, what are the cornerstones of what we're doing? And figuring out what those are, always centered in what the value proposition is to customers, right? We need to know what their incentives are, what they need and want. That's the cornerstone. +And then the feasibility and the infrastructure and, you know, regulatory are the blanks we fill in sort of from there. But without demand, none of that stuff would matter, right? It's a really hard thing because you start to think about...and we talk about this stuff all the time; I want to call out. It's not, like, we're strictly disciplined about we're not talking about that right now. Like, it comes up all the time. +And we're sharing what we're learning and what we're seeing out there. We're looking at other products that have, you know, come onto the market recently, like, long-time players in the FinTech space. We're looking at all of that stuff, what they've done, what they've built, and how. We're thinking and talking about those things, but those decisions are not as important as making sure that we're as close to the customer as we can. That's the cornerstone pieces. +Our customers and our partners, what are their motivations? What do they need? And then, once we have those corner pieces, then we fill in the puzzle. It's a big, complex puzzle, but you always have to start with something of value. If you're not bringing something of value to those folks, none of this other stuff really matters. +DAWN: This is making me wonder if there are people out there who start their puzzles in the middle [laughs]. +JORDYN: Guilty as charged [laughs]. +DAWN: I meant more [inaudible 18:57]. I didn't mean metaphorically. We know that happens [laughter], unfortunately. +JORDYN: Yes, no, I have absolutely been that person personally, you know, and it can be really distracting. The feasibility puzzle is very interesting, and it feels inevitable. Like, you're going to have to solve those problems. The problem is that you don't know which of them is going to matter right now. So, solving those problems now, like Ashley said, it's sort of a waste of time. You might end up solving them eventually, right? But you need to figure out the strategic path forward. And so, yeah, it's tough. +I have an engineering background. I love solving complex puzzles. It's very tempting to go do that right now, and it feels much more tangible. Like, okay, we can go read the regulations. We can, like, look at what the infrastructure can do right now. Let's go solve that problem. But it would be just a colossal waste of time to go off in that direction right now. And we don't yet know fully what the value proposition is for whom. Like, that is the gem at the heart of this. +I want to acknowledge that there are software efforts out there where the core value really is in a technical innovation. But I would still argue that the timing of bringing that technical innovation to market has as much to do with the market. We can see this over and over again with tons of technologies that were developed years or decades ago, but the market was not at a place where it needed that thing yet. +And I really say needed; wanted is a different thing, right? You need to get to a place where the need is red hot. So, it's tough. The puzzle is fascinating. It's very distracting. We end up talking about it a lot, but we have to, like, bring ourselves back to the stakeholders. +DAWN: To wrap things up, now that y'all have sort of deepened your understanding of things, what can you expect from the process going forward? What should we expect to sort of hear about next time we meet? +JORDYN: We're actually already edging into this, and it's fun to watch how this process happens. When you start to hear something repeatable, you inevitably move into prototyping because you start to have a real shared understanding of what it is you need to put in front of people. +We're just now, I would say, like, today, getting to the place where we're confident that we need to be testing messaging in particular. We've heard enough things that we need to start testing. Like, are we talking about the problems in the way that, you know, customers and our partners are talking about them? And we need to start trying that language out and then seeing how it resonates. That's the first piece of testing. We're already starting to conceive of workflows, like a prototype concept. +It's so fascinating how, again, it's just always is a consequence of alignment and insight. You don't have to plan it. It emerges. As soon as you've started to put the pieces together a little bit, it's just very natural that, as a group, you start talking about how you might address this problem. You can tell when we've gotten there because we are aligned. In the same way that you're hearing the same thing from the customer, you start to see the same solution because it's clear what is needed. So, we're really moving into that. +I want to make it clear, like, we don't stop interviewing. We don't stop talking to folks. But the sort of how specific we are with what we're asking and what we're showing people changes a little bit. That's really just starting to happen now. And I'm sure we'll have a lot more to say about that next time [laughs]. +ASHLEY: Yeah, it's been a lot of fun. I'll say the value of the team is incredible. I can't stress that enough. Just this morning, I came to our morning sync and was like, "Listen, I learned this thing. I think it's over. We're done." And Jordyn and team were like, "No, this is actually a really great thing." And, you know, I'm just like, they're going to give up. They're going to shut it down. They're going to say, "No, we don't want to work with you." And they're like, "This is great news." +And so, just the diversity of perspective is so different, and it's really great to have that. Because sometimes you can get focused on something in such a linear way that you're like, there's no way out of this thing. And you kind of miss the forest for the trees, so... +JORDYN: I'm glad you brought that moment up. I was hoping we would talk about it during this live session because it was one of those moments where you were like, "I have some really bad news. I learned something. This is very sad." And you kind of talked about it a minute. +I had a sort of unbridled glee [laughs]. I was like, oh, awesome, because we knew enough to know there was, like, we were missing something. There are a bunch of solutions in the market that look very different than what we were considering. And we were like, why? There's got to be a good reason. These people are not dumb. The market they're seeing is not different from the market we're seeing. So, like, why have they made a different call? +And this piece of information, you know, Ashley showed up and was like, "Hey, I learned something, here it is." And I was like, "That's the piece of information. Great." So, now we actually can make a plan. We are still sort of convinced of the value that we were driving toward. And now we just have an added understanding of what it will take to get there. Good. Now we know what it'll take. +It's really terrible to have an idea of the value prop that you want to pursue and not have any idea of how would it get there. But now we actually really did feel like a piece of a puzzle falling into place. And it was hilarious because Ashely was, like, very grim, and then I was like, "Oh," I was like, "Great." [laughs] +ASHLEY: I was like -- +JORDYN: Ashley was like, "Wait, what?" [laughs] It was very funny. +ASHLEY: Yeah, it was great. I was like, I hope the rest of my day is this good, so... +[laughter] +DAWN: Well, I'm sorry to say, Ashley, but you can't get rid of us that easily [laughter]. Thank you both for chatting with me today. +If y'all want to stay updated, you can follow along on LinkedIn or YouTube. We do these live streams every two weeks. We also share incubator news and updates on our blog, so thoughtbot.com/blog. You can always go to the incubator site to understand a little bit more about the program. That's thoughtbot.com/incubator. Send us your questions if you have them. And you can always attend the lives, comment on the threads, send us an email. We love to hear from y'all. Thank you for tuning in +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Ashley Sheble, Dawn Delatte, and Jordyn Bonds. + + + In this second conversation in this Mini Incubator Series, Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product.

+ +

The trio talks about Ashley's experiences and progress in the program. She emphasizes the significance of user research and interviews in shaping product strategy and understanding customer needs. She also highlights the need to narrow their focus to specific customer segments to build a product that resonates with a particular group. Additionally, they discuss the complexities of the FinTech industry and how regulatory considerations are an integral part of their product development process. As they gain more insights, they are transitioning into the prototyping and testing phase to validate their product concepts and messaging.

+ +

Just catching up? Listen to Part I of the Mini Incubator Series.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

DAWN: Hello, everyone. I'm Dawn Delatte. I am a Managing Director here at thoughtbot. And I'm filling in for Lindsey. And I'm super excited to be here and chat with Ashley and Jordyn about how the incubator is going so far.

+ +

If you are tuning in, you're probably familiar with thoughtbot, but just in case you're not, we are a product design and development consultancy who works with people and products across the entire product lifecycle to make your team and product a success. We are currently running our second incubator session. If you're not familiar with it, we've got a ton of content from our first session that you can check out, or you can follow along in this one.

+ +

But our incubator program is an eight-week program that we take a founder through to validate or invalidate their new product ideas through lots of market research, customer discovery, interviews, and such. And then, we come out with a product plan that helps set them on the right path forward.

+ +

In the last update, we introduced our incubator founder, who's with us again today. In this session, we'll be talking with Ashley and Jordyn about digging deep into research and plenty of interviews and, you know, what they're learning and what the process is like so far. So, I'm excited to get started. How about y'all kick us off with some introductions? Jordyn?

+ +

JORDYN: I'm Jordyn Bonds. I'm the Director of Product Strategy at thoughtbot on Dawn's team, the Ignite team at thoughtbot. I'm a two-time startup founder myself. I've worked with a couple of other early-stage startups, so all about the zero-to-one startup journey over here.

+ +

ASHLEY: And I'm Ashley Sheble. I am the Founder of AvidFirst, and I am the second incubator founder. And working with Jordyn and team and thoughtbot to really accelerate the mission of our company, which is focused on simplifying college saving and spending.

+ +

DAWN: Ashley, why don't you recap a little bit for us what's happened since the last time?

+ +

ASHLEY: Yeah, I'd love to. So, the past three weeks have been really just getting into the weeds on user interviews, talking with different stakeholders as it relates to the problem we're looking to solve. And what we're finding are some key themes. And so, really trying to aggregate the data, focus in on those key themes, and find out where we can really pull at some of those strings to start creating some solutions that are meaningful and specific.

+ +

One of the primary trends that we're seeing is just lack of awareness around some of the resources and tools available to people as it relates to saving for college; 529s, for example, are a really great tool. And most people, 70%, aren't aware of them. And so, if you've never heard of them, you're in great company.

+ +

So, just really looking at high-level trends, getting more specific on even more granular trends, and trying to pull everything together and create a product that's meaningful. And again, it circles back to our overarching mission of simplifying college saving and spending.

+ +

DAWN: Nice. Is there something that has come up either in the process or, you know, from interviews that has been your big sort of aha or eureka moment?

+ +

ASHLEY: I feel like there's an aha moment pretty much every day. And sometimes the aha moments are like, oh my gosh, this is amazing. We're really on to something. And then, sometimes the aha moments are like, wow, we're really off course, and we have no idea what this means and what do we do with it. And so, it's kind of this up-and-down experience, like we talked about last time we chatted.

+ +

But it is exciting at the same time because no matter what aha moment, all of it means something. And it helps us make forward progress in the right direction versus making forward progress and then hitting a roadblock and realizing, okay, that's as far as we can go, and now we have to start all over. The team has been really good about helping me make sense of some of these findings that we are uncovering and piecing together some solutions that really address some of these aha moments, both shocking and positive.

+ +

DAWN: It's really great to hear you articulate that from a founder perspective and someone who, you know, isn't doing this sort of day-to-day product and development thing because, you know, that's a really common experience for us is hearing what's going well and what's not going well and sort of pivoting. But yeah, it's good to hear that directly from you.

+ +

So, y'all have been doing a ton of research and a ton of talking to people. Jordyn, tell us how you feel about user research. I know that term, in particular, has some interesting [chuckles] connotations, but dig into that.

+ +

JORDYN: Yeah. Well, we kind of talked about this a little bit this week, and I think research is really broad and vague. And so, just talking about research often doesn't feel super sort of actionable to people. User research is really about once you have a product and market and you have users, how they're using your product or not using it, right? So that's user research.

+ +

But I find that people often talk about this sort of higher-level strategic research that we're engaged in right now using the same term. And it leads people astray because they think that you need a prototype or you need an app to be able to do user research, which you do. But that's not really the kind of research that we're engaged in yet. Right now, we're doing customer discovery. And that involves researching and interviewing a ton of different personas, some of whom might end up being our customers, some of whom are interested stakeholders or partners. It's a really wide-ranging kind of cast of characters.

+ +

And the truth is, we don't know who these people are to us yet, right? So, it's really just sort of interviewing [laughs]. It's a hard thing to kind of characterize. I would love to hear, Ashley, like, how you're finding it. But, like, from where I sit, it really isn't about walking people through an interface yet. It's way more just asking folks about their life and their work and how they're doing things now, I think, is a really critical component.

+ +

Like what you're trying to do with these interviews is find out what are the true pain points that people have, not what they think you want to hear, but what the pain points are that they already have and that they are already trying to solve in certain ways and how they're solving them. And it requires a lot of just high-level questions and then closing your mouth and listening. But it's a very different thing, I think, than user research. But often, in product land, we kind of just use user research as this blanket term, but it really is a bunch of different kinds of things.

+ +

ASHLEY: Yeah, I would add to what Jordyn is saying, and the use of research, it's really interesting to just hear people's experience and their own background. And we always try to preface, like, there is no right or wrong answer. We just want to hear about the way you're thinking about something or the way you're currently doing something, not how you hypothetically would do something. Because, I don't know, think about your own life, and you think about the way you would do something. It's probably about ten times better than the way you actually do something.

+ +

When I get asked like, "Well, how many times a day do you set time to just decompress?" In my mind, I'm like, "Oh, probably, like, five times a day." When in reality, that's never. It's a never. So, if somebody were, like, you know, asking me for user research, you know, "Would you use this thing to decompress?" I'd be like, "Sure." But I wouldn't. I would not use it because I just don't make the time for something like that. So, the point is, is not asking people hypothetically how they would do something but how they're actually doing something now and then using that insight to build around.

+ +

And then, beyond just that customer journey, the stakeholder journey. And when you think about building a solution, there are more people involved than just the end user. There are so many different parties that play into a certain product, especially as you think about FinTech or you think about a large segment like the education segment. There are a lot of players, and you have to look at the way each player is looking at a problem and understand how those all tie together. And sometimes that's super obvious, and sometimes it's not obvious at all. And so, thankfully, having a team that has a different lens in the way we're interpreting data allows us to get to a solution faster.

+ +

DAWN: Yeah, I like that. Again, it's great to hear you articulating that. And I think we have this old article about not using terms like user research. I think it focuses a little bit more on user testing because that implies the idea of testing a user. But we're not testing people; we're testing our concepts. I think that we use the word usability test as a way to sort of delineate a little bit better. Here's the purpose of this test. We're actually testing the product versus, you know, having a conversation.

+ +

When you throw in words like interview or even customer, customer could be presumptive in some ways. But it's difficult to sort of tell people what you're doing when you're like, I'm just having a lot of conversations this week [laughs], just meeting, meeting a lot of people and listening. Meeting and listening, I guess, is the activity [laughs]. So, why is that stuff important? And can there be too much of it? What is this process like, and why are y'all doing it?

+ +

JORDYN: It's so funny to have internalized the sort of value of doing this kind of work so thoroughly that sometimes I even have...I'm like, how else do you know what's going on out there? I mean, that's ultimately the purpose of it is that you really don't know how people are living and working until you ask them or, even better, watch them live and work if you can. And what's really critical is that that changes over time. We're all constantly changing our behavior in response to new trends, new tools we might adopt, right? And the research at this level, this high level of, like, how are you living and working, really can never end for that reason, right?

+ +

Like, the classic example in sort of software product land is when Netflix really started to invest in online streaming and gradually sunset its DVD-by-mail service. And they did it right at the peak of that service. And so, people were like, this is really wild. Why are they doing this? This is so successful. Why would they, like, stop doing this thing that's really successful?

+ +

But they had been talking to their customers, their end users. They had been, as you said, Dawn, more than talking to them, listening to them. And they were looking at the trends. And they were like, there's no future in this. There's a future in online streaming, and we need to get ahead of that future. And we need to dominate that opportunity because we're in a position to do so. And it takes a lot of listening, synthesizing, and then risk-taking. But it doesn't feel like a risk when you've been listening to your customers, I guess, is, like, why this research is so important.

+ +

When you know something about the market because there is no daylight between you and how folks are living and what they're doing out there, it doesn't feel very risky. You have, like, complete certainty about what's happening out there because you know. Because you're talking to people. You have relationships with them. It's not merely about some...and when we say research, I don't want it to sound, like, sort of cold and, like, purely numbers-driven.

+ +

This is, like, we're having warm, engaging, you know, human conversations with human beings, like, all day, every day. But because of that, we have a really good sense of what's going on out there. And the decisions we make, they feel inevitable or something. You start to see an opportunity out there that just feels obvious. And it's a funny thing to watch that kind of once everybody on the team is aligned around that reality that we're hearing and the sort of inevitability of, like, what you need. You start to get kind of panicked because you're like, who else is seeing this? This is so obvious to us. And you start to kind of be like, who else is it obvious to?

+ +

But, you know, sadly, I don't know what the right word is here, but, like, it's hard work. This work of listening it is not very scalable work. You can do some things to operationalize it for sure, but it takes time to engage with humans, to synthesize what you've heard, to share it with your team, to stay on the same page about it. It's not super scalable work, straight up. But it is the most valuable work that you could possibly be doing. So, it's okay that it's not scalable. But yeah, you start to identify these real market insights. And then you kind of have this minute of, like, who else is seeing this? Because this looks really clear to us, right? [laughs]

+ +

ASHLEY: And it's interesting because the last time we chatted here a couple of weeks ago, Lindsey was like, "I'm sure you'll be in a different spot next week. And, you know, you'll be thinking about something different than you are right now." And, in my head, I was like, probably not. I've done a lot of research. It'll probably be the same. And she was right. It's very different from where we were a couple of weeks ago, and the way we're thinking about taking a certain path and circling back to having these conversations that are so critical and really shape the way you're thinking about problems from so many different directions. And so, I thought that was funny that she was right.

+ +

DAWN: Lindsey is always right.

+ +

JORDYN: Another ingredient here that I think is really important that becomes clear when you start doing this work but is a hard thing to describe...and I would kind of love to hear how Ashley has been thinking about this. But if you're not hearing a pattern, if you're out there doing the interviewing and it's just a million different descriptions of reality, that is the surest sign that you are not focused on a small enough addressable group of people. You haven't narrowed into a group of people who are the same.

+ +

And that's really the only way to build a product is to find a group of people who are the same. Make something for them that they love, and then think about where you can go from there. You can't please all of the people all of the time, but you can't please all the people at once, right? You're not going to be able to build a product that does that. And I would say, like, even later, you're not, you know, there's like...it just...it totally dilutes your focus.

+ +

So, if you are out there doing a bunch of interviewing, a bunch of research, and you're just hearing a bunch of different voices, and it sounds like there's no signal there, it's just that you haven't sufficiently narrowed. So, one of the things we've been doing over the last couple of weeks is really trying to figure out who exactly has the pain point the most that is addressable, in the sense that it's a group of people who are similar, similar enough that we can build a product for them, that is going to work for all of them, and we can speak about it in a way that resonates for them?

+ +

And it feels kind of impossible. And it also kind of feels, I don't know, a little bit like cheating. Like, it feels opposite of how I think founders think about making products. It's like, you want to build a thing that appeals to a lot of people. That's the drive, and that is absolutely the correct long-term drive, right? And it feels a little bit about sort of throw the game by choosing the people. It feels a little bit like you're like, well, of course, we can make something for a group of people if we've already pre-selected who they are, but it's like, yeah, exactly, that's a lot easier [laughs].

+ +

So, anyway, I didn't want to move on without sort of mentioning that that focus on a persona is really, really critical. Yes, we're doing a ton of research, or we're talking to a ton of different people. But in each of those categories, we're really trying to figure out who are addressable niches to start?

+ +

ASHLEY: Yeah, and I think just getting as specific as possible, like Jordyn has said, has been...in my mind, I was thinking, we don't want to do that because then that really limits the amount of people we can help or the amount of people who could really benefit from a solution. But the good news is that once you solve a problem for a group of people, you can expand upon that and use the learnings from that solution and build something that can help more and more people. Because initially, I was like, "No, we don't want to do that. That's crazy." And she was right.

+ +

DAWN: Jordyn is another one of those people that's always right [laughs]. Mostly right. Okay, so you're using what you're finding and hearing in these conversations to help guide, you know, your focus, but especially the space that y'all are operating in, FinTech, in particular, is a very complex space. And so, there's all sorts of other dynamics that have to come into your strategy and direction for the product. So, how are y'all navigating which dynamics to focus on outside of what you're discovering in these conversations, you know, whether that be infrastructure, regulatory things, like, you know, all of those complexities?

+ +

ASHLEY: Yeah, I would say, right now, we're focusing on infrastructure. And that will inform the regulatory piece because there are so many nuances in the space as it relates to what type of product you're building for whom and where. And so, once that is more crystallized, the regulatory pieces can be plugged in. And you're right; it's super complex. And we want to make sure that we're being extremely compliant in every possible way. And so, that is highest priority.

+ +

But I think, too, to try to boil the ocean with all the different nuances when maybe we're not as crystal clear on the infrastructure would be, I don't know, waste of time is the wrong phrase, but I think it would not be the most efficient use of time. I think getting that infrastructure and then nailing down the regulatory piece around the infrastructure is the best path that we're thinking.

+ +

JORDYN: Yeah, I would just add here that this space is really complex. And the image that's kind of emerged most recently is of a giant puzzle we're putting together. There are a lot of pieces to this puzzle. It's not a thousand-piece puzzle, but it feels close [laughs]. But where we're starting out is where you start with any puzzle, which is the corner pieces. Like, what are the cornerstones of what we're doing? And figuring out what those are, always centered in what the value proposition is to customers, right? We need to know what their incentives are, what they need and want. That's the cornerstone.

+ +

And then the feasibility and the infrastructure and, you know, regulatory are the blanks we fill in sort of from there. But without demand, none of that stuff would matter, right? It's a really hard thing because you start to think about...and we talk about this stuff all the time; I want to call out. It's not, like, we're strictly disciplined about we're not talking about that right now. Like, it comes up all the time.

+ +

And we're sharing what we're learning and what we're seeing out there. We're looking at other products that have, you know, come onto the market recently, like, long-time players in the FinTech space. We're looking at all of that stuff, what they've done, what they've built, and how. We're thinking and talking about those things, but those decisions are not as important as making sure that we're as close to the customer as we can. That's the cornerstone pieces.

+ +

Our customers and our partners, what are their motivations? What do they need? And then, once we have those corner pieces, then we fill in the puzzle. It's a big, complex puzzle, but you always have to start with something of value. If you're not bringing something of value to those folks, none of this other stuff really matters.

+ +

DAWN: This is making me wonder if there are people out there who start their puzzles in the middle [laughs].

+ +

JORDYN: Guilty as charged [laughs].

+ +

DAWN: I meant more [inaudible 18:57]. I didn't mean metaphorically. We know that happens [laughter], unfortunately.

+ +

JORDYN: Yes, no, I have absolutely been that person personally, you know, and it can be really distracting. The feasibility puzzle is very interesting, and it feels inevitable. Like, you're going to have to solve those problems. The problem is that you don't know which of them is going to matter right now. So, solving those problems now, like Ashley said, it's sort of a waste of time. You might end up solving them eventually, right? But you need to figure out the strategic path forward. And so, yeah, it's tough.

+ +

I have an engineering background. I love solving complex puzzles. It's very tempting to go do that right now, and it feels much more tangible. Like, okay, we can go read the regulations. We can, like, look at what the infrastructure can do right now. Let's go solve that problem. But it would be just a colossal waste of time to go off in that direction right now. And we don't yet know fully what the value proposition is for whom. Like, that is the gem at the heart of this.

+ +

I want to acknowledge that there are software efforts out there where the core value really is in a technical innovation. But I would still argue that the timing of bringing that technical innovation to market has as much to do with the market. We can see this over and over again with tons of technologies that were developed years or decades ago, but the market was not at a place where it needed that thing yet.

+ +

And I really say needed; wanted is a different thing, right? You need to get to a place where the need is red hot. So, it's tough. The puzzle is fascinating. It's very distracting. We end up talking about it a lot, but we have to, like, bring ourselves back to the stakeholders.

+ +

DAWN: To wrap things up, now that y'all have sort of deepened your understanding of things, what can you expect from the process going forward? What should we expect to sort of hear about next time we meet?

+ +

JORDYN: We're actually already edging into this, and it's fun to watch how this process happens. When you start to hear something repeatable, you inevitably move into prototyping because you start to have a real shared understanding of what it is you need to put in front of people.

+ +

We're just now, I would say, like, today, getting to the place where we're confident that we need to be testing messaging in particular. We've heard enough things that we need to start testing. Like, are we talking about the problems in the way that, you know, customers and our partners are talking about them? And we need to start trying that language out and then seeing how it resonates. That's the first piece of testing. We're already starting to conceive of workflows, like a prototype concept.

+ +

It's so fascinating how, again, it's just always is a consequence of alignment and insight. You don't have to plan it. It emerges. As soon as you've started to put the pieces together a little bit, it's just very natural that, as a group, you start talking about how you might address this problem. You can tell when we've gotten there because we are aligned. In the same way that you're hearing the same thing from the customer, you start to see the same solution because it's clear what is needed. So, we're really moving into that.

+ +

I want to make it clear, like, we don't stop interviewing. We don't stop talking to folks. But the sort of how specific we are with what we're asking and what we're showing people changes a little bit. That's really just starting to happen now. And I'm sure we'll have a lot more to say about that next time [laughs].

+ +

ASHLEY: Yeah, it's been a lot of fun. I'll say the value of the team is incredible. I can't stress that enough. Just this morning, I came to our morning sync and was like, "Listen, I learned this thing. I think it's over. We're done." And Jordyn and team were like, "No, this is actually a really great thing." And, you know, I'm just like, they're going to give up. They're going to shut it down. They're going to say, "No, we don't want to work with you." And they're like, "This is great news."

+ +

And so, just the diversity of perspective is so different, and it's really great to have that. Because sometimes you can get focused on something in such a linear way that you're like, there's no way out of this thing. And you kind of miss the forest for the trees, so...

+ +

JORDYN: I'm glad you brought that moment up. I was hoping we would talk about it during this live session because it was one of those moments where you were like, "I have some really bad news. I learned something. This is very sad." And you kind of talked about it a minute.

+ +

I had a sort of unbridled glee [laughs]. I was like, oh, awesome, because we knew enough to know there was, like, we were missing something. There are a bunch of solutions in the market that look very different than what we were considering. And we were like, why? There's got to be a good reason. These people are not dumb. The market they're seeing is not different from the market we're seeing. So, like, why have they made a different call?

+ +

And this piece of information, you know, Ashley showed up and was like, "Hey, I learned something, here it is." And I was like, "That's the piece of information. Great." So, now we actually can make a plan. We are still sort of convinced of the value that we were driving toward. And now we just have an added understanding of what it will take to get there. Good. Now we know what it'll take.

+ +

It's really terrible to have an idea of the value prop that you want to pursue and not have any idea of how would it get there. But now we actually really did feel like a piece of a puzzle falling into place. And it was hilarious because Ashely was, like, very grim, and then I was like, "Oh," I was like, "Great." [laughs]

+ +

ASHLEY: I was like --

+ +

JORDYN: Ashley was like, "Wait, what?" [laughs] It was very funny.

+ +

ASHLEY: Yeah, it was great. I was like, I hope the rest of my day is this good, so...

+ +

[laughter]

+ +

DAWN: Well, I'm sorry to say, Ashley, but you can't get rid of us that easily [laughter]. Thank you both for chatting with me today.

+ +

If y'all want to stay updated, you can follow along on LinkedIn or YouTube. We do these live streams every two weeks. We also share incubator news and updates on our blog, so thoughtbot.com/blog. You can always go to the incubator site to understand a little bit more about the program. That's thoughtbot.com/incubator. Send us your questions if you have them. And you can always attend the lives, comment on the threads, send us an email. We love to hear from y'all. Thank you for tuning in

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble, Dawn Delatte, and Jordyn Bonds.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this second conversation in this Mini Incubator Series, Dawn Delatte and Jordyn Bonds interview Ashley Sheble, the Founder of AvidFirst, about her experiences and progress in thoughtbot's Incubator Program, which aims to help founders like Ashley turn an idea into a viable product.

+ +

The trio talks about Ashley's experiences and progress in the program. She emphasizes the significance of user research and interviews in shaping product strategy and understanding customer needs. She also highlights the need to narrow their focus to specific customer segments to build a product that resonates with a particular group. Additionally, they discuss the complexities of the FinTech industry and how regulatory considerations are an integral part of their product development process. As they gain more insights, they are transitioning into the prototyping and testing phase to validate their product concepts and messaging.

+ +

Just catching up? Listen to Part I of the Mini Incubator Series.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

DAWN: Hello, everyone. I'm Dawn Delatte. I am a Managing Director here at thoughtbot. And I'm filling in for Lindsey. And I'm super excited to be here and chat with Ashley and Jordyn about how the incubator is going so far.

+ +

If you are tuning in, you're probably familiar with thoughtbot, but just in case you're not, we are a product design and development consultancy who works with people and products across the entire product lifecycle to make your team and product a success. We are currently running our second incubator session. If you're not familiar with it, we've got a ton of content from our first session that you can check out, or you can follow along in this one.

+ +

But our incubator program is an eight-week program that we take a founder through to validate or invalidate their new product ideas through lots of market research, customer discovery, interviews, and such. And then, we come out with a product plan that helps set them on the right path forward.

+ +

In the last update, we introduced our incubator founder, who's with us again today. In this session, we'll be talking with Ashley and Jordyn about digging deep into research and plenty of interviews and, you know, what they're learning and what the process is like so far. So, I'm excited to get started. How about y'all kick us off with some introductions? Jordyn?

+ +

JORDYN: I'm Jordyn Bonds. I'm the Director of Product Strategy at thoughtbot on Dawn's team, the Ignite team at thoughtbot. I'm a two-time startup founder myself. I've worked with a couple of other early-stage startups, so all about the zero-to-one startup journey over here.

+ +

ASHLEY: And I'm Ashley Sheble. I am the Founder of AvidFirst, and I am the second incubator founder. And working with Jordyn and team and thoughtbot to really accelerate the mission of our company, which is focused on simplifying college saving and spending.

+ +

DAWN: Ashley, why don't you recap a little bit for us what's happened since the last time?

+ +

ASHLEY: Yeah, I'd love to. So, the past three weeks have been really just getting into the weeds on user interviews, talking with different stakeholders as it relates to the problem we're looking to solve. And what we're finding are some key themes. And so, really trying to aggregate the data, focus in on those key themes, and find out where we can really pull at some of those strings to start creating some solutions that are meaningful and specific.

+ +

One of the primary trends that we're seeing is just lack of awareness around some of the resources and tools available to people as it relates to saving for college; 529s, for example, are a really great tool. And most people, 70%, aren't aware of them. And so, if you've never heard of them, you're in great company.

+ +

So, just really looking at high-level trends, getting more specific on even more granular trends, and trying to pull everything together and create a product that's meaningful. And again, it circles back to our overarching mission of simplifying college saving and spending.

+ +

DAWN: Nice. Is there something that has come up either in the process or, you know, from interviews that has been your big sort of aha or eureka moment?

+ +

ASHLEY: I feel like there's an aha moment pretty much every day. And sometimes the aha moments are like, oh my gosh, this is amazing. We're really on to something. And then, sometimes the aha moments are like, wow, we're really off course, and we have no idea what this means and what do we do with it. And so, it's kind of this up-and-down experience, like we talked about last time we chatted.

+ +

But it is exciting at the same time because no matter what aha moment, all of it means something. And it helps us make forward progress in the right direction versus making forward progress and then hitting a roadblock and realizing, okay, that's as far as we can go, and now we have to start all over. The team has been really good about helping me make sense of some of these findings that we are uncovering and piecing together some solutions that really address some of these aha moments, both shocking and positive.

+ +

DAWN: It's really great to hear you articulate that from a founder perspective and someone who, you know, isn't doing this sort of day-to-day product and development thing because, you know, that's a really common experience for us is hearing what's going well and what's not going well and sort of pivoting. But yeah, it's good to hear that directly from you.

+ +

So, y'all have been doing a ton of research and a ton of talking to people. Jordyn, tell us how you feel about user research. I know that term, in particular, has some interesting [chuckles] connotations, but dig into that.

+ +

JORDYN: Yeah. Well, we kind of talked about this a little bit this week, and I think research is really broad and vague. And so, just talking about research often doesn't feel super sort of actionable to people. User research is really about once you have a product and market and you have users, how they're using your product or not using it, right? So that's user research.

+ +

But I find that people often talk about this sort of higher-level strategic research that we're engaged in right now using the same term. And it leads people astray because they think that you need a prototype or you need an app to be able to do user research, which you do. But that's not really the kind of research that we're engaged in yet. Right now, we're doing customer discovery. And that involves researching and interviewing a ton of different personas, some of whom might end up being our customers, some of whom are interested stakeholders or partners. It's a really wide-ranging kind of cast of characters.

+ +

And the truth is, we don't know who these people are to us yet, right? So, it's really just sort of interviewing [laughs]. It's a hard thing to kind of characterize. I would love to hear, Ashley, like, how you're finding it. But, like, from where I sit, it really isn't about walking people through an interface yet. It's way more just asking folks about their life and their work and how they're doing things now, I think, is a really critical component.

+ +

Like what you're trying to do with these interviews is find out what are the true pain points that people have, not what they think you want to hear, but what the pain points are that they already have and that they are already trying to solve in certain ways and how they're solving them. And it requires a lot of just high-level questions and then closing your mouth and listening. But it's a very different thing, I think, than user research. But often, in product land, we kind of just use user research as this blanket term, but it really is a bunch of different kinds of things.

+ +

ASHLEY: Yeah, I would add to what Jordyn is saying, and the use of research, it's really interesting to just hear people's experience and their own background. And we always try to preface, like, there is no right or wrong answer. We just want to hear about the way you're thinking about something or the way you're currently doing something, not how you hypothetically would do something. Because, I don't know, think about your own life, and you think about the way you would do something. It's probably about ten times better than the way you actually do something.

+ +

When I get asked like, "Well, how many times a day do you set time to just decompress?" In my mind, I'm like, "Oh, probably, like, five times a day." When in reality, that's never. It's a never. So, if somebody were, like, you know, asking me for user research, you know, "Would you use this thing to decompress?" I'd be like, "Sure." But I wouldn't. I would not use it because I just don't make the time for something like that. So, the point is, is not asking people hypothetically how they would do something but how they're actually doing something now and then using that insight to build around.

+ +

And then, beyond just that customer journey, the stakeholder journey. And when you think about building a solution, there are more people involved than just the end user. There are so many different parties that play into a certain product, especially as you think about FinTech or you think about a large segment like the education segment. There are a lot of players, and you have to look at the way each player is looking at a problem and understand how those all tie together. And sometimes that's super obvious, and sometimes it's not obvious at all. And so, thankfully, having a team that has a different lens in the way we're interpreting data allows us to get to a solution faster.

+ +

DAWN: Yeah, I like that. Again, it's great to hear you articulating that. And I think we have this old article about not using terms like user research. I think it focuses a little bit more on user testing because that implies the idea of testing a user. But we're not testing people; we're testing our concepts. I think that we use the word usability test as a way to sort of delineate a little bit better. Here's the purpose of this test. We're actually testing the product versus, you know, having a conversation.

+ +

When you throw in words like interview or even customer, customer could be presumptive in some ways. But it's difficult to sort of tell people what you're doing when you're like, I'm just having a lot of conversations this week [laughs], just meeting, meeting a lot of people and listening. Meeting and listening, I guess, is the activity [laughs]. So, why is that stuff important? And can there be too much of it? What is this process like, and why are y'all doing it?

+ +

JORDYN: It's so funny to have internalized the sort of value of doing this kind of work so thoroughly that sometimes I even have...I'm like, how else do you know what's going on out there? I mean, that's ultimately the purpose of it is that you really don't know how people are living and working until you ask them or, even better, watch them live and work if you can. And what's really critical is that that changes over time. We're all constantly changing our behavior in response to new trends, new tools we might adopt, right? And the research at this level, this high level of, like, how are you living and working, really can never end for that reason, right?

+ +

Like, the classic example in sort of software product land is when Netflix really started to invest in online streaming and gradually sunset its DVD-by-mail service. And they did it right at the peak of that service. And so, people were like, this is really wild. Why are they doing this? This is so successful. Why would they, like, stop doing this thing that's really successful?

+ +

But they had been talking to their customers, their end users. They had been, as you said, Dawn, more than talking to them, listening to them. And they were looking at the trends. And they were like, there's no future in this. There's a future in online streaming, and we need to get ahead of that future. And we need to dominate that opportunity because we're in a position to do so. And it takes a lot of listening, synthesizing, and then risk-taking. But it doesn't feel like a risk when you've been listening to your customers, I guess, is, like, why this research is so important.

+ +

When you know something about the market because there is no daylight between you and how folks are living and what they're doing out there, it doesn't feel very risky. You have, like, complete certainty about what's happening out there because you know. Because you're talking to people. You have relationships with them. It's not merely about some...and when we say research, I don't want it to sound, like, sort of cold and, like, purely numbers-driven.

+ +

This is, like, we're having warm, engaging, you know, human conversations with human beings, like, all day, every day. But because of that, we have a really good sense of what's going on out there. And the decisions we make, they feel inevitable or something. You start to see an opportunity out there that just feels obvious. And it's a funny thing to watch that kind of once everybody on the team is aligned around that reality that we're hearing and the sort of inevitability of, like, what you need. You start to get kind of panicked because you're like, who else is seeing this? This is so obvious to us. And you start to kind of be like, who else is it obvious to?

+ +

But, you know, sadly, I don't know what the right word is here, but, like, it's hard work. This work of listening it is not very scalable work. You can do some things to operationalize it for sure, but it takes time to engage with humans, to synthesize what you've heard, to share it with your team, to stay on the same page about it. It's not super scalable work, straight up. But it is the most valuable work that you could possibly be doing. So, it's okay that it's not scalable. But yeah, you start to identify these real market insights. And then you kind of have this minute of, like, who else is seeing this? Because this looks really clear to us, right? [laughs]

+ +

ASHLEY: And it's interesting because the last time we chatted here a couple of weeks ago, Lindsey was like, "I'm sure you'll be in a different spot next week. And, you know, you'll be thinking about something different than you are right now." And, in my head, I was like, probably not. I've done a lot of research. It'll probably be the same. And she was right. It's very different from where we were a couple of weeks ago, and the way we're thinking about taking a certain path and circling back to having these conversations that are so critical and really shape the way you're thinking about problems from so many different directions. And so, I thought that was funny that she was right.

+ +

DAWN: Lindsey is always right.

+ +

JORDYN: Another ingredient here that I think is really important that becomes clear when you start doing this work but is a hard thing to describe...and I would kind of love to hear how Ashley has been thinking about this. But if you're not hearing a pattern, if you're out there doing the interviewing and it's just a million different descriptions of reality, that is the surest sign that you are not focused on a small enough addressable group of people. You haven't narrowed into a group of people who are the same.

+ +

And that's really the only way to build a product is to find a group of people who are the same. Make something for them that they love, and then think about where you can go from there. You can't please all of the people all of the time, but you can't please all the people at once, right? You're not going to be able to build a product that does that. And I would say, like, even later, you're not, you know, there's like...it just...it totally dilutes your focus.

+ +

So, if you are out there doing a bunch of interviewing, a bunch of research, and you're just hearing a bunch of different voices, and it sounds like there's no signal there, it's just that you haven't sufficiently narrowed. So, one of the things we've been doing over the last couple of weeks is really trying to figure out who exactly has the pain point the most that is addressable, in the sense that it's a group of people who are similar, similar enough that we can build a product for them, that is going to work for all of them, and we can speak about it in a way that resonates for them?

+ +

And it feels kind of impossible. And it also kind of feels, I don't know, a little bit like cheating. Like, it feels opposite of how I think founders think about making products. It's like, you want to build a thing that appeals to a lot of people. That's the drive, and that is absolutely the correct long-term drive, right? And it feels a little bit about sort of throw the game by choosing the people. It feels a little bit like you're like, well, of course, we can make something for a group of people if we've already pre-selected who they are, but it's like, yeah, exactly, that's a lot easier [laughs].

+ +

So, anyway, I didn't want to move on without sort of mentioning that that focus on a persona is really, really critical. Yes, we're doing a ton of research, or we're talking to a ton of different people. But in each of those categories, we're really trying to figure out who are addressable niches to start?

+ +

ASHLEY: Yeah, and I think just getting as specific as possible, like Jordyn has said, has been...in my mind, I was thinking, we don't want to do that because then that really limits the amount of people we can help or the amount of people who could really benefit from a solution. But the good news is that once you solve a problem for a group of people, you can expand upon that and use the learnings from that solution and build something that can help more and more people. Because initially, I was like, "No, we don't want to do that. That's crazy." And she was right.

+ +

DAWN: Jordyn is another one of those people that's always right [laughs]. Mostly right. Okay, so you're using what you're finding and hearing in these conversations to help guide, you know, your focus, but especially the space that y'all are operating in, FinTech, in particular, is a very complex space. And so, there's all sorts of other dynamics that have to come into your strategy and direction for the product. So, how are y'all navigating which dynamics to focus on outside of what you're discovering in these conversations, you know, whether that be infrastructure, regulatory things, like, you know, all of those complexities?

+ +

ASHLEY: Yeah, I would say, right now, we're focusing on infrastructure. And that will inform the regulatory piece because there are so many nuances in the space as it relates to what type of product you're building for whom and where. And so, once that is more crystallized, the regulatory pieces can be plugged in. And you're right; it's super complex. And we want to make sure that we're being extremely compliant in every possible way. And so, that is highest priority.

+ +

But I think, too, to try to boil the ocean with all the different nuances when maybe we're not as crystal clear on the infrastructure would be, I don't know, waste of time is the wrong phrase, but I think it would not be the most efficient use of time. I think getting that infrastructure and then nailing down the regulatory piece around the infrastructure is the best path that we're thinking.

+ +

JORDYN: Yeah, I would just add here that this space is really complex. And the image that's kind of emerged most recently is of a giant puzzle we're putting together. There are a lot of pieces to this puzzle. It's not a thousand-piece puzzle, but it feels close [laughs]. But where we're starting out is where you start with any puzzle, which is the corner pieces. Like, what are the cornerstones of what we're doing? And figuring out what those are, always centered in what the value proposition is to customers, right? We need to know what their incentives are, what they need and want. That's the cornerstone.

+ +

And then the feasibility and the infrastructure and, you know, regulatory are the blanks we fill in sort of from there. But without demand, none of that stuff would matter, right? It's a really hard thing because you start to think about...and we talk about this stuff all the time; I want to call out. It's not, like, we're strictly disciplined about we're not talking about that right now. Like, it comes up all the time.

+ +

And we're sharing what we're learning and what we're seeing out there. We're looking at other products that have, you know, come onto the market recently, like, long-time players in the FinTech space. We're looking at all of that stuff, what they've done, what they've built, and how. We're thinking and talking about those things, but those decisions are not as important as making sure that we're as close to the customer as we can. That's the cornerstone pieces.

+ +

Our customers and our partners, what are their motivations? What do they need? And then, once we have those corner pieces, then we fill in the puzzle. It's a big, complex puzzle, but you always have to start with something of value. If you're not bringing something of value to those folks, none of this other stuff really matters.

+ +

DAWN: This is making me wonder if there are people out there who start their puzzles in the middle [laughs].

+ +

JORDYN: Guilty as charged [laughs].

+ +

DAWN: I meant more [inaudible 18:57]. I didn't mean metaphorically. We know that happens [laughter], unfortunately.

+ +

JORDYN: Yes, no, I have absolutely been that person personally, you know, and it can be really distracting. The feasibility puzzle is very interesting, and it feels inevitable. Like, you're going to have to solve those problems. The problem is that you don't know which of them is going to matter right now. So, solving those problems now, like Ashley said, it's sort of a waste of time. You might end up solving them eventually, right? But you need to figure out the strategic path forward. And so, yeah, it's tough.

+ +

I have an engineering background. I love solving complex puzzles. It's very tempting to go do that right now, and it feels much more tangible. Like, okay, we can go read the regulations. We can, like, look at what the infrastructure can do right now. Let's go solve that problem. But it would be just a colossal waste of time to go off in that direction right now. And we don't yet know fully what the value proposition is for whom. Like, that is the gem at the heart of this.

+ +

I want to acknowledge that there are software efforts out there where the core value really is in a technical innovation. But I would still argue that the timing of bringing that technical innovation to market has as much to do with the market. We can see this over and over again with tons of technologies that were developed years or decades ago, but the market was not at a place where it needed that thing yet.

+ +

And I really say needed; wanted is a different thing, right? You need to get to a place where the need is red hot. So, it's tough. The puzzle is fascinating. It's very distracting. We end up talking about it a lot, but we have to, like, bring ourselves back to the stakeholders.

+ +

DAWN: To wrap things up, now that y'all have sort of deepened your understanding of things, what can you expect from the process going forward? What should we expect to sort of hear about next time we meet?

+ +

JORDYN: We're actually already edging into this, and it's fun to watch how this process happens. When you start to hear something repeatable, you inevitably move into prototyping because you start to have a real shared understanding of what it is you need to put in front of people.

+ +

We're just now, I would say, like, today, getting to the place where we're confident that we need to be testing messaging in particular. We've heard enough things that we need to start testing. Like, are we talking about the problems in the way that, you know, customers and our partners are talking about them? And we need to start trying that language out and then seeing how it resonates. That's the first piece of testing. We're already starting to conceive of workflows, like a prototype concept.

+ +

It's so fascinating how, again, it's just always is a consequence of alignment and insight. You don't have to plan it. It emerges. As soon as you've started to put the pieces together a little bit, it's just very natural that, as a group, you start talking about how you might address this problem. You can tell when we've gotten there because we are aligned. In the same way that you're hearing the same thing from the customer, you start to see the same solution because it's clear what is needed. So, we're really moving into that.

+ +

I want to make it clear, like, we don't stop interviewing. We don't stop talking to folks. But the sort of how specific we are with what we're asking and what we're showing people changes a little bit. That's really just starting to happen now. And I'm sure we'll have a lot more to say about that next time [laughs].

+ +

ASHLEY: Yeah, it's been a lot of fun. I'll say the value of the team is incredible. I can't stress that enough. Just this morning, I came to our morning sync and was like, "Listen, I learned this thing. I think it's over. We're done." And Jordyn and team were like, "No, this is actually a really great thing." And, you know, I'm just like, they're going to give up. They're going to shut it down. They're going to say, "No, we don't want to work with you." And they're like, "This is great news."

+ +

And so, just the diversity of perspective is so different, and it's really great to have that. Because sometimes you can get focused on something in such a linear way that you're like, there's no way out of this thing. And you kind of miss the forest for the trees, so...

+ +

JORDYN: I'm glad you brought that moment up. I was hoping we would talk about it during this live session because it was one of those moments where you were like, "I have some really bad news. I learned something. This is very sad." And you kind of talked about it a minute.

+ +

I had a sort of unbridled glee [laughs]. I was like, oh, awesome, because we knew enough to know there was, like, we were missing something. There are a bunch of solutions in the market that look very different than what we were considering. And we were like, why? There's got to be a good reason. These people are not dumb. The market they're seeing is not different from the market we're seeing. So, like, why have they made a different call?

+ +

And this piece of information, you know, Ashley showed up and was like, "Hey, I learned something, here it is." And I was like, "That's the piece of information. Great." So, now we actually can make a plan. We are still sort of convinced of the value that we were driving toward. And now we just have an added understanding of what it will take to get there. Good. Now we know what it'll take.

+ +

It's really terrible to have an idea of the value prop that you want to pursue and not have any idea of how would it get there. But now we actually really did feel like a piece of a puzzle falling into place. And it was hilarious because Ashely was, like, very grim, and then I was like, "Oh," I was like, "Great." [laughs]

+ +

ASHLEY: I was like --

+ +

JORDYN: Ashley was like, "Wait, what?" [laughs] It was very funny.

+ +

ASHLEY: Yeah, it was great. I was like, I hope the rest of my day is this good, so...

+ +

[laughter]

+ +

DAWN: Well, I'm sorry to say, Ashley, but you can't get rid of us that easily [laughter]. Thank you both for chatting with me today.

+ +

If y'all want to stay updated, you can follow along on LinkedIn or YouTube. We do these live streams every two weeks. We also share incubator news and updates on our blog, so thoughtbot.com/blog. You can always go to the incubator site to understand a little bit more about the program. That's thoughtbot.com/incubator. Send us your questions if you have them. And you can always attend the lives, comment on the threads, send us an email. We love to hear from y'all. Thank you for tuning in

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble, Dawn Delatte, and Jordyn Bonds.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JNNvtnl3 + + ]]> + + Ashley Sheble + Dawn Delatte + Jordyn Bonds + + + thoughtbot's Incubator Program Mini Season - Episode 01: AvidFirst with Ashley Sheble + https://podcast.thoughtbot.com/incubatormini1 + 89aa52e1-a052-4d03-9007-726f933a8cba + Wed, 01 Nov 2023 00:00:00 -0400 + thoughtbot + + full + 12 + thoughtbot + Lindsey Christensen is back as the Marketing Lead at thoughtbot! She's joined by guests Jordyn Bonds, the Director of Product Strategy at thoughtbot, and Ashley Sheble, a founder currently participating in thoughtbot's eight-week startup incubator, to discuss the multifaceted journey of entrepreneurship. + +thoughtbot's Incubator Program aims to help founders like Ashley turn an idea into a viable product. They're currently at the stage of validating assumptions about the problem space and target market. Jordyn introduces a new concept: a project roadmap visualization that includes an "emotions workstream." This is designed to help founders anticipate and navigate the emotional rollercoaster often associated with the early stages of startup development. + +Ashley finds the roadmap valuable, especially as it challenges her to examine her ideas from multiple perspectives. She appreciates the one-on-one support from the Incubator team, which complements her own expertise. She also speaks to the liberating aspect of acknowledging emotions in the startup journey, which is especially pertinent for female founders who often face additional challenges like lack of funding. + +Jordyn emphasizes the importance of early and continuous customer engagement for product validation and innovation. She encourages aspiring entrepreneurs to talk to potential customers as soon as possible to iterate and learn from these interactions. Jordan and Ashley stress that embracing the logical and emotional aspects of entrepreneurship leads to more effective and grounded decision-making. + 30:38 + no + + + Lindsey Christensen is back as the Marketing Lead at thoughtbot! She's joined by guests Jordyn Bonds, the Director of Product Strategy at thoughtbot, and Ashley Sheble, a founder currently participating in thoughtbot's eight-week startup incubator, to discuss the multifaceted journey of entrepreneurship. +thoughtbot's Incubator Program aims to help founders like Ashley turn an idea into a viable product. They're currently at the stage of validating assumptions about the problem space and target market. Jordyn introduces a new concept: a project roadmap visualization that includes an "emotions workstream." This is designed to help founders anticipate and navigate the emotional rollercoaster often associated with the early stages of startup development. +Ashley finds the roadmap valuable, especially as it challenges her to examine her ideas from multiple perspectives. She appreciates the one-on-one support from the Incubator team, which complements her own expertise. She also speaks to the liberating aspect of acknowledging emotions in the startup journey, which is especially pertinent for female founders who often face additional challenges like lack of funding. +Jordyn emphasizes the importance of early and continuous customer engagement for product validation and innovation. She encourages aspiring entrepreneurs to talk to potential customers as soon as possible to iterate and learn from these interactions. Jordan and Ashley stress that embracing the logical and emotional aspects of entrepreneurship leads to more effective and grounded decision-making. +Follow Ashley Sheble on LinkedIn (https://www.linkedin.com/in/ashley-sheble/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +LINDSEY: All right, we are live. So, thank you for joining us today. So, we've got a new founder that's going through thoughtbot's startup incubator. And we're going to be checking in with her as she goes through the program, learning what she learns, learning about the process. +Quick reminder: thoughtbot is a development and design company. We help founders and existing companies create, launch, and improve amazing products and their teams. And one way we do that is through our startup incubator. The incubator is an eight-week program. And our second session just kicked off, which we're going to be talking about a whole lot today. +So, I'm excited to introduce you to the founder that's going through that process, as well as our fearless leader of the incubator program, Jordyn, I myself, Lindsey Christensen. I'm the Marketing Lead here at thoughtbot. I'll be asking lots of questions. But if you also have questions, please enter them in the chat, and we'll get to those as well. Before we get to Ashley, I'm going to start off with Jordyn. For those who may not be familiar with you, can you tell us who you are and what you're doing? +JORDYN: I am Jordyn Bonds. And I am the Director of Product Strategy on thoughtbot's, Ignite team, which is the team that is kind of experimenting with this incubator, shall we say. And I am a two-time startup founder myself. I've worked at other early-stage startups as initial head of product. Long ago, I spent ten years as a software engineer. So, that's my distant background. And I live in Boston. +LINDSEY: Oh, we got our first comment. Someone says, "Thanks for sharing your experience." Thank you. Welcome. Love that. Keep the comments and questions coming. +Okay. And now for our latest guest of honor. Ashley, can you introduce yourself to the audience? A little bit about you and maybe even about your journey to bring you here today. +ASHLEY: Yeah, absolutely. So, hi, everybody. My name is Ashley Sheble. I'm currently based in Houston, Texas. I have about 15 years of experience in sales and operations roles. And I have two kids. I've got one who started third grade yesterday and one who started her senior year of high school yesterday, which is crazy. Time really flies by. +But the reason why that's relevant for this conversation is because I have attended so many college tours over the past few years and started learning about just how expensive higher education has become. I had no idea that a public four-year in-state school could cost $100,000 plus for just four years. And then, you start looking at out-of-state and private schools, and that number doubles, which is crazy to me. +So, after I got through that initial sticker shock, I was like, how is this possible? Like, now I understand why the student debt crisis is happening. And became really passionate about learning more about it and trying to figure out ways that I could help. Because obviously, the solutions and tools we have today to help people prepare for the education they or their children or family members need or want just aren't working. So, became really excited about that and working with thoughtbot as their second founder to explore this further. +LINDSEY: Amazing. So, Ashley, fighting the good fight. Student debt, I know, a topic near and dear to many people who are dealing with this. You mentioned your kid's journey to college is what started the idea. Let's dig into that a little bit more. How are you approaching the challenge, the problems that you see? Or maybe, like, how long it's been that you've been kind of playing around with this idea. +ASHLEY: Yeah, absolutely. So, I'm in a graduate school program and have used this as an opportunity to really explore different ways to attack problems. I became really interested in innovation and entrepreneurship at grad school and began just doing research, learning about ways to solve really big, complex problems, and found that technology could really be an interesting way to approach the student debt problem differently than what's been done before. +It's an industry that has largely lacked innovation, and have been working with professors and experts just to think about ways to apply technology to this really complicated problem to provide a more simple solution for people who just want to pay for school. +LINDSEY: And this is your first time being a founder. Is that right? +ASHLEY: It is. So, thank goodness for thoughtbot being my partner here because I'm not a technical person, meaning I don't develop software. I'm not a software designer, and knew that that was going to be a critical piece of developing a solution. And so, I'm grateful for the opportunity to work with Jordyn and her team. +LINDSEY: Have you, like, always thought you would, at some point, start your own thing? You know, have you always been entrepreneurial? +ASHLEY: Yeah, I think so. I can tell you my first business started in third grade. I launched my babysitting venture and marketed my services all over the neighborhood and church, and wherever would allow me to hang up a flyer, and had a pretty steady book of business, if you will. And in hindsight, I really cannot believe that parents allowed a 10-year-old to babysit their kids. You know, maybe in the '90s there were fewer questions–definitely less legal restrictions around age. +LINDSEY: The '90s were wild. +ASHLEY: The '90s were wild, yeah. Maybe I just seemed mature and responsible. I don't know. I don't know. +LINDSEY: Amazing. All right. Jordyn, so Ashley submitted for the thoughtbot incubator. What stood out to you in that application? And why did she seem like, you know, the right fit to go through the program? +JORDYN: Yeah, Ashley's application was just totally...it had that combination of prepared, done her homework, done the work to present the story well, but also clearly had a passion and a connection to the problem space. It wasn't just, like, a purely academic exercise for her, and just came prepared–really gave thoughtful answers in the application. There's a number of interviews that happened during the application process. She showed up with bells on and asked really good questions, which is something we always look for from founders as well. And she just knocked it out of the park. +ASHLEY: Thank you. +LINDSEY: And why was maybe where she is in her business or product journey a good fit for the incubator? +JORDYN: Great question. So, we sit at a really special moment, which is usually founders are coming to us, well, hopefully, founders are coming to us pre-product. So, they have not built a thing yet. They're basically at that moment where they've identified an opportunity. They've given it lots of thought, done a ton of research, maybe started talking to people about it. +But they're not sure how to take an idea, an opportunity, and what happens between that moment and innovation, actually a plan for a product, a strategic plan for product, and the ability to execute on that. There's a big gap there in understanding, especially for first-time founders. It certainly was a gap for me as a [laughs] first-time founder. That's the ideal candidate for us. +That said, we do have folks coming to the incubator who are interested in executing, like, a strategic pivot. Maybe they've found that the first thing they did was just, like, a market flop, and they basically want to do the programming. They're sort of starting over. Maybe they have a little bit...they're basically like, "Hey, we disqualified one idea. [laughs] We would like to come up with some other options." Those folks are also a good fit. And that is exactly the moment that Ashley is at. She's done a lot of great research so far–has a really interesting idea, interesting take on an interesting problem, but could really benefit from the programming of turning that into technical innovation. +LINDSEY: Which leads me back to you, Ashley. Can you tell us a little bit about your pre-thoughtbot research, like, both, like, how you approached it and maybe even some things that you learned that have helped you with your early direction? +ASHLEY: Yeah, absolutely. So, initially, just did a lot of industry research, just general population research, and then became a little bit more focused on solving problems for families in the U.S. right now. So, narrowing down that market scope. +And then, our focus right now is drilling into: how can we serve parents, students at each phase of their journey as parents or students, making sure that we are adding value as we're creating a service to help attack saving for college in a really effective way that is easy to do and is also going to help somebody be financially prepared to pay for a really expensive price tag without having to rely on student loans? +And so, we're doing a lot of focused research right now, building on what I did in grad school with professors and mentors and experts there, but being more focused and intentional around understanding each phase of the customer journey. So, whether you're a new parent, maybe a parent of kids that are a little older, or a parent of kids that are about to go to college or in college, how are we providing value at each stage of that journey? And so, we're really focusing in with customer interviews, understanding the pain points, and understanding what value is lacking as we think about building something that people want and like to use. +LINDSEY: In that early research, is there anything you learned or, like, positive signals you got as you were talking to people where it gave you a motivation to keep going, like, there is a good idea here to follow? +ASHLEY: Yeah, there have been some ideas that we're finding are just absolutely terrible, and they're just not going to work, which is good to know now before we spend a lot of time chasing something that's not going to be helpful. And also really finding some interesting patterns among conversations. We're digging in a little more where, initially, we thought, oh, nobody cares about that, or, oh, that's not a big deal. That's not a pain point, but actually, it is. +So, Jordyn, with her experience as a founder in prior experiences she's been able to use what she learned that maybe went well or didn't go as well as she had hoped and apply that learning to what we're doing together on this particular project. And so, that's super valuable, helps me avoid some rookie mistakes, and definitely prevents us from wasting a lot of time and resources that probably would have been wasted otherwise. +LINDSEY: Jordyn, can you tell me a little bit more about the kickoff, where we are? Because this is early, early days, where, you know, maybe a week in. You know, what does that initial kickoff with the founder look like? What are you doing? +JORDYN: Yeah. So, the first few days are really spent...we as a team on the thoughtbot side need to get to the place where we know everything the founder knows to date. So, it's very intense, a lot of, like, resource sharing, research sharing, conversations, a lot of elliptical conversations where Ashley will tell us something, we'll all go off and do some digging and some research, and come back and be like, ask her some questions, where she's like, [laughs] "If you recall, I said that to you," you know. +But, basically, it's one of those sort of processes where you don't know what you don't know. You start to understand. You come back, you ask questions, you dig. And the process is really about figuring out: where are the holes? So, Ashley has done a ton of really great work. She is but one person who has had divided attention. So, there are some places where we have some assumptions, all of us as individuals, and Ashley, specifically as a founder, has some assumptions about this problem space that we haven't validated yet. We haven't validated or invalidated. That's really what we're looking for. +It's like, is this hunch correct, incorrect? How do we know? So, we're really in those first few days are listening for those assumptions, for those untested assumptions. There's a ton of stuff in there where she's just like, I know the answer to this already. Here's what I know, and here's how I know it. Great, cool, validated, got it. But there's this other set of things that really then becomes the focus of the subsequent weeks of work. +And often, we find what those assumptions center around are early adopter market characteristics. There's the big vision, right? Which we don't doubt. Basically like, we do not disagree that paying for college is a huge problem. The student debt crisis is huge. There's a million ways to go about addressing that problem. How are we going to, from where we are right now, lay a pathway where we build value upon value? We find something valuable to give the market where it is right now, where we are right now, and then we build from that. +And so, you know, there's assumptions about who needs this, who wants this, who's struggling to pay for college, who's having no problem at all paying for college. But what we're trying to do is sort of zoom in on that group of folks, very tiny, specific group of folks who are having this problem the most acutely in a way that we are best situated to address. That's the magic we're trying to do. +So, it's really those early days are about listening to what Ashley knows, going out into the market, doing some research, follow-up research, but then really trying to come up with an early adopter hypothesis. And then immediately, as quickly as possible, interviewing as many of those people as we can so that we can validate or invalidate the assumptions we have about them. So, that's really the phase that we just started. Like, today and yesterday, we just started interviewing. +We have our first sort of hypothesis about...Ashley mentioned the journey of, like, beginning of child's life. Maybe, as a parent, I have aspirations for this child to go to college. Where do I start saving? You know, that end of the journey all the way to I am actively paying for a college education right now. Where in that journey are the pain points? And can we focus specifically on a particular group of people at a particular moment in that journey in order to provide maximum value right now and then expand from there? +So, we're doing a bunch of interviewing. I had a customer persona interview right before coming to this. You immediately start learning. There's just no substitute for it. The thing I tell founders constantly and I just sound like an absolute broken record, but you got to talk to people. You got to start talking to them now. You got to keep talking to them. You got to think hard and creatively about what you're hearing and who they are. And that's really the work that we're doing together right now. +LINDSEY: Exciting. [crosstalk 15:04] Ashley, I was going to say how is this kickoff then for you? +ASHLEY: Really good. One thing Lindsey and team have brought to the table, especially thinking about me working as a solo founder, is just around the fact that everybody has different perspectives. And we all have different expertise and different experiences that we're bringing to the table. So, the way that I've been thinking about a problem could be 180 from the way Jordyn's thinking about it or some other folks on our team. +And it's really interesting to have to really test a lot of these assumptions. I'm like, oh yeah, everybody thinks this way. Oh yeah, everybody does this. And it turns out I'm the only one, or maybe only a couple of us in the group are aligning with that perspective. And so, it has been so valuable as a solo founder to have a team of people researching the same problem from a different perspective. So, I just wanted to add that. +LINDSEY: No, that's a great one. And that is sometimes challenging, I think, for the founders. I don't know if you're finding this when you're just getting started. But as you go through the process, things that you have maybe held to be true or facts you end up finding out are assumptions, or maybe assumptions that are false. Which also reminds me of Jordyn: you were telling me something very interesting that you're doing during this incubator, which is founder emotions mapping. +JORDYN: [laughs] Yeah. +LINDSEY: What is this? +JORDYN: Yeah, we've got this project roadmap visualization. It's a Gantt chart. Y'all, it is a Gantt chart. And it basically just lays out, broadly speaking, what we're going to do together on what timeline. It helps us, together, visualize where we're going, where we are, and what we need to do in between so that we don't lose sight of that. +And this time, it was the first time that we added...we had this sort of insight that we should add an emotions workstream [laughs] because so much of the early stage is just an emotional rollercoaster because you are learning so much so fast. And if you're lucky and you immediately go into innovation, delivery, learning more, scaling, right? It's this very fast loop. And it's not just that you're learning stuff about your market really quickly. You're learning stuff about yourself and about the work. The learning curve is just really steep. +And we had realized that you end up going through this cycle of emotions that's pretty predictable [chuckles], and that's great, right? We want founders to know that their emotions...not only are their emotions, like, totally valid, we wanted to welcome them in a little bit more than we have in the past. +So, we added this little emotions work stream that was basically just like, hey, first week, first few days of kickoff, you're going to feel like a million bucks. You're like, yes, I know some stuff. I finally got a team working on this with me. To the moon, right? Like, you got this, like, very optimistic, exuberant kind [laughs] of attitude. +Immediately, you start hearing perspectives you hadn't heard before in your problem space. You start uncovering contrary evidence. We start talking to people. Immediately, you start to learn things that you didn't know you didn't know, right? So, up until this moment, you've just had some blinders on, and you're like, the path is clear, and it is amazing. I'm just going to motor my way to success. +And our process is about really taking those blinders off and figuring out what is actually around me on this road? Are there words of attackers coming at me from the sides? Like, I need to know those things, right? But what happens is you start to know what you don't know. And so, there's this dip. You start off very optimistic, and then you have a week or two of declining mood where you're mortified. You learn that you had some assumptions that are not valid. There's some other risks and things lying out there in the market. It's truly mortifying. +Maybe you learn about a competitor you didn't know about because you just weren't searching the right words, or whatever it is, right? That moment a lot of founders are just like, the moment I discovered my first real competitor, and I had, like, a panic attack, right? That happened to me. +But then you start to make a plan around those things, okay, cool. Like, maybe we need to differentiate ourselves. Maybe there is some more information we need to figure out about how to go after this, et cetera. And you start that slow climb of dealing with the new information that you have, right? And filling in those gaps [inaudible 19:22]. +Then you start to climb out of the hole, right? You're like, okay, we got a plan. I got a team. We're doing the work. Awesome. You learn new, really exciting things. And then you end up back on that, like, high where you're like, this is so awesome. We have the best idea. And now we know everything there is to know. But no, no, you've just reached a new plateau [laughs]. And there are more things to be learned and more things...So, it's this really predictable cycle, and that's fine. That's good. You wouldn't be here if you didn't care about the problem space, right? If you weren't passionate about it. +And so, we really wanted to actually call that out this time and make space for it and put it on the map. Hey, we might be feeling this way right now, just heads up. That's okay. We're going to be feeling really great in a week. And then, the week after that, we're going to be feeling [laughs] like garbage again. It's okay. Because knowing that really makes you feel. +And it took me a long time as a first-time founder to realize that, like, my moment-to-moment emotional experience is...I need to make space for it. It is what it is. But it is not the story of my business. And it's a thing you just kind of have to learn after going through a bunch of those cycles. But, like, part of what we're trying to do with the incubator is help founders not fall in those potholes, not make the rookie mistakes, as Ashley put it. +And one of those rookie mistakes is thinking that the first time you identify a direct competitor, everything that you've been working toward for the last year is useless, and you should quit, and everyone thinks you're a fool, and, like, whatever crazy narrative you [laughs] have going on in your mind [laughs]. We're kind of here to be like, it's okay. This is to be expected: onward and upward. The hard work continues. +So yeah, it's very fun. At some point, we will publish a little version of this visualization with our little cycle of feelings on the bottom. But it reminds us to make space for them in the conversation when we are doing those check-ins. Like, here we are on this roadmap, and here's where our feelings may or may not be. +ASHLEY: Her recap for day one is spot on. I left that conversation; I walked out of my office and told my husband, I said, "Listen, we're going to solve the student debt crisis. We're going to." And he was like, "Really? Okay." And I was like, "Yeah, we are." And then, like, two days later, I was like, "No, we are not going to be effective at this." And then, the next day, I was like, "No, I fixed it. We fixed it. It's fine." So, being able to reference that chart is really helpful and validating for me as a person to be like: I should be feeling like this; yes, I do. Perfect, you know, I'm right on track. +And I think, too, as a founder, and especially as a female founder, you are expected to just keep it together. Maybe that's a self-imposed belief. But when you think about the fact that female CEOs only have about 2% of the venture capital funding, it's like, you know, why would I ever raise a red flag for myself by letting my emotions be part of the conversation or letting my emotions even have a place in the business I'm building? And so, for her to say, "Listen, no, that's a really important part of this journey; we need to talk about it and make space for it," is really liberating. +And I think, too, just when you think about what has happened with the pandemic and all the awareness around mental health and behavioral health, and making sure that we're making time for managing emotions has been more important than ever. We see the research that if you don't manage those emotions, they're going to manage you. So, find a productive way to do it. Work with your team and find support in a way that works for you or a productive way to just kind of get some stress out without having to just internalize everything because that never works out. +So, it's been really great to have her be able to bring that as part of our conversation and our project plan and make sure that it's a relevant piece. +LINDSEY: Very well said. And I'm so glad you did bring up that point about being women founders, and, you know, having more of a, you know, an uphill battle and feeling that emotions are a sign of weakness or a sign that you don't know what you're doing. We have more impostor syndrome because of these outside factors like lack of funding, you know, lack of support. So, it's really great for you to share that and hopefully inspire others. In fact, we got a comment: "Ashley, your drive and ambition to solve a huge issue in our country is so inspiring." Thank you -- +ASHLEY: Oh, thank you. +LINDSEY: For adding that comment, folks who are following along. So, it sounds like, for you, the emotion mapping is a positive experience, where it's helping you kind of ground yourself as, even these early days, some assumptions are being challenged, or you're seeing some challenges in the business idea. +ASHLEY: Oh yeah, absolutely. Circling back to the thoughtbot team, couldn't do this without them in a really tactical and effective way. Because they have the experience and the skills that I don't have, and us working together on this same problem has been incredible. +LINDSEY: How did you come to get connected with the incubator and thoughtbot and submitting that application? +ASHLEY: Yeah. So, I'm part of the Harvard Innovation Lab, which is the innovation program at Harvard for all the students. And somebody was talking about this incubator program, and there are a lot of incubator programs out there. And so, initially, I thought, oh okay, well, this will be just, like, all the others and probably not what I'm looking for. But I did some research and looked at the website and read more about the program and thought, oh my gosh, this is exactly what I've been looking for and didn't know existed because it is that one-on-one support, and most incubator or accelerator programs you're one of many companies going through the process. +And so, the feedback I have from others who have gone through similar paths is it's great, and it's nice to have a cohort. But at the same time, you're largely figuring things out for yourself, which I was doing anyway. So, I was like, well, what value is that going to bring? This is a one-on-one experience. There's a team dedicated to working on this solution, problem, et cetera with me. +And I'm just so thankful that there are software developers and designers that are interested in helping me tackle this challenge also. So, that was really exciting to have other people also excited about the same problem but able to bring different skill sets to the table to actually bring this to life. +LINDSEY: Oh, that's great. Thanks for sharing. All right, so nearing the end of our chat here. Jordyn, what is next? I think we're going to check back in in a couple of weeks. What might those weeks include? +JORDYN: Well, as I mentioned, we really began customer interviewing...I say customer, and this is really...often, it means a lot of things. It means interviewing people who might be users, people who might be customers, people who might be partners in what we're building. And we are just going to learn so much so quickly. We're going to invalidate a lot of things. We're going to come up with new ideas. So like, we will be different humans with a different perspective on the world in two weeks, which is really exciting. +But really, so this effort is really about learning how to have your audience lead you. And it isn't about just listening to your audience. So, when they say like, "Make the button blue," you're like, "Okay, blue button, you got it." It's like actually hearing about their lives and their pain points and then innovating. They're not software developers, your audience typically, so they aren't solving this problem themselves. It's up to you to translate what you're hearing into something innovative. +I think a standard metaphor here or example–I guess it's more like a case study—is, like, the famous Ford quote that, like, if he had pulled people and asked them what they wanted, they would have said faster horses, not a car, right? So, it's like, you got to look at the landscape, look at what's possible, maybe new things are possible technically, right? And so, we can solve this problem better, a problem that we know humans have, which is paying for college, or, in Ford's case, getting from point A to point B quickly. +So, it's really our job to listen and let what we're hearing from the audience be our guide, but not just, like, sort of take dictation, right? And that's where the skill and having done this lots of times comes in. So, that's what we're going to be doing in the next two weeks. We're going to be listening very closely, iterating on the questions that we're asking and who we're asking them to. And out of that will emerge the strategically sound innovation path, and it never fails to work. I cannot stress enough that if you talk to [laughs] people and you listen to them, opportunities become very clear. +So, if any of you out there are nursing an idea that you've been nursing for a while, and you're like, I'm not ready to talk to people about it; I need to think about it longer, nope. Talk to people about it today, please. Will you screw that conversation up? Yep. But the sooner you have it, the sooner you'll screw it up and learn from it. The longer you wait, the more your assumptions build, and then it gets very tense and very wrong. And you could really think yourself off into, like, a very weird place. +So, I encourage you all to do your research; talk to people about what you're thinking, what you're working on, the people for whom it matters. And that is what we are going to be doing for the next two weeks, and then is what Ashley is going to be doing for the rest of the life of this company because you never stop. It's not a thing. You don't do, like, a customer research sprint, and then you stop. If you stop doing that, you stop innovating, and then other people in the market overtake you. Sorry, I feel passionate about this issue [laughs]. +LINDSEY: No, that's good. That's a quick pitch at the end here for everyone to apply to the next session incubator. Start getting the idea and the research you've been doing together. This could be you. So, hope you'll join us again in two weeks as we catch up. And yeah, as Jordyn said, things are going to be...there'll be so many insights in that amount of time. I almost started laughing after I asked, like, what will happen in two weeks? Because I know it's going to be so different, you know, day to day you all are doing so much work, learning so much. So, I'm really excited to learn about that. +So, stay tuned with us here in two weeks. We'll also be posting updates to the thoughtbot blog: thoughtbot.com/blog. And just really looking forward to following along with your journey, Ashley. Thank you so much for joining and sharing today. +ASHLEY: Yeah, thank you for having me. +LINDSEY: Jordyn, thank you as always. +JORDYN: Of course. +LINDSEY: And thank you, audience. Everyone have a fantastic day. +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guests: Ashley Sheble and Jordyn Bonds. + + + Lindsey Christensen is back as the Marketing Lead at thoughtbot! She's joined by guests Jordyn Bonds, the Director of Product Strategy at thoughtbot, and Ashley Sheble, a founder currently participating in thoughtbot's eight-week startup incubator, to discuss the multifaceted journey of entrepreneurship.

+ +

thoughtbot's Incubator Program aims to help founders like Ashley turn an idea into a viable product. They're currently at the stage of validating assumptions about the problem space and target market. Jordyn introduces a new concept: a project roadmap visualization that includes an "emotions workstream." This is designed to help founders anticipate and navigate the emotional rollercoaster often associated with the early stages of startup development.

+ +

Ashley finds the roadmap valuable, especially as it challenges her to examine her ideas from multiple perspectives. She appreciates the one-on-one support from the Incubator team, which complements her own expertise. She also speaks to the liberating aspect of acknowledging emotions in the startup journey, which is especially pertinent for female founders who often face additional challenges like lack of funding.

+ +

Jordyn emphasizes the importance of early and continuous customer engagement for product validation and innovation. She encourages aspiring entrepreneurs to talk to potential customers as soon as possible to iterate and learn from these interactions. Jordan and Ashley stress that embracing the logical and emotional aspects of entrepreneurship leads to more effective and grounded decision-making.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: All right, we are live. So, thank you for joining us today. So, we've got a new founder that's going through thoughtbot's startup incubator. And we're going to be checking in with her as she goes through the program, learning what she learns, learning about the process.

+ +

Quick reminder: thoughtbot is a development and design company. We help founders and existing companies create, launch, and improve amazing products and their teams. And one way we do that is through our startup incubator. The incubator is an eight-week program. And our second session just kicked off, which we're going to be talking about a whole lot today.

+ +

So, I'm excited to introduce you to the founder that's going through that process, as well as our fearless leader of the incubator program, Jordyn, I myself, Lindsey Christensen. I'm the Marketing Lead here at thoughtbot. I'll be asking lots of questions. But if you also have questions, please enter them in the chat, and we'll get to those as well. Before we get to Ashley, I'm going to start off with Jordyn. For those who may not be familiar with you, can you tell us who you are and what you're doing?

+ +

JORDYN: I am Jordyn Bonds. And I am the Director of Product Strategy on thoughtbot's, Ignite team, which is the team that is kind of experimenting with this incubator, shall we say. And I am a two-time startup founder myself. I've worked at other early-stage startups as initial head of product. Long ago, I spent ten years as a software engineer. So, that's my distant background. And I live in Boston.

+ +

LINDSEY: Oh, we got our first comment. Someone says, "Thanks for sharing your experience." Thank you. Welcome. Love that. Keep the comments and questions coming.

+ +

Okay. And now for our latest guest of honor. Ashley, can you introduce yourself to the audience? A little bit about you and maybe even about your journey to bring you here today.

+ +

ASHLEY: Yeah, absolutely. So, hi, everybody. My name is Ashley Sheble. I'm currently based in Houston, Texas. I have about 15 years of experience in sales and operations roles. And I have two kids. I've got one who started third grade yesterday and one who started her senior year of high school yesterday, which is crazy. Time really flies by.

+ +

But the reason why that's relevant for this conversation is because I have attended so many college tours over the past few years and started learning about just how expensive higher education has become. I had no idea that a public four-year in-state school could cost $100,000 plus for just four years. And then, you start looking at out-of-state and private schools, and that number doubles, which is crazy to me.

+ +

So, after I got through that initial sticker shock, I was like, how is this possible? Like, now I understand why the student debt crisis is happening. And became really passionate about learning more about it and trying to figure out ways that I could help. Because obviously, the solutions and tools we have today to help people prepare for the education they or their children or family members need or want just aren't working. So, became really excited about that and working with thoughtbot as their second founder to explore this further.

+ +

LINDSEY: Amazing. So, Ashley, fighting the good fight. Student debt, I know, a topic near and dear to many people who are dealing with this. You mentioned your kid's journey to college is what started the idea. Let's dig into that a little bit more. How are you approaching the challenge, the problems that you see? Or maybe, like, how long it's been that you've been kind of playing around with this idea.

+ +

ASHLEY: Yeah, absolutely. So, I'm in a graduate school program and have used this as an opportunity to really explore different ways to attack problems. I became really interested in innovation and entrepreneurship at grad school and began just doing research, learning about ways to solve really big, complex problems, and found that technology could really be an interesting way to approach the student debt problem differently than what's been done before.

+ +

It's an industry that has largely lacked innovation, and have been working with professors and experts just to think about ways to apply technology to this really complicated problem to provide a more simple solution for people who just want to pay for school.

+ +

LINDSEY: And this is your first time being a founder. Is that right?

+ +

ASHLEY: It is. So, thank goodness for thoughtbot being my partner here because I'm not a technical person, meaning I don't develop software. I'm not a software designer, and knew that that was going to be a critical piece of developing a solution. And so, I'm grateful for the opportunity to work with Jordyn and her team.

+ +

LINDSEY: Have you, like, always thought you would, at some point, start your own thing? You know, have you always been entrepreneurial?

+ +

ASHLEY: Yeah, I think so. I can tell you my first business started in third grade. I launched my babysitting venture and marketed my services all over the neighborhood and church, and wherever would allow me to hang up a flyer, and had a pretty steady book of business, if you will. And in hindsight, I really cannot believe that parents allowed a 10-year-old to babysit their kids. You know, maybe in the '90s there were fewer questions–definitely less legal restrictions around age.

+ +

LINDSEY: The '90s were wild.

+ +

ASHLEY: The '90s were wild, yeah. Maybe I just seemed mature and responsible. I don't know. I don't know.

+ +

LINDSEY: Amazing. All right. Jordyn, so Ashley submitted for the thoughtbot incubator. What stood out to you in that application? And why did she seem like, you know, the right fit to go through the program?

+ +

JORDYN: Yeah, Ashley's application was just totally...it had that combination of prepared, done her homework, done the work to present the story well, but also clearly had a passion and a connection to the problem space. It wasn't just, like, a purely academic exercise for her, and just came prepared–really gave thoughtful answers in the application. There's a number of interviews that happened during the application process. She showed up with bells on and asked really good questions, which is something we always look for from founders as well. And she just knocked it out of the park.

+ +

ASHLEY: Thank you.

+ +

LINDSEY: And why was maybe where she is in her business or product journey a good fit for the incubator?

+ +

JORDYN: Great question. So, we sit at a really special moment, which is usually founders are coming to us, well, hopefully, founders are coming to us pre-product. So, they have not built a thing yet. They're basically at that moment where they've identified an opportunity. They've given it lots of thought, done a ton of research, maybe started talking to people about it.

+ +

But they're not sure how to take an idea, an opportunity, and what happens between that moment and innovation, actually a plan for a product, a strategic plan for product, and the ability to execute on that. There's a big gap there in understanding, especially for first-time founders. It certainly was a gap for me as a [laughs] first-time founder. That's the ideal candidate for us.

+ +

That said, we do have folks coming to the incubator who are interested in executing, like, a strategic pivot. Maybe they've found that the first thing they did was just, like, a market flop, and they basically want to do the programming. They're sort of starting over. Maybe they have a little bit...they're basically like, "Hey, we disqualified one idea. [laughs] We would like to come up with some other options." Those folks are also a good fit. And that is exactly the moment that Ashley is at. She's done a lot of great research so far–has a really interesting idea, interesting take on an interesting problem, but could really benefit from the programming of turning that into technical innovation.

+ +

LINDSEY: Which leads me back to you, Ashley. Can you tell us a little bit about your pre-thoughtbot research, like, both, like, how you approached it and maybe even some things that you learned that have helped you with your early direction?

+ +

ASHLEY: Yeah, absolutely. So, initially, just did a lot of industry research, just general population research, and then became a little bit more focused on solving problems for families in the U.S. right now. So, narrowing down that market scope.

+ +

And then, our focus right now is drilling into: how can we serve parents, students at each phase of their journey as parents or students, making sure that we are adding value as we're creating a service to help attack saving for college in a really effective way that is easy to do and is also going to help somebody be financially prepared to pay for a really expensive price tag without having to rely on student loans?

+ +

And so, we're doing a lot of focused research right now, building on what I did in grad school with professors and mentors and experts there, but being more focused and intentional around understanding each phase of the customer journey. So, whether you're a new parent, maybe a parent of kids that are a little older, or a parent of kids that are about to go to college or in college, how are we providing value at each stage of that journey? And so, we're really focusing in with customer interviews, understanding the pain points, and understanding what value is lacking as we think about building something that people want and like to use.

+ +

LINDSEY: In that early research, is there anything you learned or, like, positive signals you got as you were talking to people where it gave you a motivation to keep going, like, there is a good idea here to follow?

+ +

ASHLEY: Yeah, there have been some ideas that we're finding are just absolutely terrible, and they're just not going to work, which is good to know now before we spend a lot of time chasing something that's not going to be helpful. And also really finding some interesting patterns among conversations. We're digging in a little more where, initially, we thought, oh, nobody cares about that, or, oh, that's not a big deal. That's not a pain point, but actually, it is.

+ +

So, Jordyn, with her experience as a founder in prior experiences she's been able to use what she learned that maybe went well or didn't go as well as she had hoped and apply that learning to what we're doing together on this particular project. And so, that's super valuable, helps me avoid some rookie mistakes, and definitely prevents us from wasting a lot of time and resources that probably would have been wasted otherwise.

+ +

LINDSEY: Jordyn, can you tell me a little bit more about the kickoff, where we are? Because this is early, early days, where, you know, maybe a week in. You know, what does that initial kickoff with the founder look like? What are you doing?

+ +

JORDYN: Yeah. So, the first few days are really spent...we as a team on the thoughtbot side need to get to the place where we know everything the founder knows to date. So, it's very intense, a lot of, like, resource sharing, research sharing, conversations, a lot of elliptical conversations where Ashley will tell us something, we'll all go off and do some digging and some research, and come back and be like, ask her some questions, where she's like, [laughs] "If you recall, I said that to you," you know.

+ +

But, basically, it's one of those sort of processes where you don't know what you don't know. You start to understand. You come back, you ask questions, you dig. And the process is really about figuring out: where are the holes? So, Ashley has done a ton of really great work. She is but one person who has had divided attention. So, there are some places where we have some assumptions, all of us as individuals, and Ashley, specifically as a founder, has some assumptions about this problem space that we haven't validated yet. We haven't validated or invalidated. That's really what we're looking for.

+ +

It's like, is this hunch correct, incorrect? How do we know? So, we're really in those first few days are listening for those assumptions, for those untested assumptions. There's a ton of stuff in there where she's just like, I know the answer to this already. Here's what I know, and here's how I know it. Great, cool, validated, got it. But there's this other set of things that really then becomes the focus of the subsequent weeks of work.

+ +

And often, we find what those assumptions center around are early adopter market characteristics. There's the big vision, right? Which we don't doubt. Basically like, we do not disagree that paying for college is a huge problem. The student debt crisis is huge. There's a million ways to go about addressing that problem. How are we going to, from where we are right now, lay a pathway where we build value upon value? We find something valuable to give the market where it is right now, where we are right now, and then we build from that.

+ +

And so, you know, there's assumptions about who needs this, who wants this, who's struggling to pay for college, who's having no problem at all paying for college. But what we're trying to do is sort of zoom in on that group of folks, very tiny, specific group of folks who are having this problem the most acutely in a way that we are best situated to address. That's the magic we're trying to do.

+ +

So, it's really those early days are about listening to what Ashley knows, going out into the market, doing some research, follow-up research, but then really trying to come up with an early adopter hypothesis. And then immediately, as quickly as possible, interviewing as many of those people as we can so that we can validate or invalidate the assumptions we have about them. So, that's really the phase that we just started. Like, today and yesterday, we just started interviewing.

+ +

We have our first sort of hypothesis about...Ashley mentioned the journey of, like, beginning of child's life. Maybe, as a parent, I have aspirations for this child to go to college. Where do I start saving? You know, that end of the journey all the way to I am actively paying for a college education right now. Where in that journey are the pain points? And can we focus specifically on a particular group of people at a particular moment in that journey in order to provide maximum value right now and then expand from there?

+ +

So, we're doing a bunch of interviewing. I had a customer persona interview right before coming to this. You immediately start learning. There's just no substitute for it. The thing I tell founders constantly and I just sound like an absolute broken record, but you got to talk to people. You got to start talking to them now. You got to keep talking to them. You got to think hard and creatively about what you're hearing and who they are. And that's really the work that we're doing together right now.

+ +

LINDSEY: Exciting. [crosstalk 15:04] Ashley, I was going to say how is this kickoff then for you?

+ +

ASHLEY: Really good. One thing Lindsey and team have brought to the table, especially thinking about me working as a solo founder, is just around the fact that everybody has different perspectives. And we all have different expertise and different experiences that we're bringing to the table. So, the way that I've been thinking about a problem could be 180 from the way Jordyn's thinking about it or some other folks on our team.

+ +

And it's really interesting to have to really test a lot of these assumptions. I'm like, oh yeah, everybody thinks this way. Oh yeah, everybody does this. And it turns out I'm the only one, or maybe only a couple of us in the group are aligning with that perspective. And so, it has been so valuable as a solo founder to have a team of people researching the same problem from a different perspective. So, I just wanted to add that.

+ +

LINDSEY: No, that's a great one. And that is sometimes challenging, I think, for the founders. I don't know if you're finding this when you're just getting started. But as you go through the process, things that you have maybe held to be true or facts you end up finding out are assumptions, or maybe assumptions that are false. Which also reminds me of Jordyn: you were telling me something very interesting that you're doing during this incubator, which is founder emotions mapping.

+ +

JORDYN: [laughs] Yeah.

+ +

LINDSEY: What is this?

+ +

JORDYN: Yeah, we've got this project roadmap visualization. It's a Gantt chart. Y'all, it is a Gantt chart. And it basically just lays out, broadly speaking, what we're going to do together on what timeline. It helps us, together, visualize where we're going, where we are, and what we need to do in between so that we don't lose sight of that.

+ +

And this time, it was the first time that we added...we had this sort of insight that we should add an emotions workstream [laughs] because so much of the early stage is just an emotional rollercoaster because you are learning so much so fast. And if you're lucky and you immediately go into innovation, delivery, learning more, scaling, right? It's this very fast loop. And it's not just that you're learning stuff about your market really quickly. You're learning stuff about yourself and about the work. The learning curve is just really steep.

+ +

And we had realized that you end up going through this cycle of emotions that's pretty predictable [chuckles], and that's great, right? We want founders to know that their emotions...not only are their emotions, like, totally valid, we wanted to welcome them in a little bit more than we have in the past.

+ +

So, we added this little emotions work stream that was basically just like, hey, first week, first few days of kickoff, you're going to feel like a million bucks. You're like, yes, I know some stuff. I finally got a team working on this with me. To the moon, right? Like, you got this, like, very optimistic, exuberant kind [laughs] of attitude.

+ +

Immediately, you start hearing perspectives you hadn't heard before in your problem space. You start uncovering contrary evidence. We start talking to people. Immediately, you start to learn things that you didn't know you didn't know, right? So, up until this moment, you've just had some blinders on, and you're like, the path is clear, and it is amazing. I'm just going to motor my way to success.

+ +

And our process is about really taking those blinders off and figuring out what is actually around me on this road? Are there words of attackers coming at me from the sides? Like, I need to know those things, right? But what happens is you start to know what you don't know. And so, there's this dip. You start off very optimistic, and then you have a week or two of declining mood where you're mortified. You learn that you had some assumptions that are not valid. There's some other risks and things lying out there in the market. It's truly mortifying.

+ +

Maybe you learn about a competitor you didn't know about because you just weren't searching the right words, or whatever it is, right? That moment a lot of founders are just like, the moment I discovered my first real competitor, and I had, like, a panic attack, right? That happened to me.

+ +

But then you start to make a plan around those things, okay, cool. Like, maybe we need to differentiate ourselves. Maybe there is some more information we need to figure out about how to go after this, et cetera. And you start that slow climb of dealing with the new information that you have, right? And filling in those gaps [inaudible 19:22].

+ +

Then you start to climb out of the hole, right? You're like, okay, we got a plan. I got a team. We're doing the work. Awesome. You learn new, really exciting things. And then you end up back on that, like, high where you're like, this is so awesome. We have the best idea. And now we know everything there is to know. But no, no, you've just reached a new plateau [laughs]. And there are more things to be learned and more things...So, it's this really predictable cycle, and that's fine. That's good. You wouldn't be here if you didn't care about the problem space, right? If you weren't passionate about it.

+ +

And so, we really wanted to actually call that out this time and make space for it and put it on the map. Hey, we might be feeling this way right now, just heads up. That's okay. We're going to be feeling really great in a week. And then, the week after that, we're going to be feeling [laughs] like garbage again. It's okay. Because knowing that really makes you feel.

+ +

And it took me a long time as a first-time founder to realize that, like, my moment-to-moment emotional experience is...I need to make space for it. It is what it is. But it is not the story of my business. And it's a thing you just kind of have to learn after going through a bunch of those cycles. But, like, part of what we're trying to do with the incubator is help founders not fall in those potholes, not make the rookie mistakes, as Ashley put it.

+ +

And one of those rookie mistakes is thinking that the first time you identify a direct competitor, everything that you've been working toward for the last year is useless, and you should quit, and everyone thinks you're a fool, and, like, whatever crazy narrative you [laughs] have going on in your mind [laughs]. We're kind of here to be like, it's okay. This is to be expected: onward and upward. The hard work continues.

+ +

So yeah, it's very fun. At some point, we will publish a little version of this visualization with our little cycle of feelings on the bottom. But it reminds us to make space for them in the conversation when we are doing those check-ins. Like, here we are on this roadmap, and here's where our feelings may or may not be.

+ +

ASHLEY: Her recap for day one is spot on. I left that conversation; I walked out of my office and told my husband, I said, "Listen, we're going to solve the student debt crisis. We're going to." And he was like, "Really? Okay." And I was like, "Yeah, we are." And then, like, two days later, I was like, "No, we are not going to be effective at this." And then, the next day, I was like, "No, I fixed it. We fixed it. It's fine." So, being able to reference that chart is really helpful and validating for me as a person to be like: I should be feeling like this; yes, I do. Perfect, you know, I'm right on track.

+ +

And I think, too, as a founder, and especially as a female founder, you are expected to just keep it together. Maybe that's a self-imposed belief. But when you think about the fact that female CEOs only have about 2% of the venture capital funding, it's like, you know, why would I ever raise a red flag for myself by letting my emotions be part of the conversation or letting my emotions even have a place in the business I'm building? And so, for her to say, "Listen, no, that's a really important part of this journey; we need to talk about it and make space for it," is really liberating.

+ +

And I think, too, just when you think about what has happened with the pandemic and all the awareness around mental health and behavioral health, and making sure that we're making time for managing emotions has been more important than ever. We see the research that if you don't manage those emotions, they're going to manage you. So, find a productive way to do it. Work with your team and find support in a way that works for you or a productive way to just kind of get some stress out without having to just internalize everything because that never works out.

+ +

So, it's been really great to have her be able to bring that as part of our conversation and our project plan and make sure that it's a relevant piece.

+ +

LINDSEY: Very well said. And I'm so glad you did bring up that point about being women founders, and, you know, having more of a, you know, an uphill battle and feeling that emotions are a sign of weakness or a sign that you don't know what you're doing. We have more impostor syndrome because of these outside factors like lack of funding, you know, lack of support. So, it's really great for you to share that and hopefully inspire others. In fact, we got a comment: "Ashley, your drive and ambition to solve a huge issue in our country is so inspiring." Thank you --

+ +

ASHLEY: Oh, thank you.

+ +

LINDSEY: For adding that comment, folks who are following along. So, it sounds like, for you, the emotion mapping is a positive experience, where it's helping you kind of ground yourself as, even these early days, some assumptions are being challenged, or you're seeing some challenges in the business idea.

+ +

ASHLEY: Oh yeah, absolutely. Circling back to the thoughtbot team, couldn't do this without them in a really tactical and effective way. Because they have the experience and the skills that I don't have, and us working together on this same problem has been incredible.

+ +

LINDSEY: How did you come to get connected with the incubator and thoughtbot and submitting that application?

+ +

ASHLEY: Yeah. So, I'm part of the Harvard Innovation Lab, which is the innovation program at Harvard for all the students. And somebody was talking about this incubator program, and there are a lot of incubator programs out there. And so, initially, I thought, oh okay, well, this will be just, like, all the others and probably not what I'm looking for. But I did some research and looked at the website and read more about the program and thought, oh my gosh, this is exactly what I've been looking for and didn't know existed because it is that one-on-one support, and most incubator or accelerator programs you're one of many companies going through the process.

+ +

And so, the feedback I have from others who have gone through similar paths is it's great, and it's nice to have a cohort. But at the same time, you're largely figuring things out for yourself, which I was doing anyway. So, I was like, well, what value is that going to bring? This is a one-on-one experience. There's a team dedicated to working on this solution, problem, et cetera with me.

+ +

And I'm just so thankful that there are software developers and designers that are interested in helping me tackle this challenge also. So, that was really exciting to have other people also excited about the same problem but able to bring different skill sets to the table to actually bring this to life.

+ +

LINDSEY: Oh, that's great. Thanks for sharing. All right, so nearing the end of our chat here. Jordyn, what is next? I think we're going to check back in in a couple of weeks. What might those weeks include?

+ +

JORDYN: Well, as I mentioned, we really began customer interviewing...I say customer, and this is really...often, it means a lot of things. It means interviewing people who might be users, people who might be customers, people who might be partners in what we're building. And we are just going to learn so much so quickly. We're going to invalidate a lot of things. We're going to come up with new ideas. So like, we will be different humans with a different perspective on the world in two weeks, which is really exciting.

+ +

But really, so this effort is really about learning how to have your audience lead you. And it isn't about just listening to your audience. So, when they say like, "Make the button blue," you're like, "Okay, blue button, you got it." It's like actually hearing about their lives and their pain points and then innovating. They're not software developers, your audience typically, so they aren't solving this problem themselves. It's up to you to translate what you're hearing into something innovative.

+ +

I think a standard metaphor here or example–I guess it's more like a case study—is, like, the famous Ford quote that, like, if he had pulled people and asked them what they wanted, they would have said faster horses, not a car, right? So, it's like, you got to look at the landscape, look at what's possible, maybe new things are possible technically, right? And so, we can solve this problem better, a problem that we know humans have, which is paying for college, or, in Ford's case, getting from point A to point B quickly.

+ +

So, it's really our job to listen and let what we're hearing from the audience be our guide, but not just, like, sort of take dictation, right? And that's where the skill and having done this lots of times comes in. So, that's what we're going to be doing in the next two weeks. We're going to be listening very closely, iterating on the questions that we're asking and who we're asking them to. And out of that will emerge the strategically sound innovation path, and it never fails to work. I cannot stress enough that if you talk to [laughs] people and you listen to them, opportunities become very clear.

+ +

So, if any of you out there are nursing an idea that you've been nursing for a while, and you're like, I'm not ready to talk to people about it; I need to think about it longer, nope. Talk to people about it today, please. Will you screw that conversation up? Yep. But the sooner you have it, the sooner you'll screw it up and learn from it. The longer you wait, the more your assumptions build, and then it gets very tense and very wrong. And you could really think yourself off into, like, a very weird place.

+ +

So, I encourage you all to do your research; talk to people about what you're thinking, what you're working on, the people for whom it matters. And that is what we are going to be doing for the next two weeks, and then is what Ashley is going to be doing for the rest of the life of this company because you never stop. It's not a thing. You don't do, like, a customer research sprint, and then you stop. If you stop doing that, you stop innovating, and then other people in the market overtake you. Sorry, I feel passionate about this issue [laughs].

+ +

LINDSEY: No, that's good. That's a quick pitch at the end here for everyone to apply to the next session incubator. Start getting the idea and the research you've been doing together. This could be you. So, hope you'll join us again in two weeks as we catch up. And yeah, as Jordyn said, things are going to be...there'll be so many insights in that amount of time. I almost started laughing after I asked, like, what will happen in two weeks? Because I know it's going to be so different, you know, day to day you all are doing so much work, learning so much. So, I'm really excited to learn about that.

+ +

So, stay tuned with us here in two weeks. We'll also be posting updates to the thoughtbot blog: thoughtbot.com/blog. And just really looking forward to following along with your journey, Ashley. Thank you so much for joining and sharing today.

+ +

ASHLEY: Yeah, thank you for having me.

+ +

LINDSEY: Jordyn, thank you as always.

+ +

JORDYN: Of course.

+ +

LINDSEY: And thank you, audience. Everyone have a fantastic day.

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble and Jordyn Bonds.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lindsey Christensen is back as the Marketing Lead at thoughtbot! She's joined by guests Jordyn Bonds, the Director of Product Strategy at thoughtbot, and Ashley Sheble, a founder currently participating in thoughtbot's eight-week startup incubator, to discuss the multifaceted journey of entrepreneurship.

+ +

thoughtbot's Incubator Program aims to help founders like Ashley turn an idea into a viable product. They're currently at the stage of validating assumptions about the problem space and target market. Jordyn introduces a new concept: a project roadmap visualization that includes an "emotions workstream." This is designed to help founders anticipate and navigate the emotional rollercoaster often associated with the early stages of startup development.

+ +

Ashley finds the roadmap valuable, especially as it challenges her to examine her ideas from multiple perspectives. She appreciates the one-on-one support from the Incubator team, which complements her own expertise. She also speaks to the liberating aspect of acknowledging emotions in the startup journey, which is especially pertinent for female founders who often face additional challenges like lack of funding.

+ +

Jordyn emphasizes the importance of early and continuous customer engagement for product validation and innovation. She encourages aspiring entrepreneurs to talk to potential customers as soon as possible to iterate and learn from these interactions. Jordan and Ashley stress that embracing the logical and emotional aspects of entrepreneurship leads to more effective and grounded decision-making.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: All right, we are live. So, thank you for joining us today. So, we've got a new founder that's going through thoughtbot's startup incubator. And we're going to be checking in with her as she goes through the program, learning what she learns, learning about the process.

+ +

Quick reminder: thoughtbot is a development and design company. We help founders and existing companies create, launch, and improve amazing products and their teams. And one way we do that is through our startup incubator. The incubator is an eight-week program. And our second session just kicked off, which we're going to be talking about a whole lot today.

+ +

So, I'm excited to introduce you to the founder that's going through that process, as well as our fearless leader of the incubator program, Jordyn, I myself, Lindsey Christensen. I'm the Marketing Lead here at thoughtbot. I'll be asking lots of questions. But if you also have questions, please enter them in the chat, and we'll get to those as well. Before we get to Ashley, I'm going to start off with Jordyn. For those who may not be familiar with you, can you tell us who you are and what you're doing?

+ +

JORDYN: I am Jordyn Bonds. And I am the Director of Product Strategy on thoughtbot's, Ignite team, which is the team that is kind of experimenting with this incubator, shall we say. And I am a two-time startup founder myself. I've worked at other early-stage startups as initial head of product. Long ago, I spent ten years as a software engineer. So, that's my distant background. And I live in Boston.

+ +

LINDSEY: Oh, we got our first comment. Someone says, "Thanks for sharing your experience." Thank you. Welcome. Love that. Keep the comments and questions coming.

+ +

Okay. And now for our latest guest of honor. Ashley, can you introduce yourself to the audience? A little bit about you and maybe even about your journey to bring you here today.

+ +

ASHLEY: Yeah, absolutely. So, hi, everybody. My name is Ashley Sheble. I'm currently based in Houston, Texas. I have about 15 years of experience in sales and operations roles. And I have two kids. I've got one who started third grade yesterday and one who started her senior year of high school yesterday, which is crazy. Time really flies by.

+ +

But the reason why that's relevant for this conversation is because I have attended so many college tours over the past few years and started learning about just how expensive higher education has become. I had no idea that a public four-year in-state school could cost $100,000 plus for just four years. And then, you start looking at out-of-state and private schools, and that number doubles, which is crazy to me.

+ +

So, after I got through that initial sticker shock, I was like, how is this possible? Like, now I understand why the student debt crisis is happening. And became really passionate about learning more about it and trying to figure out ways that I could help. Because obviously, the solutions and tools we have today to help people prepare for the education they or their children or family members need or want just aren't working. So, became really excited about that and working with thoughtbot as their second founder to explore this further.

+ +

LINDSEY: Amazing. So, Ashley, fighting the good fight. Student debt, I know, a topic near and dear to many people who are dealing with this. You mentioned your kid's journey to college is what started the idea. Let's dig into that a little bit more. How are you approaching the challenge, the problems that you see? Or maybe, like, how long it's been that you've been kind of playing around with this idea.

+ +

ASHLEY: Yeah, absolutely. So, I'm in a graduate school program and have used this as an opportunity to really explore different ways to attack problems. I became really interested in innovation and entrepreneurship at grad school and began just doing research, learning about ways to solve really big, complex problems, and found that technology could really be an interesting way to approach the student debt problem differently than what's been done before.

+ +

It's an industry that has largely lacked innovation, and have been working with professors and experts just to think about ways to apply technology to this really complicated problem to provide a more simple solution for people who just want to pay for school.

+ +

LINDSEY: And this is your first time being a founder. Is that right?

+ +

ASHLEY: It is. So, thank goodness for thoughtbot being my partner here because I'm not a technical person, meaning I don't develop software. I'm not a software designer, and knew that that was going to be a critical piece of developing a solution. And so, I'm grateful for the opportunity to work with Jordyn and her team.

+ +

LINDSEY: Have you, like, always thought you would, at some point, start your own thing? You know, have you always been entrepreneurial?

+ +

ASHLEY: Yeah, I think so. I can tell you my first business started in third grade. I launched my babysitting venture and marketed my services all over the neighborhood and church, and wherever would allow me to hang up a flyer, and had a pretty steady book of business, if you will. And in hindsight, I really cannot believe that parents allowed a 10-year-old to babysit their kids. You know, maybe in the '90s there were fewer questions–definitely less legal restrictions around age.

+ +

LINDSEY: The '90s were wild.

+ +

ASHLEY: The '90s were wild, yeah. Maybe I just seemed mature and responsible. I don't know. I don't know.

+ +

LINDSEY: Amazing. All right. Jordyn, so Ashley submitted for the thoughtbot incubator. What stood out to you in that application? And why did she seem like, you know, the right fit to go through the program?

+ +

JORDYN: Yeah, Ashley's application was just totally...it had that combination of prepared, done her homework, done the work to present the story well, but also clearly had a passion and a connection to the problem space. It wasn't just, like, a purely academic exercise for her, and just came prepared–really gave thoughtful answers in the application. There's a number of interviews that happened during the application process. She showed up with bells on and asked really good questions, which is something we always look for from founders as well. And she just knocked it out of the park.

+ +

ASHLEY: Thank you.

+ +

LINDSEY: And why was maybe where she is in her business or product journey a good fit for the incubator?

+ +

JORDYN: Great question. So, we sit at a really special moment, which is usually founders are coming to us, well, hopefully, founders are coming to us pre-product. So, they have not built a thing yet. They're basically at that moment where they've identified an opportunity. They've given it lots of thought, done a ton of research, maybe started talking to people about it.

+ +

But they're not sure how to take an idea, an opportunity, and what happens between that moment and innovation, actually a plan for a product, a strategic plan for product, and the ability to execute on that. There's a big gap there in understanding, especially for first-time founders. It certainly was a gap for me as a [laughs] first-time founder. That's the ideal candidate for us.

+ +

That said, we do have folks coming to the incubator who are interested in executing, like, a strategic pivot. Maybe they've found that the first thing they did was just, like, a market flop, and they basically want to do the programming. They're sort of starting over. Maybe they have a little bit...they're basically like, "Hey, we disqualified one idea. [laughs] We would like to come up with some other options." Those folks are also a good fit. And that is exactly the moment that Ashley is at. She's done a lot of great research so far–has a really interesting idea, interesting take on an interesting problem, but could really benefit from the programming of turning that into technical innovation.

+ +

LINDSEY: Which leads me back to you, Ashley. Can you tell us a little bit about your pre-thoughtbot research, like, both, like, how you approached it and maybe even some things that you learned that have helped you with your early direction?

+ +

ASHLEY: Yeah, absolutely. So, initially, just did a lot of industry research, just general population research, and then became a little bit more focused on solving problems for families in the U.S. right now. So, narrowing down that market scope.

+ +

And then, our focus right now is drilling into: how can we serve parents, students at each phase of their journey as parents or students, making sure that we are adding value as we're creating a service to help attack saving for college in a really effective way that is easy to do and is also going to help somebody be financially prepared to pay for a really expensive price tag without having to rely on student loans?

+ +

And so, we're doing a lot of focused research right now, building on what I did in grad school with professors and mentors and experts there, but being more focused and intentional around understanding each phase of the customer journey. So, whether you're a new parent, maybe a parent of kids that are a little older, or a parent of kids that are about to go to college or in college, how are we providing value at each stage of that journey? And so, we're really focusing in with customer interviews, understanding the pain points, and understanding what value is lacking as we think about building something that people want and like to use.

+ +

LINDSEY: In that early research, is there anything you learned or, like, positive signals you got as you were talking to people where it gave you a motivation to keep going, like, there is a good idea here to follow?

+ +

ASHLEY: Yeah, there have been some ideas that we're finding are just absolutely terrible, and they're just not going to work, which is good to know now before we spend a lot of time chasing something that's not going to be helpful. And also really finding some interesting patterns among conversations. We're digging in a little more where, initially, we thought, oh, nobody cares about that, or, oh, that's not a big deal. That's not a pain point, but actually, it is.

+ +

So, Jordyn, with her experience as a founder in prior experiences she's been able to use what she learned that maybe went well or didn't go as well as she had hoped and apply that learning to what we're doing together on this particular project. And so, that's super valuable, helps me avoid some rookie mistakes, and definitely prevents us from wasting a lot of time and resources that probably would have been wasted otherwise.

+ +

LINDSEY: Jordyn, can you tell me a little bit more about the kickoff, where we are? Because this is early, early days, where, you know, maybe a week in. You know, what does that initial kickoff with the founder look like? What are you doing?

+ +

JORDYN: Yeah. So, the first few days are really spent...we as a team on the thoughtbot side need to get to the place where we know everything the founder knows to date. So, it's very intense, a lot of, like, resource sharing, research sharing, conversations, a lot of elliptical conversations where Ashley will tell us something, we'll all go off and do some digging and some research, and come back and be like, ask her some questions, where she's like, [laughs] "If you recall, I said that to you," you know.

+ +

But, basically, it's one of those sort of processes where you don't know what you don't know. You start to understand. You come back, you ask questions, you dig. And the process is really about figuring out: where are the holes? So, Ashley has done a ton of really great work. She is but one person who has had divided attention. So, there are some places where we have some assumptions, all of us as individuals, and Ashley, specifically as a founder, has some assumptions about this problem space that we haven't validated yet. We haven't validated or invalidated. That's really what we're looking for.

+ +

It's like, is this hunch correct, incorrect? How do we know? So, we're really in those first few days are listening for those assumptions, for those untested assumptions. There's a ton of stuff in there where she's just like, I know the answer to this already. Here's what I know, and here's how I know it. Great, cool, validated, got it. But there's this other set of things that really then becomes the focus of the subsequent weeks of work.

+ +

And often, we find what those assumptions center around are early adopter market characteristics. There's the big vision, right? Which we don't doubt. Basically like, we do not disagree that paying for college is a huge problem. The student debt crisis is huge. There's a million ways to go about addressing that problem. How are we going to, from where we are right now, lay a pathway where we build value upon value? We find something valuable to give the market where it is right now, where we are right now, and then we build from that.

+ +

And so, you know, there's assumptions about who needs this, who wants this, who's struggling to pay for college, who's having no problem at all paying for college. But what we're trying to do is sort of zoom in on that group of folks, very tiny, specific group of folks who are having this problem the most acutely in a way that we are best situated to address. That's the magic we're trying to do.

+ +

So, it's really those early days are about listening to what Ashley knows, going out into the market, doing some research, follow-up research, but then really trying to come up with an early adopter hypothesis. And then immediately, as quickly as possible, interviewing as many of those people as we can so that we can validate or invalidate the assumptions we have about them. So, that's really the phase that we just started. Like, today and yesterday, we just started interviewing.

+ +

We have our first sort of hypothesis about...Ashley mentioned the journey of, like, beginning of child's life. Maybe, as a parent, I have aspirations for this child to go to college. Where do I start saving? You know, that end of the journey all the way to I am actively paying for a college education right now. Where in that journey are the pain points? And can we focus specifically on a particular group of people at a particular moment in that journey in order to provide maximum value right now and then expand from there?

+ +

So, we're doing a bunch of interviewing. I had a customer persona interview right before coming to this. You immediately start learning. There's just no substitute for it. The thing I tell founders constantly and I just sound like an absolute broken record, but you got to talk to people. You got to start talking to them now. You got to keep talking to them. You got to think hard and creatively about what you're hearing and who they are. And that's really the work that we're doing together right now.

+ +

LINDSEY: Exciting. [crosstalk 15:04] Ashley, I was going to say how is this kickoff then for you?

+ +

ASHLEY: Really good. One thing Lindsey and team have brought to the table, especially thinking about me working as a solo founder, is just around the fact that everybody has different perspectives. And we all have different expertise and different experiences that we're bringing to the table. So, the way that I've been thinking about a problem could be 180 from the way Jordyn's thinking about it or some other folks on our team.

+ +

And it's really interesting to have to really test a lot of these assumptions. I'm like, oh yeah, everybody thinks this way. Oh yeah, everybody does this. And it turns out I'm the only one, or maybe only a couple of us in the group are aligning with that perspective. And so, it has been so valuable as a solo founder to have a team of people researching the same problem from a different perspective. So, I just wanted to add that.

+ +

LINDSEY: No, that's a great one. And that is sometimes challenging, I think, for the founders. I don't know if you're finding this when you're just getting started. But as you go through the process, things that you have maybe held to be true or facts you end up finding out are assumptions, or maybe assumptions that are false. Which also reminds me of Jordyn: you were telling me something very interesting that you're doing during this incubator, which is founder emotions mapping.

+ +

JORDYN: [laughs] Yeah.

+ +

LINDSEY: What is this?

+ +

JORDYN: Yeah, we've got this project roadmap visualization. It's a Gantt chart. Y'all, it is a Gantt chart. And it basically just lays out, broadly speaking, what we're going to do together on what timeline. It helps us, together, visualize where we're going, where we are, and what we need to do in between so that we don't lose sight of that.

+ +

And this time, it was the first time that we added...we had this sort of insight that we should add an emotions workstream [laughs] because so much of the early stage is just an emotional rollercoaster because you are learning so much so fast. And if you're lucky and you immediately go into innovation, delivery, learning more, scaling, right? It's this very fast loop. And it's not just that you're learning stuff about your market really quickly. You're learning stuff about yourself and about the work. The learning curve is just really steep.

+ +

And we had realized that you end up going through this cycle of emotions that's pretty predictable [chuckles], and that's great, right? We want founders to know that their emotions...not only are their emotions, like, totally valid, we wanted to welcome them in a little bit more than we have in the past.

+ +

So, we added this little emotions work stream that was basically just like, hey, first week, first few days of kickoff, you're going to feel like a million bucks. You're like, yes, I know some stuff. I finally got a team working on this with me. To the moon, right? Like, you got this, like, very optimistic, exuberant kind [laughs] of attitude.

+ +

Immediately, you start hearing perspectives you hadn't heard before in your problem space. You start uncovering contrary evidence. We start talking to people. Immediately, you start to learn things that you didn't know you didn't know, right? So, up until this moment, you've just had some blinders on, and you're like, the path is clear, and it is amazing. I'm just going to motor my way to success.

+ +

And our process is about really taking those blinders off and figuring out what is actually around me on this road? Are there words of attackers coming at me from the sides? Like, I need to know those things, right? But what happens is you start to know what you don't know. And so, there's this dip. You start off very optimistic, and then you have a week or two of declining mood where you're mortified. You learn that you had some assumptions that are not valid. There's some other risks and things lying out there in the market. It's truly mortifying.

+ +

Maybe you learn about a competitor you didn't know about because you just weren't searching the right words, or whatever it is, right? That moment a lot of founders are just like, the moment I discovered my first real competitor, and I had, like, a panic attack, right? That happened to me.

+ +

But then you start to make a plan around those things, okay, cool. Like, maybe we need to differentiate ourselves. Maybe there is some more information we need to figure out about how to go after this, et cetera. And you start that slow climb of dealing with the new information that you have, right? And filling in those gaps [inaudible 19:22].

+ +

Then you start to climb out of the hole, right? You're like, okay, we got a plan. I got a team. We're doing the work. Awesome. You learn new, really exciting things. And then you end up back on that, like, high where you're like, this is so awesome. We have the best idea. And now we know everything there is to know. But no, no, you've just reached a new plateau [laughs]. And there are more things to be learned and more things...So, it's this really predictable cycle, and that's fine. That's good. You wouldn't be here if you didn't care about the problem space, right? If you weren't passionate about it.

+ +

And so, we really wanted to actually call that out this time and make space for it and put it on the map. Hey, we might be feeling this way right now, just heads up. That's okay. We're going to be feeling really great in a week. And then, the week after that, we're going to be feeling [laughs] like garbage again. It's okay. Because knowing that really makes you feel.

+ +

And it took me a long time as a first-time founder to realize that, like, my moment-to-moment emotional experience is...I need to make space for it. It is what it is. But it is not the story of my business. And it's a thing you just kind of have to learn after going through a bunch of those cycles. But, like, part of what we're trying to do with the incubator is help founders not fall in those potholes, not make the rookie mistakes, as Ashley put it.

+ +

And one of those rookie mistakes is thinking that the first time you identify a direct competitor, everything that you've been working toward for the last year is useless, and you should quit, and everyone thinks you're a fool, and, like, whatever crazy narrative you [laughs] have going on in your mind [laughs]. We're kind of here to be like, it's okay. This is to be expected: onward and upward. The hard work continues.

+ +

So yeah, it's very fun. At some point, we will publish a little version of this visualization with our little cycle of feelings on the bottom. But it reminds us to make space for them in the conversation when we are doing those check-ins. Like, here we are on this roadmap, and here's where our feelings may or may not be.

+ +

ASHLEY: Her recap for day one is spot on. I left that conversation; I walked out of my office and told my husband, I said, "Listen, we're going to solve the student debt crisis. We're going to." And he was like, "Really? Okay." And I was like, "Yeah, we are." And then, like, two days later, I was like, "No, we are not going to be effective at this." And then, the next day, I was like, "No, I fixed it. We fixed it. It's fine." So, being able to reference that chart is really helpful and validating for me as a person to be like: I should be feeling like this; yes, I do. Perfect, you know, I'm right on track.

+ +

And I think, too, as a founder, and especially as a female founder, you are expected to just keep it together. Maybe that's a self-imposed belief. But when you think about the fact that female CEOs only have about 2% of the venture capital funding, it's like, you know, why would I ever raise a red flag for myself by letting my emotions be part of the conversation or letting my emotions even have a place in the business I'm building? And so, for her to say, "Listen, no, that's a really important part of this journey; we need to talk about it and make space for it," is really liberating.

+ +

And I think, too, just when you think about what has happened with the pandemic and all the awareness around mental health and behavioral health, and making sure that we're making time for managing emotions has been more important than ever. We see the research that if you don't manage those emotions, they're going to manage you. So, find a productive way to do it. Work with your team and find support in a way that works for you or a productive way to just kind of get some stress out without having to just internalize everything because that never works out.

+ +

So, it's been really great to have her be able to bring that as part of our conversation and our project plan and make sure that it's a relevant piece.

+ +

LINDSEY: Very well said. And I'm so glad you did bring up that point about being women founders, and, you know, having more of a, you know, an uphill battle and feeling that emotions are a sign of weakness or a sign that you don't know what you're doing. We have more impostor syndrome because of these outside factors like lack of funding, you know, lack of support. So, it's really great for you to share that and hopefully inspire others. In fact, we got a comment: "Ashley, your drive and ambition to solve a huge issue in our country is so inspiring." Thank you --

+ +

ASHLEY: Oh, thank you.

+ +

LINDSEY: For adding that comment, folks who are following along. So, it sounds like, for you, the emotion mapping is a positive experience, where it's helping you kind of ground yourself as, even these early days, some assumptions are being challenged, or you're seeing some challenges in the business idea.

+ +

ASHLEY: Oh yeah, absolutely. Circling back to the thoughtbot team, couldn't do this without them in a really tactical and effective way. Because they have the experience and the skills that I don't have, and us working together on this same problem has been incredible.

+ +

LINDSEY: How did you come to get connected with the incubator and thoughtbot and submitting that application?

+ +

ASHLEY: Yeah. So, I'm part of the Harvard Innovation Lab, which is the innovation program at Harvard for all the students. And somebody was talking about this incubator program, and there are a lot of incubator programs out there. And so, initially, I thought, oh okay, well, this will be just, like, all the others and probably not what I'm looking for. But I did some research and looked at the website and read more about the program and thought, oh my gosh, this is exactly what I've been looking for and didn't know existed because it is that one-on-one support, and most incubator or accelerator programs you're one of many companies going through the process.

+ +

And so, the feedback I have from others who have gone through similar paths is it's great, and it's nice to have a cohort. But at the same time, you're largely figuring things out for yourself, which I was doing anyway. So, I was like, well, what value is that going to bring? This is a one-on-one experience. There's a team dedicated to working on this solution, problem, et cetera with me.

+ +

And I'm just so thankful that there are software developers and designers that are interested in helping me tackle this challenge also. So, that was really exciting to have other people also excited about the same problem but able to bring different skill sets to the table to actually bring this to life.

+ +

LINDSEY: Oh, that's great. Thanks for sharing. All right, so nearing the end of our chat here. Jordyn, what is next? I think we're going to check back in in a couple of weeks. What might those weeks include?

+ +

JORDYN: Well, as I mentioned, we really began customer interviewing...I say customer, and this is really...often, it means a lot of things. It means interviewing people who might be users, people who might be customers, people who might be partners in what we're building. And we are just going to learn so much so quickly. We're going to invalidate a lot of things. We're going to come up with new ideas. So like, we will be different humans with a different perspective on the world in two weeks, which is really exciting.

+ +

But really, so this effort is really about learning how to have your audience lead you. And it isn't about just listening to your audience. So, when they say like, "Make the button blue," you're like, "Okay, blue button, you got it." It's like actually hearing about their lives and their pain points and then innovating. They're not software developers, your audience typically, so they aren't solving this problem themselves. It's up to you to translate what you're hearing into something innovative.

+ +

I think a standard metaphor here or example–I guess it's more like a case study—is, like, the famous Ford quote that, like, if he had pulled people and asked them what they wanted, they would have said faster horses, not a car, right? So, it's like, you got to look at the landscape, look at what's possible, maybe new things are possible technically, right? And so, we can solve this problem better, a problem that we know humans have, which is paying for college, or, in Ford's case, getting from point A to point B quickly.

+ +

So, it's really our job to listen and let what we're hearing from the audience be our guide, but not just, like, sort of take dictation, right? And that's where the skill and having done this lots of times comes in. So, that's what we're going to be doing in the next two weeks. We're going to be listening very closely, iterating on the questions that we're asking and who we're asking them to. And out of that will emerge the strategically sound innovation path, and it never fails to work. I cannot stress enough that if you talk to [laughs] people and you listen to them, opportunities become very clear.

+ +

So, if any of you out there are nursing an idea that you've been nursing for a while, and you're like, I'm not ready to talk to people about it; I need to think about it longer, nope. Talk to people about it today, please. Will you screw that conversation up? Yep. But the sooner you have it, the sooner you'll screw it up and learn from it. The longer you wait, the more your assumptions build, and then it gets very tense and very wrong. And you could really think yourself off into, like, a very weird place.

+ +

So, I encourage you all to do your research; talk to people about what you're thinking, what you're working on, the people for whom it matters. And that is what we are going to be doing for the next two weeks, and then is what Ashley is going to be doing for the rest of the life of this company because you never stop. It's not a thing. You don't do, like, a customer research sprint, and then you stop. If you stop doing that, you stop innovating, and then other people in the market overtake you. Sorry, I feel passionate about this issue [laughs].

+ +

LINDSEY: No, that's good. That's a quick pitch at the end here for everyone to apply to the next session incubator. Start getting the idea and the research you've been doing together. This could be you. So, hope you'll join us again in two weeks as we catch up. And yeah, as Jordyn said, things are going to be...there'll be so many insights in that amount of time. I almost started laughing after I asked, like, what will happen in two weeks? Because I know it's going to be so different, you know, day to day you all are doing so much work, learning so much. So, I'm really excited to learn about that.

+ +

So, stay tuned with us here in two weeks. We'll also be posting updates to the thoughtbot blog: thoughtbot.com/blog. And just really looking forward to following along with your journey, Ashley. Thank you so much for joining and sharing today.

+ +

ASHLEY: Yeah, thank you for having me.

+ +

LINDSEY: Jordyn, thank you as always.

+ +

JORDYN: Of course.

+ +

LINDSEY: And thank you, audience. Everyone have a fantastic day.

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Ashley Sheble and Jordyn Bonds.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+l6l06PVR + + ]]> + + Lindsey Christensen + Jordyn Bonds + Ashley Sheble + + + 497: Axiom with Seif Lotfy + https://podcast.thoughtbot.com/497 + 6bfba652-2dc5-4089-9cc2-c6c6020e73ab + Thu, 19 Oct 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Victoria is joined by guest co-host Joe Ferris, CTO at thoughtbot, and Seif Lotfy, the CTO and Co-Founder of Axiom. Seif discusses the journey, challenges, and strategies behind his data analytics and observability platform. + +Seif, who has a background in robotics and was a 2008 Sony AIBO robotic soccer world champion, shares that Axiom pivoted from being a Datadog competitor to focusing on logs and event data. The company even built its own logs database to provide a cost-effective solution for large-scale analytics. Seif is driven by his passion for his team and the invaluable feedback from the community, emphasizing that sales validate the effectiveness of a product. The conversation also delves into Axiom's shift in focus towards developers to address their need for better and more affordable observability tools. + +On the business front, Seif reveals the company's challenges in scaling across multiple domains without compromising its core offerings. He discusses the importance of internal values like moving with urgency and high velocity to guide the company's future. Furthermore, he touches on the challenges and strategies of open-sourcing projects and advises avoiding platforms like Reddit and Hacker News to maintain focus. + 39:13 + no + + + Victoria is joined by guest co-host Joe Ferris, CTO at thoughtbot, and Seif Lotfy, the CTO and Co-Founder of Axiom. Seif discusses the journey, challenges, and strategies behind his data analytics and observability platform. +Seif, who has a background in robotics and was a 2008 Sony AIBO robotic soccer world champion, shares that Axiom pivoted from being a Datadog competitor to focusing on logs and event data. The company even built its own logs database to provide a cost-effective solution for large-scale analytics. Seif is driven by his passion for his team and the invaluable feedback from the community, emphasizing that sales validate the effectiveness of a product. The conversation also delves into Axiom's shift in focus towards developers to address their need for better and more affordable observability tools. +On the business front, Seif reveals the company's challenges in scaling across multiple domains without compromising its core offerings. He discusses the importance of internal values like moving with urgency and high velocity to guide the company's future. Furthermore, he touches on the challenges and strategies of open-sourcing projects and advises avoiding platforms like Reddit and Hacker News to maintain focus. +Axiom (https://axiom.co/) +Follow Axiom on LinkedIn (https://www.linkedin.com/company/axiomhq/), X (https://twitter.com/AxiomFM), GitHub (https://github.com/axiomhq), or Discord (https://discord.com/invite/axiom-co). +Follow Seif Lotfy on LinkedIn (https://www.linkedin.com/in/seiflotfy/) or X (https://twitter.com/seiflotfy). Visit his website at seif.codes (https://seif.codes/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Seif Lotfy, CTO and Co-Founder of Axiom, the best home for your event data. Seif, thank you for joining me. +SEIF: Hey, everybody. Thanks for having me. This is awesome. I love the name of the podcast, given that I used to compete in robotics. +VICTORIA: What? All right, we're going to have to talk about that. And I also want to introduce a guest co-host today. Since we're talking about cloud, and observability, and data, I invited Joe Ferris, thoughtbot CTO and Director of Development of our platform engineering team, Mission Control. Welcome, Joe. How are you? +JOE: Good, thanks. Good to be back again. +VICTORIA: Okay. I am excited to talk to you all about observability. But I need to go back to Seif's comment on competing with robots. Can you tell me a little bit more about what robots you've built in the past? +SEIF: I didn't build robots; I used to program them. Remember the Sony AIBOs, where Sony made these dog robots? And we would make them compete. There was an international competition where we made them play soccer, and they had to be completely autonomous. They only communicate via Bluetooth or via wireless protocols. And you only have the camera as your sensor as well as...a chest sensor throws the ball near you, and then yeah, you make them play football against each other, four versus four with a goalkeeper and everything. Just look it up: RoboCup AIBO. Look it up on YouTube. And I...2008 world champion with the German team. +VICTORIA: That sounds incredible. What kind of crowds are you drawing out for a robot soccer match? Is that a lot of people involved with that? +SEIF: You would be surprised how big the RoboCup competition is. It's ridiculous. +VICTORIA: I want to go. I'm ready. I want to, like, I'll look it up and find out when the next one is. +SEIF: No more Sony robots but other robots. Now, there's two-legged robots. So, they make them play as two-legged robots, much slower than four-legged robots, but works. +VICTORIA: Wait. So, the robots you were playing soccer with had four legs they were running around on? +SEIF: Yeah, they were dogs [laughter]. +VICTORIA: That's awesome. +SEIF: We all get the same robot. It's just a competition on software, right? On a software level. And some other competitions within the RoboCup actually use...you build your own robot and stuff like that. But this one was...it's called the Standard League, where we all have a robot, and we have to program it. +JOE: And the standard robot was a dog. +SEIF: Yeah, I think back then...we're talking...it's been a long time. I think it started in 2001 or something. I think the competition started in 2001 or 2002. And I compete from 2006 to 2008. Robots back then were just, you know, simple. +VICTORIA: Robots today are way too complicated [laughs]. +SEIF: Even AI is more complicated. +VICTORIA: That's right. Yeah, everything has gotten a lot more complicated [laughs]. I'm so curious how you went from being a world-champion robot dog soccer player [laughs] programmer [laughs] to where you are today with Axiom. Can you tell me a little bit more about your journey? +SEIF: The journey is interesting because it came from open source. I used to do open source on the side a lot–part of the GNOME Project. That's where I met Neil and the rest of my team, Mikkel Kamstrup, the whole crowd, basically. We worked on GNOME. We worked on Ubuntu. Like, most of them were working professionally on it. I was working for another company, but we worked on the same project. +We ended up at Xamarin, which was bought by Microsoft. And then we ended up doing Axiom. But we've been around each other professionally since 2009, most of us. It's like a little family. But how we ended up exactly in observability, I think it's just trying to fix pain points in my life. +VICTORIA: Yeah, I was reading through the docs on Axiom. And there's an interesting point you make about organizations having to choose between how much data they have and how much they want to spend on it. So, maybe you can tell me a little bit more about that pain point and what you really found in the early stages that you wanted to solve. +SEIF: So, the early stages of what we wanted to solve we were mainly dealing with...so, the early, early stage, we were actually trying to be a Datadog competitor, where we were going to be self-hosted. Eventually, we focused on logs because we found out that's what was a big problem for most people, just event data, not just metric but generally event data, so logs, traces, et cetera. We built out our own logs database completely from scratch. +And one of the things we stumbled upon was; basically, you have three things when it comes to logging, which is low cost, low latency, and large scale. That's what everybody wants. But you can't get all three of them; you can only get two of them. And we opted...like, we chose large scale and low cost. And when it comes to latency, we say it should be just fast enough, right? And that's where we focused on, and this is how we started building it. And with that, this is how we managed to stand out by just having way lower cost than anybody else in the industry and dealing with large scale. +VICTORIA: That's really interesting. And how did you approach making the ingestion pipeline for masses amount of data more efficient? +SEIF: Just make it coordination-free as possible, right? And get rid of Kafka because Kafka just, you know, drains your...it's where you throw in money. Like maintaining Kafka...it's like back then Elasticsearch, right? Elasticsearch was the biggest part of your infrastructure that would cost money. Now, it's also Kafka. +So, we found a way to have our own internal way of queueing things without having to rely on Kafka. As I said, we wrote everything from scratch to make it work. Like, every now and then, I think that we can spin this out of the company and make it a new product. But now, eyes on the prize, right? +JOE: It's interesting to hear that somebody who spent so much time in the open-source community ended up rolling their own solution to so many problems. Do you feel like you had some lessons learned from open source that led you to reject solutions like Kafka, or how did that journey go? +SEIF: I don't think I'm rejecting Kafka. The problem is how Kafka is built, right? Kafka is still...you have to set up all these servers. They have to communicate, et cetera, etcetera. They didn't build it in a way where it's stateless, and that's what we're trying to go to. We're trying to make things as stateless as possible. So, Kafka was never built for the cloud-native era. And you can't really rely on SQS or something like that because it won't deal with this high throughput. +So, that's why I said, like, we will sacrifice some latency, but at least the cost is low. So, if messages show after half a second or a second, I'm good. It doesn't have to be real-time for me. So, I had to write a couple of these things. But also, it doesn't mean that we reject open source. Like, we actually do like open source. We open-source a couple of libraries. We contribute back to open source, right? We needed a solution back then for that problem, and we couldn't find any. And maybe one day, open source will have, right? +JOE: Yeah. I was going to ask if you considered open-sourcing any of your high latency, high throughput solutions. +SEIF: Not high latency. You make it sound bad. +JOE: [laughs] +SEIF: You make it sound bad. It's, like, fast enough, right? I'm not going to compete on milliseconds because, also, I'm competing with ClickHouse. I don't want to compete with ClickHouse. ClickHouse is low latency and large scale, right? But then the cost is, you know, off the charts a bit sometimes. +I'm going the other route. Like, you know, it's fast enough. Like, how, you know, if it's under two, three seconds, everybody's happy, right? If the results come within two, three seconds, everybody is happy. If you're going to build a real-time trading system on top of it, I'll strongly advise against that. But if you're building, you know, you're looking at dashboards, you're more in the observability field, yeah, we're good. +VICTORIA: Yeah, I'm curious what you found, like, which customer personas that market really resonated with. Like, is there a particular, like, industry type where you're noticing they really want to lower their cost, and they're okay with this just fast enough latency? +SEIF: Honestly, with the current recession, everybody is okay with giving up some of the speed to reduce the money because I think it's not linear reduction. It's more exponential reduction at this point, right? You give up a second, and you're saving 30%. You give up two seconds, all of a sudden, you're saving 80%. +So, I'd say in the beginning, everybody thought they need everything to be very, very fast. And now they're realizing, you know, with limitations you have around your budget and spending, you're like, okay, I'm okay with the speed. And, again, we're not slow. I'm just saying people realize they don't need everything under a second. They're okay with waiting for two seconds. +VICTORIA: That totally resonates with me. And I'm curious if you can add maybe a non-technical or a real-life example of, like, how this impacts the operations of a company or organization, like, if you can give us, like, a business-y example of how this impacts how people work. +SEIF: I don't know how, like, how do people work on that? Nothing changed, really. They're still doing the, like...really nothing because...and that aspect is you run a query, and, again, as I said, you're not getting the result in a second. You're just waiting two seconds or three seconds, and it's there. So, nothing really changed. I think people can wait three seconds. And we're still like–when I say this, we're still faster than most others. We're just not as fast as people who are trying to compete on a millisecond level. +VICTORIA: Yeah, that's okay. Maybe I'll take it back even, like, a step further, right? Like, our audience is really sometimes just founders who almost have no formal technical training or background. So, when we talk about observability, sometimes people who work in DevOps and operations all understand it and kind of know why it's important [laughs] and what we're talking about. So, maybe you could, like, go back to -- +SEIF: Oh, if you're asking about new types of people who've been using it -- +VICTORIA: Yeah. Like, if you're going to explain to, like, a non-technical founder, like, why your product is important, or, like, how people in their organization might use it, what would you say? +SEIF: Oh, okay, if you put it like that. It's more of if you have data, timestamp data, and you want to run analytics on top of it, so that could be transactions, that could be web vitals, rather than count every time somebody visits, you have a timestamp. So, you can count, like, how many visitors visited the website and what, you know, all these kinds of things. That's where you want to use something like Axiom. That's outside the DevOps space, of course. And in DevOps space, there's so many other things you use Axiom for, but that's outside the DevOps space. +And we actually...we implemented as zero-config integration with Vercel that kind of went viral. And we were, for a while, the number one enterprise for self-integration because so many people were using it. So, Vercel users are usually not necessarily writing the most complex backends, but a lot of things are happening on the front-end side of things. And we would be giving them dashboards, automated dashboards about, you know, latencies, and how long a request took, and how long the response took, and the content type, and the status codes, et cetera, et cetera. And there's a huge user base around that. +VICTORIA: I like that. And it's something, for me, you know, as a managing director of our platform engineering team, I want to talk more to founders about. It's great that you put this product and this app out into the world. But how do you know that people are actually using it? How do you know that people, like, maybe, are they all quitting after the first day and not coming back to your app? Or maybe, like, the page isn't loading or, like, it's not working as they expected it to. +And, like, if you don't have anything observing what users are doing in your app, then it's going to be hard to show that you're getting any traction and know where you need to go in and make corrections and adjust. +SEIF: We have two ways of doing this. Right now, internally, we use our own tools to see, like, who is sending us data. We have a deployment that's monitoring production deployment. And we're just, you know, seeing how people are using it, how much data they're sending every day, who stopped sending data, who spiked in sending data sets, et cetera. +But we're using Mixpanel, and Dominic, our Head of Product, implemented a couple of key metrics to that for that specifically. So, we know, like, what's the average time until somebody starts going from building its own queries with the builder to writing APL, or how long it takes them from, you know, running two queries to five queries. And, you know, we just start measuring these things now. And it's been going...we've been growing healthy around that. +So, we tend to measure user interaction, but also, we tend to measure how much data is being sent. Because let's keep in mind, usually, people go in and check for things if there's a problem. So, if there's no problem, the user won't interact with us much unless there's a notification that kicks off. We also just check, like, how much data is being sent to us the whole time. +VICTORIA: That makes sense. Like, you can't just rely on, like, well, if it was broken, they would write a [chuckles], like, a question or something. So, how do you get those metrics and that data around their interactions? So, that's really interesting. So, I wonder if we can go back and talk about, you know, we already mentioned a little bit about, like, the early days of Axiom and how you got started. Was there anything that you found in the early discovery process that was surprising and made you pivot strategy? +SEIF: A couple of things. Basically, people don't really care about the tech as much as they care [inaudible 12:51] and the packaging, so that's something that we had to learn. And number two, continuous feedback. Continuous feedback changed the way we worked completely, right? And, you know, after that, we had a Slack channel, then we opened a Discord channel. And, like, this continuous feedback coming in just helps with iterating, helps us with prioritizing, et cetera. And that changed the way we actually developed product. +VICTORIA: You use Slack and Discord? +SEIF: No. No Slack anymore. We had a community Slack. We had a community [inaudible 13:19] Slack. Now, there's no community Slack. We only have a community Discord. And the community Slack is...sorry, internally, we use Slack, but there's a community Discord for the community. +JOE: But how do you keep that staffed? Is it, like, everybody is in the Discord during working hours? Is it somebody's job to watch out for community questions? +SEIF: I think everybody gets involved now just...and you can see it. If you go on our Discord, you will just see it. Just everyone just gets involved. I think just people are passionate about what they're doing. At least most people are involved on Discord, right? Because there's, like, Discord the help sections, and people are just asking questions and other people answering. +And now, we reached a point where people in the community start answering the questions for other people in the community. So, that's how we see it's starting to become a healthy community, et cetera. But that is one of my favorite things: when I see somebody from the community answering somebody else, that's a highlight for me. Actually, we hired somebody from that community because they were so active. +JOE: Yeah, I think one of the biggest signs that a product is healthy is when there's a healthy ecosystem building up around it. +SEIF: Yeah, and Discord reminds me of the old days of open sources like IRC, just with memes now. But because all of us come from the old IRC days, being on Discord and chatting around, et cetera, et cetera, just gives us this momentum back, gave us this momentum back, whereas Slack always felt a bit too businessy to me. +JOE: Slack is like IRC with emoji. Discord is IRC with memes. +SEIF: I would say Slack reminds me somehow of MSN Messenger, right? +JOE: I feel like there's a huge slam on MSN Messenger here. +SEIF: [laughs] What do you guys use internally, Slack or? I think you're using Slack, right? Or Teams. Don't tell me you're using Teams. +JOE: No, we're using Slack. +SEIF: Okay, good, because I shit talk. Like, there is this, I’ll sh*t talk here–when I start talking about Teams, so...I remember that one thing Google did once, and that failed miserably. +JOE: Google still has, like, seven active chat products. +SEIF: Like, I think every department or every, like, group of engineers just uses one of them internally. I'm not sure. Never got to that point. But hey, who am I to judge? +VICTORIA: I just feel like I end up using all of them, and then I'm just rotating between different tabs all day long. You maybe talked me into using Discord. I feel like I've been resisting it, but you got me with the memes. +SEIF: Yeah, it's definitely worth it. It's more entertaining. More noise, but more entertaining. You feel it's alive, whereas Slack is...also because there's no, like, history is forever. So, you always go back, and you're like, oh my God, what the hell is this? +VICTORIA: Yeah, I have, like, all of them. I'll do anything. +SEIF: They should be using Axiom in the background. Just send data to Axiom; we can keep your chat history. +VICTORIA: Yeah, maybe. I'm so curious because, you know, you mentioned something about how you realized that it didn't matter really how cool the tech was if the product packaging wasn't also appealing to people. Because you seem really excited about what you've built. So, I'm curious, so just tell us a little bit more about how you went about trying to, like, promote this thing you built. Or was, like, the continuous feedback really early on, or how did that all kind of come together? +SEIF: The continuous feedback helped us with performance, but actually getting people to sign up and pay money it started early on. But with Vercel, it kind of skyrocketed, right? And that's mostly because we went with the whole zero-config approach where it's just literally two clicks. And all of a sudden, Vercel is sending your data to Axiom, and that's it. We will create [inaudible 16:33]. +And we worked very closely with Vercel to do this, to make this happen, which was awesome. Like, yeah, hats off to them. They were fantastic. And just two clicks, three clicks away, and all of a sudden, we created Axiom organization for you, the data set for you. And then we're sending it...and the data from Vercel is being forwarded to it. I think that packaging was so simple that it made people try it out quickly. And then, the experience of actually using Axiom was sticky, so they continued using it. +And then the price was so low because we give 500 gigs for free, right? You send us 500 gigs a month of logs for free, and we don't care. And you can start off here with one terabyte for 25 bucks. So, people just start signing up. Now, before that, it was five terabytes a month for $99, and then we changed the plan. But yeah, it was cheap enough, so people just start sending us more and more and more data eventually. +They weren't thinking...we changed the way people start thinking of “what am I going to send to Axiom” or “what am I going to send to my logs provider or log storage?” To how much more can I send? And I think that's what we wanted to reach. We wanted people to think, how much more can I send? +JOE: You mentioned latency and cost. I'm curious about...the other big challenge we've seen with observability platforms, including logs, is cardinality of labels. Was there anything you had to sacrifice upfront in terms of cardinality to manage either cost or volume? +SEIF: No, not really. Because the way we designed it was that we should be able to deal with high cardinality from scratch, right? I mean, there's open-source ways of doing, like, if you look at how, like, a column store, if you look at a column store and every dimension is its own column, it's just that becomes, like, you can limit on the amount of columns you're creating, but you should never limit on the amount of different values in a column could be. +So, if you're having something like stat tags, right? Let's say hosting, like, hostname should be a column, but then the different hostnames you have, we never limit that. So, the cardinality on a value is something that is unlimited for us, and we don't really see it in cost. It doesn't really hit us on cost. It reflects a bit on compression if you get into technical details of that because, you know, high cardinality means a lot of different data. So, compression is harder, but it's not repetitive. +But then if you look at, you know, oh, I want to send a lot of different types of fields, not values with fields, so you have hostname, and latency, and whatnot, et cetera, et cetera, yeah, that's where limitation starts because then they have...it's like you're going to a wide range of...and a wider dimension. But even that, we, yeah, we can deal with thousands at this point. And we realize, like, most people will not need more than three or four. It's like a Postgres table. You don't need more than 3,000 to 4000 columns; else, you know, you're doing a lot. +JOE: I think it's actually pretty compelling in terms of cost, though. Like, that's one of the things we've had to be most careful about in terms of containing cost for metrics and logs is, a lot of providers will...they'll either charge you based on the number of unique metric combinations or the performance suffers greatly. Like, we've used a lot of Prometheus-based solutions. +And so, when we're working with developers, even though they don't need more than, you know, a few dozen metric combinations most of the time, it's hard for people to think of what they need upfront. It's much easier after you deploy it to be able to query your data and slice it retroactively based on what you're seeing. +SEIF: That's the detail. When you say we're using Prometheus, a lot of the metrics tools out there are using, just like Prometheus, are using the Gorilla data structure. And the real data structure was never designed to deal with high cardinality labels. So, basically, to put it in a simple way, every combination of tags you send for metrics is its own file on disk. That's, like, the very simple way of explaining this. And then, when you're trying to search through everything, right? And you have a lot of these combinations. I actually have to get all these files from this conversion back together, you know, and then they're chunked, et cetera. So, it's a problem. +Generally, how metrics are doing it...most metrics products are using it, even VictoriaMetrics, et cetera. What they're doing is they're using either the Prometheus TSDB data structure, which is based on Gorilla. Influx was doing the same thing. They pivoted to using more and more like the ones we use, and Honeycomb uses, right? So, we might not be as fast on metrics side as these highly optimized. But then when it comes to high [inaudible 20:49], once we start dealing with high cardinality, we will be faster than those solutions. And that's on a very technical level. +JOE: That's pretty cool. I realize we're getting pretty technical here. Maybe it's worth defining cardinality for the audience. +SEIF: Defining cardinality to the...I mean, we just did that, right? +JOE: What do you think, Victoria? Do you know what cardinality is now? [laughs] +VICTORIA: All right. Now I'm like, do I know? I was like, I think I know what it means. Cardinality is, like, let's say you have a piece of data like an event or a transaction. +SEIF: It's like the distinct count on a property that gives you the cardinality of a property. +VICTORIA: Right. It's like how many pieces of information you have about that one event, basically, yeah. +JOE: But with some traditional metrics stores, it's easy to make mistakes. For example, you could have unbounded cardinality by including response time as one of the labels -- +SEIF: Tags. +JOE: And then it's just going to -- +SEIF: Oh, no, no. Let me give you a better one. I put in timestamp at some point in my life. +JOE: Yeah, I feel like everybody has done that one. +[laughter] +SEIF: I've put a system timestamp at some point in my life. There was the actual timestamp, and there was a system timestamp that I would put because I wanted to know when the...because I couldn't control the timestamp, and the only timestamp I had was a system timestamp. I would always add the actual timestamp of when that event actually happened into a metric, and yeah, that did not scale. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +VICTORIA: Yeah. I wonder if you could maybe share, like, a story about when it's gone wrong, and you've suddenly charged a lot of money [laughs] just to get information about what's happening in the system. Any, like, personal experiences with observability that kind of informed what you did with Axiom? +SEIF: Oof, I have a very bad one, like, a very, very bad one. I used to work for a company. We had to deploy Elasticsearch on Windows Servers, and it was US-East-1. So, just a combination of Elasticsearch back in 2013, 2014 together with Azure and Windows Server was not a good idea. So, you see where this is going, right? +JOE: I see where it's going. +SEIF: Eventually, we had, like, we get all these problems because we used Elasticsearch and Kibana as our, you know, observability platform to measure everything around the product we were building. And funny enough, it cost us more than actually maintaining the infrastructure of the product. But not just that, it also kept me up longer because most of the downtimes I would get were not because of the product going down. It's because my Elasticsearch cluster started going down, and there's reasons for that. Because back then, Microsoft Azure thought that it's okay for any VM to lose connection with the rest of the VMs for 30 seconds per day. And then, all of a sudden, you have Elasticsearch with a split-brain problem. +And there was a phase where I started getting alerted so much that back then, my partner threatened to leave me. So I bought a...what I think was a shock bracelet or a shock collar via Bluetooth, and I connected it to phone for any notification. And I bought that off Alibaba, by the way. And I would charge it at night, put it on my wrist, and go to sleep. And then, when alert happens, it will fully discharge the battery on me every time. +JOE: Okay, I have to admit, I did not see where that was going. +SEIF: Yeah, did that for a while; definitely did not save my relationship either. But eventually, that was the point where, you know, we started looking into other observability tools like Datadog, et cetera, et cetera, et cetera. And that's where the actual journey began, where we moved away from Elasticsearch and Kibana to look for something, okay, that we don't have to maintain ourselves and we can use, et cetera. So, it's not about the costs as much; it was just pain. +VICTORIA: Yeah, pain is a real pain point, actual physical [chuckles] and emotional pain point [laughter]. What, like, motivates you to keep going with Axiom and to keep, like, the wind in your sails to keep working on it? +SEIF: There's a couple of things. I love working with my team. So, honestly, I just wake up, and I compliment my team. I just love working with them. They're a lot of fun to work with. And they challenge me, and I challenge them back. And I upset them a lot. And they can't upset me, but I upset them. But I love working with them, and I love working with that team. +And the other thing is getting, like, having this constant feedback from customers just makes you want to do more and, you know, close sales, et cetera. It's interesting, like, how I'm a very technical person, and I'm more interested in sales because sales means your product works, the product, the technical parts, et cetera. Because if technically it's not working, you can't build a product on top of it. And if you're not selling it, then what's the point? You only sell when the product is good, more or less, unless you're Oracle. +VICTORIA: I had someone ask me about Oracle recently, actually. They're like, "Are you considering going back to it?" And I'm maybe a little allergic to it from having a federal consulting background [laughs]. But maybe they'll come back around. I don't know. We'll see. +SEIF: Did you sell your soul back then? +VICTORIA: You know, I feel like I just grew up in a place where that's what everyone did was all. +SEIF: It was Oracle, IBM, or HP back in the day. +VICTORIA: Yeah. Well, basically, when you're working on applications that were built in, like, the '80s, Oracle was, like, this hot, new database technology [laughs] that they just got five years ago. So, that's just, yeah, interesting. +SEIF: Although, from a database perspective, they did a lot of the innovations. A lot of first innovations could have come from Oracle. From a technical perspective, they're ridiculous. I'm not sure from a product perspective how good they are. But I know their sales team is so big, so huge. They don't care about the product anymore. They can still sell. +VICTORIA: I think, you know, everything in tech is cyclical. So, you know, if they have the right strategy and they're making some interesting changes over there, there's always a chance [laughs]. Certain use cases, I mean, I think that's the interesting point about working in technology is that you know, every company is a tech company. And so, there's just a lot of different types of people, personas, and use cases for different types of products. So, I wonder, you know, you kind of mentioned earlier that, like, everyone is interested in Axiom. But, you know, I don't know, are you narrowing the market? Or, like, how are you trying to kind of focus your messaging and your sales for Axiom? +SEIF: I'm trying to focus on developers. So, we're really trying to focus on developers because the experience around observability is crap. It's stupid expensive. Sorry for being straightforward, right? And that's what we're trying to change. And we're targeting developers mainly. We want developers to like us. And we'll find all these different types of developers who are using it, and that's the interesting thing. +And because of them, we start adding more and more features, like, you know, we added tracing, and now that enables, like, billions of events pushed through for, you know, again, for almost no money, again, $25 a month for a terabyte of data. And we're doing this with metrics next. And that's just to address the developers who have been giving us feedback and the market demand. I will sum it up, again, like, the experience is crap, and it's stupid expensive. I think that's the [inaudible 28:07] of observability is just that's how I would sum it up. +VICTORIA: If you could go back in time and talk to yourself when you were still a developer, now that you're CTO, what advice would you give yourself? +JOE: Besides avoiding shock collars. +VICTORIA: [laughs] Yes. +SEIF: Get people's feedback quickly so you know you're on the right track. I think that's very, very, very, very important. Don't just work in the dark, or don't go too long into stealth mode because, eventually, people catch up. Also, ship when you're 80% ready because 100% is too late. I think it's the same thing here. +JOE: Ship often and early. +SEIF: Yeah, even if it's not fully ready, it's still feedback. +VICTORIA: Ship often and early and talk to people [laughs]. Just, do you feel like, as a developer, did you have the skills you needed to be able to get the most out of those feedback and out of those conversations you were having with people around your product? +SEIF: I still don't think I'm good enough. You're just constantly learning, right? I just accepted I'm part of a team, and I have my contributions. But as an individual, I still don't think I know enough. I think there's more I need to learn at this point. +VICTORIA: I wonder, what questions do you have for me or Joe? +SEIF: How did you start your podcast, and why the name? +VICTORIA: Oh, man, I hope I can answer. So, the podcast was started...I think it's, like, we're actually about to be at our 500th Episode. So, I've only been a host for the last year. Maybe Joe even knows more than I do. But what I recall is that one person at thoughtbot thought it would be a great idea to start a podcast, and then they did it. And it seems like the whole company is obsessed with robots. I'm not really sure where that came from. There used to be a tiny robot in the office, is what I remember. And people started using that as, like, the mascot. And then, yeah, that's it, that's the whole thing. +SEIF: Was the robot doing anything useful or just being cute? +JOE: It was just cute, and it's hard to make a robot cute. +SEIF: Was it a real robot, or was it like a -- +JOE: No, there was, at one point, a toy robot. The name...I actually forget the origin–origin of the name, but the name Giant Robots comes from our blog. So, we named the podcast the same as the blog: Giant Robots Smashing Into Other Giant Robots. +SEIF: Yes, it's called transformers. +VICTORIA: Yeah, I like it. It's, I mean, now I feel like -- +SEIF: [laughs] +VICTORIA: We got to get more, like, robot dogs involved [laughs] in the podcast. +SEIF: Like, I wanted to add one thing when we talked about, you know, what gets me going. And I want to mention that I have a six-month-old son now. He definitely adds a lot of motivation for me to wake up in the morning and work. But he also makes me wake up regardless if I want to or not. +VICTORIA: Yeah, you said you had invented an alarm clock that never turns off. Never snoozes [laughs]. +SEIF: Yes, absolutely. +VICTORIA: I have the same thing, but it's my dog. But he does snooze, actually. He'll just, like, get tired and go back to sleep [laughs]. +SEIF: Oh, I have a question. Do dogs have a Tamagotchi phase? Because, like, my son, the first three months was like a Tamagotchi. It was easy to read him. +VICTORIA: Oh yeah, uh-huh. +SEIF: Noisy but easy. +VICTORIA: Yes, yes. +SEIF: Now, it's just like, yeah, I don't know, like, the last month he has opinions at six months. I think it's because I raised him in Europe. I should take him back to the Middle East [laughs]. No opinions. +VICTORIA: No, dogs totally have, like, a communication style, you know, I pretty much know what he, I mean, I can read his mind, obviously [laughs]. +SEIF: Sure, but that's when they grow a bit. But what when they were very...when the dog was very young? +VICTORIA: Yeah, they, I mean, they also learn, like, your stuff, too. So, they, like, learn how to get you to do stuff or, like, I know she'll feed me if I'm sitting here [laughs]. +SEIF: And how much is one dog year, seven years? +VICTORIA: Seven years. +SEIF: Seven years? +VICTORIA: Yeah, seven years? +SEIF: Yeah. So, basically, in one year, like, three months, he's already...in one month, he's, you know, seven months old. He's like, yeah. +VICTORIA: Yeah. In a year, they're, like, teenagers. And then, in two years, they're, like, full adults. +SEIF: Yeah. So, the first month is basically going through the first six months of a human being. So yeah, you pass...the first two days or three days are the Tamagotchi phase that I'm talking about. +VICTORIA: [chuckles] I read this book, and it was, like, to understand dogs, it's like, they're just like humans that are trying to, like, maximize the number of positive experiences that they have. So, like, if you think about that framing around all your interactions about, like, maybe you're trying to get your son to do something, you can be like, okay, how do I, like, I don't know, train him that good things happen when he does the things I want him to do? [laughs] That's kind of maybe manipulative but effective. So, you're not learning baby sign language? You're just, like, going off facial expressions? +SEIF: I started. I know how Mama looks like. I know how Dada looks like. I know how more looks like, slowly. And he already does this thing that I know that when he's uncomfortable, he starts opening and closing his hands. And when he's completely uncomfortable and basically that he needs to go sleep, he starts pulling his own hair. +VICTORIA: [laughs] I do the same thing [laughs]. +SEIF: You pull your own hair when you go to sleep? I don't have that. I don't have hair. +VICTORIA: I think I do start, like, touching my head though, yeah [inaudible 33:04]. +SEIF: Azure took the last bit of hair I had! Went away with Azure, Elasticsearch, and the shock collar. +VICTORIA: [laughs] +SEIF: I have none of them left. Absolutely nothing. I should sue Elasticsearch for this shit. +VICTORIA: [laughs] Let me know how that goes. Maybe there's more people who could join your lawsuit, you know, with a class action. +SEIF: [laughs] Yeah. Well, one thing I wanted to also just highlight is, right now, one of the things that also makes the company move forward is we realized that in a single domain, we proved ourselves very valuable to specific companies, right? So, that was a big, big thing, milestone for us. And now we're trying to move into a handful of domains and see which one of those work out the best for us. Does that make sense? +VICTORIA: Yeah. And I'm curious: what are the biggest challenges or hurdles that you associate with that? +SEIF: At this point, you don't want just feedback. You want constructive criticism. Like, you want to work with people who will criticize the applic...and you iterate with them based on this criticism, right? They're just not happy about you and trying to create design partners. So, for us, it was very important to have these small design partners who can work with us to actually prove ourselves as valuable in a single domain. +Right now, we need to find a way to scale this across several domains. And how do you do that without sacrificing? Like, how do you open into other domains without sacrificing the original domain you came from? So, there's a lot of things [inaudible 34:28]. And we are in the middle of this. Honestly, I Forrest Gumped my way through half of this, right? Like, I didn't know what I was doing. I had ideas. I think it's more of luck at this point. And I had luck. No, we did work. We did work a lot. We did sleepless nights and everything. +But I think, in the last three years, we became more mature and started thinking more about product. And as I said, like, our CEO, Neil, and Dominic, our head of product, are putting everything behind being a product-led organization, not just a tech-led organization. +VICTORIA: That's super interesting. I love to hear that that's the way you're thinking about it. +JOE: I was just curious what other domains you're looking at pushing into if you can say. +SEIF: So, we are going to start moving into ETL a bit more. We're trying to see how we can fit in specific ML scenarios. I can't say more about the other, though. +JOE: Do you think you'll take the same approaches in terms of value proposition, like, low cost, good enough latency? +SEIF: Yes, that's definitely one thing. But there's also...so, this is the values we're bringing to the customer. But also, now, our internal values are different. Now it's more of move with urgency and high velocity, as we said before, right? Think big, work small. The values in terms of values we're going to take to the customers it's the same ones. And maybe we'll add some more, but it's still going to be low-cost and large-scale. And, internally, we're just becoming more, excuse my French, agile. I hate that word so much. Should be good with Scrum. +VICTORIA: It's painful, but everyone knows what you're talking about [laughs], you know, like -- +SEIF: See, I have opinions here about Scrum. I think Scrum should be only used in terms of iceScrum [inaudible 36:04], or something like that. +VICTORIA: Oh no [laughter]. Well, it's a Rugby term, right? Like, that's where it should probably stay. +SEIF: I did not know it's a rugby term. +VICTORIA: Yeah, so it should stay there, but -- +SEIF: Yes [laughs]. +VICTORIA: Yeah, I think it's interesting. Yeah, I like the being flexible. I like the just, like, continuous feedback and how you all have set up to, like, talk with your customers. Because you mentioned earlier that, like, you might open source some of your projects. And I'm just curious, like, what goes into that decision for you when you're going to do that? Like, what makes you think this project would be good for open source or when you think, actually, we need to, like, keep it? +SEIF: So, we open source libraries, right? We actually do that already. And some other big organizations use our libraries; even our competitors use our libraries, that we do. The whole product itself or at least a big part of the product, like database, I'm not sure we're going to open source that, at least not anytime soon. And if we open source, it's going to be at a point where the value-add it brings is nothing compared to how well our product is, right? So, if we can replace whatever's at the back with...the storage engine we have in the back with something else and the product doesn't get affected, that's when we open source it. +VICTORIA: That's interesting. That makes sense to me. But yeah, thank you for clarifying that. I just wanted to make sure to circle back. Since you have this big history in open source, yeah, I'm curious if you see... +SEIF: Burning me out? +VICTORIA: Burning you out, yeah [laughter]. Oh, that's a good question. Yeah, like, because, you know, we're about to be in October here. Do you have any advice or strategies as a maintainer for not getting burned out during the next couple of weeks besides, like, hide in a cave and without internet access [laughs]? +SEIF: Stay away from Reddit and Hacker News. That's my goal for October now because I'm always afraid of getting too attached to an idea, or too motivated, or excited by an idea that I drift away from what I am actually supposed to be doing. +VICTORIA: Last question is, is there anything else you would like to promote? +SEIF: Yeah, check out our website; I think it's at axiom.co. Check it out. Sign up. And comment on Discord and talk to me. I don't bite, sometimes grumpy, but that's just because of lack of sleep in the morning. But, you know, around midday, I'm good. And if you're ever in Berlin and you want to hang out, I'm more than willing to hang out. +VICTORIA: Whoo, that's awesome. Yeah, Berlin is great. I was there a couple of years ago but no plans to go back anytime soon, but maybe I'll keep that in mind. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg. +And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. + Special Guests: Joe Ferris and Seif Lotfy. + + + Victoria is joined by guest co-host Joe Ferris, CTO at thoughtbot, and Seif Lotfy, the CTO and Co-Founder of Axiom. Seif discusses the journey, challenges, and strategies behind his data analytics and observability platform.

+ +

Seif, who has a background in robotics and was a 2008 Sony AIBO robotic soccer world champion, shares that Axiom pivoted from being a Datadog competitor to focusing on logs and event data. The company even built its own logs database to provide a cost-effective solution for large-scale analytics. Seif is driven by his passion for his team and the invaluable feedback from the community, emphasizing that sales validate the effectiveness of a product. The conversation also delves into Axiom's shift in focus towards developers to address their need for better and more affordable observability tools.

+ +

On the business front, Seif reveals the company's challenges in scaling across multiple domains without compromising its core offerings. He discusses the importance of internal values like moving with urgency and high velocity to guide the company's future. Furthermore, he touches on the challenges and strategies of open-sourcing projects and advises avoiding platforms like Reddit and Hacker News to maintain focus.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Seif Lotfy, CTO and Co-Founder of Axiom, the best home for your event data. Seif, thank you for joining me.

+ +

SEIF: Hey, everybody. Thanks for having me. This is awesome. I love the name of the podcast, given that I used to compete in robotics.

+ +

VICTORIA: What? All right, we're going to have to talk about that. And I also want to introduce a guest co-host today. Since we're talking about cloud, and observability, and data, I invited Joe Ferris, thoughtbot CTO and Director of Development of our platform engineering team, Mission Control. Welcome, Joe. How are you?

+ +

JOE: Good, thanks. Good to be back again.

+ +

VICTORIA: Okay. I am excited to talk to you all about observability. But I need to go back to Seif's comment on competing with robots. Can you tell me a little bit more about what robots you've built in the past?

+ +

SEIF: I didn't build robots; I used to program them. Remember the Sony AIBOs, where Sony made these dog robots? And we would make them compete. There was an international competition where we made them play soccer, and they had to be completely autonomous. They only communicate via Bluetooth or via wireless protocols. And you only have the camera as your sensor as well as...a chest sensor throws the ball near you, and then yeah, you make them play football against each other, four versus four with a goalkeeper and everything. Just look it up: RoboCup AIBO. Look it up on YouTube. And I...2008 world champion with the German team.

+ +

VICTORIA: That sounds incredible. What kind of crowds are you drawing out for a robot soccer match? Is that a lot of people involved with that?

+ +

SEIF: You would be surprised how big the RoboCup competition is. It's ridiculous.

+ +

VICTORIA: I want to go. I'm ready. I want to, like, I'll look it up and find out when the next one is.

+ +

SEIF: No more Sony robots but other robots. Now, there's two-legged robots. So, they make them play as two-legged robots, much slower than four-legged robots, but works.

+ +

VICTORIA: Wait. So, the robots you were playing soccer with had four legs they were running around on?

+ +

SEIF: Yeah, they were dogs [laughter].

+ +

VICTORIA: That's awesome.

+ +

SEIF: We all get the same robot. It's just a competition on software, right? On a software level. And some other competitions within the RoboCup actually use...you build your own robot and stuff like that. But this one was...it's called the Standard League, where we all have a robot, and we have to program it.

+ +

JOE: And the standard robot was a dog.

+ +

SEIF: Yeah, I think back then...we're talking...it's been a long time. I think it started in 2001 or something. I think the competition started in 2001 or 2002. And I compete from 2006 to 2008. Robots back then were just, you know, simple.

+ +

VICTORIA: Robots today are way too complicated [laughs].

+ +

SEIF: Even AI is more complicated.

+ +

VICTORIA: That's right. Yeah, everything has gotten a lot more complicated [laughs]. I'm so curious how you went from being a world-champion robot dog soccer player [laughs] programmer [laughs] to where you are today with Axiom. Can you tell me a little bit more about your journey?

+ +

SEIF: The journey is interesting because it came from open source. I used to do open source on the side a lot–part of the GNOME Project. That's where I met Neil and the rest of my team, Mikkel Kamstrup, the whole crowd, basically. We worked on GNOME. We worked on Ubuntu. Like, most of them were working professionally on it. I was working for another company, but we worked on the same project.

+ +

We ended up at Xamarin, which was bought by Microsoft. And then we ended up doing Axiom. But we've been around each other professionally since 2009, most of us. It's like a little family. But how we ended up exactly in observability, I think it's just trying to fix pain points in my life.

+ +

VICTORIA: Yeah, I was reading through the docs on Axiom. And there's an interesting point you make about organizations having to choose between how much data they have and how much they want to spend on it. So, maybe you can tell me a little bit more about that pain point and what you really found in the early stages that you wanted to solve.

+ +

SEIF: So, the early stages of what we wanted to solve we were mainly dealing with...so, the early, early stage, we were actually trying to be a Datadog competitor, where we were going to be self-hosted. Eventually, we focused on logs because we found out that's what was a big problem for most people, just event data, not just metric but generally event data, so logs, traces, et cetera. We built out our own logs database completely from scratch.

+ +

And one of the things we stumbled upon was; basically, you have three things when it comes to logging, which is low cost, low latency, and large scale. That's what everybody wants. But you can't get all three of them; you can only get two of them. And we opted...like, we chose large scale and low cost. And when it comes to latency, we say it should be just fast enough, right? And that's where we focused on, and this is how we started building it. And with that, this is how we managed to stand out by just having way lower cost than anybody else in the industry and dealing with large scale.

+ +

VICTORIA: That's really interesting. And how did you approach making the ingestion pipeline for masses amount of data more efficient?

+ +

SEIF: Just make it coordination-free as possible, right? And get rid of Kafka because Kafka just, you know, drains your...it's where you throw in money. Like maintaining Kafka...it's like back then Elasticsearch, right? Elasticsearch was the biggest part of your infrastructure that would cost money. Now, it's also Kafka.

+ +

So, we found a way to have our own internal way of queueing things without having to rely on Kafka. As I said, we wrote everything from scratch to make it work. Like, every now and then, I think that we can spin this out of the company and make it a new product. But now, eyes on the prize, right?

+ +

JOE: It's interesting to hear that somebody who spent so much time in the open-source community ended up rolling their own solution to so many problems. Do you feel like you had some lessons learned from open source that led you to reject solutions like Kafka, or how did that journey go?

+ +

SEIF: I don't think I'm rejecting Kafka. The problem is how Kafka is built, right? Kafka is still...you have to set up all these servers. They have to communicate, et cetera, etcetera. They didn't build it in a way where it's stateless, and that's what we're trying to go to. We're trying to make things as stateless as possible. So, Kafka was never built for the cloud-native era. And you can't really rely on SQS or something like that because it won't deal with this high throughput.

+ +

So, that's why I said, like, we will sacrifice some latency, but at least the cost is low. So, if messages show after half a second or a second, I'm good. It doesn't have to be real-time for me. So, I had to write a couple of these things. But also, it doesn't mean that we reject open source. Like, we actually do like open source. We open-source a couple of libraries. We contribute back to open source, right? We needed a solution back then for that problem, and we couldn't find any. And maybe one day, open source will have, right?

+ +

JOE: Yeah. I was going to ask if you considered open-sourcing any of your high latency, high throughput solutions.

+ +

SEIF: Not high latency. You make it sound bad.

+ +

JOE: [laughs]

+ +

SEIF: You make it sound bad. It's, like, fast enough, right? I'm not going to compete on milliseconds because, also, I'm competing with ClickHouse. I don't want to compete with ClickHouse. ClickHouse is low latency and large scale, right? But then the cost is, you know, off the charts a bit sometimes.

+ +

I'm going the other route. Like, you know, it's fast enough. Like, how, you know, if it's under two, three seconds, everybody's happy, right? If the results come within two, three seconds, everybody is happy. If you're going to build a real-time trading system on top of it, I'll strongly advise against that. But if you're building, you know, you're looking at dashboards, you're more in the observability field, yeah, we're good.

+ +

VICTORIA: Yeah, I'm curious what you found, like, which customer personas that market really resonated with. Like, is there a particular, like, industry type where you're noticing they really want to lower their cost, and they're okay with this just fast enough latency?

+ +

SEIF: Honestly, with the current recession, everybody is okay with giving up some of the speed to reduce the money because I think it's not linear reduction. It's more exponential reduction at this point, right? You give up a second, and you're saving 30%. You give up two seconds, all of a sudden, you're saving 80%.

+ +

So, I'd say in the beginning, everybody thought they need everything to be very, very fast. And now they're realizing, you know, with limitations you have around your budget and spending, you're like, okay, I'm okay with the speed. And, again, we're not slow. I'm just saying people realize they don't need everything under a second. They're okay with waiting for two seconds.

+ +

VICTORIA: That totally resonates with me. And I'm curious if you can add maybe a non-technical or a real-life example of, like, how this impacts the operations of a company or organization, like, if you can give us, like, a business-y example of how this impacts how people work.

+ +

SEIF: I don't know how, like, how do people work on that? Nothing changed, really. They're still doing the, like...really nothing because...and that aspect is you run a query, and, again, as I said, you're not getting the result in a second. You're just waiting two seconds or three seconds, and it's there. So, nothing really changed. I think people can wait three seconds. And we're still like–when I say this, we're still faster than most others. We're just not as fast as people who are trying to compete on a millisecond level.

+ +

VICTORIA: Yeah, that's okay. Maybe I'll take it back even, like, a step further, right? Like, our audience is really sometimes just founders who almost have no formal technical training or background. So, when we talk about observability, sometimes people who work in DevOps and operations all understand it and kind of know why it's important [laughs] and what we're talking about. So, maybe you could, like, go back to --

+ +

SEIF: Oh, if you're asking about new types of people who've been using it --

+ +

VICTORIA: Yeah. Like, if you're going to explain to, like, a non-technical founder, like, why your product is important, or, like, how people in their organization might use it, what would you say?

+ +

SEIF: Oh, okay, if you put it like that. It's more of if you have data, timestamp data, and you want to run analytics on top of it, so that could be transactions, that could be web vitals, rather than count every time somebody visits, you have a timestamp. So, you can count, like, how many visitors visited the website and what, you know, all these kinds of things. That's where you want to use something like Axiom. That's outside the DevOps space, of course. And in DevOps space, there's so many other things you use Axiom for, but that's outside the DevOps space.

+ +

And we actually...we implemented as zero-config integration with Vercel that kind of went viral. And we were, for a while, the number one enterprise for self-integration because so many people were using it. So, Vercel users are usually not necessarily writing the most complex backends, but a lot of things are happening on the front-end side of things. And we would be giving them dashboards, automated dashboards about, you know, latencies, and how long a request took, and how long the response took, and the content type, and the status codes, et cetera, et cetera. And there's a huge user base around that.

+ +

VICTORIA: I like that. And it's something, for me, you know, as a managing director of our platform engineering team, I want to talk more to founders about. It's great that you put this product and this app out into the world. But how do you know that people are actually using it? How do you know that people, like, maybe, are they all quitting after the first day and not coming back to your app? Or maybe, like, the page isn't loading or, like, it's not working as they expected it to.

+ +

And, like, if you don't have anything observing what users are doing in your app, then it's going to be hard to show that you're getting any traction and know where you need to go in and make corrections and adjust.

+ +

SEIF: We have two ways of doing this. Right now, internally, we use our own tools to see, like, who is sending us data. We have a deployment that's monitoring production deployment. And we're just, you know, seeing how people are using it, how much data they're sending every day, who stopped sending data, who spiked in sending data sets, et cetera.

+ +

But we're using Mixpanel, and Dominic, our Head of Product, implemented a couple of key metrics to that for that specifically. So, we know, like, what's the average time until somebody starts going from building its own queries with the builder to writing APL, or how long it takes them from, you know, running two queries to five queries. And, you know, we just start measuring these things now. And it's been going...we've been growing healthy around that.

+ +

So, we tend to measure user interaction, but also, we tend to measure how much data is being sent. Because let's keep in mind, usually, people go in and check for things if there's a problem. So, if there's no problem, the user won't interact with us much unless there's a notification that kicks off. We also just check, like, how much data is being sent to us the whole time.

+ +

VICTORIA: That makes sense. Like, you can't just rely on, like, well, if it was broken, they would write a [chuckles], like, a question or something. So, how do you get those metrics and that data around their interactions? So, that's really interesting. So, I wonder if we can go back and talk about, you know, we already mentioned a little bit about, like, the early days of Axiom and how you got started. Was there anything that you found in the early discovery process that was surprising and made you pivot strategy?

+ +

SEIF: A couple of things. Basically, people don't really care about the tech as much as they care [inaudible 12:51] and the packaging, so that's something that we had to learn. And number two, continuous feedback. Continuous feedback changed the way we worked completely, right? And, you know, after that, we had a Slack channel, then we opened a Discord channel. And, like, this continuous feedback coming in just helps with iterating, helps us with prioritizing, et cetera. And that changed the way we actually developed product.

+ +

VICTORIA: You use Slack and Discord?

+ +

SEIF: No. No Slack anymore. We had a community Slack. We had a community [inaudible 13:19] Slack. Now, there's no community Slack. We only have a community Discord. And the community Slack is...sorry, internally, we use Slack, but there's a community Discord for the community.

+ +

JOE: But how do you keep that staffed? Is it, like, everybody is in the Discord during working hours? Is it somebody's job to watch out for community questions?

+ +

SEIF: I think everybody gets involved now just...and you can see it. If you go on our Discord, you will just see it. Just everyone just gets involved. I think just people are passionate about what they're doing. At least most people are involved on Discord, right? Because there's, like, Discord the help sections, and people are just asking questions and other people answering.

+ +

And now, we reached a point where people in the community start answering the questions for other people in the community. So, that's how we see it's starting to become a healthy community, et cetera. But that is one of my favorite things: when I see somebody from the community answering somebody else, that's a highlight for me. Actually, we hired somebody from that community because they were so active.

+ +

JOE: Yeah, I think one of the biggest signs that a product is healthy is when there's a healthy ecosystem building up around it.

+ +

SEIF: Yeah, and Discord reminds me of the old days of open sources like IRC, just with memes now. But because all of us come from the old IRC days, being on Discord and chatting around, et cetera, et cetera, just gives us this momentum back, gave us this momentum back, whereas Slack always felt a bit too businessy to me.

+ +

JOE: Slack is like IRC with emoji. Discord is IRC with memes.

+ +

SEIF: I would say Slack reminds me somehow of MSN Messenger, right?

+ +

JOE: I feel like there's a huge slam on MSN Messenger here.

+ +

SEIF: [laughs] What do you guys use internally, Slack or? I think you're using Slack, right? Or Teams. Don't tell me you're using Teams.

+ +

JOE: No, we're using Slack.

+ +

SEIF: Okay, good, because I shit talk. Like, there is this, I’ll sh*t talk here–when I start talking about Teams, so...I remember that one thing Google did once, and that failed miserably.

+ +

JOE: Google still has, like, seven active chat products.

+ +

SEIF: Like, I think every department or every, like, group of engineers just uses one of them internally. I'm not sure. Never got to that point. But hey, who am I to judge?

+ +

VICTORIA: I just feel like I end up using all of them, and then I'm just rotating between different tabs all day long. You maybe talked me into using Discord. I feel like I've been resisting it, but you got me with the memes.

+ +

SEIF: Yeah, it's definitely worth it. It's more entertaining. More noise, but more entertaining. You feel it's alive, whereas Slack is...also because there's no, like, history is forever. So, you always go back, and you're like, oh my God, what the hell is this?

+ +

VICTORIA: Yeah, I have, like, all of them. I'll do anything.

+ +

SEIF: They should be using Axiom in the background. Just send data to Axiom; we can keep your chat history.

+ +

VICTORIA: Yeah, maybe. I'm so curious because, you know, you mentioned something about how you realized that it didn't matter really how cool the tech was if the product packaging wasn't also appealing to people. Because you seem really excited about what you've built. So, I'm curious, so just tell us a little bit more about how you went about trying to, like, promote this thing you built. Or was, like, the continuous feedback really early on, or how did that all kind of come together?

+ +

SEIF: The continuous feedback helped us with performance, but actually getting people to sign up and pay money it started early on. But with Vercel, it kind of skyrocketed, right? And that's mostly because we went with the whole zero-config approach where it's just literally two clicks. And all of a sudden, Vercel is sending your data to Axiom, and that's it. We will create [inaudible 16:33].

+ +

And we worked very closely with Vercel to do this, to make this happen, which was awesome. Like, yeah, hats off to them. They were fantastic. And just two clicks, three clicks away, and all of a sudden, we created Axiom organization for you, the data set for you. And then we're sending it...and the data from Vercel is being forwarded to it. I think that packaging was so simple that it made people try it out quickly. And then, the experience of actually using Axiom was sticky, so they continued using it.

+ +

And then the price was so low because we give 500 gigs for free, right? You send us 500 gigs a month of logs for free, and we don't care. And you can start off here with one terabyte for 25 bucks. So, people just start signing up. Now, before that, it was five terabytes a month for $99, and then we changed the plan. But yeah, it was cheap enough, so people just start sending us more and more and more data eventually.

+ +

They weren't thinking...we changed the way people start thinking of “what am I going to send to Axiom” or “what am I going to send to my logs provider or log storage?” To how much more can I send? And I think that's what we wanted to reach. We wanted people to think, how much more can I send?

+ +

JOE: You mentioned latency and cost. I'm curious about...the other big challenge we've seen with observability platforms, including logs, is cardinality of labels. Was there anything you had to sacrifice upfront in terms of cardinality to manage either cost or volume?

+ +

SEIF: No, not really. Because the way we designed it was that we should be able to deal with high cardinality from scratch, right? I mean, there's open-source ways of doing, like, if you look at how, like, a column store, if you look at a column store and every dimension is its own column, it's just that becomes, like, you can limit on the amount of columns you're creating, but you should never limit on the amount of different values in a column could be.

+ +

So, if you're having something like stat tags, right? Let's say hosting, like, hostname should be a column, but then the different hostnames you have, we never limit that. So, the cardinality on a value is something that is unlimited for us, and we don't really see it in cost. It doesn't really hit us on cost. It reflects a bit on compression if you get into technical details of that because, you know, high cardinality means a lot of different data. So, compression is harder, but it's not repetitive.

+ +

But then if you look at, you know, oh, I want to send a lot of different types of fields, not values with fields, so you have hostname, and latency, and whatnot, et cetera, et cetera, yeah, that's where limitation starts because then they have...it's like you're going to a wide range of...and a wider dimension. But even that, we, yeah, we can deal with thousands at this point. And we realize, like, most people will not need more than three or four. It's like a Postgres table. You don't need more than 3,000 to 4000 columns; else, you know, you're doing a lot.

+ +

JOE: I think it's actually pretty compelling in terms of cost, though. Like, that's one of the things we've had to be most careful about in terms of containing cost for metrics and logs is, a lot of providers will...they'll either charge you based on the number of unique metric combinations or the performance suffers greatly. Like, we've used a lot of Prometheus-based solutions.

+ +

And so, when we're working with developers, even though they don't need more than, you know, a few dozen metric combinations most of the time, it's hard for people to think of what they need upfront. It's much easier after you deploy it to be able to query your data and slice it retroactively based on what you're seeing.

+ +

SEIF: That's the detail. When you say we're using Prometheus, a lot of the metrics tools out there are using, just like Prometheus, are using the Gorilla data structure. And the real data structure was never designed to deal with high cardinality labels. So, basically, to put it in a simple way, every combination of tags you send for metrics is its own file on disk. That's, like, the very simple way of explaining this. And then, when you're trying to search through everything, right? And you have a lot of these combinations. I actually have to get all these files from this conversion back together, you know, and then they're chunked, et cetera. So, it's a problem.

+ +

Generally, how metrics are doing it...most metrics products are using it, even VictoriaMetrics, et cetera. What they're doing is they're using either the Prometheus TSDB data structure, which is based on Gorilla. Influx was doing the same thing. They pivoted to using more and more like the ones we use, and Honeycomb uses, right? So, we might not be as fast on metrics side as these highly optimized. But then when it comes to high [inaudible 20:49], once we start dealing with high cardinality, we will be faster than those solutions. And that's on a very technical level.

+ +

JOE: That's pretty cool. I realize we're getting pretty technical here. Maybe it's worth defining cardinality for the audience.

+ +

SEIF: Defining cardinality to the...I mean, we just did that, right?

+ +

JOE: What do you think, Victoria? Do you know what cardinality is now? [laughs]

+ +

VICTORIA: All right. Now I'm like, do I know? I was like, I think I know what it means. Cardinality is, like, let's say you have a piece of data like an event or a transaction.

+ +

SEIF: It's like the distinct count on a property that gives you the cardinality of a property.

+ +

VICTORIA: Right. It's like how many pieces of information you have about that one event, basically, yeah.

+ +

JOE: But with some traditional metrics stores, it's easy to make mistakes. For example, you could have unbounded cardinality by including response time as one of the labels --

+ +

SEIF: Tags.

+ +

JOE: And then it's just going to --

+ +

SEIF: Oh, no, no. Let me give you a better one. I put in timestamp at some point in my life.

+ +

JOE: Yeah, I feel like everybody has done that one.

+ +

[laughter]

+ +

SEIF: I've put a system timestamp at some point in my life. There was the actual timestamp, and there was a system timestamp that I would put because I wanted to know when the...because I couldn't control the timestamp, and the only timestamp I had was a system timestamp. I would always add the actual timestamp of when that event actually happened into a metric, and yeah, that did not scale.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: Yeah. I wonder if you could maybe share, like, a story about when it's gone wrong, and you've suddenly charged a lot of money [laughs] just to get information about what's happening in the system. Any, like, personal experiences with observability that kind of informed what you did with Axiom?

+ +

SEIF: Oof, I have a very bad one, like, a very, very bad one. I used to work for a company. We had to deploy Elasticsearch on Windows Servers, and it was US-East-1. So, just a combination of Elasticsearch back in 2013, 2014 together with Azure and Windows Server was not a good idea. So, you see where this is going, right?

+ +

JOE: I see where it's going.

+ +

SEIF: Eventually, we had, like, we get all these problems because we used Elasticsearch and Kibana as our, you know, observability platform to measure everything around the product we were building. And funny enough, it cost us more than actually maintaining the infrastructure of the product. But not just that, it also kept me up longer because most of the downtimes I would get were not because of the product going down. It's because my Elasticsearch cluster started going down, and there's reasons for that. Because back then, Microsoft Azure thought that it's okay for any VM to lose connection with the rest of the VMs for 30 seconds per day. And then, all of a sudden, you have Elasticsearch with a split-brain problem.

+ +

And there was a phase where I started getting alerted so much that back then, my partner threatened to leave me. So I bought a...what I think was a shock bracelet or a shock collar via Bluetooth, and I connected it to phone for any notification. And I bought that off Alibaba, by the way. And I would charge it at night, put it on my wrist, and go to sleep. And then, when alert happens, it will fully discharge the battery on me every time.

+ +

JOE: Okay, I have to admit, I did not see where that was going.

+ +

SEIF: Yeah, did that for a while; definitely did not save my relationship either. But eventually, that was the point where, you know, we started looking into other observability tools like Datadog, et cetera, et cetera, et cetera. And that's where the actual journey began, where we moved away from Elasticsearch and Kibana to look for something, okay, that we don't have to maintain ourselves and we can use, et cetera. So, it's not about the costs as much; it was just pain.

+ +

VICTORIA: Yeah, pain is a real pain point, actual physical [chuckles] and emotional pain point [laughter]. What, like, motivates you to keep going with Axiom and to keep, like, the wind in your sails to keep working on it?

+ +

SEIF: There's a couple of things. I love working with my team. So, honestly, I just wake up, and I compliment my team. I just love working with them. They're a lot of fun to work with. And they challenge me, and I challenge them back. And I upset them a lot. And they can't upset me, but I upset them. But I love working with them, and I love working with that team.

+ +

And the other thing is getting, like, having this constant feedback from customers just makes you want to do more and, you know, close sales, et cetera. It's interesting, like, how I'm a very technical person, and I'm more interested in sales because sales means your product works, the product, the technical parts, et cetera. Because if technically it's not working, you can't build a product on top of it. And if you're not selling it, then what's the point? You only sell when the product is good, more or less, unless you're Oracle.

+ +

VICTORIA: I had someone ask me about Oracle recently, actually. They're like, "Are you considering going back to it?" And I'm maybe a little allergic to it from having a federal consulting background [laughs]. But maybe they'll come back around. I don't know. We'll see.

+ +

SEIF: Did you sell your soul back then?

+ +

VICTORIA: You know, I feel like I just grew up in a place where that's what everyone did was all.

+ +

SEIF: It was Oracle, IBM, or HP back in the day.

+ +

VICTORIA: Yeah. Well, basically, when you're working on applications that were built in, like, the '80s, Oracle was, like, this hot, new database technology [laughs] that they just got five years ago. So, that's just, yeah, interesting.

+ +

SEIF: Although, from a database perspective, they did a lot of the innovations. A lot of first innovations could have come from Oracle. From a technical perspective, they're ridiculous. I'm not sure from a product perspective how good they are. But I know their sales team is so big, so huge. They don't care about the product anymore. They can still sell.

+ +

VICTORIA: I think, you know, everything in tech is cyclical. So, you know, if they have the right strategy and they're making some interesting changes over there, there's always a chance [laughs]. Certain use cases, I mean, I think that's the interesting point about working in technology is that you know, every company is a tech company. And so, there's just a lot of different types of people, personas, and use cases for different types of products. So, I wonder, you know, you kind of mentioned earlier that, like, everyone is interested in Axiom. But, you know, I don't know, are you narrowing the market? Or, like, how are you trying to kind of focus your messaging and your sales for Axiom?

+ +

SEIF: I'm trying to focus on developers. So, we're really trying to focus on developers because the experience around observability is crap. It's stupid expensive. Sorry for being straightforward, right? And that's what we're trying to change. And we're targeting developers mainly. We want developers to like us. And we'll find all these different types of developers who are using it, and that's the interesting thing.

+ +

And because of them, we start adding more and more features, like, you know, we added tracing, and now that enables, like, billions of events pushed through for, you know, again, for almost no money, again, $25 a month for a terabyte of data. And we're doing this with metrics next. And that's just to address the developers who have been giving us feedback and the market demand. I will sum it up, again, like, the experience is crap, and it's stupid expensive. I think that's the [inaudible 28:07] of observability is just that's how I would sum it up.

+ +

VICTORIA: If you could go back in time and talk to yourself when you were still a developer, now that you're CTO, what advice would you give yourself?

+ +

JOE: Besides avoiding shock collars.

+ +

VICTORIA: [laughs] Yes.

+ +

SEIF: Get people's feedback quickly so you know you're on the right track. I think that's very, very, very, very important. Don't just work in the dark, or don't go too long into stealth mode because, eventually, people catch up. Also, ship when you're 80% ready because 100% is too late. I think it's the same thing here.

+ +

JOE: Ship often and early.

+ +

SEIF: Yeah, even if it's not fully ready, it's still feedback.

+ +

VICTORIA: Ship often and early and talk to people [laughs]. Just, do you feel like, as a developer, did you have the skills you needed to be able to get the most out of those feedback and out of those conversations you were having with people around your product?

+ +

SEIF: I still don't think I'm good enough. You're just constantly learning, right? I just accepted I'm part of a team, and I have my contributions. But as an individual, I still don't think I know enough. I think there's more I need to learn at this point.

+ +

VICTORIA: I wonder, what questions do you have for me or Joe?

+ +

SEIF: How did you start your podcast, and why the name?

+ +

VICTORIA: Oh, man, I hope I can answer. So, the podcast was started...I think it's, like, we're actually about to be at our 500th Episode. So, I've only been a host for the last year. Maybe Joe even knows more than I do. But what I recall is that one person at thoughtbot thought it would be a great idea to start a podcast, and then they did it. And it seems like the whole company is obsessed with robots. I'm not really sure where that came from. There used to be a tiny robot in the office, is what I remember. And people started using that as, like, the mascot. And then, yeah, that's it, that's the whole thing.

+ +

SEIF: Was the robot doing anything useful or just being cute?

+ +

JOE: It was just cute, and it's hard to make a robot cute.

+ +

SEIF: Was it a real robot, or was it like a --

+ +

JOE: No, there was, at one point, a toy robot. The name...I actually forget the origin–origin of the name, but the name Giant Robots comes from our blog. So, we named the podcast the same as the blog: Giant Robots Smashing Into Other Giant Robots.

+ +

SEIF: Yes, it's called transformers.

+ +

VICTORIA: Yeah, I like it. It's, I mean, now I feel like --

+ +

SEIF: [laughs]

+ +

VICTORIA: We got to get more, like, robot dogs involved [laughs] in the podcast.

+ +

SEIF: Like, I wanted to add one thing when we talked about, you know, what gets me going. And I want to mention that I have a six-month-old son now. He definitely adds a lot of motivation for me to wake up in the morning and work. But he also makes me wake up regardless if I want to or not.

+ +

VICTORIA: Yeah, you said you had invented an alarm clock that never turns off. Never snoozes [laughs].

+ +

SEIF: Yes, absolutely.

+ +

VICTORIA: I have the same thing, but it's my dog. But he does snooze, actually. He'll just, like, get tired and go back to sleep [laughs].

+ +

SEIF: Oh, I have a question. Do dogs have a Tamagotchi phase? Because, like, my son, the first three months was like a Tamagotchi. It was easy to read him.

+ +

VICTORIA: Oh yeah, uh-huh.

+ +

SEIF: Noisy but easy.

+ +

VICTORIA: Yes, yes.

+ +

SEIF: Now, it's just like, yeah, I don't know, like, the last month he has opinions at six months. I think it's because I raised him in Europe. I should take him back to the Middle East [laughs]. No opinions.

+ +

VICTORIA: No, dogs totally have, like, a communication style, you know, I pretty much know what he, I mean, I can read his mind, obviously [laughs].

+ +

SEIF: Sure, but that's when they grow a bit. But what when they were very...when the dog was very young?

+ +

VICTORIA: Yeah, they, I mean, they also learn, like, your stuff, too. So, they, like, learn how to get you to do stuff or, like, I know she'll feed me if I'm sitting here [laughs].

+ +

SEIF: And how much is one dog year, seven years?

+ +

VICTORIA: Seven years.

+ +

SEIF: Seven years?

+ +

VICTORIA: Yeah, seven years?

+ +

SEIF: Yeah. So, basically, in one year, like, three months, he's already...in one month, he's, you know, seven months old. He's like, yeah.

+ +

VICTORIA: Yeah. In a year, they're, like, teenagers. And then, in two years, they're, like, full adults.

+ +

SEIF: Yeah. So, the first month is basically going through the first six months of a human being. So yeah, you pass...the first two days or three days are the Tamagotchi phase that I'm talking about.

+ +

VICTORIA: [chuckles] I read this book, and it was, like, to understand dogs, it's like, they're just like humans that are trying to, like, maximize the number of positive experiences that they have. So, like, if you think about that framing around all your interactions about, like, maybe you're trying to get your son to do something, you can be like, okay, how do I, like, I don't know, train him that good things happen when he does the things I want him to do? [laughs] That's kind of maybe manipulative but effective. So, you're not learning baby sign language? You're just, like, going off facial expressions?

+ +

SEIF: I started. I know how Mama looks like. I know how Dada looks like. I know how more looks like, slowly. And he already does this thing that I know that when he's uncomfortable, he starts opening and closing his hands. And when he's completely uncomfortable and basically that he needs to go sleep, he starts pulling his own hair.

+ +

VICTORIA: [laughs] I do the same thing [laughs].

+ +

SEIF: You pull your own hair when you go to sleep? I don't have that. I don't have hair.

+ +

VICTORIA: I think I do start, like, touching my head though, yeah [inaudible 33:04].

+ +

SEIF: Azure took the last bit of hair I had! Went away with Azure, Elasticsearch, and the shock collar.

+ +

VICTORIA: [laughs]

+ +

SEIF: I have none of them left. Absolutely nothing. I should sue Elasticsearch for this shit.

+ +

VICTORIA: [laughs] Let me know how that goes. Maybe there's more people who could join your lawsuit, you know, with a class action.

+ +

SEIF: [laughs] Yeah. Well, one thing I wanted to also just highlight is, right now, one of the things that also makes the company move forward is we realized that in a single domain, we proved ourselves very valuable to specific companies, right? So, that was a big, big thing, milestone for us. And now we're trying to move into a handful of domains and see which one of those work out the best for us. Does that make sense?

+ +

VICTORIA: Yeah. And I'm curious: what are the biggest challenges or hurdles that you associate with that?

+ +

SEIF: At this point, you don't want just feedback. You want constructive criticism. Like, you want to work with people who will criticize the applic...and you iterate with them based on this criticism, right? They're just not happy about you and trying to create design partners. So, for us, it was very important to have these small design partners who can work with us to actually prove ourselves as valuable in a single domain.

+ +

Right now, we need to find a way to scale this across several domains. And how do you do that without sacrificing? Like, how do you open into other domains without sacrificing the original domain you came from? So, there's a lot of things [inaudible 34:28]. And we are in the middle of this. Honestly, I Forrest Gumped my way through half of this, right? Like, I didn't know what I was doing. I had ideas. I think it's more of luck at this point. And I had luck. No, we did work. We did work a lot. We did sleepless nights and everything.

+ +

But I think, in the last three years, we became more mature and started thinking more about product. And as I said, like, our CEO, Neil, and Dominic, our head of product, are putting everything behind being a product-led organization, not just a tech-led organization.

+ +

VICTORIA: That's super interesting. I love to hear that that's the way you're thinking about it.

+ +

JOE: I was just curious what other domains you're looking at pushing into if you can say.

+ +

SEIF: So, we are going to start moving into ETL a bit more. We're trying to see how we can fit in specific ML scenarios. I can't say more about the other, though.

+ +

JOE: Do you think you'll take the same approaches in terms of value proposition, like, low cost, good enough latency?

+ +

SEIF: Yes, that's definitely one thing. But there's also...so, this is the values we're bringing to the customer. But also, now, our internal values are different. Now it's more of move with urgency and high velocity, as we said before, right? Think big, work small. The values in terms of values we're going to take to the customers it's the same ones. And maybe we'll add some more, but it's still going to be low-cost and large-scale. And, internally, we're just becoming more, excuse my French, agile. I hate that word so much. Should be good with Scrum.

+ +

VICTORIA: It's painful, but everyone knows what you're talking about [laughs], you know, like --

+ +

SEIF: See, I have opinions here about Scrum. I think Scrum should be only used in terms of iceScrum [inaudible 36:04], or something like that.

+ +

VICTORIA: Oh no [laughter]. Well, it's a Rugby term, right? Like, that's where it should probably stay.

+ +

SEIF: I did not know it's a rugby term.

+ +

VICTORIA: Yeah, so it should stay there, but --

+ +

SEIF: Yes [laughs].

+ +

VICTORIA: Yeah, I think it's interesting. Yeah, I like the being flexible. I like the just, like, continuous feedback and how you all have set up to, like, talk with your customers. Because you mentioned earlier that, like, you might open source some of your projects. And I'm just curious, like, what goes into that decision for you when you're going to do that? Like, what makes you think this project would be good for open source or when you think, actually, we need to, like, keep it?

+ +

SEIF: So, we open source libraries, right? We actually do that already. And some other big organizations use our libraries; even our competitors use our libraries, that we do. The whole product itself or at least a big part of the product, like database, I'm not sure we're going to open source that, at least not anytime soon. And if we open source, it's going to be at a point where the value-add it brings is nothing compared to how well our product is, right? So, if we can replace whatever's at the back with...the storage engine we have in the back with something else and the product doesn't get affected, that's when we open source it.

+ +

VICTORIA: That's interesting. That makes sense to me. But yeah, thank you for clarifying that. I just wanted to make sure to circle back. Since you have this big history in open source, yeah, I'm curious if you see...

+ +

SEIF: Burning me out?

+ +

VICTORIA: Burning you out, yeah [laughter]. Oh, that's a good question. Yeah, like, because, you know, we're about to be in October here. Do you have any advice or strategies as a maintainer for not getting burned out during the next couple of weeks besides, like, hide in a cave and without internet access [laughs]?

+ +

SEIF: Stay away from Reddit and Hacker News. That's my goal for October now because I'm always afraid of getting too attached to an idea, or too motivated, or excited by an idea that I drift away from what I am actually supposed to be doing.

+ +

VICTORIA: Last question is, is there anything else you would like to promote?

+ +

SEIF: Yeah, check out our website; I think it's at axiom.co. Check it out. Sign up. And comment on Discord and talk to me. I don't bite, sometimes grumpy, but that's just because of lack of sleep in the morning. But, you know, around midday, I'm good. And if you're ever in Berlin and you want to hang out, I'm more than willing to hang out.

+ +

VICTORIA: Whoo, that's awesome. Yeah, Berlin is great. I was there a couple of years ago but no plans to go back anytime soon, but maybe I'll keep that in mind.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg.

+ +

And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Joe Ferris and Seif Lotfy.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Victoria is joined by guest co-host Joe Ferris, CTO at thoughtbot, and Seif Lotfy, the CTO and Co-Founder of Axiom. Seif discusses the journey, challenges, and strategies behind his data analytics and observability platform.

+ +

Seif, who has a background in robotics and was a 2008 Sony AIBO robotic soccer world champion, shares that Axiom pivoted from being a Datadog competitor to focusing on logs and event data. The company even built its own logs database to provide a cost-effective solution for large-scale analytics. Seif is driven by his passion for his team and the invaluable feedback from the community, emphasizing that sales validate the effectiveness of a product. The conversation also delves into Axiom's shift in focus towards developers to address their need for better and more affordable observability tools.

+ +

On the business front, Seif reveals the company's challenges in scaling across multiple domains without compromising its core offerings. He discusses the importance of internal values like moving with urgency and high velocity to guide the company's future. Furthermore, he touches on the challenges and strategies of open-sourcing projects and advises avoiding platforms like Reddit and Hacker News to maintain focus.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido, and with me today is Seif Lotfy, CTO and Co-Founder of Axiom, the best home for your event data. Seif, thank you for joining me.

+ +

SEIF: Hey, everybody. Thanks for having me. This is awesome. I love the name of the podcast, given that I used to compete in robotics.

+ +

VICTORIA: What? All right, we're going to have to talk about that. And I also want to introduce a guest co-host today. Since we're talking about cloud, and observability, and data, I invited Joe Ferris, thoughtbot CTO and Director of Development of our platform engineering team, Mission Control. Welcome, Joe. How are you?

+ +

JOE: Good, thanks. Good to be back again.

+ +

VICTORIA: Okay. I am excited to talk to you all about observability. But I need to go back to Seif's comment on competing with robots. Can you tell me a little bit more about what robots you've built in the past?

+ +

SEIF: I didn't build robots; I used to program them. Remember the Sony AIBOs, where Sony made these dog robots? And we would make them compete. There was an international competition where we made them play soccer, and they had to be completely autonomous. They only communicate via Bluetooth or via wireless protocols. And you only have the camera as your sensor as well as...a chest sensor throws the ball near you, and then yeah, you make them play football against each other, four versus four with a goalkeeper and everything. Just look it up: RoboCup AIBO. Look it up on YouTube. And I...2008 world champion with the German team.

+ +

VICTORIA: That sounds incredible. What kind of crowds are you drawing out for a robot soccer match? Is that a lot of people involved with that?

+ +

SEIF: You would be surprised how big the RoboCup competition is. It's ridiculous.

+ +

VICTORIA: I want to go. I'm ready. I want to, like, I'll look it up and find out when the next one is.

+ +

SEIF: No more Sony robots but other robots. Now, there's two-legged robots. So, they make them play as two-legged robots, much slower than four-legged robots, but works.

+ +

VICTORIA: Wait. So, the robots you were playing soccer with had four legs they were running around on?

+ +

SEIF: Yeah, they were dogs [laughter].

+ +

VICTORIA: That's awesome.

+ +

SEIF: We all get the same robot. It's just a competition on software, right? On a software level. And some other competitions within the RoboCup actually use...you build your own robot and stuff like that. But this one was...it's called the Standard League, where we all have a robot, and we have to program it.

+ +

JOE: And the standard robot was a dog.

+ +

SEIF: Yeah, I think back then...we're talking...it's been a long time. I think it started in 2001 or something. I think the competition started in 2001 or 2002. And I compete from 2006 to 2008. Robots back then were just, you know, simple.

+ +

VICTORIA: Robots today are way too complicated [laughs].

+ +

SEIF: Even AI is more complicated.

+ +

VICTORIA: That's right. Yeah, everything has gotten a lot more complicated [laughs]. I'm so curious how you went from being a world-champion robot dog soccer player [laughs] programmer [laughs] to where you are today with Axiom. Can you tell me a little bit more about your journey?

+ +

SEIF: The journey is interesting because it came from open source. I used to do open source on the side a lot–part of the GNOME Project. That's where I met Neil and the rest of my team, Mikkel Kamstrup, the whole crowd, basically. We worked on GNOME. We worked on Ubuntu. Like, most of them were working professionally on it. I was working for another company, but we worked on the same project.

+ +

We ended up at Xamarin, which was bought by Microsoft. And then we ended up doing Axiom. But we've been around each other professionally since 2009, most of us. It's like a little family. But how we ended up exactly in observability, I think it's just trying to fix pain points in my life.

+ +

VICTORIA: Yeah, I was reading through the docs on Axiom. And there's an interesting point you make about organizations having to choose between how much data they have and how much they want to spend on it. So, maybe you can tell me a little bit more about that pain point and what you really found in the early stages that you wanted to solve.

+ +

SEIF: So, the early stages of what we wanted to solve we were mainly dealing with...so, the early, early stage, we were actually trying to be a Datadog competitor, where we were going to be self-hosted. Eventually, we focused on logs because we found out that's what was a big problem for most people, just event data, not just metric but generally event data, so logs, traces, et cetera. We built out our own logs database completely from scratch.

+ +

And one of the things we stumbled upon was; basically, you have three things when it comes to logging, which is low cost, low latency, and large scale. That's what everybody wants. But you can't get all three of them; you can only get two of them. And we opted...like, we chose large scale and low cost. And when it comes to latency, we say it should be just fast enough, right? And that's where we focused on, and this is how we started building it. And with that, this is how we managed to stand out by just having way lower cost than anybody else in the industry and dealing with large scale.

+ +

VICTORIA: That's really interesting. And how did you approach making the ingestion pipeline for masses amount of data more efficient?

+ +

SEIF: Just make it coordination-free as possible, right? And get rid of Kafka because Kafka just, you know, drains your...it's where you throw in money. Like maintaining Kafka...it's like back then Elasticsearch, right? Elasticsearch was the biggest part of your infrastructure that would cost money. Now, it's also Kafka.

+ +

So, we found a way to have our own internal way of queueing things without having to rely on Kafka. As I said, we wrote everything from scratch to make it work. Like, every now and then, I think that we can spin this out of the company and make it a new product. But now, eyes on the prize, right?

+ +

JOE: It's interesting to hear that somebody who spent so much time in the open-source community ended up rolling their own solution to so many problems. Do you feel like you had some lessons learned from open source that led you to reject solutions like Kafka, or how did that journey go?

+ +

SEIF: I don't think I'm rejecting Kafka. The problem is how Kafka is built, right? Kafka is still...you have to set up all these servers. They have to communicate, et cetera, etcetera. They didn't build it in a way where it's stateless, and that's what we're trying to go to. We're trying to make things as stateless as possible. So, Kafka was never built for the cloud-native era. And you can't really rely on SQS or something like that because it won't deal with this high throughput.

+ +

So, that's why I said, like, we will sacrifice some latency, but at least the cost is low. So, if messages show after half a second or a second, I'm good. It doesn't have to be real-time for me. So, I had to write a couple of these things. But also, it doesn't mean that we reject open source. Like, we actually do like open source. We open-source a couple of libraries. We contribute back to open source, right? We needed a solution back then for that problem, and we couldn't find any. And maybe one day, open source will have, right?

+ +

JOE: Yeah. I was going to ask if you considered open-sourcing any of your high latency, high throughput solutions.

+ +

SEIF: Not high latency. You make it sound bad.

+ +

JOE: [laughs]

+ +

SEIF: You make it sound bad. It's, like, fast enough, right? I'm not going to compete on milliseconds because, also, I'm competing with ClickHouse. I don't want to compete with ClickHouse. ClickHouse is low latency and large scale, right? But then the cost is, you know, off the charts a bit sometimes.

+ +

I'm going the other route. Like, you know, it's fast enough. Like, how, you know, if it's under two, three seconds, everybody's happy, right? If the results come within two, three seconds, everybody is happy. If you're going to build a real-time trading system on top of it, I'll strongly advise against that. But if you're building, you know, you're looking at dashboards, you're more in the observability field, yeah, we're good.

+ +

VICTORIA: Yeah, I'm curious what you found, like, which customer personas that market really resonated with. Like, is there a particular, like, industry type where you're noticing they really want to lower their cost, and they're okay with this just fast enough latency?

+ +

SEIF: Honestly, with the current recession, everybody is okay with giving up some of the speed to reduce the money because I think it's not linear reduction. It's more exponential reduction at this point, right? You give up a second, and you're saving 30%. You give up two seconds, all of a sudden, you're saving 80%.

+ +

So, I'd say in the beginning, everybody thought they need everything to be very, very fast. And now they're realizing, you know, with limitations you have around your budget and spending, you're like, okay, I'm okay with the speed. And, again, we're not slow. I'm just saying people realize they don't need everything under a second. They're okay with waiting for two seconds.

+ +

VICTORIA: That totally resonates with me. And I'm curious if you can add maybe a non-technical or a real-life example of, like, how this impacts the operations of a company or organization, like, if you can give us, like, a business-y example of how this impacts how people work.

+ +

SEIF: I don't know how, like, how do people work on that? Nothing changed, really. They're still doing the, like...really nothing because...and that aspect is you run a query, and, again, as I said, you're not getting the result in a second. You're just waiting two seconds or three seconds, and it's there. So, nothing really changed. I think people can wait three seconds. And we're still like–when I say this, we're still faster than most others. We're just not as fast as people who are trying to compete on a millisecond level.

+ +

VICTORIA: Yeah, that's okay. Maybe I'll take it back even, like, a step further, right? Like, our audience is really sometimes just founders who almost have no formal technical training or background. So, when we talk about observability, sometimes people who work in DevOps and operations all understand it and kind of know why it's important [laughs] and what we're talking about. So, maybe you could, like, go back to --

+ +

SEIF: Oh, if you're asking about new types of people who've been using it --

+ +

VICTORIA: Yeah. Like, if you're going to explain to, like, a non-technical founder, like, why your product is important, or, like, how people in their organization might use it, what would you say?

+ +

SEIF: Oh, okay, if you put it like that. It's more of if you have data, timestamp data, and you want to run analytics on top of it, so that could be transactions, that could be web vitals, rather than count every time somebody visits, you have a timestamp. So, you can count, like, how many visitors visited the website and what, you know, all these kinds of things. That's where you want to use something like Axiom. That's outside the DevOps space, of course. And in DevOps space, there's so many other things you use Axiom for, but that's outside the DevOps space.

+ +

And we actually...we implemented as zero-config integration with Vercel that kind of went viral. And we were, for a while, the number one enterprise for self-integration because so many people were using it. So, Vercel users are usually not necessarily writing the most complex backends, but a lot of things are happening on the front-end side of things. And we would be giving them dashboards, automated dashboards about, you know, latencies, and how long a request took, and how long the response took, and the content type, and the status codes, et cetera, et cetera. And there's a huge user base around that.

+ +

VICTORIA: I like that. And it's something, for me, you know, as a managing director of our platform engineering team, I want to talk more to founders about. It's great that you put this product and this app out into the world. But how do you know that people are actually using it? How do you know that people, like, maybe, are they all quitting after the first day and not coming back to your app? Or maybe, like, the page isn't loading or, like, it's not working as they expected it to.

+ +

And, like, if you don't have anything observing what users are doing in your app, then it's going to be hard to show that you're getting any traction and know where you need to go in and make corrections and adjust.

+ +

SEIF: We have two ways of doing this. Right now, internally, we use our own tools to see, like, who is sending us data. We have a deployment that's monitoring production deployment. And we're just, you know, seeing how people are using it, how much data they're sending every day, who stopped sending data, who spiked in sending data sets, et cetera.

+ +

But we're using Mixpanel, and Dominic, our Head of Product, implemented a couple of key metrics to that for that specifically. So, we know, like, what's the average time until somebody starts going from building its own queries with the builder to writing APL, or how long it takes them from, you know, running two queries to five queries. And, you know, we just start measuring these things now. And it's been going...we've been growing healthy around that.

+ +

So, we tend to measure user interaction, but also, we tend to measure how much data is being sent. Because let's keep in mind, usually, people go in and check for things if there's a problem. So, if there's no problem, the user won't interact with us much unless there's a notification that kicks off. We also just check, like, how much data is being sent to us the whole time.

+ +

VICTORIA: That makes sense. Like, you can't just rely on, like, well, if it was broken, they would write a [chuckles], like, a question or something. So, how do you get those metrics and that data around their interactions? So, that's really interesting. So, I wonder if we can go back and talk about, you know, we already mentioned a little bit about, like, the early days of Axiom and how you got started. Was there anything that you found in the early discovery process that was surprising and made you pivot strategy?

+ +

SEIF: A couple of things. Basically, people don't really care about the tech as much as they care [inaudible 12:51] and the packaging, so that's something that we had to learn. And number two, continuous feedback. Continuous feedback changed the way we worked completely, right? And, you know, after that, we had a Slack channel, then we opened a Discord channel. And, like, this continuous feedback coming in just helps with iterating, helps us with prioritizing, et cetera. And that changed the way we actually developed product.

+ +

VICTORIA: You use Slack and Discord?

+ +

SEIF: No. No Slack anymore. We had a community Slack. We had a community [inaudible 13:19] Slack. Now, there's no community Slack. We only have a community Discord. And the community Slack is...sorry, internally, we use Slack, but there's a community Discord for the community.

+ +

JOE: But how do you keep that staffed? Is it, like, everybody is in the Discord during working hours? Is it somebody's job to watch out for community questions?

+ +

SEIF: I think everybody gets involved now just...and you can see it. If you go on our Discord, you will just see it. Just everyone just gets involved. I think just people are passionate about what they're doing. At least most people are involved on Discord, right? Because there's, like, Discord the help sections, and people are just asking questions and other people answering.

+ +

And now, we reached a point where people in the community start answering the questions for other people in the community. So, that's how we see it's starting to become a healthy community, et cetera. But that is one of my favorite things: when I see somebody from the community answering somebody else, that's a highlight for me. Actually, we hired somebody from that community because they were so active.

+ +

JOE: Yeah, I think one of the biggest signs that a product is healthy is when there's a healthy ecosystem building up around it.

+ +

SEIF: Yeah, and Discord reminds me of the old days of open sources like IRC, just with memes now. But because all of us come from the old IRC days, being on Discord and chatting around, et cetera, et cetera, just gives us this momentum back, gave us this momentum back, whereas Slack always felt a bit too businessy to me.

+ +

JOE: Slack is like IRC with emoji. Discord is IRC with memes.

+ +

SEIF: I would say Slack reminds me somehow of MSN Messenger, right?

+ +

JOE: I feel like there's a huge slam on MSN Messenger here.

+ +

SEIF: [laughs] What do you guys use internally, Slack or? I think you're using Slack, right? Or Teams. Don't tell me you're using Teams.

+ +

JOE: No, we're using Slack.

+ +

SEIF: Okay, good, because I shit talk. Like, there is this, I’ll sh*t talk here–when I start talking about Teams, so...I remember that one thing Google did once, and that failed miserably.

+ +

JOE: Google still has, like, seven active chat products.

+ +

SEIF: Like, I think every department or every, like, group of engineers just uses one of them internally. I'm not sure. Never got to that point. But hey, who am I to judge?

+ +

VICTORIA: I just feel like I end up using all of them, and then I'm just rotating between different tabs all day long. You maybe talked me into using Discord. I feel like I've been resisting it, but you got me with the memes.

+ +

SEIF: Yeah, it's definitely worth it. It's more entertaining. More noise, but more entertaining. You feel it's alive, whereas Slack is...also because there's no, like, history is forever. So, you always go back, and you're like, oh my God, what the hell is this?

+ +

VICTORIA: Yeah, I have, like, all of them. I'll do anything.

+ +

SEIF: They should be using Axiom in the background. Just send data to Axiom; we can keep your chat history.

+ +

VICTORIA: Yeah, maybe. I'm so curious because, you know, you mentioned something about how you realized that it didn't matter really how cool the tech was if the product packaging wasn't also appealing to people. Because you seem really excited about what you've built. So, I'm curious, so just tell us a little bit more about how you went about trying to, like, promote this thing you built. Or was, like, the continuous feedback really early on, or how did that all kind of come together?

+ +

SEIF: The continuous feedback helped us with performance, but actually getting people to sign up and pay money it started early on. But with Vercel, it kind of skyrocketed, right? And that's mostly because we went with the whole zero-config approach where it's just literally two clicks. And all of a sudden, Vercel is sending your data to Axiom, and that's it. We will create [inaudible 16:33].

+ +

And we worked very closely with Vercel to do this, to make this happen, which was awesome. Like, yeah, hats off to them. They were fantastic. And just two clicks, three clicks away, and all of a sudden, we created Axiom organization for you, the data set for you. And then we're sending it...and the data from Vercel is being forwarded to it. I think that packaging was so simple that it made people try it out quickly. And then, the experience of actually using Axiom was sticky, so they continued using it.

+ +

And then the price was so low because we give 500 gigs for free, right? You send us 500 gigs a month of logs for free, and we don't care. And you can start off here with one terabyte for 25 bucks. So, people just start signing up. Now, before that, it was five terabytes a month for $99, and then we changed the plan. But yeah, it was cheap enough, so people just start sending us more and more and more data eventually.

+ +

They weren't thinking...we changed the way people start thinking of “what am I going to send to Axiom” or “what am I going to send to my logs provider or log storage?” To how much more can I send? And I think that's what we wanted to reach. We wanted people to think, how much more can I send?

+ +

JOE: You mentioned latency and cost. I'm curious about...the other big challenge we've seen with observability platforms, including logs, is cardinality of labels. Was there anything you had to sacrifice upfront in terms of cardinality to manage either cost or volume?

+ +

SEIF: No, not really. Because the way we designed it was that we should be able to deal with high cardinality from scratch, right? I mean, there's open-source ways of doing, like, if you look at how, like, a column store, if you look at a column store and every dimension is its own column, it's just that becomes, like, you can limit on the amount of columns you're creating, but you should never limit on the amount of different values in a column could be.

+ +

So, if you're having something like stat tags, right? Let's say hosting, like, hostname should be a column, but then the different hostnames you have, we never limit that. So, the cardinality on a value is something that is unlimited for us, and we don't really see it in cost. It doesn't really hit us on cost. It reflects a bit on compression if you get into technical details of that because, you know, high cardinality means a lot of different data. So, compression is harder, but it's not repetitive.

+ +

But then if you look at, you know, oh, I want to send a lot of different types of fields, not values with fields, so you have hostname, and latency, and whatnot, et cetera, et cetera, yeah, that's where limitation starts because then they have...it's like you're going to a wide range of...and a wider dimension. But even that, we, yeah, we can deal with thousands at this point. And we realize, like, most people will not need more than three or four. It's like a Postgres table. You don't need more than 3,000 to 4000 columns; else, you know, you're doing a lot.

+ +

JOE: I think it's actually pretty compelling in terms of cost, though. Like, that's one of the things we've had to be most careful about in terms of containing cost for metrics and logs is, a lot of providers will...they'll either charge you based on the number of unique metric combinations or the performance suffers greatly. Like, we've used a lot of Prometheus-based solutions.

+ +

And so, when we're working with developers, even though they don't need more than, you know, a few dozen metric combinations most of the time, it's hard for people to think of what they need upfront. It's much easier after you deploy it to be able to query your data and slice it retroactively based on what you're seeing.

+ +

SEIF: That's the detail. When you say we're using Prometheus, a lot of the metrics tools out there are using, just like Prometheus, are using the Gorilla data structure. And the real data structure was never designed to deal with high cardinality labels. So, basically, to put it in a simple way, every combination of tags you send for metrics is its own file on disk. That's, like, the very simple way of explaining this. And then, when you're trying to search through everything, right? And you have a lot of these combinations. I actually have to get all these files from this conversion back together, you know, and then they're chunked, et cetera. So, it's a problem.

+ +

Generally, how metrics are doing it...most metrics products are using it, even VictoriaMetrics, et cetera. What they're doing is they're using either the Prometheus TSDB data structure, which is based on Gorilla. Influx was doing the same thing. They pivoted to using more and more like the ones we use, and Honeycomb uses, right? So, we might not be as fast on metrics side as these highly optimized. But then when it comes to high [inaudible 20:49], once we start dealing with high cardinality, we will be faster than those solutions. And that's on a very technical level.

+ +

JOE: That's pretty cool. I realize we're getting pretty technical here. Maybe it's worth defining cardinality for the audience.

+ +

SEIF: Defining cardinality to the...I mean, we just did that, right?

+ +

JOE: What do you think, Victoria? Do you know what cardinality is now? [laughs]

+ +

VICTORIA: All right. Now I'm like, do I know? I was like, I think I know what it means. Cardinality is, like, let's say you have a piece of data like an event or a transaction.

+ +

SEIF: It's like the distinct count on a property that gives you the cardinality of a property.

+ +

VICTORIA: Right. It's like how many pieces of information you have about that one event, basically, yeah.

+ +

JOE: But with some traditional metrics stores, it's easy to make mistakes. For example, you could have unbounded cardinality by including response time as one of the labels --

+ +

SEIF: Tags.

+ +

JOE: And then it's just going to --

+ +

SEIF: Oh, no, no. Let me give you a better one. I put in timestamp at some point in my life.

+ +

JOE: Yeah, I feel like everybody has done that one.

+ +

[laughter]

+ +

SEIF: I've put a system timestamp at some point in my life. There was the actual timestamp, and there was a system timestamp that I would put because I wanted to know when the...because I couldn't control the timestamp, and the only timestamp I had was a system timestamp. I would always add the actual timestamp of when that event actually happened into a metric, and yeah, that did not scale.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

VICTORIA: Yeah. I wonder if you could maybe share, like, a story about when it's gone wrong, and you've suddenly charged a lot of money [laughs] just to get information about what's happening in the system. Any, like, personal experiences with observability that kind of informed what you did with Axiom?

+ +

SEIF: Oof, I have a very bad one, like, a very, very bad one. I used to work for a company. We had to deploy Elasticsearch on Windows Servers, and it was US-East-1. So, just a combination of Elasticsearch back in 2013, 2014 together with Azure and Windows Server was not a good idea. So, you see where this is going, right?

+ +

JOE: I see where it's going.

+ +

SEIF: Eventually, we had, like, we get all these problems because we used Elasticsearch and Kibana as our, you know, observability platform to measure everything around the product we were building. And funny enough, it cost us more than actually maintaining the infrastructure of the product. But not just that, it also kept me up longer because most of the downtimes I would get were not because of the product going down. It's because my Elasticsearch cluster started going down, and there's reasons for that. Because back then, Microsoft Azure thought that it's okay for any VM to lose connection with the rest of the VMs for 30 seconds per day. And then, all of a sudden, you have Elasticsearch with a split-brain problem.

+ +

And there was a phase where I started getting alerted so much that back then, my partner threatened to leave me. So I bought a...what I think was a shock bracelet or a shock collar via Bluetooth, and I connected it to phone for any notification. And I bought that off Alibaba, by the way. And I would charge it at night, put it on my wrist, and go to sleep. And then, when alert happens, it will fully discharge the battery on me every time.

+ +

JOE: Okay, I have to admit, I did not see where that was going.

+ +

SEIF: Yeah, did that for a while; definitely did not save my relationship either. But eventually, that was the point where, you know, we started looking into other observability tools like Datadog, et cetera, et cetera, et cetera. And that's where the actual journey began, where we moved away from Elasticsearch and Kibana to look for something, okay, that we don't have to maintain ourselves and we can use, et cetera. So, it's not about the costs as much; it was just pain.

+ +

VICTORIA: Yeah, pain is a real pain point, actual physical [chuckles] and emotional pain point [laughter]. What, like, motivates you to keep going with Axiom and to keep, like, the wind in your sails to keep working on it?

+ +

SEIF: There's a couple of things. I love working with my team. So, honestly, I just wake up, and I compliment my team. I just love working with them. They're a lot of fun to work with. And they challenge me, and I challenge them back. And I upset them a lot. And they can't upset me, but I upset them. But I love working with them, and I love working with that team.

+ +

And the other thing is getting, like, having this constant feedback from customers just makes you want to do more and, you know, close sales, et cetera. It's interesting, like, how I'm a very technical person, and I'm more interested in sales because sales means your product works, the product, the technical parts, et cetera. Because if technically it's not working, you can't build a product on top of it. And if you're not selling it, then what's the point? You only sell when the product is good, more or less, unless you're Oracle.

+ +

VICTORIA: I had someone ask me about Oracle recently, actually. They're like, "Are you considering going back to it?" And I'm maybe a little allergic to it from having a federal consulting background [laughs]. But maybe they'll come back around. I don't know. We'll see.

+ +

SEIF: Did you sell your soul back then?

+ +

VICTORIA: You know, I feel like I just grew up in a place where that's what everyone did was all.

+ +

SEIF: It was Oracle, IBM, or HP back in the day.

+ +

VICTORIA: Yeah. Well, basically, when you're working on applications that were built in, like, the '80s, Oracle was, like, this hot, new database technology [laughs] that they just got five years ago. So, that's just, yeah, interesting.

+ +

SEIF: Although, from a database perspective, they did a lot of the innovations. A lot of first innovations could have come from Oracle. From a technical perspective, they're ridiculous. I'm not sure from a product perspective how good they are. But I know their sales team is so big, so huge. They don't care about the product anymore. They can still sell.

+ +

VICTORIA: I think, you know, everything in tech is cyclical. So, you know, if they have the right strategy and they're making some interesting changes over there, there's always a chance [laughs]. Certain use cases, I mean, I think that's the interesting point about working in technology is that you know, every company is a tech company. And so, there's just a lot of different types of people, personas, and use cases for different types of products. So, I wonder, you know, you kind of mentioned earlier that, like, everyone is interested in Axiom. But, you know, I don't know, are you narrowing the market? Or, like, how are you trying to kind of focus your messaging and your sales for Axiom?

+ +

SEIF: I'm trying to focus on developers. So, we're really trying to focus on developers because the experience around observability is crap. It's stupid expensive. Sorry for being straightforward, right? And that's what we're trying to change. And we're targeting developers mainly. We want developers to like us. And we'll find all these different types of developers who are using it, and that's the interesting thing.

+ +

And because of them, we start adding more and more features, like, you know, we added tracing, and now that enables, like, billions of events pushed through for, you know, again, for almost no money, again, $25 a month for a terabyte of data. And we're doing this with metrics next. And that's just to address the developers who have been giving us feedback and the market demand. I will sum it up, again, like, the experience is crap, and it's stupid expensive. I think that's the [inaudible 28:07] of observability is just that's how I would sum it up.

+ +

VICTORIA: If you could go back in time and talk to yourself when you were still a developer, now that you're CTO, what advice would you give yourself?

+ +

JOE: Besides avoiding shock collars.

+ +

VICTORIA: [laughs] Yes.

+ +

SEIF: Get people's feedback quickly so you know you're on the right track. I think that's very, very, very, very important. Don't just work in the dark, or don't go too long into stealth mode because, eventually, people catch up. Also, ship when you're 80% ready because 100% is too late. I think it's the same thing here.

+ +

JOE: Ship often and early.

+ +

SEIF: Yeah, even if it's not fully ready, it's still feedback.

+ +

VICTORIA: Ship often and early and talk to people [laughs]. Just, do you feel like, as a developer, did you have the skills you needed to be able to get the most out of those feedback and out of those conversations you were having with people around your product?

+ +

SEIF: I still don't think I'm good enough. You're just constantly learning, right? I just accepted I'm part of a team, and I have my contributions. But as an individual, I still don't think I know enough. I think there's more I need to learn at this point.

+ +

VICTORIA: I wonder, what questions do you have for me or Joe?

+ +

SEIF: How did you start your podcast, and why the name?

+ +

VICTORIA: Oh, man, I hope I can answer. So, the podcast was started...I think it's, like, we're actually about to be at our 500th Episode. So, I've only been a host for the last year. Maybe Joe even knows more than I do. But what I recall is that one person at thoughtbot thought it would be a great idea to start a podcast, and then they did it. And it seems like the whole company is obsessed with robots. I'm not really sure where that came from. There used to be a tiny robot in the office, is what I remember. And people started using that as, like, the mascot. And then, yeah, that's it, that's the whole thing.

+ +

SEIF: Was the robot doing anything useful or just being cute?

+ +

JOE: It was just cute, and it's hard to make a robot cute.

+ +

SEIF: Was it a real robot, or was it like a --

+ +

JOE: No, there was, at one point, a toy robot. The name...I actually forget the origin–origin of the name, but the name Giant Robots comes from our blog. So, we named the podcast the same as the blog: Giant Robots Smashing Into Other Giant Robots.

+ +

SEIF: Yes, it's called transformers.

+ +

VICTORIA: Yeah, I like it. It's, I mean, now I feel like --

+ +

SEIF: [laughs]

+ +

VICTORIA: We got to get more, like, robot dogs involved [laughs] in the podcast.

+ +

SEIF: Like, I wanted to add one thing when we talked about, you know, what gets me going. And I want to mention that I have a six-month-old son now. He definitely adds a lot of motivation for me to wake up in the morning and work. But he also makes me wake up regardless if I want to or not.

+ +

VICTORIA: Yeah, you said you had invented an alarm clock that never turns off. Never snoozes [laughs].

+ +

SEIF: Yes, absolutely.

+ +

VICTORIA: I have the same thing, but it's my dog. But he does snooze, actually. He'll just, like, get tired and go back to sleep [laughs].

+ +

SEIF: Oh, I have a question. Do dogs have a Tamagotchi phase? Because, like, my son, the first three months was like a Tamagotchi. It was easy to read him.

+ +

VICTORIA: Oh yeah, uh-huh.

+ +

SEIF: Noisy but easy.

+ +

VICTORIA: Yes, yes.

+ +

SEIF: Now, it's just like, yeah, I don't know, like, the last month he has opinions at six months. I think it's because I raised him in Europe. I should take him back to the Middle East [laughs]. No opinions.

+ +

VICTORIA: No, dogs totally have, like, a communication style, you know, I pretty much know what he, I mean, I can read his mind, obviously [laughs].

+ +

SEIF: Sure, but that's when they grow a bit. But what when they were very...when the dog was very young?

+ +

VICTORIA: Yeah, they, I mean, they also learn, like, your stuff, too. So, they, like, learn how to get you to do stuff or, like, I know she'll feed me if I'm sitting here [laughs].

+ +

SEIF: And how much is one dog year, seven years?

+ +

VICTORIA: Seven years.

+ +

SEIF: Seven years?

+ +

VICTORIA: Yeah, seven years?

+ +

SEIF: Yeah. So, basically, in one year, like, three months, he's already...in one month, he's, you know, seven months old. He's like, yeah.

+ +

VICTORIA: Yeah. In a year, they're, like, teenagers. And then, in two years, they're, like, full adults.

+ +

SEIF: Yeah. So, the first month is basically going through the first six months of a human being. So yeah, you pass...the first two days or three days are the Tamagotchi phase that I'm talking about.

+ +

VICTORIA: [chuckles] I read this book, and it was, like, to understand dogs, it's like, they're just like humans that are trying to, like, maximize the number of positive experiences that they have. So, like, if you think about that framing around all your interactions about, like, maybe you're trying to get your son to do something, you can be like, okay, how do I, like, I don't know, train him that good things happen when he does the things I want him to do? [laughs] That's kind of maybe manipulative but effective. So, you're not learning baby sign language? You're just, like, going off facial expressions?

+ +

SEIF: I started. I know how Mama looks like. I know how Dada looks like. I know how more looks like, slowly. And he already does this thing that I know that when he's uncomfortable, he starts opening and closing his hands. And when he's completely uncomfortable and basically that he needs to go sleep, he starts pulling his own hair.

+ +

VICTORIA: [laughs] I do the same thing [laughs].

+ +

SEIF: You pull your own hair when you go to sleep? I don't have that. I don't have hair.

+ +

VICTORIA: I think I do start, like, touching my head though, yeah [inaudible 33:04].

+ +

SEIF: Azure took the last bit of hair I had! Went away with Azure, Elasticsearch, and the shock collar.

+ +

VICTORIA: [laughs]

+ +

SEIF: I have none of them left. Absolutely nothing. I should sue Elasticsearch for this shit.

+ +

VICTORIA: [laughs] Let me know how that goes. Maybe there's more people who could join your lawsuit, you know, with a class action.

+ +

SEIF: [laughs] Yeah. Well, one thing I wanted to also just highlight is, right now, one of the things that also makes the company move forward is we realized that in a single domain, we proved ourselves very valuable to specific companies, right? So, that was a big, big thing, milestone for us. And now we're trying to move into a handful of domains and see which one of those work out the best for us. Does that make sense?

+ +

VICTORIA: Yeah. And I'm curious: what are the biggest challenges or hurdles that you associate with that?

+ +

SEIF: At this point, you don't want just feedback. You want constructive criticism. Like, you want to work with people who will criticize the applic...and you iterate with them based on this criticism, right? They're just not happy about you and trying to create design partners. So, for us, it was very important to have these small design partners who can work with us to actually prove ourselves as valuable in a single domain.

+ +

Right now, we need to find a way to scale this across several domains. And how do you do that without sacrificing? Like, how do you open into other domains without sacrificing the original domain you came from? So, there's a lot of things [inaudible 34:28]. And we are in the middle of this. Honestly, I Forrest Gumped my way through half of this, right? Like, I didn't know what I was doing. I had ideas. I think it's more of luck at this point. And I had luck. No, we did work. We did work a lot. We did sleepless nights and everything.

+ +

But I think, in the last three years, we became more mature and started thinking more about product. And as I said, like, our CEO, Neil, and Dominic, our head of product, are putting everything behind being a product-led organization, not just a tech-led organization.

+ +

VICTORIA: That's super interesting. I love to hear that that's the way you're thinking about it.

+ +

JOE: I was just curious what other domains you're looking at pushing into if you can say.

+ +

SEIF: So, we are going to start moving into ETL a bit more. We're trying to see how we can fit in specific ML scenarios. I can't say more about the other, though.

+ +

JOE: Do you think you'll take the same approaches in terms of value proposition, like, low cost, good enough latency?

+ +

SEIF: Yes, that's definitely one thing. But there's also...so, this is the values we're bringing to the customer. But also, now, our internal values are different. Now it's more of move with urgency and high velocity, as we said before, right? Think big, work small. The values in terms of values we're going to take to the customers it's the same ones. And maybe we'll add some more, but it's still going to be low-cost and large-scale. And, internally, we're just becoming more, excuse my French, agile. I hate that word so much. Should be good with Scrum.

+ +

VICTORIA: It's painful, but everyone knows what you're talking about [laughs], you know, like --

+ +

SEIF: See, I have opinions here about Scrum. I think Scrum should be only used in terms of iceScrum [inaudible 36:04], or something like that.

+ +

VICTORIA: Oh no [laughter]. Well, it's a Rugby term, right? Like, that's where it should probably stay.

+ +

SEIF: I did not know it's a rugby term.

+ +

VICTORIA: Yeah, so it should stay there, but --

+ +

SEIF: Yes [laughs].

+ +

VICTORIA: Yeah, I think it's interesting. Yeah, I like the being flexible. I like the just, like, continuous feedback and how you all have set up to, like, talk with your customers. Because you mentioned earlier that, like, you might open source some of your projects. And I'm just curious, like, what goes into that decision for you when you're going to do that? Like, what makes you think this project would be good for open source or when you think, actually, we need to, like, keep it?

+ +

SEIF: So, we open source libraries, right? We actually do that already. And some other big organizations use our libraries; even our competitors use our libraries, that we do. The whole product itself or at least a big part of the product, like database, I'm not sure we're going to open source that, at least not anytime soon. And if we open source, it's going to be at a point where the value-add it brings is nothing compared to how well our product is, right? So, if we can replace whatever's at the back with...the storage engine we have in the back with something else and the product doesn't get affected, that's when we open source it.

+ +

VICTORIA: That's interesting. That makes sense to me. But yeah, thank you for clarifying that. I just wanted to make sure to circle back. Since you have this big history in open source, yeah, I'm curious if you see...

+ +

SEIF: Burning me out?

+ +

VICTORIA: Burning you out, yeah [laughter]. Oh, that's a good question. Yeah, like, because, you know, we're about to be in October here. Do you have any advice or strategies as a maintainer for not getting burned out during the next couple of weeks besides, like, hide in a cave and without internet access [laughs]?

+ +

SEIF: Stay away from Reddit and Hacker News. That's my goal for October now because I'm always afraid of getting too attached to an idea, or too motivated, or excited by an idea that I drift away from what I am actually supposed to be doing.

+ +

VICTORIA: Last question is, is there anything else you would like to promote?

+ +

SEIF: Yeah, check out our website; I think it's at axiom.co. Check it out. Sign up. And comment on Discord and talk to me. I don't bite, sometimes grumpy, but that's just because of lack of sleep in the morning. But, you know, around midday, I'm good. And if you're ever in Berlin and you want to hang out, I'm more than willing to hang out.

+ +

VICTORIA: Whoo, that's awesome. Yeah, Berlin is great. I was there a couple of years ago but no plans to go back anytime soon, but maybe I'll keep that in mind.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg.

+ +

And this podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guests: Joe Ferris and Seif Lotfy.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kaIeUF9b + + ]]> + + Victoria Guido + Joe Ferris + Seif Lotfy + + + 496: SmartCert with Lonni Kieffer + https://podcast.thoughtbot.com/496 + 647ba476-42bc-4a11-8e63-1c7e723dda2f + Thu, 12 Oct 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Hosts Will Larry and Victoria Guido talk with Lonni Kieffer, Co-Founder and Chief Customer Officer at SmartCert. SmartCert's mission is to digitize and streamline the certificate transfer process in supply chains, mainly focusing on the aerospace industry. Lonni shares insights into the challenges of managing change within traditional industries, the importance of building a solid foundation of leadership and core values, and SmartCert's strategies for customer success and self-service. + +Lonni also shares the history of the company's growth and its focus on vendor accountability and internal processes to increase supply chain efficiency. SmartCert's platform offers features like document verification and digital signatures to facilitate accessible communication among teams. She discusses the role of their partner company, TechFabric, in building their MVP and how they've grown their internal team. She also highlights 2024 as a pivotal year for SmartCert, aiming for a global impact within the next five years. + +Regarding advice for aspiring entrepreneurs, Lonni emphasizes the importance of grit, flexibility, and a strong belief in one's mission. She also talks about the value of relationships in business growth and the critical role of sleep for effective functioning and decision-making. + 43:04 + no + + + Hosts Will Larry and Victoria Guido talk with Lonni Kieffer, Co-Founder and Chief Customer Officer at SmartCert. SmartCert's mission is to digitize and streamline the certificate transfer process in supply chains, mainly focusing on the aerospace industry. Lonni shares insights into the challenges of managing change within traditional industries, the importance of building a solid foundation of leadership and core values, and SmartCert's strategies for customer success and self-service. +Lonni also shares the history of the company's growth and its focus on vendor accountability and internal processes to increase supply chain efficiency. SmartCert's platform offers features like document verification and digital signatures to facilitate accessible communication among teams. She discusses the role of their partner company, TechFabric, in building their MVP and how they've grown their internal team. She also highlights 2024 as a pivotal year for SmartCert, aiming for a global impact within the next five years. +Regarding advice for aspiring entrepreneurs, Lonni emphasizes the importance of grit, flexibility, and a strong belief in one's mission. She also talks about the value of relationships in business growth and the critical role of sleep for effective functioning and decision-making. +SmartCert (https://www.smartcert.tech/) +TechFabric (https://techfabric.com/) +Follow SmartCert on LinkedIn (https://www.linkedin.com/company/aramid/) or X (https://twitter.com/smartcert_tech). +Follow Lonni Kieffer on LinkedIn (https://www.linkedin.com/in/lonnik/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with me today is Lonni Kieffer, Co-Founder and Chief Customer Officer at SmartCert, a universal cloud-based platform that simplifies every aspect of cert transfer. Lonni, thank you for joining me. +LONNI: Thanks so much for having me. I love what you guys do. And I'm excited to contribute to the conversation. +VICTORIA: Wonderful. Well, we like to warm up a little bit first before we dive into business topics. Anything exciting going on in your world, Will or Lonni? +LONNI: I'll let Will start. +WILL: It's funny because, with three small kids, I think we're finally starting to find our rhythm and our routine, so that's kind of exciting. I know it sounds boring, but when you have three small kids, routine, I feel like, is everything. We're starting to find that because a couple of weeks ago, my son had surgery. So, it threw all of our routines off and everything, and trying to help him get better and heal and everything. But now he's doing good. He's back running around, having fun. So yeah, getting back to that normal life it's exciting, and we're looking forward to it. +LONNI: That makes so much sense. And I'm glad you mentioned kids because [laughs] I was also going to talk about my three kids and the fact that I am headed down to a family weekend tomorrow to join two-thirds of my daughters for a fun activity. It usually involves some fun meals, grocery shopping to fill [laughs] small college dorm refrigerators. But the challenge that I have then...Will, you have the young ones, and I have the older ones that are definitely going to keep me on my toes. I don't know that I can keep up with college life so much. So, usually, this is really fun but also really exhausting [laughs]. +WILL: I promise you, they're looking forward to it, so don't underestimate what you're doing [laughs]. +LONNI: [chuckles] Yes, for sure. +VICTORIA: I'm going to feel bad with my update [laughs]. It's like, oh, I'm surfing. I think I was in a surf film yesterday on accident, which was pretty funny. And then I'm going to surf this afternoon and climb. Which you're talking about being on a routine and I just...I can't seem to get my routine of when I'm surfing or when I'm climbing figured out to the point where I just keep, like, exhausting myself trying to do both [laughs]. But that's what's going on in my world. But I am not quite on the kids and baby train yet. But it does sound fun. It sounds...it encompasses a lot. And then you get to just experience a different time of their life compared to what you're going through. +WILL: Yeah, don't feel bad talking about something else, and fun. Like, today, I signed up for a kickball league in my area. So, I'm looking forward to it. So, I have those activities also. That's a must, I feel. +LONNI: That's so true, any kind of outdoor time. Even just reading about all the statistics now about direct sunlight, I think it's so incredibly important to weave that into the day. So, Victoria, I give you mad props for having a full agenda of those [laughs] activities. +VICTORIA: That's good. I'm glad to hear you're having some fun, too, Will and Lonni, getting out there, getting outside in the sunshine while it's still here. Yeah, I appreciate that. So, I'm curious...you know, that's what humans do best, right? Like humans, we're supposed to be outside. We're supposed to be, like, enjoying the sunshine. We're not supposed to be managing paperwork every day [laughs]. So, could you tell me a little bit more about SmartCert and the mission behind the company? +LONNI: For sure. The paperwork side is truly sad. I was having a discussion with a customer yesterday, and they still receive 90% of the product certs as paper from their vendors. And if you imagine not only the time that it takes to use paper these days [laughs] but the cost associated with that, I think there's some painful statistics around the fact that companies spend on average almost $500 a day on paper and toner. +And, you know, our goal started three years ago when the founder, Lyndon Lattie, who had spent 20 years in manufacturing and distribution in aerospace, finally decided to quit his perfectly good job and really work on alleviating a lot of the bottlenecks and hurdles that's really prevalent in supply chains. Every little nut and bolt that goes into an aircraft requires a lot of documentation that provides traceability to acknowledge that these parts meet the standards that the industry holds that we all have confidence in. So, when there isn't a paper trail or documents go missing, things get very expensive and chaotic. +And what we're trying to do is really remove paper [laughs], the physical part of it, from the equation and use the cloud to not only receive documents from suppliers but store them and send them on to customers. So, we're not only speeding things up, but we're also checking the box on sustainability and helping a fairly antiquated industry move forward with innovation and technology. +WILL: I love that idea because I'm the type of person that I don't use journals or things like that or paper to-do lists because I lose them all. And I like to think I'm a fairly responsible person, and I still lose them all. I love having it on my phone because I know exactly where it's at. 9.9 times out of 10, I have my phone with me. So, when I think of an idea, I have it; I can do something on it. In your experience, I don't know if you have this number or if you can estimate how often does paper certifications go missing, do you think? +LONNI: We're talking to some big, big aerospace companies these days, and they have estimated on a daily basis that 80 to 100 shipments have paperwork problems. So, when you think about the sheer volume on a daily basis and the time that it requires to really enable teams to track down paperwork, sometimes you go to your vendor and ask for the documentation, and they have to go back in time because they don't have it. Those delays can halt manufacturing and certainly make a big impact on profitability and just the ability to do business. +VICTORIA: Right. And from my background working in the federal government space for a while, I have a sense of just how many rules and regulations a particular product might have applied to it. And thinking about, like, the aerospace where, like, down to the individual bolts and nuts have to have all the specifications and the documentation of, like, the size, and where it came from, and the materials. And if you lose that, then you can't...it's, like, you can't work, or you have to go back to a manufacturer. So, how does SmartCert start to solve that issue? +LONNI: One of the big things that we're focused on this year is making it easier to receive documents from suppliers. It's the one place that a lot of companies don't have control over. You could have a strong internal process. You could have a strong process for sending these documents to your customers, but you're still at the mercy of what your suppliers choose to do. +Our big focus this year is starting with vendor accountability and starting to be able to compile data around vendor performance with documents but also start to create a more standard receiving process. So, next month, we are launching a new feature where you could take an email or a digital document, even if you do have to scan it in from a supplier and add that all to your shared dashboard. +And the idea here is to create a strong internal process instead of being at the mercy of your vendors but also make things work faster once documents are received. Usually, that effort is pretty siloed, where there's one receiving team, the processing and review team. The quality team is waiting for the documents. When you start to give everyone access to documents as they're received, you certainly can see cutting down on the steps and fostering stronger communication among internal teams. +So, because you now have a good repository and time and date-stamped information, you can start to see the vendors that are costing you money, have the conversations ahead of contracts. There's a big focus on vendor scorecards and continuous improvement in the industry. So, our goal is to be able to provide that centralized repository where the data comes to life instead of multiple people receiving certs and processing certs. That's one big focus on the receiving side. +And then, from an internal perspective, we've built the tools in SmartCert that enable the teams, once the documents are received, to quickly search in the document, make sure that the information is included and accurate. If it is, they can digitally sign and approve it, which is a common next step. If there is information missing, they can reject those certs and kind of maintain the communication within the same platform instead of going into an email and waiting on when to provide updated documents. We're focused on, again, keeping the conversation within one platform. +And then, on the customer side, it's the same thing: the traceability, the visibility of sending documents. So many companies are at the mercy of customers losing paperwork or asking them to resend it. And those are the things that we've eliminated by providing dashboard-to-dashboard delivery and that centralized access. So, even if the buyer you work with is on vacation, your certs aren't sitting in an email inbox for the next five days, not being accessible to the rest of the team. So, those kinds of, I think, focuses on efficiency all the way through the process are where we really feel will make a big impact for every company, large and small. +WILL: So, I know in the past you started multiple companies, and then about four years ago, you started SmartCert. So, how was the beginning getting traction for SmartCert? And were there any benefits to being a founder in the past that helped you with SmartCert? +LONNI: I love that question. My efforts at entrepreneurship certainly help. You know, you recognize that the ball's in your court in every facet of the business, the hats that you have to wear across everything you do and want to accomplish. It helped provide a good foundation. SmartCert certainly is more daunting and bigger than my past experiences. But having a good understanding of the requirements around flexibility, a willingness to figure things out on the fly, and a real confidence in what we're doing and believing in is so important. +You know, we are working to convince hundreds of thousands of companies to finally move away from super manual processes. And I think you have to have a lot of confidence and belief in not only what you're doing but the impact that you can make in order for you to keep going. And recognize if you are a new product in a new category, the path to building growth is usually pretty difficult. +WILL: If there is someone who is thinking about starting a company, what advice would you give them? Because I know it's not easy to start a company. It's hard, let's just be honest, it's very hard. If you can give someone advice on, "Hey, take that next step, start it," what advice would you give them? +LONNI: Well, I think you have to have the grit to get through the bad days. It is an insane roller coaster. But, for me, I think there are so many books and advice, and formulas out there for starting a business. You know, we've read every single book out there. And I think intuition is such a big piece of the potential and success for a business. While formulas and successful companies and what they share and how they did it is really helpful, I think at the end of the day, there may be moments that give you pause because it doesn't align with your intuition. And I think you really have to pay attention to those. +So, we spent all of 2022 really working on the SaaS formula. We aligned our website and our conversations to fit those kinds of meetings and conversations. And it turns out because of the people we were talking to and the challenge with change management in this level of transition, the SaaS formula was not successful for us. We made a decision at the end of 2022 to move towards product-led growth, having about 1,000 companies. I hope that'll be next week—our big magic, fun, new milestone. +We're really looking to empower the companies who are already participating on the network to drive growth. Many of them are receiving certs from our paying customers and just starting to get familiar with a new way of doing business. But things last year didn't feel right. It was incredibly frustrating to go through those motions and not have the success and metrics that were expected. The piece about intuition and being bold enough and confident enough in why you're doing what you're doing to be able to pivot is crucial. +VICTORIA: So, you've talked to...or have over 1,000 customers. I wonder what was anything really surprising to you that you discovered in that process. +LONNI: I think for us...and it kind of lends itself to the conversations we were having last year. To us and to our early adopters, SmartCert was a no-brainer. People that were spending eight hours a day were now spending an hour a day on the same work but just doing it much faster, reducing a lot of human error and automating so much of it. So, when we did have the conversations and make, you know, the introductions to the industry and work to build awareness, it was very obvious that change management is a paralyzing [laughs] aspect. +And when technology is rearing its ugly head in the requirements for your business, the future of your business, I think for manufacturing and distribution, the timeline for a lot of that movement towards digital documents and working in the cloud was accelerated with COVID, with inflation. And all of a sudden, now there's companies who are leaping ahead and some that are falling behind. And it's now a requirement to prioritize more efficient processes simply because there's less people to do the work. And the companies who are taking advantage of innovation are really maximizing the opportunities to build their business, get more customers, and have more success. +WILL: I was looking at your team, and it looks like you brought on the head of technology, I think, in 2022. And so, I think it was you and your co-founder in the very early days. How was it as a founder to build a technical app and going through that process? How was that process for you? +LONNI: We were so lucky to partner with a local company in building out the MVP of SmartCert. They had an amazing team. They helped us bring to life a lot of Lyndon's ideas and also had a good background in supply chain. So, I always give props to TechFabric in Gilbert, Arizona, for giving us the opportunity to prove out the model. And that was then enabling us to get the funding and higher Mark who, I will say, every day I don't know how we became so lucky. +I think startup life is challenging in and of itself. But he really embraced the mission and the opportunity to rebuild SmartCert from the ground up for the scalability it requires but to also embrace the security aspects that are coming to the industry, those compliance requirements, and working alongside us. He's one of the few, I think, heads of technology that are involved in a lot of conversations with customers. And we are absolutely so lucky to be able to add him to our team and continue to evolve the platform in all the ways it needs to to accommodate what we're trying to achieve. +VICTORIA: Thank you for sharing that. I wonder, what does success really look like for you now, or six months from now, maybe even five years from now? +LONNI: It'll be three years that we have launched SmartCert in March. And when we think about, you know, what's the first thing to prove when you're a new product in a new market, and it's to prove that people are willing to pay to alleviate the pain. And I think we've done a good job doing that. It's building virality now, you know. As the industry is now expanding its use of SmartCert, more companies are participating. So, we've built a good foundation, which has allowed us to start working with some of the global aerospace companies, distributors, and contract manufacturers, and pilots. We're defining those opportunities now. +And I think 2024 will be a really big year for us to expand the features and the usage and adoption not only with additional supply chains but much more fast-paced growth with participating companies so that in five years, we could really look back and say, "We have really supported supply chains all over the world in working smarter, approaching sustainability with the right goals and processes to cut down on paper, and also be able to combat the challenges with labor shortages, apply technology in ways that are going to certainly make sense for them and for the future." +VICTORIA: I like that you tie in business goals with, like, big, dreamy goals, like, really reducing our impact on the planet and things like that. Because I think that's...you need to have something to come back to at the end of the day when you're working really hard in a startup like this. +LONNI: We had a really fun exercise, an internal exercise. So, our lead investor, TitletownTech, obviously has entrepreneurs in residence that we had the advantage of working with. We went through an exercise of really trying to articulate what is, like, the big, hairy goal? What is our mission? And our tagline is now taking the paper and the work out of paperwork so humans can do what they do best. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +WILL: You were talking about the exercise to figure out, like, where your company is going. I want to ask question, like, around your leadership and core values. Like, how important is it for you to set that foundation now for the next couple of years? Because it sounds like that's what you're doing. You're setting that foundation, and I heard you say it a couple of times, foundation. So, how important is it to set that foundation for the growth that you're expecting over the next couple of years? +LONNI: When you do have a product-led growth initiative, it means you need to provide as much self-service onboarding, and training tools, and resources as you can to make it easy for companies to move from their free account to a paid account and take advantage of all of the features and the functionality. +So, our goals right now are to eliminate hurdles that companies may feel in making the transition. Because we've had so many conversations over the past, I guess, almost three years, we're pretty articulate on being able to help with process changes. What are you doing now? Here's how SmartCert fits in. Are your goals on the supplier side or your internal organization? Is it with customers? And just help walk them down the path of making a transition so it doesn't feel like it's going to require months or years or tons of man-hours that just aren't available as people just try and get through the day. +So, from a foundational perspective, customer success is really now sales, marketing support. And those are the tools that I think will help companies have a clear path. We've learned that they really want to make very clear decisions. If I do this, what are the steps? So, we're providing clarity and a lot of good guidance that doesn't require a lot of man-hours on our side to be able to help turn free accounts into paid accounts and continue their expanded use of the platform. +VICTORIA: That's very cool. Do you have any questions for me or Will? +LONNI: So, you guys have a lot of conversations. I would love to hear what's really stood out in the last month or so. What's kind of resonated with you? Or what did you hear and apply in your life? +VICTORIA: I have a couple of answers. I mean, I've had a lot of really amazing guests on the show. It's hard to pick out any few that were really important or had some meaningful takeaways. I really liked Charity Majors when I asked her how the company is doing, and she's like, "Well, we haven't failed yet." [laughs] And just an interesting mentality of very humble and very just open to change and open to seeing, like, what's going to happen next. +And also, I think that Irina Nazarova talked about managing products versus managing open-source projects, and how that is different, and how it might influence your business differently, especially as a consulting company. So, I thought that was really interesting. +I always love having guests on the show and hearing about why they started what they're doing. And it's just really inspiring to hear people take a chance on an idea that they have, that they feel passionate about, and really put everything behind it. And, you know, most of the time, we're talking to people who have succeeded [chuckles]. A few guests we've had are just getting started in their journey, and it is still kind of unclear. And I really enjoy those conversations as well, where they're just still not really sure if it's going to work. So, that's been a little bit about my experience as a host on the show. +WILL: Yeah, I think I was going to go in a similar direction because I love talking to founders because it's just a different...almost like what you said, like, it's okay; go out there. Take that next step. It may hurt. It may be hard. It's not an easy path but go out there. You can do it. And it's not just for starting a company; for me, it's almost everyday life, like the hard things that come my way in life. Like, it's okay; I can do it. +So, I think it's very encouraging to hear founders and their mindset when they started companies and after, like, multiple years of where they're at. And, like, yeah, it was hard. It was not easy, but hey, I made it. Like, I'm on the other side of it. And we're doing great, or we're still in there just hanging out. So, I think, for me, it's being resilient. I think that's the big thing. +LONNI: I think you nailed it because real talk is survival. And if you aren't honest with yourself, it's not likely you're going to be able to survive. So, I think when you take stock of what you're trying to achieve, the road is super hard, or, like, everyone says, "Everyone would be doing it." But there's a reason, and there's intention there. +And there are so many entrepreneurs who have failed over time only to have more intelligence, experience to get it right at some point. So, I don't know that anything is linear these days. We get smarter and certainly savvier around topics that interest us. And if it drives you towards entrepreneurship, I salute you. It makes having three daughters feel like a spa treatment. +But I also know that I get excited about the other side of this. But our board reminds me that there's so much of this that feeds my soul. And it's hard to give that up when you do sell the company or move on because you're used to just being involved in all the things and being able to take advantage of the highs and come together during the lows. And that roller coaster is actually what everyone tells me I'm going to miss the most. I don't believe them yet. But [laughs] I think that they're probably right. +VICTORIA: I think maybe you'll have a nostalgia for it. But you'll enjoy your peacefulness as well. +LONNI: Yeah [laughs]. +VICTORIA: Hopefully. [laughs] You have to hope. Yeah, I wonder, you know, speaking about, like, having investors and going around trying to raise money for a product, did you receive any advice or suggestions that, looking back on, you were like, "Actually, that was completely not helpful; I'm glad I didn't take it"? +LONNI: There were many companies who declined to participate in conversations because we were not building SmartCert on blockchain. And some of them have come back around and asked, "Are your plans to include it?" And we've always felt not only does that require a huge leap...We're taking an industry from paper to digital, so if you want to layer blockchain on that, you're probably going to go nowhere really fast. Because I don't think there's anyone on this planet who can explain it well or really articulate the benefits when, in fact, you're sending paper in boxes. And, sure, there's the security element to that, but it's not really aligned with what blockchain is meant to do. +So, we kind of have a laugh now about those that pushed so hard for we will only fund if this is blockchain-enabled. And we're so glad we didn't do that [laughs]. +VICTORIA: Yeah, I mean, my understanding for, like, a blockchain, one good use case might be for, like, unique identities or something. Taking the more practical approach, sometimes I think people forget in technology that we're just...the future is here, but it's not evenly distributed. And there is paper being sent in boxes. And sometimes we can make a big impact, which is very simple solutions. But even simple solutions aren't simple to implement and make change happen. +So, I'm wondering if you have any advice for founders who are facing a big change management that they're trying to push through. What advice would you give them to kind of start making inroads into that? +LONNI: There are companies who make hundreds of millions of dollars helping [laughs] other companies through change management, and it's not lost on me that it's its own business. What we have really come to understand is you need to meet everyone where they're at. The tools that we've built are simple. You learn SmartCert in five minutes. It is how processes change that have been in place since the beginning of time for this company. +And I think when it comes down to it, there are plenty of business owners and C-suite executives that can say, "Yes, this makes sense. We're going to do it." But being voluntold as the user who needs to not only learn something new but move out of their comfort zone figure out how to learn while doing your job every day, those are the people that I really think is important to support. They're going to mean the success of the adoption. And they are the ones that deserve the cheerleading. +So, with change management, my advice would be is to think about every single person that this affects in the company, understand who is able to realize immediate benefits, whose are maybe more short-term once this is launched or as your customers adopt it. And then who benefits, and how do they benefit for the long-term? Because you sort of need to help them keep their eye on the prize to get through the steps, it's going to require to change the way they show up every day. +WILL: So, Victoria asked you about advice that you're glad that you didn't take. Was there any advice that you're like, "Wow, that was the best advice, and I am so glad that we did follow it"? +LONNI: Towards the end of last year when, we sort of accepted our fate that standard sales, SaaS sales, was not going to work for us. Lyndon, the founder and one of the members of our board, had a really great conversation around relationships, especially with these antiquated industries. And if you are new technology, the real key to winning business, sort of earning that street cred, being accepted as a thought leader, is to make relationships with people. +It is still a person-to-person decision that helped us prioritize attending regional conferences and industry conferences to meet people face to face as often as possible to build the trust and to be able to build the relationships that will help create the confidence in every company we talk to about moving forward but making sure that there's still a human element involved. +WILL: I love that advice. Yeah, it's interesting how many companies, I feel like, forget that, is that the people is the reason that your company exists. I don't know where I got it from, but someone told me it's three Ps that, like, what is kind of the foundation for your company. I think it's people, processes, and products. If you can nail those three things, like you will be successful majority of the time. And I thought that was very interesting. +LONNI: It's so true. Empowering people and accepting the challenges that they face, being real about what change means for them, being able to, you know, speak their language, and acknowledge what taking on new commitments and new processes means for them is going to be the way to be successful. +VICTORIA: And how does your balance feel between your life and your family, that you've mentioned, and working for this company trying to get it off the ground? +LONNI: There are times where I'm proud being able to show my daughters that you can do it all, but it's hard to do it all. I'm grateful to work from home because it does enable me to not only work in yoga pants all day but to have time for self-care. So, the endorphins at the gym are survival for me. Being able to find your people...I was so lucky to be a part of StartupAZ, which is a cohort here in Arizona of just about a dozen companies. And we got together on a monthly basis to talk through what's working, what's not working, sort of setting goals for ourselves but also commiserating. +Because I feel like being an entrepreneur can feel really isolating. I don't think there's many people that understand what this means on a daily basis. There's certainly a whole new language beyond that with tech founders. And it helped me feel seen in a way that I can't articulate or get from my friends. So, that was really important for me. +What I try and be really sensitive to is this is a grind, but I'm doing it on behalf of my family. So, prioritizing time, even if it's, well, you know what? I'm going to drive you to school because that means I get 10 minutes in the car one one-on-one with you. Those are the things that I think if you're going to have less time, find ways to make it more meaningful without screens and phones, and just connect to your people. That's been important to me. +There are days that I'm better at it. This week has not been great simply because we have some big deadlines. And I do still try and prioritize things like the gym simply because my brain works so much better with [chuckles] endorphins than without. So, you'll have parental guilt. But if you really remind yourself that you're showing up for the greater good and you're doing it for your people, then your people will still always be in the forefront. +WILL: Do you have any foreseeable hurdles coming up with SmartCert? +LONNI: This is a big year for us. We, as many tech companies, have worked really hard to extend our runway. The funding [chuckles] world, the milestones, and markers required for a Series A round have all changed a lot since we were funded. And I think the hurdles we face is to demonstrate enough of momentum, great outcomes with our pilots, with these larger companies, to be able to go back to our investors and expand the future with the funding we'll need to continue to scale. So, that's probably a consistent point of view for a lot of tech companies. +It's sort of that make-or-break year. But we feel pretty good about it certainly because of the changes we've made to the way we go to market, but also the features we released this year in support of these larger conversations and being able to bring on someone who's going to then have 2,400 of their suppliers join the network. So, there's a lot of potential, but there's also a lot at risk. +VICTORIA: Yeah. So, I'm curious how that process was when you decided to pivot and you decided to create some new features to meet what your customers were telling you. How did you go about getting the support you needed to build those features? +LONNI: One thing that I think we did okay at, but if I had to look back, I'd say we should have done more of, is talking to the companies represented on SmartCert, certainly our paid customers. But those conversations helped us prioritize the features that would enable them to work smarter, to reduce risk, to be more efficient, to grow in a way that's going to support and embrace technology as it's introduced to the industry. +So, when you think back to what can you learn, it should always be the people that are using your product. We have, in this year, created a lot of internal tools so that once you do receive documents, or if you're a manufacturer and you're generating documents, centralizing those for access among teams, and creating a really automated process to send those to customers was the focus. And the conversation now has moved, as I mentioned, to the supplier side. And that's one area where I think we have the greatest opportunity for growth simply because it is the one area of the business you have the least control over. +So, we've kind of come full circle with building the tools that make sense for those that are using it now and building a new path to participate on a network or create efficiencies by making standard processes. Even if your suppliers aren't participating on SmartCert, we are going to be launching the ability to take the documents, as I mentioned, and turn them into SmartCerts. That, to me, I think presents the greatest opportunity for us to really build a lot of momentum. +VICTORIA: I love that. And so, you have your own team of developers working on this. Are you working with, like, an outsourced team? Or how did you structure the type of technical skills you needed to bring into the team? +LONNI: Our partner company that built our MVP, TechFabric, is still connected with us. So, if we have integrations, their team usually assists us with those SmartCert integrations into things like ERPs and just legacy systems that our customers are using. What they helped us with is to kind of provide the ideal candidate framework based on their knowledge of not only where the platform needs to go but the requirements and capabilities it requires, and participated in interviews to help us build our internal team. So, without having leadership in technology, that was a huge win for us to have an advisor and a supporter to be able to have the conversations we weren't qualified to have in order to hire the right people. +VICTORIA: Gotcha. That makes sense. And maybe I missed this point earlier. But how did you meet them, or how did you find them? +LONNI: Well, the story is a good one. We're based in Gilbert, Arizona. And as we were exploring what the options were, obviously trying to prioritize local relationships and partnerships, we did a Google search and ended up just having great conversations and feeling very fortunate that they were in our backyard and still are a really strong partner. +VICTORIA: Oh, that makes sense. And having someone nearby, too, probably helps to just make it all feel a little cozier, so I love that. I love hearing about it and that they've helped you get to a place you want to be with the app. I'm so grateful to hear your story and hear more about what y'all are working on. Is there anything else that you would like to promote? +LONNI: It's always fun having these conversations because sometimes you forget, you know, you're stuck in the minutiae of the day-to-day. And I just appreciate being able to tell the story and be reminded of how far we've come. And certainly celebrate and challenge anyone else who's considering a [inaudible 41:24] at this to take it. +And if there's any advice that I would want to leave everyone with is to prioritize sleep [laughs] because it's the secret weapon. And I can tell that the days that I don't get enough, I don't think the way that I should. And it's almost like sleep is the new drug. And find any way possible, whether it's white noise, CBD, black-out shades, find your peace because sleep is your friend. +WILL: I totally agree with that. +[chuckles] +VICTORIA: Thank you so much for your time and for being here with us today. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you could find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +AD: +Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. +More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Lonni Kieffer. + + + Hosts Will Larry and Victoria Guido talk with Lonni Kieffer, Co-Founder and Chief Customer Officer at SmartCert. SmartCert's mission is to digitize and streamline the certificate transfer process in supply chains, mainly focusing on the aerospace industry. Lonni shares insights into the challenges of managing change within traditional industries, the importance of building a solid foundation of leadership and core values, and SmartCert's strategies for customer success and self-service.

+ +

Lonni also shares the history of the company's growth and its focus on vendor accountability and internal processes to increase supply chain efficiency. SmartCert's platform offers features like document verification and digital signatures to facilitate accessible communication among teams. She discusses the role of their partner company, TechFabric, in building their MVP and how they've grown their internal team. She also highlights 2024 as a pivotal year for SmartCert, aiming for a global impact within the next five years.

+ +

Regarding advice for aspiring entrepreneurs, Lonni emphasizes the importance of grit, flexibility, and a strong belief in one's mission. She also talks about the value of relationships in business growth and the critical role of sleep for effective functioning and decision-making.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Lonni Kieffer, Co-Founder and Chief Customer Officer at SmartCert, a universal cloud-based platform that simplifies every aspect of cert transfer. Lonni, thank you for joining me.

+ +

LONNI: Thanks so much for having me. I love what you guys do. And I'm excited to contribute to the conversation.

+ +

VICTORIA: Wonderful. Well, we like to warm up a little bit first before we dive into business topics. Anything exciting going on in your world, Will or Lonni?

+ +

LONNI: I'll let Will start.

+ +

WILL: It's funny because, with three small kids, I think we're finally starting to find our rhythm and our routine, so that's kind of exciting. I know it sounds boring, but when you have three small kids, routine, I feel like, is everything. We're starting to find that because a couple of weeks ago, my son had surgery. So, it threw all of our routines off and everything, and trying to help him get better and heal and everything. But now he's doing good. He's back running around, having fun. So yeah, getting back to that normal life it's exciting, and we're looking forward to it.

+ +

LONNI: That makes so much sense. And I'm glad you mentioned kids because [laughs] I was also going to talk about my three kids and the fact that I am headed down to a family weekend tomorrow to join two-thirds of my daughters for a fun activity. It usually involves some fun meals, grocery shopping to fill [laughs] small college dorm refrigerators. But the challenge that I have then...Will, you have the young ones, and I have the older ones that are definitely going to keep me on my toes. I don't know that I can keep up with college life so much. So, usually, this is really fun but also really exhausting [laughs].

+ +

WILL: I promise you, they're looking forward to it, so don't underestimate what you're doing [laughs].

+ +

LONNI: [chuckles] Yes, for sure.

+ +

VICTORIA: I'm going to feel bad with my update [laughs]. It's like, oh, I'm surfing. I think I was in a surf film yesterday on accident, which was pretty funny. And then I'm going to surf this afternoon and climb. Which you're talking about being on a routine and I just...I can't seem to get my routine of when I'm surfing or when I'm climbing figured out to the point where I just keep, like, exhausting myself trying to do both [laughs]. But that's what's going on in my world. But I am not quite on the kids and baby train yet. But it does sound fun. It sounds...it encompasses a lot. And then you get to just experience a different time of their life compared to what you're going through.

+ +

WILL: Yeah, don't feel bad talking about something else, and fun. Like, today, I signed up for a kickball league in my area. So, I'm looking forward to it. So, I have those activities also. That's a must, I feel.

+ +

LONNI: That's so true, any kind of outdoor time. Even just reading about all the statistics now about direct sunlight, I think it's so incredibly important to weave that into the day. So, Victoria, I give you mad props for having a full agenda of those [laughs] activities.

+ +

VICTORIA: That's good. I'm glad to hear you're having some fun, too, Will and Lonni, getting out there, getting outside in the sunshine while it's still here. Yeah, I appreciate that. So, I'm curious...you know, that's what humans do best, right? Like humans, we're supposed to be outside. We're supposed to be, like, enjoying the sunshine. We're not supposed to be managing paperwork every day [laughs]. So, could you tell me a little bit more about SmartCert and the mission behind the company?

+ +

LONNI: For sure. The paperwork side is truly sad. I was having a discussion with a customer yesterday, and they still receive 90% of the product certs as paper from their vendors. And if you imagine not only the time that it takes to use paper these days [laughs] but the cost associated with that, I think there's some painful statistics around the fact that companies spend on average almost $500 a day on paper and toner.

+ +

And, you know, our goal started three years ago when the founder, Lyndon Lattie, who had spent 20 years in manufacturing and distribution in aerospace, finally decided to quit his perfectly good job and really work on alleviating a lot of the bottlenecks and hurdles that's really prevalent in supply chains. Every little nut and bolt that goes into an aircraft requires a lot of documentation that provides traceability to acknowledge that these parts meet the standards that the industry holds that we all have confidence in. So, when there isn't a paper trail or documents go missing, things get very expensive and chaotic.

+ +

And what we're trying to do is really remove paper [laughs], the physical part of it, from the equation and use the cloud to not only receive documents from suppliers but store them and send them on to customers. So, we're not only speeding things up, but we're also checking the box on sustainability and helping a fairly antiquated industry move forward with innovation and technology.

+ +

WILL: I love that idea because I'm the type of person that I don't use journals or things like that or paper to-do lists because I lose them all. And I like to think I'm a fairly responsible person, and I still lose them all. I love having it on my phone because I know exactly where it's at. 9.9 times out of 10, I have my phone with me. So, when I think of an idea, I have it; I can do something on it. In your experience, I don't know if you have this number or if you can estimate how often does paper certifications go missing, do you think?

+ +

LONNI: We're talking to some big, big aerospace companies these days, and they have estimated on a daily basis that 80 to 100 shipments have paperwork problems. So, when you think about the sheer volume on a daily basis and the time that it requires to really enable teams to track down paperwork, sometimes you go to your vendor and ask for the documentation, and they have to go back in time because they don't have it. Those delays can halt manufacturing and certainly make a big impact on profitability and just the ability to do business.

+ +

VICTORIA: Right. And from my background working in the federal government space for a while, I have a sense of just how many rules and regulations a particular product might have applied to it. And thinking about, like, the aerospace where, like, down to the individual bolts and nuts have to have all the specifications and the documentation of, like, the size, and where it came from, and the materials. And if you lose that, then you can't...it's, like, you can't work, or you have to go back to a manufacturer. So, how does SmartCert start to solve that issue?

+ +

LONNI: One of the big things that we're focused on this year is making it easier to receive documents from suppliers. It's the one place that a lot of companies don't have control over. You could have a strong internal process. You could have a strong process for sending these documents to your customers, but you're still at the mercy of what your suppliers choose to do.

+ +

Our big focus this year is starting with vendor accountability and starting to be able to compile data around vendor performance with documents but also start to create a more standard receiving process. So, next month, we are launching a new feature where you could take an email or a digital document, even if you do have to scan it in from a supplier and add that all to your shared dashboard.

+ +

And the idea here is to create a strong internal process instead of being at the mercy of your vendors but also make things work faster once documents are received. Usually, that effort is pretty siloed, where there's one receiving team, the processing and review team. The quality team is waiting for the documents. When you start to give everyone access to documents as they're received, you certainly can see cutting down on the steps and fostering stronger communication among internal teams.

+ +

So, because you now have a good repository and time and date-stamped information, you can start to see the vendors that are costing you money, have the conversations ahead of contracts. There's a big focus on vendor scorecards and continuous improvement in the industry. So, our goal is to be able to provide that centralized repository where the data comes to life instead of multiple people receiving certs and processing certs. That's one big focus on the receiving side.

+ +

And then, from an internal perspective, we've built the tools in SmartCert that enable the teams, once the documents are received, to quickly search in the document, make sure that the information is included and accurate. If it is, they can digitally sign and approve it, which is a common next step. If there is information missing, they can reject those certs and kind of maintain the communication within the same platform instead of going into an email and waiting on when to provide updated documents. We're focused on, again, keeping the conversation within one platform.

+ +

And then, on the customer side, it's the same thing: the traceability, the visibility of sending documents. So many companies are at the mercy of customers losing paperwork or asking them to resend it. And those are the things that we've eliminated by providing dashboard-to-dashboard delivery and that centralized access. So, even if the buyer you work with is on vacation, your certs aren't sitting in an email inbox for the next five days, not being accessible to the rest of the team. So, those kinds of, I think, focuses on efficiency all the way through the process are where we really feel will make a big impact for every company, large and small.

+ +

WILL: So, I know in the past you started multiple companies, and then about four years ago, you started SmartCert. So, how was the beginning getting traction for SmartCert? And were there any benefits to being a founder in the past that helped you with SmartCert?

+ +

LONNI: I love that question. My efforts at entrepreneurship certainly help. You know, you recognize that the ball's in your court in every facet of the business, the hats that you have to wear across everything you do and want to accomplish. It helped provide a good foundation. SmartCert certainly is more daunting and bigger than my past experiences. But having a good understanding of the requirements around flexibility, a willingness to figure things out on the fly, and a real confidence in what we're doing and believing in is so important.

+ +

You know, we are working to convince hundreds of thousands of companies to finally move away from super manual processes. And I think you have to have a lot of confidence and belief in not only what you're doing but the impact that you can make in order for you to keep going. And recognize if you are a new product in a new category, the path to building growth is usually pretty difficult.

+ +

WILL: If there is someone who is thinking about starting a company, what advice would you give them? Because I know it's not easy to start a company. It's hard, let's just be honest, it's very hard. If you can give someone advice on, "Hey, take that next step, start it," what advice would you give them?

+ +

LONNI: Well, I think you have to have the grit to get through the bad days. It is an insane roller coaster. But, for me, I think there are so many books and advice, and formulas out there for starting a business. You know, we've read every single book out there. And I think intuition is such a big piece of the potential and success for a business. While formulas and successful companies and what they share and how they did it is really helpful, I think at the end of the day, there may be moments that give you pause because it doesn't align with your intuition. And I think you really have to pay attention to those.

+ +

So, we spent all of 2022 really working on the SaaS formula. We aligned our website and our conversations to fit those kinds of meetings and conversations. And it turns out because of the people we were talking to and the challenge with change management in this level of transition, the SaaS formula was not successful for us. We made a decision at the end of 2022 to move towards product-led growth, having about 1,000 companies. I hope that'll be next week—our big magic, fun, new milestone.

+ +

We're really looking to empower the companies who are already participating on the network to drive growth. Many of them are receiving certs from our paying customers and just starting to get familiar with a new way of doing business. But things last year didn't feel right. It was incredibly frustrating to go through those motions and not have the success and metrics that were expected. The piece about intuition and being bold enough and confident enough in why you're doing what you're doing to be able to pivot is crucial.

+ +

VICTORIA: So, you've talked to...or have over 1,000 customers. I wonder what was anything really surprising to you that you discovered in that process.

+ +

LONNI: I think for us...and it kind of lends itself to the conversations we were having last year. To us and to our early adopters, SmartCert was a no-brainer. People that were spending eight hours a day were now spending an hour a day on the same work but just doing it much faster, reducing a lot of human error and automating so much of it. So, when we did have the conversations and make, you know, the introductions to the industry and work to build awareness, it was very obvious that change management is a paralyzing [laughs] aspect.

+ +

And when technology is rearing its ugly head in the requirements for your business, the future of your business, I think for manufacturing and distribution, the timeline for a lot of that movement towards digital documents and working in the cloud was accelerated with COVID, with inflation. And all of a sudden, now there's companies who are leaping ahead and some that are falling behind. And it's now a requirement to prioritize more efficient processes simply because there's less people to do the work. And the companies who are taking advantage of innovation are really maximizing the opportunities to build their business, get more customers, and have more success.

+ +

WILL: I was looking at your team, and it looks like you brought on the head of technology, I think, in 2022. And so, I think it was you and your co-founder in the very early days. How was it as a founder to build a technical app and going through that process? How was that process for you?

+ +

LONNI: We were so lucky to partner with a local company in building out the MVP of SmartCert. They had an amazing team. They helped us bring to life a lot of Lyndon's ideas and also had a good background in supply chain. So, I always give props to TechFabric in Gilbert, Arizona, for giving us the opportunity to prove out the model. And that was then enabling us to get the funding and higher Mark who, I will say, every day I don't know how we became so lucky.

+ +

I think startup life is challenging in and of itself. But he really embraced the mission and the opportunity to rebuild SmartCert from the ground up for the scalability it requires but to also embrace the security aspects that are coming to the industry, those compliance requirements, and working alongside us. He's one of the few, I think, heads of technology that are involved in a lot of conversations with customers. And we are absolutely so lucky to be able to add him to our team and continue to evolve the platform in all the ways it needs to to accommodate what we're trying to achieve.

+ +

VICTORIA: Thank you for sharing that. I wonder, what does success really look like for you now, or six months from now, maybe even five years from now?

+ +

LONNI: It'll be three years that we have launched SmartCert in March. And when we think about, you know, what's the first thing to prove when you're a new product in a new market, and it's to prove that people are willing to pay to alleviate the pain. And I think we've done a good job doing that. It's building virality now, you know. As the industry is now expanding its use of SmartCert, more companies are participating. So, we've built a good foundation, which has allowed us to start working with some of the global aerospace companies, distributors, and contract manufacturers, and pilots. We're defining those opportunities now.

+ +

And I think 2024 will be a really big year for us to expand the features and the usage and adoption not only with additional supply chains but much more fast-paced growth with participating companies so that in five years, we could really look back and say, "We have really supported supply chains all over the world in working smarter, approaching sustainability with the right goals and processes to cut down on paper, and also be able to combat the challenges with labor shortages, apply technology in ways that are going to certainly make sense for them and for the future."

+ +

VICTORIA: I like that you tie in business goals with, like, big, dreamy goals, like, really reducing our impact on the planet and things like that. Because I think that's...you need to have something to come back to at the end of the day when you're working really hard in a startup like this.

+ +

LONNI: We had a really fun exercise, an internal exercise. So, our lead investor, TitletownTech, obviously has entrepreneurs in residence that we had the advantage of working with. We went through an exercise of really trying to articulate what is, like, the big, hairy goal? What is our mission? And our tagline is now taking the paper and the work out of paperwork so humans can do what they do best.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: You were talking about the exercise to figure out, like, where your company is going. I want to ask question, like, around your leadership and core values. Like, how important is it for you to set that foundation now for the next couple of years? Because it sounds like that's what you're doing. You're setting that foundation, and I heard you say it a couple of times, foundation. So, how important is it to set that foundation for the growth that you're expecting over the next couple of years?

+ +

LONNI: When you do have a product-led growth initiative, it means you need to provide as much self-service onboarding, and training tools, and resources as you can to make it easy for companies to move from their free account to a paid account and take advantage of all of the features and the functionality.

+ +

So, our goals right now are to eliminate hurdles that companies may feel in making the transition. Because we've had so many conversations over the past, I guess, almost three years, we're pretty articulate on being able to help with process changes. What are you doing now? Here's how SmartCert fits in. Are your goals on the supplier side or your internal organization? Is it with customers? And just help walk them down the path of making a transition so it doesn't feel like it's going to require months or years or tons of man-hours that just aren't available as people just try and get through the day.

+ +

So, from a foundational perspective, customer success is really now sales, marketing support. And those are the tools that I think will help companies have a clear path. We've learned that they really want to make very clear decisions. If I do this, what are the steps? So, we're providing clarity and a lot of good guidance that doesn't require a lot of man-hours on our side to be able to help turn free accounts into paid accounts and continue their expanded use of the platform.

+ +

VICTORIA: That's very cool. Do you have any questions for me or Will?

+ +

LONNI: So, you guys have a lot of conversations. I would love to hear what's really stood out in the last month or so. What's kind of resonated with you? Or what did you hear and apply in your life?

+ +

VICTORIA: I have a couple of answers. I mean, I've had a lot of really amazing guests on the show. It's hard to pick out any few that were really important or had some meaningful takeaways. I really liked Charity Majors when I asked her how the company is doing, and she's like, "Well, we haven't failed yet." [laughs] And just an interesting mentality of very humble and very just open to change and open to seeing, like, what's going to happen next.

+ +

And also, I think that Irina Nazarova talked about managing products versus managing open-source projects, and how that is different, and how it might influence your business differently, especially as a consulting company. So, I thought that was really interesting.

+ +

I always love having guests on the show and hearing about why they started what they're doing. And it's just really inspiring to hear people take a chance on an idea that they have, that they feel passionate about, and really put everything behind it. And, you know, most of the time, we're talking to people who have succeeded [chuckles]. A few guests we've had are just getting started in their journey, and it is still kind of unclear. And I really enjoy those conversations as well, where they're just still not really sure if it's going to work. So, that's been a little bit about my experience as a host on the show.

+ +

WILL: Yeah, I think I was going to go in a similar direction because I love talking to founders because it's just a different...almost like what you said, like, it's okay; go out there. Take that next step. It may hurt. It may be hard. It's not an easy path but go out there. You can do it. And it's not just for starting a company; for me, it's almost everyday life, like the hard things that come my way in life. Like, it's okay; I can do it.

+ +

So, I think it's very encouraging to hear founders and their mindset when they started companies and after, like, multiple years of where they're at. And, like, yeah, it was hard. It was not easy, but hey, I made it. Like, I'm on the other side of it. And we're doing great, or we're still in there just hanging out. So, I think, for me, it's being resilient. I think that's the big thing.

+ +

LONNI: I think you nailed it because real talk is survival. And if you aren't honest with yourself, it's not likely you're going to be able to survive. So, I think when you take stock of what you're trying to achieve, the road is super hard, or, like, everyone says, "Everyone would be doing it." But there's a reason, and there's intention there.

+ +

And there are so many entrepreneurs who have failed over time only to have more intelligence, experience to get it right at some point. So, I don't know that anything is linear these days. We get smarter and certainly savvier around topics that interest us. And if it drives you towards entrepreneurship, I salute you. It makes having three daughters feel like a spa treatment.

+ +

But I also know that I get excited about the other side of this. But our board reminds me that there's so much of this that feeds my soul. And it's hard to give that up when you do sell the company or move on because you're used to just being involved in all the things and being able to take advantage of the highs and come together during the lows. And that roller coaster is actually what everyone tells me I'm going to miss the most. I don't believe them yet. But [laughs] I think that they're probably right.

+ +

VICTORIA: I think maybe you'll have a nostalgia for it. But you'll enjoy your peacefulness as well.

+ +

LONNI: Yeah [laughs].

+ +

VICTORIA: Hopefully. [laughs] You have to hope. Yeah, I wonder, you know, speaking about, like, having investors and going around trying to raise money for a product, did you receive any advice or suggestions that, looking back on, you were like, "Actually, that was completely not helpful; I'm glad I didn't take it"?

+ +

LONNI: There were many companies who declined to participate in conversations because we were not building SmartCert on blockchain. And some of them have come back around and asked, "Are your plans to include it?" And we've always felt not only does that require a huge leap...We're taking an industry from paper to digital, so if you want to layer blockchain on that, you're probably going to go nowhere really fast. Because I don't think there's anyone on this planet who can explain it well or really articulate the benefits when, in fact, you're sending paper in boxes. And, sure, there's the security element to that, but it's not really aligned with what blockchain is meant to do.

+ +

So, we kind of have a laugh now about those that pushed so hard for we will only fund if this is blockchain-enabled. And we're so glad we didn't do that [laughs].

+ +

VICTORIA: Yeah, I mean, my understanding for, like, a blockchain, one good use case might be for, like, unique identities or something. Taking the more practical approach, sometimes I think people forget in technology that we're just...the future is here, but it's not evenly distributed. And there is paper being sent in boxes. And sometimes we can make a big impact, which is very simple solutions. But even simple solutions aren't simple to implement and make change happen.

+ +

So, I'm wondering if you have any advice for founders who are facing a big change management that they're trying to push through. What advice would you give them to kind of start making inroads into that?

+ +

LONNI: There are companies who make hundreds of millions of dollars helping [laughs] other companies through change management, and it's not lost on me that it's its own business. What we have really come to understand is you need to meet everyone where they're at. The tools that we've built are simple. You learn SmartCert in five minutes. It is how processes change that have been in place since the beginning of time for this company.

+ +

And I think when it comes down to it, there are plenty of business owners and C-suite executives that can say, "Yes, this makes sense. We're going to do it." But being voluntold as the user who needs to not only learn something new but move out of their comfort zone figure out how to learn while doing your job every day, those are the people that I really think is important to support. They're going to mean the success of the adoption. And they are the ones that deserve the cheerleading.

+ +

So, with change management, my advice would be is to think about every single person that this affects in the company, understand who is able to realize immediate benefits, whose are maybe more short-term once this is launched or as your customers adopt it. And then who benefits, and how do they benefit for the long-term? Because you sort of need to help them keep their eye on the prize to get through the steps, it's going to require to change the way they show up every day.

+ +

WILL: So, Victoria asked you about advice that you're glad that you didn't take. Was there any advice that you're like, "Wow, that was the best advice, and I am so glad that we did follow it"?

+ +

LONNI: Towards the end of last year when, we sort of accepted our fate that standard sales, SaaS sales, was not going to work for us. Lyndon, the founder and one of the members of our board, had a really great conversation around relationships, especially with these antiquated industries. And if you are new technology, the real key to winning business, sort of earning that street cred, being accepted as a thought leader, is to make relationships with people.

+ +

It is still a person-to-person decision that helped us prioritize attending regional conferences and industry conferences to meet people face to face as often as possible to build the trust and to be able to build the relationships that will help create the confidence in every company we talk to about moving forward but making sure that there's still a human element involved.

+ +

WILL: I love that advice. Yeah, it's interesting how many companies, I feel like, forget that, is that the people is the reason that your company exists. I don't know where I got it from, but someone told me it's three Ps that, like, what is kind of the foundation for your company. I think it's people, processes, and products. If you can nail those three things, like you will be successful majority of the time. And I thought that was very interesting.

+ +

LONNI: It's so true. Empowering people and accepting the challenges that they face, being real about what change means for them, being able to, you know, speak their language, and acknowledge what taking on new commitments and new processes means for them is going to be the way to be successful.

+ +

VICTORIA: And how does your balance feel between your life and your family, that you've mentioned, and working for this company trying to get it off the ground?

+ +

LONNI: There are times where I'm proud being able to show my daughters that you can do it all, but it's hard to do it all. I'm grateful to work from home because it does enable me to not only work in yoga pants all day but to have time for self-care. So, the endorphins at the gym are survival for me. Being able to find your people...I was so lucky to be a part of StartupAZ, which is a cohort here in Arizona of just about a dozen companies. And we got together on a monthly basis to talk through what's working, what's not working, sort of setting goals for ourselves but also commiserating.

+ +

Because I feel like being an entrepreneur can feel really isolating. I don't think there's many people that understand what this means on a daily basis. There's certainly a whole new language beyond that with tech founders. And it helped me feel seen in a way that I can't articulate or get from my friends. So, that was really important for me.

+ +

What I try and be really sensitive to is this is a grind, but I'm doing it on behalf of my family. So, prioritizing time, even if it's, well, you know what? I'm going to drive you to school because that means I get 10 minutes in the car one one-on-one with you. Those are the things that I think if you're going to have less time, find ways to make it more meaningful without screens and phones, and just connect to your people. That's been important to me.

+ +

There are days that I'm better at it. This week has not been great simply because we have some big deadlines. And I do still try and prioritize things like the gym simply because my brain works so much better with [chuckles] endorphins than without. So, you'll have parental guilt. But if you really remind yourself that you're showing up for the greater good and you're doing it for your people, then your people will still always be in the forefront.

+ +

WILL: Do you have any foreseeable hurdles coming up with SmartCert?

+ +

LONNI: This is a big year for us. We, as many tech companies, have worked really hard to extend our runway. The funding [chuckles] world, the milestones, and markers required for a Series A round have all changed a lot since we were funded. And I think the hurdles we face is to demonstrate enough of momentum, great outcomes with our pilots, with these larger companies, to be able to go back to our investors and expand the future with the funding we'll need to continue to scale. So, that's probably a consistent point of view for a lot of tech companies.

+ +

It's sort of that make-or-break year. But we feel pretty good about it certainly because of the changes we've made to the way we go to market, but also the features we released this year in support of these larger conversations and being able to bring on someone who's going to then have 2,400 of their suppliers join the network. So, there's a lot of potential, but there's also a lot at risk.

+ +

VICTORIA: Yeah. So, I'm curious how that process was when you decided to pivot and you decided to create some new features to meet what your customers were telling you. How did you go about getting the support you needed to build those features?

+ +

LONNI: One thing that I think we did okay at, but if I had to look back, I'd say we should have done more of, is talking to the companies represented on SmartCert, certainly our paid customers. But those conversations helped us prioritize the features that would enable them to work smarter, to reduce risk, to be more efficient, to grow in a way that's going to support and embrace technology as it's introduced to the industry.

+ +

So, when you think back to what can you learn, it should always be the people that are using your product. We have, in this year, created a lot of internal tools so that once you do receive documents, or if you're a manufacturer and you're generating documents, centralizing those for access among teams, and creating a really automated process to send those to customers was the focus. And the conversation now has moved, as I mentioned, to the supplier side. And that's one area where I think we have the greatest opportunity for growth simply because it is the one area of the business you have the least control over.

+ +

So, we've kind of come full circle with building the tools that make sense for those that are using it now and building a new path to participate on a network or create efficiencies by making standard processes. Even if your suppliers aren't participating on SmartCert, we are going to be launching the ability to take the documents, as I mentioned, and turn them into SmartCerts. That, to me, I think presents the greatest opportunity for us to really build a lot of momentum.

+ +

VICTORIA: I love that. And so, you have your own team of developers working on this. Are you working with, like, an outsourced team? Or how did you structure the type of technical skills you needed to bring into the team?

+ +

LONNI: Our partner company that built our MVP, TechFabric, is still connected with us. So, if we have integrations, their team usually assists us with those SmartCert integrations into things like ERPs and just legacy systems that our customers are using. What they helped us with is to kind of provide the ideal candidate framework based on their knowledge of not only where the platform needs to go but the requirements and capabilities it requires, and participated in interviews to help us build our internal team. So, without having leadership in technology, that was a huge win for us to have an advisor and a supporter to be able to have the conversations we weren't qualified to have in order to hire the right people.

+ +

VICTORIA: Gotcha. That makes sense. And maybe I missed this point earlier. But how did you meet them, or how did you find them?

+ +

LONNI: Well, the story is a good one. We're based in Gilbert, Arizona. And as we were exploring what the options were, obviously trying to prioritize local relationships and partnerships, we did a Google search and ended up just having great conversations and feeling very fortunate that they were in our backyard and still are a really strong partner.

+ +

VICTORIA: Oh, that makes sense. And having someone nearby, too, probably helps to just make it all feel a little cozier, so I love that. I love hearing about it and that they've helped you get to a place you want to be with the app. I'm so grateful to hear your story and hear more about what y'all are working on. Is there anything else that you would like to promote?

+ +

LONNI: It's always fun having these conversations because sometimes you forget, you know, you're stuck in the minutiae of the day-to-day. And I just appreciate being able to tell the story and be reminded of how far we've come. And certainly celebrate and challenge anyone else who's considering a [inaudible 41:24] at this to take it.

+ +

And if there's any advice that I would want to leave everyone with is to prioritize sleep [laughs] because it's the secret weapon. And I can tell that the days that I don't get enough, I don't think the way that I should. And it's almost like sleep is the new drug. And find any way possible, whether it's white noise, CBD, black-out shades, find your peace because sleep is your friend.

+ +

WILL: I totally agree with that.

+ +

[chuckles]

+ +

VICTORIA: Thank you so much for your time and for being here with us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Lonni Kieffer.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hosts Will Larry and Victoria Guido talk with Lonni Kieffer, Co-Founder and Chief Customer Officer at SmartCert. SmartCert's mission is to digitize and streamline the certificate transfer process in supply chains, mainly focusing on the aerospace industry. Lonni shares insights into the challenges of managing change within traditional industries, the importance of building a solid foundation of leadership and core values, and SmartCert's strategies for customer success and self-service.

+ +

Lonni also shares the history of the company's growth and its focus on vendor accountability and internal processes to increase supply chain efficiency. SmartCert's platform offers features like document verification and digital signatures to facilitate accessible communication among teams. She discusses the role of their partner company, TechFabric, in building their MVP and how they've grown their internal team. She also highlights 2024 as a pivotal year for SmartCert, aiming for a global impact within the next five years.

+ +

Regarding advice for aspiring entrepreneurs, Lonni emphasizes the importance of grit, flexibility, and a strong belief in one's mission. She also talks about the value of relationships in business growth and the critical role of sleep for effective functioning and decision-making.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Lonni Kieffer, Co-Founder and Chief Customer Officer at SmartCert, a universal cloud-based platform that simplifies every aspect of cert transfer. Lonni, thank you for joining me.

+ +

LONNI: Thanks so much for having me. I love what you guys do. And I'm excited to contribute to the conversation.

+ +

VICTORIA: Wonderful. Well, we like to warm up a little bit first before we dive into business topics. Anything exciting going on in your world, Will or Lonni?

+ +

LONNI: I'll let Will start.

+ +

WILL: It's funny because, with three small kids, I think we're finally starting to find our rhythm and our routine, so that's kind of exciting. I know it sounds boring, but when you have three small kids, routine, I feel like, is everything. We're starting to find that because a couple of weeks ago, my son had surgery. So, it threw all of our routines off and everything, and trying to help him get better and heal and everything. But now he's doing good. He's back running around, having fun. So yeah, getting back to that normal life it's exciting, and we're looking forward to it.

+ +

LONNI: That makes so much sense. And I'm glad you mentioned kids because [laughs] I was also going to talk about my three kids and the fact that I am headed down to a family weekend tomorrow to join two-thirds of my daughters for a fun activity. It usually involves some fun meals, grocery shopping to fill [laughs] small college dorm refrigerators. But the challenge that I have then...Will, you have the young ones, and I have the older ones that are definitely going to keep me on my toes. I don't know that I can keep up with college life so much. So, usually, this is really fun but also really exhausting [laughs].

+ +

WILL: I promise you, they're looking forward to it, so don't underestimate what you're doing [laughs].

+ +

LONNI: [chuckles] Yes, for sure.

+ +

VICTORIA: I'm going to feel bad with my update [laughs]. It's like, oh, I'm surfing. I think I was in a surf film yesterday on accident, which was pretty funny. And then I'm going to surf this afternoon and climb. Which you're talking about being on a routine and I just...I can't seem to get my routine of when I'm surfing or when I'm climbing figured out to the point where I just keep, like, exhausting myself trying to do both [laughs]. But that's what's going on in my world. But I am not quite on the kids and baby train yet. But it does sound fun. It sounds...it encompasses a lot. And then you get to just experience a different time of their life compared to what you're going through.

+ +

WILL: Yeah, don't feel bad talking about something else, and fun. Like, today, I signed up for a kickball league in my area. So, I'm looking forward to it. So, I have those activities also. That's a must, I feel.

+ +

LONNI: That's so true, any kind of outdoor time. Even just reading about all the statistics now about direct sunlight, I think it's so incredibly important to weave that into the day. So, Victoria, I give you mad props for having a full agenda of those [laughs] activities.

+ +

VICTORIA: That's good. I'm glad to hear you're having some fun, too, Will and Lonni, getting out there, getting outside in the sunshine while it's still here. Yeah, I appreciate that. So, I'm curious...you know, that's what humans do best, right? Like humans, we're supposed to be outside. We're supposed to be, like, enjoying the sunshine. We're not supposed to be managing paperwork every day [laughs]. So, could you tell me a little bit more about SmartCert and the mission behind the company?

+ +

LONNI: For sure. The paperwork side is truly sad. I was having a discussion with a customer yesterday, and they still receive 90% of the product certs as paper from their vendors. And if you imagine not only the time that it takes to use paper these days [laughs] but the cost associated with that, I think there's some painful statistics around the fact that companies spend on average almost $500 a day on paper and toner.

+ +

And, you know, our goal started three years ago when the founder, Lyndon Lattie, who had spent 20 years in manufacturing and distribution in aerospace, finally decided to quit his perfectly good job and really work on alleviating a lot of the bottlenecks and hurdles that's really prevalent in supply chains. Every little nut and bolt that goes into an aircraft requires a lot of documentation that provides traceability to acknowledge that these parts meet the standards that the industry holds that we all have confidence in. So, when there isn't a paper trail or documents go missing, things get very expensive and chaotic.

+ +

And what we're trying to do is really remove paper [laughs], the physical part of it, from the equation and use the cloud to not only receive documents from suppliers but store them and send them on to customers. So, we're not only speeding things up, but we're also checking the box on sustainability and helping a fairly antiquated industry move forward with innovation and technology.

+ +

WILL: I love that idea because I'm the type of person that I don't use journals or things like that or paper to-do lists because I lose them all. And I like to think I'm a fairly responsible person, and I still lose them all. I love having it on my phone because I know exactly where it's at. 9.9 times out of 10, I have my phone with me. So, when I think of an idea, I have it; I can do something on it. In your experience, I don't know if you have this number or if you can estimate how often does paper certifications go missing, do you think?

+ +

LONNI: We're talking to some big, big aerospace companies these days, and they have estimated on a daily basis that 80 to 100 shipments have paperwork problems. So, when you think about the sheer volume on a daily basis and the time that it requires to really enable teams to track down paperwork, sometimes you go to your vendor and ask for the documentation, and they have to go back in time because they don't have it. Those delays can halt manufacturing and certainly make a big impact on profitability and just the ability to do business.

+ +

VICTORIA: Right. And from my background working in the federal government space for a while, I have a sense of just how many rules and regulations a particular product might have applied to it. And thinking about, like, the aerospace where, like, down to the individual bolts and nuts have to have all the specifications and the documentation of, like, the size, and where it came from, and the materials. And if you lose that, then you can't...it's, like, you can't work, or you have to go back to a manufacturer. So, how does SmartCert start to solve that issue?

+ +

LONNI: One of the big things that we're focused on this year is making it easier to receive documents from suppliers. It's the one place that a lot of companies don't have control over. You could have a strong internal process. You could have a strong process for sending these documents to your customers, but you're still at the mercy of what your suppliers choose to do.

+ +

Our big focus this year is starting with vendor accountability and starting to be able to compile data around vendor performance with documents but also start to create a more standard receiving process. So, next month, we are launching a new feature where you could take an email or a digital document, even if you do have to scan it in from a supplier and add that all to your shared dashboard.

+ +

And the idea here is to create a strong internal process instead of being at the mercy of your vendors but also make things work faster once documents are received. Usually, that effort is pretty siloed, where there's one receiving team, the processing and review team. The quality team is waiting for the documents. When you start to give everyone access to documents as they're received, you certainly can see cutting down on the steps and fostering stronger communication among internal teams.

+ +

So, because you now have a good repository and time and date-stamped information, you can start to see the vendors that are costing you money, have the conversations ahead of contracts. There's a big focus on vendor scorecards and continuous improvement in the industry. So, our goal is to be able to provide that centralized repository where the data comes to life instead of multiple people receiving certs and processing certs. That's one big focus on the receiving side.

+ +

And then, from an internal perspective, we've built the tools in SmartCert that enable the teams, once the documents are received, to quickly search in the document, make sure that the information is included and accurate. If it is, they can digitally sign and approve it, which is a common next step. If there is information missing, they can reject those certs and kind of maintain the communication within the same platform instead of going into an email and waiting on when to provide updated documents. We're focused on, again, keeping the conversation within one platform.

+ +

And then, on the customer side, it's the same thing: the traceability, the visibility of sending documents. So many companies are at the mercy of customers losing paperwork or asking them to resend it. And those are the things that we've eliminated by providing dashboard-to-dashboard delivery and that centralized access. So, even if the buyer you work with is on vacation, your certs aren't sitting in an email inbox for the next five days, not being accessible to the rest of the team. So, those kinds of, I think, focuses on efficiency all the way through the process are where we really feel will make a big impact for every company, large and small.

+ +

WILL: So, I know in the past you started multiple companies, and then about four years ago, you started SmartCert. So, how was the beginning getting traction for SmartCert? And were there any benefits to being a founder in the past that helped you with SmartCert?

+ +

LONNI: I love that question. My efforts at entrepreneurship certainly help. You know, you recognize that the ball's in your court in every facet of the business, the hats that you have to wear across everything you do and want to accomplish. It helped provide a good foundation. SmartCert certainly is more daunting and bigger than my past experiences. But having a good understanding of the requirements around flexibility, a willingness to figure things out on the fly, and a real confidence in what we're doing and believing in is so important.

+ +

You know, we are working to convince hundreds of thousands of companies to finally move away from super manual processes. And I think you have to have a lot of confidence and belief in not only what you're doing but the impact that you can make in order for you to keep going. And recognize if you are a new product in a new category, the path to building growth is usually pretty difficult.

+ +

WILL: If there is someone who is thinking about starting a company, what advice would you give them? Because I know it's not easy to start a company. It's hard, let's just be honest, it's very hard. If you can give someone advice on, "Hey, take that next step, start it," what advice would you give them?

+ +

LONNI: Well, I think you have to have the grit to get through the bad days. It is an insane roller coaster. But, for me, I think there are so many books and advice, and formulas out there for starting a business. You know, we've read every single book out there. And I think intuition is such a big piece of the potential and success for a business. While formulas and successful companies and what they share and how they did it is really helpful, I think at the end of the day, there may be moments that give you pause because it doesn't align with your intuition. And I think you really have to pay attention to those.

+ +

So, we spent all of 2022 really working on the SaaS formula. We aligned our website and our conversations to fit those kinds of meetings and conversations. And it turns out because of the people we were talking to and the challenge with change management in this level of transition, the SaaS formula was not successful for us. We made a decision at the end of 2022 to move towards product-led growth, having about 1,000 companies. I hope that'll be next week—our big magic, fun, new milestone.

+ +

We're really looking to empower the companies who are already participating on the network to drive growth. Many of them are receiving certs from our paying customers and just starting to get familiar with a new way of doing business. But things last year didn't feel right. It was incredibly frustrating to go through those motions and not have the success and metrics that were expected. The piece about intuition and being bold enough and confident enough in why you're doing what you're doing to be able to pivot is crucial.

+ +

VICTORIA: So, you've talked to...or have over 1,000 customers. I wonder what was anything really surprising to you that you discovered in that process.

+ +

LONNI: I think for us...and it kind of lends itself to the conversations we were having last year. To us and to our early adopters, SmartCert was a no-brainer. People that were spending eight hours a day were now spending an hour a day on the same work but just doing it much faster, reducing a lot of human error and automating so much of it. So, when we did have the conversations and make, you know, the introductions to the industry and work to build awareness, it was very obvious that change management is a paralyzing [laughs] aspect.

+ +

And when technology is rearing its ugly head in the requirements for your business, the future of your business, I think for manufacturing and distribution, the timeline for a lot of that movement towards digital documents and working in the cloud was accelerated with COVID, with inflation. And all of a sudden, now there's companies who are leaping ahead and some that are falling behind. And it's now a requirement to prioritize more efficient processes simply because there's less people to do the work. And the companies who are taking advantage of innovation are really maximizing the opportunities to build their business, get more customers, and have more success.

+ +

WILL: I was looking at your team, and it looks like you brought on the head of technology, I think, in 2022. And so, I think it was you and your co-founder in the very early days. How was it as a founder to build a technical app and going through that process? How was that process for you?

+ +

LONNI: We were so lucky to partner with a local company in building out the MVP of SmartCert. They had an amazing team. They helped us bring to life a lot of Lyndon's ideas and also had a good background in supply chain. So, I always give props to TechFabric in Gilbert, Arizona, for giving us the opportunity to prove out the model. And that was then enabling us to get the funding and higher Mark who, I will say, every day I don't know how we became so lucky.

+ +

I think startup life is challenging in and of itself. But he really embraced the mission and the opportunity to rebuild SmartCert from the ground up for the scalability it requires but to also embrace the security aspects that are coming to the industry, those compliance requirements, and working alongside us. He's one of the few, I think, heads of technology that are involved in a lot of conversations with customers. And we are absolutely so lucky to be able to add him to our team and continue to evolve the platform in all the ways it needs to to accommodate what we're trying to achieve.

+ +

VICTORIA: Thank you for sharing that. I wonder, what does success really look like for you now, or six months from now, maybe even five years from now?

+ +

LONNI: It'll be three years that we have launched SmartCert in March. And when we think about, you know, what's the first thing to prove when you're a new product in a new market, and it's to prove that people are willing to pay to alleviate the pain. And I think we've done a good job doing that. It's building virality now, you know. As the industry is now expanding its use of SmartCert, more companies are participating. So, we've built a good foundation, which has allowed us to start working with some of the global aerospace companies, distributors, and contract manufacturers, and pilots. We're defining those opportunities now.

+ +

And I think 2024 will be a really big year for us to expand the features and the usage and adoption not only with additional supply chains but much more fast-paced growth with participating companies so that in five years, we could really look back and say, "We have really supported supply chains all over the world in working smarter, approaching sustainability with the right goals and processes to cut down on paper, and also be able to combat the challenges with labor shortages, apply technology in ways that are going to certainly make sense for them and for the future."

+ +

VICTORIA: I like that you tie in business goals with, like, big, dreamy goals, like, really reducing our impact on the planet and things like that. Because I think that's...you need to have something to come back to at the end of the day when you're working really hard in a startup like this.

+ +

LONNI: We had a really fun exercise, an internal exercise. So, our lead investor, TitletownTech, obviously has entrepreneurs in residence that we had the advantage of working with. We went through an exercise of really trying to articulate what is, like, the big, hairy goal? What is our mission? And our tagline is now taking the paper and the work out of paperwork so humans can do what they do best.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: You were talking about the exercise to figure out, like, where your company is going. I want to ask question, like, around your leadership and core values. Like, how important is it for you to set that foundation now for the next couple of years? Because it sounds like that's what you're doing. You're setting that foundation, and I heard you say it a couple of times, foundation. So, how important is it to set that foundation for the growth that you're expecting over the next couple of years?

+ +

LONNI: When you do have a product-led growth initiative, it means you need to provide as much self-service onboarding, and training tools, and resources as you can to make it easy for companies to move from their free account to a paid account and take advantage of all of the features and the functionality.

+ +

So, our goals right now are to eliminate hurdles that companies may feel in making the transition. Because we've had so many conversations over the past, I guess, almost three years, we're pretty articulate on being able to help with process changes. What are you doing now? Here's how SmartCert fits in. Are your goals on the supplier side or your internal organization? Is it with customers? And just help walk them down the path of making a transition so it doesn't feel like it's going to require months or years or tons of man-hours that just aren't available as people just try and get through the day.

+ +

So, from a foundational perspective, customer success is really now sales, marketing support. And those are the tools that I think will help companies have a clear path. We've learned that they really want to make very clear decisions. If I do this, what are the steps? So, we're providing clarity and a lot of good guidance that doesn't require a lot of man-hours on our side to be able to help turn free accounts into paid accounts and continue their expanded use of the platform.

+ +

VICTORIA: That's very cool. Do you have any questions for me or Will?

+ +

LONNI: So, you guys have a lot of conversations. I would love to hear what's really stood out in the last month or so. What's kind of resonated with you? Or what did you hear and apply in your life?

+ +

VICTORIA: I have a couple of answers. I mean, I've had a lot of really amazing guests on the show. It's hard to pick out any few that were really important or had some meaningful takeaways. I really liked Charity Majors when I asked her how the company is doing, and she's like, "Well, we haven't failed yet." [laughs] And just an interesting mentality of very humble and very just open to change and open to seeing, like, what's going to happen next.

+ +

And also, I think that Irina Nazarova talked about managing products versus managing open-source projects, and how that is different, and how it might influence your business differently, especially as a consulting company. So, I thought that was really interesting.

+ +

I always love having guests on the show and hearing about why they started what they're doing. And it's just really inspiring to hear people take a chance on an idea that they have, that they feel passionate about, and really put everything behind it. And, you know, most of the time, we're talking to people who have succeeded [chuckles]. A few guests we've had are just getting started in their journey, and it is still kind of unclear. And I really enjoy those conversations as well, where they're just still not really sure if it's going to work. So, that's been a little bit about my experience as a host on the show.

+ +

WILL: Yeah, I think I was going to go in a similar direction because I love talking to founders because it's just a different...almost like what you said, like, it's okay; go out there. Take that next step. It may hurt. It may be hard. It's not an easy path but go out there. You can do it. And it's not just for starting a company; for me, it's almost everyday life, like the hard things that come my way in life. Like, it's okay; I can do it.

+ +

So, I think it's very encouraging to hear founders and their mindset when they started companies and after, like, multiple years of where they're at. And, like, yeah, it was hard. It was not easy, but hey, I made it. Like, I'm on the other side of it. And we're doing great, or we're still in there just hanging out. So, I think, for me, it's being resilient. I think that's the big thing.

+ +

LONNI: I think you nailed it because real talk is survival. And if you aren't honest with yourself, it's not likely you're going to be able to survive. So, I think when you take stock of what you're trying to achieve, the road is super hard, or, like, everyone says, "Everyone would be doing it." But there's a reason, and there's intention there.

+ +

And there are so many entrepreneurs who have failed over time only to have more intelligence, experience to get it right at some point. So, I don't know that anything is linear these days. We get smarter and certainly savvier around topics that interest us. And if it drives you towards entrepreneurship, I salute you. It makes having three daughters feel like a spa treatment.

+ +

But I also know that I get excited about the other side of this. But our board reminds me that there's so much of this that feeds my soul. And it's hard to give that up when you do sell the company or move on because you're used to just being involved in all the things and being able to take advantage of the highs and come together during the lows. And that roller coaster is actually what everyone tells me I'm going to miss the most. I don't believe them yet. But [laughs] I think that they're probably right.

+ +

VICTORIA: I think maybe you'll have a nostalgia for it. But you'll enjoy your peacefulness as well.

+ +

LONNI: Yeah [laughs].

+ +

VICTORIA: Hopefully. [laughs] You have to hope. Yeah, I wonder, you know, speaking about, like, having investors and going around trying to raise money for a product, did you receive any advice or suggestions that, looking back on, you were like, "Actually, that was completely not helpful; I'm glad I didn't take it"?

+ +

LONNI: There were many companies who declined to participate in conversations because we were not building SmartCert on blockchain. And some of them have come back around and asked, "Are your plans to include it?" And we've always felt not only does that require a huge leap...We're taking an industry from paper to digital, so if you want to layer blockchain on that, you're probably going to go nowhere really fast. Because I don't think there's anyone on this planet who can explain it well or really articulate the benefits when, in fact, you're sending paper in boxes. And, sure, there's the security element to that, but it's not really aligned with what blockchain is meant to do.

+ +

So, we kind of have a laugh now about those that pushed so hard for we will only fund if this is blockchain-enabled. And we're so glad we didn't do that [laughs].

+ +

VICTORIA: Yeah, I mean, my understanding for, like, a blockchain, one good use case might be for, like, unique identities or something. Taking the more practical approach, sometimes I think people forget in technology that we're just...the future is here, but it's not evenly distributed. And there is paper being sent in boxes. And sometimes we can make a big impact, which is very simple solutions. But even simple solutions aren't simple to implement and make change happen.

+ +

So, I'm wondering if you have any advice for founders who are facing a big change management that they're trying to push through. What advice would you give them to kind of start making inroads into that?

+ +

LONNI: There are companies who make hundreds of millions of dollars helping [laughs] other companies through change management, and it's not lost on me that it's its own business. What we have really come to understand is you need to meet everyone where they're at. The tools that we've built are simple. You learn SmartCert in five minutes. It is how processes change that have been in place since the beginning of time for this company.

+ +

And I think when it comes down to it, there are plenty of business owners and C-suite executives that can say, "Yes, this makes sense. We're going to do it." But being voluntold as the user who needs to not only learn something new but move out of their comfort zone figure out how to learn while doing your job every day, those are the people that I really think is important to support. They're going to mean the success of the adoption. And they are the ones that deserve the cheerleading.

+ +

So, with change management, my advice would be is to think about every single person that this affects in the company, understand who is able to realize immediate benefits, whose are maybe more short-term once this is launched or as your customers adopt it. And then who benefits, and how do they benefit for the long-term? Because you sort of need to help them keep their eye on the prize to get through the steps, it's going to require to change the way they show up every day.

+ +

WILL: So, Victoria asked you about advice that you're glad that you didn't take. Was there any advice that you're like, "Wow, that was the best advice, and I am so glad that we did follow it"?

+ +

LONNI: Towards the end of last year when, we sort of accepted our fate that standard sales, SaaS sales, was not going to work for us. Lyndon, the founder and one of the members of our board, had a really great conversation around relationships, especially with these antiquated industries. And if you are new technology, the real key to winning business, sort of earning that street cred, being accepted as a thought leader, is to make relationships with people.

+ +

It is still a person-to-person decision that helped us prioritize attending regional conferences and industry conferences to meet people face to face as often as possible to build the trust and to be able to build the relationships that will help create the confidence in every company we talk to about moving forward but making sure that there's still a human element involved.

+ +

WILL: I love that advice. Yeah, it's interesting how many companies, I feel like, forget that, is that the people is the reason that your company exists. I don't know where I got it from, but someone told me it's three Ps that, like, what is kind of the foundation for your company. I think it's people, processes, and products. If you can nail those three things, like you will be successful majority of the time. And I thought that was very interesting.

+ +

LONNI: It's so true. Empowering people and accepting the challenges that they face, being real about what change means for them, being able to, you know, speak their language, and acknowledge what taking on new commitments and new processes means for them is going to be the way to be successful.

+ +

VICTORIA: And how does your balance feel between your life and your family, that you've mentioned, and working for this company trying to get it off the ground?

+ +

LONNI: There are times where I'm proud being able to show my daughters that you can do it all, but it's hard to do it all. I'm grateful to work from home because it does enable me to not only work in yoga pants all day but to have time for self-care. So, the endorphins at the gym are survival for me. Being able to find your people...I was so lucky to be a part of StartupAZ, which is a cohort here in Arizona of just about a dozen companies. And we got together on a monthly basis to talk through what's working, what's not working, sort of setting goals for ourselves but also commiserating.

+ +

Because I feel like being an entrepreneur can feel really isolating. I don't think there's many people that understand what this means on a daily basis. There's certainly a whole new language beyond that with tech founders. And it helped me feel seen in a way that I can't articulate or get from my friends. So, that was really important for me.

+ +

What I try and be really sensitive to is this is a grind, but I'm doing it on behalf of my family. So, prioritizing time, even if it's, well, you know what? I'm going to drive you to school because that means I get 10 minutes in the car one one-on-one with you. Those are the things that I think if you're going to have less time, find ways to make it more meaningful without screens and phones, and just connect to your people. That's been important to me.

+ +

There are days that I'm better at it. This week has not been great simply because we have some big deadlines. And I do still try and prioritize things like the gym simply because my brain works so much better with [chuckles] endorphins than without. So, you'll have parental guilt. But if you really remind yourself that you're showing up for the greater good and you're doing it for your people, then your people will still always be in the forefront.

+ +

WILL: Do you have any foreseeable hurdles coming up with SmartCert?

+ +

LONNI: This is a big year for us. We, as many tech companies, have worked really hard to extend our runway. The funding [chuckles] world, the milestones, and markers required for a Series A round have all changed a lot since we were funded. And I think the hurdles we face is to demonstrate enough of momentum, great outcomes with our pilots, with these larger companies, to be able to go back to our investors and expand the future with the funding we'll need to continue to scale. So, that's probably a consistent point of view for a lot of tech companies.

+ +

It's sort of that make-or-break year. But we feel pretty good about it certainly because of the changes we've made to the way we go to market, but also the features we released this year in support of these larger conversations and being able to bring on someone who's going to then have 2,400 of their suppliers join the network. So, there's a lot of potential, but there's also a lot at risk.

+ +

VICTORIA: Yeah. So, I'm curious how that process was when you decided to pivot and you decided to create some new features to meet what your customers were telling you. How did you go about getting the support you needed to build those features?

+ +

LONNI: One thing that I think we did okay at, but if I had to look back, I'd say we should have done more of, is talking to the companies represented on SmartCert, certainly our paid customers. But those conversations helped us prioritize the features that would enable them to work smarter, to reduce risk, to be more efficient, to grow in a way that's going to support and embrace technology as it's introduced to the industry.

+ +

So, when you think back to what can you learn, it should always be the people that are using your product. We have, in this year, created a lot of internal tools so that once you do receive documents, or if you're a manufacturer and you're generating documents, centralizing those for access among teams, and creating a really automated process to send those to customers was the focus. And the conversation now has moved, as I mentioned, to the supplier side. And that's one area where I think we have the greatest opportunity for growth simply because it is the one area of the business you have the least control over.

+ +

So, we've kind of come full circle with building the tools that make sense for those that are using it now and building a new path to participate on a network or create efficiencies by making standard processes. Even if your suppliers aren't participating on SmartCert, we are going to be launching the ability to take the documents, as I mentioned, and turn them into SmartCerts. That, to me, I think presents the greatest opportunity for us to really build a lot of momentum.

+ +

VICTORIA: I love that. And so, you have your own team of developers working on this. Are you working with, like, an outsourced team? Or how did you structure the type of technical skills you needed to bring into the team?

+ +

LONNI: Our partner company that built our MVP, TechFabric, is still connected with us. So, if we have integrations, their team usually assists us with those SmartCert integrations into things like ERPs and just legacy systems that our customers are using. What they helped us with is to kind of provide the ideal candidate framework based on their knowledge of not only where the platform needs to go but the requirements and capabilities it requires, and participated in interviews to help us build our internal team. So, without having leadership in technology, that was a huge win for us to have an advisor and a supporter to be able to have the conversations we weren't qualified to have in order to hire the right people.

+ +

VICTORIA: Gotcha. That makes sense. And maybe I missed this point earlier. But how did you meet them, or how did you find them?

+ +

LONNI: Well, the story is a good one. We're based in Gilbert, Arizona. And as we were exploring what the options were, obviously trying to prioritize local relationships and partnerships, we did a Google search and ended up just having great conversations and feeling very fortunate that they were in our backyard and still are a really strong partner.

+ +

VICTORIA: Oh, that makes sense. And having someone nearby, too, probably helps to just make it all feel a little cozier, so I love that. I love hearing about it and that they've helped you get to a place you want to be with the app. I'm so grateful to hear your story and hear more about what y'all are working on. Is there anything else that you would like to promote?

+ +

LONNI: It's always fun having these conversations because sometimes you forget, you know, you're stuck in the minutiae of the day-to-day. And I just appreciate being able to tell the story and be reminded of how far we've come. And certainly celebrate and challenge anyone else who's considering a [inaudible 41:24] at this to take it.

+ +

And if there's any advice that I would want to leave everyone with is to prioritize sleep [laughs] because it's the secret weapon. And I can tell that the days that I don't get enough, I don't think the way that I should. And it's almost like sleep is the new drug. And find any way possible, whether it's white noise, CBD, black-out shades, find your peace because sleep is your friend.

+ +

WILL: I totally agree with that.

+ +

[chuckles]

+ +

VICTORIA: Thank you so much for your time and for being here with us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

AD:

+ +

Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us.

+ +

More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Special Guest: Lonni Kieffer.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+92dEryy- + + ]]> + + Will Larry + Victoria Guido + Lonni Kieffer + + + 495: Free Code Camp with Quincy Larson + https://podcast.thoughtbot.com/495 + a9d0949b-f0a3-4608-9771-7e55aedcb91d + Thu, 05 Oct 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Quincy Larson is the founder of freeCodeCamp.org, which helps people learn to code for free by creating thousands of videos, articles, and interactive coding lessons–all freely available to the public. Quincy shares his journey from transitioning from teaching into software development, how freeCodeCamp was born out of his desire to make educational systems more efficient through coding, and discusses the early challenges of bootstrapping the platform, and how it has now grown into a 501(c)(3) nonprofit organization. + +Quincy and hosts Victoria and Will, discuss the platform's technical architecture, especially their global server distribution and decision to rely on volunteer-led translation efforts rather than machines to ensure both the quality and human touch of their educational content. He also talks about the state of free and low-cost degree programs, the student loan crisis, and the ongoing debate between traditional computer science degrees and coding bootcamps. + 56:49 + no + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP. +Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox! +Quincy Larson is the founder of freeCodeCamp.org, which helps people learn to code for free by creating thousands of videos, articles, and interactive coding lessons–all freely available to the public. Quincy shares his journey from transitioning from teaching into software development, how freeCodeCamp was born out of his desire to make educational systems more efficient through coding, and discusses the early challenges of bootstrapping the platform, and how it has now grown into a 501(c)(3) nonprofit organization. +Quincy and hosts Victoria and Will, discuss the platform's technical architecture, especially their global server distribution and decision to rely on volunteer-led translation efforts rather than machines to ensure both the quality and human touch of their educational content. He also talks about the state of free and low-cost degree programs, the student loan crisis, and the ongoing debate between traditional computer science degrees and coding bootcamps. +Free Code Campi (https://www.freecodecamp.org/) +Follow Free Code Camp on LinkedIn (https://www.linkedin.com/school/free-code-camp/) or X (https://twitter.com/freeCodeCamp). +Follow Quincy Larson on LinkedIn (https://www.linkedin.com/in/quincylarson/) or X (https://twitter.com/ossia). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robot Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with me today is Quincy Larson, Host of the freeCodeCamp Podcast, Teacher, and Founder of freecodecamp.org, a community of people around the world who are learning to code together. Quincy, thank you for joining us. +QUINCY: Yeah, thanks for having me, Will and Victoria. +VICTORIA: Yeah, thank you for being here. So, I understand that you made a big shift personally for yourself from California to Texas. How has that been for your family and for, you know, as a founder who is running a nonprofit? +QUINCY: Yeah, things are going great. It was a big move. We had some kids, and it was difficult to find, like, a good place to live in California that didn't cost, like, millions of dollars [laughter]. And so, at least in the San Francisco Bay Area, we were living in East Bay. +I grew up here in Texas and Oklahoma. And I was like, well, maybe we could go back to the southwest, and so we did that. And we were able to come back and comfortably purchase a home here in Plano, Texas. We were able to find one that was, like, really close to a really good public school system. And so, every morning, I'm able to walk my kids to school. +And I'd say that Texas has been a great change from California, where I lived for seven or eight years over there. And I love California. Texas has a lot of great things about it, too. It is a little bit hotter than California. It doesn't quite have California's Mediterranean climate, but it's been great here. I like it. And I would say if people are thinking about moving to Texas from California, there are definitely some really good spots of Texas that I think they'll feel really comfortable in. +WILL: That's awesome, yeah. I'm originally from Louisiana. So, you're bringing back, like, memories of me growing up, always going to Texas and stuff. And I know exactly where Plano is, so that's amazing. How has it been with your kids? Because we were talking, and you said your kid recently started school. How's that been? +QUINCY: Yeah, so my daughter started school a couple of years ago, and she just turned eight. And my son he's turning six this weekend. He just started kindergarten. We were having him take classes at the YMCA some pre-school. And he went from doing that for the first few hours of the day, and then we'd pick him up and bring him home and eat lunch with him and everything. +And now he's got to go to school from, like, 7:00 a.m. to, like, 3:00 p.m. And he's been freaking out, like, "Why is school so long? Oh my goodness, I'm so tired all the time," [laughs]. So, he didn't realize that school would be as involved a process. He was all excited. But now he's complaining about, like, just the sheer length of school. But meanwhile, my wife and I we're just, like, celebrating because we actually have some time around the house where we can get work done without having kids running around causing chaos [laughs]. So yeah, I think he's adapting. He's making friends. We're doing playdates and stuff, and he's having fun. It's just a transition, you know. +But it is nice because before, I would walk my daughter to school, and that was a very quick, 10-minute round trip, and then I'd walk my son to school. And that was, like, an hour round trip because we walked all the way to the YMCA. And I would do that to kind of toughen him up and get him walking a lot. It was a huge chunk of time. And now I can just grab both, one [inaudible 4:04] hand in each hand, and walk them to school, and drop them off, and be done with it and get back to work. So, it's definitely nice having both at the same school. +VICTORIA: I love the work-life balance and that you were able to find and live somewhere that's affordable and has enough space for your family. And I wonder if we can draw a connection there between achieving that kind of lifestyle and learning to code, and what the mission of freeCodeCamp is for you, and what that means to people and changing careers. +QUINCY: Absolutely. So, my background is in teaching. And I was a teacher and a school director at schools here in the U.S. and over in China. And that involved me being on campus, like working directly with my admin staff, with my instructional staff, and working directly with students. So, working remotely was kind of, like, a foreign concept way back in, like, 2010 or so 2011 when I started my transition into working as a software developer. +But being able to work remotely has been a real game changer for me. And also, you can imagine, like, being a developer, you can command much larger compensation, and you have a lot more career options than being a teacher or a school director. So, it's given me a lot of agency in what I wanted to do. Even before, you know, starting freeCodeCamp, when I was working as a software developer and doing freelance work and stuff, I was able to do everything remotely. And that just gave me a ton of flexibility. +So, the way that I learned to code personally was I wanted to help our school be more efficient. A lot of our teachers, a lot of our admin they were spending all day kind of chained to their desk entering information into computers for compliance reasons, to be able to produce great reports, to be able to produce attendance reports, immigration documents, all those things. And I just thought, like, is there a way that maybe I could automate some of this? +And I didn't know anything about programming. I was about 31 years old. I was just sitting at my desk, and I just started kind of, like, Googling around and learning some very basic programming. And with that, over the course of a few months, I was really able to transform how the school ran. And we, like, won an award. And, like, a whole bunch of the students were, like, having a great time because they were spending so much more time with their teachers. And they were like, "Hey..." like, telling all their friends and family to transfer into the school. So, it was a massive success. +And I thought, wow, if one person who doesn't even really know that much about programming can effect such a change with just a little bit of programming skills, imagine what I could do if I actually learned to code properly, so [chuckles] I did that. I spent about nine months going to hackathons every weekend, and reading a lot of books, and using a lot of open courses online, like from MIT, from Stanford, and I kind of taught myself to code for free. +And then, I was able to get a job as a developer at a mid-size tech startup in California. And from there, I just learned more and more, and it was amazing. And it was an amazing transformation for me personally. And I thought, well, I want to help other people be able to do this because I know so many people out there would like to be working in a field where they have more conversation, a higher degree of control. They get to do creative work instead of, you know, tedious work. +As a developer, you're constantly doing new stuff because code is infinitely reproducible. So, you could always just go back to code you've previously written if you needed to solve the same problem again. So, you're always in this kind of learning mindset. You're always in this problem-solving mindset. And it's really thrilling. It's just great, impactful work. So, I wanted to help more people be able to do that, hence starting a bunch of different projects that people didn't care about and then eventually starting a project that people did care about, which is freeCodeCamp. And since then, just kind of leading this project in trying to help as many people as possible learn to code. +WILL: So, I was looking at your website. And I didn't even realize this until I was doing more research for the podcast, but you have over 10,000 tutorials, and they're in different categories. I saw you just recently released one on finance, which I actually bookmarked it because I'm going to go through it and look at it. You help more than a million people every day. So, how was it when you first started out? Like, how was, I guess, you could say, the grind? How was it in those early days? +QUINCY: I'm a big advocate of, you know, for work-life balance, but, like, I kind of, like, exclude founders from that. I really do think that if you're trying to get something started, you're going to have to work really hard and probably way beyond what would be reasonable for a person who's getting a salary or working at an existing company if you're trying to get things started. So, I mean, it was, like, 100-hour weeks, maybe 120 some weeks [laughs]. +I would sleep and just wake up and get to my desk and try to, like, put out fires, fix the server, improve the codebase, respond to learners in the community who had feedback, deal with support issues. Like, I was basically doing everything myself. And gradually, we were able to, like, build out the team over a long period of time. But really, the first few years was me self-financing everything with just my teacher savings. I spent, like, $150,000 of my own money just trying to keep freeCodeCamp going. +For the first couple of years, we got tax-exempt status from the IRS. When that finally happened, I was like, great, like, let's go out and see if we can get some people to donate. So, we started asking people who were using freeCodeCamp if they'd be willing to donate $3 a month and eventually $5 a month, and we were able to support the organization through that. Really, it's just like a grassroots donor-supported effort. +And then, we've been able to get some grants from Linux Foundation, and From Google, from Microsoft, from a whole lot of other big tech companies, and from some other nonprofits in the space. But mostly, it's just been, like, individual donors donating $5. And if you get enough people doing that, you get, like, a budget where you can actually pay for, you know, we have more than 100 servers around the world serving freeCodeCamp in, like, six different languages. +We have, you know, all these other, like, initiatives. Like, we've got Code Radio, where you can go listen to Lo-fi while you're coding. And there are servers all over the world. And you can change the bit rate to suit whatever data you have and everything. Like, we wanted to just offer a whole lot of different services. We have mobile apps now. We've got an iOS and an Android app for freeCodeCamp. And then, of course, we've got the podcasts. We've got four podcasts: one in English, which I host, and then we've got one in Spanish, one in Portuguese, and one in Chinese. +VICTORIA: Yeah, I absolutely want to ask you more about your podcasts. But first, I wanted to hear–can you tell me a little more about the decision to be 501(c)(3) or a nonprofit status? And were you always firm in that decision? Do people question it? And what was the real reasoning and commitment to that formation? +QUINCY: I guess I would consider myself an idealist. Like, I genuinely believe that most educational endeavors should be, you know, nonprofit. They should be driven by either governments or by charities. I'm always kind of skeptical when there's, like, some late-night TV commercial, like, "Viewer, we'll help you get our degree," and it's from, like, a private for-profit university, something like that. +So, I was like, in education...and I don't think everything in society needs to be that way, but I do think, like, education and, to an extent, healthcare these should be led by charities. Like, you know, the Red Cross, or, like, Doctors Without Borders, or churches, you know, own many of the universities, many of the hospital systems in the United States. I think that's a good thing. I think it's a very good thing that it's not just, you know, private profit-maximizing, market incentive-bound organizations that are doing all the stuff in education and in healthcare. +I wanted to try to create something that, like, a lot of other people would see and say, "Oh wow, this charity can actually survive. It can sustain itself without raising a bunch of VC, without going public," or any of those things that a for-profit entity would do. And, again, I just want to emphasize, like, I don't think that iPhones should be made [chuckles] by nonprofits or anything like that. +I'm just saying, like, for the purpose of actually educating people, the incentives are not necessarily aligned when you're trying to get money from...especially when you're talking about people that 60% of people on earth live off less than $10 a day. Those people should be spending their money on food. They should be spending their money on shelter. They should be spending their money on family. They should not be spending money on online courses, in my humble opinion. Like, online courses should be freely available to those people. +So, to some extent, freeCodeCamp, we want to make sure that everybody everywhere in the world has access to first-rate learning resources on math, programming, computer science, regardless of their ability to pay. So, that's kind of, like, the ideal logical [inaudible 12:19], I guess, of freeCodeCamp. We kind of live that. Like, we're really serious. We will never pay, well, anything on freeCodeCamp. We won't account email gate anything. We are, I guess, absolutist in the sense that we want all of freeCodeCamp's learning resources to be free for everyone. +Because of that, it made sense to like, incorporate as a 501 (c)(3) public charity. And so, we're tax-exempt. And people who donate to freeCodeCamp they can, you know, deduct it from their U.S. taxes. If a large company or even a small startup...we've had lots of startups like New Relic, like Retool, we've had Postman, Hostinger, a whole lot of different startups and mid-sized tech companies, Pulumi, Appsmith, they've all given us these grants that we can use to develop courses. So, we can often develop courses incorporating those resources. But that's tax-exempt, right? They can deduct that from their U.S. taxes. +So, it's a big incentive for other people to partner with us and for people to donate funds to us. And it allows us to have the interests aligned in the sense that only people who have, you know, free cash flow or who have disposable income those are the people that are supporting freeCodeCamp. +For the people that are, you know, single parents or that are taking care of their aging relatives, or are already working two jobs, or are completely unemployed and don't have any funds to speak of that are using the public library computer to access freeCodeCamp, right? Or using freeCodeCamp on a $50 prepaid phone from Walmart or something like that, right? Like those people can still use freeCodeCamp, and we can have the people who do have resources subsidize everyone else. +WILL: Wow. I absolutely love that because...and I wish freeCodeCamp was around whenever I was in, like, high school and, you know, the early 2000s because we just didn't have the resources because I grew up in a small town in Louisiana. And this could have been so beneficial to that community because, like you said, we didn't have the resources–someone to teach coding there. There was no developers around that town that I was in. So, I really appreciate that you're doing this for everyone. +And I know for me even...so, when I reached out to you, I did it because I was excited because I've used freeCodeCamp so many times, so many times to learn just in my journey to become a senior developer. Like, freeCodeCamp was one of the resources that I used because, one, it was free. But it wasn't...I think sometimes you can get free resources, and it's not great quality almost. Like, it's almost like you're more confused than before. But with freeCodeCamp, it was very, very amazing quality. And it was very clear on what I was learning. Honestly, thank you for helping me grow as a developer, just, honestly, thank you for that. +QUINCY: Absolutely, Will. I feel honored to have helped you. And, yes, we want to help all the kids who are growing up in rural Louisiana or...I'm from, you know, Oklahoma City, not, like, the biggest, most prosperous city in the United States. Like, I want to help all of my friends who growing up who were eating meals provided by the state school system or my older friends who are on disability. Like, I want to make sure that they have resources, too. +And in the process of doing that, it's a privilege to also serve all the working software engineers like you out there who just need, like, a reference resource or, like, oh, I've heard about Bun JS or Tailwind CSS. Or something like, I'm going to watch this three-hour course where I'm going to learn how to do Flutter. Like, freeCodeCamp has a 37-hour Flutter course. So, we've got, like, all these courses on using OpenAI APIs and things like that, too, right? +So, it's not just for beginners, but we definitely want to, like, first and foremost, we want to serve people who we're kind of, like, the resource of last resort for, if you want to think of it that way. Like, only freeCodeCamp can help these people. Sure, they can probably use some other free courses on YouTube. And there are lots of other blogs that publish good tutorials and stuff. But freeCodeCamp is like an organized effort, specifically to help those people in need. And just kind of a side benefit of it is that you know, more established, experienced devs like you also get kind of, like, some benefit out of it as well. +WILL: Whenever you were a developer, and you decided to start freeCodeCamp, how many years of experience did you have? And how did you overcome impostor syndrome, not only as a developer but as a founder? Because I feel like just overcoming it as a developer is hard, but you were also, you know, like you said, you know, handling everything for freeCodeCamp. So, how did you do that? And kind of tell us about that experience. +QUINCY: Yeah. So, I didn't really know what I was doing. I think most founders probably don't know what they're doing. And I think that's totally fine because you can learn while you're doing. And we live in the United States, which is a country that kind of rewards experimentation and does not punish failure as much as a lot of other cultures does. Even if you try really hard, you're going to learn a tremendous amount, and you're going to try your next project. And that's what I did. I tried...I launched several educational, like, open learning resource-type projects, and none of them made any dent at all [laughs] in the proverbial universe. Like, nobody cared. +Like, I would go and, like, I'd be talking to people. And I'd be explaining, like, "Oh, this solves this problem that you have." And you could kind of tell, like, people would sign in one time just to be polite, but then they'd never sign in again. So, it was very tricky to get traction. And I read a bunch of books. And I went to a lot of founder-focused meetups in San Francisco Bay Area. I had, like, moved out to San Francisco, specifically to try to, like, kind of make up for my deficit, the fact that I didn't know anybody because I was from Oklahoma City. +I didn't know anybody in tech. And I didn't have, like, a fancy, you know, pedigree from, like, Harvard, or Wharton, or something like that, right? Like, I went to, like, a state university, and I studied English, right? And [chuckles] so, I didn't even have, like, a CS degree or anything like that. So, I definitely felt like an impostor. I just had to kind of, like, power through that and be okay with that. +And it's something a little bit easier for me to do because, you know, I'm a White guy with glasses and a beard. And, like, nobody's walking up saying, "Are you sure you're a developer?" Or like, "Are you in marketing?" You know, like, the typical kind of, like, slight that they may say to somebody who doesn't necessarily look like me. And so I didn't have to deal with any of that nonsense, but there was still a lot of just self-doubt that I had to power through. And I think that was a big advantage for me. It was just, like, I was kind of, like, at war with myself and my own confidence. +In fact, I found the software development community, and especially the open-source community, to be incredibly uplifting and empowering. And, like, they want to see you win. They want you to sit down and build a really cool project over the weekend and in the hackathon and present it. And, you know, they want you to learn. They know that you know, everybody is going to learn at a different rate and that a lot of people are going to get discouraged and leave tech and just go back to working in whatever field they were working in before. And that's totally cool. +But I do feel that they're there to support you and to encourage you. And there are lots of different events. There are lots of different communities. I recently listened to the founder of Women Who Code, who was on this very podcast [laughs], Giant Robots Smashing Into Giant Robots, the greatest podcast name of all time. And, you know, there are people out there that are working very hard to make it easier for folks to get into tech. I think that that has been a huge part. +Even before freeCodeCamp, you know, there were Harvard professors–Stanford professors putting their entire coursework for free online. You could go to, like, different tech events around California, for example, where I was when I was learning to code. And there'd just be tons of people that were eager to, like, learn more about you and to welcome you. And there would be, you know, recruiters that would talk to you and say, "Well, you may not be ready yet, but, like, let's talk in six months," right? +And so, there was kind of, like, that spirit of you're going to get there. It's just going to take a lot of time. Nobody was telling me, "Oh, learning to code is easy," [chuckles] because it's not easy. There were lots of people that were, like, "Learning to code is hard. But you've got this. Just stick with it. If I could be of help, let me know," people who would pair program with me to help me, like, improve my chops, people who would volunteer to, like, look at my projects and give design feedback, all those kinds of things. +And I think you're going to find all those things on the web. You're going to find those things in the open-source community. freeCodeCamp has a forum where people volunteer their time and energy to help build one another up and help one another get unstuck on whatever projects they're working on, give feedback on projects. And so, I think, to a large extent, the very giving nature, I almost want to say, like, selfless nature, of the global software developer community that is what saved me. And that's what enabled me to transition into this field, even as a teacher in his 30s. +VICTORIA: It's interesting you say that. Because I feel as someone who hires engineers and developers, I love people who have teaching backgrounds because it means they're five-star communicators [laughs]. And I think that you know, in your job, when you're pairing with other developers, or you're talking to clients, in our case, that communicating what you're working on and how you're thinking about something is, like, 50% of the job [laughs]. +For freeCodeCamp, I saw you have 40,000 people have found jobs after completing courses on there. I hope you feel like you've really, like, established some success here already. But what's on the horizon? What are you looking forward to in the next six months or six years with freeCodeCamp? +QUINCY: Yeah, I'll be happy to answer that. But I want to emphasize what you just said: communication is, like, half the job. That's something that thoughtbot has gotten really early on. And I'll tell you that thoughtbot Playbook was incredibly helpful for me as a software developer and also early on for freeCodeCamp's team. And I think a lot of teams make use of that open resource. +So, thank you for continuing to maintain that and kind of drive home that communication really is...like, meetings are essential [chuckles]. And it's not always just, like, leave me alone and let me go back to my cubicle and code. You know, I like to quote the old joke that, you know, weeks of coding can save you hours of meetings because I really do believe that communication is core. +So, to answer your question about where freeCodeCamp is headed in terms of what kind of impact we'd like to have, I feel like we're just getting started. I feel like pretty much every Fortune 500 company wants to become a tech company in some way or another. Everybody is pushing things to the software layer because software is infinitely reproducible. It's so much easier to maintain software or fix things in production. +Like, you realize, oh, there's a big problem. Like, we don't have to recall all the cars back to the dealerships to go and open up the hood and fix this, you know, mechanical defect. If we're controlling all these things at the software layer, right? We can potentially just deploy a fix and tell people like, "Hey, version update [chuckles], you know, download this security patch," or whatever, right? +So, there are so many different things that you can do with software. I feel like the potential growth of the field of software and the number of software developers that the world will ultimately need...currently, we've got maybe 30 or 40 million developers on earth that are professional paid-to-code people. But I think that number is going to increase dramatically over the next 50 years or so. +And I'll go ahead and address the elephant in the room [laughs] because pretty much everybody asks me this question like, "Don't you think that, like, tools like large language models like GPT-4 and things are going to obviate the need for so many developers?" And I think they're going to make individual developers more productive. +But if you think about what code is, it's really extremely explicit directions for how to do something, whether you're using, you know, machine code, or you're using a scripting language like Python, or you're using English, and you're talking directly to the computer like you would on Star Trek. Essentially, you have to have a really deep understanding of the problem. And you need to know exactly what needs to be done in exactly what sequence. You may not need to manipulate bytecode like you would back in the '70s. But you are going to need to understand the fundamental problems, and you're going to need to be able to address it. +So, I'm optimistic that the number of developers is going to continue to grow. The developers are going to continue to command more and more, I guess, respect in society. And they're going to continue to have more and more agency in what they want to do with their careers and have more and more options and, ultimately, be able to command higher compensation, be able to work remotely if they'd like. +Developers will continue to be able to ascend through corporate hierarchies and become, you know, vice presidents or even executives like the CEO, right? If you look at a lot of the big tech companies, the CEO is a developer. And I think that that will continue. And the computer science degrees will continue to be extremely valuable. +So, what is freeCodeCamp working on now that we think will further help people? Well, we're working on a free four-year computer science degree, a Bachelor in computer science, and there's also an associate in mathematics that we're developing. And those are going to be a progression of 40 university-level courses that have labs and have a substantial block of lectures that you'll watch. And then, we'll also have final examinations and everything. And we're developing that curriculum. We've got one of the courses live, and we're developing the second one, and eventually, we'll have all 40. It'll take till the 2030s. But we're going to have those. +And then, once we have some longitudinal data about graduates and their success rates and everything, we are going to apply for the accreditation process, and we're going to get accredited as a university, right? Like, you can go through that process. Not a lot of organizations do that; not a lot of new universities are coming about in the 2020s. But it is something that can be done. And we've done a great deal of research, talked to a bunch of accreditors, talked to a bunch of university admins who go through the accreditation process. We think we can do it. +So, again, very long-term goal. But when you're a 501(c)(3) public charity, you don't have to worry about freeCodeCamp getting acquired or all the things that would traditionally happen with, like, a for-profit company. You have a lot more leeway to plan really far. And you've got, like, this really broad mandate in terms of what you want to accomplish. And even if, you know, creating a university degree program in the 2030s would not be a profitable endeavor that, like, a rational shareholder value-maximizing corporation would embark upon, it is the sort of project that, you know, a charity like freeCodeCamp could do. So, we're going to do it. +MID-ROLL AD: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +VICTORIA: I think that's great. And, actually, you know, I got my master's in information technology and project management online way back when. So, I really like the availability of modern computer science bachelor's and master's being available at that low price point. And you're able to pursue that with the business structure you put in place. +I'm curious to kind of go back to something you said earlier on how widely available it is and how you spread out across all these multiple countries. Were there any technical architecture decisions that you had to make along the way? And how did those decisions end up turning out? +QUINCY: Absolutely. So, one of the things we did was we located servers all around the world. We're multi-cloud, and we've got servers in different data centers in, like, Singapore, Europe, Latin America, and we're trying to reduce latency for everybody. Another thing that we've done is, you know, we don't use, like, Google Translate to just translate all our different pages into however many languages are currently available on Google Translate; I think it's, like, more than 100. We actually have a big localization effort that's led primarily by volunteers. We have some staff that oversee some of the translation. +And essentially, we have a whole bunch of people working at translate.freecodecamp.org and translating the curriculum, translating the tutorials into major world languages. Most prominently would be Spanish, Chinese, Japanese, Korean, Portuguese, Ukrainian. Like, all these different world languages, there's, like, a freeCodeCamp version for those, and you can go into the menu, and you can choose it. And it's actually, like, hand-translated by native speakers of that language who are developers. +So, that's been another extremely, you know, time-intensive effort by the community. But we believe that, you know, the quality of the translations is really important. And we want that kind of human touch. We don't want kind of weird artifacts and typos that would be associated with machine translation. And we want to make sure that each of the challenges...because they're extremely tersely worded, again, communication is so important. +If you go through the freeCodeCamp curriculum, we try to use as few words as absolutely necessary to effectively communicate what the task the learner needs to accomplish is, and we try to, just in time, teach them concepts. We don't want to present them with a big wall of text. Read this 20-page PDF to understand how, you know, CSS, you know, borders work or something like that. No, we're teaching, like, kind of, like, just in time, like, okay, let's write this line of code. Okay, great, the test passed. Let's go to this next one. This test isn't passing. Here is some contextual-specific hints as to why your code is not passing, why you're not able to advance, right? +And we do projects [inaudible 30:30] to learn where we break everything down into steps. So, that's a lot of instructions that need to be very carefully translated into these different world languages to truly make freeCodeCamp accessible to everyone, regardless of whether they happen to be fortunate enough to grow up speaking English at a native level, right? +I would say that's our main consideration is, like, the localization effort but also just having servers everywhere and doing everything we can to comply with, like, all the different data rules and privacy rules and everything of all these different countries. It's a lot of work, but in my humble opinion, it's worth it. +WILL: I had, like, a two-part question because I wanted to loop back around. When you're talking about the free bachelor's program, one, does anything like that exist where you can get a bachelor-level program, and it's free? And then the second part is, how many countries are you in? +QUINCY: Yeah, so currently, lots of governments in Europe, for example, will offer free degrees that are kind of subsidized by the state. There may be some other kind of degree equivalent programs that are offered that are subsidized by corporations. For example, if you work at Starbucks, I think you can get a degree from Arizona State University. And that's a great benefit that Starbucks offers to people. Arizona State University, of course, being one of the biggest public universities in the United States in terms of enrollment. +As far as free degrees, though, in the United States, there's nothing like that where, like, literally anyone can just go and get a degree for free without needing to enroll, without needing to pay any sort of fees. There are tuition-free programs, but they still charge you fees for, like, taking exams and things like that. +What I like to call ultra-low-cost degree providers–there's Western Governors University, and there's University of the People. And both of these are accredited institutions that you can go, and you can get a degree for, you know, $5,000, $10,000, $15,000. And it's a full-blown four-year degree. Now, that is amazing. I applaud those efforts. I've enjoyed talking to the folks at those different schools. +I think the next step is to go truly free. There's nothing blocking you at all. You don't have to be banked. You don't have to have a credit card. You don't have to have any money. You can still get this degree. That's what we're chasing. And I think we'll get there, but it's just a lot of work. +WILL: So, it's blowing my mind. It's just blowing me away because, like, you know, we talk about the student loan crisis, I would say. The impact if...when—I'm not going to say if—when you do this, the impact that can have on there, have you thought about that? And kind of, if you have, what has been your thoughts around that? +QUINCY: Yeah, so there are $1.7 trillion in outstanding student loans in the United States. That's money that individual people, most of whom don't make a ton of money, right? Like, many of those people didn't actually finish the degree that they incurred the debt to pursue. Many of them had to drop out for a variety of different reasons or defer. Maybe they'll eventually finish those degrees. But as you can see from, like, the macroeconomic, educational, like, labor market data, like, having a partial degree doesn't make a big difference in terms of your earning power. You really need to finish the degree to be able to realize the benefits of having spent all that time studying, and a lot of people haven't. +So, yes, there are, like, a lot of people out there that went to medical school, for example, and they're working as physicians. And they are going to eventually be able to pay that off because they're doctors, and they're commanding a great compensation, right? And they've got tons of career options. +But if you studied English like I did and you incurred a whole lot of student debt, it could take a very long time for you to make enough money as a teacher, or as, like, a grant writer, or working at a newspaper, or something like that. Like, it can take you years to pay it off. And, in the meantime, it's just continuing to accumulate interest in your, you know, you might be a very diligent person who pays their student loan bill every single month, and yet, you could see that amount, the total amount that you owe continuing to grow despite this. That's just the nature of the time value of money and the nature of debt. +And I thank my lucky stars that I went to school back in, like, 2000. Like, my tuition was $1,000 a semester, right? I mean, it's incredible. But that was, like, at a state school, like, a public university in the middle of Oklahoma. And it's not, like, a university you've heard of. It's basically, like, the cheapest possible option. I think community colleges can make a huge dent. I always implore people to think more about community colleges. +I've talked with so many people on the freeCodeCamp podcast who were able to leverage community colleges and then transition into a, you know, research university, like a state school, and finish up their degree there. But they saved, like, basically half their money because they were paying almost nothing to attend the community college. And in California especially, the community colleges are just ridiculously worth it. Like, you're paying a few hundred dollars a course. I mean, it's just incredible value. So, I think the community college system is going to play a big role. But my hope is that, you know, freeCodeCamp can thrive. +And it'll take us years for people to realize because if you go on, like, Google Ads and you try to run a Google Ad for, like, any sort of educational-related topic, anything related to higher education, it's, like, hundreds of dollars per click because there are all these for-profit universities that make a tremendous amount of money from getting people who just came back from serving in the military and getting, like, huge chunks of their GI Bill, or getting, like, all these federal subsidies, any number of things. Or basically just tricking families into paying huge amounts of money when they could have attended a much more sensible public university, you know, a private nonprofit university that doesn't charge an arm and a leg. +So, I think that we are going to have an impact. I just want to say that I don't think that this is a panacea. It's going to take many years for freeCodeCamp to be adopted by a whole lot of people. It will take a long time for employers to look at the freeCodeCamp degree and say, "Oh, this is comparable to a computer science degree from..." say, Ohio State, or UT Austin, or something like that, right? Like, it's going to be a long time before we can get that level of buy-in. +I don't want anybody listening to say, "Oh, I'd love to get a computer science degree. I'm just going to hold out and get the degree from freeCodeCamp." Like, my humble advice would be: go to a community college, then go to a state school. Get that four-year computer science degree. It is worth its weight in gold. But you don't want to accumulate a lot of debt. Just try to like, minimize your debt in the meantime. +And, hopefully, over time, you know, the free model will prove out, and it'll just be a whole bunch of alumni supporting freeCodeCamp. And that's the dream is that, like, you know, Michael Bloomberg gave a billion dollars to Johns Hopkins University, a billion dollars. Like, Johns Hopkins never needs to charge tuition again with a billion dollars. They can just basically operate their institution off the interest from that, right? And lots of institutions...like, Harvard has, I don't know, like, 60-plus billion dollars in their endowment, right? +So, the idea would be freeCodeCamp continues to get this, you know, huge alumni network of people who are doing great and who went to freeCodeCamp and who basically donate back in. And then, we can essentially have the deep pockets subsidizing everybody else who's just at the beginning of their careers who don't have a lot of earning power. +You know, when I was a teenager, when I was in my 20s, I worked at convenience stores. I worked at Taco Bell. I did all kinds of, like, literally showing up at 6:00 a.m. to mop the grocery store-type jobs, right? And that is not a path to being able to afford an education in 2023. University tuition is out of control. It's, like, ridiculously high. It's grown way faster than inflation for decades. So, what can we do to alleviate that pressure? In my humble opinion, we just need to come up with free options and support ultra-low-cost options that are already out there. +VICTORIA: I was going to ask, but you might have already answered this question somewhat. But I get this question a lot for people who are interested in getting into tech, whether they should get a computer science degree or go to a bootcamp. And I think you've mentioned all the positive things about getting a degree. I'm curious if, in your degree program, you would also tailor it more to what people might expect in a modern tech market and industry in their first job. +QUINCY: Yeah. So, the way that we're developing our degree program is we essentially did, like, an analysis of the top 20 computer science programs in the United States: Carnegie Mellon, Berkeley, Stanford, MIT, all those schools that you would think of as being, like, really good computer science programs. And we basically drew a best-fit line through all their course offerings and looked at all their textbooks and everything that they cover. And, essentially, we're teaching a composite of those top 20 programs. +Now, there are some things that, surprisingly, those programs don't offer, such as a course on ethics. It's something like 13% of those degree programs require an ethics course. And I think every developer should take a developer ethics course, or at least some sort of philosophy course to, like, understand what does it mean to be a good person? [laughs] Like, what is, you know, an anti-pattern? What is Blackhat user experiences? [laughs] I'm like, when should I, like, raise my hand during a meeting to say like, "Hey, should we really be doing this?" You know. +So, ethics–security courses–I was surprised that not very many of those degree programs offer a course in information security, which I believe should be required. So, I'm kind of editorializing a little bit on top of what the composite says. But I feel very strongly that, you know, our degree program needs to have those courses. But in general, it's just everything that everybody else is teaching. +And yes, like, a coding bootcamp...I've written a lot about coding bootcamps. I wrote, like, a Coding Bootcamp Handbook, which you can just Google, like, "Coding bootcamp book" or something like that, probably then you can find it. But, essentially like, those programs are usually private. Even if it's at a big, public university, it's often run by a big, private for-profit bootcamp chain. I don't want to say, like, all bootcamps are a bad deal, but buyer beware [laughs]. +Frankly, I don't think that you can learn everything you need to know to be a software engineer within the compressed timelines that a lot of those bootcamps are operating under. There's a reason it takes four years to get a computer science degree because: there's a tremendous amount of math, programming, computer science, engineering knowledge that you need to cultivate. +And you can absolutely get a developer job without a computer science degree. I don't have a computer science degree [chuckles], and I worked as a software engineer, right? And I know plenty of people who are doing that that didn't even go to college, right? People who were truckers or people who were doing construction work who just sat down and hit the books really hard and came out the other side being able to work as a software developer. But it is going to be vastly easier for you if you do have a computer science degree. +Now, if you're in your 30s, if you've got kids, if you've got a whole lot of other obligations, should you go back to school? Maybe not. And so, it's not cut and dry, like, oh, just drop whatever you're doing and go back to...The situation is going to be nuanced. +If you've already got a job working as a developer, should you go back and get a CS degree? Probably not. Maybe you can get your employer to pay for you to go to, like, a CS master's program, for example. There are a lot of really good online master's degree programs. Like, Georgia Tech has a master's in computer science that is very affordable, and it's very good. Georgia Tech is one of the best computer science programs in the United States. +So, definitely, like, everybody's situation is going to be different. And there's no blanket advice. I would just be very wary of, like, anybody who's talking to you who wants your money [laughs]. freeCodeCamp will never want your money for anything. Like, we would love to have your donation long after you're a successful developer. You turn around and, like, send the elevator back down by donating to freeCodeCamp. +But just be skeptical and, like, do your research and don't buy into, like, the marketing speak about, like, being able to get a job immediately. "Oh, it's easy. Anybody can learn to code." Like, I do believe any sufficiently motivated person can learn to code. But I also believe that it's a process that can take years, especially if you're doing the safe thing and continuing to work your day job while you learn these skills over a much longer period of time. +I don't believe learning in a compressed kind of bootcamp...like, if you think about, you know, bootcamp in the military, like, this is, like, you're getting shipped away, and you're doing nothing but, like, learning these skills and everything like that. And I don't think that that's right for programming, personally [laughs]. +I think there's a reason why many of these programs have gone from 9 weeks to 12 weeks to 6 months. Some of them might be, like, an entire year now. It's because it's them kind of admitting that, like, oh, there's quite a bit to learn here, and it's going to take some time. And there's diminishing returns to learning a whole bunch of hours in a day. I think you'll make much better gains studying programming 1 hour a day for 365 days than you'll make studying, you know, 8 hours a day for, like, two months or something like that if that makes sense. I'm not sure if the math works out there. +But my point is, it's totally fine, and it's actually quite optimal to just work your day job, take care of your kids, spend time with your parents, you know, do all those things, hang out with friends and have a social life, all those things in addition to just having programming be one of those things you're working on in the background with your mornings or your evenings. +WILL: Tell us a little bit about your podcast. Yeah, tell us kind of what's the purpose of it and just the history of it. +QUINCY: Yeah. Well, I learned from the best. So, I'm a longtime listener of this podcast, of course. My friend, Saron Yitbarek, hosts CodeNewbie, which is an excellent podcast, the Changelog, which is an open-source podcast. I've had a great time interviewing the Changelog hosts and being on their show several times. So, I basically just learned as much as I could, and then I just went out and started interviewing people. +And so, I've interviewed a lot of devs. I've interviewed people that are, like, learning to code driving Uber. I've interviewed the founder of Stack Overflow [chuckles], Jeff Atwood. I'm going to interview the founder of Trello in a few weeks when I'm back out in New York City. And I do my interviews in person. I just have my mobile studio. When I'm in San Francisco–when I'm in New York, I just go around and do a bunch of interviews and kind of bank them, and then I edit them myself and publish them. +And the goal is just to give people exposure to developers. What are developers thinking? What are developers talking about? What do developers care about? And I try to hit, like, a very broad range of developers, try to talk to as many women as possible and, you know, striving for, like, 50% representation or better on the podcast. And I talk to a lot of people from different countries, although that's a little harder to do when you're recording in person. I may break down and do some over Zencastr, which is a tool we used in the past. I just like the spontaneity and the fun of meeting with people in person. +But yeah, it's just like, if you are looking for, like, long-form, some of these are, like, two-and-a-half-hour long discussions, where we really delve into people's backstory and, like, what inspired them to become a developer, what they're learning along the way, how they feel about different aspects of software development. Like, for example, earlier, Will, you mentioned impostor syndrome, which is something I think virtually everybody struggles with in some capacity, you know, the freeCodeCamp podcast, tune in [chuckles] and subscribe. +And if you have any feedback for me, I'd love to hear it. I'm still learning. I'm doing my best as a podcast host. And I'm constantly learning about tech as it evolves, as new tools come out, as new practices are pioneered. There's entire new technologies, like large language models, that actually work. And, I mean, we've had those since, like, the '60s, like, language models and stuff, but, like, only recently have they become incredibly impressive, exploring these tools and exploring a lot of the people behind them. +VICTORIA: Okay, great. Do you have any questions for me or Will? +QUINCY: Yeah. What inspired you all to get involved in tech, in...I don't know if somebody...did somebody at thoughtbot actually approach you and say, "Hey, we want you to run this"? Or was it something where like, "I'd love to run this"? Like, because podcasting is not easy. You're putting yourself out there. You're saying things that are recorded forever [laughs]. And so, if you say something really naive or silly or something like that, that's kind of always there, right? It takes a certain amount of bravery to do this. What got you into hosting this podcast? +VICTORIA: For me, I mean, if I go way back before getting into tech, my mom she got her undergraduate degree in horticulture to become a florist, and then realized she couldn't make any money off that and went back to school for computer science. And so, she taught me how to use a computer really early on. And when I was in school, I had started in architecture, and then I wanted to change into business intelligence. But I didn't want to apply to the business school, so I got a degree in economics and a job at the IT help desk. +And then from there, I was able to kind of transition into tech as a teacher, which was oddly enough...my first job in tech was training a 400-person program how to do, like, version management, and peer reviews [laughs], and timekeeping. And the reason I got the job is a friend from rock climbing introduced me, and he's like, they're like, "Oh, well, you train people how to rock climb. You can train people how to, like, do this stuff." [laughs] I'm like, oh, okay, that sounds great. +But anyways, I worked my way up into project management and ended up getting my masters in IT. And when I came to thoughtbot, I had just moved to California, and I wanted to rebuild my network. I had a big network in D.C., organizing meetups and DevOps D.C., Women Who Code, teaching people, and communicating. And I ran a very small podcast there with a friend. +So, when I joined thoughtbot, a podcast was a great way to just meet different people, expand my network, give people something to talk to me about when I go to events [laughs] that's not just, like, let me sell you some DevOps work. For me, it's been really fun to just reach out to people that we admire in the community and hear their story, and a little bit about them, and what advice they have for themselves or for other people. And, usually, that ends up benefiting me as well. So, it's been very fun for me. +QUINCY: So, your less conventional path into tech combined with your own experience doing podcasting, it sounds like you were a natural choice for hosting a podcast. +VICTORIA: Right. And I think I said before we started the show I didn't realize that it was such a well-loved and long-running podcast [laughs] [inaudible 49:01]. But I think we've really come into our own a little bit with hosting, and it's been super fun to work with Will and Chad on it as well. +QUINCY: Awesome. And, Will, what's your story, man? How did you get onto the coveted Giant Robots Smashing into Giant Robots podcast? +WILL: I actually went to college for sports medicine, and I was on track to go to med school, but my senior year...which I wish I would have had this conversation with myself a lot earlier, didn't have to do the hard work that I did at undergraduate. But my senior year, I was like, why am I really going to med school? And, honestly, it was more for the money, for the...yeah, more for the money. I just wanted to get paid a lot of money. I was like, yeah, that's not going to sustain me. I need to just pivot. +So, I pivoted–started working at some nonprofits. And I ended up losing my job and got another job at Buckle, the clothing store, which was not a great fit for me. It helped me provide, but that's just not who I am. I'm not a fashion icon [laughs]. And then I changed to a travel agency insurance company, which it paid the bills. I wasn't passionate about it at all, and it paid the bills. And I was still struggling from losing my job. It was the first time that I lost my job. +And my spouse came to me one day and is like, "All right, we're going to have the serious talk." And we almost flipped roles because that's usually who I am. I'm like, "All right, let's have a real talk. Let's get down to it." But I was just in a bad place. And she was like, "All right, we have to change because we can't keep going down this path." +So, she was like, "If you had a choice to do anything, what would you want to do?" And I was like, "Well, probably something with computers and coding because I never had that opportunity when I was growing up because of the small town." And she looked at me, and she's like, "Go sign up right now." And I was like, okay, I'm going to sign up. +When you mentioned that you made a transition in your 30s, I was around my 30s when I made the transition into coding. And so, it was a big transition. It was a big pivot for me because I'm having to learn, almost like I'm in college again, which was eight years ago. And so, it was just tough, and it wasn't new. So, that's how I got into coding. +How I got on the podcast: I think I was talking to Chad and my direct report. I was just talking to them about challenging myself, and so it was multiple things. But, like, writing blog posts that was actually very challenging to me. I still don't like to write. It's not my favorite thing. Give me math or something like that or science; that's where I feel at home. But whenever, you know, you talk about writing and stuff, I can do it, and I'm decent at it. But it's not something that I feel comfortable in. The same thing with the podcast. +The reason why I got on here is because I wanted to get out of my comfort zone and I wanted to grow. And I also wanted to get a chance to talk to people who's making a difference–who's impacting the world. So, like, this conversation today is like, yes, this is why I wanted to be a part of this podcast. So yeah, that's how I got started in tech and on the podcast. +QUINCY: Awesome, Will. I'm thrilled that you went ahead and persevered and got into tech. It doesn't sound like it was a straight line, and it rarely is for people. But I'm always excited to meet somebody who learned to code in their 30s who stuck with it and is prospering as a result. So, congratulations to you. +WILL: Thank you. +VICTORIA: I'm still learning. I haven't quite got [inaudible 52:42] "Hello, worlds," multiple times [laughs]. But I don't really code every day for my job. I just kind of need to know what stuff is to be able to talk to people and in that way as a managing director. So, I appreciate Will bringing that backstory to this episode in particular. What else? Any other final takeaway that you'd like to leave our listeners with? +QUINCY: I just want to thank you all for continuing to host this podcast, thoughtbot for operating the excellent Playbook, which, for anybody listening who is unfamiliar with, you should check it out. Again, it's just chock full of institutional wisdom accumulated over the years. +And I hope everybody out there who's thinking about taking the plunge and learning coding or software development, or even, like, a semi-technical area of being in the software development process of learning visual design, learning how to do user experience research, any number of the different roles in tech, I hope you'll go for it. And I hope you will be as undaunted as you can. And just know that freeCodeCamp and the freeCodeCamp community we are in your corner. +If you need to learn something, there's a very good chance that we have some tutorials written by thoughtful teachers who want people like you to come forward and like, read these resources and use it. There's a saying: like, the thing that programmers want the most is to have their code running in production somewhere. And, as a teacher, the thing you want the most is for you to have students, for you to have learning resources out there that are making a positive difference. +So, again, I just count my blessings every day that I'm able to be involved in this community. I hope anyone listening who wants to transition into tech or to become even more technical gets involved in the freeCodeCamp community as well. We welcome you. +WILL: Are there any opportunities? I know we talked about donations. So, for one, where can they go if they want to donate? And then also, like, you know, if developers want to get to be a part of the open-source network you have, is that possible? And how can they do that? +QUINCY: Absolutely. So, if you want to donate to freeCodeCamp, just go to donate.freecodecamp.org. And you can become, like, a $5 a month donor, if you'd like. If you want to give a larger amount, I've got this article; just Google "How to Donate to freeCodeCamp." And I've written this detailed guide to, like, all the different ways like mailing checks. +We had a gentleman who passed away and left a whole lot of money for freeCodeCamp in his will. So, those kinds of legacy gifts are definitely something. We've had people donate stock, like, any number of different things. I will bend over backwards to make sure that we can receive your donation, and we can give you a tax receipt so you can deduct it from your taxes as well if you'd like. +And then, for contributing to freeCodeCamp, of course, we're an open-source project, and we welcome your code contributions. We have spent a great deal of time trying to make freeCodeCamp as hospitable as possible for both new developers who want to get involved and more senior developers who just want to do some, like, 20%-time type contributing to open-source projects: contribute.freecodecamp.org. So, again, donate.freecodecamp.org and contribute.freecodecamp.org. Those will take you where you need to go. +VICTORIA: Wonderful. Thank you so much again, Quincy, for joining us. +And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you could find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Quincy Larson. + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP.

+ +

Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox!

+ +
+ +

Quincy Larson is the founder of freeCodeCamp.org, which helps people learn to code for free by creating thousands of videos, articles, and interactive coding lessons–all freely available to the public. Quincy shares his journey from transitioning from teaching into software development, how freeCodeCamp was born out of his desire to make educational systems more efficient through coding, and discusses the early challenges of bootstrapping the platform, and how it has now grown into a 501(c)(3) nonprofit organization.

+ +

Quincy and hosts Victoria and Will, discuss the platform's technical architecture, especially their global server distribution and decision to rely on volunteer-led translation efforts rather than machines to ensure both the quality and human touch of their educational content. He also talks about the state of free and low-cost degree programs, the student loan crisis, and the ongoing debate between traditional computer science degrees and coding bootcamps.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robot Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Quincy Larson, Host of the freeCodeCamp Podcast, Teacher, and Founder of freecodecamp.org, a community of people around the world who are learning to code together. Quincy, thank you for joining us.

+ +

QUINCY: Yeah, thanks for having me, Will and Victoria.

+ +

VICTORIA: Yeah, thank you for being here. So, I understand that you made a big shift personally for yourself from California to Texas. How has that been for your family and for, you know, as a founder who is running a nonprofit?

+ +

QUINCY: Yeah, things are going great. It was a big move. We had some kids, and it was difficult to find, like, a good place to live in California that didn't cost, like, millions of dollars [laughter]. And so, at least in the San Francisco Bay Area, we were living in East Bay.

+ +

I grew up here in Texas and Oklahoma. And I was like, well, maybe we could go back to the southwest, and so we did that. And we were able to come back and comfortably purchase a home here in Plano, Texas. We were able to find one that was, like, really close to a really good public school system. And so, every morning, I'm able to walk my kids to school.

+ +

And I'd say that Texas has been a great change from California, where I lived for seven or eight years over there. And I love California. Texas has a lot of great things about it, too. It is a little bit hotter than California. It doesn't quite have California's Mediterranean climate, but it's been great here. I like it. And I would say if people are thinking about moving to Texas from California, there are definitely some really good spots of Texas that I think they'll feel really comfortable in.

+ +

WILL: That's awesome, yeah. I'm originally from Louisiana. So, you're bringing back, like, memories of me growing up, always going to Texas and stuff. And I know exactly where Plano is, so that's amazing. How has it been with your kids? Because we were talking, and you said your kid recently started school. How's that been?

+ +

QUINCY: Yeah, so my daughter started school a couple of years ago, and she just turned eight. And my son he's turning six this weekend. He just started kindergarten. We were having him take classes at the YMCA some pre-school. And he went from doing that for the first few hours of the day, and then we'd pick him up and bring him home and eat lunch with him and everything.

+ +

And now he's got to go to school from, like, 7:00 a.m. to, like, 3:00 p.m. And he's been freaking out, like, "Why is school so long? Oh my goodness, I'm so tired all the time," [laughs]. So, he didn't realize that school would be as involved a process. He was all excited. But now he's complaining about, like, just the sheer length of school. But meanwhile, my wife and I we're just, like, celebrating because we actually have some time around the house where we can get work done without having kids running around causing chaos [laughs]. So yeah, I think he's adapting. He's making friends. We're doing playdates and stuff, and he's having fun. It's just a transition, you know.

+ +

But it is nice because before, I would walk my daughter to school, and that was a very quick, 10-minute round trip, and then I'd walk my son to school. And that was, like, an hour round trip because we walked all the way to the YMCA. And I would do that to kind of toughen him up and get him walking a lot. It was a huge chunk of time. And now I can just grab both, one [inaudible 4:04] hand in each hand, and walk them to school, and drop them off, and be done with it and get back to work. So, it's definitely nice having both at the same school.

+ +

VICTORIA: I love the work-life balance and that you were able to find and live somewhere that's affordable and has enough space for your family. And I wonder if we can draw a connection there between achieving that kind of lifestyle and learning to code, and what the mission of freeCodeCamp is for you, and what that means to people and changing careers.

+ +

QUINCY: Absolutely. So, my background is in teaching. And I was a teacher and a school director at schools here in the U.S. and over in China. And that involved me being on campus, like working directly with my admin staff, with my instructional staff, and working directly with students. So, working remotely was kind of, like, a foreign concept way back in, like, 2010 or so 2011 when I started my transition into working as a software developer.

+ +

But being able to work remotely has been a real game changer for me. And also, you can imagine, like, being a developer, you can command much larger compensation, and you have a lot more career options than being a teacher or a school director. So, it's given me a lot of agency in what I wanted to do. Even before, you know, starting freeCodeCamp, when I was working as a software developer and doing freelance work and stuff, I was able to do everything remotely. And that just gave me a ton of flexibility.

+ +

So, the way that I learned to code personally was I wanted to help our school be more efficient. A lot of our teachers, a lot of our admin they were spending all day kind of chained to their desk entering information into computers for compliance reasons, to be able to produce great reports, to be able to produce attendance reports, immigration documents, all those things. And I just thought, like, is there a way that maybe I could automate some of this?

+ +

And I didn't know anything about programming. I was about 31 years old. I was just sitting at my desk, and I just started kind of, like, Googling around and learning some very basic programming. And with that, over the course of a few months, I was really able to transform how the school ran. And we, like, won an award. And, like, a whole bunch of the students were, like, having a great time because they were spending so much more time with their teachers. And they were like, "Hey..." like, telling all their friends and family to transfer into the school. So, it was a massive success.

+ +

And I thought, wow, if one person who doesn't even really know that much about programming can effect such a change with just a little bit of programming skills, imagine what I could do if I actually learned to code properly, so [chuckles] I did that. I spent about nine months going to hackathons every weekend, and reading a lot of books, and using a lot of open courses online, like from MIT, from Stanford, and I kind of taught myself to code for free.

+ +

And then, I was able to get a job as a developer at a mid-size tech startup in California. And from there, I just learned more and more, and it was amazing. And it was an amazing transformation for me personally. And I thought, well, I want to help other people be able to do this because I know so many people out there would like to be working in a field where they have more conversation, a higher degree of control. They get to do creative work instead of, you know, tedious work.

+ +

As a developer, you're constantly doing new stuff because code is infinitely reproducible. So, you could always just go back to code you've previously written if you needed to solve the same problem again. So, you're always in this kind of learning mindset. You're always in this problem-solving mindset. And it's really thrilling. It's just great, impactful work. So, I wanted to help more people be able to do that, hence starting a bunch of different projects that people didn't care about and then eventually starting a project that people did care about, which is freeCodeCamp. And since then, just kind of leading this project in trying to help as many people as possible learn to code.

+ +

WILL: So, I was looking at your website. And I didn't even realize this until I was doing more research for the podcast, but you have over 10,000 tutorials, and they're in different categories. I saw you just recently released one on finance, which I actually bookmarked it because I'm going to go through it and look at it. You help more than a million people every day. So, how was it when you first started out? Like, how was, I guess, you could say, the grind? How was it in those early days?

+ +

QUINCY: I'm a big advocate of, you know, for work-life balance, but, like, I kind of, like, exclude founders from that. I really do think that if you're trying to get something started, you're going to have to work really hard and probably way beyond what would be reasonable for a person who's getting a salary or working at an existing company if you're trying to get things started. So, I mean, it was, like, 100-hour weeks, maybe 120 some weeks [laughs].

+ +

I would sleep and just wake up and get to my desk and try to, like, put out fires, fix the server, improve the codebase, respond to learners in the community who had feedback, deal with support issues. Like, I was basically doing everything myself. And gradually, we were able to, like, build out the team over a long period of time. But really, the first few years was me self-financing everything with just my teacher savings. I spent, like, $150,000 of my own money just trying to keep freeCodeCamp going.

+ +

For the first couple of years, we got tax-exempt status from the IRS. When that finally happened, I was like, great, like, let's go out and see if we can get some people to donate. So, we started asking people who were using freeCodeCamp if they'd be willing to donate $3 a month and eventually $5 a month, and we were able to support the organization through that. Really, it's just like a grassroots donor-supported effort.

+ +

And then, we've been able to get some grants from Linux Foundation, and From Google, from Microsoft, from a whole lot of other big tech companies, and from some other nonprofits in the space. But mostly, it's just been, like, individual donors donating $5. And if you get enough people doing that, you get, like, a budget where you can actually pay for, you know, we have more than 100 servers around the world serving freeCodeCamp in, like, six different languages.

+ +

We have, you know, all these other, like, initiatives. Like, we've got Code Radio, where you can go listen to Lo-fi while you're coding. And there are servers all over the world. And you can change the bit rate to suit whatever data you have and everything. Like, we wanted to just offer a whole lot of different services. We have mobile apps now. We've got an iOS and an Android app for freeCodeCamp. And then, of course, we've got the podcasts. We've got four podcasts: one in English, which I host, and then we've got one in Spanish, one in Portuguese, and one in Chinese.

+ +

VICTORIA: Yeah, I absolutely want to ask you more about your podcasts. But first, I wanted to hear–can you tell me a little more about the decision to be 501(c)(3) or a nonprofit status? And were you always firm in that decision? Do people question it? And what was the real reasoning and commitment to that formation?

+ +

QUINCY: I guess I would consider myself an idealist. Like, I genuinely believe that most educational endeavors should be, you know, nonprofit. They should be driven by either governments or by charities. I'm always kind of skeptical when there's, like, some late-night TV commercial, like, "Viewer, we'll help you get our degree," and it's from, like, a private for-profit university, something like that.

+ +

So, I was like, in education...and I don't think everything in society needs to be that way, but I do think, like, education and, to an extent, healthcare these should be led by charities. Like, you know, the Red Cross, or, like, Doctors Without Borders, or churches, you know, own many of the universities, many of the hospital systems in the United States. I think that's a good thing. I think it's a very good thing that it's not just, you know, private profit-maximizing, market incentive-bound organizations that are doing all the stuff in education and in healthcare.

+ +

I wanted to try to create something that, like, a lot of other people would see and say, "Oh wow, this charity can actually survive. It can sustain itself without raising a bunch of VC, without going public," or any of those things that a for-profit entity would do. And, again, I just want to emphasize, like, I don't think that iPhones should be made [chuckles] by nonprofits or anything like that.

+ +

I'm just saying, like, for the purpose of actually educating people, the incentives are not necessarily aligned when you're trying to get money from...especially when you're talking about people that 60% of people on earth live off less than $10 a day. Those people should be spending their money on food. They should be spending their money on shelter. They should be spending their money on family. They should not be spending money on online courses, in my humble opinion. Like, online courses should be freely available to those people.

+ +

So, to some extent, freeCodeCamp, we want to make sure that everybody everywhere in the world has access to first-rate learning resources on math, programming, computer science, regardless of their ability to pay. So, that's kind of, like, the ideal logical [inaudible 12:19], I guess, of freeCodeCamp. We kind of live that. Like, we're really serious. We will never pay, well, anything on freeCodeCamp. We won't account email gate anything. We are, I guess, absolutist in the sense that we want all of freeCodeCamp's learning resources to be free for everyone.

+ +

Because of that, it made sense to like, incorporate as a 501 (c)(3) public charity. And so, we're tax-exempt. And people who donate to freeCodeCamp they can, you know, deduct it from their U.S. taxes. If a large company or even a small startup...we've had lots of startups like New Relic, like Retool, we've had Postman, Hostinger, a whole lot of different startups and mid-sized tech companies, Pulumi, Appsmith, they've all given us these grants that we can use to develop courses. So, we can often develop courses incorporating those resources. But that's tax-exempt, right? They can deduct that from their U.S. taxes.

+ +

So, it's a big incentive for other people to partner with us and for people to donate funds to us. And it allows us to have the interests aligned in the sense that only people who have, you know, free cash flow or who have disposable income those are the people that are supporting freeCodeCamp.

+ +

For the people that are, you know, single parents or that are taking care of their aging relatives, or are already working two jobs, or are completely unemployed and don't have any funds to speak of that are using the public library computer to access freeCodeCamp, right? Or using freeCodeCamp on a $50 prepaid phone from Walmart or something like that, right? Like those people can still use freeCodeCamp, and we can have the people who do have resources subsidize everyone else.

+ +

WILL: Wow. I absolutely love that because...and I wish freeCodeCamp was around whenever I was in, like, high school and, you know, the early 2000s because we just didn't have the resources because I grew up in a small town in Louisiana. And this could have been so beneficial to that community because, like you said, we didn't have the resources–someone to teach coding there. There was no developers around that town that I was in. So, I really appreciate that you're doing this for everyone.

+ +

And I know for me even...so, when I reached out to you, I did it because I was excited because I've used freeCodeCamp so many times, so many times to learn just in my journey to become a senior developer. Like, freeCodeCamp was one of the resources that I used because, one, it was free. But it wasn't...I think sometimes you can get free resources, and it's not great quality almost. Like, it's almost like you're more confused than before. But with freeCodeCamp, it was very, very amazing quality. And it was very clear on what I was learning. Honestly, thank you for helping me grow as a developer, just, honestly, thank you for that.

+ +

QUINCY: Absolutely, Will. I feel honored to have helped you. And, yes, we want to help all the kids who are growing up in rural Louisiana or...I'm from, you know, Oklahoma City, not, like, the biggest, most prosperous city in the United States. Like, I want to help all of my friends who growing up who were eating meals provided by the state school system or my older friends who are on disability. Like, I want to make sure that they have resources, too.

+ +

And in the process of doing that, it's a privilege to also serve all the working software engineers like you out there who just need, like, a reference resource or, like, oh, I've heard about Bun JS or Tailwind CSS. Or something like, I'm going to watch this three-hour course where I'm going to learn how to do Flutter. Like, freeCodeCamp has a 37-hour Flutter course. So, we've got, like, all these courses on using OpenAI APIs and things like that, too, right?

+ +

So, it's not just for beginners, but we definitely want to, like, first and foremost, we want to serve people who we're kind of, like, the resource of last resort for, if you want to think of it that way. Like, only freeCodeCamp can help these people. Sure, they can probably use some other free courses on YouTube. And there are lots of other blogs that publish good tutorials and stuff. But freeCodeCamp is like an organized effort, specifically to help those people in need. And just kind of a side benefit of it is that you know, more established, experienced devs like you also get kind of, like, some benefit out of it as well.

+ +

WILL: Whenever you were a developer, and you decided to start freeCodeCamp, how many years of experience did you have? And how did you overcome impostor syndrome, not only as a developer but as a founder? Because I feel like just overcoming it as a developer is hard, but you were also, you know, like you said, you know, handling everything for freeCodeCamp. So, how did you do that? And kind of tell us about that experience.

+ +

QUINCY: Yeah. So, I didn't really know what I was doing. I think most founders probably don't know what they're doing. And I think that's totally fine because you can learn while you're doing. And we live in the United States, which is a country that kind of rewards experimentation and does not punish failure as much as a lot of other cultures does. Even if you try really hard, you're going to learn a tremendous amount, and you're going to try your next project. And that's what I did. I tried...I launched several educational, like, open learning resource-type projects, and none of them made any dent at all [laughs] in the proverbial universe. Like, nobody cared.

+ +

Like, I would go and, like, I'd be talking to people. And I'd be explaining, like, "Oh, this solves this problem that you have." And you could kind of tell, like, people would sign in one time just to be polite, but then they'd never sign in again. So, it was very tricky to get traction. And I read a bunch of books. And I went to a lot of founder-focused meetups in San Francisco Bay Area. I had, like, moved out to San Francisco, specifically to try to, like, kind of make up for my deficit, the fact that I didn't know anybody because I was from Oklahoma City.

+ +

I didn't know anybody in tech. And I didn't have, like, a fancy, you know, pedigree from, like, Harvard, or Wharton, or something like that, right? Like, I went to, like, a state university, and I studied English, right? And [chuckles] so, I didn't even have, like, a CS degree or anything like that. So, I definitely felt like an impostor. I just had to kind of, like, power through that and be okay with that.

+ +

And it's something a little bit easier for me to do because, you know, I'm a White guy with glasses and a beard. And, like, nobody's walking up saying, "Are you sure you're a developer?" Or like, "Are you in marketing?" You know, like, the typical kind of, like, slight that they may say to somebody who doesn't necessarily look like me. And so I didn't have to deal with any of that nonsense, but there was still a lot of just self-doubt that I had to power through. And I think that was a big advantage for me. It was just, like, I was kind of, like, at war with myself and my own confidence.

+ +

In fact, I found the software development community, and especially the open-source community, to be incredibly uplifting and empowering. And, like, they want to see you win. They want you to sit down and build a really cool project over the weekend and in the hackathon and present it. And, you know, they want you to learn. They know that you know, everybody is going to learn at a different rate and that a lot of people are going to get discouraged and leave tech and just go back to working in whatever field they were working in before. And that's totally cool.

+ +

But I do feel that they're there to support you and to encourage you. And there are lots of different events. There are lots of different communities. I recently listened to the founder of Women Who Code, who was on this very podcast [laughs], Giant Robots Smashing Into Giant Robots, the greatest podcast name of all time. And, you know, there are people out there that are working very hard to make it easier for folks to get into tech. I think that that has been a huge part.

+ +

Even before freeCodeCamp, you know, there were Harvard professors–Stanford professors putting their entire coursework for free online. You could go to, like, different tech events around California, for example, where I was when I was learning to code. And there'd just be tons of people that were eager to, like, learn more about you and to welcome you. And there would be, you know, recruiters that would talk to you and say, "Well, you may not be ready yet, but, like, let's talk in six months," right?

+ +

And so, there was kind of, like, that spirit of you're going to get there. It's just going to take a lot of time. Nobody was telling me, "Oh, learning to code is easy," [chuckles] because it's not easy. There were lots of people that were, like, "Learning to code is hard. But you've got this. Just stick with it. If I could be of help, let me know," people who would pair program with me to help me, like, improve my chops, people who would volunteer to, like, look at my projects and give design feedback, all those kinds of things.

+ +

And I think you're going to find all those things on the web. You're going to find those things in the open-source community. freeCodeCamp has a forum where people volunteer their time and energy to help build one another up and help one another get unstuck on whatever projects they're working on, give feedback on projects. And so, I think, to a large extent, the very giving nature, I almost want to say, like, selfless nature, of the global software developer community that is what saved me. And that's what enabled me to transition into this field, even as a teacher in his 30s.

+ +

VICTORIA: It's interesting you say that. Because I feel as someone who hires engineers and developers, I love people who have teaching backgrounds because it means they're five-star communicators [laughs]. And I think that you know, in your job, when you're pairing with other developers, or you're talking to clients, in our case, that communicating what you're working on and how you're thinking about something is, like, 50% of the job [laughs].

+ +

For freeCodeCamp, I saw you have 40,000 people have found jobs after completing courses on there. I hope you feel like you've really, like, established some success here already. But what's on the horizon? What are you looking forward to in the next six months or six years with freeCodeCamp?

+ +

QUINCY: Yeah, I'll be happy to answer that. But I want to emphasize what you just said: communication is, like, half the job. That's something that thoughtbot has gotten really early on. And I'll tell you that thoughtbot Playbook was incredibly helpful for me as a software developer and also early on for freeCodeCamp's team. And I think a lot of teams make use of that open resource.

+ +

So, thank you for continuing to maintain that and kind of drive home that communication really is...like, meetings are essential [chuckles]. And it's not always just, like, leave me alone and let me go back to my cubicle and code. You know, I like to quote the old joke that, you know, weeks of coding can save you hours of meetings because I really do believe that communication is core.

+ +

So, to answer your question about where freeCodeCamp is headed in terms of what kind of impact we'd like to have, I feel like we're just getting started. I feel like pretty much every Fortune 500 company wants to become a tech company in some way or another. Everybody is pushing things to the software layer because software is infinitely reproducible. It's so much easier to maintain software or fix things in production.

+ +

Like, you realize, oh, there's a big problem. Like, we don't have to recall all the cars back to the dealerships to go and open up the hood and fix this, you know, mechanical defect. If we're controlling all these things at the software layer, right? We can potentially just deploy a fix and tell people like, "Hey, version update [chuckles], you know, download this security patch," or whatever, right?

+ +

So, there are so many different things that you can do with software. I feel like the potential growth of the field of software and the number of software developers that the world will ultimately need...currently, we've got maybe 30 or 40 million developers on earth that are professional paid-to-code people. But I think that number is going to increase dramatically over the next 50 years or so.

+ +

And I'll go ahead and address the elephant in the room [laughs] because pretty much everybody asks me this question like, "Don't you think that, like, tools like large language models like GPT-4 and things are going to obviate the need for so many developers?" And I think they're going to make individual developers more productive.

+ +

But if you think about what code is, it's really extremely explicit directions for how to do something, whether you're using, you know, machine code, or you're using a scripting language like Python, or you're using English, and you're talking directly to the computer like you would on Star Trek. Essentially, you have to have a really deep understanding of the problem. And you need to know exactly what needs to be done in exactly what sequence. You may not need to manipulate bytecode like you would back in the '70s. But you are going to need to understand the fundamental problems, and you're going to need to be able to address it.

+ +

So, I'm optimistic that the number of developers is going to continue to grow. The developers are going to continue to command more and more, I guess, respect in society. And they're going to continue to have more and more agency in what they want to do with their careers and have more and more options and, ultimately, be able to command higher compensation, be able to work remotely if they'd like.

+ +

Developers will continue to be able to ascend through corporate hierarchies and become, you know, vice presidents or even executives like the CEO, right? If you look at a lot of the big tech companies, the CEO is a developer. And I think that that will continue. And the computer science degrees will continue to be extremely valuable.

+ +

So, what is freeCodeCamp working on now that we think will further help people? Well, we're working on a free four-year computer science degree, a Bachelor in computer science, and there's also an associate in mathematics that we're developing. And those are going to be a progression of 40 university-level courses that have labs and have a substantial block of lectures that you'll watch. And then, we'll also have final examinations and everything. And we're developing that curriculum. We've got one of the courses live, and we're developing the second one, and eventually, we'll have all 40. It'll take till the 2030s. But we're going to have those.

+ +

And then, once we have some longitudinal data about graduates and their success rates and everything, we are going to apply for the accreditation process, and we're going to get accredited as a university, right? Like, you can go through that process. Not a lot of organizations do that; not a lot of new universities are coming about in the 2020s. But it is something that can be done. And we've done a great deal of research, talked to a bunch of accreditors, talked to a bunch of university admins who go through the accreditation process. We think we can do it.

+ +

So, again, very long-term goal. But when you're a 501(c)(3) public charity, you don't have to worry about freeCodeCamp getting acquired or all the things that would traditionally happen with, like, a for-profit company. You have a lot more leeway to plan really far. And you've got, like, this really broad mandate in terms of what you want to accomplish. And even if, you know, creating a university degree program in the 2030s would not be a profitable endeavor that, like, a rational shareholder value-maximizing corporation would embark upon, it is the sort of project that, you know, a charity like freeCodeCamp could do. So, we're going to do it.

+ +

MID-ROLL AD:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: I think that's great. And, actually, you know, I got my master's in information technology and project management online way back when. So, I really like the availability of modern computer science bachelor's and master's being available at that low price point. And you're able to pursue that with the business structure you put in place.

+ +

I'm curious to kind of go back to something you said earlier on how widely available it is and how you spread out across all these multiple countries. Were there any technical architecture decisions that you had to make along the way? And how did those decisions end up turning out?

+ +

QUINCY: Absolutely. So, one of the things we did was we located servers all around the world. We're multi-cloud, and we've got servers in different data centers in, like, Singapore, Europe, Latin America, and we're trying to reduce latency for everybody. Another thing that we've done is, you know, we don't use, like, Google Translate to just translate all our different pages into however many languages are currently available on Google Translate; I think it's, like, more than 100. We actually have a big localization effort that's led primarily by volunteers. We have some staff that oversee some of the translation.

+ +

And essentially, we have a whole bunch of people working at translate.freecodecamp.org and translating the curriculum, translating the tutorials into major world languages. Most prominently would be Spanish, Chinese, Japanese, Korean, Portuguese, Ukrainian. Like, all these different world languages, there's, like, a freeCodeCamp version for those, and you can go into the menu, and you can choose it. And it's actually, like, hand-translated by native speakers of that language who are developers.

+ +

So, that's been another extremely, you know, time-intensive effort by the community. But we believe that, you know, the quality of the translations is really important. And we want that kind of human touch. We don't want kind of weird artifacts and typos that would be associated with machine translation. And we want to make sure that each of the challenges...because they're extremely tersely worded, again, communication is so important.

+ +

If you go through the freeCodeCamp curriculum, we try to use as few words as absolutely necessary to effectively communicate what the task the learner needs to accomplish is, and we try to, just in time, teach them concepts. We don't want to present them with a big wall of text. Read this 20-page PDF to understand how, you know, CSS, you know, borders work or something like that. No, we're teaching, like, kind of, like, just in time, like, okay, let's write this line of code. Okay, great, the test passed. Let's go to this next one. This test isn't passing. Here is some contextual-specific hints as to why your code is not passing, why you're not able to advance, right?

+ +

And we do projects [inaudible 30:30] to learn where we break everything down into steps. So, that's a lot of instructions that need to be very carefully translated into these different world languages to truly make freeCodeCamp accessible to everyone, regardless of whether they happen to be fortunate enough to grow up speaking English at a native level, right?

+ +

I would say that's our main consideration is, like, the localization effort but also just having servers everywhere and doing everything we can to comply with, like, all the different data rules and privacy rules and everything of all these different countries. It's a lot of work, but in my humble opinion, it's worth it.

+ +

WILL: I had, like, a two-part question because I wanted to loop back around. When you're talking about the free bachelor's program, one, does anything like that exist where you can get a bachelor-level program, and it's free? And then the second part is, how many countries are you in?

+ +

QUINCY: Yeah, so currently, lots of governments in Europe, for example, will offer free degrees that are kind of subsidized by the state. There may be some other kind of degree equivalent programs that are offered that are subsidized by corporations. For example, if you work at Starbucks, I think you can get a degree from Arizona State University. And that's a great benefit that Starbucks offers to people. Arizona State University, of course, being one of the biggest public universities in the United States in terms of enrollment.

+ +

As far as free degrees, though, in the United States, there's nothing like that where, like, literally anyone can just go and get a degree for free without needing to enroll, without needing to pay any sort of fees. There are tuition-free programs, but they still charge you fees for, like, taking exams and things like that.

+ +

What I like to call ultra-low-cost degree providers–there's Western Governors University, and there's University of the People. And both of these are accredited institutions that you can go, and you can get a degree for, you know, $5,000, $10,000, $15,000. And it's a full-blown four-year degree. Now, that is amazing. I applaud those efforts. I've enjoyed talking to the folks at those different schools.

+ +

I think the next step is to go truly free. There's nothing blocking you at all. You don't have to be banked. You don't have to have a credit card. You don't have to have any money. You can still get this degree. That's what we're chasing. And I think we'll get there, but it's just a lot of work.

+ +

WILL: So, it's blowing my mind. It's just blowing me away because, like, you know, we talk about the student loan crisis, I would say. The impact if...when—I'm not going to say if—when you do this, the impact that can have on there, have you thought about that? And kind of, if you have, what has been your thoughts around that?

+ +

QUINCY: Yeah, so there are $1.7 trillion in outstanding student loans in the United States. That's money that individual people, most of whom don't make a ton of money, right? Like, many of those people didn't actually finish the degree that they incurred the debt to pursue. Many of them had to drop out for a variety of different reasons or defer. Maybe they'll eventually finish those degrees. But as you can see from, like, the macroeconomic, educational, like, labor market data, like, having a partial degree doesn't make a big difference in terms of your earning power. You really need to finish the degree to be able to realize the benefits of having spent all that time studying, and a lot of people haven't.

+ +

So, yes, there are, like, a lot of people out there that went to medical school, for example, and they're working as physicians. And they are going to eventually be able to pay that off because they're doctors, and they're commanding a great compensation, right? And they've got tons of career options.

+ +

But if you studied English like I did and you incurred a whole lot of student debt, it could take a very long time for you to make enough money as a teacher, or as, like, a grant writer, or working at a newspaper, or something like that. Like, it can take you years to pay it off. And, in the meantime, it's just continuing to accumulate interest in your, you know, you might be a very diligent person who pays their student loan bill every single month, and yet, you could see that amount, the total amount that you owe continuing to grow despite this. That's just the nature of the time value of money and the nature of debt.

+ +

And I thank my lucky stars that I went to school back in, like, 2000. Like, my tuition was $1,000 a semester, right? I mean, it's incredible. But that was, like, at a state school, like, a public university in the middle of Oklahoma. And it's not, like, a university you've heard of. It's basically, like, the cheapest possible option. I think community colleges can make a huge dent. I always implore people to think more about community colleges.

+ +

I've talked with so many people on the freeCodeCamp podcast who were able to leverage community colleges and then transition into a, you know, research university, like a state school, and finish up their degree there. But they saved, like, basically half their money because they were paying almost nothing to attend the community college. And in California especially, the community colleges are just ridiculously worth it. Like, you're paying a few hundred dollars a course. I mean, it's just incredible value. So, I think the community college system is going to play a big role. But my hope is that, you know, freeCodeCamp can thrive.

+ +

And it'll take us years for people to realize because if you go on, like, Google Ads and you try to run a Google Ad for, like, any sort of educational-related topic, anything related to higher education, it's, like, hundreds of dollars per click because there are all these for-profit universities that make a tremendous amount of money from getting people who just came back from serving in the military and getting, like, huge chunks of their GI Bill, or getting, like, all these federal subsidies, any number of things. Or basically just tricking families into paying huge amounts of money when they could have attended a much more sensible public university, you know, a private nonprofit university that doesn't charge an arm and a leg.

+ +

So, I think that we are going to have an impact. I just want to say that I don't think that this is a panacea. It's going to take many years for freeCodeCamp to be adopted by a whole lot of people. It will take a long time for employers to look at the freeCodeCamp degree and say, "Oh, this is comparable to a computer science degree from..." say, Ohio State, or UT Austin, or something like that, right? Like, it's going to be a long time before we can get that level of buy-in.

+ +

I don't want anybody listening to say, "Oh, I'd love to get a computer science degree. I'm just going to hold out and get the degree from freeCodeCamp." Like, my humble advice would be: go to a community college, then go to a state school. Get that four-year computer science degree. It is worth its weight in gold. But you don't want to accumulate a lot of debt. Just try to like, minimize your debt in the meantime.

+ +

And, hopefully, over time, you know, the free model will prove out, and it'll just be a whole bunch of alumni supporting freeCodeCamp. And that's the dream is that, like, you know, Michael Bloomberg gave a billion dollars to Johns Hopkins University, a billion dollars. Like, Johns Hopkins never needs to charge tuition again with a billion dollars. They can just basically operate their institution off the interest from that, right? And lots of institutions...like, Harvard has, I don't know, like, 60-plus billion dollars in their endowment, right?

+ +

So, the idea would be freeCodeCamp continues to get this, you know, huge alumni network of people who are doing great and who went to freeCodeCamp and who basically donate back in. And then, we can essentially have the deep pockets subsidizing everybody else who's just at the beginning of their careers who don't have a lot of earning power.

+ +

You know, when I was a teenager, when I was in my 20s, I worked at convenience stores. I worked at Taco Bell. I did all kinds of, like, literally showing up at 6:00 a.m. to mop the grocery store-type jobs, right? And that is not a path to being able to afford an education in 2023. University tuition is out of control. It's, like, ridiculously high. It's grown way faster than inflation for decades. So, what can we do to alleviate that pressure? In my humble opinion, we just need to come up with free options and support ultra-low-cost options that are already out there.

+ +

VICTORIA: I was going to ask, but you might have already answered this question somewhat. But I get this question a lot for people who are interested in getting into tech, whether they should get a computer science degree or go to a bootcamp. And I think you've mentioned all the positive things about getting a degree. I'm curious if, in your degree program, you would also tailor it more to what people might expect in a modern tech market and industry in their first job.

+ +

QUINCY: Yeah. So, the way that we're developing our degree program is we essentially did, like, an analysis of the top 20 computer science programs in the United States: Carnegie Mellon, Berkeley, Stanford, MIT, all those schools that you would think of as being, like, really good computer science programs. And we basically drew a best-fit line through all their course offerings and looked at all their textbooks and everything that they cover. And, essentially, we're teaching a composite of those top 20 programs.

+ +

Now, there are some things that, surprisingly, those programs don't offer, such as a course on ethics. It's something like 13% of those degree programs require an ethics course. And I think every developer should take a developer ethics course, or at least some sort of philosophy course to, like, understand what does it mean to be a good person? [laughs] Like, what is, you know, an anti-pattern? What is Blackhat user experiences? [laughs] I'm like, when should I, like, raise my hand during a meeting to say like, "Hey, should we really be doing this?" You know.

+ +

So, ethics–security courses–I was surprised that not very many of those degree programs offer a course in information security, which I believe should be required. So, I'm kind of editorializing a little bit on top of what the composite says. But I feel very strongly that, you know, our degree program needs to have those courses. But in general, it's just everything that everybody else is teaching.

+ +

And yes, like, a coding bootcamp...I've written a lot about coding bootcamps. I wrote, like, a Coding Bootcamp Handbook, which you can just Google, like, "Coding bootcamp book" or something like that, probably then you can find it. But, essentially like, those programs are usually private. Even if it's at a big, public university, it's often run by a big, private for-profit bootcamp chain. I don't want to say, like, all bootcamps are a bad deal, but buyer beware [laughs].

+ +

Frankly, I don't think that you can learn everything you need to know to be a software engineer within the compressed timelines that a lot of those bootcamps are operating under. There's a reason it takes four years to get a computer science degree because: there's a tremendous amount of math, programming, computer science, engineering knowledge that you need to cultivate.

+ +

And you can absolutely get a developer job without a computer science degree. I don't have a computer science degree [chuckles], and I worked as a software engineer, right? And I know plenty of people who are doing that that didn't even go to college, right? People who were truckers or people who were doing construction work who just sat down and hit the books really hard and came out the other side being able to work as a software developer. But it is going to be vastly easier for you if you do have a computer science degree.

+ +

Now, if you're in your 30s, if you've got kids, if you've got a whole lot of other obligations, should you go back to school? Maybe not. And so, it's not cut and dry, like, oh, just drop whatever you're doing and go back to...The situation is going to be nuanced.

+ +

If you've already got a job working as a developer, should you go back and get a CS degree? Probably not. Maybe you can get your employer to pay for you to go to, like, a CS master's program, for example. There are a lot of really good online master's degree programs. Like, Georgia Tech has a master's in computer science that is very affordable, and it's very good. Georgia Tech is one of the best computer science programs in the United States.

+ +

So, definitely, like, everybody's situation is going to be different. And there's no blanket advice. I would just be very wary of, like, anybody who's talking to you who wants your money [laughs]. freeCodeCamp will never want your money for anything. Like, we would love to have your donation long after you're a successful developer. You turn around and, like, send the elevator back down by donating to freeCodeCamp.

+ +

But just be skeptical and, like, do your research and don't buy into, like, the marketing speak about, like, being able to get a job immediately. "Oh, it's easy. Anybody can learn to code." Like, I do believe any sufficiently motivated person can learn to code. But I also believe that it's a process that can take years, especially if you're doing the safe thing and continuing to work your day job while you learn these skills over a much longer period of time.

+ +

I don't believe learning in a compressed kind of bootcamp...like, if you think about, you know, bootcamp in the military, like, this is, like, you're getting shipped away, and you're doing nothing but, like, learning these skills and everything like that. And I don't think that that's right for programming, personally [laughs].

+ +

I think there's a reason why many of these programs have gone from 9 weeks to 12 weeks to 6 months. Some of them might be, like, an entire year now. It's because it's them kind of admitting that, like, oh, there's quite a bit to learn here, and it's going to take some time. And there's diminishing returns to learning a whole bunch of hours in a day. I think you'll make much better gains studying programming 1 hour a day for 365 days than you'll make studying, you know, 8 hours a day for, like, two months or something like that if that makes sense. I'm not sure if the math works out there.

+ +

But my point is, it's totally fine, and it's actually quite optimal to just work your day job, take care of your kids, spend time with your parents, you know, do all those things, hang out with friends and have a social life, all those things in addition to just having programming be one of those things you're working on in the background with your mornings or your evenings.

+ +

WILL: Tell us a little bit about your podcast. Yeah, tell us kind of what's the purpose of it and just the history of it.

+ +

QUINCY: Yeah. Well, I learned from the best. So, I'm a longtime listener of this podcast, of course. My friend, Saron Yitbarek, hosts CodeNewbie, which is an excellent podcast, the Changelog, which is an open-source podcast. I've had a great time interviewing the Changelog hosts and being on their show several times. So, I basically just learned as much as I could, and then I just went out and started interviewing people.

+ +

And so, I've interviewed a lot of devs. I've interviewed people that are, like, learning to code driving Uber. I've interviewed the founder of Stack Overflow [chuckles], Jeff Atwood. I'm going to interview the founder of Trello in a few weeks when I'm back out in New York City. And I do my interviews in person. I just have my mobile studio. When I'm in San Francisco–when I'm in New York, I just go around and do a bunch of interviews and kind of bank them, and then I edit them myself and publish them.

+ +

And the goal is just to give people exposure to developers. What are developers thinking? What are developers talking about? What do developers care about? And I try to hit, like, a very broad range of developers, try to talk to as many women as possible and, you know, striving for, like, 50% representation or better on the podcast. And I talk to a lot of people from different countries, although that's a little harder to do when you're recording in person. I may break down and do some over Zencastr, which is a tool we used in the past. I just like the spontaneity and the fun of meeting with people in person.

+ +

But yeah, it's just like, if you are looking for, like, long-form, some of these are, like, two-and-a-half-hour long discussions, where we really delve into people's backstory and, like, what inspired them to become a developer, what they're learning along the way, how they feel about different aspects of software development. Like, for example, earlier, Will, you mentioned impostor syndrome, which is something I think virtually everybody struggles with in some capacity, you know, the freeCodeCamp podcast, tune in [chuckles] and subscribe.

+ +

And if you have any feedback for me, I'd love to hear it. I'm still learning. I'm doing my best as a podcast host. And I'm constantly learning about tech as it evolves, as new tools come out, as new practices are pioneered. There's entire new technologies, like large language models, that actually work. And, I mean, we've had those since, like, the '60s, like, language models and stuff, but, like, only recently have they become incredibly impressive, exploring these tools and exploring a lot of the people behind them.

+ +

VICTORIA: Okay, great. Do you have any questions for me or Will?

+ +

QUINCY: Yeah. What inspired you all to get involved in tech, in...I don't know if somebody...did somebody at thoughtbot actually approach you and say, "Hey, we want you to run this"? Or was it something where like, "I'd love to run this"? Like, because podcasting is not easy. You're putting yourself out there. You're saying things that are recorded forever [laughs]. And so, if you say something really naive or silly or something like that, that's kind of always there, right? It takes a certain amount of bravery to do this. What got you into hosting this podcast?

+ +

VICTORIA: For me, I mean, if I go way back before getting into tech, my mom she got her undergraduate degree in horticulture to become a florist, and then realized she couldn't make any money off that and went back to school for computer science. And so, she taught me how to use a computer really early on. And when I was in school, I had started in architecture, and then I wanted to change into business intelligence. But I didn't want to apply to the business school, so I got a degree in economics and a job at the IT help desk.

+ +

And then from there, I was able to kind of transition into tech as a teacher, which was oddly enough...my first job in tech was training a 400-person program how to do, like, version management, and peer reviews [laughs], and timekeeping. And the reason I got the job is a friend from rock climbing introduced me, and he's like, they're like, "Oh, well, you train people how to rock climb. You can train people how to, like, do this stuff." [laughs] I'm like, oh, okay, that sounds great.

+ +

But anyways, I worked my way up into project management and ended up getting my masters in IT. And when I came to thoughtbot, I had just moved to California, and I wanted to rebuild my network. I had a big network in D.C., organizing meetups and DevOps D.C., Women Who Code, teaching people, and communicating. And I ran a very small podcast there with a friend.

+ +

So, when I joined thoughtbot, a podcast was a great way to just meet different people, expand my network, give people something to talk to me about when I go to events [laughs] that's not just, like, let me sell you some DevOps work. For me, it's been really fun to just reach out to people that we admire in the community and hear their story, and a little bit about them, and what advice they have for themselves or for other people. And, usually, that ends up benefiting me as well. So, it's been very fun for me.

+ +

QUINCY: So, your less conventional path into tech combined with your own experience doing podcasting, it sounds like you were a natural choice for hosting a podcast.

+ +

VICTORIA: Right. And I think I said before we started the show I didn't realize that it was such a well-loved and long-running podcast [laughs] [inaudible 49:01]. But I think we've really come into our own a little bit with hosting, and it's been super fun to work with Will and Chad on it as well.

+ +

QUINCY: Awesome. And, Will, what's your story, man? How did you get onto the coveted Giant Robots Smashing into Giant Robots podcast?

+ +

WILL: I actually went to college for sports medicine, and I was on track to go to med school, but my senior year...which I wish I would have had this conversation with myself a lot earlier, didn't have to do the hard work that I did at undergraduate. But my senior year, I was like, why am I really going to med school? And, honestly, it was more for the money, for the...yeah, more for the money. I just wanted to get paid a lot of money. I was like, yeah, that's not going to sustain me. I need to just pivot.

+ +

So, I pivoted–started working at some nonprofits. And I ended up losing my job and got another job at Buckle, the clothing store, which was not a great fit for me. It helped me provide, but that's just not who I am. I'm not a fashion icon [laughs]. And then I changed to a travel agency insurance company, which it paid the bills. I wasn't passionate about it at all, and it paid the bills. And I was still struggling from losing my job. It was the first time that I lost my job.

+ +

And my spouse came to me one day and is like, "All right, we're going to have the serious talk." And we almost flipped roles because that's usually who I am. I'm like, "All right, let's have a real talk. Let's get down to it." But I was just in a bad place. And she was like, "All right, we have to change because we can't keep going down this path."

+ +

So, she was like, "If you had a choice to do anything, what would you want to do?" And I was like, "Well, probably something with computers and coding because I never had that opportunity when I was growing up because of the small town." And she looked at me, and she's like, "Go sign up right now." And I was like, okay, I'm going to sign up.

+ +

When you mentioned that you made a transition in your 30s, I was around my 30s when I made the transition into coding. And so, it was a big transition. It was a big pivot for me because I'm having to learn, almost like I'm in college again, which was eight years ago. And so, it was just tough, and it wasn't new. So, that's how I got into coding.

+ +

How I got on the podcast: I think I was talking to Chad and my direct report. I was just talking to them about challenging myself, and so it was multiple things. But, like, writing blog posts that was actually very challenging to me. I still don't like to write. It's not my favorite thing. Give me math or something like that or science; that's where I feel at home. But whenever, you know, you talk about writing and stuff, I can do it, and I'm decent at it. But it's not something that I feel comfortable in. The same thing with the podcast.

+ +

The reason why I got on here is because I wanted to get out of my comfort zone and I wanted to grow. And I also wanted to get a chance to talk to people who's making a difference–who's impacting the world. So, like, this conversation today is like, yes, this is why I wanted to be a part of this podcast. So yeah, that's how I got started in tech and on the podcast.

+ +

QUINCY: Awesome, Will. I'm thrilled that you went ahead and persevered and got into tech. It doesn't sound like it was a straight line, and it rarely is for people. But I'm always excited to meet somebody who learned to code in their 30s who stuck with it and is prospering as a result. So, congratulations to you.

+ +

WILL: Thank you.

+ +

VICTORIA: I'm still learning. I haven't quite got [inaudible 52:42] "Hello, worlds," multiple times [laughs]. But I don't really code every day for my job. I just kind of need to know what stuff is to be able to talk to people and in that way as a managing director. So, I appreciate Will bringing that backstory to this episode in particular. What else? Any other final takeaway that you'd like to leave our listeners with?

+ +

QUINCY: I just want to thank you all for continuing to host this podcast, thoughtbot for operating the excellent Playbook, which, for anybody listening who is unfamiliar with, you should check it out. Again, it's just chock full of institutional wisdom accumulated over the years.

+ +

And I hope everybody out there who's thinking about taking the plunge and learning coding or software development, or even, like, a semi-technical area of being in the software development process of learning visual design, learning how to do user experience research, any number of the different roles in tech, I hope you'll go for it. And I hope you will be as undaunted as you can. And just know that freeCodeCamp and the freeCodeCamp community we are in your corner.

+ +

If you need to learn something, there's a very good chance that we have some tutorials written by thoughtful teachers who want people like you to come forward and like, read these resources and use it. There's a saying: like, the thing that programmers want the most is to have their code running in production somewhere. And, as a teacher, the thing you want the most is for you to have students, for you to have learning resources out there that are making a positive difference.

+ +

So, again, I just count my blessings every day that I'm able to be involved in this community. I hope anyone listening who wants to transition into tech or to become even more technical gets involved in the freeCodeCamp community as well. We welcome you.

+ +

WILL: Are there any opportunities? I know we talked about donations. So, for one, where can they go if they want to donate? And then also, like, you know, if developers want to get to be a part of the open-source network you have, is that possible? And how can they do that?

+ +

QUINCY: Absolutely. So, if you want to donate to freeCodeCamp, just go to donate.freecodecamp.org. And you can become, like, a $5 a month donor, if you'd like. If you want to give a larger amount, I've got this article; just Google "How to Donate to freeCodeCamp." And I've written this detailed guide to, like, all the different ways like mailing checks.

+ +

We had a gentleman who passed away and left a whole lot of money for freeCodeCamp in his will. So, those kinds of legacy gifts are definitely something. We've had people donate stock, like, any number of different things. I will bend over backwards to make sure that we can receive your donation, and we can give you a tax receipt so you can deduct it from your taxes as well if you'd like.

+ +

And then, for contributing to freeCodeCamp, of course, we're an open-source project, and we welcome your code contributions. We have spent a great deal of time trying to make freeCodeCamp as hospitable as possible for both new developers who want to get involved and more senior developers who just want to do some, like, 20%-time type contributing to open-source projects: contribute.freecodecamp.org. So, again, donate.freecodecamp.org and contribute.freecodecamp.org. Those will take you where you need to go.

+ +

VICTORIA: Wonderful. Thank you so much again, Quincy, for joining us.

+ +

And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Quincy Larson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP.

+ +

Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox!

+ +
+ +

Quincy Larson is the founder of freeCodeCamp.org, which helps people learn to code for free by creating thousands of videos, articles, and interactive coding lessons–all freely available to the public. Quincy shares his journey from transitioning from teaching into software development, how freeCodeCamp was born out of his desire to make educational systems more efficient through coding, and discusses the early challenges of bootstrapping the platform, and how it has now grown into a 501(c)(3) nonprofit organization.

+ +

Quincy and hosts Victoria and Will, discuss the platform's technical architecture, especially their global server distribution and decision to rely on volunteer-led translation efforts rather than machines to ensure both the quality and human touch of their educational content. He also talks about the state of free and low-cost degree programs, the student loan crisis, and the ongoing debate between traditional computer science degrees and coding bootcamps.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robot Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Quincy Larson, Host of the freeCodeCamp Podcast, Teacher, and Founder of freecodecamp.org, a community of people around the world who are learning to code together. Quincy, thank you for joining us.

+ +

QUINCY: Yeah, thanks for having me, Will and Victoria.

+ +

VICTORIA: Yeah, thank you for being here. So, I understand that you made a big shift personally for yourself from California to Texas. How has that been for your family and for, you know, as a founder who is running a nonprofit?

+ +

QUINCY: Yeah, things are going great. It was a big move. We had some kids, and it was difficult to find, like, a good place to live in California that didn't cost, like, millions of dollars [laughter]. And so, at least in the San Francisco Bay Area, we were living in East Bay.

+ +

I grew up here in Texas and Oklahoma. And I was like, well, maybe we could go back to the southwest, and so we did that. And we were able to come back and comfortably purchase a home here in Plano, Texas. We were able to find one that was, like, really close to a really good public school system. And so, every morning, I'm able to walk my kids to school.

+ +

And I'd say that Texas has been a great change from California, where I lived for seven or eight years over there. And I love California. Texas has a lot of great things about it, too. It is a little bit hotter than California. It doesn't quite have California's Mediterranean climate, but it's been great here. I like it. And I would say if people are thinking about moving to Texas from California, there are definitely some really good spots of Texas that I think they'll feel really comfortable in.

+ +

WILL: That's awesome, yeah. I'm originally from Louisiana. So, you're bringing back, like, memories of me growing up, always going to Texas and stuff. And I know exactly where Plano is, so that's amazing. How has it been with your kids? Because we were talking, and you said your kid recently started school. How's that been?

+ +

QUINCY: Yeah, so my daughter started school a couple of years ago, and she just turned eight. And my son he's turning six this weekend. He just started kindergarten. We were having him take classes at the YMCA some pre-school. And he went from doing that for the first few hours of the day, and then we'd pick him up and bring him home and eat lunch with him and everything.

+ +

And now he's got to go to school from, like, 7:00 a.m. to, like, 3:00 p.m. And he's been freaking out, like, "Why is school so long? Oh my goodness, I'm so tired all the time," [laughs]. So, he didn't realize that school would be as involved a process. He was all excited. But now he's complaining about, like, just the sheer length of school. But meanwhile, my wife and I we're just, like, celebrating because we actually have some time around the house where we can get work done without having kids running around causing chaos [laughs]. So yeah, I think he's adapting. He's making friends. We're doing playdates and stuff, and he's having fun. It's just a transition, you know.

+ +

But it is nice because before, I would walk my daughter to school, and that was a very quick, 10-minute round trip, and then I'd walk my son to school. And that was, like, an hour round trip because we walked all the way to the YMCA. And I would do that to kind of toughen him up and get him walking a lot. It was a huge chunk of time. And now I can just grab both, one [inaudible 4:04] hand in each hand, and walk them to school, and drop them off, and be done with it and get back to work. So, it's definitely nice having both at the same school.

+ +

VICTORIA: I love the work-life balance and that you were able to find and live somewhere that's affordable and has enough space for your family. And I wonder if we can draw a connection there between achieving that kind of lifestyle and learning to code, and what the mission of freeCodeCamp is for you, and what that means to people and changing careers.

+ +

QUINCY: Absolutely. So, my background is in teaching. And I was a teacher and a school director at schools here in the U.S. and over in China. And that involved me being on campus, like working directly with my admin staff, with my instructional staff, and working directly with students. So, working remotely was kind of, like, a foreign concept way back in, like, 2010 or so 2011 when I started my transition into working as a software developer.

+ +

But being able to work remotely has been a real game changer for me. And also, you can imagine, like, being a developer, you can command much larger compensation, and you have a lot more career options than being a teacher or a school director. So, it's given me a lot of agency in what I wanted to do. Even before, you know, starting freeCodeCamp, when I was working as a software developer and doing freelance work and stuff, I was able to do everything remotely. And that just gave me a ton of flexibility.

+ +

So, the way that I learned to code personally was I wanted to help our school be more efficient. A lot of our teachers, a lot of our admin they were spending all day kind of chained to their desk entering information into computers for compliance reasons, to be able to produce great reports, to be able to produce attendance reports, immigration documents, all those things. And I just thought, like, is there a way that maybe I could automate some of this?

+ +

And I didn't know anything about programming. I was about 31 years old. I was just sitting at my desk, and I just started kind of, like, Googling around and learning some very basic programming. And with that, over the course of a few months, I was really able to transform how the school ran. And we, like, won an award. And, like, a whole bunch of the students were, like, having a great time because they were spending so much more time with their teachers. And they were like, "Hey..." like, telling all their friends and family to transfer into the school. So, it was a massive success.

+ +

And I thought, wow, if one person who doesn't even really know that much about programming can effect such a change with just a little bit of programming skills, imagine what I could do if I actually learned to code properly, so [chuckles] I did that. I spent about nine months going to hackathons every weekend, and reading a lot of books, and using a lot of open courses online, like from MIT, from Stanford, and I kind of taught myself to code for free.

+ +

And then, I was able to get a job as a developer at a mid-size tech startup in California. And from there, I just learned more and more, and it was amazing. And it was an amazing transformation for me personally. And I thought, well, I want to help other people be able to do this because I know so many people out there would like to be working in a field where they have more conversation, a higher degree of control. They get to do creative work instead of, you know, tedious work.

+ +

As a developer, you're constantly doing new stuff because code is infinitely reproducible. So, you could always just go back to code you've previously written if you needed to solve the same problem again. So, you're always in this kind of learning mindset. You're always in this problem-solving mindset. And it's really thrilling. It's just great, impactful work. So, I wanted to help more people be able to do that, hence starting a bunch of different projects that people didn't care about and then eventually starting a project that people did care about, which is freeCodeCamp. And since then, just kind of leading this project in trying to help as many people as possible learn to code.

+ +

WILL: So, I was looking at your website. And I didn't even realize this until I was doing more research for the podcast, but you have over 10,000 tutorials, and they're in different categories. I saw you just recently released one on finance, which I actually bookmarked it because I'm going to go through it and look at it. You help more than a million people every day. So, how was it when you first started out? Like, how was, I guess, you could say, the grind? How was it in those early days?

+ +

QUINCY: I'm a big advocate of, you know, for work-life balance, but, like, I kind of, like, exclude founders from that. I really do think that if you're trying to get something started, you're going to have to work really hard and probably way beyond what would be reasonable for a person who's getting a salary or working at an existing company if you're trying to get things started. So, I mean, it was, like, 100-hour weeks, maybe 120 some weeks [laughs].

+ +

I would sleep and just wake up and get to my desk and try to, like, put out fires, fix the server, improve the codebase, respond to learners in the community who had feedback, deal with support issues. Like, I was basically doing everything myself. And gradually, we were able to, like, build out the team over a long period of time. But really, the first few years was me self-financing everything with just my teacher savings. I spent, like, $150,000 of my own money just trying to keep freeCodeCamp going.

+ +

For the first couple of years, we got tax-exempt status from the IRS. When that finally happened, I was like, great, like, let's go out and see if we can get some people to donate. So, we started asking people who were using freeCodeCamp if they'd be willing to donate $3 a month and eventually $5 a month, and we were able to support the organization through that. Really, it's just like a grassroots donor-supported effort.

+ +

And then, we've been able to get some grants from Linux Foundation, and From Google, from Microsoft, from a whole lot of other big tech companies, and from some other nonprofits in the space. But mostly, it's just been, like, individual donors donating $5. And if you get enough people doing that, you get, like, a budget where you can actually pay for, you know, we have more than 100 servers around the world serving freeCodeCamp in, like, six different languages.

+ +

We have, you know, all these other, like, initiatives. Like, we've got Code Radio, where you can go listen to Lo-fi while you're coding. And there are servers all over the world. And you can change the bit rate to suit whatever data you have and everything. Like, we wanted to just offer a whole lot of different services. We have mobile apps now. We've got an iOS and an Android app for freeCodeCamp. And then, of course, we've got the podcasts. We've got four podcasts: one in English, which I host, and then we've got one in Spanish, one in Portuguese, and one in Chinese.

+ +

VICTORIA: Yeah, I absolutely want to ask you more about your podcasts. But first, I wanted to hear–can you tell me a little more about the decision to be 501(c)(3) or a nonprofit status? And were you always firm in that decision? Do people question it? And what was the real reasoning and commitment to that formation?

+ +

QUINCY: I guess I would consider myself an idealist. Like, I genuinely believe that most educational endeavors should be, you know, nonprofit. They should be driven by either governments or by charities. I'm always kind of skeptical when there's, like, some late-night TV commercial, like, "Viewer, we'll help you get our degree," and it's from, like, a private for-profit university, something like that.

+ +

So, I was like, in education...and I don't think everything in society needs to be that way, but I do think, like, education and, to an extent, healthcare these should be led by charities. Like, you know, the Red Cross, or, like, Doctors Without Borders, or churches, you know, own many of the universities, many of the hospital systems in the United States. I think that's a good thing. I think it's a very good thing that it's not just, you know, private profit-maximizing, market incentive-bound organizations that are doing all the stuff in education and in healthcare.

+ +

I wanted to try to create something that, like, a lot of other people would see and say, "Oh wow, this charity can actually survive. It can sustain itself without raising a bunch of VC, without going public," or any of those things that a for-profit entity would do. And, again, I just want to emphasize, like, I don't think that iPhones should be made [chuckles] by nonprofits or anything like that.

+ +

I'm just saying, like, for the purpose of actually educating people, the incentives are not necessarily aligned when you're trying to get money from...especially when you're talking about people that 60% of people on earth live off less than $10 a day. Those people should be spending their money on food. They should be spending their money on shelter. They should be spending their money on family. They should not be spending money on online courses, in my humble opinion. Like, online courses should be freely available to those people.

+ +

So, to some extent, freeCodeCamp, we want to make sure that everybody everywhere in the world has access to first-rate learning resources on math, programming, computer science, regardless of their ability to pay. So, that's kind of, like, the ideal logical [inaudible 12:19], I guess, of freeCodeCamp. We kind of live that. Like, we're really serious. We will never pay, well, anything on freeCodeCamp. We won't account email gate anything. We are, I guess, absolutist in the sense that we want all of freeCodeCamp's learning resources to be free for everyone.

+ +

Because of that, it made sense to like, incorporate as a 501 (c)(3) public charity. And so, we're tax-exempt. And people who donate to freeCodeCamp they can, you know, deduct it from their U.S. taxes. If a large company or even a small startup...we've had lots of startups like New Relic, like Retool, we've had Postman, Hostinger, a whole lot of different startups and mid-sized tech companies, Pulumi, Appsmith, they've all given us these grants that we can use to develop courses. So, we can often develop courses incorporating those resources. But that's tax-exempt, right? They can deduct that from their U.S. taxes.

+ +

So, it's a big incentive for other people to partner with us and for people to donate funds to us. And it allows us to have the interests aligned in the sense that only people who have, you know, free cash flow or who have disposable income those are the people that are supporting freeCodeCamp.

+ +

For the people that are, you know, single parents or that are taking care of their aging relatives, or are already working two jobs, or are completely unemployed and don't have any funds to speak of that are using the public library computer to access freeCodeCamp, right? Or using freeCodeCamp on a $50 prepaid phone from Walmart or something like that, right? Like those people can still use freeCodeCamp, and we can have the people who do have resources subsidize everyone else.

+ +

WILL: Wow. I absolutely love that because...and I wish freeCodeCamp was around whenever I was in, like, high school and, you know, the early 2000s because we just didn't have the resources because I grew up in a small town in Louisiana. And this could have been so beneficial to that community because, like you said, we didn't have the resources–someone to teach coding there. There was no developers around that town that I was in. So, I really appreciate that you're doing this for everyone.

+ +

And I know for me even...so, when I reached out to you, I did it because I was excited because I've used freeCodeCamp so many times, so many times to learn just in my journey to become a senior developer. Like, freeCodeCamp was one of the resources that I used because, one, it was free. But it wasn't...I think sometimes you can get free resources, and it's not great quality almost. Like, it's almost like you're more confused than before. But with freeCodeCamp, it was very, very amazing quality. And it was very clear on what I was learning. Honestly, thank you for helping me grow as a developer, just, honestly, thank you for that.

+ +

QUINCY: Absolutely, Will. I feel honored to have helped you. And, yes, we want to help all the kids who are growing up in rural Louisiana or...I'm from, you know, Oklahoma City, not, like, the biggest, most prosperous city in the United States. Like, I want to help all of my friends who growing up who were eating meals provided by the state school system or my older friends who are on disability. Like, I want to make sure that they have resources, too.

+ +

And in the process of doing that, it's a privilege to also serve all the working software engineers like you out there who just need, like, a reference resource or, like, oh, I've heard about Bun JS or Tailwind CSS. Or something like, I'm going to watch this three-hour course where I'm going to learn how to do Flutter. Like, freeCodeCamp has a 37-hour Flutter course. So, we've got, like, all these courses on using OpenAI APIs and things like that, too, right?

+ +

So, it's not just for beginners, but we definitely want to, like, first and foremost, we want to serve people who we're kind of, like, the resource of last resort for, if you want to think of it that way. Like, only freeCodeCamp can help these people. Sure, they can probably use some other free courses on YouTube. And there are lots of other blogs that publish good tutorials and stuff. But freeCodeCamp is like an organized effort, specifically to help those people in need. And just kind of a side benefit of it is that you know, more established, experienced devs like you also get kind of, like, some benefit out of it as well.

+ +

WILL: Whenever you were a developer, and you decided to start freeCodeCamp, how many years of experience did you have? And how did you overcome impostor syndrome, not only as a developer but as a founder? Because I feel like just overcoming it as a developer is hard, but you were also, you know, like you said, you know, handling everything for freeCodeCamp. So, how did you do that? And kind of tell us about that experience.

+ +

QUINCY: Yeah. So, I didn't really know what I was doing. I think most founders probably don't know what they're doing. And I think that's totally fine because you can learn while you're doing. And we live in the United States, which is a country that kind of rewards experimentation and does not punish failure as much as a lot of other cultures does. Even if you try really hard, you're going to learn a tremendous amount, and you're going to try your next project. And that's what I did. I tried...I launched several educational, like, open learning resource-type projects, and none of them made any dent at all [laughs] in the proverbial universe. Like, nobody cared.

+ +

Like, I would go and, like, I'd be talking to people. And I'd be explaining, like, "Oh, this solves this problem that you have." And you could kind of tell, like, people would sign in one time just to be polite, but then they'd never sign in again. So, it was very tricky to get traction. And I read a bunch of books. And I went to a lot of founder-focused meetups in San Francisco Bay Area. I had, like, moved out to San Francisco, specifically to try to, like, kind of make up for my deficit, the fact that I didn't know anybody because I was from Oklahoma City.

+ +

I didn't know anybody in tech. And I didn't have, like, a fancy, you know, pedigree from, like, Harvard, or Wharton, or something like that, right? Like, I went to, like, a state university, and I studied English, right? And [chuckles] so, I didn't even have, like, a CS degree or anything like that. So, I definitely felt like an impostor. I just had to kind of, like, power through that and be okay with that.

+ +

And it's something a little bit easier for me to do because, you know, I'm a White guy with glasses and a beard. And, like, nobody's walking up saying, "Are you sure you're a developer?" Or like, "Are you in marketing?" You know, like, the typical kind of, like, slight that they may say to somebody who doesn't necessarily look like me. And so I didn't have to deal with any of that nonsense, but there was still a lot of just self-doubt that I had to power through. And I think that was a big advantage for me. It was just, like, I was kind of, like, at war with myself and my own confidence.

+ +

In fact, I found the software development community, and especially the open-source community, to be incredibly uplifting and empowering. And, like, they want to see you win. They want you to sit down and build a really cool project over the weekend and in the hackathon and present it. And, you know, they want you to learn. They know that you know, everybody is going to learn at a different rate and that a lot of people are going to get discouraged and leave tech and just go back to working in whatever field they were working in before. And that's totally cool.

+ +

But I do feel that they're there to support you and to encourage you. And there are lots of different events. There are lots of different communities. I recently listened to the founder of Women Who Code, who was on this very podcast [laughs], Giant Robots Smashing Into Giant Robots, the greatest podcast name of all time. And, you know, there are people out there that are working very hard to make it easier for folks to get into tech. I think that that has been a huge part.

+ +

Even before freeCodeCamp, you know, there were Harvard professors–Stanford professors putting their entire coursework for free online. You could go to, like, different tech events around California, for example, where I was when I was learning to code. And there'd just be tons of people that were eager to, like, learn more about you and to welcome you. And there would be, you know, recruiters that would talk to you and say, "Well, you may not be ready yet, but, like, let's talk in six months," right?

+ +

And so, there was kind of, like, that spirit of you're going to get there. It's just going to take a lot of time. Nobody was telling me, "Oh, learning to code is easy," [chuckles] because it's not easy. There were lots of people that were, like, "Learning to code is hard. But you've got this. Just stick with it. If I could be of help, let me know," people who would pair program with me to help me, like, improve my chops, people who would volunteer to, like, look at my projects and give design feedback, all those kinds of things.

+ +

And I think you're going to find all those things on the web. You're going to find those things in the open-source community. freeCodeCamp has a forum where people volunteer their time and energy to help build one another up and help one another get unstuck on whatever projects they're working on, give feedback on projects. And so, I think, to a large extent, the very giving nature, I almost want to say, like, selfless nature, of the global software developer community that is what saved me. And that's what enabled me to transition into this field, even as a teacher in his 30s.

+ +

VICTORIA: It's interesting you say that. Because I feel as someone who hires engineers and developers, I love people who have teaching backgrounds because it means they're five-star communicators [laughs]. And I think that you know, in your job, when you're pairing with other developers, or you're talking to clients, in our case, that communicating what you're working on and how you're thinking about something is, like, 50% of the job [laughs].

+ +

For freeCodeCamp, I saw you have 40,000 people have found jobs after completing courses on there. I hope you feel like you've really, like, established some success here already. But what's on the horizon? What are you looking forward to in the next six months or six years with freeCodeCamp?

+ +

QUINCY: Yeah, I'll be happy to answer that. But I want to emphasize what you just said: communication is, like, half the job. That's something that thoughtbot has gotten really early on. And I'll tell you that thoughtbot Playbook was incredibly helpful for me as a software developer and also early on for freeCodeCamp's team. And I think a lot of teams make use of that open resource.

+ +

So, thank you for continuing to maintain that and kind of drive home that communication really is...like, meetings are essential [chuckles]. And it's not always just, like, leave me alone and let me go back to my cubicle and code. You know, I like to quote the old joke that, you know, weeks of coding can save you hours of meetings because I really do believe that communication is core.

+ +

So, to answer your question about where freeCodeCamp is headed in terms of what kind of impact we'd like to have, I feel like we're just getting started. I feel like pretty much every Fortune 500 company wants to become a tech company in some way or another. Everybody is pushing things to the software layer because software is infinitely reproducible. It's so much easier to maintain software or fix things in production.

+ +

Like, you realize, oh, there's a big problem. Like, we don't have to recall all the cars back to the dealerships to go and open up the hood and fix this, you know, mechanical defect. If we're controlling all these things at the software layer, right? We can potentially just deploy a fix and tell people like, "Hey, version update [chuckles], you know, download this security patch," or whatever, right?

+ +

So, there are so many different things that you can do with software. I feel like the potential growth of the field of software and the number of software developers that the world will ultimately need...currently, we've got maybe 30 or 40 million developers on earth that are professional paid-to-code people. But I think that number is going to increase dramatically over the next 50 years or so.

+ +

And I'll go ahead and address the elephant in the room [laughs] because pretty much everybody asks me this question like, "Don't you think that, like, tools like large language models like GPT-4 and things are going to obviate the need for so many developers?" And I think they're going to make individual developers more productive.

+ +

But if you think about what code is, it's really extremely explicit directions for how to do something, whether you're using, you know, machine code, or you're using a scripting language like Python, or you're using English, and you're talking directly to the computer like you would on Star Trek. Essentially, you have to have a really deep understanding of the problem. And you need to know exactly what needs to be done in exactly what sequence. You may not need to manipulate bytecode like you would back in the '70s. But you are going to need to understand the fundamental problems, and you're going to need to be able to address it.

+ +

So, I'm optimistic that the number of developers is going to continue to grow. The developers are going to continue to command more and more, I guess, respect in society. And they're going to continue to have more and more agency in what they want to do with their careers and have more and more options and, ultimately, be able to command higher compensation, be able to work remotely if they'd like.

+ +

Developers will continue to be able to ascend through corporate hierarchies and become, you know, vice presidents or even executives like the CEO, right? If you look at a lot of the big tech companies, the CEO is a developer. And I think that that will continue. And the computer science degrees will continue to be extremely valuable.

+ +

So, what is freeCodeCamp working on now that we think will further help people? Well, we're working on a free four-year computer science degree, a Bachelor in computer science, and there's also an associate in mathematics that we're developing. And those are going to be a progression of 40 university-level courses that have labs and have a substantial block of lectures that you'll watch. And then, we'll also have final examinations and everything. And we're developing that curriculum. We've got one of the courses live, and we're developing the second one, and eventually, we'll have all 40. It'll take till the 2030s. But we're going to have those.

+ +

And then, once we have some longitudinal data about graduates and their success rates and everything, we are going to apply for the accreditation process, and we're going to get accredited as a university, right? Like, you can go through that process. Not a lot of organizations do that; not a lot of new universities are coming about in the 2020s. But it is something that can be done. And we've done a great deal of research, talked to a bunch of accreditors, talked to a bunch of university admins who go through the accreditation process. We think we can do it.

+ +

So, again, very long-term goal. But when you're a 501(c)(3) public charity, you don't have to worry about freeCodeCamp getting acquired or all the things that would traditionally happen with, like, a for-profit company. You have a lot more leeway to plan really far. And you've got, like, this really broad mandate in terms of what you want to accomplish. And even if, you know, creating a university degree program in the 2030s would not be a profitable endeavor that, like, a rational shareholder value-maximizing corporation would embark upon, it is the sort of project that, you know, a charity like freeCodeCamp could do. So, we're going to do it.

+ +

MID-ROLL AD:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: I think that's great. And, actually, you know, I got my master's in information technology and project management online way back when. So, I really like the availability of modern computer science bachelor's and master's being available at that low price point. And you're able to pursue that with the business structure you put in place.

+ +

I'm curious to kind of go back to something you said earlier on how widely available it is and how you spread out across all these multiple countries. Were there any technical architecture decisions that you had to make along the way? And how did those decisions end up turning out?

+ +

QUINCY: Absolutely. So, one of the things we did was we located servers all around the world. We're multi-cloud, and we've got servers in different data centers in, like, Singapore, Europe, Latin America, and we're trying to reduce latency for everybody. Another thing that we've done is, you know, we don't use, like, Google Translate to just translate all our different pages into however many languages are currently available on Google Translate; I think it's, like, more than 100. We actually have a big localization effort that's led primarily by volunteers. We have some staff that oversee some of the translation.

+ +

And essentially, we have a whole bunch of people working at translate.freecodecamp.org and translating the curriculum, translating the tutorials into major world languages. Most prominently would be Spanish, Chinese, Japanese, Korean, Portuguese, Ukrainian. Like, all these different world languages, there's, like, a freeCodeCamp version for those, and you can go into the menu, and you can choose it. And it's actually, like, hand-translated by native speakers of that language who are developers.

+ +

So, that's been another extremely, you know, time-intensive effort by the community. But we believe that, you know, the quality of the translations is really important. And we want that kind of human touch. We don't want kind of weird artifacts and typos that would be associated with machine translation. And we want to make sure that each of the challenges...because they're extremely tersely worded, again, communication is so important.

+ +

If you go through the freeCodeCamp curriculum, we try to use as few words as absolutely necessary to effectively communicate what the task the learner needs to accomplish is, and we try to, just in time, teach them concepts. We don't want to present them with a big wall of text. Read this 20-page PDF to understand how, you know, CSS, you know, borders work or something like that. No, we're teaching, like, kind of, like, just in time, like, okay, let's write this line of code. Okay, great, the test passed. Let's go to this next one. This test isn't passing. Here is some contextual-specific hints as to why your code is not passing, why you're not able to advance, right?

+ +

And we do projects [inaudible 30:30] to learn where we break everything down into steps. So, that's a lot of instructions that need to be very carefully translated into these different world languages to truly make freeCodeCamp accessible to everyone, regardless of whether they happen to be fortunate enough to grow up speaking English at a native level, right?

+ +

I would say that's our main consideration is, like, the localization effort but also just having servers everywhere and doing everything we can to comply with, like, all the different data rules and privacy rules and everything of all these different countries. It's a lot of work, but in my humble opinion, it's worth it.

+ +

WILL: I had, like, a two-part question because I wanted to loop back around. When you're talking about the free bachelor's program, one, does anything like that exist where you can get a bachelor-level program, and it's free? And then the second part is, how many countries are you in?

+ +

QUINCY: Yeah, so currently, lots of governments in Europe, for example, will offer free degrees that are kind of subsidized by the state. There may be some other kind of degree equivalent programs that are offered that are subsidized by corporations. For example, if you work at Starbucks, I think you can get a degree from Arizona State University. And that's a great benefit that Starbucks offers to people. Arizona State University, of course, being one of the biggest public universities in the United States in terms of enrollment.

+ +

As far as free degrees, though, in the United States, there's nothing like that where, like, literally anyone can just go and get a degree for free without needing to enroll, without needing to pay any sort of fees. There are tuition-free programs, but they still charge you fees for, like, taking exams and things like that.

+ +

What I like to call ultra-low-cost degree providers–there's Western Governors University, and there's University of the People. And both of these are accredited institutions that you can go, and you can get a degree for, you know, $5,000, $10,000, $15,000. And it's a full-blown four-year degree. Now, that is amazing. I applaud those efforts. I've enjoyed talking to the folks at those different schools.

+ +

I think the next step is to go truly free. There's nothing blocking you at all. You don't have to be banked. You don't have to have a credit card. You don't have to have any money. You can still get this degree. That's what we're chasing. And I think we'll get there, but it's just a lot of work.

+ +

WILL: So, it's blowing my mind. It's just blowing me away because, like, you know, we talk about the student loan crisis, I would say. The impact if...when—I'm not going to say if—when you do this, the impact that can have on there, have you thought about that? And kind of, if you have, what has been your thoughts around that?

+ +

QUINCY: Yeah, so there are $1.7 trillion in outstanding student loans in the United States. That's money that individual people, most of whom don't make a ton of money, right? Like, many of those people didn't actually finish the degree that they incurred the debt to pursue. Many of them had to drop out for a variety of different reasons or defer. Maybe they'll eventually finish those degrees. But as you can see from, like, the macroeconomic, educational, like, labor market data, like, having a partial degree doesn't make a big difference in terms of your earning power. You really need to finish the degree to be able to realize the benefits of having spent all that time studying, and a lot of people haven't.

+ +

So, yes, there are, like, a lot of people out there that went to medical school, for example, and they're working as physicians. And they are going to eventually be able to pay that off because they're doctors, and they're commanding a great compensation, right? And they've got tons of career options.

+ +

But if you studied English like I did and you incurred a whole lot of student debt, it could take a very long time for you to make enough money as a teacher, or as, like, a grant writer, or working at a newspaper, or something like that. Like, it can take you years to pay it off. And, in the meantime, it's just continuing to accumulate interest in your, you know, you might be a very diligent person who pays their student loan bill every single month, and yet, you could see that amount, the total amount that you owe continuing to grow despite this. That's just the nature of the time value of money and the nature of debt.

+ +

And I thank my lucky stars that I went to school back in, like, 2000. Like, my tuition was $1,000 a semester, right? I mean, it's incredible. But that was, like, at a state school, like, a public university in the middle of Oklahoma. And it's not, like, a university you've heard of. It's basically, like, the cheapest possible option. I think community colleges can make a huge dent. I always implore people to think more about community colleges.

+ +

I've talked with so many people on the freeCodeCamp podcast who were able to leverage community colleges and then transition into a, you know, research university, like a state school, and finish up their degree there. But they saved, like, basically half their money because they were paying almost nothing to attend the community college. And in California especially, the community colleges are just ridiculously worth it. Like, you're paying a few hundred dollars a course. I mean, it's just incredible value. So, I think the community college system is going to play a big role. But my hope is that, you know, freeCodeCamp can thrive.

+ +

And it'll take us years for people to realize because if you go on, like, Google Ads and you try to run a Google Ad for, like, any sort of educational-related topic, anything related to higher education, it's, like, hundreds of dollars per click because there are all these for-profit universities that make a tremendous amount of money from getting people who just came back from serving in the military and getting, like, huge chunks of their GI Bill, or getting, like, all these federal subsidies, any number of things. Or basically just tricking families into paying huge amounts of money when they could have attended a much more sensible public university, you know, a private nonprofit university that doesn't charge an arm and a leg.

+ +

So, I think that we are going to have an impact. I just want to say that I don't think that this is a panacea. It's going to take many years for freeCodeCamp to be adopted by a whole lot of people. It will take a long time for employers to look at the freeCodeCamp degree and say, "Oh, this is comparable to a computer science degree from..." say, Ohio State, or UT Austin, or something like that, right? Like, it's going to be a long time before we can get that level of buy-in.

+ +

I don't want anybody listening to say, "Oh, I'd love to get a computer science degree. I'm just going to hold out and get the degree from freeCodeCamp." Like, my humble advice would be: go to a community college, then go to a state school. Get that four-year computer science degree. It is worth its weight in gold. But you don't want to accumulate a lot of debt. Just try to like, minimize your debt in the meantime.

+ +

And, hopefully, over time, you know, the free model will prove out, and it'll just be a whole bunch of alumni supporting freeCodeCamp. And that's the dream is that, like, you know, Michael Bloomberg gave a billion dollars to Johns Hopkins University, a billion dollars. Like, Johns Hopkins never needs to charge tuition again with a billion dollars. They can just basically operate their institution off the interest from that, right? And lots of institutions...like, Harvard has, I don't know, like, 60-plus billion dollars in their endowment, right?

+ +

So, the idea would be freeCodeCamp continues to get this, you know, huge alumni network of people who are doing great and who went to freeCodeCamp and who basically donate back in. And then, we can essentially have the deep pockets subsidizing everybody else who's just at the beginning of their careers who don't have a lot of earning power.

+ +

You know, when I was a teenager, when I was in my 20s, I worked at convenience stores. I worked at Taco Bell. I did all kinds of, like, literally showing up at 6:00 a.m. to mop the grocery store-type jobs, right? And that is not a path to being able to afford an education in 2023. University tuition is out of control. It's, like, ridiculously high. It's grown way faster than inflation for decades. So, what can we do to alleviate that pressure? In my humble opinion, we just need to come up with free options and support ultra-low-cost options that are already out there.

+ +

VICTORIA: I was going to ask, but you might have already answered this question somewhat. But I get this question a lot for people who are interested in getting into tech, whether they should get a computer science degree or go to a bootcamp. And I think you've mentioned all the positive things about getting a degree. I'm curious if, in your degree program, you would also tailor it more to what people might expect in a modern tech market and industry in their first job.

+ +

QUINCY: Yeah. So, the way that we're developing our degree program is we essentially did, like, an analysis of the top 20 computer science programs in the United States: Carnegie Mellon, Berkeley, Stanford, MIT, all those schools that you would think of as being, like, really good computer science programs. And we basically drew a best-fit line through all their course offerings and looked at all their textbooks and everything that they cover. And, essentially, we're teaching a composite of those top 20 programs.

+ +

Now, there are some things that, surprisingly, those programs don't offer, such as a course on ethics. It's something like 13% of those degree programs require an ethics course. And I think every developer should take a developer ethics course, or at least some sort of philosophy course to, like, understand what does it mean to be a good person? [laughs] Like, what is, you know, an anti-pattern? What is Blackhat user experiences? [laughs] I'm like, when should I, like, raise my hand during a meeting to say like, "Hey, should we really be doing this?" You know.

+ +

So, ethics–security courses–I was surprised that not very many of those degree programs offer a course in information security, which I believe should be required. So, I'm kind of editorializing a little bit on top of what the composite says. But I feel very strongly that, you know, our degree program needs to have those courses. But in general, it's just everything that everybody else is teaching.

+ +

And yes, like, a coding bootcamp...I've written a lot about coding bootcamps. I wrote, like, a Coding Bootcamp Handbook, which you can just Google, like, "Coding bootcamp book" or something like that, probably then you can find it. But, essentially like, those programs are usually private. Even if it's at a big, public university, it's often run by a big, private for-profit bootcamp chain. I don't want to say, like, all bootcamps are a bad deal, but buyer beware [laughs].

+ +

Frankly, I don't think that you can learn everything you need to know to be a software engineer within the compressed timelines that a lot of those bootcamps are operating under. There's a reason it takes four years to get a computer science degree because: there's a tremendous amount of math, programming, computer science, engineering knowledge that you need to cultivate.

+ +

And you can absolutely get a developer job without a computer science degree. I don't have a computer science degree [chuckles], and I worked as a software engineer, right? And I know plenty of people who are doing that that didn't even go to college, right? People who were truckers or people who were doing construction work who just sat down and hit the books really hard and came out the other side being able to work as a software developer. But it is going to be vastly easier for you if you do have a computer science degree.

+ +

Now, if you're in your 30s, if you've got kids, if you've got a whole lot of other obligations, should you go back to school? Maybe not. And so, it's not cut and dry, like, oh, just drop whatever you're doing and go back to...The situation is going to be nuanced.

+ +

If you've already got a job working as a developer, should you go back and get a CS degree? Probably not. Maybe you can get your employer to pay for you to go to, like, a CS master's program, for example. There are a lot of really good online master's degree programs. Like, Georgia Tech has a master's in computer science that is very affordable, and it's very good. Georgia Tech is one of the best computer science programs in the United States.

+ +

So, definitely, like, everybody's situation is going to be different. And there's no blanket advice. I would just be very wary of, like, anybody who's talking to you who wants your money [laughs]. freeCodeCamp will never want your money for anything. Like, we would love to have your donation long after you're a successful developer. You turn around and, like, send the elevator back down by donating to freeCodeCamp.

+ +

But just be skeptical and, like, do your research and don't buy into, like, the marketing speak about, like, being able to get a job immediately. "Oh, it's easy. Anybody can learn to code." Like, I do believe any sufficiently motivated person can learn to code. But I also believe that it's a process that can take years, especially if you're doing the safe thing and continuing to work your day job while you learn these skills over a much longer period of time.

+ +

I don't believe learning in a compressed kind of bootcamp...like, if you think about, you know, bootcamp in the military, like, this is, like, you're getting shipped away, and you're doing nothing but, like, learning these skills and everything like that. And I don't think that that's right for programming, personally [laughs].

+ +

I think there's a reason why many of these programs have gone from 9 weeks to 12 weeks to 6 months. Some of them might be, like, an entire year now. It's because it's them kind of admitting that, like, oh, there's quite a bit to learn here, and it's going to take some time. And there's diminishing returns to learning a whole bunch of hours in a day. I think you'll make much better gains studying programming 1 hour a day for 365 days than you'll make studying, you know, 8 hours a day for, like, two months or something like that if that makes sense. I'm not sure if the math works out there.

+ +

But my point is, it's totally fine, and it's actually quite optimal to just work your day job, take care of your kids, spend time with your parents, you know, do all those things, hang out with friends and have a social life, all those things in addition to just having programming be one of those things you're working on in the background with your mornings or your evenings.

+ +

WILL: Tell us a little bit about your podcast. Yeah, tell us kind of what's the purpose of it and just the history of it.

+ +

QUINCY: Yeah. Well, I learned from the best. So, I'm a longtime listener of this podcast, of course. My friend, Saron Yitbarek, hosts CodeNewbie, which is an excellent podcast, the Changelog, which is an open-source podcast. I've had a great time interviewing the Changelog hosts and being on their show several times. So, I basically just learned as much as I could, and then I just went out and started interviewing people.

+ +

And so, I've interviewed a lot of devs. I've interviewed people that are, like, learning to code driving Uber. I've interviewed the founder of Stack Overflow [chuckles], Jeff Atwood. I'm going to interview the founder of Trello in a few weeks when I'm back out in New York City. And I do my interviews in person. I just have my mobile studio. When I'm in San Francisco–when I'm in New York, I just go around and do a bunch of interviews and kind of bank them, and then I edit them myself and publish them.

+ +

And the goal is just to give people exposure to developers. What are developers thinking? What are developers talking about? What do developers care about? And I try to hit, like, a very broad range of developers, try to talk to as many women as possible and, you know, striving for, like, 50% representation or better on the podcast. And I talk to a lot of people from different countries, although that's a little harder to do when you're recording in person. I may break down and do some over Zencastr, which is a tool we used in the past. I just like the spontaneity and the fun of meeting with people in person.

+ +

But yeah, it's just like, if you are looking for, like, long-form, some of these are, like, two-and-a-half-hour long discussions, where we really delve into people's backstory and, like, what inspired them to become a developer, what they're learning along the way, how they feel about different aspects of software development. Like, for example, earlier, Will, you mentioned impostor syndrome, which is something I think virtually everybody struggles with in some capacity, you know, the freeCodeCamp podcast, tune in [chuckles] and subscribe.

+ +

And if you have any feedback for me, I'd love to hear it. I'm still learning. I'm doing my best as a podcast host. And I'm constantly learning about tech as it evolves, as new tools come out, as new practices are pioneered. There's entire new technologies, like large language models, that actually work. And, I mean, we've had those since, like, the '60s, like, language models and stuff, but, like, only recently have they become incredibly impressive, exploring these tools and exploring a lot of the people behind them.

+ +

VICTORIA: Okay, great. Do you have any questions for me or Will?

+ +

QUINCY: Yeah. What inspired you all to get involved in tech, in...I don't know if somebody...did somebody at thoughtbot actually approach you and say, "Hey, we want you to run this"? Or was it something where like, "I'd love to run this"? Like, because podcasting is not easy. You're putting yourself out there. You're saying things that are recorded forever [laughs]. And so, if you say something really naive or silly or something like that, that's kind of always there, right? It takes a certain amount of bravery to do this. What got you into hosting this podcast?

+ +

VICTORIA: For me, I mean, if I go way back before getting into tech, my mom she got her undergraduate degree in horticulture to become a florist, and then realized she couldn't make any money off that and went back to school for computer science. And so, she taught me how to use a computer really early on. And when I was in school, I had started in architecture, and then I wanted to change into business intelligence. But I didn't want to apply to the business school, so I got a degree in economics and a job at the IT help desk.

+ +

And then from there, I was able to kind of transition into tech as a teacher, which was oddly enough...my first job in tech was training a 400-person program how to do, like, version management, and peer reviews [laughs], and timekeeping. And the reason I got the job is a friend from rock climbing introduced me, and he's like, they're like, "Oh, well, you train people how to rock climb. You can train people how to, like, do this stuff." [laughs] I'm like, oh, okay, that sounds great.

+ +

But anyways, I worked my way up into project management and ended up getting my masters in IT. And when I came to thoughtbot, I had just moved to California, and I wanted to rebuild my network. I had a big network in D.C., organizing meetups and DevOps D.C., Women Who Code, teaching people, and communicating. And I ran a very small podcast there with a friend.

+ +

So, when I joined thoughtbot, a podcast was a great way to just meet different people, expand my network, give people something to talk to me about when I go to events [laughs] that's not just, like, let me sell you some DevOps work. For me, it's been really fun to just reach out to people that we admire in the community and hear their story, and a little bit about them, and what advice they have for themselves or for other people. And, usually, that ends up benefiting me as well. So, it's been very fun for me.

+ +

QUINCY: So, your less conventional path into tech combined with your own experience doing podcasting, it sounds like you were a natural choice for hosting a podcast.

+ +

VICTORIA: Right. And I think I said before we started the show I didn't realize that it was such a well-loved and long-running podcast [laughs] [inaudible 49:01]. But I think we've really come into our own a little bit with hosting, and it's been super fun to work with Will and Chad on it as well.

+ +

QUINCY: Awesome. And, Will, what's your story, man? How did you get onto the coveted Giant Robots Smashing into Giant Robots podcast?

+ +

WILL: I actually went to college for sports medicine, and I was on track to go to med school, but my senior year...which I wish I would have had this conversation with myself a lot earlier, didn't have to do the hard work that I did at undergraduate. But my senior year, I was like, why am I really going to med school? And, honestly, it was more for the money, for the...yeah, more for the money. I just wanted to get paid a lot of money. I was like, yeah, that's not going to sustain me. I need to just pivot.

+ +

So, I pivoted–started working at some nonprofits. And I ended up losing my job and got another job at Buckle, the clothing store, which was not a great fit for me. It helped me provide, but that's just not who I am. I'm not a fashion icon [laughs]. And then I changed to a travel agency insurance company, which it paid the bills. I wasn't passionate about it at all, and it paid the bills. And I was still struggling from losing my job. It was the first time that I lost my job.

+ +

And my spouse came to me one day and is like, "All right, we're going to have the serious talk." And we almost flipped roles because that's usually who I am. I'm like, "All right, let's have a real talk. Let's get down to it." But I was just in a bad place. And she was like, "All right, we have to change because we can't keep going down this path."

+ +

So, she was like, "If you had a choice to do anything, what would you want to do?" And I was like, "Well, probably something with computers and coding because I never had that opportunity when I was growing up because of the small town." And she looked at me, and she's like, "Go sign up right now." And I was like, okay, I'm going to sign up.

+ +

When you mentioned that you made a transition in your 30s, I was around my 30s when I made the transition into coding. And so, it was a big transition. It was a big pivot for me because I'm having to learn, almost like I'm in college again, which was eight years ago. And so, it was just tough, and it wasn't new. So, that's how I got into coding.

+ +

How I got on the podcast: I think I was talking to Chad and my direct report. I was just talking to them about challenging myself, and so it was multiple things. But, like, writing blog posts that was actually very challenging to me. I still don't like to write. It's not my favorite thing. Give me math or something like that or science; that's where I feel at home. But whenever, you know, you talk about writing and stuff, I can do it, and I'm decent at it. But it's not something that I feel comfortable in. The same thing with the podcast.

+ +

The reason why I got on here is because I wanted to get out of my comfort zone and I wanted to grow. And I also wanted to get a chance to talk to people who's making a difference–who's impacting the world. So, like, this conversation today is like, yes, this is why I wanted to be a part of this podcast. So yeah, that's how I got started in tech and on the podcast.

+ +

QUINCY: Awesome, Will. I'm thrilled that you went ahead and persevered and got into tech. It doesn't sound like it was a straight line, and it rarely is for people. But I'm always excited to meet somebody who learned to code in their 30s who stuck with it and is prospering as a result. So, congratulations to you.

+ +

WILL: Thank you.

+ +

VICTORIA: I'm still learning. I haven't quite got [inaudible 52:42] "Hello, worlds," multiple times [laughs]. But I don't really code every day for my job. I just kind of need to know what stuff is to be able to talk to people and in that way as a managing director. So, I appreciate Will bringing that backstory to this episode in particular. What else? Any other final takeaway that you'd like to leave our listeners with?

+ +

QUINCY: I just want to thank you all for continuing to host this podcast, thoughtbot for operating the excellent Playbook, which, for anybody listening who is unfamiliar with, you should check it out. Again, it's just chock full of institutional wisdom accumulated over the years.

+ +

And I hope everybody out there who's thinking about taking the plunge and learning coding or software development, or even, like, a semi-technical area of being in the software development process of learning visual design, learning how to do user experience research, any number of the different roles in tech, I hope you'll go for it. And I hope you will be as undaunted as you can. And just know that freeCodeCamp and the freeCodeCamp community we are in your corner.

+ +

If you need to learn something, there's a very good chance that we have some tutorials written by thoughtful teachers who want people like you to come forward and like, read these resources and use it. There's a saying: like, the thing that programmers want the most is to have their code running in production somewhere. And, as a teacher, the thing you want the most is for you to have students, for you to have learning resources out there that are making a positive difference.

+ +

So, again, I just count my blessings every day that I'm able to be involved in this community. I hope anyone listening who wants to transition into tech or to become even more technical gets involved in the freeCodeCamp community as well. We welcome you.

+ +

WILL: Are there any opportunities? I know we talked about donations. So, for one, where can they go if they want to donate? And then also, like, you know, if developers want to get to be a part of the open-source network you have, is that possible? And how can they do that?

+ +

QUINCY: Absolutely. So, if you want to donate to freeCodeCamp, just go to donate.freecodecamp.org. And you can become, like, a $5 a month donor, if you'd like. If you want to give a larger amount, I've got this article; just Google "How to Donate to freeCodeCamp." And I've written this detailed guide to, like, all the different ways like mailing checks.

+ +

We had a gentleman who passed away and left a whole lot of money for freeCodeCamp in his will. So, those kinds of legacy gifts are definitely something. We've had people donate stock, like, any number of different things. I will bend over backwards to make sure that we can receive your donation, and we can give you a tax receipt so you can deduct it from your taxes as well if you'd like.

+ +

And then, for contributing to freeCodeCamp, of course, we're an open-source project, and we welcome your code contributions. We have spent a great deal of time trying to make freeCodeCamp as hospitable as possible for both new developers who want to get involved and more senior developers who just want to do some, like, 20%-time type contributing to open-source projects: contribute.freecodecamp.org. So, again, donate.freecodecamp.org and contribute.freecodecamp.org. Those will take you where you need to go.

+ +

VICTORIA: Wonderful. Thank you so much again, Quincy, for joining us.

+ +

And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Quincy Larson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bSIufm8D + + ]]> + + Will Larry + Victoria Guido + Quincy Larson + + + 494: Aigo.ai with Peter Voss + https://podcast.thoughtbot.com/494 + 348cbf62-bd3b-4ab1-9469-8288d081fdf1 + Thu, 28 Sep 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Peter Voss is the CEO and Chief Scientist of Aigo.ai, a groundbreaking alternative to conventional chatbots and generative models like ChatGPT. Aigo's chatbot is powered by Artificial General Intelligence (AGI), enabling it to think, learn, and reason much like a human being. It boasts short-term and long-term memory, setting it apart in terms of personalized service and context-awareness. + +Along with host Chad Pytel, Peter talks about how most chatbots and AI systems today are basic. They can answer questions but can't understand or remember the context. Aigo.ai is different because it's built to think and learn more like humans. It can adapt and get better the more you use it. He also highlights the challenges Aigo.ai faces in securing venture capital, given that its innovative approach doesn't align with current investment models heavily focused on generative or deep learning AI. Peter and Chad agree that while generative AI serves certain functions well, the quest for a system that can think, learn, and reason like a human demands a fundamentally different approach. + 33:54 + no + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP. +Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox! +Peter Voss is the CEO and Chief Scientist of Aigo.ai, a groundbreaking alternative to conventional chatbots and generative models like ChatGPT. Aigo's chatbot is powered by Artificial General Intelligence (AGI), enabling it to think, learn, and reason much like a human being. It boasts short-term and long-term memory, setting it apart in terms of personalized service and context-awareness. +Along with host Chad Pytel, Peter talks about how most chatbots and AI systems today are basic. They can answer questions but can't understand or remember the context. Aigo.ai is different because it's built to think and learn more like humans. It can adapt and get better the more you use it. He also highlights the challenges Aigo.ai faces in securing venture capital, given that its innovative approach doesn't align with current investment models heavily focused on generative or deep learning AI. Peter and Chad agree that while generative AI serves certain functions well, the quest for a system that can think, learn, and reason like a human demands a fundamentally different approach. +Aigo.ai (https://aigo.ai/) +Follow Aigo.ai on LinkedIn (https://www.linkedin.com/company/aigo-ai/) or YouTube (https://www.youtube.com/channel/UCl3XKNOL5rEit0txjVA07Ew). +Follow Peter Voss on LinkedIn (https://www.linkedin.com/in/vosspeter/). Visit his website: optimal.org/voss.html (http://optimal.org/voss.html) +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Peter Voss, CEO and Chief Scientist at Aigo.ai. Peter, thanks so much for joining me. +PETER: Yes, thank you. +CHAD: So, tell us a little bit about what Aigo.ai does. You've been working in AI for a long time. And it seems like Aigo is sort of the current culmination of a lot of your 15 years of work, so... +PETER: Yes, exactly. So, the quick way to describe our current product is a chatbot with a brain, and the important part is the brain. That basically, for the last 15-plus years, I've been working on the core technology for what's called AGI, Artificial General Intelligence, a system that can think, learn, reason similar to the way humans do. Now, we're not yet at human level with this technology. But it's a lot smarter and a lot more usable than traditional chatbots that don't have a brain. +CHAD: I want to dig into this idea a little bit. I think, like a lot of people, I've used just traditional chatbots, particularly like ChatGPT is the latest. I've built some things on top of it. What is the brain that makes it different? Especially if you've used one, what is using Aigo going to be different? +PETER: Right. I can give a concrete example of one of our customers then I can talk about the technology. So, one of our big customers is the 1-800-Flowers group of companies, which is Harry & David Popcorn Factory and several others. And wanted to provide a hyper-personalized concierge service for their customers where, you know, the system learns who you buy gifts for, for what occasions, you know, what your relationship is to them, and to basically remember who you are and what you want for each of their 20 million customers. +And they tried different technologies out there, you know, all the top brands and so on, and they just couldn't get it off the ground. And the reason is because they really don't learn. And we now have 89% self-service on the things that we've implemented, which is pretty much unheard of for complex conversations. +So, why can we do that? The reason is that our system has deep understanding. So, we have deep pausing, deep understanding, but more importantly, that the system remembers. It has short-term memory. It has long-term memory. And it uses that as context. So, you know, when you call back a second time, it'll remember what your previous call was, you know, what your preferences are, and so on. And it can basically use that information, the short and long-term memory, and reason about it. And that is really a step forward. +Now, until ChatGPT, which is really very different technology from chatbot technology, I mean, chatbot technology, you're assuming...the kind of thing we're talking about is really augmenting call center, you know, automatic call center calls. There, you need deep integration into the customers' back-end system. You obviously need to know what the latest product availability is, what the customers' outstanding orders are, you know, all sorts of things like, you know, delivery schedules. And we probably have, like, two dozen APIs that connect our system to their various corporate databases and so on. +Now, traditional chatbots obviously can do that. You hook up the APIs and do things, and it's, you know, it's a lot of work. But traditional chatbot technology really hasn't really changed much in 30 years. You basically have a categorizer; how can I help you? Basically, try to...what is the intent, intent categorizer? And then once your intent has been identified, you basically have a flowchart-type program that, you know, forces you down a flowchart. And that's what makes them so horrible because it doesn't use context. It doesn't have short-term memory. +CHAD: And I just wanted to clarify the product and where you mentioned call center. So, this isn't just...or only text-based chat. This is voice. +PETER: Yes. We started off with chat, and we now also have voice, so omnichannel. And the beauty of the system having the brain as well is you can jump from text messaging to a chat on the website to Apple ABC to voice, you know. So, you can basically move from one channel to another seamlessly. You know, so that's against traditional chatbot technology, which is really what everybody is still using. +Now, ChatGPT, of course, the fact that it's called ChatGPT sort of makes it a bit confusing. And, I mean, it's phenomenal. The technology is absolutely phenomenal in terms of what it can do, you know, write poems and give you ideas. And the amount of information it's amazing. However, it's really not suited for commercial-grade applications because it hallucinates and it doesn't have memory. +CHAD: You can give it some context, but it's basically faking it. You're providing it information every time you start to use it. +PETER: Correct. The next time you connect, that memory is gone, you know [crosstalk 05:58] +CHAD: Unless you build an application that saves it and then feeds it in again. +PETER: Right. Then you basically run out of context we know very quickly. In fact, I just published a white paper about how we can get to human-level AI. And one of the things we did and go over in the paper is we did a benchmark our technology where we fed the system about 300 or 400 facts, simple facts. You know, it might be my sister likes chocolate or, you know, it could be other things like I don't park my car in the garage or [chuckles], you know. It could be just simple facts, a few hundred of those. And then we asked questions about that. +Now, ChatGPT scored less than 1% on that because, you know, with an 8K window, it basically just couldn't remember any of this stuff. So, we use -- +CHAD: It also doesn't, in my experience...it's basically answering the way it thinks the answer should sound or look. And so, it doesn't actually understand the facts that you give it. +PETER: Exactly. +CHAD: And so, if you feed it a bunch of things which are similar, it gets really confused because it doesn't actually understand the things. It might answer correctly, but it will, in my experience, just as likely answer incorrectly. +PETER: Yeah. So, it's extremely powerful technology for helping search as well if a company has all the documents and they...but the human always has to be in the loop. It just makes way too many mistakes. But it's very useful if it gives you information 8 out of 10 times and saves you a lot of time. And it's relatively easy to detect the other two times where it gives you wrong information. Now, I know in programming, sometimes, it's given me wrong information and ended up taking longer to debug the misinformation it gave me than it would have taken me. But overall, it's still a very, very powerful tool. +But it really isn't suitable for, you know, serious chatbot applications that are integrated into back-end system because these need to be signed off by...legal department needs to be happy that it's not going to get the company into trouble. Marketing department needs to sign off on it and customer experience, you know. And a generative system like that, you really can't rely on what it's going to say, and that's apart from security concerns and, you know, the lack of memory and deep understanding. +CHAD: Yeah. So, you mentioned generative AI, which is sort of one of the underlying pieces of ChatGPT. In your solutions, are you using any generative solutions? +PETER: No, not at all. Well, I can give one example. You know, what 1-800-Flowers do is they have an option to write a poem for your mother's birthday or Mother's Day or something like it. And for that, we will use ChatGPT, or they use ChatGPT for that because that's what it's good at. But, you know, that's really just any other app that you might call up to do something for you, you know, like calling up FedEx to find out where your goods are. +Apart from that, our technology...it's a good question you ask because, you know, statistical systems and generative AI now have really dominated the AI scene for the last about 12 years, really sort of since DeepMind started. Because it's been incredibly successful to take masses amounts of data and masses amounts of computing power and, you know, number crunch them and then be able to categorize and identify images and, you know, do all sorts of magical things. +But, the approach we use is cognitive AI as opposed to generative. It's a relatively unknown approach, but that's what we've been working on for 15 years. And it starts with the question of what does intelligence require to build a system so that it doesn't use masses amounts of data? It's not the quantity of data that counts. It's the quality of data. +And it's important that it can learn incrementally as you go along like humans do and that it can validate what it learns. It can reason about, you know, new information. Does this make sense? Do I need to ask a follow-up question? You know, that kind of thing. So, it's cognitive AI. That's the approach we're using. +CHAD: And, obviously, you have a product, and you've productized it. But you said, you know, we've been working on this, or you've been working on this model for a long time. How has it progressed? +PETER: Yes, we are now on, depending on how you count, but on the third major version of it that we've started. And really, the progress has been determined by resources really than any technology. You know, it's not that we sort of have a big R&D requirement. It's really more development. But we are a relatively small company. And because we're using such different technology, it's actually been pretty hard to raise VC money. You know, they look at it and, you know, ask you, "What's your training data? How big is your model?" You know, and that kind of thing. +CHAD: Oh, so the questions investors or people know to ask aren't relevant. +PETER: Correct. And, you know, they bring in the AI experts, and then they say, "Well, what kind of deep learning, machine learning, or generative, or what transformer model are using?" And we say, "Well, we don't." And typically, that's kind of, "Oh okay, well, then it can't possibly work, you know, we don't understand it." +So, we just recently launched. You know, with all the excitement of generative AI now recently, with so much money flowing into it, we actually launched a major development effort. Now we want to hire an additional a hundred people to basically crank up the IQ. So, over the years, you know, we're working on two aspects of it: one is to continually crank up the IQ of the system, that it can understand more and more complex situations; it can reason better and be able to handle bigger amounts of data. So, that's sort of the technical part that we've been working on. +But then the other side, of course, running a business, a lot of our effort over the last 15 years has gone into making it industrial strength, you know, security, scalability, robustness of the system. Our current technology, our first version, was actually a SaaS model that we deployed behind a customer's firewall. +CHAD: Yeah, I noticed that you're targeting more enterprise deployments. +PETER: Yeah, that's at the moment because, financially, it makes more sense for us to kind of get off the ground to work with, you know, larger companies where we supply the technology, and it's deployed usually in the cloud but in their own cloud behind their firewall. So, they're very happy with that. You know, they have complete control over their data and reliability, and so on. But we provide the technology and then just licensing it. +CHAD: Now, a lot of people are familiar with generative AI, you know, it runs on GPUs and that kind of thing. Does the hardware profile for where you're hosting it look the same as that, or is it different? +PETER: No, no, no, it requires much less horsepower. So, I mean, we can run an agent on a five-year-old laptop, you know, and it doesn't...instead of it costing $100 million to train the model, it's like pennies [laughter] to train the model. I mean, we train it during our regression testing, and that we train it several times a day. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +CHAD: So, you mentioned ramping up the IQ is a goal of yours. With a cognitive model, does that mean just teaching it more things? What does it entail? +PETER: Yes, there's a little bit of tension between commercial requirements and what you ultimately want for intelligence because a truly intelligent system, you want it to be very autonomous and adaptive and have a wide range of knowledge. Now, for current commercial applications we're doing, you actually don't want the system to learn things by itself or to make up stuff, you know, you want it to be predictable. So, they develop and to ultimately get to full human-level or AGI capability requires a system to be more adaptive–be able to learn things more. +So, the one big change we are making to the system right now is natural language understanding or English understanding. And our current commercial version was actually developed through our—we call them AI psychologists, our linguists, and cognitive psychologists—by basically teaching it the rules of English grammar. And we've always known that that's suboptimal. So, with the current version, we are now actually teaching it English from the ground up the way a child might learn a language, so the language itself. So, it can learn any language. +So, for commercial applications, that wasn't really a need. But to ultimately get to human level, it needs to be more adaptive, more autonomous, and have a wider range of knowledge than the commercial version. That's basically where our focus is. And, you know, we know what needs to be done, but, you know, it's quite a bit of work. That's why we need to hire about 100 people to deal with all of the different training things. It's largely training the system, you know, but there are also some architectural improvements we need to make on performance and the way the system reasons. +CHAD: Well, you used the term Artificial General Intelligence. I understand you're one of the people who coined that term [chuckles] or the person. +PETER: Yes. In 2002, I got together with two other people who felt that the time was ripe to get back to the original dream of AI, you know, from 60 years ago, to build thinking machines basically. So, we decided to write a book on the topic to put our ideas out there. And we were looking for a title for the book, and three of us—myself, Ben Goertzel, and Shane Legg, who's actually one of the founders of DeepMind; he was working for me at the time. And we were brainstorming it, and that's what we came up with was AGI, Artificial General Intelligence. +CHAD: So, for people who aren't familiar, it's what you were sort of alluding to. You're basically trying to replicate the human brain, the way humans learn, right? That's the basic idea is -- +PETER: Yeah, the human cognition really, yeah, human mind, human cognition. That's exactly right. I mean, we want an AI that can think, learn, and reason the way humans do, you know, that it can hit the box and learn a new topic, you know, you can have any kind of conversation. And we really believe we have the technology to do that. +We've built quite a number of different prototypes that already show this kind of capability where it can, you know, read Wikipedia, integrate that with existing knowledge, and then have a conversation about it. And if it's not sure about something, it'll ask for clarification and things like that. We really just need to scale it up. And, of course, it's a huge deal for us to eventually get to human-level AI. +CHAD: Yeah. How much sort of studying of the brain or cognition do you do in your work, where, you know, sort of going back and saying, "Okay, we want to tackle this thing"? Do you do research into cognition? +PETER: Yeah, that's a very interesting question. It really gets to the heart of why I think we haven't made more progress in developing AGI. In fact, another white paper I published recently is "Why Don't We Have AGI Yet?" And, you know, one of the big problems is that statistical AI has been so incredibly successful over the last decade or so that it sucked all of the oxygen out of the air. +But to your question, before I started on this project, I actually took off five years to study intelligence because, to me, that's really what cognitive AI approach is all about is you start off by saying, what is intelligence? What does it require? And I studied it from the perspective of philosophy, epistemology, theory of knowledge. You know, what's reality? How do we know anything? +CHAD: [laughs] +PETER: How can we be sure? You know, really those most fundamental questions. Then how do children learn? What do IQ tests measure? How does our intelligence differ to animal intelligence? What is that magic difference between, you know, evolution? Suddenly, we have this high-level cognition. And the short answer of that is being able to form abstract concepts or concept formation is sort of key, and to have metacognition, to be able to think about your own thinking. +So, those are kind of the things I discovered during the five years of study. Obviously, I also looked at what had already been done in the field of AI, as in good old-fashioned AI, and neural networks, and so on. So, this is what brought me together. So, absolutely, as a starting point to say, what is intelligence? Or what are the aspects of intelligence that are really important and core? +Now, as far as studying the brain is concerned, I certainly looked at that, but I pretty quickly decided that that wasn't that relevant. It's, you know, you certainly get some ideas. I mean, neural networks, ours is kind of a neural network or knowledge graph, so there's some similarity with that. But the analogy one often gives, which I think is not bad, is, you know, we've had flying machines for 100 years. We are still nowhere near reverse engineering a bird. +CHAD: Right. +PETER: So, you know, evolution and biology are just very different from designing things and using the materials that we need to use in computers. So, definitely, understanding intelligence, I think, is key to being able to build it. +CHAD: Well, in some ways, that is part of the reason why statistical AI has gotten so much attention with that sort of airplane analogy because it's like, maybe we need to not try to replicate human cognition [chuckles]. Maybe we need to just embrace what computers are good at and try to find a different way. +PETER: Right, right. But that argument really falls down when you say you are ignoring intelligence, you know, or you're ignoring the kind of intelligence. And we can see how ridiculous the sort of the current...well, I mean, first of all, let me say Sam Altman, and everybody says...well, they say two things: one, we have no idea how these things work, which is not a good thing if you're [chuckles] trying to build something and improve it. And the second thing they say...Demis Hassabis and, you know, everybody says it, "This is not going to get us to human-level AI, to human-level intelligence." +They realize that this is the wrong approach. But they also haven't come up with what the right approach is because they are stuck within the statistical big data approach, you know, we need another 100 billion dollars to build even bigger computers with bigger models, you know, but that's really -- +CHAD: Right. It might be creating a tool, which has some uses, but it is not actual; I mean, it's not really even actual artificial intelligence -- +PETER: Correct. And, I mean, you can sort of see this very easily if...imagine you hired a personal assistant for yourself, a human. And, you know, they come to you, and they know how to use Excel and do QuickBooks or whatever, and a lot of things, so great. They start working with you. +But, you know, every now and again, they say something that's completely wrong with full confidence, so that's a problem. Then the second thing is you tell them, "Well, we've just introduced a new product. We shut down this branch here. And, you know, I've got a new partner in the business and a new board member." And the next day, they come in, and they remember nothing of that, you know, [chuckles] that's not very intelligent. +CHAD: Right. No, no, it's not. It's possible that there's a way for these two things to use each other, like generating intelligent-sounding, understanding what someone is saying and finding like things to it, and being able to generate meaningful, intelligent language might be useful in a cognitive model. +PETER: We obviously thought long and hard about this, especially when, you know, generative AI became so powerful. I mean, it does some amazing things. So, can we combine the technology? And the answer is quite simply no. As I mentioned earlier, we can use generative AI kind of as an API or as a tool or something. You know, so if our system needs to write a poem or something, then yes, you know, these systems can do a good job of it. +But the reason you can't really just combine them and kind of build a Frankensteinian kind of [laughs] thing is you really need to have context that you currently have fully integrated. So you can't have two brains, you know, the one brain, which is a read-only brain, and then our brain, our cognitive brain, which basically constantly adapts and uses the context of what it's heard using short-term memory, long-term memory, reasoning, and so on. +So, all of those mental mechanisms of deep understanding of context, short-term and long-term memory, reasoning, language generation–they all have to be tightly integrated and work together. And that's basically the approach that we have. Now, like a human to...if you write, you know, "Generate an essay," and you want to have it come up with maybe some ideas, changing the style, for example, you know, it would make sense for our system to use a generative AI system like a tool because humans are good tool users. You know, I wouldn't expect our system to be the world chess champion or Go champion. It can use a chess-playing AI or a Go-playing AI to do that job. +CHAD: That's really cool. You mentioned the short-term, long-term memory. If I am using or working on a deployment for Aigo, is that something that I specify, like, oh, this thing where we've collected goes in short term versus long term, or does the system actually do that automatically? +PETER: That's the beauty of the system that: it automatically has short and long-term memory. So, really, the only thing that needs to be sort of externally specified is things you don't want to keep in long-term memory, you know, that for some reason, security reasons, or a company gives you a password or whatever. So, then, they need to be tagged. +So, we have, like, an ontology that describes all of the different kinds of knowledge that you have. And in the ontology, you can tag certain branches of the ontology or certain nodes in the ontology to say, this should not be remembered, or this should be encrypted or, you know, whatever. But by default, everything that comes into short-term memory is remembered. So, you know, a computer can have photographic memory. +CHAD: You know, that is part of why...someone critical of what they've heard might say, "Well, you're just replicating a human brain. How is this going to be better?" And I think that that's where you're just...what you said, like, when we do artificial general intelligence with computers, they all have photographic memory. +PETER: Right. Well, in my presentations, when I give talks on this, I have the one slide that actually talks about how AI is superior to humans in as far as getting work done in cognition, and there's actually quite a number of things. So, let me first kind of give one example here. So, imagine you train up one AI to be a PhD-level cancer researcher, you know, it goes through whatever training, and reading, and coaching, and so on. +So, you now have this PhD-level cancer researcher. You now make a million copies of that, and you have a million PhD-level cancer researchers chipping away at the problem. Now, I'm sure we would make a lot more progress, and you can now replicate that idea, that same thinking, you know, in energy, pollution, poverty, whatever, I mean, any disease, that kind of approach. So, I mean, that already is one major difference that you make copies of an AI, which you can't of humans. +But there are other things. First of all, they are significantly less expensive than humans. Humans are very expensive. So much lower cost. They work 24/7 without breaks, without getting tired. I don't know the best human on how many hours they can concentrate without needing a break, maybe a few hours a day, or six, maybe four hours a day. So, 24/7. +Then, they can communicate with each other much better than humans do because they could share information sort of by transferring blocks of data across from one to the other without the ego getting in the way. I mean, you take humans, not very good at sharing information and discoveries. Then they don't have certain distractions that we have like romantic things and kids in schools and, you know. +CHAD: Although if you actually do get a full [laughs] AGI, then it might start to have those things [laughs]. +PETER: Well, yeah, that's a whole nother topic. But our AIs, we basically build them not to want to have children [laughs] so, you know. And then, of course, things we spoke about, photographic memory. It has instantaneous access to all the information in the world, all the databases, you know, much better than we have, like, if we had a direct connection to the internet and brain, you know, but at a much higher bandwidth than we could ever achieve with our wetware. +And then, lastly, they are much better at reasoning than humans are. I mean, our ability to reason is what I call an evolutionary afterthought. We are not actually that good at logical thinking, and AIs can be, you know. +CHAD: We like to think we are, though. +PETER: [chuckles] Well, you know, compared to animals, yes, definitely. We are significantly better. But realistically, humans are not that good at rational, logical thinking. +CHAD: You know, I read something that a lot of decisions are made at a different level than the logical part. And then, the logical part justifies the decision. +PETER: Yeah, absolutely. And, in fact, this is why smart people are actually worse at that because they're really good at rationalizations. You know, they can rationalize their weird beliefs and/or their weird behavior or something. That's true. +CHAD: You mentioned that your primary customers are enterprises. Who makes up your ideal customer? And if someone was listening who matched that profile and wanted to get in touch with you, what would they look like? +PETER: The simplest and most obvious way is if they have call centers of 100 people or more—hundreds, or thousands, tens of thousands even. But the economics from about 100 people in the call center, where we might be able to save them 50% of that, you know, depending on the kind of business. +CHAD: And are your solutions typically employed before the actual people, and then they fall back to people in certain circumstances? +PETER: Correct. That's exactly right. And, you know, the advantage there is, whatever Aigo already gathers, we then summarize it and pop that to the human operator so that, you know, that the customer -- +CHAD: That's great because that's super annoying. +PETER: It is. +CHAD: [laughs] +PETER: It is super annoying and -- +CHAD: When you finally get to a person, and it's like, I just spent five minutes providing all this information that you apparently don't have. +PETER: Right. Yeah, no, absolutely, that's kind of one of the key things that the AI has that information. It can summarize it and provide it to the live operator. So that would be, you know, the sort of the most obvious use case. +But we also have use cases on the go with student assistant, for example, where it's sort of more on an individual basis. You know, imagine your kid just starts at university. It's just overwhelming. It can have a personal personal assistant, you know, that knows all about you in particular. But then also knows about the university, knows its way around, where you get your books, your meals, and, you know, different societies and curriculum and so on. Or diabetes coach, you know, where it can help people with diabetes manage their meals and activities, where it can learn whether you love broccoli, or you're vegetarian, or whatever, and help guide you through that. Internal help desks are another application, of course. +CHAD: Yeah. I was going to say even the same thing as at a university when people join a big company, you know, there's an onboarding process. +PETER: Exactly. Yeah. +CHAD: And there could be things that you're not aware of or don't know where to find. +PETER: Internal HR and IT, absolutely, as you say, on onboarding. Those are other applications where our technology is well-suited. +And one other category is what we call a co-pilot. So, think of it as Clippy on steroids, you know, where basically you have complex software like, you know, SAP, or Salesforce, or something like that. And you can basically just have Aigo as a front end to it, and you can just talk to it. And it will know where to navigate, what to get, and basically do things, complex things in the software. +And software vendors like that idea because people utilize more features of the software than they would otherwise, you know. It can accelerate your learning curve and make it much easier to use the product. So, you know, really, the technology that we have is industry and application-agnostic to a large extent. We're just currently not yet at human level. +CHAD: Right. I hope you get there eventually. It'll be certainly exciting when you do. +PETER: Yes. Well, we do expect to get there. We just, you know, as I said, we've just launched a project now to raise the additional money we need to hire the people that we need. And we actually believe we are only a few years away from full human-level intelligence or AGI. +CHAD: Wow, that's exciting. So, if the solution that you currently have and people want to go along for the journey with you, how can they get in touch with Aigo? +PETER: They could contact me directly: peter@aigo.ai. I'm also active on Twitter, LinkedIn. +CHAD: Cool. We'll include all of those links in the show notes, which people can find at giantrobots.fm. +If you have questions for me, email me at hosts@giantrobots.fm. Find me on Mastodon @cpytel@thoughtbot.social. +You can find a complete transcript for this episode as well at giantrobots.fm. +Peter, thank you so much for joining me. I really appreciate it and all of the wisdom that you've shared with us today. +PETER: Well, thank you. They were good questions. Thank you. +CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Peter Voss. + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP.

+ +

Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox!

+ +
+ +

Peter Voss is the CEO and Chief Scientist of Aigo.ai, a groundbreaking alternative to conventional chatbots and generative models like ChatGPT. Aigo's chatbot is powered by Artificial General Intelligence (AGI), enabling it to think, learn, and reason much like a human being. It boasts short-term and long-term memory, setting it apart in terms of personalized service and context-awareness.

+ +

Along with host Chad Pytel, Peter talks about how most chatbots and AI systems today are basic. They can answer questions but can't understand or remember the context. Aigo.ai is different because it's built to think and learn more like humans. It can adapt and get better the more you use it. He also highlights the challenges Aigo.ai faces in securing venture capital, given that its innovative approach doesn't align with current investment models heavily focused on generative or deep learning AI. Peter and Chad agree that while generative AI serves certain functions well, the quest for a system that can think, learn, and reason like a human demands a fundamentally different approach.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Peter Voss, CEO and Chief Scientist at Aigo.ai. Peter, thanks so much for joining me.

+ +

PETER: Yes, thank you.

+ +

CHAD: So, tell us a little bit about what Aigo.ai does. You've been working in AI for a long time. And it seems like Aigo is sort of the current culmination of a lot of your 15 years of work, so...

+ +

PETER: Yes, exactly. So, the quick way to describe our current product is a chatbot with a brain, and the important part is the brain. That basically, for the last 15-plus years, I've been working on the core technology for what's called AGI, Artificial General Intelligence, a system that can think, learn, reason similar to the way humans do. Now, we're not yet at human level with this technology. But it's a lot smarter and a lot more usable than traditional chatbots that don't have a brain.

+ +

CHAD: I want to dig into this idea a little bit. I think, like a lot of people, I've used just traditional chatbots, particularly like ChatGPT is the latest. I've built some things on top of it. What is the brain that makes it different? Especially if you've used one, what is using Aigo going to be different?

+ +

PETER: Right. I can give a concrete example of one of our customers then I can talk about the technology. So, one of our big customers is the 1-800-Flowers group of companies, which is Harry & David Popcorn Factory and several others. And wanted to provide a hyper-personalized concierge service for their customers where, you know, the system learns who you buy gifts for, for what occasions, you know, what your relationship is to them, and to basically remember who you are and what you want for each of their 20 million customers.

+ +

And they tried different technologies out there, you know, all the top brands and so on, and they just couldn't get it off the ground. And the reason is because they really don't learn. And we now have 89% self-service on the things that we've implemented, which is pretty much unheard of for complex conversations.

+ +

So, why can we do that? The reason is that our system has deep understanding. So, we have deep pausing, deep understanding, but more importantly, that the system remembers. It has short-term memory. It has long-term memory. And it uses that as context. So, you know, when you call back a second time, it'll remember what your previous call was, you know, what your preferences are, and so on. And it can basically use that information, the short and long-term memory, and reason about it. And that is really a step forward.

+ +

Now, until ChatGPT, which is really very different technology from chatbot technology, I mean, chatbot technology, you're assuming...the kind of thing we're talking about is really augmenting call center, you know, automatic call center calls. There, you need deep integration into the customers' back-end system. You obviously need to know what the latest product availability is, what the customers' outstanding orders are, you know, all sorts of things like, you know, delivery schedules. And we probably have, like, two dozen APIs that connect our system to their various corporate databases and so on.

+ +

Now, traditional chatbots obviously can do that. You hook up the APIs and do things, and it's, you know, it's a lot of work. But traditional chatbot technology really hasn't really changed much in 30 years. You basically have a categorizer; how can I help you? Basically, try to...what is the intent, intent categorizer? And then once your intent has been identified, you basically have a flowchart-type program that, you know, forces you down a flowchart. And that's what makes them so horrible because it doesn't use context. It doesn't have short-term memory.

+ +

CHAD: And I just wanted to clarify the product and where you mentioned call center. So, this isn't just...or only text-based chat. This is voice.

+ +

PETER: Yes. We started off with chat, and we now also have voice, so omnichannel. And the beauty of the system having the brain as well is you can jump from text messaging to a chat on the website to Apple ABC to voice, you know. So, you can basically move from one channel to another seamlessly. You know, so that's against traditional chatbot technology, which is really what everybody is still using.

+ +

Now, ChatGPT, of course, the fact that it's called ChatGPT sort of makes it a bit confusing. And, I mean, it's phenomenal. The technology is absolutely phenomenal in terms of what it can do, you know, write poems and give you ideas. And the amount of information it's amazing. However, it's really not suited for commercial-grade applications because it hallucinates and it doesn't have memory.

+ +

CHAD: You can give it some context, but it's basically faking it. You're providing it information every time you start to use it.

+ +

PETER: Correct. The next time you connect, that memory is gone, you know [crosstalk 05:58]

+ +

CHAD: Unless you build an application that saves it and then feeds it in again.

+ +

PETER: Right. Then you basically run out of context we know very quickly. In fact, I just published a white paper about how we can get to human-level AI. And one of the things we did and go over in the paper is we did a benchmark our technology where we fed the system about 300 or 400 facts, simple facts. You know, it might be my sister likes chocolate or, you know, it could be other things like I don't park my car in the garage or [chuckles], you know. It could be just simple facts, a few hundred of those. And then we asked questions about that.

+ +

Now, ChatGPT scored less than 1% on that because, you know, with an 8K window, it basically just couldn't remember any of this stuff. So, we use --

+ +

CHAD: It also doesn't, in my experience...it's basically answering the way it thinks the answer should sound or look. And so, it doesn't actually understand the facts that you give it.

+ +

PETER: Exactly.

+ +

CHAD: And so, if you feed it a bunch of things which are similar, it gets really confused because it doesn't actually understand the things. It might answer correctly, but it will, in my experience, just as likely answer incorrectly.

+ +

PETER: Yeah. So, it's extremely powerful technology for helping search as well if a company has all the documents and they...but the human always has to be in the loop. It just makes way too many mistakes. But it's very useful if it gives you information 8 out of 10 times and saves you a lot of time. And it's relatively easy to detect the other two times where it gives you wrong information. Now, I know in programming, sometimes, it's given me wrong information and ended up taking longer to debug the misinformation it gave me than it would have taken me. But overall, it's still a very, very powerful tool.

+ +

But it really isn't suitable for, you know, serious chatbot applications that are integrated into back-end system because these need to be signed off by...legal department needs to be happy that it's not going to get the company into trouble. Marketing department needs to sign off on it and customer experience, you know. And a generative system like that, you really can't rely on what it's going to say, and that's apart from security concerns and, you know, the lack of memory and deep understanding.

+ +

CHAD: Yeah. So, you mentioned generative AI, which is sort of one of the underlying pieces of ChatGPT. In your solutions, are you using any generative solutions?

+ +

PETER: No, not at all. Well, I can give one example. You know, what 1-800-Flowers do is they have an option to write a poem for your mother's birthday or Mother's Day or something like it. And for that, we will use ChatGPT, or they use ChatGPT for that because that's what it's good at. But, you know, that's really just any other app that you might call up to do something for you, you know, like calling up FedEx to find out where your goods are.

+ +

Apart from that, our technology...it's a good question you ask because, you know, statistical systems and generative AI now have really dominated the AI scene for the last about 12 years, really sort of since DeepMind started. Because it's been incredibly successful to take masses amounts of data and masses amounts of computing power and, you know, number crunch them and then be able to categorize and identify images and, you know, do all sorts of magical things.

+ +

But, the approach we use is cognitive AI as opposed to generative. It's a relatively unknown approach, but that's what we've been working on for 15 years. And it starts with the question of what does intelligence require to build a system so that it doesn't use masses amounts of data? It's not the quantity of data that counts. It's the quality of data.

+ +

And it's important that it can learn incrementally as you go along like humans do and that it can validate what it learns. It can reason about, you know, new information. Does this make sense? Do I need to ask a follow-up question? You know, that kind of thing. So, it's cognitive AI. That's the approach we're using.

+ +

CHAD: And, obviously, you have a product, and you've productized it. But you said, you know, we've been working on this, or you've been working on this model for a long time. How has it progressed?

+ +

PETER: Yes, we are now on, depending on how you count, but on the third major version of it that we've started. And really, the progress has been determined by resources really than any technology. You know, it's not that we sort of have a big R&D requirement. It's really more development. But we are a relatively small company. And because we're using such different technology, it's actually been pretty hard to raise VC money. You know, they look at it and, you know, ask you, "What's your training data? How big is your model?" You know, and that kind of thing.

+ +

CHAD: Oh, so the questions investors or people know to ask aren't relevant.

+ +

PETER: Correct. And, you know, they bring in the AI experts, and then they say, "Well, what kind of deep learning, machine learning, or generative, or what transformer model are using?" And we say, "Well, we don't." And typically, that's kind of, "Oh okay, well, then it can't possibly work, you know, we don't understand it."

+ +

So, we just recently launched. You know, with all the excitement of generative AI now recently, with so much money flowing into it, we actually launched a major development effort. Now we want to hire an additional a hundred people to basically crank up the IQ. So, over the years, you know, we're working on two aspects of it: one is to continually crank up the IQ of the system, that it can understand more and more complex situations; it can reason better and be able to handle bigger amounts of data. So, that's sort of the technical part that we've been working on.

+ +

But then the other side, of course, running a business, a lot of our effort over the last 15 years has gone into making it industrial strength, you know, security, scalability, robustness of the system. Our current technology, our first version, was actually a SaaS model that we deployed behind a customer's firewall.

+ +

CHAD: Yeah, I noticed that you're targeting more enterprise deployments.

+ +

PETER: Yeah, that's at the moment because, financially, it makes more sense for us to kind of get off the ground to work with, you know, larger companies where we supply the technology, and it's deployed usually in the cloud but in their own cloud behind their firewall. So, they're very happy with that. You know, they have complete control over their data and reliability, and so on. But we provide the technology and then just licensing it.

+ +

CHAD: Now, a lot of people are familiar with generative AI, you know, it runs on GPUs and that kind of thing. Does the hardware profile for where you're hosting it look the same as that, or is it different?

+ +

PETER: No, no, no, it requires much less horsepower. So, I mean, we can run an agent on a five-year-old laptop, you know, and it doesn't...instead of it costing $100 million to train the model, it's like pennies [laughter] to train the model. I mean, we train it during our regression testing, and that we train it several times a day.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: So, you mentioned ramping up the IQ is a goal of yours. With a cognitive model, does that mean just teaching it more things? What does it entail?

+ +

PETER: Yes, there's a little bit of tension between commercial requirements and what you ultimately want for intelligence because a truly intelligent system, you want it to be very autonomous and adaptive and have a wide range of knowledge. Now, for current commercial applications we're doing, you actually don't want the system to learn things by itself or to make up stuff, you know, you want it to be predictable. So, they develop and to ultimately get to full human-level or AGI capability requires a system to be more adaptive–be able to learn things more.

+ +

So, the one big change we are making to the system right now is natural language understanding or English understanding. And our current commercial version was actually developed through our—we call them AI psychologists, our linguists, and cognitive psychologists—by basically teaching it the rules of English grammar. And we've always known that that's suboptimal. So, with the current version, we are now actually teaching it English from the ground up the way a child might learn a language, so the language itself. So, it can learn any language.

+ +

So, for commercial applications, that wasn't really a need. But to ultimately get to human level, it needs to be more adaptive, more autonomous, and have a wider range of knowledge than the commercial version. That's basically where our focus is. And, you know, we know what needs to be done, but, you know, it's quite a bit of work. That's why we need to hire about 100 people to deal with all of the different training things. It's largely training the system, you know, but there are also some architectural improvements we need to make on performance and the way the system reasons.

+ +

CHAD: Well, you used the term Artificial General Intelligence. I understand you're one of the people who coined that term [chuckles] or the person.

+ +

PETER: Yes. In 2002, I got together with two other people who felt that the time was ripe to get back to the original dream of AI, you know, from 60 years ago, to build thinking machines basically. So, we decided to write a book on the topic to put our ideas out there. And we were looking for a title for the book, and three of us—myself, Ben Goertzel, and Shane Legg, who's actually one of the founders of DeepMind; he was working for me at the time. And we were brainstorming it, and that's what we came up with was AGI, Artificial General Intelligence.

+ +

CHAD: So, for people who aren't familiar, it's what you were sort of alluding to. You're basically trying to replicate the human brain, the way humans learn, right? That's the basic idea is --

+ +

PETER: Yeah, the human cognition really, yeah, human mind, human cognition. That's exactly right. I mean, we want an AI that can think, learn, and reason the way humans do, you know, that it can hit the box and learn a new topic, you know, you can have any kind of conversation. And we really believe we have the technology to do that.

+ +

We've built quite a number of different prototypes that already show this kind of capability where it can, you know, read Wikipedia, integrate that with existing knowledge, and then have a conversation about it. And if it's not sure about something, it'll ask for clarification and things like that. We really just need to scale it up. And, of course, it's a huge deal for us to eventually get to human-level AI.

+ +

CHAD: Yeah. How much sort of studying of the brain or cognition do you do in your work, where, you know, sort of going back and saying, "Okay, we want to tackle this thing"? Do you do research into cognition?

+ +

PETER: Yeah, that's a very interesting question. It really gets to the heart of why I think we haven't made more progress in developing AGI. In fact, another white paper I published recently is "Why Don't We Have AGI Yet?" And, you know, one of the big problems is that statistical AI has been so incredibly successful over the last decade or so that it sucked all of the oxygen out of the air.

+ +

But to your question, before I started on this project, I actually took off five years to study intelligence because, to me, that's really what cognitive AI approach is all about is you start off by saying, what is intelligence? What does it require? And I studied it from the perspective of philosophy, epistemology, theory of knowledge. You know, what's reality? How do we know anything?

+ +

CHAD: [laughs]

+ +

PETER: How can we be sure? You know, really those most fundamental questions. Then how do children learn? What do IQ tests measure? How does our intelligence differ to animal intelligence? What is that magic difference between, you know, evolution? Suddenly, we have this high-level cognition. And the short answer of that is being able to form abstract concepts or concept formation is sort of key, and to have metacognition, to be able to think about your own thinking.

+ +

So, those are kind of the things I discovered during the five years of study. Obviously, I also looked at what had already been done in the field of AI, as in good old-fashioned AI, and neural networks, and so on. So, this is what brought me together. So, absolutely, as a starting point to say, what is intelligence? Or what are the aspects of intelligence that are really important and core?

+ +

Now, as far as studying the brain is concerned, I certainly looked at that, but I pretty quickly decided that that wasn't that relevant. It's, you know, you certainly get some ideas. I mean, neural networks, ours is kind of a neural network or knowledge graph, so there's some similarity with that. But the analogy one often gives, which I think is not bad, is, you know, we've had flying machines for 100 years. We are still nowhere near reverse engineering a bird.

+ +

CHAD: Right.

+ +

PETER: So, you know, evolution and biology are just very different from designing things and using the materials that we need to use in computers. So, definitely, understanding intelligence, I think, is key to being able to build it.

+ +

CHAD: Well, in some ways, that is part of the reason why statistical AI has gotten so much attention with that sort of airplane analogy because it's like, maybe we need to not try to replicate human cognition [chuckles]. Maybe we need to just embrace what computers are good at and try to find a different way.

+ +

PETER: Right, right. But that argument really falls down when you say you are ignoring intelligence, you know, or you're ignoring the kind of intelligence. And we can see how ridiculous the sort of the current...well, I mean, first of all, let me say Sam Altman, and everybody says...well, they say two things: one, we have no idea how these things work, which is not a good thing if you're [chuckles] trying to build something and improve it. And the second thing they say...Demis Hassabis and, you know, everybody says it, "This is not going to get us to human-level AI, to human-level intelligence."

+ +

They realize that this is the wrong approach. But they also haven't come up with what the right approach is because they are stuck within the statistical big data approach, you know, we need another 100 billion dollars to build even bigger computers with bigger models, you know, but that's really --

+ +

CHAD: Right. It might be creating a tool, which has some uses, but it is not actual; I mean, it's not really even actual artificial intelligence --

+ +

PETER: Correct. And, I mean, you can sort of see this very easily if...imagine you hired a personal assistant for yourself, a human. And, you know, they come to you, and they know how to use Excel and do QuickBooks or whatever, and a lot of things, so great. They start working with you.

+ +

But, you know, every now and again, they say something that's completely wrong with full confidence, so that's a problem. Then the second thing is you tell them, "Well, we've just introduced a new product. We shut down this branch here. And, you know, I've got a new partner in the business and a new board member." And the next day, they come in, and they remember nothing of that, you know, [chuckles] that's not very intelligent.

+ +

CHAD: Right. No, no, it's not. It's possible that there's a way for these two things to use each other, like generating intelligent-sounding, understanding what someone is saying and finding like things to it, and being able to generate meaningful, intelligent language might be useful in a cognitive model.

+ +

PETER: We obviously thought long and hard about this, especially when, you know, generative AI became so powerful. I mean, it does some amazing things. So, can we combine the technology? And the answer is quite simply no. As I mentioned earlier, we can use generative AI kind of as an API or as a tool or something. You know, so if our system needs to write a poem or something, then yes, you know, these systems can do a good job of it.

+ +

But the reason you can't really just combine them and kind of build a Frankensteinian kind of [laughs] thing is you really need to have context that you currently have fully integrated. So you can't have two brains, you know, the one brain, which is a read-only brain, and then our brain, our cognitive brain, which basically constantly adapts and uses the context of what it's heard using short-term memory, long-term memory, reasoning, and so on.

+ +

So, all of those mental mechanisms of deep understanding of context, short-term and long-term memory, reasoning, language generation–they all have to be tightly integrated and work together. And that's basically the approach that we have. Now, like a human to...if you write, you know, "Generate an essay," and you want to have it come up with maybe some ideas, changing the style, for example, you know, it would make sense for our system to use a generative AI system like a tool because humans are good tool users. You know, I wouldn't expect our system to be the world chess champion or Go champion. It can use a chess-playing AI or a Go-playing AI to do that job.

+ +

CHAD: That's really cool. You mentioned the short-term, long-term memory. If I am using or working on a deployment for Aigo, is that something that I specify, like, oh, this thing where we've collected goes in short term versus long term, or does the system actually do that automatically?

+ +

PETER: That's the beauty of the system that: it automatically has short and long-term memory. So, really, the only thing that needs to be sort of externally specified is things you don't want to keep in long-term memory, you know, that for some reason, security reasons, or a company gives you a password or whatever. So, then, they need to be tagged.

+ +

So, we have, like, an ontology that describes all of the different kinds of knowledge that you have. And in the ontology, you can tag certain branches of the ontology or certain nodes in the ontology to say, this should not be remembered, or this should be encrypted or, you know, whatever. But by default, everything that comes into short-term memory is remembered. So, you know, a computer can have photographic memory.

+ +

CHAD: You know, that is part of why...someone critical of what they've heard might say, "Well, you're just replicating a human brain. How is this going to be better?" And I think that that's where you're just...what you said, like, when we do artificial general intelligence with computers, they all have photographic memory.

+ +

PETER: Right. Well, in my presentations, when I give talks on this, I have the one slide that actually talks about how AI is superior to humans in as far as getting work done in cognition, and there's actually quite a number of things. So, let me first kind of give one example here. So, imagine you train up one AI to be a PhD-level cancer researcher, you know, it goes through whatever training, and reading, and coaching, and so on.

+ +

So, you now have this PhD-level cancer researcher. You now make a million copies of that, and you have a million PhD-level cancer researchers chipping away at the problem. Now, I'm sure we would make a lot more progress, and you can now replicate that idea, that same thinking, you know, in energy, pollution, poverty, whatever, I mean, any disease, that kind of approach. So, I mean, that already is one major difference that you make copies of an AI, which you can't of humans.

+ +

But there are other things. First of all, they are significantly less expensive than humans. Humans are very expensive. So much lower cost. They work 24/7 without breaks, without getting tired. I don't know the best human on how many hours they can concentrate without needing a break, maybe a few hours a day, or six, maybe four hours a day. So, 24/7.

+ +

Then, they can communicate with each other much better than humans do because they could share information sort of by transferring blocks of data across from one to the other without the ego getting in the way. I mean, you take humans, not very good at sharing information and discoveries. Then they don't have certain distractions that we have like romantic things and kids in schools and, you know.

+ +

CHAD: Although if you actually do get a full [laughs] AGI, then it might start to have those things [laughs].

+ +

PETER: Well, yeah, that's a whole nother topic. But our AIs, we basically build them not to want to have children [laughs] so, you know. And then, of course, things we spoke about, photographic memory. It has instantaneous access to all the information in the world, all the databases, you know, much better than we have, like, if we had a direct connection to the internet and brain, you know, but at a much higher bandwidth than we could ever achieve with our wetware.

+ +

And then, lastly, they are much better at reasoning than humans are. I mean, our ability to reason is what I call an evolutionary afterthought. We are not actually that good at logical thinking, and AIs can be, you know.

+ +

CHAD: We like to think we are, though.

+ +

PETER: [chuckles] Well, you know, compared to animals, yes, definitely. We are significantly better. But realistically, humans are not that good at rational, logical thinking.

+ +

CHAD: You know, I read something that a lot of decisions are made at a different level than the logical part. And then, the logical part justifies the decision.

+ +

PETER: Yeah, absolutely. And, in fact, this is why smart people are actually worse at that because they're really good at rationalizations. You know, they can rationalize their weird beliefs and/or their weird behavior or something. That's true.

+ +

CHAD: You mentioned that your primary customers are enterprises. Who makes up your ideal customer? And if someone was listening who matched that profile and wanted to get in touch with you, what would they look like?

+ +

PETER: The simplest and most obvious way is if they have call centers of 100 people or more—hundreds, or thousands, tens of thousands even. But the economics from about 100 people in the call center, where we might be able to save them 50% of that, you know, depending on the kind of business.

+ +

CHAD: And are your solutions typically employed before the actual people, and then they fall back to people in certain circumstances?

+ +

PETER: Correct. That's exactly right. And, you know, the advantage there is, whatever Aigo already gathers, we then summarize it and pop that to the human operator so that, you know, that the customer --

+ +

CHAD: That's great because that's super annoying.

+ +

PETER: It is.

+ +

CHAD: [laughs]

+ +

PETER: It is super annoying and --

+ +

CHAD: When you finally get to a person, and it's like, I just spent five minutes providing all this information that you apparently don't have.

+ +

PETER: Right. Yeah, no, absolutely, that's kind of one of the key things that the AI has that information. It can summarize it and provide it to the live operator. So that would be, you know, the sort of the most obvious use case.

+ +

But we also have use cases on the go with student assistant, for example, where it's sort of more on an individual basis. You know, imagine your kid just starts at university. It's just overwhelming. It can have a personal personal assistant, you know, that knows all about you in particular. But then also knows about the university, knows its way around, where you get your books, your meals, and, you know, different societies and curriculum and so on. Or diabetes coach, you know, where it can help people with diabetes manage their meals and activities, where it can learn whether you love broccoli, or you're vegetarian, or whatever, and help guide you through that. Internal help desks are another application, of course.

+ +

CHAD: Yeah. I was going to say even the same thing as at a university when people join a big company, you know, there's an onboarding process.

+ +

PETER: Exactly. Yeah.

+ +

CHAD: And there could be things that you're not aware of or don't know where to find.

+ +

PETER: Internal HR and IT, absolutely, as you say, on onboarding. Those are other applications where our technology is well-suited.

+ +

And one other category is what we call a co-pilot. So, think of it as Clippy on steroids, you know, where basically you have complex software like, you know, SAP, or Salesforce, or something like that. And you can basically just have Aigo as a front end to it, and you can just talk to it. And it will know where to navigate, what to get, and basically do things, complex things in the software.

+ +

And software vendors like that idea because people utilize more features of the software than they would otherwise, you know. It can accelerate your learning curve and make it much easier to use the product. So, you know, really, the technology that we have is industry and application-agnostic to a large extent. We're just currently not yet at human level.

+ +

CHAD: Right. I hope you get there eventually. It'll be certainly exciting when you do.

+ +

PETER: Yes. Well, we do expect to get there. We just, you know, as I said, we've just launched a project now to raise the additional money we need to hire the people that we need. And we actually believe we are only a few years away from full human-level intelligence or AGI.

+ +

CHAD: Wow, that's exciting. So, if the solution that you currently have and people want to go along for the journey with you, how can they get in touch with Aigo?

+ +

PETER: They could contact me directly: peter@aigo.ai. I'm also active on Twitter, LinkedIn.

+ +

CHAD: Cool. We'll include all of those links in the show notes, which people can find at giantrobots.fm.

+ +

If you have questions for me, email me at hosts@giantrobots.fm. Find me on Mastodon @cpytel@thoughtbot.social.

+ +

You can find a complete transcript for this episode as well at giantrobots.fm.

+ +

Peter, thank you so much for joining me. I really appreciate it and all of the wisdom that you've shared with us today.

+ +

PETER: Well, thank you. They were good questions. Thank you.

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Peter Voss.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP.

+ +

Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox!

+ +
+ +

Peter Voss is the CEO and Chief Scientist of Aigo.ai, a groundbreaking alternative to conventional chatbots and generative models like ChatGPT. Aigo's chatbot is powered by Artificial General Intelligence (AGI), enabling it to think, learn, and reason much like a human being. It boasts short-term and long-term memory, setting it apart in terms of personalized service and context-awareness.

+ +

Along with host Chad Pytel, Peter talks about how most chatbots and AI systems today are basic. They can answer questions but can't understand or remember the context. Aigo.ai is different because it's built to think and learn more like humans. It can adapt and get better the more you use it. He also highlights the challenges Aigo.ai faces in securing venture capital, given that its innovative approach doesn't align with current investment models heavily focused on generative or deep learning AI. Peter and Chad agree that while generative AI serves certain functions well, the quest for a system that can think, learn, and reason like a human demands a fundamentally different approach.

+ +
+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Peter Voss, CEO and Chief Scientist at Aigo.ai. Peter, thanks so much for joining me.

+ +

PETER: Yes, thank you.

+ +

CHAD: So, tell us a little bit about what Aigo.ai does. You've been working in AI for a long time. And it seems like Aigo is sort of the current culmination of a lot of your 15 years of work, so...

+ +

PETER: Yes, exactly. So, the quick way to describe our current product is a chatbot with a brain, and the important part is the brain. That basically, for the last 15-plus years, I've been working on the core technology for what's called AGI, Artificial General Intelligence, a system that can think, learn, reason similar to the way humans do. Now, we're not yet at human level with this technology. But it's a lot smarter and a lot more usable than traditional chatbots that don't have a brain.

+ +

CHAD: I want to dig into this idea a little bit. I think, like a lot of people, I've used just traditional chatbots, particularly like ChatGPT is the latest. I've built some things on top of it. What is the brain that makes it different? Especially if you've used one, what is using Aigo going to be different?

+ +

PETER: Right. I can give a concrete example of one of our customers then I can talk about the technology. So, one of our big customers is the 1-800-Flowers group of companies, which is Harry & David Popcorn Factory and several others. And wanted to provide a hyper-personalized concierge service for their customers where, you know, the system learns who you buy gifts for, for what occasions, you know, what your relationship is to them, and to basically remember who you are and what you want for each of their 20 million customers.

+ +

And they tried different technologies out there, you know, all the top brands and so on, and they just couldn't get it off the ground. And the reason is because they really don't learn. And we now have 89% self-service on the things that we've implemented, which is pretty much unheard of for complex conversations.

+ +

So, why can we do that? The reason is that our system has deep understanding. So, we have deep pausing, deep understanding, but more importantly, that the system remembers. It has short-term memory. It has long-term memory. And it uses that as context. So, you know, when you call back a second time, it'll remember what your previous call was, you know, what your preferences are, and so on. And it can basically use that information, the short and long-term memory, and reason about it. And that is really a step forward.

+ +

Now, until ChatGPT, which is really very different technology from chatbot technology, I mean, chatbot technology, you're assuming...the kind of thing we're talking about is really augmenting call center, you know, automatic call center calls. There, you need deep integration into the customers' back-end system. You obviously need to know what the latest product availability is, what the customers' outstanding orders are, you know, all sorts of things like, you know, delivery schedules. And we probably have, like, two dozen APIs that connect our system to their various corporate databases and so on.

+ +

Now, traditional chatbots obviously can do that. You hook up the APIs and do things, and it's, you know, it's a lot of work. But traditional chatbot technology really hasn't really changed much in 30 years. You basically have a categorizer; how can I help you? Basically, try to...what is the intent, intent categorizer? And then once your intent has been identified, you basically have a flowchart-type program that, you know, forces you down a flowchart. And that's what makes them so horrible because it doesn't use context. It doesn't have short-term memory.

+ +

CHAD: And I just wanted to clarify the product and where you mentioned call center. So, this isn't just...or only text-based chat. This is voice.

+ +

PETER: Yes. We started off with chat, and we now also have voice, so omnichannel. And the beauty of the system having the brain as well is you can jump from text messaging to a chat on the website to Apple ABC to voice, you know. So, you can basically move from one channel to another seamlessly. You know, so that's against traditional chatbot technology, which is really what everybody is still using.

+ +

Now, ChatGPT, of course, the fact that it's called ChatGPT sort of makes it a bit confusing. And, I mean, it's phenomenal. The technology is absolutely phenomenal in terms of what it can do, you know, write poems and give you ideas. And the amount of information it's amazing. However, it's really not suited for commercial-grade applications because it hallucinates and it doesn't have memory.

+ +

CHAD: You can give it some context, but it's basically faking it. You're providing it information every time you start to use it.

+ +

PETER: Correct. The next time you connect, that memory is gone, you know [crosstalk 05:58]

+ +

CHAD: Unless you build an application that saves it and then feeds it in again.

+ +

PETER: Right. Then you basically run out of context we know very quickly. In fact, I just published a white paper about how we can get to human-level AI. And one of the things we did and go over in the paper is we did a benchmark our technology where we fed the system about 300 or 400 facts, simple facts. You know, it might be my sister likes chocolate or, you know, it could be other things like I don't park my car in the garage or [chuckles], you know. It could be just simple facts, a few hundred of those. And then we asked questions about that.

+ +

Now, ChatGPT scored less than 1% on that because, you know, with an 8K window, it basically just couldn't remember any of this stuff. So, we use --

+ +

CHAD: It also doesn't, in my experience...it's basically answering the way it thinks the answer should sound or look. And so, it doesn't actually understand the facts that you give it.

+ +

PETER: Exactly.

+ +

CHAD: And so, if you feed it a bunch of things which are similar, it gets really confused because it doesn't actually understand the things. It might answer correctly, but it will, in my experience, just as likely answer incorrectly.

+ +

PETER: Yeah. So, it's extremely powerful technology for helping search as well if a company has all the documents and they...but the human always has to be in the loop. It just makes way too many mistakes. But it's very useful if it gives you information 8 out of 10 times and saves you a lot of time. And it's relatively easy to detect the other two times where it gives you wrong information. Now, I know in programming, sometimes, it's given me wrong information and ended up taking longer to debug the misinformation it gave me than it would have taken me. But overall, it's still a very, very powerful tool.

+ +

But it really isn't suitable for, you know, serious chatbot applications that are integrated into back-end system because these need to be signed off by...legal department needs to be happy that it's not going to get the company into trouble. Marketing department needs to sign off on it and customer experience, you know. And a generative system like that, you really can't rely on what it's going to say, and that's apart from security concerns and, you know, the lack of memory and deep understanding.

+ +

CHAD: Yeah. So, you mentioned generative AI, which is sort of one of the underlying pieces of ChatGPT. In your solutions, are you using any generative solutions?

+ +

PETER: No, not at all. Well, I can give one example. You know, what 1-800-Flowers do is they have an option to write a poem for your mother's birthday or Mother's Day or something like it. And for that, we will use ChatGPT, or they use ChatGPT for that because that's what it's good at. But, you know, that's really just any other app that you might call up to do something for you, you know, like calling up FedEx to find out where your goods are.

+ +

Apart from that, our technology...it's a good question you ask because, you know, statistical systems and generative AI now have really dominated the AI scene for the last about 12 years, really sort of since DeepMind started. Because it's been incredibly successful to take masses amounts of data and masses amounts of computing power and, you know, number crunch them and then be able to categorize and identify images and, you know, do all sorts of magical things.

+ +

But, the approach we use is cognitive AI as opposed to generative. It's a relatively unknown approach, but that's what we've been working on for 15 years. And it starts with the question of what does intelligence require to build a system so that it doesn't use masses amounts of data? It's not the quantity of data that counts. It's the quality of data.

+ +

And it's important that it can learn incrementally as you go along like humans do and that it can validate what it learns. It can reason about, you know, new information. Does this make sense? Do I need to ask a follow-up question? You know, that kind of thing. So, it's cognitive AI. That's the approach we're using.

+ +

CHAD: And, obviously, you have a product, and you've productized it. But you said, you know, we've been working on this, or you've been working on this model for a long time. How has it progressed?

+ +

PETER: Yes, we are now on, depending on how you count, but on the third major version of it that we've started. And really, the progress has been determined by resources really than any technology. You know, it's not that we sort of have a big R&D requirement. It's really more development. But we are a relatively small company. And because we're using such different technology, it's actually been pretty hard to raise VC money. You know, they look at it and, you know, ask you, "What's your training data? How big is your model?" You know, and that kind of thing.

+ +

CHAD: Oh, so the questions investors or people know to ask aren't relevant.

+ +

PETER: Correct. And, you know, they bring in the AI experts, and then they say, "Well, what kind of deep learning, machine learning, or generative, or what transformer model are using?" And we say, "Well, we don't." And typically, that's kind of, "Oh okay, well, then it can't possibly work, you know, we don't understand it."

+ +

So, we just recently launched. You know, with all the excitement of generative AI now recently, with so much money flowing into it, we actually launched a major development effort. Now we want to hire an additional a hundred people to basically crank up the IQ. So, over the years, you know, we're working on two aspects of it: one is to continually crank up the IQ of the system, that it can understand more and more complex situations; it can reason better and be able to handle bigger amounts of data. So, that's sort of the technical part that we've been working on.

+ +

But then the other side, of course, running a business, a lot of our effort over the last 15 years has gone into making it industrial strength, you know, security, scalability, robustness of the system. Our current technology, our first version, was actually a SaaS model that we deployed behind a customer's firewall.

+ +

CHAD: Yeah, I noticed that you're targeting more enterprise deployments.

+ +

PETER: Yeah, that's at the moment because, financially, it makes more sense for us to kind of get off the ground to work with, you know, larger companies where we supply the technology, and it's deployed usually in the cloud but in their own cloud behind their firewall. So, they're very happy with that. You know, they have complete control over their data and reliability, and so on. But we provide the technology and then just licensing it.

+ +

CHAD: Now, a lot of people are familiar with generative AI, you know, it runs on GPUs and that kind of thing. Does the hardware profile for where you're hosting it look the same as that, or is it different?

+ +

PETER: No, no, no, it requires much less horsepower. So, I mean, we can run an agent on a five-year-old laptop, you know, and it doesn't...instead of it costing $100 million to train the model, it's like pennies [laughter] to train the model. I mean, we train it during our regression testing, and that we train it several times a day.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: So, you mentioned ramping up the IQ is a goal of yours. With a cognitive model, does that mean just teaching it more things? What does it entail?

+ +

PETER: Yes, there's a little bit of tension between commercial requirements and what you ultimately want for intelligence because a truly intelligent system, you want it to be very autonomous and adaptive and have a wide range of knowledge. Now, for current commercial applications we're doing, you actually don't want the system to learn things by itself or to make up stuff, you know, you want it to be predictable. So, they develop and to ultimately get to full human-level or AGI capability requires a system to be more adaptive–be able to learn things more.

+ +

So, the one big change we are making to the system right now is natural language understanding or English understanding. And our current commercial version was actually developed through our—we call them AI psychologists, our linguists, and cognitive psychologists—by basically teaching it the rules of English grammar. And we've always known that that's suboptimal. So, with the current version, we are now actually teaching it English from the ground up the way a child might learn a language, so the language itself. So, it can learn any language.

+ +

So, for commercial applications, that wasn't really a need. But to ultimately get to human level, it needs to be more adaptive, more autonomous, and have a wider range of knowledge than the commercial version. That's basically where our focus is. And, you know, we know what needs to be done, but, you know, it's quite a bit of work. That's why we need to hire about 100 people to deal with all of the different training things. It's largely training the system, you know, but there are also some architectural improvements we need to make on performance and the way the system reasons.

+ +

CHAD: Well, you used the term Artificial General Intelligence. I understand you're one of the people who coined that term [chuckles] or the person.

+ +

PETER: Yes. In 2002, I got together with two other people who felt that the time was ripe to get back to the original dream of AI, you know, from 60 years ago, to build thinking machines basically. So, we decided to write a book on the topic to put our ideas out there. And we were looking for a title for the book, and three of us—myself, Ben Goertzel, and Shane Legg, who's actually one of the founders of DeepMind; he was working for me at the time. And we were brainstorming it, and that's what we came up with was AGI, Artificial General Intelligence.

+ +

CHAD: So, for people who aren't familiar, it's what you were sort of alluding to. You're basically trying to replicate the human brain, the way humans learn, right? That's the basic idea is --

+ +

PETER: Yeah, the human cognition really, yeah, human mind, human cognition. That's exactly right. I mean, we want an AI that can think, learn, and reason the way humans do, you know, that it can hit the box and learn a new topic, you know, you can have any kind of conversation. And we really believe we have the technology to do that.

+ +

We've built quite a number of different prototypes that already show this kind of capability where it can, you know, read Wikipedia, integrate that with existing knowledge, and then have a conversation about it. And if it's not sure about something, it'll ask for clarification and things like that. We really just need to scale it up. And, of course, it's a huge deal for us to eventually get to human-level AI.

+ +

CHAD: Yeah. How much sort of studying of the brain or cognition do you do in your work, where, you know, sort of going back and saying, "Okay, we want to tackle this thing"? Do you do research into cognition?

+ +

PETER: Yeah, that's a very interesting question. It really gets to the heart of why I think we haven't made more progress in developing AGI. In fact, another white paper I published recently is "Why Don't We Have AGI Yet?" And, you know, one of the big problems is that statistical AI has been so incredibly successful over the last decade or so that it sucked all of the oxygen out of the air.

+ +

But to your question, before I started on this project, I actually took off five years to study intelligence because, to me, that's really what cognitive AI approach is all about is you start off by saying, what is intelligence? What does it require? And I studied it from the perspective of philosophy, epistemology, theory of knowledge. You know, what's reality? How do we know anything?

+ +

CHAD: [laughs]

+ +

PETER: How can we be sure? You know, really those most fundamental questions. Then how do children learn? What do IQ tests measure? How does our intelligence differ to animal intelligence? What is that magic difference between, you know, evolution? Suddenly, we have this high-level cognition. And the short answer of that is being able to form abstract concepts or concept formation is sort of key, and to have metacognition, to be able to think about your own thinking.

+ +

So, those are kind of the things I discovered during the five years of study. Obviously, I also looked at what had already been done in the field of AI, as in good old-fashioned AI, and neural networks, and so on. So, this is what brought me together. So, absolutely, as a starting point to say, what is intelligence? Or what are the aspects of intelligence that are really important and core?

+ +

Now, as far as studying the brain is concerned, I certainly looked at that, but I pretty quickly decided that that wasn't that relevant. It's, you know, you certainly get some ideas. I mean, neural networks, ours is kind of a neural network or knowledge graph, so there's some similarity with that. But the analogy one often gives, which I think is not bad, is, you know, we've had flying machines for 100 years. We are still nowhere near reverse engineering a bird.

+ +

CHAD: Right.

+ +

PETER: So, you know, evolution and biology are just very different from designing things and using the materials that we need to use in computers. So, definitely, understanding intelligence, I think, is key to being able to build it.

+ +

CHAD: Well, in some ways, that is part of the reason why statistical AI has gotten so much attention with that sort of airplane analogy because it's like, maybe we need to not try to replicate human cognition [chuckles]. Maybe we need to just embrace what computers are good at and try to find a different way.

+ +

PETER: Right, right. But that argument really falls down when you say you are ignoring intelligence, you know, or you're ignoring the kind of intelligence. And we can see how ridiculous the sort of the current...well, I mean, first of all, let me say Sam Altman, and everybody says...well, they say two things: one, we have no idea how these things work, which is not a good thing if you're [chuckles] trying to build something and improve it. And the second thing they say...Demis Hassabis and, you know, everybody says it, "This is not going to get us to human-level AI, to human-level intelligence."

+ +

They realize that this is the wrong approach. But they also haven't come up with what the right approach is because they are stuck within the statistical big data approach, you know, we need another 100 billion dollars to build even bigger computers with bigger models, you know, but that's really --

+ +

CHAD: Right. It might be creating a tool, which has some uses, but it is not actual; I mean, it's not really even actual artificial intelligence --

+ +

PETER: Correct. And, I mean, you can sort of see this very easily if...imagine you hired a personal assistant for yourself, a human. And, you know, they come to you, and they know how to use Excel and do QuickBooks or whatever, and a lot of things, so great. They start working with you.

+ +

But, you know, every now and again, they say something that's completely wrong with full confidence, so that's a problem. Then the second thing is you tell them, "Well, we've just introduced a new product. We shut down this branch here. And, you know, I've got a new partner in the business and a new board member." And the next day, they come in, and they remember nothing of that, you know, [chuckles] that's not very intelligent.

+ +

CHAD: Right. No, no, it's not. It's possible that there's a way for these two things to use each other, like generating intelligent-sounding, understanding what someone is saying and finding like things to it, and being able to generate meaningful, intelligent language might be useful in a cognitive model.

+ +

PETER: We obviously thought long and hard about this, especially when, you know, generative AI became so powerful. I mean, it does some amazing things. So, can we combine the technology? And the answer is quite simply no. As I mentioned earlier, we can use generative AI kind of as an API or as a tool or something. You know, so if our system needs to write a poem or something, then yes, you know, these systems can do a good job of it.

+ +

But the reason you can't really just combine them and kind of build a Frankensteinian kind of [laughs] thing is you really need to have context that you currently have fully integrated. So you can't have two brains, you know, the one brain, which is a read-only brain, and then our brain, our cognitive brain, which basically constantly adapts and uses the context of what it's heard using short-term memory, long-term memory, reasoning, and so on.

+ +

So, all of those mental mechanisms of deep understanding of context, short-term and long-term memory, reasoning, language generation–they all have to be tightly integrated and work together. And that's basically the approach that we have. Now, like a human to...if you write, you know, "Generate an essay," and you want to have it come up with maybe some ideas, changing the style, for example, you know, it would make sense for our system to use a generative AI system like a tool because humans are good tool users. You know, I wouldn't expect our system to be the world chess champion or Go champion. It can use a chess-playing AI or a Go-playing AI to do that job.

+ +

CHAD: That's really cool. You mentioned the short-term, long-term memory. If I am using or working on a deployment for Aigo, is that something that I specify, like, oh, this thing where we've collected goes in short term versus long term, or does the system actually do that automatically?

+ +

PETER: That's the beauty of the system that: it automatically has short and long-term memory. So, really, the only thing that needs to be sort of externally specified is things you don't want to keep in long-term memory, you know, that for some reason, security reasons, or a company gives you a password or whatever. So, then, they need to be tagged.

+ +

So, we have, like, an ontology that describes all of the different kinds of knowledge that you have. And in the ontology, you can tag certain branches of the ontology or certain nodes in the ontology to say, this should not be remembered, or this should be encrypted or, you know, whatever. But by default, everything that comes into short-term memory is remembered. So, you know, a computer can have photographic memory.

+ +

CHAD: You know, that is part of why...someone critical of what they've heard might say, "Well, you're just replicating a human brain. How is this going to be better?" And I think that that's where you're just...what you said, like, when we do artificial general intelligence with computers, they all have photographic memory.

+ +

PETER: Right. Well, in my presentations, when I give talks on this, I have the one slide that actually talks about how AI is superior to humans in as far as getting work done in cognition, and there's actually quite a number of things. So, let me first kind of give one example here. So, imagine you train up one AI to be a PhD-level cancer researcher, you know, it goes through whatever training, and reading, and coaching, and so on.

+ +

So, you now have this PhD-level cancer researcher. You now make a million copies of that, and you have a million PhD-level cancer researchers chipping away at the problem. Now, I'm sure we would make a lot more progress, and you can now replicate that idea, that same thinking, you know, in energy, pollution, poverty, whatever, I mean, any disease, that kind of approach. So, I mean, that already is one major difference that you make copies of an AI, which you can't of humans.

+ +

But there are other things. First of all, they are significantly less expensive than humans. Humans are very expensive. So much lower cost. They work 24/7 without breaks, without getting tired. I don't know the best human on how many hours they can concentrate without needing a break, maybe a few hours a day, or six, maybe four hours a day. So, 24/7.

+ +

Then, they can communicate with each other much better than humans do because they could share information sort of by transferring blocks of data across from one to the other without the ego getting in the way. I mean, you take humans, not very good at sharing information and discoveries. Then they don't have certain distractions that we have like romantic things and kids in schools and, you know.

+ +

CHAD: Although if you actually do get a full [laughs] AGI, then it might start to have those things [laughs].

+ +

PETER: Well, yeah, that's a whole nother topic. But our AIs, we basically build them not to want to have children [laughs] so, you know. And then, of course, things we spoke about, photographic memory. It has instantaneous access to all the information in the world, all the databases, you know, much better than we have, like, if we had a direct connection to the internet and brain, you know, but at a much higher bandwidth than we could ever achieve with our wetware.

+ +

And then, lastly, they are much better at reasoning than humans are. I mean, our ability to reason is what I call an evolutionary afterthought. We are not actually that good at logical thinking, and AIs can be, you know.

+ +

CHAD: We like to think we are, though.

+ +

PETER: [chuckles] Well, you know, compared to animals, yes, definitely. We are significantly better. But realistically, humans are not that good at rational, logical thinking.

+ +

CHAD: You know, I read something that a lot of decisions are made at a different level than the logical part. And then, the logical part justifies the decision.

+ +

PETER: Yeah, absolutely. And, in fact, this is why smart people are actually worse at that because they're really good at rationalizations. You know, they can rationalize their weird beliefs and/or their weird behavior or something. That's true.

+ +

CHAD: You mentioned that your primary customers are enterprises. Who makes up your ideal customer? And if someone was listening who matched that profile and wanted to get in touch with you, what would they look like?

+ +

PETER: The simplest and most obvious way is if they have call centers of 100 people or more—hundreds, or thousands, tens of thousands even. But the economics from about 100 people in the call center, where we might be able to save them 50% of that, you know, depending on the kind of business.

+ +

CHAD: And are your solutions typically employed before the actual people, and then they fall back to people in certain circumstances?

+ +

PETER: Correct. That's exactly right. And, you know, the advantage there is, whatever Aigo already gathers, we then summarize it and pop that to the human operator so that, you know, that the customer --

+ +

CHAD: That's great because that's super annoying.

+ +

PETER: It is.

+ +

CHAD: [laughs]

+ +

PETER: It is super annoying and --

+ +

CHAD: When you finally get to a person, and it's like, I just spent five minutes providing all this information that you apparently don't have.

+ +

PETER: Right. Yeah, no, absolutely, that's kind of one of the key things that the AI has that information. It can summarize it and provide it to the live operator. So that would be, you know, the sort of the most obvious use case.

+ +

But we also have use cases on the go with student assistant, for example, where it's sort of more on an individual basis. You know, imagine your kid just starts at university. It's just overwhelming. It can have a personal personal assistant, you know, that knows all about you in particular. But then also knows about the university, knows its way around, where you get your books, your meals, and, you know, different societies and curriculum and so on. Or diabetes coach, you know, where it can help people with diabetes manage their meals and activities, where it can learn whether you love broccoli, or you're vegetarian, or whatever, and help guide you through that. Internal help desks are another application, of course.

+ +

CHAD: Yeah. I was going to say even the same thing as at a university when people join a big company, you know, there's an onboarding process.

+ +

PETER: Exactly. Yeah.

+ +

CHAD: And there could be things that you're not aware of or don't know where to find.

+ +

PETER: Internal HR and IT, absolutely, as you say, on onboarding. Those are other applications where our technology is well-suited.

+ +

And one other category is what we call a co-pilot. So, think of it as Clippy on steroids, you know, where basically you have complex software like, you know, SAP, or Salesforce, or something like that. And you can basically just have Aigo as a front end to it, and you can just talk to it. And it will know where to navigate, what to get, and basically do things, complex things in the software.

+ +

And software vendors like that idea because people utilize more features of the software than they would otherwise, you know. It can accelerate your learning curve and make it much easier to use the product. So, you know, really, the technology that we have is industry and application-agnostic to a large extent. We're just currently not yet at human level.

+ +

CHAD: Right. I hope you get there eventually. It'll be certainly exciting when you do.

+ +

PETER: Yes. Well, we do expect to get there. We just, you know, as I said, we've just launched a project now to raise the additional money we need to hire the people that we need. And we actually believe we are only a few years away from full human-level intelligence or AGI.

+ +

CHAD: Wow, that's exciting. So, if the solution that you currently have and people want to go along for the journey with you, how can they get in touch with Aigo?

+ +

PETER: They could contact me directly: peter@aigo.ai. I'm also active on Twitter, LinkedIn.

+ +

CHAD: Cool. We'll include all of those links in the show notes, which people can find at giantrobots.fm.

+ +

If you have questions for me, email me at hosts@giantrobots.fm. Find me on Mastodon @cpytel@thoughtbot.social.

+ +

You can find a complete transcript for this episode as well at giantrobots.fm.

+ +

Peter, thank you so much for joining me. I really appreciate it and all of the wisdom that you've shared with us today.

+ +

PETER: Well, thank you. They were good questions. Thank you.

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Peter Voss.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7QnINf57 + + ]]> + + Chad Pytel + Peter Voss + + + 493: Mobile Development at thoughtbot with Stephen Hanson + https://podcast.thoughtbot.com/493 + 3eadc43d-dae5-4377-8324-57846135cb35 + Thu, 21 Sep 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Co-host Will Larry interviews Stephen Hanson, the Director of Mobile Development at thoughtbot. The two explore the complexities of mobile app development, focusing on the advantages and disadvantages of React Native and Flutter. + +Stephen, who initially started as a full-stack web developer specializing in Enterprise Java, discusses React Native's cost-effectiveness and the convenience of having a unified codebase for iOS and Android platforms. However, he notes that Flutter might be a more suitable choice for high-performance needs. Both hosts emphasize the nuances of the mobile ecosystem, covering topics like in-app purchases, push notifications, and the strict guidelines set by app stores like Apple's. They agree that a comprehensive understanding of these aspects is crucial for an entire development team, including designers and project managers. + +Additionally, Stephen shares that the driving force behind his career is the opportunity to create apps that enhance people's lives. Stephen wraps up the discussion by detailing thoughtbot's goals of improving mobile development practices within the company and the broader developer community. + 34:30 + no + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP. +Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox! +__ +Co-host Will Larry interviews Stephen Hanson, the Director of Mobile Development at thoughtbot. The two explore the complexities of mobile app development, focusing on the advantages and disadvantages of React Native and Flutter. +Stephen, who initially started as a full-stack web developer specializing in Enterprise Java, discusses React Native's cost-effectiveness and the convenience of having a unified codebase for iOS and Android platforms. However, he notes that Flutter might be a more suitable choice for high-performance needs. Both hosts emphasize the nuances of the mobile ecosystem, covering topics like in-app purchases, push notifications, and the strict guidelines set by app stores like Apple's. They agree that a comprehensive understanding of these aspects is crucial for an entire development team, including designers and project managers. +Additionally, Stephen shares that the driving force behind his career is the opportunity to create apps that enhance people's lives. Stephen wraps up the discussion by detailing thoughtbot's goals of improving mobile development practices within the company and the broader developer community. +__ +React Native (https://reactnative.dev/) +Flutter (https://flutter.dev/) +Follow Stephen Hanson on LinkedIn (https://www.linkedin.com/in/hansonsteve/). Visit his website: shanson.co (https://shanson.co/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Stephen Hanson, Director of Mobile Development here at thoughtbot. Stephen, thank you for joining me. +STEPHEN: Hi, Will. Thanks for having me. I'm excited to be here. +WILL: Yeah. I'm excited to talk about mobile development. But before we get started, tell us a little bit about who Stephen Hanson is: your personal life. +STEPHEN: You know this because we often talk about our families when we get together. But I have two young kids, two and four years old. When you say personal life to anybody who has young kids, that's what we're talking about. +[laughter] +WILL: Yes. +STEPHEN: So, they're keeping me busy but in the best way. +WILL: Yeah, definitely. And I totally understand that. So, I know we talk about this often, but you like to woodwork. You like to work with your hands like most of us in tech. Like, we think so much with our head and mental that we try to find something to do physically, and yours is woodworking. Tell me a little bit about that. +STEPHEN: Yeah. I think it's exactly what you said. I think working on a computer all day, you know, many years ago, I was like, what's something I can do with my hands, right? Something a little more physical. So yeah, fine woodworking has been a hobby of mine for quite a few years. And we were even chatting the other day about, you know, I'm trying to take time during the day to sneak out to the garage for 15 minutes, you know, during my lunch break or whatever to just get that mental reset and just work on something. +WILL: Yeah. I know that you built your office that you work out of. I've been wanting to ask you, one, how did you do it? Two, how did you have the confidence to do it [laughter] to make sure that it was going to...how can I say this? I would be afraid that would it still be standing [laughter] after a little bit? [laughs] +STEPHEN: Yeah, to be honest, that was definitely a fear. Yeah, I built my office in 2020, you know, COVID hit. All of a sudden, I was working fully remote. And we had another kid on the way. You know, we didn't have space in the house. So, I was like, what am I going to do? [laughs] I was already doing woodworking, but I didn't have any construction or carpentry experience. +So, yeah, I definitely had the confidence issue. And I think, you know, I was just like, I don't know, let's just give it a try. [laughter] That's really all I can say. I didn't have the skills yet. But I watched a lot of YouTube and read a lot of [laughs] forums or, you know, just found info wherever I could, so...[laughs] +WILL: Yep. And it's still standing today, correct? [laughs] +STEPHEN: Correct. Yeah. [laughs] No, I'm just sitting in, like, a pile of rubble right now. +[laughter] +WILL: That's awesome, yeah. It's kind of like development sometimes for me. Like, you just got to take that leap sometimes, so... +STEPHEN: You do, right? It's like, you know, fake it till you make it. +[laughter] +WILL: Yep. That's awesome. Awesome. Awesome. So, tell us a little bit about how did you get started in development in general? And then, how did you get started in React Native? +STEPHEN: Yeah. So, I started out as a full-stack web developer. So, I didn't initially set out and say, "I'm going to build mobile apps," right? And I started out in 2011. I was working in Enterprise Java. I worked for American Airlines for a couple of years, and then I did enterprise consulting. I eventually made my way to, like, Rails and front-end development. And around 2016, 2017, I was freelancing. And eventually, clients started asking me to build mobile apps. [chuckles] +WILL: [inaudible 04:16] +STEPHEN: And I didn't know how to build mobile apps. So, I did what any web developer would do who doesn't build apps, and I used web technology. So, those first couple of apps that I built were hybrid apps. I used Ionic. And those are, you know, web apps that you package in a Native Wrapper. So, developing these apps, I literally developed them in a browser, right? And they're web apps. [laughs] And that was my first experience building apps. +Even if they were web-based, I still had to work with the native app stores and learn, you know, app review guidelines and implement some native functionality, even though it was through, like, the Ionic wrappers. You know, people kind of trash on hybrid apps, and sometimes for good reason. But that wasn't a bad first experience for me or outcome, honestly. The clients were happy. They had apps in the app stores that were working for a pretty reasonable development cost. So yeah, that was my first experience in mobile. The end result isn't something I'd be necessarily proud of today. [laughs] +WILL: I think that's all devs. [laughs] +STEPHEN: Yeah, you know, [laughter] yeah, I -- +WILL: Looking back at their work, yeah. [laughs] +STEPHEN: I was talking about that. I could look back to something I built a month ago. [laughs] +WILL: Yes. +[laughter] +STEPHEN: You don't have to go back far. +[laughter] +WILL: Yeah, so true [laughs]. You started working with the client when you were freelancing. So, how did you go from the hybrid web apps to actually saying, okay, I want to change, and I want to go all in on React Native? +STEPHEN: React Native came out around that same time I was building those hybrid apps. So, the hybrid apps were 2016, 2017. React Native came out in 2015. So it was out, but it was still pretty new. And I was really interested in React Native right from the beginning, but I was also a little intimidated by it [chuckles]. +So, when those first clients came to me for mobile apps, I didn't feel confident enough to say, "Yes, I can build you a React Native app." But a year or two later, I was working for another client on their Rails app. And I was building an API for their new React Native app. You know, I was really interested in React Native. So I said, "Hey, [chuckles] why don't I help out on the app side, too?" And they were like, "Sure, that sounds great." So that was kind of where I got my foot in the door with React Native. +And then more opportunities like that just kept popping up over the next year. So, I got to work on a couple of other React Native apps. And like we talked about, I just started calling myself a React Native developer [laughs]. The rest is history. +WILL: Yep. So true. We'll touch more on that later. But what would you say to a client who is trying to figure out if they should build native versus React Native? +STEPHEN: There's a few things to consider when making that decision. But I think, usually, what I've seen is it comes down to budget and user experience. The bottom line is React Native is going to be a lot cheaper. You're basically building one app instead of two, right? Most of your code in a React Native app is going to be in JavaScript, and you can reuse all of that code across Android and iOS. +If you're building a native app, you're just building two completely separate apps. So, it's just going to be cheaper to build that React Native app, and a lot of times, that's what it comes down to. For most companies, it can be really hard to justify that extra cost of building a completely native app for each platform. +But then the question is when we talk about how can you justify the cost? Well, what would justify the cost, right? [laughs] I think probably the biggest trade-off when you build a React Native app versus a purely native app is there is a little bit of a performance penalty by building in React Native versus native. +So, I think apps that will need to have a very flashy cutting-edge experience with lots of user-driven animation and effects, you know, when you get into that domain, I think that's where we see pure native starting to make more sense. But most apps and users would never feel that performance penalty of React Native. So, for most apps, that's not really something that enters into the equation. +WILL: I want to dig into something you said. You were talking about if you do go native, you usually have to build an iOS and an Android separately. But with React Native, you could do it together. So, for someone who's maybe never done either one of them, can you kind of dig into, like, what does that look like? So, when you say I have to build an iOS and an Android portion versus I can do one codebase for React Native, can you walk us through kind of what that looks like, just a sample feature? +STEPHEN: When I say React Native is a single codebase and, you know, native apps, you're building two apps, the way React Native works is you're basically building a React app. So, all of your business logic is going to be in React. And when your React code renders some UI, that gets translated into native UI. But your business logic is still going to be living in that JavaScript React app. So, one, when I say performance penalty, that's what I'm talking about is: there's a little bit of a performance penalty communicating back and forth between your JavaScript thread and the native system thread. +But when we talk about one codebase versus two, that's what a React Native app looks like. You basically are working on a React app. It's one codebase with one set of business logic. And when you say, "Show a modal on the screen," that gets translated into a native Android modal or a native iOS modal, but in your code, you're just saying, "Show a modal." [laughs] So, you're just writing that one time. So yeah, a React Native project is just one codebase. +Now, one thing that we haven't really touched on is in a React Native app, you do have the ability to drop down into native code. So, you have access to the native Android project and the native iOS project in your React Native app. So, you can write completely native code if you want to. +But the appeal of React Native is you don't have to, you know, unless you get into one of those situations where you need to do something native that isn't supported out of the box with React Native or by an existing third-party library, or you want to have a very performant, very interactive part of your app. Maybe there's a reason you want to do that in native. You know, you do have that option in a React Native app of dropping down into that native code level. +But to contrast that with a purely native project, you will have two completely separate codebases, one for Android and one for iOS. You'll have a development team for Android and a development team for iOS, you know, typically with different skill sets. The Android project will be Java, Kotlin. And your iOS project is swift. So, just in every sense, you really have two different projects when you're working on a purely native app. +WILL: Okay, yeah, that makes sense. So like, for React Native, that show modal is just however many lines to show that one modal, and it does it for iOS and Android. But when you talk about native, you're saying that; however, iOS says to show that modal, you have to do it that way. But then Android, you also have to do it the Android way. And one developer, unless they know both of them, may not be able to handle both for those cases, correct? +STEPHEN: Yeah, exactly. React Native abstracts away those underlying platforms. So, you really just need to know React Native for most cases. Though, there's definitely a benefit of knowing the underlying platforms. +WILL: Definitely. Especially, like you touched on if you wanted to go into that native portion to add in a feature. You know, for example, I know we both worked on a project where we had a scanning app. And we had to tap into that native portion and React Native in order to get the scanning app to work, correct? +STEPHEN: Yeah, that's right. We had to support some barcode scanning devices and hook into those barcode scanning frameworks that were proprietary [chuckles] to those devices. So yeah, we had to build native modules for Android and iOS to support those. +WILL: Gotcha. Okay. I want to touch back on something you said earlier about the flashy experiences. You said sometimes you may not see it or whatever, but sometimes, if you want that flashy experience, it's better to go the native route. Can you explain that a little bit more? +STEPHEN: So yeah, it's kind of what I was touching on a second ago. You know, in a React Native app, you have the JavaScript thread that is always running and coordinating UI changes with business logic. So, you've got your business logic in JavaScript. You've got the UI in native. And those need to be coordinated to interact. So, that's kind of where that performance penalty can happen. +You know, again, most apps and users would never feel this penalty. I've never been, like, using my phone and been like, oh, this is a React Native app; I can feel it, you know. [laughs] It's not something that typically enters the picture for most apps that we work on. But there are certain types of apps that might be more important, you know, highly interactive games or things that just need to have that extra flashiness and interactive flashiness specifically, where it could make sense to build that natively. +Another interesting thing in the React Native space is React Native recently re-architected their rendering engine to be written in C++ and be more efficient. So, this performance overhead might be a little bit less of a trade-off. They've re-architected the way that React Native JavaScript talks to the native layer, which might make this even less of an issue going forward. +WILL: I looked it up for the podcast. But do you know some of the companies that we probably are familiar with, like they built apps on React Native? Can you name a couple? +STEPHEN: Yeah, I was recently looking at this, too. And, you know, the big one is Facebook, right? Facebook built React Native. So, they're the sponsor of that project. So, Facebook and Facebook Messenger, I believe those apps are built with React Native. I don't know if the entire apps are or not [chuckles]. Do you know by chance? [laughs] +WILL: React Native on their website says, "Hey, we're going to showcase these apps that they're built in React Native." So, I'm guessing a huge portion of it was built in React Native, so... +STEPHEN: Yeah. That's a good point. Yeah, you're right. They're showcasing it there. So yeah, you know, other ones, you know, lots of brands, Shopify, looks like PlayStation. I'm looking at the list now on the React Native website: Pinterest, Flipkart, Discord, Walmart, Tesla, Coinbase, Mercari. Yeah, I mean, it's just a lot of big-name apps built in React Native, including quite a few that we've [laughs] that we've built. +[laughter] +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at tbot.io/entrepreneurs. +WILL: If I'm absolutely sold on getting that flashy experience, is native the only route to go? +STEPHEN: I think until pretty recently, that would have been your option [laughs]. But Flutter has been picking up a little bit of momentum. So, Flutter is developed by Google. And it's kind of a challenger in that React Native space. It kind of has the same write once, run anywhere, you know, philosophy as React Native. You have one codebase. But they tout kind of being a more performant option than React Native. So, it compiles down to native ARM or Intel code, which can give better performance without, you know, not needing that JavaScript bridge kind of handling that communication between the UI and the business logic. +WILL: So, when would you use Flutter versus React Native? +STEPHEN: I kind of keep going back to, like, you know, we talk about the performance overhead of a React Native app. I don't think that's even on the map for the vast majority of apps. Like, this isn't a performance penalty that you can typically feel. +So, looking at Flutter versus React Native, React Native has several advantages. I think the biggest one is it's React. So, every team has React developers already on the team, pretty much nowadays. So, you know, if you've got an organization that says, "Oh, we need to build a mobile app," they probably already have a team of React developers somewhere working on their web app [laughs]. So, there's a big benefit of kind of centralizing their team around that technology. You know, you can have a little bit of cross-pollination between web and mobile, which can be really nice. +I think, similarly, it's a lot easier to find and hire React or React Native developers right now than it is to find and hire Flutter developers. So, Flutter is written in Dart, and it has its own front-end framework. So, this isn't necessarily a technology that you're going to have on your existing team. Like, I've never worked with Dart, personally. It's not nearly as common as React developers. You know, that, to me, is going to be a big downside. You know, the talent pool is a lot smaller for Flutter/Dart developers. +Also, the ecosystem with Flutter being newer, it's not as established. It doesn't have as large of an ecosystem as React Native. So, for those reasons, I think React Native is still, at least for us, like, it's usually where we would steer a client over Flutter, unless they're in that category of, like, they're really going for something, you know, groundbreaking. And, you know, the choice is either, you know, they've ruled out React Native. They need to get that native performance, and maybe they could achieve that with Flutter, and maybe Flutter would be a good option then. +WILL: Okay. You mentioned that—and I agree with you—like, you probably have some React devs on your team somewhere. Most companies does. So, say if I am bought in, I'm going all in on React Native, and I have React web developers on my team. Is that an easy transition for those developers, or what does that transition look like? +STEPHEN: Yeah, this is something...I think you and I have talked about this a lot because we both transitioned from React Web to React Native. And, you know, it wasn't all that easy, right? [laughs] +WILL: No, it was not [laughter] at all. +[laughter] +STEPHEN: So yeah, you know, it is a fallacy to say, "Hey, we've got a React team, you know, let's just start tomorrow on building an app, and it'll be smooth sailing. And, you know, no one needs to learn anything, and we'll be good to go," right? [laughs] So, you know, what I always say is a React web developer can successfully work on a React Native app. But I don't think they have the skills yet to lead that initiative because there's just so much to the mobile ecosystem that needs to be learned. +And really, you know, my first couple of React Native apps, I wasn't the lead developer. There was somebody on those projects who really knew that space better than I did. And that was really helpful for me to have. How about you? What about your first, like, React Native project? What did that look like? +WILL: It was at another company, and the exact words paraphrasing was, "You know React, so you can easily work on React Native." And so, I got on the project. And I really struggled, to be honest with you, because there's a lot of things that I didn't know: in-app purchases, push notifications, how to deal with Apple store, Android store, deploying to those stores. Like all of those things, navigation is totally different than React navigations and routes. It was a lot. It was a lot more than they led on to what it was. +Eventually, I caught on. It took me a while. I needed to work with some more senior React Native developers, and I was able to really pick it up. But yeah, it was tough. I'll be honest: I struggled for a while because I went in feeling like I should have known all those things because that's the way it was conveyed to me. Now that I look back on it I was like, there's no way I could have known those things. It's just a different language. So, I had to get in there and learn it. +And I even...I'm trying to think I've learned a couple of new languages. But it's almost like learning a new language just with, you know, the, like I mentioned, the in-app purchases, push notifications. It's just totally different. +STEPHEN: Yeah, that's been my experience also. I think the challenges weren't, like, coding [laughs] because, you know, building a React Native app is coding in React. The challenges that I faced were, like you said, it's just the mobile ecosystem and learning all the intricacies, the functionality that users have come to expect in mobile apps, you know, like password manager, integration, and background execution modes, and deep linking strategies, all that kind of stuff. +You know, if you don't know what questions to ask or what features to be thinking of, it's just really hard. And [laughs] I think it's more than just the developer needing to know that too. I think anytime it comes, you know, down to building an app, the whole team needs to have that mobile background. It's just a completely different platform than building for the web, right? So like, product owners, project managers, designers, developers all need that context so we can be prioritizing the right features and building a UI that matches the patterns that people have come to expect in a mobile app. And then, of course, developing those apps using the, you know, the proper native modules. +WILL: Yeah, definitely. And I [chuckles]...you mentioned that it's mostly on, like, the mobile side. I don't know the best way to say that. But, like, I can tell you, when I first got onto the React Native project, there were numerous features that I could implement, and to a certain point to where I had to go that mobile. +So, like, I was like, oh yeah, I can learn these new components that's in React Native. Okay, I got it to work. It's finished. You know, my PM would be like, "Well, it's not completely finished because you have to deploy it." And I was like, oh, I have no idea what I'm doing now. Like, I just know [laughs]...I know up to this point. +STEPHEN: [laughs] +WILL: But anything over that, I'm like, yeah, I have no idea. +STEPHEN: Especially with consulting, right? With consulting, you need even more expertise, right? The clients are counting on you to build their app. And that's where, you know, having that deep, deep familiarity where you can say to a client, "This is how we're going to do the deployment process, you know, and I need, you know, X, Y, and Z to help set it up. And here are the deliverables, and here's when we'll have it," that kind of thing. Like, it really takes it up a whole nother notch what you need to know. +WILL: Definitely, yeah. Because I think compared to mobile, I feel like web development can almost be like the Wild Wild West. And what I mean by that is, like, there's no rules for you to push out a website in web. Like, you know, you build it. You push it out. It can be out there, you know. Whoever is hosting it, unless you go against their rules, maybe, but their rules are very relaxed and stuff like that. +Mobile, there's a totally different set of rules. Because, like, I was laughing not too long ago. There was rumors that Elon Musk was going to remove the blocking feature on Twitter [chuckles]. And it was funny because all the mobile devs they came out. And if you're a mobile dev, you know this. Apple is very strict. +STEPHEN: [laughs] +WILL: If this is a social media app that you're building, you have to have that blocking feature, which I agree it needs to be there. But it's funny, like, all the mobile devs was like, yeah, that's not going to work. Good luck [chuckles]. Good luck being an app again. +STEPHEN: Yeah, [laughs] good luck. +WILL: Like, they're going to kick it off. And yeah, they're very big on kicking it off if it doesn't follow those rules and things like that. So yeah, for React Native, you have to learn those rules, or, like I said, they won't approve it. They won't push it out to their store. +STEPHEN: Yep, exactly. Yeah. I feel like the new one at every client project; I have to say, "We have to offer a way to delete your account in the app," because [laughs] that's a new one that launched last year, and I think has just started being enforced more recently. Like, all those little gotcha rules, you know, like, if you don't know about that, then you're going to go to submit your app to the stores, and you're going to get rejected every single time. [laughs]. +WILL: And they're not shy about rejecting you [laughs]. +STEPHEN: Yeah. But I would say, like, a lot of the rules, I'm like, yes, this is amazing that we have these rules, you know. It does help keep the community safer like things like blocking. But then there's the other rules of, like, Apple's like, hey, you've got to use our payment system and pay us 30% of every sale. +WILL: Yes [laughs]. +STEPHEN: I was, like, you know, there's some evil stuff happening there, too. +WILL: I totally agree. And we ran into that issue. We had an app that used Stripe. And we actually had to remove it in order to use in-app purchases because...I forgot the rules around it, but it was essentially for digital content. I think it's what it was. And so, we had to use Apple's in-app purchases. So yeah, I totally agree with you on that. +STEPHEN: Yeah. I feel like I've been a part of so many apps where we're, like, reading those rules. And we're like, okay, you know, it's like, we're watching a live stream of birds. +WILL: [laughs] +STEPHEN: You know, like, the birds aren't digital [laughter], you know. It's like, [laughs] where does this fall in the rule? [laughs] +WILL: Yes [laughs]. I've done that, too [laughter]. Yep. It's almost like, you know, I feel like lawyers, okay, like, is this what this rule is, or the law what is written, or does this fall underneath that? So yeah, totally, totally agree. +STEPHEN: Yep [laughs]. +WILL: So, you've been here a couple of years at thoughtbot. What has been your experience building React Natives here for clients at thoughtbot? +STEPHEN: Yeah, yeah. I've been at thoughtbot for about five years now. And I have been building React Native apps that whole time. And, I mean, I started at thoughtbot a little more in the full-stack space, web development, and have transitioned to where I'm mostly only building React Native mobile apps now. +It's been a great experience. I think that React Native is really a sweet spot of; we're able to build these apps really efficiently and much less expensively than when we're doing pure native. And the end product is a really good app. So, it's been a great experience, you know, React Native is really...it has a really nice development experience. You know, it's the JavaScript React ecosystem. And we use TypeScript, and we have a really good developer experience with it. And then we're building apps that clients are really happy with and with a good budget. +So, I think it's kind of that, you know, like, win-win-win kind of scenario where everybody is happy. And yeah, I don't see it going anywhere. And I think we're going to be building React Native apps for quite a while to come. +WILL: Yeah, I totally agree with that. Where do you see React Native and mobile dev going here at thoughtbot in the next six months or even the next year? What are your goals for the mobile team? +STEPHEN: We've got a couple of goals. One of them is around kind of what we've talked about with the mobile space in general. This isn't really specific to React Native, but it can be. But, consulting in the mobile space is challenging because there's a lot of mobile-specific domain knowledge that a team really needs to have. +So, that's something that we've started looking into is, like, how do we build up our resources internally and then, hopefully, externally as well to help guide us on our projects and ensure that we have, like, you know, we are developing apps consistently and efficiently every time? So, that's something we're looking into is, like resources to help our teams—not just developers, but project managers, designers, and developers—help us navigate the mobile space. +Okay, you're going to do push notifications. Here's the library we use. Here's things to think about, and interactions to think about, and iOS-specific functionality that we could support, and Android-specific functionality that we can support. You know, you're going to do deep linking; do you want to use universal links, or do you want to use a different strategy, a scheme-based link? So, basically, building up that set of resources so that our teams are all able to consult and build efficiently and consistently across the board. So, that's kind of goal number one. +And then, goal number two is to kind of bring some of that out into the community a little bit more. So, thoughtbot is very well known in the Rails space for all of the open-source content we've put out and blog posts, and courses, and books. I mean, there's just so much on the Rails side that thoughtbot has done. And we're just a little bit less mature on the React Native side in terms of what we've put out there. So, that's kind of the second goal is giving back, helping others kind of do that same thing. I feel like we have developed our practices internally, and we're building some great apps. And it's kind of time to contribute back a little bit more. +WILL: Awesome. I'm looking forward to reaching those goals. If you can go back and give yourself advice, what would you tell yourself? +STEPHEN: I would maybe say, read the documentation [laughs]. I don't know when I got into mobile; I think I just jumped in. And, you know, we've talked about some of the mobile-specific domain, and not knowing what you don't know, and app review guidelines. I feel like early on, I just responded to challenges as they came up, as opposed to just digging into, you know, Apple's documentation and Android's documentation and just really understanding the underlying operating systems in stores. That's probably a piece of advice. +If I could go back, I would just start at the documentation, you know, go to developer.apple.com and read about all of the underlying APIs of StoreKit and, you know, associated domains and all of these sorts of things. Just learn 'em, and then you know 'em. [laughs]. +So, maybe that could have saved me some heartache if I just was a little more intentional about, okay, I'm getting into app development. I'm going to set aside some time and just really learn this stuff, as opposed to kind of where I had one foot in the door, one foot out of the door for a while. And I think that kept me from just sitting down and really going deep. +WILL: That's really good advice. Just read the documentation. And that's not just Apple. +STEPHEN: [laughs] +WILL: That's a lot of departments, sections of my life. So, yes, I like that. +[laughter] +STEPHEN: I actually...that's something I did early in my career. So, I started as an Enterprise Java developer in 2011, and I was using the Spring framework. I downloaded the entire PDF. It was, like, 250 pages, the documentation [laughs]. And I remember just being on, like, airplane flights, and I just read the documentation, just cover to cover. That served me so well. I was, like, the expert, you know [laughs]. I don't always do it, but when I do, I'm like, oh yeah, why didn't I do that sooner? [laughs] +WILL: Yeah, totally agree. I like that. What is the wind in your sails? What motivates Stephen? +STEPHEN: Like, I think what attracted me to software development is just being able to build stuff, you know, probably the same thing that attracted me to woodworking. So, I think what motivates me is that prospect of, hey, I'm building an app that people are going to use, and it's going to make their life better. So, that's really what gets me up and gets me motivated. It's less so the actual coding, to be honest. It's really the prospect of, like, hey, I'm building something. +WILL: Awesome. Yeah. Is there anything that you would like to promote? +STEPHEN: If you're interested in building a mobile app, come talk to us. We'd love to build your mobile app. Go to thoughtbot.com/hire-us; I believe hire-us. We would love to talk to you about your mobile project. So, don't hesitate to reach out. We'd love to hear about what you're interested in building. +WILL: Awesome. Well, Stephen, it was great to chat with you. It's always great to chat with you about mobile development and just personal life things. So, I really appreciate you being on the podcast today. +STEPHEN: Thanks for having me, Will. It was a lot of fun. Always good talking with you. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Stephen Hanson. + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP.

+ +

Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox!

+ +

__

+ +

Co-host Will Larry interviews Stephen Hanson, the Director of Mobile Development at thoughtbot. The two explore the complexities of mobile app development, focusing on the advantages and disadvantages of React Native and Flutter.

+ +

Stephen, who initially started as a full-stack web developer specializing in Enterprise Java, discusses React Native's cost-effectiveness and the convenience of having a unified codebase for iOS and Android platforms. However, he notes that Flutter might be a more suitable choice for high-performance needs. Both hosts emphasize the nuances of the mobile ecosystem, covering topics like in-app purchases, push notifications, and the strict guidelines set by app stores like Apple's. They agree that a comprehensive understanding of these aspects is crucial for an entire development team, including designers and project managers.

+ +

Additionally, Stephen shares that the driving force behind his career is the opportunity to create apps that enhance people's lives. Stephen wraps up the discussion by detailing thoughtbot's goals of improving mobile development practices within the company and the broader developer community.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Stephen Hanson, Director of Mobile Development here at thoughtbot. Stephen, thank you for joining me.

+ +

STEPHEN: Hi, Will. Thanks for having me. I'm excited to be here.

+ +

WILL: Yeah. I'm excited to talk about mobile development. But before we get started, tell us a little bit about who Stephen Hanson is: your personal life.

+ +

STEPHEN: You know this because we often talk about our families when we get together. But I have two young kids, two and four years old. When you say personal life to anybody who has young kids, that's what we're talking about.

+ +

[laughter]

+ +

WILL: Yes.

+ +

STEPHEN: So, they're keeping me busy but in the best way.

+ +

WILL: Yeah, definitely. And I totally understand that. So, I know we talk about this often, but you like to woodwork. You like to work with your hands like most of us in tech. Like, we think so much with our head and mental that we try to find something to do physically, and yours is woodworking. Tell me a little bit about that.

+ +

STEPHEN: Yeah. I think it's exactly what you said. I think working on a computer all day, you know, many years ago, I was like, what's something I can do with my hands, right? Something a little more physical. So yeah, fine woodworking has been a hobby of mine for quite a few years. And we were even chatting the other day about, you know, I'm trying to take time during the day to sneak out to the garage for 15 minutes, you know, during my lunch break or whatever to just get that mental reset and just work on something.

+ +

WILL: Yeah. I know that you built your office that you work out of. I've been wanting to ask you, one, how did you do it? Two, how did you have the confidence to do it [laughter] to make sure that it was going to...how can I say this? I would be afraid that would it still be standing [laughter] after a little bit? [laughs]

+ +

STEPHEN: Yeah, to be honest, that was definitely a fear. Yeah, I built my office in 2020, you know, COVID hit. All of a sudden, I was working fully remote. And we had another kid on the way. You know, we didn't have space in the house. So, I was like, what am I going to do? [laughs] I was already doing woodworking, but I didn't have any construction or carpentry experience.

+ +

So, yeah, I definitely had the confidence issue. And I think, you know, I was just like, I don't know, let's just give it a try. [laughter] That's really all I can say. I didn't have the skills yet. But I watched a lot of YouTube and read a lot of [laughs] forums or, you know, just found info wherever I could, so...[laughs]

+ +

WILL: Yep. And it's still standing today, correct? [laughs]

+ +

STEPHEN: Correct. Yeah. [laughs] No, I'm just sitting in, like, a pile of rubble right now.

+ +

[laughter]

+ +

WILL: That's awesome, yeah. It's kind of like development sometimes for me. Like, you just got to take that leap sometimes, so...

+ +

STEPHEN: You do, right? It's like, you know, fake it till you make it.

+ +

[laughter]

+ +

WILL: Yep. That's awesome. Awesome. Awesome. So, tell us a little bit about how did you get started in development in general? And then, how did you get started in React Native?

+ +

STEPHEN: Yeah. So, I started out as a full-stack web developer. So, I didn't initially set out and say, "I'm going to build mobile apps," right? And I started out in 2011. I was working in Enterprise Java. I worked for American Airlines for a couple of years, and then I did enterprise consulting. I eventually made my way to, like, Rails and front-end development. And around 2016, 2017, I was freelancing. And eventually, clients started asking me to build mobile apps. [chuckles]

+ +

WILL: [inaudible 04:16]

+ +

STEPHEN: And I didn't know how to build mobile apps. So, I did what any web developer would do who doesn't build apps, and I used web technology. So, those first couple of apps that I built were hybrid apps. I used Ionic. And those are, you know, web apps that you package in a Native Wrapper. So, developing these apps, I literally developed them in a browser, right? And they're web apps. [laughs] And that was my first experience building apps.

+ +

Even if they were web-based, I still had to work with the native app stores and learn, you know, app review guidelines and implement some native functionality, even though it was through, like, the Ionic wrappers. You know, people kind of trash on hybrid apps, and sometimes for good reason. But that wasn't a bad first experience for me or outcome, honestly. The clients were happy. They had apps in the app stores that were working for a pretty reasonable development cost. So yeah, that was my first experience in mobile. The end result isn't something I'd be necessarily proud of today. [laughs]

+ +

WILL: I think that's all devs. [laughs]

+ +

STEPHEN: Yeah, you know, [laughter] yeah, I --

+ +

WILL: Looking back at their work, yeah. [laughs]

+ +

STEPHEN: I was talking about that. I could look back to something I built a month ago. [laughs]

+ +

WILL: Yes.

+ +

[laughter]

+ +

STEPHEN: You don't have to go back far.

+ +

[laughter]

+ +

WILL: Yeah, so true [laughs]. You started working with the client when you were freelancing. So, how did you go from the hybrid web apps to actually saying, okay, I want to change, and I want to go all in on React Native?

+ +

STEPHEN: React Native came out around that same time I was building those hybrid apps. So, the hybrid apps were 2016, 2017. React Native came out in 2015. So it was out, but it was still pretty new. And I was really interested in React Native right from the beginning, but I was also a little intimidated by it [chuckles].

+ +

So, when those first clients came to me for mobile apps, I didn't feel confident enough to say, "Yes, I can build you a React Native app." But a year or two later, I was working for another client on their Rails app. And I was building an API for their new React Native app. You know, I was really interested in React Native. So I said, "Hey, [chuckles] why don't I help out on the app side, too?" And they were like, "Sure, that sounds great." So that was kind of where I got my foot in the door with React Native.

+ +

And then more opportunities like that just kept popping up over the next year. So, I got to work on a couple of other React Native apps. And like we talked about, I just started calling myself a React Native developer [laughs]. The rest is history.

+ +

WILL: Yep. So true. We'll touch more on that later. But what would you say to a client who is trying to figure out if they should build native versus React Native?

+ +

STEPHEN: There's a few things to consider when making that decision. But I think, usually, what I've seen is it comes down to budget and user experience. The bottom line is React Native is going to be a lot cheaper. You're basically building one app instead of two, right? Most of your code in a React Native app is going to be in JavaScript, and you can reuse all of that code across Android and iOS.

+ +

If you're building a native app, you're just building two completely separate apps. So, it's just going to be cheaper to build that React Native app, and a lot of times, that's what it comes down to. For most companies, it can be really hard to justify that extra cost of building a completely native app for each platform.

+ +

But then the question is when we talk about how can you justify the cost? Well, what would justify the cost, right? [laughs] I think probably the biggest trade-off when you build a React Native app versus a purely native app is there is a little bit of a performance penalty by building in React Native versus native.

+ +

So, I think apps that will need to have a very flashy cutting-edge experience with lots of user-driven animation and effects, you know, when you get into that domain, I think that's where we see pure native starting to make more sense. But most apps and users would never feel that performance penalty of React Native. So, for most apps, that's not really something that enters into the equation.

+ +

WILL: I want to dig into something you said. You were talking about if you do go native, you usually have to build an iOS and an Android separately. But with React Native, you could do it together. So, for someone who's maybe never done either one of them, can you kind of dig into, like, what does that look like? So, when you say I have to build an iOS and an Android portion versus I can do one codebase for React Native, can you walk us through kind of what that looks like, just a sample feature?

+ +

STEPHEN: When I say React Native is a single codebase and, you know, native apps, you're building two apps, the way React Native works is you're basically building a React app. So, all of your business logic is going to be in React. And when your React code renders some UI, that gets translated into native UI. But your business logic is still going to be living in that JavaScript React app. So, one, when I say performance penalty, that's what I'm talking about is: there's a little bit of a performance penalty communicating back and forth between your JavaScript thread and the native system thread.

+ +

But when we talk about one codebase versus two, that's what a React Native app looks like. You basically are working on a React app. It's one codebase with one set of business logic. And when you say, "Show a modal on the screen," that gets translated into a native Android modal or a native iOS modal, but in your code, you're just saying, "Show a modal." [laughs] So, you're just writing that one time. So yeah, a React Native project is just one codebase.

+ +

Now, one thing that we haven't really touched on is in a React Native app, you do have the ability to drop down into native code. So, you have access to the native Android project and the native iOS project in your React Native app. So, you can write completely native code if you want to.

+ +

But the appeal of React Native is you don't have to, you know, unless you get into one of those situations where you need to do something native that isn't supported out of the box with React Native or by an existing third-party library, or you want to have a very performant, very interactive part of your app. Maybe there's a reason you want to do that in native. You know, you do have that option in a React Native app of dropping down into that native code level.

+ +

But to contrast that with a purely native project, you will have two completely separate codebases, one for Android and one for iOS. You'll have a development team for Android and a development team for iOS, you know, typically with different skill sets. The Android project will be Java, Kotlin. And your iOS project is swift. So, just in every sense, you really have two different projects when you're working on a purely native app.

+ +

WILL: Okay, yeah, that makes sense. So like, for React Native, that show modal is just however many lines to show that one modal, and it does it for iOS and Android. But when you talk about native, you're saying that; however, iOS says to show that modal, you have to do it that way. But then Android, you also have to do it the Android way. And one developer, unless they know both of them, may not be able to handle both for those cases, correct?

+ +

STEPHEN: Yeah, exactly. React Native abstracts away those underlying platforms. So, you really just need to know React Native for most cases. Though, there's definitely a benefit of knowing the underlying platforms.

+ +

WILL: Definitely. Especially, like you touched on if you wanted to go into that native portion to add in a feature. You know, for example, I know we both worked on a project where we had a scanning app. And we had to tap into that native portion and React Native in order to get the scanning app to work, correct?

+ +

STEPHEN: Yeah, that's right. We had to support some barcode scanning devices and hook into those barcode scanning frameworks that were proprietary [chuckles] to those devices. So yeah, we had to build native modules for Android and iOS to support those.

+ +

WILL: Gotcha. Okay. I want to touch back on something you said earlier about the flashy experiences. You said sometimes you may not see it or whatever, but sometimes, if you want that flashy experience, it's better to go the native route. Can you explain that a little bit more?

+ +

STEPHEN: So yeah, it's kind of what I was touching on a second ago. You know, in a React Native app, you have the JavaScript thread that is always running and coordinating UI changes with business logic. So, you've got your business logic in JavaScript. You've got the UI in native. And those need to be coordinated to interact. So, that's kind of where that performance penalty can happen.

+ +

You know, again, most apps and users would never feel this penalty. I've never been, like, using my phone and been like, oh, this is a React Native app; I can feel it, you know. [laughs] It's not something that typically enters the picture for most apps that we work on. But there are certain types of apps that might be more important, you know, highly interactive games or things that just need to have that extra flashiness and interactive flashiness specifically, where it could make sense to build that natively.

+ +

Another interesting thing in the React Native space is React Native recently re-architected their rendering engine to be written in C++ and be more efficient. So, this performance overhead might be a little bit less of a trade-off. They've re-architected the way that React Native JavaScript talks to the native layer, which might make this even less of an issue going forward.

+ +

WILL: I looked it up for the podcast. But do you know some of the companies that we probably are familiar with, like they built apps on React Native? Can you name a couple?

+ +

STEPHEN: Yeah, I was recently looking at this, too. And, you know, the big one is Facebook, right? Facebook built React Native. So, they're the sponsor of that project. So, Facebook and Facebook Messenger, I believe those apps are built with React Native. I don't know if the entire apps are or not [chuckles]. Do you know by chance? [laughs]

+ +

WILL: React Native on their website says, "Hey, we're going to showcase these apps that they're built in React Native." So, I'm guessing a huge portion of it was built in React Native, so...

+ +

STEPHEN: Yeah. That's a good point. Yeah, you're right. They're showcasing it there. So yeah, you know, other ones, you know, lots of brands, Shopify, looks like PlayStation. I'm looking at the list now on the React Native website: Pinterest, Flipkart, Discord, Walmart, Tesla, Coinbase, Mercari. Yeah, I mean, it's just a lot of big-name apps built in React Native, including quite a few that we've [laughs] that we've built.

+ +

[laughter]

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

WILL: If I'm absolutely sold on getting that flashy experience, is native the only route to go?

+ +

STEPHEN: I think until pretty recently, that would have been your option [laughs]. But Flutter has been picking up a little bit of momentum. So, Flutter is developed by Google. And it's kind of a challenger in that React Native space. It kind of has the same write once, run anywhere, you know, philosophy as React Native. You have one codebase. But they tout kind of being a more performant option than React Native. So, it compiles down to native ARM or Intel code, which can give better performance without, you know, not needing that JavaScript bridge kind of handling that communication between the UI and the business logic.

+ +

WILL: So, when would you use Flutter versus React Native?

+ +

STEPHEN: I kind of keep going back to, like, you know, we talk about the performance overhead of a React Native app. I don't think that's even on the map for the vast majority of apps. Like, this isn't a performance penalty that you can typically feel.

+ +

So, looking at Flutter versus React Native, React Native has several advantages. I think the biggest one is it's React. So, every team has React developers already on the team, pretty much nowadays. So, you know, if you've got an organization that says, "Oh, we need to build a mobile app," they probably already have a team of React developers somewhere working on their web app [laughs]. So, there's a big benefit of kind of centralizing their team around that technology. You know, you can have a little bit of cross-pollination between web and mobile, which can be really nice.

+ +

I think, similarly, it's a lot easier to find and hire React or React Native developers right now than it is to find and hire Flutter developers. So, Flutter is written in Dart, and it has its own front-end framework. So, this isn't necessarily a technology that you're going to have on your existing team. Like, I've never worked with Dart, personally. It's not nearly as common as React developers. You know, that, to me, is going to be a big downside. You know, the talent pool is a lot smaller for Flutter/Dart developers.

+ +

Also, the ecosystem with Flutter being newer, it's not as established. It doesn't have as large of an ecosystem as React Native. So, for those reasons, I think React Native is still, at least for us, like, it's usually where we would steer a client over Flutter, unless they're in that category of, like, they're really going for something, you know, groundbreaking. And, you know, the choice is either, you know, they've ruled out React Native. They need to get that native performance, and maybe they could achieve that with Flutter, and maybe Flutter would be a good option then.

+ +

WILL: Okay. You mentioned that—and I agree with you—like, you probably have some React devs on your team somewhere. Most companies does. So, say if I am bought in, I'm going all in on React Native, and I have React web developers on my team. Is that an easy transition for those developers, or what does that transition look like?

+ +

STEPHEN: Yeah, this is something...I think you and I have talked about this a lot because we both transitioned from React Web to React Native. And, you know, it wasn't all that easy, right? [laughs]

+ +

WILL: No, it was not [laughter] at all.

+ +

[laughter]

+ +

STEPHEN: So yeah, you know, it is a fallacy to say, "Hey, we've got a React team, you know, let's just start tomorrow on building an app, and it'll be smooth sailing. And, you know, no one needs to learn anything, and we'll be good to go," right? [laughs] So, you know, what I always say is a React web developer can successfully work on a React Native app. But I don't think they have the skills yet to lead that initiative because there's just so much to the mobile ecosystem that needs to be learned.

+ +

And really, you know, my first couple of React Native apps, I wasn't the lead developer. There was somebody on those projects who really knew that space better than I did. And that was really helpful for me to have. How about you? What about your first, like, React Native project? What did that look like?

+ +

WILL: It was at another company, and the exact words paraphrasing was, "You know React, so you can easily work on React Native." And so, I got on the project. And I really struggled, to be honest with you, because there's a lot of things that I didn't know: in-app purchases, push notifications, how to deal with Apple store, Android store, deploying to those stores. Like all of those things, navigation is totally different than React navigations and routes. It was a lot. It was a lot more than they led on to what it was.

+ +

Eventually, I caught on. It took me a while. I needed to work with some more senior React Native developers, and I was able to really pick it up. But yeah, it was tough. I'll be honest: I struggled for a while because I went in feeling like I should have known all those things because that's the way it was conveyed to me. Now that I look back on it I was like, there's no way I could have known those things. It's just a different language. So, I had to get in there and learn it.

+ +

And I even...I'm trying to think I've learned a couple of new languages. But it's almost like learning a new language just with, you know, the, like I mentioned, the in-app purchases, push notifications. It's just totally different.

+ +

STEPHEN: Yeah, that's been my experience also. I think the challenges weren't, like, coding [laughs] because, you know, building a React Native app is coding in React. The challenges that I faced were, like you said, it's just the mobile ecosystem and learning all the intricacies, the functionality that users have come to expect in mobile apps, you know, like password manager, integration, and background execution modes, and deep linking strategies, all that kind of stuff.

+ +

You know, if you don't know what questions to ask or what features to be thinking of, it's just really hard. And [laughs] I think it's more than just the developer needing to know that too. I think anytime it comes, you know, down to building an app, the whole team needs to have that mobile background. It's just a completely different platform than building for the web, right? So like, product owners, project managers, designers, developers all need that context so we can be prioritizing the right features and building a UI that matches the patterns that people have come to expect in a mobile app. And then, of course, developing those apps using the, you know, the proper native modules.

+ +

WILL: Yeah, definitely. And I [chuckles]...you mentioned that it's mostly on, like, the mobile side. I don't know the best way to say that. But, like, I can tell you, when I first got onto the React Native project, there were numerous features that I could implement, and to a certain point to where I had to go that mobile.

+ +

So, like, I was like, oh yeah, I can learn these new components that's in React Native. Okay, I got it to work. It's finished. You know, my PM would be like, "Well, it's not completely finished because you have to deploy it." And I was like, oh, I have no idea what I'm doing now. Like, I just know [laughs]...I know up to this point.

+ +

STEPHEN: [laughs]

+ +

WILL: But anything over that, I'm like, yeah, I have no idea.

+ +

STEPHEN: Especially with consulting, right? With consulting, you need even more expertise, right? The clients are counting on you to build their app. And that's where, you know, having that deep, deep familiarity where you can say to a client, "This is how we're going to do the deployment process, you know, and I need, you know, X, Y, and Z to help set it up. And here are the deliverables, and here's when we'll have it," that kind of thing. Like, it really takes it up a whole nother notch what you need to know.

+ +

WILL: Definitely, yeah. Because I think compared to mobile, I feel like web development can almost be like the Wild Wild West. And what I mean by that is, like, there's no rules for you to push out a website in web. Like, you know, you build it. You push it out. It can be out there, you know. Whoever is hosting it, unless you go against their rules, maybe, but their rules are very relaxed and stuff like that.

+ +

Mobile, there's a totally different set of rules. Because, like, I was laughing not too long ago. There was rumors that Elon Musk was going to remove the blocking feature on Twitter [chuckles]. And it was funny because all the mobile devs they came out. And if you're a mobile dev, you know this. Apple is very strict.

+ +

STEPHEN: [laughs]

+ +

WILL: If this is a social media app that you're building, you have to have that blocking feature, which I agree it needs to be there. But it's funny, like, all the mobile devs was like, yeah, that's not going to work. Good luck [chuckles]. Good luck being an app again.

+ +

STEPHEN: Yeah, [laughs] good luck.

+ +

WILL: Like, they're going to kick it off. And yeah, they're very big on kicking it off if it doesn't follow those rules and things like that. So yeah, for React Native, you have to learn those rules, or, like I said, they won't approve it. They won't push it out to their store.

+ +

STEPHEN: Yep, exactly. Yeah. I feel like the new one at every client project; I have to say, "We have to offer a way to delete your account in the app," because [laughs] that's a new one that launched last year, and I think has just started being enforced more recently. Like, all those little gotcha rules, you know, like, if you don't know about that, then you're going to go to submit your app to the stores, and you're going to get rejected every single time. [laughs].

+ +

WILL: And they're not shy about rejecting you [laughs].

+ +

STEPHEN: Yeah. But I would say, like, a lot of the rules, I'm like, yes, this is amazing that we have these rules, you know. It does help keep the community safer like things like blocking. But then there's the other rules of, like, Apple's like, hey, you've got to use our payment system and pay us 30% of every sale.

+ +

WILL: Yes [laughs].

+ +

STEPHEN: I was, like, you know, there's some evil stuff happening there, too.

+ +

WILL: I totally agree. And we ran into that issue. We had an app that used Stripe. And we actually had to remove it in order to use in-app purchases because...I forgot the rules around it, but it was essentially for digital content. I think it's what it was. And so, we had to use Apple's in-app purchases. So yeah, I totally agree with you on that.

+ +

STEPHEN: Yeah. I feel like I've been a part of so many apps where we're, like, reading those rules. And we're like, okay, you know, it's like, we're watching a live stream of birds.

+ +

WILL: [laughs]

+ +

STEPHEN: You know, like, the birds aren't digital [laughter], you know. It's like, [laughs] where does this fall in the rule? [laughs]

+ +

WILL: Yes [laughs]. I've done that, too [laughter]. Yep. It's almost like, you know, I feel like lawyers, okay, like, is this what this rule is, or the law what is written, or does this fall underneath that? So yeah, totally, totally agree.

+ +

STEPHEN: Yep [laughs].

+ +

WILL: So, you've been here a couple of years at thoughtbot. What has been your experience building React Natives here for clients at thoughtbot?

+ +

STEPHEN: Yeah, yeah. I've been at thoughtbot for about five years now. And I have been building React Native apps that whole time. And, I mean, I started at thoughtbot a little more in the full-stack space, web development, and have transitioned to where I'm mostly only building React Native mobile apps now.

+ +

It's been a great experience. I think that React Native is really a sweet spot of; we're able to build these apps really efficiently and much less expensively than when we're doing pure native. And the end product is a really good app. So, it's been a great experience, you know, React Native is really...it has a really nice development experience. You know, it's the JavaScript React ecosystem. And we use TypeScript, and we have a really good developer experience with it. And then we're building apps that clients are really happy with and with a good budget.

+ +

So, I think it's kind of that, you know, like, win-win-win kind of scenario where everybody is happy. And yeah, I don't see it going anywhere. And I think we're going to be building React Native apps for quite a while to come.

+ +

WILL: Yeah, I totally agree with that. Where do you see React Native and mobile dev going here at thoughtbot in the next six months or even the next year? What are your goals for the mobile team?

+ +

STEPHEN: We've got a couple of goals. One of them is around kind of what we've talked about with the mobile space in general. This isn't really specific to React Native, but it can be. But, consulting in the mobile space is challenging because there's a lot of mobile-specific domain knowledge that a team really needs to have.

+ +

So, that's something that we've started looking into is, like, how do we build up our resources internally and then, hopefully, externally as well to help guide us on our projects and ensure that we have, like, you know, we are developing apps consistently and efficiently every time? So, that's something we're looking into is, like resources to help our teams—not just developers, but project managers, designers, and developers—help us navigate the mobile space.

+ +

Okay, you're going to do push notifications. Here's the library we use. Here's things to think about, and interactions to think about, and iOS-specific functionality that we could support, and Android-specific functionality that we can support. You know, you're going to do deep linking; do you want to use universal links, or do you want to use a different strategy, a scheme-based link? So, basically, building up that set of resources so that our teams are all able to consult and build efficiently and consistently across the board. So, that's kind of goal number one.

+ +

And then, goal number two is to kind of bring some of that out into the community a little bit more. So, thoughtbot is very well known in the Rails space for all of the open-source content we've put out and blog posts, and courses, and books. I mean, there's just so much on the Rails side that thoughtbot has done. And we're just a little bit less mature on the React Native side in terms of what we've put out there. So, that's kind of the second goal is giving back, helping others kind of do that same thing. I feel like we have developed our practices internally, and we're building some great apps. And it's kind of time to contribute back a little bit more.

+ +

WILL: Awesome. I'm looking forward to reaching those goals. If you can go back and give yourself advice, what would you tell yourself?

+ +

STEPHEN: I would maybe say, read the documentation [laughs]. I don't know when I got into mobile; I think I just jumped in. And, you know, we've talked about some of the mobile-specific domain, and not knowing what you don't know, and app review guidelines. I feel like early on, I just responded to challenges as they came up, as opposed to just digging into, you know, Apple's documentation and Android's documentation and just really understanding the underlying operating systems in stores. That's probably a piece of advice.

+ +

If I could go back, I would just start at the documentation, you know, go to developer.apple.com and read about all of the underlying APIs of StoreKit and, you know, associated domains and all of these sorts of things. Just learn 'em, and then you know 'em. [laughs].

+ +

So, maybe that could have saved me some heartache if I just was a little more intentional about, okay, I'm getting into app development. I'm going to set aside some time and just really learn this stuff, as opposed to kind of where I had one foot in the door, one foot out of the door for a while. And I think that kept me from just sitting down and really going deep.

+ +

WILL: That's really good advice. Just read the documentation. And that's not just Apple.

+ +

STEPHEN: [laughs]

+ +

WILL: That's a lot of departments, sections of my life. So, yes, I like that.

+ +

[laughter]

+ +

STEPHEN: I actually...that's something I did early in my career. So, I started as an Enterprise Java developer in 2011, and I was using the Spring framework. I downloaded the entire PDF. It was, like, 250 pages, the documentation [laughs]. And I remember just being on, like, airplane flights, and I just read the documentation, just cover to cover. That served me so well. I was, like, the expert, you know [laughs]. I don't always do it, but when I do, I'm like, oh yeah, why didn't I do that sooner? [laughs]

+ +

WILL: Yeah, totally agree. I like that. What is the wind in your sails? What motivates Stephen?

+ +

STEPHEN: Like, I think what attracted me to software development is just being able to build stuff, you know, probably the same thing that attracted me to woodworking. So, I think what motivates me is that prospect of, hey, I'm building an app that people are going to use, and it's going to make their life better. So, that's really what gets me up and gets me motivated. It's less so the actual coding, to be honest. It's really the prospect of, like, hey, I'm building something.

+ +

WILL: Awesome. Yeah. Is there anything that you would like to promote?

+ +

STEPHEN: If you're interested in building a mobile app, come talk to us. We'd love to build your mobile app. Go to thoughtbot.com/hire-us; I believe hire-us. We would love to talk to you about your mobile project. So, don't hesitate to reach out. We'd love to hear about what you're interested in building.

+ +

WILL: Awesome. Well, Stephen, it was great to chat with you. It's always great to chat with you about mobile development and just personal life things. So, I really appreciate you being on the podcast today.

+ +

STEPHEN: Thanks for having me, Will. It was a lot of fun. Always good talking with you.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Stephen Hanson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + We are thrilled to announce the third session of our new Incubator Program. If you have a business idea that involves a web or mobile app, we encourage you to apply to our eight-week program. We'll help you validate your market opportunity, experiment with messaging and product ideas, and move forward with confidence toward an MVP.

+ +

Learn more and apply at tbot.io/incubator. We look forward to seeing your application in our inbox!

+ +

__

+ +

Co-host Will Larry interviews Stephen Hanson, the Director of Mobile Development at thoughtbot. The two explore the complexities of mobile app development, focusing on the advantages and disadvantages of React Native and Flutter.

+ +

Stephen, who initially started as a full-stack web developer specializing in Enterprise Java, discusses React Native's cost-effectiveness and the convenience of having a unified codebase for iOS and Android platforms. However, he notes that Flutter might be a more suitable choice for high-performance needs. Both hosts emphasize the nuances of the mobile ecosystem, covering topics like in-app purchases, push notifications, and the strict guidelines set by app stores like Apple's. They agree that a comprehensive understanding of these aspects is crucial for an entire development team, including designers and project managers.

+ +

Additionally, Stephen shares that the driving force behind his career is the opportunity to create apps that enhance people's lives. Stephen wraps up the discussion by detailing thoughtbot's goals of improving mobile development practices within the company and the broader developer community.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Stephen Hanson, Director of Mobile Development here at thoughtbot. Stephen, thank you for joining me.

+ +

STEPHEN: Hi, Will. Thanks for having me. I'm excited to be here.

+ +

WILL: Yeah. I'm excited to talk about mobile development. But before we get started, tell us a little bit about who Stephen Hanson is: your personal life.

+ +

STEPHEN: You know this because we often talk about our families when we get together. But I have two young kids, two and four years old. When you say personal life to anybody who has young kids, that's what we're talking about.

+ +

[laughter]

+ +

WILL: Yes.

+ +

STEPHEN: So, they're keeping me busy but in the best way.

+ +

WILL: Yeah, definitely. And I totally understand that. So, I know we talk about this often, but you like to woodwork. You like to work with your hands like most of us in tech. Like, we think so much with our head and mental that we try to find something to do physically, and yours is woodworking. Tell me a little bit about that.

+ +

STEPHEN: Yeah. I think it's exactly what you said. I think working on a computer all day, you know, many years ago, I was like, what's something I can do with my hands, right? Something a little more physical. So yeah, fine woodworking has been a hobby of mine for quite a few years. And we were even chatting the other day about, you know, I'm trying to take time during the day to sneak out to the garage for 15 minutes, you know, during my lunch break or whatever to just get that mental reset and just work on something.

+ +

WILL: Yeah. I know that you built your office that you work out of. I've been wanting to ask you, one, how did you do it? Two, how did you have the confidence to do it [laughter] to make sure that it was going to...how can I say this? I would be afraid that would it still be standing [laughter] after a little bit? [laughs]

+ +

STEPHEN: Yeah, to be honest, that was definitely a fear. Yeah, I built my office in 2020, you know, COVID hit. All of a sudden, I was working fully remote. And we had another kid on the way. You know, we didn't have space in the house. So, I was like, what am I going to do? [laughs] I was already doing woodworking, but I didn't have any construction or carpentry experience.

+ +

So, yeah, I definitely had the confidence issue. And I think, you know, I was just like, I don't know, let's just give it a try. [laughter] That's really all I can say. I didn't have the skills yet. But I watched a lot of YouTube and read a lot of [laughs] forums or, you know, just found info wherever I could, so...[laughs]

+ +

WILL: Yep. And it's still standing today, correct? [laughs]

+ +

STEPHEN: Correct. Yeah. [laughs] No, I'm just sitting in, like, a pile of rubble right now.

+ +

[laughter]

+ +

WILL: That's awesome, yeah. It's kind of like development sometimes for me. Like, you just got to take that leap sometimes, so...

+ +

STEPHEN: You do, right? It's like, you know, fake it till you make it.

+ +

[laughter]

+ +

WILL: Yep. That's awesome. Awesome. Awesome. So, tell us a little bit about how did you get started in development in general? And then, how did you get started in React Native?

+ +

STEPHEN: Yeah. So, I started out as a full-stack web developer. So, I didn't initially set out and say, "I'm going to build mobile apps," right? And I started out in 2011. I was working in Enterprise Java. I worked for American Airlines for a couple of years, and then I did enterprise consulting. I eventually made my way to, like, Rails and front-end development. And around 2016, 2017, I was freelancing. And eventually, clients started asking me to build mobile apps. [chuckles]

+ +

WILL: [inaudible 04:16]

+ +

STEPHEN: And I didn't know how to build mobile apps. So, I did what any web developer would do who doesn't build apps, and I used web technology. So, those first couple of apps that I built were hybrid apps. I used Ionic. And those are, you know, web apps that you package in a Native Wrapper. So, developing these apps, I literally developed them in a browser, right? And they're web apps. [laughs] And that was my first experience building apps.

+ +

Even if they were web-based, I still had to work with the native app stores and learn, you know, app review guidelines and implement some native functionality, even though it was through, like, the Ionic wrappers. You know, people kind of trash on hybrid apps, and sometimes for good reason. But that wasn't a bad first experience for me or outcome, honestly. The clients were happy. They had apps in the app stores that were working for a pretty reasonable development cost. So yeah, that was my first experience in mobile. The end result isn't something I'd be necessarily proud of today. [laughs]

+ +

WILL: I think that's all devs. [laughs]

+ +

STEPHEN: Yeah, you know, [laughter] yeah, I --

+ +

WILL: Looking back at their work, yeah. [laughs]

+ +

STEPHEN: I was talking about that. I could look back to something I built a month ago. [laughs]

+ +

WILL: Yes.

+ +

[laughter]

+ +

STEPHEN: You don't have to go back far.

+ +

[laughter]

+ +

WILL: Yeah, so true [laughs]. You started working with the client when you were freelancing. So, how did you go from the hybrid web apps to actually saying, okay, I want to change, and I want to go all in on React Native?

+ +

STEPHEN: React Native came out around that same time I was building those hybrid apps. So, the hybrid apps were 2016, 2017. React Native came out in 2015. So it was out, but it was still pretty new. And I was really interested in React Native right from the beginning, but I was also a little intimidated by it [chuckles].

+ +

So, when those first clients came to me for mobile apps, I didn't feel confident enough to say, "Yes, I can build you a React Native app." But a year or two later, I was working for another client on their Rails app. And I was building an API for their new React Native app. You know, I was really interested in React Native. So I said, "Hey, [chuckles] why don't I help out on the app side, too?" And they were like, "Sure, that sounds great." So that was kind of where I got my foot in the door with React Native.

+ +

And then more opportunities like that just kept popping up over the next year. So, I got to work on a couple of other React Native apps. And like we talked about, I just started calling myself a React Native developer [laughs]. The rest is history.

+ +

WILL: Yep. So true. We'll touch more on that later. But what would you say to a client who is trying to figure out if they should build native versus React Native?

+ +

STEPHEN: There's a few things to consider when making that decision. But I think, usually, what I've seen is it comes down to budget and user experience. The bottom line is React Native is going to be a lot cheaper. You're basically building one app instead of two, right? Most of your code in a React Native app is going to be in JavaScript, and you can reuse all of that code across Android and iOS.

+ +

If you're building a native app, you're just building two completely separate apps. So, it's just going to be cheaper to build that React Native app, and a lot of times, that's what it comes down to. For most companies, it can be really hard to justify that extra cost of building a completely native app for each platform.

+ +

But then the question is when we talk about how can you justify the cost? Well, what would justify the cost, right? [laughs] I think probably the biggest trade-off when you build a React Native app versus a purely native app is there is a little bit of a performance penalty by building in React Native versus native.

+ +

So, I think apps that will need to have a very flashy cutting-edge experience with lots of user-driven animation and effects, you know, when you get into that domain, I think that's where we see pure native starting to make more sense. But most apps and users would never feel that performance penalty of React Native. So, for most apps, that's not really something that enters into the equation.

+ +

WILL: I want to dig into something you said. You were talking about if you do go native, you usually have to build an iOS and an Android separately. But with React Native, you could do it together. So, for someone who's maybe never done either one of them, can you kind of dig into, like, what does that look like? So, when you say I have to build an iOS and an Android portion versus I can do one codebase for React Native, can you walk us through kind of what that looks like, just a sample feature?

+ +

STEPHEN: When I say React Native is a single codebase and, you know, native apps, you're building two apps, the way React Native works is you're basically building a React app. So, all of your business logic is going to be in React. And when your React code renders some UI, that gets translated into native UI. But your business logic is still going to be living in that JavaScript React app. So, one, when I say performance penalty, that's what I'm talking about is: there's a little bit of a performance penalty communicating back and forth between your JavaScript thread and the native system thread.

+ +

But when we talk about one codebase versus two, that's what a React Native app looks like. You basically are working on a React app. It's one codebase with one set of business logic. And when you say, "Show a modal on the screen," that gets translated into a native Android modal or a native iOS modal, but in your code, you're just saying, "Show a modal." [laughs] So, you're just writing that one time. So yeah, a React Native project is just one codebase.

+ +

Now, one thing that we haven't really touched on is in a React Native app, you do have the ability to drop down into native code. So, you have access to the native Android project and the native iOS project in your React Native app. So, you can write completely native code if you want to.

+ +

But the appeal of React Native is you don't have to, you know, unless you get into one of those situations where you need to do something native that isn't supported out of the box with React Native or by an existing third-party library, or you want to have a very performant, very interactive part of your app. Maybe there's a reason you want to do that in native. You know, you do have that option in a React Native app of dropping down into that native code level.

+ +

But to contrast that with a purely native project, you will have two completely separate codebases, one for Android and one for iOS. You'll have a development team for Android and a development team for iOS, you know, typically with different skill sets. The Android project will be Java, Kotlin. And your iOS project is swift. So, just in every sense, you really have two different projects when you're working on a purely native app.

+ +

WILL: Okay, yeah, that makes sense. So like, for React Native, that show modal is just however many lines to show that one modal, and it does it for iOS and Android. But when you talk about native, you're saying that; however, iOS says to show that modal, you have to do it that way. But then Android, you also have to do it the Android way. And one developer, unless they know both of them, may not be able to handle both for those cases, correct?

+ +

STEPHEN: Yeah, exactly. React Native abstracts away those underlying platforms. So, you really just need to know React Native for most cases. Though, there's definitely a benefit of knowing the underlying platforms.

+ +

WILL: Definitely. Especially, like you touched on if you wanted to go into that native portion to add in a feature. You know, for example, I know we both worked on a project where we had a scanning app. And we had to tap into that native portion and React Native in order to get the scanning app to work, correct?

+ +

STEPHEN: Yeah, that's right. We had to support some barcode scanning devices and hook into those barcode scanning frameworks that were proprietary [chuckles] to those devices. So yeah, we had to build native modules for Android and iOS to support those.

+ +

WILL: Gotcha. Okay. I want to touch back on something you said earlier about the flashy experiences. You said sometimes you may not see it or whatever, but sometimes, if you want that flashy experience, it's better to go the native route. Can you explain that a little bit more?

+ +

STEPHEN: So yeah, it's kind of what I was touching on a second ago. You know, in a React Native app, you have the JavaScript thread that is always running and coordinating UI changes with business logic. So, you've got your business logic in JavaScript. You've got the UI in native. And those need to be coordinated to interact. So, that's kind of where that performance penalty can happen.

+ +

You know, again, most apps and users would never feel this penalty. I've never been, like, using my phone and been like, oh, this is a React Native app; I can feel it, you know. [laughs] It's not something that typically enters the picture for most apps that we work on. But there are certain types of apps that might be more important, you know, highly interactive games or things that just need to have that extra flashiness and interactive flashiness specifically, where it could make sense to build that natively.

+ +

Another interesting thing in the React Native space is React Native recently re-architected their rendering engine to be written in C++ and be more efficient. So, this performance overhead might be a little bit less of a trade-off. They've re-architected the way that React Native JavaScript talks to the native layer, which might make this even less of an issue going forward.

+ +

WILL: I looked it up for the podcast. But do you know some of the companies that we probably are familiar with, like they built apps on React Native? Can you name a couple?

+ +

STEPHEN: Yeah, I was recently looking at this, too. And, you know, the big one is Facebook, right? Facebook built React Native. So, they're the sponsor of that project. So, Facebook and Facebook Messenger, I believe those apps are built with React Native. I don't know if the entire apps are or not [chuckles]. Do you know by chance? [laughs]

+ +

WILL: React Native on their website says, "Hey, we're going to showcase these apps that they're built in React Native." So, I'm guessing a huge portion of it was built in React Native, so...

+ +

STEPHEN: Yeah. That's a good point. Yeah, you're right. They're showcasing it there. So yeah, you know, other ones, you know, lots of brands, Shopify, looks like PlayStation. I'm looking at the list now on the React Native website: Pinterest, Flipkart, Discord, Walmart, Tesla, Coinbase, Mercari. Yeah, I mean, it's just a lot of big-name apps built in React Native, including quite a few that we've [laughs] that we've built.

+ +

[laughter]

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at tbot.io/entrepreneurs.

+ +

WILL: If I'm absolutely sold on getting that flashy experience, is native the only route to go?

+ +

STEPHEN: I think until pretty recently, that would have been your option [laughs]. But Flutter has been picking up a little bit of momentum. So, Flutter is developed by Google. And it's kind of a challenger in that React Native space. It kind of has the same write once, run anywhere, you know, philosophy as React Native. You have one codebase. But they tout kind of being a more performant option than React Native. So, it compiles down to native ARM or Intel code, which can give better performance without, you know, not needing that JavaScript bridge kind of handling that communication between the UI and the business logic.

+ +

WILL: So, when would you use Flutter versus React Native?

+ +

STEPHEN: I kind of keep going back to, like, you know, we talk about the performance overhead of a React Native app. I don't think that's even on the map for the vast majority of apps. Like, this isn't a performance penalty that you can typically feel.

+ +

So, looking at Flutter versus React Native, React Native has several advantages. I think the biggest one is it's React. So, every team has React developers already on the team, pretty much nowadays. So, you know, if you've got an organization that says, "Oh, we need to build a mobile app," they probably already have a team of React developers somewhere working on their web app [laughs]. So, there's a big benefit of kind of centralizing their team around that technology. You know, you can have a little bit of cross-pollination between web and mobile, which can be really nice.

+ +

I think, similarly, it's a lot easier to find and hire React or React Native developers right now than it is to find and hire Flutter developers. So, Flutter is written in Dart, and it has its own front-end framework. So, this isn't necessarily a technology that you're going to have on your existing team. Like, I've never worked with Dart, personally. It's not nearly as common as React developers. You know, that, to me, is going to be a big downside. You know, the talent pool is a lot smaller for Flutter/Dart developers.

+ +

Also, the ecosystem with Flutter being newer, it's not as established. It doesn't have as large of an ecosystem as React Native. So, for those reasons, I think React Native is still, at least for us, like, it's usually where we would steer a client over Flutter, unless they're in that category of, like, they're really going for something, you know, groundbreaking. And, you know, the choice is either, you know, they've ruled out React Native. They need to get that native performance, and maybe they could achieve that with Flutter, and maybe Flutter would be a good option then.

+ +

WILL: Okay. You mentioned that—and I agree with you—like, you probably have some React devs on your team somewhere. Most companies does. So, say if I am bought in, I'm going all in on React Native, and I have React web developers on my team. Is that an easy transition for those developers, or what does that transition look like?

+ +

STEPHEN: Yeah, this is something...I think you and I have talked about this a lot because we both transitioned from React Web to React Native. And, you know, it wasn't all that easy, right? [laughs]

+ +

WILL: No, it was not [laughter] at all.

+ +

[laughter]

+ +

STEPHEN: So yeah, you know, it is a fallacy to say, "Hey, we've got a React team, you know, let's just start tomorrow on building an app, and it'll be smooth sailing. And, you know, no one needs to learn anything, and we'll be good to go," right? [laughs] So, you know, what I always say is a React web developer can successfully work on a React Native app. But I don't think they have the skills yet to lead that initiative because there's just so much to the mobile ecosystem that needs to be learned.

+ +

And really, you know, my first couple of React Native apps, I wasn't the lead developer. There was somebody on those projects who really knew that space better than I did. And that was really helpful for me to have. How about you? What about your first, like, React Native project? What did that look like?

+ +

WILL: It was at another company, and the exact words paraphrasing was, "You know React, so you can easily work on React Native." And so, I got on the project. And I really struggled, to be honest with you, because there's a lot of things that I didn't know: in-app purchases, push notifications, how to deal with Apple store, Android store, deploying to those stores. Like all of those things, navigation is totally different than React navigations and routes. It was a lot. It was a lot more than they led on to what it was.

+ +

Eventually, I caught on. It took me a while. I needed to work with some more senior React Native developers, and I was able to really pick it up. But yeah, it was tough. I'll be honest: I struggled for a while because I went in feeling like I should have known all those things because that's the way it was conveyed to me. Now that I look back on it I was like, there's no way I could have known those things. It's just a different language. So, I had to get in there and learn it.

+ +

And I even...I'm trying to think I've learned a couple of new languages. But it's almost like learning a new language just with, you know, the, like I mentioned, the in-app purchases, push notifications. It's just totally different.

+ +

STEPHEN: Yeah, that's been my experience also. I think the challenges weren't, like, coding [laughs] because, you know, building a React Native app is coding in React. The challenges that I faced were, like you said, it's just the mobile ecosystem and learning all the intricacies, the functionality that users have come to expect in mobile apps, you know, like password manager, integration, and background execution modes, and deep linking strategies, all that kind of stuff.

+ +

You know, if you don't know what questions to ask or what features to be thinking of, it's just really hard. And [laughs] I think it's more than just the developer needing to know that too. I think anytime it comes, you know, down to building an app, the whole team needs to have that mobile background. It's just a completely different platform than building for the web, right? So like, product owners, project managers, designers, developers all need that context so we can be prioritizing the right features and building a UI that matches the patterns that people have come to expect in a mobile app. And then, of course, developing those apps using the, you know, the proper native modules.

+ +

WILL: Yeah, definitely. And I [chuckles]...you mentioned that it's mostly on, like, the mobile side. I don't know the best way to say that. But, like, I can tell you, when I first got onto the React Native project, there were numerous features that I could implement, and to a certain point to where I had to go that mobile.

+ +

So, like, I was like, oh yeah, I can learn these new components that's in React Native. Okay, I got it to work. It's finished. You know, my PM would be like, "Well, it's not completely finished because you have to deploy it." And I was like, oh, I have no idea what I'm doing now. Like, I just know [laughs]...I know up to this point.

+ +

STEPHEN: [laughs]

+ +

WILL: But anything over that, I'm like, yeah, I have no idea.

+ +

STEPHEN: Especially with consulting, right? With consulting, you need even more expertise, right? The clients are counting on you to build their app. And that's where, you know, having that deep, deep familiarity where you can say to a client, "This is how we're going to do the deployment process, you know, and I need, you know, X, Y, and Z to help set it up. And here are the deliverables, and here's when we'll have it," that kind of thing. Like, it really takes it up a whole nother notch what you need to know.

+ +

WILL: Definitely, yeah. Because I think compared to mobile, I feel like web development can almost be like the Wild Wild West. And what I mean by that is, like, there's no rules for you to push out a website in web. Like, you know, you build it. You push it out. It can be out there, you know. Whoever is hosting it, unless you go against their rules, maybe, but their rules are very relaxed and stuff like that.

+ +

Mobile, there's a totally different set of rules. Because, like, I was laughing not too long ago. There was rumors that Elon Musk was going to remove the blocking feature on Twitter [chuckles]. And it was funny because all the mobile devs they came out. And if you're a mobile dev, you know this. Apple is very strict.

+ +

STEPHEN: [laughs]

+ +

WILL: If this is a social media app that you're building, you have to have that blocking feature, which I agree it needs to be there. But it's funny, like, all the mobile devs was like, yeah, that's not going to work. Good luck [chuckles]. Good luck being an app again.

+ +

STEPHEN: Yeah, [laughs] good luck.

+ +

WILL: Like, they're going to kick it off. And yeah, they're very big on kicking it off if it doesn't follow those rules and things like that. So yeah, for React Native, you have to learn those rules, or, like I said, they won't approve it. They won't push it out to their store.

+ +

STEPHEN: Yep, exactly. Yeah. I feel like the new one at every client project; I have to say, "We have to offer a way to delete your account in the app," because [laughs] that's a new one that launched last year, and I think has just started being enforced more recently. Like, all those little gotcha rules, you know, like, if you don't know about that, then you're going to go to submit your app to the stores, and you're going to get rejected every single time. [laughs].

+ +

WILL: And they're not shy about rejecting you [laughs].

+ +

STEPHEN: Yeah. But I would say, like, a lot of the rules, I'm like, yes, this is amazing that we have these rules, you know. It does help keep the community safer like things like blocking. But then there's the other rules of, like, Apple's like, hey, you've got to use our payment system and pay us 30% of every sale.

+ +

WILL: Yes [laughs].

+ +

STEPHEN: I was, like, you know, there's some evil stuff happening there, too.

+ +

WILL: I totally agree. And we ran into that issue. We had an app that used Stripe. And we actually had to remove it in order to use in-app purchases because...I forgot the rules around it, but it was essentially for digital content. I think it's what it was. And so, we had to use Apple's in-app purchases. So yeah, I totally agree with you on that.

+ +

STEPHEN: Yeah. I feel like I've been a part of so many apps where we're, like, reading those rules. And we're like, okay, you know, it's like, we're watching a live stream of birds.

+ +

WILL: [laughs]

+ +

STEPHEN: You know, like, the birds aren't digital [laughter], you know. It's like, [laughs] where does this fall in the rule? [laughs]

+ +

WILL: Yes [laughs]. I've done that, too [laughter]. Yep. It's almost like, you know, I feel like lawyers, okay, like, is this what this rule is, or the law what is written, or does this fall underneath that? So yeah, totally, totally agree.

+ +

STEPHEN: Yep [laughs].

+ +

WILL: So, you've been here a couple of years at thoughtbot. What has been your experience building React Natives here for clients at thoughtbot?

+ +

STEPHEN: Yeah, yeah. I've been at thoughtbot for about five years now. And I have been building React Native apps that whole time. And, I mean, I started at thoughtbot a little more in the full-stack space, web development, and have transitioned to where I'm mostly only building React Native mobile apps now.

+ +

It's been a great experience. I think that React Native is really a sweet spot of; we're able to build these apps really efficiently and much less expensively than when we're doing pure native. And the end product is a really good app. So, it's been a great experience, you know, React Native is really...it has a really nice development experience. You know, it's the JavaScript React ecosystem. And we use TypeScript, and we have a really good developer experience with it. And then we're building apps that clients are really happy with and with a good budget.

+ +

So, I think it's kind of that, you know, like, win-win-win kind of scenario where everybody is happy. And yeah, I don't see it going anywhere. And I think we're going to be building React Native apps for quite a while to come.

+ +

WILL: Yeah, I totally agree with that. Where do you see React Native and mobile dev going here at thoughtbot in the next six months or even the next year? What are your goals for the mobile team?

+ +

STEPHEN: We've got a couple of goals. One of them is around kind of what we've talked about with the mobile space in general. This isn't really specific to React Native, but it can be. But, consulting in the mobile space is challenging because there's a lot of mobile-specific domain knowledge that a team really needs to have.

+ +

So, that's something that we've started looking into is, like, how do we build up our resources internally and then, hopefully, externally as well to help guide us on our projects and ensure that we have, like, you know, we are developing apps consistently and efficiently every time? So, that's something we're looking into is, like resources to help our teams—not just developers, but project managers, designers, and developers—help us navigate the mobile space.

+ +

Okay, you're going to do push notifications. Here's the library we use. Here's things to think about, and interactions to think about, and iOS-specific functionality that we could support, and Android-specific functionality that we can support. You know, you're going to do deep linking; do you want to use universal links, or do you want to use a different strategy, a scheme-based link? So, basically, building up that set of resources so that our teams are all able to consult and build efficiently and consistently across the board. So, that's kind of goal number one.

+ +

And then, goal number two is to kind of bring some of that out into the community a little bit more. So, thoughtbot is very well known in the Rails space for all of the open-source content we've put out and blog posts, and courses, and books. I mean, there's just so much on the Rails side that thoughtbot has done. And we're just a little bit less mature on the React Native side in terms of what we've put out there. So, that's kind of the second goal is giving back, helping others kind of do that same thing. I feel like we have developed our practices internally, and we're building some great apps. And it's kind of time to contribute back a little bit more.

+ +

WILL: Awesome. I'm looking forward to reaching those goals. If you can go back and give yourself advice, what would you tell yourself?

+ +

STEPHEN: I would maybe say, read the documentation [laughs]. I don't know when I got into mobile; I think I just jumped in. And, you know, we've talked about some of the mobile-specific domain, and not knowing what you don't know, and app review guidelines. I feel like early on, I just responded to challenges as they came up, as opposed to just digging into, you know, Apple's documentation and Android's documentation and just really understanding the underlying operating systems in stores. That's probably a piece of advice.

+ +

If I could go back, I would just start at the documentation, you know, go to developer.apple.com and read about all of the underlying APIs of StoreKit and, you know, associated domains and all of these sorts of things. Just learn 'em, and then you know 'em. [laughs].

+ +

So, maybe that could have saved me some heartache if I just was a little more intentional about, okay, I'm getting into app development. I'm going to set aside some time and just really learn this stuff, as opposed to kind of where I had one foot in the door, one foot out of the door for a while. And I think that kept me from just sitting down and really going deep.

+ +

WILL: That's really good advice. Just read the documentation. And that's not just Apple.

+ +

STEPHEN: [laughs]

+ +

WILL: That's a lot of departments, sections of my life. So, yes, I like that.

+ +

[laughter]

+ +

STEPHEN: I actually...that's something I did early in my career. So, I started as an Enterprise Java developer in 2011, and I was using the Spring framework. I downloaded the entire PDF. It was, like, 250 pages, the documentation [laughs]. And I remember just being on, like, airplane flights, and I just read the documentation, just cover to cover. That served me so well. I was, like, the expert, you know [laughs]. I don't always do it, but when I do, I'm like, oh yeah, why didn't I do that sooner? [laughs]

+ +

WILL: Yeah, totally agree. I like that. What is the wind in your sails? What motivates Stephen?

+ +

STEPHEN: Like, I think what attracted me to software development is just being able to build stuff, you know, probably the same thing that attracted me to woodworking. So, I think what motivates me is that prospect of, hey, I'm building an app that people are going to use, and it's going to make their life better. So, that's really what gets me up and gets me motivated. It's less so the actual coding, to be honest. It's really the prospect of, like, hey, I'm building something.

+ +

WILL: Awesome. Yeah. Is there anything that you would like to promote?

+ +

STEPHEN: If you're interested in building a mobile app, come talk to us. We'd love to build your mobile app. Go to thoughtbot.com/hire-us; I believe hire-us. We would love to talk to you about your mobile project. So, don't hesitate to reach out. We'd love to hear about what you're interested in building.

+ +

WILL: Awesome. Well, Stephen, it was great to chat with you. It's always great to chat with you about mobile development and just personal life things. So, I really appreciate you being on the podcast today.

+ +

STEPHEN: Thanks for having me, Will. It was a lot of fun. Always good talking with you.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Stephen Hanson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jthEDJ6N + + ]]> + + Will Larry + Stephen Hanson + + + 492: Backstop.it and Varo Bank with Rishi Malik + https://podcast.thoughtbot.com/492 + dc2028cc-f9cf-4442-abae-da007b96cfb3 + Thu, 14 Sep 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Victoria and Will interview Rishi Malik, the Founder of Backstop.it and VP of Engineering at Varo Bank. They talk about Rishi's recent adventure at DEF CON, the renowned annual security conference that he's attended for six years, and describes how it has transformed from a mere learning experience into a thrilling competition for him and his team. The conference = their playground for tackling an array of security challenges and brain-teasing puzzles, with a primary focus on cloud security competitions. + +The trio cover the significance of community in such events and how problem-solving through interaction adds value. Rishi shares his background, tracing his path from firmware development through various tech companies to his current roles in security and engineering management. + +The vital topic of security in the fintech and banking sector highlights the initial concerns people had when online banking emerged. Rishi navigates through the technical intricacies of security measures, liability protection, and the regulatory framework that safeguards online banking for consumers. He also highlights the evolving landscape, where technological advancements and convenience have bolstered consumer confidence in online banking. + +Rishi shares his unique approach to leadership and decision-making, and pearls of wisdom for budding engineers starting their careers. His advice revolves around nurturing curiosity and relentlessly seeking to understand the "why" behind systems and processes. + 40:17 + no + + + Victoria and Will interview Rishi Malik, the Founder of Backstop.it and VP of Engineering at Varo Bank. They talk about Rishi's recent adventure at DEF CON, the renowned annual security conference that he's attended for six years, and describes how it has transformed from a mere learning experience into a thrilling competition for him and his team. The conference = their playground for tackling an array of security challenges and brain-teasing puzzles, with a primary focus on cloud security competitions. +They talk about the significance of community in such events and how problem-solving through interaction adds value. Rishi shares his background, tracing his path from firmware development through various tech companies to his current roles in security and engineering management. +The vital topic of security in the fintech and banking sector highlights the initial concerns people had when online banking emerged. Rishi navigates through the technical intricacies of security measures, liability protection, and the regulatory framework that safeguards online banking for consumers. He also highlights the evolving landscape, where technological advancements and convenience have bolstered consumer confidence in online banking. +Rishi shares his unique approach to leadership and decision-making, and pearls of wisdom for budding engineers starting their careers. His advice revolves around nurturing curiosity and relentlessly seeking to understand the "why" behind systems and processes. +__ +Backstop.it (https://backstop.it/) +Follow Backstop.it on X (https://twitter.com/wearebackstop). +Varo Bank (https://www.varomoney.com/) +Follow Varo Bank on Instagram (https://www.instagram.com/varobank/), Facebook (https://www.facebook.com/varomoney/), X (https://twitter.com/varobank), YouTube (https://www.youtube.com/varomoney), or LinkedIn (https://www.linkedin.com/company/varobank/). +Follow Rishi Malik on LinkedIn (https://www.linkedin.com/in/rishilmalik/). +Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. And with us today is Rishi Malik, Founder of Backstop.it and VP of Engineering at Varo Bank. Rishi, thank you for joining us. +RISHI: Thanks for having me. I'm excited to be here. +VICTORIA: Yes, Rishi. I'm so excited to talk with you today about your security background and get into your role at Varo and Backstop IT. But first, I wanted to hear a little bit more about your recent experience attending DEF CON. How was that? +RISHI: It was awesome. I do have quite the background in security at this point. And one of the things I started doing early on, as I was getting up to speed and learning more about the security-specific side of things, was beginning to attend DEF CON itself. So, I've now gone six years straight. +And it started out as just kind of experiencing the conference and security and meeting folks. But it's progressed to where I now bring a team of people where we go and we compete. We have a good time. But we do get to kind of bring the security side of things into the software engineering and engineering leadership stuff that we all do on a day-to-day basis. +VICTORIA: Yeah. And what kind of puzzles do you solve with your team when you attend DEF CON? +RISHI: There's definitely a lot of variety there, which I think is part of the fun. So, DEF CON frequently has electronic badges, you know, with random puzzles on there that you have to solve. Some of it are cryptographic. Some of them are kind of random cultural things. Sometimes there's music challenges based around it. Sometimes, it's social and interactive. And you have to go find the right type of badge or the right person behind it to unlock something. So, all of those, you know, typically exist and are a ton of fun. +Primarily, in the last few years, we've been focusing more on the cloud CTF. So, in this case, it's our team competing against other teams and really focused on cloud security. So, it's, you know, figuring out vulnerabilities in, you know, specially designed puzzles around AWS and GCP, the application side of things as well, and competing to see how well you can do. +Three years ago, the last couple of years, we've not won it, but we've been pretty competitive. And the great thing is the field is expanding as more and more people get into CTF themselves but, more importantly, into cloud infrastructure and cloud knowledge there. So, it's just great to see that expansion and see what people are into, what people are learning, and how challenging some of these things can be. +VICTORIA: I love the idea of having a puzzle at a conference where you have to find a specific person to solve it. And yeah, I'm always interested in ways where we can have these events where you're getting together and building community and growing expertise in a field but in a way that makes it fun [laughs] and isn't just life-draining long, like, talks about random stuff. +RISHI: [laughs] I think what you're touching on there is crucial. And you said the word community, and, to me, that is, you know, a big part of what DEF CON and, you know, hacking and security culture is. But it is, I think, one of the things that kind of outside of this, we tend to miss it more, you know, specifically, like, focused conferences. It is more about kind of the content, you know, the hallway track is always a thing. But it's less intentional than I personally, at this stage, really prefer, you know. So, I do like those things where it is encouraging interaction. +For me, I'd rather go to happy hour with some people who are really well versed in the subject that they're in rather than even necessarily listening to a talk from them on what they're doing. Simply because I think the community aspect, the social aspect, actually gets you more of the information that is more relevant to what you're doing on a day-to-day basis than just consuming it passively. +VICTORIA: I agree because consuming it passively or even intentionally remotely, there are things that you didn't even think to think about [laughs] that aren't going to come up just on your own. You have to have another person there who's...Actually, I have a good friend who's co-working with me this week who's at Ticketmaster. And so, just hearing about some of the problems they have and issues there has been entertaining for me. So yeah, I love that about DEF CON, and I love hearing about community stories and fun ways that companies can get a benefit out of coming together and just putting good content out there. +RISHI: Absolutely. I think problem-solving is where you get the most value out of it as a company and as a business. +VICTORIA: Yeah, maybe that's a good segue to tell me a little bit more about your background and how you came to be where you are today. +RISHI: Yeah. For me growing up, I was always that problem-solver type of person. So, I think that's what kind of naturally gravitated me towards tech and, you know, hardware and software engineering. You know, so, for me, I go back quite a while. I'd been doing a lot of development, you know, in the early days of my career. +I started out doing firmware development back in the days of large tape libraries, right? So, if you think about, like, big businesses back before cloud was a big thing and even back before SSDs were a thing, you know, it was all spinning disks. It was all tape. And that's kind of the area that I started in. So, I was working on robots that actually move tapes around these giant tape libraries that are, you know, taller than I am that you can walk inside of because they're so big, for big corporations to be able to backup their data on an overnight basis. You have to do that kind of stuff. +Then I started going into smaller and smaller companies, into web tech, into startups, then into venture-backed startups. And then, eventually, I started my own company and did that for a while. All of this is really just kind of, you know, software engineering in a nutshell, lots of different languages, lots of different technologies. But really, from the standpoint of, here's a whole bunch of hard problems that need to be solved. Let's figure out how we can do that and how we can make some money by solving some of these problems. +That eventually kind of led me down the security path as well and the engineering management side of things, which is what I do now, both at Backstop...is a security consulting business and being VP of Engineering at Varo Bank. +WILL: How was your journey? Because you started as an intern in 2003. +RISHI: [laughs] +WILL: And then, you know, 20 years later. So, how was your journey through all of that? [laughs] +RISHI: [laughs] You know, I hadn't actually put it together that it has been 20 years this year until you said that. So, that's awesome. It's been a blast, you know. I can honestly say it's been wildly different than what I imagined 20 years ago and interesting in different ways. I think I'm very fortunate to be able to say that. +When I started out as an intern in 2003, technologies were very different. I was doing some intern shifts with the federal government, you know, so the pace was wildly different. And when I think of where technology has come now, and where the industry has gone, and what I get to do on a day-to-day basis, I'm kind of just almost speechless at just how far we've come in 20 years, how easy some things are, how remarkably hard some other things are that should honestly be easy at this point, but just the things that we can do. +I'm old enough that I remember cell phones being a thing and then smartphones coming out and playing with them and being like, yeah, this is kind of mediocre. I don't really know why people would want this. And the iPhone coming out and just changing the game and being like, okay, now I get it. You know, to the experience of the internet and, you know, mobile data and everywhere. It's just phenomenal the advances that we've had in the last 20 years. And it makes me excited for the next 20 years to see what we can do as we go forward. +VICTORIA: I'm going to take personal offense to someone knowing that technology being too old [laughs], but, yeah, because it really wasn't that long ago. And I think one thing I always think about having a background in civic tech and in financial tech as well is that the future is here; it's just not evenly distributed. So, now, if you're building a new company, of course, the default is to go straight to the cloud. +But many companies and organizations that have been around for 60-80 years and using the internet right when it first came out are still in really old technologies that just simply work. And maybe they're not totally sure why, and change is difficult and slow. So, I wonder if you have any experience that you can take from the banking or fintech industry on how to make the most out of modern security and compliance platforms. +RISHI: Yeah, you know, I think most people in tech especially...and the gray hairs on me are saying the younger folks in tech especially don't realize just how much older technologies still exist and will exist for quite some time. +When you think of banking itself, you know, most of the major companies that you can think of, you know, in the U.S. especially but kind of across the world that are the top tier names of banks, and networks, and stuff like that, still run mainframes. When you swipe your credit card, there's a very good chance that is processed on a mainframe. And that's not a bad thing. But it's just, you know when you talk to younger engineers, it's not something that kind of crosses their mind. They feel like it is old-tech. +The bulk of businesses don't actually run on the cloud. Having been through it, I've racked and stacked servers and had to figure out how to physically take hardware across, you know, country borders and things like those lines. And now, when I do want to spin up a server somewhere else, it's just a different AWS region. So, it's remarkably easy, at this point, to solve a lot of those problems. +But once you're up and live and you have customers, you know, where downtime is impactful or, you know, the cost of moving to the cloud or modernizing your technology is substantial, things tend to move a lot slower. And I think you see that, especially when it comes to security, because we have more modern movements like DevOps bringing security into it. And with a lot of the, you know, the modern security and compliance platforms that exist, they work very, very well for what they do, especially when you're a startup or your whole tech stack is modernized. +The biggest challenges, I think, seem to come in when you have that hybrid aspect of it. You do have some cloud infrastructure you have to secure. You do have some physical data centers you have to secure. You have something that is, you know, on-premise in your office. You have something that is co [inaudible 10:01] somewhere else. Or you also have to deal with stuff like, you know, much less modern tech, you know, when it comes to mainframes and security and kind of being responsible for all of that. +And I think that is a big challenge because security is one of those things where it's, you know, if you think of your house, you can have the strongest locks on your door and everything else like that. But if you have one weak point, you have a window that's left open, that's all it takes. And so, it has to be all-inclusive and holistic. And I think that is remarkably hard to do well, even despite where technology has come to these days. +WILL: Speaking of securities, I remember when the Internet banking started a couple of years ago. And some of the biggest, I guess, fears were, like, the security around it, the safety. Because, you know, your money, you're putting your money in it, and you can't go to a physical location to talk to anyone or anything. And the more and more you learn about it...at first, I was terrified of it because you couldn't go talk to someone. But the more and more I learned about it, I was like, oh, there's so much security around it. In your role, what does that look like for you? Because you have such a huge impact with people's money. So, how do you overcome that fear that people have? +RISHI: There's, I think, a number of steps that kind of go into it. And, you know, in 2023, it's certainly a little bit easier than it used to be. But, you know, very similar, I've had the same questions, you know, and concerns that you're describing. And I remember using one of the first banks that was essentially all digital and kind of wondering, you know, where is my money going? What happens if something goes wrong? And all of those types of things. +And so, I think there is kind of a number of different aspects that go into it. One is, you know, obviously, the technical aspects of security, you know, when you put your credit card number in on the internet, you know, is it encrypted? You know, is it over, you know, TLS? What's happening there? You know, how safe and secure is all that kind of thing? +You know, at this point, pretty much everyone, at least in the U.S., has been affected by credit card breaches, huge companies like Home Depot and Target that got cards accessed or, you know, just even the smaller companies when you're buying something random from maybe something...a smaller website on the internet. You know, that's all a little bit better now. So, I think what you have there was just kind of a little bit of becoming comfortable with what exists now. +The other aspect, though, I think, then comes into, well, what happens when something goes wrong? And I think there's a number of aspects that are super helpful for that. I think the liability aspect of credit card, you know, companies saying, you know, and the banks "You're not liable for a fraudulent transaction," I think that was a very big and important step that really helps with that. +And on top of that, then I think when you have stuff like the FDIC, you know, and insurance in the U.S., you know, that is government-backed that says, you know what? Even if this is an online-only digital bank, you're safe. You're protected. The government's got your back in that regard. And we're going to make sure that's covered. At Varo, that's one of the key things that we think about a lot because we are a bank. +Now, most FinTechs, actually, aren't banks, right? They partner with other third-party banks to provide their financial services. Whereas at Varo, we are federally regulated. And so, we have the full FDIC protection. We get the benefits of that. But it also means that we deal with the regulation aspects and being able to prove that we are safe and secure and show the regulators that we're doing the right things for our customers. +And I think that's huge and important because, obviously, it's safety for customers. But then it changes how you begin to think about how you're designing products, and how you're [inaudible 13:34] them, and, you know, how you're marketing them. Are we making a mobile app that shows that we're safe, and secure, and stable? Or are we doing this [inaudible 13:42] thing of moving too fast and breaking things? +When it's people's money, you have to be very, very dialed into that. You still have to be able to move fast, but you have to show the protection and the safety that people have because it is impactful to their lives. And so, I think from the FinTech perspective, that's a shift that's been happening over the last couple of years to continue that. +The last thing I'll say, too, is that part of it has just come from technology itself and the comfort there. It used to be that people who were buying, you know, items on the internet were more the exception rather than the rule. And now with Amazon, with Shopify, with all the other stuff that's out there, like, it's much more than a norm. And so, all of that just adds that level of comfort that says, I know I'm doing the right things as a consumer, that I'm protected. If I, you know, do have problems, my bank's got my back. The government is watching out for what's happening and trying to do what they can do to regulate all of that. +So, I think all of that has combined to get to that point where we can do much more of our banking online and safely. And I think that's a pretty fantastic thing when it comes to what customers get from that. I am old enough that I remember having to figure out times to get to the bank because they're open nine to five, and, you know, I have to deposit my paycheck. And, you know, I work nine to five, and maybe more hours pass, and I had no idea when I can go get that submitted. +And now, when I have to deposit something, I can just take a picture with my phone, and it safely makes it to my account. So, I think the convenience that we have now is really amazing, but it has certainly taken some time. And I think a number of different industry and commercial players kind of come together and make that happen. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +VICTORIA: I appreciate that perspective on approaching security from the user experience of wanting safety. And I'm curious if we can talk in contrast from that experience to the developer experience with security. And how do you, as a new leader in this financial product company, prioritize security and introduce it from a, like, building a safety culture perspective? +RISHI: I think you just said that very eloquently. It is a safety culture. And cultural changes are hard. And I think for quite some time in the developer industry, security was either an afterthought or somebody else's problem. You know, it's the security team that has to think about it. It's, you know, and even these days, it's the red team that's going to go, you know, find these answers or whatever I'm shipping as a developer. My only thing to focus on is how fast I can ship, or, you know, what I'm shipping, rather than how secure is what I'm shipping. +And so, I think to really be effective at that, it is a cultural shift. You have to think and talk about security from the outset. And you have to bake those processes into how you build product. Those security conversations really do need to start at the design phase. And, you know, thinking about a mobile app for a bank as an example, you know, it starts when you're just thinking about the different screens on a mobile app that people are going to go through. How are people interpreting this? You know, what is the [inaudible 17:23], and the feeling, and the emotions, that we're building towards? You know, is that safe and secure or, you know, is it not? +But then it starts getting to the architecture and the design of the systems themselves to say, well, here's how they're going to enter information, here's how we're passing this back and forth. And especially in a world where a lot of software isn't just 100% in-house, but we're calling other partners for that, you know, be it, you know, infrastructure or risk, you know, or compliance, or whatever else it may be, how are we protecting people's data? How are we making sure our third parties are protecting people's data? You know, how are we encrypting it? How are we thinking about their safety all the way through? +Again, even all the way down to the individual developer that's writing code, how are we verifying they're writing good, high-quality, secure code? Part of it is training, part of it is culture, part of it is using good tooling around that to be able to make sure and say, when humans make mistakes because we are all human and we all will make mistakes, how are we catching that? +What are the layers do we have to make sure that if a mistake does happen, we either catch it before it happens or, you know, we have defense in depth such that that mistake in and of itself isn't enough to cause a, you know, compromise or a problem for our customers? So, I think it starts right from the start. And then, every kind of step along the way for delivering value for customers, also let's add that security and privacy and compliance perspective in there as well. +VICTORIA: Yes, I agree. And I don't want to work for a company where if I make a small human mistake, I'm going to potentially cost someone tens or however many thousands of dollars. [laughs] +WILL: I have a question around that. How, as a leader, how does that affect you day to day? Because I feel like there's some companies, maybe thoughtbot, maybe other companies, that a decision is not as critical as working as a bank. So, you, as a leader, how do you handle that? +RISHI: There's a couple of things I try and consider in any given big or important decision I have to make, the aspects around, like, you know, the context, what the decision is, and that type of stuff. But from a higher level, there's kind of two things I try and keep in mind. And when I say keep in mind, like, when it's a big, impactful decision, I will actually go through the steps of, you know, writing it down or talking this out loud, sometimes by myself, sometimes with others, just, again, to make sure we are actually getting to the meat of it. +But the first thing I'm trying to think of is kind of the Amazon idea of one-way versus two-way doors. If we make this decision and this is the wrong decision, what are the ramifications of that? You know, is it super easy to undo and there's very little risk with it? Or is it once we've made this decision or the negative outcome of this decision has happened, is it unfixable to a certain degree? +You know, and that is a good reminder in my head to make sure that, you know, A, I am considering it deeply. And that, B, if it is something where the ramifications, you know, are super huge, that you do take the time, and you do the legwork necessary to make sure you're making a good, valid decision, you know, based on the data, based on the risks involved and that there's a deep understanding of the problem there. +The second thing I try to think of is our customers. So, at Varo, our customers aren't who most banks target. A lot of banks want you to take all your money, put it in there, and they're going to loan that money out to make their money. And Varo is not that type of bank, and we focus on a pretty different segment of the market. What that means is our customers need their money. They need it safely and reliably, and it needs to be accurate when they have it. +And what I mean by that is, you know, frequently, our customers may not have, you know, hundreds or a thousand dollars worth of float in their bank accounts. So, if they're going and they're buying groceries and they can't because there's an error on our side because we're down, and because the transactions haven't settled, then that is very, very impactful to them, you know, as an individual. +And I think about that with most of these decisions because being in software and being in engineering I am fortunate enough that I'm not necessarily experiencing the same economic struggles that our customers may have. And so, that reminder helps me to think about it from their perspective. In addition, I also like to try and think of it from the perspective...from my mom, actually, who, you know, she is retired age. She's a teacher. She's non-technical. +And so, I think about her because I'd say, okay, when we're making a product or a design decision, how easy is it for her to understand? And my biases when I think about that, really kind of come into focus when I think about how she would interpret things. Because, you know, again, for me, I'm in tech. I think about things, you know, very analytically. And I just have a ton of experience across the industry, which she doesn't have. So, even something as simple as a little bit of copy for a page that makes a ton of sense to me, when I think about how she would interpret it, it's frequently wildly different. +And so, all of those things, I think, kind of come together to help make a very strong and informed decision in these types of situations where the negative outcomes really do matter. But you are, you know, as Varo is, you're a startup. And you do need to be able to build more products quickly because our customers have needs that aren't being met by the existing banking industry. And so, we need to provide value to them so that their lives are a bit better. +VICTORIA: I love that focus on a specific market segment and their needs and solving for that problem. And we know that if you're at a certain income level, it's more expensive [laughs] because of the overdraft fees and other things that can cause you problems. So, I really appreciate that that's the mission at Varo, and that's who you're focusing on to create a better banking product that makes more sense. +I'm curious if there were any surprises and challenges that you could share from that discovery process and finding out, you know, exactly what were those things where your mom was, like, uh, actually, I need something completely different. [laughs] +RISHI: Yeah, so, [chuckles] I'm chuckling because, you know, it's not, like, a single kind of time or event. It's, you know, definitely an ongoing process. But, you know, as actually, we were talking, you know, about earlier in terms of being kind of comfortable with doing things digital and online, that in and of itself is something that even in 2023, my mom isn't as comfortable or as confident as, you know, say, maybe the three of us are. +As an example, when sending money, you know, kind of like a peer-to-peer basis, like, if I'm sending my mom a little bit of money, or she's sending me something, you're kind of within the family. Things that I would think would be kind of very easy and straightforward actually do cause her a little bit more concern. Okay, I'm entering my debit card number into this so that it can get, you know, the cash transferred into my bank account. You know, again, for me, it didn't even cross my mind, actually, that that would be something uncomfortable. But for my mom, that was something where she actually had some concerns about it and was messaging me. +Her kind of personal point of view on that was, I would rather use a credit card for this and get the money on a credit card instead of a debit card because the debit card is linked to a bank account, and the security around that needs to be, you know, much tighter. And so, it made her more uncomfortable entering that on her phone. Whereas even a credit card it would have given her a little bit more peace of mind simply because it wasn't directly tied to her bank account. +So, that's just, you know, the most recent example. I mean, honestly, that was earlier today, but it's something I hadn't thought of. And, again, for most of our customers, maybe that's not the case and how they think. But for folks that are at that retirement age, you know, in a world where there are constant barrages of scam, you know, emails, and phone calls, and text messages going around, the concern was definitely there. +VICTORIA: That happened to me. Last week, I was on vacation with my family, and we needed to pay my mom for the house we'd rented. And I had to teach her how to use Zelle and set up Zelle. [laughter] It was a week-long process. But we got there, and it works [laughs] now. But yeah, it's interesting what concerns they have. And the funny part about it was that my sister-in-law happens to be, like, a lawyer who prevents class action lawsuits at a major bank. And she reassured us that it was, in fact, secure. [laughs] +I think it's interesting thinking about that user experience for security. And I'm curious, again, like, compare again with the developer experience and using security toolings. And I wonder if you had any top recommendations on tools that make the developer experience a little more comfortable and feeling like you're deploying with security in mind. +RISHI: That, in particular, is a bit of a hard question to answer. I try and stay away from specific vendors when it comes to that because I think a lot of it is contextual. But I could definitely talk through, like, some of the tools that I use and the way I like to think about it, especially from the developer perspective. +I think, first off, consider what aspect of the software development, you know, lifecycle you're in. If you are an engineer writing, you know, mostly application code and dealing with building product and features and stuff like that, start from that angle. I could even take a step back and say security as an industry is very, very wide at this point. There is somebody trying to sell you a tool for basically every step in the SDLC process, and honestly, before and after to [inaudible 26:23]. I would even almost say it's, to some extent, kind of information and vendor overload in a lot of ways. +So, I think what's important is to think about what your particular aspect of that is. Again, as an application engineer, or if you're building cloud infrastructure, or if you're an SRE, you know, or a platform team, kind of depending on what you are, your tooling will be different. The concepts are all kind of similar ideas, but how you go about what you build will be different. +In general, I like to say, from the app side of things, A, start with considering the code you're writing. And that's a little bit cultural, but it's also kind of more training. Are you writing code with a security mindset? are you designing systems with a security mindset? These aren't things that are typically taught, you know, in school if you go get a CS degree, or even in a lot of companies in terms of the things that you should be thinking about. So, A, start from there. +And if you don't feel like you think about, you know, is this design secure? Have we done, you know, threat modeling on it? Are we considering all of the error paths or the negative ways people can break the system? Then, start from that and start going through some of the security training that exists out there. And there's a lot of different aspects or avenues by which you can get that to be able to say, like, okay, I know I'm at least thinking about the code I write with a security mindset, even if you haven't actually changed anything about the code you're writing yet. +What I actually think is really helpful for a lot of engineers is to have them try and break things. It's why I like to compete in CTFs, but it's also why I like to have my engineers do the same types of things. Trying to break software is both really insightful from the aspect that you don't get when you're just writing code and shipping it because it's not something you have time to do, but it's also a great way to build up some of the skills that you need to then protect against. +And there's a lot of good, you know, cyber ranges out there. There's lots of good, just intentionally vulnerable applications that you can find on GitHub but that you can just run, you know, locally even on your machine and say, okay, now I have a little web app stood up. I know this is vulnerable. What do I do? How do I go and break it? Because then all of a sudden, the code that you're writing you start to think about a little bit differently. +It's not just about how am I solving this product problem or this development problem? But it's, how am I doing this in a way that is safe and secure? Again, as an application side of things, you know, just make sure you know the OWASP Top 10 inside and out. Those are the most basic things a lot of engineers miss. And it only takes, again, one miss for it to be critical. So, start reviewing it. +And then, you start to think about the tooling aspect of it. People are human. We're going to make mistakes. So, how do we use the power of technology to be able to stop this? You know, and there is static scanning tools. Like, there's a whole bunch of different ones out there. You know, Semgrep is a great one that's open source just to get started with that can help you find the vulnerable code that may exist there. +Consider the SQL queries that you're writing, and most importantly, how you're writing them. You know, are you taking user input and just chucking it in there, or are you sanitizing it? When I ask these questions, for a lot of engineers, it's not usually yes or no. It's much more of an, well, I don't know. Because in software, we do a really good job of writing abstraction layers. But that also means, you know, to some extent, there may be a little bit of magic in there, or a lack thereof of magic that you don't necessarily know about. +And so, you have to be able to dive into the libraries. You have to know what you're doing to even be able to say something like, oh no, this SQL query is safe from this user input because we have sanitized it. We have, you know, done a prepared statement, whatever it may be. Or, no, actually, we are just doing something here that's been vulnerable, and we didn't realize we were, and so now that's something we have to address. +So, I think, like, that aspect in and of itself, which isn't, you know, a crazy ton of things. It's not spending a ton of money on different tools. But it's just internalizing the fact that you start to think a little bit differently. It provides a ton of value. +The last thing on that, too, is to be able to say, especially if you're coming from a development side, or even just from a founder or a startup side of things, what are my big risks? What do I need to take care of first? What are the giant holes or flaws? You know, and what is my threat model around that? +Obviously, as a bank, you have to care very deeply right from the start. You know, if you're not a bank, if you're not dealing with financial transactions, or PII, or anything like that, there are some things that you can deal with a little bit later. So, you have to know your industry, and you have to know what people are trying to do and the threat models and the threat vectors that can exist based on where you are. +WILL: That's amazing. You know, earlier, we talked about you being an engineer for 20 years, different areas, and stuff like that. Do you have any advice for engineers that are starting out right now? And, you know, from probably year one to year, you know, anything under ten years of experience, do you have any advice that you usually give engineers when you're chatting with them? +RISHI: The advice I tend to give people who are just starting out is be the type of person that asks, "How does this work?" Or "Why does this work?" And then do the work to figure out the answer. Maybe it is talking to someone; maybe it's diving into the details; maybe it's reading a book in some aspect that you haven't had much exposure to. +When I look at my career and when I look at the careers of folks around me and the people that I've seen be most successful, both in engineering but also on the business side, that desire to know why something is the case is I think, one of the biggest things that determines success. And then the ability to answer that question by putting in the right types of work, the right types of scientific method and processes and such, are the other factor. So, to me, that's what I try and get across to people. +I say that mostly to junior folks because I think when you're getting started, it's really difficult. There's a ton out there. And we've, again, as software engineers, and hardware engineers, and cloud, and all this kind of stuff, done a pretty good job of building a ton of abstraction layers. All of our abstraction layers [inaudible 32:28] to some degree. +You know, so as you start, you know, writing a bunch of code, you start finding a bunch of bugs that you don't necessarily know how to solve and that don't make any sense in the avenue that you've been exposed to. But as soon as you get into the next layer, you understand how that works begin to make a lot more sense. So, I think being comfortable with saying, "I have no idea why this is the case, but I'm going to go find out," makes the biggest difference for people just starting out their career. +WILL: I love that advice. Not too long ago, my manager encouraged me to write a blog post on something that I thought that I really knew. And when I started writing that blog post, I was like, oh boy, I have no idea. I know how to do it, but I don't know the why behind it. And so, I was very thankful that he encouraged me to write a blog post on it. Because once you start explaining it to other people, I feel you really have to know the whys. And so, I love that advice. That's really good advice. +VICTORIA: Me too. And it makes sense with what we see statistically as well in the DORA research. The DevOps Research Association publishes a survey every year, the State of DevOps Report. And one of the biggest findings I remember from last year's was that the most secure and reliable systems have the most open communication and high trust among the teams. And so, being able to have that curiosity as a junior developer, you need to be in an environment where you can feel comfortable asking questions [laughs], and you can approach different people, and you're encouraged to make those connections and write blog posts like Will was saying. +RISHI: Absolutely, absolutely. I think you touched on something very important there as well. The psychological safety really makes a big difference. And I think that's critical for, again, like, folks especially earlier in their career or have recently transitioned to tech, or whatever the case may be. Because asking "Why?" should be something that excites people, and there are companies where that's not necessarily the case, right? Where you asking why, it seems to be viewed as a sign that you don't know something, and therefore, you're not as good as what you should be, you know, the level you should be at or for whatever they expect. +But I do think that's the wrong attitude. I think the more people ask why, the more people are able and comfortable to be able to say, "I don't know, but I'm going to go find out," and then being able to be successful with that makes way better systems. It makes way safer and more secure systems. And, honestly, I think it makes humans, in general, better humans because we can do that. +VICTORIA: I think that's a great note to start to wrap up on. Is there any questions that you have for me or Will? +RISHI: Yeah. I would love to hear from both of you as to what you see; with the experiences that you have and what you do, the biggest impediments or speed bumps are when it comes to developers being able to write and ship secure code. +VICTORIA: When we're talking with new clients, it depends on where they are in really the adoption of their product and the maturity of their organization. Some early founders really have no technology experience. They have never managed an IT organization. You know, setting up basic employee account access and IDs is some of the initial steps you have to take to really get to where you can do identity management, and permissions management, and all the things that are really table stakes for security. +And then others have some progress, and they have a fair amount of data. And maybe it's in that situation, like you said before, where it's really a trade-off between the cost and benefit of making those changes to a more secure, more best practice in the cloud or in their CI/CD pipeline or wherever it may be. +And then, when you're a larger organization, and you have to make the trade-offs between all of that, and how it's impacting your developer experience, and how long are those deployed times now. And you might get fewer rates of errors and fewer rates of security vulnerabilities. But if it's taking three hours for your deployments to go out [laughs] because there's so many people, and there's so many checks to go through, then you have to consider where you can make some cuts and where there might be more efficiencies to be gained. +So, it's really interesting. Everyone's on a different point in their journey. And starting with the basics, like you said, I love that you brought up the OWASP Top 10. We've been adopting the CIS Controls and just doing a basic internal security audit ourselves to get more ready and to be in a position where... +What I'm familiar with as well from working in federal agencies, consulting, maintaining some of the older security frameworks can be a really high cost, not only in terms of auditing fees but what it impacts to your organization to, like, maintain those things [laughs] and the documentation required. And how do you do that in an agile way, in a way that really focuses on addressing the actual purpose of the requirements over needing to check a box? And how do we replicate that for our clients as well? +RISHI: That is super helpful. And I think the checkbox aspect that you just discussed I think is key. It's a difficult position to be in when there are boxes that you have to check and don't necessarily actually add value when it comes to security or compliance or, you know, a decrease in risk for the company. And I think that one of the challenges industry-wide has always been that security and compliance in and of itself tends to move a little bit slower from a blue team or a protection perspective than the rest of the industry. +And so, I mean, I can think of, you know, audits that I've been in where, you know, just even the fact that things were cloud-hosted just didn't make sense to the auditors. And it was a struggle to get them to understand that, you know, there is shared responsibility, and this kind of stuff exists, and AWS is taking care of some things, and we're taking care of some other things when they've just been developed with this on-premise kind of mentality. +That is one of the big challenges that still exists kind of across the board is making sure that the security work that you're doing adds security value, adds business value. It isn't just checking the box for the sake of checking the box, even when that's sometimes necessary. +VICTORIA: I am a pro box checker. +RISHI: [laughs] +VICTORIA: Like, I'll get the box checked. I'll use Trello and Confluence and any other tool besides Excel to do it, too. We'll make it happen with less pain, but I'd rather not do it [laughs] if we don't have to. +RISHI: [laughs] +VICTORIA: Let's make it easy. No, I love it. Is there anything else that you want to promote? +RISHI: No, I don't think there's anything else I want to promote other than I'm going to go back to what I said just earlier, like, that culture. And if, you know, folks are out there and you have junior engineers, you have engineers that are asking "Why?", you have people that just want to do the right thing and get better, lean into that. Double down on those types of folks. Those are the ones that are going to make big differences in what you do as a business, and do what you can to help them out. I think that is something we don't see enough of in the industry still. And I would love for that to change. +VICTORIA: I love that. Thank you so much, Rishi, for joining us. +RISHI: Thanks for having me. This was a great conversation. I appreciate the time. +VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you could find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Rishi Malik. + + + Victoria and Will interview Rishi Malik, the Founder of Backstop.it and VP of Engineering at Varo Bank. They talk about Rishi's recent adventure at DEF CON, the renowned annual security conference that he's attended for six years, and describes how it has transformed from a mere learning experience into a thrilling competition for him and his team. The conference = their playground for tackling an array of security challenges and brain-teasing puzzles, with a primary focus on cloud security competitions.

+ +

They talk about the significance of community in such events and how problem-solving through interaction adds value. Rishi shares his background, tracing his path from firmware development through various tech companies to his current roles in security and engineering management.

+ +

The vital topic of security in the fintech and banking sector highlights the initial concerns people had when online banking emerged. Rishi navigates through the technical intricacies of security measures, liability protection, and the regulatory framework that safeguards online banking for consumers. He also highlights the evolving landscape, where technological advancements and convenience have bolstered consumer confidence in online banking.

+ +

Rishi shares his unique approach to leadership and decision-making, and pearls of wisdom for budding engineers starting their careers. His advice revolves around nurturing curiosity and relentlessly seeking to understand the "why" behind systems and processes.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Rishi Malik, Founder of Backstop.it and VP of Engineering at Varo Bank. Rishi, thank you for joining us.

+ +

RISHI: Thanks for having me. I'm excited to be here.

+ +

VICTORIA: Yes, Rishi. I'm so excited to talk with you today about your security background and get into your role at Varo and Backstop IT. But first, I wanted to hear a little bit more about your recent experience attending DEF CON. How was that?

+ +

RISHI: It was awesome. I do have quite the background in security at this point. And one of the things I started doing early on, as I was getting up to speed and learning more about the security-specific side of things, was beginning to attend DEF CON itself. So, I've now gone six years straight.

+ +

And it started out as just kind of experiencing the conference and security and meeting folks. But it's progressed to where I now bring a team of people where we go and we compete. We have a good time. But we do get to kind of bring the security side of things into the software engineering and engineering leadership stuff that we all do on a day-to-day basis.

+ +

VICTORIA: Yeah. And what kind of puzzles do you solve with your team when you attend DEF CON?

+ +

RISHI: There's definitely a lot of variety there, which I think is part of the fun. So, DEF CON frequently has electronic badges, you know, with random puzzles on there that you have to solve. Some of it are cryptographic. Some of them are kind of random cultural things. Sometimes there's music challenges based around it. Sometimes, it's social and interactive. And you have to go find the right type of badge or the right person behind it to unlock something. So, all of those, you know, typically exist and are a ton of fun.

+ +

Primarily, in the last few years, we've been focusing more on the cloud CTF. So, in this case, it's our team competing against other teams and really focused on cloud security. So, it's, you know, figuring out vulnerabilities in, you know, specially designed puzzles around AWS and GCP, the application side of things as well, and competing to see how well you can do.

+ +

Three years ago, the last couple of years, we've not won it, but we've been pretty competitive. And the great thing is the field is expanding as more and more people get into CTF themselves but, more importantly, into cloud infrastructure and cloud knowledge there. So, it's just great to see that expansion and see what people are into, what people are learning, and how challenging some of these things can be.

+ +

VICTORIA: I love the idea of having a puzzle at a conference where you have to find a specific person to solve it. And yeah, I'm always interested in ways where we can have these events where you're getting together and building community and growing expertise in a field but in a way that makes it fun [laughs] and isn't just life-draining long, like, talks about random stuff.

+ +

RISHI: [laughs] I think what you're touching on there is crucial. And you said the word community, and, to me, that is, you know, a big part of what DEF CON and, you know, hacking and security culture is. But it is, I think, one of the things that kind of outside of this, we tend to miss it more, you know, specifically, like, focused conferences. It is more about kind of the content, you know, the hallway track is always a thing. But it's less intentional than I personally, at this stage, really prefer, you know. So, I do like those things where it is encouraging interaction.

+ +

For me, I'd rather go to happy hour with some people who are really well versed in the subject that they're in rather than even necessarily listening to a talk from them on what they're doing. Simply because I think the community aspect, the social aspect, actually gets you more of the information that is more relevant to what you're doing on a day-to-day basis than just consuming it passively.

+ +

VICTORIA: I agree because consuming it passively or even intentionally remotely, there are things that you didn't even think to think about [laughs] that aren't going to come up just on your own. You have to have another person there who's...Actually, I have a good friend who's co-working with me this week who's at Ticketmaster. And so, just hearing about some of the problems they have and issues there has been entertaining for me. So yeah, I love that about DEF CON, and I love hearing about community stories and fun ways that companies can get a benefit out of coming together and just putting good content out there.

+ +

RISHI: Absolutely. I think problem-solving is where you get the most value out of it as a company and as a business.

+ +

VICTORIA: Yeah, maybe that's a good segue to tell me a little bit more about your background and how you came to be where you are today.

+ +

RISHI: Yeah. For me growing up, I was always that problem-solver type of person. So, I think that's what kind of naturally gravitated me towards tech and, you know, hardware and software engineering. You know, so, for me, I go back quite a while. I'd been doing a lot of development, you know, in the early days of my career.

+ +

I started out doing firmware development back in the days of large tape libraries, right? So, if you think about, like, big businesses back before cloud was a big thing and even back before SSDs were a thing, you know, it was all spinning disks. It was all tape. And that's kind of the area that I started in. So, I was working on robots that actually move tapes around these giant tape libraries that are, you know, taller than I am that you can walk inside of because they're so big, for big corporations to be able to backup their data on an overnight basis. You have to do that kind of stuff.

+ +

Then I started going into smaller and smaller companies, into web tech, into startups, then into venture-backed startups. And then, eventually, I started my own company and did that for a while. All of this is really just kind of, you know, software engineering in a nutshell, lots of different languages, lots of different technologies. But really, from the standpoint of, here's a whole bunch of hard problems that need to be solved. Let's figure out how we can do that and how we can make some money by solving some of these problems.

+ +

That eventually kind of led me down the security path as well and the engineering management side of things, which is what I do now, both at Backstop...is a security consulting business and being VP of Engineering at Varo Bank.

+ +

WILL: How was your journey? Because you started as an intern in 2003.

+ +

RISHI: [laughs]

+ +

WILL: And then, you know, 20 years later. So, how was your journey through all of that? [laughs]

+ +

RISHI: [laughs] You know, I hadn't actually put it together that it has been 20 years this year until you said that. So, that's awesome. It's been a blast, you know. I can honestly say it's been wildly different than what I imagined 20 years ago and interesting in different ways. I think I'm very fortunate to be able to say that.

+ +

When I started out as an intern in 2003, technologies were very different. I was doing some intern shifts with the federal government, you know, so the pace was wildly different. And when I think of where technology has come now, and where the industry has gone, and what I get to do on a day-to-day basis, I'm kind of just almost speechless at just how far we've come in 20 years, how easy some things are, how remarkably hard some other things are that should honestly be easy at this point, but just the things that we can do.

+ +

I'm old enough that I remember cell phones being a thing and then smartphones coming out and playing with them and being like, yeah, this is kind of mediocre. I don't really know why people would want this. And the iPhone coming out and just changing the game and being like, okay, now I get it. You know, to the experience of the internet and, you know, mobile data and everywhere. It's just phenomenal the advances that we've had in the last 20 years. And it makes me excited for the next 20 years to see what we can do as we go forward.

+ +

VICTORIA: I'm going to take personal offense to someone knowing that technology being too old [laughs], but, yeah, because it really wasn't that long ago. And I think one thing I always think about having a background in civic tech and in financial tech as well is that the future is here; it's just not evenly distributed. So, now, if you're building a new company, of course, the default is to go straight to the cloud.

+ +

But many companies and organizations that have been around for 60-80 years and using the internet right when it first came out are still in really old technologies that just simply work. And maybe they're not totally sure why, and change is difficult and slow. So, I wonder if you have any experience that you can take from the banking or fintech industry on how to make the most out of modern security and compliance platforms.

+ +

RISHI: Yeah, you know, I think most people in tech especially...and the gray hairs on me are saying the younger folks in tech especially don't realize just how much older technologies still exist and will exist for quite some time.

+ +

When you think of banking itself, you know, most of the major companies that you can think of, you know, in the U.S. especially but kind of across the world that are the top tier names of banks, and networks, and stuff like that, still run mainframes. When you swipe your credit card, there's a very good chance that is processed on a mainframe. And that's not a bad thing. But it's just, you know when you talk to younger engineers, it's not something that kind of crosses their mind. They feel like it is old-tech.

+ +

The bulk of businesses don't actually run on the cloud. Having been through it, I've racked and stacked servers and had to figure out how to physically take hardware across, you know, country borders and things like those lines. And now, when I do want to spin up a server somewhere else, it's just a different AWS region. So, it's remarkably easy, at this point, to solve a lot of those problems.

+ +

But once you're up and live and you have customers, you know, where downtime is impactful or, you know, the cost of moving to the cloud or modernizing your technology is substantial, things tend to move a lot slower. And I think you see that, especially when it comes to security, because we have more modern movements like DevOps bringing security into it. And with a lot of the, you know, the modern security and compliance platforms that exist, they work very, very well for what they do, especially when you're a startup or your whole tech stack is modernized.

+ +

The biggest challenges, I think, seem to come in when you have that hybrid aspect of it. You do have some cloud infrastructure you have to secure. You do have some physical data centers you have to secure. You have something that is, you know, on-premise in your office. You have something that is co [inaudible 10:01] somewhere else. Or you also have to deal with stuff like, you know, much less modern tech, you know, when it comes to mainframes and security and kind of being responsible for all of that.

+ +

And I think that is a big challenge because security is one of those things where it's, you know, if you think of your house, you can have the strongest locks on your door and everything else like that. But if you have one weak point, you have a window that's left open, that's all it takes. And so, it has to be all-inclusive and holistic. And I think that is remarkably hard to do well, even despite where technology has come to these days.

+ +

WILL: Speaking of securities, I remember when the Internet banking started a couple of years ago. And some of the biggest, I guess, fears were, like, the security around it, the safety. Because, you know, your money, you're putting your money in it, and you can't go to a physical location to talk to anyone or anything. And the more and more you learn about it...at first, I was terrified of it because you couldn't go talk to someone. But the more and more I learned about it, I was like, oh, there's so much security around it. In your role, what does that look like for you? Because you have such a huge impact with people's money. So, how do you overcome that fear that people have?

+ +

RISHI: There's, I think, a number of steps that kind of go into it. And, you know, in 2023, it's certainly a little bit easier than it used to be. But, you know, very similar, I've had the same questions, you know, and concerns that you're describing. And I remember using one of the first banks that was essentially all digital and kind of wondering, you know, where is my money going? What happens if something goes wrong? And all of those types of things.

+ +

And so, I think there is kind of a number of different aspects that go into it. One is, you know, obviously, the technical aspects of security, you know, when you put your credit card number in on the internet, you know, is it encrypted? You know, is it over, you know, TLS? What's happening there? You know, how safe and secure is all that kind of thing?

+ +

You know, at this point, pretty much everyone, at least in the U.S., has been affected by credit card breaches, huge companies like Home Depot and Target that got cards accessed or, you know, just even the smaller companies when you're buying something random from maybe something...a smaller website on the internet. You know, that's all a little bit better now. So, I think what you have there was just kind of a little bit of becoming comfortable with what exists now.

+ +

The other aspect, though, I think, then comes into, well, what happens when something goes wrong? And I think there's a number of aspects that are super helpful for that. I think the liability aspect of credit card, you know, companies saying, you know, and the banks "You're not liable for a fraudulent transaction," I think that was a very big and important step that really helps with that.

+ +

And on top of that, then I think when you have stuff like the FDIC, you know, and insurance in the U.S., you know, that is government-backed that says, you know what? Even if this is an online-only digital bank, you're safe. You're protected. The government's got your back in that regard. And we're going to make sure that's covered. At Varo, that's one of the key things that we think about a lot because we are a bank.

+ +

Now, most FinTechs, actually, aren't banks, right? They partner with other third-party banks to provide their financial services. Whereas at Varo, we are federally regulated. And so, we have the full FDIC protection. We get the benefits of that. But it also means that we deal with the regulation aspects and being able to prove that we are safe and secure and show the regulators that we're doing the right things for our customers.

+ +

And I think that's huge and important because, obviously, it's safety for customers. But then it changes how you begin to think about how you're designing products, and how you're [inaudible 13:34] them, and, you know, how you're marketing them. Are we making a mobile app that shows that we're safe, and secure, and stable? Or are we doing this [inaudible 13:42] thing of moving too fast and breaking things?

+ +

When it's people's money, you have to be very, very dialed into that. You still have to be able to move fast, but you have to show the protection and the safety that people have because it is impactful to their lives. And so, I think from the FinTech perspective, that's a shift that's been happening over the last couple of years to continue that.

+ +

The last thing I'll say, too, is that part of it has just come from technology itself and the comfort there. It used to be that people who were buying, you know, items on the internet were more the exception rather than the rule. And now with Amazon, with Shopify, with all the other stuff that's out there, like, it's much more than a norm. And so, all of that just adds that level of comfort that says, I know I'm doing the right things as a consumer, that I'm protected. If I, you know, do have problems, my bank's got my back. The government is watching out for what's happening and trying to do what they can do to regulate all of that.

+ +

So, I think all of that has combined to get to that point where we can do much more of our banking online and safely. And I think that's a pretty fantastic thing when it comes to what customers get from that. I am old enough that I remember having to figure out times to get to the bank because they're open nine to five, and, you know, I have to deposit my paycheck. And, you know, I work nine to five, and maybe more hours pass, and I had no idea when I can go get that submitted.

+ +

And now, when I have to deposit something, I can just take a picture with my phone, and it safely makes it to my account. So, I think the convenience that we have now is really amazing, but it has certainly taken some time. And I think a number of different industry and commercial players kind of come together and make that happen.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: I appreciate that perspective on approaching security from the user experience of wanting safety. And I'm curious if we can talk in contrast from that experience to the developer experience with security. And how do you, as a new leader in this financial product company, prioritize security and introduce it from a, like, building a safety culture perspective?

+ +

RISHI: I think you just said that very eloquently. It is a safety culture. And cultural changes are hard. And I think for quite some time in the developer industry, security was either an afterthought or somebody else's problem. You know, it's the security team that has to think about it. It's, you know, and even these days, it's the red team that's going to go, you know, find these answers or whatever I'm shipping as a developer. My only thing to focus on is how fast I can ship, or, you know, what I'm shipping, rather than how secure is what I'm shipping.

+ +

And so, I think to really be effective at that, it is a cultural shift. You have to think and talk about security from the outset. And you have to bake those processes into how you build product. Those security conversations really do need to start at the design phase. And, you know, thinking about a mobile app for a bank as an example, you know, it starts when you're just thinking about the different screens on a mobile app that people are going to go through. How are people interpreting this? You know, what is the [inaudible 17:23], and the feeling, and the emotions, that we're building towards? You know, is that safe and secure or, you know, is it not?

+ +

But then it starts getting to the architecture and the design of the systems themselves to say, well, here's how they're going to enter information, here's how we're passing this back and forth. And especially in a world where a lot of software isn't just 100% in-house, but we're calling other partners for that, you know, be it, you know, infrastructure or risk, you know, or compliance, or whatever else it may be, how are we protecting people's data? How are we making sure our third parties are protecting people's data? You know, how are we encrypting it? How are we thinking about their safety all the way through?

+ +

Again, even all the way down to the individual developer that's writing code, how are we verifying they're writing good, high-quality, secure code? Part of it is training, part of it is culture, part of it is using good tooling around that to be able to make sure and say, when humans make mistakes because we are all human and we all will make mistakes, how are we catching that?

+ +

What are the layers do we have to make sure that if a mistake does happen, we either catch it before it happens or, you know, we have defense in depth such that that mistake in and of itself isn't enough to cause a, you know, compromise or a problem for our customers? So, I think it starts right from the start. And then, every kind of step along the way for delivering value for customers, also let's add that security and privacy and compliance perspective in there as well.

+ +

VICTORIA: Yes, I agree. And I don't want to work for a company where if I make a small human mistake, I'm going to potentially cost someone tens or however many thousands of dollars. [laughs]

+ +

WILL: I have a question around that. How, as a leader, how does that affect you day to day? Because I feel like there's some companies, maybe thoughtbot, maybe other companies, that a decision is not as critical as working as a bank. So, you, as a leader, how do you handle that?

+ +

RISHI: There's a couple of things I try and consider in any given big or important decision I have to make, the aspects around, like, you know, the context, what the decision is, and that type of stuff. But from a higher level, there's kind of two things I try and keep in mind. And when I say keep in mind, like, when it's a big, impactful decision, I will actually go through the steps of, you know, writing it down or talking this out loud, sometimes by myself, sometimes with others, just, again, to make sure we are actually getting to the meat of it.

+ +

But the first thing I'm trying to think of is kind of the Amazon idea of one-way versus two-way doors. If we make this decision and this is the wrong decision, what are the ramifications of that? You know, is it super easy to undo and there's very little risk with it? Or is it once we've made this decision or the negative outcome of this decision has happened, is it unfixable to a certain degree?

+ +

You know, and that is a good reminder in my head to make sure that, you know, A, I am considering it deeply. And that, B, if it is something where the ramifications, you know, are super huge, that you do take the time, and you do the legwork necessary to make sure you're making a good, valid decision, you know, based on the data, based on the risks involved and that there's a deep understanding of the problem there.

+ +

The second thing I try to think of is our customers. So, at Varo, our customers aren't who most banks target. A lot of banks want you to take all your money, put it in there, and they're going to loan that money out to make their money. And Varo is not that type of bank, and we focus on a pretty different segment of the market. What that means is our customers need their money. They need it safely and reliably, and it needs to be accurate when they have it.

+ +

And what I mean by that is, you know, frequently, our customers may not have, you know, hundreds or a thousand dollars worth of float in their bank accounts. So, if they're going and they're buying groceries and they can't because there's an error on our side because we're down, and because the transactions haven't settled, then that is very, very impactful to them, you know, as an individual.

+ +

And I think about that with most of these decisions because being in software and being in engineering I am fortunate enough that I'm not necessarily experiencing the same economic struggles that our customers may have. And so, that reminder helps me to think about it from their perspective. In addition, I also like to try and think of it from the perspective...from my mom, actually, who, you know, she is retired age. She's a teacher. She's non-technical.

+ +

And so, I think about her because I'd say, okay, when we're making a product or a design decision, how easy is it for her to understand? And my biases when I think about that, really kind of come into focus when I think about how she would interpret things. Because, you know, again, for me, I'm in tech. I think about things, you know, very analytically. And I just have a ton of experience across the industry, which she doesn't have. So, even something as simple as a little bit of copy for a page that makes a ton of sense to me, when I think about how she would interpret it, it's frequently wildly different.

+ +

And so, all of those things, I think, kind of come together to help make a very strong and informed decision in these types of situations where the negative outcomes really do matter. But you are, you know, as Varo is, you're a startup. And you do need to be able to build more products quickly because our customers have needs that aren't being met by the existing banking industry. And so, we need to provide value to them so that their lives are a bit better.

+ +

VICTORIA: I love that focus on a specific market segment and their needs and solving for that problem. And we know that if you're at a certain income level, it's more expensive [laughs] because of the overdraft fees and other things that can cause you problems. So, I really appreciate that that's the mission at Varo, and that's who you're focusing on to create a better banking product that makes more sense.

+ +

I'm curious if there were any surprises and challenges that you could share from that discovery process and finding out, you know, exactly what were those things where your mom was, like, uh, actually, I need something completely different. [laughs]

+ +

RISHI: Yeah, so, [chuckles] I'm chuckling because, you know, it's not, like, a single kind of time or event. It's, you know, definitely an ongoing process. But, you know, as actually, we were talking, you know, about earlier in terms of being kind of comfortable with doing things digital and online, that in and of itself is something that even in 2023, my mom isn't as comfortable or as confident as, you know, say, maybe the three of us are.

+ +

As an example, when sending money, you know, kind of like a peer-to-peer basis, like, if I'm sending my mom a little bit of money, or she's sending me something, you're kind of within the family. Things that I would think would be kind of very easy and straightforward actually do cause her a little bit more concern. Okay, I'm entering my debit card number into this so that it can get, you know, the cash transferred into my bank account. You know, again, for me, it didn't even cross my mind, actually, that that would be something uncomfortable. But for my mom, that was something where she actually had some concerns about it and was messaging me.

+ +

Her kind of personal point of view on that was, I would rather use a credit card for this and get the money on a credit card instead of a debit card because the debit card is linked to a bank account, and the security around that needs to be, you know, much tighter. And so, it made her more uncomfortable entering that on her phone. Whereas even a credit card it would have given her a little bit more peace of mind simply because it wasn't directly tied to her bank account.

+ +

So, that's just, you know, the most recent example. I mean, honestly, that was earlier today, but it's something I hadn't thought of. And, again, for most of our customers, maybe that's not the case and how they think. But for folks that are at that retirement age, you know, in a world where there are constant barrages of scam, you know, emails, and phone calls, and text messages going around, the concern was definitely there.

+ +

VICTORIA: That happened to me. Last week, I was on vacation with my family, and we needed to pay my mom for the house we'd rented. And I had to teach her how to use Zelle and set up Zelle. [laughter] It was a week-long process. But we got there, and it works [laughs] now. But yeah, it's interesting what concerns they have. And the funny part about it was that my sister-in-law happens to be, like, a lawyer who prevents class action lawsuits at a major bank. And she reassured us that it was, in fact, secure. [laughs]

+ +

I think it's interesting thinking about that user experience for security. And I'm curious, again, like, compare again with the developer experience and using security toolings. And I wonder if you had any top recommendations on tools that make the developer experience a little more comfortable and feeling like you're deploying with security in mind.

+ +

RISHI: That, in particular, is a bit of a hard question to answer. I try and stay away from specific vendors when it comes to that because I think a lot of it is contextual. But I could definitely talk through, like, some of the tools that I use and the way I like to think about it, especially from the developer perspective.

+ +

I think, first off, consider what aspect of the software development, you know, lifecycle you're in. If you are an engineer writing, you know, mostly application code and dealing with building product and features and stuff like that, start from that angle. I could even take a step back and say security as an industry is very, very wide at this point. There is somebody trying to sell you a tool for basically every step in the SDLC process, and honestly, before and after to [inaudible 26:23]. I would even almost say it's, to some extent, kind of information and vendor overload in a lot of ways.

+ +

So, I think what's important is to think about what your particular aspect of that is. Again, as an application engineer, or if you're building cloud infrastructure, or if you're an SRE, you know, or a platform team, kind of depending on what you are, your tooling will be different. The concepts are all kind of similar ideas, but how you go about what you build will be different.

+ +

In general, I like to say, from the app side of things, A, start with considering the code you're writing. And that's a little bit cultural, but it's also kind of more training. Are you writing code with a security mindset? are you designing systems with a security mindset? These aren't things that are typically taught, you know, in school if you go get a CS degree, or even in a lot of companies in terms of the things that you should be thinking about. So, A, start from there.

+ +

And if you don't feel like you think about, you know, is this design secure? Have we done, you know, threat modeling on it? Are we considering all of the error paths or the negative ways people can break the system? Then, start from that and start going through some of the security training that exists out there. And there's a lot of different aspects or avenues by which you can get that to be able to say, like, okay, I know I'm at least thinking about the code I write with a security mindset, even if you haven't actually changed anything about the code you're writing yet.

+ +

What I actually think is really helpful for a lot of engineers is to have them try and break things. It's why I like to compete in CTFs, but it's also why I like to have my engineers do the same types of things. Trying to break software is both really insightful from the aspect that you don't get when you're just writing code and shipping it because it's not something you have time to do, but it's also a great way to build up some of the skills that you need to then protect against.

+ +

And there's a lot of good, you know, cyber ranges out there. There's lots of good, just intentionally vulnerable applications that you can find on GitHub but that you can just run, you know, locally even on your machine and say, okay, now I have a little web app stood up. I know this is vulnerable. What do I do? How do I go and break it? Because then all of a sudden, the code that you're writing you start to think about a little bit differently.

+ +

It's not just about how am I solving this product problem or this development problem? But it's, how am I doing this in a way that is safe and secure? Again, as an application side of things, you know, just make sure you know the OWASP Top 10 inside and out. Those are the most basic things a lot of engineers miss. And it only takes, again, one miss for it to be critical. So, start reviewing it.

+ +

And then, you start to think about the tooling aspect of it. People are human. We're going to make mistakes. So, how do we use the power of technology to be able to stop this? You know, and there is static scanning tools. Like, there's a whole bunch of different ones out there. You know, Semgrep is a great one that's open source just to get started with that can help you find the vulnerable code that may exist there.

+ +

Consider the SQL queries that you're writing, and most importantly, how you're writing them. You know, are you taking user input and just chucking it in there, or are you sanitizing it? When I ask these questions, for a lot of engineers, it's not usually yes or no. It's much more of an, well, I don't know. Because in software, we do a really good job of writing abstraction layers. But that also means, you know, to some extent, there may be a little bit of magic in there, or a lack thereof of magic that you don't necessarily know about.

+ +

And so, you have to be able to dive into the libraries. You have to know what you're doing to even be able to say something like, oh no, this SQL query is safe from this user input because we have sanitized it. We have, you know, done a prepared statement, whatever it may be. Or, no, actually, we are just doing something here that's been vulnerable, and we didn't realize we were, and so now that's something we have to address.

+ +

So, I think, like, that aspect in and of itself, which isn't, you know, a crazy ton of things. It's not spending a ton of money on different tools. But it's just internalizing the fact that you start to think a little bit differently. It provides a ton of value.

+ +

The last thing on that, too, is to be able to say, especially if you're coming from a development side, or even just from a founder or a startup side of things, what are my big risks? What do I need to take care of first? What are the giant holes or flaws? You know, and what is my threat model around that?

+ +

Obviously, as a bank, you have to care very deeply right from the start. You know, if you're not a bank, if you're not dealing with financial transactions, or PII, or anything like that, there are some things that you can deal with a little bit later. So, you have to know your industry, and you have to know what people are trying to do and the threat models and the threat vectors that can exist based on where you are.

+ +

WILL: That's amazing. You know, earlier, we talked about you being an engineer for 20 years, different areas, and stuff like that. Do you have any advice for engineers that are starting out right now? And, you know, from probably year one to year, you know, anything under ten years of experience, do you have any advice that you usually give engineers when you're chatting with them?

+ +

RISHI: The advice I tend to give people who are just starting out is be the type of person that asks, "How does this work?" Or "Why does this work?" And then do the work to figure out the answer. Maybe it is talking to someone; maybe it's diving into the details; maybe it's reading a book in some aspect that you haven't had much exposure to.

+ +

When I look at my career and when I look at the careers of folks around me and the people that I've seen be most successful, both in engineering but also on the business side, that desire to know why something is the case is I think, one of the biggest things that determines success. And then the ability to answer that question by putting in the right types of work, the right types of scientific method and processes and such, are the other factor. So, to me, that's what I try and get across to people.

+ +

I say that mostly to junior folks because I think when you're getting started, it's really difficult. There's a ton out there. And we've, again, as software engineers, and hardware engineers, and cloud, and all this kind of stuff, done a pretty good job of building a ton of abstraction layers. All of our abstraction layers [inaudible 32:28] to some degree.

+ +

You know, so as you start, you know, writing a bunch of code, you start finding a bunch of bugs that you don't necessarily know how to solve and that don't make any sense in the avenue that you've been exposed to. But as soon as you get into the next layer, you understand how that works begin to make a lot more sense. So, I think being comfortable with saying, "I have no idea why this is the case, but I'm going to go find out," makes the biggest difference for people just starting out their career.

+ +

WILL: I love that advice. Not too long ago, my manager encouraged me to write a blog post on something that I thought that I really knew. And when I started writing that blog post, I was like, oh boy, I have no idea. I know how to do it, but I don't know the why behind it. And so, I was very thankful that he encouraged me to write a blog post on it. Because once you start explaining it to other people, I feel you really have to know the whys. And so, I love that advice. That's really good advice.

+ +

VICTORIA: Me too. And it makes sense with what we see statistically as well in the DORA research. The DevOps Research Association publishes a survey every year, the State of DevOps Report. And one of the biggest findings I remember from last year's was that the most secure and reliable systems have the most open communication and high trust among the teams. And so, being able to have that curiosity as a junior developer, you need to be in an environment where you can feel comfortable asking questions [laughs], and you can approach different people, and you're encouraged to make those connections and write blog posts like Will was saying.

+ +

RISHI: Absolutely, absolutely. I think you touched on something very important there as well. The psychological safety really makes a big difference. And I think that's critical for, again, like, folks especially earlier in their career or have recently transitioned to tech, or whatever the case may be. Because asking "Why?" should be something that excites people, and there are companies where that's not necessarily the case, right? Where you asking why, it seems to be viewed as a sign that you don't know something, and therefore, you're not as good as what you should be, you know, the level you should be at or for whatever they expect.

+ +

But I do think that's the wrong attitude. I think the more people ask why, the more people are able and comfortable to be able to say, "I don't know, but I'm going to go find out," and then being able to be successful with that makes way better systems. It makes way safer and more secure systems. And, honestly, I think it makes humans, in general, better humans because we can do that.

+ +

VICTORIA: I think that's a great note to start to wrap up on. Is there any questions that you have for me or Will?

+ +

RISHI: Yeah. I would love to hear from both of you as to what you see; with the experiences that you have and what you do, the biggest impediments or speed bumps are when it comes to developers being able to write and ship secure code.

+ +

VICTORIA: When we're talking with new clients, it depends on where they are in really the adoption of their product and the maturity of their organization. Some early founders really have no technology experience. They have never managed an IT organization. You know, setting up basic employee account access and IDs is some of the initial steps you have to take to really get to where you can do identity management, and permissions management, and all the things that are really table stakes for security.

+ +

And then others have some progress, and they have a fair amount of data. And maybe it's in that situation, like you said before, where it's really a trade-off between the cost and benefit of making those changes to a more secure, more best practice in the cloud or in their CI/CD pipeline or wherever it may be.

+ +

And then, when you're a larger organization, and you have to make the trade-offs between all of that, and how it's impacting your developer experience, and how long are those deployed times now. And you might get fewer rates of errors and fewer rates of security vulnerabilities. But if it's taking three hours for your deployments to go out [laughs] because there's so many people, and there's so many checks to go through, then you have to consider where you can make some cuts and where there might be more efficiencies to be gained.

+ +

So, it's really interesting. Everyone's on a different point in their journey. And starting with the basics, like you said, I love that you brought up the OWASP Top 10. We've been adopting the CIS Controls and just doing a basic internal security audit ourselves to get more ready and to be in a position where...

+ +

What I'm familiar with as well from working in federal agencies, consulting, maintaining some of the older security frameworks can be a really high cost, not only in terms of auditing fees but what it impacts to your organization to, like, maintain those things [laughs] and the documentation required. And how do you do that in an agile way, in a way that really focuses on addressing the actual purpose of the requirements over needing to check a box? And how do we replicate that for our clients as well?

+ +

RISHI: That is super helpful. And I think the checkbox aspect that you just discussed I think is key. It's a difficult position to be in when there are boxes that you have to check and don't necessarily actually add value when it comes to security or compliance or, you know, a decrease in risk for the company. And I think that one of the challenges industry-wide has always been that security and compliance in and of itself tends to move a little bit slower from a blue team or a protection perspective than the rest of the industry.

+ +

And so, I mean, I can think of, you know, audits that I've been in where, you know, just even the fact that things were cloud-hosted just didn't make sense to the auditors. And it was a struggle to get them to understand that, you know, there is shared responsibility, and this kind of stuff exists, and AWS is taking care of some things, and we're taking care of some other things when they've just been developed with this on-premise kind of mentality.

+ +

That is one of the big challenges that still exists kind of across the board is making sure that the security work that you're doing adds security value, adds business value. It isn't just checking the box for the sake of checking the box, even when that's sometimes necessary.

+ +

VICTORIA: I am a pro box checker.

+ +

RISHI: [laughs]

+ +

VICTORIA: Like, I'll get the box checked. I'll use Trello and Confluence and any other tool besides Excel to do it, too. We'll make it happen with less pain, but I'd rather not do it [laughs] if we don't have to.

+ +

RISHI: [laughs]

+ +

VICTORIA: Let's make it easy. No, I love it. Is there anything else that you want to promote?

+ +

RISHI: No, I don't think there's anything else I want to promote other than I'm going to go back to what I said just earlier, like, that culture. And if, you know, folks are out there and you have junior engineers, you have engineers that are asking "Why?", you have people that just want to do the right thing and get better, lean into that. Double down on those types of folks. Those are the ones that are going to make big differences in what you do as a business, and do what you can to help them out. I think that is something we don't see enough of in the industry still. And I would love for that to change.

+ +

VICTORIA: I love that. Thank you so much, Rishi, for joining us.

+ +

RISHI: Thanks for having me. This was a great conversation. I appreciate the time.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Rishi Malik.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Victoria and Will interview Rishi Malik, the Founder of Backstop.it and VP of Engineering at Varo Bank. They talk about Rishi's recent adventure at DEF CON, the renowned annual security conference that he's attended for six years, and describes how it has transformed from a mere learning experience into a thrilling competition for him and his team. The conference = their playground for tackling an array of security challenges and brain-teasing puzzles, with a primary focus on cloud security competitions.

+ +

They talk about the significance of community in such events and how problem-solving through interaction adds value. Rishi shares his background, tracing his path from firmware development through various tech companies to his current roles in security and engineering management.

+ +

The vital topic of security in the fintech and banking sector highlights the initial concerns people had when online banking emerged. Rishi navigates through the technical intricacies of security measures, liability protection, and the regulatory framework that safeguards online banking for consumers. He also highlights the evolving landscape, where technological advancements and convenience have bolstered consumer confidence in online banking.

+ +

Rishi shares his unique approach to leadership and decision-making, and pearls of wisdom for budding engineers starting their careers. His advice revolves around nurturing curiosity and relentlessly seeking to understand the "why" behind systems and processes.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Rishi Malik, Founder of Backstop.it and VP of Engineering at Varo Bank. Rishi, thank you for joining us.

+ +

RISHI: Thanks for having me. I'm excited to be here.

+ +

VICTORIA: Yes, Rishi. I'm so excited to talk with you today about your security background and get into your role at Varo and Backstop IT. But first, I wanted to hear a little bit more about your recent experience attending DEF CON. How was that?

+ +

RISHI: It was awesome. I do have quite the background in security at this point. And one of the things I started doing early on, as I was getting up to speed and learning more about the security-specific side of things, was beginning to attend DEF CON itself. So, I've now gone six years straight.

+ +

And it started out as just kind of experiencing the conference and security and meeting folks. But it's progressed to where I now bring a team of people where we go and we compete. We have a good time. But we do get to kind of bring the security side of things into the software engineering and engineering leadership stuff that we all do on a day-to-day basis.

+ +

VICTORIA: Yeah. And what kind of puzzles do you solve with your team when you attend DEF CON?

+ +

RISHI: There's definitely a lot of variety there, which I think is part of the fun. So, DEF CON frequently has electronic badges, you know, with random puzzles on there that you have to solve. Some of it are cryptographic. Some of them are kind of random cultural things. Sometimes there's music challenges based around it. Sometimes, it's social and interactive. And you have to go find the right type of badge or the right person behind it to unlock something. So, all of those, you know, typically exist and are a ton of fun.

+ +

Primarily, in the last few years, we've been focusing more on the cloud CTF. So, in this case, it's our team competing against other teams and really focused on cloud security. So, it's, you know, figuring out vulnerabilities in, you know, specially designed puzzles around AWS and GCP, the application side of things as well, and competing to see how well you can do.

+ +

Three years ago, the last couple of years, we've not won it, but we've been pretty competitive. And the great thing is the field is expanding as more and more people get into CTF themselves but, more importantly, into cloud infrastructure and cloud knowledge there. So, it's just great to see that expansion and see what people are into, what people are learning, and how challenging some of these things can be.

+ +

VICTORIA: I love the idea of having a puzzle at a conference where you have to find a specific person to solve it. And yeah, I'm always interested in ways where we can have these events where you're getting together and building community and growing expertise in a field but in a way that makes it fun [laughs] and isn't just life-draining long, like, talks about random stuff.

+ +

RISHI: [laughs] I think what you're touching on there is crucial. And you said the word community, and, to me, that is, you know, a big part of what DEF CON and, you know, hacking and security culture is. But it is, I think, one of the things that kind of outside of this, we tend to miss it more, you know, specifically, like, focused conferences. It is more about kind of the content, you know, the hallway track is always a thing. But it's less intentional than I personally, at this stage, really prefer, you know. So, I do like those things where it is encouraging interaction.

+ +

For me, I'd rather go to happy hour with some people who are really well versed in the subject that they're in rather than even necessarily listening to a talk from them on what they're doing. Simply because I think the community aspect, the social aspect, actually gets you more of the information that is more relevant to what you're doing on a day-to-day basis than just consuming it passively.

+ +

VICTORIA: I agree because consuming it passively or even intentionally remotely, there are things that you didn't even think to think about [laughs] that aren't going to come up just on your own. You have to have another person there who's...Actually, I have a good friend who's co-working with me this week who's at Ticketmaster. And so, just hearing about some of the problems they have and issues there has been entertaining for me. So yeah, I love that about DEF CON, and I love hearing about community stories and fun ways that companies can get a benefit out of coming together and just putting good content out there.

+ +

RISHI: Absolutely. I think problem-solving is where you get the most value out of it as a company and as a business.

+ +

VICTORIA: Yeah, maybe that's a good segue to tell me a little bit more about your background and how you came to be where you are today.

+ +

RISHI: Yeah. For me growing up, I was always that problem-solver type of person. So, I think that's what kind of naturally gravitated me towards tech and, you know, hardware and software engineering. You know, so, for me, I go back quite a while. I'd been doing a lot of development, you know, in the early days of my career.

+ +

I started out doing firmware development back in the days of large tape libraries, right? So, if you think about, like, big businesses back before cloud was a big thing and even back before SSDs were a thing, you know, it was all spinning disks. It was all tape. And that's kind of the area that I started in. So, I was working on robots that actually move tapes around these giant tape libraries that are, you know, taller than I am that you can walk inside of because they're so big, for big corporations to be able to backup their data on an overnight basis. You have to do that kind of stuff.

+ +

Then I started going into smaller and smaller companies, into web tech, into startups, then into venture-backed startups. And then, eventually, I started my own company and did that for a while. All of this is really just kind of, you know, software engineering in a nutshell, lots of different languages, lots of different technologies. But really, from the standpoint of, here's a whole bunch of hard problems that need to be solved. Let's figure out how we can do that and how we can make some money by solving some of these problems.

+ +

That eventually kind of led me down the security path as well and the engineering management side of things, which is what I do now, both at Backstop...is a security consulting business and being VP of Engineering at Varo Bank.

+ +

WILL: How was your journey? Because you started as an intern in 2003.

+ +

RISHI: [laughs]

+ +

WILL: And then, you know, 20 years later. So, how was your journey through all of that? [laughs]

+ +

RISHI: [laughs] You know, I hadn't actually put it together that it has been 20 years this year until you said that. So, that's awesome. It's been a blast, you know. I can honestly say it's been wildly different than what I imagined 20 years ago and interesting in different ways. I think I'm very fortunate to be able to say that.

+ +

When I started out as an intern in 2003, technologies were very different. I was doing some intern shifts with the federal government, you know, so the pace was wildly different. And when I think of where technology has come now, and where the industry has gone, and what I get to do on a day-to-day basis, I'm kind of just almost speechless at just how far we've come in 20 years, how easy some things are, how remarkably hard some other things are that should honestly be easy at this point, but just the things that we can do.

+ +

I'm old enough that I remember cell phones being a thing and then smartphones coming out and playing with them and being like, yeah, this is kind of mediocre. I don't really know why people would want this. And the iPhone coming out and just changing the game and being like, okay, now I get it. You know, to the experience of the internet and, you know, mobile data and everywhere. It's just phenomenal the advances that we've had in the last 20 years. And it makes me excited for the next 20 years to see what we can do as we go forward.

+ +

VICTORIA: I'm going to take personal offense to someone knowing that technology being too old [laughs], but, yeah, because it really wasn't that long ago. And I think one thing I always think about having a background in civic tech and in financial tech as well is that the future is here; it's just not evenly distributed. So, now, if you're building a new company, of course, the default is to go straight to the cloud.

+ +

But many companies and organizations that have been around for 60-80 years and using the internet right when it first came out are still in really old technologies that just simply work. And maybe they're not totally sure why, and change is difficult and slow. So, I wonder if you have any experience that you can take from the banking or fintech industry on how to make the most out of modern security and compliance platforms.

+ +

RISHI: Yeah, you know, I think most people in tech especially...and the gray hairs on me are saying the younger folks in tech especially don't realize just how much older technologies still exist and will exist for quite some time.

+ +

When you think of banking itself, you know, most of the major companies that you can think of, you know, in the U.S. especially but kind of across the world that are the top tier names of banks, and networks, and stuff like that, still run mainframes. When you swipe your credit card, there's a very good chance that is processed on a mainframe. And that's not a bad thing. But it's just, you know when you talk to younger engineers, it's not something that kind of crosses their mind. They feel like it is old-tech.

+ +

The bulk of businesses don't actually run on the cloud. Having been through it, I've racked and stacked servers and had to figure out how to physically take hardware across, you know, country borders and things like those lines. And now, when I do want to spin up a server somewhere else, it's just a different AWS region. So, it's remarkably easy, at this point, to solve a lot of those problems.

+ +

But once you're up and live and you have customers, you know, where downtime is impactful or, you know, the cost of moving to the cloud or modernizing your technology is substantial, things tend to move a lot slower. And I think you see that, especially when it comes to security, because we have more modern movements like DevOps bringing security into it. And with a lot of the, you know, the modern security and compliance platforms that exist, they work very, very well for what they do, especially when you're a startup or your whole tech stack is modernized.

+ +

The biggest challenges, I think, seem to come in when you have that hybrid aspect of it. You do have some cloud infrastructure you have to secure. You do have some physical data centers you have to secure. You have something that is, you know, on-premise in your office. You have something that is co [inaudible 10:01] somewhere else. Or you also have to deal with stuff like, you know, much less modern tech, you know, when it comes to mainframes and security and kind of being responsible for all of that.

+ +

And I think that is a big challenge because security is one of those things where it's, you know, if you think of your house, you can have the strongest locks on your door and everything else like that. But if you have one weak point, you have a window that's left open, that's all it takes. And so, it has to be all-inclusive and holistic. And I think that is remarkably hard to do well, even despite where technology has come to these days.

+ +

WILL: Speaking of securities, I remember when the Internet banking started a couple of years ago. And some of the biggest, I guess, fears were, like, the security around it, the safety. Because, you know, your money, you're putting your money in it, and you can't go to a physical location to talk to anyone or anything. And the more and more you learn about it...at first, I was terrified of it because you couldn't go talk to someone. But the more and more I learned about it, I was like, oh, there's so much security around it. In your role, what does that look like for you? Because you have such a huge impact with people's money. So, how do you overcome that fear that people have?

+ +

RISHI: There's, I think, a number of steps that kind of go into it. And, you know, in 2023, it's certainly a little bit easier than it used to be. But, you know, very similar, I've had the same questions, you know, and concerns that you're describing. And I remember using one of the first banks that was essentially all digital and kind of wondering, you know, where is my money going? What happens if something goes wrong? And all of those types of things.

+ +

And so, I think there is kind of a number of different aspects that go into it. One is, you know, obviously, the technical aspects of security, you know, when you put your credit card number in on the internet, you know, is it encrypted? You know, is it over, you know, TLS? What's happening there? You know, how safe and secure is all that kind of thing?

+ +

You know, at this point, pretty much everyone, at least in the U.S., has been affected by credit card breaches, huge companies like Home Depot and Target that got cards accessed or, you know, just even the smaller companies when you're buying something random from maybe something...a smaller website on the internet. You know, that's all a little bit better now. So, I think what you have there was just kind of a little bit of becoming comfortable with what exists now.

+ +

The other aspect, though, I think, then comes into, well, what happens when something goes wrong? And I think there's a number of aspects that are super helpful for that. I think the liability aspect of credit card, you know, companies saying, you know, and the banks "You're not liable for a fraudulent transaction," I think that was a very big and important step that really helps with that.

+ +

And on top of that, then I think when you have stuff like the FDIC, you know, and insurance in the U.S., you know, that is government-backed that says, you know what? Even if this is an online-only digital bank, you're safe. You're protected. The government's got your back in that regard. And we're going to make sure that's covered. At Varo, that's one of the key things that we think about a lot because we are a bank.

+ +

Now, most FinTechs, actually, aren't banks, right? They partner with other third-party banks to provide their financial services. Whereas at Varo, we are federally regulated. And so, we have the full FDIC protection. We get the benefits of that. But it also means that we deal with the regulation aspects and being able to prove that we are safe and secure and show the regulators that we're doing the right things for our customers.

+ +

And I think that's huge and important because, obviously, it's safety for customers. But then it changes how you begin to think about how you're designing products, and how you're [inaudible 13:34] them, and, you know, how you're marketing them. Are we making a mobile app that shows that we're safe, and secure, and stable? Or are we doing this [inaudible 13:42] thing of moving too fast and breaking things?

+ +

When it's people's money, you have to be very, very dialed into that. You still have to be able to move fast, but you have to show the protection and the safety that people have because it is impactful to their lives. And so, I think from the FinTech perspective, that's a shift that's been happening over the last couple of years to continue that.

+ +

The last thing I'll say, too, is that part of it has just come from technology itself and the comfort there. It used to be that people who were buying, you know, items on the internet were more the exception rather than the rule. And now with Amazon, with Shopify, with all the other stuff that's out there, like, it's much more than a norm. And so, all of that just adds that level of comfort that says, I know I'm doing the right things as a consumer, that I'm protected. If I, you know, do have problems, my bank's got my back. The government is watching out for what's happening and trying to do what they can do to regulate all of that.

+ +

So, I think all of that has combined to get to that point where we can do much more of our banking online and safely. And I think that's a pretty fantastic thing when it comes to what customers get from that. I am old enough that I remember having to figure out times to get to the bank because they're open nine to five, and, you know, I have to deposit my paycheck. And, you know, I work nine to five, and maybe more hours pass, and I had no idea when I can go get that submitted.

+ +

And now, when I have to deposit something, I can just take a picture with my phone, and it safely makes it to my account. So, I think the convenience that we have now is really amazing, but it has certainly taken some time. And I think a number of different industry and commercial players kind of come together and make that happen.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: I appreciate that perspective on approaching security from the user experience of wanting safety. And I'm curious if we can talk in contrast from that experience to the developer experience with security. And how do you, as a new leader in this financial product company, prioritize security and introduce it from a, like, building a safety culture perspective?

+ +

RISHI: I think you just said that very eloquently. It is a safety culture. And cultural changes are hard. And I think for quite some time in the developer industry, security was either an afterthought or somebody else's problem. You know, it's the security team that has to think about it. It's, you know, and even these days, it's the red team that's going to go, you know, find these answers or whatever I'm shipping as a developer. My only thing to focus on is how fast I can ship, or, you know, what I'm shipping, rather than how secure is what I'm shipping.

+ +

And so, I think to really be effective at that, it is a cultural shift. You have to think and talk about security from the outset. And you have to bake those processes into how you build product. Those security conversations really do need to start at the design phase. And, you know, thinking about a mobile app for a bank as an example, you know, it starts when you're just thinking about the different screens on a mobile app that people are going to go through. How are people interpreting this? You know, what is the [inaudible 17:23], and the feeling, and the emotions, that we're building towards? You know, is that safe and secure or, you know, is it not?

+ +

But then it starts getting to the architecture and the design of the systems themselves to say, well, here's how they're going to enter information, here's how we're passing this back and forth. And especially in a world where a lot of software isn't just 100% in-house, but we're calling other partners for that, you know, be it, you know, infrastructure or risk, you know, or compliance, or whatever else it may be, how are we protecting people's data? How are we making sure our third parties are protecting people's data? You know, how are we encrypting it? How are we thinking about their safety all the way through?

+ +

Again, even all the way down to the individual developer that's writing code, how are we verifying they're writing good, high-quality, secure code? Part of it is training, part of it is culture, part of it is using good tooling around that to be able to make sure and say, when humans make mistakes because we are all human and we all will make mistakes, how are we catching that?

+ +

What are the layers do we have to make sure that if a mistake does happen, we either catch it before it happens or, you know, we have defense in depth such that that mistake in and of itself isn't enough to cause a, you know, compromise or a problem for our customers? So, I think it starts right from the start. And then, every kind of step along the way for delivering value for customers, also let's add that security and privacy and compliance perspective in there as well.

+ +

VICTORIA: Yes, I agree. And I don't want to work for a company where if I make a small human mistake, I'm going to potentially cost someone tens or however many thousands of dollars. [laughs]

+ +

WILL: I have a question around that. How, as a leader, how does that affect you day to day? Because I feel like there's some companies, maybe thoughtbot, maybe other companies, that a decision is not as critical as working as a bank. So, you, as a leader, how do you handle that?

+ +

RISHI: There's a couple of things I try and consider in any given big or important decision I have to make, the aspects around, like, you know, the context, what the decision is, and that type of stuff. But from a higher level, there's kind of two things I try and keep in mind. And when I say keep in mind, like, when it's a big, impactful decision, I will actually go through the steps of, you know, writing it down or talking this out loud, sometimes by myself, sometimes with others, just, again, to make sure we are actually getting to the meat of it.

+ +

But the first thing I'm trying to think of is kind of the Amazon idea of one-way versus two-way doors. If we make this decision and this is the wrong decision, what are the ramifications of that? You know, is it super easy to undo and there's very little risk with it? Or is it once we've made this decision or the negative outcome of this decision has happened, is it unfixable to a certain degree?

+ +

You know, and that is a good reminder in my head to make sure that, you know, A, I am considering it deeply. And that, B, if it is something where the ramifications, you know, are super huge, that you do take the time, and you do the legwork necessary to make sure you're making a good, valid decision, you know, based on the data, based on the risks involved and that there's a deep understanding of the problem there.

+ +

The second thing I try to think of is our customers. So, at Varo, our customers aren't who most banks target. A lot of banks want you to take all your money, put it in there, and they're going to loan that money out to make their money. And Varo is not that type of bank, and we focus on a pretty different segment of the market. What that means is our customers need their money. They need it safely and reliably, and it needs to be accurate when they have it.

+ +

And what I mean by that is, you know, frequently, our customers may not have, you know, hundreds or a thousand dollars worth of float in their bank accounts. So, if they're going and they're buying groceries and they can't because there's an error on our side because we're down, and because the transactions haven't settled, then that is very, very impactful to them, you know, as an individual.

+ +

And I think about that with most of these decisions because being in software and being in engineering I am fortunate enough that I'm not necessarily experiencing the same economic struggles that our customers may have. And so, that reminder helps me to think about it from their perspective. In addition, I also like to try and think of it from the perspective...from my mom, actually, who, you know, she is retired age. She's a teacher. She's non-technical.

+ +

And so, I think about her because I'd say, okay, when we're making a product or a design decision, how easy is it for her to understand? And my biases when I think about that, really kind of come into focus when I think about how she would interpret things. Because, you know, again, for me, I'm in tech. I think about things, you know, very analytically. And I just have a ton of experience across the industry, which she doesn't have. So, even something as simple as a little bit of copy for a page that makes a ton of sense to me, when I think about how she would interpret it, it's frequently wildly different.

+ +

And so, all of those things, I think, kind of come together to help make a very strong and informed decision in these types of situations where the negative outcomes really do matter. But you are, you know, as Varo is, you're a startup. And you do need to be able to build more products quickly because our customers have needs that aren't being met by the existing banking industry. And so, we need to provide value to them so that their lives are a bit better.

+ +

VICTORIA: I love that focus on a specific market segment and their needs and solving for that problem. And we know that if you're at a certain income level, it's more expensive [laughs] because of the overdraft fees and other things that can cause you problems. So, I really appreciate that that's the mission at Varo, and that's who you're focusing on to create a better banking product that makes more sense.

+ +

I'm curious if there were any surprises and challenges that you could share from that discovery process and finding out, you know, exactly what were those things where your mom was, like, uh, actually, I need something completely different. [laughs]

+ +

RISHI: Yeah, so, [chuckles] I'm chuckling because, you know, it's not, like, a single kind of time or event. It's, you know, definitely an ongoing process. But, you know, as actually, we were talking, you know, about earlier in terms of being kind of comfortable with doing things digital and online, that in and of itself is something that even in 2023, my mom isn't as comfortable or as confident as, you know, say, maybe the three of us are.

+ +

As an example, when sending money, you know, kind of like a peer-to-peer basis, like, if I'm sending my mom a little bit of money, or she's sending me something, you're kind of within the family. Things that I would think would be kind of very easy and straightforward actually do cause her a little bit more concern. Okay, I'm entering my debit card number into this so that it can get, you know, the cash transferred into my bank account. You know, again, for me, it didn't even cross my mind, actually, that that would be something uncomfortable. But for my mom, that was something where she actually had some concerns about it and was messaging me.

+ +

Her kind of personal point of view on that was, I would rather use a credit card for this and get the money on a credit card instead of a debit card because the debit card is linked to a bank account, and the security around that needs to be, you know, much tighter. And so, it made her more uncomfortable entering that on her phone. Whereas even a credit card it would have given her a little bit more peace of mind simply because it wasn't directly tied to her bank account.

+ +

So, that's just, you know, the most recent example. I mean, honestly, that was earlier today, but it's something I hadn't thought of. And, again, for most of our customers, maybe that's not the case and how they think. But for folks that are at that retirement age, you know, in a world where there are constant barrages of scam, you know, emails, and phone calls, and text messages going around, the concern was definitely there.

+ +

VICTORIA: That happened to me. Last week, I was on vacation with my family, and we needed to pay my mom for the house we'd rented. And I had to teach her how to use Zelle and set up Zelle. [laughter] It was a week-long process. But we got there, and it works [laughs] now. But yeah, it's interesting what concerns they have. And the funny part about it was that my sister-in-law happens to be, like, a lawyer who prevents class action lawsuits at a major bank. And she reassured us that it was, in fact, secure. [laughs]

+ +

I think it's interesting thinking about that user experience for security. And I'm curious, again, like, compare again with the developer experience and using security toolings. And I wonder if you had any top recommendations on tools that make the developer experience a little more comfortable and feeling like you're deploying with security in mind.

+ +

RISHI: That, in particular, is a bit of a hard question to answer. I try and stay away from specific vendors when it comes to that because I think a lot of it is contextual. But I could definitely talk through, like, some of the tools that I use and the way I like to think about it, especially from the developer perspective.

+ +

I think, first off, consider what aspect of the software development, you know, lifecycle you're in. If you are an engineer writing, you know, mostly application code and dealing with building product and features and stuff like that, start from that angle. I could even take a step back and say security as an industry is very, very wide at this point. There is somebody trying to sell you a tool for basically every step in the SDLC process, and honestly, before and after to [inaudible 26:23]. I would even almost say it's, to some extent, kind of information and vendor overload in a lot of ways.

+ +

So, I think what's important is to think about what your particular aspect of that is. Again, as an application engineer, or if you're building cloud infrastructure, or if you're an SRE, you know, or a platform team, kind of depending on what you are, your tooling will be different. The concepts are all kind of similar ideas, but how you go about what you build will be different.

+ +

In general, I like to say, from the app side of things, A, start with considering the code you're writing. And that's a little bit cultural, but it's also kind of more training. Are you writing code with a security mindset? are you designing systems with a security mindset? These aren't things that are typically taught, you know, in school if you go get a CS degree, or even in a lot of companies in terms of the things that you should be thinking about. So, A, start from there.

+ +

And if you don't feel like you think about, you know, is this design secure? Have we done, you know, threat modeling on it? Are we considering all of the error paths or the negative ways people can break the system? Then, start from that and start going through some of the security training that exists out there. And there's a lot of different aspects or avenues by which you can get that to be able to say, like, okay, I know I'm at least thinking about the code I write with a security mindset, even if you haven't actually changed anything about the code you're writing yet.

+ +

What I actually think is really helpful for a lot of engineers is to have them try and break things. It's why I like to compete in CTFs, but it's also why I like to have my engineers do the same types of things. Trying to break software is both really insightful from the aspect that you don't get when you're just writing code and shipping it because it's not something you have time to do, but it's also a great way to build up some of the skills that you need to then protect against.

+ +

And there's a lot of good, you know, cyber ranges out there. There's lots of good, just intentionally vulnerable applications that you can find on GitHub but that you can just run, you know, locally even on your machine and say, okay, now I have a little web app stood up. I know this is vulnerable. What do I do? How do I go and break it? Because then all of a sudden, the code that you're writing you start to think about a little bit differently.

+ +

It's not just about how am I solving this product problem or this development problem? But it's, how am I doing this in a way that is safe and secure? Again, as an application side of things, you know, just make sure you know the OWASP Top 10 inside and out. Those are the most basic things a lot of engineers miss. And it only takes, again, one miss for it to be critical. So, start reviewing it.

+ +

And then, you start to think about the tooling aspect of it. People are human. We're going to make mistakes. So, how do we use the power of technology to be able to stop this? You know, and there is static scanning tools. Like, there's a whole bunch of different ones out there. You know, Semgrep is a great one that's open source just to get started with that can help you find the vulnerable code that may exist there.

+ +

Consider the SQL queries that you're writing, and most importantly, how you're writing them. You know, are you taking user input and just chucking it in there, or are you sanitizing it? When I ask these questions, for a lot of engineers, it's not usually yes or no. It's much more of an, well, I don't know. Because in software, we do a really good job of writing abstraction layers. But that also means, you know, to some extent, there may be a little bit of magic in there, or a lack thereof of magic that you don't necessarily know about.

+ +

And so, you have to be able to dive into the libraries. You have to know what you're doing to even be able to say something like, oh no, this SQL query is safe from this user input because we have sanitized it. We have, you know, done a prepared statement, whatever it may be. Or, no, actually, we are just doing something here that's been vulnerable, and we didn't realize we were, and so now that's something we have to address.

+ +

So, I think, like, that aspect in and of itself, which isn't, you know, a crazy ton of things. It's not spending a ton of money on different tools. But it's just internalizing the fact that you start to think a little bit differently. It provides a ton of value.

+ +

The last thing on that, too, is to be able to say, especially if you're coming from a development side, or even just from a founder or a startup side of things, what are my big risks? What do I need to take care of first? What are the giant holes or flaws? You know, and what is my threat model around that?

+ +

Obviously, as a bank, you have to care very deeply right from the start. You know, if you're not a bank, if you're not dealing with financial transactions, or PII, or anything like that, there are some things that you can deal with a little bit later. So, you have to know your industry, and you have to know what people are trying to do and the threat models and the threat vectors that can exist based on where you are.

+ +

WILL: That's amazing. You know, earlier, we talked about you being an engineer for 20 years, different areas, and stuff like that. Do you have any advice for engineers that are starting out right now? And, you know, from probably year one to year, you know, anything under ten years of experience, do you have any advice that you usually give engineers when you're chatting with them?

+ +

RISHI: The advice I tend to give people who are just starting out is be the type of person that asks, "How does this work?" Or "Why does this work?" And then do the work to figure out the answer. Maybe it is talking to someone; maybe it's diving into the details; maybe it's reading a book in some aspect that you haven't had much exposure to.

+ +

When I look at my career and when I look at the careers of folks around me and the people that I've seen be most successful, both in engineering but also on the business side, that desire to know why something is the case is I think, one of the biggest things that determines success. And then the ability to answer that question by putting in the right types of work, the right types of scientific method and processes and such, are the other factor. So, to me, that's what I try and get across to people.

+ +

I say that mostly to junior folks because I think when you're getting started, it's really difficult. There's a ton out there. And we've, again, as software engineers, and hardware engineers, and cloud, and all this kind of stuff, done a pretty good job of building a ton of abstraction layers. All of our abstraction layers [inaudible 32:28] to some degree.

+ +

You know, so as you start, you know, writing a bunch of code, you start finding a bunch of bugs that you don't necessarily know how to solve and that don't make any sense in the avenue that you've been exposed to. But as soon as you get into the next layer, you understand how that works begin to make a lot more sense. So, I think being comfortable with saying, "I have no idea why this is the case, but I'm going to go find out," makes the biggest difference for people just starting out their career.

+ +

WILL: I love that advice. Not too long ago, my manager encouraged me to write a blog post on something that I thought that I really knew. And when I started writing that blog post, I was like, oh boy, I have no idea. I know how to do it, but I don't know the why behind it. And so, I was very thankful that he encouraged me to write a blog post on it. Because once you start explaining it to other people, I feel you really have to know the whys. And so, I love that advice. That's really good advice.

+ +

VICTORIA: Me too. And it makes sense with what we see statistically as well in the DORA research. The DevOps Research Association publishes a survey every year, the State of DevOps Report. And one of the biggest findings I remember from last year's was that the most secure and reliable systems have the most open communication and high trust among the teams. And so, being able to have that curiosity as a junior developer, you need to be in an environment where you can feel comfortable asking questions [laughs], and you can approach different people, and you're encouraged to make those connections and write blog posts like Will was saying.

+ +

RISHI: Absolutely, absolutely. I think you touched on something very important there as well. The psychological safety really makes a big difference. And I think that's critical for, again, like, folks especially earlier in their career or have recently transitioned to tech, or whatever the case may be. Because asking "Why?" should be something that excites people, and there are companies where that's not necessarily the case, right? Where you asking why, it seems to be viewed as a sign that you don't know something, and therefore, you're not as good as what you should be, you know, the level you should be at or for whatever they expect.

+ +

But I do think that's the wrong attitude. I think the more people ask why, the more people are able and comfortable to be able to say, "I don't know, but I'm going to go find out," and then being able to be successful with that makes way better systems. It makes way safer and more secure systems. And, honestly, I think it makes humans, in general, better humans because we can do that.

+ +

VICTORIA: I think that's a great note to start to wrap up on. Is there any questions that you have for me or Will?

+ +

RISHI: Yeah. I would love to hear from both of you as to what you see; with the experiences that you have and what you do, the biggest impediments or speed bumps are when it comes to developers being able to write and ship secure code.

+ +

VICTORIA: When we're talking with new clients, it depends on where they are in really the adoption of their product and the maturity of their organization. Some early founders really have no technology experience. They have never managed an IT organization. You know, setting up basic employee account access and IDs is some of the initial steps you have to take to really get to where you can do identity management, and permissions management, and all the things that are really table stakes for security.

+ +

And then others have some progress, and they have a fair amount of data. And maybe it's in that situation, like you said before, where it's really a trade-off between the cost and benefit of making those changes to a more secure, more best practice in the cloud or in their CI/CD pipeline or wherever it may be.

+ +

And then, when you're a larger organization, and you have to make the trade-offs between all of that, and how it's impacting your developer experience, and how long are those deployed times now. And you might get fewer rates of errors and fewer rates of security vulnerabilities. But if it's taking three hours for your deployments to go out [laughs] because there's so many people, and there's so many checks to go through, then you have to consider where you can make some cuts and where there might be more efficiencies to be gained.

+ +

So, it's really interesting. Everyone's on a different point in their journey. And starting with the basics, like you said, I love that you brought up the OWASP Top 10. We've been adopting the CIS Controls and just doing a basic internal security audit ourselves to get more ready and to be in a position where...

+ +

What I'm familiar with as well from working in federal agencies, consulting, maintaining some of the older security frameworks can be a really high cost, not only in terms of auditing fees but what it impacts to your organization to, like, maintain those things [laughs] and the documentation required. And how do you do that in an agile way, in a way that really focuses on addressing the actual purpose of the requirements over needing to check a box? And how do we replicate that for our clients as well?

+ +

RISHI: That is super helpful. And I think the checkbox aspect that you just discussed I think is key. It's a difficult position to be in when there are boxes that you have to check and don't necessarily actually add value when it comes to security or compliance or, you know, a decrease in risk for the company. And I think that one of the challenges industry-wide has always been that security and compliance in and of itself tends to move a little bit slower from a blue team or a protection perspective than the rest of the industry.

+ +

And so, I mean, I can think of, you know, audits that I've been in where, you know, just even the fact that things were cloud-hosted just didn't make sense to the auditors. And it was a struggle to get them to understand that, you know, there is shared responsibility, and this kind of stuff exists, and AWS is taking care of some things, and we're taking care of some other things when they've just been developed with this on-premise kind of mentality.

+ +

That is one of the big challenges that still exists kind of across the board is making sure that the security work that you're doing adds security value, adds business value. It isn't just checking the box for the sake of checking the box, even when that's sometimes necessary.

+ +

VICTORIA: I am a pro box checker.

+ +

RISHI: [laughs]

+ +

VICTORIA: Like, I'll get the box checked. I'll use Trello and Confluence and any other tool besides Excel to do it, too. We'll make it happen with less pain, but I'd rather not do it [laughs] if we don't have to.

+ +

RISHI: [laughs]

+ +

VICTORIA: Let's make it easy. No, I love it. Is there anything else that you want to promote?

+ +

RISHI: No, I don't think there's anything else I want to promote other than I'm going to go back to what I said just earlier, like, that culture. And if, you know, folks are out there and you have junior engineers, you have engineers that are asking "Why?", you have people that just want to do the right thing and get better, lean into that. Double down on those types of folks. Those are the ones that are going to make big differences in what you do as a business, and do what you can to help them out. I think that is something we don't see enough of in the industry still. And I would love for that to change.

+ +

VICTORIA: I love that. Thank you so much, Rishi, for joining us.

+ +

RISHI: Thanks for having me. This was a great conversation. I appreciate the time.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Rishi Malik.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+86Sg9PIo + + ]]> + + Will Larry + Victoria Guido + Rishi Malik + + + 491: Compt.io with Amy Spurling + https://podcast.thoughtbot.com/491 + 4dae51cb-526a-4b95-9281-c7dda1a40f7e + Thu, 07 Sep 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Amy Spurling is the Founder and CEO of Compt, helping companies build and scale flexible perks, stipends that delight teams. She explains how Compt's approach to benefits aligns with an employee's life stages, and shares insights from data that revealed the vast diversity of vendors utilized by employees. + +Amy talks about fundraising for Compt, highlighting the gender investment gap and the difficulties faced by female founders. She also shares her personal experiences as a lesbian founder and emphasizes the importance of a diverse workforce. She outlines Compt's mission to provide equitable compensation and foster a broader perspective within companies, the economic miss of not investing in female-founded companies, and the complexities of transitioning into different roles within a startup. + 42:46 + no + + + Amy Spurling is the Founder and CEO of Compt, helping companies build and scale flexible perks, stipends that delight teams. She explains how Compt's approach to benefits aligns with an employee's life stages, and shares insights from data that revealed the vast diversity of vendors utilized by employees. +Amy talks about fundraising for Compt, highlighting the gender investment gap and the difficulties faced by female founders. She also shares her personal experiences as a lesbian founder and emphasizes the importance of a diverse workforce. She outlines Compt's mission to provide equitable compensation and foster a broader perspective within companies, the economic miss of not investing in female-founded companies, and the complexities of transitioning into different roles within a startup. +Amy's leadership values of balance and belonging are explored, and she shares insights about navigating hurdles like SOC 2 and GDPR compliance. Additionally, they talk about trends in the tech industry, such as AI's use in healthcare and the potential for bias in software, along with data privacy issues. +__ +Compt.io (https://www.compt.io/) +Follow Compt.io on LinkedIn (https://www.linkedin.com/company/compt/), Instagram (https://www.instagram.com/compthq/), Facebook (https://www.facebook.com/ComptHQ), or Xr (https://twitter.com/ComptHQ). +Follow Amy Spurling on LinkedIn (https://www.linkedin.com/in/amyspurling/) or X (https://twitter.com/amyspurling). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. And with us today is Amy Spurling, Founder and CEO of Compt, helping companies build and scale flexible perks, stipends that delight teams. Amy, thank you for joining. +AMY: Thanks so much for having me. +VICTORIA: Amy, I saw in your LinkedIn background that you have a picture of someone hiking in what looks like a very remote area. So, just to start us off today, I wonder if you could tell us a little bit more about that. And what's your hobby there? +AMY: Sure. I do spend a lot of time backpacking. That picture, I believe, was actually taken in Mongolia a couple of years ago. We spent ten days kind of hiking around in, I mean, everything is backcountry basically in Mongolia. So, spending a lot of time walking around, looking at mountains, is kind of my pastime. +WILL: I have a question around backpacking itself. When you say backpacking, what does that mean? Does it mean you only have a backpack, and you're out in the mountains, and you're just enjoying life? +AMY: It depends. So, in Mongolia, there were a couple of folks with camels, so carrying the heavy gear for us but still living in tents. My wife and I just did a backpacking trip in the Accursed Mountains in Albania, though, and everything was on our backpack. So, you're carrying a 35-pound pack. It has all your food, your water, your camping gear, and you just go. And you're just kind of living off the land kind of. I mean, you're taking food, so it's not like I'm foraging or hunting but living in the outback. +WILL: Wow. What does that do for you just internally, just getting off the grid, enjoying nature? Because I know with tech and everything now, it's kind of hard to do that. But you've done that, I think you said, for ten days. Like, walk us through that experience a little bit. +AMY: Some people use yoga, things like that, to go to a zen place, be calm, you know, help quiet their mind. For me, I need to do something active, and that's what I use this for. So getting off away from my phone, away from my laptop—those are not available to me when I'm in the mountains—and just focusing on being very present and listening to the birds, smelling the flowers. You know, pushing myself to where I'm, you know, exerting a lot of energy hiking and just kind of being is just...it's pretty fantastic. +VICTORIA: And I'm curious, what brought you to decide to go to Albania to get to that experience? Because that's not a top destination for many people. But -- +AMY: It is not. So, we travel a fair amount, and we backpack a fair amount. And the mountains there are honestly some of the most beautiful I've seen anywhere in the world. And so, we're always looking for, where can you get off the grid pretty quickly? Where can you be in the mountains pretty quickly in a way that still has a path so that you're not putting yourself in danger? Unless...I mean, we've done that too. +But you want to make sure you have a guide, obviously, if you're going completely no path, no trail kind of camping, too. But it just looked really beautiful. We planned it actually for three years ago and had to cancel because it was May of 2020. And so, we've had this trip kind of on the books and planned for it for a while. +VICTORIA: That's awesome. Yeah, I know of Albania because I had a friend who worked there for a few years. And she said the rock climbing there is amazing. And it actually has one of the last wild rivers in Europe. So, it's just a very remote, very interesting place. So, it's funny that you went there [laughs]. I was like, wait, other people also go to Albania. That's awesome. I love the outdoor space. +Well, what a great perk or benefit to working to be able to take those vacations and take that time off and spend it in a way that makes you feel refreshed. Tell me more about Compt and your background. What led you to found this company? +AMY: Sure. I've been in tech companies for, you know, over 20 years. I've been a CFO, a COO building other people's dreams, so coming in as a primary executive, you know, first funding round type of person, help scale the team, manage finance and HR. And I loved doing that, but I got really frustrated with the lack of tools that I needed to be able to hire people and to retain people. Because the way we compensate people has changed for the last 10, 15 years. +And so, ultimately, decided to build a platform to solve my own problem and my own team's problems, and started that getting close to six years ago now. But wanted to build a tech company in a very different way as well. So, in the same way, I take time off, I want my team to take time off. So, we operate on a basis of everyone should be taking their time off. Don't check in while you're out. We'll make sure we're covered. You know, let's build a sustainable business here. And everybody should be working 40 to 45 hours a week, which is definitely not a startup culture or norm. +WILL: Yeah. I love that. I was doing some research on Compt. And so, in your words, can you explain to everyone exactly what your company does? +AMY: Sure. So, we build lifestyle benefit accounts for companies. And what that means...and the terminology keeps changing, so some people may call them stipends or allowances. But it's really looking at how you pull together employee perks, benefits that will help compete for talent. And right now, retention is kind of the key driver for most companies. How do I keep the people I have really happy? +Competitive salaries are obviously table stakes. Health insurance for most industries is table stakes. So, it's, what else are you offering them? You can offer a grab bag of stuff, which a lot of companies try and do, but you get very low utilization. Or you can do something like a stipend or a lifestyle spending account, which is what we build, which allows for complete flexibility so that every employee can do something different. So that even if you're offering wellness, you know, what the three of us think about as wellness is likely very different. +I spend a lot of money at REI, like, they are basically, like, as big as my mortgage. I spend so much money there because I want backpacking gear. Wellness for you folks may be a little bit different. And so, allowing for that personalization so everybody can do something that matters to them. +VICTORIA: Right. And I love that it comes from a problem you found in your own experience of working with early-stage startups and being on the executive level and finance and building teams from the ground up. So, I'm curious, what lessons did you find in your previous roles that were maybe ten times more important when you started your own company? +AMY: I learned so much through all of my prior companies and pulled in the lessons of the things that worked really well but then also the things that it was, like, wow, I would definitely do that different. DEI is very important to us. I knew building a diverse team was going to be a competitive advantage for us. And none of my prior teams really met that mark. You know, most of them were Boston-based, the usual kind of profile of a tech company: 85%-95% White guys, mostly from MIT, you know, very, very talented, but also coached and trained by the same professors for the last 20 years. +So, I knew I wanted different perspectives around the table, and that was going to be really key. So, looking at non-traditional backgrounds, especially as we were looking at hiring engineers, for instance, that was really interesting to me because I knew that would be part of our competitive advantage as we started building up this platform that is employee engagement but very much a tax compliance and budgeting tool as well. +VICTORIA: I love hearing that. And it's something I've heard from actually thoughtbot's founder, Chad. That is something he wished he invested more in when he first started it. So, I'm curious as to how that's played out from when you started to where you are now. You said, I think, it's been six years, right? +AMY: January will be six years, so five and a half-ish, I guess, right now. I mean, it was a stated part of what we were going to do from day one. All of my prior companies wanted that as well. I don't think anybody starts out and says, "Hey, I'd really love a one-note company." No one says that. Everybody thinks that they're doing the right things and hiring the best talent. But what you do is you end up hiring from your network, which usually looks just like you. +And when you get to be, you know, 100, 150 people and you're looking around going, wow, we have some gaps here, it's really hard to fill them because who wants to be the first and the only of whatever? You know, I've been the only woman on most management teams. +So, for us, it was day one, make it part of the focus and make sure we're really looking for the best talent and casting a very wide net. So, right now, we're sitting at 56% female and 36% people of color, and somewhere around 18%-19% LGBTQIA. So, we're trying to make sure that we're attracting all those amazing perspectives. +And they're from people from around the country, which I also think is really important when you're building a tech company. Don't just build in areas where you're in your little tech bubble. If you want to build a product that actually services everyone, you need to have other kind of cultural and country perspectives as well. +VICTORIA: Yeah. And that makes perfect sense for what you described earlier for Compt, that it is supposed to be flexible to provide health benefits or wellness benefits to anyone. And there can be a lot of different definitions of that. So, it makes sense that your team reflects the people that you're building for. +AMY: Exactly. +WILL: Yeah. How does that work? How does Compt accomplish that? Because I know early on I was doing nonprofits and I was a decent leader. But I struggle to get outside of myself, my own bubble if that makes sense. So, like, that was before I had kids. I had no idea what it meant to have kids and just the struggles and everything if you have kids. So, there's so many different things that I've learned over the years that, like, just people have their own struggles. So, how does Compt accomplish the diversity of a company? +AMY: So, it's so interesting you mentioned that. I was on a podcast the other day with somebody who was, like, "You know, we didn't really think about our benefits and how important they were." And then, the founder who was the person on the podcast, and he was like, "But then I had kids. And suddenly, I realized, and we had this amazing aha moment." I'm like, well, it's great you had the aha moment. But let's back it up and do this before the founder has children. Sometimes you need to recognize the entire team needs something different and try and support them. +My frustration with the tools out there are there are tools that are like, hey, we're a DE&I platform. We will help you with that. You know, we've got a benefit for fertility. We've got a benefit for, you know, elder care. There's all kinds of benefits. These are great benefits, but they're also very, very specific in how they support an employee. And it's very small moment in time, usually. +Whereas with something like Compt, where we say, "Hey, we support family," your version of family, having children is very different from my version of family, where I don't have children, but we both have families. And we can both use that stipend in a way that is meaningful for us. What puts the employee back in charge, what matters in their lives, instead of the company trying to read everyone's mind, which is honestly a no-win situation for anyone. So, it just makes it very, very broad. +VICTORIA: Yes. And I've been on both sides, obviously, as an employee, but also previously role of VP of Operations. And trying to design benefits packages that are appealing, and competitive, and fair is a challenging task. So -- +AMY: It's impossible. It's impossible. [laughs] +VICTORIA: Very hard. And I'm curious what you found in the early stages of Compt that was surprising to you in the discovery process building the product. +AMY: So, for me, I mean, discovery was I am the buyer for this product. So, I wanted this about five years before I decided to go and build it. And I was talking to other finance and HR professionals going around going, "All right, are you feeling this exact same pain that I'm feeling? Because it is getting completely insurmountable." +We were all being pitched all these different platforms and products. Everybody had something they wanted to sell through HR to help attract, and engage and retain talent and all the things, right? But there's no tracking. It's not taxed correctly. And ultimately, no matter what you bring in, maybe 2% to 3% of your team would use it. So, you're spending all this time and energy in putting all this love into wanting to support your team, and then nobody uses the stuff that you bring in because it just doesn't apply to them. +And so, I realized, like, my pivotal moment was, all right, none of this is working. I've been waiting five years for somebody to build it. Let's go build something that is completely vendor-agnostic. There's no vendors on this platform by design because everyone ultimately wants something different. +And, you know, through that process, we were, of course, pushed by many VCs who said, "Hey, build your marketplace, build your marketplace, you know, that's going to be your moat and your special sauce." And I said, "No, no, no, that's not what we're going to do here because that doesn't solve that problem." And we finally had the data to prove it, which is fantastic. +You know, we actually did a sample of 8,700 people on our platform, and we watched them for a year. And said, "How many different vendors are these 8,700 people going to use?" Because that's the marketplace we'd have to build because we have 91% employee engagement. Nobody can beat us in the industry. We've got the highest employee engagement of any platform in our category. So, how many different vendors could 8,700 people use in that time period? Do you guys have any guesses how many they used in that time period to get to that engagement? +VICTORIA: Out of 8,700 vendors? +AMY: No, 8,700 employees. So, how many different vendors they used in that time period. +VICTORIA: Hmm, like, per employee, I could see maybe, like, 10? I don't know. Two? +AMY: We saw 27,000 different vendors used across all the employees, so 27,000 different unique vendors. So, on average, every employee wants three unique vendors that no one else is using. +VICTORIA: Oh wow. +WILL: Wow. +VICTORIA: Yeah, okay. [laughter] Right. +AMY: So, it's just you can't build that, I mean, you could build that marketplace, but nobody's going to visit that marketplace because nobody wants to scroll through 27,000 things. And so, it just keeps changing. +You know, and I saw that even with the woman who started the company with me, you know, when she...we, of course, use Compt internally. And she started using her wellness stipend. You know, at first, she was doing 5Ks. So, she'd register for the race. She'd go train. She'd do all the things. Then she got pregnant and had a baby and started shifting over to prenatal vitamins, to Lamaze classes, to, you know, mommy yoga, things like that. Then once she had the baby, it shifted again. +And so, it allows for a company to flow with an employee's lifecycle without having to get into an employee's life stage and, "Hey, what do you need at this moment in time?" Employees can self-direct that, so it makes it easier for employees and a lot easier for companies who are not trying to...we don't want to map out every single moment of our employee's personal life. We shouldn't be involved in that. And so, this is a way to support them but also give them a little space too. +WILL: I absolutely love that because that is, yes, that is a flow. Like, before you have kids, it's, like, yes, I can go run these 5Ks; I can do this. When you have kids, it totally changes. Like, okay, what can I do with my kids? So, workout, or that's my away time. So, I love that it's an ebb and flow with the person. And they can pick their own thing, like -- +AMY: Right. We're all adults. +WILL: Yes. [laughs] +AMY: I think I sat there going; why am I dictating someone's health and wellness regimen? I am not qualified for this on any stretch. Like, why am I dictating what somebody's mental health strategy should be? That's terrifying. You're adults. You work with your professionals. We'll support it. +WILL: Yes. I remember at one company I worked for; they had this gym that they had, you know, got a deal with. And I was so frustrated because I was like, that's, like, 45 minutes away from my house. +AMY: [laughs] Right. +WILL: It's a perk, but it means absolutely nothing to me. I can't use it. So yes, yeah. [laughs] +AMY: Well, and, like, not everybody wants to work, say...there was, you know, we see a lot of that is there's been a transition over time. COVID really changed that as people couldn't go to gyms, and companies shifted to stipends. But you may not want to work out with your co-workers, and that's okay, too. Like, it's okay to want to do your own thing and be in your own space, which is where we see this kind of decline of the, you know, on-site company gym, which, you know, some people just don't want to do that. +VICTORIA: Yeah. So, I love that you stayed true to this problem that you found and you backed it up with data. So, you're like, here's clear data on, say, why those VCs' advice was bad [laughs] about the marketplace. +AMY: Ill-informed. They needed data to see otherwise. [laughs] +VICTORIA: Yeah. Well, I'm curious about your experience going through fundraising and starting up for Compt with your background as a CFO and how that was for you. +AMY: It was...I naively thought it would be easier for me, and maybe it was because I had all this experience raising money as a CFO in all these prior companies. But the reality is that women receive less than 2% of all funding, even though we start 50% of the businesses. And if you look at, you know, Black female founders, they're receiving, like, 0.3, 0.5% of funding. Like, it's just...it's not nice out there. +You know, on average, a lot of VCs are looking at 3,000, 4,000, or 5000 different companies a year and investing in 10. And so, the odds of getting funded are very, very low, which means that you're just going to experience a whole lot of unique situations as a female founder. I saw that you folks work with LOLA, which is fantastic. I'm a huge fan of LOLA and kind of what their founders put together. And I've heard some amazing things about the pitches that she's done for VCs and that she's just not shy about what she's building. And I really appreciate that. +It's never a fun situation. And it gets easier the later stages because you have more metrics, and data, and all of that. And we ultimately found phenomenal investors that I'm very, very happy to have as part of our journey. But it's definitely...it's not pretty out there is the reality. +VICTORIA: Right. And I saw that you either attended or put on an event about the gender investment gap, which I think is what you just referred to there as well. So, I'm curious how that conversation went and if there were any insights about what the industry can do to promote more investment in women and people of color founders. +AMY: So, that's actually coming up August 10th, and so that's coming up in a few weeks that we're going to be hosting that. I'm actually part of a small group that is spearheading some legislation in Massachusetts to help change this funding dynamic for female founders, which I'm pretty excited about. And California also has some legislation they're looking at right now. +In Mass, we're looking at how fair lending laws can apply to venture capital. There are laws on the books on how capital gets distributed when you look at the banking system. But there's virtually no regulation when you look at venture funding, and there's no accountability, and there's no metrics that anybody is being held to. +I don't believe that you know, just because I pitched a VC that they should be funding me, you know, it needs to be part of their thesis and all of those things. But when you see so much disparity in what is happening out there, bias is coming into play. And there needs to be something that helps level that playing field. And so, that's where legislation comes into play and helps change that dynamic. So, pretty excited about the legislation that's before both the Senate and the Mass State House, likely going to be heard this November. So, we're pretty excited about that. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +WILL: So, Amy, you're talking a lot about diversity, inclusion, and just biases, and things like that. You're doing a great job with it. Your product is perfect for that because it reaches so many different levels. And I just want to ask you, why are you so passionate about it? Why is this so important to you? +AMY: For me, personally, I am a lesbian founder. I am the only, you know, LGBTQ in many of my companies. And I'm always the, I mean, very frequently, the only woman in the boardroom, the only woman on the leadership team. That's not super comfortable, honestly. When you are having to fight for your place at the table, and you see things that could be done differently because you're bringing a different perspective, that, to me, is a missed opportunity for companies and for employees as well who, you know, there's amazing talent out there. If you're only looking at one flavor of talent, you're missing the opportunity to really build a world-class organization. +And so, to me, it's both the personal side where I want to work with the best people. I want to work with a lot of different perspectives. I want to work with people who are bringing things to the table that I haven't thought about. But also, making sure that we're creating an environment where those people can feel comfortable as well, and so people don't feel marginalized or tokenized and have the ability to really bring their best selves to work. That's really important to me. +It's a reflection of the world around us. It's bringing out the best in all of us. And so, for me, that's the environment I want to create in my own company. And it's also what I want to help companies be able to foster within their companies because I think a lot of companies really do want that. They just don't know how to go about it. They don't have actual tools to support a diverse team. You pay for things for the people you have, and then you hire more people like the people you have. We want to be a tool to help them expand that very organically and make it a lot easier to support a broader perspective of people. +VICTORIA: I appreciate that. And it speaks to something you said earlier about 50% of the businesses are started by women. And so, if you're not investing in them, there's a huge market and huge potential and opportunity there that's just not -- +AMY: The economic miss is in the trillions, is what's been estimated. Like, it's an absolute economic miss. I mean, you also have the statistics of what female-founded companies do. We tend to be more profitable. We tend to be more capital efficient. We tend to, you know, have better outcomes. It's just so the economics of it are there. It's just trying to get folks to understand where their biases are coming into play and funding things that may be a little outside their comfort zone. +VICTORIA: Right. That's going to be a big project to undo all of that. So, each piece that works towards it to break it down, I think, is really important. And it seems like Compt is a great tool for companies to start working towards that, at least in the equity of their benefits, which is -- [laughs] +AMY: Exactly. Because, I mean, if people can't use a perk, then it's inequitable compensation. And if you have inequitable compensation, you're already going down that path. You end up with wage gaps, and then you end up with promotion gaps. And all these things feed into each other. So, we're just trying to chip away at one piece of the problem. There's lots of places that this needs to be adjusted and changed over time. But we want to at least chip away at that one piece where this piece of compensation can be equitable and support everyone. +WILL: Yeah, I love that. I was looking at your LinkedIn. And it looks like you've been almost, later this year, maybe six years of Compt. What was some of the early traction? Like, how was it in the early days for you? +AMY: It was an interesting transition for me, going from CFO and COO over to the CEO role. That was easier in some ways than I thought it was going to be and harder in other ways. You know, on the easy side, I've already done fundraising. I understand how to write a business model, and look at financial plans, and make sure the concept is viable and all the things. But I also am not an engineer. I'm not a product designer. +And so needed to make sure we immediately surrounded ourselves with the right talent and the right help to make sure that we could build the right product, pull the things out of my brain that are conceptual but definitely not product design. No one wants me touching product design. I've been barred from all codebases in this company. They don't want me touching anything, with good reason. And so, making sure that we have those right people to build and design the software in a way that functionally makes sense. +VICTORIA: I think that is great that...I laughed when you said that you are barred from touching any of the code. [laughs] It's like, you're able to...I think a strong leader recognizes when other people have the expertise and makes space for them to do their best work. I also see that, at the same time, you've been a mentor with the MassChallenge group. And I'm curious if you have a most frequent piece of advice that you give to founders and people starting out building great products. +AMY: The biggest piece of advice, I think, is to make sure you're taking care of yourself through this process. It's an exhausting process to build a company. And there's always way more that you should be doing every day than you can possibly get done. And if you just completely absorb yourself in it, you're going to end up burning out. So, making sure that you rest, that you still make time to exercise and to move, and that you spend time with family. All of those things, I think, are really, really important. That's been part of our core tenets. +From day one, I said, "No more than 40 to 45 hours a week." It doesn't mean I'm not thinking about this business far more than 45 hours a week, but I'm not going to sit behind a computer that many hours in a week because I will burn out. And if I'm out and I'm reading something, or I'm, you know, going for a walk, I'm going to have moments of inspiration because I can actually have those creative thoughts firing when I'm not just putting out fires. +And so, I think that's really, really important for founders to make sure they take that time and allow their brains to clear a little bit so that they can build more efficiently, build faster, and have really good critical reasoning skills. +WILL: I love that you not only have the product to, you know, help taking time off, but you also are preaching it per se, like, take time off. Don't work more than 40-45 hours. Like, take care of yourself. So, I love that advice that you're giving is right in the message with your product. So, I love it. +AMY: Thank you. I do hammer home with this team. What we build is obviously very, very important to me, but how we build this company is equally important. We spend just as much time thinking about how we're building and designing this company internally as we do about our product because they need to be a virtuous cycle between the two, quite frankly. And so, if they aren't aligned, we're going to fail. +WILL: Definitely. Wow. Awesome. What does success look like for you and Compt in the next, you know, six months to a year? +AMY: For us, it's really about reaching as many people as possible. So, how do we have an impact on as many lives as possible and help people be able to access this piece of their compensation? What is interesting right now is we're in a really interesting moment. The tech industry is going through...shall we call it an awakening? Where money is tighter. There's been some layoffs. You know, it's just a very different world in tech right now. And everybody's in a little bit of a holding pattern to figure out, okay, what's next? +What we're seeing across our portfolio of companies is that there's a lot of industries that are, for the first time, really thinking about how do we retain folks? How do we think about hiring in a new way? So, industries like construction and manufacturing. Industries that never had employee kind of lifestyle benefits or perks they're taking a look at that because unemployment is so, so low. +And so, for the first time ever, we have the ability to have an impact on groups that never had access to professional development, to wellness, to things like that. And that's really exciting because you can have such a huge, impactful moment where people have just been without for so long. And so, that's pretty exciting for us. +VICTORIA: You're touching upon a topic that I've thought about before, where in the tech industry, we're used to having a lot of benefits and perks and that not every industry is the same way. So, I'm curious; you mentioned construction and some other groups that are looking to adopt more of these benefits because unemployment is so low. I'm curious, like, if there are any patterns or things that you see, like, specific industries that are more interested than others, or what's going on there? +AMY: Our portfolio of tech companies are only about...they're less than 40% of our customers, actually. So, a relatively low percentage of our customers come from the tech industry. What we find is that healthcare systems this is really important. As you're thinking about how you're going to retain nursing staff, it is incredibly difficult. And so, we see a lot of movement in the healthcare space. We see a lot of movement, again, across manufacturing and construction, you know, financial services. +Pretty much anybody who is struggling to hire and is worried about retaining is trying to figure out what's my strategy? How do I do this in the least expensive way possible but reach everyone? Because those employee engagement metrics are so consistently important to look at. And most platforms and things that you could be doing out there are going to give you a 2% to 3% utilization. So, it's very, very low. +You know, wellness is by far the most common use case we see companies putting in place. It's good for employees. It's good for the employer. That's by far the most important or the most common. But we also see things like family, and just more of a whole well-being kind of concept as well, so beyond wellness, so allowing for that broader reach. +We're also seeing industries where people are starting to age out. So, we've got five generations at work right now. There's industries where folks have historically stayed forever. You know, you've got the people who have been there 20-30 years. Well, those same industries are now sitting there going, all right, how do I get the next two generations to come in here? Because it's such an old-guard and old approach. We've got to change things up. And so, we're seeing a pretty big cultural shift happen within a lot of these more nascent industries. +WILL: Yeah. I can definitely see how that would be tough going from, you know, you said five generations are currently in the workforce? +AMY: Yep. +WILL: I didn't even think about that. Wow. +AMY: Yeah, you got a lot of different parts of the life cycle. You know, think about professional development. Professional development for a 22-year-old is very different from professional development for a 65-year-old. But both are in the workplace, and both want to keep learning. It's just what your needs are and what you need to learn. And how you want to learn is going to be very, very different. +WILL: Wow. So true. I love how you're talking about your leadership and just the way you lead. I can just hear it in what you're saying. What are some of your core values that drive you every day? +AMY: One of the big ones, and it probably goes back to, you know, I'm sure, birth placement, whatever. I'm an oldest child, all the things that come with being an oldest child. But fairness is a really big one for me. And so, it's thinking about how we apply that as a company, so equitable compensation falls under that. Making sure that we've got a team that is balanced and diverse is really important to me. +You know, thinking, you know, our core values are balance and belonging. That runs through absolutely everything that we do and is core and central to it. Because, again, how we build this company is just as important to me as what we're building. And so, making sure that we hold true to those values is critical because we have amazing people, and they need to feel supported as well. +VICTORIA: Well, that really comes through in everything that you say and that we've talked about so far today, and I really appreciate that. And I'm curious if you could go back in time to when you first started Compt and tell yourself any piece of advice or information; what would you say? +AMY: That piece of advice has changed over time; I will tell you that. The one that is most recent for me is really because we're an HR tech platform, and we service, you know, an entire organization, is really thinking about how you support different industries at different moments in time, the concept of product-market fit. When you're that type of a platform, which there aren't many, there's not many platforms that sit across an entire organization, but compensation is one of them. You need to be thinking about which industries are struggling to hire, which are struggling to retain at this moment in time. +And so, I don't think there's one place, like, hey, we have product-market fit, now we can scale. I think that's a misnomer for our part of the HR tech space. And so, it's constant experimentation on go-to-market strategy and constant kind of adjustment as markets ebb and flow over time. +WILL: What is some of your biggest hurdles right now or even in the future that you can see coming? +AMY: If I had a crystal ball, life would definitely be easier. I'd love to know when this economic cycle is going to shift and, you know when things get a little bit easier for companies. You know, HR leaders and finance leaders are not having the most fun at this moment in time. They're being tasked with making everybody happy but on very small budgets, and so they're really challenged with that. And they're really burnt out, and they're exhausted. So, I'm looking forward to a shift so when people can get back to feeling a little bit physically better. But also, it just helps navigate a market and be better able to support your employees. +VICTORIA: I've been thinking about that question recently, what I would tell my past self, and I think it's mostly, like, food related. +[laughter] +AMY: Ooh, interesting. +VICTORIA: Use better vinegars, like, invest in fancier olive oil. [laughs] +AMY: So, my new luxury pro-tip is you buy a $7 bunch of eucalyptus at the grocery store, and you tie it above your shower head. I'm not kidding; you will feel like you're at a spa. It costs $7. I learned it because I was at some fancy resort. One of my investors, you know, paid for us to go to a conference that I was not paying for. And I was like, that is genius. You suddenly feel like you are in someplace fancy, and it was seven bucks. It's amazing. +WILL: Yes. +VICTORIA: That sounds incredible. I'm going to do that. +WILL: Same. +[laughter] +VICTORIA: [inaudible 34:35] buy some. No, it's so good. Do you have any questions for us, Amy? +AMY: Yeah. I mean, what trends are you seeing in the market right now? Like, what types of companies are being developed? Where do you see growth happening in the market? +VICTORIA: That's probably a better question for me. As a managing director, I spend more time networking and going to events. And it's interesting being in San Diego. There's a big biotech startup here. So, I went to an EvoNexus Demo Day and saw the things that people were using. And there seemed to be a trend of using AI and machine learning to create better health outcomes, whether that's for predictors for which people will respond better to anti-cancer drugs, or, you know, how do we monitor the release of drugs for someone's system who's, you know, going through methadone in therapy. So, it's really interesting. +I think that you know, you mentioned that there's not the same amount of money in the tech market, but I think there is still a lot of work being done to solve real problems that people have. So yeah, I'm really curious to see those types of projects and which ones are going to be successful, and how much the AI trend will really fade out. Like, clearly, in some use cases, you can see how beneficial it could be. And other times, it seems like it's kind of just like slapped on there for -- +AMY: Agreed. +VICTORIA: Marketing purposes, so... +AMY: That's really just a database query. It's not AI. [laughs] +VICTORIA: Right. [laughs] It's interesting because, you know, I just had lunch with a bunch of other CTOs in San Diego, and we were talking about AI, and some of the inherent risks of it, and the damage it can cause. And I always like to bring it back to, like, there are some people who are already harmed by these trends. And we have to work around that. Like, there is some, you know, greater supposed existential threat with AI that I think is rather unlikely. But if we think about that too much and not focus on the current harm that's being done, then that's, you know, more dangerous than the other one. +AMY: Yeah. No, absolutely. I mean, there's definitely, I mean, even just with facial recognition and how that's applied and what that's used for. I mean, any software that is built with people has bias. And so, whatever biases they're bringing into it is the bias that's going to exist in the software. And so, there's...we already are starting from, you know, going back to our earlier conversation, if companies are not diverse and not building for really diverse perspectives, they're inherently going to build bias software, whether or not, I mean, I don't think that's anybody's intention. But that's what's going to happen because you just didn't think about things you didn't know. +VICTORIA: Right. And, of course, I'm here in Southern California. There's the strikes for the actors and writers' strike happening a few hours north of us. And they were actually, you know, for some actors, signing away their rights to their likeness. +AMY: Wow. +VICTORIA: And then they could make an AI image and -- +AMY: Wow. You could just create an entire movie with somebody's image and dub in a voice, and suddenly you don't need actors. +VICTORIA: Right. And it's, of course, more often non-White actors and models who are being replaced. And so, I think that's a very interesting trend that people may not have thought about yet. +AMY: Fascinating. +VICTORIA: So yeah, I mean, having people on your leadership team who are thinking about these [laughs] different types of issues, like, yeah, I think it's really important. And then also, from, like, a data privacy perspective, all the laws that are coming out and that have come out. And I think that some founders and CTOs are really struggling with how to comply and protect everyone's data that way. +AMY: No. It's something we think about a lot because we have the potential to have access to a lot of employee data. We take a very minimalist approach stated, not a big data play. That's not what we're here for. That's not what we're trying to do, this mountain of data on people, and then we'll figure out how to monetize it. We want to build something a little bit different. And so using only data that needs to be used so that we can truly support people with what our actual goal and aim is, rather than having that be a secondary cause. +VICTORIA: Yeah. And I wanted to ask you about that actually because you have SOC 2 and GDPR compliance. And it's a topic that I think a lot of founders know that security is important, but it can be a significant investment. So, I'm curious your trade-offs and your timing for when you went for those compliance frameworks. +AMY: We went early for it. I mean, so our platform, I mean, we're integrated with payroll platforms. We're touching employee data. So, we went for it early because we knew that it was going to be important, and it's a lot easier to do it before you make a mess than it is after the fact. I've done SOC 2 compliance in two prior companies. It's not fun. It is not my most fun thing that I've ever done. +Fortunately, there are geniuses out there who built platforms to make this very, very easy now. We use a platform called Vanta that is absolutely incredible, made it super easy to get SOC 2 compliant, go through our audits, do all the things, so that, at least, is a lot easier. But it was something that we needed the funding to invest in. It's not inexpensive. +But we knew that it was going to be critical because people need to feel that their data is secure and that you know what you're doing, and that you're not just kind of flying by the seat of your pants. There's a lot of tech companies that operate on, we'll figure out the tax, or we'll figure out the law. We'll figure out the compliance later. And that's been a stated part of their mission. That's just not the way I'm going to operate. And that doesn't work very well when you're dealing with HR, quite frankly, or finance because we have to comply with laws. So, getting ahead of that early was part of our strategy. +VICTORIA: That makes sense. Your finance background making it clear what the legal implications are. [laughs] +AMY: Exactly. Like, I'm not messing around with the IRS. Nobody wants to get audited by the IRS. It's not fun. Let's just keep things tax compliant. Chances are you're not going to get audited by the IRS. But if you are a tech company, if you do want to go public, if you do want to be acquired likely from a public company, you have to have these things in order because otherwise, it's coming off your purchase price or your stock price because you've got disclosures you've got to put out there, so little hidden, nasty gotchas. +And it can be a six-year lookback period. So, you're like, oh, I'll worry about it later. Six years is a long time. And if you start messing around with that, it gets very, very expensive to clean up. So, just do it right from the beginning. You know, the same way you're doing payroll correctly now, invest a little bit, and it makes it a lot easier. +VICTORIA: Yeah, I agree. And I think the tooling that's out there makes it a little bit easier; at least then, you know you have the confidence that your data is protected. Especially if you're a non-technical founder, I can imagine that makes you feel better that things are the way they should be. +AMY: Exactly. Somebody has looked at this thing. Somebody is making sure that it's working the way it's supposed to. You know, that definitely helps when you're a non-technical founder, or just not a tax expert, or a legal expert, you know, around these things. It's not even the technical founders that have to worry about it. Data comes in all kinds of forms. +VICTORIA: Yeah, that makes a lot of sense. +AMY: This has been a fantastic conversation. I've really enjoyed it. +VICTORIA: Well, thank you. +WILL: Same. +VICTORIA: I've enjoyed it as well. I really appreciate you taking the time. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg. +WILL: And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Amy Spurling. + + + Amy Spurling is the Founder and CEO of Compt, helping companies build and scale flexible perks, stipends that delight teams. She explains how Compt's approach to benefits aligns with an employee's life stages, and shares insights from data that revealed the vast diversity of vendors utilized by employees.

+ +

Amy talks about fundraising for Compt, highlighting the gender investment gap and the difficulties faced by female founders. She also shares her personal experiences as a lesbian founder and emphasizes the importance of a diverse workforce. She outlines Compt's mission to provide equitable compensation and foster a broader perspective within companies, the economic miss of not investing in female-founded companies, and the complexities of transitioning into different roles within a startup.

+ +

Amy's leadership values of balance and belonging are explored, and she shares insights about navigating hurdles like SOC 2 and GDPR compliance. Additionally, they talk about trends in the tech industry, such as AI's use in healthcare and the potential for bias in software, along with data privacy issues.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Amy Spurling, Founder and CEO of Compt, helping companies build and scale flexible perks, stipends that delight teams. Amy, thank you for joining.

+ +

AMY: Thanks so much for having me.

+ +

VICTORIA: Amy, I saw in your LinkedIn background that you have a picture of someone hiking in what looks like a very remote area. So, just to start us off today, I wonder if you could tell us a little bit more about that. And what's your hobby there?

+ +

AMY: Sure. I do spend a lot of time backpacking. That picture, I believe, was actually taken in Mongolia a couple of years ago. We spent ten days kind of hiking around in, I mean, everything is backcountry basically in Mongolia. So, spending a lot of time walking around, looking at mountains, is kind of my pastime.

+ +

WILL: I have a question around backpacking itself. When you say backpacking, what does that mean? Does it mean you only have a backpack, and you're out in the mountains, and you're just enjoying life?

+ +

AMY: It depends. So, in Mongolia, there were a couple of folks with camels, so carrying the heavy gear for us but still living in tents. My wife and I just did a backpacking trip in the Accursed Mountains in Albania, though, and everything was on our backpack. So, you're carrying a 35-pound pack. It has all your food, your water, your camping gear, and you just go. And you're just kind of living off the land kind of. I mean, you're taking food, so it's not like I'm foraging or hunting but living in the outback.

+ +

WILL: Wow. What does that do for you just internally, just getting off the grid, enjoying nature? Because I know with tech and everything now, it's kind of hard to do that. But you've done that, I think you said, for ten days. Like, walk us through that experience a little bit.

+ +

AMY: Some people use yoga, things like that, to go to a zen place, be calm, you know, help quiet their mind. For me, I need to do something active, and that's what I use this for. So getting off away from my phone, away from my laptop—those are not available to me when I'm in the mountains—and just focusing on being very present and listening to the birds, smelling the flowers. You know, pushing myself to where I'm, you know, exerting a lot of energy hiking and just kind of being is just...it's pretty fantastic.

+ +

VICTORIA: And I'm curious, what brought you to decide to go to Albania to get to that experience? Because that's not a top destination for many people. But --

+ +

AMY: It is not. So, we travel a fair amount, and we backpack a fair amount. And the mountains there are honestly some of the most beautiful I've seen anywhere in the world. And so, we're always looking for, where can you get off the grid pretty quickly? Where can you be in the mountains pretty quickly in a way that still has a path so that you're not putting yourself in danger? Unless...I mean, we've done that too.

+ +

But you want to make sure you have a guide, obviously, if you're going completely no path, no trail kind of camping, too. But it just looked really beautiful. We planned it actually for three years ago and had to cancel because it was May of 2020. And so, we've had this trip kind of on the books and planned for it for a while.

+ +

VICTORIA: That's awesome. Yeah, I know of Albania because I had a friend who worked there for a few years. And she said the rock climbing there is amazing. And it actually has one of the last wild rivers in Europe. So, it's just a very remote, very interesting place. So, it's funny that you went there [laughs]. I was like, wait, other people also go to Albania. That's awesome. I love the outdoor space.

+ +

Well, what a great perk or benefit to working to be able to take those vacations and take that time off and spend it in a way that makes you feel refreshed. Tell me more about Compt and your background. What led you to found this company?

+ +

AMY: Sure. I've been in tech companies for, you know, over 20 years. I've been a CFO, a COO building other people's dreams, so coming in as a primary executive, you know, first funding round type of person, help scale the team, manage finance and HR. And I loved doing that, but I got really frustrated with the lack of tools that I needed to be able to hire people and to retain people. Because the way we compensate people has changed for the last 10, 15 years.

+ +

And so, ultimately, decided to build a platform to solve my own problem and my own team's problems, and started that getting close to six years ago now. But wanted to build a tech company in a very different way as well. So, in the same way, I take time off, I want my team to take time off. So, we operate on a basis of everyone should be taking their time off. Don't check in while you're out. We'll make sure we're covered. You know, let's build a sustainable business here. And everybody should be working 40 to 45 hours a week, which is definitely not a startup culture or norm.

+ +

WILL: Yeah. I love that. I was doing some research on Compt. And so, in your words, can you explain to everyone exactly what your company does?

+ +

AMY: Sure. So, we build lifestyle benefit accounts for companies. And what that means...and the terminology keeps changing, so some people may call them stipends or allowances. But it's really looking at how you pull together employee perks, benefits that will help compete for talent. And right now, retention is kind of the key driver for most companies. How do I keep the people I have really happy?

+ +

Competitive salaries are obviously table stakes. Health insurance for most industries is table stakes. So, it's, what else are you offering them? You can offer a grab bag of stuff, which a lot of companies try and do, but you get very low utilization. Or you can do something like a stipend or a lifestyle spending account, which is what we build, which allows for complete flexibility so that every employee can do something different. So that even if you're offering wellness, you know, what the three of us think about as wellness is likely very different.

+ +

I spend a lot of money at REI, like, they are basically, like, as big as my mortgage. I spend so much money there because I want backpacking gear. Wellness for you folks may be a little bit different. And so, allowing for that personalization so everybody can do something that matters to them.

+ +

VICTORIA: Right. And I love that it comes from a problem you found in your own experience of working with early-stage startups and being on the executive level and finance and building teams from the ground up. So, I'm curious, what lessons did you find in your previous roles that were maybe ten times more important when you started your own company?

+ +

AMY: I learned so much through all of my prior companies and pulled in the lessons of the things that worked really well but then also the things that it was, like, wow, I would definitely do that different. DEI is very important to us. I knew building a diverse team was going to be a competitive advantage for us. And none of my prior teams really met that mark. You know, most of them were Boston-based, the usual kind of profile of a tech company: 85%-95% White guys, mostly from MIT, you know, very, very talented, but also coached and trained by the same professors for the last 20 years.

+ +

So, I knew I wanted different perspectives around the table, and that was going to be really key. So, looking at non-traditional backgrounds, especially as we were looking at hiring engineers, for instance, that was really interesting to me because I knew that would be part of our competitive advantage as we started building up this platform that is employee engagement but very much a tax compliance and budgeting tool as well.

+ +

VICTORIA: I love hearing that. And it's something I've heard from actually thoughtbot's founder, Chad. That is something he wished he invested more in when he first started it. So, I'm curious as to how that's played out from when you started to where you are now. You said, I think, it's been six years, right?

+ +

AMY: January will be six years, so five and a half-ish, I guess, right now. I mean, it was a stated part of what we were going to do from day one. All of my prior companies wanted that as well. I don't think anybody starts out and says, "Hey, I'd really love a one-note company." No one says that. Everybody thinks that they're doing the right things and hiring the best talent. But what you do is you end up hiring from your network, which usually looks just like you.

+ +

And when you get to be, you know, 100, 150 people and you're looking around going, wow, we have some gaps here, it's really hard to fill them because who wants to be the first and the only of whatever? You know, I've been the only woman on most management teams.

+ +

So, for us, it was day one, make it part of the focus and make sure we're really looking for the best talent and casting a very wide net. So, right now, we're sitting at 56% female and 36% people of color, and somewhere around 18%-19% LGBTQIA. So, we're trying to make sure that we're attracting all those amazing perspectives.

+ +

And they're from people from around the country, which I also think is really important when you're building a tech company. Don't just build in areas where you're in your little tech bubble. If you want to build a product that actually services everyone, you need to have other kind of cultural and country perspectives as well.

+ +

VICTORIA: Yeah. And that makes perfect sense for what you described earlier for Compt, that it is supposed to be flexible to provide health benefits or wellness benefits to anyone. And there can be a lot of different definitions of that. So, it makes sense that your team reflects the people that you're building for.

+ +

AMY: Exactly.

+ +

WILL: Yeah. How does that work? How does Compt accomplish that? Because I know early on I was doing nonprofits and I was a decent leader. But I struggle to get outside of myself, my own bubble if that makes sense. So, like, that was before I had kids. I had no idea what it meant to have kids and just the struggles and everything if you have kids. So, there's so many different things that I've learned over the years that, like, just people have their own struggles. So, how does Compt accomplish the diversity of a company?

+ +

AMY: So, it's so interesting you mentioned that. I was on a podcast the other day with somebody who was, like, "You know, we didn't really think about our benefits and how important they were." And then, the founder who was the person on the podcast, and he was like, "But then I had kids. And suddenly, I realized, and we had this amazing aha moment." I'm like, well, it's great you had the aha moment. But let's back it up and do this before the founder has children. Sometimes you need to recognize the entire team needs something different and try and support them.

+ +

My frustration with the tools out there are there are tools that are like, hey, we're a DE&I platform. We will help you with that. You know, we've got a benefit for fertility. We've got a benefit for, you know, elder care. There's all kinds of benefits. These are great benefits, but they're also very, very specific in how they support an employee. And it's very small moment in time, usually.

+ +

Whereas with something like Compt, where we say, "Hey, we support family," your version of family, having children is very different from my version of family, where I don't have children, but we both have families. And we can both use that stipend in a way that is meaningful for us. What puts the employee back in charge, what matters in their lives, instead of the company trying to read everyone's mind, which is honestly a no-win situation for anyone. So, it just makes it very, very broad.

+ +

VICTORIA: Yes. And I've been on both sides, obviously, as an employee, but also previously role of VP of Operations. And trying to design benefits packages that are appealing, and competitive, and fair is a challenging task. So --

+ +

AMY: It's impossible. It's impossible. [laughs]

+ +

VICTORIA: Very hard. And I'm curious what you found in the early stages of Compt that was surprising to you in the discovery process building the product.

+ +

AMY: So, for me, I mean, discovery was I am the buyer for this product. So, I wanted this about five years before I decided to go and build it. And I was talking to other finance and HR professionals going around going, "All right, are you feeling this exact same pain that I'm feeling? Because it is getting completely insurmountable."

+ +

We were all being pitched all these different platforms and products. Everybody had something they wanted to sell through HR to help attract, and engage and retain talent and all the things, right? But there's no tracking. It's not taxed correctly. And ultimately, no matter what you bring in, maybe 2% to 3% of your team would use it. So, you're spending all this time and energy in putting all this love into wanting to support your team, and then nobody uses the stuff that you bring in because it just doesn't apply to them.

+ +

And so, I realized, like, my pivotal moment was, all right, none of this is working. I've been waiting five years for somebody to build it. Let's go build something that is completely vendor-agnostic. There's no vendors on this platform by design because everyone ultimately wants something different.

+ +

And, you know, through that process, we were, of course, pushed by many VCs who said, "Hey, build your marketplace, build your marketplace, you know, that's going to be your moat and your special sauce." And I said, "No, no, no, that's not what we're going to do here because that doesn't solve that problem." And we finally had the data to prove it, which is fantastic.

+ +

You know, we actually did a sample of 8,700 people on our platform, and we watched them for a year. And said, "How many different vendors are these 8,700 people going to use?" Because that's the marketplace we'd have to build because we have 91% employee engagement. Nobody can beat us in the industry. We've got the highest employee engagement of any platform in our category. So, how many different vendors could 8,700 people use in that time period? Do you guys have any guesses how many they used in that time period to get to that engagement?

+ +

VICTORIA: Out of 8,700 vendors?

+ +

AMY: No, 8,700 employees. So, how many different vendors they used in that time period.

+ +

VICTORIA: Hmm, like, per employee, I could see maybe, like, 10? I don't know. Two?

+ +

AMY: We saw 27,000 different vendors used across all the employees, so 27,000 different unique vendors. So, on average, every employee wants three unique vendors that no one else is using.

+ +

VICTORIA: Oh wow.

+ +

WILL: Wow.

+ +

VICTORIA: Yeah, okay. [laughter] Right.

+ +

AMY: So, it's just you can't build that, I mean, you could build that marketplace, but nobody's going to visit that marketplace because nobody wants to scroll through 27,000 things. And so, it just keeps changing.

+ +

You know, and I saw that even with the woman who started the company with me, you know, when she...we, of course, use Compt internally. And she started using her wellness stipend. You know, at first, she was doing 5Ks. So, she'd register for the race. She'd go train. She'd do all the things. Then she got pregnant and had a baby and started shifting over to prenatal vitamins, to Lamaze classes, to, you know, mommy yoga, things like that. Then once she had the baby, it shifted again.

+ +

And so, it allows for a company to flow with an employee's lifecycle without having to get into an employee's life stage and, "Hey, what do you need at this moment in time?" Employees can self-direct that, so it makes it easier for employees and a lot easier for companies who are not trying to...we don't want to map out every single moment of our employee's personal life. We shouldn't be involved in that. And so, this is a way to support them but also give them a little space too.

+ +

WILL: I absolutely love that because that is, yes, that is a flow. Like, before you have kids, it's, like, yes, I can go run these 5Ks; I can do this. When you have kids, it totally changes. Like, okay, what can I do with my kids? So, workout, or that's my away time. So, I love that it's an ebb and flow with the person. And they can pick their own thing, like --

+ +

AMY: Right. We're all adults.

+ +

WILL: Yes. [laughs]

+ +

AMY: I think I sat there going; why am I dictating someone's health and wellness regimen? I am not qualified for this on any stretch. Like, why am I dictating what somebody's mental health strategy should be? That's terrifying. You're adults. You work with your professionals. We'll support it.

+ +

WILL: Yes. I remember at one company I worked for; they had this gym that they had, you know, got a deal with. And I was so frustrated because I was like, that's, like, 45 minutes away from my house.

+ +

AMY: [laughs] Right.

+ +

WILL: It's a perk, but it means absolutely nothing to me. I can't use it. So yes, yeah. [laughs]

+ +

AMY: Well, and, like, not everybody wants to work, say...there was, you know, we see a lot of that is there's been a transition over time. COVID really changed that as people couldn't go to gyms, and companies shifted to stipends. But you may not want to work out with your co-workers, and that's okay, too. Like, it's okay to want to do your own thing and be in your own space, which is where we see this kind of decline of the, you know, on-site company gym, which, you know, some people just don't want to do that.

+ +

VICTORIA: Yeah. So, I love that you stayed true to this problem that you found and you backed it up with data. So, you're like, here's clear data on, say, why those VCs' advice was bad [laughs] about the marketplace.

+ +

AMY: Ill-informed. They needed data to see otherwise. [laughs]

+ +

VICTORIA: Yeah. Well, I'm curious about your experience going through fundraising and starting up for Compt with your background as a CFO and how that was for you.

+ +

AMY: It was...I naively thought it would be easier for me, and maybe it was because I had all this experience raising money as a CFO in all these prior companies. But the reality is that women receive less than 2% of all funding, even though we start 50% of the businesses. And if you look at, you know, Black female founders, they're receiving, like, 0.3, 0.5% of funding. Like, it's just...it's not nice out there.

+ +

You know, on average, a lot of VCs are looking at 3,000, 4,000, or 5000 different companies a year and investing in 10. And so, the odds of getting funded are very, very low, which means that you're just going to experience a whole lot of unique situations as a female founder. I saw that you folks work with LOLA, which is fantastic. I'm a huge fan of LOLA and kind of what their founders put together. And I've heard some amazing things about the pitches that she's done for VCs and that she's just not shy about what she's building. And I really appreciate that.

+ +

It's never a fun situation. And it gets easier the later stages because you have more metrics, and data, and all of that. And we ultimately found phenomenal investors that I'm very, very happy to have as part of our journey. But it's definitely...it's not pretty out there is the reality.

+ +

VICTORIA: Right. And I saw that you either attended or put on an event about the gender investment gap, which I think is what you just referred to there as well. So, I'm curious how that conversation went and if there were any insights about what the industry can do to promote more investment in women and people of color founders.

+ +

AMY: So, that's actually coming up August 10th, and so that's coming up in a few weeks that we're going to be hosting that. I'm actually part of a small group that is spearheading some legislation in Massachusetts to help change this funding dynamic for female founders, which I'm pretty excited about. And California also has some legislation they're looking at right now.

+ +

In Mass, we're looking at how fair lending laws can apply to venture capital. There are laws on the books on how capital gets distributed when you look at the banking system. But there's virtually no regulation when you look at venture funding, and there's no accountability, and there's no metrics that anybody is being held to.

+ +

I don't believe that you know, just because I pitched a VC that they should be funding me, you know, it needs to be part of their thesis and all of those things. But when you see so much disparity in what is happening out there, bias is coming into play. And there needs to be something that helps level that playing field. And so, that's where legislation comes into play and helps change that dynamic. So, pretty excited about the legislation that's before both the Senate and the Mass State House, likely going to be heard this November. So, we're pretty excited about that.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

WILL: So, Amy, you're talking a lot about diversity, inclusion, and just biases, and things like that. You're doing a great job with it. Your product is perfect for that because it reaches so many different levels. And I just want to ask you, why are you so passionate about it? Why is this so important to you?

+ +

AMY: For me, personally, I am a lesbian founder. I am the only, you know, LGBTQ in many of my companies. And I'm always the, I mean, very frequently, the only woman in the boardroom, the only woman on the leadership team. That's not super comfortable, honestly. When you are having to fight for your place at the table, and you see things that could be done differently because you're bringing a different perspective, that, to me, is a missed opportunity for companies and for employees as well who, you know, there's amazing talent out there. If you're only looking at one flavor of talent, you're missing the opportunity to really build a world-class organization.

+ +

And so, to me, it's both the personal side where I want to work with the best people. I want to work with a lot of different perspectives. I want to work with people who are bringing things to the table that I haven't thought about. But also, making sure that we're creating an environment where those people can feel comfortable as well, and so people don't feel marginalized or tokenized and have the ability to really bring their best selves to work. That's really important to me.

+ +

It's a reflection of the world around us. It's bringing out the best in all of us. And so, for me, that's the environment I want to create in my own company. And it's also what I want to help companies be able to foster within their companies because I think a lot of companies really do want that. They just don't know how to go about it. They don't have actual tools to support a diverse team. You pay for things for the people you have, and then you hire more people like the people you have. We want to be a tool to help them expand that very organically and make it a lot easier to support a broader perspective of people.

+ +

VICTORIA: I appreciate that. And it speaks to something you said earlier about 50% of the businesses are started by women. And so, if you're not investing in them, there's a huge market and huge potential and opportunity there that's just not --

+ +

AMY: The economic miss is in the trillions, is what's been estimated. Like, it's an absolute economic miss. I mean, you also have the statistics of what female-founded companies do. We tend to be more profitable. We tend to be more capital efficient. We tend to, you know, have better outcomes. It's just so the economics of it are there. It's just trying to get folks to understand where their biases are coming into play and funding things that may be a little outside their comfort zone.

+ +

VICTORIA: Right. That's going to be a big project to undo all of that. So, each piece that works towards it to break it down, I think, is really important. And it seems like Compt is a great tool for companies to start working towards that, at least in the equity of their benefits, which is -- [laughs]

+ +

AMY: Exactly. Because, I mean, if people can't use a perk, then it's inequitable compensation. And if you have inequitable compensation, you're already going down that path. You end up with wage gaps, and then you end up with promotion gaps. And all these things feed into each other. So, we're just trying to chip away at one piece of the problem. There's lots of places that this needs to be adjusted and changed over time. But we want to at least chip away at that one piece where this piece of compensation can be equitable and support everyone.

+ +

WILL: Yeah, I love that. I was looking at your LinkedIn. And it looks like you've been almost, later this year, maybe six years of Compt. What was some of the early traction? Like, how was it in the early days for you?

+ +

AMY: It was an interesting transition for me, going from CFO and COO over to the CEO role. That was easier in some ways than I thought it was going to be and harder in other ways. You know, on the easy side, I've already done fundraising. I understand how to write a business model, and look at financial plans, and make sure the concept is viable and all the things. But I also am not an engineer. I'm not a product designer.

+ +

And so needed to make sure we immediately surrounded ourselves with the right talent and the right help to make sure that we could build the right product, pull the things out of my brain that are conceptual but definitely not product design. No one wants me touching product design. I've been barred from all codebases in this company. They don't want me touching anything, with good reason. And so, making sure that we have those right people to build and design the software in a way that functionally makes sense.

+ +

VICTORIA: I think that is great that...I laughed when you said that you are barred from touching any of the code. [laughs] It's like, you're able to...I think a strong leader recognizes when other people have the expertise and makes space for them to do their best work. I also see that, at the same time, you've been a mentor with the MassChallenge group. And I'm curious if you have a most frequent piece of advice that you give to founders and people starting out building great products.

+ +

AMY: The biggest piece of advice, I think, is to make sure you're taking care of yourself through this process. It's an exhausting process to build a company. And there's always way more that you should be doing every day than you can possibly get done. And if you just completely absorb yourself in it, you're going to end up burning out. So, making sure that you rest, that you still make time to exercise and to move, and that you spend time with family. All of those things, I think, are really, really important. That's been part of our core tenets.

+ +

From day one, I said, "No more than 40 to 45 hours a week." It doesn't mean I'm not thinking about this business far more than 45 hours a week, but I'm not going to sit behind a computer that many hours in a week because I will burn out. And if I'm out and I'm reading something, or I'm, you know, going for a walk, I'm going to have moments of inspiration because I can actually have those creative thoughts firing when I'm not just putting out fires.

+ +

And so, I think that's really, really important for founders to make sure they take that time and allow their brains to clear a little bit so that they can build more efficiently, build faster, and have really good critical reasoning skills.

+ +

WILL: I love that you not only have the product to, you know, help taking time off, but you also are preaching it per se, like, take time off. Don't work more than 40-45 hours. Like, take care of yourself. So, I love that advice that you're giving is right in the message with your product. So, I love it.

+ +

AMY: Thank you. I do hammer home with this team. What we build is obviously very, very important to me, but how we build this company is equally important. We spend just as much time thinking about how we're building and designing this company internally as we do about our product because they need to be a virtuous cycle between the two, quite frankly. And so, if they aren't aligned, we're going to fail.

+ +

WILL: Definitely. Wow. Awesome. What does success look like for you and Compt in the next, you know, six months to a year?

+ +

AMY: For us, it's really about reaching as many people as possible. So, how do we have an impact on as many lives as possible and help people be able to access this piece of their compensation? What is interesting right now is we're in a really interesting moment. The tech industry is going through...shall we call it an awakening? Where money is tighter. There's been some layoffs. You know, it's just a very different world in tech right now. And everybody's in a little bit of a holding pattern to figure out, okay, what's next?

+ +

What we're seeing across our portfolio of companies is that there's a lot of industries that are, for the first time, really thinking about how do we retain folks? How do we think about hiring in a new way? So, industries like construction and manufacturing. Industries that never had employee kind of lifestyle benefits or perks they're taking a look at that because unemployment is so, so low.

+ +

And so, for the first time ever, we have the ability to have an impact on groups that never had access to professional development, to wellness, to things like that. And that's really exciting because you can have such a huge, impactful moment where people have just been without for so long. And so, that's pretty exciting for us.

+ +

VICTORIA: You're touching upon a topic that I've thought about before, where in the tech industry, we're used to having a lot of benefits and perks and that not every industry is the same way. So, I'm curious; you mentioned construction and some other groups that are looking to adopt more of these benefits because unemployment is so low. I'm curious, like, if there are any patterns or things that you see, like, specific industries that are more interested than others, or what's going on there?

+ +

AMY: Our portfolio of tech companies are only about...they're less than 40% of our customers, actually. So, a relatively low percentage of our customers come from the tech industry. What we find is that healthcare systems this is really important. As you're thinking about how you're going to retain nursing staff, it is incredibly difficult. And so, we see a lot of movement in the healthcare space. We see a lot of movement, again, across manufacturing and construction, you know, financial services.

+ +

Pretty much anybody who is struggling to hire and is worried about retaining is trying to figure out what's my strategy? How do I do this in the least expensive way possible but reach everyone? Because those employee engagement metrics are so consistently important to look at. And most platforms and things that you could be doing out there are going to give you a 2% to 3% utilization. So, it's very, very low.

+ +

You know, wellness is by far the most common use case we see companies putting in place. It's good for employees. It's good for the employer. That's by far the most important or the most common. But we also see things like family, and just more of a whole well-being kind of concept as well, so beyond wellness, so allowing for that broader reach.

+ +

We're also seeing industries where people are starting to age out. So, we've got five generations at work right now. There's industries where folks have historically stayed forever. You know, you've got the people who have been there 20-30 years. Well, those same industries are now sitting there going, all right, how do I get the next two generations to come in here? Because it's such an old-guard and old approach. We've got to change things up. And so, we're seeing a pretty big cultural shift happen within a lot of these more nascent industries.

+ +

WILL: Yeah. I can definitely see how that would be tough going from, you know, you said five generations are currently in the workforce?

+ +

AMY: Yep.

+ +

WILL: I didn't even think about that. Wow.

+ +

AMY: Yeah, you got a lot of different parts of the life cycle. You know, think about professional development. Professional development for a 22-year-old is very different from professional development for a 65-year-old. But both are in the workplace, and both want to keep learning. It's just what your needs are and what you need to learn. And how you want to learn is going to be very, very different.

+ +

WILL: Wow. So true. I love how you're talking about your leadership and just the way you lead. I can just hear it in what you're saying. What are some of your core values that drive you every day?

+ +

AMY: One of the big ones, and it probably goes back to, you know, I'm sure, birth placement, whatever. I'm an oldest child, all the things that come with being an oldest child. But fairness is a really big one for me. And so, it's thinking about how we apply that as a company, so equitable compensation falls under that. Making sure that we've got a team that is balanced and diverse is really important to me.

+ +

You know, thinking, you know, our core values are balance and belonging. That runs through absolutely everything that we do and is core and central to it. Because, again, how we build this company is just as important to me as what we're building. And so, making sure that we hold true to those values is critical because we have amazing people, and they need to feel supported as well.

+ +

VICTORIA: Well, that really comes through in everything that you say and that we've talked about so far today, and I really appreciate that. And I'm curious if you could go back in time to when you first started Compt and tell yourself any piece of advice or information; what would you say?

+ +

AMY: That piece of advice has changed over time; I will tell you that. The one that is most recent for me is really because we're an HR tech platform, and we service, you know, an entire organization, is really thinking about how you support different industries at different moments in time, the concept of product-market fit. When you're that type of a platform, which there aren't many, there's not many platforms that sit across an entire organization, but compensation is one of them. You need to be thinking about which industries are struggling to hire, which are struggling to retain at this moment in time.

+ +

And so, I don't think there's one place, like, hey, we have product-market fit, now we can scale. I think that's a misnomer for our part of the HR tech space. And so, it's constant experimentation on go-to-market strategy and constant kind of adjustment as markets ebb and flow over time.

+ +

WILL: What is some of your biggest hurdles right now or even in the future that you can see coming?

+ +

AMY: If I had a crystal ball, life would definitely be easier. I'd love to know when this economic cycle is going to shift and, you know when things get a little bit easier for companies. You know, HR leaders and finance leaders are not having the most fun at this moment in time. They're being tasked with making everybody happy but on very small budgets, and so they're really challenged with that. And they're really burnt out, and they're exhausted. So, I'm looking forward to a shift so when people can get back to feeling a little bit physically better. But also, it just helps navigate a market and be better able to support your employees.

+ +

VICTORIA: I've been thinking about that question recently, what I would tell my past self, and I think it's mostly, like, food related.

+ +

[laughter]

+ +

AMY: Ooh, interesting.

+ +

VICTORIA: Use better vinegars, like, invest in fancier olive oil. [laughs]

+ +

AMY: So, my new luxury pro-tip is you buy a $7 bunch of eucalyptus at the grocery store, and you tie it above your shower head. I'm not kidding; you will feel like you're at a spa. It costs $7. I learned it because I was at some fancy resort. One of my investors, you know, paid for us to go to a conference that I was not paying for. And I was like, that is genius. You suddenly feel like you are in someplace fancy, and it was seven bucks. It's amazing.

+ +

WILL: Yes.

+ +

VICTORIA: That sounds incredible. I'm going to do that.

+ +

WILL: Same.

+ +

[laughter]

+ +

VICTORIA: [inaudible 34:35] buy some. No, it's so good. Do you have any questions for us, Amy?

+ +

AMY: Yeah. I mean, what trends are you seeing in the market right now? Like, what types of companies are being developed? Where do you see growth happening in the market?

+ +

VICTORIA: That's probably a better question for me. As a managing director, I spend more time networking and going to events. And it's interesting being in San Diego. There's a big biotech startup here. So, I went to an EvoNexus Demo Day and saw the things that people were using. And there seemed to be a trend of using AI and machine learning to create better health outcomes, whether that's for predictors for which people will respond better to anti-cancer drugs, or, you know, how do we monitor the release of drugs for someone's system who's, you know, going through methadone in therapy. So, it's really interesting.

+ +

I think that you know, you mentioned that there's not the same amount of money in the tech market, but I think there is still a lot of work being done to solve real problems that people have. So yeah, I'm really curious to see those types of projects and which ones are going to be successful, and how much the AI trend will really fade out. Like, clearly, in some use cases, you can see how beneficial it could be. And other times, it seems like it's kind of just like slapped on there for --

+ +

AMY: Agreed.

+ +

VICTORIA: Marketing purposes, so...

+ +

AMY: That's really just a database query. It's not AI. [laughs]

+ +

VICTORIA: Right. [laughs] It's interesting because, you know, I just had lunch with a bunch of other CTOs in San Diego, and we were talking about AI, and some of the inherent risks of it, and the damage it can cause. And I always like to bring it back to, like, there are some people who are already harmed by these trends. And we have to work around that. Like, there is some, you know, greater supposed existential threat with AI that I think is rather unlikely. But if we think about that too much and not focus on the current harm that's being done, then that's, you know, more dangerous than the other one.

+ +

AMY: Yeah. No, absolutely. I mean, there's definitely, I mean, even just with facial recognition and how that's applied and what that's used for. I mean, any software that is built with people has bias. And so, whatever biases they're bringing into it is the bias that's going to exist in the software. And so, there's...we already are starting from, you know, going back to our earlier conversation, if companies are not diverse and not building for really diverse perspectives, they're inherently going to build bias software, whether or not, I mean, I don't think that's anybody's intention. But that's what's going to happen because you just didn't think about things you didn't know.

+ +

VICTORIA: Right. And, of course, I'm here in Southern California. There's the strikes for the actors and writers' strike happening a few hours north of us. And they were actually, you know, for some actors, signing away their rights to their likeness.

+ +

AMY: Wow.

+ +

VICTORIA: And then they could make an AI image and --

+ +

AMY: Wow. You could just create an entire movie with somebody's image and dub in a voice, and suddenly you don't need actors.

+ +

VICTORIA: Right. And it's, of course, more often non-White actors and models who are being replaced. And so, I think that's a very interesting trend that people may not have thought about yet.

+ +

AMY: Fascinating.

+ +

VICTORIA: So yeah, I mean, having people on your leadership team who are thinking about these [laughs] different types of issues, like, yeah, I think it's really important. And then also, from, like, a data privacy perspective, all the laws that are coming out and that have come out. And I think that some founders and CTOs are really struggling with how to comply and protect everyone's data that way.

+ +

AMY: No. It's something we think about a lot because we have the potential to have access to a lot of employee data. We take a very minimalist approach stated, not a big data play. That's not what we're here for. That's not what we're trying to do, this mountain of data on people, and then we'll figure out how to monetize it. We want to build something a little bit different. And so using only data that needs to be used so that we can truly support people with what our actual goal and aim is, rather than having that be a secondary cause.

+ +

VICTORIA: Yeah. And I wanted to ask you about that actually because you have SOC 2 and GDPR compliance. And it's a topic that I think a lot of founders know that security is important, but it can be a significant investment. So, I'm curious your trade-offs and your timing for when you went for those compliance frameworks.

+ +

AMY: We went early for it. I mean, so our platform, I mean, we're integrated with payroll platforms. We're touching employee data. So, we went for it early because we knew that it was going to be important, and it's a lot easier to do it before you make a mess than it is after the fact. I've done SOC 2 compliance in two prior companies. It's not fun. It is not my most fun thing that I've ever done.

+ +

Fortunately, there are geniuses out there who built platforms to make this very, very easy now. We use a platform called Vanta that is absolutely incredible, made it super easy to get SOC 2 compliant, go through our audits, do all the things, so that, at least, is a lot easier. But it was something that we needed the funding to invest in. It's not inexpensive.

+ +

But we knew that it was going to be critical because people need to feel that their data is secure and that you know what you're doing, and that you're not just kind of flying by the seat of your pants. There's a lot of tech companies that operate on, we'll figure out the tax, or we'll figure out the law. We'll figure out the compliance later. And that's been a stated part of their mission. That's just not the way I'm going to operate. And that doesn't work very well when you're dealing with HR, quite frankly, or finance because we have to comply with laws. So, getting ahead of that early was part of our strategy.

+ +

VICTORIA: That makes sense. Your finance background making it clear what the legal implications are. [laughs]

+ +

AMY: Exactly. Like, I'm not messing around with the IRS. Nobody wants to get audited by the IRS. It's not fun. Let's just keep things tax compliant. Chances are you're not going to get audited by the IRS. But if you are a tech company, if you do want to go public, if you do want to be acquired likely from a public company, you have to have these things in order because otherwise, it's coming off your purchase price or your stock price because you've got disclosures you've got to put out there, so little hidden, nasty gotchas.

+ +

And it can be a six-year lookback period. So, you're like, oh, I'll worry about it later. Six years is a long time. And if you start messing around with that, it gets very, very expensive to clean up. So, just do it right from the beginning. You know, the same way you're doing payroll correctly now, invest a little bit, and it makes it a lot easier.

+ +

VICTORIA: Yeah, I agree. And I think the tooling that's out there makes it a little bit easier; at least then, you know you have the confidence that your data is protected. Especially if you're a non-technical founder, I can imagine that makes you feel better that things are the way they should be.

+ +

AMY: Exactly. Somebody has looked at this thing. Somebody is making sure that it's working the way it's supposed to. You know, that definitely helps when you're a non-technical founder, or just not a tax expert, or a legal expert, you know, around these things. It's not even the technical founders that have to worry about it. Data comes in all kinds of forms.

+ +

VICTORIA: Yeah, that makes a lot of sense.

+ +

AMY: This has been a fantastic conversation. I've really enjoyed it.

+ +

VICTORIA: Well, thank you.

+ +

WILL: Same.

+ +

VICTORIA: I've enjoyed it as well. I really appreciate you taking the time.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Amy Spurling.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Amy Spurling is the Founder and CEO of Compt, helping companies build and scale flexible perks, stipends that delight teams. She explains how Compt's approach to benefits aligns with an employee's life stages, and shares insights from data that revealed the vast diversity of vendors utilized by employees.

+ +

Amy talks about fundraising for Compt, highlighting the gender investment gap and the difficulties faced by female founders. She also shares her personal experiences as a lesbian founder and emphasizes the importance of a diverse workforce. She outlines Compt's mission to provide equitable compensation and foster a broader perspective within companies, the economic miss of not investing in female-founded companies, and the complexities of transitioning into different roles within a startup.

+ +

Amy's leadership values of balance and belonging are explored, and she shares insights about navigating hurdles like SOC 2 and GDPR compliance. Additionally, they talk about trends in the tech industry, such as AI's use in healthcare and the potential for bias in software, along with data privacy issues.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Amy Spurling, Founder and CEO of Compt, helping companies build and scale flexible perks, stipends that delight teams. Amy, thank you for joining.

+ +

AMY: Thanks so much for having me.

+ +

VICTORIA: Amy, I saw in your LinkedIn background that you have a picture of someone hiking in what looks like a very remote area. So, just to start us off today, I wonder if you could tell us a little bit more about that. And what's your hobby there?

+ +

AMY: Sure. I do spend a lot of time backpacking. That picture, I believe, was actually taken in Mongolia a couple of years ago. We spent ten days kind of hiking around in, I mean, everything is backcountry basically in Mongolia. So, spending a lot of time walking around, looking at mountains, is kind of my pastime.

+ +

WILL: I have a question around backpacking itself. When you say backpacking, what does that mean? Does it mean you only have a backpack, and you're out in the mountains, and you're just enjoying life?

+ +

AMY: It depends. So, in Mongolia, there were a couple of folks with camels, so carrying the heavy gear for us but still living in tents. My wife and I just did a backpacking trip in the Accursed Mountains in Albania, though, and everything was on our backpack. So, you're carrying a 35-pound pack. It has all your food, your water, your camping gear, and you just go. And you're just kind of living off the land kind of. I mean, you're taking food, so it's not like I'm foraging or hunting but living in the outback.

+ +

WILL: Wow. What does that do for you just internally, just getting off the grid, enjoying nature? Because I know with tech and everything now, it's kind of hard to do that. But you've done that, I think you said, for ten days. Like, walk us through that experience a little bit.

+ +

AMY: Some people use yoga, things like that, to go to a zen place, be calm, you know, help quiet their mind. For me, I need to do something active, and that's what I use this for. So getting off away from my phone, away from my laptop—those are not available to me when I'm in the mountains—and just focusing on being very present and listening to the birds, smelling the flowers. You know, pushing myself to where I'm, you know, exerting a lot of energy hiking and just kind of being is just...it's pretty fantastic.

+ +

VICTORIA: And I'm curious, what brought you to decide to go to Albania to get to that experience? Because that's not a top destination for many people. But --

+ +

AMY: It is not. So, we travel a fair amount, and we backpack a fair amount. And the mountains there are honestly some of the most beautiful I've seen anywhere in the world. And so, we're always looking for, where can you get off the grid pretty quickly? Where can you be in the mountains pretty quickly in a way that still has a path so that you're not putting yourself in danger? Unless...I mean, we've done that too.

+ +

But you want to make sure you have a guide, obviously, if you're going completely no path, no trail kind of camping, too. But it just looked really beautiful. We planned it actually for three years ago and had to cancel because it was May of 2020. And so, we've had this trip kind of on the books and planned for it for a while.

+ +

VICTORIA: That's awesome. Yeah, I know of Albania because I had a friend who worked there for a few years. And she said the rock climbing there is amazing. And it actually has one of the last wild rivers in Europe. So, it's just a very remote, very interesting place. So, it's funny that you went there [laughs]. I was like, wait, other people also go to Albania. That's awesome. I love the outdoor space.

+ +

Well, what a great perk or benefit to working to be able to take those vacations and take that time off and spend it in a way that makes you feel refreshed. Tell me more about Compt and your background. What led you to found this company?

+ +

AMY: Sure. I've been in tech companies for, you know, over 20 years. I've been a CFO, a COO building other people's dreams, so coming in as a primary executive, you know, first funding round type of person, help scale the team, manage finance and HR. And I loved doing that, but I got really frustrated with the lack of tools that I needed to be able to hire people and to retain people. Because the way we compensate people has changed for the last 10, 15 years.

+ +

And so, ultimately, decided to build a platform to solve my own problem and my own team's problems, and started that getting close to six years ago now. But wanted to build a tech company in a very different way as well. So, in the same way, I take time off, I want my team to take time off. So, we operate on a basis of everyone should be taking their time off. Don't check in while you're out. We'll make sure we're covered. You know, let's build a sustainable business here. And everybody should be working 40 to 45 hours a week, which is definitely not a startup culture or norm.

+ +

WILL: Yeah. I love that. I was doing some research on Compt. And so, in your words, can you explain to everyone exactly what your company does?

+ +

AMY: Sure. So, we build lifestyle benefit accounts for companies. And what that means...and the terminology keeps changing, so some people may call them stipends or allowances. But it's really looking at how you pull together employee perks, benefits that will help compete for talent. And right now, retention is kind of the key driver for most companies. How do I keep the people I have really happy?

+ +

Competitive salaries are obviously table stakes. Health insurance for most industries is table stakes. So, it's, what else are you offering them? You can offer a grab bag of stuff, which a lot of companies try and do, but you get very low utilization. Or you can do something like a stipend or a lifestyle spending account, which is what we build, which allows for complete flexibility so that every employee can do something different. So that even if you're offering wellness, you know, what the three of us think about as wellness is likely very different.

+ +

I spend a lot of money at REI, like, they are basically, like, as big as my mortgage. I spend so much money there because I want backpacking gear. Wellness for you folks may be a little bit different. And so, allowing for that personalization so everybody can do something that matters to them.

+ +

VICTORIA: Right. And I love that it comes from a problem you found in your own experience of working with early-stage startups and being on the executive level and finance and building teams from the ground up. So, I'm curious, what lessons did you find in your previous roles that were maybe ten times more important when you started your own company?

+ +

AMY: I learned so much through all of my prior companies and pulled in the lessons of the things that worked really well but then also the things that it was, like, wow, I would definitely do that different. DEI is very important to us. I knew building a diverse team was going to be a competitive advantage for us. And none of my prior teams really met that mark. You know, most of them were Boston-based, the usual kind of profile of a tech company: 85%-95% White guys, mostly from MIT, you know, very, very talented, but also coached and trained by the same professors for the last 20 years.

+ +

So, I knew I wanted different perspectives around the table, and that was going to be really key. So, looking at non-traditional backgrounds, especially as we were looking at hiring engineers, for instance, that was really interesting to me because I knew that would be part of our competitive advantage as we started building up this platform that is employee engagement but very much a tax compliance and budgeting tool as well.

+ +

VICTORIA: I love hearing that. And it's something I've heard from actually thoughtbot's founder, Chad. That is something he wished he invested more in when he first started it. So, I'm curious as to how that's played out from when you started to where you are now. You said, I think, it's been six years, right?

+ +

AMY: January will be six years, so five and a half-ish, I guess, right now. I mean, it was a stated part of what we were going to do from day one. All of my prior companies wanted that as well. I don't think anybody starts out and says, "Hey, I'd really love a one-note company." No one says that. Everybody thinks that they're doing the right things and hiring the best talent. But what you do is you end up hiring from your network, which usually looks just like you.

+ +

And when you get to be, you know, 100, 150 people and you're looking around going, wow, we have some gaps here, it's really hard to fill them because who wants to be the first and the only of whatever? You know, I've been the only woman on most management teams.

+ +

So, for us, it was day one, make it part of the focus and make sure we're really looking for the best talent and casting a very wide net. So, right now, we're sitting at 56% female and 36% people of color, and somewhere around 18%-19% LGBTQIA. So, we're trying to make sure that we're attracting all those amazing perspectives.

+ +

And they're from people from around the country, which I also think is really important when you're building a tech company. Don't just build in areas where you're in your little tech bubble. If you want to build a product that actually services everyone, you need to have other kind of cultural and country perspectives as well.

+ +

VICTORIA: Yeah. And that makes perfect sense for what you described earlier for Compt, that it is supposed to be flexible to provide health benefits or wellness benefits to anyone. And there can be a lot of different definitions of that. So, it makes sense that your team reflects the people that you're building for.

+ +

AMY: Exactly.

+ +

WILL: Yeah. How does that work? How does Compt accomplish that? Because I know early on I was doing nonprofits and I was a decent leader. But I struggle to get outside of myself, my own bubble if that makes sense. So, like, that was before I had kids. I had no idea what it meant to have kids and just the struggles and everything if you have kids. So, there's so many different things that I've learned over the years that, like, just people have their own struggles. So, how does Compt accomplish the diversity of a company?

+ +

AMY: So, it's so interesting you mentioned that. I was on a podcast the other day with somebody who was, like, "You know, we didn't really think about our benefits and how important they were." And then, the founder who was the person on the podcast, and he was like, "But then I had kids. And suddenly, I realized, and we had this amazing aha moment." I'm like, well, it's great you had the aha moment. But let's back it up and do this before the founder has children. Sometimes you need to recognize the entire team needs something different and try and support them.

+ +

My frustration with the tools out there are there are tools that are like, hey, we're a DE&I platform. We will help you with that. You know, we've got a benefit for fertility. We've got a benefit for, you know, elder care. There's all kinds of benefits. These are great benefits, but they're also very, very specific in how they support an employee. And it's very small moment in time, usually.

+ +

Whereas with something like Compt, where we say, "Hey, we support family," your version of family, having children is very different from my version of family, where I don't have children, but we both have families. And we can both use that stipend in a way that is meaningful for us. What puts the employee back in charge, what matters in their lives, instead of the company trying to read everyone's mind, which is honestly a no-win situation for anyone. So, it just makes it very, very broad.

+ +

VICTORIA: Yes. And I've been on both sides, obviously, as an employee, but also previously role of VP of Operations. And trying to design benefits packages that are appealing, and competitive, and fair is a challenging task. So --

+ +

AMY: It's impossible. It's impossible. [laughs]

+ +

VICTORIA: Very hard. And I'm curious what you found in the early stages of Compt that was surprising to you in the discovery process building the product.

+ +

AMY: So, for me, I mean, discovery was I am the buyer for this product. So, I wanted this about five years before I decided to go and build it. And I was talking to other finance and HR professionals going around going, "All right, are you feeling this exact same pain that I'm feeling? Because it is getting completely insurmountable."

+ +

We were all being pitched all these different platforms and products. Everybody had something they wanted to sell through HR to help attract, and engage and retain talent and all the things, right? But there's no tracking. It's not taxed correctly. And ultimately, no matter what you bring in, maybe 2% to 3% of your team would use it. So, you're spending all this time and energy in putting all this love into wanting to support your team, and then nobody uses the stuff that you bring in because it just doesn't apply to them.

+ +

And so, I realized, like, my pivotal moment was, all right, none of this is working. I've been waiting five years for somebody to build it. Let's go build something that is completely vendor-agnostic. There's no vendors on this platform by design because everyone ultimately wants something different.

+ +

And, you know, through that process, we were, of course, pushed by many VCs who said, "Hey, build your marketplace, build your marketplace, you know, that's going to be your moat and your special sauce." And I said, "No, no, no, that's not what we're going to do here because that doesn't solve that problem." And we finally had the data to prove it, which is fantastic.

+ +

You know, we actually did a sample of 8,700 people on our platform, and we watched them for a year. And said, "How many different vendors are these 8,700 people going to use?" Because that's the marketplace we'd have to build because we have 91% employee engagement. Nobody can beat us in the industry. We've got the highest employee engagement of any platform in our category. So, how many different vendors could 8,700 people use in that time period? Do you guys have any guesses how many they used in that time period to get to that engagement?

+ +

VICTORIA: Out of 8,700 vendors?

+ +

AMY: No, 8,700 employees. So, how many different vendors they used in that time period.

+ +

VICTORIA: Hmm, like, per employee, I could see maybe, like, 10? I don't know. Two?

+ +

AMY: We saw 27,000 different vendors used across all the employees, so 27,000 different unique vendors. So, on average, every employee wants three unique vendors that no one else is using.

+ +

VICTORIA: Oh wow.

+ +

WILL: Wow.

+ +

VICTORIA: Yeah, okay. [laughter] Right.

+ +

AMY: So, it's just you can't build that, I mean, you could build that marketplace, but nobody's going to visit that marketplace because nobody wants to scroll through 27,000 things. And so, it just keeps changing.

+ +

You know, and I saw that even with the woman who started the company with me, you know, when she...we, of course, use Compt internally. And she started using her wellness stipend. You know, at first, she was doing 5Ks. So, she'd register for the race. She'd go train. She'd do all the things. Then she got pregnant and had a baby and started shifting over to prenatal vitamins, to Lamaze classes, to, you know, mommy yoga, things like that. Then once she had the baby, it shifted again.

+ +

And so, it allows for a company to flow with an employee's lifecycle without having to get into an employee's life stage and, "Hey, what do you need at this moment in time?" Employees can self-direct that, so it makes it easier for employees and a lot easier for companies who are not trying to...we don't want to map out every single moment of our employee's personal life. We shouldn't be involved in that. And so, this is a way to support them but also give them a little space too.

+ +

WILL: I absolutely love that because that is, yes, that is a flow. Like, before you have kids, it's, like, yes, I can go run these 5Ks; I can do this. When you have kids, it totally changes. Like, okay, what can I do with my kids? So, workout, or that's my away time. So, I love that it's an ebb and flow with the person. And they can pick their own thing, like --

+ +

AMY: Right. We're all adults.

+ +

WILL: Yes. [laughs]

+ +

AMY: I think I sat there going; why am I dictating someone's health and wellness regimen? I am not qualified for this on any stretch. Like, why am I dictating what somebody's mental health strategy should be? That's terrifying. You're adults. You work with your professionals. We'll support it.

+ +

WILL: Yes. I remember at one company I worked for; they had this gym that they had, you know, got a deal with. And I was so frustrated because I was like, that's, like, 45 minutes away from my house.

+ +

AMY: [laughs] Right.

+ +

WILL: It's a perk, but it means absolutely nothing to me. I can't use it. So yes, yeah. [laughs]

+ +

AMY: Well, and, like, not everybody wants to work, say...there was, you know, we see a lot of that is there's been a transition over time. COVID really changed that as people couldn't go to gyms, and companies shifted to stipends. But you may not want to work out with your co-workers, and that's okay, too. Like, it's okay to want to do your own thing and be in your own space, which is where we see this kind of decline of the, you know, on-site company gym, which, you know, some people just don't want to do that.

+ +

VICTORIA: Yeah. So, I love that you stayed true to this problem that you found and you backed it up with data. So, you're like, here's clear data on, say, why those VCs' advice was bad [laughs] about the marketplace.

+ +

AMY: Ill-informed. They needed data to see otherwise. [laughs]

+ +

VICTORIA: Yeah. Well, I'm curious about your experience going through fundraising and starting up for Compt with your background as a CFO and how that was for you.

+ +

AMY: It was...I naively thought it would be easier for me, and maybe it was because I had all this experience raising money as a CFO in all these prior companies. But the reality is that women receive less than 2% of all funding, even though we start 50% of the businesses. And if you look at, you know, Black female founders, they're receiving, like, 0.3, 0.5% of funding. Like, it's just...it's not nice out there.

+ +

You know, on average, a lot of VCs are looking at 3,000, 4,000, or 5000 different companies a year and investing in 10. And so, the odds of getting funded are very, very low, which means that you're just going to experience a whole lot of unique situations as a female founder. I saw that you folks work with LOLA, which is fantastic. I'm a huge fan of LOLA and kind of what their founders put together. And I've heard some amazing things about the pitches that she's done for VCs and that she's just not shy about what she's building. And I really appreciate that.

+ +

It's never a fun situation. And it gets easier the later stages because you have more metrics, and data, and all of that. And we ultimately found phenomenal investors that I'm very, very happy to have as part of our journey. But it's definitely...it's not pretty out there is the reality.

+ +

VICTORIA: Right. And I saw that you either attended or put on an event about the gender investment gap, which I think is what you just referred to there as well. So, I'm curious how that conversation went and if there were any insights about what the industry can do to promote more investment in women and people of color founders.

+ +

AMY: So, that's actually coming up August 10th, and so that's coming up in a few weeks that we're going to be hosting that. I'm actually part of a small group that is spearheading some legislation in Massachusetts to help change this funding dynamic for female founders, which I'm pretty excited about. And California also has some legislation they're looking at right now.

+ +

In Mass, we're looking at how fair lending laws can apply to venture capital. There are laws on the books on how capital gets distributed when you look at the banking system. But there's virtually no regulation when you look at venture funding, and there's no accountability, and there's no metrics that anybody is being held to.

+ +

I don't believe that you know, just because I pitched a VC that they should be funding me, you know, it needs to be part of their thesis and all of those things. But when you see so much disparity in what is happening out there, bias is coming into play. And there needs to be something that helps level that playing field. And so, that's where legislation comes into play and helps change that dynamic. So, pretty excited about the legislation that's before both the Senate and the Mass State House, likely going to be heard this November. So, we're pretty excited about that.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

WILL: So, Amy, you're talking a lot about diversity, inclusion, and just biases, and things like that. You're doing a great job with it. Your product is perfect for that because it reaches so many different levels. And I just want to ask you, why are you so passionate about it? Why is this so important to you?

+ +

AMY: For me, personally, I am a lesbian founder. I am the only, you know, LGBTQ in many of my companies. And I'm always the, I mean, very frequently, the only woman in the boardroom, the only woman on the leadership team. That's not super comfortable, honestly. When you are having to fight for your place at the table, and you see things that could be done differently because you're bringing a different perspective, that, to me, is a missed opportunity for companies and for employees as well who, you know, there's amazing talent out there. If you're only looking at one flavor of talent, you're missing the opportunity to really build a world-class organization.

+ +

And so, to me, it's both the personal side where I want to work with the best people. I want to work with a lot of different perspectives. I want to work with people who are bringing things to the table that I haven't thought about. But also, making sure that we're creating an environment where those people can feel comfortable as well, and so people don't feel marginalized or tokenized and have the ability to really bring their best selves to work. That's really important to me.

+ +

It's a reflection of the world around us. It's bringing out the best in all of us. And so, for me, that's the environment I want to create in my own company. And it's also what I want to help companies be able to foster within their companies because I think a lot of companies really do want that. They just don't know how to go about it. They don't have actual tools to support a diverse team. You pay for things for the people you have, and then you hire more people like the people you have. We want to be a tool to help them expand that very organically and make it a lot easier to support a broader perspective of people.

+ +

VICTORIA: I appreciate that. And it speaks to something you said earlier about 50% of the businesses are started by women. And so, if you're not investing in them, there's a huge market and huge potential and opportunity there that's just not --

+ +

AMY: The economic miss is in the trillions, is what's been estimated. Like, it's an absolute economic miss. I mean, you also have the statistics of what female-founded companies do. We tend to be more profitable. We tend to be more capital efficient. We tend to, you know, have better outcomes. It's just so the economics of it are there. It's just trying to get folks to understand where their biases are coming into play and funding things that may be a little outside their comfort zone.

+ +

VICTORIA: Right. That's going to be a big project to undo all of that. So, each piece that works towards it to break it down, I think, is really important. And it seems like Compt is a great tool for companies to start working towards that, at least in the equity of their benefits, which is -- [laughs]

+ +

AMY: Exactly. Because, I mean, if people can't use a perk, then it's inequitable compensation. And if you have inequitable compensation, you're already going down that path. You end up with wage gaps, and then you end up with promotion gaps. And all these things feed into each other. So, we're just trying to chip away at one piece of the problem. There's lots of places that this needs to be adjusted and changed over time. But we want to at least chip away at that one piece where this piece of compensation can be equitable and support everyone.

+ +

WILL: Yeah, I love that. I was looking at your LinkedIn. And it looks like you've been almost, later this year, maybe six years of Compt. What was some of the early traction? Like, how was it in the early days for you?

+ +

AMY: It was an interesting transition for me, going from CFO and COO over to the CEO role. That was easier in some ways than I thought it was going to be and harder in other ways. You know, on the easy side, I've already done fundraising. I understand how to write a business model, and look at financial plans, and make sure the concept is viable and all the things. But I also am not an engineer. I'm not a product designer.

+ +

And so needed to make sure we immediately surrounded ourselves with the right talent and the right help to make sure that we could build the right product, pull the things out of my brain that are conceptual but definitely not product design. No one wants me touching product design. I've been barred from all codebases in this company. They don't want me touching anything, with good reason. And so, making sure that we have those right people to build and design the software in a way that functionally makes sense.

+ +

VICTORIA: I think that is great that...I laughed when you said that you are barred from touching any of the code. [laughs] It's like, you're able to...I think a strong leader recognizes when other people have the expertise and makes space for them to do their best work. I also see that, at the same time, you've been a mentor with the MassChallenge group. And I'm curious if you have a most frequent piece of advice that you give to founders and people starting out building great products.

+ +

AMY: The biggest piece of advice, I think, is to make sure you're taking care of yourself through this process. It's an exhausting process to build a company. And there's always way more that you should be doing every day than you can possibly get done. And if you just completely absorb yourself in it, you're going to end up burning out. So, making sure that you rest, that you still make time to exercise and to move, and that you spend time with family. All of those things, I think, are really, really important. That's been part of our core tenets.

+ +

From day one, I said, "No more than 40 to 45 hours a week." It doesn't mean I'm not thinking about this business far more than 45 hours a week, but I'm not going to sit behind a computer that many hours in a week because I will burn out. And if I'm out and I'm reading something, or I'm, you know, going for a walk, I'm going to have moments of inspiration because I can actually have those creative thoughts firing when I'm not just putting out fires.

+ +

And so, I think that's really, really important for founders to make sure they take that time and allow their brains to clear a little bit so that they can build more efficiently, build faster, and have really good critical reasoning skills.

+ +

WILL: I love that you not only have the product to, you know, help taking time off, but you also are preaching it per se, like, take time off. Don't work more than 40-45 hours. Like, take care of yourself. So, I love that advice that you're giving is right in the message with your product. So, I love it.

+ +

AMY: Thank you. I do hammer home with this team. What we build is obviously very, very important to me, but how we build this company is equally important. We spend just as much time thinking about how we're building and designing this company internally as we do about our product because they need to be a virtuous cycle between the two, quite frankly. And so, if they aren't aligned, we're going to fail.

+ +

WILL: Definitely. Wow. Awesome. What does success look like for you and Compt in the next, you know, six months to a year?

+ +

AMY: For us, it's really about reaching as many people as possible. So, how do we have an impact on as many lives as possible and help people be able to access this piece of their compensation? What is interesting right now is we're in a really interesting moment. The tech industry is going through...shall we call it an awakening? Where money is tighter. There's been some layoffs. You know, it's just a very different world in tech right now. And everybody's in a little bit of a holding pattern to figure out, okay, what's next?

+ +

What we're seeing across our portfolio of companies is that there's a lot of industries that are, for the first time, really thinking about how do we retain folks? How do we think about hiring in a new way? So, industries like construction and manufacturing. Industries that never had employee kind of lifestyle benefits or perks they're taking a look at that because unemployment is so, so low.

+ +

And so, for the first time ever, we have the ability to have an impact on groups that never had access to professional development, to wellness, to things like that. And that's really exciting because you can have such a huge, impactful moment where people have just been without for so long. And so, that's pretty exciting for us.

+ +

VICTORIA: You're touching upon a topic that I've thought about before, where in the tech industry, we're used to having a lot of benefits and perks and that not every industry is the same way. So, I'm curious; you mentioned construction and some other groups that are looking to adopt more of these benefits because unemployment is so low. I'm curious, like, if there are any patterns or things that you see, like, specific industries that are more interested than others, or what's going on there?

+ +

AMY: Our portfolio of tech companies are only about...they're less than 40% of our customers, actually. So, a relatively low percentage of our customers come from the tech industry. What we find is that healthcare systems this is really important. As you're thinking about how you're going to retain nursing staff, it is incredibly difficult. And so, we see a lot of movement in the healthcare space. We see a lot of movement, again, across manufacturing and construction, you know, financial services.

+ +

Pretty much anybody who is struggling to hire and is worried about retaining is trying to figure out what's my strategy? How do I do this in the least expensive way possible but reach everyone? Because those employee engagement metrics are so consistently important to look at. And most platforms and things that you could be doing out there are going to give you a 2% to 3% utilization. So, it's very, very low.

+ +

You know, wellness is by far the most common use case we see companies putting in place. It's good for employees. It's good for the employer. That's by far the most important or the most common. But we also see things like family, and just more of a whole well-being kind of concept as well, so beyond wellness, so allowing for that broader reach.

+ +

We're also seeing industries where people are starting to age out. So, we've got five generations at work right now. There's industries where folks have historically stayed forever. You know, you've got the people who have been there 20-30 years. Well, those same industries are now sitting there going, all right, how do I get the next two generations to come in here? Because it's such an old-guard and old approach. We've got to change things up. And so, we're seeing a pretty big cultural shift happen within a lot of these more nascent industries.

+ +

WILL: Yeah. I can definitely see how that would be tough going from, you know, you said five generations are currently in the workforce?

+ +

AMY: Yep.

+ +

WILL: I didn't even think about that. Wow.

+ +

AMY: Yeah, you got a lot of different parts of the life cycle. You know, think about professional development. Professional development for a 22-year-old is very different from professional development for a 65-year-old. But both are in the workplace, and both want to keep learning. It's just what your needs are and what you need to learn. And how you want to learn is going to be very, very different.

+ +

WILL: Wow. So true. I love how you're talking about your leadership and just the way you lead. I can just hear it in what you're saying. What are some of your core values that drive you every day?

+ +

AMY: One of the big ones, and it probably goes back to, you know, I'm sure, birth placement, whatever. I'm an oldest child, all the things that come with being an oldest child. But fairness is a really big one for me. And so, it's thinking about how we apply that as a company, so equitable compensation falls under that. Making sure that we've got a team that is balanced and diverse is really important to me.

+ +

You know, thinking, you know, our core values are balance and belonging. That runs through absolutely everything that we do and is core and central to it. Because, again, how we build this company is just as important to me as what we're building. And so, making sure that we hold true to those values is critical because we have amazing people, and they need to feel supported as well.

+ +

VICTORIA: Well, that really comes through in everything that you say and that we've talked about so far today, and I really appreciate that. And I'm curious if you could go back in time to when you first started Compt and tell yourself any piece of advice or information; what would you say?

+ +

AMY: That piece of advice has changed over time; I will tell you that. The one that is most recent for me is really because we're an HR tech platform, and we service, you know, an entire organization, is really thinking about how you support different industries at different moments in time, the concept of product-market fit. When you're that type of a platform, which there aren't many, there's not many platforms that sit across an entire organization, but compensation is one of them. You need to be thinking about which industries are struggling to hire, which are struggling to retain at this moment in time.

+ +

And so, I don't think there's one place, like, hey, we have product-market fit, now we can scale. I think that's a misnomer for our part of the HR tech space. And so, it's constant experimentation on go-to-market strategy and constant kind of adjustment as markets ebb and flow over time.

+ +

WILL: What is some of your biggest hurdles right now or even in the future that you can see coming?

+ +

AMY: If I had a crystal ball, life would definitely be easier. I'd love to know when this economic cycle is going to shift and, you know when things get a little bit easier for companies. You know, HR leaders and finance leaders are not having the most fun at this moment in time. They're being tasked with making everybody happy but on very small budgets, and so they're really challenged with that. And they're really burnt out, and they're exhausted. So, I'm looking forward to a shift so when people can get back to feeling a little bit physically better. But also, it just helps navigate a market and be better able to support your employees.

+ +

VICTORIA: I've been thinking about that question recently, what I would tell my past self, and I think it's mostly, like, food related.

+ +

[laughter]

+ +

AMY: Ooh, interesting.

+ +

VICTORIA: Use better vinegars, like, invest in fancier olive oil. [laughs]

+ +

AMY: So, my new luxury pro-tip is you buy a $7 bunch of eucalyptus at the grocery store, and you tie it above your shower head. I'm not kidding; you will feel like you're at a spa. It costs $7. I learned it because I was at some fancy resort. One of my investors, you know, paid for us to go to a conference that I was not paying for. And I was like, that is genius. You suddenly feel like you are in someplace fancy, and it was seven bucks. It's amazing.

+ +

WILL: Yes.

+ +

VICTORIA: That sounds incredible. I'm going to do that.

+ +

WILL: Same.

+ +

[laughter]

+ +

VICTORIA: [inaudible 34:35] buy some. No, it's so good. Do you have any questions for us, Amy?

+ +

AMY: Yeah. I mean, what trends are you seeing in the market right now? Like, what types of companies are being developed? Where do you see growth happening in the market?

+ +

VICTORIA: That's probably a better question for me. As a managing director, I spend more time networking and going to events. And it's interesting being in San Diego. There's a big biotech startup here. So, I went to an EvoNexus Demo Day and saw the things that people were using. And there seemed to be a trend of using AI and machine learning to create better health outcomes, whether that's for predictors for which people will respond better to anti-cancer drugs, or, you know, how do we monitor the release of drugs for someone's system who's, you know, going through methadone in therapy. So, it's really interesting.

+ +

I think that you know, you mentioned that there's not the same amount of money in the tech market, but I think there is still a lot of work being done to solve real problems that people have. So yeah, I'm really curious to see those types of projects and which ones are going to be successful, and how much the AI trend will really fade out. Like, clearly, in some use cases, you can see how beneficial it could be. And other times, it seems like it's kind of just like slapped on there for --

+ +

AMY: Agreed.

+ +

VICTORIA: Marketing purposes, so...

+ +

AMY: That's really just a database query. It's not AI. [laughs]

+ +

VICTORIA: Right. [laughs] It's interesting because, you know, I just had lunch with a bunch of other CTOs in San Diego, and we were talking about AI, and some of the inherent risks of it, and the damage it can cause. And I always like to bring it back to, like, there are some people who are already harmed by these trends. And we have to work around that. Like, there is some, you know, greater supposed existential threat with AI that I think is rather unlikely. But if we think about that too much and not focus on the current harm that's being done, then that's, you know, more dangerous than the other one.

+ +

AMY: Yeah. No, absolutely. I mean, there's definitely, I mean, even just with facial recognition and how that's applied and what that's used for. I mean, any software that is built with people has bias. And so, whatever biases they're bringing into it is the bias that's going to exist in the software. And so, there's...we already are starting from, you know, going back to our earlier conversation, if companies are not diverse and not building for really diverse perspectives, they're inherently going to build bias software, whether or not, I mean, I don't think that's anybody's intention. But that's what's going to happen because you just didn't think about things you didn't know.

+ +

VICTORIA: Right. And, of course, I'm here in Southern California. There's the strikes for the actors and writers' strike happening a few hours north of us. And they were actually, you know, for some actors, signing away their rights to their likeness.

+ +

AMY: Wow.

+ +

VICTORIA: And then they could make an AI image and --

+ +

AMY: Wow. You could just create an entire movie with somebody's image and dub in a voice, and suddenly you don't need actors.

+ +

VICTORIA: Right. And it's, of course, more often non-White actors and models who are being replaced. And so, I think that's a very interesting trend that people may not have thought about yet.

+ +

AMY: Fascinating.

+ +

VICTORIA: So yeah, I mean, having people on your leadership team who are thinking about these [laughs] different types of issues, like, yeah, I think it's really important. And then also, from, like, a data privacy perspective, all the laws that are coming out and that have come out. And I think that some founders and CTOs are really struggling with how to comply and protect everyone's data that way.

+ +

AMY: No. It's something we think about a lot because we have the potential to have access to a lot of employee data. We take a very minimalist approach stated, not a big data play. That's not what we're here for. That's not what we're trying to do, this mountain of data on people, and then we'll figure out how to monetize it. We want to build something a little bit different. And so using only data that needs to be used so that we can truly support people with what our actual goal and aim is, rather than having that be a secondary cause.

+ +

VICTORIA: Yeah. And I wanted to ask you about that actually because you have SOC 2 and GDPR compliance. And it's a topic that I think a lot of founders know that security is important, but it can be a significant investment. So, I'm curious your trade-offs and your timing for when you went for those compliance frameworks.

+ +

AMY: We went early for it. I mean, so our platform, I mean, we're integrated with payroll platforms. We're touching employee data. So, we went for it early because we knew that it was going to be important, and it's a lot easier to do it before you make a mess than it is after the fact. I've done SOC 2 compliance in two prior companies. It's not fun. It is not my most fun thing that I've ever done.

+ +

Fortunately, there are geniuses out there who built platforms to make this very, very easy now. We use a platform called Vanta that is absolutely incredible, made it super easy to get SOC 2 compliant, go through our audits, do all the things, so that, at least, is a lot easier. But it was something that we needed the funding to invest in. It's not inexpensive.

+ +

But we knew that it was going to be critical because people need to feel that their data is secure and that you know what you're doing, and that you're not just kind of flying by the seat of your pants. There's a lot of tech companies that operate on, we'll figure out the tax, or we'll figure out the law. We'll figure out the compliance later. And that's been a stated part of their mission. That's just not the way I'm going to operate. And that doesn't work very well when you're dealing with HR, quite frankly, or finance because we have to comply with laws. So, getting ahead of that early was part of our strategy.

+ +

VICTORIA: That makes sense. Your finance background making it clear what the legal implications are. [laughs]

+ +

AMY: Exactly. Like, I'm not messing around with the IRS. Nobody wants to get audited by the IRS. It's not fun. Let's just keep things tax compliant. Chances are you're not going to get audited by the IRS. But if you are a tech company, if you do want to go public, if you do want to be acquired likely from a public company, you have to have these things in order because otherwise, it's coming off your purchase price or your stock price because you've got disclosures you've got to put out there, so little hidden, nasty gotchas.

+ +

And it can be a six-year lookback period. So, you're like, oh, I'll worry about it later. Six years is a long time. And if you start messing around with that, it gets very, very expensive to clean up. So, just do it right from the beginning. You know, the same way you're doing payroll correctly now, invest a little bit, and it makes it a lot easier.

+ +

VICTORIA: Yeah, I agree. And I think the tooling that's out there makes it a little bit easier; at least then, you know you have the confidence that your data is protected. Especially if you're a non-technical founder, I can imagine that makes you feel better that things are the way they should be.

+ +

AMY: Exactly. Somebody has looked at this thing. Somebody is making sure that it's working the way it's supposed to. You know, that definitely helps when you're a non-technical founder, or just not a tax expert, or a legal expert, you know, around these things. It's not even the technical founders that have to worry about it. Data comes in all kinds of forms.

+ +

VICTORIA: Yeah, that makes a lot of sense.

+ +

AMY: This has been a fantastic conversation. I've really enjoyed it.

+ +

VICTORIA: Well, thank you.

+ +

WILL: Same.

+ +

VICTORIA: I've enjoyed it as well. I really appreciate you taking the time.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Amy Spurling.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+vYtt3WUp + + ]]> + + Will Larry + Victoria Guido + Amy Spurling + + + 490: Datadog with Sean O'Connor + https://podcast.thoughtbot.com/490 + bc02c39b-583c-4187-b6b3-88f7415aa8aa + Thu, 31 Aug 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Sean O'Connor is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications. + +Sean discusses his transition from an individual contributor to management and shares why he chose Datadog, emphasizing the appeal of high-scale problems and the real business nature of the company. They delve into the importance of performance management and observability and cover the cultural and technical challenges Sean faces in managing a diverse, geographically spread team, and discuss the transition at Datadog from a decentralized model to more centralized platforms, the corresponding changes in both technical strategies and people management, and what excites him about Datadog's future, including the integration of security offerings into developers' daily experiences, and the evolution of Kubernetes and internal build and release tooling. + 45:55 + no + + + Sean O'Connor is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications. +Sean discusses his transition from an individual contributor to management and shares why he chose Datadog, emphasizing the appeal of high-scale problems and the real business nature of the company. They delve into the importance of performance management and observability and cover the cultural and technical challenges Sean faces in managing a diverse, geographically spread team, and discuss the transition at Datadog from a decentralized model to more centralized platforms, the corresponding changes in both technical strategies and people management, and what excites him about Datadog's future, including the integration of security offerings into developers' daily experiences, and the evolution of Kubernetes and internal build and release tooling. +__ +Datadog (https://www.datadoghq.com/) +Follow Datadog on LinkedIn (https://www.linkedin.com/company/datadog/), Instagram (https://www.instagram.com/datadoghq/), Youtube (https://www.youtube.com/user/DatadogHQ), or Twitter (https://twitter.com/datadoghq). +Follow Sean O'Connor on LinkedIn (https://www.linkedin.com/in/seanoc/) or Twitter (https://twitter.com/theSeanOC). Visit his website at seanoc.com (https://seanoc.com/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. And with us today is Sean O'Connor. He is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications. Sean, thank you for joining us. +SEAN: Hi, thanks for having me on. +VICTORIA: Yeah, I'm super excited to get to talking with you about everything cloud, and DevOps, and engineering. But why don't we first start with just a conversation about what's going on in your life? Is there any exciting personal moment coming up for you soon? +SEAN: Yeah, my wife and I are expecting our first kiddo in the next few weeks, so getting us prepared for that as we can and trying to get as much sleep as we can. [laughs] +WILL: Get as much sleep as you can now, so...[laughs] I have a question around that. When you first found out that you're going to be a dad, what was your feeling? Because I remember the feeling that I had; it was a mixed reaction of just everything. So, I just wanted to see what was your reaction whenever you found out that you're going to be a dad for the first time. +SEAN: Yeah, I was pretty excited. My wife and I had been kind of trying for this for a little while. We're both kind of at the older end for new parents in our late 30s. So, yeah, excited but definitely, I don't know, maybe a certain amount of, I don't know about fear but, you know, maybe just concerned with change and how different life will be, but mostly excitement and happiness. [laughs] +WILL: Yeah, I remember the excitement and happiness. But I also remember, like, wait, I don't know exactly what to do in this situation. And what about the situations that I have no idea about and things like that? So, I will tell you, kids are resilient. You're going to do great as a dad. +[laughter] +SEAN: Yep. Yeah, definitely; I think I feel much more comfortable about the idea of being a parent now than I may have been in my 20s. But yeah, definitely, the idea of being responsible for and raising a whole other human is intimidating. [laughs] +VICTORIA: I think the fact that you're worried about it is a good sign [laughs], right? +SEAN: I hope so. [laughs] +VICTORIA: Like, you understand that it's difficult. You're going to be a great parent just by the fact that you understand it's difficult and there's a lot of work ahead. So, I think I'm really excited for you. And I'm glad we get to talk to you at this point because probably when the episode comes out, you'll be able to listen to it with your new baby in hand. So... +WILL: Good. Excited for it. [laughs] +VICTORIA: Yeah, love that. Well, great. Well, why don't you tell me a little bit more about your other background, your professional background? What brought you to the role you're into today? +SEAN: Yeah. Well, like we mentioned in the beginning; currently, I'm a Director of Engineering at Datadog. I run our computing cloud team. It's responsible for all of our Kubernetes infrastructure, as well as kind of all the tooling for dealing with the cloud providers that we run on and as well as kind of [inaudible 02:54] crypto infrastructure. +Within Datadog, I've always been in management roles though I've kind of bounced around. I've been here for about five and a half years. So, before this, I was running a data store infrastructure team. Before that, when I first came in, I was running the APM product team, kind of bounced around between product and infra. And that's kind of, I guess, been a lot of the story of much of my career is wearing lots of different hats and kind of bouncing around between kind of infrastructure-focused roles and product-focused roles. +So, before this, I was running the back-end engineering and DevOps teams at Bitly. So, I was there for about five and a half years, started there originally as a software engineer. And before that, a lot of early-stage startups and consulting doing whatever needed doing, and getting to learn about lots of different kind of industries and domains, which is always fun. [laughs] +VICTORIA: That's great. So, you had that broad range of experience coming from all different areas of operations in my mind, which is, like, security and infrastructure, and now working your way into a management position. What was the challenge for you in making that switch from being such a strong individual contributor into an effective manager? +SEAN: Sure. You know, I think certainly there is a lot of kind of the classic challenges of learning to let go but still staying involved, right? You know, as a manager, if you're working on critical path tasks hands-on yourself, that's probably not a good sign. [laughs] On the other hand, if you come, like, completely divorced from what your team is doing, especially as, like, a team lead level kind of manager, you know, that's not great either. So, figuring that balancing act definitely was a bit tricky for me. +Similarly, I think time management and learning to accept that, especially as you get into, like, further steps along in your career that, like, you know, it's not even a question of keeping all the balls in the air, but more figuring out, like, what balls are made out of rubber and which ones are made out of glass, and maybe keeping those ones in the air. [laughs] So, just a lot of those kind of, like, you know, prioritization and figuring out, like, what the right level of involvement and context is, is definitely the eternal learning, I think, for me. [laughs] +WILL: I remember whenever I was looking to change jobs, kind of my mindset was I wanted to work at thoughtbot more because of the values. And I wanted to learn and challenge myself and things like that. And it was so much more, but those were some of the main items that I wanted to experience in my next job. So, when you changed, and you went from Bitly to Datadog, what was that thing that made you say, I want to join Datadog? +SEAN: Yeah, that was definitely an interesting job search and transition. So, at that point in time, I was living in New York. I was looking to stay in New York. So, I was kind of talking to a bunch of different companies. Both from personal experience and from talking to some friends, I wasn't super interested in looking at, like, working at mostly, like, the super big, you know, Google, Amazon, Meta type of companies. But also, having done, like, super early stage, you know, like, seed, series A type of companies, having played that game, I wasn't in a place in my life to do that either. [laughs] So, I was looking kind of in between that space. +So, this would have been in 2018. So, I was talking to a lot of, like, series A and series B-type companies. And most of them were, like, real businesses. [laughs] Like, they may not be profitable yet, but, like, they had a very clear idea of how they would get there and, like, what that would look like. And so, that was pleasant compared to some past points in my career. +But a lot of them, you know, I was effectively doing, like, automation of human processes, which is important. It has value. But it means that, like, realistically, this company will never have more than 50 servers. And when I worked at Bitly, I did have a taste for kind of working in those high-scale, high-availability type environments. +So, Datadog initially was appealing because it kind of checked all those boxes of, you know, very high-scale problems, high availability needs, a very real business. [laughs] This is before Datadog had gone public. And then, as I started to talk to them and got to know them, I also really liked a lot of kind of the culture and all the people I interacted with. So, it became a very clear choice very quickly as that process moved along. +VICTORIA: Yeah, a very real business. Datadog is one of the Gartner's Magic leaders for APM and observability in the industry. And I understand you're also one of the larger SaaS solutions running Kubernetes, right? +SEAN: Yep. Yeah, at this point. Five years ago, that story was maybe a little bit different. [laughs] But yeah, no, no, we definitely have a pretty substantial Kubernetes suite that we run everything on top of. And we get the blessings and curses of we get some really cool problems to work on, but there's also a lot of problems that we come across that when we talk to kind of peers in the industry about kind of how they're trying to solve them, they don't have answers yet either. [laughs] So, we get to kind of figure out a lot of that kind of early discovery games. [laughs] +VICTORIA: Yeah. I like how exciting and growing this industry is around kind of your compute and monitoring the performance of your applications. I wonder if you could kind of speak to our audience a little bit, who may not have a big technical background, about just why it's important to think about performance management and observability early on in your application. +SEAN: There can be a few pieces there. One of the bigger ones, I think, is thinking about that kind of early and getting used to working with that kind of tooling early in a project or a product. I think it has an analogous effect to, like, thinking about, like, compounding interest in, like, a savings account or investing or something like that. In that, by having those tools available early on and having that visibility available early on, you can really both initially get a lot of value and just kind of understanding kind of what's happening with your system and very quickly troubleshoot problems and make sure things are running efficiently. +But then that can help get to a place where you get to that, like, flywheel effect as you're kind of building your product of, as you're able to solve things quickly, that means you have more time to invest in other parts of the product, and so on and so forth. So, yeah, it's one of those things where kind of the earlier you can get started on that, the more that benefit gets amplified over time. +And thankfully, with Datadog and other offerings like that now, you can get started with that relatively quickly, right? You're not having to necessarily make the choice of, like, oh, can I justify spending a week, a month, whatever, setting up all my own infrastructure for this, as opposed to, you know, plugging in a credit card and getting going right away? And not necessarily starting with everything from day zero but getting started with something and then being able to build on that definitely can be a worthwhile trade-off. [laughs] +VICTORIA: That makes sense. And I'm curious your perspective, Will, as a developer on our Lift Off team, which is really about the services around that time when you want to start taking it really seriously. Like, you've built an app [laughs]. You know it's a viable product, and there's a market for it. And just, like, how you think about observability when you're doing your app building. +WILL: The approach I really take is, like, what is the end goal? I'm currently on a project right now that we came in later than normal. We're trying to work through that. +SEAN: I haven't come from, you know, that kind of consulting and professional services and support kind of place. I'm curious about, like, what, if any, differences or experiences do you have, like, in that context of, like, how do you use your observability tools or, like, what value they have as opposed to maybe more, like, straight product development? +VICTORIA: Right. So, we recently partnered with, you know, our platform engineering team worked with the Lift Off team to create a product from scratch. And we built in observability tools with Prometheus, and Grafana, and Sentry so that the developers could instrument their app and build metrics around the performance in the way they expected the application to work so that when it goes live and meets real users, they're confident their users are able to actually use the app with a general acceptable level of latency and other things that are really key to the functionality of the app. +And so, I think that the interesting part was, with the founders who don't have a background in IT operations or application monitoring and performance, it sort of makes sense. But it's still maybe a stretch to really see the full value of that, especially when you're just trying to get the app out the door. +SEAN: Nice. +VICTORIA: [chuckles] That's my answer. What kind of challenges do you have in your role managing this large team in a very competitive company, running a ton of Kubernetes clusters? [laughs] What's your challenges in your director of engineering role there? +SEAN: You know, it's definitely a mix of kind of, like, technical or strategic challenges there, as well as people challenges. On the technical and strategic side, the interesting thing for our team right now is we're in the middle of a very interesting transition. Still, today, the teams at Datadog work in very much a 'You build it, you run it' kind of model, right? So, teams working on user-facing features in addition to, like, you know, designing those features and writing the code for that, they're responsible for deploying that code, offering the services that code runs within, being on call for that, so on and so forth. +And until relatively recently, that ownership was very intense to the point where some teams maybe even had their own build and release processes. They were running their own data stores. And, like, that was very valuable for much of our history because that let those teams to be very agile and not have to worry about, like, convincing the entire company to change if they needed to make some kind of change. +But as we've grown and as, you know, we've kind of taken on a lot more complexity in our environment from, you know, running across more providers, running across more regions, taking on more of regulatory concerns, to kind of the viability of running everything entirely [inaudible 12:13] for those product teams, it has become much harder. [laughs] +You start to see a transition where previously the infrastructure teams were much more acting as subject matter experts and consultants to, now, we're increasingly offering more centralized platforms and offerings that can offload a lot of that kind of complexity and the stuff that isn't the core of what the other product-focused teams are trying to do. +And so, as we go through that change, it means internally, a lot of our teams, and how we think about our roles, and how we go about doing our work, changes from, like, a very, you know, traditional reliability type one on one consultation and advising type role to effectively internal product development and internal platform development. So, that's a pretty big both mindset and practice shift. [laughs] So, that's one that we're kind of evolving our way through. +And, of course, as what happens to kind of things, like, you still have to do all the old stuff while you're doing the new thing. [laughs] You don't get to just stop and just do the new thing. So, that's been an interesting kind of journey and one that we're always kind of figuring out as we go. That is a lot of kind of what I focus on. +You know, people wise, you know, we have an interesting aim of...There's about 40 people in my org. They are spread across EMEA and North America with kind of, let's say, hubs in New York and Paris. So, with that, you know, you have a pretty significant time zone difference and some non-trivial cultural differences. [laughs] And so, you know, making sure that everybody is still able to kind of work efficiently, and communicate effectively, and collaborate effectively, while still working within all those constraints is always an ongoing challenge. [laughs] +WILL: Yeah, you mentioned the different cultures, the different types of employees you have, and everyone is not the same. And there's so many cultures, so many...whatever people are going through, you as a leader, how do you navigate through that? Like, how do you constantly challenge yourself to be a better leader, knowing that not everyone can be managed the same way, that there's just so much diversity, probably even in your company among your employees? +SEAN: I think a lot of it starts from a place of listening and paying attention to kind of just see where people are happy, where they feel like they have unmet needs. As an example, I moved from that last kind of data store-focused team to this computing cloud team last November. +And so, as part of that move, probably for the first two or three months that I was in the role, I wasn't particularly driving much in the way of changes or setting much of a vision beyond what the team already had, just because as the new person coming in, it's usually kind of hard to have a lot of credibility and/or even just have the idea of, like, you know, like you're saying, like, what different people are looking for, or what they need, how they will respond best. +I just spend a lot of time just talking to people, getting to know the team, building those relationships, getting to know those people, getting to know those groups. And then, from there, figuring out, you know, both where the kind of the high priority areas where change or investment is needed. But then also figuring out, yeah, kind of based on all that, what's the right way to go about that with the different groups? Because yeah, it's definitely isn't a one size fits all solution. +But for me, it's always kind of starting from a place of listening and understanding and using that to develop, I guess, empathy for the people involved and understanding their perspectives and then figuring it out from there. I imagine–I don't know, but I imagine thoughtbot's a pretty distributed company. How do you all kind of think about some of those challenges of just navigating people coming from very different contexts? +WILL: Yeah, I was going to ask Victoria that because Victoria is one of the leaders of our team here at thoughtbot. So, Victoria, what are your thoughts on it? +VICTORIA: I have also one of the most distributed teams at thoughtbot because we do offer 24/7 support to some clients. And we cover time zones from the Pacific through West Africa. So, we just try to create a lot of opportunities for people to engage, whether it's remotely, especially offering a lot of virtual engagement and social engagement remotely. But then also, offering some in-person, whether it's a company in-person event, or encouraging people to engage with their local community and trying to find conferences, meetups, events that are relevant to us as a business, and a great opportunity for them to go and get some in-person interaction. So, I think then encouraging them to bring those ideas back. +And, of course, thoughtbot is known for having just incredible remote async communication happening all the time. It's actually almost a little oppressive to keep up with, to be honest, [laughs] but I love it. There's just a lot of...there's GitHub issues. There's Slack communications. There's, like, open messages. And people are really encouraged to contribute to the conversation and bring up any idea and any problem they're having, and actively add to and modify our company policies and procedures so that we can do the best work with each other and know how to work with each other, and to put out the best products. +I think that's key to having that conversation, especially for a company that's as big as Datadog and has so many clients, and has become such a leader in this metrics area. Being able to listen within your company and to your clients is probably going to set you up for success for any, like, tech leadership role [laughs]. +I'm curious, what are you most excited about now that you've been in the role for a little while? You've heard from a lot of people within the company. Can you share anything in your direction in the next six months or a year that you're super excited about? +SEAN: So, there's usually kind of probably two sides to that question of kind of, like, from a product and business standpoint and from an internal infrastructure standpoint, given that's where my day-to-day focus is. You know, on the product side, one thing that's been definitely interesting to watch in my time at Datadog is we really made the transition from kind of, like, a point solution type product to much more of a platform. +For context, when I joined Datadog, I think logs had just gone GA, and APM was in beta, I think. So, we were just starting to figure out, like, how we expand beyond the initial infrastructure metrics product. And, obviously, at this point, now we have a whole, you know, suite of offerings. And so, kind of the opportunities that come with that, as far as both different spaces that we can jump into, and kind of the value that we can provide by having all those different capabilities play together really nicely, is exciting and is cool. +Like, you know, one of the things that definitely lit an interesting light bulb for me was talking to some of the folks working on our newer security offerings and them talking about how, obviously, you want to meet, you know, your normal requirements in that space, so being able to provide the visibility that, you know, security teams are looking for there. +But also, figuring out how we integrate that information into your developers' everyday experience so that they can have more ownership over that aspect of the systems that they're building and make everybody's job easier and more efficient, right? Instead of having, you know, the nightmare spreadsheet whenever a CVE comes out and having some poor TPM chase half the company to get their libraries updated, you know, being able to make that visible in the product where people are doing their work every day, you know, things like that are always kind of exciting opportunities. +On the internal side, we're starting to think about, like, what the next major evolution of our kind of Kubernetes and kind of internal build and release tooling looks like. Today, a lot of kind of how teams interact with our Kubernetes infrastructure is still pretty raw. Like, they're working directly with specific Kubernetes clusters, and they are exposed to all the individual Kubernetes primitives, which is very powerful, but it's also a pretty steep learning curve. [laughs] +And for a lot of teams, it ends up meaning that there's lots of, you know, knobs that they have to know what they do. But at the end of the day, like, they're not getting a lot of benefit from that, right? There's more just opportunity for them to accidentally put themselves in a bad place. So, we're starting to figure out, like, higher level abstractions and offerings to simplify how all that for teams look like. +So, we're still a bit early days in working through that, but it's exciting to figure out, like, how we can still give teams kind of the flexibility and the power that they need but make those experiences much easier and not have to have them become Kubernetes experts just to deploy a simple process. And, yes, so there's some lots of fun challenges in there. [laughs] +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +WILL: I have a question around your experience. So, you've been a developer around 20 years. What has been your experience over that 20 years or about of the growth in this market? Because I can only imagine what the market was, you know, in the early 2000s versus right now because I still remember...I still have nightmares of dial-up, dial tone tu-tu-tu. No one could call you, stuff like that. So, what has been your experience, just seeing the market grow from where you started? +SEAN: Sure, yeah. I think probably a lot of the biggest pieces of it are just seeing the extent to which...I want to say it was Cory Doctorow, but I'm not sure who actually originally coined the idea, but the idea that, you know, software is eating the world, right? Like, eventually, to some degree, every company becomes a software company because software ends up becoming involved in pretty much everything that we as a society do. +So, definitely seeing the progression of that, I think, over that time period has been striking, you know, especially when I was working in more consulting contexts and working more in companies and industries where like, you know, the tech isn't really the focus but just how much that, you know, from an engineering standpoint, relatively basic software can fundamentally transform those businesses and those industries has definitely been striking. +And then, you know, I think from a more individual perspective, seeing as, you know, our tools become more sophisticated and easier to access, just seeing how much of a mixed bag that has become [laughs]. And just kind of the flavor of, like, you know, as more people have more powerful tools, that can be very enabling and gives voice to many people. But it also means that the ability of an individual or a small group to abuse those tools in ways that we're maybe not fully ready to deal with as a society has been interesting to see how that's played out. +VICTORIA: Yeah. I think you bring up some really great points there. And it reminds me of one of my favorite quotes is that, like, the future is here—it's just not evenly distributed. [laughs] And so, in some communities that I go to, everyone knows what Kubernetes is; everyone knows what DevOps is. It's kind of, like, old news. [laughs] And then, some people are still just like, "What?" [laughs]. +It's interesting to think about that and think about the implications on your last point about just how dangerous the supply chain is in building software and how some of these abstractions and some of these things that just make it so easy to build applications can also introduce a good amount of risk into your product and into your business, right? So, I wonder if you can tell me a little bit more about your perspective on security and DevSecOps and what founders might be thinking about to protect their IP and their client's data in their product. +SEAN: That one is interesting and tricky in that, like, we're in a little bit of, like, things are better and worse than they ever have been before [laughs], right? Like, there is a certain level of, I think, baseline knowledge and competency that I think company leaders really just have to have now, part of, like, kind of table stakes, which can definitely be challenging, and that, like, that probably was much less, if even the case, you know, 10-20 years ago in a lot of businesses. +As an example, right? Like, obviously, like if it's a tech-focused company, like, that can be a thing. But, like, if you're running a plumbing business with a dozen trucks, let's say, like, 20 years ago, you probably didn't have to think that much about data privacy and data security. But, like, now you're almost certainly using some kind of electronic system to kind of manage all your customer records, and your job scheduling, and all that kind of stuff. So, like, now, that is something that's a primary concern for your business. +On the flip side of that, I think there is much better resources, and tools, and practices available out there. I forget the name of the tool now. But I remember recently, I was working with a company on the ISO long string of numbers certifications that you tend to want to do when you're handling certain types of data. There was a tool they were able to work with that basically made it super easy for them to, like, gather all the evidence for that and whatnot, in a way where, like, you know, in the past, you probably just had to hire a compliance person to know what you had to do and how to present that. +But now, you could just sign up for a SaaS product. And, like, obviously, it can't just do it for you. Like, it's about making your policies. But it still gave you enough support where if you're, like, bootstrapping a company, like, yeah, you probably don't need to hire a specialist to [inaudible 25:08], which is a huge deal. +You know, similarly, a lot of things come much safer by default. When you think about, like, the security on something like an iPhone, or an iPad, or an Android device, like, just out of the box, that's light-years ahead of whatever Windows PC you were going to buy ten years ago. [laughs] And so, that kind of gives you a much better starting place. But some interesting challenges that come with that, right? And that we do now, literally, every person on the planet is walking around with microphones and cameras and all kinds of sensors on them. It's an interesting balance, I think. +Similarly, I'm curious how you all think about kind of talking with your clients and your customers about this because I'm sure you all have a non-trivial amount of education to do there. [laughs] +VICTORIA: Yeah, definitely. And I think a lot of it comes in when we have clients who are very early founders, and they don't have a CTO or a technical side of their business, and advising them on exactly what you laid out. Like, here's the baseline. Like, here's where you want to start from. We generally use the CIS controls, this internet for internet security. It puts out a really great tool set, too, for some things you were mentioning earlier. Let's figure out how to report and how to identify all of the things that we're supposed to be doing. It could be overwhelming. It's a lot. +Like, in my past role as VP of Operations at Pluribus Digital, I was responsible for helping our team continue to meet our...we had three different ISO long number certifications [laughs]. We did a CMMI as well, which has come up a few times in my career. And they give you about a couple of hundreds of controls that you're supposed to meet. It's in very kind of, like, legalese that you have to understand. And that's a pretty big gap to solve for someone who doesn't have the technical experience to start. +Like, what you were saying, too, that it's more dangerous and more safer than it has been before. So, if we make choices for those types of clients in very safe, trusted platforms, then they're going to be set up for success and not have to worry about those details as much. And we kind of go forward with confidence that if they are going to have to come up against compliance requirements or local state regulations, which are also...there's more of those every day, and a lot of liability you can face as a founder, especially if you're dealing with, like, health or financial data, in the state of California, for example. [laughs] +It puts you at a really big amount of liability that I don't think we've really seen the impact of how bad it can be and will be coming out in the next couple of years now that that law has passed. But that's kind of the approach that we like to think. It's like, you know, there's a minimum we can do that will mitigate a lot of this risk [laughs], so let's do that. Let's do the basics and start off on the right foot here. +SEAN: Yeah, no, that makes sense. Yeah, it's definitely something I've come to appreciate, especially doing work in regulated spaces is, when you do reach the point where you do need to have some kind of subject matter expert involved, whether it's somebody in-house or a consultant or an advisor, I've definitely learned that usually, like, the better ones are going to talk to you in terms of, like, what are the risk trade-offs you're making here? And what are the principles that all these detailed controls or guidelines are looking to get at? +As opposed to just, like, walking you through the box-checking exercise. In my experience, a really good lawyer or somebody who will talk to you about risk versus just saying whether or not you can do something. [laughs] It has a very similar feeling in my experience. +VICTORIA: Yeah, it's a lot about risk. And someone's got to be able to make those trade-off decisions, and it can be really tough, but it's doable. And I think it shouldn't scare people away. And there's lots of people, lots of ways to do it also, which is exciting. So, I think it's a good space to be in and to see it growing and pay attention to. [laughs] +It's fun for me to be in a different place where we're given the opportunity to kind of educate or bring people along in a security journey versus having it be a top-down executive-level decision that we need to meet this particular security standard, and that's the way it's going to be. [laughs] Yeah, so that I appreciate. +Is there anything that really surprised you in your conversations with Datadog or with other companies around these types of services for, like, platform engineering and observability? Is there anything that surprised you in the discovery process with potential clients for your products? +SEAN: I think one of the biggest surprises, or maybe not a surprise but an interesting thing is, to what extent, you know, for us, I don't know if this is still the case, but I think in many places, like, we're probably more often competing against nothing than a competing product. And by that, I mean, especially as you look at some of our more sophisticated products like APM, or profiling, it's not so much that somebody has an existing tool that we're looking to replace; it's much more than this is just not a thing they do today. [laughs] +And so, that leads to a very interestingly different conversation that I think, you know, relates to some of what we were saying with security where, you know, I think a non-trivial part of what our sales and technical enablement folks do is effectively education for our customers and potential customers of why they might want to use tools like this, and what kind of value they could get from them. +The other one that's been interesting is to see how different customers' attitudes around tools like this have evolved as they've gone through their own migration to the cloud journeys, right? We definitely have a lot of customers that, I think, you know, 5, 10 years ago, when they were running entirely on-prem, using a SaaS product would have been a complete non-starter. +But as they move into the cloud, both as they kind of generally get more comfortable with the idea of delegating some of these responsibilities, as well as they start to understand kind of, like, the complexity of the tooling required as their environment gets more complex, the value of a dedicated product like something like Datadog as opposed to, you know, what you kind of get out of the box with the cloud providers or what you might kind of build on your own has definitely been interesting. [laughs] +VICTORIA: Is there a common point that you find companies get to where they're like, all right, now, I really need something? Can you say a little bit more about, like, what might be going on in the organization at that time? +SEAN: You know, I think there could be a few different paths that companies take to it. Some of it, I think, can come from a place of...I think, especially for kind of larger enterprise customers making a transition like that, they tend to be taking a more holistic look at kind of their distinct practices and seeing what they want to change as they move into the cloud. And often, kind of finding an observability vendor is just kind of, like, part of the checklist there. [laughs] Not to dismiss it, but just, like, that seems to be certainly one path into it. +I think for smaller customers, or maybe customers that are more, say, cloud-native, I think it can generally be a mix of either hitting a point where they're kind of done with the overhead of trying to maintain their own infrastructure of, like, trying to run their own ELK stack and, like, build all the tooling on top of that, and keeping that up and running, and the costs associated with that. Or, it's potentially seeing the sophistication of tooling that, like, a dedicated provider can afford to invest that realistically, you're never going to invest in on your own, right? Like, stuff like live profiling is deeply non-trivial to implement. [laughs] +I think especially once people get some experience with a product like Datadog, they start thinking about, like, okay, how much value are we actually getting out of doing this on our own versus using a more off-the-shelf product? I don't know if we've been doing it post-COVID. But I remember pre-COVID...so Datadog has a huge presence at re:Invent and the other similar major cloud provider things. +And I remember for a few years at re:Invent, you know, we obviously had, like, the giant 60x60 booth in the main expo floor, where we were giving demos and whatnot. But they also would have...AWS would do this, like, I think they call it the interactive hall where companies could have, like, more hands-on booths, and you had, like, a whole spectrum of stuff. And there were, like, some companies just had, like, random, like, RC car setups or Lego tables, just stuff like that. +But we actually did a setup where there was a booth of, I think, like, six stations. People would step up, and they would race each other to solve a kind of faux incident using Datadog. The person who would solve it first would win a switch. I think we gave away a huge number of switches as part of that, which at first I was like, wow, that seems expensive. [laughs] +But then later, you know, I was mostly working the main booth at that re:Invent. So by the, like, Wednesday and Thursday of re:Invent, I'd have people walking up to the main booth being like, "Hey, so I did the thing over at the Aria. And now I installed Datadog in prod last night, and I have questions." I was like, oh, okay. [laughs] So, I think just, like, the power of, like, getting that hands-on time, and using some of the tools, and understanding the difference there is what kind of gets a lot of people to kind of change their mind there. [laughs] +VICTORIA: You'd get me with a switch right now. I kind of want one, but I don't want to buy one. +SEAN: [laughs] +WILL: Same. [laughs] +VICTORIA: Because I know it'll take up all my time. +SEAN: Uh-huh. That's fair. [laughs] +VICTORIA: But I will try to win one at a conference for sure. I think that's true. And it makes sense that because your product is often going with clients that don't have these practices yet, that as soon as you give them exposure to it, you see what you can do with it, that becomes a very powerful selling tool. Like, this is the value of the product, right? [laughs] +SEAN: Yeah, there is also something we see, and I think most of our kind of peers in the industry see is, very often, people come in initially looking for and using a single product, like, you know, infrastructure, metrics, or logs. And then, as they see that and see where that touches other parts of the product, their usage kind of grows and expands over time. I would obviously defer to our earnings calls for exact numbers. But generally speaking, more or less kind of half of our new business is usually expanded usage from existing customers as opposed to new customers coming in. So, I think there's also a lot of just kind of organic discovery and building of trust over time that happens there, which is interesting. +VICTORIA: One of my favorite points to make, which is that SRE sounds very technical and, like, this really extreme thing. But to make it sound a little more easier, is that it is how you validate that the user experience is what you expect it to be. [laughs] I wonder if you have any other thoughts you want to add to that, just about, like, SRE and user experience and how that all connects for real business value. +SEAN: I think a lot of places where, you know, we've both seen internally ourselves and with customers is, you know; obviously, different companies operate in different models and whatnot. Where people have seen success is where, you know, people with formal SRE titles or team names can kind of be coming in as just kind of another perspective on the various kind of things that teams are trying to drive towards. +The places reliability is successfully integrated is when they can kind of make that connection that you were talking about. It's, like, obviously, everybody should go take their vitamins, but, like, what actual value is coming from this, right? Nobody wants to have outages, but, like, to do the work to invest in reliability, often, like, it can be hard to say, like, okay, what's the actual difference between before and after? Having people who can help draw those connections and help weigh those trade-offs, I think, can definitely be super helpful. +But it is generally much more effective, I think, in my experience, when it does come from that perspective of, like, what value are we providing? What are we trading off as part of this? As opposed to just, well, you should do this because it's the right thing to do, kind of a moralistic perspective. [laughs] But, I don't know, how do you all kind of end up having that conversation with your customers and clients? +VICTORIA: That's exactly it. That's the same. It's starting that conversation about, like, well, what happens when this experience fails, which designers don't necessarily think about? What's, like, the most important paths that you want a user to take through your application that we want to make sure works? +And when you tie it all back there, I think then when the developers are understanding how to create those metrics and how to understand user behavior, that's when it becomes really powerful so that they're getting the feedback they need to do the right code, and to make the right changes. Versus just going purely on interviews [laughs] and not necessarily, like, understanding behavior within the app. I think that starts to make it clear. +SEAN: Part of that, I think that's been an interesting experience for us is also just some of the conversation there around, like, almost the flip side of, when are you investing potentially too much in that, right? Because, like, especially after a certain point, the cost of additional gains grows exponentially, right? Each one of those nines gets more and more expensive. [laughs] +And so, having the conversation of, like, do you actually need that level of reliability, or, like, is that...just like what you're saying. Like, you know, kind of giving some of that context and that pressure of, like, yeah, we can do that, but, like, this is what it's going to cost. Is that what you want to be spending your money on? Kind of things can also be an interesting part of that conversation. +VICTORIA: That's a really good point that, you know, you can set goals that are too high [laughs] and not necessary. So, it does take a lot of just understanding about your data and your users to know what are acceptable levels of error. +I think the other thing that you can think about, too, like, what could happen, and we've seen it happen with some startups, is that, like, something within the app is deeply broken, but you don't know. And you just think that you're not having user engagement, or that users are signing off, or, like, you know, not opening the app after the first day. +So, if you don't have any way to really actively monitor it and you're not spending money on an active development team, you can have some method to just be confident that the app is working and to make your life less miserable [laughs] when you have a smaller team supporting, especially if you're trying to really minimize your overhead for running an application. +SEAN: Yep. It's surprisingly hard to know when things are broken sometimes. [laughs] +VICTORIA: Yes, and then extremely painful when you find out later [laughs] because that's when it's become a real problem, yeah. I wonder, are there any other questions you have for me or for Will? +SEAN: How big of an organization is thoughtbot at this time? +VICTORIA: Close to 75 people? We're, yeah, between the Americas and the [inaudible 38:31] region. So, that's where we're at right now, yeah. +SEAN: Nice. At that size, like, and I guess it sounds like you're pretty heavily distributed, so maybe some of this doesn't happen as much, but, like, one of the things I definitely remember...so, when I joined Datadog, it was probably about 500 people. And I think we're just under 5,000 now. There are definitely some points where there were surprisingly, like, physical aspects to where it became a problem of just, like, where certain teams didn't fit into a room anymore. [laughs] Like, I had surprise in the changes in that, like, dynamic. I'm curious if you've all kind of run into any kind of, I don't know, similar interesting thresholds or changes as you've kind of grown and evolved. +WILL: I will say this, we're about 100, I think, Victoria. +VICTORIA: Oh, okay, we're 100 people. I think, you know, I've only been at thoughtbot for just over a year now. And my understanding of the history is that when we were growing before COVID, there's always been a very intentionality about growth. And there was never a goal to get to a huge size or to really grow beyond just, like, a steady, profitable growth. [laughs] +So, when we were growing in person, there were new offices being stood up. So, we, you know, maybe started out of New York and Boston and grew to London. And then, there was Texas, and I think a few other ones that started. Then with COVID, the decision was made to go fully remote, and I think that's opened up a lot of opportunities for us. And from my understanding in the previous and the past, is that there's a big shift to be fully remote. +It's been challenging, where I think a lot of people miss some of the in-person days, and I'm sure it's definitely lonely working remote all day by yourself. So, you have to really proactively find opportunities to see other people and to engage remotely. But I think also, we hire people from so many different places and so much different talent, and then, also, you know, better informs our products and creates a different, you know, energy within the company that I think is really fun and really exciting for us now. +WILL: Yeah, I would agree with that because I think the team that I'm on has about 26 people on the Lift Off team. And we're constantly thinking of new ways to get everyone involved. But as a developer, me myself being remote, I love talking to people. So, I try to be proactive and, like, connect with the people I'm working with and say, "Hey, how can I help you with this?" Let's jump in this room and just work together, chat together, and stuff like that, so... +And it has opened the door because the current project that I'm on, I would never have had an opportunity to be on. I think it's based in Utah, and I'm in South Florida. So, there's just no way if we weren't remote that I'd been a part of it. So... +SEAN: Nice. And I can definitely appreciate that. I remember when we first started COVID lockdown; I think, at that point, Datadog was probably about...Datadog engineering was probably about 30% remote, so certainly a significant remote contingent but mixed. But my teams were pretty remote-heavy. So, in some ways, not a lot changed, right? Like, I think more people on my team were, like, who are all these other people in my house now instead of [laughs], I mean, just transition from being in an office to working from home. +But I do remember maybe, like, about six months in, starting to feel, yeah, some of the loneliness and the separation of just, like, not being able to do, like, quarterly team meetups or stuff like that. So, it's definitely been an interesting transition. For context, at this point, we kind of have a hybrid setup. So, we still have a significant kind of full-time remote contingent, and then four people who are in office locations, people joining for about three days a week in office. So, it's definitely an interesting transition and an interesting new world. [laughs] +VICTORIA: Yeah. And I'm curious how you find the tech scene in Denver versus New York or if you're engaging in the community in the same way since you moved. +SEAN: There definitely is some weirdness since COVID started [laughs] broadly [inaudible 42:21]. So, I moved here in 2020. But I'd been coming out here a lot before that. I helped to build an office here with Bitly. So, I was probably coming out once a quarter for a bunch of years. So, one parallel that is finally similar is, like, in both places, it is a small world. It doesn't take that long for you to be in that community, in either of those communities and start running into the same people in different places. So, that's always been [inaudible 42:42] and especially in New York. New York is a city of what? 8, 9 million people? +But once you're working in New York tech for a few years and you go into some meetups, you start running into the same people, and you have one or two degrees [inaudible 42:52] to a lot of people, surprisingly quickly. [laughs] So, that's similar. But Denver probably is interesting in that it's definitely transplant-heavy. I think Denver tends to check the box for, like, it was part of why Bitly opened an office here and, to a degree, Datadog as well. +I think of like, you know, if you're trying to recruit people and you previously were mostly recruiting in, like, New York or Silicon Valley; if you're based in New York, and you're trying to recruit somebody from Silicon Valley, and part of why they're looking for a new gig is they're burned out on Silicon Valley, asking them to move to New York probably isn't all that attractive. [laughs] But Denver is different enough in that in terms of kind of being a smaller city, easier access to nature, a bunch of that kind of stuff, that a lot of times we were able to attract talent that was a much more appealing prospect. [laughs] +You'll see an interesting mix of industries here. One of the bigger things here is there's a very large government and DOD presence here. I remember I went to DevOps Days Rockies, I think, a few years ago. There was a Birds of a Feather session on trying to apply DevOps principles in air-gapped networks. That was a very interesting conversation. [laughs] +VICTORIA: That's interesting. I would not have thought Colorado would be a big hub for federal technology. But there you go, it's everywhere. +WILL: Yeah. +SEAN: Denver metro, I think, is actually the largest presence of federal offices outside of the D.C. metro. +VICTORIA: That's interesting. Yeah, I'm used to trying to recruit people into D.C., and so, it's definitely not the good weather, [laughs], not a good argument in my favor. So, I just wanted to give you a final chance. Anything else you'd like to promote, Sean? +SEAN: Generally, not super active on social things these days, but you can find whatever I have done at seanoc.com, S-E–A-N-O-C.com for the spelling. And otherwise, if you're interested in some engineering content and hearing about some of those kind of bleeding edge challenges that I was mentioning before, I would definitely check out the Datadog engineering blog. There's lots of kind of really interesting content there on both, you know, things we've learned from incidents and interesting projects that we're working on. There's all kinds of fun stuff there. +VICTORIA: That makes me think I should have asked you more questions, Sean. [laughs] No, I think it was great. Thank you so much for joining us today. I'll definitely check all that stuff out. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg. +WILL: And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Sean O'Connor. + + + Sean O'Connor is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications.

+ +

Sean discusses his transition from an individual contributor to management and shares why he chose Datadog, emphasizing the appeal of high-scale problems and the real business nature of the company. They delve into the importance of performance management and observability and cover the cultural and technical challenges Sean faces in managing a diverse, geographically spread team, and discuss the transition at Datadog from a decentralized model to more centralized platforms, the corresponding changes in both technical strategies and people management, and what excites him about Datadog's future, including the integration of security offerings into developers' daily experiences, and the evolution of Kubernetes and internal build and release tooling.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Sean O'Connor. He is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications. Sean, thank you for joining us.

+ +

SEAN: Hi, thanks for having me on.

+ +

VICTORIA: Yeah, I'm super excited to get to talking with you about everything cloud, and DevOps, and engineering. But why don't we first start with just a conversation about what's going on in your life? Is there any exciting personal moment coming up for you soon?

+ +

SEAN: Yeah, my wife and I are expecting our first kiddo in the next few weeks, so getting us prepared for that as we can and trying to get as much sleep as we can. [laughs]

+ +

WILL: Get as much sleep as you can now, so...[laughs] I have a question around that. When you first found out that you're going to be a dad, what was your feeling? Because I remember the feeling that I had; it was a mixed reaction of just everything. So, I just wanted to see what was your reaction whenever you found out that you're going to be a dad for the first time.

+ +

SEAN: Yeah, I was pretty excited. My wife and I had been kind of trying for this for a little while. We're both kind of at the older end for new parents in our late 30s. So, yeah, excited but definitely, I don't know, maybe a certain amount of, I don't know about fear but, you know, maybe just concerned with change and how different life will be, but mostly excitement and happiness. [laughs]

+ +

WILL: Yeah, I remember the excitement and happiness. But I also remember, like, wait, I don't know exactly what to do in this situation. And what about the situations that I have no idea about and things like that? So, I will tell you, kids are resilient. You're going to do great as a dad.

+ +

[laughter]

+ +

SEAN: Yep. Yeah, definitely; I think I feel much more comfortable about the idea of being a parent now than I may have been in my 20s. But yeah, definitely, the idea of being responsible for and raising a whole other human is intimidating. [laughs]

+ +

VICTORIA: I think the fact that you're worried about it is a good sign [laughs], right?

+ +

SEAN: I hope so. [laughs]

+ +

VICTORIA: Like, you understand that it's difficult. You're going to be a great parent just by the fact that you understand it's difficult and there's a lot of work ahead. So, I think I'm really excited for you. And I'm glad we get to talk to you at this point because probably when the episode comes out, you'll be able to listen to it with your new baby in hand. So...

+ +

WILL: Good. Excited for it. [laughs]

+ +

VICTORIA: Yeah, love that. Well, great. Well, why don't you tell me a little bit more about your other background, your professional background? What brought you to the role you're into today?

+ +

SEAN: Yeah. Well, like we mentioned in the beginning; currently, I'm a Director of Engineering at Datadog. I run our computing cloud team. It's responsible for all of our Kubernetes infrastructure, as well as kind of all the tooling for dealing with the cloud providers that we run on and as well as kind of [inaudible 02:54] crypto infrastructure.

+ +

Within Datadog, I've always been in management roles though I've kind of bounced around. I've been here for about five and a half years. So, before this, I was running a data store infrastructure team. Before that, when I first came in, I was running the APM product team, kind of bounced around between product and infra. And that's kind of, I guess, been a lot of the story of much of my career is wearing lots of different hats and kind of bouncing around between kind of infrastructure-focused roles and product-focused roles.

+ +

So, before this, I was running the back-end engineering and DevOps teams at Bitly. So, I was there for about five and a half years, started there originally as a software engineer. And before that, a lot of early-stage startups and consulting doing whatever needed doing, and getting to learn about lots of different kind of industries and domains, which is always fun. [laughs]

+ +

VICTORIA: That's great. So, you had that broad range of experience coming from all different areas of operations in my mind, which is, like, security and infrastructure, and now working your way into a management position. What was the challenge for you in making that switch from being such a strong individual contributor into an effective manager?

+ +

SEAN: Sure. You know, I think certainly there is a lot of kind of the classic challenges of learning to let go but still staying involved, right? You know, as a manager, if you're working on critical path tasks hands-on yourself, that's probably not a good sign. [laughs] On the other hand, if you come, like, completely divorced from what your team is doing, especially as, like, a team lead level kind of manager, you know, that's not great either. So, figuring that balancing act definitely was a bit tricky for me.

+ +

Similarly, I think time management and learning to accept that, especially as you get into, like, further steps along in your career that, like, you know, it's not even a question of keeping all the balls in the air, but more figuring out, like, what balls are made out of rubber and which ones are made out of glass, and maybe keeping those ones in the air. [laughs] So, just a lot of those kind of, like, you know, prioritization and figuring out, like, what the right level of involvement and context is, is definitely the eternal learning, I think, for me. [laughs]

+ +

WILL: I remember whenever I was looking to change jobs, kind of my mindset was I wanted to work at thoughtbot more because of the values. And I wanted to learn and challenge myself and things like that. And it was so much more, but those were some of the main items that I wanted to experience in my next job. So, when you changed, and you went from Bitly to Datadog, what was that thing that made you say, I want to join Datadog?

+ +

SEAN: Yeah, that was definitely an interesting job search and transition. So, at that point in time, I was living in New York. I was looking to stay in New York. So, I was kind of talking to a bunch of different companies. Both from personal experience and from talking to some friends, I wasn't super interested in looking at, like, working at mostly, like, the super big, you know, Google, Amazon, Meta type of companies. But also, having done, like, super early stage, you know, like, seed, series A type of companies, having played that game, I wasn't in a place in my life to do that either. [laughs] So, I was looking kind of in between that space.

+ +

So, this would have been in 2018. So, I was talking to a lot of, like, series A and series B-type companies. And most of them were, like, real businesses. [laughs] Like, they may not be profitable yet, but, like, they had a very clear idea of how they would get there and, like, what that would look like. And so, that was pleasant compared to some past points in my career.

+ +

But a lot of them, you know, I was effectively doing, like, automation of human processes, which is important. It has value. But it means that, like, realistically, this company will never have more than 50 servers. And when I worked at Bitly, I did have a taste for kind of working in those high-scale, high-availability type environments.

+ +

So, Datadog initially was appealing because it kind of checked all those boxes of, you know, very high-scale problems, high availability needs, a very real business. [laughs] This is before Datadog had gone public. And then, as I started to talk to them and got to know them, I also really liked a lot of kind of the culture and all the people I interacted with. So, it became a very clear choice very quickly as that process moved along.

+ +

VICTORIA: Yeah, a very real business. Datadog is one of the Gartner's Magic leaders for APM and observability in the industry. And I understand you're also one of the larger SaaS solutions running Kubernetes, right?

+ +

SEAN: Yep. Yeah, at this point. Five years ago, that story was maybe a little bit different. [laughs] But yeah, no, no, we definitely have a pretty substantial Kubernetes suite that we run everything on top of. And we get the blessings and curses of we get some really cool problems to work on, but there's also a lot of problems that we come across that when we talk to kind of peers in the industry about kind of how they're trying to solve them, they don't have answers yet either. [laughs] So, we get to kind of figure out a lot of that kind of early discovery games. [laughs]

+ +

VICTORIA: Yeah. I like how exciting and growing this industry is around kind of your compute and monitoring the performance of your applications. I wonder if you could kind of speak to our audience a little bit, who may not have a big technical background, about just why it's important to think about performance management and observability early on in your application.

+ +

SEAN: There can be a few pieces there. One of the bigger ones, I think, is thinking about that kind of early and getting used to working with that kind of tooling early in a project or a product. I think it has an analogous effect to, like, thinking about, like, compounding interest in, like, a savings account or investing or something like that. In that, by having those tools available early on and having that visibility available early on, you can really both initially get a lot of value and just kind of understanding kind of what's happening with your system and very quickly troubleshoot problems and make sure things are running efficiently.

+ +

But then that can help get to a place where you get to that, like, flywheel effect as you're kind of building your product of, as you're able to solve things quickly, that means you have more time to invest in other parts of the product, and so on and so forth. So, yeah, it's one of those things where kind of the earlier you can get started on that, the more that benefit gets amplified over time.

+ +

And thankfully, with Datadog and other offerings like that now, you can get started with that relatively quickly, right? You're not having to necessarily make the choice of, like, oh, can I justify spending a week, a month, whatever, setting up all my own infrastructure for this, as opposed to, you know, plugging in a credit card and getting going right away? And not necessarily starting with everything from day zero but getting started with something and then being able to build on that definitely can be a worthwhile trade-off. [laughs]

+ +

VICTORIA: That makes sense. And I'm curious your perspective, Will, as a developer on our Lift Off team, which is really about the services around that time when you want to start taking it really seriously. Like, you've built an app [laughs]. You know it's a viable product, and there's a market for it. And just, like, how you think about observability when you're doing your app building.

+ +

WILL: The approach I really take is, like, what is the end goal? I'm currently on a project right now that we came in later than normal. We're trying to work through that.

+ +

SEAN: I haven't come from, you know, that kind of consulting and professional services and support kind of place. I'm curious about, like, what, if any, differences or experiences do you have, like, in that context of, like, how do you use your observability tools or, like, what value they have as opposed to maybe more, like, straight product development?

+ +

VICTORIA: Right. So, we recently partnered with, you know, our platform engineering team worked with the Lift Off team to create a product from scratch. And we built in observability tools with Prometheus, and Grafana, and Sentry so that the developers could instrument their app and build metrics around the performance in the way they expected the application to work so that when it goes live and meets real users, they're confident their users are able to actually use the app with a general acceptable level of latency and other things that are really key to the functionality of the app.

+ +

And so, I think that the interesting part was, with the founders who don't have a background in IT operations or application monitoring and performance, it sort of makes sense. But it's still maybe a stretch to really see the full value of that, especially when you're just trying to get the app out the door.

+ +

SEAN: Nice.

+ +

VICTORIA: [chuckles] That's my answer. What kind of challenges do you have in your role managing this large team in a very competitive company, running a ton of Kubernetes clusters? [laughs] What's your challenges in your director of engineering role there?

+ +

SEAN: You know, it's definitely a mix of kind of, like, technical or strategic challenges there, as well as people challenges. On the technical and strategic side, the interesting thing for our team right now is we're in the middle of a very interesting transition. Still, today, the teams at Datadog work in very much a 'You build it, you run it' kind of model, right? So, teams working on user-facing features in addition to, like, you know, designing those features and writing the code for that, they're responsible for deploying that code, offering the services that code runs within, being on call for that, so on and so forth.

+ +

And until relatively recently, that ownership was very intense to the point where some teams maybe even had their own build and release processes. They were running their own data stores. And, like, that was very valuable for much of our history because that let those teams to be very agile and not have to worry about, like, convincing the entire company to change if they needed to make some kind of change.

+ +

But as we've grown and as, you know, we've kind of taken on a lot more complexity in our environment from, you know, running across more providers, running across more regions, taking on more of regulatory concerns, to kind of the viability of running everything entirely [inaudible 12:13] for those product teams, it has become much harder. [laughs]

+ +

You start to see a transition where previously the infrastructure teams were much more acting as subject matter experts and consultants to, now, we're increasingly offering more centralized platforms and offerings that can offload a lot of that kind of complexity and the stuff that isn't the core of what the other product-focused teams are trying to do.

+ +

And so, as we go through that change, it means internally, a lot of our teams, and how we think about our roles, and how we go about doing our work, changes from, like, a very, you know, traditional reliability type one on one consultation and advising type role to effectively internal product development and internal platform development. So, that's a pretty big both mindset and practice shift. [laughs] So, that's one that we're kind of evolving our way through.

+ +

And, of course, as what happens to kind of things, like, you still have to do all the old stuff while you're doing the new thing. [laughs] You don't get to just stop and just do the new thing. So, that's been an interesting kind of journey and one that we're always kind of figuring out as we go. That is a lot of kind of what I focus on.

+ +

You know, people wise, you know, we have an interesting aim of...There's about 40 people in my org. They are spread across EMEA and North America with kind of, let's say, hubs in New York and Paris. So, with that, you know, you have a pretty significant time zone difference and some non-trivial cultural differences. [laughs] And so, you know, making sure that everybody is still able to kind of work efficiently, and communicate effectively, and collaborate effectively, while still working within all those constraints is always an ongoing challenge. [laughs]

+ +

WILL: Yeah, you mentioned the different cultures, the different types of employees you have, and everyone is not the same. And there's so many cultures, so many...whatever people are going through, you as a leader, how do you navigate through that? Like, how do you constantly challenge yourself to be a better leader, knowing that not everyone can be managed the same way, that there's just so much diversity, probably even in your company among your employees?

+ +

SEAN: I think a lot of it starts from a place of listening and paying attention to kind of just see where people are happy, where they feel like they have unmet needs. As an example, I moved from that last kind of data store-focused team to this computing cloud team last November.

+ +

And so, as part of that move, probably for the first two or three months that I was in the role, I wasn't particularly driving much in the way of changes or setting much of a vision beyond what the team already had, just because as the new person coming in, it's usually kind of hard to have a lot of credibility and/or even just have the idea of, like, you know, like you're saying, like, what different people are looking for, or what they need, how they will respond best.

+ +

I just spend a lot of time just talking to people, getting to know the team, building those relationships, getting to know those people, getting to know those groups. And then, from there, figuring out, you know, both where the kind of the high priority areas where change or investment is needed. But then also figuring out, yeah, kind of based on all that, what's the right way to go about that with the different groups? Because yeah, it's definitely isn't a one size fits all solution.

+ +

But for me, it's always kind of starting from a place of listening and understanding and using that to develop, I guess, empathy for the people involved and understanding their perspectives and then figuring it out from there. I imagine–I don't know, but I imagine thoughtbot's a pretty distributed company. How do you all kind of think about some of those challenges of just navigating people coming from very different contexts?

+ +

WILL: Yeah, I was going to ask Victoria that because Victoria is one of the leaders of our team here at thoughtbot. So, Victoria, what are your thoughts on it?

+ +

VICTORIA: I have also one of the most distributed teams at thoughtbot because we do offer 24/7 support to some clients. And we cover time zones from the Pacific through West Africa. So, we just try to create a lot of opportunities for people to engage, whether it's remotely, especially offering a lot of virtual engagement and social engagement remotely. But then also, offering some in-person, whether it's a company in-person event, or encouraging people to engage with their local community and trying to find conferences, meetups, events that are relevant to us as a business, and a great opportunity for them to go and get some in-person interaction. So, I think then encouraging them to bring those ideas back.

+ +

And, of course, thoughtbot is known for having just incredible remote async communication happening all the time. It's actually almost a little oppressive to keep up with, to be honest, [laughs] but I love it. There's just a lot of...there's GitHub issues. There's Slack communications. There's, like, open messages. And people are really encouraged to contribute to the conversation and bring up any idea and any problem they're having, and actively add to and modify our company policies and procedures so that we can do the best work with each other and know how to work with each other, and to put out the best products.

+ +

I think that's key to having that conversation, especially for a company that's as big as Datadog and has so many clients, and has become such a leader in this metrics area. Being able to listen within your company and to your clients is probably going to set you up for success for any, like, tech leadership role [laughs].

+ +

I'm curious, what are you most excited about now that you've been in the role for a little while? You've heard from a lot of people within the company. Can you share anything in your direction in the next six months or a year that you're super excited about?

+ +

SEAN: So, there's usually kind of probably two sides to that question of kind of, like, from a product and business standpoint and from an internal infrastructure standpoint, given that's where my day-to-day focus is. You know, on the product side, one thing that's been definitely interesting to watch in my time at Datadog is we really made the transition from kind of, like, a point solution type product to much more of a platform.

+ +

For context, when I joined Datadog, I think logs had just gone GA, and APM was in beta, I think. So, we were just starting to figure out, like, how we expand beyond the initial infrastructure metrics product. And, obviously, at this point, now we have a whole, you know, suite of offerings. And so, kind of the opportunities that come with that, as far as both different spaces that we can jump into, and kind of the value that we can provide by having all those different capabilities play together really nicely, is exciting and is cool.

+ +

Like, you know, one of the things that definitely lit an interesting light bulb for me was talking to some of the folks working on our newer security offerings and them talking about how, obviously, you want to meet, you know, your normal requirements in that space, so being able to provide the visibility that, you know, security teams are looking for there.

+ +

But also, figuring out how we integrate that information into your developers' everyday experience so that they can have more ownership over that aspect of the systems that they're building and make everybody's job easier and more efficient, right? Instead of having, you know, the nightmare spreadsheet whenever a CVE comes out and having some poor TPM chase half the company to get their libraries updated, you know, being able to make that visible in the product where people are doing their work every day, you know, things like that are always kind of exciting opportunities.

+ +

On the internal side, we're starting to think about, like, what the next major evolution of our kind of Kubernetes and kind of internal build and release tooling looks like. Today, a lot of kind of how teams interact with our Kubernetes infrastructure is still pretty raw. Like, they're working directly with specific Kubernetes clusters, and they are exposed to all the individual Kubernetes primitives, which is very powerful, but it's also a pretty steep learning curve. [laughs]

+ +

And for a lot of teams, it ends up meaning that there's lots of, you know, knobs that they have to know what they do. But at the end of the day, like, they're not getting a lot of benefit from that, right? There's more just opportunity for them to accidentally put themselves in a bad place. So, we're starting to figure out, like, higher level abstractions and offerings to simplify how all that for teams look like.

+ +

So, we're still a bit early days in working through that, but it's exciting to figure out, like, how we can still give teams kind of the flexibility and the power that they need but make those experiences much easier and not have to have them become Kubernetes experts just to deploy a simple process. And, yes, so there's some lots of fun challenges in there. [laughs]

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

WILL: I have a question around your experience. So, you've been a developer around 20 years. What has been your experience over that 20 years or about of the growth in this market? Because I can only imagine what the market was, you know, in the early 2000s versus right now because I still remember...I still have nightmares of dial-up, dial tone tu-tu-tu. No one could call you, stuff like that. So, what has been your experience, just seeing the market grow from where you started?

+ +

SEAN: Sure, yeah. I think probably a lot of the biggest pieces of it are just seeing the extent to which...I want to say it was Cory Doctorow, but I'm not sure who actually originally coined the idea, but the idea that, you know, software is eating the world, right? Like, eventually, to some degree, every company becomes a software company because software ends up becoming involved in pretty much everything that we as a society do.

+ +

So, definitely seeing the progression of that, I think, over that time period has been striking, you know, especially when I was working in more consulting contexts and working more in companies and industries where like, you know, the tech isn't really the focus but just how much that, you know, from an engineering standpoint, relatively basic software can fundamentally transform those businesses and those industries has definitely been striking.

+ +

And then, you know, I think from a more individual perspective, seeing as, you know, our tools become more sophisticated and easier to access, just seeing how much of a mixed bag that has become [laughs]. And just kind of the flavor of, like, you know, as more people have more powerful tools, that can be very enabling and gives voice to many people. But it also means that the ability of an individual or a small group to abuse those tools in ways that we're maybe not fully ready to deal with as a society has been interesting to see how that's played out.

+ +

VICTORIA: Yeah. I think you bring up some really great points there. And it reminds me of one of my favorite quotes is that, like, the future is here—it's just not evenly distributed. [laughs] And so, in some communities that I go to, everyone knows what Kubernetes is; everyone knows what DevOps is. It's kind of, like, old news. [laughs] And then, some people are still just like, "What?" [laughs].

+ +

It's interesting to think about that and think about the implications on your last point about just how dangerous the supply chain is in building software and how some of these abstractions and some of these things that just make it so easy to build applications can also introduce a good amount of risk into your product and into your business, right? So, I wonder if you can tell me a little bit more about your perspective on security and DevSecOps and what founders might be thinking about to protect their IP and their client's data in their product.

+ +

SEAN: That one is interesting and tricky in that, like, we're in a little bit of, like, things are better and worse than they ever have been before [laughs], right? Like, there is a certain level of, I think, baseline knowledge and competency that I think company leaders really just have to have now, part of, like, kind of table stakes, which can definitely be challenging, and that, like, that probably was much less, if even the case, you know, 10-20 years ago in a lot of businesses.

+ +

As an example, right? Like, obviously, like if it's a tech-focused company, like, that can be a thing. But, like, if you're running a plumbing business with a dozen trucks, let's say, like, 20 years ago, you probably didn't have to think that much about data privacy and data security. But, like, now you're almost certainly using some kind of electronic system to kind of manage all your customer records, and your job scheduling, and all that kind of stuff. So, like, now, that is something that's a primary concern for your business.

+ +

On the flip side of that, I think there is much better resources, and tools, and practices available out there. I forget the name of the tool now. But I remember recently, I was working with a company on the ISO long string of numbers certifications that you tend to want to do when you're handling certain types of data. There was a tool they were able to work with that basically made it super easy for them to, like, gather all the evidence for that and whatnot, in a way where, like, you know, in the past, you probably just had to hire a compliance person to know what you had to do and how to present that.

+ +

But now, you could just sign up for a SaaS product. And, like, obviously, it can't just do it for you. Like, it's about making your policies. But it still gave you enough support where if you're, like, bootstrapping a company, like, yeah, you probably don't need to hire a specialist to [inaudible 25:08], which is a huge deal.

+ +

You know, similarly, a lot of things come much safer by default. When you think about, like, the security on something like an iPhone, or an iPad, or an Android device, like, just out of the box, that's light-years ahead of whatever Windows PC you were going to buy ten years ago. [laughs] And so, that kind of gives you a much better starting place. But some interesting challenges that come with that, right? And that we do now, literally, every person on the planet is walking around with microphones and cameras and all kinds of sensors on them. It's an interesting balance, I think.

+ +

Similarly, I'm curious how you all think about kind of talking with your clients and your customers about this because I'm sure you all have a non-trivial amount of education to do there. [laughs]

+ +

VICTORIA: Yeah, definitely. And I think a lot of it comes in when we have clients who are very early founders, and they don't have a CTO or a technical side of their business, and advising them on exactly what you laid out. Like, here's the baseline. Like, here's where you want to start from. We generally use the CIS controls, this internet for internet security. It puts out a really great tool set, too, for some things you were mentioning earlier. Let's figure out how to report and how to identify all of the things that we're supposed to be doing. It could be overwhelming. It's a lot.

+ +

Like, in my past role as VP of Operations at Pluribus Digital, I was responsible for helping our team continue to meet our...we had three different ISO long number certifications [laughs]. We did a CMMI as well, which has come up a few times in my career. And they give you about a couple of hundreds of controls that you're supposed to meet. It's in very kind of, like, legalese that you have to understand. And that's a pretty big gap to solve for someone who doesn't have the technical experience to start.

+ +

Like, what you were saying, too, that it's more dangerous and more safer than it has been before. So, if we make choices for those types of clients in very safe, trusted platforms, then they're going to be set up for success and not have to worry about those details as much. And we kind of go forward with confidence that if they are going to have to come up against compliance requirements or local state regulations, which are also...there's more of those every day, and a lot of liability you can face as a founder, especially if you're dealing with, like, health or financial data, in the state of California, for example. [laughs]

+ +

It puts you at a really big amount of liability that I don't think we've really seen the impact of how bad it can be and will be coming out in the next couple of years now that that law has passed. But that's kind of the approach that we like to think. It's like, you know, there's a minimum we can do that will mitigate a lot of this risk [laughs], so let's do that. Let's do the basics and start off on the right foot here.

+ +

SEAN: Yeah, no, that makes sense. Yeah, it's definitely something I've come to appreciate, especially doing work in regulated spaces is, when you do reach the point where you do need to have some kind of subject matter expert involved, whether it's somebody in-house or a consultant or an advisor, I've definitely learned that usually, like, the better ones are going to talk to you in terms of, like, what are the risk trade-offs you're making here? And what are the principles that all these detailed controls or guidelines are looking to get at?

+ +

As opposed to just, like, walking you through the box-checking exercise. In my experience, a really good lawyer or somebody who will talk to you about risk versus just saying whether or not you can do something. [laughs] It has a very similar feeling in my experience.

+ +

VICTORIA: Yeah, it's a lot about risk. And someone's got to be able to make those trade-off decisions, and it can be really tough, but it's doable. And I think it shouldn't scare people away. And there's lots of people, lots of ways to do it also, which is exciting. So, I think it's a good space to be in and to see it growing and pay attention to. [laughs]

+ +

It's fun for me to be in a different place where we're given the opportunity to kind of educate or bring people along in a security journey versus having it be a top-down executive-level decision that we need to meet this particular security standard, and that's the way it's going to be. [laughs] Yeah, so that I appreciate.

+ +

Is there anything that really surprised you in your conversations with Datadog or with other companies around these types of services for, like, platform engineering and observability? Is there anything that surprised you in the discovery process with potential clients for your products?

+ +

SEAN: I think one of the biggest surprises, or maybe not a surprise but an interesting thing is, to what extent, you know, for us, I don't know if this is still the case, but I think in many places, like, we're probably more often competing against nothing than a competing product. And by that, I mean, especially as you look at some of our more sophisticated products like APM, or profiling, it's not so much that somebody has an existing tool that we're looking to replace; it's much more than this is just not a thing they do today. [laughs]

+ +

And so, that leads to a very interestingly different conversation that I think, you know, relates to some of what we were saying with security where, you know, I think a non-trivial part of what our sales and technical enablement folks do is effectively education for our customers and potential customers of why they might want to use tools like this, and what kind of value they could get from them.

+ +

The other one that's been interesting is to see how different customers' attitudes around tools like this have evolved as they've gone through their own migration to the cloud journeys, right? We definitely have a lot of customers that, I think, you know, 5, 10 years ago, when they were running entirely on-prem, using a SaaS product would have been a complete non-starter.

+ +

But as they move into the cloud, both as they kind of generally get more comfortable with the idea of delegating some of these responsibilities, as well as they start to understand kind of, like, the complexity of the tooling required as their environment gets more complex, the value of a dedicated product like something like Datadog as opposed to, you know, what you kind of get out of the box with the cloud providers or what you might kind of build on your own has definitely been interesting. [laughs]

+ +

VICTORIA: Is there a common point that you find companies get to where they're like, all right, now, I really need something? Can you say a little bit more about, like, what might be going on in the organization at that time?

+ +

SEAN: You know, I think there could be a few different paths that companies take to it. Some of it, I think, can come from a place of...I think, especially for kind of larger enterprise customers making a transition like that, they tend to be taking a more holistic look at kind of their distinct practices and seeing what they want to change as they move into the cloud. And often, kind of finding an observability vendor is just kind of, like, part of the checklist there. [laughs] Not to dismiss it, but just, like, that seems to be certainly one path into it.

+ +

I think for smaller customers, or maybe customers that are more, say, cloud-native, I think it can generally be a mix of either hitting a point where they're kind of done with the overhead of trying to maintain their own infrastructure of, like, trying to run their own ELK stack and, like, build all the tooling on top of that, and keeping that up and running, and the costs associated with that. Or, it's potentially seeing the sophistication of tooling that, like, a dedicated provider can afford to invest that realistically, you're never going to invest in on your own, right? Like, stuff like live profiling is deeply non-trivial to implement. [laughs]

+ +

I think especially once people get some experience with a product like Datadog, they start thinking about, like, okay, how much value are we actually getting out of doing this on our own versus using a more off-the-shelf product? I don't know if we've been doing it post-COVID. But I remember pre-COVID...so Datadog has a huge presence at re:Invent and the other similar major cloud provider things.

+ +

And I remember for a few years at re:Invent, you know, we obviously had, like, the giant 60x60 booth in the main expo floor, where we were giving demos and whatnot. But they also would have...AWS would do this, like, I think they call it the interactive hall where companies could have, like, more hands-on booths, and you had, like, a whole spectrum of stuff. And there were, like, some companies just had, like, random, like, RC car setups or Lego tables, just stuff like that.

+ +

But we actually did a setup where there was a booth of, I think, like, six stations. People would step up, and they would race each other to solve a kind of faux incident using Datadog. The person who would solve it first would win a switch. I think we gave away a huge number of switches as part of that, which at first I was like, wow, that seems expensive. [laughs]

+ +

But then later, you know, I was mostly working the main booth at that re:Invent. So by the, like, Wednesday and Thursday of re:Invent, I'd have people walking up to the main booth being like, "Hey, so I did the thing over at the Aria. And now I installed Datadog in prod last night, and I have questions." I was like, oh, okay. [laughs] So, I think just, like, the power of, like, getting that hands-on time, and using some of the tools, and understanding the difference there is what kind of gets a lot of people to kind of change their mind there. [laughs]

+ +

VICTORIA: You'd get me with a switch right now. I kind of want one, but I don't want to buy one.

+ +

SEAN: [laughs]

+ +

WILL: Same. [laughs]

+ +

VICTORIA: Because I know it'll take up all my time.

+ +

SEAN: Uh-huh. That's fair. [laughs]

+ +

VICTORIA: But I will try to win one at a conference for sure. I think that's true. And it makes sense that because your product is often going with clients that don't have these practices yet, that as soon as you give them exposure to it, you see what you can do with it, that becomes a very powerful selling tool. Like, this is the value of the product, right? [laughs]

+ +

SEAN: Yeah, there is also something we see, and I think most of our kind of peers in the industry see is, very often, people come in initially looking for and using a single product, like, you know, infrastructure, metrics, or logs. And then, as they see that and see where that touches other parts of the product, their usage kind of grows and expands over time. I would obviously defer to our earnings calls for exact numbers. But generally speaking, more or less kind of half of our new business is usually expanded usage from existing customers as opposed to new customers coming in. So, I think there's also a lot of just kind of organic discovery and building of trust over time that happens there, which is interesting.

+ +

VICTORIA: One of my favorite points to make, which is that SRE sounds very technical and, like, this really extreme thing. But to make it sound a little more easier, is that it is how you validate that the user experience is what you expect it to be. [laughs] I wonder if you have any other thoughts you want to add to that, just about, like, SRE and user experience and how that all connects for real business value.

+ +

SEAN: I think a lot of places where, you know, we've both seen internally ourselves and with customers is, you know; obviously, different companies operate in different models and whatnot. Where people have seen success is where, you know, people with formal SRE titles or team names can kind of be coming in as just kind of another perspective on the various kind of things that teams are trying to drive towards.

+ +

The places reliability is successfully integrated is when they can kind of make that connection that you were talking about. It's, like, obviously, everybody should go take their vitamins, but, like, what actual value is coming from this, right? Nobody wants to have outages, but, like, to do the work to invest in reliability, often, like, it can be hard to say, like, okay, what's the actual difference between before and after? Having people who can help draw those connections and help weigh those trade-offs, I think, can definitely be super helpful.

+ +

But it is generally much more effective, I think, in my experience, when it does come from that perspective of, like, what value are we providing? What are we trading off as part of this? As opposed to just, well, you should do this because it's the right thing to do, kind of a moralistic perspective. [laughs] But, I don't know, how do you all kind of end up having that conversation with your customers and clients?

+ +

VICTORIA: That's exactly it. That's the same. It's starting that conversation about, like, well, what happens when this experience fails, which designers don't necessarily think about? What's, like, the most important paths that you want a user to take through your application that we want to make sure works?

+ +

And when you tie it all back there, I think then when the developers are understanding how to create those metrics and how to understand user behavior, that's when it becomes really powerful so that they're getting the feedback they need to do the right code, and to make the right changes. Versus just going purely on interviews [laughs] and not necessarily, like, understanding behavior within the app. I think that starts to make it clear.

+ +

SEAN: Part of that, I think that's been an interesting experience for us is also just some of the conversation there around, like, almost the flip side of, when are you investing potentially too much in that, right? Because, like, especially after a certain point, the cost of additional gains grows exponentially, right? Each one of those nines gets more and more expensive. [laughs]

+ +

And so, having the conversation of, like, do you actually need that level of reliability, or, like, is that...just like what you're saying. Like, you know, kind of giving some of that context and that pressure of, like, yeah, we can do that, but, like, this is what it's going to cost. Is that what you want to be spending your money on? Kind of things can also be an interesting part of that conversation.

+ +

VICTORIA: That's a really good point that, you know, you can set goals that are too high [laughs] and not necessary. So, it does take a lot of just understanding about your data and your users to know what are acceptable levels of error.

+ +

I think the other thing that you can think about, too, like, what could happen, and we've seen it happen with some startups, is that, like, something within the app is deeply broken, but you don't know. And you just think that you're not having user engagement, or that users are signing off, or, like, you know, not opening the app after the first day.

+ +

So, if you don't have any way to really actively monitor it and you're not spending money on an active development team, you can have some method to just be confident that the app is working and to make your life less miserable [laughs] when you have a smaller team supporting, especially if you're trying to really minimize your overhead for running an application.

+ +

SEAN: Yep. It's surprisingly hard to know when things are broken sometimes. [laughs]

+ +

VICTORIA: Yes, and then extremely painful when you find out later [laughs] because that's when it's become a real problem, yeah. I wonder, are there any other questions you have for me or for Will?

+ +

SEAN: How big of an organization is thoughtbot at this time?

+ +

VICTORIA: Close to 75 people? We're, yeah, between the Americas and the [inaudible 38:31] region. So, that's where we're at right now, yeah.

+ +

SEAN: Nice. At that size, like, and I guess it sounds like you're pretty heavily distributed, so maybe some of this doesn't happen as much, but, like, one of the things I definitely remember...so, when I joined Datadog, it was probably about 500 people. And I think we're just under 5,000 now. There are definitely some points where there were surprisingly, like, physical aspects to where it became a problem of just, like, where certain teams didn't fit into a room anymore. [laughs] Like, I had surprise in the changes in that, like, dynamic. I'm curious if you've all kind of run into any kind of, I don't know, similar interesting thresholds or changes as you've kind of grown and evolved.

+ +

WILL: I will say this, we're about 100, I think, Victoria.

+ +

VICTORIA: Oh, okay, we're 100 people. I think, you know, I've only been at thoughtbot for just over a year now. And my understanding of the history is that when we were growing before COVID, there's always been a very intentionality about growth. And there was never a goal to get to a huge size or to really grow beyond just, like, a steady, profitable growth. [laughs]

+ +

So, when we were growing in person, there were new offices being stood up. So, we, you know, maybe started out of New York and Boston and grew to London. And then, there was Texas, and I think a few other ones that started. Then with COVID, the decision was made to go fully remote, and I think that's opened up a lot of opportunities for us. And from my understanding in the previous and the past, is that there's a big shift to be fully remote.

+ +

It's been challenging, where I think a lot of people miss some of the in-person days, and I'm sure it's definitely lonely working remote all day by yourself. So, you have to really proactively find opportunities to see other people and to engage remotely. But I think also, we hire people from so many different places and so much different talent, and then, also, you know, better informs our products and creates a different, you know, energy within the company that I think is really fun and really exciting for us now.

+ +

WILL: Yeah, I would agree with that because I think the team that I'm on has about 26 people on the Lift Off team. And we're constantly thinking of new ways to get everyone involved. But as a developer, me myself being remote, I love talking to people. So, I try to be proactive and, like, connect with the people I'm working with and say, "Hey, how can I help you with this?" Let's jump in this room and just work together, chat together, and stuff like that, so...

+ +

And it has opened the door because the current project that I'm on, I would never have had an opportunity to be on. I think it's based in Utah, and I'm in South Florida. So, there's just no way if we weren't remote that I'd been a part of it. So...

+ +

SEAN: Nice. And I can definitely appreciate that. I remember when we first started COVID lockdown; I think, at that point, Datadog was probably about...Datadog engineering was probably about 30% remote, so certainly a significant remote contingent but mixed. But my teams were pretty remote-heavy. So, in some ways, not a lot changed, right? Like, I think more people on my team were, like, who are all these other people in my house now instead of [laughs], I mean, just transition from being in an office to working from home.

+ +

But I do remember maybe, like, about six months in, starting to feel, yeah, some of the loneliness and the separation of just, like, not being able to do, like, quarterly team meetups or stuff like that. So, it's definitely been an interesting transition. For context, at this point, we kind of have a hybrid setup. So, we still have a significant kind of full-time remote contingent, and then four people who are in office locations, people joining for about three days a week in office. So, it's definitely an interesting transition and an interesting new world. [laughs]

+ +

VICTORIA: Yeah. And I'm curious how you find the tech scene in Denver versus New York or if you're engaging in the community in the same way since you moved.

+ +

SEAN: There definitely is some weirdness since COVID started [laughs] broadly [inaudible 42:21]. So, I moved here in 2020. But I'd been coming out here a lot before that. I helped to build an office here with Bitly. So, I was probably coming out once a quarter for a bunch of years. So, one parallel that is finally similar is, like, in both places, it is a small world. It doesn't take that long for you to be in that community, in either of those communities and start running into the same people in different places. So, that's always been [inaudible 42:42] and especially in New York. New York is a city of what? 8, 9 million people?

+ +

But once you're working in New York tech for a few years and you go into some meetups, you start running into the same people, and you have one or two degrees [inaudible 42:52] to a lot of people, surprisingly quickly. [laughs] So, that's similar. But Denver probably is interesting in that it's definitely transplant-heavy. I think Denver tends to check the box for, like, it was part of why Bitly opened an office here and, to a degree, Datadog as well.

+ +

I think of like, you know, if you're trying to recruit people and you previously were mostly recruiting in, like, New York or Silicon Valley; if you're based in New York, and you're trying to recruit somebody from Silicon Valley, and part of why they're looking for a new gig is they're burned out on Silicon Valley, asking them to move to New York probably isn't all that attractive. [laughs] But Denver is different enough in that in terms of kind of being a smaller city, easier access to nature, a bunch of that kind of stuff, that a lot of times we were able to attract talent that was a much more appealing prospect. [laughs]

+ +

You'll see an interesting mix of industries here. One of the bigger things here is there's a very large government and DOD presence here. I remember I went to DevOps Days Rockies, I think, a few years ago. There was a Birds of a Feather session on trying to apply DevOps principles in air-gapped networks. That was a very interesting conversation. [laughs]

+ +

VICTORIA: That's interesting. I would not have thought Colorado would be a big hub for federal technology. But there you go, it's everywhere.

+ +

WILL: Yeah.

+ +

SEAN: Denver metro, I think, is actually the largest presence of federal offices outside of the D.C. metro.

+ +

VICTORIA: That's interesting. Yeah, I'm used to trying to recruit people into D.C., and so, it's definitely not the good weather, [laughs], not a good argument in my favor. So, I just wanted to give you a final chance. Anything else you'd like to promote, Sean?

+ +

SEAN: Generally, not super active on social things these days, but you can find whatever I have done at seanoc.com, S-E–A-N-O-C.com for the spelling. And otherwise, if you're interested in some engineering content and hearing about some of those kind of bleeding edge challenges that I was mentioning before, I would definitely check out the Datadog engineering blog. There's lots of kind of really interesting content there on both, you know, things we've learned from incidents and interesting projects that we're working on. There's all kinds of fun stuff there.

+ +

VICTORIA: That makes me think I should have asked you more questions, Sean. [laughs] No, I think it was great. Thank you so much for joining us today. I'll definitely check all that stuff out.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Sean O'Connor.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sean O'Connor is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications.

+ +

Sean discusses his transition from an individual contributor to management and shares why he chose Datadog, emphasizing the appeal of high-scale problems and the real business nature of the company. They delve into the importance of performance management and observability and cover the cultural and technical challenges Sean faces in managing a diverse, geographically spread team, and discuss the transition at Datadog from a decentralized model to more centralized platforms, the corresponding changes in both technical strategies and people management, and what excites him about Datadog's future, including the integration of security offerings into developers' daily experiences, and the evolution of Kubernetes and internal build and release tooling.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Sean O'Connor. He is the Director of Engineering at Datadog. Datadog is the essential monitoring and security platform for cloud applications. Sean, thank you for joining us.

+ +

SEAN: Hi, thanks for having me on.

+ +

VICTORIA: Yeah, I'm super excited to get to talking with you about everything cloud, and DevOps, and engineering. But why don't we first start with just a conversation about what's going on in your life? Is there any exciting personal moment coming up for you soon?

+ +

SEAN: Yeah, my wife and I are expecting our first kiddo in the next few weeks, so getting us prepared for that as we can and trying to get as much sleep as we can. [laughs]

+ +

WILL: Get as much sleep as you can now, so...[laughs] I have a question around that. When you first found out that you're going to be a dad, what was your feeling? Because I remember the feeling that I had; it was a mixed reaction of just everything. So, I just wanted to see what was your reaction whenever you found out that you're going to be a dad for the first time.

+ +

SEAN: Yeah, I was pretty excited. My wife and I had been kind of trying for this for a little while. We're both kind of at the older end for new parents in our late 30s. So, yeah, excited but definitely, I don't know, maybe a certain amount of, I don't know about fear but, you know, maybe just concerned with change and how different life will be, but mostly excitement and happiness. [laughs]

+ +

WILL: Yeah, I remember the excitement and happiness. But I also remember, like, wait, I don't know exactly what to do in this situation. And what about the situations that I have no idea about and things like that? So, I will tell you, kids are resilient. You're going to do great as a dad.

+ +

[laughter]

+ +

SEAN: Yep. Yeah, definitely; I think I feel much more comfortable about the idea of being a parent now than I may have been in my 20s. But yeah, definitely, the idea of being responsible for and raising a whole other human is intimidating. [laughs]

+ +

VICTORIA: I think the fact that you're worried about it is a good sign [laughs], right?

+ +

SEAN: I hope so. [laughs]

+ +

VICTORIA: Like, you understand that it's difficult. You're going to be a great parent just by the fact that you understand it's difficult and there's a lot of work ahead. So, I think I'm really excited for you. And I'm glad we get to talk to you at this point because probably when the episode comes out, you'll be able to listen to it with your new baby in hand. So...

+ +

WILL: Good. Excited for it. [laughs]

+ +

VICTORIA: Yeah, love that. Well, great. Well, why don't you tell me a little bit more about your other background, your professional background? What brought you to the role you're into today?

+ +

SEAN: Yeah. Well, like we mentioned in the beginning; currently, I'm a Director of Engineering at Datadog. I run our computing cloud team. It's responsible for all of our Kubernetes infrastructure, as well as kind of all the tooling for dealing with the cloud providers that we run on and as well as kind of [inaudible 02:54] crypto infrastructure.

+ +

Within Datadog, I've always been in management roles though I've kind of bounced around. I've been here for about five and a half years. So, before this, I was running a data store infrastructure team. Before that, when I first came in, I was running the APM product team, kind of bounced around between product and infra. And that's kind of, I guess, been a lot of the story of much of my career is wearing lots of different hats and kind of bouncing around between kind of infrastructure-focused roles and product-focused roles.

+ +

So, before this, I was running the back-end engineering and DevOps teams at Bitly. So, I was there for about five and a half years, started there originally as a software engineer. And before that, a lot of early-stage startups and consulting doing whatever needed doing, and getting to learn about lots of different kind of industries and domains, which is always fun. [laughs]

+ +

VICTORIA: That's great. So, you had that broad range of experience coming from all different areas of operations in my mind, which is, like, security and infrastructure, and now working your way into a management position. What was the challenge for you in making that switch from being such a strong individual contributor into an effective manager?

+ +

SEAN: Sure. You know, I think certainly there is a lot of kind of the classic challenges of learning to let go but still staying involved, right? You know, as a manager, if you're working on critical path tasks hands-on yourself, that's probably not a good sign. [laughs] On the other hand, if you come, like, completely divorced from what your team is doing, especially as, like, a team lead level kind of manager, you know, that's not great either. So, figuring that balancing act definitely was a bit tricky for me.

+ +

Similarly, I think time management and learning to accept that, especially as you get into, like, further steps along in your career that, like, you know, it's not even a question of keeping all the balls in the air, but more figuring out, like, what balls are made out of rubber and which ones are made out of glass, and maybe keeping those ones in the air. [laughs] So, just a lot of those kind of, like, you know, prioritization and figuring out, like, what the right level of involvement and context is, is definitely the eternal learning, I think, for me. [laughs]

+ +

WILL: I remember whenever I was looking to change jobs, kind of my mindset was I wanted to work at thoughtbot more because of the values. And I wanted to learn and challenge myself and things like that. And it was so much more, but those were some of the main items that I wanted to experience in my next job. So, when you changed, and you went from Bitly to Datadog, what was that thing that made you say, I want to join Datadog?

+ +

SEAN: Yeah, that was definitely an interesting job search and transition. So, at that point in time, I was living in New York. I was looking to stay in New York. So, I was kind of talking to a bunch of different companies. Both from personal experience and from talking to some friends, I wasn't super interested in looking at, like, working at mostly, like, the super big, you know, Google, Amazon, Meta type of companies. But also, having done, like, super early stage, you know, like, seed, series A type of companies, having played that game, I wasn't in a place in my life to do that either. [laughs] So, I was looking kind of in between that space.

+ +

So, this would have been in 2018. So, I was talking to a lot of, like, series A and series B-type companies. And most of them were, like, real businesses. [laughs] Like, they may not be profitable yet, but, like, they had a very clear idea of how they would get there and, like, what that would look like. And so, that was pleasant compared to some past points in my career.

+ +

But a lot of them, you know, I was effectively doing, like, automation of human processes, which is important. It has value. But it means that, like, realistically, this company will never have more than 50 servers. And when I worked at Bitly, I did have a taste for kind of working in those high-scale, high-availability type environments.

+ +

So, Datadog initially was appealing because it kind of checked all those boxes of, you know, very high-scale problems, high availability needs, a very real business. [laughs] This is before Datadog had gone public. And then, as I started to talk to them and got to know them, I also really liked a lot of kind of the culture and all the people I interacted with. So, it became a very clear choice very quickly as that process moved along.

+ +

VICTORIA: Yeah, a very real business. Datadog is one of the Gartner's Magic leaders for APM and observability in the industry. And I understand you're also one of the larger SaaS solutions running Kubernetes, right?

+ +

SEAN: Yep. Yeah, at this point. Five years ago, that story was maybe a little bit different. [laughs] But yeah, no, no, we definitely have a pretty substantial Kubernetes suite that we run everything on top of. And we get the blessings and curses of we get some really cool problems to work on, but there's also a lot of problems that we come across that when we talk to kind of peers in the industry about kind of how they're trying to solve them, they don't have answers yet either. [laughs] So, we get to kind of figure out a lot of that kind of early discovery games. [laughs]

+ +

VICTORIA: Yeah. I like how exciting and growing this industry is around kind of your compute and monitoring the performance of your applications. I wonder if you could kind of speak to our audience a little bit, who may not have a big technical background, about just why it's important to think about performance management and observability early on in your application.

+ +

SEAN: There can be a few pieces there. One of the bigger ones, I think, is thinking about that kind of early and getting used to working with that kind of tooling early in a project or a product. I think it has an analogous effect to, like, thinking about, like, compounding interest in, like, a savings account or investing or something like that. In that, by having those tools available early on and having that visibility available early on, you can really both initially get a lot of value and just kind of understanding kind of what's happening with your system and very quickly troubleshoot problems and make sure things are running efficiently.

+ +

But then that can help get to a place where you get to that, like, flywheel effect as you're kind of building your product of, as you're able to solve things quickly, that means you have more time to invest in other parts of the product, and so on and so forth. So, yeah, it's one of those things where kind of the earlier you can get started on that, the more that benefit gets amplified over time.

+ +

And thankfully, with Datadog and other offerings like that now, you can get started with that relatively quickly, right? You're not having to necessarily make the choice of, like, oh, can I justify spending a week, a month, whatever, setting up all my own infrastructure for this, as opposed to, you know, plugging in a credit card and getting going right away? And not necessarily starting with everything from day zero but getting started with something and then being able to build on that definitely can be a worthwhile trade-off. [laughs]

+ +

VICTORIA: That makes sense. And I'm curious your perspective, Will, as a developer on our Lift Off team, which is really about the services around that time when you want to start taking it really seriously. Like, you've built an app [laughs]. You know it's a viable product, and there's a market for it. And just, like, how you think about observability when you're doing your app building.

+ +

WILL: The approach I really take is, like, what is the end goal? I'm currently on a project right now that we came in later than normal. We're trying to work through that.

+ +

SEAN: I haven't come from, you know, that kind of consulting and professional services and support kind of place. I'm curious about, like, what, if any, differences or experiences do you have, like, in that context of, like, how do you use your observability tools or, like, what value they have as opposed to maybe more, like, straight product development?

+ +

VICTORIA: Right. So, we recently partnered with, you know, our platform engineering team worked with the Lift Off team to create a product from scratch. And we built in observability tools with Prometheus, and Grafana, and Sentry so that the developers could instrument their app and build metrics around the performance in the way they expected the application to work so that when it goes live and meets real users, they're confident their users are able to actually use the app with a general acceptable level of latency and other things that are really key to the functionality of the app.

+ +

And so, I think that the interesting part was, with the founders who don't have a background in IT operations or application monitoring and performance, it sort of makes sense. But it's still maybe a stretch to really see the full value of that, especially when you're just trying to get the app out the door.

+ +

SEAN: Nice.

+ +

VICTORIA: [chuckles] That's my answer. What kind of challenges do you have in your role managing this large team in a very competitive company, running a ton of Kubernetes clusters? [laughs] What's your challenges in your director of engineering role there?

+ +

SEAN: You know, it's definitely a mix of kind of, like, technical or strategic challenges there, as well as people challenges. On the technical and strategic side, the interesting thing for our team right now is we're in the middle of a very interesting transition. Still, today, the teams at Datadog work in very much a 'You build it, you run it' kind of model, right? So, teams working on user-facing features in addition to, like, you know, designing those features and writing the code for that, they're responsible for deploying that code, offering the services that code runs within, being on call for that, so on and so forth.

+ +

And until relatively recently, that ownership was very intense to the point where some teams maybe even had their own build and release processes. They were running their own data stores. And, like, that was very valuable for much of our history because that let those teams to be very agile and not have to worry about, like, convincing the entire company to change if they needed to make some kind of change.

+ +

But as we've grown and as, you know, we've kind of taken on a lot more complexity in our environment from, you know, running across more providers, running across more regions, taking on more of regulatory concerns, to kind of the viability of running everything entirely [inaudible 12:13] for those product teams, it has become much harder. [laughs]

+ +

You start to see a transition where previously the infrastructure teams were much more acting as subject matter experts and consultants to, now, we're increasingly offering more centralized platforms and offerings that can offload a lot of that kind of complexity and the stuff that isn't the core of what the other product-focused teams are trying to do.

+ +

And so, as we go through that change, it means internally, a lot of our teams, and how we think about our roles, and how we go about doing our work, changes from, like, a very, you know, traditional reliability type one on one consultation and advising type role to effectively internal product development and internal platform development. So, that's a pretty big both mindset and practice shift. [laughs] So, that's one that we're kind of evolving our way through.

+ +

And, of course, as what happens to kind of things, like, you still have to do all the old stuff while you're doing the new thing. [laughs] You don't get to just stop and just do the new thing. So, that's been an interesting kind of journey and one that we're always kind of figuring out as we go. That is a lot of kind of what I focus on.

+ +

You know, people wise, you know, we have an interesting aim of...There's about 40 people in my org. They are spread across EMEA and North America with kind of, let's say, hubs in New York and Paris. So, with that, you know, you have a pretty significant time zone difference and some non-trivial cultural differences. [laughs] And so, you know, making sure that everybody is still able to kind of work efficiently, and communicate effectively, and collaborate effectively, while still working within all those constraints is always an ongoing challenge. [laughs]

+ +

WILL: Yeah, you mentioned the different cultures, the different types of employees you have, and everyone is not the same. And there's so many cultures, so many...whatever people are going through, you as a leader, how do you navigate through that? Like, how do you constantly challenge yourself to be a better leader, knowing that not everyone can be managed the same way, that there's just so much diversity, probably even in your company among your employees?

+ +

SEAN: I think a lot of it starts from a place of listening and paying attention to kind of just see where people are happy, where they feel like they have unmet needs. As an example, I moved from that last kind of data store-focused team to this computing cloud team last November.

+ +

And so, as part of that move, probably for the first two or three months that I was in the role, I wasn't particularly driving much in the way of changes or setting much of a vision beyond what the team already had, just because as the new person coming in, it's usually kind of hard to have a lot of credibility and/or even just have the idea of, like, you know, like you're saying, like, what different people are looking for, or what they need, how they will respond best.

+ +

I just spend a lot of time just talking to people, getting to know the team, building those relationships, getting to know those people, getting to know those groups. And then, from there, figuring out, you know, both where the kind of the high priority areas where change or investment is needed. But then also figuring out, yeah, kind of based on all that, what's the right way to go about that with the different groups? Because yeah, it's definitely isn't a one size fits all solution.

+ +

But for me, it's always kind of starting from a place of listening and understanding and using that to develop, I guess, empathy for the people involved and understanding their perspectives and then figuring it out from there. I imagine–I don't know, but I imagine thoughtbot's a pretty distributed company. How do you all kind of think about some of those challenges of just navigating people coming from very different contexts?

+ +

WILL: Yeah, I was going to ask Victoria that because Victoria is one of the leaders of our team here at thoughtbot. So, Victoria, what are your thoughts on it?

+ +

VICTORIA: I have also one of the most distributed teams at thoughtbot because we do offer 24/7 support to some clients. And we cover time zones from the Pacific through West Africa. So, we just try to create a lot of opportunities for people to engage, whether it's remotely, especially offering a lot of virtual engagement and social engagement remotely. But then also, offering some in-person, whether it's a company in-person event, or encouraging people to engage with their local community and trying to find conferences, meetups, events that are relevant to us as a business, and a great opportunity for them to go and get some in-person interaction. So, I think then encouraging them to bring those ideas back.

+ +

And, of course, thoughtbot is known for having just incredible remote async communication happening all the time. It's actually almost a little oppressive to keep up with, to be honest, [laughs] but I love it. There's just a lot of...there's GitHub issues. There's Slack communications. There's, like, open messages. And people are really encouraged to contribute to the conversation and bring up any idea and any problem they're having, and actively add to and modify our company policies and procedures so that we can do the best work with each other and know how to work with each other, and to put out the best products.

+ +

I think that's key to having that conversation, especially for a company that's as big as Datadog and has so many clients, and has become such a leader in this metrics area. Being able to listen within your company and to your clients is probably going to set you up for success for any, like, tech leadership role [laughs].

+ +

I'm curious, what are you most excited about now that you've been in the role for a little while? You've heard from a lot of people within the company. Can you share anything in your direction in the next six months or a year that you're super excited about?

+ +

SEAN: So, there's usually kind of probably two sides to that question of kind of, like, from a product and business standpoint and from an internal infrastructure standpoint, given that's where my day-to-day focus is. You know, on the product side, one thing that's been definitely interesting to watch in my time at Datadog is we really made the transition from kind of, like, a point solution type product to much more of a platform.

+ +

For context, when I joined Datadog, I think logs had just gone GA, and APM was in beta, I think. So, we were just starting to figure out, like, how we expand beyond the initial infrastructure metrics product. And, obviously, at this point, now we have a whole, you know, suite of offerings. And so, kind of the opportunities that come with that, as far as both different spaces that we can jump into, and kind of the value that we can provide by having all those different capabilities play together really nicely, is exciting and is cool.

+ +

Like, you know, one of the things that definitely lit an interesting light bulb for me was talking to some of the folks working on our newer security offerings and them talking about how, obviously, you want to meet, you know, your normal requirements in that space, so being able to provide the visibility that, you know, security teams are looking for there.

+ +

But also, figuring out how we integrate that information into your developers' everyday experience so that they can have more ownership over that aspect of the systems that they're building and make everybody's job easier and more efficient, right? Instead of having, you know, the nightmare spreadsheet whenever a CVE comes out and having some poor TPM chase half the company to get their libraries updated, you know, being able to make that visible in the product where people are doing their work every day, you know, things like that are always kind of exciting opportunities.

+ +

On the internal side, we're starting to think about, like, what the next major evolution of our kind of Kubernetes and kind of internal build and release tooling looks like. Today, a lot of kind of how teams interact with our Kubernetes infrastructure is still pretty raw. Like, they're working directly with specific Kubernetes clusters, and they are exposed to all the individual Kubernetes primitives, which is very powerful, but it's also a pretty steep learning curve. [laughs]

+ +

And for a lot of teams, it ends up meaning that there's lots of, you know, knobs that they have to know what they do. But at the end of the day, like, they're not getting a lot of benefit from that, right? There's more just opportunity for them to accidentally put themselves in a bad place. So, we're starting to figure out, like, higher level abstractions and offerings to simplify how all that for teams look like.

+ +

So, we're still a bit early days in working through that, but it's exciting to figure out, like, how we can still give teams kind of the flexibility and the power that they need but make those experiences much easier and not have to have them become Kubernetes experts just to deploy a simple process. And, yes, so there's some lots of fun challenges in there. [laughs]

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

WILL: I have a question around your experience. So, you've been a developer around 20 years. What has been your experience over that 20 years or about of the growth in this market? Because I can only imagine what the market was, you know, in the early 2000s versus right now because I still remember...I still have nightmares of dial-up, dial tone tu-tu-tu. No one could call you, stuff like that. So, what has been your experience, just seeing the market grow from where you started?

+ +

SEAN: Sure, yeah. I think probably a lot of the biggest pieces of it are just seeing the extent to which...I want to say it was Cory Doctorow, but I'm not sure who actually originally coined the idea, but the idea that, you know, software is eating the world, right? Like, eventually, to some degree, every company becomes a software company because software ends up becoming involved in pretty much everything that we as a society do.

+ +

So, definitely seeing the progression of that, I think, over that time period has been striking, you know, especially when I was working in more consulting contexts and working more in companies and industries where like, you know, the tech isn't really the focus but just how much that, you know, from an engineering standpoint, relatively basic software can fundamentally transform those businesses and those industries has definitely been striking.

+ +

And then, you know, I think from a more individual perspective, seeing as, you know, our tools become more sophisticated and easier to access, just seeing how much of a mixed bag that has become [laughs]. And just kind of the flavor of, like, you know, as more people have more powerful tools, that can be very enabling and gives voice to many people. But it also means that the ability of an individual or a small group to abuse those tools in ways that we're maybe not fully ready to deal with as a society has been interesting to see how that's played out.

+ +

VICTORIA: Yeah. I think you bring up some really great points there. And it reminds me of one of my favorite quotes is that, like, the future is here—it's just not evenly distributed. [laughs] And so, in some communities that I go to, everyone knows what Kubernetes is; everyone knows what DevOps is. It's kind of, like, old news. [laughs] And then, some people are still just like, "What?" [laughs].

+ +

It's interesting to think about that and think about the implications on your last point about just how dangerous the supply chain is in building software and how some of these abstractions and some of these things that just make it so easy to build applications can also introduce a good amount of risk into your product and into your business, right? So, I wonder if you can tell me a little bit more about your perspective on security and DevSecOps and what founders might be thinking about to protect their IP and their client's data in their product.

+ +

SEAN: That one is interesting and tricky in that, like, we're in a little bit of, like, things are better and worse than they ever have been before [laughs], right? Like, there is a certain level of, I think, baseline knowledge and competency that I think company leaders really just have to have now, part of, like, kind of table stakes, which can definitely be challenging, and that, like, that probably was much less, if even the case, you know, 10-20 years ago in a lot of businesses.

+ +

As an example, right? Like, obviously, like if it's a tech-focused company, like, that can be a thing. But, like, if you're running a plumbing business with a dozen trucks, let's say, like, 20 years ago, you probably didn't have to think that much about data privacy and data security. But, like, now you're almost certainly using some kind of electronic system to kind of manage all your customer records, and your job scheduling, and all that kind of stuff. So, like, now, that is something that's a primary concern for your business.

+ +

On the flip side of that, I think there is much better resources, and tools, and practices available out there. I forget the name of the tool now. But I remember recently, I was working with a company on the ISO long string of numbers certifications that you tend to want to do when you're handling certain types of data. There was a tool they were able to work with that basically made it super easy for them to, like, gather all the evidence for that and whatnot, in a way where, like, you know, in the past, you probably just had to hire a compliance person to know what you had to do and how to present that.

+ +

But now, you could just sign up for a SaaS product. And, like, obviously, it can't just do it for you. Like, it's about making your policies. But it still gave you enough support where if you're, like, bootstrapping a company, like, yeah, you probably don't need to hire a specialist to [inaudible 25:08], which is a huge deal.

+ +

You know, similarly, a lot of things come much safer by default. When you think about, like, the security on something like an iPhone, or an iPad, or an Android device, like, just out of the box, that's light-years ahead of whatever Windows PC you were going to buy ten years ago. [laughs] And so, that kind of gives you a much better starting place. But some interesting challenges that come with that, right? And that we do now, literally, every person on the planet is walking around with microphones and cameras and all kinds of sensors on them. It's an interesting balance, I think.

+ +

Similarly, I'm curious how you all think about kind of talking with your clients and your customers about this because I'm sure you all have a non-trivial amount of education to do there. [laughs]

+ +

VICTORIA: Yeah, definitely. And I think a lot of it comes in when we have clients who are very early founders, and they don't have a CTO or a technical side of their business, and advising them on exactly what you laid out. Like, here's the baseline. Like, here's where you want to start from. We generally use the CIS controls, this internet for internet security. It puts out a really great tool set, too, for some things you were mentioning earlier. Let's figure out how to report and how to identify all of the things that we're supposed to be doing. It could be overwhelming. It's a lot.

+ +

Like, in my past role as VP of Operations at Pluribus Digital, I was responsible for helping our team continue to meet our...we had three different ISO long number certifications [laughs]. We did a CMMI as well, which has come up a few times in my career. And they give you about a couple of hundreds of controls that you're supposed to meet. It's in very kind of, like, legalese that you have to understand. And that's a pretty big gap to solve for someone who doesn't have the technical experience to start.

+ +

Like, what you were saying, too, that it's more dangerous and more safer than it has been before. So, if we make choices for those types of clients in very safe, trusted platforms, then they're going to be set up for success and not have to worry about those details as much. And we kind of go forward with confidence that if they are going to have to come up against compliance requirements or local state regulations, which are also...there's more of those every day, and a lot of liability you can face as a founder, especially if you're dealing with, like, health or financial data, in the state of California, for example. [laughs]

+ +

It puts you at a really big amount of liability that I don't think we've really seen the impact of how bad it can be and will be coming out in the next couple of years now that that law has passed. But that's kind of the approach that we like to think. It's like, you know, there's a minimum we can do that will mitigate a lot of this risk [laughs], so let's do that. Let's do the basics and start off on the right foot here.

+ +

SEAN: Yeah, no, that makes sense. Yeah, it's definitely something I've come to appreciate, especially doing work in regulated spaces is, when you do reach the point where you do need to have some kind of subject matter expert involved, whether it's somebody in-house or a consultant or an advisor, I've definitely learned that usually, like, the better ones are going to talk to you in terms of, like, what are the risk trade-offs you're making here? And what are the principles that all these detailed controls or guidelines are looking to get at?

+ +

As opposed to just, like, walking you through the box-checking exercise. In my experience, a really good lawyer or somebody who will talk to you about risk versus just saying whether or not you can do something. [laughs] It has a very similar feeling in my experience.

+ +

VICTORIA: Yeah, it's a lot about risk. And someone's got to be able to make those trade-off decisions, and it can be really tough, but it's doable. And I think it shouldn't scare people away. And there's lots of people, lots of ways to do it also, which is exciting. So, I think it's a good space to be in and to see it growing and pay attention to. [laughs]

+ +

It's fun for me to be in a different place where we're given the opportunity to kind of educate or bring people along in a security journey versus having it be a top-down executive-level decision that we need to meet this particular security standard, and that's the way it's going to be. [laughs] Yeah, so that I appreciate.

+ +

Is there anything that really surprised you in your conversations with Datadog or with other companies around these types of services for, like, platform engineering and observability? Is there anything that surprised you in the discovery process with potential clients for your products?

+ +

SEAN: I think one of the biggest surprises, or maybe not a surprise but an interesting thing is, to what extent, you know, for us, I don't know if this is still the case, but I think in many places, like, we're probably more often competing against nothing than a competing product. And by that, I mean, especially as you look at some of our more sophisticated products like APM, or profiling, it's not so much that somebody has an existing tool that we're looking to replace; it's much more than this is just not a thing they do today. [laughs]

+ +

And so, that leads to a very interestingly different conversation that I think, you know, relates to some of what we were saying with security where, you know, I think a non-trivial part of what our sales and technical enablement folks do is effectively education for our customers and potential customers of why they might want to use tools like this, and what kind of value they could get from them.

+ +

The other one that's been interesting is to see how different customers' attitudes around tools like this have evolved as they've gone through their own migration to the cloud journeys, right? We definitely have a lot of customers that, I think, you know, 5, 10 years ago, when they were running entirely on-prem, using a SaaS product would have been a complete non-starter.

+ +

But as they move into the cloud, both as they kind of generally get more comfortable with the idea of delegating some of these responsibilities, as well as they start to understand kind of, like, the complexity of the tooling required as their environment gets more complex, the value of a dedicated product like something like Datadog as opposed to, you know, what you kind of get out of the box with the cloud providers or what you might kind of build on your own has definitely been interesting. [laughs]

+ +

VICTORIA: Is there a common point that you find companies get to where they're like, all right, now, I really need something? Can you say a little bit more about, like, what might be going on in the organization at that time?

+ +

SEAN: You know, I think there could be a few different paths that companies take to it. Some of it, I think, can come from a place of...I think, especially for kind of larger enterprise customers making a transition like that, they tend to be taking a more holistic look at kind of their distinct practices and seeing what they want to change as they move into the cloud. And often, kind of finding an observability vendor is just kind of, like, part of the checklist there. [laughs] Not to dismiss it, but just, like, that seems to be certainly one path into it.

+ +

I think for smaller customers, or maybe customers that are more, say, cloud-native, I think it can generally be a mix of either hitting a point where they're kind of done with the overhead of trying to maintain their own infrastructure of, like, trying to run their own ELK stack and, like, build all the tooling on top of that, and keeping that up and running, and the costs associated with that. Or, it's potentially seeing the sophistication of tooling that, like, a dedicated provider can afford to invest that realistically, you're never going to invest in on your own, right? Like, stuff like live profiling is deeply non-trivial to implement. [laughs]

+ +

I think especially once people get some experience with a product like Datadog, they start thinking about, like, okay, how much value are we actually getting out of doing this on our own versus using a more off-the-shelf product? I don't know if we've been doing it post-COVID. But I remember pre-COVID...so Datadog has a huge presence at re:Invent and the other similar major cloud provider things.

+ +

And I remember for a few years at re:Invent, you know, we obviously had, like, the giant 60x60 booth in the main expo floor, where we were giving demos and whatnot. But they also would have...AWS would do this, like, I think they call it the interactive hall where companies could have, like, more hands-on booths, and you had, like, a whole spectrum of stuff. And there were, like, some companies just had, like, random, like, RC car setups or Lego tables, just stuff like that.

+ +

But we actually did a setup where there was a booth of, I think, like, six stations. People would step up, and they would race each other to solve a kind of faux incident using Datadog. The person who would solve it first would win a switch. I think we gave away a huge number of switches as part of that, which at first I was like, wow, that seems expensive. [laughs]

+ +

But then later, you know, I was mostly working the main booth at that re:Invent. So by the, like, Wednesday and Thursday of re:Invent, I'd have people walking up to the main booth being like, "Hey, so I did the thing over at the Aria. And now I installed Datadog in prod last night, and I have questions." I was like, oh, okay. [laughs] So, I think just, like, the power of, like, getting that hands-on time, and using some of the tools, and understanding the difference there is what kind of gets a lot of people to kind of change their mind there. [laughs]

+ +

VICTORIA: You'd get me with a switch right now. I kind of want one, but I don't want to buy one.

+ +

SEAN: [laughs]

+ +

WILL: Same. [laughs]

+ +

VICTORIA: Because I know it'll take up all my time.

+ +

SEAN: Uh-huh. That's fair. [laughs]

+ +

VICTORIA: But I will try to win one at a conference for sure. I think that's true. And it makes sense that because your product is often going with clients that don't have these practices yet, that as soon as you give them exposure to it, you see what you can do with it, that becomes a very powerful selling tool. Like, this is the value of the product, right? [laughs]

+ +

SEAN: Yeah, there is also something we see, and I think most of our kind of peers in the industry see is, very often, people come in initially looking for and using a single product, like, you know, infrastructure, metrics, or logs. And then, as they see that and see where that touches other parts of the product, their usage kind of grows and expands over time. I would obviously defer to our earnings calls for exact numbers. But generally speaking, more or less kind of half of our new business is usually expanded usage from existing customers as opposed to new customers coming in. So, I think there's also a lot of just kind of organic discovery and building of trust over time that happens there, which is interesting.

+ +

VICTORIA: One of my favorite points to make, which is that SRE sounds very technical and, like, this really extreme thing. But to make it sound a little more easier, is that it is how you validate that the user experience is what you expect it to be. [laughs] I wonder if you have any other thoughts you want to add to that, just about, like, SRE and user experience and how that all connects for real business value.

+ +

SEAN: I think a lot of places where, you know, we've both seen internally ourselves and with customers is, you know; obviously, different companies operate in different models and whatnot. Where people have seen success is where, you know, people with formal SRE titles or team names can kind of be coming in as just kind of another perspective on the various kind of things that teams are trying to drive towards.

+ +

The places reliability is successfully integrated is when they can kind of make that connection that you were talking about. It's, like, obviously, everybody should go take their vitamins, but, like, what actual value is coming from this, right? Nobody wants to have outages, but, like, to do the work to invest in reliability, often, like, it can be hard to say, like, okay, what's the actual difference between before and after? Having people who can help draw those connections and help weigh those trade-offs, I think, can definitely be super helpful.

+ +

But it is generally much more effective, I think, in my experience, when it does come from that perspective of, like, what value are we providing? What are we trading off as part of this? As opposed to just, well, you should do this because it's the right thing to do, kind of a moralistic perspective. [laughs] But, I don't know, how do you all kind of end up having that conversation with your customers and clients?

+ +

VICTORIA: That's exactly it. That's the same. It's starting that conversation about, like, well, what happens when this experience fails, which designers don't necessarily think about? What's, like, the most important paths that you want a user to take through your application that we want to make sure works?

+ +

And when you tie it all back there, I think then when the developers are understanding how to create those metrics and how to understand user behavior, that's when it becomes really powerful so that they're getting the feedback they need to do the right code, and to make the right changes. Versus just going purely on interviews [laughs] and not necessarily, like, understanding behavior within the app. I think that starts to make it clear.

+ +

SEAN: Part of that, I think that's been an interesting experience for us is also just some of the conversation there around, like, almost the flip side of, when are you investing potentially too much in that, right? Because, like, especially after a certain point, the cost of additional gains grows exponentially, right? Each one of those nines gets more and more expensive. [laughs]

+ +

And so, having the conversation of, like, do you actually need that level of reliability, or, like, is that...just like what you're saying. Like, you know, kind of giving some of that context and that pressure of, like, yeah, we can do that, but, like, this is what it's going to cost. Is that what you want to be spending your money on? Kind of things can also be an interesting part of that conversation.

+ +

VICTORIA: That's a really good point that, you know, you can set goals that are too high [laughs] and not necessary. So, it does take a lot of just understanding about your data and your users to know what are acceptable levels of error.

+ +

I think the other thing that you can think about, too, like, what could happen, and we've seen it happen with some startups, is that, like, something within the app is deeply broken, but you don't know. And you just think that you're not having user engagement, or that users are signing off, or, like, you know, not opening the app after the first day.

+ +

So, if you don't have any way to really actively monitor it and you're not spending money on an active development team, you can have some method to just be confident that the app is working and to make your life less miserable [laughs] when you have a smaller team supporting, especially if you're trying to really minimize your overhead for running an application.

+ +

SEAN: Yep. It's surprisingly hard to know when things are broken sometimes. [laughs]

+ +

VICTORIA: Yes, and then extremely painful when you find out later [laughs] because that's when it's become a real problem, yeah. I wonder, are there any other questions you have for me or for Will?

+ +

SEAN: How big of an organization is thoughtbot at this time?

+ +

VICTORIA: Close to 75 people? We're, yeah, between the Americas and the [inaudible 38:31] region. So, that's where we're at right now, yeah.

+ +

SEAN: Nice. At that size, like, and I guess it sounds like you're pretty heavily distributed, so maybe some of this doesn't happen as much, but, like, one of the things I definitely remember...so, when I joined Datadog, it was probably about 500 people. And I think we're just under 5,000 now. There are definitely some points where there were surprisingly, like, physical aspects to where it became a problem of just, like, where certain teams didn't fit into a room anymore. [laughs] Like, I had surprise in the changes in that, like, dynamic. I'm curious if you've all kind of run into any kind of, I don't know, similar interesting thresholds or changes as you've kind of grown and evolved.

+ +

WILL: I will say this, we're about 100, I think, Victoria.

+ +

VICTORIA: Oh, okay, we're 100 people. I think, you know, I've only been at thoughtbot for just over a year now. And my understanding of the history is that when we were growing before COVID, there's always been a very intentionality about growth. And there was never a goal to get to a huge size or to really grow beyond just, like, a steady, profitable growth. [laughs]

+ +

So, when we were growing in person, there were new offices being stood up. So, we, you know, maybe started out of New York and Boston and grew to London. And then, there was Texas, and I think a few other ones that started. Then with COVID, the decision was made to go fully remote, and I think that's opened up a lot of opportunities for us. And from my understanding in the previous and the past, is that there's a big shift to be fully remote.

+ +

It's been challenging, where I think a lot of people miss some of the in-person days, and I'm sure it's definitely lonely working remote all day by yourself. So, you have to really proactively find opportunities to see other people and to engage remotely. But I think also, we hire people from so many different places and so much different talent, and then, also, you know, better informs our products and creates a different, you know, energy within the company that I think is really fun and really exciting for us now.

+ +

WILL: Yeah, I would agree with that because I think the team that I'm on has about 26 people on the Lift Off team. And we're constantly thinking of new ways to get everyone involved. But as a developer, me myself being remote, I love talking to people. So, I try to be proactive and, like, connect with the people I'm working with and say, "Hey, how can I help you with this?" Let's jump in this room and just work together, chat together, and stuff like that, so...

+ +

And it has opened the door because the current project that I'm on, I would never have had an opportunity to be on. I think it's based in Utah, and I'm in South Florida. So, there's just no way if we weren't remote that I'd been a part of it. So...

+ +

SEAN: Nice. And I can definitely appreciate that. I remember when we first started COVID lockdown; I think, at that point, Datadog was probably about...Datadog engineering was probably about 30% remote, so certainly a significant remote contingent but mixed. But my teams were pretty remote-heavy. So, in some ways, not a lot changed, right? Like, I think more people on my team were, like, who are all these other people in my house now instead of [laughs], I mean, just transition from being in an office to working from home.

+ +

But I do remember maybe, like, about six months in, starting to feel, yeah, some of the loneliness and the separation of just, like, not being able to do, like, quarterly team meetups or stuff like that. So, it's definitely been an interesting transition. For context, at this point, we kind of have a hybrid setup. So, we still have a significant kind of full-time remote contingent, and then four people who are in office locations, people joining for about three days a week in office. So, it's definitely an interesting transition and an interesting new world. [laughs]

+ +

VICTORIA: Yeah. And I'm curious how you find the tech scene in Denver versus New York or if you're engaging in the community in the same way since you moved.

+ +

SEAN: There definitely is some weirdness since COVID started [laughs] broadly [inaudible 42:21]. So, I moved here in 2020. But I'd been coming out here a lot before that. I helped to build an office here with Bitly. So, I was probably coming out once a quarter for a bunch of years. So, one parallel that is finally similar is, like, in both places, it is a small world. It doesn't take that long for you to be in that community, in either of those communities and start running into the same people in different places. So, that's always been [inaudible 42:42] and especially in New York. New York is a city of what? 8, 9 million people?

+ +

But once you're working in New York tech for a few years and you go into some meetups, you start running into the same people, and you have one or two degrees [inaudible 42:52] to a lot of people, surprisingly quickly. [laughs] So, that's similar. But Denver probably is interesting in that it's definitely transplant-heavy. I think Denver tends to check the box for, like, it was part of why Bitly opened an office here and, to a degree, Datadog as well.

+ +

I think of like, you know, if you're trying to recruit people and you previously were mostly recruiting in, like, New York or Silicon Valley; if you're based in New York, and you're trying to recruit somebody from Silicon Valley, and part of why they're looking for a new gig is they're burned out on Silicon Valley, asking them to move to New York probably isn't all that attractive. [laughs] But Denver is different enough in that in terms of kind of being a smaller city, easier access to nature, a bunch of that kind of stuff, that a lot of times we were able to attract talent that was a much more appealing prospect. [laughs]

+ +

You'll see an interesting mix of industries here. One of the bigger things here is there's a very large government and DOD presence here. I remember I went to DevOps Days Rockies, I think, a few years ago. There was a Birds of a Feather session on trying to apply DevOps principles in air-gapped networks. That was a very interesting conversation. [laughs]

+ +

VICTORIA: That's interesting. I would not have thought Colorado would be a big hub for federal technology. But there you go, it's everywhere.

+ +

WILL: Yeah.

+ +

SEAN: Denver metro, I think, is actually the largest presence of federal offices outside of the D.C. metro.

+ +

VICTORIA: That's interesting. Yeah, I'm used to trying to recruit people into D.C., and so, it's definitely not the good weather, [laughs], not a good argument in my favor. So, I just wanted to give you a final chance. Anything else you'd like to promote, Sean?

+ +

SEAN: Generally, not super active on social things these days, but you can find whatever I have done at seanoc.com, S-E–A-N-O-C.com for the spelling. And otherwise, if you're interested in some engineering content and hearing about some of those kind of bleeding edge challenges that I was mentioning before, I would definitely check out the Datadog engineering blog. There's lots of kind of really interesting content there on both, you know, things we've learned from incidents and interesting projects that we're working on. There's all kinds of fun stuff there.

+ +

VICTORIA: That makes me think I should have asked you more questions, Sean. [laughs] No, I think it was great. Thank you so much for joining us today. I'll definitely check all that stuff out.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Sean O'Connor.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+70Kkasc3 + + ]]> + + Will Larry + Victoria Guido + Sean O'Connor + + + 489: CTO Lunches with Kendall Miller + https://podcast.thoughtbot.com/489 + b1f3c63e-d52b-4014-894f-29b7d640e653 + Thu, 24 Aug 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Kendall Miller is the Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. + +From technical insights to business considerations and community engagement, the conversation provides a comprehensive look at Kubernetes and talks about CTO Lunches, a community for CTOs and senior engineering leaders, and a focus on building connections within the tech industry. + 38:17 + no + + + Kendall Miller is the Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. +The first half of the conversation with host Victoria Guido and special guest host, Joe Ferris, CTO of thoughtbot revolves around the use, adoption, and growth of Kubernetes within the technology industry. The discussion explores Kubernetes' history, influence, and its comparison with other platforms like Heroku and WordPress, emphasizing its adaptability and potential. +The second half focuses on more practical aspects of Kubernetes, including its adoption and scalability. It centers on the appropriateness of adopting Kubernetes for different projects and how it can future-proof infrastructure. The importance of translating technical language into business speak is emphasized to influence executives and others in the decision-making process and Kendall also discuss communication and empathy in tech, particularly the skill of framing questions and understanding others' emotional states. +__ +CTO Lunches (http://ctolunches.com/) +Follow CTO Lunches on LinkedIn (https://www.linkedin.com/company/ctolunches/) or Twitter (https://twitter.com/cto_lunches). +Follow Kendall Miller on LinkedIn (https://www.linkedin.com/in/kendallamiller/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Kendall Miller, Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. Kendall, thank you for joining me. +KENDALL: Thanks for having me. I'm excited. +VICTORIA: And today, we have a special guest host, Joe Ferris, CTO of thoughtbot. Joe, thank you for joining us. +JOE: Hello there. Thank you for having me. +KENDALL: Hi, Joe. Thanks for being here. It's exciting. +VICTORIA: Yes. It's so exciting. I think this is going to be a great episode. So, Kendall, I met you at a San Diego CTO lunch recently, and I know that's not the only thing that you do. So, you're also an advisor, a board member, and CXO. So, maybe tell us a little bit more about your background. +KENDALL: Gosh, my background is complicated. I've been involved in tech for a very long time. In college, I worked for a company that started Twitter about five years too soon, and then worked in the nonprofit space in China for ten years, then came back, got back involved in tech. +Today, I'm usually the business guy. So, when technical founders start technical products and want help turning them into successful technical businesses, that's when they call me. So, I have the technical background. I have never been paid to write code, which is probably a good thing. But I can hang in the technical conversations for the most part, but I'm much more interested in the business side and the people leadership side of business. So that tends to be where I play. Every organization hires me to do something different. +VICTORIA: Thank you for that. And I'm just curious about the CTO Lunches. Just tell me a little bit more about that. And what's the idea behind it that led you to co-found it? +KENDALL: CTO Lunches has actually been around for about eight years. And I didn't start the initial incarnation of it. It was two people that got us started, and I was trying to hire one of them; one thing led to another. Actually, originally, they did not want me to join. I think, at the time, my title was COO at a company that I was working with. +About six months later, I took over engineering as VP of engineering, and then they're like, you can join the group now. We're less strict about that [laughs] now. Although it is highly focused on senior engineering leaders, it's not exclusively CTOs. But the group's been in place for a very long time, just intended as a place to network, have conversation with people who are in that senior-most technical position at technical organization. +So, the CTO role is a lonely role. CTOs get fired all the time. There's not a technical person at the company that doesn't think they can do the job better than them. So, the CTO is always getting feedback. You're doing this wrong. The trade-offs you're making are wrong. This isn't going where it should be going. We should automate that. Why haven't we automated that? We should switch to this other tool. I've used it before; it's 100 times better. Joe, let me know if I'm getting any of this wrong. But that's the experience that I've had. +Having a place where people can get together and, you know, half the time just complain to each other, hey, this is hard, is really why the networking group exists. So, it's a listserv. And there are local lunches that started in Boulder, Colorado. It's gotten pretty global. +About a year ago, a little over a year ago, I was talking with one of the people who'd gotten it started. I've been involved in the Denver chapter for most of those eight years. And I was suggesting to him that he change a few things about it, to monetize it so that he could invest in it further. And he came back a few months later and said, "I want to take your advice and do this, but I want you to come do it with me." +So, we founded the company officially...I think in December is when paperwork went into place. And we started investing in it a little bit more heavily. I was living in Europe last year, so we went and put on lunches in Paris, and Lisbon, and London, and, gosh, all over the place. I'm sure I'm missing some, Amsterdam. But there's been chapters all over the U.S. and a couple of other parts of the world for a long time. +VICTORIA: That reflects my experience attending a CTO lunch. It's just very casual, like, just get together and eat food and talk about what you've worked on recently, issues you're having, just get ideas and make some friends. So, I really appreciated the group, and I'm going to personally plug the San Diego Chapter has picked up again. And we're meeting next Friday down in Del Mar. And we're going to be meeting on the last Friday of every month through October. So, I'm super excited to be a part of the group. +And Joe, yeah, I'm curious about your perspective. As a CTO with thoughtbot, just what are your thoughts about that kind of thing? +KENDALL: Yeah. How right am I about how lonely you are, Joe? +JOE: [laughs] You know, I've been lonelier since we went remote. I used to work in the office, and I was a CTO, but also, I had lunch with people, which was nice. So, I'm lonelier. But yeah, I think everybody needs a group like that, like, senior developer therapy just to talk about your woes together, drown your sorrows. +KENDALL: Well, I think years ago, I heard that CTOs are the most fired C-level executive. +JOE: You're making me nervous now. +KENDALL: [laughs] You've been there a long time, Joe. I know you've been there a long time. If you haven't been fired yet, you probably got a little while longer in you. This will be really awkward if it's published and you've already been fired. +VICTORIA: We can always edit that out afterwards. +[laughter] +KENDALL: Yeah, no, I think it is a particularly lonely position. And, again, I think a lot of it is the average engineer in a technical company doesn't look at the COO or the CFO or even the CEO and think I could do that. But they're all looking at the CTO and thinking, what does that person do that I can't do? +It's ridiculous because most of them would make terrible CTOs because it does require some of the business sense. Or, you know, right out of the gate, they might make terrible CTOs. It actually is quite a skill to be the most technical person and speak the business language. I mean, am I right about that, Joe? Like, was that hard for you to learn? +JOE: Yeah, I definitely think...so, my background is also technical. I have a background in consulting. So, I always did a lot of metaprogramming, if you will. But making that transition to thinking about organizations that way, thinking about how all the other pieces play into it, was a pretty big step for me, even before I became a CTO as a consultant. +KENDALL: Well, because you can't just chase the newest, hottest technology. You have to make business trade-offs. And not everything can be resume-driven development, right? Even if that technology over there is newer or hotter, it doesn't mean you have a business model that supports it. And it doesn't mean that migrating to it can be done, right? +JOE: Yeah. I mean, even beyond choosing technologies, just choosing where to invest in your software stack, like, what needs to be reworked, what doesn't, and trying to explain those trade-offs, I think, is a rare skill. Being able to explain why something would be harder than something else when you're working with the leadership to prioritize a backlog it's a puzzle. +KENDALL: Well, and I think when I'm in an executive conversation, and the CTO says, "Here's the thing that I think is the best decision technically, and I think it's the wrong decision for the business because of X, Y, or Z," I'm always super impressed, right? Like, this is the right technical solution for what we want. However, we shouldn't pursue that for business reasons right now. Maybe we can in six months, but right now, we need to prioritize this other thing. I don't know, that's always when I feel like, oh, this person knows what they're doing. +JOE: There's nothing more dangerous to software than a bored developer. [laughs] One nice thing about being a consultant is that I don't have to invent problems to solve with technology at my company because sooner or later, I'll run across a company that has those problems, and I'll get to use that technology. +But I think a lot of people are mostly happy...they might be happy in their role. They might be happy with our team. But they're very interested in whatever is hot right now, like machine learning, AI. And so, suddenly, that surreptitiously makes its way into the tech stack. And then, years later, it's somebody's problem to maintain. +KENDALL: [laughs] Well, I have a specific memory of a firm in New York City that was, you know, this is relevant to y'all as thoughtbot is that, you know, at least historically, it was, to me, the premier Ruby on Rails consulting shop. I think that's still largely y'alls focus. Am I right about that? +JOE: We still do a ton of Rails, yeah. +KENDALL: Okay. Well, so this organization was all Ruby on Rails. It was a big organization. They had a very large customer base. And they hired a new CTO who came in, told everybody in the company they were stupid, laid off 70% of the engineering organization, and told the CEO he was going to completely rewrite the product from scratch in .NET, and he could do it in three weeks. And I'm pretty sure the business went under about three months later [laughs] because that was just so outrageously nuts to me. +JOE: It's too bad he laid everybody off beforehand. I've been in that situation where somebody tells me, "I'm going to rewrite this. It'll be ready in three weeks." And I could fight with them and try and convince them they're wrong. But I feel like somebody who's approaching that with that attitude they're missing all of the nuance and context that would make it possible to explain to them why it's not going to work. And so, it's easier to just say, "You know, take the three weeks. I'll talk to you in three weeks." But if you've already laid off your development team, that's hard [laughs] to recover from. +KENDALL: That's exactly right. +VICTORIA: There's got to be a name for that kind of CTO who just wants to come in and blow everything up [laughs]. Yeah, so you spend a lot of time talking to different CTOs and doing this social networking aspect. I'm wondering if there's, like, patterns that you see. You've mentioned already one about just, like, the most often getting fired. [laughs] But what are the patterns you see, like, in challenges, and then what makes someone successful in that CTO role? +KENDALL: Well, oh gosh, I have so many thoughts about this. First of all, I run into a couple of different categories of CTOs. There's a lot of people who come to CTO Lunches who are small company CTOs. I mean, it makes sense that there's a lot more small company CTOs than there are big company CTOs. But the small company CTO who maybe it's their first gig in the role or they're a serial CTO. There's the fractional CTOs that come that are doing it across several different organizations at the same time, and then there's the big company CTO who shows up. And honestly, all of their problems are very different. +The thing that they have in common is even at a very large organization, in that position, they can make a decision that causes the company to go under. So, there is a significant amount of volatility in the amount of power that they wield. So, what's interesting about that is not everybody understands that. +And so, first of all, there's the kind of CTO that just doesn't get that, and that doesn't matter if they're fractional, or a small company CTO, or a big company CTO. If they don't understand that, they're going to cause significant problems, right? Like the person I just mentioned who said, "I can just re-platform this in three weeks in .NET." There's that. +I mean, I think, as with any senior leadership position, the comfort with volatility, the ability to know what to communicate down versus across and versus up, and then the ability to speak the business language. For everybody, the CFO's job is to communicate the financial needs alongside of the business leads, right? +If the CFO's sole goal is to cut costs or make sure we're running as lean as possible, they're a bad CFO. But they're not as good of a CFO as the CFO who can say, "Hey, we're underspending right here. And I can look at the numbers and know we should invest more there. How can we invest more there and invest it well?" And it's the same thing for a technology executive to be able to look at the business context and communicate it back. +And there are so many CTOs that I've worked with who they're the most technical person in the room, and they know it. And as a result, they're just a jerk to everyone around them, like, everything you did here was wrong. You know, that's where they fail. And so, if they can communicate the business needs, navigate the volatility, and support a team that's going to make decisions that aren't always the same decision they're going to make, they're going to be successful. Honestly, there's very, very few CTOs that I've met like that. People who are excited to meet you at work, excited to see you succeed, excited to see that you went and built a thing is great. +I mean, the reason I was VP of engineering is the CTO that I was working with at the time...it's a terrible story. There was an engineer who had seen something that we were doing on repeat all the time and, in his spare time, spent about 40 hours outside of work, not during work hours, automating this task that we were doing regularly. And it was related to standing up a whole bunch of things in our standard infrastructure. +He brings it to the CTO and says, "Look what I built." And the CTO, instead of saying, "Hey, this is incredible. Thank you. This is going to save us a bunch of time. Let's iterate on it. Here's some things I'd like to tweak. Can we bring it in this direction? Can we..." you know, whatever, said, "Why is this in Python? It should be in Ansible," something like that. I can't remember. And the engineer literally burst into tears. [laughs] +JOE: Oh my God. +KENDALL: [laughs] Well, I mean, yeah, it was like; literally, that's why the CTO stopped managing people that day. There's a lot of examples that I have like that. Joe, I appreciate that your response is, "Oh my God." Because I think there's a lot of people who'd be like, wait, what was wrong with that? Shouldn't it have been in Ansible? +JOE: [laughs] Yeah, I've seen CTOs come into primarily two groups. One is the CTO who just tells, you know, like, they make the decisions, and they tell everybody what to do. They obviously don't have all of the information because you can't be in every room all the time. And the other is the CTO, who just wants to be one of the team members and doesn't make any decisions and tries to get people to make decisions collectively on their own without any particular guidance or structure. And finding that middle spot of, like, not just saying, "Hey, everything's in Ansible," allowing for the creativity and initiative, but also coalescing the group into a single direction, I think, is what makes a good CTO. +KENDALL: Well, yeah, because the CTO does have to say no, sometimes, right? Like, the best product, people say, "No." Good CTOs say, "No." There is some amount of, hey, I need you to come to me with trade-offs about this. Why are you going to make that decision? And I'm sorry, you still didn't convince me, right? Like, I mean, those are appropriate things to say. But yeah, I'm with you on that. You said they fall into two categories. But you really mean the third and that middle ground. Is it easy for you to walk that middle ground, Joe? +JOE: I wouldn't say it's easy. [laughs] +KENDALL: Yeah. Well, I'm always nervous to say something. I'm doing well because I know there's a report out there that can point at every time I failed at it, right? So... +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +VICTORIA: Yeah, what I'm getting from what you're saying, too, is this communication ability and not just, like, to communicate clearly but with a high level of empathy. So, if you say like, "Well, why is it in Python and not Ansible?" is different than being like, "What makes Python the best solution here?" Like, it's a different way to frame the question that could put someone on the defensive that just really requires, like, a high level of emotional intelligence. +And also, if they've just worked, like, an 80-hour week, [laughs] I probably would maybe choose a different time to bring those questions up and notice that they have been burning the candle at both ends and prioritize getting them some rest. So, speaking of, like, communication and getting prioritization for [inaudible 15:34], especially on, like, infrastructure teams, maybe we could talk a little bit about Kubernetes, like, when that comes up as an appropriate solution, and how you talk about it with the business. +KENDALL: My background with Kubernetes is long because a company that I still work with, Fairwinds, used to be called ReactiveOps, has been in the Kubernetes space for a very long time. I think we were one of the very first companies working with Kubernetes. It was coming up that people were running into the limits of something like Heroku, right? And I think it's Kelsey Hightower who said every company wants a PaaS. They just want the Paas that they built themselves. And that's really accurate. +And I think Kubernetes isn't quite a framework for building your own PaaS or isn't quite a foundation where I think of a foundation for a house. Instead, it's more like rebar and cement and somebody saying, "Good luck, buddy." You know, you still have to know how to put the rebar and cement together to even make the foundation, but it is the building blocks that help get you to a custom-built PaaS. And it's become something that a lot of people have landed on as, you know, the broadly accepted way to build cloud-native infrastructure. +The reason I've been in the Kubernetes space and the space that I see Kubernetes still filling is we need to standardize on something. We can choose a cloud provider's PaaS. We can choose a third-party PaaS, or we can standardize on something like Kubernetes. And even though we're not going to migrate from AWS to Azure, the flexibility that Kubernetes gives us as a broadly adopted pattern is going to give us some ability to be future-proofed in our infrastructure in a way that previous stacks were not, you know, it was Puppet, and it was Ansible. And it was SaltStack. And it was all Terraform all the time. +I'm not saying those things don't exist anymore. I'm saying Kubernetes kind of has won that battle. Joe, since you're here and I know y'all are doing some Kubernetes work now at thoughtbot, I'm curious if you agree with that characterization. +JOE: Yeah, I think that's true. I think it's the center for people to coalesce around. Like, for an effort in the industry to move forward, there needs to be some common language, some common ground. And I think Kubernetes struck the right balance of being abstract. So, you can use it in different environments but still making some decisions, so you don't have to make them all. +And so, like, all of the things you had to do with containers like figuring out what your data solution is going to be, what your networking solution is going to be, Kubernetes didn't even really make those decisions. [laughs] They just made a platform where those decisions can be made in a common way. And that allowed the community and the ecosystem to grow. +KENDALL: I mean, I think of it a lot like WordPress; you know, WordPress is hated by many. When WordPress came out, it was hot, right? And it was PHP, which everybody was super excited about at the time. Kubernetes is going to reach a point where it's as long in the tooth and terrible as people think WordPress is, but it has become the standard. And the advantage of the standard is you can use the not standard. You can go build a website in Jekyll instead of WordPress, and there's going to be some things that are nicer about Jekyll. +But because WordPress is so broadly adopted, there's a plugin for everything. And I think that's where Kubernetes sits is because it's become so widely adopted everybody's building for it. Everybody's adapting for it. If you run into a problem, you're going to find somebody else out there who has that problem. +In fact, I think of one organization that I know that was on HashiCorp's Nomad. And they said, "Actually, we think Nomad has better technology through and through. But we think we're the only company at this size and scale using Nomad. And so, when we run into a problem, we can't Google for it. There's no such thing as a plugin that exists to solve this. Nobody has ever run into this before on Nomad. But there's 100 companies dealing with the same problem in Kubernetes, and there's ten solutions." And I think that's the power that it brings. +VICTORIA: So, it's not just a trend that CTOs are moving towards, you think. +KENDALL: I mean, I think it's already won the battle and the hockey stick of adoption. We're still right at the very bottom of that tick-up because it takes people a long time to adapt new technology like this, especially in their infrastructure. It's a big migration, to move. So, I don't think it's the widely adopted infrastructure technology even yet. I think a lot of the biggest organizations are still running on things that predate Kubernetes. But I think it has won the battle, and it is winning the battle and is going to be the thing going forward, so yeah. +JOE: I think it also has a lot of room to grow still. Like, there are other technologies that I used previously, like Docker, and they were a big step up from some of the things I was doing at the time. But you quickly hit the ceiling, or it was, like, I don't know where to go with this next. I don't know what else is going to happen. +Whereas with Kubernetes, there are so many directions it can go in. Like, the serverless Kubernetes offerings that are starting to pop up are extremely interesting, where, you know, you don't actually maintain a cluster or anything. You just deploy things to this ethereal cluster that always exists. And so, that sort of combination of platform as a service, function as a service, Kubernetes, as that evolves, I think there are a lot of exciting things that have yet to come in the Kubernetes space. +KENDALL: Well, so say more about that, Joe, because I've been going to KubeCon for a very long time, maybe...I don't know if it's 2016 or so when I first went. And it felt for a number of years...maybe those first four-ish years it was always the people at KubeCon were the, like, big dreamers and thinkers and, like, we're here to change the future of cloud infrastructure. And this is going places, and we're excited to be here and be a part of it. And here's what I'm going to do that changes the next thing. +And I feel like now if I go to KubeCon, it's a lot of people from, you know, IBM and some big bank that are, like, deep sigh, well, I have to adopt Kubernetes. I need to know what the vendors are. What do you guys do, and how does this work? Can you please teach it to me? Because I'm being told by my boss, I have to do it. +I don't see that excitement around Kubernetes anymore. The excitement I see is all around further up the stack, you know, things like Wasm, WebAssembly, or eBPF, the networking things and tracing things that are possible. Maybe that's further down the stack. I guess it depends on how you think about it, but different part of the stack. So, I'm curious, touching on the serverless components of Kubernetes; sure, I get that. And I do think, increasingly, the PaaSs of the future are all going to be Kubernetes-based, whether that's exposed or not. +But where are the places that you think it's still going to go? Because I feel like it's already gotten boring, maybe in a positive way. But I don't see the excitement around it like I saw a few years back. And I'm curious what else you think is going to happen. +JOE: Yeah, I mean, I don't think I disagree. I think Kubernetes itself, the core concept, is, like, it's still changing. But you're right that the excitement about Kubernetes existing has gone down because it's been there for a while. But I feel like the ecosystem is still growing pretty rapidly. Like, the things you mentioned, like Wasm and Istio, and all the tools in that ecosystem that continue to grow, is where I think the interesting things will happen. Like, it's created this new lower-level layer of abstraction that makes it possible to build concepts and technology that could not have existed before. +KENDALL: Yeah, well, and I'm, you know, talking to people who are working really hard at making short-run ephemeral workloads work better on things like GPUs for the sake of AI, right? Like, I mean, there is some really interesting things happening, and people are doing this in Kubernetes. So, I get that. I agree with that. +It is interesting that Kubernetes has become sort of the stable thing, and now it's about who can build the interesting add-ons. It's almost like, okay, we've built Half-Life. What is Counter-Strike going to look like? You know. That's a terrible (I'm aging myself.) example. But still. +VICTORIA: I think it's interesting, I mean, to look at the size of the market for platform engineering right now. In 2022, was 4.8 billion, and it's estimated to be in 10 years $41 billion. So, there is this emerging trend of different platform engineering products, different abstractions on top of Kubernetes. And I wonder what advice you would have for a technical founder who's looking to build and solve some of these interesting issues in Kubernetes and create a business around it. +KENDALL: Well, okay, let me clarify that question. Are you thinking, I'm a startup, and I need to build my infrastructure, and I'm going to choose Kubernetes. What advice do I need? Or are you thinking, I am founder, and I want to go build on the Kubernetes ecosystem. What advice do you have? +VICTORIA: Now I want to know the answer to both. But my question was the second one to start. +KENDALL: One of the things that is hard about the Kubernetes ecosystem is there's not a ton of companies that have made a whole bunch of money in Kubernetes because, as I said, I still think we're actually really early in the adoption curve. +The kinds of companies that have adopted Kubernetes are the kinds of companies that don't spend lots and lots of money on an infrastructure. [laughs] They're the kinds of companies that are fast-moving, early adopters, or, you know, those first followers, and so they're under $100 million companies for the most part. Where the JP Morgans and Chase are running Kubernetes somewhere in their stack, but they haven't adopted it across the stack to need the biggest, best tools about it. +So, the first piece of advice that I'd give is, be a little wary. It's still very early to the market. Maybe now is the time to build the thing. When ReactiveOps pivoted to Kubernetes, I think it was six months of having conversations with companies who were just, like, so excited about it, and this is definitely what we want to do. But nobody was doing it yet. You know, it was, we have, like, six solid months of just excitement and nobody actually pulling the trigger. And, you know, we were a little too early to that market. And that was just the people adopting it. +So, I think there is some nervousness that cloud-native solutions the only people who are really making money in Kubernetes are named Amazon, Google, and Microsoft because it's the cloud providers that are making a ton off of it. Now, there's Rancher. There is StackPointCloud. There's a few others that have had big exits in this space. But I don't think it's actually as big of a booming economy as a lot of people think, in part because EKS is an incredibly amazing product. +Like, eight years ago, the thing people paid us the most to do at ReactiveOps was just stand up Kubernetes because it was so stinking hard to just get it up and working. And now you click some buttons. Anybody can go do that. So, it's changed a lot, right? And I think be wary when you're entering that ecosystem. +And then, my advice to the founder that's not building on the ecosystem but just looking to adopt a technology that's going to be a future-proofed infrastructure is just adopt one of the cloud-native platforms. And there are a whole bunch of sort of default best-in-class add-ons out there that you need to throw in. Don't adopt too many because then you have to maintain them forever. That's the easiest way to get started. You can figure out all the rest of it later. But if you go use EKS, or GKE, AKS, you can get started pretty easily and build something that is going to be future-proofed. I don't know, Joe; I'm curious if you disagree with any of that. +JOE: Well, I think it's interesting to think about who's making money in Kubernetes. Like, I think there might not be as many companies who are doing only Kubernetes and Kubernetes-focused products that are massively successful. But I think because it has had a good amount of adoption and because it's easier to work with something that's standardized, it has helped companies sell things that they wanted to sell anyway. Like, all the Datadog, all the Scalas, the logging companies, they all have Kubernetes add-ons. +And now everybody is paying Datadog [laughs] to have a dashboard for their Kubernetes cluster. I think they're making more money than they would have been without targeting the market. And so, I think that's really...if you want to get into the market, it's not, like, I'm going to build a Kubernetes product. It's if I'm building operations and an infrastructure product, I should definitely have it work with Kubernetes, and people will want to click and install it. +KENDALL: So, to be clear, you know, one of the companies that I work with is called Axiom, and they play in the same, you know, monitoring, observability space as Datadog does. And part of what makes Kubernetes interesting in that space is in a microservice environment; there's so much happening. Where are problems being caused? We don't live in a day where I can just run my code, and it tells me that there's an unexpected semicolon on line 23, right? Like, that still happens. You're still doing those things. +But this microservice talking to that microservice is where things tend to break down. Did I communicate this correctly? What was sent? What was received? Where did it break down? What was the latency? And if you were doing things in the old way back when you were standing it up with, say, Ansible, or Puppet, or something like that, and you were orchestrating all of these cloud virtual machines, you had to really work hard to instrument the tracing and logging and everything involved in order to track what was going on. +Whereas that's one of the magic things about Kubernetes is with a few of the add-ons or some of the things out of the box with Kubernetes, it's a couple of clicks to get so, so much of the data and have insight into where things are going and what's going wrong. And so, I 100% agree with that. +Kubernetes is generating a tremendous amount of data. And if you're a data company, it's really nice to have all that come in, and it helps them make money, helps the user of Kubernetes in that situation understand where problems are happening and breaking down. Yeah, there's definitely some network effects of what Kubernetes is doing in that. I completely agree. +JOE: I think there are also some interesting companies, like, where they make...Emissary, Ambassador, and they have that sort of dual -- +KENDALL: Komodor, is that -- +JOE: Yeah, maybe. They have open source, but then they have a product. +KENDALL: You're thinking of Ambassador Labs. +JOE: Yeah. Ambassador Labs, yeah. I guess I don't really know how much money they're making. But I think that's a really interesting concept as people who make open-source things then make a well-supported product built around it. +KENDALL: Sure. What's interesting is, I think in the VC world, at least right now, and it may pick up again, but post-Silicon Valley Bank nearly caving in, I think that the VC tolerance for, yeah, just go get a billion open-source adopters, and we'll figure out how to monetize later I think that the tolerance for that is a lot lower than it was even six months ago. +JOE: Yeah, I think you have to have a dual model right from the beginning now. +KENDALL: Yeah. Agreed. +VICTORIA: You got to figure out how to make money on Kubernetes before you can. [laughs] +KENDALL: You know, minor detail. That's why I think services companies in this space still have a lot going for it. Because in order to even be able to sell software to a company using Kubernetes, you half the time have to go stand up Kubernetes for them because it is still that hard for so many people to really adopt it. +VICTORIA: Yeah. And maybe, like, talking more about, like, when it is the right decision to start on Kubernetes because I think the question I get sometimes is just, is it overkill? Is it too much for what we're building? Especially, like, if you're building a brand-new product, you're not even sure if it's going to get adopted that widely. +KENDALL: I mean, and I'm [laughs] curious your thought on this, Joe, but there's a good argument to be made that Heroku was enough for the vast majority of founders early on. But the thing is, Kubernetes isn't as hard as it used to be. Going and clicking a couple of buttons on GKE and deploying something into Kubernetes with GKE Autopilot running it's not as easy as Heroku, but it's not wildly far off. And it does substantially future-proof you. +So, when is it too early? I'm not sure it's ever too early if you have an intention of scaling if you're planning on running some kind of legacy workload, like, things that are going to be stateful. Or maybe WordPress, for example, you don't probably need to deploy your WordPress blog onto Kubernetes. You can do that in your cPanel on Bluehost. I don't actually know if Bluehost even exists anymore, but I assume it's still a thing. I don't know, what would you say, Joe? +JOE: I agree with that. I think it's a hard first pill to swallow. But I think the reality is that it's very easy to underestimate the infrastructure needs of even an early product. Like, it doesn't really matter what you're building. You're still going to have things like secrets management. You're still going to have to worry about networking. They just don't go away. There's no way you have a product without them. +And so, rather than slowly solving all those problems from scratch on a platform that isn't designed for it, I think it's easier to just bite the bullet and use one of the managed solutions, especially, as you said, I think it's getting easier and easier. The activation energy from going from credit card to Kubernetes cluster is just getting lower. +KENDALL: And so, the role of the CTO is just getting easier and easier because they can just adopt the one technology, and it's obviously Kubernetes. And it's obviously Rust, right? [laughter] Yeah, no, I'm with you. And I think if you find somebody who knows Kubernetes inside and out, it's really not going to take them long to get started. +VICTORIA: Yeah, once again, change management is the biggest challenge for any new innovation coming into adoption. So, I'm curious to talk more about the influence that you need and how you influence others to come around to these types of ideas, like, in the executive suite and with the leadership of a company, especially on these types of topics, which can feel maybe a little abstract for people. +KENDALL: How you influence them specifically to use Kubernetes, or just how you talk with them about technology adoption in general? Or what are you asking? +VICTORIA: Yeah, like, how do I get people to not just turn their ears off when I say the word Kubernetes? [laughs] +KENDALL: Yeah, I mean, I think...so I think that's where it's the technologist's job and the role of the CTO to translate these things into business speak. And that's why I'm using words like future-proofing your infrastructure is because there are companies that...I know one company that made a conscious decision that they were going to try to re-platform every single year, and that is not a good idea or sustainable for the vast majority [laughs] of companies. In fact, I can't think of a single situation where that makes sense. +But if you can say to the CFO, "Hey, it's going to cost us a little bit more right now. It's going to save us substantially in the long term because this is the thing that's winning. And if we go standardize on Heroku right now, every company does eventually have to migrate off of Heroku. They either go out of business, or they get too big for it." That's the kind of thing that needs to be communicated in order to get people to adopt it. +They don't care what the word is. They don't care if you're saying Kubernetes; you know, most CFOs understand it about as well as my mom does. My mom tries to bring it up in conversation because she's heard me use it. And she thinks it makes her sound smart, which maybe it does in the right climate. +VICTORIA: My partner does the same thing. He says DevOps and Kubernetes all the time. I'm like; you don't know what you're talking about. [laughter] +JOE: Those words do not come up in my house. +KENDALL: One of my kids asked me to explain Kubernetes. And I do a whole talk, particularly at organizations where understanding Kubernetes is essential to the salespeople's role. And I give a whole talk about the background of how we got here from deploying on some servers in our back room. And, you know, what's different about the cloud, what containerization did, et cetera. And I have this long explanation. And I remember taking a deep breath and saying to my kids, "Do you really want to hear this?" And I had one son say, "Yes, absolutely." And my wife and three of the other kids all stood up and said, "No way," and left the room. +So, when somebody asks me, "What do you do?" Actually, one of the key relationships I built with some of the early people at GCP when we were partnering closely with them was a person that I met, and I asked, "What do you do for a living?" And he said, "I can tell you, but it's not going to mean anything to you." And I was like, "That's what I say to people." And it turned out he was in charge of, you know, Kubernetes partnerships for Google. I can explain to you what it means and why it's important. But you're not going to be happy that I spent that time explaining it to you. +VICTORIA: [laughs] That sounds awesome, though. It sounds like you built a server rack just to demo to your children what it was. +KENDALL: No, no. I just talked back through the history of...that company that I mentioned that built Twitter about five years too early; we had a, you know, we had a server rack in the...literally physically in our closet that was serving up our product at the time. +VICTORIA: Probably the best demo I ever saw was at Google headquarters in Herndon, and someone had built...They had 3D-printed a little mini server rack that they had put Raspberry Pis onto, and then they had Kubernetes deployed on it. And they did an automatic failover of a node to just demo how it works and had little lights that went with it. It was pretty fun. So maybe you should get one for yourself. [laughter] It's a fun project. +KENDALL: They remember the things that it enables. They don't remember what it does. And so, when I say so, and so is a client that's using this technology, then they get real excited because they're like, "My dad makes that work." And I'm like, well, okay, that's kind of a stretch, but you get the idea. +VICTORIA: Yeah, you got to lean into that kind of reputation in your house. +KENDALL: That's right. +VICTORIA: And you're like, yes, that's correct. +KENDALL: That's right. [laughs] +VICTORIA: I do make Kubernetes. I make all the clouds work, yeah. +KENDALL: Actually, my most common explanation is Kubernetes is the plumbing of the internet. Unless you're a plumber, you don't care about the pipes. You just want your shit to flush when you use the toilet. You want the things to load when you click your buttons. You don't actually care what's going on behind the scenes, but this is what's orchestrating it increasingly across the internet. +VICTORIA: So far, we've called Kubernetes WordPress or the toilet. [laughs] +KENDALL: The plumbing. +[laughter] +VICTORIA: You are really good at selling it. +[laughter] +KENDALL: Hey, if you want to build a nice, clean city, you need good plumbing. You might not care what the pipes are made of, but you need good plumbing. [laughs] +VICTORIA: Works for me. On that note -- [laughs] +KENDALL: Yeah. Right? Right? +VICTORIA: That's [inaudible 36:41] on a high note. Is there anything else that you'd like to promote? +KENDALL: With regards to CTO Lunches, we have a free listserv. There are local lunches. If there isn't a local lunch where you are, it's very lightweight to start up a chapter. We often have folks who are willing to sponsor that first lunch to get you going. We do have a paid tier of CTO Lunches. If you want a small back room Slack channel of people to discuss, I think it's $99 a month. +Yeah, if you're a CTO and/or a senior engineering leader and you want a community of people to process with, be it our free tier or our paid tier, we've got something for you. We're trying to invest in this to build community around it. And it's something we enjoy doing more than almost anything. Come take part. +VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Kendall Miller. + + + Kendall Miller is the Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections.

+ +

The first half of the conversation with host Victoria Guido and special guest host, Joe Ferris, CTO of thoughtbot revolves around the use, adoption, and growth of Kubernetes within the technology industry. The discussion explores Kubernetes' history, influence, and its comparison with other platforms like Heroku and WordPress, emphasizing its adaptability and potential.

+ +

The second half focuses on more practical aspects of Kubernetes, including its adoption and scalability. It centers on the appropriateness of adopting Kubernetes for different projects and how it can future-proof infrastructure. The importance of translating technical language into business speak is emphasized to influence executives and others in the decision-making process and Kendall also discuss communication and empathy in tech, particularly the skill of framing questions and understanding others' emotional states.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Kendall Miller, Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. Kendall, thank you for joining me.

+ +

KENDALL: Thanks for having me. I'm excited.

+ +

VICTORIA: And today, we have a special guest host, Joe Ferris, CTO of thoughtbot. Joe, thank you for joining us.

+ +

JOE: Hello there. Thank you for having me.

+ +

KENDALL: Hi, Joe. Thanks for being here. It's exciting.

+ +

VICTORIA: Yes. It's so exciting. I think this is going to be a great episode. So, Kendall, I met you at a San Diego CTO lunch recently, and I know that's not the only thing that you do. So, you're also an advisor, a board member, and CXO. So, maybe tell us a little bit more about your background.

+ +

KENDALL: Gosh, my background is complicated. I've been involved in tech for a very long time. In college, I worked for a company that started Twitter about five years too soon, and then worked in the nonprofit space in China for ten years, then came back, got back involved in tech.

+ +

Today, I'm usually the business guy. So, when technical founders start technical products and want help turning them into successful technical businesses, that's when they call me. So, I have the technical background. I have never been paid to write code, which is probably a good thing. But I can hang in the technical conversations for the most part, but I'm much more interested in the business side and the people leadership side of business. So that tends to be where I play. Every organization hires me to do something different.

+ +

VICTORIA: Thank you for that. And I'm just curious about the CTO Lunches. Just tell me a little bit more about that. And what's the idea behind it that led you to co-found it?

+ +

KENDALL: CTO Lunches has actually been around for about eight years. And I didn't start the initial incarnation of it. It was two people that got us started, and I was trying to hire one of them; one thing led to another. Actually, originally, they did not want me to join. I think, at the time, my title was COO at a company that I was working with.

+ +

About six months later, I took over engineering as VP of engineering, and then they're like, you can join the group now. We're less strict about that [laughs] now. Although it is highly focused on senior engineering leaders, it's not exclusively CTOs. But the group's been in place for a very long time, just intended as a place to network, have conversation with people who are in that senior-most technical position at technical organization.

+ +

So, the CTO role is a lonely role. CTOs get fired all the time. There's not a technical person at the company that doesn't think they can do the job better than them. So, the CTO is always getting feedback. You're doing this wrong. The trade-offs you're making are wrong. This isn't going where it should be going. We should automate that. Why haven't we automated that? We should switch to this other tool. I've used it before; it's 100 times better. Joe, let me know if I'm getting any of this wrong. But that's the experience that I've had.

+ +

Having a place where people can get together and, you know, half the time just complain to each other, hey, this is hard, is really why the networking group exists. So, it's a listserv. And there are local lunches that started in Boulder, Colorado. It's gotten pretty global.

+ +

About a year ago, a little over a year ago, I was talking with one of the people who'd gotten it started. I've been involved in the Denver chapter for most of those eight years. And I was suggesting to him that he change a few things about it, to monetize it so that he could invest in it further. And he came back a few months later and said, "I want to take your advice and do this, but I want you to come do it with me."

+ +

So, we founded the company officially...I think in December is when paperwork went into place. And we started investing in it a little bit more heavily. I was living in Europe last year, so we went and put on lunches in Paris, and Lisbon, and London, and, gosh, all over the place. I'm sure I'm missing some, Amsterdam. But there's been chapters all over the U.S. and a couple of other parts of the world for a long time.

+ +

VICTORIA: That reflects my experience attending a CTO lunch. It's just very casual, like, just get together and eat food and talk about what you've worked on recently, issues you're having, just get ideas and make some friends. So, I really appreciated the group, and I'm going to personally plug the San Diego Chapter has picked up again. And we're meeting next Friday down in Del Mar. And we're going to be meeting on the last Friday of every month through October. So, I'm super excited to be a part of the group.

+ +

And Joe, yeah, I'm curious about your perspective. As a CTO with thoughtbot, just what are your thoughts about that kind of thing?

+ +

KENDALL: Yeah. How right am I about how lonely you are, Joe?

+ +

JOE: [laughs] You know, I've been lonelier since we went remote. I used to work in the office, and I was a CTO, but also, I had lunch with people, which was nice. So, I'm lonelier. But yeah, I think everybody needs a group like that, like, senior developer therapy just to talk about your woes together, drown your sorrows.

+ +

KENDALL: Well, I think years ago, I heard that CTOs are the most fired C-level executive.

+ +

JOE: You're making me nervous now.

+ +

KENDALL: [laughs] You've been there a long time, Joe. I know you've been there a long time. If you haven't been fired yet, you probably got a little while longer in you. This will be really awkward if it's published and you've already been fired.

+ +

VICTORIA: We can always edit that out afterwards.

+ +

[laughter]

+ +

KENDALL: Yeah, no, I think it is a particularly lonely position. And, again, I think a lot of it is the average engineer in a technical company doesn't look at the COO or the CFO or even the CEO and think I could do that. But they're all looking at the CTO and thinking, what does that person do that I can't do?

+ +

It's ridiculous because most of them would make terrible CTOs because it does require some of the business sense. Or, you know, right out of the gate, they might make terrible CTOs. It actually is quite a skill to be the most technical person and speak the business language. I mean, am I right about that, Joe? Like, was that hard for you to learn?

+ +

JOE: Yeah, I definitely think...so, my background is also technical. I have a background in consulting. So, I always did a lot of metaprogramming, if you will. But making that transition to thinking about organizations that way, thinking about how all the other pieces play into it, was a pretty big step for me, even before I became a CTO as a consultant.

+ +

KENDALL: Well, because you can't just chase the newest, hottest technology. You have to make business trade-offs. And not everything can be resume-driven development, right? Even if that technology over there is newer or hotter, it doesn't mean you have a business model that supports it. And it doesn't mean that migrating to it can be done, right?

+ +

JOE: Yeah. I mean, even beyond choosing technologies, just choosing where to invest in your software stack, like, what needs to be reworked, what doesn't, and trying to explain those trade-offs, I think, is a rare skill. Being able to explain why something would be harder than something else when you're working with the leadership to prioritize a backlog it's a puzzle.

+ +

KENDALL: Well, and I think when I'm in an executive conversation, and the CTO says, "Here's the thing that I think is the best decision technically, and I think it's the wrong decision for the business because of X, Y, or Z," I'm always super impressed, right? Like, this is the right technical solution for what we want. However, we shouldn't pursue that for business reasons right now. Maybe we can in six months, but right now, we need to prioritize this other thing. I don't know, that's always when I feel like, oh, this person knows what they're doing.

+ +

JOE: There's nothing more dangerous to software than a bored developer. [laughs] One nice thing about being a consultant is that I don't have to invent problems to solve with technology at my company because sooner or later, I'll run across a company that has those problems, and I'll get to use that technology.

+ +

But I think a lot of people are mostly happy...they might be happy in their role. They might be happy with our team. But they're very interested in whatever is hot right now, like machine learning, AI. And so, suddenly, that surreptitiously makes its way into the tech stack. And then, years later, it's somebody's problem to maintain.

+ +

KENDALL: [laughs] Well, I have a specific memory of a firm in New York City that was, you know, this is relevant to y'all as thoughtbot is that, you know, at least historically, it was, to me, the premier Ruby on Rails consulting shop. I think that's still largely y'alls focus. Am I right about that?

+ +

JOE: We still do a ton of Rails, yeah.

+ +

KENDALL: Okay. Well, so this organization was all Ruby on Rails. It was a big organization. They had a very large customer base. And they hired a new CTO who came in, told everybody in the company they were stupid, laid off 70% of the engineering organization, and told the CEO he was going to completely rewrite the product from scratch in .NET, and he could do it in three weeks. And I'm pretty sure the business went under about three months later [laughs] because that was just so outrageously nuts to me.

+ +

JOE: It's too bad he laid everybody off beforehand. I've been in that situation where somebody tells me, "I'm going to rewrite this. It'll be ready in three weeks." And I could fight with them and try and convince them they're wrong. But I feel like somebody who's approaching that with that attitude they're missing all of the nuance and context that would make it possible to explain to them why it's not going to work. And so, it's easier to just say, "You know, take the three weeks. I'll talk to you in three weeks." But if you've already laid off your development team, that's hard [laughs] to recover from.

+ +

KENDALL: That's exactly right.

+ +

VICTORIA: There's got to be a name for that kind of CTO who just wants to come in and blow everything up [laughs]. Yeah, so you spend a lot of time talking to different CTOs and doing this social networking aspect. I'm wondering if there's, like, patterns that you see. You've mentioned already one about just, like, the most often getting fired. [laughs] But what are the patterns you see, like, in challenges, and then what makes someone successful in that CTO role?

+ +

KENDALL: Well, oh gosh, I have so many thoughts about this. First of all, I run into a couple of different categories of CTOs. There's a lot of people who come to CTO Lunches who are small company CTOs. I mean, it makes sense that there's a lot more small company CTOs than there are big company CTOs. But the small company CTO who maybe it's their first gig in the role or they're a serial CTO. There's the fractional CTOs that come that are doing it across several different organizations at the same time, and then there's the big company CTO who shows up. And honestly, all of their problems are very different.

+ +

The thing that they have in common is even at a very large organization, in that position, they can make a decision that causes the company to go under. So, there is a significant amount of volatility in the amount of power that they wield. So, what's interesting about that is not everybody understands that.

+ +

And so, first of all, there's the kind of CTO that just doesn't get that, and that doesn't matter if they're fractional, or a small company CTO, or a big company CTO. If they don't understand that, they're going to cause significant problems, right? Like the person I just mentioned who said, "I can just re-platform this in three weeks in .NET." There's that.

+ +

I mean, I think, as with any senior leadership position, the comfort with volatility, the ability to know what to communicate down versus across and versus up, and then the ability to speak the business language. For everybody, the CFO's job is to communicate the financial needs alongside of the business leads, right?

+ +

If the CFO's sole goal is to cut costs or make sure we're running as lean as possible, they're a bad CFO. But they're not as good of a CFO as the CFO who can say, "Hey, we're underspending right here. And I can look at the numbers and know we should invest more there. How can we invest more there and invest it well?" And it's the same thing for a technology executive to be able to look at the business context and communicate it back.

+ +

And there are so many CTOs that I've worked with who they're the most technical person in the room, and they know it. And as a result, they're just a jerk to everyone around them, like, everything you did here was wrong. You know, that's where they fail. And so, if they can communicate the business needs, navigate the volatility, and support a team that's going to make decisions that aren't always the same decision they're going to make, they're going to be successful. Honestly, there's very, very few CTOs that I've met like that. People who are excited to meet you at work, excited to see you succeed, excited to see that you went and built a thing is great.

+ +

I mean, the reason I was VP of engineering is the CTO that I was working with at the time...it's a terrible story. There was an engineer who had seen something that we were doing on repeat all the time and, in his spare time, spent about 40 hours outside of work, not during work hours, automating this task that we were doing regularly. And it was related to standing up a whole bunch of things in our standard infrastructure.

+ +

He brings it to the CTO and says, "Look what I built." And the CTO, instead of saying, "Hey, this is incredible. Thank you. This is going to save us a bunch of time. Let's iterate on it. Here's some things I'd like to tweak. Can we bring it in this direction? Can we..." you know, whatever, said, "Why is this in Python? It should be in Ansible," something like that. I can't remember. And the engineer literally burst into tears. [laughs]

+ +

JOE: Oh my God.

+ +

KENDALL: [laughs] Well, I mean, yeah, it was like; literally, that's why the CTO stopped managing people that day. There's a lot of examples that I have like that. Joe, I appreciate that your response is, "Oh my God." Because I think there's a lot of people who'd be like, wait, what was wrong with that? Shouldn't it have been in Ansible?

+ +

JOE: [laughs] Yeah, I've seen CTOs come into primarily two groups. One is the CTO who just tells, you know, like, they make the decisions, and they tell everybody what to do. They obviously don't have all of the information because you can't be in every room all the time. And the other is the CTO, who just wants to be one of the team members and doesn't make any decisions and tries to get people to make decisions collectively on their own without any particular guidance or structure. And finding that middle spot of, like, not just saying, "Hey, everything's in Ansible," allowing for the creativity and initiative, but also coalescing the group into a single direction, I think, is what makes a good CTO.

+ +

KENDALL: Well, yeah, because the CTO does have to say no, sometimes, right? Like, the best product, people say, "No." Good CTOs say, "No." There is some amount of, hey, I need you to come to me with trade-offs about this. Why are you going to make that decision? And I'm sorry, you still didn't convince me, right? Like, I mean, those are appropriate things to say. But yeah, I'm with you on that. You said they fall into two categories. But you really mean the third and that middle ground. Is it easy for you to walk that middle ground, Joe?

+ +

JOE: I wouldn't say it's easy. [laughs]

+ +

KENDALL: Yeah. Well, I'm always nervous to say something. I'm doing well because I know there's a report out there that can point at every time I failed at it, right? So...

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: Yeah, what I'm getting from what you're saying, too, is this communication ability and not just, like, to communicate clearly but with a high level of empathy. So, if you say like, "Well, why is it in Python and not Ansible?" is different than being like, "What makes Python the best solution here?" Like, it's a different way to frame the question that could put someone on the defensive that just really requires, like, a high level of emotional intelligence.

+ +

And also, if they've just worked, like, an 80-hour week, [laughs] I probably would maybe choose a different time to bring those questions up and notice that they have been burning the candle at both ends and prioritize getting them some rest. So, speaking of, like, communication and getting prioritization for [inaudible 15:34], especially on, like, infrastructure teams, maybe we could talk a little bit about Kubernetes, like, when that comes up as an appropriate solution, and how you talk about it with the business.

+ +

KENDALL: My background with Kubernetes is long because a company that I still work with, Fairwinds, used to be called ReactiveOps, has been in the Kubernetes space for a very long time. I think we were one of the very first companies working with Kubernetes. It was coming up that people were running into the limits of something like Heroku, right? And I think it's Kelsey Hightower who said every company wants a PaaS. They just want the Paas that they built themselves. And that's really accurate.

+ +

And I think Kubernetes isn't quite a framework for building your own PaaS or isn't quite a foundation where I think of a foundation for a house. Instead, it's more like rebar and cement and somebody saying, "Good luck, buddy." You know, you still have to know how to put the rebar and cement together to even make the foundation, but it is the building blocks that help get you to a custom-built PaaS. And it's become something that a lot of people have landed on as, you know, the broadly accepted way to build cloud-native infrastructure.

+ +

The reason I've been in the Kubernetes space and the space that I see Kubernetes still filling is we need to standardize on something. We can choose a cloud provider's PaaS. We can choose a third-party PaaS, or we can standardize on something like Kubernetes. And even though we're not going to migrate from AWS to Azure, the flexibility that Kubernetes gives us as a broadly adopted pattern is going to give us some ability to be future-proofed in our infrastructure in a way that previous stacks were not, you know, it was Puppet, and it was Ansible. And it was SaltStack. And it was all Terraform all the time.

+ +

I'm not saying those things don't exist anymore. I'm saying Kubernetes kind of has won that battle. Joe, since you're here and I know y'all are doing some Kubernetes work now at thoughtbot, I'm curious if you agree with that characterization.

+ +

JOE: Yeah, I think that's true. I think it's the center for people to coalesce around. Like, for an effort in the industry to move forward, there needs to be some common language, some common ground. And I think Kubernetes struck the right balance of being abstract. So, you can use it in different environments but still making some decisions, so you don't have to make them all.

+ +

And so, like, all of the things you had to do with containers like figuring out what your data solution is going to be, what your networking solution is going to be, Kubernetes didn't even really make those decisions. [laughs] They just made a platform where those decisions can be made in a common way. And that allowed the community and the ecosystem to grow.

+ +

KENDALL: I mean, I think of it a lot like WordPress; you know, WordPress is hated by many. When WordPress came out, it was hot, right? And it was PHP, which everybody was super excited about at the time. Kubernetes is going to reach a point where it's as long in the tooth and terrible as people think WordPress is, but it has become the standard. And the advantage of the standard is you can use the not standard. You can go build a website in Jekyll instead of WordPress, and there's going to be some things that are nicer about Jekyll.

+ +

But because WordPress is so broadly adopted, there's a plugin for everything. And I think that's where Kubernetes sits is because it's become so widely adopted everybody's building for it. Everybody's adapting for it. If you run into a problem, you're going to find somebody else out there who has that problem.

+ +

In fact, I think of one organization that I know that was on HashiCorp's Nomad. And they said, "Actually, we think Nomad has better technology through and through. But we think we're the only company at this size and scale using Nomad. And so, when we run into a problem, we can't Google for it. There's no such thing as a plugin that exists to solve this. Nobody has ever run into this before on Nomad. But there's 100 companies dealing with the same problem in Kubernetes, and there's ten solutions." And I think that's the power that it brings.

+ +

VICTORIA: So, it's not just a trend that CTOs are moving towards, you think.

+ +

KENDALL: I mean, I think it's already won the battle and the hockey stick of adoption. We're still right at the very bottom of that tick-up because it takes people a long time to adapt new technology like this, especially in their infrastructure. It's a big migration, to move. So, I don't think it's the widely adopted infrastructure technology even yet. I think a lot of the biggest organizations are still running on things that predate Kubernetes. But I think it has won the battle, and it is winning the battle and is going to be the thing going forward, so yeah.

+ +

JOE: I think it also has a lot of room to grow still. Like, there are other technologies that I used previously, like Docker, and they were a big step up from some of the things I was doing at the time. But you quickly hit the ceiling, or it was, like, I don't know where to go with this next. I don't know what else is going to happen.

+ +

Whereas with Kubernetes, there are so many directions it can go in. Like, the serverless Kubernetes offerings that are starting to pop up are extremely interesting, where, you know, you don't actually maintain a cluster or anything. You just deploy things to this ethereal cluster that always exists. And so, that sort of combination of platform as a service, function as a service, Kubernetes, as that evolves, I think there are a lot of exciting things that have yet to come in the Kubernetes space.

+ +

KENDALL: Well, so say more about that, Joe, because I've been going to KubeCon for a very long time, maybe...I don't know if it's 2016 or so when I first went. And it felt for a number of years...maybe those first four-ish years it was always the people at KubeCon were the, like, big dreamers and thinkers and, like, we're here to change the future of cloud infrastructure. And this is going places, and we're excited to be here and be a part of it. And here's what I'm going to do that changes the next thing.

+ +

And I feel like now if I go to KubeCon, it's a lot of people from, you know, IBM and some big bank that are, like, deep sigh, well, I have to adopt Kubernetes. I need to know what the vendors are. What do you guys do, and how does this work? Can you please teach it to me? Because I'm being told by my boss, I have to do it.

+ +

I don't see that excitement around Kubernetes anymore. The excitement I see is all around further up the stack, you know, things like Wasm, WebAssembly, or eBPF, the networking things and tracing things that are possible. Maybe that's further down the stack. I guess it depends on how you think about it, but different part of the stack. So, I'm curious, touching on the serverless components of Kubernetes; sure, I get that. And I do think, increasingly, the PaaSs of the future are all going to be Kubernetes-based, whether that's exposed or not.

+ +

But where are the places that you think it's still going to go? Because I feel like it's already gotten boring, maybe in a positive way. But I don't see the excitement around it like I saw a few years back. And I'm curious what else you think is going to happen.

+ +

JOE: Yeah, I mean, I don't think I disagree. I think Kubernetes itself, the core concept, is, like, it's still changing. But you're right that the excitement about Kubernetes existing has gone down because it's been there for a while. But I feel like the ecosystem is still growing pretty rapidly. Like, the things you mentioned, like Wasm and Istio, and all the tools in that ecosystem that continue to grow, is where I think the interesting things will happen. Like, it's created this new lower-level layer of abstraction that makes it possible to build concepts and technology that could not have existed before.

+ +

KENDALL: Yeah, well, and I'm, you know, talking to people who are working really hard at making short-run ephemeral workloads work better on things like GPUs for the sake of AI, right? Like, I mean, there is some really interesting things happening, and people are doing this in Kubernetes. So, I get that. I agree with that.

+ +

It is interesting that Kubernetes has become sort of the stable thing, and now it's about who can build the interesting add-ons. It's almost like, okay, we've built Half-Life. What is Counter-Strike going to look like? You know. That's a terrible (I'm aging myself.) example. But still.

+ +

VICTORIA: I think it's interesting, I mean, to look at the size of the market for platform engineering right now. In 2022, was 4.8 billion, and it's estimated to be in 10 years $41 billion. So, there is this emerging trend of different platform engineering products, different abstractions on top of Kubernetes. And I wonder what advice you would have for a technical founder who's looking to build and solve some of these interesting issues in Kubernetes and create a business around it.

+ +

KENDALL: Well, okay, let me clarify that question. Are you thinking, I'm a startup, and I need to build my infrastructure, and I'm going to choose Kubernetes. What advice do I need? Or are you thinking, I am founder, and I want to go build on the Kubernetes ecosystem. What advice do you have?

+ +

VICTORIA: Now I want to know the answer to both. But my question was the second one to start.

+ +

KENDALL: One of the things that is hard about the Kubernetes ecosystem is there's not a ton of companies that have made a whole bunch of money in Kubernetes because, as I said, I still think we're actually really early in the adoption curve.

+ +

The kinds of companies that have adopted Kubernetes are the kinds of companies that don't spend lots and lots of money on an infrastructure. [laughs] They're the kinds of companies that are fast-moving, early adopters, or, you know, those first followers, and so they're under $100 million companies for the most part. Where the JP Morgans and Chase are running Kubernetes somewhere in their stack, but they haven't adopted it across the stack to need the biggest, best tools about it.

+ +

So, the first piece of advice that I'd give is, be a little wary. It's still very early to the market. Maybe now is the time to build the thing. When ReactiveOps pivoted to Kubernetes, I think it was six months of having conversations with companies who were just, like, so excited about it, and this is definitely what we want to do. But nobody was doing it yet. You know, it was, we have, like, six solid months of just excitement and nobody actually pulling the trigger. And, you know, we were a little too early to that market. And that was just the people adopting it.

+ +

So, I think there is some nervousness that cloud-native solutions the only people who are really making money in Kubernetes are named Amazon, Google, and Microsoft because it's the cloud providers that are making a ton off of it. Now, there's Rancher. There is StackPointCloud. There's a few others that have had big exits in this space. But I don't think it's actually as big of a booming economy as a lot of people think, in part because EKS is an incredibly amazing product.

+ +

Like, eight years ago, the thing people paid us the most to do at ReactiveOps was just stand up Kubernetes because it was so stinking hard to just get it up and working. And now you click some buttons. Anybody can go do that. So, it's changed a lot, right? And I think be wary when you're entering that ecosystem.

+ +

And then, my advice to the founder that's not building on the ecosystem but just looking to adopt a technology that's going to be a future-proofed infrastructure is just adopt one of the cloud-native platforms. And there are a whole bunch of sort of default best-in-class add-ons out there that you need to throw in. Don't adopt too many because then you have to maintain them forever. That's the easiest way to get started. You can figure out all the rest of it later. But if you go use EKS, or GKE, AKS, you can get started pretty easily and build something that is going to be future-proofed. I don't know, Joe; I'm curious if you disagree with any of that.

+ +

JOE: Well, I think it's interesting to think about who's making money in Kubernetes. Like, I think there might not be as many companies who are doing only Kubernetes and Kubernetes-focused products that are massively successful. But I think because it has had a good amount of adoption and because it's easier to work with something that's standardized, it has helped companies sell things that they wanted to sell anyway. Like, all the Datadog, all the Scalas, the logging companies, they all have Kubernetes add-ons.

+ +

And now everybody is paying Datadog [laughs] to have a dashboard for their Kubernetes cluster. I think they're making more money than they would have been without targeting the market. And so, I think that's really...if you want to get into the market, it's not, like, I'm going to build a Kubernetes product. It's if I'm building operations and an infrastructure product, I should definitely have it work with Kubernetes, and people will want to click and install it.

+ +

KENDALL: So, to be clear, you know, one of the companies that I work with is called Axiom, and they play in the same, you know, monitoring, observability space as Datadog does. And part of what makes Kubernetes interesting in that space is in a microservice environment; there's so much happening. Where are problems being caused? We don't live in a day where I can just run my code, and it tells me that there's an unexpected semicolon on line 23, right? Like, that still happens. You're still doing those things.

+ +

But this microservice talking to that microservice is where things tend to break down. Did I communicate this correctly? What was sent? What was received? Where did it break down? What was the latency? And if you were doing things in the old way back when you were standing it up with, say, Ansible, or Puppet, or something like that, and you were orchestrating all of these cloud virtual machines, you had to really work hard to instrument the tracing and logging and everything involved in order to track what was going on.

+ +

Whereas that's one of the magic things about Kubernetes is with a few of the add-ons or some of the things out of the box with Kubernetes, it's a couple of clicks to get so, so much of the data and have insight into where things are going and what's going wrong. And so, I 100% agree with that.

+ +

Kubernetes is generating a tremendous amount of data. And if you're a data company, it's really nice to have all that come in, and it helps them make money, helps the user of Kubernetes in that situation understand where problems are happening and breaking down. Yeah, there's definitely some network effects of what Kubernetes is doing in that. I completely agree.

+ +

JOE: I think there are also some interesting companies, like, where they make...Emissary, Ambassador, and they have that sort of dual --

+ +

KENDALL: Komodor, is that --

+ +

JOE: Yeah, maybe. They have open source, but then they have a product.

+ +

KENDALL: You're thinking of Ambassador Labs.

+ +

JOE: Yeah. Ambassador Labs, yeah. I guess I don't really know how much money they're making. But I think that's a really interesting concept as people who make open-source things then make a well-supported product built around it.

+ +

KENDALL: Sure. What's interesting is, I think in the VC world, at least right now, and it may pick up again, but post-Silicon Valley Bank nearly caving in, I think that the VC tolerance for, yeah, just go get a billion open-source adopters, and we'll figure out how to monetize later I think that the tolerance for that is a lot lower than it was even six months ago.

+ +

JOE: Yeah, I think you have to have a dual model right from the beginning now.

+ +

KENDALL: Yeah. Agreed.

+ +

VICTORIA: You got to figure out how to make money on Kubernetes before you can. [laughs]

+ +

KENDALL: You know, minor detail. That's why I think services companies in this space still have a lot going for it. Because in order to even be able to sell software to a company using Kubernetes, you half the time have to go stand up Kubernetes for them because it is still that hard for so many people to really adopt it.

+ +

VICTORIA: Yeah. And maybe, like, talking more about, like, when it is the right decision to start on Kubernetes because I think the question I get sometimes is just, is it overkill? Is it too much for what we're building? Especially, like, if you're building a brand-new product, you're not even sure if it's going to get adopted that widely.

+ +

KENDALL: I mean, and I'm [laughs] curious your thought on this, Joe, but there's a good argument to be made that Heroku was enough for the vast majority of founders early on. But the thing is, Kubernetes isn't as hard as it used to be. Going and clicking a couple of buttons on GKE and deploying something into Kubernetes with GKE Autopilot running it's not as easy as Heroku, but it's not wildly far off. And it does substantially future-proof you.

+ +

So, when is it too early? I'm not sure it's ever too early if you have an intention of scaling if you're planning on running some kind of legacy workload, like, things that are going to be stateful. Or maybe WordPress, for example, you don't probably need to deploy your WordPress blog onto Kubernetes. You can do that in your cPanel on Bluehost. I don't actually know if Bluehost even exists anymore, but I assume it's still a thing. I don't know, what would you say, Joe?

+ +

JOE: I agree with that. I think it's a hard first pill to swallow. But I think the reality is that it's very easy to underestimate the infrastructure needs of even an early product. Like, it doesn't really matter what you're building. You're still going to have things like secrets management. You're still going to have to worry about networking. They just don't go away. There's no way you have a product without them.

+ +

And so, rather than slowly solving all those problems from scratch on a platform that isn't designed for it, I think it's easier to just bite the bullet and use one of the managed solutions, especially, as you said, I think it's getting easier and easier. The activation energy from going from credit card to Kubernetes cluster is just getting lower.

+ +

KENDALL: And so, the role of the CTO is just getting easier and easier because they can just adopt the one technology, and it's obviously Kubernetes. And it's obviously Rust, right? [laughter] Yeah, no, I'm with you. And I think if you find somebody who knows Kubernetes inside and out, it's really not going to take them long to get started.

+ +

VICTORIA: Yeah, once again, change management is the biggest challenge for any new innovation coming into adoption. So, I'm curious to talk more about the influence that you need and how you influence others to come around to these types of ideas, like, in the executive suite and with the leadership of a company, especially on these types of topics, which can feel maybe a little abstract for people.

+ +

KENDALL: How you influence them specifically to use Kubernetes, or just how you talk with them about technology adoption in general? Or what are you asking?

+ +

VICTORIA: Yeah, like, how do I get people to not just turn their ears off when I say the word Kubernetes? [laughs]

+ +

KENDALL: Yeah, I mean, I think...so I think that's where it's the technologist's job and the role of the CTO to translate these things into business speak. And that's why I'm using words like future-proofing your infrastructure is because there are companies that...I know one company that made a conscious decision that they were going to try to re-platform every single year, and that is not a good idea or sustainable for the vast majority [laughs] of companies. In fact, I can't think of a single situation where that makes sense.

+ +

But if you can say to the CFO, "Hey, it's going to cost us a little bit more right now. It's going to save us substantially in the long term because this is the thing that's winning. And if we go standardize on Heroku right now, every company does eventually have to migrate off of Heroku. They either go out of business, or they get too big for it." That's the kind of thing that needs to be communicated in order to get people to adopt it.

+ +

They don't care what the word is. They don't care if you're saying Kubernetes; you know, most CFOs understand it about as well as my mom does. My mom tries to bring it up in conversation because she's heard me use it. And she thinks it makes her sound smart, which maybe it does in the right climate.

+ +

VICTORIA: My partner does the same thing. He says DevOps and Kubernetes all the time. I'm like; you don't know what you're talking about. [laughter]

+ +

JOE: Those words do not come up in my house.

+ +

KENDALL: One of my kids asked me to explain Kubernetes. And I do a whole talk, particularly at organizations where understanding Kubernetes is essential to the salespeople's role. And I give a whole talk about the background of how we got here from deploying on some servers in our back room. And, you know, what's different about the cloud, what containerization did, et cetera. And I have this long explanation. And I remember taking a deep breath and saying to my kids, "Do you really want to hear this?" And I had one son say, "Yes, absolutely." And my wife and three of the other kids all stood up and said, "No way," and left the room.

+ +

So, when somebody asks me, "What do you do?" Actually, one of the key relationships I built with some of the early people at GCP when we were partnering closely with them was a person that I met, and I asked, "What do you do for a living?" And he said, "I can tell you, but it's not going to mean anything to you." And I was like, "That's what I say to people." And it turned out he was in charge of, you know, Kubernetes partnerships for Google. I can explain to you what it means and why it's important. But you're not going to be happy that I spent that time explaining it to you.

+ +

VICTORIA: [laughs] That sounds awesome, though. It sounds like you built a server rack just to demo to your children what it was.

+ +

KENDALL: No, no. I just talked back through the history of...that company that I mentioned that built Twitter about five years too early; we had a, you know, we had a server rack in the...literally physically in our closet that was serving up our product at the time.

+ +

VICTORIA: Probably the best demo I ever saw was at Google headquarters in Herndon, and someone had built...They had 3D-printed a little mini server rack that they had put Raspberry Pis onto, and then they had Kubernetes deployed on it. And they did an automatic failover of a node to just demo how it works and had little lights that went with it. It was pretty fun. So maybe you should get one for yourself. [laughter] It's a fun project.

+ +

KENDALL: They remember the things that it enables. They don't remember what it does. And so, when I say so, and so is a client that's using this technology, then they get real excited because they're like, "My dad makes that work." And I'm like, well, okay, that's kind of a stretch, but you get the idea.

+ +

VICTORIA: Yeah, you got to lean into that kind of reputation in your house.

+ +

KENDALL: That's right.

+ +

VICTORIA: And you're like, yes, that's correct.

+ +

KENDALL: That's right. [laughs]

+ +

VICTORIA: I do make Kubernetes. I make all the clouds work, yeah.

+ +

KENDALL: Actually, my most common explanation is Kubernetes is the plumbing of the internet. Unless you're a plumber, you don't care about the pipes. You just want your shit to flush when you use the toilet. You want the things to load when you click your buttons. You don't actually care what's going on behind the scenes, but this is what's orchestrating it increasingly across the internet.

+ +

VICTORIA: So far, we've called Kubernetes WordPress or the toilet. [laughs]

+ +

KENDALL: The plumbing.

+ +

[laughter]

+ +

VICTORIA: You are really good at selling it.

+ +

[laughter]

+ +

KENDALL: Hey, if you want to build a nice, clean city, you need good plumbing. You might not care what the pipes are made of, but you need good plumbing. [laughs]

+ +

VICTORIA: Works for me. On that note -- [laughs]

+ +

KENDALL: Yeah. Right? Right?

+ +

VICTORIA: That's [inaudible 36:41] on a high note. Is there anything else that you'd like to promote?

+ +

KENDALL: With regards to CTO Lunches, we have a free listserv. There are local lunches. If there isn't a local lunch where you are, it's very lightweight to start up a chapter. We often have folks who are willing to sponsor that first lunch to get you going. We do have a paid tier of CTO Lunches. If you want a small back room Slack channel of people to discuss, I think it's $99 a month.

+ +

Yeah, if you're a CTO and/or a senior engineering leader and you want a community of people to process with, be it our free tier or our paid tier, we've got something for you. We're trying to invest in this to build community around it. And it's something we enjoy doing more than almost anything. Come take part.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Kendall Miller.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Kendall Miller is the Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections.

+ +

The first half of the conversation with host Victoria Guido and special guest host, Joe Ferris, CTO of thoughtbot revolves around the use, adoption, and growth of Kubernetes within the technology industry. The discussion explores Kubernetes' history, influence, and its comparison with other platforms like Heroku and WordPress, emphasizing its adaptability and potential.

+ +

The second half focuses on more practical aspects of Kubernetes, including its adoption and scalability. It centers on the appropriateness of adopting Kubernetes for different projects and how it can future-proof infrastructure. The importance of translating technical language into business speak is emphasized to influence executives and others in the decision-making process and Kendall also discuss communication and empathy in tech, particularly the skill of framing questions and understanding others' emotional states.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Kendall Miller, Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. Kendall, thank you for joining me.

+ +

KENDALL: Thanks for having me. I'm excited.

+ +

VICTORIA: And today, we have a special guest host, Joe Ferris, CTO of thoughtbot. Joe, thank you for joining us.

+ +

JOE: Hello there. Thank you for having me.

+ +

KENDALL: Hi, Joe. Thanks for being here. It's exciting.

+ +

VICTORIA: Yes. It's so exciting. I think this is going to be a great episode. So, Kendall, I met you at a San Diego CTO lunch recently, and I know that's not the only thing that you do. So, you're also an advisor, a board member, and CXO. So, maybe tell us a little bit more about your background.

+ +

KENDALL: Gosh, my background is complicated. I've been involved in tech for a very long time. In college, I worked for a company that started Twitter about five years too soon, and then worked in the nonprofit space in China for ten years, then came back, got back involved in tech.

+ +

Today, I'm usually the business guy. So, when technical founders start technical products and want help turning them into successful technical businesses, that's when they call me. So, I have the technical background. I have never been paid to write code, which is probably a good thing. But I can hang in the technical conversations for the most part, but I'm much more interested in the business side and the people leadership side of business. So that tends to be where I play. Every organization hires me to do something different.

+ +

VICTORIA: Thank you for that. And I'm just curious about the CTO Lunches. Just tell me a little bit more about that. And what's the idea behind it that led you to co-found it?

+ +

KENDALL: CTO Lunches has actually been around for about eight years. And I didn't start the initial incarnation of it. It was two people that got us started, and I was trying to hire one of them; one thing led to another. Actually, originally, they did not want me to join. I think, at the time, my title was COO at a company that I was working with.

+ +

About six months later, I took over engineering as VP of engineering, and then they're like, you can join the group now. We're less strict about that [laughs] now. Although it is highly focused on senior engineering leaders, it's not exclusively CTOs. But the group's been in place for a very long time, just intended as a place to network, have conversation with people who are in that senior-most technical position at technical organization.

+ +

So, the CTO role is a lonely role. CTOs get fired all the time. There's not a technical person at the company that doesn't think they can do the job better than them. So, the CTO is always getting feedback. You're doing this wrong. The trade-offs you're making are wrong. This isn't going where it should be going. We should automate that. Why haven't we automated that? We should switch to this other tool. I've used it before; it's 100 times better. Joe, let me know if I'm getting any of this wrong. But that's the experience that I've had.

+ +

Having a place where people can get together and, you know, half the time just complain to each other, hey, this is hard, is really why the networking group exists. So, it's a listserv. And there are local lunches that started in Boulder, Colorado. It's gotten pretty global.

+ +

About a year ago, a little over a year ago, I was talking with one of the people who'd gotten it started. I've been involved in the Denver chapter for most of those eight years. And I was suggesting to him that he change a few things about it, to monetize it so that he could invest in it further. And he came back a few months later and said, "I want to take your advice and do this, but I want you to come do it with me."

+ +

So, we founded the company officially...I think in December is when paperwork went into place. And we started investing in it a little bit more heavily. I was living in Europe last year, so we went and put on lunches in Paris, and Lisbon, and London, and, gosh, all over the place. I'm sure I'm missing some, Amsterdam. But there's been chapters all over the U.S. and a couple of other parts of the world for a long time.

+ +

VICTORIA: That reflects my experience attending a CTO lunch. It's just very casual, like, just get together and eat food and talk about what you've worked on recently, issues you're having, just get ideas and make some friends. So, I really appreciated the group, and I'm going to personally plug the San Diego Chapter has picked up again. And we're meeting next Friday down in Del Mar. And we're going to be meeting on the last Friday of every month through October. So, I'm super excited to be a part of the group.

+ +

And Joe, yeah, I'm curious about your perspective. As a CTO with thoughtbot, just what are your thoughts about that kind of thing?

+ +

KENDALL: Yeah. How right am I about how lonely you are, Joe?

+ +

JOE: [laughs] You know, I've been lonelier since we went remote. I used to work in the office, and I was a CTO, but also, I had lunch with people, which was nice. So, I'm lonelier. But yeah, I think everybody needs a group like that, like, senior developer therapy just to talk about your woes together, drown your sorrows.

+ +

KENDALL: Well, I think years ago, I heard that CTOs are the most fired C-level executive.

+ +

JOE: You're making me nervous now.

+ +

KENDALL: [laughs] You've been there a long time, Joe. I know you've been there a long time. If you haven't been fired yet, you probably got a little while longer in you. This will be really awkward if it's published and you've already been fired.

+ +

VICTORIA: We can always edit that out afterwards.

+ +

[laughter]

+ +

KENDALL: Yeah, no, I think it is a particularly lonely position. And, again, I think a lot of it is the average engineer in a technical company doesn't look at the COO or the CFO or even the CEO and think I could do that. But they're all looking at the CTO and thinking, what does that person do that I can't do?

+ +

It's ridiculous because most of them would make terrible CTOs because it does require some of the business sense. Or, you know, right out of the gate, they might make terrible CTOs. It actually is quite a skill to be the most technical person and speak the business language. I mean, am I right about that, Joe? Like, was that hard for you to learn?

+ +

JOE: Yeah, I definitely think...so, my background is also technical. I have a background in consulting. So, I always did a lot of metaprogramming, if you will. But making that transition to thinking about organizations that way, thinking about how all the other pieces play into it, was a pretty big step for me, even before I became a CTO as a consultant.

+ +

KENDALL: Well, because you can't just chase the newest, hottest technology. You have to make business trade-offs. And not everything can be resume-driven development, right? Even if that technology over there is newer or hotter, it doesn't mean you have a business model that supports it. And it doesn't mean that migrating to it can be done, right?

+ +

JOE: Yeah. I mean, even beyond choosing technologies, just choosing where to invest in your software stack, like, what needs to be reworked, what doesn't, and trying to explain those trade-offs, I think, is a rare skill. Being able to explain why something would be harder than something else when you're working with the leadership to prioritize a backlog it's a puzzle.

+ +

KENDALL: Well, and I think when I'm in an executive conversation, and the CTO says, "Here's the thing that I think is the best decision technically, and I think it's the wrong decision for the business because of X, Y, or Z," I'm always super impressed, right? Like, this is the right technical solution for what we want. However, we shouldn't pursue that for business reasons right now. Maybe we can in six months, but right now, we need to prioritize this other thing. I don't know, that's always when I feel like, oh, this person knows what they're doing.

+ +

JOE: There's nothing more dangerous to software than a bored developer. [laughs] One nice thing about being a consultant is that I don't have to invent problems to solve with technology at my company because sooner or later, I'll run across a company that has those problems, and I'll get to use that technology.

+ +

But I think a lot of people are mostly happy...they might be happy in their role. They might be happy with our team. But they're very interested in whatever is hot right now, like machine learning, AI. And so, suddenly, that surreptitiously makes its way into the tech stack. And then, years later, it's somebody's problem to maintain.

+ +

KENDALL: [laughs] Well, I have a specific memory of a firm in New York City that was, you know, this is relevant to y'all as thoughtbot is that, you know, at least historically, it was, to me, the premier Ruby on Rails consulting shop. I think that's still largely y'alls focus. Am I right about that?

+ +

JOE: We still do a ton of Rails, yeah.

+ +

KENDALL: Okay. Well, so this organization was all Ruby on Rails. It was a big organization. They had a very large customer base. And they hired a new CTO who came in, told everybody in the company they were stupid, laid off 70% of the engineering organization, and told the CEO he was going to completely rewrite the product from scratch in .NET, and he could do it in three weeks. And I'm pretty sure the business went under about three months later [laughs] because that was just so outrageously nuts to me.

+ +

JOE: It's too bad he laid everybody off beforehand. I've been in that situation where somebody tells me, "I'm going to rewrite this. It'll be ready in three weeks." And I could fight with them and try and convince them they're wrong. But I feel like somebody who's approaching that with that attitude they're missing all of the nuance and context that would make it possible to explain to them why it's not going to work. And so, it's easier to just say, "You know, take the three weeks. I'll talk to you in three weeks." But if you've already laid off your development team, that's hard [laughs] to recover from.

+ +

KENDALL: That's exactly right.

+ +

VICTORIA: There's got to be a name for that kind of CTO who just wants to come in and blow everything up [laughs]. Yeah, so you spend a lot of time talking to different CTOs and doing this social networking aspect. I'm wondering if there's, like, patterns that you see. You've mentioned already one about just, like, the most often getting fired. [laughs] But what are the patterns you see, like, in challenges, and then what makes someone successful in that CTO role?

+ +

KENDALL: Well, oh gosh, I have so many thoughts about this. First of all, I run into a couple of different categories of CTOs. There's a lot of people who come to CTO Lunches who are small company CTOs. I mean, it makes sense that there's a lot more small company CTOs than there are big company CTOs. But the small company CTO who maybe it's their first gig in the role or they're a serial CTO. There's the fractional CTOs that come that are doing it across several different organizations at the same time, and then there's the big company CTO who shows up. And honestly, all of their problems are very different.

+ +

The thing that they have in common is even at a very large organization, in that position, they can make a decision that causes the company to go under. So, there is a significant amount of volatility in the amount of power that they wield. So, what's interesting about that is not everybody understands that.

+ +

And so, first of all, there's the kind of CTO that just doesn't get that, and that doesn't matter if they're fractional, or a small company CTO, or a big company CTO. If they don't understand that, they're going to cause significant problems, right? Like the person I just mentioned who said, "I can just re-platform this in three weeks in .NET." There's that.

+ +

I mean, I think, as with any senior leadership position, the comfort with volatility, the ability to know what to communicate down versus across and versus up, and then the ability to speak the business language. For everybody, the CFO's job is to communicate the financial needs alongside of the business leads, right?

+ +

If the CFO's sole goal is to cut costs or make sure we're running as lean as possible, they're a bad CFO. But they're not as good of a CFO as the CFO who can say, "Hey, we're underspending right here. And I can look at the numbers and know we should invest more there. How can we invest more there and invest it well?" And it's the same thing for a technology executive to be able to look at the business context and communicate it back.

+ +

And there are so many CTOs that I've worked with who they're the most technical person in the room, and they know it. And as a result, they're just a jerk to everyone around them, like, everything you did here was wrong. You know, that's where they fail. And so, if they can communicate the business needs, navigate the volatility, and support a team that's going to make decisions that aren't always the same decision they're going to make, they're going to be successful. Honestly, there's very, very few CTOs that I've met like that. People who are excited to meet you at work, excited to see you succeed, excited to see that you went and built a thing is great.

+ +

I mean, the reason I was VP of engineering is the CTO that I was working with at the time...it's a terrible story. There was an engineer who had seen something that we were doing on repeat all the time and, in his spare time, spent about 40 hours outside of work, not during work hours, automating this task that we were doing regularly. And it was related to standing up a whole bunch of things in our standard infrastructure.

+ +

He brings it to the CTO and says, "Look what I built." And the CTO, instead of saying, "Hey, this is incredible. Thank you. This is going to save us a bunch of time. Let's iterate on it. Here's some things I'd like to tweak. Can we bring it in this direction? Can we..." you know, whatever, said, "Why is this in Python? It should be in Ansible," something like that. I can't remember. And the engineer literally burst into tears. [laughs]

+ +

JOE: Oh my God.

+ +

KENDALL: [laughs] Well, I mean, yeah, it was like; literally, that's why the CTO stopped managing people that day. There's a lot of examples that I have like that. Joe, I appreciate that your response is, "Oh my God." Because I think there's a lot of people who'd be like, wait, what was wrong with that? Shouldn't it have been in Ansible?

+ +

JOE: [laughs] Yeah, I've seen CTOs come into primarily two groups. One is the CTO who just tells, you know, like, they make the decisions, and they tell everybody what to do. They obviously don't have all of the information because you can't be in every room all the time. And the other is the CTO, who just wants to be one of the team members and doesn't make any decisions and tries to get people to make decisions collectively on their own without any particular guidance or structure. And finding that middle spot of, like, not just saying, "Hey, everything's in Ansible," allowing for the creativity and initiative, but also coalescing the group into a single direction, I think, is what makes a good CTO.

+ +

KENDALL: Well, yeah, because the CTO does have to say no, sometimes, right? Like, the best product, people say, "No." Good CTOs say, "No." There is some amount of, hey, I need you to come to me with trade-offs about this. Why are you going to make that decision? And I'm sorry, you still didn't convince me, right? Like, I mean, those are appropriate things to say. But yeah, I'm with you on that. You said they fall into two categories. But you really mean the third and that middle ground. Is it easy for you to walk that middle ground, Joe?

+ +

JOE: I wouldn't say it's easy. [laughs]

+ +

KENDALL: Yeah. Well, I'm always nervous to say something. I'm doing well because I know there's a report out there that can point at every time I failed at it, right? So...

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: Yeah, what I'm getting from what you're saying, too, is this communication ability and not just, like, to communicate clearly but with a high level of empathy. So, if you say like, "Well, why is it in Python and not Ansible?" is different than being like, "What makes Python the best solution here?" Like, it's a different way to frame the question that could put someone on the defensive that just really requires, like, a high level of emotional intelligence.

+ +

And also, if they've just worked, like, an 80-hour week, [laughs] I probably would maybe choose a different time to bring those questions up and notice that they have been burning the candle at both ends and prioritize getting them some rest. So, speaking of, like, communication and getting prioritization for [inaudible 15:34], especially on, like, infrastructure teams, maybe we could talk a little bit about Kubernetes, like, when that comes up as an appropriate solution, and how you talk about it with the business.

+ +

KENDALL: My background with Kubernetes is long because a company that I still work with, Fairwinds, used to be called ReactiveOps, has been in the Kubernetes space for a very long time. I think we were one of the very first companies working with Kubernetes. It was coming up that people were running into the limits of something like Heroku, right? And I think it's Kelsey Hightower who said every company wants a PaaS. They just want the Paas that they built themselves. And that's really accurate.

+ +

And I think Kubernetes isn't quite a framework for building your own PaaS or isn't quite a foundation where I think of a foundation for a house. Instead, it's more like rebar and cement and somebody saying, "Good luck, buddy." You know, you still have to know how to put the rebar and cement together to even make the foundation, but it is the building blocks that help get you to a custom-built PaaS. And it's become something that a lot of people have landed on as, you know, the broadly accepted way to build cloud-native infrastructure.

+ +

The reason I've been in the Kubernetes space and the space that I see Kubernetes still filling is we need to standardize on something. We can choose a cloud provider's PaaS. We can choose a third-party PaaS, or we can standardize on something like Kubernetes. And even though we're not going to migrate from AWS to Azure, the flexibility that Kubernetes gives us as a broadly adopted pattern is going to give us some ability to be future-proofed in our infrastructure in a way that previous stacks were not, you know, it was Puppet, and it was Ansible. And it was SaltStack. And it was all Terraform all the time.

+ +

I'm not saying those things don't exist anymore. I'm saying Kubernetes kind of has won that battle. Joe, since you're here and I know y'all are doing some Kubernetes work now at thoughtbot, I'm curious if you agree with that characterization.

+ +

JOE: Yeah, I think that's true. I think it's the center for people to coalesce around. Like, for an effort in the industry to move forward, there needs to be some common language, some common ground. And I think Kubernetes struck the right balance of being abstract. So, you can use it in different environments but still making some decisions, so you don't have to make them all.

+ +

And so, like, all of the things you had to do with containers like figuring out what your data solution is going to be, what your networking solution is going to be, Kubernetes didn't even really make those decisions. [laughs] They just made a platform where those decisions can be made in a common way. And that allowed the community and the ecosystem to grow.

+ +

KENDALL: I mean, I think of it a lot like WordPress; you know, WordPress is hated by many. When WordPress came out, it was hot, right? And it was PHP, which everybody was super excited about at the time. Kubernetes is going to reach a point where it's as long in the tooth and terrible as people think WordPress is, but it has become the standard. And the advantage of the standard is you can use the not standard. You can go build a website in Jekyll instead of WordPress, and there's going to be some things that are nicer about Jekyll.

+ +

But because WordPress is so broadly adopted, there's a plugin for everything. And I think that's where Kubernetes sits is because it's become so widely adopted everybody's building for it. Everybody's adapting for it. If you run into a problem, you're going to find somebody else out there who has that problem.

+ +

In fact, I think of one organization that I know that was on HashiCorp's Nomad. And they said, "Actually, we think Nomad has better technology through and through. But we think we're the only company at this size and scale using Nomad. And so, when we run into a problem, we can't Google for it. There's no such thing as a plugin that exists to solve this. Nobody has ever run into this before on Nomad. But there's 100 companies dealing with the same problem in Kubernetes, and there's ten solutions." And I think that's the power that it brings.

+ +

VICTORIA: So, it's not just a trend that CTOs are moving towards, you think.

+ +

KENDALL: I mean, I think it's already won the battle and the hockey stick of adoption. We're still right at the very bottom of that tick-up because it takes people a long time to adapt new technology like this, especially in their infrastructure. It's a big migration, to move. So, I don't think it's the widely adopted infrastructure technology even yet. I think a lot of the biggest organizations are still running on things that predate Kubernetes. But I think it has won the battle, and it is winning the battle and is going to be the thing going forward, so yeah.

+ +

JOE: I think it also has a lot of room to grow still. Like, there are other technologies that I used previously, like Docker, and they were a big step up from some of the things I was doing at the time. But you quickly hit the ceiling, or it was, like, I don't know where to go with this next. I don't know what else is going to happen.

+ +

Whereas with Kubernetes, there are so many directions it can go in. Like, the serverless Kubernetes offerings that are starting to pop up are extremely interesting, where, you know, you don't actually maintain a cluster or anything. You just deploy things to this ethereal cluster that always exists. And so, that sort of combination of platform as a service, function as a service, Kubernetes, as that evolves, I think there are a lot of exciting things that have yet to come in the Kubernetes space.

+ +

KENDALL: Well, so say more about that, Joe, because I've been going to KubeCon for a very long time, maybe...I don't know if it's 2016 or so when I first went. And it felt for a number of years...maybe those first four-ish years it was always the people at KubeCon were the, like, big dreamers and thinkers and, like, we're here to change the future of cloud infrastructure. And this is going places, and we're excited to be here and be a part of it. And here's what I'm going to do that changes the next thing.

+ +

And I feel like now if I go to KubeCon, it's a lot of people from, you know, IBM and some big bank that are, like, deep sigh, well, I have to adopt Kubernetes. I need to know what the vendors are. What do you guys do, and how does this work? Can you please teach it to me? Because I'm being told by my boss, I have to do it.

+ +

I don't see that excitement around Kubernetes anymore. The excitement I see is all around further up the stack, you know, things like Wasm, WebAssembly, or eBPF, the networking things and tracing things that are possible. Maybe that's further down the stack. I guess it depends on how you think about it, but different part of the stack. So, I'm curious, touching on the serverless components of Kubernetes; sure, I get that. And I do think, increasingly, the PaaSs of the future are all going to be Kubernetes-based, whether that's exposed or not.

+ +

But where are the places that you think it's still going to go? Because I feel like it's already gotten boring, maybe in a positive way. But I don't see the excitement around it like I saw a few years back. And I'm curious what else you think is going to happen.

+ +

JOE: Yeah, I mean, I don't think I disagree. I think Kubernetes itself, the core concept, is, like, it's still changing. But you're right that the excitement about Kubernetes existing has gone down because it's been there for a while. But I feel like the ecosystem is still growing pretty rapidly. Like, the things you mentioned, like Wasm and Istio, and all the tools in that ecosystem that continue to grow, is where I think the interesting things will happen. Like, it's created this new lower-level layer of abstraction that makes it possible to build concepts and technology that could not have existed before.

+ +

KENDALL: Yeah, well, and I'm, you know, talking to people who are working really hard at making short-run ephemeral workloads work better on things like GPUs for the sake of AI, right? Like, I mean, there is some really interesting things happening, and people are doing this in Kubernetes. So, I get that. I agree with that.

+ +

It is interesting that Kubernetes has become sort of the stable thing, and now it's about who can build the interesting add-ons. It's almost like, okay, we've built Half-Life. What is Counter-Strike going to look like? You know. That's a terrible (I'm aging myself.) example. But still.

+ +

VICTORIA: I think it's interesting, I mean, to look at the size of the market for platform engineering right now. In 2022, was 4.8 billion, and it's estimated to be in 10 years $41 billion. So, there is this emerging trend of different platform engineering products, different abstractions on top of Kubernetes. And I wonder what advice you would have for a technical founder who's looking to build and solve some of these interesting issues in Kubernetes and create a business around it.

+ +

KENDALL: Well, okay, let me clarify that question. Are you thinking, I'm a startup, and I need to build my infrastructure, and I'm going to choose Kubernetes. What advice do I need? Or are you thinking, I am founder, and I want to go build on the Kubernetes ecosystem. What advice do you have?

+ +

VICTORIA: Now I want to know the answer to both. But my question was the second one to start.

+ +

KENDALL: One of the things that is hard about the Kubernetes ecosystem is there's not a ton of companies that have made a whole bunch of money in Kubernetes because, as I said, I still think we're actually really early in the adoption curve.

+ +

The kinds of companies that have adopted Kubernetes are the kinds of companies that don't spend lots and lots of money on an infrastructure. [laughs] They're the kinds of companies that are fast-moving, early adopters, or, you know, those first followers, and so they're under $100 million companies for the most part. Where the JP Morgans and Chase are running Kubernetes somewhere in their stack, but they haven't adopted it across the stack to need the biggest, best tools about it.

+ +

So, the first piece of advice that I'd give is, be a little wary. It's still very early to the market. Maybe now is the time to build the thing. When ReactiveOps pivoted to Kubernetes, I think it was six months of having conversations with companies who were just, like, so excited about it, and this is definitely what we want to do. But nobody was doing it yet. You know, it was, we have, like, six solid months of just excitement and nobody actually pulling the trigger. And, you know, we were a little too early to that market. And that was just the people adopting it.

+ +

So, I think there is some nervousness that cloud-native solutions the only people who are really making money in Kubernetes are named Amazon, Google, and Microsoft because it's the cloud providers that are making a ton off of it. Now, there's Rancher. There is StackPointCloud. There's a few others that have had big exits in this space. But I don't think it's actually as big of a booming economy as a lot of people think, in part because EKS is an incredibly amazing product.

+ +

Like, eight years ago, the thing people paid us the most to do at ReactiveOps was just stand up Kubernetes because it was so stinking hard to just get it up and working. And now you click some buttons. Anybody can go do that. So, it's changed a lot, right? And I think be wary when you're entering that ecosystem.

+ +

And then, my advice to the founder that's not building on the ecosystem but just looking to adopt a technology that's going to be a future-proofed infrastructure is just adopt one of the cloud-native platforms. And there are a whole bunch of sort of default best-in-class add-ons out there that you need to throw in. Don't adopt too many because then you have to maintain them forever. That's the easiest way to get started. You can figure out all the rest of it later. But if you go use EKS, or GKE, AKS, you can get started pretty easily and build something that is going to be future-proofed. I don't know, Joe; I'm curious if you disagree with any of that.

+ +

JOE: Well, I think it's interesting to think about who's making money in Kubernetes. Like, I think there might not be as many companies who are doing only Kubernetes and Kubernetes-focused products that are massively successful. But I think because it has had a good amount of adoption and because it's easier to work with something that's standardized, it has helped companies sell things that they wanted to sell anyway. Like, all the Datadog, all the Scalas, the logging companies, they all have Kubernetes add-ons.

+ +

And now everybody is paying Datadog [laughs] to have a dashboard for their Kubernetes cluster. I think they're making more money than they would have been without targeting the market. And so, I think that's really...if you want to get into the market, it's not, like, I'm going to build a Kubernetes product. It's if I'm building operations and an infrastructure product, I should definitely have it work with Kubernetes, and people will want to click and install it.

+ +

KENDALL: So, to be clear, you know, one of the companies that I work with is called Axiom, and they play in the same, you know, monitoring, observability space as Datadog does. And part of what makes Kubernetes interesting in that space is in a microservice environment; there's so much happening. Where are problems being caused? We don't live in a day where I can just run my code, and it tells me that there's an unexpected semicolon on line 23, right? Like, that still happens. You're still doing those things.

+ +

But this microservice talking to that microservice is where things tend to break down. Did I communicate this correctly? What was sent? What was received? Where did it break down? What was the latency? And if you were doing things in the old way back when you were standing it up with, say, Ansible, or Puppet, or something like that, and you were orchestrating all of these cloud virtual machines, you had to really work hard to instrument the tracing and logging and everything involved in order to track what was going on.

+ +

Whereas that's one of the magic things about Kubernetes is with a few of the add-ons or some of the things out of the box with Kubernetes, it's a couple of clicks to get so, so much of the data and have insight into where things are going and what's going wrong. And so, I 100% agree with that.

+ +

Kubernetes is generating a tremendous amount of data. And if you're a data company, it's really nice to have all that come in, and it helps them make money, helps the user of Kubernetes in that situation understand where problems are happening and breaking down. Yeah, there's definitely some network effects of what Kubernetes is doing in that. I completely agree.

+ +

JOE: I think there are also some interesting companies, like, where they make...Emissary, Ambassador, and they have that sort of dual --

+ +

KENDALL: Komodor, is that --

+ +

JOE: Yeah, maybe. They have open source, but then they have a product.

+ +

KENDALL: You're thinking of Ambassador Labs.

+ +

JOE: Yeah. Ambassador Labs, yeah. I guess I don't really know how much money they're making. But I think that's a really interesting concept as people who make open-source things then make a well-supported product built around it.

+ +

KENDALL: Sure. What's interesting is, I think in the VC world, at least right now, and it may pick up again, but post-Silicon Valley Bank nearly caving in, I think that the VC tolerance for, yeah, just go get a billion open-source adopters, and we'll figure out how to monetize later I think that the tolerance for that is a lot lower than it was even six months ago.

+ +

JOE: Yeah, I think you have to have a dual model right from the beginning now.

+ +

KENDALL: Yeah. Agreed.

+ +

VICTORIA: You got to figure out how to make money on Kubernetes before you can. [laughs]

+ +

KENDALL: You know, minor detail. That's why I think services companies in this space still have a lot going for it. Because in order to even be able to sell software to a company using Kubernetes, you half the time have to go stand up Kubernetes for them because it is still that hard for so many people to really adopt it.

+ +

VICTORIA: Yeah. And maybe, like, talking more about, like, when it is the right decision to start on Kubernetes because I think the question I get sometimes is just, is it overkill? Is it too much for what we're building? Especially, like, if you're building a brand-new product, you're not even sure if it's going to get adopted that widely.

+ +

KENDALL: I mean, and I'm [laughs] curious your thought on this, Joe, but there's a good argument to be made that Heroku was enough for the vast majority of founders early on. But the thing is, Kubernetes isn't as hard as it used to be. Going and clicking a couple of buttons on GKE and deploying something into Kubernetes with GKE Autopilot running it's not as easy as Heroku, but it's not wildly far off. And it does substantially future-proof you.

+ +

So, when is it too early? I'm not sure it's ever too early if you have an intention of scaling if you're planning on running some kind of legacy workload, like, things that are going to be stateful. Or maybe WordPress, for example, you don't probably need to deploy your WordPress blog onto Kubernetes. You can do that in your cPanel on Bluehost. I don't actually know if Bluehost even exists anymore, but I assume it's still a thing. I don't know, what would you say, Joe?

+ +

JOE: I agree with that. I think it's a hard first pill to swallow. But I think the reality is that it's very easy to underestimate the infrastructure needs of even an early product. Like, it doesn't really matter what you're building. You're still going to have things like secrets management. You're still going to have to worry about networking. They just don't go away. There's no way you have a product without them.

+ +

And so, rather than slowly solving all those problems from scratch on a platform that isn't designed for it, I think it's easier to just bite the bullet and use one of the managed solutions, especially, as you said, I think it's getting easier and easier. The activation energy from going from credit card to Kubernetes cluster is just getting lower.

+ +

KENDALL: And so, the role of the CTO is just getting easier and easier because they can just adopt the one technology, and it's obviously Kubernetes. And it's obviously Rust, right? [laughter] Yeah, no, I'm with you. And I think if you find somebody who knows Kubernetes inside and out, it's really not going to take them long to get started.

+ +

VICTORIA: Yeah, once again, change management is the biggest challenge for any new innovation coming into adoption. So, I'm curious to talk more about the influence that you need and how you influence others to come around to these types of ideas, like, in the executive suite and with the leadership of a company, especially on these types of topics, which can feel maybe a little abstract for people.

+ +

KENDALL: How you influence them specifically to use Kubernetes, or just how you talk with them about technology adoption in general? Or what are you asking?

+ +

VICTORIA: Yeah, like, how do I get people to not just turn their ears off when I say the word Kubernetes? [laughs]

+ +

KENDALL: Yeah, I mean, I think...so I think that's where it's the technologist's job and the role of the CTO to translate these things into business speak. And that's why I'm using words like future-proofing your infrastructure is because there are companies that...I know one company that made a conscious decision that they were going to try to re-platform every single year, and that is not a good idea or sustainable for the vast majority [laughs] of companies. In fact, I can't think of a single situation where that makes sense.

+ +

But if you can say to the CFO, "Hey, it's going to cost us a little bit more right now. It's going to save us substantially in the long term because this is the thing that's winning. And if we go standardize on Heroku right now, every company does eventually have to migrate off of Heroku. They either go out of business, or they get too big for it." That's the kind of thing that needs to be communicated in order to get people to adopt it.

+ +

They don't care what the word is. They don't care if you're saying Kubernetes; you know, most CFOs understand it about as well as my mom does. My mom tries to bring it up in conversation because she's heard me use it. And she thinks it makes her sound smart, which maybe it does in the right climate.

+ +

VICTORIA: My partner does the same thing. He says DevOps and Kubernetes all the time. I'm like; you don't know what you're talking about. [laughter]

+ +

JOE: Those words do not come up in my house.

+ +

KENDALL: One of my kids asked me to explain Kubernetes. And I do a whole talk, particularly at organizations where understanding Kubernetes is essential to the salespeople's role. And I give a whole talk about the background of how we got here from deploying on some servers in our back room. And, you know, what's different about the cloud, what containerization did, et cetera. And I have this long explanation. And I remember taking a deep breath and saying to my kids, "Do you really want to hear this?" And I had one son say, "Yes, absolutely." And my wife and three of the other kids all stood up and said, "No way," and left the room.

+ +

So, when somebody asks me, "What do you do?" Actually, one of the key relationships I built with some of the early people at GCP when we were partnering closely with them was a person that I met, and I asked, "What do you do for a living?" And he said, "I can tell you, but it's not going to mean anything to you." And I was like, "That's what I say to people." And it turned out he was in charge of, you know, Kubernetes partnerships for Google. I can explain to you what it means and why it's important. But you're not going to be happy that I spent that time explaining it to you.

+ +

VICTORIA: [laughs] That sounds awesome, though. It sounds like you built a server rack just to demo to your children what it was.

+ +

KENDALL: No, no. I just talked back through the history of...that company that I mentioned that built Twitter about five years too early; we had a, you know, we had a server rack in the...literally physically in our closet that was serving up our product at the time.

+ +

VICTORIA: Probably the best demo I ever saw was at Google headquarters in Herndon, and someone had built...They had 3D-printed a little mini server rack that they had put Raspberry Pis onto, and then they had Kubernetes deployed on it. And they did an automatic failover of a node to just demo how it works and had little lights that went with it. It was pretty fun. So maybe you should get one for yourself. [laughter] It's a fun project.

+ +

KENDALL: They remember the things that it enables. They don't remember what it does. And so, when I say so, and so is a client that's using this technology, then they get real excited because they're like, "My dad makes that work." And I'm like, well, okay, that's kind of a stretch, but you get the idea.

+ +

VICTORIA: Yeah, you got to lean into that kind of reputation in your house.

+ +

KENDALL: That's right.

+ +

VICTORIA: And you're like, yes, that's correct.

+ +

KENDALL: That's right. [laughs]

+ +

VICTORIA: I do make Kubernetes. I make all the clouds work, yeah.

+ +

KENDALL: Actually, my most common explanation is Kubernetes is the plumbing of the internet. Unless you're a plumber, you don't care about the pipes. You just want your shit to flush when you use the toilet. You want the things to load when you click your buttons. You don't actually care what's going on behind the scenes, but this is what's orchestrating it increasingly across the internet.

+ +

VICTORIA: So far, we've called Kubernetes WordPress or the toilet. [laughs]

+ +

KENDALL: The plumbing.

+ +

[laughter]

+ +

VICTORIA: You are really good at selling it.

+ +

[laughter]

+ +

KENDALL: Hey, if you want to build a nice, clean city, you need good plumbing. You might not care what the pipes are made of, but you need good plumbing. [laughs]

+ +

VICTORIA: Works for me. On that note -- [laughs]

+ +

KENDALL: Yeah. Right? Right?

+ +

VICTORIA: That's [inaudible 36:41] on a high note. Is there anything else that you'd like to promote?

+ +

KENDALL: With regards to CTO Lunches, we have a free listserv. There are local lunches. If there isn't a local lunch where you are, it's very lightweight to start up a chapter. We often have folks who are willing to sponsor that first lunch to get you going. We do have a paid tier of CTO Lunches. If you want a small back room Slack channel of people to discuss, I think it's $99 a month.

+ +

Yeah, if you're a CTO and/or a senior engineering leader and you want a community of people to process with, be it our free tier or our paid tier, we've got something for you. We're trying to invest in this to build community around it. And it's something we enjoy doing more than almost anything. Come take part.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Kendall Miller.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JkLDbCJa + + ]]> + + Victoria Guido + Kendall Miller + + + 488: Women Who Code with Alaina Percival + https://podcast.thoughtbot.com/488 + a8cd4f1a-45c3-4608-ae39-e6b2ab31591a + Thu, 17 Aug 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Alaina Percival is the Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers. + +This discussion offers a detailed look into the women in tech movement, the importance of community, and the drive to create a more equitable industry. It serves as a reflection on both the strides made in fostering diversity and the work still needed to create a truly inclusive technology field. + 38:40 + no + + + Alaina Percival is the Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers. +Alaina delves into the origin and mission of Women Who Code, highlighting its community building, free technical events, and collaboration with companies to promote diversity in hiring. Victoria adds her personal experience with the organization, emphasizing its positive impact on her career. +They discuss the challenges faced while expanding Women Who Code, including the need for systems and processes to manage growth. Alaina recounts stories of discrimination faced by women in tech and stresses the need for continued support and encouragement. The conversation also touches on the financial benefits of diversity and the alignment of Valor Ventures with Women Who Code's values. +This discussion offers a detailed look into the women in tech movement, the importance of community, and the drive to create a more equitable industry. It serves as a reflection on both the strides made in fostering diversity and the work still needed to create a truly inclusive technology field. +__ +Women Who Code (https://www.womenwhocode.com/) +Join the Women Who Code Slack! (https://docs.google.com/forms/d/e/1FAIpQLSctj9HJr-5yadDbKYygBYBfNUWmjgODlkp8lgLou26AedIkuQ/viewform) +Women Who Code Podcast (https://www.womenwhocode.com/podcast) +Follow Women Who Code on Facebook (https://www.facebook.com/womenwhocode), LinkedIn (https://www.linkedin.com/company/women-who-code/), Instagram (https://www.instagram.com/womenwhocode/), GitHub (https://github.com/WomenWhoCode), Twitter (https://twitter.com/WomenWhoCode), or YouTube (https://www.youtube.com/c/WomenWhoCodeGlobal?themeRefresh=1) +Follow Alaina Percival on LinkedIn (https://www.linkedin.com/in/alainapercival/) or Twitter (https://twitter.com/alaina). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with me today is Alaina Percival, Venture Partner at Valor Ventures and Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers. Alaina, thank you for joining us. +ALAINA: Thank you so much for having me. I'm thrilled to be here. +VICTORIA: I'm thrilled to have you as well. I reached out. As you know, I was previously a Director of Women Who Code D.C. and helped to organize our DevOps and cloud series when I lived there. And it really had a huge impact on my career. So, I'm just super psyched to talk to you today. What's going on in your world, Alaina? +ALAINA: So, in addition to my full-time job of working with Women Who Code, I'm also a mom of two young children, and so they're currently three and five. And so, it's summer. We've got summer camp. Every week is a different program with different details and things that you have to read and stay up on. It's a lot of additional project management added on over the summer. I'm looking forward to getting back to the school year, where I can kind of focus on just one role. +WILL: That's amazing. And I can totally relate because I have a four, a three, and a one-year-old. Yes, it's a different story when you have to, like you said, project manage around them. So, that's amazing that you're wearing so many hats, and you're doing that. Hats off to you. +ALAINA: Same to you. [laughter] +WILL: Victoria, what about you? What's going on in your world? +VICTORIA: Well, it is summertime at the beach, so all the kids are out. [laughs] It's busy. But that means that you know, the weather is warming up. It's tempting to try to go surfing again, so we'll see if that ends up happening anytime soon. But no, I'm hanging out. I'm local. I'm kind of done traveling for a little bit, so not until I go out to Outer Banks to visit my baby niece and nephew in August. So that's where I'm at right now. I'm kind of hunkered in trying to survive without air conditioning here and get through the summer. [laughs] +WILL: You don't have AC? +VICTORIA: I do not. Yeah, there's a lot of houses around here just never were built with it. I have heat, but I have no air conditioning. +ALAINA: Are you being hit with the heat wave that's happening? +VICTORIA: Yes. But it's still very mild. We're spoiled here for sure on weather. +WILL: [laughs] +VICTORIA: It's like 77, and I'm like, ugh, it's so hot. [laughs] +WILL: I'm in Florida, and it amazes me. So, I got up early, around 7:00 o'clock, to go out for a run, and it's, like, 87 degrees. And it feels like almost 100 at 7:00 a.m. And I'm like -- +VICTORIA: Oof. +WILL: How? [laughs] Like, the sun is barely out, and it's already reaching 100. So yeah. +ALAINA: I feel you. I'm in Atlanta. Yesterday, I had an in-person meeting. Typically, we're entirely remote. So, I was wearing real pants [laughs], and it was a hard day. We're not quite as hot as Florida. We are in the low 90s. But yeah, this weather is for real. +WILL: Yes. [laughter] +VICTORIA: That is the...yeah, working in person again in a hot climate. [laughs] I forgot the challenges of that of, like, trying to navigate life while having to be fully clothed is difficult in that kind of weather. So, I'm glad. I hope you all find some ways to stay cool and to entertain your children [laughs] so that you have some sanity and can get through the summer. I've also been really interested in the European model of just taking five weeks off in the summer. Doesn't that sound nice? +WILL: Yes. [laughs] +ALAINA: Yeah. I started my career off in Germany. I worked for Puma. Their headquarters is right outside of Nuremberg in a town called Herzogenaurach. And people really do take the whole month off August. And, in fact, you would even separate out the salaries. So, you got something called urlaubsgeld, which was vacation money. So, you would get kind of a little bonus going into August, and then everybody would take off. So, I agree with you. We should be doing that. +VICTORIA: Yeah, we should be doing that. And I'm so excited. Maybe we can segue into, like, your background and how you got started. How did you go from there to founding Women Who Code? +ALAINA: Yeah, so after working at Puma, I somewhat came back to the United States. I did a dual degree program, an MBA where I was studying between Atlanta, so I could get back in the United States, spend some time with my family, and then also the Sorbonne in Paris. And I did an MBA and a degree in organizational management, Master's in organizational management. +Then I went to work for really small ones, performance wear company. And that was more, like, a startup because you really had to think outside of the box. You know, you're a small $10 million a year company, and Nike and Mizuno, you know, these big companies are your competitors. +So, I had the opportunity to move out to San Francisco. It was one of the cities that was always on my list of, hey, if you get a chance to do it, go for it. And I did. So, I moved out there, and I kind of hit a bit of a wall with my career, an unexpected wall because up until that point, I had just this really, you know, successful early career. I got out there, and they're, like, Puma. You know, you haven't worked for Microsoft, or Twitter, or Facebook, or Google. Who are you? +So, I started learning to code just to transition my skill set to help me understand the culture and the language and just getting more involved in the tech community. And I was still struggling a little bit in figuring out my transition pathway and got more and more involved with Women Who Code and started, you know, spending my nights and weekends. +And finally, I was at a small startup that had gotten acquired, so I had my official tech credibility. And I went to work for one of the top technical recruiting firms, executive recruiting firms in the Bay Area, as their head of developer outreach. And I largely chose that role because they were allowing me to run their philanthropic arm, and I focused that around supporting underrepresented communities, you know, get a leg up in the tech community. And then, while I was there, I was working with CTOs, vice presidents of engineering, directors of engineering on a day-to-day basis. +And I started learning what they were doing in their career to help develop and cultivate the success that they were having, and I started bringing that knowledge and programming into Women Who Code. And that's where our mission around seeing diverse women excel in technology careers came about is, you know, that piece of retaining and seeing diverse women excelling was an area that wasn't really the focus at the time. And I feel like it sounds funny now because it's such a big piece of conversation. But that was the beginning. +VICTORIA: Yeah, it's so interesting that your experience from being in a startup and then how you moved up into being really involved in the hiring and the process of how women...how anyone would actually, like, move up in their career led you to have that background to found Women Who Code. And for people who maybe don't know, [laughs] no, I certainly know what it is. Can you talk a little bit more about what it offers to women and what it offers to companies who are looking to hire diverse women? +ALAINA: For individuals, we are the largest and most active community of diverse technologists. We have close to 350,000 members. We're serving members across 147 countries. And we're producing close to 2,000 free technical events every single year, so that's about an average of 5 per day. +Once those events take place, if you happen to miss them if you happen to not be in a location where they're having them in person, we're putting a lot of that on our YouTube channel. So, you can go back when you have time, when you're available, still invest in yourself and learn some of these technical and career-related skills. +You can also, you know, when you think about, say, the 2,000 talks that are being delivered at Women Who Code, the majority of them are being led by and delivered by diverse technologists. So, we're creating role models and helping people who are on their career path have a sense of belonging, see a pathway to success. People who are thinking about the career path see themselves represented as thought leaders, as leaders in the tech industry. And that sense of belonging, that sense of drive, is just so important to be able to continue on in your career. +But we work with companies. So, Women Who Code is dedicated to accessibility. All of our programming is free or scholarship accessible. And so, what we do is we work with companies, and we do this for two reasons: for programmatic reasons. Because we know that if companies develop strong diversity, equity, and inclusion, and belonging practices, that we will reach our mission and vision so much faster than if we work with every individual in the world. But it also creates an opportunity for us to be able to support the community. +So, we work with companies to sponsor Women Who Code to donate to support Women Who Code's programming. We have our first-ever walk coming up, so a walk, run, roll called Women Who Code to the Finish Line. And we're going to be having that in September of this year. And that's going to be an opportunity for the stakeholders. You know, often, people who aren't in our community but absolutely support us say, "How can we help?" And so, companies can form teams and go and walk, run, roll to change the face of the tech industry. +Right now, we're also in a position where the tech industry has been doing a lot of layoffs, so there's a lot of instability. And so, when that happens, our programming thrives. So, people are coming to our events in high numbers. People are participating in our programming. People are visiting our job board. It's the time when companies are stepping back and pulling back on their funding and things like that. +So, I just encourage every single company to...if you have a great technical job open, make sure you're sharing it with the Women Who Code community because we have incredible technologists. They deserve access to companies that are willing to support them and the best roles that are available in the industry today. +WILL: Alaina, I just want to honestly and truly say this, what you're doing is amazing. Having a background in nonprofit, over 140 companies, over 300,000 in your membership, and it's an international nonprofit. It's truly amazing what you're doing and helping women find their role and help them become better. +I'm truly just blown away by, you know, you started in September 2011, so you're coming up on 12 years this year. And just 12 years as a nonprofit and doing this, share with us how was it received at the very beginning? Because I feel like that was a different time that we're in right now. +ALAINA: Yeah, it started off as a meetup, just a community group in San Francisco. And it was incredible. It felt like our little secret. And we were spending time together. We were learning. We were building connections. And just it was this incredible community. And then, the world started talking about, hey, we need to teach girls to code. We need to teach women to code. And we were this community of people in the industry. Our average age at Women Who Code is 30, so 50% of our members are currently in technical roles. +So, we had this moment of, hey, we need to elevate the voice of those who are in the industry right now, alongside teaching girls to code and teaching women to code. Because if you miss out on that, it actually becomes a threat to the women in the industry who, every time you hear "Teach women to code," you're saying she doesn't already know how to do it. And we had so many people in our community who already did and already had to kind of prove themselves on a regular basis or constantly underestimated. +In the early years, a Women Who Code leader who told me that she was managing a booth at a conference, and everyone was an engineer except for one recruiter, and the recruiter's name was Brian. Someone walked up to her and said, "Are you Brian?" Because it was easier to imagine that her name was Brian than that she was one of the engineers at the table. +And so, kind of going through this, we said, hey, we need to elevate our voices. We need to elevate the needs of women in the industry. And it feels being in it day by day, that nothing's happening. But when you look back over 13-15 years, you see that parental leave policies have improved significantly, that we see numbers in leadership going up across the board, that it's part of the conversation that relatively standard and tech companies to have DEI roles within the organization, within the people team. And so, these are not enough. It's just the beginning. But it is a lot that's taken place over the past 10 to 15 years. +VICTORIA: I agree. And I can relate as someone who was a project manager working in a technology space. Was it back in, like, 2013 or something? And you'd go to tech meetups, and most likely, I would be the only woman there. [laughs] But then, with Women Who Code, my friend invited me to go to a Ruby event, and it was, you know, all women. [laughs]. There was a woman who was even giving the instruction. And so, that was just a really cool feeling after having been out networking and feeling kind of isolated to really find a lot of people who are similar to you. +And I remember part of the narrative at that time when we were talking about increasing inclusion and diversity in technology; there was a narrative that, well, there just aren't as many women in tech. And being a part of Women Who Code, I could be able to, like, answer back to say, "Well, there actually is a lot of women in tech." +And it's the bigger problem that women would get started because they're interested in the industry and having good careers, but then they would fall out midway. So, there just wasn't enough progression in their careers. There wasn't enough support on the parental leave side, or there just wasn't enough community to keep people interested, like, when you're the only one. And many of our members they were the only women in their company, and then Women Who Code was where they found people they could really connect with. +So, I just think it's interesting that it solves a particular problem where we would have women who are just interested in learning to code who would come to our events. And then, we had women who were actively coding in their jobs and teaching others in these leadership roles within the community to advance their own careers. And that's certainly what I did, and how I broke into executive leadership was, like, I'm a director at Women Who Code and I've got all this other leadership experience. And I'm bringing that network with me. It really increases your value to employers and demonstrates your leadership abilities. +ALAINA: Yeah, I couldn't agree more. The program which we kind of fell into, it's our volunteers, is our program that I'm actually most proud of at Women Who Code. And it's probably because I get to know our volunteers because I know so many people's lives and careers are impacted by our programming. +But that leadership development, that practice-based leadership that our volunteers are able to obtain, the doors that get open, and just like you said, it opened doors. And I remember it hit me when one of our volunteers told me she was interviewing with SpaceX. And one of the reasons they said they were excited to talk to her was because of her Women Who Code leadership experience. And I just thought to myself, we're doing something right. [laughs] +VICTORIA: Yeah, absolutely. And I think maybe part of Will's question before, too, is, like, did it always feel like you were doing something right? Or did it all just come together naturally? Or what kind of bumps did you initially hit when you were getting things off the ground? +ALAINA: Yeah. When we first got started and realized, hey, we need to make Women Who Code more accessible, we were doing everything in a very manual way. We needed to adapt to building systems and processes, and that's not the fun part of running a volunteer organization. And when you're moving so fast, it means slowing things down a little bit to be able to make sure that you can do things better, more consistently, more efficiently, but it's so critical. +And so, I would say we kind of launched outside of the Bay Area in a couple of cities. And it just snowballed until we expanded into 20 to 40 more cities within probably a year outside of that. And we just really needed to catch up on creating systems and processes, which is not beautiful at all, but it's an important part of running a real business, a real company. +WILL: That's amazing. First off, I just want to say I am so sorry that the world we live in looks down upon women or anybody. So, I'm just so sorry that, like, the story you said about Brian, asking the lady that. I feel like that's so disrespectful. I am so sorry if you ever got treated that way or anything like that. +And so, I was going to ask this question, and then I kind of answered it. But the question was, do you think women are at a place to where kind of equal in tech? And I kind of answered my own question and said, "No." And so, I want to reframe it. What do you think it will take to continue to help the women get to that level of where it should be? +ALAINA: It's going to take a lot of things. But the fastest and easiest way to create more equality for women and girls in the tech industry is by investing and supporting the incredible talent that is in the industry today. We need them to thrive. We need them to stay in their careers. We need them to become leaders with power and influence to create more equity in the industry so that when future generations are coming in, they're coming into an industry that is less broken for them, that is more welcoming, that shows and demonstrates more opportunity. +This is one of the most exciting and innovative industries to be a part of. So many things are being shaped and built for the first time that are systems that are going to be the foundations for years or centuries to come. And so, it's more important now than ever for us to be thinking about bringing equity into that so we're not dealing with technical debt, where we're starting from a system that has more equality to it. +VICTORIA: I really appreciate that perspective. And I'm curious how that relates to your work at Valor Ventures as well. +ALAINA: Valor Ventures is very aligned with the values of Women Who Code, which is why I chose it. I am passionate about creating more equality and opportunity for diverse individuals to thrive and succeed in general but via the tech industry. And so, when I move into focusing on entrepreneurs and focusing on seeing diverse entrepreneurs succeed in building thriving organizations, I see an opportunity to have someone who will be thinking earlier about the policies and the practices that are going to build more equitable teams, products that are really for all of their users. +VICTORIA: I think that's a great mindset. And it reminds me that when we talked about, like, the importance of diversity, and equity, and inclusion, that it's not purely a moral thing, even though morally we know we want to support and be inclusive, but that it's also good business strategy [laughs], just by the value of having different perspectives and different types of people, and then being able to have your products be accessible for a diverse group as well, right? +ALAINA: Yeah, the data shows teams that are diverse are smarter. Companies that have women represented in leadership they have a stronger ROI. There's business reason behind it. There's certainly a social-moral reason that it just should take place. But, you know, if you need to come back to your shareholders or your investors, there's financial data around it. +WILL: Yeah, I totally agree on all that, like, yes, yes, yes, yes, yes. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +WILL: What have you seen hold back women in this space? And the reason I'm asking this question is because there are some biases out there, and, at times, we don't even realize it. For example, I know we have parental leave. And before I had kids, I didn't understand parental leave at all. But then, now that I have kids, I'm like, oh, it is not even close to being enough time during that time, you know, four or five hours of sleep at night, just all those things. +So, in your experience, what have you seen? And hopefully, we can use this as a learning opportunity for anybody that just may be blind to it. What have you seen that kind of holds it back? +ALAINA: That's holding back, like, implementing specific policies and practices or? +WILL: Yes, holding back the policies, or maybe women not being as prevalent in tech roles any of those areas. +ALAINA: So, sort of two different approaches with that is I'm optimistic. I think most companies, yes, they care about the bottom line, but they want to be doing the right thing if it's easy. Leaders like me we need to put pressure on companies making better decisions. But also, industry leaders and organizations out there need to be able to make it easier for companies to make the decisions that are going to create more equity inside of their organization. +I know that's taking the responsibility off of them a little bit. But companies won't make commitments. They won't do the hard things if they don't know how to do it. And so, the easier that we can make it for them to make the right decision, the more likely they are to make the right decision. +VICTORIA: I think that people want to do the right thing if it's easy is a really succinct way to explain a lot of, like, social and moral [laughs] issues right now, right? Most people generally want to do the right thing, but it can be complex. +I'm curious about, speaking of complexity, for Women Who Code, going through, you know, being an organization that was built around in-person events, and then having COVID happen, so, like, what were some of the challenges of the last few years and changes that you experienced along the way? +ALAINA: Yeah, when COVID hit, that was a big moment for the whole world. It was certainly really hard for organizations that rely on in-person activities. You know, our major conference supplied a third of our operating revenue. Our members were going to, you know, close to 2,000 in-person events. And so, we had to adapt just like everyone else. The organizations and the companies that adapted were the ones that thrived. +So, we had to completely retrain all of our volunteers from doing in-person events to be able to create digital events for our community. We had to figure out how to produce major events, and conferences, and hackathons and do it in a remote way. And then, of course, there's the day-to-day that absolutely everyone had, and that was, you know, just your team went from meeting in person to everyone being remote. +And some of the great things that came out about that is we were serving members in about 26 countries and about 80 cities, and now we serve members in 147 countries. It just made it accessible that if you don't happen to be in a location where an event is happening and you also don't happen to have childcare, be able to participate, that you are still able to participate in an online setting. +And then, what we saw with being able to start moving more of, you know, those talks that were being delivered to our YouTube channel, it then became even more accessible. People spent about five years of life watching our YouTube trainings, and that's time people are investing in themselves. And when I say they did it, and I'm talking about in 2022. So, our YouTube channel, our trainings, they continue to grow, and then our online events continue to happen. But luckily, now we are able to start going back in person. +And it's, again, just so amazing to be able to see the people you haven't seen in a long time, feel that feeling that is just a little bit different for an in-person event. +WILL: That's amazing. So, from, say, 2019, 2020 to now, it went from 80 countries to over 140, just because of the pivot to go more, like, YouTube and tech. Is that kind of what you're saying about the growth of it? +ALAINA: Yeah, so about 80 cities, so about 25 countries to serving members in 147 countries. +WILL: That's amazing. +ALAINA: Yeah, a tremendous amount of growth and creating accessibility around the globe. Previously, we were really only able to focus on tech hubs that had an ecosystem to support it. But, you know, just because you're from a rural area of your state or from a country in the Global South, you still deserve access to this incredible community and all of the free accessible programming that Women Who Code has to offer. +When we have a conference, we have people from 88 countries participating. And when you sign into the networking session, you're going to hop on the phone with someone from Nigeria, someone from Bangladesh, someone from your same city, and it's just such an incredible experience to be able to have that global focus and reach. +WILL: Wow, that is so amazing. So, let's talk about right now. What does your next milestone look like, you know, in the next six months or next year? What does that look like for you? +ALAINA: As I mentioned before, one of the big challenges we've had this year is our programming is going so, so well, but our funding has pulled back a little bit. And so, we're working to diversify our revenue strategy a little bit and have a traditional nonprofit walk that we've never done before. And it's a remote walk, so anyone all over the world can participate just like you can with our digital events. +But this has been something new for us. Because when we went through it during COVID, again, you know, you'd get on the call with all of your partners. You know, the world is going through something, and you kind of say, oh yeah, we're in it together. But you don't see the grace that you saw in 2020 and sort of the camaraderie, and we're in this together, and we're going to give you space and support you, you know, in every way that we can that, you know, is just really missing this time around. You know, we have members who absolutely need support in their careers right now. And so, it's navigating through something different. +VICTORIA: Yeah. And I guess talking more about inclusivity, like, we have all this free content, and it is Women Who Code. But I remember when I was an organizer, I had a few people ask me, "Well if I'm a man, can I come to your event?" And I was like, "Yes, it's open to everyone," right? Like, it's promoting women, and it's about women growing in their careers. And certainly, if that's not also your intention with attending the event, you should keep that in mind and make sure you're leaving space for other people. +But I also really appreciated that it's open for everyone and that it's open for everyone who is in the women umbrella, and being intentional about that, and that it's inclusive of everyone who relates to being a woman, right? +ALAINA: Yeah. Women Who Code welcomes all genders. We, you know, really struggle with our name from a brand perspective because it isn't as inclusive as we'd like it to be. So, actually, after we say our name, we try not to repeat the word women anywhere else. From the beginning, been dedicated to having an open, accessible community. But we definitely require, you know, that you are following our code of conduct, that you're there for the intended purpose of the event. And we want to make sure that we're protecting our community. +VICTORIA: Well, I really appreciate that. And I appreciate...it sounds like a value organization that I'm with. I always look for those things that that's what we're really promoting. +There's been so many changes that have happened with Women Who Code and in your career. If you could go back in time and give yourself some advice when you were first getting started, what would you tell yourself? +ALAINA: If I was going back and thinking about what I would tell myself in the beginning, I'd probably tell myself to focus on data sooner. Coming from the history of being a meetup group to transitioning to being a global nonprofit, we dragged our feet around focusing on data impact, and really, it's because we're constantly doing so much programming. We're always doing so many things, and anything you add on is an extra thing to do. And so, I would say focus on the data much sooner. +VICTORIA: I can speak to there being a lot of events. I remember back in the heyday in D.C., it was, like, algorithms on Tuesdays and Ruby on Thursdays, and then next week, it would be DevOps. And there was just always something going on. And I thought that was so cool. And I really appreciate just really everyone who is involved in putting on those programs. I really want to emphasize, too, like, the value for companies working with Women Who Code. And what do they get out of the partnership, and how can they really engage with the community? +ALAINA: Yeah. So, companies that work with us, it's a partnership. They are there to support the community, and that's what they have to do to really develop trust. And we're going to make sure that we're guiding them in that process. So, if we see an opportunity for them to engage in a more authentic way, we're going to point that out. But companies are often hiring from our community; that's one of the big reasons, not just through our job board because our members are unicorns. They're diverse technologists, and everyone wants to hire them. +And so, you can just say, "Hey, come work for me." But really, they want you to explain who's on the team? What are the exciting projects, and what are the exciting technologies that your company is building? So that they can actually identify that your company is an organization that they would want to work for before just applying for a job. And that's what a lot of our partnership creates space for. +So, maybe getting an opportunity to join our podcast and tell the story and get to know some of the diverse leadership team or diverse engineering team, learn about some of your, like, commitment to DEI and things like that. Because when a senior engineer receives multiple job outreaches, they're going to respond to the one that they've heard of, that they already know is a good company, that they know is supporting and investing in building equity into the tech ecosystem. That's going to go a long way in them deciding to reply. +WILL: That's awesome. Earlier, you mentioned being inclusive of all the members. I think I know the answer, but I just want to double-check. If I want to volunteer, am I able to volunteer at Women Who Code? +ALAINA: Yes, absolutely. If you visit our website...and we just updated our website, so I encourage everyone to go visit womenwhocode.com today. It's looking different than it has over the past five years. There's a sign-up to volunteer. You would be absolutely welcome, Will. +WILL: Awesome. And, as a volunteer, what would that look like? What could I get involved in? What areas? +ALAINA: You could decide to be a speaker. You could apply to be a network leader. You could become a lead in a particular technology area. We have six technical tracks. Our tracks are cloud, data science, Python, mobile. When [inaudible 32:53] hears about it, we will have emerging technologies track that was expanded from our blockchain community this year. And then, we also have a career track as well. So, you can become a lead focused on one of those particular areas in our digital communities. You can get engaged with the Women Who Code community in many different ways. +We also have some really cool programs like mentor me and buddy system, so getting involved in those. Building long-form connections or long-time connections with individuals in the community really helps to create a sense of belonging and start to build trust and an opportunity to exchange knowledge. +VICTORIA: I always really appreciated people who were, like, "Do you need a space to host your meetup?" Or "Do you want us to buy you pizza for your meetup?" [laughs] Those are very easy ways to engage. And it's true that the membership does see and pay attention to, like, who is regularly getting involved in committing to this, and it makes a difference in your brand and reputation. +ALAINA: Absolutely. The companies that work with us absolutely hire from the Women Who Code community. I'll give two examples. So, one of the most exciting examples was we had an event at a company, and they sort of were connecting in an authentic way, not, like, an interview way, but they essentially were doing an early interview with people who were there. And so I remember that it took place on Tuesday, and they had a job offer on Friday at the company that they were at. So, they were just able to move so quickly and hire someone from our community. +And then, ages ago, Snapchat was at our first-ever conference, and they had hired four or six people at that event. And it was just so cool to see that we're not a recruiting agency, so we really just rely on either individuals or companies to tell us when they have these amazing career outcomes. So, every time we hear about it, it's always exciting to me. +VICTORIA: That's super cool. And I wonder, what is the thing you're most excited about coming up for Women Who Code this year? +ALAINA: We have CONNECT Asia taking place later on this year, and so that's our major technical conference with a focus in the Asia market. It's going to be just really, really exciting. We haven't had one since pre-COVID. It's still going to be a remote event. We had CONNECT LATAM, so our first-ever conference focused on Latin America last year. And this year, it's focused on Asia. So, it's really exciting to get back and provide some support to our regional audiences and really showcase some of the incredible talent and leadership coming out of those regions. +WILL: That's amazing. So, the question I have for you, and it's easy to assume this question, but I want to hear from you because I know you talked about, at the beginning, how it was when you started the nonprofit. But what is the wind in your sails? Like, what keeps you motivated and going? It sounds like it's an easy answer, but just from your heart, what motivates you? +ALAINA: Oh, it is absolutely the stories that I hear, like I said, especially from our volunteers. So, the Mexico City volunteer who, in under a year, told me her salary increased 200%. The director from Toronto, you know, when she stepped up, was an individual contributor, and under one year, she made it to director level, and today she's a vice president. +So, when I think of the career impacts that are taking place for our members, and every single time I hear about it, it drives me to wake up. It drives me to work harder. It drives me to deliver better program and just makes me completely connected to what we do as an organization. +VICTORIA: What a great benefit. And for myself, personally, it absolutely has been a factor in the last, like, two jobs I've gotten. [laughs] They're like, "Oh, you are a director at Women Who Code? That's so interesting." So, I really appreciate everything that you've done and happy to be a part of that. And my personal network, I know many women who have been through that and benefited immensely from having that networking community. And really, even just being able to see yourself and know that you belong in the industry, I think, is really, really important. +ALAINA: I'm sure I'm going to be telling your story the next time someone asks me. +[laughter] +VICTORIA: That's great. No, please do. And let's see; we're wrapping up at the end of our time here. Is there anything else that you would like to promote? +ALAINA: Yeah, please visit womenwhocode.com. If you have technical jobs available, please post them to the Women Who Code job board. Again, it's just womenwhocode.com/jobs. Join our community. Check out our amazing, new, beautiful website, and follow us on social media @WomenWhoCode. +VICTORIA: Love that. Thank you so much for joining us today. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you can find me @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Alaina Percival. + + + Alaina Percival is the Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers.

+ +

Alaina delves into the origin and mission of Women Who Code, highlighting its community building, free technical events, and collaboration with companies to promote diversity in hiring. Victoria adds her personal experience with the organization, emphasizing its positive impact on her career.

+ +

They discuss the challenges faced while expanding Women Who Code, including the need for systems and processes to manage growth. Alaina recounts stories of discrimination faced by women in tech and stresses the need for continued support and encouragement. The conversation also touches on the financial benefits of diversity and the alignment of Valor Ventures with Women Who Code's values.

+ +

This discussion offers a detailed look into the women in tech movement, the importance of community, and the drive to create a more equitable industry. It serves as a reflection on both the strides made in fostering diversity and the work still needed to create a truly inclusive technology field.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Alaina Percival, Venture Partner at Valor Ventures and Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers. Alaina, thank you for joining us.

+ +

ALAINA: Thank you so much for having me. I'm thrilled to be here.

+ +

VICTORIA: I'm thrilled to have you as well. I reached out. As you know, I was previously a Director of Women Who Code D.C. and helped to organize our DevOps and cloud series when I lived there. And it really had a huge impact on my career. So, I'm just super psyched to talk to you today. What's going on in your world, Alaina?

+ +

ALAINA: So, in addition to my full-time job of working with Women Who Code, I'm also a mom of two young children, and so they're currently three and five. And so, it's summer. We've got summer camp. Every week is a different program with different details and things that you have to read and stay up on. It's a lot of additional project management added on over the summer. I'm looking forward to getting back to the school year, where I can kind of focus on just one role.

+ +

WILL: That's amazing. And I can totally relate because I have a four, a three, and a one-year-old. Yes, it's a different story when you have to, like you said, project manage around them. So, that's amazing that you're wearing so many hats, and you're doing that. Hats off to you.

+ +

ALAINA: Same to you. [laughter]

+ +

WILL: Victoria, what about you? What's going on in your world?

+ +

VICTORIA: Well, it is summertime at the beach, so all the kids are out. [laughs] It's busy. But that means that you know, the weather is warming up. It's tempting to try to go surfing again, so we'll see if that ends up happening anytime soon. But no, I'm hanging out. I'm local. I'm kind of done traveling for a little bit, so not until I go out to Outer Banks to visit my baby niece and nephew in August. So that's where I'm at right now. I'm kind of hunkered in trying to survive without air conditioning here and get through the summer. [laughs]

+ +

WILL: You don't have AC?

+ +

VICTORIA: I do not. Yeah, there's a lot of houses around here just never were built with it. I have heat, but I have no air conditioning.

+ +

ALAINA: Are you being hit with the heat wave that's happening?

+ +

VICTORIA: Yes. But it's still very mild. We're spoiled here for sure on weather.

+ +

WILL: [laughs]

+ +

VICTORIA: It's like 77, and I'm like, ugh, it's so hot. [laughs]

+ +

WILL: I'm in Florida, and it amazes me. So, I got up early, around 7:00 o'clock, to go out for a run, and it's, like, 87 degrees. And it feels like almost 100 at 7:00 a.m. And I'm like --

+ +

VICTORIA: Oof.

+ +

WILL: How? [laughs] Like, the sun is barely out, and it's already reaching 100. So yeah.

+ +

ALAINA: I feel you. I'm in Atlanta. Yesterday, I had an in-person meeting. Typically, we're entirely remote. So, I was wearing real pants [laughs], and it was a hard day. We're not quite as hot as Florida. We are in the low 90s. But yeah, this weather is for real.

+ +

WILL: Yes. [laughter]

+ +

VICTORIA: That is the...yeah, working in person again in a hot climate. [laughs] I forgot the challenges of that of, like, trying to navigate life while having to be fully clothed is difficult in that kind of weather. So, I'm glad. I hope you all find some ways to stay cool and to entertain your children [laughs] so that you have some sanity and can get through the summer. I've also been really interested in the European model of just taking five weeks off in the summer. Doesn't that sound nice?

+ +

WILL: Yes. [laughs]

+ +

ALAINA: Yeah. I started my career off in Germany. I worked for Puma. Their headquarters is right outside of Nuremberg in a town called Herzogenaurach. And people really do take the whole month off August. And, in fact, you would even separate out the salaries. So, you got something called urlaubsgeld, which was vacation money. So, you would get kind of a little bonus going into August, and then everybody would take off. So, I agree with you. We should be doing that.

+ +

VICTORIA: Yeah, we should be doing that. And I'm so excited. Maybe we can segue into, like, your background and how you got started. How did you go from there to founding Women Who Code?

+ +

ALAINA: Yeah, so after working at Puma, I somewhat came back to the United States. I did a dual degree program, an MBA where I was studying between Atlanta, so I could get back in the United States, spend some time with my family, and then also the Sorbonne in Paris. And I did an MBA and a degree in organizational management, Master's in organizational management.

+ +

Then I went to work for really small ones, performance wear company. And that was more, like, a startup because you really had to think outside of the box. You know, you're a small $10 million a year company, and Nike and Mizuno, you know, these big companies are your competitors.

+ +

So, I had the opportunity to move out to San Francisco. It was one of the cities that was always on my list of, hey, if you get a chance to do it, go for it. And I did. So, I moved out there, and I kind of hit a bit of a wall with my career, an unexpected wall because up until that point, I had just this really, you know, successful early career. I got out there, and they're, like, Puma. You know, you haven't worked for Microsoft, or Twitter, or Facebook, or Google. Who are you?

+ +

So, I started learning to code just to transition my skill set to help me understand the culture and the language and just getting more involved in the tech community. And I was still struggling a little bit in figuring out my transition pathway and got more and more involved with Women Who Code and started, you know, spending my nights and weekends.

+ +

And finally, I was at a small startup that had gotten acquired, so I had my official tech credibility. And I went to work for one of the top technical recruiting firms, executive recruiting firms in the Bay Area, as their head of developer outreach. And I largely chose that role because they were allowing me to run their philanthropic arm, and I focused that around supporting underrepresented communities, you know, get a leg up in the tech community. And then, while I was there, I was working with CTOs, vice presidents of engineering, directors of engineering on a day-to-day basis.

+ +

And I started learning what they were doing in their career to help develop and cultivate the success that they were having, and I started bringing that knowledge and programming into Women Who Code. And that's where our mission around seeing diverse women excel in technology careers came about is, you know, that piece of retaining and seeing diverse women excelling was an area that wasn't really the focus at the time. And I feel like it sounds funny now because it's such a big piece of conversation. But that was the beginning.

+ +

VICTORIA: Yeah, it's so interesting that your experience from being in a startup and then how you moved up into being really involved in the hiring and the process of how women...how anyone would actually, like, move up in their career led you to have that background to found Women Who Code. And for people who maybe don't know, [laughs] no, I certainly know what it is. Can you talk a little bit more about what it offers to women and what it offers to companies who are looking to hire diverse women?

+ +

ALAINA: For individuals, we are the largest and most active community of diverse technologists. We have close to 350,000 members. We're serving members across 147 countries. And we're producing close to 2,000 free technical events every single year, so that's about an average of 5 per day.

+ +

Once those events take place, if you happen to miss them if you happen to not be in a location where they're having them in person, we're putting a lot of that on our YouTube channel. So, you can go back when you have time, when you're available, still invest in yourself and learn some of these technical and career-related skills.

+ +

You can also, you know, when you think about, say, the 2,000 talks that are being delivered at Women Who Code, the majority of them are being led by and delivered by diverse technologists. So, we're creating role models and helping people who are on their career path have a sense of belonging, see a pathway to success. People who are thinking about the career path see themselves represented as thought leaders, as leaders in the tech industry. And that sense of belonging, that sense of drive, is just so important to be able to continue on in your career.

+ +

But we work with companies. So, Women Who Code is dedicated to accessibility. All of our programming is free or scholarship accessible. And so, what we do is we work with companies, and we do this for two reasons: for programmatic reasons. Because we know that if companies develop strong diversity, equity, and inclusion, and belonging practices, that we will reach our mission and vision so much faster than if we work with every individual in the world. But it also creates an opportunity for us to be able to support the community.

+ +

So, we work with companies to sponsor Women Who Code to donate to support Women Who Code's programming. We have our first-ever walk coming up, so a walk, run, roll called Women Who Code to the Finish Line. And we're going to be having that in September of this year. And that's going to be an opportunity for the stakeholders. You know, often, people who aren't in our community but absolutely support us say, "How can we help?" And so, companies can form teams and go and walk, run, roll to change the face of the tech industry.

+ +

Right now, we're also in a position where the tech industry has been doing a lot of layoffs, so there's a lot of instability. And so, when that happens, our programming thrives. So, people are coming to our events in high numbers. People are participating in our programming. People are visiting our job board. It's the time when companies are stepping back and pulling back on their funding and things like that.

+ +

So, I just encourage every single company to...if you have a great technical job open, make sure you're sharing it with the Women Who Code community because we have incredible technologists. They deserve access to companies that are willing to support them and the best roles that are available in the industry today.

+ +

WILL: Alaina, I just want to honestly and truly say this, what you're doing is amazing. Having a background in nonprofit, over 140 companies, over 300,000 in your membership, and it's an international nonprofit. It's truly amazing what you're doing and helping women find their role and help them become better.

+ +

I'm truly just blown away by, you know, you started in September 2011, so you're coming up on 12 years this year. And just 12 years as a nonprofit and doing this, share with us how was it received at the very beginning? Because I feel like that was a different time that we're in right now.

+ +

ALAINA: Yeah, it started off as a meetup, just a community group in San Francisco. And it was incredible. It felt like our little secret. And we were spending time together. We were learning. We were building connections. And just it was this incredible community. And then, the world started talking about, hey, we need to teach girls to code. We need to teach women to code. And we were this community of people in the industry. Our average age at Women Who Code is 30, so 50% of our members are currently in technical roles.

+ +

So, we had this moment of, hey, we need to elevate the voice of those who are in the industry right now, alongside teaching girls to code and teaching women to code. Because if you miss out on that, it actually becomes a threat to the women in the industry who, every time you hear "Teach women to code," you're saying she doesn't already know how to do it. And we had so many people in our community who already did and already had to kind of prove themselves on a regular basis or constantly underestimated.

+ +

In the early years, a Women Who Code leader who told me that she was managing a booth at a conference, and everyone was an engineer except for one recruiter, and the recruiter's name was Brian. Someone walked up to her and said, "Are you Brian?" Because it was easier to imagine that her name was Brian than that she was one of the engineers at the table.

+ +

And so, kind of going through this, we said, hey, we need to elevate our voices. We need to elevate the needs of women in the industry. And it feels being in it day by day, that nothing's happening. But when you look back over 13-15 years, you see that parental leave policies have improved significantly, that we see numbers in leadership going up across the board, that it's part of the conversation that relatively standard and tech companies to have DEI roles within the organization, within the people team. And so, these are not enough. It's just the beginning. But it is a lot that's taken place over the past 10 to 15 years.

+ +

VICTORIA: I agree. And I can relate as someone who was a project manager working in a technology space. Was it back in, like, 2013 or something? And you'd go to tech meetups, and most likely, I would be the only woman there. [laughs] But then, with Women Who Code, my friend invited me to go to a Ruby event, and it was, you know, all women. [laughs]. There was a woman who was even giving the instruction. And so, that was just a really cool feeling after having been out networking and feeling kind of isolated to really find a lot of people who are similar to you.

+ +

And I remember part of the narrative at that time when we were talking about increasing inclusion and diversity in technology; there was a narrative that, well, there just aren't as many women in tech. And being a part of Women Who Code, I could be able to, like, answer back to say, "Well, there actually is a lot of women in tech."

+ +

And it's the bigger problem that women would get started because they're interested in the industry and having good careers, but then they would fall out midway. So, there just wasn't enough progression in their careers. There wasn't enough support on the parental leave side, or there just wasn't enough community to keep people interested, like, when you're the only one. And many of our members they were the only women in their company, and then Women Who Code was where they found people they could really connect with.

+ +

So, I just think it's interesting that it solves a particular problem where we would have women who are just interested in learning to code who would come to our events. And then, we had women who were actively coding in their jobs and teaching others in these leadership roles within the community to advance their own careers. And that's certainly what I did, and how I broke into executive leadership was, like, I'm a director at Women Who Code and I've got all this other leadership experience. And I'm bringing that network with me. It really increases your value to employers and demonstrates your leadership abilities.

+ +

ALAINA: Yeah, I couldn't agree more. The program which we kind of fell into, it's our volunteers, is our program that I'm actually most proud of at Women Who Code. And it's probably because I get to know our volunteers because I know so many people's lives and careers are impacted by our programming.

+ +

But that leadership development, that practice-based leadership that our volunteers are able to obtain, the doors that get open, and just like you said, it opened doors. And I remember it hit me when one of our volunteers told me she was interviewing with SpaceX. And one of the reasons they said they were excited to talk to her was because of her Women Who Code leadership experience. And I just thought to myself, we're doing something right. [laughs]

+ +

VICTORIA: Yeah, absolutely. And I think maybe part of Will's question before, too, is, like, did it always feel like you were doing something right? Or did it all just come together naturally? Or what kind of bumps did you initially hit when you were getting things off the ground?

+ +

ALAINA: Yeah. When we first got started and realized, hey, we need to make Women Who Code more accessible, we were doing everything in a very manual way. We needed to adapt to building systems and processes, and that's not the fun part of running a volunteer organization. And when you're moving so fast, it means slowing things down a little bit to be able to make sure that you can do things better, more consistently, more efficiently, but it's so critical.

+ +

And so, I would say we kind of launched outside of the Bay Area in a couple of cities. And it just snowballed until we expanded into 20 to 40 more cities within probably a year outside of that. And we just really needed to catch up on creating systems and processes, which is not beautiful at all, but it's an important part of running a real business, a real company.

+ +

WILL: That's amazing. First off, I just want to say I am so sorry that the world we live in looks down upon women or anybody. So, I'm just so sorry that, like, the story you said about Brian, asking the lady that. I feel like that's so disrespectful. I am so sorry if you ever got treated that way or anything like that.

+ +

And so, I was going to ask this question, and then I kind of answered it. But the question was, do you think women are at a place to where kind of equal in tech? And I kind of answered my own question and said, "No." And so, I want to reframe it. What do you think it will take to continue to help the women get to that level of where it should be?

+ +

ALAINA: It's going to take a lot of things. But the fastest and easiest way to create more equality for women and girls in the tech industry is by investing and supporting the incredible talent that is in the industry today. We need them to thrive. We need them to stay in their careers. We need them to become leaders with power and influence to create more equity in the industry so that when future generations are coming in, they're coming into an industry that is less broken for them, that is more welcoming, that shows and demonstrates more opportunity.

+ +

This is one of the most exciting and innovative industries to be a part of. So many things are being shaped and built for the first time that are systems that are going to be the foundations for years or centuries to come. And so, it's more important now than ever for us to be thinking about bringing equity into that so we're not dealing with technical debt, where we're starting from a system that has more equality to it.

+ +

VICTORIA: I really appreciate that perspective. And I'm curious how that relates to your work at Valor Ventures as well.

+ +

ALAINA: Valor Ventures is very aligned with the values of Women Who Code, which is why I chose it. I am passionate about creating more equality and opportunity for diverse individuals to thrive and succeed in general but via the tech industry. And so, when I move into focusing on entrepreneurs and focusing on seeing diverse entrepreneurs succeed in building thriving organizations, I see an opportunity to have someone who will be thinking earlier about the policies and the practices that are going to build more equitable teams, products that are really for all of their users.

+ +

VICTORIA: I think that's a great mindset. And it reminds me that when we talked about, like, the importance of diversity, and equity, and inclusion, that it's not purely a moral thing, even though morally we know we want to support and be inclusive, but that it's also good business strategy [laughs], just by the value of having different perspectives and different types of people, and then being able to have your products be accessible for a diverse group as well, right?

+ +

ALAINA: Yeah, the data shows teams that are diverse are smarter. Companies that have women represented in leadership they have a stronger ROI. There's business reason behind it. There's certainly a social-moral reason that it just should take place. But, you know, if you need to come back to your shareholders or your investors, there's financial data around it.

+ +

WILL: Yeah, I totally agree on all that, like, yes, yes, yes, yes, yes.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

WILL: What have you seen hold back women in this space? And the reason I'm asking this question is because there are some biases out there, and, at times, we don't even realize it. For example, I know we have parental leave. And before I had kids, I didn't understand parental leave at all. But then, now that I have kids, I'm like, oh, it is not even close to being enough time during that time, you know, four or five hours of sleep at night, just all those things.

+ +

So, in your experience, what have you seen? And hopefully, we can use this as a learning opportunity for anybody that just may be blind to it. What have you seen that kind of holds it back?

+ +

ALAINA: That's holding back, like, implementing specific policies and practices or?

+ +

WILL: Yes, holding back the policies, or maybe women not being as prevalent in tech roles any of those areas.

+ +

ALAINA: So, sort of two different approaches with that is I'm optimistic. I think most companies, yes, they care about the bottom line, but they want to be doing the right thing if it's easy. Leaders like me we need to put pressure on companies making better decisions. But also, industry leaders and organizations out there need to be able to make it easier for companies to make the decisions that are going to create more equity inside of their organization.

+ +

I know that's taking the responsibility off of them a little bit. But companies won't make commitments. They won't do the hard things if they don't know how to do it. And so, the easier that we can make it for them to make the right decision, the more likely they are to make the right decision.

+ +

VICTORIA: I think that people want to do the right thing if it's easy is a really succinct way to explain a lot of, like, social and moral [laughs] issues right now, right? Most people generally want to do the right thing, but it can be complex.

+ +

I'm curious about, speaking of complexity, for Women Who Code, going through, you know, being an organization that was built around in-person events, and then having COVID happen, so, like, what were some of the challenges of the last few years and changes that you experienced along the way?

+ +

ALAINA: Yeah, when COVID hit, that was a big moment for the whole world. It was certainly really hard for organizations that rely on in-person activities. You know, our major conference supplied a third of our operating revenue. Our members were going to, you know, close to 2,000 in-person events. And so, we had to adapt just like everyone else. The organizations and the companies that adapted were the ones that thrived.

+ +

So, we had to completely retrain all of our volunteers from doing in-person events to be able to create digital events for our community. We had to figure out how to produce major events, and conferences, and hackathons and do it in a remote way. And then, of course, there's the day-to-day that absolutely everyone had, and that was, you know, just your team went from meeting in person to everyone being remote.

+ +

And some of the great things that came out about that is we were serving members in about 26 countries and about 80 cities, and now we serve members in 147 countries. It just made it accessible that if you don't happen to be in a location where an event is happening and you also don't happen to have childcare, be able to participate, that you are still able to participate in an online setting.

+ +

And then, what we saw with being able to start moving more of, you know, those talks that were being delivered to our YouTube channel, it then became even more accessible. People spent about five years of life watching our YouTube trainings, and that's time people are investing in themselves. And when I say they did it, and I'm talking about in 2022. So, our YouTube channel, our trainings, they continue to grow, and then our online events continue to happen. But luckily, now we are able to start going back in person.

+ +

And it's, again, just so amazing to be able to see the people you haven't seen in a long time, feel that feeling that is just a little bit different for an in-person event.

+ +

WILL: That's amazing. So, from, say, 2019, 2020 to now, it went from 80 countries to over 140, just because of the pivot to go more, like, YouTube and tech. Is that kind of what you're saying about the growth of it?

+ +

ALAINA: Yeah, so about 80 cities, so about 25 countries to serving members in 147 countries.

+ +

WILL: That's amazing.

+ +

ALAINA: Yeah, a tremendous amount of growth and creating accessibility around the globe. Previously, we were really only able to focus on tech hubs that had an ecosystem to support it. But, you know, just because you're from a rural area of your state or from a country in the Global South, you still deserve access to this incredible community and all of the free accessible programming that Women Who Code has to offer.

+ +

When we have a conference, we have people from 88 countries participating. And when you sign into the networking session, you're going to hop on the phone with someone from Nigeria, someone from Bangladesh, someone from your same city, and it's just such an incredible experience to be able to have that global focus and reach.

+ +

WILL: Wow, that is so amazing. So, let's talk about right now. What does your next milestone look like, you know, in the next six months or next year? What does that look like for you?

+ +

ALAINA: As I mentioned before, one of the big challenges we've had this year is our programming is going so, so well, but our funding has pulled back a little bit. And so, we're working to diversify our revenue strategy a little bit and have a traditional nonprofit walk that we've never done before. And it's a remote walk, so anyone all over the world can participate just like you can with our digital events.

+ +

But this has been something new for us. Because when we went through it during COVID, again, you know, you'd get on the call with all of your partners. You know, the world is going through something, and you kind of say, oh yeah, we're in it together. But you don't see the grace that you saw in 2020 and sort of the camaraderie, and we're in this together, and we're going to give you space and support you, you know, in every way that we can that, you know, is just really missing this time around. You know, we have members who absolutely need support in their careers right now. And so, it's navigating through something different.

+ +

VICTORIA: Yeah. And I guess talking more about inclusivity, like, we have all this free content, and it is Women Who Code. But I remember when I was an organizer, I had a few people ask me, "Well if I'm a man, can I come to your event?" And I was like, "Yes, it's open to everyone," right? Like, it's promoting women, and it's about women growing in their careers. And certainly, if that's not also your intention with attending the event, you should keep that in mind and make sure you're leaving space for other people.

+ +

But I also really appreciated that it's open for everyone and that it's open for everyone who is in the women umbrella, and being intentional about that, and that it's inclusive of everyone who relates to being a woman, right?

+ +

ALAINA: Yeah. Women Who Code welcomes all genders. We, you know, really struggle with our name from a brand perspective because it isn't as inclusive as we'd like it to be. So, actually, after we say our name, we try not to repeat the word women anywhere else. From the beginning, been dedicated to having an open, accessible community. But we definitely require, you know, that you are following our code of conduct, that you're there for the intended purpose of the event. And we want to make sure that we're protecting our community.

+ +

VICTORIA: Well, I really appreciate that. And I appreciate...it sounds like a value organization that I'm with. I always look for those things that that's what we're really promoting.

+ +

There's been so many changes that have happened with Women Who Code and in your career. If you could go back in time and give yourself some advice when you were first getting started, what would you tell yourself?

+ +

ALAINA: If I was going back and thinking about what I would tell myself in the beginning, I'd probably tell myself to focus on data sooner. Coming from the history of being a meetup group to transitioning to being a global nonprofit, we dragged our feet around focusing on data impact, and really, it's because we're constantly doing so much programming. We're always doing so many things, and anything you add on is an extra thing to do. And so, I would say focus on the data much sooner.

+ +

VICTORIA: I can speak to there being a lot of events. I remember back in the heyday in D.C., it was, like, algorithms on Tuesdays and Ruby on Thursdays, and then next week, it would be DevOps. And there was just always something going on. And I thought that was so cool. And I really appreciate just really everyone who is involved in putting on those programs. I really want to emphasize, too, like, the value for companies working with Women Who Code. And what do they get out of the partnership, and how can they really engage with the community?

+ +

ALAINA: Yeah. So, companies that work with us, it's a partnership. They are there to support the community, and that's what they have to do to really develop trust. And we're going to make sure that we're guiding them in that process. So, if we see an opportunity for them to engage in a more authentic way, we're going to point that out. But companies are often hiring from our community; that's one of the big reasons, not just through our job board because our members are unicorns. They're diverse technologists, and everyone wants to hire them.

+ +

And so, you can just say, "Hey, come work for me." But really, they want you to explain who's on the team? What are the exciting projects, and what are the exciting technologies that your company is building? So that they can actually identify that your company is an organization that they would want to work for before just applying for a job. And that's what a lot of our partnership creates space for.

+ +

So, maybe getting an opportunity to join our podcast and tell the story and get to know some of the diverse leadership team or diverse engineering team, learn about some of your, like, commitment to DEI and things like that. Because when a senior engineer receives multiple job outreaches, they're going to respond to the one that they've heard of, that they already know is a good company, that they know is supporting and investing in building equity into the tech ecosystem. That's going to go a long way in them deciding to reply.

+ +

WILL: That's awesome. Earlier, you mentioned being inclusive of all the members. I think I know the answer, but I just want to double-check. If I want to volunteer, am I able to volunteer at Women Who Code?

+ +

ALAINA: Yes, absolutely. If you visit our website...and we just updated our website, so I encourage everyone to go visit womenwhocode.com today. It's looking different than it has over the past five years. There's a sign-up to volunteer. You would be absolutely welcome, Will.

+ +

WILL: Awesome. And, as a volunteer, what would that look like? What could I get involved in? What areas?

+ +

ALAINA: You could decide to be a speaker. You could apply to be a network leader. You could become a lead in a particular technology area. We have six technical tracks. Our tracks are cloud, data science, Python, mobile. When [inaudible 32:53] hears about it, we will have emerging technologies track that was expanded from our blockchain community this year. And then, we also have a career track as well. So, you can become a lead focused on one of those particular areas in our digital communities. You can get engaged with the Women Who Code community in many different ways.

+ +

We also have some really cool programs like mentor me and buddy system, so getting involved in those. Building long-form connections or long-time connections with individuals in the community really helps to create a sense of belonging and start to build trust and an opportunity to exchange knowledge.

+ +

VICTORIA: I always really appreciated people who were, like, "Do you need a space to host your meetup?" Or "Do you want us to buy you pizza for your meetup?" [laughs] Those are very easy ways to engage. And it's true that the membership does see and pay attention to, like, who is regularly getting involved in committing to this, and it makes a difference in your brand and reputation.

+ +

ALAINA: Absolutely. The companies that work with us absolutely hire from the Women Who Code community. I'll give two examples. So, one of the most exciting examples was we had an event at a company, and they sort of were connecting in an authentic way, not, like, an interview way, but they essentially were doing an early interview with people who were there. And so I remember that it took place on Tuesday, and they had a job offer on Friday at the company that they were at. So, they were just able to move so quickly and hire someone from our community.

+ +

And then, ages ago, Snapchat was at our first-ever conference, and they had hired four or six people at that event. And it was just so cool to see that we're not a recruiting agency, so we really just rely on either individuals or companies to tell us when they have these amazing career outcomes. So, every time we hear about it, it's always exciting to me.

+ +

VICTORIA: That's super cool. And I wonder, what is the thing you're most excited about coming up for Women Who Code this year?

+ +

ALAINA: We have CONNECT Asia taking place later on this year, and so that's our major technical conference with a focus in the Asia market. It's going to be just really, really exciting. We haven't had one since pre-COVID. It's still going to be a remote event. We had CONNECT LATAM, so our first-ever conference focused on Latin America last year. And this year, it's focused on Asia. So, it's really exciting to get back and provide some support to our regional audiences and really showcase some of the incredible talent and leadership coming out of those regions.

+ +

WILL: That's amazing. So, the question I have for you, and it's easy to assume this question, but I want to hear from you because I know you talked about, at the beginning, how it was when you started the nonprofit. But what is the wind in your sails? Like, what keeps you motivated and going? It sounds like it's an easy answer, but just from your heart, what motivates you?

+ +

ALAINA: Oh, it is absolutely the stories that I hear, like I said, especially from our volunteers. So, the Mexico City volunteer who, in under a year, told me her salary increased 200%. The director from Toronto, you know, when she stepped up, was an individual contributor, and under one year, she made it to director level, and today she's a vice president.

+ +

So, when I think of the career impacts that are taking place for our members, and every single time I hear about it, it drives me to wake up. It drives me to work harder. It drives me to deliver better program and just makes me completely connected to what we do as an organization.

+ +

VICTORIA: What a great benefit. And for myself, personally, it absolutely has been a factor in the last, like, two jobs I've gotten. [laughs] They're like, "Oh, you are a director at Women Who Code? That's so interesting." So, I really appreciate everything that you've done and happy to be a part of that. And my personal network, I know many women who have been through that and benefited immensely from having that networking community. And really, even just being able to see yourself and know that you belong in the industry, I think, is really, really important.

+ +

ALAINA: I'm sure I'm going to be telling your story the next time someone asks me.

+ +

[laughter]

+ +

VICTORIA: That's great. No, please do. And let's see; we're wrapping up at the end of our time here. Is there anything else that you would like to promote?

+ +

ALAINA: Yeah, please visit womenwhocode.com. If you have technical jobs available, please post them to the Women Who Code job board. Again, it's just womenwhocode.com/jobs. Join our community. Check out our amazing, new, beautiful website, and follow us on social media @WomenWhoCode.

+ +

VICTORIA: Love that. Thank you so much for joining us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Alaina Percival.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Alaina Percival is the Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers.

+ +

Alaina delves into the origin and mission of Women Who Code, highlighting its community building, free technical events, and collaboration with companies to promote diversity in hiring. Victoria adds her personal experience with the organization, emphasizing its positive impact on her career.

+ +

They discuss the challenges faced while expanding Women Who Code, including the need for systems and processes to manage growth. Alaina recounts stories of discrimination faced by women in tech and stresses the need for continued support and encouragement. The conversation also touches on the financial benefits of diversity and the alignment of Valor Ventures with Women Who Code's values.

+ +

This discussion offers a detailed look into the women in tech movement, the importance of community, and the drive to create a more equitable industry. It serves as a reflection on both the strides made in fostering diversity and the work still needed to create a truly inclusive technology field.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with me today is Alaina Percival, Venture Partner at Valor Ventures and Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers. Alaina, thank you for joining us.

+ +

ALAINA: Thank you so much for having me. I'm thrilled to be here.

+ +

VICTORIA: I'm thrilled to have you as well. I reached out. As you know, I was previously a Director of Women Who Code D.C. and helped to organize our DevOps and cloud series when I lived there. And it really had a huge impact on my career. So, I'm just super psyched to talk to you today. What's going on in your world, Alaina?

+ +

ALAINA: So, in addition to my full-time job of working with Women Who Code, I'm also a mom of two young children, and so they're currently three and five. And so, it's summer. We've got summer camp. Every week is a different program with different details and things that you have to read and stay up on. It's a lot of additional project management added on over the summer. I'm looking forward to getting back to the school year, where I can kind of focus on just one role.

+ +

WILL: That's amazing. And I can totally relate because I have a four, a three, and a one-year-old. Yes, it's a different story when you have to, like you said, project manage around them. So, that's amazing that you're wearing so many hats, and you're doing that. Hats off to you.

+ +

ALAINA: Same to you. [laughter]

+ +

WILL: Victoria, what about you? What's going on in your world?

+ +

VICTORIA: Well, it is summertime at the beach, so all the kids are out. [laughs] It's busy. But that means that you know, the weather is warming up. It's tempting to try to go surfing again, so we'll see if that ends up happening anytime soon. But no, I'm hanging out. I'm local. I'm kind of done traveling for a little bit, so not until I go out to Outer Banks to visit my baby niece and nephew in August. So that's where I'm at right now. I'm kind of hunkered in trying to survive without air conditioning here and get through the summer. [laughs]

+ +

WILL: You don't have AC?

+ +

VICTORIA: I do not. Yeah, there's a lot of houses around here just never were built with it. I have heat, but I have no air conditioning.

+ +

ALAINA: Are you being hit with the heat wave that's happening?

+ +

VICTORIA: Yes. But it's still very mild. We're spoiled here for sure on weather.

+ +

WILL: [laughs]

+ +

VICTORIA: It's like 77, and I'm like, ugh, it's so hot. [laughs]

+ +

WILL: I'm in Florida, and it amazes me. So, I got up early, around 7:00 o'clock, to go out for a run, and it's, like, 87 degrees. And it feels like almost 100 at 7:00 a.m. And I'm like --

+ +

VICTORIA: Oof.

+ +

WILL: How? [laughs] Like, the sun is barely out, and it's already reaching 100. So yeah.

+ +

ALAINA: I feel you. I'm in Atlanta. Yesterday, I had an in-person meeting. Typically, we're entirely remote. So, I was wearing real pants [laughs], and it was a hard day. We're not quite as hot as Florida. We are in the low 90s. But yeah, this weather is for real.

+ +

WILL: Yes. [laughter]

+ +

VICTORIA: That is the...yeah, working in person again in a hot climate. [laughs] I forgot the challenges of that of, like, trying to navigate life while having to be fully clothed is difficult in that kind of weather. So, I'm glad. I hope you all find some ways to stay cool and to entertain your children [laughs] so that you have some sanity and can get through the summer. I've also been really interested in the European model of just taking five weeks off in the summer. Doesn't that sound nice?

+ +

WILL: Yes. [laughs]

+ +

ALAINA: Yeah. I started my career off in Germany. I worked for Puma. Their headquarters is right outside of Nuremberg in a town called Herzogenaurach. And people really do take the whole month off August. And, in fact, you would even separate out the salaries. So, you got something called urlaubsgeld, which was vacation money. So, you would get kind of a little bonus going into August, and then everybody would take off. So, I agree with you. We should be doing that.

+ +

VICTORIA: Yeah, we should be doing that. And I'm so excited. Maybe we can segue into, like, your background and how you got started. How did you go from there to founding Women Who Code?

+ +

ALAINA: Yeah, so after working at Puma, I somewhat came back to the United States. I did a dual degree program, an MBA where I was studying between Atlanta, so I could get back in the United States, spend some time with my family, and then also the Sorbonne in Paris. And I did an MBA and a degree in organizational management, Master's in organizational management.

+ +

Then I went to work for really small ones, performance wear company. And that was more, like, a startup because you really had to think outside of the box. You know, you're a small $10 million a year company, and Nike and Mizuno, you know, these big companies are your competitors.

+ +

So, I had the opportunity to move out to San Francisco. It was one of the cities that was always on my list of, hey, if you get a chance to do it, go for it. And I did. So, I moved out there, and I kind of hit a bit of a wall with my career, an unexpected wall because up until that point, I had just this really, you know, successful early career. I got out there, and they're, like, Puma. You know, you haven't worked for Microsoft, or Twitter, or Facebook, or Google. Who are you?

+ +

So, I started learning to code just to transition my skill set to help me understand the culture and the language and just getting more involved in the tech community. And I was still struggling a little bit in figuring out my transition pathway and got more and more involved with Women Who Code and started, you know, spending my nights and weekends.

+ +

And finally, I was at a small startup that had gotten acquired, so I had my official tech credibility. And I went to work for one of the top technical recruiting firms, executive recruiting firms in the Bay Area, as their head of developer outreach. And I largely chose that role because they were allowing me to run their philanthropic arm, and I focused that around supporting underrepresented communities, you know, get a leg up in the tech community. And then, while I was there, I was working with CTOs, vice presidents of engineering, directors of engineering on a day-to-day basis.

+ +

And I started learning what they were doing in their career to help develop and cultivate the success that they were having, and I started bringing that knowledge and programming into Women Who Code. And that's where our mission around seeing diverse women excel in technology careers came about is, you know, that piece of retaining and seeing diverse women excelling was an area that wasn't really the focus at the time. And I feel like it sounds funny now because it's such a big piece of conversation. But that was the beginning.

+ +

VICTORIA: Yeah, it's so interesting that your experience from being in a startup and then how you moved up into being really involved in the hiring and the process of how women...how anyone would actually, like, move up in their career led you to have that background to found Women Who Code. And for people who maybe don't know, [laughs] no, I certainly know what it is. Can you talk a little bit more about what it offers to women and what it offers to companies who are looking to hire diverse women?

+ +

ALAINA: For individuals, we are the largest and most active community of diverse technologists. We have close to 350,000 members. We're serving members across 147 countries. And we're producing close to 2,000 free technical events every single year, so that's about an average of 5 per day.

+ +

Once those events take place, if you happen to miss them if you happen to not be in a location where they're having them in person, we're putting a lot of that on our YouTube channel. So, you can go back when you have time, when you're available, still invest in yourself and learn some of these technical and career-related skills.

+ +

You can also, you know, when you think about, say, the 2,000 talks that are being delivered at Women Who Code, the majority of them are being led by and delivered by diverse technologists. So, we're creating role models and helping people who are on their career path have a sense of belonging, see a pathway to success. People who are thinking about the career path see themselves represented as thought leaders, as leaders in the tech industry. And that sense of belonging, that sense of drive, is just so important to be able to continue on in your career.

+ +

But we work with companies. So, Women Who Code is dedicated to accessibility. All of our programming is free or scholarship accessible. And so, what we do is we work with companies, and we do this for two reasons: for programmatic reasons. Because we know that if companies develop strong diversity, equity, and inclusion, and belonging practices, that we will reach our mission and vision so much faster than if we work with every individual in the world. But it also creates an opportunity for us to be able to support the community.

+ +

So, we work with companies to sponsor Women Who Code to donate to support Women Who Code's programming. We have our first-ever walk coming up, so a walk, run, roll called Women Who Code to the Finish Line. And we're going to be having that in September of this year. And that's going to be an opportunity for the stakeholders. You know, often, people who aren't in our community but absolutely support us say, "How can we help?" And so, companies can form teams and go and walk, run, roll to change the face of the tech industry.

+ +

Right now, we're also in a position where the tech industry has been doing a lot of layoffs, so there's a lot of instability. And so, when that happens, our programming thrives. So, people are coming to our events in high numbers. People are participating in our programming. People are visiting our job board. It's the time when companies are stepping back and pulling back on their funding and things like that.

+ +

So, I just encourage every single company to...if you have a great technical job open, make sure you're sharing it with the Women Who Code community because we have incredible technologists. They deserve access to companies that are willing to support them and the best roles that are available in the industry today.

+ +

WILL: Alaina, I just want to honestly and truly say this, what you're doing is amazing. Having a background in nonprofit, over 140 companies, over 300,000 in your membership, and it's an international nonprofit. It's truly amazing what you're doing and helping women find their role and help them become better.

+ +

I'm truly just blown away by, you know, you started in September 2011, so you're coming up on 12 years this year. And just 12 years as a nonprofit and doing this, share with us how was it received at the very beginning? Because I feel like that was a different time that we're in right now.

+ +

ALAINA: Yeah, it started off as a meetup, just a community group in San Francisco. And it was incredible. It felt like our little secret. And we were spending time together. We were learning. We were building connections. And just it was this incredible community. And then, the world started talking about, hey, we need to teach girls to code. We need to teach women to code. And we were this community of people in the industry. Our average age at Women Who Code is 30, so 50% of our members are currently in technical roles.

+ +

So, we had this moment of, hey, we need to elevate the voice of those who are in the industry right now, alongside teaching girls to code and teaching women to code. Because if you miss out on that, it actually becomes a threat to the women in the industry who, every time you hear "Teach women to code," you're saying she doesn't already know how to do it. And we had so many people in our community who already did and already had to kind of prove themselves on a regular basis or constantly underestimated.

+ +

In the early years, a Women Who Code leader who told me that she was managing a booth at a conference, and everyone was an engineer except for one recruiter, and the recruiter's name was Brian. Someone walked up to her and said, "Are you Brian?" Because it was easier to imagine that her name was Brian than that she was one of the engineers at the table.

+ +

And so, kind of going through this, we said, hey, we need to elevate our voices. We need to elevate the needs of women in the industry. And it feels being in it day by day, that nothing's happening. But when you look back over 13-15 years, you see that parental leave policies have improved significantly, that we see numbers in leadership going up across the board, that it's part of the conversation that relatively standard and tech companies to have DEI roles within the organization, within the people team. And so, these are not enough. It's just the beginning. But it is a lot that's taken place over the past 10 to 15 years.

+ +

VICTORIA: I agree. And I can relate as someone who was a project manager working in a technology space. Was it back in, like, 2013 or something? And you'd go to tech meetups, and most likely, I would be the only woman there. [laughs] But then, with Women Who Code, my friend invited me to go to a Ruby event, and it was, you know, all women. [laughs]. There was a woman who was even giving the instruction. And so, that was just a really cool feeling after having been out networking and feeling kind of isolated to really find a lot of people who are similar to you.

+ +

And I remember part of the narrative at that time when we were talking about increasing inclusion and diversity in technology; there was a narrative that, well, there just aren't as many women in tech. And being a part of Women Who Code, I could be able to, like, answer back to say, "Well, there actually is a lot of women in tech."

+ +

And it's the bigger problem that women would get started because they're interested in the industry and having good careers, but then they would fall out midway. So, there just wasn't enough progression in their careers. There wasn't enough support on the parental leave side, or there just wasn't enough community to keep people interested, like, when you're the only one. And many of our members they were the only women in their company, and then Women Who Code was where they found people they could really connect with.

+ +

So, I just think it's interesting that it solves a particular problem where we would have women who are just interested in learning to code who would come to our events. And then, we had women who were actively coding in their jobs and teaching others in these leadership roles within the community to advance their own careers. And that's certainly what I did, and how I broke into executive leadership was, like, I'm a director at Women Who Code and I've got all this other leadership experience. And I'm bringing that network with me. It really increases your value to employers and demonstrates your leadership abilities.

+ +

ALAINA: Yeah, I couldn't agree more. The program which we kind of fell into, it's our volunteers, is our program that I'm actually most proud of at Women Who Code. And it's probably because I get to know our volunteers because I know so many people's lives and careers are impacted by our programming.

+ +

But that leadership development, that practice-based leadership that our volunteers are able to obtain, the doors that get open, and just like you said, it opened doors. And I remember it hit me when one of our volunteers told me she was interviewing with SpaceX. And one of the reasons they said they were excited to talk to her was because of her Women Who Code leadership experience. And I just thought to myself, we're doing something right. [laughs]

+ +

VICTORIA: Yeah, absolutely. And I think maybe part of Will's question before, too, is, like, did it always feel like you were doing something right? Or did it all just come together naturally? Or what kind of bumps did you initially hit when you were getting things off the ground?

+ +

ALAINA: Yeah. When we first got started and realized, hey, we need to make Women Who Code more accessible, we were doing everything in a very manual way. We needed to adapt to building systems and processes, and that's not the fun part of running a volunteer organization. And when you're moving so fast, it means slowing things down a little bit to be able to make sure that you can do things better, more consistently, more efficiently, but it's so critical.

+ +

And so, I would say we kind of launched outside of the Bay Area in a couple of cities. And it just snowballed until we expanded into 20 to 40 more cities within probably a year outside of that. And we just really needed to catch up on creating systems and processes, which is not beautiful at all, but it's an important part of running a real business, a real company.

+ +

WILL: That's amazing. First off, I just want to say I am so sorry that the world we live in looks down upon women or anybody. So, I'm just so sorry that, like, the story you said about Brian, asking the lady that. I feel like that's so disrespectful. I am so sorry if you ever got treated that way or anything like that.

+ +

And so, I was going to ask this question, and then I kind of answered it. But the question was, do you think women are at a place to where kind of equal in tech? And I kind of answered my own question and said, "No." And so, I want to reframe it. What do you think it will take to continue to help the women get to that level of where it should be?

+ +

ALAINA: It's going to take a lot of things. But the fastest and easiest way to create more equality for women and girls in the tech industry is by investing and supporting the incredible talent that is in the industry today. We need them to thrive. We need them to stay in their careers. We need them to become leaders with power and influence to create more equity in the industry so that when future generations are coming in, they're coming into an industry that is less broken for them, that is more welcoming, that shows and demonstrates more opportunity.

+ +

This is one of the most exciting and innovative industries to be a part of. So many things are being shaped and built for the first time that are systems that are going to be the foundations for years or centuries to come. And so, it's more important now than ever for us to be thinking about bringing equity into that so we're not dealing with technical debt, where we're starting from a system that has more equality to it.

+ +

VICTORIA: I really appreciate that perspective. And I'm curious how that relates to your work at Valor Ventures as well.

+ +

ALAINA: Valor Ventures is very aligned with the values of Women Who Code, which is why I chose it. I am passionate about creating more equality and opportunity for diverse individuals to thrive and succeed in general but via the tech industry. And so, when I move into focusing on entrepreneurs and focusing on seeing diverse entrepreneurs succeed in building thriving organizations, I see an opportunity to have someone who will be thinking earlier about the policies and the practices that are going to build more equitable teams, products that are really for all of their users.

+ +

VICTORIA: I think that's a great mindset. And it reminds me that when we talked about, like, the importance of diversity, and equity, and inclusion, that it's not purely a moral thing, even though morally we know we want to support and be inclusive, but that it's also good business strategy [laughs], just by the value of having different perspectives and different types of people, and then being able to have your products be accessible for a diverse group as well, right?

+ +

ALAINA: Yeah, the data shows teams that are diverse are smarter. Companies that have women represented in leadership they have a stronger ROI. There's business reason behind it. There's certainly a social-moral reason that it just should take place. But, you know, if you need to come back to your shareholders or your investors, there's financial data around it.

+ +

WILL: Yeah, I totally agree on all that, like, yes, yes, yes, yes, yes.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

WILL: What have you seen hold back women in this space? And the reason I'm asking this question is because there are some biases out there, and, at times, we don't even realize it. For example, I know we have parental leave. And before I had kids, I didn't understand parental leave at all. But then, now that I have kids, I'm like, oh, it is not even close to being enough time during that time, you know, four or five hours of sleep at night, just all those things.

+ +

So, in your experience, what have you seen? And hopefully, we can use this as a learning opportunity for anybody that just may be blind to it. What have you seen that kind of holds it back?

+ +

ALAINA: That's holding back, like, implementing specific policies and practices or?

+ +

WILL: Yes, holding back the policies, or maybe women not being as prevalent in tech roles any of those areas.

+ +

ALAINA: So, sort of two different approaches with that is I'm optimistic. I think most companies, yes, they care about the bottom line, but they want to be doing the right thing if it's easy. Leaders like me we need to put pressure on companies making better decisions. But also, industry leaders and organizations out there need to be able to make it easier for companies to make the decisions that are going to create more equity inside of their organization.

+ +

I know that's taking the responsibility off of them a little bit. But companies won't make commitments. They won't do the hard things if they don't know how to do it. And so, the easier that we can make it for them to make the right decision, the more likely they are to make the right decision.

+ +

VICTORIA: I think that people want to do the right thing if it's easy is a really succinct way to explain a lot of, like, social and moral [laughs] issues right now, right? Most people generally want to do the right thing, but it can be complex.

+ +

I'm curious about, speaking of complexity, for Women Who Code, going through, you know, being an organization that was built around in-person events, and then having COVID happen, so, like, what were some of the challenges of the last few years and changes that you experienced along the way?

+ +

ALAINA: Yeah, when COVID hit, that was a big moment for the whole world. It was certainly really hard for organizations that rely on in-person activities. You know, our major conference supplied a third of our operating revenue. Our members were going to, you know, close to 2,000 in-person events. And so, we had to adapt just like everyone else. The organizations and the companies that adapted were the ones that thrived.

+ +

So, we had to completely retrain all of our volunteers from doing in-person events to be able to create digital events for our community. We had to figure out how to produce major events, and conferences, and hackathons and do it in a remote way. And then, of course, there's the day-to-day that absolutely everyone had, and that was, you know, just your team went from meeting in person to everyone being remote.

+ +

And some of the great things that came out about that is we were serving members in about 26 countries and about 80 cities, and now we serve members in 147 countries. It just made it accessible that if you don't happen to be in a location where an event is happening and you also don't happen to have childcare, be able to participate, that you are still able to participate in an online setting.

+ +

And then, what we saw with being able to start moving more of, you know, those talks that were being delivered to our YouTube channel, it then became even more accessible. People spent about five years of life watching our YouTube trainings, and that's time people are investing in themselves. And when I say they did it, and I'm talking about in 2022. So, our YouTube channel, our trainings, they continue to grow, and then our online events continue to happen. But luckily, now we are able to start going back in person.

+ +

And it's, again, just so amazing to be able to see the people you haven't seen in a long time, feel that feeling that is just a little bit different for an in-person event.

+ +

WILL: That's amazing. So, from, say, 2019, 2020 to now, it went from 80 countries to over 140, just because of the pivot to go more, like, YouTube and tech. Is that kind of what you're saying about the growth of it?

+ +

ALAINA: Yeah, so about 80 cities, so about 25 countries to serving members in 147 countries.

+ +

WILL: That's amazing.

+ +

ALAINA: Yeah, a tremendous amount of growth and creating accessibility around the globe. Previously, we were really only able to focus on tech hubs that had an ecosystem to support it. But, you know, just because you're from a rural area of your state or from a country in the Global South, you still deserve access to this incredible community and all of the free accessible programming that Women Who Code has to offer.

+ +

When we have a conference, we have people from 88 countries participating. And when you sign into the networking session, you're going to hop on the phone with someone from Nigeria, someone from Bangladesh, someone from your same city, and it's just such an incredible experience to be able to have that global focus and reach.

+ +

WILL: Wow, that is so amazing. So, let's talk about right now. What does your next milestone look like, you know, in the next six months or next year? What does that look like for you?

+ +

ALAINA: As I mentioned before, one of the big challenges we've had this year is our programming is going so, so well, but our funding has pulled back a little bit. And so, we're working to diversify our revenue strategy a little bit and have a traditional nonprofit walk that we've never done before. And it's a remote walk, so anyone all over the world can participate just like you can with our digital events.

+ +

But this has been something new for us. Because when we went through it during COVID, again, you know, you'd get on the call with all of your partners. You know, the world is going through something, and you kind of say, oh yeah, we're in it together. But you don't see the grace that you saw in 2020 and sort of the camaraderie, and we're in this together, and we're going to give you space and support you, you know, in every way that we can that, you know, is just really missing this time around. You know, we have members who absolutely need support in their careers right now. And so, it's navigating through something different.

+ +

VICTORIA: Yeah. And I guess talking more about inclusivity, like, we have all this free content, and it is Women Who Code. But I remember when I was an organizer, I had a few people ask me, "Well if I'm a man, can I come to your event?" And I was like, "Yes, it's open to everyone," right? Like, it's promoting women, and it's about women growing in their careers. And certainly, if that's not also your intention with attending the event, you should keep that in mind and make sure you're leaving space for other people.

+ +

But I also really appreciated that it's open for everyone and that it's open for everyone who is in the women umbrella, and being intentional about that, and that it's inclusive of everyone who relates to being a woman, right?

+ +

ALAINA: Yeah. Women Who Code welcomes all genders. We, you know, really struggle with our name from a brand perspective because it isn't as inclusive as we'd like it to be. So, actually, after we say our name, we try not to repeat the word women anywhere else. From the beginning, been dedicated to having an open, accessible community. But we definitely require, you know, that you are following our code of conduct, that you're there for the intended purpose of the event. And we want to make sure that we're protecting our community.

+ +

VICTORIA: Well, I really appreciate that. And I appreciate...it sounds like a value organization that I'm with. I always look for those things that that's what we're really promoting.

+ +

There's been so many changes that have happened with Women Who Code and in your career. If you could go back in time and give yourself some advice when you were first getting started, what would you tell yourself?

+ +

ALAINA: If I was going back and thinking about what I would tell myself in the beginning, I'd probably tell myself to focus on data sooner. Coming from the history of being a meetup group to transitioning to being a global nonprofit, we dragged our feet around focusing on data impact, and really, it's because we're constantly doing so much programming. We're always doing so many things, and anything you add on is an extra thing to do. And so, I would say focus on the data much sooner.

+ +

VICTORIA: I can speak to there being a lot of events. I remember back in the heyday in D.C., it was, like, algorithms on Tuesdays and Ruby on Thursdays, and then next week, it would be DevOps. And there was just always something going on. And I thought that was so cool. And I really appreciate just really everyone who is involved in putting on those programs. I really want to emphasize, too, like, the value for companies working with Women Who Code. And what do they get out of the partnership, and how can they really engage with the community?

+ +

ALAINA: Yeah. So, companies that work with us, it's a partnership. They are there to support the community, and that's what they have to do to really develop trust. And we're going to make sure that we're guiding them in that process. So, if we see an opportunity for them to engage in a more authentic way, we're going to point that out. But companies are often hiring from our community; that's one of the big reasons, not just through our job board because our members are unicorns. They're diverse technologists, and everyone wants to hire them.

+ +

And so, you can just say, "Hey, come work for me." But really, they want you to explain who's on the team? What are the exciting projects, and what are the exciting technologies that your company is building? So that they can actually identify that your company is an organization that they would want to work for before just applying for a job. And that's what a lot of our partnership creates space for.

+ +

So, maybe getting an opportunity to join our podcast and tell the story and get to know some of the diverse leadership team or diverse engineering team, learn about some of your, like, commitment to DEI and things like that. Because when a senior engineer receives multiple job outreaches, they're going to respond to the one that they've heard of, that they already know is a good company, that they know is supporting and investing in building equity into the tech ecosystem. That's going to go a long way in them deciding to reply.

+ +

WILL: That's awesome. Earlier, you mentioned being inclusive of all the members. I think I know the answer, but I just want to double-check. If I want to volunteer, am I able to volunteer at Women Who Code?

+ +

ALAINA: Yes, absolutely. If you visit our website...and we just updated our website, so I encourage everyone to go visit womenwhocode.com today. It's looking different than it has over the past five years. There's a sign-up to volunteer. You would be absolutely welcome, Will.

+ +

WILL: Awesome. And, as a volunteer, what would that look like? What could I get involved in? What areas?

+ +

ALAINA: You could decide to be a speaker. You could apply to be a network leader. You could become a lead in a particular technology area. We have six technical tracks. Our tracks are cloud, data science, Python, mobile. When [inaudible 32:53] hears about it, we will have emerging technologies track that was expanded from our blockchain community this year. And then, we also have a career track as well. So, you can become a lead focused on one of those particular areas in our digital communities. You can get engaged with the Women Who Code community in many different ways.

+ +

We also have some really cool programs like mentor me and buddy system, so getting involved in those. Building long-form connections or long-time connections with individuals in the community really helps to create a sense of belonging and start to build trust and an opportunity to exchange knowledge.

+ +

VICTORIA: I always really appreciated people who were, like, "Do you need a space to host your meetup?" Or "Do you want us to buy you pizza for your meetup?" [laughs] Those are very easy ways to engage. And it's true that the membership does see and pay attention to, like, who is regularly getting involved in committing to this, and it makes a difference in your brand and reputation.

+ +

ALAINA: Absolutely. The companies that work with us absolutely hire from the Women Who Code community. I'll give two examples. So, one of the most exciting examples was we had an event at a company, and they sort of were connecting in an authentic way, not, like, an interview way, but they essentially were doing an early interview with people who were there. And so I remember that it took place on Tuesday, and they had a job offer on Friday at the company that they were at. So, they were just able to move so quickly and hire someone from our community.

+ +

And then, ages ago, Snapchat was at our first-ever conference, and they had hired four or six people at that event. And it was just so cool to see that we're not a recruiting agency, so we really just rely on either individuals or companies to tell us when they have these amazing career outcomes. So, every time we hear about it, it's always exciting to me.

+ +

VICTORIA: That's super cool. And I wonder, what is the thing you're most excited about coming up for Women Who Code this year?

+ +

ALAINA: We have CONNECT Asia taking place later on this year, and so that's our major technical conference with a focus in the Asia market. It's going to be just really, really exciting. We haven't had one since pre-COVID. It's still going to be a remote event. We had CONNECT LATAM, so our first-ever conference focused on Latin America last year. And this year, it's focused on Asia. So, it's really exciting to get back and provide some support to our regional audiences and really showcase some of the incredible talent and leadership coming out of those regions.

+ +

WILL: That's amazing. So, the question I have for you, and it's easy to assume this question, but I want to hear from you because I know you talked about, at the beginning, how it was when you started the nonprofit. But what is the wind in your sails? Like, what keeps you motivated and going? It sounds like it's an easy answer, but just from your heart, what motivates you?

+ +

ALAINA: Oh, it is absolutely the stories that I hear, like I said, especially from our volunteers. So, the Mexico City volunteer who, in under a year, told me her salary increased 200%. The director from Toronto, you know, when she stepped up, was an individual contributor, and under one year, she made it to director level, and today she's a vice president.

+ +

So, when I think of the career impacts that are taking place for our members, and every single time I hear about it, it drives me to wake up. It drives me to work harder. It drives me to deliver better program and just makes me completely connected to what we do as an organization.

+ +

VICTORIA: What a great benefit. And for myself, personally, it absolutely has been a factor in the last, like, two jobs I've gotten. [laughs] They're like, "Oh, you are a director at Women Who Code? That's so interesting." So, I really appreciate everything that you've done and happy to be a part of that. And my personal network, I know many women who have been through that and benefited immensely from having that networking community. And really, even just being able to see yourself and know that you belong in the industry, I think, is really, really important.

+ +

ALAINA: I'm sure I'm going to be telling your story the next time someone asks me.

+ +

[laughter]

+ +

VICTORIA: That's great. No, please do. And let's see; we're wrapping up at the end of our time here. Is there anything else that you would like to promote?

+ +

ALAINA: Yeah, please visit womenwhocode.com. If you have technical jobs available, please post them to the Women Who Code job board. Again, it's just womenwhocode.com/jobs. Join our community. Check out our amazing, new, beautiful website, and follow us on social media @WomenWhoCode.

+ +

VICTORIA: Love that. Thank you so much for joining us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you can find me @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Alaina Percival.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ru_so9DE + + ]]> + + Will Larry + Victoria Guido + Alaina Percival + + + 487: OtisHealth with Marc Mar-Yohana + https://podcast.thoughtbot.com/487 + 4ae7ab96-4127-4791-af8b-7981bfa64d29 + Thu, 10 Aug 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Marc Mar-Yohana is the CEO and Founder of OtisHealth, a personal health application and platform for patient-caregiver engagement, population health, and clinical research. + +Marc has dedicated his life to developing better tools for families and caregivers to manage their loved one's health. He aimed to create a unified system where all health data could be gathered, enabling caregivers, patients, and medical providers to see the whole picture. OtisHealth allows patients to integrate data from different sources, including wearable devices, and capture information outside clinical settings. + 36:25 + no + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +Marc Mar-Yohana is the CEO and Founder of OtisHealth, a personal health application and platform for patient-caregiver engagement, population health, and clinical research. +The conversation revolves around the origin and working principles of OtisHealth, a healthcare app designed to consolidate health information. Marc was motivated to start the app following the tragic death of his eight-year-old daughter, Constance, from an undiagnosed brain tumor. Despite being under the care of multiple health providers, the fragmentation of her medical data meant they missed the signs of her condition. +Marc has dedicated his life to developing better tools for families and caregivers to manage their loved one's health. He aimed to create a unified system where all health data could be gathered, enabling caregivers, patients, and medical providers to see the whole picture. OtisHealth allows patients to integrate data from different sources, including wearable devices, and capture information outside clinical settings. +The initial outreach strategy of OtisHealth through consumer channels was slow to get traction. The company switched to recruiting through organizations with health interests, such as health insurers or "payers," leading to a significant increase in users. Although not everyone uses the app daily, it is a crucial health management tool for those with chronic illnesses or emergencies. +The trustworthiness of OtisHealth is demonstrated through accreditation from the Electronic Healthcare Network Accreditation Commission, indicating that their practices meet or exceed federal regulatory requirements and industry guidelines. This, along with community outreach and educational content, helped build trust with users. +Marc's diverse corporate background gave him the skill set to lead OtisHealth, emphasizing the importance of team development and collaboration with other organizations, even competitors, to move the mission forward. +__ +OtisHealth (https://otishealth.net/) +Follow OtisHealth on Facebook (https://www.facebook.com/OtisHealth), LinkedIn (https://www.linkedin.com/company/otishealth/), Instagram (https://www.instagram.com/bloxisawesome/), or YouTube (https://www.youtube.com/channel/UC5yGWpOTCOJnbxjD1LnkMXg) +Follow Marc Mar-Yohana on LinkedIn (https://www.linkedin.com/in/marc-mar-yohana/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Marc Mar-Yohana, CEO and Founder of OtisHealth, a personal health application and a platform for patient-caregiver engagement, population health, and clinical research. Marc, thank you for joining me. +MARC: Victoria, I'm honored to be here. Thank you so much for inviting me to join you on this podcast. +VICTORIA: You're welcome. I'm excited to have you. So, why don't you just tell me a little bit about what's going on in your world right now? +MARC: Well, OtisHealth is keeping me pretty busy. So, I live in Northern California. My team is mostly in California, a little bit in Illinois. And we're busy every day, both supporting our members and working with clients. And so, it's exciting times, especially on our advocacy front. We work with organizations across the country to advocate for patient access to their health records and also for individuals themselves to improve their access to quality healthcare wherever they reside in the United States. +The advocacy, the work with our clients, and the work with our members keeps us super busy. Although I do still try to make time to hike in the beautiful scenery out here. I'm new to California. I'm originally from Illinois, so it's great to just be able to get out every once in a while for a hike in the area. +VICTORIA: That's wonderful. Have you made it to any redwood forest out there? +MARC: Yeah, Muir Woods, which is just north of us, north of the San Francisco Bay Area. Most of the time, we like to walk the coastline. So just north of Santa Cruz is a great state park known as Wilder State Ranch. And they have amazing views of the coastline, wonderful views of birds, as well as occasionally spotting whales, and dolphins, and sea otters along the coast. +VICTORIA: That's so cool. I had a friend, actually, who just went up there and went kayaking with the otters, and I'm very jealous. [laughter] It sounds beautiful. +MARC: Yeah, that can be fun. Otters are really cute creatures. And they can be aggressive too. There's a concern right now. There's one female otter that likes to grab people's surfboards. And I saw a video of a sea lion jumping on top of a sea kayak to steal a fish from a fisherman. +VICTORIA: I think if a sea otter or a sea lion wanted my vessel, a kayak or surfboard, I mean, you can have it. [laughter] You worked this hard. [laughs] +MARC: Yeah, they're pretty aggressive. They're more comfortable in the water than we are, so they [laughs] pretty much are in charge in the environment. +VICTORIA: That's right. We're in their house, right? So, I'm, like, okay, [laughs] you can have it. That's great. Oh, wonderful. I'm glad you still have time to get outside and enjoy hiking with your family, even though you're a very busy founder [chuckles] and very active advocate for your community. So, why don't you tell me how everything with OtisHealth got started? +MARC: So, it started with a tragedy, a horrible tragedy in my life. My daughter, Constance, who was eight years old at the time and had been previously diagnosed with autism, apraxia of speech, and epilepsy, died from an undiagnosed brain tumor. She had great healthcare. She had a neurologist, a pediatrician. She had therapists that saw her five days a week and, of course, her parents watching over her. Yet, we all missed the symptoms, the major illness that claimed her life. +And so, because all of her healthcare providers were on different systems, and as parents, we didn't have a system, there wasn't a place to put our observations together. And everyone attributed their observations of her changing condition to other medical concerns. And so, after she passed, I started to spend a couple of years trying to understand what happened. And I realized a big part of it was the information was in front of us. It was just in different people's hands. And when we put it together, we could have seen the whole picture that would have shown that she had a more serious illness. +And so I chose a new mission in my life: to abandon my corporate career and move into this role of developing a better set of tools for families and caregivers to manage their loved one's health. And so, our mission today is to work with families, caregivers, and people with chronic illness to give them better tools to manage their everyday health and the health of their loved ones, and thereby also improving lives in the community. +VICTORIA: Well, I love that out of the tragedy, you were able to find direction and purpose to solve this major problem, which I can relate to having moved across the country. Your medical records don't come with you. You have to basically kind of start all over, or they have to go get them from your past patients. It's not unified as a system, as you might think that is. [laughs] +MARC: That's absolutely right. Our data is spread out across different clinical sources. Just in the time I moved out here to California from Chicago, I saw five different providers just because I wanted to get some tests done. So, I had to go to a few different locations to do a normal battery of tests. And so, I had at least five different health records created just when I moved out here. And they're all in different systems, and they're not even on the same type of application. +So, to bring them together, I had to basically download them and put them in files on my desktop computer. With OtisHealth, I'm able to retrieve that data and put it onto one continuous record and watch it. But that's still just our clinical data, meaning data collected in clinical settings. We have more data to share of things that you and I observe as regular people or our families observe. And so, the part that's missing in the record is all the observations in the time that we're not in the physician, in a physician's office, or in the presence of a clinician. +We can; with our tools today, such as wearable watches, or blood pressure cuffs that are Bluetooth-connected, we can get a lot more data and share that back into our records so that we have a true baseline, not the once-a-year that I go to see a physician, and they say my blood pressure is high. And the next time I go, it's low. It's because we only have two data points over two years. Where today, with our technology and our capabilities, we can have a baseline of true data continuously throughout the year that will give the physician or care team more insights into how we're doing in terms of our health. +VICTORIA: That's so interesting. And it makes a lot of sense to me why someone would want to use this or why doctors would want to use this. And I'm curious, once you had this idea, how did you get that initial traction to get started with OtisHealth? +MARC: Initially, it was a little difficult. And this is kind of part of our lessons learned when we started the company. We started advertising on Facebook. This is after we launched the product. So, we launched in 2021. We had the idea that we were going to make this available to a lot of people. We knew a lot of folks that needed it. It was okay to get the first 100 or so people because there were folks that we knew needed the application or folks that were curious about it and wanted to try it. +And we started advertising through consumer channels such as Facebook, and LinkedIn, and other magazines to people that we knew had the need for the app. Yet, it was a very slow uptake. And the part of what we learned and we started applying to our marketing or our membership development or recruitment thesis is that the health records are kind of like an umbrella. +We don't think about the umbrella or going out to get an umbrella until it's raining, and for most people, it doesn't rain very often. And so, it's not something that people would use every day. In most cases, they use it only when they have an emergency or when they're managing their chronic illness or the chronic illness of a loved one. +And so, we eventually changed the way we were recruiting and started recruiting through other organizations, such as clients where we're able to get thousands of users through the client that has members. And then, slowly, over time, teach them the importance of managing their everyday health, and taking their own vitals, and recording that, and they record for themselves and their family. +VICTORIA: Right. So, you were able to offer the app for free for daily users because you found another group that was interested in having access to the data and having this app, right? +MARC: Yeah. So, anybody today can go to the Apple Store or the Google Play Store and they could download the app for free. And they can use the web version also. And they could share it with friends and family, which I always encourage people to do. So, if you have an emergency contact, invite them to your medical records; at least they have your basic medications, and allergies, and other key information in case of an emergency. +What we did in terms of our change of strategy early on is we started going to organizations that also had an interest in improving the health of their population and, in particular, health insurers or what we call in the industry payers. And so, payer organizations could be Medicaid, Medicare, or it could be employee health plan, one of the big health insurance companies like Blue Cross or UnitedHealthcare. They have an interest in people managing their everyday health. +And so, one of our clients right now, everyone that enrolls in one of their plans automatically gets enrolled in a version of OtisHealth specifically for their members. And those members could still invite people to join them on the platform, and those people can get on with OtisHealth. But the nice thing is now this payer has a way to both encourage healthier activity or healthier practices for their population and monitor if there's a problem. So, if somebody is missing medications, or not taking their medications on time, or has vitals that are tracking poorly, this gives the payer an opportunity to reach out and ask them if they need help managing their health. +VICTORIA: So, how does that dynamic affect how you measure successful engagement on the platform, like, a successful rate of engagement? +MARC: So, for us, most people don't use the app every day. Most of us don't even think about our health [laughs] on a daily basis from a standpoint of our medical health or clinical health. Sometimes those of us that exercise regularly think about it in those terms or eating healthy. But we don't think about keeping a record or using an app to maintain our health. +And so, for us, an active user is anybody that's logging in at least once a month to update their information. Our really great users are the ones who are using the reminder features to take supplements or take their medications. And so, I would say of the few thousand users that we have—we're approaching 10,000 right now active users—only a small percentage of those, maybe 10%, are actually using it on a daily basis for themselves or their family. +And so, for us, a good engagement and good practice is folks setting reminders on at least a weekly basis to take vitals, weigh themselves—something that would help them track their health over time—and if they're taking medications, to set daily reminders for the medications that they take. And so, we currently have far more people enrolled in OtisHealth and that, you know, 5,000, 6000 I mentioned that are active. But they basically bought the umbrella, and they just put it in their closet. They're waiting for that rainy day that they have to pull it out and start using it. +VICTORIA: That makes sense. And I'm already in my head going through the people in my family who would benefit from this where, you know, I have family members who have a learning and a physical disability, and tracking everything that they're supposed to be doing to maintain their health is quite difficult. So, I can definitely see the value in that and why people would want to use it. +And I think for, you know, healthcare apps, you have to build this high level of trust. You know, people are giving you all this data about their health information. So, how do you go about building a product that people can trust from the beginning? +MARC: One of the things we sort early in the life of OtisHealth is an accreditation. An accreditation is not required by law. It's not required by any institution necessarily. It's a third party that reviews our practices and our systems to see if we're actually following good privacy and security standards and practices. +And so we went live in November of 2021, and by the end of December of 2021, we already had our full accreditation in what's called a comprehensive level from a national established organization known as The Electronic Healthcare Network Accreditation Commission. +And so, that was the first step of making sure that folks understood that we took their privacy and security seriously. That accreditation means that our practices and our technology meets or exceeds federal regulatory requirements and industry guidelines. And that's just the first step. +Then after that, it's really a matter of people gain their trust because an accreditation itself doesn't necessarily mean that we trust that brand. That's just a basic starting point for us. After that, we publish articles about maintaining health. We have launched some videos about different aspects of our advocacy, such as with autism for caregivers. And we participate in community activities at the national level to improve patient access and to talk about how important it is to manage our own health and the health of our loved ones. +And so, it's a combination of both basic accreditations that show that we made the investment, and we provided a third party to critique us and to review us. And we actively maintain that accreditation is not a one-time stamp. And then, the second part is continuous outreach, and letting the community know what we're working on, what's important to us, so that, over time, they start to look at what we do and start to trust it and invite other people to trust it as well. +VICTORIA: That makes a lot of sense. And I'm curious if there were experiences from your corporate career that informed how you acted as a founder and what you prioritized. +MARC: I've had an odd corporate career. [laughs] So, I started my career as an engineer in manufacturing operations and in product development and then went down to as a consultant strategy in ops and market management, and then, later, investment management and private equity, and then, later, for a safety science company where I was managing global capital investments in technology and new operations. +And so, I've been fortunate that I've had a breadth of experience, from marketing to sales, to product and technology development, and infrastructure management. So, I had some basic skills that helped me understand what...well, the endeavor before I jumped into it because I spent a couple of years thinking about whether or not I even wanted to do something like this. +And then, I would say probably the most important part of my previous experience that I apply every day at OtisHealth is developing teams and developing collaboration with different organizations. You know, aside from the team that I have, our own staff, we also work very closely with other organizations, even competitors, to make sure that we're all successful. +And so, that collaboration across organizations that don't even have a necessarily contractual relationship is something that I brought over from my previous work and seeing how working across the industry, we can help each other and serve the mission. So, I think that was probably the most important part of my previous work experience that I apply today is this: building a team and building a coalition of organizations that want to move forward together. +VICTORIA: That's great. And I'm wondering if there was anything that surprised you in that early phase of building collaboration with other companies and understanding your users that changed the strategic direction you were going with in the app. +MARC: So, one of the things that I was really just in awe of was how willing people in the healthcare industry were to jump in and help out when we started talking. And so, many of the organizations that we work with, the founders or the senior staff within the nonprofits we work with, all have a story of why they're doing what they're doing. Many are brilliant people who could have taken their careers in many different directions, not in healthcare. And they chose to move forward in healthcare because of some personal experience in their life. +And so, as I learned about the people I was working with, I was surprised how quickly they just took me under their wing and said, "Hey, let's get you started marketing. Let's move OtisHealth forward." And so, we have organizations like Onyx and Invitae [SP] that are giving us support in data access. There's another organization that I can't mention yet; that's another private entity that has offered their support, and we hope to launch with them in the next couple of weeks. And so, we're forming these data access bridges to help get patients more access to their data, their loved ones' data. +And then, there's the nonprofits in the advocacy and standards organizations we work with, such as HL7, which is an international health technology standards organization, and DirectTrust, which is an organization that establishes trust networks in ecosystems, as well as the technology infrastructure behind how those systems communicate. And we work also with EHNAC, the accreditation commission. So, we not only are using the accreditation from EHNAC, we're on committees to advise them on future criteria for accreditation. +VICTORIA: That's really cool. I love that there's that collaboration and just openness and willingness to try to make things better and to invest in solutions together. +Mid-Roll Ad: +VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? +RICHARD: Hi, Victoria. +VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? +RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. +And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along. +And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. +VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? +RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. +The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. +And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. +VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken. +RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. +VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. +RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. +And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. +VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So... +[laughter] +RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. +VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... +RICHARD: [chuckles] Absolutely. +VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. +RICHARD: Yeah, it was a pleasure. Thank you. +VICTORIA: You mentioned advocacy. And I'm curious if you could say more about what advocacy are you doing or how does that blend into your business model and what you're doing with OtisHealth? +MARC: I'll give you an example. One of the organizations we belong to and I participate in personally is the Health Information Management System Society. And so, this is a professional society of healthcare IT professionals. And in Northern California, there's an advocacy committee that works directly with the state legislature to promote legislation that will improve the quality of healthcare for people in California. We actively talk to members of the legislature to tell them what bills we think are important. +The ones we focus on and the ones I personally focus on are the ones that improve access to our data and also improve our privacy. So, there's a legislation in California, as an example, that will prohibit access to people's healthcare data without proper legal warrant. So, it's basically extending HIPAA protections across any health app launched in California. And we, of course, are already HIPAA-compliant, so that's very easy for us. +There's also advocacy specific to certain health conditions. So, my daughter had autism. I work with the Autism Society here in California and also Achieve Tahoe, which is an organization that teaches skiing and other skills to people with disabilities in particular. This past season was my first season. I work primarily with children and young adults with autism and other developmental disorders. +And then we also partner with organizations when we think that they're aligned with some of our mission. And so we work with the Caregiver Action Network. We also will work with AARP and other organizations regarding caregiver rights and also teaching caregivers how to access the healthcare data of their loved ones and how to take care of themselves personally. +VICTORIA: That's wonderful. And I guess it's not really a question, but I saw that autism service dogs are a thing, and I just thought that was really cool. [laughs] +MARC: Yeah, OtisHealth is named after Constance's autism service dog, Otis. And so, service dogs are extraordinary animals. They're highly trained. Otis had been trained for two years before we received him. He was trained specifically for Constance's needs, and he kept her safe. And that was the primary interest in Otis is observing things that she...because of her cognitive limitations, wasn't always aware of her surroundings and wasn't always safe. And so, the dog maintained her safety and her boundaries and kept her focused, as well as just basically blocked her if she was going to do something that was unsafe. +So, there are many different kinds of service dogs, and I'm talking specifically about ADA, the Americans with Disability Act type service dogs. These aren't, like, companion dogs or therapy dogs. These are truly highly trained animals that are focused on specific tasks to help an individual be safer, more free, or have more abilities than their disabilities may allow. +VICTORIA: Well, I love that. And I like that the app is named after her dog as well. That's just very sweet. And I love that that's how that worked. And I'm curious, what's on the horizon? What are you most excited about for OtisHealth in the next year? +MARC: Like all startups, we have [laughs] a lot of plans. And we've been invited to speak at some conferences. I spoke at two already this year. And I have another one coming up in Washington, D.C., where we're going to advocate, again, for patient access. And this is primarily talking to the health systems themselves in adopting technology that makes it easier for patients to securely access their health records. +And so, we're excited about that movement in the industry to recognize and start to act on that need for patients to be able to access their health records. And we work with our partners to promote that and also with the federal government. We work with the health and human services to promote this access. And we were published in a report earlier this year because of our technology demonstration with health and human services. And it sounds like it's finally getting some real traction in hospital systems. And members of the Federal Congress are also saying that this is something we need to move forward with in a more aggressive manner. +On a more direct path, we're excited our membership's growing. We've had tens of thousands of people register to use the app, with thousands actively using it today. We're working on some new programs right now for payers and for providers that will improve health outcomes and within their populations, as well as bring on hundreds of thousands of other people on the app. +We're really excited to know that we're getting both recognized for the work that we're doing and that people are starting to understand the importance of managing everyday health, whether it's with OtisHealth or another application. +VICTORIA: Well, I love being excited for these opportunities to advocate for your product and for the mission behind the product. I'm not going to recommend being excited about going to D.C. during the summer. [laughs] Last time I was there when I landed at 9:00 p.m., it was 90 degrees outside [chuckles] and humid, like, 90% humidity. But it's great to have access to people who care and are trying to make things better and have that voice. I'm excited to see you grow. +And then, it's been two years since you started the app. I wonder, if you could go back in time to when you first were getting started, what advice would you give yourself? +MARC: So, this is a really hard thing for anybody to look back and say that they'd like to change a few things. There are things I would change. I have a lot of experience managing large, sophisticated programs. Because in the past I had large budgets, it was really easy to maintain strict discipline around the implementation. And I think I was too loose in the implementation process at the onset of OtisHealth. +I would have been more disciplined around my program management and the accountability that I had to developers I was using. As a startup, I didn't have a large development team in-house. I needed to use external parties. And I should have been a little more closely on top of that process. +The other things that we experienced were primarily a result of pivots. We were constantly pivoting as we were learning. I think having a team to review our process and pivot more quickly is really critical. You don't want to pivot 20 times a week. You need to stay focused for a while, but also having friends or advisors or members of your team that can help you assess when a pivot is necessary, or a new opportunity presents itself, I think, is critical. And so, we all know, as founders, the team is key. And I think the earlier you engage a team and not be bashful by asking for advice, the better. +VICTORIA: I love that. And I'm curious if you have any advice from your program or from your startup career now on choosing the right development teams. And how do you find those right partners to actually build the app and have that accountability? +MARC: So, I would say the number one thing that I've learned, that I knew previously, but I really appreciate it more now as a founder of a small company, is you need mission alignment, not just company to company, but person to person. And I took my time picking advisors to join us, and I took my time getting people on board to OtisHealth. We pick folks that we believe understand what we're doing, and we take our time and make sure that they appreciate it and that we're comfortable with them. +Our startup is too small to make a bad hire or to have the wrong perspective because somebody has other motives, such as just making money. If I was providing advice in terms of picking teams or picking vendors to work with, I would say take it slow. Don't rush, even though you may be in a rush, or we may be in a rush to get moving, either for financial reasons or personal reasons. +It's important just to feel comfortable. Get to know folks. Meet them in person if you can and spend a few hours with them at a time [laughs], just to make sure that they believe in you, and you believe in them, and that you have a common vision. Because when things get rough or tough, financially or otherwise, you need people that are going to be able to stick through it and work with you. +VICTORIA: That makes a lot of sense. There's a lot of pivots happening. You want everyone to be on the same page. And you don't want to have to be corralling everyone all the time if they have competing priorities, so that makes a lot of sense. +MARC: Absolutely. Just to be clearer on that, we all run into challenges. So, in some cases, we had to make some financial sacrifices, and everyone did it together. You really need people that are that committed that say, "Okay, I understand where we are, and so, I'm willing to take a pay cut for a while or not get paid for a while until we can get this spec started again." Even vendors I work with today that are strategic vendors understand that and have helped us financially when we need some time to get more revenue in. +VICTORIA: Great. And so, when you were building a healthcare app, was there people you needed to have on your team who had that exact specialty in either patient care, or medical records, or something like that? +MARC: Yes, yeah, you need experts. So, I'm a quick read. I mean, I spent a couple of years learning the industry and understanding the technology. But the person that's our IT director he has over 25 years of experience in healthcare IT systems, so he is the expert in-house. We also have advisors on our team that are experts in payer services and payer systems, launching healthcare apps, managing standards, and managing SaaS services. We have a data and an AI expert, and a clinical research specialist. We also have physicians we refer to. [laughs] So, we have a pretty big entourage of individuals that we go to for very specific advice and work. +VICTORIA: That makes a lot of sense. Let's see, what question should I be asking that I haven't asked yet? +MARC: You know, I think most of the people listening to this podcast are technical founders. And it was surprising to me, and I had some founders contact me, asked for some free advice, which I'm happy to do, but they didn't seem sincere in their interest in being in healthcare. And one thing I told them, and I would say to anybody that's interested in being a healthcare technology developer, is you have to have a reason to do it besides the money. +It will be a really hard battle to move forward with a technology if the only motivation is a financial opportunity. That isn't going to sustain the pivots or the development. You'll run into a lot of walls, primarily because everyone will see it. Everyone in the industry sees those players come in that just have a financial interest, and the consumers see it, and they don't like it. +So, my advice to anybody that wants to develop technology in healthcare is you have to be a little sincere about it and have a real reason to do it beyond just making money, and I think you'll find it more rewarding. There's so much need for healthcare technology and better technology out there. So, I welcome folks to join the fight, the battle, or the opportunities. But I would say that just come in with the idea that you're helping people, not just making money. +VICTORIA: I think that rings true for any business you're in, right? But especially in healthcare because it is this big target. Even in consulting, if you're doing business development and you're thinking of working on health IT projects, there's just a huge market that you have to narrow down and figure out where you're going to be. So, if you don't have that intrinsic motivation, it can be overwhelming and scattered, and then people won't connect with you, right? Because everybody is going after the same thing. +MARC: That's exactly right. One of the conferences I went to earlier this year, a speaker got up and said, "People invest in people, or people make deals with other people." We talk about companies signing a deal with another company, but it's really one person trusting another person. Whether it's in healthcare or another industry, obviously, that trust needs to happen. At some point, if I don't trust the individual I'm talking to, I'm less likely to have a deal with that company. +VICTORIA: Right. It's like; I don't know how, you know, it doesn't really matter how impressive your credentials are. If there's not a basic level of trust, you might not move forward with it, so that makes a lot of sense to me. +MARC: Yeah, that's absolutely right, Victoria. +VICTORIA: Absolutely. Is there anything else that you'd like to promote at the end of this podcast? +MARC: I'd love for folks to try OtisHealth. If you have family that have chronic medical needs or need help managing their medical information, please download OtisHealth, help them join. There are videos on YouTube that explain how to use it if you need some guidance, but we believe most of it is self-explanatory. +We are continuously adding data access points. We're going to be launching this week new versions of OtisHealth that have access privileges for people in New York and Nevada and parts of California and Colorado. And so that means that with the app, once you're ID-proofed on the app, you can use it to get your medical records from different sources without having to log into all these different patient portals. So please try it. Use it for yourself but especially use it for your family or anybody who you care for. We'd love to get your feedback as you use the app too. +VICTORIA: That's great. And I'm actually already thinking about...next week; I'm going to be going to The San Diego Annual Veterans Stand Down, where anyone who is experiencing homelessness can come in and get access to all the services that they might need, whether it's legal, or healthcare, or dentistry, showers, food, all of these things. And I'm curious if that organization might benefit from having a tool like that for their users. So, I'll be talking about it. [laughs] +MARC: Oh, thank you so much. That'd be wonderful. Thank you. +VICTORIA: That's great. Well, thank you so much, Marc, for joining us. +MARC: My pleasure. Thank you, Victoria, for having me on the show. +VICTORIA: Excellent. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Marc Mar-Yohana. + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +
+ +

Marc Mar-Yohana is the CEO and Founder of OtisHealth, a personal health application and platform for patient-caregiver engagement, population health, and clinical research.

+ +

The conversation revolves around the origin and working principles of OtisHealth, a healthcare app designed to consolidate health information. Marc was motivated to start the app following the tragic death of his eight-year-old daughter, Constance, from an undiagnosed brain tumor. Despite being under the care of multiple health providers, the fragmentation of her medical data meant they missed the signs of her condition.

+ +

Marc has dedicated his life to developing better tools for families and caregivers to manage their loved one's health. He aimed to create a unified system where all health data could be gathered, enabling caregivers, patients, and medical providers to see the whole picture. OtisHealth allows patients to integrate data from different sources, including wearable devices, and capture information outside clinical settings.

+ +

The initial outreach strategy of OtisHealth through consumer channels was slow to get traction. The company switched to recruiting through organizations with health interests, such as health insurers or "payers," leading to a significant increase in users. Although not everyone uses the app daily, it is a crucial health management tool for those with chronic illnesses or emergencies.

+ +

The trustworthiness of OtisHealth is demonstrated through accreditation from the Electronic Healthcare Network Accreditation Commission, indicating that their practices meet or exceed federal regulatory requirements and industry guidelines. This, along with community outreach and educational content, helped build trust with users.

+ +

Marc's diverse corporate background gave him the skill set to lead OtisHealth, emphasizing the importance of team development and collaboration with other organizations, even competitors, to move the mission forward.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Marc Mar-Yohana, CEO and Founder of OtisHealth, a personal health application and a platform for patient-caregiver engagement, population health, and clinical research. Marc, thank you for joining me.

+ +

MARC: Victoria, I'm honored to be here. Thank you so much for inviting me to join you on this podcast.

+ +

VICTORIA: You're welcome. I'm excited to have you. So, why don't you just tell me a little bit about what's going on in your world right now?

+ +

MARC: Well, OtisHealth is keeping me pretty busy. So, I live in Northern California. My team is mostly in California, a little bit in Illinois. And we're busy every day, both supporting our members and working with clients. And so, it's exciting times, especially on our advocacy front. We work with organizations across the country to advocate for patient access to their health records and also for individuals themselves to improve their access to quality healthcare wherever they reside in the United States.

+ +

The advocacy, the work with our clients, and the work with our members keeps us super busy. Although I do still try to make time to hike in the beautiful scenery out here. I'm new to California. I'm originally from Illinois, so it's great to just be able to get out every once in a while for a hike in the area.

+ +

VICTORIA: That's wonderful. Have you made it to any redwood forest out there?

+ +

MARC: Yeah, Muir Woods, which is just north of us, north of the San Francisco Bay Area. Most of the time, we like to walk the coastline. So just north of Santa Cruz is a great state park known as Wilder State Ranch. And they have amazing views of the coastline, wonderful views of birds, as well as occasionally spotting whales, and dolphins, and sea otters along the coast.

+ +

VICTORIA: That's so cool. I had a friend, actually, who just went up there and went kayaking with the otters, and I'm very jealous. [laughter] It sounds beautiful.

+ +

MARC: Yeah, that can be fun. Otters are really cute creatures. And they can be aggressive too. There's a concern right now. There's one female otter that likes to grab people's surfboards. And I saw a video of a sea lion jumping on top of a sea kayak to steal a fish from a fisherman.

+ +

VICTORIA: I think if a sea otter or a sea lion wanted my vessel, a kayak or surfboard, I mean, you can have it. [laughter] You worked this hard. [laughs]

+ +

MARC: Yeah, they're pretty aggressive. They're more comfortable in the water than we are, so they [laughs] pretty much are in charge in the environment.

+ +

VICTORIA: That's right. We're in their house, right? So, I'm, like, okay, [laughs] you can have it. That's great. Oh, wonderful. I'm glad you still have time to get outside and enjoy hiking with your family, even though you're a very busy founder [chuckles] and very active advocate for your community. So, why don't you tell me how everything with OtisHealth got started?

+ +

MARC: So, it started with a tragedy, a horrible tragedy in my life. My daughter, Constance, who was eight years old at the time and had been previously diagnosed with autism, apraxia of speech, and epilepsy, died from an undiagnosed brain tumor. She had great healthcare. She had a neurologist, a pediatrician. She had therapists that saw her five days a week and, of course, her parents watching over her. Yet, we all missed the symptoms, the major illness that claimed her life.

+ +

And so, because all of her healthcare providers were on different systems, and as parents, we didn't have a system, there wasn't a place to put our observations together. And everyone attributed their observations of her changing condition to other medical concerns. And so, after she passed, I started to spend a couple of years trying to understand what happened. And I realized a big part of it was the information was in front of us. It was just in different people's hands. And when we put it together, we could have seen the whole picture that would have shown that she had a more serious illness.

+ +

And so I chose a new mission in my life: to abandon my corporate career and move into this role of developing a better set of tools for families and caregivers to manage their loved one's health. And so, our mission today is to work with families, caregivers, and people with chronic illness to give them better tools to manage their everyday health and the health of their loved ones, and thereby also improving lives in the community.

+ +

VICTORIA: Well, I love that out of the tragedy, you were able to find direction and purpose to solve this major problem, which I can relate to having moved across the country. Your medical records don't come with you. You have to basically kind of start all over, or they have to go get them from your past patients. It's not unified as a system, as you might think that is. [laughs]

+ +

MARC: That's absolutely right. Our data is spread out across different clinical sources. Just in the time I moved out here to California from Chicago, I saw five different providers just because I wanted to get some tests done. So, I had to go to a few different locations to do a normal battery of tests. And so, I had at least five different health records created just when I moved out here. And they're all in different systems, and they're not even on the same type of application.

+ +

So, to bring them together, I had to basically download them and put them in files on my desktop computer. With OtisHealth, I'm able to retrieve that data and put it onto one continuous record and watch it. But that's still just our clinical data, meaning data collected in clinical settings. We have more data to share of things that you and I observe as regular people or our families observe. And so, the part that's missing in the record is all the observations in the time that we're not in the physician, in a physician's office, or in the presence of a clinician.

+ +

We can; with our tools today, such as wearable watches, or blood pressure cuffs that are Bluetooth-connected, we can get a lot more data and share that back into our records so that we have a true baseline, not the once-a-year that I go to see a physician, and they say my blood pressure is high. And the next time I go, it's low. It's because we only have two data points over two years. Where today, with our technology and our capabilities, we can have a baseline of true data continuously throughout the year that will give the physician or care team more insights into how we're doing in terms of our health.

+ +

VICTORIA: That's so interesting. And it makes a lot of sense to me why someone would want to use this or why doctors would want to use this. And I'm curious, once you had this idea, how did you get that initial traction to get started with OtisHealth?

+ +

MARC: Initially, it was a little difficult. And this is kind of part of our lessons learned when we started the company. We started advertising on Facebook. This is after we launched the product. So, we launched in 2021. We had the idea that we were going to make this available to a lot of people. We knew a lot of folks that needed it. It was okay to get the first 100 or so people because there were folks that we knew needed the application or folks that were curious about it and wanted to try it.

+ +

And we started advertising through consumer channels such as Facebook, and LinkedIn, and other magazines to people that we knew had the need for the app. Yet, it was a very slow uptake. And the part of what we learned and we started applying to our marketing or our membership development or recruitment thesis is that the health records are kind of like an umbrella.

+ +

We don't think about the umbrella or going out to get an umbrella until it's raining, and for most people, it doesn't rain very often. And so, it's not something that people would use every day. In most cases, they use it only when they have an emergency or when they're managing their chronic illness or the chronic illness of a loved one.

+ +

And so, we eventually changed the way we were recruiting and started recruiting through other organizations, such as clients where we're able to get thousands of users through the client that has members. And then, slowly, over time, teach them the importance of managing their everyday health, and taking their own vitals, and recording that, and they record for themselves and their family.

+ +

VICTORIA: Right. So, you were able to offer the app for free for daily users because you found another group that was interested in having access to the data and having this app, right?

+ +

MARC: Yeah. So, anybody today can go to the Apple Store or the Google Play Store and they could download the app for free. And they can use the web version also. And they could share it with friends and family, which I always encourage people to do. So, if you have an emergency contact, invite them to your medical records; at least they have your basic medications, and allergies, and other key information in case of an emergency.

+ +

What we did in terms of our change of strategy early on is we started going to organizations that also had an interest in improving the health of their population and, in particular, health insurers or what we call in the industry payers. And so, payer organizations could be Medicaid, Medicare, or it could be employee health plan, one of the big health insurance companies like Blue Cross or UnitedHealthcare. They have an interest in people managing their everyday health.

+ +

And so, one of our clients right now, everyone that enrolls in one of their plans automatically gets enrolled in a version of OtisHealth specifically for their members. And those members could still invite people to join them on the platform, and those people can get on with OtisHealth. But the nice thing is now this payer has a way to both encourage healthier activity or healthier practices for their population and monitor if there's a problem. So, if somebody is missing medications, or not taking their medications on time, or has vitals that are tracking poorly, this gives the payer an opportunity to reach out and ask them if they need help managing their health.

+ +

VICTORIA: So, how does that dynamic affect how you measure successful engagement on the platform, like, a successful rate of engagement?

+ +

MARC: So, for us, most people don't use the app every day. Most of us don't even think about our health [laughs] on a daily basis from a standpoint of our medical health or clinical health. Sometimes those of us that exercise regularly think about it in those terms or eating healthy. But we don't think about keeping a record or using an app to maintain our health.

+ +

And so, for us, an active user is anybody that's logging in at least once a month to update their information. Our really great users are the ones who are using the reminder features to take supplements or take their medications. And so, I would say of the few thousand users that we have—we're approaching 10,000 right now active users—only a small percentage of those, maybe 10%, are actually using it on a daily basis for themselves or their family.

+ +

And so, for us, a good engagement and good practice is folks setting reminders on at least a weekly basis to take vitals, weigh themselves—something that would help them track their health over time—and if they're taking medications, to set daily reminders for the medications that they take. And so, we currently have far more people enrolled in OtisHealth and that, you know, 5,000, 6000 I mentioned that are active. But they basically bought the umbrella, and they just put it in their closet. They're waiting for that rainy day that they have to pull it out and start using it.

+ +

VICTORIA: That makes sense. And I'm already in my head going through the people in my family who would benefit from this where, you know, I have family members who have a learning and a physical disability, and tracking everything that they're supposed to be doing to maintain their health is quite difficult. So, I can definitely see the value in that and why people would want to use it.

+ +

And I think for, you know, healthcare apps, you have to build this high level of trust. You know, people are giving you all this data about their health information. So, how do you go about building a product that people can trust from the beginning?

+ +

MARC: One of the things we sort early in the life of OtisHealth is an accreditation. An accreditation is not required by law. It's not required by any institution necessarily. It's a third party that reviews our practices and our systems to see if we're actually following good privacy and security standards and practices.

+ +

And so we went live in November of 2021, and by the end of December of 2021, we already had our full accreditation in what's called a comprehensive level from a national established organization known as The Electronic Healthcare Network Accreditation Commission.

+ +

And so, that was the first step of making sure that folks understood that we took their privacy and security seriously. That accreditation means that our practices and our technology meets or exceeds federal regulatory requirements and industry guidelines. And that's just the first step.

+ +

Then after that, it's really a matter of people gain their trust because an accreditation itself doesn't necessarily mean that we trust that brand. That's just a basic starting point for us. After that, we publish articles about maintaining health. We have launched some videos about different aspects of our advocacy, such as with autism for caregivers. And we participate in community activities at the national level to improve patient access and to talk about how important it is to manage our own health and the health of our loved ones.

+ +

And so, it's a combination of both basic accreditations that show that we made the investment, and we provided a third party to critique us and to review us. And we actively maintain that accreditation is not a one-time stamp. And then, the second part is continuous outreach, and letting the community know what we're working on, what's important to us, so that, over time, they start to look at what we do and start to trust it and invite other people to trust it as well.

+ +

VICTORIA: That makes a lot of sense. And I'm curious if there were experiences from your corporate career that informed how you acted as a founder and what you prioritized.

+ +

MARC: I've had an odd corporate career. [laughs] So, I started my career as an engineer in manufacturing operations and in product development and then went down to as a consultant strategy in ops and market management, and then, later, investment management and private equity, and then, later, for a safety science company where I was managing global capital investments in technology and new operations.

+ +

And so, I've been fortunate that I've had a breadth of experience, from marketing to sales, to product and technology development, and infrastructure management. So, I had some basic skills that helped me understand what...well, the endeavor before I jumped into it because I spent a couple of years thinking about whether or not I even wanted to do something like this.

+ +

And then, I would say probably the most important part of my previous experience that I apply every day at OtisHealth is developing teams and developing collaboration with different organizations. You know, aside from the team that I have, our own staff, we also work very closely with other organizations, even competitors, to make sure that we're all successful.

+ +

And so, that collaboration across organizations that don't even have a necessarily contractual relationship is something that I brought over from my previous work and seeing how working across the industry, we can help each other and serve the mission. So, I think that was probably the most important part of my previous work experience that I apply today is this: building a team and building a coalition of organizations that want to move forward together.

+ +

VICTORIA: That's great. And I'm wondering if there was anything that surprised you in that early phase of building collaboration with other companies and understanding your users that changed the strategic direction you were going with in the app.

+ +

MARC: So, one of the things that I was really just in awe of was how willing people in the healthcare industry were to jump in and help out when we started talking. And so, many of the organizations that we work with, the founders or the senior staff within the nonprofits we work with, all have a story of why they're doing what they're doing. Many are brilliant people who could have taken their careers in many different directions, not in healthcare. And they chose to move forward in healthcare because of some personal experience in their life.

+ +

And so, as I learned about the people I was working with, I was surprised how quickly they just took me under their wing and said, "Hey, let's get you started marketing. Let's move OtisHealth forward." And so, we have organizations like Onyx and Invitae [SP] that are giving us support in data access. There's another organization that I can't mention yet; that's another private entity that has offered their support, and we hope to launch with them in the next couple of weeks. And so, we're forming these data access bridges to help get patients more access to their data, their loved ones' data.

+ +

And then, there's the nonprofits in the advocacy and standards organizations we work with, such as HL7, which is an international health technology standards organization, and DirectTrust, which is an organization that establishes trust networks in ecosystems, as well as the technology infrastructure behind how those systems communicate. And we work also with EHNAC, the accreditation commission. So, we not only are using the accreditation from EHNAC, we're on committees to advise them on future criteria for accreditation.

+ +

VICTORIA: That's really cool. I love that there's that collaboration and just openness and willingness to try to make things better and to invest in solutions together.

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So...

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

VICTORIA: You mentioned advocacy. And I'm curious if you could say more about what advocacy are you doing or how does that blend into your business model and what you're doing with OtisHealth?

+ +

MARC: I'll give you an example. One of the organizations we belong to and I participate in personally is the Health Information Management System Society. And so, this is a professional society of healthcare IT professionals. And in Northern California, there's an advocacy committee that works directly with the state legislature to promote legislation that will improve the quality of healthcare for people in California. We actively talk to members of the legislature to tell them what bills we think are important.

+ +

The ones we focus on and the ones I personally focus on are the ones that improve access to our data and also improve our privacy. So, there's a legislation in California, as an example, that will prohibit access to people's healthcare data without proper legal warrant. So, it's basically extending HIPAA protections across any health app launched in California. And we, of course, are already HIPAA-compliant, so that's very easy for us.

+ +

There's also advocacy specific to certain health conditions. So, my daughter had autism. I work with the Autism Society here in California and also Achieve Tahoe, which is an organization that teaches skiing and other skills to people with disabilities in particular. This past season was my first season. I work primarily with children and young adults with autism and other developmental disorders.

+ +

And then we also partner with organizations when we think that they're aligned with some of our mission. And so we work with the Caregiver Action Network. We also will work with AARP and other organizations regarding caregiver rights and also teaching caregivers how to access the healthcare data of their loved ones and how to take care of themselves personally.

+ +

VICTORIA: That's wonderful. And I guess it's not really a question, but I saw that autism service dogs are a thing, and I just thought that was really cool. [laughs]

+ +

MARC: Yeah, OtisHealth is named after Constance's autism service dog, Otis. And so, service dogs are extraordinary animals. They're highly trained. Otis had been trained for two years before we received him. He was trained specifically for Constance's needs, and he kept her safe. And that was the primary interest in Otis is observing things that she...because of her cognitive limitations, wasn't always aware of her surroundings and wasn't always safe. And so, the dog maintained her safety and her boundaries and kept her focused, as well as just basically blocked her if she was going to do something that was unsafe.

+ +

So, there are many different kinds of service dogs, and I'm talking specifically about ADA, the Americans with Disability Act type service dogs. These aren't, like, companion dogs or therapy dogs. These are truly highly trained animals that are focused on specific tasks to help an individual be safer, more free, or have more abilities than their disabilities may allow.

+ +

VICTORIA: Well, I love that. And I like that the app is named after her dog as well. That's just very sweet. And I love that that's how that worked. And I'm curious, what's on the horizon? What are you most excited about for OtisHealth in the next year?

+ +

MARC: Like all startups, we have [laughs] a lot of plans. And we've been invited to speak at some conferences. I spoke at two already this year. And I have another one coming up in Washington, D.C., where we're going to advocate, again, for patient access. And this is primarily talking to the health systems themselves in adopting technology that makes it easier for patients to securely access their health records.

+ +

And so, we're excited about that movement in the industry to recognize and start to act on that need for patients to be able to access their health records. And we work with our partners to promote that and also with the federal government. We work with the health and human services to promote this access. And we were published in a report earlier this year because of our technology demonstration with health and human services. And it sounds like it's finally getting some real traction in hospital systems. And members of the Federal Congress are also saying that this is something we need to move forward with in a more aggressive manner.

+ +

On a more direct path, we're excited our membership's growing. We've had tens of thousands of people register to use the app, with thousands actively using it today. We're working on some new programs right now for payers and for providers that will improve health outcomes and within their populations, as well as bring on hundreds of thousands of other people on the app.

+ +

We're really excited to know that we're getting both recognized for the work that we're doing and that people are starting to understand the importance of managing everyday health, whether it's with OtisHealth or another application.

+ +

VICTORIA: Well, I love being excited for these opportunities to advocate for your product and for the mission behind the product. I'm not going to recommend being excited about going to D.C. during the summer. [laughs] Last time I was there when I landed at 9:00 p.m., it was 90 degrees outside [chuckles] and humid, like, 90% humidity. But it's great to have access to people who care and are trying to make things better and have that voice. I'm excited to see you grow.

+ +

And then, it's been two years since you started the app. I wonder, if you could go back in time to when you first were getting started, what advice would you give yourself?

+ +

MARC: So, this is a really hard thing for anybody to look back and say that they'd like to change a few things. There are things I would change. I have a lot of experience managing large, sophisticated programs. Because in the past I had large budgets, it was really easy to maintain strict discipline around the implementation. And I think I was too loose in the implementation process at the onset of OtisHealth.

+ +

I would have been more disciplined around my program management and the accountability that I had to developers I was using. As a startup, I didn't have a large development team in-house. I needed to use external parties. And I should have been a little more closely on top of that process.

+ +

The other things that we experienced were primarily a result of pivots. We were constantly pivoting as we were learning. I think having a team to review our process and pivot more quickly is really critical. You don't want to pivot 20 times a week. You need to stay focused for a while, but also having friends or advisors or members of your team that can help you assess when a pivot is necessary, or a new opportunity presents itself, I think, is critical. And so, we all know, as founders, the team is key. And I think the earlier you engage a team and not be bashful by asking for advice, the better.

+ +

VICTORIA: I love that. And I'm curious if you have any advice from your program or from your startup career now on choosing the right development teams. And how do you find those right partners to actually build the app and have that accountability?

+ +

MARC: So, I would say the number one thing that I've learned, that I knew previously, but I really appreciate it more now as a founder of a small company, is you need mission alignment, not just company to company, but person to person. And I took my time picking advisors to join us, and I took my time getting people on board to OtisHealth. We pick folks that we believe understand what we're doing, and we take our time and make sure that they appreciate it and that we're comfortable with them.

+ +

Our startup is too small to make a bad hire or to have the wrong perspective because somebody has other motives, such as just making money. If I was providing advice in terms of picking teams or picking vendors to work with, I would say take it slow. Don't rush, even though you may be in a rush, or we may be in a rush to get moving, either for financial reasons or personal reasons.

+ +

It's important just to feel comfortable. Get to know folks. Meet them in person if you can and spend a few hours with them at a time [laughs], just to make sure that they believe in you, and you believe in them, and that you have a common vision. Because when things get rough or tough, financially or otherwise, you need people that are going to be able to stick through it and work with you.

+ +

VICTORIA: That makes a lot of sense. There's a lot of pivots happening. You want everyone to be on the same page. And you don't want to have to be corralling everyone all the time if they have competing priorities, so that makes a lot of sense.

+ +

MARC: Absolutely. Just to be clearer on that, we all run into challenges. So, in some cases, we had to make some financial sacrifices, and everyone did it together. You really need people that are that committed that say, "Okay, I understand where we are, and so, I'm willing to take a pay cut for a while or not get paid for a while until we can get this spec started again." Even vendors I work with today that are strategic vendors understand that and have helped us financially when we need some time to get more revenue in.

+ +

VICTORIA: Great. And so, when you were building a healthcare app, was there people you needed to have on your team who had that exact specialty in either patient care, or medical records, or something like that?

+ +

MARC: Yes, yeah, you need experts. So, I'm a quick read. I mean, I spent a couple of years learning the industry and understanding the technology. But the person that's our IT director he has over 25 years of experience in healthcare IT systems, so he is the expert in-house. We also have advisors on our team that are experts in payer services and payer systems, launching healthcare apps, managing standards, and managing SaaS services. We have a data and an AI expert, and a clinical research specialist. We also have physicians we refer to. [laughs] So, we have a pretty big entourage of individuals that we go to for very specific advice and work.

+ +

VICTORIA: That makes a lot of sense. Let's see, what question should I be asking that I haven't asked yet?

+ +

MARC: You know, I think most of the people listening to this podcast are technical founders. And it was surprising to me, and I had some founders contact me, asked for some free advice, which I'm happy to do, but they didn't seem sincere in their interest in being in healthcare. And one thing I told them, and I would say to anybody that's interested in being a healthcare technology developer, is you have to have a reason to do it besides the money.

+ +

It will be a really hard battle to move forward with a technology if the only motivation is a financial opportunity. That isn't going to sustain the pivots or the development. You'll run into a lot of walls, primarily because everyone will see it. Everyone in the industry sees those players come in that just have a financial interest, and the consumers see it, and they don't like it.

+ +

So, my advice to anybody that wants to develop technology in healthcare is you have to be a little sincere about it and have a real reason to do it beyond just making money, and I think you'll find it more rewarding. There's so much need for healthcare technology and better technology out there. So, I welcome folks to join the fight, the battle, or the opportunities. But I would say that just come in with the idea that you're helping people, not just making money.

+ +

VICTORIA: I think that rings true for any business you're in, right? But especially in healthcare because it is this big target. Even in consulting, if you're doing business development and you're thinking of working on health IT projects, there's just a huge market that you have to narrow down and figure out where you're going to be. So, if you don't have that intrinsic motivation, it can be overwhelming and scattered, and then people won't connect with you, right? Because everybody is going after the same thing.

+ +

MARC: That's exactly right. One of the conferences I went to earlier this year, a speaker got up and said, "People invest in people, or people make deals with other people." We talk about companies signing a deal with another company, but it's really one person trusting another person. Whether it's in healthcare or another industry, obviously, that trust needs to happen. At some point, if I don't trust the individual I'm talking to, I'm less likely to have a deal with that company.

+ +

VICTORIA: Right. It's like; I don't know how, you know, it doesn't really matter how impressive your credentials are. If there's not a basic level of trust, you might not move forward with it, so that makes a lot of sense to me.

+ +

MARC: Yeah, that's absolutely right, Victoria.

+ +

VICTORIA: Absolutely. Is there anything else that you'd like to promote at the end of this podcast?

+ +

MARC: I'd love for folks to try OtisHealth. If you have family that have chronic medical needs or need help managing their medical information, please download OtisHealth, help them join. There are videos on YouTube that explain how to use it if you need some guidance, but we believe most of it is self-explanatory.

+ +

We are continuously adding data access points. We're going to be launching this week new versions of OtisHealth that have access privileges for people in New York and Nevada and parts of California and Colorado. And so that means that with the app, once you're ID-proofed on the app, you can use it to get your medical records from different sources without having to log into all these different patient portals. So please try it. Use it for yourself but especially use it for your family or anybody who you care for. We'd love to get your feedback as you use the app too.

+ +

VICTORIA: That's great. And I'm actually already thinking about...next week; I'm going to be going to The San Diego Annual Veterans Stand Down, where anyone who is experiencing homelessness can come in and get access to all the services that they might need, whether it's legal, or healthcare, or dentistry, showers, food, all of these things. And I'm curious if that organization might benefit from having a tool like that for their users. So, I'll be talking about it. [laughs]

+ +

MARC: Oh, thank you so much. That'd be wonderful. Thank you.

+ +

VICTORIA: That's great. Well, thank you so much, Marc, for joining us.

+ +

MARC: My pleasure. Thank you, Victoria, for having me on the show.

+ +

VICTORIA: Excellent.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Marc Mar-Yohana.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +
+ +

Marc Mar-Yohana is the CEO and Founder of OtisHealth, a personal health application and platform for patient-caregiver engagement, population health, and clinical research.

+ +

The conversation revolves around the origin and working principles of OtisHealth, a healthcare app designed to consolidate health information. Marc was motivated to start the app following the tragic death of his eight-year-old daughter, Constance, from an undiagnosed brain tumor. Despite being under the care of multiple health providers, the fragmentation of her medical data meant they missed the signs of her condition.

+ +

Marc has dedicated his life to developing better tools for families and caregivers to manage their loved one's health. He aimed to create a unified system where all health data could be gathered, enabling caregivers, patients, and medical providers to see the whole picture. OtisHealth allows patients to integrate data from different sources, including wearable devices, and capture information outside clinical settings.

+ +

The initial outreach strategy of OtisHealth through consumer channels was slow to get traction. The company switched to recruiting through organizations with health interests, such as health insurers or "payers," leading to a significant increase in users. Although not everyone uses the app daily, it is a crucial health management tool for those with chronic illnesses or emergencies.

+ +

The trustworthiness of OtisHealth is demonstrated through accreditation from the Electronic Healthcare Network Accreditation Commission, indicating that their practices meet or exceed federal regulatory requirements and industry guidelines. This, along with community outreach and educational content, helped build trust with users.

+ +

Marc's diverse corporate background gave him the skill set to lead OtisHealth, emphasizing the importance of team development and collaboration with other organizations, even competitors, to move the mission forward.

+ +

__

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Marc Mar-Yohana, CEO and Founder of OtisHealth, a personal health application and a platform for patient-caregiver engagement, population health, and clinical research. Marc, thank you for joining me.

+ +

MARC: Victoria, I'm honored to be here. Thank you so much for inviting me to join you on this podcast.

+ +

VICTORIA: You're welcome. I'm excited to have you. So, why don't you just tell me a little bit about what's going on in your world right now?

+ +

MARC: Well, OtisHealth is keeping me pretty busy. So, I live in Northern California. My team is mostly in California, a little bit in Illinois. And we're busy every day, both supporting our members and working with clients. And so, it's exciting times, especially on our advocacy front. We work with organizations across the country to advocate for patient access to their health records and also for individuals themselves to improve their access to quality healthcare wherever they reside in the United States.

+ +

The advocacy, the work with our clients, and the work with our members keeps us super busy. Although I do still try to make time to hike in the beautiful scenery out here. I'm new to California. I'm originally from Illinois, so it's great to just be able to get out every once in a while for a hike in the area.

+ +

VICTORIA: That's wonderful. Have you made it to any redwood forest out there?

+ +

MARC: Yeah, Muir Woods, which is just north of us, north of the San Francisco Bay Area. Most of the time, we like to walk the coastline. So just north of Santa Cruz is a great state park known as Wilder State Ranch. And they have amazing views of the coastline, wonderful views of birds, as well as occasionally spotting whales, and dolphins, and sea otters along the coast.

+ +

VICTORIA: That's so cool. I had a friend, actually, who just went up there and went kayaking with the otters, and I'm very jealous. [laughter] It sounds beautiful.

+ +

MARC: Yeah, that can be fun. Otters are really cute creatures. And they can be aggressive too. There's a concern right now. There's one female otter that likes to grab people's surfboards. And I saw a video of a sea lion jumping on top of a sea kayak to steal a fish from a fisherman.

+ +

VICTORIA: I think if a sea otter or a sea lion wanted my vessel, a kayak or surfboard, I mean, you can have it. [laughter] You worked this hard. [laughs]

+ +

MARC: Yeah, they're pretty aggressive. They're more comfortable in the water than we are, so they [laughs] pretty much are in charge in the environment.

+ +

VICTORIA: That's right. We're in their house, right? So, I'm, like, okay, [laughs] you can have it. That's great. Oh, wonderful. I'm glad you still have time to get outside and enjoy hiking with your family, even though you're a very busy founder [chuckles] and very active advocate for your community. So, why don't you tell me how everything with OtisHealth got started?

+ +

MARC: So, it started with a tragedy, a horrible tragedy in my life. My daughter, Constance, who was eight years old at the time and had been previously diagnosed with autism, apraxia of speech, and epilepsy, died from an undiagnosed brain tumor. She had great healthcare. She had a neurologist, a pediatrician. She had therapists that saw her five days a week and, of course, her parents watching over her. Yet, we all missed the symptoms, the major illness that claimed her life.

+ +

And so, because all of her healthcare providers were on different systems, and as parents, we didn't have a system, there wasn't a place to put our observations together. And everyone attributed their observations of her changing condition to other medical concerns. And so, after she passed, I started to spend a couple of years trying to understand what happened. And I realized a big part of it was the information was in front of us. It was just in different people's hands. And when we put it together, we could have seen the whole picture that would have shown that she had a more serious illness.

+ +

And so I chose a new mission in my life: to abandon my corporate career and move into this role of developing a better set of tools for families and caregivers to manage their loved one's health. And so, our mission today is to work with families, caregivers, and people with chronic illness to give them better tools to manage their everyday health and the health of their loved ones, and thereby also improving lives in the community.

+ +

VICTORIA: Well, I love that out of the tragedy, you were able to find direction and purpose to solve this major problem, which I can relate to having moved across the country. Your medical records don't come with you. You have to basically kind of start all over, or they have to go get them from your past patients. It's not unified as a system, as you might think that is. [laughs]

+ +

MARC: That's absolutely right. Our data is spread out across different clinical sources. Just in the time I moved out here to California from Chicago, I saw five different providers just because I wanted to get some tests done. So, I had to go to a few different locations to do a normal battery of tests. And so, I had at least five different health records created just when I moved out here. And they're all in different systems, and they're not even on the same type of application.

+ +

So, to bring them together, I had to basically download them and put them in files on my desktop computer. With OtisHealth, I'm able to retrieve that data and put it onto one continuous record and watch it. But that's still just our clinical data, meaning data collected in clinical settings. We have more data to share of things that you and I observe as regular people or our families observe. And so, the part that's missing in the record is all the observations in the time that we're not in the physician, in a physician's office, or in the presence of a clinician.

+ +

We can; with our tools today, such as wearable watches, or blood pressure cuffs that are Bluetooth-connected, we can get a lot more data and share that back into our records so that we have a true baseline, not the once-a-year that I go to see a physician, and they say my blood pressure is high. And the next time I go, it's low. It's because we only have two data points over two years. Where today, with our technology and our capabilities, we can have a baseline of true data continuously throughout the year that will give the physician or care team more insights into how we're doing in terms of our health.

+ +

VICTORIA: That's so interesting. And it makes a lot of sense to me why someone would want to use this or why doctors would want to use this. And I'm curious, once you had this idea, how did you get that initial traction to get started with OtisHealth?

+ +

MARC: Initially, it was a little difficult. And this is kind of part of our lessons learned when we started the company. We started advertising on Facebook. This is after we launched the product. So, we launched in 2021. We had the idea that we were going to make this available to a lot of people. We knew a lot of folks that needed it. It was okay to get the first 100 or so people because there were folks that we knew needed the application or folks that were curious about it and wanted to try it.

+ +

And we started advertising through consumer channels such as Facebook, and LinkedIn, and other magazines to people that we knew had the need for the app. Yet, it was a very slow uptake. And the part of what we learned and we started applying to our marketing or our membership development or recruitment thesis is that the health records are kind of like an umbrella.

+ +

We don't think about the umbrella or going out to get an umbrella until it's raining, and for most people, it doesn't rain very often. And so, it's not something that people would use every day. In most cases, they use it only when they have an emergency or when they're managing their chronic illness or the chronic illness of a loved one.

+ +

And so, we eventually changed the way we were recruiting and started recruiting through other organizations, such as clients where we're able to get thousands of users through the client that has members. And then, slowly, over time, teach them the importance of managing their everyday health, and taking their own vitals, and recording that, and they record for themselves and their family.

+ +

VICTORIA: Right. So, you were able to offer the app for free for daily users because you found another group that was interested in having access to the data and having this app, right?

+ +

MARC: Yeah. So, anybody today can go to the Apple Store or the Google Play Store and they could download the app for free. And they can use the web version also. And they could share it with friends and family, which I always encourage people to do. So, if you have an emergency contact, invite them to your medical records; at least they have your basic medications, and allergies, and other key information in case of an emergency.

+ +

What we did in terms of our change of strategy early on is we started going to organizations that also had an interest in improving the health of their population and, in particular, health insurers or what we call in the industry payers. And so, payer organizations could be Medicaid, Medicare, or it could be employee health plan, one of the big health insurance companies like Blue Cross or UnitedHealthcare. They have an interest in people managing their everyday health.

+ +

And so, one of our clients right now, everyone that enrolls in one of their plans automatically gets enrolled in a version of OtisHealth specifically for their members. And those members could still invite people to join them on the platform, and those people can get on with OtisHealth. But the nice thing is now this payer has a way to both encourage healthier activity or healthier practices for their population and monitor if there's a problem. So, if somebody is missing medications, or not taking their medications on time, or has vitals that are tracking poorly, this gives the payer an opportunity to reach out and ask them if they need help managing their health.

+ +

VICTORIA: So, how does that dynamic affect how you measure successful engagement on the platform, like, a successful rate of engagement?

+ +

MARC: So, for us, most people don't use the app every day. Most of us don't even think about our health [laughs] on a daily basis from a standpoint of our medical health or clinical health. Sometimes those of us that exercise regularly think about it in those terms or eating healthy. But we don't think about keeping a record or using an app to maintain our health.

+ +

And so, for us, an active user is anybody that's logging in at least once a month to update their information. Our really great users are the ones who are using the reminder features to take supplements or take their medications. And so, I would say of the few thousand users that we have—we're approaching 10,000 right now active users—only a small percentage of those, maybe 10%, are actually using it on a daily basis for themselves or their family.

+ +

And so, for us, a good engagement and good practice is folks setting reminders on at least a weekly basis to take vitals, weigh themselves—something that would help them track their health over time—and if they're taking medications, to set daily reminders for the medications that they take. And so, we currently have far more people enrolled in OtisHealth and that, you know, 5,000, 6000 I mentioned that are active. But they basically bought the umbrella, and they just put it in their closet. They're waiting for that rainy day that they have to pull it out and start using it.

+ +

VICTORIA: That makes sense. And I'm already in my head going through the people in my family who would benefit from this where, you know, I have family members who have a learning and a physical disability, and tracking everything that they're supposed to be doing to maintain their health is quite difficult. So, I can definitely see the value in that and why people would want to use it.

+ +

And I think for, you know, healthcare apps, you have to build this high level of trust. You know, people are giving you all this data about their health information. So, how do you go about building a product that people can trust from the beginning?

+ +

MARC: One of the things we sort early in the life of OtisHealth is an accreditation. An accreditation is not required by law. It's not required by any institution necessarily. It's a third party that reviews our practices and our systems to see if we're actually following good privacy and security standards and practices.

+ +

And so we went live in November of 2021, and by the end of December of 2021, we already had our full accreditation in what's called a comprehensive level from a national established organization known as The Electronic Healthcare Network Accreditation Commission.

+ +

And so, that was the first step of making sure that folks understood that we took their privacy and security seriously. That accreditation means that our practices and our technology meets or exceeds federal regulatory requirements and industry guidelines. And that's just the first step.

+ +

Then after that, it's really a matter of people gain their trust because an accreditation itself doesn't necessarily mean that we trust that brand. That's just a basic starting point for us. After that, we publish articles about maintaining health. We have launched some videos about different aspects of our advocacy, such as with autism for caregivers. And we participate in community activities at the national level to improve patient access and to talk about how important it is to manage our own health and the health of our loved ones.

+ +

And so, it's a combination of both basic accreditations that show that we made the investment, and we provided a third party to critique us and to review us. And we actively maintain that accreditation is not a one-time stamp. And then, the second part is continuous outreach, and letting the community know what we're working on, what's important to us, so that, over time, they start to look at what we do and start to trust it and invite other people to trust it as well.

+ +

VICTORIA: That makes a lot of sense. And I'm curious if there were experiences from your corporate career that informed how you acted as a founder and what you prioritized.

+ +

MARC: I've had an odd corporate career. [laughs] So, I started my career as an engineer in manufacturing operations and in product development and then went down to as a consultant strategy in ops and market management, and then, later, investment management and private equity, and then, later, for a safety science company where I was managing global capital investments in technology and new operations.

+ +

And so, I've been fortunate that I've had a breadth of experience, from marketing to sales, to product and technology development, and infrastructure management. So, I had some basic skills that helped me understand what...well, the endeavor before I jumped into it because I spent a couple of years thinking about whether or not I even wanted to do something like this.

+ +

And then, I would say probably the most important part of my previous experience that I apply every day at OtisHealth is developing teams and developing collaboration with different organizations. You know, aside from the team that I have, our own staff, we also work very closely with other organizations, even competitors, to make sure that we're all successful.

+ +

And so, that collaboration across organizations that don't even have a necessarily contractual relationship is something that I brought over from my previous work and seeing how working across the industry, we can help each other and serve the mission. So, I think that was probably the most important part of my previous work experience that I apply today is this: building a team and building a coalition of organizations that want to move forward together.

+ +

VICTORIA: That's great. And I'm wondering if there was anything that surprised you in that early phase of building collaboration with other companies and understanding your users that changed the strategic direction you were going with in the app.

+ +

MARC: So, one of the things that I was really just in awe of was how willing people in the healthcare industry were to jump in and help out when we started talking. And so, many of the organizations that we work with, the founders or the senior staff within the nonprofits we work with, all have a story of why they're doing what they're doing. Many are brilliant people who could have taken their careers in many different directions, not in healthcare. And they chose to move forward in healthcare because of some personal experience in their life.

+ +

And so, as I learned about the people I was working with, I was surprised how quickly they just took me under their wing and said, "Hey, let's get you started marketing. Let's move OtisHealth forward." And so, we have organizations like Onyx and Invitae [SP] that are giving us support in data access. There's another organization that I can't mention yet; that's another private entity that has offered their support, and we hope to launch with them in the next couple of weeks. And so, we're forming these data access bridges to help get patients more access to their data, their loved ones' data.

+ +

And then, there's the nonprofits in the advocacy and standards organizations we work with, such as HL7, which is an international health technology standards organization, and DirectTrust, which is an organization that establishes trust networks in ecosystems, as well as the technology infrastructure behind how those systems communicate. And we work also with EHNAC, the accreditation commission. So, we not only are using the accreditation from EHNAC, we're on committees to advise them on future criteria for accreditation.

+ +

VICTORIA: That's really cool. I love that there's that collaboration and just openness and willingness to try to make things better and to invest in solutions together.

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So...

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

VICTORIA: You mentioned advocacy. And I'm curious if you could say more about what advocacy are you doing or how does that blend into your business model and what you're doing with OtisHealth?

+ +

MARC: I'll give you an example. One of the organizations we belong to and I participate in personally is the Health Information Management System Society. And so, this is a professional society of healthcare IT professionals. And in Northern California, there's an advocacy committee that works directly with the state legislature to promote legislation that will improve the quality of healthcare for people in California. We actively talk to members of the legislature to tell them what bills we think are important.

+ +

The ones we focus on and the ones I personally focus on are the ones that improve access to our data and also improve our privacy. So, there's a legislation in California, as an example, that will prohibit access to people's healthcare data without proper legal warrant. So, it's basically extending HIPAA protections across any health app launched in California. And we, of course, are already HIPAA-compliant, so that's very easy for us.

+ +

There's also advocacy specific to certain health conditions. So, my daughter had autism. I work with the Autism Society here in California and also Achieve Tahoe, which is an organization that teaches skiing and other skills to people with disabilities in particular. This past season was my first season. I work primarily with children and young adults with autism and other developmental disorders.

+ +

And then we also partner with organizations when we think that they're aligned with some of our mission. And so we work with the Caregiver Action Network. We also will work with AARP and other organizations regarding caregiver rights and also teaching caregivers how to access the healthcare data of their loved ones and how to take care of themselves personally.

+ +

VICTORIA: That's wonderful. And I guess it's not really a question, but I saw that autism service dogs are a thing, and I just thought that was really cool. [laughs]

+ +

MARC: Yeah, OtisHealth is named after Constance's autism service dog, Otis. And so, service dogs are extraordinary animals. They're highly trained. Otis had been trained for two years before we received him. He was trained specifically for Constance's needs, and he kept her safe. And that was the primary interest in Otis is observing things that she...because of her cognitive limitations, wasn't always aware of her surroundings and wasn't always safe. And so, the dog maintained her safety and her boundaries and kept her focused, as well as just basically blocked her if she was going to do something that was unsafe.

+ +

So, there are many different kinds of service dogs, and I'm talking specifically about ADA, the Americans with Disability Act type service dogs. These aren't, like, companion dogs or therapy dogs. These are truly highly trained animals that are focused on specific tasks to help an individual be safer, more free, or have more abilities than their disabilities may allow.

+ +

VICTORIA: Well, I love that. And I like that the app is named after her dog as well. That's just very sweet. And I love that that's how that worked. And I'm curious, what's on the horizon? What are you most excited about for OtisHealth in the next year?

+ +

MARC: Like all startups, we have [laughs] a lot of plans. And we've been invited to speak at some conferences. I spoke at two already this year. And I have another one coming up in Washington, D.C., where we're going to advocate, again, for patient access. And this is primarily talking to the health systems themselves in adopting technology that makes it easier for patients to securely access their health records.

+ +

And so, we're excited about that movement in the industry to recognize and start to act on that need for patients to be able to access their health records. And we work with our partners to promote that and also with the federal government. We work with the health and human services to promote this access. And we were published in a report earlier this year because of our technology demonstration with health and human services. And it sounds like it's finally getting some real traction in hospital systems. And members of the Federal Congress are also saying that this is something we need to move forward with in a more aggressive manner.

+ +

On a more direct path, we're excited our membership's growing. We've had tens of thousands of people register to use the app, with thousands actively using it today. We're working on some new programs right now for payers and for providers that will improve health outcomes and within their populations, as well as bring on hundreds of thousands of other people on the app.

+ +

We're really excited to know that we're getting both recognized for the work that we're doing and that people are starting to understand the importance of managing everyday health, whether it's with OtisHealth or another application.

+ +

VICTORIA: Well, I love being excited for these opportunities to advocate for your product and for the mission behind the product. I'm not going to recommend being excited about going to D.C. during the summer. [laughs] Last time I was there when I landed at 9:00 p.m., it was 90 degrees outside [chuckles] and humid, like, 90% humidity. But it's great to have access to people who care and are trying to make things better and have that voice. I'm excited to see you grow.

+ +

And then, it's been two years since you started the app. I wonder, if you could go back in time to when you first were getting started, what advice would you give yourself?

+ +

MARC: So, this is a really hard thing for anybody to look back and say that they'd like to change a few things. There are things I would change. I have a lot of experience managing large, sophisticated programs. Because in the past I had large budgets, it was really easy to maintain strict discipline around the implementation. And I think I was too loose in the implementation process at the onset of OtisHealth.

+ +

I would have been more disciplined around my program management and the accountability that I had to developers I was using. As a startup, I didn't have a large development team in-house. I needed to use external parties. And I should have been a little more closely on top of that process.

+ +

The other things that we experienced were primarily a result of pivots. We were constantly pivoting as we were learning. I think having a team to review our process and pivot more quickly is really critical. You don't want to pivot 20 times a week. You need to stay focused for a while, but also having friends or advisors or members of your team that can help you assess when a pivot is necessary, or a new opportunity presents itself, I think, is critical. And so, we all know, as founders, the team is key. And I think the earlier you engage a team and not be bashful by asking for advice, the better.

+ +

VICTORIA: I love that. And I'm curious if you have any advice from your program or from your startup career now on choosing the right development teams. And how do you find those right partners to actually build the app and have that accountability?

+ +

MARC: So, I would say the number one thing that I've learned, that I knew previously, but I really appreciate it more now as a founder of a small company, is you need mission alignment, not just company to company, but person to person. And I took my time picking advisors to join us, and I took my time getting people on board to OtisHealth. We pick folks that we believe understand what we're doing, and we take our time and make sure that they appreciate it and that we're comfortable with them.

+ +

Our startup is too small to make a bad hire or to have the wrong perspective because somebody has other motives, such as just making money. If I was providing advice in terms of picking teams or picking vendors to work with, I would say take it slow. Don't rush, even though you may be in a rush, or we may be in a rush to get moving, either for financial reasons or personal reasons.

+ +

It's important just to feel comfortable. Get to know folks. Meet them in person if you can and spend a few hours with them at a time [laughs], just to make sure that they believe in you, and you believe in them, and that you have a common vision. Because when things get rough or tough, financially or otherwise, you need people that are going to be able to stick through it and work with you.

+ +

VICTORIA: That makes a lot of sense. There's a lot of pivots happening. You want everyone to be on the same page. And you don't want to have to be corralling everyone all the time if they have competing priorities, so that makes a lot of sense.

+ +

MARC: Absolutely. Just to be clearer on that, we all run into challenges. So, in some cases, we had to make some financial sacrifices, and everyone did it together. You really need people that are that committed that say, "Okay, I understand where we are, and so, I'm willing to take a pay cut for a while or not get paid for a while until we can get this spec started again." Even vendors I work with today that are strategic vendors understand that and have helped us financially when we need some time to get more revenue in.

+ +

VICTORIA: Great. And so, when you were building a healthcare app, was there people you needed to have on your team who had that exact specialty in either patient care, or medical records, or something like that?

+ +

MARC: Yes, yeah, you need experts. So, I'm a quick read. I mean, I spent a couple of years learning the industry and understanding the technology. But the person that's our IT director he has over 25 years of experience in healthcare IT systems, so he is the expert in-house. We also have advisors on our team that are experts in payer services and payer systems, launching healthcare apps, managing standards, and managing SaaS services. We have a data and an AI expert, and a clinical research specialist. We also have physicians we refer to. [laughs] So, we have a pretty big entourage of individuals that we go to for very specific advice and work.

+ +

VICTORIA: That makes a lot of sense. Let's see, what question should I be asking that I haven't asked yet?

+ +

MARC: You know, I think most of the people listening to this podcast are technical founders. And it was surprising to me, and I had some founders contact me, asked for some free advice, which I'm happy to do, but they didn't seem sincere in their interest in being in healthcare. And one thing I told them, and I would say to anybody that's interested in being a healthcare technology developer, is you have to have a reason to do it besides the money.

+ +

It will be a really hard battle to move forward with a technology if the only motivation is a financial opportunity. That isn't going to sustain the pivots or the development. You'll run into a lot of walls, primarily because everyone will see it. Everyone in the industry sees those players come in that just have a financial interest, and the consumers see it, and they don't like it.

+ +

So, my advice to anybody that wants to develop technology in healthcare is you have to be a little sincere about it and have a real reason to do it beyond just making money, and I think you'll find it more rewarding. There's so much need for healthcare technology and better technology out there. So, I welcome folks to join the fight, the battle, or the opportunities. But I would say that just come in with the idea that you're helping people, not just making money.

+ +

VICTORIA: I think that rings true for any business you're in, right? But especially in healthcare because it is this big target. Even in consulting, if you're doing business development and you're thinking of working on health IT projects, there's just a huge market that you have to narrow down and figure out where you're going to be. So, if you don't have that intrinsic motivation, it can be overwhelming and scattered, and then people won't connect with you, right? Because everybody is going after the same thing.

+ +

MARC: That's exactly right. One of the conferences I went to earlier this year, a speaker got up and said, "People invest in people, or people make deals with other people." We talk about companies signing a deal with another company, but it's really one person trusting another person. Whether it's in healthcare or another industry, obviously, that trust needs to happen. At some point, if I don't trust the individual I'm talking to, I'm less likely to have a deal with that company.

+ +

VICTORIA: Right. It's like; I don't know how, you know, it doesn't really matter how impressive your credentials are. If there's not a basic level of trust, you might not move forward with it, so that makes a lot of sense to me.

+ +

MARC: Yeah, that's absolutely right, Victoria.

+ +

VICTORIA: Absolutely. Is there anything else that you'd like to promote at the end of this podcast?

+ +

MARC: I'd love for folks to try OtisHealth. If you have family that have chronic medical needs or need help managing their medical information, please download OtisHealth, help them join. There are videos on YouTube that explain how to use it if you need some guidance, but we believe most of it is self-explanatory.

+ +

We are continuously adding data access points. We're going to be launching this week new versions of OtisHealth that have access privileges for people in New York and Nevada and parts of California and Colorado. And so that means that with the app, once you're ID-proofed on the app, you can use it to get your medical records from different sources without having to log into all these different patient portals. So please try it. Use it for yourself but especially use it for your family or anybody who you care for. We'd love to get your feedback as you use the app too.

+ +

VICTORIA: That's great. And I'm actually already thinking about...next week; I'm going to be going to The San Diego Annual Veterans Stand Down, where anyone who is experiencing homelessness can come in and get access to all the services that they might need, whether it's legal, or healthcare, or dentistry, showers, food, all of these things. And I'm curious if that organization might benefit from having a tool like that for their users. So, I'll be talking about it. [laughs]

+ +

MARC: Oh, thank you so much. That'd be wonderful. Thank you.

+ +

VICTORIA: That's great. Well, thank you so much, Marc, for joining us.

+ +

MARC: My pleasure. Thank you, Victoria, for having me on the show.

+ +

VICTORIA: Excellent.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Marc Mar-Yohana.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mtpfcK9h + + ]]> + + Victoria Guido + Marc Mar-Yohana + + + 486: Blox with Simon Ritchie + https://podcast.thoughtbot.com/486 + 872ab0ef-ad68-4f55-a79b-9da31949655e + Thu, 03 Aug 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Simon Ritchie, the founder and CEO of Blox, discusses his background and journey leading up to starting the company. He began his career in finance but discovered his passion for technology and finance systems. He worked at Anaplan, a successful finance planning and analysis software company, but saw the limitations of rigid systems when COVID-19 hit. He realized there was a need for a more flexible and accessible financial modeling and planning tool, especially for small businesses and charities. + +Blox aims to fill this gap by providing a powerful yet easy-to-use modeling, calculation, and planning engine that sits between spreadsheets and complex enterprise software. The company is about a year old, has raised venture funding, and launched a free tier of its product. They prioritize building a compelling product, iterating quickly, and engaging with users to understand their needs. + 46:00 + no + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +__ +Simon Ritchie, the founder and CEO of Blox, discusses his background and journey leading up to starting the company. He began his career in finance but discovered his passion for technology and finance systems. He worked at Anaplan, a successful finance planning and analysis software company, but saw the limitations of rigid systems when COVID-19 hit. He realized there was a need for a more flexible and accessible financial modeling and planning tool, especially for small businesses and charities. +Blox aims to fill this gap by providing a powerful yet easy-to-use modeling, calculation, and planning engine that sits between spreadsheets and complex enterprise software. The company is about a year old, has raised venture funding, and launched a free tier of its product. They prioritize building a compelling product, iterating quickly, and engaging with users to understand their needs. +Simon acknowledges that building the product has been enjoyable, leveraging his background in product management. However, sales, marketing, and customer traction have proven challenging. Nonetheless, he remains optimistic about Blox's progress and is committed to providing a valuable solution to help businesses make informed decisions and achieve their financial goals. +Blox (https://www.blox.so/) +Follow Blox on Twitter (https://twitter.com/blox_is_awesome), Facebook (https://www.facebook.com/blox.for.planning), LinkedIn (https://www.linkedin.com/company/blox-plan/), Instagram (https://www.instagram.com/bloxisawesome/), or TikTok (https://www.tiktok.com/@bravewithblox/) +Follow Simon Ritchie on LinkedIn (https://www.linkedin.com/in/siritchie/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. And with me today is Simon Ritchie, Founder and CEO of Blox, which provides pre-built planning models to help business leaders escape the tyranny of complex, clunky, and error-prone spreadsheets, giving you visibility into and confidence in the reality of your business. +Simon, thank you for joining us. How are you doing today? +SIMON: Hey, guys. Yeah, I'm very good today. +VICTORIA: So, Simon, where are you joining us from today? +SIMON: So, I'm joining from the UK. I live in a city called Brighton on the South Coast of the UK, where it's a lovely day today. It's nice and sunny. +VICTORIA: Oh, that's where our thoughtbot summit has been the last two years, in Brighton, actually. +SIMON: Fantastic. Yeah, it's a wonderful place. +VICTORIA: And a great place to be in the summer right now, right? Do you get out in the water very often? +SIMON: Yeah. Yeah, absolutely. Like many others, we have a paddle board. So, I go out with my family. I have four kids, so we go out and have fun at the beach. Brighton's got a stony beach. So we are, as Brightoners, we're very proud of the stones. You know, if you have sand, you get sand everywhere, stones are...it's much cleaner. [laughter] It does hurt your feet, though. There you go. +[laughter] +WILL: Yeah, that was the first time I've ever seen that, and I was like, that's very interesting. +SIMON: Yeah. [laughs] +WILL: I probably will like it because I don't like the sand getting everywhere, so... +SIMON: Yeah, absolutely. +WILL: So, yeah, I probably could trade that in. [laughs] +SIMON: Yeah, yeah. You just have to wear shoes if you want to go run around. We're proud. We're proud of it. +VICTORIA: I didn't think about that either. It makes a lot more sense. I don't really like the sand [laughter]. Rocks make more sense. But in California here, we're surfing, so having too many rocks on the beach would be a problem [laughs] for those of us who can't control ourselves. [laughter] +SIMON: Yes. Yeah, Victoria, I thought you lived in Wales when I first looked at your profile -- +VICTORIA: Oh, right. +SIMON: On LinkedIn. And I thought, oh -- +VICTORIA: That's...yeah. +SIMON: A Welsh girl. That's -- +VICTORIA: My family is actually Welsh on my mother's side. +SIMON: Oh really? +VICTORIA: Yeah. +SIMON: Okay. +VICTORIA: And Cardiff...California is named after Cardiff, Wales. +SIMON: Okay, oh. +VICTORIA: But yeah, so that's where it came from. So, I thought that was very cute, too. +SIMON: [laughs] Very cool. +VICTORIA: But, you know, Cardiff-by-the Sea is its own little beach town here. +SIMON: It's not Wales. [laughs] +VICTORIA: Not Wales. [laughs] Pretty different. But I do hear Wales is beautiful. +SIMON: Oh, it is. Yeah, absolutely. +VICTORIA: Awesome. Well, let's talk about Blox a little bit. So, why don't you tell us maybe a little bit about your background and how you came around to starting it? +SIMON: Yeah, great. So, and just in terms of me and my background, so I started my career in finance, actually. I didn't really know what to go and study, so I thought, you know, studying numbers was probably a good thing. So, I did an accounting finance degree. And I got into the world of work in finance roles very quickly realized that finance wasn't for me. I just didn't really want to be a CFO. I just didn't feel the passion for it. +But I was the techie guy always in the finance team. I was the guy people turned to and originally for, you know, Excel and spreadsheet modeling. And behind Excel, you've got VBA. So, you've got this little, you know, it was my first exposure to programming and some, you know, and what coding was. And so, I sort of just realized, actually, I love the technology side. And so, I followed my passion more into the finance systems arena. +And my passion has always been...the focus of my career has been helping leaders understand what's going on in the business by getting hold of those numbers, the data that they have, and analyzing it, summarizing it, trying to draw insights from it so they can make decisions. And so, in the early days, it was lots of Excel spreadsheet modeling. And, in some businesses, there's still tons of spreadsheet modeling going on. +And then the next phase of my career was actually working in...there are a number of software options that help you with planning, modeling, reporting, et cetera. So, I joined...well, I did some consulting for a while and then joined a company called Anaplan. And was an early employee, the company was still very early in their journey. They were just launching a European office, so I joined as one of the early European employees. +And Anaplan went on, over the course of nearly eight years that I was there, to be [inaudible 04:31], absolute rocket ship, grew up to 2,000 people, and we floated on the New York Stock Exchange and then IPO in 2018. It was acquired last year for a very big number. So really fantastic time there. +But to just talk about Blox, so I left Anaplan two years ago. The observations that I made that led to Blox ultimately were there were sort of three main aspects. Like, when COVID happened, the world changed radically. And what I saw...I was working in Anaplan. For anyone who doesn't know, Anaplan they focus on selling to large enterprise. So, you may not be familiar with the company if you're not a CFO or a finance person in a very large company. And they sell very expensive product. It's very, very powerful modeling, calculation, FP&A, finance planning, and analysis software. +And so, companies...we were working with companies like Procter & Gamble, HP, Cisco, Google, and others. What I observed was when COVID kicked in, the FP&A system was too rigid. So, Anaplan, you know, these models that people had built up, spent a lot of time and energy building up, it was too rigid. The world changed so much that they couldn't really use their typical budgeting systems or these FP&A solutions. They couldn't use Anaplan. +So, everybody just jumped back into a spreadsheet to figure out, you know, do I still have a business? How am I going to survive this if I just had to shut all my retail stores or if I had to send everybody home? You know, so everyone was using spreadsheets, basically. +And so my observation there was that the tools that are available at that point are still way too hard to use. They're not flexible enough. You can't mold them quickly enough to really handle some of those scenarios that you want to throw at it as a leader. So, when you're trying to make big decisions about new revenue streams, new offices that you would want to launch, restructuring your team, investing in more people, those things they're really hard to model in the tools that are available. You need real specialist experience and expertise. That's very expensive, et cetera. So that was one part. +And then the other thing that happened was I've worked most of my career in larger companies. And I'd worked in, yeah, in finance, in businesses. And also, I'm a chartered management accountant. It's all about helping with managing a business with your numbers. And I hadn't really worked with many very small companies. I ended up volunteering. +When the lockdowns were happening, there were lots of people that were sheltering in place and they were staying at home. And so, a local charity had organized to put together food parcels, and then they found drivers to drive them around. And so I had volunteered through a friend of a friend, and somewhere my name got put in. So, I ended up driving these food deliveries around for the summer, and I loved it. Every Thursday, I'd take a couple of hours to just drive around and drop some food on people's doorsteps and then maybe have a quick conversation with them from a distance. +I got connected with the charity. It is a local charity that runs on the South Coast in England here. And they found out I was an accountant, and I worked in software technology. They were like, [gasps], please, you can be our new best friend. We need some help. So, I ended up helping them a bit in their back office with some of the reporting that they do. And to cut a long story short, they're a charity. They live on grant funding that they get. So, they apply for grants, and then the grant providers want them to report back on the progress that they've made, the services that they've offered, the people they've helped. +So, I went and helped them, and they needed these reports and some plans for grants that they were trying to get. What seemed really easy to me, like, they were showing me that they had to download this data from a system. And they needed to filter it and then count how many people they had been helping. And they basically were just, you know, with different needs and in different categories and cohorts. +So, they would basically download the data, open it in a spreadsheet, put a filter on, select some filters, and then they would count the number of rows that had that criteria. And then, they would type the number into an email. And I just showed them some very simple things, like, when you do a filter or if you select the cells, you can see a countdown at the bottom-right in Excel, and I showed them that. And they almost fell off their chair because [laughs] they were like, "Oh, you know, why did we not see that sooner?" +But I suppose through that, and, you know, through the various times that I helped them...and I just helped them with initially some spreadsheets and just some help with that. But it just showed me that there are a lot of businesses, a lot of charities in this case, but a lot of businesses where the leaders are not finance savvy, and they are not accountants. They're not MBAs, but they still need help running their business. They need to do reporting. They need to do planning, you know, manage their business, control the finances. +So, I just thought, you know, just started thinking a lot more about what does a small business need? What does a leader in a business need to make great decisions, run the business? And how could we get them a tool or some software that doesn't cost hundreds of grand every year but is accessible, a nice, low price point, and really easy for them to use? And that's the problem that I thought about for a long time. And ultimately, that's what we're trying to work on with Blox. +WILL: That's amazing. I used to work at a nonprofit. And I remember those days of, like, because I wasn't an MBA, like you said, MBA finance and just trying to figure out numbers. I don't even remember the software we used. +SIMON: [laughs] +WILL: But it was old and very hard to maneuver. [laughter] +SIMON: Oh yeah. +WILL: It was harder to maneuver than spreadsheets. And I was like, ahh, this is a nightmare. So, this is amazing that you're doing that. Can you tell us more about how Blox solves that issue? Because it sounds like it is a tween of big software that's for enterprise companies and spreadsheets. So, it's kind of in the middle; it sounds like. +SIMON: So, spreadsheets are great. They're really easy. They're easy to start with. You'll often find that your spreadsheet will just kind of reach its natural end. It becomes too complex. And that normally happens when you've got, like, you're planning for lots of people, or lots of products, or lots of different projects. +And so, you end up sort of having to figure out how to scale the model, you know, across lots of different columns or rows, or you start copying. And how you'll have three identical tabs or ten identical tabs. And, at that point, you've basically outgrown Excel, and trying to keep that spreadsheet running and working it becomes a real nightmare. And so, that's the point where Blox comes in. You could use Blox right from the very beginning. +We've started with a focus on making really nice, simple models that you can just pick up and use. So, our earliest customers are startups doing a financial model for a brand-new idea. So, you can use Blox from the beginning, but you could probably use a spreadsheet, too. Where you would want to use Blox is where it becomes more complex, and you've got a lot more going on. You might have lots of different months, and you've got loads of time. You might want to connect it to your actual accounting system or a CRM system. +And so, when you want to pull in actual data and do some reporting and maybe have different scenarios, different versions of a plan or of a report, that's where you've basically outgrown a spreadsheet, and it just becomes complex and unwieldy. And that's where you would want to move into a system. That's what we're building with Blox is basically a powerful modeling calculation planning engine that scales really easily. +So, you can build up your dimensions, products, countries, time, et cetera, and you can build up those dimensions. You can build up your logic. You can add your own KPIs. You can add your own projection logic, et cetera. You can build out a model. We've got lots of template models that you can start with because you shouldn't have to start from scratch every time. You can get going. You can load up your own data very quickly at the beginning. +For a lot of models, it's just assumptions. You're just trying to work out, okay, like, we've got some service businesses that use Blox. To get a basic model together, what you need to know is how many people do you have roughly? How much do you pay them? And then, how many people do you plan to hire at certain times? And how long does it take to ramp a new hire? Because, normally, there's some sort of ramp time. +And if it's a service business and you're selling time, then you kind of have an average number of hours billable or often called utilization. So, with a few quick assumptions, you could throw them in. You could build out a multi-year plan for your business. And you could use that to think about, okay, how can I grow this business? I kind of talk about it as a financial roadmap that you could create. +So, you know, often in the product world, we talk about product roadmaps. I like to talk about, you know, a business roadmap or financial roadmap. And that's really what we are working on; Blox and Blox will help you with this financial roadmap that you can build out. You know, I'd like to get my business to this point to, you know, 2 million in revenue, or 10 million in revenue, or maybe there are some financial or non-financial goals that you're trying to get to. +And, with a model, you can help try and kind of work out what the assumptions and drivers and what those things need to look like. And then, as a manager of the business, you can start working on, okay, how do I increase my headcount? Or how do I decrease this particular cost per unit or various things like that? So yeah, that's a very high level on what we're doing with Blox. +VICTORIA: Thank you for that. And I certainly can relate to that, having worked for several different consulting services companies and how difficult it can be to get software [laughs] to project that -- +SIMON: [laughs] +VICTORIA: Far into the future, like, to think about how you're going to hire, all the things that go into it. So, I'm curious about your own plan for Blox. Like, how would you describe where you are in your plan for the company? +SIMON: We are a year old, actually just celebrated our one-year anniversary. In the last year, we've formed, hired an early team. We've fundraised successfully. So, we raised venture finance to fund the business. It's a complex product to build. We're trying to replace a spreadsheet, which has got tons and tons of features. They've been developing that for a long time. So, for someone to come across, it needs to be a relatively mature product. +So, we raised venture funds from investors. We're busy investing that to build up the product and take that to market. It's been a fantastic year. And this is my first time as a founder. I've worked in leadership roles in technology businesses, in customer success, and in product as well. +Yeah, I definitely would say working as a founder in a brand-new startup is very different to working in product, in a scale-up. You know, some of the lessons that I learned back there have been useful. You know, you learn how to juggle chaos, how to juggle...how to spin lots of plates. But yeah, I'm really delighted with our progress so far. We've fundraised. We ran a beta of our product last year with some early customers. We graduated from that. +Our approach has always been to try and get the product out, so really embrace agile. It's kind of you don't see it so often in enterprise software. What you see is companies that like to just put "Book a demo" on the website. And they don't like to show their software until they've already kind of sold the value, and they've pitched, you know, positioned their pricing, and qualified their leads, et cetera. Our approach has always been let's build a fantastic product. Let's build something which is super compelling, super easy to use. Let's get people into the product as quickly as possible so they can experience it, see if it's going to be valuable for them. +We launched a free tier of our product, the first sort of MVP, as a free tier, so not paid, not with some of the features that we plan to add to the product. And so, we've got that out there, and it's been fantastic. We've got users from all over the world using it in all sorts of different ways. And that's the other thing that is really great for us. Because it's such a flexible product, it can be used in lots of places. +So, we've got all sorts of different applications being used by it. People jump in; they use it. They can try different templates that we've got. And then, if they need something different...every business is slightly different. So, if they need something slightly different, they can just chat to us in the product. We absolutely love chatting to people. And then, you know, we'll often spin up a custom template for them. And when we've done a few of those, then we'll build a standard template for a new industry. That's a little bit about where we're at. +We're a small team based between here and India, where most of our developers are. It's good fun. Some of the learning...so I would say maybe it's just because of my background. So, I moved into product, and I was a product manager and then product leader for the last six years. +So, for me, I've found building the product has been the easier part, probably because it's my background and that's where my passion is. So, I absolutely love anytime I get to spend in the product and spend with the team. The original founding team is myself as founder and CEO. And I don't get too much time on the product. I have a product manager and a designer. And so, that was the first...the early team, the founding team. And then we've added marketing and some other roles and software development. And so that's the team. +I've found building the product has been really fun, and that's been a bit easier. Trying to work out how to do fundraising was a real challenge, so that took a lot of energy. We've been pretty successful so far in that. Still, always more to go, always more fundraising needed definitely. The really hard thing, especially in the market that we're in right now, it's hard, you know, getting early customer traction and selling. And that's really hard trying to get your name out there, build a brand, find early customers. That's really hard. +So yeah, that's definitely an observation for me that the product has been really fun and a bit easier than I thought. But yeah, trying to do sales, marketing, figure that out...and probably as well because it's not my background or my kind of natural area of interest, so I've been learning. That's always tough, isn't it? +Mid-Roll Ad: +VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? +RICHARD: Hi, Victoria. +VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? +RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. +And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along. +And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. +VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? +RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. +The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. +And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. +VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken. +RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. +VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. +RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. +And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. +VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So... +[laughter] +RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. +VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... +RICHARD: [chuckles] Absolutely. +VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. +RICHARD: Yeah, it was a pleasure. Thank you. +WILL: You mentioned getting your product out there how challenging it can be. So, what has been some other wins and some challenges that you've had as a first-time founder? +SIMON: So, my approach to things as a leader is I basically like to bring silliness and games to help motivate and energize the team. So, as a human, I have quite a lot of energy. I roll around with lots of energy. And I take loads of photos of what I'm doing, and I share those. So, we have a Friday wrap-up with the team, and so I'll often share a lot of the pictures of, you know, what I've been up to this week. +So, yeah, there's been some really fantastic moments launching a product. We launched our MVP in three months. So, we basically set off...I actually funded the first season of the business, a couple of software developers, a couple of early employees. I funded the first season. We hadn't raised money. And I just spoke to my wife, and I said, "Look, now's the time. I really want to do this." +You know, I've been saving up if you like, I had this, like, one day I'll do a startup fund. Some people would probably call that their long-term savings or like, you know, some...and I kind of called it my one day I'll do a startup fund. So, I'd been building up this fund because I knew that at some point, I'll probably go do this. The timing was way earlier than I thought. I thought I'd still do another four or five years in a career in a corporate role to try and get a few more notches in my belts to make fundraising easier, et cetera. +The timing came. The team was perfect. And everything just felt right, so we went for it. But yeah, we basically set out. We didn't know where we were going to get funding from. The market was in a real state, so this was middle of 2022. The Ukraine war had kicked in; valuations had dropped by 90% for a lot of tech companies. The post-COVID bubble had burst. It was hard. +So, we sat down, and we were like, okay, we could spend all of our runway trying to fundraise now, or we could crack on and try and build the first MVP. But we'd already done a lot of the market research, the user testing, early prototypes, et cetera. And that's a bit of a long story. But we had done that in the company that the founding team had worked at, and then we were actually a spin-out. So that happened. +And we were sitting here thinking, okay, you know, we could spend all of our runway fundraising, or we could just crack on and build a product as quick as we can in the next three months. And so, we had this really hard conversation where we descoped so much stuff. And we just figured out what's the core piece that will really show the value of what we're trying to build, that we'd give to a user, that we could give to an early customer that they could use and get value from? And so, we came up with that scope. +And we cracked on, and we built it. Within two and a half months, we had a working version. We played with it. Within three months, we kind of launched into this beta and got early users onto. So that was, you know, fantastic. So, we did that in the first three months, and then off the success of having an MVP, and just being able to show the product, and start getting some early user feedback, initial feedback was, you know, we took into account very quickly and improved. +And just having that, you know, you basically start building momentum. Every step is still really hard, but you do build momentum. So, we got this product. We launched it. We went to a couple of events, and we talked about that, and then we did some fundraising. And we landed some funding, so that was fantastic. And then, you know, and then we've just gone sort of step by step from there. So, it's really fantastic what we've been able to achieve so far. +The challenges there's been loads of them, especially when you're building a startup. It's really exciting. So, you can get people excited quite easily about the future potential. And you can kind of talk about what this can be. I've got a printed picture of a unicorn on my whiteboard in my office right here as a sort of a statement of, you know, where we're going. +It's really hard as a founder or a leader trying to persuade people to leave a stable job, take a pay cut, and come and work with you and give them some equity, which you hope will be worth a ton, and you kind of paint the picture. But also, you don't know how long you can keep them because you're on runway. You're on runway. You haven't got infinite cash if it's not a profitable business. +So, you know, there are some real challenges. And, as a founder, you go through ups and downs. Ben Horowitz talks about it in his great book, The Hard Things About Hard Things, as the struggle. I definitely understand that a lot more now because there is an up and down to this. You do build momentum, but you also...you're creating the momentum, you know, one hard push at a time. So that's that early customers come on. You kind of pitch the dream of what the product will do, and then it will fall over as soon as they touch it. But I absolutely love it. +What I love is the chance to create and how quickly you can move in the early days of a startup or a new product, where you don't have masses of technical debt. You don't have hundreds of customers. You don't have all this, you know, you don't have a massive team where everyone's got their point of view on what you should do. So, you can move really fast, and that's fantastic [inaudible 30:14] creative season. So yeah, lots of ups and downs, but it's really fun. +VICTORIA: That's so interesting and particularly interesting that you're trying to make something that's easier to use than Excel. So, I'm curious how you're testing to make sure that it's actually easy. And what might be...I'm sure there's some interesting feedback you got about that. +SIMON: Yeah, so we're making Blox easier than Excel. But it's got to be powerful enough to be able to handle the data and the modeling that you need for a business. If you're doing projections for multiple years if you've got lots of products or teams, then it can be complex, so it needs to be powerful enough to handle that. It needs to be flexible enough because you can take a template, but every business has got its own unique quirks. So, it needs to be flexible enough that it can be tailored easy for a unique business. +And then, crucially, and this is also important, it needs to be easy enough to use so that the person who understands the business can change the model to kind of suit their business. That's the bit that most of the other players, you know, the enterprise software that's available today, just that they haven't figured out how to make it easy enough so that a businessperson that, you know, doesn't have database experience, can't write SQL, not going to write Python, you know, doesn't do complex scripting or any of this stuff. +It's got to be easy enough that they can, you know, tailor, reflect the way that their business works, the way that they make money, the way that their cost structure works, so they can figure out what drives the business. And so, if they're projecting revenue, they can work out the costs associated. +So, one of our founding team is a UX designer, a really, really fantastic designer, very experienced. He's been in the game for 25 years since, way before it was called UX. And started doing graphic design, and then has done lots of branding and branding for some really fantastic, large companies, did lots of consulting. And then got into UX and how, you know, the art of wireframing and helping to make products easily usable. I call him my secret weapon. I've worked with some fantastic designers in the past, so, as a founder, I think I appreciate and understand the value of a really good design and a really good UX designer. +So, Mike, our UX designer, has just been fantastic at that. He's very good at wireframing and very good at testing. And he's not a finance planning expert. That's why I call him my secret weapon because, you know, I understand planning really well, but sometimes I understand it too well. When I describe what a user is trying to do or, you know, what I expect a screen will look like, I'm just probably subconsciously replacing or recreating something that I've seen or used before, whereas he's coming at it brand new. He's not worked in planning or data modeling, or many of these things. He's worked in lots of different businesses. +So, he comes at it with a mobile-first perspective. Normally, he's thinking about, okay, how could this be used by a busy leader on their phone and they're running around? And so, he's been really fantastic at helping to keep it simple and easy and to rethink and to create a product, which is just so different to what other tools in the space are doing. And that's some of the feedback we get. It looks so different. It works so different. +But yeah, the hard thing is that spreadsheets are the most sticky tool, I think. They're just so useful for, you know, for everything where you need to get a list of things. You just start throwing it into a spreadsheet, and then you can, you know, organize it and improve structure over time. But yeah, it's a really sticky tool. And we train people how to use spreadsheets from early days from school. My 12-year-old daughter she already has been taught how to use a spreadsheet in school. +So, what we're trying to do is create something which is easier. But there's also, you know, you want there to be some familiarity in there so that people will...to avoid some of the friction of the people who have it. No one really signs up to learn a new tool if they can avoid it. We're lazy. [laughs] +VICTORIA: It makes sense that design would be a big priority for your product because that was your intention from the beginning, right? Is to make something that's easy to use, so you prioritize that as an investment. +SIMON: That's right. That's absolutely right. Yeah. +VICTORIA: What's on the horizon? What are you the most excited about for Blox in the coming months? +SIMON: So, yeah, we've got some really exciting elements of our roadmap coming. So, yeah, really excited to see these things come to life. Like anyone working in building products, whether you're designing, doing product, sort of overseeing, or actually developing, it's so great to see these things come to life. You spend a long time thinking and chatting about them, imagining, ideating about how they could look. +The thing that I'm just most excited about is—and that's probably why I love product—is, you know, you're building a product, and then you can...then you're talking to somebody about how they would use this. Or before that, you're talking about their day-to-day right now and what their problems are, and how you could help them save time, save money, et cetera. +And so, you know, I absolutely love chatting to more and more different types of companies, leaders in different parts of the business. And, you know, especially in our space, it's mostly about, okay, how can I help? You know, how could we improve this planning process that we've got, whether it's, you know, planning for the cost of running a big project or trying to figure out how can I scale my business to reach my objectives? So, I just love chatting to lots of different leaders globally. So, I love going to events, chatting to people, fact-finding about how they run their business, how they think about finances, et cetera. +In terms of the product roadmap, we're working on some exciting new scenario capabilities, so you can easily look at different scenarios around a decision. So, you might be trying to decide, you know, should I be aggressive with my investments and hiring, or should I be pessimistic? Or is there a middle ground? So, we're adding, like, scenario capabilities where you can build out different versions of that, and then easily compare and contrast, and then decide which one to do. +We're working on some really...really enjoying working on some intelligent capabilities. So, again, in the search of making it really easy to use for a busy leader, for a busy businessperson, or a busy finance person, making it really easy to use. So, we've invested a lot in AI technology and been designing, developing POCs around how AI could help to onboard customers faster, how we could help to personalize models for businesses automagically. +So, as soon as we understand the website of a user, what sort of industry they're in, we can automagically personalize the template for them, add their own KPIs, like, industry-specific KPIs, into the model, and throw in benchmark data and all these things. So, we've got some fantastic AI capabilities coming through the pipe and some data integrations. As we get out more and more, we're connecting to different data sources. So, yeah, exciting times ahead for the roadmap. +And as we add more features, then we'll add different pricing tiers, you know, so we can try and offer a nice, affordable entry-level offering for Blox, but then we will, you know, as you get more and more different features, you'll pay at the appropriate level. So that's a little bit about what our future looks like. +WILL: That's neat some of the things you have coming up. You mentioned AI and how you're kind of embracing that. Can you expound on that? Like, kind of I know you said some data models automagically is going to do it. But, like, where can you see the benefit for a customer to use that? Because I know AI can be scary and stuff like that. But, like, just kind of taking the fear out of it and talking about how beneficial it can be. +SIMON: Yeah. So, there's lots of different places where AI can help. So, the typical model today for finance planning is you'd have a leader who's responsible for the business, and they're responsible for an advertising budget. You know, they just intuitively know, you know, where should I spend money, what's good return on my investment, what's, you know, what works. +But when it comes to actually trying to model that, so how to put that into a financial model or some other model that you can understand the relationships between these things, put in the KPIs, have the formulas, calculating things in the right way at the right level, what you often find is that the leader is not the system's expert. So, you'll often have, especially in bigger businesses, you've got this expert data analyst or FP&A finance planning person that will do the modeling. +So, we really believe that AI can be like a digital business coach to digitize that business advisory piece. So, the leader can be sitting down. They can be looking to try and improve some part of their business or understand some part of their spend and trying to work out, like, what would life look like if I increased my spend on this particular channel by X? And so, you know, we are looking at AI to help with lots of different areas around this. Initially, it's helping a new user to get onboarded with Blox. So, it's taking a template and helping to personalize it for their business. +What we basically try and do is fetch as much data about a new user and a new company as possible. So, if their team is on their website, then we'll pull in their team. If their products are listed on their website, we'll pull in a list of their products and try and throw that into the model and take out a lot of the friction that you have. As a user in the new system, you have to type in everything normally. If you're trying to model a business, you used to type it all in or copy and paste it from a spreadsheet. +So, we're looking at lots of options to help onboard new users. That has a good value add for us because we can increase the speed of adoption and help get users to value faster, which is great for us. And also, users are, you know, they're busy. They're impatient, and they want to understand what value they're going to get before they spend lots more of their time. So that's going to be useful for us and them. +And yeah, helping to interpret the data. So, they'll connect us to their source systems. We'll be able to interpret what's going on, help them to understand different options and scenarios about how things might play out in the future. Basically, AI will help us to draw our insights that we can present to the user, will help explain what the user is looking at when they're looking at the model, so we can summarize some of the key insights so that they can use that. +We're expecting to have all sorts of users, but we're really focusing on really busy leaders who may have a good understanding of spreadsheets and data, but they're just too busy, and so they don't have time. So, they want something which is quick and easy. Or leaders who don't have that expertise, so those are the ones that we really cater for. We try and keep it really simple and help guide them through the process, et cetera. So that's where AI is going to be, like, that digital business AI...We kind of kind of talk about this AI business coach concept. +And, over time, we'll build up more and more elements to that coach capability. We call him Anton in our team when we talk. We'll add more and more capabilities to him. But we've built a number of different POCs. And we've launched a couple of those with some customers. We've been out to events and showing off these new capabilities to basically test them out, understand what's working, what's not. What more do we need to think about to productionize this proof of concept? So that's, yeah, it's a very exciting time to be working on those things. +VICTORIA: I love hearing about that. That's super interesting to see where it's going to go. So, my last question for you today is, is there anything else that you would like to promote? +SIMON: I think I would just say, yeah, if you're a leader running a business or maybe it's a service business, and you're trying to think about, you know, when hiring business planning, financial planning, anything like that, then I'd love for you to come over to Blox, and you can jump straight into the product from our website. You can sign up. +I absolutely love chatting to people about their businesses and what they're trying to do with their finances. So, if you want to do that, you can sign up. You can chat to us. I actually take a lot of time to respond to people in there, so yeah, if you want to do that. Or, if you can, also find me on LinkedIn. You can search me there. Just strike up a conversation and say, "Hey, Simon, I'd love to chat about financial roadmapping or finance planning." +Yeah, I absolutely just love to speak to different leaders that work right across the business in different roles and see how we can help them to build a business that really unlock the potential that they have in their business through a great understanding of finances. So, yeah, if I can be of help, I would love that. +VICTORIA: Wonderful. And we'll have all those links in the show notes so our audience can go and take a look. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +VICTORIA: And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Simon Ritchie. + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

__

+ +

Simon Ritchie, the founder and CEO of Blox, discusses his background and journey leading up to starting the company. He began his career in finance but discovered his passion for technology and finance systems. He worked at Anaplan, a successful finance planning and analysis software company, but saw the limitations of rigid systems when COVID-19 hit. He realized there was a need for a more flexible and accessible financial modeling and planning tool, especially for small businesses and charities.

+ +

Blox aims to fill this gap by providing a powerful yet easy-to-use modeling, calculation, and planning engine that sits between spreadsheets and complex enterprise software. The company is about a year old, has raised venture funding, and launched a free tier of its product. They prioritize building a compelling product, iterating quickly, and engaging with users to understand their needs.

+ +

Simon acknowledges that building the product has been enjoyable, leveraging his background in product management. However, sales, marketing, and customer traction have proven challenging. Nonetheless, he remains optimistic about Blox's progress and is committed to providing a valuable solution to help businesses make informed decisions and achieve their financial goals.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with me today is Simon Ritchie, Founder and CEO of Blox, which provides pre-built planning models to help business leaders escape the tyranny of complex, clunky, and error-prone spreadsheets, giving you visibility into and confidence in the reality of your business.

+ +

Simon, thank you for joining us. How are you doing today?

+ +

SIMON: Hey, guys. Yeah, I'm very good today.

+ +

VICTORIA: So, Simon, where are you joining us from today?

+ +

SIMON: So, I'm joining from the UK. I live in a city called Brighton on the South Coast of the UK, where it's a lovely day today. It's nice and sunny.

+ +

VICTORIA: Oh, that's where our thoughtbot summit has been the last two years, in Brighton, actually.

+ +

SIMON: Fantastic. Yeah, it's a wonderful place.

+ +

VICTORIA: And a great place to be in the summer right now, right? Do you get out in the water very often?

+ +

SIMON: Yeah. Yeah, absolutely. Like many others, we have a paddle board. So, I go out with my family. I have four kids, so we go out and have fun at the beach. Brighton's got a stony beach. So we are, as Brightoners, we're very proud of the stones. You know, if you have sand, you get sand everywhere, stones are...it's much cleaner. [laughter] It does hurt your feet, though. There you go.

+ +

[laughter]

+ +

WILL: Yeah, that was the first time I've ever seen that, and I was like, that's very interesting.

+ +

SIMON: Yeah. [laughs]

+ +

WILL: I probably will like it because I don't like the sand getting everywhere, so...

+ +

SIMON: Yeah, absolutely.

+ +

WILL: So, yeah, I probably could trade that in. [laughs]

+ +

SIMON: Yeah, yeah. You just have to wear shoes if you want to go run around. We're proud. We're proud of it.

+ +

VICTORIA: I didn't think about that either. It makes a lot more sense. I don't really like the sand [laughter]. Rocks make more sense. But in California here, we're surfing, so having too many rocks on the beach would be a problem [laughs] for those of us who can't control ourselves. [laughter]

+ +

SIMON: Yes. Yeah, Victoria, I thought you lived in Wales when I first looked at your profile --

+ +

VICTORIA: Oh, right.

+ +

SIMON: On LinkedIn. And I thought, oh --

+ +

VICTORIA: That's...yeah.

+ +

SIMON: A Welsh girl. That's --

+ +

VICTORIA: My family is actually Welsh on my mother's side.

+ +

SIMON: Oh really?

+ +

VICTORIA: Yeah.

+ +

SIMON: Okay.

+ +

VICTORIA: And Cardiff...California is named after Cardiff, Wales.

+ +

SIMON: Okay, oh.

+ +

VICTORIA: But yeah, so that's where it came from. So, I thought that was very cute, too.

+ +

SIMON: [laughs] Very cool.

+ +

VICTORIA: But, you know, Cardiff-by-the Sea is its own little beach town here.

+ +

SIMON: It's not Wales. [laughs]

+ +

VICTORIA: Not Wales. [laughs] Pretty different. But I do hear Wales is beautiful.

+ +

SIMON: Oh, it is. Yeah, absolutely.

+ +

VICTORIA: Awesome. Well, let's talk about Blox a little bit. So, why don't you tell us maybe a little bit about your background and how you came around to starting it?

+ +

SIMON: Yeah, great. So, and just in terms of me and my background, so I started my career in finance, actually. I didn't really know what to go and study, so I thought, you know, studying numbers was probably a good thing. So, I did an accounting finance degree. And I got into the world of work in finance roles very quickly realized that finance wasn't for me. I just didn't really want to be a CFO. I just didn't feel the passion for it.

+ +

But I was the techie guy always in the finance team. I was the guy people turned to and originally for, you know, Excel and spreadsheet modeling. And behind Excel, you've got VBA. So, you've got this little, you know, it was my first exposure to programming and some, you know, and what coding was. And so, I sort of just realized, actually, I love the technology side. And so, I followed my passion more into the finance systems arena.

+ +

And my passion has always been...the focus of my career has been helping leaders understand what's going on in the business by getting hold of those numbers, the data that they have, and analyzing it, summarizing it, trying to draw insights from it so they can make decisions. And so, in the early days, it was lots of Excel spreadsheet modeling. And, in some businesses, there's still tons of spreadsheet modeling going on.

+ +

And then the next phase of my career was actually working in...there are a number of software options that help you with planning, modeling, reporting, et cetera. So, I joined...well, I did some consulting for a while and then joined a company called Anaplan. And was an early employee, the company was still very early in their journey. They were just launching a European office, so I joined as one of the early European employees.

+ +

And Anaplan went on, over the course of nearly eight years that I was there, to be [inaudible 04:31], absolute rocket ship, grew up to 2,000 people, and we floated on the New York Stock Exchange and then IPO in 2018. It was acquired last year for a very big number. So really fantastic time there.

+ +

But to just talk about Blox, so I left Anaplan two years ago. The observations that I made that led to Blox ultimately were there were sort of three main aspects. Like, when COVID happened, the world changed radically. And what I saw...I was working in Anaplan. For anyone who doesn't know, Anaplan they focus on selling to large enterprise. So, you may not be familiar with the company if you're not a CFO or a finance person in a very large company. And they sell very expensive product. It's very, very powerful modeling, calculation, FP&A, finance planning, and analysis software.

+ +

And so, companies...we were working with companies like Procter & Gamble, HP, Cisco, Google, and others. What I observed was when COVID kicked in, the FP&A system was too rigid. So, Anaplan, you know, these models that people had built up, spent a lot of time and energy building up, it was too rigid. The world changed so much that they couldn't really use their typical budgeting systems or these FP&A solutions. They couldn't use Anaplan.

+ +

So, everybody just jumped back into a spreadsheet to figure out, you know, do I still have a business? How am I going to survive this if I just had to shut all my retail stores or if I had to send everybody home? You know, so everyone was using spreadsheets, basically.

+ +

And so my observation there was that the tools that are available at that point are still way too hard to use. They're not flexible enough. You can't mold them quickly enough to really handle some of those scenarios that you want to throw at it as a leader. So, when you're trying to make big decisions about new revenue streams, new offices that you would want to launch, restructuring your team, investing in more people, those things they're really hard to model in the tools that are available. You need real specialist experience and expertise. That's very expensive, et cetera. So that was one part.

+ +

And then the other thing that happened was I've worked most of my career in larger companies. And I'd worked in, yeah, in finance, in businesses. And also, I'm a chartered management accountant. It's all about helping with managing a business with your numbers. And I hadn't really worked with many very small companies. I ended up volunteering.

+ +

When the lockdowns were happening, there were lots of people that were sheltering in place and they were staying at home. And so, a local charity had organized to put together food parcels, and then they found drivers to drive them around. And so I had volunteered through a friend of a friend, and somewhere my name got put in. So, I ended up driving these food deliveries around for the summer, and I loved it. Every Thursday, I'd take a couple of hours to just drive around and drop some food on people's doorsteps and then maybe have a quick conversation with them from a distance.

+ +

I got connected with the charity. It is a local charity that runs on the South Coast in England here. And they found out I was an accountant, and I worked in software technology. They were like, [gasps], please, you can be our new best friend. We need some help. So, I ended up helping them a bit in their back office with some of the reporting that they do. And to cut a long story short, they're a charity. They live on grant funding that they get. So, they apply for grants, and then the grant providers want them to report back on the progress that they've made, the services that they've offered, the people they've helped.

+ +

So, I went and helped them, and they needed these reports and some plans for grants that they were trying to get. What seemed really easy to me, like, they were showing me that they had to download this data from a system. And they needed to filter it and then count how many people they had been helping. And they basically were just, you know, with different needs and in different categories and cohorts.

+ +

So, they would basically download the data, open it in a spreadsheet, put a filter on, select some filters, and then they would count the number of rows that had that criteria. And then, they would type the number into an email. And I just showed them some very simple things, like, when you do a filter or if you select the cells, you can see a countdown at the bottom-right in Excel, and I showed them that. And they almost fell off their chair because [laughs] they were like, "Oh, you know, why did we not see that sooner?"

+ +

But I suppose through that, and, you know, through the various times that I helped them...and I just helped them with initially some spreadsheets and just some help with that. But it just showed me that there are a lot of businesses, a lot of charities in this case, but a lot of businesses where the leaders are not finance savvy, and they are not accountants. They're not MBAs, but they still need help running their business. They need to do reporting. They need to do planning, you know, manage their business, control the finances.

+ +

So, I just thought, you know, just started thinking a lot more about what does a small business need? What does a leader in a business need to make great decisions, run the business? And how could we get them a tool or some software that doesn't cost hundreds of grand every year but is accessible, a nice, low price point, and really easy for them to use? And that's the problem that I thought about for a long time. And ultimately, that's what we're trying to work on with Blox.

+ +

WILL: That's amazing. I used to work at a nonprofit. And I remember those days of, like, because I wasn't an MBA, like you said, MBA finance and just trying to figure out numbers. I don't even remember the software we used.

+ +

SIMON: [laughs]

+ +

WILL: But it was old and very hard to maneuver. [laughter]

+ +

SIMON: Oh yeah.

+ +

WILL: It was harder to maneuver than spreadsheets. And I was like, ahh, this is a nightmare. So, this is amazing that you're doing that. Can you tell us more about how Blox solves that issue? Because it sounds like it is a tween of big software that's for enterprise companies and spreadsheets. So, it's kind of in the middle; it sounds like.

+ +

SIMON: So, spreadsheets are great. They're really easy. They're easy to start with. You'll often find that your spreadsheet will just kind of reach its natural end. It becomes too complex. And that normally happens when you've got, like, you're planning for lots of people, or lots of products, or lots of different projects.

+ +

And so, you end up sort of having to figure out how to scale the model, you know, across lots of different columns or rows, or you start copying. And how you'll have three identical tabs or ten identical tabs. And, at that point, you've basically outgrown Excel, and trying to keep that spreadsheet running and working it becomes a real nightmare. And so, that's the point where Blox comes in. You could use Blox right from the very beginning.

+ +

We've started with a focus on making really nice, simple models that you can just pick up and use. So, our earliest customers are startups doing a financial model for a brand-new idea. So, you can use Blox from the beginning, but you could probably use a spreadsheet, too. Where you would want to use Blox is where it becomes more complex, and you've got a lot more going on. You might have lots of different months, and you've got loads of time. You might want to connect it to your actual accounting system or a CRM system.

+ +

And so, when you want to pull in actual data and do some reporting and maybe have different scenarios, different versions of a plan or of a report, that's where you've basically outgrown a spreadsheet, and it just becomes complex and unwieldy. And that's where you would want to move into a system. That's what we're building with Blox is basically a powerful modeling calculation planning engine that scales really easily.

+ +

So, you can build up your dimensions, products, countries, time, et cetera, and you can build up those dimensions. You can build up your logic. You can add your own KPIs. You can add your own projection logic, et cetera. You can build out a model. We've got lots of template models that you can start with because you shouldn't have to start from scratch every time. You can get going. You can load up your own data very quickly at the beginning.

+ +

For a lot of models, it's just assumptions. You're just trying to work out, okay, like, we've got some service businesses that use Blox. To get a basic model together, what you need to know is how many people do you have roughly? How much do you pay them? And then, how many people do you plan to hire at certain times? And how long does it take to ramp a new hire? Because, normally, there's some sort of ramp time.

+ +

And if it's a service business and you're selling time, then you kind of have an average number of hours billable or often called utilization. So, with a few quick assumptions, you could throw them in. You could build out a multi-year plan for your business. And you could use that to think about, okay, how can I grow this business? I kind of talk about it as a financial roadmap that you could create.

+ +

So, you know, often in the product world, we talk about product roadmaps. I like to talk about, you know, a business roadmap or financial roadmap. And that's really what we are working on; Blox and Blox will help you with this financial roadmap that you can build out. You know, I'd like to get my business to this point to, you know, 2 million in revenue, or 10 million in revenue, or maybe there are some financial or non-financial goals that you're trying to get to.

+ +

And, with a model, you can help try and kind of work out what the assumptions and drivers and what those things need to look like. And then, as a manager of the business, you can start working on, okay, how do I increase my headcount? Or how do I decrease this particular cost per unit or various things like that? So yeah, that's a very high level on what we're doing with Blox.

+ +

VICTORIA: Thank you for that. And I certainly can relate to that, having worked for several different consulting services companies and how difficult it can be to get software [laughs] to project that --

+ +

SIMON: [laughs]

+ +

VICTORIA: Far into the future, like, to think about how you're going to hire, all the things that go into it. So, I'm curious about your own plan for Blox. Like, how would you describe where you are in your plan for the company?

+ +

SIMON: We are a year old, actually just celebrated our one-year anniversary. In the last year, we've formed, hired an early team. We've fundraised successfully. So, we raised venture finance to fund the business. It's a complex product to build. We're trying to replace a spreadsheet, which has got tons and tons of features. They've been developing that for a long time. So, for someone to come across, it needs to be a relatively mature product.

+ +

So, we raised venture funds from investors. We're busy investing that to build up the product and take that to market. It's been a fantastic year. And this is my first time as a founder. I've worked in leadership roles in technology businesses, in customer success, and in product as well.

+ +

Yeah, I definitely would say working as a founder in a brand-new startup is very different to working in product, in a scale-up. You know, some of the lessons that I learned back there have been useful. You know, you learn how to juggle chaos, how to juggle...how to spin lots of plates. But yeah, I'm really delighted with our progress so far. We've fundraised. We ran a beta of our product last year with some early customers. We graduated from that.

+ +

Our approach has always been to try and get the product out, so really embrace agile. It's kind of you don't see it so often in enterprise software. What you see is companies that like to just put "Book a demo" on the website. And they don't like to show their software until they've already kind of sold the value, and they've pitched, you know, positioned their pricing, and qualified their leads, et cetera. Our approach has always been let's build a fantastic product. Let's build something which is super compelling, super easy to use. Let's get people into the product as quickly as possible so they can experience it, see if it's going to be valuable for them.

+ +

We launched a free tier of our product, the first sort of MVP, as a free tier, so not paid, not with some of the features that we plan to add to the product. And so, we've got that out there, and it's been fantastic. We've got users from all over the world using it in all sorts of different ways. And that's the other thing that is really great for us. Because it's such a flexible product, it can be used in lots of places.

+ +

So, we've got all sorts of different applications being used by it. People jump in; they use it. They can try different templates that we've got. And then, if they need something different...every business is slightly different. So, if they need something slightly different, they can just chat to us in the product. We absolutely love chatting to people. And then, you know, we'll often spin up a custom template for them. And when we've done a few of those, then we'll build a standard template for a new industry. That's a little bit about where we're at.

+ +

We're a small team based between here and India, where most of our developers are. It's good fun. Some of the learning...so I would say maybe it's just because of my background. So, I moved into product, and I was a product manager and then product leader for the last six years.

+ +

So, for me, I've found building the product has been the easier part, probably because it's my background and that's where my passion is. So, I absolutely love anytime I get to spend in the product and spend with the team. The original founding team is myself as founder and CEO. And I don't get too much time on the product. I have a product manager and a designer. And so, that was the first...the early team, the founding team. And then we've added marketing and some other roles and software development. And so that's the team.

+ +

I've found building the product has been really fun, and that's been a bit easier. Trying to work out how to do fundraising was a real challenge, so that took a lot of energy. We've been pretty successful so far in that. Still, always more to go, always more fundraising needed definitely. The really hard thing, especially in the market that we're in right now, it's hard, you know, getting early customer traction and selling. And that's really hard trying to get your name out there, build a brand, find early customers. That's really hard.

+ +

So yeah, that's definitely an observation for me that the product has been really fun and a bit easier than I thought. But yeah, trying to do sales, marketing, figure that out...and probably as well because it's not my background or my kind of natural area of interest, so I've been learning. That's always tough, isn't it?

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So...

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

WILL: You mentioned getting your product out there how challenging it can be. So, what has been some other wins and some challenges that you've had as a first-time founder?

+ +

SIMON: So, my approach to things as a leader is I basically like to bring silliness and games to help motivate and energize the team. So, as a human, I have quite a lot of energy. I roll around with lots of energy. And I take loads of photos of what I'm doing, and I share those. So, we have a Friday wrap-up with the team, and so I'll often share a lot of the pictures of, you know, what I've been up to this week.

+ +

So, yeah, there's been some really fantastic moments launching a product. We launched our MVP in three months. So, we basically set off...I actually funded the first season of the business, a couple of software developers, a couple of early employees. I funded the first season. We hadn't raised money. And I just spoke to my wife, and I said, "Look, now's the time. I really want to do this."

+ +

You know, I've been saving up if you like, I had this, like, one day I'll do a startup fund. Some people would probably call that their long-term savings or like, you know, some...and I kind of called it my one day I'll do a startup fund. So, I'd been building up this fund because I knew that at some point, I'll probably go do this. The timing was way earlier than I thought. I thought I'd still do another four or five years in a career in a corporate role to try and get a few more notches in my belts to make fundraising easier, et cetera.

+ +

The timing came. The team was perfect. And everything just felt right, so we went for it. But yeah, we basically set out. We didn't know where we were going to get funding from. The market was in a real state, so this was middle of 2022. The Ukraine war had kicked in; valuations had dropped by 90% for a lot of tech companies. The post-COVID bubble had burst. It was hard.

+ +

So, we sat down, and we were like, okay, we could spend all of our runway trying to fundraise now, or we could crack on and try and build the first MVP. But we'd already done a lot of the market research, the user testing, early prototypes, et cetera. And that's a bit of a long story. But we had done that in the company that the founding team had worked at, and then we were actually a spin-out. So that happened.

+ +

And we were sitting here thinking, okay, you know, we could spend all of our runway fundraising, or we could just crack on and build a product as quick as we can in the next three months. And so, we had this really hard conversation where we descoped so much stuff. And we just figured out what's the core piece that will really show the value of what we're trying to build, that we'd give to a user, that we could give to an early customer that they could use and get value from? And so, we came up with that scope.

+ +

And we cracked on, and we built it. Within two and a half months, we had a working version. We played with it. Within three months, we kind of launched into this beta and got early users onto. So that was, you know, fantastic. So, we did that in the first three months, and then off the success of having an MVP, and just being able to show the product, and start getting some early user feedback, initial feedback was, you know, we took into account very quickly and improved.

+ +

And just having that, you know, you basically start building momentum. Every step is still really hard, but you do build momentum. So, we got this product. We launched it. We went to a couple of events, and we talked about that, and then we did some fundraising. And we landed some funding, so that was fantastic. And then, you know, and then we've just gone sort of step by step from there. So, it's really fantastic what we've been able to achieve so far.

+ +

The challenges there's been loads of them, especially when you're building a startup. It's really exciting. So, you can get people excited quite easily about the future potential. And you can kind of talk about what this can be. I've got a printed picture of a unicorn on my whiteboard in my office right here as a sort of a statement of, you know, where we're going.

+ +

It's really hard as a founder or a leader trying to persuade people to leave a stable job, take a pay cut, and come and work with you and give them some equity, which you hope will be worth a ton, and you kind of paint the picture. But also, you don't know how long you can keep them because you're on runway. You're on runway. You haven't got infinite cash if it's not a profitable business.

+ +

So, you know, there are some real challenges. And, as a founder, you go through ups and downs. Ben Horowitz talks about it in his great book, The Hard Things About Hard Things, as the struggle. I definitely understand that a lot more now because there is an up and down to this. You do build momentum, but you also...you're creating the momentum, you know, one hard push at a time. So that's that early customers come on. You kind of pitch the dream of what the product will do, and then it will fall over as soon as they touch it. But I absolutely love it.

+ +

What I love is the chance to create and how quickly you can move in the early days of a startup or a new product, where you don't have masses of technical debt. You don't have hundreds of customers. You don't have all this, you know, you don't have a massive team where everyone's got their point of view on what you should do. So, you can move really fast, and that's fantastic [inaudible 30:14] creative season. So yeah, lots of ups and downs, but it's really fun.

+ +

VICTORIA: That's so interesting and particularly interesting that you're trying to make something that's easier to use than Excel. So, I'm curious how you're testing to make sure that it's actually easy. And what might be...I'm sure there's some interesting feedback you got about that.

+ +

SIMON: Yeah, so we're making Blox easier than Excel. But it's got to be powerful enough to be able to handle the data and the modeling that you need for a business. If you're doing projections for multiple years if you've got lots of products or teams, then it can be complex, so it needs to be powerful enough to handle that. It needs to be flexible enough because you can take a template, but every business has got its own unique quirks. So, it needs to be flexible enough that it can be tailored easy for a unique business.

+ +

And then, crucially, and this is also important, it needs to be easy enough to use so that the person who understands the business can change the model to kind of suit their business. That's the bit that most of the other players, you know, the enterprise software that's available today, just that they haven't figured out how to make it easy enough so that a businessperson that, you know, doesn't have database experience, can't write SQL, not going to write Python, you know, doesn't do complex scripting or any of this stuff.

+ +

It's got to be easy enough that they can, you know, tailor, reflect the way that their business works, the way that they make money, the way that their cost structure works, so they can figure out what drives the business. And so, if they're projecting revenue, they can work out the costs associated.

+ +

So, one of our founding team is a UX designer, a really, really fantastic designer, very experienced. He's been in the game for 25 years since, way before it was called UX. And started doing graphic design, and then has done lots of branding and branding for some really fantastic, large companies, did lots of consulting. And then got into UX and how, you know, the art of wireframing and helping to make products easily usable. I call him my secret weapon. I've worked with some fantastic designers in the past, so, as a founder, I think I appreciate and understand the value of a really good design and a really good UX designer.

+ +

So, Mike, our UX designer, has just been fantastic at that. He's very good at wireframing and very good at testing. And he's not a finance planning expert. That's why I call him my secret weapon because, you know, I understand planning really well, but sometimes I understand it too well. When I describe what a user is trying to do or, you know, what I expect a screen will look like, I'm just probably subconsciously replacing or recreating something that I've seen or used before, whereas he's coming at it brand new. He's not worked in planning or data modeling, or many of these things. He's worked in lots of different businesses.

+ +

So, he comes at it with a mobile-first perspective. Normally, he's thinking about, okay, how could this be used by a busy leader on their phone and they're running around? And so, he's been really fantastic at helping to keep it simple and easy and to rethink and to create a product, which is just so different to what other tools in the space are doing. And that's some of the feedback we get. It looks so different. It works so different.

+ +

But yeah, the hard thing is that spreadsheets are the most sticky tool, I think. They're just so useful for, you know, for everything where you need to get a list of things. You just start throwing it into a spreadsheet, and then you can, you know, organize it and improve structure over time. But yeah, it's a really sticky tool. And we train people how to use spreadsheets from early days from school. My 12-year-old daughter she already has been taught how to use a spreadsheet in school.

+ +

So, what we're trying to do is create something which is easier. But there's also, you know, you want there to be some familiarity in there so that people will...to avoid some of the friction of the people who have it. No one really signs up to learn a new tool if they can avoid it. We're lazy. [laughs]

+ +

VICTORIA: It makes sense that design would be a big priority for your product because that was your intention from the beginning, right? Is to make something that's easy to use, so you prioritize that as an investment.

+ +

SIMON: That's right. That's absolutely right. Yeah.

+ +

VICTORIA: What's on the horizon? What are you the most excited about for Blox in the coming months?

+ +

SIMON: So, yeah, we've got some really exciting elements of our roadmap coming. So, yeah, really excited to see these things come to life. Like anyone working in building products, whether you're designing, doing product, sort of overseeing, or actually developing, it's so great to see these things come to life. You spend a long time thinking and chatting about them, imagining, ideating about how they could look.

+ +

The thing that I'm just most excited about is—and that's probably why I love product—is, you know, you're building a product, and then you can...then you're talking to somebody about how they would use this. Or before that, you're talking about their day-to-day right now and what their problems are, and how you could help them save time, save money, et cetera.

+ +

And so, you know, I absolutely love chatting to more and more different types of companies, leaders in different parts of the business. And, you know, especially in our space, it's mostly about, okay, how can I help? You know, how could we improve this planning process that we've got, whether it's, you know, planning for the cost of running a big project or trying to figure out how can I scale my business to reach my objectives? So, I just love chatting to lots of different leaders globally. So, I love going to events, chatting to people, fact-finding about how they run their business, how they think about finances, et cetera.

+ +

In terms of the product roadmap, we're working on some exciting new scenario capabilities, so you can easily look at different scenarios around a decision. So, you might be trying to decide, you know, should I be aggressive with my investments and hiring, or should I be pessimistic? Or is there a middle ground? So, we're adding, like, scenario capabilities where you can build out different versions of that, and then easily compare and contrast, and then decide which one to do.

+ +

We're working on some really...really enjoying working on some intelligent capabilities. So, again, in the search of making it really easy to use for a busy leader, for a busy businessperson, or a busy finance person, making it really easy to use. So, we've invested a lot in AI technology and been designing, developing POCs around how AI could help to onboard customers faster, how we could help to personalize models for businesses automagically.

+ +

So, as soon as we understand the website of a user, what sort of industry they're in, we can automagically personalize the template for them, add their own KPIs, like, industry-specific KPIs, into the model, and throw in benchmark data and all these things. So, we've got some fantastic AI capabilities coming through the pipe and some data integrations. As we get out more and more, we're connecting to different data sources. So, yeah, exciting times ahead for the roadmap.

+ +

And as we add more features, then we'll add different pricing tiers, you know, so we can try and offer a nice, affordable entry-level offering for Blox, but then we will, you know, as you get more and more different features, you'll pay at the appropriate level. So that's a little bit about what our future looks like.

+ +

WILL: That's neat some of the things you have coming up. You mentioned AI and how you're kind of embracing that. Can you expound on that? Like, kind of I know you said some data models automagically is going to do it. But, like, where can you see the benefit for a customer to use that? Because I know AI can be scary and stuff like that. But, like, just kind of taking the fear out of it and talking about how beneficial it can be.

+ +

SIMON: Yeah. So, there's lots of different places where AI can help. So, the typical model today for finance planning is you'd have a leader who's responsible for the business, and they're responsible for an advertising budget. You know, they just intuitively know, you know, where should I spend money, what's good return on my investment, what's, you know, what works.

+ +

But when it comes to actually trying to model that, so how to put that into a financial model or some other model that you can understand the relationships between these things, put in the KPIs, have the formulas, calculating things in the right way at the right level, what you often find is that the leader is not the system's expert. So, you'll often have, especially in bigger businesses, you've got this expert data analyst or FP&A finance planning person that will do the modeling.

+ +

So, we really believe that AI can be like a digital business coach to digitize that business advisory piece. So, the leader can be sitting down. They can be looking to try and improve some part of their business or understand some part of their spend and trying to work out, like, what would life look like if I increased my spend on this particular channel by X? And so, you know, we are looking at AI to help with lots of different areas around this. Initially, it's helping a new user to get onboarded with Blox. So, it's taking a template and helping to personalize it for their business.

+ +

What we basically try and do is fetch as much data about a new user and a new company as possible. So, if their team is on their website, then we'll pull in their team. If their products are listed on their website, we'll pull in a list of their products and try and throw that into the model and take out a lot of the friction that you have. As a user in the new system, you have to type in everything normally. If you're trying to model a business, you used to type it all in or copy and paste it from a spreadsheet.

+ +

So, we're looking at lots of options to help onboard new users. That has a good value add for us because we can increase the speed of adoption and help get users to value faster, which is great for us. And also, users are, you know, they're busy. They're impatient, and they want to understand what value they're going to get before they spend lots more of their time. So that's going to be useful for us and them.

+ +

And yeah, helping to interpret the data. So, they'll connect us to their source systems. We'll be able to interpret what's going on, help them to understand different options and scenarios about how things might play out in the future. Basically, AI will help us to draw our insights that we can present to the user, will help explain what the user is looking at when they're looking at the model, so we can summarize some of the key insights so that they can use that.

+ +

We're expecting to have all sorts of users, but we're really focusing on really busy leaders who may have a good understanding of spreadsheets and data, but they're just too busy, and so they don't have time. So, they want something which is quick and easy. Or leaders who don't have that expertise, so those are the ones that we really cater for. We try and keep it really simple and help guide them through the process, et cetera. So that's where AI is going to be, like, that digital business AI...We kind of kind of talk about this AI business coach concept.

+ +

And, over time, we'll build up more and more elements to that coach capability. We call him Anton in our team when we talk. We'll add more and more capabilities to him. But we've built a number of different POCs. And we've launched a couple of those with some customers. We've been out to events and showing off these new capabilities to basically test them out, understand what's working, what's not. What more do we need to think about to productionize this proof of concept? So that's, yeah, it's a very exciting time to be working on those things.

+ +

VICTORIA: I love hearing about that. That's super interesting to see where it's going to go. So, my last question for you today is, is there anything else that you would like to promote?

+ +

SIMON: I think I would just say, yeah, if you're a leader running a business or maybe it's a service business, and you're trying to think about, you know, when hiring business planning, financial planning, anything like that, then I'd love for you to come over to Blox, and you can jump straight into the product from our website. You can sign up.

+ +

I absolutely love chatting to people about their businesses and what they're trying to do with their finances. So, if you want to do that, you can sign up. You can chat to us. I actually take a lot of time to respond to people in there, so yeah, if you want to do that. Or, if you can, also find me on LinkedIn. You can search me there. Just strike up a conversation and say, "Hey, Simon, I'd love to chat about financial roadmapping or finance planning."

+ +

Yeah, I absolutely just love to speak to different leaders that work right across the business in different roles and see how we can help them to build a business that really unlock the potential that they have in their business through a great understanding of finances. So, yeah, if I can be of help, I would love that.

+ +

VICTORIA: Wonderful. And we'll have all those links in the show notes so our audience can go and take a look.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Simon Ritchie.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

__

+ +

Simon Ritchie, the founder and CEO of Blox, discusses his background and journey leading up to starting the company. He began his career in finance but discovered his passion for technology and finance systems. He worked at Anaplan, a successful finance planning and analysis software company, but saw the limitations of rigid systems when COVID-19 hit. He realized there was a need for a more flexible and accessible financial modeling and planning tool, especially for small businesses and charities.

+ +

Blox aims to fill this gap by providing a powerful yet easy-to-use modeling, calculation, and planning engine that sits between spreadsheets and complex enterprise software. The company is about a year old, has raised venture funding, and launched a free tier of its product. They prioritize building a compelling product, iterating quickly, and engaging with users to understand their needs.

+ +

Simon acknowledges that building the product has been enjoyable, leveraging his background in product management. However, sales, marketing, and customer traction have proven challenging. Nonetheless, he remains optimistic about Blox's progress and is committed to providing a valuable solution to help businesses make informed decisions and achieve their financial goals.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with me today is Simon Ritchie, Founder and CEO of Blox, which provides pre-built planning models to help business leaders escape the tyranny of complex, clunky, and error-prone spreadsheets, giving you visibility into and confidence in the reality of your business.

+ +

Simon, thank you for joining us. How are you doing today?

+ +

SIMON: Hey, guys. Yeah, I'm very good today.

+ +

VICTORIA: So, Simon, where are you joining us from today?

+ +

SIMON: So, I'm joining from the UK. I live in a city called Brighton on the South Coast of the UK, where it's a lovely day today. It's nice and sunny.

+ +

VICTORIA: Oh, that's where our thoughtbot summit has been the last two years, in Brighton, actually.

+ +

SIMON: Fantastic. Yeah, it's a wonderful place.

+ +

VICTORIA: And a great place to be in the summer right now, right? Do you get out in the water very often?

+ +

SIMON: Yeah. Yeah, absolutely. Like many others, we have a paddle board. So, I go out with my family. I have four kids, so we go out and have fun at the beach. Brighton's got a stony beach. So we are, as Brightoners, we're very proud of the stones. You know, if you have sand, you get sand everywhere, stones are...it's much cleaner. [laughter] It does hurt your feet, though. There you go.

+ +

[laughter]

+ +

WILL: Yeah, that was the first time I've ever seen that, and I was like, that's very interesting.

+ +

SIMON: Yeah. [laughs]

+ +

WILL: I probably will like it because I don't like the sand getting everywhere, so...

+ +

SIMON: Yeah, absolutely.

+ +

WILL: So, yeah, I probably could trade that in. [laughs]

+ +

SIMON: Yeah, yeah. You just have to wear shoes if you want to go run around. We're proud. We're proud of it.

+ +

VICTORIA: I didn't think about that either. It makes a lot more sense. I don't really like the sand [laughter]. Rocks make more sense. But in California here, we're surfing, so having too many rocks on the beach would be a problem [laughs] for those of us who can't control ourselves. [laughter]

+ +

SIMON: Yes. Yeah, Victoria, I thought you lived in Wales when I first looked at your profile --

+ +

VICTORIA: Oh, right.

+ +

SIMON: On LinkedIn. And I thought, oh --

+ +

VICTORIA: That's...yeah.

+ +

SIMON: A Welsh girl. That's --

+ +

VICTORIA: My family is actually Welsh on my mother's side.

+ +

SIMON: Oh really?

+ +

VICTORIA: Yeah.

+ +

SIMON: Okay.

+ +

VICTORIA: And Cardiff...California is named after Cardiff, Wales.

+ +

SIMON: Okay, oh.

+ +

VICTORIA: But yeah, so that's where it came from. So, I thought that was very cute, too.

+ +

SIMON: [laughs] Very cool.

+ +

VICTORIA: But, you know, Cardiff-by-the Sea is its own little beach town here.

+ +

SIMON: It's not Wales. [laughs]

+ +

VICTORIA: Not Wales. [laughs] Pretty different. But I do hear Wales is beautiful.

+ +

SIMON: Oh, it is. Yeah, absolutely.

+ +

VICTORIA: Awesome. Well, let's talk about Blox a little bit. So, why don't you tell us maybe a little bit about your background and how you came around to starting it?

+ +

SIMON: Yeah, great. So, and just in terms of me and my background, so I started my career in finance, actually. I didn't really know what to go and study, so I thought, you know, studying numbers was probably a good thing. So, I did an accounting finance degree. And I got into the world of work in finance roles very quickly realized that finance wasn't for me. I just didn't really want to be a CFO. I just didn't feel the passion for it.

+ +

But I was the techie guy always in the finance team. I was the guy people turned to and originally for, you know, Excel and spreadsheet modeling. And behind Excel, you've got VBA. So, you've got this little, you know, it was my first exposure to programming and some, you know, and what coding was. And so, I sort of just realized, actually, I love the technology side. And so, I followed my passion more into the finance systems arena.

+ +

And my passion has always been...the focus of my career has been helping leaders understand what's going on in the business by getting hold of those numbers, the data that they have, and analyzing it, summarizing it, trying to draw insights from it so they can make decisions. And so, in the early days, it was lots of Excel spreadsheet modeling. And, in some businesses, there's still tons of spreadsheet modeling going on.

+ +

And then the next phase of my career was actually working in...there are a number of software options that help you with planning, modeling, reporting, et cetera. So, I joined...well, I did some consulting for a while and then joined a company called Anaplan. And was an early employee, the company was still very early in their journey. They were just launching a European office, so I joined as one of the early European employees.

+ +

And Anaplan went on, over the course of nearly eight years that I was there, to be [inaudible 04:31], absolute rocket ship, grew up to 2,000 people, and we floated on the New York Stock Exchange and then IPO in 2018. It was acquired last year for a very big number. So really fantastic time there.

+ +

But to just talk about Blox, so I left Anaplan two years ago. The observations that I made that led to Blox ultimately were there were sort of three main aspects. Like, when COVID happened, the world changed radically. And what I saw...I was working in Anaplan. For anyone who doesn't know, Anaplan they focus on selling to large enterprise. So, you may not be familiar with the company if you're not a CFO or a finance person in a very large company. And they sell very expensive product. It's very, very powerful modeling, calculation, FP&A, finance planning, and analysis software.

+ +

And so, companies...we were working with companies like Procter & Gamble, HP, Cisco, Google, and others. What I observed was when COVID kicked in, the FP&A system was too rigid. So, Anaplan, you know, these models that people had built up, spent a lot of time and energy building up, it was too rigid. The world changed so much that they couldn't really use their typical budgeting systems or these FP&A solutions. They couldn't use Anaplan.

+ +

So, everybody just jumped back into a spreadsheet to figure out, you know, do I still have a business? How am I going to survive this if I just had to shut all my retail stores or if I had to send everybody home? You know, so everyone was using spreadsheets, basically.

+ +

And so my observation there was that the tools that are available at that point are still way too hard to use. They're not flexible enough. You can't mold them quickly enough to really handle some of those scenarios that you want to throw at it as a leader. So, when you're trying to make big decisions about new revenue streams, new offices that you would want to launch, restructuring your team, investing in more people, those things they're really hard to model in the tools that are available. You need real specialist experience and expertise. That's very expensive, et cetera. So that was one part.

+ +

And then the other thing that happened was I've worked most of my career in larger companies. And I'd worked in, yeah, in finance, in businesses. And also, I'm a chartered management accountant. It's all about helping with managing a business with your numbers. And I hadn't really worked with many very small companies. I ended up volunteering.

+ +

When the lockdowns were happening, there were lots of people that were sheltering in place and they were staying at home. And so, a local charity had organized to put together food parcels, and then they found drivers to drive them around. And so I had volunteered through a friend of a friend, and somewhere my name got put in. So, I ended up driving these food deliveries around for the summer, and I loved it. Every Thursday, I'd take a couple of hours to just drive around and drop some food on people's doorsteps and then maybe have a quick conversation with them from a distance.

+ +

I got connected with the charity. It is a local charity that runs on the South Coast in England here. And they found out I was an accountant, and I worked in software technology. They were like, [gasps], please, you can be our new best friend. We need some help. So, I ended up helping them a bit in their back office with some of the reporting that they do. And to cut a long story short, they're a charity. They live on grant funding that they get. So, they apply for grants, and then the grant providers want them to report back on the progress that they've made, the services that they've offered, the people they've helped.

+ +

So, I went and helped them, and they needed these reports and some plans for grants that they were trying to get. What seemed really easy to me, like, they were showing me that they had to download this data from a system. And they needed to filter it and then count how many people they had been helping. And they basically were just, you know, with different needs and in different categories and cohorts.

+ +

So, they would basically download the data, open it in a spreadsheet, put a filter on, select some filters, and then they would count the number of rows that had that criteria. And then, they would type the number into an email. And I just showed them some very simple things, like, when you do a filter or if you select the cells, you can see a countdown at the bottom-right in Excel, and I showed them that. And they almost fell off their chair because [laughs] they were like, "Oh, you know, why did we not see that sooner?"

+ +

But I suppose through that, and, you know, through the various times that I helped them...and I just helped them with initially some spreadsheets and just some help with that. But it just showed me that there are a lot of businesses, a lot of charities in this case, but a lot of businesses where the leaders are not finance savvy, and they are not accountants. They're not MBAs, but they still need help running their business. They need to do reporting. They need to do planning, you know, manage their business, control the finances.

+ +

So, I just thought, you know, just started thinking a lot more about what does a small business need? What does a leader in a business need to make great decisions, run the business? And how could we get them a tool or some software that doesn't cost hundreds of grand every year but is accessible, a nice, low price point, and really easy for them to use? And that's the problem that I thought about for a long time. And ultimately, that's what we're trying to work on with Blox.

+ +

WILL: That's amazing. I used to work at a nonprofit. And I remember those days of, like, because I wasn't an MBA, like you said, MBA finance and just trying to figure out numbers. I don't even remember the software we used.

+ +

SIMON: [laughs]

+ +

WILL: But it was old and very hard to maneuver. [laughter]

+ +

SIMON: Oh yeah.

+ +

WILL: It was harder to maneuver than spreadsheets. And I was like, ahh, this is a nightmare. So, this is amazing that you're doing that. Can you tell us more about how Blox solves that issue? Because it sounds like it is a tween of big software that's for enterprise companies and spreadsheets. So, it's kind of in the middle; it sounds like.

+ +

SIMON: So, spreadsheets are great. They're really easy. They're easy to start with. You'll often find that your spreadsheet will just kind of reach its natural end. It becomes too complex. And that normally happens when you've got, like, you're planning for lots of people, or lots of products, or lots of different projects.

+ +

And so, you end up sort of having to figure out how to scale the model, you know, across lots of different columns or rows, or you start copying. And how you'll have three identical tabs or ten identical tabs. And, at that point, you've basically outgrown Excel, and trying to keep that spreadsheet running and working it becomes a real nightmare. And so, that's the point where Blox comes in. You could use Blox right from the very beginning.

+ +

We've started with a focus on making really nice, simple models that you can just pick up and use. So, our earliest customers are startups doing a financial model for a brand-new idea. So, you can use Blox from the beginning, but you could probably use a spreadsheet, too. Where you would want to use Blox is where it becomes more complex, and you've got a lot more going on. You might have lots of different months, and you've got loads of time. You might want to connect it to your actual accounting system or a CRM system.

+ +

And so, when you want to pull in actual data and do some reporting and maybe have different scenarios, different versions of a plan or of a report, that's where you've basically outgrown a spreadsheet, and it just becomes complex and unwieldy. And that's where you would want to move into a system. That's what we're building with Blox is basically a powerful modeling calculation planning engine that scales really easily.

+ +

So, you can build up your dimensions, products, countries, time, et cetera, and you can build up those dimensions. You can build up your logic. You can add your own KPIs. You can add your own projection logic, et cetera. You can build out a model. We've got lots of template models that you can start with because you shouldn't have to start from scratch every time. You can get going. You can load up your own data very quickly at the beginning.

+ +

For a lot of models, it's just assumptions. You're just trying to work out, okay, like, we've got some service businesses that use Blox. To get a basic model together, what you need to know is how many people do you have roughly? How much do you pay them? And then, how many people do you plan to hire at certain times? And how long does it take to ramp a new hire? Because, normally, there's some sort of ramp time.

+ +

And if it's a service business and you're selling time, then you kind of have an average number of hours billable or often called utilization. So, with a few quick assumptions, you could throw them in. You could build out a multi-year plan for your business. And you could use that to think about, okay, how can I grow this business? I kind of talk about it as a financial roadmap that you could create.

+ +

So, you know, often in the product world, we talk about product roadmaps. I like to talk about, you know, a business roadmap or financial roadmap. And that's really what we are working on; Blox and Blox will help you with this financial roadmap that you can build out. You know, I'd like to get my business to this point to, you know, 2 million in revenue, or 10 million in revenue, or maybe there are some financial or non-financial goals that you're trying to get to.

+ +

And, with a model, you can help try and kind of work out what the assumptions and drivers and what those things need to look like. And then, as a manager of the business, you can start working on, okay, how do I increase my headcount? Or how do I decrease this particular cost per unit or various things like that? So yeah, that's a very high level on what we're doing with Blox.

+ +

VICTORIA: Thank you for that. And I certainly can relate to that, having worked for several different consulting services companies and how difficult it can be to get software [laughs] to project that --

+ +

SIMON: [laughs]

+ +

VICTORIA: Far into the future, like, to think about how you're going to hire, all the things that go into it. So, I'm curious about your own plan for Blox. Like, how would you describe where you are in your plan for the company?

+ +

SIMON: We are a year old, actually just celebrated our one-year anniversary. In the last year, we've formed, hired an early team. We've fundraised successfully. So, we raised venture finance to fund the business. It's a complex product to build. We're trying to replace a spreadsheet, which has got tons and tons of features. They've been developing that for a long time. So, for someone to come across, it needs to be a relatively mature product.

+ +

So, we raised venture funds from investors. We're busy investing that to build up the product and take that to market. It's been a fantastic year. And this is my first time as a founder. I've worked in leadership roles in technology businesses, in customer success, and in product as well.

+ +

Yeah, I definitely would say working as a founder in a brand-new startup is very different to working in product, in a scale-up. You know, some of the lessons that I learned back there have been useful. You know, you learn how to juggle chaos, how to juggle...how to spin lots of plates. But yeah, I'm really delighted with our progress so far. We've fundraised. We ran a beta of our product last year with some early customers. We graduated from that.

+ +

Our approach has always been to try and get the product out, so really embrace agile. It's kind of you don't see it so often in enterprise software. What you see is companies that like to just put "Book a demo" on the website. And they don't like to show their software until they've already kind of sold the value, and they've pitched, you know, positioned their pricing, and qualified their leads, et cetera. Our approach has always been let's build a fantastic product. Let's build something which is super compelling, super easy to use. Let's get people into the product as quickly as possible so they can experience it, see if it's going to be valuable for them.

+ +

We launched a free tier of our product, the first sort of MVP, as a free tier, so not paid, not with some of the features that we plan to add to the product. And so, we've got that out there, and it's been fantastic. We've got users from all over the world using it in all sorts of different ways. And that's the other thing that is really great for us. Because it's such a flexible product, it can be used in lots of places.

+ +

So, we've got all sorts of different applications being used by it. People jump in; they use it. They can try different templates that we've got. And then, if they need something different...every business is slightly different. So, if they need something slightly different, they can just chat to us in the product. We absolutely love chatting to people. And then, you know, we'll often spin up a custom template for them. And when we've done a few of those, then we'll build a standard template for a new industry. That's a little bit about where we're at.

+ +

We're a small team based between here and India, where most of our developers are. It's good fun. Some of the learning...so I would say maybe it's just because of my background. So, I moved into product, and I was a product manager and then product leader for the last six years.

+ +

So, for me, I've found building the product has been the easier part, probably because it's my background and that's where my passion is. So, I absolutely love anytime I get to spend in the product and spend with the team. The original founding team is myself as founder and CEO. And I don't get too much time on the product. I have a product manager and a designer. And so, that was the first...the early team, the founding team. And then we've added marketing and some other roles and software development. And so that's the team.

+ +

I've found building the product has been really fun, and that's been a bit easier. Trying to work out how to do fundraising was a real challenge, so that took a lot of energy. We've been pretty successful so far in that. Still, always more to go, always more fundraising needed definitely. The really hard thing, especially in the market that we're in right now, it's hard, you know, getting early customer traction and selling. And that's really hard trying to get your name out there, build a brand, find early customers. That's really hard.

+ +

So yeah, that's definitely an observation for me that the product has been really fun and a bit easier than I thought. But yeah, trying to do sales, marketing, figure that out...and probably as well because it's not my background or my kind of natural area of interest, so I've been learning. That's always tough, isn't it?

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So...

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

WILL: You mentioned getting your product out there how challenging it can be. So, what has been some other wins and some challenges that you've had as a first-time founder?

+ +

SIMON: So, my approach to things as a leader is I basically like to bring silliness and games to help motivate and energize the team. So, as a human, I have quite a lot of energy. I roll around with lots of energy. And I take loads of photos of what I'm doing, and I share those. So, we have a Friday wrap-up with the team, and so I'll often share a lot of the pictures of, you know, what I've been up to this week.

+ +

So, yeah, there's been some really fantastic moments launching a product. We launched our MVP in three months. So, we basically set off...I actually funded the first season of the business, a couple of software developers, a couple of early employees. I funded the first season. We hadn't raised money. And I just spoke to my wife, and I said, "Look, now's the time. I really want to do this."

+ +

You know, I've been saving up if you like, I had this, like, one day I'll do a startup fund. Some people would probably call that their long-term savings or like, you know, some...and I kind of called it my one day I'll do a startup fund. So, I'd been building up this fund because I knew that at some point, I'll probably go do this. The timing was way earlier than I thought. I thought I'd still do another four or five years in a career in a corporate role to try and get a few more notches in my belts to make fundraising easier, et cetera.

+ +

The timing came. The team was perfect. And everything just felt right, so we went for it. But yeah, we basically set out. We didn't know where we were going to get funding from. The market was in a real state, so this was middle of 2022. The Ukraine war had kicked in; valuations had dropped by 90% for a lot of tech companies. The post-COVID bubble had burst. It was hard.

+ +

So, we sat down, and we were like, okay, we could spend all of our runway trying to fundraise now, or we could crack on and try and build the first MVP. But we'd already done a lot of the market research, the user testing, early prototypes, et cetera. And that's a bit of a long story. But we had done that in the company that the founding team had worked at, and then we were actually a spin-out. So that happened.

+ +

And we were sitting here thinking, okay, you know, we could spend all of our runway fundraising, or we could just crack on and build a product as quick as we can in the next three months. And so, we had this really hard conversation where we descoped so much stuff. And we just figured out what's the core piece that will really show the value of what we're trying to build, that we'd give to a user, that we could give to an early customer that they could use and get value from? And so, we came up with that scope.

+ +

And we cracked on, and we built it. Within two and a half months, we had a working version. We played with it. Within three months, we kind of launched into this beta and got early users onto. So that was, you know, fantastic. So, we did that in the first three months, and then off the success of having an MVP, and just being able to show the product, and start getting some early user feedback, initial feedback was, you know, we took into account very quickly and improved.

+ +

And just having that, you know, you basically start building momentum. Every step is still really hard, but you do build momentum. So, we got this product. We launched it. We went to a couple of events, and we talked about that, and then we did some fundraising. And we landed some funding, so that was fantastic. And then, you know, and then we've just gone sort of step by step from there. So, it's really fantastic what we've been able to achieve so far.

+ +

The challenges there's been loads of them, especially when you're building a startup. It's really exciting. So, you can get people excited quite easily about the future potential. And you can kind of talk about what this can be. I've got a printed picture of a unicorn on my whiteboard in my office right here as a sort of a statement of, you know, where we're going.

+ +

It's really hard as a founder or a leader trying to persuade people to leave a stable job, take a pay cut, and come and work with you and give them some equity, which you hope will be worth a ton, and you kind of paint the picture. But also, you don't know how long you can keep them because you're on runway. You're on runway. You haven't got infinite cash if it's not a profitable business.

+ +

So, you know, there are some real challenges. And, as a founder, you go through ups and downs. Ben Horowitz talks about it in his great book, The Hard Things About Hard Things, as the struggle. I definitely understand that a lot more now because there is an up and down to this. You do build momentum, but you also...you're creating the momentum, you know, one hard push at a time. So that's that early customers come on. You kind of pitch the dream of what the product will do, and then it will fall over as soon as they touch it. But I absolutely love it.

+ +

What I love is the chance to create and how quickly you can move in the early days of a startup or a new product, where you don't have masses of technical debt. You don't have hundreds of customers. You don't have all this, you know, you don't have a massive team where everyone's got their point of view on what you should do. So, you can move really fast, and that's fantastic [inaudible 30:14] creative season. So yeah, lots of ups and downs, but it's really fun.

+ +

VICTORIA: That's so interesting and particularly interesting that you're trying to make something that's easier to use than Excel. So, I'm curious how you're testing to make sure that it's actually easy. And what might be...I'm sure there's some interesting feedback you got about that.

+ +

SIMON: Yeah, so we're making Blox easier than Excel. But it's got to be powerful enough to be able to handle the data and the modeling that you need for a business. If you're doing projections for multiple years if you've got lots of products or teams, then it can be complex, so it needs to be powerful enough to handle that. It needs to be flexible enough because you can take a template, but every business has got its own unique quirks. So, it needs to be flexible enough that it can be tailored easy for a unique business.

+ +

And then, crucially, and this is also important, it needs to be easy enough to use so that the person who understands the business can change the model to kind of suit their business. That's the bit that most of the other players, you know, the enterprise software that's available today, just that they haven't figured out how to make it easy enough so that a businessperson that, you know, doesn't have database experience, can't write SQL, not going to write Python, you know, doesn't do complex scripting or any of this stuff.

+ +

It's got to be easy enough that they can, you know, tailor, reflect the way that their business works, the way that they make money, the way that their cost structure works, so they can figure out what drives the business. And so, if they're projecting revenue, they can work out the costs associated.

+ +

So, one of our founding team is a UX designer, a really, really fantastic designer, very experienced. He's been in the game for 25 years since, way before it was called UX. And started doing graphic design, and then has done lots of branding and branding for some really fantastic, large companies, did lots of consulting. And then got into UX and how, you know, the art of wireframing and helping to make products easily usable. I call him my secret weapon. I've worked with some fantastic designers in the past, so, as a founder, I think I appreciate and understand the value of a really good design and a really good UX designer.

+ +

So, Mike, our UX designer, has just been fantastic at that. He's very good at wireframing and very good at testing. And he's not a finance planning expert. That's why I call him my secret weapon because, you know, I understand planning really well, but sometimes I understand it too well. When I describe what a user is trying to do or, you know, what I expect a screen will look like, I'm just probably subconsciously replacing or recreating something that I've seen or used before, whereas he's coming at it brand new. He's not worked in planning or data modeling, or many of these things. He's worked in lots of different businesses.

+ +

So, he comes at it with a mobile-first perspective. Normally, he's thinking about, okay, how could this be used by a busy leader on their phone and they're running around? And so, he's been really fantastic at helping to keep it simple and easy and to rethink and to create a product, which is just so different to what other tools in the space are doing. And that's some of the feedback we get. It looks so different. It works so different.

+ +

But yeah, the hard thing is that spreadsheets are the most sticky tool, I think. They're just so useful for, you know, for everything where you need to get a list of things. You just start throwing it into a spreadsheet, and then you can, you know, organize it and improve structure over time. But yeah, it's a really sticky tool. And we train people how to use spreadsheets from early days from school. My 12-year-old daughter she already has been taught how to use a spreadsheet in school.

+ +

So, what we're trying to do is create something which is easier. But there's also, you know, you want there to be some familiarity in there so that people will...to avoid some of the friction of the people who have it. No one really signs up to learn a new tool if they can avoid it. We're lazy. [laughs]

+ +

VICTORIA: It makes sense that design would be a big priority for your product because that was your intention from the beginning, right? Is to make something that's easy to use, so you prioritize that as an investment.

+ +

SIMON: That's right. That's absolutely right. Yeah.

+ +

VICTORIA: What's on the horizon? What are you the most excited about for Blox in the coming months?

+ +

SIMON: So, yeah, we've got some really exciting elements of our roadmap coming. So, yeah, really excited to see these things come to life. Like anyone working in building products, whether you're designing, doing product, sort of overseeing, or actually developing, it's so great to see these things come to life. You spend a long time thinking and chatting about them, imagining, ideating about how they could look.

+ +

The thing that I'm just most excited about is—and that's probably why I love product—is, you know, you're building a product, and then you can...then you're talking to somebody about how they would use this. Or before that, you're talking about their day-to-day right now and what their problems are, and how you could help them save time, save money, et cetera.

+ +

And so, you know, I absolutely love chatting to more and more different types of companies, leaders in different parts of the business. And, you know, especially in our space, it's mostly about, okay, how can I help? You know, how could we improve this planning process that we've got, whether it's, you know, planning for the cost of running a big project or trying to figure out how can I scale my business to reach my objectives? So, I just love chatting to lots of different leaders globally. So, I love going to events, chatting to people, fact-finding about how they run their business, how they think about finances, et cetera.

+ +

In terms of the product roadmap, we're working on some exciting new scenario capabilities, so you can easily look at different scenarios around a decision. So, you might be trying to decide, you know, should I be aggressive with my investments and hiring, or should I be pessimistic? Or is there a middle ground? So, we're adding, like, scenario capabilities where you can build out different versions of that, and then easily compare and contrast, and then decide which one to do.

+ +

We're working on some really...really enjoying working on some intelligent capabilities. So, again, in the search of making it really easy to use for a busy leader, for a busy businessperson, or a busy finance person, making it really easy to use. So, we've invested a lot in AI technology and been designing, developing POCs around how AI could help to onboard customers faster, how we could help to personalize models for businesses automagically.

+ +

So, as soon as we understand the website of a user, what sort of industry they're in, we can automagically personalize the template for them, add their own KPIs, like, industry-specific KPIs, into the model, and throw in benchmark data and all these things. So, we've got some fantastic AI capabilities coming through the pipe and some data integrations. As we get out more and more, we're connecting to different data sources. So, yeah, exciting times ahead for the roadmap.

+ +

And as we add more features, then we'll add different pricing tiers, you know, so we can try and offer a nice, affordable entry-level offering for Blox, but then we will, you know, as you get more and more different features, you'll pay at the appropriate level. So that's a little bit about what our future looks like.

+ +

WILL: That's neat some of the things you have coming up. You mentioned AI and how you're kind of embracing that. Can you expound on that? Like, kind of I know you said some data models automagically is going to do it. But, like, where can you see the benefit for a customer to use that? Because I know AI can be scary and stuff like that. But, like, just kind of taking the fear out of it and talking about how beneficial it can be.

+ +

SIMON: Yeah. So, there's lots of different places where AI can help. So, the typical model today for finance planning is you'd have a leader who's responsible for the business, and they're responsible for an advertising budget. You know, they just intuitively know, you know, where should I spend money, what's good return on my investment, what's, you know, what works.

+ +

But when it comes to actually trying to model that, so how to put that into a financial model or some other model that you can understand the relationships between these things, put in the KPIs, have the formulas, calculating things in the right way at the right level, what you often find is that the leader is not the system's expert. So, you'll often have, especially in bigger businesses, you've got this expert data analyst or FP&A finance planning person that will do the modeling.

+ +

So, we really believe that AI can be like a digital business coach to digitize that business advisory piece. So, the leader can be sitting down. They can be looking to try and improve some part of their business or understand some part of their spend and trying to work out, like, what would life look like if I increased my spend on this particular channel by X? And so, you know, we are looking at AI to help with lots of different areas around this. Initially, it's helping a new user to get onboarded with Blox. So, it's taking a template and helping to personalize it for their business.

+ +

What we basically try and do is fetch as much data about a new user and a new company as possible. So, if their team is on their website, then we'll pull in their team. If their products are listed on their website, we'll pull in a list of their products and try and throw that into the model and take out a lot of the friction that you have. As a user in the new system, you have to type in everything normally. If you're trying to model a business, you used to type it all in or copy and paste it from a spreadsheet.

+ +

So, we're looking at lots of options to help onboard new users. That has a good value add for us because we can increase the speed of adoption and help get users to value faster, which is great for us. And also, users are, you know, they're busy. They're impatient, and they want to understand what value they're going to get before they spend lots more of their time. So that's going to be useful for us and them.

+ +

And yeah, helping to interpret the data. So, they'll connect us to their source systems. We'll be able to interpret what's going on, help them to understand different options and scenarios about how things might play out in the future. Basically, AI will help us to draw our insights that we can present to the user, will help explain what the user is looking at when they're looking at the model, so we can summarize some of the key insights so that they can use that.

+ +

We're expecting to have all sorts of users, but we're really focusing on really busy leaders who may have a good understanding of spreadsheets and data, but they're just too busy, and so they don't have time. So, they want something which is quick and easy. Or leaders who don't have that expertise, so those are the ones that we really cater for. We try and keep it really simple and help guide them through the process, et cetera. So that's where AI is going to be, like, that digital business AI...We kind of kind of talk about this AI business coach concept.

+ +

And, over time, we'll build up more and more elements to that coach capability. We call him Anton in our team when we talk. We'll add more and more capabilities to him. But we've built a number of different POCs. And we've launched a couple of those with some customers. We've been out to events and showing off these new capabilities to basically test them out, understand what's working, what's not. What more do we need to think about to productionize this proof of concept? So that's, yeah, it's a very exciting time to be working on those things.

+ +

VICTORIA: I love hearing about that. That's super interesting to see where it's going to go. So, my last question for you today is, is there anything else that you would like to promote?

+ +

SIMON: I think I would just say, yeah, if you're a leader running a business or maybe it's a service business, and you're trying to think about, you know, when hiring business planning, financial planning, anything like that, then I'd love for you to come over to Blox, and you can jump straight into the product from our website. You can sign up.

+ +

I absolutely love chatting to people about their businesses and what they're trying to do with their finances. So, if you want to do that, you can sign up. You can chat to us. I actually take a lot of time to respond to people in there, so yeah, if you want to do that. Or, if you can, also find me on LinkedIn. You can search me there. Just strike up a conversation and say, "Hey, Simon, I'd love to chat about financial roadmapping or finance planning."

+ +

Yeah, I absolutely just love to speak to different leaders that work right across the business in different roles and see how we can help them to build a business that really unlock the potential that they have in their business through a great understanding of finances. So, yeah, if I can be of help, I would love that.

+ +

VICTORIA: Wonderful. And we'll have all those links in the show notes so our audience can go and take a look.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Simon Ritchie.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Kp1l6SU9 + + ]]> + + Will Larry + Victoria Guido + Simon Ritchie + + + 485: Pointz with Maggie Bachenberg and Trisha Ballakur + https://podcast.thoughtbot.com/485 + fbeccb0c-e0f7-46e8-a01e-a302462c735e + Thu, 27 Jul 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Maggie Bachenberg, CEO, and Trisha Ballakur, CTO, are the co-founders of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities. + +Victoria talks to Maggie and Trisha about their cycling backgrounds, how they met and became co-founders, and what they feel is the differentiator for their app versus what was/is already on the market for biking-related apps. + 38:12 + no + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +__ +Maggie Bachenberg, CEO, and Trisha Ballakur, CTO, are the co-founders of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities. +Victoria talks to Maggie and Trisha about their cycling backgrounds, how they met and became co-founders, and what they feel is the differentiator for their app versus what was/is already on the market for biking-related apps. +Pointz (https://www.bikepointz.com/) +Follow Pointz (https://www.instagram.com/bikepointz/) on Instagram (https://www.instagram.com/bikepointz/), Facebook (https://www.facebook.com/bikepointz/), LinkedIn (https://www.linkedin.com/company/bikepointz/), or TikTok (https://www.tiktok.com/@bikepointz) +Follow Maggie Bachenberg on LinkedIn (https://www.linkedin.com/in/maggiebachenberg/). +Follow Trisha Ballakur on LinkedIn (https://www.linkedin.com/in/trisha-ballakur-070138187/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. With me today is Maggie Bachenberg, CEO and Co-Founder of Pointz, and Trisha Ballakur, CTO and Co-Founder of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities. +Just to get us started here, are you both cyclists? And if so, where do you do that at? What's your city? Where do you bike around? +MAGGIE: Yeah, we both bike. So I live in Providence, Rhode Island, along with Trisha, and use my bike primarily as a transportation device. So I'm riding around from my house to work, to get groceries, to my friend's house, kind of all different types of purposes. +TRISHA: Yeah, and I grew up biking but kind of stopped after age, like, six or seven. And it was only when I got to college at Brown, where I met Maggie, that I got back into it and felt more confident to get back on the bike. And that was completely actually because of Pointz. +VICTORIA: Oh, that's nice. Yeah, speaking of confidence, I am not confident on a bicycle. I actually only learned after college. [laughs] And there's a video out there of my college friends helping me learn how to ride a bike. It's very cute. But still not my expertise. So I'm excited to learn more about it and learn about how Pointz could give you that confidence. So, whoever who'd like to start, why don't you tell me about what caused you to want to create Pointz? +MAGGIE: Pointz was originally kind of my idea. And I got into biking in 2017 when I did a long-distance bike trip. I biked from Virginia to California. And it was my first time doing long-distance cycling, and I just kind of fell in love with it. +But I realized that when I was riding, it was pretty scary to navigate cities in particular. And so, a lot of locals would redirect me onto different routes that were safer. And I was confused why this wasn't captured in a mapping app already. And so, that's kind of where the idea was seeded. But I didn't start working on it until I got to college and met Trisha. +VICTORIA: Great. So you got to college, and you saw that there was a need to have easier access to biking and biking information in an area, right? +MAGGIE: Yeah, exactly. +VICTORIA: Very cool. What was that initial process like? It was just the two of you, and you started building stuff? How did you really get the traction going early on? +MAGGIE: It started with doing some customer discovery interviews with local cyclists. And so we interviewed over 100 initially and just asked kind of what their biggest barrier was to start riding. And we kept hearing this recurring theme of people not feeling safe enough to go on different routes. +And so we brainstormed a bunch of different ideas in a class that Trisha and I were in together. But we ended up landing on the one that we're working on today, which is, like, you know, the rating system, and then also putting the rating system of bike friendliness into a routing algorithm where people could actually find routes. +VICTORIA: That's very cool. And was there anything that really surprised you in that customer discovery process? +MAGGIE: Just maybe the consistency around people's fear and, like, I guess, being nervous on a bike because we were interviewing people of all types of backgrounds and experiences. And even people that were more experienced had this fear of getting hit by a car because of lack of infrastructure and that sort of thing. +TRISHA: Doing customer discovery and chatting with so many different types of riders...and we call them riders, bike riders, rather than cyclists for the distinction that, you know, in the bike riding community, there's a lot of very avid fitness-geared cyclists, maybe who want to go on their bikes to burn calories and challenge themselves. +A lot of people they would call themselves someone who rides a bike. And it's to those types of people where safety is really critical, especially in allowing new people to go and try to ride a bike for the first time or the first time in many years. And so, that's something else that we noticed from those customer discovery interviews is identifying the different types of riders. +VICTORIA: Thank you. That clears it up for me because I never know to call someone a cyclist or a rider, but it makes sense that cyclist is more, like, the athletic pursuit versus riding and, you know, just trying to get about your day. [laughs] And it also makes me feel better that even people who are really experienced riders have fear of being unsafe or getting hit by a car because that's certainly what I'm thinking about when I'm [laughs] venturing out there. So, what was your initial build like for the app solving this problem? +TRISHA: Initially, we had a couple of different Brown University interns or students working on it together one summer and myself included. And that evolved to me and this one other student who was working with us figuring out how to transition the app from, like, an iOS Swift native app to React Native so it could be cross-platform. And we had to teach ourselves React Native for that. +So our intern at the time he had done an internship during the summer at this one startup where they taught him React Native. So he had done a couple of projects there. And I had a little bit of experience writing in JavaScript but really not as much as him. And so, together, we worked on coding the app from what we had in iOS in Swift, which was pretty limiting. But, at the time, it wasn't very much. +But we were able to replicate that in React Native during; I think it was my junior...Maggie in my junior winter break. That became the start of our MVP, which had many, many more iterations to get all the features in and was a little bit slow to build until when we released it out, which was our senior year in about March or so. +VICTORIA: So that's really exciting. So, like, how long did it take you to really get to that initial MVP with the team that you have? +TRISHA: It took quite a bit longer than expected, as with all sorts of technology when you're building it for the first time. So what was important to us throughout the process was making sure that all the features we put out there were really well tested, and were useful, and were actually solving the problem of providing safer routing. +And to get to that stage, at first, we, you know, we had an app in Swift. Then we wanted to make it cross-platformed, and we needed to have the routing algorithm actually take those different weights, the different bike friendliness ratings of the roads into account. And that took a lot of researching and talking to mentors. So there were quite a few really hard challenges to get to the MVP, which is why it spanned about a year to get to that point. +But throughout it all, we worked with other students at Brown. Then we pulled in some front-end contractors from online, like contractor sites, who were awesome. And we were just focused on being really scrappy to get it out in March of 2022. +VICTORIA: That's great. And maybe it felt like a long time, but I feel like a year for a really solid MVP is pretty good, [laughs] especially when you have those safety concerns, and the quality of your data, and what you're giving out is super important. So now you've got the MVP, and I believe you just raised your round of seed funding last year. What was that process like for you? +MAGGIE: Yes, so the round of funding that we did, we raised the first initial amount actually going into our senior year, and that was from a firm called Rogue Venture Partners. And we also got a little bit of it from their Women's Fund. And, yeah, that was the kind of piece of funding that got us started and allowed us to really, you know, add additional resources to the product to get it out there, at least the MVP. And then, after that, we got a little bit more funding from them. +And then we raised money from Techstars as well because we got into their accelerator at The Roux Institute. That's kind of in association with Northeastern, and that was out of Portland, Maine. I guess it wasn't really necessarily, like, a cohesive round. It was, like, a couple of different checks that all kind of went into, like, our early funding for Pointz. +And I would say it was very much so based on, you know, our relationship that we had with our initial venture firm that were working with Rogue. They actually mentored us for quite a few months before they invested in us. So they started mentoring us our junior year when we were in school. And then we got the deal together September of 2021. +VICTORIA: That's awesome. Well, congratulations. And I'm glad you were able to find the right partnerships, and mentors, and funding that you needed. What did you find was really the differentiator for your app versus what was already on the market for biking-related apps? +MAGGIE: There are a couple of different types of competitors, so there are the biking-related apps that you just mentioned, and then there are the general kind of use case apps like Google Maps or Apple Maps. And so, for the bike-related apps, the main thing that's different about Pointz is that we're more focused on, like, bike riders in general, so people that are riding around for transportation and recreation, not so much the cyclist type of a person that Trisha described earlier. +So, you know, a lot of our features are geared towards people that are getting around the city or maybe are exploring a city or a neighborhood. It doesn't necessarily have to be a city, but that's kind of the focus. Whereas for other cycling-specific apps, like Komoot or Ride with GPS, it's focused a lot on, like, the fitness side of things and the recreation fitness side of riders. And so, at least the Ride with GPS and a few other of, like, the technologies that are available to more hardcore cyclists tend to have a more sharp learning curve. And ours was built more as, like, a general use case in navigating and exploring. +VICTORIA: That makes sense. So it's more for people like me who are trying to go the most scenic [laughs] or the flattest and the safest way, not necessarily the fastest or the more fitness-focused aspect of cycling and biking. +MAGGIE: Yeah, exactly. And, you know, we actually built this for people like us. Granted, I did do that long-distance bike trip. But, generally, I don't consider myself that hardcore of a rider, I mean, in my daily life. So it's for people who don't really identify as a cyclist and are more just, like, riding their bike around and, honestly, for people who are new to riding in general. +Because a lot of our riders have recently gotten into biking or have recently moved to a new area, and so, they're just trying to figure out, you know, where are the good places to ride? Where do I feel safe? And, you know, how can I get more comfortable on my bike? +VICTORIA: I'm loving this idea because I have a bike that's been sitting in my patio for over a year. [laughs] I haven't used...my partner is like, "Can we get rid of it? Because you don't use it." But I'm like, "I will. I will use it." I know my neighborhood problem is that there are giant hills if we leave our street here. So getting out is fine. But getting back in [laughs], it's like you need an electric bike. So that's very exciting. +So, tell me more about now that you've graduated and you're taking this up full time; what does the future look like? What's on your horizon? +MAGGIE: I mean, we've been working a lot with one of our advisors on, you know, getting to the point where people really love the product, and that's been kind of happening over the last year. We met Anuj Adhiya from Lenny's Newsletter. We've been working with him to really hone in on what the thing is that people really love about Pointz and make that experience better. And then also figure out what exactly the persona is so we can target them eventually with marketing, which is kind of the stage that we're at right now. +So we were seeing our retention curves really evening out in especially a couple of cities that we're targeting. And so, this summer, we're focusing on getting our user base up in Los Angeles and then trying to figure out how, like, a playbook for scaling up a user base in a specific geography. Right now, a lot of our users are distributed throughout the United States. And there are clusters, but there's not, like, a huge spike in one city. And so, that's what we're working on right now is figuring out how to get a geographic kind of density to happen. +VICTORIA: That makes sense. And it sounded like the app also uses a lot of user-generated data for safety ratings and things like that. Am I getting that accurately? +TRISHA: Yep, that's correct. And what we do is we have a bunch of different layers of our data that we pull from. We have a base layer of data that comes from OpenStreetMap, and then we build on top of that. We rate all roads on a one through five bike friendliness scale. And building on top of that, we pull from city-specific data sets from cities, and towns, and municipalities. And then, we layer on the crowdsourcing similar to how Waze does at the top. +VICTORIA: Got it. So taking advantage of that open data, the open city data, and what other data the city is putting out there. Are you finding that you're using whether or not a city has open data to inform if you're going to expand into that location? +MAGGIE: Kind of as a focus point. So, the way it works right now is Pointz is available actually anywhere in the U.S. So; it doesn't matter if you're in a city or a rural area, you can use Pointz. And you can use it for routing and navigation and all the features that are available. However, we only have visualized the ratings in all 350 or so urban areas in the U.S., and so those are all visualized, but not all of them have the supplemental city-data. +And so, the way we decide when we pull in city data is based on gaps in, like, the base layer. So, if we're seeing that there are a lot of accuracy issues in a specific city, we'll go, and we'll look and see if there's a more accurate map that the city has put out or that an advocacy group has put out. And so, we've done this recently in Chicago, Minneapolis, Portland, Oregon, just to supplement the base layer of data, and it has helped a lot in terms of accuracy. And users or our riders really like it. +VICTORIA: That's great. And what is your current level of usage in the app? How well have you been adopted? +MAGGIE: Are you talking in terms of, like, user numbers or just, like, our engagement levels? +VICTORIA: Yeah, whatever you're using to measure your level of engagement or number of users on the app. Like, what are your stats looking like? +MAGGIE: Yeah, so, we use...we have our overall signups. And then we have a subcategory of, like, active and engaged users. And so, for our overall signups, we're at just over 9,000 total signups since we launched the MVP, and we haven't marketed it at all kind of until right now, where we're trying to push it out in LA a bit more. +And then, in terms of our engaged cohort, I'd have to pull up the exact number. But last I checked, it was around 1,800 monthly active users. We kind of look at that cohort, and then we break it down into, you know, who's even more engaged in that? Who's coming back every week, every day? +Mid-Roll Ad: +VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? +RICHARD: Hi, Victoria. +VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? +RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. +And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along. +And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. +VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? +RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. +The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. +And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. +VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken. +RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. +VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. +RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. +And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. +VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So... +[laughter] +RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. +VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... +RICHARD: [chuckles] Absolutely. +VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. +RICHARD: Yeah, it was a pleasure. Thank you. +VICTORIA: I'm wondering if you have any incentives built into the app for users who are, like, contributing data back, or maybe they're writing every single day. Are there any little challenges or achievements that you could unlock within the app right now? +MAGGIE: We do have some gamification, yes. And so, the way that people can earn points on the app...we call them points with a Z because of the name. The way that they can earn those points are a couple of ways. So, one is through riding their bike and using Pointz as a navigation tool or as a tool to record their ride. And so, for that, you get one point for every mile. +And then the second way is by contributing to the map, so either crowdsourcing an amenity like a bike parking that isn't on the map already or by adding information about a hazard that might be on the map, like, for example, a car parked in the bike lane. And for each of those, you know, you get one point. And so, yeah, we have that gamification system built out and a couple of...like, we have a leaderboard. And then, also, we have, like, a way for you to kind of go up in your avatar on the app. +But besides that, we do monthly contests. And so, this past month, we partnered up with a company called Po Campo, which makes stylish bike bags that can be taken off your bike and then worn as, like, a purse or a handbag. And so, they sponsored the prize, which is one of their bags, and whoever kind of gave the highest quality and quantity of crowdsourcing reviews and miles ridden they're the winner of the contest for this month of June. +VICTORIA: That's very cool. I love to see that and hear about what strategies people have for engaging with their users within the app. I'm curious to go back to, you know when you two first met, how did you know that you were going to be good partners to work on this project together? +TRISHA: One of the ways that we knew that was because we had first been introduced to each other from our mutual friend who is a close friend of both of ours, and she had been telling the other person about each other. And it was one day where we just met up, and we really clicked. +But, at that point, Maggie was looking for someone who could work on the mobile development, and I didn't have any experience with that. However, I joined a club, which Maggie was leading, which was called The Women's Entrepreneurship Group. And we got a chance to work together and plan out many events, including a large conference right before COVID hit. +Like, we saw how we'd worked together. We really enjoyed it. And we had very similar aspirations and motivations towards entrepreneurship. When I had the chance to basically join what Maggie was already working on with Pointz in the summer of 2020, I knew that that was going to be a great opportunity. And we decided to become co-founders by the end of the summer. +VICTORIA: That's very cool. And I know how important it is to have the right team together to work on a project like this and to start something up from scratch. So, were there other big turning points? And you mentioned COVID, so I'm curious how that affected the growth and progress of this effort. +MAGGIE: Yeah, to be honest, in the heart of COVID, like 2020, we weren't really built yet. So, it didn't quite affect us a whole lot, just because the product didn't get launched until the spring of 2020 to actually, you know, kind of publicly. But there were a couple of other turning points in our company, one of them was Techstars and kind of the progress we made during Techstars. +We joined the accelerator, and we were having a bit of a hard time getting tech kind of pushed out really quickly. It was taking us a long time to build the features. And so, Trisha and I kind of evaluated why that was happening. And we came up with a process that worked a lot better, which we still use today. And speaking of team, we got a couple of really awesome teammates that made a huge difference on how quickly we could turn around features and bug fixes. And so, that was a really big turning point because we were able to iterate much more quickly and get feedback from our riders a lot faster. So that happened November, December of last year, of 2022. +The other big turning point, I would say, is the slider that we released in March of this past year of 2023. And so we were having a hard time retaining users and getting them to really like the routing because people who bike tend to be very opinionated. And if the route isn't exactly kind of how they wanted it, they would be upset. And so, we'd fix it for one group of users, and then we would upset another group that didn't want that, you know, added to the routing. +What we ended up doing was releasing this safety slider, which has the fastest routes on the left side of the slider and then the safest or the longest routes on the right side of the slider. And that really helped people get a wide variety of routes that fit their use case. And it's helped a ton with retention. And also, the feedback we were getting from users really changed from, like, really honing in on a very specific issue with routes that they were getting to general feedback about how we could enhance the app and keep people coming back more consistently. +TRISHA: I just want to emphasize again that, yeah, the team is really critical. And, like, on our team, we have really awesome people who are 10xers and just great. Also, have someone who worked at MapQuest and has...I think our combined mapping experience is around 20-plus years. So it's really awesome to have that sort of a team together. +VICTORIA: Yes. And, you know, talking about it now on the podcast, in retrospect, I'm sure it all seems like it came together, and it was kismet, and everything just worked. But was that how it really felt? Or were there moments where you doubted it and thought, maybe this isn't going to come together? +MAGGIE: Yeah, definitely. There were moments of that feeling. One thing that gave us a lot of confidence was getting to the point where we felt like we could really iterate quickly and release features at a consistent and predictable cadence. So that gave us confidence that you know, there is a process for this, and there's a process of gathering user feedback and rider feedback, and then translating that into features, or bug fixes, or UI fixes. I think that gave me a lot of confidence that we could solve it. +But, of course, it always takes a lot longer than you expect. And our advisor, Anuj, always says that 80% of what you're going to do won't work and 20% of it will. And it's all about how quickly you can iterate and figure out what works. And sometimes you get lucky, and it happens quicker. Or maybe you have unique insight into the problem, and you can guess, and it works out quicker. But I don't know; I definitely think it's been a learning process for everyone on our team. +VICTORIA: That's great advice. And now that you've got your velocity up and you have your confidence, what's on the horizon? Are there new features that you all are working on that you're excited about? +TRISHA: Yeah, so we're really excited about leaning into the whole generative AI trends that are happening, especially with ChatGPT and others. One thing that we've been hearing from most of our riders, people who use Pointz, is that using the app to create routes, which will allow them to explore new places, go to a new coffee shop that they've been hoping to go to but just don't know how to actually get there is critical. And most of our riders on Pointz are people who are new to a city. Maybe they've only lived there for a max of one year or less. So, exploring the area around them is really important to them, and that's why they use Pointz. +And so, leaning into that, we're going to be releasing, in the next couple of weeks, a new explore feature where someone can go and, you know, describe to Pointz what type of route or...not even route, what type of things they want to see in a city, and Pointz will come up with that. It'll learn their preferences and continue to suggest really awesome places to get to, which they can do car-free, basically, through bikes, because they can be safe and, you know, they can rely on this app to get them through the city safely. +VICTORIA: That's really exciting. And I'm excited to try it out myself [laughs] once you have that feature launched. Maybe you can tell me how that feature plays into...or what your success really looks like for Pointz in the next six months. +MAGGIE: Yeah, so I think that feature is something that will be, I mean, of course, we got to test it, but I think that it will help people kind of use Pointz as an exploration tool more effectively. People are already using it for that, but it's not specifically built for exploration. Right now, it's built more for, I guess, routing to, you know, new places but not specifically, like, oh, let's go on a route that takes me through all these tourist destinations in the city I'm visiting. But this new feature will allow people to use it for that more. +And I think, overall, you know, our mission at Pointz is to help people feel comfortable riding bikes so that they can drive less and feel like they can get around in a sustainable fashion, rather than having to rely on their car so often. And this feature is tied to that in the sense of, like, people can use it as a tool to help them, you know, find the safe route or a route they're comfortable with, and then use it to explore an area but maybe a bit more geared towards, like, tourists or, you know, more recreational-type use cases. +VICTORIA: That's very cool. Thank you so much for sharing that. And what is your biggest challenge to achieving that success? +MAGGIE: I think biking is a first step in that process of helping people feel like they can be more car-light or car-free, you know, use their car less. There are obviously a ton of other factors that go into whether or not you're driving, or you're taking a bike, or you're taking public transportation. And, you know, our next steps after we have really nailed this product are to explore those opportunities and build tools that help people choose alternative transportation more often. That's what we're excited about going into the future. +You know, there's a ton happening in cities all across the U.S., not only for biking but also investments in transit, infrastructure, and whatnot. So, you know, young people and people of all ages...I think a lot of people feel comfortable and that they don't want to be sitting in traffic a whole lot [laughs] because that's not fun for anyone. And, you know, traffic and congestion is always frustrating. So, as much as we can reduce that, I think that's the mission of our company. And, of course, it takes a ton of scale. But it's a big goal, but we're going after it. +VICTORIA: That's great. You know, I heard about a town in the U.S. that actually had banned cars and was pedestrians only for the whole town. It's like, what a great idea. [laughs] But I love it. I love that you're working on it. And I wonder now, you know, you're a couple of years into it. If you could go back in time and give advice to yourself when you first started this project, what advice would you give yourself? +MAGGIE: For me, I would say to get a minimal viable product more minimal, [chuckles] so reduce it to, like, a single feature, get it out quickly, and start getting feedback more quickly from, like, a very practical, you know, piece of advice. +And then, like, an overall piece of advice would be just to be more confident earlier on. It took a long time for me to gain the confidence of, like, being a thought leader in the space. And, you know, I felt like I was young, so there were all these people that knew more than me. But I think everyone has a really unique perspective, and if you really lean into that and share that with the world, it can inspire a lot of people. And you just have to be confident enough to do that. +TRISHA: Yeah, I definitely second what Maggie just said. I think also from the tech perspective, if you're someone who is maybe more inexperienced, like, I just got out of college and did this, and I have never worked a full-time job before anywhere except this. And so I think there was a lot of doubt that I had of being able to lead the technical side because I didn't have 20 years experience working somewhere. +But, actually, at the end of the day, that doesn't matter. It just matters that you're able to be in touch with what it takes to build certain features and talk to the users, or your riders, or whoever because they're the ones who are going to be dictating whether this is a success or not based on what you build. It's really not good if you're building and wasting a lot of resources and time on features which nobody wants or nobody uses. And so, that's been core to why I think I've gotten a lot of confidence in being able to be, like, the tech leader in this app and in this space. +VICTORIA: Yeah, I'm curious to hear more about that. You touched on this really being your first full-time job. So, how do you build your personal brand as an executive leader in this company that you're building? +TRISHA: For anyone who does startups, they'll know that it's a lot of figuring it out as you go, and things that you're taught in school don't necessarily translate well to the startup world because, like, I did, like, a Bachelor of Science in Computer Science. I did operating systems. I built a whole bunch of random stuff in school, and I studied for hours and hours. +Of a lot of that, the most important thing, which actually translates to working in my field, is the perseverance to, like, keep going and working really hard. Otherwise, none of that stuff which I learned honestly translates. I had to learn everything myself with regards to building mobile apps. And I think the foundations were really critical from school but not really much of the hours of studying. I don't think that that's necessary, but I think it's necessary to build that sort of perseverance mindset. +VICTORIA: That makes sense sort of to reflect that back a little bit, just having the perseverance to keep pushing, and keep learning, and keep understanding what is it going to take to build the features that you want? And that's really the core of being a CTO, right? +TRISHA: Exactly. Exactly. Yeah. +VICTORIA: And, Maggie, I wonder about you as well, like, what resources are you drawing on to really perform as a CEO for this company? +TRISHA: One thing that I read a lot is...it's more product-focused, actually, but it's product and growth-focused. It's Lenny's Newsletter, which I mentioned earlier. I use that as a resource a lot. I listen to their podcasts, and I read their articles. +And then secondly, I interact a lot with other CEOs and founders because I think that's one of the best ways you can learn is from other people who are in it right now, maybe are a couple of steps ahead of you, or who have done it before. And so, I lean into that quite a bit. And just, you know, try to get advice from people, take what makes sense, and apply it to what we're working on. +VICTORIA: That sounds great, yeah. I can relate to that; just building your personal network with people who are in similar roles helps you stay in touch and understand what other challenges people are facing and what you might face someday, right? [laughs] That's really cool. I love that you have all that set up. +And is there anything else that you all would like to promote today? +MAGGIE: I would just say to anybody who's interested in biking or maybe is, like, a beginner rider, we'd love to have you try out the app and then explore your area and give it a try one weekend when you have some time and see if you feel more confident, you know, given the routes that are on more green and protected roads. +VICTORIA: I'm really excited to be talking to you because I am that person. I need this app. [laughs] I'm excited to try it out. Thank you, Maggie and Trisha, for joining us today. [laughs] It was a really great conversation, and I'm excited to follow along and see what happens with Pointz in the coming years. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guests: Maggie Bachenberg and Trisha Ballakur. + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

__

+ +

Maggie Bachenberg, CEO, and Trisha Ballakur, CTO, are the co-founders of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities.

+ +

Victoria talks to Maggie and Trisha about their cycling backgrounds, how they met and became co-founders, and what they feel is the differentiator for their app versus what was/is already on the market for biking-related apps.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. With me today is Maggie Bachenberg, CEO and Co-Founder of Pointz, and Trisha Ballakur, CTO and Co-Founder of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities.

+ +

Just to get us started here, are you both cyclists? And if so, where do you do that at? What's your city? Where do you bike around?

+ +

MAGGIE: Yeah, we both bike. So I live in Providence, Rhode Island, along with Trisha, and use my bike primarily as a transportation device. So I'm riding around from my house to work, to get groceries, to my friend's house, kind of all different types of purposes.

+ +

TRISHA: Yeah, and I grew up biking but kind of stopped after age, like, six or seven. And it was only when I got to college at Brown, where I met Maggie, that I got back into it and felt more confident to get back on the bike. And that was completely actually because of Pointz.

+ +

VICTORIA: Oh, that's nice. Yeah, speaking of confidence, I am not confident on a bicycle. I actually only learned after college. [laughs] And there's a video out there of my college friends helping me learn how to ride a bike. It's very cute. But still not my expertise. So I'm excited to learn more about it and learn about how Pointz could give you that confidence. So, whoever who'd like to start, why don't you tell me about what caused you to want to create Pointz?

+ +

MAGGIE: Pointz was originally kind of my idea. And I got into biking in 2017 when I did a long-distance bike trip. I biked from Virginia to California. And it was my first time doing long-distance cycling, and I just kind of fell in love with it.

+ +

But I realized that when I was riding, it was pretty scary to navigate cities in particular. And so, a lot of locals would redirect me onto different routes that were safer. And I was confused why this wasn't captured in a mapping app already. And so, that's kind of where the idea was seeded. But I didn't start working on it until I got to college and met Trisha.

+ +

VICTORIA: Great. So you got to college, and you saw that there was a need to have easier access to biking and biking information in an area, right?

+ +

MAGGIE: Yeah, exactly.

+ +

VICTORIA: Very cool. What was that initial process like? It was just the two of you, and you started building stuff? How did you really get the traction going early on?

+ +

MAGGIE: It started with doing some customer discovery interviews with local cyclists. And so we interviewed over 100 initially and just asked kind of what their biggest barrier was to start riding. And we kept hearing this recurring theme of people not feeling safe enough to go on different routes.

+ +

And so we brainstormed a bunch of different ideas in a class that Trisha and I were in together. But we ended up landing on the one that we're working on today, which is, like, you know, the rating system, and then also putting the rating system of bike friendliness into a routing algorithm where people could actually find routes.

+ +

VICTORIA: That's very cool. And was there anything that really surprised you in that customer discovery process?

+ +

MAGGIE: Just maybe the consistency around people's fear and, like, I guess, being nervous on a bike because we were interviewing people of all types of backgrounds and experiences. And even people that were more experienced had this fear of getting hit by a car because of lack of infrastructure and that sort of thing.

+ +

TRISHA: Doing customer discovery and chatting with so many different types of riders...and we call them riders, bike riders, rather than cyclists for the distinction that, you know, in the bike riding community, there's a lot of very avid fitness-geared cyclists, maybe who want to go on their bikes to burn calories and challenge themselves.

+ +

A lot of people they would call themselves someone who rides a bike. And it's to those types of people where safety is really critical, especially in allowing new people to go and try to ride a bike for the first time or the first time in many years. And so, that's something else that we noticed from those customer discovery interviews is identifying the different types of riders.

+ +

VICTORIA: Thank you. That clears it up for me because I never know to call someone a cyclist or a rider, but it makes sense that cyclist is more, like, the athletic pursuit versus riding and, you know, just trying to get about your day. [laughs] And it also makes me feel better that even people who are really experienced riders have fear of being unsafe or getting hit by a car because that's certainly what I'm thinking about when I'm [laughs] venturing out there. So, what was your initial build like for the app solving this problem?

+ +

TRISHA: Initially, we had a couple of different Brown University interns or students working on it together one summer and myself included. And that evolved to me and this one other student who was working with us figuring out how to transition the app from, like, an iOS Swift native app to React Native so it could be cross-platform. And we had to teach ourselves React Native for that.

+ +

So our intern at the time he had done an internship during the summer at this one startup where they taught him React Native. So he had done a couple of projects there. And I had a little bit of experience writing in JavaScript but really not as much as him. And so, together, we worked on coding the app from what we had in iOS in Swift, which was pretty limiting. But, at the time, it wasn't very much.

+ +

But we were able to replicate that in React Native during; I think it was my junior...Maggie in my junior winter break. That became the start of our MVP, which had many, many more iterations to get all the features in and was a little bit slow to build until when we released it out, which was our senior year in about March or so.

+ +

VICTORIA: So that's really exciting. So, like, how long did it take you to really get to that initial MVP with the team that you have?

+ +

TRISHA: It took quite a bit longer than expected, as with all sorts of technology when you're building it for the first time. So what was important to us throughout the process was making sure that all the features we put out there were really well tested, and were useful, and were actually solving the problem of providing safer routing.

+ +

And to get to that stage, at first, we, you know, we had an app in Swift. Then we wanted to make it cross-platformed, and we needed to have the routing algorithm actually take those different weights, the different bike friendliness ratings of the roads into account. And that took a lot of researching and talking to mentors. So there were quite a few really hard challenges to get to the MVP, which is why it spanned about a year to get to that point.

+ +

But throughout it all, we worked with other students at Brown. Then we pulled in some front-end contractors from online, like contractor sites, who were awesome. And we were just focused on being really scrappy to get it out in March of 2022.

+ +

VICTORIA: That's great. And maybe it felt like a long time, but I feel like a year for a really solid MVP is pretty good, [laughs] especially when you have those safety concerns, and the quality of your data, and what you're giving out is super important. So now you've got the MVP, and I believe you just raised your round of seed funding last year. What was that process like for you?

+ +

MAGGIE: Yes, so the round of funding that we did, we raised the first initial amount actually going into our senior year, and that was from a firm called Rogue Venture Partners. And we also got a little bit of it from their Women's Fund. And, yeah, that was the kind of piece of funding that got us started and allowed us to really, you know, add additional resources to the product to get it out there, at least the MVP. And then, after that, we got a little bit more funding from them.

+ +

And then we raised money from Techstars as well because we got into their accelerator at The Roux Institute. That's kind of in association with Northeastern, and that was out of Portland, Maine. I guess it wasn't really necessarily, like, a cohesive round. It was, like, a couple of different checks that all kind of went into, like, our early funding for Pointz.

+ +

And I would say it was very much so based on, you know, our relationship that we had with our initial venture firm that were working with Rogue. They actually mentored us for quite a few months before they invested in us. So they started mentoring us our junior year when we were in school. And then we got the deal together September of 2021.

+ +

VICTORIA: That's awesome. Well, congratulations. And I'm glad you were able to find the right partnerships, and mentors, and funding that you needed. What did you find was really the differentiator for your app versus what was already on the market for biking-related apps?

+ +

MAGGIE: There are a couple of different types of competitors, so there are the biking-related apps that you just mentioned, and then there are the general kind of use case apps like Google Maps or Apple Maps. And so, for the bike-related apps, the main thing that's different about Pointz is that we're more focused on, like, bike riders in general, so people that are riding around for transportation and recreation, not so much the cyclist type of a person that Trisha described earlier.

+ +

So, you know, a lot of our features are geared towards people that are getting around the city or maybe are exploring a city or a neighborhood. It doesn't necessarily have to be a city, but that's kind of the focus. Whereas for other cycling-specific apps, like Komoot or Ride with GPS, it's focused a lot on, like, the fitness side of things and the recreation fitness side of riders. And so, at least the Ride with GPS and a few other of, like, the technologies that are available to more hardcore cyclists tend to have a more sharp learning curve. And ours was built more as, like, a general use case in navigating and exploring.

+ +

VICTORIA: That makes sense. So it's more for people like me who are trying to go the most scenic [laughs] or the flattest and the safest way, not necessarily the fastest or the more fitness-focused aspect of cycling and biking.

+ +

MAGGIE: Yeah, exactly. And, you know, we actually built this for people like us. Granted, I did do that long-distance bike trip. But, generally, I don't consider myself that hardcore of a rider, I mean, in my daily life. So it's for people who don't really identify as a cyclist and are more just, like, riding their bike around and, honestly, for people who are new to riding in general.

+ +

Because a lot of our riders have recently gotten into biking or have recently moved to a new area, and so, they're just trying to figure out, you know, where are the good places to ride? Where do I feel safe? And, you know, how can I get more comfortable on my bike?

+ +

VICTORIA: I'm loving this idea because I have a bike that's been sitting in my patio for over a year. [laughs] I haven't used...my partner is like, "Can we get rid of it? Because you don't use it." But I'm like, "I will. I will use it." I know my neighborhood problem is that there are giant hills if we leave our street here. So getting out is fine. But getting back in [laughs], it's like you need an electric bike. So that's very exciting.

+ +

So, tell me more about now that you've graduated and you're taking this up full time; what does the future look like? What's on your horizon?

+ +

MAGGIE: I mean, we've been working a lot with one of our advisors on, you know, getting to the point where people really love the product, and that's been kind of happening over the last year. We met Anuj Adhiya from Lenny's Newsletter. We've been working with him to really hone in on what the thing is that people really love about Pointz and make that experience better. And then also figure out what exactly the persona is so we can target them eventually with marketing, which is kind of the stage that we're at right now.

+ +

So we were seeing our retention curves really evening out in especially a couple of cities that we're targeting. And so, this summer, we're focusing on getting our user base up in Los Angeles and then trying to figure out how, like, a playbook for scaling up a user base in a specific geography. Right now, a lot of our users are distributed throughout the United States. And there are clusters, but there's not, like, a huge spike in one city. And so, that's what we're working on right now is figuring out how to get a geographic kind of density to happen.

+ +

VICTORIA: That makes sense. And it sounded like the app also uses a lot of user-generated data for safety ratings and things like that. Am I getting that accurately?

+ +

TRISHA: Yep, that's correct. And what we do is we have a bunch of different layers of our data that we pull from. We have a base layer of data that comes from OpenStreetMap, and then we build on top of that. We rate all roads on a one through five bike friendliness scale. And building on top of that, we pull from city-specific data sets from cities, and towns, and municipalities. And then, we layer on the crowdsourcing similar to how Waze does at the top.

+ +

VICTORIA: Got it. So taking advantage of that open data, the open city data, and what other data the city is putting out there. Are you finding that you're using whether or not a city has open data to inform if you're going to expand into that location?

+ +

MAGGIE: Kind of as a focus point. So, the way it works right now is Pointz is available actually anywhere in the U.S. So; it doesn't matter if you're in a city or a rural area, you can use Pointz. And you can use it for routing and navigation and all the features that are available. However, we only have visualized the ratings in all 350 or so urban areas in the U.S., and so those are all visualized, but not all of them have the supplemental city-data.

+ +

And so, the way we decide when we pull in city data is based on gaps in, like, the base layer. So, if we're seeing that there are a lot of accuracy issues in a specific city, we'll go, and we'll look and see if there's a more accurate map that the city has put out or that an advocacy group has put out. And so, we've done this recently in Chicago, Minneapolis, Portland, Oregon, just to supplement the base layer of data, and it has helped a lot in terms of accuracy. And users or our riders really like it.

+ +

VICTORIA: That's great. And what is your current level of usage in the app? How well have you been adopted?

+ +

MAGGIE: Are you talking in terms of, like, user numbers or just, like, our engagement levels?

+ +

VICTORIA: Yeah, whatever you're using to measure your level of engagement or number of users on the app. Like, what are your stats looking like?

+ +

MAGGIE: Yeah, so, we use...we have our overall signups. And then we have a subcategory of, like, active and engaged users. And so, for our overall signups, we're at just over 9,000 total signups since we launched the MVP, and we haven't marketed it at all kind of until right now, where we're trying to push it out in LA a bit more.

+ +

And then, in terms of our engaged cohort, I'd have to pull up the exact number. But last I checked, it was around 1,800 monthly active users. We kind of look at that cohort, and then we break it down into, you know, who's even more engaged in that? Who's coming back every week, every day?

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So...

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

VICTORIA: I'm wondering if you have any incentives built into the app for users who are, like, contributing data back, or maybe they're writing every single day. Are there any little challenges or achievements that you could unlock within the app right now?

+ +

MAGGIE: We do have some gamification, yes. And so, the way that people can earn points on the app...we call them points with a Z because of the name. The way that they can earn those points are a couple of ways. So, one is through riding their bike and using Pointz as a navigation tool or as a tool to record their ride. And so, for that, you get one point for every mile.

+ +

And then the second way is by contributing to the map, so either crowdsourcing an amenity like a bike parking that isn't on the map already or by adding information about a hazard that might be on the map, like, for example, a car parked in the bike lane. And for each of those, you know, you get one point. And so, yeah, we have that gamification system built out and a couple of...like, we have a leaderboard. And then, also, we have, like, a way for you to kind of go up in your avatar on the app.

+ +

But besides that, we do monthly contests. And so, this past month, we partnered up with a company called Po Campo, which makes stylish bike bags that can be taken off your bike and then worn as, like, a purse or a handbag. And so, they sponsored the prize, which is one of their bags, and whoever kind of gave the highest quality and quantity of crowdsourcing reviews and miles ridden they're the winner of the contest for this month of June.

+ +

VICTORIA: That's very cool. I love to see that and hear about what strategies people have for engaging with their users within the app. I'm curious to go back to, you know when you two first met, how did you know that you were going to be good partners to work on this project together?

+ +

TRISHA: One of the ways that we knew that was because we had first been introduced to each other from our mutual friend who is a close friend of both of ours, and she had been telling the other person about each other. And it was one day where we just met up, and we really clicked.

+ +

But, at that point, Maggie was looking for someone who could work on the mobile development, and I didn't have any experience with that. However, I joined a club, which Maggie was leading, which was called The Women's Entrepreneurship Group. And we got a chance to work together and plan out many events, including a large conference right before COVID hit.

+ +

Like, we saw how we'd worked together. We really enjoyed it. And we had very similar aspirations and motivations towards entrepreneurship. When I had the chance to basically join what Maggie was already working on with Pointz in the summer of 2020, I knew that that was going to be a great opportunity. And we decided to become co-founders by the end of the summer.

+ +

VICTORIA: That's very cool. And I know how important it is to have the right team together to work on a project like this and to start something up from scratch. So, were there other big turning points? And you mentioned COVID, so I'm curious how that affected the growth and progress of this effort.

+ +

MAGGIE: Yeah, to be honest, in the heart of COVID, like 2020, we weren't really built yet. So, it didn't quite affect us a whole lot, just because the product didn't get launched until the spring of 2020 to actually, you know, kind of publicly. But there were a couple of other turning points in our company, one of them was Techstars and kind of the progress we made during Techstars.

+ +

We joined the accelerator, and we were having a bit of a hard time getting tech kind of pushed out really quickly. It was taking us a long time to build the features. And so, Trisha and I kind of evaluated why that was happening. And we came up with a process that worked a lot better, which we still use today. And speaking of team, we got a couple of really awesome teammates that made a huge difference on how quickly we could turn around features and bug fixes. And so, that was a really big turning point because we were able to iterate much more quickly and get feedback from our riders a lot faster. So that happened November, December of last year, of 2022.

+ +

The other big turning point, I would say, is the slider that we released in March of this past year of 2023. And so we were having a hard time retaining users and getting them to really like the routing because people who bike tend to be very opinionated. And if the route isn't exactly kind of how they wanted it, they would be upset. And so, we'd fix it for one group of users, and then we would upset another group that didn't want that, you know, added to the routing.

+ +

What we ended up doing was releasing this safety slider, which has the fastest routes on the left side of the slider and then the safest or the longest routes on the right side of the slider. And that really helped people get a wide variety of routes that fit their use case. And it's helped a ton with retention. And also, the feedback we were getting from users really changed from, like, really honing in on a very specific issue with routes that they were getting to general feedback about how we could enhance the app and keep people coming back more consistently.

+ +

TRISHA: I just want to emphasize again that, yeah, the team is really critical. And, like, on our team, we have really awesome people who are 10xers and just great. Also, have someone who worked at MapQuest and has...I think our combined mapping experience is around 20-plus years. So it's really awesome to have that sort of a team together.

+ +

VICTORIA: Yes. And, you know, talking about it now on the podcast, in retrospect, I'm sure it all seems like it came together, and it was kismet, and everything just worked. But was that how it really felt? Or were there moments where you doubted it and thought, maybe this isn't going to come together?

+ +

MAGGIE: Yeah, definitely. There were moments of that feeling. One thing that gave us a lot of confidence was getting to the point where we felt like we could really iterate quickly and release features at a consistent and predictable cadence. So that gave us confidence that you know, there is a process for this, and there's a process of gathering user feedback and rider feedback, and then translating that into features, or bug fixes, or UI fixes. I think that gave me a lot of confidence that we could solve it.

+ +

But, of course, it always takes a lot longer than you expect. And our advisor, Anuj, always says that 80% of what you're going to do won't work and 20% of it will. And it's all about how quickly you can iterate and figure out what works. And sometimes you get lucky, and it happens quicker. Or maybe you have unique insight into the problem, and you can guess, and it works out quicker. But I don't know; I definitely think it's been a learning process for everyone on our team.

+ +

VICTORIA: That's great advice. And now that you've got your velocity up and you have your confidence, what's on the horizon? Are there new features that you all are working on that you're excited about?

+ +

TRISHA: Yeah, so we're really excited about leaning into the whole generative AI trends that are happening, especially with ChatGPT and others. One thing that we've been hearing from most of our riders, people who use Pointz, is that using the app to create routes, which will allow them to explore new places, go to a new coffee shop that they've been hoping to go to but just don't know how to actually get there is critical. And most of our riders on Pointz are people who are new to a city. Maybe they've only lived there for a max of one year or less. So, exploring the area around them is really important to them, and that's why they use Pointz.

+ +

And so, leaning into that, we're going to be releasing, in the next couple of weeks, a new explore feature where someone can go and, you know, describe to Pointz what type of route or...not even route, what type of things they want to see in a city, and Pointz will come up with that. It'll learn their preferences and continue to suggest really awesome places to get to, which they can do car-free, basically, through bikes, because they can be safe and, you know, they can rely on this app to get them through the city safely.

+ +

VICTORIA: That's really exciting. And I'm excited to try it out myself [laughs] once you have that feature launched. Maybe you can tell me how that feature plays into...or what your success really looks like for Pointz in the next six months.

+ +

MAGGIE: Yeah, so I think that feature is something that will be, I mean, of course, we got to test it, but I think that it will help people kind of use Pointz as an exploration tool more effectively. People are already using it for that, but it's not specifically built for exploration. Right now, it's built more for, I guess, routing to, you know, new places but not specifically, like, oh, let's go on a route that takes me through all these tourist destinations in the city I'm visiting. But this new feature will allow people to use it for that more.

+ +

And I think, overall, you know, our mission at Pointz is to help people feel comfortable riding bikes so that they can drive less and feel like they can get around in a sustainable fashion, rather than having to rely on their car so often. And this feature is tied to that in the sense of, like, people can use it as a tool to help them, you know, find the safe route or a route they're comfortable with, and then use it to explore an area but maybe a bit more geared towards, like, tourists or, you know, more recreational-type use cases.

+ +

VICTORIA: That's very cool. Thank you so much for sharing that. And what is your biggest challenge to achieving that success?

+ +

MAGGIE: I think biking is a first step in that process of helping people feel like they can be more car-light or car-free, you know, use their car less. There are obviously a ton of other factors that go into whether or not you're driving, or you're taking a bike, or you're taking public transportation. And, you know, our next steps after we have really nailed this product are to explore those opportunities and build tools that help people choose alternative transportation more often. That's what we're excited about going into the future.

+ +

You know, there's a ton happening in cities all across the U.S., not only for biking but also investments in transit, infrastructure, and whatnot. So, you know, young people and people of all ages...I think a lot of people feel comfortable and that they don't want to be sitting in traffic a whole lot [laughs] because that's not fun for anyone. And, you know, traffic and congestion is always frustrating. So, as much as we can reduce that, I think that's the mission of our company. And, of course, it takes a ton of scale. But it's a big goal, but we're going after it.

+ +

VICTORIA: That's great. You know, I heard about a town in the U.S. that actually had banned cars and was pedestrians only for the whole town. It's like, what a great idea. [laughs] But I love it. I love that you're working on it. And I wonder now, you know, you're a couple of years into it. If you could go back in time and give advice to yourself when you first started this project, what advice would you give yourself?

+ +

MAGGIE: For me, I would say to get a minimal viable product more minimal, [chuckles] so reduce it to, like, a single feature, get it out quickly, and start getting feedback more quickly from, like, a very practical, you know, piece of advice.

+ +

And then, like, an overall piece of advice would be just to be more confident earlier on. It took a long time for me to gain the confidence of, like, being a thought leader in the space. And, you know, I felt like I was young, so there were all these people that knew more than me. But I think everyone has a really unique perspective, and if you really lean into that and share that with the world, it can inspire a lot of people. And you just have to be confident enough to do that.

+ +

TRISHA: Yeah, I definitely second what Maggie just said. I think also from the tech perspective, if you're someone who is maybe more inexperienced, like, I just got out of college and did this, and I have never worked a full-time job before anywhere except this. And so I think there was a lot of doubt that I had of being able to lead the technical side because I didn't have 20 years experience working somewhere.

+ +

But, actually, at the end of the day, that doesn't matter. It just matters that you're able to be in touch with what it takes to build certain features and talk to the users, or your riders, or whoever because they're the ones who are going to be dictating whether this is a success or not based on what you build. It's really not good if you're building and wasting a lot of resources and time on features which nobody wants or nobody uses. And so, that's been core to why I think I've gotten a lot of confidence in being able to be, like, the tech leader in this app and in this space.

+ +

VICTORIA: Yeah, I'm curious to hear more about that. You touched on this really being your first full-time job. So, how do you build your personal brand as an executive leader in this company that you're building?

+ +

TRISHA: For anyone who does startups, they'll know that it's a lot of figuring it out as you go, and things that you're taught in school don't necessarily translate well to the startup world because, like, I did, like, a Bachelor of Science in Computer Science. I did operating systems. I built a whole bunch of random stuff in school, and I studied for hours and hours.

+ +

Of a lot of that, the most important thing, which actually translates to working in my field, is the perseverance to, like, keep going and working really hard. Otherwise, none of that stuff which I learned honestly translates. I had to learn everything myself with regards to building mobile apps. And I think the foundations were really critical from school but not really much of the hours of studying. I don't think that that's necessary, but I think it's necessary to build that sort of perseverance mindset.

+ +

VICTORIA: That makes sense sort of to reflect that back a little bit, just having the perseverance to keep pushing, and keep learning, and keep understanding what is it going to take to build the features that you want? And that's really the core of being a CTO, right?

+ +

TRISHA: Exactly. Exactly. Yeah.

+ +

VICTORIA: And, Maggie, I wonder about you as well, like, what resources are you drawing on to really perform as a CEO for this company?

+ +

TRISHA: One thing that I read a lot is...it's more product-focused, actually, but it's product and growth-focused. It's Lenny's Newsletter, which I mentioned earlier. I use that as a resource a lot. I listen to their podcasts, and I read their articles.

+ +

And then secondly, I interact a lot with other CEOs and founders because I think that's one of the best ways you can learn is from other people who are in it right now, maybe are a couple of steps ahead of you, or who have done it before. And so, I lean into that quite a bit. And just, you know, try to get advice from people, take what makes sense, and apply it to what we're working on.

+ +

VICTORIA: That sounds great, yeah. I can relate to that; just building your personal network with people who are in similar roles helps you stay in touch and understand what other challenges people are facing and what you might face someday, right? [laughs] That's really cool. I love that you have all that set up.

+ +

And is there anything else that you all would like to promote today?

+ +

MAGGIE: I would just say to anybody who's interested in biking or maybe is, like, a beginner rider, we'd love to have you try out the app and then explore your area and give it a try one weekend when you have some time and see if you feel more confident, you know, given the routes that are on more green and protected roads.

+ +

VICTORIA: I'm really excited to be talking to you because I am that person. I need this app. [laughs] I'm excited to try it out. Thank you, Maggie and Trisha, for joining us today. [laughs] It was a really great conversation, and I'm excited to follow along and see what happens with Pointz in the coming years.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Maggie Bachenberg and Trisha Ballakur.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

__

+ +

Maggie Bachenberg, CEO, and Trisha Ballakur, CTO, are the co-founders of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities.

+ +

Victoria talks to Maggie and Trisha about their cycling backgrounds, how they met and became co-founders, and what they feel is the differentiator for their app versus what was/is already on the market for biking-related apps.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. With me today is Maggie Bachenberg, CEO and Co-Founder of Pointz, and Trisha Ballakur, CTO and Co-Founder of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities.

+ +

Just to get us started here, are you both cyclists? And if so, where do you do that at? What's your city? Where do you bike around?

+ +

MAGGIE: Yeah, we both bike. So I live in Providence, Rhode Island, along with Trisha, and use my bike primarily as a transportation device. So I'm riding around from my house to work, to get groceries, to my friend's house, kind of all different types of purposes.

+ +

TRISHA: Yeah, and I grew up biking but kind of stopped after age, like, six or seven. And it was only when I got to college at Brown, where I met Maggie, that I got back into it and felt more confident to get back on the bike. And that was completely actually because of Pointz.

+ +

VICTORIA: Oh, that's nice. Yeah, speaking of confidence, I am not confident on a bicycle. I actually only learned after college. [laughs] And there's a video out there of my college friends helping me learn how to ride a bike. It's very cute. But still not my expertise. So I'm excited to learn more about it and learn about how Pointz could give you that confidence. So, whoever who'd like to start, why don't you tell me about what caused you to want to create Pointz?

+ +

MAGGIE: Pointz was originally kind of my idea. And I got into biking in 2017 when I did a long-distance bike trip. I biked from Virginia to California. And it was my first time doing long-distance cycling, and I just kind of fell in love with it.

+ +

But I realized that when I was riding, it was pretty scary to navigate cities in particular. And so, a lot of locals would redirect me onto different routes that were safer. And I was confused why this wasn't captured in a mapping app already. And so, that's kind of where the idea was seeded. But I didn't start working on it until I got to college and met Trisha.

+ +

VICTORIA: Great. So you got to college, and you saw that there was a need to have easier access to biking and biking information in an area, right?

+ +

MAGGIE: Yeah, exactly.

+ +

VICTORIA: Very cool. What was that initial process like? It was just the two of you, and you started building stuff? How did you really get the traction going early on?

+ +

MAGGIE: It started with doing some customer discovery interviews with local cyclists. And so we interviewed over 100 initially and just asked kind of what their biggest barrier was to start riding. And we kept hearing this recurring theme of people not feeling safe enough to go on different routes.

+ +

And so we brainstormed a bunch of different ideas in a class that Trisha and I were in together. But we ended up landing on the one that we're working on today, which is, like, you know, the rating system, and then also putting the rating system of bike friendliness into a routing algorithm where people could actually find routes.

+ +

VICTORIA: That's very cool. And was there anything that really surprised you in that customer discovery process?

+ +

MAGGIE: Just maybe the consistency around people's fear and, like, I guess, being nervous on a bike because we were interviewing people of all types of backgrounds and experiences. And even people that were more experienced had this fear of getting hit by a car because of lack of infrastructure and that sort of thing.

+ +

TRISHA: Doing customer discovery and chatting with so many different types of riders...and we call them riders, bike riders, rather than cyclists for the distinction that, you know, in the bike riding community, there's a lot of very avid fitness-geared cyclists, maybe who want to go on their bikes to burn calories and challenge themselves.

+ +

A lot of people they would call themselves someone who rides a bike. And it's to those types of people where safety is really critical, especially in allowing new people to go and try to ride a bike for the first time or the first time in many years. And so, that's something else that we noticed from those customer discovery interviews is identifying the different types of riders.

+ +

VICTORIA: Thank you. That clears it up for me because I never know to call someone a cyclist or a rider, but it makes sense that cyclist is more, like, the athletic pursuit versus riding and, you know, just trying to get about your day. [laughs] And it also makes me feel better that even people who are really experienced riders have fear of being unsafe or getting hit by a car because that's certainly what I'm thinking about when I'm [laughs] venturing out there. So, what was your initial build like for the app solving this problem?

+ +

TRISHA: Initially, we had a couple of different Brown University interns or students working on it together one summer and myself included. And that evolved to me and this one other student who was working with us figuring out how to transition the app from, like, an iOS Swift native app to React Native so it could be cross-platform. And we had to teach ourselves React Native for that.

+ +

So our intern at the time he had done an internship during the summer at this one startup where they taught him React Native. So he had done a couple of projects there. And I had a little bit of experience writing in JavaScript but really not as much as him. And so, together, we worked on coding the app from what we had in iOS in Swift, which was pretty limiting. But, at the time, it wasn't very much.

+ +

But we were able to replicate that in React Native during; I think it was my junior...Maggie in my junior winter break. That became the start of our MVP, which had many, many more iterations to get all the features in and was a little bit slow to build until when we released it out, which was our senior year in about March or so.

+ +

VICTORIA: So that's really exciting. So, like, how long did it take you to really get to that initial MVP with the team that you have?

+ +

TRISHA: It took quite a bit longer than expected, as with all sorts of technology when you're building it for the first time. So what was important to us throughout the process was making sure that all the features we put out there were really well tested, and were useful, and were actually solving the problem of providing safer routing.

+ +

And to get to that stage, at first, we, you know, we had an app in Swift. Then we wanted to make it cross-platformed, and we needed to have the routing algorithm actually take those different weights, the different bike friendliness ratings of the roads into account. And that took a lot of researching and talking to mentors. So there were quite a few really hard challenges to get to the MVP, which is why it spanned about a year to get to that point.

+ +

But throughout it all, we worked with other students at Brown. Then we pulled in some front-end contractors from online, like contractor sites, who were awesome. And we were just focused on being really scrappy to get it out in March of 2022.

+ +

VICTORIA: That's great. And maybe it felt like a long time, but I feel like a year for a really solid MVP is pretty good, [laughs] especially when you have those safety concerns, and the quality of your data, and what you're giving out is super important. So now you've got the MVP, and I believe you just raised your round of seed funding last year. What was that process like for you?

+ +

MAGGIE: Yes, so the round of funding that we did, we raised the first initial amount actually going into our senior year, and that was from a firm called Rogue Venture Partners. And we also got a little bit of it from their Women's Fund. And, yeah, that was the kind of piece of funding that got us started and allowed us to really, you know, add additional resources to the product to get it out there, at least the MVP. And then, after that, we got a little bit more funding from them.

+ +

And then we raised money from Techstars as well because we got into their accelerator at The Roux Institute. That's kind of in association with Northeastern, and that was out of Portland, Maine. I guess it wasn't really necessarily, like, a cohesive round. It was, like, a couple of different checks that all kind of went into, like, our early funding for Pointz.

+ +

And I would say it was very much so based on, you know, our relationship that we had with our initial venture firm that were working with Rogue. They actually mentored us for quite a few months before they invested in us. So they started mentoring us our junior year when we were in school. And then we got the deal together September of 2021.

+ +

VICTORIA: That's awesome. Well, congratulations. And I'm glad you were able to find the right partnerships, and mentors, and funding that you needed. What did you find was really the differentiator for your app versus what was already on the market for biking-related apps?

+ +

MAGGIE: There are a couple of different types of competitors, so there are the biking-related apps that you just mentioned, and then there are the general kind of use case apps like Google Maps or Apple Maps. And so, for the bike-related apps, the main thing that's different about Pointz is that we're more focused on, like, bike riders in general, so people that are riding around for transportation and recreation, not so much the cyclist type of a person that Trisha described earlier.

+ +

So, you know, a lot of our features are geared towards people that are getting around the city or maybe are exploring a city or a neighborhood. It doesn't necessarily have to be a city, but that's kind of the focus. Whereas for other cycling-specific apps, like Komoot or Ride with GPS, it's focused a lot on, like, the fitness side of things and the recreation fitness side of riders. And so, at least the Ride with GPS and a few other of, like, the technologies that are available to more hardcore cyclists tend to have a more sharp learning curve. And ours was built more as, like, a general use case in navigating and exploring.

+ +

VICTORIA: That makes sense. So it's more for people like me who are trying to go the most scenic [laughs] or the flattest and the safest way, not necessarily the fastest or the more fitness-focused aspect of cycling and biking.

+ +

MAGGIE: Yeah, exactly. And, you know, we actually built this for people like us. Granted, I did do that long-distance bike trip. But, generally, I don't consider myself that hardcore of a rider, I mean, in my daily life. So it's for people who don't really identify as a cyclist and are more just, like, riding their bike around and, honestly, for people who are new to riding in general.

+ +

Because a lot of our riders have recently gotten into biking or have recently moved to a new area, and so, they're just trying to figure out, you know, where are the good places to ride? Where do I feel safe? And, you know, how can I get more comfortable on my bike?

+ +

VICTORIA: I'm loving this idea because I have a bike that's been sitting in my patio for over a year. [laughs] I haven't used...my partner is like, "Can we get rid of it? Because you don't use it." But I'm like, "I will. I will use it." I know my neighborhood problem is that there are giant hills if we leave our street here. So getting out is fine. But getting back in [laughs], it's like you need an electric bike. So that's very exciting.

+ +

So, tell me more about now that you've graduated and you're taking this up full time; what does the future look like? What's on your horizon?

+ +

MAGGIE: I mean, we've been working a lot with one of our advisors on, you know, getting to the point where people really love the product, and that's been kind of happening over the last year. We met Anuj Adhiya from Lenny's Newsletter. We've been working with him to really hone in on what the thing is that people really love about Pointz and make that experience better. And then also figure out what exactly the persona is so we can target them eventually with marketing, which is kind of the stage that we're at right now.

+ +

So we were seeing our retention curves really evening out in especially a couple of cities that we're targeting. And so, this summer, we're focusing on getting our user base up in Los Angeles and then trying to figure out how, like, a playbook for scaling up a user base in a specific geography. Right now, a lot of our users are distributed throughout the United States. And there are clusters, but there's not, like, a huge spike in one city. And so, that's what we're working on right now is figuring out how to get a geographic kind of density to happen.

+ +

VICTORIA: That makes sense. And it sounded like the app also uses a lot of user-generated data for safety ratings and things like that. Am I getting that accurately?

+ +

TRISHA: Yep, that's correct. And what we do is we have a bunch of different layers of our data that we pull from. We have a base layer of data that comes from OpenStreetMap, and then we build on top of that. We rate all roads on a one through five bike friendliness scale. And building on top of that, we pull from city-specific data sets from cities, and towns, and municipalities. And then, we layer on the crowdsourcing similar to how Waze does at the top.

+ +

VICTORIA: Got it. So taking advantage of that open data, the open city data, and what other data the city is putting out there. Are you finding that you're using whether or not a city has open data to inform if you're going to expand into that location?

+ +

MAGGIE: Kind of as a focus point. So, the way it works right now is Pointz is available actually anywhere in the U.S. So; it doesn't matter if you're in a city or a rural area, you can use Pointz. And you can use it for routing and navigation and all the features that are available. However, we only have visualized the ratings in all 350 or so urban areas in the U.S., and so those are all visualized, but not all of them have the supplemental city-data.

+ +

And so, the way we decide when we pull in city data is based on gaps in, like, the base layer. So, if we're seeing that there are a lot of accuracy issues in a specific city, we'll go, and we'll look and see if there's a more accurate map that the city has put out or that an advocacy group has put out. And so, we've done this recently in Chicago, Minneapolis, Portland, Oregon, just to supplement the base layer of data, and it has helped a lot in terms of accuracy. And users or our riders really like it.

+ +

VICTORIA: That's great. And what is your current level of usage in the app? How well have you been adopted?

+ +

MAGGIE: Are you talking in terms of, like, user numbers or just, like, our engagement levels?

+ +

VICTORIA: Yeah, whatever you're using to measure your level of engagement or number of users on the app. Like, what are your stats looking like?

+ +

MAGGIE: Yeah, so, we use...we have our overall signups. And then we have a subcategory of, like, active and engaged users. And so, for our overall signups, we're at just over 9,000 total signups since we launched the MVP, and we haven't marketed it at all kind of until right now, where we're trying to push it out in LA a bit more.

+ +

And then, in terms of our engaged cohort, I'd have to pull up the exact number. But last I checked, it was around 1,800 monthly active users. We kind of look at that cohort, and then we break it down into, you know, who's even more engaged in that? Who's coming back every week, every day?

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So...

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

VICTORIA: I'm wondering if you have any incentives built into the app for users who are, like, contributing data back, or maybe they're writing every single day. Are there any little challenges or achievements that you could unlock within the app right now?

+ +

MAGGIE: We do have some gamification, yes. And so, the way that people can earn points on the app...we call them points with a Z because of the name. The way that they can earn those points are a couple of ways. So, one is through riding their bike and using Pointz as a navigation tool or as a tool to record their ride. And so, for that, you get one point for every mile.

+ +

And then the second way is by contributing to the map, so either crowdsourcing an amenity like a bike parking that isn't on the map already or by adding information about a hazard that might be on the map, like, for example, a car parked in the bike lane. And for each of those, you know, you get one point. And so, yeah, we have that gamification system built out and a couple of...like, we have a leaderboard. And then, also, we have, like, a way for you to kind of go up in your avatar on the app.

+ +

But besides that, we do monthly contests. And so, this past month, we partnered up with a company called Po Campo, which makes stylish bike bags that can be taken off your bike and then worn as, like, a purse or a handbag. And so, they sponsored the prize, which is one of their bags, and whoever kind of gave the highest quality and quantity of crowdsourcing reviews and miles ridden they're the winner of the contest for this month of June.

+ +

VICTORIA: That's very cool. I love to see that and hear about what strategies people have for engaging with their users within the app. I'm curious to go back to, you know when you two first met, how did you know that you were going to be good partners to work on this project together?

+ +

TRISHA: One of the ways that we knew that was because we had first been introduced to each other from our mutual friend who is a close friend of both of ours, and she had been telling the other person about each other. And it was one day where we just met up, and we really clicked.

+ +

But, at that point, Maggie was looking for someone who could work on the mobile development, and I didn't have any experience with that. However, I joined a club, which Maggie was leading, which was called The Women's Entrepreneurship Group. And we got a chance to work together and plan out many events, including a large conference right before COVID hit.

+ +

Like, we saw how we'd worked together. We really enjoyed it. And we had very similar aspirations and motivations towards entrepreneurship. When I had the chance to basically join what Maggie was already working on with Pointz in the summer of 2020, I knew that that was going to be a great opportunity. And we decided to become co-founders by the end of the summer.

+ +

VICTORIA: That's very cool. And I know how important it is to have the right team together to work on a project like this and to start something up from scratch. So, were there other big turning points? And you mentioned COVID, so I'm curious how that affected the growth and progress of this effort.

+ +

MAGGIE: Yeah, to be honest, in the heart of COVID, like 2020, we weren't really built yet. So, it didn't quite affect us a whole lot, just because the product didn't get launched until the spring of 2020 to actually, you know, kind of publicly. But there were a couple of other turning points in our company, one of them was Techstars and kind of the progress we made during Techstars.

+ +

We joined the accelerator, and we were having a bit of a hard time getting tech kind of pushed out really quickly. It was taking us a long time to build the features. And so, Trisha and I kind of evaluated why that was happening. And we came up with a process that worked a lot better, which we still use today. And speaking of team, we got a couple of really awesome teammates that made a huge difference on how quickly we could turn around features and bug fixes. And so, that was a really big turning point because we were able to iterate much more quickly and get feedback from our riders a lot faster. So that happened November, December of last year, of 2022.

+ +

The other big turning point, I would say, is the slider that we released in March of this past year of 2023. And so we were having a hard time retaining users and getting them to really like the routing because people who bike tend to be very opinionated. And if the route isn't exactly kind of how they wanted it, they would be upset. And so, we'd fix it for one group of users, and then we would upset another group that didn't want that, you know, added to the routing.

+ +

What we ended up doing was releasing this safety slider, which has the fastest routes on the left side of the slider and then the safest or the longest routes on the right side of the slider. And that really helped people get a wide variety of routes that fit their use case. And it's helped a ton with retention. And also, the feedback we were getting from users really changed from, like, really honing in on a very specific issue with routes that they were getting to general feedback about how we could enhance the app and keep people coming back more consistently.

+ +

TRISHA: I just want to emphasize again that, yeah, the team is really critical. And, like, on our team, we have really awesome people who are 10xers and just great. Also, have someone who worked at MapQuest and has...I think our combined mapping experience is around 20-plus years. So it's really awesome to have that sort of a team together.

+ +

VICTORIA: Yes. And, you know, talking about it now on the podcast, in retrospect, I'm sure it all seems like it came together, and it was kismet, and everything just worked. But was that how it really felt? Or were there moments where you doubted it and thought, maybe this isn't going to come together?

+ +

MAGGIE: Yeah, definitely. There were moments of that feeling. One thing that gave us a lot of confidence was getting to the point where we felt like we could really iterate quickly and release features at a consistent and predictable cadence. So that gave us confidence that you know, there is a process for this, and there's a process of gathering user feedback and rider feedback, and then translating that into features, or bug fixes, or UI fixes. I think that gave me a lot of confidence that we could solve it.

+ +

But, of course, it always takes a lot longer than you expect. And our advisor, Anuj, always says that 80% of what you're going to do won't work and 20% of it will. And it's all about how quickly you can iterate and figure out what works. And sometimes you get lucky, and it happens quicker. Or maybe you have unique insight into the problem, and you can guess, and it works out quicker. But I don't know; I definitely think it's been a learning process for everyone on our team.

+ +

VICTORIA: That's great advice. And now that you've got your velocity up and you have your confidence, what's on the horizon? Are there new features that you all are working on that you're excited about?

+ +

TRISHA: Yeah, so we're really excited about leaning into the whole generative AI trends that are happening, especially with ChatGPT and others. One thing that we've been hearing from most of our riders, people who use Pointz, is that using the app to create routes, which will allow them to explore new places, go to a new coffee shop that they've been hoping to go to but just don't know how to actually get there is critical. And most of our riders on Pointz are people who are new to a city. Maybe they've only lived there for a max of one year or less. So, exploring the area around them is really important to them, and that's why they use Pointz.

+ +

And so, leaning into that, we're going to be releasing, in the next couple of weeks, a new explore feature where someone can go and, you know, describe to Pointz what type of route or...not even route, what type of things they want to see in a city, and Pointz will come up with that. It'll learn their preferences and continue to suggest really awesome places to get to, which they can do car-free, basically, through bikes, because they can be safe and, you know, they can rely on this app to get them through the city safely.

+ +

VICTORIA: That's really exciting. And I'm excited to try it out myself [laughs] once you have that feature launched. Maybe you can tell me how that feature plays into...or what your success really looks like for Pointz in the next six months.

+ +

MAGGIE: Yeah, so I think that feature is something that will be, I mean, of course, we got to test it, but I think that it will help people kind of use Pointz as an exploration tool more effectively. People are already using it for that, but it's not specifically built for exploration. Right now, it's built more for, I guess, routing to, you know, new places but not specifically, like, oh, let's go on a route that takes me through all these tourist destinations in the city I'm visiting. But this new feature will allow people to use it for that more.

+ +

And I think, overall, you know, our mission at Pointz is to help people feel comfortable riding bikes so that they can drive less and feel like they can get around in a sustainable fashion, rather than having to rely on their car so often. And this feature is tied to that in the sense of, like, people can use it as a tool to help them, you know, find the safe route or a route they're comfortable with, and then use it to explore an area but maybe a bit more geared towards, like, tourists or, you know, more recreational-type use cases.

+ +

VICTORIA: That's very cool. Thank you so much for sharing that. And what is your biggest challenge to achieving that success?

+ +

MAGGIE: I think biking is a first step in that process of helping people feel like they can be more car-light or car-free, you know, use their car less. There are obviously a ton of other factors that go into whether or not you're driving, or you're taking a bike, or you're taking public transportation. And, you know, our next steps after we have really nailed this product are to explore those opportunities and build tools that help people choose alternative transportation more often. That's what we're excited about going into the future.

+ +

You know, there's a ton happening in cities all across the U.S., not only for biking but also investments in transit, infrastructure, and whatnot. So, you know, young people and people of all ages...I think a lot of people feel comfortable and that they don't want to be sitting in traffic a whole lot [laughs] because that's not fun for anyone. And, you know, traffic and congestion is always frustrating. So, as much as we can reduce that, I think that's the mission of our company. And, of course, it takes a ton of scale. But it's a big goal, but we're going after it.

+ +

VICTORIA: That's great. You know, I heard about a town in the U.S. that actually had banned cars and was pedestrians only for the whole town. It's like, what a great idea. [laughs] But I love it. I love that you're working on it. And I wonder now, you know, you're a couple of years into it. If you could go back in time and give advice to yourself when you first started this project, what advice would you give yourself?

+ +

MAGGIE: For me, I would say to get a minimal viable product more minimal, [chuckles] so reduce it to, like, a single feature, get it out quickly, and start getting feedback more quickly from, like, a very practical, you know, piece of advice.

+ +

And then, like, an overall piece of advice would be just to be more confident earlier on. It took a long time for me to gain the confidence of, like, being a thought leader in the space. And, you know, I felt like I was young, so there were all these people that knew more than me. But I think everyone has a really unique perspective, and if you really lean into that and share that with the world, it can inspire a lot of people. And you just have to be confident enough to do that.

+ +

TRISHA: Yeah, I definitely second what Maggie just said. I think also from the tech perspective, if you're someone who is maybe more inexperienced, like, I just got out of college and did this, and I have never worked a full-time job before anywhere except this. And so I think there was a lot of doubt that I had of being able to lead the technical side because I didn't have 20 years experience working somewhere.

+ +

But, actually, at the end of the day, that doesn't matter. It just matters that you're able to be in touch with what it takes to build certain features and talk to the users, or your riders, or whoever because they're the ones who are going to be dictating whether this is a success or not based on what you build. It's really not good if you're building and wasting a lot of resources and time on features which nobody wants or nobody uses. And so, that's been core to why I think I've gotten a lot of confidence in being able to be, like, the tech leader in this app and in this space.

+ +

VICTORIA: Yeah, I'm curious to hear more about that. You touched on this really being your first full-time job. So, how do you build your personal brand as an executive leader in this company that you're building?

+ +

TRISHA: For anyone who does startups, they'll know that it's a lot of figuring it out as you go, and things that you're taught in school don't necessarily translate well to the startup world because, like, I did, like, a Bachelor of Science in Computer Science. I did operating systems. I built a whole bunch of random stuff in school, and I studied for hours and hours.

+ +

Of a lot of that, the most important thing, which actually translates to working in my field, is the perseverance to, like, keep going and working really hard. Otherwise, none of that stuff which I learned honestly translates. I had to learn everything myself with regards to building mobile apps. And I think the foundations were really critical from school but not really much of the hours of studying. I don't think that that's necessary, but I think it's necessary to build that sort of perseverance mindset.

+ +

VICTORIA: That makes sense sort of to reflect that back a little bit, just having the perseverance to keep pushing, and keep learning, and keep understanding what is it going to take to build the features that you want? And that's really the core of being a CTO, right?

+ +

TRISHA: Exactly. Exactly. Yeah.

+ +

VICTORIA: And, Maggie, I wonder about you as well, like, what resources are you drawing on to really perform as a CEO for this company?

+ +

TRISHA: One thing that I read a lot is...it's more product-focused, actually, but it's product and growth-focused. It's Lenny's Newsletter, which I mentioned earlier. I use that as a resource a lot. I listen to their podcasts, and I read their articles.

+ +

And then secondly, I interact a lot with other CEOs and founders because I think that's one of the best ways you can learn is from other people who are in it right now, maybe are a couple of steps ahead of you, or who have done it before. And so, I lean into that quite a bit. And just, you know, try to get advice from people, take what makes sense, and apply it to what we're working on.

+ +

VICTORIA: That sounds great, yeah. I can relate to that; just building your personal network with people who are in similar roles helps you stay in touch and understand what other challenges people are facing and what you might face someday, right? [laughs] That's really cool. I love that you have all that set up.

+ +

And is there anything else that you all would like to promote today?

+ +

MAGGIE: I would just say to anybody who's interested in biking or maybe is, like, a beginner rider, we'd love to have you try out the app and then explore your area and give it a try one weekend when you have some time and see if you feel more confident, you know, given the routes that are on more green and protected roads.

+ +

VICTORIA: I'm really excited to be talking to you because I am that person. I need this app. [laughs] I'm excited to try it out. Thank you, Maggie and Trisha, for joining us today. [laughs] It was a really great conversation, and I'm excited to follow along and see what happens with Pointz in the coming years.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Maggie Bachenberg and Trisha Ballakur.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+G-_czS_J + + ]]> + + Victoria Guido + Maggie Bachenberg + Trisha Ballakur + + + 484: Ruby On Rails: The Podcast with Brittany Martin + https://podcast.thoughtbot.com/484 + 813476f9-eae5-469d-8bf3-339cf5936269 + Thu, 20 Jul 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Brittany Martin is an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers and is the Co-host of The Ruby on Rails Podcast. + +Victoria and Will talk to Brittany about the multitude of stuff she's interested in, including Roller Derby, and gives the story of how she found herself co-hosting the show. She says knowing what your brand is and what listeners should expect from listening to you is super important, and she gives her opinion on what it means to be in the Ruby on Rails Community. + 50:30 + no + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +-- +Brittany Martin is an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers and is the Co-host of The Ruby on Rails Podcast. +Victoria and Will talk to Brittany about the multitude of stuff she's interested in, including Roller Derby, and gives the story of how she found herself co-hosting the show. She says knowing what your brand is and what listeners should expect from listening to you is super important, and she gives her opinion on what it means to be in the Ruby on Rails Community. +Shogun (https://getshogun.com) +The Ruby on Rails Podcast (https://www.therubyonrailspodcast.com/) +Follow Brittany Martin on LinkedIn (https://www.linkedin.com/in/brittanyjmartin1/) or Twitter (https://twitter.com/BrittJMartin), or visit her website (https://brittanymartin.dev/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. And with us today is Brittany Martin, an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers. She is the Co-host of The Ruby on Rails Podcast, almost five years running. And she plays roller derby for Steel City Roller Derby under the pseudonym, catch this, Merge Conflict. She is based in Pittsburgh, Pennsylvania. Brittany, thank you for joining us. +BRITTANY: I am so thrilled to be on here. I have been listening to Giant Robots for years. So it's an absolute honor to be on the show today. +VICTORIA: Yes, thank you so much for joining us. And I met you at RailsConf this year. And, at the time, you had a boot on your foot. So, I have to ask you, are you healed? Are you recovered? Are you walking around again? +BRITTANY: This is such a good question. When I was between jobs in March, I was, you know, having these two weeks, I had a whole list of things that I was going to be doing. You know, I was going to train, like, running and whatnot. And I had roller derby practice that first week, and I broke my ankle. And, you know, going into it, I had no idea what a blocker it was going to be. I was like, oh, this is minor. It'll just take a couple of weeks to heal. No, it's been a long process. +But I can gleefully tell the listeners that I am out of the boot. I am walking. I am hopefully getting into a sports program next week that will train me up to get back into CrossFit, running, and skating. Though the really funny part is that I currently have another injury which is golfer's elbow. [laughs] +WILL: Oh, wow. +BRITTANY: Yeah. So I have that from overusing my arms. So I'm a little bit of a mess, but, you know, getting myself back together physically so I can get back on my skates. +WILL: So I know it's called golfer's elbow. But did you actually hurt it doing golf, or was it another sport you were playing? +BRITTANY: It's so funny that you ask that, Will, because whenever people ask me how I broke my ankle, I can be glamorous and be like, "Oh, it was roller derby." +WILL: [laughs] +BRITTANY: Like, it's a sexy injury, you know. I have a friend who just broke their ankle because they were dancing down the stairs and broke it, not as glamorous of a story, right? +WILL: [laughs] +BRITTANY: Golfer's elbow. I literally have no idea how this happened. I've never golfed a day in my life. So [laughter] it's my non-glamorous injury at this point. +WILL: Yeah, that's my background, sports medicine. +BRITTANY: Oh, great. +WILL: So it's interesting. Yeah, golfer's elbow, and I'm like, it's usually not golf that does it. So...[laughs] +BRITTANY: Yeah. So I said something to my PT. I was like, "Am I the first person to ever get golfer's elbow from, like, you know, fixing another injury?" And she's like, "Yes. Yes, you are." [laughs] And I was like, oh. [laughter] I really was expecting to get some reassurance that it wasn't me. But hey, what are you going to do? +WILL: There you go. +BRITTANY: I love the fact that you do love my roller derby name. As you can imagine, it is a beacon for finding the other programmers out on the track because they find it very funny. Nobody else finds it funny whatsoever. And people call me Merge for short, and some people think it's Marge. And I just allow it at this point. [laughter] My number is 200, and its status code okay. When you hit me, I get up okay until, apparently, I break my ankle. So...[laughter] +WILL: I love it. Because if you're a programmer, you're like, oh, she means business. +BRITTANY: Exactly. +WILL: Because merge conflicts...yeah, never fun. +BRITTANY: Exactly. +VICTORIA: I love that. I love finding other people who work in tech in other random activities. Like, I've recruited people from the climbing gym. [laughs] I'm like, oh, we're climbing together, and, oh, you're an engineer. That's interesting. [laughs] So it's great to, like, be with your community in different settings, so... +And you're just so involved in the Ruby on Rails Community. And I'm curious what really got you started into podcasting. +BRITTANY: Yeah, that's a really good question. So I'm a former product manager former MBA. So I didn't know how to code. I moved out to San Francisco because I thought that's what everyone did. If you wanted to be in tech, you moved out to San Francisco, and so I did that. +And I realized very quickly that it was going to be hard for me to be a product manager without knowing how to code. And so I went to a bootcamp at night, and I became a Ruby on Rails developer. So I wish I had, like, just a really cool story for why I chose Rails. It's literally the framework that was being taught by the bootcamp. +WILL: [laughs] +BRITTANY: But I'm so glad that it was because I love this community so much. But, you know, when I moved out to San Francisco, I just had my current partner at the time and my dog. I didn't have any friends. And so it was really the perfect time to learn how to code just because I was really able to focus. And I ended up having a lot of long walks at night, like, getting to the train, getting to the bus, and that's really when I got into listening to podcasts. I'm not a huge music person, which is kind of weird. I really...I deeply love podcasts. +And so I just kind of glommed on to a bunch of podcasts like Giant Robots, CodeNewbie, Bike Shed. I figured if I listened to all the things that I wanted to be, like, osmosis would just happen, and I would just start learning the things because I was actively learning about how to code. And I thought just listening to those concepts would really help. And really what ended up happening is those people that I was listening to, like, to me, they became celebrities to me. Like, I don't care about regular celebrities. [laughter] I care about people within these communities that I care so much about. +And so, you know, a couple of years into that, I was still very much devoted to listening to podcasts. I trained for my first marathon listening to podcasts. And I was listening to The Ruby on Rails Podcast, and, at the time, Kyle Daigle had taken over the show. And he had decided, in order to spice things up on the show, he was going to bring co-hosts on that he was going to rotate through. So, every couple of weeks, you would come on as a co-host, and you would drive the conversation with things that were going on in your life. +And, at the time, you know, there wasn't a lot of women, female representation in podcasts. I felt that I was doing interesting things. I was working at a non-profit doing ticketing for the Broadway Symphony and opera, like, in Rails. So I felt like I was always working in Rails, and I thought I could provide some useful insight. So I reached out to Kyle. I must have been very ambitious that day because I reached out and I said, "Hey, how about bringing me on as a co-host?" And he said, "Yeah, absolutely. Like, that would be great." +And so I came on as one of the regular co-hosts on The Ruby on Rails Podcast, which I should have been flying high, right? Like, this is exactly what I wanted. I got to become like one of my own celebrities, right? Well, Kyle got really busy. At the time, I believe it's when Microsoft was acquiring GitHub. And Kyle still works at GitHub today. Kyle is amazing. He's their COO now. +But the podcast kind of went dormant for a couple of months. It was my big opportunity. I really loved, you know, being on a podcast. I had done a couple of episodes. So I reached out to Kyle and said, "Hey, is there any chance you would give me the podcast?" And he said, "Absolutely." And he signed over everything to me, [laughter] which was really scary because I was taking over a podcast that had been around, at that time, it had been around for at least ten years, hundreds of episodes deep. It was on its own network. It was on the 5by5 Network at the time. So it had sponsors and expectations. +And so, really, I had to learn everything from the get-go. Like, I made up my own episode plans. I made up my own questions, like, how to do ad reads, how to edit, how to upload to the hosting platform like; that was entirely on me. And, you know, we can talk more about how the podcast has evolved over those years. But yeah, long story now made short, that is how I got my start in podcasting. +WILL: That's actually really amazing that that's how it got started and everything. Let's go back to when you first started. What was your feelings like? You say it was a lot to take on. Can you dig deeper in that and tell us more about that? Because I think I felt the same way. I think we've been doing this for about a year now. It's scary, let's be honest. It's scary jumping on a podcast and sharing who you are and what you're doing. So, can you tell us more about that? +BRITTANY: Absolutely. I think one thing is just knowing what is your brand and, you know, what listeners should expect from listening to you because this is a podcast that had been around for ten years. You know, it had changed formats several times. It was an interview-style podcast at one point. At one point, it was a bunch of co-hosts that would just meet every week to talk out what was going on. And so I really needed to take a moment and kind of look over the metrics of the episodes. +Like, I have that marketing background. I have that product background. So I wanted to know, like, what's actually working? Like, what do listeners want to listen to? And I also, like, kind of pored through all the reviews of the podcast. I'm like, did people even notice that this podcast went offline? Like, what's the current ecosystem? How many podcasts are out there in the Ruby and Rails space? +And so what I started doing is I wanted to create, like, a safe environment in order to start the podcast over again. So what I did is I did interview-style podcasts with my friends, people that would tolerate me, you know, making mistakes, knowing that I was probably...I am a terrible editor. And so bringing those people on to have just genuine conversations with. And then really just tried to pick up the listenership of the podcast because I'm basically waving my arms saying, "Hey, folks. Like, The Ruby on Rails Podcast is back. I'm here as your host. And, like, we are here to stay. Like, I want this to be a mainstay in the community." +VICTORIA: That's great. So you started to apply those concepts from your product background. And I'm curious what you found in how the business of the podcast really works. +BRITTANY: Yeah, I learned a lot, and we can talk about the transition. So, when I came on to the 5by5 Ruby on Rails Podcast, at the time, this was back in 2018. The podcast was being managed by 5by5, which is, like, a long-standing podcast network. They're still around, but they're much smaller than they used to be. +So, like, all of the sponsorship and the episode management was being handled by them. And so I didn't have a lot of insight into that part of the podcast. What I did have insight into is, like, what content is performing well? And what is the audience reaction to what we're putting out there? Like, how is the listenership coming back and whatnot? +Now, one thing that did happen over the course of me managing The Ruby on Rails Podcast is we decided to take the podcast independent at one point, you know, 5by5 was starting to wind down. And so, back in 2021, I reached out to 5by5 and said, "Hey, I genuinely really love this podcast. I want to be able to take it to a different platform, you know, have it go independent. But it's really important to me that I'm able to hold on to the current subscribers that I have." +I think we all know that, like, if you rebrand something and it's a totally different RSS feed, it's really hard to get people to move over, especially if they're using something that makes podcast listening really easy like Apple Podcasts, you know, you subscribe. You get new episodes, and you just hit play. And so they were extremely willing to work with me. +And so, we ended up taking the podcast independent. 5by5 created the hosting platform Fireside. And so we moved the podcast over to Fireside, and that was, like, a very seamless transition. But it was a moment in time where, you know, I was kind of questioning. We're no longer 5by5. It was the 5by5 Ruby on Rails Podcast. What do we call it? And so I genuinely had that moment where I was like, I could be really clever with the name. But then I stepped back, and I was like, no, everyone already refers to it as The Ruby on Rails Podcast. I'm just going to go with it. And so I think that ended up being a good decision. +We did change the logo of the show. We kept the same feed. And we had, like, the first episode on the new...we're not even on a network now; we're independent. The first episode of, like, the V2 of The Ruby on Rails Podcast is really what we called it. We just kind of explained the whole move. And I'm just deeply grateful all of our listeners just kind of followed along. +And I will say the biggest boon to us moving is that we did get a professional editor. And so, like, the quality of the episodes went up, which is the best money that you can spend. Get yourself a professional editor. I cannot stress that enough. Or you get really good at it yourself. But I know my own skills, and it was never going to be that way. +And so we took it independent. And I also decided to do a format change as well because it was a lot to do years of a podcast by myself. It was a lot. So I'm really glad Victoria and Will that you have each other. I think it's really great to have co-hosts. So I ended up moving the podcast. I now have a producing partner, and that's Mirror Placement. They do recruiting for Ruby on Rails, and they are wonderful partners. +But I also have three co-hosts that rotate through. I have Brian Mariani, who's a recruiter and founder of Mirror Placement. I have Jemma Issroff, who works on Ruby at Shopify. And I have Nick Schwaderer, who works on Rails infrastructure at Shopify. And that's been great because I rotate through those co-hosts. And I always have fresh content from them. But I also do the interview-style episodes as well, which Victoria was on recently. +VICTORIA: Yes. I agree 100%. Having a co-host like Will makes it so much more fun. And I cannot appreciate our editor Mandy Moore enough. And I agree on that advice. And I actually would add when people ask me if they should start a podcast, recommend having at least one other person [laughs] who you want to talk with about that topic for every week. But I wonder, if someone's thinking about starting a podcast, what would you have them consider as to whether or not it's worth it for them? +BRITTANY: I recently joined the podcasting subreddit on Reddit just because I was interested to see what kind of questions there were out there. Because when I got into podcasting, I was, like, oh, you just need to have a microphone and a way to record, and you just put it out there, and people are going to listen. It feels very much...like, you remember when, you know, the iPhone came out, and the App Store was empty? And then any app that you made was, like, amazing. Everybody would download it because there was nothing to download. We're now getting to a point with podcasts; there's just a lot out there. +My first bit of advice is, something that I said earlier, is make sure that you have an identity around your podcasts. Like, make sure that you are targeting a niche. It's fine if there are other people doing it, but do something that is uniquely you and do something that brings you joy. I really love talking to people in the Ruby on Rails Community. I have a special affinity for people who have never been on a podcast before. It's a lot of work. +So it's definitely worth it. I've gotten to meet a lot of my programming heroes because of it. And there are times where I've been very tempted to take a break and be able to step away from it. But, as of right now, it has been a good experience. +And what I often say whenever I open up my conference talks is the Ruby on Rails Community is my community contribution because I'm not someone who regularly contributes to open source. And so this is kind of, like, how I give back, and I get to meet a lot of amazing people. +Mid-Roll Ad: +VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. +From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. +To receive a custom quote, contact sales@thoughtbot.com. +VICTORIA: And with me here, I have Richard Newman, who's the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? +RICHARD: Hi, Victoria. +VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? +RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. +And so a number of things that we pay attention to in maintenance are we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application, we're responding to those sorts of changes as we go along. +And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. +VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? +RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. +The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. +And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. +VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where suddenly, you need to make a very large investment and fixing whatever is broken. +RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. +VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. +RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. +And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. +VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. +[laughter] +RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. +VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... +RICHARD: [chuckles] Absolutely. +VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. +RICHARD: Yeah, it was a pleasure. Thank you. +WILL: I have a question around your listeners. I just want to take a second and just thank everyone who listens to the podcast. We really appreciate you so much, so just thank you, thank you, thank you. Because if you don't have listeners, you don't have a podcast, like you said a second ago. And you went through so many changes. What's been your biggest win, and how do you continue winning with your listeners? And how do you engage with them? +BRITTANY: This is a fun answer because, actually, thoughtbot comes into play there. They did not pay me to say this. But one thing that The Bike Shed used to do is they used to go to RailsConf and RubyConf, and they would record episodes during the conference with various Ruby heroes in the community. This is going back to me seeing these people as celebrities. I just thought that was, like, the coolest thing. And, at the time, I couldn't afford to go to conferences like that. So being able to listen to those podcasts and get to hear that kind of content was really important to me. +And so, you know, eventually, that stopped being a thing at RubyConf and RailsConf. And two years ago, I reached out and said, "Hey, I really love those kinds of sessions. Is there any way that I could take the lead on bringing those sessions back?" And we did. So it took in the form of a podcast panel at these different conferences where we would bring in different podcasts in the community. And we would have a panel. We would answer listener questions. It was genuinely a lot of fun. +So that is a proud moment for me. But it's a proud moment for me because it gave me the opportunity to reach out to podcasts in the community and say, "Hey, we're not competing here. We're friends. I want to record content with you. Like, please be part of my podcast community." And we have never been tighter. +So, like, we guest on each other's podcasts. We promote each other's podcasts on like Mastodon and Twitter. And it is just the most lovely thing ever because now we say things like, oh, yeah, like, this podcast, like, that's our, like, sister podcast, or that's our brother podcast. Like, it's so cool that we, you know, rising tide raises all ships. That's exactly what's happening here in the Ruby podcast community. +VICTORIA: I like that familial sense within the different Ruby on Rails podcasts, and maybe even Giant Robots is a part of that. Like, are we a cousin or an uncle? [laughter] Who knows? But I was actually there when you recorded the episode live at RailsConf in Atlanta this year. Was that your favorite moment at RailsConf, or was it something else? +BRITTANY: Yeah, I would say that was my favorite moment at RailsConf. No matter how many times I meet Aaron Patterson, I am always, like, deeply intimidated by just how funny and intelligent he is. So having that excuse of reaching out to him and saying like, "Hey, will you please be on this podcast panel?" was so fun. +I deeply adore Irina Nazarova, and so having her on the panel as well was fun. And then just doing the wildcard of having the audience, like, vote in who was going to be the third panel was truly a risky move, Victoria. [laughs] But it ended up paying off, and it ended up generating some really fun content for us. +VICTORIA: That's awesome. And I'm curious, you know, to talk a little bit more about the Ruby on Rails Community. And what do you see is the biggest challenge that it's facing right now? +BRITTANY: Oh, I have so many opinions on this. What a great question. [laughs] So I recently put together a talk proposal. It's currently waitlisted at a conference, but it is a talk that I very much want to give. +But one project that I would really like to work on is...between, I would say, 2013 and 2015, Ruby on Rails was definitely the number one framework that was being taught in bootcamps. And I'm really curious about what happened to all those people. I'm one of them. I learned Ruby on Rails in 2014. I still believe that I'm in the Ruby on Rails Community, not only for the podcast, but I'm an engineering manager for a company that writes Rails. So I believe I'm very much in the community. I'm so curious. Those people had so much potential of being seniors, principals, staff engineers, founders, engineering managers, architects. What happened to them? And did they stay in our community? +And then my second part of that is, what does it mean to be in the Ruby on Rails Community? Like, can you just listen to podcasts and be in the community? Do you need to actively write Ruby? I just find that whole thing very interesting. We're very obsessed with bringing new programmers into the Rails community, which I think is important. But what about the people who we taught Rails and left us? Like, is there an opportunity to bring them back? +WILL: It's funny you say that because I wasn't in that year range. I was a little later, like, 2017. And I learned Ruby on Rails, and then I went to JavaScript, you know, React, React Native, but I'm slowly inching back towards Ruby on Rails. My current project, I'm actually able to do some Ruby on Rails. And I'm really excited about it because, like you, that was my first language style that I learned, and I still love it. It is weird, but you always love your first language; I do, at least. So it's interesting that you said that because, yeah, I can say, for me, I'm slowly coming back towards it. +BRITTANY: Well, welcome back, Will. We're excited to have you. +I know that Node was such a heavy hitter when it came out, and it made a lot of sense. Like, we're going to teach you JavaScript on the front end. Oh, hey, we're going to also teach you JavaScript on the back end. You know, from the business side, I'm so curious whether or not Rails is still, like, one of the top three solutions in order to get an MVP off the ground. I don't have my thumb on that, so I'm very curious whether or not that's true or not. +VICTORIA: We certainly still tend to default to it at thoughtbot and to get MVPs off the ground. And we're still building a bunch of products every year with it. [laughs] So, Ruby on Rails and React together, especially if you're trying to iterate very quickly and test your assumptions about what you're building, I think that it's still a really fast and high-performing framework to use. +And it's interesting because there's a coding school in San Diego, Codecademy, which is really heavily involved, [chuckles] of course, in the Ruby on Rails Community, and they still teach it in their bootcamp. And one of the reasons they said to me was because it's one of the frameworks that gives you that holistic view of how everything works. [laughs] +Like, if you're new to tech, new to programming, in general, it's a very easy entry point to understanding. And I think that, of itself, when you're talking, like, the long-term viability of a framework, being able to hire people who can step in and understand what's going on in your codebase, that framework gives you a higher chance of that. [laughs] You know, that might point to your long-term success, too. +BRITTANY: Now, that's a really good point. Going back to the podcast as well, I think one thing that is not very well solved is just being able to make it sustainable as well because there are only so many sponsors out there. And it's really hard to prove ROI from sponsoring a podcast, right? Like, you can put links in the show notes. And you can hope people click on them and they convert. And you can be able to say, "Hey, this podcast is the reason." +But I've seen a lot of people start podcasts, and they think, well, if I put a bunch of episodes out and some people listen, then sponsors are going to knock down my door. I'm very lucky that I've had some long-term sponsors that have been able to keep the show sustainable. And I love seeing podcasts that come out of companies, you know, like thoughtbot, where you are being sustained by the company that, you know, is producing it. It's really hard to justify a podcast as a business unless you are already a major celebrity already, right? +VICTORIA: Yeah, we certainly don't do it for the money it makes us directly off the podcast. We do not. +[laughter] +BRITTANY: We do not. +VICTORIA: Yeah, I agree with that. And yeah, and even it's interesting as an advertising vehicle or marketing for your company. It can be great because, like, I feel with Giant Robots, we have so many listeners, like, loyal listeners over the years that we have this, like, direct way of communicating with a community that we care about. [laughs] But if you don't have...trying to, like, create that market and create that group of people from the ground up can be really tough. [laughs] And it takes a lot of time, a lot of investment, and a lot of effort, especially if you can't afford a professional editor. [laughs] +BRITTANY: Agreed. There's just some cost that I believe, like, the longer I do this, that are just, like, non-negotiable. There are some things that you can definitely have as optional. You know, for me, like, you have to have a good microphone. You have to have a professional editor. I pay for, like, my calendar scheduling software because I want to make that really, like, slick for my guests. Like, I used to...oh, I used to do the emails back and forth of, like, I'm available at Thursday at 2:00 or Friday at 3:00. Like, would one of these work for you? No. [laughs] It's just...that's a rotten experience. +For us, we do send, like, a thank you gift after being on the show, which has been, like, a nice add with having a producing partner that will back me on that. And I try to get to as many conferences as possible because I think it's a great vehicle to promote the podcast, but those end up all being optional. And all those things they do cost money. +VICTORIA: They do. And it's funny, like, yeah, getting out to the conferences, it's still the number one way to grow things is by meeting people in person [laughs], like, being real and human. +BRITTANY: Shocking, right? [laughs] +VICTORIA: Yeah. And I'm just kind of curious, like, in terms of how you picture what success means for your podcast. Like, what does that look like in the next six months or even, like, five years of hosting this podcast for you? +BRITTANY: Ooh, this is, like, the existential crisis question because I've been doing it for nearly five years. And I think the question is always going to be, you know, like, how long do I want to keep hosting the podcast? I will say the podcast is a positive influence on me in terms of making sure that I stay connected to people, that I keep writing code on the side so that way, I know what I'm talking about. +I have this whole imposter thing of, like, what if someone finds out I'm not a Ruby on Rails developer day to day and that I'm, like, actually thinking about business problems; I was, like, an engineering manager? You know, I'm going to get found out, and people are going to unsubscribe. +But in all seriousness, I think the success for this podcast is that it can go on without me. It's been around for that long already. And eventually, like, I want to have a succession plan where someones, I will say, like, multiple co-hosts to be able to take it over from there. It'll be rough to watch because, like, I really enjoy, you know, my current era because I feel like the podcast has gone through different eras. I really do enjoy it. But, at some point, it's just not going to make sense in terms of my professional goals. Do you feel the same? +VICTORIA: Yes. But we're only a year in. So I feel like I'm still...[laughter] I feel like I'm still new to hosting. And I'm like, oh, I've already recorded, like, 30 episodes or something. [laughs] +There's been a lot of change. And we're always thinking about, like, how do we make it better? What do we do? And trying to figure out how do we really get the most out of it for ourselves. But I feel the same way that it's just one of the more fun things that I do at thoughtbot [laughs]. And it gives me that chance to reach out to people and start conversations that I otherwise would not have had. So I really appreciate it. I don't know what you think, Will. +WILL: No, I totally agree with you. I love meeting new people. And I love meeting the diverse group of people that we have on the podcast. I love that just, like, how did you get here? Like, what makes you keep at it? Like, you've been at it for five years. What makes you keep at it? Just those questions like that I really love. +For me personally, I think that I'm still in the growing phase of podcast hosting. Like, I can get better at this. I can get better at that. What else can I get better at? So I think that's where I'm at in this phase. But, like Victoria said, that's only a year in. It's a different story when you're five years in. +BRITTANY: [laughs] It is. And one thing that I will do to make it more sustainable is, you know, like when you're running, you can either be sprinting, or you can be doing, like, a long endurance race. So with the podcast, I will book a bunch of podcasts in one week and say, this is my week to be recording. Like, I'm going to be very heads down on the podcast. I have other things going on in my life, but I'm like, this is a podcast week for me. And so I will record a bunch of episodes. +And that essentially gives me a couple of weeks where I can essentially take a break from the podcast. But guess what, listeners? Like, you're still getting new episodes. So you have no idea that I'm secretly taking a break. And I think that has also been a huge help. +Odd fact is that the five years that I've been hosting The Ruby on Rails Podcast, I am only missing from one episode. And the reason for that is that when I broke my ankle, [laughs] I called my co-host and was like, "Hey, I'm going into surgery tomorrow. We have this great episode being recorded tomorrow. I need you to take it." [laughs] And so that is the one episode that I am missing from, but I think it was a good lesson for me to know that I can step away and good content can still happen. +WILL: That's amazing. That's a pretty good record. [laughs] +BRITTANY: Or it might be obsessive, Will. I don't know. +[laughter] +WILL: Let me ask you this, what does success look like for you personally - roller derby, your full-time job? What does success look like for you in those areas in six months or a couple of years? +BRITTANY: Oh, that's a really great question. So I had stepped away from roller derby during the pandemic. And so I absolutely love fitness. I do CrossFit. I have a peloton. I have my own little home gym that I built during the pandemic that I absolutely adore. +So, you know, success for me is continuing to invest in that self-care. I want to keep skating just because I'm that person. Everyone came to me, and they're like, "Oh, you broke your ankle. I bet you won't go back to a roller derby." And I was like, oh, you think I won't? You think I won't go back? [laughs] So I'm headed back, but I'm going to be very careful about it. Because I've seen that, you know, your body can break, and you need to give yourself some rest. +But to answer, overall, like, I am an engineering manager now, and, you know, my goal is to eventually to get to that director level. And, in some ways, like, I can justify the podcast just because I do get the excuse to talk to people that have the job that I eventually want to have in my career. And so it helps in that regard as well. +VICTORIA: I think that's great, and I agree. That's also why I started getting involved in my community a lot, maybe 5 or 10 years ago. I was just like, here's opportunities to show my leadership and see how connected I am with other leaders. [laughs] It helps in that way. And on blading, I actually bought rollerblades recently just to go around the neighborhood. +BRITTANY: Yeesssss! +VICTORIA: And I got heckled by a woman [laughs] who said...I think she was being sincere, but she was like, "Bend your knees, and it's going to be okay." [laughter] Like, "Wear wrist guards next time." [laughter] I was like, maybe just my face was very try-hard in that moment. Because I have a lot of respect for people who can roller derby and get around on skates that fast. [laughs] +BRITTANY: Well, you know what's really funny? (I haven't even talked about this on my own podcast.) is that you know, I'm involved in the Roller Derby League. Obviously, I can't skate right now. And so I needed to find a committee so that I was able to still, you know, provide value to the league. And so, for some reason, I decided that skater resources would be a good idea. +So I'm essentially one of the people who is, you know, human resources within the Roller Derby League. And so when there are disputes or questions, or people have hurt feelings, like, they're coming to me, which is, you know, really funny because I do some of that as an engineering manager. So, like, to your point, Victoria, like, you know, I can do growth because they're way more extreme through roller derby, as you can imagine. And, in some ways, it ends up being good practice. +VICTORIA: Yes, that does sound like practice for higher-level management decisions, [laughs] so get ready. You're going to have issues and problems, and you're the one to solve it. So... +BRITTANY: Yeah. It's not like their problems don't matter. But, in some ways, it's almost like playing with monopoly money because, like, you know, you're not dealing with somebody's, like, livelihood. You're dealing with a sport that they do for fun. Like, trust me, no one is being paid to play roller derby. [laughs] It's a very expensive sport. There's a lot of equipment involved. And, Victoria, yes, you want to wear wristguards. +[laughter] +VICTORIA: Yes. I learned my lesson. +BRITTANY: You write code. You want to wear wrist guards. +[laughter] +VICTORIA: Right. And yeah, it's funny about things like that. Like, it's still very meaningful to people. Like, when I used to coach kids' climbing competitions, it's, like, the same thing. Like, it's rock climbing, everybody, but some people take it very seriously. [laughs] There's a lot of feelings involved. But, at the end of the day, it's nice to have that practice outside of the pressure of it being someone's livelihood and all of those details. +BRITTANY: Agreed. +VICTORIA: Well, let me ask you this question. It's one of our favorite ones. But if you could go back in time and give advice to your younger self, what would you say? And maybe it's at the beginning of the podcast or some other inflection point in your career. +BRITTANY: That is...oh, what a gift because hindsight is 20/20, isn't it? When I was going through school, I ended up getting a marketing degree because I really enjoyed business. I really liked, you know, the mechanics behind marketing. But, at the time, I had taken a couple of computer classes, and this was back in 2006. And, you know, I thought about double majoring in computer science and marketing. And someone gave me the terrible advice that computer programming was going to go away [laughs], and so it would be a waste of time to get that double degree in computer science. And so, you know, I'm very much a second career developer. +Like I noted earlier, you know, I was a PM. I was a non-technical product manager before I learned how to code, and so I learned how to code in my 30s. So I wish I could go back and get into programming way earlier. It would have changed the entire trajectory of my life. But part of me always wants to live out, like, that Black Mirror, like, what it would have been like if I had learned to code so much earlier. Would I have found Ruby? Maybe not. +WILL: I totally agree with that because the same story. I remember growing up, and I had a cousin that lived next door. He used to program, and I was just, like, he was a celebrity because I was like, whoa, look what he's doing, and how can you do that? And then I went off to college. +Well, I grew up in a small town, so we didn't really have many computer programs. I went to a college, and they said, "Hey, we have this one computer course you can either take it or test out." I was like; I'm not taking it; test out. I want to save that money. And I didn't realize how much I'll love computers and programming until later in life, late 20s, early 30s. And I wish I could have started early, so I totally agree with you about that. +VICTORIA: Like, I wish I would have time now to learn how to code. [laughs] Like, I still need to learn it. No, I think that...oh, would I advise? I don't know. You know what's funny? A recent guest said that if that had happened, they still wouldn't have believed themselves [laughs], right? Like, would you really believe someone telling you what to do? Like, you know, you try to make the best decision that you can at the time. +BRITTANY: I think it's fun to look back and see all the little things that happened that got you to where you are. So, like, two of, like, crucial things that happened for me. I was in school to become a genetic counselor, and I hated it. And so I had gotten an internship, and, like, that internship changed everything because it was like a day in the life as a genetic counselor, and I really did not like it at all. And so, I ended up dropping all my classes and moving into the business school. And so that was one thing that happened. +And then the second thing is, you know, I was working at a cowboy restaurant. [laughs] It was ridiculous. And I was getting ready to graduate school and just absolutely terrified about not having a job. I ended up getting this table of this company that was, like, having a business meeting, and we ended up chatting, and they were so wonderful. And they left me their business card, and, like, that ended up being my first job. +It's just the little micro-decisions that you make that, like, change your entire trajectory, which is really so cool. So you end up not really regretting anything, but you always just kind of look back and reflect, and you're like, what if I had given that table away? Or what if I hadn't been ambitious and, like, tried to get that internship? So just everything's an opportunity, right? +WILL: Yeah, I totally, totally agree with that. So you do roller derby, CrossFit, marathons, coding, your podcast. So you do a lot of self-care, which I don't think, especially in the tech world, we do enough self-care. I know I don't. I am horrible at it, trying to get better. What's your wind in your sails for that? Like, how do you keep going? Like, how do you stay disciplined with that? +BRITTANY: I think, for me, I feel better when I move my body. I make better decisions. I am more patient. I need to work out earlier in the day. Like, I am a morning person, and so it makes me feel good. And so then I go into work in a good mood. And I deal with people day to day, right? Like, I manage ten developers. And so it's also something that I can use to connect with my team as well. A lot of them also like to do physical things, and so that works out nicely. +In terms of nutrition, I definitely could be better. But I will say my partner and I take turns meal prepping our lunches. We both work from home. And so being able to, like, in between meetings run over and grab a box of actually good food to be able to eat lunch. We do, like, a meal service at night as well. +I don't know, like, you need to look out for you. Because while the belief is that other people are also looking out, nobody's going to look out for you like you are. And so you have to prioritize self-care and just making sure that you're getting those moments. And I agree with you, Will; sometimes, I'm absolutely terrible at setting up those processes so that way you don't fall through. +VICTORIA: I think there's a book that makes me think of it called, like, The Subtle Art of Not Giving a F*ck. [laughs] +BRITTANY: Yes. +VICTORIA: Yeah. +BRITTANY: Yes. +VICTORIA: Yep. And I think that's part of it, too. Like, there's a lot of pressure to be so high-performing and to do all the things for your family, and for your work and your personal life. But, at the end of the day, it's also okay to just sit around and do nothing [laughs] and, like, relax. +BRITTANY: Yeah, I've watched a lot of Drag Race, a lot. [laughs] +VICTORIA: Oh, awesome. Yes. What's your favorite season? +BRITTANY: Oh, season six, I would say. Season six is just so good. Are you watching All-Stars? +VICTORIA: I'm not right now. I'm actually...I usually binge-watch it at random times. So I'm not really caught up. But I have met a few of them at drag shows. I think I've met Milk. Is that [inaudible 44:27] +BRITTANY: Oh, wow. What a queen to have met. +VICTORIA: I know. +BRITTANY: That's amazing. [laughs] +VICTORIA: That was actually a very funny story. I'll tell you another time. [laughs] But yes. +BRITTANY: But honestly, like, Drag Race actually relates to engineering management for me because, you know, at my last job, I had two developers that I was struggling to connect with. And I realized that after stand-up, they were staying behind to talk about Drag Race, and I wanted to connect with them. And I was like, oh, I'll check out a couple of episodes and became so deeply addicted [laughs] that, like, I surpassed them in how much I loved it. +So, like, it is a fun, like, I've always thought about giving a conference talk where, like, each report that I have, like, one crazy thing that they do...well, not crazy but, like, one, you know, passion that they have and, like, trying it just to have something to relate to. Though I will say, I did manage somebody who really liked to jump out of planes, and that is just not in the cards for me. +VICTORIA: I love that too. I like when someone is really passionate about something. I'm like, okay, I'll give it a chance, at least once, you know. But I have some friends right now who are into freediving, and I'm not convinced [laughs] that I want to go try to hold my breath underwater. +BRITTANY: What in the world is freediving? +VICTORIA: It's diving underwater without oxygen. +BRITTANY: No. +VICTORIA: Yeah. Yeah. +BRITTANY: That's a big nope for me. +VICTORIA: And, like, hunting fish. So, like, they catch tuna and stuff. They're down there pew-pew and making sushi when they get back. +BRITTANY: Well, that actually sounds wonderful. But -- +VICTORIA: Yeah, I'm like, I will eat this. I will eat [laughs] whatever you catch. +BRITTANY: Yes, that's fair. +VICTORIA: Yeah. Like, I'm into the results but not...I might try some of the, like... a lot of it is, like, training your breath and being able to hold your breath and to stay calm because that's really the biggest problem. [laughs] I do rock climbing. I think that's enough. Like, that's -- +WILL: [laughs] +BRITTANY: That's pretty badass. +VICTORIA: Yeah. [laughs] +WILL: Yes. +BRITTANY: That is a very cool sport. +VICTORIA: Yeah. And, actually, you're mentioning how it was, like, you worked at a cowboy restaurant, and that was how you got your first connection to your job. And, like, I would go up to, like, my college climbing wall and be, like, I'm a rock climber; you should hire me. And [laughs] through that connection, I got my first referral to my first job in DC. And so, basically, my whole life revolves around it. [laughs] Nothing would happen without these little connections that you make. +I'm curious, Will, if you had a pivot point like that you can tell us about. +WILL: It was probably getting to tech because it was more of a hobby, and sometimes it's still a big hobby for me. So I will say either getting into tech or working out. So I try to work out with friends. So I used to play football. Everything was a group workout. So after football, it was very hard for me to work out because it was always a group workout. So after many, many years of finally realizing that, I try to work out in groups, with friends, and stuff like that. So that's probably the biggest thing for me is, like, working out in a group and having someone to hold me accountable. +BRITTANY: I love that. That's one reason...so I used to be a fitness instructor. I should reveal that as well. I used to be a BODYPUMP instructor. And the reason for that is just, like, again, I thought people that were fitness instructors were just, like, celebrities and absolute badasses. And so, I used to only go to group fitness class as well because I needed that accountability. And so, yeah, there's definitely days I wake up where I absolutely do not want to do anything. But having that accountability, it's just really awesome, and really, it makes sure that you follow through. +VICTORIA: That makes sense how you've practiced your voice and why your podcasting voice is so strong [laughter] because you're a fitness instructor. That's what is starting to add up for me. [laughter] +BRITTANY: You know what? The biggest challenge of being a fitness instructor is that they would send me the routines, and I would have to memorize them. And being able to memorize like, oh, I'm going to squat on the fourth count. And I'm going to do a clean and press on the eighth count. Oh my God, is that an algorithm -- +WILL: Yes. +BRITTANY: You know, for a pro...and I was like, is there any way that I could somehow automate? Like, part of me wanted to game it. I'm like, how do I game this so I don't have to spend so much time trying to memorize it? I mean, it was truly, truly challenging. And it was probably, like, the best brain teaser that I could have been doing because you're essentially putting on a live performance while working out. And everyone needs to be able to follow you and feel encouraged by you. It was just...it was a wild time. +WILL: [laughs] +VICTORIA: That sounds very demanding. Well, coming up to the end of our time here, is there anything else you would like to promote today? +BRITTANY: Ooh, no. We're currently not hiring at my job. Normally, that is something that I would promote. I would say if you are interested in checking out my podcast, it is The Ruby on Rails Podcast. We have plenty of things on there that are not Rails-specific. We've had conversations about, like, what's it like to get stock options at a company? What does the recruiting landscape currently look like? And then we also have, like, deep topics about, like, what's currently being merged into Ruby Core? So, really, we have a wide variety of topics. +So, if you find my voice somewhat pleasant, come on over; we'd be happy to have you. And, of course, you can listen to Victoria's episode, that will be linked up in the show notes. But this was such a pleasure. It was great spending time with you both, Will and Victoria. +WILL: Yeah, it was great. Loved chatting with you. +VICTORIA: Yes, thank you so much for joining. This was super fun. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +WILL: If you have any questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @will23larry. +VICTORIA: And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Brittany Martin. + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

--

+ +

Brittany Martin is an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers and is the Co-host of The Ruby on Rails Podcast.

+ +

Victoria and Will talk to Brittany about the multitude of stuff she's interested in, including Roller Derby, and gives the story of how she found herself co-hosting the show. She says knowing what your brand is and what listeners should expect from listening to you is super important, and she gives her opinion on what it means to be in the Ruby on Rails Community.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Brittany Martin, an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers. She is the Co-host of The Ruby on Rails Podcast, almost five years running. And she plays roller derby for Steel City Roller Derby under the pseudonym, catch this, Merge Conflict. She is based in Pittsburgh, Pennsylvania. Brittany, thank you for joining us.

+ +

BRITTANY: I am so thrilled to be on here. I have been listening to Giant Robots for years. So it's an absolute honor to be on the show today.

+ +

VICTORIA: Yes, thank you so much for joining us. And I met you at RailsConf this year. And, at the time, you had a boot on your foot. So, I have to ask you, are you healed? Are you recovered? Are you walking around again?

+ +

BRITTANY: This is such a good question. When I was between jobs in March, I was, you know, having these two weeks, I had a whole list of things that I was going to be doing. You know, I was going to train, like, running and whatnot. And I had roller derby practice that first week, and I broke my ankle. And, you know, going into it, I had no idea what a blocker it was going to be. I was like, oh, this is minor. It'll just take a couple of weeks to heal. No, it's been a long process.

+ +

But I can gleefully tell the listeners that I am out of the boot. I am walking. I am hopefully getting into a sports program next week that will train me up to get back into CrossFit, running, and skating. Though the really funny part is that I currently have another injury which is golfer's elbow. [laughs]

+ +

WILL: Oh, wow.

+ +

BRITTANY: Yeah. So I have that from overusing my arms. So I'm a little bit of a mess, but, you know, getting myself back together physically so I can get back on my skates.

+ +

WILL: So I know it's called golfer's elbow. But did you actually hurt it doing golf, or was it another sport you were playing?

+ +

BRITTANY: It's so funny that you ask that, Will, because whenever people ask me how I broke my ankle, I can be glamorous and be like, "Oh, it was roller derby."

+ +

WILL: [laughs]

+ +

BRITTANY: Like, it's a sexy injury, you know. I have a friend who just broke their ankle because they were dancing down the stairs and broke it, not as glamorous of a story, right?

+ +

WILL: [laughs]

+ +

BRITTANY: Golfer's elbow. I literally have no idea how this happened. I've never golfed a day in my life. So [laughter] it's my non-glamorous injury at this point.

+ +

WILL: Yeah, that's my background, sports medicine.

+ +

BRITTANY: Oh, great.

+ +

WILL: So it's interesting. Yeah, golfer's elbow, and I'm like, it's usually not golf that does it. So...[laughs]

+ +

BRITTANY: Yeah. So I said something to my PT. I was like, "Am I the first person to ever get golfer's elbow from, like, you know, fixing another injury?" And she's like, "Yes. Yes, you are." [laughs] And I was like, oh. [laughter] I really was expecting to get some reassurance that it wasn't me. But hey, what are you going to do?

+ +

WILL: There you go.

+ +

BRITTANY: I love the fact that you do love my roller derby name. As you can imagine, it is a beacon for finding the other programmers out on the track because they find it very funny. Nobody else finds it funny whatsoever. And people call me Merge for short, and some people think it's Marge. And I just allow it at this point. [laughter] My number is 200, and its status code okay. When you hit me, I get up okay until, apparently, I break my ankle. So...[laughter]

+ +

WILL: I love it. Because if you're a programmer, you're like, oh, she means business.

+ +

BRITTANY: Exactly.

+ +

WILL: Because merge conflicts...yeah, never fun.

+ +

BRITTANY: Exactly.

+ +

VICTORIA: I love that. I love finding other people who work in tech in other random activities. Like, I've recruited people from the climbing gym. [laughs] I'm like, oh, we're climbing together, and, oh, you're an engineer. That's interesting. [laughs] So it's great to, like, be with your community in different settings, so...

+ +

And you're just so involved in the Ruby on Rails Community. And I'm curious what really got you started into podcasting.

+ +

BRITTANY: Yeah, that's a really good question. So I'm a former product manager former MBA. So I didn't know how to code. I moved out to San Francisco because I thought that's what everyone did. If you wanted to be in tech, you moved out to San Francisco, and so I did that.

+ +

And I realized very quickly that it was going to be hard for me to be a product manager without knowing how to code. And so I went to a bootcamp at night, and I became a Ruby on Rails developer. So I wish I had, like, just a really cool story for why I chose Rails. It's literally the framework that was being taught by the bootcamp.

+ +

WILL: [laughs]

+ +

BRITTANY: But I'm so glad that it was because I love this community so much. But, you know, when I moved out to San Francisco, I just had my current partner at the time and my dog. I didn't have any friends. And so it was really the perfect time to learn how to code just because I was really able to focus. And I ended up having a lot of long walks at night, like, getting to the train, getting to the bus, and that's really when I got into listening to podcasts. I'm not a huge music person, which is kind of weird. I really...I deeply love podcasts.

+ +

And so I just kind of glommed on to a bunch of podcasts like Giant Robots, CodeNewbie, Bike Shed. I figured if I listened to all the things that I wanted to be, like, osmosis would just happen, and I would just start learning the things because I was actively learning about how to code. And I thought just listening to those concepts would really help. And really what ended up happening is those people that I was listening to, like, to me, they became celebrities to me. Like, I don't care about regular celebrities. [laughter] I care about people within these communities that I care so much about.

+ +

And so, you know, a couple of years into that, I was still very much devoted to listening to podcasts. I trained for my first marathon listening to podcasts. And I was listening to The Ruby on Rails Podcast, and, at the time, Kyle Daigle had taken over the show. And he had decided, in order to spice things up on the show, he was going to bring co-hosts on that he was going to rotate through. So, every couple of weeks, you would come on as a co-host, and you would drive the conversation with things that were going on in your life.

+ +

And, at the time, you know, there wasn't a lot of women, female representation in podcasts. I felt that I was doing interesting things. I was working at a non-profit doing ticketing for the Broadway Symphony and opera, like, in Rails. So I felt like I was always working in Rails, and I thought I could provide some useful insight. So I reached out to Kyle. I must have been very ambitious that day because I reached out and I said, "Hey, how about bringing me on as a co-host?" And he said, "Yeah, absolutely. Like, that would be great."

+ +

And so I came on as one of the regular co-hosts on The Ruby on Rails Podcast, which I should have been flying high, right? Like, this is exactly what I wanted. I got to become like one of my own celebrities, right? Well, Kyle got really busy. At the time, I believe it's when Microsoft was acquiring GitHub. And Kyle still works at GitHub today. Kyle is amazing. He's their COO now.

+ +

But the podcast kind of went dormant for a couple of months. It was my big opportunity. I really loved, you know, being on a podcast. I had done a couple of episodes. So I reached out to Kyle and said, "Hey, is there any chance you would give me the podcast?" And he said, "Absolutely." And he signed over everything to me, [laughter] which was really scary because I was taking over a podcast that had been around, at that time, it had been around for at least ten years, hundreds of episodes deep. It was on its own network. It was on the 5by5 Network at the time. So it had sponsors and expectations.

+ +

And so, really, I had to learn everything from the get-go. Like, I made up my own episode plans. I made up my own questions, like, how to do ad reads, how to edit, how to upload to the hosting platform like; that was entirely on me. And, you know, we can talk more about how the podcast has evolved over those years. But yeah, long story now made short, that is how I got my start in podcasting.

+ +

WILL: That's actually really amazing that that's how it got started and everything. Let's go back to when you first started. What was your feelings like? You say it was a lot to take on. Can you dig deeper in that and tell us more about that? Because I think I felt the same way. I think we've been doing this for about a year now. It's scary, let's be honest. It's scary jumping on a podcast and sharing who you are and what you're doing. So, can you tell us more about that?

+ +

BRITTANY: Absolutely. I think one thing is just knowing what is your brand and, you know, what listeners should expect from listening to you because this is a podcast that had been around for ten years. You know, it had changed formats several times. It was an interview-style podcast at one point. At one point, it was a bunch of co-hosts that would just meet every week to talk out what was going on. And so I really needed to take a moment and kind of look over the metrics of the episodes.

+ +

Like, I have that marketing background. I have that product background. So I wanted to know, like, what's actually working? Like, what do listeners want to listen to? And I also, like, kind of pored through all the reviews of the podcast. I'm like, did people even notice that this podcast went offline? Like, what's the current ecosystem? How many podcasts are out there in the Ruby and Rails space?

+ +

And so what I started doing is I wanted to create, like, a safe environment in order to start the podcast over again. So what I did is I did interview-style podcasts with my friends, people that would tolerate me, you know, making mistakes, knowing that I was probably...I am a terrible editor. And so bringing those people on to have just genuine conversations with. And then really just tried to pick up the listenership of the podcast because I'm basically waving my arms saying, "Hey, folks. Like, The Ruby on Rails Podcast is back. I'm here as your host. And, like, we are here to stay. Like, I want this to be a mainstay in the community."

+ +

VICTORIA: That's great. So you started to apply those concepts from your product background. And I'm curious what you found in how the business of the podcast really works.

+ +

BRITTANY: Yeah, I learned a lot, and we can talk about the transition. So, when I came on to the 5by5 Ruby on Rails Podcast, at the time, this was back in 2018. The podcast was being managed by 5by5, which is, like, a long-standing podcast network. They're still around, but they're much smaller than they used to be.

+ +

So, like, all of the sponsorship and the episode management was being handled by them. And so I didn't have a lot of insight into that part of the podcast. What I did have insight into is, like, what content is performing well? And what is the audience reaction to what we're putting out there? Like, how is the listenership coming back and whatnot?

+ +

Now, one thing that did happen over the course of me managing The Ruby on Rails Podcast is we decided to take the podcast independent at one point, you know, 5by5 was starting to wind down. And so, back in 2021, I reached out to 5by5 and said, "Hey, I genuinely really love this podcast. I want to be able to take it to a different platform, you know, have it go independent. But it's really important to me that I'm able to hold on to the current subscribers that I have."

+ +

I think we all know that, like, if you rebrand something and it's a totally different RSS feed, it's really hard to get people to move over, especially if they're using something that makes podcast listening really easy like Apple Podcasts, you know, you subscribe. You get new episodes, and you just hit play. And so they were extremely willing to work with me.

+ +

And so, we ended up taking the podcast independent. 5by5 created the hosting platform Fireside. And so we moved the podcast over to Fireside, and that was, like, a very seamless transition. But it was a moment in time where, you know, I was kind of questioning. We're no longer 5by5. It was the 5by5 Ruby on Rails Podcast. What do we call it? And so I genuinely had that moment where I was like, I could be really clever with the name. But then I stepped back, and I was like, no, everyone already refers to it as The Ruby on Rails Podcast. I'm just going to go with it. And so I think that ended up being a good decision.

+ +

We did change the logo of the show. We kept the same feed. And we had, like, the first episode on the new...we're not even on a network now; we're independent. The first episode of, like, the V2 of The Ruby on Rails Podcast is really what we called it. We just kind of explained the whole move. And I'm just deeply grateful all of our listeners just kind of followed along.

+ +

And I will say the biggest boon to us moving is that we did get a professional editor. And so, like, the quality of the episodes went up, which is the best money that you can spend. Get yourself a professional editor. I cannot stress that enough. Or you get really good at it yourself. But I know my own skills, and it was never going to be that way.

+ +

And so we took it independent. And I also decided to do a format change as well because it was a lot to do years of a podcast by myself. It was a lot. So I'm really glad Victoria and Will that you have each other. I think it's really great to have co-hosts. So I ended up moving the podcast. I now have a producing partner, and that's Mirror Placement. They do recruiting for Ruby on Rails, and they are wonderful partners.

+ +

But I also have three co-hosts that rotate through. I have Brian Mariani, who's a recruiter and founder of Mirror Placement. I have Jemma Issroff, who works on Ruby at Shopify. And I have Nick Schwaderer, who works on Rails infrastructure at Shopify. And that's been great because I rotate through those co-hosts. And I always have fresh content from them. But I also do the interview-style episodes as well, which Victoria was on recently.

+ +

VICTORIA: Yes. I agree 100%. Having a co-host like Will makes it so much more fun. And I cannot appreciate our editor Mandy Moore enough. And I agree on that advice. And I actually would add when people ask me if they should start a podcast, recommend having at least one other person [laughs] who you want to talk with about that topic for every week. But I wonder, if someone's thinking about starting a podcast, what would you have them consider as to whether or not it's worth it for them?

+ +

BRITTANY: I recently joined the podcasting subreddit on Reddit just because I was interested to see what kind of questions there were out there. Because when I got into podcasting, I was, like, oh, you just need to have a microphone and a way to record, and you just put it out there, and people are going to listen. It feels very much...like, you remember when, you know, the iPhone came out, and the App Store was empty? And then any app that you made was, like, amazing. Everybody would download it because there was nothing to download. We're now getting to a point with podcasts; there's just a lot out there.

+ +

My first bit of advice is, something that I said earlier, is make sure that you have an identity around your podcasts. Like, make sure that you are targeting a niche. It's fine if there are other people doing it, but do something that is uniquely you and do something that brings you joy. I really love talking to people in the Ruby on Rails Community. I have a special affinity for people who have never been on a podcast before. It's a lot of work.

+ +

So it's definitely worth it. I've gotten to meet a lot of my programming heroes because of it. And there are times where I've been very tempted to take a break and be able to step away from it. But, as of right now, it has been a good experience.

+ +

And what I often say whenever I open up my conference talks is the Ruby on Rails Community is my community contribution because I'm not someone who regularly contributes to open source. And so this is kind of, like, how I give back, and I get to meet a lot of amazing people.

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who's the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so a number of things that we pay attention to in maintenance are we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head.

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

WILL: I have a question around your listeners. I just want to take a second and just thank everyone who listens to the podcast. We really appreciate you so much, so just thank you, thank you, thank you. Because if you don't have listeners, you don't have a podcast, like you said a second ago. And you went through so many changes. What's been your biggest win, and how do you continue winning with your listeners? And how do you engage with them?

+ +

BRITTANY: This is a fun answer because, actually, thoughtbot comes into play there. They did not pay me to say this. But one thing that The Bike Shed used to do is they used to go to RailsConf and RubyConf, and they would record episodes during the conference with various Ruby heroes in the community. This is going back to me seeing these people as celebrities. I just thought that was, like, the coolest thing. And, at the time, I couldn't afford to go to conferences like that. So being able to listen to those podcasts and get to hear that kind of content was really important to me.

+ +

And so, you know, eventually, that stopped being a thing at RubyConf and RailsConf. And two years ago, I reached out and said, "Hey, I really love those kinds of sessions. Is there any way that I could take the lead on bringing those sessions back?" And we did. So it took in the form of a podcast panel at these different conferences where we would bring in different podcasts in the community. And we would have a panel. We would answer listener questions. It was genuinely a lot of fun.

+ +

So that is a proud moment for me. But it's a proud moment for me because it gave me the opportunity to reach out to podcasts in the community and say, "Hey, we're not competing here. We're friends. I want to record content with you. Like, please be part of my podcast community." And we have never been tighter.

+ +

So, like, we guest on each other's podcasts. We promote each other's podcasts on like Mastodon and Twitter. And it is just the most lovely thing ever because now we say things like, oh, yeah, like, this podcast, like, that's our, like, sister podcast, or that's our brother podcast. Like, it's so cool that we, you know, rising tide raises all ships. That's exactly what's happening here in the Ruby podcast community.

+ +

VICTORIA: I like that familial sense within the different Ruby on Rails podcasts, and maybe even Giant Robots is a part of that. Like, are we a cousin or an uncle? [laughter] Who knows? But I was actually there when you recorded the episode live at RailsConf in Atlanta this year. Was that your favorite moment at RailsConf, or was it something else?

+ +

BRITTANY: Yeah, I would say that was my favorite moment at RailsConf. No matter how many times I meet Aaron Patterson, I am always, like, deeply intimidated by just how funny and intelligent he is. So having that excuse of reaching out to him and saying like, "Hey, will you please be on this podcast panel?" was so fun.

+ +

I deeply adore Irina Nazarova, and so having her on the panel as well was fun. And then just doing the wildcard of having the audience, like, vote in who was going to be the third panel was truly a risky move, Victoria. [laughs] But it ended up paying off, and it ended up generating some really fun content for us.

+ +

VICTORIA: That's awesome. And I'm curious, you know, to talk a little bit more about the Ruby on Rails Community. And what do you see is the biggest challenge that it's facing right now?

+ +

BRITTANY: Oh, I have so many opinions on this. What a great question. [laughs] So I recently put together a talk proposal. It's currently waitlisted at a conference, but it is a talk that I very much want to give.

+ +

But one project that I would really like to work on is...between, I would say, 2013 and 2015, Ruby on Rails was definitely the number one framework that was being taught in bootcamps. And I'm really curious about what happened to all those people. I'm one of them. I learned Ruby on Rails in 2014. I still believe that I'm in the Ruby on Rails Community, not only for the podcast, but I'm an engineering manager for a company that writes Rails. So I believe I'm very much in the community. I'm so curious. Those people had so much potential of being seniors, principals, staff engineers, founders, engineering managers, architects. What happened to them? And did they stay in our community?

+ +

And then my second part of that is, what does it mean to be in the Ruby on Rails Community? Like, can you just listen to podcasts and be in the community? Do you need to actively write Ruby? I just find that whole thing very interesting. We're very obsessed with bringing new programmers into the Rails community, which I think is important. But what about the people who we taught Rails and left us? Like, is there an opportunity to bring them back?

+ +

WILL: It's funny you say that because I wasn't in that year range. I was a little later, like, 2017. And I learned Ruby on Rails, and then I went to JavaScript, you know, React, React Native, but I'm slowly inching back towards Ruby on Rails. My current project, I'm actually able to do some Ruby on Rails. And I'm really excited about it because, like you, that was my first language style that I learned, and I still love it. It is weird, but you always love your first language; I do, at least. So it's interesting that you said that because, yeah, I can say, for me, I'm slowly coming back towards it.

+ +

BRITTANY: Well, welcome back, Will. We're excited to have you.

+ +

I know that Node was such a heavy hitter when it came out, and it made a lot of sense. Like, we're going to teach you JavaScript on the front end. Oh, hey, we're going to also teach you JavaScript on the back end. You know, from the business side, I'm so curious whether or not Rails is still, like, one of the top three solutions in order to get an MVP off the ground. I don't have my thumb on that, so I'm very curious whether or not that's true or not.

+ +

VICTORIA: We certainly still tend to default to it at thoughtbot and to get MVPs off the ground. And we're still building a bunch of products every year with it. [laughs] So, Ruby on Rails and React together, especially if you're trying to iterate very quickly and test your assumptions about what you're building, I think that it's still a really fast and high-performing framework to use.

+ +

And it's interesting because there's a coding school in San Diego, Codecademy, which is really heavily involved, [chuckles] of course, in the Ruby on Rails Community, and they still teach it in their bootcamp. And one of the reasons they said to me was because it's one of the frameworks that gives you that holistic view of how everything works. [laughs]

+ +

Like, if you're new to tech, new to programming, in general, it's a very easy entry point to understanding. And I think that, of itself, when you're talking, like, the long-term viability of a framework, being able to hire people who can step in and understand what's going on in your codebase, that framework gives you a higher chance of that. [laughs] You know, that might point to your long-term success, too.

+ +

BRITTANY: Now, that's a really good point. Going back to the podcast as well, I think one thing that is not very well solved is just being able to make it sustainable as well because there are only so many sponsors out there. And it's really hard to prove ROI from sponsoring a podcast, right? Like, you can put links in the show notes. And you can hope people click on them and they convert. And you can be able to say, "Hey, this podcast is the reason."

+ +

But I've seen a lot of people start podcasts, and they think, well, if I put a bunch of episodes out and some people listen, then sponsors are going to knock down my door. I'm very lucky that I've had some long-term sponsors that have been able to keep the show sustainable. And I love seeing podcasts that come out of companies, you know, like thoughtbot, where you are being sustained by the company that, you know, is producing it. It's really hard to justify a podcast as a business unless you are already a major celebrity already, right?

+ +

VICTORIA: Yeah, we certainly don't do it for the money it makes us directly off the podcast. We do not.

+ +

[laughter]

+ +

BRITTANY: We do not.

+ +

VICTORIA: Yeah, I agree with that. And yeah, and even it's interesting as an advertising vehicle or marketing for your company. It can be great because, like, I feel with Giant Robots, we have so many listeners, like, loyal listeners over the years that we have this, like, direct way of communicating with a community that we care about. [laughs] But if you don't have...trying to, like, create that market and create that group of people from the ground up can be really tough. [laughs] And it takes a lot of time, a lot of investment, and a lot of effort, especially if you can't afford a professional editor. [laughs]

+ +

BRITTANY: Agreed. There's just some cost that I believe, like, the longer I do this, that are just, like, non-negotiable. There are some things that you can definitely have as optional. You know, for me, like, you have to have a good microphone. You have to have a professional editor. I pay for, like, my calendar scheduling software because I want to make that really, like, slick for my guests. Like, I used to...oh, I used to do the emails back and forth of, like, I'm available at Thursday at 2:00 or Friday at 3:00. Like, would one of these work for you? No. [laughs] It's just...that's a rotten experience.

+ +

For us, we do send, like, a thank you gift after being on the show, which has been, like, a nice add with having a producing partner that will back me on that. And I try to get to as many conferences as possible because I think it's a great vehicle to promote the podcast, but those end up all being optional. And all those things they do cost money.

+ +

VICTORIA: They do. And it's funny, like, yeah, getting out to the conferences, it's still the number one way to grow things is by meeting people in person [laughs], like, being real and human.

+ +

BRITTANY: Shocking, right? [laughs]

+ +

VICTORIA: Yeah. And I'm just kind of curious, like, in terms of how you picture what success means for your podcast. Like, what does that look like in the next six months or even, like, five years of hosting this podcast for you?

+ +

BRITTANY: Ooh, this is, like, the existential crisis question because I've been doing it for nearly five years. And I think the question is always going to be, you know, like, how long do I want to keep hosting the podcast? I will say the podcast is a positive influence on me in terms of making sure that I stay connected to people, that I keep writing code on the side so that way, I know what I'm talking about.

+ +

I have this whole imposter thing of, like, what if someone finds out I'm not a Ruby on Rails developer day to day and that I'm, like, actually thinking about business problems; I was, like, an engineering manager? You know, I'm going to get found out, and people are going to unsubscribe.

+ +

But in all seriousness, I think the success for this podcast is that it can go on without me. It's been around for that long already. And eventually, like, I want to have a succession plan where someones, I will say, like, multiple co-hosts to be able to take it over from there. It'll be rough to watch because, like, I really enjoy, you know, my current era because I feel like the podcast has gone through different eras. I really do enjoy it. But, at some point, it's just not going to make sense in terms of my professional goals. Do you feel the same?

+ +

VICTORIA: Yes. But we're only a year in. So I feel like I'm still...[laughter] I feel like I'm still new to hosting. And I'm like, oh, I've already recorded, like, 30 episodes or something. [laughs]

+ +

There's been a lot of change. And we're always thinking about, like, how do we make it better? What do we do? And trying to figure out how do we really get the most out of it for ourselves. But I feel the same way that it's just one of the more fun things that I do at thoughtbot [laughs]. And it gives me that chance to reach out to people and start conversations that I otherwise would not have had. So I really appreciate it. I don't know what you think, Will.

+ +

WILL: No, I totally agree with you. I love meeting new people. And I love meeting the diverse group of people that we have on the podcast. I love that just, like, how did you get here? Like, what makes you keep at it? Like, you've been at it for five years. What makes you keep at it? Just those questions like that I really love.

+ +

For me personally, I think that I'm still in the growing phase of podcast hosting. Like, I can get better at this. I can get better at that. What else can I get better at? So I think that's where I'm at in this phase. But, like Victoria said, that's only a year in. It's a different story when you're five years in.

+ +

BRITTANY: [laughs] It is. And one thing that I will do to make it more sustainable is, you know, like when you're running, you can either be sprinting, or you can be doing, like, a long endurance race. So with the podcast, I will book a bunch of podcasts in one week and say, this is my week to be recording. Like, I'm going to be very heads down on the podcast. I have other things going on in my life, but I'm like, this is a podcast week for me. And so I will record a bunch of episodes.

+ +

And that essentially gives me a couple of weeks where I can essentially take a break from the podcast. But guess what, listeners? Like, you're still getting new episodes. So you have no idea that I'm secretly taking a break. And I think that has also been a huge help.

+ +

Odd fact is that the five years that I've been hosting The Ruby on Rails Podcast, I am only missing from one episode. And the reason for that is that when I broke my ankle, [laughs] I called my co-host and was like, "Hey, I'm going into surgery tomorrow. We have this great episode being recorded tomorrow. I need you to take it." [laughs] And so that is the one episode that I am missing from, but I think it was a good lesson for me to know that I can step away and good content can still happen.

+ +

WILL: That's amazing. That's a pretty good record. [laughs]

+ +

BRITTANY: Or it might be obsessive, Will. I don't know.

+ +

[laughter]

+ +

WILL: Let me ask you this, what does success look like for you personally - roller derby, your full-time job? What does success look like for you in those areas in six months or a couple of years?

+ +

BRITTANY: Oh, that's a really great question. So I had stepped away from roller derby during the pandemic. And so I absolutely love fitness. I do CrossFit. I have a peloton. I have my own little home gym that I built during the pandemic that I absolutely adore.

+ +

So, you know, success for me is continuing to invest in that self-care. I want to keep skating just because I'm that person. Everyone came to me, and they're like, "Oh, you broke your ankle. I bet you won't go back to a roller derby." And I was like, oh, you think I won't? You think I won't go back? [laughs] So I'm headed back, but I'm going to be very careful about it. Because I've seen that, you know, your body can break, and you need to give yourself some rest.

+ +

But to answer, overall, like, I am an engineering manager now, and, you know, my goal is to eventually to get to that director level. And, in some ways, like, I can justify the podcast just because I do get the excuse to talk to people that have the job that I eventually want to have in my career. And so it helps in that regard as well.

+ +

VICTORIA: I think that's great, and I agree. That's also why I started getting involved in my community a lot, maybe 5 or 10 years ago. I was just like, here's opportunities to show my leadership and see how connected I am with other leaders. [laughs] It helps in that way. And on blading, I actually bought rollerblades recently just to go around the neighborhood.

+ +

BRITTANY: Yeesssss!

+ +

VICTORIA: And I got heckled by a woman [laughs] who said...I think she was being sincere, but she was like, "Bend your knees, and it's going to be okay." [laughter] Like, "Wear wrist guards next time." [laughter] I was like, maybe just my face was very try-hard in that moment. Because I have a lot of respect for people who can roller derby and get around on skates that fast. [laughs]

+ +

BRITTANY: Well, you know what's really funny? (I haven't even talked about this on my own podcast.) is that you know, I'm involved in the Roller Derby League. Obviously, I can't skate right now. And so I needed to find a committee so that I was able to still, you know, provide value to the league. And so, for some reason, I decided that skater resources would be a good idea.

+ +

So I'm essentially one of the people who is, you know, human resources within the Roller Derby League. And so when there are disputes or questions, or people have hurt feelings, like, they're coming to me, which is, you know, really funny because I do some of that as an engineering manager. So, like, to your point, Victoria, like, you know, I can do growth because they're way more extreme through roller derby, as you can imagine. And, in some ways, it ends up being good practice.

+ +

VICTORIA: Yes, that does sound like practice for higher-level management decisions, [laughs] so get ready. You're going to have issues and problems, and you're the one to solve it. So...

+ +

BRITTANY: Yeah. It's not like their problems don't matter. But, in some ways, it's almost like playing with monopoly money because, like, you know, you're not dealing with somebody's, like, livelihood. You're dealing with a sport that they do for fun. Like, trust me, no one is being paid to play roller derby. [laughs] It's a very expensive sport. There's a lot of equipment involved. And, Victoria, yes, you want to wear wristguards.

+ +

[laughter]

+ +

VICTORIA: Yes. I learned my lesson.

+ +

BRITTANY: You write code. You want to wear wrist guards.

+ +

[laughter]

+ +

VICTORIA: Right. And yeah, it's funny about things like that. Like, it's still very meaningful to people. Like, when I used to coach kids' climbing competitions, it's, like, the same thing. Like, it's rock climbing, everybody, but some people take it very seriously. [laughs] There's a lot of feelings involved. But, at the end of the day, it's nice to have that practice outside of the pressure of it being someone's livelihood and all of those details.

+ +

BRITTANY: Agreed.

+ +

VICTORIA: Well, let me ask you this question. It's one of our favorite ones. But if you could go back in time and give advice to your younger self, what would you say? And maybe it's at the beginning of the podcast or some other inflection point in your career.

+ +

BRITTANY: That is...oh, what a gift because hindsight is 20/20, isn't it? When I was going through school, I ended up getting a marketing degree because I really enjoyed business. I really liked, you know, the mechanics behind marketing. But, at the time, I had taken a couple of computer classes, and this was back in 2006. And, you know, I thought about double majoring in computer science and marketing. And someone gave me the terrible advice that computer programming was going to go away [laughs], and so it would be a waste of time to get that double degree in computer science. And so, you know, I'm very much a second career developer.

+ +

Like I noted earlier, you know, I was a PM. I was a non-technical product manager before I learned how to code, and so I learned how to code in my 30s. So I wish I could go back and get into programming way earlier. It would have changed the entire trajectory of my life. But part of me always wants to live out, like, that Black Mirror, like, what it would have been like if I had learned to code so much earlier. Would I have found Ruby? Maybe not.

+ +

WILL: I totally agree with that because the same story. I remember growing up, and I had a cousin that lived next door. He used to program, and I was just, like, he was a celebrity because I was like, whoa, look what he's doing, and how can you do that? And then I went off to college.

+ +

Well, I grew up in a small town, so we didn't really have many computer programs. I went to a college, and they said, "Hey, we have this one computer course you can either take it or test out." I was like; I'm not taking it; test out. I want to save that money. And I didn't realize how much I'll love computers and programming until later in life, late 20s, early 30s. And I wish I could have started early, so I totally agree with you about that.

+ +

VICTORIA: Like, I wish I would have time now to learn how to code. [laughs] Like, I still need to learn it. No, I think that...oh, would I advise? I don't know. You know what's funny? A recent guest said that if that had happened, they still wouldn't have believed themselves [laughs], right? Like, would you really believe someone telling you what to do? Like, you know, you try to make the best decision that you can at the time.

+ +

BRITTANY: I think it's fun to look back and see all the little things that happened that got you to where you are. So, like, two of, like, crucial things that happened for me. I was in school to become a genetic counselor, and I hated it. And so I had gotten an internship, and, like, that internship changed everything because it was like a day in the life as a genetic counselor, and I really did not like it at all. And so, I ended up dropping all my classes and moving into the business school. And so that was one thing that happened.

+ +

And then the second thing is, you know, I was working at a cowboy restaurant. [laughs] It was ridiculous. And I was getting ready to graduate school and just absolutely terrified about not having a job. I ended up getting this table of this company that was, like, having a business meeting, and we ended up chatting, and they were so wonderful. And they left me their business card, and, like, that ended up being my first job.

+ +

It's just the little micro-decisions that you make that, like, change your entire trajectory, which is really so cool. So you end up not really regretting anything, but you always just kind of look back and reflect, and you're like, what if I had given that table away? Or what if I hadn't been ambitious and, like, tried to get that internship? So just everything's an opportunity, right?

+ +

WILL: Yeah, I totally, totally agree with that. So you do roller derby, CrossFit, marathons, coding, your podcast. So you do a lot of self-care, which I don't think, especially in the tech world, we do enough self-care. I know I don't. I am horrible at it, trying to get better. What's your wind in your sails for that? Like, how do you keep going? Like, how do you stay disciplined with that?

+ +

BRITTANY: I think, for me, I feel better when I move my body. I make better decisions. I am more patient. I need to work out earlier in the day. Like, I am a morning person, and so it makes me feel good. And so then I go into work in a good mood. And I deal with people day to day, right? Like, I manage ten developers. And so it's also something that I can use to connect with my team as well. A lot of them also like to do physical things, and so that works out nicely.

+ +

In terms of nutrition, I definitely could be better. But I will say my partner and I take turns meal prepping our lunches. We both work from home. And so being able to, like, in between meetings run over and grab a box of actually good food to be able to eat lunch. We do, like, a meal service at night as well.

+ +

I don't know, like, you need to look out for you. Because while the belief is that other people are also looking out, nobody's going to look out for you like you are. And so you have to prioritize self-care and just making sure that you're getting those moments. And I agree with you, Will; sometimes, I'm absolutely terrible at setting up those processes so that way you don't fall through.

+ +

VICTORIA: I think there's a book that makes me think of it called, like, The Subtle Art of Not Giving a F*ck. [laughs]

+ +

BRITTANY: Yes.

+ +

VICTORIA: Yeah.

+ +

BRITTANY: Yes.

+ +

VICTORIA: Yep. And I think that's part of it, too. Like, there's a lot of pressure to be so high-performing and to do all the things for your family, and for your work and your personal life. But, at the end of the day, it's also okay to just sit around and do nothing [laughs] and, like, relax.

+ +

BRITTANY: Yeah, I've watched a lot of Drag Race, a lot. [laughs]

+ +

VICTORIA: Oh, awesome. Yes. What's your favorite season?

+ +

BRITTANY: Oh, season six, I would say. Season six is just so good. Are you watching All-Stars?

+ +

VICTORIA: I'm not right now. I'm actually...I usually binge-watch it at random times. So I'm not really caught up. But I have met a few of them at drag shows. I think I've met Milk. Is that [inaudible 44:27]

+ +

BRITTANY: Oh, wow. What a queen to have met.

+ +

VICTORIA: I know.

+ +

BRITTANY: That's amazing. [laughs]

+ +

VICTORIA: That was actually a very funny story. I'll tell you another time. [laughs] But yes.

+ +

BRITTANY: But honestly, like, Drag Race actually relates to engineering management for me because, you know, at my last job, I had two developers that I was struggling to connect with. And I realized that after stand-up, they were staying behind to talk about Drag Race, and I wanted to connect with them. And I was like, oh, I'll check out a couple of episodes and became so deeply addicted [laughs] that, like, I surpassed them in how much I loved it.

+ +

So, like, it is a fun, like, I've always thought about giving a conference talk where, like, each report that I have, like, one crazy thing that they do...well, not crazy but, like, one, you know, passion that they have and, like, trying it just to have something to relate to. Though I will say, I did manage somebody who really liked to jump out of planes, and that is just not in the cards for me.

+ +

VICTORIA: I love that too. I like when someone is really passionate about something. I'm like, okay, I'll give it a chance, at least once, you know. But I have some friends right now who are into freediving, and I'm not convinced [laughs] that I want to go try to hold my breath underwater.

+ +

BRITTANY: What in the world is freediving?

+ +

VICTORIA: It's diving underwater without oxygen.

+ +

BRITTANY: No.

+ +

VICTORIA: Yeah. Yeah.

+ +

BRITTANY: That's a big nope for me.

+ +

VICTORIA: And, like, hunting fish. So, like, they catch tuna and stuff. They're down there pew-pew and making sushi when they get back.

+ +

BRITTANY: Well, that actually sounds wonderful. But --

+ +

VICTORIA: Yeah, I'm like, I will eat this. I will eat [laughs] whatever you catch.

+ +

BRITTANY: Yes, that's fair.

+ +

VICTORIA: Yeah. Like, I'm into the results but not...I might try some of the, like... a lot of it is, like, training your breath and being able to hold your breath and to stay calm because that's really the biggest problem. [laughs] I do rock climbing. I think that's enough. Like, that's --

+ +

WILL: [laughs]

+ +

BRITTANY: That's pretty badass.

+ +

VICTORIA: Yeah. [laughs]

+ +

WILL: Yes.

+ +

BRITTANY: That is a very cool sport.

+ +

VICTORIA: Yeah. And, actually, you're mentioning how it was, like, you worked at a cowboy restaurant, and that was how you got your first connection to your job. And, like, I would go up to, like, my college climbing wall and be, like, I'm a rock climber; you should hire me. And [laughs] through that connection, I got my first referral to my first job in DC. And so, basically, my whole life revolves around it. [laughs] Nothing would happen without these little connections that you make.

+ +

I'm curious, Will, if you had a pivot point like that you can tell us about.

+ +

WILL: It was probably getting to tech because it was more of a hobby, and sometimes it's still a big hobby for me. So I will say either getting into tech or working out. So I try to work out with friends. So I used to play football. Everything was a group workout. So after football, it was very hard for me to work out because it was always a group workout. So after many, many years of finally realizing that, I try to work out in groups, with friends, and stuff like that. So that's probably the biggest thing for me is, like, working out in a group and having someone to hold me accountable.

+ +

BRITTANY: I love that. That's one reason...so I used to be a fitness instructor. I should reveal that as well. I used to be a BODYPUMP instructor. And the reason for that is just, like, again, I thought people that were fitness instructors were just, like, celebrities and absolute badasses. And so, I used to only go to group fitness class as well because I needed that accountability. And so, yeah, there's definitely days I wake up where I absolutely do not want to do anything. But having that accountability, it's just really awesome, and really, it makes sure that you follow through.

+ +

VICTORIA: That makes sense how you've practiced your voice and why your podcasting voice is so strong [laughter] because you're a fitness instructor. That's what is starting to add up for me. [laughter]

+ +

BRITTANY: You know what? The biggest challenge of being a fitness instructor is that they would send me the routines, and I would have to memorize them. And being able to memorize like, oh, I'm going to squat on the fourth count. And I'm going to do a clean and press on the eighth count. Oh my God, is that an algorithm --

+ +

WILL: Yes.

+ +

BRITTANY: You know, for a pro...and I was like, is there any way that I could somehow automate? Like, part of me wanted to game it. I'm like, how do I game this so I don't have to spend so much time trying to memorize it? I mean, it was truly, truly challenging. And it was probably, like, the best brain teaser that I could have been doing because you're essentially putting on a live performance while working out. And everyone needs to be able to follow you and feel encouraged by you. It was just...it was a wild time.

+ +

WILL: [laughs]

+ +

VICTORIA: That sounds very demanding. Well, coming up to the end of our time here, is there anything else you would like to promote today?

+ +

BRITTANY: Ooh, no. We're currently not hiring at my job. Normally, that is something that I would promote. I would say if you are interested in checking out my podcast, it is The Ruby on Rails Podcast. We have plenty of things on there that are not Rails-specific. We've had conversations about, like, what's it like to get stock options at a company? What does the recruiting landscape currently look like? And then we also have, like, deep topics about, like, what's currently being merged into Ruby Core? So, really, we have a wide variety of topics.

+ +

So, if you find my voice somewhat pleasant, come on over; we'd be happy to have you. And, of course, you can listen to Victoria's episode, that will be linked up in the show notes. But this was such a pleasure. It was great spending time with you both, Will and Victoria.

+ +

WILL: Yeah, it was great. Loved chatting with you.

+ +

VICTORIA: Yes, thank you so much for joining. This was super fun.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

WILL: If you have any questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brittany Martin.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

--

+ +

Brittany Martin is an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers and is the Co-host of The Ruby on Rails Podcast.

+ +

Victoria and Will talk to Brittany about the multitude of stuff she's interested in, including Roller Derby, and gives the story of how she found herself co-hosting the show. She says knowing what your brand is and what listeners should expect from listening to you is super important, and she gives her opinion on what it means to be in the Ruby on Rails Community.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Brittany Martin, an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers. She is the Co-host of The Ruby on Rails Podcast, almost five years running. And she plays roller derby for Steel City Roller Derby under the pseudonym, catch this, Merge Conflict. She is based in Pittsburgh, Pennsylvania. Brittany, thank you for joining us.

+ +

BRITTANY: I am so thrilled to be on here. I have been listening to Giant Robots for years. So it's an absolute honor to be on the show today.

+ +

VICTORIA: Yes, thank you so much for joining us. And I met you at RailsConf this year. And, at the time, you had a boot on your foot. So, I have to ask you, are you healed? Are you recovered? Are you walking around again?

+ +

BRITTANY: This is such a good question. When I was between jobs in March, I was, you know, having these two weeks, I had a whole list of things that I was going to be doing. You know, I was going to train, like, running and whatnot. And I had roller derby practice that first week, and I broke my ankle. And, you know, going into it, I had no idea what a blocker it was going to be. I was like, oh, this is minor. It'll just take a couple of weeks to heal. No, it's been a long process.

+ +

But I can gleefully tell the listeners that I am out of the boot. I am walking. I am hopefully getting into a sports program next week that will train me up to get back into CrossFit, running, and skating. Though the really funny part is that I currently have another injury which is golfer's elbow. [laughs]

+ +

WILL: Oh, wow.

+ +

BRITTANY: Yeah. So I have that from overusing my arms. So I'm a little bit of a mess, but, you know, getting myself back together physically so I can get back on my skates.

+ +

WILL: So I know it's called golfer's elbow. But did you actually hurt it doing golf, or was it another sport you were playing?

+ +

BRITTANY: It's so funny that you ask that, Will, because whenever people ask me how I broke my ankle, I can be glamorous and be like, "Oh, it was roller derby."

+ +

WILL: [laughs]

+ +

BRITTANY: Like, it's a sexy injury, you know. I have a friend who just broke their ankle because they were dancing down the stairs and broke it, not as glamorous of a story, right?

+ +

WILL: [laughs]

+ +

BRITTANY: Golfer's elbow. I literally have no idea how this happened. I've never golfed a day in my life. So [laughter] it's my non-glamorous injury at this point.

+ +

WILL: Yeah, that's my background, sports medicine.

+ +

BRITTANY: Oh, great.

+ +

WILL: So it's interesting. Yeah, golfer's elbow, and I'm like, it's usually not golf that does it. So...[laughs]

+ +

BRITTANY: Yeah. So I said something to my PT. I was like, "Am I the first person to ever get golfer's elbow from, like, you know, fixing another injury?" And she's like, "Yes. Yes, you are." [laughs] And I was like, oh. [laughter] I really was expecting to get some reassurance that it wasn't me. But hey, what are you going to do?

+ +

WILL: There you go.

+ +

BRITTANY: I love the fact that you do love my roller derby name. As you can imagine, it is a beacon for finding the other programmers out on the track because they find it very funny. Nobody else finds it funny whatsoever. And people call me Merge for short, and some people think it's Marge. And I just allow it at this point. [laughter] My number is 200, and its status code okay. When you hit me, I get up okay until, apparently, I break my ankle. So...[laughter]

+ +

WILL: I love it. Because if you're a programmer, you're like, oh, she means business.

+ +

BRITTANY: Exactly.

+ +

WILL: Because merge conflicts...yeah, never fun.

+ +

BRITTANY: Exactly.

+ +

VICTORIA: I love that. I love finding other people who work in tech in other random activities. Like, I've recruited people from the climbing gym. [laughs] I'm like, oh, we're climbing together, and, oh, you're an engineer. That's interesting. [laughs] So it's great to, like, be with your community in different settings, so...

+ +

And you're just so involved in the Ruby on Rails Community. And I'm curious what really got you started into podcasting.

+ +

BRITTANY: Yeah, that's a really good question. So I'm a former product manager former MBA. So I didn't know how to code. I moved out to San Francisco because I thought that's what everyone did. If you wanted to be in tech, you moved out to San Francisco, and so I did that.

+ +

And I realized very quickly that it was going to be hard for me to be a product manager without knowing how to code. And so I went to a bootcamp at night, and I became a Ruby on Rails developer. So I wish I had, like, just a really cool story for why I chose Rails. It's literally the framework that was being taught by the bootcamp.

+ +

WILL: [laughs]

+ +

BRITTANY: But I'm so glad that it was because I love this community so much. But, you know, when I moved out to San Francisco, I just had my current partner at the time and my dog. I didn't have any friends. And so it was really the perfect time to learn how to code just because I was really able to focus. And I ended up having a lot of long walks at night, like, getting to the train, getting to the bus, and that's really when I got into listening to podcasts. I'm not a huge music person, which is kind of weird. I really...I deeply love podcasts.

+ +

And so I just kind of glommed on to a bunch of podcasts like Giant Robots, CodeNewbie, Bike Shed. I figured if I listened to all the things that I wanted to be, like, osmosis would just happen, and I would just start learning the things because I was actively learning about how to code. And I thought just listening to those concepts would really help. And really what ended up happening is those people that I was listening to, like, to me, they became celebrities to me. Like, I don't care about regular celebrities. [laughter] I care about people within these communities that I care so much about.

+ +

And so, you know, a couple of years into that, I was still very much devoted to listening to podcasts. I trained for my first marathon listening to podcasts. And I was listening to The Ruby on Rails Podcast, and, at the time, Kyle Daigle had taken over the show. And he had decided, in order to spice things up on the show, he was going to bring co-hosts on that he was going to rotate through. So, every couple of weeks, you would come on as a co-host, and you would drive the conversation with things that were going on in your life.

+ +

And, at the time, you know, there wasn't a lot of women, female representation in podcasts. I felt that I was doing interesting things. I was working at a non-profit doing ticketing for the Broadway Symphony and opera, like, in Rails. So I felt like I was always working in Rails, and I thought I could provide some useful insight. So I reached out to Kyle. I must have been very ambitious that day because I reached out and I said, "Hey, how about bringing me on as a co-host?" And he said, "Yeah, absolutely. Like, that would be great."

+ +

And so I came on as one of the regular co-hosts on The Ruby on Rails Podcast, which I should have been flying high, right? Like, this is exactly what I wanted. I got to become like one of my own celebrities, right? Well, Kyle got really busy. At the time, I believe it's when Microsoft was acquiring GitHub. And Kyle still works at GitHub today. Kyle is amazing. He's their COO now.

+ +

But the podcast kind of went dormant for a couple of months. It was my big opportunity. I really loved, you know, being on a podcast. I had done a couple of episodes. So I reached out to Kyle and said, "Hey, is there any chance you would give me the podcast?" And he said, "Absolutely." And he signed over everything to me, [laughter] which was really scary because I was taking over a podcast that had been around, at that time, it had been around for at least ten years, hundreds of episodes deep. It was on its own network. It was on the 5by5 Network at the time. So it had sponsors and expectations.

+ +

And so, really, I had to learn everything from the get-go. Like, I made up my own episode plans. I made up my own questions, like, how to do ad reads, how to edit, how to upload to the hosting platform like; that was entirely on me. And, you know, we can talk more about how the podcast has evolved over those years. But yeah, long story now made short, that is how I got my start in podcasting.

+ +

WILL: That's actually really amazing that that's how it got started and everything. Let's go back to when you first started. What was your feelings like? You say it was a lot to take on. Can you dig deeper in that and tell us more about that? Because I think I felt the same way. I think we've been doing this for about a year now. It's scary, let's be honest. It's scary jumping on a podcast and sharing who you are and what you're doing. So, can you tell us more about that?

+ +

BRITTANY: Absolutely. I think one thing is just knowing what is your brand and, you know, what listeners should expect from listening to you because this is a podcast that had been around for ten years. You know, it had changed formats several times. It was an interview-style podcast at one point. At one point, it was a bunch of co-hosts that would just meet every week to talk out what was going on. And so I really needed to take a moment and kind of look over the metrics of the episodes.

+ +

Like, I have that marketing background. I have that product background. So I wanted to know, like, what's actually working? Like, what do listeners want to listen to? And I also, like, kind of pored through all the reviews of the podcast. I'm like, did people even notice that this podcast went offline? Like, what's the current ecosystem? How many podcasts are out there in the Ruby and Rails space?

+ +

And so what I started doing is I wanted to create, like, a safe environment in order to start the podcast over again. So what I did is I did interview-style podcasts with my friends, people that would tolerate me, you know, making mistakes, knowing that I was probably...I am a terrible editor. And so bringing those people on to have just genuine conversations with. And then really just tried to pick up the listenership of the podcast because I'm basically waving my arms saying, "Hey, folks. Like, The Ruby on Rails Podcast is back. I'm here as your host. And, like, we are here to stay. Like, I want this to be a mainstay in the community."

+ +

VICTORIA: That's great. So you started to apply those concepts from your product background. And I'm curious what you found in how the business of the podcast really works.

+ +

BRITTANY: Yeah, I learned a lot, and we can talk about the transition. So, when I came on to the 5by5 Ruby on Rails Podcast, at the time, this was back in 2018. The podcast was being managed by 5by5, which is, like, a long-standing podcast network. They're still around, but they're much smaller than they used to be.

+ +

So, like, all of the sponsorship and the episode management was being handled by them. And so I didn't have a lot of insight into that part of the podcast. What I did have insight into is, like, what content is performing well? And what is the audience reaction to what we're putting out there? Like, how is the listenership coming back and whatnot?

+ +

Now, one thing that did happen over the course of me managing The Ruby on Rails Podcast is we decided to take the podcast independent at one point, you know, 5by5 was starting to wind down. And so, back in 2021, I reached out to 5by5 and said, "Hey, I genuinely really love this podcast. I want to be able to take it to a different platform, you know, have it go independent. But it's really important to me that I'm able to hold on to the current subscribers that I have."

+ +

I think we all know that, like, if you rebrand something and it's a totally different RSS feed, it's really hard to get people to move over, especially if they're using something that makes podcast listening really easy like Apple Podcasts, you know, you subscribe. You get new episodes, and you just hit play. And so they were extremely willing to work with me.

+ +

And so, we ended up taking the podcast independent. 5by5 created the hosting platform Fireside. And so we moved the podcast over to Fireside, and that was, like, a very seamless transition. But it was a moment in time where, you know, I was kind of questioning. We're no longer 5by5. It was the 5by5 Ruby on Rails Podcast. What do we call it? And so I genuinely had that moment where I was like, I could be really clever with the name. But then I stepped back, and I was like, no, everyone already refers to it as The Ruby on Rails Podcast. I'm just going to go with it. And so I think that ended up being a good decision.

+ +

We did change the logo of the show. We kept the same feed. And we had, like, the first episode on the new...we're not even on a network now; we're independent. The first episode of, like, the V2 of The Ruby on Rails Podcast is really what we called it. We just kind of explained the whole move. And I'm just deeply grateful all of our listeners just kind of followed along.

+ +

And I will say the biggest boon to us moving is that we did get a professional editor. And so, like, the quality of the episodes went up, which is the best money that you can spend. Get yourself a professional editor. I cannot stress that enough. Or you get really good at it yourself. But I know my own skills, and it was never going to be that way.

+ +

And so we took it independent. And I also decided to do a format change as well because it was a lot to do years of a podcast by myself. It was a lot. So I'm really glad Victoria and Will that you have each other. I think it's really great to have co-hosts. So I ended up moving the podcast. I now have a producing partner, and that's Mirror Placement. They do recruiting for Ruby on Rails, and they are wonderful partners.

+ +

But I also have three co-hosts that rotate through. I have Brian Mariani, who's a recruiter and founder of Mirror Placement. I have Jemma Issroff, who works on Ruby at Shopify. And I have Nick Schwaderer, who works on Rails infrastructure at Shopify. And that's been great because I rotate through those co-hosts. And I always have fresh content from them. But I also do the interview-style episodes as well, which Victoria was on recently.

+ +

VICTORIA: Yes. I agree 100%. Having a co-host like Will makes it so much more fun. And I cannot appreciate our editor Mandy Moore enough. And I agree on that advice. And I actually would add when people ask me if they should start a podcast, recommend having at least one other person [laughs] who you want to talk with about that topic for every week. But I wonder, if someone's thinking about starting a podcast, what would you have them consider as to whether or not it's worth it for them?

+ +

BRITTANY: I recently joined the podcasting subreddit on Reddit just because I was interested to see what kind of questions there were out there. Because when I got into podcasting, I was, like, oh, you just need to have a microphone and a way to record, and you just put it out there, and people are going to listen. It feels very much...like, you remember when, you know, the iPhone came out, and the App Store was empty? And then any app that you made was, like, amazing. Everybody would download it because there was nothing to download. We're now getting to a point with podcasts; there's just a lot out there.

+ +

My first bit of advice is, something that I said earlier, is make sure that you have an identity around your podcasts. Like, make sure that you are targeting a niche. It's fine if there are other people doing it, but do something that is uniquely you and do something that brings you joy. I really love talking to people in the Ruby on Rails Community. I have a special affinity for people who have never been on a podcast before. It's a lot of work.

+ +

So it's definitely worth it. I've gotten to meet a lot of my programming heroes because of it. And there are times where I've been very tempted to take a break and be able to step away from it. But, as of right now, it has been a good experience.

+ +

And what I often say whenever I open up my conference talks is the Ruby on Rails Community is my community contribution because I'm not someone who regularly contributes to open source. And so this is kind of, like, how I give back, and I get to meet a lot of amazing people.

+ +

Mid-Roll Ad:

+ +

VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes.

+ +

From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance.

+ +

To receive a custom quote, contact sales@thoughtbot.com.

+ +

VICTORIA: And with me here, I have Richard Newman, who's the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right?

+ +

RICHARD: Hi, Victoria.

+ +

VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance?

+ +

RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth.

+ +

And so a number of things that we pay attention to in maintenance are we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application, we're responding to those sorts of changes as we go along.

+ +

And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you.

+ +

VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance?

+ +

RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance.

+ +

The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make.

+ +

And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application.

+ +

VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where suddenly, you need to make a very large investment and fixing whatever is broken.

+ +

RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it.

+ +

VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details.

+ +

RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down.

+ +

And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics.

+ +

VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head.

+ +

[laughter]

+ +

RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you.

+ +

VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So...

+ +

RICHARD: [chuckles] Absolutely.

+ +

VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon.

+ +

RICHARD: Yeah, it was a pleasure. Thank you.

+ +

WILL: I have a question around your listeners. I just want to take a second and just thank everyone who listens to the podcast. We really appreciate you so much, so just thank you, thank you, thank you. Because if you don't have listeners, you don't have a podcast, like you said a second ago. And you went through so many changes. What's been your biggest win, and how do you continue winning with your listeners? And how do you engage with them?

+ +

BRITTANY: This is a fun answer because, actually, thoughtbot comes into play there. They did not pay me to say this. But one thing that The Bike Shed used to do is they used to go to RailsConf and RubyConf, and they would record episodes during the conference with various Ruby heroes in the community. This is going back to me seeing these people as celebrities. I just thought that was, like, the coolest thing. And, at the time, I couldn't afford to go to conferences like that. So being able to listen to those podcasts and get to hear that kind of content was really important to me.

+ +

And so, you know, eventually, that stopped being a thing at RubyConf and RailsConf. And two years ago, I reached out and said, "Hey, I really love those kinds of sessions. Is there any way that I could take the lead on bringing those sessions back?" And we did. So it took in the form of a podcast panel at these different conferences where we would bring in different podcasts in the community. And we would have a panel. We would answer listener questions. It was genuinely a lot of fun.

+ +

So that is a proud moment for me. But it's a proud moment for me because it gave me the opportunity to reach out to podcasts in the community and say, "Hey, we're not competing here. We're friends. I want to record content with you. Like, please be part of my podcast community." And we have never been tighter.

+ +

So, like, we guest on each other's podcasts. We promote each other's podcasts on like Mastodon and Twitter. And it is just the most lovely thing ever because now we say things like, oh, yeah, like, this podcast, like, that's our, like, sister podcast, or that's our brother podcast. Like, it's so cool that we, you know, rising tide raises all ships. That's exactly what's happening here in the Ruby podcast community.

+ +

VICTORIA: I like that familial sense within the different Ruby on Rails podcasts, and maybe even Giant Robots is a part of that. Like, are we a cousin or an uncle? [laughter] Who knows? But I was actually there when you recorded the episode live at RailsConf in Atlanta this year. Was that your favorite moment at RailsConf, or was it something else?

+ +

BRITTANY: Yeah, I would say that was my favorite moment at RailsConf. No matter how many times I meet Aaron Patterson, I am always, like, deeply intimidated by just how funny and intelligent he is. So having that excuse of reaching out to him and saying like, "Hey, will you please be on this podcast panel?" was so fun.

+ +

I deeply adore Irina Nazarova, and so having her on the panel as well was fun. And then just doing the wildcard of having the audience, like, vote in who was going to be the third panel was truly a risky move, Victoria. [laughs] But it ended up paying off, and it ended up generating some really fun content for us.

+ +

VICTORIA: That's awesome. And I'm curious, you know, to talk a little bit more about the Ruby on Rails Community. And what do you see is the biggest challenge that it's facing right now?

+ +

BRITTANY: Oh, I have so many opinions on this. What a great question. [laughs] So I recently put together a talk proposal. It's currently waitlisted at a conference, but it is a talk that I very much want to give.

+ +

But one project that I would really like to work on is...between, I would say, 2013 and 2015, Ruby on Rails was definitely the number one framework that was being taught in bootcamps. And I'm really curious about what happened to all those people. I'm one of them. I learned Ruby on Rails in 2014. I still believe that I'm in the Ruby on Rails Community, not only for the podcast, but I'm an engineering manager for a company that writes Rails. So I believe I'm very much in the community. I'm so curious. Those people had so much potential of being seniors, principals, staff engineers, founders, engineering managers, architects. What happened to them? And did they stay in our community?

+ +

And then my second part of that is, what does it mean to be in the Ruby on Rails Community? Like, can you just listen to podcasts and be in the community? Do you need to actively write Ruby? I just find that whole thing very interesting. We're very obsessed with bringing new programmers into the Rails community, which I think is important. But what about the people who we taught Rails and left us? Like, is there an opportunity to bring them back?

+ +

WILL: It's funny you say that because I wasn't in that year range. I was a little later, like, 2017. And I learned Ruby on Rails, and then I went to JavaScript, you know, React, React Native, but I'm slowly inching back towards Ruby on Rails. My current project, I'm actually able to do some Ruby on Rails. And I'm really excited about it because, like you, that was my first language style that I learned, and I still love it. It is weird, but you always love your first language; I do, at least. So it's interesting that you said that because, yeah, I can say, for me, I'm slowly coming back towards it.

+ +

BRITTANY: Well, welcome back, Will. We're excited to have you.

+ +

I know that Node was such a heavy hitter when it came out, and it made a lot of sense. Like, we're going to teach you JavaScript on the front end. Oh, hey, we're going to also teach you JavaScript on the back end. You know, from the business side, I'm so curious whether or not Rails is still, like, one of the top three solutions in order to get an MVP off the ground. I don't have my thumb on that, so I'm very curious whether or not that's true or not.

+ +

VICTORIA: We certainly still tend to default to it at thoughtbot and to get MVPs off the ground. And we're still building a bunch of products every year with it. [laughs] So, Ruby on Rails and React together, especially if you're trying to iterate very quickly and test your assumptions about what you're building, I think that it's still a really fast and high-performing framework to use.

+ +

And it's interesting because there's a coding school in San Diego, Codecademy, which is really heavily involved, [chuckles] of course, in the Ruby on Rails Community, and they still teach it in their bootcamp. And one of the reasons they said to me was because it's one of the frameworks that gives you that holistic view of how everything works. [laughs]

+ +

Like, if you're new to tech, new to programming, in general, it's a very easy entry point to understanding. And I think that, of itself, when you're talking, like, the long-term viability of a framework, being able to hire people who can step in and understand what's going on in your codebase, that framework gives you a higher chance of that. [laughs] You know, that might point to your long-term success, too.

+ +

BRITTANY: Now, that's a really good point. Going back to the podcast as well, I think one thing that is not very well solved is just being able to make it sustainable as well because there are only so many sponsors out there. And it's really hard to prove ROI from sponsoring a podcast, right? Like, you can put links in the show notes. And you can hope people click on them and they convert. And you can be able to say, "Hey, this podcast is the reason."

+ +

But I've seen a lot of people start podcasts, and they think, well, if I put a bunch of episodes out and some people listen, then sponsors are going to knock down my door. I'm very lucky that I've had some long-term sponsors that have been able to keep the show sustainable. And I love seeing podcasts that come out of companies, you know, like thoughtbot, where you are being sustained by the company that, you know, is producing it. It's really hard to justify a podcast as a business unless you are already a major celebrity already, right?

+ +

VICTORIA: Yeah, we certainly don't do it for the money it makes us directly off the podcast. We do not.

+ +

[laughter]

+ +

BRITTANY: We do not.

+ +

VICTORIA: Yeah, I agree with that. And yeah, and even it's interesting as an advertising vehicle or marketing for your company. It can be great because, like, I feel with Giant Robots, we have so many listeners, like, loyal listeners over the years that we have this, like, direct way of communicating with a community that we care about. [laughs] But if you don't have...trying to, like, create that market and create that group of people from the ground up can be really tough. [laughs] And it takes a lot of time, a lot of investment, and a lot of effort, especially if you can't afford a professional editor. [laughs]

+ +

BRITTANY: Agreed. There's just some cost that I believe, like, the longer I do this, that are just, like, non-negotiable. There are some things that you can definitely have as optional. You know, for me, like, you have to have a good microphone. You have to have a professional editor. I pay for, like, my calendar scheduling software because I want to make that really, like, slick for my guests. Like, I used to...oh, I used to do the emails back and forth of, like, I'm available at Thursday at 2:00 or Friday at 3:00. Like, would one of these work for you? No. [laughs] It's just...that's a rotten experience.

+ +

For us, we do send, like, a thank you gift after being on the show, which has been, like, a nice add with having a producing partner that will back me on that. And I try to get to as many conferences as possible because I think it's a great vehicle to promote the podcast, but those end up all being optional. And all those things they do cost money.

+ +

VICTORIA: They do. And it's funny, like, yeah, getting out to the conferences, it's still the number one way to grow things is by meeting people in person [laughs], like, being real and human.

+ +

BRITTANY: Shocking, right? [laughs]

+ +

VICTORIA: Yeah. And I'm just kind of curious, like, in terms of how you picture what success means for your podcast. Like, what does that look like in the next six months or even, like, five years of hosting this podcast for you?

+ +

BRITTANY: Ooh, this is, like, the existential crisis question because I've been doing it for nearly five years. And I think the question is always going to be, you know, like, how long do I want to keep hosting the podcast? I will say the podcast is a positive influence on me in terms of making sure that I stay connected to people, that I keep writing code on the side so that way, I know what I'm talking about.

+ +

I have this whole imposter thing of, like, what if someone finds out I'm not a Ruby on Rails developer day to day and that I'm, like, actually thinking about business problems; I was, like, an engineering manager? You know, I'm going to get found out, and people are going to unsubscribe.

+ +

But in all seriousness, I think the success for this podcast is that it can go on without me. It's been around for that long already. And eventually, like, I want to have a succession plan where someones, I will say, like, multiple co-hosts to be able to take it over from there. It'll be rough to watch because, like, I really enjoy, you know, my current era because I feel like the podcast has gone through different eras. I really do enjoy it. But, at some point, it's just not going to make sense in terms of my professional goals. Do you feel the same?

+ +

VICTORIA: Yes. But we're only a year in. So I feel like I'm still...[laughter] I feel like I'm still new to hosting. And I'm like, oh, I've already recorded, like, 30 episodes or something. [laughs]

+ +

There's been a lot of change. And we're always thinking about, like, how do we make it better? What do we do? And trying to figure out how do we really get the most out of it for ourselves. But I feel the same way that it's just one of the more fun things that I do at thoughtbot [laughs]. And it gives me that chance to reach out to people and start conversations that I otherwise would not have had. So I really appreciate it. I don't know what you think, Will.

+ +

WILL: No, I totally agree with you. I love meeting new people. And I love meeting the diverse group of people that we have on the podcast. I love that just, like, how did you get here? Like, what makes you keep at it? Like, you've been at it for five years. What makes you keep at it? Just those questions like that I really love.

+ +

For me personally, I think that I'm still in the growing phase of podcast hosting. Like, I can get better at this. I can get better at that. What else can I get better at? So I think that's where I'm at in this phase. But, like Victoria said, that's only a year in. It's a different story when you're five years in.

+ +

BRITTANY: [laughs] It is. And one thing that I will do to make it more sustainable is, you know, like when you're running, you can either be sprinting, or you can be doing, like, a long endurance race. So with the podcast, I will book a bunch of podcasts in one week and say, this is my week to be recording. Like, I'm going to be very heads down on the podcast. I have other things going on in my life, but I'm like, this is a podcast week for me. And so I will record a bunch of episodes.

+ +

And that essentially gives me a couple of weeks where I can essentially take a break from the podcast. But guess what, listeners? Like, you're still getting new episodes. So you have no idea that I'm secretly taking a break. And I think that has also been a huge help.

+ +

Odd fact is that the five years that I've been hosting The Ruby on Rails Podcast, I am only missing from one episode. And the reason for that is that when I broke my ankle, [laughs] I called my co-host and was like, "Hey, I'm going into surgery tomorrow. We have this great episode being recorded tomorrow. I need you to take it." [laughs] And so that is the one episode that I am missing from, but I think it was a good lesson for me to know that I can step away and good content can still happen.

+ +

WILL: That's amazing. That's a pretty good record. [laughs]

+ +

BRITTANY: Or it might be obsessive, Will. I don't know.

+ +

[laughter]

+ +

WILL: Let me ask you this, what does success look like for you personally - roller derby, your full-time job? What does success look like for you in those areas in six months or a couple of years?

+ +

BRITTANY: Oh, that's a really great question. So I had stepped away from roller derby during the pandemic. And so I absolutely love fitness. I do CrossFit. I have a peloton. I have my own little home gym that I built during the pandemic that I absolutely adore.

+ +

So, you know, success for me is continuing to invest in that self-care. I want to keep skating just because I'm that person. Everyone came to me, and they're like, "Oh, you broke your ankle. I bet you won't go back to a roller derby." And I was like, oh, you think I won't? You think I won't go back? [laughs] So I'm headed back, but I'm going to be very careful about it. Because I've seen that, you know, your body can break, and you need to give yourself some rest.

+ +

But to answer, overall, like, I am an engineering manager now, and, you know, my goal is to eventually to get to that director level. And, in some ways, like, I can justify the podcast just because I do get the excuse to talk to people that have the job that I eventually want to have in my career. And so it helps in that regard as well.

+ +

VICTORIA: I think that's great, and I agree. That's also why I started getting involved in my community a lot, maybe 5 or 10 years ago. I was just like, here's opportunities to show my leadership and see how connected I am with other leaders. [laughs] It helps in that way. And on blading, I actually bought rollerblades recently just to go around the neighborhood.

+ +

BRITTANY: Yeesssss!

+ +

VICTORIA: And I got heckled by a woman [laughs] who said...I think she was being sincere, but she was like, "Bend your knees, and it's going to be okay." [laughter] Like, "Wear wrist guards next time." [laughter] I was like, maybe just my face was very try-hard in that moment. Because I have a lot of respect for people who can roller derby and get around on skates that fast. [laughs]

+ +

BRITTANY: Well, you know what's really funny? (I haven't even talked about this on my own podcast.) is that you know, I'm involved in the Roller Derby League. Obviously, I can't skate right now. And so I needed to find a committee so that I was able to still, you know, provide value to the league. And so, for some reason, I decided that skater resources would be a good idea.

+ +

So I'm essentially one of the people who is, you know, human resources within the Roller Derby League. And so when there are disputes or questions, or people have hurt feelings, like, they're coming to me, which is, you know, really funny because I do some of that as an engineering manager. So, like, to your point, Victoria, like, you know, I can do growth because they're way more extreme through roller derby, as you can imagine. And, in some ways, it ends up being good practice.

+ +

VICTORIA: Yes, that does sound like practice for higher-level management decisions, [laughs] so get ready. You're going to have issues and problems, and you're the one to solve it. So...

+ +

BRITTANY: Yeah. It's not like their problems don't matter. But, in some ways, it's almost like playing with monopoly money because, like, you know, you're not dealing with somebody's, like, livelihood. You're dealing with a sport that they do for fun. Like, trust me, no one is being paid to play roller derby. [laughs] It's a very expensive sport. There's a lot of equipment involved. And, Victoria, yes, you want to wear wristguards.

+ +

[laughter]

+ +

VICTORIA: Yes. I learned my lesson.

+ +

BRITTANY: You write code. You want to wear wrist guards.

+ +

[laughter]

+ +

VICTORIA: Right. And yeah, it's funny about things like that. Like, it's still very meaningful to people. Like, when I used to coach kids' climbing competitions, it's, like, the same thing. Like, it's rock climbing, everybody, but some people take it very seriously. [laughs] There's a lot of feelings involved. But, at the end of the day, it's nice to have that practice outside of the pressure of it being someone's livelihood and all of those details.

+ +

BRITTANY: Agreed.

+ +

VICTORIA: Well, let me ask you this question. It's one of our favorite ones. But if you could go back in time and give advice to your younger self, what would you say? And maybe it's at the beginning of the podcast or some other inflection point in your career.

+ +

BRITTANY: That is...oh, what a gift because hindsight is 20/20, isn't it? When I was going through school, I ended up getting a marketing degree because I really enjoyed business. I really liked, you know, the mechanics behind marketing. But, at the time, I had taken a couple of computer classes, and this was back in 2006. And, you know, I thought about double majoring in computer science and marketing. And someone gave me the terrible advice that computer programming was going to go away [laughs], and so it would be a waste of time to get that double degree in computer science. And so, you know, I'm very much a second career developer.

+ +

Like I noted earlier, you know, I was a PM. I was a non-technical product manager before I learned how to code, and so I learned how to code in my 30s. So I wish I could go back and get into programming way earlier. It would have changed the entire trajectory of my life. But part of me always wants to live out, like, that Black Mirror, like, what it would have been like if I had learned to code so much earlier. Would I have found Ruby? Maybe not.

+ +

WILL: I totally agree with that because the same story. I remember growing up, and I had a cousin that lived next door. He used to program, and I was just, like, he was a celebrity because I was like, whoa, look what he's doing, and how can you do that? And then I went off to college.

+ +

Well, I grew up in a small town, so we didn't really have many computer programs. I went to a college, and they said, "Hey, we have this one computer course you can either take it or test out." I was like; I'm not taking it; test out. I want to save that money. And I didn't realize how much I'll love computers and programming until later in life, late 20s, early 30s. And I wish I could have started early, so I totally agree with you about that.

+ +

VICTORIA: Like, I wish I would have time now to learn how to code. [laughs] Like, I still need to learn it. No, I think that...oh, would I advise? I don't know. You know what's funny? A recent guest said that if that had happened, they still wouldn't have believed themselves [laughs], right? Like, would you really believe someone telling you what to do? Like, you know, you try to make the best decision that you can at the time.

+ +

BRITTANY: I think it's fun to look back and see all the little things that happened that got you to where you are. So, like, two of, like, crucial things that happened for me. I was in school to become a genetic counselor, and I hated it. And so I had gotten an internship, and, like, that internship changed everything because it was like a day in the life as a genetic counselor, and I really did not like it at all. And so, I ended up dropping all my classes and moving into the business school. And so that was one thing that happened.

+ +

And then the second thing is, you know, I was working at a cowboy restaurant. [laughs] It was ridiculous. And I was getting ready to graduate school and just absolutely terrified about not having a job. I ended up getting this table of this company that was, like, having a business meeting, and we ended up chatting, and they were so wonderful. And they left me their business card, and, like, that ended up being my first job.

+ +

It's just the little micro-decisions that you make that, like, change your entire trajectory, which is really so cool. So you end up not really regretting anything, but you always just kind of look back and reflect, and you're like, what if I had given that table away? Or what if I hadn't been ambitious and, like, tried to get that internship? So just everything's an opportunity, right?

+ +

WILL: Yeah, I totally, totally agree with that. So you do roller derby, CrossFit, marathons, coding, your podcast. So you do a lot of self-care, which I don't think, especially in the tech world, we do enough self-care. I know I don't. I am horrible at it, trying to get better. What's your wind in your sails for that? Like, how do you keep going? Like, how do you stay disciplined with that?

+ +

BRITTANY: I think, for me, I feel better when I move my body. I make better decisions. I am more patient. I need to work out earlier in the day. Like, I am a morning person, and so it makes me feel good. And so then I go into work in a good mood. And I deal with people day to day, right? Like, I manage ten developers. And so it's also something that I can use to connect with my team as well. A lot of them also like to do physical things, and so that works out nicely.

+ +

In terms of nutrition, I definitely could be better. But I will say my partner and I take turns meal prepping our lunches. We both work from home. And so being able to, like, in between meetings run over and grab a box of actually good food to be able to eat lunch. We do, like, a meal service at night as well.

+ +

I don't know, like, you need to look out for you. Because while the belief is that other people are also looking out, nobody's going to look out for you like you are. And so you have to prioritize self-care and just making sure that you're getting those moments. And I agree with you, Will; sometimes, I'm absolutely terrible at setting up those processes so that way you don't fall through.

+ +

VICTORIA: I think there's a book that makes me think of it called, like, The Subtle Art of Not Giving a F*ck. [laughs]

+ +

BRITTANY: Yes.

+ +

VICTORIA: Yeah.

+ +

BRITTANY: Yes.

+ +

VICTORIA: Yep. And I think that's part of it, too. Like, there's a lot of pressure to be so high-performing and to do all the things for your family, and for your work and your personal life. But, at the end of the day, it's also okay to just sit around and do nothing [laughs] and, like, relax.

+ +

BRITTANY: Yeah, I've watched a lot of Drag Race, a lot. [laughs]

+ +

VICTORIA: Oh, awesome. Yes. What's your favorite season?

+ +

BRITTANY: Oh, season six, I would say. Season six is just so good. Are you watching All-Stars?

+ +

VICTORIA: I'm not right now. I'm actually...I usually binge-watch it at random times. So I'm not really caught up. But I have met a few of them at drag shows. I think I've met Milk. Is that [inaudible 44:27]

+ +

BRITTANY: Oh, wow. What a queen to have met.

+ +

VICTORIA: I know.

+ +

BRITTANY: That's amazing. [laughs]

+ +

VICTORIA: That was actually a very funny story. I'll tell you another time. [laughs] But yes.

+ +

BRITTANY: But honestly, like, Drag Race actually relates to engineering management for me because, you know, at my last job, I had two developers that I was struggling to connect with. And I realized that after stand-up, they were staying behind to talk about Drag Race, and I wanted to connect with them. And I was like, oh, I'll check out a couple of episodes and became so deeply addicted [laughs] that, like, I surpassed them in how much I loved it.

+ +

So, like, it is a fun, like, I've always thought about giving a conference talk where, like, each report that I have, like, one crazy thing that they do...well, not crazy but, like, one, you know, passion that they have and, like, trying it just to have something to relate to. Though I will say, I did manage somebody who really liked to jump out of planes, and that is just not in the cards for me.

+ +

VICTORIA: I love that too. I like when someone is really passionate about something. I'm like, okay, I'll give it a chance, at least once, you know. But I have some friends right now who are into freediving, and I'm not convinced [laughs] that I want to go try to hold my breath underwater.

+ +

BRITTANY: What in the world is freediving?

+ +

VICTORIA: It's diving underwater without oxygen.

+ +

BRITTANY: No.

+ +

VICTORIA: Yeah. Yeah.

+ +

BRITTANY: That's a big nope for me.

+ +

VICTORIA: And, like, hunting fish. So, like, they catch tuna and stuff. They're down there pew-pew and making sushi when they get back.

+ +

BRITTANY: Well, that actually sounds wonderful. But --

+ +

VICTORIA: Yeah, I'm like, I will eat this. I will eat [laughs] whatever you catch.

+ +

BRITTANY: Yes, that's fair.

+ +

VICTORIA: Yeah. Like, I'm into the results but not...I might try some of the, like... a lot of it is, like, training your breath and being able to hold your breath and to stay calm because that's really the biggest problem. [laughs] I do rock climbing. I think that's enough. Like, that's --

+ +

WILL: [laughs]

+ +

BRITTANY: That's pretty badass.

+ +

VICTORIA: Yeah. [laughs]

+ +

WILL: Yes.

+ +

BRITTANY: That is a very cool sport.

+ +

VICTORIA: Yeah. And, actually, you're mentioning how it was, like, you worked at a cowboy restaurant, and that was how you got your first connection to your job. And, like, I would go up to, like, my college climbing wall and be, like, I'm a rock climber; you should hire me. And [laughs] through that connection, I got my first referral to my first job in DC. And so, basically, my whole life revolves around it. [laughs] Nothing would happen without these little connections that you make.

+ +

I'm curious, Will, if you had a pivot point like that you can tell us about.

+ +

WILL: It was probably getting to tech because it was more of a hobby, and sometimes it's still a big hobby for me. So I will say either getting into tech or working out. So I try to work out with friends. So I used to play football. Everything was a group workout. So after football, it was very hard for me to work out because it was always a group workout. So after many, many years of finally realizing that, I try to work out in groups, with friends, and stuff like that. So that's probably the biggest thing for me is, like, working out in a group and having someone to hold me accountable.

+ +

BRITTANY: I love that. That's one reason...so I used to be a fitness instructor. I should reveal that as well. I used to be a BODYPUMP instructor. And the reason for that is just, like, again, I thought people that were fitness instructors were just, like, celebrities and absolute badasses. And so, I used to only go to group fitness class as well because I needed that accountability. And so, yeah, there's definitely days I wake up where I absolutely do not want to do anything. But having that accountability, it's just really awesome, and really, it makes sure that you follow through.

+ +

VICTORIA: That makes sense how you've practiced your voice and why your podcasting voice is so strong [laughter] because you're a fitness instructor. That's what is starting to add up for me. [laughter]

+ +

BRITTANY: You know what? The biggest challenge of being a fitness instructor is that they would send me the routines, and I would have to memorize them. And being able to memorize like, oh, I'm going to squat on the fourth count. And I'm going to do a clean and press on the eighth count. Oh my God, is that an algorithm --

+ +

WILL: Yes.

+ +

BRITTANY: You know, for a pro...and I was like, is there any way that I could somehow automate? Like, part of me wanted to game it. I'm like, how do I game this so I don't have to spend so much time trying to memorize it? I mean, it was truly, truly challenging. And it was probably, like, the best brain teaser that I could have been doing because you're essentially putting on a live performance while working out. And everyone needs to be able to follow you and feel encouraged by you. It was just...it was a wild time.

+ +

WILL: [laughs]

+ +

VICTORIA: That sounds very demanding. Well, coming up to the end of our time here, is there anything else you would like to promote today?

+ +

BRITTANY: Ooh, no. We're currently not hiring at my job. Normally, that is something that I would promote. I would say if you are interested in checking out my podcast, it is The Ruby on Rails Podcast. We have plenty of things on there that are not Rails-specific. We've had conversations about, like, what's it like to get stock options at a company? What does the recruiting landscape currently look like? And then we also have, like, deep topics about, like, what's currently being merged into Ruby Core? So, really, we have a wide variety of topics.

+ +

So, if you find my voice somewhat pleasant, come on over; we'd be happy to have you. And, of course, you can listen to Victoria's episode, that will be linked up in the show notes. But this was such a pleasure. It was great spending time with you both, Will and Victoria.

+ +

WILL: Yeah, it was great. Loved chatting with you.

+ +

VICTORIA: Yes, thank you so much for joining. This was super fun.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

WILL: If you have any questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brittany Martin.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pje3HA6q + + ]]> + + Will Larry + Victoria Guido + Brittany Martin + + + 483: Honeycomb.io with Charity Majors + https://podcast.thoughtbot.com/483 + 99c2286f-3a41-40d3-94bf-074d8838dab6 + Thu, 13 Jul 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Charity Majors is Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. + +Victoria talks to Charity about observability, her technical background and decision to start Honeycomb.io, thoughts about the whole ops SRE profession, and things that surprised her along her journey of building a company around observability as a concept. + 40:46 + no + + + Charity Majors is Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. +Victoria and Will talk to Charity about observability, her technical background and decision to start Honeycomb.io, thoughts about the whole ops SRE profession, and things that surprised her along her journey of building a company around observability as a concept. +Honeycomb (https://www.honeycomb.io/) +Follow Honeycomb on Facebook (https://www.facebook.com/honeycombio), Twitter (https://twitter.com/honeycombio), Youtube (https://www.youtube.com/channel/UCty8KGQ3oAP0MQQmLIv7k0Q), or LinkedIn (https://www.linkedin.com/company/honeycomb.io/). +Follow Charity Majors on LinkedIn (https://www.linkedin.com/in/charity-majors/) or Twitter (https://twitter.com/mipsytipsy), or visit her website (https://charity.wtf/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your other host, Will Larry. And with us today is Charity Majors, Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. Charity, thank you for joining us. How are you doing? +CHARITY: Thanks for having me. I'm a little bit crunchy from a [laughs] long flight this morning. But I'm very happy to be home in San Francisco and happy to be talking to you. +VICTORIA: Wonderful. And, Charity, I looked at your profile and noticed that you're a fan of whiskey. And I thought I might ask you just to get us started here, like, what's your favorite brand? +CHARITY: Oh, goodness, that's like asking me to choose my favorite child if I had children. [laughter]. You know, I used to really be into the peaty scotches, the Islays, in particular. But lately, I've been more of a bourbon kick. Of course, everybody loves Pappy Van Winkle, George T. Stagg; impossible to find now, but it's so, so good. You know, if it's high-proof and single barrel, I will probably drink it. +VICTORIA: That sounds great. Yeah, I tend to have the same approach. And, like, people ask me if I like it, and I like all of them. [laughter] I don't [inaudible 01:21] that I didn't like. [laughs] +CHARITY: [inaudible 01:23] tongue sting? Then I'm in. [laughs] +VICTORIA: Yeah, [inaudible 01:26]. +WILL: See, I'm the opposite. I want something smooth. I'm a fruity drink type of guy. I'm just going, to be honest. +CHARITY: There's no shame in that. +WILL: No shame here. [laughs] Give me a margarita, and you have a happy Will for life. [laughs] +VICTORIA: We'll have to get you to come out and visit San Diego for some margaritas, Will. That's -- +CHARITY: Oh yeah. +VICTORIA: Yeah, it's the place to be. Yeah, we do more of a bourbon drink in our house, like bourbon soda. That's usually what we make, like, my own custom simple syrup, and mix it with a little bourbon and soda water. And that's what we do for a cool down at the end of the day sometimes, yeah. Well, awesome. +Let's see. So, Charity, why don't you just tell me a little more about Honeycomb? What is it? +CHARITY: Well, it's a startup that hasn't failed yet, so... [laughs] to my own shock. [laughs] We're still around seven and a half years in. And I say that just so much joking. Like, you're not really supposed to say this as a founder, but, like, I 100% thought we were going to fail from the beginning. But we haven't yet, and we just got more money. So we'll be around for a while. +We kind of pioneered the whole concept of observability, which now doesn't really mean anything at all. Everybody and their mother is like, well, I do observability, too. But back when we started talking about it, it was kind of a little bit revolutionary, I guess in that, you know, we started talking about how important it is to have high cardinality data in your systems. You really can't debug without it. +And the fact that our systems are getting just astronomically more complex, and yet, we're still trying to debug it with these tools based on, you know, the metric data type [laughs] defined since the '70s when space was incredibly rare and expensive. And now space is incredibly cheap, but we should be wasteful with it so we can understand our incredibly complex systems. So that's us. +We really try to empower software engineers to own their own code in production. For a long time, it was like, all of the tools for you to understand your software were really written for low-level ops people because they speak the language of, like, RAM, and disks, and CPU, which you shouldn't have to understand that in order to be able to understand I just deployed something, what went wrong? +WILL: I love the honesty because there are so many founders that I'll talk to, and I'm like, okay, you're very successful. But did you really expect this to be what it is today? Did you really expect to survive? Because, like, just some of their ideas, I'm like, it's brilliant, but if I was with you back in the day, I'd be like, it ain't going to work. It's not going to work. [laughs] +CHARITY: Yeah. And I feel like the VC culture really encourages delusion, just, like, self-delusion, like, this delusive thinking. You're supposed to, like, broadcast just, like, rock-solid confidence in yourself and your ideas at all time. And I think that only sociopaths do that. [laughs] I don't want to work for anyone who's that confident in themselves or their idea. +Because I'm showing my own stripes, I guess, you know, I'm a reliability engineer. I wake up in the morning; I'm like, what's wrong with the day? That's just how my brain works. But I feel like I would rather work with people who are constantly scanning the horizon and being like, okay, what's likely to kill us today? Instead of people who are just like, I am right. [laughs] You know? +VICTORIA: Yeah. And I can relate that back to observability by thinking how, you know, you can have an idea about how your system is supposed to work, and then there's the way that it actually works. [laughs] +CHARITY: Oh my God. +VICTORIA: Right? +CHARITY: Yes. It's so much that. +VICTORIA: Maybe you can tell us just a little bit more about, like, what is observability? Or how would you explain that to someone who isn't necessarily in it every day? +CHARITY: I would explain it; I mean, it depends on who your audience is, of course. But I would explain it like engineers spend all day in their IDEs. And they come to believe that that's what software is. But software is not lines of code. Software is those lines of code running in production with real users using it. That's when software becomes real. +And, for too long, we've treated like that, like, an entirely different...well, it's written. [laughs] You know, for launch, I was like, well, it's ops' problem, as the meme says. But we haven't really gotten to a point yet where...I feel like when you're developing with observability; you should be instrumenting your code as you go with an eye towards your future self. How am I going to know if this is working or not? How am I going to know if this breaks? +And when you deploy it, you should then go and look at your code in production and look at it through the lens of the telemetry that you just wrote and ask yourself, is it doing what I expected it to? Does anything else look weird? Because the cost of finding and fixing bugs goes up exponentially from the moment that you write them. It's like you type a bug; you backspace. Cool, good for you. That's the fastest you can fix it. The next fastest is if you find it when you're running tests. But tests are only ever going to find the things you could predict were going to fail or that have already failed. +The first real opportunity that you have to see if your code really works or not is right after you've deployed it, but only if you've given yourself the telemetry to do so. Like, the idea of just merging your code, like walking out the door or merging your code and waiting to get paged or to get [laughs] escalated to this is madness. This should be such an artifact of the battle days when dev writes, and ops runs it. That doesn't work, right? +Like, in the beginning, we had software engineers who wrote code and ran that code in production, and that's how things should be. You should be writing code and running code in production. And the reason I think we're starting to see that reality emerge again is because our systems have gotten so complicated. We kind of can't not because you can't really run your code as a black box anymore. You can't ignore what's on the inside. You have to be able to look at the code in order to be able to run it effectively. +And conversely, I don't think you could develop good code unless you're constantly exposing yourself to the consequences of that code. It lets you know when it breaks, that whole feedback loop that completely severed when we had dev versus ops. And we're slowly kind of knitting it together again. But, like, that's what's at the heart of that incredibly powerful feedback loop. It's the heart of all software engineering is, instrumenting your code and looking at it and asking yourself, is it doing what I expected it to do? +WILL: That's really neat. You said you're a reliability engineer. What's your background? Tell me more about it because you're the CTO of Honeycomb. So you have some technical background. What does that look like? +CHARITY: Yeah, well, I was a music major and then a serial dropout. I've never graduated from anything, ever. And then, I worked at startups in Silicon Valley. Nothing you'd ever...well, I worked at Linden Lab for a few years and some other places. +But honestly, the reason I started Honeycomb was because...so I worked at Parse. I was the infrastructure lead at Parse; rest in peace. It got acquired by Facebook. And when I was leaving Facebook, it was the only time in my life that I'd ever had a pedigree. Well, I've actually been an ops engineer my entire career. When I was leaving Facebook, I had VCs going, "Would you like some money to do something? Because you're coming from Facebook, so you must be smart." +On the one hand, that was kind of offensive. And on the other hand, like, I kind of felt the obligation to just take the money and run, like, on behalf of all dropouts, of women, and queers everywhere. Just, you know, how often...am I ever going to get this chance again? No, I'm not. So, good. +VICTORIA: Yes, I will accept your money. [laughs] +CHARITY: Yeah, right? +VICTORIA: I will take it. And I'm not surprised that you were a music major. I've met many, I would say, people who are active in social media about DevOps, and then it turns out they were a theater major, [laughs] or music, or something different. And they kind of naturally found their way. +CHARITY: The whole ops SRE profession has historically been a real magnet for weirdo people, weird past, people who took very non-traditional. So it's always been about tinkering, just understanding systems. And there hasn't been this high bar for formal, you know, knowledge that you need just to get your first job. I feel like this is all changing. And it makes me kind of...I understand why it's changing, and it also makes me kind of sad. +VICTORIA: So I think you have a quote about, you know, working on infrastructure teams that everything comes back to databases. +CHARITY: [laughs] +VICTORIA: I wonder if you could expand on that. +CHARITY: I've been an accidental DBA my entire career. I just always seemed to be the one left holding the bag. [laughs] We were playing musical chairs. I just feel like, you know, as you're moving up the stack, you can get more and more reckless. As you move down the stack, the closer you get to, like, bits on disk, the more conservative you have to be, the more blast radius your mistakes could have. +Like, shit changes all the time in JavaScript land. In database land, we're still doing CRUD operators, like, since Stonebreaker did it in the '70s. We're still doing very fundamental stuff. I love it, though, because, I don't know, it's such a capsule of computers at large, which is just that people have no idea how much shit breaks. [laughs] Stuff breaks all the time. And the beauty of it is that we keep going. It's not that things don't break. You have no idea how much stuff is broken in your stack right now. But we find ways to resolve it after the fact. +I just think that data is so fascinating because it has so much gravity. I don't know, I could keep going, but I feel like you get the point. I just think it's really fun. I think danger is fun, I think. It might not surprise you to learn that I, too, was diagnosed with ADHD in the past couple of years. I feel like this is another strand that most DevOps, SRE types have in common, which is just [laughs] highly motivated in a good way by panic. [laughs] +WILL: I love that you said you love danger because I feel like that is right in your wheelhouse. Like, you have to love danger to be in that field because it's predictable. You're the one that's coming in and putting out the fires when everyone sometimes they're running for the window. Like you said, like, you got caught holding the bag. So that's really neat. +This is a big question for me, especially for being an engineer, a dev, do you find that product and design teams understand and see the value in SRE? +CHARITY: Oooh. These types of cultural questions are always so difficult for me to gauge whether or not my sample is representative of the larger population. Because, in my experience, you know, ops teams typically rule the roost, like, they get final say over everything. But I know that that's not typically true. Like, throughout the industry, like, ops teams kind of have a history of being kind of kicked around. +I think that they do see the value because everybody can see when it breaks. But I think that they mostly see the value when it breaks. I think that it takes a rare, farsighted product team to be able to consent to giving, like, investments all along in the kinds of improvements that will pay off later on instead of just pouring all of the resources into fast fixes and features and feature, feature, feature. +And then, of course, you know, you slowly grind to a halt as a team because you're just amassing surface area. You're not paying down your tech debt. And I think it's not always clear to product and design leaders how to make those investments in a way that actually benefits them instead of it just being a cost center. You know, it's just something that's always a break on them instead of actually enabling them to move faster. +WILL: Yeah, yeah. And I can definitely see that being an engineer dev. I'm going to change it a little bit. And I'm going to ask, Victoria, since you're the managing director of that team, how do you feel about that question? Do you feel that's the same thing, or what's your observation of that? +VICTORIA: I think Charity is, like, spot on because it does depend on the type of organization that you're working in, the hierarchy, and who gets priority over budget and things like that. And so the interesting thought for me coming from federal IT organizations into more commercial and startup organizations is that there is a little bit of a disconnect. And we started to ask our designers and developers like, "Well, have you thought much about, like, what happens when this fails?" [laughs] And especially -- +CHARITY: Great question. +VICTORIA: Yeah, like, when you're dealing with, like, healthcare startups or with bank startups and really thinking through all the ways it could go wrong. Is it a new pathway? Which I think is exciting for a lot of people. And I'm curious, too, Charity, like with Honeycomb, was there things that surprised you in your journey of discovery about, you know, building a company about observability and what people wanted out of this space? +CHARITY: Oh my goodness. [laughs] Was anything not a surprise? I mean, [laughs] yeah, absolutely. You're a director of what team? +VICTORIA: I'm a managing director of our Mission Control team. +CHARITY: Oooh. +VICTORIA: Which is our platform engineering, and DevOps, and SRE team. +CHARITY: Now, does your platform engineering team have product managers? +VICTORIA: I think it might be me. [laughs] +CHARITY: Aha. +VICTORIA: It might be me. And we have a team lead, and our CTO is actually our acting development director. So he's really leading the development of that project platform. +CHARITY: When I was in New York the last couple of days, I just gave a talk at KubeCon about the Perils, Pitfalls, and Pratfalls of Platform Engineering, just talking about all of the ways that platform teams accidentally steer themselves into the ditch. +One of the biggest mistakes that people make in that situation is not running the platform team like a product team, you know, having a sort of, like, if we build it, they will come sort of a mentality towards the platform that they're building internally for their engineers, and not doing the things like, you know, discovery or finding out like, am I really building, you know, the most important thing, you know, that people need right now? +And it's like, I didn't learn those skills as an engineer. Like, in the infrastructure land, we didn't learn how to work with product people. We didn't learn how to work with designers. And I feel like the biggest piece of career advice that I give, you know, people like me now, is learn how to work with product and like a product org. +I'm curious, like, what you're observing in your realm when it comes to this stuff. Like, how much like a product org do you work? +VICTORIA: Oh, I agree 100%. So I've actually been interested in applying our platform project to the thoughtbot Incubator Program. [laughs] +CHARITY: Mmm. +VICTORIA: So they have this method for doing market strategy, and user interviews, and all of that...exactly what you're saying, like, run it like a product. So I want them to help me with it. [laughs] +CHARITY: Nice. +VICTORIA: Yes, because I am also a managing director, and so we're managing a team and building business. And we also have this product or this open-source project, really. It's not...we don't necessarily want to be prescriptive with how we, as thoughtbot, tell people how to build their platforms. So with every client, we do a deep dive to see how is their dev team actually working? What are the pain points? What are the things we can do based on, like, you know, this collection of tools and knowledge that we have on what's worked for past clients that makes the most sense for them? +So, in that way, I think it is very customer-focused [laughs], right? And that's the motto we want to keep with. And I have been on other project teams where we just try to reproduce what worked for one client and to make that a product. And it doesn't always work [laughs] because of what you're saying. Like, you have to really...and especially, I think that just the diversity of the systems that we are building and have been built is kind of, like, breathtaking [laughs], you know. +CHARITY: Yeah. [chuckles] +VICTORIA: I'm sure you have some familiarity with that. +CHARITY: [laughs] +VICTORIA: But what did you really find in the market that worked for you right away, like, was, like, the problem that you were able to solve and start building within your business? +CHARITY: We did everything all wrong. So I had had this experience at Facebook, which, you know, at Parse, you know, we had all these reliability issues because of the architecture. What we were building was just fundamentally...as soon as any customer got big, like, they would take up all the resources in this shared, you know, tenancy thing, and the whole platform would go down. And it was so frustrating. And we were working on a rewrite and everything. Like, it was professionally humiliating for me as a reliability engineer to have a platform this bad at reliability. +And part of the issue was that you know, we had a million mobile apps, and it was a different app every time, different application...the iTunes Store, like, top five or something. And so the previous generation of tools and strategies like building dashboards and doing retros and being like, well, I'll make a dashboard so that I can find this problem next time immediately, like, just went out the window. Like, none of them would work because they were always about the last battle. And it was always something new. +And at one point, we started getting some datasets into this tool at Facebook called Scuba. It was butt ugly. Like, it was aggressively hostile to users. But it let us do one thing really well, which was slice and dice high cardinality dimensions in near real-time. And having the ability to do that to, like, break down by user ID, which is not possible with, you know, I don't know how familiar -- +I'll briefly describe high cardinality. So imagine you have a collection of 100 million users. And the highest possible cardinality would be a unique ID because, you know, social security number, very high cardinality. And something much lower cardinality would be like inches of height. And all of metrics and dashboards are oriented around low cardinality dimensions. If you have more than a couple hundred hosts, you can no longer tag your metrics with a host ID. It just falls apart. So being able to break down by, like, you know, one of a million app IDs. +It took...the amount of time it took for us to identify and find these brand-new problems, it dropped like a rock, like, from hours of opening it. We never even solved a lot of the problems that we saw. We just recovered. We moved on [laughs] with our day, dropped from that to, like, seconds or minutes. Like, it wasn't even an engineering problem anymore. It was like a support problem, you know, you just go click, click, click, click, click, oh, there it is. Just follow the trail of breadcrumbs. +That made such an impression on me. And when I was leaving, I was just like, I can't go back to not having something like this. I was so much less powerful as an engineer. It's just, like, it's unthinkable. So when we started Honeycomb, we were just, like, we went hands down, and we started building. We didn't want to write a database. We had to write a database because there was nothing out there that could do this. +And we spent the first year or two not even really talking to customers. When we did talk to customers, I would tell our engineers to ignore their feedback [laughs] because they were all telling us they wanted better metrics. And we're like, no, we're not doing metrics. +The first thing that we found we could kind of connect to real problems that people were looking for was that it was high cardinality. There were a few, not many; there were a few engineers out there Googling for high cardinality metrics. And those engineers found us and became our earliest customers because we were able to do breathtaking...from their perspective, they were like, we've been told this is impossible. We've been told that this can't be done. +Things like Intercom was able to start tagging other requests with, like, app ID and customer ID. And immediately started noticing things like, oh, this database that we were just about to have to, like, spend six months sharding and extending, oh, it turns out 80% of the queries in flight to this database are all coming from one customer who is paying us $200 a month, so maybe we shouldn't [laughs] do that engineering labor. Maybe we should just, you know, throttle this guy who is only paying us 200 bucks a month. Or just all these things you can't actually see until you can use this very, very special tool. And then once you can see that... +So, like, our first customers became rabid fans and vouched for us to investors, and this still blows people's minds to this day. It's an incredibly difficult thing to explain and describe to people, but once they see it on their own data, it clicks because everybody's run into this problem before, and it's really frustrating. +VICTORIA: Yeah, that's super interesting and a great example to illustrate that point of just, like, not really knowing what's going on in your system. And, you know, you mentioned just, like, certainly at scale, that's when you really, really need to have [laughs] data and insight into your systems. +CHARITY: Yeah. +VICTORIA: But one question I get a lot is, like, at what scale do you actually need to start worrying about SRE? [laughs] Which -- +CHARITY: SRE? +VICTORIA: Yeah, I'll let you answer that. Yeah, site reliability or even things like...like, everything under that umbrella like observability, like, you know, putting in monitoring and tracing and all this stuff. Sometimes people are just like, well, when do I actually have to care? [laughs] +CHARITY: I recognize this is, you know, coming from somebody who does this for a living, so, like, people can write it off all they want. But, like, the idea of developing without observability is just sad to me, like, from day one. This is not a tax. It's not something that slows you down or makes your lives worse. It's something that makes your lives better from day one. It helps you move more quickly, with more confidence. It helps you not make as many mistakes. It helps you... +Like, most people are used to interacting with their systems, which are just like flaming hairballs under their bed. Nobody has ever understood these systems. They certainly don't understand them. And every day, they ship more code that they don't understand, create systems that they've never understood. And then an alarm goes off, and everybody just, like, braces for impact because they don't understand them. +This is not the inevitable end state of computing. It doesn't have to be like this. You can have systems that are well-understood, that are tractable, that you could...it's just...it's so sad to me that people are like, oh God, when do I have to add telemetry? And I'm just like, how do you write software without telemetry? How do you have any confidence that the work you're doing is what you thought you were doing? You know, I just... +And, of course, if you're waiting to tack it on later, of course, it's not going to be as useful because you're trying to add telemetry for stuff you were writing weeks, or months, or years ago. The time to add it is while you're writing it. No one is ever going to understand your software as well as you do the moment that you're writing it. That's when you know your original intent. You know what you're trying to do. You know why you're trying to do it. You know what you tried that didn't work. You know, ultimately, what the most valuable pieces of data are. Why wouldn't you leave little breadcrumbs for yourself so that future you can find them? +You know, it's like...I just feel like this entire mental shift it can become just as much of a habit as like commenting your code or adding, you know, commenting in your pull request, you know. It becomes second nature, and reaching for it becomes second nature. You should have in your body a feeling of I'm not done until you've looked at your telemetry in production. That's the first moment that you can tell yourself, ah, yes, it probably does what I think it does, right? +So, like, this question it makes me sad. It gets me a little worked up because I feel like it's such a symptom of people who I know what their jobs are like based on that question, and it's not as good as it could be. Their jobs are much sadder and more confusing than it could be if they had a slightly different approach to telemetry. That's the observability bit. +But about SRE, very few ops engineers start companies, it seems, when I did, you know, I was one of three founding members. And the first thing I did was, of course, spin up an infrastructure and set up CI/CD and all this stuff. And I'm, like, feeling less useful than the others but, you know, doing my part. But that stuff that I spun up, we didn't have to hire an SRE for years, and when we did, it was pretty optional. And this is a system, you know, things trickle down, right? +Doing things right from the beginning and having them be clear and well-understood, and efficient, we were able to do so much with so few people. You know, we were landing, you know, hundreds of thousand-dollar deals with people who thought we had hundreds of employees. We had 12 engineers for the first almost five years, just 12 engineers. But, like, almost all of the energy that they put into the world went into moving the business forward, not fighting with the system, or thrashing the system, or trying to figure out bugs, or trying to track down things that were just, like, impossible to figure out. We waste so much time as engineers by trying to add this stuff in later. +So the actual answer to your question is, like, if you aren't lucky enough to have an ops co-founder, is as soon as you have real users. You know, I've made a career out of basically being the first engineer to join from infrastructure when the software engineers are starting to have real customers. Like, at Parse, they brought me in when they were about to do their alpha release. And they're like, whoa, okay, I guess we better have someone who knows how to run things. +And I came in, and I spent the next, you know, year or so just cleaning up shit that they had done, which wasn't terrible. But, you know, they just didn't really know what they were doing. So I kind of had to undo everything, redo it. And just the earlier, the better, right? It will pay off. +Now, that said, there is a real risk of over-engineering early. Companies they don't fail because they innovated too quickly; let's put it that way. They fail because they couldn't focus. They couldn't connect with their customers. They couldn't do all these things. And so you really do want to do just enough to get you to the next place so that you can put most of your effort into making product for your customers. +But yeah, it's so much easier to set yourself up with auto-deployment so that every CI/CD run automatically deploys your code to production and just maintain as you grow. That is so easy compared to trying to take, you know, a long, slow, you know, leaky deploy process and turn it into one that could auto-deploy safely after every commit. So yeah, do it early. And then maintain is the easiest way in the world to do this stuff. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +WILL: Correct me if I'm wrong, I think you said Facebook and mobile. Do you have, not experience with mobile but do you...does Honeycomb do anything in the mobile space? Because I feel like that portion is probably the most complicated for mobile, like, dealing with iOS and Android and everything that they're asking for. So... +CHARITY: We don't have mobile stuff at Honeycomb. Parse was a mobile Backend as a Service. So I went straight from doing all mobile all the time to doing no mobile at all. I also went from doing databases all the time to doing, you know...it's good career advice typically to find a niche and then stay in it, and I have not followed that advice. [laughter] I've just jumped from...as soon as I'm good at something, I start doing something else. +WILL: Let me ask you this, how come you don't see more mobile SRE or help in that area? +CHARITY: I think that you see lots of SREs for mobile apps, but they're on the back-end side. They're on the server side. So it's just not as visible. But even if you've got, like, a stack that's entirely serverless, you still need SRE. +But I think that the model is really shifting. You know, it used to be you hired an SRE team or an ops team to carry the pager for you and to take the alerts and to, like, buffer everything, and nowadays, that's not the expectation. That's not what good companies do. You know, they set up systems for their software engineers to own their code in production. But they need help because they're not experts in this, and that's where SRE types come in. Is that your experience? +WILL: Yeah, for the most part. Yeah, that is. +CHARITY: Yeah, I think that's very healthy. +VICTORIA: And I agree with that as well. And I'm going to take that clip of your reaction to that question about when you should start doing [laughter] observability and just play for everybody whenever someone asks [laughs] me that. I'm like, here's the answer. That's great. +CHARITY: I think a good metaphor for that is like, if you're buying a house and taking out a loan, the more of a down payment you can put down upfront, the lower that your monthly payments are going to be for the rest of your...you amortize that out over the next 20-30 years. The more you can do that, the better your life is going to be because interest rates are a bitch. +VICTORIA: It makes sense. And yeah, like, to your point earlier about when people actually do start to care about it is usually after something has broken in a traumatic way that can be really bad for your clients and, like, your legal [laughter] stance -- +CHARITY: That's true. +VICTORIA: As a company. +CHARITY: Facing stuff, yeah, is where people usually start to think about it. But, like, the less visible part, and I think almost the more important part is what it does to your velocity and your ability to execute internally. When you have a good, clean system that is well-tended that, you know, where the amount of time between when you're writing the code and when the code is in production, and you're looking at...when that is short and tight, like, no more than a couple of hours, like, it's a different job than if it takes you, like, days or weeks to deploy. Your changes get bashed up with other people's. +And, you know, like, you enter, like, the software development death spiral where, you know, it takes a while. So your diffs get even bigger, so code review takes even longer, so it takes even longer. And then your changes are all getting bashed up. And, you know, now you need a team to run deploys and releases. And now you need an SRE team to do the firefighting. +And, like, your systems are...the bigger it gets, the more complicated it gets, the more you're spending time just waiting on each other or switching contexts. You ever, like, see an app and been like, oh, that's a cool app? I wonder...they have 800 engineers at that company. And you're just like, what the hell are they all doing? Like, seriously, how does it take that many engineers to build this admittedly nice little product? +I guarantee you it's because their internal hygiene is just terrible. It takes them too long to deploy things. They've forgotten what they've written by the time it's out, so nobody ever goes and looks at it. So it's just like, it's becoming a hairball under your bed. Nobody's looking at it. It's becoming more and more mysterious to you. +Like, I have a rule of thumb which there's no mathematical science behind this, just experience. But it's a rule of thumb that says that if it takes you, you know, on the order of, say, a couple of hours tops to deploy your software, if it takes you that many engineers to build and own that product, well, if your deploys take on the order of days instead of hours, it will take you twice as many people [chuckles] to build and support that product. +And if it takes you weeks to deploy that product, it will take you twice as many again; if anything, that is an underestimate because it actually goes up exponentially, not linearly. But, like, we are so wasteful when it comes to people's time. It is so much easier for managers to go, uh, we're overloaded. Let's hire more people. For some reason, you can always get headcount when you can't actually get the discipline to say no to things or the people to work on internal tools to, like, shrink that gap between when you've written it and when it's live. +And just the waste, it just spirals out of control, man, and it's not good. And, you know, it should be such a fun, creative, fulfilling job where you spend your day solving puzzles for money and moving the business materially forward every day. And instead, how much of our time do we just sit here, like, twiddling our thumbs and waiting for the build to finish or waiting for code review [laughs] to get turned around? Or, you know, swapping projects and, like, trying to page all that context in your brain? Like, it's absurd, and this is not that hard of a problem to fix. +VICTORIA: Engineering should be fun, and it should be dangerous. That's what [laughs] I'm getting out of this -- +CHARITY: It should be fun, and it should be dangerous. I love that. +VICTORIA: Fun and dangerous. I like it. [laughs] And speaking of danger, I mean, maybe it's not dangerous, but what does success really look like for you at Honeycomb in the next six months or even in the next five years? +CHARITY: I find it much more easier to answer what failure would look like. +VICTORIA: You can answer that too if you like. [laughs] +CHARITY: [laughs] What would success look like? I mean, obviously, I have no desire to ever go through another acquisition, and I don't want to go out of business. So it'd be nice not to do either of those things, which means since we've taken VC money, IPO would be nice eventually. +But, like, ultimately, like, what motivates Christine and me and our entire company really is just, you know, we're engineers. We've felt this pain. We have seen that the world can be better. [laughs] We really just want to help, you know, move engineering into the current decade. +I feel like there are so many teams out there who hear me talk about this stuff. And they listen wistfully, and they're like, yeah, and they roll their eyes. They're like, yeah, you work in Silicon Valley, or yeah, but you work at a startup, or yeah...they have all these reasons why they don't get nice things. +We're just not good enough engineers is the one that breaks my heart the most because it's not true. Like, it has nothing to do...it has almost nothing to do with how good of an engineer you are. You have to be so much better of an engineer to deal with a giant hairball than with software that gets deployed, you know, within the hour that you can just go look at and see if it's working or not. +I want this to go mainstream. I want people...I want engineers to just have a better time at work. And I want people to succeed at what they're doing. And just...the more we can bring that kind of change to more and more people, the more successful I will feel. +VICTORIA: I really like that. And I think it's great. And it also makes me think I find that people who work in the DevOps space have a certain type of mentality sometimes, [laughs] like, it's about the greater community and, like, just making being at work better. And I also think it maybe makes you more willing to admit your failures [laughs] like you were earlier, right? +CHARITY: Probably. +VICTORIA: That's part of the culture. It's like, well, we messed up. [laughs] We broke stuff, and we're going to learn from it. +CHARITY: It's healthy. I'm trying to institute a rule where at all hands when we're doing different organizations giving an update every two weeks, where we talk two-thirds about our successes and things that worked great and one-third about things that just didn't work. Like, I think we could all stand to talk about our failures a lot more. +VICTORIA: Yeah, makes it a lot less scary, I think [laughs], right? +CHARITY: Yeah, yeah. It democratizes the feeling, and it genuinely...it makes me happy. It's like, that didn't work, great. Now we know not to do it. Of the infinite number of things that we could try, now we know something for real. I think it's exciting. And, I don't know, I think it's funny when things fail. And I think that if we can just laugh about it together... +You know, in every engineering org that I've ever worked at, out of all the teams, the ops types teams have always been the ones that are the most tightly bonded. They have this real, like, Band of Brothers type of sentiment. And I think it's because, you know, we've historically endured most of the pain. [laughs] But, like, that sense of, like, it's us against the system, that there is hilarity in failure. And, at the end of the day, we're all just monkeys, like, poking at electrical sockets is, I think...I think it's healthy. [laughs] +WILL: That's really neat. I love it. This is one of my favorite questions. What advice would you give yourself if you could go back in time? +CHARITY: I don't know. I think I'd just give myself a thumbs up and go; it's going to be all right. I don't know; I wouldn't... I don't think that I would try to alter the time continuum [laughs] in any way. But I had a lot of anxiety when I was younger about going to hell and all this stuff. And so I think...but anything I said to my future self, I wouldn't have believed anyway. So yeah, I respectfully decline the offer. +VICTORIA: That's fair. I mean, I think about that a lot too actually, like, I sometimes think like, well, if I could go back to myself a year ago and just -- +CHARITY: Yeah. I would look at me like I was stupid. +[laughter] +VICTORIA: That makes sense. It reminds me a little bit about what you said, though, like, doing SRE and everything upfront or the observability pieces and building it correctly in a way you can deploy fastly is like a gift to your future self. [laughs] +CHARITY: Yes, it is, with a bow. Yes, exactly. +VICTORIA: There you go. Well, all right. I think we are about ready to wrap up. Is there anything you would like to promote specifically? +CHARITY: We just launched this really cool little thing at Honeycomb. And you won't often hear me say the words cool and AI in proximity to each other, but we just launched this really dope little thing. It's a tool for using natural language to ask questions of your telemetry. So, if you just deployed something and you want to know, like, what's slow or did anything change, you can just ask it using English, and it does a ChatGPT thing and generates the right graphs for you. It's pretty sweet. +VICTORIA: That's really cool. So, if you have Honeycomb set up and working in your system and then you can just ask the little chatbot, "Hey, what's going on here?" +CHARITY: Yeah. What's the slowest endpoint? And it'll just tell you, which is great because I feel like I do not think graphically at all. My brain just really doesn't. So I have never been the person who's, like, creating dashboards or graphs. My friend Ben Hartshorne works with me, and he'll make the dashboards. And then I get up in the morning, and I bookmark them. And so we're sort of symbiotic. +But everyone can tweak a query, right? Once you have something that you know is, like, within spitting distance as the data you want, anyone can tweak it, but composing is really hard. So I feel like this really helps you get over that initial hurdle of, like, er, what do I break down by? What do I group by? What are the field names? You just ask it the question, and then you've got to click, click, click, and, like, get exactly what you want out of it. I think it's, like, a game changer. +VICTORIA: That sounds extremely cool. And we will certainly link to it in our show notes today. Thank you so much for being with us and spending the time, Charity. +CHARITY: Yeah, this was really fun. +VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you could find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Charity Majors. + + + Charity Majors is Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together.

+ +

Victoria and Will talk to Charity about observability, her technical background and decision to start Honeycomb.io, thoughts about the whole ops SRE profession, and things that surprised her along her journey of building a company around observability as a concept.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Charity Majors, Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. Charity, thank you for joining us. How are you doing?

+ +

CHARITY: Thanks for having me. I'm a little bit crunchy from a [laughs] long flight this morning. But I'm very happy to be home in San Francisco and happy to be talking to you.

+ +

VICTORIA: Wonderful. And, Charity, I looked at your profile and noticed that you're a fan of whiskey. And I thought I might ask you just to get us started here, like, what's your favorite brand?

+ +

CHARITY: Oh, goodness, that's like asking me to choose my favorite child if I had children. [laughter]. You know, I used to really be into the peaty scotches, the Islays, in particular. But lately, I've been more of a bourbon kick. Of course, everybody loves Pappy Van Winkle, George T. Stagg; impossible to find now, but it's so, so good. You know, if it's high-proof and single barrel, I will probably drink it.

+ +

VICTORIA: That sounds great. Yeah, I tend to have the same approach. And, like, people ask me if I like it, and I like all of them. [laughter] I don't [inaudible 01:21] that I didn't like. [laughs]

+ +

CHARITY: [inaudible 01:23] tongue sting? Then I'm in. [laughs]

+ +

VICTORIA: Yeah, [inaudible 01:26].

+ +

WILL: See, I'm the opposite. I want something smooth. I'm a fruity drink type of guy. I'm just going, to be honest.

+ +

CHARITY: There's no shame in that.

+ +

WILL: No shame here. [laughs] Give me a margarita, and you have a happy Will for life. [laughs]

+ +

VICTORIA: We'll have to get you to come out and visit San Diego for some margaritas, Will. That's --

+ +

CHARITY: Oh yeah.

+ +

VICTORIA: Yeah, it's the place to be. Yeah, we do more of a bourbon drink in our house, like bourbon soda. That's usually what we make, like, my own custom simple syrup, and mix it with a little bourbon and soda water. And that's what we do for a cool down at the end of the day sometimes, yeah. Well, awesome.

+ +

Let's see. So, Charity, why don't you just tell me a little more about Honeycomb? What is it?

+ +

CHARITY: Well, it's a startup that hasn't failed yet, so... [laughs] to my own shock. [laughs] We're still around seven and a half years in. And I say that just so much joking. Like, you're not really supposed to say this as a founder, but, like, I 100% thought we were going to fail from the beginning. But we haven't yet, and we just got more money. So we'll be around for a while.

+ +

We kind of pioneered the whole concept of observability, which now doesn't really mean anything at all. Everybody and their mother is like, well, I do observability, too. But back when we started talking about it, it was kind of a little bit revolutionary, I guess in that, you know, we started talking about how important it is to have high cardinality data in your systems. You really can't debug without it.

+ +

And the fact that our systems are getting just astronomically more complex, and yet, we're still trying to debug it with these tools based on, you know, the metric data type [laughs] defined since the '70s when space was incredibly rare and expensive. And now space is incredibly cheap, but we should be wasteful with it so we can understand our incredibly complex systems. So that's us.

+ +

We really try to empower software engineers to own their own code in production. For a long time, it was like, all of the tools for you to understand your software were really written for low-level ops people because they speak the language of, like, RAM, and disks, and CPU, which you shouldn't have to understand that in order to be able to understand I just deployed something, what went wrong?

+ +

WILL: I love the honesty because there are so many founders that I'll talk to, and I'm like, okay, you're very successful. But did you really expect this to be what it is today? Did you really expect to survive? Because, like, just some of their ideas, I'm like, it's brilliant, but if I was with you back in the day, I'd be like, it ain't going to work. It's not going to work. [laughs]

+ +

CHARITY: Yeah. And I feel like the VC culture really encourages delusion, just, like, self-delusion, like, this delusive thinking. You're supposed to, like, broadcast just, like, rock-solid confidence in yourself and your ideas at all time. And I think that only sociopaths do that. [laughs] I don't want to work for anyone who's that confident in themselves or their idea.

+ +

Because I'm showing my own stripes, I guess, you know, I'm a reliability engineer. I wake up in the morning; I'm like, what's wrong with the day? That's just how my brain works. But I feel like I would rather work with people who are constantly scanning the horizon and being like, okay, what's likely to kill us today? Instead of people who are just like, I am right. [laughs] You know?

+ +

VICTORIA: Yeah. And I can relate that back to observability by thinking how, you know, you can have an idea about how your system is supposed to work, and then there's the way that it actually works. [laughs]

+ +

CHARITY: Oh my God.

+ +

VICTORIA: Right?

+ +

CHARITY: Yes. It's so much that.

+ +

VICTORIA: Maybe you can tell us just a little bit more about, like, what is observability? Or how would you explain that to someone who isn't necessarily in it every day?

+ +

CHARITY: I would explain it; I mean, it depends on who your audience is, of course. But I would explain it like engineers spend all day in their IDEs. And they come to believe that that's what software is. But software is not lines of code. Software is those lines of code running in production with real users using it. That's when software becomes real.

+ +

And, for too long, we've treated like that, like, an entirely different...well, it's written. [laughs] You know, for launch, I was like, well, it's ops' problem, as the meme says. But we haven't really gotten to a point yet where...I feel like when you're developing with observability; you should be instrumenting your code as you go with an eye towards your future self. How am I going to know if this is working or not? How am I going to know if this breaks?

+ +

And when you deploy it, you should then go and look at your code in production and look at it through the lens of the telemetry that you just wrote and ask yourself, is it doing what I expected it to? Does anything else look weird? Because the cost of finding and fixing bugs goes up exponentially from the moment that you write them. It's like you type a bug; you backspace. Cool, good for you. That's the fastest you can fix it. The next fastest is if you find it when you're running tests. But tests are only ever going to find the things you could predict were going to fail or that have already failed.

+ +

The first real opportunity that you have to see if your code really works or not is right after you've deployed it, but only if you've given yourself the telemetry to do so. Like, the idea of just merging your code, like walking out the door or merging your code and waiting to get paged or to get [laughs] escalated to this is madness. This should be such an artifact of the battle days when dev writes, and ops runs it. That doesn't work, right?

+ +

Like, in the beginning, we had software engineers who wrote code and ran that code in production, and that's how things should be. You should be writing code and running code in production. And the reason I think we're starting to see that reality emerge again is because our systems have gotten so complicated. We kind of can't not because you can't really run your code as a black box anymore. You can't ignore what's on the inside. You have to be able to look at the code in order to be able to run it effectively.

+ +

And conversely, I don't think you could develop good code unless you're constantly exposing yourself to the consequences of that code. It lets you know when it breaks, that whole feedback loop that completely severed when we had dev versus ops. And we're slowly kind of knitting it together again. But, like, that's what's at the heart of that incredibly powerful feedback loop. It's the heart of all software engineering is, instrumenting your code and looking at it and asking yourself, is it doing what I expected it to do?

+ +

WILL: That's really neat. You said you're a reliability engineer. What's your background? Tell me more about it because you're the CTO of Honeycomb. So you have some technical background. What does that look like?

+ +

CHARITY: Yeah, well, I was a music major and then a serial dropout. I've never graduated from anything, ever. And then, I worked at startups in Silicon Valley. Nothing you'd ever...well, I worked at Linden Lab for a few years and some other places.

+ +

But honestly, the reason I started Honeycomb was because...so I worked at Parse. I was the infrastructure lead at Parse; rest in peace. It got acquired by Facebook. And when I was leaving Facebook, it was the only time in my life that I'd ever had a pedigree. Well, I've actually been an ops engineer my entire career. When I was leaving Facebook, I had VCs going, "Would you like some money to do something? Because you're coming from Facebook, so you must be smart."

+ +

On the one hand, that was kind of offensive. And on the other hand, like, I kind of felt the obligation to just take the money and run, like, on behalf of all dropouts, of women, and queers everywhere. Just, you know, how often...am I ever going to get this chance again? No, I'm not. So, good.

+ +

VICTORIA: Yes, I will accept your money. [laughs]

+ +

CHARITY: Yeah, right?

+ +

VICTORIA: I will take it. And I'm not surprised that you were a music major. I've met many, I would say, people who are active in social media about DevOps, and then it turns out they were a theater major, [laughs] or music, or something different. And they kind of naturally found their way.

+ +

CHARITY: The whole ops SRE profession has historically been a real magnet for weirdo people, weird past, people who took very non-traditional. So it's always been about tinkering, just understanding systems. And there hasn't been this high bar for formal, you know, knowledge that you need just to get your first job. I feel like this is all changing. And it makes me kind of...I understand why it's changing, and it also makes me kind of sad.

+ +

VICTORIA: So I think you have a quote about, you know, working on infrastructure teams that everything comes back to databases.

+ +

CHARITY: [laughs]

+ +

VICTORIA: I wonder if you could expand on that.

+ +

CHARITY: I've been an accidental DBA my entire career. I just always seemed to be the one left holding the bag. [laughs] We were playing musical chairs. I just feel like, you know, as you're moving up the stack, you can get more and more reckless. As you move down the stack, the closer you get to, like, bits on disk, the more conservative you have to be, the more blast radius your mistakes could have.

+ +

Like, shit changes all the time in JavaScript land. In database land, we're still doing CRUD operators, like, since Stonebreaker did it in the '70s. We're still doing very fundamental stuff. I love it, though, because, I don't know, it's such a capsule of computers at large, which is just that people have no idea how much shit breaks. [laughs] Stuff breaks all the time. And the beauty of it is that we keep going. It's not that things don't break. You have no idea how much stuff is broken in your stack right now. But we find ways to resolve it after the fact.

+ +

I just think that data is so fascinating because it has so much gravity. I don't know, I could keep going, but I feel like you get the point. I just think it's really fun. I think danger is fun, I think. It might not surprise you to learn that I, too, was diagnosed with ADHD in the past couple of years. I feel like this is another strand that most DevOps, SRE types have in common, which is just [laughs] highly motivated in a good way by panic. [laughs]

+ +

WILL: I love that you said you love danger because I feel like that is right in your wheelhouse. Like, you have to love danger to be in that field because it's predictable. You're the one that's coming in and putting out the fires when everyone sometimes they're running for the window. Like you said, like, you got caught holding the bag. So that's really neat.

+ +

This is a big question for me, especially for being an engineer, a dev, do you find that product and design teams understand and see the value in SRE?

+ +

CHARITY: Oooh. These types of cultural questions are always so difficult for me to gauge whether or not my sample is representative of the larger population. Because, in my experience, you know, ops teams typically rule the roost, like, they get final say over everything. But I know that that's not typically true. Like, throughout the industry, like, ops teams kind of have a history of being kind of kicked around.

+ +

I think that they do see the value because everybody can see when it breaks. But I think that they mostly see the value when it breaks. I think that it takes a rare, farsighted product team to be able to consent to giving, like, investments all along in the kinds of improvements that will pay off later on instead of just pouring all of the resources into fast fixes and features and feature, feature, feature.

+ +

And then, of course, you know, you slowly grind to a halt as a team because you're just amassing surface area. You're not paying down your tech debt. And I think it's not always clear to product and design leaders how to make those investments in a way that actually benefits them instead of it just being a cost center. You know, it's just something that's always a break on them instead of actually enabling them to move faster.

+ +

WILL: Yeah, yeah. And I can definitely see that being an engineer dev. I'm going to change it a little bit. And I'm going to ask, Victoria, since you're the managing director of that team, how do you feel about that question? Do you feel that's the same thing, or what's your observation of that?

+ +

VICTORIA: I think Charity is, like, spot on because it does depend on the type of organization that you're working in, the hierarchy, and who gets priority over budget and things like that. And so the interesting thought for me coming from federal IT organizations into more commercial and startup organizations is that there is a little bit of a disconnect. And we started to ask our designers and developers like, "Well, have you thought much about, like, what happens when this fails?" [laughs] And especially --

+ +

CHARITY: Great question.

+ +

VICTORIA: Yeah, like, when you're dealing with, like, healthcare startups or with bank startups and really thinking through all the ways it could go wrong. Is it a new pathway? Which I think is exciting for a lot of people. And I'm curious, too, Charity, like with Honeycomb, was there things that surprised you in your journey of discovery about, you know, building a company about observability and what people wanted out of this space?

+ +

CHARITY: Oh my goodness. [laughs] Was anything not a surprise? I mean, [laughs] yeah, absolutely. You're a director of what team?

+ +

VICTORIA: I'm a managing director of our Mission Control team.

+ +

CHARITY: Oooh.

+ +

VICTORIA: Which is our platform engineering, and DevOps, and SRE team.

+ +

CHARITY: Now, does your platform engineering team have product managers?

+ +

VICTORIA: I think it might be me. [laughs]

+ +

CHARITY: Aha.

+ +

VICTORIA: It might be me. And we have a team lead, and our CTO is actually our acting development director. So he's really leading the development of that project platform.

+ +

CHARITY: When I was in New York the last couple of days, I just gave a talk at KubeCon about the Perils, Pitfalls, and Pratfalls of Platform Engineering, just talking about all of the ways that platform teams accidentally steer themselves into the ditch.

+ +

One of the biggest mistakes that people make in that situation is not running the platform team like a product team, you know, having a sort of, like, if we build it, they will come sort of a mentality towards the platform that they're building internally for their engineers, and not doing the things like, you know, discovery or finding out like, am I really building, you know, the most important thing, you know, that people need right now?

+ +

And it's like, I didn't learn those skills as an engineer. Like, in the infrastructure land, we didn't learn how to work with product people. We didn't learn how to work with designers. And I feel like the biggest piece of career advice that I give, you know, people like me now, is learn how to work with product and like a product org.

+ +

I'm curious, like, what you're observing in your realm when it comes to this stuff. Like, how much like a product org do you work?

+ +

VICTORIA: Oh, I agree 100%. So I've actually been interested in applying our platform project to the thoughtbot Incubator Program. [laughs]

+ +

CHARITY: Mmm.

+ +

VICTORIA: So they have this method for doing market strategy, and user interviews, and all of that...exactly what you're saying, like, run it like a product. So I want them to help me with it. [laughs]

+ +

CHARITY: Nice.

+ +

VICTORIA: Yes, because I am also a managing director, and so we're managing a team and building business. And we also have this product or this open-source project, really. It's not...we don't necessarily want to be prescriptive with how we, as thoughtbot, tell people how to build their platforms. So with every client, we do a deep dive to see how is their dev team actually working? What are the pain points? What are the things we can do based on, like, you know, this collection of tools and knowledge that we have on what's worked for past clients that makes the most sense for them?

+ +

So, in that way, I think it is very customer-focused [laughs], right? And that's the motto we want to keep with. And I have been on other project teams where we just try to reproduce what worked for one client and to make that a product. And it doesn't always work [laughs] because of what you're saying. Like, you have to really...and especially, I think that just the diversity of the systems that we are building and have been built is kind of, like, breathtaking [laughs], you know.

+ +

CHARITY: Yeah. [chuckles]

+ +

VICTORIA: I'm sure you have some familiarity with that.

+ +

CHARITY: [laughs]

+ +

VICTORIA: But what did you really find in the market that worked for you right away, like, was, like, the problem that you were able to solve and start building within your business?

+ +

CHARITY: We did everything all wrong. So I had had this experience at Facebook, which, you know, at Parse, you know, we had all these reliability issues because of the architecture. What we were building was just fundamentally...as soon as any customer got big, like, they would take up all the resources in this shared, you know, tenancy thing, and the whole platform would go down. And it was so frustrating. And we were working on a rewrite and everything. Like, it was professionally humiliating for me as a reliability engineer to have a platform this bad at reliability.

+ +

And part of the issue was that you know, we had a million mobile apps, and it was a different app every time, different application...the iTunes Store, like, top five or something. And so the previous generation of tools and strategies like building dashboards and doing retros and being like, well, I'll make a dashboard so that I can find this problem next time immediately, like, just went out the window. Like, none of them would work because they were always about the last battle. And it was always something new.

+ +

And at one point, we started getting some datasets into this tool at Facebook called Scuba. It was butt ugly. Like, it was aggressively hostile to users. But it let us do one thing really well, which was slice and dice high cardinality dimensions in near real-time. And having the ability to do that to, like, break down by user ID, which is not possible with, you know, I don't know how familiar --

+ +

I'll briefly describe high cardinality. So imagine you have a collection of 100 million users. And the highest possible cardinality would be a unique ID because, you know, social security number, very high cardinality. And something much lower cardinality would be like inches of height. And all of metrics and dashboards are oriented around low cardinality dimensions. If you have more than a couple hundred hosts, you can no longer tag your metrics with a host ID. It just falls apart. So being able to break down by, like, you know, one of a million app IDs.

+ +

It took...the amount of time it took for us to identify and find these brand-new problems, it dropped like a rock, like, from hours of opening it. We never even solved a lot of the problems that we saw. We just recovered. We moved on [laughs] with our day, dropped from that to, like, seconds or minutes. Like, it wasn't even an engineering problem anymore. It was like a support problem, you know, you just go click, click, click, click, click, oh, there it is. Just follow the trail of breadcrumbs.

+ +

That made such an impression on me. And when I was leaving, I was just like, I can't go back to not having something like this. I was so much less powerful as an engineer. It's just, like, it's unthinkable. So when we started Honeycomb, we were just, like, we went hands down, and we started building. We didn't want to write a database. We had to write a database because there was nothing out there that could do this.

+ +

And we spent the first year or two not even really talking to customers. When we did talk to customers, I would tell our engineers to ignore their feedback [laughs] because they were all telling us they wanted better metrics. And we're like, no, we're not doing metrics.

+ +

The first thing that we found we could kind of connect to real problems that people were looking for was that it was high cardinality. There were a few, not many; there were a few engineers out there Googling for high cardinality metrics. And those engineers found us and became our earliest customers because we were able to do breathtaking...from their perspective, they were like, we've been told this is impossible. We've been told that this can't be done.

+ +

Things like Intercom was able to start tagging other requests with, like, app ID and customer ID. And immediately started noticing things like, oh, this database that we were just about to have to, like, spend six months sharding and extending, oh, it turns out 80% of the queries in flight to this database are all coming from one customer who is paying us $200 a month, so maybe we shouldn't [laughs] do that engineering labor. Maybe we should just, you know, throttle this guy who is only paying us 200 bucks a month. Or just all these things you can't actually see until you can use this very, very special tool. And then once you can see that...

+ +

So, like, our first customers became rabid fans and vouched for us to investors, and this still blows people's minds to this day. It's an incredibly difficult thing to explain and describe to people, but once they see it on their own data, it clicks because everybody's run into this problem before, and it's really frustrating.

+ +

VICTORIA: Yeah, that's super interesting and a great example to illustrate that point of just, like, not really knowing what's going on in your system. And, you know, you mentioned just, like, certainly at scale, that's when you really, really need to have [laughs] data and insight into your systems.

+ +

CHARITY: Yeah.

+ +

VICTORIA: But one question I get a lot is, like, at what scale do you actually need to start worrying about SRE? [laughs] Which --

+ +

CHARITY: SRE?

+ +

VICTORIA: Yeah, I'll let you answer that. Yeah, site reliability or even things like...like, everything under that umbrella like observability, like, you know, putting in monitoring and tracing and all this stuff. Sometimes people are just like, well, when do I actually have to care? [laughs]

+ +

CHARITY: I recognize this is, you know, coming from somebody who does this for a living, so, like, people can write it off all they want. But, like, the idea of developing without observability is just sad to me, like, from day one. This is not a tax. It's not something that slows you down or makes your lives worse. It's something that makes your lives better from day one. It helps you move more quickly, with more confidence. It helps you not make as many mistakes. It helps you...

+ +

Like, most people are used to interacting with their systems, which are just like flaming hairballs under their bed. Nobody has ever understood these systems. They certainly don't understand them. And every day, they ship more code that they don't understand, create systems that they've never understood. And then an alarm goes off, and everybody just, like, braces for impact because they don't understand them.

+ +

This is not the inevitable end state of computing. It doesn't have to be like this. You can have systems that are well-understood, that are tractable, that you could...it's just...it's so sad to me that people are like, oh God, when do I have to add telemetry? And I'm just like, how do you write software without telemetry? How do you have any confidence that the work you're doing is what you thought you were doing? You know, I just...

+ +

And, of course, if you're waiting to tack it on later, of course, it's not going to be as useful because you're trying to add telemetry for stuff you were writing weeks, or months, or years ago. The time to add it is while you're writing it. No one is ever going to understand your software as well as you do the moment that you're writing it. That's when you know your original intent. You know what you're trying to do. You know why you're trying to do it. You know what you tried that didn't work. You know, ultimately, what the most valuable pieces of data are. Why wouldn't you leave little breadcrumbs for yourself so that future you can find them?

+ +

You know, it's like...I just feel like this entire mental shift it can become just as much of a habit as like commenting your code or adding, you know, commenting in your pull request, you know. It becomes second nature, and reaching for it becomes second nature. You should have in your body a feeling of I'm not done until you've looked at your telemetry in production. That's the first moment that you can tell yourself, ah, yes, it probably does what I think it does, right?

+ +

So, like, this question it makes me sad. It gets me a little worked up because I feel like it's such a symptom of people who I know what their jobs are like based on that question, and it's not as good as it could be. Their jobs are much sadder and more confusing than it could be if they had a slightly different approach to telemetry. That's the observability bit.

+ +

But about SRE, very few ops engineers start companies, it seems, when I did, you know, I was one of three founding members. And the first thing I did was, of course, spin up an infrastructure and set up CI/CD and all this stuff. And I'm, like, feeling less useful than the others but, you know, doing my part. But that stuff that I spun up, we didn't have to hire an SRE for years, and when we did, it was pretty optional. And this is a system, you know, things trickle down, right?

+ +

Doing things right from the beginning and having them be clear and well-understood, and efficient, we were able to do so much with so few people. You know, we were landing, you know, hundreds of thousand-dollar deals with people who thought we had hundreds of employees. We had 12 engineers for the first almost five years, just 12 engineers. But, like, almost all of the energy that they put into the world went into moving the business forward, not fighting with the system, or thrashing the system, or trying to figure out bugs, or trying to track down things that were just, like, impossible to figure out. We waste so much time as engineers by trying to add this stuff in later.

+ +

So the actual answer to your question is, like, if you aren't lucky enough to have an ops co-founder, is as soon as you have real users. You know, I've made a career out of basically being the first engineer to join from infrastructure when the software engineers are starting to have real customers. Like, at Parse, they brought me in when they were about to do their alpha release. And they're like, whoa, okay, I guess we better have someone who knows how to run things.

+ +

And I came in, and I spent the next, you know, year or so just cleaning up shit that they had done, which wasn't terrible. But, you know, they just didn't really know what they were doing. So I kind of had to undo everything, redo it. And just the earlier, the better, right? It will pay off.

+ +

Now, that said, there is a real risk of over-engineering early. Companies they don't fail because they innovated too quickly; let's put it that way. They fail because they couldn't focus. They couldn't connect with their customers. They couldn't do all these things. And so you really do want to do just enough to get you to the next place so that you can put most of your effort into making product for your customers.

+ +

But yeah, it's so much easier to set yourself up with auto-deployment so that every CI/CD run automatically deploys your code to production and just maintain as you grow. That is so easy compared to trying to take, you know, a long, slow, you know, leaky deploy process and turn it into one that could auto-deploy safely after every commit. So yeah, do it early. And then maintain is the easiest way in the world to do this stuff.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

WILL: Correct me if I'm wrong, I think you said Facebook and mobile. Do you have, not experience with mobile but do you...does Honeycomb do anything in the mobile space? Because I feel like that portion is probably the most complicated for mobile, like, dealing with iOS and Android and everything that they're asking for. So...

+ +

CHARITY: We don't have mobile stuff at Honeycomb. Parse was a mobile Backend as a Service. So I went straight from doing all mobile all the time to doing no mobile at all. I also went from doing databases all the time to doing, you know...it's good career advice typically to find a niche and then stay in it, and I have not followed that advice. [laughter] I've just jumped from...as soon as I'm good at something, I start doing something else.

+ +

WILL: Let me ask you this, how come you don't see more mobile SRE or help in that area?

+ +

CHARITY: I think that you see lots of SREs for mobile apps, but they're on the back-end side. They're on the server side. So it's just not as visible. But even if you've got, like, a stack that's entirely serverless, you still need SRE.

+ +

But I think that the model is really shifting. You know, it used to be you hired an SRE team or an ops team to carry the pager for you and to take the alerts and to, like, buffer everything, and nowadays, that's not the expectation. That's not what good companies do. You know, they set up systems for their software engineers to own their code in production. But they need help because they're not experts in this, and that's where SRE types come in. Is that your experience?

+ +

WILL: Yeah, for the most part. Yeah, that is.

+ +

CHARITY: Yeah, I think that's very healthy.

+ +

VICTORIA: And I agree with that as well. And I'm going to take that clip of your reaction to that question about when you should start doing [laughter] observability and just play for everybody whenever someone asks [laughs] me that. I'm like, here's the answer. That's great.

+ +

CHARITY: I think a good metaphor for that is like, if you're buying a house and taking out a loan, the more of a down payment you can put down upfront, the lower that your monthly payments are going to be for the rest of your...you amortize that out over the next 20-30 years. The more you can do that, the better your life is going to be because interest rates are a bitch.

+ +

VICTORIA: It makes sense. And yeah, like, to your point earlier about when people actually do start to care about it is usually after something has broken in a traumatic way that can be really bad for your clients and, like, your legal [laughter] stance --

+ +

CHARITY: That's true.

+ +

VICTORIA: As a company.

+ +

CHARITY: Facing stuff, yeah, is where people usually start to think about it. But, like, the less visible part, and I think almost the more important part is what it does to your velocity and your ability to execute internally. When you have a good, clean system that is well-tended that, you know, where the amount of time between when you're writing the code and when the code is in production, and you're looking at...when that is short and tight, like, no more than a couple of hours, like, it's a different job than if it takes you, like, days or weeks to deploy. Your changes get bashed up with other people's.

+ +

And, you know, like, you enter, like, the software development death spiral where, you know, it takes a while. So your diffs get even bigger, so code review takes even longer, so it takes even longer. And then your changes are all getting bashed up. And, you know, now you need a team to run deploys and releases. And now you need an SRE team to do the firefighting.

+ +

And, like, your systems are...the bigger it gets, the more complicated it gets, the more you're spending time just waiting on each other or switching contexts. You ever, like, see an app and been like, oh, that's a cool app? I wonder...they have 800 engineers at that company. And you're just like, what the hell are they all doing? Like, seriously, how does it take that many engineers to build this admittedly nice little product?

+ +

I guarantee you it's because their internal hygiene is just terrible. It takes them too long to deploy things. They've forgotten what they've written by the time it's out, so nobody ever goes and looks at it. So it's just like, it's becoming a hairball under your bed. Nobody's looking at it. It's becoming more and more mysterious to you.

+ +

Like, I have a rule of thumb which there's no mathematical science behind this, just experience. But it's a rule of thumb that says that if it takes you, you know, on the order of, say, a couple of hours tops to deploy your software, if it takes you that many engineers to build and own that product, well, if your deploys take on the order of days instead of hours, it will take you twice as many people [chuckles] to build and support that product.

+ +

And if it takes you weeks to deploy that product, it will take you twice as many again; if anything, that is an underestimate because it actually goes up exponentially, not linearly. But, like, we are so wasteful when it comes to people's time. It is so much easier for managers to go, uh, we're overloaded. Let's hire more people. For some reason, you can always get headcount when you can't actually get the discipline to say no to things or the people to work on internal tools to, like, shrink that gap between when you've written it and when it's live.

+ +

And just the waste, it just spirals out of control, man, and it's not good. And, you know, it should be such a fun, creative, fulfilling job where you spend your day solving puzzles for money and moving the business materially forward every day. And instead, how much of our time do we just sit here, like, twiddling our thumbs and waiting for the build to finish or waiting for code review [laughs] to get turned around? Or, you know, swapping projects and, like, trying to page all that context in your brain? Like, it's absurd, and this is not that hard of a problem to fix.

+ +

VICTORIA: Engineering should be fun, and it should be dangerous. That's what [laughs] I'm getting out of this --

+ +

CHARITY: It should be fun, and it should be dangerous. I love that.

+ +

VICTORIA: Fun and dangerous. I like it. [laughs] And speaking of danger, I mean, maybe it's not dangerous, but what does success really look like for you at Honeycomb in the next six months or even in the next five years?

+ +

CHARITY: I find it much more easier to answer what failure would look like.

+ +

VICTORIA: You can answer that too if you like. [laughs]

+ +

CHARITY: [laughs] What would success look like? I mean, obviously, I have no desire to ever go through another acquisition, and I don't want to go out of business. So it'd be nice not to do either of those things, which means since we've taken VC money, IPO would be nice eventually.

+ +

But, like, ultimately, like, what motivates Christine and me and our entire company really is just, you know, we're engineers. We've felt this pain. We have seen that the world can be better. [laughs] We really just want to help, you know, move engineering into the current decade.

+ +

I feel like there are so many teams out there who hear me talk about this stuff. And they listen wistfully, and they're like, yeah, and they roll their eyes. They're like, yeah, you work in Silicon Valley, or yeah, but you work at a startup, or yeah...they have all these reasons why they don't get nice things.

+ +

We're just not good enough engineers is the one that breaks my heart the most because it's not true. Like, it has nothing to do...it has almost nothing to do with how good of an engineer you are. You have to be so much better of an engineer to deal with a giant hairball than with software that gets deployed, you know, within the hour that you can just go look at and see if it's working or not.

+ +

I want this to go mainstream. I want people...I want engineers to just have a better time at work. And I want people to succeed at what they're doing. And just...the more we can bring that kind of change to more and more people, the more successful I will feel.

+ +

VICTORIA: I really like that. And I think it's great. And it also makes me think I find that people who work in the DevOps space have a certain type of mentality sometimes, [laughs] like, it's about the greater community and, like, just making being at work better. And I also think it maybe makes you more willing to admit your failures [laughs] like you were earlier, right?

+ +

CHARITY: Probably.

+ +

VICTORIA: That's part of the culture. It's like, well, we messed up. [laughs] We broke stuff, and we're going to learn from it.

+ +

CHARITY: It's healthy. I'm trying to institute a rule where at all hands when we're doing different organizations giving an update every two weeks, where we talk two-thirds about our successes and things that worked great and one-third about things that just didn't work. Like, I think we could all stand to talk about our failures a lot more.

+ +

VICTORIA: Yeah, makes it a lot less scary, I think [laughs], right?

+ +

CHARITY: Yeah, yeah. It democratizes the feeling, and it genuinely...it makes me happy. It's like, that didn't work, great. Now we know not to do it. Of the infinite number of things that we could try, now we know something for real. I think it's exciting. And, I don't know, I think it's funny when things fail. And I think that if we can just laugh about it together...

+ +

You know, in every engineering org that I've ever worked at, out of all the teams, the ops types teams have always been the ones that are the most tightly bonded. They have this real, like, Band of Brothers type of sentiment. And I think it's because, you know, we've historically endured most of the pain. [laughs] But, like, that sense of, like, it's us against the system, that there is hilarity in failure. And, at the end of the day, we're all just monkeys, like, poking at electrical sockets is, I think...I think it's healthy. [laughs]

+ +

WILL: That's really neat. I love it. This is one of my favorite questions. What advice would you give yourself if you could go back in time?

+ +

CHARITY: I don't know. I think I'd just give myself a thumbs up and go; it's going to be all right. I don't know; I wouldn't... I don't think that I would try to alter the time continuum [laughs] in any way. But I had a lot of anxiety when I was younger about going to hell and all this stuff. And so I think...but anything I said to my future self, I wouldn't have believed anyway. So yeah, I respectfully decline the offer.

+ +

VICTORIA: That's fair. I mean, I think about that a lot too actually, like, I sometimes think like, well, if I could go back to myself a year ago and just --

+ +

CHARITY: Yeah. I would look at me like I was stupid.

+ +

[laughter]

+ +

VICTORIA: That makes sense. It reminds me a little bit about what you said, though, like, doing SRE and everything upfront or the observability pieces and building it correctly in a way you can deploy fastly is like a gift to your future self. [laughs]

+ +

CHARITY: Yes, it is, with a bow. Yes, exactly.

+ +

VICTORIA: There you go. Well, all right. I think we are about ready to wrap up. Is there anything you would like to promote specifically?

+ +

CHARITY: We just launched this really cool little thing at Honeycomb. And you won't often hear me say the words cool and AI in proximity to each other, but we just launched this really dope little thing. It's a tool for using natural language to ask questions of your telemetry. So, if you just deployed something and you want to know, like, what's slow or did anything change, you can just ask it using English, and it does a ChatGPT thing and generates the right graphs for you. It's pretty sweet.

+ +

VICTORIA: That's really cool. So, if you have Honeycomb set up and working in your system and then you can just ask the little chatbot, "Hey, what's going on here?"

+ +

CHARITY: Yeah. What's the slowest endpoint? And it'll just tell you, which is great because I feel like I do not think graphically at all. My brain just really doesn't. So I have never been the person who's, like, creating dashboards or graphs. My friend Ben Hartshorne works with me, and he'll make the dashboards. And then I get up in the morning, and I bookmark them. And so we're sort of symbiotic.

+ +

But everyone can tweak a query, right? Once you have something that you know is, like, within spitting distance as the data you want, anyone can tweak it, but composing is really hard. So I feel like this really helps you get over that initial hurdle of, like, er, what do I break down by? What do I group by? What are the field names? You just ask it the question, and then you've got to click, click, click, and, like, get exactly what you want out of it. I think it's, like, a game changer.

+ +

VICTORIA: That sounds extremely cool. And we will certainly link to it in our show notes today. Thank you so much for being with us and spending the time, Charity.

+ +

CHARITY: Yeah, this was really fun.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Charity Majors.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Charity Majors is Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together.

+ +

Victoria and Will talk to Charity about observability, her technical background and decision to start Honeycomb.io, thoughts about the whole ops SRE profession, and things that surprised her along her journey of building a company around observability as a concept.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your other host, Will Larry. And with us today is Charity Majors, Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. Charity, thank you for joining us. How are you doing?

+ +

CHARITY: Thanks for having me. I'm a little bit crunchy from a [laughs] long flight this morning. But I'm very happy to be home in San Francisco and happy to be talking to you.

+ +

VICTORIA: Wonderful. And, Charity, I looked at your profile and noticed that you're a fan of whiskey. And I thought I might ask you just to get us started here, like, what's your favorite brand?

+ +

CHARITY: Oh, goodness, that's like asking me to choose my favorite child if I had children. [laughter]. You know, I used to really be into the peaty scotches, the Islays, in particular. But lately, I've been more of a bourbon kick. Of course, everybody loves Pappy Van Winkle, George T. Stagg; impossible to find now, but it's so, so good. You know, if it's high-proof and single barrel, I will probably drink it.

+ +

VICTORIA: That sounds great. Yeah, I tend to have the same approach. And, like, people ask me if I like it, and I like all of them. [laughter] I don't [inaudible 01:21] that I didn't like. [laughs]

+ +

CHARITY: [inaudible 01:23] tongue sting? Then I'm in. [laughs]

+ +

VICTORIA: Yeah, [inaudible 01:26].

+ +

WILL: See, I'm the opposite. I want something smooth. I'm a fruity drink type of guy. I'm just going, to be honest.

+ +

CHARITY: There's no shame in that.

+ +

WILL: No shame here. [laughs] Give me a margarita, and you have a happy Will for life. [laughs]

+ +

VICTORIA: We'll have to get you to come out and visit San Diego for some margaritas, Will. That's --

+ +

CHARITY: Oh yeah.

+ +

VICTORIA: Yeah, it's the place to be. Yeah, we do more of a bourbon drink in our house, like bourbon soda. That's usually what we make, like, my own custom simple syrup, and mix it with a little bourbon and soda water. And that's what we do for a cool down at the end of the day sometimes, yeah. Well, awesome.

+ +

Let's see. So, Charity, why don't you just tell me a little more about Honeycomb? What is it?

+ +

CHARITY: Well, it's a startup that hasn't failed yet, so... [laughs] to my own shock. [laughs] We're still around seven and a half years in. And I say that just so much joking. Like, you're not really supposed to say this as a founder, but, like, I 100% thought we were going to fail from the beginning. But we haven't yet, and we just got more money. So we'll be around for a while.

+ +

We kind of pioneered the whole concept of observability, which now doesn't really mean anything at all. Everybody and their mother is like, well, I do observability, too. But back when we started talking about it, it was kind of a little bit revolutionary, I guess in that, you know, we started talking about how important it is to have high cardinality data in your systems. You really can't debug without it.

+ +

And the fact that our systems are getting just astronomically more complex, and yet, we're still trying to debug it with these tools based on, you know, the metric data type [laughs] defined since the '70s when space was incredibly rare and expensive. And now space is incredibly cheap, but we should be wasteful with it so we can understand our incredibly complex systems. So that's us.

+ +

We really try to empower software engineers to own their own code in production. For a long time, it was like, all of the tools for you to understand your software were really written for low-level ops people because they speak the language of, like, RAM, and disks, and CPU, which you shouldn't have to understand that in order to be able to understand I just deployed something, what went wrong?

+ +

WILL: I love the honesty because there are so many founders that I'll talk to, and I'm like, okay, you're very successful. But did you really expect this to be what it is today? Did you really expect to survive? Because, like, just some of their ideas, I'm like, it's brilliant, but if I was with you back in the day, I'd be like, it ain't going to work. It's not going to work. [laughs]

+ +

CHARITY: Yeah. And I feel like the VC culture really encourages delusion, just, like, self-delusion, like, this delusive thinking. You're supposed to, like, broadcast just, like, rock-solid confidence in yourself and your ideas at all time. And I think that only sociopaths do that. [laughs] I don't want to work for anyone who's that confident in themselves or their idea.

+ +

Because I'm showing my own stripes, I guess, you know, I'm a reliability engineer. I wake up in the morning; I'm like, what's wrong with the day? That's just how my brain works. But I feel like I would rather work with people who are constantly scanning the horizon and being like, okay, what's likely to kill us today? Instead of people who are just like, I am right. [laughs] You know?

+ +

VICTORIA: Yeah. And I can relate that back to observability by thinking how, you know, you can have an idea about how your system is supposed to work, and then there's the way that it actually works. [laughs]

+ +

CHARITY: Oh my God.

+ +

VICTORIA: Right?

+ +

CHARITY: Yes. It's so much that.

+ +

VICTORIA: Maybe you can tell us just a little bit more about, like, what is observability? Or how would you explain that to someone who isn't necessarily in it every day?

+ +

CHARITY: I would explain it; I mean, it depends on who your audience is, of course. But I would explain it like engineers spend all day in their IDEs. And they come to believe that that's what software is. But software is not lines of code. Software is those lines of code running in production with real users using it. That's when software becomes real.

+ +

And, for too long, we've treated like that, like, an entirely different...well, it's written. [laughs] You know, for launch, I was like, well, it's ops' problem, as the meme says. But we haven't really gotten to a point yet where...I feel like when you're developing with observability; you should be instrumenting your code as you go with an eye towards your future self. How am I going to know if this is working or not? How am I going to know if this breaks?

+ +

And when you deploy it, you should then go and look at your code in production and look at it through the lens of the telemetry that you just wrote and ask yourself, is it doing what I expected it to? Does anything else look weird? Because the cost of finding and fixing bugs goes up exponentially from the moment that you write them. It's like you type a bug; you backspace. Cool, good for you. That's the fastest you can fix it. The next fastest is if you find it when you're running tests. But tests are only ever going to find the things you could predict were going to fail or that have already failed.

+ +

The first real opportunity that you have to see if your code really works or not is right after you've deployed it, but only if you've given yourself the telemetry to do so. Like, the idea of just merging your code, like walking out the door or merging your code and waiting to get paged or to get [laughs] escalated to this is madness. This should be such an artifact of the battle days when dev writes, and ops runs it. That doesn't work, right?

+ +

Like, in the beginning, we had software engineers who wrote code and ran that code in production, and that's how things should be. You should be writing code and running code in production. And the reason I think we're starting to see that reality emerge again is because our systems have gotten so complicated. We kind of can't not because you can't really run your code as a black box anymore. You can't ignore what's on the inside. You have to be able to look at the code in order to be able to run it effectively.

+ +

And conversely, I don't think you could develop good code unless you're constantly exposing yourself to the consequences of that code. It lets you know when it breaks, that whole feedback loop that completely severed when we had dev versus ops. And we're slowly kind of knitting it together again. But, like, that's what's at the heart of that incredibly powerful feedback loop. It's the heart of all software engineering is, instrumenting your code and looking at it and asking yourself, is it doing what I expected it to do?

+ +

WILL: That's really neat. You said you're a reliability engineer. What's your background? Tell me more about it because you're the CTO of Honeycomb. So you have some technical background. What does that look like?

+ +

CHARITY: Yeah, well, I was a music major and then a serial dropout. I've never graduated from anything, ever. And then, I worked at startups in Silicon Valley. Nothing you'd ever...well, I worked at Linden Lab for a few years and some other places.

+ +

But honestly, the reason I started Honeycomb was because...so I worked at Parse. I was the infrastructure lead at Parse; rest in peace. It got acquired by Facebook. And when I was leaving Facebook, it was the only time in my life that I'd ever had a pedigree. Well, I've actually been an ops engineer my entire career. When I was leaving Facebook, I had VCs going, "Would you like some money to do something? Because you're coming from Facebook, so you must be smart."

+ +

On the one hand, that was kind of offensive. And on the other hand, like, I kind of felt the obligation to just take the money and run, like, on behalf of all dropouts, of women, and queers everywhere. Just, you know, how often...am I ever going to get this chance again? No, I'm not. So, good.

+ +

VICTORIA: Yes, I will accept your money. [laughs]

+ +

CHARITY: Yeah, right?

+ +

VICTORIA: I will take it. And I'm not surprised that you were a music major. I've met many, I would say, people who are active in social media about DevOps, and then it turns out they were a theater major, [laughs] or music, or something different. And they kind of naturally found their way.

+ +

CHARITY: The whole ops SRE profession has historically been a real magnet for weirdo people, weird past, people who took very non-traditional. So it's always been about tinkering, just understanding systems. And there hasn't been this high bar for formal, you know, knowledge that you need just to get your first job. I feel like this is all changing. And it makes me kind of...I understand why it's changing, and it also makes me kind of sad.

+ +

VICTORIA: So I think you have a quote about, you know, working on infrastructure teams that everything comes back to databases.

+ +

CHARITY: [laughs]

+ +

VICTORIA: I wonder if you could expand on that.

+ +

CHARITY: I've been an accidental DBA my entire career. I just always seemed to be the one left holding the bag. [laughs] We were playing musical chairs. I just feel like, you know, as you're moving up the stack, you can get more and more reckless. As you move down the stack, the closer you get to, like, bits on disk, the more conservative you have to be, the more blast radius your mistakes could have.

+ +

Like, shit changes all the time in JavaScript land. In database land, we're still doing CRUD operators, like, since Stonebreaker did it in the '70s. We're still doing very fundamental stuff. I love it, though, because, I don't know, it's such a capsule of computers at large, which is just that people have no idea how much shit breaks. [laughs] Stuff breaks all the time. And the beauty of it is that we keep going. It's not that things don't break. You have no idea how much stuff is broken in your stack right now. But we find ways to resolve it after the fact.

+ +

I just think that data is so fascinating because it has so much gravity. I don't know, I could keep going, but I feel like you get the point. I just think it's really fun. I think danger is fun, I think. It might not surprise you to learn that I, too, was diagnosed with ADHD in the past couple of years. I feel like this is another strand that most DevOps, SRE types have in common, which is just [laughs] highly motivated in a good way by panic. [laughs]

+ +

WILL: I love that you said you love danger because I feel like that is right in your wheelhouse. Like, you have to love danger to be in that field because it's predictable. You're the one that's coming in and putting out the fires when everyone sometimes they're running for the window. Like you said, like, you got caught holding the bag. So that's really neat.

+ +

This is a big question for me, especially for being an engineer, a dev, do you find that product and design teams understand and see the value in SRE?

+ +

CHARITY: Oooh. These types of cultural questions are always so difficult for me to gauge whether or not my sample is representative of the larger population. Because, in my experience, you know, ops teams typically rule the roost, like, they get final say over everything. But I know that that's not typically true. Like, throughout the industry, like, ops teams kind of have a history of being kind of kicked around.

+ +

I think that they do see the value because everybody can see when it breaks. But I think that they mostly see the value when it breaks. I think that it takes a rare, farsighted product team to be able to consent to giving, like, investments all along in the kinds of improvements that will pay off later on instead of just pouring all of the resources into fast fixes and features and feature, feature, feature.

+ +

And then, of course, you know, you slowly grind to a halt as a team because you're just amassing surface area. You're not paying down your tech debt. And I think it's not always clear to product and design leaders how to make those investments in a way that actually benefits them instead of it just being a cost center. You know, it's just something that's always a break on them instead of actually enabling them to move faster.

+ +

WILL: Yeah, yeah. And I can definitely see that being an engineer dev. I'm going to change it a little bit. And I'm going to ask, Victoria, since you're the managing director of that team, how do you feel about that question? Do you feel that's the same thing, or what's your observation of that?

+ +

VICTORIA: I think Charity is, like, spot on because it does depend on the type of organization that you're working in, the hierarchy, and who gets priority over budget and things like that. And so the interesting thought for me coming from federal IT organizations into more commercial and startup organizations is that there is a little bit of a disconnect. And we started to ask our designers and developers like, "Well, have you thought much about, like, what happens when this fails?" [laughs] And especially --

+ +

CHARITY: Great question.

+ +

VICTORIA: Yeah, like, when you're dealing with, like, healthcare startups or with bank startups and really thinking through all the ways it could go wrong. Is it a new pathway? Which I think is exciting for a lot of people. And I'm curious, too, Charity, like with Honeycomb, was there things that surprised you in your journey of discovery about, you know, building a company about observability and what people wanted out of this space?

+ +

CHARITY: Oh my goodness. [laughs] Was anything not a surprise? I mean, [laughs] yeah, absolutely. You're a director of what team?

+ +

VICTORIA: I'm a managing director of our Mission Control team.

+ +

CHARITY: Oooh.

+ +

VICTORIA: Which is our platform engineering, and DevOps, and SRE team.

+ +

CHARITY: Now, does your platform engineering team have product managers?

+ +

VICTORIA: I think it might be me. [laughs]

+ +

CHARITY: Aha.

+ +

VICTORIA: It might be me. And we have a team lead, and our CTO is actually our acting development director. So he's really leading the development of that project platform.

+ +

CHARITY: When I was in New York the last couple of days, I just gave a talk at KubeCon about the Perils, Pitfalls, and Pratfalls of Platform Engineering, just talking about all of the ways that platform teams accidentally steer themselves into the ditch.

+ +

One of the biggest mistakes that people make in that situation is not running the platform team like a product team, you know, having a sort of, like, if we build it, they will come sort of a mentality towards the platform that they're building internally for their engineers, and not doing the things like, you know, discovery or finding out like, am I really building, you know, the most important thing, you know, that people need right now?

+ +

And it's like, I didn't learn those skills as an engineer. Like, in the infrastructure land, we didn't learn how to work with product people. We didn't learn how to work with designers. And I feel like the biggest piece of career advice that I give, you know, people like me now, is learn how to work with product and like a product org.

+ +

I'm curious, like, what you're observing in your realm when it comes to this stuff. Like, how much like a product org do you work?

+ +

VICTORIA: Oh, I agree 100%. So I've actually been interested in applying our platform project to the thoughtbot Incubator Program. [laughs]

+ +

CHARITY: Mmm.

+ +

VICTORIA: So they have this method for doing market strategy, and user interviews, and all of that...exactly what you're saying, like, run it like a product. So I want them to help me with it. [laughs]

+ +

CHARITY: Nice.

+ +

VICTORIA: Yes, because I am also a managing director, and so we're managing a team and building business. And we also have this product or this open-source project, really. It's not...we don't necessarily want to be prescriptive with how we, as thoughtbot, tell people how to build their platforms. So with every client, we do a deep dive to see how is their dev team actually working? What are the pain points? What are the things we can do based on, like, you know, this collection of tools and knowledge that we have on what's worked for past clients that makes the most sense for them?

+ +

So, in that way, I think it is very customer-focused [laughs], right? And that's the motto we want to keep with. And I have been on other project teams where we just try to reproduce what worked for one client and to make that a product. And it doesn't always work [laughs] because of what you're saying. Like, you have to really...and especially, I think that just the diversity of the systems that we are building and have been built is kind of, like, breathtaking [laughs], you know.

+ +

CHARITY: Yeah. [chuckles]

+ +

VICTORIA: I'm sure you have some familiarity with that.

+ +

CHARITY: [laughs]

+ +

VICTORIA: But what did you really find in the market that worked for you right away, like, was, like, the problem that you were able to solve and start building within your business?

+ +

CHARITY: We did everything all wrong. So I had had this experience at Facebook, which, you know, at Parse, you know, we had all these reliability issues because of the architecture. What we were building was just fundamentally...as soon as any customer got big, like, they would take up all the resources in this shared, you know, tenancy thing, and the whole platform would go down. And it was so frustrating. And we were working on a rewrite and everything. Like, it was professionally humiliating for me as a reliability engineer to have a platform this bad at reliability.

+ +

And part of the issue was that you know, we had a million mobile apps, and it was a different app every time, different application...the iTunes Store, like, top five or something. And so the previous generation of tools and strategies like building dashboards and doing retros and being like, well, I'll make a dashboard so that I can find this problem next time immediately, like, just went out the window. Like, none of them would work because they were always about the last battle. And it was always something new.

+ +

And at one point, we started getting some datasets into this tool at Facebook called Scuba. It was butt ugly. Like, it was aggressively hostile to users. But it let us do one thing really well, which was slice and dice high cardinality dimensions in near real-time. And having the ability to do that to, like, break down by user ID, which is not possible with, you know, I don't know how familiar --

+ +

I'll briefly describe high cardinality. So imagine you have a collection of 100 million users. And the highest possible cardinality would be a unique ID because, you know, social security number, very high cardinality. And something much lower cardinality would be like inches of height. And all of metrics and dashboards are oriented around low cardinality dimensions. If you have more than a couple hundred hosts, you can no longer tag your metrics with a host ID. It just falls apart. So being able to break down by, like, you know, one of a million app IDs.

+ +

It took...the amount of time it took for us to identify and find these brand-new problems, it dropped like a rock, like, from hours of opening it. We never even solved a lot of the problems that we saw. We just recovered. We moved on [laughs] with our day, dropped from that to, like, seconds or minutes. Like, it wasn't even an engineering problem anymore. It was like a support problem, you know, you just go click, click, click, click, click, oh, there it is. Just follow the trail of breadcrumbs.

+ +

That made such an impression on me. And when I was leaving, I was just like, I can't go back to not having something like this. I was so much less powerful as an engineer. It's just, like, it's unthinkable. So when we started Honeycomb, we were just, like, we went hands down, and we started building. We didn't want to write a database. We had to write a database because there was nothing out there that could do this.

+ +

And we spent the first year or two not even really talking to customers. When we did talk to customers, I would tell our engineers to ignore their feedback [laughs] because they were all telling us they wanted better metrics. And we're like, no, we're not doing metrics.

+ +

The first thing that we found we could kind of connect to real problems that people were looking for was that it was high cardinality. There were a few, not many; there were a few engineers out there Googling for high cardinality metrics. And those engineers found us and became our earliest customers because we were able to do breathtaking...from their perspective, they were like, we've been told this is impossible. We've been told that this can't be done.

+ +

Things like Intercom was able to start tagging other requests with, like, app ID and customer ID. And immediately started noticing things like, oh, this database that we were just about to have to, like, spend six months sharding and extending, oh, it turns out 80% of the queries in flight to this database are all coming from one customer who is paying us $200 a month, so maybe we shouldn't [laughs] do that engineering labor. Maybe we should just, you know, throttle this guy who is only paying us 200 bucks a month. Or just all these things you can't actually see until you can use this very, very special tool. And then once you can see that...

+ +

So, like, our first customers became rabid fans and vouched for us to investors, and this still blows people's minds to this day. It's an incredibly difficult thing to explain and describe to people, but once they see it on their own data, it clicks because everybody's run into this problem before, and it's really frustrating.

+ +

VICTORIA: Yeah, that's super interesting and a great example to illustrate that point of just, like, not really knowing what's going on in your system. And, you know, you mentioned just, like, certainly at scale, that's when you really, really need to have [laughs] data and insight into your systems.

+ +

CHARITY: Yeah.

+ +

VICTORIA: But one question I get a lot is, like, at what scale do you actually need to start worrying about SRE? [laughs] Which --

+ +

CHARITY: SRE?

+ +

VICTORIA: Yeah, I'll let you answer that. Yeah, site reliability or even things like...like, everything under that umbrella like observability, like, you know, putting in monitoring and tracing and all this stuff. Sometimes people are just like, well, when do I actually have to care? [laughs]

+ +

CHARITY: I recognize this is, you know, coming from somebody who does this for a living, so, like, people can write it off all they want. But, like, the idea of developing without observability is just sad to me, like, from day one. This is not a tax. It's not something that slows you down or makes your lives worse. It's something that makes your lives better from day one. It helps you move more quickly, with more confidence. It helps you not make as many mistakes. It helps you...

+ +

Like, most people are used to interacting with their systems, which are just like flaming hairballs under their bed. Nobody has ever understood these systems. They certainly don't understand them. And every day, they ship more code that they don't understand, create systems that they've never understood. And then an alarm goes off, and everybody just, like, braces for impact because they don't understand them.

+ +

This is not the inevitable end state of computing. It doesn't have to be like this. You can have systems that are well-understood, that are tractable, that you could...it's just...it's so sad to me that people are like, oh God, when do I have to add telemetry? And I'm just like, how do you write software without telemetry? How do you have any confidence that the work you're doing is what you thought you were doing? You know, I just...

+ +

And, of course, if you're waiting to tack it on later, of course, it's not going to be as useful because you're trying to add telemetry for stuff you were writing weeks, or months, or years ago. The time to add it is while you're writing it. No one is ever going to understand your software as well as you do the moment that you're writing it. That's when you know your original intent. You know what you're trying to do. You know why you're trying to do it. You know what you tried that didn't work. You know, ultimately, what the most valuable pieces of data are. Why wouldn't you leave little breadcrumbs for yourself so that future you can find them?

+ +

You know, it's like...I just feel like this entire mental shift it can become just as much of a habit as like commenting your code or adding, you know, commenting in your pull request, you know. It becomes second nature, and reaching for it becomes second nature. You should have in your body a feeling of I'm not done until you've looked at your telemetry in production. That's the first moment that you can tell yourself, ah, yes, it probably does what I think it does, right?

+ +

So, like, this question it makes me sad. It gets me a little worked up because I feel like it's such a symptom of people who I know what their jobs are like based on that question, and it's not as good as it could be. Their jobs are much sadder and more confusing than it could be if they had a slightly different approach to telemetry. That's the observability bit.

+ +

But about SRE, very few ops engineers start companies, it seems, when I did, you know, I was one of three founding members. And the first thing I did was, of course, spin up an infrastructure and set up CI/CD and all this stuff. And I'm, like, feeling less useful than the others but, you know, doing my part. But that stuff that I spun up, we didn't have to hire an SRE for years, and when we did, it was pretty optional. And this is a system, you know, things trickle down, right?

+ +

Doing things right from the beginning and having them be clear and well-understood, and efficient, we were able to do so much with so few people. You know, we were landing, you know, hundreds of thousand-dollar deals with people who thought we had hundreds of employees. We had 12 engineers for the first almost five years, just 12 engineers. But, like, almost all of the energy that they put into the world went into moving the business forward, not fighting with the system, or thrashing the system, or trying to figure out bugs, or trying to track down things that were just, like, impossible to figure out. We waste so much time as engineers by trying to add this stuff in later.

+ +

So the actual answer to your question is, like, if you aren't lucky enough to have an ops co-founder, is as soon as you have real users. You know, I've made a career out of basically being the first engineer to join from infrastructure when the software engineers are starting to have real customers. Like, at Parse, they brought me in when they were about to do their alpha release. And they're like, whoa, okay, I guess we better have someone who knows how to run things.

+ +

And I came in, and I spent the next, you know, year or so just cleaning up shit that they had done, which wasn't terrible. But, you know, they just didn't really know what they were doing. So I kind of had to undo everything, redo it. And just the earlier, the better, right? It will pay off.

+ +

Now, that said, there is a real risk of over-engineering early. Companies they don't fail because they innovated too quickly; let's put it that way. They fail because they couldn't focus. They couldn't connect with their customers. They couldn't do all these things. And so you really do want to do just enough to get you to the next place so that you can put most of your effort into making product for your customers.

+ +

But yeah, it's so much easier to set yourself up with auto-deployment so that every CI/CD run automatically deploys your code to production and just maintain as you grow. That is so easy compared to trying to take, you know, a long, slow, you know, leaky deploy process and turn it into one that could auto-deploy safely after every commit. So yeah, do it early. And then maintain is the easiest way in the world to do this stuff.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

WILL: Correct me if I'm wrong, I think you said Facebook and mobile. Do you have, not experience with mobile but do you...does Honeycomb do anything in the mobile space? Because I feel like that portion is probably the most complicated for mobile, like, dealing with iOS and Android and everything that they're asking for. So...

+ +

CHARITY: We don't have mobile stuff at Honeycomb. Parse was a mobile Backend as a Service. So I went straight from doing all mobile all the time to doing no mobile at all. I also went from doing databases all the time to doing, you know...it's good career advice typically to find a niche and then stay in it, and I have not followed that advice. [laughter] I've just jumped from...as soon as I'm good at something, I start doing something else.

+ +

WILL: Let me ask you this, how come you don't see more mobile SRE or help in that area?

+ +

CHARITY: I think that you see lots of SREs for mobile apps, but they're on the back-end side. They're on the server side. So it's just not as visible. But even if you've got, like, a stack that's entirely serverless, you still need SRE.

+ +

But I think that the model is really shifting. You know, it used to be you hired an SRE team or an ops team to carry the pager for you and to take the alerts and to, like, buffer everything, and nowadays, that's not the expectation. That's not what good companies do. You know, they set up systems for their software engineers to own their code in production. But they need help because they're not experts in this, and that's where SRE types come in. Is that your experience?

+ +

WILL: Yeah, for the most part. Yeah, that is.

+ +

CHARITY: Yeah, I think that's very healthy.

+ +

VICTORIA: And I agree with that as well. And I'm going to take that clip of your reaction to that question about when you should start doing [laughter] observability and just play for everybody whenever someone asks [laughs] me that. I'm like, here's the answer. That's great.

+ +

CHARITY: I think a good metaphor for that is like, if you're buying a house and taking out a loan, the more of a down payment you can put down upfront, the lower that your monthly payments are going to be for the rest of your...you amortize that out over the next 20-30 years. The more you can do that, the better your life is going to be because interest rates are a bitch.

+ +

VICTORIA: It makes sense. And yeah, like, to your point earlier about when people actually do start to care about it is usually after something has broken in a traumatic way that can be really bad for your clients and, like, your legal [laughter] stance --

+ +

CHARITY: That's true.

+ +

VICTORIA: As a company.

+ +

CHARITY: Facing stuff, yeah, is where people usually start to think about it. But, like, the less visible part, and I think almost the more important part is what it does to your velocity and your ability to execute internally. When you have a good, clean system that is well-tended that, you know, where the amount of time between when you're writing the code and when the code is in production, and you're looking at...when that is short and tight, like, no more than a couple of hours, like, it's a different job than if it takes you, like, days or weeks to deploy. Your changes get bashed up with other people's.

+ +

And, you know, like, you enter, like, the software development death spiral where, you know, it takes a while. So your diffs get even bigger, so code review takes even longer, so it takes even longer. And then your changes are all getting bashed up. And, you know, now you need a team to run deploys and releases. And now you need an SRE team to do the firefighting.

+ +

And, like, your systems are...the bigger it gets, the more complicated it gets, the more you're spending time just waiting on each other or switching contexts. You ever, like, see an app and been like, oh, that's a cool app? I wonder...they have 800 engineers at that company. And you're just like, what the hell are they all doing? Like, seriously, how does it take that many engineers to build this admittedly nice little product?

+ +

I guarantee you it's because their internal hygiene is just terrible. It takes them too long to deploy things. They've forgotten what they've written by the time it's out, so nobody ever goes and looks at it. So it's just like, it's becoming a hairball under your bed. Nobody's looking at it. It's becoming more and more mysterious to you.

+ +

Like, I have a rule of thumb which there's no mathematical science behind this, just experience. But it's a rule of thumb that says that if it takes you, you know, on the order of, say, a couple of hours tops to deploy your software, if it takes you that many engineers to build and own that product, well, if your deploys take on the order of days instead of hours, it will take you twice as many people [chuckles] to build and support that product.

+ +

And if it takes you weeks to deploy that product, it will take you twice as many again; if anything, that is an underestimate because it actually goes up exponentially, not linearly. But, like, we are so wasteful when it comes to people's time. It is so much easier for managers to go, uh, we're overloaded. Let's hire more people. For some reason, you can always get headcount when you can't actually get the discipline to say no to things or the people to work on internal tools to, like, shrink that gap between when you've written it and when it's live.

+ +

And just the waste, it just spirals out of control, man, and it's not good. And, you know, it should be such a fun, creative, fulfilling job where you spend your day solving puzzles for money and moving the business materially forward every day. And instead, how much of our time do we just sit here, like, twiddling our thumbs and waiting for the build to finish or waiting for code review [laughs] to get turned around? Or, you know, swapping projects and, like, trying to page all that context in your brain? Like, it's absurd, and this is not that hard of a problem to fix.

+ +

VICTORIA: Engineering should be fun, and it should be dangerous. That's what [laughs] I'm getting out of this --

+ +

CHARITY: It should be fun, and it should be dangerous. I love that.

+ +

VICTORIA: Fun and dangerous. I like it. [laughs] And speaking of danger, I mean, maybe it's not dangerous, but what does success really look like for you at Honeycomb in the next six months or even in the next five years?

+ +

CHARITY: I find it much more easier to answer what failure would look like.

+ +

VICTORIA: You can answer that too if you like. [laughs]

+ +

CHARITY: [laughs] What would success look like? I mean, obviously, I have no desire to ever go through another acquisition, and I don't want to go out of business. So it'd be nice not to do either of those things, which means since we've taken VC money, IPO would be nice eventually.

+ +

But, like, ultimately, like, what motivates Christine and me and our entire company really is just, you know, we're engineers. We've felt this pain. We have seen that the world can be better. [laughs] We really just want to help, you know, move engineering into the current decade.

+ +

I feel like there are so many teams out there who hear me talk about this stuff. And they listen wistfully, and they're like, yeah, and they roll their eyes. They're like, yeah, you work in Silicon Valley, or yeah, but you work at a startup, or yeah...they have all these reasons why they don't get nice things.

+ +

We're just not good enough engineers is the one that breaks my heart the most because it's not true. Like, it has nothing to do...it has almost nothing to do with how good of an engineer you are. You have to be so much better of an engineer to deal with a giant hairball than with software that gets deployed, you know, within the hour that you can just go look at and see if it's working or not.

+ +

I want this to go mainstream. I want people...I want engineers to just have a better time at work. And I want people to succeed at what they're doing. And just...the more we can bring that kind of change to more and more people, the more successful I will feel.

+ +

VICTORIA: I really like that. And I think it's great. And it also makes me think I find that people who work in the DevOps space have a certain type of mentality sometimes, [laughs] like, it's about the greater community and, like, just making being at work better. And I also think it maybe makes you more willing to admit your failures [laughs] like you were earlier, right?

+ +

CHARITY: Probably.

+ +

VICTORIA: That's part of the culture. It's like, well, we messed up. [laughs] We broke stuff, and we're going to learn from it.

+ +

CHARITY: It's healthy. I'm trying to institute a rule where at all hands when we're doing different organizations giving an update every two weeks, where we talk two-thirds about our successes and things that worked great and one-third about things that just didn't work. Like, I think we could all stand to talk about our failures a lot more.

+ +

VICTORIA: Yeah, makes it a lot less scary, I think [laughs], right?

+ +

CHARITY: Yeah, yeah. It democratizes the feeling, and it genuinely...it makes me happy. It's like, that didn't work, great. Now we know not to do it. Of the infinite number of things that we could try, now we know something for real. I think it's exciting. And, I don't know, I think it's funny when things fail. And I think that if we can just laugh about it together...

+ +

You know, in every engineering org that I've ever worked at, out of all the teams, the ops types teams have always been the ones that are the most tightly bonded. They have this real, like, Band of Brothers type of sentiment. And I think it's because, you know, we've historically endured most of the pain. [laughs] But, like, that sense of, like, it's us against the system, that there is hilarity in failure. And, at the end of the day, we're all just monkeys, like, poking at electrical sockets is, I think...I think it's healthy. [laughs]

+ +

WILL: That's really neat. I love it. This is one of my favorite questions. What advice would you give yourself if you could go back in time?

+ +

CHARITY: I don't know. I think I'd just give myself a thumbs up and go; it's going to be all right. I don't know; I wouldn't... I don't think that I would try to alter the time continuum [laughs] in any way. But I had a lot of anxiety when I was younger about going to hell and all this stuff. And so I think...but anything I said to my future self, I wouldn't have believed anyway. So yeah, I respectfully decline the offer.

+ +

VICTORIA: That's fair. I mean, I think about that a lot too actually, like, I sometimes think like, well, if I could go back to myself a year ago and just --

+ +

CHARITY: Yeah. I would look at me like I was stupid.

+ +

[laughter]

+ +

VICTORIA: That makes sense. It reminds me a little bit about what you said, though, like, doing SRE and everything upfront or the observability pieces and building it correctly in a way you can deploy fastly is like a gift to your future self. [laughs]

+ +

CHARITY: Yes, it is, with a bow. Yes, exactly.

+ +

VICTORIA: There you go. Well, all right. I think we are about ready to wrap up. Is there anything you would like to promote specifically?

+ +

CHARITY: We just launched this really cool little thing at Honeycomb. And you won't often hear me say the words cool and AI in proximity to each other, but we just launched this really dope little thing. It's a tool for using natural language to ask questions of your telemetry. So, if you just deployed something and you want to know, like, what's slow or did anything change, you can just ask it using English, and it does a ChatGPT thing and generates the right graphs for you. It's pretty sweet.

+ +

VICTORIA: That's really cool. So, if you have Honeycomb set up and working in your system and then you can just ask the little chatbot, "Hey, what's going on here?"

+ +

CHARITY: Yeah. What's the slowest endpoint? And it'll just tell you, which is great because I feel like I do not think graphically at all. My brain just really doesn't. So I have never been the person who's, like, creating dashboards or graphs. My friend Ben Hartshorne works with me, and he'll make the dashboards. And then I get up in the morning, and I bookmark them. And so we're sort of symbiotic.

+ +

But everyone can tweak a query, right? Once you have something that you know is, like, within spitting distance as the data you want, anyone can tweak it, but composing is really hard. So I feel like this really helps you get over that initial hurdle of, like, er, what do I break down by? What do I group by? What are the field names? You just ask it the question, and then you've got to click, click, click, and, like, get exactly what you want out of it. I think it's, like, a game changer.

+ +

VICTORIA: That sounds extremely cool. And we will certainly link to it in our show notes today. Thank you so much for being with us and spending the time, Charity.

+ +

CHARITY: Yeah, this was really fun.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Charity Majors.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+yu1dRzNS + + ]]> + + Will Larry + Victoria Guido + Charity Majors + + + 482: Evil Martians with Irina Nazarova + https://podcast.thoughtbot.com/482 + b2737f87-ba39-4230-8b29-8c5205a74764 + Thu, 06 Jul 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Irina Nazarova is CEO of Evil Martians, a product development consultancy that works with startups and established businesses while creating open-source products and services. + +Victoria talks to Irina about getting a sense of what people are interested in learning about or what kind of problems they have, how consulting and product development complement each other, and of course, the question on everyone's minds: Is Evil Martians really evil? 😈 + 33:46 + no + + + Irina Nazarova is CEO of Evil Martians, a product development consultancy that works with startups and established businesses while creating open-source products and services. +Victoria talks to Irina about getting a sense of what people are interested in learning about or what kind of problems they have, how consulting and product development complement each other, and of course, the question on everyone's minds: Is Evil Martians really evil? 😈 +Evil Martians (https://evilmartians.com/) +Follow Evil Martians on GitHub (https://github.com/evilmartians), Twitter (https://twitter.com/evilmartians), Instagram (https://www.instagram.com/evil.martians/), or LinkedIn (https://www.linkedin.com/company/evil-martians/). +Follow Irina Nazarova on LinkedIn (https://www.linkedin.com/in/nonconstant/), or Twitter (https://twitter.com/inazarova). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Irina Nazarova, CEO at Evil Martians, a product development consultancy that works with startups and established businesses while also creating open-source-based products and services. Irina, thanks for joining us. +IRINA: Hey, thank you for having me. +VICTORIA: You're welcome. Tell me a little bit about what's going on in your world this week. +IRINA: So I just returned from Rails SaaS in Athens, which was pretty incredible. It's a smaller conference, but it has amazing vibes, amazing people. And, like, I just loved it there in Athens. +VICTORIA: Mmm. +IRINA: And, yeah, I wonder how your experience was? Because I know you also went to Japan, right? +VICTORIA: Yeah, I went to RubyKaigi in Matsumoto last month. It was a good community, and to get to travel to a cool place was really fun. So I feel really lucky that I was able to get to go. Did you eat a lot of Greek food while you were there? +IRINA: Not that much. I was a speaker. So I was a bit nervous, and I skipped some meals. [chuckles] +VICTORIA: Oh no. [laughs] +IRINA: Just to prepare. But we did have a super nice dinner with Xavier Noria, and, well, we had some Greek wine. All right, we did that. +VICTORIA: That sounds fabulous. And, you know, I was going to ask you...one of my questions was about the conferences you've been attending because we met at RailsConf in Atlanta. And I saw you went to Rails SaaS and maybe some other ones recently. So, how has that been for you overall? +IRINA: It's amazing. I think, like, all the conferences are suddenly back. And the energy is different than maybe pre-COVID. I didn't really attend many conferences pre-COVID, but I did attend some. Now people are so eager to sort of reconnect. And me, I think, I feel like I'm only starting to make those connections. And it's so emotional to meet people that I only see on Twitter, but meeting them in person is magical for some reason. So this is what's happening. Like, to me, I'm just amazed by all this energy and support coming from the community towards many people, like, towards each other. +VICTORIA: I also feel amazed when I meet someone I've followed on Twitter for a long time but in real life [laughs]. I'm like, wow. That was Aaron Patterson for me. I was like, oh, this is someone I followed on Twitter a long time ago because I thought they were funny. And now they're a speaker at this conference I'm at [laughs], which is really nice. And do the conferences help you connect more to potential clients? Or what's, like, the business reason for attending all of these events? +IRINA: Good question. So I'm not expecting any, you know, direct sales to happen at the conferences. But, for example, I get to understand the clients, maybe better, the potential clients. And I get to connect with the existing clients, again, on a different level. So, if you have a client at the conference and you have a chance to see them in person, which we never do, and you as well, right? thoughtbot, you guys are not meeting the clients, like, the same thing. But if you get to meet even, like, some people from the client team, it's amazing. You can have a different type of connection. +And I met an engineer from our past client at RailsConf, and it was something incredible. I didn't expect him to react like the way he did. You know, the moment he realized that I am from Evil Martians, like, his facial expressions just immediately transformed into a big smile. And he said such warm words about the things we did, something like two or three years ago. I mean, you don't have anything better than that in this industry, right? There's nothing better than this sincere, you know, gratitude from a client. [chuckles] It's just amazing. +VICTORIA: I can relate to that, being from thoughtbot and attending Rails and RubyConfs. It is a nice feeling that people know the company or they know some open-source projects or some training materials we put out. And they're so grateful. [laughs] And I've only been at thoughtbot for a year. So, for me, I'm like, you're welcome. [laughs] I haven't done those things, but I will. And I will build on, you know, I think it also helps you kind of get a sense for what people are interested in learning about or what kind of problems they have. So, tell me more about that with Evil Martians. What is it all about? +IRINA: I think we share this feeling where we want to give back. You and me we both felt something where people were grateful for something the companies did. But now I feel I need to give back somehow, and maybe I'm sure you feel the same. And you're doing this podcast, which is important for the community and other things. You're open-sourcing the tooling. So both of our companies are actually sharing a lot of, like, philosophies, attitude, where it's great to be in the community that we're in. +So we also do something where we have some products like AnyCable. And it's interesting to talk to people using those products because we do have a much larger number of users of our products, you know, compared to our consulting clients, that's for sure. So the chances of meeting the users of AnyCable or, like, other products are pretty high at the conference, at Rails Conference. +VICTORIA: Right. So I find it similar that you have the consultancy side and you have the product development side. Take it a little bit further back to just where it all started with Evil Martians. Are you really evil? It's [laughs] [inaudible 05:47] question. +IRINA: Absolutely. We are. I mean, and we come from Mars. +VICTORIA: [laughs] +IRINA: Yeah, that's also true. It's a nice planet. We just make you think that it's a bad planet. +VICTORIA: Yeah, to keep you away. You don't want too many tourists. +IRINA: Yeah. +VICTORIA: Mm-hmm, that makes sense. [laughs] But I understand you all started as a consultancy from back-end engineers. And then, it grew into what it is today and having several side projects. So, how does the consultancy side and the product development side complement each other? +IRINA: Yeah, so the way it works, it's like a cycle of things where we work for startups like thoughtbot. And then, we work with 20 to 30 product engineering teams every year. And we notice which tools could be helpful for those teams and maybe would be helpful for us in those teams. So we're trying to enhance, improve our own productivity and the productivity of our clients. And that's how, I think, many of our open-source projects started. +Some of the open-source projects, I think, started, you know, for fun, for some other reasons. But many of them actually were useful in the client projects. So then we are passionate about this. So, for example, we have PostCSS. PostCSS was built by our Head of Front End, Andrey Sitnik. And it has something, like, 30,000, you know, GitHub Stars. And Autoprefixer, which is a PostCSS plugin, has, like, 20,000 GitHub Stars. So they are huge. I mean, it's not just about the stars; half of the internet is actually using PostCSS. +But PostCSS is popular, but we didn't turn it into a product. We are not commercializing it at all. But some of the other tools, let's call them tools, that we open-sourced, we could then envision how we could commercialize them. And the way it works is there are actually several strategies. For imgproxy, for example, we sell a paid version. But for AnyCable, which is another tool, we also sell a pro version. But we also earn consulting kind of get consulting clients come in for product development related to AnyCable, let's say. This is how AnyCable also helps us get consulting clients in a major way. +And then we ended up building a lot of tools for engineers. And then because we work with this type of tools, now we also have many developer tools clients. So we started specializing on developer tools. It's about half of the sort of revenue. And now it's getting even more interesting; I think, because we don't just build tools for engineers, you know, ourselves as side projects, like I said. But also, our consultant work is essentially the same thing. It's often commercial open source like Teleport, or HTTPie, tools for engineers. +This is exciting, I think, because now we can use this, you know, sort of connection with a type of audience, with a type of customer base, like the engineers, and we can leverage this experience in our consulting work, which is even better. And then we do open source with the products. They help us get consultant revenue, and then the experience on those projects helps us improve our products, and get product ideas, and get the first users for those products, et cetera. So it's like consulting helps product development, in our case. +VICTORIA: So, to play that back a little bit, it's almost like a cycle where they feed into each other where your engineers as they're working are also kind of, like, the customers who would be using the developer tools that you want to build. So you have some market research there. And then, you know, it all feeds back into each other so that the customers who are using your products are also likely to need your consultant services. [laughs] So that's a nice flow. +I wonder if there's anything surprising that came out during that kind of discovery process for product, for developer tools when you were first starting out, anything that you thought this is a tool maybe we think people are going to use. But then what was the reality, or [chuckles] what surprising things happened? +IRINA: A lot of things. But I think the main one that is sort of important is that there's a difference between open source and product a product. And the differences...okay, the way I'm trying to explain it is, like, between...it's, like, the difference between you and your friend from another industry. +Let's say you have a friend who is a microbiologist or something. And they are smart, right? They are smart in their own field. But if you give them your open source and ask them to take a look and you expect them to learn about it, to want to learn about it, they won't do it. They might use your product based on your open source, though, if it is easy if they know how to benefit from the product. +So what I'm trying to say is, turning open source into a product is like essentially building a new product, a new thing where the customer base is different because you want it to be wider. But you don't want them to learn about your open source and to be passionate about your technology. You want them to be passionate about the value they want to get, you know, about something they're building. So it's a shift in mentality that you got to make to make it work. +And pretty often, the people that collaborate with us in the open source are, you know, super different from the people who become our users. And users are great, but, you know, they don't want to learn too much about the internals and how it's supposed to work. They just want to click a button, and pay some money, and get the result, get the value from this. And, I don't know, it sounds simple. But it's actually a major shift in thinking about your product for you as an author of a tool, of a technology, of something. +VICTORIA: That's a really interesting distinction to make. So, when you're building open-source projects, you want to really invite people in and get people excited about how the whole tool works and how they can use it in their projects. And then, on the product side, you're wanting to make it super easy [chuckles] for people and make sure they're focusing on the value of what they're getting out of this product instead of having to, like, understand all the little details. Is that right? +IRINA: Yeah, exactly, exactly. +VICTORIA: That makes sense. And is there any product in particular that you're really excited about or you see a lot of growth in with Evil Martians? +IRINA: Yeah, I will talk about AnyCable. I will say AnyCable because I am personally involved in its development. So we did it with Vladimir Dementyev, the author. And the exciting part about AnyCable is the types of products and the types of functionality that can be built using AnyCable. So these are all kind of collaboration features, collaboration tools. The simplest are just the chats within your Rails application. And we have a lot of medical and healthcare applications that want to keep the data, the chat, you know, data on their own servers without sending them to some SaaSs. That's why they use AnyCable. +But also, we have other tools that use AnyCable to build collaboration. And we've helped some clients build this at Evil Martians using AnyCable, leveraging AnyCable. But it's exciting when, like, other companies do it themselves sort of without us just by using the product. So I don't like it when I don't have the collaboration within a tool that you're using with someone else together. +So I remember we were using something like a tool to create a service, and me and Vladimir we're using it simultaneously, you know, rewriting our edits all the time. And it was so frustrating because they didn't support collaboration in this tool. So the thing you do when you don't support the collaboration is just that every user, every player, is just rewriting what the other player did without saving. So it's, like, so frustrating, yeah. So I like it that our product is helping people fix this problem. +VICTORIA: Right. And to kind of summarize a little bit about what AnyCable does, is that it allows you to build Ruby on Rails apps and use any WebSocket server in any language as a replacement for the Ruby server. Is that accurate? +IRINA: Not exactly. So AnyCable is a server that stands next to your Ruby on Rails app and handles all the WebSockets. It's written in Go. It's super fast, super efficient, and scales efficiently. That's the most important part. Because you don't have to scale your entire Ruby on Rails app, your, you know, entire logic just to support the real-time load. So you only scale this small, efficient app, and it handles all the load and super quickly. And it also supports HTML over WebSockets updates, I mean, Hotwire and stuff. So it helps you scale your Hotwire updates as well. +So it's much faster than Ruby. It's much more efficient in terms of scaling. And, yeah, it's bidirectional, meaning that the server sends...by the way, it's just a drop-in replacement for ActionCable. So we're using ActionCable protocol. So we have the channels and stuff. So this means that we can send data, you know, from server broadcasts, the data from server, but we can also send the data from any client. +And one of the use cases for Any Cable, by the way, is different devices that send their coordinates or some other data in real-time. Like, we have some kind of cars sending us GPS data. It's cute, I think that you keep your business logic in your Ruby and Rails app, which is the place to write your business logic, which is the best place to write it. But the infrastructure and all the sort of delivery guarantees, order guarantees, all this kind of infrastructure layer is serviced, is handled by AnyCable, so you don't have to worry about it. +VICTORIA: That makes sense. Thank you for expanding on that. The interesting part for you on that is just to have this be able to be more collaborative, right? So we're working on this whole project together and not siloing into our different groups and building bespoke products to solve this problem. +IRINA: Yeah, I mean, I like collaborative UI as a norm, as something that has to be there. So, for any work-related tools...and we do work remotely now over the internet somehow. So I think any tool for any professionals has to have a collaborative regime, right? Support for collaboration because people want to work together. And that's the only way to work, I think. +VICTORIA: Yeah, that makes sense to me. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: Was there anything that's happened in the last few years maybe, or even that's come up in that discovery process as you're building these products that made you shift your strategic direction for Evil Martians? +IRINA: Yeah. I was initially looking for the right strategy regarding the products at Evil Martians. And what I mean is we were always passionate about building our own products, building our own products for engineers. We were always passionate about this. But, in order to make it work...and I think it works now, in a way, because we just had our other product, imgproxy, incorporate. And they raised a round of external financing, which is a win, I think. I mean, they have a long, long way to go. And we will try to support them. But, for me, it's important that we had an internal project, you know, graduate us and move beyond Evil Martians. +So something that I changed, I think, in the company together with the founders, for sure, is how we structure the incentives related to the internal products. What I'm trying to say is this: many companies that have an internal project will be looking to own those products. That's what I'm trying to say. And we are not looking for that. +What we're looking for is to have a founding team for a product and to make sure they have the majority of shares, that they are the owners of this product. Because we know that building a product is such a long way, and it's a difficult journey. And it takes years and decades to build them into something large, or profitable, or sustainable. So we want the people who are actually doing this to be properly motivated. +So something that I convinced the founders to do was to keep the share of Evil Martian's [inaudible 20:40] in those new products at a low level, which may sound counterintuitive for some businessmen, you know, for some owners of the business. They will say, "Well, this was something that was built internally in this company. So this is fully owned by this company." And I agree. Like, from the legal standpoint, this is correct. +But it doesn't make much sense if you think about it because you don't want to own, you know, 95% or 100% in something that its worth is zero or even, you know, a negative amount when you keep investing, and you're not getting any returns. But rather, you'd have 10%, 15%, 20% in something large and profitable. And that was the change, I think, where we said, look, we'll be investing in products in a certain way to make sure that the founders, you know, the team of authors is properly motivated. So they own this, and Evil Martians is just the first investor. +VICTORIA: That makes a lot of sense because I have been a part of companies where they wanted to reproduce and productize what they'd built for a client and make that something they owned. And I think you use an interesting approach to motivate people to contribute to a project like that by sharing the ownership. [laughs] And that makes a lot of sense to me. I'm curious, based on your response to that last question, how would you describe your leadership style as a CEO? +IRINA: There's no one way to be the CEO, I guess. So every person approaches this differently. And it's not that easy to be the CEO after the founder, [laughs] so, when, you know, the founder who was the CEO before hands you the job. It's not that easy. But I had trust and support. And I still have it, for sure, the trust and support from the founders and from the team because I've been with the company for four years already when I moved into this role. +And I think of my style as, first of all, you know, listen to the team, collect the information first. I imagine that I act like a consultant from a management consulting firm, but I didn't work in a management consulting firm. I didn't know how they actually work. But I imagine this is how they work. They sort of speak with every person on the team, and they try to figure out the blockers, the problems, and the aspirations of the team. +And then they try to find how to improve, you know, the collective utility, the utility of the group, how to improve the situation, maybe not for every single person but for the majority of them. And this was my initial approach and fixing some, maybe, problems in the company. But I would also try to come up with my own ideas as well for sure. But I rely on the team a lot. +So what I also did is I started relying on my leadership team much more than maybe the founder and CEO. So I'm relying on Andrey Sitnik, Head of Front End, on Roman Shamin, on Vladimir Dementyev, and other people, Victoria, Victoria Melnikova, our Head of New Business. And I'm relying on many people heavily, heavily. +And my goal is to make sure they see where we want to go and they each can contribute in a certain way. And I ask them how they can contribute. I'm not telling them how to do this, right? I trust their judgment in their area of expertise. But mostly, I just ask about what they can do. And this is how we work together. +VICTORIA: I like that. I like how you're really connecting with your team and finding out their strengths, and their struggles, and what they think should do. And then it's how do you enable them as a CEO to achieve this greater vision that you all want to work towards? So I really like that. What would you say is maybe your biggest challenge that you're facing right now? +IRINA: I actually challenged myself to become more publicly, sort of effective. [laughs] That's why I'm here, for example. So I realized we do have amazing engineers, amazing designers who are out there, you know, doing podcasts, doing open-source, building technologies, writing on our blog, doing all of this. And I realized that, well, I should do my part as well. And this was one of the goals for this year. +The other goal, the other challenge is so complicated that I'm not sure [laughs] I'm ready to talk about it yet. So some of the things I'm trying to do, to be honest, I'm not sure if I can do them at all, [laughs] and that's the problem. +So thoughtbot has the Incubator Program, right? And this means that thoughtbot presumably gets equity in those new businesses that people build with thoughtbot's help and guidance. And we're not doing this, but we're doing something else, also trying to make sure we have shares in the amazing businesses that we help grow and they become successful. And we're doing everything we can to make sure they are successful. And I want this company to have a share in the success of our clients, our products, all of that together. +VICTORIA: It would probably contribute to motivation, which is another factor you mentioned previously about. +IRINA: Yep. +VICTORIA: You know, right? [laughs] +IRINA: Absolutely, yeah. +VICTORIA: Right. We're all going to work a lot harder and collaborate a lot more together. That makes sense. +IRINA: Yeah, it also means, yeah, that it makes sense to have a share at Evil Martians. You know, as a part of the company, as an employee, you're getting a share in the company. But as you know, when you are a consulting company, it's sort of a complicated question, actually. If you're a startup and you are granting equity-like stock options to your team, this makes sense because if the company goes, you know, grows and goes public; those shares become something super valuable, like, super cool. +But we are not looking to grow our consulting company into something huge. That's for sure. It won't be possible, right? We are operating at this small niche, that's for sure. And we don't have that many amazing engineers, consultants, and it's so hard to hire them. So, anyways, we're not looking to grow that much, although we are growing. And this means that shares in our company do not mean the same thing as the shares in our clients. But if we participate in the success of our clients, then it sort of changes the whole motivation on our own team. This is what I'm thinking about. +VICTORIA: Yeah, that's a great question. And I wonder, to build on that, what success really looks like six months from now, or even, like, five years from now for Evil Martians. +IRINA: I want us to be recognized as the best consultancy, consulting company for developer tools, products. I know maybe it sounds ambitious, but this is what we are super passionate about. This is where we are accumulating the expertise. And this means I want people to think Evil Martians when they build a product for engineers. I want them to think about us and reach out to us. But also, I want us to build a number of successful products, commercial products for engineers, which is a huge challenge. Like, doing both it's not easy, that's for sure. But let's see. +VICTORIA: Yeah, it's good to be ambitious. And I love that journey for you. I'm excited to follow along. I wonder what advice you would give yourself if you could travel back in time to maybe when you first joined [chuckles] Evil Martians. +IRINA: I'd say, first of all, be confident in sharing your opinion because, well, especially for females, we do have a lot of, like, impostor syndrome when joining a tech company, for sure. But it's not just females, right? When you dig deeper, you realize that most people have impostor syndrome, regardless of their gender, background, et cetera. No one is this perfect image of a perfect engineer. It's just no one, really. And everyone has that. +And I want everyone who is joining the new company or maybe entering tech as the industry to be confident in sharing their opinions, well, humbly, respectfully but for sure. But don't shy away from asking the questions and from owning your agenda. That's what I want to say. +Like, the first year and maybe two years, I didn't own my own agenda. I didn't try to control the sort of to-do lists, the things I'm doing. And later, when I started thinking, you know, critically about my own priorities, I realized that I could bring more value by doing something else, maybe not, you know, not 100% different things but maybe by adding 20% to the mix and removing something that is actually not urgent, not important, you know, just randomly added to...just randomly asked by someone, [chuckles] you know. +So I think own your own agenda. Be more confident and look forward. Try to imagine the future that you want. And, for some reason, it works. I don't know how, but it does work. So you start imagining the future. You share it with the team; you discuss it with the team. And this is the magic of the teamwork. Maybe you cannot do it alone, but as a team, so much more is possible. +VICTORIA: I love that. And thank you so much for sharing. I'm sure there's maybe a future Irina out there [laughs] who's hearing that advice now and can take it into their work. What if your younger self could travel forward in time, and what advice would they give you now? +IRINA: Oh, this is funny. Maybe my younger self would say that I should spend more time with my friends. [laughs] That's what I should do, yeah. +VICTORIA: That's never bad advice, I think. I love it. Okay. So, is there anything that you would like to promote? +IRINA: This is not tech-related at all. But I want to ask the listeners to donate to the non-profit organizations supporting people in Ukraine because people are suffering in Ukraine. And there was this explosion of the dam, and the floods, everything. And it's never been as important as it is now to support the non-profits. And I can suggest the Nova Ukraine non-profit organization. It's an American organization, but they send all their money to the local initiatives. So it's a great way to support a good cause. +VICTORIA: Yes, wonderful, and we can include that into the show notes. Thank you so much for joining me today, Irina. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you could email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Irina Nazarova. + + + Irina Nazarova is CEO of Evil Martians, a product development consultancy that works with startups and established businesses while creating open-source products and services.

+ +

Victoria talks to Irina about getting a sense of what people are interested in learning about or what kind of problems they have, how consulting and product development complement each other, and of course, the question on everyone's minds: Is Evil Martians really evil? 😈

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Irina Nazarova, CEO at Evil Martians, a product development consultancy that works with startups and established businesses while also creating open-source-based products and services. Irina, thanks for joining us.

+ +

IRINA: Hey, thank you for having me.

+ +

VICTORIA: You're welcome. Tell me a little bit about what's going on in your world this week.

+ +

IRINA: So I just returned from Rails SaaS in Athens, which was pretty incredible. It's a smaller conference, but it has amazing vibes, amazing people. And, like, I just loved it there in Athens.

+ +

VICTORIA: Mmm.

+ +

IRINA: And, yeah, I wonder how your experience was? Because I know you also went to Japan, right?

+ +

VICTORIA: Yeah, I went to RubyKaigi in Matsumoto last month. It was a good community, and to get to travel to a cool place was really fun. So I feel really lucky that I was able to get to go. Did you eat a lot of Greek food while you were there?

+ +

IRINA: Not that much. I was a speaker. So I was a bit nervous, and I skipped some meals. [chuckles]

+ +

VICTORIA: Oh no. [laughs]

+ +

IRINA: Just to prepare. But we did have a super nice dinner with Xavier Noria, and, well, we had some Greek wine. All right, we did that.

+ +

VICTORIA: That sounds fabulous. And, you know, I was going to ask you...one of my questions was about the conferences you've been attending because we met at RailsConf in Atlanta. And I saw you went to Rails SaaS and maybe some other ones recently. So, how has that been for you overall?

+ +

IRINA: It's amazing. I think, like, all the conferences are suddenly back. And the energy is different than maybe pre-COVID. I didn't really attend many conferences pre-COVID, but I did attend some. Now people are so eager to sort of reconnect. And me, I think, I feel like I'm only starting to make those connections. And it's so emotional to meet people that I only see on Twitter, but meeting them in person is magical for some reason. So this is what's happening. Like, to me, I'm just amazed by all this energy and support coming from the community towards many people, like, towards each other.

+ +

VICTORIA: I also feel amazed when I meet someone I've followed on Twitter for a long time but in real life [laughs]. I'm like, wow. That was Aaron Patterson for me. I was like, oh, this is someone I followed on Twitter a long time ago because I thought they were funny. And now they're a speaker at this conference I'm at [laughs], which is really nice. And do the conferences help you connect more to potential clients? Or what's, like, the business reason for attending all of these events?

+ +

IRINA: Good question. So I'm not expecting any, you know, direct sales to happen at the conferences. But, for example, I get to understand the clients, maybe better, the potential clients. And I get to connect with the existing clients, again, on a different level. So, if you have a client at the conference and you have a chance to see them in person, which we never do, and you as well, right? thoughtbot, you guys are not meeting the clients, like, the same thing. But if you get to meet even, like, some people from the client team, it's amazing. You can have a different type of connection.

+ +

And I met an engineer from our past client at RailsConf, and it was something incredible. I didn't expect him to react like the way he did. You know, the moment he realized that I am from Evil Martians, like, his facial expressions just immediately transformed into a big smile. And he said such warm words about the things we did, something like two or three years ago. I mean, you don't have anything better than that in this industry, right? There's nothing better than this sincere, you know, gratitude from a client. [chuckles] It's just amazing.

+ +

VICTORIA: I can relate to that, being from thoughtbot and attending Rails and RubyConfs. It is a nice feeling that people know the company or they know some open-source projects or some training materials we put out. And they're so grateful. [laughs] And I've only been at thoughtbot for a year. So, for me, I'm like, you're welcome. [laughs] I haven't done those things, but I will. And I will build on, you know, I think it also helps you kind of get a sense for what people are interested in learning about or what kind of problems they have. So, tell me more about that with Evil Martians. What is it all about?

+ +

IRINA: I think we share this feeling where we want to give back. You and me we both felt something where people were grateful for something the companies did. But now I feel I need to give back somehow, and maybe I'm sure you feel the same. And you're doing this podcast, which is important for the community and other things. You're open-sourcing the tooling. So both of our companies are actually sharing a lot of, like, philosophies, attitude, where it's great to be in the community that we're in.

+ +

So we also do something where we have some products like AnyCable. And it's interesting to talk to people using those products because we do have a much larger number of users of our products, you know, compared to our consulting clients, that's for sure. So the chances of meeting the users of AnyCable or, like, other products are pretty high at the conference, at Rails Conference.

+ +

VICTORIA: Right. So I find it similar that you have the consultancy side and you have the product development side. Take it a little bit further back to just where it all started with Evil Martians. Are you really evil? It's [laughs] [inaudible 05:47] question.

+ +

IRINA: Absolutely. We are. I mean, and we come from Mars.

+ +

VICTORIA: [laughs]

+ +

IRINA: Yeah, that's also true. It's a nice planet. We just make you think that it's a bad planet.

+ +

VICTORIA: Yeah, to keep you away. You don't want too many tourists.

+ +

IRINA: Yeah.

+ +

VICTORIA: Mm-hmm, that makes sense. [laughs] But I understand you all started as a consultancy from back-end engineers. And then, it grew into what it is today and having several side projects. So, how does the consultancy side and the product development side complement each other?

+ +

IRINA: Yeah, so the way it works, it's like a cycle of things where we work for startups like thoughtbot. And then, we work with 20 to 30 product engineering teams every year. And we notice which tools could be helpful for those teams and maybe would be helpful for us in those teams. So we're trying to enhance, improve our own productivity and the productivity of our clients. And that's how, I think, many of our open-source projects started.

+ +

Some of the open-source projects, I think, started, you know, for fun, for some other reasons. But many of them actually were useful in the client projects. So then we are passionate about this. So, for example, we have PostCSS. PostCSS was built by our Head of Front End, Andrey Sitnik. And it has something, like, 30,000, you know, GitHub Stars. And Autoprefixer, which is a PostCSS plugin, has, like, 20,000 GitHub Stars. So they are huge. I mean, it's not just about the stars; half of the internet is actually using PostCSS.

+ +

But PostCSS is popular, but we didn't turn it into a product. We are not commercializing it at all. But some of the other tools, let's call them tools, that we open-sourced, we could then envision how we could commercialize them. And the way it works is there are actually several strategies. For imgproxy, for example, we sell a paid version. But for AnyCable, which is another tool, we also sell a pro version. But we also earn consulting kind of get consulting clients come in for product development related to AnyCable, let's say. This is how AnyCable also helps us get consulting clients in a major way.

+ +

And then we ended up building a lot of tools for engineers. And then because we work with this type of tools, now we also have many developer tools clients. So we started specializing on developer tools. It's about half of the sort of revenue. And now it's getting even more interesting; I think, because we don't just build tools for engineers, you know, ourselves as side projects, like I said. But also, our consultant work is essentially the same thing. It's often commercial open source like Teleport, or HTTPie, tools for engineers.

+ +

This is exciting, I think, because now we can use this, you know, sort of connection with a type of audience, with a type of customer base, like the engineers, and we can leverage this experience in our consulting work, which is even better. And then we do open source with the products. They help us get consultant revenue, and then the experience on those projects helps us improve our products, and get product ideas, and get the first users for those products, et cetera. So it's like consulting helps product development, in our case.

+ +

VICTORIA: So, to play that back a little bit, it's almost like a cycle where they feed into each other where your engineers as they're working are also kind of, like, the customers who would be using the developer tools that you want to build. So you have some market research there. And then, you know, it all feeds back into each other so that the customers who are using your products are also likely to need your consultant services. [laughs] So that's a nice flow.

+ +

I wonder if there's anything surprising that came out during that kind of discovery process for product, for developer tools when you were first starting out, anything that you thought this is a tool maybe we think people are going to use. But then what was the reality, or [chuckles] what surprising things happened?

+ +

IRINA: A lot of things. But I think the main one that is sort of important is that there's a difference between open source and product a product. And the differences...okay, the way I'm trying to explain it is, like, between...it's, like, the difference between you and your friend from another industry.

+ +

Let's say you have a friend who is a microbiologist or something. And they are smart, right? They are smart in their own field. But if you give them your open source and ask them to take a look and you expect them to learn about it, to want to learn about it, they won't do it. They might use your product based on your open source, though, if it is easy if they know how to benefit from the product.

+ +

So what I'm trying to say is, turning open source into a product is like essentially building a new product, a new thing where the customer base is different because you want it to be wider. But you don't want them to learn about your open source and to be passionate about your technology. You want them to be passionate about the value they want to get, you know, about something they're building. So it's a shift in mentality that you got to make to make it work.

+ +

And pretty often, the people that collaborate with us in the open source are, you know, super different from the people who become our users. And users are great, but, you know, they don't want to learn too much about the internals and how it's supposed to work. They just want to click a button, and pay some money, and get the result, get the value from this. And, I don't know, it sounds simple. But it's actually a major shift in thinking about your product for you as an author of a tool, of a technology, of something.

+ +

VICTORIA: That's a really interesting distinction to make. So, when you're building open-source projects, you want to really invite people in and get people excited about how the whole tool works and how they can use it in their projects. And then, on the product side, you're wanting to make it super easy [chuckles] for people and make sure they're focusing on the value of what they're getting out of this product instead of having to, like, understand all the little details. Is that right?

+ +

IRINA: Yeah, exactly, exactly.

+ +

VICTORIA: That makes sense. And is there any product in particular that you're really excited about or you see a lot of growth in with Evil Martians?

+ +

IRINA: Yeah, I will talk about AnyCable. I will say AnyCable because I am personally involved in its development. So we did it with Vladimir Dementyev, the author. And the exciting part about AnyCable is the types of products and the types of functionality that can be built using AnyCable. So these are all kind of collaboration features, collaboration tools. The simplest are just the chats within your Rails application. And we have a lot of medical and healthcare applications that want to keep the data, the chat, you know, data on their own servers without sending them to some SaaSs. That's why they use AnyCable.

+ +

But also, we have other tools that use AnyCable to build collaboration. And we've helped some clients build this at Evil Martians using AnyCable, leveraging AnyCable. But it's exciting when, like, other companies do it themselves sort of without us just by using the product. So I don't like it when I don't have the collaboration within a tool that you're using with someone else together.

+ +

So I remember we were using something like a tool to create a service, and me and Vladimir we're using it simultaneously, you know, rewriting our edits all the time. And it was so frustrating because they didn't support collaboration in this tool. So the thing you do when you don't support the collaboration is just that every user, every player, is just rewriting what the other player did without saving. So it's, like, so frustrating, yeah. So I like it that our product is helping people fix this problem.

+ +

VICTORIA: Right. And to kind of summarize a little bit about what AnyCable does, is that it allows you to build Ruby on Rails apps and use any WebSocket server in any language as a replacement for the Ruby server. Is that accurate?

+ +

IRINA: Not exactly. So AnyCable is a server that stands next to your Ruby on Rails app and handles all the WebSockets. It's written in Go. It's super fast, super efficient, and scales efficiently. That's the most important part. Because you don't have to scale your entire Ruby on Rails app, your, you know, entire logic just to support the real-time load. So you only scale this small, efficient app, and it handles all the load and super quickly. And it also supports HTML over WebSockets updates, I mean, Hotwire and stuff. So it helps you scale your Hotwire updates as well.

+ +

So it's much faster than Ruby. It's much more efficient in terms of scaling. And, yeah, it's bidirectional, meaning that the server sends...by the way, it's just a drop-in replacement for ActionCable. So we're using ActionCable protocol. So we have the channels and stuff. So this means that we can send data, you know, from server broadcasts, the data from server, but we can also send the data from any client.

+ +

And one of the use cases for Any Cable, by the way, is different devices that send their coordinates or some other data in real-time. Like, we have some kind of cars sending us GPS data. It's cute, I think that you keep your business logic in your Ruby and Rails app, which is the place to write your business logic, which is the best place to write it. But the infrastructure and all the sort of delivery guarantees, order guarantees, all this kind of infrastructure layer is serviced, is handled by AnyCable, so you don't have to worry about it.

+ +

VICTORIA: That makes sense. Thank you for expanding on that. The interesting part for you on that is just to have this be able to be more collaborative, right? So we're working on this whole project together and not siloing into our different groups and building bespoke products to solve this problem.

+ +

IRINA: Yeah, I mean, I like collaborative UI as a norm, as something that has to be there. So, for any work-related tools...and we do work remotely now over the internet somehow. So I think any tool for any professionals has to have a collaborative regime, right? Support for collaboration because people want to work together. And that's the only way to work, I think.

+ +

VICTORIA: Yeah, that makes sense to me.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: Was there anything that's happened in the last few years maybe, or even that's come up in that discovery process as you're building these products that made you shift your strategic direction for Evil Martians?

+ +

IRINA: Yeah. I was initially looking for the right strategy regarding the products at Evil Martians. And what I mean is we were always passionate about building our own products, building our own products for engineers. We were always passionate about this. But, in order to make it work...and I think it works now, in a way, because we just had our other product, imgproxy, incorporate. And they raised a round of external financing, which is a win, I think. I mean, they have a long, long way to go. And we will try to support them. But, for me, it's important that we had an internal project, you know, graduate us and move beyond Evil Martians.

+ +

So something that I changed, I think, in the company together with the founders, for sure, is how we structure the incentives related to the internal products. What I'm trying to say is this: many companies that have an internal project will be looking to own those products. That's what I'm trying to say. And we are not looking for that.

+ +

What we're looking for is to have a founding team for a product and to make sure they have the majority of shares, that they are the owners of this product. Because we know that building a product is such a long way, and it's a difficult journey. And it takes years and decades to build them into something large, or profitable, or sustainable. So we want the people who are actually doing this to be properly motivated.

+ +

So something that I convinced the founders to do was to keep the share of Evil Martian's [inaudible 20:40] in those new products at a low level, which may sound counterintuitive for some businessmen, you know, for some owners of the business. They will say, "Well, this was something that was built internally in this company. So this is fully owned by this company." And I agree. Like, from the legal standpoint, this is correct.

+ +

But it doesn't make much sense if you think about it because you don't want to own, you know, 95% or 100% in something that its worth is zero or even, you know, a negative amount when you keep investing, and you're not getting any returns. But rather, you'd have 10%, 15%, 20% in something large and profitable. And that was the change, I think, where we said, look, we'll be investing in products in a certain way to make sure that the founders, you know, the team of authors is properly motivated. So they own this, and Evil Martians is just the first investor.

+ +

VICTORIA: That makes a lot of sense because I have been a part of companies where they wanted to reproduce and productize what they'd built for a client and make that something they owned. And I think you use an interesting approach to motivate people to contribute to a project like that by sharing the ownership. [laughs] And that makes a lot of sense to me. I'm curious, based on your response to that last question, how would you describe your leadership style as a CEO?

+ +

IRINA: There's no one way to be the CEO, I guess. So every person approaches this differently. And it's not that easy to be the CEO after the founder, [laughs] so, when, you know, the founder who was the CEO before hands you the job. It's not that easy. But I had trust and support. And I still have it, for sure, the trust and support from the founders and from the team because I've been with the company for four years already when I moved into this role.

+ +

And I think of my style as, first of all, you know, listen to the team, collect the information first. I imagine that I act like a consultant from a management consulting firm, but I didn't work in a management consulting firm. I didn't know how they actually work. But I imagine this is how they work. They sort of speak with every person on the team, and they try to figure out the blockers, the problems, and the aspirations of the team.

+ +

And then they try to find how to improve, you know, the collective utility, the utility of the group, how to improve the situation, maybe not for every single person but for the majority of them. And this was my initial approach and fixing some, maybe, problems in the company. But I would also try to come up with my own ideas as well for sure. But I rely on the team a lot.

+ +

So what I also did is I started relying on my leadership team much more than maybe the founder and CEO. So I'm relying on Andrey Sitnik, Head of Front End, on Roman Shamin, on Vladimir Dementyev, and other people, Victoria, Victoria Melnikova, our Head of New Business. And I'm relying on many people heavily, heavily.

+ +

And my goal is to make sure they see where we want to go and they each can contribute in a certain way. And I ask them how they can contribute. I'm not telling them how to do this, right? I trust their judgment in their area of expertise. But mostly, I just ask about what they can do. And this is how we work together.

+ +

VICTORIA: I like that. I like how you're really connecting with your team and finding out their strengths, and their struggles, and what they think should do. And then it's how do you enable them as a CEO to achieve this greater vision that you all want to work towards? So I really like that. What would you say is maybe your biggest challenge that you're facing right now?

+ +

IRINA: I actually challenged myself to become more publicly, sort of effective. [laughs] That's why I'm here, for example. So I realized we do have amazing engineers, amazing designers who are out there, you know, doing podcasts, doing open-source, building technologies, writing on our blog, doing all of this. And I realized that, well, I should do my part as well. And this was one of the goals for this year.

+ +

The other goal, the other challenge is so complicated that I'm not sure [laughs] I'm ready to talk about it yet. So some of the things I'm trying to do, to be honest, I'm not sure if I can do them at all, [laughs] and that's the problem.

+ +

So thoughtbot has the Incubator Program, right? And this means that thoughtbot presumably gets equity in those new businesses that people build with thoughtbot's help and guidance. And we're not doing this, but we're doing something else, also trying to make sure we have shares in the amazing businesses that we help grow and they become successful. And we're doing everything we can to make sure they are successful. And I want this company to have a share in the success of our clients, our products, all of that together.

+ +

VICTORIA: It would probably contribute to motivation, which is another factor you mentioned previously about.

+ +

IRINA: Yep.

+ +

VICTORIA: You know, right? [laughs]

+ +

IRINA: Absolutely, yeah.

+ +

VICTORIA: Right. We're all going to work a lot harder and collaborate a lot more together. That makes sense.

+ +

IRINA: Yeah, it also means, yeah, that it makes sense to have a share at Evil Martians. You know, as a part of the company, as an employee, you're getting a share in the company. But as you know, when you are a consulting company, it's sort of a complicated question, actually. If you're a startup and you are granting equity-like stock options to your team, this makes sense because if the company goes, you know, grows and goes public; those shares become something super valuable, like, super cool.

+ +

But we are not looking to grow our consulting company into something huge. That's for sure. It won't be possible, right? We are operating at this small niche, that's for sure. And we don't have that many amazing engineers, consultants, and it's so hard to hire them. So, anyways, we're not looking to grow that much, although we are growing. And this means that shares in our company do not mean the same thing as the shares in our clients. But if we participate in the success of our clients, then it sort of changes the whole motivation on our own team. This is what I'm thinking about.

+ +

VICTORIA: Yeah, that's a great question. And I wonder, to build on that, what success really looks like six months from now, or even, like, five years from now for Evil Martians.

+ +

IRINA: I want us to be recognized as the best consultancy, consulting company for developer tools, products. I know maybe it sounds ambitious, but this is what we are super passionate about. This is where we are accumulating the expertise. And this means I want people to think Evil Martians when they build a product for engineers. I want them to think about us and reach out to us. But also, I want us to build a number of successful products, commercial products for engineers, which is a huge challenge. Like, doing both it's not easy, that's for sure. But let's see.

+ +

VICTORIA: Yeah, it's good to be ambitious. And I love that journey for you. I'm excited to follow along. I wonder what advice you would give yourself if you could travel back in time to maybe when you first joined [chuckles] Evil Martians.

+ +

IRINA: I'd say, first of all, be confident in sharing your opinion because, well, especially for females, we do have a lot of, like, impostor syndrome when joining a tech company, for sure. But it's not just females, right? When you dig deeper, you realize that most people have impostor syndrome, regardless of their gender, background, et cetera. No one is this perfect image of a perfect engineer. It's just no one, really. And everyone has that.

+ +

And I want everyone who is joining the new company or maybe entering tech as the industry to be confident in sharing their opinions, well, humbly, respectfully but for sure. But don't shy away from asking the questions and from owning your agenda. That's what I want to say.

+ +

Like, the first year and maybe two years, I didn't own my own agenda. I didn't try to control the sort of to-do lists, the things I'm doing. And later, when I started thinking, you know, critically about my own priorities, I realized that I could bring more value by doing something else, maybe not, you know, not 100% different things but maybe by adding 20% to the mix and removing something that is actually not urgent, not important, you know, just randomly added to...just randomly asked by someone, [chuckles] you know.

+ +

So I think own your own agenda. Be more confident and look forward. Try to imagine the future that you want. And, for some reason, it works. I don't know how, but it does work. So you start imagining the future. You share it with the team; you discuss it with the team. And this is the magic of the teamwork. Maybe you cannot do it alone, but as a team, so much more is possible.

+ +

VICTORIA: I love that. And thank you so much for sharing. I'm sure there's maybe a future Irina out there [laughs] who's hearing that advice now and can take it into their work. What if your younger self could travel forward in time, and what advice would they give you now?

+ +

IRINA: Oh, this is funny. Maybe my younger self would say that I should spend more time with my friends. [laughs] That's what I should do, yeah.

+ +

VICTORIA: That's never bad advice, I think. I love it. Okay. So, is there anything that you would like to promote?

+ +

IRINA: This is not tech-related at all. But I want to ask the listeners to donate to the non-profit organizations supporting people in Ukraine because people are suffering in Ukraine. And there was this explosion of the dam, and the floods, everything. And it's never been as important as it is now to support the non-profits. And I can suggest the Nova Ukraine non-profit organization. It's an American organization, but they send all their money to the local initiatives. So it's a great way to support a good cause.

+ +

VICTORIA: Yes, wonderful, and we can include that into the show notes. Thank you so much for joining me today, Irina.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you could email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Irina Nazarova.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Irina Nazarova is CEO of Evil Martians, a product development consultancy that works with startups and established businesses while creating open-source products and services.

+ +

Victoria talks to Irina about getting a sense of what people are interested in learning about or what kind of problems they have, how consulting and product development complement each other, and of course, the question on everyone's minds: Is Evil Martians really evil? 😈

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Irina Nazarova, CEO at Evil Martians, a product development consultancy that works with startups and established businesses while also creating open-source-based products and services. Irina, thanks for joining us.

+ +

IRINA: Hey, thank you for having me.

+ +

VICTORIA: You're welcome. Tell me a little bit about what's going on in your world this week.

+ +

IRINA: So I just returned from Rails SaaS in Athens, which was pretty incredible. It's a smaller conference, but it has amazing vibes, amazing people. And, like, I just loved it there in Athens.

+ +

VICTORIA: Mmm.

+ +

IRINA: And, yeah, I wonder how your experience was? Because I know you also went to Japan, right?

+ +

VICTORIA: Yeah, I went to RubyKaigi in Matsumoto last month. It was a good community, and to get to travel to a cool place was really fun. So I feel really lucky that I was able to get to go. Did you eat a lot of Greek food while you were there?

+ +

IRINA: Not that much. I was a speaker. So I was a bit nervous, and I skipped some meals. [chuckles]

+ +

VICTORIA: Oh no. [laughs]

+ +

IRINA: Just to prepare. But we did have a super nice dinner with Xavier Noria, and, well, we had some Greek wine. All right, we did that.

+ +

VICTORIA: That sounds fabulous. And, you know, I was going to ask you...one of my questions was about the conferences you've been attending because we met at RailsConf in Atlanta. And I saw you went to Rails SaaS and maybe some other ones recently. So, how has that been for you overall?

+ +

IRINA: It's amazing. I think, like, all the conferences are suddenly back. And the energy is different than maybe pre-COVID. I didn't really attend many conferences pre-COVID, but I did attend some. Now people are so eager to sort of reconnect. And me, I think, I feel like I'm only starting to make those connections. And it's so emotional to meet people that I only see on Twitter, but meeting them in person is magical for some reason. So this is what's happening. Like, to me, I'm just amazed by all this energy and support coming from the community towards many people, like, towards each other.

+ +

VICTORIA: I also feel amazed when I meet someone I've followed on Twitter for a long time but in real life [laughs]. I'm like, wow. That was Aaron Patterson for me. I was like, oh, this is someone I followed on Twitter a long time ago because I thought they were funny. And now they're a speaker at this conference I'm at [laughs], which is really nice. And do the conferences help you connect more to potential clients? Or what's, like, the business reason for attending all of these events?

+ +

IRINA: Good question. So I'm not expecting any, you know, direct sales to happen at the conferences. But, for example, I get to understand the clients, maybe better, the potential clients. And I get to connect with the existing clients, again, on a different level. So, if you have a client at the conference and you have a chance to see them in person, which we never do, and you as well, right? thoughtbot, you guys are not meeting the clients, like, the same thing. But if you get to meet even, like, some people from the client team, it's amazing. You can have a different type of connection.

+ +

And I met an engineer from our past client at RailsConf, and it was something incredible. I didn't expect him to react like the way he did. You know, the moment he realized that I am from Evil Martians, like, his facial expressions just immediately transformed into a big smile. And he said such warm words about the things we did, something like two or three years ago. I mean, you don't have anything better than that in this industry, right? There's nothing better than this sincere, you know, gratitude from a client. [chuckles] It's just amazing.

+ +

VICTORIA: I can relate to that, being from thoughtbot and attending Rails and RubyConfs. It is a nice feeling that people know the company or they know some open-source projects or some training materials we put out. And they're so grateful. [laughs] And I've only been at thoughtbot for a year. So, for me, I'm like, you're welcome. [laughs] I haven't done those things, but I will. And I will build on, you know, I think it also helps you kind of get a sense for what people are interested in learning about or what kind of problems they have. So, tell me more about that with Evil Martians. What is it all about?

+ +

IRINA: I think we share this feeling where we want to give back. You and me we both felt something where people were grateful for something the companies did. But now I feel I need to give back somehow, and maybe I'm sure you feel the same. And you're doing this podcast, which is important for the community and other things. You're open-sourcing the tooling. So both of our companies are actually sharing a lot of, like, philosophies, attitude, where it's great to be in the community that we're in.

+ +

So we also do something where we have some products like AnyCable. And it's interesting to talk to people using those products because we do have a much larger number of users of our products, you know, compared to our consulting clients, that's for sure. So the chances of meeting the users of AnyCable or, like, other products are pretty high at the conference, at Rails Conference.

+ +

VICTORIA: Right. So I find it similar that you have the consultancy side and you have the product development side. Take it a little bit further back to just where it all started with Evil Martians. Are you really evil? It's [laughs] [inaudible 05:47] question.

+ +

IRINA: Absolutely. We are. I mean, and we come from Mars.

+ +

VICTORIA: [laughs]

+ +

IRINA: Yeah, that's also true. It's a nice planet. We just make you think that it's a bad planet.

+ +

VICTORIA: Yeah, to keep you away. You don't want too many tourists.

+ +

IRINA: Yeah.

+ +

VICTORIA: Mm-hmm, that makes sense. [laughs] But I understand you all started as a consultancy from back-end engineers. And then, it grew into what it is today and having several side projects. So, how does the consultancy side and the product development side complement each other?

+ +

IRINA: Yeah, so the way it works, it's like a cycle of things where we work for startups like thoughtbot. And then, we work with 20 to 30 product engineering teams every year. And we notice which tools could be helpful for those teams and maybe would be helpful for us in those teams. So we're trying to enhance, improve our own productivity and the productivity of our clients. And that's how, I think, many of our open-source projects started.

+ +

Some of the open-source projects, I think, started, you know, for fun, for some other reasons. But many of them actually were useful in the client projects. So then we are passionate about this. So, for example, we have PostCSS. PostCSS was built by our Head of Front End, Andrey Sitnik. And it has something, like, 30,000, you know, GitHub Stars. And Autoprefixer, which is a PostCSS plugin, has, like, 20,000 GitHub Stars. So they are huge. I mean, it's not just about the stars; half of the internet is actually using PostCSS.

+ +

But PostCSS is popular, but we didn't turn it into a product. We are not commercializing it at all. But some of the other tools, let's call them tools, that we open-sourced, we could then envision how we could commercialize them. And the way it works is there are actually several strategies. For imgproxy, for example, we sell a paid version. But for AnyCable, which is another tool, we also sell a pro version. But we also earn consulting kind of get consulting clients come in for product development related to AnyCable, let's say. This is how AnyCable also helps us get consulting clients in a major way.

+ +

And then we ended up building a lot of tools for engineers. And then because we work with this type of tools, now we also have many developer tools clients. So we started specializing on developer tools. It's about half of the sort of revenue. And now it's getting even more interesting; I think, because we don't just build tools for engineers, you know, ourselves as side projects, like I said. But also, our consultant work is essentially the same thing. It's often commercial open source like Teleport, or HTTPie, tools for engineers.

+ +

This is exciting, I think, because now we can use this, you know, sort of connection with a type of audience, with a type of customer base, like the engineers, and we can leverage this experience in our consulting work, which is even better. And then we do open source with the products. They help us get consultant revenue, and then the experience on those projects helps us improve our products, and get product ideas, and get the first users for those products, et cetera. So it's like consulting helps product development, in our case.

+ +

VICTORIA: So, to play that back a little bit, it's almost like a cycle where they feed into each other where your engineers as they're working are also kind of, like, the customers who would be using the developer tools that you want to build. So you have some market research there. And then, you know, it all feeds back into each other so that the customers who are using your products are also likely to need your consultant services. [laughs] So that's a nice flow.

+ +

I wonder if there's anything surprising that came out during that kind of discovery process for product, for developer tools when you were first starting out, anything that you thought this is a tool maybe we think people are going to use. But then what was the reality, or [chuckles] what surprising things happened?

+ +

IRINA: A lot of things. But I think the main one that is sort of important is that there's a difference between open source and product a product. And the differences...okay, the way I'm trying to explain it is, like, between...it's, like, the difference between you and your friend from another industry.

+ +

Let's say you have a friend who is a microbiologist or something. And they are smart, right? They are smart in their own field. But if you give them your open source and ask them to take a look and you expect them to learn about it, to want to learn about it, they won't do it. They might use your product based on your open source, though, if it is easy if they know how to benefit from the product.

+ +

So what I'm trying to say is, turning open source into a product is like essentially building a new product, a new thing where the customer base is different because you want it to be wider. But you don't want them to learn about your open source and to be passionate about your technology. You want them to be passionate about the value they want to get, you know, about something they're building. So it's a shift in mentality that you got to make to make it work.

+ +

And pretty often, the people that collaborate with us in the open source are, you know, super different from the people who become our users. And users are great, but, you know, they don't want to learn too much about the internals and how it's supposed to work. They just want to click a button, and pay some money, and get the result, get the value from this. And, I don't know, it sounds simple. But it's actually a major shift in thinking about your product for you as an author of a tool, of a technology, of something.

+ +

VICTORIA: That's a really interesting distinction to make. So, when you're building open-source projects, you want to really invite people in and get people excited about how the whole tool works and how they can use it in their projects. And then, on the product side, you're wanting to make it super easy [chuckles] for people and make sure they're focusing on the value of what they're getting out of this product instead of having to, like, understand all the little details. Is that right?

+ +

IRINA: Yeah, exactly, exactly.

+ +

VICTORIA: That makes sense. And is there any product in particular that you're really excited about or you see a lot of growth in with Evil Martians?

+ +

IRINA: Yeah, I will talk about AnyCable. I will say AnyCable because I am personally involved in its development. So we did it with Vladimir Dementyev, the author. And the exciting part about AnyCable is the types of products and the types of functionality that can be built using AnyCable. So these are all kind of collaboration features, collaboration tools. The simplest are just the chats within your Rails application. And we have a lot of medical and healthcare applications that want to keep the data, the chat, you know, data on their own servers without sending them to some SaaSs. That's why they use AnyCable.

+ +

But also, we have other tools that use AnyCable to build collaboration. And we've helped some clients build this at Evil Martians using AnyCable, leveraging AnyCable. But it's exciting when, like, other companies do it themselves sort of without us just by using the product. So I don't like it when I don't have the collaboration within a tool that you're using with someone else together.

+ +

So I remember we were using something like a tool to create a service, and me and Vladimir we're using it simultaneously, you know, rewriting our edits all the time. And it was so frustrating because they didn't support collaboration in this tool. So the thing you do when you don't support the collaboration is just that every user, every player, is just rewriting what the other player did without saving. So it's, like, so frustrating, yeah. So I like it that our product is helping people fix this problem.

+ +

VICTORIA: Right. And to kind of summarize a little bit about what AnyCable does, is that it allows you to build Ruby on Rails apps and use any WebSocket server in any language as a replacement for the Ruby server. Is that accurate?

+ +

IRINA: Not exactly. So AnyCable is a server that stands next to your Ruby on Rails app and handles all the WebSockets. It's written in Go. It's super fast, super efficient, and scales efficiently. That's the most important part. Because you don't have to scale your entire Ruby on Rails app, your, you know, entire logic just to support the real-time load. So you only scale this small, efficient app, and it handles all the load and super quickly. And it also supports HTML over WebSockets updates, I mean, Hotwire and stuff. So it helps you scale your Hotwire updates as well.

+ +

So it's much faster than Ruby. It's much more efficient in terms of scaling. And, yeah, it's bidirectional, meaning that the server sends...by the way, it's just a drop-in replacement for ActionCable. So we're using ActionCable protocol. So we have the channels and stuff. So this means that we can send data, you know, from server broadcasts, the data from server, but we can also send the data from any client.

+ +

And one of the use cases for Any Cable, by the way, is different devices that send their coordinates or some other data in real-time. Like, we have some kind of cars sending us GPS data. It's cute, I think that you keep your business logic in your Ruby and Rails app, which is the place to write your business logic, which is the best place to write it. But the infrastructure and all the sort of delivery guarantees, order guarantees, all this kind of infrastructure layer is serviced, is handled by AnyCable, so you don't have to worry about it.

+ +

VICTORIA: That makes sense. Thank you for expanding on that. The interesting part for you on that is just to have this be able to be more collaborative, right? So we're working on this whole project together and not siloing into our different groups and building bespoke products to solve this problem.

+ +

IRINA: Yeah, I mean, I like collaborative UI as a norm, as something that has to be there. So, for any work-related tools...and we do work remotely now over the internet somehow. So I think any tool for any professionals has to have a collaborative regime, right? Support for collaboration because people want to work together. And that's the only way to work, I think.

+ +

VICTORIA: Yeah, that makes sense to me.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: Was there anything that's happened in the last few years maybe, or even that's come up in that discovery process as you're building these products that made you shift your strategic direction for Evil Martians?

+ +

IRINA: Yeah. I was initially looking for the right strategy regarding the products at Evil Martians. And what I mean is we were always passionate about building our own products, building our own products for engineers. We were always passionate about this. But, in order to make it work...and I think it works now, in a way, because we just had our other product, imgproxy, incorporate. And they raised a round of external financing, which is a win, I think. I mean, they have a long, long way to go. And we will try to support them. But, for me, it's important that we had an internal project, you know, graduate us and move beyond Evil Martians.

+ +

So something that I changed, I think, in the company together with the founders, for sure, is how we structure the incentives related to the internal products. What I'm trying to say is this: many companies that have an internal project will be looking to own those products. That's what I'm trying to say. And we are not looking for that.

+ +

What we're looking for is to have a founding team for a product and to make sure they have the majority of shares, that they are the owners of this product. Because we know that building a product is such a long way, and it's a difficult journey. And it takes years and decades to build them into something large, or profitable, or sustainable. So we want the people who are actually doing this to be properly motivated.

+ +

So something that I convinced the founders to do was to keep the share of Evil Martian's [inaudible 20:40] in those new products at a low level, which may sound counterintuitive for some businessmen, you know, for some owners of the business. They will say, "Well, this was something that was built internally in this company. So this is fully owned by this company." And I agree. Like, from the legal standpoint, this is correct.

+ +

But it doesn't make much sense if you think about it because you don't want to own, you know, 95% or 100% in something that its worth is zero or even, you know, a negative amount when you keep investing, and you're not getting any returns. But rather, you'd have 10%, 15%, 20% in something large and profitable. And that was the change, I think, where we said, look, we'll be investing in products in a certain way to make sure that the founders, you know, the team of authors is properly motivated. So they own this, and Evil Martians is just the first investor.

+ +

VICTORIA: That makes a lot of sense because I have been a part of companies where they wanted to reproduce and productize what they'd built for a client and make that something they owned. And I think you use an interesting approach to motivate people to contribute to a project like that by sharing the ownership. [laughs] And that makes a lot of sense to me. I'm curious, based on your response to that last question, how would you describe your leadership style as a CEO?

+ +

IRINA: There's no one way to be the CEO, I guess. So every person approaches this differently. And it's not that easy to be the CEO after the founder, [laughs] so, when, you know, the founder who was the CEO before hands you the job. It's not that easy. But I had trust and support. And I still have it, for sure, the trust and support from the founders and from the team because I've been with the company for four years already when I moved into this role.

+ +

And I think of my style as, first of all, you know, listen to the team, collect the information first. I imagine that I act like a consultant from a management consulting firm, but I didn't work in a management consulting firm. I didn't know how they actually work. But I imagine this is how they work. They sort of speak with every person on the team, and they try to figure out the blockers, the problems, and the aspirations of the team.

+ +

And then they try to find how to improve, you know, the collective utility, the utility of the group, how to improve the situation, maybe not for every single person but for the majority of them. And this was my initial approach and fixing some, maybe, problems in the company. But I would also try to come up with my own ideas as well for sure. But I rely on the team a lot.

+ +

So what I also did is I started relying on my leadership team much more than maybe the founder and CEO. So I'm relying on Andrey Sitnik, Head of Front End, on Roman Shamin, on Vladimir Dementyev, and other people, Victoria, Victoria Melnikova, our Head of New Business. And I'm relying on many people heavily, heavily.

+ +

And my goal is to make sure they see where we want to go and they each can contribute in a certain way. And I ask them how they can contribute. I'm not telling them how to do this, right? I trust their judgment in their area of expertise. But mostly, I just ask about what they can do. And this is how we work together.

+ +

VICTORIA: I like that. I like how you're really connecting with your team and finding out their strengths, and their struggles, and what they think should do. And then it's how do you enable them as a CEO to achieve this greater vision that you all want to work towards? So I really like that. What would you say is maybe your biggest challenge that you're facing right now?

+ +

IRINA: I actually challenged myself to become more publicly, sort of effective. [laughs] That's why I'm here, for example. So I realized we do have amazing engineers, amazing designers who are out there, you know, doing podcasts, doing open-source, building technologies, writing on our blog, doing all of this. And I realized that, well, I should do my part as well. And this was one of the goals for this year.

+ +

The other goal, the other challenge is so complicated that I'm not sure [laughs] I'm ready to talk about it yet. So some of the things I'm trying to do, to be honest, I'm not sure if I can do them at all, [laughs] and that's the problem.

+ +

So thoughtbot has the Incubator Program, right? And this means that thoughtbot presumably gets equity in those new businesses that people build with thoughtbot's help and guidance. And we're not doing this, but we're doing something else, also trying to make sure we have shares in the amazing businesses that we help grow and they become successful. And we're doing everything we can to make sure they are successful. And I want this company to have a share in the success of our clients, our products, all of that together.

+ +

VICTORIA: It would probably contribute to motivation, which is another factor you mentioned previously about.

+ +

IRINA: Yep.

+ +

VICTORIA: You know, right? [laughs]

+ +

IRINA: Absolutely, yeah.

+ +

VICTORIA: Right. We're all going to work a lot harder and collaborate a lot more together. That makes sense.

+ +

IRINA: Yeah, it also means, yeah, that it makes sense to have a share at Evil Martians. You know, as a part of the company, as an employee, you're getting a share in the company. But as you know, when you are a consulting company, it's sort of a complicated question, actually. If you're a startup and you are granting equity-like stock options to your team, this makes sense because if the company goes, you know, grows and goes public; those shares become something super valuable, like, super cool.

+ +

But we are not looking to grow our consulting company into something huge. That's for sure. It won't be possible, right? We are operating at this small niche, that's for sure. And we don't have that many amazing engineers, consultants, and it's so hard to hire them. So, anyways, we're not looking to grow that much, although we are growing. And this means that shares in our company do not mean the same thing as the shares in our clients. But if we participate in the success of our clients, then it sort of changes the whole motivation on our own team. This is what I'm thinking about.

+ +

VICTORIA: Yeah, that's a great question. And I wonder, to build on that, what success really looks like six months from now, or even, like, five years from now for Evil Martians.

+ +

IRINA: I want us to be recognized as the best consultancy, consulting company for developer tools, products. I know maybe it sounds ambitious, but this is what we are super passionate about. This is where we are accumulating the expertise. And this means I want people to think Evil Martians when they build a product for engineers. I want them to think about us and reach out to us. But also, I want us to build a number of successful products, commercial products for engineers, which is a huge challenge. Like, doing both it's not easy, that's for sure. But let's see.

+ +

VICTORIA: Yeah, it's good to be ambitious. And I love that journey for you. I'm excited to follow along. I wonder what advice you would give yourself if you could travel back in time to maybe when you first joined [chuckles] Evil Martians.

+ +

IRINA: I'd say, first of all, be confident in sharing your opinion because, well, especially for females, we do have a lot of, like, impostor syndrome when joining a tech company, for sure. But it's not just females, right? When you dig deeper, you realize that most people have impostor syndrome, regardless of their gender, background, et cetera. No one is this perfect image of a perfect engineer. It's just no one, really. And everyone has that.

+ +

And I want everyone who is joining the new company or maybe entering tech as the industry to be confident in sharing their opinions, well, humbly, respectfully but for sure. But don't shy away from asking the questions and from owning your agenda. That's what I want to say.

+ +

Like, the first year and maybe two years, I didn't own my own agenda. I didn't try to control the sort of to-do lists, the things I'm doing. And later, when I started thinking, you know, critically about my own priorities, I realized that I could bring more value by doing something else, maybe not, you know, not 100% different things but maybe by adding 20% to the mix and removing something that is actually not urgent, not important, you know, just randomly added to...just randomly asked by someone, [chuckles] you know.

+ +

So I think own your own agenda. Be more confident and look forward. Try to imagine the future that you want. And, for some reason, it works. I don't know how, but it does work. So you start imagining the future. You share it with the team; you discuss it with the team. And this is the magic of the teamwork. Maybe you cannot do it alone, but as a team, so much more is possible.

+ +

VICTORIA: I love that. And thank you so much for sharing. I'm sure there's maybe a future Irina out there [laughs] who's hearing that advice now and can take it into their work. What if your younger self could travel forward in time, and what advice would they give you now?

+ +

IRINA: Oh, this is funny. Maybe my younger self would say that I should spend more time with my friends. [laughs] That's what I should do, yeah.

+ +

VICTORIA: That's never bad advice, I think. I love it. Okay. So, is there anything that you would like to promote?

+ +

IRINA: This is not tech-related at all. But I want to ask the listeners to donate to the non-profit organizations supporting people in Ukraine because people are suffering in Ukraine. And there was this explosion of the dam, and the floods, everything. And it's never been as important as it is now to support the non-profits. And I can suggest the Nova Ukraine non-profit organization. It's an American organization, but they send all their money to the local initiatives. So it's a great way to support a good cause.

+ +

VICTORIA: Yes, wonderful, and we can include that into the show notes. Thank you so much for joining me today, Irina.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you could email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Irina Nazarova.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+i7YuJAJo + + ]]> + + Victoria Guido + Irina Nazarova + + + 481: Oscar Health with Neetu Rajpal + https://podcast.thoughtbot.com/481 + 020261f7-8880-42fe-90bd-686812a2a72b + Thu, 29 Jun 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Neetu Rajpal is the CTO of Oscar Health. Oscar aims to make a healthier life accessible and affordable for all by refactoring healthcare to make great care cost less. + +Chad talks to Neetu about working for a relatively new insurance company, reorganizing its structure by getting people into the right positions, and how incorporating large language models and generative AI is an inflection point that will help move things forward. + 31:49 + no + + + Neetu Rajpal is the CTO of Oscar Health. Oscar aims to make a healthier life accessible and affordable for all by refactoring healthcare to make great care cost less. +Chad talks to Neetu about working for a relatively new insurance company, reorganizing its structure by getting people into the right positions, and how incorporating large language models and generative AI is an inflection point that will help move things forward. +Oscar Health (https://www.hioscar.com/) +Follow Oscar Health on Facebook (https://www.facebook.com/OscarHealth), YouTube (https://www.youtube.com/user/OscarHealthInsurance), Twitter (https://twitter.com/OscarHealth), Instagram (https://www.instagram.com/oscarhealth/), or LinkedIn (https://www.linkedin.com/company/oscar-health/). +Follow Neetu Rajpal on LinkedIn (https://www.linkedin.com/in/neeturajpal/), or Twitter (https://twitter.com/Nee2D2). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Neetu Rajpal, the CTO of Oscar Health. Neetu, thank you so much for joining me. +NEETU: It's great to be here. Thank you very much for having me. +CHAD: I want to talk about your role at Oscar Health, and your history, and everything that you've done. But everyone listening might not be familiar with Oscar Health. So let's start there; what is Oscar Health? +NEETU: Yes. Oscar Health is a health insurance company. We sell health insurance, primarily on the ACA marketplace across 20 different states in the U.S. We have just over a million members. So we basically sell health insurance to people. +One of the big, unique things about Oscar Health has been it's a very relatively new insurance company. So it's only been around for about ten years. And it was founded as a pretty standard tech startup. We've built all of the infrastructure for acquiring supporting members and providers, and brokers in-house. So we're fully cloud-native, distributed systems hosted on AWS and GCP with a giant data lake that supports all of our workflows. And this is a pretty unique integrated solution in terms of health insurance companies. So we're very much a tech-focused health insurance company. I've been at Oscar for about three and a half years. +I came to Oscar not from a healthcare background but just really mission-oriented and motivated to go help something in the healthcare space. I've spent most of my career building software, first at Microsoft and then at Conductor and WeWork. And I'm really excited to be here. It's really, really rewarding to be at a company that's serving primarily an underserved market in the ACA space. +CHAD: Well, I suppose full disclosure is in order. Oscar and thoughtbot have been working together for a long time now, actually, with Oscar as a client of ours. So I appreciate you joining us on the show, and I appreciate you working with us over the years. I think we worked...we started working with Oscar maybe when you were just in one or two states. And so, how have you handled that growth? And I think that's one of the complexities of the insurance space, right? Is every location is different in important ways. +NEETU: Yeah. Actually, it seems like Oscar and thoughtbot have worked longer than Oscar and myself. +CHAD: [laughs] +NEETU: So I think that's a pretty exciting, interesting statistic. And even during my time, it's been a great experience working with thoughtbot. +One of the big premise Oscar had was to build software that was segregated enough and isolated enough but composable enough that you could, in fact, bundle the full healthcare tech stack and then bundle it back together as you needed with configuration and scale it as you needed with, like, smart built-in scalability. And I think our ability to grow into multiple states and multiple counties has been, like, a good proof point of the fact that you can, in fact, do that. +In most cases, adding a new state is sometimes, at least from the tech perspective, from the software perspective is a combination of identifying the right configuration settings, mapping it to the features, and then just configuring the software to be able to support that new service area that we've just added. And that, I think, has been, like, a huge value add in terms of being able to add new locations to serve our members, add new providers, add new contracts. And our premise of building stuff or to unbundle and then bundle it back together as needed has really proven out a lot. +CHAD: I assume there have been some challenges along the way. What do you think have been among the biggest? +NEETU: I think the challenges have been an interesting combination of just learning the insurance business landscape then building software that aligns with it. So each county you might go into, each state you might go into, have its own set of regulatory requirements, have its own set of, like, reimbursement requirements, have its own set of, like, plan requirements, and these are...as a new insurance company, I think along the way, we really did have to learn a lot of these things and sometimes by trial and error and that, you know, it's a pretty sometimes a long cycle with insurance. So that has been interesting and challenging. +CHAD: So not necessarily a technical problem but more, like, even just figuring out what it should...how it should work. +NEETU: Yeah. I think definitely the business problem has been interesting on the technical side. So I started at Oscar about three and a half years ago. And my first questions as I was going through the interview process were, "Like, I don't understand why you built all of this stuff in-house, like, why aren't you just [inaudible 05:18]?" And those were rather naive questions to be asking a tech-focused insurance company. +Many years ago, when Oscar chose to use Elasticsearch, it wasn't a BAA-compliant solution. So you couldn't actually use a managed version of Elasticsearch. So we ended up hosting our own Elasticsearch cluster. We were one of the first or the first few people to actually sign a BAA with AWS a long time ago. So, technically speaking, I think the challenges have been around you don't always have the same set of tools available to you; at least, that used to be the case. This is rapidly declining rapidly. The availability of tools is almost the same now. And two, the ecosystem that you live in. +We still definitely have a service that has easy availability to a fax machine, and I think there are a few companies that are able to say that. But it's also the ecosystem that you live in, that you're trying to bring along with yourself, and also ecosystem you're using to support and build the tech stack. Both of those things have been rather interesting. In terms of actually building the software, that's, like, pretty standard regular set of software challenges. +CHAD: How big is the Oscar engineering team at this point? +NEETU: Oscar engineering team has fluctuated between 300 and 400 people over the past few years. I think we're about 350 or so right now. +CHAD: Generally speaking, how is the team organized to perform at that scale? +NEETU: I am actually a pretty big believer in first building a tech strategy that is tied to the business strategy before building the org structure. So, even at the Oscar engineering and tech team org structure, it has probably fluctuated quite a bit based on what the business needed. As of right now, we have dedicated folks that are aligned along individual set of audiences that we are supporting. +So we have a group of people who focuses primarily on the members and the member applications. We have a group of folks who focuses primarily on the provider and all the needs of the providers. And then we have a group of people maybe focused on just growth in general. And that could be growth through enrollments with brokers, enrollments without brokers, direct exchanges, or even some of our +Oscar business work. +So we've tried to, at this moment, align ourselves with the audience that we're serving. And, of course, like, no engineering team is purely vertical or purely horizontal. So we also have an infrastructure platform team that supports all of the areas. +CHAD: Do people sort of opt in, or are their roles advertised in each of those places? Or, as you reorganize into those structures, have you seen ways that work successfully in terms of getting people into the right position? +NEETU: Like, at the larger level in terms of the audience space, there tends to be pretty standard set of roles. As you might imagine, when the companies are smaller, there's a lot of investment or need for really, truly full-stack developers and full-stack engineers. As we've grown larger, there is a bit of specialization towards either the front-end portion of the house or the back-end portion of the house. +And we do have roles posted, and the roles some of them concentrate more towards the front-end tech. Some of them concentrate more towards distributed computing, and back end, and data engineering roles. And some concentrate more towards infrastructure engineering. And, as the teams always get bigger, there tend to also be, like, the supporting functions around technical product management and technical program management that are also part of the equation at the moment. +We do post all of these roles in those terms, with clarity around what the expectations are. As we re-org, we always prioritize internal candidates. We have a big enough team. People like to work on different set of problems and happy to align passions with our business needs because that tends to work out really, really well. +CHAD: Well, there's a reason why I'm asking about this particularly for you because one of the things that stood out to me about your background was the length of time that you were at Microsoft and the movement that you did between a variety of different roles across the organization. So that's an experience that you bring to the table. Was that something that you did intentionally? +NEETU: Yeah. I was at Microsoft for 18 years. And I think every couple of years, I did a new thing. And while I would like to very much say, yeah, I totally figured out that I wanted to be an engineer... +CHAD: [laughs] +NEETU: And then a product manager, and then, you know, an engineer again, or then a product manager again, or a leadership role again, or even the stack as in work on small APIs or work on full enterprise-grade products or cloud...I would like to very much say those were very thought through, you know, clearly pre-planned career moves; they were not. +And particularly, in my case, they were very much I chased problems. And I would get very obsessed or interested in a particular problem. And then, I would go dive deep into that problem and aim to go solve it. And by the time I had figured it out and solved it, there was always a new problem. And this was the wonderful promise of Microsoft where, you know, it is so large, and there are so many different ways to think about different problems, or different ways you can bring software to market, or problems in the world you can solve with it, that I particularly took full advantage of it. +And that hasn't really changed in terms of how the rest of my career post-Microsoft has gone, either. Every couple of years, I find myself in a space that is completely scary, completely new, completely different. For me, that tends to be my happy place, to be working on super difficult things that are very scary. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot's Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +CHAD: It does sound like even though you might not have some grand plan, [chuckles] you are driven to seek out challenges. +NEETU: Yeah. I heard something really, really long time ago that kind of has stuck with me always, which is don't let your curiosity die. So, if you are curious, don't just let it shy away; just indulge in it. That's how you're always moving forward. For me, that's been a big theme as in, I really, really enjoy always learning. Always finding myself not to be the smartest person in the room is really, really great. And always moving forward and pushing hard, and solving bigger and bigger problems. +CHAD: So, when you were deciding to join Oscar Health, how concerned were you with the particulars of the individual position that you were applying for? Or was it more, like, I've identified this space and this problem that I want to be a part of? +NEETU: Yeah, that's a really, really great question. And I think it's one of the ones that when I mentor people, I tell them about as well, which is, I had a role with Conductor that was this head of R&D, CTO, and CPO, and a very traditional ladder style path to the next step or something along those lines or bigger. But I personally am not motivated by titles as much as I am about potential impact I can have. +My walk into healthcare out of MarTech or out of just, like, platform was very personal in terms of I have a healthcare story. Everybody really has a healthcare story. And I wanted to go do something in this space, utilize all of the skills that I already have, and then try to push the space forward. +And so, when I joined Oscar, I was not really that motivated by what the title was going to be. I was really looking for is, is there going to be an opportunity to have an impact? And is there going to be space for me to have impact? Am I going to be surrounded by a group of people who I can have impact with? That was the primary concern. And I did join Oscar as a VP of engineering. And that didn't last very long. +Within the next year and a half, I was already promoted to CTO in that role. And each one of those steps was very much motivated by will I actually be able to have impact? Will I be empowered to have impact? Was I equipped to have an impact? And was I going to learn a lot in that role? Those were my primary motivators. And that's always been the case. +It's also a hard-won lesson. Like, when I had my first kid, it was a really difficult time, personally. I had really bad postpartum depression. I had really hard time dealing with what is going to happen with my career, and I had to take a step back. And as somebody who was, like, super ambitious and wanted to go straight up, that was a really challenging thing to do. And that was a long time ago, and I've been able to rebuild, quote, unquote, "rebuild" my career back multiple times over. +So it's actually been, like, a hard-won lesson where it doesn't kind of matter what part of the rocket ship you have a seat on, as long as you have the seat on the rocket ship. And by rocket ship, I wish I was only talking about stock price; I'm not. I'm just talking about the ability to have impact. If I can be in this right group and I can have a voice, then it didn't matter what my title was. +CHAD: Yeah, thank you for sharing. And I think it feels like the pace of change accelerates. But in growing organizations, so much changes all of the time. So what you are doing...or the roles that exist will change as well. And the other thing...I often get asked by clients, "Should we be hiring a VP of engineering or a CTO?" I'm like, the definition of those roles varies so much between company, and team size, and everything. It's like; it really is difficult to answer that question because it is so different. It all depends on the needs of the organization. +NEETU: Yeah. I've done both of those roles, at least twice each time, twice now. And I've personally discovered that A, those roles don't really have a defined, like, there is no clear definition for either one of those roles. +The other thing that I think is more important is I don't think the organizations know what they want out of those roles most of the times, either. In my experience so far, VP of engineering is a little bit easier to define because it has a very heavy management component to it. And so I've ended up just defining those roles for myself every time, and so far, so good. +And the way I define those roles is very much, like, a CTO role is a half-business half-technical role. It's the role where you understand the business strategy and turn it into a tech strategy that supports the business strategy and pushes the business forward, and acts as the competitive advantage for the business. And your role is, in fact, to be the person who takes tech and applies it to pushing the business forward. That's one direction. +And the other direction, it is the role to take the business strategy and translate into technical terms so that you can bring and coalesce your whole team's motivation around it and bring the whole team around it. And I definitely find this very much at Oscar, where most people who join Oscar engineering and Oscar tech they all come motivated outside of Oscar already to help push the industry forward in one way or another. +So actually keeping that motivation in the right place all the time with authenticity and truth about what it is, how we're pushing the business forward. And helping the business move forward is an extremely valuable skill. So, from my perspective, the tech role is definitely half-business, half-tech with some variable sprinkling of management attached to it, and I think that's the CTO role. And the VP of engineering was very heavily bent towards management, I think, yeah. +CHAD: Well, so in that CTO role, we'll often be faced with understanding how industry changes, or new technology, or whatever can help the business. Obviously, we have a big one happening right now with artificial intelligence or large language models and machine learning. I have a couple of questions around this area. But, like, is there something in particular with that that you're either thinking about now in terms of Oscar or have already incorporated? +NEETU: Yeah. I think large language models and generative AI, in general, is definitely an inflection point. And I think it's an inflection point that is going to help push so many things forward. And I think healthcare is very interestingly poised towards pushing in that direction. There is everything from, like, shortage of providers or shortage of mental health providers to just a large availability of data in the healthcare space that can help discover things that may not be the easiest to discover through humans looking at it. So I think there's a huge opportunity. +I also think it needs, like, a bit of cautious evaluation. We are dealing with something that you can't break, so you can't move fast and break things when you're dealing with people. But there are interesting use cases where you could use generative AI and have it maybe not make a decision for a person but assist the provider to make a decision. Or you can use it in areas, at least in healthcare space, where there is a lot of inefficiency because of too much to do. And you can actually optimize a whole bunch of that. +So examples could be, you know, there's the standard examples of chatbots as in, is this doctor part of my network? Can I have an appointment with this doctor? Can I have an appointment and a prior auth with this doctor immediately? Like, those are, I think, a little bit more accessible use cases. And Oscar, also, we're exploring and figuring out which one of those makes most sense for us in our business. And there's tons of excitement and tons of, like, thought being put behind it. As of right now, I probably can't say all the things that we're working on at the moment. But yes, absolutely, this is a very big deal. +CHAD: So, speaking more generally around exploring new ideas, you mentioned at Conductor, you were in an R&D role combined...like, is there strategies that you've seen that work particularly well for doing research and development within an organization, exploring new ideas, figuring things out? +NEETU: Yeah. It definitely depends on which portion or which portion of the maturity stack you're on. If you're building software that is going to be sold to enterprises, you have to have some version of a promise of a date, and then you have to keep your promise. So, if you're selling enterprise software, you have to be predictable because your partners on the other side are relying on you. +And you can't actually get predictability without having enough stability in your team, and enough stability in your roadmaps, and enough stability in your tech environment [inaudible 22:30] So that you can figure out what you're going to build, you can figure out where you're going to build, and how you're going to build it. You can figure out what teams and resources you're going to allocate to it. And you can also have some confidence that when you're ready to send code out to production, there is some automated CI/CD system that is, like, going to help you make sure that the number of errors that you are sending out into the world is as few as possible. +And that superpower of being able to, like, churn out code and features and products like a machine on a pretty regular basis has the potential downside of not being able to disrupt yourself. And I think there are definitely a couple of strategies to do that. One of them is to allocate enough space by filling it with P2s as opposed to everything being a P0, that if you were to, like, displace the P2s with something that is new and available now, then you're going to be okay because you can live without the P2s. We had to have enough of those. +There is also the whole skunk works model, which I think works pretty well. I think it does need to be set up carefully so that you're not, like, destroying the motivation of everybody in the team. You do have the opportunity to do the skunkworks model. And, like, the generating ideas portion, we do this at Oscar, and I think this is also done elsewhere. We have pretty regular hackathons that are dedicated amounts of time, and we put them on the schedule. And, during that time, we just go explore and dream and go build other things. And we build it collaboratively with the rest of the business. +And there are definitely still, like, stories of things that were developed in a hackathon that served us really well for years on end. And I don't think that's ever going to change. But anything that is, like, a real solid enterprise production stuff probably needs a dedicated skunkworks something or the other so you can...I don't think it's a bad thing to have solid schedules. I think it's a really huge superpower to have solid schedules. I do think you have to have the discipline to be able to disrupt yourself; otherwise, somebody else will. +CHAD: Right. And so figuring out a structure, you can do that. And, like you said, you know, you don't want to ruin the morale or the excitement of the entire organization where people say, like, "Well, it's not my job," you know, or, "I wish I could work on this, but it's this team's." And you're not set up to capture that individual person's excitement over generative AI, for example, who is the one who's actually going to make it happen. And you're squashing that because they're not, quote, unquote, "supposed to work on it." I think that's a really difficult balance to strike. +NEETU: Yeah, I think it is. But I don't know; there are very few things in the healthcare space that anybody does that is easy. +CHAD: Yeah, that's a good point. Now that you've been in the role, well, at Oscar for a few years, what's next? What are the things that, like, you feel like are sort of motivating you each day you come to work? +NEETU: Oscar is in the ACA space, which serves primarily underserved communities. There have been, like, some recent examples of where people had to shutter doors in the ACA space. So the fact that we're still around and the fact that we're successful, like, we don't take that for granted. It's a really valuable thing to be able to survive in this market and to be able to grow. +We launched a mission-driven tech-focused company ten years ago based on the belief that you could build your own tech stack and be successful in a very tightly controlled market. And I think this is the year that we actually had to just, like, really prove out the use case. So, this year, Oscar is 100% focused on being insure co profitable. And once we finish proving that out, next year, we're going to prove out that it is... Holdco can be profitable, which is all of our tech stack, in addition to all of our insurance business. +And I'm very, very much looking forward to Oscar being successful this year in the mission, where I think it's just proving out that you can build a successful business and ACA-powered by your own tech stack. And not compromising on the outcomes for our members is really valuable and keeps me very motivated. +And then, looking at the future, looking at being able to be 100% full company profitable and potentially selling our software for others so they could also bring this efficiency to their businesses is extremely motivating for me. And, as of right now, this is what the whole company is focused on. And we're all super excited about it. +CHAD: Yeah, oftentimes, having a clear goal that everyone knows about and is working on can be really empowering for an organization, even if it's hard. +NEETU: Yeah. Like I said before, I think almost everybody I've interacted with at Oscar didn't come to Oscar, assuming it was going to be easy. They came to Oscar with full knowledge that it was going to be hard, but they were going to try anyway. So we are so close. +CHAD: Yeah. And, you know, that's one of the things that, at thoughtbot, we skew to working with clients that do positive things for the world, that deserve to exist for precisely this reason, is when you have a positive purpose in your organization, it makes working hard easier, [laughs] or solving big problems easier because you know that you're going to have a positive impact when you do. +NEETU: Yeah. The personal healthcare story was a motivating factor towards going to go do something that was, like, going to be, like, positive for the world. I wish I could say, yes, I'm going to solve all of healthcare's problems and [inaudible 29:02] not that way. +CHAD: Yeah. Well, that was actually what I was going to ask you about next is that's the thing about healthcare. And I've seen people almost get demoralized for it because you actually can't solve every problem. It's really difficult to solve all of healthcare. So, how do you sort of exist within that environment and not get demotivated? +NEETU: I think the more you dig into the problem, the more you realize how interconnected the way in, like, society, politics, money, power, and tech it really is. And it seems like if you try to solve the whole thing, it almost feels like you're going to boil the whole ocean. And it is definitely a blocker from even trying. +And, for me, it was just like, does that mean I stop? Do I apply the boy scout rule of, like, just trying to leave it better off, a whole lot better off, as much possible better off than I found it? I could do that. Or I could just go do something completely different. But there is no guarantee it's going to be as motivating or potentially as impacting. So, for me, it's very much about, like, if I could make even small changes, I know they'll be part of a greater whole. So I will just try to make those small changes because, alternatively, I may be neutral for the world at most. +CHAD: Well, Neetu, thank you so much for stopping by and sharing with us. I really appreciate it. +NEETU: Thank you very much for having me. It's been a great conversation. +CHAD: If folks want to get in touch with you or follow along, where are the best places for them to do that? +NEETU: I am easy to find on LinkedIn. I do have a Twitter account, but I'm not very active. It's @Nee2D2, and I look forward to hearing from people. +CHAD: Awesome. +You can subscribe to the show and find notes for this episode, along with a complete transcript, at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Mastodon @cpytel@thoughtbot.social. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Neetu Rajpal. + + + Neetu Rajpal is the CTO of Oscar Health. Oscar aims to make a healthier life accessible and affordable for all by refactoring healthcare to make great care cost less.

+ +

Chad talks to Neetu about working for a relatively new insurance company, reorganizing its structure by getting people into the right positions, and how incorporating large language models and generative AI is an inflection point that will help move things forward.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Neetu Rajpal, the CTO of Oscar Health. Neetu, thank you so much for joining me.

+ +

NEETU: It's great to be here. Thank you very much for having me.

+ +

CHAD: I want to talk about your role at Oscar Health, and your history, and everything that you've done. But everyone listening might not be familiar with Oscar Health. So let's start there; what is Oscar Health?

+ +

NEETU: Yes. Oscar Health is a health insurance company. We sell health insurance, primarily on the ACA marketplace across 20 different states in the U.S. We have just over a million members. So we basically sell health insurance to people.

+ +

One of the big, unique things about Oscar Health has been it's a very relatively new insurance company. So it's only been around for about ten years. And it was founded as a pretty standard tech startup. We've built all of the infrastructure for acquiring supporting members and providers, and brokers in-house. So we're fully cloud-native, distributed systems hosted on AWS and GCP with a giant data lake that supports all of our workflows. And this is a pretty unique integrated solution in terms of health insurance companies. So we're very much a tech-focused health insurance company. I've been at Oscar for about three and a half years.

+ +

I came to Oscar not from a healthcare background but just really mission-oriented and motivated to go help something in the healthcare space. I've spent most of my career building software, first at Microsoft and then at Conductor and WeWork. And I'm really excited to be here. It's really, really rewarding to be at a company that's serving primarily an underserved market in the ACA space.

+ +

CHAD: Well, I suppose full disclosure is in order. Oscar and thoughtbot have been working together for a long time now, actually, with Oscar as a client of ours. So I appreciate you joining us on the show, and I appreciate you working with us over the years. I think we worked...we started working with Oscar maybe when you were just in one or two states. And so, how have you handled that growth? And I think that's one of the complexities of the insurance space, right? Is every location is different in important ways.

+ +

NEETU: Yeah. Actually, it seems like Oscar and thoughtbot have worked longer than Oscar and myself.

+ +

CHAD: [laughs]

+ +

NEETU: So I think that's a pretty exciting, interesting statistic. And even during my time, it's been a great experience working with thoughtbot.

+ +

One of the big premise Oscar had was to build software that was segregated enough and isolated enough but composable enough that you could, in fact, bundle the full healthcare tech stack and then bundle it back together as you needed with configuration and scale it as you needed with, like, smart built-in scalability. And I think our ability to grow into multiple states and multiple counties has been, like, a good proof point of the fact that you can, in fact, do that.

+ +

In most cases, adding a new state is sometimes, at least from the tech perspective, from the software perspective is a combination of identifying the right configuration settings, mapping it to the features, and then just configuring the software to be able to support that new service area that we've just added. And that, I think, has been, like, a huge value add in terms of being able to add new locations to serve our members, add new providers, add new contracts. And our premise of building stuff or to unbundle and then bundle it back together as needed has really proven out a lot.

+ +

CHAD: I assume there have been some challenges along the way. What do you think have been among the biggest?

+ +

NEETU: I think the challenges have been an interesting combination of just learning the insurance business landscape then building software that aligns with it. So each county you might go into, each state you might go into, have its own set of regulatory requirements, have its own set of, like, reimbursement requirements, have its own set of, like, plan requirements, and these are...as a new insurance company, I think along the way, we really did have to learn a lot of these things and sometimes by trial and error and that, you know, it's a pretty sometimes a long cycle with insurance. So that has been interesting and challenging.

+ +

CHAD: So not necessarily a technical problem but more, like, even just figuring out what it should...how it should work.

+ +

NEETU: Yeah. I think definitely the business problem has been interesting on the technical side. So I started at Oscar about three and a half years ago. And my first questions as I was going through the interview process were, "Like, I don't understand why you built all of this stuff in-house, like, why aren't you just [inaudible 05:18]?" And those were rather naive questions to be asking a tech-focused insurance company.

+ +

Many years ago, when Oscar chose to use Elasticsearch, it wasn't a BAA-compliant solution. So you couldn't actually use a managed version of Elasticsearch. So we ended up hosting our own Elasticsearch cluster. We were one of the first or the first few people to actually sign a BAA with AWS a long time ago. So, technically speaking, I think the challenges have been around you don't always have the same set of tools available to you; at least, that used to be the case. This is rapidly declining rapidly. The availability of tools is almost the same now. And two, the ecosystem that you live in.

+ +

We still definitely have a service that has easy availability to a fax machine, and I think there are a few companies that are able to say that. But it's also the ecosystem that you live in, that you're trying to bring along with yourself, and also ecosystem you're using to support and build the tech stack. Both of those things have been rather interesting. In terms of actually building the software, that's, like, pretty standard regular set of software challenges.

+ +

CHAD: How big is the Oscar engineering team at this point?

+ +

NEETU: Oscar engineering team has fluctuated between 300 and 400 people over the past few years. I think we're about 350 or so right now.

+ +

CHAD: Generally speaking, how is the team organized to perform at that scale?

+ +

NEETU: I am actually a pretty big believer in first building a tech strategy that is tied to the business strategy before building the org structure. So, even at the Oscar engineering and tech team org structure, it has probably fluctuated quite a bit based on what the business needed. As of right now, we have dedicated folks that are aligned along individual set of audiences that we are supporting.

+ +

So we have a group of people who focuses primarily on the members and the member applications. We have a group of folks who focuses primarily on the provider and all the needs of the providers. And then we have a group of people maybe focused on just growth in general. And that could be growth through enrollments with brokers, enrollments without brokers, direct exchanges, or even some of our +Oscar business work.

+ +

So we've tried to, at this moment, align ourselves with the audience that we're serving. And, of course, like, no engineering team is purely vertical or purely horizontal. So we also have an infrastructure platform team that supports all of the areas.

+ +

CHAD: Do people sort of opt in, or are their roles advertised in each of those places? Or, as you reorganize into those structures, have you seen ways that work successfully in terms of getting people into the right position?

+ +

NEETU: Like, at the larger level in terms of the audience space, there tends to be pretty standard set of roles. As you might imagine, when the companies are smaller, there's a lot of investment or need for really, truly full-stack developers and full-stack engineers. As we've grown larger, there is a bit of specialization towards either the front-end portion of the house or the back-end portion of the house.

+ +

And we do have roles posted, and the roles some of them concentrate more towards the front-end tech. Some of them concentrate more towards distributed computing, and back end, and data engineering roles. And some concentrate more towards infrastructure engineering. And, as the teams always get bigger, there tend to also be, like, the supporting functions around technical product management and technical program management that are also part of the equation at the moment.

+ +

We do post all of these roles in those terms, with clarity around what the expectations are. As we re-org, we always prioritize internal candidates. We have a big enough team. People like to work on different set of problems and happy to align passions with our business needs because that tends to work out really, really well.

+ +

CHAD: Well, there's a reason why I'm asking about this particularly for you because one of the things that stood out to me about your background was the length of time that you were at Microsoft and the movement that you did between a variety of different roles across the organization. So that's an experience that you bring to the table. Was that something that you did intentionally?

+ +

NEETU: Yeah. I was at Microsoft for 18 years. And I think every couple of years, I did a new thing. And while I would like to very much say, yeah, I totally figured out that I wanted to be an engineer...

+ +

CHAD: [laughs]

+ +

NEETU: And then a product manager, and then, you know, an engineer again, or then a product manager again, or a leadership role again, or even the stack as in work on small APIs or work on full enterprise-grade products or cloud...I would like to very much say those were very thought through, you know, clearly pre-planned career moves; they were not.

+ +

And particularly, in my case, they were very much I chased problems. And I would get very obsessed or interested in a particular problem. And then, I would go dive deep into that problem and aim to go solve it. And by the time I had figured it out and solved it, there was always a new problem. And this was the wonderful promise of Microsoft where, you know, it is so large, and there are so many different ways to think about different problems, or different ways you can bring software to market, or problems in the world you can solve with it, that I particularly took full advantage of it.

+ +

And that hasn't really changed in terms of how the rest of my career post-Microsoft has gone, either. Every couple of years, I find myself in a space that is completely scary, completely new, completely different. For me, that tends to be my happy place, to be working on super difficult things that are very scary.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot's Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: It does sound like even though you might not have some grand plan, [chuckles] you are driven to seek out challenges.

+ +

NEETU: Yeah. I heard something really, really long time ago that kind of has stuck with me always, which is don't let your curiosity die. So, if you are curious, don't just let it shy away; just indulge in it. That's how you're always moving forward. For me, that's been a big theme as in, I really, really enjoy always learning. Always finding myself not to be the smartest person in the room is really, really great. And always moving forward and pushing hard, and solving bigger and bigger problems.

+ +

CHAD: So, when you were deciding to join Oscar Health, how concerned were you with the particulars of the individual position that you were applying for? Or was it more, like, I've identified this space and this problem that I want to be a part of?

+ +

NEETU: Yeah, that's a really, really great question. And I think it's one of the ones that when I mentor people, I tell them about as well, which is, I had a role with Conductor that was this head of R&D, CTO, and CPO, and a very traditional ladder style path to the next step or something along those lines or bigger. But I personally am not motivated by titles as much as I am about potential impact I can have.

+ +

My walk into healthcare out of MarTech or out of just, like, platform was very personal in terms of I have a healthcare story. Everybody really has a healthcare story. And I wanted to go do something in this space, utilize all of the skills that I already have, and then try to push the space forward.

+ +

And so, when I joined Oscar, I was not really that motivated by what the title was going to be. I was really looking for is, is there going to be an opportunity to have an impact? And is there going to be space for me to have impact? Am I going to be surrounded by a group of people who I can have impact with? That was the primary concern. And I did join Oscar as a VP of engineering. And that didn't last very long.

+ +

Within the next year and a half, I was already promoted to CTO in that role. And each one of those steps was very much motivated by will I actually be able to have impact? Will I be empowered to have impact? Was I equipped to have an impact? And was I going to learn a lot in that role? Those were my primary motivators. And that's always been the case.

+ +

It's also a hard-won lesson. Like, when I had my first kid, it was a really difficult time, personally. I had really bad postpartum depression. I had really hard time dealing with what is going to happen with my career, and I had to take a step back. And as somebody who was, like, super ambitious and wanted to go straight up, that was a really challenging thing to do. And that was a long time ago, and I've been able to rebuild, quote, unquote, "rebuild" my career back multiple times over.

+ +

So it's actually been, like, a hard-won lesson where it doesn't kind of matter what part of the rocket ship you have a seat on, as long as you have the seat on the rocket ship. And by rocket ship, I wish I was only talking about stock price; I'm not. I'm just talking about the ability to have impact. If I can be in this right group and I can have a voice, then it didn't matter what my title was.

+ +

CHAD: Yeah, thank you for sharing. And I think it feels like the pace of change accelerates. But in growing organizations, so much changes all of the time. So what you are doing...or the roles that exist will change as well. And the other thing...I often get asked by clients, "Should we be hiring a VP of engineering or a CTO?" I'm like, the definition of those roles varies so much between company, and team size, and everything. It's like; it really is difficult to answer that question because it is so different. It all depends on the needs of the organization.

+ +

NEETU: Yeah. I've done both of those roles, at least twice each time, twice now. And I've personally discovered that A, those roles don't really have a defined, like, there is no clear definition for either one of those roles.

+ +

The other thing that I think is more important is I don't think the organizations know what they want out of those roles most of the times, either. In my experience so far, VP of engineering is a little bit easier to define because it has a very heavy management component to it. And so I've ended up just defining those roles for myself every time, and so far, so good.

+ +

And the way I define those roles is very much, like, a CTO role is a half-business half-technical role. It's the role where you understand the business strategy and turn it into a tech strategy that supports the business strategy and pushes the business forward, and acts as the competitive advantage for the business. And your role is, in fact, to be the person who takes tech and applies it to pushing the business forward. That's one direction.

+ +

And the other direction, it is the role to take the business strategy and translate into technical terms so that you can bring and coalesce your whole team's motivation around it and bring the whole team around it. And I definitely find this very much at Oscar, where most people who join Oscar engineering and Oscar tech they all come motivated outside of Oscar already to help push the industry forward in one way or another.

+ +

So actually keeping that motivation in the right place all the time with authenticity and truth about what it is, how we're pushing the business forward. And helping the business move forward is an extremely valuable skill. So, from my perspective, the tech role is definitely half-business, half-tech with some variable sprinkling of management attached to it, and I think that's the CTO role. And the VP of engineering was very heavily bent towards management, I think, yeah.

+ +

CHAD: Well, so in that CTO role, we'll often be faced with understanding how industry changes, or new technology, or whatever can help the business. Obviously, we have a big one happening right now with artificial intelligence or large language models and machine learning. I have a couple of questions around this area. But, like, is there something in particular with that that you're either thinking about now in terms of Oscar or have already incorporated?

+ +

NEETU: Yeah. I think large language models and generative AI, in general, is definitely an inflection point. And I think it's an inflection point that is going to help push so many things forward. And I think healthcare is very interestingly poised towards pushing in that direction. There is everything from, like, shortage of providers or shortage of mental health providers to just a large availability of data in the healthcare space that can help discover things that may not be the easiest to discover through humans looking at it. So I think there's a huge opportunity.

+ +

I also think it needs, like, a bit of cautious evaluation. We are dealing with something that you can't break, so you can't move fast and break things when you're dealing with people. But there are interesting use cases where you could use generative AI and have it maybe not make a decision for a person but assist the provider to make a decision. Or you can use it in areas, at least in healthcare space, where there is a lot of inefficiency because of too much to do. And you can actually optimize a whole bunch of that.

+ +

So examples could be, you know, there's the standard examples of chatbots as in, is this doctor part of my network? Can I have an appointment with this doctor? Can I have an appointment and a prior auth with this doctor immediately? Like, those are, I think, a little bit more accessible use cases. And Oscar, also, we're exploring and figuring out which one of those makes most sense for us in our business. And there's tons of excitement and tons of, like, thought being put behind it. As of right now, I probably can't say all the things that we're working on at the moment. But yes, absolutely, this is a very big deal.

+ +

CHAD: So, speaking more generally around exploring new ideas, you mentioned at Conductor, you were in an R&D role combined...like, is there strategies that you've seen that work particularly well for doing research and development within an organization, exploring new ideas, figuring things out?

+ +

NEETU: Yeah. It definitely depends on which portion or which portion of the maturity stack you're on. If you're building software that is going to be sold to enterprises, you have to have some version of a promise of a date, and then you have to keep your promise. So, if you're selling enterprise software, you have to be predictable because your partners on the other side are relying on you.

+ +

And you can't actually get predictability without having enough stability in your team, and enough stability in your roadmaps, and enough stability in your tech environment [inaudible 22:30] So that you can figure out what you're going to build, you can figure out where you're going to build, and how you're going to build it. You can figure out what teams and resources you're going to allocate to it. And you can also have some confidence that when you're ready to send code out to production, there is some automated CI/CD system that is, like, going to help you make sure that the number of errors that you are sending out into the world is as few as possible.

+ +

And that superpower of being able to, like, churn out code and features and products like a machine on a pretty regular basis has the potential downside of not being able to disrupt yourself. And I think there are definitely a couple of strategies to do that. One of them is to allocate enough space by filling it with P2s as opposed to everything being a P0, that if you were to, like, displace the P2s with something that is new and available now, then you're going to be okay because you can live without the P2s. We had to have enough of those.

+ +

There is also the whole skunk works model, which I think works pretty well. I think it does need to be set up carefully so that you're not, like, destroying the motivation of everybody in the team. You do have the opportunity to do the skunkworks model. And, like, the generating ideas portion, we do this at Oscar, and I think this is also done elsewhere. We have pretty regular hackathons that are dedicated amounts of time, and we put them on the schedule. And, during that time, we just go explore and dream and go build other things. And we build it collaboratively with the rest of the business.

+ +

And there are definitely still, like, stories of things that were developed in a hackathon that served us really well for years on end. And I don't think that's ever going to change. But anything that is, like, a real solid enterprise production stuff probably needs a dedicated skunkworks something or the other so you can...I don't think it's a bad thing to have solid schedules. I think it's a really huge superpower to have solid schedules. I do think you have to have the discipline to be able to disrupt yourself; otherwise, somebody else will.

+ +

CHAD: Right. And so figuring out a structure, you can do that. And, like you said, you know, you don't want to ruin the morale or the excitement of the entire organization where people say, like, "Well, it's not my job," you know, or, "I wish I could work on this, but it's this team's." And you're not set up to capture that individual person's excitement over generative AI, for example, who is the one who's actually going to make it happen. And you're squashing that because they're not, quote, unquote, "supposed to work on it." I think that's a really difficult balance to strike.

+ +

NEETU: Yeah, I think it is. But I don't know; there are very few things in the healthcare space that anybody does that is easy.

+ +

CHAD: Yeah, that's a good point. Now that you've been in the role, well, at Oscar for a few years, what's next? What are the things that, like, you feel like are sort of motivating you each day you come to work?

+ +

NEETU: Oscar is in the ACA space, which serves primarily underserved communities. There have been, like, some recent examples of where people had to shutter doors in the ACA space. So the fact that we're still around and the fact that we're successful, like, we don't take that for granted. It's a really valuable thing to be able to survive in this market and to be able to grow.

+ +

We launched a mission-driven tech-focused company ten years ago based on the belief that you could build your own tech stack and be successful in a very tightly controlled market. And I think this is the year that we actually had to just, like, really prove out the use case. So, this year, Oscar is 100% focused on being insure co profitable. And once we finish proving that out, next year, we're going to prove out that it is... Holdco can be profitable, which is all of our tech stack, in addition to all of our insurance business.

+ +

And I'm very, very much looking forward to Oscar being successful this year in the mission, where I think it's just proving out that you can build a successful business and ACA-powered by your own tech stack. And not compromising on the outcomes for our members is really valuable and keeps me very motivated.

+ +

And then, looking at the future, looking at being able to be 100% full company profitable and potentially selling our software for others so they could also bring this efficiency to their businesses is extremely motivating for me. And, as of right now, this is what the whole company is focused on. And we're all super excited about it.

+ +

CHAD: Yeah, oftentimes, having a clear goal that everyone knows about and is working on can be really empowering for an organization, even if it's hard.

+ +

NEETU: Yeah. Like I said before, I think almost everybody I've interacted with at Oscar didn't come to Oscar, assuming it was going to be easy. They came to Oscar with full knowledge that it was going to be hard, but they were going to try anyway. So we are so close.

+ +

CHAD: Yeah. And, you know, that's one of the things that, at thoughtbot, we skew to working with clients that do positive things for the world, that deserve to exist for precisely this reason, is when you have a positive purpose in your organization, it makes working hard easier, [laughs] or solving big problems easier because you know that you're going to have a positive impact when you do.

+ +

NEETU: Yeah. The personal healthcare story was a motivating factor towards going to go do something that was, like, going to be, like, positive for the world. I wish I could say, yes, I'm going to solve all of healthcare's problems and [inaudible 29:02] not that way.

+ +

CHAD: Yeah. Well, that was actually what I was going to ask you about next is that's the thing about healthcare. And I've seen people almost get demoralized for it because you actually can't solve every problem. It's really difficult to solve all of healthcare. So, how do you sort of exist within that environment and not get demotivated?

+ +

NEETU: I think the more you dig into the problem, the more you realize how interconnected the way in, like, society, politics, money, power, and tech it really is. And it seems like if you try to solve the whole thing, it almost feels like you're going to boil the whole ocean. And it is definitely a blocker from even trying.

+ +

And, for me, it was just like, does that mean I stop? Do I apply the boy scout rule of, like, just trying to leave it better off, a whole lot better off, as much possible better off than I found it? I could do that. Or I could just go do something completely different. But there is no guarantee it's going to be as motivating or potentially as impacting. So, for me, it's very much about, like, if I could make even small changes, I know they'll be part of a greater whole. So I will just try to make those small changes because, alternatively, I may be neutral for the world at most.

+ +

CHAD: Well, Neetu, thank you so much for stopping by and sharing with us. I really appreciate it.

+ +

NEETU: Thank you very much for having me. It's been a great conversation.

+ +

CHAD: If folks want to get in touch with you or follow along, where are the best places for them to do that?

+ +

NEETU: I am easy to find on LinkedIn. I do have a Twitter account, but I'm not very active. It's @Nee2D2, and I look forward to hearing from people.

+ +

CHAD: Awesome.

+ +

You can subscribe to the show and find notes for this episode, along with a complete transcript, at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Mastodon @cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Neetu Rajpal.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Neetu Rajpal is the CTO of Oscar Health. Oscar aims to make a healthier life accessible and affordable for all by refactoring healthcare to make great care cost less.

+ +

Chad talks to Neetu about working for a relatively new insurance company, reorganizing its structure by getting people into the right positions, and how incorporating large language models and generative AI is an inflection point that will help move things forward.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Neetu Rajpal, the CTO of Oscar Health. Neetu, thank you so much for joining me.

+ +

NEETU: It's great to be here. Thank you very much for having me.

+ +

CHAD: I want to talk about your role at Oscar Health, and your history, and everything that you've done. But everyone listening might not be familiar with Oscar Health. So let's start there; what is Oscar Health?

+ +

NEETU: Yes. Oscar Health is a health insurance company. We sell health insurance, primarily on the ACA marketplace across 20 different states in the U.S. We have just over a million members. So we basically sell health insurance to people.

+ +

One of the big, unique things about Oscar Health has been it's a very relatively new insurance company. So it's only been around for about ten years. And it was founded as a pretty standard tech startup. We've built all of the infrastructure for acquiring supporting members and providers, and brokers in-house. So we're fully cloud-native, distributed systems hosted on AWS and GCP with a giant data lake that supports all of our workflows. And this is a pretty unique integrated solution in terms of health insurance companies. So we're very much a tech-focused health insurance company. I've been at Oscar for about three and a half years.

+ +

I came to Oscar not from a healthcare background but just really mission-oriented and motivated to go help something in the healthcare space. I've spent most of my career building software, first at Microsoft and then at Conductor and WeWork. And I'm really excited to be here. It's really, really rewarding to be at a company that's serving primarily an underserved market in the ACA space.

+ +

CHAD: Well, I suppose full disclosure is in order. Oscar and thoughtbot have been working together for a long time now, actually, with Oscar as a client of ours. So I appreciate you joining us on the show, and I appreciate you working with us over the years. I think we worked...we started working with Oscar maybe when you were just in one or two states. And so, how have you handled that growth? And I think that's one of the complexities of the insurance space, right? Is every location is different in important ways.

+ +

NEETU: Yeah. Actually, it seems like Oscar and thoughtbot have worked longer than Oscar and myself.

+ +

CHAD: [laughs]

+ +

NEETU: So I think that's a pretty exciting, interesting statistic. And even during my time, it's been a great experience working with thoughtbot.

+ +

One of the big premise Oscar had was to build software that was segregated enough and isolated enough but composable enough that you could, in fact, bundle the full healthcare tech stack and then bundle it back together as you needed with configuration and scale it as you needed with, like, smart built-in scalability. And I think our ability to grow into multiple states and multiple counties has been, like, a good proof point of the fact that you can, in fact, do that.

+ +

In most cases, adding a new state is sometimes, at least from the tech perspective, from the software perspective is a combination of identifying the right configuration settings, mapping it to the features, and then just configuring the software to be able to support that new service area that we've just added. And that, I think, has been, like, a huge value add in terms of being able to add new locations to serve our members, add new providers, add new contracts. And our premise of building stuff or to unbundle and then bundle it back together as needed has really proven out a lot.

+ +

CHAD: I assume there have been some challenges along the way. What do you think have been among the biggest?

+ +

NEETU: I think the challenges have been an interesting combination of just learning the insurance business landscape then building software that aligns with it. So each county you might go into, each state you might go into, have its own set of regulatory requirements, have its own set of, like, reimbursement requirements, have its own set of, like, plan requirements, and these are...as a new insurance company, I think along the way, we really did have to learn a lot of these things and sometimes by trial and error and that, you know, it's a pretty sometimes a long cycle with insurance. So that has been interesting and challenging.

+ +

CHAD: So not necessarily a technical problem but more, like, even just figuring out what it should...how it should work.

+ +

NEETU: Yeah. I think definitely the business problem has been interesting on the technical side. So I started at Oscar about three and a half years ago. And my first questions as I was going through the interview process were, "Like, I don't understand why you built all of this stuff in-house, like, why aren't you just [inaudible 05:18]?" And those were rather naive questions to be asking a tech-focused insurance company.

+ +

Many years ago, when Oscar chose to use Elasticsearch, it wasn't a BAA-compliant solution. So you couldn't actually use a managed version of Elasticsearch. So we ended up hosting our own Elasticsearch cluster. We were one of the first or the first few people to actually sign a BAA with AWS a long time ago. So, technically speaking, I think the challenges have been around you don't always have the same set of tools available to you; at least, that used to be the case. This is rapidly declining rapidly. The availability of tools is almost the same now. And two, the ecosystem that you live in.

+ +

We still definitely have a service that has easy availability to a fax machine, and I think there are a few companies that are able to say that. But it's also the ecosystem that you live in, that you're trying to bring along with yourself, and also ecosystem you're using to support and build the tech stack. Both of those things have been rather interesting. In terms of actually building the software, that's, like, pretty standard regular set of software challenges.

+ +

CHAD: How big is the Oscar engineering team at this point?

+ +

NEETU: Oscar engineering team has fluctuated between 300 and 400 people over the past few years. I think we're about 350 or so right now.

+ +

CHAD: Generally speaking, how is the team organized to perform at that scale?

+ +

NEETU: I am actually a pretty big believer in first building a tech strategy that is tied to the business strategy before building the org structure. So, even at the Oscar engineering and tech team org structure, it has probably fluctuated quite a bit based on what the business needed. As of right now, we have dedicated folks that are aligned along individual set of audiences that we are supporting.

+ +

So we have a group of people who focuses primarily on the members and the member applications. We have a group of folks who focuses primarily on the provider and all the needs of the providers. And then we have a group of people maybe focused on just growth in general. And that could be growth through enrollments with brokers, enrollments without brokers, direct exchanges, or even some of our +Oscar business work.

+ +

So we've tried to, at this moment, align ourselves with the audience that we're serving. And, of course, like, no engineering team is purely vertical or purely horizontal. So we also have an infrastructure platform team that supports all of the areas.

+ +

CHAD: Do people sort of opt in, or are their roles advertised in each of those places? Or, as you reorganize into those structures, have you seen ways that work successfully in terms of getting people into the right position?

+ +

NEETU: Like, at the larger level in terms of the audience space, there tends to be pretty standard set of roles. As you might imagine, when the companies are smaller, there's a lot of investment or need for really, truly full-stack developers and full-stack engineers. As we've grown larger, there is a bit of specialization towards either the front-end portion of the house or the back-end portion of the house.

+ +

And we do have roles posted, and the roles some of them concentrate more towards the front-end tech. Some of them concentrate more towards distributed computing, and back end, and data engineering roles. And some concentrate more towards infrastructure engineering. And, as the teams always get bigger, there tend to also be, like, the supporting functions around technical product management and technical program management that are also part of the equation at the moment.

+ +

We do post all of these roles in those terms, with clarity around what the expectations are. As we re-org, we always prioritize internal candidates. We have a big enough team. People like to work on different set of problems and happy to align passions with our business needs because that tends to work out really, really well.

+ +

CHAD: Well, there's a reason why I'm asking about this particularly for you because one of the things that stood out to me about your background was the length of time that you were at Microsoft and the movement that you did between a variety of different roles across the organization. So that's an experience that you bring to the table. Was that something that you did intentionally?

+ +

NEETU: Yeah. I was at Microsoft for 18 years. And I think every couple of years, I did a new thing. And while I would like to very much say, yeah, I totally figured out that I wanted to be an engineer...

+ +

CHAD: [laughs]

+ +

NEETU: And then a product manager, and then, you know, an engineer again, or then a product manager again, or a leadership role again, or even the stack as in work on small APIs or work on full enterprise-grade products or cloud...I would like to very much say those were very thought through, you know, clearly pre-planned career moves; they were not.

+ +

And particularly, in my case, they were very much I chased problems. And I would get very obsessed or interested in a particular problem. And then, I would go dive deep into that problem and aim to go solve it. And by the time I had figured it out and solved it, there was always a new problem. And this was the wonderful promise of Microsoft where, you know, it is so large, and there are so many different ways to think about different problems, or different ways you can bring software to market, or problems in the world you can solve with it, that I particularly took full advantage of it.

+ +

And that hasn't really changed in terms of how the rest of my career post-Microsoft has gone, either. Every couple of years, I find myself in a space that is completely scary, completely new, completely different. For me, that tends to be my happy place, to be working on super difficult things that are very scary.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot's Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: It does sound like even though you might not have some grand plan, [chuckles] you are driven to seek out challenges.

+ +

NEETU: Yeah. I heard something really, really long time ago that kind of has stuck with me always, which is don't let your curiosity die. So, if you are curious, don't just let it shy away; just indulge in it. That's how you're always moving forward. For me, that's been a big theme as in, I really, really enjoy always learning. Always finding myself not to be the smartest person in the room is really, really great. And always moving forward and pushing hard, and solving bigger and bigger problems.

+ +

CHAD: So, when you were deciding to join Oscar Health, how concerned were you with the particulars of the individual position that you were applying for? Or was it more, like, I've identified this space and this problem that I want to be a part of?

+ +

NEETU: Yeah, that's a really, really great question. And I think it's one of the ones that when I mentor people, I tell them about as well, which is, I had a role with Conductor that was this head of R&D, CTO, and CPO, and a very traditional ladder style path to the next step or something along those lines or bigger. But I personally am not motivated by titles as much as I am about potential impact I can have.

+ +

My walk into healthcare out of MarTech or out of just, like, platform was very personal in terms of I have a healthcare story. Everybody really has a healthcare story. And I wanted to go do something in this space, utilize all of the skills that I already have, and then try to push the space forward.

+ +

And so, when I joined Oscar, I was not really that motivated by what the title was going to be. I was really looking for is, is there going to be an opportunity to have an impact? And is there going to be space for me to have impact? Am I going to be surrounded by a group of people who I can have impact with? That was the primary concern. And I did join Oscar as a VP of engineering. And that didn't last very long.

+ +

Within the next year and a half, I was already promoted to CTO in that role. And each one of those steps was very much motivated by will I actually be able to have impact? Will I be empowered to have impact? Was I equipped to have an impact? And was I going to learn a lot in that role? Those were my primary motivators. And that's always been the case.

+ +

It's also a hard-won lesson. Like, when I had my first kid, it was a really difficult time, personally. I had really bad postpartum depression. I had really hard time dealing with what is going to happen with my career, and I had to take a step back. And as somebody who was, like, super ambitious and wanted to go straight up, that was a really challenging thing to do. And that was a long time ago, and I've been able to rebuild, quote, unquote, "rebuild" my career back multiple times over.

+ +

So it's actually been, like, a hard-won lesson where it doesn't kind of matter what part of the rocket ship you have a seat on, as long as you have the seat on the rocket ship. And by rocket ship, I wish I was only talking about stock price; I'm not. I'm just talking about the ability to have impact. If I can be in this right group and I can have a voice, then it didn't matter what my title was.

+ +

CHAD: Yeah, thank you for sharing. And I think it feels like the pace of change accelerates. But in growing organizations, so much changes all of the time. So what you are doing...or the roles that exist will change as well. And the other thing...I often get asked by clients, "Should we be hiring a VP of engineering or a CTO?" I'm like, the definition of those roles varies so much between company, and team size, and everything. It's like; it really is difficult to answer that question because it is so different. It all depends on the needs of the organization.

+ +

NEETU: Yeah. I've done both of those roles, at least twice each time, twice now. And I've personally discovered that A, those roles don't really have a defined, like, there is no clear definition for either one of those roles.

+ +

The other thing that I think is more important is I don't think the organizations know what they want out of those roles most of the times, either. In my experience so far, VP of engineering is a little bit easier to define because it has a very heavy management component to it. And so I've ended up just defining those roles for myself every time, and so far, so good.

+ +

And the way I define those roles is very much, like, a CTO role is a half-business half-technical role. It's the role where you understand the business strategy and turn it into a tech strategy that supports the business strategy and pushes the business forward, and acts as the competitive advantage for the business. And your role is, in fact, to be the person who takes tech and applies it to pushing the business forward. That's one direction.

+ +

And the other direction, it is the role to take the business strategy and translate into technical terms so that you can bring and coalesce your whole team's motivation around it and bring the whole team around it. And I definitely find this very much at Oscar, where most people who join Oscar engineering and Oscar tech they all come motivated outside of Oscar already to help push the industry forward in one way or another.

+ +

So actually keeping that motivation in the right place all the time with authenticity and truth about what it is, how we're pushing the business forward. And helping the business move forward is an extremely valuable skill. So, from my perspective, the tech role is definitely half-business, half-tech with some variable sprinkling of management attached to it, and I think that's the CTO role. And the VP of engineering was very heavily bent towards management, I think, yeah.

+ +

CHAD: Well, so in that CTO role, we'll often be faced with understanding how industry changes, or new technology, or whatever can help the business. Obviously, we have a big one happening right now with artificial intelligence or large language models and machine learning. I have a couple of questions around this area. But, like, is there something in particular with that that you're either thinking about now in terms of Oscar or have already incorporated?

+ +

NEETU: Yeah. I think large language models and generative AI, in general, is definitely an inflection point. And I think it's an inflection point that is going to help push so many things forward. And I think healthcare is very interestingly poised towards pushing in that direction. There is everything from, like, shortage of providers or shortage of mental health providers to just a large availability of data in the healthcare space that can help discover things that may not be the easiest to discover through humans looking at it. So I think there's a huge opportunity.

+ +

I also think it needs, like, a bit of cautious evaluation. We are dealing with something that you can't break, so you can't move fast and break things when you're dealing with people. But there are interesting use cases where you could use generative AI and have it maybe not make a decision for a person but assist the provider to make a decision. Or you can use it in areas, at least in healthcare space, where there is a lot of inefficiency because of too much to do. And you can actually optimize a whole bunch of that.

+ +

So examples could be, you know, there's the standard examples of chatbots as in, is this doctor part of my network? Can I have an appointment with this doctor? Can I have an appointment and a prior auth with this doctor immediately? Like, those are, I think, a little bit more accessible use cases. And Oscar, also, we're exploring and figuring out which one of those makes most sense for us in our business. And there's tons of excitement and tons of, like, thought being put behind it. As of right now, I probably can't say all the things that we're working on at the moment. But yes, absolutely, this is a very big deal.

+ +

CHAD: So, speaking more generally around exploring new ideas, you mentioned at Conductor, you were in an R&D role combined...like, is there strategies that you've seen that work particularly well for doing research and development within an organization, exploring new ideas, figuring things out?

+ +

NEETU: Yeah. It definitely depends on which portion or which portion of the maturity stack you're on. If you're building software that is going to be sold to enterprises, you have to have some version of a promise of a date, and then you have to keep your promise. So, if you're selling enterprise software, you have to be predictable because your partners on the other side are relying on you.

+ +

And you can't actually get predictability without having enough stability in your team, and enough stability in your roadmaps, and enough stability in your tech environment [inaudible 22:30] So that you can figure out what you're going to build, you can figure out where you're going to build, and how you're going to build it. You can figure out what teams and resources you're going to allocate to it. And you can also have some confidence that when you're ready to send code out to production, there is some automated CI/CD system that is, like, going to help you make sure that the number of errors that you are sending out into the world is as few as possible.

+ +

And that superpower of being able to, like, churn out code and features and products like a machine on a pretty regular basis has the potential downside of not being able to disrupt yourself. And I think there are definitely a couple of strategies to do that. One of them is to allocate enough space by filling it with P2s as opposed to everything being a P0, that if you were to, like, displace the P2s with something that is new and available now, then you're going to be okay because you can live without the P2s. We had to have enough of those.

+ +

There is also the whole skunk works model, which I think works pretty well. I think it does need to be set up carefully so that you're not, like, destroying the motivation of everybody in the team. You do have the opportunity to do the skunkworks model. And, like, the generating ideas portion, we do this at Oscar, and I think this is also done elsewhere. We have pretty regular hackathons that are dedicated amounts of time, and we put them on the schedule. And, during that time, we just go explore and dream and go build other things. And we build it collaboratively with the rest of the business.

+ +

And there are definitely still, like, stories of things that were developed in a hackathon that served us really well for years on end. And I don't think that's ever going to change. But anything that is, like, a real solid enterprise production stuff probably needs a dedicated skunkworks something or the other so you can...I don't think it's a bad thing to have solid schedules. I think it's a really huge superpower to have solid schedules. I do think you have to have the discipline to be able to disrupt yourself; otherwise, somebody else will.

+ +

CHAD: Right. And so figuring out a structure, you can do that. And, like you said, you know, you don't want to ruin the morale or the excitement of the entire organization where people say, like, "Well, it's not my job," you know, or, "I wish I could work on this, but it's this team's." And you're not set up to capture that individual person's excitement over generative AI, for example, who is the one who's actually going to make it happen. And you're squashing that because they're not, quote, unquote, "supposed to work on it." I think that's a really difficult balance to strike.

+ +

NEETU: Yeah, I think it is. But I don't know; there are very few things in the healthcare space that anybody does that is easy.

+ +

CHAD: Yeah, that's a good point. Now that you've been in the role, well, at Oscar for a few years, what's next? What are the things that, like, you feel like are sort of motivating you each day you come to work?

+ +

NEETU: Oscar is in the ACA space, which serves primarily underserved communities. There have been, like, some recent examples of where people had to shutter doors in the ACA space. So the fact that we're still around and the fact that we're successful, like, we don't take that for granted. It's a really valuable thing to be able to survive in this market and to be able to grow.

+ +

We launched a mission-driven tech-focused company ten years ago based on the belief that you could build your own tech stack and be successful in a very tightly controlled market. And I think this is the year that we actually had to just, like, really prove out the use case. So, this year, Oscar is 100% focused on being insure co profitable. And once we finish proving that out, next year, we're going to prove out that it is... Holdco can be profitable, which is all of our tech stack, in addition to all of our insurance business.

+ +

And I'm very, very much looking forward to Oscar being successful this year in the mission, where I think it's just proving out that you can build a successful business and ACA-powered by your own tech stack. And not compromising on the outcomes for our members is really valuable and keeps me very motivated.

+ +

And then, looking at the future, looking at being able to be 100% full company profitable and potentially selling our software for others so they could also bring this efficiency to their businesses is extremely motivating for me. And, as of right now, this is what the whole company is focused on. And we're all super excited about it.

+ +

CHAD: Yeah, oftentimes, having a clear goal that everyone knows about and is working on can be really empowering for an organization, even if it's hard.

+ +

NEETU: Yeah. Like I said before, I think almost everybody I've interacted with at Oscar didn't come to Oscar, assuming it was going to be easy. They came to Oscar with full knowledge that it was going to be hard, but they were going to try anyway. So we are so close.

+ +

CHAD: Yeah. And, you know, that's one of the things that, at thoughtbot, we skew to working with clients that do positive things for the world, that deserve to exist for precisely this reason, is when you have a positive purpose in your organization, it makes working hard easier, [laughs] or solving big problems easier because you know that you're going to have a positive impact when you do.

+ +

NEETU: Yeah. The personal healthcare story was a motivating factor towards going to go do something that was, like, going to be, like, positive for the world. I wish I could say, yes, I'm going to solve all of healthcare's problems and [inaudible 29:02] not that way.

+ +

CHAD: Yeah. Well, that was actually what I was going to ask you about next is that's the thing about healthcare. And I've seen people almost get demoralized for it because you actually can't solve every problem. It's really difficult to solve all of healthcare. So, how do you sort of exist within that environment and not get demotivated?

+ +

NEETU: I think the more you dig into the problem, the more you realize how interconnected the way in, like, society, politics, money, power, and tech it really is. And it seems like if you try to solve the whole thing, it almost feels like you're going to boil the whole ocean. And it is definitely a blocker from even trying.

+ +

And, for me, it was just like, does that mean I stop? Do I apply the boy scout rule of, like, just trying to leave it better off, a whole lot better off, as much possible better off than I found it? I could do that. Or I could just go do something completely different. But there is no guarantee it's going to be as motivating or potentially as impacting. So, for me, it's very much about, like, if I could make even small changes, I know they'll be part of a greater whole. So I will just try to make those small changes because, alternatively, I may be neutral for the world at most.

+ +

CHAD: Well, Neetu, thank you so much for stopping by and sharing with us. I really appreciate it.

+ +

NEETU: Thank you very much for having me. It's been a great conversation.

+ +

CHAD: If folks want to get in touch with you or follow along, where are the best places for them to do that?

+ +

NEETU: I am easy to find on LinkedIn. I do have a Twitter account, but I'm not very active. It's @Nee2D2, and I look forward to hearing from people.

+ +

CHAD: Awesome.

+ +

You can subscribe to the show and find notes for this episode, along with a complete transcript, at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Mastodon @cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Neetu Rajpal.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+q0U_UB7V + + ]]> + + Chad Pytel + Neetu Rajpal + + + 480: klo.dev with Aaron Torres and Ala Shiban + https://podcast.thoughtbot.com/480 + 0df6a926-0971-4609-b6cc-fb3afcecc268 + Thu, 22 Jun 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Aaron Torres and Ala Shiban are from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. + +Victoria talks to Aaron and Ala about the Klotho engine, Klotho the CLI tool, and InfraCopilot and how they work together to help enable developer teams to iterate on applications and features quickly. + 39:17 + no + + + Aaron Torres and Ala Shiban are from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. +Victoria talks to Aaron and Ala about the Klotho engine, Klotho the CLI tool, and InfraCopilot and how they work together to help enable developer teams to iterate on applications and features quickly. +Klotho (https://klo.dev/) +Infrastructure Copilot (https://infracopilot.io/) +Follow Klotho on Github (https://github.com/klothoplatform/klotho), Discord (https://discord.com/invite/4wwBRqqysY), Twitter (https://twitter.com/GetKlotho), or LinkedIn (https://www.linkedin.com/company/klothoplatform/). +Follow Aaron Torres on LinkedIn (https://www.linkedin.com/in/torresaaron/), or Twitter (https://twitter.com/aarontorres). +Follow Ala Shiban on LinkedIn (https://www.linkedin.com/in/alashiban/) or Twitter (https://twitter.com/AlaShiban). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Aaron Torres and Ala Shiban from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. Aaron and Ala, thank you for joining me. +ALA: Thank you for having us. +AARON: Yeah, thank you very much. +VICTORIA: Well, great. I wanted to just start with a little bit of a icebreaker; maybe tell me a little bit more about what the weather is like where you're currently at. +AARON: So I'm in St. Louis, Missouri. Right now, it is definitely...it feels like summer finally. So we're getting some nice, warm days and clear skies. +ALA: And I'm in LA. And it's gloomier than I would like compared to what it's been in the last few years. But I'll take it if this means we're getting closer to summer. +VICTORIA: Right. And I'm not too far from you, Ala, in San Diego, and it's a little chillier than I would prefer as well. But that's what we get for living close to the beach. So there's always trade-offs. +Well, wonderful. I'm so excited to talk to you about your product here today. Let me start with a question about, let's say, I'm a non-technical founder, and I've just heard about your product. What's your pitch to someone in that position on the value of your tool? +ALA: For somebody who isn't technical, I would say you can enable your team, your developer team, to quickly iterate on their applications or features and let InfraCopilot and Klotho take care of taking that application or features and deploy them and getting them running on the cloud. +VICTORIA: Okay. So maybe I've been thinking about having to hire an AWS engineer or someone who's an infrastructure engineer. I could consider getting a tool like Klotho and Infrastructure Copilot to allow my developers to take on more of that responsibility themselves. +ALA: Absolutely. +VICTORIA: Gotcha. Okay, well, great. So let me ask about how did it all get started? What was the impetus that set you on this journey +ALA: Both Aaron and I used to work at Riot Games, and I used to lead the cloud services org at Riot. I had about 50 people, 40 engineers, as part of a larger 120-person org, infrastructure platform org, which was tasked with building the platform that runs League of Legends, VALORANT, for 200 million people all around the world, in China. Full DevOps mode for Riot developers and full ops mode for running in China. +It took us three years, a lot of effort. And by the time we were done, it was already legacy, and that seemed broken to me. We were already getting started to do another round of upgrades and iterations. At that point, I decided to leave. But I couldn't let go of this feeling that we shouldn't have had to spend so many years solving a problem only for it not to be solved. And based on research and conversations, it was clear that this was an industry-wide phenomena. And so I went about trying to figure out why that happens and then how we can solve it, and that's how Klotho came about. +VICTORIA: That's so interesting. And I've certainly been a part of similar situations where you spend so much time solving a big problem and infrastructure only to get to the end of it and realize now you have a whole nother set of problems. [laughs] And you get upgrade. And they've also invented new ways of doing things in the cloud that you want to be able to take advantage of. +So you had that time with Riot Games and League of Legends and building this globally responsive infrastructure. What lessons learned did you take from that into building Klotho and building your product, Infrastructure Copilot? +AARON: We learned a bunch of things. One of the more difficult problems to solve isn't technical at all; it's organizational and understanding how the organization flows and how the different teams interact with each other. So we really endeavor to solve that problem. I mean, our product is a technical product, but it is meant to help bridge that gulf and make that problem a little bit easier as well. +Otherwise, yeah, exactly to your point, part of the problem with these migrations is that new technology comes along. And there's definitely a feeling of when you hire new developers, they are excited about the new thing, and there's other reasons as well. But you get this kind of natural, eternal migration going to the newer technology. +VICTORIA: That makes sense. And you bring up a great point on some of the issues, not being technical but organizational. And when I look at a lot of infrastructure-as-code tools, when we get to security, I wonder how it fits in with the organizational requirements for security, right? Like, you have to have defined groups who have defined access to different levels and have the tools in place to be able to manage identities in your organization. So I'm curious how that fits into what you built with Klotho and the Infrastructure Copilot. +ALA: The way we think about infrastructure is as a set of intents or things that developers, and operators, cloud engineers, infrastructure engineers are trying to satisfy or to do. So you have tasks. You're trying to build a solution. You're trying to build an architecture or add something to it. And organizations have constraints, whether it's their own Terraform, or their own ruleset, or security expectations, or compliance expectations. +And the way we look at this dynamic is those rules are encoded in a way that Klotho, which is a cloud compiler, it has the ability to reason about both the application and the infrastructure-as-code and enforce or at least warn about mismatches between the constraints that the organization sets, and what the developer or operator are trying to do, or the intent that is being described high level or low level within the tools. And then that is reflected both visually and in code and in the infrastructure-as-code, one or more. And so it's very much rooted in how the entire set of technologies and product and tools are designed. +VICTORIA: Got it. So do you see the tool will be more fit for the market of larger development shops who maybe have existing infrastructure but want to experiment with a different way of managing it for their developers? +ALA: It depends. So because we went about solving the problem rather than just building a specific vertical or a specific stack piece, we try to only play in this space of intelligent editing and intelligent understanding of the alignment between infrastructure and code. And so you could, as a developer, effectively with Klotho, write a plain application and have it be running in the cloud without knowing anything in the underlying cloud systems. It will set up storage, and persistence, and security, and secrets. All those elements are easily accessible within the code itself. +It can also work in the context of a company where the infrastructure or platform team have set those rules and guidance within the tools. And then, developers can continue working the way they expect to work, either in code or in the infrastructure-as-code layer. And it would still allow them to do the same intents that they want only within that sandbox. Or if they can't be satisfied because they're trying to do something that isn't allowed, they have a mechanism of, one, knowing that but also asking, in our case, InfraCopilot to help it reshape what it's doing, what they're doing into the sandbox and the trade-offs that that brings in. +VICTORIA: Got it. So you can both start from scratch and start a brand new application using it, or you can integrate it with your existing rules and systems and everything that already exists. +ALA: Exactly. +VICTORIA: Gotcha. Yeah, I think one interesting thing we've found with very new founders who are building their application for the first time is that there are some essential things, like, they don't even have an identity store like a Google [laughs] or Microsoft Azure Directory. So starting to work in the cloud, there are some basic elements you have to set up first that's a little bit of a barrier. So it sounds like what you're saying with Klotho is that you wouldn't necessarily have those same issues. Or how would you get that initial, like, cloud accounts set up? +AARON: Yeah. So, for the situation where you're bootstrapping everything from scratch, you've done nothing; we haven't invested much in setting up the initial accounts. But assuming you get to the point where you have AWS credentials, and you're able to hit the AWS API using the CLI, that's sort of where we can take over. So, yeah, like, I would say right now, as a business, it's definitely where the value is coming is going to be these mid-sized companies. But for that scenario specifically, bootstrapping and starting something from scratch, if you have that initial setup in place, it's one of the fastest ways to go from a concept to something running in the cloud. +ALA: And if you think about the two tools that we're building, there's Klotho, which InfraCopilot...or the Klotho engine, which Klotho the CLI tool uses and InfraCopilot uses. The Klotho engine is responsible for the intelligence. It knows how to translate things like I want a web API that talks to DynamoDB. And it will literally create everything or modify everything that is needed to give you that and plug in your code. +You can also say things in a much higher level degree, which things like I want a lambda which handles 10,000 users. And I want it to be lowest latency talking to an RDS Instance or to a Postgres database. And what that would do is, in our side, in the Klotho engine, we understand that there needs to be a VPC and subnets, and spin up RDS, and connect an RDS proxy. Because for connection pooling with lambda specifically, you need one to scale to that degree of scale. And so that is the intelligence that is built into the Klotho engine if you want to start from the infrastructure. +If you want to start from code, all you have to do is bring in the Redis instance, the Redis SDK, and, let's say, your favorite web framework, and just add the annotations or the metadata that says, I want this web framework to be exposed to the internet, and I want this Redis to be persisted in the cloud. And you run Klotho. And what comes out the other end is the cloud version that does that for you. And it's one command away from getting it to run. +VICTORIA: So that's interesting how the two tools work together and how a developer might be able to get things spun up quickly on the cloud without having to know the details of each particular AWS service. And reading through your docs, it sounds like once you have something working in the cloud, then you'll also get automated recommendations on how to improve it for cost and reliability. Is that right? +ALA: That's where we're headed. +VICTORIA: Gotcha. I'm curious; for Aaron, it sounds like there is more in that organizational challenges that you alluded to earlier. So you want to be able to deliver this capability to developers. But what barriers have you found organizationally to getting this done? +AARON: So I'm going to speak specifically on infrastructure here because I think this is one of the biggest ones we've seen. But typically, when you get to a larger-sized company, we'll call it a mid-sized company with, you know, a couple hundred engineers or more, you get to the point where it doesn't make sense for every team to own their entire vertical. And so you want to really put the cloud knowledge into a central team. +And so you tend to build either a platform team, or an infrastructure team, or a cloud team who sort of owns how cloud resources are provisioned, which ones they support, et cetera. And so, really, some of the friction I'm talking about is the friction between that team and developer teams who really just want to write their application and get going quickly. But you don't have to fall within the boundaries set by that central team. +To give, like, a real concrete example of that, if you wanted to prototype a new technology, like, let's say that some new database technology came out and you wanted to use it, it's a very coordinated effort between both teams in terms of the roadmap. Like, the infrastructure team needs to get on that roadmap, that they need to make a sandbox and how that's going to work. The code team needs to make an application to test it. And the whole thing requires a lot more communication than just tech. +VICTORIA: Yeah, no, I've been part of kind of one of those classic DevOps problems. It's where now you've built the ops team and the dev team, [laughs] and now you're back to those coordination issues that you had before. So, if I were a dev using Klotho or the infrastructure-as-code copilot, I would theoretically have access to any AWS sandbox account. And I could just spin up whatever I wanted [laughs] within the limits that could be defined by your security team or by your, you know, I'm sure there's someone who's setting a limit on the size of databases you could spin up for fun. Does that sound right? +AARON: Yeah, that's totally right. And in addition to just limits, it's also policies. So a good example is maybe in production for databases, you have a data retention policy. And you have something like we need to keep three months of backups for this amount of time. We want to make sure that if someone spins up a production database from any of those app teams, that they will follow their company policy there and not accidentally, like, lose data where it has to be maintained for some reason. +ALA: That's an important distinction where we have our own set of, you know, best practice or rules that are followed roughly in the industry. But also, the key here is that the infrastructure central teams in every company can describe the different rulesets and guidelines, guardrails within the company on what developers can do, not only in low-level descriptions like instance sizes or how much something is, whether it's Spot Instances always or not in production versus dev. But also be able to teach the system when a developer says, "I want a database," spin up a Postgres database with this configuration that is wired to the larger application that they have. +Or, if I want to run a service, then it spins up the correct elements and configures them to work, let's say, Kubernetes pods, or lambdas, or a combination based on what the company has described as the right way for that company to do things. And so it gives flexibility to not know the specific details but still get the company's specific way of doing them. +And the key here is that we're trying to codify the communication patterns that do happen, and they need to happen if there's no tools to facilitate it between the infrastructure platform team and the feature teams. Only in this case, we try and capture that in a way that the central teams can define it. And the developers on feature teams can consume it without having as much friction. +VICTORIA: So that will be different than, like, an infrastructure team that's putting out everything in Terraform and doing pull requests based off GitHub repository to that. It makes it a little more easier to read, and understand, and share the updates and changes. +AARON: Right. And also, I mean, so, like, the thing you're describing of, like, the central team, having Terraform tends to be, like, these golden templates. Like they say, "If you want to make a database, here's your database template." And then you get a lot of interesting issues like drift, where maybe some teams are using the old versions of the templates, and they're not picking up the new changes. And how do you kind of reconcile all that? So it is meant to help with all of those things. +VICTORIA: That makes a lot of sense. And I'm curious, what questions came up in the customer discovery process for this product that surprised you? +ALA: I think there's one...I don't know that it was a question, but I think there was...So, when we started with Klotho, Klotho has the ability to enable a code-first approach, which means that you give the tool to developers as the infrastructure or platform team, or if you're a smaller shop, then you can just use Klotho directly. You set the rules on what's allowed or what's not allowed, and then developers can work very freely. They can describe very succinctly how to turn a plain object, SDK, et cetera, how to build larger architectures very quickly with a few annotations that we describe and that give cloud powers. +We had always thought that some teams will feel that this encroaches on their jobs. We've heard from people on infra, you know, platform teams, "This is amazing. But this is my job." And so, one of our hypotheses was that we are encroaching into what they see as their responsibility. And we built more and more mechanisms that would clean up that interface and give them the ability to control more so they can free themselves up, just like most automations that happen in the world, to do more things. +What happened later surprised us. And by having a few or several more discoveries, we found out that the feeling isn't a fear of the tool replacing their job. The fear or worry is that the tool will make their jobs boring, what is left of the job be boring, and nobody wants to go to work and not have cool and fun things to do. And because I think we all, on a certain degree, believe that, you know, if we take away some of the work that we're doing, we'll find something higher level and harder to solve, but until that exists in people's minds, there's nothing there. And therefore, they're left with whatever they don't want to do or didn't want to do. +And so that's where we tried to take a step back from all the intelligence the Klotho engine provides through that code-first Klotho. And we built out focusing on one of the pillars in the tech to create InfraCopilot, which helps with keeping or making the things that we already do much simpler but also in a way that maintains and does it in a fun way. +VICTORIA: That makes sense because my understanding of where to use AI and where to use machine learning for best purposes is to automate those, like, repetitive, boring tasks and allow people to focus on the creative and more interesting work, right? +ALA: Yes and no. The interesting bit about our approach to ML is that we don't actually use machine learning or ChatGPT for any of the intelligence layers, meaning we don't ask ChatGPT to generate Terraform or any kind of GPT model to analyze a certain aspect of the infrastructure. That is all deterministic and happens in the Klotho engine. That is the uniqueness of why this always works rather than if GPT happened to get it right. +What we use ML for is the ability to parse the intent. So we actually use it as a language model to parse the intent from what the user is trying to convey, meaning I want a lambda with an API gateway. What we get back from our use of ML is the user has asked for a lambda, an AWS lambda, and API gateway and that they be connected. That is the only thing we get back. And that is fed into the Klotho engine. And then, we do the intelligence to translate that to an actual architecture. +VICTORIA: That's a really cool way to use natural language processing to build cloud infrastructure. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +VICTORIA: I'm curious; you said you're already working on some issues about being able to suggest improvements for cost reduction and efficiencies. What else is on your roadmap for what's coming up next? +AARON: So there's a bunch of things in the long-term roadmap. And I'll say that, like, in the short term, it's much more about just expanding the breadth of what we support. If you think about just generating all the different permutations and types of infrastructure, it's, like, a huge matrix problem. Like, there's many, many dimensions that you could go in. And if you add an extra cloud or you add an extra capability, it expands everything. So you can imagine, like, testing it to make sure things work, and everything becomes very complicated. So, really, a lot of what we're doing is still foundational and trying to just increase the breadth, make the intent processing more intelligent, make the other bits work. +And then one of the areas right now is for our initial release of the product; we chose to use Discord as our interface for the chatbot. And the reason for that is because it gives us a lot of benefits of having sort of the community built in and the engagement built in where we can actually talk with users and try and understand what they're doing. +However, we really have a lot of UI changes and expansions that we'd like to do. And even from some of our early demo material, we have things like being able to right-click and being able to configure your lambda directly from the UI. So there's a lot of areas there that we can expand into an intent, too, once we get sort of the foundational stuff done, as an example. +The intelligence bit is a much bigger process, like, there's a lot of things to unpack there. So I won't talk about it too much. But if we were to just talk about the most simple things, it'd be setting up alerts somehow and then feeding into our system that, like, we're hitting those alerts, and we have to make modifications. A good example of that would be, like, configuring auto scaling on an instance for [inaudible 22:17]. So we can get some of those benefits now. The bigger vision of what we want to do with optimization requires a lot more exploration and also the ability to look at what's happening to your application while it's running in the cloud. +ALA: Let me maybe shed a bit more light on the problems we're trying to solve and where we're headed. When it comes to optimization, to truly optimize a cloud application, you have to reason about it on the application level rather than on the one service level. To do that, we have to be able to look at the application as an application. And today, there's a multi-repo approach to building cloud applications. +So one of the future work that we're going to do is be able to reason about existing infrastructure-as-code from different portions of the teams or organization or even multiple services that the same team works and link them together. So, when we look at reasoning about an architecture, it is within the entire context of the application rather than just the smaller bits and pieces. That's one layer. +Another layer is being able to ingest the real runtime application metrics and infrastructure metrics, let's say, from AWS or Azure into the optimizer system to be able to not only say, oh well, I want low latency. Then this is hard-coded to use a Fargate instance instead of a lambda. But more realistically, being able to see what that means in lambda world and maybe increase the concurrency count. +Because we know that within the confines of cost limitations or constraints that the company wants to have, it is more feasible and cost-effective to raise the minimum concurrency rate of that lambda instead of using Fargate. You can only do that by having real-time data, or aggregated data come from the performance characteristics of the applications. And so that's another layer that we're going to be focusing on. +The third one is, just like Aaron said, being able to approach that editing experience and operational experience, not just through one system like InfraCopilot but also through a web UI, or an app, or even as an extension to other systems that want to integrate with Klotho's engine. +The last thing that I think is key is that we're still holding on to the vision that infrastructure should be invisible to most developers. Infrastructure definition is similar to how we approach assembly code. It's the bits and pieces. It's the underlying components, the CPUs, the storage. And as long as we're building microservices in that level of fidelity, of like, thinking about the wiring and how things interconnect, then we're not going to get the gains of 10x productivity building cloud applications. We have to enable developers and operators to work on a higher abstraction. +And so our end game, where we're headed, is still what we want to build with Klotho, which is the ability to write code and have it be translated into what's allowed in the infrastructure within the constraints of the underlying platforms that infrastructure or platform teams set for the rest of the organization. It can be one set or multiple sets, but it's still that type of developers develop, and the infrastructure teams set them up to be able to develop, and there's separation. +VICTORIA: Those are all really interesting problems to be solving. I also saw on your roadmap that you have published on Klotho that you're thinking of open-sourcing Klotho on GitHub. +AARON: So, at this point, we already have the core engine of Klotho open-sourced, so the same engine that's powering InfraCopilot and Klotho, the tool itself is open source today. So, if anyone wants to take a look, it is on github.com/klothoplatform/klotho. +VICTORIA: Super interesting. And it sounds like you mentioned you have a Discord. So that's where you're also getting feedback from developers on how to do this. And I think that challenge you mentioned about creating abstractions so that developers don't have to worry as much about the infrastructure and platform teams can just enable them to get their work done; I'm curious what you think is the biggest challenge with that. It seems like a problem that a lot of companies are trying to solve. So, what's the biggest challenge? And I think what do you think is unique about Klotho and solving that challenge? +AARON: I guess what I would say the biggest challenge today is that every company is different enough that they all saw this in a slightly different way. So it's like, right now, the tools that are available are the building blocks to make the solution but not the solution itself. So, like, every cloud team approaches it on, let's build our own platform. We're building our own platform that every one of our developers is going to use. In some cases, we're building, like, frameworks and SDKs that everyone's going to use. But then the problem is that you're effectively saying my company is entering the platform management business. And there's no way the economies of scale will make sense forever in that world. So I think that's the biggest issue. +And I think the reason it hasn't been solved is it's just a very hard problem. There's many approaches, but there's not a clear solution that kind of brings it all together. And I think our product is positioned better than most to solve some of the higher-level abstractions. It still doesn't solve the whole problem. There's still some things that are going to be tricky. But the idea is, if you can get to the point where you're using some of our abstractions, then you've guaranteed yourself portability into the future, like, your architecture will be able to evolve, even in technologies that don't exist yet once they become available. +ALA: To tack on to what Aaron said, a key difference, and to our knowledge, this doesn't exist in any other tool or technology, is a fundamentally new architecture we call adaptive architecture. It is not microservices. It is not monoliths. It's a superset that combines all the benefits from monoliths, microservices, and serverless if you consider it a different platform or paradigm. What that means is that you get the benefits without the drawbacks. And the reason we can do it is because of the compiler approach that we're taking, where everything in the architecture that we produce is interchangeable. +The team has decided to use Kubernetes, a specific version of Kubernetes with Istio. That works great. And, a year later, it turns out that that choice no longer scales well for the use. And we need to use Linkerd. The problem in today's world and what companies have to do is retrofit everything and not only the technology itself, but it's the ripple effects of changing it into everything else that all the other choices that were made that depended on it. +In the Klotho world, because of the compilation step or the compilation approach and its extensibility, you could say, I want to take out Istio and replace it with Linkerd. And it would percolate all the changes that need to happen everywhere for that to maintain its semantic behavior. To our knowledge, that doesn't exist anywhere today. +VICTORIA: So it would do, maybe not, like, would do migrations for you as well? +ALA: I think migrations are a special case. When it comes to stateless things, yes. When it comes to data, we are much more conservative. Again, bringing what we've learned in different companies in, a lot of solutions try to solve all the things versus we're trying to play in a very specific niche, which is the adaptive architecture of it all. +But if you want to move data, there's fantastic tools for it, and we will guide you through getting the access to the actual underlying services and, say, great, write a migration system, or we can generate for you. But you will run it to move the data from, let's say, Postgres to MySQL or from being able to drain a unit on Kubernetes to a lambda. Some of those things are much more automatic. And the transition happened through the underlying technologies like Terraform or Pulumi. Others will require you to take a step, not because we can't do it for you but we want to be conservative with the choices. +AARON: I would also add that another aspect of this is that we don't position ourselves as being the center of the universe for these teams. Like a lot of products, you kind of have to adopt the platform, and everything has to plug into it, and if you don't adhere, it doesn't work. +We're trying very, very hard with our design to make it so that existing apps will continue to function like they've always functioned. If app developers want to continue using direct SDKs and managing config themselves, they can absolutely do that. And then they'll interact well with Klotho apps that are also in that same company. So we're trying to make it so that you can adopt incrementally without having to go all in. +VICTORIA: So that makes a lot of sense. So it's really helpful if you're trying to swap out those stateless parts of your infrastructure and you want to make some changes there. And then, if you were going to do a data migration, it would help you and guide you to where additional tools might be needed to do that. And at your market segment, you're really focusing on having it be an additional tool, as opposed to, like, an all-encompassing platform. Did I get it all right? +[crosstalk 31:07] +ALA: Exactly. +VICTORIA: [laughs] Cool. All right. Well, that's exciting. That's a lot of cool things that you all are working on. I'm curious how overall the workload is for you two. How big of a team do you have so far? How are you balancing out this work of creating something new and exciting that has such a broad potential scope? +AARON: Yeah. So, right now, the team is currently six people. So it's Ala and I, plus four additional engineers is the current team. And in terms of, like, where we're focusing, the real answer is that it's somewhat reactive, and it's very fast. So, like, it could be, like...in fact, Copilot went from ideation to us acting on it extremely quickly. And it wasn't even in the pipeline before that. So I'd actually say the biggest challenge has been where do we sort of focus our energy to get the best results? And a lot of where we spend our time is sort of meta-process of, like, making sure we're investing in the right things. +ALA: And I think that comes from both Aaron and I have been in the industry for over 15 years. We don't, you know, drop everything and now switch to something new. We're very both tactical and strategic with the pace and when we pivot. But the idea is when we decide to change and focus on something that we think will be higher value, and it's almost always rooted in the signals and hypotheses that we set out to kind of learn from, from every iteration that we go after. +We are not the type that would say, "Oh, we saw this. Let's drop everything, and let's go do it." I think we've seen enough in the industry that there's a measure of knowing when to switch, and when to refocus, and what to do when these higher tidbits come, and then being able to execute aggressively when that choice or decision happens. +VICTORIA: Are there any trends that you're watching right now that the outcome would influence a change in direction for you? +ALA: Not technically. I think what we're seeing in the industry is there's no real approaches to solving the problem. I would say most of the solutions and trends that we're seeing are...I call them streamlined complexity. We choose a set of technologies, and we make that easy. We make the SaaS version, and it can do these workloads, and it makes that easy. But the minute you step out of the comfort zone of those tools, you're back into the nightmare that building distributed systems brings with it, and then you're back to, you know, square one. +What we're trying to do is fundamentally solve the problem. And we haven't seen many at least make a lot of headway there. We are seeing a few of the startups that are starting to think in the same vein, which is the zeitgeist. And that's fantastic. We actually work with them closely to try and broaden the category. +VICTORIA: Right. Do you feel that other companies who are working in a similar problem space that there is...is it competitive between each other? Or do you think it's actually more collaborative? +ALA: It depends on the companies and what they're trying to achieve. Every set of companies have different incentives. So Google, Amazon, and Microsoft have, you know, are incentivized to keep you on their clouds. They may care less about what they have in there as long as you are happy to stay. So you'll see more open source being adopted. You will see Amazon trying to copy or operationalize a lot of open-source tools. Microsoft will give their...because they are working with larger companies to have more vertical solutions. Google is trying to catch up. +If you look at startups, you will see some focus more on developers. You'll see others focus on infra team. So it really depends on the intersection of the companies, and then they either collaborate or they compete, depending on how it affects their strategy. +In our case, we recognize that our competition is the incumbents and the current way of doing things. And so we are happy to collaborate with all the startups that are doing something in the vicinity of what we're doing, startups like Ampt, and Encore, and Winglang. And there's several others. We have our own Slack channel where we talk about, like, where we're headed or at least what we can do to support one another. +VICTORIA: Great. And I wonder if that's part of your business decision to open source your product as well or if there are other factors involved. +ALA: I think the biggest factor that we've seen, realistically, is the expectation in the developer community to have a core that is open source, not even the source available model but to have an open-source core that they can rely on always existing and referencing when, you know if the company disappears or Oracle buys them. And so I would say that that was the biggest determining factor in the end to open-sourcing the Klotho engine. It's a very pragmatic view. +VICTORIA: That makes sense. Well, I wanted to make sure we had time to ask one of my favorite questions that I ask on the podcast, and you can both answer. But if you could go back in time to when you first started this project, what advice would you give yourself? +ALA: I guess the advice that I would give is keep selling and start selling as early as you can, even before the vision is realized. Or let's say you're making kind of headway towards what you'll wind up sharing and giving companies, the lead time to creating the opportunities and the belief and the faith that you can solve problems for companies, and the entire machinery of doing that is a lot more complex than most founders, I think, or at least first-time founders or, honestly, myself have found it to be. +AARON: Yeah. If I try and answer that same question, it's very challenging. I guess my perspective now is there's nothing I could tell myself that would make me go any faster because a lot of it really is the journey. Like, the amount of stuff that we've learned in the last year of working on this and exploring and talking with people and everything else has been so vast that there's nothing I can communicate to past me that would prepare me any better. So [laughs] I think I would try just my best to be encouraging to just stick with it. +VICTORIA: Well, that's good. And who knows what you're going to learn in the next year that [laughs] probably might not help you in the past either? That's wonderful. Do you have any final takeaways for our listeners today or anything you'd like to promote? +ALA: So, from my lens, I've always wanted to do a startup but felt that the life setting wasn't quite ready. And a lot of the startup culture is talking about younger, earlier founders. I think having had the industry experience and understanding both the organizational and technical challenges, knowing more people, and engineers, and founders, potential founders, has been vastly more helpful than what I would have been able to pull off ten years ago. So, if you are thinking maybe it's too late, it is not. It's probably easier in some regards now. And yeah, check out InfraCopilot. It's on infracopilot.io. We would love to have you try it out and go on this journey with us. +AARON: Yeah, I would definitely echo that. I mean, sort of the same thing on the journey. Like, it's never too late to start. And yeah, like, I would say being in the industry and actually seeing these problems first-hand makes it so much more fulfilling to actually try and solve them. +VICTORIA: That's [inaudible 38:15]. I'm excited to see what you all accomplish. And I appreciate you coming on the show. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg or on Mastodon @vguido@thoughtbot.social. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guests: Aaron Torres and Ala Shiban. + + + Aaron Torres and Ala Shiban are from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code.

+ +

Victoria talks to Aaron and Ala about the Klotho engine, Klotho the CLI tool, and InfraCopilot and how they work together to help enable developer teams to iterate on applications and features quickly.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Aaron Torres and Ala Shiban from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. Aaron and Ala, thank you for joining me.

+ +

ALA: Thank you for having us.

+ +

AARON: Yeah, thank you very much.

+ +

VICTORIA: Well, great. I wanted to just start with a little bit of a icebreaker; maybe tell me a little bit more about what the weather is like where you're currently at.

+ +

AARON: So I'm in St. Louis, Missouri. Right now, it is definitely...it feels like summer finally. So we're getting some nice, warm days and clear skies.

+ +

ALA: And I'm in LA. And it's gloomier than I would like compared to what it's been in the last few years. But I'll take it if this means we're getting closer to summer.

+ +

VICTORIA: Right. And I'm not too far from you, Ala, in San Diego, and it's a little chillier than I would prefer as well. But that's what we get for living close to the beach. So there's always trade-offs.

+ +

Well, wonderful. I'm so excited to talk to you about your product here today. Let me start with a question about, let's say, I'm a non-technical founder, and I've just heard about your product. What's your pitch to someone in that position on the value of your tool?

+ +

ALA: For somebody who isn't technical, I would say you can enable your team, your developer team, to quickly iterate on their applications or features and let InfraCopilot and Klotho take care of taking that application or features and deploy them and getting them running on the cloud.

+ +

VICTORIA: Okay. So maybe I've been thinking about having to hire an AWS engineer or someone who's an infrastructure engineer. I could consider getting a tool like Klotho and Infrastructure Copilot to allow my developers to take on more of that responsibility themselves.

+ +

ALA: Absolutely.

+ +

VICTORIA: Gotcha. Okay, well, great. So let me ask about how did it all get started? What was the impetus that set you on this journey

+ +

ALA: Both Aaron and I used to work at Riot Games, and I used to lead the cloud services org at Riot. I had about 50 people, 40 engineers, as part of a larger 120-person org, infrastructure platform org, which was tasked with building the platform that runs League of Legends, VALORANT, for 200 million people all around the world, in China. Full DevOps mode for Riot developers and full ops mode for running in China.

+ +

It took us three years, a lot of effort. And by the time we were done, it was already legacy, and that seemed broken to me. We were already getting started to do another round of upgrades and iterations. At that point, I decided to leave. But I couldn't let go of this feeling that we shouldn't have had to spend so many years solving a problem only for it not to be solved. And based on research and conversations, it was clear that this was an industry-wide phenomena. And so I went about trying to figure out why that happens and then how we can solve it, and that's how Klotho came about.

+ +

VICTORIA: That's so interesting. And I've certainly been a part of similar situations where you spend so much time solving a big problem and infrastructure only to get to the end of it and realize now you have a whole nother set of problems. [laughs] And you get upgrade. And they've also invented new ways of doing things in the cloud that you want to be able to take advantage of.

+ +

So you had that time with Riot Games and League of Legends and building this globally responsive infrastructure. What lessons learned did you take from that into building Klotho and building your product, Infrastructure Copilot?

+ +

AARON: We learned a bunch of things. One of the more difficult problems to solve isn't technical at all; it's organizational and understanding how the organization flows and how the different teams interact with each other. So we really endeavor to solve that problem. I mean, our product is a technical product, but it is meant to help bridge that gulf and make that problem a little bit easier as well.

+ +

Otherwise, yeah, exactly to your point, part of the problem with these migrations is that new technology comes along. And there's definitely a feeling of when you hire new developers, they are excited about the new thing, and there's other reasons as well. But you get this kind of natural, eternal migration going to the newer technology.

+ +

VICTORIA: That makes sense. And you bring up a great point on some of the issues, not being technical but organizational. And when I look at a lot of infrastructure-as-code tools, when we get to security, I wonder how it fits in with the organizational requirements for security, right? Like, you have to have defined groups who have defined access to different levels and have the tools in place to be able to manage identities in your organization. So I'm curious how that fits into what you built with Klotho and the Infrastructure Copilot.

+ +

ALA: The way we think about infrastructure is as a set of intents or things that developers, and operators, cloud engineers, infrastructure engineers are trying to satisfy or to do. So you have tasks. You're trying to build a solution. You're trying to build an architecture or add something to it. And organizations have constraints, whether it's their own Terraform, or their own ruleset, or security expectations, or compliance expectations.

+ +

And the way we look at this dynamic is those rules are encoded in a way that Klotho, which is a cloud compiler, it has the ability to reason about both the application and the infrastructure-as-code and enforce or at least warn about mismatches between the constraints that the organization sets, and what the developer or operator are trying to do, or the intent that is being described high level or low level within the tools. And then that is reflected both visually and in code and in the infrastructure-as-code, one or more. And so it's very much rooted in how the entire set of technologies and product and tools are designed.

+ +

VICTORIA: Got it. So do you see the tool will be more fit for the market of larger development shops who maybe have existing infrastructure but want to experiment with a different way of managing it for their developers?

+ +

ALA: It depends. So because we went about solving the problem rather than just building a specific vertical or a specific stack piece, we try to only play in this space of intelligent editing and intelligent understanding of the alignment between infrastructure and code. And so you could, as a developer, effectively with Klotho, write a plain application and have it be running in the cloud without knowing anything in the underlying cloud systems. It will set up storage, and persistence, and security, and secrets. All those elements are easily accessible within the code itself.

+ +

It can also work in the context of a company where the infrastructure or platform team have set those rules and guidance within the tools. And then, developers can continue working the way they expect to work, either in code or in the infrastructure-as-code layer. And it would still allow them to do the same intents that they want only within that sandbox. Or if they can't be satisfied because they're trying to do something that isn't allowed, they have a mechanism of, one, knowing that but also asking, in our case, InfraCopilot to help it reshape what it's doing, what they're doing into the sandbox and the trade-offs that that brings in.

+ +

VICTORIA: Got it. So you can both start from scratch and start a brand new application using it, or you can integrate it with your existing rules and systems and everything that already exists.

+ +

ALA: Exactly.

+ +

VICTORIA: Gotcha. Yeah, I think one interesting thing we've found with very new founders who are building their application for the first time is that there are some essential things, like, they don't even have an identity store like a Google [laughs] or Microsoft Azure Directory. So starting to work in the cloud, there are some basic elements you have to set up first that's a little bit of a barrier. So it sounds like what you're saying with Klotho is that you wouldn't necessarily have those same issues. Or how would you get that initial, like, cloud accounts set up?

+ +

AARON: Yeah. So, for the situation where you're bootstrapping everything from scratch, you've done nothing; we haven't invested much in setting up the initial accounts. But assuming you get to the point where you have AWS credentials, and you're able to hit the AWS API using the CLI, that's sort of where we can take over. So, yeah, like, I would say right now, as a business, it's definitely where the value is coming is going to be these mid-sized companies. But for that scenario specifically, bootstrapping and starting something from scratch, if you have that initial setup in place, it's one of the fastest ways to go from a concept to something running in the cloud.

+ +

ALA: And if you think about the two tools that we're building, there's Klotho, which InfraCopilot...or the Klotho engine, which Klotho the CLI tool uses and InfraCopilot uses. The Klotho engine is responsible for the intelligence. It knows how to translate things like I want a web API that talks to DynamoDB. And it will literally create everything or modify everything that is needed to give you that and plug in your code.

+ +

You can also say things in a much higher level degree, which things like I want a lambda which handles 10,000 users. And I want it to be lowest latency talking to an RDS Instance or to a Postgres database. And what that would do is, in our side, in the Klotho engine, we understand that there needs to be a VPC and subnets, and spin up RDS, and connect an RDS proxy. Because for connection pooling with lambda specifically, you need one to scale to that degree of scale. And so that is the intelligence that is built into the Klotho engine if you want to start from the infrastructure.

+ +

If you want to start from code, all you have to do is bring in the Redis instance, the Redis SDK, and, let's say, your favorite web framework, and just add the annotations or the metadata that says, I want this web framework to be exposed to the internet, and I want this Redis to be persisted in the cloud. And you run Klotho. And what comes out the other end is the cloud version that does that for you. And it's one command away from getting it to run.

+ +

VICTORIA: So that's interesting how the two tools work together and how a developer might be able to get things spun up quickly on the cloud without having to know the details of each particular AWS service. And reading through your docs, it sounds like once you have something working in the cloud, then you'll also get automated recommendations on how to improve it for cost and reliability. Is that right?

+ +

ALA: That's where we're headed.

+ +

VICTORIA: Gotcha. I'm curious; for Aaron, it sounds like there is more in that organizational challenges that you alluded to earlier. So you want to be able to deliver this capability to developers. But what barriers have you found organizationally to getting this done?

+ +

AARON: So I'm going to speak specifically on infrastructure here because I think this is one of the biggest ones we've seen. But typically, when you get to a larger-sized company, we'll call it a mid-sized company with, you know, a couple hundred engineers or more, you get to the point where it doesn't make sense for every team to own their entire vertical. And so you want to really put the cloud knowledge into a central team.

+ +

And so you tend to build either a platform team, or an infrastructure team, or a cloud team who sort of owns how cloud resources are provisioned, which ones they support, et cetera. And so, really, some of the friction I'm talking about is the friction between that team and developer teams who really just want to write their application and get going quickly. But you don't have to fall within the boundaries set by that central team.

+ +

To give, like, a real concrete example of that, if you wanted to prototype a new technology, like, let's say that some new database technology came out and you wanted to use it, it's a very coordinated effort between both teams in terms of the roadmap. Like, the infrastructure team needs to get on that roadmap, that they need to make a sandbox and how that's going to work. The code team needs to make an application to test it. And the whole thing requires a lot more communication than just tech.

+ +

VICTORIA: Yeah, no, I've been part of kind of one of those classic DevOps problems. It's where now you've built the ops team and the dev team, [laughs] and now you're back to those coordination issues that you had before. So, if I were a dev using Klotho or the infrastructure-as-code copilot, I would theoretically have access to any AWS sandbox account. And I could just spin up whatever I wanted [laughs] within the limits that could be defined by your security team or by your, you know, I'm sure there's someone who's setting a limit on the size of databases you could spin up for fun. Does that sound right?

+ +

AARON: Yeah, that's totally right. And in addition to just limits, it's also policies. So a good example is maybe in production for databases, you have a data retention policy. And you have something like we need to keep three months of backups for this amount of time. We want to make sure that if someone spins up a production database from any of those app teams, that they will follow their company policy there and not accidentally, like, lose data where it has to be maintained for some reason.

+ +

ALA: That's an important distinction where we have our own set of, you know, best practice or rules that are followed roughly in the industry. But also, the key here is that the infrastructure central teams in every company can describe the different rulesets and guidelines, guardrails within the company on what developers can do, not only in low-level descriptions like instance sizes or how much something is, whether it's Spot Instances always or not in production versus dev. But also be able to teach the system when a developer says, "I want a database," spin up a Postgres database with this configuration that is wired to the larger application that they have.

+ +

Or, if I want to run a service, then it spins up the correct elements and configures them to work, let's say, Kubernetes pods, or lambdas, or a combination based on what the company has described as the right way for that company to do things. And so it gives flexibility to not know the specific details but still get the company's specific way of doing them.

+ +

And the key here is that we're trying to codify the communication patterns that do happen, and they need to happen if there's no tools to facilitate it between the infrastructure platform team and the feature teams. Only in this case, we try and capture that in a way that the central teams can define it. And the developers on feature teams can consume it without having as much friction.

+ +

VICTORIA: So that will be different than, like, an infrastructure team that's putting out everything in Terraform and doing pull requests based off GitHub repository to that. It makes it a little more easier to read, and understand, and share the updates and changes.

+ +

AARON: Right. And also, I mean, so, like, the thing you're describing of, like, the central team, having Terraform tends to be, like, these golden templates. Like they say, "If you want to make a database, here's your database template." And then you get a lot of interesting issues like drift, where maybe some teams are using the old versions of the templates, and they're not picking up the new changes. And how do you kind of reconcile all that? So it is meant to help with all of those things.

+ +

VICTORIA: That makes a lot of sense. And I'm curious, what questions came up in the customer discovery process for this product that surprised you?

+ +

ALA: I think there's one...I don't know that it was a question, but I think there was...So, when we started with Klotho, Klotho has the ability to enable a code-first approach, which means that you give the tool to developers as the infrastructure or platform team, or if you're a smaller shop, then you can just use Klotho directly. You set the rules on what's allowed or what's not allowed, and then developers can work very freely. They can describe very succinctly how to turn a plain object, SDK, et cetera, how to build larger architectures very quickly with a few annotations that we describe and that give cloud powers.

+ +

We had always thought that some teams will feel that this encroaches on their jobs. We've heard from people on infra, you know, platform teams, "This is amazing. But this is my job." And so, one of our hypotheses was that we are encroaching into what they see as their responsibility. And we built more and more mechanisms that would clean up that interface and give them the ability to control more so they can free themselves up, just like most automations that happen in the world, to do more things.

+ +

What happened later surprised us. And by having a few or several more discoveries, we found out that the feeling isn't a fear of the tool replacing their job. The fear or worry is that the tool will make their jobs boring, what is left of the job be boring, and nobody wants to go to work and not have cool and fun things to do. And because I think we all, on a certain degree, believe that, you know, if we take away some of the work that we're doing, we'll find something higher level and harder to solve, but until that exists in people's minds, there's nothing there. And therefore, they're left with whatever they don't want to do or didn't want to do.

+ +

And so that's where we tried to take a step back from all the intelligence the Klotho engine provides through that code-first Klotho. And we built out focusing on one of the pillars in the tech to create InfraCopilot, which helps with keeping or making the things that we already do much simpler but also in a way that maintains and does it in a fun way.

+ +

VICTORIA: That makes sense because my understanding of where to use AI and where to use machine learning for best purposes is to automate those, like, repetitive, boring tasks and allow people to focus on the creative and more interesting work, right?

+ +

ALA: Yes and no. The interesting bit about our approach to ML is that we don't actually use machine learning or ChatGPT for any of the intelligence layers, meaning we don't ask ChatGPT to generate Terraform or any kind of GPT model to analyze a certain aspect of the infrastructure. That is all deterministic and happens in the Klotho engine. That is the uniqueness of why this always works rather than if GPT happened to get it right.

+ +

What we use ML for is the ability to parse the intent. So we actually use it as a language model to parse the intent from what the user is trying to convey, meaning I want a lambda with an API gateway. What we get back from our use of ML is the user has asked for a lambda, an AWS lambda, and API gateway and that they be connected. That is the only thing we get back. And that is fed into the Klotho engine. And then, we do the intelligence to translate that to an actual architecture.

+ +

VICTORIA: That's a really cool way to use natural language processing to build cloud infrastructure.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: I'm curious; you said you're already working on some issues about being able to suggest improvements for cost reduction and efficiencies. What else is on your roadmap for what's coming up next?

+ +

AARON: So there's a bunch of things in the long-term roadmap. And I'll say that, like, in the short term, it's much more about just expanding the breadth of what we support. If you think about just generating all the different permutations and types of infrastructure, it's, like, a huge matrix problem. Like, there's many, many dimensions that you could go in. And if you add an extra cloud or you add an extra capability, it expands everything. So you can imagine, like, testing it to make sure things work, and everything becomes very complicated. So, really, a lot of what we're doing is still foundational and trying to just increase the breadth, make the intent processing more intelligent, make the other bits work.

+ +

And then one of the areas right now is for our initial release of the product; we chose to use Discord as our interface for the chatbot. And the reason for that is because it gives us a lot of benefits of having sort of the community built in and the engagement built in where we can actually talk with users and try and understand what they're doing.

+ +

However, we really have a lot of UI changes and expansions that we'd like to do. And even from some of our early demo material, we have things like being able to right-click and being able to configure your lambda directly from the UI. So there's a lot of areas there that we can expand into an intent, too, once we get sort of the foundational stuff done, as an example.

+ +

The intelligence bit is a much bigger process, like, there's a lot of things to unpack there. So I won't talk about it too much. But if we were to just talk about the most simple things, it'd be setting up alerts somehow and then feeding into our system that, like, we're hitting those alerts, and we have to make modifications. A good example of that would be, like, configuring auto scaling on an instance for [inaudible 22:17]. So we can get some of those benefits now. The bigger vision of what we want to do with optimization requires a lot more exploration and also the ability to look at what's happening to your application while it's running in the cloud.

+ +

ALA: Let me maybe shed a bit more light on the problems we're trying to solve and where we're headed. When it comes to optimization, to truly optimize a cloud application, you have to reason about it on the application level rather than on the one service level. To do that, we have to be able to look at the application as an application. And today, there's a multi-repo approach to building cloud applications.

+ +

So one of the future work that we're going to do is be able to reason about existing infrastructure-as-code from different portions of the teams or organization or even multiple services that the same team works and link them together. So, when we look at reasoning about an architecture, it is within the entire context of the application rather than just the smaller bits and pieces. That's one layer.

+ +

Another layer is being able to ingest the real runtime application metrics and infrastructure metrics, let's say, from AWS or Azure into the optimizer system to be able to not only say, oh well, I want low latency. Then this is hard-coded to use a Fargate instance instead of a lambda. But more realistically, being able to see what that means in lambda world and maybe increase the concurrency count.

+ +

Because we know that within the confines of cost limitations or constraints that the company wants to have, it is more feasible and cost-effective to raise the minimum concurrency rate of that lambda instead of using Fargate. You can only do that by having real-time data, or aggregated data come from the performance characteristics of the applications. And so that's another layer that we're going to be focusing on.

+ +

The third one is, just like Aaron said, being able to approach that editing experience and operational experience, not just through one system like InfraCopilot but also through a web UI, or an app, or even as an extension to other systems that want to integrate with Klotho's engine.

+ +

The last thing that I think is key is that we're still holding on to the vision that infrastructure should be invisible to most developers. Infrastructure definition is similar to how we approach assembly code. It's the bits and pieces. It's the underlying components, the CPUs, the storage. And as long as we're building microservices in that level of fidelity, of like, thinking about the wiring and how things interconnect, then we're not going to get the gains of 10x productivity building cloud applications. We have to enable developers and operators to work on a higher abstraction.

+ +

And so our end game, where we're headed, is still what we want to build with Klotho, which is the ability to write code and have it be translated into what's allowed in the infrastructure within the constraints of the underlying platforms that infrastructure or platform teams set for the rest of the organization. It can be one set or multiple sets, but it's still that type of developers develop, and the infrastructure teams set them up to be able to develop, and there's separation.

+ +

VICTORIA: Those are all really interesting problems to be solving. I also saw on your roadmap that you have published on Klotho that you're thinking of open-sourcing Klotho on GitHub.

+ +

AARON: So, at this point, we already have the core engine of Klotho open-sourced, so the same engine that's powering InfraCopilot and Klotho, the tool itself is open source today. So, if anyone wants to take a look, it is on github.com/klothoplatform/klotho.

+ +

VICTORIA: Super interesting. And it sounds like you mentioned you have a Discord. So that's where you're also getting feedback from developers on how to do this. And I think that challenge you mentioned about creating abstractions so that developers don't have to worry as much about the infrastructure and platform teams can just enable them to get their work done; I'm curious what you think is the biggest challenge with that. It seems like a problem that a lot of companies are trying to solve. So, what's the biggest challenge? And I think what do you think is unique about Klotho and solving that challenge?

+ +

AARON: I guess what I would say the biggest challenge today is that every company is different enough that they all saw this in a slightly different way. So it's like, right now, the tools that are available are the building blocks to make the solution but not the solution itself. So, like, every cloud team approaches it on, let's build our own platform. We're building our own platform that every one of our developers is going to use. In some cases, we're building, like, frameworks and SDKs that everyone's going to use. But then the problem is that you're effectively saying my company is entering the platform management business. And there's no way the economies of scale will make sense forever in that world. So I think that's the biggest issue.

+ +

And I think the reason it hasn't been solved is it's just a very hard problem. There's many approaches, but there's not a clear solution that kind of brings it all together. And I think our product is positioned better than most to solve some of the higher-level abstractions. It still doesn't solve the whole problem. There's still some things that are going to be tricky. But the idea is, if you can get to the point where you're using some of our abstractions, then you've guaranteed yourself portability into the future, like, your architecture will be able to evolve, even in technologies that don't exist yet once they become available.

+ +

ALA: To tack on to what Aaron said, a key difference, and to our knowledge, this doesn't exist in any other tool or technology, is a fundamentally new architecture we call adaptive architecture. It is not microservices. It is not monoliths. It's a superset that combines all the benefits from monoliths, microservices, and serverless if you consider it a different platform or paradigm. What that means is that you get the benefits without the drawbacks. And the reason we can do it is because of the compiler approach that we're taking, where everything in the architecture that we produce is interchangeable.

+ +

The team has decided to use Kubernetes, a specific version of Kubernetes with Istio. That works great. And, a year later, it turns out that that choice no longer scales well for the use. And we need to use Linkerd. The problem in today's world and what companies have to do is retrofit everything and not only the technology itself, but it's the ripple effects of changing it into everything else that all the other choices that were made that depended on it.

+ +

In the Klotho world, because of the compilation step or the compilation approach and its extensibility, you could say, I want to take out Istio and replace it with Linkerd. And it would percolate all the changes that need to happen everywhere for that to maintain its semantic behavior. To our knowledge, that doesn't exist anywhere today.

+ +

VICTORIA: So it would do, maybe not, like, would do migrations for you as well?

+ +

ALA: I think migrations are a special case. When it comes to stateless things, yes. When it comes to data, we are much more conservative. Again, bringing what we've learned in different companies in, a lot of solutions try to solve all the things versus we're trying to play in a very specific niche, which is the adaptive architecture of it all.

+ +

But if you want to move data, there's fantastic tools for it, and we will guide you through getting the access to the actual underlying services and, say, great, write a migration system, or we can generate for you. But you will run it to move the data from, let's say, Postgres to MySQL or from being able to drain a unit on Kubernetes to a lambda. Some of those things are much more automatic. And the transition happened through the underlying technologies like Terraform or Pulumi. Others will require you to take a step, not because we can't do it for you but we want to be conservative with the choices.

+ +

AARON: I would also add that another aspect of this is that we don't position ourselves as being the center of the universe for these teams. Like a lot of products, you kind of have to adopt the platform, and everything has to plug into it, and if you don't adhere, it doesn't work.

+ +

We're trying very, very hard with our design to make it so that existing apps will continue to function like they've always functioned. If app developers want to continue using direct SDKs and managing config themselves, they can absolutely do that. And then they'll interact well with Klotho apps that are also in that same company. So we're trying to make it so that you can adopt incrementally without having to go all in.

+ +

VICTORIA: So that makes a lot of sense. So it's really helpful if you're trying to swap out those stateless parts of your infrastructure and you want to make some changes there. And then, if you were going to do a data migration, it would help you and guide you to where additional tools might be needed to do that. And at your market segment, you're really focusing on having it be an additional tool, as opposed to, like, an all-encompassing platform. Did I get it all right?

+ +

[crosstalk 31:07]

+ +

ALA: Exactly.

+ +

VICTORIA: [laughs] Cool. All right. Well, that's exciting. That's a lot of cool things that you all are working on. I'm curious how overall the workload is for you two. How big of a team do you have so far? How are you balancing out this work of creating something new and exciting that has such a broad potential scope?

+ +

AARON: Yeah. So, right now, the team is currently six people. So it's Ala and I, plus four additional engineers is the current team. And in terms of, like, where we're focusing, the real answer is that it's somewhat reactive, and it's very fast. So, like, it could be, like...in fact, Copilot went from ideation to us acting on it extremely quickly. And it wasn't even in the pipeline before that. So I'd actually say the biggest challenge has been where do we sort of focus our energy to get the best results? And a lot of where we spend our time is sort of meta-process of, like, making sure we're investing in the right things.

+ +

ALA: And I think that comes from both Aaron and I have been in the industry for over 15 years. We don't, you know, drop everything and now switch to something new. We're very both tactical and strategic with the pace and when we pivot. But the idea is when we decide to change and focus on something that we think will be higher value, and it's almost always rooted in the signals and hypotheses that we set out to kind of learn from, from every iteration that we go after.

+ +

We are not the type that would say, "Oh, we saw this. Let's drop everything, and let's go do it." I think we've seen enough in the industry that there's a measure of knowing when to switch, and when to refocus, and what to do when these higher tidbits come, and then being able to execute aggressively when that choice or decision happens.

+ +

VICTORIA: Are there any trends that you're watching right now that the outcome would influence a change in direction for you?

+ +

ALA: Not technically. I think what we're seeing in the industry is there's no real approaches to solving the problem. I would say most of the solutions and trends that we're seeing are...I call them streamlined complexity. We choose a set of technologies, and we make that easy. We make the SaaS version, and it can do these workloads, and it makes that easy. But the minute you step out of the comfort zone of those tools, you're back into the nightmare that building distributed systems brings with it, and then you're back to, you know, square one.

+ +

What we're trying to do is fundamentally solve the problem. And we haven't seen many at least make a lot of headway there. We are seeing a few of the startups that are starting to think in the same vein, which is the zeitgeist. And that's fantastic. We actually work with them closely to try and broaden the category.

+ +

VICTORIA: Right. Do you feel that other companies who are working in a similar problem space that there is...is it competitive between each other? Or do you think it's actually more collaborative?

+ +

ALA: It depends on the companies and what they're trying to achieve. Every set of companies have different incentives. So Google, Amazon, and Microsoft have, you know, are incentivized to keep you on their clouds. They may care less about what they have in there as long as you are happy to stay. So you'll see more open source being adopted. You will see Amazon trying to copy or operationalize a lot of open-source tools. Microsoft will give their...because they are working with larger companies to have more vertical solutions. Google is trying to catch up.

+ +

If you look at startups, you will see some focus more on developers. You'll see others focus on infra team. So it really depends on the intersection of the companies, and then they either collaborate or they compete, depending on how it affects their strategy.

+ +

In our case, we recognize that our competition is the incumbents and the current way of doing things. And so we are happy to collaborate with all the startups that are doing something in the vicinity of what we're doing, startups like Ampt, and Encore, and Winglang. And there's several others. We have our own Slack channel where we talk about, like, where we're headed or at least what we can do to support one another.

+ +

VICTORIA: Great. And I wonder if that's part of your business decision to open source your product as well or if there are other factors involved.

+ +

ALA: I think the biggest factor that we've seen, realistically, is the expectation in the developer community to have a core that is open source, not even the source available model but to have an open-source core that they can rely on always existing and referencing when, you know if the company disappears or Oracle buys them. And so I would say that that was the biggest determining factor in the end to open-sourcing the Klotho engine. It's a very pragmatic view.

+ +

VICTORIA: That makes sense. Well, I wanted to make sure we had time to ask one of my favorite questions that I ask on the podcast, and you can both answer. But if you could go back in time to when you first started this project, what advice would you give yourself?

+ +

ALA: I guess the advice that I would give is keep selling and start selling as early as you can, even before the vision is realized. Or let's say you're making kind of headway towards what you'll wind up sharing and giving companies, the lead time to creating the opportunities and the belief and the faith that you can solve problems for companies, and the entire machinery of doing that is a lot more complex than most founders, I think, or at least first-time founders or, honestly, myself have found it to be.

+ +

AARON: Yeah. If I try and answer that same question, it's very challenging. I guess my perspective now is there's nothing I could tell myself that would make me go any faster because a lot of it really is the journey. Like, the amount of stuff that we've learned in the last year of working on this and exploring and talking with people and everything else has been so vast that there's nothing I can communicate to past me that would prepare me any better. So [laughs] I think I would try just my best to be encouraging to just stick with it.

+ +

VICTORIA: Well, that's good. And who knows what you're going to learn in the next year that [laughs] probably might not help you in the past either? That's wonderful. Do you have any final takeaways for our listeners today or anything you'd like to promote?

+ +

ALA: So, from my lens, I've always wanted to do a startup but felt that the life setting wasn't quite ready. And a lot of the startup culture is talking about younger, earlier founders. I think having had the industry experience and understanding both the organizational and technical challenges, knowing more people, and engineers, and founders, potential founders, has been vastly more helpful than what I would have been able to pull off ten years ago. So, if you are thinking maybe it's too late, it is not. It's probably easier in some regards now. And yeah, check out InfraCopilot. It's on infracopilot.io. We would love to have you try it out and go on this journey with us.

+ +

AARON: Yeah, I would definitely echo that. I mean, sort of the same thing on the journey. Like, it's never too late to start. And yeah, like, I would say being in the industry and actually seeing these problems first-hand makes it so much more fulfilling to actually try and solve them.

+ +

VICTORIA: That's [inaudible 38:15]. I'm excited to see what you all accomplish. And I appreciate you coming on the show.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg or on Mastodon @vguido@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Aaron Torres and Ala Shiban.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Aaron Torres and Ala Shiban are from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code.

+ +

Victoria talks to Aaron and Ala about the Klotho engine, Klotho the CLI tool, and InfraCopilot and how they work together to help enable developer teams to iterate on applications and features quickly.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Aaron Torres and Ala Shiban from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. Aaron and Ala, thank you for joining me.

+ +

ALA: Thank you for having us.

+ +

AARON: Yeah, thank you very much.

+ +

VICTORIA: Well, great. I wanted to just start with a little bit of a icebreaker; maybe tell me a little bit more about what the weather is like where you're currently at.

+ +

AARON: So I'm in St. Louis, Missouri. Right now, it is definitely...it feels like summer finally. So we're getting some nice, warm days and clear skies.

+ +

ALA: And I'm in LA. And it's gloomier than I would like compared to what it's been in the last few years. But I'll take it if this means we're getting closer to summer.

+ +

VICTORIA: Right. And I'm not too far from you, Ala, in San Diego, and it's a little chillier than I would prefer as well. But that's what we get for living close to the beach. So there's always trade-offs.

+ +

Well, wonderful. I'm so excited to talk to you about your product here today. Let me start with a question about, let's say, I'm a non-technical founder, and I've just heard about your product. What's your pitch to someone in that position on the value of your tool?

+ +

ALA: For somebody who isn't technical, I would say you can enable your team, your developer team, to quickly iterate on their applications or features and let InfraCopilot and Klotho take care of taking that application or features and deploy them and getting them running on the cloud.

+ +

VICTORIA: Okay. So maybe I've been thinking about having to hire an AWS engineer or someone who's an infrastructure engineer. I could consider getting a tool like Klotho and Infrastructure Copilot to allow my developers to take on more of that responsibility themselves.

+ +

ALA: Absolutely.

+ +

VICTORIA: Gotcha. Okay, well, great. So let me ask about how did it all get started? What was the impetus that set you on this journey

+ +

ALA: Both Aaron and I used to work at Riot Games, and I used to lead the cloud services org at Riot. I had about 50 people, 40 engineers, as part of a larger 120-person org, infrastructure platform org, which was tasked with building the platform that runs League of Legends, VALORANT, for 200 million people all around the world, in China. Full DevOps mode for Riot developers and full ops mode for running in China.

+ +

It took us three years, a lot of effort. And by the time we were done, it was already legacy, and that seemed broken to me. We were already getting started to do another round of upgrades and iterations. At that point, I decided to leave. But I couldn't let go of this feeling that we shouldn't have had to spend so many years solving a problem only for it not to be solved. And based on research and conversations, it was clear that this was an industry-wide phenomena. And so I went about trying to figure out why that happens and then how we can solve it, and that's how Klotho came about.

+ +

VICTORIA: That's so interesting. And I've certainly been a part of similar situations where you spend so much time solving a big problem and infrastructure only to get to the end of it and realize now you have a whole nother set of problems. [laughs] And you get upgrade. And they've also invented new ways of doing things in the cloud that you want to be able to take advantage of.

+ +

So you had that time with Riot Games and League of Legends and building this globally responsive infrastructure. What lessons learned did you take from that into building Klotho and building your product, Infrastructure Copilot?

+ +

AARON: We learned a bunch of things. One of the more difficult problems to solve isn't technical at all; it's organizational and understanding how the organization flows and how the different teams interact with each other. So we really endeavor to solve that problem. I mean, our product is a technical product, but it is meant to help bridge that gulf and make that problem a little bit easier as well.

+ +

Otherwise, yeah, exactly to your point, part of the problem with these migrations is that new technology comes along. And there's definitely a feeling of when you hire new developers, they are excited about the new thing, and there's other reasons as well. But you get this kind of natural, eternal migration going to the newer technology.

+ +

VICTORIA: That makes sense. And you bring up a great point on some of the issues, not being technical but organizational. And when I look at a lot of infrastructure-as-code tools, when we get to security, I wonder how it fits in with the organizational requirements for security, right? Like, you have to have defined groups who have defined access to different levels and have the tools in place to be able to manage identities in your organization. So I'm curious how that fits into what you built with Klotho and the Infrastructure Copilot.

+ +

ALA: The way we think about infrastructure is as a set of intents or things that developers, and operators, cloud engineers, infrastructure engineers are trying to satisfy or to do. So you have tasks. You're trying to build a solution. You're trying to build an architecture or add something to it. And organizations have constraints, whether it's their own Terraform, or their own ruleset, or security expectations, or compliance expectations.

+ +

And the way we look at this dynamic is those rules are encoded in a way that Klotho, which is a cloud compiler, it has the ability to reason about both the application and the infrastructure-as-code and enforce or at least warn about mismatches between the constraints that the organization sets, and what the developer or operator are trying to do, or the intent that is being described high level or low level within the tools. And then that is reflected both visually and in code and in the infrastructure-as-code, one or more. And so it's very much rooted in how the entire set of technologies and product and tools are designed.

+ +

VICTORIA: Got it. So do you see the tool will be more fit for the market of larger development shops who maybe have existing infrastructure but want to experiment with a different way of managing it for their developers?

+ +

ALA: It depends. So because we went about solving the problem rather than just building a specific vertical or a specific stack piece, we try to only play in this space of intelligent editing and intelligent understanding of the alignment between infrastructure and code. And so you could, as a developer, effectively with Klotho, write a plain application and have it be running in the cloud without knowing anything in the underlying cloud systems. It will set up storage, and persistence, and security, and secrets. All those elements are easily accessible within the code itself.

+ +

It can also work in the context of a company where the infrastructure or platform team have set those rules and guidance within the tools. And then, developers can continue working the way they expect to work, either in code or in the infrastructure-as-code layer. And it would still allow them to do the same intents that they want only within that sandbox. Or if they can't be satisfied because they're trying to do something that isn't allowed, they have a mechanism of, one, knowing that but also asking, in our case, InfraCopilot to help it reshape what it's doing, what they're doing into the sandbox and the trade-offs that that brings in.

+ +

VICTORIA: Got it. So you can both start from scratch and start a brand new application using it, or you can integrate it with your existing rules and systems and everything that already exists.

+ +

ALA: Exactly.

+ +

VICTORIA: Gotcha. Yeah, I think one interesting thing we've found with very new founders who are building their application for the first time is that there are some essential things, like, they don't even have an identity store like a Google [laughs] or Microsoft Azure Directory. So starting to work in the cloud, there are some basic elements you have to set up first that's a little bit of a barrier. So it sounds like what you're saying with Klotho is that you wouldn't necessarily have those same issues. Or how would you get that initial, like, cloud accounts set up?

+ +

AARON: Yeah. So, for the situation where you're bootstrapping everything from scratch, you've done nothing; we haven't invested much in setting up the initial accounts. But assuming you get to the point where you have AWS credentials, and you're able to hit the AWS API using the CLI, that's sort of where we can take over. So, yeah, like, I would say right now, as a business, it's definitely where the value is coming is going to be these mid-sized companies. But for that scenario specifically, bootstrapping and starting something from scratch, if you have that initial setup in place, it's one of the fastest ways to go from a concept to something running in the cloud.

+ +

ALA: And if you think about the two tools that we're building, there's Klotho, which InfraCopilot...or the Klotho engine, which Klotho the CLI tool uses and InfraCopilot uses. The Klotho engine is responsible for the intelligence. It knows how to translate things like I want a web API that talks to DynamoDB. And it will literally create everything or modify everything that is needed to give you that and plug in your code.

+ +

You can also say things in a much higher level degree, which things like I want a lambda which handles 10,000 users. And I want it to be lowest latency talking to an RDS Instance or to a Postgres database. And what that would do is, in our side, in the Klotho engine, we understand that there needs to be a VPC and subnets, and spin up RDS, and connect an RDS proxy. Because for connection pooling with lambda specifically, you need one to scale to that degree of scale. And so that is the intelligence that is built into the Klotho engine if you want to start from the infrastructure.

+ +

If you want to start from code, all you have to do is bring in the Redis instance, the Redis SDK, and, let's say, your favorite web framework, and just add the annotations or the metadata that says, I want this web framework to be exposed to the internet, and I want this Redis to be persisted in the cloud. And you run Klotho. And what comes out the other end is the cloud version that does that for you. And it's one command away from getting it to run.

+ +

VICTORIA: So that's interesting how the two tools work together and how a developer might be able to get things spun up quickly on the cloud without having to know the details of each particular AWS service. And reading through your docs, it sounds like once you have something working in the cloud, then you'll also get automated recommendations on how to improve it for cost and reliability. Is that right?

+ +

ALA: That's where we're headed.

+ +

VICTORIA: Gotcha. I'm curious; for Aaron, it sounds like there is more in that organizational challenges that you alluded to earlier. So you want to be able to deliver this capability to developers. But what barriers have you found organizationally to getting this done?

+ +

AARON: So I'm going to speak specifically on infrastructure here because I think this is one of the biggest ones we've seen. But typically, when you get to a larger-sized company, we'll call it a mid-sized company with, you know, a couple hundred engineers or more, you get to the point where it doesn't make sense for every team to own their entire vertical. And so you want to really put the cloud knowledge into a central team.

+ +

And so you tend to build either a platform team, or an infrastructure team, or a cloud team who sort of owns how cloud resources are provisioned, which ones they support, et cetera. And so, really, some of the friction I'm talking about is the friction between that team and developer teams who really just want to write their application and get going quickly. But you don't have to fall within the boundaries set by that central team.

+ +

To give, like, a real concrete example of that, if you wanted to prototype a new technology, like, let's say that some new database technology came out and you wanted to use it, it's a very coordinated effort between both teams in terms of the roadmap. Like, the infrastructure team needs to get on that roadmap, that they need to make a sandbox and how that's going to work. The code team needs to make an application to test it. And the whole thing requires a lot more communication than just tech.

+ +

VICTORIA: Yeah, no, I've been part of kind of one of those classic DevOps problems. It's where now you've built the ops team and the dev team, [laughs] and now you're back to those coordination issues that you had before. So, if I were a dev using Klotho or the infrastructure-as-code copilot, I would theoretically have access to any AWS sandbox account. And I could just spin up whatever I wanted [laughs] within the limits that could be defined by your security team or by your, you know, I'm sure there's someone who's setting a limit on the size of databases you could spin up for fun. Does that sound right?

+ +

AARON: Yeah, that's totally right. And in addition to just limits, it's also policies. So a good example is maybe in production for databases, you have a data retention policy. And you have something like we need to keep three months of backups for this amount of time. We want to make sure that if someone spins up a production database from any of those app teams, that they will follow their company policy there and not accidentally, like, lose data where it has to be maintained for some reason.

+ +

ALA: That's an important distinction where we have our own set of, you know, best practice or rules that are followed roughly in the industry. But also, the key here is that the infrastructure central teams in every company can describe the different rulesets and guidelines, guardrails within the company on what developers can do, not only in low-level descriptions like instance sizes or how much something is, whether it's Spot Instances always or not in production versus dev. But also be able to teach the system when a developer says, "I want a database," spin up a Postgres database with this configuration that is wired to the larger application that they have.

+ +

Or, if I want to run a service, then it spins up the correct elements and configures them to work, let's say, Kubernetes pods, or lambdas, or a combination based on what the company has described as the right way for that company to do things. And so it gives flexibility to not know the specific details but still get the company's specific way of doing them.

+ +

And the key here is that we're trying to codify the communication patterns that do happen, and they need to happen if there's no tools to facilitate it between the infrastructure platform team and the feature teams. Only in this case, we try and capture that in a way that the central teams can define it. And the developers on feature teams can consume it without having as much friction.

+ +

VICTORIA: So that will be different than, like, an infrastructure team that's putting out everything in Terraform and doing pull requests based off GitHub repository to that. It makes it a little more easier to read, and understand, and share the updates and changes.

+ +

AARON: Right. And also, I mean, so, like, the thing you're describing of, like, the central team, having Terraform tends to be, like, these golden templates. Like they say, "If you want to make a database, here's your database template." And then you get a lot of interesting issues like drift, where maybe some teams are using the old versions of the templates, and they're not picking up the new changes. And how do you kind of reconcile all that? So it is meant to help with all of those things.

+ +

VICTORIA: That makes a lot of sense. And I'm curious, what questions came up in the customer discovery process for this product that surprised you?

+ +

ALA: I think there's one...I don't know that it was a question, but I think there was...So, when we started with Klotho, Klotho has the ability to enable a code-first approach, which means that you give the tool to developers as the infrastructure or platform team, or if you're a smaller shop, then you can just use Klotho directly. You set the rules on what's allowed or what's not allowed, and then developers can work very freely. They can describe very succinctly how to turn a plain object, SDK, et cetera, how to build larger architectures very quickly with a few annotations that we describe and that give cloud powers.

+ +

We had always thought that some teams will feel that this encroaches on their jobs. We've heard from people on infra, you know, platform teams, "This is amazing. But this is my job." And so, one of our hypotheses was that we are encroaching into what they see as their responsibility. And we built more and more mechanisms that would clean up that interface and give them the ability to control more so they can free themselves up, just like most automations that happen in the world, to do more things.

+ +

What happened later surprised us. And by having a few or several more discoveries, we found out that the feeling isn't a fear of the tool replacing their job. The fear or worry is that the tool will make their jobs boring, what is left of the job be boring, and nobody wants to go to work and not have cool and fun things to do. And because I think we all, on a certain degree, believe that, you know, if we take away some of the work that we're doing, we'll find something higher level and harder to solve, but until that exists in people's minds, there's nothing there. And therefore, they're left with whatever they don't want to do or didn't want to do.

+ +

And so that's where we tried to take a step back from all the intelligence the Klotho engine provides through that code-first Klotho. And we built out focusing on one of the pillars in the tech to create InfraCopilot, which helps with keeping or making the things that we already do much simpler but also in a way that maintains and does it in a fun way.

+ +

VICTORIA: That makes sense because my understanding of where to use AI and where to use machine learning for best purposes is to automate those, like, repetitive, boring tasks and allow people to focus on the creative and more interesting work, right?

+ +

ALA: Yes and no. The interesting bit about our approach to ML is that we don't actually use machine learning or ChatGPT for any of the intelligence layers, meaning we don't ask ChatGPT to generate Terraform or any kind of GPT model to analyze a certain aspect of the infrastructure. That is all deterministic and happens in the Klotho engine. That is the uniqueness of why this always works rather than if GPT happened to get it right.

+ +

What we use ML for is the ability to parse the intent. So we actually use it as a language model to parse the intent from what the user is trying to convey, meaning I want a lambda with an API gateway. What we get back from our use of ML is the user has asked for a lambda, an AWS lambda, and API gateway and that they be connected. That is the only thing we get back. And that is fed into the Klotho engine. And then, we do the intelligence to translate that to an actual architecture.

+ +

VICTORIA: That's a really cool way to use natural language processing to build cloud infrastructure.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: I'm curious; you said you're already working on some issues about being able to suggest improvements for cost reduction and efficiencies. What else is on your roadmap for what's coming up next?

+ +

AARON: So there's a bunch of things in the long-term roadmap. And I'll say that, like, in the short term, it's much more about just expanding the breadth of what we support. If you think about just generating all the different permutations and types of infrastructure, it's, like, a huge matrix problem. Like, there's many, many dimensions that you could go in. And if you add an extra cloud or you add an extra capability, it expands everything. So you can imagine, like, testing it to make sure things work, and everything becomes very complicated. So, really, a lot of what we're doing is still foundational and trying to just increase the breadth, make the intent processing more intelligent, make the other bits work.

+ +

And then one of the areas right now is for our initial release of the product; we chose to use Discord as our interface for the chatbot. And the reason for that is because it gives us a lot of benefits of having sort of the community built in and the engagement built in where we can actually talk with users and try and understand what they're doing.

+ +

However, we really have a lot of UI changes and expansions that we'd like to do. And even from some of our early demo material, we have things like being able to right-click and being able to configure your lambda directly from the UI. So there's a lot of areas there that we can expand into an intent, too, once we get sort of the foundational stuff done, as an example.

+ +

The intelligence bit is a much bigger process, like, there's a lot of things to unpack there. So I won't talk about it too much. But if we were to just talk about the most simple things, it'd be setting up alerts somehow and then feeding into our system that, like, we're hitting those alerts, and we have to make modifications. A good example of that would be, like, configuring auto scaling on an instance for [inaudible 22:17]. So we can get some of those benefits now. The bigger vision of what we want to do with optimization requires a lot more exploration and also the ability to look at what's happening to your application while it's running in the cloud.

+ +

ALA: Let me maybe shed a bit more light on the problems we're trying to solve and where we're headed. When it comes to optimization, to truly optimize a cloud application, you have to reason about it on the application level rather than on the one service level. To do that, we have to be able to look at the application as an application. And today, there's a multi-repo approach to building cloud applications.

+ +

So one of the future work that we're going to do is be able to reason about existing infrastructure-as-code from different portions of the teams or organization or even multiple services that the same team works and link them together. So, when we look at reasoning about an architecture, it is within the entire context of the application rather than just the smaller bits and pieces. That's one layer.

+ +

Another layer is being able to ingest the real runtime application metrics and infrastructure metrics, let's say, from AWS or Azure into the optimizer system to be able to not only say, oh well, I want low latency. Then this is hard-coded to use a Fargate instance instead of a lambda. But more realistically, being able to see what that means in lambda world and maybe increase the concurrency count.

+ +

Because we know that within the confines of cost limitations or constraints that the company wants to have, it is more feasible and cost-effective to raise the minimum concurrency rate of that lambda instead of using Fargate. You can only do that by having real-time data, or aggregated data come from the performance characteristics of the applications. And so that's another layer that we're going to be focusing on.

+ +

The third one is, just like Aaron said, being able to approach that editing experience and operational experience, not just through one system like InfraCopilot but also through a web UI, or an app, or even as an extension to other systems that want to integrate with Klotho's engine.

+ +

The last thing that I think is key is that we're still holding on to the vision that infrastructure should be invisible to most developers. Infrastructure definition is similar to how we approach assembly code. It's the bits and pieces. It's the underlying components, the CPUs, the storage. And as long as we're building microservices in that level of fidelity, of like, thinking about the wiring and how things interconnect, then we're not going to get the gains of 10x productivity building cloud applications. We have to enable developers and operators to work on a higher abstraction.

+ +

And so our end game, where we're headed, is still what we want to build with Klotho, which is the ability to write code and have it be translated into what's allowed in the infrastructure within the constraints of the underlying platforms that infrastructure or platform teams set for the rest of the organization. It can be one set or multiple sets, but it's still that type of developers develop, and the infrastructure teams set them up to be able to develop, and there's separation.

+ +

VICTORIA: Those are all really interesting problems to be solving. I also saw on your roadmap that you have published on Klotho that you're thinking of open-sourcing Klotho on GitHub.

+ +

AARON: So, at this point, we already have the core engine of Klotho open-sourced, so the same engine that's powering InfraCopilot and Klotho, the tool itself is open source today. So, if anyone wants to take a look, it is on github.com/klothoplatform/klotho.

+ +

VICTORIA: Super interesting. And it sounds like you mentioned you have a Discord. So that's where you're also getting feedback from developers on how to do this. And I think that challenge you mentioned about creating abstractions so that developers don't have to worry as much about the infrastructure and platform teams can just enable them to get their work done; I'm curious what you think is the biggest challenge with that. It seems like a problem that a lot of companies are trying to solve. So, what's the biggest challenge? And I think what do you think is unique about Klotho and solving that challenge?

+ +

AARON: I guess what I would say the biggest challenge today is that every company is different enough that they all saw this in a slightly different way. So it's like, right now, the tools that are available are the building blocks to make the solution but not the solution itself. So, like, every cloud team approaches it on, let's build our own platform. We're building our own platform that every one of our developers is going to use. In some cases, we're building, like, frameworks and SDKs that everyone's going to use. But then the problem is that you're effectively saying my company is entering the platform management business. And there's no way the economies of scale will make sense forever in that world. So I think that's the biggest issue.

+ +

And I think the reason it hasn't been solved is it's just a very hard problem. There's many approaches, but there's not a clear solution that kind of brings it all together. And I think our product is positioned better than most to solve some of the higher-level abstractions. It still doesn't solve the whole problem. There's still some things that are going to be tricky. But the idea is, if you can get to the point where you're using some of our abstractions, then you've guaranteed yourself portability into the future, like, your architecture will be able to evolve, even in technologies that don't exist yet once they become available.

+ +

ALA: To tack on to what Aaron said, a key difference, and to our knowledge, this doesn't exist in any other tool or technology, is a fundamentally new architecture we call adaptive architecture. It is not microservices. It is not monoliths. It's a superset that combines all the benefits from monoliths, microservices, and serverless if you consider it a different platform or paradigm. What that means is that you get the benefits without the drawbacks. And the reason we can do it is because of the compiler approach that we're taking, where everything in the architecture that we produce is interchangeable.

+ +

The team has decided to use Kubernetes, a specific version of Kubernetes with Istio. That works great. And, a year later, it turns out that that choice no longer scales well for the use. And we need to use Linkerd. The problem in today's world and what companies have to do is retrofit everything and not only the technology itself, but it's the ripple effects of changing it into everything else that all the other choices that were made that depended on it.

+ +

In the Klotho world, because of the compilation step or the compilation approach and its extensibility, you could say, I want to take out Istio and replace it with Linkerd. And it would percolate all the changes that need to happen everywhere for that to maintain its semantic behavior. To our knowledge, that doesn't exist anywhere today.

+ +

VICTORIA: So it would do, maybe not, like, would do migrations for you as well?

+ +

ALA: I think migrations are a special case. When it comes to stateless things, yes. When it comes to data, we are much more conservative. Again, bringing what we've learned in different companies in, a lot of solutions try to solve all the things versus we're trying to play in a very specific niche, which is the adaptive architecture of it all.

+ +

But if you want to move data, there's fantastic tools for it, and we will guide you through getting the access to the actual underlying services and, say, great, write a migration system, or we can generate for you. But you will run it to move the data from, let's say, Postgres to MySQL or from being able to drain a unit on Kubernetes to a lambda. Some of those things are much more automatic. And the transition happened through the underlying technologies like Terraform or Pulumi. Others will require you to take a step, not because we can't do it for you but we want to be conservative with the choices.

+ +

AARON: I would also add that another aspect of this is that we don't position ourselves as being the center of the universe for these teams. Like a lot of products, you kind of have to adopt the platform, and everything has to plug into it, and if you don't adhere, it doesn't work.

+ +

We're trying very, very hard with our design to make it so that existing apps will continue to function like they've always functioned. If app developers want to continue using direct SDKs and managing config themselves, they can absolutely do that. And then they'll interact well with Klotho apps that are also in that same company. So we're trying to make it so that you can adopt incrementally without having to go all in.

+ +

VICTORIA: So that makes a lot of sense. So it's really helpful if you're trying to swap out those stateless parts of your infrastructure and you want to make some changes there. And then, if you were going to do a data migration, it would help you and guide you to where additional tools might be needed to do that. And at your market segment, you're really focusing on having it be an additional tool, as opposed to, like, an all-encompassing platform. Did I get it all right?

+ +

[crosstalk 31:07]

+ +

ALA: Exactly.

+ +

VICTORIA: [laughs] Cool. All right. Well, that's exciting. That's a lot of cool things that you all are working on. I'm curious how overall the workload is for you two. How big of a team do you have so far? How are you balancing out this work of creating something new and exciting that has such a broad potential scope?

+ +

AARON: Yeah. So, right now, the team is currently six people. So it's Ala and I, plus four additional engineers is the current team. And in terms of, like, where we're focusing, the real answer is that it's somewhat reactive, and it's very fast. So, like, it could be, like...in fact, Copilot went from ideation to us acting on it extremely quickly. And it wasn't even in the pipeline before that. So I'd actually say the biggest challenge has been where do we sort of focus our energy to get the best results? And a lot of where we spend our time is sort of meta-process of, like, making sure we're investing in the right things.

+ +

ALA: And I think that comes from both Aaron and I have been in the industry for over 15 years. We don't, you know, drop everything and now switch to something new. We're very both tactical and strategic with the pace and when we pivot. But the idea is when we decide to change and focus on something that we think will be higher value, and it's almost always rooted in the signals and hypotheses that we set out to kind of learn from, from every iteration that we go after.

+ +

We are not the type that would say, "Oh, we saw this. Let's drop everything, and let's go do it." I think we've seen enough in the industry that there's a measure of knowing when to switch, and when to refocus, and what to do when these higher tidbits come, and then being able to execute aggressively when that choice or decision happens.

+ +

VICTORIA: Are there any trends that you're watching right now that the outcome would influence a change in direction for you?

+ +

ALA: Not technically. I think what we're seeing in the industry is there's no real approaches to solving the problem. I would say most of the solutions and trends that we're seeing are...I call them streamlined complexity. We choose a set of technologies, and we make that easy. We make the SaaS version, and it can do these workloads, and it makes that easy. But the minute you step out of the comfort zone of those tools, you're back into the nightmare that building distributed systems brings with it, and then you're back to, you know, square one.

+ +

What we're trying to do is fundamentally solve the problem. And we haven't seen many at least make a lot of headway there. We are seeing a few of the startups that are starting to think in the same vein, which is the zeitgeist. And that's fantastic. We actually work with them closely to try and broaden the category.

+ +

VICTORIA: Right. Do you feel that other companies who are working in a similar problem space that there is...is it competitive between each other? Or do you think it's actually more collaborative?

+ +

ALA: It depends on the companies and what they're trying to achieve. Every set of companies have different incentives. So Google, Amazon, and Microsoft have, you know, are incentivized to keep you on their clouds. They may care less about what they have in there as long as you are happy to stay. So you'll see more open source being adopted. You will see Amazon trying to copy or operationalize a lot of open-source tools. Microsoft will give their...because they are working with larger companies to have more vertical solutions. Google is trying to catch up.

+ +

If you look at startups, you will see some focus more on developers. You'll see others focus on infra team. So it really depends on the intersection of the companies, and then they either collaborate or they compete, depending on how it affects their strategy.

+ +

In our case, we recognize that our competition is the incumbents and the current way of doing things. And so we are happy to collaborate with all the startups that are doing something in the vicinity of what we're doing, startups like Ampt, and Encore, and Winglang. And there's several others. We have our own Slack channel where we talk about, like, where we're headed or at least what we can do to support one another.

+ +

VICTORIA: Great. And I wonder if that's part of your business decision to open source your product as well or if there are other factors involved.

+ +

ALA: I think the biggest factor that we've seen, realistically, is the expectation in the developer community to have a core that is open source, not even the source available model but to have an open-source core that they can rely on always existing and referencing when, you know if the company disappears or Oracle buys them. And so I would say that that was the biggest determining factor in the end to open-sourcing the Klotho engine. It's a very pragmatic view.

+ +

VICTORIA: That makes sense. Well, I wanted to make sure we had time to ask one of my favorite questions that I ask on the podcast, and you can both answer. But if you could go back in time to when you first started this project, what advice would you give yourself?

+ +

ALA: I guess the advice that I would give is keep selling and start selling as early as you can, even before the vision is realized. Or let's say you're making kind of headway towards what you'll wind up sharing and giving companies, the lead time to creating the opportunities and the belief and the faith that you can solve problems for companies, and the entire machinery of doing that is a lot more complex than most founders, I think, or at least first-time founders or, honestly, myself have found it to be.

+ +

AARON: Yeah. If I try and answer that same question, it's very challenging. I guess my perspective now is there's nothing I could tell myself that would make me go any faster because a lot of it really is the journey. Like, the amount of stuff that we've learned in the last year of working on this and exploring and talking with people and everything else has been so vast that there's nothing I can communicate to past me that would prepare me any better. So [laughs] I think I would try just my best to be encouraging to just stick with it.

+ +

VICTORIA: Well, that's good. And who knows what you're going to learn in the next year that [laughs] probably might not help you in the past either? That's wonderful. Do you have any final takeaways for our listeners today or anything you'd like to promote?

+ +

ALA: So, from my lens, I've always wanted to do a startup but felt that the life setting wasn't quite ready. And a lot of the startup culture is talking about younger, earlier founders. I think having had the industry experience and understanding both the organizational and technical challenges, knowing more people, and engineers, and founders, potential founders, has been vastly more helpful than what I would have been able to pull off ten years ago. So, if you are thinking maybe it's too late, it is not. It's probably easier in some regards now. And yeah, check out InfraCopilot. It's on infracopilot.io. We would love to have you try it out and go on this journey with us.

+ +

AARON: Yeah, I would definitely echo that. I mean, sort of the same thing on the journey. Like, it's never too late to start. And yeah, like, I would say being in the industry and actually seeing these problems first-hand makes it so much more fulfilling to actually try and solve them.

+ +

VICTORIA: That's [inaudible 38:15]. I'm excited to see what you all accomplish. And I appreciate you coming on the show.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg or on Mastodon @vguido@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Aaron Torres and Ala Shiban.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ZdLCUUch + + ]]> + + Victoria Guido + Aaron Torres + Ala Shiban + + + 479: Wistia with Brendan Schwartz + https://podcast.thoughtbot.com/479 + 3c1e2c86-1e69-40e7-95c5-762818de9754 + Thu, 15 Jun 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Brendan Schwartz is the Co-Founder and CTO of Wistia, software that makes it easy to find, engage, and grow your audience with video. + +Victoria talks to Brendan about the latest updates on the platform, interesting problems he found that Wistia was able to remove and help his team get to speed and velocity, and the personal value that drives his decision-making. + 38:45 + no + + + Brendan Schwartz is the Co-Founder and CTO of Wistia, software that makes it easy to find, engage, and grow your audience with video. +Victoria talks to Brendan about the latest updates on the platform, interesting problems he found that Wistia was able to remove and help his team get to speed and velocity, and the personal value that drives his decision-making. +Wista (https://wistia.com/) +Follow Wistia on Twitter (https://twitter.com/wistia) or LinkedIn (https://www.linkedin.com/company/wistia/). +Follow Brendan Schwartz on LinkedIn (https://www.linkedin.com/in/brendanschwartz/), Twitter (https://twitter.com/brendan), or visit his website (https://brendanschwartz.com/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Brendan Schwartz, Co-Founder and CTO of Wistia, software that makes it easy to find, engage, and grow your audience with video. Brendan, thank you for joining us. +BRENDAN: Thanks so much for having me. +VICTORIA: And I believe this will be your third time, at least, on the Giant Robots Podcast, right? +BRENDAN: Yes, I think this is my third appearance. Thank you for having me back. +VICTORIA: Yes. +BRENDAN: Is there anything I receive? What is it when you host SNL in a [crosstalk 00:39]. +VICTORIA: You get a jacket. +BRENDAN: A jacket, yeah. +VICTORIA: Yeah, we should. +BRENDAN: [laughs] +VICTORIA: We should do a Giant Robots jacket or something from returned guests. I love it. So it's been great to follow along your journey here. So, for those who don't know, like, what is Wistia? And I'll say, just a precursor, that thoughtbot is a client of Wistia. So we use it ourselves. But why don't you just give us a little bit about what is the product and what makes it different? +BRENDAN: Sure. And thank you so much for being a customer all these years. You kind of hit it at the top, but we help businesses of all sizes thrive with video. And so we serve mostly marketers. To dive a little bit into the history of the business, we'll be around seven...is that right? 17 years. It sounds like a long time when I say it out loud, [laughs] 17 years this June. And, for most of our history, we were, I'd say, a video-hosting platform for marketers. So if you want to put video on your website, track who's watching it, how they're watching it, and integrate that data with your other marketing systems, that was our focus and what we did. +And over, I'd say, the past two years, we've brought in that focus to help businesses with all aspects of their video marketing from creating video...We recently introduced a live video product for webinars and for live events last fall. We just launched last week, which I'm very excited about native video recording in the Wistia platform. So you can record your webcam and your screen. And there's also a very simple video editor in the platform, which has been really powerful for folks to make small adjustments to content or to atomize content, take out highlights or sections of things, and to be able to publish them to their audiences. +VICTORIA: Thank you for providing that context. And I'm curious if there were any, like, environmental or market forces that pushed you in that direction with the latest updates on the platform. +BRENDAN: So, like I mentioned, we...in a large part, our success came (We're a relatively small team.) it came from being focused. And so for, you know, that decade or more, there were a lot of things that we had heard from the market or from customers. Like, live video was an obvious one we had been asked for a really long time. When will Wistia do live? When will Wistia do live? And, you know, our approach to that is we want to be really good and excellent at the things that we do and be focused. And I think that has served us well over the time that we've existed. +And some of that came out of; I'd say, the really early days of the company where...it's funny, [laughs] we've always built Wistia, you know, sometimes we say in the shadow of YouTube, so YouTube and seeing YouTube. My co-founder was the first person who showed me YouTube in 2005, I think it was, and that was part of the inspiration to start Wistia. We are both really into video. And we saw that and having video be more accessible on the web, we knew was something that was going to change the world. +There was a question...this sounds kind of dated nowadays to say, but there was a question if you were starting a business, you know, let’s say, in 2006 or 2007 or '8, right? What are you going to do when Google enters your space? [laughs] It was a funny one for us to answer because we said...well, I forgot when YouTube was bought by Google. It was maybe in 2006 or something like that. Like, Google is already in our space, and it's free. So that was always an interesting challenge. +And the way that we were successful there [laughs]...obviously, YouTube is at a much larger scale [laughs] and level of success than Wistia is. But to the extent we have a business at all against a very well-known and free competitor from those early days, it was being really focused on our customers and keeping the product footprint fairly small. +Our business changed a lot during the pandemic. There were some obvious things, right? Video was used a lot more. So existing customers had a lot more usage. We saw an influx of customers, people who maybe were late to adopt video in their organization, and then that became a much obvious way that people could reach their audiences and grow. So that was something of a tailwind for us. +And then it also forced us to kind of take a step back and look at the market in general with clear eyes. It was a funny moment, I think, for me and my co-founder because in the years leading up to that, you know, it had been like 12,13 years of doing Wistia, and it felt like we had solved a lot of problems in the product. We were still building new things, but they were for the most mature part of our audience or the most advanced marketers, which was pretty fun. But it felt like a lot of the problems had been solved. We were always, like, is the product done? Is the product complete? +And when we took a step back and looked at the market, what we had found was that we had kind of just, like, got ourselves into this, you know, more mature corner of the market. But in a large part, because of COVID, so many businesses, existing and new businesses, were very new to video and were using video in new ways. And people who had been using video, their solutions to do that were super fragmented. +You'd have one product that is providing...[laughs] You might have a different product you're using for internal meetings, video meetings, and that's different than a live event product, that's different than a webinar product, that's different than where you might publish your videos or host your videos, which is different than how you'd, like, analyze your performance. +And as video became more important to organizations, that fragmentation of the solutions was something that was super painful. And we had heard from a lot of people who were Wistia customers and people who were not...having this as an all-in-one platform was something that they really desired, which I was also kind of, you know, we were, like, cynical about a little bit, right? +Because if [laughs] you're in the world of product, it's like you can ask, you know, if you had a magic wand, what would you want? And someone says, "Oh, I want it all in one. And if you could just do everything for me, that would be so great." You know, it's hard to say, is that what people really want? And what gave us more confidence at that was, correct, is when we started digging into some of the details and hearing about existing workflows that existed that marketers have to deal with, including ourselves. We do a lot of content marketing. +A lot of the really interesting things you could do in a product that is all in one it opens up new opportunities. And you could just imagine...you've hosted a webinar before. Almost always, it's the best practice that you host a webinar; after you're finished, you probably have a good marketing asset there. You should publish it to your website. You usually need to do some light editing. Maybe you're going to take off the Q&A before you publish it. And you put it on your website. +And then, a while later, you're like, was this effective? Did it work? And then you have to, you know, probably have a spreadsheet somewhere. You have to go into the tool used to host the webinar to figure out who was watching it and [laughs] who registered. Did they attend? And then where's the data for how it performed on your website? How many people watched it? Did you get subscribers if you were, you know, had an email gate on that content? It's cumbersome, and it's a mess. +And then, you know, the most motivated people who are well-resourced have the time to do that and analyze the performance. But then a lot of marketers who are on smaller teams they just don't have time to do that, which means a lot of content gets under-utilized or under-marketed. So a lot of evidence and motivation to change what we were doing and expand the product footprint. So that had us make a big investment in our product design and engineering teams, and we almost...we doubled them in about 18 months. And then that kind of set us on this journey that we started maybe two years ago to greatly expand what we're doing. +VICTORIA: Well, that's great. So just to play that back, staying close and focused on your customers almost had you to a point of being stable with your product until COVID happened. And you have this increased demand for video that opened it up to almost have Wistia be like a startup again and create a whole new feature branch, right? +BRENDAN: Yeah, that's exactly right. And that was really fun and motivating. I mean, we...that early-stage energy and not having all the answers to things where stuff is a little bit, you know, less-researched, and it's faster paced is something that I really like. That was a big shift for the company. So there was some, I don't know, I think we had some self-doubt a little bit if I'm honest, of, you know, when you've been so focused for so long. Like, can we do this? +Like, will we be able to create something really good with this expanded footprint, and what resources that take? And is it going to take shifting the culture and mindset of the team, like, in ourselves? But, I don't know, that's kind of why I started the [laughs] business in the first, like, the adventure and not knowing what's next is very appealing. So that's been the fun part of it. +VICTORIA: And how did you go about shifting that mindset? Or even what was the moment where you realized that you needed to go after this shift? And how did you start lobbying everyone around you to get on board? +BRENDAN: A lot of those customer interviews and market interviews, we worked with an outside firm. We worked with Boston Consulting Group, who was a really great partner. We have obviously worked with folks outside. We hadn't worked with somebody; I'd say, at that scale in terms of kind of, like, tie-in with our company strategy today. But that was really helpful to have a partner, especially to push us. We got to something different than we had been doing, I mean, not dramatically so. But it was expanding what we were doing. +So that was really helpful. It helped...that put some structure around it to what we had, and the whole company knew this was happening and was along for the ride. So I'd say the communication and getting to a clear strategy was something we did pretty well, and telling that story internally. I'd say where we didn't do as well [laughs] and were maybe late to make some decisions is how the culture would need to change to support that strategy. +Again, like I said, we've doubled the product design and engineering teams. That is now feeling in a pretty good spot, but that was a lot of growth for us. And was, I'd say, pretty messy along the way. So the beginning, I'd say, was clear, and I think communicated well. And then I feel like in the middle it was, I don't know, a big mess where we got maybe a year in, and we're like, wow, we have this new strategy, but we really haven't executed much on it. +Some of these things we're building are taking a lot longer than we thought. Our velocity doesn't feel great. Like, maybe we didn't plan some of this stuff out. Like, we've hired a lot of people, but, like, are they productive yet? And so, yeah, I think we were in a pretty [laughs] tough spot maybe last summer. We were a year into this strategic shift, but it didn't feel like we were really moving against it as much as we had hoped. +VICTORIA: It makes sense that it would take some time to change strategic direction and then get to that high-velocity point that you would expect. Were there other blockers that you found you were able to remove to get the team back up to that high velocity on delivering features for clients? +BRENDAN: [laughs] Well, it's funny that you say that. I wish; I mean, that is pretty obvious, I think, and obvious in retrospect. But, for some reason, when you're in this, or when we were in this, you're impatient, and you want it faster. And I think probably [laughs] having some clear expectations would have made the ride a little smoother along the way for this. I feel like I have to remind myself of this pretty frequently. +I mean, Wistia is not big. We're 180 people or so but certainly bigger than...I can think back to various other sizes. Doing that strategic shift it takes time for leadership, let's say, or me to shift my mindset about some of those things. And then once you've changed your mind, you kind of... it's easy, or at least for me, to discount the time it took and all the information it took to lead to that, which needs to cascade through an organization. And so that's where some of that impatience...or just the piece you said about, yeah, it makes sense that this would take time. I was like -- +VICTORIA: [laughs] [inaudible 11:56] +BRENDAN: [laughter] You're like, once you've got it, you're like, wow, this is so exciting. Let's go. Let's go. And everybody is like, what are you talking about? +VICTORIA: Yeah. My background has been in, like, Federal IT consulting. So you're used to kind of the pace of things being a little slower. And I think people forget that as an organization gets to any amount of size, that kind of bureaucracy tends to creep in. And, like you're saying, the information just needs to cascade down throughout everybody. I think my original question was, were there any blockers or interesting problems you found that you were able to remove and help your team get to that speed or velocity you really wanted? +BRENDAN: Yeah, there were a lot. I think most of them and most of the hardest ones to move centered around cultural change, and they weren't necessarily so clear at the onset. And so, you know, one thing that kind of partway into the strategy change that became clear is, and you had said it, it's like going from, you know, basically thinking of ourselves as being in a late stage or more mature market to being in an early-stage environment. And the type of culture that, you know, succeeds in those worlds is different. +One thing that we've learned along the way at Wistia that we have employed and I think been successful with is this concept that when you update your strategy as a company, you should be thoughtful and, like, make conscious updates to your culture and values. And so much is that...so you're saying culture is the way that you work. You want that to be in support of strategy. And I remember when I first heard this concept, and we were earlier into our journey. I was like, what is this, like, corporate nonsense? Culture is just this, like, intangible, you know, it's this sum of how everyone works. And it's, like, this beautiful symphony of values. [laughs] +It was a more kind of, like, idealistic [laughs] view of it or more organic view of it, which I think is reasonable. But you can also be intentional about your culture. So when we wrestled with that the first time...this was many years ago when we updated. I forgot even what the strategic changes at the time. But we updated our values, and we set about making a conscious cultural change. So when we changed the strategy this time, we did the same thing. I'd say we were a little bit late doing it, like, getting to it. But we did do it. +And so some of that was there were certain things...so, for instance, being so focused. We had a really lean team. And we were optimizing for things like predictability of outcomes and needing to be correct. So, for instance, if you're only going to make...let's just, like, say, on the product side. Like, if you're only going to be able to ship or do, you know, a few big improvements to the product per year, like, you're well served to kind of go slowly and make sure those have a reasonable chance of success. This was, like, the culture and the mode that we were in. +That doesn't really work very well when you're in an early-stage environment where things are pretty unpredictable and things are moving really quickly. So that was an example of something that we kind of identified, and we're like, we're going to need to change this. So it was this shift from teams feeling the need to be correct and really well-researched about something to moving towards; I'd say, you need to talk to a lot of customers to build customer intuition in order to make decisions faster. +But that shouldn't be the case that; for every product decision you need to make, you have to talk to 5 or 10 customers to validate that. You should be able to build an intuition to be able to make those decisions faster, and we should be more tolerant of failure. And so, we should work in a more incremental style. I mean, some of this is, like, super familiar to anybody [laughs] listening to this, right? It's like a more agile style. So work more incrementally, like, work incrementally towards great as opposed to, you know, this big thing that's going to be super polished and correct from the jump. +VICTORIA: I think that's really interesting. And it's not necessarily wrong to be so thorough in your changes when you're in that steady state, and you, like, know what clients you have, and you have a pretty well-defined product. But it's interesting that it took quite a bit of effort, it sounds like, to shift back into a flow state where you're incrementally doing changes very frequently to get that new product and find those new customers that you're targeting. +BRENDAN: And it continues to be. We've made a lot of progress on this. And maybe it's helpful...I don't know if it's helpful to folks listening to dive into some of the details of how we went about making those changes. It's still really difficult, right? There's a lot of things in tension. +So I'd say in our previous mode, one thing we were pretty good about is when something was released, it was well-tested. It was high quality. It was, like, well-communicated. Throughout the org, people knew what was coming. Obviously, there were hiccups with that, but, like, that's the side of the spectrum that we were on there. +And then in this mode where we're building faster and more incrementally, we have a lot of internal tension in terms of quality, like, is this good enough? Is this first version good enough? Are we going to make a bad first impression? And so, obviously, you do this for a...it's a set of trade-offs, right? There's no free lunch, but that is still very much we're trying to find the right balance. +VICTORIA: Right. So, like, in your role as CTO, how do you make people feel comfortable failing [laughs] [inaudible 17:06] describing. +BRENDAN: Some of this cultural change, I think, it's been interesting to go through because some of the properties of how we had been working are, you know, things that are part of the way I like to work. Like, it makes me uncomfortable to release something that you know the flaws in it. And that's an old kind of startup advice that I think is generally right. Like, if you release something and it doesn't make you a little bit uncomfortable, you have waited too long. [laughs] Advice is very easy and abstract. It's hard to apply. Like, there's a huge spectrum there of, like, how uncomfortable [laughs] you want to be. +But I will say that that's been something that's been, yeah, hard to reconcile with. And I guess that the piece that I'm able to do in my role is, like, remind folks where we're headed, right? So the first version can be a bit rough. What matters is what happens after that. So, if we're quick to listen to customers, to fix those things, to correct that, and people can see that momentum, I think that matters for a lot. And I think that's, like, something...I've been telling that story repeatedly. +Internally, I've had other leaders, and that's what we've really been leaning on is, like, we've adjusted how we're delivering customer value. And that we're going to push things out that might be a little bit more raw, but where we ultimately are going to get them to and get them to quickly is something that we're really proud of. So that has helped. And then, I'd say we still haven't figured out, which is, again, like, in these smaller increments, things can be a failure, and that's okay as long as we learn something and correct and move forward. +And one thing that's been a little bit tricky to recognize, too, is there's some places where you have some experiment, and you're not actually sure if there's a market or if there's a need for a feature. So you might do something, and it really doesn't land well. And then you learn something about the market or the customer base and say, okay, that isn't what people needed. +But, in a lot of places that we're building product, like, let's say, take live video, for example. [laughs] When we launch a live video product, it may be a failure. Like, the first version may not be completely right or may be a failure. But the customer need for [laughs] a live video for a webinar exists, right? So that's not the type of failure that you go, oh, I guess there's not [laughs] a market there. Or, it's like, you go back and say, okay, how do we need to improve this to make it work? +I don't think we have the right language internally around that. You know, there are certain areas where it's like a failure, and then it's like, okay, we've learned not to do that again. And there's other areas where it's like, we're going to keep...[laughs] not we're going to keep failing. I mean, there are goals to succeed, right? But we're going to keep improving this until we get it to work because we know there is a market here, and there is a customer need. +VICTORIA: Making a culture where it's acceptable to run experiments [chuckles] and as long as you're learning from the failures. And honestly, it sounds like you all are very connected to your customer. Like, you're talking to them regularly. You're testing out features with them and getting that feedback. And that sounds like that's really what you want to focus on and want your whole team to focus on. +BRENDAN: Yes, yeah, exactly. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: You mentioned a little bit about your values. So, what would you say is, like, your most important personal value that drives your decision-making at Wistia? +BRENDAN: So, like I mentioned, we've changed our values over time when we've changed strategy. And we think of our values as a decision-making framework, not as a set of things that we value. For instance, if you go on our website on wistia.com, I think about/values, about/company. It's somewhere. And you can see our values. It's not a list of everything that Wistia values or even the things that we value the most. +For example, Wistia has, like, creativity is something that I value a lot that is very built into Wistia's culture that we value a lot, but it's not a listed value. It used to be at one point, and then we found that as a decision-making tool, it wasn't very helpful. [laughs] If you're faced with a decision, and you say, okay, one of the values is creativity, how do I make this more creative, right? +VICTORIA: [laughs] +BRENDAN: That's not usually the question you want to ask. So we have, over the years, shifted towards the values are a decision-making framework. And I'd say the one value that has stood the test of time in there is simplicity, which is not unique to Wistia, but it's something that I care a lot about personally. It's served us well as a business. +It's almost always harder to get to a simple solution or answer than it is to get to a complex one. It takes a lot of failure. Sometimes there isn't a simple solution, but I think it's always worth the pursuit of trying to find one. And that's served us well in keeping a focused and easy-to-use product. I think that's fairly self-evident [laughs] why that matters to customers. And it's something that I think it's hard to do as you grow, and add, and get bigger. And it's an important feature of the product. And it's an important feature of, I don't know, companies' internal policies or the employee experience. +The simpler something is, it's easier to understand. I think the more someone who works inside your company can wrap their arms around more of that context or, you know, more of the product, more of the all the ins and outs of how it is to work there, the better informed they'll be, the better faster they'll be able to make decisions, and the better work they'll be able to do. So, yeah, simplicity, minimalism, those are things I think that have served us well over the years. +VICTORIA: Oh, I appreciate that. I could see how that could apply to how you're writing your code, or how you're designing a feature, or even your pricing structure. +BRENDAN: Yeah, and I don't think...we definitely don't always get it right. So, you know, all of this is aspirational, but I think it's the right thing to aspire to. +VICTORIA: Right. Oh, I'm familiar. [laughter] It's like that, I mean, the Marie Kondo, like, keeping it simple and organized. It's definitely aspirational [laughter] in my personal life as well. But that makes sense. Okay, I have a fun one for you. What is your favorite viral video style that you think people should do more of on Wistia? [laughs] +BRENDAN: Oh, whoa. That's a hot-button one. [laughs] I think we have long said...this, like, feels like it takes me back to when we first started Wistia. The term viral and viral video was a new thing for the internet, I guess because video on the internet was still fairly new. I've always been on the side of this, like, hardworking video. And most of our customers are B2B businesses, so these are, like, marketing teams at B2B companies. +I'm sure a lot of people who are listening to this have seen some very cringeworthy, you know, attempts at a viral video made by various corporations. Those usually don't land well. There are some people out there maybe that can crack this and make something that is viral through some art and science, but most everybody else cannot. +VICTORIA: [laughs] +BRENDAN: It's like, not something that can be kind of, like, bottled and captured. So we've always been on the side of, like, be authentic, be yourself, make these harder-working videos. But -- +VICTORIA: I think that's generally good advice for businesses that was, like, maybe don't try to just do viral trends...[laughs] Like, make your own authentic content. But you personally now, like, yeah, if you were going to do whatever the latest TikTok trend is, which one would you pick? +BRENDAN: You know, okay, maybe here's one. So we have always been, as I described it, on the side of, like, do not do this. It is, like, almost always going to be cringe-worthy. But do you remember...I don't know what year this is from, the Harlem Shake. It was mostly kind of a business trend, right? You'd play this track, the Harlem Shake, and have, like, when the beat dropped, it would go from normal office to everyone dancing in a costume. +VICTORIA: Oh, that's fun. +BRENDAN: So it was, like, a fun trend. But it was...we were and still are, I'd say, fairly, like, anti-trend. I don't know what, you know, like, contrarian when it comes to marketing trends or things like that. But then, when this happened, we were like, this will be really funny. We should set a calendar reminder to do this, like, ten years in the future. +Actually, the last onsite that we had; unfortunately, it was the last day. Our head of production [laughs] who, like, we kind of had this, like, running joke of he randomly saw a news article. I think that it was the 10-year anniversary of the Harlem Shake [laughs] or whatever. He's like, oh, this would be...this is the perfect time to do this, now that it's so, so, so out of vogue. But, you know, people, like, maybe have fond memories of it. And now this is so out of fashion. I think it could be funny to do it. [laughs] +VICTORIA: Yeah, right. You don't want to do it just because it's the trend. But if it fits your personality and your business, then I think it would make sense. +BRENDAN: Yeah. +VICTORIA: I've heard that there might be a Wes Anderson style. [laughs] And I wanted to do a Wes Anderson goes to RailsConf video, but I'm actually meeting this -- +BRENDAN: Did you do it? +VICTORIA: I didn't do it. I'm not actually good enough. I think tomorrow I'm meeting with the Wistia customer success team. [laughs] I'm going to ask them to help me. +BRENDAN: Oh yes, we'll help you. +VICTORIA: Yes. +BRENDAN: I do like...that trend is nice. That feels like a; I don't know, like, less aggressive. I've seen a lot of those, and they don't feel, I don't know, cringeworthy to me because maybe it's a nice shell in which to put some personality and content, as opposed to -- +VICTORIA: Just being goofy or whatever, yeah. [laughs] +BRENDAN: Yeah, I don't know exactly how to describe it. But I think that one works better. Yeah, someone at Wistia did that the other day in the office, and people enjoyed it a lot. That was more for, like, internal consumption. But those ones are nice. +VICTORIA: Yeah. Well, I like the idea of bringing some of these editing tools to marketing teams where they can maybe not create viral videos all the time but do a lot of very highly editing and having it all in one place as well. Like you mentioned, I do run webinars, [laughs] and I'm familiar with the bouncing around between different tools to get everything to work. And there's even sometimes, like, security issues with different types of video-hosting tools. So I think there's a lot to offer for a marketing team who may not have as many resources to do the individual pieces. +BRENDAN: Yeah, that's a story we've heard, yeah, from a lot of customers. And we have a lot of video resources internally because we're a video company, and we invest a lot in that. But even so, yeah, if you talk to folks on our marketing team, they'd say it's hard to get those resources, especially if you have something small that you want to do. +I think it's always better if the person who has the need can easily do the thing themselves, right? More and better work gets done that way versus if it's, like, this chain of having to, like, ask other people because then you're like, should I really ask? It's like, do I want to, you know, spend social capital or budget on this thing? Will it work, will it not? But you can be, I think, faster and also experiment more when you have those tools available to you. +VICTORIA: Yeah, no, that makes sense. Because I don't know if it's worth [laughs] me spending my team's time to make this Wes Anderson video, but I want to do it for fun. So we'll see if I can do it at RubyKaigi next week. +BRENDAN: You should. That's great. That's, like, the perfect example of it because I feel like, yeah, well, maybe not. You might be sheepish to be like, yeah, I'm going to spend, like, ten grand with this, like, contractor to make this Wes Anderson...and to be like, what do you...what? What are you doing? +VICTORIA: [laughs] That makes sense. +BRENDAN: But if you do it, I think, you know, it's very likely it'll be really well-received, and you'll learn something about your audience. And then that could, like, blossom into, you know, a whole bunch of other things. I feel like that's been the case for us in our content marketing. We've long said, and this is, like, much more commonplace now, but one of the advantages of having a video producer in-house, like, is exactly that you now are employing someone full-time. +And so you've, you know, like, maybe knocked off, like, the major pieces of content that a business would make with video, some of the obvious things. But then it's exactly what you're talking about that, oh, we could take a risk, and we could try this. And that's where you learn and figure out new things and things that are different than your competitors might be doing or more creative approaches. +VICTORIA: Oh, That's great. You know, something I like to ask everybody who comes on the show, and it will be super interesting since you've been on a few times before, but if you could go back in time to your younger self when you first started Wistia, what advice would you give yourself? +BRENDAN: Patient...One funny thing of when we started Wistia, we had really unrealistic expectations. I don't think that's [laughs] unique when starting a business when you're young. But yeah, I was 22 or 23, as was my co-founder, Chris. And we really honestly thought—this is, like, this is cringeworthy to say—that we would either be really successful and, in six months, build this great business and sell it to Facebook or now Meta, right? But that was, like, a hot company at the time. +So we'd be wildly successful and sell to Facebook in six months, or we would fail in obscurity. That was, like, our honest-to-goodness business plan, which is so naive. [laughs] And here we are, you know, 17 years later and having a wonderful time. So I guess I would say, I mean, it's the most cliché advice, and you're young, and you never listen to stuff like this, but it's, like, enjoy the journey. +[laughter] +Things haven't always been easy. And there are, you know, hard challenges and, like, times filled with self-doubt. But even in those moments, if you have support from people around you, if you can learn to enjoy the growth and the journey, that is what keeps you motivated to do something for a long period of time. And usually, you know, people who stay focused on something for a long period of time you figure it out and can be successful. This sounds like the most generic advice as I say this out loud. +VICTORIA: [laughs] +BRENDAN: It really is. Enjoy the journey. [laughs] +VICTORIA: Enjoy the journey. But I think that's common. And even actually talking with Chad a few weeks ago and interviewing him about thoughtbot, is his younger self would tell him to have more fun [laughs] during the whole process and really enjoy it. And I think it's also interesting that you had either the most optimistic and the most [laughs] pessimistic as options and, like, nothing in between [laughter] that you expected would happen. +Which is funny because I have people ask me, like, is there still money in building apps and building new products? And it's like, yeah, like, it feels like there's these big people in the space, and they're doing everything you could think of possible. But there's still niche market that you can pursue [laughs], right? And there is still the ways that you can differentiate yourself as a product. +BRENDAN: Yeah, I think that's exactly right. What advice would you give to your younger self? +VICTORIA: Oh, me? I think, you know, probably something similar. Like, I feel like all of the times in my life where I've been, like, what am I going to do next and been really stressed out about it, within, like, three to six months, I found a new job, or I found something better where life improved a hundred-fold. [laughter]. So I think that's something even now I like to keep in mind is, like, if things turned down badly, like; usually, things turn around in a few months after that, [laughs] and a lot of times for the better. And that's, you know, true with, like, moving to California across the country from DC a few years ago. And yeah, a few other points like that. +I think the other part I think about is who I might have invested more time in and who I would have invested less time in. And like what you were saying, like, having the support of people around you, and finding the people who really have your back and support you, and, for people who don't, maybe letting go a little sooner. [laughs] +BRENDAN: Oh, interesting. Yeah, that's good advice. Yeah, I feel like both of those things are things I should probably remind myself of more frequently. [laughs] +VICTORIA: Right? And have more fun, which means...there's another quote I heard that's, like, when people travel back in time, they're worried about changing a small thing that will affect the future. But people don't think that they can make small changes now that will affect their future big time. +BRENDAN: Oh, that's a good one. I haven't heard that. But that's a good one. +VICTORIA: Well, super cool. Just to kind of really summarize or go back to some things we mentioned already about video, just how important do you think video really is to marketing in the current landscape for businesses? +BRENDAN: I mean, [laughs] I'm a very biased party, but I think it is becoming increasingly more important. I think it is the default way a lot of people want to consume information. This is a whole other tip that we didn't talk about with what's happening in the world of generative AI. And I'm sure a lot of people listening to this have voice cloning and how good those things have been getting. +I think it's going to make the value of authentic connections in video much more important in the short and medium term. And there's some challenging questions about how do you tell what's real in an environment where we've gone past the uncanny valley in terms of generating, you know, an avatar of me or you with the perfect voice clone? But I think people are going to rely a lot on video to break through. +VICTORIA: Yeah, that makes a lot of sense. It's going to be just more video world [laughs] as it goes. What does success look like for Wistia six months from now and even five years from now, the longer term? +BRENDAN: I think for six months from now, so there's a lot of new areas of the product that we've added. And, in the next six months, we should be able to make pretty substantial progress to have those parts of the product have really solid adoption and repeated usage by customers. I think that's what success looks like, which we're seeing it now for our editors, probably the farthest along, that it has really good adoption among the customer base, and repeat usage, which I think is, like, a really good sign of success for a product. +Live is still really early for us. You don't get a lot of shots if something goes wrong with a live event. [laughs] You know, I'd be pretty quick to look for another platform. And that's a pretty mature market where there are a lot of really strong competition. I think if we can get to a place in six months where we've got, you know, a few hundred customers using that every week or every month, we'd feel like we're on a path towards success. +And the five-year version, I don't know, we recently started making three-year goals for the company a few years ago that have been pretty helpful to have as an anchoring. We have not made a five-year goal. But the thing I'm very excited about right now and what we're doing is, again, like, live is a small example. The market for live itself is much bigger than the market that traditionally Wistia has been in, and just in terms of video hosting, which itself has always grown a lot over the years. And it's itself a big market, as is video recording and creating video. +So we have entered into a bunch of new markets that are all really quite large. And it's pretty humbling to be in a spot where I feel like we have a really solid base with a lot of in-depth knowledge of marketing and our customer to be able to build a really excellent product for that set. We're playing in a much bigger market than I ever thought we would. +VICTORIA: It's like, success already achieved. +[laughter] +BRENDAN: Well, I don't know. It doesn't feel that way. It doesn't feel that way. But -- [laughs] +VICTORIA: Maybe next time you come on the podcast, you'll have another success story to share with us. [laughs] +BRENDAN: I hope so. Yeah, I feel like that's always the case, right? It's like, yeah, there are moments where we're certainly very proud of what we've been able to achieve. But most of my time is spent [laughs] in the headspace of, you know, why are we so slow? Why is the product not good enough? Why are we, you know, like, all the stuff that's going wrong, right? Which drives you to be better and is exciting. +VICTORIA: Right. That makes sense. Well, hopefully, this helps remind you all the good stuff that you all have done so far, too. +BRENDAN: [laughs] +VICTORIA: I'm really excited to hear about just how your values drive your decisions and then how that goes to the rest of the team and how closely you're listening to your customers, too, on the product. I think those are all just really great cultural examples and ways to build great products. So, thank you for sharing your story with me. +And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. And if you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter at @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Brendan Schwartz. + + + Brendan Schwartz is the Co-Founder and CTO of Wistia, software that makes it easy to find, engage, and grow your audience with video.

+ +

Victoria talks to Brendan about the latest updates on the platform, interesting problems he found that Wistia was able to remove and help his team get to speed and velocity, and the personal value that drives his decision-making.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Brendan Schwartz, Co-Founder and CTO of Wistia, software that makes it easy to find, engage, and grow your audience with video. Brendan, thank you for joining us.

+ +

BRENDAN: Thanks so much for having me.

+ +

VICTORIA: And I believe this will be your third time, at least, on the Giant Robots Podcast, right?

+ +

BRENDAN: Yes, I think this is my third appearance. Thank you for having me back.

+ +

VICTORIA: Yes.

+ +

BRENDAN: Is there anything I receive? What is it when you host SNL in a [crosstalk 00:39].

+ +

VICTORIA: You get a jacket.

+ +

BRENDAN: A jacket, yeah.

+ +

VICTORIA: Yeah, we should.

+ +

BRENDAN: [laughs]

+ +

VICTORIA: We should do a Giant Robots jacket or something from returned guests. I love it. So it's been great to follow along your journey here. So, for those who don't know, like, what is Wistia? And I'll say, just a precursor, that thoughtbot is a client of Wistia. So we use it ourselves. But why don't you just give us a little bit about what is the product and what makes it different?

+ +

BRENDAN: Sure. And thank you so much for being a customer all these years. You kind of hit it at the top, but we help businesses of all sizes thrive with video. And so we serve mostly marketers. To dive a little bit into the history of the business, we'll be around seven...is that right? 17 years. It sounds like a long time when I say it out loud, [laughs] 17 years this June. And, for most of our history, we were, I'd say, a video-hosting platform for marketers. So if you want to put video on your website, track who's watching it, how they're watching it, and integrate that data with your other marketing systems, that was our focus and what we did.

+ +

And over, I'd say, the past two years, we've brought in that focus to help businesses with all aspects of their video marketing from creating video...We recently introduced a live video product for webinars and for live events last fall. We just launched last week, which I'm very excited about native video recording in the Wistia platform. So you can record your webcam and your screen. And there's also a very simple video editor in the platform, which has been really powerful for folks to make small adjustments to content or to atomize content, take out highlights or sections of things, and to be able to publish them to their audiences.

+ +

VICTORIA: Thank you for providing that context. And I'm curious if there were any, like, environmental or market forces that pushed you in that direction with the latest updates on the platform.

+ +

BRENDAN: So, like I mentioned, we...in a large part, our success came (We're a relatively small team.) it came from being focused. And so for, you know, that decade or more, there were a lot of things that we had heard from the market or from customers. Like, live video was an obvious one we had been asked for a really long time. When will Wistia do live? When will Wistia do live? And, you know, our approach to that is we want to be really good and excellent at the things that we do and be focused. And I think that has served us well over the time that we've existed.

+ +

And some of that came out of; I'd say, the really early days of the company where...it's funny, [laughs] we've always built Wistia, you know, sometimes we say in the shadow of YouTube, so YouTube and seeing YouTube. My co-founder was the first person who showed me YouTube in 2005, I think it was, and that was part of the inspiration to start Wistia. We are both really into video. And we saw that and having video be more accessible on the web, we knew was something that was going to change the world.

+ +

There was a question...this sounds kind of dated nowadays to say, but there was a question if you were starting a business, you know, let’s say, in 2006 or 2007 or '8, right? What are you going to do when Google enters your space? [laughs] It was a funny one for us to answer because we said...well, I forgot when YouTube was bought by Google. It was maybe in 2006 or something like that. Like, Google is already in our space, and it's free. So that was always an interesting challenge.

+ +

And the way that we were successful there [laughs]...obviously, YouTube is at a much larger scale [laughs] and level of success than Wistia is. But to the extent we have a business at all against a very well-known and free competitor from those early days, it was being really focused on our customers and keeping the product footprint fairly small.

+ +

Our business changed a lot during the pandemic. There were some obvious things, right? Video was used a lot more. So existing customers had a lot more usage. We saw an influx of customers, people who maybe were late to adopt video in their organization, and then that became a much obvious way that people could reach their audiences and grow. So that was something of a tailwind for us.

+ +

And then it also forced us to kind of take a step back and look at the market in general with clear eyes. It was a funny moment, I think, for me and my co-founder because in the years leading up to that, you know, it had been like 12,13 years of doing Wistia, and it felt like we had solved a lot of problems in the product. We were still building new things, but they were for the most mature part of our audience or the most advanced marketers, which was pretty fun. But it felt like a lot of the problems had been solved. We were always, like, is the product done? Is the product complete?

+ +

And when we took a step back and looked at the market, what we had found was that we had kind of just, like, got ourselves into this, you know, more mature corner of the market. But in a large part, because of COVID, so many businesses, existing and new businesses, were very new to video and were using video in new ways. And people who had been using video, their solutions to do that were super fragmented.

+ +

You'd have one product that is providing...[laughs] You might have a different product you're using for internal meetings, video meetings, and that's different than a live event product, that's different than a webinar product, that's different than where you might publish your videos or host your videos, which is different than how you'd, like, analyze your performance.

+ +

And as video became more important to organizations, that fragmentation of the solutions was something that was super painful. And we had heard from a lot of people who were Wistia customers and people who were not...having this as an all-in-one platform was something that they really desired, which I was also kind of, you know, we were, like, cynical about a little bit, right?

+ +

Because if [laughs] you're in the world of product, it's like you can ask, you know, if you had a magic wand, what would you want? And someone says, "Oh, I want it all in one. And if you could just do everything for me, that would be so great." You know, it's hard to say, is that what people really want? And what gave us more confidence at that was, correct, is when we started digging into some of the details and hearing about existing workflows that existed that marketers have to deal with, including ourselves. We do a lot of content marketing.

+ +

A lot of the really interesting things you could do in a product that is all in one it opens up new opportunities. And you could just imagine...you've hosted a webinar before. Almost always, it's the best practice that you host a webinar; after you're finished, you probably have a good marketing asset there. You should publish it to your website. You usually need to do some light editing. Maybe you're going to take off the Q&A before you publish it. And you put it on your website.

+ +

And then, a while later, you're like, was this effective? Did it work? And then you have to, you know, probably have a spreadsheet somewhere. You have to go into the tool used to host the webinar to figure out who was watching it and [laughs] who registered. Did they attend? And then where's the data for how it performed on your website? How many people watched it? Did you get subscribers if you were, you know, had an email gate on that content? It's cumbersome, and it's a mess.

+ +

And then, you know, the most motivated people who are well-resourced have the time to do that and analyze the performance. But then a lot of marketers who are on smaller teams they just don't have time to do that, which means a lot of content gets under-utilized or under-marketed. So a lot of evidence and motivation to change what we were doing and expand the product footprint. So that had us make a big investment in our product design and engineering teams, and we almost...we doubled them in about 18 months. And then that kind of set us on this journey that we started maybe two years ago to greatly expand what we're doing.

+ +

VICTORIA: Well, that's great. So just to play that back, staying close and focused on your customers almost had you to a point of being stable with your product until COVID happened. And you have this increased demand for video that opened it up to almost have Wistia be like a startup again and create a whole new feature branch, right?

+ +

BRENDAN: Yeah, that's exactly right. And that was really fun and motivating. I mean, we...that early-stage energy and not having all the answers to things where stuff is a little bit, you know, less-researched, and it's faster paced is something that I really like. That was a big shift for the company. So there was some, I don't know, I think we had some self-doubt a little bit if I'm honest, of, you know, when you've been so focused for so long. Like, can we do this?

+ +

Like, will we be able to create something really good with this expanded footprint, and what resources that take? And is it going to take shifting the culture and mindset of the team, like, in ourselves? But, I don't know, that's kind of why I started the [laughs] business in the first, like, the adventure and not knowing what's next is very appealing. So that's been the fun part of it.

+ +

VICTORIA: And how did you go about shifting that mindset? Or even what was the moment where you realized that you needed to go after this shift? And how did you start lobbying everyone around you to get on board?

+ +

BRENDAN: A lot of those customer interviews and market interviews, we worked with an outside firm. We worked with Boston Consulting Group, who was a really great partner. We have obviously worked with folks outside. We hadn't worked with somebody; I'd say, at that scale in terms of kind of, like, tie-in with our company strategy today. But that was really helpful to have a partner, especially to push us. We got to something different than we had been doing, I mean, not dramatically so. But it was expanding what we were doing.

+ +

So that was really helpful. It helped...that put some structure around it to what we had, and the whole company knew this was happening and was along for the ride. So I'd say the communication and getting to a clear strategy was something we did pretty well, and telling that story internally. I'd say where we didn't do as well [laughs] and were maybe late to make some decisions is how the culture would need to change to support that strategy.

+ +

Again, like I said, we've doubled the product design and engineering teams. That is now feeling in a pretty good spot, but that was a lot of growth for us. And was, I'd say, pretty messy along the way. So the beginning, I'd say, was clear, and I think communicated well. And then I feel like in the middle it was, I don't know, a big mess where we got maybe a year in, and we're like, wow, we have this new strategy, but we really haven't executed much on it.

+ +

Some of these things we're building are taking a lot longer than we thought. Our velocity doesn't feel great. Like, maybe we didn't plan some of this stuff out. Like, we've hired a lot of people, but, like, are they productive yet? And so, yeah, I think we were in a pretty [laughs] tough spot maybe last summer. We were a year into this strategic shift, but it didn't feel like we were really moving against it as much as we had hoped.

+ +

VICTORIA: It makes sense that it would take some time to change strategic direction and then get to that high-velocity point that you would expect. Were there other blockers that you found you were able to remove to get the team back up to that high velocity on delivering features for clients?

+ +

BRENDAN: [laughs] Well, it's funny that you say that. I wish; I mean, that is pretty obvious, I think, and obvious in retrospect. But, for some reason, when you're in this, or when we were in this, you're impatient, and you want it faster. And I think probably [laughs] having some clear expectations would have made the ride a little smoother along the way for this. I feel like I have to remind myself of this pretty frequently.

+ +

I mean, Wistia is not big. We're 180 people or so but certainly bigger than...I can think back to various other sizes. Doing that strategic shift it takes time for leadership, let's say, or me to shift my mindset about some of those things. And then once you've changed your mind, you kind of... it's easy, or at least for me, to discount the time it took and all the information it took to lead to that, which needs to cascade through an organization. And so that's where some of that impatience...or just the piece you said about, yeah, it makes sense that this would take time. I was like --

+ +

VICTORIA: [laughs] [inaudible 11:56]

+ +

BRENDAN: [laughter] You're like, once you've got it, you're like, wow, this is so exciting. Let's go. Let's go. And everybody is like, what are you talking about?

+ +

VICTORIA: Yeah. My background has been in, like, Federal IT consulting. So you're used to kind of the pace of things being a little slower. And I think people forget that as an organization gets to any amount of size, that kind of bureaucracy tends to creep in. And, like you're saying, the information just needs to cascade down throughout everybody. I think my original question was, were there any blockers or interesting problems you found that you were able to remove and help your team get to that speed or velocity you really wanted?

+ +

BRENDAN: Yeah, there were a lot. I think most of them and most of the hardest ones to move centered around cultural change, and they weren't necessarily so clear at the onset. And so, you know, one thing that kind of partway into the strategy change that became clear is, and you had said it, it's like going from, you know, basically thinking of ourselves as being in a late stage or more mature market to being in an early-stage environment. And the type of culture that, you know, succeeds in those worlds is different.

+ +

One thing that we've learned along the way at Wistia that we have employed and I think been successful with is this concept that when you update your strategy as a company, you should be thoughtful and, like, make conscious updates to your culture and values. And so much is that...so you're saying culture is the way that you work. You want that to be in support of strategy. And I remember when I first heard this concept, and we were earlier into our journey. I was like, what is this, like, corporate nonsense? Culture is just this, like, intangible, you know, it's this sum of how everyone works. And it's, like, this beautiful symphony of values. [laughs]

+ +

It was a more kind of, like, idealistic [laughs] view of it or more organic view of it, which I think is reasonable. But you can also be intentional about your culture. So when we wrestled with that the first time...this was many years ago when we updated. I forgot even what the strategic changes at the time. But we updated our values, and we set about making a conscious cultural change. So when we changed the strategy this time, we did the same thing. I'd say we were a little bit late doing it, like, getting to it. But we did do it.

+ +

And so some of that was there were certain things...so, for instance, being so focused. We had a really lean team. And we were optimizing for things like predictability of outcomes and needing to be correct. So, for instance, if you're only going to make...let's just, like, say, on the product side. Like, if you're only going to be able to ship or do, you know, a few big improvements to the product per year, like, you're well served to kind of go slowly and make sure those have a reasonable chance of success. This was, like, the culture and the mode that we were in.

+ +

That doesn't really work very well when you're in an early-stage environment where things are pretty unpredictable and things are moving really quickly. So that was an example of something that we kind of identified, and we're like, we're going to need to change this. So it was this shift from teams feeling the need to be correct and really well-researched about something to moving towards; I'd say, you need to talk to a lot of customers to build customer intuition in order to make decisions faster.

+ +

But that shouldn't be the case that; for every product decision you need to make, you have to talk to 5 or 10 customers to validate that. You should be able to build an intuition to be able to make those decisions faster, and we should be more tolerant of failure. And so, we should work in a more incremental style. I mean, some of this is, like, super familiar to anybody [laughs] listening to this, right? It's like a more agile style. So work more incrementally, like, work incrementally towards great as opposed to, you know, this big thing that's going to be super polished and correct from the jump.

+ +

VICTORIA: I think that's really interesting. And it's not necessarily wrong to be so thorough in your changes when you're in that steady state, and you, like, know what clients you have, and you have a pretty well-defined product. But it's interesting that it took quite a bit of effort, it sounds like, to shift back into a flow state where you're incrementally doing changes very frequently to get that new product and find those new customers that you're targeting.

+ +

BRENDAN: And it continues to be. We've made a lot of progress on this. And maybe it's helpful...I don't know if it's helpful to folks listening to dive into some of the details of how we went about making those changes. It's still really difficult, right? There's a lot of things in tension.

+ +

So I'd say in our previous mode, one thing we were pretty good about is when something was released, it was well-tested. It was high quality. It was, like, well-communicated. Throughout the org, people knew what was coming. Obviously, there were hiccups with that, but, like, that's the side of the spectrum that we were on there.

+ +

And then in this mode where we're building faster and more incrementally, we have a lot of internal tension in terms of quality, like, is this good enough? Is this first version good enough? Are we going to make a bad first impression? And so, obviously, you do this for a...it's a set of trade-offs, right? There's no free lunch, but that is still very much we're trying to find the right balance.

+ +

VICTORIA: Right. So, like, in your role as CTO, how do you make people feel comfortable failing [laughs] [inaudible 17:06] describing.

+ +

BRENDAN: Some of this cultural change, I think, it's been interesting to go through because some of the properties of how we had been working are, you know, things that are part of the way I like to work. Like, it makes me uncomfortable to release something that you know the flaws in it. And that's an old kind of startup advice that I think is generally right. Like, if you release something and it doesn't make you a little bit uncomfortable, you have waited too long. [laughs] Advice is very easy and abstract. It's hard to apply. Like, there's a huge spectrum there of, like, how uncomfortable [laughs] you want to be.

+ +

But I will say that that's been something that's been, yeah, hard to reconcile with. And I guess that the piece that I'm able to do in my role is, like, remind folks where we're headed, right? So the first version can be a bit rough. What matters is what happens after that. So, if we're quick to listen to customers, to fix those things, to correct that, and people can see that momentum, I think that matters for a lot. And I think that's, like, something...I've been telling that story repeatedly.

+ +

Internally, I've had other leaders, and that's what we've really been leaning on is, like, we've adjusted how we're delivering customer value. And that we're going to push things out that might be a little bit more raw, but where we ultimately are going to get them to and get them to quickly is something that we're really proud of. So that has helped. And then, I'd say we still haven't figured out, which is, again, like, in these smaller increments, things can be a failure, and that's okay as long as we learn something and correct and move forward.

+ +

And one thing that's been a little bit tricky to recognize, too, is there's some places where you have some experiment, and you're not actually sure if there's a market or if there's a need for a feature. So you might do something, and it really doesn't land well. And then you learn something about the market or the customer base and say, okay, that isn't what people needed.

+ +

But, in a lot of places that we're building product, like, let's say, take live video, for example. [laughs] When we launch a live video product, it may be a failure. Like, the first version may not be completely right or may be a failure. But the customer need for [laughs] a live video for a webinar exists, right? So that's not the type of failure that you go, oh, I guess there's not [laughs] a market there. Or, it's like, you go back and say, okay, how do we need to improve this to make it work?

+ +

I don't think we have the right language internally around that. You know, there are certain areas where it's like a failure, and then it's like, okay, we've learned not to do that again. And there's other areas where it's like, we're going to keep...[laughs] not we're going to keep failing. I mean, there are goals to succeed, right? But we're going to keep improving this until we get it to work because we know there is a market here, and there is a customer need.

+ +

VICTORIA: Making a culture where it's acceptable to run experiments [chuckles] and as long as you're learning from the failures. And honestly, it sounds like you all are very connected to your customer. Like, you're talking to them regularly. You're testing out features with them and getting that feedback. And that sounds like that's really what you want to focus on and want your whole team to focus on.

+ +

BRENDAN: Yes, yeah, exactly.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: You mentioned a little bit about your values. So, what would you say is, like, your most important personal value that drives your decision-making at Wistia?

+ +

BRENDAN: So, like I mentioned, we've changed our values over time when we've changed strategy. And we think of our values as a decision-making framework, not as a set of things that we value. For instance, if you go on our website on wistia.com, I think about/values, about/company. It's somewhere. And you can see our values. It's not a list of everything that Wistia values or even the things that we value the most.

+ +

For example, Wistia has, like, creativity is something that I value a lot that is very built into Wistia's culture that we value a lot, but it's not a listed value. It used to be at one point, and then we found that as a decision-making tool, it wasn't very helpful. [laughs] If you're faced with a decision, and you say, okay, one of the values is creativity, how do I make this more creative, right?

+ +

VICTORIA: [laughs]

+ +

BRENDAN: That's not usually the question you want to ask. So we have, over the years, shifted towards the values are a decision-making framework. And I'd say the one value that has stood the test of time in there is simplicity, which is not unique to Wistia, but it's something that I care a lot about personally. It's served us well as a business.

+ +

It's almost always harder to get to a simple solution or answer than it is to get to a complex one. It takes a lot of failure. Sometimes there isn't a simple solution, but I think it's always worth the pursuit of trying to find one. And that's served us well in keeping a focused and easy-to-use product. I think that's fairly self-evident [laughs] why that matters to customers. And it's something that I think it's hard to do as you grow, and add, and get bigger. And it's an important feature of the product. And it's an important feature of, I don't know, companies' internal policies or the employee experience.

+ +

The simpler something is, it's easier to understand. I think the more someone who works inside your company can wrap their arms around more of that context or, you know, more of the product, more of the all the ins and outs of how it is to work there, the better informed they'll be, the better faster they'll be able to make decisions, and the better work they'll be able to do. So, yeah, simplicity, minimalism, those are things I think that have served us well over the years.

+ +

VICTORIA: Oh, I appreciate that. I could see how that could apply to how you're writing your code, or how you're designing a feature, or even your pricing structure.

+ +

BRENDAN: Yeah, and I don't think...we definitely don't always get it right. So, you know, all of this is aspirational, but I think it's the right thing to aspire to.

+ +

VICTORIA: Right. Oh, I'm familiar. [laughter] It's like that, I mean, the Marie Kondo, like, keeping it simple and organized. It's definitely aspirational [laughter] in my personal life as well. But that makes sense. Okay, I have a fun one for you. What is your favorite viral video style that you think people should do more of on Wistia? [laughs]

+ +

BRENDAN: Oh, whoa. That's a hot-button one. [laughs] I think we have long said...this, like, feels like it takes me back to when we first started Wistia. The term viral and viral video was a new thing for the internet, I guess because video on the internet was still fairly new. I've always been on the side of this, like, hardworking video. And most of our customers are B2B businesses, so these are, like, marketing teams at B2B companies.

+ +

I'm sure a lot of people who are listening to this have seen some very cringeworthy, you know, attempts at a viral video made by various corporations. Those usually don't land well. There are some people out there maybe that can crack this and make something that is viral through some art and science, but most everybody else cannot.

+ +

VICTORIA: [laughs]

+ +

BRENDAN: It's like, not something that can be kind of, like, bottled and captured. So we've always been on the side of, like, be authentic, be yourself, make these harder-working videos. But --

+ +

VICTORIA: I think that's generally good advice for businesses that was, like, maybe don't try to just do viral trends...[laughs] Like, make your own authentic content. But you personally now, like, yeah, if you were going to do whatever the latest TikTok trend is, which one would you pick?

+ +

BRENDAN: You know, okay, maybe here's one. So we have always been, as I described it, on the side of, like, do not do this. It is, like, almost always going to be cringe-worthy. But do you remember...I don't know what year this is from, the Harlem Shake. It was mostly kind of a business trend, right? You'd play this track, the Harlem Shake, and have, like, when the beat dropped, it would go from normal office to everyone dancing in a costume.

+ +

VICTORIA: Oh, that's fun.

+ +

BRENDAN: So it was, like, a fun trend. But it was...we were and still are, I'd say, fairly, like, anti-trend. I don't know what, you know, like, contrarian when it comes to marketing trends or things like that. But then, when this happened, we were like, this will be really funny. We should set a calendar reminder to do this, like, ten years in the future.

+ +

Actually, the last onsite that we had; unfortunately, it was the last day. Our head of production [laughs] who, like, we kind of had this, like, running joke of he randomly saw a news article. I think that it was the 10-year anniversary of the Harlem Shake [laughs] or whatever. He's like, oh, this would be...this is the perfect time to do this, now that it's so, so, so out of vogue. But, you know, people, like, maybe have fond memories of it. And now this is so out of fashion. I think it could be funny to do it. [laughs]

+ +

VICTORIA: Yeah, right. You don't want to do it just because it's the trend. But if it fits your personality and your business, then I think it would make sense.

+ +

BRENDAN: Yeah.

+ +

VICTORIA: I've heard that there might be a Wes Anderson style. [laughs] And I wanted to do a Wes Anderson goes to RailsConf video, but I'm actually meeting this --

+ +

BRENDAN: Did you do it?

+ +

VICTORIA: I didn't do it. I'm not actually good enough. I think tomorrow I'm meeting with the Wistia customer success team. [laughs] I'm going to ask them to help me.

+ +

BRENDAN: Oh yes, we'll help you.

+ +

VICTORIA: Yes.

+ +

BRENDAN: I do like...that trend is nice. That feels like a; I don't know, like, less aggressive. I've seen a lot of those, and they don't feel, I don't know, cringeworthy to me because maybe it's a nice shell in which to put some personality and content, as opposed to --

+ +

VICTORIA: Just being goofy or whatever, yeah. [laughs]

+ +

BRENDAN: Yeah, I don't know exactly how to describe it. But I think that one works better. Yeah, someone at Wistia did that the other day in the office, and people enjoyed it a lot. That was more for, like, internal consumption. But those ones are nice.

+ +

VICTORIA: Yeah. Well, I like the idea of bringing some of these editing tools to marketing teams where they can maybe not create viral videos all the time but do a lot of very highly editing and having it all in one place as well. Like you mentioned, I do run webinars, [laughs] and I'm familiar with the bouncing around between different tools to get everything to work. And there's even sometimes, like, security issues with different types of video-hosting tools. So I think there's a lot to offer for a marketing team who may not have as many resources to do the individual pieces.

+ +

BRENDAN: Yeah, that's a story we've heard, yeah, from a lot of customers. And we have a lot of video resources internally because we're a video company, and we invest a lot in that. But even so, yeah, if you talk to folks on our marketing team, they'd say it's hard to get those resources, especially if you have something small that you want to do.

+ +

I think it's always better if the person who has the need can easily do the thing themselves, right? More and better work gets done that way versus if it's, like, this chain of having to, like, ask other people because then you're like, should I really ask? It's like, do I want to, you know, spend social capital or budget on this thing? Will it work, will it not? But you can be, I think, faster and also experiment more when you have those tools available to you.

+ +

VICTORIA: Yeah, no, that makes sense. Because I don't know if it's worth [laughs] me spending my team's time to make this Wes Anderson video, but I want to do it for fun. So we'll see if I can do it at RubyKaigi next week.

+ +

BRENDAN: You should. That's great. That's, like, the perfect example of it because I feel like, yeah, well, maybe not. You might be sheepish to be like, yeah, I'm going to spend, like, ten grand with this, like, contractor to make this Wes Anderson...and to be like, what do you...what? What are you doing?

+ +

VICTORIA: [laughs] That makes sense.

+ +

BRENDAN: But if you do it, I think, you know, it's very likely it'll be really well-received, and you'll learn something about your audience. And then that could, like, blossom into, you know, a whole bunch of other things. I feel like that's been the case for us in our content marketing. We've long said, and this is, like, much more commonplace now, but one of the advantages of having a video producer in-house, like, is exactly that you now are employing someone full-time.

+ +

And so you've, you know, like, maybe knocked off, like, the major pieces of content that a business would make with video, some of the obvious things. But then it's exactly what you're talking about that, oh, we could take a risk, and we could try this. And that's where you learn and figure out new things and things that are different than your competitors might be doing or more creative approaches.

+ +

VICTORIA: Oh, That's great. You know, something I like to ask everybody who comes on the show, and it will be super interesting since you've been on a few times before, but if you could go back in time to your younger self when you first started Wistia, what advice would you give yourself?

+ +

BRENDAN: Patient...One funny thing of when we started Wistia, we had really unrealistic expectations. I don't think that's [laughs] unique when starting a business when you're young. But yeah, I was 22 or 23, as was my co-founder, Chris. And we really honestly thought—this is, like, this is cringeworthy to say—that we would either be really successful and, in six months, build this great business and sell it to Facebook or now Meta, right? But that was, like, a hot company at the time.

+ +

So we'd be wildly successful and sell to Facebook in six months, or we would fail in obscurity. That was, like, our honest-to-goodness business plan, which is so naive. [laughs] And here we are, you know, 17 years later and having a wonderful time. So I guess I would say, I mean, it's the most cliché advice, and you're young, and you never listen to stuff like this, but it's, like, enjoy the journey.

+ +

[laughter]

+ +

Things haven't always been easy. And there are, you know, hard challenges and, like, times filled with self-doubt. But even in those moments, if you have support from people around you, if you can learn to enjoy the growth and the journey, that is what keeps you motivated to do something for a long period of time. And usually, you know, people who stay focused on something for a long period of time you figure it out and can be successful. This sounds like the most generic advice as I say this out loud.

+ +

VICTORIA: [laughs]

+ +

BRENDAN: It really is. Enjoy the journey. [laughs]

+ +

VICTORIA: Enjoy the journey. But I think that's common. And even actually talking with Chad a few weeks ago and interviewing him about thoughtbot, is his younger self would tell him to have more fun [laughs] during the whole process and really enjoy it. And I think it's also interesting that you had either the most optimistic and the most [laughs] pessimistic as options and, like, nothing in between [laughter] that you expected would happen.

+ +

Which is funny because I have people ask me, like, is there still money in building apps and building new products? And it's like, yeah, like, it feels like there's these big people in the space, and they're doing everything you could think of possible. But there's still niche market that you can pursue [laughs], right? And there is still the ways that you can differentiate yourself as a product.

+ +

BRENDAN: Yeah, I think that's exactly right. What advice would you give to your younger self?

+ +

VICTORIA: Oh, me? I think, you know, probably something similar. Like, I feel like all of the times in my life where I've been, like, what am I going to do next and been really stressed out about it, within, like, three to six months, I found a new job, or I found something better where life improved a hundred-fold. [laughter]. So I think that's something even now I like to keep in mind is, like, if things turned down badly, like; usually, things turn around in a few months after that, [laughs] and a lot of times for the better. And that's, you know, true with, like, moving to California across the country from DC a few years ago. And yeah, a few other points like that.

+ +

I think the other part I think about is who I might have invested more time in and who I would have invested less time in. And like what you were saying, like, having the support of people around you, and finding the people who really have your back and support you, and, for people who don't, maybe letting go a little sooner. [laughs]

+ +

BRENDAN: Oh, interesting. Yeah, that's good advice. Yeah, I feel like both of those things are things I should probably remind myself of more frequently. [laughs]

+ +

VICTORIA: Right? And have more fun, which means...there's another quote I heard that's, like, when people travel back in time, they're worried about changing a small thing that will affect the future. But people don't think that they can make small changes now that will affect their future big time.

+ +

BRENDAN: Oh, that's a good one. I haven't heard that. But that's a good one.

+ +

VICTORIA: Well, super cool. Just to kind of really summarize or go back to some things we mentioned already about video, just how important do you think video really is to marketing in the current landscape for businesses?

+ +

BRENDAN: I mean, [laughs] I'm a very biased party, but I think it is becoming increasingly more important. I think it is the default way a lot of people want to consume information. This is a whole other tip that we didn't talk about with what's happening in the world of generative AI. And I'm sure a lot of people listening to this have voice cloning and how good those things have been getting.

+ +

I think it's going to make the value of authentic connections in video much more important in the short and medium term. And there's some challenging questions about how do you tell what's real in an environment where we've gone past the uncanny valley in terms of generating, you know, an avatar of me or you with the perfect voice clone? But I think people are going to rely a lot on video to break through.

+ +

VICTORIA: Yeah, that makes a lot of sense. It's going to be just more video world [laughs] as it goes. What does success look like for Wistia six months from now and even five years from now, the longer term?

+ +

BRENDAN: I think for six months from now, so there's a lot of new areas of the product that we've added. And, in the next six months, we should be able to make pretty substantial progress to have those parts of the product have really solid adoption and repeated usage by customers. I think that's what success looks like, which we're seeing it now for our editors, probably the farthest along, that it has really good adoption among the customer base, and repeat usage, which I think is, like, a really good sign of success for a product.

+ +

Live is still really early for us. You don't get a lot of shots if something goes wrong with a live event. [laughs] You know, I'd be pretty quick to look for another platform. And that's a pretty mature market where there are a lot of really strong competition. I think if we can get to a place in six months where we've got, you know, a few hundred customers using that every week or every month, we'd feel like we're on a path towards success.

+ +

And the five-year version, I don't know, we recently started making three-year goals for the company a few years ago that have been pretty helpful to have as an anchoring. We have not made a five-year goal. But the thing I'm very excited about right now and what we're doing is, again, like, live is a small example. The market for live itself is much bigger than the market that traditionally Wistia has been in, and just in terms of video hosting, which itself has always grown a lot over the years. And it's itself a big market, as is video recording and creating video.

+ +

So we have entered into a bunch of new markets that are all really quite large. And it's pretty humbling to be in a spot where I feel like we have a really solid base with a lot of in-depth knowledge of marketing and our customer to be able to build a really excellent product for that set. We're playing in a much bigger market than I ever thought we would.

+ +

VICTORIA: It's like, success already achieved.

+ +

[laughter]

+ +

BRENDAN: Well, I don't know. It doesn't feel that way. It doesn't feel that way. But -- [laughs]

+ +

VICTORIA: Maybe next time you come on the podcast, you'll have another success story to share with us. [laughs]

+ +

BRENDAN: I hope so. Yeah, I feel like that's always the case, right? It's like, yeah, there are moments where we're certainly very proud of what we've been able to achieve. But most of my time is spent [laughs] in the headspace of, you know, why are we so slow? Why is the product not good enough? Why are we, you know, like, all the stuff that's going wrong, right? Which drives you to be better and is exciting.

+ +

VICTORIA: Right. That makes sense. Well, hopefully, this helps remind you all the good stuff that you all have done so far, too.

+ +

BRENDAN: [laughs]

+ +

VICTORIA: I'm really excited to hear about just how your values drive your decisions and then how that goes to the rest of the team and how closely you're listening to your customers, too, on the product. I think those are all just really great cultural examples and ways to build great products. So, thank you for sharing your story with me.

+ +

And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. And if you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter at @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brendan Schwartz.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Brendan Schwartz is the Co-Founder and CTO of Wistia, software that makes it easy to find, engage, and grow your audience with video.

+ +

Victoria talks to Brendan about the latest updates on the platform, interesting problems he found that Wistia was able to remove and help his team get to speed and velocity, and the personal value that drives his decision-making.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Brendan Schwartz, Co-Founder and CTO of Wistia, software that makes it easy to find, engage, and grow your audience with video. Brendan, thank you for joining us.

+ +

BRENDAN: Thanks so much for having me.

+ +

VICTORIA: And I believe this will be your third time, at least, on the Giant Robots Podcast, right?

+ +

BRENDAN: Yes, I think this is my third appearance. Thank you for having me back.

+ +

VICTORIA: Yes.

+ +

BRENDAN: Is there anything I receive? What is it when you host SNL in a [crosstalk 00:39].

+ +

VICTORIA: You get a jacket.

+ +

BRENDAN: A jacket, yeah.

+ +

VICTORIA: Yeah, we should.

+ +

BRENDAN: [laughs]

+ +

VICTORIA: We should do a Giant Robots jacket or something from returned guests. I love it. So it's been great to follow along your journey here. So, for those who don't know, like, what is Wistia? And I'll say, just a precursor, that thoughtbot is a client of Wistia. So we use it ourselves. But why don't you just give us a little bit about what is the product and what makes it different?

+ +

BRENDAN: Sure. And thank you so much for being a customer all these years. You kind of hit it at the top, but we help businesses of all sizes thrive with video. And so we serve mostly marketers. To dive a little bit into the history of the business, we'll be around seven...is that right? 17 years. It sounds like a long time when I say it out loud, [laughs] 17 years this June. And, for most of our history, we were, I'd say, a video-hosting platform for marketers. So if you want to put video on your website, track who's watching it, how they're watching it, and integrate that data with your other marketing systems, that was our focus and what we did.

+ +

And over, I'd say, the past two years, we've brought in that focus to help businesses with all aspects of their video marketing from creating video...We recently introduced a live video product for webinars and for live events last fall. We just launched last week, which I'm very excited about native video recording in the Wistia platform. So you can record your webcam and your screen. And there's also a very simple video editor in the platform, which has been really powerful for folks to make small adjustments to content or to atomize content, take out highlights or sections of things, and to be able to publish them to their audiences.

+ +

VICTORIA: Thank you for providing that context. And I'm curious if there were any, like, environmental or market forces that pushed you in that direction with the latest updates on the platform.

+ +

BRENDAN: So, like I mentioned, we...in a large part, our success came (We're a relatively small team.) it came from being focused. And so for, you know, that decade or more, there were a lot of things that we had heard from the market or from customers. Like, live video was an obvious one we had been asked for a really long time. When will Wistia do live? When will Wistia do live? And, you know, our approach to that is we want to be really good and excellent at the things that we do and be focused. And I think that has served us well over the time that we've existed.

+ +

And some of that came out of; I'd say, the really early days of the company where...it's funny, [laughs] we've always built Wistia, you know, sometimes we say in the shadow of YouTube, so YouTube and seeing YouTube. My co-founder was the first person who showed me YouTube in 2005, I think it was, and that was part of the inspiration to start Wistia. We are both really into video. And we saw that and having video be more accessible on the web, we knew was something that was going to change the world.

+ +

There was a question...this sounds kind of dated nowadays to say, but there was a question if you were starting a business, you know, let’s say, in 2006 or 2007 or '8, right? What are you going to do when Google enters your space? [laughs] It was a funny one for us to answer because we said...well, I forgot when YouTube was bought by Google. It was maybe in 2006 or something like that. Like, Google is already in our space, and it's free. So that was always an interesting challenge.

+ +

And the way that we were successful there [laughs]...obviously, YouTube is at a much larger scale [laughs] and level of success than Wistia is. But to the extent we have a business at all against a very well-known and free competitor from those early days, it was being really focused on our customers and keeping the product footprint fairly small.

+ +

Our business changed a lot during the pandemic. There were some obvious things, right? Video was used a lot more. So existing customers had a lot more usage. We saw an influx of customers, people who maybe were late to adopt video in their organization, and then that became a much obvious way that people could reach their audiences and grow. So that was something of a tailwind for us.

+ +

And then it also forced us to kind of take a step back and look at the market in general with clear eyes. It was a funny moment, I think, for me and my co-founder because in the years leading up to that, you know, it had been like 12,13 years of doing Wistia, and it felt like we had solved a lot of problems in the product. We were still building new things, but they were for the most mature part of our audience or the most advanced marketers, which was pretty fun. But it felt like a lot of the problems had been solved. We were always, like, is the product done? Is the product complete?

+ +

And when we took a step back and looked at the market, what we had found was that we had kind of just, like, got ourselves into this, you know, more mature corner of the market. But in a large part, because of COVID, so many businesses, existing and new businesses, were very new to video and were using video in new ways. And people who had been using video, their solutions to do that were super fragmented.

+ +

You'd have one product that is providing...[laughs] You might have a different product you're using for internal meetings, video meetings, and that's different than a live event product, that's different than a webinar product, that's different than where you might publish your videos or host your videos, which is different than how you'd, like, analyze your performance.

+ +

And as video became more important to organizations, that fragmentation of the solutions was something that was super painful. And we had heard from a lot of people who were Wistia customers and people who were not...having this as an all-in-one platform was something that they really desired, which I was also kind of, you know, we were, like, cynical about a little bit, right?

+ +

Because if [laughs] you're in the world of product, it's like you can ask, you know, if you had a magic wand, what would you want? And someone says, "Oh, I want it all in one. And if you could just do everything for me, that would be so great." You know, it's hard to say, is that what people really want? And what gave us more confidence at that was, correct, is when we started digging into some of the details and hearing about existing workflows that existed that marketers have to deal with, including ourselves. We do a lot of content marketing.

+ +

A lot of the really interesting things you could do in a product that is all in one it opens up new opportunities. And you could just imagine...you've hosted a webinar before. Almost always, it's the best practice that you host a webinar; after you're finished, you probably have a good marketing asset there. You should publish it to your website. You usually need to do some light editing. Maybe you're going to take off the Q&A before you publish it. And you put it on your website.

+ +

And then, a while later, you're like, was this effective? Did it work? And then you have to, you know, probably have a spreadsheet somewhere. You have to go into the tool used to host the webinar to figure out who was watching it and [laughs] who registered. Did they attend? And then where's the data for how it performed on your website? How many people watched it? Did you get subscribers if you were, you know, had an email gate on that content? It's cumbersome, and it's a mess.

+ +

And then, you know, the most motivated people who are well-resourced have the time to do that and analyze the performance. But then a lot of marketers who are on smaller teams they just don't have time to do that, which means a lot of content gets under-utilized or under-marketed. So a lot of evidence and motivation to change what we were doing and expand the product footprint. So that had us make a big investment in our product design and engineering teams, and we almost...we doubled them in about 18 months. And then that kind of set us on this journey that we started maybe two years ago to greatly expand what we're doing.

+ +

VICTORIA: Well, that's great. So just to play that back, staying close and focused on your customers almost had you to a point of being stable with your product until COVID happened. And you have this increased demand for video that opened it up to almost have Wistia be like a startup again and create a whole new feature branch, right?

+ +

BRENDAN: Yeah, that's exactly right. And that was really fun and motivating. I mean, we...that early-stage energy and not having all the answers to things where stuff is a little bit, you know, less-researched, and it's faster paced is something that I really like. That was a big shift for the company. So there was some, I don't know, I think we had some self-doubt a little bit if I'm honest, of, you know, when you've been so focused for so long. Like, can we do this?

+ +

Like, will we be able to create something really good with this expanded footprint, and what resources that take? And is it going to take shifting the culture and mindset of the team, like, in ourselves? But, I don't know, that's kind of why I started the [laughs] business in the first, like, the adventure and not knowing what's next is very appealing. So that's been the fun part of it.

+ +

VICTORIA: And how did you go about shifting that mindset? Or even what was the moment where you realized that you needed to go after this shift? And how did you start lobbying everyone around you to get on board?

+ +

BRENDAN: A lot of those customer interviews and market interviews, we worked with an outside firm. We worked with Boston Consulting Group, who was a really great partner. We have obviously worked with folks outside. We hadn't worked with somebody; I'd say, at that scale in terms of kind of, like, tie-in with our company strategy today. But that was really helpful to have a partner, especially to push us. We got to something different than we had been doing, I mean, not dramatically so. But it was expanding what we were doing.

+ +

So that was really helpful. It helped...that put some structure around it to what we had, and the whole company knew this was happening and was along for the ride. So I'd say the communication and getting to a clear strategy was something we did pretty well, and telling that story internally. I'd say where we didn't do as well [laughs] and were maybe late to make some decisions is how the culture would need to change to support that strategy.

+ +

Again, like I said, we've doubled the product design and engineering teams. That is now feeling in a pretty good spot, but that was a lot of growth for us. And was, I'd say, pretty messy along the way. So the beginning, I'd say, was clear, and I think communicated well. And then I feel like in the middle it was, I don't know, a big mess where we got maybe a year in, and we're like, wow, we have this new strategy, but we really haven't executed much on it.

+ +

Some of these things we're building are taking a lot longer than we thought. Our velocity doesn't feel great. Like, maybe we didn't plan some of this stuff out. Like, we've hired a lot of people, but, like, are they productive yet? And so, yeah, I think we were in a pretty [laughs] tough spot maybe last summer. We were a year into this strategic shift, but it didn't feel like we were really moving against it as much as we had hoped.

+ +

VICTORIA: It makes sense that it would take some time to change strategic direction and then get to that high-velocity point that you would expect. Were there other blockers that you found you were able to remove to get the team back up to that high velocity on delivering features for clients?

+ +

BRENDAN: [laughs] Well, it's funny that you say that. I wish; I mean, that is pretty obvious, I think, and obvious in retrospect. But, for some reason, when you're in this, or when we were in this, you're impatient, and you want it faster. And I think probably [laughs] having some clear expectations would have made the ride a little smoother along the way for this. I feel like I have to remind myself of this pretty frequently.

+ +

I mean, Wistia is not big. We're 180 people or so but certainly bigger than...I can think back to various other sizes. Doing that strategic shift it takes time for leadership, let's say, or me to shift my mindset about some of those things. And then once you've changed your mind, you kind of... it's easy, or at least for me, to discount the time it took and all the information it took to lead to that, which needs to cascade through an organization. And so that's where some of that impatience...or just the piece you said about, yeah, it makes sense that this would take time. I was like --

+ +

VICTORIA: [laughs] [inaudible 11:56]

+ +

BRENDAN: [laughter] You're like, once you've got it, you're like, wow, this is so exciting. Let's go. Let's go. And everybody is like, what are you talking about?

+ +

VICTORIA: Yeah. My background has been in, like, Federal IT consulting. So you're used to kind of the pace of things being a little slower. And I think people forget that as an organization gets to any amount of size, that kind of bureaucracy tends to creep in. And, like you're saying, the information just needs to cascade down throughout everybody. I think my original question was, were there any blockers or interesting problems you found that you were able to remove and help your team get to that speed or velocity you really wanted?

+ +

BRENDAN: Yeah, there were a lot. I think most of them and most of the hardest ones to move centered around cultural change, and they weren't necessarily so clear at the onset. And so, you know, one thing that kind of partway into the strategy change that became clear is, and you had said it, it's like going from, you know, basically thinking of ourselves as being in a late stage or more mature market to being in an early-stage environment. And the type of culture that, you know, succeeds in those worlds is different.

+ +

One thing that we've learned along the way at Wistia that we have employed and I think been successful with is this concept that when you update your strategy as a company, you should be thoughtful and, like, make conscious updates to your culture and values. And so much is that...so you're saying culture is the way that you work. You want that to be in support of strategy. And I remember when I first heard this concept, and we were earlier into our journey. I was like, what is this, like, corporate nonsense? Culture is just this, like, intangible, you know, it's this sum of how everyone works. And it's, like, this beautiful symphony of values. [laughs]

+ +

It was a more kind of, like, idealistic [laughs] view of it or more organic view of it, which I think is reasonable. But you can also be intentional about your culture. So when we wrestled with that the first time...this was many years ago when we updated. I forgot even what the strategic changes at the time. But we updated our values, and we set about making a conscious cultural change. So when we changed the strategy this time, we did the same thing. I'd say we were a little bit late doing it, like, getting to it. But we did do it.

+ +

And so some of that was there were certain things...so, for instance, being so focused. We had a really lean team. And we were optimizing for things like predictability of outcomes and needing to be correct. So, for instance, if you're only going to make...let's just, like, say, on the product side. Like, if you're only going to be able to ship or do, you know, a few big improvements to the product per year, like, you're well served to kind of go slowly and make sure those have a reasonable chance of success. This was, like, the culture and the mode that we were in.

+ +

That doesn't really work very well when you're in an early-stage environment where things are pretty unpredictable and things are moving really quickly. So that was an example of something that we kind of identified, and we're like, we're going to need to change this. So it was this shift from teams feeling the need to be correct and really well-researched about something to moving towards; I'd say, you need to talk to a lot of customers to build customer intuition in order to make decisions faster.

+ +

But that shouldn't be the case that; for every product decision you need to make, you have to talk to 5 or 10 customers to validate that. You should be able to build an intuition to be able to make those decisions faster, and we should be more tolerant of failure. And so, we should work in a more incremental style. I mean, some of this is, like, super familiar to anybody [laughs] listening to this, right? It's like a more agile style. So work more incrementally, like, work incrementally towards great as opposed to, you know, this big thing that's going to be super polished and correct from the jump.

+ +

VICTORIA: I think that's really interesting. And it's not necessarily wrong to be so thorough in your changes when you're in that steady state, and you, like, know what clients you have, and you have a pretty well-defined product. But it's interesting that it took quite a bit of effort, it sounds like, to shift back into a flow state where you're incrementally doing changes very frequently to get that new product and find those new customers that you're targeting.

+ +

BRENDAN: And it continues to be. We've made a lot of progress on this. And maybe it's helpful...I don't know if it's helpful to folks listening to dive into some of the details of how we went about making those changes. It's still really difficult, right? There's a lot of things in tension.

+ +

So I'd say in our previous mode, one thing we were pretty good about is when something was released, it was well-tested. It was high quality. It was, like, well-communicated. Throughout the org, people knew what was coming. Obviously, there were hiccups with that, but, like, that's the side of the spectrum that we were on there.

+ +

And then in this mode where we're building faster and more incrementally, we have a lot of internal tension in terms of quality, like, is this good enough? Is this first version good enough? Are we going to make a bad first impression? And so, obviously, you do this for a...it's a set of trade-offs, right? There's no free lunch, but that is still very much we're trying to find the right balance.

+ +

VICTORIA: Right. So, like, in your role as CTO, how do you make people feel comfortable failing [laughs] [inaudible 17:06] describing.

+ +

BRENDAN: Some of this cultural change, I think, it's been interesting to go through because some of the properties of how we had been working are, you know, things that are part of the way I like to work. Like, it makes me uncomfortable to release something that you know the flaws in it. And that's an old kind of startup advice that I think is generally right. Like, if you release something and it doesn't make you a little bit uncomfortable, you have waited too long. [laughs] Advice is very easy and abstract. It's hard to apply. Like, there's a huge spectrum there of, like, how uncomfortable [laughs] you want to be.

+ +

But I will say that that's been something that's been, yeah, hard to reconcile with. And I guess that the piece that I'm able to do in my role is, like, remind folks where we're headed, right? So the first version can be a bit rough. What matters is what happens after that. So, if we're quick to listen to customers, to fix those things, to correct that, and people can see that momentum, I think that matters for a lot. And I think that's, like, something...I've been telling that story repeatedly.

+ +

Internally, I've had other leaders, and that's what we've really been leaning on is, like, we've adjusted how we're delivering customer value. And that we're going to push things out that might be a little bit more raw, but where we ultimately are going to get them to and get them to quickly is something that we're really proud of. So that has helped. And then, I'd say we still haven't figured out, which is, again, like, in these smaller increments, things can be a failure, and that's okay as long as we learn something and correct and move forward.

+ +

And one thing that's been a little bit tricky to recognize, too, is there's some places where you have some experiment, and you're not actually sure if there's a market or if there's a need for a feature. So you might do something, and it really doesn't land well. And then you learn something about the market or the customer base and say, okay, that isn't what people needed.

+ +

But, in a lot of places that we're building product, like, let's say, take live video, for example. [laughs] When we launch a live video product, it may be a failure. Like, the first version may not be completely right or may be a failure. But the customer need for [laughs] a live video for a webinar exists, right? So that's not the type of failure that you go, oh, I guess there's not [laughs] a market there. Or, it's like, you go back and say, okay, how do we need to improve this to make it work?

+ +

I don't think we have the right language internally around that. You know, there are certain areas where it's like a failure, and then it's like, okay, we've learned not to do that again. And there's other areas where it's like, we're going to keep...[laughs] not we're going to keep failing. I mean, there are goals to succeed, right? But we're going to keep improving this until we get it to work because we know there is a market here, and there is a customer need.

+ +

VICTORIA: Making a culture where it's acceptable to run experiments [chuckles] and as long as you're learning from the failures. And honestly, it sounds like you all are very connected to your customer. Like, you're talking to them regularly. You're testing out features with them and getting that feedback. And that sounds like that's really what you want to focus on and want your whole team to focus on.

+ +

BRENDAN: Yes, yeah, exactly.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: You mentioned a little bit about your values. So, what would you say is, like, your most important personal value that drives your decision-making at Wistia?

+ +

BRENDAN: So, like I mentioned, we've changed our values over time when we've changed strategy. And we think of our values as a decision-making framework, not as a set of things that we value. For instance, if you go on our website on wistia.com, I think about/values, about/company. It's somewhere. And you can see our values. It's not a list of everything that Wistia values or even the things that we value the most.

+ +

For example, Wistia has, like, creativity is something that I value a lot that is very built into Wistia's culture that we value a lot, but it's not a listed value. It used to be at one point, and then we found that as a decision-making tool, it wasn't very helpful. [laughs] If you're faced with a decision, and you say, okay, one of the values is creativity, how do I make this more creative, right?

+ +

VICTORIA: [laughs]

+ +

BRENDAN: That's not usually the question you want to ask. So we have, over the years, shifted towards the values are a decision-making framework. And I'd say the one value that has stood the test of time in there is simplicity, which is not unique to Wistia, but it's something that I care a lot about personally. It's served us well as a business.

+ +

It's almost always harder to get to a simple solution or answer than it is to get to a complex one. It takes a lot of failure. Sometimes there isn't a simple solution, but I think it's always worth the pursuit of trying to find one. And that's served us well in keeping a focused and easy-to-use product. I think that's fairly self-evident [laughs] why that matters to customers. And it's something that I think it's hard to do as you grow, and add, and get bigger. And it's an important feature of the product. And it's an important feature of, I don't know, companies' internal policies or the employee experience.

+ +

The simpler something is, it's easier to understand. I think the more someone who works inside your company can wrap their arms around more of that context or, you know, more of the product, more of the all the ins and outs of how it is to work there, the better informed they'll be, the better faster they'll be able to make decisions, and the better work they'll be able to do. So, yeah, simplicity, minimalism, those are things I think that have served us well over the years.

+ +

VICTORIA: Oh, I appreciate that. I could see how that could apply to how you're writing your code, or how you're designing a feature, or even your pricing structure.

+ +

BRENDAN: Yeah, and I don't think...we definitely don't always get it right. So, you know, all of this is aspirational, but I think it's the right thing to aspire to.

+ +

VICTORIA: Right. Oh, I'm familiar. [laughter] It's like that, I mean, the Marie Kondo, like, keeping it simple and organized. It's definitely aspirational [laughter] in my personal life as well. But that makes sense. Okay, I have a fun one for you. What is your favorite viral video style that you think people should do more of on Wistia? [laughs]

+ +

BRENDAN: Oh, whoa. That's a hot-button one. [laughs] I think we have long said...this, like, feels like it takes me back to when we first started Wistia. The term viral and viral video was a new thing for the internet, I guess because video on the internet was still fairly new. I've always been on the side of this, like, hardworking video. And most of our customers are B2B businesses, so these are, like, marketing teams at B2B companies.

+ +

I'm sure a lot of people who are listening to this have seen some very cringeworthy, you know, attempts at a viral video made by various corporations. Those usually don't land well. There are some people out there maybe that can crack this and make something that is viral through some art and science, but most everybody else cannot.

+ +

VICTORIA: [laughs]

+ +

BRENDAN: It's like, not something that can be kind of, like, bottled and captured. So we've always been on the side of, like, be authentic, be yourself, make these harder-working videos. But --

+ +

VICTORIA: I think that's generally good advice for businesses that was, like, maybe don't try to just do viral trends...[laughs] Like, make your own authentic content. But you personally now, like, yeah, if you were going to do whatever the latest TikTok trend is, which one would you pick?

+ +

BRENDAN: You know, okay, maybe here's one. So we have always been, as I described it, on the side of, like, do not do this. It is, like, almost always going to be cringe-worthy. But do you remember...I don't know what year this is from, the Harlem Shake. It was mostly kind of a business trend, right? You'd play this track, the Harlem Shake, and have, like, when the beat dropped, it would go from normal office to everyone dancing in a costume.

+ +

VICTORIA: Oh, that's fun.

+ +

BRENDAN: So it was, like, a fun trend. But it was...we were and still are, I'd say, fairly, like, anti-trend. I don't know what, you know, like, contrarian when it comes to marketing trends or things like that. But then, when this happened, we were like, this will be really funny. We should set a calendar reminder to do this, like, ten years in the future.

+ +

Actually, the last onsite that we had; unfortunately, it was the last day. Our head of production [laughs] who, like, we kind of had this, like, running joke of he randomly saw a news article. I think that it was the 10-year anniversary of the Harlem Shake [laughs] or whatever. He's like, oh, this would be...this is the perfect time to do this, now that it's so, so, so out of vogue. But, you know, people, like, maybe have fond memories of it. And now this is so out of fashion. I think it could be funny to do it. [laughs]

+ +

VICTORIA: Yeah, right. You don't want to do it just because it's the trend. But if it fits your personality and your business, then I think it would make sense.

+ +

BRENDAN: Yeah.

+ +

VICTORIA: I've heard that there might be a Wes Anderson style. [laughs] And I wanted to do a Wes Anderson goes to RailsConf video, but I'm actually meeting this --

+ +

BRENDAN: Did you do it?

+ +

VICTORIA: I didn't do it. I'm not actually good enough. I think tomorrow I'm meeting with the Wistia customer success team. [laughs] I'm going to ask them to help me.

+ +

BRENDAN: Oh yes, we'll help you.

+ +

VICTORIA: Yes.

+ +

BRENDAN: I do like...that trend is nice. That feels like a; I don't know, like, less aggressive. I've seen a lot of those, and they don't feel, I don't know, cringeworthy to me because maybe it's a nice shell in which to put some personality and content, as opposed to --

+ +

VICTORIA: Just being goofy or whatever, yeah. [laughs]

+ +

BRENDAN: Yeah, I don't know exactly how to describe it. But I think that one works better. Yeah, someone at Wistia did that the other day in the office, and people enjoyed it a lot. That was more for, like, internal consumption. But those ones are nice.

+ +

VICTORIA: Yeah. Well, I like the idea of bringing some of these editing tools to marketing teams where they can maybe not create viral videos all the time but do a lot of very highly editing and having it all in one place as well. Like you mentioned, I do run webinars, [laughs] and I'm familiar with the bouncing around between different tools to get everything to work. And there's even sometimes, like, security issues with different types of video-hosting tools. So I think there's a lot to offer for a marketing team who may not have as many resources to do the individual pieces.

+ +

BRENDAN: Yeah, that's a story we've heard, yeah, from a lot of customers. And we have a lot of video resources internally because we're a video company, and we invest a lot in that. But even so, yeah, if you talk to folks on our marketing team, they'd say it's hard to get those resources, especially if you have something small that you want to do.

+ +

I think it's always better if the person who has the need can easily do the thing themselves, right? More and better work gets done that way versus if it's, like, this chain of having to, like, ask other people because then you're like, should I really ask? It's like, do I want to, you know, spend social capital or budget on this thing? Will it work, will it not? But you can be, I think, faster and also experiment more when you have those tools available to you.

+ +

VICTORIA: Yeah, no, that makes sense. Because I don't know if it's worth [laughs] me spending my team's time to make this Wes Anderson video, but I want to do it for fun. So we'll see if I can do it at RubyKaigi next week.

+ +

BRENDAN: You should. That's great. That's, like, the perfect example of it because I feel like, yeah, well, maybe not. You might be sheepish to be like, yeah, I'm going to spend, like, ten grand with this, like, contractor to make this Wes Anderson...and to be like, what do you...what? What are you doing?

+ +

VICTORIA: [laughs] That makes sense.

+ +

BRENDAN: But if you do it, I think, you know, it's very likely it'll be really well-received, and you'll learn something about your audience. And then that could, like, blossom into, you know, a whole bunch of other things. I feel like that's been the case for us in our content marketing. We've long said, and this is, like, much more commonplace now, but one of the advantages of having a video producer in-house, like, is exactly that you now are employing someone full-time.

+ +

And so you've, you know, like, maybe knocked off, like, the major pieces of content that a business would make with video, some of the obvious things. But then it's exactly what you're talking about that, oh, we could take a risk, and we could try this. And that's where you learn and figure out new things and things that are different than your competitors might be doing or more creative approaches.

+ +

VICTORIA: Oh, That's great. You know, something I like to ask everybody who comes on the show, and it will be super interesting since you've been on a few times before, but if you could go back in time to your younger self when you first started Wistia, what advice would you give yourself?

+ +

BRENDAN: Patient...One funny thing of when we started Wistia, we had really unrealistic expectations. I don't think that's [laughs] unique when starting a business when you're young. But yeah, I was 22 or 23, as was my co-founder, Chris. And we really honestly thought—this is, like, this is cringeworthy to say—that we would either be really successful and, in six months, build this great business and sell it to Facebook or now Meta, right? But that was, like, a hot company at the time.

+ +

So we'd be wildly successful and sell to Facebook in six months, or we would fail in obscurity. That was, like, our honest-to-goodness business plan, which is so naive. [laughs] And here we are, you know, 17 years later and having a wonderful time. So I guess I would say, I mean, it's the most cliché advice, and you're young, and you never listen to stuff like this, but it's, like, enjoy the journey.

+ +

[laughter]

+ +

Things haven't always been easy. And there are, you know, hard challenges and, like, times filled with self-doubt. But even in those moments, if you have support from people around you, if you can learn to enjoy the growth and the journey, that is what keeps you motivated to do something for a long period of time. And usually, you know, people who stay focused on something for a long period of time you figure it out and can be successful. This sounds like the most generic advice as I say this out loud.

+ +

VICTORIA: [laughs]

+ +

BRENDAN: It really is. Enjoy the journey. [laughs]

+ +

VICTORIA: Enjoy the journey. But I think that's common. And even actually talking with Chad a few weeks ago and interviewing him about thoughtbot, is his younger self would tell him to have more fun [laughs] during the whole process and really enjoy it. And I think it's also interesting that you had either the most optimistic and the most [laughs] pessimistic as options and, like, nothing in between [laughter] that you expected would happen.

+ +

Which is funny because I have people ask me, like, is there still money in building apps and building new products? And it's like, yeah, like, it feels like there's these big people in the space, and they're doing everything you could think of possible. But there's still niche market that you can pursue [laughs], right? And there is still the ways that you can differentiate yourself as a product.

+ +

BRENDAN: Yeah, I think that's exactly right. What advice would you give to your younger self?

+ +

VICTORIA: Oh, me? I think, you know, probably something similar. Like, I feel like all of the times in my life where I've been, like, what am I going to do next and been really stressed out about it, within, like, three to six months, I found a new job, or I found something better where life improved a hundred-fold. [laughter]. So I think that's something even now I like to keep in mind is, like, if things turned down badly, like; usually, things turn around in a few months after that, [laughs] and a lot of times for the better. And that's, you know, true with, like, moving to California across the country from DC a few years ago. And yeah, a few other points like that.

+ +

I think the other part I think about is who I might have invested more time in and who I would have invested less time in. And like what you were saying, like, having the support of people around you, and finding the people who really have your back and support you, and, for people who don't, maybe letting go a little sooner. [laughs]

+ +

BRENDAN: Oh, interesting. Yeah, that's good advice. Yeah, I feel like both of those things are things I should probably remind myself of more frequently. [laughs]

+ +

VICTORIA: Right? And have more fun, which means...there's another quote I heard that's, like, when people travel back in time, they're worried about changing a small thing that will affect the future. But people don't think that they can make small changes now that will affect their future big time.

+ +

BRENDAN: Oh, that's a good one. I haven't heard that. But that's a good one.

+ +

VICTORIA: Well, super cool. Just to kind of really summarize or go back to some things we mentioned already about video, just how important do you think video really is to marketing in the current landscape for businesses?

+ +

BRENDAN: I mean, [laughs] I'm a very biased party, but I think it is becoming increasingly more important. I think it is the default way a lot of people want to consume information. This is a whole other tip that we didn't talk about with what's happening in the world of generative AI. And I'm sure a lot of people listening to this have voice cloning and how good those things have been getting.

+ +

I think it's going to make the value of authentic connections in video much more important in the short and medium term. And there's some challenging questions about how do you tell what's real in an environment where we've gone past the uncanny valley in terms of generating, you know, an avatar of me or you with the perfect voice clone? But I think people are going to rely a lot on video to break through.

+ +

VICTORIA: Yeah, that makes a lot of sense. It's going to be just more video world [laughs] as it goes. What does success look like for Wistia six months from now and even five years from now, the longer term?

+ +

BRENDAN: I think for six months from now, so there's a lot of new areas of the product that we've added. And, in the next six months, we should be able to make pretty substantial progress to have those parts of the product have really solid adoption and repeated usage by customers. I think that's what success looks like, which we're seeing it now for our editors, probably the farthest along, that it has really good adoption among the customer base, and repeat usage, which I think is, like, a really good sign of success for a product.

+ +

Live is still really early for us. You don't get a lot of shots if something goes wrong with a live event. [laughs] You know, I'd be pretty quick to look for another platform. And that's a pretty mature market where there are a lot of really strong competition. I think if we can get to a place in six months where we've got, you know, a few hundred customers using that every week or every month, we'd feel like we're on a path towards success.

+ +

And the five-year version, I don't know, we recently started making three-year goals for the company a few years ago that have been pretty helpful to have as an anchoring. We have not made a five-year goal. But the thing I'm very excited about right now and what we're doing is, again, like, live is a small example. The market for live itself is much bigger than the market that traditionally Wistia has been in, and just in terms of video hosting, which itself has always grown a lot over the years. And it's itself a big market, as is video recording and creating video.

+ +

So we have entered into a bunch of new markets that are all really quite large. And it's pretty humbling to be in a spot where I feel like we have a really solid base with a lot of in-depth knowledge of marketing and our customer to be able to build a really excellent product for that set. We're playing in a much bigger market than I ever thought we would.

+ +

VICTORIA: It's like, success already achieved.

+ +

[laughter]

+ +

BRENDAN: Well, I don't know. It doesn't feel that way. It doesn't feel that way. But -- [laughs]

+ +

VICTORIA: Maybe next time you come on the podcast, you'll have another success story to share with us. [laughs]

+ +

BRENDAN: I hope so. Yeah, I feel like that's always the case, right? It's like, yeah, there are moments where we're certainly very proud of what we've been able to achieve. But most of my time is spent [laughs] in the headspace of, you know, why are we so slow? Why is the product not good enough? Why are we, you know, like, all the stuff that's going wrong, right? Which drives you to be better and is exciting.

+ +

VICTORIA: Right. That makes sense. Well, hopefully, this helps remind you all the good stuff that you all have done so far, too.

+ +

BRENDAN: [laughs]

+ +

VICTORIA: I'm really excited to hear about just how your values drive your decisions and then how that goes to the rest of the team and how closely you're listening to your customers, too, on the product. I think those are all just really great cultural examples and ways to build great products. So, thank you for sharing your story with me.

+ +

And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. And if you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter at @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brendan Schwartz.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+A_44VqjV + + ]]> + + Victoria Guido + Brendan Schwartz + + + 478: Senga with Agnes Malatinszky + https://podcast.thoughtbot.com/478 + 9ca7e172-0891-4c34-89e2-52a8a924b2da + Thu, 08 Jun 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Agnes Malatinszky is the Founder of Senga, which takes care of back-office administrative needs for freelancers, contractors, and solopreneurs. + +Victoria and Will interview Agnes about the thoughtbot Incubator program and what led Agnes to choose to apply, what the demands on her time were like, how it worked, and how she feels now that she's at the end of the program. + 22:00 + no + + + Agnes Malatinszky is the Founder of Senga, which takes care of back-office administrative needs for freelancers, contractors, and solopreneurs. +Victoria and Will interview Agnes about the thoughtbot Incubator program and what led Agnes to choose to apply, what the demands on her time were like, how it worked, and how she feels now that she's at the end of the program. +Senga (https://www.senga.app/) +Follow Agnes Malatinszky on LinkedIn (https://www.linkedin.com/in/agnes-malatinszky/) or Twitter (https://twitter.com/agnesmalatin). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: I'm your other host, Victoria Guido. And with me today is Agnes Malatinszky, Founder of Senga, providing back-end support for freelancers. Agnes, thank you for joining me. +AGNES: Hey, it's a pleasure to be here. +VICTORIA: You are the first graduate of thoughtbot's incubator program, and I'm really excited to dive into that with you today. So, before we get started in talking about the incubator program, let's just start with what fun thing do you have going on this week? +AGNES: I'm based in Washington, D.C., and it's a beautiful time of year here. Early summer, late spring is gorgeous. So I'm excited because my family and I are actually headed out to Harpers Ferry this weekend for a little hike. So I'm looking forward to that. +WILL: So, what is...when you say a hike, can you explain it to anybody that's outside of the D.C. area? +AGNES: It's just a beautiful area in West Virginia. And we're going to take our dog and my daughter out there and get some fresh air and walk around. There's a little historic town there as well that's really interesting to explore. +WILL: That sounds fun. +VICTORIA: Yeah. I've been to Harpers Ferry to go floating, like, on the river. +AGNES: Yes. +VICTORIA: Where you float down the river in inner tubes and drink beverages. [laughter] There's also...there's rock climbing in Harpers Ferry too, which is sometimes closed for bird nesting. So it is really beautiful. +AGNES: Ooh, I didn't know that. That's really cool. We'll keep an eye out for that. +WILL: Yes. For anybody that doesn't know, Victoria is an amazing rock climber. I have a lot of respect for her because I don't know if I could do it. [laughter] +VICTORIA: You could definitely do it. The next thoughtbot trip that we're on, we'll go rock climbing, Will. I'm confident in your skills. You could do it. Yes, I'm a big rock climber and rock-climbing advocate, so I'll talk about it forever if you let me. +WILL: [laughs] +VICTORIA: And I'm actually going to go rock climbing this weekend and get outside myself. And we're going up to Mammoth, California. And we're going to do a half-climbing, half-ski trip. +WILL: Ooh. +VICTORIA: So that's going to be fun for Memorial Day weekend, so...What about you, Will? What do you have going on fun this week? +WILL: Yeah. So you said skiing. +VICTORIA: Yes. So Mammoth got the most snow in the country this year. When we were there in February, they'd already had, like, 10 feet of snow. And then they got another foot of snow while we were there, so they're going to have snow through August, at least. +WILL: August. Wow. Here in South Florida, the lowest we got was 50. So snow, I don't even know what you're talking about. [laughs] Yeah, so you asked what I'm going to do. Last week was a big week for us because my boys they turned four years old and one year old. And we took them to Disney and had a blast. Anybody who's been to Disney knows it's a trip. It could be a lot, especially it was very hot there too. So I think this weekend we're just going to take it easy. We're just going to relax and just enjoy it. +VICTORIA: Trip of a lifetime for them, I'm sure. +WILL: Yes, they loved it. +VICTORIA: We have Disneyland over here in California. I have been to Disney World in Florida. But I still haven't been to Disneyland since I've been here, [laughs] which I think some people would judge me for. +AGNES: You know what? I haven't been to either. I hold it against my parents forever. [laughter] Although my family is not a big fan of crowds, so I think that's why. +WILL: Yes, if you're not a fan of crowds, Disney is not the place, especially now. I've heard around September is probably the best time to go. So we're going to try that out during that time too. +AGNES: Ooh, protip. You heard it here first. +WILL: Yes. [laughs] +VICTORIA: September, Disneyland, Florida sounds very warm to me. [laughs] But yeah, we're actually going to go to Mexico with thoughtbot as a team meetup in September, which is also going to be pretty warm, I think. [laughs] But it'll be fun. Well, that's lovely. I love getting to hear a little bit about your lives before we dig into your business. +Agnes, I'm super excited to hear about Senga. But maybe start with just a little bit about your background before you started. +AGNES: I had been thinking about starting my own business for a while. I am an immigrant, and I come from an entrepreneurial family. Actually, my mom ran her own translation business back in Hungary, and now she's a really successful artist. So, you know, I had support from them and my husband as well to sort of try out something new. +But, in my last role, I was actually Chief Operating Officer at an EdTech company that had scaled to serve over 80% of U.S. schools during the pandemic. And I was at that company for about five years and had seen the full arc of, you know, startup to a mature organization. So I was ready to take on a new challenge and to learn something new. +WILL: You mentioned that your mom was an entrepreneur. And my dad was an entrepreneur, also. He had his own electric and HVAC business, and I learned so much from him. Is there anything that you can just, like, ooh, I learned this and this from my mom as a kid, looking at your mom being an entrepreneur? +AGNES: I mean, she is just a, you know, fix-it person in every sense of the word. So she will fix an electric outlet. She will fix something with her business. +WILL: [laughs] +AGNES: She's just, like, really good at getting her hands dirty and being really scrappy. And I think that's a really important skill to have, you know, especially in a startup, and especially when you're starting out and still on your own. +VICTORIA: So, what did your parents say when you told them you were going to start out on your own and build your own company? +AGNES: They were really encouraging. They, you know, they keep up with all my LinkedIn posts, and they read everything I publish. So they're just very supportive and the best cheerleaders I could possibly hope for. [laughs] +WILL: Did stepping out and starting your business did anything scare you in that area? +AGNES: Oh my gosh, every day, something new. It's all just uncertainty and risk at this point. You know, I'm very, very early in my startup journey, so literally every question about the business I have to test. I have to find answers for. And that ranges everything from, you know, business formation to, you know, the nuts and bolts of getting the business organized and setting up financials, and the legal structure for the company, to figuring out what the product is going to be. So all this uncertainty is definitely a little bit nerve-racking. +VICTORIA: And I'm wondering, what about your past experience as a Chief Operations Officer led you to want to build a product like Senga? +AGNES: So being a Chief Operating Officer, I think one of the things that I really learned was that in order for a business to be really successful, and for people working at that company to be really successful, they have to have the organization's support to do what they do best. You know, what I used to tell my operations team was that you know, we were really the plumbers of the organization, making sure that everything ran smoothly behind the scenes. +So, actually, that was one of the inspirations for Senga, for my current company, this idea that freelancers and independent workers don't have that support. They don't necessarily have somebody helping them with HR, and with financials, and with legal stuff, and with everything else that goes into running a business, whether you're a business of 1 or a business of 100. And that's really where I wanted to come in and, you know, support independent workers. +VICTORIA: One follow-up question for Agnes on your experience in the COO role. I believe your team also had a lot of background in the freelancing world. So you had people you could ask questions to and start to understand that market. Is that right? +AGNES: Yeah. Like a lot of businesses, I guess we had, you know, freelancers and contract workers that we relied on. And that's increasingly true for most companies now, I would say. There's specialized roles. There is seasonal roles that you don't necessarily hire full-time employees for but that are perfect for somebody, you know, on a temporary basis or somebody with more specialized skills. So you're exactly right; being able to tap into that network and having had experience working with freelancers and contractors was really helpful coming into the incubator and having people to tap for interviews and for input. +VICTORIA: Great. And then, what is the thoughtbot incubator, which we've mentioned a few times already? It is for a non-technical founding team with a business idea that involves a web or a mobile app. It's an eight-week program that helps you get the proof points you need in order to move forward with confidence. So I'm curious, Agnes, what led you to choose the thoughtbot incubator Program as something you wanted to apply to? +AGNES: I mean, it's exactly what you named. So this incubator program was really a perfect launching pad for me. It's designed for non-technical founders, like myself, to get their own dedicated team of product and dev experts to, you know, like, hone customer discovery practice, create a product strategy, run proof of concept experiments. And, you know, these were exactly the areas where I lacked skills and expertise the most. So I had actually looked at other incubators and even some venture studios before, but those models were not as good of a fit for me. I was really excited to find and to be able to join thoughtbot's incubator program. +MID-ROLL AD: +Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. +Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff. +WILL: What was the original idea behind Senga? +AGNES: The idea that I came into the incubator with and then the pain points that we honed in on during the incubator, and then the long-term vision for the company are all kind of a little bit different. So I'll zoom out first to the sort of 30,000-foot view of this. +So, coming into the incubator, I had been reading and researching a lot about some macro trends that I think are really interesting, and these are trends that many of us are keeping an eye on. So they're nothing revolutionary, but I think they're going to create some really interesting problems to solve in the next couple of years. So the first one is the rise of independent workers, or contractors, or freelancers. I'm kind of going to use these terms interchangeably. +In recent years, the number of independent workers has shot up like crazy. There are already over 65 million independent workers in the U.S., and this number is growing by about 25% annually. And then, add to this that economic downturns tend to grow this number even more. You know, this makes up about a third of the workforce in the U.S. already, and it's growing. +The second thing is that you know, the fact that early-career folks, especially Gen Z, really like the independence and autonomy that comes with this type of work. Over half of Gen Z already freelance, and the majority want to make independent work their career. In other words, they explicitly do not want to work for a company in the traditional sense. +And then, third, there's kind of a mishmash of factors that I'll lump into one bullet that additionally drive up this type of work, which is that, increasingly, jobs are going to be skills-based, not degree-based, and all work, even white-collar work, will become more modular. Both tech advances and even, I think, novel organizational structures are going to make it possible for people to hyper-specialize and to plug into different organizations at different times, and, you know, even simultaneously to perform that specialized work. +So take all this together, and what I'm really seeing is that the current market offerings serving freelancers and contractors are not nearly enough to meet all their needs, which is driving huge inefficiency. The types of companies that cater to this segment now or, you know, there's mature marketplaces like Upwork, and Fiverr, and some earlier-stage companies that do, you know, more workflow and back office. But I'm not seeing a comprehensive solution, and that's driving like I said, a lot of inefficiency. So, ultimately, being a freelancer is still really hard. Only about 50% of a freelancer's time is spent on billable work. And so this is what I really want to solve. +VICTORIA: And did anything change through the incubator process? +AGNES: So the biggest thing I found during the incubator was actually a really good entry point into this market. So startup wisdom says that you have to narrow down your product to a super tight segment that has a very strong, like, yes to your product. So, during the course of the eight weeks that I did the incubator, we did a ton of interviews, and I was really on the lookout for big spikes and pain points that repeated for a specific niche of freelancers. And that's exactly what we ended up finding. +There's lots of nuance to this, but generally speaking, people new to freelancing and those that are just looking to get started need help getting started in a more manageable way and then setting up good practices that will serve them in the long run. +WILL: You mentioned those practices that helps them set them up in the long run. Are you talking about mostly the operation, so, like, anything that's non-billable for a client? +AGNES: Exactly, yeah. So that's kind of how I think about the work is anything that's billable and then anything that's non-billable. So that includes client management, client communication, marketing themselves, finding, you know, new work, so drumming up new business, all the back-office financials, back-office legal and admin stuff. All these other things that traditionally would be, you know, done by, you know, an operations team at a big company, but, for freelancers, they have to do it themselves. +WILL: Yeah, I love that idea because my spouse she dipped her toe into the freelance world. And I felt like the operations kind of overcame everything else. And so it almost felt like the operations was taking over the job. But it's one of those things I feel like we didn't really think through of how much work that that 50% is. Like, how much work do you have to do, which are taxes, operations, speaking to clients, even to get to the things that people usually love, like the design, the software development? So I'm excited about this product. +AGNES: Yeah, exactly. And that's kind of what I kept hearing again and again in interviews with all sorts of different freelancers because we went out and interviewed folks from, you know, everywhere from graphic design, to UX/UI design, to web developers, to other types of creatives, content creators. And this idea that they all get into freelancing to pursue their passion, the thing that they're uniquely good at. But then end up spending a huge chunk of their time on, you know, things that they're not really specialized in, you know, basically running their business. +VICTORIA: What types of experiments did you run while you were in the incubator program with the people you mentioned you're talking to? And what were the demands on your time really like? +AGNES: Oh, so the program is between 20 to 40 hours a week. I had a chance to meet with my thoughtbot team daily. We had independent work time, also breakout sessions. Like you said, a lot of that time was spent doing interviews and running all sorts of different experiments, so discovery interviews, interviews showing the prototype once we had it to interviewees. But we also set up Google Ads. We created a landing page with various calls to action. And then based on who was coming through the landing page and what they were doing on the site, we had all sorts of, you know, lessons that we could take away from that. +And then another piece of it was I also learned how to basically start building out an organic community around this problem and from, you know, the community of freelancers, which is so important to have, like, for a future user base and also to be able to continue to engage with my target audience. +WILL: Was there anything that surprised you about the program, or did you have any interesting findings coming out of the program? +AGNES: One thing I learned through the program was that you know, there are concrete steps that you can take and a process that you can follow to build out a strong business that solves real problems for people. And that's really what this program and this incubator is focused on, is to teach you those skills to go through those early steps. +You know, everything that I had read before about startups they're kind of clouded in mystery. And, you know, the big ones that end up being really successful tend to be mythologized, and founder stories tend to have these, like, big eureka moments in them, where the founder had their big idea that led to the big company. But really, at the early stage, it's pretty messy. And nevertheless, you have these steps that you can follow and processes that you can follow to build out the company. +VICTORIA: And how are you feeling now at the end of the program? +AGNES: I feel really excited and, frankly, more confident than I came into the program. So, you know, I'm leaving here with lots of good data, lots of good anecdotal evidence, having had dozens and dozens of conversations with my target market. So, for me, that's a really great feeling to know that my ideas they don't just exist in the abstract in my head but that we've bounced them against the universe and confirmed that folks are having the pain points that we expected and some that we did not expect. And that there is an opportunity around this. +WILL: So, what could be done better about the incubator program from your perspective? +AGNES: It was a great program, and that's a pretty hard question to answer. But, you know, I would selfishly say make it longer. Eight weeks is, by design, you know, a pretty short time to get started. And that's really what the program is designed to do is to get you started, to set you up with good practices and good tools. But, again, selfishly, I wish it were a little bit longer, so I can stick around and have the thoughtbot team around me. +And then I just look forward to building more of a community as more founders join thoughtbot's incubator every quarter. We have a shared Slack channel that I'm going to continue hanging out in and that I've been told the new founders, as well, will be added to. So I'm looking forward to getting to meet them and to, you know, hear about their experience as well. +VICTORIA: What's coming up next for you in the next six months? +AGNES: So I'm talking to a couple of potential partners in the next couple of weeks, which might kind of change the roadmap slightly. But, basically, this summer and fall, I'm building out a lot of the content and the prototype for Senga. Again, continuing to talk to the freelancers I've been continuing to talk to. I'm also putting together sort of, like, an advisory committee of freelancers I've met along the way who had a strong yes sort of reaction to this product. And then my goal is that by fall or winter, I'll be able to start building out an MVP. +WILL: That's exciting. +AGNES: Yeah, I'm really excited. [laughs] +WILL: Your dream is finally coming true, so, yeah, you have something to be excited about. [laughs] Do you have any advice for any other founders? +AGNES: I guess I don't know how qualified I feel to be, you know, handing out advice as a brand-new founder. But, overall, I would encourage others out there who are interested in taking this path to, you know, really take a risk and to bet on themselves. What I've found in the last couple of months is that there are so many supportive communities, and founder groups, and entrepreneur groups. +And this is kind of common advice, and everybody says this, but there's really no way you can fully prepare. You just kind of have to start doing. And at least from what I've seen, that's the secret sauce to this early stage is to keep doing and to keep going from one step to the next every day. +VICTORIA: If you could travel back in time and give yourself advice from when before this all started, what advice would you give yourself? +AGNES: I would just encourage myself to, you know, take the plunge and maybe even go down this path sooner. You know, I feel really confident where I'm at now in terms of my career and my, you know, support networks and everything. But being able to go back and start experimenting earlier and start going down this path earlier might have even set me up better. +WILL: One thing when you're starting a startup is funding. Are you looking for any funding? +AGNES: Not urgently, but I'm definitely interested in talking to others working and investing in this space. So, you know, if any of your listeners are investors or entrepreneurs in a similar space, I would love to talk to them. +WILL: Yeah. So, how could they reach you if they wanted to reach out to you? +AGNES: You can reach me by email at hello@senga.app, or you can find us on LinkedIn at Senga. +VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You could find me on Twitter @victori_ousg. +WILL: And you can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + Special Guest: Agnes Malatinszky. + + + Agnes Malatinszky is the Founder of Senga, which takes care of back-office administrative needs for freelancers, contractors, and solopreneurs.

+ +

Victoria and Will interview Agnes about the thoughtbot Incubator program and what led Agnes to choose to apply, what the demands on her time were like, how it worked, and how she feels now that she's at the end of the program.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: I'm your other host, Victoria Guido. And with me today is Agnes Malatinszky, Founder of Senga, providing back-end support for freelancers. Agnes, thank you for joining me.

+ +

AGNES: Hey, it's a pleasure to be here.

+ +

VICTORIA: You are the first graduate of thoughtbot's incubator program, and I'm really excited to dive into that with you today. So, before we get started in talking about the incubator program, let's just start with what fun thing do you have going on this week?

+ +

AGNES: I'm based in Washington, D.C., and it's a beautiful time of year here. Early summer, late spring is gorgeous. So I'm excited because my family and I are actually headed out to Harpers Ferry this weekend for a little hike. So I'm looking forward to that.

+ +

WILL: So, what is...when you say a hike, can you explain it to anybody that's outside of the D.C. area?

+ +

AGNES: It's just a beautiful area in West Virginia. And we're going to take our dog and my daughter out there and get some fresh air and walk around. There's a little historic town there as well that's really interesting to explore.

+ +

WILL: That sounds fun.

+ +

VICTORIA: Yeah. I've been to Harpers Ferry to go floating, like, on the river.

+ +

AGNES: Yes.

+ +

VICTORIA: Where you float down the river in inner tubes and drink beverages. [laughter] There's also...there's rock climbing in Harpers Ferry too, which is sometimes closed for bird nesting. So it is really beautiful.

+ +

AGNES: Ooh, I didn't know that. That's really cool. We'll keep an eye out for that.

+ +

WILL: Yes. For anybody that doesn't know, Victoria is an amazing rock climber. I have a lot of respect for her because I don't know if I could do it. [laughter]

+ +

VICTORIA: You could definitely do it. The next thoughtbot trip that we're on, we'll go rock climbing, Will. I'm confident in your skills. You could do it. Yes, I'm a big rock climber and rock-climbing advocate, so I'll talk about it forever if you let me.

+ +

WILL: [laughs]

+ +

VICTORIA: And I'm actually going to go rock climbing this weekend and get outside myself. And we're going up to Mammoth, California. And we're going to do a half-climbing, half-ski trip.

+ +

WILL: Ooh.

+ +

VICTORIA: So that's going to be fun for Memorial Day weekend, so...What about you, Will? What do you have going on fun this week?

+ +

WILL: Yeah. So you said skiing.

+ +

VICTORIA: Yes. So Mammoth got the most snow in the country this year. When we were there in February, they'd already had, like, 10 feet of snow. And then they got another foot of snow while we were there, so they're going to have snow through August, at least.

+ +

WILL: August. Wow. Here in South Florida, the lowest we got was 50. So snow, I don't even know what you're talking about. [laughs] Yeah, so you asked what I'm going to do. Last week was a big week for us because my boys they turned four years old and one year old. And we took them to Disney and had a blast. Anybody who's been to Disney knows it's a trip. It could be a lot, especially it was very hot there too. So I think this weekend we're just going to take it easy. We're just going to relax and just enjoy it.

+ +

VICTORIA: Trip of a lifetime for them, I'm sure.

+ +

WILL: Yes, they loved it.

+ +

VICTORIA: We have Disneyland over here in California. I have been to Disney World in Florida. But I still haven't been to Disneyland since I've been here, [laughs] which I think some people would judge me for.

+ +

AGNES: You know what? I haven't been to either. I hold it against my parents forever. [laughter] Although my family is not a big fan of crowds, so I think that's why.

+ +

WILL: Yes, if you're not a fan of crowds, Disney is not the place, especially now. I've heard around September is probably the best time to go. So we're going to try that out during that time too.

+ +

AGNES: Ooh, protip. You heard it here first.

+ +

WILL: Yes. [laughs]

+ +

VICTORIA: September, Disneyland, Florida sounds very warm to me. [laughs] But yeah, we're actually going to go to Mexico with thoughtbot as a team meetup in September, which is also going to be pretty warm, I think. [laughs] But it'll be fun. Well, that's lovely. I love getting to hear a little bit about your lives before we dig into your business.

+ +

Agnes, I'm super excited to hear about Senga. But maybe start with just a little bit about your background before you started.

+ +

AGNES: I had been thinking about starting my own business for a while. I am an immigrant, and I come from an entrepreneurial family. Actually, my mom ran her own translation business back in Hungary, and now she's a really successful artist. So, you know, I had support from them and my husband as well to sort of try out something new.

+ +

But, in my last role, I was actually Chief Operating Officer at an EdTech company that had scaled to serve over 80% of U.S. schools during the pandemic. And I was at that company for about five years and had seen the full arc of, you know, startup to a mature organization. So I was ready to take on a new challenge and to learn something new.

+ +

WILL: You mentioned that your mom was an entrepreneur. And my dad was an entrepreneur, also. He had his own electric and HVAC business, and I learned so much from him. Is there anything that you can just, like, ooh, I learned this and this from my mom as a kid, looking at your mom being an entrepreneur?

+ +

AGNES: I mean, she is just a, you know, fix-it person in every sense of the word. So she will fix an electric outlet. She will fix something with her business.

+ +

WILL: [laughs]

+ +

AGNES: She's just, like, really good at getting her hands dirty and being really scrappy. And I think that's a really important skill to have, you know, especially in a startup, and especially when you're starting out and still on your own.

+ +

VICTORIA: So, what did your parents say when you told them you were going to start out on your own and build your own company?

+ +

AGNES: They were really encouraging. They, you know, they keep up with all my LinkedIn posts, and they read everything I publish. So they're just very supportive and the best cheerleaders I could possibly hope for. [laughs]

+ +

WILL: Did stepping out and starting your business did anything scare you in that area?

+ +

AGNES: Oh my gosh, every day, something new. It's all just uncertainty and risk at this point. You know, I'm very, very early in my startup journey, so literally every question about the business I have to test. I have to find answers for. And that ranges everything from, you know, business formation to, you know, the nuts and bolts of getting the business organized and setting up financials, and the legal structure for the company, to figuring out what the product is going to be. So all this uncertainty is definitely a little bit nerve-racking.

+ +

VICTORIA: And I'm wondering, what about your past experience as a Chief Operations Officer led you to want to build a product like Senga?

+ +

AGNES: So being a Chief Operating Officer, I think one of the things that I really learned was that in order for a business to be really successful, and for people working at that company to be really successful, they have to have the organization's support to do what they do best. You know, what I used to tell my operations team was that you know, we were really the plumbers of the organization, making sure that everything ran smoothly behind the scenes.

+ +

So, actually, that was one of the inspirations for Senga, for my current company, this idea that freelancers and independent workers don't have that support. They don't necessarily have somebody helping them with HR, and with financials, and with legal stuff, and with everything else that goes into running a business, whether you're a business of 1 or a business of 100. And that's really where I wanted to come in and, you know, support independent workers.

+ +

VICTORIA: One follow-up question for Agnes on your experience in the COO role. I believe your team also had a lot of background in the freelancing world. So you had people you could ask questions to and start to understand that market. Is that right?

+ +

AGNES: Yeah. Like a lot of businesses, I guess we had, you know, freelancers and contract workers that we relied on. And that's increasingly true for most companies now, I would say. There's specialized roles. There is seasonal roles that you don't necessarily hire full-time employees for but that are perfect for somebody, you know, on a temporary basis or somebody with more specialized skills. So you're exactly right; being able to tap into that network and having had experience working with freelancers and contractors was really helpful coming into the incubator and having people to tap for interviews and for input.

+ +

VICTORIA: Great. And then, what is the thoughtbot incubator, which we've mentioned a few times already? It is for a non-technical founding team with a business idea that involves a web or a mobile app. It's an eight-week program that helps you get the proof points you need in order to move forward with confidence. So I'm curious, Agnes, what led you to choose the thoughtbot incubator Program as something you wanted to apply to?

+ +

AGNES: I mean, it's exactly what you named. So this incubator program was really a perfect launching pad for me. It's designed for non-technical founders, like myself, to get their own dedicated team of product and dev experts to, you know, like, hone customer discovery practice, create a product strategy, run proof of concept experiments. And, you know, these were exactly the areas where I lacked skills and expertise the most. So I had actually looked at other incubators and even some venture studios before, but those models were not as good of a fit for me. I was really excited to find and to be able to join thoughtbot's incubator program.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff.

+ +

WILL: What was the original idea behind Senga?

+ +

AGNES: The idea that I came into the incubator with and then the pain points that we honed in on during the incubator, and then the long-term vision for the company are all kind of a little bit different. So I'll zoom out first to the sort of 30,000-foot view of this.

+ +

So, coming into the incubator, I had been reading and researching a lot about some macro trends that I think are really interesting, and these are trends that many of us are keeping an eye on. So they're nothing revolutionary, but I think they're going to create some really interesting problems to solve in the next couple of years. So the first one is the rise of independent workers, or contractors, or freelancers. I'm kind of going to use these terms interchangeably.

+ +

In recent years, the number of independent workers has shot up like crazy. There are already over 65 million independent workers in the U.S., and this number is growing by about 25% annually. And then, add to this that economic downturns tend to grow this number even more. You know, this makes up about a third of the workforce in the U.S. already, and it's growing.

+ +

The second thing is that you know, the fact that early-career folks, especially Gen Z, really like the independence and autonomy that comes with this type of work. Over half of Gen Z already freelance, and the majority want to make independent work their career. In other words, they explicitly do not want to work for a company in the traditional sense.

+ +

And then, third, there's kind of a mishmash of factors that I'll lump into one bullet that additionally drive up this type of work, which is that, increasingly, jobs are going to be skills-based, not degree-based, and all work, even white-collar work, will become more modular. Both tech advances and even, I think, novel organizational structures are going to make it possible for people to hyper-specialize and to plug into different organizations at different times, and, you know, even simultaneously to perform that specialized work.

+ +

So take all this together, and what I'm really seeing is that the current market offerings serving freelancers and contractors are not nearly enough to meet all their needs, which is driving huge inefficiency. The types of companies that cater to this segment now or, you know, there's mature marketplaces like Upwork, and Fiverr, and some earlier-stage companies that do, you know, more workflow and back office. But I'm not seeing a comprehensive solution, and that's driving like I said, a lot of inefficiency. So, ultimately, being a freelancer is still really hard. Only about 50% of a freelancer's time is spent on billable work. And so this is what I really want to solve.

+ +

VICTORIA: And did anything change through the incubator process?

+ +

AGNES: So the biggest thing I found during the incubator was actually a really good entry point into this market. So startup wisdom says that you have to narrow down your product to a super tight segment that has a very strong, like, yes to your product. So, during the course of the eight weeks that I did the incubator, we did a ton of interviews, and I was really on the lookout for big spikes and pain points that repeated for a specific niche of freelancers. And that's exactly what we ended up finding.

+ +

There's lots of nuance to this, but generally speaking, people new to freelancing and those that are just looking to get started need help getting started in a more manageable way and then setting up good practices that will serve them in the long run.

+ +

WILL: You mentioned those practices that helps them set them up in the long run. Are you talking about mostly the operation, so, like, anything that's non-billable for a client?

+ +

AGNES: Exactly, yeah. So that's kind of how I think about the work is anything that's billable and then anything that's non-billable. So that includes client management, client communication, marketing themselves, finding, you know, new work, so drumming up new business, all the back-office financials, back-office legal and admin stuff. All these other things that traditionally would be, you know, done by, you know, an operations team at a big company, but, for freelancers, they have to do it themselves.

+ +

WILL: Yeah, I love that idea because my spouse she dipped her toe into the freelance world. And I felt like the operations kind of overcame everything else. And so it almost felt like the operations was taking over the job. But it's one of those things I feel like we didn't really think through of how much work that that 50% is. Like, how much work do you have to do, which are taxes, operations, speaking to clients, even to get to the things that people usually love, like the design, the software development? So I'm excited about this product.

+ +

AGNES: Yeah, exactly. And that's kind of what I kept hearing again and again in interviews with all sorts of different freelancers because we went out and interviewed folks from, you know, everywhere from graphic design, to UX/UI design, to web developers, to other types of creatives, content creators. And this idea that they all get into freelancing to pursue their passion, the thing that they're uniquely good at. But then end up spending a huge chunk of their time on, you know, things that they're not really specialized in, you know, basically running their business.

+ +

VICTORIA: What types of experiments did you run while you were in the incubator program with the people you mentioned you're talking to? And what were the demands on your time really like?

+ +

AGNES: Oh, so the program is between 20 to 40 hours a week. I had a chance to meet with my thoughtbot team daily. We had independent work time, also breakout sessions. Like you said, a lot of that time was spent doing interviews and running all sorts of different experiments, so discovery interviews, interviews showing the prototype once we had it to interviewees. But we also set up Google Ads. We created a landing page with various calls to action. And then based on who was coming through the landing page and what they were doing on the site, we had all sorts of, you know, lessons that we could take away from that.

+ +

And then another piece of it was I also learned how to basically start building out an organic community around this problem and from, you know, the community of freelancers, which is so important to have, like, for a future user base and also to be able to continue to engage with my target audience.

+ +

WILL: Was there anything that surprised you about the program, or did you have any interesting findings coming out of the program?

+ +

AGNES: One thing I learned through the program was that you know, there are concrete steps that you can take and a process that you can follow to build out a strong business that solves real problems for people. And that's really what this program and this incubator is focused on, is to teach you those skills to go through those early steps.

+ +

You know, everything that I had read before about startups they're kind of clouded in mystery. And, you know, the big ones that end up being really successful tend to be mythologized, and founder stories tend to have these, like, big eureka moments in them, where the founder had their big idea that led to the big company. But really, at the early stage, it's pretty messy. And nevertheless, you have these steps that you can follow and processes that you can follow to build out the company.

+ +

VICTORIA: And how are you feeling now at the end of the program?

+ +

AGNES: I feel really excited and, frankly, more confident than I came into the program. So, you know, I'm leaving here with lots of good data, lots of good anecdotal evidence, having had dozens and dozens of conversations with my target market. So, for me, that's a really great feeling to know that my ideas they don't just exist in the abstract in my head but that we've bounced them against the universe and confirmed that folks are having the pain points that we expected and some that we did not expect. And that there is an opportunity around this.

+ +

WILL: So, what could be done better about the incubator program from your perspective?

+ +

AGNES: It was a great program, and that's a pretty hard question to answer. But, you know, I would selfishly say make it longer. Eight weeks is, by design, you know, a pretty short time to get started. And that's really what the program is designed to do is to get you started, to set you up with good practices and good tools. But, again, selfishly, I wish it were a little bit longer, so I can stick around and have the thoughtbot team around me.

+ +

And then I just look forward to building more of a community as more founders join thoughtbot's incubator every quarter. We have a shared Slack channel that I'm going to continue hanging out in and that I've been told the new founders, as well, will be added to. So I'm looking forward to getting to meet them and to, you know, hear about their experience as well.

+ +

VICTORIA: What's coming up next for you in the next six months?

+ +

AGNES: So I'm talking to a couple of potential partners in the next couple of weeks, which might kind of change the roadmap slightly. But, basically, this summer and fall, I'm building out a lot of the content and the prototype for Senga. Again, continuing to talk to the freelancers I've been continuing to talk to. I'm also putting together sort of, like, an advisory committee of freelancers I've met along the way who had a strong yes sort of reaction to this product. And then my goal is that by fall or winter, I'll be able to start building out an MVP.

+ +

WILL: That's exciting.

+ +

AGNES: Yeah, I'm really excited. [laughs]

+ +

WILL: Your dream is finally coming true, so, yeah, you have something to be excited about. [laughs] Do you have any advice for any other founders?

+ +

AGNES: I guess I don't know how qualified I feel to be, you know, handing out advice as a brand-new founder. But, overall, I would encourage others out there who are interested in taking this path to, you know, really take a risk and to bet on themselves. What I've found in the last couple of months is that there are so many supportive communities, and founder groups, and entrepreneur groups.

+ +

And this is kind of common advice, and everybody says this, but there's really no way you can fully prepare. You just kind of have to start doing. And at least from what I've seen, that's the secret sauce to this early stage is to keep doing and to keep going from one step to the next every day.

+ +

VICTORIA: If you could travel back in time and give yourself advice from when before this all started, what advice would you give yourself?

+ +

AGNES: I would just encourage myself to, you know, take the plunge and maybe even go down this path sooner. You know, I feel really confident where I'm at now in terms of my career and my, you know, support networks and everything. But being able to go back and start experimenting earlier and start going down this path earlier might have even set me up better.

+ +

WILL: One thing when you're starting a startup is funding. Are you looking for any funding?

+ +

AGNES: Not urgently, but I'm definitely interested in talking to others working and investing in this space. So, you know, if any of your listeners are investors or entrepreneurs in a similar space, I would love to talk to them.

+ +

WILL: Yeah. So, how could they reach you if they wanted to reach out to you?

+ +

AGNES: You can reach me by email at hello@senga.app, or you can find us on LinkedIn at Senga.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You could find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Agnes Malatinszky.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Agnes Malatinszky is the Founder of Senga, which takes care of back-office administrative needs for freelancers, contractors, and solopreneurs.

+ +

Victoria and Will interview Agnes about the thoughtbot Incubator program and what led Agnes to choose to apply, what the demands on her time were like, how it worked, and how she feels now that she's at the end of the program.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: I'm your other host, Victoria Guido. And with me today is Agnes Malatinszky, Founder of Senga, providing back-end support for freelancers. Agnes, thank you for joining me.

+ +

AGNES: Hey, it's a pleasure to be here.

+ +

VICTORIA: You are the first graduate of thoughtbot's incubator program, and I'm really excited to dive into that with you today. So, before we get started in talking about the incubator program, let's just start with what fun thing do you have going on this week?

+ +

AGNES: I'm based in Washington, D.C., and it's a beautiful time of year here. Early summer, late spring is gorgeous. So I'm excited because my family and I are actually headed out to Harpers Ferry this weekend for a little hike. So I'm looking forward to that.

+ +

WILL: So, what is...when you say a hike, can you explain it to anybody that's outside of the D.C. area?

+ +

AGNES: It's just a beautiful area in West Virginia. And we're going to take our dog and my daughter out there and get some fresh air and walk around. There's a little historic town there as well that's really interesting to explore.

+ +

WILL: That sounds fun.

+ +

VICTORIA: Yeah. I've been to Harpers Ferry to go floating, like, on the river.

+ +

AGNES: Yes.

+ +

VICTORIA: Where you float down the river in inner tubes and drink beverages. [laughter] There's also...there's rock climbing in Harpers Ferry too, which is sometimes closed for bird nesting. So it is really beautiful.

+ +

AGNES: Ooh, I didn't know that. That's really cool. We'll keep an eye out for that.

+ +

WILL: Yes. For anybody that doesn't know, Victoria is an amazing rock climber. I have a lot of respect for her because I don't know if I could do it. [laughter]

+ +

VICTORIA: You could definitely do it. The next thoughtbot trip that we're on, we'll go rock climbing, Will. I'm confident in your skills. You could do it. Yes, I'm a big rock climber and rock-climbing advocate, so I'll talk about it forever if you let me.

+ +

WILL: [laughs]

+ +

VICTORIA: And I'm actually going to go rock climbing this weekend and get outside myself. And we're going up to Mammoth, California. And we're going to do a half-climbing, half-ski trip.

+ +

WILL: Ooh.

+ +

VICTORIA: So that's going to be fun for Memorial Day weekend, so...What about you, Will? What do you have going on fun this week?

+ +

WILL: Yeah. So you said skiing.

+ +

VICTORIA: Yes. So Mammoth got the most snow in the country this year. When we were there in February, they'd already had, like, 10 feet of snow. And then they got another foot of snow while we were there, so they're going to have snow through August, at least.

+ +

WILL: August. Wow. Here in South Florida, the lowest we got was 50. So snow, I don't even know what you're talking about. [laughs] Yeah, so you asked what I'm going to do. Last week was a big week for us because my boys they turned four years old and one year old. And we took them to Disney and had a blast. Anybody who's been to Disney knows it's a trip. It could be a lot, especially it was very hot there too. So I think this weekend we're just going to take it easy. We're just going to relax and just enjoy it.

+ +

VICTORIA: Trip of a lifetime for them, I'm sure.

+ +

WILL: Yes, they loved it.

+ +

VICTORIA: We have Disneyland over here in California. I have been to Disney World in Florida. But I still haven't been to Disneyland since I've been here, [laughs] which I think some people would judge me for.

+ +

AGNES: You know what? I haven't been to either. I hold it against my parents forever. [laughter] Although my family is not a big fan of crowds, so I think that's why.

+ +

WILL: Yes, if you're not a fan of crowds, Disney is not the place, especially now. I've heard around September is probably the best time to go. So we're going to try that out during that time too.

+ +

AGNES: Ooh, protip. You heard it here first.

+ +

WILL: Yes. [laughs]

+ +

VICTORIA: September, Disneyland, Florida sounds very warm to me. [laughs] But yeah, we're actually going to go to Mexico with thoughtbot as a team meetup in September, which is also going to be pretty warm, I think. [laughs] But it'll be fun. Well, that's lovely. I love getting to hear a little bit about your lives before we dig into your business.

+ +

Agnes, I'm super excited to hear about Senga. But maybe start with just a little bit about your background before you started.

+ +

AGNES: I had been thinking about starting my own business for a while. I am an immigrant, and I come from an entrepreneurial family. Actually, my mom ran her own translation business back in Hungary, and now she's a really successful artist. So, you know, I had support from them and my husband as well to sort of try out something new.

+ +

But, in my last role, I was actually Chief Operating Officer at an EdTech company that had scaled to serve over 80% of U.S. schools during the pandemic. And I was at that company for about five years and had seen the full arc of, you know, startup to a mature organization. So I was ready to take on a new challenge and to learn something new.

+ +

WILL: You mentioned that your mom was an entrepreneur. And my dad was an entrepreneur, also. He had his own electric and HVAC business, and I learned so much from him. Is there anything that you can just, like, ooh, I learned this and this from my mom as a kid, looking at your mom being an entrepreneur?

+ +

AGNES: I mean, she is just a, you know, fix-it person in every sense of the word. So she will fix an electric outlet. She will fix something with her business.

+ +

WILL: [laughs]

+ +

AGNES: She's just, like, really good at getting her hands dirty and being really scrappy. And I think that's a really important skill to have, you know, especially in a startup, and especially when you're starting out and still on your own.

+ +

VICTORIA: So, what did your parents say when you told them you were going to start out on your own and build your own company?

+ +

AGNES: They were really encouraging. They, you know, they keep up with all my LinkedIn posts, and they read everything I publish. So they're just very supportive and the best cheerleaders I could possibly hope for. [laughs]

+ +

WILL: Did stepping out and starting your business did anything scare you in that area?

+ +

AGNES: Oh my gosh, every day, something new. It's all just uncertainty and risk at this point. You know, I'm very, very early in my startup journey, so literally every question about the business I have to test. I have to find answers for. And that ranges everything from, you know, business formation to, you know, the nuts and bolts of getting the business organized and setting up financials, and the legal structure for the company, to figuring out what the product is going to be. So all this uncertainty is definitely a little bit nerve-racking.

+ +

VICTORIA: And I'm wondering, what about your past experience as a Chief Operations Officer led you to want to build a product like Senga?

+ +

AGNES: So being a Chief Operating Officer, I think one of the things that I really learned was that in order for a business to be really successful, and for people working at that company to be really successful, they have to have the organization's support to do what they do best. You know, what I used to tell my operations team was that you know, we were really the plumbers of the organization, making sure that everything ran smoothly behind the scenes.

+ +

So, actually, that was one of the inspirations for Senga, for my current company, this idea that freelancers and independent workers don't have that support. They don't necessarily have somebody helping them with HR, and with financials, and with legal stuff, and with everything else that goes into running a business, whether you're a business of 1 or a business of 100. And that's really where I wanted to come in and, you know, support independent workers.

+ +

VICTORIA: One follow-up question for Agnes on your experience in the COO role. I believe your team also had a lot of background in the freelancing world. So you had people you could ask questions to and start to understand that market. Is that right?

+ +

AGNES: Yeah. Like a lot of businesses, I guess we had, you know, freelancers and contract workers that we relied on. And that's increasingly true for most companies now, I would say. There's specialized roles. There is seasonal roles that you don't necessarily hire full-time employees for but that are perfect for somebody, you know, on a temporary basis or somebody with more specialized skills. So you're exactly right; being able to tap into that network and having had experience working with freelancers and contractors was really helpful coming into the incubator and having people to tap for interviews and for input.

+ +

VICTORIA: Great. And then, what is the thoughtbot incubator, which we've mentioned a few times already? It is for a non-technical founding team with a business idea that involves a web or a mobile app. It's an eight-week program that helps you get the proof points you need in order to move forward with confidence. So I'm curious, Agnes, what led you to choose the thoughtbot incubator Program as something you wanted to apply to?

+ +

AGNES: I mean, it's exactly what you named. So this incubator program was really a perfect launching pad for me. It's designed for non-technical founders, like myself, to get their own dedicated team of product and dev experts to, you know, like, hone customer discovery practice, create a product strategy, run proof of concept experiments. And, you know, these were exactly the areas where I lacked skills and expertise the most. So I had actually looked at other incubators and even some venture studios before, but those models were not as good of a fit for me. I was really excited to find and to be able to join thoughtbot's incubator program.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff.

+ +

WILL: What was the original idea behind Senga?

+ +

AGNES: The idea that I came into the incubator with and then the pain points that we honed in on during the incubator, and then the long-term vision for the company are all kind of a little bit different. So I'll zoom out first to the sort of 30,000-foot view of this.

+ +

So, coming into the incubator, I had been reading and researching a lot about some macro trends that I think are really interesting, and these are trends that many of us are keeping an eye on. So they're nothing revolutionary, but I think they're going to create some really interesting problems to solve in the next couple of years. So the first one is the rise of independent workers, or contractors, or freelancers. I'm kind of going to use these terms interchangeably.

+ +

In recent years, the number of independent workers has shot up like crazy. There are already over 65 million independent workers in the U.S., and this number is growing by about 25% annually. And then, add to this that economic downturns tend to grow this number even more. You know, this makes up about a third of the workforce in the U.S. already, and it's growing.

+ +

The second thing is that you know, the fact that early-career folks, especially Gen Z, really like the independence and autonomy that comes with this type of work. Over half of Gen Z already freelance, and the majority want to make independent work their career. In other words, they explicitly do not want to work for a company in the traditional sense.

+ +

And then, third, there's kind of a mishmash of factors that I'll lump into one bullet that additionally drive up this type of work, which is that, increasingly, jobs are going to be skills-based, not degree-based, and all work, even white-collar work, will become more modular. Both tech advances and even, I think, novel organizational structures are going to make it possible for people to hyper-specialize and to plug into different organizations at different times, and, you know, even simultaneously to perform that specialized work.

+ +

So take all this together, and what I'm really seeing is that the current market offerings serving freelancers and contractors are not nearly enough to meet all their needs, which is driving huge inefficiency. The types of companies that cater to this segment now or, you know, there's mature marketplaces like Upwork, and Fiverr, and some earlier-stage companies that do, you know, more workflow and back office. But I'm not seeing a comprehensive solution, and that's driving like I said, a lot of inefficiency. So, ultimately, being a freelancer is still really hard. Only about 50% of a freelancer's time is spent on billable work. And so this is what I really want to solve.

+ +

VICTORIA: And did anything change through the incubator process?

+ +

AGNES: So the biggest thing I found during the incubator was actually a really good entry point into this market. So startup wisdom says that you have to narrow down your product to a super tight segment that has a very strong, like, yes to your product. So, during the course of the eight weeks that I did the incubator, we did a ton of interviews, and I was really on the lookout for big spikes and pain points that repeated for a specific niche of freelancers. And that's exactly what we ended up finding.

+ +

There's lots of nuance to this, but generally speaking, people new to freelancing and those that are just looking to get started need help getting started in a more manageable way and then setting up good practices that will serve them in the long run.

+ +

WILL: You mentioned those practices that helps them set them up in the long run. Are you talking about mostly the operation, so, like, anything that's non-billable for a client?

+ +

AGNES: Exactly, yeah. So that's kind of how I think about the work is anything that's billable and then anything that's non-billable. So that includes client management, client communication, marketing themselves, finding, you know, new work, so drumming up new business, all the back-office financials, back-office legal and admin stuff. All these other things that traditionally would be, you know, done by, you know, an operations team at a big company, but, for freelancers, they have to do it themselves.

+ +

WILL: Yeah, I love that idea because my spouse she dipped her toe into the freelance world. And I felt like the operations kind of overcame everything else. And so it almost felt like the operations was taking over the job. But it's one of those things I feel like we didn't really think through of how much work that that 50% is. Like, how much work do you have to do, which are taxes, operations, speaking to clients, even to get to the things that people usually love, like the design, the software development? So I'm excited about this product.

+ +

AGNES: Yeah, exactly. And that's kind of what I kept hearing again and again in interviews with all sorts of different freelancers because we went out and interviewed folks from, you know, everywhere from graphic design, to UX/UI design, to web developers, to other types of creatives, content creators. And this idea that they all get into freelancing to pursue their passion, the thing that they're uniquely good at. But then end up spending a huge chunk of their time on, you know, things that they're not really specialized in, you know, basically running their business.

+ +

VICTORIA: What types of experiments did you run while you were in the incubator program with the people you mentioned you're talking to? And what were the demands on your time really like?

+ +

AGNES: Oh, so the program is between 20 to 40 hours a week. I had a chance to meet with my thoughtbot team daily. We had independent work time, also breakout sessions. Like you said, a lot of that time was spent doing interviews and running all sorts of different experiments, so discovery interviews, interviews showing the prototype once we had it to interviewees. But we also set up Google Ads. We created a landing page with various calls to action. And then based on who was coming through the landing page and what they were doing on the site, we had all sorts of, you know, lessons that we could take away from that.

+ +

And then another piece of it was I also learned how to basically start building out an organic community around this problem and from, you know, the community of freelancers, which is so important to have, like, for a future user base and also to be able to continue to engage with my target audience.

+ +

WILL: Was there anything that surprised you about the program, or did you have any interesting findings coming out of the program?

+ +

AGNES: One thing I learned through the program was that you know, there are concrete steps that you can take and a process that you can follow to build out a strong business that solves real problems for people. And that's really what this program and this incubator is focused on, is to teach you those skills to go through those early steps.

+ +

You know, everything that I had read before about startups they're kind of clouded in mystery. And, you know, the big ones that end up being really successful tend to be mythologized, and founder stories tend to have these, like, big eureka moments in them, where the founder had their big idea that led to the big company. But really, at the early stage, it's pretty messy. And nevertheless, you have these steps that you can follow and processes that you can follow to build out the company.

+ +

VICTORIA: And how are you feeling now at the end of the program?

+ +

AGNES: I feel really excited and, frankly, more confident than I came into the program. So, you know, I'm leaving here with lots of good data, lots of good anecdotal evidence, having had dozens and dozens of conversations with my target market. So, for me, that's a really great feeling to know that my ideas they don't just exist in the abstract in my head but that we've bounced them against the universe and confirmed that folks are having the pain points that we expected and some that we did not expect. And that there is an opportunity around this.

+ +

WILL: So, what could be done better about the incubator program from your perspective?

+ +

AGNES: It was a great program, and that's a pretty hard question to answer. But, you know, I would selfishly say make it longer. Eight weeks is, by design, you know, a pretty short time to get started. And that's really what the program is designed to do is to get you started, to set you up with good practices and good tools. But, again, selfishly, I wish it were a little bit longer, so I can stick around and have the thoughtbot team around me.

+ +

And then I just look forward to building more of a community as more founders join thoughtbot's incubator every quarter. We have a shared Slack channel that I'm going to continue hanging out in and that I've been told the new founders, as well, will be added to. So I'm looking forward to getting to meet them and to, you know, hear about their experience as well.

+ +

VICTORIA: What's coming up next for you in the next six months?

+ +

AGNES: So I'm talking to a couple of potential partners in the next couple of weeks, which might kind of change the roadmap slightly. But, basically, this summer and fall, I'm building out a lot of the content and the prototype for Senga. Again, continuing to talk to the freelancers I've been continuing to talk to. I'm also putting together sort of, like, an advisory committee of freelancers I've met along the way who had a strong yes sort of reaction to this product. And then my goal is that by fall or winter, I'll be able to start building out an MVP.

+ +

WILL: That's exciting.

+ +

AGNES: Yeah, I'm really excited. [laughs]

+ +

WILL: Your dream is finally coming true, so, yeah, you have something to be excited about. [laughs] Do you have any advice for any other founders?

+ +

AGNES: I guess I don't know how qualified I feel to be, you know, handing out advice as a brand-new founder. But, overall, I would encourage others out there who are interested in taking this path to, you know, really take a risk and to bet on themselves. What I've found in the last couple of months is that there are so many supportive communities, and founder groups, and entrepreneur groups.

+ +

And this is kind of common advice, and everybody says this, but there's really no way you can fully prepare. You just kind of have to start doing. And at least from what I've seen, that's the secret sauce to this early stage is to keep doing and to keep going from one step to the next every day.

+ +

VICTORIA: If you could travel back in time and give yourself advice from when before this all started, what advice would you give yourself?

+ +

AGNES: I would just encourage myself to, you know, take the plunge and maybe even go down this path sooner. You know, I feel really confident where I'm at now in terms of my career and my, you know, support networks and everything. But being able to go back and start experimenting earlier and start going down this path earlier might have even set me up better.

+ +

WILL: One thing when you're starting a startup is funding. Are you looking for any funding?

+ +

AGNES: Not urgently, but I'm definitely interested in talking to others working and investing in this space. So, you know, if any of your listeners are investors or entrepreneurs in a similar space, I would love to talk to them.

+ +

WILL: Yeah. So, how could they reach you if they wanted to reach out to you?

+ +

AGNES: You can reach me by email at hello@senga.app, or you can find us on LinkedIn at Senga.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You could find me on Twitter @victori_ousg.

+ +

WILL: And you can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Agnes Malatinszky.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+gAGOth3f + + ]]> + + Will Larry + Victoria Guido + Agnes Malatinszky + + + 477: 20th Anniversary Episode + https://podcast.thoughtbot.com/477 + 936287ca-024a-46df-912c-2ef5f7dfa2a7 + Thu, 01 Jun 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Chad joins cohosts Victoria and Will to talk about thoughtbot's 20th birthday! 🤖🎉 + +In this episode, you'll find the 411 on the thoughtbot mascot, "Ralph," taking the company fully remote, and our company values and how we believe products should be designed and built! + 52:35 + no + + + Chad joins cohosts Victoria and Will to talk about thoughtbot's 20th birthday! 🤖🎉 +In this episode, you'll find the 411 on the thoughtbot mascot, "Ralph," taking the company fully remote, and our company values and how we believe products should be designed and built! +Follow Chad Pytel on LinkedIn (https://www.linkedin.com/in/cpytel/), Twitter (https://twitter.com/cpytel), or visit his website (https://b.dougie.dev/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. +We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. +Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. +JORDYN: Thanks for having us. +DAWN: Yeah, glad to be here. +VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? +JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. +VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. +JORDYN: Wonderful. +VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? +JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. +VICTORIA: What made you decide to start this incubator program this year with thoughtbot? +DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. +And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. +It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. +VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? +DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? +It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. +VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. +JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. +You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. +He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. +You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? +VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? +DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. +So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. +VICTORIA: Wonderful. That's amazing. Thank you both so much. +INTRO MUSIC: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your host, Will Larry. And with us today is our other host, Chad Pytel, the CEO of thoughtbot. Which, we're celebrating 20 years of business this year. Chad, welcome. +CHAD: Oh, it's good to have the tables turned on me. And I'm looking forward to the discussion today. +VICTORIA: Great. We have a whole set of questions, some of which come from other employees within thoughtbot. So we're really excited to dig into it today. Why don't we start with thoughtbot's iconic logo, the Ralph bot, and the little red robot that everyone knows thoughtbot for? And we call him Ralph within thoughtbot. So, how did Ralph come to be? Where does his design come from? And how did that become part of the company mascot? +CHAD: I'm happy to tell the story. But I have a question for both of you: have you ever heard me call the robot Ralph? +WILL: [laughs] No. +VICTORIA: I don't think I've ever heard you refer to the robot. +WILL: [laughs] +VICTORIA: So, if you did call it, I don't know what you would call it. +WILL: Oh, who started that? [laughs] +CHAD: It was someone who was at the company, Matt Jankowski. +WILL: [laughs] +VICTORIA: Ah, I see. +CHAD: I actually don't like the name. I think it's a terrible name for the robot. [laughs] I don't understand why the robot has to be gendered at all. And so I've never said that that's the robot's name. You know, when you're CEO, you have to pick your battles. +WILL: [laughs] Yes. +CHAD: Yeah. So that's the unofficial name of the robot, I think. And Matt started calling it that because Matt's a big fan of coming up with names for things. And yeah, so, at some point, he started calling it that. And it sort of stuck as people joined the company and just sort of assumed that that's what the robot's called. +We didn't start with this logo. Logo has always been a robot. But the thing we started with was an illustration based off of a tin robot that I think either one of us had or that we saw a picture of. Another Matt, who is one of the founders of the company, sketched it. He was a designer as well as a developer. And we used it for a few years. +But what we learned over the course of it as we gained more exposure is that, actually, it's a really common tin toy robot. And you can find a lot of other art and illustration and uses of it in stock photography and everything. Which at first was good because then we could get a bunch of stock photography, and it was our logo. But then we realized, ooh, this is not something that we really own or have control over. So we started to think about creating our own robot logo from scratch. +Since we're a design firm, and I think it's notoriously hard to design things for yourself, we actually went to another agency that we were friends with and hired them to work with us to create the logo. And I have to say I was probably the worst client ever. +WILL: [laughs] +CHAD: Because I was asking...I had a particular vision in mind for this idea of, like, a powerful robot. And we kept on doing sketches, after sketch, after sketch, and it was really hard. We couldn't arrive at something that seemed powerful, that didn't seem aggressive. The logo at the time was a 3D representation of the robot. And it was really hard to also make a new 3D robot that looked powerful but not aggressive. And we just banged our heads against that for a long time. I think it was a couple of months. +Until one day, I just said, you know what? We're not going to do it. Let's just stop trying to do this. [chuckles] Let's just do the simplest 2D representation of a robot that we can think of. And just going back to the drawing board starting over, we arrived at the logo we have today. Now we have to deal with the fact that it looks a lot like the Android logo. [laughter] But that's the, I guess, the story of the robot. +WILL: So, first off, scratching the name Ralph. [laughs] +CHAD: No, no, you can use it. I just think it's funny. +WILL: Definitely. Second thing is Chad is not a good client when working with designers. No, I'm just joking. [laughs] +CHAD: No, it's totally true. +WILL: [laughs] +CHAD: You know, when we have strong opinions that are mostly preferences, that leads to people being bad clients. [laughter] Because there was no reasoning behind, you know, the preferences. It was just what I had in my head. And so it wasn't until I let that go that we were able to arrive at something usable. +WILL: [laughs] That's awesome. So, was the robot a passion for you, or was it just a toy that one of the founders, employees had, and that's where you went with it, how you got your inspiration? +CHAD: The name thoughtbot with the bot on the end comes from...because before we started thoughtbot, we did a lot of Java development as a group, same people I went to school with them. We did projects together. And we would follow the pattern where you sort of have an object and then a manager object or a service object. And it was a common naming pattern. If you have orders or customers, then the service object might be called order manager or customer manager. And, in our code, we tended to not do that and instead do bots. So we would have order bot over orders, customer bot over customers. +So, when we were brainstorming names for the company, we naturally tended to put bot on the end because that was our typical naming convention in the projects we were doing together. And so there wasn't anything particular about robots that we cared about at all. [laughter] It was that naming convention, which then extended to, okay, well, it's the thoughtbot. And so it should be a robot with thoughts on it or thought lines or something like that. That's where it came from. +VICTORIA: I love to hear that. I'm learning so much myself I didn't know before even as a thoughtbot employee. +WILL: [laughs] +VICTORIA: It's been 20 years since you started the business. I want to start...or go back in time. So, if you could go back and give yourself, the younger version of you 20 years ago, some advice, what would you say? +CHAD: I've gotten similar versions of this question on different shows. My answer for the last several years has been pretty consistent. So I'll give that one, and then I think I have another one too. The thing that I didn't realize at the time that I think I would be better for and the company would be better for I had a big blind spot in terms of I started thoughtbot with friends. We were the same age. We were all five White guys in our 20s, just out of school. That was the people that I was doing projects with; that was the people I was surrounded by in school. And it was a big blind spot. +And, if I could go back in time, I would try to open my eyes to the fact that that was the case. And I think that I would be a lot better for it. And I think the company would be a lot better for having started with a more diverse team from the beginning because it makes us worse when you don't start off that way. It's harder and harder to correct it the longer it goes on. And so that would be something that I would go back and try to tell myself. Look at what you're doing. You don't realize now, but it is important. +WILL: So, because we started talking about this at Summit a month ago, and it was amazing to hear that you're saying that because, at the same time, we're at this all-staff event, and we're able to see how diverse our team is and stuff like that. How has the journey been increasing the diversity of the team? Like, I look at our team photo, and it's just amazing to see the diversity in every level, especially in leadership, the diversity in leadership. And I know we haven't, quote, unquote, "arrived." So, how has that journey been? And what does it look like in the future? +CHAD: Yeah, I mean, we've clearly made a lot of progress on this. It is better and easier now than it was in the early days because nobody wants to be the first. Nobody wants to be the first woman on the team. No one wants to be the first person of color on the team. You don't know when you're coming into an organization like that, whether it's the kind of place for you or whether you're going to run into problems. And so now that we've made some progress, that in and of itself makes it easier to continue on the journey. +But when we were just getting started on that, we really needed to do a lot to intentionally fix it without tokenizing people, which is not easy to do. And so we're very fortunate that we have made progress. And I appreciate everyone along the way putting themselves out there, willing to be the first, or the second, or the third. I know that that's not easy, and it's made thoughtbot a better place now that we've progressed. +WILL: Yeah, and I want to interrupt and say this: after that conversation, I remember I had to split and run to another event. While at that event, I met one of the first ladies that were on the team. And I started chatting about her experience. And it was amazing to see the transformation from the beginning to where it is now. So it was just really good to have that conversation with you, and then go talk to her and just, I guess, see the complete picture, so that's amazing because she's still on the team to this day. +CHAD: Yeah. But we're not done yet. Like you said, we still have [laughs], you know, we can always be better. +WILL: Where do you see it going in the future? +CHAD: Well, I think that even though the management team, the senior leadership team, we have made progress there, I think that that is an obvious area where we have more progress to go in terms of making sure that people at the company are represented...the demographics of the people at the company are represented at every level of the company, especially when you have a culture like we do where the leaders are the people who have been here the longest. And we don't have so many of those positions opening up over the years. +In fact, over the last five years, we've eliminated more of those positions in order to reduce overhead and to stay financially sustainable. So we actually have less of those opportunities than we have in the past, and so that holds us back. And so we have to figure out how to handle that and to do better with that. +The other is, you know, one of the biggest changes over the last three years is going fully remote. And that has enabled us to hire the best people, no matter where they live, in the time zones that we operate in. And that has been really great for bringing new people, new energy onto the team. That is going to continue into the future. And we're going to see the demographics of the company continue to shift away from the United States. 60% of the company is now outside of the U.S., and that's going to keep on going. And that doesn't make us any worse off. It makes us better. +VICTORIA: Yeah, I wanted to ask you about that. So, thoughtbot, as I understand it before we went fully remote, was known for having an amazing in-person office culture. So, what was that shift like for you? And how do you maintain that company culture after going fully remote? +CHAD: Well, here's the honest answer. +WILL: [laughs] +CHAD: The honest answer was I was already not part of that office company culture. I was traveling one week out of every month to one of the studios. I didn't interact with people in the same way because of my position within the company. I was out of the studio a lot of the time. And even when I wasn't there, I was already working from home a few days a week because of my travel schedule or something like that. So moving to fully remote...and I was already sort of over-commuting to 45 minutes each way to the office. +And so moving to fully remote has made things a lot better for me because I'm traveling a lot less. I get to be home with my family a lot more. I don't have that commute time. And my experience now, I think, is more similar to everyone else on that team. And I feel like we're all sharing more equally in what the experience is at thoughtbot. And so when I work to improve that, I'm not only working to improve it for me. I'm working to improve it for everybody. +And so there are trade-offs. It is certainly different for the individual designer or developer at thoughtbot than it was before. But I think that the benefits of having the team that we have now, people being able to live where they want to live and to get that commute time back, outweigh the downsides of changing that company culture. +VICTORIA: The other part is about just that shift, right? Of it was COVID. [laughs] Obviously, a lot of people were going remote at that time. So I'm just curious how that experience really happened for thoughtbot. I know how it happened for me at the company I was at. [laughs] +CHAD: Well, it was certainly abrupt, you know. And, at the time, we thought, okay, we're going to shut down the office for two weeks, and then we'll all be back. And that, very quickly, was proven to be wrong. When it came to our actual work, the biggest shift we had was in the way that we collaborated with clients. But we were already collaborating with each other across studios in a distributed way. And so that was a more natural progression. +I think the biggest shift was the way that our projects were working and collaborating with clients. You know, we would have clients in the office with us, too, sitting right next to us. And so figuring out how to do design sprints fully remotely, to ramp up the amount of remote pair programming that we were doing, those were the big changes, I think. +And then you had the cultural ones, too, that you really need to work at when two people are getting a snack in the kitchen and having an off-hand chat about something. When you're fully remote, that doesn't happen. You need to put a lot more effort into those sort of what would have been casual conversations previously. +WILL: So, and it seems like...just having a conversation with you, I know that it wasn't an easy decision to change over. And my question is, how do you make decisions, especially the hard ones that are not...and you stick with them? For example, I know, like, with hiring, we're talking about the diversity and creating a diverse pool that kind of resembles the area that we're trying to hire for, so, you know, resemble the U.S., or overseas, or wherever it is. And that's a hard thing to do at times, but we stuck with it. And there's been other decisions I've noticed. +So, how do you make those decisions, one, and then, how do you stick with them when most companies or most people will say, "Hey, it's just too hard. Let's pivot and change it up"? +CHAD: Yeah, we have our values, five core values, and one of them is fulfillment. And I often refer to that as our North Star value, meaning that when we're faced with a decision as a company or as individuals, fulfillment is often the one that we most often look to as the guide for which direction to go in. And I think that that is really powerful for us. It causes us to choose things that other companies might not choose. +And it also is really powerful for us because it means that I don't need to be the one to make all of the decisions. You can make decisions based on what is fulfilling to you in your work. And that's very likely the right thing for everybody else at the company. And it may mean that we're a little bit less successful financially. But there are two aspects to success, you know, you need to be financially sustainable, but if you're unhappy in your work, if you're unfulfilled in your work, then that's not truly being successful. And so that's the guiding point of the way that we make a lot of decisions. +Take the example of going remote, we weren't really deciding between going back to the way things were or going fully remote. Going back to the way things were was not an option because we had already told everyone if you need to move if you need to be away from the studio you were previously part of, go do that. You don't need to worry about remaining at thoughtbot. And about 20 people moved away from where their studio had been located, which is about 20% of the company. So we were deciding between hybrid or fully remote. Going back to the way things were wasn't an option because we had already removed that from the table, I think, guided by supporting the team, fulfillment, trust, our values. +So then the decision-making comes, do we want to figure out how to be hybrid? Which we had done before in our history. And we understood, based on that past experience, that you have to work at that quite a bit to integrate everyone fully, and sort of if you don't, it becomes very tough or even just mediocre. And so it was, are we more excited about working at being the best hybrid organization in the world, or are we more excited at figuring out how to be the best remote company in the world? +You know, for me, that was an obvious choice. I was more excited about figuring out how to be the best remote company than I was about being the best hybrid company. So I think that that's an okay... [laughter] I think that's an okay way to make decisions. What are you more excited by? What are you going to be more fulfilled by in your work than that? And so that's, you know, sort of dissecting that decision-making, you know, part of what tipped us over the edge in terms of choosing to be fully remote. +VICTORIA: I like that you said that you tried to make it so that you're not the one making all the decisions. [chuckles] And I felt that as a managing director and as an associate director that there is a very purposeful tact of when I'm bringing issues to leadership. The response I get back is very careful not to tell me what to do. [laughs] +CHAD: Yeah. I'm sure it's annoying at times, right? [laughter] +VICTORIA: I think it's a shift, right? Like, if you're coming from a typical, like, top-down organization, it can be a real mind shift, and it can be frustrating. But then, once you embrace it, it can be very fulfilling, like you said. +CHAD: Part of why we do that, too, is because if you're not careful, you know, one of our other values is trust. And we really do trust people more than they're used to. And our other value is self-management. So, people should be left to their own devices. People at thoughtbot take initiative in their work to make decisions, those kinds of things. And so, at the intersection of trust and self-management, what happens in a lot of other cultures is this idea of permission. If you have to ask permission to do things, then you can't truly self-manage. +So, when you come to a leader and you're asking for something, it's hard for that not to be articulated as asking for permission for something in a traditional sort of power hierarchy. I encourage people at thoughtbot to think about...in the way that our culture works, it's a lot better to frame things as asking for advice because there are people who have more experience in a certain area than you or whatever. +And so a much better way of framing the conversation that you want to have with those people is instead of just asking open-ended questions, which it's very easy to misunderstand as basically just asking for permission to do something, it's better to say, like, "Here's what I know. Here's what I would do based on what I know. Do you have any advice for me based on that?" And then I can say, "Oh, well, here's what I know. [laughs] Can I share that with you?" +And then, you can take that information in, and then you can make the decision based on having that additional information. I don't want to make the decision for somebody. That's the way I think about it. If you're not sure what's happening, it can be pretty frustrating in our culture because we are sort of averse to telling other people what to do. We're happy to help people and give people information, but we don't like to tell people what to do. +WILL: Yeah, and I've definitely felt this, even as a developer here. But it has been the perfect fit for me because I love the, hey, we trust you. Go and do it. Go make decisions. Hey, even if you fail, let's come back and talk about it and move forward. But also the pushing me out of my comfort zone. There has been numerous times where I'm like, "Yeah, I don't think I can do that." And someone in leadership is like, "I think you can. Let's try it out. Let's do it. If you have any questions, come talk to me. I'll help you in any way I can." So, even as a developer, I feel that same way. +And so I guess my question for you, Chad, is there's been a lot of decisions that I've seen you make or even this part right here, the trust. Because sometimes, money can override that when you're a CEO, especially because of jobs and everything. But you said fulfillment, and you had the values. But, Chad, as the CEO, like, why do you personally lead like that and make decisions like that? +CHAD: It's a really good question. [laughs] +WILL: I always wanted to peel back the layers of Chad. +VICTORIA: [laughs] +WILL: So that's what it is. [laughs] +CHAD: To tie it back to development, just like you just did, I think a lot of our values and the way that we do things come from the way that we believe products should be designed and built. When I'm working on a project, I don't want to be told how to do everything. I don't want every ticket to be specified without me being part of the understanding or decision-making process. +I want to be able to collaborate with the people that I'm working with, understand the problems that we're trying to solve, and then pick up the ticket and do the research, figure out the best way to solve it or be part of that. And when it's not clear to me, ask questions, learn from other people about the right way to solve something might be, and then to implement it in the best way that I know how, and collaborate with the people that I'm working with as I do that. +And then I pick up that ticket, and I'm responsible for deploying it to staging and asking for acceptance of it. And I'm responsible for deploying it to production. So I'm pushing my work. I have agency over my work at every step of the way. I hope everyone who's listening has had an opportunity to be on a project where you've truly had agency over your own work. It's a really good, fulfilling feeling. And so I think that's where it comes from. I think that's what I try to bring to everything that I do. +VICTORIA: And I think that philosophy is what creates such a compelling company culture and makes people want to work here, right? +CHAD: I think so. Particularly because the work we do, the majority of us are designers and developers, but I don't think it's just design and develop. Like, it resonates a lot the relation to product work. But I think that's true for fulfillment in your own work generally across the board, no matter what your role is. People would rather have agency over their own work than to be micromanaged, to be told what to do all of the time. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: In 20 years of hiring people and building products, what has really changed in terms of what you see customers looking for in building products, and what's stayed the same? +CHAD: There's a lot that has changed, mostly in terms of platforms and practices. When we were first getting started out, the practice of test-driven development was not generally established as a best practice. It was one that we needed to advocate for and fight for, and really put ourselves out there as this is what we believe about the way good products are built, and if you don't want that, we're not a good fit for each other. So that's what I mean by practices. A lot of those things that used to be controversial we sort of won on as they played out as, yes, general agreement now about certain best practices. And so that has evolved over time. +The other is mobile development. You know, when we first started, that wasn't really a thing. We did some mobile development early on for Palm platforms and for Motorola platforms using different versions of Java. It was a very different ecosystem. And mobile development has evolved a lot and become...almost every project we do has some mobile component. And a lot of them are native mobile applications with an API back end that we're building as well. So that has been a big change. +The things that stay the same are, I would say, the things that we have sort of been constant about. So in the way that best practices change or evolve, the constant has been that we put ourselves out there, willing to be opinionated about what we believe the current best way of working is. That means that the clients who work with us are coming to us wanting that. +And that leads to a culture of work and quality and that kind of thing, which I think has been pretty constant over the years. But it's not because we didn't try. Like, if we were willing to be anything to anybody and to compromise all the time and those kinds of things, it wouldn't be a constant. But we work at it, but I think that feeling of what it's like to do this work has been a constant. +WILL: Speaking of changes and constant changes sometimes, what's the story behind the handbook? Everyone at the company can access the handbook through GitHub and how [inaudible 29:35] Whose idea was it? How did that come to be? And explain how it's always changing and what that looks like. +CHAD: Yeah. So, like you said, we have our company handbook and the public playbook in a source code repository that everyone at the company collaborates on and has access to change. I don't remember who initially moved it into version control. It started as a document. We worked with an outside payroll or HR company to make as our first company handbook. It had policies and those kinds of things in it. At one point, you know, we were doing some revisions, and maybe me, maybe somebody else said, "Let's move this out of this," whatever it was at the time, Word doc, or whatever, "and move it into Markdown and natural place we want to have version control on it." +But even though we moved the document into version control and even though everyone at the company technically had access to it, I think for many years, we still did things like a lot of companies do, which is the version control in and of itself isn't the special thing. It's using GitHub issues to track actual problems that we know about, or potential issues that we know about, defects in our policies, our practices, the company itself, just like we do on our software products. That was the actual fundamental shift that we made because it completely changed the way that we make change at the company and organize the work that we do to improve the company. +And the way that that happened was, I think, prior to that, we made changes in a lot of ways that companies make changes. So some people know about some things, some people don't. Typically, senior leaders will get together often in meetings and talk about the issues that they see. And they tend to result in really big changes all at once that attempt to address multiple issues or make big reorganizational changes. And there's a tendency not to work iteratively when you work that way, and we did the same thing. +So the sort of final big event that happened that triggered the fundamental change of working was, at the time, we had an unlimited time off policy. We had gone to that a few years prior because it was a trend in general. But also, we were tired of sort of tracking time and the permission that happens around time off and all that kind of stuff. So we had sort of blown it all up and gone to an unlimited time off policy. But it's more well understood now that unlimited time off policies have a few issues. And we were seeing those issues. +Time off was very inconsistent among everyone on the team. Particularly, new people would join the company, and they'd be like, okay, yes, but how much time am I supposed to really take? So that was one issue. Another issue was we wanted to increase the amount of parental leave that we offered as a company, like, on paper. Now, technically, we had the unlimited time off policy, but you want to give guidance to people, and you want to be able to say in a job advertisement that you have this much parental leave, you know. +And because we're a consulting company and we make our revenue when people are working, the question was asked, how much can we say that we have for parental leave? And it was a very uncomfortable position for us to be in to not be able to work that financially because we could say, okay, we have 12 weeks of parental leave. But, at any point in time, anyone else could take more time off for any other reason because we had unlimited time off policy. And the idea that we couldn't prioritize one kind of time off over another to make it work financially was uncomfortable to us. +And then, the state of California passed a sick time law, which was fundamentally incompatible with unlimited time off policies that lump sick time and vacation time together. And so we knew about these things. We got together in a meeting. We talked about them. And we put together a pull request to the handbook that, you know, we said, you know, we could probably fix any one of these problems. But probably all signs are pointing to just switching back to a regular time off policy. +And so we put together a pull request. You can probably guess since I'm telling this story that, generally, people were very surprised. It was a big change to take in all at once. And I think even though we have a high level of trust, as a company, it was hard for people who generally viewed an unlimited time off policy as a good thing. You know, they were worried that there was some ulterior motive there, that something was being taken away for some reason, maybe financial. So we worked through it, and the pull request is there for everyone at the company, so you can see. +Anna, when she opened the pull request, outlined all of those reasons why, but it was a lot of information to take in. And after we made it through, it sort of caused me to reflect on the process. And there was good criticism from members of the team at the time about the process, and we really took that in. And I think it was the state of California passing that law that the solution that we arrived at to mind for me because they passed the law in, whatever it was, the spring or the summer. And it wasn't going to go into effect until the new year. +And that's really no different than, you know, a new version of a library is going to come out, or a new version of an operating system or a browser is going to come out. And we know it's going to break our app. What do we do? We create a ticket in the backlog. We describe what the problem is. We prioritize it among everything else we're working on. And we make sure that the fix is in place in time for that to be released. +And yet, we weren't doing that for these very obvious defects or things that we knew were going to break an existing policy against this kind of stuff. So I was like, we could use GitHub issues to log problems that we know about that are out there, and not only would that have led to a lot more transparency along the way. When a change was made, people could have come along that journey with us of identifying the problem, being aware of it, being part of problem-solving, and coming to a resolution, and then getting a pull request. +But more fundamentally, I think once you start to work that way, probably would have never made the change that we did in the first place because this way causes you to work more incrementally, to work more iteratively, to take each of the problems to try to identify the root cause and the best way to fix it. And very often, that is a smaller change that you can put into place more quickly. And we know that we don't need to get it perfect. We don't need to change absolutely everything about this all at once in order to fix every problem. We just need to make tomorrow better than today. +If we can do that, then we know that, over time, it adds up to significant positive change that is very different a year from now or two years from now than what we're doing today. But we do that by chipping away and making tomorrow better than today. And so working this way with these discrete tickets, with this thing, there are downsides too, don't get me wrong. It's not all sunshine and rainbows. It's hard to work this way. But those are some of the benefits and sort of the story of how we arrived at how we do things. +WILL: I love that because I'm familiar with creating PRs, commenting on PRs, just giving feedback through PRs. And also, I've never been in a leadership meeting at thoughtbot, like, just never been in one. But I know that if I comment on a PR, my voice is heard with leadership making the decision. I love that idea. +CHAD: Yeah, leadership meetings at thoughtbot are actually very boring. +WILL: [laughs] +CHAD: Because the only things that we're talking about that aren't represented in GitHub issues are things that aren't proper for GitHub issues, so they're individual personal problems or things like that, or, hey, we're doing a leadership training and, you know, talking about that. Actual change, actual things that happen, are represented in those GitHub issues. And that's why it's super important that we have issues for everything because when we truly work this way, if something's not represented as an issue, it's not getting worked on. +There's not a lot happening in leadership meetings other than those things that aren't ideal for GitHub issues, or we're going through, and we're saying, "Hey, this issue has been sitting around for a while," or "What's the update?" And you'll often see someone comment after the fact about an issue. Now, that being said, I think one of the hardest things about this is that when you expose these big issues, it can be a little discouraging over time to have them be around there to be not closed. +But the way...I'll bring this back to our product work as well, like, when you identify...at least this is the case for me. A bug could have been there for two years, [chuckles] and I don't know about it, and therefore, it's out of sight, out of mind. I didn't know about it. But the minute I find out about a bug in a product that I'm working on, I can't stop thinking about it, and I want to fix it so badly. It becomes my top priority right away. [laughs] +And I have to remind myself that just because I know about something now doesn't mean it's actually the highest priority item, or that I can fix it, or that I should take the time to fix it. I know it's my natural tendency to do that. So shedding light on something that's positive in and of itself, and then we can chip away at that over time. And this way of working allows us to tackle big problems. But sometimes it doesn't feel so great because you're identifying sort of defects in the company itself that make everybody uncomfortable. But I would rather light be shed on those so that we have a chance to improve it than to have it go unidentified, just like bugs in our products. +VICTORIA: And just to illustrate, we have 162 open issues on our handbook. [laughter] But, you know, from my perspective, that makes me really excited, like, people are engaging with it. They're putting in issues and creating it. Because I've converted a company handbook to GitHub before, and no one ever looked at it. [laughs] So it was actually kind of nice that -- +CHAD: [laughs] +VICTORIA: You said that it took some time to build up that interaction with it and make people feel comfortable. And I wanted to ask about actually your Dungeons & Dragons campaigns that you run with the company. And I'm wondering what skills or practices from that comes over into your leadership style or the culture at thoughtbot. +CHAD: Ooh, I'm not sure it's as deep as that, Victoria. +VICTORIA: [laughs] +CHAD: I just really like [laughter] playing Dungeons & Dragons. But I will say the itch that it scratches for me and the reason why I like Dungeons & Dragons, and the reason why I'm really happy to play it with thoughtbot people...my degree is computer science. But all throughout elementary school, high school, I did improv and theater, and I have a degree in theater as well. +For a long time, Dungeons & Dragons is essentially doing group improv with other people around a game. And to be able to bring those two things together with a group of people that I like to have fun with it's a really great outlet. And I really enjoy it. But I'm not sure that there's anything deeper than it sort of scratches that performance itch that I have with a group of people that I like to hang out with. +VICTORIA: That's fair. And then, just to kind of go back to one of our earlier questions we asked —what would you go back in time and advise your younger self —now, what if your younger person could travel to the future and give you some advice, looking at where you are at now? +CHAD: The only way that I've done this for 20 years is day by day. Like, each day, you get up, and you approach each day. This is the way I do it anyway. It's like I approach each day as a fresh day. And now, over thousands of days, it's been 20 years. And I think that that is part of why at least I've been able to do this so long is I don't do a lot of dwelling on what happened yesterday. I think about today and tomorrow much more than I do about what happened yesterday. +The upside is I've been able to do this for 20 years. [laughs] The downside to that is you tend to not reflect so much on the good things, just like you don't reflect so much on the bad things. You tend to not celebrate the milestones when they happen or appreciate them as much because you're onto the next thing. You're thinking about tomorrow rather than yesterday. And so I would think that if my younger self came forward and talked to me today, I think the thing that he would say is like, hey, look at where you are, look at what you've done. Take a moment [laughs] to celebrate not only your work but, you know, this is true for the people around me. +I tend not to celebrate the accomplishments as much and everything because I'm very much someone who sort of lives in maybe not even the moment but the next moment that's about to happen. And so I think the person would say, relax a little bit, have a little bit more fun. Take a moment to celebrate the people around you a little bit more. I think that's what I would say to myself. +WILL: I love learning things that I didn't know about thoughtbot. So this has been perfect. +CHAD: Thank you both for the really thoughtful questions. And on the note of what I just [inaudible 44:53], thank you for everything that you both do at thoughtbot. I really appreciate it. We couldn't have accomplished everything that we have without the individuals [inaudible 45:01]. So I'm here sort of representing thoughtbot for our 20th anniversary, but it's not just me who got us to this point. It's been a lot of other people over the many years making it happen. And so I appreciate both of you for helping make it happen. +VICTORIA: Well, thank you. And again, thank you so much for joining us. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you could find me @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Chad joins cohosts Victoria and Will to talk about thoughtbot's 20th birthday! 🤖🎉

+ +

In this episode, you'll find the 411 on the thoughtbot mascot, "Ralph," taking the company fully remote, and our company values and how we believe products should be designed and built!

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your host, Will Larry. And with us today is our other host, Chad Pytel, the CEO of thoughtbot. Which, we're celebrating 20 years of business this year. Chad, welcome.

+ +

CHAD: Oh, it's good to have the tables turned on me. And I'm looking forward to the discussion today.

+ +

VICTORIA: Great. We have a whole set of questions, some of which come from other employees within thoughtbot. So we're really excited to dig into it today. Why don't we start with thoughtbot's iconic logo, the Ralph bot, and the little red robot that everyone knows thoughtbot for? And we call him Ralph within thoughtbot. So, how did Ralph come to be? Where does his design come from? And how did that become part of the company mascot?

+ +

CHAD: I'm happy to tell the story. But I have a question for both of you: have you ever heard me call the robot Ralph?

+ +

WILL: [laughs] No.

+ +

VICTORIA: I don't think I've ever heard you refer to the robot.

+ +

WILL: [laughs]

+ +

VICTORIA: So, if you did call it, I don't know what you would call it.

+ +

WILL: Oh, who started that? [laughs]

+ +

CHAD: It was someone who was at the company, Matt Jankowski.

+ +

WILL: [laughs]

+ +

VICTORIA: Ah, I see.

+ +

CHAD: I actually don't like the name. I think it's a terrible name for the robot. [laughs] I don't understand why the robot has to be gendered at all. And so I've never said that that's the robot's name. You know, when you're CEO, you have to pick your battles.

+ +

WILL: [laughs] Yes.

+ +

CHAD: Yeah. So that's the unofficial name of the robot, I think. And Matt started calling it that because Matt's a big fan of coming up with names for things. And yeah, so, at some point, he started calling it that. And it sort of stuck as people joined the company and just sort of assumed that that's what the robot's called.

+ +

We didn't start with this logo. Logo has always been a robot. But the thing we started with was an illustration based off of a tin robot that I think either one of us had or that we saw a picture of. Another Matt, who is one of the founders of the company, sketched it. He was a designer as well as a developer. And we used it for a few years.

+ +

But what we learned over the course of it as we gained more exposure is that, actually, it's a really common tin toy robot. And you can find a lot of other art and illustration and uses of it in stock photography and everything. Which at first was good because then we could get a bunch of stock photography, and it was our logo. But then we realized, ooh, this is not something that we really own or have control over. So we started to think about creating our own robot logo from scratch.

+ +

Since we're a design firm, and I think it's notoriously hard to design things for yourself, we actually went to another agency that we were friends with and hired them to work with us to create the logo. And I have to say I was probably the worst client ever.

+ +

WILL: [laughs]

+ +

CHAD: Because I was asking...I had a particular vision in mind for this idea of, like, a powerful robot. And we kept on doing sketches, after sketch, after sketch, and it was really hard. We couldn't arrive at something that seemed powerful, that didn't seem aggressive. The logo at the time was a 3D representation of the robot. And it was really hard to also make a new 3D robot that looked powerful but not aggressive. And we just banged our heads against that for a long time. I think it was a couple of months.

+ +

Until one day, I just said, you know what? We're not going to do it. Let's just stop trying to do this. [chuckles] Let's just do the simplest 2D representation of a robot that we can think of. And just going back to the drawing board starting over, we arrived at the logo we have today. Now we have to deal with the fact that it looks a lot like the Android logo. [laughter] But that's the, I guess, the story of the robot.

+ +

WILL: So, first off, scratching the name Ralph. [laughs]

+ +

CHAD: No, no, you can use it. I just think it's funny.

+ +

WILL: Definitely. Second thing is Chad is not a good client when working with designers. No, I'm just joking. [laughs]

+ +

CHAD: No, it's totally true.

+ +

WILL: [laughs]

+ +

CHAD: You know, when we have strong opinions that are mostly preferences, that leads to people being bad clients. [laughter] Because there was no reasoning behind, you know, the preferences. It was just what I had in my head. And so it wasn't until I let that go that we were able to arrive at something usable.

+ +

WILL: [laughs] That's awesome. So, was the robot a passion for you, or was it just a toy that one of the founders, employees had, and that's where you went with it, how you got your inspiration?

+ +

CHAD: The name thoughtbot with the bot on the end comes from...because before we started thoughtbot, we did a lot of Java development as a group, same people I went to school with them. We did projects together. And we would follow the pattern where you sort of have an object and then a manager object or a service object. And it was a common naming pattern. If you have orders or customers, then the service object might be called order manager or customer manager. And, in our code, we tended to not do that and instead do bots. So we would have order bot over orders, customer bot over customers.

+ +

So, when we were brainstorming names for the company, we naturally tended to put bot on the end because that was our typical naming convention in the projects we were doing together. And so there wasn't anything particular about robots that we cared about at all. [laughter] It was that naming convention, which then extended to, okay, well, it's the thoughtbot. And so it should be a robot with thoughts on it or thought lines or something like that. That's where it came from.

+ +

VICTORIA: I love to hear that. I'm learning so much myself I didn't know before even as a thoughtbot employee.

+ +

WILL: [laughs]

+ +

VICTORIA: It's been 20 years since you started the business. I want to start...or go back in time. So, if you could go back and give yourself, the younger version of you 20 years ago, some advice, what would you say?

+ +

CHAD: I've gotten similar versions of this question on different shows. My answer for the last several years has been pretty consistent. So I'll give that one, and then I think I have another one too. The thing that I didn't realize at the time that I think I would be better for and the company would be better for I had a big blind spot in terms of I started thoughtbot with friends. We were the same age. We were all five White guys in our 20s, just out of school. That was the people that I was doing projects with; that was the people I was surrounded by in school. And it was a big blind spot.

+ +

And, if I could go back in time, I would try to open my eyes to the fact that that was the case. And I think that I would be a lot better for it. And I think the company would be a lot better for having started with a more diverse team from the beginning because it makes us worse when you don't start off that way. It's harder and harder to correct it the longer it goes on. And so that would be something that I would go back and try to tell myself. Look at what you're doing. You don't realize now, but it is important.

+ +

WILL: So, because we started talking about this at Summit a month ago, and it was amazing to hear that you're saying that because, at the same time, we're at this all-staff event, and we're able to see how diverse our team is and stuff like that. How has the journey been increasing the diversity of the team? Like, I look at our team photo, and it's just amazing to see the diversity in every level, especially in leadership, the diversity in leadership. And I know we haven't, quote, unquote, "arrived." So, how has that journey been? And what does it look like in the future?

+ +

CHAD: Yeah, I mean, we've clearly made a lot of progress on this. It is better and easier now than it was in the early days because nobody wants to be the first. Nobody wants to be the first woman on the team. No one wants to be the first person of color on the team. You don't know when you're coming into an organization like that, whether it's the kind of place for you or whether you're going to run into problems. And so now that we've made some progress, that in and of itself makes it easier to continue on the journey.

+ +

But when we were just getting started on that, we really needed to do a lot to intentionally fix it without tokenizing people, which is not easy to do. And so we're very fortunate that we have made progress. And I appreciate everyone along the way putting themselves out there, willing to be the first, or the second, or the third. I know that that's not easy, and it's made thoughtbot a better place now that we've progressed.

+ +

WILL: Yeah, and I want to interrupt and say this: after that conversation, I remember I had to split and run to another event. While at that event, I met one of the first ladies that were on the team. And I started chatting about her experience. And it was amazing to see the transformation from the beginning to where it is now. So it was just really good to have that conversation with you, and then go talk to her and just, I guess, see the complete picture, so that's amazing because she's still on the team to this day.

+ +

CHAD: Yeah. But we're not done yet. Like you said, we still have [laughs], you know, we can always be better.

+ +

WILL: Where do you see it going in the future?

+ +

CHAD: Well, I think that even though the management team, the senior leadership team, we have made progress there, I think that that is an obvious area where we have more progress to go in terms of making sure that people at the company are represented...the demographics of the people at the company are represented at every level of the company, especially when you have a culture like we do where the leaders are the people who have been here the longest. And we don't have so many of those positions opening up over the years.

+ +

In fact, over the last five years, we've eliminated more of those positions in order to reduce overhead and to stay financially sustainable. So we actually have less of those opportunities than we have in the past, and so that holds us back. And so we have to figure out how to handle that and to do better with that.

+ +

The other is, you know, one of the biggest changes over the last three years is going fully remote. And that has enabled us to hire the best people, no matter where they live, in the time zones that we operate in. And that has been really great for bringing new people, new energy onto the team. That is going to continue into the future. And we're going to see the demographics of the company continue to shift away from the United States. 60% of the company is now outside of the U.S., and that's going to keep on going. And that doesn't make us any worse off. It makes us better.

+ +

VICTORIA: Yeah, I wanted to ask you about that. So, thoughtbot, as I understand it before we went fully remote, was known for having an amazing in-person office culture. So, what was that shift like for you? And how do you maintain that company culture after going fully remote?

+ +

CHAD: Well, here's the honest answer.

+ +

WILL: [laughs]

+ +

CHAD: The honest answer was I was already not part of that office company culture. I was traveling one week out of every month to one of the studios. I didn't interact with people in the same way because of my position within the company. I was out of the studio a lot of the time. And even when I wasn't there, I was already working from home a few days a week because of my travel schedule or something like that. So moving to fully remote...and I was already sort of over-commuting to 45 minutes each way to the office.

+ +

And so moving to fully remote has made things a lot better for me because I'm traveling a lot less. I get to be home with my family a lot more. I don't have that commute time. And my experience now, I think, is more similar to everyone else on that team. And I feel like we're all sharing more equally in what the experience is at thoughtbot. And so when I work to improve that, I'm not only working to improve it for me. I'm working to improve it for everybody.

+ +

And so there are trade-offs. It is certainly different for the individual designer or developer at thoughtbot than it was before. But I think that the benefits of having the team that we have now, people being able to live where they want to live and to get that commute time back, outweigh the downsides of changing that company culture.

+ +

VICTORIA: The other part is about just that shift, right? Of it was COVID. [laughs] Obviously, a lot of people were going remote at that time. So I'm just curious how that experience really happened for thoughtbot. I know how it happened for me at the company I was at. [laughs]

+ +

CHAD: Well, it was certainly abrupt, you know. And, at the time, we thought, okay, we're going to shut down the office for two weeks, and then we'll all be back. And that, very quickly, was proven to be wrong. When it came to our actual work, the biggest shift we had was in the way that we collaborated with clients. But we were already collaborating with each other across studios in a distributed way. And so that was a more natural progression.

+ +

I think the biggest shift was the way that our projects were working and collaborating with clients. You know, we would have clients in the office with us, too, sitting right next to us. And so figuring out how to do design sprints fully remotely, to ramp up the amount of remote pair programming that we were doing, those were the big changes, I think.

+ +

And then you had the cultural ones, too, that you really need to work at when two people are getting a snack in the kitchen and having an off-hand chat about something. When you're fully remote, that doesn't happen. You need to put a lot more effort into those sort of what would have been casual conversations previously.

+ +

WILL: So, and it seems like...just having a conversation with you, I know that it wasn't an easy decision to change over. And my question is, how do you make decisions, especially the hard ones that are not...and you stick with them? For example, I know, like, with hiring, we're talking about the diversity and creating a diverse pool that kind of resembles the area that we're trying to hire for, so, you know, resemble the U.S., or overseas, or wherever it is. And that's a hard thing to do at times, but we stuck with it. And there's been other decisions I've noticed.

+ +

So, how do you make those decisions, one, and then, how do you stick with them when most companies or most people will say, "Hey, it's just too hard. Let's pivot and change it up"?

+ +

CHAD: Yeah, we have our values, five core values, and one of them is fulfillment. And I often refer to that as our North Star value, meaning that when we're faced with a decision as a company or as individuals, fulfillment is often the one that we most often look to as the guide for which direction to go in. And I think that that is really powerful for us. It causes us to choose things that other companies might not choose.

+ +

And it also is really powerful for us because it means that I don't need to be the one to make all of the decisions. You can make decisions based on what is fulfilling to you in your work. And that's very likely the right thing for everybody else at the company. And it may mean that we're a little bit less successful financially. But there are two aspects to success, you know, you need to be financially sustainable, but if you're unhappy in your work, if you're unfulfilled in your work, then that's not truly being successful. And so that's the guiding point of the way that we make a lot of decisions.

+ +

Take the example of going remote, we weren't really deciding between going back to the way things were or going fully remote. Going back to the way things were was not an option because we had already told everyone if you need to move if you need to be away from the studio you were previously part of, go do that. You don't need to worry about remaining at thoughtbot. And about 20 people moved away from where their studio had been located, which is about 20% of the company. So we were deciding between hybrid or fully remote. Going back to the way things were wasn't an option because we had already removed that from the table, I think, guided by supporting the team, fulfillment, trust, our values.

+ +

So then the decision-making comes, do we want to figure out how to be hybrid? Which we had done before in our history. And we understood, based on that past experience, that you have to work at that quite a bit to integrate everyone fully, and sort of if you don't, it becomes very tough or even just mediocre. And so it was, are we more excited about working at being the best hybrid organization in the world, or are we more excited at figuring out how to be the best remote company in the world?

+ +

You know, for me, that was an obvious choice. I was more excited about figuring out how to be the best remote company than I was about being the best hybrid company. So I think that that's an okay... [laughter] I think that's an okay way to make decisions. What are you more excited by? What are you going to be more fulfilled by in your work than that? And so that's, you know, sort of dissecting that decision-making, you know, part of what tipped us over the edge in terms of choosing to be fully remote.

+ +

VICTORIA: I like that you said that you tried to make it so that you're not the one making all the decisions. [chuckles] And I felt that as a managing director and as an associate director that there is a very purposeful tact of when I'm bringing issues to leadership. The response I get back is very careful not to tell me what to do. [laughs]

+ +

CHAD: Yeah. I'm sure it's annoying at times, right? [laughter]

+ +

VICTORIA: I think it's a shift, right? Like, if you're coming from a typical, like, top-down organization, it can be a real mind shift, and it can be frustrating. But then, once you embrace it, it can be very fulfilling, like you said.

+ +

CHAD: Part of why we do that, too, is because if you're not careful, you know, one of our other values is trust. And we really do trust people more than they're used to. And our other value is self-management. So, people should be left to their own devices. People at thoughtbot take initiative in their work to make decisions, those kinds of things. And so, at the intersection of trust and self-management, what happens in a lot of other cultures is this idea of permission. If you have to ask permission to do things, then you can't truly self-manage.

+ +

So, when you come to a leader and you're asking for something, it's hard for that not to be articulated as asking for permission for something in a traditional sort of power hierarchy. I encourage people at thoughtbot to think about...in the way that our culture works, it's a lot better to frame things as asking for advice because there are people who have more experience in a certain area than you or whatever.

+ +

And so a much better way of framing the conversation that you want to have with those people is instead of just asking open-ended questions, which it's very easy to misunderstand as basically just asking for permission to do something, it's better to say, like, "Here's what I know. Here's what I would do based on what I know. Do you have any advice for me based on that?" And then I can say, "Oh, well, here's what I know. [laughs] Can I share that with you?"

+ +

And then, you can take that information in, and then you can make the decision based on having that additional information. I don't want to make the decision for somebody. That's the way I think about it. If you're not sure what's happening, it can be pretty frustrating in our culture because we are sort of averse to telling other people what to do. We're happy to help people and give people information, but we don't like to tell people what to do.

+ +

WILL: Yeah, and I've definitely felt this, even as a developer here. But it has been the perfect fit for me because I love the, hey, we trust you. Go and do it. Go make decisions. Hey, even if you fail, let's come back and talk about it and move forward. But also the pushing me out of my comfort zone. There has been numerous times where I'm like, "Yeah, I don't think I can do that." And someone in leadership is like, "I think you can. Let's try it out. Let's do it. If you have any questions, come talk to me. I'll help you in any way I can." So, even as a developer, I feel that same way.

+ +

And so I guess my question for you, Chad, is there's been a lot of decisions that I've seen you make or even this part right here, the trust. Because sometimes, money can override that when you're a CEO, especially because of jobs and everything. But you said fulfillment, and you had the values. But, Chad, as the CEO, like, why do you personally lead like that and make decisions like that?

+ +

CHAD: It's a really good question. [laughs]

+ +

WILL: I always wanted to peel back the layers of Chad.

+ +

VICTORIA: [laughs]

+ +

WILL: So that's what it is. [laughs]

+ +

CHAD: To tie it back to development, just like you just did, I think a lot of our values and the way that we do things come from the way that we believe products should be designed and built. When I'm working on a project, I don't want to be told how to do everything. I don't want every ticket to be specified without me being part of the understanding or decision-making process.

+ +

I want to be able to collaborate with the people that I'm working with, understand the problems that we're trying to solve, and then pick up the ticket and do the research, figure out the best way to solve it or be part of that. And when it's not clear to me, ask questions, learn from other people about the right way to solve something might be, and then to implement it in the best way that I know how, and collaborate with the people that I'm working with as I do that.

+ +

And then I pick up that ticket, and I'm responsible for deploying it to staging and asking for acceptance of it. And I'm responsible for deploying it to production. So I'm pushing my work. I have agency over my work at every step of the way. I hope everyone who's listening has had an opportunity to be on a project where you've truly had agency over your own work. It's a really good, fulfilling feeling. And so I think that's where it comes from. I think that's what I try to bring to everything that I do.

+ +

VICTORIA: And I think that philosophy is what creates such a compelling company culture and makes people want to work here, right?

+ +

CHAD: I think so. Particularly because the work we do, the majority of us are designers and developers, but I don't think it's just design and develop. Like, it resonates a lot the relation to product work. But I think that's true for fulfillment in your own work generally across the board, no matter what your role is. People would rather have agency over their own work than to be micromanaged, to be told what to do all of the time.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: In 20 years of hiring people and building products, what has really changed in terms of what you see customers looking for in building products, and what's stayed the same?

+ +

CHAD: There's a lot that has changed, mostly in terms of platforms and practices. When we were first getting started out, the practice of test-driven development was not generally established as a best practice. It was one that we needed to advocate for and fight for, and really put ourselves out there as this is what we believe about the way good products are built, and if you don't want that, we're not a good fit for each other. So that's what I mean by practices. A lot of those things that used to be controversial we sort of won on as they played out as, yes, general agreement now about certain best practices. And so that has evolved over time.

+ +

The other is mobile development. You know, when we first started, that wasn't really a thing. We did some mobile development early on for Palm platforms and for Motorola platforms using different versions of Java. It was a very different ecosystem. And mobile development has evolved a lot and become...almost every project we do has some mobile component. And a lot of them are native mobile applications with an API back end that we're building as well. So that has been a big change.

+ +

The things that stay the same are, I would say, the things that we have sort of been constant about. So in the way that best practices change or evolve, the constant has been that we put ourselves out there, willing to be opinionated about what we believe the current best way of working is. That means that the clients who work with us are coming to us wanting that.

+ +

And that leads to a culture of work and quality and that kind of thing, which I think has been pretty constant over the years. But it's not because we didn't try. Like, if we were willing to be anything to anybody and to compromise all the time and those kinds of things, it wouldn't be a constant. But we work at it, but I think that feeling of what it's like to do this work has been a constant.

+ +

WILL: Speaking of changes and constant changes sometimes, what's the story behind the handbook? Everyone at the company can access the handbook through GitHub and how [inaudible 29:35] Whose idea was it? How did that come to be? And explain how it's always changing and what that looks like.

+ +

CHAD: Yeah. So, like you said, we have our company handbook and the public playbook in a source code repository that everyone at the company collaborates on and has access to change. I don't remember who initially moved it into version control. It started as a document. We worked with an outside payroll or HR company to make as our first company handbook. It had policies and those kinds of things in it. At one point, you know, we were doing some revisions, and maybe me, maybe somebody else said, "Let's move this out of this," whatever it was at the time, Word doc, or whatever, "and move it into Markdown and natural place we want to have version control on it."

+ +

But even though we moved the document into version control and even though everyone at the company technically had access to it, I think for many years, we still did things like a lot of companies do, which is the version control in and of itself isn't the special thing. It's using GitHub issues to track actual problems that we know about, or potential issues that we know about, defects in our policies, our practices, the company itself, just like we do on our software products. That was the actual fundamental shift that we made because it completely changed the way that we make change at the company and organize the work that we do to improve the company.

+ +

And the way that that happened was, I think, prior to that, we made changes in a lot of ways that companies make changes. So some people know about some things, some people don't. Typically, senior leaders will get together often in meetings and talk about the issues that they see. And they tend to result in really big changes all at once that attempt to address multiple issues or make big reorganizational changes. And there's a tendency not to work iteratively when you work that way, and we did the same thing.

+ +

So the sort of final big event that happened that triggered the fundamental change of working was, at the time, we had an unlimited time off policy. We had gone to that a few years prior because it was a trend in general. But also, we were tired of sort of tracking time and the permission that happens around time off and all that kind of stuff. So we had sort of blown it all up and gone to an unlimited time off policy. But it's more well understood now that unlimited time off policies have a few issues. And we were seeing those issues.

+ +

Time off was very inconsistent among everyone on the team. Particularly, new people would join the company, and they'd be like, okay, yes, but how much time am I supposed to really take? So that was one issue. Another issue was we wanted to increase the amount of parental leave that we offered as a company, like, on paper. Now, technically, we had the unlimited time off policy, but you want to give guidance to people, and you want to be able to say in a job advertisement that you have this much parental leave, you know.

+ +

And because we're a consulting company and we make our revenue when people are working, the question was asked, how much can we say that we have for parental leave? And it was a very uncomfortable position for us to be in to not be able to work that financially because we could say, okay, we have 12 weeks of parental leave. But, at any point in time, anyone else could take more time off for any other reason because we had unlimited time off policy. And the idea that we couldn't prioritize one kind of time off over another to make it work financially was uncomfortable to us.

+ +

And then, the state of California passed a sick time law, which was fundamentally incompatible with unlimited time off policies that lump sick time and vacation time together. And so we knew about these things. We got together in a meeting. We talked about them. And we put together a pull request to the handbook that, you know, we said, you know, we could probably fix any one of these problems. But probably all signs are pointing to just switching back to a regular time off policy.

+ +

And so we put together a pull request. You can probably guess since I'm telling this story that, generally, people were very surprised. It was a big change to take in all at once. And I think even though we have a high level of trust, as a company, it was hard for people who generally viewed an unlimited time off policy as a good thing. You know, they were worried that there was some ulterior motive there, that something was being taken away for some reason, maybe financial. So we worked through it, and the pull request is there for everyone at the company, so you can see.

+ +

Anna, when she opened the pull request, outlined all of those reasons why, but it was a lot of information to take in. And after we made it through, it sort of caused me to reflect on the process. And there was good criticism from members of the team at the time about the process, and we really took that in. And I think it was the state of California passing that law that the solution that we arrived at to mind for me because they passed the law in, whatever it was, the spring or the summer. And it wasn't going to go into effect until the new year.

+ +

And that's really no different than, you know, a new version of a library is going to come out, or a new version of an operating system or a browser is going to come out. And we know it's going to break our app. What do we do? We create a ticket in the backlog. We describe what the problem is. We prioritize it among everything else we're working on. And we make sure that the fix is in place in time for that to be released.

+ +

And yet, we weren't doing that for these very obvious defects or things that we knew were going to break an existing policy against this kind of stuff. So I was like, we could use GitHub issues to log problems that we know about that are out there, and not only would that have led to a lot more transparency along the way. When a change was made, people could have come along that journey with us of identifying the problem, being aware of it, being part of problem-solving, and coming to a resolution, and then getting a pull request.

+ +

But more fundamentally, I think once you start to work that way, probably would have never made the change that we did in the first place because this way causes you to work more incrementally, to work more iteratively, to take each of the problems to try to identify the root cause and the best way to fix it. And very often, that is a smaller change that you can put into place more quickly. And we know that we don't need to get it perfect. We don't need to change absolutely everything about this all at once in order to fix every problem. We just need to make tomorrow better than today.

+ +

If we can do that, then we know that, over time, it adds up to significant positive change that is very different a year from now or two years from now than what we're doing today. But we do that by chipping away and making tomorrow better than today. And so working this way with these discrete tickets, with this thing, there are downsides too, don't get me wrong. It's not all sunshine and rainbows. It's hard to work this way. But those are some of the benefits and sort of the story of how we arrived at how we do things.

+ +

WILL: I love that because I'm familiar with creating PRs, commenting on PRs, just giving feedback through PRs. And also, I've never been in a leadership meeting at thoughtbot, like, just never been in one. But I know that if I comment on a PR, my voice is heard with leadership making the decision. I love that idea.

+ +

CHAD: Yeah, leadership meetings at thoughtbot are actually very boring.

+ +

WILL: [laughs]

+ +

CHAD: Because the only things that we're talking about that aren't represented in GitHub issues are things that aren't proper for GitHub issues, so they're individual personal problems or things like that, or, hey, we're doing a leadership training and, you know, talking about that. Actual change, actual things that happen, are represented in those GitHub issues. And that's why it's super important that we have issues for everything because when we truly work this way, if something's not represented as an issue, it's not getting worked on.

+ +

There's not a lot happening in leadership meetings other than those things that aren't ideal for GitHub issues, or we're going through, and we're saying, "Hey, this issue has been sitting around for a while," or "What's the update?" And you'll often see someone comment after the fact about an issue. Now, that being said, I think one of the hardest things about this is that when you expose these big issues, it can be a little discouraging over time to have them be around there to be not closed.

+ +

But the way...I'll bring this back to our product work as well, like, when you identify...at least this is the case for me. A bug could have been there for two years, [chuckles] and I don't know about it, and therefore, it's out of sight, out of mind. I didn't know about it. But the minute I find out about a bug in a product that I'm working on, I can't stop thinking about it, and I want to fix it so badly. It becomes my top priority right away. [laughs]

+ +

And I have to remind myself that just because I know about something now doesn't mean it's actually the highest priority item, or that I can fix it, or that I should take the time to fix it. I know it's my natural tendency to do that. So shedding light on something that's positive in and of itself, and then we can chip away at that over time. And this way of working allows us to tackle big problems. But sometimes it doesn't feel so great because you're identifying sort of defects in the company itself that make everybody uncomfortable. But I would rather light be shed on those so that we have a chance to improve it than to have it go unidentified, just like bugs in our products.

+ +

VICTORIA: And just to illustrate, we have 162 open issues on our handbook. [laughter] But, you know, from my perspective, that makes me really excited, like, people are engaging with it. They're putting in issues and creating it. Because I've converted a company handbook to GitHub before, and no one ever looked at it. [laughs] So it was actually kind of nice that --

+ +

CHAD: [laughs]

+ +

VICTORIA: You said that it took some time to build up that interaction with it and make people feel comfortable. And I wanted to ask about actually your Dungeons & Dragons campaigns that you run with the company. And I'm wondering what skills or practices from that comes over into your leadership style or the culture at thoughtbot.

+ +

CHAD: Ooh, I'm not sure it's as deep as that, Victoria.

+ +

VICTORIA: [laughs]

+ +

CHAD: I just really like [laughter] playing Dungeons & Dragons. But I will say the itch that it scratches for me and the reason why I like Dungeons & Dragons, and the reason why I'm really happy to play it with thoughtbot people...my degree is computer science. But all throughout elementary school, high school, I did improv and theater, and I have a degree in theater as well.

+ +

For a long time, Dungeons & Dragons is essentially doing group improv with other people around a game. And to be able to bring those two things together with a group of people that I like to have fun with it's a really great outlet. And I really enjoy it. But I'm not sure that there's anything deeper than it sort of scratches that performance itch that I have with a group of people that I like to hang out with.

+ +

VICTORIA: That's fair. And then, just to kind of go back to one of our earlier questions we asked —what would you go back in time and advise your younger self —now, what if your younger person could travel to the future and give you some advice, looking at where you are at now?

+ +

CHAD: The only way that I've done this for 20 years is day by day. Like, each day, you get up, and you approach each day. This is the way I do it anyway. It's like I approach each day as a fresh day. And now, over thousands of days, it's been 20 years. And I think that that is part of why at least I've been able to do this so long is I don't do a lot of dwelling on what happened yesterday. I think about today and tomorrow much more than I do about what happened yesterday.

+ +

The upside is I've been able to do this for 20 years. [laughs] The downside to that is you tend to not reflect so much on the good things, just like you don't reflect so much on the bad things. You tend to not celebrate the milestones when they happen or appreciate them as much because you're onto the next thing. You're thinking about tomorrow rather than yesterday. And so I would think that if my younger self came forward and talked to me today, I think the thing that he would say is like, hey, look at where you are, look at what you've done. Take a moment [laughs] to celebrate not only your work but, you know, this is true for the people around me.

+ +

I tend not to celebrate the accomplishments as much and everything because I'm very much someone who sort of lives in maybe not even the moment but the next moment that's about to happen. And so I think the person would say, relax a little bit, have a little bit more fun. Take a moment to celebrate the people around you a little bit more. I think that's what I would say to myself.

+ +

WILL: I love learning things that I didn't know about thoughtbot. So this has been perfect.

+ +

CHAD: Thank you both for the really thoughtful questions. And on the note of what I just [inaudible 44:53], thank you for everything that you both do at thoughtbot. I really appreciate it. We couldn't have accomplished everything that we have without the individuals [inaudible 45:01]. So I'm here sort of representing thoughtbot for our 20th anniversary, but it's not just me who got us to this point. It's been a lot of other people over the many years making it happen. And so I appreciate both of you for helping make it happen.

+ +

VICTORIA: Well, thank you. And again, thank you so much for joining us.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad joins cohosts Victoria and Will to talk about thoughtbot's 20th birthday! 🤖🎉

+ +

In this episode, you'll find the 411 on the thoughtbot mascot, "Ralph," taking the company fully remote, and our company values and how we believe products should be designed and built!

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your host, Will Larry. And with us today is our other host, Chad Pytel, the CEO of thoughtbot. Which, we're celebrating 20 years of business this year. Chad, welcome.

+ +

CHAD: Oh, it's good to have the tables turned on me. And I'm looking forward to the discussion today.

+ +

VICTORIA: Great. We have a whole set of questions, some of which come from other employees within thoughtbot. So we're really excited to dig into it today. Why don't we start with thoughtbot's iconic logo, the Ralph bot, and the little red robot that everyone knows thoughtbot for? And we call him Ralph within thoughtbot. So, how did Ralph come to be? Where does his design come from? And how did that become part of the company mascot?

+ +

CHAD: I'm happy to tell the story. But I have a question for both of you: have you ever heard me call the robot Ralph?

+ +

WILL: [laughs] No.

+ +

VICTORIA: I don't think I've ever heard you refer to the robot.

+ +

WILL: [laughs]

+ +

VICTORIA: So, if you did call it, I don't know what you would call it.

+ +

WILL: Oh, who started that? [laughs]

+ +

CHAD: It was someone who was at the company, Matt Jankowski.

+ +

WILL: [laughs]

+ +

VICTORIA: Ah, I see.

+ +

CHAD: I actually don't like the name. I think it's a terrible name for the robot. [laughs] I don't understand why the robot has to be gendered at all. And so I've never said that that's the robot's name. You know, when you're CEO, you have to pick your battles.

+ +

WILL: [laughs] Yes.

+ +

CHAD: Yeah. So that's the unofficial name of the robot, I think. And Matt started calling it that because Matt's a big fan of coming up with names for things. And yeah, so, at some point, he started calling it that. And it sort of stuck as people joined the company and just sort of assumed that that's what the robot's called.

+ +

We didn't start with this logo. Logo has always been a robot. But the thing we started with was an illustration based off of a tin robot that I think either one of us had or that we saw a picture of. Another Matt, who is one of the founders of the company, sketched it. He was a designer as well as a developer. And we used it for a few years.

+ +

But what we learned over the course of it as we gained more exposure is that, actually, it's a really common tin toy robot. And you can find a lot of other art and illustration and uses of it in stock photography and everything. Which at first was good because then we could get a bunch of stock photography, and it was our logo. But then we realized, ooh, this is not something that we really own or have control over. So we started to think about creating our own robot logo from scratch.

+ +

Since we're a design firm, and I think it's notoriously hard to design things for yourself, we actually went to another agency that we were friends with and hired them to work with us to create the logo. And I have to say I was probably the worst client ever.

+ +

WILL: [laughs]

+ +

CHAD: Because I was asking...I had a particular vision in mind for this idea of, like, a powerful robot. And we kept on doing sketches, after sketch, after sketch, and it was really hard. We couldn't arrive at something that seemed powerful, that didn't seem aggressive. The logo at the time was a 3D representation of the robot. And it was really hard to also make a new 3D robot that looked powerful but not aggressive. And we just banged our heads against that for a long time. I think it was a couple of months.

+ +

Until one day, I just said, you know what? We're not going to do it. Let's just stop trying to do this. [chuckles] Let's just do the simplest 2D representation of a robot that we can think of. And just going back to the drawing board starting over, we arrived at the logo we have today. Now we have to deal with the fact that it looks a lot like the Android logo. [laughter] But that's the, I guess, the story of the robot.

+ +

WILL: So, first off, scratching the name Ralph. [laughs]

+ +

CHAD: No, no, you can use it. I just think it's funny.

+ +

WILL: Definitely. Second thing is Chad is not a good client when working with designers. No, I'm just joking. [laughs]

+ +

CHAD: No, it's totally true.

+ +

WILL: [laughs]

+ +

CHAD: You know, when we have strong opinions that are mostly preferences, that leads to people being bad clients. [laughter] Because there was no reasoning behind, you know, the preferences. It was just what I had in my head. And so it wasn't until I let that go that we were able to arrive at something usable.

+ +

WILL: [laughs] That's awesome. So, was the robot a passion for you, or was it just a toy that one of the founders, employees had, and that's where you went with it, how you got your inspiration?

+ +

CHAD: The name thoughtbot with the bot on the end comes from...because before we started thoughtbot, we did a lot of Java development as a group, same people I went to school with them. We did projects together. And we would follow the pattern where you sort of have an object and then a manager object or a service object. And it was a common naming pattern. If you have orders or customers, then the service object might be called order manager or customer manager. And, in our code, we tended to not do that and instead do bots. So we would have order bot over orders, customer bot over customers.

+ +

So, when we were brainstorming names for the company, we naturally tended to put bot on the end because that was our typical naming convention in the projects we were doing together. And so there wasn't anything particular about robots that we cared about at all. [laughter] It was that naming convention, which then extended to, okay, well, it's the thoughtbot. And so it should be a robot with thoughts on it or thought lines or something like that. That's where it came from.

+ +

VICTORIA: I love to hear that. I'm learning so much myself I didn't know before even as a thoughtbot employee.

+ +

WILL: [laughs]

+ +

VICTORIA: It's been 20 years since you started the business. I want to start...or go back in time. So, if you could go back and give yourself, the younger version of you 20 years ago, some advice, what would you say?

+ +

CHAD: I've gotten similar versions of this question on different shows. My answer for the last several years has been pretty consistent. So I'll give that one, and then I think I have another one too. The thing that I didn't realize at the time that I think I would be better for and the company would be better for I had a big blind spot in terms of I started thoughtbot with friends. We were the same age. We were all five White guys in our 20s, just out of school. That was the people that I was doing projects with; that was the people I was surrounded by in school. And it was a big blind spot.

+ +

And, if I could go back in time, I would try to open my eyes to the fact that that was the case. And I think that I would be a lot better for it. And I think the company would be a lot better for having started with a more diverse team from the beginning because it makes us worse when you don't start off that way. It's harder and harder to correct it the longer it goes on. And so that would be something that I would go back and try to tell myself. Look at what you're doing. You don't realize now, but it is important.

+ +

WILL: So, because we started talking about this at Summit a month ago, and it was amazing to hear that you're saying that because, at the same time, we're at this all-staff event, and we're able to see how diverse our team is and stuff like that. How has the journey been increasing the diversity of the team? Like, I look at our team photo, and it's just amazing to see the diversity in every level, especially in leadership, the diversity in leadership. And I know we haven't, quote, unquote, "arrived." So, how has that journey been? And what does it look like in the future?

+ +

CHAD: Yeah, I mean, we've clearly made a lot of progress on this. It is better and easier now than it was in the early days because nobody wants to be the first. Nobody wants to be the first woman on the team. No one wants to be the first person of color on the team. You don't know when you're coming into an organization like that, whether it's the kind of place for you or whether you're going to run into problems. And so now that we've made some progress, that in and of itself makes it easier to continue on the journey.

+ +

But when we were just getting started on that, we really needed to do a lot to intentionally fix it without tokenizing people, which is not easy to do. And so we're very fortunate that we have made progress. And I appreciate everyone along the way putting themselves out there, willing to be the first, or the second, or the third. I know that that's not easy, and it's made thoughtbot a better place now that we've progressed.

+ +

WILL: Yeah, and I want to interrupt and say this: after that conversation, I remember I had to split and run to another event. While at that event, I met one of the first ladies that were on the team. And I started chatting about her experience. And it was amazing to see the transformation from the beginning to where it is now. So it was just really good to have that conversation with you, and then go talk to her and just, I guess, see the complete picture, so that's amazing because she's still on the team to this day.

+ +

CHAD: Yeah. But we're not done yet. Like you said, we still have [laughs], you know, we can always be better.

+ +

WILL: Where do you see it going in the future?

+ +

CHAD: Well, I think that even though the management team, the senior leadership team, we have made progress there, I think that that is an obvious area where we have more progress to go in terms of making sure that people at the company are represented...the demographics of the people at the company are represented at every level of the company, especially when you have a culture like we do where the leaders are the people who have been here the longest. And we don't have so many of those positions opening up over the years.

+ +

In fact, over the last five years, we've eliminated more of those positions in order to reduce overhead and to stay financially sustainable. So we actually have less of those opportunities than we have in the past, and so that holds us back. And so we have to figure out how to handle that and to do better with that.

+ +

The other is, you know, one of the biggest changes over the last three years is going fully remote. And that has enabled us to hire the best people, no matter where they live, in the time zones that we operate in. And that has been really great for bringing new people, new energy onto the team. That is going to continue into the future. And we're going to see the demographics of the company continue to shift away from the United States. 60% of the company is now outside of the U.S., and that's going to keep on going. And that doesn't make us any worse off. It makes us better.

+ +

VICTORIA: Yeah, I wanted to ask you about that. So, thoughtbot, as I understand it before we went fully remote, was known for having an amazing in-person office culture. So, what was that shift like for you? And how do you maintain that company culture after going fully remote?

+ +

CHAD: Well, here's the honest answer.

+ +

WILL: [laughs]

+ +

CHAD: The honest answer was I was already not part of that office company culture. I was traveling one week out of every month to one of the studios. I didn't interact with people in the same way because of my position within the company. I was out of the studio a lot of the time. And even when I wasn't there, I was already working from home a few days a week because of my travel schedule or something like that. So moving to fully remote...and I was already sort of over-commuting to 45 minutes each way to the office.

+ +

And so moving to fully remote has made things a lot better for me because I'm traveling a lot less. I get to be home with my family a lot more. I don't have that commute time. And my experience now, I think, is more similar to everyone else on that team. And I feel like we're all sharing more equally in what the experience is at thoughtbot. And so when I work to improve that, I'm not only working to improve it for me. I'm working to improve it for everybody.

+ +

And so there are trade-offs. It is certainly different for the individual designer or developer at thoughtbot than it was before. But I think that the benefits of having the team that we have now, people being able to live where they want to live and to get that commute time back, outweigh the downsides of changing that company culture.

+ +

VICTORIA: The other part is about just that shift, right? Of it was COVID. [laughs] Obviously, a lot of people were going remote at that time. So I'm just curious how that experience really happened for thoughtbot. I know how it happened for me at the company I was at. [laughs]

+ +

CHAD: Well, it was certainly abrupt, you know. And, at the time, we thought, okay, we're going to shut down the office for two weeks, and then we'll all be back. And that, very quickly, was proven to be wrong. When it came to our actual work, the biggest shift we had was in the way that we collaborated with clients. But we were already collaborating with each other across studios in a distributed way. And so that was a more natural progression.

+ +

I think the biggest shift was the way that our projects were working and collaborating with clients. You know, we would have clients in the office with us, too, sitting right next to us. And so figuring out how to do design sprints fully remotely, to ramp up the amount of remote pair programming that we were doing, those were the big changes, I think.

+ +

And then you had the cultural ones, too, that you really need to work at when two people are getting a snack in the kitchen and having an off-hand chat about something. When you're fully remote, that doesn't happen. You need to put a lot more effort into those sort of what would have been casual conversations previously.

+ +

WILL: So, and it seems like...just having a conversation with you, I know that it wasn't an easy decision to change over. And my question is, how do you make decisions, especially the hard ones that are not...and you stick with them? For example, I know, like, with hiring, we're talking about the diversity and creating a diverse pool that kind of resembles the area that we're trying to hire for, so, you know, resemble the U.S., or overseas, or wherever it is. And that's a hard thing to do at times, but we stuck with it. And there's been other decisions I've noticed.

+ +

So, how do you make those decisions, one, and then, how do you stick with them when most companies or most people will say, "Hey, it's just too hard. Let's pivot and change it up"?

+ +

CHAD: Yeah, we have our values, five core values, and one of them is fulfillment. And I often refer to that as our North Star value, meaning that when we're faced with a decision as a company or as individuals, fulfillment is often the one that we most often look to as the guide for which direction to go in. And I think that that is really powerful for us. It causes us to choose things that other companies might not choose.

+ +

And it also is really powerful for us because it means that I don't need to be the one to make all of the decisions. You can make decisions based on what is fulfilling to you in your work. And that's very likely the right thing for everybody else at the company. And it may mean that we're a little bit less successful financially. But there are two aspects to success, you know, you need to be financially sustainable, but if you're unhappy in your work, if you're unfulfilled in your work, then that's not truly being successful. And so that's the guiding point of the way that we make a lot of decisions.

+ +

Take the example of going remote, we weren't really deciding between going back to the way things were or going fully remote. Going back to the way things were was not an option because we had already told everyone if you need to move if you need to be away from the studio you were previously part of, go do that. You don't need to worry about remaining at thoughtbot. And about 20 people moved away from where their studio had been located, which is about 20% of the company. So we were deciding between hybrid or fully remote. Going back to the way things were wasn't an option because we had already removed that from the table, I think, guided by supporting the team, fulfillment, trust, our values.

+ +

So then the decision-making comes, do we want to figure out how to be hybrid? Which we had done before in our history. And we understood, based on that past experience, that you have to work at that quite a bit to integrate everyone fully, and sort of if you don't, it becomes very tough or even just mediocre. And so it was, are we more excited about working at being the best hybrid organization in the world, or are we more excited at figuring out how to be the best remote company in the world?

+ +

You know, for me, that was an obvious choice. I was more excited about figuring out how to be the best remote company than I was about being the best hybrid company. So I think that that's an okay... [laughter] I think that's an okay way to make decisions. What are you more excited by? What are you going to be more fulfilled by in your work than that? And so that's, you know, sort of dissecting that decision-making, you know, part of what tipped us over the edge in terms of choosing to be fully remote.

+ +

VICTORIA: I like that you said that you tried to make it so that you're not the one making all the decisions. [chuckles] And I felt that as a managing director and as an associate director that there is a very purposeful tact of when I'm bringing issues to leadership. The response I get back is very careful not to tell me what to do. [laughs]

+ +

CHAD: Yeah. I'm sure it's annoying at times, right? [laughter]

+ +

VICTORIA: I think it's a shift, right? Like, if you're coming from a typical, like, top-down organization, it can be a real mind shift, and it can be frustrating. But then, once you embrace it, it can be very fulfilling, like you said.

+ +

CHAD: Part of why we do that, too, is because if you're not careful, you know, one of our other values is trust. And we really do trust people more than they're used to. And our other value is self-management. So, people should be left to their own devices. People at thoughtbot take initiative in their work to make decisions, those kinds of things. And so, at the intersection of trust and self-management, what happens in a lot of other cultures is this idea of permission. If you have to ask permission to do things, then you can't truly self-manage.

+ +

So, when you come to a leader and you're asking for something, it's hard for that not to be articulated as asking for permission for something in a traditional sort of power hierarchy. I encourage people at thoughtbot to think about...in the way that our culture works, it's a lot better to frame things as asking for advice because there are people who have more experience in a certain area than you or whatever.

+ +

And so a much better way of framing the conversation that you want to have with those people is instead of just asking open-ended questions, which it's very easy to misunderstand as basically just asking for permission to do something, it's better to say, like, "Here's what I know. Here's what I would do based on what I know. Do you have any advice for me based on that?" And then I can say, "Oh, well, here's what I know. [laughs] Can I share that with you?"

+ +

And then, you can take that information in, and then you can make the decision based on having that additional information. I don't want to make the decision for somebody. That's the way I think about it. If you're not sure what's happening, it can be pretty frustrating in our culture because we are sort of averse to telling other people what to do. We're happy to help people and give people information, but we don't like to tell people what to do.

+ +

WILL: Yeah, and I've definitely felt this, even as a developer here. But it has been the perfect fit for me because I love the, hey, we trust you. Go and do it. Go make decisions. Hey, even if you fail, let's come back and talk about it and move forward. But also the pushing me out of my comfort zone. There has been numerous times where I'm like, "Yeah, I don't think I can do that." And someone in leadership is like, "I think you can. Let's try it out. Let's do it. If you have any questions, come talk to me. I'll help you in any way I can." So, even as a developer, I feel that same way.

+ +

And so I guess my question for you, Chad, is there's been a lot of decisions that I've seen you make or even this part right here, the trust. Because sometimes, money can override that when you're a CEO, especially because of jobs and everything. But you said fulfillment, and you had the values. But, Chad, as the CEO, like, why do you personally lead like that and make decisions like that?

+ +

CHAD: It's a really good question. [laughs]

+ +

WILL: I always wanted to peel back the layers of Chad.

+ +

VICTORIA: [laughs]

+ +

WILL: So that's what it is. [laughs]

+ +

CHAD: To tie it back to development, just like you just did, I think a lot of our values and the way that we do things come from the way that we believe products should be designed and built. When I'm working on a project, I don't want to be told how to do everything. I don't want every ticket to be specified without me being part of the understanding or decision-making process.

+ +

I want to be able to collaborate with the people that I'm working with, understand the problems that we're trying to solve, and then pick up the ticket and do the research, figure out the best way to solve it or be part of that. And when it's not clear to me, ask questions, learn from other people about the right way to solve something might be, and then to implement it in the best way that I know how, and collaborate with the people that I'm working with as I do that.

+ +

And then I pick up that ticket, and I'm responsible for deploying it to staging and asking for acceptance of it. And I'm responsible for deploying it to production. So I'm pushing my work. I have agency over my work at every step of the way. I hope everyone who's listening has had an opportunity to be on a project where you've truly had agency over your own work. It's a really good, fulfilling feeling. And so I think that's where it comes from. I think that's what I try to bring to everything that I do.

+ +

VICTORIA: And I think that philosophy is what creates such a compelling company culture and makes people want to work here, right?

+ +

CHAD: I think so. Particularly because the work we do, the majority of us are designers and developers, but I don't think it's just design and develop. Like, it resonates a lot the relation to product work. But I think that's true for fulfillment in your own work generally across the board, no matter what your role is. People would rather have agency over their own work than to be micromanaged, to be told what to do all of the time.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: In 20 years of hiring people and building products, what has really changed in terms of what you see customers looking for in building products, and what's stayed the same?

+ +

CHAD: There's a lot that has changed, mostly in terms of platforms and practices. When we were first getting started out, the practice of test-driven development was not generally established as a best practice. It was one that we needed to advocate for and fight for, and really put ourselves out there as this is what we believe about the way good products are built, and if you don't want that, we're not a good fit for each other. So that's what I mean by practices. A lot of those things that used to be controversial we sort of won on as they played out as, yes, general agreement now about certain best practices. And so that has evolved over time.

+ +

The other is mobile development. You know, when we first started, that wasn't really a thing. We did some mobile development early on for Palm platforms and for Motorola platforms using different versions of Java. It was a very different ecosystem. And mobile development has evolved a lot and become...almost every project we do has some mobile component. And a lot of them are native mobile applications with an API back end that we're building as well. So that has been a big change.

+ +

The things that stay the same are, I would say, the things that we have sort of been constant about. So in the way that best practices change or evolve, the constant has been that we put ourselves out there, willing to be opinionated about what we believe the current best way of working is. That means that the clients who work with us are coming to us wanting that.

+ +

And that leads to a culture of work and quality and that kind of thing, which I think has been pretty constant over the years. But it's not because we didn't try. Like, if we were willing to be anything to anybody and to compromise all the time and those kinds of things, it wouldn't be a constant. But we work at it, but I think that feeling of what it's like to do this work has been a constant.

+ +

WILL: Speaking of changes and constant changes sometimes, what's the story behind the handbook? Everyone at the company can access the handbook through GitHub and how [inaudible 29:35] Whose idea was it? How did that come to be? And explain how it's always changing and what that looks like.

+ +

CHAD: Yeah. So, like you said, we have our company handbook and the public playbook in a source code repository that everyone at the company collaborates on and has access to change. I don't remember who initially moved it into version control. It started as a document. We worked with an outside payroll or HR company to make as our first company handbook. It had policies and those kinds of things in it. At one point, you know, we were doing some revisions, and maybe me, maybe somebody else said, "Let's move this out of this," whatever it was at the time, Word doc, or whatever, "and move it into Markdown and natural place we want to have version control on it."

+ +

But even though we moved the document into version control and even though everyone at the company technically had access to it, I think for many years, we still did things like a lot of companies do, which is the version control in and of itself isn't the special thing. It's using GitHub issues to track actual problems that we know about, or potential issues that we know about, defects in our policies, our practices, the company itself, just like we do on our software products. That was the actual fundamental shift that we made because it completely changed the way that we make change at the company and organize the work that we do to improve the company.

+ +

And the way that that happened was, I think, prior to that, we made changes in a lot of ways that companies make changes. So some people know about some things, some people don't. Typically, senior leaders will get together often in meetings and talk about the issues that they see. And they tend to result in really big changes all at once that attempt to address multiple issues or make big reorganizational changes. And there's a tendency not to work iteratively when you work that way, and we did the same thing.

+ +

So the sort of final big event that happened that triggered the fundamental change of working was, at the time, we had an unlimited time off policy. We had gone to that a few years prior because it was a trend in general. But also, we were tired of sort of tracking time and the permission that happens around time off and all that kind of stuff. So we had sort of blown it all up and gone to an unlimited time off policy. But it's more well understood now that unlimited time off policies have a few issues. And we were seeing those issues.

+ +

Time off was very inconsistent among everyone on the team. Particularly, new people would join the company, and they'd be like, okay, yes, but how much time am I supposed to really take? So that was one issue. Another issue was we wanted to increase the amount of parental leave that we offered as a company, like, on paper. Now, technically, we had the unlimited time off policy, but you want to give guidance to people, and you want to be able to say in a job advertisement that you have this much parental leave, you know.

+ +

And because we're a consulting company and we make our revenue when people are working, the question was asked, how much can we say that we have for parental leave? And it was a very uncomfortable position for us to be in to not be able to work that financially because we could say, okay, we have 12 weeks of parental leave. But, at any point in time, anyone else could take more time off for any other reason because we had unlimited time off policy. And the idea that we couldn't prioritize one kind of time off over another to make it work financially was uncomfortable to us.

+ +

And then, the state of California passed a sick time law, which was fundamentally incompatible with unlimited time off policies that lump sick time and vacation time together. And so we knew about these things. We got together in a meeting. We talked about them. And we put together a pull request to the handbook that, you know, we said, you know, we could probably fix any one of these problems. But probably all signs are pointing to just switching back to a regular time off policy.

+ +

And so we put together a pull request. You can probably guess since I'm telling this story that, generally, people were very surprised. It was a big change to take in all at once. And I think even though we have a high level of trust, as a company, it was hard for people who generally viewed an unlimited time off policy as a good thing. You know, they were worried that there was some ulterior motive there, that something was being taken away for some reason, maybe financial. So we worked through it, and the pull request is there for everyone at the company, so you can see.

+ +

Anna, when she opened the pull request, outlined all of those reasons why, but it was a lot of information to take in. And after we made it through, it sort of caused me to reflect on the process. And there was good criticism from members of the team at the time about the process, and we really took that in. And I think it was the state of California passing that law that the solution that we arrived at to mind for me because they passed the law in, whatever it was, the spring or the summer. And it wasn't going to go into effect until the new year.

+ +

And that's really no different than, you know, a new version of a library is going to come out, or a new version of an operating system or a browser is going to come out. And we know it's going to break our app. What do we do? We create a ticket in the backlog. We describe what the problem is. We prioritize it among everything else we're working on. And we make sure that the fix is in place in time for that to be released.

+ +

And yet, we weren't doing that for these very obvious defects or things that we knew were going to break an existing policy against this kind of stuff. So I was like, we could use GitHub issues to log problems that we know about that are out there, and not only would that have led to a lot more transparency along the way. When a change was made, people could have come along that journey with us of identifying the problem, being aware of it, being part of problem-solving, and coming to a resolution, and then getting a pull request.

+ +

But more fundamentally, I think once you start to work that way, probably would have never made the change that we did in the first place because this way causes you to work more incrementally, to work more iteratively, to take each of the problems to try to identify the root cause and the best way to fix it. And very often, that is a smaller change that you can put into place more quickly. And we know that we don't need to get it perfect. We don't need to change absolutely everything about this all at once in order to fix every problem. We just need to make tomorrow better than today.

+ +

If we can do that, then we know that, over time, it adds up to significant positive change that is very different a year from now or two years from now than what we're doing today. But we do that by chipping away and making tomorrow better than today. And so working this way with these discrete tickets, with this thing, there are downsides too, don't get me wrong. It's not all sunshine and rainbows. It's hard to work this way. But those are some of the benefits and sort of the story of how we arrived at how we do things.

+ +

WILL: I love that because I'm familiar with creating PRs, commenting on PRs, just giving feedback through PRs. And also, I've never been in a leadership meeting at thoughtbot, like, just never been in one. But I know that if I comment on a PR, my voice is heard with leadership making the decision. I love that idea.

+ +

CHAD: Yeah, leadership meetings at thoughtbot are actually very boring.

+ +

WILL: [laughs]

+ +

CHAD: Because the only things that we're talking about that aren't represented in GitHub issues are things that aren't proper for GitHub issues, so they're individual personal problems or things like that, or, hey, we're doing a leadership training and, you know, talking about that. Actual change, actual things that happen, are represented in those GitHub issues. And that's why it's super important that we have issues for everything because when we truly work this way, if something's not represented as an issue, it's not getting worked on.

+ +

There's not a lot happening in leadership meetings other than those things that aren't ideal for GitHub issues, or we're going through, and we're saying, "Hey, this issue has been sitting around for a while," or "What's the update?" And you'll often see someone comment after the fact about an issue. Now, that being said, I think one of the hardest things about this is that when you expose these big issues, it can be a little discouraging over time to have them be around there to be not closed.

+ +

But the way...I'll bring this back to our product work as well, like, when you identify...at least this is the case for me. A bug could have been there for two years, [chuckles] and I don't know about it, and therefore, it's out of sight, out of mind. I didn't know about it. But the minute I find out about a bug in a product that I'm working on, I can't stop thinking about it, and I want to fix it so badly. It becomes my top priority right away. [laughs]

+ +

And I have to remind myself that just because I know about something now doesn't mean it's actually the highest priority item, or that I can fix it, or that I should take the time to fix it. I know it's my natural tendency to do that. So shedding light on something that's positive in and of itself, and then we can chip away at that over time. And this way of working allows us to tackle big problems. But sometimes it doesn't feel so great because you're identifying sort of defects in the company itself that make everybody uncomfortable. But I would rather light be shed on those so that we have a chance to improve it than to have it go unidentified, just like bugs in our products.

+ +

VICTORIA: And just to illustrate, we have 162 open issues on our handbook. [laughter] But, you know, from my perspective, that makes me really excited, like, people are engaging with it. They're putting in issues and creating it. Because I've converted a company handbook to GitHub before, and no one ever looked at it. [laughs] So it was actually kind of nice that --

+ +

CHAD: [laughs]

+ +

VICTORIA: You said that it took some time to build up that interaction with it and make people feel comfortable. And I wanted to ask about actually your Dungeons & Dragons campaigns that you run with the company. And I'm wondering what skills or practices from that comes over into your leadership style or the culture at thoughtbot.

+ +

CHAD: Ooh, I'm not sure it's as deep as that, Victoria.

+ +

VICTORIA: [laughs]

+ +

CHAD: I just really like [laughter] playing Dungeons & Dragons. But I will say the itch that it scratches for me and the reason why I like Dungeons & Dragons, and the reason why I'm really happy to play it with thoughtbot people...my degree is computer science. But all throughout elementary school, high school, I did improv and theater, and I have a degree in theater as well.

+ +

For a long time, Dungeons & Dragons is essentially doing group improv with other people around a game. And to be able to bring those two things together with a group of people that I like to have fun with it's a really great outlet. And I really enjoy it. But I'm not sure that there's anything deeper than it sort of scratches that performance itch that I have with a group of people that I like to hang out with.

+ +

VICTORIA: That's fair. And then, just to kind of go back to one of our earlier questions we asked —what would you go back in time and advise your younger self —now, what if your younger person could travel to the future and give you some advice, looking at where you are at now?

+ +

CHAD: The only way that I've done this for 20 years is day by day. Like, each day, you get up, and you approach each day. This is the way I do it anyway. It's like I approach each day as a fresh day. And now, over thousands of days, it's been 20 years. And I think that that is part of why at least I've been able to do this so long is I don't do a lot of dwelling on what happened yesterday. I think about today and tomorrow much more than I do about what happened yesterday.

+ +

The upside is I've been able to do this for 20 years. [laughs] The downside to that is you tend to not reflect so much on the good things, just like you don't reflect so much on the bad things. You tend to not celebrate the milestones when they happen or appreciate them as much because you're onto the next thing. You're thinking about tomorrow rather than yesterday. And so I would think that if my younger self came forward and talked to me today, I think the thing that he would say is like, hey, look at where you are, look at what you've done. Take a moment [laughs] to celebrate not only your work but, you know, this is true for the people around me.

+ +

I tend not to celebrate the accomplishments as much and everything because I'm very much someone who sort of lives in maybe not even the moment but the next moment that's about to happen. And so I think the person would say, relax a little bit, have a little bit more fun. Take a moment to celebrate the people around you a little bit more. I think that's what I would say to myself.

+ +

WILL: I love learning things that I didn't know about thoughtbot. So this has been perfect.

+ +

CHAD: Thank you both for the really thoughtful questions. And on the note of what I just [inaudible 44:53], thank you for everything that you both do at thoughtbot. I really appreciate it. We couldn't have accomplished everything that we have without the individuals [inaudible 45:01]. So I'm here sort of representing thoughtbot for our 20th anniversary, but it's not just me who got us to this point. It's been a lot of other people over the many years making it happen. And so I appreciate both of you for helping make it happen.

+ +

VICTORIA: Well, thank you. And again, thank you so much for joining us.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+-0RbrDjQ + + ]]> + + Will Larry + Victoria Guido + Chad Pytel + + + 476: OpenSauced with Brian Douglas + https://podcast.thoughtbot.com/476 + 3e244905-dec5-471e-9733-4e116b531ccf + Thu, 25 May 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Brian Douglas is the CEO of OpenSauced which helps enterprises discover the best engineers in Open Source. + +Victoria and Will talk to Brian about meeting as many developers as possible, setting goals, and keeping himself accountable, and what makes a successful open source project. + 41:23 + no + + + Brian Douglas is the CEO of OpenSauced which helps enterprises discover the best engineers in Open Source. +Victoria and Will talk to Brian about meeting as many developers as possible, setting goals, and keeping himself accountable, and what makes a successful open source project. +OpenSauced (https://opensauced.pizza/) +Follow OpenSauced on Twitter (https://twitter.com/saucedopen), GitHub (https://github.com/open-sauced), Instagram (https://www.instagram.com/opensauced/), YouTube (https://www.youtube.com/opensauced), Discord (https://discord.com/invite/U2peSNf23P), and Dev.to (https://dev.to/opensauced). +Follow Brian Douglas on LinkedIn (https://www.linkedin.com/in/brianldouglas/), Twitter (https://twitter.com/bdougieYO), or visit his website (https://b.dougie.dev/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. +We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. +Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. +JORDYN: Thanks for having us. +DAWN: Yeah, glad to be here. +VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? +JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. +VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. +JORDYN: Wonderful. +VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? +JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. +VICTORIA: What made you decide to start this incubator program this year with thoughtbot? +DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. +And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. +It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. +VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? +DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? +It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. +VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. +JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. +You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. +He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. +You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? +VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? +DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. +So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. +VICTORIA: Wonderful. That's amazing. Thank you both so much. +INTRO MUSIC: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. +WILL: And I'm your host, Will WILL. And with us today is Brian Douglas, CEO of OpenSauced, helping enterprises discover best engineers in open source. Brian, thank you for joining us today. +BRIAN: My pleasure. Thanks for inviting me on the podcast. +VICTORIA: Just tell us a little bit more about OpenSauced. +BRIAN: Yeah, it's opensauced.pizza is the URL. So I always point that out because it's easy to found. +WILL: I love it. +BRIAN: And OpenSauced is a platform for engineers to find their next contributions and enterprises to discover the best engineers doing open-source, so... +VICTORIA: Right. So maybe tell me what led you to start this company? +BRIAN: Yeah, that's a great question. Actually, if you don't mind, I'll start further back. I graduated college in 2008 during the financial crisis with a finance degree. And what I learned pretty quickly is, like, if you don't know anybody in finance, it's a little hard to get a job in a bad market. So I took a sales role instead, mainly because I just wanted to learn. I was very much introverted. I wanted to learn how to talk to people, and have conversation, and communicate. +So I did that four years and then got my MBA. And then started learning how to code while building an app, which is...I mentioned before we hit record I learned about this podcast around that time, which is, like, very serendipitous to be on this podcast years later. But, fast forward, OpenSauced, like, because of the whole networking aspect of how I got my job in sales and how I was able to do sales when I learned how to engineer, I knew the connection to open source, or how I learned how to code was, like, a wealth of information. +So I made it my career goal to meet as many developers as possible. And then, I was working at this company called Netlify. I was employee number three there. And my role was to basically be a front-end engineer, but where I was actually getting more adoption to the product by doing open source. Like, every time I'd do an open-source contribution, I'd add a Netlify deploy preview manually in my PR. And that would give the maintainer enough juice to review the PR sooner. +And I was doing a lot of open-source contribution at the time. So I wanted to build a tool to maintain, like, all the PRs I had opened in-flight that I needed to respond back to or...because back in, like, 2016, notifications on GitHub they weren't the greatest. +WILL: [laughs] +BRIAN: So I built a tool just to keep up to date on what I had opened and how I can communicate back with the maintainer. And saw a need...actually, I didn't see the need. I used this thing myself, and then in 2020, I started live streaming myself, building more features on top of this, like, CRM tool, and had a few people ask, "Hey, can you add a login to this? I'd love to use this, too, with my own database and stuff like that." +So I did that. I added login. And I say database, like, we actually originally started with no database. We used GitHub Issues as a tracking mechanism for tracking repos and conversations. We've since moved away from that because, now, obviously, GitHub's got way more advanced in how notifications work. But the sort of ethos of the project still lives today, and what we have in the open-source platform. So that's, like, the long tale of how we got to where we are today. +And then, I spoke at GitHub Universe on OpenSauced back in 2017. And from that talk, I had GitHub employees reach out to me and ask me to work at GitHub. So I accepted, and I worked at GitHub for almost five years, sort of putting OpenSauced to the side up until last year, decided to go ahead and pursue it again. And at that point, decided to make it a company. +VICTORIA: What a cool story. There are so many things in there that I want to follow up on. I'm sure, Will, you also are like -- [laughs] +WILL: [laughs] Yes. +VICTORIA: I have so many questions. [laughs] +WILL: Wow, that's amazing just hearing the story from you [laughs] got a four-year degree in finance, 2008 happened, no job, very hard to get a job because of who you know. And then you go and changed directions to start learning to code. And I love how it's kind of guided your path to where you are here right now. Like, who knows? But would you have been the CEO of OpenSauced if 2008 would have never happened? So it's amazing to see it. +So, I guess, because I love the idea of OpenSauced...because I am that developer that wants to get into open source, but it is hard. It is hard to find the issues that you can work on. It's hard to get into the community to do that. So, if you can just explain to me a little bit more as from there, and we can do it from the enterprise portion later. But, as far as a user: a developer, what does it look like for me to use OpenSauced as a developer? +BRIAN: Yeah, yeah. And that's a great question, too, as well. It's funny how serendipitous the story is today, but when I was living it, it was like, oh, man, I'm never going to get a job. [laughter] Or I'm never going to learn how to code. And I think anybody listening who might be where I was ten years ago, I just want to preface, like, your story is like a guided path through experiences. And every experience is like an opportunity for that sort of one piece of, like, the sort of stepping stone to move on to, like, CEO of whatever your next startup is or senior engineer, or staff engineer, whatever it is. +But, to answer your question, Will, we built a Discord, and the Discord itself is how we sort of discovered this sort of onboard ramp into open source. So today, if you sign up to OpenSauced, again, opensauced.pizza, you connect to your GitHub account, and you get on-boarded into a flow to ask a couple questions. So, like, what languages are you interested in? And then, what time zone are you in? +And the reason for those two things is, one because we're going to do recommendations for projects pretty soon. Everything is open source, so you can literally see the issues that are open about recommendations; happy to take contributions and feedback on it. And then time zone is because communication is pretty key. So, like, if someone is not awake when I see their PR, I have an expectation of, like, cool, I'll write a response, and I'll wait for them to wake up and respond back to that. +So the goal there is there's a lot of projects on GitHub, like, 372 million repos is the number off the top of my head. They literally announce this stuff, and they share the data. But of those repos, only 225,000 have more than five contributors. Understanding what you're looking to accomplish first out of doing open source to either share knowledge, or gain knowledge, to get exposure, to get a job, or just to enhance your current job by go try something that's not in the roadmap of what you're working on. +Eventually, we'll start asking those questions around, like, what type of contributor that you want to be, so we can start recommending those types of projects. But I mentioned that 225,000 repo number because there are a lot of projects that don't have five contributors that could use their second contributor, or third, fourth. And my recommendation is always find up-and-coming, like, growth-stage projects. +A lot of people want to contribute to React. You had mentioned you did React, Will. That's a really big lift to go contribute upstream to a project maintained and supported by millions of enterprises around the world. But there are tons of projects that go trending every week that have no documentation, that have no README, that have no structure and are just getting off the ground. Like, those are the best projects that we try to showcase. So, like, that's hot.opensauced.pizza is our sort of up-and-coming project list. +And the way that works is like projects that are trending based on our open-source community; we surface those there. There's a lot of work we have to do on that project. That was, like, a Hack Week project we did a couple of years ago as a community. But the basis of that is they're looking to build our recommendation engine off that. +So, step one is find a project that is welcoming, that needs some work done, and then find the path in. So the path usually is going to be your CONTRIBUTING.md, which is like established projects will have this. But if you don't find a CONTRIBUTING.md, but you find a project you want to use, chances are you could build that CONTRIBUTING.md and ask the question, so, like, hey, how would I contribute? Like, how can I be supportive? +Actually, I did this talk a couple of years ago at Juneteenth Conf. It was a remote conference on Juneteenth, which a bunch of Black Engineers we all gave our technical expertise sponsored by Microsoft. And I was talking about the idea of open-source hospitality. The best thing you could do is be that sort of hospitable person, either you're a maintainer or a first-time contributor. Like, be that person to set it up for the next person behind you. +And the idea of hospitality, you go to a hotel. Like, you know where the towels are. Like, you know where the soaps are. Like, you know exactly where everything is all the time. And, in open source, like, if we could set up our projects in a very similar fashion, like, not franchise them in a way like the Hilton or Marriott, but set the expectation that there is a way to source information and to interact and operate, so... +VICTORIA: Yeah, I mean, I love, [laughs] like, hot.opensauced.pizza. That's hilarious. And I love how you have used humor to...even though it's a very serious product, we're making it more friendly and more hospitable like you're saying. And I like how you said, you know, the journey is cool looking back on it, but it was really hard to go through it. And now you're this wonderful speaker and a CEO. +But you said that you weren't actually good at talking to people at first. And you specifically sought to get better at that skill. So I wonder if you would share more about that, how that's impacted your career, and why that's important as a developer to have those communication skills. +BRIAN: Yeah, it's like...I have a twin brother since birth, basically. And my twin brother is very extroverted. Like, he actually used to wait tables in college. It was like he was the person that would make you feel very special as a server. Like, he's the type of person that kind of lights up the room when you walk in. His name is Brock. My entire life growing up, I was always Brock's brother. And it's like, oh, you're Brock's brother. And it's like, yeah, I'm Brock's brother. +And I'm more of a person, like, if you meet me in person, like, I'm very much reserved. I'm sort of reading the room, waiting for my point to jump in. And I made it a point for me to, like, have enough comfort to speak on a podcast or speak at a conference because I knew that skill set would be valuable. Because I definitely had, in my sales career, definitely got overlooked for a lot of opportunity because folks thought, oh, I don't think Brian could do it. +So coming into tech and seeing that when every time I went to a meet up...because meetups also are places where I cut my teeth and got to learn about the industry and the community. They always needed someone to speak. So I was, like, oh, there's an opportunity. I can leverage this opportunity of them always looking for speakers and me always wanting to share knowledge and learn something new to do talks. +So my first-ever conference talk was in San Francisco. And I had learned React Native, but prior to React Native, I had learned Objective-C. And then, in between Objective-C and React Native, I learned Swift because React Native and Swift came out the same year. Well, React Native went public, open source, the same year as Swift. So it was like a really interesting year back in; I think it was 2017 where...actually, it might have been 2016. +But, anyway, everything came out at the same time. And I was learning iOS development. So I made it a point for me to give a talk. But my pet peeve for giving talks is, a lot of times, people just go directly into the code, and there's, like, no connection to a story, or why do I care about this? +So I always bring storytelling into my conversations and talks. So, like, that talk about Swift, and Objective-C, and React Native, I made the comparison of, like...it was the same year that Kanye West took the mic from Taylor Swift at the VMAs or whatever the award show was. And the correlation was React Native took the mic away from Swift because it built similar interactions for JavaScript developers to understand and build iOS applications that was not like Ionic or RubyMine or...I forgot the Ruby one. +But, anyway, what I'm getting at is, I just wanted to bring story to this because usually what happens is like, you see cool things, but you never remember what the name is. You try to find that REPL again, or you try to figure out who that speaker is. And it's usually hard to find it after the fact. So, like, my goal was always to make it memorable, which is why I go by Bdougie because Bdougie is easier to Google than Brian Douglas. Shout out to Brian Douglas, who's based in Ireland who does system engineering, and has a great YouTube channel. Like, I want to be memorable. And I want to make it easy for folks to find me after. +So, while at GitHub, when I was developing all this sort of like Kanye West-type speaking and stuff like that, well, literally, I would use Kanye West years ago as the example to understand storytelling. I no longer use Kanye West. I'm now a Beyoncé advocate. [laughter] So I use Beyoncé instead. +But I guess what I'm getting at is, like, I just had a goal. And I knew if I could teach myself to code...and it was about 17 weeks it took me from zero to ship a Ruby on Rails app. And I felt confident enough to talk about it. I knew basically anything I could just accomplish just by putting some effort and consistency behind it. So that's the...sorry, that was a little more long-winded than expected. But I just keep accountable and set goals for myself and try to achieve enough to feel proud about at the end of the year. +WILL: Yeah. It's so funny because I recently had a similar situation. At thoughtbot, we try to engage with the community, and one of the ways was writing a blog post. I've never been a writer. It just hasn't been my thing. But I was telling my boss, I was like, I'm going to do that to get outside my comfort zone and to really stretch myself. And at the same time, I was like, why a blog post? Like, I don't know, it doesn't really make sense why a blog post. +Well, when I started writing the blog post, I was like, oh, you have to really know, one, what you're talking about in order to write about it. And so I had to really do some research, really had to study it. And I finished it last week. And then, now, looking back over the last couple of months it took me to write that blog post, I'm like, wow, I feel stretched. But I feel really good, and I feel really good about the topic that I did. +So that's interesting that you went through that process to stretch yourself and to grow and even learning to code and get to that point. So talking about...you were at Netlify, and then you worked at GitHub. And then you're at your current one OpenSauced. How have Netlify and GitHub, the work that you did there, how has it prepared you for your position right now? +BRIAN: You know, actually, that's a great question. I don't know how much thought I put into that. Like, Netlify prepared me because it gave me an opportunity. So I was employee number three, but I had a sales background. And so I got to be an engineer, but they kept always trying to ask me like, you know, business questions and strategy. And, like, I pitched them a 30-60-90 in my interview of, like, what's the growth strategy of Netlify, like day zero when I start? +And I go into way more detail in other content. But that prepared me because I got to see how startups work, being so early. I got to see that startup go from seed-funded, just closed their seed round to get their series B is when I left. At GitHub, I got to see what it looked like at a bigger company, which, like, it doesn't matter how big or small you are, like, there's always chaos. +Like, GitHub was, like, so much chaos, and there was a lot of good that was happening but a lot of uncertainty at the time I joined in 2018. And then, nine months later, Microsoft acquired GitHub. So then I got to learn stability and what it looks like to...for personal reasons, I always had a budget but never had extra money, even years into my engineering career. And that taught me what it looks like when success meets career. +With that being said, like, the problem that I'm solving, I got to learn firsthand while being at Netlify and getting adoption and traction through open source. And then going to GitHub and seeing every single other company that looked at GitHub as a solution to their open-source collaborations and interactions. And then also seeing that there was a hole in just understanding, like, how do you survive? How do you sustain yourself as your career but also your open-source project? +Like, a lot of folks want to know, like, what success looks like for open source. Like, how do you get on the trending algorithm? Like, how do you get noticed? It's more than just pushing to GitHub and hoping for the best. There are, like, other things that happen for projects to be successful. And for us to choose the next in the future technologies, it really comes down to community, marketing, and then resources. And those three things end up making projects successful. With OpenSauced, we're working to help inflate some storytelling and add some of those resources to open-source projects. +VICTORIA: Great. So you were able to really get, like, the full vision of what it could be if you had a product that became successful and stable, and you knew you wanted to build it on open source. So I love that you really just...you had this problem, and that's what you built the product around. And that ended up becoming the business. What was surprising for you in those early discovery phases with OpenSauced when you were first thinking of building it? +BRIAN: I guess what's really surprising is we're not, like, crazy traction today. But we've done a pretty good job of getting, like, 2,000 developers to sign up to it since December. And then the conversations with enterprises so far just by the sheer...like, basically, what was surprising is if you use proper sales technique and you're early stage as a startup, so, like, not necessarily hire salespeople, but as a founder or as a stakeholder, just go talk to your future customers and your users. Everyone says it, but that's actually super valuable. +And I think in the same vein of open source, folks they see projects die on the vine, but then you see projects succeed. And I think it also comes down to how often the maintainer of the project is talking to the contributors and the users and also that distinction as well. There are folks who want to contribute code to the codebase, but then there are folks who want to use the codebase. And, like, how do you interact between the two? And how do you cross the chasm for those folks as well? +And, a lot of times, it's just fascinating just, like, just by trying, and just by showing up, that's half. It's all cliché stuff, like, I could say, but it's all true. Like, showing up is, like, it's, like, step one. Just show up, do the thing, do the work. And then talk to people is, like, step two. And it's hard to say, like, okay, yeah, because we are not a multibillion-dollar company, like, we're just getting started. So I can't say, like, yeah, we're super successful. But we've survived the year. +And we've survived the year based on those two steps, the showing up and then talking to people. Because a lot of times, we could get lost in the sauce, per se, of just shipping code and never talking to anybody and never coming up for air. And I think what I learned, going back to what I learned from GitHub and Netlify, is talking to people and getting that feedback loop going is the best thing you could do for any product. Any early project, any feature you're working on, talk to people about it and see if it's actually valuable for somebody that after you ship it, something will happen. +WILL: You're talking about communication is a big thing for a successful project. Have you noticed any other trends that make a successful open-source project? +BRIAN: Yeah, that's...Any other trends? Yeah. I mean, AI, [laughs] just kidding. +WILL: [laughs] +BRIAN: No, I mean, but it also it is true, like, having a trend not sort of following the herd, but catching the herd earlier is extremely valuable. Like, at Netlify, we caught the trend of React. So, basically, Netlify built essentially GitHub Pages but a product and a company. And that was, like, the original project of Netlify. It's expanded so much further from that. But at that time, when I joined, I joined three months before Create React App was developed. So, like, it was a CLI tool to build React apps easy. +And, prior to that, React was, like, super complicated to get up and running. Like, you had to know Webpack. You had to know, Babel. You had to make all that glue happen together. And then there wasn't an easy process to go host it somewhere. So the prevalence of build tools like Grunt, and Gulp, and Browserify, they all made it easier to build a static output from React. And that trend is what took Netlify to where it is today. +It's like, people needed a place to deploy these static applications. GitHub Pages was like the solution for a lot of folks. Because Heroku, like, why pay $7 for something you could host on S3 for free? But the challenge was S3 it requires way more thought in how you host and take it down and deploy, and then it becomes like a Kubernetes nightmare. So the trend there was, like, people just wanted to have a better developer experience. +When it comes to, like, open source, the developer experience in JavaScript has improved so much more. But folks are now looking at the next thing like a Zig, or a Rust, or all these other new languages and server renderings and stuff like that. So I guess when I take a step back, when I look at how I chose things I wanted to work on, and communities I wanted to hang out in...before committing to React...I'm based out here in Oakland, so San Francisco, basically. +By seeing the sheer number of RSVPs to the React meetup, it made me confident that React would be something I should pay attention to. When you look at the RSVPs of now all these AI meetups that are happening in San Francisco, like, every single weekend is a hackathon. Highly confident that if you're engineering today, you probably want to know what embeddings are and know how OpenAI works. Not that you necessarily have to build AI stuff, but it is going to be the thing that people are going to be using. +So just like we had to learn build tools, and servers, and CDNs prior, now it's all trivial stuff that you can sort of use Cloudflare for free. Like, AI is going to be very similar, and it's probably going to happen much quicker. But, in the time being, the trend right now is, like, you should probably understand whatever the players are in that space so that way you're able to talk confidently about it. +WILL: That's really good advice, yep. +VICTORIA: Absolutely. And, you know, in my role as Managing Director of Mission Control, or, like, DevOps, SRE platform, I spend a lot of time looking at trends, more on the engineering side. So I think my question is, [laughs] as someone who hires people to work on open-source projects, and who actively maintains and contributes to open-source projects, what should I be thinking about how to use OpenSauced as in my role? +BRIAN: For hiring and sourcing skilled folks, we're actually working on a tool right now to make it more discoverable. So, today, when you onboard as an individual developer, you can check a box in your settings to say, like, if you want to collaborate with other folks, you have to opt into it. So if you want to be discovered on OpenSauced, it's in the settings. We'll probably expose that and share more about that in the future, like, in the next month or so. +But for, in particular, our user flow today for folks looking to find other people to contribute alongside their project is, you add your project to what we call an Insight Page. You click on the tab on the top and create a page with your project. And then, you can see contributions in your project in the last 30 days. And then you can also add other projects like your project, so you can see who else is contributing. +So, that way, you can start discovering folks who are making contributions consistently and start to get some stories of, like, if they're interested in collaborating, they'll check that box; if they're not, the box won't be checked. But at least you know the sort of scope of the ecosystem. +As an individual developer, we have the onboarding flow, but then we also have highlights. So, eventually, we'll do recommendations to get you to make contributions. But, for now, if you're already making contributions, you can highlight the contributions you've made so that way, you're more discoverable on the platform. And the highlights are very much like a LinkedIn post or a tweet. You just drop in a PR, and then we'll either generate that description for you, or you write a description: I did a thing. This is what it was. This was the experience. +And then, now you're attached to the project through not just a code contribution but also a discovery mechanism, which is a highlight. And then, eventually, we'll start doing blog posts, and guides, and stuff like that, as they're written. Like, if you want to attribute your career, and your journey to your participation to, like, documentation updates and stuff like that, those will also be highlights coming soon. +WILL: I love, love, love that. +MID-ROLL AD: +Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. +Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff +WILL: I hear you saying that you have some things that's coming soon. In a high, high level, what are some of the things that you have coming? And what does success look like, six months, a year? What does that look like? Because it sounds like you have some really good ideas that you're working on. +BRIAN: Yeah, yeah. So, like, six months to the end of the year, what we want to do is actually start getting more deeper insights to what's happening in open source. What we're doing right now is building the individual developer profile and experience so that way, they're able to be discovered, find projects to work on. And then what's next is there are tons of enterprises and companies that are maintaining open-source projects, SDKs. +And what we're seeing right now is we're seeing massive layoffs happening currently in the industry. So like, as of today, I think Facebook laid off 4,000 people, ESPN laid off, like, 7,000 Disney employees as well. And some of those employees are around the Disney+ place. It's a lot of technical engineering stuff. So I guess what I'm getting at is there...we want to be able to see the trends of places that activity is happening and start recommending people to that. +But also, we want to give an opportunity for folks who...companies...sorry, I'm avoiding trying to name specific companies because nothing is in contract yet. But certain companies, like, you, don't think of as an open-source powerhouse. So, like, a company we're now talking to right now is walgreens.com. And Walgreens they have tech. They've got open source that they participated. But they're not thought of as a place like, oh, I want to go work at Walgreens and go work on some cloud infrastructure stuff. +So, how does Walgreens get exposure? And, like, hey, we're involved in the kubectl, and the Kubernetes platform and stuff like that, like, be aware that there's opportunity here. So we're going to start driving that connection to folks. So, as you develop your career doing open source, you can also be noticed, and folks can reach out to you. +And also, I want to stand on the notion of open source is not for everybody. But I also want to point out, like, my entire career in open source has not been nights and weekends. It's always been finding a company that supports my interest to do open-source at work. +Part of my story is, like, I was getting an MBA. My first kid, who's nine years old now he, was born 11 weeks early. And he's the reason why I built an app because I wanted to build an app to solve a pain point that I had, and ended up building that in 17 weeks. And that turned into opportunity. +So I guess what I'm getting at is, like, folks being laid off right now, you might have some extra free time. You might be submitting like 100 applications a day. Consider taking that down to 50 applications a day, and then try to contribute to a couple of open-source projects a month. So that way, there's some more story to be shared as you're in the job market. +VICTORIA: I love that you created that app when you had your son and you had that need. And for developers wanting to get noticed and wanting to get their next leg up or maybe even negotiate for higher salaries, what's the traditional way people do that now to kind of highlight themselves? +BRIAN: The traditional way what people are doing is they're tweeting. They're speaking at conferences. They're sharing their stories. It's like zero to I'm an influencer in the open-source space. There's no real clear guide and steps to get to that point, which is why we have highlights today. Like, we want to make it low effort for folks to write 200 characters about something they contributed to. +We're actually working on something to generate pull request descriptions because I think that's another missed opportunity. Like, when you open a PR in an open-source project, and it says no description added, like, that's a missed opportunity. Like, there's an opportunity for you to share what you've learned, what Stack Overflow questions you looked at, like, how you got to the problem, and why this is the right solution. All should be in the pull request description. +And then that pull request should be in your cover letter for your resume so that people can go back and say, "Oh, wow, you did some real work." I can go see the history of your contributions because perhaps the job you got let go from you only worked in private repos. You couldn't really showcase your skills. That now gives you a competitive edge. +And I guess when I look into this, like, going back to my original onboard ramp into engineering, I graduated with a finance degree with no network. I had one internship at an insurance company, but that wasn't enough. Like, everyone who I interned with, like, the guy who got a job at the internship, like, his dad was a client, was a big client at that firm. And another guy he worked at a golf course, and he'd be the caddy for all these big finance folks where I went to school. +So, once I learned that there's an opportunity to get a job by just knowing people, that changed my entire path. Like, when I got to sales, like, oh, or when I got to engineering, I just knew go and meet people. Go have conversations. Go to meetups. +What I'm trying to do with OpenSauced is make that step closer for folks, so they could look up and be like, you know, I've made all these contributions, or I don't know where to start. Let me just look at people who I know and follow in the industry and see where they're contributing, and make that connection. So, like, we've kind of closed that gap without the need of, again, you don't need 100,000 Twitter followers to get noticed. Just make some contributions or show up and ask questions. And, hopefully, that's the first step to establishing your career. +VICTORIA: Well, that sounds great for both people who are looking to get hired, but also, as someone who hires people, [laughter] I know that there's a lot of amazing developers who are never going to do a conference talk, or they're not going to post on Twitter. So I love that that's available, and that's something you're working on. +BRIAN: Yeah, it's just coming out of my own pain of, like, I was saying, like, looking at the story now, it sounds great. [laughs] But part of that story was like, hey, I was getting severely underpaid as an engineer in San Francisco, living in a one-bedroom apartment with two kids. Like, all that part of the story is like nothing I dwell on. But it's like, all that opportunity and knowledge-sharing that I ended up benefiting from, it's like what I constantly try to give. I pay it forward with folks. +And I'm more than happy to talk with folks on Twitter and in OpenSauced Discord and other places because I think there's a lot of opportunity in open source. And if anybody's willing to listen, I'm willing to show them the path. +WILL: I'm so glad you brought that up because this is one of my favorite questions I ask on the podcast: So, knowing where you're at right now and your story, you've gone the ups, the downs, all of it. If you can go back in time and know what you know now, what advice would you give yourself at the beginning? +BRIAN: Honestly, I would say write it down. Like, one thing that I did is I did a blog post, and that's part of the reason why I was able to find my first job in engineering is I started a blog, which was really for myself to learn what I did yesterday. I tell everyone who I mentor it takes two hours every time you want to sit and learn something new because one hour is to remember what you did yesterday, and then one hour is to do something new. And so, I usually write it down and then make it a blog post just to solve that problem. +I wish I did more with that, like, you know, wrote a book, or created a YouTube channel, or something because all that knowledge and that sort of sharing is actually what got me to level up faster. I was asked by one of my close friends, like, "Hey, how do you do it? How do you accomplish everything you've done in the last, like, 9-10 years?" And I didn't know what the answer was then. But the answer today for my friend, and I'll share this with them, is it's because I wrote it down. +I was able to go back and see what I did. And then, at the end of six months, I was able to go back six months and see what I did. It's like the idea of relativity with, like, Einstein. Relativity is the idea of motion and the perception. Like, if you're in a train, it feels like you're just going slow. But you might be going 100 miles per hour, but you don't feel that. And when you're going on your journey, you could be going 100 miles per hour, but you're thinking, oh, man, I failed yesterday. I could have solved a problem. But yeah, you solved six problems while trying to solve for one. It's that situation. +So advice for myself, in the beginning, write it down and then share it way more than I did when I started. Because a lot of the stuff I'm like, even in this conversation, I'm thinking, oh yeah, this, this, and this. And I never shared that before, and I wish I did. So yeah. +WILL: I love that. Because yeah, I feel like that's development, like, you have some weeks that you're shipping out multiple features. And then other weeks, you're like, I barely got one out, or I barely fixed this one bug that I've been trying to...struggling with the last couple of weeks. So yeah, I like that advice. Write it down. +And remember where you've been, remember. I just love the example you used, too, because it does seem like I haven't made any movement. But when you look back, you're like, no, you actually made a lot of movement. And you were very successful with what you did. So that's great advice. +VICTORIA: I sometimes write things, and then I go back maybe six months later and read them. And I'm like, who wrote this? [laughter] I don't remember learning this stuff. Oh yeah, I guess I did, right, yeah. [laughs] No, that's so cool. What questions do you have for us, Brian? +BRIAN: I'm curious in, like, how do thoughtbot folks stay up to date? Like, what does your involvement in open source look like today? +VICTORIA: Yeah, so we are known for being active maintainers of a lot of very popular Ruby on Rails gems. So we're a consulting agency. So we're able to structure our time with our clients so that we can build in what we call investment days, which is typically Fridays, so that people can contribute to open-source projects. They can write blog posts. They can do trainings. And so that gives us the structure to be able to actually allow our employees to contribute to open source, and it's a huge part of our business as well. +So if you have a Ruby on Rails project, you're probably using one of our gems. [laughs] And so, when there's other crises or other things happening in an organization, and they want to bring in an expert, they know that that's who thoughtbot is. Of course, we've expanded, and we do React, and now we're doing platform engineering. And we have some open-source TerraForm modules that we use to migrate people onto AWS and operate at that enterprise level with a mix of managed products from AWS as well. +And that continues to be, like, how we talk to people [laughs] and get that buzzword out there is, like, okay, there's this cool open-source project. Like, one I'm excited about now is OpenTelemetry. And so we're digging into that and figuring out how we can contribute. And can we make a big impact here? And that just opens the door to conversations in a way that is less salesy, right? [laughs] +And people know us as the contributors and maintainers, and that creates a level of trust that goes a long way. And also, it really speaks to how we operate as a company as well, where the code is open and when we give it back to the customers, it's not. Some organizations will build stuff and then never give it to you. [laughs] +BRIAN: Yeah. So it sounds like folks at thoughtbot could probably benefit from things like OpenSauced for discoverability. And I get a lot of conversation around in OpenSauced as like, how do I get connected to maintainer of X or maintainer of Y? And the first step is like, how do I even know who the maintainer is? Because when you go to GitHub, you could sort this by last commit date, which not a lot of people know. You can sort the contributors by most frequently and stuff like that. +But it's challenging to find out who to reach out to when it comes to packages, especially when people move on. Like, someone created a thing. They have tons of commits. And then they look like they're the number one committer for the past ten years, but they left five years ago. Those are things that we're trying to make more discoverable to solve that problem. +But then, going into that thoughtbot thing, is like being able to reach out to thoughtbot and be like, oh, who can I reach out to about this gem? And, say, I have an idea, or we have an issue; how can we get unblocked because we're using this in our product? And I imagine with consulting, there's an opportunity to say, hey thoughtbot...which, honestly, at Netlify, we used thoughtbot to solve some harder problems for us. We were just like, yeah, we don't have the bandwidth to go down this path. Let's go to consulting to unblock us in this arena. +VICTORIA: Right. And that was really important to me in making the decision to join thoughtbot last year is that it was built around open source. And that ethos really spoke to me as, like, this is a place where I want to work. [laughs] And you can think of, like, if you're looking for vendors, like, oh, I want to work with people who have that same ethos. So yeah, OpenSauced seems like a really cool product. I'd be curious about how we can leverage it more at thoughtbot. +BRIAN: We just shipped a feature called Teams, which it's self-explanatory. But, basically, when you build an insight page, you're able to build a team to help the discover process of what's happening in contributions. You get details and reporting on OpenSauced. The goal is basically to unblock teams who are involved in open source together and make it more discoverable for folks who want to find maintainers and collaborate with them. +VICTORIA: Will, I know we're running close on time. But I had one more question about what you said around making open source more hospitable. And, you know, you mentioned going to Juneteenth Conf. And I'm curious if you have a perspective on if open source is equitably accessible to everyone or if there are things we can be doing as a community to be more inclusive. +BRIAN: Yeah, it's a great question. So the first answer is quick, it's no. The reason why it's no is because we have to admit [laughs] where there are inequitable situations. And as much as we want to set this up of, like, I want to say that there's opportunity for everyone to contribute based on no matter where their background, but just by your time zone, makes it inequitable of, like, whether you can contribute to open source. Because if you look at the data and zoom out, most open source happens in the West Coast U.S., so from San Francisco to Seattle. Like, majority of contributions are there. There are reasons for that. +Like, California has a very, very expressive clause of like where you can contribute. And, technically, your employer can block you on doing open-source contributions. Unless you sign...like, at Apple, you sign away your rights to be able to do that in your employee offer letter. Sorry, [laughs] not to be a dig against Apple. Apple buy lots of open source. But what I'm getting at is that the opportunity is there, but it's the awareness thing. +I'm part of an organization called DevColor. It's an organization of Black engineers in tech. We have squads and monthly meetings where we just talk about our career, and growth, and stuff like that. And I attribute a lot of that interactions to my success is, like, talking to other folks who are years ahead of me and have a lot more experience. +But I say this because the majority of the folks that I interact with at DevColor they don't do open source because they all...to be a Black engineer at a level of like senior engineer at Netlify, or a staff engineer, or a manager...sorry, I meant, like, Netflix but Netlify too. You basically had a career path of, like, you probably went to school at a decent engineering school, or you figured out how to get a job at Facebook or Google. And, like, that's pretty much it. +And, like, this is a blanket statement. I totally understand there are outliers. But the majority of the folks I interact with at DevColor they have a job. They have a great job. And they're doing the thing, and they're being very successful. But there's less community interaction. And that's what DevColor exists for is to encourage that community interaction and participation. +So, at the end of the day, like, there's opportunity to make it more equitable. So things like, every time there's a release cut for a major open-source project, why not go to Black Girls CODE and have them build something with it? +And, again, very specific, like, React 19 that's currently being tested, why not go to all these other underrepresented organizations and partner with them to show them how to use this project? Because the assumption is everyone in open source, you got to be senior enough to participate, or if it's too hot, get out of the kitchen. But if we set up a place for people to interact and level up, in three or four years from now, you'll see the open-source ecosystem of that project be completely different as far as diversity. +But it takes that investment to have that onboard ramp to even have that connection or conversation about testing early releases with underrepresented groups in engineering. That's where we have to start, and that's what we're trying to do at OpenSauced. We want to make that connection. I have a whole plan for it. I'll share in a blog post. I also mentioned that a lot of these thoughts are on our blog as well. I've been writing blog posts around these conversations. So opensauced.pizza/blog if you're interested. +VICTORIA: Very cool. Thank you for that. +WILL: I'm just processing on the whole conversation. It has just been great. +VICTORIA: Yes. Thank you so much for sharing with us. And I wonder, do you have any final takeaways for our listeners today, Brian? +BRIAN: Yeah, final takeaways. Like, if anything at all resonated in this conversation, please reach out, bdougie on GitHub. I'm pretty active with my notifications. So if you @ mention me in a random project, I'll probably jump back in and respond to you. But also Twitter @bdougieYO. And then, I mentioned our blog. We also have a newsletter. So, if you're interested in any of this OpenSauced journey, please join us there, and keep in touch. +VICTORIA: Wonderful. Thank you so much for joining us today and sharing your story. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +WILL: And you could find me @will23larry +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Brian Douglas. + + + Brian Douglas is the CEO of OpenSauced which helps enterprises discover the best engineers in Open Source.

+ +

Victoria and Will talk to Brian about meeting as many developers as possible, setting goals, and keeping himself accountable, and what makes a successful open source project.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your host, Will WILL. And with us today is Brian Douglas, CEO of OpenSauced, helping enterprises discover best engineers in open source. Brian, thank you for joining us today.

+ +

BRIAN: My pleasure. Thanks for inviting me on the podcast.

+ +

VICTORIA: Just tell us a little bit more about OpenSauced.

+ +

BRIAN: Yeah, it's opensauced.pizza is the URL. So I always point that out because it's easy to found.

+ +

WILL: I love it.

+ +

BRIAN: And OpenSauced is a platform for engineers to find their next contributions and enterprises to discover the best engineers doing open-source, so...

+ +

VICTORIA: Right. So maybe tell me what led you to start this company?

+ +

BRIAN: Yeah, that's a great question. Actually, if you don't mind, I'll start further back. I graduated college in 2008 during the financial crisis with a finance degree. And what I learned pretty quickly is, like, if you don't know anybody in finance, it's a little hard to get a job in a bad market. So I took a sales role instead, mainly because I just wanted to learn. I was very much introverted. I wanted to learn how to talk to people, and have conversation, and communicate.

+ +

So I did that four years and then got my MBA. And then started learning how to code while building an app, which is...I mentioned before we hit record I learned about this podcast around that time, which is, like, very serendipitous to be on this podcast years later. But, fast forward, OpenSauced, like, because of the whole networking aspect of how I got my job in sales and how I was able to do sales when I learned how to engineer, I knew the connection to open source, or how I learned how to code was, like, a wealth of information.

+ +

So I made it my career goal to meet as many developers as possible. And then, I was working at this company called Netlify. I was employee number three there. And my role was to basically be a front-end engineer, but where I was actually getting more adoption to the product by doing open source. Like, every time I'd do an open-source contribution, I'd add a Netlify deploy preview manually in my PR. And that would give the maintainer enough juice to review the PR sooner.

+ +

And I was doing a lot of open-source contribution at the time. So I wanted to build a tool to maintain, like, all the PRs I had opened in-flight that I needed to respond back to or...because back in, like, 2016, notifications on GitHub they weren't the greatest.

+ +

WILL: [laughs]

+ +

BRIAN: So I built a tool just to keep up to date on what I had opened and how I can communicate back with the maintainer. And saw a need...actually, I didn't see the need. I used this thing myself, and then in 2020, I started live streaming myself, building more features on top of this, like, CRM tool, and had a few people ask, "Hey, can you add a login to this? I'd love to use this, too, with my own database and stuff like that."

+ +

So I did that. I added login. And I say database, like, we actually originally started with no database. We used GitHub Issues as a tracking mechanism for tracking repos and conversations. We've since moved away from that because, now, obviously, GitHub's got way more advanced in how notifications work. But the sort of ethos of the project still lives today, and what we have in the open-source platform. So that's, like, the long tale of how we got to where we are today.

+ +

And then, I spoke at GitHub Universe on OpenSauced back in 2017. And from that talk, I had GitHub employees reach out to me and ask me to work at GitHub. So I accepted, and I worked at GitHub for almost five years, sort of putting OpenSauced to the side up until last year, decided to go ahead and pursue it again. And at that point, decided to make it a company.

+ +

VICTORIA: What a cool story. There are so many things in there that I want to follow up on. I'm sure, Will, you also are like -- [laughs]

+ +

WILL: [laughs] Yes.

+ +

VICTORIA: I have so many questions. [laughs]

+ +

WILL: Wow, that's amazing just hearing the story from you [laughs] got a four-year degree in finance, 2008 happened, no job, very hard to get a job because of who you know. And then you go and changed directions to start learning to code. And I love how it's kind of guided your path to where you are here right now. Like, who knows? But would you have been the CEO of OpenSauced if 2008 would have never happened? So it's amazing to see it.

+ +

So, I guess, because I love the idea of OpenSauced...because I am that developer that wants to get into open source, but it is hard. It is hard to find the issues that you can work on. It's hard to get into the community to do that. So, if you can just explain to me a little bit more as from there, and we can do it from the enterprise portion later. But, as far as a user: a developer, what does it look like for me to use OpenSauced as a developer?

+ +

BRIAN: Yeah, yeah. And that's a great question, too, as well. It's funny how serendipitous the story is today, but when I was living it, it was like, oh, man, I'm never going to get a job. [laughter] Or I'm never going to learn how to code. And I think anybody listening who might be where I was ten years ago, I just want to preface, like, your story is like a guided path through experiences. And every experience is like an opportunity for that sort of one piece of, like, the sort of stepping stone to move on to, like, CEO of whatever your next startup is or senior engineer, or staff engineer, whatever it is.

+ +

But, to answer your question, Will, we built a Discord, and the Discord itself is how we sort of discovered this sort of onboard ramp into open source. So today, if you sign up to OpenSauced, again, opensauced.pizza, you connect to your GitHub account, and you get on-boarded into a flow to ask a couple questions. So, like, what languages are you interested in? And then, what time zone are you in?

+ +

And the reason for those two things is, one because we're going to do recommendations for projects pretty soon. Everything is open source, so you can literally see the issues that are open about recommendations; happy to take contributions and feedback on it. And then time zone is because communication is pretty key. So, like, if someone is not awake when I see their PR, I have an expectation of, like, cool, I'll write a response, and I'll wait for them to wake up and respond back to that.

+ +

So the goal there is there's a lot of projects on GitHub, like, 372 million repos is the number off the top of my head. They literally announce this stuff, and they share the data. But of those repos, only 225,000 have more than five contributors. Understanding what you're looking to accomplish first out of doing open source to either share knowledge, or gain knowledge, to get exposure, to get a job, or just to enhance your current job by go try something that's not in the roadmap of what you're working on.

+ +

Eventually, we'll start asking those questions around, like, what type of contributor that you want to be, so we can start recommending those types of projects. But I mentioned that 225,000 repo number because there are a lot of projects that don't have five contributors that could use their second contributor, or third, fourth. And my recommendation is always find up-and-coming, like, growth-stage projects.

+ +

A lot of people want to contribute to React. You had mentioned you did React, Will. That's a really big lift to go contribute upstream to a project maintained and supported by millions of enterprises around the world. But there are tons of projects that go trending every week that have no documentation, that have no README, that have no structure and are just getting off the ground. Like, those are the best projects that we try to showcase. So, like, that's hot.opensauced.pizza is our sort of up-and-coming project list.

+ +

And the way that works is like projects that are trending based on our open-source community; we surface those there. There's a lot of work we have to do on that project. That was, like, a Hack Week project we did a couple of years ago as a community. But the basis of that is they're looking to build our recommendation engine off that.

+ +

So, step one is find a project that is welcoming, that needs some work done, and then find the path in. So the path usually is going to be your CONTRIBUTING.md, which is like established projects will have this. But if you don't find a CONTRIBUTING.md, but you find a project you want to use, chances are you could build that CONTRIBUTING.md and ask the question, so, like, hey, how would I contribute? Like, how can I be supportive?

+ +

Actually, I did this talk a couple of years ago at Juneteenth Conf. It was a remote conference on Juneteenth, which a bunch of Black Engineers we all gave our technical expertise sponsored by Microsoft. And I was talking about the idea of open-source hospitality. The best thing you could do is be that sort of hospitable person, either you're a maintainer or a first-time contributor. Like, be that person to set it up for the next person behind you.

+ +

And the idea of hospitality, you go to a hotel. Like, you know where the towels are. Like, you know where the soaps are. Like, you know exactly where everything is all the time. And, in open source, like, if we could set up our projects in a very similar fashion, like, not franchise them in a way like the Hilton or Marriott, but set the expectation that there is a way to source information and to interact and operate, so...

+ +

VICTORIA: Yeah, I mean, I love, [laughs] like, hot.opensauced.pizza. That's hilarious. And I love how you have used humor to...even though it's a very serious product, we're making it more friendly and more hospitable like you're saying. And I like how you said, you know, the journey is cool looking back on it, but it was really hard to go through it. And now you're this wonderful speaker and a CEO.

+ +

But you said that you weren't actually good at talking to people at first. And you specifically sought to get better at that skill. So I wonder if you would share more about that, how that's impacted your career, and why that's important as a developer to have those communication skills.

+ +

BRIAN: Yeah, it's like...I have a twin brother since birth, basically. And my twin brother is very extroverted. Like, he actually used to wait tables in college. It was like he was the person that would make you feel very special as a server. Like, he's the type of person that kind of lights up the room when you walk in. His name is Brock. My entire life growing up, I was always Brock's brother. And it's like, oh, you're Brock's brother. And it's like, yeah, I'm Brock's brother.

+ +

And I'm more of a person, like, if you meet me in person, like, I'm very much reserved. I'm sort of reading the room, waiting for my point to jump in. And I made it a point for me to, like, have enough comfort to speak on a podcast or speak at a conference because I knew that skill set would be valuable. Because I definitely had, in my sales career, definitely got overlooked for a lot of opportunity because folks thought, oh, I don't think Brian could do it.

+ +

So coming into tech and seeing that when every time I went to a meet up...because meetups also are places where I cut my teeth and got to learn about the industry and the community. They always needed someone to speak. So I was, like, oh, there's an opportunity. I can leverage this opportunity of them always looking for speakers and me always wanting to share knowledge and learn something new to do talks.

+ +

So my first-ever conference talk was in San Francisco. And I had learned React Native, but prior to React Native, I had learned Objective-C. And then, in between Objective-C and React Native, I learned Swift because React Native and Swift came out the same year. Well, React Native went public, open source, the same year as Swift. So it was like a really interesting year back in; I think it was 2017 where...actually, it might have been 2016.

+ +

But, anyway, everything came out at the same time. And I was learning iOS development. So I made it a point for me to give a talk. But my pet peeve for giving talks is, a lot of times, people just go directly into the code, and there's, like, no connection to a story, or why do I care about this?

+ +

So I always bring storytelling into my conversations and talks. So, like, that talk about Swift, and Objective-C, and React Native, I made the comparison of, like...it was the same year that Kanye West took the mic from Taylor Swift at the VMAs or whatever the award show was. And the correlation was React Native took the mic away from Swift because it built similar interactions for JavaScript developers to understand and build iOS applications that was not like Ionic or RubyMine or...I forgot the Ruby one.

+But, anyway, what I'm getting at is, I just wanted to bring story to this because usually what happens is like, you see cool things, but you never remember what the name is. You try to find that REPL again, or you try to figure out who that speaker is. And it's usually hard to find it after the fact. So, like, my goal was always to make it memorable, which is why I go by Bdougie because Bdougie is easier to Google than Brian Douglas. Shout out to Brian Douglas, who's based in Ireland who does system engineering, and has a great YouTube channel. Like, I want to be memorable. And I want to make it easy for folks to find me after.

+ +

So, while at GitHub, when I was developing all this sort of like Kanye West-type speaking and stuff like that, well, literally, I would use Kanye West years ago as the example to understand storytelling. I no longer use Kanye West. I'm now a Beyoncé advocate. [laughter] So I use Beyoncé instead.

+ +

But I guess what I'm getting at is, like, I just had a goal. And I knew if I could teach myself to code...and it was about 17 weeks it took me from zero to ship a Ruby on Rails app. And I felt confident enough to talk about it. I knew basically anything I could just accomplish just by putting some effort and consistency behind it. So that's the...sorry, that was a little more long-winded than expected. But I just keep accountable and set goals for myself and try to achieve enough to feel proud about at the end of the year.

+ +

WILL: Yeah. It's so funny because I recently had a similar situation. At thoughtbot, we try to engage with the community, and one of the ways was writing a blog post. I've never been a writer. It just hasn't been my thing. But I was telling my boss, I was like, I'm going to do that to get outside my comfort zone and to really stretch myself. And at the same time, I was like, why a blog post? Like, I don't know, it doesn't really make sense why a blog post.

+ +

Well, when I started writing the blog post, I was like, oh, you have to really know, one, what you're talking about in order to write about it. And so I had to really do some research, really had to study it. And I finished it last week. And then, now, looking back over the last couple of months it took me to write that blog post, I'm like, wow, I feel stretched. But I feel really good, and I feel really good about the topic that I did.

+ +

So that's interesting that you went through that process to stretch yourself and to grow and even learning to code and get to that point. So talking about...you were at Netlify, and then you worked at GitHub. And then you're at your current one OpenSauced. How have Netlify and GitHub, the work that you did there, how has it prepared you for your position right now?

+ +

BRIAN: You know, actually, that's a great question. I don't know how much thought I put into that. Like, Netlify prepared me because it gave me an opportunity. So I was employee number three, but I had a sales background. And so I got to be an engineer, but they kept always trying to ask me like, you know, business questions and strategy. And, like, I pitched them a 30-60-90 in my interview of, like, what's the growth strategy of Netlify, like day zero when I start?

+ +

And I go into way more detail in other content. But that prepared me because I got to see how startups work, being so early. I got to see that startup go from seed-funded, just closed their seed round to get their series B is when I left. At GitHub, I got to see what it looked like at a bigger company, which, like, it doesn't matter how big or small you are, like, there's always chaos.

+ +

Like, GitHub was, like, so much chaos, and there was a lot of good that was happening but a lot of uncertainty at the time I joined in 2018. And then, nine months later, Microsoft acquired GitHub. So then I got to learn stability and what it looks like to...for personal reasons, I always had a budget but never had extra money, even years into my engineering career. And that taught me what it looks like when success meets career.

+ +

With that being said, like, the problem that I'm solving, I got to learn firsthand while being at Netlify and getting adoption and traction through open source. And then going to GitHub and seeing every single other company that looked at GitHub as a solution to their open-source collaborations and interactions. And then also seeing that there was a hole in just understanding, like, how do you survive? How do you sustain yourself as your career but also your open-source project?

+ +

Like, a lot of folks want to know, like, what success looks like for open source. Like, how do you get on the trending algorithm? Like, how do you get noticed? It's more than just pushing to GitHub and hoping for the best. There are, like, other things that happen for projects to be successful. And for us to choose the next in the future technologies, it really comes down to community, marketing, and then resources. And those three things end up making projects successful. With OpenSauced, we're working to help inflate some storytelling and add some of those resources to open-source projects.

+ +

VICTORIA: Great. So you were able to really get, like, the full vision of what it could be if you had a product that became successful and stable, and you knew you wanted to build it on open source. So I love that you really just...you had this problem, and that's what you built the product around. And that ended up becoming the business. What was surprising for you in those early discovery phases with OpenSauced when you were first thinking of building it?

+ +

BRIAN: I guess what's really surprising is we're not, like, crazy traction today. But we've done a pretty good job of getting, like, 2,000 developers to sign up to it since December. And then the conversations with enterprises so far just by the sheer...like, basically, what was surprising is if you use proper sales technique and you're early stage as a startup, so, like, not necessarily hire salespeople, but as a founder or as a stakeholder, just go talk to your future customers and your users. Everyone says it, but that's actually super valuable.

+ +

And I think in the same vein of open source, folks they see projects die on the vine, but then you see projects succeed. And I think it also comes down to how often the maintainer of the project is talking to the contributors and the users and also that distinction as well. There are folks who want to contribute code to the codebase, but then there are folks who want to use the codebase. And, like, how do you interact between the two? And how do you cross the chasm for those folks as well?

+ +

And, a lot of times, it's just fascinating just, like, just by trying, and just by showing up, that's half. It's all cliché stuff, like, I could say, but it's all true. Like, showing up is, like, it's, like, step one. Just show up, do the thing, do the work. And then talk to people is, like, step two. And it's hard to say, like, okay, yeah, because we are not a multibillion-dollar company, like, we're just getting started. So I can't say, like, yeah, we're super successful. But we've survived the year.

+ +

And we've survived the year based on those two steps, the showing up and then talking to people. Because a lot of times, we could get lost in the sauce, per se, of just shipping code and never talking to anybody and never coming up for air. And I think what I learned, going back to what I learned from GitHub and Netlify, is talking to people and getting that feedback loop going is the best thing you could do for any product. Any early project, any feature you're working on, talk to people about it and see if it's actually valuable for somebody that after you ship it, something will happen.

+ +

WILL: You're talking about communication is a big thing for a successful project. Have you noticed any other trends that make a successful open-source project?

+ +

BRIAN: Yeah, that's...Any other trends? Yeah. I mean, AI, [laughs] just kidding.

+ +

WILL: [laughs]

+ +

BRIAN: No, I mean, but it also it is true, like, having a trend not sort of following the herd, but catching the herd earlier is extremely valuable. Like, at Netlify, we caught the trend of React. So, basically, Netlify built essentially GitHub Pages but a product and a company. And that was, like, the original project of Netlify. It's expanded so much further from that. But at that time, when I joined, I joined three months before Create React App was developed. So, like, it was a CLI tool to build React apps easy.

+ +

And, prior to that, React was, like, super complicated to get up and running. Like, you had to know Webpack. You had to know, Babel. You had to make all that glue happen together. And then there wasn't an easy process to go host it somewhere. So the prevalence of build tools like Grunt, and Gulp, and Browserify, they all made it easier to build a static output from React. And that trend is what took Netlify to where it is today.

+ +

It's like, people needed a place to deploy these static applications. GitHub Pages was like the solution for a lot of folks. Because Heroku, like, why pay $7 for something you could host on S3 for free? But the challenge was S3 it requires way more thought in how you host and take it down and deploy, and then it becomes like a Kubernetes nightmare. So the trend there was, like, people just wanted to have a better developer experience.

+ +

When it comes to, like, open source, the developer experience in JavaScript has improved so much more. But folks are now looking at the next thing like a Zig, or a Rust, or all these other new languages and server renderings and stuff like that. So I guess when I take a step back, when I look at how I chose things I wanted to work on, and communities I wanted to hang out in...before committing to React...I'm based out here in Oakland, so San Francisco, basically.

+ +

By seeing the sheer number of RSVPs to the React meetup, it made me confident that React would be something I should pay attention to. When you look at the RSVPs of now all these AI meetups that are happening in San Francisco, like, every single weekend is a hackathon. Highly confident that if you're engineering today, you probably want to know what embeddings are and know how OpenAI works. Not that you necessarily have to build AI stuff, but it is going to be the thing that people are going to be using.

+ +

So just like we had to learn build tools, and servers, and CDNs prior, now it's all trivial stuff that you can sort of use Cloudflare for free. Like, AI is going to be very similar, and it's probably going to happen much quicker. But, in the time being, the trend right now is, like, you should probably understand whatever the players are in that space so that way you're able to talk confidently about it.

+ +

WILL: That's really good advice, yep.

+ +

VICTORIA: Absolutely. And, you know, in my role as Managing Director of Mission Control, or, like, DevOps, SRE platform, I spend a lot of time looking at trends, more on the engineering side. So I think my question is, [laughs] as someone who hires people to work on open-source projects, and who actively maintains and contributes to open-source projects, what should I be thinking about how to use OpenSauced as in my role?

+ +

BRIAN: For hiring and sourcing skilled folks, we're actually working on a tool right now to make it more discoverable. So, today, when you onboard as an individual developer, you can check a box in your settings to say, like, if you want to collaborate with other folks, you have to opt into it. So if you want to be discovered on OpenSauced, it's in the settings. We'll probably expose that and share more about that in the future, like, in the next month or so.

+ +

But for, in particular, our user flow today for folks looking to find other people to contribute alongside their project is, you add your project to what we call an Insight Page. You click on the tab on the top and create a page with your project. And then, you can see contributions in your project in the last 30 days. And then you can also add other projects like your project, so you can see who else is contributing.

+ +

So, that way, you can start discovering folks who are making contributions consistently and start to get some stories of, like, if they're interested in collaborating, they'll check that box; if they're not, the box won't be checked. But at least you know the sort of scope of the ecosystem.

+ +

As an individual developer, we have the onboarding flow, but then we also have highlights. So, eventually, we'll do recommendations to get you to make contributions. But, for now, if you're already making contributions, you can highlight the contributions you've made so that way, you're more discoverable on the platform. And the highlights are very much like a LinkedIn post or a tweet. You just drop in a PR, and then we'll either generate that description for you, or you write a description: I did a thing. This is what it was. This was the experience.

+ +

And then, now you're attached to the project through not just a code contribution but also a discovery mechanism, which is a highlight. And then, eventually, we'll start doing blog posts, and guides, and stuff like that, as they're written. Like, if you want to attribute your career, and your journey to your participation to, like, documentation updates and stuff like that, those will also be highlights coming soon.

+ +

WILL: I love, love, love that.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff

+ +

WILL: I hear you saying that you have some things that's coming soon. In a high, high level, what are some of the things that you have coming? And what does success look like, six months, a year? What does that look like? Because it sounds like you have some really good ideas that you're working on.

+ +

BRIAN: Yeah, yeah. So, like, six months to the end of the year, what we want to do is actually start getting more deeper insights to what's happening in open source. What we're doing right now is building the individual developer profile and experience so that way, they're able to be discovered, find projects to work on. And then what's next is there are tons of enterprises and companies that are maintaining open-source projects, SDKs.

+ +

And what we're seeing right now is we're seeing massive layoffs happening currently in the industry. So like, as of today, I think Facebook laid off 4,000 people, ESPN laid off, like, 7,000 Disney employees as well. And some of those employees are around the Disney+ place. It's a lot of technical engineering stuff. So I guess what I'm getting at is there...we want to be able to see the trends of places that activity is happening and start recommending people to that.

+ +

But also, we want to give an opportunity for folks who...companies...sorry, I'm avoiding trying to name specific companies because nothing is in contract yet. But certain companies, like, you, don't think of as an open-source powerhouse. So, like, a company we're now talking to right now is walgreens.com. And Walgreens they have tech. They've got open source that they participated. But they're not thought of as a place like, oh, I want to go work at Walgreens and go work on some cloud infrastructure stuff.

+ +

So, how does Walgreens get exposure? And, like, hey, we're involved in the kubectl, and the Kubernetes platform and stuff like that, like, be aware that there's opportunity here. So we're going to start driving that connection to folks. So, as you develop your career doing open source, you can also be noticed, and folks can reach out to you.

+ +

And also, I want to stand on the notion of open source is not for everybody. But I also want to point out, like, my entire career in open source has not been nights and weekends. It's always been finding a company that supports my interest to do open-source at work.

+ +

Part of my story is, like, I was getting an MBA. My first kid, who's nine years old now he, was born 11 weeks early. And he's the reason why I built an app because I wanted to build an app to solve a pain point that I had, and ended up building that in 17 weeks. And that turned into opportunity.

+ +

So I guess what I'm getting at is, like, folks being laid off right now, you might have some extra free time. You might be submitting like 100 applications a day. Consider taking that down to 50 applications a day, and then try to contribute to a couple of open-source projects a month. So that way, there's some more story to be shared as you're in the job market.

+ +

VICTORIA: I love that you created that app when you had your son and you had that need. And for developers wanting to get noticed and wanting to get their next leg up or maybe even negotiate for higher salaries, what's the traditional way people do that now to kind of highlight themselves?

+ +

BRIAN: The traditional way what people are doing is they're tweeting. They're speaking at conferences. They're sharing their stories. It's like zero to I'm an influencer in the open-source space. There's no real clear guide and steps to get to that point, which is why we have highlights today. Like, we want to make it low effort for folks to write 200 characters about something they contributed to.

+ +

We're actually working on something to generate pull request descriptions because I think that's another missed opportunity. Like, when you open a PR in an open-source project, and it says no description added, like, that's a missed opportunity. Like, there's an opportunity for you to share what you've learned, what Stack Overflow questions you looked at, like, how you got to the problem, and why this is the right solution. All should be in the pull request description.

+ +

And then that pull request should be in your cover letter for your resume so that people can go back and say, "Oh, wow, you did some real work." I can go see the history of your contributions because perhaps the job you got let go from you only worked in private repos. You couldn't really showcase your skills. That now gives you a competitive edge.

+ +

And I guess when I look into this, like, going back to my original onboard ramp into engineering, I graduated with a finance degree with no network. I had one internship at an insurance company, but that wasn't enough. Like, everyone who I interned with, like, the guy who got a job at the internship, like, his dad was a client, was a big client at that firm. And another guy he worked at a golf course, and he'd be the caddy for all these big finance folks where I went to school.

+ +

So, once I learned that there's an opportunity to get a job by just knowing people, that changed my entire path. Like, when I got to sales, like, oh, or when I got to engineering, I just knew go and meet people. Go have conversations. Go to meetups.

+ +

What I'm trying to do with OpenSauced is make that step closer for folks, so they could look up and be like, you know, I've made all these contributions, or I don't know where to start. Let me just look at people who I know and follow in the industry and see where they're contributing, and make that connection. So, like, we've kind of closed that gap without the need of, again, you don't need 100,000 Twitter followers to get noticed. Just make some contributions or show up and ask questions. And, hopefully, that's the first step to establishing your career.

+ +

VICTORIA: Well, that sounds great for both people who are looking to get hired, but also, as someone who hires people, [laughter] I know that there's a lot of amazing developers who are never going to do a conference talk, or they're not going to post on Twitter. So I love that that's available, and that's something you're working on.

+ +

BRIAN: Yeah, it's just coming out of my own pain of, like, I was saying, like, looking at the story now, it sounds great. [laughs] But part of that story was like, hey, I was getting severely underpaid as an engineer in San Francisco, living in a one-bedroom apartment with two kids. Like, all that part of the story is like nothing I dwell on. But it's like, all that opportunity and knowledge-sharing that I ended up benefiting from, it's like what I constantly try to give. I pay it forward with folks.

+ +

And I'm more than happy to talk with folks on Twitter and in OpenSauced Discord and other places because I think there's a lot of opportunity in open source. And if anybody's willing to listen, I'm willing to show them the path.

+ +

WILL: I'm so glad you brought that up because this is one of my favorite questions I ask on the podcast: So, knowing where you're at right now and your story, you've gone the ups, the downs, all of it. If you can go back in time and know what you know now, what advice would you give yourself at the beginning?

+ +

BRIAN: Honestly, I would say write it down. Like, one thing that I did is I did a blog post, and that's part of the reason why I was able to find my first job in engineering is I started a blog, which was really for myself to learn what I did yesterday. I tell everyone who I mentor it takes two hours every time you want to sit and learn something new because one hour is to remember what you did yesterday, and then one hour is to do something new. And so, I usually write it down and then make it a blog post just to solve that problem.

+ +

I wish I did more with that, like, you know, wrote a book, or created a YouTube channel, or something because all that knowledge and that sort of sharing is actually what got me to level up faster. I was asked by one of my close friends, like, "Hey, how do you do it? How do you accomplish everything you've done in the last, like, 9-10 years?" And I didn't know what the answer was then. But the answer today for my friend, and I'll share this with them, is it's because I wrote it down.

+ +

I was able to go back and see what I did. And then, at the end of six months, I was able to go back six months and see what I did. It's like the idea of relativity with, like, Einstein. Relativity is the idea of motion and the perception. Like, if you're in a train, it feels like you're just going slow. But you might be going 100 miles per hour, but you don't feel that. And when you're going on your journey, you could be going 100 miles per hour, but you're thinking, oh, man, I failed yesterday. I could have solved a problem. But yeah, you solved six problems while trying to solve for one. It's that situation.

+ +

So advice for myself, in the beginning, write it down and then share it way more than I did when I started. Because a lot of the stuff I'm like, even in this conversation, I'm thinking, oh yeah, this, this, and this. And I never shared that before, and I wish I did. So yeah.

+ +

WILL: I love that. Because yeah, I feel like that's development, like, you have some weeks that you're shipping out multiple features. And then other weeks, you're like, I barely got one out, or I barely fixed this one bug that I've been trying to...struggling with the last couple of weeks. So yeah, I like that advice. Write it down.

+ +

And remember where you've been, remember. I just love the example you used, too, because it does seem like I haven't made any movement. But when you look back, you're like, no, you actually made a lot of movement. And you were very successful with what you did. So that's great advice.

+ +

VICTORIA: I sometimes write things, and then I go back maybe six months later and read them. And I'm like, who wrote this? [laughter] I don't remember learning this stuff. Oh yeah, I guess I did, right, yeah. [laughs] No, that's so cool. What questions do you have for us, Brian?

+ +

BRIAN: I'm curious in, like, how do thoughtbot folks stay up to date? Like, what does your involvement in open source look like today?

+ +

VICTORIA: Yeah, so we are known for being active maintainers of a lot of very popular Ruby on Rails gems. So we're a consulting agency. So we're able to structure our time with our clients so that we can build in what we call investment days, which is typically Fridays, so that people can contribute to open-source projects. They can write blog posts. They can do trainings. And so that gives us the structure to be able to actually allow our employees to contribute to open source, and it's a huge part of our business as well.

+ +

So if you have a Ruby on Rails project, you're probably using one of our gems. [laughs] And so, when there's other crises or other things happening in an organization, and they want to bring in an expert, they know that that's who thoughtbot is. Of course, we've expanded, and we do React, and now we're doing platform engineering. And we have some open-source TerraForm modules that we use to migrate people onto AWS and operate at that enterprise level with a mix of managed products from AWS as well.

+ +

And that continues to be, like, how we talk to people [laughs] and get that buzzword out there is, like, okay, there's this cool open-source project. Like, one I'm excited about now is OpenTelemetry. And so we're digging into that and figuring out how we can contribute. And can we make a big impact here? And that just opens the door to conversations in a way that is less salesy, right? [laughs]

+ +

And people know us as the contributors and maintainers, and that creates a level of trust that goes a long way. And also, it really speaks to how we operate as a company as well, where the code is open and when we give it back to the customers, it's not. Some organizations will build stuff and then never give it to you. [laughs]

+ +

BRIAN: Yeah. So it sounds like folks at thoughtbot could probably benefit from things like OpenSauced for discoverability. And I get a lot of conversation around in OpenSauced as like, how do I get connected to maintainer of X or maintainer of Y? And the first step is like, how do I even know who the maintainer is? Because when you go to GitHub, you could sort this by last commit date, which not a lot of people know. You can sort the contributors by most frequently and stuff like that.

+ +

But it's challenging to find out who to reach out to when it comes to packages, especially when people move on. Like, someone created a thing. They have tons of commits. And then they look like they're the number one committer for the past ten years, but they left five years ago. Those are things that we're trying to make more discoverable to solve that problem.

+ +

But then, going into that thoughtbot thing, is like being able to reach out to thoughtbot and be like, oh, who can I reach out to about this gem? And, say, I have an idea, or we have an issue; how can we get unblocked because we're using this in our product? And I imagine with consulting, there's an opportunity to say, hey thoughtbot...which, honestly, at Netlify, we used thoughtbot to solve some harder problems for us. We were just like, yeah, we don't have the bandwidth to go down this path. Let's go to consulting to unblock us in this arena.

+ +

VICTORIA: Right. And that was really important to me in making the decision to join thoughtbot last year is that it was built around open source. And that ethos really spoke to me as, like, this is a place where I want to work. [laughs] And you can think of, like, if you're looking for vendors, like, oh, I want to work with people who have that same ethos. So yeah, OpenSauced seems like a really cool product. I'd be curious about how we can leverage it more at thoughtbot.

+ +

BRIAN: We just shipped a feature called Teams, which it's self-explanatory. But, basically, when you build an insight page, you're able to build a team to help the discover process of what's happening in contributions. You get details and reporting on OpenSauced. The goal is basically to unblock teams who are involved in open source together and make it more discoverable for folks who want to find maintainers and collaborate with them.

+ +

VICTORIA: Will, I know we're running close on time. But I had one more question about what you said around making open source more hospitable. And, you know, you mentioned going to Juneteenth Conf. And I'm curious if you have a perspective on if open source is equitably accessible to everyone or if there are things we can be doing as a community to be more inclusive.

+ +

BRIAN: Yeah, it's a great question. So the first answer is quick, it's no. The reason why it's no is because we have to admit [laughs] where there are inequitable situations. And as much as we want to set this up of, like, I want to say that there's opportunity for everyone to contribute based on no matter where their background, but just by your time zone, makes it inequitable of, like, whether you can contribute to open source. Because if you look at the data and zoom out, most open source happens in the West Coast U.S., so from San Francisco to Seattle. Like, majority of contributions are there. There are reasons for that.

+ +

Like, California has a very, very expressive clause of like where you can contribute. And, technically, your employer can block you on doing open-source contributions. Unless you sign...like, at Apple, you sign away your rights to be able to do that in your employee offer letter. Sorry, [laughs] not to be a dig against Apple. Apple buy lots of open source. But what I'm getting at is that the opportunity is there, but it's the awareness thing.

+ +

I'm part of an organization called DevColor. It's an organization of Black engineers in tech. We have squads and monthly meetings where we just talk about our career, and growth, and stuff like that. And I attribute a lot of that interactions to my success is, like, talking to other folks who are years ahead of me and have a lot more experience.

+ +

But I say this because the majority of the folks that I interact with at DevColor they don't do open source because they all...to be a Black engineer at a level of like senior engineer at Netlify, or a staff engineer, or a manager...sorry, I meant, like, Netflix but Netlify too. You basically had a career path of, like, you probably went to school at a decent engineering school, or you figured out how to get a job at Facebook or Google. And, like, that's pretty much it.

+ +

And, like, this is a blanket statement. I totally understand there are outliers. But the majority of the folks I interact with at DevColor they have a job. They have a great job. And they're doing the thing, and they're being very successful. But there's less community interaction. And that's what DevColor exists for is to encourage that community interaction and participation.

+ +

So, at the end of the day, like, there's opportunity to make it more equitable. So things like, every time there's a release cut for a major open-source project, why not go to Black Girls CODE and have them build something with it?

+ +

And, again, very specific, like, React 19 that's currently being tested, why not go to all these other underrepresented organizations and partner with them to show them how to use this project? Because the assumption is everyone in open source, you got to be senior enough to participate, or if it's too hot, get out of the kitchen. But if we set up a place for people to interact and level up, in three or four years from now, you'll see the open-source ecosystem of that project be completely different as far as diversity.

+ +

But it takes that investment to have that onboard ramp to even have that connection or conversation about testing early releases with underrepresented groups in engineering. That's where we have to start, and that's what we're trying to do at OpenSauced. We want to make that connection. I have a whole plan for it. I'll share in a blog post. I also mentioned that a lot of these thoughts are on our blog as well. I've been writing blog posts around these conversations. So opensauced.pizza/blog if you're interested.

+ +

VICTORIA: Very cool. Thank you for that.

+ +

WILL: I'm just processing on the whole conversation. It has just been great.

+ +

VICTORIA: Yes. Thank you so much for sharing with us. And I wonder, do you have any final takeaways for our listeners today, Brian?

+ +

BRIAN: Yeah, final takeaways. Like, if anything at all resonated in this conversation, please reach out, bdougie on GitHub. I'm pretty active with my notifications. So if you @ mention me in a random project, I'll probably jump back in and respond to you. But also Twitter @bdougieYO. And then, I mentioned our blog. We also have a newsletter. So, if you're interested in any of this OpenSauced journey, please join us there, and keep in touch.

+ +

VICTORIA: Wonderful. Thank you so much for joining us today and sharing your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me @will23larry

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brian Douglas.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Brian Douglas is the CEO of OpenSauced which helps enterprises discover the best engineers in Open Source.

+ +

Victoria and Will talk to Brian about meeting as many developers as possible, setting goals, and keeping himself accountable, and what makes a successful open source project.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

+ +

WILL: And I'm your host, Will WILL. And with us today is Brian Douglas, CEO of OpenSauced, helping enterprises discover best engineers in open source. Brian, thank you for joining us today.

+ +

BRIAN: My pleasure. Thanks for inviting me on the podcast.

+ +

VICTORIA: Just tell us a little bit more about OpenSauced.

+ +

BRIAN: Yeah, it's opensauced.pizza is the URL. So I always point that out because it's easy to found.

+ +

WILL: I love it.

+ +

BRIAN: And OpenSauced is a platform for engineers to find their next contributions and enterprises to discover the best engineers doing open-source, so...

+ +

VICTORIA: Right. So maybe tell me what led you to start this company?

+ +

BRIAN: Yeah, that's a great question. Actually, if you don't mind, I'll start further back. I graduated college in 2008 during the financial crisis with a finance degree. And what I learned pretty quickly is, like, if you don't know anybody in finance, it's a little hard to get a job in a bad market. So I took a sales role instead, mainly because I just wanted to learn. I was very much introverted. I wanted to learn how to talk to people, and have conversation, and communicate.

+ +

So I did that four years and then got my MBA. And then started learning how to code while building an app, which is...I mentioned before we hit record I learned about this podcast around that time, which is, like, very serendipitous to be on this podcast years later. But, fast forward, OpenSauced, like, because of the whole networking aspect of how I got my job in sales and how I was able to do sales when I learned how to engineer, I knew the connection to open source, or how I learned how to code was, like, a wealth of information.

+ +

So I made it my career goal to meet as many developers as possible. And then, I was working at this company called Netlify. I was employee number three there. And my role was to basically be a front-end engineer, but where I was actually getting more adoption to the product by doing open source. Like, every time I'd do an open-source contribution, I'd add a Netlify deploy preview manually in my PR. And that would give the maintainer enough juice to review the PR sooner.

+ +

And I was doing a lot of open-source contribution at the time. So I wanted to build a tool to maintain, like, all the PRs I had opened in-flight that I needed to respond back to or...because back in, like, 2016, notifications on GitHub they weren't the greatest.

+ +

WILL: [laughs]

+ +

BRIAN: So I built a tool just to keep up to date on what I had opened and how I can communicate back with the maintainer. And saw a need...actually, I didn't see the need. I used this thing myself, and then in 2020, I started live streaming myself, building more features on top of this, like, CRM tool, and had a few people ask, "Hey, can you add a login to this? I'd love to use this, too, with my own database and stuff like that."

+ +

So I did that. I added login. And I say database, like, we actually originally started with no database. We used GitHub Issues as a tracking mechanism for tracking repos and conversations. We've since moved away from that because, now, obviously, GitHub's got way more advanced in how notifications work. But the sort of ethos of the project still lives today, and what we have in the open-source platform. So that's, like, the long tale of how we got to where we are today.

+ +

And then, I spoke at GitHub Universe on OpenSauced back in 2017. And from that talk, I had GitHub employees reach out to me and ask me to work at GitHub. So I accepted, and I worked at GitHub for almost five years, sort of putting OpenSauced to the side up until last year, decided to go ahead and pursue it again. And at that point, decided to make it a company.

+ +

VICTORIA: What a cool story. There are so many things in there that I want to follow up on. I'm sure, Will, you also are like -- [laughs]

+ +

WILL: [laughs] Yes.

+ +

VICTORIA: I have so many questions. [laughs]

+ +

WILL: Wow, that's amazing just hearing the story from you [laughs] got a four-year degree in finance, 2008 happened, no job, very hard to get a job because of who you know. And then you go and changed directions to start learning to code. And I love how it's kind of guided your path to where you are here right now. Like, who knows? But would you have been the CEO of OpenSauced if 2008 would have never happened? So it's amazing to see it.

+ +

So, I guess, because I love the idea of OpenSauced...because I am that developer that wants to get into open source, but it is hard. It is hard to find the issues that you can work on. It's hard to get into the community to do that. So, if you can just explain to me a little bit more as from there, and we can do it from the enterprise portion later. But, as far as a user: a developer, what does it look like for me to use OpenSauced as a developer?

+ +

BRIAN: Yeah, yeah. And that's a great question, too, as well. It's funny how serendipitous the story is today, but when I was living it, it was like, oh, man, I'm never going to get a job. [laughter] Or I'm never going to learn how to code. And I think anybody listening who might be where I was ten years ago, I just want to preface, like, your story is like a guided path through experiences. And every experience is like an opportunity for that sort of one piece of, like, the sort of stepping stone to move on to, like, CEO of whatever your next startup is or senior engineer, or staff engineer, whatever it is.

+ +

But, to answer your question, Will, we built a Discord, and the Discord itself is how we sort of discovered this sort of onboard ramp into open source. So today, if you sign up to OpenSauced, again, opensauced.pizza, you connect to your GitHub account, and you get on-boarded into a flow to ask a couple questions. So, like, what languages are you interested in? And then, what time zone are you in?

+ +

And the reason for those two things is, one because we're going to do recommendations for projects pretty soon. Everything is open source, so you can literally see the issues that are open about recommendations; happy to take contributions and feedback on it. And then time zone is because communication is pretty key. So, like, if someone is not awake when I see their PR, I have an expectation of, like, cool, I'll write a response, and I'll wait for them to wake up and respond back to that.

+ +

So the goal there is there's a lot of projects on GitHub, like, 372 million repos is the number off the top of my head. They literally announce this stuff, and they share the data. But of those repos, only 225,000 have more than five contributors. Understanding what you're looking to accomplish first out of doing open source to either share knowledge, or gain knowledge, to get exposure, to get a job, or just to enhance your current job by go try something that's not in the roadmap of what you're working on.

+ +

Eventually, we'll start asking those questions around, like, what type of contributor that you want to be, so we can start recommending those types of projects. But I mentioned that 225,000 repo number because there are a lot of projects that don't have five contributors that could use their second contributor, or third, fourth. And my recommendation is always find up-and-coming, like, growth-stage projects.

+ +

A lot of people want to contribute to React. You had mentioned you did React, Will. That's a really big lift to go contribute upstream to a project maintained and supported by millions of enterprises around the world. But there are tons of projects that go trending every week that have no documentation, that have no README, that have no structure and are just getting off the ground. Like, those are the best projects that we try to showcase. So, like, that's hot.opensauced.pizza is our sort of up-and-coming project list.

+ +

And the way that works is like projects that are trending based on our open-source community; we surface those there. There's a lot of work we have to do on that project. That was, like, a Hack Week project we did a couple of years ago as a community. But the basis of that is they're looking to build our recommendation engine off that.

+ +

So, step one is find a project that is welcoming, that needs some work done, and then find the path in. So the path usually is going to be your CONTRIBUTING.md, which is like established projects will have this. But if you don't find a CONTRIBUTING.md, but you find a project you want to use, chances are you could build that CONTRIBUTING.md and ask the question, so, like, hey, how would I contribute? Like, how can I be supportive?

+ +

Actually, I did this talk a couple of years ago at Juneteenth Conf. It was a remote conference on Juneteenth, which a bunch of Black Engineers we all gave our technical expertise sponsored by Microsoft. And I was talking about the idea of open-source hospitality. The best thing you could do is be that sort of hospitable person, either you're a maintainer or a first-time contributor. Like, be that person to set it up for the next person behind you.

+ +

And the idea of hospitality, you go to a hotel. Like, you know where the towels are. Like, you know where the soaps are. Like, you know exactly where everything is all the time. And, in open source, like, if we could set up our projects in a very similar fashion, like, not franchise them in a way like the Hilton or Marriott, but set the expectation that there is a way to source information and to interact and operate, so...

+ +

VICTORIA: Yeah, I mean, I love, [laughs] like, hot.opensauced.pizza. That's hilarious. And I love how you have used humor to...even though it's a very serious product, we're making it more friendly and more hospitable like you're saying. And I like how you said, you know, the journey is cool looking back on it, but it was really hard to go through it. And now you're this wonderful speaker and a CEO.

+ +

But you said that you weren't actually good at talking to people at first. And you specifically sought to get better at that skill. So I wonder if you would share more about that, how that's impacted your career, and why that's important as a developer to have those communication skills.

+ +

BRIAN: Yeah, it's like...I have a twin brother since birth, basically. And my twin brother is very extroverted. Like, he actually used to wait tables in college. It was like he was the person that would make you feel very special as a server. Like, he's the type of person that kind of lights up the room when you walk in. His name is Brock. My entire life growing up, I was always Brock's brother. And it's like, oh, you're Brock's brother. And it's like, yeah, I'm Brock's brother.

+ +

And I'm more of a person, like, if you meet me in person, like, I'm very much reserved. I'm sort of reading the room, waiting for my point to jump in. And I made it a point for me to, like, have enough comfort to speak on a podcast or speak at a conference because I knew that skill set would be valuable. Because I definitely had, in my sales career, definitely got overlooked for a lot of opportunity because folks thought, oh, I don't think Brian could do it.

+ +

So coming into tech and seeing that when every time I went to a meet up...because meetups also are places where I cut my teeth and got to learn about the industry and the community. They always needed someone to speak. So I was, like, oh, there's an opportunity. I can leverage this opportunity of them always looking for speakers and me always wanting to share knowledge and learn something new to do talks.

+ +

So my first-ever conference talk was in San Francisco. And I had learned React Native, but prior to React Native, I had learned Objective-C. And then, in between Objective-C and React Native, I learned Swift because React Native and Swift came out the same year. Well, React Native went public, open source, the same year as Swift. So it was like a really interesting year back in; I think it was 2017 where...actually, it might have been 2016.

+ +

But, anyway, everything came out at the same time. And I was learning iOS development. So I made it a point for me to give a talk. But my pet peeve for giving talks is, a lot of times, people just go directly into the code, and there's, like, no connection to a story, or why do I care about this?

+ +

So I always bring storytelling into my conversations and talks. So, like, that talk about Swift, and Objective-C, and React Native, I made the comparison of, like...it was the same year that Kanye West took the mic from Taylor Swift at the VMAs or whatever the award show was. And the correlation was React Native took the mic away from Swift because it built similar interactions for JavaScript developers to understand and build iOS applications that was not like Ionic or RubyMine or...I forgot the Ruby one.

+But, anyway, what I'm getting at is, I just wanted to bring story to this because usually what happens is like, you see cool things, but you never remember what the name is. You try to find that REPL again, or you try to figure out who that speaker is. And it's usually hard to find it after the fact. So, like, my goal was always to make it memorable, which is why I go by Bdougie because Bdougie is easier to Google than Brian Douglas. Shout out to Brian Douglas, who's based in Ireland who does system engineering, and has a great YouTube channel. Like, I want to be memorable. And I want to make it easy for folks to find me after.

+ +

So, while at GitHub, when I was developing all this sort of like Kanye West-type speaking and stuff like that, well, literally, I would use Kanye West years ago as the example to understand storytelling. I no longer use Kanye West. I'm now a Beyoncé advocate. [laughter] So I use Beyoncé instead.

+ +

But I guess what I'm getting at is, like, I just had a goal. And I knew if I could teach myself to code...and it was about 17 weeks it took me from zero to ship a Ruby on Rails app. And I felt confident enough to talk about it. I knew basically anything I could just accomplish just by putting some effort and consistency behind it. So that's the...sorry, that was a little more long-winded than expected. But I just keep accountable and set goals for myself and try to achieve enough to feel proud about at the end of the year.

+ +

WILL: Yeah. It's so funny because I recently had a similar situation. At thoughtbot, we try to engage with the community, and one of the ways was writing a blog post. I've never been a writer. It just hasn't been my thing. But I was telling my boss, I was like, I'm going to do that to get outside my comfort zone and to really stretch myself. And at the same time, I was like, why a blog post? Like, I don't know, it doesn't really make sense why a blog post.

+ +

Well, when I started writing the blog post, I was like, oh, you have to really know, one, what you're talking about in order to write about it. And so I had to really do some research, really had to study it. And I finished it last week. And then, now, looking back over the last couple of months it took me to write that blog post, I'm like, wow, I feel stretched. But I feel really good, and I feel really good about the topic that I did.

+ +

So that's interesting that you went through that process to stretch yourself and to grow and even learning to code and get to that point. So talking about...you were at Netlify, and then you worked at GitHub. And then you're at your current one OpenSauced. How have Netlify and GitHub, the work that you did there, how has it prepared you for your position right now?

+ +

BRIAN: You know, actually, that's a great question. I don't know how much thought I put into that. Like, Netlify prepared me because it gave me an opportunity. So I was employee number three, but I had a sales background. And so I got to be an engineer, but they kept always trying to ask me like, you know, business questions and strategy. And, like, I pitched them a 30-60-90 in my interview of, like, what's the growth strategy of Netlify, like day zero when I start?

+ +

And I go into way more detail in other content. But that prepared me because I got to see how startups work, being so early. I got to see that startup go from seed-funded, just closed their seed round to get their series B is when I left. At GitHub, I got to see what it looked like at a bigger company, which, like, it doesn't matter how big or small you are, like, there's always chaos.

+ +

Like, GitHub was, like, so much chaos, and there was a lot of good that was happening but a lot of uncertainty at the time I joined in 2018. And then, nine months later, Microsoft acquired GitHub. So then I got to learn stability and what it looks like to...for personal reasons, I always had a budget but never had extra money, even years into my engineering career. And that taught me what it looks like when success meets career.

+ +

With that being said, like, the problem that I'm solving, I got to learn firsthand while being at Netlify and getting adoption and traction through open source. And then going to GitHub and seeing every single other company that looked at GitHub as a solution to their open-source collaborations and interactions. And then also seeing that there was a hole in just understanding, like, how do you survive? How do you sustain yourself as your career but also your open-source project?

+ +

Like, a lot of folks want to know, like, what success looks like for open source. Like, how do you get on the trending algorithm? Like, how do you get noticed? It's more than just pushing to GitHub and hoping for the best. There are, like, other things that happen for projects to be successful. And for us to choose the next in the future technologies, it really comes down to community, marketing, and then resources. And those three things end up making projects successful. With OpenSauced, we're working to help inflate some storytelling and add some of those resources to open-source projects.

+ +

VICTORIA: Great. So you were able to really get, like, the full vision of what it could be if you had a product that became successful and stable, and you knew you wanted to build it on open source. So I love that you really just...you had this problem, and that's what you built the product around. And that ended up becoming the business. What was surprising for you in those early discovery phases with OpenSauced when you were first thinking of building it?

+ +

BRIAN: I guess what's really surprising is we're not, like, crazy traction today. But we've done a pretty good job of getting, like, 2,000 developers to sign up to it since December. And then the conversations with enterprises so far just by the sheer...like, basically, what was surprising is if you use proper sales technique and you're early stage as a startup, so, like, not necessarily hire salespeople, but as a founder or as a stakeholder, just go talk to your future customers and your users. Everyone says it, but that's actually super valuable.

+ +

And I think in the same vein of open source, folks they see projects die on the vine, but then you see projects succeed. And I think it also comes down to how often the maintainer of the project is talking to the contributors and the users and also that distinction as well. There are folks who want to contribute code to the codebase, but then there are folks who want to use the codebase. And, like, how do you interact between the two? And how do you cross the chasm for those folks as well?

+ +

And, a lot of times, it's just fascinating just, like, just by trying, and just by showing up, that's half. It's all cliché stuff, like, I could say, but it's all true. Like, showing up is, like, it's, like, step one. Just show up, do the thing, do the work. And then talk to people is, like, step two. And it's hard to say, like, okay, yeah, because we are not a multibillion-dollar company, like, we're just getting started. So I can't say, like, yeah, we're super successful. But we've survived the year.

+ +

And we've survived the year based on those two steps, the showing up and then talking to people. Because a lot of times, we could get lost in the sauce, per se, of just shipping code and never talking to anybody and never coming up for air. And I think what I learned, going back to what I learned from GitHub and Netlify, is talking to people and getting that feedback loop going is the best thing you could do for any product. Any early project, any feature you're working on, talk to people about it and see if it's actually valuable for somebody that after you ship it, something will happen.

+ +

WILL: You're talking about communication is a big thing for a successful project. Have you noticed any other trends that make a successful open-source project?

+ +

BRIAN: Yeah, that's...Any other trends? Yeah. I mean, AI, [laughs] just kidding.

+ +

WILL: [laughs]

+ +

BRIAN: No, I mean, but it also it is true, like, having a trend not sort of following the herd, but catching the herd earlier is extremely valuable. Like, at Netlify, we caught the trend of React. So, basically, Netlify built essentially GitHub Pages but a product and a company. And that was, like, the original project of Netlify. It's expanded so much further from that. But at that time, when I joined, I joined three months before Create React App was developed. So, like, it was a CLI tool to build React apps easy.

+ +

And, prior to that, React was, like, super complicated to get up and running. Like, you had to know Webpack. You had to know, Babel. You had to make all that glue happen together. And then there wasn't an easy process to go host it somewhere. So the prevalence of build tools like Grunt, and Gulp, and Browserify, they all made it easier to build a static output from React. And that trend is what took Netlify to where it is today.

+ +

It's like, people needed a place to deploy these static applications. GitHub Pages was like the solution for a lot of folks. Because Heroku, like, why pay $7 for something you could host on S3 for free? But the challenge was S3 it requires way more thought in how you host and take it down and deploy, and then it becomes like a Kubernetes nightmare. So the trend there was, like, people just wanted to have a better developer experience.

+ +

When it comes to, like, open source, the developer experience in JavaScript has improved so much more. But folks are now looking at the next thing like a Zig, or a Rust, or all these other new languages and server renderings and stuff like that. So I guess when I take a step back, when I look at how I chose things I wanted to work on, and communities I wanted to hang out in...before committing to React...I'm based out here in Oakland, so San Francisco, basically.

+ +

By seeing the sheer number of RSVPs to the React meetup, it made me confident that React would be something I should pay attention to. When you look at the RSVPs of now all these AI meetups that are happening in San Francisco, like, every single weekend is a hackathon. Highly confident that if you're engineering today, you probably want to know what embeddings are and know how OpenAI works. Not that you necessarily have to build AI stuff, but it is going to be the thing that people are going to be using.

+ +

So just like we had to learn build tools, and servers, and CDNs prior, now it's all trivial stuff that you can sort of use Cloudflare for free. Like, AI is going to be very similar, and it's probably going to happen much quicker. But, in the time being, the trend right now is, like, you should probably understand whatever the players are in that space so that way you're able to talk confidently about it.

+ +

WILL: That's really good advice, yep.

+ +

VICTORIA: Absolutely. And, you know, in my role as Managing Director of Mission Control, or, like, DevOps, SRE platform, I spend a lot of time looking at trends, more on the engineering side. So I think my question is, [laughs] as someone who hires people to work on open-source projects, and who actively maintains and contributes to open-source projects, what should I be thinking about how to use OpenSauced as in my role?

+ +

BRIAN: For hiring and sourcing skilled folks, we're actually working on a tool right now to make it more discoverable. So, today, when you onboard as an individual developer, you can check a box in your settings to say, like, if you want to collaborate with other folks, you have to opt into it. So if you want to be discovered on OpenSauced, it's in the settings. We'll probably expose that and share more about that in the future, like, in the next month or so.

+ +

But for, in particular, our user flow today for folks looking to find other people to contribute alongside their project is, you add your project to what we call an Insight Page. You click on the tab on the top and create a page with your project. And then, you can see contributions in your project in the last 30 days. And then you can also add other projects like your project, so you can see who else is contributing.

+ +

So, that way, you can start discovering folks who are making contributions consistently and start to get some stories of, like, if they're interested in collaborating, they'll check that box; if they're not, the box won't be checked. But at least you know the sort of scope of the ecosystem.

+ +

As an individual developer, we have the onboarding flow, but then we also have highlights. So, eventually, we'll do recommendations to get you to make contributions. But, for now, if you're already making contributions, you can highlight the contributions you've made so that way, you're more discoverable on the platform. And the highlights are very much like a LinkedIn post or a tweet. You just drop in a PR, and then we'll either generate that description for you, or you write a description: I did a thing. This is what it was. This was the experience.

+ +

And then, now you're attached to the project through not just a code contribution but also a discovery mechanism, which is a highlight. And then, eventually, we'll start doing blog posts, and guides, and stuff like that, as they're written. Like, if you want to attribute your career, and your journey to your participation to, like, documentation updates and stuff like that, those will also be highlights coming soon.

+ +

WILL: I love, love, love that.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff

+ +

WILL: I hear you saying that you have some things that's coming soon. In a high, high level, what are some of the things that you have coming? And what does success look like, six months, a year? What does that look like? Because it sounds like you have some really good ideas that you're working on.

+ +

BRIAN: Yeah, yeah. So, like, six months to the end of the year, what we want to do is actually start getting more deeper insights to what's happening in open source. What we're doing right now is building the individual developer profile and experience so that way, they're able to be discovered, find projects to work on. And then what's next is there are tons of enterprises and companies that are maintaining open-source projects, SDKs.

+ +

And what we're seeing right now is we're seeing massive layoffs happening currently in the industry. So like, as of today, I think Facebook laid off 4,000 people, ESPN laid off, like, 7,000 Disney employees as well. And some of those employees are around the Disney+ place. It's a lot of technical engineering stuff. So I guess what I'm getting at is there...we want to be able to see the trends of places that activity is happening and start recommending people to that.

+ +

But also, we want to give an opportunity for folks who...companies...sorry, I'm avoiding trying to name specific companies because nothing is in contract yet. But certain companies, like, you, don't think of as an open-source powerhouse. So, like, a company we're now talking to right now is walgreens.com. And Walgreens they have tech. They've got open source that they participated. But they're not thought of as a place like, oh, I want to go work at Walgreens and go work on some cloud infrastructure stuff.

+ +

So, how does Walgreens get exposure? And, like, hey, we're involved in the kubectl, and the Kubernetes platform and stuff like that, like, be aware that there's opportunity here. So we're going to start driving that connection to folks. So, as you develop your career doing open source, you can also be noticed, and folks can reach out to you.

+ +

And also, I want to stand on the notion of open source is not for everybody. But I also want to point out, like, my entire career in open source has not been nights and weekends. It's always been finding a company that supports my interest to do open-source at work.

+ +

Part of my story is, like, I was getting an MBA. My first kid, who's nine years old now he, was born 11 weeks early. And he's the reason why I built an app because I wanted to build an app to solve a pain point that I had, and ended up building that in 17 weeks. And that turned into opportunity.

+ +

So I guess what I'm getting at is, like, folks being laid off right now, you might have some extra free time. You might be submitting like 100 applications a day. Consider taking that down to 50 applications a day, and then try to contribute to a couple of open-source projects a month. So that way, there's some more story to be shared as you're in the job market.

+ +

VICTORIA: I love that you created that app when you had your son and you had that need. And for developers wanting to get noticed and wanting to get their next leg up or maybe even negotiate for higher salaries, what's the traditional way people do that now to kind of highlight themselves?

+ +

BRIAN: The traditional way what people are doing is they're tweeting. They're speaking at conferences. They're sharing their stories. It's like zero to I'm an influencer in the open-source space. There's no real clear guide and steps to get to that point, which is why we have highlights today. Like, we want to make it low effort for folks to write 200 characters about something they contributed to.

+ +

We're actually working on something to generate pull request descriptions because I think that's another missed opportunity. Like, when you open a PR in an open-source project, and it says no description added, like, that's a missed opportunity. Like, there's an opportunity for you to share what you've learned, what Stack Overflow questions you looked at, like, how you got to the problem, and why this is the right solution. All should be in the pull request description.

+ +

And then that pull request should be in your cover letter for your resume so that people can go back and say, "Oh, wow, you did some real work." I can go see the history of your contributions because perhaps the job you got let go from you only worked in private repos. You couldn't really showcase your skills. That now gives you a competitive edge.

+ +

And I guess when I look into this, like, going back to my original onboard ramp into engineering, I graduated with a finance degree with no network. I had one internship at an insurance company, but that wasn't enough. Like, everyone who I interned with, like, the guy who got a job at the internship, like, his dad was a client, was a big client at that firm. And another guy he worked at a golf course, and he'd be the caddy for all these big finance folks where I went to school.

+ +

So, once I learned that there's an opportunity to get a job by just knowing people, that changed my entire path. Like, when I got to sales, like, oh, or when I got to engineering, I just knew go and meet people. Go have conversations. Go to meetups.

+ +

What I'm trying to do with OpenSauced is make that step closer for folks, so they could look up and be like, you know, I've made all these contributions, or I don't know where to start. Let me just look at people who I know and follow in the industry and see where they're contributing, and make that connection. So, like, we've kind of closed that gap without the need of, again, you don't need 100,000 Twitter followers to get noticed. Just make some contributions or show up and ask questions. And, hopefully, that's the first step to establishing your career.

+ +

VICTORIA: Well, that sounds great for both people who are looking to get hired, but also, as someone who hires people, [laughter] I know that there's a lot of amazing developers who are never going to do a conference talk, or they're not going to post on Twitter. So I love that that's available, and that's something you're working on.

+ +

BRIAN: Yeah, it's just coming out of my own pain of, like, I was saying, like, looking at the story now, it sounds great. [laughs] But part of that story was like, hey, I was getting severely underpaid as an engineer in San Francisco, living in a one-bedroom apartment with two kids. Like, all that part of the story is like nothing I dwell on. But it's like, all that opportunity and knowledge-sharing that I ended up benefiting from, it's like what I constantly try to give. I pay it forward with folks.

+ +

And I'm more than happy to talk with folks on Twitter and in OpenSauced Discord and other places because I think there's a lot of opportunity in open source. And if anybody's willing to listen, I'm willing to show them the path.

+ +

WILL: I'm so glad you brought that up because this is one of my favorite questions I ask on the podcast: So, knowing where you're at right now and your story, you've gone the ups, the downs, all of it. If you can go back in time and know what you know now, what advice would you give yourself at the beginning?

+ +

BRIAN: Honestly, I would say write it down. Like, one thing that I did is I did a blog post, and that's part of the reason why I was able to find my first job in engineering is I started a blog, which was really for myself to learn what I did yesterday. I tell everyone who I mentor it takes two hours every time you want to sit and learn something new because one hour is to remember what you did yesterday, and then one hour is to do something new. And so, I usually write it down and then make it a blog post just to solve that problem.

+ +

I wish I did more with that, like, you know, wrote a book, or created a YouTube channel, or something because all that knowledge and that sort of sharing is actually what got me to level up faster. I was asked by one of my close friends, like, "Hey, how do you do it? How do you accomplish everything you've done in the last, like, 9-10 years?" And I didn't know what the answer was then. But the answer today for my friend, and I'll share this with them, is it's because I wrote it down.

+ +

I was able to go back and see what I did. And then, at the end of six months, I was able to go back six months and see what I did. It's like the idea of relativity with, like, Einstein. Relativity is the idea of motion and the perception. Like, if you're in a train, it feels like you're just going slow. But you might be going 100 miles per hour, but you don't feel that. And when you're going on your journey, you could be going 100 miles per hour, but you're thinking, oh, man, I failed yesterday. I could have solved a problem. But yeah, you solved six problems while trying to solve for one. It's that situation.

+ +

So advice for myself, in the beginning, write it down and then share it way more than I did when I started. Because a lot of the stuff I'm like, even in this conversation, I'm thinking, oh yeah, this, this, and this. And I never shared that before, and I wish I did. So yeah.

+ +

WILL: I love that. Because yeah, I feel like that's development, like, you have some weeks that you're shipping out multiple features. And then other weeks, you're like, I barely got one out, or I barely fixed this one bug that I've been trying to...struggling with the last couple of weeks. So yeah, I like that advice. Write it down.

+ +

And remember where you've been, remember. I just love the example you used, too, because it does seem like I haven't made any movement. But when you look back, you're like, no, you actually made a lot of movement. And you were very successful with what you did. So that's great advice.

+ +

VICTORIA: I sometimes write things, and then I go back maybe six months later and read them. And I'm like, who wrote this? [laughter] I don't remember learning this stuff. Oh yeah, I guess I did, right, yeah. [laughs] No, that's so cool. What questions do you have for us, Brian?

+ +

BRIAN: I'm curious in, like, how do thoughtbot folks stay up to date? Like, what does your involvement in open source look like today?

+ +

VICTORIA: Yeah, so we are known for being active maintainers of a lot of very popular Ruby on Rails gems. So we're a consulting agency. So we're able to structure our time with our clients so that we can build in what we call investment days, which is typically Fridays, so that people can contribute to open-source projects. They can write blog posts. They can do trainings. And so that gives us the structure to be able to actually allow our employees to contribute to open source, and it's a huge part of our business as well.

+ +

So if you have a Ruby on Rails project, you're probably using one of our gems. [laughs] And so, when there's other crises or other things happening in an organization, and they want to bring in an expert, they know that that's who thoughtbot is. Of course, we've expanded, and we do React, and now we're doing platform engineering. And we have some open-source TerraForm modules that we use to migrate people onto AWS and operate at that enterprise level with a mix of managed products from AWS as well.

+ +

And that continues to be, like, how we talk to people [laughs] and get that buzzword out there is, like, okay, there's this cool open-source project. Like, one I'm excited about now is OpenTelemetry. And so we're digging into that and figuring out how we can contribute. And can we make a big impact here? And that just opens the door to conversations in a way that is less salesy, right? [laughs]

+ +

And people know us as the contributors and maintainers, and that creates a level of trust that goes a long way. And also, it really speaks to how we operate as a company as well, where the code is open and when we give it back to the customers, it's not. Some organizations will build stuff and then never give it to you. [laughs]

+ +

BRIAN: Yeah. So it sounds like folks at thoughtbot could probably benefit from things like OpenSauced for discoverability. And I get a lot of conversation around in OpenSauced as like, how do I get connected to maintainer of X or maintainer of Y? And the first step is like, how do I even know who the maintainer is? Because when you go to GitHub, you could sort this by last commit date, which not a lot of people know. You can sort the contributors by most frequently and stuff like that.

+ +

But it's challenging to find out who to reach out to when it comes to packages, especially when people move on. Like, someone created a thing. They have tons of commits. And then they look like they're the number one committer for the past ten years, but they left five years ago. Those are things that we're trying to make more discoverable to solve that problem.

+ +

But then, going into that thoughtbot thing, is like being able to reach out to thoughtbot and be like, oh, who can I reach out to about this gem? And, say, I have an idea, or we have an issue; how can we get unblocked because we're using this in our product? And I imagine with consulting, there's an opportunity to say, hey thoughtbot...which, honestly, at Netlify, we used thoughtbot to solve some harder problems for us. We were just like, yeah, we don't have the bandwidth to go down this path. Let's go to consulting to unblock us in this arena.

+ +

VICTORIA: Right. And that was really important to me in making the decision to join thoughtbot last year is that it was built around open source. And that ethos really spoke to me as, like, this is a place where I want to work. [laughs] And you can think of, like, if you're looking for vendors, like, oh, I want to work with people who have that same ethos. So yeah, OpenSauced seems like a really cool product. I'd be curious about how we can leverage it more at thoughtbot.

+ +

BRIAN: We just shipped a feature called Teams, which it's self-explanatory. But, basically, when you build an insight page, you're able to build a team to help the discover process of what's happening in contributions. You get details and reporting on OpenSauced. The goal is basically to unblock teams who are involved in open source together and make it more discoverable for folks who want to find maintainers and collaborate with them.

+ +

VICTORIA: Will, I know we're running close on time. But I had one more question about what you said around making open source more hospitable. And, you know, you mentioned going to Juneteenth Conf. And I'm curious if you have a perspective on if open source is equitably accessible to everyone or if there are things we can be doing as a community to be more inclusive.

+ +

BRIAN: Yeah, it's a great question. So the first answer is quick, it's no. The reason why it's no is because we have to admit [laughs] where there are inequitable situations. And as much as we want to set this up of, like, I want to say that there's opportunity for everyone to contribute based on no matter where their background, but just by your time zone, makes it inequitable of, like, whether you can contribute to open source. Because if you look at the data and zoom out, most open source happens in the West Coast U.S., so from San Francisco to Seattle. Like, majority of contributions are there. There are reasons for that.

+ +

Like, California has a very, very expressive clause of like where you can contribute. And, technically, your employer can block you on doing open-source contributions. Unless you sign...like, at Apple, you sign away your rights to be able to do that in your employee offer letter. Sorry, [laughs] not to be a dig against Apple. Apple buy lots of open source. But what I'm getting at is that the opportunity is there, but it's the awareness thing.

+ +

I'm part of an organization called DevColor. It's an organization of Black engineers in tech. We have squads and monthly meetings where we just talk about our career, and growth, and stuff like that. And I attribute a lot of that interactions to my success is, like, talking to other folks who are years ahead of me and have a lot more experience.

+ +

But I say this because the majority of the folks that I interact with at DevColor they don't do open source because they all...to be a Black engineer at a level of like senior engineer at Netlify, or a staff engineer, or a manager...sorry, I meant, like, Netflix but Netlify too. You basically had a career path of, like, you probably went to school at a decent engineering school, or you figured out how to get a job at Facebook or Google. And, like, that's pretty much it.

+ +

And, like, this is a blanket statement. I totally understand there are outliers. But the majority of the folks I interact with at DevColor they have a job. They have a great job. And they're doing the thing, and they're being very successful. But there's less community interaction. And that's what DevColor exists for is to encourage that community interaction and participation.

+ +

So, at the end of the day, like, there's opportunity to make it more equitable. So things like, every time there's a release cut for a major open-source project, why not go to Black Girls CODE and have them build something with it?

+ +

And, again, very specific, like, React 19 that's currently being tested, why not go to all these other underrepresented organizations and partner with them to show them how to use this project? Because the assumption is everyone in open source, you got to be senior enough to participate, or if it's too hot, get out of the kitchen. But if we set up a place for people to interact and level up, in three or four years from now, you'll see the open-source ecosystem of that project be completely different as far as diversity.

+ +

But it takes that investment to have that onboard ramp to even have that connection or conversation about testing early releases with underrepresented groups in engineering. That's where we have to start, and that's what we're trying to do at OpenSauced. We want to make that connection. I have a whole plan for it. I'll share in a blog post. I also mentioned that a lot of these thoughts are on our blog as well. I've been writing blog posts around these conversations. So opensauced.pizza/blog if you're interested.

+ +

VICTORIA: Very cool. Thank you for that.

+ +

WILL: I'm just processing on the whole conversation. It has just been great.

+ +

VICTORIA: Yes. Thank you so much for sharing with us. And I wonder, do you have any final takeaways for our listeners today, Brian?

+ +

BRIAN: Yeah, final takeaways. Like, if anything at all resonated in this conversation, please reach out, bdougie on GitHub. I'm pretty active with my notifications. So if you @ mention me in a random project, I'll probably jump back in and respond to you. But also Twitter @bdougieYO. And then, I mentioned our blog. We also have a newsletter. So, if you're interested in any of this OpenSauced journey, please join us there, and keep in touch.

+ +

VICTORIA: Wonderful. Thank you so much for joining us today and sharing your story.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

WILL: And you could find me @will23larry

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brian Douglas.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ronbm4DV + + ]]> + + Will Larry + Victoria Guido + Brian Douglas + + + 475: Designing Data Governance From the Ground Up with Lauren Maffeo + https://podcast.thoughtbot.com/475 + 0d052161-dc8a-40a4-a9c0-fa553b465088 + Thu, 18 May 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Lauren Maffeo is the author of Designing Data Governance from the Ground Up. + +Victoria talks to Lauren about human-centered design work, data stewardship and governance, and writing a book anybody can use regardless of industry or team size. + 48:45 + no + + + Lauren Maffeo is the author of Designing Data Governance from the Ground Up. +Victoria talks to Lauren about human-centered design work, data stewardship and governance, and writing a book anybody can use regardless of industry or team size. +Designing Data Governance from the Ground Up (https://www.amazon.com/Designing-Data-Governance-Ground-Data-Driven/dp/1680509802) +Follow Lauren Maffeo on LinkedIn (https://www.linkedin.com/in/laurenmaffeo/) or Twitter (https://twitter.com/LaurenMaffeo). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. +We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. +Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. +JORDYN: Thanks for having us. +DAWN: Yeah, glad to be here. +VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? +JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. +VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. +JORDYN: Wonderful. +VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? +JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. +VICTORIA: What made you decide to start this incubator program this year with thoughtbot? +DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. +And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. +It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. +VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? +DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? +It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. +VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. +JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. +You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. +He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. +You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? +VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? +DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. +So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. +VICTORIA: Wonderful. That's amazing. Thank you both so much. +INTRO MUSIC: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Lauren Maffeo, Author of Designing Data Governance from the Ground Up. Lauren, thank you for joining us. +LAUREN: Thanks so much for having me, Victoria. I'm excited to be here. +VICTORIA: Wonderful. I'm excited to dive right into this topic. But first, maybe just tell me what led you to start writing this book? +LAUREN: I was first inspired to write this book by my clients, actually. I was working as a service designer at Steampunk, which is a human-centered design firm serving the federal government. I still do work for Steampunk. And a few years ago, I was working with a client who had a very large database containing millions of unique data points going back several centuries. +And I realized throughout the course of my discovery process, which is a big part of human-centered design work, that most of their processes for managing the data in this database were purely manual. There was no DevSecOps integrated into their workflows. These workflows often included several people and took up to a week to complete. And this was an organization that had many data points, as mentioned, in its purview. +They also had a large team to manage the data in various ways. But they still really struggled with an overall lack of processes. And really, more importantly, they lacked quality standards for data, which they could then automate throughout their production processes. I realized that even when organizations exist to have data in their purview and to share it with their users, that doesn't necessarily mean that they actually have governance principles that they abide by. +And so that led me to really consider, more broadly, the bigger challenges that we see with technology like AI, machine learning, large language models. We know now that there is a big risk of bias within these technologies themselves due to the data. And when I dug deeper, first as a research analyst at Gartner and then as a service designer at Steampunk, I realized that the big challenge that makes this a reality is lack of governance. +It's not having the quality standards for deciding how data is fit for use. It's not categorizing your data according to the top domains in your organization that produce data. It's lack of clear ownership regarding who owns which data sets and who is able to make decisions about data. It's not having things like a data destruction policy, which shows people how long you hold on to data for. So that knowledge and seeing firsthand how many organizations struggle with that lack of governance that's what inspired me to write the book itself. +And I wanted to write it from the lens of a service designer. I have my own bias towards that, given that I am a practicing service designer. But I do believe that data governance when approached through a design thinking lens, can yield stronger results than if it is that top-down IT approach that many organizations use today unsuccessfully. +VICTORIA: So let me play that back a little bit. So, in your experience, organizations that struggle to make the most out of their data have an issue with defining the authority and who has that authority to make decisions, and you refer to that as governance. So that when it comes down to it, if you're building things and you want to say, is this ethical? Is this right? Is this secure? Is it private enough? Someone needs to be responsible [laughs] for answering that. And I love that you're bringing this human-centered design approach into it. +LAUREN: Yeah, that's exactly right. And I would say that ownership is a big part of data governance. It is one of the most crucial parts. I have a chapter in my book on data stewards, what they are, the roles they play, and how to select them and get them on board with your data governance vision. The main thing I want to emphasize about data stewardship is that it is not just the technical members of your team. Data scientists, data architects, and engineers can all be exceptional data stewards, especially because they work with the data day in and day out. +The challenge I see is that these people typically are not very close to the data, and so they don't have that context for what different data points mean. They might not know offhand what the definitions per data piece are. They might not know the format that the data originates in. That's information that people in non-technical roles tend to possess. +And so, data stewardship and governance is not about turning your sales director into a data engineer or having them build ETL pipelines. But it is about having the people who know that data best be in positions where they're able to make decisions about it, to define it, to decide which pieces of metadata are attached to each piece of data. And then those standards are what get automated throughout the DevSecOps process to make better life cycles that produce better-quality data faster, at speed with fewer resources. +VICTORIA: So, when we talk about authority, what we really mean is, like, who has enough context to make smart decisions? +LAUREN: Who has enough context and also enough expertise? I think a big mistake that we as an industry have made with data management is that we have given the responsibility for all data in an organization to one team, sometimes one person. So, typically, what we've done in the past is we've seen all data in an organization managed by IT. They, as a department, make top-down decisions about who has access to which data, what data definitions exist, where the data catalog lives, if it exists in an organization at all. +And that creates a lot of blockers for people if you always have to go through one team or person to get permission to use data. And then, on top of that, the IT team doesn't have the context that your subject matter experts do about the data in their respective divisions. And so it really is about expanding the idea of who owns data and who is in a position of authority to make decisions about it by collaborating across silos. This is very challenging work to do. +But I would actually say that for smaller organizations, they might lack the resources in, time, and money, and people to do data governance at scale. But what they can do is start embedding data governance as a core principle into the fabric of their organizations. And ultimately, I think that will power them for success in a way that larger organizations were not able to because there is a lot of technical debt out there when it comes to bad data. And one way to avoid that in the future or to at least mitigate it is to establish data governance standards early on. +VICTORIA: Talk me through what your approach would be if you were working with an organization who wants to build-in this into the fabric of how they work. What would be your first steps in engaging with them and identifying where they have needs in part of that discovery process? +LAUREN: In human-centered design, the discovery process occurs very early in a project. This is where you are working hand in hand with your client to figure out what their core needs are and how you can help them solve those core needs. And this is important to do because it's not always obvious what those needs are. +You might get a contract to work on something very specific, whether it's designing the user interface of a database or it's migrating a website. Those are technical challenges to solve. And those are typically the reason why you get contracted to work with your client. But you still have to do quite a bit of work to figure out what the real ask is there and what is causing the need for them to have hired you in the first place. +And so, the first thing I would do if I was walking a client through this is I would start by asking who the most technical senior lead in the organization is. And I would ask how they are managing data today. I think it's really important, to be honest about the state of data in your organization today. +The work that we do designing data governance is very forward-thinking in a lot of ways, but you need a foundation to build upon. And I think people need to be honest about the state of that foundation in their organization. So the first thing I would do is find that most-senior data leader who is responsible for making decisions about data and owns the data strategy because that person is tasked with figuring out how to use data in a way that is going to benefit the business writ large. And so, data governance is a big part of what they are tasked to do. +And so, in the first instance, what I would do is I would host a workshop with the client where I would ask them to do a few things. They would start by answering two questions: What is my company's mission statement, and how do we use data to fulfill that mission statement? These are very baseline questions. And the first one is so obvious and simple that it might be a little bit off-putting because you're tempted to think, as a senior leader, I already know what my company does. Why do I need to answer it like this? +And you need to answer it like this because just like we often get contracts to work on particular technical problems, you'd be surprised by how many senior leaders cannot articulate their company's mission statements. They'll talk to you about their jobs, the tools they use to do their jobs, who they work with on a daily basis. But they still aren't ultimately answering the question of how their job, how the technology they use fulfills a bigger organizational need. +And so, without understanding what that organizational need is, you won't be able to articulate how data fulfills that mission. And if you're not able to explain how data fulfills your company's mission, I doubt you can explain which servers your data lives on, which file format it needs to be converted to, who owns which data sets, where they originate, what your DevSecOps processes are. So answering those two questions about the company mission and how data is used to fulfill that mission is the first step. +The second thing I would do is ask this senior leader, let's say the chief data officer, to define the data domains within their organization. And when we talk about data domains, we are talking about the areas of the business that are the key areas of interest. This can also be the problem spaces that your organization addresses. It also can have a hand in how your organization is designed as is; in other words, who reports to whom? +Do you have sales and marketing within one part of the organization, or are they separate? Do you have customer success as its own wing of the organization separate from product? However your organization is architected, you can draw lines between those different teams, departments, and the domains that your organization works in. +And then, most importantly, you want to be looking at who leads each domain and has oversight over the data in that domain. This is a really important aspect of the work because, as mentioned, stewards play a really key role in upholding and executing data governance. You need data stewards across non-technical and technical roles. So defining not just what the data domains are but who leads each domain in a senior role is really important to mapping out who your data stewards will be and to architect your first data governance council. +And then, finally, the last thing I would have them do in the first instance is map out a business capability map showing not only what their data domains are but then the sub-domains underneath. So, for example, you have sales, and that can be a business capability. But then, within the sales data domain, you're going to have very different types of sales data. You're going to have quarterly sales, bi-annual sales, inbound leads versus outbound leads. You're going to have very different types of data within that sales data domain. And you want to build those out as much as you possibly can across all of your data domains. +If you are a small organization, it's common to have about four to six data domains with subdomains underneath, each of those four to six. But it varies according to each startup and organization and how they are structured. Regardless of how your organization is structured, there's always value in doing those three things. So you start by identifying what your organization does and how data fulfills that goal. You define the core data domains in your organization, including who owns each domain. +And then, you take that information about data domains, and you create a capability map showing not just your core data domains but the subdomains underneath because you're going to use all of that information to architect a future data governance program based on what you currently have today. +VICTORIA: I think that's a great approach, and it makes a lot of sense. Is that kind of, like, the minimum that people should be doing for a data governance program? Like, what's the essentials to do, like, maybe even your due diligence, say, as a health tech startup company? +LAUREN: This is the bare minimum of what I think every organization should do. The specifics of that are different depending on industry, depending on company size, organizational structure. But I wrote this book to be a compass that any organization can use. There's a lot of nuance, especially when we get into the production environment an organization has. There's a lot of nuance there depending on tools, all of that. +And so I wanted to write a book that anybody could use regardless of industry size, team size, all of that information. I would say that those are the essential first steps. And I do think that is part of the discovery process is figuring out where you stand today, and no matter how ugly it might be. Because, like we've mentioned, there is more data produced on a daily basis than ever before. And you are not going into this data governance work with a clean slate. You already have work in your organization that you do to manage data. And you really need to know where there are gaps so that you can address those gaps. +And so, when we go into the production environment and thinking about what you need to do to be managing data for quality on a regular basis, there are a couple of key things. The first is that you need a plan for how you're going to govern data throughout each lifecycle. So you are very likely not using a piece of data once and never again. You are likely using it through several projects. +So you always want to have a plan for governance in production that includes policies on data usage, data archiving, and data destruction. Because you want to make sure that you are fulfilling those principles, whatever they are, throughout each lifecycle because you are managing data as a product. +And that brings me to the next thing that I would encourage people working in data governance to consider, which is taking the data mesh principle of managing data as a product. And this is a fundamental mind shift from how big data has been managed in the past, where it was more of a service. There are many detriments to that, given the volume of data that exists today and given how much data environments have changed. +So, when we think about data mesh, we're really thinking about four key principles. The first is that you want to manage your data according to specific domains. So you want to be creating a cloud environment that really accounts for the nuance of each data domain. That's why it's so important to define what those data domains are. You're going to not just document what those domains are. You're going to be managing and owning data in a domain-specific way. +The second thing is managing data as a product. And so, rather than taking the data as a service approach, you have data stewards who manage their respective data as products within the cloud environment. And so then, for instance, rather than using data about customer interactions in a single business context, you can instead use that data in a range of ways across the organization, and other colleagues can use that data as well. +You also want to have data available as a self-service infrastructure. This is really important in data mesh. Because it emphasizes keeping all data on a centralized platform that manages your storage, streaming, pipelines, and anything else, and this is crucial because it prevents data from leaving in disparate systems on various servers. And it also erases or eases the need to build integrations between those different systems and databases. And it also gives each data steward a way to manage their domain data from the same source. +And then the last principle for data mesh is ecosystem governance. And really, what we're talking about here is reinforcing the data framework and mission statement that you are using to guide all of your work. It's very common in tech for tech startups to operate according to a bigger vision and according to principles that really establish the rationale for why that startup deserves to exist in the world. +And likewise, you want to be doing all of your production work with data according to a bigger framework and mission that you've already shared. And you want to make sure that all of your data is formatted, standardized, and discoverable against equal standards that govern the quality of your data. +VICTORIA: That sounds like data is your biggest value as a company and your greatest source of liability [laughs] and in many ways. And, I'm curious, you mentioned just data as a product, if you can talk more about how that fits into how company owners and founders should be thinking about data and the company they're building. +LAUREN: So that's a very astute comment about data as a liability. That is absolutely true. And that is one of the reasons why governance is not just nice to have. It's really essential, especially in this day and age. The U.S. has been quite lax when it comes to data privacy and protection standards for U.S. citizens. But I do think that that will change over the next several years. I think U.S. citizens will get more data protections. And that means that organizations are going to have to be more astute about tracking their data and making sure that they are using it in appropriate ways. +So, when we're talking to founders who want to consider how to govern data as a product, you're thinking about data stewards taking on the role of product managers and using data in ways that benefits not just them and their respective domains but also giving it context and making it available to the wider business in a way that it was not available before. +So if you are architecting your data mesh environment in the cloud, what you might be able to do is create various domains that exist on their own little microservice environments. And so you have all of these different domains that exist in one environment, but then they all connect to this bigger data mesh catalog. And from the catalog, that is where your colleagues across the business can access the data in your domain. +Now, you don't want to necessarily give free rein for anybody in your organization to get any data at any time. You might want to establish guardrails for who is able to access which data and what those parameters are. And the data as a product mindset allows you to do that because it gives you, as the data steward/pseudo pm, the autonomy to define how and when your data is used, rather than giving that responsibility to a third-party colleague who does not have that context about the data in your domain. +VICTORIA: I like that about really giving the people who have the right context the ability to manage their product and their data within their product. That makes a lot of sense to me. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design-driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: What is it like to really bring in this culture of design-thinking into an organization that's built a product around data? +LAUREN: It can be incredibly hard. I have found that folks really vary in their approach to this type of work. I think many people that I talk to have tried doing data governance to some degree in the past, and, for various reasons, it was not successful. So as a result, they're very hesitant to try again. I think also for many technical leaders, if they're in CIO, CDO, CTO roles, they are not used to design thinking or to doing human-centered design work. +That's not the ethos that was part of the tech space for a very long time. It was all about the technology, building what you could, experimenting and tinkering, and then figuring out the user part later. And so this is a real fundamental mindset shift to insist on having a vision for how data benefits your business before you start investing money and people into building different data pipelines and resources. +It's also a fundamental shift for everyone in an organization because we, in society writ large, are taught to believe that data is the responsibility of one person or one team. And we just can't afford to think like that anymore. There is too much data produced and ingested on a daily basis for it to fall to one person or one team. +And even if you do have a technical team who is most adept at managing the cloud environment, the data architecture, building the new models for things like fraud detection, that's all the purview of maybe one team that is more technical. But that does not mean that the rest of the organization doesn't have a part to play in defining the standards for data that govern everything about the technical environment. +And I think a big comparison we can make is to security. Many of us… most of us, even if we work in tech, are not cybersecurity experts. But we also know that employees are the number one cause of breaches at organizations. There's no malintent behind that, but people are most likely to expose company data and cause a breach from within the company itself. And so organizations know that they are responsible for creating not just secure technical environments but educating their employees and their workforce on how to be stewards of security. +And so, even at my company, we run constant tests to see who is going to be vulnerable to phishing? Who is going to click on malicious links? They run quarterly tests to assess how healthy we are from a cybersecurity perspective. And if you click on a phishing attempt and you fall for it, you are directed to a self-service education video that you have to complete, going over the aspects of this phishing test, what made it malicious. +And then you're taught to educate yourself on what to look for in the future. We really need to be doing something very similar with data. And it doesn't mean that you host a two-hour training and then never talk about data again. You really need to look at ways to weave data governance into the fabric of your organization so that it is not disruptive to anybody's day. It's a natural part of their day, and it is part of working at your organization. Part of your organizational goals include having people serve as data stewards. And you emphasize that stewardship is for everyone, not just the people in the technology side of the business. +VICTORIA: I love that. And I think there's something to be said for having more people involved in the data process and how that will impact just the quality of your data and the inclusivity of what you're building to bring those perspectives together. +LAUREN: I agree. And that's the real goal. And I think this is, again, something that's actually easier for startups to do because startups are naturally more nimble. They find out what works, what doesn't work. They're willing to try things. They have to be willing to try things. Because, to use a really clichéd phrase, if they're not innovating, then they're going to get stale and go out of business. +But the other benefit that I think startups have when they're doing this work is the small size. Yes, you don't have the budget or team size of a company like JP Morgan, that is enormous, or a big bank. But you still have an opportunity to really design a culture, an organizational culture that puts data first, regardless of role. And then you can architect the structure of every role according to that vision. +And I think that's a really exciting opportunity for companies, especially if they are selling data or already giving data as a product in some way. If they're selling, you know, data as a product services, this is a really great approach and a unique approach to solving data governance and making it everyone's opportunity to grow their own roles and work smarter. +VICTORIA: Right. And when it's really the core of your business, it makes sense to pay more attention to that area [laughs]. It's what makes it worthwhile. It's what makes potential investors know that you're a real company who takes things seriously. [laughs] +LAUREN: That's true. That's very true. +VICTORIA: I'm thinking, what questions...do you have any questions for me? +LAUREN: I'm curious to know, when you talk to thoughtbot clients, what are the main aspects of data that they struggle with? I hear a variety of reasons for data struggles when I talk to clients, when I talk to people on the tech side, either as engineers or architects. I'm curious to hear what the thoughtbot community struggles with the most when it comes to managing big data. +VICTORIA: I think, in my experience, in the last less than a year that I've been with thoughtbot, one challenge which is sort of related to data...but I think for many small companies or startups they don't really have an IT department per se. So, like, what you mentioned early on in the discovery process as, like, who is the most senior technical person on your team? And that person may have little to no experience managing an IT operations group. +I think it's really bringing consulting from the ground up for an organization on IT operations, data management, user and access management. Those types of policies might just be something they hadn't considered before because it's not in their background and experience. But maybe once they've gotten set up, I think the other interesting part that happens is sometimes there's just data that's just not being managed at all. And there are processes and bits and pieces of code in app that no one really knows what they are, who they're used for, [laughs] where the data goes. And then, you know, the connections between data. +So everything that you're mentioning that could happen when you don't do data governance, where it can slow down deployment processes. It can mean that you're giving access to people who maybe shouldn't have access to production data. It can mean that you have vulnerabilities in your infrastructure. That means someone could have compromised your data already, and you just don't know about it. Just some of the issues that we see related to data across the spectrum of people in their lifecycle of their startups. +LAUREN: That makes total sense, I think, especially when you are in a startup. If you're going by the typical startup model, you have that business-minded founder, and then you likely have a more technical co-founder. But we, I think, make the assumption that if you are, quote, unquote, "technical," you, therefore, know how to do anything and everything about every system, every framework, every type of cloud environment. And we all know that that's just not the case. +And so it's easy to try to find the Chief Technology Officer or the Chief Information Officer if one exists and to think, oh, this is the right person for the job. And they might be the most qualified person given the context, but that still doesn't mean that they have experience doing this work. The reality is that very few people today have deep hands-on experience making decisions about data with the volume that we see today. And so it's a new frontier for many people. +And then, on top of that, like you said as well, it's really difficult to know where your data lives and to track it. And the amount of work that goes into answering those very basic questions is enormous. And that's why documentation is so important. That's why data lineage in your architecture is so important. It really gives you a snapshot of which data lives where, how it's used. And that is invaluable in terms of reducing technical debt. +VICTORIA: I agree. And I wonder if you have any tips for people facilitating conversations in their organization about data governance. What would you tell them to make it less scary and more fun, more appealing to work on? +LAUREN: I both love and hate the term data governance. Because it's a word that you say, and whether you are technical or not, many people tune out as soon as they hear it because it is, in a way, a scary word. It makes people think purely of compliance, of being told what they can't do. And that can be a real challenge for folks. +So I would say that if you are tasked with making a data governance program across your organization, you have to invest in making it real for people. You have to sell them on stewardship by articulating what folks will gain from serving as stewards. I think that's really critical because we are going to be asking folks to join a cause that they're not going to understand why it affects them or why it benefits them at first. And so it's really your job to articulate not only the benefits to them of helping to set up this data stewardship work but also articulating how data governance will help them get better at their jobs. +I also think you have to create a culture where you are not only encouraging people to work across party lines, so to speak, to work across silos but to reward them for doing so. You are, especially in the early months, asking a lot of people who join your data stewardship initiatives and your data governance council you're asking them to build something from the ground up, and that's not easy work. +So I think any opportunity you can come up with to reward stewards in the form of bonuses or in terms of giving them more leeway to do their jobs more of a title bump than they might have had otherwise. Giving them formal recognition for their contributions to data governance is really essential as well. Because then they see that they are rewarded for contributing to the thought leadership that helps the data governance move forward. +VICTORIA: I'm curious, what is your favorite way to be rewarded at work, Lauren? +LAUREN: So I am a words person. When we talk about love languages, one of them is words of affirmation. And I would say that is the best way to quote, unquote, "reward me." I save emails and screenshots of text messages and emails that have really meant a lot to me. If someone sends me a handwritten card that really strikes a chord, I will save that card for years. My refrigerator is filled with holiday cards and birthday cards, even from years past. +And so any way to recognize people for the job they're doing and to let someone know that they're seen, and their work is seen and valued really resonates with me. I think this is especially important in remote environments because I love working from home, and I am at home alone all day. And so, especially if you are the only person of your kind, of your role on your team, it's very easy to feel insular and to wonder if you're hitting the mark, if you're doing a good job. I think recognition, whether verbally or on Slack, of a job well done it really resonates with me. And that's a great way to feel rewarded. +VICTORIA: I love that. And being fully remote with thoughtbot, I can feel that as well. We have a big culture of recognizing people. At least weekly, we do 15Five as a tool to kind of give people high-fives across the company. +LAUREN: Yep, Steampunk does...we use Lattice. And people can submit praise and recognition for their colleagues in Lattice. And it's hooked up to Slack. And so then, when someone submits positive feedback or a kudos to a colleague in Lattice, then everyone sees it in Slack. And I think that's a great way to boost morale and give people a little visibility that they might not have gotten otherwise, especially because we also do consulting work. +So we are knee-deep in our projects on a daily basis, and we don't always see or know what our colleagues are working on. So little things like that go a long way towards making people feel recognized and valued as part of a bigger company. But I'm also curious, Victoria, what's your favorite way to get rewarded and recognized at work? +VICTORIA: I think I also like the verbal. I feel like I like giving high-fives more than I like receiving them. But sometimes also, like, working at thoughtbot, there are just so many amazing people who help me all throughout the day. I start writing them, and then I'm like, well, I have to also thank this person, and then this person. And then I just get overwhelmed. [laughs] So I'm trying to do more often so I don't have a backlog of them throughout the week and then get overwhelmed on Friday. +LAUREN: I think that's a great way to do it, and I think it's especially important when you're in a leadership role. Something that I'm realizing more and more as I progress in my career is that the more senior you are, the more your morale and attitude sets the tone for the rest of the team. And that's why I think if you are in a position to lead data governance, your approach to it is so crucial to success. Because you really have to get people on board with something that they might not understand at first, that they might resent it first. +This is work that seems simple on the surface, but it's actually very difficult. The technology is easy. The people are what's hard. And you really have to come in, I think, emphasizing to your data stewards and your broader organization, not just what governance is, because, frankly, a lot of people don't care. But you really have to make it tangible for them. And you have to help them see that governance affects everyone, and everyone can have a hand in co-creating it through shared standards. +I think there's a lot to be learned from the open-source community in this regard. The open-source community, more than any other I can think of, is the model of self-governance. It does not mean that it's perfect. But it does mean that people from all roles, backgrounds have a shared mission to build something from nothing and to make it an initiative that other people will benefit from. And I think that attitude is really well-positioned for success with data governance. +VICTORIA: I love that. And great points all around on how data governance can really impact an organization. Are there any final takeaways for our listeners? +LAUREN: The biggest takeaway I would say is to be thoughtful about how you roll out data governance in your organization. But don't be scared if your organization is small. Again, it's very common for people to think my business is too small to really implement governance. We don't have the budget for, you know, the AWS environment we might need. Or we don't have the right number of people to serve as stewards. We don't actually have many data domains yet because we're so new. +And I would say start with what you have. If you are a business in today's day and age, I guarantee that you have enough data in your possession to start building out a data governance program that is thoughtful and mission-oriented. And I would really encourage everyone to do that, regardless of how big your organization is. +And then the other takeaway I would say is, if you remember nothing else about data governance, I would say to remember that you automate your standards. Your standards for data quality, data destruction, data usage are not divorced from your technical team's production environments; it's the exact opposite. Your standards should govern your environment, and they should be a lighthouse when you are doing that work. And so you always want to try to integrate your standards into your production environment, into your ETL pipelines, into your DevSecOps. That is where the magic happens. Keeping them siloed won't work. +And so I'd love for people, if you really enjoyed this episode and the conversation resonated with you, too, get a copy of the book. It is my first book. And I was really excited to work with the Pragmatic Programmers on it. So if readers go to pragprog.com, they can get a copy of the book directly through the publisher. But the book is also available at Target, Barnes & Noble, Amazon, and local bookstores. So I am very grateful as a first-time author for any and all support. And I would really also love to hear from thoughtbot clients and podcast listeners what you thought of the book because version two is not out of the question. +VICTORIA: Well, looking forward to it. Thank you again so much, Lauren, for joining us today. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Lauren Maffeo. + + + Lauren Maffeo is the author of Designing Data Governance from the Ground Up.

+ +

Victoria talks to Lauren about human-centered design work, data stewardship and governance, and writing a book anybody can use regardless of industry or team size.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Lauren Maffeo, Author of Designing Data Governance from the Ground Up. Lauren, thank you for joining us.

+ +

LAUREN: Thanks so much for having me, Victoria. I'm excited to be here.

+ +

VICTORIA: Wonderful. I'm excited to dive right into this topic. But first, maybe just tell me what led you to start writing this book?

+ +

LAUREN: I was first inspired to write this book by my clients, actually. I was working as a service designer at Steampunk, which is a human-centered design firm serving the federal government. I still do work for Steampunk. And a few years ago, I was working with a client who had a very large database containing millions of unique data points going back several centuries.

+ +

And I realized throughout the course of my discovery process, which is a big part of human-centered design work, that most of their processes for managing the data in this database were purely manual. There was no DevSecOps integrated into their workflows. These workflows often included several people and took up to a week to complete. And this was an organization that had many data points, as mentioned, in its purview.

+ +

They also had a large team to manage the data in various ways. But they still really struggled with an overall lack of processes. And really, more importantly, they lacked quality standards for data, which they could then automate throughout their production processes. I realized that even when organizations exist to have data in their purview and to share it with their users, that doesn't necessarily mean that they actually have governance principles that they abide by.

+ +

And so that led me to really consider, more broadly, the bigger challenges that we see with technology like AI, machine learning, large language models. We know now that there is a big risk of bias within these technologies themselves due to the data. And when I dug deeper, first as a research analyst at Gartner and then as a service designer at Steampunk, I realized that the big challenge that makes this a reality is lack of governance.

+ +

It's not having the quality standards for deciding how data is fit for use. It's not categorizing your data according to the top domains in your organization that produce data. It's lack of clear ownership regarding who owns which data sets and who is able to make decisions about data. It's not having things like a data destruction policy, which shows people how long you hold on to data for. So that knowledge and seeing firsthand how many organizations struggle with that lack of governance that's what inspired me to write the book itself.

+ +

And I wanted to write it from the lens of a service designer. I have my own bias towards that, given that I am a practicing service designer. But I do believe that data governance when approached through a design thinking lens, can yield stronger results than if it is that top-down IT approach that many organizations use today unsuccessfully.

+ +

VICTORIA: So let me play that back a little bit. So, in your experience, organizations that struggle to make the most out of their data have an issue with defining the authority and who has that authority to make decisions, and you refer to that as governance. So that when it comes down to it, if you're building things and you want to say, is this ethical? Is this right? Is this secure? Is it private enough? Someone needs to be responsible [laughs] for answering that. And I love that you're bringing this human-centered design approach into it.

+ +

LAUREN: Yeah, that's exactly right. And I would say that ownership is a big part of data governance. It is one of the most crucial parts. I have a chapter in my book on data stewards, what they are, the roles they play, and how to select them and get them on board with your data governance vision. The main thing I want to emphasize about data stewardship is that it is not just the technical members of your team. Data scientists, data architects, and engineers can all be exceptional data stewards, especially because they work with the data day in and day out.

+ +

The challenge I see is that these people typically are not very close to the data, and so they don't have that context for what different data points mean. They might not know offhand what the definitions per data piece are. They might not know the format that the data originates in. That's information that people in non-technical roles tend to possess.

+ +

And so, data stewardship and governance is not about turning your sales director into a data engineer or having them build ETL pipelines. But it is about having the people who know that data best be in positions where they're able to make decisions about it, to define it, to decide which pieces of metadata are attached to each piece of data. And then those standards are what get automated throughout the DevSecOps process to make better life cycles that produce better-quality data faster, at speed with fewer resources.

+ +

VICTORIA: So, when we talk about authority, what we really mean is, like, who has enough context to make smart decisions?

+ +

LAUREN: Who has enough context and also enough expertise? I think a big mistake that we as an industry have made with data management is that we have given the responsibility for all data in an organization to one team, sometimes one person. So, typically, what we've done in the past is we've seen all data in an organization managed by IT. They, as a department, make top-down decisions about who has access to which data, what data definitions exist, where the data catalog lives, if it exists in an organization at all.

+ +

And that creates a lot of blockers for people if you always have to go through one team or person to get permission to use data. And then, on top of that, the IT team doesn't have the context that your subject matter experts do about the data in their respective divisions. And so it really is about expanding the idea of who owns data and who is in a position of authority to make decisions about it by collaborating across silos. This is very challenging work to do.

+ +

But I would actually say that for smaller organizations, they might lack the resources in, time, and money, and people to do data governance at scale. But what they can do is start embedding data governance as a core principle into the fabric of their organizations. And ultimately, I think that will power them for success in a way that larger organizations were not able to because there is a lot of technical debt out there when it comes to bad data. And one way to avoid that in the future or to at least mitigate it is to establish data governance standards early on.

+ +

VICTORIA: Talk me through what your approach would be if you were working with an organization who wants to build-in this into the fabric of how they work. What would be your first steps in engaging with them and identifying where they have needs in part of that discovery process?

+ +

LAUREN: In human-centered design, the discovery process occurs very early in a project. This is where you are working hand in hand with your client to figure out what their core needs are and how you can help them solve those core needs. And this is important to do because it's not always obvious what those needs are.

+ +

You might get a contract to work on something very specific, whether it's designing the user interface of a database or it's migrating a website. Those are technical challenges to solve. And those are typically the reason why you get contracted to work with your client. But you still have to do quite a bit of work to figure out what the real ask is there and what is causing the need for them to have hired you in the first place.

+ +

And so, the first thing I would do if I was walking a client through this is I would start by asking who the most technical senior lead in the organization is. And I would ask how they are managing data today. I think it's really important, to be honest about the state of data in your organization today.

+ +

The work that we do designing data governance is very forward-thinking in a lot of ways, but you need a foundation to build upon. And I think people need to be honest about the state of that foundation in their organization. So the first thing I would do is find that most-senior data leader who is responsible for making decisions about data and owns the data strategy because that person is tasked with figuring out how to use data in a way that is going to benefit the business writ large. And so, data governance is a big part of what they are tasked to do.

+ +

And so, in the first instance, what I would do is I would host a workshop with the client where I would ask them to do a few things. They would start by answering two questions: What is my company's mission statement, and how do we use data to fulfill that mission statement? These are very baseline questions. And the first one is so obvious and simple that it might be a little bit off-putting because you're tempted to think, as a senior leader, I already know what my company does. Why do I need to answer it like this?

+ +

And you need to answer it like this because just like we often get contracts to work on particular technical problems, you'd be surprised by how many senior leaders cannot articulate their company's mission statements. They'll talk to you about their jobs, the tools they use to do their jobs, who they work with on a daily basis. But they still aren't ultimately answering the question of how their job, how the technology they use fulfills a bigger organizational need.

+ +

And so, without understanding what that organizational need is, you won't be able to articulate how data fulfills that mission. And if you're not able to explain how data fulfills your company's mission, I doubt you can explain which servers your data lives on, which file format it needs to be converted to, who owns which data sets, where they originate, what your DevSecOps processes are. So answering those two questions about the company mission and how data is used to fulfill that mission is the first step.

+ +

The second thing I would do is ask this senior leader, let's say the chief data officer, to define the data domains within their organization. And when we talk about data domains, we are talking about the areas of the business that are the key areas of interest. This can also be the problem spaces that your organization addresses. It also can have a hand in how your organization is designed as is; in other words, who reports to whom?

+ +

Do you have sales and marketing within one part of the organization, or are they separate? Do you have customer success as its own wing of the organization separate from product? However your organization is architected, you can draw lines between those different teams, departments, and the domains that your organization works in.

+ +

And then, most importantly, you want to be looking at who leads each domain and has oversight over the data in that domain. This is a really important aspect of the work because, as mentioned, stewards play a really key role in upholding and executing data governance. You need data stewards across non-technical and technical roles. So defining not just what the data domains are but who leads each domain in a senior role is really important to mapping out who your data stewards will be and to architect your first data governance council.

+ +

And then, finally, the last thing I would have them do in the first instance is map out a business capability map showing not only what their data domains are but then the sub-domains underneath. So, for example, you have sales, and that can be a business capability. But then, within the sales data domain, you're going to have very different types of sales data. You're going to have quarterly sales, bi-annual sales, inbound leads versus outbound leads. You're going to have very different types of data within that sales data domain. And you want to build those out as much as you possibly can across all of your data domains.

+ +

If you are a small organization, it's common to have about four to six data domains with subdomains underneath, each of those four to six. But it varies according to each startup and organization and how they are structured. Regardless of how your organization is structured, there's always value in doing those three things. So you start by identifying what your organization does and how data fulfills that goal. You define the core data domains in your organization, including who owns each domain.

+ +

And then, you take that information about data domains, and you create a capability map showing not just your core data domains but the subdomains underneath because you're going to use all of that information to architect a future data governance program based on what you currently have today.

+ +

VICTORIA: I think that's a great approach, and it makes a lot of sense. Is that kind of, like, the minimum that people should be doing for a data governance program? Like, what's the essentials to do, like, maybe even your due diligence, say, as a health tech startup company?

+ +

LAUREN: This is the bare minimum of what I think every organization should do. The specifics of that are different depending on industry, depending on company size, organizational structure. But I wrote this book to be a compass that any organization can use. There's a lot of nuance, especially when we get into the production environment an organization has. There's a lot of nuance there depending on tools, all of that.

+ +

And so I wanted to write a book that anybody could use regardless of industry size, team size, all of that information. I would say that those are the essential first steps. And I do think that is part of the discovery process is figuring out where you stand today, and no matter how ugly it might be. Because, like we've mentioned, there is more data produced on a daily basis than ever before. And you are not going into this data governance work with a clean slate. You already have work in your organization that you do to manage data. And you really need to know where there are gaps so that you can address those gaps.

+ +

And so, when we go into the production environment and thinking about what you need to do to be managing data for quality on a regular basis, there are a couple of key things. The first is that you need a plan for how you're going to govern data throughout each lifecycle. So you are very likely not using a piece of data once and never again. You are likely using it through several projects.

+ +

So you always want to have a plan for governance in production that includes policies on data usage, data archiving, and data destruction. Because you want to make sure that you are fulfilling those principles, whatever they are, throughout each lifecycle because you are managing data as a product.

+ +

And that brings me to the next thing that I would encourage people working in data governance to consider, which is taking the data mesh principle of managing data as a product. And this is a fundamental mind shift from how big data has been managed in the past, where it was more of a service. There are many detriments to that, given the volume of data that exists today and given how much data environments have changed.

+ +

So, when we think about data mesh, we're really thinking about four key principles. The first is that you want to manage your data according to specific domains. So you want to be creating a cloud environment that really accounts for the nuance of each data domain. That's why it's so important to define what those data domains are. You're going to not just document what those domains are. You're going to be managing and owning data in a domain-specific way.

+ +

The second thing is managing data as a product. And so, rather than taking the data as a service approach, you have data stewards who manage their respective data as products within the cloud environment. And so then, for instance, rather than using data about customer interactions in a single business context, you can instead use that data in a range of ways across the organization, and other colleagues can use that data as well.

+ +

You also want to have data available as a self-service infrastructure. This is really important in data mesh. Because it emphasizes keeping all data on a centralized platform that manages your storage, streaming, pipelines, and anything else, and this is crucial because it prevents data from leaving in disparate systems on various servers. And it also erases or eases the need to build integrations between those different systems and databases. And it also gives each data steward a way to manage their domain data from the same source.

+ +

And then the last principle for data mesh is ecosystem governance. And really, what we're talking about here is reinforcing the data framework and mission statement that you are using to guide all of your work. It's very common in tech for tech startups to operate according to a bigger vision and according to principles that really establish the rationale for why that startup deserves to exist in the world.

+ +

And likewise, you want to be doing all of your production work with data according to a bigger framework and mission that you've already shared. And you want to make sure that all of your data is formatted, standardized, and discoverable against equal standards that govern the quality of your data.

+ +

VICTORIA: That sounds like data is your biggest value as a company and your greatest source of liability [laughs] and in many ways. And, I'm curious, you mentioned just data as a product, if you can talk more about how that fits into how company owners and founders should be thinking about data and the company they're building.

+ +

LAUREN: So that's a very astute comment about data as a liability. That is absolutely true. And that is one of the reasons why governance is not just nice to have. It's really essential, especially in this day and age. The U.S. has been quite lax when it comes to data privacy and protection standards for U.S. citizens. But I do think that that will change over the next several years. I think U.S. citizens will get more data protections. And that means that organizations are going to have to be more astute about tracking their data and making sure that they are using it in appropriate ways.

+ +

So, when we're talking to founders who want to consider how to govern data as a product, you're thinking about data stewards taking on the role of product managers and using data in ways that benefits not just them and their respective domains but also giving it context and making it available to the wider business in a way that it was not available before.

+ +

So if you are architecting your data mesh environment in the cloud, what you might be able to do is create various domains that exist on their own little microservice environments. And so you have all of these different domains that exist in one environment, but then they all connect to this bigger data mesh catalog. And from the catalog, that is where your colleagues across the business can access the data in your domain.

+ +

Now, you don't want to necessarily give free rein for anybody in your organization to get any data at any time. You might want to establish guardrails for who is able to access which data and what those parameters are. And the data as a product mindset allows you to do that because it gives you, as the data steward/pseudo pm, the autonomy to define how and when your data is used, rather than giving that responsibility to a third-party colleague who does not have that context about the data in your domain.

+ +

VICTORIA: I like that about really giving the people who have the right context the ability to manage their product and their data within their product. That makes a lot of sense to me.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design-driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: What is it like to really bring in this culture of design-thinking into an organization that's built a product around data?

+ +

LAUREN: It can be incredibly hard. I have found that folks really vary in their approach to this type of work. I think many people that I talk to have tried doing data governance to some degree in the past, and, for various reasons, it was not successful. So as a result, they're very hesitant to try again. I think also for many technical leaders, if they're in CIO, CDO, CTO roles, they are not used to design thinking or to doing human-centered design work.

+ +

That's not the ethos that was part of the tech space for a very long time. It was all about the technology, building what you could, experimenting and tinkering, and then figuring out the user part later. And so this is a real fundamental mindset shift to insist on having a vision for how data benefits your business before you start investing money and people into building different data pipelines and resources.

+ +

It's also a fundamental shift for everyone in an organization because we, in society writ large, are taught to believe that data is the responsibility of one person or one team. And we just can't afford to think like that anymore. There is too much data produced and ingested on a daily basis for it to fall to one person or one team.

+ +

And even if you do have a technical team who is most adept at managing the cloud environment, the data architecture, building the new models for things like fraud detection, that's all the purview of maybe one team that is more technical. But that does not mean that the rest of the organization doesn't have a part to play in defining the standards for data that govern everything about the technical environment.

+ +

And I think a big comparison we can make is to security. Many of us… most of us, even if we work in tech, are not cybersecurity experts. But we also know that employees are the number one cause of breaches at organizations. There's no malintent behind that, but people are most likely to expose company data and cause a breach from within the company itself. And so organizations know that they are responsible for creating not just secure technical environments but educating their employees and their workforce on how to be stewards of security.

+ +

And so, even at my company, we run constant tests to see who is going to be vulnerable to phishing? Who is going to click on malicious links? They run quarterly tests to assess how healthy we are from a cybersecurity perspective. And if you click on a phishing attempt and you fall for it, you are directed to a self-service education video that you have to complete, going over the aspects of this phishing test, what made it malicious.

+ +

And then you're taught to educate yourself on what to look for in the future. We really need to be doing something very similar with data. And it doesn't mean that you host a two-hour training and then never talk about data again. You really need to look at ways to weave data governance into the fabric of your organization so that it is not disruptive to anybody's day. It's a natural part of their day, and it is part of working at your organization. Part of your organizational goals include having people serve as data stewards. And you emphasize that stewardship is for everyone, not just the people in the technology side of the business.

+ +

VICTORIA: I love that. And I think there's something to be said for having more people involved in the data process and how that will impact just the quality of your data and the inclusivity of what you're building to bring those perspectives together.

+ +

LAUREN: I agree. And that's the real goal. And I think this is, again, something that's actually easier for startups to do because startups are naturally more nimble. They find out what works, what doesn't work. They're willing to try things. They have to be willing to try things. Because, to use a really clichéd phrase, if they're not innovating, then they're going to get stale and go out of business.

+ +

But the other benefit that I think startups have when they're doing this work is the small size. Yes, you don't have the budget or team size of a company like JP Morgan, that is enormous, or a big bank. But you still have an opportunity to really design a culture, an organizational culture that puts data first, regardless of role. And then you can architect the structure of every role according to that vision.

+ +

And I think that's a really exciting opportunity for companies, especially if they are selling data or already giving data as a product in some way. If they're selling, you know, data as a product services, this is a really great approach and a unique approach to solving data governance and making it everyone's opportunity to grow their own roles and work smarter.

+ +

VICTORIA: Right. And when it's really the core of your business, it makes sense to pay more attention to that area [laughs]. It's what makes it worthwhile. It's what makes potential investors know that you're a real company who takes things seriously. [laughs]

+ +

LAUREN: That's true. That's very true.

+ +

VICTORIA: I'm thinking, what questions...do you have any questions for me?

+ +

LAUREN: I'm curious to know, when you talk to thoughtbot clients, what are the main aspects of data that they struggle with? I hear a variety of reasons for data struggles when I talk to clients, when I talk to people on the tech side, either as engineers or architects. I'm curious to hear what the thoughtbot community struggles with the most when it comes to managing big data.

+ +

VICTORIA: I think, in my experience, in the last less than a year that I've been with thoughtbot, one challenge which is sort of related to data...but I think for many small companies or startups they don't really have an IT department per se. So, like, what you mentioned early on in the discovery process as, like, who is the most senior technical person on your team? And that person may have little to no experience managing an IT operations group.

+ +

I think it's really bringing consulting from the ground up for an organization on IT operations, data management, user and access management. Those types of policies might just be something they hadn't considered before because it's not in their background and experience. But maybe once they've gotten set up, I think the other interesting part that happens is sometimes there's just data that's just not being managed at all. And there are processes and bits and pieces of code in app that no one really knows what they are, who they're used for, [laughs] where the data goes. And then, you know, the connections between data.

+ +

So everything that you're mentioning that could happen when you don't do data governance, where it can slow down deployment processes. It can mean that you're giving access to people who maybe shouldn't have access to production data. It can mean that you have vulnerabilities in your infrastructure. That means someone could have compromised your data already, and you just don't know about it. Just some of the issues that we see related to data across the spectrum of people in their lifecycle of their startups.

+ +

LAUREN: That makes total sense, I think, especially when you are in a startup. If you're going by the typical startup model, you have that business-minded founder, and then you likely have a more technical co-founder. But we, I think, make the assumption that if you are, quote, unquote, "technical," you, therefore, know how to do anything and everything about every system, every framework, every type of cloud environment. And we all know that that's just not the case.

+ +

And so it's easy to try to find the Chief Technology Officer or the Chief Information Officer if one exists and to think, oh, this is the right person for the job. And they might be the most qualified person given the context, but that still doesn't mean that they have experience doing this work. The reality is that very few people today have deep hands-on experience making decisions about data with the volume that we see today. And so it's a new frontier for many people.

+ +

And then, on top of that, like you said as well, it's really difficult to know where your data lives and to track it. And the amount of work that goes into answering those very basic questions is enormous. And that's why documentation is so important. That's why data lineage in your architecture is so important. It really gives you a snapshot of which data lives where, how it's used. And that is invaluable in terms of reducing technical debt.

+ +

VICTORIA: I agree. And I wonder if you have any tips for people facilitating conversations in their organization about data governance. What would you tell them to make it less scary and more fun, more appealing to work on?

+ +

LAUREN: I both love and hate the term data governance. Because it's a word that you say, and whether you are technical or not, many people tune out as soon as they hear it because it is, in a way, a scary word. It makes people think purely of compliance, of being told what they can't do. And that can be a real challenge for folks.

+ +

So I would say that if you are tasked with making a data governance program across your organization, you have to invest in making it real for people. You have to sell them on stewardship by articulating what folks will gain from serving as stewards. I think that's really critical because we are going to be asking folks to join a cause that they're not going to understand why it affects them or why it benefits them at first. And so it's really your job to articulate not only the benefits to them of helping to set up this data stewardship work but also articulating how data governance will help them get better at their jobs.

+ +

I also think you have to create a culture where you are not only encouraging people to work across party lines, so to speak, to work across silos but to reward them for doing so. You are, especially in the early months, asking a lot of people who join your data stewardship initiatives and your data governance council you're asking them to build something from the ground up, and that's not easy work.

+ +

So I think any opportunity you can come up with to reward stewards in the form of bonuses or in terms of giving them more leeway to do their jobs more of a title bump than they might have had otherwise. Giving them formal recognition for their contributions to data governance is really essential as well. Because then they see that they are rewarded for contributing to the thought leadership that helps the data governance move forward.

+ +

VICTORIA: I'm curious, what is your favorite way to be rewarded at work, Lauren?

+ +

LAUREN: So I am a words person. When we talk about love languages, one of them is words of affirmation. And I would say that is the best way to quote, unquote, "reward me." I save emails and screenshots of text messages and emails that have really meant a lot to me. If someone sends me a handwritten card that really strikes a chord, I will save that card for years. My refrigerator is filled with holiday cards and birthday cards, even from years past.

+ +

And so any way to recognize people for the job they're doing and to let someone know that they're seen, and their work is seen and valued really resonates with me. I think this is especially important in remote environments because I love working from home, and I am at home alone all day. And so, especially if you are the only person of your kind, of your role on your team, it's very easy to feel insular and to wonder if you're hitting the mark, if you're doing a good job. I think recognition, whether verbally or on Slack, of a job well done it really resonates with me. And that's a great way to feel rewarded.

+ +

VICTORIA: I love that. And being fully remote with thoughtbot, I can feel that as well. We have a big culture of recognizing people. At least weekly, we do 15Five as a tool to kind of give people high-fives across the company.

+ +

LAUREN: Yep, Steampunk does...we use Lattice. And people can submit praise and recognition for their colleagues in Lattice. And it's hooked up to Slack. And so then, when someone submits positive feedback or a kudos to a colleague in Lattice, then everyone sees it in Slack. And I think that's a great way to boost morale and give people a little visibility that they might not have gotten otherwise, especially because we also do consulting work.

+ +

So we are knee-deep in our projects on a daily basis, and we don't always see or know what our colleagues are working on. So little things like that go a long way towards making people feel recognized and valued as part of a bigger company. But I'm also curious, Victoria, what's your favorite way to get rewarded and recognized at work?

+ +

VICTORIA: I think I also like the verbal. I feel like I like giving high-fives more than I like receiving them. But sometimes also, like, working at thoughtbot, there are just so many amazing people who help me all throughout the day. I start writing them, and then I'm like, well, I have to also thank this person, and then this person. And then I just get overwhelmed. [laughs] So I'm trying to do more often so I don't have a backlog of them throughout the week and then get overwhelmed on Friday.

+ +

LAUREN: I think that's a great way to do it, and I think it's especially important when you're in a leadership role. Something that I'm realizing more and more as I progress in my career is that the more senior you are, the more your morale and attitude sets the tone for the rest of the team. And that's why I think if you are in a position to lead data governance, your approach to it is so crucial to success. Because you really have to get people on board with something that they might not understand at first, that they might resent it first.

+ +

This is work that seems simple on the surface, but it's actually very difficult. The technology is easy. The people are what's hard. And you really have to come in, I think, emphasizing to your data stewards and your broader organization, not just what governance is, because, frankly, a lot of people don't care. But you really have to make it tangible for them. And you have to help them see that governance affects everyone, and everyone can have a hand in co-creating it through shared standards.

+ +

I think there's a lot to be learned from the open-source community in this regard. The open-source community, more than any other I can think of, is the model of self-governance. It does not mean that it's perfect. But it does mean that people from all roles, backgrounds have a shared mission to build something from nothing and to make it an initiative that other people will benefit from. And I think that attitude is really well-positioned for success with data governance.

+ +

VICTORIA: I love that. And great points all around on how data governance can really impact an organization. Are there any final takeaways for our listeners?

+ +

LAUREN: The biggest takeaway I would say is to be thoughtful about how you roll out data governance in your organization. But don't be scared if your organization is small. Again, it's very common for people to think my business is too small to really implement governance. We don't have the budget for, you know, the AWS environment we might need. Or we don't have the right number of people to serve as stewards. We don't actually have many data domains yet because we're so new.

+ +

And I would say start with what you have. If you are a business in today's day and age, I guarantee that you have enough data in your possession to start building out a data governance program that is thoughtful and mission-oriented. And I would really encourage everyone to do that, regardless of how big your organization is.

+ +

And then the other takeaway I would say is, if you remember nothing else about data governance, I would say to remember that you automate your standards. Your standards for data quality, data destruction, data usage are not divorced from your technical team's production environments; it's the exact opposite. Your standards should govern your environment, and they should be a lighthouse when you are doing that work. And so you always want to try to integrate your standards into your production environment, into your ETL pipelines, into your DevSecOps. That is where the magic happens. Keeping them siloed won't work.

+ +

And so I'd love for people, if you really enjoyed this episode and the conversation resonated with you, too, get a copy of the book. It is my first book. And I was really excited to work with the Pragmatic Programmers on it. So if readers go to pragprog.com, they can get a copy of the book directly through the publisher. But the book is also available at Target, Barnes & Noble, Amazon, and local bookstores. So I am very grateful as a first-time author for any and all support. And I would really also love to hear from thoughtbot clients and podcast listeners what you thought of the book because version two is not out of the question.

+ +

VICTORIA: Well, looking forward to it. Thank you again so much, Lauren, for joining us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Lauren Maffeo.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lauren Maffeo is the author of Designing Data Governance from the Ground Up.

+ +

Victoria talks to Lauren about human-centered design work, data stewardship and governance, and writing a book anybody can use regardless of industry or team size.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Lauren Maffeo, Author of Designing Data Governance from the Ground Up. Lauren, thank you for joining us.

+ +

LAUREN: Thanks so much for having me, Victoria. I'm excited to be here.

+ +

VICTORIA: Wonderful. I'm excited to dive right into this topic. But first, maybe just tell me what led you to start writing this book?

+ +

LAUREN: I was first inspired to write this book by my clients, actually. I was working as a service designer at Steampunk, which is a human-centered design firm serving the federal government. I still do work for Steampunk. And a few years ago, I was working with a client who had a very large database containing millions of unique data points going back several centuries.

+ +

And I realized throughout the course of my discovery process, which is a big part of human-centered design work, that most of their processes for managing the data in this database were purely manual. There was no DevSecOps integrated into their workflows. These workflows often included several people and took up to a week to complete. And this was an organization that had many data points, as mentioned, in its purview.

+ +

They also had a large team to manage the data in various ways. But they still really struggled with an overall lack of processes. And really, more importantly, they lacked quality standards for data, which they could then automate throughout their production processes. I realized that even when organizations exist to have data in their purview and to share it with their users, that doesn't necessarily mean that they actually have governance principles that they abide by.

+ +

And so that led me to really consider, more broadly, the bigger challenges that we see with technology like AI, machine learning, large language models. We know now that there is a big risk of bias within these technologies themselves due to the data. And when I dug deeper, first as a research analyst at Gartner and then as a service designer at Steampunk, I realized that the big challenge that makes this a reality is lack of governance.

+ +

It's not having the quality standards for deciding how data is fit for use. It's not categorizing your data according to the top domains in your organization that produce data. It's lack of clear ownership regarding who owns which data sets and who is able to make decisions about data. It's not having things like a data destruction policy, which shows people how long you hold on to data for. So that knowledge and seeing firsthand how many organizations struggle with that lack of governance that's what inspired me to write the book itself.

+ +

And I wanted to write it from the lens of a service designer. I have my own bias towards that, given that I am a practicing service designer. But I do believe that data governance when approached through a design thinking lens, can yield stronger results than if it is that top-down IT approach that many organizations use today unsuccessfully.

+ +

VICTORIA: So let me play that back a little bit. So, in your experience, organizations that struggle to make the most out of their data have an issue with defining the authority and who has that authority to make decisions, and you refer to that as governance. So that when it comes down to it, if you're building things and you want to say, is this ethical? Is this right? Is this secure? Is it private enough? Someone needs to be responsible [laughs] for answering that. And I love that you're bringing this human-centered design approach into it.

+ +

LAUREN: Yeah, that's exactly right. And I would say that ownership is a big part of data governance. It is one of the most crucial parts. I have a chapter in my book on data stewards, what they are, the roles they play, and how to select them and get them on board with your data governance vision. The main thing I want to emphasize about data stewardship is that it is not just the technical members of your team. Data scientists, data architects, and engineers can all be exceptional data stewards, especially because they work with the data day in and day out.

+ +

The challenge I see is that these people typically are not very close to the data, and so they don't have that context for what different data points mean. They might not know offhand what the definitions per data piece are. They might not know the format that the data originates in. That's information that people in non-technical roles tend to possess.

+ +

And so, data stewardship and governance is not about turning your sales director into a data engineer or having them build ETL pipelines. But it is about having the people who know that data best be in positions where they're able to make decisions about it, to define it, to decide which pieces of metadata are attached to each piece of data. And then those standards are what get automated throughout the DevSecOps process to make better life cycles that produce better-quality data faster, at speed with fewer resources.

+ +

VICTORIA: So, when we talk about authority, what we really mean is, like, who has enough context to make smart decisions?

+ +

LAUREN: Who has enough context and also enough expertise? I think a big mistake that we as an industry have made with data management is that we have given the responsibility for all data in an organization to one team, sometimes one person. So, typically, what we've done in the past is we've seen all data in an organization managed by IT. They, as a department, make top-down decisions about who has access to which data, what data definitions exist, where the data catalog lives, if it exists in an organization at all.

+ +

And that creates a lot of blockers for people if you always have to go through one team or person to get permission to use data. And then, on top of that, the IT team doesn't have the context that your subject matter experts do about the data in their respective divisions. And so it really is about expanding the idea of who owns data and who is in a position of authority to make decisions about it by collaborating across silos. This is very challenging work to do.

+ +

But I would actually say that for smaller organizations, they might lack the resources in, time, and money, and people to do data governance at scale. But what they can do is start embedding data governance as a core principle into the fabric of their organizations. And ultimately, I think that will power them for success in a way that larger organizations were not able to because there is a lot of technical debt out there when it comes to bad data. And one way to avoid that in the future or to at least mitigate it is to establish data governance standards early on.

+ +

VICTORIA: Talk me through what your approach would be if you were working with an organization who wants to build-in this into the fabric of how they work. What would be your first steps in engaging with them and identifying where they have needs in part of that discovery process?

+ +

LAUREN: In human-centered design, the discovery process occurs very early in a project. This is where you are working hand in hand with your client to figure out what their core needs are and how you can help them solve those core needs. And this is important to do because it's not always obvious what those needs are.

+ +

You might get a contract to work on something very specific, whether it's designing the user interface of a database or it's migrating a website. Those are technical challenges to solve. And those are typically the reason why you get contracted to work with your client. But you still have to do quite a bit of work to figure out what the real ask is there and what is causing the need for them to have hired you in the first place.

+ +

And so, the first thing I would do if I was walking a client through this is I would start by asking who the most technical senior lead in the organization is. And I would ask how they are managing data today. I think it's really important, to be honest about the state of data in your organization today.

+ +

The work that we do designing data governance is very forward-thinking in a lot of ways, but you need a foundation to build upon. And I think people need to be honest about the state of that foundation in their organization. So the first thing I would do is find that most-senior data leader who is responsible for making decisions about data and owns the data strategy because that person is tasked with figuring out how to use data in a way that is going to benefit the business writ large. And so, data governance is a big part of what they are tasked to do.

+ +

And so, in the first instance, what I would do is I would host a workshop with the client where I would ask them to do a few things. They would start by answering two questions: What is my company's mission statement, and how do we use data to fulfill that mission statement? These are very baseline questions. And the first one is so obvious and simple that it might be a little bit off-putting because you're tempted to think, as a senior leader, I already know what my company does. Why do I need to answer it like this?

+ +

And you need to answer it like this because just like we often get contracts to work on particular technical problems, you'd be surprised by how many senior leaders cannot articulate their company's mission statements. They'll talk to you about their jobs, the tools they use to do their jobs, who they work with on a daily basis. But they still aren't ultimately answering the question of how their job, how the technology they use fulfills a bigger organizational need.

+ +

And so, without understanding what that organizational need is, you won't be able to articulate how data fulfills that mission. And if you're not able to explain how data fulfills your company's mission, I doubt you can explain which servers your data lives on, which file format it needs to be converted to, who owns which data sets, where they originate, what your DevSecOps processes are. So answering those two questions about the company mission and how data is used to fulfill that mission is the first step.

+ +

The second thing I would do is ask this senior leader, let's say the chief data officer, to define the data domains within their organization. And when we talk about data domains, we are talking about the areas of the business that are the key areas of interest. This can also be the problem spaces that your organization addresses. It also can have a hand in how your organization is designed as is; in other words, who reports to whom?

+ +

Do you have sales and marketing within one part of the organization, or are they separate? Do you have customer success as its own wing of the organization separate from product? However your organization is architected, you can draw lines between those different teams, departments, and the domains that your organization works in.

+ +

And then, most importantly, you want to be looking at who leads each domain and has oversight over the data in that domain. This is a really important aspect of the work because, as mentioned, stewards play a really key role in upholding and executing data governance. You need data stewards across non-technical and technical roles. So defining not just what the data domains are but who leads each domain in a senior role is really important to mapping out who your data stewards will be and to architect your first data governance council.

+ +

And then, finally, the last thing I would have them do in the first instance is map out a business capability map showing not only what their data domains are but then the sub-domains underneath. So, for example, you have sales, and that can be a business capability. But then, within the sales data domain, you're going to have very different types of sales data. You're going to have quarterly sales, bi-annual sales, inbound leads versus outbound leads. You're going to have very different types of data within that sales data domain. And you want to build those out as much as you possibly can across all of your data domains.

+ +

If you are a small organization, it's common to have about four to six data domains with subdomains underneath, each of those four to six. But it varies according to each startup and organization and how they are structured. Regardless of how your organization is structured, there's always value in doing those three things. So you start by identifying what your organization does and how data fulfills that goal. You define the core data domains in your organization, including who owns each domain.

+ +

And then, you take that information about data domains, and you create a capability map showing not just your core data domains but the subdomains underneath because you're going to use all of that information to architect a future data governance program based on what you currently have today.

+ +

VICTORIA: I think that's a great approach, and it makes a lot of sense. Is that kind of, like, the minimum that people should be doing for a data governance program? Like, what's the essentials to do, like, maybe even your due diligence, say, as a health tech startup company?

+ +

LAUREN: This is the bare minimum of what I think every organization should do. The specifics of that are different depending on industry, depending on company size, organizational structure. But I wrote this book to be a compass that any organization can use. There's a lot of nuance, especially when we get into the production environment an organization has. There's a lot of nuance there depending on tools, all of that.

+ +

And so I wanted to write a book that anybody could use regardless of industry size, team size, all of that information. I would say that those are the essential first steps. And I do think that is part of the discovery process is figuring out where you stand today, and no matter how ugly it might be. Because, like we've mentioned, there is more data produced on a daily basis than ever before. And you are not going into this data governance work with a clean slate. You already have work in your organization that you do to manage data. And you really need to know where there are gaps so that you can address those gaps.

+ +

And so, when we go into the production environment and thinking about what you need to do to be managing data for quality on a regular basis, there are a couple of key things. The first is that you need a plan for how you're going to govern data throughout each lifecycle. So you are very likely not using a piece of data once and never again. You are likely using it through several projects.

+ +

So you always want to have a plan for governance in production that includes policies on data usage, data archiving, and data destruction. Because you want to make sure that you are fulfilling those principles, whatever they are, throughout each lifecycle because you are managing data as a product.

+ +

And that brings me to the next thing that I would encourage people working in data governance to consider, which is taking the data mesh principle of managing data as a product. And this is a fundamental mind shift from how big data has been managed in the past, where it was more of a service. There are many detriments to that, given the volume of data that exists today and given how much data environments have changed.

+ +

So, when we think about data mesh, we're really thinking about four key principles. The first is that you want to manage your data according to specific domains. So you want to be creating a cloud environment that really accounts for the nuance of each data domain. That's why it's so important to define what those data domains are. You're going to not just document what those domains are. You're going to be managing and owning data in a domain-specific way.

+ +

The second thing is managing data as a product. And so, rather than taking the data as a service approach, you have data stewards who manage their respective data as products within the cloud environment. And so then, for instance, rather than using data about customer interactions in a single business context, you can instead use that data in a range of ways across the organization, and other colleagues can use that data as well.

+ +

You also want to have data available as a self-service infrastructure. This is really important in data mesh. Because it emphasizes keeping all data on a centralized platform that manages your storage, streaming, pipelines, and anything else, and this is crucial because it prevents data from leaving in disparate systems on various servers. And it also erases or eases the need to build integrations between those different systems and databases. And it also gives each data steward a way to manage their domain data from the same source.

+ +

And then the last principle for data mesh is ecosystem governance. And really, what we're talking about here is reinforcing the data framework and mission statement that you are using to guide all of your work. It's very common in tech for tech startups to operate according to a bigger vision and according to principles that really establish the rationale for why that startup deserves to exist in the world.

+ +

And likewise, you want to be doing all of your production work with data according to a bigger framework and mission that you've already shared. And you want to make sure that all of your data is formatted, standardized, and discoverable against equal standards that govern the quality of your data.

+ +

VICTORIA: That sounds like data is your biggest value as a company and your greatest source of liability [laughs] and in many ways. And, I'm curious, you mentioned just data as a product, if you can talk more about how that fits into how company owners and founders should be thinking about data and the company they're building.

+ +

LAUREN: So that's a very astute comment about data as a liability. That is absolutely true. And that is one of the reasons why governance is not just nice to have. It's really essential, especially in this day and age. The U.S. has been quite lax when it comes to data privacy and protection standards for U.S. citizens. But I do think that that will change over the next several years. I think U.S. citizens will get more data protections. And that means that organizations are going to have to be more astute about tracking their data and making sure that they are using it in appropriate ways.

+ +

So, when we're talking to founders who want to consider how to govern data as a product, you're thinking about data stewards taking on the role of product managers and using data in ways that benefits not just them and their respective domains but also giving it context and making it available to the wider business in a way that it was not available before.

+ +

So if you are architecting your data mesh environment in the cloud, what you might be able to do is create various domains that exist on their own little microservice environments. And so you have all of these different domains that exist in one environment, but then they all connect to this bigger data mesh catalog. And from the catalog, that is where your colleagues across the business can access the data in your domain.

+ +

Now, you don't want to necessarily give free rein for anybody in your organization to get any data at any time. You might want to establish guardrails for who is able to access which data and what those parameters are. And the data as a product mindset allows you to do that because it gives you, as the data steward/pseudo pm, the autonomy to define how and when your data is used, rather than giving that responsibility to a third-party colleague who does not have that context about the data in your domain.

+ +

VICTORIA: I like that about really giving the people who have the right context the ability to manage their product and their data within their product. That makes a lot of sense to me.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design-driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: What is it like to really bring in this culture of design-thinking into an organization that's built a product around data?

+ +

LAUREN: It can be incredibly hard. I have found that folks really vary in their approach to this type of work. I think many people that I talk to have tried doing data governance to some degree in the past, and, for various reasons, it was not successful. So as a result, they're very hesitant to try again. I think also for many technical leaders, if they're in CIO, CDO, CTO roles, they are not used to design thinking or to doing human-centered design work.

+ +

That's not the ethos that was part of the tech space for a very long time. It was all about the technology, building what you could, experimenting and tinkering, and then figuring out the user part later. And so this is a real fundamental mindset shift to insist on having a vision for how data benefits your business before you start investing money and people into building different data pipelines and resources.

+ +

It's also a fundamental shift for everyone in an organization because we, in society writ large, are taught to believe that data is the responsibility of one person or one team. And we just can't afford to think like that anymore. There is too much data produced and ingested on a daily basis for it to fall to one person or one team.

+ +

And even if you do have a technical team who is most adept at managing the cloud environment, the data architecture, building the new models for things like fraud detection, that's all the purview of maybe one team that is more technical. But that does not mean that the rest of the organization doesn't have a part to play in defining the standards for data that govern everything about the technical environment.

+ +

And I think a big comparison we can make is to security. Many of us… most of us, even if we work in tech, are not cybersecurity experts. But we also know that employees are the number one cause of breaches at organizations. There's no malintent behind that, but people are most likely to expose company data and cause a breach from within the company itself. And so organizations know that they are responsible for creating not just secure technical environments but educating their employees and their workforce on how to be stewards of security.

+ +

And so, even at my company, we run constant tests to see who is going to be vulnerable to phishing? Who is going to click on malicious links? They run quarterly tests to assess how healthy we are from a cybersecurity perspective. And if you click on a phishing attempt and you fall for it, you are directed to a self-service education video that you have to complete, going over the aspects of this phishing test, what made it malicious.

+ +

And then you're taught to educate yourself on what to look for in the future. We really need to be doing something very similar with data. And it doesn't mean that you host a two-hour training and then never talk about data again. You really need to look at ways to weave data governance into the fabric of your organization so that it is not disruptive to anybody's day. It's a natural part of their day, and it is part of working at your organization. Part of your organizational goals include having people serve as data stewards. And you emphasize that stewardship is for everyone, not just the people in the technology side of the business.

+ +

VICTORIA: I love that. And I think there's something to be said for having more people involved in the data process and how that will impact just the quality of your data and the inclusivity of what you're building to bring those perspectives together.

+ +

LAUREN: I agree. And that's the real goal. And I think this is, again, something that's actually easier for startups to do because startups are naturally more nimble. They find out what works, what doesn't work. They're willing to try things. They have to be willing to try things. Because, to use a really clichéd phrase, if they're not innovating, then they're going to get stale and go out of business.

+ +

But the other benefit that I think startups have when they're doing this work is the small size. Yes, you don't have the budget or team size of a company like JP Morgan, that is enormous, or a big bank. But you still have an opportunity to really design a culture, an organizational culture that puts data first, regardless of role. And then you can architect the structure of every role according to that vision.

+ +

And I think that's a really exciting opportunity for companies, especially if they are selling data or already giving data as a product in some way. If they're selling, you know, data as a product services, this is a really great approach and a unique approach to solving data governance and making it everyone's opportunity to grow their own roles and work smarter.

+ +

VICTORIA: Right. And when it's really the core of your business, it makes sense to pay more attention to that area [laughs]. It's what makes it worthwhile. It's what makes potential investors know that you're a real company who takes things seriously. [laughs]

+ +

LAUREN: That's true. That's very true.

+ +

VICTORIA: I'm thinking, what questions...do you have any questions for me?

+ +

LAUREN: I'm curious to know, when you talk to thoughtbot clients, what are the main aspects of data that they struggle with? I hear a variety of reasons for data struggles when I talk to clients, when I talk to people on the tech side, either as engineers or architects. I'm curious to hear what the thoughtbot community struggles with the most when it comes to managing big data.

+ +

VICTORIA: I think, in my experience, in the last less than a year that I've been with thoughtbot, one challenge which is sort of related to data...but I think for many small companies or startups they don't really have an IT department per se. So, like, what you mentioned early on in the discovery process as, like, who is the most senior technical person on your team? And that person may have little to no experience managing an IT operations group.

+ +

I think it's really bringing consulting from the ground up for an organization on IT operations, data management, user and access management. Those types of policies might just be something they hadn't considered before because it's not in their background and experience. But maybe once they've gotten set up, I think the other interesting part that happens is sometimes there's just data that's just not being managed at all. And there are processes and bits and pieces of code in app that no one really knows what they are, who they're used for, [laughs] where the data goes. And then, you know, the connections between data.

+ +

So everything that you're mentioning that could happen when you don't do data governance, where it can slow down deployment processes. It can mean that you're giving access to people who maybe shouldn't have access to production data. It can mean that you have vulnerabilities in your infrastructure. That means someone could have compromised your data already, and you just don't know about it. Just some of the issues that we see related to data across the spectrum of people in their lifecycle of their startups.

+ +

LAUREN: That makes total sense, I think, especially when you are in a startup. If you're going by the typical startup model, you have that business-minded founder, and then you likely have a more technical co-founder. But we, I think, make the assumption that if you are, quote, unquote, "technical," you, therefore, know how to do anything and everything about every system, every framework, every type of cloud environment. And we all know that that's just not the case.

+ +

And so it's easy to try to find the Chief Technology Officer or the Chief Information Officer if one exists and to think, oh, this is the right person for the job. And they might be the most qualified person given the context, but that still doesn't mean that they have experience doing this work. The reality is that very few people today have deep hands-on experience making decisions about data with the volume that we see today. And so it's a new frontier for many people.

+ +

And then, on top of that, like you said as well, it's really difficult to know where your data lives and to track it. And the amount of work that goes into answering those very basic questions is enormous. And that's why documentation is so important. That's why data lineage in your architecture is so important. It really gives you a snapshot of which data lives where, how it's used. And that is invaluable in terms of reducing technical debt.

+ +

VICTORIA: I agree. And I wonder if you have any tips for people facilitating conversations in their organization about data governance. What would you tell them to make it less scary and more fun, more appealing to work on?

+ +

LAUREN: I both love and hate the term data governance. Because it's a word that you say, and whether you are technical or not, many people tune out as soon as they hear it because it is, in a way, a scary word. It makes people think purely of compliance, of being told what they can't do. And that can be a real challenge for folks.

+ +

So I would say that if you are tasked with making a data governance program across your organization, you have to invest in making it real for people. You have to sell them on stewardship by articulating what folks will gain from serving as stewards. I think that's really critical because we are going to be asking folks to join a cause that they're not going to understand why it affects them or why it benefits them at first. And so it's really your job to articulate not only the benefits to them of helping to set up this data stewardship work but also articulating how data governance will help them get better at their jobs.

+ +

I also think you have to create a culture where you are not only encouraging people to work across party lines, so to speak, to work across silos but to reward them for doing so. You are, especially in the early months, asking a lot of people who join your data stewardship initiatives and your data governance council you're asking them to build something from the ground up, and that's not easy work.

+ +

So I think any opportunity you can come up with to reward stewards in the form of bonuses or in terms of giving them more leeway to do their jobs more of a title bump than they might have had otherwise. Giving them formal recognition for their contributions to data governance is really essential as well. Because then they see that they are rewarded for contributing to the thought leadership that helps the data governance move forward.

+ +

VICTORIA: I'm curious, what is your favorite way to be rewarded at work, Lauren?

+ +

LAUREN: So I am a words person. When we talk about love languages, one of them is words of affirmation. And I would say that is the best way to quote, unquote, "reward me." I save emails and screenshots of text messages and emails that have really meant a lot to me. If someone sends me a handwritten card that really strikes a chord, I will save that card for years. My refrigerator is filled with holiday cards and birthday cards, even from years past.

+ +

And so any way to recognize people for the job they're doing and to let someone know that they're seen, and their work is seen and valued really resonates with me. I think this is especially important in remote environments because I love working from home, and I am at home alone all day. And so, especially if you are the only person of your kind, of your role on your team, it's very easy to feel insular and to wonder if you're hitting the mark, if you're doing a good job. I think recognition, whether verbally or on Slack, of a job well done it really resonates with me. And that's a great way to feel rewarded.

+ +

VICTORIA: I love that. And being fully remote with thoughtbot, I can feel that as well. We have a big culture of recognizing people. At least weekly, we do 15Five as a tool to kind of give people high-fives across the company.

+ +

LAUREN: Yep, Steampunk does...we use Lattice. And people can submit praise and recognition for their colleagues in Lattice. And it's hooked up to Slack. And so then, when someone submits positive feedback or a kudos to a colleague in Lattice, then everyone sees it in Slack. And I think that's a great way to boost morale and give people a little visibility that they might not have gotten otherwise, especially because we also do consulting work.

+ +

So we are knee-deep in our projects on a daily basis, and we don't always see or know what our colleagues are working on. So little things like that go a long way towards making people feel recognized and valued as part of a bigger company. But I'm also curious, Victoria, what's your favorite way to get rewarded and recognized at work?

+ +

VICTORIA: I think I also like the verbal. I feel like I like giving high-fives more than I like receiving them. But sometimes also, like, working at thoughtbot, there are just so many amazing people who help me all throughout the day. I start writing them, and then I'm like, well, I have to also thank this person, and then this person. And then I just get overwhelmed. [laughs] So I'm trying to do more often so I don't have a backlog of them throughout the week and then get overwhelmed on Friday.

+ +

LAUREN: I think that's a great way to do it, and I think it's especially important when you're in a leadership role. Something that I'm realizing more and more as I progress in my career is that the more senior you are, the more your morale and attitude sets the tone for the rest of the team. And that's why I think if you are in a position to lead data governance, your approach to it is so crucial to success. Because you really have to get people on board with something that they might not understand at first, that they might resent it first.

+ +

This is work that seems simple on the surface, but it's actually very difficult. The technology is easy. The people are what's hard. And you really have to come in, I think, emphasizing to your data stewards and your broader organization, not just what governance is, because, frankly, a lot of people don't care. But you really have to make it tangible for them. And you have to help them see that governance affects everyone, and everyone can have a hand in co-creating it through shared standards.

+ +

I think there's a lot to be learned from the open-source community in this regard. The open-source community, more than any other I can think of, is the model of self-governance. It does not mean that it's perfect. But it does mean that people from all roles, backgrounds have a shared mission to build something from nothing and to make it an initiative that other people will benefit from. And I think that attitude is really well-positioned for success with data governance.

+ +

VICTORIA: I love that. And great points all around on how data governance can really impact an organization. Are there any final takeaways for our listeners?

+ +

LAUREN: The biggest takeaway I would say is to be thoughtful about how you roll out data governance in your organization. But don't be scared if your organization is small. Again, it's very common for people to think my business is too small to really implement governance. We don't have the budget for, you know, the AWS environment we might need. Or we don't have the right number of people to serve as stewards. We don't actually have many data domains yet because we're so new.

+ +

And I would say start with what you have. If you are a business in today's day and age, I guarantee that you have enough data in your possession to start building out a data governance program that is thoughtful and mission-oriented. And I would really encourage everyone to do that, regardless of how big your organization is.

+ +

And then the other takeaway I would say is, if you remember nothing else about data governance, I would say to remember that you automate your standards. Your standards for data quality, data destruction, data usage are not divorced from your technical team's production environments; it's the exact opposite. Your standards should govern your environment, and they should be a lighthouse when you are doing that work. And so you always want to try to integrate your standards into your production environment, into your ETL pipelines, into your DevSecOps. That is where the magic happens. Keeping them siloed won't work.

+ +

And so I'd love for people, if you really enjoyed this episode and the conversation resonated with you, too, get a copy of the book. It is my first book. And I was really excited to work with the Pragmatic Programmers on it. So if readers go to pragprog.com, they can get a copy of the book directly through the publisher. But the book is also available at Target, Barnes & Noble, Amazon, and local bookstores. So I am very grateful as a first-time author for any and all support. And I would really also love to hear from thoughtbot clients and podcast listeners what you thought of the book because version two is not out of the question.

+ +

VICTORIA: Well, looking forward to it. Thank you again so much, Lauren, for joining us today.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Lauren Maffeo.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+3r18piyl + + ]]> + + Victoria Guido + Lauren Maffeo + + + 474: Freelance Producer, Podcaster, Actor, Motion Capture & Performance Capture Performer Jasper (William) Cartwright + https://podcast.thoughtbot.com/474 + 422d2aca-f04d-4375-a5ab-18d3669198b0 + Thu, 11 May 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Jasper (William) Cartwright is a Freelance Producer, Podcaster, Actor, and Motion Capture & Performance Capture Performer. + +Chad talks to Jasper about his podcast Three Black Halflings, which is committed to discussing diversity and inclusion within fantasy, sci-fi, and nerdy culture from the perspective of three people of color, what it's like to be in the space, and why representation is super important. + 43:42 + no + + + Jasper (William) Cartwright is a Freelance Producer, Podcaster, Actor, and Motion Capture & Performance Capture Performer. +Chad talks to Jasper about his podcast Three Black Halflings, which is committed to discussing diversity and inclusion within fantasy, sci-fi, and nerdy culture from the perspective of three people of color, what it's like to be in the space, and why representation is super important. +Follow Jasper (William) Cartwright on LinkedIn (https://www.linkedin.com/in/jasper-cartwright-217b72113/) or Twitter (https://twitter.com/JW_Cartwright). Check out his website at jasperwcartwright.com (https://www.jasperwcartwright.com/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. +We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. +Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. +JORDYN: Thanks for having us. +DAWN: Yeah, glad to be here. +VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? +JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. +VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. +JORDYN: Wonderful. +VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? +JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. +VICTORIA: What made you decide to start this incubator program this year with thoughtbot? +DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. +And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. +It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. +VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? +DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? +It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. +VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. +JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. +You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. +He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. +You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? +VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? +DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. +So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. +VICTORIA: Wonderful. That's amazing. Thank you both so much. +INTRO MUSIC: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jasper William-Cartwright, Game Master for hire, Actor, Creative Consultant, Podcaster, Co-Host of The Performance Capture Podcast, and Co-Host of one of my favorite podcasts, Three Black Halflings. Jasper, thank you so much for joining me. +JASPER: Hey, no, thank you so much for having me. And, man, with that intro, I almost feel... +CHAD: [laughs] +JASPER: I almost felt...I was like, oh, I feel cool. Those are some fun things. [laughs] +CHAD: I almost started with a Heeello robots. +JASPER: [laughs] +CHAD: But it doesn't really have the alliteration that hello Halflings does, so... +JASPER: Sure. I don't even know how the hello Halfling started. Like, I'm going to have to go back and listen to some of the earlier episodes again because I genuinely have no idea how it happened. And now it's gotten to a point where it's unyieldy. Every episode, I feel like I have to get a little bit further and a little bit higher. And I'm like, this can't be good for people's ears, so, [laughs] yeah. +CHAD: So I know what the show is, but in your own words, what is the Three Black Halflings Podcast? +JASPER: The Three Black Halflings Podcast is a show which is committed to talking about diversity and inclusion within fantasy and sci-fi, and sort of anything that nerdy culture touches, we try to cover it from the perspective of three people of color, what it's like to be in the space, and why representation is super important. +CHAD: I want to talk about the origin of the show and how you got started. But I was introducing someone to the show previously because I try to tell everybody I can about the show. [laughter] I've noticed in the beginning when you started, there was a lot of low-hanging fruit, like, we can dive into this stuff and educate people. And over time, you've introduced actual play where you're playing Dungeons & Dragons on the show. And I think it's changed a little bit, and it's still great. +But I always also recommend people go back to the beginning. And I think a lot of the episodes are sort of timeless. They're not about the news of the day. They're diving into particular topics and discussing either the impact or the problems that they have or how to play them better. +JASPER: Yeah, definitely. I think you're absolutely right. It's been a weird thing where because we've become more popular and we're kind of more in tune with the TTRPG space; I think that typically what has happened for us is that we've spent less time really digging around for, you know, what's some stuff... all the things that we can explore. And we're a lot more kind of like, what's the beat of the moment? If that makes sense. And I think that's why we haven't done as many episodes like that. +And also, just because we...I just think that the audience is changing. And the way that people consume our content is changing. It tends to go in cycles for us where we'll do a batch of very topical episodes then we'll do more really nitty gritty kind of game design episodes. And so I think a lot of it does depend on the sort of moment, what's going on. There are still a bunch of episodes that we have planned. And obviously, we have the Halfling University series which is coming out currently, which is a more retrospective look back on poignant things throughout the history of nerd [inaudible 3:11] and nerd culture. So I like to think there's a good variety on there. +CHAD: Obviously the show, especially I think when it started, had a very heavy focus on Dungeons & Dragons, which I love. People who know me [laughs] know that I love Dungeons & Dragons. +JASPER: [laughs] +CHAD: And I've been playing it for a long time. And as someone playing it since I was a teenager, I didn't realize until I got older and learned a lot more...and certainly, the show went a long way to sort of educating me about how not only the origins of some of the tropes of fantasy and Dungeons & Dragons but just in general how to have inclusive play. +When you're playing with a group of people, and to bring it back to a non-Dungeons & Dragons specific thing, this is true, I think, in any group of people. When you're surrounded by a group of people who look the same as you, are from the same area, have the same experiences, you don't realize what's missing from that table, and that's true in our companies, and it's true around a TTRPG table too. +JASPER: Yeah, I completely agree. And I think that's the same for a lot of us. I remember doing a big post after I'd been doing the show for about six months, and it was just like, I was very open when I started the show that a lot of what I wanted to talk about I wanted it to be a safe space for me to explore some of these things. +Because I grew up in a very White middle-class area, and therefore I had a lot of the blind spots that I would see my friends of color call out my White friends for or whatever it may be. And so I was like, okay, it's time for me to educate myself. And I wanted to do it in a safe space, in a place where I could learn from great people. Obviously, we had other co-hosts of the show who are fantastic people, but we had things like sensitivity consultants and people like that come on. +I always like to shout out James Mendez Hodes, who, if you ever want to do a bit of a deep dive into fantasy...and you said, Chad, the historical basis for some of the stuff that we use, and he wrote some really incredible stuff. And so a lot of it was about me trying to educate myself as well and kind of put in that work. I thought there was a value there in doing it in an open forum in sort of saying, hey, I'm a person of color, and I'm also trying to figure this out, you know what I mean? +CHAD: Mm-hmm. +JASPER: Because I think that a lot of the time, the barrier for anyone who doesn't belong to a minority group is like, oh, man, I don't want to burden someone else with my own understanding of this thing, and I don't want to ask the wrong questions. Or maybe I don't even know where to begin in educating myself. And so there was something about the three of us and me particularly kind of being very open about the fact that we were learning about this too and that there might be things that...mistakes or things might slightly be out of place but that we have that openness and willingness to learn. +And I think that in today's internet culture where everyone is so kind of reaction-based, it just felt important to me that we had a space where we could sit in and talk about stuff and really be open with each other in a way that we knew we'd all be able to shake hands and be like, cool, that was a good session or whatever [laughs] it was today, and not be like, I hate you, you know what I mean? Because someone had made a mistake, or misspoke, or something like that. +And I think you're absolutely right. It's something I've started to do a bit more of recently, which is doing diversity and inclusion talks and coaching for companies because I think a lot of the lessons that I've learned through doing this show, especially around things like language and how you set up a work environment to suit people of color and more generally, minorities, it's a slightly continuous pursuit in the sense that you always have to be kind of open and learning. +And I think also it provides a...what I think is best about it is that it provides such richness to your work environment. We always say on Three Black Halflings that we want you to take these things and use them to enhance your game. Like you're saying, if you have the same people with the same experiences all the time and that's all you ever hear, then, of course, you're going to get a pretty one-sided experience. And then, if you expand that out to include people from halfway across the world who have a very different experience, they're going to see things differently. +And I can almost guarantee there'll be a problem that you and your team have been stuck on for like months, and someone from a different perspective will come in and be like, boom, there's the problem, or that's how we get around it because they have a different frame of reference to you. And so I always try to...it sounds really awful to say sell it, [laughs] you know, not trying to sell diversity and inclusion, but I always want to try and go further by saying it's not just about getting different faces in the door. It's about enriching the work that you do and allowing your team to do the best work that they can. +Just the quantity of difference between the kinds of things like games that I used to run, you know, to link it back to Dungeons & Dragons, versus the games that I run now, just having had this wealth of influence from other people and different experiences is incredible. And I think it holds true for every element of my work. So I work as a producer a lot in lots of creative fields as opposed to just podcasting. And it's improved tenfold just by having a diverse group of people that I draw from their experiences in my pursuits. So I think it makes a big difference. +CHAD: I think it's the idea that you wanted a safe space, and so you created a public podcast on the internet. +[laughter] +JASPER: Yeah, I can see how that sounds now. +[laughter] +CHAD: I assume that you've had to navigate being in public spaces talking about diversity, inclusion. I'm sure that that has been difficult at times. +JASPER: Yeah, for sure. I think just to clarify that as well, [laughs] because I am definitely aware of how it sounds, I've always been a very, like, I don't care attitude, you know what I mean? +CHAD: Yeah. +JASPER: In the sense that I felt like I needed what I was going to make, if that makes sense. What, I guess, I meant by a safe space is I wanted people to have the safe space of listening to it. I was getting the safe space as far as I was concerned because podcasts aren't a reactionary medium, which is lovely. So thank God your audience isn't sat here just saying everything that you said wrong and correcting you. People are probably shouting at me for stuff that I've said already on this episode. [chuckles] +So it's definitely a fine line, like you said, to put something out on the internet. It's a very, very public thing to do. But it definitely just felt like, for me, creating somewhere where people could just disappear a little bit and encounter these things in a way where they're not going to be called out, or they're not going to be kind of threatened. There's no risk of cancellation or whatever if you say the wrong thing or whatever it is. It felt important. +And yeah, we've had to deal with...I will say this; it's kind of tricky to sum up the things that we've dealt with because I think a lot of stuff is still so systemic in the sense that just even down to the opportunities that you get and things like that where you kind of go like, huh, they started in this space like two months ago, and they have twice the followers we do. And they're getting loads of money for doing these streams. [laughs] And you're going to go, like, hold on, what's going on here? +CHAD: Yeah, there are three people on this show. They have ten times the Patreons that we do. +[laughter] +JASPER: Yeah, exactly. +CHAD: Why might that be? +[laughter] +JASPER: Yeah, exactly. Exactly that. And that's one side of it. And then, to be honest, the most it's happened...and this is quite a recent thing, which I don't even think we've really spoken about on the show was the reaction to the...so for anyone who doesn't know Dungeons & Dragons, there was a recent controversy where Hasbro and Wizards of the Coast threatened to repeal part of the license, which allowed creators to freely kind of use elements, not all of them, but some elements of the Dungeons & Dragons game and the Dungeons & Dragons IP for content basically. +And they wanted to repeal it, and they wanted to start bringing in more checks and balances in terms of what you could and couldn't do. And they wanted to start taking cuts of the profits and all this kind of thing. And anyway, the reaction was, as you can probably imagine, not great. Us content creators are ostensibly the lifeblood of this game, especially in terms of its online presence. +So we ended up getting the opportunity to interview one of the executive producers at Wizards of the Coast, and we put it on our YouTube. And it's hilariously one of the most viewed pieces of content that the Three Black Halflings has, full stop. And the reaction is so strange because you have people that get super angry at this guy for being corporate, and this and that, and the other. And we were like, okay, that's fine. So that was the first wave of reaction. +Then it was like, he's a racist against White people. And we were like, whoa, okay. And then it turned into you're racist because you didn't call him out for being racist against White people. And then, eventually, I think it just found its way to the trolls who are now just being openly racist about it. +So it's a very strange dynamic of seeing that play out in terms of it literally depending on the amount of people that listened to it, do you know what I mean? It didn't hit troll numbers yet, like; it needed to be more popular to hit troll numbers. So part of me does wonder if we just haven't quite got to peak troll numbers [laughter] with the main podcast. I'm sort of readying myself with a spear and a shield, so I'm like, okay, trolls are coming. +CHAD: It's like a double-edged sword. You want to be more popular but at the same time, hmm. Part of what I'm getting at is I think the work you do, even if you take sort of systemic racism out of it, the reaction to diversity and inclusion topics out of it, it's not easy to be an independent content creator, then you add that on to it. So how do you keep going? You've been doing it for three years now. What's your day-to-day like? How do you keep going at it? +JASPER: I mean, the rewards are just huge. I got to go to the Dungeons & Dragons premiere the other day. I went to a party in the Tower of London and had people coming up to me. Everyone knew who I was at the Tower of London at a party in the Tower of London. And when I say Tower of London, I want to clarify that it wasn't a function room attached to the Tower of London. +CHAD: [laughs] +JASPER: We were in the Tower of London. I was having champagne, sipping it next to Henry VIII's armor. +CHAD: [laughs] Amazing. +JASPER: It was absolutely wild and being there and people coming up to me and being like, "We love what Three Black Halflings does. We think it's a really important voice in the community. And you guys absolutely like..." you know, because I was sort of like, oh God, I can't believe we're here or whatever. And people would be like, "No, no, you absolutely deserve to be here. It's so important that you guys are here." So I think that has a huge impact. +People in the community, the way that we've been embraced there's so many shows and so many people who are creating content that are working so hard who don't have nearly the platform that we have. And I think that is, A, a testament to us and the hard work that we put in. But it's also a testament to just how important what we're doing within the community is. +And I still don't really think there is a facsimile for Three Black Halflings in the industry in the sense that we're a talk show. We talk about heavy topics a lot of the time, but we do it with a smile on our face. And we try to laugh as much as humanly possible, you know what I mean? Because the whole premise of this show was that Black joy can be a form of protest. So we wanted to be like, hey, we can talk about serious stuff without having to cry and feel crushingly horrible about it, you know. [laughs] +And I think I guess that's how I feel whenever I feel like I want to cry or feel crushingly horrible about my workload or how hard it is to make the show is that I go, this is kind of the point, you know what I mean? This is why we got into it because I think that this is going to make it easier for someone else to do the same thing or someone else do something even better, and that, for me, is incredibly rewarding. +But I will caveat all of that by saying we've started to generate some money through ad revenue and Patreon, everything like that. And it's actually...this show has given me the opportunity to leave my full-time day job, which was still kind of creative. I was working in animation before this. And I loved that job, but now I get to be my own boss. +And it's been a really steep learning curve learning how to do work-life balance when you're your own boss because you're like, I could really disrespect my time here, you know what I mean? [laughter] I can get a lot done today. And I go, no, I have to spend time with my fiancée. I have to eat food. I have to sleep. I have to drink water. I think a lot of the process has been about that. +And I think, especially recently, I've gotten much better at kind of giving myself that work-life balance, and that makes it a lot easier for me to carry on. Because I feel like we've gotten to a point where I can be honest with the community as well and say, "Hey, we're having a late episode this week because there are some kinks with the edit," or something. [laughs] And people are just like, "Yeah, it's fine." +So I was actually having a consultancy session for someone yesterday. And one of the big things I kept saying to them was, as a content creator, you have to realize the world is not going to crash and burn if you don't hold the standards that you've set for yourself. Because the chances are your audience has much, much lower expectations, and that's not because they don't think you can do it. It's just because they understand that you're human, and they want you to do well, you know what I mean? +So if ever I feel like, oh no, Three Black Halflings has really messed up, I'm like, this episode sounds terrible. And we put it out and, ugh, and I'm there twisting myself into knots and making myself feel horrible. And then I go to the Discord, and everyone's like, "Oh, that sounded a bit janky. Oh, well, I'm sure they'll sort it out." [laughs] It's just like, it's absolutely fine. +So taking pressure off of yourself, I think, is something that I think is really important if you're trying to pursue, especially if you're trying to start out in pursuit of something like this because, yeah, it's super easy to drown yourself [laughs] in all of the kind of stress and anxiety about putting content out. +CHAD: You mentioned ads, and you mentioned Patreon. I think it was...was it last year that you joined a podcast network? +JASPER: Ooh, it would have been a year before. +CHAD: A year. +JASPER: So I've been with Headgum, I think, for nearly two years now. +CHAD: Wow. What sort of prompted that, and what does being part of a network give you as a podcast? +JASPER: Hell yeah. Joining a network ostensibly is just like joining a kind of family of other shows. I guess the closest equivalent really is sort of having your show picked up by Netflix or a broadcaster or something like that. It's sort of like you're bringing your show to that family. And then the most common thing...every network is obviously slightly different and will have different kinds of support structures that they offer certain shows depending on the money they generate, all that kind of thing. +But the most common one is effectively; you are now in a group that can all support each other and can all benefit each other by doing ad swaps because ad swaps typically is the absolute best way to improve podcast performance, mostly just because the user journey is super simple. It's like, hey, do you like the sound of this podcast? Well, the link to it is in your description. You have to click twice. You have to go into the description, click on that link, and then hit subscribe, and you're done. That's all you have to do, and it will be there. And you know it'll automatically tee up in your feed and all that kind of stuff. +So things like pod swaps and everything like that are by far the most effective for spreading the word about your show. And it also just helps you really hit specific target audiences where you go; we have great metrics that we can see of like, the average age of our listeners, how they identify gender-wise, music they listen to typically, what the average Three Black Halflings listens to. I think when you roll all of that information together as a part of a network, you have a huge bank of data, which they can then use to kind of market you in the best way and push you out in the best way. +And then, on top of that, most networks will have some sort of ad revenue like sort of system or tech, I guess, is probably the best way of putting it. And certainly, for some networks, they almost run like tech companies, how I imagine tech companies run. You're probably about to tell me, "A lot better." [laughs] +CHAD: Don't worry about it. [laughs]. +JASPER: But, for instance, Headgum has Gumball. So Gumball is their ad sales sort of site, which has software which allows you to basically...everyone can go, and you can book ads just by looking at the podcast, seeing how many downloads it has; again, it has a breakdown of demographics and things like that that you can look at to see if that will marry up with whatever product you're pushing out. And then that will automatically set up a prompt for me to then read the script, upload it, and then that will put a dynamic ad in the middle of an episode, however many episodes until a certain amount of impressions are delivered. +So, again, that will be very unique and different depending on which network you join. But ostensibly, I'd say those are the two main things is pooling of resources amongst a family of different podcasts and then some sort of promise of ad revenue or ad sales. Most of them also have an ad sales team where they'll go and hunt out more specific spots for your show. +So, for instance, we just got sponsored by, I think it was Penguin or maybe Random House. Actually, maybe it's Random House who are publishing three little additional books to go in and around the Dungeons & Dragons movie. So we just did a little ad for them. And that was, again, the sales team kind of going out and being like, oh, we can see that you're looking for advertising places. Why don't you come and advertise on this Dungeons & Dragons podcast? [laughs] So yeah, stuff like that, I think. +Those were, I'd say, the main areas, and then it'll kind of depend...some podcast networks will help with editing. They'll have almost like a house style. So they'll sort of...they'll say, oh, we'll do the editing for you because we want to marry up all the shows so that they have a similar sound +CHAD: Is Headgum doing some editing for you and not on other episodes, or…? +JASPER: No. Headgum pretty much does...one of the best things [laughs] about it is we have an incredible sound designer; shout out to Daniel. He's actually one of the sound designers of God of War, if you can believe that. +CHAD: [laughs] +JASPER: He's won several awards for sound design. He basically has almost like a little side hustle, which is him and a group of his friends who do podcast editing for Headgum. He does our main shows and our actual play shows. They were like, "Oh yeah, they can help you out with your actual play shows." And then me, as the incredibly stressed-out producer that was also having to listen to multiple hours of my own voice a week, went, "What about the main show as well?" +CHAD: [laughs] +JASPER: And they were like, "Yeah, fine." [laughter] I was like, "Thank you," [laughs] because I can't bear listening to myself. I don't mind editing, and I'm not bad at it. But listening to my own voice is not on my list of to-dos. [laughs] +CHAD: It sounds like, overall, that being part of a network has been positive for you. +JASPER: Yeah, hugely. +CHAD: That's awesome. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +CHAD: Let's talk about...I'm making the assumption...I didn't dwell too much at the beginning of the episode that people understand what Dungeons & Dragons is, but maybe that's too big of an assumption. But it just seems so much more popular now [laughs] than it ever had before. So I feel like I can at least say Dungeons & Dragons to people, and people are like, even if I don't actually know what it's like to play, I know what it is, at least now. [laughs] +JASPER: Yeah, yeah, you got an idea of what it is. Yeah, for sure. [laughs] +CHAD: But let's maybe, at this point, take a little bit of a step back. And Dungeons & Dragons is more popular than it has ever been before. I think that that's really exciting for creators like you because it must feel like there's more opportunity than ever. +JASPER: Yes, yeah, absolutely. And I think that...so this actually, I think really ties into something that I've been doing a little bit of research on, which is...I can't say too much at this point, but I'm putting together a convention. Part of the idea behind this convention was that I've noticed there's a really big trend towards experience-based entertainment. We love movies. We love going out to bowling, all that kind of stuff. But real full immersion-based experiences, I think, are...post-lockdown, everyone's like, yes, give me all of that. I've been cooped up in a house. I want to be whisked away as far away as possible. +And so I do think that is part of the reason why Dungeons & Dragons has started to become even organically more and more popular. Because I just think the idea that instead of, I don't know, just sitting around on a Friday with some friends talking, or just watching a movie, or whatever it may be, that you can kind of with your friends go off and take part in something that feels epic and larger than life and really allows you to abandon for just a couple of hours some of the strains and pressures on your life. +I think, again, post-lockdown, that just feels like such an appetizing thing [laughs] to be able to do. And I just think with then the general acceptance of nerdiness as mainstream culture; people are just a lot more willing to be like, well, if I'm going to watch a movie with a dude who has a suit made entirely of iron and says really corny lines and shoots laser beams out of his chest, I probably could be okay with pretending to be a goblin for half an hour. +CHAD: [laughs] +JASPER: Whereas I think before, people would have been really like, no, no, no, we don't do that. I only watch, I don't know, Kubrick movies or something. Do you know what I mean? +CHAD: Yeah. +JASPER: Like, that's their form of entertainment. +CHAD: Yeah, that trend really resonates with me. Even before the pandemic, escape rooms and that kind of thing were becoming really popular. +JASPER: Yes. +CHAD: I mean, there are escape rooms everywhere now. [laughs] +JASPER: One of the things that I found out as I was coming up with the idea for this convention...I was talking to a buddy of mine, and he basically owns an event space, which has a cinema in it, and it also has a little theater. And he ran over; I think it was last summer, a "Guardians of the Galaxy" themed kind of experience where you walked around, and you got to meet some of the characters and stuff like that. And then next door in that building, they were showing the "Thor: Love and Thunder" movie. +And despite the fact that the experience was three times as expensive as the "Thor: Love and Thunder" movie at the cinema, that experience sold out almost instantly. And the "Thor: Love and Thunder" movie was struggling to get people on the seats; you know what I mean? But I was like, but "Thor: Love and Thunder" is a Guardians film, you know what I mean? All of them are there. It's ostensibly a "Guardians of the Galaxy" movie, and yet people are going to see a "Guardians of the Galaxy" experience, which I don't even know if it was like an official thing...rather than seeing the movie of it. +So I just think, yeah, like you said, this trend for escape rooms and all that kind of stuff just really resonated with me that I was like, yeah, that's...like, if I had to choose, if I was in a privileged position and could afford to go to that thing, I'd be like, pssh, yeah, I'd probably go to the "Guardians of the Galaxy" experience rather than just, eh, I don't have to watch the film. I could probably get it on Disney Plus in like two weeks, so...[laughs] +CHAD: Yeah. Have you ever been to a secret cinema in London? +JASPER: Yes. I did "Top Gun: Maverick" Up here in Manchester. +CHAD: [laughs] I went to the "Star Wars" one a few years ago. +JASPER: Nice. How was that? +CHAD: I guess, actually, it would have been five years ago. It was amazing. So for people who don't know, secret cinema is you're ostensibly going to see a movie, [laughs] but they build up an entire experience with improv actors themed to the movie that you're seeing, and you don't know where it is. It's technically a secret. They send you the location of it. You go there, and you're whisked away into the world of the movie. +JASPER: Yeah, I did a "28 Days Later" one. [laughter] Yeah, that was one... +CHAD: Horrifying. +JASPER: Yeah, that one was a little much, honestly. [laughs] I was like, I love this movie, but I don't feel safe sat in this cinema [laughs] because I've just walked through three fields filled with zombies and I ran for half of it. [laughs] So, I don't know, I was like, my heart was still racing as I sat down to watch the movie, which I think in many ways, did enhance the experience because I was sort of looking over my shoulder for half of it. [laughs] +CHAD: And when people who haven't ever actually seen Dungeons & Dragons played before, I often describe it as we're just telling a story together. Or maybe if they're a little less intimidated by improv because some people are into it, it's like an improv show where you can basically do anything you want or say what you want to do. And then you roll the dice to see whether it actually happens or not. And that's really at the base level all it is. +JASPER: Yeah, yeah, absolutely. [laughs] +CHAD: And I think you're right; people are more open to that idea of an experience or a game like that than they ever have been before. +JASPER: Yeah, for sure. There are so many things that you can kind of fall back on if you're not someone who is super comfortable with improvising or whatever. And I think that's what the game provides is it provides enough structure for you to then just kind of, honestly, because, you know, you do just kind of forget that you're doing it really after about 10 minutes of slight awkwardness when you start with a new group because the game provides you with almost like the fuel. You'll be like, oh, I don't know if I can do this or whatever. And it's like, okay, just go ahead and roll me a d20. And then you roll in that 20, and everyone loses their minds around the table. +CHAD: [chuckles] +JASPER: And suddenly you're like, okay, I'm in this. I'm the barbarian, and I'm getting angry. And I run in there, and I kick the door down, you know what I mean? And suddenly, you're sat there watching this person who was super nervous five seconds ago stood up on their feet screaming at me as the DM telling me how they eviscerate all these bad guys. So yeah, definitely, the game provides a very good structure for that. +CHAD: With this...you mentioned building this experience for a convention. Do you want to talk more about that? +JASPER: Yes, I can talk about it in very broad terms. I just can't go into the specifics of when, and the whos, and stuff like that. But ostensibly, the idea was to do a...I got really interested by this idea of reclaiming fantasy. It was kind of like this thing that kept going around in my head. And I was like; I wonder if there's a way that we could see our...again, specifically geared towards minority groups. It's what I know well and a community that I want to continue to serve. +And I was like; I wonder if we can create a space where it's specifically for them, explicitly for them in the sense that I think there are a lot of spaces that are explicitly for non-minority groups, you know what I mean? I think a lot of the traditional conventions typically are those things. But I think we get very afraid of creating something where we...people with the purse strings usually go, oh no, you can't exclude people, and I'm like, we're not excluding people. We're just making it very specifically for someone else. +And a lot of it was...it then came from the idea of seeing "The Rings of Power" trailer get released. And then the thing that's trending on Twitter is like; there were no black elves, not yes, we've got a black elf, you know what I mean? And I suddenly was like, I really want us to have a space where we can be celebrated in fantasy, et cetera, without having to have that caveated as like seeing it as some sort of diversity hire or whatever. +Anyway, this snowballed through going to things like D&D in a Castle and combining it with this idea of reclaiming fantasy of, like, what if we did it inside of like a stately home or a castle? What if we made this event and we really made it that you as a minority can be there and celebrated in the space where you've got, like, Baron, what's his name, on the wall? +CHAD: [laughs] +JASPER: And it's this White dude from 500 years ago, do you know what I mean? And it's like, I just really loved the idea of a room full of minorities really feeling welcomed and like they were a part of this space, and just realizing minorities we've been around forever, you know what I mean? [laughs] There's never been a point in human history where people with Brown skin haven't been here. We've always been here. +So I guess it was just about really realizing that when we sat there watching, I don't know, Pirates of the Caribbean, and there's like two Black people in the swamp. It's like, no, no, no, no, we would have been everywhere, [laughs] do you know what I mean? We would have been everywhere. And we can be celebrated in these spaces too. These don't have to just be White spaces, and they don't just have to be for a very specific group that they have been traditionally for in the past. [laughs] And yeah, the reaction to this sort of pitch, if you will, was overwhelmingly positive. +CHAD: That's good. +JASPER: And it really took me by surprise, actually, because I was sort of thinking, yeah, I'm really sticking it to them with this pitch. +CHAD: [laughs] +JASPER: And then everyone was like, "Yeah, we love it." And I was like, oh, right. +CHAD: [laughs] +JASPER: Okay, yeah. [laughs] I was sort of doing that, and I had to climb down a little bit and be like, okay, awesome. Let's talk about it. What I think is really exciting about that it's just that I really think that conventions and everything can do more in terms of delivering experience. Like myself and my fiancée went to Comic-Con a couple of years ago. And I remember her feeling like, oh, it was just a little bit flat. And it was just sort of...I thought that there'd be more kind of grandeur to it, almost like there'd be more...it was just other than people cosplaying; there wasn't a lot of theater to the whole thing. +It was just like in these massive warehouses, and add a little bit of that theater in, have some of those actors, have some of the music and the sound and everything, really give people a place to go and explore and enjoy exploring. And I kind of keep thinking in my head it's like LARP lite, you know what I mean? +CHAD: Yeah. +JASPER: It's like LARP still with the kind of commercial interaction that you can still go and meet your favorite people. You can still get signings. You can still get previews of things. You can still buy things that you've been wanting to buy all year and that you can only get when you go to a certain convention, and all of the kind of normal convention tropes but really just explicitly labeling it on the bottle: this is for minority groups. Because I honestly think if we explicitly label it like that as well, we'll start to get away from a lot of the things that have plagued conventions for far too long when it comes to making people feel comfortable in those spaces. +And quite often, my biggest tip when it comes to diversity and inclusion with companies as well it's just like, put it on the bowl. Like, if you really believe it, have it front and center. Don't tuck it away in like a D&I bit on your website. Have it there so that everyone can see it. Everyone knows when they come to work with you; this is what you stand for. This is what you believe in, things like that, so... +CHAD: That sounds awesome. And it's a really good illustration of the idea which we've talked about on the show in previous episodes is that when you are used to being in the majority all the time, and that is the default, when something is being done that's different than that, it feels like you're losing something. It feels like you're under attack. That's a total natural feeling. +JASPER: Yes, yes. +CHAD: So it's like, that sounds like a great experience. I would love to experience that, and I'm being excluded because I'm White; that's not fair. But that's coming from a position of you've been in those safe spaces for yourself in a world that's been entirely tailored for you. So you haven't realized that you've had that all along. +JASPER: Yeah, absolutely. And the beauty of it is..., and this is where it's even better for people in the majority, which is that we have zero intention of making an unsafe space for anyone because that would be wild. So even the spaces that we create for minorities explicitly will still be safe for you as well, you know what I mean? +But I think, like you said, it's that reaction, which, again, I get it completely because, as I mentioned earlier, I was there. I've been there. I've been in a space where I suddenly go, oh, I'm part of the problem, and it feels horrible. Like, it's not nice, and it's a really challenging thing, which you have to be comfortable with, and I think everyone should be comfortable with it. +Whether you're a minority or not, everyone has blind spots. Everyone has biases. It's a huge part of human interaction. And honestly, in a modern world with the way that social media is, I don't think you can live without biases and without assumptions because you see new people, thousands of new people every day if you want to just by scrolling on your Twitter feed. So to be in this zen place of just like, I will accept everyone only on their merits, and I will not judge anyone would be impossible and maddening, I think. +So it's a perfectly normal thing to exist with those biases. The thing that we have to get better at is going, cool; I've got those biases. Now it's time to let them slide, like, to move them over there and to not get defensive if someone calls them out. Like, that's the trick. That's the magic trick. That's pulling the rabbit out of the hat. That's what you got to get comfortable with. +CHAD: Yeah, awesome. Well, I really appreciate the conversation, and I really appreciate you taking the time. I know that you get married in less than a week from now. +JASPER: I do. I do get married -- +CHAD: So congratulations in advance. +JASPER: Thank you so much. Thank you. +CHAD: If we could just take a few more minutes at the end to maybe nerd out about the Dungeons & Dragons movie, which I know you went to the premiere for, and I just saw this weekend... +JASPER: Oh please, let's do. Absolutely. +CHAD: It was funny because I think you've said exactly how I left the movie feeling, which was they captured the spirit of what it's actually...like, it was just fun. And Dungeons & Dragons is fun in a way that is not like "Lord of the Rings" [laughs] or just super serious fantasy, right? +JASPER: Yeah, yeah. I can't even think of the last time we had a fantasy movie that was like, you know, other than, I don't know, "Your Highness" or something that was just like, I don't know, yeah, whatever that was, you know what I mean? Something that was like an actual movie and didn't take itself too seriously, yeah. +CHAD: Yeah, I'm so happy because you could have easily have seen it, like, no, we need to do something super serious and to compete against "Game of Thrones" and "Lord of the Rings" and all that stuff. And to feel like, you know, this was made by people who get it and represented what I love was really exciting. +JASPER: Yeah. And I think that what it did for me is I think it lays the groundwork for them to explore more serious places because now they will have that trust that they understand what it's like to be at the table and how to do that. And then I think this is where the real skill is going to come in for them to curate more of these which is like...that, I think, is the art of a really good DM. They can have you absolutely roaring with laughter one minute and then sobbing in like, you know, and it's like an hour's difference, [laughs] you know what I mean? Between the two places. And that's then the next step for these. +But I think this was absolutely the tone they needed to strike for this, especially for this first kind of outing. I think they really needed to say, hey, we get it. We understand what it's like, just displaying purely unhinged actions and things, which I think that's the bit that feels D&D for me is when a character...and I think I won't go into any spoilers, but I think you'll probably know the moment I'm describing when a very clear solution is laid out in front of you in big, green letters, for instance, and you choose to do something truly, truly unhinged and wild. Because that was what you decided you were going to do ahead of time. +It's such a D&D thing to do. [laughs] And I loved that. It was one of my favorite moments in the movie. And I just thought that perfectly encapsulates the nature of it and the thing that you don't get to see in "Game of Thrones" or whatever because you don't get the Nat 1s or the Nat 20s, I think in the "Game of Thrones." Everything's like 7 to 12; you know what I mean? +CHAD: [laughs] Right. Right. +JASPER: Everyone is relatively skilled, so they can't just, like, you know what I mean? You can't have the mountain versus the Viper, and the mountain just trips over a rock and brains himself on the floor. +CHAD: [laughs] Right. +JASPER: You know what I mean? Because that would be a Nat 1, but that would be ridiculous because the mountain is an incredibly skilled fighter, and therefore, it wouldn't work like that. +CHAD: Yeah, yeah. I found myself grinning throughout, aside from the moments where I was laughing, just like, oh, that's...yes. +JASPER: [laughs] +CHAD: Just the whole thing about planning and how he's a planner. +JASPER: Yes. [laughs] +CHAD: Oh, that is so D&D. And just at the end, the way that that battle lays out, I just feel like it just captures everyone's act in the six-second increments in a D&D battle. And everything's happening all at once, and that's what that battle was like at the end. +JASPER: Yeah. And it also just props for like a really good magic fight. +CHAD: [laughs] Right. +JASPER: Like, I don't even know what the word is, but we have been convinced for years that Harry Potter had good magic, but no, he doesn't. +CHAD: [laughs] +JASPER: Harry Potter has wand-fu, and it's terrible. It's like; it's not particularly pleasing. It's basically the same as "Star Wars." It's just like a little laser pistol type, piu-piu-piu. +CHAD: [laughs] +JASPER: That's effectively what Harry Potter becomes. And then to see Bigby's Hand and spells like this be used in the ways, like, it was just so fun. And also, it really teaches the importance of flavoring your attacks and how much life you can bring to a game, to anything, by just adding that little bit more, like, that little bit of extra sauce on top. +I think Holger the Barbarian does a perfect job of this in the movie where she's always using improvised weapons, and the way that she fights it's, oh, it's very, very pleasing to watch. And you're sat there going, yeah man, barbarians are so cool. But half the time when you're in a game, you'll just be like, yeah, I run up, and I attack with my axe. It's like, no, give me more, give me more. Tell me how and why and stuff like that. So I agree; I think they did a great job. And I was also just grinning from ear to ear [laughs] during most of it. +CHAD: I feel like I could talk to you all day. +JASPER: [laughs] +CHAD: But I really appreciate it. If folks want to either get in touch with you, we mentioned at the top of the show you are a Game Master for hire, and you do games remotely, right? +JASPER: Yes, I do. I do. I do. +CHAD: So where are all the places that people can find you, get in touch with you, book you, all that stuff? +JASPER: Heck yeah. If anyone knows about my GMing for hire, it's you. [laughter] You had me DM for you for, in total, like, 29 hours in the space of a week. [laughs] +CHAD: Yeah. So we brought Jasper and we had the thoughtbot summit where we got the company together in person and so Jasper came and he DMed two sessions with two different groups for us, which was awesome. And then I went to D&D in a Castle, which you mentioned earlier in the show. It's where you go to a castle in the UK and play D&D for three and a half days straight basically. It was an amazing experience and Jasper was an incredible DM. +JASPER: Thank you. And if anyone is interested in hiring me as a DM, like I said, I do consultancy, whether it be D&I consultancy or podcast to help you grow podcasts and things like that, or even just get started. Most of that information is on my website which is jasperwcartwright.com. You can find me on all social medias. I'm usually pretty good at responding to people in there, and that is just @JW_Cartwright on all of my social media. So yeah, go follow me, and I've got a bunch of really exciting stuff coming up, so it's a good time to follow me. [laughs] +CHAD: Awesome. +You can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon @cpytel@thoughtbot.social. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening and see you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Jasper (William) Cartwright. + + + Jasper (William) Cartwright is a Freelance Producer, Podcaster, Actor, and Motion Capture & Performance Capture Performer.

+ +

Chad talks to Jasper about his podcast Three Black Halflings, which is committed to discussing diversity and inclusion within fantasy, sci-fi, and nerdy culture from the perspective of three people of color, what it's like to be in the space, and why representation is super important.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jasper William-Cartwright, Game Master for hire, Actor, Creative Consultant, Podcaster, Co-Host of The Performance Capture Podcast, and Co-Host of one of my favorite podcasts, Three Black Halflings. Jasper, thank you so much for joining me.

+ +

JASPER: Hey, no, thank you so much for having me. And, man, with that intro, I almost feel...

+ +

CHAD: [laughs]

+ +

JASPER: I almost felt...I was like, oh, I feel cool. Those are some fun things. [laughs]

+ +

CHAD: I almost started with a Heeello robots.

+ +

JASPER: [laughs]

+ +

CHAD: But it doesn't really have the alliteration that hello Halflings does, so...

+ +

JASPER: Sure. I don't even know how the hello Halfling started. Like, I'm going to have to go back and listen to some of the earlier episodes again because I genuinely have no idea how it happened. And now it's gotten to a point where it's unyieldy. Every episode, I feel like I have to get a little bit further and a little bit higher. And I'm like, this can't be good for people's ears, so, [laughs] yeah.

+ +

CHAD: So I know what the show is, but in your own words, what is the Three Black Halflings Podcast?

+ +

JASPER: The Three Black Halflings Podcast is a show which is committed to talking about diversity and inclusion within fantasy and sci-fi, and sort of anything that nerdy culture touches, we try to cover it from the perspective of three people of color, what it's like to be in the space, and why representation is super important.

+ +

CHAD: I want to talk about the origin of the show and how you got started. But I was introducing someone to the show previously because I try to tell everybody I can about the show. [laughter] I've noticed in the beginning when you started, there was a lot of low-hanging fruit, like, we can dive into this stuff and educate people. And over time, you've introduced actual play where you're playing Dungeons & Dragons on the show. And I think it's changed a little bit, and it's still great.

+ +

But I always also recommend people go back to the beginning. And I think a lot of the episodes are sort of timeless. They're not about the news of the day. They're diving into particular topics and discussing either the impact or the problems that they have or how to play them better.

+ +

JASPER: Yeah, definitely. I think you're absolutely right. It's been a weird thing where because we've become more popular and we're kind of more in tune with the TTRPG space; I think that typically what has happened for us is that we've spent less time really digging around for, you know, what's some stuff... all the things that we can explore. And we're a lot more kind of like, what's the beat of the moment? If that makes sense. And I think that's why we haven't done as many episodes like that.

+ +

And also, just because we...I just think that the audience is changing. And the way that people consume our content is changing. It tends to go in cycles for us where we'll do a batch of very topical episodes then we'll do more really nitty gritty kind of game design episodes. And so I think a lot of it does depend on the sort of moment, what's going on. There are still a bunch of episodes that we have planned. And obviously, we have the Halfling University series which is coming out currently, which is a more retrospective look back on poignant things throughout the history of nerd [inaudible 3:11] and nerd culture. So I like to think there's a good variety on there.

+ +

CHAD: Obviously the show, especially I think when it started, had a very heavy focus on Dungeons & Dragons, which I love. People who know me [laughs] know that I love Dungeons & Dragons.

+ +

JASPER: [laughs]

+ +

CHAD: And I've been playing it for a long time. And as someone playing it since I was a teenager, I didn't realize until I got older and learned a lot more...and certainly, the show went a long way to sort of educating me about how not only the origins of some of the tropes of fantasy and Dungeons & Dragons but just in general how to have inclusive play.

+ +

When you're playing with a group of people, and to bring it back to a non-Dungeons & Dragons specific thing, this is true, I think, in any group of people. When you're surrounded by a group of people who look the same as you, are from the same area, have the same experiences, you don't realize what's missing from that table, and that's true in our companies, and it's true around a TTRPG table too.

+ +

JASPER: Yeah, I completely agree. And I think that's the same for a lot of us. I remember doing a big post after I'd been doing the show for about six months, and it was just like, I was very open when I started the show that a lot of what I wanted to talk about I wanted it to be a safe space for me to explore some of these things.

+ +

Because I grew up in a very White middle-class area, and therefore I had a lot of the blind spots that I would see my friends of color call out my White friends for or whatever it may be. And so I was like, okay, it's time for me to educate myself. And I wanted to do it in a safe space, in a place where I could learn from great people. Obviously, we had other co-hosts of the show who are fantastic people, but we had things like sensitivity consultants and people like that come on.

+ +

I always like to shout out James Mendez Hodes, who, if you ever want to do a bit of a deep dive into fantasy...and you said, Chad, the historical basis for some of the stuff that we use, and he wrote some really incredible stuff. And so a lot of it was about me trying to educate myself as well and kind of put in that work. I thought there was a value there in doing it in an open forum in sort of saying, hey, I'm a person of color, and I'm also trying to figure this out, you know what I mean?

+ +

CHAD: Mm-hmm.

+ +

JASPER: Because I think that a lot of the time, the barrier for anyone who doesn't belong to a minority group is like, oh, man, I don't want to burden someone else with my own understanding of this thing, and I don't want to ask the wrong questions. Or maybe I don't even know where to begin in educating myself. And so there was something about the three of us and me particularly kind of being very open about the fact that we were learning about this too and that there might be things that...mistakes or things might slightly be out of place but that we have that openness and willingness to learn.

+ +

And I think that in today's internet culture where everyone is so kind of reaction-based, it just felt important to me that we had a space where we could sit in and talk about stuff and really be open with each other in a way that we knew we'd all be able to shake hands and be like, cool, that was a good session or whatever [laughs] it was today, and not be like, I hate you, you know what I mean? Because someone had made a mistake, or misspoke, or something like that.

+ +

And I think you're absolutely right. It's something I've started to do a bit more of recently, which is doing diversity and inclusion talks and coaching for companies because I think a lot of the lessons that I've learned through doing this show, especially around things like language and how you set up a work environment to suit people of color and more generally, minorities, it's a slightly continuous pursuit in the sense that you always have to be kind of open and learning.

+ +

And I think also it provides a...what I think is best about it is that it provides such richness to your work environment. We always say on Three Black Halflings that we want you to take these things and use them to enhance your game. Like you're saying, if you have the same people with the same experiences all the time and that's all you ever hear, then, of course, you're going to get a pretty one-sided experience. And then, if you expand that out to include people from halfway across the world who have a very different experience, they're going to see things differently.

+ +

And I can almost guarantee there'll be a problem that you and your team have been stuck on for like months, and someone from a different perspective will come in and be like, boom, there's the problem, or that's how we get around it because they have a different frame of reference to you. And so I always try to...it sounds really awful to say sell it, [laughs] you know, not trying to sell diversity and inclusion, but I always want to try and go further by saying it's not just about getting different faces in the door. It's about enriching the work that you do and allowing your team to do the best work that they can.

+ +

Just the quantity of difference between the kinds of things like games that I used to run, you know, to link it back to Dungeons & Dragons, versus the games that I run now, just having had this wealth of influence from other people and different experiences is incredible. And I think it holds true for every element of my work. So I work as a producer a lot in lots of creative fields as opposed to just podcasting. And it's improved tenfold just by having a diverse group of people that I draw from their experiences in my pursuits. So I think it makes a big difference.

+ +

CHAD: I think it's the idea that you wanted a safe space, and so you created a public podcast on the internet.

+ +

[laughter]

+ +

JASPER: Yeah, I can see how that sounds now.

+ +

[laughter]

+ +

CHAD: I assume that you've had to navigate being in public spaces talking about diversity, inclusion. I'm sure that that has been difficult at times.

+ +

JASPER: Yeah, for sure. I think just to clarify that as well, [laughs] because I am definitely aware of how it sounds, I've always been a very, like, I don't care attitude, you know what I mean?

+ +

CHAD: Yeah.

+ +

JASPER: In the sense that I felt like I needed what I was going to make, if that makes sense. What, I guess, I meant by a safe space is I wanted people to have the safe space of listening to it. I was getting the safe space as far as I was concerned because podcasts aren't a reactionary medium, which is lovely. So thank God your audience isn't sat here just saying everything that you said wrong and correcting you. People are probably shouting at me for stuff that I've said already on this episode. [chuckles]

+ +

So it's definitely a fine line, like you said, to put something out on the internet. It's a very, very public thing to do. But it definitely just felt like, for me, creating somewhere where people could just disappear a little bit and encounter these things in a way where they're not going to be called out, or they're not going to be kind of threatened. There's no risk of cancellation or whatever if you say the wrong thing or whatever it is. It felt important.

+ +

And yeah, we've had to deal with...I will say this; it's kind of tricky to sum up the things that we've dealt with because I think a lot of stuff is still so systemic in the sense that just even down to the opportunities that you get and things like that where you kind of go like, huh, they started in this space like two months ago, and they have twice the followers we do. And they're getting loads of money for doing these streams. [laughs] And you're going to go, like, hold on, what's going on here?

+ +

CHAD: Yeah, there are three people on this show. They have ten times the Patreons that we do.

+ +

[laughter]

+ +

JASPER: Yeah, exactly.

+ +

CHAD: Why might that be?

+ +

[laughter]

+ +

JASPER: Yeah, exactly. Exactly that. And that's one side of it. And then, to be honest, the most it's happened...and this is quite a recent thing, which I don't even think we've really spoken about on the show was the reaction to the...so for anyone who doesn't know Dungeons & Dragons, there was a recent controversy where Hasbro and Wizards of the Coast threatened to repeal part of the license, which allowed creators to freely kind of use elements, not all of them, but some elements of the Dungeons & Dragons game and the Dungeons & Dragons IP for content basically.

+ +

And they wanted to repeal it, and they wanted to start bringing in more checks and balances in terms of what you could and couldn't do. And they wanted to start taking cuts of the profits and all this kind of thing. And anyway, the reaction was, as you can probably imagine, not great. Us content creators are ostensibly the lifeblood of this game, especially in terms of its online presence.

+ +

So we ended up getting the opportunity to interview one of the executive producers at Wizards of the Coast, and we put it on our YouTube. And it's hilariously one of the most viewed pieces of content that the Three Black Halflings has, full stop. And the reaction is so strange because you have people that get super angry at this guy for being corporate, and this and that, and the other. And we were like, okay, that's fine. So that was the first wave of reaction.

+ +

Then it was like, he's a racist against White people. And we were like, whoa, okay. And then it turned into you're racist because you didn't call him out for being racist against White people. And then, eventually, I think it just found its way to the trolls who are now just being openly racist about it.

+ +

So it's a very strange dynamic of seeing that play out in terms of it literally depending on the amount of people that listened to it, do you know what I mean? It didn't hit troll numbers yet, like; it needed to be more popular to hit troll numbers. So part of me does wonder if we just haven't quite got to peak troll numbers [laughter] with the main podcast. I'm sort of readying myself with a spear and a shield, so I'm like, okay, trolls are coming.

+ +

CHAD: It's like a double-edged sword. You want to be more popular but at the same time, hmm. Part of what I'm getting at is I think the work you do, even if you take sort of systemic racism out of it, the reaction to diversity and inclusion topics out of it, it's not easy to be an independent content creator, then you add that on to it. So how do you keep going? You've been doing it for three years now. What's your day-to-day like? How do you keep going at it?

+ +

JASPER: I mean, the rewards are just huge. I got to go to the Dungeons & Dragons premiere the other day. I went to a party in the Tower of London and had people coming up to me. Everyone knew who I was at the Tower of London at a party in the Tower of London. And when I say Tower of London, I want to clarify that it wasn't a function room attached to the Tower of London.

+ +

CHAD: [laughs]

+ +

JASPER: We were in the Tower of London. I was having champagne, sipping it next to Henry VIII's armor.

+ +

CHAD: [laughs] Amazing.

+ +

JASPER: It was absolutely wild and being there and people coming up to me and being like, "We love what Three Black Halflings does. We think it's a really important voice in the community. And you guys absolutely like..." you know, because I was sort of like, oh God, I can't believe we're here or whatever. And people would be like, "No, no, you absolutely deserve to be here. It's so important that you guys are here." So I think that has a huge impact.

+ +

People in the community, the way that we've been embraced there's so many shows and so many people who are creating content that are working so hard who don't have nearly the platform that we have. And I think that is, A, a testament to us and the hard work that we put in. But it's also a testament to just how important what we're doing within the community is.

+ +

And I still don't really think there is a facsimile for Three Black Halflings in the industry in the sense that we're a talk show. We talk about heavy topics a lot of the time, but we do it with a smile on our face. And we try to laugh as much as humanly possible, you know what I mean? Because the whole premise of this show was that Black joy can be a form of protest. So we wanted to be like, hey, we can talk about serious stuff without having to cry and feel crushingly horrible about it, you know. [laughs]

+ +

And I think I guess that's how I feel whenever I feel like I want to cry or feel crushingly horrible about my workload or how hard it is to make the show is that I go, this is kind of the point, you know what I mean? This is why we got into it because I think that this is going to make it easier for someone else to do the same thing or someone else do something even better, and that, for me, is incredibly rewarding.

+ +

But I will caveat all of that by saying we've started to generate some money through ad revenue and Patreon, everything like that. And it's actually...this show has given me the opportunity to leave my full-time day job, which was still kind of creative. I was working in animation before this. And I loved that job, but now I get to be my own boss.

+ +

And it's been a really steep learning curve learning how to do work-life balance when you're your own boss because you're like, I could really disrespect my time here, you know what I mean? [laughter] I can get a lot done today. And I go, no, I have to spend time with my fiancée. I have to eat food. I have to sleep. I have to drink water. I think a lot of the process has been about that.

+ +

And I think, especially recently, I've gotten much better at kind of giving myself that work-life balance, and that makes it a lot easier for me to carry on. Because I feel like we've gotten to a point where I can be honest with the community as well and say, "Hey, we're having a late episode this week because there are some kinks with the edit," or something. [laughs] And people are just like, "Yeah, it's fine."

+ +

So I was actually having a consultancy session for someone yesterday. And one of the big things I kept saying to them was, as a content creator, you have to realize the world is not going to crash and burn if you don't hold the standards that you've set for yourself. Because the chances are your audience has much, much lower expectations, and that's not because they don't think you can do it. It's just because they understand that you're human, and they want you to do well, you know what I mean?

+ +

So if ever I feel like, oh no, Three Black Halflings has really messed up, I'm like, this episode sounds terrible. And we put it out and, ugh, and I'm there twisting myself into knots and making myself feel horrible. And then I go to the Discord, and everyone's like, "Oh, that sounded a bit janky. Oh, well, I'm sure they'll sort it out." [laughs] It's just like, it's absolutely fine.

+ +

So taking pressure off of yourself, I think, is something that I think is really important if you're trying to pursue, especially if you're trying to start out in pursuit of something like this because, yeah, it's super easy to drown yourself [laughs] in all of the kind of stress and anxiety about putting content out.

+ +

CHAD: You mentioned ads, and you mentioned Patreon. I think it was...was it last year that you joined a podcast network?

+ +

JASPER: Ooh, it would have been a year before.

+ +

CHAD: A year.

+ +

JASPER: So I've been with Headgum, I think, for nearly two years now.

+ +

CHAD: Wow. What sort of prompted that, and what does being part of a network give you as a podcast?

+ +

JASPER: Hell yeah. Joining a network ostensibly is just like joining a kind of family of other shows. I guess the closest equivalent really is sort of having your show picked up by Netflix or a broadcaster or something like that. It's sort of like you're bringing your show to that family. And then the most common thing...every network is obviously slightly different and will have different kinds of support structures that they offer certain shows depending on the money they generate, all that kind of thing.

+ +

But the most common one is effectively; you are now in a group that can all support each other and can all benefit each other by doing ad swaps because ad swaps typically is the absolute best way to improve podcast performance, mostly just because the user journey is super simple. It's like, hey, do you like the sound of this podcast? Well, the link to it is in your description. You have to click twice. You have to go into the description, click on that link, and then hit subscribe, and you're done. That's all you have to do, and it will be there. And you know it'll automatically tee up in your feed and all that kind of stuff.

+ +

So things like pod swaps and everything like that are by far the most effective for spreading the word about your show. And it also just helps you really hit specific target audiences where you go; we have great metrics that we can see of like, the average age of our listeners, how they identify gender-wise, music they listen to typically, what the average Three Black Halflings listens to. I think when you roll all of that information together as a part of a network, you have a huge bank of data, which they can then use to kind of market you in the best way and push you out in the best way.

+ +

And then, on top of that, most networks will have some sort of ad revenue like sort of system or tech, I guess, is probably the best way of putting it. And certainly, for some networks, they almost run like tech companies, how I imagine tech companies run. You're probably about to tell me, "A lot better." [laughs]

+ +

CHAD: Don't worry about it. [laughs].

+ +

JASPER: But, for instance, Headgum has Gumball. So Gumball is their ad sales sort of site, which has software which allows you to basically...everyone can go, and you can book ads just by looking at the podcast, seeing how many downloads it has; again, it has a breakdown of demographics and things like that that you can look at to see if that will marry up with whatever product you're pushing out. And then that will automatically set up a prompt for me to then read the script, upload it, and then that will put a dynamic ad in the middle of an episode, however many episodes until a certain amount of impressions are delivered.

+ +

So, again, that will be very unique and different depending on which network you join. But ostensibly, I'd say those are the two main things is pooling of resources amongst a family of different podcasts and then some sort of promise of ad revenue or ad sales. Most of them also have an ad sales team where they'll go and hunt out more specific spots for your show.

+ +

So, for instance, we just got sponsored by, I think it was Penguin or maybe Random House. Actually, maybe it's Random House who are publishing three little additional books to go in and around the Dungeons & Dragons movie. So we just did a little ad for them. And that was, again, the sales team kind of going out and being like, oh, we can see that you're looking for advertising places. Why don't you come and advertise on this Dungeons & Dragons podcast? [laughs] So yeah, stuff like that, I think.

+ +

Those were, I'd say, the main areas, and then it'll kind of depend...some podcast networks will help with editing. They'll have almost like a house style. So they'll sort of...they'll say, oh, we'll do the editing for you because we want to marry up all the shows so that they have a similar sound

+ +

CHAD: Is Headgum doing some editing for you and not on other episodes, or…?

+ +

JASPER: No. Headgum pretty much does...one of the best things [laughs] about it is we have an incredible sound designer; shout out to Daniel. He's actually one of the sound designers of God of War, if you can believe that.

+ +

CHAD: [laughs]

+ +

JASPER: He's won several awards for sound design. He basically has almost like a little side hustle, which is him and a group of his friends who do podcast editing for Headgum. He does our main shows and our actual play shows. They were like, "Oh yeah, they can help you out with your actual play shows." And then me, as the incredibly stressed-out producer that was also having to listen to multiple hours of my own voice a week, went, "What about the main show as well?"

+ +

CHAD: [laughs]

+ +

JASPER: And they were like, "Yeah, fine." [laughter] I was like, "Thank you," [laughs] because I can't bear listening to myself. I don't mind editing, and I'm not bad at it. But listening to my own voice is not on my list of to-dos. [laughs]

+ +

CHAD: It sounds like, overall, that being part of a network has been positive for you.

+ +

JASPER: Yeah, hugely.

+ +

CHAD: That's awesome.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

CHAD: Let's talk about...I'm making the assumption...I didn't dwell too much at the beginning of the episode that people understand what Dungeons & Dragons is, but maybe that's too big of an assumption. But it just seems so much more popular now [laughs] than it ever had before. So I feel like I can at least say Dungeons & Dragons to people, and people are like, even if I don't actually know what it's like to play, I know what it is, at least now. [laughs]

+ +

JASPER: Yeah, yeah, you got an idea of what it is. Yeah, for sure. [laughs]

+ +

CHAD: But let's maybe, at this point, take a little bit of a step back. And Dungeons & Dragons is more popular than it has ever been before. I think that that's really exciting for creators like you because it must feel like there's more opportunity than ever.

+ +

JASPER: Yes, yeah, absolutely. And I think that...so this actually, I think really ties into something that I've been doing a little bit of research on, which is...I can't say too much at this point, but I'm putting together a convention. Part of the idea behind this convention was that I've noticed there's a really big trend towards experience-based entertainment. We love movies. We love going out to bowling, all that kind of stuff. But real full immersion-based experiences, I think, are...post-lockdown, everyone's like, yes, give me all of that. I've been cooped up in a house. I want to be whisked away as far away as possible.

+ +

And so I do think that is part of the reason why Dungeons & Dragons has started to become even organically more and more popular. Because I just think the idea that instead of, I don't know, just sitting around on a Friday with some friends talking, or just watching a movie, or whatever it may be, that you can kind of with your friends go off and take part in something that feels epic and larger than life and really allows you to abandon for just a couple of hours some of the strains and pressures on your life.

+ +

I think, again, post-lockdown, that just feels like such an appetizing thing [laughs] to be able to do. And I just think with then the general acceptance of nerdiness as mainstream culture; people are just a lot more willing to be like, well, if I'm going to watch a movie with a dude who has a suit made entirely of iron and says really corny lines and shoots laser beams out of his chest, I probably could be okay with pretending to be a goblin for half an hour.

+ +

CHAD: [laughs]

+ +

JASPER: Whereas I think before, people would have been really like, no, no, no, we don't do that. I only watch, I don't know, Kubrick movies or something. Do you know what I mean?

+ +

CHAD: Yeah.

+ +

JASPER: Like, that's their form of entertainment.

+ +

CHAD: Yeah, that trend really resonates with me. Even before the pandemic, escape rooms and that kind of thing were becoming really popular.

+ +

JASPER: Yes.

+ +

CHAD: I mean, there are escape rooms everywhere now. [laughs]

+ +

JASPER: One of the things that I found out as I was coming up with the idea for this convention...I was talking to a buddy of mine, and he basically owns an event space, which has a cinema in it, and it also has a little theater. And he ran over; I think it was last summer, a "Guardians of the Galaxy" themed kind of experience where you walked around, and you got to meet some of the characters and stuff like that. And then next door in that building, they were showing the "Thor: Love and Thunder" movie.

+ +

And despite the fact that the experience was three times as expensive as the "Thor: Love and Thunder" movie at the cinema, that experience sold out almost instantly. And the "Thor: Love and Thunder" movie was struggling to get people on the seats; you know what I mean? But I was like, but "Thor: Love and Thunder" is a Guardians film, you know what I mean? All of them are there. It's ostensibly a "Guardians of the Galaxy" movie, and yet people are going to see a "Guardians of the Galaxy" experience, which I don't even know if it was like an official thing...rather than seeing the movie of it.

+ +

So I just think, yeah, like you said, this trend for escape rooms and all that kind of stuff just really resonated with me that I was like, yeah, that's...like, if I had to choose, if I was in a privileged position and could afford to go to that thing, I'd be like, pssh, yeah, I'd probably go to the "Guardians of the Galaxy" experience rather than just, eh, I don't have to watch the film. I could probably get it on Disney Plus in like two weeks, so...[laughs]

+ +

CHAD: Yeah. Have you ever been to a secret cinema in London?

+ +

JASPER: Yes. I did "Top Gun: Maverick" Up here in Manchester.

+ +

CHAD: [laughs] I went to the "Star Wars" one a few years ago.

+ +

JASPER: Nice. How was that?

+ +

CHAD: I guess, actually, it would have been five years ago. It was amazing. So for people who don't know, secret cinema is you're ostensibly going to see a movie, [laughs] but they build up an entire experience with improv actors themed to the movie that you're seeing, and you don't know where it is. It's technically a secret. They send you the location of it. You go there, and you're whisked away into the world of the movie.

+ +

JASPER: Yeah, I did a "28 Days Later" one. [laughter] Yeah, that was one...

+ +

CHAD: Horrifying.

+ +

JASPER: Yeah, that one was a little much, honestly. [laughs] I was like, I love this movie, but I don't feel safe sat in this cinema [laughs] because I've just walked through three fields filled with zombies and I ran for half of it. [laughs] So, I don't know, I was like, my heart was still racing as I sat down to watch the movie, which I think in many ways, did enhance the experience because I was sort of looking over my shoulder for half of it. [laughs]

+ +

CHAD: And when people who haven't ever actually seen Dungeons & Dragons played before, I often describe it as we're just telling a story together. Or maybe if they're a little less intimidated by improv because some people are into it, it's like an improv show where you can basically do anything you want or say what you want to do. And then you roll the dice to see whether it actually happens or not. And that's really at the base level all it is.

+ +

JASPER: Yeah, yeah, absolutely. [laughs]

+ +

CHAD: And I think you're right; people are more open to that idea of an experience or a game like that than they ever have been before.

+ +

JASPER: Yeah, for sure. There are so many things that you can kind of fall back on if you're not someone who is super comfortable with improvising or whatever. And I think that's what the game provides is it provides enough structure for you to then just kind of, honestly, because, you know, you do just kind of forget that you're doing it really after about 10 minutes of slight awkwardness when you start with a new group because the game provides you with almost like the fuel. You'll be like, oh, I don't know if I can do this or whatever. And it's like, okay, just go ahead and roll me a d20. And then you roll in that 20, and everyone loses their minds around the table.

+ +

CHAD: [chuckles]

+ +

JASPER: And suddenly you're like, okay, I'm in this. I'm the barbarian, and I'm getting angry. And I run in there, and I kick the door down, you know what I mean? And suddenly, you're sat there watching this person who was super nervous five seconds ago stood up on their feet screaming at me as the DM telling me how they eviscerate all these bad guys. So yeah, definitely, the game provides a very good structure for that.

+ +

CHAD: With this...you mentioned building this experience for a convention. Do you want to talk more about that?

+ +

JASPER: Yes, I can talk about it in very broad terms. I just can't go into the specifics of when, and the whos, and stuff like that. But ostensibly, the idea was to do a...I got really interested by this idea of reclaiming fantasy. It was kind of like this thing that kept going around in my head. And I was like; I wonder if there's a way that we could see our...again, specifically geared towards minority groups. It's what I know well and a community that I want to continue to serve.

+ +

And I was like; I wonder if we can create a space where it's specifically for them, explicitly for them in the sense that I think there are a lot of spaces that are explicitly for non-minority groups, you know what I mean? I think a lot of the traditional conventions typically are those things. But I think we get very afraid of creating something where we...people with the purse strings usually go, oh no, you can't exclude people, and I'm like, we're not excluding people. We're just making it very specifically for someone else.

+ +

And a lot of it was...it then came from the idea of seeing "The Rings of Power" trailer get released. And then the thing that's trending on Twitter is like; there were no black elves, not yes, we've got a black elf, you know what I mean? And I suddenly was like, I really want us to have a space where we can be celebrated in fantasy, et cetera, without having to have that caveated as like seeing it as some sort of diversity hire or whatever.

+ +

Anyway, this snowballed through going to things like D&D in a Castle and combining it with this idea of reclaiming fantasy of, like, what if we did it inside of like a stately home or a castle? What if we made this event and we really made it that you as a minority can be there and celebrated in the space where you've got, like, Baron, what's his name, on the wall?

+ +

CHAD: [laughs]

+ +

JASPER: And it's this White dude from 500 years ago, do you know what I mean? And it's like, I just really loved the idea of a room full of minorities really feeling welcomed and like they were a part of this space, and just realizing minorities we've been around forever, you know what I mean? [laughs] There's never been a point in human history where people with Brown skin haven't been here. We've always been here.

+ +

So I guess it was just about really realizing that when we sat there watching, I don't know, Pirates of the Caribbean, and there's like two Black people in the swamp. It's like, no, no, no, no, we would have been everywhere, [laughs] do you know what I mean? We would have been everywhere. And we can be celebrated in these spaces too. These don't have to just be White spaces, and they don't just have to be for a very specific group that they have been traditionally for in the past. [laughs] And yeah, the reaction to this sort of pitch, if you will, was overwhelmingly positive.

+ +

CHAD: That's good.

+ +

JASPER: And it really took me by surprise, actually, because I was sort of thinking, yeah, I'm really sticking it to them with this pitch.

+ +

CHAD: [laughs]

+ +

JASPER: And then everyone was like, "Yeah, we love it." And I was like, oh, right.

+ +

CHAD: [laughs]

+ +

JASPER: Okay, yeah. [laughs] I was sort of doing that, and I had to climb down a little bit and be like, okay, awesome. Let's talk about it. What I think is really exciting about that it's just that I really think that conventions and everything can do more in terms of delivering experience. Like myself and my fiancée went to Comic-Con a couple of years ago. And I remember her feeling like, oh, it was just a little bit flat. And it was just sort of...I thought that there'd be more kind of grandeur to it, almost like there'd be more...it was just other than people cosplaying; there wasn't a lot of theater to the whole thing.

+ +

It was just like in these massive warehouses, and add a little bit of that theater in, have some of those actors, have some of the music and the sound and everything, really give people a place to go and explore and enjoy exploring. And I kind of keep thinking in my head it's like LARP lite, you know what I mean?

+ +

CHAD: Yeah.

+ +

JASPER: It's like LARP still with the kind of commercial interaction that you can still go and meet your favorite people. You can still get signings. You can still get previews of things. You can still buy things that you've been wanting to buy all year and that you can only get when you go to a certain convention, and all of the kind of normal convention tropes but really just explicitly labeling it on the bottle: this is for minority groups. Because I honestly think if we explicitly label it like that as well, we'll start to get away from a lot of the things that have plagued conventions for far too long when it comes to making people feel comfortable in those spaces.

+ +

And quite often, my biggest tip when it comes to diversity and inclusion with companies as well it's just like, put it on the bowl. Like, if you really believe it, have it front and center. Don't tuck it away in like a D&I bit on your website. Have it there so that everyone can see it. Everyone knows when they come to work with you; this is what you stand for. This is what you believe in, things like that, so...

+ +

CHAD: That sounds awesome. And it's a really good illustration of the idea which we've talked about on the show in previous episodes is that when you are used to being in the majority all the time, and that is the default, when something is being done that's different than that, it feels like you're losing something. It feels like you're under attack. That's a total natural feeling.

+ +

JASPER: Yes, yes.

+ +

CHAD: So it's like, that sounds like a great experience. I would love to experience that, and I'm being excluded because I'm White; that's not fair. But that's coming from a position of you've been in those safe spaces for yourself in a world that's been entirely tailored for you. So you haven't realized that you've had that all along.

+ +

JASPER: Yeah, absolutely. And the beauty of it is..., and this is where it's even better for people in the majority, which is that we have zero intention of making an unsafe space for anyone because that would be wild. So even the spaces that we create for minorities explicitly will still be safe for you as well, you know what I mean?

+ +

But I think, like you said, it's that reaction, which, again, I get it completely because, as I mentioned earlier, I was there. I've been there. I've been in a space where I suddenly go, oh, I'm part of the problem, and it feels horrible. Like, it's not nice, and it's a really challenging thing, which you have to be comfortable with, and I think everyone should be comfortable with it.

+ +

Whether you're a minority or not, everyone has blind spots. Everyone has biases. It's a huge part of human interaction. And honestly, in a modern world with the way that social media is, I don't think you can live without biases and without assumptions because you see new people, thousands of new people every day if you want to just by scrolling on your Twitter feed. So to be in this zen place of just like, I will accept everyone only on their merits, and I will not judge anyone would be impossible and maddening, I think.

+ +

So it's a perfectly normal thing to exist with those biases. The thing that we have to get better at is going, cool; I've got those biases. Now it's time to let them slide, like, to move them over there and to not get defensive if someone calls them out. Like, that's the trick. That's the magic trick. That's pulling the rabbit out of the hat. That's what you got to get comfortable with.

+ +

CHAD: Yeah, awesome. Well, I really appreciate the conversation, and I really appreciate you taking the time. I know that you get married in less than a week from now.

+ +

JASPER: I do. I do get married --

+ +

CHAD: So congratulations in advance.

+ +

JASPER: Thank you so much. Thank you.

+ +

CHAD: If we could just take a few more minutes at the end to maybe nerd out about the Dungeons & Dragons movie, which I know you went to the premiere for, and I just saw this weekend...

+ +

JASPER: Oh please, let's do. Absolutely.

+ +

CHAD: It was funny because I think you've said exactly how I left the movie feeling, which was they captured the spirit of what it's actually...like, it was just fun. And Dungeons & Dragons is fun in a way that is not like "Lord of the Rings" [laughs] or just super serious fantasy, right?

+ +

JASPER: Yeah, yeah. I can't even think of the last time we had a fantasy movie that was like, you know, other than, I don't know, "Your Highness" or something that was just like, I don't know, yeah, whatever that was, you know what I mean? Something that was like an actual movie and didn't take itself too seriously, yeah.

+ +

CHAD: Yeah, I'm so happy because you could have easily have seen it, like, no, we need to do something super serious and to compete against "Game of Thrones" and "Lord of the Rings" and all that stuff. And to feel like, you know, this was made by people who get it and represented what I love was really exciting.

+ +

JASPER: Yeah. And I think that what it did for me is I think it lays the groundwork for them to explore more serious places because now they will have that trust that they understand what it's like to be at the table and how to do that. And then I think this is where the real skill is going to come in for them to curate more of these which is like...that, I think, is the art of a really good DM. They can have you absolutely roaring with laughter one minute and then sobbing in like, you know, and it's like an hour's difference, [laughs] you know what I mean? Between the two places. And that's then the next step for these.

+ +

But I think this was absolutely the tone they needed to strike for this, especially for this first kind of outing. I think they really needed to say, hey, we get it. We understand what it's like, just displaying purely unhinged actions and things, which I think that's the bit that feels D&D for me is when a character...and I think I won't go into any spoilers, but I think you'll probably know the moment I'm describing when a very clear solution is laid out in front of you in big, green letters, for instance, and you choose to do something truly, truly unhinged and wild. Because that was what you decided you were going to do ahead of time.

+ +

It's such a D&D thing to do. [laughs] And I loved that. It was one of my favorite moments in the movie. And I just thought that perfectly encapsulates the nature of it and the thing that you don't get to see in "Game of Thrones" or whatever because you don't get the Nat 1s or the Nat 20s, I think in the "Game of Thrones." Everything's like 7 to 12; you know what I mean?

+ +

CHAD: [laughs] Right. Right.

+ +

JASPER: Everyone is relatively skilled, so they can't just, like, you know what I mean? You can't have the mountain versus the Viper, and the mountain just trips over a rock and brains himself on the floor.

+ +

CHAD: [laughs] Right.

+ +

JASPER: You know what I mean? Because that would be a Nat 1, but that would be ridiculous because the mountain is an incredibly skilled fighter, and therefore, it wouldn't work like that.

+ +

CHAD: Yeah, yeah. I found myself grinning throughout, aside from the moments where I was laughing, just like, oh, that's...yes.

+ +

JASPER: [laughs]

+ +

CHAD: Just the whole thing about planning and how he's a planner.

+ +

JASPER: Yes. [laughs]

+ +

CHAD: Oh, that is so D&D. And just at the end, the way that that battle lays out, I just feel like it just captures everyone's act in the six-second increments in a D&D battle. And everything's happening all at once, and that's what that battle was like at the end.

+ +

JASPER: Yeah. And it also just props for like a really good magic fight.

+ +

CHAD: [laughs] Right.

+ +

JASPER: Like, I don't even know what the word is, but we have been convinced for years that Harry Potter had good magic, but no, he doesn't.

+ +

CHAD: [laughs]

+ +

JASPER: Harry Potter has wand-fu, and it's terrible. It's like; it's not particularly pleasing. It's basically the same as "Star Wars." It's just like a little laser pistol type, piu-piu-piu.

+ +

CHAD: [laughs]

+ +

JASPER: That's effectively what Harry Potter becomes. And then to see Bigby's Hand and spells like this be used in the ways, like, it was just so fun. And also, it really teaches the importance of flavoring your attacks and how much life you can bring to a game, to anything, by just adding that little bit more, like, that little bit of extra sauce on top.

+ +

I think Holger the Barbarian does a perfect job of this in the movie where she's always using improvised weapons, and the way that she fights it's, oh, it's very, very pleasing to watch. And you're sat there going, yeah man, barbarians are so cool. But half the time when you're in a game, you'll just be like, yeah, I run up, and I attack with my axe. It's like, no, give me more, give me more. Tell me how and why and stuff like that. So I agree; I think they did a great job. And I was also just grinning from ear to ear [laughs] during most of it.

+ +

CHAD: I feel like I could talk to you all day.

+ +

JASPER: [laughs]

+ +

CHAD: But I really appreciate it. If folks want to either get in touch with you, we mentioned at the top of the show you are a Game Master for hire, and you do games remotely, right?

+ +

JASPER: Yes, I do. I do. I do.

+ +

CHAD: So where are all the places that people can find you, get in touch with you, book you, all that stuff?

+ +

JASPER: Heck yeah. If anyone knows about my GMing for hire, it's you. [laughter] You had me DM for you for, in total, like, 29 hours in the space of a week. [laughs]

+ +

CHAD: Yeah. So we brought Jasper and we had the thoughtbot summit where we got the company together in person and so Jasper came and he DMed two sessions with two different groups for us, which was awesome. And then I went to D&D in a Castle, which you mentioned earlier in the show. It's where you go to a castle in the UK and play D&D for three and a half days straight basically. It was an amazing experience and Jasper was an incredible DM.

+ +

JASPER: Thank you. And if anyone is interested in hiring me as a DM, like I said, I do consultancy, whether it be D&I consultancy or podcast to help you grow podcasts and things like that, or even just get started. Most of that information is on my website which is jasperwcartwright.com. You can find me on all social medias. I'm usually pretty good at responding to people in there, and that is just @JW_Cartwright on all of my social media. So yeah, go follow me, and I've got a bunch of really exciting stuff coming up, so it's a good time to follow me. [laughs]

+ +

CHAD: Awesome.

+ +

You can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon @cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Jasper (William) Cartwright.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jasper (William) Cartwright is a Freelance Producer, Podcaster, Actor, and Motion Capture & Performance Capture Performer.

+ +

Chad talks to Jasper about his podcast Three Black Halflings, which is committed to discussing diversity and inclusion within fantasy, sci-fi, and nerdy culture from the perspective of three people of color, what it's like to be in the space, and why representation is super important.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

+ +

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

+ +

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

+ +

JORDYN: Thanks for having us.

+ +

DAWN: Yeah, glad to be here.

+ +

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

+ +

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

+ +

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

+ +

JORDYN: Wonderful.

+ +

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

+ +

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

+ +

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

+ +

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

+ +

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

+ +

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

+ +

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

+ +

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

+ +

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

+ +

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

+ +

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

+ +

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

+ +

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

+ +

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

+ +

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

+ +

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

+ +

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

+ +

VICTORIA: Wonderful. That's amazing. Thank you both so much.

+ +

INTRO MUSIC:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jasper William-Cartwright, Game Master for hire, Actor, Creative Consultant, Podcaster, Co-Host of The Performance Capture Podcast, and Co-Host of one of my favorite podcasts, Three Black Halflings. Jasper, thank you so much for joining me.

+ +

JASPER: Hey, no, thank you so much for having me. And, man, with that intro, I almost feel...

+ +

CHAD: [laughs]

+ +

JASPER: I almost felt...I was like, oh, I feel cool. Those are some fun things. [laughs]

+ +

CHAD: I almost started with a Heeello robots.

+ +

JASPER: [laughs]

+ +

CHAD: But it doesn't really have the alliteration that hello Halflings does, so...

+ +

JASPER: Sure. I don't even know how the hello Halfling started. Like, I'm going to have to go back and listen to some of the earlier episodes again because I genuinely have no idea how it happened. And now it's gotten to a point where it's unyieldy. Every episode, I feel like I have to get a little bit further and a little bit higher. And I'm like, this can't be good for people's ears, so, [laughs] yeah.

+ +

CHAD: So I know what the show is, but in your own words, what is the Three Black Halflings Podcast?

+ +

JASPER: The Three Black Halflings Podcast is a show which is committed to talking about diversity and inclusion within fantasy and sci-fi, and sort of anything that nerdy culture touches, we try to cover it from the perspective of three people of color, what it's like to be in the space, and why representation is super important.

+ +

CHAD: I want to talk about the origin of the show and how you got started. But I was introducing someone to the show previously because I try to tell everybody I can about the show. [laughter] I've noticed in the beginning when you started, there was a lot of low-hanging fruit, like, we can dive into this stuff and educate people. And over time, you've introduced actual play where you're playing Dungeons & Dragons on the show. And I think it's changed a little bit, and it's still great.

+ +

But I always also recommend people go back to the beginning. And I think a lot of the episodes are sort of timeless. They're not about the news of the day. They're diving into particular topics and discussing either the impact or the problems that they have or how to play them better.

+ +

JASPER: Yeah, definitely. I think you're absolutely right. It's been a weird thing where because we've become more popular and we're kind of more in tune with the TTRPG space; I think that typically what has happened for us is that we've spent less time really digging around for, you know, what's some stuff... all the things that we can explore. And we're a lot more kind of like, what's the beat of the moment? If that makes sense. And I think that's why we haven't done as many episodes like that.

+ +

And also, just because we...I just think that the audience is changing. And the way that people consume our content is changing. It tends to go in cycles for us where we'll do a batch of very topical episodes then we'll do more really nitty gritty kind of game design episodes. And so I think a lot of it does depend on the sort of moment, what's going on. There are still a bunch of episodes that we have planned. And obviously, we have the Halfling University series which is coming out currently, which is a more retrospective look back on poignant things throughout the history of nerd [inaudible 3:11] and nerd culture. So I like to think there's a good variety on there.

+ +

CHAD: Obviously the show, especially I think when it started, had a very heavy focus on Dungeons & Dragons, which I love. People who know me [laughs] know that I love Dungeons & Dragons.

+ +

JASPER: [laughs]

+ +

CHAD: And I've been playing it for a long time. And as someone playing it since I was a teenager, I didn't realize until I got older and learned a lot more...and certainly, the show went a long way to sort of educating me about how not only the origins of some of the tropes of fantasy and Dungeons & Dragons but just in general how to have inclusive play.

+ +

When you're playing with a group of people, and to bring it back to a non-Dungeons & Dragons specific thing, this is true, I think, in any group of people. When you're surrounded by a group of people who look the same as you, are from the same area, have the same experiences, you don't realize what's missing from that table, and that's true in our companies, and it's true around a TTRPG table too.

+ +

JASPER: Yeah, I completely agree. And I think that's the same for a lot of us. I remember doing a big post after I'd been doing the show for about six months, and it was just like, I was very open when I started the show that a lot of what I wanted to talk about I wanted it to be a safe space for me to explore some of these things.

+ +

Because I grew up in a very White middle-class area, and therefore I had a lot of the blind spots that I would see my friends of color call out my White friends for or whatever it may be. And so I was like, okay, it's time for me to educate myself. And I wanted to do it in a safe space, in a place where I could learn from great people. Obviously, we had other co-hosts of the show who are fantastic people, but we had things like sensitivity consultants and people like that come on.

+ +

I always like to shout out James Mendez Hodes, who, if you ever want to do a bit of a deep dive into fantasy...and you said, Chad, the historical basis for some of the stuff that we use, and he wrote some really incredible stuff. And so a lot of it was about me trying to educate myself as well and kind of put in that work. I thought there was a value there in doing it in an open forum in sort of saying, hey, I'm a person of color, and I'm also trying to figure this out, you know what I mean?

+ +

CHAD: Mm-hmm.

+ +

JASPER: Because I think that a lot of the time, the barrier for anyone who doesn't belong to a minority group is like, oh, man, I don't want to burden someone else with my own understanding of this thing, and I don't want to ask the wrong questions. Or maybe I don't even know where to begin in educating myself. And so there was something about the three of us and me particularly kind of being very open about the fact that we were learning about this too and that there might be things that...mistakes or things might slightly be out of place but that we have that openness and willingness to learn.

+ +

And I think that in today's internet culture where everyone is so kind of reaction-based, it just felt important to me that we had a space where we could sit in and talk about stuff and really be open with each other in a way that we knew we'd all be able to shake hands and be like, cool, that was a good session or whatever [laughs] it was today, and not be like, I hate you, you know what I mean? Because someone had made a mistake, or misspoke, or something like that.

+ +

And I think you're absolutely right. It's something I've started to do a bit more of recently, which is doing diversity and inclusion talks and coaching for companies because I think a lot of the lessons that I've learned through doing this show, especially around things like language and how you set up a work environment to suit people of color and more generally, minorities, it's a slightly continuous pursuit in the sense that you always have to be kind of open and learning.

+ +

And I think also it provides a...what I think is best about it is that it provides such richness to your work environment. We always say on Three Black Halflings that we want you to take these things and use them to enhance your game. Like you're saying, if you have the same people with the same experiences all the time and that's all you ever hear, then, of course, you're going to get a pretty one-sided experience. And then, if you expand that out to include people from halfway across the world who have a very different experience, they're going to see things differently.

+ +

And I can almost guarantee there'll be a problem that you and your team have been stuck on for like months, and someone from a different perspective will come in and be like, boom, there's the problem, or that's how we get around it because they have a different frame of reference to you. And so I always try to...it sounds really awful to say sell it, [laughs] you know, not trying to sell diversity and inclusion, but I always want to try and go further by saying it's not just about getting different faces in the door. It's about enriching the work that you do and allowing your team to do the best work that they can.

+ +

Just the quantity of difference between the kinds of things like games that I used to run, you know, to link it back to Dungeons & Dragons, versus the games that I run now, just having had this wealth of influence from other people and different experiences is incredible. And I think it holds true for every element of my work. So I work as a producer a lot in lots of creative fields as opposed to just podcasting. And it's improved tenfold just by having a diverse group of people that I draw from their experiences in my pursuits. So I think it makes a big difference.

+ +

CHAD: I think it's the idea that you wanted a safe space, and so you created a public podcast on the internet.

+ +

[laughter]

+ +

JASPER: Yeah, I can see how that sounds now.

+ +

[laughter]

+ +

CHAD: I assume that you've had to navigate being in public spaces talking about diversity, inclusion. I'm sure that that has been difficult at times.

+ +

JASPER: Yeah, for sure. I think just to clarify that as well, [laughs] because I am definitely aware of how it sounds, I've always been a very, like, I don't care attitude, you know what I mean?

+ +

CHAD: Yeah.

+ +

JASPER: In the sense that I felt like I needed what I was going to make, if that makes sense. What, I guess, I meant by a safe space is I wanted people to have the safe space of listening to it. I was getting the safe space as far as I was concerned because podcasts aren't a reactionary medium, which is lovely. So thank God your audience isn't sat here just saying everything that you said wrong and correcting you. People are probably shouting at me for stuff that I've said already on this episode. [chuckles]

+ +

So it's definitely a fine line, like you said, to put something out on the internet. It's a very, very public thing to do. But it definitely just felt like, for me, creating somewhere where people could just disappear a little bit and encounter these things in a way where they're not going to be called out, or they're not going to be kind of threatened. There's no risk of cancellation or whatever if you say the wrong thing or whatever it is. It felt important.

+ +

And yeah, we've had to deal with...I will say this; it's kind of tricky to sum up the things that we've dealt with because I think a lot of stuff is still so systemic in the sense that just even down to the opportunities that you get and things like that where you kind of go like, huh, they started in this space like two months ago, and they have twice the followers we do. And they're getting loads of money for doing these streams. [laughs] And you're going to go, like, hold on, what's going on here?

+ +

CHAD: Yeah, there are three people on this show. They have ten times the Patreons that we do.

+ +

[laughter]

+ +

JASPER: Yeah, exactly.

+ +

CHAD: Why might that be?

+ +

[laughter]

+ +

JASPER: Yeah, exactly. Exactly that. And that's one side of it. And then, to be honest, the most it's happened...and this is quite a recent thing, which I don't even think we've really spoken about on the show was the reaction to the...so for anyone who doesn't know Dungeons & Dragons, there was a recent controversy where Hasbro and Wizards of the Coast threatened to repeal part of the license, which allowed creators to freely kind of use elements, not all of them, but some elements of the Dungeons & Dragons game and the Dungeons & Dragons IP for content basically.

+ +

And they wanted to repeal it, and they wanted to start bringing in more checks and balances in terms of what you could and couldn't do. And they wanted to start taking cuts of the profits and all this kind of thing. And anyway, the reaction was, as you can probably imagine, not great. Us content creators are ostensibly the lifeblood of this game, especially in terms of its online presence.

+ +

So we ended up getting the opportunity to interview one of the executive producers at Wizards of the Coast, and we put it on our YouTube. And it's hilariously one of the most viewed pieces of content that the Three Black Halflings has, full stop. And the reaction is so strange because you have people that get super angry at this guy for being corporate, and this and that, and the other. And we were like, okay, that's fine. So that was the first wave of reaction.

+ +

Then it was like, he's a racist against White people. And we were like, whoa, okay. And then it turned into you're racist because you didn't call him out for being racist against White people. And then, eventually, I think it just found its way to the trolls who are now just being openly racist about it.

+ +

So it's a very strange dynamic of seeing that play out in terms of it literally depending on the amount of people that listened to it, do you know what I mean? It didn't hit troll numbers yet, like; it needed to be more popular to hit troll numbers. So part of me does wonder if we just haven't quite got to peak troll numbers [laughter] with the main podcast. I'm sort of readying myself with a spear and a shield, so I'm like, okay, trolls are coming.

+ +

CHAD: It's like a double-edged sword. You want to be more popular but at the same time, hmm. Part of what I'm getting at is I think the work you do, even if you take sort of systemic racism out of it, the reaction to diversity and inclusion topics out of it, it's not easy to be an independent content creator, then you add that on to it. So how do you keep going? You've been doing it for three years now. What's your day-to-day like? How do you keep going at it?

+ +

JASPER: I mean, the rewards are just huge. I got to go to the Dungeons & Dragons premiere the other day. I went to a party in the Tower of London and had people coming up to me. Everyone knew who I was at the Tower of London at a party in the Tower of London. And when I say Tower of London, I want to clarify that it wasn't a function room attached to the Tower of London.

+ +

CHAD: [laughs]

+ +

JASPER: We were in the Tower of London. I was having champagne, sipping it next to Henry VIII's armor.

+ +

CHAD: [laughs] Amazing.

+ +

JASPER: It was absolutely wild and being there and people coming up to me and being like, "We love what Three Black Halflings does. We think it's a really important voice in the community. And you guys absolutely like..." you know, because I was sort of like, oh God, I can't believe we're here or whatever. And people would be like, "No, no, you absolutely deserve to be here. It's so important that you guys are here." So I think that has a huge impact.

+ +

People in the community, the way that we've been embraced there's so many shows and so many people who are creating content that are working so hard who don't have nearly the platform that we have. And I think that is, A, a testament to us and the hard work that we put in. But it's also a testament to just how important what we're doing within the community is.

+ +

And I still don't really think there is a facsimile for Three Black Halflings in the industry in the sense that we're a talk show. We talk about heavy topics a lot of the time, but we do it with a smile on our face. And we try to laugh as much as humanly possible, you know what I mean? Because the whole premise of this show was that Black joy can be a form of protest. So we wanted to be like, hey, we can talk about serious stuff without having to cry and feel crushingly horrible about it, you know. [laughs]

+ +

And I think I guess that's how I feel whenever I feel like I want to cry or feel crushingly horrible about my workload or how hard it is to make the show is that I go, this is kind of the point, you know what I mean? This is why we got into it because I think that this is going to make it easier for someone else to do the same thing or someone else do something even better, and that, for me, is incredibly rewarding.

+ +

But I will caveat all of that by saying we've started to generate some money through ad revenue and Patreon, everything like that. And it's actually...this show has given me the opportunity to leave my full-time day job, which was still kind of creative. I was working in animation before this. And I loved that job, but now I get to be my own boss.

+ +

And it's been a really steep learning curve learning how to do work-life balance when you're your own boss because you're like, I could really disrespect my time here, you know what I mean? [laughter] I can get a lot done today. And I go, no, I have to spend time with my fiancée. I have to eat food. I have to sleep. I have to drink water. I think a lot of the process has been about that.

+ +

And I think, especially recently, I've gotten much better at kind of giving myself that work-life balance, and that makes it a lot easier for me to carry on. Because I feel like we've gotten to a point where I can be honest with the community as well and say, "Hey, we're having a late episode this week because there are some kinks with the edit," or something. [laughs] And people are just like, "Yeah, it's fine."

+ +

So I was actually having a consultancy session for someone yesterday. And one of the big things I kept saying to them was, as a content creator, you have to realize the world is not going to crash and burn if you don't hold the standards that you've set for yourself. Because the chances are your audience has much, much lower expectations, and that's not because they don't think you can do it. It's just because they understand that you're human, and they want you to do well, you know what I mean?

+ +

So if ever I feel like, oh no, Three Black Halflings has really messed up, I'm like, this episode sounds terrible. And we put it out and, ugh, and I'm there twisting myself into knots and making myself feel horrible. And then I go to the Discord, and everyone's like, "Oh, that sounded a bit janky. Oh, well, I'm sure they'll sort it out." [laughs] It's just like, it's absolutely fine.

+ +

So taking pressure off of yourself, I think, is something that I think is really important if you're trying to pursue, especially if you're trying to start out in pursuit of something like this because, yeah, it's super easy to drown yourself [laughs] in all of the kind of stress and anxiety about putting content out.

+ +

CHAD: You mentioned ads, and you mentioned Patreon. I think it was...was it last year that you joined a podcast network?

+ +

JASPER: Ooh, it would have been a year before.

+ +

CHAD: A year.

+ +

JASPER: So I've been with Headgum, I think, for nearly two years now.

+ +

CHAD: Wow. What sort of prompted that, and what does being part of a network give you as a podcast?

+ +

JASPER: Hell yeah. Joining a network ostensibly is just like joining a kind of family of other shows. I guess the closest equivalent really is sort of having your show picked up by Netflix or a broadcaster or something like that. It's sort of like you're bringing your show to that family. And then the most common thing...every network is obviously slightly different and will have different kinds of support structures that they offer certain shows depending on the money they generate, all that kind of thing.

+ +

But the most common one is effectively; you are now in a group that can all support each other and can all benefit each other by doing ad swaps because ad swaps typically is the absolute best way to improve podcast performance, mostly just because the user journey is super simple. It's like, hey, do you like the sound of this podcast? Well, the link to it is in your description. You have to click twice. You have to go into the description, click on that link, and then hit subscribe, and you're done. That's all you have to do, and it will be there. And you know it'll automatically tee up in your feed and all that kind of stuff.

+ +

So things like pod swaps and everything like that are by far the most effective for spreading the word about your show. And it also just helps you really hit specific target audiences where you go; we have great metrics that we can see of like, the average age of our listeners, how they identify gender-wise, music they listen to typically, what the average Three Black Halflings listens to. I think when you roll all of that information together as a part of a network, you have a huge bank of data, which they can then use to kind of market you in the best way and push you out in the best way.

+ +

And then, on top of that, most networks will have some sort of ad revenue like sort of system or tech, I guess, is probably the best way of putting it. And certainly, for some networks, they almost run like tech companies, how I imagine tech companies run. You're probably about to tell me, "A lot better." [laughs]

+ +

CHAD: Don't worry about it. [laughs].

+ +

JASPER: But, for instance, Headgum has Gumball. So Gumball is their ad sales sort of site, which has software which allows you to basically...everyone can go, and you can book ads just by looking at the podcast, seeing how many downloads it has; again, it has a breakdown of demographics and things like that that you can look at to see if that will marry up with whatever product you're pushing out. And then that will automatically set up a prompt for me to then read the script, upload it, and then that will put a dynamic ad in the middle of an episode, however many episodes until a certain amount of impressions are delivered.

+ +

So, again, that will be very unique and different depending on which network you join. But ostensibly, I'd say those are the two main things is pooling of resources amongst a family of different podcasts and then some sort of promise of ad revenue or ad sales. Most of them also have an ad sales team where they'll go and hunt out more specific spots for your show.

+ +

So, for instance, we just got sponsored by, I think it was Penguin or maybe Random House. Actually, maybe it's Random House who are publishing three little additional books to go in and around the Dungeons & Dragons movie. So we just did a little ad for them. And that was, again, the sales team kind of going out and being like, oh, we can see that you're looking for advertising places. Why don't you come and advertise on this Dungeons & Dragons podcast? [laughs] So yeah, stuff like that, I think.

+ +

Those were, I'd say, the main areas, and then it'll kind of depend...some podcast networks will help with editing. They'll have almost like a house style. So they'll sort of...they'll say, oh, we'll do the editing for you because we want to marry up all the shows so that they have a similar sound

+ +

CHAD: Is Headgum doing some editing for you and not on other episodes, or…?

+ +

JASPER: No. Headgum pretty much does...one of the best things [laughs] about it is we have an incredible sound designer; shout out to Daniel. He's actually one of the sound designers of God of War, if you can believe that.

+ +

CHAD: [laughs]

+ +

JASPER: He's won several awards for sound design. He basically has almost like a little side hustle, which is him and a group of his friends who do podcast editing for Headgum. He does our main shows and our actual play shows. They were like, "Oh yeah, they can help you out with your actual play shows." And then me, as the incredibly stressed-out producer that was also having to listen to multiple hours of my own voice a week, went, "What about the main show as well?"

+ +

CHAD: [laughs]

+ +

JASPER: And they were like, "Yeah, fine." [laughter] I was like, "Thank you," [laughs] because I can't bear listening to myself. I don't mind editing, and I'm not bad at it. But listening to my own voice is not on my list of to-dos. [laughs]

+ +

CHAD: It sounds like, overall, that being part of a network has been positive for you.

+ +

JASPER: Yeah, hugely.

+ +

CHAD: That's awesome.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

CHAD: Let's talk about...I'm making the assumption...I didn't dwell too much at the beginning of the episode that people understand what Dungeons & Dragons is, but maybe that's too big of an assumption. But it just seems so much more popular now [laughs] than it ever had before. So I feel like I can at least say Dungeons & Dragons to people, and people are like, even if I don't actually know what it's like to play, I know what it is, at least now. [laughs]

+ +

JASPER: Yeah, yeah, you got an idea of what it is. Yeah, for sure. [laughs]

+ +

CHAD: But let's maybe, at this point, take a little bit of a step back. And Dungeons & Dragons is more popular than it has ever been before. I think that that's really exciting for creators like you because it must feel like there's more opportunity than ever.

+ +

JASPER: Yes, yeah, absolutely. And I think that...so this actually, I think really ties into something that I've been doing a little bit of research on, which is...I can't say too much at this point, but I'm putting together a convention. Part of the idea behind this convention was that I've noticed there's a really big trend towards experience-based entertainment. We love movies. We love going out to bowling, all that kind of stuff. But real full immersion-based experiences, I think, are...post-lockdown, everyone's like, yes, give me all of that. I've been cooped up in a house. I want to be whisked away as far away as possible.

+ +

And so I do think that is part of the reason why Dungeons & Dragons has started to become even organically more and more popular. Because I just think the idea that instead of, I don't know, just sitting around on a Friday with some friends talking, or just watching a movie, or whatever it may be, that you can kind of with your friends go off and take part in something that feels epic and larger than life and really allows you to abandon for just a couple of hours some of the strains and pressures on your life.

+ +

I think, again, post-lockdown, that just feels like such an appetizing thing [laughs] to be able to do. And I just think with then the general acceptance of nerdiness as mainstream culture; people are just a lot more willing to be like, well, if I'm going to watch a movie with a dude who has a suit made entirely of iron and says really corny lines and shoots laser beams out of his chest, I probably could be okay with pretending to be a goblin for half an hour.

+ +

CHAD: [laughs]

+ +

JASPER: Whereas I think before, people would have been really like, no, no, no, we don't do that. I only watch, I don't know, Kubrick movies or something. Do you know what I mean?

+ +

CHAD: Yeah.

+ +

JASPER: Like, that's their form of entertainment.

+ +

CHAD: Yeah, that trend really resonates with me. Even before the pandemic, escape rooms and that kind of thing were becoming really popular.

+ +

JASPER: Yes.

+ +

CHAD: I mean, there are escape rooms everywhere now. [laughs]

+ +

JASPER: One of the things that I found out as I was coming up with the idea for this convention...I was talking to a buddy of mine, and he basically owns an event space, which has a cinema in it, and it also has a little theater. And he ran over; I think it was last summer, a "Guardians of the Galaxy" themed kind of experience where you walked around, and you got to meet some of the characters and stuff like that. And then next door in that building, they were showing the "Thor: Love and Thunder" movie.

+ +

And despite the fact that the experience was three times as expensive as the "Thor: Love and Thunder" movie at the cinema, that experience sold out almost instantly. And the "Thor: Love and Thunder" movie was struggling to get people on the seats; you know what I mean? But I was like, but "Thor: Love and Thunder" is a Guardians film, you know what I mean? All of them are there. It's ostensibly a "Guardians of the Galaxy" movie, and yet people are going to see a "Guardians of the Galaxy" experience, which I don't even know if it was like an official thing...rather than seeing the movie of it.

+ +

So I just think, yeah, like you said, this trend for escape rooms and all that kind of stuff just really resonated with me that I was like, yeah, that's...like, if I had to choose, if I was in a privileged position and could afford to go to that thing, I'd be like, pssh, yeah, I'd probably go to the "Guardians of the Galaxy" experience rather than just, eh, I don't have to watch the film. I could probably get it on Disney Plus in like two weeks, so...[laughs]

+ +

CHAD: Yeah. Have you ever been to a secret cinema in London?

+ +

JASPER: Yes. I did "Top Gun: Maverick" Up here in Manchester.

+ +

CHAD: [laughs] I went to the "Star Wars" one a few years ago.

+ +

JASPER: Nice. How was that?

+ +

CHAD: I guess, actually, it would have been five years ago. It was amazing. So for people who don't know, secret cinema is you're ostensibly going to see a movie, [laughs] but they build up an entire experience with improv actors themed to the movie that you're seeing, and you don't know where it is. It's technically a secret. They send you the location of it. You go there, and you're whisked away into the world of the movie.

+ +

JASPER: Yeah, I did a "28 Days Later" one. [laughter] Yeah, that was one...

+ +

CHAD: Horrifying.

+ +

JASPER: Yeah, that one was a little much, honestly. [laughs] I was like, I love this movie, but I don't feel safe sat in this cinema [laughs] because I've just walked through three fields filled with zombies and I ran for half of it. [laughs] So, I don't know, I was like, my heart was still racing as I sat down to watch the movie, which I think in many ways, did enhance the experience because I was sort of looking over my shoulder for half of it. [laughs]

+ +

CHAD: And when people who haven't ever actually seen Dungeons & Dragons played before, I often describe it as we're just telling a story together. Or maybe if they're a little less intimidated by improv because some people are into it, it's like an improv show where you can basically do anything you want or say what you want to do. And then you roll the dice to see whether it actually happens or not. And that's really at the base level all it is.

+ +

JASPER: Yeah, yeah, absolutely. [laughs]

+ +

CHAD: And I think you're right; people are more open to that idea of an experience or a game like that than they ever have been before.

+ +

JASPER: Yeah, for sure. There are so many things that you can kind of fall back on if you're not someone who is super comfortable with improvising or whatever. And I think that's what the game provides is it provides enough structure for you to then just kind of, honestly, because, you know, you do just kind of forget that you're doing it really after about 10 minutes of slight awkwardness when you start with a new group because the game provides you with almost like the fuel. You'll be like, oh, I don't know if I can do this or whatever. And it's like, okay, just go ahead and roll me a d20. And then you roll in that 20, and everyone loses their minds around the table.

+ +

CHAD: [chuckles]

+ +

JASPER: And suddenly you're like, okay, I'm in this. I'm the barbarian, and I'm getting angry. And I run in there, and I kick the door down, you know what I mean? And suddenly, you're sat there watching this person who was super nervous five seconds ago stood up on their feet screaming at me as the DM telling me how they eviscerate all these bad guys. So yeah, definitely, the game provides a very good structure for that.

+ +

CHAD: With this...you mentioned building this experience for a convention. Do you want to talk more about that?

+ +

JASPER: Yes, I can talk about it in very broad terms. I just can't go into the specifics of when, and the whos, and stuff like that. But ostensibly, the idea was to do a...I got really interested by this idea of reclaiming fantasy. It was kind of like this thing that kept going around in my head. And I was like; I wonder if there's a way that we could see our...again, specifically geared towards minority groups. It's what I know well and a community that I want to continue to serve.

+ +

And I was like; I wonder if we can create a space where it's specifically for them, explicitly for them in the sense that I think there are a lot of spaces that are explicitly for non-minority groups, you know what I mean? I think a lot of the traditional conventions typically are those things. But I think we get very afraid of creating something where we...people with the purse strings usually go, oh no, you can't exclude people, and I'm like, we're not excluding people. We're just making it very specifically for someone else.

+ +

And a lot of it was...it then came from the idea of seeing "The Rings of Power" trailer get released. And then the thing that's trending on Twitter is like; there were no black elves, not yes, we've got a black elf, you know what I mean? And I suddenly was like, I really want us to have a space where we can be celebrated in fantasy, et cetera, without having to have that caveated as like seeing it as some sort of diversity hire or whatever.

+ +

Anyway, this snowballed through going to things like D&D in a Castle and combining it with this idea of reclaiming fantasy of, like, what if we did it inside of like a stately home or a castle? What if we made this event and we really made it that you as a minority can be there and celebrated in the space where you've got, like, Baron, what's his name, on the wall?

+ +

CHAD: [laughs]

+ +

JASPER: And it's this White dude from 500 years ago, do you know what I mean? And it's like, I just really loved the idea of a room full of minorities really feeling welcomed and like they were a part of this space, and just realizing minorities we've been around forever, you know what I mean? [laughs] There's never been a point in human history where people with Brown skin haven't been here. We've always been here.

+ +

So I guess it was just about really realizing that when we sat there watching, I don't know, Pirates of the Caribbean, and there's like two Black people in the swamp. It's like, no, no, no, no, we would have been everywhere, [laughs] do you know what I mean? We would have been everywhere. And we can be celebrated in these spaces too. These don't have to just be White spaces, and they don't just have to be for a very specific group that they have been traditionally for in the past. [laughs] And yeah, the reaction to this sort of pitch, if you will, was overwhelmingly positive.

+ +

CHAD: That's good.

+ +

JASPER: And it really took me by surprise, actually, because I was sort of thinking, yeah, I'm really sticking it to them with this pitch.

+ +

CHAD: [laughs]

+ +

JASPER: And then everyone was like, "Yeah, we love it." And I was like, oh, right.

+ +

CHAD: [laughs]

+ +

JASPER: Okay, yeah. [laughs] I was sort of doing that, and I had to climb down a little bit and be like, okay, awesome. Let's talk about it. What I think is really exciting about that it's just that I really think that conventions and everything can do more in terms of delivering experience. Like myself and my fiancée went to Comic-Con a couple of years ago. And I remember her feeling like, oh, it was just a little bit flat. And it was just sort of...I thought that there'd be more kind of grandeur to it, almost like there'd be more...it was just other than people cosplaying; there wasn't a lot of theater to the whole thing.

+ +

It was just like in these massive warehouses, and add a little bit of that theater in, have some of those actors, have some of the music and the sound and everything, really give people a place to go and explore and enjoy exploring. And I kind of keep thinking in my head it's like LARP lite, you know what I mean?

+ +

CHAD: Yeah.

+ +

JASPER: It's like LARP still with the kind of commercial interaction that you can still go and meet your favorite people. You can still get signings. You can still get previews of things. You can still buy things that you've been wanting to buy all year and that you can only get when you go to a certain convention, and all of the kind of normal convention tropes but really just explicitly labeling it on the bottle: this is for minority groups. Because I honestly think if we explicitly label it like that as well, we'll start to get away from a lot of the things that have plagued conventions for far too long when it comes to making people feel comfortable in those spaces.

+ +

And quite often, my biggest tip when it comes to diversity and inclusion with companies as well it's just like, put it on the bowl. Like, if you really believe it, have it front and center. Don't tuck it away in like a D&I bit on your website. Have it there so that everyone can see it. Everyone knows when they come to work with you; this is what you stand for. This is what you believe in, things like that, so...

+ +

CHAD: That sounds awesome. And it's a really good illustration of the idea which we've talked about on the show in previous episodes is that when you are used to being in the majority all the time, and that is the default, when something is being done that's different than that, it feels like you're losing something. It feels like you're under attack. That's a total natural feeling.

+ +

JASPER: Yes, yes.

+ +

CHAD: So it's like, that sounds like a great experience. I would love to experience that, and I'm being excluded because I'm White; that's not fair. But that's coming from a position of you've been in those safe spaces for yourself in a world that's been entirely tailored for you. So you haven't realized that you've had that all along.

+ +

JASPER: Yeah, absolutely. And the beauty of it is..., and this is where it's even better for people in the majority, which is that we have zero intention of making an unsafe space for anyone because that would be wild. So even the spaces that we create for minorities explicitly will still be safe for you as well, you know what I mean?

+ +

But I think, like you said, it's that reaction, which, again, I get it completely because, as I mentioned earlier, I was there. I've been there. I've been in a space where I suddenly go, oh, I'm part of the problem, and it feels horrible. Like, it's not nice, and it's a really challenging thing, which you have to be comfortable with, and I think everyone should be comfortable with it.

+ +

Whether you're a minority or not, everyone has blind spots. Everyone has biases. It's a huge part of human interaction. And honestly, in a modern world with the way that social media is, I don't think you can live without biases and without assumptions because you see new people, thousands of new people every day if you want to just by scrolling on your Twitter feed. So to be in this zen place of just like, I will accept everyone only on their merits, and I will not judge anyone would be impossible and maddening, I think.

+ +

So it's a perfectly normal thing to exist with those biases. The thing that we have to get better at is going, cool; I've got those biases. Now it's time to let them slide, like, to move them over there and to not get defensive if someone calls them out. Like, that's the trick. That's the magic trick. That's pulling the rabbit out of the hat. That's what you got to get comfortable with.

+ +

CHAD: Yeah, awesome. Well, I really appreciate the conversation, and I really appreciate you taking the time. I know that you get married in less than a week from now.

+ +

JASPER: I do. I do get married --

+ +

CHAD: So congratulations in advance.

+ +

JASPER: Thank you so much. Thank you.

+ +

CHAD: If we could just take a few more minutes at the end to maybe nerd out about the Dungeons & Dragons movie, which I know you went to the premiere for, and I just saw this weekend...

+ +

JASPER: Oh please, let's do. Absolutely.

+ +

CHAD: It was funny because I think you've said exactly how I left the movie feeling, which was they captured the spirit of what it's actually...like, it was just fun. And Dungeons & Dragons is fun in a way that is not like "Lord of the Rings" [laughs] or just super serious fantasy, right?

+ +

JASPER: Yeah, yeah. I can't even think of the last time we had a fantasy movie that was like, you know, other than, I don't know, "Your Highness" or something that was just like, I don't know, yeah, whatever that was, you know what I mean? Something that was like an actual movie and didn't take itself too seriously, yeah.

+ +

CHAD: Yeah, I'm so happy because you could have easily have seen it, like, no, we need to do something super serious and to compete against "Game of Thrones" and "Lord of the Rings" and all that stuff. And to feel like, you know, this was made by people who get it and represented what I love was really exciting.

+ +

JASPER: Yeah. And I think that what it did for me is I think it lays the groundwork for them to explore more serious places because now they will have that trust that they understand what it's like to be at the table and how to do that. And then I think this is where the real skill is going to come in for them to curate more of these which is like...that, I think, is the art of a really good DM. They can have you absolutely roaring with laughter one minute and then sobbing in like, you know, and it's like an hour's difference, [laughs] you know what I mean? Between the two places. And that's then the next step for these.

+ +

But I think this was absolutely the tone they needed to strike for this, especially for this first kind of outing. I think they really needed to say, hey, we get it. We understand what it's like, just displaying purely unhinged actions and things, which I think that's the bit that feels D&D for me is when a character...and I think I won't go into any spoilers, but I think you'll probably know the moment I'm describing when a very clear solution is laid out in front of you in big, green letters, for instance, and you choose to do something truly, truly unhinged and wild. Because that was what you decided you were going to do ahead of time.

+ +

It's such a D&D thing to do. [laughs] And I loved that. It was one of my favorite moments in the movie. And I just thought that perfectly encapsulates the nature of it and the thing that you don't get to see in "Game of Thrones" or whatever because you don't get the Nat 1s or the Nat 20s, I think in the "Game of Thrones." Everything's like 7 to 12; you know what I mean?

+ +

CHAD: [laughs] Right. Right.

+ +

JASPER: Everyone is relatively skilled, so they can't just, like, you know what I mean? You can't have the mountain versus the Viper, and the mountain just trips over a rock and brains himself on the floor.

+ +

CHAD: [laughs] Right.

+ +

JASPER: You know what I mean? Because that would be a Nat 1, but that would be ridiculous because the mountain is an incredibly skilled fighter, and therefore, it wouldn't work like that.

+ +

CHAD: Yeah, yeah. I found myself grinning throughout, aside from the moments where I was laughing, just like, oh, that's...yes.

+ +

JASPER: [laughs]

+ +

CHAD: Just the whole thing about planning and how he's a planner.

+ +

JASPER: Yes. [laughs]

+ +

CHAD: Oh, that is so D&D. And just at the end, the way that that battle lays out, I just feel like it just captures everyone's act in the six-second increments in a D&D battle. And everything's happening all at once, and that's what that battle was like at the end.

+ +

JASPER: Yeah. And it also just props for like a really good magic fight.

+ +

CHAD: [laughs] Right.

+ +

JASPER: Like, I don't even know what the word is, but we have been convinced for years that Harry Potter had good magic, but no, he doesn't.

+ +

CHAD: [laughs]

+ +

JASPER: Harry Potter has wand-fu, and it's terrible. It's like; it's not particularly pleasing. It's basically the same as "Star Wars." It's just like a little laser pistol type, piu-piu-piu.

+ +

CHAD: [laughs]

+ +

JASPER: That's effectively what Harry Potter becomes. And then to see Bigby's Hand and spells like this be used in the ways, like, it was just so fun. And also, it really teaches the importance of flavoring your attacks and how much life you can bring to a game, to anything, by just adding that little bit more, like, that little bit of extra sauce on top.

+ +

I think Holger the Barbarian does a perfect job of this in the movie where she's always using improvised weapons, and the way that she fights it's, oh, it's very, very pleasing to watch. And you're sat there going, yeah man, barbarians are so cool. But half the time when you're in a game, you'll just be like, yeah, I run up, and I attack with my axe. It's like, no, give me more, give me more. Tell me how and why and stuff like that. So I agree; I think they did a great job. And I was also just grinning from ear to ear [laughs] during most of it.

+ +

CHAD: I feel like I could talk to you all day.

+ +

JASPER: [laughs]

+ +

CHAD: But I really appreciate it. If folks want to either get in touch with you, we mentioned at the top of the show you are a Game Master for hire, and you do games remotely, right?

+ +

JASPER: Yes, I do. I do. I do.

+ +

CHAD: So where are all the places that people can find you, get in touch with you, book you, all that stuff?

+ +

JASPER: Heck yeah. If anyone knows about my GMing for hire, it's you. [laughter] You had me DM for you for, in total, like, 29 hours in the space of a week. [laughs]

+ +

CHAD: Yeah. So we brought Jasper and we had the thoughtbot summit where we got the company together in person and so Jasper came and he DMed two sessions with two different groups for us, which was awesome. And then I went to D&D in a Castle, which you mentioned earlier in the show. It's where you go to a castle in the UK and play D&D for three and a half days straight basically. It was an amazing experience and Jasper was an incredible DM.

+ +

JASPER: Thank you. And if anyone is interested in hiring me as a DM, like I said, I do consultancy, whether it be D&I consultancy or podcast to help you grow podcasts and things like that, or even just get started. Most of that information is on my website which is jasperwcartwright.com. You can find me on all social medias. I'm usually pretty good at responding to people in there, and that is just @JW_Cartwright on all of my social media. So yeah, go follow me, and I've got a bunch of really exciting stuff coming up, so it's a good time to follow me. [laughs]

+ +

CHAD: Awesome.

+ +

You can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon @cpytel@thoughtbot.social.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Jasper (William) Cartwright.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Pv5B4ikZ + + ]]> + + Chad Pytel + Jasper (William) Cartwright + + + 473: Noula with Noelle Acosta + https://podcast.thoughtbot.com/473 + 488154ae-cb8b-4e1d-909e-9110b5bcbf46 + Thu, 04 May 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Noelle Acosta is Founder and CEO of Noula Health, a data-driven platform that uses personalized hormonal health data to deliver tailored care. + +Victoria talks to Noelle about helping patients with uteruses to better understand their bodies by providing them with hormonal health data that's unique to them and providing them with individualized care they deserve at their fingertips through a virtual app. + 38:42 + no + + + Noelle Acosta is Founder and CEO of Noula Health, a data-driven platform that uses personalized hormonal health data to deliver tailored care. +Victoria talks to Noelle about helping patients with uteruses to better understand their bodies by providing them with hormonal health data that's unique to them and providing them with individualized care they deserve at their fingertips through a virtual app. +Noula (https://noula.com/) +Follow Noula on LinkedIn (https://www.linkedin.com/company/noula-health/) or Twitter (https://twitter.com/noulahealth). +Follow Noelle Acosta on LinkedIn (https://www.linkedin.com/in/noelle-acosta/) or Twitter (https://twitter.com/noelleacoss). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Noelle Acosta, Founder and CEO of Noula Health, a data-driven platform that uses personalized hormonal health data to deliver tailored care. Noelle, thank you for joining me. +NOELLE: Thank you so much for having me, Victoria. It's a pleasure to be here. +VICTORIA: Wonderful. I'm excited to learn more about your product today that you're building. Can you just tell me a little bit more about it? +NOELLE: Yeah, absolutely. Well, I feel like, [chuckles] one, you could work here. You did a phenomenal job of sharing what Noula is. But here at Noula, we are a virtual care platform that really empowers women and patients with uteruses to better understand their bodies by providing them with hormonal health data that's unique to them. Based on that information, we're able to provide them with the individualized, tailored care that they deserve at their fingertips through a virtual app. +VICTORIA: Wonderful. And I'm wondering what led you to think I need to make this company. What happened in your life where you decided this needs to exist in the world? +NOELLE: Really it stems from my own personal brush with an undiagnosed chronic condition where I truly was the one in five women who felt dismissed, denied, and ignored in the traditional healthcare settings. And that is really something that's actually unified us all as a team here at Noula. We have the shared frustration in terms of the gaps that we experienced overall; not one, two of our health journeys looked alike. +And so during this time, I found myself really just kind of banging my head against a wall where I had these ongoing symptoms that disrupted every aspect of my life, not just my physical health, but it became really very much an emotional roller coaster as well. Because despite having access to care and wonderful employer-sponsored health insurance, I was finding that my doctors were essentially brushing me off, attributing it to stress. +And it really led to me kind of just having this inner monologue and questioning myself as, like, is this in my head? Maybe it is stress-related. This doesn't feel normal. Should this be normal? And so I, just like 70% of millennials, turned to Google as my medical companion. I lost trust in healthcare settings and just turned to do research around what could be possibly causing the symptoms in my overall health. And I just refused to believe that this was my sense of normalcy. +And through my own research, I started finding things like my ethnicity and my environment could have an impact in the symptoms that I was experiencing. I was dealing with chronic pelvic pain, irregular periods to the point where I was actually menstruating for seven months straight. I had horrible migraines. And so I just really turned to these medical journals to try to figure out and uncover what my body was telling me. +And so, based on that research, I finally went back to the doctor demanding an ultrasound, where they ended up finding over 40 abnormal follicles and cysts on my ovaries. And even at that point, my treatment plan was a Band-Aid fix. And so, ultimately, I really felt like the system fundamentally failed me. This Band-Aid fix was essentially, hey, we'll put back your former birth control method and call us when you're ready to have a baby, and we'll figure it out then. And so, to this day, I actually haven't received any additional care, guidance from any clinician despite being in and out of the doctor's office with the symptoms. +And so I ended up being diagnosed with a condition called PCOS. Again, from my own research, I learned that Mexican women with PCOS, so yours truly, we have the most severe phenotype that puts us at the highest risk for other complications that are beyond just reproductive health. It increases my risk for diabetes. It increases my risk for hypertension. And these are ultimately very costly to my health. And I was just frustrated. I thought, why am I learning about this through my own research versus the doctor's office, where it really felt like a one size fits all approach to care? +And so, based on my experience, I started talking to more and more women. And I found that I wasn't alone with this shared frustration. We see that 80% of people who menstruate suffer from hormonal imbalances. And more often than not, women are juggling with more than two chronic conditions at a time. And so it's truly something that I felt as a patient that we were missing to feel empowered in our health and actually feel seen and heard. And then, when I actually spoke to clinicians as well, they felt that they weren't set up to care for their patients in the way that they wanted to care for them. +VICTORIA: And I'm wondering how those women and the people you talked to started to inform the roadmap for the product that you were going to build. +NOELLE: Yeah, yeah, absolutely. I mean, truly, the voice of those members, and these patients are the center of our lighthouse in terms of how we shape our product roadmap ahead. And so, ultimately, it really came down to us initially doing customer discovery. So I was really surprised to see how many people were willing to talk about their experiences navigating their health as a woman or a person with a uterus. And that was really telling in itself because I've heard from folks where they had to pay others with gift cards to have this conversation about how they might navigate certain workflows as it might relate to the products they're building. But naturally, these folks wanted to talk about their experiences. +So we kind of tackled this in a couple of parts, one, I was going out into my own network, reaching out to friends of friends, posting in Nextdoor Facebook groups, really asking for 15 minutes of people's times to learn about their experience. And within two weeks, I had almost 100 customer discovery calls booked where these women were wanting to talk about their frustration and what they wished they had in terms of the care that they wanted. +And so that was point A, like, okay, I think we're onto something. Our gaps in our experiences are shared across the board. And this is the pain that not only I experienced, or the Noula team has experienced, but that hundreds of women have experienced. The other piece, too, is, believe it or not, you know, we're constantly doing customer discovery as an early-stage company. But when we launched our beta, we launched with an initial hypothesis. But we saw that what our members were coming in for more aligns with their hormone health than what we initially thought, where we thought majority of folks would be coming to us at a family building stage. +And then even [laughs] truly through social media, our TikTok channel alone when we lead with these persona stories it helps drive this just natural virality to it. And daily, we have folks reaching out to us asking if what they're experiencing is normal or what they should do. And so they're coming to us because we really fill this very prevalent gap in care today. +VICTORIA: It must be really reassuring on a personal level and also on a business level that you found a problem that you can really help and make a difference with. +NOELLE: Yeah, absolutely. I mean, it's frustrating that we are all bonded and unified by this experience. But ultimately, we'll continue to use the voice of our members as our guiding light to shape our roadmap ahead. And actually, that's what you see today with Noula. We took the learnings from the beta. We took the conversations that we've had with so many members and just women and folks outside of Noula to really shape what you see today. +VICTORIA: That's wonderful. And you already mentioned one surprise that you found in your customer discovery process. I wonder if you could even tell me a little bit more about any hypothesis you had that you found from research; the outcome was quite different, and that changed your business strategy. +NOELLE: Yeah, yeah, absolutely. So we have always seen ourselves as truly being this co-piloted partner for women in their healthcare journeys for life. But when initially launching our beta, we thought our niche today is going to be folks navigating family planning, so people who are looking to start a family in the near future, actively trying to conceive, pregnant, or recently postpartum. So we built a beta around that. And it was very low-code. This is before I had any technical talent [chuckles] on our team and essentially no money. +And so, we built this low-code/no-code beta and launched it. We brought on about 100 folks to this closed beta. And with that, we built the product with that hypothesis in mind that we're going to be targeting specific stages. But what ultimately happened is as we were onboarding the 100 users, we found over...with each onboarded user, we started to see the scale tip where all of a sudden, 80% of those users very much had a story that mirrored my own experience with health. +They were coming to us because they suspected that they had a hormonal imbalance or these unexplained symptoms that they didn't know what was causing them. Several of them had been diagnosed with conditions like PCOS, endometriosis, or fibroids. Many of them were dealing with unexplained period pain and irregular menstruation. And so we started to scratch our heads to be like, oh, wow. Okay, so these folks are actually coming to us for a different reason than we had [chuckles] initially anticipated. +They're using the product differently. And also, they are far more engaged than our initial hypothesized users, which were pregnant people. And so while we have been able to really create a product that is able to adapt with these users over time, we found that that messaging and creation of a safe space for those users was incredibly important, and we wanted to lean into that. +VICTORIA: That's really cool. And maybe talk more about creating that safe space in dealing with healthcare data. Were there any special considerations you had to bring into building your tech stack with those really delicate elements? +NOELLE: Yeah, yeah. I mean, ultimately, safety and security of their data and honoring that privacy. We will never sell any data whatsoever. And I know that was a concern for many and still is since we've seen in the news this has been happening with other apps and stuff where they're selling user health data to social media sites. So honoring and protecting that privacy, first and foremost. The other piece is we had to also empower our care team to support our members in the best way that they can with the information that they had about their unique health. +And so, unfortunately, our members were coming to us at such an emotionally turmoil time in their lives that they wanted answers. They were frustrated. They were saying, "Why is this happening to me?" We had to really ensure that we could be that empathetic ally for them, empower them with information, and really arm them with tools to use inside and outside of the clinic to get the answers that they deserve. +VICTORIA: Right, and I see that. So on your site, there's a quiz you can take about your symptoms, and then you can sign up for what's ultimately going to be a home test kit. Is that right? +NOELLE: Yes, yes. So users are able to sign up for Noula at no cost to you. So you can start free tracking your symptoms, and these symptom trackers are going to be customized to you. So based on... similar to the quiz that you mentioned, you'll be able to answer questions about what you're experiencing, what your goals are. And Noula will make recommendations of what to track within the app itself. You can then track your symptoms that you select over time and get this customized snapshot to build this true picture of your health. +You can then continue to add on to that snapshot of your health through that home hormone test. So you don't necessarily need to purchase the test if you don't want to. But you have the ability to test your hormones to get a clearer picture of your baseline hormonal health. And we're able to really help arm you with that information about your body. +And then, from there, beyond just that information from that data set, you have access to empathetic coaching from medical experts. All of our care coaches are registered nurses. So you do have that expert at your fingertips who's there to really steer and guide you every step of the way. And that was something that I actually felt was missing from my own experience when navigating my own symptoms pre-Noula. +I found myself running these tests [chuckles] on my own, like ordering tests online trying to figure out what was going on. And just kind of hit this wall where I said to myself, I don't know how to interpret these. I don't know what to do with these. I don't know how to talk to my doctor about this. What do I do? +VICTORIA: That's so interesting. And I heard you mentioned empathy a few times and how important that is. Would you say that's one of your core values that you bring into founding a company like this? +NOELLE: Oh yeah, absolutely, absolutely. So I actually studied to become a doula. And so some of the pillars that we were trained in were really supporting our clients in these four primary pillars: ensuring that we can support them with physical support, emotional support, informational support, and advocacy. So really, those four pillars together have really steered us to create this foundation of empathetic care. And so that is truly integral to our brand and who we are, how we deliver that care, and also in such an inclusive and culturally competent way. +VICTORIA: It sounds really important what you mentioned; building an app requires a lot of trust to be able to give you your data and trust that the results that you're getting are helpful. So I really love that that's a part of your core value that you bring to the organization too. +NOELLE: Yeah, I think it was something that was really important to us from the very beginning, especially because we are a BIPOC and queer-co-founded company. It's rare that we see ourselves in the ecosystem, not just as founders [chuckles] but even just in how care is designed for us. So we wanted to ensure that we were creating this space where everyone can see themselves. And it's been so reassuring to hear from members and even just folks who find Noula on their own that they finally feel like they're seen and heard as an individual with Noula. +VICTORIA: Well, that might be the answer to my next question, which is what keeps you going, and what's the wind in your sails that keeps you pressing forward with this? +NOELLE: [chuckles] It's definitely that I think being able to hear from our members how Noula has helped change their life, even it is just a little bit where they feel more confident, where they feel supported, and they don't feel alone means everything to us. And the other piece is I feel incredibly proud when members have actually tuned in to listen to their bodies. And despite their experience feeling brushed off in the traditional healthcare setting, they really listen to themselves and turn to Noula. +And there have been cases where we help support these folks to the point where because of Noula (One member is actually popping up in my head specifically.), they were able to find that they had a hereditary thyroid condition before it worsened because of Noula. And so that in itself was so powerful because their experience in the clinic was very much more like, well, no wonder you're fatigued and no wonder you have brain fog. You have a baby; what do you expect? +VICTORIA: Oh, I love that; what a powerful message. And I think that speaks to the power of having systems in place that are designed with those people in mind. +NOELLE: 100% yes. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint +VICTORIA: So what does success look like in the immediate future and in the longer term for Noula? +NOELLE: I think today, our success is very much qualitative. I think with health, especially digital health, it's a long game. And so today, we're measuring success by those member stories, by hearing from them that, again, this is a place where they finally feel empowered in their health. They have the tools that they need to unlock the best version of themselves so that they can get the care that they envision on their terms. So really, just through that qualitative piece. +Patient satisfaction is another huge factor as well. We supercharge our algorithm based on the identified and pooled hormonal health data so that we can continue providing tailored recommendations that are personalized to each user. So in my example, my Noula experience might say, okay, we know that Noelle is a Latina woman who has PCOS. Other people who might have had similar symptoms to her have found these recommendations or tracking these symptoms to be really helpful for them, and so that's something that I would try. And so really just, again, creating a space where you're not alone is huge. And so that's where we really lean into the qualitative piece. +And as we grow, we also incorporate the quantitative success metrics as well. So how are we measuring impact in terms of health outcomes so that we can also just inform the system to deliver better care? Because, I mean, there's just so much unknown about the female body specifically. It wasn't until 1993 that women were even required to be a part of a clinical study. So there's just a lot of gray area that needs to be addressed to deliver better health outcomes overall, especially when health outcomes amongst women in the U.S. is so poor. +VICTORIA: And as a woman in the U.S. who has hormones, I 100% get the value and the potential for an app like this. Have you had that same positive reaction from investors or from other people who are looking to join your group? +NOELLE: Yeah, yeah, absolutely. I mean, the investors who really understand it and get it, unfortunately, do because either they or someone they loved has been impacted by a hormonal imbalance or by being dismissed in the traditional healthcare settings. So similar to how the Noula team and our members have been unified by these experiences, we find that outside as well with investors. +What makes me really proud, too, is connecting with clinicians. Like, our Medical Director, Dr. Marieme Mbaye, who is a highly rated physician in New York City, turned away from practicing medicine to join Noula because she even felt like her hands were tied behind her back with the type of care she can deliver. And so it's always incredibly reassuring when we hear from clinicians that this is why care should be designed to really proactively look out for groups of people who are often overlooked, which, sadly, tend to be women and people of color. +VICTORIA: Right, almost like it was designed that way in the system. +[laughter] +NOELLE: Yep. +VICTORIA: That's great. I'm glad that other people are seeing that benefit. And what hurdles do you see on the road ahead for where you're going with Noula? +NOELLE: As we are bringing on members, the more that we've built this trust with our member base, the more they want from us [laughs] in terms of us truly just being their end-to-end care delivery partner, and we would love to get there. But as a very early-stage company, we have to build things quickly but one thing at a time. So oftentimes, I feel like, okay, we have this huge leap to make to deliver the care that our members are asking for, and so it's a blessing and a curse where they're like, "We love this so much. Can you be my doctor? I don't want to go to another doctor." Or, "Can I get this through you and only you, or do I need to go somewhere else?" +VICTORIA: Well, that must be a great feeling to have. But also staying focused, like you mentioned, would be a challenge, and being able to get done within your capabilities. But it's funny because I think there's a huge demand in this market [laughs] that we've had similar kind of demand for other women's health-focused products or people with uteruses too. Clearly, something is broken. [laughs] So you've got a lot of great work you want to get done. Is there anything really already planned in your roadmap that you're super excited about? +NOELLE: Yeah. And we'll be rolling out insurance-covered telehealth appointments very soon, so that's one thing that I'm particularly just incredibly excited about because I think it does...how we got to delivering that was through the feedback from our members. And so I think that, in turn, will allow us to take one step closer to truly being that healthcare delivery partner for all members on all those levels. Very, very excited about that because it very much aligns with our mission to deliver accessible and equitable care. +VICTORIA: Yeah, that's a huge capability, and especially considering in some areas, there just might not be access to doctors or hospitals that you can go to in person, so... +NOELLE: Yeah, yeah, absolutely. I mean, only 50% of U.S. counties have access to OBGYNs and with the average appointment length only being 15 minutes. Like, again, physicians have their hands tied behind their backs because that means per OBGYN, they're managing about 3,500 patients, which just isn't feasible or scalable. +VICTORIA: Wow. Yeah, that's a lot of patients. [laughs] Well, I want to go back to some folks that you mentioned earlier on your team and just tell me about how it all started coming together with building your team at Noula. +NOELLE: Yeah, yeah, absolutely. So my co-founder and CTO, her name is Suzie Grange. She is an absolutely wonderful, brilliant engineer. Her and I actually worked together at our previous employer company called Maven Clinic. So at Maven Clinic, I was responsible for helping lead sales and business development through some growth milestones. And Suzie was the founding engineer over at Maven. So she was there for the long haul, for over seven years. And so she had left Maven before I did. +And once I took the leap into building Noula full-time, her and I reconnected, and we welcomed her to the team as a co-founder and CTO last year, which has been so instrumental to how we've built our product to date. We actually [laughs] ran into fun challenges many startups will where we've had to recently rebuild our entire tech stack and truly couldn't have done this without her and our back-end engineer as well. And so she's just been incredible. +And then we also brought on our medical director, as I shared, Dr. Marieme Mbaye, who was a practicing OBGYN based out of Brooklyn, New York City. And she has also had experience advising for women's health startups like Natalist to Frame Fertility and others. +VICTORIA: Got it. So you found your technical co-founder, or you maybe already started together and then got the technical expertise there. You mentioned taking the leap to do Noula full-time. What was that decision like for you emotionally? +NOELLE: It was a really big decision, and it was also a very vulnerable decision on my part. And so I'm going to open up about this because I think it's important to also recognize that this is a scary decision for all founders to make. When I was dealing with these chronic symptoms, that was back in 2019, so this was before I joined Maven Clinic. And I knew I wanted to build something to change the system. But I thought the best way to ensure what I was going to build were to be successful was to contribute to a company, learn as much as I could, fail fast, fail forward. So I joined Maven. I was there for almost two years, and that experience alone was instrumental. +But ultimately, what really drove me to make the leap and place this blind faith in myself and just jump into this unknown abyss was after another health scare. I promise you I'm healthy. But I went through...in early 2021, I had a massive seizure in my sleep, and I was hospitalized where they thought I had a brain tumor. And I just remember sitting in the ambulance. And this was during COVID, so I had to go alone. I was hospitalized alone. +And I remember sitting in the ambulance, and I don't know why this sticks with me so much, but I remember seeing the light of the street lamp, and I was just looking at it. And I thought I'm not ready to leave the earth without making an impact here. And so I told myself, I was like, if I make it out of this alive, I'm going to do whatever it takes to change healthcare and make the impact that I want. And so I did just that. +I'm okay. I don't have a brain tumor, thank goodness. And I trusted myself trusted that the conversations that I had with friends, family, and other people who shared those experiences with me would serve as our lighthouse to building an incredibly impactful product that would reshape the future of health for good. +VICTORIA: Oh, that's incredible that you had that experience that made you think about what really mattered and what you wanted to do with the rest of your time. It sounds like you had friends and family to support you along the way with that decision, right? +NOELLE: Yeah. And a lot of them didn't get it. To this day, my mom's like, "Don't you want to go to med school or be a nurse?" [laughs] I'm like, "No." [laughs] But yes, absolutely had their support. +VICTORIA: Oh, that's wonderful. I mean, I can see that, even if you have a good idea that some people might be like, "Don't you need a job?" +[laughter] +NOELLE: Exactly. And that's exactly the kind of position I was in. I said, okay, I need to make a game plan. And when I quit Maven, I had joined an accelerator program called Visible Hands, which was designed by POC founders. And for three months, you got a small chunk of money. And I worked backwards, I said, okay, within this three-month period, I need to prove that Noula is a venture backable business. +And so I worked backwards with how much savings I had left to continue supporting myself. And that gave me till...so the program started in September, and I had basically saved enough money for myself through end of February, maybe end of March is stretching it, of 2022. And so, I worked backwards from that date and closed an oversubscribed pre-seed round in February. +VICTORIA: Wow. +NOELLE: So that was really...it was very challenging. I don't think I've...I worked harder in my life than I ever had before. And so yeah, that's really kind of where we're at today. And it made me one of less than 100 Latina women to ever raise a million dollars, which is wild. +VICTORIA: Awesome that you were able to do that, and sad that the number is so small. [laughs] +NOELLE: I know. And I did the math, and we said, okay, 0.4% of venture dollars go to Latina founders. I need to have 200 meetings just to get one yes. And so I was chasing as many meetings as I could and chasing nos as fast as I could because I thought the sooner I could get a no, the quicker I could move on to the next. +VICTORIA: So, really trying to weed out people who just weren't going to be a good fit. [laughs] +NOELLE: Right. +VICTORIA: That makes sense. But ultimately, you were able to find someone who aligned with you. Was there a checklist or some kind of way that you used to decide if those investors were going to be right for you? +NOELLE: Yeah, I think, ultimately, the connection to our mission. At the early stage, they're making a bet too on founder fit, and so I wanted them to, one understand and feel confident in myself as a founder. And so I wanted to see that on the call. And then two, I also wanted to ensure they understood that this was a problem. And so there were some investors where they didn't understand the problem or why anyone would need this. And some of them didn't understand things like what menstruation was, not even kidding. [laughs] +I didn't have any...at that point, I was like, I don't have a single check. I had to make the decision, like, this isn't going to be the right partner for me. And so those were kind of my two main criteria, like, do I believe they're going to be the right partner in helping us accelerate just my vision and supporting me as a founder? Do they believe in me and in our vision? And two, do they understand the problem and the impact? +VICTORIA: Right, that makes sense. So then that kind of empowers you to continue doing the work that you know you should be doing. +NOELLE: Right. +VICTORIA: Well, I wanted to ask you a little bit more about TikTok too, and how you used social media to raise your brand awareness. +NOELLE: [laughs] So, our TikTok strategy, I'm embarrassed at how long it took me to make our very first TikTok [laughs] because I probably spent way too much time trying to figure it out. But our TikTok strategy really aligns with our brand strategies. Our core pillars in terms of that really come down to leading with empathy, so showcasing real, raw, authentic stories from real people. So we can show, like, you are not alone in this. And then two, educational pieces as well. +So we have a series called Dear Noula where anyone can write in anonymous questions to Noula. And our medical director, Dr. Marieme Mbaye, will answer those on TikTok. And so, really, what's helped drive the virality in our TikTok strategy is the marriage of that approach where one of our most viral TikToks is one of me with my ultrasound behind me. And then another one that's very educational based around what your vaginal discharge might be telling you. And so there's that blended approach to just, again, showing those real stories with digestible educational bits of content has really helped us build that brand awareness and also just the trust in our brand as well. +VICTORIA: That's great. And I think that's something that a lot of startups might be thinking about marketing-wise. Like, how do they use those types of tools to really connect with people? And I like the approach that you've taken with being educational and with being very real, [laughs] which makes sense. Okay, so we asked about what your biggest challenges were on the horizon. What do you think are the biggest opportunities that you could potentially take on at Noula in the next six months to a year? +NOELLE: What I'm particularly very excited about with Noula is our ability to adapt with users over time. So what we often see with a lot of digital health solutions, especially in women's health, is they tend to be very stage-specific. You use this product for fertility-related stuff, this one for pregnancy-related stuff, this for postpartum-related stuff, or STIs, for example. So they tend to be very specific. +And what I'm particularly eager to showcase is truly how Noula is designed to adapt with those folks over time, so from menstruation through menopause. And the more that you use Noula, the longer you use Noula, the more customized insights you'll have about your unique body to inform providers to deliver that individualized care. So truly, the thing I'm looking forward to most is time, seeing how Noula can truly fit patients' lives versus the other way around. And also being in a position where our solution isn't tied to just a reproductive stage. It's truly encompassing our whole health beyond just reproductive organs but taking into account genetics, lifestyle, environment, stress, sleep, nutrition, et cetera. +VICTORIA: That's very cool. So kind of expanding into even more tailored patient data and services that you can provide over time. +NOELLE: Yeah, and, I mean, this is information that most people's doctors don't have access to. +VICTORIA: Yeah, I could see that. And, I mean, anyone who's used a menstrual tracking app you can predict things based on the longer time period you've been tracking it, right? +NOELLE: Exactly, exactly. +VICTORIA: That's very cool. I'm excited to see it come out. And I think by the time this podcast airs; you'll have launched a new product. Is that right? +NOELLE: Yeah. So by the time this podcast launches, we'll be completely launched. I will have the app and care coaching available for anyone to use, sign up for, and it's really, really exciting stuff on the horizon. +VICTORIA: That's super cool. Well, my last question for you is if you could go back in time to when you first started Noula, what advice would you give yourself? +NOELLE: I tend to be a perfectionist. So I'd say just ship faster; don't chase perfection because things are going to change. I learned that from the beta itself, where we spent time building this product that we wanted to be so perfect. And again, [chuckle] what we learned was that the initial cohort of users who we thought would be our biggest advocates and earliest adopters of Noula was not true. And so being okay with your first iteration as being imperfect is okay. Some of the best advice I actually got after we launched our beta was that if you're not embarrassed by your MVP, you launched too late. +VICTORIA: [laughs] That's really funny. It should be kind of awkward, right? +NOELLE: Yeah. Isn't that great? [laughs] +VICTORIA: That's really good. [laughs] +NOELLE: I wish I had heard this before. I [laughs] spent so much time trying to perfect this to the T. [laughs] +VICTORIA: I think we're going to maybe print out a banner that says that and hang it behind [laughter] our screens or something. Yeah, I love that. And I love just how much went into the customer discovery and how you were flexible to change your hypothesis for what was going to work for people based on that. +NOELLE: Yeah. And I think one thing that really helped, too, just honestly from my sales background, was I was very mindful of not leading a horse to water when doing customer discovery. So I think often we hear that, you know, we ask very pointed questions to try to lead folks to say, "Yes, I would use your product," or, "Yeah, that sounds useful." I purposely asked very open-ended questions like, "Walk me through your experience navigating your health," and just listened. +And that allowed me to find patterns across the number of conversations that I had that ultimately led us to build the beta in our product that you see today is through those very open-ended questions and hearing from users themselves as far as what they thought was missing versus me saying, "If we build this feature, would you use it?" +VICTORIA: That's very cool. And I learned a lot just from taking the quiz on your website. [laughs] +NOELLE: Oh, awesome. [laughs] +VICTORIA: So I'm really excited to see what you all come up with next. Are there any final takeaways or thoughts you want to leave for our listeners today? +NOELLE: We'd love to hear about your experience using Noula. So you can use Noula free for a limited time. We're offering 30 days of free care coaching for anyone that signs up and discounted access to the hormone testing. So just really excited to share with the world because it's about damn time we get the care that we deserve. +VICTORIA: Absolutely. Thank you so much for joining us today. +And you can subscribe to the show and find notes along with a complete transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Noelle Acosta is Founder and CEO of Noula Health, a data-driven platform that uses personalized hormonal health data to deliver tailored care.

+ +

Victoria talks to Noelle about helping patients with uteruses to better understand their bodies by providing them with hormonal health data that's unique to them and providing them with individualized care they deserve at their fingertips through a virtual app.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Noelle Acosta, Founder and CEO of Noula Health, a data-driven platform that uses personalized hormonal health data to deliver tailored care. Noelle, thank you for joining me.

+ +

NOELLE: Thank you so much for having me, Victoria. It's a pleasure to be here.

+ +

VICTORIA: Wonderful. I'm excited to learn more about your product today that you're building. Can you just tell me a little bit more about it?

+ +

NOELLE: Yeah, absolutely. Well, I feel like, [chuckles] one, you could work here. You did a phenomenal job of sharing what Noula is. But here at Noula, we are a virtual care platform that really empowers women and patients with uteruses to better understand their bodies by providing them with hormonal health data that's unique to them. Based on that information, we're able to provide them with the individualized, tailored care that they deserve at their fingertips through a virtual app.

+ +

VICTORIA: Wonderful. And I'm wondering what led you to think I need to make this company. What happened in your life where you decided this needs to exist in the world?

+ +

NOELLE: Really it stems from my own personal brush with an undiagnosed chronic condition where I truly was the one in five women who felt dismissed, denied, and ignored in the traditional healthcare settings. And that is really something that's actually unified us all as a team here at Noula. We have the shared frustration in terms of the gaps that we experienced overall; not one, two of our health journeys looked alike.

+ +

And so during this time, I found myself really just kind of banging my head against a wall where I had these ongoing symptoms that disrupted every aspect of my life, not just my physical health, but it became really very much an emotional roller coaster as well. Because despite having access to care and wonderful employer-sponsored health insurance, I was finding that my doctors were essentially brushing me off, attributing it to stress.

+ +

And it really led to me kind of just having this inner monologue and questioning myself as, like, is this in my head? Maybe it is stress-related. This doesn't feel normal. Should this be normal? And so I, just like 70% of millennials, turned to Google as my medical companion. I lost trust in healthcare settings and just turned to do research around what could be possibly causing the symptoms in my overall health. And I just refused to believe that this was my sense of normalcy.

+ +

And through my own research, I started finding things like my ethnicity and my environment could have an impact in the symptoms that I was experiencing. I was dealing with chronic pelvic pain, irregular periods to the point where I was actually menstruating for seven months straight. I had horrible migraines. And so I just really turned to these medical journals to try to figure out and uncover what my body was telling me.

+ +

And so, based on that research, I finally went back to the doctor demanding an ultrasound, where they ended up finding over 40 abnormal follicles and cysts on my ovaries. And even at that point, my treatment plan was a Band-Aid fix. And so, ultimately, I really felt like the system fundamentally failed me. This Band-Aid fix was essentially, hey, we'll put back your former birth control method and call us when you're ready to have a baby, and we'll figure it out then. And so, to this day, I actually haven't received any additional care, guidance from any clinician despite being in and out of the doctor's office with the symptoms.

+ +

And so I ended up being diagnosed with a condition called PCOS. Again, from my own research, I learned that Mexican women with PCOS, so yours truly, we have the most severe phenotype that puts us at the highest risk for other complications that are beyond just reproductive health. It increases my risk for diabetes. It increases my risk for hypertension. And these are ultimately very costly to my health. And I was just frustrated. I thought, why am I learning about this through my own research versus the doctor's office, where it really felt like a one size fits all approach to care?

+ +

And so, based on my experience, I started talking to more and more women. And I found that I wasn't alone with this shared frustration. We see that 80% of people who menstruate suffer from hormonal imbalances. And more often than not, women are juggling with more than two chronic conditions at a time. And so it's truly something that I felt as a patient that we were missing to feel empowered in our health and actually feel seen and heard. And then, when I actually spoke to clinicians as well, they felt that they weren't set up to care for their patients in the way that they wanted to care for them.

+ +

VICTORIA: And I'm wondering how those women and the people you talked to started to inform the roadmap for the product that you were going to build.

+ +

NOELLE: Yeah, yeah, absolutely. I mean, truly, the voice of those members, and these patients are the center of our lighthouse in terms of how we shape our product roadmap ahead. And so, ultimately, it really came down to us initially doing customer discovery. So I was really surprised to see how many people were willing to talk about their experiences navigating their health as a woman or a person with a uterus. And that was really telling in itself because I've heard from folks where they had to pay others with gift cards to have this conversation about how they might navigate certain workflows as it might relate to the products they're building. But naturally, these folks wanted to talk about their experiences.

+ +

So we kind of tackled this in a couple of parts, one, I was going out into my own network, reaching out to friends of friends, posting in Nextdoor Facebook groups, really asking for 15 minutes of people's times to learn about their experience. And within two weeks, I had almost 100 customer discovery calls booked where these women were wanting to talk about their frustration and what they wished they had in terms of the care that they wanted.

+ +

And so that was point A, like, okay, I think we're onto something. Our gaps in our experiences are shared across the board. And this is the pain that not only I experienced, or the Noula team has experienced, but that hundreds of women have experienced. The other piece, too, is, believe it or not, you know, we're constantly doing customer discovery as an early-stage company. But when we launched our beta, we launched with an initial hypothesis. But we saw that what our members were coming in for more aligns with their hormone health than what we initially thought, where we thought majority of folks would be coming to us at a family building stage.

+ +

And then even [laughs] truly through social media, our TikTok channel alone when we lead with these persona stories it helps drive this just natural virality to it. And daily, we have folks reaching out to us asking if what they're experiencing is normal or what they should do. And so they're coming to us because we really fill this very prevalent gap in care today.

+ +

VICTORIA: It must be really reassuring on a personal level and also on a business level that you found a problem that you can really help and make a difference with.

+ +

NOELLE: Yeah, absolutely. I mean, it's frustrating that we are all bonded and unified by this experience. But ultimately, we'll continue to use the voice of our members as our guiding light to shape our roadmap ahead. And actually, that's what you see today with Noula. We took the learnings from the beta. We took the conversations that we've had with so many members and just women and folks outside of Noula to really shape what you see today.

+ +

VICTORIA: That's wonderful. And you already mentioned one surprise that you found in your customer discovery process. I wonder if you could even tell me a little bit more about any hypothesis you had that you found from research; the outcome was quite different, and that changed your business strategy.

+ +

NOELLE: Yeah, yeah, absolutely. So we have always seen ourselves as truly being this co-piloted partner for women in their healthcare journeys for life. But when initially launching our beta, we thought our niche today is going to be folks navigating family planning, so people who are looking to start a family in the near future, actively trying to conceive, pregnant, or recently postpartum. So we built a beta around that. And it was very low-code. This is before I had any technical talent [chuckles] on our team and essentially no money.

+ +

And so, we built this low-code/no-code beta and launched it. We brought on about 100 folks to this closed beta. And with that, we built the product with that hypothesis in mind that we're going to be targeting specific stages. But what ultimately happened is as we were onboarding the 100 users, we found over...with each onboarded user, we started to see the scale tip where all of a sudden, 80% of those users very much had a story that mirrored my own experience with health.

+ +

They were coming to us because they suspected that they had a hormonal imbalance or these unexplained symptoms that they didn't know what was causing them. Several of them had been diagnosed with conditions like PCOS, endometriosis, or fibroids. Many of them were dealing with unexplained period pain and irregular menstruation. And so we started to scratch our heads to be like, oh, wow. Okay, so these folks are actually coming to us for a different reason than we had [chuckles] initially anticipated.

+ +

They're using the product differently. And also, they are far more engaged than our initial hypothesized users, which were pregnant people. And so while we have been able to really create a product that is able to adapt with these users over time, we found that that messaging and creation of a safe space for those users was incredibly important, and we wanted to lean into that.

+ +

VICTORIA: That's really cool. And maybe talk more about creating that safe space in dealing with healthcare data. Were there any special considerations you had to bring into building your tech stack with those really delicate elements?

+ +

NOELLE: Yeah, yeah. I mean, ultimately, safety and security of their data and honoring that privacy. We will never sell any data whatsoever. And I know that was a concern for many and still is since we've seen in the news this has been happening with other apps and stuff where they're selling user health data to social media sites. So honoring and protecting that privacy, first and foremost. The other piece is we had to also empower our care team to support our members in the best way that they can with the information that they had about their unique health.

+ +

And so, unfortunately, our members were coming to us at such an emotionally turmoil time in their lives that they wanted answers. They were frustrated. They were saying, "Why is this happening to me?" We had to really ensure that we could be that empathetic ally for them, empower them with information, and really arm them with tools to use inside and outside of the clinic to get the answers that they deserve.

+ +

VICTORIA: Right, and I see that. So on your site, there's a quiz you can take about your symptoms, and then you can sign up for what's ultimately going to be a home test kit. Is that right?

+ +

NOELLE: Yes, yes. So users are able to sign up for Noula at no cost to you. So you can start free tracking your symptoms, and these symptom trackers are going to be customized to you. So based on... similar to the quiz that you mentioned, you'll be able to answer questions about what you're experiencing, what your goals are. And Noula will make recommendations of what to track within the app itself. You can then track your symptoms that you select over time and get this customized snapshot to build this true picture of your health.

+ +

You can then continue to add on to that snapshot of your health through that home hormone test. So you don't necessarily need to purchase the test if you don't want to. But you have the ability to test your hormones to get a clearer picture of your baseline hormonal health. And we're able to really help arm you with that information about your body.

+ +

And then, from there, beyond just that information from that data set, you have access to empathetic coaching from medical experts. All of our care coaches are registered nurses. So you do have that expert at your fingertips who's there to really steer and guide you every step of the way. And that was something that I actually felt was missing from my own experience when navigating my own symptoms pre-Noula.

+ +

I found myself running these tests [chuckles] on my own, like ordering tests online trying to figure out what was going on. And just kind of hit this wall where I said to myself, I don't know how to interpret these. I don't know what to do with these. I don't know how to talk to my doctor about this. What do I do?

+ +

VICTORIA: That's so interesting. And I heard you mentioned empathy a few times and how important that is. Would you say that's one of your core values that you bring into founding a company like this?

+ +

NOELLE: Oh yeah, absolutely, absolutely. So I actually studied to become a doula. And so some of the pillars that we were trained in were really supporting our clients in these four primary pillars: ensuring that we can support them with physical support, emotional support, informational support, and advocacy. So really, those four pillars together have really steered us to create this foundation of empathetic care. And so that is truly integral to our brand and who we are, how we deliver that care, and also in such an inclusive and culturally competent way.

+ +

VICTORIA: It sounds really important what you mentioned; building an app requires a lot of trust to be able to give you your data and trust that the results that you're getting are helpful. So I really love that that's a part of your core value that you bring to the organization too.

+ +

NOELLE: Yeah, I think it was something that was really important to us from the very beginning, especially because we are a BIPOC and queer-co-founded company. It's rare that we see ourselves in the ecosystem, not just as founders [chuckles] but even just in how care is designed for us. So we wanted to ensure that we were creating this space where everyone can see themselves. And it's been so reassuring to hear from members and even just folks who find Noula on their own that they finally feel like they're seen and heard as an individual with Noula.

+ +

VICTORIA: Well, that might be the answer to my next question, which is what keeps you going, and what's the wind in your sails that keeps you pressing forward with this?

+ +

NOELLE: [chuckles] It's definitely that I think being able to hear from our members how Noula has helped change their life, even it is just a little bit where they feel more confident, where they feel supported, and they don't feel alone means everything to us. And the other piece is I feel incredibly proud when members have actually tuned in to listen to their bodies. And despite their experience feeling brushed off in the traditional healthcare setting, they really listen to themselves and turn to Noula.

+And there have been cases where we help support these folks to the point where because of Noula (One member is actually popping up in my head specifically.), they were able to find that they had a hereditary thyroid condition before it worsened because of Noula. And so that in itself was so powerful because their experience in the clinic was very much more like, well, no wonder you're fatigued and no wonder you have brain fog. You have a baby; what do you expect?

+ +

VICTORIA: Oh, I love that; what a powerful message. And I think that speaks to the power of having systems in place that are designed with those people in mind.

+ +

NOELLE: 100% yes.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: So what does success look like in the immediate future and in the longer term for Noula?

+ +

NOELLE: I think today, our success is very much qualitative. I think with health, especially digital health, it's a long game. And so today, we're measuring success by those member stories, by hearing from them that, again, this is a place where they finally feel empowered in their health. They have the tools that they need to unlock the best version of themselves so that they can get the care that they envision on their terms. So really, just through that qualitative piece.

+ +

Patient satisfaction is another huge factor as well. We supercharge our algorithm based on the identified and pooled hormonal health data so that we can continue providing tailored recommendations that are personalized to each user. So in my example, my Noula experience might say, okay, we know that Noelle is a Latina woman who has PCOS. Other people who might have had similar symptoms to her have found these recommendations or tracking these symptoms to be really helpful for them, and so that's something that I would try. And so really just, again, creating a space where you're not alone is huge. And so that's where we really lean into the qualitative piece.

+ +

And as we grow, we also incorporate the quantitative success metrics as well. So how are we measuring impact in terms of health outcomes so that we can also just inform the system to deliver better care? Because, I mean, there's just so much unknown about the female body specifically. It wasn't until 1993 that women were even required to be a part of a clinical study. So there's just a lot of gray area that needs to be addressed to deliver better health outcomes overall, especially when health outcomes amongst women in the U.S. is so poor.

+ +

VICTORIA: And as a woman in the U.S. who has hormones, I 100% get the value and the potential for an app like this. Have you had that same positive reaction from investors or from other people who are looking to join your group?

+ +

NOELLE: Yeah, yeah, absolutely. I mean, the investors who really understand it and get it, unfortunately, do because either they or someone they loved has been impacted by a hormonal imbalance or by being dismissed in the traditional healthcare settings. So similar to how the Noula team and our members have been unified by these experiences, we find that outside as well with investors.

+ +

What makes me really proud, too, is connecting with clinicians. Like, our Medical Director, Dr. Marieme Mbaye, who is a highly rated physician in New York City, turned away from practicing medicine to join Noula because she even felt like her hands were tied behind her back with the type of care she can deliver. And so it's always incredibly reassuring when we hear from clinicians that this is why care should be designed to really proactively look out for groups of people who are often overlooked, which, sadly, tend to be women and people of color.

+ +

VICTORIA: Right, almost like it was designed that way in the system.

+ +

[laughter]

+ +

NOELLE: Yep.

+ +

VICTORIA: That's great. I'm glad that other people are seeing that benefit. And what hurdles do you see on the road ahead for where you're going with Noula?

+ +

NOELLE: As we are bringing on members, the more that we've built this trust with our member base, the more they want from us [laughs] in terms of us truly just being their end-to-end care delivery partner, and we would love to get there. But as a very early-stage company, we have to build things quickly but one thing at a time. So oftentimes, I feel like, okay, we have this huge leap to make to deliver the care that our members are asking for, and so it's a blessing and a curse where they're like, "We love this so much. Can you be my doctor? I don't want to go to another doctor." Or, "Can I get this through you and only you, or do I need to go somewhere else?"

+ +

VICTORIA: Well, that must be a great feeling to have. But also staying focused, like you mentioned, would be a challenge, and being able to get done within your capabilities. But it's funny because I think there's a huge demand in this market [laughs] that we've had similar kind of demand for other women's health-focused products or people with uteruses too. Clearly, something is broken. [laughs] So you've got a lot of great work you want to get done. Is there anything really already planned in your roadmap that you're super excited about?

+ +

NOELLE: Yeah. And we'll be rolling out insurance-covered telehealth appointments very soon, so that's one thing that I'm particularly just incredibly excited about because I think it does...how we got to delivering that was through the feedback from our members. And so I think that, in turn, will allow us to take one step closer to truly being that healthcare delivery partner for all members on all those levels. Very, very excited about that because it very much aligns with our mission to deliver accessible and equitable care.

+ +

VICTORIA: Yeah, that's a huge capability, and especially considering in some areas, there just might not be access to doctors or hospitals that you can go to in person, so...

+ +

NOELLE: Yeah, yeah, absolutely. I mean, only 50% of U.S. counties have access to OBGYNs and with the average appointment length only being 15 minutes. Like, again, physicians have their hands tied behind their backs because that means per OBGYN, they're managing about 3,500 patients, which just isn't feasible or scalable.

+ +

VICTORIA: Wow. Yeah, that's a lot of patients. [laughs] Well, I want to go back to some folks that you mentioned earlier on your team and just tell me about how it all started coming together with building your team at Noula.

+ +

NOELLE: Yeah, yeah, absolutely. So my co-founder and CTO, her name is Suzie Grange. She is an absolutely wonderful, brilliant engineer. Her and I actually worked together at our previous employer company called Maven Clinic. So at Maven Clinic, I was responsible for helping lead sales and business development through some growth milestones. And Suzie was the founding engineer over at Maven. So she was there for the long haul, for over seven years. And so she had left Maven before I did.

+ +

And once I took the leap into building Noula full-time, her and I reconnected, and we welcomed her to the team as a co-founder and CTO last year, which has been so instrumental to how we've built our product to date. We actually [laughs] ran into fun challenges many startups will where we've had to recently rebuild our entire tech stack and truly couldn't have done this without her and our back-end engineer as well. And so she's just been incredible.

+ +

And then we also brought on our medical director, as I shared, Dr. Marieme Mbaye, who was a practicing OBGYN based out of Brooklyn, New York City. And she has also had experience advising for women's health startups like Natalist to Frame Fertility and others.

+ +

VICTORIA: Got it. So you found your technical co-founder, or you maybe already started together and then got the technical expertise there. You mentioned taking the leap to do Noula full-time. What was that decision like for you emotionally?

+ +

NOELLE: It was a really big decision, and it was also a very vulnerable decision on my part. And so I'm going to open up about this because I think it's important to also recognize that this is a scary decision for all founders to make. When I was dealing with these chronic symptoms, that was back in 2019, so this was before I joined Maven Clinic. And I knew I wanted to build something to change the system. But I thought the best way to ensure what I was going to build were to be successful was to contribute to a company, learn as much as I could, fail fast, fail forward. So I joined Maven. I was there for almost two years, and that experience alone was instrumental.

+ +

But ultimately, what really drove me to make the leap and place this blind faith in myself and just jump into this unknown abyss was after another health scare. I promise you I'm healthy. But I went through...in early 2021, I had a massive seizure in my sleep, and I was hospitalized where they thought I had a brain tumor. And I just remember sitting in the ambulance. And this was during COVID, so I had to go alone. I was hospitalized alone.

+ +

And I remember sitting in the ambulance, and I don't know why this sticks with me so much, but I remember seeing the light of the street lamp, and I was just looking at it. And I thought I'm not ready to leave the earth without making an impact here. And so I told myself, I was like, if I make it out of this alive, I'm going to do whatever it takes to change healthcare and make the impact that I want. And so I did just that.

+ +

I'm okay. I don't have a brain tumor, thank goodness. And I trusted myself trusted that the conversations that I had with friends, family, and other people who shared those experiences with me would serve as our lighthouse to building an incredibly impactful product that would reshape the future of health for good.

+ +

VICTORIA: Oh, that's incredible that you had that experience that made you think about what really mattered and what you wanted to do with the rest of your time. It sounds like you had friends and family to support you along the way with that decision, right?

+ +

NOELLE: Yeah. And a lot of them didn't get it. To this day, my mom's like, "Don't you want to go to med school or be a nurse?" [laughs] I'm like, "No." [laughs] But yes, absolutely had their support.

+ +

VICTORIA: Oh, that's wonderful. I mean, I can see that, even if you have a good idea that some people might be like, "Don't you need a job?"

+ +

[laughter]

+ +

NOELLE: Exactly. And that's exactly the kind of position I was in. I said, okay, I need to make a game plan. And when I quit Maven, I had joined an accelerator program called Visible Hands, which was designed by POC founders. And for three months, you got a small chunk of money. And I worked backwards, I said, okay, within this three-month period, I need to prove that Noula is a venture backable business.

+ +

And so I worked backwards with how much savings I had left to continue supporting myself. And that gave me till...so the program started in September, and I had basically saved enough money for myself through end of February, maybe end of March is stretching it, of 2022. And so, I worked backwards from that date and closed an oversubscribed pre-seed round in February.

+ +

VICTORIA: Wow.

+ +

NOELLE: So that was really...it was very challenging. I don't think I've...I worked harder in my life than I ever had before. And so yeah, that's really kind of where we're at today. And it made me one of less than 100 Latina women to ever raise a million dollars, which is wild.

+ +

VICTORIA: Awesome that you were able to do that, and sad that the number is so small. [laughs]

+ +

NOELLE: I know. And I did the math, and we said, okay, 0.4% of venture dollars go to Latina founders. I need to have 200 meetings just to get one yes. And so I was chasing as many meetings as I could and chasing nos as fast as I could because I thought the sooner I could get a no, the quicker I could move on to the next.

+ +

VICTORIA: So, really trying to weed out people who just weren't going to be a good fit. [laughs]

+ +

NOELLE: Right.

+ +

VICTORIA: That makes sense. But ultimately, you were able to find someone who aligned with you. Was there a checklist or some kind of way that you used to decide if those investors were going to be right for you?

+ +

NOELLE: Yeah, I think, ultimately, the connection to our mission. At the early stage, they're making a bet too on founder fit, and so I wanted them to, one understand and feel confident in myself as a founder. And so I wanted to see that on the call. And then two, I also wanted to ensure they understood that this was a problem. And so there were some investors where they didn't understand the problem or why anyone would need this. And some of them didn't understand things like what menstruation was, not even kidding. [laughs]

+ +

I didn't have any...at that point, I was like, I don't have a single check. I had to make the decision, like, this isn't going to be the right partner for me. And so those were kind of my two main criteria, like, do I believe they're going to be the right partner in helping us accelerate just my vision and supporting me as a founder? Do they believe in me and in our vision? And two, do they understand the problem and the impact?

+ +

VICTORIA: Right, that makes sense. So then that kind of empowers you to continue doing the work that you know you should be doing.

+ +

NOELLE: Right.

+ +

VICTORIA: Well, I wanted to ask you a little bit more about TikTok too, and how you used social media to raise your brand awareness.

+ +

NOELLE: [laughs] So, our TikTok strategy, I'm embarrassed at how long it took me to make our very first TikTok [laughs] because I probably spent way too much time trying to figure it out. But our TikTok strategy really aligns with our brand strategies. Our core pillars in terms of that really come down to leading with empathy, so showcasing real, raw, authentic stories from real people. So we can show, like, you are not alone in this. And then two, educational pieces as well.

+ +

So we have a series called Dear Noula where anyone can write in anonymous questions to Noula. And our medical director, Dr. Marieme Mbaye, will answer those on TikTok. And so, really, what's helped drive the virality in our TikTok strategy is the marriage of that approach where one of our most viral TikToks is one of me with my ultrasound behind me. And then another one that's very educational based around what your vaginal discharge might be telling you. And so there's that blended approach to just, again, showing those real stories with digestible educational bits of content has really helped us build that brand awareness and also just the trust in our brand as well.

+ +

VICTORIA: That's great. And I think that's something that a lot of startups might be thinking about marketing-wise. Like, how do they use those types of tools to really connect with people? And I like the approach that you've taken with being educational and with being very real, [laughs] which makes sense. Okay, so we asked about what your biggest challenges were on the horizon. What do you think are the biggest opportunities that you could potentially take on at Noula in the next six months to a year?

+ +

NOELLE: What I'm particularly very excited about with Noula is our ability to adapt with users over time. So what we often see with a lot of digital health solutions, especially in women's health, is they tend to be very stage-specific. You use this product for fertility-related stuff, this one for pregnancy-related stuff, this for postpartum-related stuff, or STIs, for example. So they tend to be very specific.

+ +

And what I'm particularly eager to showcase is truly how Noula is designed to adapt with those folks over time, so from menstruation through menopause. And the more that you use Noula, the longer you use Noula, the more customized insights you'll have about your unique body to inform providers to deliver that individualized care. So truly, the thing I'm looking forward to most is time, seeing how Noula can truly fit patients' lives versus the other way around. And also being in a position where our solution isn't tied to just a reproductive stage. It's truly encompassing our whole health beyond just reproductive organs but taking into account genetics, lifestyle, environment, stress, sleep, nutrition, et cetera.

+ +

VICTORIA: That's very cool. So kind of expanding into even more tailored patient data and services that you can provide over time.

+ +

NOELLE: Yeah, and, I mean, this is information that most people's doctors don't have access to.

+ +

VICTORIA: Yeah, I could see that. And, I mean, anyone who's used a menstrual tracking app you can predict things based on the longer time period you've been tracking it, right?

+ +

NOELLE: Exactly, exactly.

+ +

VICTORIA: That's very cool. I'm excited to see it come out. And I think by the time this podcast airs; you'll have launched a new product. Is that right?

+ +

NOELLE: Yeah. So by the time this podcast launches, we'll be completely launched. I will have the app and care coaching available for anyone to use, sign up for, and it's really, really exciting stuff on the horizon.

+ +

VICTORIA: That's super cool. Well, my last question for you is if you could go back in time to when you first started Noula, what advice would you give yourself?

+ +

NOELLE: I tend to be a perfectionist. So I'd say just ship faster; don't chase perfection because things are going to change. I learned that from the beta itself, where we spent time building this product that we wanted to be so perfect. And again, [chuckle] what we learned was that the initial cohort of users who we thought would be our biggest advocates and earliest adopters of Noula was not true. And so being okay with your first iteration as being imperfect is okay. Some of the best advice I actually got after we launched our beta was that if you're not embarrassed by your MVP, you launched too late.

+ +

VICTORIA: [laughs] That's really funny. It should be kind of awkward, right?

+ +

NOELLE: Yeah. Isn't that great? [laughs]

+ +

VICTORIA: That's really good. [laughs]

+ +

NOELLE: I wish I had heard this before. I [laughs] spent so much time trying to perfect this to the T. [laughs]

+ +

VICTORIA: I think we're going to maybe print out a banner that says that and hang it behind [laughter] our screens or something. Yeah, I love that. And I love just how much went into the customer discovery and how you were flexible to change your hypothesis for what was going to work for people based on that.

+ +

NOELLE: Yeah. And I think one thing that really helped, too, just honestly from my sales background, was I was very mindful of not leading a horse to water when doing customer discovery. So I think often we hear that, you know, we ask very pointed questions to try to lead folks to say, "Yes, I would use your product," or, "Yeah, that sounds useful." I purposely asked very open-ended questions like, "Walk me through your experience navigating your health," and just listened.

+ +

And that allowed me to find patterns across the number of conversations that I had that ultimately led us to build the beta in our product that you see today is through those very open-ended questions and hearing from users themselves as far as what they thought was missing versus me saying, "If we build this feature, would you use it?"

+ +

VICTORIA: That's very cool. And I learned a lot just from taking the quiz on your website. [laughs]

+ +

NOELLE: Oh, awesome. [laughs]

+ +

VICTORIA: So I'm really excited to see what you all come up with next. Are there any final takeaways or thoughts you want to leave for our listeners today?

+ +

NOELLE: We'd love to hear about your experience using Noula. So you can use Noula free for a limited time. We're offering 30 days of free care coaching for anyone that signs up and discounted access to the hormone testing. So just really excited to share with the world because it's about damn time we get the care that we deserve.

+ +

VICTORIA: Absolutely. Thank you so much for joining us today.

+ +

And you can subscribe to the show and find notes along with a complete transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Noelle Acosta is Founder and CEO of Noula Health, a data-driven platform that uses personalized hormonal health data to deliver tailored care.

+ +

Victoria talks to Noelle about helping patients with uteruses to better understand their bodies by providing them with hormonal health data that's unique to them and providing them with individualized care they deserve at their fingertips through a virtual app.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Noelle Acosta, Founder and CEO of Noula Health, a data-driven platform that uses personalized hormonal health data to deliver tailored care. Noelle, thank you for joining me.

+ +

NOELLE: Thank you so much for having me, Victoria. It's a pleasure to be here.

+ +

VICTORIA: Wonderful. I'm excited to learn more about your product today that you're building. Can you just tell me a little bit more about it?

+ +

NOELLE: Yeah, absolutely. Well, I feel like, [chuckles] one, you could work here. You did a phenomenal job of sharing what Noula is. But here at Noula, we are a virtual care platform that really empowers women and patients with uteruses to better understand their bodies by providing them with hormonal health data that's unique to them. Based on that information, we're able to provide them with the individualized, tailored care that they deserve at their fingertips through a virtual app.

+ +

VICTORIA: Wonderful. And I'm wondering what led you to think I need to make this company. What happened in your life where you decided this needs to exist in the world?

+ +

NOELLE: Really it stems from my own personal brush with an undiagnosed chronic condition where I truly was the one in five women who felt dismissed, denied, and ignored in the traditional healthcare settings. And that is really something that's actually unified us all as a team here at Noula. We have the shared frustration in terms of the gaps that we experienced overall; not one, two of our health journeys looked alike.

+ +

And so during this time, I found myself really just kind of banging my head against a wall where I had these ongoing symptoms that disrupted every aspect of my life, not just my physical health, but it became really very much an emotional roller coaster as well. Because despite having access to care and wonderful employer-sponsored health insurance, I was finding that my doctors were essentially brushing me off, attributing it to stress.

+ +

And it really led to me kind of just having this inner monologue and questioning myself as, like, is this in my head? Maybe it is stress-related. This doesn't feel normal. Should this be normal? And so I, just like 70% of millennials, turned to Google as my medical companion. I lost trust in healthcare settings and just turned to do research around what could be possibly causing the symptoms in my overall health. And I just refused to believe that this was my sense of normalcy.

+ +

And through my own research, I started finding things like my ethnicity and my environment could have an impact in the symptoms that I was experiencing. I was dealing with chronic pelvic pain, irregular periods to the point where I was actually menstruating for seven months straight. I had horrible migraines. And so I just really turned to these medical journals to try to figure out and uncover what my body was telling me.

+ +

And so, based on that research, I finally went back to the doctor demanding an ultrasound, where they ended up finding over 40 abnormal follicles and cysts on my ovaries. And even at that point, my treatment plan was a Band-Aid fix. And so, ultimately, I really felt like the system fundamentally failed me. This Band-Aid fix was essentially, hey, we'll put back your former birth control method and call us when you're ready to have a baby, and we'll figure it out then. And so, to this day, I actually haven't received any additional care, guidance from any clinician despite being in and out of the doctor's office with the symptoms.

+ +

And so I ended up being diagnosed with a condition called PCOS. Again, from my own research, I learned that Mexican women with PCOS, so yours truly, we have the most severe phenotype that puts us at the highest risk for other complications that are beyond just reproductive health. It increases my risk for diabetes. It increases my risk for hypertension. And these are ultimately very costly to my health. And I was just frustrated. I thought, why am I learning about this through my own research versus the doctor's office, where it really felt like a one size fits all approach to care?

+ +

And so, based on my experience, I started talking to more and more women. And I found that I wasn't alone with this shared frustration. We see that 80% of people who menstruate suffer from hormonal imbalances. And more often than not, women are juggling with more than two chronic conditions at a time. And so it's truly something that I felt as a patient that we were missing to feel empowered in our health and actually feel seen and heard. And then, when I actually spoke to clinicians as well, they felt that they weren't set up to care for their patients in the way that they wanted to care for them.

+ +

VICTORIA: And I'm wondering how those women and the people you talked to started to inform the roadmap for the product that you were going to build.

+ +

NOELLE: Yeah, yeah, absolutely. I mean, truly, the voice of those members, and these patients are the center of our lighthouse in terms of how we shape our product roadmap ahead. And so, ultimately, it really came down to us initially doing customer discovery. So I was really surprised to see how many people were willing to talk about their experiences navigating their health as a woman or a person with a uterus. And that was really telling in itself because I've heard from folks where they had to pay others with gift cards to have this conversation about how they might navigate certain workflows as it might relate to the products they're building. But naturally, these folks wanted to talk about their experiences.

+ +

So we kind of tackled this in a couple of parts, one, I was going out into my own network, reaching out to friends of friends, posting in Nextdoor Facebook groups, really asking for 15 minutes of people's times to learn about their experience. And within two weeks, I had almost 100 customer discovery calls booked where these women were wanting to talk about their frustration and what they wished they had in terms of the care that they wanted.

+ +

And so that was point A, like, okay, I think we're onto something. Our gaps in our experiences are shared across the board. And this is the pain that not only I experienced, or the Noula team has experienced, but that hundreds of women have experienced. The other piece, too, is, believe it or not, you know, we're constantly doing customer discovery as an early-stage company. But when we launched our beta, we launched with an initial hypothesis. But we saw that what our members were coming in for more aligns with their hormone health than what we initially thought, where we thought majority of folks would be coming to us at a family building stage.

+ +

And then even [laughs] truly through social media, our TikTok channel alone when we lead with these persona stories it helps drive this just natural virality to it. And daily, we have folks reaching out to us asking if what they're experiencing is normal or what they should do. And so they're coming to us because we really fill this very prevalent gap in care today.

+ +

VICTORIA: It must be really reassuring on a personal level and also on a business level that you found a problem that you can really help and make a difference with.

+ +

NOELLE: Yeah, absolutely. I mean, it's frustrating that we are all bonded and unified by this experience. But ultimately, we'll continue to use the voice of our members as our guiding light to shape our roadmap ahead. And actually, that's what you see today with Noula. We took the learnings from the beta. We took the conversations that we've had with so many members and just women and folks outside of Noula to really shape what you see today.

+ +

VICTORIA: That's wonderful. And you already mentioned one surprise that you found in your customer discovery process. I wonder if you could even tell me a little bit more about any hypothesis you had that you found from research; the outcome was quite different, and that changed your business strategy.

+ +

NOELLE: Yeah, yeah, absolutely. So we have always seen ourselves as truly being this co-piloted partner for women in their healthcare journeys for life. But when initially launching our beta, we thought our niche today is going to be folks navigating family planning, so people who are looking to start a family in the near future, actively trying to conceive, pregnant, or recently postpartum. So we built a beta around that. And it was very low-code. This is before I had any technical talent [chuckles] on our team and essentially no money.

+ +

And so, we built this low-code/no-code beta and launched it. We brought on about 100 folks to this closed beta. And with that, we built the product with that hypothesis in mind that we're going to be targeting specific stages. But what ultimately happened is as we were onboarding the 100 users, we found over...with each onboarded user, we started to see the scale tip where all of a sudden, 80% of those users very much had a story that mirrored my own experience with health.

+ +

They were coming to us because they suspected that they had a hormonal imbalance or these unexplained symptoms that they didn't know what was causing them. Several of them had been diagnosed with conditions like PCOS, endometriosis, or fibroids. Many of them were dealing with unexplained period pain and irregular menstruation. And so we started to scratch our heads to be like, oh, wow. Okay, so these folks are actually coming to us for a different reason than we had [chuckles] initially anticipated.

+ +

They're using the product differently. And also, they are far more engaged than our initial hypothesized users, which were pregnant people. And so while we have been able to really create a product that is able to adapt with these users over time, we found that that messaging and creation of a safe space for those users was incredibly important, and we wanted to lean into that.

+ +

VICTORIA: That's really cool. And maybe talk more about creating that safe space in dealing with healthcare data. Were there any special considerations you had to bring into building your tech stack with those really delicate elements?

+ +

NOELLE: Yeah, yeah. I mean, ultimately, safety and security of their data and honoring that privacy. We will never sell any data whatsoever. And I know that was a concern for many and still is since we've seen in the news this has been happening with other apps and stuff where they're selling user health data to social media sites. So honoring and protecting that privacy, first and foremost. The other piece is we had to also empower our care team to support our members in the best way that they can with the information that they had about their unique health.

+ +

And so, unfortunately, our members were coming to us at such an emotionally turmoil time in their lives that they wanted answers. They were frustrated. They were saying, "Why is this happening to me?" We had to really ensure that we could be that empathetic ally for them, empower them with information, and really arm them with tools to use inside and outside of the clinic to get the answers that they deserve.

+ +

VICTORIA: Right, and I see that. So on your site, there's a quiz you can take about your symptoms, and then you can sign up for what's ultimately going to be a home test kit. Is that right?

+ +

NOELLE: Yes, yes. So users are able to sign up for Noula at no cost to you. So you can start free tracking your symptoms, and these symptom trackers are going to be customized to you. So based on... similar to the quiz that you mentioned, you'll be able to answer questions about what you're experiencing, what your goals are. And Noula will make recommendations of what to track within the app itself. You can then track your symptoms that you select over time and get this customized snapshot to build this true picture of your health.

+ +

You can then continue to add on to that snapshot of your health through that home hormone test. So you don't necessarily need to purchase the test if you don't want to. But you have the ability to test your hormones to get a clearer picture of your baseline hormonal health. And we're able to really help arm you with that information about your body.

+ +

And then, from there, beyond just that information from that data set, you have access to empathetic coaching from medical experts. All of our care coaches are registered nurses. So you do have that expert at your fingertips who's there to really steer and guide you every step of the way. And that was something that I actually felt was missing from my own experience when navigating my own symptoms pre-Noula.

+ +

I found myself running these tests [chuckles] on my own, like ordering tests online trying to figure out what was going on. And just kind of hit this wall where I said to myself, I don't know how to interpret these. I don't know what to do with these. I don't know how to talk to my doctor about this. What do I do?

+ +

VICTORIA: That's so interesting. And I heard you mentioned empathy a few times and how important that is. Would you say that's one of your core values that you bring into founding a company like this?

+ +

NOELLE: Oh yeah, absolutely, absolutely. So I actually studied to become a doula. And so some of the pillars that we were trained in were really supporting our clients in these four primary pillars: ensuring that we can support them with physical support, emotional support, informational support, and advocacy. So really, those four pillars together have really steered us to create this foundation of empathetic care. And so that is truly integral to our brand and who we are, how we deliver that care, and also in such an inclusive and culturally competent way.

+ +

VICTORIA: It sounds really important what you mentioned; building an app requires a lot of trust to be able to give you your data and trust that the results that you're getting are helpful. So I really love that that's a part of your core value that you bring to the organization too.

+ +

NOELLE: Yeah, I think it was something that was really important to us from the very beginning, especially because we are a BIPOC and queer-co-founded company. It's rare that we see ourselves in the ecosystem, not just as founders [chuckles] but even just in how care is designed for us. So we wanted to ensure that we were creating this space where everyone can see themselves. And it's been so reassuring to hear from members and even just folks who find Noula on their own that they finally feel like they're seen and heard as an individual with Noula.

+ +

VICTORIA: Well, that might be the answer to my next question, which is what keeps you going, and what's the wind in your sails that keeps you pressing forward with this?

+ +

NOELLE: [chuckles] It's definitely that I think being able to hear from our members how Noula has helped change their life, even it is just a little bit where they feel more confident, where they feel supported, and they don't feel alone means everything to us. And the other piece is I feel incredibly proud when members have actually tuned in to listen to their bodies. And despite their experience feeling brushed off in the traditional healthcare setting, they really listen to themselves and turn to Noula.

+And there have been cases where we help support these folks to the point where because of Noula (One member is actually popping up in my head specifically.), they were able to find that they had a hereditary thyroid condition before it worsened because of Noula. And so that in itself was so powerful because their experience in the clinic was very much more like, well, no wonder you're fatigued and no wonder you have brain fog. You have a baby; what do you expect?

+ +

VICTORIA: Oh, I love that; what a powerful message. And I think that speaks to the power of having systems in place that are designed with those people in mind.

+ +

NOELLE: 100% yes.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: So what does success look like in the immediate future and in the longer term for Noula?

+ +

NOELLE: I think today, our success is very much qualitative. I think with health, especially digital health, it's a long game. And so today, we're measuring success by those member stories, by hearing from them that, again, this is a place where they finally feel empowered in their health. They have the tools that they need to unlock the best version of themselves so that they can get the care that they envision on their terms. So really, just through that qualitative piece.

+ +

Patient satisfaction is another huge factor as well. We supercharge our algorithm based on the identified and pooled hormonal health data so that we can continue providing tailored recommendations that are personalized to each user. So in my example, my Noula experience might say, okay, we know that Noelle is a Latina woman who has PCOS. Other people who might have had similar symptoms to her have found these recommendations or tracking these symptoms to be really helpful for them, and so that's something that I would try. And so really just, again, creating a space where you're not alone is huge. And so that's where we really lean into the qualitative piece.

+ +

And as we grow, we also incorporate the quantitative success metrics as well. So how are we measuring impact in terms of health outcomes so that we can also just inform the system to deliver better care? Because, I mean, there's just so much unknown about the female body specifically. It wasn't until 1993 that women were even required to be a part of a clinical study. So there's just a lot of gray area that needs to be addressed to deliver better health outcomes overall, especially when health outcomes amongst women in the U.S. is so poor.

+ +

VICTORIA: And as a woman in the U.S. who has hormones, I 100% get the value and the potential for an app like this. Have you had that same positive reaction from investors or from other people who are looking to join your group?

+ +

NOELLE: Yeah, yeah, absolutely. I mean, the investors who really understand it and get it, unfortunately, do because either they or someone they loved has been impacted by a hormonal imbalance or by being dismissed in the traditional healthcare settings. So similar to how the Noula team and our members have been unified by these experiences, we find that outside as well with investors.

+ +

What makes me really proud, too, is connecting with clinicians. Like, our Medical Director, Dr. Marieme Mbaye, who is a highly rated physician in New York City, turned away from practicing medicine to join Noula because she even felt like her hands were tied behind her back with the type of care she can deliver. And so it's always incredibly reassuring when we hear from clinicians that this is why care should be designed to really proactively look out for groups of people who are often overlooked, which, sadly, tend to be women and people of color.

+ +

VICTORIA: Right, almost like it was designed that way in the system.

+ +

[laughter]

+ +

NOELLE: Yep.

+ +

VICTORIA: That's great. I'm glad that other people are seeing that benefit. And what hurdles do you see on the road ahead for where you're going with Noula?

+ +

NOELLE: As we are bringing on members, the more that we've built this trust with our member base, the more they want from us [laughs] in terms of us truly just being their end-to-end care delivery partner, and we would love to get there. But as a very early-stage company, we have to build things quickly but one thing at a time. So oftentimes, I feel like, okay, we have this huge leap to make to deliver the care that our members are asking for, and so it's a blessing and a curse where they're like, "We love this so much. Can you be my doctor? I don't want to go to another doctor." Or, "Can I get this through you and only you, or do I need to go somewhere else?"

+ +

VICTORIA: Well, that must be a great feeling to have. But also staying focused, like you mentioned, would be a challenge, and being able to get done within your capabilities. But it's funny because I think there's a huge demand in this market [laughs] that we've had similar kind of demand for other women's health-focused products or people with uteruses too. Clearly, something is broken. [laughs] So you've got a lot of great work you want to get done. Is there anything really already planned in your roadmap that you're super excited about?

+ +

NOELLE: Yeah. And we'll be rolling out insurance-covered telehealth appointments very soon, so that's one thing that I'm particularly just incredibly excited about because I think it does...how we got to delivering that was through the feedback from our members. And so I think that, in turn, will allow us to take one step closer to truly being that healthcare delivery partner for all members on all those levels. Very, very excited about that because it very much aligns with our mission to deliver accessible and equitable care.

+ +

VICTORIA: Yeah, that's a huge capability, and especially considering in some areas, there just might not be access to doctors or hospitals that you can go to in person, so...

+ +

NOELLE: Yeah, yeah, absolutely. I mean, only 50% of U.S. counties have access to OBGYNs and with the average appointment length only being 15 minutes. Like, again, physicians have their hands tied behind their backs because that means per OBGYN, they're managing about 3,500 patients, which just isn't feasible or scalable.

+ +

VICTORIA: Wow. Yeah, that's a lot of patients. [laughs] Well, I want to go back to some folks that you mentioned earlier on your team and just tell me about how it all started coming together with building your team at Noula.

+ +

NOELLE: Yeah, yeah, absolutely. So my co-founder and CTO, her name is Suzie Grange. She is an absolutely wonderful, brilliant engineer. Her and I actually worked together at our previous employer company called Maven Clinic. So at Maven Clinic, I was responsible for helping lead sales and business development through some growth milestones. And Suzie was the founding engineer over at Maven. So she was there for the long haul, for over seven years. And so she had left Maven before I did.

+ +

And once I took the leap into building Noula full-time, her and I reconnected, and we welcomed her to the team as a co-founder and CTO last year, which has been so instrumental to how we've built our product to date. We actually [laughs] ran into fun challenges many startups will where we've had to recently rebuild our entire tech stack and truly couldn't have done this without her and our back-end engineer as well. And so she's just been incredible.

+ +

And then we also brought on our medical director, as I shared, Dr. Marieme Mbaye, who was a practicing OBGYN based out of Brooklyn, New York City. And she has also had experience advising for women's health startups like Natalist to Frame Fertility and others.

+ +

VICTORIA: Got it. So you found your technical co-founder, or you maybe already started together and then got the technical expertise there. You mentioned taking the leap to do Noula full-time. What was that decision like for you emotionally?

+ +

NOELLE: It was a really big decision, and it was also a very vulnerable decision on my part. And so I'm going to open up about this because I think it's important to also recognize that this is a scary decision for all founders to make. When I was dealing with these chronic symptoms, that was back in 2019, so this was before I joined Maven Clinic. And I knew I wanted to build something to change the system. But I thought the best way to ensure what I was going to build were to be successful was to contribute to a company, learn as much as I could, fail fast, fail forward. So I joined Maven. I was there for almost two years, and that experience alone was instrumental.

+ +

But ultimately, what really drove me to make the leap and place this blind faith in myself and just jump into this unknown abyss was after another health scare. I promise you I'm healthy. But I went through...in early 2021, I had a massive seizure in my sleep, and I was hospitalized where they thought I had a brain tumor. And I just remember sitting in the ambulance. And this was during COVID, so I had to go alone. I was hospitalized alone.

+ +

And I remember sitting in the ambulance, and I don't know why this sticks with me so much, but I remember seeing the light of the street lamp, and I was just looking at it. And I thought I'm not ready to leave the earth without making an impact here. And so I told myself, I was like, if I make it out of this alive, I'm going to do whatever it takes to change healthcare and make the impact that I want. And so I did just that.

+ +

I'm okay. I don't have a brain tumor, thank goodness. And I trusted myself trusted that the conversations that I had with friends, family, and other people who shared those experiences with me would serve as our lighthouse to building an incredibly impactful product that would reshape the future of health for good.

+ +

VICTORIA: Oh, that's incredible that you had that experience that made you think about what really mattered and what you wanted to do with the rest of your time. It sounds like you had friends and family to support you along the way with that decision, right?

+ +

NOELLE: Yeah. And a lot of them didn't get it. To this day, my mom's like, "Don't you want to go to med school or be a nurse?" [laughs] I'm like, "No." [laughs] But yes, absolutely had their support.

+ +

VICTORIA: Oh, that's wonderful. I mean, I can see that, even if you have a good idea that some people might be like, "Don't you need a job?"

+ +

[laughter]

+ +

NOELLE: Exactly. And that's exactly the kind of position I was in. I said, okay, I need to make a game plan. And when I quit Maven, I had joined an accelerator program called Visible Hands, which was designed by POC founders. And for three months, you got a small chunk of money. And I worked backwards, I said, okay, within this three-month period, I need to prove that Noula is a venture backable business.

+ +

And so I worked backwards with how much savings I had left to continue supporting myself. And that gave me till...so the program started in September, and I had basically saved enough money for myself through end of February, maybe end of March is stretching it, of 2022. And so, I worked backwards from that date and closed an oversubscribed pre-seed round in February.

+ +

VICTORIA: Wow.

+ +

NOELLE: So that was really...it was very challenging. I don't think I've...I worked harder in my life than I ever had before. And so yeah, that's really kind of where we're at today. And it made me one of less than 100 Latina women to ever raise a million dollars, which is wild.

+ +

VICTORIA: Awesome that you were able to do that, and sad that the number is so small. [laughs]

+ +

NOELLE: I know. And I did the math, and we said, okay, 0.4% of venture dollars go to Latina founders. I need to have 200 meetings just to get one yes. And so I was chasing as many meetings as I could and chasing nos as fast as I could because I thought the sooner I could get a no, the quicker I could move on to the next.

+ +

VICTORIA: So, really trying to weed out people who just weren't going to be a good fit. [laughs]

+ +

NOELLE: Right.

+ +

VICTORIA: That makes sense. But ultimately, you were able to find someone who aligned with you. Was there a checklist or some kind of way that you used to decide if those investors were going to be right for you?

+ +

NOELLE: Yeah, I think, ultimately, the connection to our mission. At the early stage, they're making a bet too on founder fit, and so I wanted them to, one understand and feel confident in myself as a founder. And so I wanted to see that on the call. And then two, I also wanted to ensure they understood that this was a problem. And so there were some investors where they didn't understand the problem or why anyone would need this. And some of them didn't understand things like what menstruation was, not even kidding. [laughs]

+ +

I didn't have any...at that point, I was like, I don't have a single check. I had to make the decision, like, this isn't going to be the right partner for me. And so those were kind of my two main criteria, like, do I believe they're going to be the right partner in helping us accelerate just my vision and supporting me as a founder? Do they believe in me and in our vision? And two, do they understand the problem and the impact?

+ +

VICTORIA: Right, that makes sense. So then that kind of empowers you to continue doing the work that you know you should be doing.

+ +

NOELLE: Right.

+ +

VICTORIA: Well, I wanted to ask you a little bit more about TikTok too, and how you used social media to raise your brand awareness.

+ +

NOELLE: [laughs] So, our TikTok strategy, I'm embarrassed at how long it took me to make our very first TikTok [laughs] because I probably spent way too much time trying to figure it out. But our TikTok strategy really aligns with our brand strategies. Our core pillars in terms of that really come down to leading with empathy, so showcasing real, raw, authentic stories from real people. So we can show, like, you are not alone in this. And then two, educational pieces as well.

+ +

So we have a series called Dear Noula where anyone can write in anonymous questions to Noula. And our medical director, Dr. Marieme Mbaye, will answer those on TikTok. And so, really, what's helped drive the virality in our TikTok strategy is the marriage of that approach where one of our most viral TikToks is one of me with my ultrasound behind me. And then another one that's very educational based around what your vaginal discharge might be telling you. And so there's that blended approach to just, again, showing those real stories with digestible educational bits of content has really helped us build that brand awareness and also just the trust in our brand as well.

+ +

VICTORIA: That's great. And I think that's something that a lot of startups might be thinking about marketing-wise. Like, how do they use those types of tools to really connect with people? And I like the approach that you've taken with being educational and with being very real, [laughs] which makes sense. Okay, so we asked about what your biggest challenges were on the horizon. What do you think are the biggest opportunities that you could potentially take on at Noula in the next six months to a year?

+ +

NOELLE: What I'm particularly very excited about with Noula is our ability to adapt with users over time. So what we often see with a lot of digital health solutions, especially in women's health, is they tend to be very stage-specific. You use this product for fertility-related stuff, this one for pregnancy-related stuff, this for postpartum-related stuff, or STIs, for example. So they tend to be very specific.

+ +

And what I'm particularly eager to showcase is truly how Noula is designed to adapt with those folks over time, so from menstruation through menopause. And the more that you use Noula, the longer you use Noula, the more customized insights you'll have about your unique body to inform providers to deliver that individualized care. So truly, the thing I'm looking forward to most is time, seeing how Noula can truly fit patients' lives versus the other way around. And also being in a position where our solution isn't tied to just a reproductive stage. It's truly encompassing our whole health beyond just reproductive organs but taking into account genetics, lifestyle, environment, stress, sleep, nutrition, et cetera.

+ +

VICTORIA: That's very cool. So kind of expanding into even more tailored patient data and services that you can provide over time.

+ +

NOELLE: Yeah, and, I mean, this is information that most people's doctors don't have access to.

+ +

VICTORIA: Yeah, I could see that. And, I mean, anyone who's used a menstrual tracking app you can predict things based on the longer time period you've been tracking it, right?

+ +

NOELLE: Exactly, exactly.

+ +

VICTORIA: That's very cool. I'm excited to see it come out. And I think by the time this podcast airs; you'll have launched a new product. Is that right?

+ +

NOELLE: Yeah. So by the time this podcast launches, we'll be completely launched. I will have the app and care coaching available for anyone to use, sign up for, and it's really, really exciting stuff on the horizon.

+ +

VICTORIA: That's super cool. Well, my last question for you is if you could go back in time to when you first started Noula, what advice would you give yourself?

+ +

NOELLE: I tend to be a perfectionist. So I'd say just ship faster; don't chase perfection because things are going to change. I learned that from the beta itself, where we spent time building this product that we wanted to be so perfect. And again, [chuckle] what we learned was that the initial cohort of users who we thought would be our biggest advocates and earliest adopters of Noula was not true. And so being okay with your first iteration as being imperfect is okay. Some of the best advice I actually got after we launched our beta was that if you're not embarrassed by your MVP, you launched too late.

+ +

VICTORIA: [laughs] That's really funny. It should be kind of awkward, right?

+ +

NOELLE: Yeah. Isn't that great? [laughs]

+ +

VICTORIA: That's really good. [laughs]

+ +

NOELLE: I wish I had heard this before. I [laughs] spent so much time trying to perfect this to the T. [laughs]

+ +

VICTORIA: I think we're going to maybe print out a banner that says that and hang it behind [laughter] our screens or something. Yeah, I love that. And I love just how much went into the customer discovery and how you were flexible to change your hypothesis for what was going to work for people based on that.

+ +

NOELLE: Yeah. And I think one thing that really helped, too, just honestly from my sales background, was I was very mindful of not leading a horse to water when doing customer discovery. So I think often we hear that, you know, we ask very pointed questions to try to lead folks to say, "Yes, I would use your product," or, "Yeah, that sounds useful." I purposely asked very open-ended questions like, "Walk me through your experience navigating your health," and just listened.

+ +

And that allowed me to find patterns across the number of conversations that I had that ultimately led us to build the beta in our product that you see today is through those very open-ended questions and hearing from users themselves as far as what they thought was missing versus me saying, "If we build this feature, would you use it?"

+ +

VICTORIA: That's very cool. And I learned a lot just from taking the quiz on your website. [laughs]

+ +

NOELLE: Oh, awesome. [laughs]

+ +

VICTORIA: So I'm really excited to see what you all come up with next. Are there any final takeaways or thoughts you want to leave for our listeners today?

+ +

NOELLE: We'd love to hear about your experience using Noula. So you can use Noula free for a limited time. We're offering 30 days of free care coaching for anyone that signs up and discounted access to the hormone testing. So just really excited to share with the world because it's about damn time we get the care that we deserve.

+ +

VICTORIA: Absolutely. Thank you so much for joining us today.

+ +

And you can subscribe to the show and find notes along with a complete transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+agUcvP6A + + ]]> + + Victoria Guido + + + 472: Interlock Capital with Neal Bloom + https://podcast.thoughtbot.com/472 + f2a3a4ef-e0df-4c70-a00e-cf2a6e7c2b25 + Thu, 27 Apr 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Neal Bloom is a Managing Partner at Interlock Capital, a community of founders, investors, and subject matter experts. + +Victoria talks to Neal about what he finds attractive about startups and companies he's excited about, out of all the pitches he receives, how many he gets to say yes to, and when working with a team, what he uses to manage information and contacts for investors. + 39:36 + no + + + Neal Bloom is a Managing Partner at Interlock Capital, a community of founders, investors, and subject matter experts. +Victoria talks to Neal about what he finds attractive about startups and companies he's excited about, out of all the pitches he receives, how many he gets to say yes to, and when working with a team, what he uses to manage information and contacts for investors. +Interlock Capital (https://interlock.capital/) +Follow Interlock Capital on LinkedIn (https://www.linkedin.com/company/interlock-capital/), or Twitter (https://twitter.com/InterlockCap). +Follow Neal Bloom on LinkedIn (https://www.linkedin.com/in/nealbbloom/) or Twitter (https://twitter.com/NealBloom). Check out his website (https://withkoji.com/@Nealbloom) and blog (https://freshbrewedtech.com/)! +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Neal Bloom, Managing Partner at Interlock Capital, a community of founders, investors, and subject matter experts. Neal, thank you for joining us. +NEAL: Hey, thanks for having me. It's so great to be here with you. +VICTORIA: Fantastic. I'm excited to finally get a chance to talk with you. I met you at an investor hike that you organize once a month. +NEAL: A founders' hike, yeah. I get up nice and early on the first Wednesday of each month in Torrey Pines in San Diego. And we hike up and down the hill with ocean views. It's not a bad day. +VICTORIA: It's a great way to start the morning, I think, and to meet other people, other builders of products in technology. So tell me more about your work at Interlock Capital. +NEAL: Sure. It really kind of organically happened that I became an investor, but not planned at all. I have an aerospace background then built my own edtech and talent tech marketplace. I call it the LinkedIn for students is really what we built as our first startup called Portfolium. We sold it, and I got really into startup communities, especially because of some people who helped me with my first startup. I want to be a part of building an even better ecosystem for others. And that turned into a podcast, a blog, an event series. +And once I had the capital from my exit, turned into angel investing as well, too, and really just found that as I got to know people over time, the more and more I got to know them, the more certain ones stood out that said, wow, I don't just want to help them for the good of it. I also just want to be along for the ride. And I started writing checks to other founders. So that was the beginning of my investor journey about five years ago. +And over COVID, a whole bunch of other later-stage experience operators, either founder-level or executives at tech companies, said, "I want to learn to do this. Can I do it alongside you?" And we created Interlock Capital as an investment syndicate. A group of us can share and utilize our brainpower, our time, and our capital to help companies. It's kind of our focus. +So that's why we call it a community because it's not just kind of a one-way pitch us, and we'll write you a check. It's very much get to know the people, find the exact right domain experts who have subject matter expertise, who've been there and done that before. If they like the company and they want to personally invest, then we go to the greater group and say, "Hey, everyone, who wants to join this deal specifically?" +So 18 investments later from Interlock Capital, we now also have an investment fund. So now we write two checks into every company. We do our syndicated style, pass the hat, if you will, "Hey, everyone, anyone want to invest in just this deal?" And then match it from our fund. And we're writing between $300,000 to $500,000 checks into early-stage software or/and software plus hardware companies. +VICTORIA: What an incredible journey. And I love that it's led you to creating a community as part of what you do as an investment capital group. What do you find interesting about these startups and these companies that you want to be interested in? +NEAL: Part of it is how much you learn about yourself, to be honest. I get to meet three to five new founders a day in a variety of ways, whether it's straight Zoom and pitch, or grab a coffee, or see them on a hike. We're kind of constantly introducing ourselves to each other. There's a bit of learning about how to size someone up to a certain regard. So you're kind of building this inner algorithm of how to top-prank people and their ideas. That's one interesting way that I never thought I would be doing professionally. +There's a lot that we say versus what we do, and that's a data point that I have to keep track of because I get pitched amazing ideas that will literally change the world for so much better. And you get really excited about it, and you get invested in it. And I call it founder love. You fall in love with these founders specifically and almost say, "I don't even care what you're working on. I just want to work more with you. How do we do it?" So there's a lot of that. +So there are some dating aspects [laughs] in terms of founder dating, like getting to know people. There's the determining how do we date towards marriage? Meaning, I'll write you a check, and I'm along for the ride for the next ten years. And then there's the kind of relationship maintenance which is okay; I wrote the check, now what? +Where can I be helpful to the company? How can I anticipate their needs so that they have to think one more thing of how to satisfy me? It's quite the opposite way around. I'm trying not to be a barrier. I'm trying to work for them while they're sleeping. So yeah, it's really interesting the kind of the relationship aspect that goes into getting to know and helping founders take their ideas and turn it into reality. +VICTORIA: That's very cool. And I have talked to people who have met you and talked to your company and just how supportive and helpful you all are even if you choose not to invest. So I think that's a really valuable resource for people. And I wonder, do you think it's something unique about the San Diego community in particular that is exciting right now? +NEAL: I think so. I think San Diego specifically has always had this culture of give-before-you-get mentality, and so we kind of lead with that. There are a lot of people moving here. And you could choose many places that could be great, like LA versus San Diego, and there's a certain kind of person that chooses here versus somewhere else. And what I have found is there's a certain kind of give-before-you-get cultural mentality here that somehow people register pretty quickly and come with. And so that's an underlying greatness about us here. +There's also because of the great environment we live in, by the beach, healthy lifestyle. I think we choose to work on things that maybe are also satisfying, just like our personal lives, meaning we work on things that matter, that are going to change the world, that are life-changing. That's not to say that we don't need certain other kinds of technology. I'm sure at some point, we felt we needed Twitter, and maybe we don't feel like that now. [laughs] +But here, it feels like everyone's working on very impactful things, and I think that's really special to think about. Some examples of that is we've got an interesting subset of the SaaS world in nonprofit tech. So GoFundMe was founded in San Diego. They have since acquired three other nonprofit tech SaaS companies in San Diego, like Classy. So that's kind of interesting. You've got people who want to build a business that services nonprofits, and now they're all under one roof. So yeah, I think there is something special. We can dive deeper into some of the other sub-industries or categories that are interesting here, too, if you're interested. +VICTORIA: Well, I could talk about San Diego all day. +NEAL: [laughs] +VICTORIA: Because I'm a fairly new resident, and I'm in love with it, obviously. [laughs] But let's talk more about products that can change the world. Like, what's one that you're really excited about that you've heard recently? +NEAL: Ooh. I would start a little high level in certain categories that I'm really liking. I like things I'm seeing in the infrastructure space right now, meaning, you know, whether it's pipes and our water utilities, and I would include that in energy and EV, you know, kind of a mobility piece. There's even the commercial side of mobility, so trucking and freight. That whole infrastructure layer is really interesting to me right now. +A certain company that, full disclosure, we invested in recently is a company called EarthGrid. They have a product that is boring holes tunnel-wise underground, but they're using just electricity and air, so plasma. And it's fascinating. They can bore holes 100 times the norm right now. They don't need to potentially trench, meaning they don't need to cut above the surface. They can just dig for miles straight underneath the ground, so they can go under things with that. And really a lot of the expensive pieces, closing lanes on freeways or highways to put fiber in or plumbing and all that. So it's really interesting to see that. +Now, one element is the technology is interesting. But they have a plan to actually own their own tunnels that go across the entire United States. So they don't just want to be a device that they're going to sell to everyone. They want to actually own their own utility that has major tunnels across the United States. So that's fascinating to me because that's like think big, think exponential around that. So that's one area that's kind of fascinating to me. +VICTORIA: That's super interesting, and thinking about the impact it can have on making power more secure for more people, things like that. There are just so many problems to solve, and so many are people trying to solve them. [laughs] - +NEAL: Yeah, exactly. And they have a clean tech angle in that there are a lot of different ways to dig and tunnel that includes chemicals, and so their big thing is to not do that. Some of their background is installing these kinds of lines in the EV space for solar panels. So they have a big kind of clean and sustainability focus there. And our infrastructure is aging big time. We've got 100-year-old bridges and pipes and other things that it's really interesting to see the government put money into. And so that is another aspect, a business model, per se of infrastructure. +You have the government putting billions, if not trillions, into upgrading our infrastructure, which as an investor, I like to hear that there's free capital out there in forms of non-dilutive funding to help these along, and that's existed for hundreds of years. Cars and oil industry got these kinds of subsidies, and then the EV and solar panels. So that's a good area that I like to look in as well is where is there additional large-scale funding to help these products really get to market? +VICTORIA: That makes sense. And so you're meeting three to five founders a day, and you're watching where the funding is available. And out of all the pitches that you receive, how many do you really get to say yes to? +NEAL: Oh, it's small, I mean, one to two a month if that would be a lot, and those could take a few months to work through. The best way for us to invest is to get to know the people for as long as possible. So I kind of mentioned that relationship aspect. I want to see how people operate. I want to see how they build product. I want to see how they get to know their customer and iterate and bring that back into design thinking. And so that's a big piece is getting to know and see the people do the things that they're saying. +Man, there are so many companies that I like on paper, whether it's oh my God, amazing team, or, oh, cool, the product. Yes, love that idea. And then you have to look at everything together, the timing, the valuation that they want, the team. Has this team been there, done that before? So there are a lot of elements that go into it. Like I mentioned, you have this founder love where you fall in love with the people, and maybe the rest doesn't work out or vice versa. But yeah, I think each investor comes at it differently. +So my area because I built two tech companies that were talent tech-related, meaning connecting people for opportunities; my investing style is very team and talent and recruitment-focused, meaning what are the superpowers of the founders? Are they aware of their weaknesses and their strengths? Have they filled in those gaps by finding co-founders that are complementary and opposites? +And then my partner, Al Bsharah, he is a super product guy, and he wants to break the product and see, how can you break it? What are they thinking product roadmap-wise? That's his first go-to. And so, for us, we're super complementary in that regard. So we will assess the same company in very different ways and then come together and say, "Let's share our scores, share our rank. Where do you think this company sits at in all these different areas and boxes?" And so that's a great way, that complementary skill sets as investors. We utilize those strengths together. +So yeah, it's hard for a founder to know that. A founder who's building a product, the person on the other side of the screen, they're meeting me. They're not going to know my algorithm. They're not going to know what I value more than something else. So there's this whole dance. I wish it didn't have to be that way, but it is a dance. It's a negotiation. +And that's why I build a community because I'd really rather take the gloves off and get to know people when they're not raising capital, when they really are just inspired by innovation and by customers, and they're just excited, and they're building product. That's the time I want to get to know them and see how they iterate before the capital question comes in. Because when it's capital, it tends to feel a little transactional, and that's just not the name of the game per se. +VICTORIA: It makes sense. And I'm curious, working with your partner who has a specialty in product, has there ever been a big surprise that he presented with you that you would never have thought of without that product perspective? +NEAL: Oh yeah, absolutely. I think there are many times now where either the company is really touting a specific piece of their product, whether it's a certain kind of technology that as a non-product builder either I think, wow, that's unique. That's special; that's novel. And I go to my partner, who really is an automation expert in terms of product building, and boom, can whip it out in a second and say, "I could that with Zapier," or now ChatGPT. So I think there are those elements that are good checkpoints of putting too much...maybe I get too excited about uniqueness or a novelty of a product. +And then there's the opposite. There's the team undersells their product, and really they're touting, hey, we have a background in this industry. So we're going to go build because we know how to get into that industry. Our uniqueness is go-to-market, so they think. And it turns out, hey, you're really underselling the product here. There's something special about your vision system here or your data set that you're using to build your ML model. So I've seen a variety of both of those. +I think we're going to see more and more right now where ChatGPT and other AI models are going to show that maybe the tech exactly like AI isn't the specialty. That's going to be a democratization across the board. We're just going to expect that everyone can build a baseline product. So how are people going to differentiate on the product? That's where I'm really excited to see where product stands out now that more and more people have more tools at their disposal to build a good product. +VICTORIA: Yeah, I'm excited for that too and to see which experiments with AI really pan out to be something useful that becomes part of everyday life. Do you have any instincts on where you think you're going to see the most out of AI innovation in tech? +NEAL: AI is such a big word, and it feels so buzzwordy right now. But actually, in San Diego, we have a deep history in the high-level AI, and it starts with analytics. We have a deep, deep bench of analytics talent here. In fact, Google Analytics was founded in San Diego under the name Urchin Analytics and acquired by Google in 2004. +VICTORIA: Oh. +NEAL: And so you have these big analytic models and builders here that is interesting to tap into. I kind of bucket it in a few areas. I look at the vision aspect, so motion capture, motion classification, image classification. That's really interesting that I think we'll see a lot of that that applied to blank. I'm seeing that applied to life sciences, so cancer detection through some sort of imaging. Obviously, the mobility aspect, whether it's self-driving or driver assisted for blank, whether that's drones, self-driving trucks, all those areas. That's one area interesting from the AI piece. +Natural language processing which there's a piece of ChatGPT to that regard. I think it is really interesting from what is your dataset? What are you tapping into? I'm also seeing that applied to digital health, whether it's clinical trials bringing AI models there, whether it's taking genomic data and saying, let's build better clinical trial classes. Maybe we don't need 500 patients when we can build the best 30 patients to enter a trial because we've got genomic data on our side. So yeah, I think I'm more looking at certain industries and saying, what is the right AI model for it? And I think that's pretty exciting. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +VICTORIA: So tell me, you know, at Interlock Capital, when you're working with a team, what do you use to really manage all of this information and these contacts for your investors? +NEAL: Yeah, it's a great question. We decided to build our own products in-house thanks to my partner Al who's a great product builder. At the end of the day, there are a few different funnels we are managing within Interlock Capital. We're managing our customer, which really is the startup. We want to make sure we're keeping track of them on whatever timeline. And so we use CRMs, basically, to manage funnels per se. So that's startups. +Then there's the deal flow sharing, so these are other VC firms, maybe other service providers, where we're sharing companies with each other. And then we have investors, so we're using CRM for managing our investors, like our limited partners, our LPs. So that's basic CRM. Luckily, we were able to use an off-the-shelf product called Streak for that. But what we do uniquely is we want to engage in two directions our investment community, meaning we want to get to know them, get to know everyone's expertise so we know when to tap them to say, "Hey, can you help on this deal?" +And help is very broad, meaning it could be to give it a quick look before I've even met them to say, "Is this something I should even be looking at?" Or I've already met the team, maybe spent a few hours with them. And I'm asking for a deep dive with an expert to say, "Join a call with me after you've reviewed a deck and help me ask harder questions." So there's that aspect of we wanted to figure out how do we get to know our people in our group? Because we're hundreds now. +So we decided to build a platform off Bubble.io and Airtable basic no-code where we could build a light profile of everyone. So everyone self-selects a number of profile aspects about themselves. It's also where we're starting to keep data and documents for them as well too. So whether it's tax documents or other forms, we can have it all in one spot. And then lastly, when we do decide to make an investment in a company, we write a very detailed memo that starts in Google Docs but then gets built into our product, the Interlock platform. +And so in that memo which could honestly be 10 to 20 pages of diligence, in our language only, what are the pros, cons, and risks? We also showcase who is on the diligence team, what their specific expertise is to this investment, if they're personally investing or not. We really want to show conviction from the diligence team. And then we've built in some really cool features where you've got a Q&A board that you can upvote other people's questions about that investment. +You can watch a video right there and then about the company, and then you can commit to the investment itself on our platform, saying, "I'm interested in this deal specifically. Here's the amount." And boom, we take you over to a third-party platform to just sign in and wire. So that's current day the product that we decided to build. +We've got this whole product roadmap that we've built out that we want to build out more. We would love to automate a little bit more of our deal funnel so that a certain company that we meet maybe they get to a certain stage that we know we're ready for diligence. We can auto-ping the ten people that have that specific domain expertise. +So luckily, we built out the profiles about everyone. Now we need to start building some automation in there so that maybe I'm not the bottleneck. I'm going to meet three to five companies a day, I mentioned. That's three to five follow-ups that I need to do. I'm never going to be as fast as the founder wants me to be on getting back to them and saying, "Here's our next steps." So if we can utilize the greater body of people that are in our investment community, that's where we'd love to build out some of the pieces next as well. So automation is kind of the hope there. +VICTORIA: That's great. And I love that you're able to take advantage of these low-code tools to build something that worked for you. What was your initial approach to figuring out how to build this in a way that worked for your user group? +NEAL: Well, we looked at a lot of existing products first, and there are. There are these angel syndicate websites like AngelList is a big one, you know, a consumer-facing platform where if you're interested in investing, you can join a group, or you can join a dozen groups and just get an email when they have a new investment opportunity. +And so we looked at...first, it was survey what's existing out there already. Start building a product feature must-have or is nice to have list for us to get off the ground within Interlock. And then determine the pros and cons of building off the shelf, the time and cost, and maintenance versus using something that already exists. So that was a big piece, just assessment upfront before we do anything. +And I think learning the landscape was big for us. I find that building tools for startups there's a lot, but there are also not a lot of mature ones because there's just not a lot of money out there to be made. There's not a billion-dollar industry of making a website to invest in startups per se yet. So that was another thing as well. It's just understanding will the companies that we choose off-the-shelf products-wise will they still be there a year or two or three from now? +And ultimately, we decided, you know what? We got to build it ourselves if we really want the two-way communication, not just one-way. We didn't see everything out there. And I think the piece you always underestimate is the maintenance over time as well as all the third-party tools and apps and services that you end up needing and using and how do they play into the maintenance role as well too. We've definitely had elements of our product break because they're no longer supporting that tool anymore. So those are all aspects that you can do as much as you can self-assessment upfront. There's obviously the maintenance piece that goes into it down the road as well too. +VICTORIA: That makes sense. And then, in this way, you have control over it, and you can change it as often as you want. +NEAL: Totally. +VICTORIA: And as much as you like, if you have the time. [laughs] +NEAL: One piece that I think we have never planned or expected is that because we built it and it's super unique, there are many other angel groups who have come to us and said, "Can we use your tool? Like, yours is better than anything that exists." And we did not build ours with a commercial aspect in mind at first. We can't just clone an Airtable and be like, "Here we go. Here's your product. It's Bubble and Airtable," because if it breaks for them, we're on the hook for that [laughs] as well too. +So I don't think we thought through too much around a commercialized product when we built out our own. But because we've been pinged so many times about, can people use it? It's on our mind now. Like, it literally is on our list of priorities of hiring either part-time or full-time a product builder to go back in and commercialize aspects so that we could actually maybe turn this into a product one day, this whole investment community manager software. +VICTORIA: That's really cool. And it's funny, talking to founders, there's always a story about how you set out to do one thing, which was build a community around startups and founders in San Diego, and then you end up building a product, [laughs] right? +NEAL: Yup. +VICTORIA: And getting something marketable later that you never even intended. +NEAL: Yeah, I mean, I think the big learning there is, one, listen to your customer first, then go build products. And so yes, you said it exactly; we wanted to build a community where we could be more engaged with our customer. And as we heard more and more from our customer, it told us what to build. And I always find that from other startups, that's a great model to follow as opposed to build and then go determine if there's a market out there for it. +VICTORIA: Yeah, that makes a lot of sense. So it's interesting that you've had this experience of building tech startups from scratch and then now investing, and then now you're back [laughs], and you have a product again. +NEAL: [laughs] +VICTORIA: So I wonder, if you could go back in time starting Interlock Capital or when you started your companies, like, what advice would you give yourself if you could travel back in time and talk to your past self? +NEAL: Oof, so much. Spend a lot of time getting to know yourself, not just what you're good at but what you like to do business-wise. And I actually see those are two different things. Sometimes the things we like to do we're not as good at, but yet we want to spend more of our time on it, and maybe it takes us longer to do it. So do some self-assessment. I would have done that more on myself. +And I'll give you an example, I, for whatever reason, like to brute force certain things like our email outreach, whereas my partner loves to build automation campaigns for it because he built a software in the email space. I know I could learn a quick automation route [laughs] to do certain things, but for whatever reason, I love sometimes the analog version of things. And that's good sometimes, and sometimes there's no time for that. +So learn a lot more about myself, what I like, and what I'm good at. And then the opposite, what I don't like doing, what could I shed as quickly as possible and could hire for in some way or another, trade my time or capital for time. And then, only then, once I know myself better, then go find the perfect partner that complements everything. It's the opposite of me in that regard, opposite in network, opposite in skill sets, and in that regard too. +And so I think my first startup, we were carbon copies of each other. We were both aerospace engineers who kind of wanted to do the same thing who lacked emotional intelligence at the time. So yeah, that's a big learning. But I didn't know enough about myself at the time. And it took hardship to learn the hard things. Honestly, entrepreneurs seem to learn by doing more than anything. So you can only tell an entrepreneur so much. Sometimes they're just going to have to go and figure it out by running through a wall. That's one thing I would have changed about myself in that regard. +I also probably would have, even earlier during college, gotten more internships to just test myself professionally and know what environments I do well in, meaning big companies, small company, or hands-on mentorship and management or hands-off certain kinds of skill sets. How could I be presenting more often versus just kind of behind-the-scenes doing? All of those I probably could have learned quicker about myself the earlier I would have put myself in those situations as opposed to getting my first job and working at one place for five years. That's a long time to dedicate to learning one culture about that I thrive in. But you live, and you learn. +VICTORIA: I love the drive to keep learning and to be like, you know, don't expect to be good at everything [laughs] that you want to do. I think that's fantastic. And what do you see success really looking like for yourself in the next six months or in the next five years? +NEAL: This year, this calendar year is really about getting the fund up and running. So we've raised an initial tranche of capital and got through this calendar year to get the full capital we want for the fund in. And we're being really picky about that. We really want operators, so that just takes time to go and meet the right people that maybe have recently exited, so have a little bit of time and have a little capital and now want to spend time with earlier stage companies. So that's a big piece of this year. +I also, on the community side, want to scale it a little bit. I've found recurring...like the founders' hike is a really consistent and easy way to build community, just meet new people, get to meet 30 people at once instead of maybe 30 coffee meetings to meet those people and just kind of selectively choose who is good to follow up with. So building and scaling, thinking about how to scale community growth is another area, and hiring a little bit around that. +So hiring either a community manager and understanding what does that role even mean? Because it's vague in a variety of scenarios. I think we as a company could utilize it. But I think even San Diego could really benefit from someone professionally community-managing all of us. I don't even know what that means yet. And I'd actually push that back on you. Like, you're recent to town. You've started to meet people in a variety of venues. What's the community management void that you see that exists locally? +VICTORIA: Oh, great question. I'm actually going to the Annual March Mingle tonight. This episode will come out a little bit later. +NEAL: I'll be there too. +VICTORIA: Oh, I was like, I'm going to interview you and probably see you later. [laughs] +NEAL: Awesome. +VICTORIA: Yeah, I think what's interesting about what I've experienced so far is that there is a thriving community. People show up to events. There are a lot of different focuses and specialties. Like, there's the San Diego Design and Accessibility meetup, which had over 30 people over and has a lot of great content. The tech coffees usually have your standard crew who comes. +I'm in North County in Encinitas, and then there's Downtown San Diego. And I think you and I have talked about this, that there isn't as much of a major hub. And people are kind of spread out and don't really like to travel outside of their little bubble, which isn't necessarily unique to San Diego. [laughs] I think we've seen this in other areas too. So I think deciding where and how and maybe just building that group of community organizers too. One thing we had in DC was we would have a meetup of all the meetup organizers. [laughs] +NEAL: Ooh. +VICTORIA: They were just the people who are running events would get together and meet each other and talk and get ideas and bounce off, and maybe that exists in San Diego, but I just haven't tapped into it yet. +NEAL: Well, that's a great, great, great, great point because, yeah, learning from others. Everyone is out there doing. Let's learn what's working and what's not. I do that actually from community to community. I do compare...I'll pop into a city on personal travel, but I'll look for, say, the Neal Bloom of Phoenix or something [laughter] and share quick notes. Something Startup San Diego started... when Startup San Diego started ten years ago and became a nonprofit shortly thereafter, it wanted to be the convener of all the organizations that help startups. +And so there became kind of the startup alliance, I think, where it was all people who run different startup orgs, mostly nonprofits or just meetups getting together. And that hasn't come back since COVID, and I don't know if anyone's thought to bring it back. So this is a great time to think about that. Let's do it. Let's absolutely get the startup community alliance back together and sharing what's working and what's not. +Something else that I think matters as we're coming out of COVID and really matters also for product is it feels like curation matters way more than anything before. Like, we value our time more. We want to be home a bit more. And so we're only going to go to the things that we know there's some value out of it as opposed to, oh, I'll show up to that thing. It sounds cool. I get free pizza. +So the curation piece, I think, is interesting to think about, like, how do you scale curation? Because if you make smaller groups and make it more valuable, you still can't make a group for everyone. Someone's always going to be missing out. That's a piece when I think of how has product worked really well for that? Obviously, product has done amazing things on curation with using filters and ranking and other things. How do you do that in real-time for community? +VICTORIA: Yeah, that's a really cool idea. And it's interesting talking with organizers from Women Who Code DC who are still there and coming back from COVID. They were all virtual events, and now they're having part virtual and part in-person. And it's interesting where some people really want to get back to the in person and see people in real life. The virtual is also still a very good option for people altogether across the board. +So, yeah, I think you're 100% right on the event has to be kind of worth it. [laughs] And how do we make that real? But we still have all these other options for connecting with each other too, and we should take advantage of this. I love that here if we're going out in person, you're on a patio. [laughs] You're outside. Even though it's pouring down rain right now so we're probably going to get rained out a little bit. +NEAL: I don't think I realized how outdoorsy we already were until this recent rain, one, because COVID forced everyone outdoors already. So for the last three years, we've only been going to places that have been outdoors. But then I realized, wait, every coffee shop I go to already is just open air. Every brewery, every restaurant is open-air. We've got it pretty good here. March Mingle, as big as it is, which it's like you're 17, 18, maybe 20, it's always an amazingly cool crowd and a crowd that I don't always see at every event. It's not the same, same people. It's a crowd that just comes to March Mingle. +VICTORIA: That's super cool. I'm excited to see you there later. And maybe by the time we've aired this episode, I'll have actually posted about it, so it won't be a surprise [laughs] for anybody. But I love that. Okay, so, wait, that was...did we talk about six months and five years into the future of success? +NEAL: We didn't. We just talked this calendar year. Five years out, professionally, I think a well-oiled community, multiple funds under management that maybe have realized, like, let's have one with different focus. Maybe there's an infrastructure tech fund, maybe there's a diabetes tech fund. I'd love to explore the curated focused thesis aspects because it's easy to be pretty general when I'm meeting so many interesting companies, and I have so many experts at my disposal. Maybe it makes sense to have multiple smaller focused funds in that regard. +I think five years out; also, we will have probably weathered some financial storms, probably be on the upswing of that, and therefore maybe there are some exits that would have happened in town. There's certainly a number of late-stage tech companies that have been at it 10, 15 years that a lot of early investors and employees with stock are just kind of waiting for a liquidity event, and I really think by then we will have seen that. And that will be really interesting to see if and how people recycle their capital back into the community, both from investing, from giving philanthropically, and then their time as well. +Sometimes when you have really big success, it's easy to check out and leave, and I'm hoping we're getting ahead of that cycle now. We're getting people to put some skin in the game now so that when the exits happen, they stay connected because they're got some investments in the community. So I'm really hoping that we've closed the wheel on the flywheel of capital, recyclable capital here in San Diego five years out from now. +VICTORIA: Oh, I really like that. And I think it makes sense from that idea of if you've benefited from being able to run your own company and to work with all these people in San Diego that when you exit, you invest that back into the community and grow future companies with it. +NEAL: Exactly. I mean, someone helped you, all of us, and they're just ahead of us. It kind of behooves all of us; then, to each stage and phase we go forward, we should look back and say, "How can we help someone behind us?" And we started this conversation that is a very San Diego culture thing. And so I'm really excited to see when that line bends back on itself, that flywheel closes. +So the other aspects of that is we're starting to build some crossroads with Tijuana. We tried before COVID, and we're trying again now. And I'm really excited to see the long-term effect of connecting these cross-border communities. And then we talked about some technology, five years out, man, if GPT is updating so quickly now, I can't even imagine what AI is building product by itself five years from now. And where do the humans play a role in that? +People love the splashy headline articles of here's where AI is going to replace your jobs. I'm thinking quite the opposite. I'm so excited for the new jobs to emerge that don't exist right now, for us to complement technology, that, you know, we'll be doing things that are better than humans. So that's a whole piece of technology and product that I'm excited to see play out. +VICTORIA: I agree. I think that it's humans plus machines make the most impact, right? [laughs] +NEAL: Exactly. +VICTORIA: It by itself won't do it. But I think that's fantastic. What a great note to kind of end on. But is there anything else that you want as a final takeaway for our listeners? +NEAL: One, I'd love to meet you if you're building an interesting product. I'd love to connect you into our community, so that's a self-serving ask. Find me on LinkedIn or Twitter; probably, Twitter's easier. Write me that you heard me on Giant Robots Smashing Into Others. Absolutely would love to hear that feedback loop. Also, come check out San Diego sometime. Come join our founders' hike. If you're listening to this, pretty much we have it on every first Wednesday of each month. We'd love to welcome you into the community here. +And if you have an idea for a startup but haven't started yet, that's a great time to be talking and thinking how could I iterate way sooner than you would have thought. So don't wait to get started on something; just start talking to people about it. Don't be afraid to share your product ideas. No one's going to steal it. So I would just tell people to get started sooner than you think. And the world will benefit from you putting that out into the universe. +VICTORIA: I love that. Thank you so much for sharing and for being a guest on our show today, Neal. We'll have links for how to get connected with you in our show notes. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Neal Bloom. + + + Neal Bloom is a Managing Partner at Interlock Capital, a community of founders, investors, and subject matter experts.

+ +

Victoria talks to Neal about what he finds attractive about startups and companies he's excited about, out of all the pitches he receives, how many he gets to say yes to, and when working with a team, what he uses to manage information and contacts for investors.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Neal Bloom, Managing Partner at Interlock Capital, a community of founders, investors, and subject matter experts. Neal, thank you for joining us.

+ +

NEAL: Hey, thanks for having me. It's so great to be here with you.

+ +

VICTORIA: Fantastic. I'm excited to finally get a chance to talk with you. I met you at an investor hike that you organize once a month.

+ +

NEAL: A founders' hike, yeah. I get up nice and early on the first Wednesday of each month in Torrey Pines in San Diego. And we hike up and down the hill with ocean views. It's not a bad day.

+ +

VICTORIA: It's a great way to start the morning, I think, and to meet other people, other builders of products in technology. So tell me more about your work at Interlock Capital.

+ +

NEAL: Sure. It really kind of organically happened that I became an investor, but not planned at all. I have an aerospace background then built my own edtech and talent tech marketplace. I call it the LinkedIn for students is really what we built as our first startup called Portfolium. We sold it, and I got really into startup communities, especially because of some people who helped me with my first startup. I want to be a part of building an even better ecosystem for others. And that turned into a podcast, a blog, an event series.

+ +

And once I had the capital from my exit, turned into angel investing as well, too, and really just found that as I got to know people over time, the more and more I got to know them, the more certain ones stood out that said, wow, I don't just want to help them for the good of it. I also just want to be along for the ride. And I started writing checks to other founders. So that was the beginning of my investor journey about five years ago.

+ +

And over COVID, a whole bunch of other later-stage experience operators, either founder-level or executives at tech companies, said, "I want to learn to do this. Can I do it alongside you?" And we created Interlock Capital as an investment syndicate. A group of us can share and utilize our brainpower, our time, and our capital to help companies. It's kind of our focus.

+ +

So that's why we call it a community because it's not just kind of a one-way pitch us, and we'll write you a check. It's very much get to know the people, find the exact right domain experts who have subject matter expertise, who've been there and done that before. If they like the company and they want to personally invest, then we go to the greater group and say, "Hey, everyone, who wants to join this deal specifically?"

+ +

So 18 investments later from Interlock Capital, we now also have an investment fund. So now we write two checks into every company. We do our syndicated style, pass the hat, if you will, "Hey, everyone, anyone want to invest in just this deal?" And then match it from our fund. And we're writing between $300,000 to $500,000 checks into early-stage software or/and software plus hardware companies.

+ +

VICTORIA: What an incredible journey. And I love that it's led you to creating a community as part of what you do as an investment capital group. What do you find interesting about these startups and these companies that you want to be interested in?

+ +

NEAL: Part of it is how much you learn about yourself, to be honest. I get to meet three to five new founders a day in a variety of ways, whether it's straight Zoom and pitch, or grab a coffee, or see them on a hike. We're kind of constantly introducing ourselves to each other. There's a bit of learning about how to size someone up to a certain regard. So you're kind of building this inner algorithm of how to top-prank people and their ideas. That's one interesting way that I never thought I would be doing professionally.

+ +

There's a lot that we say versus what we do, and that's a data point that I have to keep track of because I get pitched amazing ideas that will literally change the world for so much better. And you get really excited about it, and you get invested in it. And I call it founder love. You fall in love with these founders specifically and almost say, "I don't even care what you're working on. I just want to work more with you. How do we do it?" So there's a lot of that.

+ +

So there are some dating aspects [laughs] in terms of founder dating, like getting to know people. There's the determining how do we date towards marriage? Meaning, I'll write you a check, and I'm along for the ride for the next ten years. And then there's the kind of relationship maintenance which is okay; I wrote the check, now what?

+ +

Where can I be helpful to the company? How can I anticipate their needs so that they have to think one more thing of how to satisfy me? It's quite the opposite way around. I'm trying not to be a barrier. I'm trying to work for them while they're sleeping. So yeah, it's really interesting the kind of the relationship aspect that goes into getting to know and helping founders take their ideas and turn it into reality.

+ +

VICTORIA: That's very cool. And I have talked to people who have met you and talked to your company and just how supportive and helpful you all are even if you choose not to invest. So I think that's a really valuable resource for people. And I wonder, do you think it's something unique about the San Diego community in particular that is exciting right now?

+ +

NEAL: I think so. I think San Diego specifically has always had this culture of give-before-you-get mentality, and so we kind of lead with that. There are a lot of people moving here. And you could choose many places that could be great, like LA versus San Diego, and there's a certain kind of person that chooses here versus somewhere else. And what I have found is there's a certain kind of give-before-you-get cultural mentality here that somehow people register pretty quickly and come with. And so that's an underlying greatness about us here.

+ +

There's also because of the great environment we live in, by the beach, healthy lifestyle. I think we choose to work on things that maybe are also satisfying, just like our personal lives, meaning we work on things that matter, that are going to change the world, that are life-changing. That's not to say that we don't need certain other kinds of technology. I'm sure at some point, we felt we needed Twitter, and maybe we don't feel like that now. [laughs]

+ +

But here, it feels like everyone's working on very impactful things, and I think that's really special to think about. Some examples of that is we've got an interesting subset of the SaaS world in nonprofit tech. So GoFundMe was founded in San Diego. They have since acquired three other nonprofit tech SaaS companies in San Diego, like Classy. So that's kind of interesting. You've got people who want to build a business that services nonprofits, and now they're all under one roof. So yeah, I think there is something special. We can dive deeper into some of the other sub-industries or categories that are interesting here, too, if you're interested.

+ +

VICTORIA: Well, I could talk about San Diego all day.

+ +

NEAL: [laughs]

+ +

VICTORIA: Because I'm a fairly new resident, and I'm in love with it, obviously. [laughs] But let's talk more about products that can change the world. Like, what's one that you're really excited about that you've heard recently?

+ +

NEAL: Ooh. I would start a little high level in certain categories that I'm really liking. I like things I'm seeing in the infrastructure space right now, meaning, you know, whether it's pipes and our water utilities, and I would include that in energy and EV, you know, kind of a mobility piece. There's even the commercial side of mobility, so trucking and freight. That whole infrastructure layer is really interesting to me right now.

+ +

A certain company that, full disclosure, we invested in recently is a company called EarthGrid. They have a product that is boring holes tunnel-wise underground, but they're using just electricity and air, so plasma. And it's fascinating. They can bore holes 100 times the norm right now. They don't need to potentially trench, meaning they don't need to cut above the surface. They can just dig for miles straight underneath the ground, so they can go under things with that. And really a lot of the expensive pieces, closing lanes on freeways or highways to put fiber in or plumbing and all that. So it's really interesting to see that.

+ +

Now, one element is the technology is interesting. But they have a plan to actually own their own tunnels that go across the entire United States. So they don't just want to be a device that they're going to sell to everyone. They want to actually own their own utility that has major tunnels across the United States. So that's fascinating to me because that's like think big, think exponential around that. So that's one area that's kind of fascinating to me.

+ +

VICTORIA: That's super interesting, and thinking about the impact it can have on making power more secure for more people, things like that. There are just so many problems to solve, and so many are people trying to solve them. [laughs] -

+ +

NEAL: Yeah, exactly. And they have a clean tech angle in that there are a lot of different ways to dig and tunnel that includes chemicals, and so their big thing is to not do that. Some of their background is installing these kinds of lines in the EV space for solar panels. So they have a big kind of clean and sustainability focus there. And our infrastructure is aging big time. We've got 100-year-old bridges and pipes and other things that it's really interesting to see the government put money into. And so that is another aspect, a business model, per se of infrastructure.

+ +

You have the government putting billions, if not trillions, into upgrading our infrastructure, which as an investor, I like to hear that there's free capital out there in forms of non-dilutive funding to help these along, and that's existed for hundreds of years. Cars and oil industry got these kinds of subsidies, and then the EV and solar panels. So that's a good area that I like to look in as well is where is there additional large-scale funding to help these products really get to market?

+ +

VICTORIA: That makes sense. And so you're meeting three to five founders a day, and you're watching where the funding is available. And out of all the pitches that you receive, how many do you really get to say yes to?

+ +

NEAL: Oh, it's small, I mean, one to two a month if that would be a lot, and those could take a few months to work through. The best way for us to invest is to get to know the people for as long as possible. So I kind of mentioned that relationship aspect. I want to see how people operate. I want to see how they build product. I want to see how they get to know their customer and iterate and bring that back into design thinking. And so that's a big piece is getting to know and see the people do the things that they're saying.

+ +

Man, there are so many companies that I like on paper, whether it's oh my God, amazing team, or, oh, cool, the product. Yes, love that idea. And then you have to look at everything together, the timing, the valuation that they want, the team. Has this team been there, done that before? So there are a lot of elements that go into it. Like I mentioned, you have this founder love where you fall in love with the people, and maybe the rest doesn't work out or vice versa. But yeah, I think each investor comes at it differently.

+ +

So my area because I built two tech companies that were talent tech-related, meaning connecting people for opportunities; my investing style is very team and talent and recruitment-focused, meaning what are the superpowers of the founders? Are they aware of their weaknesses and their strengths? Have they filled in those gaps by finding co-founders that are complementary and opposites?

+ +

And then my partner, Al Bsharah, he is a super product guy, and he wants to break the product and see, how can you break it? What are they thinking product roadmap-wise? That's his first go-to. And so, for us, we're super complementary in that regard. So we will assess the same company in very different ways and then come together and say, "Let's share our scores, share our rank. Where do you think this company sits at in all these different areas and boxes?" And so that's a great way, that complementary skill sets as investors. We utilize those strengths together.

+ +

So yeah, it's hard for a founder to know that. A founder who's building a product, the person on the other side of the screen, they're meeting me. They're not going to know my algorithm. They're not going to know what I value more than something else. So there's this whole dance. I wish it didn't have to be that way, but it is a dance. It's a negotiation.

+ +

And that's why I build a community because I'd really rather take the gloves off and get to know people when they're not raising capital, when they really are just inspired by innovation and by customers, and they're just excited, and they're building product. That's the time I want to get to know them and see how they iterate before the capital question comes in. Because when it's capital, it tends to feel a little transactional, and that's just not the name of the game per se.

+ +

VICTORIA: It makes sense. And I'm curious, working with your partner who has a specialty in product, has there ever been a big surprise that he presented with you that you would never have thought of without that product perspective?

+ +

NEAL: Oh yeah, absolutely. I think there are many times now where either the company is really touting a specific piece of their product, whether it's a certain kind of technology that as a non-product builder either I think, wow, that's unique. That's special; that's novel. And I go to my partner, who really is an automation expert in terms of product building, and boom, can whip it out in a second and say, "I could that with Zapier," or now ChatGPT. So I think there are those elements that are good checkpoints of putting too much...maybe I get too excited about uniqueness or a novelty of a product.

+ +

And then there's the opposite. There's the team undersells their product, and really they're touting, hey, we have a background in this industry. So we're going to go build because we know how to get into that industry. Our uniqueness is go-to-market, so they think. And it turns out, hey, you're really underselling the product here. There's something special about your vision system here or your data set that you're using to build your ML model. So I've seen a variety of both of those.

+ +

I think we're going to see more and more right now where ChatGPT and other AI models are going to show that maybe the tech exactly like AI isn't the specialty. That's going to be a democratization across the board. We're just going to expect that everyone can build a baseline product. So how are people going to differentiate on the product? That's where I'm really excited to see where product stands out now that more and more people have more tools at their disposal to build a good product.

+ +

VICTORIA: Yeah, I'm excited for that too and to see which experiments with AI really pan out to be something useful that becomes part of everyday life. Do you have any instincts on where you think you're going to see the most out of AI innovation in tech?

+ +

NEAL: AI is such a big word, and it feels so buzzwordy right now. But actually, in San Diego, we have a deep history in the high-level AI, and it starts with analytics. We have a deep, deep bench of analytics talent here. In fact, Google Analytics was founded in San Diego under the name Urchin Analytics and acquired by Google in 2004.

+ +

VICTORIA: Oh.

+ +

NEAL: And so you have these big analytic models and builders here that is interesting to tap into. I kind of bucket it in a few areas. I look at the vision aspect, so motion capture, motion classification, image classification. That's really interesting that I think we'll see a lot of that that applied to blank. I'm seeing that applied to life sciences, so cancer detection through some sort of imaging. Obviously, the mobility aspect, whether it's self-driving or driver assisted for blank, whether that's drones, self-driving trucks, all those areas. That's one area interesting from the AI piece.

+ +

Natural language processing which there's a piece of ChatGPT to that regard. I think it is really interesting from what is your dataset? What are you tapping into? I'm also seeing that applied to digital health, whether it's clinical trials bringing AI models there, whether it's taking genomic data and saying, let's build better clinical trial classes. Maybe we don't need 500 patients when we can build the best 30 patients to enter a trial because we've got genomic data on our side. So yeah, I think I'm more looking at certain industries and saying, what is the right AI model for it? And I think that's pretty exciting.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: So tell me, you know, at Interlock Capital, when you're working with a team, what do you use to really manage all of this information and these contacts for your investors?

+ +

NEAL: Yeah, it's a great question. We decided to build our own products in-house thanks to my partner Al who's a great product builder. At the end of the day, there are a few different funnels we are managing within Interlock Capital. We're managing our customer, which really is the startup. We want to make sure we're keeping track of them on whatever timeline. And so we use CRMs, basically, to manage funnels per se. So that's startups.

+ +

Then there's the deal flow sharing, so these are other VC firms, maybe other service providers, where we're sharing companies with each other. And then we have investors, so we're using CRM for managing our investors, like our limited partners, our LPs. So that's basic CRM. Luckily, we were able to use an off-the-shelf product called Streak for that. But what we do uniquely is we want to engage in two directions our investment community, meaning we want to get to know them, get to know everyone's expertise so we know when to tap them to say, "Hey, can you help on this deal?"

+ +

And help is very broad, meaning it could be to give it a quick look before I've even met them to say, "Is this something I should even be looking at?" Or I've already met the team, maybe spent a few hours with them. And I'm asking for a deep dive with an expert to say, "Join a call with me after you've reviewed a deck and help me ask harder questions." So there's that aspect of we wanted to figure out how do we get to know our people in our group? Because we're hundreds now.

+ +

So we decided to build a platform off Bubble.io and Airtable basic no-code where we could build a light profile of everyone. So everyone self-selects a number of profile aspects about themselves. It's also where we're starting to keep data and documents for them as well too. So whether it's tax documents or other forms, we can have it all in one spot. And then lastly, when we do decide to make an investment in a company, we write a very detailed memo that starts in Google Docs but then gets built into our product, the Interlock platform.

+ +

And so in that memo which could honestly be 10 to 20 pages of diligence, in our language only, what are the pros, cons, and risks? We also showcase who is on the diligence team, what their specific expertise is to this investment, if they're personally investing or not. We really want to show conviction from the diligence team. And then we've built in some really cool features where you've got a Q&A board that you can upvote other people's questions about that investment.

+ +

You can watch a video right there and then about the company, and then you can commit to the investment itself on our platform, saying, "I'm interested in this deal specifically. Here's the amount." And boom, we take you over to a third-party platform to just sign in and wire. So that's current day the product that we decided to build.

+ +

We've got this whole product roadmap that we've built out that we want to build out more. We would love to automate a little bit more of our deal funnel so that a certain company that we meet maybe they get to a certain stage that we know we're ready for diligence. We can auto-ping the ten people that have that specific domain expertise.

+ +

So luckily, we built out the profiles about everyone. Now we need to start building some automation in there so that maybe I'm not the bottleneck. I'm going to meet three to five companies a day, I mentioned. That's three to five follow-ups that I need to do. I'm never going to be as fast as the founder wants me to be on getting back to them and saying, "Here's our next steps." So if we can utilize the greater body of people that are in our investment community, that's where we'd love to build out some of the pieces next as well. So automation is kind of the hope there.

+ +

VICTORIA: That's great. And I love that you're able to take advantage of these low-code tools to build something that worked for you. What was your initial approach to figuring out how to build this in a way that worked for your user group?

+ +

NEAL: Well, we looked at a lot of existing products first, and there are. There are these angel syndicate websites like AngelList is a big one, you know, a consumer-facing platform where if you're interested in investing, you can join a group, or you can join a dozen groups and just get an email when they have a new investment opportunity.

+ +

And so we looked at...first, it was survey what's existing out there already. Start building a product feature must-have or is nice to have list for us to get off the ground within Interlock. And then determine the pros and cons of building off the shelf, the time and cost, and maintenance versus using something that already exists. So that was a big piece, just assessment upfront before we do anything.

+ +

And I think learning the landscape was big for us. I find that building tools for startups there's a lot, but there are also not a lot of mature ones because there's just not a lot of money out there to be made. There's not a billion-dollar industry of making a website to invest in startups per se yet. So that was another thing as well. It's just understanding will the companies that we choose off-the-shelf products-wise will they still be there a year or two or three from now?

+ +

And ultimately, we decided, you know what? We got to build it ourselves if we really want the two-way communication, not just one-way. We didn't see everything out there. And I think the piece you always underestimate is the maintenance over time as well as all the third-party tools and apps and services that you end up needing and using and how do they play into the maintenance role as well too. We've definitely had elements of our product break because they're no longer supporting that tool anymore. So those are all aspects that you can do as much as you can self-assessment upfront. There's obviously the maintenance piece that goes into it down the road as well too.

+ +

VICTORIA: That makes sense. And then, in this way, you have control over it, and you can change it as often as you want.

+ +

NEAL: Totally.

+ +

VICTORIA: And as much as you like, if you have the time. [laughs]

+ +

NEAL: One piece that I think we have never planned or expected is that because we built it and it's super unique, there are many other angel groups who have come to us and said, "Can we use your tool? Like, yours is better than anything that exists." And we did not build ours with a commercial aspect in mind at first. We can't just clone an Airtable and be like, "Here we go. Here's your product. It's Bubble and Airtable," because if it breaks for them, we're on the hook for that [laughs] as well too.

+ +

So I don't think we thought through too much around a commercialized product when we built out our own. But because we've been pinged so many times about, can people use it? It's on our mind now. Like, it literally is on our list of priorities of hiring either part-time or full-time a product builder to go back in and commercialize aspects so that we could actually maybe turn this into a product one day, this whole investment community manager software.

+ +

VICTORIA: That's really cool. And it's funny, talking to founders, there's always a story about how you set out to do one thing, which was build a community around startups and founders in San Diego, and then you end up building a product, [laughs] right?

+ +

NEAL: Yup.

+ +

VICTORIA: And getting something marketable later that you never even intended.

+ +

NEAL: Yeah, I mean, I think the big learning there is, one, listen to your customer first, then go build products. And so yes, you said it exactly; we wanted to build a community where we could be more engaged with our customer. And as we heard more and more from our customer, it told us what to build. And I always find that from other startups, that's a great model to follow as opposed to build and then go determine if there's a market out there for it.

+ +

VICTORIA: Yeah, that makes a lot of sense. So it's interesting that you've had this experience of building tech startups from scratch and then now investing, and then now you're back [laughs], and you have a product again.

+ +

NEAL: [laughs]

+ +

VICTORIA: So I wonder, if you could go back in time starting Interlock Capital or when you started your companies, like, what advice would you give yourself if you could travel back in time and talk to your past self?

+ +

NEAL: Oof, so much. Spend a lot of time getting to know yourself, not just what you're good at but what you like to do business-wise. And I actually see those are two different things. Sometimes the things we like to do we're not as good at, but yet we want to spend more of our time on it, and maybe it takes us longer to do it. So do some self-assessment. I would have done that more on myself.

+ +

And I'll give you an example, I, for whatever reason, like to brute force certain things like our email outreach, whereas my partner loves to build automation campaigns for it because he built a software in the email space. I know I could learn a quick automation route [laughs] to do certain things, but for whatever reason, I love sometimes the analog version of things. And that's good sometimes, and sometimes there's no time for that.

+ +

So learn a lot more about myself, what I like, and what I'm good at. And then the opposite, what I don't like doing, what could I shed as quickly as possible and could hire for in some way or another, trade my time or capital for time. And then, only then, once I know myself better, then go find the perfect partner that complements everything. It's the opposite of me in that regard, opposite in network, opposite in skill sets, and in that regard too.

+ +

And so I think my first startup, we were carbon copies of each other. We were both aerospace engineers who kind of wanted to do the same thing who lacked emotional intelligence at the time. So yeah, that's a big learning. But I didn't know enough about myself at the time. And it took hardship to learn the hard things. Honestly, entrepreneurs seem to learn by doing more than anything. So you can only tell an entrepreneur so much. Sometimes they're just going to have to go and figure it out by running through a wall. That's one thing I would have changed about myself in that regard.

+ +

I also probably would have, even earlier during college, gotten more internships to just test myself professionally and know what environments I do well in, meaning big companies, small company, or hands-on mentorship and management or hands-off certain kinds of skill sets. How could I be presenting more often versus just kind of behind-the-scenes doing? All of those I probably could have learned quicker about myself the earlier I would have put myself in those situations as opposed to getting my first job and working at one place for five years. That's a long time to dedicate to learning one culture about that I thrive in. But you live, and you learn.

+ +

VICTORIA: I love the drive to keep learning and to be like, you know, don't expect to be good at everything [laughs] that you want to do. I think that's fantastic. And what do you see success really looking like for yourself in the next six months or in the next five years?

+ +

NEAL: This year, this calendar year is really about getting the fund up and running. So we've raised an initial tranche of capital and got through this calendar year to get the full capital we want for the fund in. And we're being really picky about that. We really want operators, so that just takes time to go and meet the right people that maybe have recently exited, so have a little bit of time and have a little capital and now want to spend time with earlier stage companies. So that's a big piece of this year.

+ +

I also, on the community side, want to scale it a little bit. I've found recurring...like the founders' hike is a really consistent and easy way to build community, just meet new people, get to meet 30 people at once instead of maybe 30 coffee meetings to meet those people and just kind of selectively choose who is good to follow up with. So building and scaling, thinking about how to scale community growth is another area, and hiring a little bit around that.

+ +

So hiring either a community manager and understanding what does that role even mean? Because it's vague in a variety of scenarios. I think we as a company could utilize it. But I think even San Diego could really benefit from someone professionally community-managing all of us. I don't even know what that means yet. And I'd actually push that back on you. Like, you're recent to town. You've started to meet people in a variety of venues. What's the community management void that you see that exists locally?

+ +

VICTORIA: Oh, great question. I'm actually going to the Annual March Mingle tonight. This episode will come out a little bit later.

+ +

NEAL: I'll be there too.

+ +

VICTORIA: Oh, I was like, I'm going to interview you and probably see you later. [laughs]

+ +

NEAL: Awesome.

+ +

VICTORIA: Yeah, I think what's interesting about what I've experienced so far is that there is a thriving community. People show up to events. There are a lot of different focuses and specialties. Like, there's the San Diego Design and Accessibility meetup, which had over 30 people over and has a lot of great content. The tech coffees usually have your standard crew who comes.

+ +

I'm in North County in Encinitas, and then there's Downtown San Diego. And I think you and I have talked about this, that there isn't as much of a major hub. And people are kind of spread out and don't really like to travel outside of their little bubble, which isn't necessarily unique to San Diego. [laughs] I think we've seen this in other areas too. So I think deciding where and how and maybe just building that group of community organizers too. One thing we had in DC was we would have a meetup of all the meetup organizers. [laughs]

+ +

NEAL: Ooh.

+ +

VICTORIA: They were just the people who are running events would get together and meet each other and talk and get ideas and bounce off, and maybe that exists in San Diego, but I just haven't tapped into it yet.

+ +

NEAL: Well, that's a great, great, great, great point because, yeah, learning from others. Everyone is out there doing. Let's learn what's working and what's not. I do that actually from community to community. I do compare...I'll pop into a city on personal travel, but I'll look for, say, the Neal Bloom of Phoenix or something [laughter] and share quick notes. Something Startup San Diego started... when Startup San Diego started ten years ago and became a nonprofit shortly thereafter, it wanted to be the convener of all the organizations that help startups.

+ +

And so there became kind of the startup alliance, I think, where it was all people who run different startup orgs, mostly nonprofits or just meetups getting together. And that hasn't come back since COVID, and I don't know if anyone's thought to bring it back. So this is a great time to think about that. Let's do it. Let's absolutely get the startup community alliance back together and sharing what's working and what's not.

+ +

Something else that I think matters as we're coming out of COVID and really matters also for product is it feels like curation matters way more than anything before. Like, we value our time more. We want to be home a bit more. And so we're only going to go to the things that we know there's some value out of it as opposed to, oh, I'll show up to that thing. It sounds cool. I get free pizza.

+ +

So the curation piece, I think, is interesting to think about, like, how do you scale curation? Because if you make smaller groups and make it more valuable, you still can't make a group for everyone. Someone's always going to be missing out. That's a piece when I think of how has product worked really well for that? Obviously, product has done amazing things on curation with using filters and ranking and other things. How do you do that in real-time for community?

+ +

VICTORIA: Yeah, that's a really cool idea. And it's interesting talking with organizers from Women Who Code DC who are still there and coming back from COVID. They were all virtual events, and now they're having part virtual and part in-person. And it's interesting where some people really want to get back to the in person and see people in real life. The virtual is also still a very good option for people altogether across the board.

+ +

So, yeah, I think you're 100% right on the event has to be kind of worth it. [laughs] And how do we make that real? But we still have all these other options for connecting with each other too, and we should take advantage of this. I love that here if we're going out in person, you're on a patio. [laughs] You're outside. Even though it's pouring down rain right now so we're probably going to get rained out a little bit.

+ +

NEAL: I don't think I realized how outdoorsy we already were until this recent rain, one, because COVID forced everyone outdoors already. So for the last three years, we've only been going to places that have been outdoors. But then I realized, wait, every coffee shop I go to already is just open air. Every brewery, every restaurant is open-air. We've got it pretty good here. March Mingle, as big as it is, which it's like you're 17, 18, maybe 20, it's always an amazingly cool crowd and a crowd that I don't always see at every event. It's not the same, same people. It's a crowd that just comes to March Mingle.

+ +

VICTORIA: That's super cool. I'm excited to see you there later. And maybe by the time we've aired this episode, I'll have actually posted about it, so it won't be a surprise [laughs] for anybody. But I love that. Okay, so, wait, that was...did we talk about six months and five years into the future of success?

+ +

NEAL: We didn't. We just talked this calendar year. Five years out, professionally, I think a well-oiled community, multiple funds under management that maybe have realized, like, let's have one with different focus. Maybe there's an infrastructure tech fund, maybe there's a diabetes tech fund. I'd love to explore the curated focused thesis aspects because it's easy to be pretty general when I'm meeting so many interesting companies, and I have so many experts at my disposal. Maybe it makes sense to have multiple smaller focused funds in that regard.

+ +

I think five years out; also, we will have probably weathered some financial storms, probably be on the upswing of that, and therefore maybe there are some exits that would have happened in town. There's certainly a number of late-stage tech companies that have been at it 10, 15 years that a lot of early investors and employees with stock are just kind of waiting for a liquidity event, and I really think by then we will have seen that. And that will be really interesting to see if and how people recycle their capital back into the community, both from investing, from giving philanthropically, and then their time as well.

+ +

Sometimes when you have really big success, it's easy to check out and leave, and I'm hoping we're getting ahead of that cycle now. We're getting people to put some skin in the game now so that when the exits happen, they stay connected because they're got some investments in the community. So I'm really hoping that we've closed the wheel on the flywheel of capital, recyclable capital here in San Diego five years out from now.

+ +

VICTORIA: Oh, I really like that. And I think it makes sense from that idea of if you've benefited from being able to run your own company and to work with all these people in San Diego that when you exit, you invest that back into the community and grow future companies with it.

+ +

NEAL: Exactly. I mean, someone helped you, all of us, and they're just ahead of us. It kind of behooves all of us; then, to each stage and phase we go forward, we should look back and say, "How can we help someone behind us?" And we started this conversation that is a very San Diego culture thing. And so I'm really excited to see when that line bends back on itself, that flywheel closes.

+ +

So the other aspects of that is we're starting to build some crossroads with Tijuana. We tried before COVID, and we're trying again now. And I'm really excited to see the long-term effect of connecting these cross-border communities. And then we talked about some technology, five years out, man, if GPT is updating so quickly now, I can't even imagine what AI is building product by itself five years from now. And where do the humans play a role in that?

+ +

People love the splashy headline articles of here's where AI is going to replace your jobs. I'm thinking quite the opposite. I'm so excited for the new jobs to emerge that don't exist right now, for us to complement technology, that, you know, we'll be doing things that are better than humans. So that's a whole piece of technology and product that I'm excited to see play out.

+ +

VICTORIA: I agree. I think that it's humans plus machines make the most impact, right? [laughs]

+ +

NEAL: Exactly.

+ +

VICTORIA: It by itself won't do it. But I think that's fantastic. What a great note to kind of end on. But is there anything else that you want as a final takeaway for our listeners?

+ +

NEAL: One, I'd love to meet you if you're building an interesting product. I'd love to connect you into our community, so that's a self-serving ask. Find me on LinkedIn or Twitter; probably, Twitter's easier. Write me that you heard me on Giant Robots Smashing Into Others. Absolutely would love to hear that feedback loop. Also, come check out San Diego sometime. Come join our founders' hike. If you're listening to this, pretty much we have it on every first Wednesday of each month. We'd love to welcome you into the community here.

+ +

And if you have an idea for a startup but haven't started yet, that's a great time to be talking and thinking how could I iterate way sooner than you would have thought. So don't wait to get started on something; just start talking to people about it. Don't be afraid to share your product ideas. No one's going to steal it. So I would just tell people to get started sooner than you think. And the world will benefit from you putting that out into the universe.

+ +

VICTORIA: I love that. Thank you so much for sharing and for being a guest on our show today, Neal. We'll have links for how to get connected with you in our show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Neal Bloom.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Neal Bloom is a Managing Partner at Interlock Capital, a community of founders, investors, and subject matter experts.

+ +

Victoria talks to Neal about what he finds attractive about startups and companies he's excited about, out of all the pitches he receives, how many he gets to say yes to, and when working with a team, what he uses to manage information and contacts for investors.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Neal Bloom, Managing Partner at Interlock Capital, a community of founders, investors, and subject matter experts. Neal, thank you for joining us.

+ +

NEAL: Hey, thanks for having me. It's so great to be here with you.

+ +

VICTORIA: Fantastic. I'm excited to finally get a chance to talk with you. I met you at an investor hike that you organize once a month.

+ +

NEAL: A founders' hike, yeah. I get up nice and early on the first Wednesday of each month in Torrey Pines in San Diego. And we hike up and down the hill with ocean views. It's not a bad day.

+ +

VICTORIA: It's a great way to start the morning, I think, and to meet other people, other builders of products in technology. So tell me more about your work at Interlock Capital.

+ +

NEAL: Sure. It really kind of organically happened that I became an investor, but not planned at all. I have an aerospace background then built my own edtech and talent tech marketplace. I call it the LinkedIn for students is really what we built as our first startup called Portfolium. We sold it, and I got really into startup communities, especially because of some people who helped me with my first startup. I want to be a part of building an even better ecosystem for others. And that turned into a podcast, a blog, an event series.

+ +

And once I had the capital from my exit, turned into angel investing as well, too, and really just found that as I got to know people over time, the more and more I got to know them, the more certain ones stood out that said, wow, I don't just want to help them for the good of it. I also just want to be along for the ride. And I started writing checks to other founders. So that was the beginning of my investor journey about five years ago.

+ +

And over COVID, a whole bunch of other later-stage experience operators, either founder-level or executives at tech companies, said, "I want to learn to do this. Can I do it alongside you?" And we created Interlock Capital as an investment syndicate. A group of us can share and utilize our brainpower, our time, and our capital to help companies. It's kind of our focus.

+ +

So that's why we call it a community because it's not just kind of a one-way pitch us, and we'll write you a check. It's very much get to know the people, find the exact right domain experts who have subject matter expertise, who've been there and done that before. If they like the company and they want to personally invest, then we go to the greater group and say, "Hey, everyone, who wants to join this deal specifically?"

+ +

So 18 investments later from Interlock Capital, we now also have an investment fund. So now we write two checks into every company. We do our syndicated style, pass the hat, if you will, "Hey, everyone, anyone want to invest in just this deal?" And then match it from our fund. And we're writing between $300,000 to $500,000 checks into early-stage software or/and software plus hardware companies.

+ +

VICTORIA: What an incredible journey. And I love that it's led you to creating a community as part of what you do as an investment capital group. What do you find interesting about these startups and these companies that you want to be interested in?

+ +

NEAL: Part of it is how much you learn about yourself, to be honest. I get to meet three to five new founders a day in a variety of ways, whether it's straight Zoom and pitch, or grab a coffee, or see them on a hike. We're kind of constantly introducing ourselves to each other. There's a bit of learning about how to size someone up to a certain regard. So you're kind of building this inner algorithm of how to top-prank people and their ideas. That's one interesting way that I never thought I would be doing professionally.

+ +

There's a lot that we say versus what we do, and that's a data point that I have to keep track of because I get pitched amazing ideas that will literally change the world for so much better. And you get really excited about it, and you get invested in it. And I call it founder love. You fall in love with these founders specifically and almost say, "I don't even care what you're working on. I just want to work more with you. How do we do it?" So there's a lot of that.

+ +

So there are some dating aspects [laughs] in terms of founder dating, like getting to know people. There's the determining how do we date towards marriage? Meaning, I'll write you a check, and I'm along for the ride for the next ten years. And then there's the kind of relationship maintenance which is okay; I wrote the check, now what?

+ +

Where can I be helpful to the company? How can I anticipate their needs so that they have to think one more thing of how to satisfy me? It's quite the opposite way around. I'm trying not to be a barrier. I'm trying to work for them while they're sleeping. So yeah, it's really interesting the kind of the relationship aspect that goes into getting to know and helping founders take their ideas and turn it into reality.

+ +

VICTORIA: That's very cool. And I have talked to people who have met you and talked to your company and just how supportive and helpful you all are even if you choose not to invest. So I think that's a really valuable resource for people. And I wonder, do you think it's something unique about the San Diego community in particular that is exciting right now?

+ +

NEAL: I think so. I think San Diego specifically has always had this culture of give-before-you-get mentality, and so we kind of lead with that. There are a lot of people moving here. And you could choose many places that could be great, like LA versus San Diego, and there's a certain kind of person that chooses here versus somewhere else. And what I have found is there's a certain kind of give-before-you-get cultural mentality here that somehow people register pretty quickly and come with. And so that's an underlying greatness about us here.

+ +

There's also because of the great environment we live in, by the beach, healthy lifestyle. I think we choose to work on things that maybe are also satisfying, just like our personal lives, meaning we work on things that matter, that are going to change the world, that are life-changing. That's not to say that we don't need certain other kinds of technology. I'm sure at some point, we felt we needed Twitter, and maybe we don't feel like that now. [laughs]

+ +

But here, it feels like everyone's working on very impactful things, and I think that's really special to think about. Some examples of that is we've got an interesting subset of the SaaS world in nonprofit tech. So GoFundMe was founded in San Diego. They have since acquired three other nonprofit tech SaaS companies in San Diego, like Classy. So that's kind of interesting. You've got people who want to build a business that services nonprofits, and now they're all under one roof. So yeah, I think there is something special. We can dive deeper into some of the other sub-industries or categories that are interesting here, too, if you're interested.

+ +

VICTORIA: Well, I could talk about San Diego all day.

+ +

NEAL: [laughs]

+ +

VICTORIA: Because I'm a fairly new resident, and I'm in love with it, obviously. [laughs] But let's talk more about products that can change the world. Like, what's one that you're really excited about that you've heard recently?

+ +

NEAL: Ooh. I would start a little high level in certain categories that I'm really liking. I like things I'm seeing in the infrastructure space right now, meaning, you know, whether it's pipes and our water utilities, and I would include that in energy and EV, you know, kind of a mobility piece. There's even the commercial side of mobility, so trucking and freight. That whole infrastructure layer is really interesting to me right now.

+ +

A certain company that, full disclosure, we invested in recently is a company called EarthGrid. They have a product that is boring holes tunnel-wise underground, but they're using just electricity and air, so plasma. And it's fascinating. They can bore holes 100 times the norm right now. They don't need to potentially trench, meaning they don't need to cut above the surface. They can just dig for miles straight underneath the ground, so they can go under things with that. And really a lot of the expensive pieces, closing lanes on freeways or highways to put fiber in or plumbing and all that. So it's really interesting to see that.

+ +

Now, one element is the technology is interesting. But they have a plan to actually own their own tunnels that go across the entire United States. So they don't just want to be a device that they're going to sell to everyone. They want to actually own their own utility that has major tunnels across the United States. So that's fascinating to me because that's like think big, think exponential around that. So that's one area that's kind of fascinating to me.

+ +

VICTORIA: That's super interesting, and thinking about the impact it can have on making power more secure for more people, things like that. There are just so many problems to solve, and so many are people trying to solve them. [laughs] -

+ +

NEAL: Yeah, exactly. And they have a clean tech angle in that there are a lot of different ways to dig and tunnel that includes chemicals, and so their big thing is to not do that. Some of their background is installing these kinds of lines in the EV space for solar panels. So they have a big kind of clean and sustainability focus there. And our infrastructure is aging big time. We've got 100-year-old bridges and pipes and other things that it's really interesting to see the government put money into. And so that is another aspect, a business model, per se of infrastructure.

+ +

You have the government putting billions, if not trillions, into upgrading our infrastructure, which as an investor, I like to hear that there's free capital out there in forms of non-dilutive funding to help these along, and that's existed for hundreds of years. Cars and oil industry got these kinds of subsidies, and then the EV and solar panels. So that's a good area that I like to look in as well is where is there additional large-scale funding to help these products really get to market?

+ +

VICTORIA: That makes sense. And so you're meeting three to five founders a day, and you're watching where the funding is available. And out of all the pitches that you receive, how many do you really get to say yes to?

+ +

NEAL: Oh, it's small, I mean, one to two a month if that would be a lot, and those could take a few months to work through. The best way for us to invest is to get to know the people for as long as possible. So I kind of mentioned that relationship aspect. I want to see how people operate. I want to see how they build product. I want to see how they get to know their customer and iterate and bring that back into design thinking. And so that's a big piece is getting to know and see the people do the things that they're saying.

+ +

Man, there are so many companies that I like on paper, whether it's oh my God, amazing team, or, oh, cool, the product. Yes, love that idea. And then you have to look at everything together, the timing, the valuation that they want, the team. Has this team been there, done that before? So there are a lot of elements that go into it. Like I mentioned, you have this founder love where you fall in love with the people, and maybe the rest doesn't work out or vice versa. But yeah, I think each investor comes at it differently.

+ +

So my area because I built two tech companies that were talent tech-related, meaning connecting people for opportunities; my investing style is very team and talent and recruitment-focused, meaning what are the superpowers of the founders? Are they aware of their weaknesses and their strengths? Have they filled in those gaps by finding co-founders that are complementary and opposites?

+ +

And then my partner, Al Bsharah, he is a super product guy, and he wants to break the product and see, how can you break it? What are they thinking product roadmap-wise? That's his first go-to. And so, for us, we're super complementary in that regard. So we will assess the same company in very different ways and then come together and say, "Let's share our scores, share our rank. Where do you think this company sits at in all these different areas and boxes?" And so that's a great way, that complementary skill sets as investors. We utilize those strengths together.

+ +

So yeah, it's hard for a founder to know that. A founder who's building a product, the person on the other side of the screen, they're meeting me. They're not going to know my algorithm. They're not going to know what I value more than something else. So there's this whole dance. I wish it didn't have to be that way, but it is a dance. It's a negotiation.

+ +

And that's why I build a community because I'd really rather take the gloves off and get to know people when they're not raising capital, when they really are just inspired by innovation and by customers, and they're just excited, and they're building product. That's the time I want to get to know them and see how they iterate before the capital question comes in. Because when it's capital, it tends to feel a little transactional, and that's just not the name of the game per se.

+ +

VICTORIA: It makes sense. And I'm curious, working with your partner who has a specialty in product, has there ever been a big surprise that he presented with you that you would never have thought of without that product perspective?

+ +

NEAL: Oh yeah, absolutely. I think there are many times now where either the company is really touting a specific piece of their product, whether it's a certain kind of technology that as a non-product builder either I think, wow, that's unique. That's special; that's novel. And I go to my partner, who really is an automation expert in terms of product building, and boom, can whip it out in a second and say, "I could that with Zapier," or now ChatGPT. So I think there are those elements that are good checkpoints of putting too much...maybe I get too excited about uniqueness or a novelty of a product.

+ +

And then there's the opposite. There's the team undersells their product, and really they're touting, hey, we have a background in this industry. So we're going to go build because we know how to get into that industry. Our uniqueness is go-to-market, so they think. And it turns out, hey, you're really underselling the product here. There's something special about your vision system here or your data set that you're using to build your ML model. So I've seen a variety of both of those.

+ +

I think we're going to see more and more right now where ChatGPT and other AI models are going to show that maybe the tech exactly like AI isn't the specialty. That's going to be a democratization across the board. We're just going to expect that everyone can build a baseline product. So how are people going to differentiate on the product? That's where I'm really excited to see where product stands out now that more and more people have more tools at their disposal to build a good product.

+ +

VICTORIA: Yeah, I'm excited for that too and to see which experiments with AI really pan out to be something useful that becomes part of everyday life. Do you have any instincts on where you think you're going to see the most out of AI innovation in tech?

+ +

NEAL: AI is such a big word, and it feels so buzzwordy right now. But actually, in San Diego, we have a deep history in the high-level AI, and it starts with analytics. We have a deep, deep bench of analytics talent here. In fact, Google Analytics was founded in San Diego under the name Urchin Analytics and acquired by Google in 2004.

+ +

VICTORIA: Oh.

+ +

NEAL: And so you have these big analytic models and builders here that is interesting to tap into. I kind of bucket it in a few areas. I look at the vision aspect, so motion capture, motion classification, image classification. That's really interesting that I think we'll see a lot of that that applied to blank. I'm seeing that applied to life sciences, so cancer detection through some sort of imaging. Obviously, the mobility aspect, whether it's self-driving or driver assisted for blank, whether that's drones, self-driving trucks, all those areas. That's one area interesting from the AI piece.

+ +

Natural language processing which there's a piece of ChatGPT to that regard. I think it is really interesting from what is your dataset? What are you tapping into? I'm also seeing that applied to digital health, whether it's clinical trials bringing AI models there, whether it's taking genomic data and saying, let's build better clinical trial classes. Maybe we don't need 500 patients when we can build the best 30 patients to enter a trial because we've got genomic data on our side. So yeah, I think I'm more looking at certain industries and saying, what is the right AI model for it? And I think that's pretty exciting.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: So tell me, you know, at Interlock Capital, when you're working with a team, what do you use to really manage all of this information and these contacts for your investors?

+ +

NEAL: Yeah, it's a great question. We decided to build our own products in-house thanks to my partner Al who's a great product builder. At the end of the day, there are a few different funnels we are managing within Interlock Capital. We're managing our customer, which really is the startup. We want to make sure we're keeping track of them on whatever timeline. And so we use CRMs, basically, to manage funnels per se. So that's startups.

+ +

Then there's the deal flow sharing, so these are other VC firms, maybe other service providers, where we're sharing companies with each other. And then we have investors, so we're using CRM for managing our investors, like our limited partners, our LPs. So that's basic CRM. Luckily, we were able to use an off-the-shelf product called Streak for that. But what we do uniquely is we want to engage in two directions our investment community, meaning we want to get to know them, get to know everyone's expertise so we know when to tap them to say, "Hey, can you help on this deal?"

+ +

And help is very broad, meaning it could be to give it a quick look before I've even met them to say, "Is this something I should even be looking at?" Or I've already met the team, maybe spent a few hours with them. And I'm asking for a deep dive with an expert to say, "Join a call with me after you've reviewed a deck and help me ask harder questions." So there's that aspect of we wanted to figure out how do we get to know our people in our group? Because we're hundreds now.

+ +

So we decided to build a platform off Bubble.io and Airtable basic no-code where we could build a light profile of everyone. So everyone self-selects a number of profile aspects about themselves. It's also where we're starting to keep data and documents for them as well too. So whether it's tax documents or other forms, we can have it all in one spot. And then lastly, when we do decide to make an investment in a company, we write a very detailed memo that starts in Google Docs but then gets built into our product, the Interlock platform.

+ +

And so in that memo which could honestly be 10 to 20 pages of diligence, in our language only, what are the pros, cons, and risks? We also showcase who is on the diligence team, what their specific expertise is to this investment, if they're personally investing or not. We really want to show conviction from the diligence team. And then we've built in some really cool features where you've got a Q&A board that you can upvote other people's questions about that investment.

+ +

You can watch a video right there and then about the company, and then you can commit to the investment itself on our platform, saying, "I'm interested in this deal specifically. Here's the amount." And boom, we take you over to a third-party platform to just sign in and wire. So that's current day the product that we decided to build.

+ +

We've got this whole product roadmap that we've built out that we want to build out more. We would love to automate a little bit more of our deal funnel so that a certain company that we meet maybe they get to a certain stage that we know we're ready for diligence. We can auto-ping the ten people that have that specific domain expertise.

+ +

So luckily, we built out the profiles about everyone. Now we need to start building some automation in there so that maybe I'm not the bottleneck. I'm going to meet three to five companies a day, I mentioned. That's three to five follow-ups that I need to do. I'm never going to be as fast as the founder wants me to be on getting back to them and saying, "Here's our next steps." So if we can utilize the greater body of people that are in our investment community, that's where we'd love to build out some of the pieces next as well. So automation is kind of the hope there.

+ +

VICTORIA: That's great. And I love that you're able to take advantage of these low-code tools to build something that worked for you. What was your initial approach to figuring out how to build this in a way that worked for your user group?

+ +

NEAL: Well, we looked at a lot of existing products first, and there are. There are these angel syndicate websites like AngelList is a big one, you know, a consumer-facing platform where if you're interested in investing, you can join a group, or you can join a dozen groups and just get an email when they have a new investment opportunity.

+ +

And so we looked at...first, it was survey what's existing out there already. Start building a product feature must-have or is nice to have list for us to get off the ground within Interlock. And then determine the pros and cons of building off the shelf, the time and cost, and maintenance versus using something that already exists. So that was a big piece, just assessment upfront before we do anything.

+ +

And I think learning the landscape was big for us. I find that building tools for startups there's a lot, but there are also not a lot of mature ones because there's just not a lot of money out there to be made. There's not a billion-dollar industry of making a website to invest in startups per se yet. So that was another thing as well. It's just understanding will the companies that we choose off-the-shelf products-wise will they still be there a year or two or three from now?

+ +

And ultimately, we decided, you know what? We got to build it ourselves if we really want the two-way communication, not just one-way. We didn't see everything out there. And I think the piece you always underestimate is the maintenance over time as well as all the third-party tools and apps and services that you end up needing and using and how do they play into the maintenance role as well too. We've definitely had elements of our product break because they're no longer supporting that tool anymore. So those are all aspects that you can do as much as you can self-assessment upfront. There's obviously the maintenance piece that goes into it down the road as well too.

+ +

VICTORIA: That makes sense. And then, in this way, you have control over it, and you can change it as often as you want.

+ +

NEAL: Totally.

+ +

VICTORIA: And as much as you like, if you have the time. [laughs]

+ +

NEAL: One piece that I think we have never planned or expected is that because we built it and it's super unique, there are many other angel groups who have come to us and said, "Can we use your tool? Like, yours is better than anything that exists." And we did not build ours with a commercial aspect in mind at first. We can't just clone an Airtable and be like, "Here we go. Here's your product. It's Bubble and Airtable," because if it breaks for them, we're on the hook for that [laughs] as well too.

+ +

So I don't think we thought through too much around a commercialized product when we built out our own. But because we've been pinged so many times about, can people use it? It's on our mind now. Like, it literally is on our list of priorities of hiring either part-time or full-time a product builder to go back in and commercialize aspects so that we could actually maybe turn this into a product one day, this whole investment community manager software.

+ +

VICTORIA: That's really cool. And it's funny, talking to founders, there's always a story about how you set out to do one thing, which was build a community around startups and founders in San Diego, and then you end up building a product, [laughs] right?

+ +

NEAL: Yup.

+ +

VICTORIA: And getting something marketable later that you never even intended.

+ +

NEAL: Yeah, I mean, I think the big learning there is, one, listen to your customer first, then go build products. And so yes, you said it exactly; we wanted to build a community where we could be more engaged with our customer. And as we heard more and more from our customer, it told us what to build. And I always find that from other startups, that's a great model to follow as opposed to build and then go determine if there's a market out there for it.

+ +

VICTORIA: Yeah, that makes a lot of sense. So it's interesting that you've had this experience of building tech startups from scratch and then now investing, and then now you're back [laughs], and you have a product again.

+ +

NEAL: [laughs]

+ +

VICTORIA: So I wonder, if you could go back in time starting Interlock Capital or when you started your companies, like, what advice would you give yourself if you could travel back in time and talk to your past self?

+ +

NEAL: Oof, so much. Spend a lot of time getting to know yourself, not just what you're good at but what you like to do business-wise. And I actually see those are two different things. Sometimes the things we like to do we're not as good at, but yet we want to spend more of our time on it, and maybe it takes us longer to do it. So do some self-assessment. I would have done that more on myself.

+ +

And I'll give you an example, I, for whatever reason, like to brute force certain things like our email outreach, whereas my partner loves to build automation campaigns for it because he built a software in the email space. I know I could learn a quick automation route [laughs] to do certain things, but for whatever reason, I love sometimes the analog version of things. And that's good sometimes, and sometimes there's no time for that.

+ +

So learn a lot more about myself, what I like, and what I'm good at. And then the opposite, what I don't like doing, what could I shed as quickly as possible and could hire for in some way or another, trade my time or capital for time. And then, only then, once I know myself better, then go find the perfect partner that complements everything. It's the opposite of me in that regard, opposite in network, opposite in skill sets, and in that regard too.

+ +

And so I think my first startup, we were carbon copies of each other. We were both aerospace engineers who kind of wanted to do the same thing who lacked emotional intelligence at the time. So yeah, that's a big learning. But I didn't know enough about myself at the time. And it took hardship to learn the hard things. Honestly, entrepreneurs seem to learn by doing more than anything. So you can only tell an entrepreneur so much. Sometimes they're just going to have to go and figure it out by running through a wall. That's one thing I would have changed about myself in that regard.

+ +

I also probably would have, even earlier during college, gotten more internships to just test myself professionally and know what environments I do well in, meaning big companies, small company, or hands-on mentorship and management or hands-off certain kinds of skill sets. How could I be presenting more often versus just kind of behind-the-scenes doing? All of those I probably could have learned quicker about myself the earlier I would have put myself in those situations as opposed to getting my first job and working at one place for five years. That's a long time to dedicate to learning one culture about that I thrive in. But you live, and you learn.

+ +

VICTORIA: I love the drive to keep learning and to be like, you know, don't expect to be good at everything [laughs] that you want to do. I think that's fantastic. And what do you see success really looking like for yourself in the next six months or in the next five years?

+ +

NEAL: This year, this calendar year is really about getting the fund up and running. So we've raised an initial tranche of capital and got through this calendar year to get the full capital we want for the fund in. And we're being really picky about that. We really want operators, so that just takes time to go and meet the right people that maybe have recently exited, so have a little bit of time and have a little capital and now want to spend time with earlier stage companies. So that's a big piece of this year.

+ +

I also, on the community side, want to scale it a little bit. I've found recurring...like the founders' hike is a really consistent and easy way to build community, just meet new people, get to meet 30 people at once instead of maybe 30 coffee meetings to meet those people and just kind of selectively choose who is good to follow up with. So building and scaling, thinking about how to scale community growth is another area, and hiring a little bit around that.

+ +

So hiring either a community manager and understanding what does that role even mean? Because it's vague in a variety of scenarios. I think we as a company could utilize it. But I think even San Diego could really benefit from someone professionally community-managing all of us. I don't even know what that means yet. And I'd actually push that back on you. Like, you're recent to town. You've started to meet people in a variety of venues. What's the community management void that you see that exists locally?

+ +

VICTORIA: Oh, great question. I'm actually going to the Annual March Mingle tonight. This episode will come out a little bit later.

+ +

NEAL: I'll be there too.

+ +

VICTORIA: Oh, I was like, I'm going to interview you and probably see you later. [laughs]

+ +

NEAL: Awesome.

+ +

VICTORIA: Yeah, I think what's interesting about what I've experienced so far is that there is a thriving community. People show up to events. There are a lot of different focuses and specialties. Like, there's the San Diego Design and Accessibility meetup, which had over 30 people over and has a lot of great content. The tech coffees usually have your standard crew who comes.

+ +

I'm in North County in Encinitas, and then there's Downtown San Diego. And I think you and I have talked about this, that there isn't as much of a major hub. And people are kind of spread out and don't really like to travel outside of their little bubble, which isn't necessarily unique to San Diego. [laughs] I think we've seen this in other areas too. So I think deciding where and how and maybe just building that group of community organizers too. One thing we had in DC was we would have a meetup of all the meetup organizers. [laughs]

+ +

NEAL: Ooh.

+ +

VICTORIA: They were just the people who are running events would get together and meet each other and talk and get ideas and bounce off, and maybe that exists in San Diego, but I just haven't tapped into it yet.

+ +

NEAL: Well, that's a great, great, great, great point because, yeah, learning from others. Everyone is out there doing. Let's learn what's working and what's not. I do that actually from community to community. I do compare...I'll pop into a city on personal travel, but I'll look for, say, the Neal Bloom of Phoenix or something [laughter] and share quick notes. Something Startup San Diego started... when Startup San Diego started ten years ago and became a nonprofit shortly thereafter, it wanted to be the convener of all the organizations that help startups.

+ +

And so there became kind of the startup alliance, I think, where it was all people who run different startup orgs, mostly nonprofits or just meetups getting together. And that hasn't come back since COVID, and I don't know if anyone's thought to bring it back. So this is a great time to think about that. Let's do it. Let's absolutely get the startup community alliance back together and sharing what's working and what's not.

+ +

Something else that I think matters as we're coming out of COVID and really matters also for product is it feels like curation matters way more than anything before. Like, we value our time more. We want to be home a bit more. And so we're only going to go to the things that we know there's some value out of it as opposed to, oh, I'll show up to that thing. It sounds cool. I get free pizza.

+ +

So the curation piece, I think, is interesting to think about, like, how do you scale curation? Because if you make smaller groups and make it more valuable, you still can't make a group for everyone. Someone's always going to be missing out. That's a piece when I think of how has product worked really well for that? Obviously, product has done amazing things on curation with using filters and ranking and other things. How do you do that in real-time for community?

+ +

VICTORIA: Yeah, that's a really cool idea. And it's interesting talking with organizers from Women Who Code DC who are still there and coming back from COVID. They were all virtual events, and now they're having part virtual and part in-person. And it's interesting where some people really want to get back to the in person and see people in real life. The virtual is also still a very good option for people altogether across the board.

+ +

So, yeah, I think you're 100% right on the event has to be kind of worth it. [laughs] And how do we make that real? But we still have all these other options for connecting with each other too, and we should take advantage of this. I love that here if we're going out in person, you're on a patio. [laughs] You're outside. Even though it's pouring down rain right now so we're probably going to get rained out a little bit.

+ +

NEAL: I don't think I realized how outdoorsy we already were until this recent rain, one, because COVID forced everyone outdoors already. So for the last three years, we've only been going to places that have been outdoors. But then I realized, wait, every coffee shop I go to already is just open air. Every brewery, every restaurant is open-air. We've got it pretty good here. March Mingle, as big as it is, which it's like you're 17, 18, maybe 20, it's always an amazingly cool crowd and a crowd that I don't always see at every event. It's not the same, same people. It's a crowd that just comes to March Mingle.

+ +

VICTORIA: That's super cool. I'm excited to see you there later. And maybe by the time we've aired this episode, I'll have actually posted about it, so it won't be a surprise [laughs] for anybody. But I love that. Okay, so, wait, that was...did we talk about six months and five years into the future of success?

+ +

NEAL: We didn't. We just talked this calendar year. Five years out, professionally, I think a well-oiled community, multiple funds under management that maybe have realized, like, let's have one with different focus. Maybe there's an infrastructure tech fund, maybe there's a diabetes tech fund. I'd love to explore the curated focused thesis aspects because it's easy to be pretty general when I'm meeting so many interesting companies, and I have so many experts at my disposal. Maybe it makes sense to have multiple smaller focused funds in that regard.

+ +

I think five years out; also, we will have probably weathered some financial storms, probably be on the upswing of that, and therefore maybe there are some exits that would have happened in town. There's certainly a number of late-stage tech companies that have been at it 10, 15 years that a lot of early investors and employees with stock are just kind of waiting for a liquidity event, and I really think by then we will have seen that. And that will be really interesting to see if and how people recycle their capital back into the community, both from investing, from giving philanthropically, and then their time as well.

+ +

Sometimes when you have really big success, it's easy to check out and leave, and I'm hoping we're getting ahead of that cycle now. We're getting people to put some skin in the game now so that when the exits happen, they stay connected because they're got some investments in the community. So I'm really hoping that we've closed the wheel on the flywheel of capital, recyclable capital here in San Diego five years out from now.

+ +

VICTORIA: Oh, I really like that. And I think it makes sense from that idea of if you've benefited from being able to run your own company and to work with all these people in San Diego that when you exit, you invest that back into the community and grow future companies with it.

+ +

NEAL: Exactly. I mean, someone helped you, all of us, and they're just ahead of us. It kind of behooves all of us; then, to each stage and phase we go forward, we should look back and say, "How can we help someone behind us?" And we started this conversation that is a very San Diego culture thing. And so I'm really excited to see when that line bends back on itself, that flywheel closes.

+ +

So the other aspects of that is we're starting to build some crossroads with Tijuana. We tried before COVID, and we're trying again now. And I'm really excited to see the long-term effect of connecting these cross-border communities. And then we talked about some technology, five years out, man, if GPT is updating so quickly now, I can't even imagine what AI is building product by itself five years from now. And where do the humans play a role in that?

+ +

People love the splashy headline articles of here's where AI is going to replace your jobs. I'm thinking quite the opposite. I'm so excited for the new jobs to emerge that don't exist right now, for us to complement technology, that, you know, we'll be doing things that are better than humans. So that's a whole piece of technology and product that I'm excited to see play out.

+ +

VICTORIA: I agree. I think that it's humans plus machines make the most impact, right? [laughs]

+ +

NEAL: Exactly.

+ +

VICTORIA: It by itself won't do it. But I think that's fantastic. What a great note to kind of end on. But is there anything else that you want as a final takeaway for our listeners?

+ +

NEAL: One, I'd love to meet you if you're building an interesting product. I'd love to connect you into our community, so that's a self-serving ask. Find me on LinkedIn or Twitter; probably, Twitter's easier. Write me that you heard me on Giant Robots Smashing Into Others. Absolutely would love to hear that feedback loop. Also, come check out San Diego sometime. Come join our founders' hike. If you're listening to this, pretty much we have it on every first Wednesday of each month. We'd love to welcome you into the community here.

+ +

And if you have an idea for a startup but haven't started yet, that's a great time to be talking and thinking how could I iterate way sooner than you would have thought. So don't wait to get started on something; just start talking to people about it. Don't be afraid to share your product ideas. No one's going to steal it. So I would just tell people to get started sooner than you think. And the world will benefit from you putting that out into the universe.

+ +

VICTORIA: I love that. Thank you so much for sharing and for being a guest on our show today, Neal. We'll have links for how to get connected with you in our show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Neal Bloom.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+vrrQAC6H + + ]]> + + Victoria Guido + Neal Bloom + + + 471: Blossm with Brian Feretic + https://podcast.thoughtbot.com/471 + f915a75e-eea9-4c41-8961-6a4a3f47cb48 + Thu, 20 Apr 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Brian Feretic is the Founder of Blossm, a community marketplace to buy, sell, and trade plants. + +Victoria talks to Brian about how coming up with the concept happened, getting started in a very scrappy way and then filling in gaps, and opening up the app to have full marketplace functionality with buying, selling, and trading capabilities. + 32:57 + no + + + Brian Feretic is the Founder of Blossm, a community marketplace to buy, sell, and trade plants. +Victoria talks to Brian about how coming up with the concept happened, getting started in a very scrappy way and then filling in gaps, and opening up the app to have full marketplace functionality with buying, selling, and trading capabilities. +Blossm (https://blossm.garden/) +Follow Blossm on LinkedIn (https://www.linkedin.com/company/blossm-plant-marketplace/), Twitter (https://twitter.com/blossmllc), Instagram (https://www.instagram.com/blossmplantswap/), Facebook (https://www.facebook.com/blossmplantswap) or TikTok (https://www.tiktok.com/@blossmplantswap). +Follow Brian Feretic on LinkedIn (https://www.linkedin.com/in/brian-feretic-3b2b337a/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido or Tori. And with me today is Brian Feretic, Founder of Blossm, a community marketplace to buy, sell, and trade plants. Brian, thank you for joining us. +BRIAN: Hey, it's great to be here, Tori. +VICTORIA: Great. I'm excited to hear more about Blossm. Why don't you just tell me a little bit more about the concept? +BRIAN: The concept actually happened at the end of 2019, and I'd already been a plant enthusiast for a couple of years. I was actually just going on my way to surf in my town of Ocean Beach, San Diego, and I stopped by this garage sale. And when I came back to pay my neighbor, I brought this rubber plant that are propagated just as a neighborly gift. She flipped out. She was ecstatic. She's like, "Oh my God, I'm such a huge plant person. Thank you so much. Why don't you come into my backyard, and I'll give you a plant tour, and you can pick something out." +And what was cool about this was it wasn't just like a simple exchange. It was like this hour-long interaction with someone that lived four blocks from me that happened to be this big plant nerd like me. And I got her whole story. She went through all these different species I didn't know about. And then, she helped me pick one out, which I still have to this day. It's this crassula succulent. When I was walking home with my new plant, I was like, oh wow, I got to go download the app for this. I would have never known this person that lives four houses away was a big plant person like me. +And when I got home, I searched the App Store. I did a Google search. I just couldn't find what I was looking for, which was basically this plant-swapping plant-connecting platform where I could find fellow plant nerds in my neighborhood. And so that kind of set me off on this path. I did some more research and decided...I was like, you know what? I'm going to commit to this and make this happen for myself and for my community. +VICTORIA: Well, what do you think makes someone a plant person [laughs] or like a...how did you describe yourself? A plant nerd? What sets that user apart? +BRIAN: We'll say it's like on a spectrum where people can shift along the spectrum. But I'd say when people start treating their plants more than objects and more what they are. They are these living things. They're beautiful. They bring people joy. I find it therapeutic to take care of them. And then the beautiful thing about it is that these plants grow, and you can propagate them and share them with your friends. And I think that is a critical aspect of this whole plant person thing. +VICTORIA: So the plants have become a little more like pets, and you can grow them in a way that creates a community around your friendship and your local area. +BRIAN: Yeah, exactly. That was actually the early signal about this whole plant world is that I saw people creating plant-dedicated Instagram accounts as if it was your dog or cat. And that was something that I realized this is a different type of person. This is a very passionate person willing to, like, they're so proud of their plant babies, we call them. [laughter] +VICTORIA: Right. And it's funny, you say, plant babies. When I think of people I know who I would consider plant people, they do talk to their plants like their babies. They're like, "Oh, it's so cute." [laughs] Or they're like, "Oh, he's not feeling so well." So I think that's great. And so you started to do some research into this community, into this group. What surprised you about your early findings? +BRIAN: This was actually something that I didn't realize until I dug deeper was that I thought that it was only going to be a local thing. People wanted to experience what I did with Sondra, who's the neighbor I swapped with, this in-person connection, swapping, checking each other's gardens out and houseplants. But I learned very quickly that people ship plants to each other not only within your own state but across the country, and this is global. +And I was just like, how do people ship plants? Turns out I do it all the time, almost weekly now, for years. That aspect was critical to realize, all right; this plant community doesn't necessarily have to be bound by physical in-person distance. It can connect online, and people share all over via shipping. +VICTORIA: That's really cool. So you decided that there's a whole international community. So is that when you decided to really start building something like an application to help people? +BRIAN: I remember just throwing this idea out to a lot of different friends, like, various backgrounds. And I was like, "Hey, what do you think of this idea about connecting people through this shared love?" And there is not one person who thought it was a terrible idea. And then I remember talking about it with a roommate at the time, and basically the same thing. I was like, "Hey, man, imagine people connecting through the shared passion. Who knows? Maybe even love can blossom." And he was like, "Dude, that's what you should call it." I was like, oh, that's a great name. It's about three and a half years now, and it's stuck ever since. +VICTORIA: I love that, [laughter] about sharing love, and how the name came about, and just starting with your friends and people you knew and bouncing ideas off of them. But your background is not specifically in technology. So what about your background applied? And what did you have to learn new to take along this journey? +BRIAN: So my whole career, I've been involved within the science sector. I actually moved to San Diego to pursue graduate school in neuroscience. I was very curious about kind of full neural networks and how those contribute to behavior. Actually, the Ph.D. program I wanted to get into at UCSD, there's a specific lab doing this really cool research with this new innovative imaging technique. And I applied twice, and I didn't get in. And so I went into biotech. +But I would say probably two things helped me. I realize now going through this entrepreneur path, things that helped train me for this, was definitely a graduate school where you're pretty much broke the whole time. My lab didn't have too much funding, so you had to be really resourceful and creative to figure stuff out with minimal resources. And that's perfectly summed up the last couple of years, just like figuring stuff out. +We have no money. How do we get awareness of our product when we can't spend, you know, we don't have ad spend or marketing budget? And it just kind of requires you to get creative and think outside the box and just really think, all right, what do I do here? And I came up with some hacky-type strategies that have been very effective. [laughs] +VICTORIA: Well, very cool. It sounds like you found your team now to start working with you on this in a very scrappy way. So how did you fill in those gaps, maybe in your knowledge or your background on how to get this done by the people that you grew around you? +BRIAN: For me, it wasn't too difficult. Well, one, my background. I was very naive with tech at the time and just programming in general. So my first task, I laid out three options. It was like, one, I can learn how to code. I dabbled in it for a week, and I was like, man, there's no way. [laughter] Two, I was like, I can outsource it, maybe somewhat cheaply, but I don't want to spend all my savings on it. +But more, I knew that, you know, say you come out of MVP product, the product always is growing, adapting, evolving, or you encounter bugs. And I could just see how full of friction the process would be if I had to, like, all right, we have found a bug, send the contract out. They have to accept the contract. And I just knew progress would be too slow to operate in that fashion. +And the third option was, like, find a technical co-founder and pursue this dream with, you know, a buddy. I was like, all right, who do I know that is in the computer stuff? And that was my thought. And my first guy I pitched it to was a friend I went to college with at Bucknell University. And he was like, I think, "This is a good idea." But he's like, "I'm going to retire probably in five years, and this is going to be a very lengthy thing." He's like, "I'm not interested." +The second guy was extremely down for it, but it turns out he didn't know how to do any mobile app development. He uses a consultant. [laughs] And so the third and who I ended up working with was my surfing and climbing buddy Nick Mitchell. I just knew he did computer-type stuff. I pitched him the idea, and he was like, "What's up with this plant thing?" +VICTORIA: [laughs] +BRIAN: And I was like, "Oh, dude, this is a rapidly growing market. I know the ins and outs really well. I know this audience. I'm one of them." He wasn't sold until he heard an NPR piece talking about the houseplant boom. And then his father sent him an article from the New York Times saying how millennials are embracing houseplants and driving this new houseplant market. +And so I think this was maybe end of December, now in 2019. And he hit me up, and of course, he's like, "Oh, dude, I want in. Let's do it." But I also wanted to make sure I knew he could actually do what was the task at hand. [laughter] So I had my other first friend vet his GitHub and stuff just to make sure. [laughs] +VICTORIA: Oh, cool. [laughs] +BRIAN: And he was like, "Yeah, you know, he looks good. Worth a shot." And it turns out Nick is excellent. He did all the front end, back end. He built this whole app basically from scratch. It's pretty amazing what he's capable of. So I got it right on the third try. [laughs] +VICTORIA: That's funny. And I'm not surprised it came from networking in the climbing community, either. +BRIAN: Right. There's a lot of smart...definitely a lot of smart people in the climbing community. And those are like my closest friends now. So it was kind of cool to find someone in that place. +VICTORIA: And I've been climbing with friends before, and you're talking about work or whatever. And they're like, "Oh, yeah, I'm also like an Azure architect," [laughs] like some specific skill that's related to what you need. And I think it's a similar cultural mindset of people you want to be working with too. Maybe that's just me. So, okay, so you found your partner. You had someone who had all the skills that you needed to make this happen. How long did it take until you really had something you were proud of? +BRIAN: So, for me, I was laid off in August of 2019. I was working at Celgene, and they got acquired by Bristol Myers Squibb for like 72 billion, so massive merger. And I was kind of getting over the field. And so I was already basically unemployed. Nick, when we started actually working together in...we'll just call it January 2020. We started working on it casually, and then the pandemic happened. And then he got laid off. And he did about a three-month stint before he got another job at ServiceNow. +But within those three months, he really cranked out like a full MVP. And then I had about probably at least 60 or 70 people I knew beta test the product for feedback and just initial thoughts. And so that was like a very critical time where we were all locked down. We have this cool idea. Let's just crank this out. So we had an MVP pretty quick. And then we actually launched it in June 2020. And I was already very stoked about the product. As long as it did its core thing, which is connecting people through this shared love, I knew it was like a proper test, a good enough test to see if this is a worthy endeavor. +VICTORIA: That's really cool. So was there any surprising feedback that you got from that initial beta testing? +BRIAN: Yeah. [laughs] So the initial concept was essentially like a Tinder for plants. [laughter] And I was just thinking about this idea, like, if people could just swipe on plants they've uploaded, and then if both people liked a particular plant and they swiped on each other, and they matched, it would open up a chat that would connect them. +And it took the...one of the issues with bartering, in general, is people are like, "Oh, I'd love to swap that with you." And they're like, "Oh, what do you want to swap? What do you have?" And a lot of times, people don't align with what they have and what they want to swap. So I figured that would get this kind of friction out of there, but still, the core was connecting people. And then, very quickly, people found it fun. And this is still a feature right now on Blossm, which we've moved to the homepage. And it got a lot of engagement and interactions on it. +But one of the simple changes was like, all right, maybe this is not the optimal way to present these plants people are uploading. Nick actually drew a lot of inspiration from OfferUp. And he was like, "Oh, this is very simple. This is a very clean way to present these things." So we started getting inspiration from OfferUp, and we changed that kind of swipe card functionality just to a scrollable grid. And that was a great insight on his part, and some of that has been core to the product from that point on. +VICTORIA: That's so cool. So I can just go in the app and see a whole list of plants that people are willing to trade. +BRIAN: Right. Actually, I would say another thing that happened very early on, too, was, once again, bartering is not the most efficient way to exchange things with each other. And within weeks, we're seeing people being like, "Oh, well, what do you want to swap?" And then people are like, "Oh, well, I don't want to swap for that. I already have that." And then other people are like, "Hey, I don't want to swap anything. I just want to buy it." And then other people are like, "Hey, I don't have anything. but how do I get stuff for you?" +So right away, we opened it up to full marketplace kind of functionality with buying, selling, and trading. And we didn't have necessarily any payment system to facilitate that. We would just connect people. And then they would use Venmo, or Paypal, or Cash App, or things like that. +VICTORIA: That makes sense. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +VICTORIA: Now you kind of got your core features figured out, and you see people engaging with the app. What are you the most excited about on the horizon in your roadmap? +BRIAN: We're about to actually finish the TechStars accelerator next week. Next week is our demo day. It's been such a great experience, and I feel blessed. But during this time, we're really figuring out, like, what's our big vision with Blossm? And we kind of went back to really harp on, like, we're more than just an e-commerce or marketplace. We're like this special passionate community where people can do this buying, and selling, and trading. +One of the things that's been the trend for years now is instead of just photos; we're about to integrate some video functionality. This is a lead in to the bigger goal. And the idea is creating this...we're calling this full plant experience focused around live video where people can engage with each other on this totally different intimate level and can really showcase their plant collection and give each other a plant tour. How do you take care of this plant? Is another big topic that always comes up. +It's just hard to really decipher what's wrong with something just from ecstatic images. And we imagine we could have live plant help. And then people can just show their plant up to the camera and showing a really holistic view of what's going on. And so this vision of live with video and creating a more complete plant experience centered around really using the community as this way to promote that and really build that even further. +VICTORIA: That's very cool. I think I've talked to you a little bit before about this giant fiddle fig I have in my office. [laughs] It's going to the ceiling. And I got it from Home Depot, so it may not be the highest quality. And I've asked you about, like, is it alive? It keeps dropping leaves. So if I had a video and I could just show you around and show you where the leaves are browning a little bit and where it's not growing, I could see the value in having that interaction like that. +BRIAN: Yeah, exactly. No one's doing that. And definitely, we want to keep innovating the space. We were first to market many years ago. And then, actually, we have some direct competitors that are blatantly just copying us, like copying email templates, features. And on one hand, it's flattering, but also we realize we have to be careful about positioning and making sure we stay ahead of the curve. And we think this is going to be the future and something that delivers really extreme value to this demographic. +VICTORIA: Absolutely. And you mentioned you're a part of a tech accelerator. Could you tell me a little bit more about choosing which program you went to and how that's affected your overall approach to your app? +BRIAN: Yeah. So last year, we added two more team members, so actually Nick's younger brother, Calvin, we poached from Amazon, which felt really good. [laughter] And then we had another friend, Ari Olmos, who we knew had experience in the startup world. He started, or I think he was, co-founder or CEO of a few other social mission startups. So he understood just the fundraising process was probably the most critical trait we're looking for, just someone that can help refine our systems, our processes, things like that. So now we're a team of four. +And we were like, all right; we need money if we want to keep this alive. And I've been full-time since the idea conception. Ari joined full-time. Nick and Calvin both had jobs. But we just knew it's critical for a high-potential startup like ours to really grow; we needed some sort of fundraising. And it seemed logical. We gave our shot at proper fundraising with some angels and VCs last year. There were very encouraging signs, but didn't necessarily translate to any checks being written for us. And then we applied to a bunch of accelerators; Y Combinator and TechStars were our top two. +We got a few rounds of interviews from TechStars, and the director, Ryan Kuder, who's great; he's actually based in San Diego. And I credit him to definitely being a key component here because I knew he really liked us. He saw the really good complementary team we built. We had a pretty mature product with traction and an active user base. And we accepted, and it did a lot of things for us. It was our first proper fundraising beyond a Kickstarter. So Nick and Calvin became full-time once we got in. +And then we just had this, like, you have access to this massive network and get this really detailed one on one mentorship. We had almost six or seven mentors that we met with weekly. They're always available to help. And probably the coolest thing about it is they're just there to help you. There's no two-sided, like, I'll help you if you can help me. We are here to help you build, grow, accelerate your business. +And they gave us really good insights on direction, really formalizing how to build in systems that will last much longer than the three month-program that essentially just mimicked a lot of stuff we've done on the program within our own team, like hosting little daily stand-ups every day. We've always done weekly meetings but using that time more efficiently, knowing how to test and measure more effectively. They've really just refined our company to be a proper business instead of four dudes trying to make this cool plant app. +VICTORIA: That's really cool. And I wonder now, like, after you've had this experience, what advice would you give yourself if you could go back in time to when this all started? +BRIAN: First thing that popped in my head was...and I kind of knew this going into it, like, this is a big project that needs time. Things that prevent startups usually is, one, you don't execute, or you just don't start it at all, or you give up too soon. And I guess I would tell myself, hey, things are going to be all right. Like, just keep sticking with it. And you're getting all the signals; this is something substantial and worthwhile. Just be patient, stick with it. Survive those valleys, and there are peaks on the way. And getting into TechStars was the ultimate validation. Yeah, I feel extremely blessed to be in it. And I think we're poised to do big things this year. +VICTORIA: That's very cool. So you've mentioned those peaks and valleys and how much time you have to spend on this type of starting a company [laughs] and building an app. How do you balance that with also having a regular life and going surfing and climbing? +BRIAN: It's tough to find your specific balance and especially during the accelerator where I didn't want to waste any opportunity. So there were a lot of times...I think January was a month straight no days off. And actually, I was injured so I couldn't surf, climb, or even play piano, so all my outlets. But just be okay with setting aside time to where you don't think about work at all. And it took me a few months to reach that point. And I found that as long as I have one activity or some exercise per day, either I surf or climb, I'm good. I don't mind working 12-plus hour days if I do one of those. +And then just to allocate one day of the week where I am like, I do a couple of hours in the morning. But one mostly day of don't think about work, just enjoy life. And that has been enough for me to feel refreshed going into next week. And so I think I got a good rhythm, and I got a good formula for what works for me. It might be different for other people, but it's important to set aside time where you don't think about it. +VICTORIA: Right. Yeah, just to turn off your brain. Sometimes I find, like, you know, you mentioned surfing and climbing helps you do that because you really just can't be on your phone [laughs] when you're out there sometimes. +BRIAN: Right. It's kind of funny because I'll almost say it's a catch-22. But sometimes, those things can be distracting, but they're also necessary for you to be focused if that makes sense. [laughs] +VICTORIA: Yeah, totally. Let me bring it back to plants. What is your favorite house plant that you have right now? +BRIAN: Man, it's changed over the years, but I do have one. It's like the most popular high-in-demand one; it's the Monstera albo. Its common counterpart is the Monstera deliciosa, which is all green. This one has white variegation on the leaves. They're just inherently beautiful plants. And anyone that sees it can be like, "Wow, that is gorgeous." +But I have one specific one, and why it's my favorite is that years ago, I was telling a climbing friend about the app, and I guess the app is out by now, but telling her about it. And she's like, "Oh, my grandmother was a huge plant person. My mom now takes care of them. I think she has one of those Monstera plants with the white on it. It was my grandma's though." And I was like, no way. I have to see this. And when I get there, she has this massive one, incredibly mature and old. I think she said it was almost 50 years old. I can't even believe this. +VICTORIA: Wow. +BRIAN: And then I asked her. I was like, "Hey," [laughs] I was like, "Can I have a little bit of that?" [laughs] And she was like, "Oh yeah, just go ahead. This is a plant. I'll grow it back." And I felt a little bad because I took a nice big cutting like multiple leave cutting. And she absolutely did not care and just was so happy. Turns out she had three of these like big mother plants. There's one cutting that had very low variegation, so it showed barely any white on it. Over time, I grew it out. Every subsequent leaf kept showing more and more white. And now it's just so beautiful. +I check up on it every day, and every new leaf is just more beautiful than the next. And it's a special one. And it was gifted to me by my friend's mother. It started off like you can say a lowly variegated plant, and now it's just thriving and beautiful. So it has some history, and it came from a friend. So without a doubt, that's my favorite one. [laughs] +VICTORIA: That's very cool. Yeah, I know those Monsteras that you're talking about. They're really interesting-looking plants. I kept one alive for a short time, and I'm very proud of myself for it. [laughs] So I'm interested in using Blossm to keep my plants alive possibly. But that's awesome. Thank you so much for sharing that. What else can I ask you? Is there anything that I should ask you that I haven't yet? +BRIAN: Well, we could actually segue from what you just said. This is an interesting thing. So I think everybody who's been through this has gone through this exact process. So they have a couple of plants. They're like, what's wrong with my plant? How do I take care of this? And they go down the Google rabbit hole, or they happen to buy one of these plant ID plant care apps. Usually, they're like freemium. You get a couple of free tries, and then you have to buy a subscription or whatever. +I also did this. And I was like, you know what? These apps suck. They just don't work, or they're too general. The best plant advice you can get is from other plant people because there are so many variables. Like, which growing zone are you in? What kind of light do you have? What's your ambient humidity, temperature? All these factors come into play on how to properly care for your plant and what could be wrong. And the best advice I've gotten was from other plant people. +And so we have, like, beyond the marketplace grid, we have this fully functioning community forum essentially like a Facebook group in a way where people can post questions about what's wrong with my plant, or what plant is this? Or share memes and just nerd out. And it's been such a critical component I think of Blossm to cultivate this community. But it's also just very functional and effective because really the only way to get that advice and care information is by interacting with other people. That's something we want to build upon in the future too with that whole live and video capabilities. +VICTORIA: Yeah, that makes sense. Just a funny story, sometimes I'll call my mom who's a big plant person, and ask her questions, and she's like, "Well, you should go check that book I got you." [laughter] It's like, it's not helpful at all. [laughs] But yeah, no, I think that's right. I think people get excited about AI and image recognition. But sometimes it's still easier to get a real effective answer from a human. +BRIAN: Yeah, I'd be curious with the whole AI getting its spotlight right now. And without a doubt, I could see applications there for it. Right now, I don't think that exists, but I'm very curious and excited to see what happens with all of it. It's going to be cool. +VICTORIA: Yeah. Well, that's awesome. And I am excited that what Blossm does is really create this community around plants and learning about them and with the people around you. Do you have any final takeaways for our listeners? +BRIAN: Hmm, final takeaways, you know, shameless self-promotion; if you love plants or you're getting into plants, Blossm is tailored for the plant person, which is what I think makes it special. And more general, I never intended to be the entrepreneur. I never intended for Blossm to be like, oh, this big tech company. I just had something I was super passionate about and wanted to see come alive for myself and for other people. +Without a doubt, that passion paired with perseverance, I think, are critical attributes to follow any idea to the end or to some level of success. So don't be afraid to take that leap. By no means has it been easy. It's been the most difficult thing I've ever done but also the most rewarding. It's been really fun too. So if you got a cool idea, maybe try to build it out, find a good co-founder, a good team. Give it a go and create something for everyone. +VICTORIA: Well, I really loved your story, Brian. I think you've found your niche. You built something. You took advantage of the time you had when you had it, and look where you are now. [laughs] I'm very excited to see what comes next. +BRIAN: Cool. Yeah, thank you so much for having me. This has been lovely, and yeah, stoked to listen to the next episodes too. +VICTORIA: Excellent. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Brian Feretic. + + + Brian Feretic is the Founder of Blossm, a community marketplace to buy, sell, and trade plants.

+ +

Victoria talks to Brian about how coming up with the concept happened, getting started in a very scrappy way and then filling in gaps, and opening up the app to have full marketplace functionality with buying, selling, and trading capabilities.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido or Tori. And with me today is Brian Feretic, Founder of Blossm, a community marketplace to buy, sell, and trade plants. Brian, thank you for joining us.

+ +

BRIAN: Hey, it's great to be here, Tori.

+ +

VICTORIA: Great. I'm excited to hear more about Blossm. Why don't you just tell me a little bit more about the concept?

+ +

BRIAN: The concept actually happened at the end of 2019, and I'd already been a plant enthusiast for a couple of years. I was actually just going on my way to surf in my town of Ocean Beach, San Diego, and I stopped by this garage sale. And when I came back to pay my neighbor, I brought this rubber plant that are propagated just as a neighborly gift. She flipped out. She was ecstatic. She's like, "Oh my God, I'm such a huge plant person. Thank you so much. Why don't you come into my backyard, and I'll give you a plant tour, and you can pick something out."

+ +

And what was cool about this was it wasn't just like a simple exchange. It was like this hour-long interaction with someone that lived four blocks from me that happened to be this big plant nerd like me. And I got her whole story. She went through all these different species I didn't know about. And then, she helped me pick one out, which I still have to this day. It's this crassula succulent. When I was walking home with my new plant, I was like, oh wow, I got to go download the app for this. I would have never known this person that lives four houses away was a big plant person like me.

+ +

And when I got home, I searched the App Store. I did a Google search. I just couldn't find what I was looking for, which was basically this plant-swapping plant-connecting platform where I could find fellow plant nerds in my neighborhood. And so that kind of set me off on this path. I did some more research and decided...I was like, you know what? I'm going to commit to this and make this happen for myself and for my community.

+ +

VICTORIA: Well, what do you think makes someone a plant person [laughs] or like a...how did you describe yourself? A plant nerd? What sets that user apart?

+ +

BRIAN: We'll say it's like on a spectrum where people can shift along the spectrum. But I'd say when people start treating their plants more than objects and more what they are. They are these living things. They're beautiful. They bring people joy. I find it therapeutic to take care of them. And then the beautiful thing about it is that these plants grow, and you can propagate them and share them with your friends. And I think that is a critical aspect of this whole plant person thing.

+ +

VICTORIA: So the plants have become a little more like pets, and you can grow them in a way that creates a community around your friendship and your local area.

+ +

BRIAN: Yeah, exactly. That was actually the early signal about this whole plant world is that I saw people creating plant-dedicated Instagram accounts as if it was your dog or cat. And that was something that I realized this is a different type of person. This is a very passionate person willing to, like, they're so proud of their plant babies, we call them. [laughter]

+ +

VICTORIA: Right. And it's funny, you say, plant babies. When I think of people I know who I would consider plant people, they do talk to their plants like their babies. They're like, "Oh, it's so cute." [laughs] Or they're like, "Oh, he's not feeling so well." So I think that's great. And so you started to do some research into this community, into this group. What surprised you about your early findings?

+ +

BRIAN: This was actually something that I didn't realize until I dug deeper was that I thought that it was only going to be a local thing. People wanted to experience what I did with Sondra, who's the neighbor I swapped with, this in-person connection, swapping, checking each other's gardens out and houseplants. But I learned very quickly that people ship plants to each other not only within your own state but across the country, and this is global.

+ +

And I was just like, how do people ship plants? Turns out I do it all the time, almost weekly now, for years. That aspect was critical to realize, all right; this plant community doesn't necessarily have to be bound by physical in-person distance. It can connect online, and people share all over via shipping.

+ +

VICTORIA: That's really cool. So you decided that there's a whole international community. So is that when you decided to really start building something like an application to help people?

+ +

BRIAN: I remember just throwing this idea out to a lot of different friends, like, various backgrounds. And I was like, "Hey, what do you think of this idea about connecting people through this shared love?" And there is not one person who thought it was a terrible idea. And then I remember talking about it with a roommate at the time, and basically the same thing. I was like, "Hey, man, imagine people connecting through the shared passion. Who knows? Maybe even love can blossom." And he was like, "Dude, that's what you should call it." I was like, oh, that's a great name. It's about three and a half years now, and it's stuck ever since.

+ +

VICTORIA: I love that, [laughter] about sharing love, and how the name came about, and just starting with your friends and people you knew and bouncing ideas off of them. But your background is not specifically in technology. So what about your background applied? And what did you have to learn new to take along this journey?

+ +

BRIAN: So my whole career, I've been involved within the science sector. I actually moved to San Diego to pursue graduate school in neuroscience. I was very curious about kind of full neural networks and how those contribute to behavior. Actually, the Ph.D. program I wanted to get into at UCSD, there's a specific lab doing this really cool research with this new innovative imaging technique. And I applied twice, and I didn't get in. And so I went into biotech.

+ +

But I would say probably two things helped me. I realize now going through this entrepreneur path, things that helped train me for this, was definitely a graduate school where you're pretty much broke the whole time. My lab didn't have too much funding, so you had to be really resourceful and creative to figure stuff out with minimal resources. And that's perfectly summed up the last couple of years, just like figuring stuff out.

+ +

We have no money. How do we get awareness of our product when we can't spend, you know, we don't have ad spend or marketing budget? And it just kind of requires you to get creative and think outside the box and just really think, all right, what do I do here? And I came up with some hacky-type strategies that have been very effective. [laughs]

+ +

VICTORIA: Well, very cool. It sounds like you found your team now to start working with you on this in a very scrappy way. So how did you fill in those gaps, maybe in your knowledge or your background on how to get this done by the people that you grew around you?

+ +

BRIAN: For me, it wasn't too difficult. Well, one, my background. I was very naive with tech at the time and just programming in general. So my first task, I laid out three options. It was like, one, I can learn how to code. I dabbled in it for a week, and I was like, man, there's no way. [laughter] Two, I was like, I can outsource it, maybe somewhat cheaply, but I don't want to spend all my savings on it.

+ +

But more, I knew that, you know, say you come out of MVP product, the product always is growing, adapting, evolving, or you encounter bugs. And I could just see how full of friction the process would be if I had to, like, all right, we have found a bug, send the contract out. They have to accept the contract. And I just knew progress would be too slow to operate in that fashion.

+ +

And the third option was, like, find a technical co-founder and pursue this dream with, you know, a buddy. I was like, all right, who do I know that is in the computer stuff? And that was my thought. And my first guy I pitched it to was a friend I went to college with at Bucknell University. And he was like, I think, "This is a good idea." But he's like, "I'm going to retire probably in five years, and this is going to be a very lengthy thing." He's like, "I'm not interested."

+ +

The second guy was extremely down for it, but it turns out he didn't know how to do any mobile app development. He uses a consultant. [laughs] And so the third and who I ended up working with was my surfing and climbing buddy Nick Mitchell. I just knew he did computer-type stuff. I pitched him the idea, and he was like, "What's up with this plant thing?"

+ +

VICTORIA: [laughs]

+ +

BRIAN: And I was like, "Oh, dude, this is a rapidly growing market. I know the ins and outs really well. I know this audience. I'm one of them." He wasn't sold until he heard an NPR piece talking about the houseplant boom. And then his father sent him an article from the New York Times saying how millennials are embracing houseplants and driving this new houseplant market.

+ +

And so I think this was maybe end of December, now in 2019. And he hit me up, and of course, he's like, "Oh, dude, I want in. Let's do it." But I also wanted to make sure I knew he could actually do what was the task at hand. [laughter] So I had my other first friend vet his GitHub and stuff just to make sure. [laughs]

+ +

VICTORIA: Oh, cool. [laughs]

+ +

BRIAN: And he was like, "Yeah, you know, he looks good. Worth a shot." And it turns out Nick is excellent. He did all the front end, back end. He built this whole app basically from scratch. It's pretty amazing what he's capable of. So I got it right on the third try. [laughs]

+ +

VICTORIA: That's funny. And I'm not surprised it came from networking in the climbing community, either.

+ +

BRIAN: Right. There's a lot of smart...definitely a lot of smart people in the climbing community. And those are like my closest friends now. So it was kind of cool to find someone in that place.

+ +

VICTORIA: And I've been climbing with friends before, and you're talking about work or whatever. And they're like, "Oh, yeah, I'm also like an Azure architect," [laughs] like some specific skill that's related to what you need. And I think it's a similar cultural mindset of people you want to be working with too. Maybe that's just me. So, okay, so you found your partner. You had someone who had all the skills that you needed to make this happen. How long did it take until you really had something you were proud of?

+ +

BRIAN: So, for me, I was laid off in August of 2019. I was working at Celgene, and they got acquired by Bristol Myers Squibb for like 72 billion, so massive merger. And I was kind of getting over the field. And so I was already basically unemployed. Nick, when we started actually working together in...we'll just call it January 2020. We started working on it casually, and then the pandemic happened. And then he got laid off. And he did about a three-month stint before he got another job at ServiceNow.

+ +

But within those three months, he really cranked out like a full MVP. And then I had about probably at least 60 or 70 people I knew beta test the product for feedback and just initial thoughts. And so that was like a very critical time where we were all locked down. We have this cool idea. Let's just crank this out. So we had an MVP pretty quick. And then we actually launched it in June 2020. And I was already very stoked about the product. As long as it did its core thing, which is connecting people through this shared love, I knew it was like a proper test, a good enough test to see if this is a worthy endeavor.

+ +

VICTORIA: That's really cool. So was there any surprising feedback that you got from that initial beta testing?

+ +

BRIAN: Yeah. [laughs] So the initial concept was essentially like a Tinder for plants. [laughter] And I was just thinking about this idea, like, if people could just swipe on plants they've uploaded, and then if both people liked a particular plant and they swiped on each other, and they matched, it would open up a chat that would connect them.

+ +

And it took the...one of the issues with bartering, in general, is people are like, "Oh, I'd love to swap that with you." And they're like, "Oh, what do you want to swap? What do you have?" And a lot of times, people don't align with what they have and what they want to swap. So I figured that would get this kind of friction out of there, but still, the core was connecting people. And then, very quickly, people found it fun. And this is still a feature right now on Blossm, which we've moved to the homepage. And it got a lot of engagement and interactions on it.

+ +

But one of the simple changes was like, all right, maybe this is not the optimal way to present these plants people are uploading. Nick actually drew a lot of inspiration from OfferUp. And he was like, "Oh, this is very simple. This is a very clean way to present these things." So we started getting inspiration from OfferUp, and we changed that kind of swipe card functionality just to a scrollable grid. And that was a great insight on his part, and some of that has been core to the product from that point on.

+ +

VICTORIA: That's so cool. So I can just go in the app and see a whole list of plants that people are willing to trade.

+ +

BRIAN: Right. Actually, I would say another thing that happened very early on, too, was, once again, bartering is not the most efficient way to exchange things with each other. And within weeks, we're seeing people being like, "Oh, well, what do you want to swap?" And then people are like, "Oh, well, I don't want to swap for that. I already have that." And then other people are like, "Hey, I don't want to swap anything. I just want to buy it." And then other people are like, "Hey, I don't have anything. but how do I get stuff for you?"

+ +

So right away, we opened it up to full marketplace kind of functionality with buying, selling, and trading. And we didn't have necessarily any payment system to facilitate that. We would just connect people. And then they would use Venmo, or Paypal, or Cash App, or things like that.

+ +

VICTORIA: That makes sense.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: Now you kind of got your core features figured out, and you see people engaging with the app. What are you the most excited about on the horizon in your roadmap?

+ +

BRIAN: We're about to actually finish the TechStars accelerator next week. Next week is our demo day. It's been such a great experience, and I feel blessed. But during this time, we're really figuring out, like, what's our big vision with Blossm? And we kind of went back to really harp on, like, we're more than just an e-commerce or marketplace. We're like this special passionate community where people can do this buying, and selling, and trading.

+ +

One of the things that's been the trend for years now is instead of just photos; we're about to integrate some video functionality. This is a lead in to the bigger goal. And the idea is creating this...we're calling this full plant experience focused around live video where people can engage with each other on this totally different intimate level and can really showcase their plant collection and give each other a plant tour. How do you take care of this plant? Is another big topic that always comes up.

+ +

It's just hard to really decipher what's wrong with something just from ecstatic images. And we imagine we could have live plant help. And then people can just show their plant up to the camera and showing a really holistic view of what's going on. And so this vision of live with video and creating a more complete plant experience centered around really using the community as this way to promote that and really build that even further.

+ +

VICTORIA: That's very cool. I think I've talked to you a little bit before about this giant fiddle fig I have in my office. [laughs] It's going to the ceiling. And I got it from Home Depot, so it may not be the highest quality. And I've asked you about, like, is it alive? It keeps dropping leaves. So if I had a video and I could just show you around and show you where the leaves are browning a little bit and where it's not growing, I could see the value in having that interaction like that.

+ +

BRIAN: Yeah, exactly. No one's doing that. And definitely, we want to keep innovating the space. We were first to market many years ago. And then, actually, we have some direct competitors that are blatantly just copying us, like copying email templates, features. And on one hand, it's flattering, but also we realize we have to be careful about positioning and making sure we stay ahead of the curve. And we think this is going to be the future and something that delivers really extreme value to this demographic.

+ +

VICTORIA: Absolutely. And you mentioned you're a part of a tech accelerator. Could you tell me a little bit more about choosing which program you went to and how that's affected your overall approach to your app?

+ +

BRIAN: Yeah. So last year, we added two more team members, so actually Nick's younger brother, Calvin, we poached from Amazon, which felt really good. [laughter] And then we had another friend, Ari Olmos, who we knew had experience in the startup world. He started, or I think he was, co-founder or CEO of a few other social mission startups. So he understood just the fundraising process was probably the most critical trait we're looking for, just someone that can help refine our systems, our processes, things like that. So now we're a team of four.

+ +

And we were like, all right; we need money if we want to keep this alive. And I've been full-time since the idea conception. Ari joined full-time. Nick and Calvin both had jobs. But we just knew it's critical for a high-potential startup like ours to really grow; we needed some sort of fundraising. And it seemed logical. We gave our shot at proper fundraising with some angels and VCs last year. There were very encouraging signs, but didn't necessarily translate to any checks being written for us. And then we applied to a bunch of accelerators; Y Combinator and TechStars were our top two.

+ +

We got a few rounds of interviews from TechStars, and the director, Ryan Kuder, who's great; he's actually based in San Diego. And I credit him to definitely being a key component here because I knew he really liked us. He saw the really good complementary team we built. We had a pretty mature product with traction and an active user base. And we accepted, and it did a lot of things for us. It was our first proper fundraising beyond a Kickstarter. So Nick and Calvin became full-time once we got in.

+ +

And then we just had this, like, you have access to this massive network and get this really detailed one on one mentorship. We had almost six or seven mentors that we met with weekly. They're always available to help. And probably the coolest thing about it is they're just there to help you. There's no two-sided, like, I'll help you if you can help me. We are here to help you build, grow, accelerate your business.

+ +

And they gave us really good insights on direction, really formalizing how to build in systems that will last much longer than the three month-program that essentially just mimicked a lot of stuff we've done on the program within our own team, like hosting little daily stand-ups every day. We've always done weekly meetings but using that time more efficiently, knowing how to test and measure more effectively. They've really just refined our company to be a proper business instead of four dudes trying to make this cool plant app.

+ +

VICTORIA: That's really cool. And I wonder now, like, after you've had this experience, what advice would you give yourself if you could go back in time to when this all started?

+ +

BRIAN: First thing that popped in my head was...and I kind of knew this going into it, like, this is a big project that needs time. Things that prevent startups usually is, one, you don't execute, or you just don't start it at all, or you give up too soon. And I guess I would tell myself, hey, things are going to be all right. Like, just keep sticking with it. And you're getting all the signals; this is something substantial and worthwhile. Just be patient, stick with it. Survive those valleys, and there are peaks on the way. And getting into TechStars was the ultimate validation. Yeah, I feel extremely blessed to be in it. And I think we're poised to do big things this year.

+ +

VICTORIA: That's very cool. So you've mentioned those peaks and valleys and how much time you have to spend on this type of starting a company [laughs] and building an app. How do you balance that with also having a regular life and going surfing and climbing?

+ +

BRIAN: It's tough to find your specific balance and especially during the accelerator where I didn't want to waste any opportunity. So there were a lot of times...I think January was a month straight no days off. And actually, I was injured so I couldn't surf, climb, or even play piano, so all my outlets. But just be okay with setting aside time to where you don't think about work at all. And it took me a few months to reach that point. And I found that as long as I have one activity or some exercise per day, either I surf or climb, I'm good. I don't mind working 12-plus hour days if I do one of those.

+ +

And then just to allocate one day of the week where I am like, I do a couple of hours in the morning. But one mostly day of don't think about work, just enjoy life. And that has been enough for me to feel refreshed going into next week. And so I think I got a good rhythm, and I got a good formula for what works for me. It might be different for other people, but it's important to set aside time where you don't think about it.

+ +

VICTORIA: Right. Yeah, just to turn off your brain. Sometimes I find, like, you know, you mentioned surfing and climbing helps you do that because you really just can't be on your phone [laughs] when you're out there sometimes.

+ +

BRIAN: Right. It's kind of funny because I'll almost say it's a catch-22. But sometimes, those things can be distracting, but they're also necessary for you to be focused if that makes sense. [laughs]

+ +

VICTORIA: Yeah, totally. Let me bring it back to plants. What is your favorite house plant that you have right now?

+ +

BRIAN: Man, it's changed over the years, but I do have one. It's like the most popular high-in-demand one; it's the Monstera albo. Its common counterpart is the Monstera deliciosa, which is all green. This one has white variegation on the leaves. They're just inherently beautiful plants. And anyone that sees it can be like, "Wow, that is gorgeous."

+ +

But I have one specific one, and why it's my favorite is that years ago, I was telling a climbing friend about the app, and I guess the app is out by now, but telling her about it. And she's like, "Oh, my grandmother was a huge plant person. My mom now takes care of them. I think she has one of those Monstera plants with the white on it. It was my grandma's though." And I was like, no way. I have to see this. And when I get there, she has this massive one, incredibly mature and old. I think she said it was almost 50 years old. I can't even believe this.

+ +

VICTORIA: Wow.

+ +

BRIAN: And then I asked her. I was like, "Hey," [laughs] I was like, "Can I have a little bit of that?" [laughs] And she was like, "Oh yeah, just go ahead. This is a plant. I'll grow it back." And I felt a little bad because I took a nice big cutting like multiple leave cutting. And she absolutely did not care and just was so happy. Turns out she had three of these like big mother plants. There's one cutting that had very low variegation, so it showed barely any white on it. Over time, I grew it out. Every subsequent leaf kept showing more and more white. And now it's just so beautiful.

+ +

I check up on it every day, and every new leaf is just more beautiful than the next. And it's a special one. And it was gifted to me by my friend's mother. It started off like you can say a lowly variegated plant, and now it's just thriving and beautiful. So it has some history, and it came from a friend. So without a doubt, that's my favorite one. [laughs]

+ +

VICTORIA: That's very cool. Yeah, I know those Monsteras that you're talking about. They're really interesting-looking plants. I kept one alive for a short time, and I'm very proud of myself for it. [laughs] So I'm interested in using Blossm to keep my plants alive possibly. But that's awesome. Thank you so much for sharing that. What else can I ask you? Is there anything that I should ask you that I haven't yet?

+ +

BRIAN: Well, we could actually segue from what you just said. This is an interesting thing. So I think everybody who's been through this has gone through this exact process. So they have a couple of plants. They're like, what's wrong with my plant? How do I take care of this? And they go down the Google rabbit hole, or they happen to buy one of these plant ID plant care apps. Usually, they're like freemium. You get a couple of free tries, and then you have to buy a subscription or whatever.

+ +

I also did this. And I was like, you know what? These apps suck. They just don't work, or they're too general. The best plant advice you can get is from other plant people because there are so many variables. Like, which growing zone are you in? What kind of light do you have? What's your ambient humidity, temperature? All these factors come into play on how to properly care for your plant and what could be wrong. And the best advice I've gotten was from other plant people.

+ +

And so we have, like, beyond the marketplace grid, we have this fully functioning community forum essentially like a Facebook group in a way where people can post questions about what's wrong with my plant, or what plant is this? Or share memes and just nerd out. And it's been such a critical component I think of Blossm to cultivate this community. But it's also just very functional and effective because really the only way to get that advice and care information is by interacting with other people. That's something we want to build upon in the future too with that whole live and video capabilities.

+ +

VICTORIA: Yeah, that makes sense. Just a funny story, sometimes I'll call my mom who's a big plant person, and ask her questions, and she's like, "Well, you should go check that book I got you." [laughter] It's like, it's not helpful at all. [laughs] But yeah, no, I think that's right. I think people get excited about AI and image recognition. But sometimes it's still easier to get a real effective answer from a human.

+ +

BRIAN: Yeah, I'd be curious with the whole AI getting its spotlight right now. And without a doubt, I could see applications there for it. Right now, I don't think that exists, but I'm very curious and excited to see what happens with all of it. It's going to be cool.

+ +

VICTORIA: Yeah. Well, that's awesome. And I am excited that what Blossm does is really create this community around plants and learning about them and with the people around you. Do you have any final takeaways for our listeners?

+ +

BRIAN: Hmm, final takeaways, you know, shameless self-promotion; if you love plants or you're getting into plants, Blossm is tailored for the plant person, which is what I think makes it special. And more general, I never intended to be the entrepreneur. I never intended for Blossm to be like, oh, this big tech company. I just had something I was super passionate about and wanted to see come alive for myself and for other people.

+ +

Without a doubt, that passion paired with perseverance, I think, are critical attributes to follow any idea to the end or to some level of success. So don't be afraid to take that leap. By no means has it been easy. It's been the most difficult thing I've ever done but also the most rewarding. It's been really fun too. So if you got a cool idea, maybe try to build it out, find a good co-founder, a good team. Give it a go and create something for everyone.

+ +

VICTORIA: Well, I really loved your story, Brian. I think you've found your niche. You built something. You took advantage of the time you had when you had it, and look where you are now. [laughs] I'm very excited to see what comes next.

+ +

BRIAN: Cool. Yeah, thank you so much for having me. This has been lovely, and yeah, stoked to listen to the next episodes too.

+ +

VICTORIA: Excellent. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brian Feretic.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Brian Feretic is the Founder of Blossm, a community marketplace to buy, sell, and trade plants.

+ +

Victoria talks to Brian about how coming up with the concept happened, getting started in a very scrappy way and then filling in gaps, and opening up the app to have full marketplace functionality with buying, selling, and trading capabilities.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido or Tori. And with me today is Brian Feretic, Founder of Blossm, a community marketplace to buy, sell, and trade plants. Brian, thank you for joining us.

+ +

BRIAN: Hey, it's great to be here, Tori.

+ +

VICTORIA: Great. I'm excited to hear more about Blossm. Why don't you just tell me a little bit more about the concept?

+ +

BRIAN: The concept actually happened at the end of 2019, and I'd already been a plant enthusiast for a couple of years. I was actually just going on my way to surf in my town of Ocean Beach, San Diego, and I stopped by this garage sale. And when I came back to pay my neighbor, I brought this rubber plant that are propagated just as a neighborly gift. She flipped out. She was ecstatic. She's like, "Oh my God, I'm such a huge plant person. Thank you so much. Why don't you come into my backyard, and I'll give you a plant tour, and you can pick something out."

+ +

And what was cool about this was it wasn't just like a simple exchange. It was like this hour-long interaction with someone that lived four blocks from me that happened to be this big plant nerd like me. And I got her whole story. She went through all these different species I didn't know about. And then, she helped me pick one out, which I still have to this day. It's this crassula succulent. When I was walking home with my new plant, I was like, oh wow, I got to go download the app for this. I would have never known this person that lives four houses away was a big plant person like me.

+ +

And when I got home, I searched the App Store. I did a Google search. I just couldn't find what I was looking for, which was basically this plant-swapping plant-connecting platform where I could find fellow plant nerds in my neighborhood. And so that kind of set me off on this path. I did some more research and decided...I was like, you know what? I'm going to commit to this and make this happen for myself and for my community.

+ +

VICTORIA: Well, what do you think makes someone a plant person [laughs] or like a...how did you describe yourself? A plant nerd? What sets that user apart?

+ +

BRIAN: We'll say it's like on a spectrum where people can shift along the spectrum. But I'd say when people start treating their plants more than objects and more what they are. They are these living things. They're beautiful. They bring people joy. I find it therapeutic to take care of them. And then the beautiful thing about it is that these plants grow, and you can propagate them and share them with your friends. And I think that is a critical aspect of this whole plant person thing.

+ +

VICTORIA: So the plants have become a little more like pets, and you can grow them in a way that creates a community around your friendship and your local area.

+ +

BRIAN: Yeah, exactly. That was actually the early signal about this whole plant world is that I saw people creating plant-dedicated Instagram accounts as if it was your dog or cat. And that was something that I realized this is a different type of person. This is a very passionate person willing to, like, they're so proud of their plant babies, we call them. [laughter]

+ +

VICTORIA: Right. And it's funny, you say, plant babies. When I think of people I know who I would consider plant people, they do talk to their plants like their babies. They're like, "Oh, it's so cute." [laughs] Or they're like, "Oh, he's not feeling so well." So I think that's great. And so you started to do some research into this community, into this group. What surprised you about your early findings?

+ +

BRIAN: This was actually something that I didn't realize until I dug deeper was that I thought that it was only going to be a local thing. People wanted to experience what I did with Sondra, who's the neighbor I swapped with, this in-person connection, swapping, checking each other's gardens out and houseplants. But I learned very quickly that people ship plants to each other not only within your own state but across the country, and this is global.

+ +

And I was just like, how do people ship plants? Turns out I do it all the time, almost weekly now, for years. That aspect was critical to realize, all right; this plant community doesn't necessarily have to be bound by physical in-person distance. It can connect online, and people share all over via shipping.

+ +

VICTORIA: That's really cool. So you decided that there's a whole international community. So is that when you decided to really start building something like an application to help people?

+ +

BRIAN: I remember just throwing this idea out to a lot of different friends, like, various backgrounds. And I was like, "Hey, what do you think of this idea about connecting people through this shared love?" And there is not one person who thought it was a terrible idea. And then I remember talking about it with a roommate at the time, and basically the same thing. I was like, "Hey, man, imagine people connecting through the shared passion. Who knows? Maybe even love can blossom." And he was like, "Dude, that's what you should call it." I was like, oh, that's a great name. It's about three and a half years now, and it's stuck ever since.

+ +

VICTORIA: I love that, [laughter] about sharing love, and how the name came about, and just starting with your friends and people you knew and bouncing ideas off of them. But your background is not specifically in technology. So what about your background applied? And what did you have to learn new to take along this journey?

+ +

BRIAN: So my whole career, I've been involved within the science sector. I actually moved to San Diego to pursue graduate school in neuroscience. I was very curious about kind of full neural networks and how those contribute to behavior. Actually, the Ph.D. program I wanted to get into at UCSD, there's a specific lab doing this really cool research with this new innovative imaging technique. And I applied twice, and I didn't get in. And so I went into biotech.

+ +

But I would say probably two things helped me. I realize now going through this entrepreneur path, things that helped train me for this, was definitely a graduate school where you're pretty much broke the whole time. My lab didn't have too much funding, so you had to be really resourceful and creative to figure stuff out with minimal resources. And that's perfectly summed up the last couple of years, just like figuring stuff out.

+ +

We have no money. How do we get awareness of our product when we can't spend, you know, we don't have ad spend or marketing budget? And it just kind of requires you to get creative and think outside the box and just really think, all right, what do I do here? And I came up with some hacky-type strategies that have been very effective. [laughs]

+ +

VICTORIA: Well, very cool. It sounds like you found your team now to start working with you on this in a very scrappy way. So how did you fill in those gaps, maybe in your knowledge or your background on how to get this done by the people that you grew around you?

+ +

BRIAN: For me, it wasn't too difficult. Well, one, my background. I was very naive with tech at the time and just programming in general. So my first task, I laid out three options. It was like, one, I can learn how to code. I dabbled in it for a week, and I was like, man, there's no way. [laughter] Two, I was like, I can outsource it, maybe somewhat cheaply, but I don't want to spend all my savings on it.

+ +

But more, I knew that, you know, say you come out of MVP product, the product always is growing, adapting, evolving, or you encounter bugs. And I could just see how full of friction the process would be if I had to, like, all right, we have found a bug, send the contract out. They have to accept the contract. And I just knew progress would be too slow to operate in that fashion.

+ +

And the third option was, like, find a technical co-founder and pursue this dream with, you know, a buddy. I was like, all right, who do I know that is in the computer stuff? And that was my thought. And my first guy I pitched it to was a friend I went to college with at Bucknell University. And he was like, I think, "This is a good idea." But he's like, "I'm going to retire probably in five years, and this is going to be a very lengthy thing." He's like, "I'm not interested."

+ +

The second guy was extremely down for it, but it turns out he didn't know how to do any mobile app development. He uses a consultant. [laughs] And so the third and who I ended up working with was my surfing and climbing buddy Nick Mitchell. I just knew he did computer-type stuff. I pitched him the idea, and he was like, "What's up with this plant thing?"

+ +

VICTORIA: [laughs]

+ +

BRIAN: And I was like, "Oh, dude, this is a rapidly growing market. I know the ins and outs really well. I know this audience. I'm one of them." He wasn't sold until he heard an NPR piece talking about the houseplant boom. And then his father sent him an article from the New York Times saying how millennials are embracing houseplants and driving this new houseplant market.

+ +

And so I think this was maybe end of December, now in 2019. And he hit me up, and of course, he's like, "Oh, dude, I want in. Let's do it." But I also wanted to make sure I knew he could actually do what was the task at hand. [laughter] So I had my other first friend vet his GitHub and stuff just to make sure. [laughs]

+ +

VICTORIA: Oh, cool. [laughs]

+ +

BRIAN: And he was like, "Yeah, you know, he looks good. Worth a shot." And it turns out Nick is excellent. He did all the front end, back end. He built this whole app basically from scratch. It's pretty amazing what he's capable of. So I got it right on the third try. [laughs]

+ +

VICTORIA: That's funny. And I'm not surprised it came from networking in the climbing community, either.

+ +

BRIAN: Right. There's a lot of smart...definitely a lot of smart people in the climbing community. And those are like my closest friends now. So it was kind of cool to find someone in that place.

+ +

VICTORIA: And I've been climbing with friends before, and you're talking about work or whatever. And they're like, "Oh, yeah, I'm also like an Azure architect," [laughs] like some specific skill that's related to what you need. And I think it's a similar cultural mindset of people you want to be working with too. Maybe that's just me. So, okay, so you found your partner. You had someone who had all the skills that you needed to make this happen. How long did it take until you really had something you were proud of?

+ +

BRIAN: So, for me, I was laid off in August of 2019. I was working at Celgene, and they got acquired by Bristol Myers Squibb for like 72 billion, so massive merger. And I was kind of getting over the field. And so I was already basically unemployed. Nick, when we started actually working together in...we'll just call it January 2020. We started working on it casually, and then the pandemic happened. And then he got laid off. And he did about a three-month stint before he got another job at ServiceNow.

+ +

But within those three months, he really cranked out like a full MVP. And then I had about probably at least 60 or 70 people I knew beta test the product for feedback and just initial thoughts. And so that was like a very critical time where we were all locked down. We have this cool idea. Let's just crank this out. So we had an MVP pretty quick. And then we actually launched it in June 2020. And I was already very stoked about the product. As long as it did its core thing, which is connecting people through this shared love, I knew it was like a proper test, a good enough test to see if this is a worthy endeavor.

+ +

VICTORIA: That's really cool. So was there any surprising feedback that you got from that initial beta testing?

+ +

BRIAN: Yeah. [laughs] So the initial concept was essentially like a Tinder for plants. [laughter] And I was just thinking about this idea, like, if people could just swipe on plants they've uploaded, and then if both people liked a particular plant and they swiped on each other, and they matched, it would open up a chat that would connect them.

+ +

And it took the...one of the issues with bartering, in general, is people are like, "Oh, I'd love to swap that with you." And they're like, "Oh, what do you want to swap? What do you have?" And a lot of times, people don't align with what they have and what they want to swap. So I figured that would get this kind of friction out of there, but still, the core was connecting people. And then, very quickly, people found it fun. And this is still a feature right now on Blossm, which we've moved to the homepage. And it got a lot of engagement and interactions on it.

+ +

But one of the simple changes was like, all right, maybe this is not the optimal way to present these plants people are uploading. Nick actually drew a lot of inspiration from OfferUp. And he was like, "Oh, this is very simple. This is a very clean way to present these things." So we started getting inspiration from OfferUp, and we changed that kind of swipe card functionality just to a scrollable grid. And that was a great insight on his part, and some of that has been core to the product from that point on.

+ +

VICTORIA: That's so cool. So I can just go in the app and see a whole list of plants that people are willing to trade.

+ +

BRIAN: Right. Actually, I would say another thing that happened very early on, too, was, once again, bartering is not the most efficient way to exchange things with each other. And within weeks, we're seeing people being like, "Oh, well, what do you want to swap?" And then people are like, "Oh, well, I don't want to swap for that. I already have that." And then other people are like, "Hey, I don't want to swap anything. I just want to buy it." And then other people are like, "Hey, I don't have anything. but how do I get stuff for you?"

+ +

So right away, we opened it up to full marketplace kind of functionality with buying, selling, and trading. And we didn't have necessarily any payment system to facilitate that. We would just connect people. And then they would use Venmo, or Paypal, or Cash App, or things like that.

+ +

VICTORIA: That makes sense.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

VICTORIA: Now you kind of got your core features figured out, and you see people engaging with the app. What are you the most excited about on the horizon in your roadmap?

+ +

BRIAN: We're about to actually finish the TechStars accelerator next week. Next week is our demo day. It's been such a great experience, and I feel blessed. But during this time, we're really figuring out, like, what's our big vision with Blossm? And we kind of went back to really harp on, like, we're more than just an e-commerce or marketplace. We're like this special passionate community where people can do this buying, and selling, and trading.

+ +

One of the things that's been the trend for years now is instead of just photos; we're about to integrate some video functionality. This is a lead in to the bigger goal. And the idea is creating this...we're calling this full plant experience focused around live video where people can engage with each other on this totally different intimate level and can really showcase their plant collection and give each other a plant tour. How do you take care of this plant? Is another big topic that always comes up.

+ +

It's just hard to really decipher what's wrong with something just from ecstatic images. And we imagine we could have live plant help. And then people can just show their plant up to the camera and showing a really holistic view of what's going on. And so this vision of live with video and creating a more complete plant experience centered around really using the community as this way to promote that and really build that even further.

+ +

VICTORIA: That's very cool. I think I've talked to you a little bit before about this giant fiddle fig I have in my office. [laughs] It's going to the ceiling. And I got it from Home Depot, so it may not be the highest quality. And I've asked you about, like, is it alive? It keeps dropping leaves. So if I had a video and I could just show you around and show you where the leaves are browning a little bit and where it's not growing, I could see the value in having that interaction like that.

+ +

BRIAN: Yeah, exactly. No one's doing that. And definitely, we want to keep innovating the space. We were first to market many years ago. And then, actually, we have some direct competitors that are blatantly just copying us, like copying email templates, features. And on one hand, it's flattering, but also we realize we have to be careful about positioning and making sure we stay ahead of the curve. And we think this is going to be the future and something that delivers really extreme value to this demographic.

+ +

VICTORIA: Absolutely. And you mentioned you're a part of a tech accelerator. Could you tell me a little bit more about choosing which program you went to and how that's affected your overall approach to your app?

+ +

BRIAN: Yeah. So last year, we added two more team members, so actually Nick's younger brother, Calvin, we poached from Amazon, which felt really good. [laughter] And then we had another friend, Ari Olmos, who we knew had experience in the startup world. He started, or I think he was, co-founder or CEO of a few other social mission startups. So he understood just the fundraising process was probably the most critical trait we're looking for, just someone that can help refine our systems, our processes, things like that. So now we're a team of four.

+ +

And we were like, all right; we need money if we want to keep this alive. And I've been full-time since the idea conception. Ari joined full-time. Nick and Calvin both had jobs. But we just knew it's critical for a high-potential startup like ours to really grow; we needed some sort of fundraising. And it seemed logical. We gave our shot at proper fundraising with some angels and VCs last year. There were very encouraging signs, but didn't necessarily translate to any checks being written for us. And then we applied to a bunch of accelerators; Y Combinator and TechStars were our top two.

+ +

We got a few rounds of interviews from TechStars, and the director, Ryan Kuder, who's great; he's actually based in San Diego. And I credit him to definitely being a key component here because I knew he really liked us. He saw the really good complementary team we built. We had a pretty mature product with traction and an active user base. And we accepted, and it did a lot of things for us. It was our first proper fundraising beyond a Kickstarter. So Nick and Calvin became full-time once we got in.

+ +

And then we just had this, like, you have access to this massive network and get this really detailed one on one mentorship. We had almost six or seven mentors that we met with weekly. They're always available to help. And probably the coolest thing about it is they're just there to help you. There's no two-sided, like, I'll help you if you can help me. We are here to help you build, grow, accelerate your business.

+ +

And they gave us really good insights on direction, really formalizing how to build in systems that will last much longer than the three month-program that essentially just mimicked a lot of stuff we've done on the program within our own team, like hosting little daily stand-ups every day. We've always done weekly meetings but using that time more efficiently, knowing how to test and measure more effectively. They've really just refined our company to be a proper business instead of four dudes trying to make this cool plant app.

+ +

VICTORIA: That's really cool. And I wonder now, like, after you've had this experience, what advice would you give yourself if you could go back in time to when this all started?

+ +

BRIAN: First thing that popped in my head was...and I kind of knew this going into it, like, this is a big project that needs time. Things that prevent startups usually is, one, you don't execute, or you just don't start it at all, or you give up too soon. And I guess I would tell myself, hey, things are going to be all right. Like, just keep sticking with it. And you're getting all the signals; this is something substantial and worthwhile. Just be patient, stick with it. Survive those valleys, and there are peaks on the way. And getting into TechStars was the ultimate validation. Yeah, I feel extremely blessed to be in it. And I think we're poised to do big things this year.

+ +

VICTORIA: That's very cool. So you've mentioned those peaks and valleys and how much time you have to spend on this type of starting a company [laughs] and building an app. How do you balance that with also having a regular life and going surfing and climbing?

+ +

BRIAN: It's tough to find your specific balance and especially during the accelerator where I didn't want to waste any opportunity. So there were a lot of times...I think January was a month straight no days off. And actually, I was injured so I couldn't surf, climb, or even play piano, so all my outlets. But just be okay with setting aside time to where you don't think about work at all. And it took me a few months to reach that point. And I found that as long as I have one activity or some exercise per day, either I surf or climb, I'm good. I don't mind working 12-plus hour days if I do one of those.

+ +

And then just to allocate one day of the week where I am like, I do a couple of hours in the morning. But one mostly day of don't think about work, just enjoy life. And that has been enough for me to feel refreshed going into next week. And so I think I got a good rhythm, and I got a good formula for what works for me. It might be different for other people, but it's important to set aside time where you don't think about it.

+ +

VICTORIA: Right. Yeah, just to turn off your brain. Sometimes I find, like, you know, you mentioned surfing and climbing helps you do that because you really just can't be on your phone [laughs] when you're out there sometimes.

+ +

BRIAN: Right. It's kind of funny because I'll almost say it's a catch-22. But sometimes, those things can be distracting, but they're also necessary for you to be focused if that makes sense. [laughs]

+ +

VICTORIA: Yeah, totally. Let me bring it back to plants. What is your favorite house plant that you have right now?

+ +

BRIAN: Man, it's changed over the years, but I do have one. It's like the most popular high-in-demand one; it's the Monstera albo. Its common counterpart is the Monstera deliciosa, which is all green. This one has white variegation on the leaves. They're just inherently beautiful plants. And anyone that sees it can be like, "Wow, that is gorgeous."

+ +

But I have one specific one, and why it's my favorite is that years ago, I was telling a climbing friend about the app, and I guess the app is out by now, but telling her about it. And she's like, "Oh, my grandmother was a huge plant person. My mom now takes care of them. I think she has one of those Monstera plants with the white on it. It was my grandma's though." And I was like, no way. I have to see this. And when I get there, she has this massive one, incredibly mature and old. I think she said it was almost 50 years old. I can't even believe this.

+ +

VICTORIA: Wow.

+ +

BRIAN: And then I asked her. I was like, "Hey," [laughs] I was like, "Can I have a little bit of that?" [laughs] And she was like, "Oh yeah, just go ahead. This is a plant. I'll grow it back." And I felt a little bad because I took a nice big cutting like multiple leave cutting. And she absolutely did not care and just was so happy. Turns out she had three of these like big mother plants. There's one cutting that had very low variegation, so it showed barely any white on it. Over time, I grew it out. Every subsequent leaf kept showing more and more white. And now it's just so beautiful.

+ +

I check up on it every day, and every new leaf is just more beautiful than the next. And it's a special one. And it was gifted to me by my friend's mother. It started off like you can say a lowly variegated plant, and now it's just thriving and beautiful. So it has some history, and it came from a friend. So without a doubt, that's my favorite one. [laughs]

+ +

VICTORIA: That's very cool. Yeah, I know those Monsteras that you're talking about. They're really interesting-looking plants. I kept one alive for a short time, and I'm very proud of myself for it. [laughs] So I'm interested in using Blossm to keep my plants alive possibly. But that's awesome. Thank you so much for sharing that. What else can I ask you? Is there anything that I should ask you that I haven't yet?

+ +

BRIAN: Well, we could actually segue from what you just said. This is an interesting thing. So I think everybody who's been through this has gone through this exact process. So they have a couple of plants. They're like, what's wrong with my plant? How do I take care of this? And they go down the Google rabbit hole, or they happen to buy one of these plant ID plant care apps. Usually, they're like freemium. You get a couple of free tries, and then you have to buy a subscription or whatever.

+ +

I also did this. And I was like, you know what? These apps suck. They just don't work, or they're too general. The best plant advice you can get is from other plant people because there are so many variables. Like, which growing zone are you in? What kind of light do you have? What's your ambient humidity, temperature? All these factors come into play on how to properly care for your plant and what could be wrong. And the best advice I've gotten was from other plant people.

+ +

And so we have, like, beyond the marketplace grid, we have this fully functioning community forum essentially like a Facebook group in a way where people can post questions about what's wrong with my plant, or what plant is this? Or share memes and just nerd out. And it's been such a critical component I think of Blossm to cultivate this community. But it's also just very functional and effective because really the only way to get that advice and care information is by interacting with other people. That's something we want to build upon in the future too with that whole live and video capabilities.

+ +

VICTORIA: Yeah, that makes sense. Just a funny story, sometimes I'll call my mom who's a big plant person, and ask her questions, and she's like, "Well, you should go check that book I got you." [laughter] It's like, it's not helpful at all. [laughs] But yeah, no, I think that's right. I think people get excited about AI and image recognition. But sometimes it's still easier to get a real effective answer from a human.

+ +

BRIAN: Yeah, I'd be curious with the whole AI getting its spotlight right now. And without a doubt, I could see applications there for it. Right now, I don't think that exists, but I'm very curious and excited to see what happens with all of it. It's going to be cool.

+ +

VICTORIA: Yeah. Well, that's awesome. And I am excited that what Blossm does is really create this community around plants and learning about them and with the people around you. Do you have any final takeaways for our listeners?

+ +

BRIAN: Hmm, final takeaways, you know, shameless self-promotion; if you love plants or you're getting into plants, Blossm is tailored for the plant person, which is what I think makes it special. And more general, I never intended to be the entrepreneur. I never intended for Blossm to be like, oh, this big tech company. I just had something I was super passionate about and wanted to see come alive for myself and for other people.

+ +

Without a doubt, that passion paired with perseverance, I think, are critical attributes to follow any idea to the end or to some level of success. So don't be afraid to take that leap. By no means has it been easy. It's been the most difficult thing I've ever done but also the most rewarding. It's been really fun too. So if you got a cool idea, maybe try to build it out, find a good co-founder, a good team. Give it a go and create something for everyone.

+ +

VICTORIA: Well, I really loved your story, Brian. I think you've found your niche. You built something. You took advantage of the time you had when you had it, and look where you are now. [laughs] I'm very excited to see what comes next.

+ +

BRIAN: Cool. Yeah, thank you so much for having me. This has been lovely, and yeah, stoked to listen to the next episodes too.

+ +

VICTORIA: Excellent. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Brian Feretic.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+G1z_bxXk + + ]]> + + Victoria Guido + Brian Feretic + + + 470: CTO Excellence in 100 Days with Etienne de Bruin + https://podcast.thoughtbot.com/470 + 82664013-38d3-48f1-b19c-d20bf6b5e6de + Thu, 13 Apr 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Etienne de Bruin is Founder of 7CTOs and Author of CTO Excellence in 100 Days. + +Victoria talks to Etienne about his book, founding 7CTOs, and keeping your technology sustainable by inspiring and motivating technology teams and people to work together and build complex systems. + 40:05 + no + + + Etienne de Bruin is Founder of 7CTOs and Author of CTO Excellence in 100 Days. +Victoria talks to Etienne about his book, founding 7CTOs, and keeping your technology sustainable by inspiring and motivating technology teams and people to work together and build complex systems. +CTO Excellence in 100 Days (https://www.amazon.com/CTO-Excellence-100-Days-Becoming-ebook/dp/B0BV8P7K3S/ref=sr_1_1?crid=14TM3PTHA16UA&keywords=cto+excellence+in+100+days&qid=1680643461&sprefix=CTO+Excellence+in+100+Days%2Caps%2C110&sr=8-1) +7CTOs (https://7ctos.com/) +Follow 7CTOs on Twitter (https://twitter.com/7ctos), Instagram (https://www.instagram.com/7ctos/), Facebook (https://www.facebook.com/7CTOs) or YouTube (https://www.youtube.com/c/7ctos). +Follow Etienne de Bruin on LinkedIn (https://www.linkedin.com/in/etdebruin/) or Twitter (https://twitter.com/etdebruin). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Etienne de Bruin, Founder of 7CTOs and Author of CTO Excellence in 100 Days. Etienne, thank you for joining me. +ETIENNE: My pleasure, Victoria. Thanks for having me. +VICTORIA: You're welcome. I'm excited to talk with you today. I hear that you recently published your book. Is it today actually the day it came out? +ETIENNE: Today is the day. The book was finished about; I would say, three months ago. So I have had great anticipation now for many, many months. And you caught me on the day, so I feel like today is my birthday. +VICTORIA: [laughs] Well, I feel honored that you chose us as your first stop [laughs] in your marketing push for your book. So tell me, what in your experience led you to begin writing this? +ETIENNE: Well, as you mentioned, I founded 7CTOs. I think it's about ten years ago now. I myself am a CTO type. I've had a career of basically being born to code in South Africa, which took me to Stellenbosch University in South Africa. I then joined a startup that took me to Germany and then landed in the U.S. in San Diego. And my whole journey has been a progression from individual contributor and really having great coding skills through the messiness and the intricacies of building startups, contributing to startups, and ultimately being in the role of CTO in startups. +And what led me to founding 7CTOs was just a realization that I didn't have the support I needed. I felt like I was going to many meetups, which was mostly oriented towards coding and sort of different new technology stacks and frameworks, or I was going to cocktail hours with vendors who were trying to sell you something. And I really felt the need to just be with my people so that I could, in a safe, and consistent, and accountable way, share the challenges that I was experiencing. +It was really from this place of founding 7CTOs, talking to hundreds of...I've probably spoken to thousands of CTOs by now. I've also placed people. I've connected people. I've seen people join companies because of connections I've made. And one of the things I saw that really bothered me was finding a great company in search of a CTO reaching out to me, talking to me about the role, me finding or through my network connecting them with a great CTO, only to find that a few months later either the relationship fizzles or even worse, the person did not succeed at the new company. +And I just felt like you can have two people, a great founder, and great CTO, individually wonderful people, ostensibly well-suited to work with each other, but then make some basic mistakes that then lead towards not the desired outcome. And so I was really torn whether I should put some thoughts into a book or into some blog posts about what I think the first 100 days should look like in a fledgling relationship. And that's ultimately how the book was born. So long, long, long, long answer, Victoria. But that's where it all started. +VICTORIA: No, that's great. I try to ask deep questions that get full answers back. [laughs] +ETIENNE: You nailed it. +VICTORIA: So I appreciate that context, yeah. So you talk about how to be successful in those first 100 days, which is critical to joining a new leadership team. What are some common mistakes that you mention that a CTO might make? And on the reverse side, what are some wins you could do early on to build trust? +ETIENNE: I think a common mistake that I see is a bit of an identity issue. The CTO joins an organization and is eager to deliver value, and I think that that value is oftentimes misplaced. And what I mean by that is you hit the ground running thinking that there's all this stuff that you have to deliver in order to prove that you can make an impact, to prove that you were the right choice. And I think there's an innate desire to impress your new employer, which I don't think is limited to the role of CTO. But I think for the CTO, this looks like some technical achievements and impact, problem-solving. +And I think what I like to see is the first 100 days being used to slow down a little bit, to listen, to be curious, to be open to building relationships, to have a longer view on what exactly is the system that you're joining. And I think to a fault; sometimes people will ignore the system they're joining and just start delivering value. And I think that that can often be misinterpreted or misunderstood. And then, if that is misunderstood in the first few months, then that really sets a tone for the rest of the tenure that I think puts the CTO on the back foot to deliver at a pace that maybe is unsustainable, so... +VICTORIA: I love that you said staying curious because I think what you can see is a tendency for, I don't know, what I've seen; maybe you've seen this too. [chuckle] But some people have a problem that they solved in a past situation, and they think that that is now the solution to every problem that they come into in a new organization, and maybe it is. But I think dealing in complex systems, having curiosity as to why decisions were made in a certain way can lead you to a better understanding of the business if that resonates with you at all. +ETIENNE: Yeah, I love that you said that. I'm a huge fan and student of complex systems. And so you just spoke my love language. +VICTORIA: [laughs] +ETIENNE: But that's exactly what happens. And I think that sometimes the debilitater of powerful and impactful people is the problem that you observe is maybe tainted by what you saw in the past. It might be a similar challenge, a similar problem. But what you solved in the past was part of a completely different system, different entities, different relationships. +And I think that by nature because the CTO is used to solving thousands and thousands of problems, there may be a bit of complacency around what is it exactly that I'm observing is the challenge here? Why exactly was I hired? What exactly does success look like for them, for the people that hired me, for the system that I've come into? And I think the tendency is to ignore all of those questions and focus on how do I feed my own need to feel valued and start solving problems in sort of a whack-a-mole style? +And I have found, even in my own experience, that there are some seriously unintended consequences that can arise from solving people's problems for them in ways that they are not used to, or they don't understand, or in some places just fully disagree with. And I think if you are not patient and take sort of 100 full days to just chill out and really enjoy learning about the system that you're joining, I think you're setting yourself up to fail or to at least be very unhappy. +VICTORIA: Right, setting yourself up for some fun conflicts [laughs] to solve if you come out right out the gate. And I think maybe, too, the first 100 days the chilling out and learning, you also have time to build empathy and build trust with people so that when you do bring up suggestions, they're maybe a little more willing to listen, right? +ETIENNE: Yes. And I think it's not uncommon to say, "Oh, well, I'm going to onboard myself. It's going to take some time before I show value." And I think there is a general sense that when the executive joins a company that, it's going to take some time. But I think that the temptation to jump into fiery situations is great, great in a bad way. It's a great temptation. And my book and my approach suggests that you take a step back and focus on a completely different area of the company, which is its people and its systems, and what success looks like for those people before you start jumping in and asserting your way of doing things. +VICTORIA: And you mentioned a question that I was going to ask, like, what does success look like? Or say you're a CEO, and you're trying to hire a CTO; what does success look like? What kind of value do you think people should expect from someone in a CTO role? +ETIENNE: Fundamentally, I think I might not be swimming in the mainstream on this topic. I don't believe that the CTO is a technical role first. I believe that the CTO is the Chief Technology Officer but is primarily a business role. And by that, I mean being a member of the C-suite, you are tasked, just like all the other members of the C-suite, to grow a company in a sustainable way. And whatever that middle letter is, is your domain and your expertise, and that's cool. But that T is surrounded by a C and an O, which in most cases has a fiduciary responsibility to the organization. +But also, first and foremost, you are a first-class member of the C-suite. And so my book talks about this, but you are there to join in with the executive leadership team and to help that team towards success. And so what that looks like for me is you are wrestling on what the targets are for the company. You participate fully in that. You then allocate a budget. In other words, you allocate cost towards how you can achieve those revenue goals. And then, with that budget as CTO, you then are budgeting towards a team that you believe can get the technology implemented that will ultimately produce the revenue. So think about revenue target, technology budget, technology people. +Now, these are all in the C-suite. These are just entries on a P&L. These are entries on the balance sheet. These are things that ultimately are abstracted towards company growth and company success. So with that, the CTO then turns into someone who wrestles with the tech teams, like, what are we going to implement? What ideas are consistent with our company principles and our vision? What does innovation look like? How do we inspire people to join our organization to do so? That, to me, is a fundamental role for the CTO, to inspire people to join the organization but also to be someone who implements and ideates on that journey. +So I think a CTO succeeds when there is revenue growth, and that is due to budget being spent in an effective way to attract amazing people to ultimately build technology that is sustainable that then feeds into tech revenue that ultimately helps the company achieve its goals. +VICTORIA: That's great. Yeah, I like that you said sustainable and the importance of people and how that relates to keeping your technology sustainable. And I'm curious if you could share more about what practices a CTO could bring to a new organization to facilitate that inspiration and to really motivate technology teams and people to work together and build these systems. +ETIENNE: I think that speaks to my earlier answer, which is the investment in people and investment in understanding the systems that exist. So whether you are a CTO, that is the first time a company ever scales and grows into having that role being created, which, you know, most tech startups these days will have the role of CTO allocated and available. The important thing to understand for you as someone stepping into that role is that your teams have a construct. They have an impression. They have an image, either of your predecessor at that company or their experiences with leadership and technology at their previous companies. +And I think it's extremely important to understand how you're being seen as a leader in the company and as CTO and that that vision of what people have of you is not necessarily based on your actions, your reputation, your good mornings in the mornings and your good evenings in the evenings. It really is based on people's constructs about what their experience has been of a CTO in their career, or like I said, the previous CTO, your predecessor. +And so I think that it's critical as you step into this role that you take the time to bring that change to show people your ways, to show people what is important to you in a way that's not a bull in a china shop. But when you break stuff, and you come in, and you announce your presence, and you assert the new way of doing things, I think that that is met with suspicion and concern most of the time. +And so I think if you can show people in the little things that you care about them, you're listening to them, you're curious about the system they're operating inside of, I think that that sets you up to then come in with the big ideas later on. But again, the emphasis being later on, past the 100 days. I talk about this in the book where introducing your tech strategy, introducing your way of doing things really comes a lot later in the 100 days than is maybe the preconceived notion. +VICTORIA: And you also mentioned a few times what the CTO should be doing and a lot of great questions that you ask, like, what does success look like? How do we build this together? And finding ways to maybe generate more ideas than just what you would come up with with your team, you're more powerful. +ETIENNE: Yes. And I think tag teaming on to that is a lot of times...and this is actually really a confounding thing that I've come across, which is the C-suite won't always understand what the role of CTO actually is. And teams won't always fully understand what the role of CTO is. When you talk about a CMO, or a CRO, or a CFO, I think you can generally understand what they're supposed to be doing. That isn't always clear for the CTO. +And it's amazing how many times I have gotten the question, well, we knew we needed someone to help us with the tech, but we don't really know what it is that you do, or what you should be doing, or what success looks like. I think not making the assumption that people know what you're there to do is a form of showing some respect and humility. +And this is why always when I'm in executive meetings, when I'm in stand-ups, or I'm in some sort of an architecture meeting, I will almost without fail I will say, "As the role of CTO, this is what I bring to the meeting," or "This is what the role of CTO would be looking for as an outcome of this conversation." Or "As the role of CTO, it is my job to ensure that our development capacity increases," to just never assume that people know what it is that you're there to do but to show them, I think, the respect and the courtesy that the role of CTO has a certain place in whatever meeting or brainstorm session is going on. +VICTORIA: I think that makes sense, too, because I could see, you know, especially you mentioned with people who maybe have had past experiences with CTOs that are not the most positive. If you bring up an idea in a meeting, everyone thinks, well, that's the solution. That's what the CTO wants. And it might not. Everyone might not feel comfortable, like, without you caveating; this is why I'm bringing this up. You know, we're here to brainstorm and not for me to just tell you what to do. [laughs] +ETIENNE: Yes, yes. And that's why I will often...honestly, this might be a real tip for people listening. But I will actively divorce who I am from the role that I'm in. And it enables me to have difficult conversations. It enables me to assert leadership without dominance. And that is to just say, "Hey, Sandra, in my role as CTO, this is what I am looking for in your growth or in your career path." Versus, "Hey, Sandra, I want you to..." or "I need you to..." +And I think the subtle difference there is to just assure someone that you're operating in a capacity that the company expects from you versus somehow having your identity wrapped in the outcome of a conversation. And that really has been a very powerful tool for me as I integrate into new companies or as I need to navigate tricky conversations. +VICTORIA: I appreciate you sharing that. I think hopefully that will be a great point for someone who's maybe struggling with something similar at this time. And maybe there are other common questions or themes that come up when you're talking to all these CTOs in organizations that you can share. +ETIENNE: By the way, if your name is Sandra and you're listening to this conversation, I totally made up the name Sandra, so I'm not referring to you, Sandra. +VICTORIA: [laughs] +ETIENNE: Okay. I think an interesting thing that I've noticed is given the stage of my company, have I addressed all the things that I need to by now? And I think that is such an indication of the times that we live in. Technology is always changing. Expectations are always changing. Clearly, if you're in a technology innovation company, things are rapidly changing. It's funny because some things just stay the same, i.e., people problems and all that. +But as far as technology landscape goes, I think that there is a little bit of a daunting feeling that, hey, I'm CTO in this company, but I don't know if I am where I need to be at compared to what other successful companies let's say, for instance, a series A company is doing. And as CTO, am I applying, am I showing up in the way that great CTOs of other series A companies are showing up? And so I would say that's problem number one is, am I operating at the level that I should be that my company is expecting of me? That's a real challenge that CTOs have. +And I think level-setting expectations communicating where we should be at is a skill that I think is missing from a lot of people who are in that role. And I think it's because we get to the roles of CTO by being people who rapidly solve problems or speedily deliver on technology. And we start associating speed with being good at our jobs, and I really think that that is wrong; that is just wrong. When you're in an executive role, patience and spending the extra day or the extra week fighting for the extra month, I think, is actually a very important role that the CTO plays in the C-suite. +And so if you have an underdeveloped sense of your own leadership style, an underdeveloped sense of your being and your essence and what it is you actually bring to the table, I think you end up just being sort of a knee-jerk tech person that just implements what other people want you to so that you could be valued for what it is that you do. Versus having that solid executive presence inside of a company that really influences and can shape the vision of the organization. +VICTORIA: Yeah, I think that's super interesting how common that question is. And I wonder if it gets to sometimes creating a shared understanding between the executive team about the technology and why certain things are important or not important. I wonder if you could talk about any maybe major trends that you see executive teams trying to take advantage of that are either positive or negative. +ETIENNE: The thing I've seen the most, which has had the greatest impact on, I think, executive teams, at least from my vantage point, is the desire to adopt some sort of business playbook or a business operating system. I think one of the most popular ones is the EOS model, Entrepreneurs Operating System. Gino Wickman, I think, wrote the book "Traction." And so it's caused a big trend with companies to try and streamline their operations by following the EOS model. And I do think that that might be the wrong solution to the right problem for many companies. +What I mean by that is, again, we're talking about blueprints. What works for one company isn't necessarily going to work for the next company. The way you set goals, the way you set your so-called rocks, or the way you set your quarterly goals, or even working by quarter if you think about a quarter, it's such an interesting...it's really a Wall Street concept. It's three months. It's really so arbitrary. +And I think that I see C-suites trying to adopt a business operating system that other companies are doing without really the necessary work being done as to, hey, what compels us through our culture, who we are, how we like to do things, what it is that works for us? And I will see some C-suites sort of spin their wheels a little bit on trying to adopt other systems when really all it takes is for them to do their own work to see what is the value stream? What does it look like inside of their company? +I actually encourage, and I think I talk about this in this book; in days 60 to 70, I talk about learning to improvise. And I think this is where I look to the CTO to use their spidey senses and their logical deduction skills, their deconstruction skills to observe what is actually happening inside of the C-suite and to facilitate conversations around what is it that people need? How do we improvise on systems that we already have? Or how do we deal with missed expectations? And I do think that the CTO can play a wonderful role inside of the C-suite to facilitate those conversations. +But I see inside of C-suites, the role of CTO being relegated to the IT person or just the tech person. And I think that victimization goes both ways. But the C-suite, where the CTO is actually facilitating hard conversations and able to do the decomposition of a complex system or the deconstruction of an often repeated problem or challenge that the company is experiencing, could really push the C-suite into a different track of thinking that could be super beneficial to unblocking some stodgy issues they've been facing. +VICTORIA: That makes sense. And it reminds me of trying to adopt agile right when it was first becoming popular and committing so hard to a framework that you don't look at what works for your team [laughs] and works for the specific technology and tools that you have. So it makes sense to me that the CTO could bring an experience like that into applying frameworks to how the business operates. +ETIENNE: Absolutely. And I think that's really when dogmatism could be your enemy. And, again, CTO joins a company, knows a certain set of skills in order to accomplish things, dogmatically tries to apply that because they are the so-called expert. And then they fail, or they're unhappy, or there's misunderstanding because we had these high expectations for you. Your interviewing was brilliant, and you said all the right things. But then, when you walked into the organization, your desire for acceptance and delivering value trumps your opportunity to be the new person and be curious about what is actually happening and what is actually going on. +This should be so obvious, but when you walk into a C-suite, there are obviously existing relationships between all the different members of the C-suite. And I advocate for being a student of those relationships. Understand the history that exists between the CEO and the CFO. And these could be very great newbie conversations to have with these various members of the C-suite. "Hey, so when did you join the company? Hey, why did you join the company? Hey, wait, which company did you come from? What drew you to this company? Where did you used to live? Why did you move?" +I think these are such incredible nodes in a complex relational hierarchy that can give you some very sound ideas as to, oh, well, why does the CEO constantly challenge what the COO is saying? Or why does the COO seem surpassed all the time? You, as CTO you, would do very well. I mean, as any C-suite member, any leader would do well to seek some insight and perception into what is going on for people. +VICTORIA: That makes sense, right? If you're going to have influence, you have to kind of understand what are all the connections and energy that's going around in the team? +ETIENNE: Absolutely. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: And maybe you can tell me more about 7CTOs and what that community can mean for someone who's growing in this role. +ETIENNE: 7CTOs, like I said earlier, I founded it...I almost said 100 days ago. I founded it ten years ago. And it was as I mentioned, the genesis of the story, which is important, is I co-founded a company with two people. I wrote the first lines of code for our product. In fact, I wrote the whole version 1 myself. And as the company grew and as the company grew beyond what it was that the three of us were comfortable with, I noticed that my CEO joined an organization a peer group organization. My COO joined a peer group organization. And I just saw this transformation in them that I really admired. +I was actually really envious when they were able to start taking what they've learned from their peer groups and bring them into our company to start operating more efficiently. And so, it was just natural that I would look for something for CTOs, and I couldn't find anything. I actually tried to join sort of more generic business leadership groups like Vestige or EO even. And I found that I wasn't really with my people. I wanted to feel like I was with the geeks who could talk all day about tech and development and probably watch the same movies and read the same books or inspired or laugh at the same jokes. +I wanted to find my people who were facing the same problems and challenges that I was, i.e., scaling companies beyond the things that we knew, beyond the things that we were comfortable with. And I wanted to have deep conversations with those people. So I wanted to be able to share my insecurities or the politics that I was facing, or the anger that I was feeling, or not feeling seen or heard. I wanted to have deep, meaningful conversations with my true peers in a regular meeting setup that was confidential and fun. And I couldn't find that. +So I decided to host a few meetups. My first meetup was actually in Old Town, San Diego, at my buddy's restaurant. And I hosted the first 10 or 12 CTOs and realized that people had a real need for that kind of interaction. And I then ended up hosting 30 different meetings in three different cities. And everywhere I went, there was the same expression that people wanted what I wanted. +And then I tried to host a few more meaningful, smaller conversations and people...quite frankly, it was a disaster. I don't think it was the right container for people to respect each other and have empathy for each other's decisions. And instead, it just became a pissing contest for who made the right decision about what situation. And that's when I realized I'm not going to be able to create a meaningful conversation without some rules. And those rules I put in place, i.e., you must attend the meetings. You need to have some skin in the game. And that's how 7CTOs was born. +And to this day, it is a vetted peer group organization. We know we have some skin in the game. There's a membership fee. There's a time commitment. And there is a commitment to yourself to grow, to have empathy, to show up for your people, to be accountable to your people, to learn the stuff that you like to learn about and to learn the stuff that you don't want to learn about. And that is where we are today. So anybody who's listening to this who has a CTO who feels cold and lonely, come join us. +VICTORIA: I appreciate the hustle, that many meetups in that many cities. I would have gotten tired. [laughs] Like, that's too much. But it seems like there was a demand, and it created something that's really meaningful for people. +ETIENNE: Yes. And I was surprised. So from San Diego, I went to Austin. And then, I also started investing in Portland. And I was really amazed how we were in different cities, but each tech scene had this group of people called CTOs who they knew how to talk about technology, and they knew how to geek out of trends and all that. But they were lacking solely in team composition, budget management, C-suite executive presence, handling disagreements with the CEO, maybe knowing when to leave, how to find new positions, to carefully consider the arc of their own careers, to just manage your LinkedIn page. I mean, it was really shocking in the early 2010s how much of that was going on. +I will say I was reluctant to actually start something. You know, 7CTOs is very much a membership organization filled with people. Not the most intuitive move for me. I thought I would be building more and more and more tech companies, SaaS products. I do that as an interim or a fractional CTO now, but I don't have my own startup right now in the tech space. But I love 7CTOs. +We have a new CEO. Her name is Beth Rehberg. We have our head of coaching. Her name is Brittany Cotton. And we have about 200-plus companies that have enrolled their CTOs in our organization. And the journey is remarkable, truly a remarkable journey to see how people are just blossoming into the full essence and the full impact that they can have in other companies. +VICTORIA: That's wonderful. And I wonder, if you could go back in time and give yourself some advice back when you started it knowing what you know now, what advice would you tell yourself? +ETIENNE: I grossly underestimated how many White guys I would be attracting. I think about three or four years into the organization; it took someone else to bring it to my attention that there were no women. There were no underrepresented minorities in this group. And so I think from day one, I would have made that a key focal point for myself to really invest in the diversity of the group. +We've come a very long way. Our numbers are growing pretty quickly in terms of women joining us and people from various communities joining us. I think that's actually becoming a hallmark of 7CTOs. And I'm very proud of it today. But, boy, back in the day, I would have made that a key prime directive. +VICTORIA: Well, that's a really honest take, and I appreciate you offering that to us. And I think that's an important thing to focus on always going forward. [laughs] But I like that, and now it's become a focus for you and creating that space that, you know, hindsight is 2020. [laughs] Well, great. Is there anything else that you'd like to leave as a takeaway for our listeners? +ETIENNE: No. I think, of course, I would love some book purchases. Apparently, the first couple of weeks are vital for any new book. So please go over to Amazon and get "CTO Excellence." I also have a website: ctoexcellence.com. So really, anybody who has an inclination towards leadership in the tech space, I'm super passionate about those people. The opportunity to influence in a creative and confident way is just limitless. And I want to help unearth that for fledgling leaders, existing leaders, some leaders who might feel stuck. +Please reach out to me. I'd love to get you connected, either through 7CTOs or even I do some coaching as well. So I consider it my life's mission to expand this ecosystem because so many people are impacted by the way we show up. And there's a great opportunity as CTOs to be transformational in our organizations. And this is what I exist to do. +VICTORIA: Well, thank you so much for joining us today. And I really appreciate you sharing what you did, and I enjoyed our conversation. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Etienne de Bruin. + + + Etienne de Bruin is Founder of 7CTOs and Author of CTO Excellence in 100 Days.

+ +

Victoria talks to Etienne about his book, founding 7CTOs, and keeping your technology sustainable by inspiring and motivating technology teams and people to work together and build complex systems.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Etienne de Bruin, Founder of 7CTOs and Author of CTO Excellence in 100 Days. Etienne, thank you for joining me.

+ +

ETIENNE: My pleasure, Victoria. Thanks for having me.

+ +

VICTORIA: You're welcome. I'm excited to talk with you today. I hear that you recently published your book. Is it today actually the day it came out?

+ +

ETIENNE: Today is the day. The book was finished about; I would say, three months ago. So I have had great anticipation now for many, many months. And you caught me on the day, so I feel like today is my birthday.

+ +

VICTORIA: [laughs] Well, I feel honored that you chose us as your first stop [laughs] in your marketing push for your book. So tell me, what in your experience led you to begin writing this?

+ +

ETIENNE: Well, as you mentioned, I founded 7CTOs. I think it's about ten years ago now. I myself am a CTO type. I've had a career of basically being born to code in South Africa, which took me to Stellenbosch University in South Africa. I then joined a startup that took me to Germany and then landed in the U.S. in San Diego. And my whole journey has been a progression from individual contributor and really having great coding skills through the messiness and the intricacies of building startups, contributing to startups, and ultimately being in the role of CTO in startups.

+ +

And what led me to founding 7CTOs was just a realization that I didn't have the support I needed. I felt like I was going to many meetups, which was mostly oriented towards coding and sort of different new technology stacks and frameworks, or I was going to cocktail hours with vendors who were trying to sell you something. And I really felt the need to just be with my people so that I could, in a safe, and consistent, and accountable way, share the challenges that I was experiencing.

+ +

It was really from this place of founding 7CTOs, talking to hundreds of...I've probably spoken to thousands of CTOs by now. I've also placed people. I've connected people. I've seen people join companies because of connections I've made. And one of the things I saw that really bothered me was finding a great company in search of a CTO reaching out to me, talking to me about the role, me finding or through my network connecting them with a great CTO, only to find that a few months later either the relationship fizzles or even worse, the person did not succeed at the new company.

+ +

And I just felt like you can have two people, a great founder, and great CTO, individually wonderful people, ostensibly well-suited to work with each other, but then make some basic mistakes that then lead towards not the desired outcome. And so I was really torn whether I should put some thoughts into a book or into some blog posts about what I think the first 100 days should look like in a fledgling relationship. And that's ultimately how the book was born. So long, long, long, long answer, Victoria. But that's where it all started.

+ +

VICTORIA: No, that's great. I try to ask deep questions that get full answers back. [laughs]

+ +

ETIENNE: You nailed it.

+ +

VICTORIA: So I appreciate that context, yeah. So you talk about how to be successful in those first 100 days, which is critical to joining a new leadership team. What are some common mistakes that you mention that a CTO might make? And on the reverse side, what are some wins you could do early on to build trust?

+ +

ETIENNE: I think a common mistake that I see is a bit of an identity issue. The CTO joins an organization and is eager to deliver value, and I think that that value is oftentimes misplaced. And what I mean by that is you hit the ground running thinking that there's all this stuff that you have to deliver in order to prove that you can make an impact, to prove that you were the right choice. And I think there's an innate desire to impress your new employer, which I don't think is limited to the role of CTO. But I think for the CTO, this looks like some technical achievements and impact, problem-solving.

+ +

And I think what I like to see is the first 100 days being used to slow down a little bit, to listen, to be curious, to be open to building relationships, to have a longer view on what exactly is the system that you're joining. And I think to a fault; sometimes people will ignore the system they're joining and just start delivering value. And I think that that can often be misinterpreted or misunderstood. And then, if that is misunderstood in the first few months, then that really sets a tone for the rest of the tenure that I think puts the CTO on the back foot to deliver at a pace that maybe is unsustainable, so...

+ +

VICTORIA: I love that you said staying curious because I think what you can see is a tendency for, I don't know, what I've seen; maybe you've seen this too. [chuckle] But some people have a problem that they solved in a past situation, and they think that that is now the solution to every problem that they come into in a new organization, and maybe it is. But I think dealing in complex systems, having curiosity as to why decisions were made in a certain way can lead you to a better understanding of the business if that resonates with you at all.

+ +

ETIENNE: Yeah, I love that you said that. I'm a huge fan and student of complex systems. And so you just spoke my love language.

+ +

VICTORIA: [laughs]

+ +

ETIENNE: But that's exactly what happens. And I think that sometimes the debilitater of powerful and impactful people is the problem that you observe is maybe tainted by what you saw in the past. It might be a similar challenge, a similar problem. But what you solved in the past was part of a completely different system, different entities, different relationships.

+ +

And I think that by nature because the CTO is used to solving thousands and thousands of problems, there may be a bit of complacency around what is it exactly that I'm observing is the challenge here? Why exactly was I hired? What exactly does success look like for them, for the people that hired me, for the system that I've come into? And I think the tendency is to ignore all of those questions and focus on how do I feed my own need to feel valued and start solving problems in sort of a whack-a-mole style?

+ +

And I have found, even in my own experience, that there are some seriously unintended consequences that can arise from solving people's problems for them in ways that they are not used to, or they don't understand, or in some places just fully disagree with. And I think if you are not patient and take sort of 100 full days to just chill out and really enjoy learning about the system that you're joining, I think you're setting yourself up to fail or to at least be very unhappy.

+ +

VICTORIA: Right, setting yourself up for some fun conflicts [laughs] to solve if you come out right out the gate. And I think maybe, too, the first 100 days the chilling out and learning, you also have time to build empathy and build trust with people so that when you do bring up suggestions, they're maybe a little more willing to listen, right?

+ +

ETIENNE: Yes. And I think it's not uncommon to say, "Oh, well, I'm going to onboard myself. It's going to take some time before I show value." And I think there is a general sense that when the executive joins a company that, it's going to take some time. But I think that the temptation to jump into fiery situations is great, great in a bad way. It's a great temptation. And my book and my approach suggests that you take a step back and focus on a completely different area of the company, which is its people and its systems, and what success looks like for those people before you start jumping in and asserting your way of doing things.

+ +

VICTORIA: And you mentioned a question that I was going to ask, like, what does success look like? Or say you're a CEO, and you're trying to hire a CTO; what does success look like? What kind of value do you think people should expect from someone in a CTO role?

+ +

ETIENNE: Fundamentally, I think I might not be swimming in the mainstream on this topic. I don't believe that the CTO is a technical role first. I believe that the CTO is the Chief Technology Officer but is primarily a business role. And by that, I mean being a member of the C-suite, you are tasked, just like all the other members of the C-suite, to grow a company in a sustainable way. And whatever that middle letter is, is your domain and your expertise, and that's cool. But that T is surrounded by a C and an O, which in most cases has a fiduciary responsibility to the organization.

+ +

But also, first and foremost, you are a first-class member of the C-suite. And so my book talks about this, but you are there to join in with the executive leadership team and to help that team towards success. And so what that looks like for me is you are wrestling on what the targets are for the company. You participate fully in that. You then allocate a budget. In other words, you allocate cost towards how you can achieve those revenue goals. And then, with that budget as CTO, you then are budgeting towards a team that you believe can get the technology implemented that will ultimately produce the revenue. So think about revenue target, technology budget, technology people.

+ +

Now, these are all in the C-suite. These are just entries on a P&L. These are entries on the balance sheet. These are things that ultimately are abstracted towards company growth and company success. So with that, the CTO then turns into someone who wrestles with the tech teams, like, what are we going to implement? What ideas are consistent with our company principles and our vision? What does innovation look like? How do we inspire people to join our organization to do so? That, to me, is a fundamental role for the CTO, to inspire people to join the organization but also to be someone who implements and ideates on that journey.

+ +

So I think a CTO succeeds when there is revenue growth, and that is due to budget being spent in an effective way to attract amazing people to ultimately build technology that is sustainable that then feeds into tech revenue that ultimately helps the company achieve its goals.

+ +

VICTORIA: That's great. Yeah, I like that you said sustainable and the importance of people and how that relates to keeping your technology sustainable. And I'm curious if you could share more about what practices a CTO could bring to a new organization to facilitate that inspiration and to really motivate technology teams and people to work together and build these systems.

+ +

ETIENNE: I think that speaks to my earlier answer, which is the investment in people and investment in understanding the systems that exist. So whether you are a CTO, that is the first time a company ever scales and grows into having that role being created, which, you know, most tech startups these days will have the role of CTO allocated and available. The important thing to understand for you as someone stepping into that role is that your teams have a construct. They have an impression. They have an image, either of your predecessor at that company or their experiences with leadership and technology at their previous companies.

+ +

And I think it's extremely important to understand how you're being seen as a leader in the company and as CTO and that that vision of what people have of you is not necessarily based on your actions, your reputation, your good mornings in the mornings and your good evenings in the evenings. It really is based on people's constructs about what their experience has been of a CTO in their career, or like I said, the previous CTO, your predecessor.

+ +

And so I think that it's critical as you step into this role that you take the time to bring that change to show people your ways, to show people what is important to you in a way that's not a bull in a china shop. But when you break stuff, and you come in, and you announce your presence, and you assert the new way of doing things, I think that that is met with suspicion and concern most of the time.

+ +

And so I think if you can show people in the little things that you care about them, you're listening to them, you're curious about the system they're operating inside of, I think that that sets you up to then come in with the big ideas later on. But again, the emphasis being later on, past the 100 days. I talk about this in the book where introducing your tech strategy, introducing your way of doing things really comes a lot later in the 100 days than is maybe the preconceived notion.

+ +

VICTORIA: And you also mentioned a few times what the CTO should be doing and a lot of great questions that you ask, like, what does success look like? How do we build this together? And finding ways to maybe generate more ideas than just what you would come up with with your team, you're more powerful.

+ +

ETIENNE: Yes. And I think tag teaming on to that is a lot of times...and this is actually really a confounding thing that I've come across, which is the C-suite won't always understand what the role of CTO actually is. And teams won't always fully understand what the role of CTO is. When you talk about a CMO, or a CRO, or a CFO, I think you can generally understand what they're supposed to be doing. That isn't always clear for the CTO.

+ +

And it's amazing how many times I have gotten the question, well, we knew we needed someone to help us with the tech, but we don't really know what it is that you do, or what you should be doing, or what success looks like. I think not making the assumption that people know what you're there to do is a form of showing some respect and humility.

+ +

And this is why always when I'm in executive meetings, when I'm in stand-ups, or I'm in some sort of an architecture meeting, I will almost without fail I will say, "As the role of CTO, this is what I bring to the meeting," or "This is what the role of CTO would be looking for as an outcome of this conversation." Or "As the role of CTO, it is my job to ensure that our development capacity increases," to just never assume that people know what it is that you're there to do but to show them, I think, the respect and the courtesy that the role of CTO has a certain place in whatever meeting or brainstorm session is going on.

+ +

VICTORIA: I think that makes sense, too, because I could see, you know, especially you mentioned with people who maybe have had past experiences with CTOs that are not the most positive. If you bring up an idea in a meeting, everyone thinks, well, that's the solution. That's what the CTO wants. And it might not. Everyone might not feel comfortable, like, without you caveating; this is why I'm bringing this up. You know, we're here to brainstorm and not for me to just tell you what to do. [laughs]

+ +

ETIENNE: Yes, yes. And that's why I will often...honestly, this might be a real tip for people listening. But I will actively divorce who I am from the role that I'm in. And it enables me to have difficult conversations. It enables me to assert leadership without dominance. And that is to just say, "Hey, Sandra, in my role as CTO, this is what I am looking for in your growth or in your career path." Versus, "Hey, Sandra, I want you to..." or "I need you to..."

+ +

And I think the subtle difference there is to just assure someone that you're operating in a capacity that the company expects from you versus somehow having your identity wrapped in the outcome of a conversation. And that really has been a very powerful tool for me as I integrate into new companies or as I need to navigate tricky conversations.

+ +

VICTORIA: I appreciate you sharing that. I think hopefully that will be a great point for someone who's maybe struggling with something similar at this time. And maybe there are other common questions or themes that come up when you're talking to all these CTOs in organizations that you can share.

+ +

ETIENNE: By the way, if your name is Sandra and you're listening to this conversation, I totally made up the name Sandra, so I'm not referring to you, Sandra.

+ +

VICTORIA: [laughs]

+ +

ETIENNE: Okay. I think an interesting thing that I've noticed is given the stage of my company, have I addressed all the things that I need to by now? And I think that is such an indication of the times that we live in. Technology is always changing. Expectations are always changing. Clearly, if you're in a technology innovation company, things are rapidly changing. It's funny because some things just stay the same, i.e., people problems and all that.

+ +

But as far as technology landscape goes, I think that there is a little bit of a daunting feeling that, hey, I'm CTO in this company, but I don't know if I am where I need to be at compared to what other successful companies let's say, for instance, a series A company is doing. And as CTO, am I applying, am I showing up in the way that great CTOs of other series A companies are showing up? And so I would say that's problem number one is, am I operating at the level that I should be that my company is expecting of me? That's a real challenge that CTOs have.

+ +

And I think level-setting expectations communicating where we should be at is a skill that I think is missing from a lot of people who are in that role. And I think it's because we get to the roles of CTO by being people who rapidly solve problems or speedily deliver on technology. And we start associating speed with being good at our jobs, and I really think that that is wrong; that is just wrong. When you're in an executive role, patience and spending the extra day or the extra week fighting for the extra month, I think, is actually a very important role that the CTO plays in the C-suite.

+ +

And so if you have an underdeveloped sense of your own leadership style, an underdeveloped sense of your being and your essence and what it is you actually bring to the table, I think you end up just being sort of a knee-jerk tech person that just implements what other people want you to so that you could be valued for what it is that you do. Versus having that solid executive presence inside of a company that really influences and can shape the vision of the organization.

+ +

VICTORIA: Yeah, I think that's super interesting how common that question is. And I wonder if it gets to sometimes creating a shared understanding between the executive team about the technology and why certain things are important or not important. I wonder if you could talk about any maybe major trends that you see executive teams trying to take advantage of that are either positive or negative.

+ +

ETIENNE: The thing I've seen the most, which has had the greatest impact on, I think, executive teams, at least from my vantage point, is the desire to adopt some sort of business playbook or a business operating system. I think one of the most popular ones is the EOS model, Entrepreneurs Operating System. Gino Wickman, I think, wrote the book "Traction." And so it's caused a big trend with companies to try and streamline their operations by following the EOS model. And I do think that that might be the wrong solution to the right problem for many companies.

+ +

What I mean by that is, again, we're talking about blueprints. What works for one company isn't necessarily going to work for the next company. The way you set goals, the way you set your so-called rocks, or the way you set your quarterly goals, or even working by quarter if you think about a quarter, it's such an interesting...it's really a Wall Street concept. It's three months. It's really so arbitrary.

+ +

And I think that I see C-suites trying to adopt a business operating system that other companies are doing without really the necessary work being done as to, hey, what compels us through our culture, who we are, how we like to do things, what it is that works for us? And I will see some C-suites sort of spin their wheels a little bit on trying to adopt other systems when really all it takes is for them to do their own work to see what is the value stream? What does it look like inside of their company?

+ +

I actually encourage, and I think I talk about this in this book; in days 60 to 70, I talk about learning to improvise. And I think this is where I look to the CTO to use their spidey senses and their logical deduction skills, their deconstruction skills to observe what is actually happening inside of the C-suite and to facilitate conversations around what is it that people need? How do we improvise on systems that we already have? Or how do we deal with missed expectations? And I do think that the CTO can play a wonderful role inside of the C-suite to facilitate those conversations.

+ +

But I see inside of C-suites, the role of CTO being relegated to the IT person or just the tech person. And I think that victimization goes both ways. But the C-suite, where the CTO is actually facilitating hard conversations and able to do the decomposition of a complex system or the deconstruction of an often repeated problem or challenge that the company is experiencing, could really push the C-suite into a different track of thinking that could be super beneficial to unblocking some stodgy issues they've been facing.

+ +

VICTORIA: That makes sense. And it reminds me of trying to adopt agile right when it was first becoming popular and committing so hard to a framework that you don't look at what works for your team [laughs] and works for the specific technology and tools that you have. So it makes sense to me that the CTO could bring an experience like that into applying frameworks to how the business operates.

+ +

ETIENNE: Absolutely. And I think that's really when dogmatism could be your enemy. And, again, CTO joins a company, knows a certain set of skills in order to accomplish things, dogmatically tries to apply that because they are the so-called expert. And then they fail, or they're unhappy, or there's misunderstanding because we had these high expectations for you. Your interviewing was brilliant, and you said all the right things. But then, when you walked into the organization, your desire for acceptance and delivering value trumps your opportunity to be the new person and be curious about what is actually happening and what is actually going on.

+ +

This should be so obvious, but when you walk into a C-suite, there are obviously existing relationships between all the different members of the C-suite. And I advocate for being a student of those relationships. Understand the history that exists between the CEO and the CFO. And these could be very great newbie conversations to have with these various members of the C-suite. "Hey, so when did you join the company? Hey, why did you join the company? Hey, wait, which company did you come from? What drew you to this company? Where did you used to live? Why did you move?"

+ +

I think these are such incredible nodes in a complex relational hierarchy that can give you some very sound ideas as to, oh, well, why does the CEO constantly challenge what the COO is saying? Or why does the COO seem surpassed all the time? You, as CTO you, would do very well. I mean, as any C-suite member, any leader would do well to seek some insight and perception into what is going on for people.

+ +

VICTORIA: That makes sense, right? If you're going to have influence, you have to kind of understand what are all the connections and energy that's going around in the team?

+ +

ETIENNE: Absolutely.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: And maybe you can tell me more about 7CTOs and what that community can mean for someone who's growing in this role.

+ +

ETIENNE: 7CTOs, like I said earlier, I founded it...I almost said 100 days ago. I founded it ten years ago. And it was as I mentioned, the genesis of the story, which is important, is I co-founded a company with two people. I wrote the first lines of code for our product. In fact, I wrote the whole version 1 myself. And as the company grew and as the company grew beyond what it was that the three of us were comfortable with, I noticed that my CEO joined an organization a peer group organization. My COO joined a peer group organization. And I just saw this transformation in them that I really admired.

+ +

I was actually really envious when they were able to start taking what they've learned from their peer groups and bring them into our company to start operating more efficiently. And so, it was just natural that I would look for something for CTOs, and I couldn't find anything. I actually tried to join sort of more generic business leadership groups like Vestige or EO even. And I found that I wasn't really with my people. I wanted to feel like I was with the geeks who could talk all day about tech and development and probably watch the same movies and read the same books or inspired or laugh at the same jokes.

+ +

I wanted to find my people who were facing the same problems and challenges that I was, i.e., scaling companies beyond the things that we knew, beyond the things that we were comfortable with. And I wanted to have deep conversations with those people. So I wanted to be able to share my insecurities or the politics that I was facing, or the anger that I was feeling, or not feeling seen or heard. I wanted to have deep, meaningful conversations with my true peers in a regular meeting setup that was confidential and fun. And I couldn't find that.

+ +

So I decided to host a few meetups. My first meetup was actually in Old Town, San Diego, at my buddy's restaurant. And I hosted the first 10 or 12 CTOs and realized that people had a real need for that kind of interaction. And I then ended up hosting 30 different meetings in three different cities. And everywhere I went, there was the same expression that people wanted what I wanted.

+ +

And then I tried to host a few more meaningful, smaller conversations and people...quite frankly, it was a disaster. I don't think it was the right container for people to respect each other and have empathy for each other's decisions. And instead, it just became a pissing contest for who made the right decision about what situation. And that's when I realized I'm not going to be able to create a meaningful conversation without some rules. And those rules I put in place, i.e., you must attend the meetings. You need to have some skin in the game. And that's how 7CTOs was born.

+ +

And to this day, it is a vetted peer group organization. We know we have some skin in the game. There's a membership fee. There's a time commitment. And there is a commitment to yourself to grow, to have empathy, to show up for your people, to be accountable to your people, to learn the stuff that you like to learn about and to learn the stuff that you don't want to learn about. And that is where we are today. So anybody who's listening to this who has a CTO who feels cold and lonely, come join us.

+ +

VICTORIA: I appreciate the hustle, that many meetups in that many cities. I would have gotten tired. [laughs] Like, that's too much. But it seems like there was a demand, and it created something that's really meaningful for people.

+ +

ETIENNE: Yes. And I was surprised. So from San Diego, I went to Austin. And then, I also started investing in Portland. And I was really amazed how we were in different cities, but each tech scene had this group of people called CTOs who they knew how to talk about technology, and they knew how to geek out of trends and all that. But they were lacking solely in team composition, budget management, C-suite executive presence, handling disagreements with the CEO, maybe knowing when to leave, how to find new positions, to carefully consider the arc of their own careers, to just manage your LinkedIn page. I mean, it was really shocking in the early 2010s how much of that was going on.

+ +

I will say I was reluctant to actually start something. You know, 7CTOs is very much a membership organization filled with people. Not the most intuitive move for me. I thought I would be building more and more and more tech companies, SaaS products. I do that as an interim or a fractional CTO now, but I don't have my own startup right now in the tech space. But I love 7CTOs.

+ +

We have a new CEO. Her name is Beth Rehberg. We have our head of coaching. Her name is Brittany Cotton. And we have about 200-plus companies that have enrolled their CTOs in our organization. And the journey is remarkable, truly a remarkable journey to see how people are just blossoming into the full essence and the full impact that they can have in other companies.

+ +

VICTORIA: That's wonderful. And I wonder, if you could go back in time and give yourself some advice back when you started it knowing what you know now, what advice would you tell yourself?

+ +

ETIENNE: I grossly underestimated how many White guys I would be attracting. I think about three or four years into the organization; it took someone else to bring it to my attention that there were no women. There were no underrepresented minorities in this group. And so I think from day one, I would have made that a key focal point for myself to really invest in the diversity of the group.

+ +

We've come a very long way. Our numbers are growing pretty quickly in terms of women joining us and people from various communities joining us. I think that's actually becoming a hallmark of 7CTOs. And I'm very proud of it today. But, boy, back in the day, I would have made that a key prime directive.

+ +

VICTORIA: Well, that's a really honest take, and I appreciate you offering that to us. And I think that's an important thing to focus on always going forward. [laughs] But I like that, and now it's become a focus for you and creating that space that, you know, hindsight is 2020. [laughs] Well, great. Is there anything else that you'd like to leave as a takeaway for our listeners?

+ +

ETIENNE: No. I think, of course, I would love some book purchases. Apparently, the first couple of weeks are vital for any new book. So please go over to Amazon and get "CTO Excellence." I also have a website: ctoexcellence.com. So really, anybody who has an inclination towards leadership in the tech space, I'm super passionate about those people. The opportunity to influence in a creative and confident way is just limitless. And I want to help unearth that for fledgling leaders, existing leaders, some leaders who might feel stuck.

+ +

Please reach out to me. I'd love to get you connected, either through 7CTOs or even I do some coaching as well. So I consider it my life's mission to expand this ecosystem because so many people are impacted by the way we show up. And there's a great opportunity as CTOs to be transformational in our organizations. And this is what I exist to do.

+ +

VICTORIA: Well, thank you so much for joining us today. And I really appreciate you sharing what you did, and I enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Etienne de Bruin.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Etienne de Bruin is Founder of 7CTOs and Author of CTO Excellence in 100 Days.

+ +

Victoria talks to Etienne about his book, founding 7CTOs, and keeping your technology sustainable by inspiring and motivating technology teams and people to work together and build complex systems.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Etienne de Bruin, Founder of 7CTOs and Author of CTO Excellence in 100 Days. Etienne, thank you for joining me.

+ +

ETIENNE: My pleasure, Victoria. Thanks for having me.

+ +

VICTORIA: You're welcome. I'm excited to talk with you today. I hear that you recently published your book. Is it today actually the day it came out?

+ +

ETIENNE: Today is the day. The book was finished about; I would say, three months ago. So I have had great anticipation now for many, many months. And you caught me on the day, so I feel like today is my birthday.

+ +

VICTORIA: [laughs] Well, I feel honored that you chose us as your first stop [laughs] in your marketing push for your book. So tell me, what in your experience led you to begin writing this?

+ +

ETIENNE: Well, as you mentioned, I founded 7CTOs. I think it's about ten years ago now. I myself am a CTO type. I've had a career of basically being born to code in South Africa, which took me to Stellenbosch University in South Africa. I then joined a startup that took me to Germany and then landed in the U.S. in San Diego. And my whole journey has been a progression from individual contributor and really having great coding skills through the messiness and the intricacies of building startups, contributing to startups, and ultimately being in the role of CTO in startups.

+ +

And what led me to founding 7CTOs was just a realization that I didn't have the support I needed. I felt like I was going to many meetups, which was mostly oriented towards coding and sort of different new technology stacks and frameworks, or I was going to cocktail hours with vendors who were trying to sell you something. And I really felt the need to just be with my people so that I could, in a safe, and consistent, and accountable way, share the challenges that I was experiencing.

+ +

It was really from this place of founding 7CTOs, talking to hundreds of...I've probably spoken to thousands of CTOs by now. I've also placed people. I've connected people. I've seen people join companies because of connections I've made. And one of the things I saw that really bothered me was finding a great company in search of a CTO reaching out to me, talking to me about the role, me finding or through my network connecting them with a great CTO, only to find that a few months later either the relationship fizzles or even worse, the person did not succeed at the new company.

+ +

And I just felt like you can have two people, a great founder, and great CTO, individually wonderful people, ostensibly well-suited to work with each other, but then make some basic mistakes that then lead towards not the desired outcome. And so I was really torn whether I should put some thoughts into a book or into some blog posts about what I think the first 100 days should look like in a fledgling relationship. And that's ultimately how the book was born. So long, long, long, long answer, Victoria. But that's where it all started.

+ +

VICTORIA: No, that's great. I try to ask deep questions that get full answers back. [laughs]

+ +

ETIENNE: You nailed it.

+ +

VICTORIA: So I appreciate that context, yeah. So you talk about how to be successful in those first 100 days, which is critical to joining a new leadership team. What are some common mistakes that you mention that a CTO might make? And on the reverse side, what are some wins you could do early on to build trust?

+ +

ETIENNE: I think a common mistake that I see is a bit of an identity issue. The CTO joins an organization and is eager to deliver value, and I think that that value is oftentimes misplaced. And what I mean by that is you hit the ground running thinking that there's all this stuff that you have to deliver in order to prove that you can make an impact, to prove that you were the right choice. And I think there's an innate desire to impress your new employer, which I don't think is limited to the role of CTO. But I think for the CTO, this looks like some technical achievements and impact, problem-solving.

+ +

And I think what I like to see is the first 100 days being used to slow down a little bit, to listen, to be curious, to be open to building relationships, to have a longer view on what exactly is the system that you're joining. And I think to a fault; sometimes people will ignore the system they're joining and just start delivering value. And I think that that can often be misinterpreted or misunderstood. And then, if that is misunderstood in the first few months, then that really sets a tone for the rest of the tenure that I think puts the CTO on the back foot to deliver at a pace that maybe is unsustainable, so...

+ +

VICTORIA: I love that you said staying curious because I think what you can see is a tendency for, I don't know, what I've seen; maybe you've seen this too. [chuckle] But some people have a problem that they solved in a past situation, and they think that that is now the solution to every problem that they come into in a new organization, and maybe it is. But I think dealing in complex systems, having curiosity as to why decisions were made in a certain way can lead you to a better understanding of the business if that resonates with you at all.

+ +

ETIENNE: Yeah, I love that you said that. I'm a huge fan and student of complex systems. And so you just spoke my love language.

+ +

VICTORIA: [laughs]

+ +

ETIENNE: But that's exactly what happens. And I think that sometimes the debilitater of powerful and impactful people is the problem that you observe is maybe tainted by what you saw in the past. It might be a similar challenge, a similar problem. But what you solved in the past was part of a completely different system, different entities, different relationships.

+ +

And I think that by nature because the CTO is used to solving thousands and thousands of problems, there may be a bit of complacency around what is it exactly that I'm observing is the challenge here? Why exactly was I hired? What exactly does success look like for them, for the people that hired me, for the system that I've come into? And I think the tendency is to ignore all of those questions and focus on how do I feed my own need to feel valued and start solving problems in sort of a whack-a-mole style?

+ +

And I have found, even in my own experience, that there are some seriously unintended consequences that can arise from solving people's problems for them in ways that they are not used to, or they don't understand, or in some places just fully disagree with. And I think if you are not patient and take sort of 100 full days to just chill out and really enjoy learning about the system that you're joining, I think you're setting yourself up to fail or to at least be very unhappy.

+ +

VICTORIA: Right, setting yourself up for some fun conflicts [laughs] to solve if you come out right out the gate. And I think maybe, too, the first 100 days the chilling out and learning, you also have time to build empathy and build trust with people so that when you do bring up suggestions, they're maybe a little more willing to listen, right?

+ +

ETIENNE: Yes. And I think it's not uncommon to say, "Oh, well, I'm going to onboard myself. It's going to take some time before I show value." And I think there is a general sense that when the executive joins a company that, it's going to take some time. But I think that the temptation to jump into fiery situations is great, great in a bad way. It's a great temptation. And my book and my approach suggests that you take a step back and focus on a completely different area of the company, which is its people and its systems, and what success looks like for those people before you start jumping in and asserting your way of doing things.

+ +

VICTORIA: And you mentioned a question that I was going to ask, like, what does success look like? Or say you're a CEO, and you're trying to hire a CTO; what does success look like? What kind of value do you think people should expect from someone in a CTO role?

+ +

ETIENNE: Fundamentally, I think I might not be swimming in the mainstream on this topic. I don't believe that the CTO is a technical role first. I believe that the CTO is the Chief Technology Officer but is primarily a business role. And by that, I mean being a member of the C-suite, you are tasked, just like all the other members of the C-suite, to grow a company in a sustainable way. And whatever that middle letter is, is your domain and your expertise, and that's cool. But that T is surrounded by a C and an O, which in most cases has a fiduciary responsibility to the organization.

+ +

But also, first and foremost, you are a first-class member of the C-suite. And so my book talks about this, but you are there to join in with the executive leadership team and to help that team towards success. And so what that looks like for me is you are wrestling on what the targets are for the company. You participate fully in that. You then allocate a budget. In other words, you allocate cost towards how you can achieve those revenue goals. And then, with that budget as CTO, you then are budgeting towards a team that you believe can get the technology implemented that will ultimately produce the revenue. So think about revenue target, technology budget, technology people.

+ +

Now, these are all in the C-suite. These are just entries on a P&L. These are entries on the balance sheet. These are things that ultimately are abstracted towards company growth and company success. So with that, the CTO then turns into someone who wrestles with the tech teams, like, what are we going to implement? What ideas are consistent with our company principles and our vision? What does innovation look like? How do we inspire people to join our organization to do so? That, to me, is a fundamental role for the CTO, to inspire people to join the organization but also to be someone who implements and ideates on that journey.

+ +

So I think a CTO succeeds when there is revenue growth, and that is due to budget being spent in an effective way to attract amazing people to ultimately build technology that is sustainable that then feeds into tech revenue that ultimately helps the company achieve its goals.

+ +

VICTORIA: That's great. Yeah, I like that you said sustainable and the importance of people and how that relates to keeping your technology sustainable. And I'm curious if you could share more about what practices a CTO could bring to a new organization to facilitate that inspiration and to really motivate technology teams and people to work together and build these systems.

+ +

ETIENNE: I think that speaks to my earlier answer, which is the investment in people and investment in understanding the systems that exist. So whether you are a CTO, that is the first time a company ever scales and grows into having that role being created, which, you know, most tech startups these days will have the role of CTO allocated and available. The important thing to understand for you as someone stepping into that role is that your teams have a construct. They have an impression. They have an image, either of your predecessor at that company or their experiences with leadership and technology at their previous companies.

+ +

And I think it's extremely important to understand how you're being seen as a leader in the company and as CTO and that that vision of what people have of you is not necessarily based on your actions, your reputation, your good mornings in the mornings and your good evenings in the evenings. It really is based on people's constructs about what their experience has been of a CTO in their career, or like I said, the previous CTO, your predecessor.

+ +

And so I think that it's critical as you step into this role that you take the time to bring that change to show people your ways, to show people what is important to you in a way that's not a bull in a china shop. But when you break stuff, and you come in, and you announce your presence, and you assert the new way of doing things, I think that that is met with suspicion and concern most of the time.

+ +

And so I think if you can show people in the little things that you care about them, you're listening to them, you're curious about the system they're operating inside of, I think that that sets you up to then come in with the big ideas later on. But again, the emphasis being later on, past the 100 days. I talk about this in the book where introducing your tech strategy, introducing your way of doing things really comes a lot later in the 100 days than is maybe the preconceived notion.

+ +

VICTORIA: And you also mentioned a few times what the CTO should be doing and a lot of great questions that you ask, like, what does success look like? How do we build this together? And finding ways to maybe generate more ideas than just what you would come up with with your team, you're more powerful.

+ +

ETIENNE: Yes. And I think tag teaming on to that is a lot of times...and this is actually really a confounding thing that I've come across, which is the C-suite won't always understand what the role of CTO actually is. And teams won't always fully understand what the role of CTO is. When you talk about a CMO, or a CRO, or a CFO, I think you can generally understand what they're supposed to be doing. That isn't always clear for the CTO.

+ +

And it's amazing how many times I have gotten the question, well, we knew we needed someone to help us with the tech, but we don't really know what it is that you do, or what you should be doing, or what success looks like. I think not making the assumption that people know what you're there to do is a form of showing some respect and humility.

+ +

And this is why always when I'm in executive meetings, when I'm in stand-ups, or I'm in some sort of an architecture meeting, I will almost without fail I will say, "As the role of CTO, this is what I bring to the meeting," or "This is what the role of CTO would be looking for as an outcome of this conversation." Or "As the role of CTO, it is my job to ensure that our development capacity increases," to just never assume that people know what it is that you're there to do but to show them, I think, the respect and the courtesy that the role of CTO has a certain place in whatever meeting or brainstorm session is going on.

+ +

VICTORIA: I think that makes sense, too, because I could see, you know, especially you mentioned with people who maybe have had past experiences with CTOs that are not the most positive. If you bring up an idea in a meeting, everyone thinks, well, that's the solution. That's what the CTO wants. And it might not. Everyone might not feel comfortable, like, without you caveating; this is why I'm bringing this up. You know, we're here to brainstorm and not for me to just tell you what to do. [laughs]

+ +

ETIENNE: Yes, yes. And that's why I will often...honestly, this might be a real tip for people listening. But I will actively divorce who I am from the role that I'm in. And it enables me to have difficult conversations. It enables me to assert leadership without dominance. And that is to just say, "Hey, Sandra, in my role as CTO, this is what I am looking for in your growth or in your career path." Versus, "Hey, Sandra, I want you to..." or "I need you to..."

+ +

And I think the subtle difference there is to just assure someone that you're operating in a capacity that the company expects from you versus somehow having your identity wrapped in the outcome of a conversation. And that really has been a very powerful tool for me as I integrate into new companies or as I need to navigate tricky conversations.

+ +

VICTORIA: I appreciate you sharing that. I think hopefully that will be a great point for someone who's maybe struggling with something similar at this time. And maybe there are other common questions or themes that come up when you're talking to all these CTOs in organizations that you can share.

+ +

ETIENNE: By the way, if your name is Sandra and you're listening to this conversation, I totally made up the name Sandra, so I'm not referring to you, Sandra.

+ +

VICTORIA: [laughs]

+ +

ETIENNE: Okay. I think an interesting thing that I've noticed is given the stage of my company, have I addressed all the things that I need to by now? And I think that is such an indication of the times that we live in. Technology is always changing. Expectations are always changing. Clearly, if you're in a technology innovation company, things are rapidly changing. It's funny because some things just stay the same, i.e., people problems and all that.

+ +

But as far as technology landscape goes, I think that there is a little bit of a daunting feeling that, hey, I'm CTO in this company, but I don't know if I am where I need to be at compared to what other successful companies let's say, for instance, a series A company is doing. And as CTO, am I applying, am I showing up in the way that great CTOs of other series A companies are showing up? And so I would say that's problem number one is, am I operating at the level that I should be that my company is expecting of me? That's a real challenge that CTOs have.

+ +

And I think level-setting expectations communicating where we should be at is a skill that I think is missing from a lot of people who are in that role. And I think it's because we get to the roles of CTO by being people who rapidly solve problems or speedily deliver on technology. And we start associating speed with being good at our jobs, and I really think that that is wrong; that is just wrong. When you're in an executive role, patience and spending the extra day or the extra week fighting for the extra month, I think, is actually a very important role that the CTO plays in the C-suite.

+ +

And so if you have an underdeveloped sense of your own leadership style, an underdeveloped sense of your being and your essence and what it is you actually bring to the table, I think you end up just being sort of a knee-jerk tech person that just implements what other people want you to so that you could be valued for what it is that you do. Versus having that solid executive presence inside of a company that really influences and can shape the vision of the organization.

+ +

VICTORIA: Yeah, I think that's super interesting how common that question is. And I wonder if it gets to sometimes creating a shared understanding between the executive team about the technology and why certain things are important or not important. I wonder if you could talk about any maybe major trends that you see executive teams trying to take advantage of that are either positive or negative.

+ +

ETIENNE: The thing I've seen the most, which has had the greatest impact on, I think, executive teams, at least from my vantage point, is the desire to adopt some sort of business playbook or a business operating system. I think one of the most popular ones is the EOS model, Entrepreneurs Operating System. Gino Wickman, I think, wrote the book "Traction." And so it's caused a big trend with companies to try and streamline their operations by following the EOS model. And I do think that that might be the wrong solution to the right problem for many companies.

+ +

What I mean by that is, again, we're talking about blueprints. What works for one company isn't necessarily going to work for the next company. The way you set goals, the way you set your so-called rocks, or the way you set your quarterly goals, or even working by quarter if you think about a quarter, it's such an interesting...it's really a Wall Street concept. It's three months. It's really so arbitrary.

+ +

And I think that I see C-suites trying to adopt a business operating system that other companies are doing without really the necessary work being done as to, hey, what compels us through our culture, who we are, how we like to do things, what it is that works for us? And I will see some C-suites sort of spin their wheels a little bit on trying to adopt other systems when really all it takes is for them to do their own work to see what is the value stream? What does it look like inside of their company?

+ +

I actually encourage, and I think I talk about this in this book; in days 60 to 70, I talk about learning to improvise. And I think this is where I look to the CTO to use their spidey senses and their logical deduction skills, their deconstruction skills to observe what is actually happening inside of the C-suite and to facilitate conversations around what is it that people need? How do we improvise on systems that we already have? Or how do we deal with missed expectations? And I do think that the CTO can play a wonderful role inside of the C-suite to facilitate those conversations.

+ +

But I see inside of C-suites, the role of CTO being relegated to the IT person or just the tech person. And I think that victimization goes both ways. But the C-suite, where the CTO is actually facilitating hard conversations and able to do the decomposition of a complex system or the deconstruction of an often repeated problem or challenge that the company is experiencing, could really push the C-suite into a different track of thinking that could be super beneficial to unblocking some stodgy issues they've been facing.

+ +

VICTORIA: That makes sense. And it reminds me of trying to adopt agile right when it was first becoming popular and committing so hard to a framework that you don't look at what works for your team [laughs] and works for the specific technology and tools that you have. So it makes sense to me that the CTO could bring an experience like that into applying frameworks to how the business operates.

+ +

ETIENNE: Absolutely. And I think that's really when dogmatism could be your enemy. And, again, CTO joins a company, knows a certain set of skills in order to accomplish things, dogmatically tries to apply that because they are the so-called expert. And then they fail, or they're unhappy, or there's misunderstanding because we had these high expectations for you. Your interviewing was brilliant, and you said all the right things. But then, when you walked into the organization, your desire for acceptance and delivering value trumps your opportunity to be the new person and be curious about what is actually happening and what is actually going on.

+ +

This should be so obvious, but when you walk into a C-suite, there are obviously existing relationships between all the different members of the C-suite. And I advocate for being a student of those relationships. Understand the history that exists between the CEO and the CFO. And these could be very great newbie conversations to have with these various members of the C-suite. "Hey, so when did you join the company? Hey, why did you join the company? Hey, wait, which company did you come from? What drew you to this company? Where did you used to live? Why did you move?"

+ +

I think these are such incredible nodes in a complex relational hierarchy that can give you some very sound ideas as to, oh, well, why does the CEO constantly challenge what the COO is saying? Or why does the COO seem surpassed all the time? You, as CTO you, would do very well. I mean, as any C-suite member, any leader would do well to seek some insight and perception into what is going on for people.

+ +

VICTORIA: That makes sense, right? If you're going to have influence, you have to kind of understand what are all the connections and energy that's going around in the team?

+ +

ETIENNE: Absolutely.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: And maybe you can tell me more about 7CTOs and what that community can mean for someone who's growing in this role.

+ +

ETIENNE: 7CTOs, like I said earlier, I founded it...I almost said 100 days ago. I founded it ten years ago. And it was as I mentioned, the genesis of the story, which is important, is I co-founded a company with two people. I wrote the first lines of code for our product. In fact, I wrote the whole version 1 myself. And as the company grew and as the company grew beyond what it was that the three of us were comfortable with, I noticed that my CEO joined an organization a peer group organization. My COO joined a peer group organization. And I just saw this transformation in them that I really admired.

+ +

I was actually really envious when they were able to start taking what they've learned from their peer groups and bring them into our company to start operating more efficiently. And so, it was just natural that I would look for something for CTOs, and I couldn't find anything. I actually tried to join sort of more generic business leadership groups like Vestige or EO even. And I found that I wasn't really with my people. I wanted to feel like I was with the geeks who could talk all day about tech and development and probably watch the same movies and read the same books or inspired or laugh at the same jokes.

+ +

I wanted to find my people who were facing the same problems and challenges that I was, i.e., scaling companies beyond the things that we knew, beyond the things that we were comfortable with. And I wanted to have deep conversations with those people. So I wanted to be able to share my insecurities or the politics that I was facing, or the anger that I was feeling, or not feeling seen or heard. I wanted to have deep, meaningful conversations with my true peers in a regular meeting setup that was confidential and fun. And I couldn't find that.

+ +

So I decided to host a few meetups. My first meetup was actually in Old Town, San Diego, at my buddy's restaurant. And I hosted the first 10 or 12 CTOs and realized that people had a real need for that kind of interaction. And I then ended up hosting 30 different meetings in three different cities. And everywhere I went, there was the same expression that people wanted what I wanted.

+ +

And then I tried to host a few more meaningful, smaller conversations and people...quite frankly, it was a disaster. I don't think it was the right container for people to respect each other and have empathy for each other's decisions. And instead, it just became a pissing contest for who made the right decision about what situation. And that's when I realized I'm not going to be able to create a meaningful conversation without some rules. And those rules I put in place, i.e., you must attend the meetings. You need to have some skin in the game. And that's how 7CTOs was born.

+ +

And to this day, it is a vetted peer group organization. We know we have some skin in the game. There's a membership fee. There's a time commitment. And there is a commitment to yourself to grow, to have empathy, to show up for your people, to be accountable to your people, to learn the stuff that you like to learn about and to learn the stuff that you don't want to learn about. And that is where we are today. So anybody who's listening to this who has a CTO who feels cold and lonely, come join us.

+ +

VICTORIA: I appreciate the hustle, that many meetups in that many cities. I would have gotten tired. [laughs] Like, that's too much. But it seems like there was a demand, and it created something that's really meaningful for people.

+ +

ETIENNE: Yes. And I was surprised. So from San Diego, I went to Austin. And then, I also started investing in Portland. And I was really amazed how we were in different cities, but each tech scene had this group of people called CTOs who they knew how to talk about technology, and they knew how to geek out of trends and all that. But they were lacking solely in team composition, budget management, C-suite executive presence, handling disagreements with the CEO, maybe knowing when to leave, how to find new positions, to carefully consider the arc of their own careers, to just manage your LinkedIn page. I mean, it was really shocking in the early 2010s how much of that was going on.

+ +

I will say I was reluctant to actually start something. You know, 7CTOs is very much a membership organization filled with people. Not the most intuitive move for me. I thought I would be building more and more and more tech companies, SaaS products. I do that as an interim or a fractional CTO now, but I don't have my own startup right now in the tech space. But I love 7CTOs.

+ +

We have a new CEO. Her name is Beth Rehberg. We have our head of coaching. Her name is Brittany Cotton. And we have about 200-plus companies that have enrolled their CTOs in our organization. And the journey is remarkable, truly a remarkable journey to see how people are just blossoming into the full essence and the full impact that they can have in other companies.

+ +

VICTORIA: That's wonderful. And I wonder, if you could go back in time and give yourself some advice back when you started it knowing what you know now, what advice would you tell yourself?

+ +

ETIENNE: I grossly underestimated how many White guys I would be attracting. I think about three or four years into the organization; it took someone else to bring it to my attention that there were no women. There were no underrepresented minorities in this group. And so I think from day one, I would have made that a key focal point for myself to really invest in the diversity of the group.

+ +

We've come a very long way. Our numbers are growing pretty quickly in terms of women joining us and people from various communities joining us. I think that's actually becoming a hallmark of 7CTOs. And I'm very proud of it today. But, boy, back in the day, I would have made that a key prime directive.

+ +

VICTORIA: Well, that's a really honest take, and I appreciate you offering that to us. And I think that's an important thing to focus on always going forward. [laughs] But I like that, and now it's become a focus for you and creating that space that, you know, hindsight is 2020. [laughs] Well, great. Is there anything else that you'd like to leave as a takeaway for our listeners?

+ +

ETIENNE: No. I think, of course, I would love some book purchases. Apparently, the first couple of weeks are vital for any new book. So please go over to Amazon and get "CTO Excellence." I also have a website: ctoexcellence.com. So really, anybody who has an inclination towards leadership in the tech space, I'm super passionate about those people. The opportunity to influence in a creative and confident way is just limitless. And I want to help unearth that for fledgling leaders, existing leaders, some leaders who might feel stuck.

+ +

Please reach out to me. I'd love to get you connected, either through 7CTOs or even I do some coaching as well. So I consider it my life's mission to expand this ecosystem because so many people are impacted by the way we show up. And there's a great opportunity as CTOs to be transformational in our organizations. And this is what I exist to do.

+ +

VICTORIA: Well, thank you so much for joining us today. And I really appreciate you sharing what you did, and I enjoyed our conversation.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Etienne de Bruin.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+6PimFcyW + + ]]> + + Victoria Guido + Etienne de Bruin + + + 469: Harpoon with Dominic Holt + https://podcast.thoughtbot.com/469 + 9bda7e9b-718d-4cbc-9d2e-3d13bb33b50f + Thu, 06 Apr 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Dominic Holt is CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds. + +Victoria talks to Dominic about commoditizing DevOps as a capability, coming up with the idea for drag and drop just thinking through how he could do these things in a visual and intuitive way, and using Kubernetes as a base for Harpoon. + 46:26 + no + + + Dominic Holt is CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds. +Victoria talks to Dominic about commoditizing DevOps as a capability, coming up with the idea for drag and drop just thinking through how he could do these things in a visual and intuitive way, and using Kubernetes as a base for Harpoon. +Harpoon (https://www.harpoon.io/) +Follow Harpoon on Facebook (https://www.facebook.com/harpothewhale/), or LinkedIn (https://www.linkedin.com/company/harpooncorp/). +Follow Dominic Holt on LinkedIn (https://www.linkedin.com/in/dominicholt/) or Twitter (https://twitter.com/xReapz). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dominic Holt, CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds. Dominic, thank you for joining me. +DOMINIC: Yeah, of course. Thanks for having me, Victoria. +VICTORIA: Yes, I'm really excited to talk all about what Kubernetes is. And I have Joe Ferris, the CTO of thoughtbot, here with me as well to help me in that process. +JOE: Hello. +VICTORIA: Excellent. Okay, so, Dominic, why don't you just tell me how it all got started? What led you to start harpoon? +DOMINIC: I got into the DevOps space fairly early. It was, I don't know, probably 2012 timeframe, which sounds like not that long ago. But, I mean, DevOps is also still a baby. So I have a software background. And I was starting to figure out how to do the continuous; I guess, automated way of standing up cloud infrastructure for Lockheed Martin at the time because people didn't know how to do that. There weren't a lot of tools available, and nobody knew what DevOps was. And if you said it to somebody, they would have slapped you. +VICTORIA: Aggressive. [laughs] +DOMINIC: [laughs] Maybe not, maybe not. Maybe they'd be nicer about it. But anyway, nobody knew what DevOps was because it wasn't coined yet. And I started realizing that this was not some system administration voodoo. It was just common sense from a software development standpoint. And I ended up leaving Lockheed shortly thereafter and going and working for a small business here in San Diego. And I said, I have no idea what any of this stuff is, but we're going to do it because, in a few years, everybody's going to be doing it because it's common sense. So we did. +We grew quite a large practice in consulting and DevOps, among other things. And predominantly, I was working with the U.S. Navy at the time, and they needed a standardized way to deploy software to aircraft carriers and destroyers, the ships out there in the ocean. And so, I came up with a design for them that used Kubernetes. And we built a pipeline, a CI/CD pipeline, to automatically deploy software from the cloud to Navy ships out in the ocean on top of Kubernetes. And everything worked great. And it was there, and we tested it. +But at the end of the day, handing over the maintenance, what we call day two ops, proved to be troubling. And it never quite made it onto the ships in the way that we wanted. So after that, I did a bunch of consulting with other groups in the Navy, and the Air Force, and Space Force, and all kinds of different groups across the government. And I also started consulting in commercial, fortune 500, startups, everything. +And I just saw that this problem was really pervasive, handling the day two operations. You get everything up and running, but then maintaining it after that was just complicated for people because all of the DevOps implementations are snowflakes. So if you go from Company A to Company B, they look nothing alike. And they may have a lot to do with somebody named Jim or Frank or Bob and how they thought was the best way to do it. +And so, running a DevOps consultancy myself, I just knew how hard it was to find the talent, and how expensive they were, and how hard it was to keep them because everyone else was trying to hire my talent all the time. And I just thought to myself, all of this is completely untenable. Somebody is going to commoditize DevOps as a capability. And what would that look like? +VICTORIA: Right. I'm familiar with the demand for people who know how to build the infrastructure and systems for deploying and running software. [laughs] And I like how you first talked about DevOps, just it being common sense. And I remember feeling that way when I went to my first DevOps DC meetup. I was like, oh, this is how you're supposed to build teams and organizations in a way to run things efficiently and apply those principles from building software to managing your infrastructure. +DOMINIC: Yeah. Well, I had lived the life of an enterprise software developer for quite a while before then. And I had gone through that whole process they talk about in all of DevOps bibles about why it is we're doing this, where the software development team would have their nice, fancy dev laptops. And the operations team with the pagers or whatever would be the ones managing the servers. And the software developers were never really sure exactly how it was going to work in production, but were like; I'm just going to throw it over the fence and see what the ops people do. +And inevitably, the ops people would call us very angrily, and they would say, "Your software doesn't work." And then, of course, we would say that the ops people are all crazy because it works just fine here on my laptop, and they just don't know what they're doing. And, I mean, we would just fight back and forth about this for six months until somebody figured out that we were running the wrong version of some dependency in the software on the ops side, and that's why it didn't work. So that process is just crazy, and nobody in their right mind would want to go through it if they could avoid it. +VICTORIA: Right. I'm sure Joe has had some stories from his time at thoughtbot. +JOE: Yeah, certainly. I was interested by what you said about working with...I think it was Frank, and Ted, and Bob. I've definitely worked with all those people in their own snowflakes. And one of the things that drew me to Kubernetes is that it was an attempt to standardize at least some of the approaches or at least provide anchor points for things like how you might implement networking, and routing, and so on. +I'm interested to hear, you know, for a drag-and-drop solution, even though Kubernetes was meant to standardize a lot of things, there are a lot of different Kubernetes distributions. And I think there are still a lot of Kubernetes snowflakes. I'm curious how you manage to tackle that problem with a drag-and-drop solution to hit the different Kubernetes distributions out there. +DOMINIC: Yeah, I mean, I think you nailed it, Joe. Standing up Kubernetes is a little bit complicated still these days. It's been made a lot easier by a lot of different companies, and products, and open-source software, and things like that. And so I see a lot of people getting up basic Kubernetes clusters these days. But then you look at companies like ARMO that are doing compliance scans and security scans on Kubernetes clusters, and they're making the claim that 100% of the Kubernetes clusters they scan are non-compliant [laughs] and have security issues. +And so that just goes to show you all of the things that one has to know to be successful just to stand up a cluster in the first place. And even when I...like for a client or something, over the years, if I was standing up a Kubernetes cluster and a lot of it was automated, you know, we used Terraform and Ansible, and all the other best practices under the hood. A lot of the response I got back when we handed over a cluster to a client was, "Okay, now what?" +There are still a lot of things you have to learn to maintain that cluster, keep it up to date, upgrade the underlying components of the cluster, deploy the software, configure the software, all those things. And can you learn these things? Absolutely. Like, they're not rocket science, but they're complicated. And it is a commitment that you have to make as an individual if you're going to become proficient in all of these things and managing your own cluster. +And so we were just...we had done this so many times at different companies I had worked with, for different clients, and seeing how all of the different pieces work together and where clients were having problems and what really hung people up. And so I just started thinking to myself, how would you make that easier? How would you make that more available to the pizza guy or an 18-year-old with no formal training that's on a ship in the ocean? And that's why I came up with the idea for drag and drop, just thinking through how can I do these things in a visual way that is going to be intuitive for people? +VICTORIA: Well, I have, obviously, a very thorough understanding of Kubernetes, [laughs] just kidding. But maybe explain a little bit more about to a founder why should they invest in this type of approach when they're building products? +DOMINIC: So I think that's a great question. What I find these days is DevOps is almost a requirement to do business these days in some sort of nimble way. So you have to...whether you're a large enterprise or you're a garage startup, you need to be able to change your software to market forces, to stuff that's happening in the news, to your customers don't like something. So you want to change it to something else quickly or pivot because if something happens, you can get your day in the sun, or you can capitalize on something that's happening. +And so the difficulty is I think a lot of people have an impression that DevOps scripts are sort of like a build once and forget type of thing, and it'll just work thereafter. But it's actually software, and I like to think of software as living organisms. You have to take care of them like they're people, almost because if you don't, they'll become brittle and unhealthy over time. If you have a child, you have to feed them probably multiple times a day, brush their teeth. You got to tuck them in at night. You have to be nice to them. You have to do all the things that you would do with a child. +But with software as well, if you just take the quick route, and quick fix things, and hack, and take shortcuts, eventually, you're going to have a very unhealthy child on your hands, and they're going to have behavior problems. At the end of the day, you have all these DevOps scripts, and they can be quite complex together. And you have to take care of them like they're your own child. +And the problem is you're also taking care of your software products like it's your child. And so now you're taking care of two children. And as somebody that has two children, I can tell you that things become much more complicated when two children are having behavioral problems than just one. And you're at the store, and it's very embarrassing. +So I guess the point is that harpoon is a capability that can basically take care of your second child for you, which is your DevOps deployments. And then you can just focus on the one child that you, I mean, this is turning into a terrible analogy at this point. [laughter] But you should love all of your children equally. But, in this case, you're looking to take care of your products and get it out there, and harpoon is something that can take care of your DevOps software for you. +VICTORIA: I agree. I think when your software or children are problematic, it's more than just embarrassing sometimes. It can create a lot of financial and legal liability as well. From your research, when you're building this product and, like, who's going to be interested in buying this thing, is that something that people are concerned about? +DOMINIC: Yeah, absolutely. I mean, the fact that we can stand up your cluster for you, stand up all of your cloud infrastructure for you, and then dynamically generate all of the configuration as code as well, and how to open those things securely up to the network and control everything such that you're not going to accidentally do something that's really bad, can definitely help out a lot of people. +The interest has been really overwhelming from so many different groups and organizations. We have people that are interested in the Department of Defense in both the U.S. and other countries. We have fortune 500 companies that see this as a pathway to accelerate digital transformation for legacy applications or even to use it as a sandbox, so people aren't bugging Frank, and Joe, and Bob, who run the Kubernetes clusters in production. +We have startups who see it just as a way to skip over the whole DevOps thing and work on getting a product-market fit so that they have a production environment that just works out of the box. So it's been really interesting seeing all the different use cases people are using harpoon for and how it's helped them in some way get to some and realize some goal that they have. +JOE: I'm curious if it's been a challenge as somebody managing the underlying infrastructure as sort of a plug-and-play thing. One experience I've had working more on the operations side of DevOps is that everything becomes your problem. Like, if the server misbehaves, if there's a database crash, whatever, certainly, that's your problem. But also, if the application is murdering your database, that becomes your problem. And it's really an application problem. But it surfaces visibly in the infrastructure when the CPU spikes and it stops responding to requests. And so, how do you navigate that agreement with your users? How do you balance what's your responsibility versus theirs to not kill the cluster? +DOMINIC: One thing that's great about Kubernetes and why it's a great base for our product is that Kubernetes is really good at keeping things running. Certainly, there are catastrophic things that can happen, like an entire region of EC2 and Amazon Web Services goes down. And that is, obviously, if you have your clusters only running in that particular region, you're going to have a bad day. +So there are things beyond our control. I mean, those things are also covered by the service-level agreement, the SLA with AWS, since you're using your own AWS account when you're utilizing harpoon. So it's like a hybrid SaaS where we deploy everything into your account, and you own it. And you can adjust those infrastructure things on your own as you'd like. So from that standpoint, you're kind of covered with your agreement with AWS as an example of a cloud service provider. +And certainly, Kubernetes also kind of knows what to do in some of those instances where you have a container that is murdering everything. In a lot of cases, it can be configured to, you know, just die or go into a CrashLoopBackOff or something if it's just taking up all your resources in the cluster versus destroying your entire cluster in a great fireworks display. So we put some of those protections into the platform as well. +But yeah, to your point, being an ops person is a difficult job because we're usually the ones [laughs] that get blamed for everything when something bad happens, even though sometimes it's the software team's fault or sometimes it's even just the infrastructure you're built on. Occasionally, AWS services and Google Cloud and Azure services do go down, and things happen. +We've had instances, even during harpoon development, where we're testing harpoon late at night on AWS, and sometimes AWS does wonky things at night that people don't realize. It's not completely perfect capability. And we're like, oh, why does it only happen at 11:58 on Tuesdays? Oh, because AWS updates their servers during that time, and it slows down everything. +It's still good to understand all the underlying components and how they work, and that could certainly help you regardless of if you use harpoon or not. But ultimately, we're just trying to make it easier for people. They can spend less time focusing on those things. We can help them with a lot of those problems that might occur, and they can focus on their software. +VICTORIA: Great. I think that's...it's interesting to me to always hear about all the different challenges in managing operations of software. So I like that you're working on this space. It's clearly a space that needs more innovation, you know, we're working on it here at thoughtbot as well. Has there been anything in your, like, any theory that you had going into your initial research that when you talked to customers surprised you and caused you to change your direction? +DOMINIC: Yeah. I mean, we run the gamut there. So we did a lot of early customer discovery to try to figure out who might be interested in this product. And so, our first thought was that startups would be the most interested in this product because they're building something new. They just want to get it out there. They want to build their MVP, and they just want to throw it on the internet and get it rolling and not have to worry about whether the software is up and down while they're doing a bunch of sales calls. Because really, during the MVP phase, if you're doing lean startup-style company development, then you really just want to be selling. You want to always be selling. +And so we thought it would just be a no-brainer for startups. And we talked to a lot of startups, and some startups for sure thought it was valuable. But a lot of them were like, "Yeah, that's cool, but we don't care about DevOps. [chuckles] We don't care about anything. Like, I'll run it on my laptop if I have to. The only thing I care about is finding product-market fit and getting that first sale." And so, at least as far as the very first customers that we were looking for, they weren't the best fit. +And then we went and talked to a bunch of mid-market companies because we just decided to go up to the next logical level. And so mid-market companies were very interested because a lot of them were starting to eyeball Kubernetes and maybe sort of migrate some of their capabilities over there. Maybe they had a little bit of ability to be a bit nimble, in that sense, versus some of the enterprise customers. And so they were very interested in it. But a lot of them were very risk averse, like, go find a bunch of enterprise customers that will buy it, and then we'll buy it. And so then we went to talk to the enterprise customers. +And that was sort of like an eye-opening time for us because the enterprise customers just got it. They were like, "Yeah, I'm trying to migrate legacy capabilities we built 10 or 15 years ago to the cloud. We're trying to containerize everything and refactor our existing software. I got to redesign the user interface that was built ten years ago." And if somebody's got a DevOps easy button, then sign me up. I would like to participate because I can't spell Kubernetes yet, but I definitely know what it is, and I want to use it. +So working with the enterprise customers was really great for us because it showed us what the appetite was in the market and who was going to immediately benefit from it. And then, ultimately, that rolls down to the mid-market companies. And maybe later-stage startups as well are starting to find a lot of value in the platform from, you know, have maybe started finding some product-market fit and care a little bit about whether people can access my software and it's maintainable and available. And so we can definitely help with that. +VICTORIA: That's super interesting, and it aligns with my experience as well, coming from consulting companies and the federal government who are working on digital services, and DevOps, and agile, and all of those transformational activities. And so it's been five years, it looks like since you started harpoon. What advice would you give to yourself if you could travel back in time when you were first starting the project? +DOMINIC: So I made lots of mistakes along the way. I'll inevitably make more. But when I first started building this thing, I wasn't even sure how it was going to work. Kubernetes can be a bit of a fickle beast, and it wasn't really built to have a drag-and-drop UI on top of it. And so there are lots of things that could go wrong, trust me, [laughs] I learned them. But building an initial prototype, like, the very base of can the capability work at all, came together pretty quickly. It was maybe three or four months of development during my nights and weekends. And building an enterprise scalable product took quite a bit longer. +But once I had an initial capability, I was very excited because, again, I didn't even know if this was possible, certainly not five or six years ago. So I didn't even really want to raise a round or make money. I do know how venture capital works. So it wasn't even my expectation that people would want to give me money because all I had was an MVP and no product-market fit. And I had just thrown it together in three or four months. But I was just excited about it. +I'm a software developer at heart, and technology excites me. And solving problems is kind of what gets me up in the morning. So I just called all the people I knew, a bunch of VCs, other people, and they're like, "Yeah, I would like to see that. Let's set up a time." And so I think maybe they interpreted that as, like, I want to do a pitch to you for money. [laughs] And I just proceeded to go to, like, this dog and pony show of showing a bunch of people this thing I built, and I thought they would just understand it and get what I was doing. +And I just proceeded to get my ass handed to me over and over and over again. Like, "This isn't that great of a product. How much money are you making?" Blah, blah, blah, blah. I'm like, "No, no, you don't get it. I just started. It's just a prototype at this stage. It's not even a finished product." And they're like, "Well, you're definitely going to fail. [laughter] You're wasting your time. What are you even doing here?" +And so that was...I like to think that I have thick skin, but that's hard to hear as an entrepreneur; just people don't get your vision. They don't understand what it is you're building and why it's going to be valuable to people. And it could be a long time before you get to a point where people can even understand what it is you're doing, and you just have to sort of stay the course and, I mean, I did. I went around on some rock somewhere and hung out in a tent on an island for a while. I just kept going. +And you just got to pour all your heart and soul, and effort into building a product if you want to make it exist out there in the world. And a lot of people are not going to get it, but as long as you believe in it and you keep pushing, then maybe someday they will get it. For the first year after we had a working enterprise-grade product, we kind of did a soft launch. And we had a small set of customers. We had 8 to 10 people that were sort of testing it out and using it, things like that. +We kind of went, you know, more gangbusters launch at the end of last year, and it was crazy. And then...what? I don't know, maybe 60 days since we did a more serious launch. And we have gone from our ten soft users to 2,000 users. +VICTORIA: Wow. Well, that's great growth. And it sounds exciting that you have your team in place now. You're able to set yourself up for growth. +Mid-Roll Ad: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: url tbot.io/devops +VICTORIA: So now that you're getting more established, you're getting more customers, you have a team supporting you on the project; what parts of the DevOps culture do you feel like are really important to making a team that will continue to grow? +DOMINIC: I've been an individual contributor for a long period of time. I was a first-level manager and managed people. At a very granular personal level, I've been a director, and a VP, and a CTO at a bunch of different places. And so all of those different roles and different companies that I've worked at have taught me a lot about people, and teams, and culture, and certainly about hiring. +I think hiring is the absolute most important thing you can do in a company, and definitively in a software company. Because there are just certain people that are going to mesh well with your culture, and the people that do and that are driven and passionate about what they do, they're just going to drive your company forward. And so I just spend a lot of my time when we need to grow as a company, which happens here and there, really focusing on who is going to be the best next person to bring on to the company. +And usually, I'm thinking about this far in advance because whenever we do need that person, I don't want to have to start thinking about it. I want to just know, like, it is Frank, it is Bob, it is Jamey, or Alex, or whoever else. Because it is...at a personal level, there has to be people who are very aligned with your visions, and your values, and your culture, and they care and are going to push the company forward. +And if you're just hiring people with a quick coding interview and a 30-minute culture fit session, you're going to make a lot of hiring mistakes. You're going to find people who are just looking for a nine-to-five or things like that, and, I mean, there's nothing wrong with that. But in a startup especially, you really need people who buy into the vision and who are going to push the thing forward. +And I'm looking for people who just care, like; they have an ownership mentality. Maybe in a different lifetime or a different part of their career, they'd be an entrepreneur at their own company. But you just give them stuff, and they're like, cool, this is mine. I'm going to take care of this. It's now my child. I will make sure that it grows up and it is healthy and goes to a good university. Those are the type of people that you want in your company, people that you would trust with your children. So those are the criteria for working at harpoon, I guess. +VICTORIA: Yeah, that's good. So what does success look like in the next six months or even beyond the next five years? +DOMINIC: I think it's still very early market for us. Certainly, we have an explosive growth of users using the platform, and that's really heartening to see. That's really awesome that people want to use the thing that you built. But again, there are so many companies out there and organizations that are still not even doing DevOps. They're just doing manual deployments, maintaining clusters manually, not using containers or Kubernetes. Not to say that you have to use these things and that they're a panacea, and they work in every sense because they don't. +But obviously, there's been a major shift in the industry towards containers and container orchestration like Kubernetes. Even some of the serverless platforms that people like to use are actually backed by Kubernetes, so you see a major shift in that direction. But there are still so many different companies and organizations that, again, are still locked into legacy ways of doing things and manually doing things. +There are companies that are trying to get their products off the ground, and they're looking for faster and easier, and cheaper ways to do that. And I think that's what's really exciting about harpoon is we can help these companies. We can help them be more successful. We can help them migrate to things that are more modern and agile. We can help them get their product off the ground faster or more reliably. And so that's kind of what excites me. +But you know what? We do a lot of demos, you know, sales demos and things like that. And, really, we don't have PowerPoints. We're just like, cool, this is the app, and this is how you use it. And it is so simplistic to use, even though Kubernetes is quite complicated, that the demo goes pretty quick. We're talking five, six minutes if there are not a lot of questions. And we always get exactly the same response, whether somebody is not super familiar with Kubernetes or they are familiar with Kubernetes, and they've set up their own cluster. It's almost always, "Wow," and then a pause, and then "But how do I know it works?" [laughs] +So there's going be a lot of work for us in educating people out there that there is an easier way to do DevOps now, that you can do drag and drop DevOps and dynamically generate all of your scripts and configuration, and open up networks, and deploy load balancers, and all the other things that you would need to do with Kubernetes, literally in a few minutes just dragging and dropping things. So there's going to be a lot of education that just goes into saying, "Hey, there's a new market, and this is what it is. And this is how it compares to the manual processes people are using out there. Here's how it compares to some of the other tools that are more incremental in nature." +And trust, you know, over time, people are going to have to use the platform and see that it works and talk to other people and be like, yeah, I deployed my software on harpoon, and nothing terrible happened. Demons didn't come out of the walls, and my software kept running, and no meteors crashed in my house. So it's just going to take some time for us to really grow and build the education around that market to show that it's possible and that it exists, and it can be an option for you. +VICTORIA: Right. I used to do a lot of intro to DevOps talks with Women Who Code and DevOps DC. And I would describe Kubernetes as a way to keep your kubes neat, and your kube is where your software lives. It's a little house that keeps the doors locked and things like that. Do you have another way to kind of explain what is Kubernetes? Like, how do you kind of even just get people started on what DevOps is? +DOMINIC: I like to usually use the cattle story. [laughs] So, in DevOps, they have these concepts of immutable infrastructure or immutable architecture. And so when you have virtual machines, which is what people have been running on for quite a while, certainly some people still run on bare metal servers, but pretty much everybody's got on board with virtualization at this point, and so most software these days is at least running on virtual machines. And so the difficulty with virtual machines is, I mean, there's nothing wrong with them, but they're kind of like pets. They exist for long periods of time. They have what we call state drift, and that's just the changing of the data or the state of the virtual machine over time. +And even if I were to kill off that virtual machine and start another one, it wouldn't be exactly the same one. It wouldn't be, you know, fluffy. It would be a clone of fluffy. And maybe it wouldn't have the same personality, and it wouldn't do exactly the same things. And sometimes that might be good; maybe fluffy was a terrible dog. But in other cases, you're like, oh crap, I needed that snowflake feature that Bob built three years ago. And Bob has been hit by a train, so people can't ask Bob anymore. +And so what then really happens at these organizations is when the virtual machines start acting up, they don't kill them. They take them to the vet. They take care of them. They pet them. They tell them they're a good boy. And you have entire enterprises that are super dependent on these virtual machines staying alive. And so that's no way to run your business. And so that's one of the reasons why people started switching over to containers because the best practices in containers is to build software that's immutable. +So if you destroy or kill one of your containers, you can start another one. And it should work exactly the same as before, and that's because when you build your containers, you can't change them unless you rebuild them. I mean, there are ways to do it, but people will wave their finger angrily at you if you try to do that because it's not a best practice. +So, at the end of the day, virtual machines are pets, and the containers are cattle. And when containers start acting up, you kill them. And you take them to the meat factory, and you go get another one. And so this provides a ton of value from a software development and an ops perspective because anytime you have a problem, you just kill your containers, start new ones, and you're off to the races again. +And it significantly reduces the troubleshooting time when you're having problems. Obviously, you probably want to log things and check into things; why did that happen? So that maybe you can go make a fix in your software. But at the end of the day, you want to keep your ops running. Containers are a great way to do that without having to be up at midnight figuring out why the virtual machine is acting up. +And so the difficulty with cattle is they like to graze and wander and break through fences and things like that. And mostly, when you have an enterprise software application or even just a startup with an MVP, you probably have multiple containers that you need to run and build this application. And so you need somebody to orchestrate. You need somebody to wrangle your containers. +And so Kubernetes, I like to say, is like cowboys. Like, they're the ones that wrangle your cattle and make sure they're all going in the right direction and doing the right things. And so it just makes natural sense. Like, if you have a bunch of cattle, you need somebody to take care of them, so that's what Kubernetes does. +JOE: Yeah, just to add to that, one of the things I really like about Kubernetes is that it's declarative versus prescriptive. So if you look at a lot of the older DevOps tools like Chef, things like that, you're effectively telling the machine what you want it to do to end up with a particular deployment. With containers, you'd say, start this number of containers on this node. Start this number of containers on this node. Add a virtual machine with these. Whereas with Kubernetes, you state the way you would like the world to be, and then Kubernetes' job is to make the world like that. +So from a developer's perspective, when they're deploying things, they don't actually usually want to think in terms of the steps involved between I push this code, and somebody can use it. What they want us to say is I want this code running in containers, and I would like it to have this configuration. I would like it to have these ports exposed. And I love that Kubernetes, to a pretty good extent, abstracts away all of those steps and just lets you say what you want. +DOMINIC: Yeah, that's a lot of the power in Kubernetes. You just say, "This is what I want, and then make it so." And Kubernetes goes out and figures out where it's going to schedule your container on what node or server if it dies. Kubernetes is like; I'm pretty sure you wanted one of those running, so I'm going to run it again. It just handles a lot of those things for you that previously you would need somebody with a pager to call to fix. And Kubernetes is automating a lot of that deployment and maintenance for you. +VICTORIA: Right. And it seems like there's the movement to really coalesce around Kubernetes. I wonder if either of you can speak to the healthiness of the ecosystem for Kubernetes, which is open source, and why you chose to build on it. +DOMINIC: So there was sort of a bit of a container orchestration war for a while. There was a bunch of different options. And I'm not saying that a lot of them weren't good options. Like, Docker built a capability called Swarm, and it's fairly simple to use and pretty powerful. But there was just a lot of backing from the open-source community behind Kubernetes when Google made it an open-source project. There were other things sort of like Kubernetes but not really like Mesos. And they all had like this huge bloodbath to see who was going to be the winner. And I just feel like Kubernetes kind of pulled ahead. +It was a really smart move from Google to make it open-source and get the open-source community's buy-in to use. And it just became a very powerful but complex tool for running your software in production. Google had been using some form of that called Google Borg for a number of years prior. And I'm guessing they're still quite a bit different. But that's how it kind of came about. Do you have anything to add, Joe? +JOE: I'd say that I judge the winner or the health of an ecosystem by the health of the off-the-shelf and open-source software that can run on that system. So Kubernetes is a thing that you use yourself. You build things to run on it. But also, you can pick and choose many things from the community that people have already built. And there is a huge open-source community for components that run on Kubernetes, everything from CI/CD to managing databases to doing interesting deployment styles like canary deployments. That's really healthy. +It just didn't happen with the other systems like Swarm or Nomad was another one. And most of the other companies that I saw doing container orchestration eventually just changed to doing their flavor of Kubernetes, like Rancher. I forget what their original platform was called. But their whole thing was based on that cattle metaphor. [chuckles] And they took a pretty similar approach to containers. And now, if you ask somebody what Rancher is, they'll tell you it's a managed Kubernetes platform. +DOMINIC: Yeah, I think it's called Longhorn, so they very much have the cattle theme in there. I mean, they're literally called Rancher, so there you go. But yeah, at the end of the day, something is going to come after Kubernetes as well. And I like to think that it's not so much a matter of what's going to be next? Is there going to be something beyond containers or container orchestrators like Kubernetes? +I just think there are going to be more and more layers of abstraction because, at the end of the day, look at the advent of things like ChatGPT and generative AI. People just want to get their jobs done more efficiently and faster. And in software, there's just a lot of time and money that goes into getting software running and keeping it running, and that's why Kubernetes makes sense. But then there's also a lot of time that goes into Kubernetes. +And so we think that harpoon is just sort of the natural next layer of abstraction that's going to live on as the next thing. So if 15 years ago I told you I was going to build a web application and I was going to go run it in the cloud, maybe you would have said, "You're crazy, Dom. Like, how could you trust this guy, Jeff, with all your software? What if he is going to steal it? And what if he can't run a data center? What then?" +And now, if I told you I was going to go build a data center because I want to build a web application, you would look at me like I was a pariah and that I was not fit to run a company and that I should just use the cloud. So I think it's the same process. We're going to go with containers and Kubernetes. And software deployment, in general, is going to be an abstraction layer that lives on top of all that because software developers and companies just want to push out good software to end users. And any sort of way to make that more efficient or more fun is going to be embraced eventually. +JOE: Yeah, I agree with that. I hear people ask, "What are you going to do when Kubernetes is obsolete?" pretty often. And I think it's achieved enough momentum that it won't be. I think it'll be what else is built on top of Kubernetes? Like, people talk about servers like they're obsolete, but they're not; there are still servers. People are just running virtual machines on them. And virtual machines are not obsolete. We'll just run containers on them. So once we get beyond the layer of worrying about containers, you'll still need a container platform. And based on the momentum it's achieved, I think that platform is going to be Kubernetes. +VICTORIA: Technology never dies. You just get more different types of technology. [laughs] Usually, that's my philosophy on that. +DOMINIC: Yeah, I mean, there's never been a better time to be a software developer, especially if you're an entrepreneur at the same time, because that's what happens over time. Like, what we're achieving with web applications today and what you can push out to the internet and kind of judge if there's a market for would have been unimaginable 20 years ago because, again, you would have had to build a data center. [laughs] And who has a bunch of tens of millions of dollars sitting around to do that? +So now you can just use existing software from other people and glue it together. And you can use the cloud and deploy your software and get it out to the masses and scale it. And it's an amazing time to be alive and to be building things for people. +VICTORIA: Right. And you mentioned a few things like artificial intelligence before, and there are a lot of people innovating in that space, which requires a lot of data, and networking, and security, and other types of things that you want to think about if you're trying to invent that kind of product. Which brings me to a question I have around, you know when you're adding that abstraction layer to these Kubernetes clusters, how does that factor into security compliance frameworks? And does that even come up with the customers who want to use your product? +DOMINIC: Yeah. I mean, definitely, people are concerned about security. When we do infrastructure as code for your virtual infrastructure that's running your Kubernetes cluster that we deploy for you, certainly, we're using best practices from a security standpoint. We do all the same things. If we're building out custom scripts for some clients somewhere, we'd want it to be secure. And we want to lock down different aspects of components that we're building and not just expose all the ports on maybe a load balancer and things like that. +So by default, we try to build in as much security as we can. It's pragmatic. I think ultimately we'll probably go down to the path of SOC 2 compliance, and then anything that goes on top of a harpoon cluster or that is deployed with harpoon will be SOC 2 compliant to a large degree. And so yeah, I mean, security is definitely a part of it. We're currently building in a lot of other security features, too, like role-based access control and zero trust, which we'll have pretty soon here. +So, yeah, if you want to build your software and get it deployed, you want it to be scalable, and you also want it to be secure. There are so many ilities that come into deploying software. But to your point, even on the artificial intelligence side, people are looking for easier ways to abstract away the complexity. Like, if I told you to go write me a blog post with either ChatGPT or go build your own generative AI model and use that, then you're probably going to be like, yeah, I'll just go to the OpenAI website. I'll be back in a minute. +And that's why also you see things like SageMaker from AWS. People want abstraction layers. They want easier ways to do things. And it's not just in DevOps; it's in artificial intelligence and machine learning. That's why drag-and-drop editors are becoming more popular in building web applications mobile applications. I think all of this software development stuff is going to be really accessible to a much larger community in the near future. +VICTORIA: Yeah, wonderful. That's great. And so, Dominic, any final takeaways for our listeners today? +DOMINIC: Definitely, if you have interest in how either harpoon or Kubernetes, in general, might be applicable to you and your company, we're a bunch of friendly people over here. Even if you're not quite sure how to get started or you need advice on stuff, definitely go hit us up on our website or hit up support at harpoon.io, and send us a message. +We're very open to helping people because, again, what we're really trying to do is make this more accessible to more people and make more people successful with this technology. So if we have to get on a bunch of phone calls or come sit next to you or do whatever else, we're here to be a resource to the community, and harpoon is for you to get started. So don't feel like you need a bunch of money to get started deploying with Kubernetes and using the platform. +VICTORIA: That's a great note to end on. +So you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Dominic Holt. + + + Dominic Holt is CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds.

+ +

Victoria talks to Dominic about commoditizing DevOps as a capability, coming up with the idea for drag and drop just thinking through how he could do these things in a visual and intuitive way, and using Kubernetes as a base for Harpoon.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dominic Holt, CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds. Dominic, thank you for joining me.

+ +

DOMINIC: Yeah, of course. Thanks for having me, Victoria.

+ +

VICTORIA: Yes, I'm really excited to talk all about what Kubernetes is. And I have Joe Ferris, the CTO of thoughtbot, here with me as well to help me in that process.

+ +

JOE: Hello.

+ +

VICTORIA: Excellent. Okay, so, Dominic, why don't you just tell me how it all got started? What led you to start harpoon?

+ +

DOMINIC: I got into the DevOps space fairly early. It was, I don't know, probably 2012 timeframe, which sounds like not that long ago. But, I mean, DevOps is also still a baby. So I have a software background. And I was starting to figure out how to do the continuous; I guess, automated way of standing up cloud infrastructure for Lockheed Martin at the time because people didn't know how to do that. There weren't a lot of tools available, and nobody knew what DevOps was. And if you said it to somebody, they would have slapped you.

+ +

VICTORIA: Aggressive. [laughs]

+ +

DOMINIC: [laughs] Maybe not, maybe not. Maybe they'd be nicer about it. But anyway, nobody knew what DevOps was because it wasn't coined yet. And I started realizing that this was not some system administration voodoo. It was just common sense from a software development standpoint. And I ended up leaving Lockheed shortly thereafter and going and working for a small business here in San Diego. And I said, I have no idea what any of this stuff is, but we're going to do it because, in a few years, everybody's going to be doing it because it's common sense. So we did.

+ +

We grew quite a large practice in consulting and DevOps, among other things. And predominantly, I was working with the U.S. Navy at the time, and they needed a standardized way to deploy software to aircraft carriers and destroyers, the ships out there in the ocean. And so, I came up with a design for them that used Kubernetes. And we built a pipeline, a CI/CD pipeline, to automatically deploy software from the cloud to Navy ships out in the ocean on top of Kubernetes. And everything worked great. And it was there, and we tested it.

+ +

But at the end of the day, handing over the maintenance, what we call day two ops, proved to be troubling. And it never quite made it onto the ships in the way that we wanted. So after that, I did a bunch of consulting with other groups in the Navy, and the Air Force, and Space Force, and all kinds of different groups across the government. And I also started consulting in commercial, fortune 500, startups, everything.

+ +

And I just saw that this problem was really pervasive, handling the day two operations. You get everything up and running, but then maintaining it after that was just complicated for people because all of the DevOps implementations are snowflakes. So if you go from Company A to Company B, they look nothing alike. And they may have a lot to do with somebody named Jim or Frank or Bob and how they thought was the best way to do it.

+ +

And so, running a DevOps consultancy myself, I just knew how hard it was to find the talent, and how expensive they were, and how hard it was to keep them because everyone else was trying to hire my talent all the time. And I just thought to myself, all of this is completely untenable. Somebody is going to commoditize DevOps as a capability. And what would that look like?

+ +

VICTORIA: Right. I'm familiar with the demand for people who know how to build the infrastructure and systems for deploying and running software. [laughs] And I like how you first talked about DevOps, just it being common sense. And I remember feeling that way when I went to my first DevOps DC meetup. I was like, oh, this is how you're supposed to build teams and organizations in a way to run things efficiently and apply those principles from building software to managing your infrastructure.

+ +

DOMINIC: Yeah. Well, I had lived the life of an enterprise software developer for quite a while before then. And I had gone through that whole process they talk about in all of DevOps bibles about why it is we're doing this, where the software development team would have their nice, fancy dev laptops. And the operations team with the pagers or whatever would be the ones managing the servers. And the software developers were never really sure exactly how it was going to work in production, but were like; I'm just going to throw it over the fence and see what the ops people do.

+ +

And inevitably, the ops people would call us very angrily, and they would say, "Your software doesn't work." And then, of course, we would say that the ops people are all crazy because it works just fine here on my laptop, and they just don't know what they're doing. And, I mean, we would just fight back and forth about this for six months until somebody figured out that we were running the wrong version of some dependency in the software on the ops side, and that's why it didn't work. So that process is just crazy, and nobody in their right mind would want to go through it if they could avoid it.

+ +

VICTORIA: Right. I'm sure Joe has had some stories from his time at thoughtbot.

+ +

JOE: Yeah, certainly. I was interested by what you said about working with...I think it was Frank, and Ted, and Bob. I've definitely worked with all those people in their own snowflakes. And one of the things that drew me to Kubernetes is that it was an attempt to standardize at least some of the approaches or at least provide anchor points for things like how you might implement networking, and routing, and so on.

+ +

I'm interested to hear, you know, for a drag-and-drop solution, even though Kubernetes was meant to standardize a lot of things, there are a lot of different Kubernetes distributions. And I think there are still a lot of Kubernetes snowflakes. I'm curious how you manage to tackle that problem with a drag-and-drop solution to hit the different Kubernetes distributions out there.

+ +

DOMINIC: Yeah, I mean, I think you nailed it, Joe. Standing up Kubernetes is a little bit complicated still these days. It's been made a lot easier by a lot of different companies, and products, and open-source software, and things like that. And so I see a lot of people getting up basic Kubernetes clusters these days. But then you look at companies like ARMO that are doing compliance scans and security scans on Kubernetes clusters, and they're making the claim that 100% of the Kubernetes clusters they scan are non-compliant [laughs] and have security issues.

+ +

And so that just goes to show you all of the things that one has to know to be successful just to stand up a cluster in the first place. And even when I...like for a client or something, over the years, if I was standing up a Kubernetes cluster and a lot of it was automated, you know, we used Terraform and Ansible, and all the other best practices under the hood. A lot of the response I got back when we handed over a cluster to a client was, "Okay, now what?"

+ +

There are still a lot of things you have to learn to maintain that cluster, keep it up to date, upgrade the underlying components of the cluster, deploy the software, configure the software, all those things. And can you learn these things? Absolutely. Like, they're not rocket science, but they're complicated. And it is a commitment that you have to make as an individual if you're going to become proficient in all of these things and managing your own cluster.

+ +

And so we were just...we had done this so many times at different companies I had worked with, for different clients, and seeing how all of the different pieces work together and where clients were having problems and what really hung people up. And so I just started thinking to myself, how would you make that easier? How would you make that more available to the pizza guy or an 18-year-old with no formal training that's on a ship in the ocean? And that's why I came up with the idea for drag and drop, just thinking through how can I do these things in a visual way that is going to be intuitive for people?

+ +

VICTORIA: Well, I have, obviously, a very thorough understanding of Kubernetes, [laughs] just kidding. But maybe explain a little bit more about to a founder why should they invest in this type of approach when they're building products?

+ +

DOMINIC: So I think that's a great question. What I find these days is DevOps is almost a requirement to do business these days in some sort of nimble way. So you have to...whether you're a large enterprise or you're a garage startup, you need to be able to change your software to market forces, to stuff that's happening in the news, to your customers don't like something. So you want to change it to something else quickly or pivot because if something happens, you can get your day in the sun, or you can capitalize on something that's happening.

+ +

And so the difficulty is I think a lot of people have an impression that DevOps scripts are sort of like a build once and forget type of thing, and it'll just work thereafter. But it's actually software, and I like to think of software as living organisms. You have to take care of them like they're people, almost because if you don't, they'll become brittle and unhealthy over time. If you have a child, you have to feed them probably multiple times a day, brush their teeth. You got to tuck them in at night. You have to be nice to them. You have to do all the things that you would do with a child.

+ +

But with software as well, if you just take the quick route, and quick fix things, and hack, and take shortcuts, eventually, you're going to have a very unhealthy child on your hands, and they're going to have behavior problems. At the end of the day, you have all these DevOps scripts, and they can be quite complex together. And you have to take care of them like they're your own child.

+ +

And the problem is you're also taking care of your software products like it's your child. And so now you're taking care of two children. And as somebody that has two children, I can tell you that things become much more complicated when two children are having behavioral problems than just one. And you're at the store, and it's very embarrassing.

+ +

So I guess the point is that harpoon is a capability that can basically take care of your second child for you, which is your DevOps deployments. And then you can just focus on the one child that you, I mean, this is turning into a terrible analogy at this point. [laughter] But you should love all of your children equally. But, in this case, you're looking to take care of your products and get it out there, and harpoon is something that can take care of your DevOps software for you.

+ +

VICTORIA: I agree. I think when your software or children are problematic, it's more than just embarrassing sometimes. It can create a lot of financial and legal liability as well. From your research, when you're building this product and, like, who's going to be interested in buying this thing, is that something that people are concerned about?

+ +

DOMINIC: Yeah, absolutely. I mean, the fact that we can stand up your cluster for you, stand up all of your cloud infrastructure for you, and then dynamically generate all of the configuration as code as well, and how to open those things securely up to the network and control everything such that you're not going to accidentally do something that's really bad, can definitely help out a lot of people.

+ +

The interest has been really overwhelming from so many different groups and organizations. We have people that are interested in the Department of Defense in both the U.S. and other countries. We have fortune 500 companies that see this as a pathway to accelerate digital transformation for legacy applications or even to use it as a sandbox, so people aren't bugging Frank, and Joe, and Bob, who run the Kubernetes clusters in production.

+ +

We have startups who see it just as a way to skip over the whole DevOps thing and work on getting a product-market fit so that they have a production environment that just works out of the box. So it's been really interesting seeing all the different use cases people are using harpoon for and how it's helped them in some way get to some and realize some goal that they have.

+ +

JOE: I'm curious if it's been a challenge as somebody managing the underlying infrastructure as sort of a plug-and-play thing. One experience I've had working more on the operations side of DevOps is that everything becomes your problem. Like, if the server misbehaves, if there's a database crash, whatever, certainly, that's your problem. But also, if the application is murdering your database, that becomes your problem. And it's really an application problem. But it surfaces visibly in the infrastructure when the CPU spikes and it stops responding to requests. And so, how do you navigate that agreement with your users? How do you balance what's your responsibility versus theirs to not kill the cluster?

+ +

DOMINIC: One thing that's great about Kubernetes and why it's a great base for our product is that Kubernetes is really good at keeping things running. Certainly, there are catastrophic things that can happen, like an entire region of EC2 and Amazon Web Services goes down. And that is, obviously, if you have your clusters only running in that particular region, you're going to have a bad day.

+ +

So there are things beyond our control. I mean, those things are also covered by the service-level agreement, the SLA with AWS, since you're using your own AWS account when you're utilizing harpoon. So it's like a hybrid SaaS where we deploy everything into your account, and you own it. And you can adjust those infrastructure things on your own as you'd like. So from that standpoint, you're kind of covered with your agreement with AWS as an example of a cloud service provider.

+ +

And certainly, Kubernetes also kind of knows what to do in some of those instances where you have a container that is murdering everything. In a lot of cases, it can be configured to, you know, just die or go into a CrashLoopBackOff or something if it's just taking up all your resources in the cluster versus destroying your entire cluster in a great fireworks display. So we put some of those protections into the platform as well.

+ +

But yeah, to your point, being an ops person is a difficult job because we're usually the ones [laughs] that get blamed for everything when something bad happens, even though sometimes it's the software team's fault or sometimes it's even just the infrastructure you're built on. Occasionally, AWS services and Google Cloud and Azure services do go down, and things happen.

+ +

We've had instances, even during harpoon development, where we're testing harpoon late at night on AWS, and sometimes AWS does wonky things at night that people don't realize. It's not completely perfect capability. And we're like, oh, why does it only happen at 11:58 on Tuesdays? Oh, because AWS updates their servers during that time, and it slows down everything.

+ +

It's still good to understand all the underlying components and how they work, and that could certainly help you regardless of if you use harpoon or not. But ultimately, we're just trying to make it easier for people. They can spend less time focusing on those things. We can help them with a lot of those problems that might occur, and they can focus on their software.

+ +

VICTORIA: Great. I think that's...it's interesting to me to always hear about all the different challenges in managing operations of software. So I like that you're working on this space. It's clearly a space that needs more innovation, you know, we're working on it here at thoughtbot as well. Has there been anything in your, like, any theory that you had going into your initial research that when you talked to customers surprised you and caused you to change your direction?

+ +

DOMINIC: Yeah. I mean, we run the gamut there. So we did a lot of early customer discovery to try to figure out who might be interested in this product. And so, our first thought was that startups would be the most interested in this product because they're building something new. They just want to get it out there. They want to build their MVP, and they just want to throw it on the internet and get it rolling and not have to worry about whether the software is up and down while they're doing a bunch of sales calls. Because really, during the MVP phase, if you're doing lean startup-style company development, then you really just want to be selling. You want to always be selling.

+ +

And so we thought it would just be a no-brainer for startups. And we talked to a lot of startups, and some startups for sure thought it was valuable. But a lot of them were like, "Yeah, that's cool, but we don't care about DevOps. [chuckles] We don't care about anything. Like, I'll run it on my laptop if I have to. The only thing I care about is finding product-market fit and getting that first sale." And so, at least as far as the very first customers that we were looking for, they weren't the best fit.

+ +

And then we went and talked to a bunch of mid-market companies because we just decided to go up to the next logical level. And so mid-market companies were very interested because a lot of them were starting to eyeball Kubernetes and maybe sort of migrate some of their capabilities over there. Maybe they had a little bit of ability to be a bit nimble, in that sense, versus some of the enterprise customers. And so they were very interested in it. But a lot of them were very risk averse, like, go find a bunch of enterprise customers that will buy it, and then we'll buy it. And so then we went to talk to the enterprise customers.

+ +

And that was sort of like an eye-opening time for us because the enterprise customers just got it. They were like, "Yeah, I'm trying to migrate legacy capabilities we built 10 or 15 years ago to the cloud. We're trying to containerize everything and refactor our existing software. I got to redesign the user interface that was built ten years ago." And if somebody's got a DevOps easy button, then sign me up. I would like to participate because I can't spell Kubernetes yet, but I definitely know what it is, and I want to use it.

+ +

So working with the enterprise customers was really great for us because it showed us what the appetite was in the market and who was going to immediately benefit from it. And then, ultimately, that rolls down to the mid-market companies. And maybe later-stage startups as well are starting to find a lot of value in the platform from, you know, have maybe started finding some product-market fit and care a little bit about whether people can access my software and it's maintainable and available. And so we can definitely help with that.

+ +

VICTORIA: That's super interesting, and it aligns with my experience as well, coming from consulting companies and the federal government who are working on digital services, and DevOps, and agile, and all of those transformational activities. And so it's been five years, it looks like since you started harpoon. What advice would you give to yourself if you could travel back in time when you were first starting the project?

+ +

DOMINIC: So I made lots of mistakes along the way. I'll inevitably make more. But when I first started building this thing, I wasn't even sure how it was going to work. Kubernetes can be a bit of a fickle beast, and it wasn't really built to have a drag-and-drop UI on top of it. And so there are lots of things that could go wrong, trust me, [laughs] I learned them. But building an initial prototype, like, the very base of can the capability work at all, came together pretty quickly. It was maybe three or four months of development during my nights and weekends. And building an enterprise scalable product took quite a bit longer.

+ +

But once I had an initial capability, I was very excited because, again, I didn't even know if this was possible, certainly not five or six years ago. So I didn't even really want to raise a round or make money. I do know how venture capital works. So it wasn't even my expectation that people would want to give me money because all I had was an MVP and no product-market fit. And I had just thrown it together in three or four months. But I was just excited about it.

+ +

I'm a software developer at heart, and technology excites me. And solving problems is kind of what gets me up in the morning. So I just called all the people I knew, a bunch of VCs, other people, and they're like, "Yeah, I would like to see that. Let's set up a time." And so I think maybe they interpreted that as, like, I want to do a pitch to you for money. [laughs] And I just proceeded to go to, like, this dog and pony show of showing a bunch of people this thing I built, and I thought they would just understand it and get what I was doing.

+ +

And I just proceeded to get my ass handed to me over and over and over again. Like, "This isn't that great of a product. How much money are you making?" Blah, blah, blah, blah. I'm like, "No, no, you don't get it. I just started. It's just a prototype at this stage. It's not even a finished product." And they're like, "Well, you're definitely going to fail. [laughter] You're wasting your time. What are you even doing here?"

+ +

And so that was...I like to think that I have thick skin, but that's hard to hear as an entrepreneur; just people don't get your vision. They don't understand what it is you're building and why it's going to be valuable to people. And it could be a long time before you get to a point where people can even understand what it is you're doing, and you just have to sort of stay the course and, I mean, I did. I went around on some rock somewhere and hung out in a tent on an island for a while. I just kept going.

+ +

And you just got to pour all your heart and soul, and effort into building a product if you want to make it exist out there in the world. And a lot of people are not going to get it, but as long as you believe in it and you keep pushing, then maybe someday they will get it. For the first year after we had a working enterprise-grade product, we kind of did a soft launch. And we had a small set of customers. We had 8 to 10 people that were sort of testing it out and using it, things like that.

+ +

We kind of went, you know, more gangbusters launch at the end of last year, and it was crazy. And then...what? I don't know, maybe 60 days since we did a more serious launch. And we have gone from our ten soft users to 2,000 users.

+ +

VICTORIA: Wow. Well, that's great growth. And it sounds exciting that you have your team in place now. You're able to set yourself up for growth.

+ +

Mid-Roll Ad:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: url tbot.io/devops

+ +

VICTORIA: So now that you're getting more established, you're getting more customers, you have a team supporting you on the project; what parts of the DevOps culture do you feel like are really important to making a team that will continue to grow?

+ +

DOMINIC: I've been an individual contributor for a long period of time. I was a first-level manager and managed people. At a very granular personal level, I've been a director, and a VP, and a CTO at a bunch of different places. And so all of those different roles and different companies that I've worked at have taught me a lot about people, and teams, and culture, and certainly about hiring.

+ +

I think hiring is the absolute most important thing you can do in a company, and definitively in a software company. Because there are just certain people that are going to mesh well with your culture, and the people that do and that are driven and passionate about what they do, they're just going to drive your company forward. And so I just spend a lot of my time when we need to grow as a company, which happens here and there, really focusing on who is going to be the best next person to bring on to the company.

+ +

And usually, I'm thinking about this far in advance because whenever we do need that person, I don't want to have to start thinking about it. I want to just know, like, it is Frank, it is Bob, it is Jamey, or Alex, or whoever else. Because it is...at a personal level, there has to be people who are very aligned with your visions, and your values, and your culture, and they care and are going to push the company forward.

+ +

And if you're just hiring people with a quick coding interview and a 30-minute culture fit session, you're going to make a lot of hiring mistakes. You're going to find people who are just looking for a nine-to-five or things like that, and, I mean, there's nothing wrong with that. But in a startup especially, you really need people who buy into the vision and who are going to push the thing forward.

+ +

And I'm looking for people who just care, like; they have an ownership mentality. Maybe in a different lifetime or a different part of their career, they'd be an entrepreneur at their own company. But you just give them stuff, and they're like, cool, this is mine. I'm going to take care of this. It's now my child. I will make sure that it grows up and it is healthy and goes to a good university. Those are the type of people that you want in your company, people that you would trust with your children. So those are the criteria for working at harpoon, I guess.

+ +

VICTORIA: Yeah, that's good. So what does success look like in the next six months or even beyond the next five years?

+ +

DOMINIC: I think it's still very early market for us. Certainly, we have an explosive growth of users using the platform, and that's really heartening to see. That's really awesome that people want to use the thing that you built. But again, there are so many companies out there and organizations that are still not even doing DevOps. They're just doing manual deployments, maintaining clusters manually, not using containers or Kubernetes. Not to say that you have to use these things and that they're a panacea, and they work in every sense because they don't.

+ +

But obviously, there's been a major shift in the industry towards containers and container orchestration like Kubernetes. Even some of the serverless platforms that people like to use are actually backed by Kubernetes, so you see a major shift in that direction. But there are still so many different companies and organizations that, again, are still locked into legacy ways of doing things and manually doing things.

+ +

There are companies that are trying to get their products off the ground, and they're looking for faster and easier, and cheaper ways to do that. And I think that's what's really exciting about harpoon is we can help these companies. We can help them be more successful. We can help them migrate to things that are more modern and agile. We can help them get their product off the ground faster or more reliably. And so that's kind of what excites me.

+ +

But you know what? We do a lot of demos, you know, sales demos and things like that. And, really, we don't have PowerPoints. We're just like, cool, this is the app, and this is how you use it. And it is so simplistic to use, even though Kubernetes is quite complicated, that the demo goes pretty quick. We're talking five, six minutes if there are not a lot of questions. And we always get exactly the same response, whether somebody is not super familiar with Kubernetes or they are familiar with Kubernetes, and they've set up their own cluster. It's almost always, "Wow," and then a pause, and then "But how do I know it works?" [laughs]

+ +

So there's going be a lot of work for us in educating people out there that there is an easier way to do DevOps now, that you can do drag and drop DevOps and dynamically generate all of your scripts and configuration, and open up networks, and deploy load balancers, and all the other things that you would need to do with Kubernetes, literally in a few minutes just dragging and dropping things. So there's going to be a lot of education that just goes into saying, "Hey, there's a new market, and this is what it is. And this is how it compares to the manual processes people are using out there. Here's how it compares to some of the other tools that are more incremental in nature."

+ +

And trust, you know, over time, people are going to have to use the platform and see that it works and talk to other people and be like, yeah, I deployed my software on harpoon, and nothing terrible happened. Demons didn't come out of the walls, and my software kept running, and no meteors crashed in my house. So it's just going to take some time for us to really grow and build the education around that market to show that it's possible and that it exists, and it can be an option for you.

+ +

VICTORIA: Right. I used to do a lot of intro to DevOps talks with Women Who Code and DevOps DC. And I would describe Kubernetes as a way to keep your kubes neat, and your kube is where your software lives. It's a little house that keeps the doors locked and things like that. Do you have another way to kind of explain what is Kubernetes? Like, how do you kind of even just get people started on what DevOps is?

+ +

DOMINIC: I like to usually use the cattle story. [laughs] So, in DevOps, they have these concepts of immutable infrastructure or immutable architecture. And so when you have virtual machines, which is what people have been running on for quite a while, certainly some people still run on bare metal servers, but pretty much everybody's got on board with virtualization at this point, and so most software these days is at least running on virtual machines. And so the difficulty with virtual machines is, I mean, there's nothing wrong with them, but they're kind of like pets. They exist for long periods of time. They have what we call state drift, and that's just the changing of the data or the state of the virtual machine over time.

+ +

And even if I were to kill off that virtual machine and start another one, it wouldn't be exactly the same one. It wouldn't be, you know, fluffy. It would be a clone of fluffy. And maybe it wouldn't have the same personality, and it wouldn't do exactly the same things. And sometimes that might be good; maybe fluffy was a terrible dog. But in other cases, you're like, oh crap, I needed that snowflake feature that Bob built three years ago. And Bob has been hit by a train, so people can't ask Bob anymore.

+ +

And so what then really happens at these organizations is when the virtual machines start acting up, they don't kill them. They take them to the vet. They take care of them. They pet them. They tell them they're a good boy. And you have entire enterprises that are super dependent on these virtual machines staying alive. And so that's no way to run your business. And so that's one of the reasons why people started switching over to containers because the best practices in containers is to build software that's immutable.

+ +

So if you destroy or kill one of your containers, you can start another one. And it should work exactly the same as before, and that's because when you build your containers, you can't change them unless you rebuild them. I mean, there are ways to do it, but people will wave their finger angrily at you if you try to do that because it's not a best practice.

+ +

So, at the end of the day, virtual machines are pets, and the containers are cattle. And when containers start acting up, you kill them. And you take them to the meat factory, and you go get another one. And so this provides a ton of value from a software development and an ops perspective because anytime you have a problem, you just kill your containers, start new ones, and you're off to the races again.

+ +

And it significantly reduces the troubleshooting time when you're having problems. Obviously, you probably want to log things and check into things; why did that happen? So that maybe you can go make a fix in your software. But at the end of the day, you want to keep your ops running. Containers are a great way to do that without having to be up at midnight figuring out why the virtual machine is acting up.

+ +

And so the difficulty with cattle is they like to graze and wander and break through fences and things like that. And mostly, when you have an enterprise software application or even just a startup with an MVP, you probably have multiple containers that you need to run and build this application. And so you need somebody to orchestrate. You need somebody to wrangle your containers.

+ +

And so Kubernetes, I like to say, is like cowboys. Like, they're the ones that wrangle your cattle and make sure they're all going in the right direction and doing the right things. And so it just makes natural sense. Like, if you have a bunch of cattle, you need somebody to take care of them, so that's what Kubernetes does.

+ +

JOE: Yeah, just to add to that, one of the things I really like about Kubernetes is that it's declarative versus prescriptive. So if you look at a lot of the older DevOps tools like Chef, things like that, you're effectively telling the machine what you want it to do to end up with a particular deployment. With containers, you'd say, start this number of containers on this node. Start this number of containers on this node. Add a virtual machine with these. Whereas with Kubernetes, you state the way you would like the world to be, and then Kubernetes' job is to make the world like that.

+ +

So from a developer's perspective, when they're deploying things, they don't actually usually want to think in terms of the steps involved between I push this code, and somebody can use it. What they want us to say is I want this code running in containers, and I would like it to have this configuration. I would like it to have these ports exposed. And I love that Kubernetes, to a pretty good extent, abstracts away all of those steps and just lets you say what you want.

+ +

DOMINIC: Yeah, that's a lot of the power in Kubernetes. You just say, "This is what I want, and then make it so." And Kubernetes goes out and figures out where it's going to schedule your container on what node or server if it dies. Kubernetes is like; I'm pretty sure you wanted one of those running, so I'm going to run it again. It just handles a lot of those things for you that previously you would need somebody with a pager to call to fix. And Kubernetes is automating a lot of that deployment and maintenance for you.

+ +

VICTORIA: Right. And it seems like there's the movement to really coalesce around Kubernetes. I wonder if either of you can speak to the healthiness of the ecosystem for Kubernetes, which is open source, and why you chose to build on it.

+ +

DOMINIC: So there was sort of a bit of a container orchestration war for a while. There was a bunch of different options. And I'm not saying that a lot of them weren't good options. Like, Docker built a capability called Swarm, and it's fairly simple to use and pretty powerful. But there was just a lot of backing from the open-source community behind Kubernetes when Google made it an open-source project. There were other things sort of like Kubernetes but not really like Mesos. And they all had like this huge bloodbath to see who was going to be the winner. And I just feel like Kubernetes kind of pulled ahead.

+ +

It was a really smart move from Google to make it open-source and get the open-source community's buy-in to use. And it just became a very powerful but complex tool for running your software in production. Google had been using some form of that called Google Borg for a number of years prior. And I'm guessing they're still quite a bit different. But that's how it kind of came about. Do you have anything to add, Joe?

+ +

JOE: I'd say that I judge the winner or the health of an ecosystem by the health of the off-the-shelf and open-source software that can run on that system. So Kubernetes is a thing that you use yourself. You build things to run on it. But also, you can pick and choose many things from the community that people have already built. And there is a huge open-source community for components that run on Kubernetes, everything from CI/CD to managing databases to doing interesting deployment styles like canary deployments. That's really healthy.

+ +

It just didn't happen with the other systems like Swarm or Nomad was another one. And most of the other companies that I saw doing container orchestration eventually just changed to doing their flavor of Kubernetes, like Rancher. I forget what their original platform was called. But their whole thing was based on that cattle metaphor. [chuckles] And they took a pretty similar approach to containers. And now, if you ask somebody what Rancher is, they'll tell you it's a managed Kubernetes platform.

+ +

DOMINIC: Yeah, I think it's called Longhorn, so they very much have the cattle theme in there. I mean, they're literally called Rancher, so there you go. But yeah, at the end of the day, something is going to come after Kubernetes as well. And I like to think that it's not so much a matter of what's going to be next? Is there going to be something beyond containers or container orchestrators like Kubernetes?

+ +

I just think there are going to be more and more layers of abstraction because, at the end of the day, look at the advent of things like ChatGPT and generative AI. People just want to get their jobs done more efficiently and faster. And in software, there's just a lot of time and money that goes into getting software running and keeping it running, and that's why Kubernetes makes sense. But then there's also a lot of time that goes into Kubernetes.

+ +

And so we think that harpoon is just sort of the natural next layer of abstraction that's going to live on as the next thing. So if 15 years ago I told you I was going to build a web application and I was going to go run it in the cloud, maybe you would have said, "You're crazy, Dom. Like, how could you trust this guy, Jeff, with all your software? What if he is going to steal it? And what if he can't run a data center? What then?"

+ +

And now, if I told you I was going to go build a data center because I want to build a web application, you would look at me like I was a pariah and that I was not fit to run a company and that I should just use the cloud. So I think it's the same process. We're going to go with containers and Kubernetes. And software deployment, in general, is going to be an abstraction layer that lives on top of all that because software developers and companies just want to push out good software to end users. And any sort of way to make that more efficient or more fun is going to be embraced eventually.

+ +

JOE: Yeah, I agree with that. I hear people ask, "What are you going to do when Kubernetes is obsolete?" pretty often. And I think it's achieved enough momentum that it won't be. I think it'll be what else is built on top of Kubernetes? Like, people talk about servers like they're obsolete, but they're not; there are still servers. People are just running virtual machines on them. And virtual machines are not obsolete. We'll just run containers on them. So once we get beyond the layer of worrying about containers, you'll still need a container platform. And based on the momentum it's achieved, I think that platform is going to be Kubernetes.

+ +

VICTORIA: Technology never dies. You just get more different types of technology. [laughs] Usually, that's my philosophy on that.

+ +

DOMINIC: Yeah, I mean, there's never been a better time to be a software developer, especially if you're an entrepreneur at the same time, because that's what happens over time. Like, what we're achieving with web applications today and what you can push out to the internet and kind of judge if there's a market for would have been unimaginable 20 years ago because, again, you would have had to build a data center. [laughs] And who has a bunch of tens of millions of dollars sitting around to do that?

+ +

So now you can just use existing software from other people and glue it together. And you can use the cloud and deploy your software and get it out to the masses and scale it. And it's an amazing time to be alive and to be building things for people.

+ +

VICTORIA: Right. And you mentioned a few things like artificial intelligence before, and there are a lot of people innovating in that space, which requires a lot of data, and networking, and security, and other types of things that you want to think about if you're trying to invent that kind of product. Which brings me to a question I have around, you know when you're adding that abstraction layer to these Kubernetes clusters, how does that factor into security compliance frameworks? And does that even come up with the customers who want to use your product?

+ +

DOMINIC: Yeah. I mean, definitely, people are concerned about security. When we do infrastructure as code for your virtual infrastructure that's running your Kubernetes cluster that we deploy for you, certainly, we're using best practices from a security standpoint. We do all the same things. If we're building out custom scripts for some clients somewhere, we'd want it to be secure. And we want to lock down different aspects of components that we're building and not just expose all the ports on maybe a load balancer and things like that.

+ +

So by default, we try to build in as much security as we can. It's pragmatic. I think ultimately we'll probably go down to the path of SOC 2 compliance, and then anything that goes on top of a harpoon cluster or that is deployed with harpoon will be SOC 2 compliant to a large degree. And so yeah, I mean, security is definitely a part of it. We're currently building in a lot of other security features, too, like role-based access control and zero trust, which we'll have pretty soon here.

+ +

So, yeah, if you want to build your software and get it deployed, you want it to be scalable, and you also want it to be secure. There are so many ilities that come into deploying software. But to your point, even on the artificial intelligence side, people are looking for easier ways to abstract away the complexity. Like, if I told you to go write me a blog post with either ChatGPT or go build your own generative AI model and use that, then you're probably going to be like, yeah, I'll just go to the OpenAI website. I'll be back in a minute.

+ +

And that's why also you see things like SageMaker from AWS. People want abstraction layers. They want easier ways to do things. And it's not just in DevOps; it's in artificial intelligence and machine learning. That's why drag-and-drop editors are becoming more popular in building web applications mobile applications. I think all of this software development stuff is going to be really accessible to a much larger community in the near future.

+ +

VICTORIA: Yeah, wonderful. That's great. And so, Dominic, any final takeaways for our listeners today?

+ +

DOMINIC: Definitely, if you have interest in how either harpoon or Kubernetes, in general, might be applicable to you and your company, we're a bunch of friendly people over here. Even if you're not quite sure how to get started or you need advice on stuff, definitely go hit us up on our website or hit up support at harpoon.io, and send us a message.

+ +

We're very open to helping people because, again, what we're really trying to do is make this more accessible to more people and make more people successful with this technology. So if we have to get on a bunch of phone calls or come sit next to you or do whatever else, we're here to be a resource to the community, and harpoon is for you to get started. So don't feel like you need a bunch of money to get started deploying with Kubernetes and using the platform.

+ +

VICTORIA: That's a great note to end on.

+ +

So you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Dominic Holt.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dominic Holt is CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds.

+ +

Victoria talks to Dominic about commoditizing DevOps as a capability, coming up with the idea for drag and drop just thinking through how he could do these things in a visual and intuitive way, and using Kubernetes as a base for Harpoon.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dominic Holt, CEO of harpoon, a drag-and-drop Kubernetes tool for deploying any software in seconds. Dominic, thank you for joining me.

+ +

DOMINIC: Yeah, of course. Thanks for having me, Victoria.

+ +

VICTORIA: Yes, I'm really excited to talk all about what Kubernetes is. And I have Joe Ferris, the CTO of thoughtbot, here with me as well to help me in that process.

+ +

JOE: Hello.

+ +

VICTORIA: Excellent. Okay, so, Dominic, why don't you just tell me how it all got started? What led you to start harpoon?

+ +

DOMINIC: I got into the DevOps space fairly early. It was, I don't know, probably 2012 timeframe, which sounds like not that long ago. But, I mean, DevOps is also still a baby. So I have a software background. And I was starting to figure out how to do the continuous; I guess, automated way of standing up cloud infrastructure for Lockheed Martin at the time because people didn't know how to do that. There weren't a lot of tools available, and nobody knew what DevOps was. And if you said it to somebody, they would have slapped you.

+ +

VICTORIA: Aggressive. [laughs]

+ +

DOMINIC: [laughs] Maybe not, maybe not. Maybe they'd be nicer about it. But anyway, nobody knew what DevOps was because it wasn't coined yet. And I started realizing that this was not some system administration voodoo. It was just common sense from a software development standpoint. And I ended up leaving Lockheed shortly thereafter and going and working for a small business here in San Diego. And I said, I have no idea what any of this stuff is, but we're going to do it because, in a few years, everybody's going to be doing it because it's common sense. So we did.

+ +

We grew quite a large practice in consulting and DevOps, among other things. And predominantly, I was working with the U.S. Navy at the time, and they needed a standardized way to deploy software to aircraft carriers and destroyers, the ships out there in the ocean. And so, I came up with a design for them that used Kubernetes. And we built a pipeline, a CI/CD pipeline, to automatically deploy software from the cloud to Navy ships out in the ocean on top of Kubernetes. And everything worked great. And it was there, and we tested it.

+ +

But at the end of the day, handing over the maintenance, what we call day two ops, proved to be troubling. And it never quite made it onto the ships in the way that we wanted. So after that, I did a bunch of consulting with other groups in the Navy, and the Air Force, and Space Force, and all kinds of different groups across the government. And I also started consulting in commercial, fortune 500, startups, everything.

+ +

And I just saw that this problem was really pervasive, handling the day two operations. You get everything up and running, but then maintaining it after that was just complicated for people because all of the DevOps implementations are snowflakes. So if you go from Company A to Company B, they look nothing alike. And they may have a lot to do with somebody named Jim or Frank or Bob and how they thought was the best way to do it.

+ +

And so, running a DevOps consultancy myself, I just knew how hard it was to find the talent, and how expensive they were, and how hard it was to keep them because everyone else was trying to hire my talent all the time. And I just thought to myself, all of this is completely untenable. Somebody is going to commoditize DevOps as a capability. And what would that look like?

+ +

VICTORIA: Right. I'm familiar with the demand for people who know how to build the infrastructure and systems for deploying and running software. [laughs] And I like how you first talked about DevOps, just it being common sense. And I remember feeling that way when I went to my first DevOps DC meetup. I was like, oh, this is how you're supposed to build teams and organizations in a way to run things efficiently and apply those principles from building software to managing your infrastructure.

+ +

DOMINIC: Yeah. Well, I had lived the life of an enterprise software developer for quite a while before then. And I had gone through that whole process they talk about in all of DevOps bibles about why it is we're doing this, where the software development team would have their nice, fancy dev laptops. And the operations team with the pagers or whatever would be the ones managing the servers. And the software developers were never really sure exactly how it was going to work in production, but were like; I'm just going to throw it over the fence and see what the ops people do.

+ +

And inevitably, the ops people would call us very angrily, and they would say, "Your software doesn't work." And then, of course, we would say that the ops people are all crazy because it works just fine here on my laptop, and they just don't know what they're doing. And, I mean, we would just fight back and forth about this for six months until somebody figured out that we were running the wrong version of some dependency in the software on the ops side, and that's why it didn't work. So that process is just crazy, and nobody in their right mind would want to go through it if they could avoid it.

+ +

VICTORIA: Right. I'm sure Joe has had some stories from his time at thoughtbot.

+ +

JOE: Yeah, certainly. I was interested by what you said about working with...I think it was Frank, and Ted, and Bob. I've definitely worked with all those people in their own snowflakes. And one of the things that drew me to Kubernetes is that it was an attempt to standardize at least some of the approaches or at least provide anchor points for things like how you might implement networking, and routing, and so on.

+ +

I'm interested to hear, you know, for a drag-and-drop solution, even though Kubernetes was meant to standardize a lot of things, there are a lot of different Kubernetes distributions. And I think there are still a lot of Kubernetes snowflakes. I'm curious how you manage to tackle that problem with a drag-and-drop solution to hit the different Kubernetes distributions out there.

+ +

DOMINIC: Yeah, I mean, I think you nailed it, Joe. Standing up Kubernetes is a little bit complicated still these days. It's been made a lot easier by a lot of different companies, and products, and open-source software, and things like that. And so I see a lot of people getting up basic Kubernetes clusters these days. But then you look at companies like ARMO that are doing compliance scans and security scans on Kubernetes clusters, and they're making the claim that 100% of the Kubernetes clusters they scan are non-compliant [laughs] and have security issues.

+ +

And so that just goes to show you all of the things that one has to know to be successful just to stand up a cluster in the first place. And even when I...like for a client or something, over the years, if I was standing up a Kubernetes cluster and a lot of it was automated, you know, we used Terraform and Ansible, and all the other best practices under the hood. A lot of the response I got back when we handed over a cluster to a client was, "Okay, now what?"

+ +

There are still a lot of things you have to learn to maintain that cluster, keep it up to date, upgrade the underlying components of the cluster, deploy the software, configure the software, all those things. And can you learn these things? Absolutely. Like, they're not rocket science, but they're complicated. And it is a commitment that you have to make as an individual if you're going to become proficient in all of these things and managing your own cluster.

+ +

And so we were just...we had done this so many times at different companies I had worked with, for different clients, and seeing how all of the different pieces work together and where clients were having problems and what really hung people up. And so I just started thinking to myself, how would you make that easier? How would you make that more available to the pizza guy or an 18-year-old with no formal training that's on a ship in the ocean? And that's why I came up with the idea for drag and drop, just thinking through how can I do these things in a visual way that is going to be intuitive for people?

+ +

VICTORIA: Well, I have, obviously, a very thorough understanding of Kubernetes, [laughs] just kidding. But maybe explain a little bit more about to a founder why should they invest in this type of approach when they're building products?

+ +

DOMINIC: So I think that's a great question. What I find these days is DevOps is almost a requirement to do business these days in some sort of nimble way. So you have to...whether you're a large enterprise or you're a garage startup, you need to be able to change your software to market forces, to stuff that's happening in the news, to your customers don't like something. So you want to change it to something else quickly or pivot because if something happens, you can get your day in the sun, or you can capitalize on something that's happening.

+ +

And so the difficulty is I think a lot of people have an impression that DevOps scripts are sort of like a build once and forget type of thing, and it'll just work thereafter. But it's actually software, and I like to think of software as living organisms. You have to take care of them like they're people, almost because if you don't, they'll become brittle and unhealthy over time. If you have a child, you have to feed them probably multiple times a day, brush their teeth. You got to tuck them in at night. You have to be nice to them. You have to do all the things that you would do with a child.

+ +

But with software as well, if you just take the quick route, and quick fix things, and hack, and take shortcuts, eventually, you're going to have a very unhealthy child on your hands, and they're going to have behavior problems. At the end of the day, you have all these DevOps scripts, and they can be quite complex together. And you have to take care of them like they're your own child.

+ +

And the problem is you're also taking care of your software products like it's your child. And so now you're taking care of two children. And as somebody that has two children, I can tell you that things become much more complicated when two children are having behavioral problems than just one. And you're at the store, and it's very embarrassing.

+ +

So I guess the point is that harpoon is a capability that can basically take care of your second child for you, which is your DevOps deployments. And then you can just focus on the one child that you, I mean, this is turning into a terrible analogy at this point. [laughter] But you should love all of your children equally. But, in this case, you're looking to take care of your products and get it out there, and harpoon is something that can take care of your DevOps software for you.

+ +

VICTORIA: I agree. I think when your software or children are problematic, it's more than just embarrassing sometimes. It can create a lot of financial and legal liability as well. From your research, when you're building this product and, like, who's going to be interested in buying this thing, is that something that people are concerned about?

+ +

DOMINIC: Yeah, absolutely. I mean, the fact that we can stand up your cluster for you, stand up all of your cloud infrastructure for you, and then dynamically generate all of the configuration as code as well, and how to open those things securely up to the network and control everything such that you're not going to accidentally do something that's really bad, can definitely help out a lot of people.

+ +

The interest has been really overwhelming from so many different groups and organizations. We have people that are interested in the Department of Defense in both the U.S. and other countries. We have fortune 500 companies that see this as a pathway to accelerate digital transformation for legacy applications or even to use it as a sandbox, so people aren't bugging Frank, and Joe, and Bob, who run the Kubernetes clusters in production.

+ +

We have startups who see it just as a way to skip over the whole DevOps thing and work on getting a product-market fit so that they have a production environment that just works out of the box. So it's been really interesting seeing all the different use cases people are using harpoon for and how it's helped them in some way get to some and realize some goal that they have.

+ +

JOE: I'm curious if it's been a challenge as somebody managing the underlying infrastructure as sort of a plug-and-play thing. One experience I've had working more on the operations side of DevOps is that everything becomes your problem. Like, if the server misbehaves, if there's a database crash, whatever, certainly, that's your problem. But also, if the application is murdering your database, that becomes your problem. And it's really an application problem. But it surfaces visibly in the infrastructure when the CPU spikes and it stops responding to requests. And so, how do you navigate that agreement with your users? How do you balance what's your responsibility versus theirs to not kill the cluster?

+ +

DOMINIC: One thing that's great about Kubernetes and why it's a great base for our product is that Kubernetes is really good at keeping things running. Certainly, there are catastrophic things that can happen, like an entire region of EC2 and Amazon Web Services goes down. And that is, obviously, if you have your clusters only running in that particular region, you're going to have a bad day.

+ +

So there are things beyond our control. I mean, those things are also covered by the service-level agreement, the SLA with AWS, since you're using your own AWS account when you're utilizing harpoon. So it's like a hybrid SaaS where we deploy everything into your account, and you own it. And you can adjust those infrastructure things on your own as you'd like. So from that standpoint, you're kind of covered with your agreement with AWS as an example of a cloud service provider.

+ +

And certainly, Kubernetes also kind of knows what to do in some of those instances where you have a container that is murdering everything. In a lot of cases, it can be configured to, you know, just die or go into a CrashLoopBackOff or something if it's just taking up all your resources in the cluster versus destroying your entire cluster in a great fireworks display. So we put some of those protections into the platform as well.

+ +

But yeah, to your point, being an ops person is a difficult job because we're usually the ones [laughs] that get blamed for everything when something bad happens, even though sometimes it's the software team's fault or sometimes it's even just the infrastructure you're built on. Occasionally, AWS services and Google Cloud and Azure services do go down, and things happen.

+ +

We've had instances, even during harpoon development, where we're testing harpoon late at night on AWS, and sometimes AWS does wonky things at night that people don't realize. It's not completely perfect capability. And we're like, oh, why does it only happen at 11:58 on Tuesdays? Oh, because AWS updates their servers during that time, and it slows down everything.

+ +

It's still good to understand all the underlying components and how they work, and that could certainly help you regardless of if you use harpoon or not. But ultimately, we're just trying to make it easier for people. They can spend less time focusing on those things. We can help them with a lot of those problems that might occur, and they can focus on their software.

+ +

VICTORIA: Great. I think that's...it's interesting to me to always hear about all the different challenges in managing operations of software. So I like that you're working on this space. It's clearly a space that needs more innovation, you know, we're working on it here at thoughtbot as well. Has there been anything in your, like, any theory that you had going into your initial research that when you talked to customers surprised you and caused you to change your direction?

+ +

DOMINIC: Yeah. I mean, we run the gamut there. So we did a lot of early customer discovery to try to figure out who might be interested in this product. And so, our first thought was that startups would be the most interested in this product because they're building something new. They just want to get it out there. They want to build their MVP, and they just want to throw it on the internet and get it rolling and not have to worry about whether the software is up and down while they're doing a bunch of sales calls. Because really, during the MVP phase, if you're doing lean startup-style company development, then you really just want to be selling. You want to always be selling.

+ +

And so we thought it would just be a no-brainer for startups. And we talked to a lot of startups, and some startups for sure thought it was valuable. But a lot of them were like, "Yeah, that's cool, but we don't care about DevOps. [chuckles] We don't care about anything. Like, I'll run it on my laptop if I have to. The only thing I care about is finding product-market fit and getting that first sale." And so, at least as far as the very first customers that we were looking for, they weren't the best fit.

+ +

And then we went and talked to a bunch of mid-market companies because we just decided to go up to the next logical level. And so mid-market companies were very interested because a lot of them were starting to eyeball Kubernetes and maybe sort of migrate some of their capabilities over there. Maybe they had a little bit of ability to be a bit nimble, in that sense, versus some of the enterprise customers. And so they were very interested in it. But a lot of them were very risk averse, like, go find a bunch of enterprise customers that will buy it, and then we'll buy it. And so then we went to talk to the enterprise customers.

+ +

And that was sort of like an eye-opening time for us because the enterprise customers just got it. They were like, "Yeah, I'm trying to migrate legacy capabilities we built 10 or 15 years ago to the cloud. We're trying to containerize everything and refactor our existing software. I got to redesign the user interface that was built ten years ago." And if somebody's got a DevOps easy button, then sign me up. I would like to participate because I can't spell Kubernetes yet, but I definitely know what it is, and I want to use it.

+ +

So working with the enterprise customers was really great for us because it showed us what the appetite was in the market and who was going to immediately benefit from it. And then, ultimately, that rolls down to the mid-market companies. And maybe later-stage startups as well are starting to find a lot of value in the platform from, you know, have maybe started finding some product-market fit and care a little bit about whether people can access my software and it's maintainable and available. And so we can definitely help with that.

+ +

VICTORIA: That's super interesting, and it aligns with my experience as well, coming from consulting companies and the federal government who are working on digital services, and DevOps, and agile, and all of those transformational activities. And so it's been five years, it looks like since you started harpoon. What advice would you give to yourself if you could travel back in time when you were first starting the project?

+ +

DOMINIC: So I made lots of mistakes along the way. I'll inevitably make more. But when I first started building this thing, I wasn't even sure how it was going to work. Kubernetes can be a bit of a fickle beast, and it wasn't really built to have a drag-and-drop UI on top of it. And so there are lots of things that could go wrong, trust me, [laughs] I learned them. But building an initial prototype, like, the very base of can the capability work at all, came together pretty quickly. It was maybe three or four months of development during my nights and weekends. And building an enterprise scalable product took quite a bit longer.

+ +

But once I had an initial capability, I was very excited because, again, I didn't even know if this was possible, certainly not five or six years ago. So I didn't even really want to raise a round or make money. I do know how venture capital works. So it wasn't even my expectation that people would want to give me money because all I had was an MVP and no product-market fit. And I had just thrown it together in three or four months. But I was just excited about it.

+ +

I'm a software developer at heart, and technology excites me. And solving problems is kind of what gets me up in the morning. So I just called all the people I knew, a bunch of VCs, other people, and they're like, "Yeah, I would like to see that. Let's set up a time." And so I think maybe they interpreted that as, like, I want to do a pitch to you for money. [laughs] And I just proceeded to go to, like, this dog and pony show of showing a bunch of people this thing I built, and I thought they would just understand it and get what I was doing.

+ +

And I just proceeded to get my ass handed to me over and over and over again. Like, "This isn't that great of a product. How much money are you making?" Blah, blah, blah, blah. I'm like, "No, no, you don't get it. I just started. It's just a prototype at this stage. It's not even a finished product." And they're like, "Well, you're definitely going to fail. [laughter] You're wasting your time. What are you even doing here?"

+ +

And so that was...I like to think that I have thick skin, but that's hard to hear as an entrepreneur; just people don't get your vision. They don't understand what it is you're building and why it's going to be valuable to people. And it could be a long time before you get to a point where people can even understand what it is you're doing, and you just have to sort of stay the course and, I mean, I did. I went around on some rock somewhere and hung out in a tent on an island for a while. I just kept going.

+ +

And you just got to pour all your heart and soul, and effort into building a product if you want to make it exist out there in the world. And a lot of people are not going to get it, but as long as you believe in it and you keep pushing, then maybe someday they will get it. For the first year after we had a working enterprise-grade product, we kind of did a soft launch. And we had a small set of customers. We had 8 to 10 people that were sort of testing it out and using it, things like that.

+ +

We kind of went, you know, more gangbusters launch at the end of last year, and it was crazy. And then...what? I don't know, maybe 60 days since we did a more serious launch. And we have gone from our ten soft users to 2,000 users.

+ +

VICTORIA: Wow. Well, that's great growth. And it sounds exciting that you have your team in place now. You're able to set yourself up for growth.

+ +

Mid-Roll Ad:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: url tbot.io/devops

+ +

VICTORIA: So now that you're getting more established, you're getting more customers, you have a team supporting you on the project; what parts of the DevOps culture do you feel like are really important to making a team that will continue to grow?

+ +

DOMINIC: I've been an individual contributor for a long period of time. I was a first-level manager and managed people. At a very granular personal level, I've been a director, and a VP, and a CTO at a bunch of different places. And so all of those different roles and different companies that I've worked at have taught me a lot about people, and teams, and culture, and certainly about hiring.

+ +

I think hiring is the absolute most important thing you can do in a company, and definitively in a software company. Because there are just certain people that are going to mesh well with your culture, and the people that do and that are driven and passionate about what they do, they're just going to drive your company forward. And so I just spend a lot of my time when we need to grow as a company, which happens here and there, really focusing on who is going to be the best next person to bring on to the company.

+ +

And usually, I'm thinking about this far in advance because whenever we do need that person, I don't want to have to start thinking about it. I want to just know, like, it is Frank, it is Bob, it is Jamey, or Alex, or whoever else. Because it is...at a personal level, there has to be people who are very aligned with your visions, and your values, and your culture, and they care and are going to push the company forward.

+ +

And if you're just hiring people with a quick coding interview and a 30-minute culture fit session, you're going to make a lot of hiring mistakes. You're going to find people who are just looking for a nine-to-five or things like that, and, I mean, there's nothing wrong with that. But in a startup especially, you really need people who buy into the vision and who are going to push the thing forward.

+ +

And I'm looking for people who just care, like; they have an ownership mentality. Maybe in a different lifetime or a different part of their career, they'd be an entrepreneur at their own company. But you just give them stuff, and they're like, cool, this is mine. I'm going to take care of this. It's now my child. I will make sure that it grows up and it is healthy and goes to a good university. Those are the type of people that you want in your company, people that you would trust with your children. So those are the criteria for working at harpoon, I guess.

+ +

VICTORIA: Yeah, that's good. So what does success look like in the next six months or even beyond the next five years?

+ +

DOMINIC: I think it's still very early market for us. Certainly, we have an explosive growth of users using the platform, and that's really heartening to see. That's really awesome that people want to use the thing that you built. But again, there are so many companies out there and organizations that are still not even doing DevOps. They're just doing manual deployments, maintaining clusters manually, not using containers or Kubernetes. Not to say that you have to use these things and that they're a panacea, and they work in every sense because they don't.

+ +

But obviously, there's been a major shift in the industry towards containers and container orchestration like Kubernetes. Even some of the serverless platforms that people like to use are actually backed by Kubernetes, so you see a major shift in that direction. But there are still so many different companies and organizations that, again, are still locked into legacy ways of doing things and manually doing things.

+ +

There are companies that are trying to get their products off the ground, and they're looking for faster and easier, and cheaper ways to do that. And I think that's what's really exciting about harpoon is we can help these companies. We can help them be more successful. We can help them migrate to things that are more modern and agile. We can help them get their product off the ground faster or more reliably. And so that's kind of what excites me.

+ +

But you know what? We do a lot of demos, you know, sales demos and things like that. And, really, we don't have PowerPoints. We're just like, cool, this is the app, and this is how you use it. And it is so simplistic to use, even though Kubernetes is quite complicated, that the demo goes pretty quick. We're talking five, six minutes if there are not a lot of questions. And we always get exactly the same response, whether somebody is not super familiar with Kubernetes or they are familiar with Kubernetes, and they've set up their own cluster. It's almost always, "Wow," and then a pause, and then "But how do I know it works?" [laughs]

+ +

So there's going be a lot of work for us in educating people out there that there is an easier way to do DevOps now, that you can do drag and drop DevOps and dynamically generate all of your scripts and configuration, and open up networks, and deploy load balancers, and all the other things that you would need to do with Kubernetes, literally in a few minutes just dragging and dropping things. So there's going to be a lot of education that just goes into saying, "Hey, there's a new market, and this is what it is. And this is how it compares to the manual processes people are using out there. Here's how it compares to some of the other tools that are more incremental in nature."

+ +

And trust, you know, over time, people are going to have to use the platform and see that it works and talk to other people and be like, yeah, I deployed my software on harpoon, and nothing terrible happened. Demons didn't come out of the walls, and my software kept running, and no meteors crashed in my house. So it's just going to take some time for us to really grow and build the education around that market to show that it's possible and that it exists, and it can be an option for you.

+ +

VICTORIA: Right. I used to do a lot of intro to DevOps talks with Women Who Code and DevOps DC. And I would describe Kubernetes as a way to keep your kubes neat, and your kube is where your software lives. It's a little house that keeps the doors locked and things like that. Do you have another way to kind of explain what is Kubernetes? Like, how do you kind of even just get people started on what DevOps is?

+ +

DOMINIC: I like to usually use the cattle story. [laughs] So, in DevOps, they have these concepts of immutable infrastructure or immutable architecture. And so when you have virtual machines, which is what people have been running on for quite a while, certainly some people still run on bare metal servers, but pretty much everybody's got on board with virtualization at this point, and so most software these days is at least running on virtual machines. And so the difficulty with virtual machines is, I mean, there's nothing wrong with them, but they're kind of like pets. They exist for long periods of time. They have what we call state drift, and that's just the changing of the data or the state of the virtual machine over time.

+ +

And even if I were to kill off that virtual machine and start another one, it wouldn't be exactly the same one. It wouldn't be, you know, fluffy. It would be a clone of fluffy. And maybe it wouldn't have the same personality, and it wouldn't do exactly the same things. And sometimes that might be good; maybe fluffy was a terrible dog. But in other cases, you're like, oh crap, I needed that snowflake feature that Bob built three years ago. And Bob has been hit by a train, so people can't ask Bob anymore.

+ +

And so what then really happens at these organizations is when the virtual machines start acting up, they don't kill them. They take them to the vet. They take care of them. They pet them. They tell them they're a good boy. And you have entire enterprises that are super dependent on these virtual machines staying alive. And so that's no way to run your business. And so that's one of the reasons why people started switching over to containers because the best practices in containers is to build software that's immutable.

+ +

So if you destroy or kill one of your containers, you can start another one. And it should work exactly the same as before, and that's because when you build your containers, you can't change them unless you rebuild them. I mean, there are ways to do it, but people will wave their finger angrily at you if you try to do that because it's not a best practice.

+ +

So, at the end of the day, virtual machines are pets, and the containers are cattle. And when containers start acting up, you kill them. And you take them to the meat factory, and you go get another one. And so this provides a ton of value from a software development and an ops perspective because anytime you have a problem, you just kill your containers, start new ones, and you're off to the races again.

+ +

And it significantly reduces the troubleshooting time when you're having problems. Obviously, you probably want to log things and check into things; why did that happen? So that maybe you can go make a fix in your software. But at the end of the day, you want to keep your ops running. Containers are a great way to do that without having to be up at midnight figuring out why the virtual machine is acting up.

+ +

And so the difficulty with cattle is they like to graze and wander and break through fences and things like that. And mostly, when you have an enterprise software application or even just a startup with an MVP, you probably have multiple containers that you need to run and build this application. And so you need somebody to orchestrate. You need somebody to wrangle your containers.

+ +

And so Kubernetes, I like to say, is like cowboys. Like, they're the ones that wrangle your cattle and make sure they're all going in the right direction and doing the right things. And so it just makes natural sense. Like, if you have a bunch of cattle, you need somebody to take care of them, so that's what Kubernetes does.

+ +

JOE: Yeah, just to add to that, one of the things I really like about Kubernetes is that it's declarative versus prescriptive. So if you look at a lot of the older DevOps tools like Chef, things like that, you're effectively telling the machine what you want it to do to end up with a particular deployment. With containers, you'd say, start this number of containers on this node. Start this number of containers on this node. Add a virtual machine with these. Whereas with Kubernetes, you state the way you would like the world to be, and then Kubernetes' job is to make the world like that.

+ +

So from a developer's perspective, when they're deploying things, they don't actually usually want to think in terms of the steps involved between I push this code, and somebody can use it. What they want us to say is I want this code running in containers, and I would like it to have this configuration. I would like it to have these ports exposed. And I love that Kubernetes, to a pretty good extent, abstracts away all of those steps and just lets you say what you want.

+ +

DOMINIC: Yeah, that's a lot of the power in Kubernetes. You just say, "This is what I want, and then make it so." And Kubernetes goes out and figures out where it's going to schedule your container on what node or server if it dies. Kubernetes is like; I'm pretty sure you wanted one of those running, so I'm going to run it again. It just handles a lot of those things for you that previously you would need somebody with a pager to call to fix. And Kubernetes is automating a lot of that deployment and maintenance for you.

+ +

VICTORIA: Right. And it seems like there's the movement to really coalesce around Kubernetes. I wonder if either of you can speak to the healthiness of the ecosystem for Kubernetes, which is open source, and why you chose to build on it.

+ +

DOMINIC: So there was sort of a bit of a container orchestration war for a while. There was a bunch of different options. And I'm not saying that a lot of them weren't good options. Like, Docker built a capability called Swarm, and it's fairly simple to use and pretty powerful. But there was just a lot of backing from the open-source community behind Kubernetes when Google made it an open-source project. There were other things sort of like Kubernetes but not really like Mesos. And they all had like this huge bloodbath to see who was going to be the winner. And I just feel like Kubernetes kind of pulled ahead.

+ +

It was a really smart move from Google to make it open-source and get the open-source community's buy-in to use. And it just became a very powerful but complex tool for running your software in production. Google had been using some form of that called Google Borg for a number of years prior. And I'm guessing they're still quite a bit different. But that's how it kind of came about. Do you have anything to add, Joe?

+ +

JOE: I'd say that I judge the winner or the health of an ecosystem by the health of the off-the-shelf and open-source software that can run on that system. So Kubernetes is a thing that you use yourself. You build things to run on it. But also, you can pick and choose many things from the community that people have already built. And there is a huge open-source community for components that run on Kubernetes, everything from CI/CD to managing databases to doing interesting deployment styles like canary deployments. That's really healthy.

+ +

It just didn't happen with the other systems like Swarm or Nomad was another one. And most of the other companies that I saw doing container orchestration eventually just changed to doing their flavor of Kubernetes, like Rancher. I forget what their original platform was called. But their whole thing was based on that cattle metaphor. [chuckles] And they took a pretty similar approach to containers. And now, if you ask somebody what Rancher is, they'll tell you it's a managed Kubernetes platform.

+ +

DOMINIC: Yeah, I think it's called Longhorn, so they very much have the cattle theme in there. I mean, they're literally called Rancher, so there you go. But yeah, at the end of the day, something is going to come after Kubernetes as well. And I like to think that it's not so much a matter of what's going to be next? Is there going to be something beyond containers or container orchestrators like Kubernetes?

+ +

I just think there are going to be more and more layers of abstraction because, at the end of the day, look at the advent of things like ChatGPT and generative AI. People just want to get their jobs done more efficiently and faster. And in software, there's just a lot of time and money that goes into getting software running and keeping it running, and that's why Kubernetes makes sense. But then there's also a lot of time that goes into Kubernetes.

+ +

And so we think that harpoon is just sort of the natural next layer of abstraction that's going to live on as the next thing. So if 15 years ago I told you I was going to build a web application and I was going to go run it in the cloud, maybe you would have said, "You're crazy, Dom. Like, how could you trust this guy, Jeff, with all your software? What if he is going to steal it? And what if he can't run a data center? What then?"

+ +

And now, if I told you I was going to go build a data center because I want to build a web application, you would look at me like I was a pariah and that I was not fit to run a company and that I should just use the cloud. So I think it's the same process. We're going to go with containers and Kubernetes. And software deployment, in general, is going to be an abstraction layer that lives on top of all that because software developers and companies just want to push out good software to end users. And any sort of way to make that more efficient or more fun is going to be embraced eventually.

+ +

JOE: Yeah, I agree with that. I hear people ask, "What are you going to do when Kubernetes is obsolete?" pretty often. And I think it's achieved enough momentum that it won't be. I think it'll be what else is built on top of Kubernetes? Like, people talk about servers like they're obsolete, but they're not; there are still servers. People are just running virtual machines on them. And virtual machines are not obsolete. We'll just run containers on them. So once we get beyond the layer of worrying about containers, you'll still need a container platform. And based on the momentum it's achieved, I think that platform is going to be Kubernetes.

+ +

VICTORIA: Technology never dies. You just get more different types of technology. [laughs] Usually, that's my philosophy on that.

+ +

DOMINIC: Yeah, I mean, there's never been a better time to be a software developer, especially if you're an entrepreneur at the same time, because that's what happens over time. Like, what we're achieving with web applications today and what you can push out to the internet and kind of judge if there's a market for would have been unimaginable 20 years ago because, again, you would have had to build a data center. [laughs] And who has a bunch of tens of millions of dollars sitting around to do that?

+ +

So now you can just use existing software from other people and glue it together. And you can use the cloud and deploy your software and get it out to the masses and scale it. And it's an amazing time to be alive and to be building things for people.

+ +

VICTORIA: Right. And you mentioned a few things like artificial intelligence before, and there are a lot of people innovating in that space, which requires a lot of data, and networking, and security, and other types of things that you want to think about if you're trying to invent that kind of product. Which brings me to a question I have around, you know when you're adding that abstraction layer to these Kubernetes clusters, how does that factor into security compliance frameworks? And does that even come up with the customers who want to use your product?

+ +

DOMINIC: Yeah. I mean, definitely, people are concerned about security. When we do infrastructure as code for your virtual infrastructure that's running your Kubernetes cluster that we deploy for you, certainly, we're using best practices from a security standpoint. We do all the same things. If we're building out custom scripts for some clients somewhere, we'd want it to be secure. And we want to lock down different aspects of components that we're building and not just expose all the ports on maybe a load balancer and things like that.

+ +

So by default, we try to build in as much security as we can. It's pragmatic. I think ultimately we'll probably go down to the path of SOC 2 compliance, and then anything that goes on top of a harpoon cluster or that is deployed with harpoon will be SOC 2 compliant to a large degree. And so yeah, I mean, security is definitely a part of it. We're currently building in a lot of other security features, too, like role-based access control and zero trust, which we'll have pretty soon here.

+ +

So, yeah, if you want to build your software and get it deployed, you want it to be scalable, and you also want it to be secure. There are so many ilities that come into deploying software. But to your point, even on the artificial intelligence side, people are looking for easier ways to abstract away the complexity. Like, if I told you to go write me a blog post with either ChatGPT or go build your own generative AI model and use that, then you're probably going to be like, yeah, I'll just go to the OpenAI website. I'll be back in a minute.

+ +

And that's why also you see things like SageMaker from AWS. People want abstraction layers. They want easier ways to do things. And it's not just in DevOps; it's in artificial intelligence and machine learning. That's why drag-and-drop editors are becoming more popular in building web applications mobile applications. I think all of this software development stuff is going to be really accessible to a much larger community in the near future.

+ +

VICTORIA: Yeah, wonderful. That's great. And so, Dominic, any final takeaways for our listeners today?

+ +

DOMINIC: Definitely, if you have interest in how either harpoon or Kubernetes, in general, might be applicable to you and your company, we're a bunch of friendly people over here. Even if you're not quite sure how to get started or you need advice on stuff, definitely go hit us up on our website or hit up support at harpoon.io, and send us a message.

+ +

We're very open to helping people because, again, what we're really trying to do is make this more accessible to more people and make more people successful with this technology. So if we have to get on a bunch of phone calls or come sit next to you or do whatever else, we're here to be a resource to the community, and harpoon is for you to get started. So don't feel like you need a bunch of money to get started deploying with Kubernetes and using the platform.

+ +

VICTORIA: That's a great note to end on.

+ +

So you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Dominic Holt.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+SxJdkQZO + + ]]> + + Will Larry + Victoria Guido + Chad Pytel + Dominic Holt + + + 468: DiME with Jennifer Goldsack + https://podcast.thoughtbot.com/468 + 45b224d3-d153-4560-a542-64bf1a2fc0e6 + Thu, 30 Mar 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Jennifer Goldsack is CEO of Digital Medicine Society (DiMe), the professional home for digital medicine. It is a global nonprofit with a mission to advance the ethical, effective, equitable, and safe use of digital technology to redefine healthcare and improve lives. + +Victoria talks to Jennifer about using new products and solutions to solve some of the most pressing and persistent challenges in healthcare, measuring success by how well they are caring for people every day and not by how good their products or how many they use on any given day, and how DiME can improve the way that we identify, manage, cure, and support people in a lifetime journey of health and disease. + 51:14 + no + + + Jennifer Goldsack is CEO of Digital Medicine Society (DiMe), the professional home for digital medicine. It is a global nonprofit with a mission to advance the ethical, effective, equitable, and safe use of digital technology to redefine healthcare and improve lives. +Victoria talks to Jennifer about using new products and solutions to solve some of the most pressing and persistent challenges in healthcare, measuring success by how well they are caring for people every day and not by how good their products or how many they use on any given day, and how DiME can improve the way that we identify, manage, cure, and support people in a lifetime journey of health and disease. +Digital Medicine Society (DiMe) (https://dimesociety.org/) +Follow Digital Medicine Society (DiMe) on LinkedIn (https://www.linkedin.com/company/dime-society/about/?viewAsMember=true) or Twitter (https://twitter.com/_DiMeSociety). +Follow Jennifer Goldsack on LinkedIn (https://www.linkedin.com/in/jgoldsack/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jennifer Goldsack, CEO of Digital Medicine Society, the professional home for digital medicine. Jennifer, thank you for joining me. +JENNIFER: Thank you so much for having me; excited for our conversation today. +VICTORIA: Wonderful, me too. And we have our Program Manager for DEI Geronda with us today. Hello. +GERONDA: Hey, how's it going? I'm super excited to be on here as well. +VICTORIA: Yes, me too. It's going to be a great conversation. So, Jennifer, why don't you just tell me a little bit more about the Digital Medicine Society? +JENNIFER: Happy to, one of my favorite topics, Victoria. So the Digital Medicine Society, or as we affectionately refer to it as DiMe, is a global nonprofit, and our mission is to advance the ethical, effective, equitable, and safe use of digital technology to redefine healthcare and improve lives. +And I think one point I'd like to make right off the bat is while we are tech and digital enthusiasts here at DiMe, we are not tech determinists. What we think about is how can we harness the promise of these new digital tools in the toolbox, these new products, these new solutions, and how can we use them to solve some of the most pressing and persistent challenges in healthcare, an industry that exists to care for people? That's what we think about all day. That's our measure of success: how well are we caring for people every day, not how good are our products or how many products can we use on any given day. +VICTORIA: Right. So what did you see in the digital health space that led you to believe that something like DiMe needed to exist in the world? +JENNIFER: So it's interesting. When we take a step back and think about all the experts that need to be at the table to ensure that we build a field of digital health that is worthy of our trust, in our opinion here at DiMe, we think this is the most interdisciplinary field you can imagine, and that's a bold claim. But let me play it out for you. And maybe we can think about some other interdisciplinary fields during the course of our discussion. +For digital medicine to work, we need citizen scientists and cyber security experts. We need physicists, engineers, product folks, data scientists, clinical scientists, clinical care providers, healthcare executives, regulators, payors, investors, funders all to sit at the table together, all to speak a common unifying language, all to have a shared idea of what our North Star is. What are we trying to do here as we digitize healthcare, and what does good look like and for whom as we do it? +And so that's the gap that the Digital Medicine Society was introduced to fill. That water cooler, if you like, where the leaders in our field can share their expertise and where we can very intentionally build a much better future for healthcare using the new digital tools in our toolbox. +VICTORIA: Interesting. And I like how you pointed out for whom. [laughs] And I see digital equity is a big topic that you're focused on with the organization. Can you tell me a little bit more about that? +JENNIFER: I'm happy to, and in our opinion here at DiMe, equity has to be front and center of everything we do. I think too many times we look across and considerations around diversity, equity, and inclusion; they're part of a rubric. They're a vertical. That's not what we think here at DiMe. We have to think about diversity, equity, and inclusion in everything that we do as we work to digitize healthcare. We know that there are pressing, persistent, and absolutely inexcusable inequities that exist across the burden of disease, across access to care, across the quality of care you're able to access, the care that you can afford. We know that all of those things introduce a long-standing history of inequities in health and healthcare. +As we digitize the healthcare industry, it's unacceptable for us just to be thinking about, hey, as long as we don't make things worse, that's not acceptable to us. We are thinking at every turn about how can we improve the way that we identify disease, the way that we manage disease, the way we cure disease, the way that we support people in a lifetime journey of health and disease? And how can we make sure that we do that for everyone in a way we've never been able to before? +So while I could talk about some of the projects that we've done that exclusively focus on advancing health equity through the use of digital tools, it's actually something we keep front and center in everything we do, in everything we talk about here at DiMe and something that we try and compel every single person in the field to think about to make sure that we seize this opportunity. +GERONDA: I think that's fantastic. And something that you hit on that it's really important for us at thoughtbot is continuous improvement. And that intentionality is incredibly important when it comes to DEI efforts. And so one thing that we do have at thoughtbot is we have trainings, and we try to work toward a shared language. But we do understand that everyone is at a different point in a different journey towards DEI to be able to build and design the best products and provide businesses to our clientele. +So I'd love to hear more about how your organization does consider that continuous improvement for all employees across the organization in terms of ensuring that you're enforcing shared language across the organization to be able to continue to have really great care for your people. +JENNIFER: Geronda, I love this. And I think that you've touched on something that's really important, which is while we can be collectively frustrated, perhaps even angry, about the health inequity that we see on a daily basis and that we frankly have not addressed as an industry for decades and decades...and quite frankly, I think we should be frustrated; we should be angry. Not taking the time to meet people where they are as they make a commitment to designing, developing, and thinking about the business incentives that they need in order to do this work well and to be intentional is actually incredibly counterproductive. So we always start with that shared language. +When we talk about inclusion in digital health, we need to not just think about all of the different vectors of inclusion and domains of diversity that we've developed as a healthcare industry, but we need to think about those vectors and domains at the intersection between healthcare and digital. And if we do nothing else beyond educate the field on what those domains and vectors are so they can be intentional, is they think about, gosh, what's the healthcare problem I want to solve for, for whom? How do I need to consider the needs of our intended users as I do that? That in and of itself is going to take us so much further than we are today. +But I'd also love to learn from you guys. I love the three-part way you describe your work, that you think about designing, and then developing, and then getting the business of great product development right. How do you guys think about it? I'd love to be able to learn from you too. +VICTORIA: One thing I know, speaking specifically to the intentionality that you mentioned, so if you're building an AI product and you're not intentionally thinking about DEI, you can actually build bias and problems into the code itself. So for us, and, Geronda, I want to hear your perspective here too, consulting with experts in the field, especially in DEI early and making a culture where we do have a program manager of DEI. So I've really pinged Geronda several times already this year about, like, I have this question about this. And I think having access to an expert and having access to knowledge that you should go back and check yourself is part of it. But do you have anything you want to add there, Geronda? +GERONDA: I definitely agree with everything that you had said, Victoria. And also what I'll add too is that it is really thinking about in everything that we do, how do we bring DEI at the forefront? And recognizing, as I mentioned before, that everyone's in a different place. So it's not to say that if you mess up or if you didn't consider something that, you can't continuously improve. And we have this culture where I'm not going to come in as the DEI police to say, "How come you didn't consider that?" Or "Why didn't you think of that earlier?" It's more to say, "Oh, okay, well, here's how we can approach this differently." +And everyone's pretty open to the feedback and the learning. And so one example that I'll give is that our website, thoughtbot.com, we're right now working towards accessibility for our website so that we can offer it more to those with disabilities, or those that are visually impaired, or hard of hearing, and offer it to be more accessible for anyone who goes to our website. And it's a learning curve for quite a few of our folks. +But the learning library that's offered in there to say, okay, I may not know everything about how things impact those that may be visually impaired, but let me educate and help to develop this website in a way that's going to support them. So to Victoria's point, it's infusing DEI in every way that we can. And what I love as well is that we do have a DEI Council, and we do have a shared platform to bring about issues or have those discussions and ask the questions so that you can continuously improve yourself to make sure that you're developing and infusing DEI across the work that you do. +So great question and I really feel like it's, of course, a work in progress. But we're in a really good place where we can continue to have that continuous improvement through education, and learning, and feedback to correct ourselves. +VICTORIA: Yeah, I love that. I think that having the culture at least puts you in a good starting place. [laughs] I'd love to hear more about what projects you've worked on in that space, specifically, Jennifer. +JENNIFER: So, first of all, I love how you talk about this idea of you need to have a culture in place that allows us to assess opportunities, that allows us to identify the kind of work we need to do based on where we are today. And then once we've assessed those opportunities, once we've identified potential pathways, we actually then have the support and the right environment to be able to implement these best practices. +And there are two things that I'd love to highlight. The first is actually education resources and specifically education resources on applied digital health ethics. I think creating this culture of ethics which is absolutely inextricable from a culture of equity, is critically important. You need to have those folks on staff just like you guys do. You need to be able to go to potential end users and communities and have line items in your budget to reimburse them for their time and their expertise. +You need to be able to have goals and performance metrics that actually reflect the success you're having or where you're struggling when we think about building a more inclusive environment. So that's a lot of what we try and fuel through our applied digital health ethics education. That's something that's a direct-to-learner option for folks; we're very proud of. We've had fantastic reviews and testimonials. We had tremendous faculty help us with that curriculum, and it's been really well received. And we are confident in the change that that education resource is driving in the field. +The second is actually a suite of resources that we launched more recently, and this is where I can start to get really tangible. So as an organization, we convened a broad and diverse group of experts to really tackle the issue of diversity, equity, and inclusion in digitized clinical trials. And I use action-oriented words like tackle very intentionally. Unfortunately, what we see an awful lot of the time is people admiring the problem, for want of a better expression, that we'll see endless panels at conferences and op-eds, and these sorts of things being written about the current state. +But what we were determined to do is own the fact that there is nothing technically prohibiting us today from deploying these digital tools and resources in the service of advancing diversity, equity, and inclusion while simultaneously addressing some of the long-standing clinical issues, while simultaneously addressing some of the regulatory science issues, while promoting access, while making sure we generate better data for better clinical decision making. +This is not an either-or. This is not a trade-off. We are not limited by the technology; we are powered by the technology. It requires our intent and our commitment to actually doing this work. So I'm going to pause there to see if Geronda or Victoria you have questions on any of that. And then I can certainly go into more detail about those tools if that's interesting. +GERONDA: It's super interesting. And I do have a question. But I'll kind of recap and understand that by having those different broadened expertise, you're having multiple people come together with this expertise so that you can ensure you're providing the best data to help you make those equitable decisions. Does that sound about right? +JENNIFER: That's exactly right. I think that as fantastic and expert as our team are, we are merely representative of a broader community that is doing this excellent work out every single day, trying to improve the way we care for people, representing different communities, building tools. And unless we bring not only those innovators from different backgrounds to the table but also representatives of the communities we're actually working hard to serve to the table, our efforts will be inadequate. And that's why we're so committed to this multidisciplinary, pre-competitive, and collaborative work as we build our tools and resources here at DiMe. +GERONDA: Yeah, and that's amazing. The question that I have for you, the follow-up question to that, is we try to look across...our company is global. We do have employees in many different countries across the globe. So trying to ensure that we have an understanding of the needs on a global scale can sometimes be challenging. Can you speak more to this multidisciplinary broadened expertise and how they might bring in perspective that can help shape your technologies or even clinical trial project in a way that supports different ethnicities across the globe and how they identify and even intersectionality of folks as well, so not just race but also LGBTQ or other races as well like socioeconomic status? +JENNIFER: It's such a good question, and it's so important. And I think one of the things that I have frankly learned an enormous amount and really taken to heart are these many different domains and these many different vectors of inclusion. Now, first of all, if we start saying, look, we have to consider these 50 (I'm being facetious, intentionally so.) different considerations, then we're going to become so overwhelmed so quickly that we become absolutely ineffectual as we try and think about serving all of these different individuals. +But, Geronda, you gave fantastic examples around the hard work that you've been doing even in your own website environment to make sure people who are differently abled...they might have certain vision or hearing impairments or whatever that might look like, and they can access your resources. They can interact with your team just as easily as anyone else. So I'll give you an example of something that had never occurred to me until we actually started working with a member of a community who represented this particular part of the workforce. +We were talking about actually how we can use a variety of different tools to monitor respiratory illnesses and diseases. You can think about things like asthma. You can think about things like cough was an important symptom of COVID, for example. How can we use the microphones that you might find in your smartwatch or your smartphone? How might we use these to be able to monitor, predict and track disease? +We'd gone through how does different socioeconomic status, how does place, how does race, or ethnicity perhaps play into your access to these different tools, your tech literacy, your trust in these different tools and products? What had not occurred to me at all...and I'm so embarrassed to say this, but you think about you can have a tool where you do all of the work around inclusive design. You can think about all of the different needs to earn the trust of the communities that you're asking to use these tools. But we hadn't contemplated how you might use these tools if someone, for example, worked in a work environment where it was incredibly loud. +If you're on a building site, if you're in a warehouse, if you're working on a checkout, it doesn't matter how good the sensor is in your smartwatch that you may have been provided with because that work environment is going to absolutely drown out any signal from that stream of data. And so we need to think about all of the different ways that someone's life, and career, and their background, and social determinants affect our ability to develop and deploy tools that really can help them manage their health, improve their health, have better health outcomes. +GERONDA: That's amazing. +VICTORIA: That's amazing. And I wonder if you've encountered too an issue with if you're designing these applications...like I know when I was living in Washington, D.C., there were 3,000 people who don't have internet at home, don't have a computer, don't have a phone. So how would your team approach that kind of problem? +JENNIFER: [laughs] I think this is the theme of our conversation. +VICTORIA: [laughs] +JENNIFER: With intentionality, which is, is the goal here simply to provision tools and technologies, or is our goal here to be more thoughtful about the tools that exist, that we can use? Is our goal here to think about digital infrastructure and how we should be thinking about that not just to power healthcare but also perhaps access to education, access to safe and secure bank accounts, all of these different sorts of things? +We cannot assume that every single person has top-of-the-range technology, unlimited data plans; we are foolish to do so. But the first thing we need to do is actually ask and understand what access to technology looks like and not just assume it's an affordability issue. Maybe it's a trust issue. You have to understand the root cause before you can work to solve something. +I'd also offer up some other data that I always find compelling and important as we have these conversations. While we know there are large portions of the population who don't have access to what some of us, unfortunately, when we're moving quickly, just assume that everyone has, there are also horribly underrepresented populations, represented populations that do have access to these technologies. Some recent data actually showed that one-third of homeless individuals in California do have a smartphone. Let's actually just pause and think about that for a moment. +You can't get access to benefits or brick-and-mortar healthcare because you have to go and fill in all of your information if you don't have a home. But if you have a smartphone, which presumably many of these folks have realized that even at some of the hardest times in their life, they actually need that to stay connected in today's digital economy, that this is actually a way and a vector for us to reach them, for us to capture information and data about what it is they need, not just to improve their healthcare but to get supported into a more safe and sustainable environment with more security where we can actually support their health in a much more holistic way. +It also can connect them with care, whether that's mental healthcare or whatever their needs are in any given moment, that if we were relying on the traditional brick and mortar system, we'd be unable to capture. So this goes back to two things. First of all, don't assume. Don't assume that people do or don't have technology, and if they don't, don't assume you understand what the root cause actually is. The second point is don't think about these digital tools as limiting factors; think about the ways that we can use them to overcome so many of the challenges that we've faced in the way we care for people for decades and decades. +VICTORIA: I love that you bring that point up. I volunteered for many years with an application called HopeOneSource, which is a mobile app for people who are experiencing homelessness to get access to services that they need. And I know it might have changed over time, but it was like 80% of people who are experiencing homelessness do have a cell phone. And partly in the United States, there is a subsidy. If you're under a certain income level, you can get a free cell phone. +But it's very easy to have your cell phone stolen or to get lost. And the impermanency of the device is also an issue. So I think it's actually, like you said, you don't want to make assumptions about what people have and what they don't. And you do want to bring the intention and understand what it's really like because that will change how you build in things like security and two-factor authentication and things like that. So... +JENNIFER: That's exactly right. And also, what are some of the infrastructure things we can do? You mentioned the subsidies for folks who are low-income. But then we want people to start transmitting confidential and private information about their health in order to access the highest quality care possible. Are we creating environments where there is access to secure connection environment? So they're not using public Wi-Fi where they actually might be more susceptible to harm due to sort of misuse of that data if it falls into the hands of the wrong folks. +These are all of the different things we need to be thinking about. That's not to slow us down or to dampen our enthusiasm for the opportunities that digitization provides to improve the way we care for people. But again, it comes back to...I think what's emerging is almost a theme of our discussion, which is the need to be intentional. +GERONDA: I love what you said about not making assumptions because I'm a DEI practitioner, but I always tell people I'm not perfect. [laughs] And so my bias comes in sometimes. I sometimes will assume that I might know the answer to something or what somebody may be experiencing because I may be incredibly passionate about the LGBTQ+ community, which I'm a part of. And it's reminding myself that I can't assume or let my own biases or own feelings towards certain things to steer my decision-making. +I really have to be super open and objective to what the facts are telling and get those other experiences from other people. So I continuously check my bias, and I continuously try not to make those assumptions which can be hard at times. And while I know everyone at thoughtbot thinks I'm perfect, I'm the best, [laughter] it's just not true. +VICTORIA: I think it is true. [laughter] +GERONDA: There you go. +JENNIFER: Geronda, I so appreciate you sharing that, and I think it probably is giving everyone listening the same experience that I am having right now, which is you owning that and being willing to share that. Immediately cascading through my mind...and now all of the assumptions that I come to the table with, and all of the ways that I think about things and those hot topics that are unique to me and my lived experience, and what I've been exposed to. And on the one hand, we should never dismiss that. On the other hand, the definition of being inclusive is to go out to folks with those different viewpoints. +And one of the things I see increasingly featuring in these sorts of domains of diversity is political views. And you think, gosh, how has this even become a thing in the way that we consider caring for people? But it's so divisive. And I come to the table with all of my thoughts about these kinds of things. But what's serving us about our lived experience and about the passions that drive us all to try and create better products and a better and more inclusive future, and what's not? And how can we humbly acknowledge that and really listen and hear what others are telling us? +GERONDA: Right. Exactly, exactly. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +VICTORIA: If I'm a clinical researcher and I'm about to design an experiment, let's say, how can I use the resources at DiMe to help inform my opinion and help bring in that inclusivity, which I want? +JENNIFER: So, Victoria, great question. [laughter] I'm teed up to answer this one. So I think the first thing is, and, Geronda, this is something that you mentioned earlier, which is you don't do a 45-minute brainstorm before you get going, check a box, and say you did it. It's a continual process, and it's a process of continual improvement. So when we describe this, we would discuss the entire clinical trials lifecycle. So, first of all, there are DEI considerations, even in the kind of question you want to answer. +If you are doing clinical research because you want to develop a new molecule, a new pill, or something, for example, what community will you be serving? What's the problem we're trying to solve for? Are we trying to add a me-too drug to a population that's already well-served? Or are we actually thinking about, gosh, there's this underrepresented population? There's a disease state where we've struggled to break through. We believe that we can deploy these digital tools in order to really effect change here. So it starts as early as what is the problem you're trying to solve for? What is your research question? +Then each stage as you think about, gosh, what are the tools that I might want to use in order to answer this question? Who are the people that we could possibly serve through the development of this new drug, for example? Great, then we take seriously our responsibility of making sure that every single individual who participates in our trial reflects and represents that broader population, that we are going to take inclusivity seriously so that when we have an answer to our research question, we know that what we know about the safety of a new drug and what we know about the effectiveness of a new drug applies equally well to every member of the population. +At that point, we're asking ourselves questions about as we think about parts of the clinical protocol, so the different steps that we work through in order to safely administer a new therapy that's part of the trial, as we think about capturing the information we need in order to determine whether it's safe and effective, are we setting that up to be as safe as effective for everyone? Are we able to design the trial in such a way that the burden of participation isn't a barrier for certain members of the community? +If we're picking digital tools to do things like remote patient monitoring...so imagine for anyone who has a smartwatch the green light on the back of your watch that's measuring your heart rate. Unfortunately, some of those products work differently across different skin tones. Have you done the work to make sure that you're selecting a tool that is going to give you equally trustworthy information for every single person? These are all of the things step by step that you should think about as you are developing a clinical trial. +We have tool after resource after checklist to help you do this in a really accessible way. We organize them so you can find them really easily based on either what stage am I at and what can I do today to be more diverse, and more equitable, and more inclusive in the way that I'm developing new medicines? We also allow you to find these tools and resources based on a particular digital product. +So if, for example, you think that you might be able to use, and we haven't said the words yet, so it's probably time, AI or machine learning to better identify a more diverse patient population that you could enroll into your trial, how are you thinking about catching potential bias that might take your good intentions and actually render them almost useless because you didn't identify bias in the algorithm, for example? So all of those tools and resources, and there are over 60 of them available, are open access. They're free to download, use them, interactive checklists, considerations documents, tools, and resources that help you act today as soon as you make a decision about doing clinical research that benefits all people. +GERONDA: And it almost sounds like, in a way, that this resource could be helpful for many other industries as well because although it's tied to clinical trials, the considerations and process that you're taking to start to think through those DEI elements that checklist can be helpful across many different disciplines. Would you say that's correct? +JENNIFER: I would. Now, Geronda, our superpower, is getting the digitization of healthcare right. And that's a big enough task that while there are other pressing areas, we will not stray into those. But I think you've hit the nail on the head. When we think about getting access to education, for example, or access to safe housing, or any other kinds of benefits, and we can think about how some of these digital tools can overcome many of the different barriers to access that different communities face. Absolutely, all of these different principles can apply. And in fact, we actually think that's really important. +We talk a lot about harmonization in the work that we do. There are folks who have product portfolios that span different industries. When we think about really trying to hammer home the need to be intentional, to make sure that as we digitize the healthcare industry, we are bringing everyone with us, we should avoid, wherever possible, having unique or special considerations. Ultimately, these are all the same humans that we serve in other industries. We are trying more than ever to meet people where they are than insisting they come to us or come to the clinic, for example. +All of these principles apply equally well. And if we do that harmonization well...and this comes back to the idea of culture that we were talking about. This just gets embedded into the culture of developing products for every single person, regardless of whether that's an educational product, or a healthcare product, or a financial product. We should be thinking about these things regardless of how we're striving to help and support people. +GERONDA: I love that. +VICTORIA: I love that. And I wonder, when you were developing these products for clinicians or for healthcare providers, was there anything surprising in your initial research and discovery when building these things? +JENNIFER: Yes. And I would say that technology is no longer the barrier. There is nothing that we need a product to do, whether that's the way we account for, right? You're not always going to eliminate it. But the way that we account for, for example, bias in the way that we capture and process data, if you acknowledge it, you can do the necessary statistical interpretation. And then you can actually be well-informed in your decision-making. +There's nothing either about the data, about the form factors, about battery life, about the performance of these tools that is stopping us from building and deploying solutions that work for everyone starting today, starting immediately. So then, what is the barrier? The barrier is a knowledge gap, a skills gap, an incentives gap. And that's really what we've been hammering to address. +And if you do look at our DEI resources, especially for digitized clinical trials, we try and think about all of those gaps and support people, whether it's through, here, let us educate you on actually where some of the risks are, some of the new vectors of inclusion or domains of diversity, especially at the intersection of digital and health. Let us support you with tools and resources, and guides for how to do this. +And then let us give you data and let us give you things like a market opportunity calculator, which is something else that we've created that will actually give you the business case to be more inclusive in the way that you develop digital products for use in clinical trials and the way you deploy them to support better research. That's really what we're focused on. +And so the surprise almost is that the tech isn't limiting us in any way. The flip side of that being we are not going to tech our way out of this. It comes down to humans and our decisions and how we develop and deploy these tools in the service of better health. +VICTORIA: That makes sense to me, and it makes me think about there's like a moral obligation or value that you can apply to DEI, but there's also a financial aspect. [laughs] And if you put a lot of effort into building an app, for example, and don't think about inclusivity, and you get to the end and think, oh, now I have to go back and make it accessible, that can be a lot of rework. It can be a lot of cost, if not even a legal liability and financial liability, I would imagine, in the healthtech sector. +JENNIFER: That's exactly right. I couldn't have said any better, Victoria. [laughs] +VICTORIA: [laughs] It's like, you are morally and legally obligated in many cases to include people. And it's better to just start from the beginning and start from the beginning and knowing what we're trying to do. +JENNIFER: 100%. And I was trying not to pile on because I think the statement just stands alone. We are morally obligated. In some cases, we are legally obligated. There are emerging regulations certainly in the clinical trials environment about having more representative samples in order for you to get regulatory approval, for example. One of those regulations is moving slowly, which is always frustrating and disappointing. But given the moral imperative, given the emerging regulations, given that finally, this is more at the forefront of conversations, you've got to think about the gymnastics that are happening to continue to avoid doing this. And that's a little bit of the pressure that we want to apply. +And so when we talk about the fact that there's no technological reason for not doing this, and when we have tried to provide the tools and resources to actually put these tools into practice, the only remaining question is, are you going to do it? And that's a big question. And as a field, we've not been terribly good at leaning into that previously. We'll talk about it all day. We'll admire the problem of inequity all day. We haven't been good enough at acting. And I'm hoping we're at a tipping point. +VICTORIA: Great. And it sounds like now with DiMe, there's no excuse. All the information is there for you. [laughter] +JENNIFER: That was exactly what we tried to do. That was the challenge that we gave ourselves and this extraordinary team. And the different individuals and organizations that came to the table to do this they set the standard high. And I'm so proud of their sort of possession, of their courage, and their tenacity in saying, "We are going to serve up absolutely everything that's needed. We're going to present it in a way that it's almost impossible not to find what you need for every person who's coming with this question." We set the standard high, and I'm incredibly proud of how well we delivered on that. +VICTORIA: What does success look like for DiMe in the next six months or in the next five years? +JENNIFER: What is it? Is it a Bill Gates quote? Is it...you sort of overestimate what you can do in 6 months and underestimate what you'll do in 10 years, something along those lines. And the intention is there, though. Anyone who knows me well will probably say I've never underestimated anything in my life. I'm always pushing for the next thing. Let's come back to this notion that the tech is not the limiting factor. And we're facing a really interesting moment in healthcare where the current environment is simply not sustainable. There are not enough clinicians to provide care or conduct research. We've had an expensive healthcare system for a long time. +But the prices are not sustainable when you think about how much health insurance is going up relative to inflation, when you think about the out-of-pocket costs that people are facing when you think about the fact that there's not a single healthcare executive who's sleeping well at night because they can't staff their units, and their supply chain costs are incredibly high. And they're worried about the sustainability of their hospital, especially in rural and underserved areas. Business, as usual, is not an option. +So in the next six months, I think we're going to keep pushing along. But in that five-year window, I think we are going to see a fundamentally different way that we care for people in the healthcare environment and that we conduct clinical trials. No longer is healthcare going to be built around the clinic. That's not to say they're going to go away. There are, of course, going to be times where you need to see a clinician in person, where you need to have a procedure, where you need to have some lab work or imaging done. +But so much of this can be translated into the home, can use tools to extend the knowledge and expertise of clinicians so that we can better care for people, all people, by meeting them where they are. I think we're going to see a fundamentally different kind of healthcare, different kinds of clinical research built around the patient, not the clinic. And part of that is going to be redefining what good healthcare even is. Currently, good healthcare is once you turn up at the clinic already sick, sometimes really sick, facing a catastrophic and likely very expensive outcome, we do our best. That's good healthcare. +I really think we're going to drive towards a future where these new flows of data and these new technologies are going to actually allow us to try and mitigate disease earlier, to intervene earlier, to catch all people who are at risk earlier in their health journey. And the great thing about that is it offers the opportunity to define healthcare differently. All of a sudden, good healthcare isn't; how good are we at intervening when you're sick? But how good are we at keeping you well and keeping you out of the healthcare system? +I also feel strongly that it is no longer going to be enough to just raise the top end of healthcare and provide the best care to the people who are able to afford it, that we are going to start to embed metrics around equity into our evaluation of good healthcare. And the sooner we do that, the better because every time we look at those numbers now, they are astonishingly bad. +VICTORIA: Yeah. And it's making me think about, you know, in five years, if we continue with the trend of global warming, they're also predicting more pandemics, more disease. And it seems like we are going to have to reimagine how we do healthcare because the current path isn't sustainable. +JENNIFER: Exactly right. Exactly right. And the sad thing about all of this is that the burden of things like climate change, the burden of pandemics falls on those communities and those individuals who have been underrepresented and underserved in healthcare for the longest. It increases the burden of disease and health stress on folks who have consistently carried the highest burden of disease, been part of the highest risk categories. Not only do we have to get better at delivering care to all people reducing the burden of disease, we have to do it where actually those challenges through all of those external pressures, Victoria, are going to be becoming worse. +VICTORIA: And it reminds me of another term I've heard for underrepresented, which is historically excluded, which I think really applies here. So that's fascinating. +JENNIFER: Because it is what it is. +VICTORIA: Yeah, right? Like, that's what it is. So I think it's wonderful that's what you're working on. And let's see if you could go back in time to when you first started DiMe Society; what advice would you give yourself now that it's been three years and you've come a long way? +JENNIFER: [laughs] Sleep more. [laughter] I don't know, when I look in the mirror these days, there's an old lady that I'm sure wasn't there at the beginning of all this. But I think that's not the spirit of the question you were asking, Victoria. I wish we'd been bolder sooner. And we've never shied away from tackling the hardest problems. We started with this bold mission and vision. +People would ask us when we launched DiMe, you know, "Gosh, are you really focused across individual health promotion, across healthcare delivery, across public health, and across clinical research?" And we said, "Absolutely," because if we don't tackle it all together, we're simply going to create new silos in the digital era. And we're never going to move towards this reimagined healthcare system, a new healthcare system, one that cares for everyone and where access to research is even harder than access to care. +With these new flows of data in the digital era, we want to do it together. So it's not that we weren't bold, but the way now we make strong statements that we've always believed and that we've always been proud of around the imperative to be inclusive around the demand for high-quality evidence to drive trust around the fact that none of this is a tech issue. It's a human issue. I wish we had gone there sooner. I think it is serving us well. +I think that the professionals that we work with across industry respond to it. They want to be part of this journey. They want to build a better healthcare system. And so, while we've always been, I think, bold and courageous in the vision that we've held and the work we've done, giving voice to it in a way that really reflects our vision and our passion has been so well received by our community. And they have stepped up to do this work incredibly well. I just wish we'd gone there sooner. That's the only thing I would have done differently. +VICTORIA: I think that's great advice, especially for founders who are starting out in a space like this, to really stand by their convictions and be bold about it. [chuckles] Like, this is what you believe in, and other people will connect to it if it's right, so I love that. And we're getting towards the end of our time here too. So I want to make sure I can pass it to Geronda if you have any other final questions for our guest here today. +GERONDA: More a comment in that I think that learning more about your organization and perusing some of the tools that you offer and the checklist that you offer...and it's such great work. And in some ways...and I'm trying to get the best way to say this. But in some ways, it's so clear of, like, this is what you can consider. This is what you should do. Although the work is not easy to do, it's really a helpful guideline for how you can start to think differently. +I really appreciate the thoughtfulness that was put into a lot of these resources that you're giving out and just where you are in your trajectory as well because DEI work is not easy work. And you sometimes...it can impact you emotionally. It can impact you mentally sometimes. But when you're continuing to go after what you know is needed and the intentionality of things, it really is super helpful. +So although I said I didn't have a question, and I just had a comment, I lied. I do have a question. [laughter] My question to you is, in doing a lot of this work, ensuring that DEI is infused in healthtech, all the work that you do and that your team does, how do you just navigate and manage your well-being, your mental health, your emotional health as you continue to do all this work? +JENNIFER: It's such a great question. And when you said, Geronda, that this can sometimes be really emotional, I heard a statistic actually from a colleague of mine, Ricki Fairley, who's the CEO of Touch, Breast Cancer, and she was telling me that cancer affecting women under 35, Black women under 35 are diagnosed with cancer at a rate twice that of White women and die at a rate three times higher than White women. And, I mean, you hear that statistic, and it just takes the wind out of you. And it would be really easy to hide from that because it's hard to hear, sometimes too hard. +The way that we handle sort of all of this as a team is we square up to these data, and then we celebrate one another. We celebrate our community when we are able to make positive change, even if it's incremental change. Even if sometimes you have those moments where you really move the needle, you have those other days or those other initiatives where you feel like you're crawling on your hands and knees to gain inches. +But to celebrate that every moment and to remind ourselves the work is returning value to those people that we all get up every morning to try and serve, that it might be hard, but we're making progress. And that is, I think, the way that, as a team, we stay positive, we stay productive, and that we're able to balance, frankly, the exposure to the reality of some of these issues. +GERONDA: I think that's great, having a community even within the workplace. It's so crucial because you spend most of your time at work, as we all know. [laughs] And there's a lot that just goes on across the world all the time, and being able to just talk it out. We have employee resource groups for people to come together with common identities and just talk through things that are impacting them. And so I really think that's great that you're able to just be honest with how you're feeling but also celebrating those important positive moments because sometimes we can focus a lot on the negative. So I really love that you bring the positive aspects of that as well. +VICTORIA: Yes, thank you for sharing, and it comes back to the intention. Like, we're all on the same page. We all have this intention of solving this problem. So we're in it together in a way. So, Jennifer, are there any final thoughts or takeaways you want to leave our listeners with today? +JENNIFER: No, this was a fantastic conversation. I think we've drawn out this theme of intentionality that will serve all of us very well. Geronda, I love the final question about how do we keep our own sort of emotional state and mental health solid as we do this hard work? It's the perfect note to end on. So Victoria, Geronda, thank you so much for having me on. This has been just a wonderful conversation. I've really enjoyed it. +VICTORIA: Wonderful. Thank you so much for joining and spending time with us today. +JENNIFER: Yes, I very much appreciate it. This was an awesome conversation. +VICTORIA: All right. And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Jennifer Goldsack. + + + Jennifer Goldsack is CEO of Digital Medicine Society (DiMe), the professional home for digital medicine. It is a global nonprofit with a mission to advance the ethical, effective, equitable, and safe use of digital technology to redefine healthcare and improve lives.

+ +

Victoria talks to Jennifer about using new products and solutions to solve some of the most pressing and persistent challenges in healthcare, measuring success by how well they are caring for people every day and not by how good their products or how many they use on any given day, and how DiME can improve the way that we identify, manage, cure, and support people in a lifetime journey of health and disease.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jennifer Goldsack, CEO of Digital Medicine Society, the professional home for digital medicine. Jennifer, thank you for joining me.

+ +

JENNIFER: Thank you so much for having me; excited for our conversation today.

+ +

VICTORIA: Wonderful, me too. And we have our Program Manager for DEI Geronda with us today. Hello.

+ +

GERONDA: Hey, how's it going? I'm super excited to be on here as well.

+ +

VICTORIA: Yes, me too. It's going to be a great conversation. So, Jennifer, why don't you just tell me a little bit more about the Digital Medicine Society?

+ +

JENNIFER: Happy to, one of my favorite topics, Victoria. So the Digital Medicine Society, or as we affectionately refer to it as DiMe, is a global nonprofit, and our mission is to advance the ethical, effective, equitable, and safe use of digital technology to redefine healthcare and improve lives.

+ +

And I think one point I'd like to make right off the bat is while we are tech and digital enthusiasts here at DiMe, we are not tech determinists. What we think about is how can we harness the promise of these new digital tools in the toolbox, these new products, these new solutions, and how can we use them to solve some of the most pressing and persistent challenges in healthcare, an industry that exists to care for people? That's what we think about all day. That's our measure of success: how well are we caring for people every day, not how good are our products or how many products can we use on any given day.

+ +

VICTORIA: Right. So what did you see in the digital health space that led you to believe that something like DiMe needed to exist in the world?

+ +

JENNIFER: So it's interesting. When we take a step back and think about all the experts that need to be at the table to ensure that we build a field of digital health that is worthy of our trust, in our opinion here at DiMe, we think this is the most interdisciplinary field you can imagine, and that's a bold claim. But let me play it out for you. And maybe we can think about some other interdisciplinary fields during the course of our discussion.

+ +

For digital medicine to work, we need citizen scientists and cyber security experts. We need physicists, engineers, product folks, data scientists, clinical scientists, clinical care providers, healthcare executives, regulators, payors, investors, funders all to sit at the table together, all to speak a common unifying language, all to have a shared idea of what our North Star is. What are we trying to do here as we digitize healthcare, and what does good look like and for whom as we do it?

+ +

And so that's the gap that the Digital Medicine Society was introduced to fill. That water cooler, if you like, where the leaders in our field can share their expertise and where we can very intentionally build a much better future for healthcare using the new digital tools in our toolbox.

+ +

VICTORIA: Interesting. And I like how you pointed out for whom. [laughs] And I see digital equity is a big topic that you're focused on with the organization. Can you tell me a little bit more about that?

+ +

JENNIFER: I'm happy to, and in our opinion here at DiMe, equity has to be front and center of everything we do. I think too many times we look across and considerations around diversity, equity, and inclusion; they're part of a rubric. They're a vertical. That's not what we think here at DiMe. We have to think about diversity, equity, and inclusion in everything that we do as we work to digitize healthcare. We know that there are pressing, persistent, and absolutely inexcusable inequities that exist across the burden of disease, across access to care, across the quality of care you're able to access, the care that you can afford. We know that all of those things introduce a long-standing history of inequities in health and healthcare.

+ +

As we digitize the healthcare industry, it's unacceptable for us just to be thinking about, hey, as long as we don't make things worse, that's not acceptable to us. We are thinking at every turn about how can we improve the way that we identify disease, the way that we manage disease, the way we cure disease, the way that we support people in a lifetime journey of health and disease? And how can we make sure that we do that for everyone in a way we've never been able to before?

+ +

So while I could talk about some of the projects that we've done that exclusively focus on advancing health equity through the use of digital tools, it's actually something we keep front and center in everything we do, in everything we talk about here at DiMe and something that we try and compel every single person in the field to think about to make sure that we seize this opportunity.

+ +

GERONDA: I think that's fantastic. And something that you hit on that it's really important for us at thoughtbot is continuous improvement. And that intentionality is incredibly important when it comes to DEI efforts. And so one thing that we do have at thoughtbot is we have trainings, and we try to work toward a shared language. But we do understand that everyone is at a different point in a different journey towards DEI to be able to build and design the best products and provide businesses to our clientele.

+ +

So I'd love to hear more about how your organization does consider that continuous improvement for all employees across the organization in terms of ensuring that you're enforcing shared language across the organization to be able to continue to have really great care for your people.

+ +

JENNIFER: Geronda, I love this. And I think that you've touched on something that's really important, which is while we can be collectively frustrated, perhaps even angry, about the health inequity that we see on a daily basis and that we frankly have not addressed as an industry for decades and decades...and quite frankly, I think we should be frustrated; we should be angry. Not taking the time to meet people where they are as they make a commitment to designing, developing, and thinking about the business incentives that they need in order to do this work well and to be intentional is actually incredibly counterproductive. So we always start with that shared language.

+ +

When we talk about inclusion in digital health, we need to not just think about all of the different vectors of inclusion and domains of diversity that we've developed as a healthcare industry, but we need to think about those vectors and domains at the intersection between healthcare and digital. And if we do nothing else beyond educate the field on what those domains and vectors are so they can be intentional, is they think about, gosh, what's the healthcare problem I want to solve for, for whom? How do I need to consider the needs of our intended users as I do that? That in and of itself is going to take us so much further than we are today.

+ +

But I'd also love to learn from you guys. I love the three-part way you describe your work, that you think about designing, and then developing, and then getting the business of great product development right. How do you guys think about it? I'd love to be able to learn from you too.

+ +

VICTORIA: One thing I know, speaking specifically to the intentionality that you mentioned, so if you're building an AI product and you're not intentionally thinking about DEI, you can actually build bias and problems into the code itself. So for us, and, Geronda, I want to hear your perspective here too, consulting with experts in the field, especially in DEI early and making a culture where we do have a program manager of DEI. So I've really pinged Geronda several times already this year about, like, I have this question about this. And I think having access to an expert and having access to knowledge that you should go back and check yourself is part of it. But do you have anything you want to add there, Geronda?

+ +

GERONDA: I definitely agree with everything that you had said, Victoria. And also what I'll add too is that it is really thinking about in everything that we do, how do we bring DEI at the forefront? And recognizing, as I mentioned before, that everyone's in a different place. So it's not to say that if you mess up or if you didn't consider something that, you can't continuously improve. And we have this culture where I'm not going to come in as the DEI police to say, "How come you didn't consider that?" Or "Why didn't you think of that earlier?" It's more to say, "Oh, okay, well, here's how we can approach this differently."

+ +

And everyone's pretty open to the feedback and the learning. And so one example that I'll give is that our website, thoughtbot.com, we're right now working towards accessibility for our website so that we can offer it more to those with disabilities, or those that are visually impaired, or hard of hearing, and offer it to be more accessible for anyone who goes to our website. And it's a learning curve for quite a few of our folks.

+ +

But the learning library that's offered in there to say, okay, I may not know everything about how things impact those that may be visually impaired, but let me educate and help to develop this website in a way that's going to support them. So to Victoria's point, it's infusing DEI in every way that we can. And what I love as well is that we do have a DEI Council, and we do have a shared platform to bring about issues or have those discussions and ask the questions so that you can continuously improve yourself to make sure that you're developing and infusing DEI across the work that you do.

+ +

So great question and I really feel like it's, of course, a work in progress. But we're in a really good place where we can continue to have that continuous improvement through education, and learning, and feedback to correct ourselves.

+ +

VICTORIA: Yeah, I love that. I think that having the culture at least puts you in a good starting place. [laughs] I'd love to hear more about what projects you've worked on in that space, specifically, Jennifer.

+ +

JENNIFER: So, first of all, I love how you talk about this idea of you need to have a culture in place that allows us to assess opportunities, that allows us to identify the kind of work we need to do based on where we are today. And then once we've assessed those opportunities, once we've identified potential pathways, we actually then have the support and the right environment to be able to implement these best practices.

+ +

And there are two things that I'd love to highlight. The first is actually education resources and specifically education resources on applied digital health ethics. I think creating this culture of ethics which is absolutely inextricable from a culture of equity, is critically important. You need to have those folks on staff just like you guys do. You need to be able to go to potential end users and communities and have line items in your budget to reimburse them for their time and their expertise.

+ +

You need to be able to have goals and performance metrics that actually reflect the success you're having or where you're struggling when we think about building a more inclusive environment. So that's a lot of what we try and fuel through our applied digital health ethics education. That's something that's a direct-to-learner option for folks; we're very proud of. We've had fantastic reviews and testimonials. We had tremendous faculty help us with that curriculum, and it's been really well received. And we are confident in the change that that education resource is driving in the field.

+ +

The second is actually a suite of resources that we launched more recently, and this is where I can start to get really tangible. So as an organization, we convened a broad and diverse group of experts to really tackle the issue of diversity, equity, and inclusion in digitized clinical trials. And I use action-oriented words like tackle very intentionally. Unfortunately, what we see an awful lot of the time is people admiring the problem, for want of a better expression, that we'll see endless panels at conferences and op-eds, and these sorts of things being written about the current state.

+ +

But what we were determined to do is own the fact that there is nothing technically prohibiting us today from deploying these digital tools and resources in the service of advancing diversity, equity, and inclusion while simultaneously addressing some of the long-standing clinical issues, while simultaneously addressing some of the regulatory science issues, while promoting access, while making sure we generate better data for better clinical decision making.

+ +

This is not an either-or. This is not a trade-off. We are not limited by the technology; we are powered by the technology. It requires our intent and our commitment to actually doing this work. So I'm going to pause there to see if Geronda or Victoria you have questions on any of that. And then I can certainly go into more detail about those tools if that's interesting.

+ +

GERONDA: It's super interesting. And I do have a question. But I'll kind of recap and understand that by having those different broadened expertise, you're having multiple people come together with this expertise so that you can ensure you're providing the best data to help you make those equitable decisions. Does that sound about right?

+ +

JENNIFER: That's exactly right. I think that as fantastic and expert as our team are, we are merely representative of a broader community that is doing this excellent work out every single day, trying to improve the way we care for people, representing different communities, building tools. And unless we bring not only those innovators from different backgrounds to the table but also representatives of the communities we're actually working hard to serve to the table, our efforts will be inadequate. And that's why we're so committed to this multidisciplinary, pre-competitive, and collaborative work as we build our tools and resources here at DiMe.

+ +

GERONDA: Yeah, and that's amazing. The question that I have for you, the follow-up question to that, is we try to look across...our company is global. We do have employees in many different countries across the globe. So trying to ensure that we have an understanding of the needs on a global scale can sometimes be challenging. Can you speak more to this multidisciplinary broadened expertise and how they might bring in perspective that can help shape your technologies or even clinical trial project in a way that supports different ethnicities across the globe and how they identify and even intersectionality of folks as well, so not just race but also LGBTQ or other races as well like socioeconomic status?

+ +

JENNIFER: It's such a good question, and it's so important. And I think one of the things that I have frankly learned an enormous amount and really taken to heart are these many different domains and these many different vectors of inclusion. Now, first of all, if we start saying, look, we have to consider these 50 (I'm being facetious, intentionally so.) different considerations, then we're going to become so overwhelmed so quickly that we become absolutely ineffectual as we try and think about serving all of these different individuals.

+ +

But, Geronda, you gave fantastic examples around the hard work that you've been doing even in your own website environment to make sure people who are differently abled...they might have certain vision or hearing impairments or whatever that might look like, and they can access your resources. They can interact with your team just as easily as anyone else. So I'll give you an example of something that had never occurred to me until we actually started working with a member of a community who represented this particular part of the workforce.

+ +

We were talking about actually how we can use a variety of different tools to monitor respiratory illnesses and diseases. You can think about things like asthma. You can think about things like cough was an important symptom of COVID, for example. How can we use the microphones that you might find in your smartwatch or your smartphone? How might we use these to be able to monitor, predict and track disease?

+ +

We'd gone through how does different socioeconomic status, how does place, how does race, or ethnicity perhaps play into your access to these different tools, your tech literacy, your trust in these different tools and products? What had not occurred to me at all...and I'm so embarrassed to say this, but you think about you can have a tool where you do all of the work around inclusive design. You can think about all of the different needs to earn the trust of the communities that you're asking to use these tools. But we hadn't contemplated how you might use these tools if someone, for example, worked in a work environment where it was incredibly loud.

+ +

If you're on a building site, if you're in a warehouse, if you're working on a checkout, it doesn't matter how good the sensor is in your smartwatch that you may have been provided with because that work environment is going to absolutely drown out any signal from that stream of data. And so we need to think about all of the different ways that someone's life, and career, and their background, and social determinants affect our ability to develop and deploy tools that really can help them manage their health, improve their health, have better health outcomes.

+ +

GERONDA: That's amazing.

+ +

VICTORIA: That's amazing. And I wonder if you've encountered too an issue with if you're designing these applications...like I know when I was living in Washington, D.C., there were 3,000 people who don't have internet at home, don't have a computer, don't have a phone. So how would your team approach that kind of problem?

+ +

JENNIFER: [laughs] I think this is the theme of our conversation.

+ +

VICTORIA: [laughs]

+ +

JENNIFER: With intentionality, which is, is the goal here simply to provision tools and technologies, or is our goal here to be more thoughtful about the tools that exist, that we can use? Is our goal here to think about digital infrastructure and how we should be thinking about that not just to power healthcare but also perhaps access to education, access to safe and secure bank accounts, all of these different sorts of things?

+ +

We cannot assume that every single person has top-of-the-range technology, unlimited data plans; we are foolish to do so. But the first thing we need to do is actually ask and understand what access to technology looks like and not just assume it's an affordability issue. Maybe it's a trust issue. You have to understand the root cause before you can work to solve something.

+ +

I'd also offer up some other data that I always find compelling and important as we have these conversations. While we know there are large portions of the population who don't have access to what some of us, unfortunately, when we're moving quickly, just assume that everyone has, there are also horribly underrepresented populations, represented populations that do have access to these technologies. Some recent data actually showed that one-third of homeless individuals in California do have a smartphone. Let's actually just pause and think about that for a moment.

+ +

You can't get access to benefits or brick-and-mortar healthcare because you have to go and fill in all of your information if you don't have a home. But if you have a smartphone, which presumably many of these folks have realized that even at some of the hardest times in their life, they actually need that to stay connected in today's digital economy, that this is actually a way and a vector for us to reach them, for us to capture information and data about what it is they need, not just to improve their healthcare but to get supported into a more safe and sustainable environment with more security where we can actually support their health in a much more holistic way.

+ +

It also can connect them with care, whether that's mental healthcare or whatever their needs are in any given moment, that if we were relying on the traditional brick and mortar system, we'd be unable to capture. So this goes back to two things. First of all, don't assume. Don't assume that people do or don't have technology, and if they don't, don't assume you understand what the root cause actually is. The second point is don't think about these digital tools as limiting factors; think about the ways that we can use them to overcome so many of the challenges that we've faced in the way we care for people for decades and decades.

+ +

VICTORIA: I love that you bring that point up. I volunteered for many years with an application called HopeOneSource, which is a mobile app for people who are experiencing homelessness to get access to services that they need. And I know it might have changed over time, but it was like 80% of people who are experiencing homelessness do have a cell phone. And partly in the United States, there is a subsidy. If you're under a certain income level, you can get a free cell phone.

+ +

But it's very easy to have your cell phone stolen or to get lost. And the impermanency of the device is also an issue. So I think it's actually, like you said, you don't want to make assumptions about what people have and what they don't. And you do want to bring the intention and understand what it's really like because that will change how you build in things like security and two-factor authentication and things like that. So...

+ +

JENNIFER: That's exactly right. And also, what are some of the infrastructure things we can do? You mentioned the subsidies for folks who are low-income. But then we want people to start transmitting confidential and private information about their health in order to access the highest quality care possible. Are we creating environments where there is access to secure connection environment? So they're not using public Wi-Fi where they actually might be more susceptible to harm due to sort of misuse of that data if it falls into the hands of the wrong folks.

+ +

These are all of the different things we need to be thinking about. That's not to slow us down or to dampen our enthusiasm for the opportunities that digitization provides to improve the way we care for people. But again, it comes back to...I think what's emerging is almost a theme of our discussion, which is the need to be intentional.

+ +

GERONDA: I love what you said about not making assumptions because I'm a DEI practitioner, but I always tell people I'm not perfect. [laughs] And so my bias comes in sometimes. I sometimes will assume that I might know the answer to something or what somebody may be experiencing because I may be incredibly passionate about the LGBTQ+ community, which I'm a part of. And it's reminding myself that I can't assume or let my own biases or own feelings towards certain things to steer my decision-making.

+ +

I really have to be super open and objective to what the facts are telling and get those other experiences from other people. So I continuously check my bias, and I continuously try not to make those assumptions which can be hard at times. And while I know everyone at thoughtbot thinks I'm perfect, I'm the best, [laughter] it's just not true.

+ +

VICTORIA: I think it is true. [laughter]

+ +

GERONDA: There you go.

+ +

JENNIFER: Geronda, I so appreciate you sharing that, and I think it probably is giving everyone listening the same experience that I am having right now, which is you owning that and being willing to share that. Immediately cascading through my mind...and now all of the assumptions that I come to the table with, and all of the ways that I think about things and those hot topics that are unique to me and my lived experience, and what I've been exposed to. And on the one hand, we should never dismiss that. On the other hand, the definition of being inclusive is to go out to folks with those different viewpoints.

+ +

And one of the things I see increasingly featuring in these sorts of domains of diversity is political views. And you think, gosh, how has this even become a thing in the way that we consider caring for people? But it's so divisive. And I come to the table with all of my thoughts about these kinds of things. But what's serving us about our lived experience and about the passions that drive us all to try and create better products and a better and more inclusive future, and what's not? And how can we humbly acknowledge that and really listen and hear what others are telling us?

+ +

GERONDA: Right. Exactly, exactly.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: If I'm a clinical researcher and I'm about to design an experiment, let's say, how can I use the resources at DiMe to help inform my opinion and help bring in that inclusivity, which I want?

+ +

JENNIFER: So, Victoria, great question. [laughter] I'm teed up to answer this one. So I think the first thing is, and, Geronda, this is something that you mentioned earlier, which is you don't do a 45-minute brainstorm before you get going, check a box, and say you did it. It's a continual process, and it's a process of continual improvement. So when we describe this, we would discuss the entire clinical trials lifecycle. So, first of all, there are DEI considerations, even in the kind of question you want to answer.

+ +

If you are doing clinical research because you want to develop a new molecule, a new pill, or something, for example, what community will you be serving? What's the problem we're trying to solve for? Are we trying to add a me-too drug to a population that's already well-served? Or are we actually thinking about, gosh, there's this underrepresented population? There's a disease state where we've struggled to break through. We believe that we can deploy these digital tools in order to really effect change here. So it starts as early as what is the problem you're trying to solve for? What is your research question?

+ +

Then each stage as you think about, gosh, what are the tools that I might want to use in order to answer this question? Who are the people that we could possibly serve through the development of this new drug, for example? Great, then we take seriously our responsibility of making sure that every single individual who participates in our trial reflects and represents that broader population, that we are going to take inclusivity seriously so that when we have an answer to our research question, we know that what we know about the safety of a new drug and what we know about the effectiveness of a new drug applies equally well to every member of the population.

+ +

At that point, we're asking ourselves questions about as we think about parts of the clinical protocol, so the different steps that we work through in order to safely administer a new therapy that's part of the trial, as we think about capturing the information we need in order to determine whether it's safe and effective, are we setting that up to be as safe as effective for everyone? Are we able to design the trial in such a way that the burden of participation isn't a barrier for certain members of the community?

+ +

If we're picking digital tools to do things like remote patient monitoring...so imagine for anyone who has a smartwatch the green light on the back of your watch that's measuring your heart rate. Unfortunately, some of those products work differently across different skin tones. Have you done the work to make sure that you're selecting a tool that is going to give you equally trustworthy information for every single person? These are all of the things step by step that you should think about as you are developing a clinical trial.

+ +

We have tool after resource after checklist to help you do this in a really accessible way. We organize them so you can find them really easily based on either what stage am I at and what can I do today to be more diverse, and more equitable, and more inclusive in the way that I'm developing new medicines? We also allow you to find these tools and resources based on a particular digital product.

+ +

So if, for example, you think that you might be able to use, and we haven't said the words yet, so it's probably time, AI or machine learning to better identify a more diverse patient population that you could enroll into your trial, how are you thinking about catching potential bias that might take your good intentions and actually render them almost useless because you didn't identify bias in the algorithm, for example? So all of those tools and resources, and there are over 60 of them available, are open access. They're free to download, use them, interactive checklists, considerations documents, tools, and resources that help you act today as soon as you make a decision about doing clinical research that benefits all people.

+ +

GERONDA: And it almost sounds like, in a way, that this resource could be helpful for many other industries as well because although it's tied to clinical trials, the considerations and process that you're taking to start to think through those DEI elements that checklist can be helpful across many different disciplines. Would you say that's correct?

+ +

JENNIFER: I would. Now, Geronda, our superpower, is getting the digitization of healthcare right. And that's a big enough task that while there are other pressing areas, we will not stray into those. But I think you've hit the nail on the head. When we think about getting access to education, for example, or access to safe housing, or any other kinds of benefits, and we can think about how some of these digital tools can overcome many of the different barriers to access that different communities face. Absolutely, all of these different principles can apply. And in fact, we actually think that's really important.

+ +

We talk a lot about harmonization in the work that we do. There are folks who have product portfolios that span different industries. When we think about really trying to hammer home the need to be intentional, to make sure that as we digitize the healthcare industry, we are bringing everyone with us, we should avoid, wherever possible, having unique or special considerations. Ultimately, these are all the same humans that we serve in other industries. We are trying more than ever to meet people where they are than insisting they come to us or come to the clinic, for example.

+ +

All of these principles apply equally well. And if we do that harmonization well...and this comes back to the idea of culture that we were talking about. This just gets embedded into the culture of developing products for every single person, regardless of whether that's an educational product, or a healthcare product, or a financial product. We should be thinking about these things regardless of how we're striving to help and support people.

+ +

GERONDA: I love that.

+ +

VICTORIA: I love that. And I wonder, when you were developing these products for clinicians or for healthcare providers, was there anything surprising in your initial research and discovery when building these things?

+ +

JENNIFER: Yes. And I would say that technology is no longer the barrier. There is nothing that we need a product to do, whether that's the way we account for, right? You're not always going to eliminate it. But the way that we account for, for example, bias in the way that we capture and process data, if you acknowledge it, you can do the necessary statistical interpretation. And then you can actually be well-informed in your decision-making.

+ +

There's nothing either about the data, about the form factors, about battery life, about the performance of these tools that is stopping us from building and deploying solutions that work for everyone starting today, starting immediately. So then, what is the barrier? The barrier is a knowledge gap, a skills gap, an incentives gap. And that's really what we've been hammering to address.

+ +

And if you do look at our DEI resources, especially for digitized clinical trials, we try and think about all of those gaps and support people, whether it's through, here, let us educate you on actually where some of the risks are, some of the new vectors of inclusion or domains of diversity, especially at the intersection of digital and health. Let us support you with tools and resources, and guides for how to do this.

+ +

And then let us give you data and let us give you things like a market opportunity calculator, which is something else that we've created that will actually give you the business case to be more inclusive in the way that you develop digital products for use in clinical trials and the way you deploy them to support better research. That's really what we're focused on.

+ +

And so the surprise almost is that the tech isn't limiting us in any way. The flip side of that being we are not going to tech our way out of this. It comes down to humans and our decisions and how we develop and deploy these tools in the service of better health.

+ +

VICTORIA: That makes sense to me, and it makes me think about there's like a moral obligation or value that you can apply to DEI, but there's also a financial aspect. [laughs] And if you put a lot of effort into building an app, for example, and don't think about inclusivity, and you get to the end and think, oh, now I have to go back and make it accessible, that can be a lot of rework. It can be a lot of cost, if not even a legal liability and financial liability, I would imagine, in the healthtech sector.

+ +

JENNIFER: That's exactly right. I couldn't have said any better, Victoria. [laughs]

+ +

VICTORIA: [laughs] It's like, you are morally and legally obligated in many cases to include people. And it's better to just start from the beginning and start from the beginning and knowing what we're trying to do.

+ +

JENNIFER: 100%. And I was trying not to pile on because I think the statement just stands alone. We are morally obligated. In some cases, we are legally obligated. There are emerging regulations certainly in the clinical trials environment about having more representative samples in order for you to get regulatory approval, for example. One of those regulations is moving slowly, which is always frustrating and disappointing. But given the moral imperative, given the emerging regulations, given that finally, this is more at the forefront of conversations, you've got to think about the gymnastics that are happening to continue to avoid doing this. And that's a little bit of the pressure that we want to apply.

+ +

And so when we talk about the fact that there's no technological reason for not doing this, and when we have tried to provide the tools and resources to actually put these tools into practice, the only remaining question is, are you going to do it? And that's a big question. And as a field, we've not been terribly good at leaning into that previously. We'll talk about it all day. We'll admire the problem of inequity all day. We haven't been good enough at acting. And I'm hoping we're at a tipping point.

+ +

VICTORIA: Great. And it sounds like now with DiMe, there's no excuse. All the information is there for you. [laughter]

+ +

JENNIFER: That was exactly what we tried to do. That was the challenge that we gave ourselves and this extraordinary team. And the different individuals and organizations that came to the table to do this they set the standard high. And I'm so proud of their sort of possession, of their courage, and their tenacity in saying, "We are going to serve up absolutely everything that's needed. We're going to present it in a way that it's almost impossible not to find what you need for every person who's coming with this question." We set the standard high, and I'm incredibly proud of how well we delivered on that.

+ +

VICTORIA: What does success look like for DiMe in the next six months or in the next five years?

+ +

JENNIFER: What is it? Is it a Bill Gates quote? Is it...you sort of overestimate what you can do in 6 months and underestimate what you'll do in 10 years, something along those lines. And the intention is there, though. Anyone who knows me well will probably say I've never underestimated anything in my life. I'm always pushing for the next thing. Let's come back to this notion that the tech is not the limiting factor. And we're facing a really interesting moment in healthcare where the current environment is simply not sustainable. There are not enough clinicians to provide care or conduct research. We've had an expensive healthcare system for a long time.

+ +

But the prices are not sustainable when you think about how much health insurance is going up relative to inflation, when you think about the out-of-pocket costs that people are facing when you think about the fact that there's not a single healthcare executive who's sleeping well at night because they can't staff their units, and their supply chain costs are incredibly high. And they're worried about the sustainability of their hospital, especially in rural and underserved areas. Business, as usual, is not an option.

+ +

So in the next six months, I think we're going to keep pushing along. But in that five-year window, I think we are going to see a fundamentally different way that we care for people in the healthcare environment and that we conduct clinical trials. No longer is healthcare going to be built around the clinic. That's not to say they're going to go away. There are, of course, going to be times where you need to see a clinician in person, where you need to have a procedure, where you need to have some lab work or imaging done.

+ +

But so much of this can be translated into the home, can use tools to extend the knowledge and expertise of clinicians so that we can better care for people, all people, by meeting them where they are. I think we're going to see a fundamentally different kind of healthcare, different kinds of clinical research built around the patient, not the clinic. And part of that is going to be redefining what good healthcare even is. Currently, good healthcare is once you turn up at the clinic already sick, sometimes really sick, facing a catastrophic and likely very expensive outcome, we do our best. That's good healthcare.

+ +

I really think we're going to drive towards a future where these new flows of data and these new technologies are going to actually allow us to try and mitigate disease earlier, to intervene earlier, to catch all people who are at risk earlier in their health journey. And the great thing about that is it offers the opportunity to define healthcare differently. All of a sudden, good healthcare isn't; how good are we at intervening when you're sick? But how good are we at keeping you well and keeping you out of the healthcare system?

+ +

I also feel strongly that it is no longer going to be enough to just raise the top end of healthcare and provide the best care to the people who are able to afford it, that we are going to start to embed metrics around equity into our evaluation of good healthcare. And the sooner we do that, the better because every time we look at those numbers now, they are astonishingly bad.

+ +

VICTORIA: Yeah. And it's making me think about, you know, in five years, if we continue with the trend of global warming, they're also predicting more pandemics, more disease. And it seems like we are going to have to reimagine how we do healthcare because the current path isn't sustainable.

+ +

JENNIFER: Exactly right. Exactly right. And the sad thing about all of this is that the burden of things like climate change, the burden of pandemics falls on those communities and those individuals who have been underrepresented and underserved in healthcare for the longest. It increases the burden of disease and health stress on folks who have consistently carried the highest burden of disease, been part of the highest risk categories. Not only do we have to get better at delivering care to all people reducing the burden of disease, we have to do it where actually those challenges through all of those external pressures, Victoria, are going to be becoming worse.

+ +

VICTORIA: And it reminds me of another term I've heard for underrepresented, which is historically excluded, which I think really applies here. So that's fascinating.

+ +

JENNIFER: Because it is what it is.

+ +

VICTORIA: Yeah, right? Like, that's what it is. So I think it's wonderful that's what you're working on. And let's see if you could go back in time to when you first started DiMe Society; what advice would you give yourself now that it's been three years and you've come a long way?

+ +

JENNIFER: [laughs] Sleep more. [laughter] I don't know, when I look in the mirror these days, there's an old lady that I'm sure wasn't there at the beginning of all this. But I think that's not the spirit of the question you were asking, Victoria. I wish we'd been bolder sooner. And we've never shied away from tackling the hardest problems. We started with this bold mission and vision.

+ +

People would ask us when we launched DiMe, you know, "Gosh, are you really focused across individual health promotion, across healthcare delivery, across public health, and across clinical research?" And we said, "Absolutely," because if we don't tackle it all together, we're simply going to create new silos in the digital era. And we're never going to move towards this reimagined healthcare system, a new healthcare system, one that cares for everyone and where access to research is even harder than access to care.

+ +

With these new flows of data in the digital era, we want to do it together. So it's not that we weren't bold, but the way now we make strong statements that we've always believed and that we've always been proud of around the imperative to be inclusive around the demand for high-quality evidence to drive trust around the fact that none of this is a tech issue. It's a human issue. I wish we had gone there sooner. I think it is serving us well.

+ +

I think that the professionals that we work with across industry respond to it. They want to be part of this journey. They want to build a better healthcare system. And so, while we've always been, I think, bold and courageous in the vision that we've held and the work we've done, giving voice to it in a way that really reflects our vision and our passion has been so well received by our community. And they have stepped up to do this work incredibly well. I just wish we'd gone there sooner. That's the only thing I would have done differently.

+ +

VICTORIA: I think that's great advice, especially for founders who are starting out in a space like this, to really stand by their convictions and be bold about it. [chuckles] Like, this is what you believe in, and other people will connect to it if it's right, so I love that. And we're getting towards the end of our time here too. So I want to make sure I can pass it to Geronda if you have any other final questions for our guest here today.

+ +

GERONDA: More a comment in that I think that learning more about your organization and perusing some of the tools that you offer and the checklist that you offer...and it's such great work. And in some ways...and I'm trying to get the best way to say this. But in some ways, it's so clear of, like, this is what you can consider. This is what you should do. Although the work is not easy to do, it's really a helpful guideline for how you can start to think differently.

+ +

I really appreciate the thoughtfulness that was put into a lot of these resources that you're giving out and just where you are in your trajectory as well because DEI work is not easy work. And you sometimes...it can impact you emotionally. It can impact you mentally sometimes. But when you're continuing to go after what you know is needed and the intentionality of things, it really is super helpful.

+ +

So although I said I didn't have a question, and I just had a comment, I lied. I do have a question. [laughter] My question to you is, in doing a lot of this work, ensuring that DEI is infused in healthtech, all the work that you do and that your team does, how do you just navigate and manage your well-being, your mental health, your emotional health as you continue to do all this work?

+ +

JENNIFER: It's such a great question. And when you said, Geronda, that this can sometimes be really emotional, I heard a statistic actually from a colleague of mine, Ricki Fairley, who's the CEO of Touch, Breast Cancer, and she was telling me that cancer affecting women under 35, Black women under 35 are diagnosed with cancer at a rate twice that of White women and die at a rate three times higher than White women. And, I mean, you hear that statistic, and it just takes the wind out of you. And it would be really easy to hide from that because it's hard to hear, sometimes too hard.

+ +

The way that we handle sort of all of this as a team is we square up to these data, and then we celebrate one another. We celebrate our community when we are able to make positive change, even if it's incremental change. Even if sometimes you have those moments where you really move the needle, you have those other days or those other initiatives where you feel like you're crawling on your hands and knees to gain inches.

+ +

But to celebrate that every moment and to remind ourselves the work is returning value to those people that we all get up every morning to try and serve, that it might be hard, but we're making progress. And that is, I think, the way that, as a team, we stay positive, we stay productive, and that we're able to balance, frankly, the exposure to the reality of some of these issues.

+ +

GERONDA: I think that's great, having a community even within the workplace. It's so crucial because you spend most of your time at work, as we all know. [laughs] And there's a lot that just goes on across the world all the time, and being able to just talk it out. We have employee resource groups for people to come together with common identities and just talk through things that are impacting them. And so I really think that's great that you're able to just be honest with how you're feeling but also celebrating those important positive moments because sometimes we can focus a lot on the negative. So I really love that you bring the positive aspects of that as well.

+ +

VICTORIA: Yes, thank you for sharing, and it comes back to the intention. Like, we're all on the same page. We all have this intention of solving this problem. So we're in it together in a way. So, Jennifer, are there any final thoughts or takeaways you want to leave our listeners with today?

+ +

JENNIFER: No, this was a fantastic conversation. I think we've drawn out this theme of intentionality that will serve all of us very well. Geronda, I love the final question about how do we keep our own sort of emotional state and mental health solid as we do this hard work? It's the perfect note to end on. So Victoria, Geronda, thank you so much for having me on. This has been just a wonderful conversation. I've really enjoyed it.

+ +

VICTORIA: Wonderful. Thank you so much for joining and spending time with us today.

+ +

JENNIFER: Yes, I very much appreciate it. This was an awesome conversation.

+ +

VICTORIA: All right. And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Jennifer Goldsack.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jennifer Goldsack is CEO of Digital Medicine Society (DiMe), the professional home for digital medicine. It is a global nonprofit with a mission to advance the ethical, effective, equitable, and safe use of digital technology to redefine healthcare and improve lives.

+ +

Victoria talks to Jennifer about using new products and solutions to solve some of the most pressing and persistent challenges in healthcare, measuring success by how well they are caring for people every day and not by how good their products or how many they use on any given day, and how DiME can improve the way that we identify, manage, cure, and support people in a lifetime journey of health and disease.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Jennifer Goldsack, CEO of Digital Medicine Society, the professional home for digital medicine. Jennifer, thank you for joining me.

+ +

JENNIFER: Thank you so much for having me; excited for our conversation today.

+ +

VICTORIA: Wonderful, me too. And we have our Program Manager for DEI Geronda with us today. Hello.

+ +

GERONDA: Hey, how's it going? I'm super excited to be on here as well.

+ +

VICTORIA: Yes, me too. It's going to be a great conversation. So, Jennifer, why don't you just tell me a little bit more about the Digital Medicine Society?

+ +

JENNIFER: Happy to, one of my favorite topics, Victoria. So the Digital Medicine Society, or as we affectionately refer to it as DiMe, is a global nonprofit, and our mission is to advance the ethical, effective, equitable, and safe use of digital technology to redefine healthcare and improve lives.

+ +

And I think one point I'd like to make right off the bat is while we are tech and digital enthusiasts here at DiMe, we are not tech determinists. What we think about is how can we harness the promise of these new digital tools in the toolbox, these new products, these new solutions, and how can we use them to solve some of the most pressing and persistent challenges in healthcare, an industry that exists to care for people? That's what we think about all day. That's our measure of success: how well are we caring for people every day, not how good are our products or how many products can we use on any given day.

+ +

VICTORIA: Right. So what did you see in the digital health space that led you to believe that something like DiMe needed to exist in the world?

+ +

JENNIFER: So it's interesting. When we take a step back and think about all the experts that need to be at the table to ensure that we build a field of digital health that is worthy of our trust, in our opinion here at DiMe, we think this is the most interdisciplinary field you can imagine, and that's a bold claim. But let me play it out for you. And maybe we can think about some other interdisciplinary fields during the course of our discussion.

+ +

For digital medicine to work, we need citizen scientists and cyber security experts. We need physicists, engineers, product folks, data scientists, clinical scientists, clinical care providers, healthcare executives, regulators, payors, investors, funders all to sit at the table together, all to speak a common unifying language, all to have a shared idea of what our North Star is. What are we trying to do here as we digitize healthcare, and what does good look like and for whom as we do it?

+ +

And so that's the gap that the Digital Medicine Society was introduced to fill. That water cooler, if you like, where the leaders in our field can share their expertise and where we can very intentionally build a much better future for healthcare using the new digital tools in our toolbox.

+ +

VICTORIA: Interesting. And I like how you pointed out for whom. [laughs] And I see digital equity is a big topic that you're focused on with the organization. Can you tell me a little bit more about that?

+ +

JENNIFER: I'm happy to, and in our opinion here at DiMe, equity has to be front and center of everything we do. I think too many times we look across and considerations around diversity, equity, and inclusion; they're part of a rubric. They're a vertical. That's not what we think here at DiMe. We have to think about diversity, equity, and inclusion in everything that we do as we work to digitize healthcare. We know that there are pressing, persistent, and absolutely inexcusable inequities that exist across the burden of disease, across access to care, across the quality of care you're able to access, the care that you can afford. We know that all of those things introduce a long-standing history of inequities in health and healthcare.

+ +

As we digitize the healthcare industry, it's unacceptable for us just to be thinking about, hey, as long as we don't make things worse, that's not acceptable to us. We are thinking at every turn about how can we improve the way that we identify disease, the way that we manage disease, the way we cure disease, the way that we support people in a lifetime journey of health and disease? And how can we make sure that we do that for everyone in a way we've never been able to before?

+ +

So while I could talk about some of the projects that we've done that exclusively focus on advancing health equity through the use of digital tools, it's actually something we keep front and center in everything we do, in everything we talk about here at DiMe and something that we try and compel every single person in the field to think about to make sure that we seize this opportunity.

+ +

GERONDA: I think that's fantastic. And something that you hit on that it's really important for us at thoughtbot is continuous improvement. And that intentionality is incredibly important when it comes to DEI efforts. And so one thing that we do have at thoughtbot is we have trainings, and we try to work toward a shared language. But we do understand that everyone is at a different point in a different journey towards DEI to be able to build and design the best products and provide businesses to our clientele.

+ +

So I'd love to hear more about how your organization does consider that continuous improvement for all employees across the organization in terms of ensuring that you're enforcing shared language across the organization to be able to continue to have really great care for your people.

+ +

JENNIFER: Geronda, I love this. And I think that you've touched on something that's really important, which is while we can be collectively frustrated, perhaps even angry, about the health inequity that we see on a daily basis and that we frankly have not addressed as an industry for decades and decades...and quite frankly, I think we should be frustrated; we should be angry. Not taking the time to meet people where they are as they make a commitment to designing, developing, and thinking about the business incentives that they need in order to do this work well and to be intentional is actually incredibly counterproductive. So we always start with that shared language.

+ +

When we talk about inclusion in digital health, we need to not just think about all of the different vectors of inclusion and domains of diversity that we've developed as a healthcare industry, but we need to think about those vectors and domains at the intersection between healthcare and digital. And if we do nothing else beyond educate the field on what those domains and vectors are so they can be intentional, is they think about, gosh, what's the healthcare problem I want to solve for, for whom? How do I need to consider the needs of our intended users as I do that? That in and of itself is going to take us so much further than we are today.

+ +

But I'd also love to learn from you guys. I love the three-part way you describe your work, that you think about designing, and then developing, and then getting the business of great product development right. How do you guys think about it? I'd love to be able to learn from you too.

+ +

VICTORIA: One thing I know, speaking specifically to the intentionality that you mentioned, so if you're building an AI product and you're not intentionally thinking about DEI, you can actually build bias and problems into the code itself. So for us, and, Geronda, I want to hear your perspective here too, consulting with experts in the field, especially in DEI early and making a culture where we do have a program manager of DEI. So I've really pinged Geronda several times already this year about, like, I have this question about this. And I think having access to an expert and having access to knowledge that you should go back and check yourself is part of it. But do you have anything you want to add there, Geronda?

+ +

GERONDA: I definitely agree with everything that you had said, Victoria. And also what I'll add too is that it is really thinking about in everything that we do, how do we bring DEI at the forefront? And recognizing, as I mentioned before, that everyone's in a different place. So it's not to say that if you mess up or if you didn't consider something that, you can't continuously improve. And we have this culture where I'm not going to come in as the DEI police to say, "How come you didn't consider that?" Or "Why didn't you think of that earlier?" It's more to say, "Oh, okay, well, here's how we can approach this differently."

+ +

And everyone's pretty open to the feedback and the learning. And so one example that I'll give is that our website, thoughtbot.com, we're right now working towards accessibility for our website so that we can offer it more to those with disabilities, or those that are visually impaired, or hard of hearing, and offer it to be more accessible for anyone who goes to our website. And it's a learning curve for quite a few of our folks.

+ +

But the learning library that's offered in there to say, okay, I may not know everything about how things impact those that may be visually impaired, but let me educate and help to develop this website in a way that's going to support them. So to Victoria's point, it's infusing DEI in every way that we can. And what I love as well is that we do have a DEI Council, and we do have a shared platform to bring about issues or have those discussions and ask the questions so that you can continuously improve yourself to make sure that you're developing and infusing DEI across the work that you do.

+ +

So great question and I really feel like it's, of course, a work in progress. But we're in a really good place where we can continue to have that continuous improvement through education, and learning, and feedback to correct ourselves.

+ +

VICTORIA: Yeah, I love that. I think that having the culture at least puts you in a good starting place. [laughs] I'd love to hear more about what projects you've worked on in that space, specifically, Jennifer.

+ +

JENNIFER: So, first of all, I love how you talk about this idea of you need to have a culture in place that allows us to assess opportunities, that allows us to identify the kind of work we need to do based on where we are today. And then once we've assessed those opportunities, once we've identified potential pathways, we actually then have the support and the right environment to be able to implement these best practices.

+ +

And there are two things that I'd love to highlight. The first is actually education resources and specifically education resources on applied digital health ethics. I think creating this culture of ethics which is absolutely inextricable from a culture of equity, is critically important. You need to have those folks on staff just like you guys do. You need to be able to go to potential end users and communities and have line items in your budget to reimburse them for their time and their expertise.

+ +

You need to be able to have goals and performance metrics that actually reflect the success you're having or where you're struggling when we think about building a more inclusive environment. So that's a lot of what we try and fuel through our applied digital health ethics education. That's something that's a direct-to-learner option for folks; we're very proud of. We've had fantastic reviews and testimonials. We had tremendous faculty help us with that curriculum, and it's been really well received. And we are confident in the change that that education resource is driving in the field.

+ +

The second is actually a suite of resources that we launched more recently, and this is where I can start to get really tangible. So as an organization, we convened a broad and diverse group of experts to really tackle the issue of diversity, equity, and inclusion in digitized clinical trials. And I use action-oriented words like tackle very intentionally. Unfortunately, what we see an awful lot of the time is people admiring the problem, for want of a better expression, that we'll see endless panels at conferences and op-eds, and these sorts of things being written about the current state.

+ +

But what we were determined to do is own the fact that there is nothing technically prohibiting us today from deploying these digital tools and resources in the service of advancing diversity, equity, and inclusion while simultaneously addressing some of the long-standing clinical issues, while simultaneously addressing some of the regulatory science issues, while promoting access, while making sure we generate better data for better clinical decision making.

+ +

This is not an either-or. This is not a trade-off. We are not limited by the technology; we are powered by the technology. It requires our intent and our commitment to actually doing this work. So I'm going to pause there to see if Geronda or Victoria you have questions on any of that. And then I can certainly go into more detail about those tools if that's interesting.

+ +

GERONDA: It's super interesting. And I do have a question. But I'll kind of recap and understand that by having those different broadened expertise, you're having multiple people come together with this expertise so that you can ensure you're providing the best data to help you make those equitable decisions. Does that sound about right?

+ +

JENNIFER: That's exactly right. I think that as fantastic and expert as our team are, we are merely representative of a broader community that is doing this excellent work out every single day, trying to improve the way we care for people, representing different communities, building tools. And unless we bring not only those innovators from different backgrounds to the table but also representatives of the communities we're actually working hard to serve to the table, our efforts will be inadequate. And that's why we're so committed to this multidisciplinary, pre-competitive, and collaborative work as we build our tools and resources here at DiMe.

+ +

GERONDA: Yeah, and that's amazing. The question that I have for you, the follow-up question to that, is we try to look across...our company is global. We do have employees in many different countries across the globe. So trying to ensure that we have an understanding of the needs on a global scale can sometimes be challenging. Can you speak more to this multidisciplinary broadened expertise and how they might bring in perspective that can help shape your technologies or even clinical trial project in a way that supports different ethnicities across the globe and how they identify and even intersectionality of folks as well, so not just race but also LGBTQ or other races as well like socioeconomic status?

+ +

JENNIFER: It's such a good question, and it's so important. And I think one of the things that I have frankly learned an enormous amount and really taken to heart are these many different domains and these many different vectors of inclusion. Now, first of all, if we start saying, look, we have to consider these 50 (I'm being facetious, intentionally so.) different considerations, then we're going to become so overwhelmed so quickly that we become absolutely ineffectual as we try and think about serving all of these different individuals.

+ +

But, Geronda, you gave fantastic examples around the hard work that you've been doing even in your own website environment to make sure people who are differently abled...they might have certain vision or hearing impairments or whatever that might look like, and they can access your resources. They can interact with your team just as easily as anyone else. So I'll give you an example of something that had never occurred to me until we actually started working with a member of a community who represented this particular part of the workforce.

+ +

We were talking about actually how we can use a variety of different tools to monitor respiratory illnesses and diseases. You can think about things like asthma. You can think about things like cough was an important symptom of COVID, for example. How can we use the microphones that you might find in your smartwatch or your smartphone? How might we use these to be able to monitor, predict and track disease?

+ +

We'd gone through how does different socioeconomic status, how does place, how does race, or ethnicity perhaps play into your access to these different tools, your tech literacy, your trust in these different tools and products? What had not occurred to me at all...and I'm so embarrassed to say this, but you think about you can have a tool where you do all of the work around inclusive design. You can think about all of the different needs to earn the trust of the communities that you're asking to use these tools. But we hadn't contemplated how you might use these tools if someone, for example, worked in a work environment where it was incredibly loud.

+ +

If you're on a building site, if you're in a warehouse, if you're working on a checkout, it doesn't matter how good the sensor is in your smartwatch that you may have been provided with because that work environment is going to absolutely drown out any signal from that stream of data. And so we need to think about all of the different ways that someone's life, and career, and their background, and social determinants affect our ability to develop and deploy tools that really can help them manage their health, improve their health, have better health outcomes.

+ +

GERONDA: That's amazing.

+ +

VICTORIA: That's amazing. And I wonder if you've encountered too an issue with if you're designing these applications...like I know when I was living in Washington, D.C., there were 3,000 people who don't have internet at home, don't have a computer, don't have a phone. So how would your team approach that kind of problem?

+ +

JENNIFER: [laughs] I think this is the theme of our conversation.

+ +

VICTORIA: [laughs]

+ +

JENNIFER: With intentionality, which is, is the goal here simply to provision tools and technologies, or is our goal here to be more thoughtful about the tools that exist, that we can use? Is our goal here to think about digital infrastructure and how we should be thinking about that not just to power healthcare but also perhaps access to education, access to safe and secure bank accounts, all of these different sorts of things?

+ +

We cannot assume that every single person has top-of-the-range technology, unlimited data plans; we are foolish to do so. But the first thing we need to do is actually ask and understand what access to technology looks like and not just assume it's an affordability issue. Maybe it's a trust issue. You have to understand the root cause before you can work to solve something.

+ +

I'd also offer up some other data that I always find compelling and important as we have these conversations. While we know there are large portions of the population who don't have access to what some of us, unfortunately, when we're moving quickly, just assume that everyone has, there are also horribly underrepresented populations, represented populations that do have access to these technologies. Some recent data actually showed that one-third of homeless individuals in California do have a smartphone. Let's actually just pause and think about that for a moment.

+ +

You can't get access to benefits or brick-and-mortar healthcare because you have to go and fill in all of your information if you don't have a home. But if you have a smartphone, which presumably many of these folks have realized that even at some of the hardest times in their life, they actually need that to stay connected in today's digital economy, that this is actually a way and a vector for us to reach them, for us to capture information and data about what it is they need, not just to improve their healthcare but to get supported into a more safe and sustainable environment with more security where we can actually support their health in a much more holistic way.

+ +

It also can connect them with care, whether that's mental healthcare or whatever their needs are in any given moment, that if we were relying on the traditional brick and mortar system, we'd be unable to capture. So this goes back to two things. First of all, don't assume. Don't assume that people do or don't have technology, and if they don't, don't assume you understand what the root cause actually is. The second point is don't think about these digital tools as limiting factors; think about the ways that we can use them to overcome so many of the challenges that we've faced in the way we care for people for decades and decades.

+ +

VICTORIA: I love that you bring that point up. I volunteered for many years with an application called HopeOneSource, which is a mobile app for people who are experiencing homelessness to get access to services that they need. And I know it might have changed over time, but it was like 80% of people who are experiencing homelessness do have a cell phone. And partly in the United States, there is a subsidy. If you're under a certain income level, you can get a free cell phone.

+ +

But it's very easy to have your cell phone stolen or to get lost. And the impermanency of the device is also an issue. So I think it's actually, like you said, you don't want to make assumptions about what people have and what they don't. And you do want to bring the intention and understand what it's really like because that will change how you build in things like security and two-factor authentication and things like that. So...

+ +

JENNIFER: That's exactly right. And also, what are some of the infrastructure things we can do? You mentioned the subsidies for folks who are low-income. But then we want people to start transmitting confidential and private information about their health in order to access the highest quality care possible. Are we creating environments where there is access to secure connection environment? So they're not using public Wi-Fi where they actually might be more susceptible to harm due to sort of misuse of that data if it falls into the hands of the wrong folks.

+ +

These are all of the different things we need to be thinking about. That's not to slow us down or to dampen our enthusiasm for the opportunities that digitization provides to improve the way we care for people. But again, it comes back to...I think what's emerging is almost a theme of our discussion, which is the need to be intentional.

+ +

GERONDA: I love what you said about not making assumptions because I'm a DEI practitioner, but I always tell people I'm not perfect. [laughs] And so my bias comes in sometimes. I sometimes will assume that I might know the answer to something or what somebody may be experiencing because I may be incredibly passionate about the LGBTQ+ community, which I'm a part of. And it's reminding myself that I can't assume or let my own biases or own feelings towards certain things to steer my decision-making.

+ +

I really have to be super open and objective to what the facts are telling and get those other experiences from other people. So I continuously check my bias, and I continuously try not to make those assumptions which can be hard at times. And while I know everyone at thoughtbot thinks I'm perfect, I'm the best, [laughter] it's just not true.

+ +

VICTORIA: I think it is true. [laughter]

+ +

GERONDA: There you go.

+ +

JENNIFER: Geronda, I so appreciate you sharing that, and I think it probably is giving everyone listening the same experience that I am having right now, which is you owning that and being willing to share that. Immediately cascading through my mind...and now all of the assumptions that I come to the table with, and all of the ways that I think about things and those hot topics that are unique to me and my lived experience, and what I've been exposed to. And on the one hand, we should never dismiss that. On the other hand, the definition of being inclusive is to go out to folks with those different viewpoints.

+ +

And one of the things I see increasingly featuring in these sorts of domains of diversity is political views. And you think, gosh, how has this even become a thing in the way that we consider caring for people? But it's so divisive. And I come to the table with all of my thoughts about these kinds of things. But what's serving us about our lived experience and about the passions that drive us all to try and create better products and a better and more inclusive future, and what's not? And how can we humbly acknowledge that and really listen and hear what others are telling us?

+ +

GERONDA: Right. Exactly, exactly.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

VICTORIA: If I'm a clinical researcher and I'm about to design an experiment, let's say, how can I use the resources at DiMe to help inform my opinion and help bring in that inclusivity, which I want?

+ +

JENNIFER: So, Victoria, great question. [laughter] I'm teed up to answer this one. So I think the first thing is, and, Geronda, this is something that you mentioned earlier, which is you don't do a 45-minute brainstorm before you get going, check a box, and say you did it. It's a continual process, and it's a process of continual improvement. So when we describe this, we would discuss the entire clinical trials lifecycle. So, first of all, there are DEI considerations, even in the kind of question you want to answer.

+ +

If you are doing clinical research because you want to develop a new molecule, a new pill, or something, for example, what community will you be serving? What's the problem we're trying to solve for? Are we trying to add a me-too drug to a population that's already well-served? Or are we actually thinking about, gosh, there's this underrepresented population? There's a disease state where we've struggled to break through. We believe that we can deploy these digital tools in order to really effect change here. So it starts as early as what is the problem you're trying to solve for? What is your research question?

+ +

Then each stage as you think about, gosh, what are the tools that I might want to use in order to answer this question? Who are the people that we could possibly serve through the development of this new drug, for example? Great, then we take seriously our responsibility of making sure that every single individual who participates in our trial reflects and represents that broader population, that we are going to take inclusivity seriously so that when we have an answer to our research question, we know that what we know about the safety of a new drug and what we know about the effectiveness of a new drug applies equally well to every member of the population.

+ +

At that point, we're asking ourselves questions about as we think about parts of the clinical protocol, so the different steps that we work through in order to safely administer a new therapy that's part of the trial, as we think about capturing the information we need in order to determine whether it's safe and effective, are we setting that up to be as safe as effective for everyone? Are we able to design the trial in such a way that the burden of participation isn't a barrier for certain members of the community?

+ +

If we're picking digital tools to do things like remote patient monitoring...so imagine for anyone who has a smartwatch the green light on the back of your watch that's measuring your heart rate. Unfortunately, some of those products work differently across different skin tones. Have you done the work to make sure that you're selecting a tool that is going to give you equally trustworthy information for every single person? These are all of the things step by step that you should think about as you are developing a clinical trial.

+ +

We have tool after resource after checklist to help you do this in a really accessible way. We organize them so you can find them really easily based on either what stage am I at and what can I do today to be more diverse, and more equitable, and more inclusive in the way that I'm developing new medicines? We also allow you to find these tools and resources based on a particular digital product.

+ +

So if, for example, you think that you might be able to use, and we haven't said the words yet, so it's probably time, AI or machine learning to better identify a more diverse patient population that you could enroll into your trial, how are you thinking about catching potential bias that might take your good intentions and actually render them almost useless because you didn't identify bias in the algorithm, for example? So all of those tools and resources, and there are over 60 of them available, are open access. They're free to download, use them, interactive checklists, considerations documents, tools, and resources that help you act today as soon as you make a decision about doing clinical research that benefits all people.

+ +

GERONDA: And it almost sounds like, in a way, that this resource could be helpful for many other industries as well because although it's tied to clinical trials, the considerations and process that you're taking to start to think through those DEI elements that checklist can be helpful across many different disciplines. Would you say that's correct?

+ +

JENNIFER: I would. Now, Geronda, our superpower, is getting the digitization of healthcare right. And that's a big enough task that while there are other pressing areas, we will not stray into those. But I think you've hit the nail on the head. When we think about getting access to education, for example, or access to safe housing, or any other kinds of benefits, and we can think about how some of these digital tools can overcome many of the different barriers to access that different communities face. Absolutely, all of these different principles can apply. And in fact, we actually think that's really important.

+ +

We talk a lot about harmonization in the work that we do. There are folks who have product portfolios that span different industries. When we think about really trying to hammer home the need to be intentional, to make sure that as we digitize the healthcare industry, we are bringing everyone with us, we should avoid, wherever possible, having unique or special considerations. Ultimately, these are all the same humans that we serve in other industries. We are trying more than ever to meet people where they are than insisting they come to us or come to the clinic, for example.

+ +

All of these principles apply equally well. And if we do that harmonization well...and this comes back to the idea of culture that we were talking about. This just gets embedded into the culture of developing products for every single person, regardless of whether that's an educational product, or a healthcare product, or a financial product. We should be thinking about these things regardless of how we're striving to help and support people.

+ +

GERONDA: I love that.

+ +

VICTORIA: I love that. And I wonder, when you were developing these products for clinicians or for healthcare providers, was there anything surprising in your initial research and discovery when building these things?

+ +

JENNIFER: Yes. And I would say that technology is no longer the barrier. There is nothing that we need a product to do, whether that's the way we account for, right? You're not always going to eliminate it. But the way that we account for, for example, bias in the way that we capture and process data, if you acknowledge it, you can do the necessary statistical interpretation. And then you can actually be well-informed in your decision-making.

+ +

There's nothing either about the data, about the form factors, about battery life, about the performance of these tools that is stopping us from building and deploying solutions that work for everyone starting today, starting immediately. So then, what is the barrier? The barrier is a knowledge gap, a skills gap, an incentives gap. And that's really what we've been hammering to address.

+ +

And if you do look at our DEI resources, especially for digitized clinical trials, we try and think about all of those gaps and support people, whether it's through, here, let us educate you on actually where some of the risks are, some of the new vectors of inclusion or domains of diversity, especially at the intersection of digital and health. Let us support you with tools and resources, and guides for how to do this.

+ +

And then let us give you data and let us give you things like a market opportunity calculator, which is something else that we've created that will actually give you the business case to be more inclusive in the way that you develop digital products for use in clinical trials and the way you deploy them to support better research. That's really what we're focused on.

+ +

And so the surprise almost is that the tech isn't limiting us in any way. The flip side of that being we are not going to tech our way out of this. It comes down to humans and our decisions and how we develop and deploy these tools in the service of better health.

+ +

VICTORIA: That makes sense to me, and it makes me think about there's like a moral obligation or value that you can apply to DEI, but there's also a financial aspect. [laughs] And if you put a lot of effort into building an app, for example, and don't think about inclusivity, and you get to the end and think, oh, now I have to go back and make it accessible, that can be a lot of rework. It can be a lot of cost, if not even a legal liability and financial liability, I would imagine, in the healthtech sector.

+ +

JENNIFER: That's exactly right. I couldn't have said any better, Victoria. [laughs]

+ +

VICTORIA: [laughs] It's like, you are morally and legally obligated in many cases to include people. And it's better to just start from the beginning and start from the beginning and knowing what we're trying to do.

+ +

JENNIFER: 100%. And I was trying not to pile on because I think the statement just stands alone. We are morally obligated. In some cases, we are legally obligated. There are emerging regulations certainly in the clinical trials environment about having more representative samples in order for you to get regulatory approval, for example. One of those regulations is moving slowly, which is always frustrating and disappointing. But given the moral imperative, given the emerging regulations, given that finally, this is more at the forefront of conversations, you've got to think about the gymnastics that are happening to continue to avoid doing this. And that's a little bit of the pressure that we want to apply.

+ +

And so when we talk about the fact that there's no technological reason for not doing this, and when we have tried to provide the tools and resources to actually put these tools into practice, the only remaining question is, are you going to do it? And that's a big question. And as a field, we've not been terribly good at leaning into that previously. We'll talk about it all day. We'll admire the problem of inequity all day. We haven't been good enough at acting. And I'm hoping we're at a tipping point.

+ +

VICTORIA: Great. And it sounds like now with DiMe, there's no excuse. All the information is there for you. [laughter]

+ +

JENNIFER: That was exactly what we tried to do. That was the challenge that we gave ourselves and this extraordinary team. And the different individuals and organizations that came to the table to do this they set the standard high. And I'm so proud of their sort of possession, of their courage, and their tenacity in saying, "We are going to serve up absolutely everything that's needed. We're going to present it in a way that it's almost impossible not to find what you need for every person who's coming with this question." We set the standard high, and I'm incredibly proud of how well we delivered on that.

+ +

VICTORIA: What does success look like for DiMe in the next six months or in the next five years?

+ +

JENNIFER: What is it? Is it a Bill Gates quote? Is it...you sort of overestimate what you can do in 6 months and underestimate what you'll do in 10 years, something along those lines. And the intention is there, though. Anyone who knows me well will probably say I've never underestimated anything in my life. I'm always pushing for the next thing. Let's come back to this notion that the tech is not the limiting factor. And we're facing a really interesting moment in healthcare where the current environment is simply not sustainable. There are not enough clinicians to provide care or conduct research. We've had an expensive healthcare system for a long time.

+ +

But the prices are not sustainable when you think about how much health insurance is going up relative to inflation, when you think about the out-of-pocket costs that people are facing when you think about the fact that there's not a single healthcare executive who's sleeping well at night because they can't staff their units, and their supply chain costs are incredibly high. And they're worried about the sustainability of their hospital, especially in rural and underserved areas. Business, as usual, is not an option.

+ +

So in the next six months, I think we're going to keep pushing along. But in that five-year window, I think we are going to see a fundamentally different way that we care for people in the healthcare environment and that we conduct clinical trials. No longer is healthcare going to be built around the clinic. That's not to say they're going to go away. There are, of course, going to be times where you need to see a clinician in person, where you need to have a procedure, where you need to have some lab work or imaging done.

+ +

But so much of this can be translated into the home, can use tools to extend the knowledge and expertise of clinicians so that we can better care for people, all people, by meeting them where they are. I think we're going to see a fundamentally different kind of healthcare, different kinds of clinical research built around the patient, not the clinic. And part of that is going to be redefining what good healthcare even is. Currently, good healthcare is once you turn up at the clinic already sick, sometimes really sick, facing a catastrophic and likely very expensive outcome, we do our best. That's good healthcare.

+ +

I really think we're going to drive towards a future where these new flows of data and these new technologies are going to actually allow us to try and mitigate disease earlier, to intervene earlier, to catch all people who are at risk earlier in their health journey. And the great thing about that is it offers the opportunity to define healthcare differently. All of a sudden, good healthcare isn't; how good are we at intervening when you're sick? But how good are we at keeping you well and keeping you out of the healthcare system?

+ +

I also feel strongly that it is no longer going to be enough to just raise the top end of healthcare and provide the best care to the people who are able to afford it, that we are going to start to embed metrics around equity into our evaluation of good healthcare. And the sooner we do that, the better because every time we look at those numbers now, they are astonishingly bad.

+ +

VICTORIA: Yeah. And it's making me think about, you know, in five years, if we continue with the trend of global warming, they're also predicting more pandemics, more disease. And it seems like we are going to have to reimagine how we do healthcare because the current path isn't sustainable.

+ +

JENNIFER: Exactly right. Exactly right. And the sad thing about all of this is that the burden of things like climate change, the burden of pandemics falls on those communities and those individuals who have been underrepresented and underserved in healthcare for the longest. It increases the burden of disease and health stress on folks who have consistently carried the highest burden of disease, been part of the highest risk categories. Not only do we have to get better at delivering care to all people reducing the burden of disease, we have to do it where actually those challenges through all of those external pressures, Victoria, are going to be becoming worse.

+ +

VICTORIA: And it reminds me of another term I've heard for underrepresented, which is historically excluded, which I think really applies here. So that's fascinating.

+ +

JENNIFER: Because it is what it is.

+ +

VICTORIA: Yeah, right? Like, that's what it is. So I think it's wonderful that's what you're working on. And let's see if you could go back in time to when you first started DiMe Society; what advice would you give yourself now that it's been three years and you've come a long way?

+ +

JENNIFER: [laughs] Sleep more. [laughter] I don't know, when I look in the mirror these days, there's an old lady that I'm sure wasn't there at the beginning of all this. But I think that's not the spirit of the question you were asking, Victoria. I wish we'd been bolder sooner. And we've never shied away from tackling the hardest problems. We started with this bold mission and vision.

+ +

People would ask us when we launched DiMe, you know, "Gosh, are you really focused across individual health promotion, across healthcare delivery, across public health, and across clinical research?" And we said, "Absolutely," because if we don't tackle it all together, we're simply going to create new silos in the digital era. And we're never going to move towards this reimagined healthcare system, a new healthcare system, one that cares for everyone and where access to research is even harder than access to care.

+ +

With these new flows of data in the digital era, we want to do it together. So it's not that we weren't bold, but the way now we make strong statements that we've always believed and that we've always been proud of around the imperative to be inclusive around the demand for high-quality evidence to drive trust around the fact that none of this is a tech issue. It's a human issue. I wish we had gone there sooner. I think it is serving us well.

+ +

I think that the professionals that we work with across industry respond to it. They want to be part of this journey. They want to build a better healthcare system. And so, while we've always been, I think, bold and courageous in the vision that we've held and the work we've done, giving voice to it in a way that really reflects our vision and our passion has been so well received by our community. And they have stepped up to do this work incredibly well. I just wish we'd gone there sooner. That's the only thing I would have done differently.

+ +

VICTORIA: I think that's great advice, especially for founders who are starting out in a space like this, to really stand by their convictions and be bold about it. [chuckles] Like, this is what you believe in, and other people will connect to it if it's right, so I love that. And we're getting towards the end of our time here too. So I want to make sure I can pass it to Geronda if you have any other final questions for our guest here today.

+ +

GERONDA: More a comment in that I think that learning more about your organization and perusing some of the tools that you offer and the checklist that you offer...and it's such great work. And in some ways...and I'm trying to get the best way to say this. But in some ways, it's so clear of, like, this is what you can consider. This is what you should do. Although the work is not easy to do, it's really a helpful guideline for how you can start to think differently.

+ +

I really appreciate the thoughtfulness that was put into a lot of these resources that you're giving out and just where you are in your trajectory as well because DEI work is not easy work. And you sometimes...it can impact you emotionally. It can impact you mentally sometimes. But when you're continuing to go after what you know is needed and the intentionality of things, it really is super helpful.

+ +

So although I said I didn't have a question, and I just had a comment, I lied. I do have a question. [laughter] My question to you is, in doing a lot of this work, ensuring that DEI is infused in healthtech, all the work that you do and that your team does, how do you just navigate and manage your well-being, your mental health, your emotional health as you continue to do all this work?

+ +

JENNIFER: It's such a great question. And when you said, Geronda, that this can sometimes be really emotional, I heard a statistic actually from a colleague of mine, Ricki Fairley, who's the CEO of Touch, Breast Cancer, and she was telling me that cancer affecting women under 35, Black women under 35 are diagnosed with cancer at a rate twice that of White women and die at a rate three times higher than White women. And, I mean, you hear that statistic, and it just takes the wind out of you. And it would be really easy to hide from that because it's hard to hear, sometimes too hard.

+ +

The way that we handle sort of all of this as a team is we square up to these data, and then we celebrate one another. We celebrate our community when we are able to make positive change, even if it's incremental change. Even if sometimes you have those moments where you really move the needle, you have those other days or those other initiatives where you feel like you're crawling on your hands and knees to gain inches.

+ +

But to celebrate that every moment and to remind ourselves the work is returning value to those people that we all get up every morning to try and serve, that it might be hard, but we're making progress. And that is, I think, the way that, as a team, we stay positive, we stay productive, and that we're able to balance, frankly, the exposure to the reality of some of these issues.

+ +

GERONDA: I think that's great, having a community even within the workplace. It's so crucial because you spend most of your time at work, as we all know. [laughs] And there's a lot that just goes on across the world all the time, and being able to just talk it out. We have employee resource groups for people to come together with common identities and just talk through things that are impacting them. And so I really think that's great that you're able to just be honest with how you're feeling but also celebrating those important positive moments because sometimes we can focus a lot on the negative. So I really love that you bring the positive aspects of that as well.

+ +

VICTORIA: Yes, thank you for sharing, and it comes back to the intention. Like, we're all on the same page. We all have this intention of solving this problem. So we're in it together in a way. So, Jennifer, are there any final thoughts or takeaways you want to leave our listeners with today?

+ +

JENNIFER: No, this was a fantastic conversation. I think we've drawn out this theme of intentionality that will serve all of us very well. Geronda, I love the final question about how do we keep our own sort of emotional state and mental health solid as we do this hard work? It's the perfect note to end on. So Victoria, Geronda, thank you so much for having me on. This has been just a wonderful conversation. I've really enjoyed it.

+ +

VICTORIA: Wonderful. Thank you so much for joining and spending time with us today.

+ +

JENNIFER: Yes, I very much appreciate it. This was an awesome conversation.

+ +

VICTORIA: All right. And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Jennifer Goldsack.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+s5SP1l4P + + ]]> + + Victoria Guido + Jennifer Goldsack + + + 467: Healthie with Cavan Klinsky + https://podcast.thoughtbot.com/467 + aedf352a-f8e9-4d57-bbcc-231137d26816 + Thu, 23 Mar 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Cavan Klinsky is Co-Founder and CTO of Healthie, a scheduling engagement and EMR platform used by healthtech organizations who seek to build long-term relationships with their clients. + +Will talks to Cavan about providing an underlying infrastructure that other digital healthcare companies use to be able to focus on patient care and not reinventing the technology wheel by providing a scheduling platform, an electronic medical record, and a patient engagement solution–all available via API, via an API-first design as well as through fully branded interfaces. Healthie lets companies get to market faster, scale with less headaches, and provides effective patient care much cheaper than if they tried to build everything themselves. + 25:48 + no + + + Cavan Klinsky is Co-Founder and CTO of Healthie, a scheduling engagement and Electronic Medical Records (EMR) platform used by healthtech organizations who seek to build long-term relationships with their clients. +Will talks to Cavan about providing an underlying infrastructure that other digital healthcare companies use to be able to focus on patient care and not reinventing the technology wheel by providing a scheduling platform, an electronic medical record, and a patient engagement solution–all available via API, via an API-first design as well as through fully branded interfaces. Healthie lets companies get to market faster, scale with less headaches, and provides effective patient care much cheaper than if they tried to build everything themselves. +Healthie (https://www.gethealthie.com/) +Follow Healthie on Facebook (https://www.facebook.com/GetHealthie/), Instagram (https://www.instagram.com/gethealthie/), LinkedIn (https://www.linkedin.com/company/get-healthie/) or Twitter (https://twitter.com/GetHealthie/). +Follow Cavan Klinsky on LinkedIn (https://www.linkedin.com/in/cavan-klinsky-4a630940/) or Twitter (https://twitter.com/klinskyc). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Cavan Klinsky, who is a part of Healthie, a scheduling engagement and EMR platform used by healthtech organizations who seek to build long-term relationships with their clients. Cavan, thank you for joining me. +CAVAN: Thanks for having me on. +WILL: Yeah, I'm excited about this. Healthcare is always an exciting topic to talk about, so let's start there. For the people who may not know, tell us about Healthie and what's in store for 2023. +CAVAN: Healthie, as you mentioned, provides underlying infrastructure that other digital healthcare companies use to be able to focus on patient care and not kind of reinventing the technology wheel. So we do that by providing a scheduling platform, an electronic medical record, and a patient engagement solution. That's all available via API, via an API-first design as well as through fully branded interfaces. So we let companies get to market faster, scale with less headaches, and provide really, really powerful patient care much more cheaply than if they tried to build everything themselves. +WILL: Oh, sweet. Okay, so who is your main audience? Is it the patient, or is it the healthcare provider? +CAVAN: Healthie is a B2B company. So we sell basically the software to the digital healthcare organizations that are looking to deliver care, but there's a patient side of the platform. So they're able to onboard their patients. It allows patients to video chat with their provider, message, track goals, view care plans, et cetera. But our customers are the businesses. +So before Healthie, people would basically either try to cobble together like eight or nine different solutions to provide the experience they wanted, or they would spend millions and millions of dollars building in-house trying to piece together. But when you look at these different healthcare organizations, 90% of the functionality they're using ends up really being the same. +But people were trapped in this build versus buy decision where they were really concerned that they wouldn't be able to have a platform flashy enough for them. But the downside of that was just the cost of building that in-house. So Healthie really changes it from a build versus buy decision to a build and buy. So our customers buy the platform. They are able to launch very quickly. But because we're API-first, they are able to extend the pieces that are most unique to them. +WILL: That's really neat. Yeah, one of the most frustrating things I find, especially when it comes to visiting a doctor, is having to call in to schedule an appointment. And I'm like; I just need an appointment; just show me the available times. I want to select it and be a part of that. And so research shows your software takes care of that, correct? +CAVAN: Yeah, that's exactly right. And patients really, really love self-scheduling capabilities. When you talk to healthcare providers, if you ask a doctor, hey, why have they not embraced it? It's because they really want this fine-grained control over their calendar. A lot of them are used to calling the receptionist who's worked there for a decade and understands their preferences and how they want things sequenced. And they want this type of appointment able to be scheduled back to back but not this other type. +That's kind of really what we enable is we have this almost eye-wateringly long settings page where you can go in there checkboxes, configure things. And what you end up is just this really nice middle ground where patients are able to get that easy, self-schedule experience, not calling anybody, not waiting on hold. But doctors and other medical professionals aren't giving up control over their calendar. So it allows our customers to be able to do a lot of optimization, making sure their providers are fully booked but in a way where for patients, it's a really, really easy experience. And that's kind of a lot of the secret sauce that we offer. +WILL: Wow, that's neat. So tell us this, tell us about your background. How did you get started into the healthcare world? +CAVAN: So I got started in the healthcare world as I think a lot of people in this space which is I really got started as a patient. I had open-heart surgery after my freshman year of high school. I had eight weeks after that where basically I ended up kind of...I wasn't able to exercise, run around, kind of do most of the things I'd spend summers doing. So I ended up really stuck in a bedroom for most of it. +But that whole experience, kind of from prepping for the surgery, having it, recovering, got me really interested in healthcare and also really frustrated at just having a bunch of poor healthcare experiences. And it also really gave me time to start learning a lot about the engineering side of things. So I built my first web application that summer with Rails. So I found a lot of great thoughtbot posts, and I have a ton of respect for thoughtbot as an organization. I've been using Rails ever since. +WILL: Wow. That's really neat. I read an article about this. Tell us about your React Native experience because, at thoughtbot, we're trying to get that started. We actually are started, but we're trying to get that same momentum as we have with Rails. +CAVAN: So I think with React Native, initially, we were just a web platform. We realized very quickly that to enable a really strong patient experience...patients wanted to be using their mobile device. They don't want to be using a mobile web browser. They want a native application. So we initially launched, and this is maybe six months after we started the company, we launched an iOS app. We realized a couple of months later that we were going to need an Android application. +So we had a Swift and an Android application written in Java. We had a server-rendered Rails web application that we expose a very, very limited set of features via a REST API. And it worked out okay, but what we realized from doing that for about a year and a half, two years, was that we were duplicating a lot of work. The iOS app and the Android app were very similar to each other. But we had two separate developers who weren't able to really code review or help out the other. +We weren't a large enough company where it made sense for us to have a bunch of iOS developers and a bunch of Android developers. And then we were also duplicating a lot of functionality with this REST API, basically copied the things that we were doing just with server-rendered HTML. So in 2018, we had basically a from-the-ground rewrite of the whole web application, which was kind of a crazy experience. We moved to a single-page application on the web. We switched over to using GraphQL for everything. +And then we initially rebuilt our mobile application still using Swift and Java but now on top of GraphQL but really with an eye towards saying, hey, how do we end up getting off of these kinds of very siloed developer experiences and not to something where even if we don't have multiple developers who can do it, at least where developers can help each other out and understand? +So a few months after that, we kicked off our React Native rebuild. We built our whole mobile applications in React Native. Ultimately, having gone through a few different React projects, I think it's the only one in my life that kind of went as expected in a positive way. We did the rewrite. It came in on time. The mobile developers, instead of having an iOS and an Android, it was just two mobile developers who were able to help out each other and collaborate. +We can have web devs do code review for mobile, and they're able to provide feedback because we use React on the web. So it's definitely not write once, run anywhere, but I do think it's pretty close to at least understand everywhere. And that's been a really, really big thing for us. And then we're still able to bridge out to Swift or to Java for some more of the OS-specific features. +WILL: Yeah, yeah, I totally agree. That's the beauty of React Native, especially for your SaaS company. It's a perfect scenario because, like you said, web developers can code review. Sometimes they can even help with the code because it's right along the same lines and everything. So that's really neat. +CAVAN: Yeah, and we're able to share libraries, so, like, some of the NPM packages end up being the same. So it's just, yeah, it's been a lot of really, really nice experiences with that. +WILL: That's neat. So as the Founder and the CTO, what keeps you up at night? +CAVAN: I think what keeps me up at night is primarily for exciting things. We're in this position where we're seeing this huge sea change in how digital healthcare is delivered. Healthie is in this really nice balance where we're a mature company, you know, we're seven years old. We serve thousands and thousands of providers, millions of patients. But we're not like the Epics of the world, that are 35 years old and are just super resistant to change. +So we ended up in this kind of nice, sweet spot where we're tech-forward enough and flexible where we can really support these high-end use cases but then also basically mature enough where we have the scalability and the resiliency as an organization to be able to do that. So, I mean, a lot of what I think about is we provide business-critical healthcare, critical infrastructure for a lot of people. And that number continues to grow every day. It needs to work. It needs to work quickly. It needs to work securely. +And that's what, a lot of the time, I think about both from a technical perspective and then also as the organization as a whole grows, from a hiring and an organizational structure perspective. So I think you really go from hacking on the codebase day one seven years ago to kind of hacking on the organization as a whole. And that's really where I spend my time and what keeps me up. +WILL: That's neat. Wow, that's really cool. So as a first-time founder, tell me this, you've been around seven years. That seems like a long time, so kudos to you for enduring that and sustaining that. That's amazing. What are some of the things that day one when you started the company...if you could look back, what are some advice that you would give yourself to say, hey, don't do this or do this? +CAVAN: Yeah, the piece of advice I would give myself is advice we actually received pretty frequently and didn't believe, and then it ended up almost totally derailing the company. +WILL: Oh wow. +CAVAN: And that's that, you know, both my co-founder and I were first-time founders. I think we're really smart. We're definitely hard-working, you know, very motivated people. And we were really convinced that we'd be able to just do a full-out sprint and never stop sprinting. And we kept on getting told by advisors and investors, "Hey, it's a marathon. It's a marathon." We were like, you know, we're just going to sprint the marathon. That started out okay, and then a couple of years in, we started hitting walls and really realized that you can't sprint a marathon. +Startups take way longer than I think founders hope they do or think that they're going to take to develop. Digital health and our healthcare system moves much, much more slower than kind of people think. So especially if you're a founder in digital health, you need to be building both a company and, I think, a personal lifestyle that's sustainable. You need to make sure that the company has money in the bank and can be around for years and years and years. And you need to make sure that your job, your day-to-day, is something that you can also continue to do for years and years and years. +So that's ultimately, I think, the most important thing that we're able to tell our customers and something that we've now gotten the company in a position to be in, which is, hey, we're a sustainable business. We're a stable business. We'll be around in 10 years. And that ends up being a huge selling point for us. But definitely, if I would go back and do it again, I would have been smarter about that from day one. I would have avoided a lot of big pain points. +WILL: Yeah. It reminds me of when I started in development. I tried that same sprint the marathon, and so many of my co-workers were like, "Slow down, you're going to burn out. You're going to burn out." And it reminds me of that when you say that. +CAVAN: Yep. And everybody thinks they're invincible, and then you realize occasionally you're not. And then also you look at it from hindsight, and you're like, well, the code I was writing between 2:00 a.m. and 6:00 a.m. every night for three months was not the best code. +WILL: [laughs] +CAVAN: And once you get to a point when you get some breathing room, it's almost that you got to go slow to go fast type things where a lot of these best practices, having really good test cases, having good CI, having good work-life balance for employees I do think on a long-enough timeline actually allows you to go much, much, much faster versus just trying to crunch the whole time. +WILL: Totally, totally. I can't tell you how many bugs that I fixed that I was sitting down for hours and hours. I go on a 15-minute walk, and I solve it in the first 5 minutes. +CAVAN: Yeah, absolutely. I literally, I mean, if I get stuck on something, you know, I just end up doing too much coding. But if I ever really, really get hung up, whether it's coding, or design, or anything like that, I'm like, at this point, I'm a cognizant of the pain. I'm not making progress. I'm spinning my wheels. I'm getting more and more frustrated with everything happening on my laptop and, like, exactly as you mentioned, go walk around the block. Come back, and you have that eureka moment pretty frequently. +WILL: Definitely, definitely. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +WILL: You kind of mentioned it, mental health. And I was listening somewhere where you said, "It's not about doing 100-hour weeks, every week, every week, every week." So for Healthie, what are some of those things that you have implemented to stay healthy, to be able to run the marathon and not burn out? +CAVAN: I loved startups and entrepreneurship stories growing up. I would read TechCrunch and Hacker News and all this stuff and Twitter. It's gotten a little better, but there's still really this pervasive mentality of like, you know, I used to have my background computer screen was, you know, "Work like somebody's trying to take it away from you 24 hours a day," which is a Mark Cuban quote. And just all these things where if you're not doing the hustle porn, if you're not putting in the 100-hour weeks, you're not a real entrepreneur. You're not going to build a good business, like, you're going to lose out. +I had really, really taken that to heart. And that kind of goes back to the sprinting a marathon piece where eventually, in 2018, it's like, well, this is not really a sustainable thing. And for us to build a sustainable, long-lasting business, for us to have the impact that my co-founder and I and the rest of the people in the company wanted to have, you need to build really a sustainable business and a sustainable lifestyle. +So I think at Healthie, or what I generalize to other companies, is the number kind of day one thing is how was the company funded? Because that ultimately drives a ton of what is determined to be sustainable. We've been lucky enough where we've had this interesting fundraising story. We raised a million dollars to basically build a related but kind of more narrow in scope business. I realized pretty quickly that that was not going to be some huge venture-scale success that we would not be able to raise more money. +We were profitable for years and years and years, kind of rebuilt the whole platform, and got into this much, much larger space. And we did last year raise another 16 and a half million dollars. But one of our most important questions, when we raised that money, was, hey, we need to find investors that are long-term aligned. We weren't looking for people looking to flip their equity in a year. We weren't looking for people who are going to push us to grow at all costs and not look at spending or how we were growing. We just wanted growth, growth, growth. +So we found investors that were really, really aligned with our long-term vision for the company. We still look at cash very, very closely. The Slack message I'm going to look out for most every week is our VP of finances, like, our breakdown on our cash flows, so I keep a very close eye there. And then really build a business that people want to pay for and use. And, at this point, we have 80-something people. Payroll is getting more and more substantial, but that's all offset by our customers and their revenue, and that is really what's sustainable. And so that's more the finance side of things. +And then, as far as the company as a whole, I mean, being super cognizant that having crunch time is not a good thing. It's not a feature; it's a huge bug. When we agree to projects, we're making sure that we're planning things out. We're leaving breathing room where we're not asking employees to work crazy hours. We're not burning employees out. We're not burning ourselves out. +And it's not not working hard because it's still working hard, but it's working hard in a very smart and focused way that is less all-consuming. I think also as a boss, just being a decent person. If people have life events that pop up, if people have crises, and people have things they need to deal with, you know, work is incredibly important. I love what I do. I think about it all day. But there's a life outside of work, and making sure that we're allowing employees to have time for that, once again, is really important for long-term sustainability. +WILL: Wow, that's really neat. That's really neat. And yeah, I totally agree with that. That sounds like a great company. And I think that's the building blocks of what it takes to start the company. So that's amazing. What are some of your accomplishments? I love for my guests to come on and brag about themselves. I know you said that you've been around seven years. You just raised $16 million. You have about 80 employees. That's amazing. What are some of the things that we don't know? Would you like to share anything with us? +CAVAN: I mean, look, I started Healthie as a freshman in college. I dropped out to work on it full-time, so Healthie has been my whole career. And I think to go on a bit of a bragging rant; Healthie has had a lot of success so far. But my co-founder and I always like to joke we're halfway into being a 13-year overnight success. So when I like to brag, I like to brag partly about what Healthie is doing. But what Healthie does is enable other companies. So I really like to brag about what those other companies are doing. +Companies using Healthie have raised over $2 billion in venture. We're supporting millions and millions of patient lives. We're supporting thousands and thousands of providers. We've seen people go from two founders in a venture studio up to these massive hundreds and hundreds of people organizations, and we do it not just in one space but in a big range of spaces. We're doing it in weight loss, behavioral health, addiction treatment, sleep, other kinds of mental health areas, chronic pain. +And the type of care that we're enabling people to provide is proactive. So we're having people treat obesity, not a heart attack, diabetes, not an amputation, addiction, not an overdose. And ultimately, what I really, really think that does is that's enabling kind of this sea change in how healthcare works in this country where the more proactive we get, the less people end up in hospitals. The cheaper healthcare is, the more efficient healthcare is, the better patient experience patients receive, and ultimately, the better healthcare they receive. So that's really what I like to brag about because, ultimately, we are kind of that core infrastructure layer that's enabling a lot of that. +WILL: Wow, that's really neat. I can't remember the name of the guy that said it, but he said there are usually three Ps, and most companies struggle with one. So it's people, products, and processes, and mostly people struggle with the processes. And it sounds like Healthie is able to help people, medical providers, with that process and to kind of say, hey, let me take that. That may not be your strong suit, so you can go and do your product and the people and stuff like that. +CAVAN: Yeah, what I really say is when you think about what makes kind of these digital healthcare companies unique, a lot of time, it's a new insight or a new type of care model. They want to combine a newly approved FDA drug that's really effective with a series of coaching encounters in a different sequence than people have been doing with really great educational content, et cetera. +We see all these different care plans in all these different areas, and they end up unique to the company and then even to patients within the company. But to be able to deliver that care plan, there are so many kinds of table stakes things you need that I really describe as boring, difficult, and non-differentiated and can only really negatively impact the company. If you have an appointment with your doctor and the video call works, you're not necessarily thinking more highly of the doctor, but if it doesn't work, if it's a shitty piece of software... +WILL: [laughs] +CAVAN: If you're not able to connect, then suddenly you think a lot worse of them. And these things are hard; getting reminders out in the right time zones, handling daylight savings time, running servers 24/7 with great uptime. These things are non-trivial, but you need to be able to do them just to be able to get to like the 5% that really makes the business unique, which is the unique care model. So that's kind of really what we enable. So yeah, I would say it's a lot of the process. It's a lot of those kinds of table stakes infrastructure but in a way that's flexible enough where they're not having to sacrifice those unique insights that they have. +WILL: Yeah, that's really neat, really, really neat. I want to shift a little bit, and I read this in a blog, so companies have been getting in trouble for data sharing. That's been the big thing right now. And I think it was your CEO that said, "Data is our customers' data; it's not Healthie's data. And that is true day one, and it's true today." Tell me more about that. Tell me kind of the outlook of Healthie with customers' data. +CAVAN: So ultimately, I think one of the things going back to sustainable long-term success is around aligned incentives. So we need to make sure that the business we're building, the way we make money, the way we succeed as a company is aligned with the way our customers succeed. And when you think about it from a data perspective, our customers are the businesses. We help them deliver care. We have, as I mentioned, millions and millions of patient lives kind of all these visits, outcomes, et cetera. +And hypothetically, you could say, try to build a business where you don't really sell the software. You give it away very cheaply, but you retain rights to the data. And then you package that, anonymize it, and sell it to pharma, or whatever, and just kind of use it really as a data platform. And I think definitely there have been EHRs out there who have done similar approaches or at least thought they would. +And ultimately, why it's so bad, or at least why we think it's so bad is because it's a fundamentally different incentive. At that point, your customers are no longer your customers. Your customers become the product, and your customers' data becomes the product. And there are some cases if you're running a free social media site, well, maybe that's the way you have to run it. What's really great about what we do is we're selling underlying software to really successful businesses that build great companies, make a lot of money, and are more than happy to pay subscription fees for that. +And then, once you're in that really enviable position, it's not worth muddying the water with anything that misaligns those incentives. So we've been very, very clear from day one that we don't provide healthcare. We are not a data play. We are a software infrastructure company. That's what we do, that's what we're great at. That's what we focus on, and we don't mess with the other stuff. +WILL: That's amazing. I love that. One of the other big things, especially in healthcare, digital healthcare, have been online threats and things like that. Tell me a little bit about that. How are you keeping your company safe from those online threats? +CAVAN: Ultimately, one of those things where let's say all our customers try to build their own stuff, they don't have the resources. They don't have the know-how. They don't have the focus. And you end up even if they have the functionality, who knows how good that security is? So one of the benefits we offer companies is, going back to one of the things we have to be really, really good at, is security. So Healthie is a secure platform. We're HIPAA compliant. We're SOC 2 Type 2 compliant. We're audited by a third party on both of those. And it's something that we think a lot about ourselves, but it also becomes a big benefit to our customers. +So if you're a brand new startup and you're trying to sell to a major hospital system, and we've seen this a lot, like, very often, they'll have myself or another security-focused person on Healthie on the call. And we enable them to have good answers to these questions because we're the ones running the servers. We're storing the data. We are already making these good decisions. We have best practices in place and have these accreditations and certifications. And that enables our customers, once again, to focus on delivering care and not in reinventing the security wheel. +So it's a big thing we think about. We're talking about security constantly here at Healthie, you know, always running kind of 24/7 compliance tools, always making sure that we're improving our security posture. But ultimately, we do it so that our customers need to worry less about it. And it is one of the...going back to the things that, you know, we don't mess with data. We do worry a lot and think a lot and do a lot around security. +WILL: That's amazing. Awesome. Love it. I want to close on this: what does Healthie have coming up, anything exciting coming up in the next year? +CAVAN: I mean, I'm excited every day when I see our customers expanding when I see the new customers we're talking to. I mean, I think, really, we've been doing the same thing, just at a larger and larger scale, for the past seven years. And our goal for 2023 as a company, and we talk about this a lot internally, is to go from startup to scaleup. +So at the end of 2023, if I look back ten months from now and say, hey, what did we set out to do? What did we accomplish? It's did we continue to build the best team? Did we continue to build the best product? Did we continue to provide the best customer experience? And are our customers seeing a lot of success on the platform? And it's not like there's a new product line to enable that. You're not going to have some silver bullet that's going to change the dynamics. But it's really we just want to take what we're doing that we're doing a really good job of and just do that on a higher scale. So that's really what we're thinking about for 2023. +WILL: I love it. Sometimes just being consistent is the way to go, so I love that. +CAVAN: Yeah, you got to show up. Look, I used to wrestle. The way you become a good wrestler is not by knowing 800 wrestling moves. It's by knowing five moves and practicing them every day over and over again for years, and that's true of a lot of sports. It's true with startups. It's just consistent focus and having an aligned mission at the company. Really, really focused on pushing the ball forward every day, day in, day out, is just so, so important. And that's really what we do here. +WILL: I love it. Love it. Love it. Is there anything that we didn't cover that you would like to share with the audience? +CAVAN: I think if you're a company building in the digital health space, if you care about having these strong relationships with your patients, definitely check us out; we're gethealthie.com. Healthie is with an I-E. And then love talking to startups, love talking digital health, and always happy to talk. +WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Cavan Klinsky. + + + Cavan Klinsky is Co-Founder and CTO of Healthie, a scheduling engagement and Electronic Medical Records (EMR) platform used by healthtech organizations who seek to build long-term relationships with their clients.

+ +

Will talks to Cavan about providing an underlying infrastructure that other digital healthcare companies use to be able to focus on patient care and not reinventing the technology wheel by providing a scheduling platform, an electronic medical record, and a patient engagement solution–all available via API, via an API-first design as well as through fully branded interfaces. Healthie lets companies get to market faster, scale with less headaches, and provides effective patient care much cheaper than if they tried to build everything themselves.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Cavan Klinsky, who is a part of Healthie, a scheduling engagement and EMR platform used by healthtech organizations who seek to build long-term relationships with their clients. Cavan, thank you for joining me.

+ +

CAVAN: Thanks for having me on.

+ +

WILL: Yeah, I'm excited about this. Healthcare is always an exciting topic to talk about, so let's start there. For the people who may not know, tell us about Healthie and what's in store for 2023.

+ +

CAVAN: Healthie, as you mentioned, provides underlying infrastructure that other digital healthcare companies use to be able to focus on patient care and not kind of reinventing the technology wheel. So we do that by providing a scheduling platform, an electronic medical record, and a patient engagement solution. That's all available via API, via an API-first design as well as through fully branded interfaces. So we let companies get to market faster, scale with less headaches, and provide really, really powerful patient care much more cheaply than if they tried to build everything themselves.

+ +

WILL: Oh, sweet. Okay, so who is your main audience? Is it the patient, or is it the healthcare provider?

+ +

CAVAN: Healthie is a B2B company. So we sell basically the software to the digital healthcare organizations that are looking to deliver care, but there's a patient side of the platform. So they're able to onboard their patients. It allows patients to video chat with their provider, message, track goals, view care plans, et cetera. But our customers are the businesses.

+ +

So before Healthie, people would basically either try to cobble together like eight or nine different solutions to provide the experience they wanted, or they would spend millions and millions of dollars building in-house trying to piece together. But when you look at these different healthcare organizations, 90% of the functionality they're using ends up really being the same.

+ +

But people were trapped in this build versus buy decision where they were really concerned that they wouldn't be able to have a platform flashy enough for them. But the downside of that was just the cost of building that in-house. So Healthie really changes it from a build versus buy decision to a build and buy. So our customers buy the platform. They are able to launch very quickly. But because we're API-first, they are able to extend the pieces that are most unique to them.

+ +

WILL: That's really neat. Yeah, one of the most frustrating things I find, especially when it comes to visiting a doctor, is having to call in to schedule an appointment. And I'm like; I just need an appointment; just show me the available times. I want to select it and be a part of that. And so research shows your software takes care of that, correct?

+ +

CAVAN: Yeah, that's exactly right. And patients really, really love self-scheduling capabilities. When you talk to healthcare providers, if you ask a doctor, hey, why have they not embraced it? It's because they really want this fine-grained control over their calendar. A lot of them are used to calling the receptionist who's worked there for a decade and understands their preferences and how they want things sequenced. And they want this type of appointment able to be scheduled back to back but not this other type.

+ +

That's kind of really what we enable is we have this almost eye-wateringly long settings page where you can go in there checkboxes, configure things. And what you end up is just this really nice middle ground where patients are able to get that easy, self-schedule experience, not calling anybody, not waiting on hold. But doctors and other medical professionals aren't giving up control over their calendar. So it allows our customers to be able to do a lot of optimization, making sure their providers are fully booked but in a way where for patients, it's a really, really easy experience. And that's kind of a lot of the secret sauce that we offer.

+ +

WILL: Wow, that's neat. So tell us this, tell us about your background. How did you get started into the healthcare world?

+ +

CAVAN: So I got started in the healthcare world as I think a lot of people in this space which is I really got started as a patient. I had open-heart surgery after my freshman year of high school. I had eight weeks after that where basically I ended up kind of...I wasn't able to exercise, run around, kind of do most of the things I'd spend summers doing. So I ended up really stuck in a bedroom for most of it.

+ +

But that whole experience, kind of from prepping for the surgery, having it, recovering, got me really interested in healthcare and also really frustrated at just having a bunch of poor healthcare experiences. And it also really gave me time to start learning a lot about the engineering side of things. So I built my first web application that summer with Rails. So I found a lot of great thoughtbot posts, and I have a ton of respect for thoughtbot as an organization. I've been using Rails ever since.

+ +

WILL: Wow. That's really neat. I read an article about this. Tell us about your React Native experience because, at thoughtbot, we're trying to get that started. We actually are started, but we're trying to get that same momentum as we have with Rails.

+ +

CAVAN: So I think with React Native, initially, we were just a web platform. We realized very quickly that to enable a really strong patient experience...patients wanted to be using their mobile device. They don't want to be using a mobile web browser. They want a native application. So we initially launched, and this is maybe six months after we started the company, we launched an iOS app. We realized a couple of months later that we were going to need an Android application.

+ +

So we had a Swift and an Android application written in Java. We had a server-rendered Rails web application that we expose a very, very limited set of features via a REST API. And it worked out okay, but what we realized from doing that for about a year and a half, two years, was that we were duplicating a lot of work. The iOS app and the Android app were very similar to each other. But we had two separate developers who weren't able to really code review or help out the other.

+ +

We weren't a large enough company where it made sense for us to have a bunch of iOS developers and a bunch of Android developers. And then we were also duplicating a lot of functionality with this REST API, basically copied the things that we were doing just with server-rendered HTML. So in 2018, we had basically a from-the-ground rewrite of the whole web application, which was kind of a crazy experience. We moved to a single-page application on the web. We switched over to using GraphQL for everything.

+ +

And then we initially rebuilt our mobile application still using Swift and Java but now on top of GraphQL but really with an eye towards saying, hey, how do we end up getting off of these kinds of very siloed developer experiences and not to something where even if we don't have multiple developers who can do it, at least where developers can help each other out and understand?

+ +

So a few months after that, we kicked off our React Native rebuild. We built our whole mobile applications in React Native. Ultimately, having gone through a few different React projects, I think it's the only one in my life that kind of went as expected in a positive way. We did the rewrite. It came in on time. The mobile developers, instead of having an iOS and an Android, it was just two mobile developers who were able to help out each other and collaborate.

+ +

We can have web devs do code review for mobile, and they're able to provide feedback because we use React on the web. So it's definitely not write once, run anywhere, but I do think it's pretty close to at least understand everywhere. And that's been a really, really big thing for us. And then we're still able to bridge out to Swift or to Java for some more of the OS-specific features.

+ +

WILL: Yeah, yeah, I totally agree. That's the beauty of React Native, especially for your SaaS company. It's a perfect scenario because, like you said, web developers can code review. Sometimes they can even help with the code because it's right along the same lines and everything. So that's really neat.

+ +

CAVAN: Yeah, and we're able to share libraries, so, like, some of the NPM packages end up being the same. So it's just, yeah, it's been a lot of really, really nice experiences with that.

+ +

WILL: That's neat. So as the Founder and the CTO, what keeps you up at night?

+ +

CAVAN: I think what keeps me up at night is primarily for exciting things. We're in this position where we're seeing this huge sea change in how digital healthcare is delivered. Healthie is in this really nice balance where we're a mature company, you know, we're seven years old. We serve thousands and thousands of providers, millions of patients. But we're not like the Epics of the world, that are 35 years old and are just super resistant to change.

+ +

So we ended up in this kind of nice, sweet spot where we're tech-forward enough and flexible where we can really support these high-end use cases but then also basically mature enough where we have the scalability and the resiliency as an organization to be able to do that. So, I mean, a lot of what I think about is we provide business-critical healthcare, critical infrastructure for a lot of people. And that number continues to grow every day. It needs to work. It needs to work quickly. It needs to work securely.

+ +

And that's what, a lot of the time, I think about both from a technical perspective and then also as the organization as a whole grows, from a hiring and an organizational structure perspective. So I think you really go from hacking on the codebase day one seven years ago to kind of hacking on the organization as a whole. And that's really where I spend my time and what keeps me up.

+ +

WILL: That's neat. Wow, that's really cool. So as a first-time founder, tell me this, you've been around seven years. That seems like a long time, so kudos to you for enduring that and sustaining that. That's amazing. What are some of the things that day one when you started the company...if you could look back, what are some advice that you would give yourself to say, hey, don't do this or do this?

+ +

CAVAN: Yeah, the piece of advice I would give myself is advice we actually received pretty frequently and didn't believe, and then it ended up almost totally derailing the company.

+ +

WILL: Oh wow.

+ +

CAVAN: And that's that, you know, both my co-founder and I were first-time founders. I think we're really smart. We're definitely hard-working, you know, very motivated people. And we were really convinced that we'd be able to just do a full-out sprint and never stop sprinting. And we kept on getting told by advisors and investors, "Hey, it's a marathon. It's a marathon." We were like, you know, we're just going to sprint the marathon. That started out okay, and then a couple of years in, we started hitting walls and really realized that you can't sprint a marathon.

+ +

Startups take way longer than I think founders hope they do or think that they're going to take to develop. Digital health and our healthcare system moves much, much more slower than kind of people think. So especially if you're a founder in digital health, you need to be building both a company and, I think, a personal lifestyle that's sustainable. You need to make sure that the company has money in the bank and can be around for years and years and years. And you need to make sure that your job, your day-to-day, is something that you can also continue to do for years and years and years.

+ +

So that's ultimately, I think, the most important thing that we're able to tell our customers and something that we've now gotten the company in a position to be in, which is, hey, we're a sustainable business. We're a stable business. We'll be around in 10 years. And that ends up being a huge selling point for us. But definitely, if I would go back and do it again, I would have been smarter about that from day one. I would have avoided a lot of big pain points.

+ +

WILL: Yeah. It reminds me of when I started in development. I tried that same sprint the marathon, and so many of my co-workers were like, "Slow down, you're going to burn out. You're going to burn out." And it reminds me of that when you say that.

+ +

CAVAN: Yep. And everybody thinks they're invincible, and then you realize occasionally you're not. And then also you look at it from hindsight, and you're like, well, the code I was writing between 2:00 a.m. and 6:00 a.m. every night for three months was not the best code.

+ +

WILL: [laughs]

+ +

CAVAN: And once you get to a point when you get some breathing room, it's almost that you got to go slow to go fast type things where a lot of these best practices, having really good test cases, having good CI, having good work-life balance for employees I do think on a long-enough timeline actually allows you to go much, much, much faster versus just trying to crunch the whole time.

+ +

WILL: Totally, totally. I can't tell you how many bugs that I fixed that I was sitting down for hours and hours. I go on a 15-minute walk, and I solve it in the first 5 minutes.

+ +

CAVAN: Yeah, absolutely. I literally, I mean, if I get stuck on something, you know, I just end up doing too much coding. But if I ever really, really get hung up, whether it's coding, or design, or anything like that, I'm like, at this point, I'm a cognizant of the pain. I'm not making progress. I'm spinning my wheels. I'm getting more and more frustrated with everything happening on my laptop and, like, exactly as you mentioned, go walk around the block. Come back, and you have that eureka moment pretty frequently.

+ +

WILL: Definitely, definitely.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

WILL: You kind of mentioned it, mental health. And I was listening somewhere where you said, "It's not about doing 100-hour weeks, every week, every week, every week." So for Healthie, what are some of those things that you have implemented to stay healthy, to be able to run the marathon and not burn out?

+ +

CAVAN: I loved startups and entrepreneurship stories growing up. I would read TechCrunch and Hacker News and all this stuff and Twitter. It's gotten a little better, but there's still really this pervasive mentality of like, you know, I used to have my background computer screen was, you know, "Work like somebody's trying to take it away from you 24 hours a day," which is a Mark Cuban quote. And just all these things where if you're not doing the hustle porn, if you're not putting in the 100-hour weeks, you're not a real entrepreneur. You're not going to build a good business, like, you're going to lose out.

+ +

I had really, really taken that to heart. And that kind of goes back to the sprinting a marathon piece where eventually, in 2018, it's like, well, this is not really a sustainable thing. And for us to build a sustainable, long-lasting business, for us to have the impact that my co-founder and I and the rest of the people in the company wanted to have, you need to build really a sustainable business and a sustainable lifestyle.

+ +

So I think at Healthie, or what I generalize to other companies, is the number kind of day one thing is how was the company funded? Because that ultimately drives a ton of what is determined to be sustainable. We've been lucky enough where we've had this interesting fundraising story. We raised a million dollars to basically build a related but kind of more narrow in scope business. I realized pretty quickly that that was not going to be some huge venture-scale success that we would not be able to raise more money.

+ +

We were profitable for years and years and years, kind of rebuilt the whole platform, and got into this much, much larger space. And we did last year raise another 16 and a half million dollars. But one of our most important questions, when we raised that money, was, hey, we need to find investors that are long-term aligned. We weren't looking for people looking to flip their equity in a year. We weren't looking for people who are going to push us to grow at all costs and not look at spending or how we were growing. We just wanted growth, growth, growth.

+ +

So we found investors that were really, really aligned with our long-term vision for the company. We still look at cash very, very closely. The Slack message I'm going to look out for most every week is our VP of finances, like, our breakdown on our cash flows, so I keep a very close eye there. And then really build a business that people want to pay for and use. And, at this point, we have 80-something people. Payroll is getting more and more substantial, but that's all offset by our customers and their revenue, and that is really what's sustainable. And so that's more the finance side of things.

+ +

And then, as far as the company as a whole, I mean, being super cognizant that having crunch time is not a good thing. It's not a feature; it's a huge bug. When we agree to projects, we're making sure that we're planning things out. We're leaving breathing room where we're not asking employees to work crazy hours. We're not burning employees out. We're not burning ourselves out.

+ +

And it's not not working hard because it's still working hard, but it's working hard in a very smart and focused way that is less all-consuming. I think also as a boss, just being a decent person. If people have life events that pop up, if people have crises, and people have things they need to deal with, you know, work is incredibly important. I love what I do. I think about it all day. But there's a life outside of work, and making sure that we're allowing employees to have time for that, once again, is really important for long-term sustainability.

+ +

WILL: Wow, that's really neat. That's really neat. And yeah, I totally agree with that. That sounds like a great company. And I think that's the building blocks of what it takes to start the company. So that's amazing. What are some of your accomplishments? I love for my guests to come on and brag about themselves. I know you said that you've been around seven years. You just raised $16 million. You have about 80 employees. That's amazing. What are some of the things that we don't know? Would you like to share anything with us?

+ +

CAVAN: I mean, look, I started Healthie as a freshman in college. I dropped out to work on it full-time, so Healthie has been my whole career. And I think to go on a bit of a bragging rant; Healthie has had a lot of success so far. But my co-founder and I always like to joke we're halfway into being a 13-year overnight success. So when I like to brag, I like to brag partly about what Healthie is doing. But what Healthie does is enable other companies. So I really like to brag about what those other companies are doing.

+ +

Companies using Healthie have raised over $2 billion in venture. We're supporting millions and millions of patient lives. We're supporting thousands and thousands of providers. We've seen people go from two founders in a venture studio up to these massive hundreds and hundreds of people organizations, and we do it not just in one space but in a big range of spaces. We're doing it in weight loss, behavioral health, addiction treatment, sleep, other kinds of mental health areas, chronic pain.

+ +

And the type of care that we're enabling people to provide is proactive. So we're having people treat obesity, not a heart attack, diabetes, not an amputation, addiction, not an overdose. And ultimately, what I really, really think that does is that's enabling kind of this sea change in how healthcare works in this country where the more proactive we get, the less people end up in hospitals. The cheaper healthcare is, the more efficient healthcare is, the better patient experience patients receive, and ultimately, the better healthcare they receive. So that's really what I like to brag about because, ultimately, we are kind of that core infrastructure layer that's enabling a lot of that.

+ +

WILL: Wow, that's really neat. I can't remember the name of the guy that said it, but he said there are usually three Ps, and most companies struggle with one. So it's people, products, and processes, and mostly people struggle with the processes. And it sounds like Healthie is able to help people, medical providers, with that process and to kind of say, hey, let me take that. That may not be your strong suit, so you can go and do your product and the people and stuff like that.

+ +

CAVAN: Yeah, what I really say is when you think about what makes kind of these digital healthcare companies unique, a lot of time, it's a new insight or a new type of care model. They want to combine a newly approved FDA drug that's really effective with a series of coaching encounters in a different sequence than people have been doing with really great educational content, et cetera.

+ +

We see all these different care plans in all these different areas, and they end up unique to the company and then even to patients within the company. But to be able to deliver that care plan, there are so many kinds of table stakes things you need that I really describe as boring, difficult, and non-differentiated and can only really negatively impact the company. If you have an appointment with your doctor and the video call works, you're not necessarily thinking more highly of the doctor, but if it doesn't work, if it's a shitty piece of software...

+ +

WILL: [laughs]

+ +

CAVAN: If you're not able to connect, then suddenly you think a lot worse of them. And these things are hard; getting reminders out in the right time zones, handling daylight savings time, running servers 24/7 with great uptime. These things are non-trivial, but you need to be able to do them just to be able to get to like the 5% that really makes the business unique, which is the unique care model. So that's kind of really what we enable. So yeah, I would say it's a lot of the process. It's a lot of those kinds of table stakes infrastructure but in a way that's flexible enough where they're not having to sacrifice those unique insights that they have.

+ +

WILL: Yeah, that's really neat, really, really neat. I want to shift a little bit, and I read this in a blog, so companies have been getting in trouble for data sharing. That's been the big thing right now. And I think it was your CEO that said, "Data is our customers' data; it's not Healthie's data. And that is true day one, and it's true today." Tell me more about that. Tell me kind of the outlook of Healthie with customers' data.

+ +

CAVAN: So ultimately, I think one of the things going back to sustainable long-term success is around aligned incentives. So we need to make sure that the business we're building, the way we make money, the way we succeed as a company is aligned with the way our customers succeed. And when you think about it from a data perspective, our customers are the businesses. We help them deliver care. We have, as I mentioned, millions and millions of patient lives kind of all these visits, outcomes, et cetera.

+ +

And hypothetically, you could say, try to build a business where you don't really sell the software. You give it away very cheaply, but you retain rights to the data. And then you package that, anonymize it, and sell it to pharma, or whatever, and just kind of use it really as a data platform. And I think definitely there have been EHRs out there who have done similar approaches or at least thought they would.

+ +

And ultimately, why it's so bad, or at least why we think it's so bad is because it's a fundamentally different incentive. At that point, your customers are no longer your customers. Your customers become the product, and your customers' data becomes the product. And there are some cases if you're running a free social media site, well, maybe that's the way you have to run it. What's really great about what we do is we're selling underlying software to really successful businesses that build great companies, make a lot of money, and are more than happy to pay subscription fees for that.

+ +

And then, once you're in that really enviable position, it's not worth muddying the water with anything that misaligns those incentives. So we've been very, very clear from day one that we don't provide healthcare. We are not a data play. We are a software infrastructure company. That's what we do, that's what we're great at. That's what we focus on, and we don't mess with the other stuff.

+ +

WILL: That's amazing. I love that. One of the other big things, especially in healthcare, digital healthcare, have been online threats and things like that. Tell me a little bit about that. How are you keeping your company safe from those online threats?

+ +

CAVAN: Ultimately, one of those things where let's say all our customers try to build their own stuff, they don't have the resources. They don't have the know-how. They don't have the focus. And you end up even if they have the functionality, who knows how good that security is? So one of the benefits we offer companies is, going back to one of the things we have to be really, really good at, is security. So Healthie is a secure platform. We're HIPAA compliant. We're SOC 2 Type 2 compliant. We're audited by a third party on both of those. And it's something that we think a lot about ourselves, but it also becomes a big benefit to our customers.

+ +

So if you're a brand new startup and you're trying to sell to a major hospital system, and we've seen this a lot, like, very often, they'll have myself or another security-focused person on Healthie on the call. And we enable them to have good answers to these questions because we're the ones running the servers. We're storing the data. We are already making these good decisions. We have best practices in place and have these accreditations and certifications. And that enables our customers, once again, to focus on delivering care and not in reinventing the security wheel.

+ +

So it's a big thing we think about. We're talking about security constantly here at Healthie, you know, always running kind of 24/7 compliance tools, always making sure that we're improving our security posture. But ultimately, we do it so that our customers need to worry less about it. And it is one of the...going back to the things that, you know, we don't mess with data. We do worry a lot and think a lot and do a lot around security.

+ +

WILL: That's amazing. Awesome. Love it. I want to close on this: what does Healthie have coming up, anything exciting coming up in the next year?

+ +

CAVAN: I mean, I'm excited every day when I see our customers expanding when I see the new customers we're talking to. I mean, I think, really, we've been doing the same thing, just at a larger and larger scale, for the past seven years. And our goal for 2023 as a company, and we talk about this a lot internally, is to go from startup to scaleup.

+ +

So at the end of 2023, if I look back ten months from now and say, hey, what did we set out to do? What did we accomplish? It's did we continue to build the best team? Did we continue to build the best product? Did we continue to provide the best customer experience? And are our customers seeing a lot of success on the platform? And it's not like there's a new product line to enable that. You're not going to have some silver bullet that's going to change the dynamics. But it's really we just want to take what we're doing that we're doing a really good job of and just do that on a higher scale. So that's really what we're thinking about for 2023.

+ +

WILL: I love it. Sometimes just being consistent is the way to go, so I love that.

+ +

CAVAN: Yeah, you got to show up. Look, I used to wrestle. The way you become a good wrestler is not by knowing 800 wrestling moves. It's by knowing five moves and practicing them every day over and over again for years, and that's true of a lot of sports. It's true with startups. It's just consistent focus and having an aligned mission at the company. Really, really focused on pushing the ball forward every day, day in, day out, is just so, so important. And that's really what we do here.

+ +

WILL: I love it. Love it. Love it. Is there anything that we didn't cover that you would like to share with the audience?

+ +

CAVAN: I think if you're a company building in the digital health space, if you care about having these strong relationships with your patients, definitely check us out; we're gethealthie.com. Healthie is with an I-E. And then love talking to startups, love talking digital health, and always happy to talk.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Cavan Klinsky.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Cavan Klinsky is Co-Founder and CTO of Healthie, a scheduling engagement and Electronic Medical Records (EMR) platform used by healthtech organizations who seek to build long-term relationships with their clients.

+ +

Will talks to Cavan about providing an underlying infrastructure that other digital healthcare companies use to be able to focus on patient care and not reinventing the technology wheel by providing a scheduling platform, an electronic medical record, and a patient engagement solution–all available via API, via an API-first design as well as through fully branded interfaces. Healthie lets companies get to market faster, scale with less headaches, and provides effective patient care much cheaper than if they tried to build everything themselves.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Cavan Klinsky, who is a part of Healthie, a scheduling engagement and EMR platform used by healthtech organizations who seek to build long-term relationships with their clients. Cavan, thank you for joining me.

+ +

CAVAN: Thanks for having me on.

+ +

WILL: Yeah, I'm excited about this. Healthcare is always an exciting topic to talk about, so let's start there. For the people who may not know, tell us about Healthie and what's in store for 2023.

+ +

CAVAN: Healthie, as you mentioned, provides underlying infrastructure that other digital healthcare companies use to be able to focus on patient care and not kind of reinventing the technology wheel. So we do that by providing a scheduling platform, an electronic medical record, and a patient engagement solution. That's all available via API, via an API-first design as well as through fully branded interfaces. So we let companies get to market faster, scale with less headaches, and provide really, really powerful patient care much more cheaply than if they tried to build everything themselves.

+ +

WILL: Oh, sweet. Okay, so who is your main audience? Is it the patient, or is it the healthcare provider?

+ +

CAVAN: Healthie is a B2B company. So we sell basically the software to the digital healthcare organizations that are looking to deliver care, but there's a patient side of the platform. So they're able to onboard their patients. It allows patients to video chat with their provider, message, track goals, view care plans, et cetera. But our customers are the businesses.

+ +

So before Healthie, people would basically either try to cobble together like eight or nine different solutions to provide the experience they wanted, or they would spend millions and millions of dollars building in-house trying to piece together. But when you look at these different healthcare organizations, 90% of the functionality they're using ends up really being the same.

+ +

But people were trapped in this build versus buy decision where they were really concerned that they wouldn't be able to have a platform flashy enough for them. But the downside of that was just the cost of building that in-house. So Healthie really changes it from a build versus buy decision to a build and buy. So our customers buy the platform. They are able to launch very quickly. But because we're API-first, they are able to extend the pieces that are most unique to them.

+ +

WILL: That's really neat. Yeah, one of the most frustrating things I find, especially when it comes to visiting a doctor, is having to call in to schedule an appointment. And I'm like; I just need an appointment; just show me the available times. I want to select it and be a part of that. And so research shows your software takes care of that, correct?

+ +

CAVAN: Yeah, that's exactly right. And patients really, really love self-scheduling capabilities. When you talk to healthcare providers, if you ask a doctor, hey, why have they not embraced it? It's because they really want this fine-grained control over their calendar. A lot of them are used to calling the receptionist who's worked there for a decade and understands their preferences and how they want things sequenced. And they want this type of appointment able to be scheduled back to back but not this other type.

+ +

That's kind of really what we enable is we have this almost eye-wateringly long settings page where you can go in there checkboxes, configure things. And what you end up is just this really nice middle ground where patients are able to get that easy, self-schedule experience, not calling anybody, not waiting on hold. But doctors and other medical professionals aren't giving up control over their calendar. So it allows our customers to be able to do a lot of optimization, making sure their providers are fully booked but in a way where for patients, it's a really, really easy experience. And that's kind of a lot of the secret sauce that we offer.

+ +

WILL: Wow, that's neat. So tell us this, tell us about your background. How did you get started into the healthcare world?

+ +

CAVAN: So I got started in the healthcare world as I think a lot of people in this space which is I really got started as a patient. I had open-heart surgery after my freshman year of high school. I had eight weeks after that where basically I ended up kind of...I wasn't able to exercise, run around, kind of do most of the things I'd spend summers doing. So I ended up really stuck in a bedroom for most of it.

+ +

But that whole experience, kind of from prepping for the surgery, having it, recovering, got me really interested in healthcare and also really frustrated at just having a bunch of poor healthcare experiences. And it also really gave me time to start learning a lot about the engineering side of things. So I built my first web application that summer with Rails. So I found a lot of great thoughtbot posts, and I have a ton of respect for thoughtbot as an organization. I've been using Rails ever since.

+ +

WILL: Wow. That's really neat. I read an article about this. Tell us about your React Native experience because, at thoughtbot, we're trying to get that started. We actually are started, but we're trying to get that same momentum as we have with Rails.

+ +

CAVAN: So I think with React Native, initially, we were just a web platform. We realized very quickly that to enable a really strong patient experience...patients wanted to be using their mobile device. They don't want to be using a mobile web browser. They want a native application. So we initially launched, and this is maybe six months after we started the company, we launched an iOS app. We realized a couple of months later that we were going to need an Android application.

+ +

So we had a Swift and an Android application written in Java. We had a server-rendered Rails web application that we expose a very, very limited set of features via a REST API. And it worked out okay, but what we realized from doing that for about a year and a half, two years, was that we were duplicating a lot of work. The iOS app and the Android app were very similar to each other. But we had two separate developers who weren't able to really code review or help out the other.

+ +

We weren't a large enough company where it made sense for us to have a bunch of iOS developers and a bunch of Android developers. And then we were also duplicating a lot of functionality with this REST API, basically copied the things that we were doing just with server-rendered HTML. So in 2018, we had basically a from-the-ground rewrite of the whole web application, which was kind of a crazy experience. We moved to a single-page application on the web. We switched over to using GraphQL for everything.

+ +

And then we initially rebuilt our mobile application still using Swift and Java but now on top of GraphQL but really with an eye towards saying, hey, how do we end up getting off of these kinds of very siloed developer experiences and not to something where even if we don't have multiple developers who can do it, at least where developers can help each other out and understand?

+ +

So a few months after that, we kicked off our React Native rebuild. We built our whole mobile applications in React Native. Ultimately, having gone through a few different React projects, I think it's the only one in my life that kind of went as expected in a positive way. We did the rewrite. It came in on time. The mobile developers, instead of having an iOS and an Android, it was just two mobile developers who were able to help out each other and collaborate.

+ +

We can have web devs do code review for mobile, and they're able to provide feedback because we use React on the web. So it's definitely not write once, run anywhere, but I do think it's pretty close to at least understand everywhere. And that's been a really, really big thing for us. And then we're still able to bridge out to Swift or to Java for some more of the OS-specific features.

+ +

WILL: Yeah, yeah, I totally agree. That's the beauty of React Native, especially for your SaaS company. It's a perfect scenario because, like you said, web developers can code review. Sometimes they can even help with the code because it's right along the same lines and everything. So that's really neat.

+ +

CAVAN: Yeah, and we're able to share libraries, so, like, some of the NPM packages end up being the same. So it's just, yeah, it's been a lot of really, really nice experiences with that.

+ +

WILL: That's neat. So as the Founder and the CTO, what keeps you up at night?

+ +

CAVAN: I think what keeps me up at night is primarily for exciting things. We're in this position where we're seeing this huge sea change in how digital healthcare is delivered. Healthie is in this really nice balance where we're a mature company, you know, we're seven years old. We serve thousands and thousands of providers, millions of patients. But we're not like the Epics of the world, that are 35 years old and are just super resistant to change.

+ +

So we ended up in this kind of nice, sweet spot where we're tech-forward enough and flexible where we can really support these high-end use cases but then also basically mature enough where we have the scalability and the resiliency as an organization to be able to do that. So, I mean, a lot of what I think about is we provide business-critical healthcare, critical infrastructure for a lot of people. And that number continues to grow every day. It needs to work. It needs to work quickly. It needs to work securely.

+ +

And that's what, a lot of the time, I think about both from a technical perspective and then also as the organization as a whole grows, from a hiring and an organizational structure perspective. So I think you really go from hacking on the codebase day one seven years ago to kind of hacking on the organization as a whole. And that's really where I spend my time and what keeps me up.

+ +

WILL: That's neat. Wow, that's really cool. So as a first-time founder, tell me this, you've been around seven years. That seems like a long time, so kudos to you for enduring that and sustaining that. That's amazing. What are some of the things that day one when you started the company...if you could look back, what are some advice that you would give yourself to say, hey, don't do this or do this?

+ +

CAVAN: Yeah, the piece of advice I would give myself is advice we actually received pretty frequently and didn't believe, and then it ended up almost totally derailing the company.

+ +

WILL: Oh wow.

+ +

CAVAN: And that's that, you know, both my co-founder and I were first-time founders. I think we're really smart. We're definitely hard-working, you know, very motivated people. And we were really convinced that we'd be able to just do a full-out sprint and never stop sprinting. And we kept on getting told by advisors and investors, "Hey, it's a marathon. It's a marathon." We were like, you know, we're just going to sprint the marathon. That started out okay, and then a couple of years in, we started hitting walls and really realized that you can't sprint a marathon.

+ +

Startups take way longer than I think founders hope they do or think that they're going to take to develop. Digital health and our healthcare system moves much, much more slower than kind of people think. So especially if you're a founder in digital health, you need to be building both a company and, I think, a personal lifestyle that's sustainable. You need to make sure that the company has money in the bank and can be around for years and years and years. And you need to make sure that your job, your day-to-day, is something that you can also continue to do for years and years and years.

+ +

So that's ultimately, I think, the most important thing that we're able to tell our customers and something that we've now gotten the company in a position to be in, which is, hey, we're a sustainable business. We're a stable business. We'll be around in 10 years. And that ends up being a huge selling point for us. But definitely, if I would go back and do it again, I would have been smarter about that from day one. I would have avoided a lot of big pain points.

+ +

WILL: Yeah. It reminds me of when I started in development. I tried that same sprint the marathon, and so many of my co-workers were like, "Slow down, you're going to burn out. You're going to burn out." And it reminds me of that when you say that.

+ +

CAVAN: Yep. And everybody thinks they're invincible, and then you realize occasionally you're not. And then also you look at it from hindsight, and you're like, well, the code I was writing between 2:00 a.m. and 6:00 a.m. every night for three months was not the best code.

+ +

WILL: [laughs]

+ +

CAVAN: And once you get to a point when you get some breathing room, it's almost that you got to go slow to go fast type things where a lot of these best practices, having really good test cases, having good CI, having good work-life balance for employees I do think on a long-enough timeline actually allows you to go much, much, much faster versus just trying to crunch the whole time.

+ +

WILL: Totally, totally. I can't tell you how many bugs that I fixed that I was sitting down for hours and hours. I go on a 15-minute walk, and I solve it in the first 5 minutes.

+ +

CAVAN: Yeah, absolutely. I literally, I mean, if I get stuck on something, you know, I just end up doing too much coding. But if I ever really, really get hung up, whether it's coding, or design, or anything like that, I'm like, at this point, I'm a cognizant of the pain. I'm not making progress. I'm spinning my wheels. I'm getting more and more frustrated with everything happening on my laptop and, like, exactly as you mentioned, go walk around the block. Come back, and you have that eureka moment pretty frequently.

+ +

WILL: Definitely, definitely.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

WILL: You kind of mentioned it, mental health. And I was listening somewhere where you said, "It's not about doing 100-hour weeks, every week, every week, every week." So for Healthie, what are some of those things that you have implemented to stay healthy, to be able to run the marathon and not burn out?

+ +

CAVAN: I loved startups and entrepreneurship stories growing up. I would read TechCrunch and Hacker News and all this stuff and Twitter. It's gotten a little better, but there's still really this pervasive mentality of like, you know, I used to have my background computer screen was, you know, "Work like somebody's trying to take it away from you 24 hours a day," which is a Mark Cuban quote. And just all these things where if you're not doing the hustle porn, if you're not putting in the 100-hour weeks, you're not a real entrepreneur. You're not going to build a good business, like, you're going to lose out.

+ +

I had really, really taken that to heart. And that kind of goes back to the sprinting a marathon piece where eventually, in 2018, it's like, well, this is not really a sustainable thing. And for us to build a sustainable, long-lasting business, for us to have the impact that my co-founder and I and the rest of the people in the company wanted to have, you need to build really a sustainable business and a sustainable lifestyle.

+ +

So I think at Healthie, or what I generalize to other companies, is the number kind of day one thing is how was the company funded? Because that ultimately drives a ton of what is determined to be sustainable. We've been lucky enough where we've had this interesting fundraising story. We raised a million dollars to basically build a related but kind of more narrow in scope business. I realized pretty quickly that that was not going to be some huge venture-scale success that we would not be able to raise more money.

+ +

We were profitable for years and years and years, kind of rebuilt the whole platform, and got into this much, much larger space. And we did last year raise another 16 and a half million dollars. But one of our most important questions, when we raised that money, was, hey, we need to find investors that are long-term aligned. We weren't looking for people looking to flip their equity in a year. We weren't looking for people who are going to push us to grow at all costs and not look at spending or how we were growing. We just wanted growth, growth, growth.

+ +

So we found investors that were really, really aligned with our long-term vision for the company. We still look at cash very, very closely. The Slack message I'm going to look out for most every week is our VP of finances, like, our breakdown on our cash flows, so I keep a very close eye there. And then really build a business that people want to pay for and use. And, at this point, we have 80-something people. Payroll is getting more and more substantial, but that's all offset by our customers and their revenue, and that is really what's sustainable. And so that's more the finance side of things.

+ +

And then, as far as the company as a whole, I mean, being super cognizant that having crunch time is not a good thing. It's not a feature; it's a huge bug. When we agree to projects, we're making sure that we're planning things out. We're leaving breathing room where we're not asking employees to work crazy hours. We're not burning employees out. We're not burning ourselves out.

+ +

And it's not not working hard because it's still working hard, but it's working hard in a very smart and focused way that is less all-consuming. I think also as a boss, just being a decent person. If people have life events that pop up, if people have crises, and people have things they need to deal with, you know, work is incredibly important. I love what I do. I think about it all day. But there's a life outside of work, and making sure that we're allowing employees to have time for that, once again, is really important for long-term sustainability.

+ +

WILL: Wow, that's really neat. That's really neat. And yeah, I totally agree with that. That sounds like a great company. And I think that's the building blocks of what it takes to start the company. So that's amazing. What are some of your accomplishments? I love for my guests to come on and brag about themselves. I know you said that you've been around seven years. You just raised $16 million. You have about 80 employees. That's amazing. What are some of the things that we don't know? Would you like to share anything with us?

+ +

CAVAN: I mean, look, I started Healthie as a freshman in college. I dropped out to work on it full-time, so Healthie has been my whole career. And I think to go on a bit of a bragging rant; Healthie has had a lot of success so far. But my co-founder and I always like to joke we're halfway into being a 13-year overnight success. So when I like to brag, I like to brag partly about what Healthie is doing. But what Healthie does is enable other companies. So I really like to brag about what those other companies are doing.

+ +

Companies using Healthie have raised over $2 billion in venture. We're supporting millions and millions of patient lives. We're supporting thousands and thousands of providers. We've seen people go from two founders in a venture studio up to these massive hundreds and hundreds of people organizations, and we do it not just in one space but in a big range of spaces. We're doing it in weight loss, behavioral health, addiction treatment, sleep, other kinds of mental health areas, chronic pain.

+ +

And the type of care that we're enabling people to provide is proactive. So we're having people treat obesity, not a heart attack, diabetes, not an amputation, addiction, not an overdose. And ultimately, what I really, really think that does is that's enabling kind of this sea change in how healthcare works in this country where the more proactive we get, the less people end up in hospitals. The cheaper healthcare is, the more efficient healthcare is, the better patient experience patients receive, and ultimately, the better healthcare they receive. So that's really what I like to brag about because, ultimately, we are kind of that core infrastructure layer that's enabling a lot of that.

+ +

WILL: Wow, that's really neat. I can't remember the name of the guy that said it, but he said there are usually three Ps, and most companies struggle with one. So it's people, products, and processes, and mostly people struggle with the processes. And it sounds like Healthie is able to help people, medical providers, with that process and to kind of say, hey, let me take that. That may not be your strong suit, so you can go and do your product and the people and stuff like that.

+ +

CAVAN: Yeah, what I really say is when you think about what makes kind of these digital healthcare companies unique, a lot of time, it's a new insight or a new type of care model. They want to combine a newly approved FDA drug that's really effective with a series of coaching encounters in a different sequence than people have been doing with really great educational content, et cetera.

+ +

We see all these different care plans in all these different areas, and they end up unique to the company and then even to patients within the company. But to be able to deliver that care plan, there are so many kinds of table stakes things you need that I really describe as boring, difficult, and non-differentiated and can only really negatively impact the company. If you have an appointment with your doctor and the video call works, you're not necessarily thinking more highly of the doctor, but if it doesn't work, if it's a shitty piece of software...

+ +

WILL: [laughs]

+ +

CAVAN: If you're not able to connect, then suddenly you think a lot worse of them. And these things are hard; getting reminders out in the right time zones, handling daylight savings time, running servers 24/7 with great uptime. These things are non-trivial, but you need to be able to do them just to be able to get to like the 5% that really makes the business unique, which is the unique care model. So that's kind of really what we enable. So yeah, I would say it's a lot of the process. It's a lot of those kinds of table stakes infrastructure but in a way that's flexible enough where they're not having to sacrifice those unique insights that they have.

+ +

WILL: Yeah, that's really neat, really, really neat. I want to shift a little bit, and I read this in a blog, so companies have been getting in trouble for data sharing. That's been the big thing right now. And I think it was your CEO that said, "Data is our customers' data; it's not Healthie's data. And that is true day one, and it's true today." Tell me more about that. Tell me kind of the outlook of Healthie with customers' data.

+ +

CAVAN: So ultimately, I think one of the things going back to sustainable long-term success is around aligned incentives. So we need to make sure that the business we're building, the way we make money, the way we succeed as a company is aligned with the way our customers succeed. And when you think about it from a data perspective, our customers are the businesses. We help them deliver care. We have, as I mentioned, millions and millions of patient lives kind of all these visits, outcomes, et cetera.

+ +

And hypothetically, you could say, try to build a business where you don't really sell the software. You give it away very cheaply, but you retain rights to the data. And then you package that, anonymize it, and sell it to pharma, or whatever, and just kind of use it really as a data platform. And I think definitely there have been EHRs out there who have done similar approaches or at least thought they would.

+ +

And ultimately, why it's so bad, or at least why we think it's so bad is because it's a fundamentally different incentive. At that point, your customers are no longer your customers. Your customers become the product, and your customers' data becomes the product. And there are some cases if you're running a free social media site, well, maybe that's the way you have to run it. What's really great about what we do is we're selling underlying software to really successful businesses that build great companies, make a lot of money, and are more than happy to pay subscription fees for that.

+ +

And then, once you're in that really enviable position, it's not worth muddying the water with anything that misaligns those incentives. So we've been very, very clear from day one that we don't provide healthcare. We are not a data play. We are a software infrastructure company. That's what we do, that's what we're great at. That's what we focus on, and we don't mess with the other stuff.

+ +

WILL: That's amazing. I love that. One of the other big things, especially in healthcare, digital healthcare, have been online threats and things like that. Tell me a little bit about that. How are you keeping your company safe from those online threats?

+ +

CAVAN: Ultimately, one of those things where let's say all our customers try to build their own stuff, they don't have the resources. They don't have the know-how. They don't have the focus. And you end up even if they have the functionality, who knows how good that security is? So one of the benefits we offer companies is, going back to one of the things we have to be really, really good at, is security. So Healthie is a secure platform. We're HIPAA compliant. We're SOC 2 Type 2 compliant. We're audited by a third party on both of those. And it's something that we think a lot about ourselves, but it also becomes a big benefit to our customers.

+ +

So if you're a brand new startup and you're trying to sell to a major hospital system, and we've seen this a lot, like, very often, they'll have myself or another security-focused person on Healthie on the call. And we enable them to have good answers to these questions because we're the ones running the servers. We're storing the data. We are already making these good decisions. We have best practices in place and have these accreditations and certifications. And that enables our customers, once again, to focus on delivering care and not in reinventing the security wheel.

+ +

So it's a big thing we think about. We're talking about security constantly here at Healthie, you know, always running kind of 24/7 compliance tools, always making sure that we're improving our security posture. But ultimately, we do it so that our customers need to worry less about it. And it is one of the...going back to the things that, you know, we don't mess with data. We do worry a lot and think a lot and do a lot around security.

+ +

WILL: That's amazing. Awesome. Love it. I want to close on this: what does Healthie have coming up, anything exciting coming up in the next year?

+ +

CAVAN: I mean, I'm excited every day when I see our customers expanding when I see the new customers we're talking to. I mean, I think, really, we've been doing the same thing, just at a larger and larger scale, for the past seven years. And our goal for 2023 as a company, and we talk about this a lot internally, is to go from startup to scaleup.

+ +

So at the end of 2023, if I look back ten months from now and say, hey, what did we set out to do? What did we accomplish? It's did we continue to build the best team? Did we continue to build the best product? Did we continue to provide the best customer experience? And are our customers seeing a lot of success on the platform? And it's not like there's a new product line to enable that. You're not going to have some silver bullet that's going to change the dynamics. But it's really we just want to take what we're doing that we're doing a really good job of and just do that on a higher scale. So that's really what we're thinking about for 2023.

+ +

WILL: I love it. Sometimes just being consistent is the way to go, so I love that.

+ +

CAVAN: Yeah, you got to show up. Look, I used to wrestle. The way you become a good wrestler is not by knowing 800 wrestling moves. It's by knowing five moves and practicing them every day over and over again for years, and that's true of a lot of sports. It's true with startups. It's just consistent focus and having an aligned mission at the company. Really, really focused on pushing the ball forward every day, day in, day out, is just so, so important. And that's really what we do here.

+ +

WILL: I love it. Love it. Love it. Is there anything that we didn't cover that you would like to share with the audience?

+ +

CAVAN: I think if you're a company building in the digital health space, if you care about having these strong relationships with your patients, definitely check us out; we're gethealthie.com. Healthie is with an I-E. And then love talking to startups, love talking digital health, and always happy to talk.

+ +

WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Cavan Klinsky.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+i_X9g-Jt + + ]]> + + Will Larry + Cavan Klinsky + + + 466: Finding Center with Dr. Stephanie Smith + https://podcast.thoughtbot.com/466 + fbf53fd2-1b41-4f7b-9961-daafe80f9e31 + Thu, 16 Mar 2023 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Dr. Stephanie Smith is Clinical Psychologist and Founder of the Finding Center app, the first intuitive eating classes app. + +Victoria, along with surprise co-host thoughtbot's Director of Product Strategy, Jordyn Bonds talks to Dr. Stephanie about creating the Finding Center app to give people who are struggling with their bodies and their relationship with food a way to follow a plan, understand a path forward, and be able to see themselves getting healthier. + 49:24 + no + + + Dr. Stephanie Smith is Clinical Psychologist and Founder of the Finding Center app, the first intuitive eating classes app. +Victoria, along with surprise co-host thoughtbot's Director of Product Strategy, Jordyn Bonds talks to Dr. Stephanie about creating the Finding Center app to give people who are struggling with their bodies and their relationship with food a way to follow a plan, understand a path forward, and be able to see themselves getting healthier. +Finding Center app (https://www.findingcenterapp.com/) +Intuitive Eating by RDN Evelyn Tribole, MS and RDN Elyse Resch, MS (https://www.amazon.com/Intuitive-Eating-4th-Anti-Diet-Revolutionary/dp/1250255198/ref=sr_1_1?adgrpid=1342504264119419&hvadid=83906755364443&hvbmt=be&hvdev=c&hvlocphy=88301&hvnetw=o&hvqmt=e&hvtargid=kwd-83906869439485%3Aloc-190&hydadcr=15521_13519216&keywords=intuitive+eating+book&qid=1677806308&sr=8-1) +The Body Is Not an Apology, Second Edition: The Power of Radical Self-Love (https://www.amazon.com/Body-Not-Apology-Second-Self-Love/dp/1523090995/ref=sr_1_1?crid=3PDHVRXXDK93Y&keywords=the+body+is+not+an+apology+book&qid=1677806361&sprefix=the+body+is+not+an+%2Caps%2C159&sr=8-1) +Follow Dr. Stephanie Smith on LinkedIn (https://www.linkedin.com/in/stephaniemsmithpsyd/), Instagram (https://www.instagram.com/stephanie_smith_psyd/), or Facebook (https://www.facebook.com/stephaniesmithpsyd/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dr. Stephanie Smith, Clinical Psychologist and Founder of the Finding Center app, the first intuitive eating classes app. Thank you for joining me. +DR. SMITH: Yeah, it's a pleasure to be here. It's nice to see you. +VICTORIA: Nice to see you too. And we also have Jordyn, our Director of Product Strategy at thoughtbot. Hi, Jordyn. +JORDYN: Hello. +VICTORIA: So let's just kick this off. And Dr. Smith, tell me a little bit more about your Finding Center app. +DR. SMITH: So I created the Finding Center app really a little bit selfishly because I wanted to create what didn't exist for me 10 or 15 years ago when I was really struggling with food and my body. And I'm very by the book, you know, tell me what to do, and I'll follow that. And there just wasn't something like that at that time of my life. +And so I created the Finding Center app to give people who are struggling with their bodies and their relationship with food a way to follow a plan, a way to understand a path forward, and to be able to see themselves getting through this, you know, getting to a healthier tomorrow. And that's what I really wanted for myself, and that's what I hope to build here. +VICTORIA: Well, I love that it came out of a personal issue you were having. And what was the gap between that type of content versus what already existed in the market? +DR. SMITH: Back at that time, you know, this is probably dating all of us here a little bit. But at that time, [chuckles] apps were a little bit newer; technology was, of course, you know, things are growing so quickly. And there were things like books, so you could read something on your own. Or you might be able to go see a therapist or a counselor, but they may not specialize in this kind of thing. And so there really was sort of this DIY, like piece things together, figure it out, try a book, try a workbook, maybe they'll go together, maybe they won't. Or go see a provider, and they may or may not specialize. +But there really wasn't something that was going to be a direct guide for these issues. And certainly, at that time, and still exists today, there's this huge lack of available things that are respectful to body diversity and size diversity. And so, really looking for something that wasn't going to be further stigmatizing, it was and still is an extremely huge challenge in this marketplace. +VICTORIA: Great. And tell me more about, you know, you've mentioned intuitive eating. And how is that different from a diet or from your regular food tracking apps? +DR. SMITH: That's such a great question. So intuitive eating is really the most old school [laughs] kind of style of eating because it's what we're all born doing. If you've spent any time around toddlers, you know that they'll have a couple of bites of a sandwich, a little bit of apple, half a cookie, and then they'll go run and play. Kids are natural intuitive eaters, and that starts to fade as we get older. And we start to have this morality around food and morality around body and this pressure to change and have things different. And we kind of lose that intuitive ability to have half a cookie and go play because I'm done right now, and maybe I'll come back to it, maybe I won't. +Intuitive eating really is about this recognition that that's what you were born with. That's what your birthright is, and you still have that. And it's really kind of pulling away these kinds of stigmas and biases that culture puts on top of our relationships with food and our relationships with our bodies. And when we can pull that back, there's this beautiful natural ability to eat what we want and to find a balanced way of nourishing ourselves. And that's really what intuitive eating is about is getting back to that. +VICTORIA: I love that. And how did you go about taking what seems like even though it's a basic, like, at its most [laughs] basic concept, but it's this very big, different way of conceptualizing food and boil that down into like an application? [laughs] +DR. SMITH: I have to be very clear here. I did not do this on my own. [chuckles] So intuitive eating has been around for a long time. It was started by a couple of dieticians, Evelyn Tribole and Elyse Resch. They've recently been in The New York Times recently and in other places. So it's becoming a little bit of a hot thing, which is great. But I had those resources. +So I've been following people who kind of are in this space. And they are one of those people who had a book and a workbook, so you weren't able to get that kind of personalized walk-through. But these resources have existed, and those are some of the resources that are the ones I mentioned, you know, that I started putting together when there wasn't something like this app that existed. +So it's really borrowing from them and then tying intuitive eating into body acceptance, and body liberation, and radical self-love, you know, tying intuitive eating in with these things, with our bodies because body shame and how we treat our bodies in terms of nourishment these are really integrated concepts. And I wanted to bring them together in a very intentional and overt kind of way. +VICTORIA: I think that's wonderful. And I'm curious, Jordyn, if you have any thoughts on if you were meeting with a founder who had just built this app, what would be your first questions you would ask? +JORDYN: Frankly, a lot of what I would ask is what you've already asked. But the sort of next thing I would focus on are questions around who are your users? How did you figure out who to bring this to first? How did you make that decision? +DR. SMITH: That's a great question. So when I was building this, you know, I think I mentioned that I was really building it from this place of what would I have needed at that time? And so I'm really looking for people who kind of think similarly, you know, who really want structure, who want multimedia kind of support. I wanted journaling activities, and I wanted education, and I wanted something to think about or some mindfulness. I really wanted a lot of things because I learn in a lot of different ways. So I'm looking for people who like to learn that way. +And I'm also the type of person that when I do something, I really want to do it. I want to dive in. I want to figure it out, you know, I really want to show up for it, and this is that kind of thing. And so it was pretty natural to think about the type of, you know, maybe personality who would be a great fit for this. +And then, in terms of who it's for, I really started with people I knew. So the first program that I ran through it was an intensive version of the app, which meant that there were weekend group meetings with everyone. And there was live Q&A and a place for us to ask questions and respond back to each other and share. +And I really started with people that I knew and friends of friends because a lot of people, you know, I think if we all think about our networks, a lot of people struggle in their relationships with food and in their relationships with body. And so the first place I started was with the people I already knew and saying, "Do you know anyone else who would be a good fit for this?" And it has kind of blossomed from there. +JORDYN: What's been one of the more unexpected things you've learned from your users as you've gotten more people into the app using it? +DR. SMITH: I think one of the things that isn't necessarily unexpected at all but is really striking to me in terms of how impactful it is is how much medical stigma impacts everyone and especially those who are in larger bodies, or bodies who are marginalized for other reasons because of their health status, or racial status, or age, or other factors like that. +As a health psychologist, I like to think of my work and my workplace as being somewhere that people can come and feel safe, and feel heard, and feel understood. And now I'm seeing, you know, I work in a doctor's office, yet my experience of being in a doctor's office is so different from other people's experiences and the stories that I heard from others about how they went in for some kind of pain and weren't even offered physical therapy, you know, were offered a diet instead of that. And those kinds of stories, how many of those I've heard, has been really striking and really surprising to me how impactful that has been and how much work we really need to do to improve the experience for patients. +JORDYN: Given that finding of the importance of safety, how has that idea informed how you've gone about designing and building the app? +DR. SMITH: Of course, with a project like this, you know, I think a lot of founders on here have shared kind of building the airplane while you fly it. [chuckles] And so I've gone and, of course, recorded a lesson or made a journal entry activity or something like that. And then I am going back, and I'm adding things to those. So I'm doing a re-recording or adding a piece, or adjusting the journal prompts or the mindfulness activity, really to make some very clear statements there around if you've heard this kind of thing, you're not alone. +If you have experienced this type of being shamed, let's really bring that out of the darkness. Let's bring it into the light because shame is something that lives in the dark. And so really wanting to help people excavate the parts of that shame that they are willing and comfortable and wanting to bring out into the light and creating a space for that has become really important for me. +It is making sure that we're able to talk about these things and say, "No, yeah, I think my provider is a great person. I do think they care about me. And at the same time, they're living in this weight bias and this stigma place too. And these are the recommendations they gave me. And that was a person that I thought would be safe." And so really trying to have those balanced discussions around why that might happen and giving people a place to talk about that. +VICTORIA: And one example I've seen in, I think, in your marketing materials is a measurement like the BMI or the Body Mass Index. And that's one that even myself I've experienced being used on me in a way where it's like, "Well, the index is saying you're overweight." And I'm like, "Well, clearly, I'm not. [laughter] Something is wrong with this measurement." And I can't even...you probably have a greater understanding of the harm that causes in communities. +DR. SMITH: Yeah, that's such a great point. I have looked at that myself. And I remember the very first time that someone said that, like, "Well, you're overweight. Have you considered losing weight?" And I was coming in...I think I was coming in to talk about something related to my period, something like that. And I thought, why are we talking about this? What is going on? [laughs] Where did this come from? I just wanted to talk about switching my birth control. And it just comes into every conversation. +And I think even someone like me, even someone who's in this space where I'm going, well, this is a bunch of crap; I think we all know at this point BMI is a bunch of crap. But even knowing that there's still this part of me that...and maybe you relate to this too of just, well, I do live in this culture. And you're saying these words about me like overweight. And my immediate thought, even though the one coming after that is frustration, my immediate thought is, oh no, what's wrong with my body? It's to be afraid. How am I going to be treated? Or does this mean something bad about my health? +And so even these metrics like BMI do a terrible job at acknowledging body diversity and actual health and all of those things. They're still scary still. And I think in a body acceptance space; it's really important for us to also acknowledge that even though we want to be body-accepting and be advocates for ourselves, it's still really normal when someone gives us that kind of information, especially someone in a position of power like a health care provider, that when someone is saying those kinds of things to us that it can still hurt. Even though we know, maybe intellectually, this is where that's coming from, that it doesn't need to hurt, it still does. +VICTORIA: And it can have financial implications as well if they're indicating that you're not "healthy" quote, unquote, because of a statistic like that that is meaningless. [laughs] But yeah, that can affect your insurance and all other kinds of things, so... +DR. SMITH: Yeah. And I think the financial piece that you're bringing up there is such a good point because there's so much power and control dynamics that can occur around finances. We really are limited by [laughs] what we can afford and not afford to do. And so people who are limited in terms of what they're able to pursue for their health will have to go along with lots of things that they may not believe in or may not want to follow up on because that's what their doctor is telling them is within their insurance to do. And that's a really hard thing. +VICTORIA: Sounds like the app gives patients or people the tools to be able to push back in some of those scenarios and also furthering body acceptance and an understanding of eating habits. What is the kind of immediate goals for your app? What does success look like in the next six months? And then maybe what does success look like five years from now? +DR. SMITH: When you started asking that question, I almost felt like a magician or a stage performer putting on 18 different hats all at once. [laughs] And I thought, from which of these should I respond to that question? [laughs] And so there's the health care provider inside of me going, well, as many people getting the support that they need, that's the benefit. So if one person gets it, that's great. I want anyone who can feel greater liberation to have that. +And then that hat pops off, and the marketer hat that I've been wearing kind of pops on and is like, well, these are the metrics in terms of growth and collaboration with other people in this space that I want to do. I want to collaborate with more people who are working here, and there are metrics around that that I want to pursue. And then the person inside of me that has to make money goes, okay, well, this many sales. +And so I think success is a really hard thing for me to pin down. But if I were to summarize, trying to kind of encapsulate all of those roles, it really just is having more people experience the app, having more people experience the education there, and being able to get that feedback to make it better. This is the first year of growth, and so there's going to be so much learning. I don't know yet what's going to be the next big thing that makes me go, oh my gosh, how did I not put that in there? And I'm just so excited to get to that point where I'm getting more of that feedback so that I can continue to make it better and better. +VICTORIA: I love that. And I think that it's a great place to be, [laughs] and you have an app that has a meaning for people. And then you also have other ways to measure your success. And, Jordyn, I'm wondering if you have any thoughts on an initial strategy to kind of meet some of the goals that Stephanie is laying out. +JORDYN: I was actually going to go backward in time first, if you don't mind, and ask, as a person with an application now out in the world who does not have a technical background, could you tell us the story of how you went from this idea to those first steps of making it happen in the world? What did you do? Where did you go? +DR. SMITH: [laughs] Yeah, so this is, on my end anyway, kind of a wild story though it may be typical for those of you who have been in this space. But so for me, I had this idea that I wanted to do to take the classes that I already do...because I already teach classes and I teach them live, and I love to do it. It's so much fun for me. But I wanted to take those and make them accessible for more people. And I wanted to make them in such a way where people could go at their own pace, you know, kind of follow through. +And so I've had this idea for, I want to say, something like five years, but I just wasn't finding the right platform. A lot of the online courses and things like that I do like them, but they didn't feel as flexible as I wanted them to be. For me, when I'm listening to an app and learning information, I want to be able to listen offline. I want to be able to watch it sometimes. I'm really looking for a lot of flexibility. +And I didn't even have the thought of an app, but that's what an app gives you, you know, it gives you this ability to be flexible, to be on the go, to kind of make your learning what you want it to be. And so I didn't really know what I was looking for, but I knew that I hadn't found it. +And then I saw this program that helps you build apps. I think I saw an ad for it on Instagram or on Facebook, you know, just one of those very random things. And I saw the ad, and I went, oh, that's kind of interesting. And I went on the platform, and they do this thing which I think makes a lot of sense. And they say, "Well, here's a 30-day free trial. Do our educational thing to learn how to build an app. And then, if it's not for you, cancel at the end of 30 days, no big deal." So I thought, all right, that sounds good. +And what I didn't realize that they were doing...I don't know if you've heard this metaphor before, but maybe it's this concept that if you want to take the island, you have to burn the boats. Basically, it's this general kind of showing up on this island with the army and saying, "Okay, well, if we want to take the island, the best way to get my troops to be able to do that is to make it so that there's no way to go back basically." And that is what this program did. +It wound up walking me through these steps that were actually slowly burning the boats because about halfway through that free trial month, they said, "Okay, now we're going to post something online about this. And we're actually going to post every day for a week." And I'm just following the steps and going, wait a second, now I have to do this because now I've said I'm going to. +And so it finally kind of got me out of this hemming and hawing, and I don't know what to do and very much launched me into this, okay, well, now this is happening kind of place. And so it was really interesting to see that happen to myself. [laughs] I could kind of see it happening a little bit. And yeah, that's how it happened. +JORDYN: That's great. I love how you made sense of the process as a person going through it. And burning the boats to take the island metaphor is one I've never heard before. But now I have to know what the platform was [laughter] because it sounds like they did a really good job of getting you to put something out there. +DR. SMITH: Yeah, they really did. The platform is called Passion.io. And they are actually a platform that I think targets health and wellness influencers which, as you know from talking with me or if you follow my things, you know sometimes I have some beef with some of the things that they might share. We might not have the same idea about how to go about those things. But Passion.io was the platform, and they have a ton of learning tools. They've got a lot of different resources on there for walking you through the initial stages of creating something. +And then they also walk you through a little bit more high-level things. And one of the pieces that I really like about it is that underneath all of this how-to is this bolstering. Because I think for a lot of people, certainly for myself, there's this thing, this imposter syndrome that we all have of, well, I'm not good enough, or no one's going to like it. Or what if I'm embarrassed? Just the many, many places of doubt that we have. +And underneath all of the how-to is really this space of you've got this. You've got a good idea. If you don't try, you'll never know. And so that's really the undercurrent of all of that. And I found that combination of this is what to do, and here's why it's meaningful to you, and here's why you are in the best place to do it, and that was really helpful. +JORDYN: Yeah, I really love that. That's a lot of my work with early-stage founders is that. It is constantly saying, "You've got this. This is your space. You know it better than most. Just because you don't know everything there is to know about starting a tech business doesn't mean you aren't qualified to engage with your customer. So like, "If not you, who? And if not now, when?" is always [laughs] kind of what I'm asking. And it sounds like this platform does a lot of that coaching. +DR. SMITH: Yeah. And, Jordyn, I just want to comment, too; I'm sure for you, if you do this a lot, you may get to points where you go; gosh, do I still need to be giving the same kind of reassurance? And I just want to say on the end of someone receiving that reassurance, yes, [laughs] we still need it. And so that work that you're able to do of just providing that consistent I'm here for you, and you are here for you, and we're going to do this. It's amazing to me how much I have needed that, and I still need that. And I just appreciate anyone who is out there doing that because it is really, really, really hard to be that vulnerable. +JORDYN: Oh, 100%. And this is hard-won for me. I've been a founder twice and a very early employee at other startups twice. And what's amazing about that particular journey is that just when you feel like you're getting your footing at one stage, the stage changes. +DR. SMITH: [laughs] Yes. +JORDYN: So, to your point, you never stop needing that bolstering and that sort of just the coaching and the cheering on because the situation you find yourself in is constantly shifting under your feet. So 100% agree. +DR. SMITH: Yes. [laughs] It sounds like you absolutely have the experience to be the person [laughs] to shepherd people through this, which, thank goodness, somebody's got to do it. [laughs] +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +JORDYN: I just feel like with a lot of things...and as a mental health professional, you're in a better place than many to understand this, but with any big undertaking like starting a business, really just anything, training for a marathon, you name it, some very significant percentage of the challenge is mental is yourself. It is getting yourself into the mindset where you can keep doing it. And I feel like a lot of folks just focus on the tactical stuff, here's how to do this, here's what to do, which is great. And you need those things. +At least half the battle is inside of us. It is emotional. It is mental. And any amount of being able to acknowledge that and grapple with those feelings as they arise is going to just make everybody that much more effective, which I feel like it's great when folks are working on apps where that's built into the mission like yours is because it's like, you can't lose sight of that. It's actually your life's work. +DR. SMITH: Yeah. And this is going to be such a psychologist comment, so forgive me for [laughs] it. But it's such an interesting thing that you're pointing out because what we're really talking about, from my perspective, is this place on the graph where vulnerability meets your highest ability to perform. And so I think for a lot of industries, not just mine, it's that crossroad where I'm at optimum vulnerability to really be able to connect. +Because when we're not vulnerable, if I keep myself too safe, then I'm not going to be able to position myself in a place to reach the most people or produce something that's going to be the most meaningful. And so I have to be willing to say, "This is going to be [laughs] really scary. This is going to really suck for me sometimes, and I'm going to get it wrong. And it's still worth it to do that because of this meaning that I'm wanting to do." +And I don't think all times in someone's life is the time [chuckles] to do that, you know, this happens to be the time for me, which is wonderful, and scary, and hard, and terrible, [laughs] and all of the rest. But it's, I think, just being conscious that there is a necessary amount of vulnerability to achieve the potential with something like this that you want to achieve and acknowledging I am just going to be sitting in a lot of hard, and that means I'm doing it right. +JORDYN: Absolutely. Yeah. And it's sort of without meeting a challenge we don't achieve. But to your point, it's that right mix of challenge and vulnerability. You don't want either of those things getting too out of balance. That is kind of the art of this journey, but 100% agree. +DR. SMITH: Yeah, I was thinking just earlier today about stress because this is stressful. It's so difficult to do. And I was talking to a friend the other day, and I was saying, "Yeah, you know, I've just been stressed with all of these things that I was doing." And this person said, "You know, well, if you tried blah, blah, blah thing, it will take the stress away." [laughs] A substance you could use to take the stress away. And I said, "You know, I haven't thought about that, and I guess I could." +But I thought in my mind how quickly we went from talking about the particular things that I was dealing with that were causing stress to trying to fix for stress and how much that's a part of our culture. And I thought, you know, the level of stress that I'm having is appropriate to the situation. I don't actually want to dull that level of stress because I need it in the same way that a car might benefit from a backup camera. When it starts to beep louder, [chuckles] I want to hear that because that's letting me know I'm heading for a crash, and I want to be conscious of that. +So certainly, as a mental health provider, I think that's one of the things that's helping me move through. It's just that sensitivity to there's a certain level of stress and a certain utility to stress. That's important when you're building something because you're also needing to maintain yourself as a person, and you've got to monitor that pretty closely. +JORDYN: You're still in private practice. +DR. SMITH: Yeah. Yeah. +JORDYN: It sounds like you've got, and I think you alluded to this earlier, a lot of hats that you're wearing. +DR. SMITH: [laughs] Yes. +JORDYN: How has it gone balancing the launch of this app with the rest of the work that you're doing? +DR. SMITH: [sighs] Well, it's been a lot. So I am a private practice psychologist. I also have a nine-to-five. I work in a hospital as a health psychologist, and, you know, building the app and doing all of those things. And I think the biggest thing that's been important for me to be able to remind myself again, and again, and again, and again is just if it stops being what I want to do, even just in a moment, don't do it; do the next thing. +Because for me in this space, as much as I might say, you know, I've burned the boats...and that is motivating for me to get through particular things. I also have to recognize that just like my body will tell me what I need with food, my body is going to let me know when I've had too much for the day or when I've been doing too much of one thing. And I need to go for a walk, or I need to just go the heck to sleep, or I need to do whatever. I need to do a different project, toss the marketing down and take a look at some of the patient notes or whatever. +For me, because I love all of what I do, everything is important to me. I think I get something from all of that, and that is important to me too. You know, not every day is roses. There are days where I just want to say, screw all of it. I'm moving to Tahiti or whatever, whatever the fantasy is. But honestly, when it comes down to it, I do it because I love it. These things are meaningful to me, and being able to share in the world in all of the myriad ways that I do that I get a lot of meaning from that. +And I would start to become concerned about that for myself if I stopped getting something back. And I think this is basically how we feel in anything that we invest in, whether I'm investing time or love, or money, or whatever we invest because we also get back, and when that stops happening, that's the time when I reevaluate. And so far, that hasn't happened yet. So far, I've been able to pivot and stay conscious of where I'm at and switch from one thing that I love to something else that I love. And then I find when I do that; I do always want to go back. +VICTORIA: That's the benefit of wearing multiple hats, right? You can pick one up and put on a different one if you're matching your energy levels. +DR. SMITH: Yeah. They say...one of the quotes that I've always related to for better or for [laughs] worse is if you want something done, give it to someone who's busy, and I think that's true for me. I'm one of those people where I like a level of busy. I thrive on that; I enjoy it. And it's just staying conscious of the balance. +VICTORIA: And I think that's great. And we talk to founders about that a lot, actually, about how to balance their time. And it's interesting to hear from a psychologist's perspective. +DR. SMITH: Yeah, it's been an interesting thing going through this as a psychologist because when I do say things like, "Well, yeah, I've been stressed," People say, "What? But you're a psychologist. You're not supposed to feel stress." And I always think this is hilarious because I go, "What the heck do you think psychologists [laughs] are?" Stress is a normal part of life. I'm going to be stressed and ticked off, and irritable, and all of the things just like everyone else. +I am very fortunate to have additional skills for how to manage it when those feelings come up, which I'm extremely, extremely grateful for. But being stressed, or upset, or sad, or any of the range of unpleasant but completely normal human emotions, we all feel those [laughs] too. Those are just as natural for us. +VICTORIA: Like, I never thought the goal of psychology was to never be stressed. +[laughter] +DR. SMITH: Right. Yeah, it's just to become increasingly better able to manage it. +VICTORIA: That makes sense. With your approach to your app, are there experiments that you're designing in the app to see what your clients relate to more, or how are you building that? +DR. SMITH: Yeah, absolutely. So one of the things that I am kind of balancing right now is that there's this space with intuitive eating. It really covers nourishing yourself, and a lot of that is around food. But our relationships with how we nourish ourselves and how we relate to our bodies also impacts how we move our bodies or not, how we are intimate with our bodies or not, how we are in much, much broader spaces in the world. +There's a quote that says something like, "It's not about food, but food is sort of the stage where we enact what we're going through," kind of where we enact the deeper things going on for us. And so for me, really, what I'm experimenting with and balancing is how much do we want to focus completely on foodstuff? And how much do we also want to recognize that food is going to also dovetail into movement, and also dovetail into mental health, and also dovetail into how you manage stress at the end of the day, and also dovetail into the intimacy that you have in relationships, and the pleasure that you allow yourself or not, or that you think that you deserve? +So I think really what I'm doing now and probably what I'll be doing forever with it is finding the right balance of those things and making sure to be respectful of all that's impacted by someone when we talk about just their relationship with food and their bodies. We're talking about their whole lives and really wanting to be able to go deeply with that and not keep it just on the surface. +VICTORIA: That makes sense and an interesting thing to try to measure and experiment out within an application, right? +DR. SMITH: Mm-hmm. So one aspect of the app, and probably the most meaningful one, is the courses. And there's another aspect of the app, which is a subscription. And so that's weekly lessons that are similar to the courses in that they're journaling, and a lesson, and mindfulness, and different components to them. But rather than being step by step by step like the courses, they are kind of on different topics each week. And so that's really been a space for me to experiment with some of that and to see what people are into and what really resonates with folks. +And also, of course, to use places like social media, I'll use Instagram, and I'll do a reel on this topic, and a reel on this topic, and see how that goes or a visual or whatever. And I think it's really been an interesting process within the app and also in the other places where I'm able to advertise for it, like on social media, just to see what's meaningful for people. So much of this process is finding your people and creating things that are meaningful for them, and I'm still learning how to do that. +VICTORIA: I think that's great. And I love to hear you're experimenting on a weekly basis for what content really resonates with people. I'm wondering, Jordyn, if you have any advice or tips for how to find your market, how to find your people. +JORDYN: Well, in this scenario, since you've got folks using the app already, it's great because you basically have leads, trails to follow, breadcrumbs to [laughs] chase down. So I don't know how many users you have already. And you don't have to tell us if you don't want to. +DR. SMITH: [laughs] +JORDYN: But I would basically look at the patterns of their usage and find those folks who are really using the app in the way you feel it is most useful and follow up with them. Who are they? Interview them if you can. But if you can find out things about them anyway, zero in on those folks as a specific niche and see if you can get as many people who look like them and can be defined in any way. It really depends on the characteristics of the folks themselves. And it could be geographic. It could be some component of their identity. It could be anything. +But basically, those folks who are really getting the most out of your app in the ways that you are sort of locating value for them really double down on those folks. Can you find more people like that? Can you find out more about how they're using the app? Why it's resonating. That's what I would be doing right now, and it's possible that's what you're doing. [laughs] +DR. SMITH: Well, I'm kind of curious about how to do that, you know, because anything you ask of people is one more thing. [laughs] And I think the truth for a lot of us is that we have a lot of things. And so I have a hesitancy in saying, "Well, do I send a survey that someone has to fill out? Do I try to take some of their time over the phone or ask for an email?" Because, of course, anything that takes time is something someone needs to put into their lives. +And as willing, as I think people are to be helpful, and certainly I'm very fortunate to be around just incredible people, there's a limit to that. You don't want to be asking for too much. And so I would be curious from your perspective, Jordyn, if you think there's a right way to do that, if there's a way that you think is kind of the right way or a way [laughs] to try to strike that balance. +JORDYN: Yeah, definitely. And that dynamic is something you've got to be sensitive to. People are busy, and you are asking them for something. But at this very early stage, that's kind of the beauty of this stage of the work is that it's an opportunity to really build with people, to invite them into the process so that they feel like they're co-creating something with you. +And that's why focusing on those users who appear to be getting the most out of the app is the best place to go because they're going to be the most likely to want...if they're getting something out of it, they probably are pretty excited about that. They're probably going to be excited to talk to you about it, et cetera. But that said, you should do something to compensate, and I don't mean that necessarily with money but compensate them for their time and their effort. +But in a mission-driven context like yours, it's really a great opportunity to kind of bring the community along with you. These folks are your first champions. You'll be surprised. In my experience, the people who are the most sort of impassioned about what you're doing and are benefiting from it the most are more than excited to help. And the channels how you make this ask just totally depends on the details of these folks and how they prefer to communicate. +So with regard to the question around a survey versus getting people to talk on the phone, it's a little bit of trial and error. Send out a survey, see if people respond. Putting a survey in the app is great, especially if it's just one question or two questions right after some key interaction. So maybe they've done today's lesson, or this week's lesson, or this week's activity, and right afterward, asking them one question about how they're finding the app. +And then, if they engage with that, then the follow-up can be, "Hey, thank you so much for giving me that feedback. If you're willing, I'd love to chat for 20 minutes with you about this. I really want to be creating this with my customers and my users. So no big deal if you don't have time; I get it. But it would be really valuable." +And you'll be surprised, I think, [laughs] how many people are more than excited because they really do feel it's a signal to them that you care deeply about their experience and that you really are trying to make that experience the best thing for them. It's sort of unintuitive. It feels like you're asking them to give you something, but what you're giving them is you're leaning in to co-creating with them. +DR. SMITH: Yeah. Jordyn, I love that. I think that's such a great idea. And from a mental health perspective, it's so authentic, too, because, of course, you want to offer people the opportunity to share about what they've learned and to be able to process it out loud. And you're right, that will be helpful to me, but it is also a service that's not dissimilar to what sometimes people come to therapy for, you know, is to just be able to process their experience out loud and be heard...and some of those things for themselves. So, Jordyn, I think that's such a great approach to that, and I really appreciate that. That's great. +JORDYN: Absolutely. And I would only add that it's another signal...who ends up responding positively to that is another signal for you on who your best collaborators are in the app. I mean, you can look at how they're using it to answer that question. But it's another signal to you like, oh, these are the folks who are really finding this useful. They're finding it so useful if they want to talk to me about it. And that will then additionally help you double down on those folks. +DR. SMITH: I'm curious for you, Jordyn, and I'm curious about how to reach a broader audience. So, certainly, I know people, and people who know me are much more comfortable reaching out to use the app or to be part of things because they know me and trust that it's going to be good. But expanding that to people that I don't know or that aren't, you know, through somebody, through a direct connection, that part is more challenging, of course. Because how would they know to trust me, especially when they've been around providers, as we were talking about, where sometimes that trust can be broken in some of these very vulnerable areas? +I've been experimenting with some things like creating an Instagram and things like that because I wanted to create a space for people to see what is this person all about? What is this messaging? But I'm curious if there are other ways that you would recommend to reach people who don't know me who would be then willing to take a chance on something like a course, which is often a kind of a high-ticket high-investment type of thing. +JORDYN: Well, there are myriad ways to do that, too, that come to mind, the kind that sort of define the ends of the spectrum. One of them is along the lines of what you're doing with Instagram, basically, advertise. Do a Google ad, do an ad on Instagram. You're going to capture a certain segment of people who are maybe not as focused on relationship-based referrals, who maybe are suffering in isolation, maybe they're not talking to anyone about this. So that's sort of one end. +But the other, I would say, is reaching out to fellow clinicians who you have a good relationship with and saying, "Hey, is this something you'd be willing to recommend to your patients or the folks that you work with? If not, why not?" Basically, activate your professional network in terms of adding this as another resource that they recommend to folks because then you're kind of multiplying that people you know effect, and that can be very powerful. +DR. SMITH: Yeah, it's such an interesting thing too because as you were talking, I started noticing, in my own mind, that little piece that we were talking about before of this kind of like, ah, well, I don't want to burden anyone. I don't want to give them one more thing to do. Then I thought, well, I love resources for my patients; that's only to the good. [laughs] I love having those things. +And so it was so interesting just to kind of observe that kind of process happening in real-time in my mind of this little bit of doubt that makes me go, oh, that makes me nervous, and then having to dig down to what you're actually telling me [laughs] because this is value-added. +JORDYN: 100%. And I'm glad that you noticed that and brought it up because I think this is especially for underrepresented founders, so women, people of color, so much self-doubt. And that hurdle is sometimes the biggest hurdle. And what I did, this is funny; this is fairly tactical. +DR. SMITH: [laughs] +JORDYN: When I was a founder, I made a document that was basically a reminder to myself. I would look at it before almost every call I had with anybody about what I was working on. But it was basically, hey, Jordyn, why are you doing this? [laughs] And it was like, why does this thing need to exist? Why am I the right person to be making it? Sort of a series of those things. And just to remind myself every time that what I was doing was valuable and that I'm not out there trying to get people to do something for me. I'm trying to get them to do something for themselves. +I'm taking a problem they're already trying to solve for themselves and just giving them another tool. That's it. And if they don't want to pick it up right now, that's fine. It might not be the right time. But reaching out to other practitioners and saying, "Hey, I have this tool. And the tool was developed out of a lot of the same things I'm imagining all of you are experiencing in your practices." A significant number of them are going to be like, "Oh great," just what you said, "Great, another tool. I can add this one. And maybe it won't be right for every one of my patients, but it might be right for some of them." +And just getting around that in your heart of, like, you're not asking them for something. You're giving them another resource. And in fact, not doing that sells yourself short, sells them short, frankly. You're not making this for you. This isn't merely about satisfying your own ego. I'm sure there's a little bit of that in there. +DR. SMITH: [laughs] +JORDYN: There always is. But for the most part, you're trying to help people, and by not telling them about what you're doing or offering it to them as a resource, it sort of defeats the purpose. +DR. SMITH: Yeah, it's such an important reframe. And like we were talking about before, it's one of those things that I think just needs to be on loop, [laughs] in the heads for founders. And probably some version of this on loop for all of us, you know, just as we're going through life kind of reminding ourselves my presence is not a burden. [laughs] It reminds me a little bit of what Sonya Renee Taylor kind of started with, "The Body is Not An Apology." And I think this is basically kind of going off of that topic. You know, I'm not a burden. +JORDYN: Absolutely. And I love that frame. You're doing this for a reason. You're not a burden. Your app that is out there helping people is not a burden; quite the opposite. +DR. SMITH: Right. It's amazing how [laughs] important that reminder is. +VICTORIA: Yeah, I love that. And, Jordyn, you also have our incubator program coming up soon for other founders. Do you want to mention that real quick? +JORDYN: Of course, I would love to. thoughtbot has a new incubator program launching this year. We have our first run of it starting in mid-March. Who this is for is non-technical founding teams. So you might be a solo person. You might have a team, but you haven't found that technical co-founder or partner yet, but your business idea involves building an app or building software of some kind. And basically, you're at the early stages. You haven't launched anything. You've identified the opportunity, maybe you've talked to a bunch of your potential users or customers, but you're not sure if there's a there there and what to do about it. That's the ideal sort of stage and persona. +And the program is really about helping those non-technical founding teams validate the market opportunity, do some experiments with product, basically build a couple of features, maybe a landing page that expresses the value proposition, et cetera, just to learn as much as they can about what the opportunity is and how they might need it with software. Get them used to working with a technical team and then help them with their planning for next steps, maybe that's raising capital, or maybe it is finding a technical co-founder. We can help with that. That's the idea. It's an eight-week program. Everybody who sees themselves in what I just said should apply. And the URL to apply is thoughtbot.com/incubator. +VICTORIA: Great. Thank you so much, Jordyn. And thank you for all your advice and your questions that you brought to the episode today. And, Stephanie, is there any final takeaways you'd like to leave our listeners with? +DR. SMITH: No, I just think this was such an excellent opportunity. I feel like I learned a lot from it. And I want to thank you both so much for taking the time. It's really been a pleasure. +VICTORIA: Wonderful. All right. Yes, thank you both so much for joining me today. +And for our listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guests: Dr. Stephanie Smith and Jordyn Bonds. + + + Dr. Stephanie Smith is Clinical Psychologist and Founder of the Finding Center app, the first intuitive eating classes app.

+ +

Victoria, along with surprise co-host thoughtbot's Director of Product Strategy, Jordyn Bonds talks to Dr. Stephanie about creating the Finding Center app to give people who are struggling with their bodies and their relationship with food a way to follow a plan, understand a path forward, and be able to see themselves getting healthier.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dr. Stephanie Smith, Clinical Psychologist and Founder of the Finding Center app, the first intuitive eating classes app. Thank you for joining me.

+ +

DR. SMITH: Yeah, it's a pleasure to be here. It's nice to see you.

+ +

VICTORIA: Nice to see you too. And we also have Jordyn, our Director of Product Strategy at thoughtbot. Hi, Jordyn.

+ +

JORDYN: Hello.

+ +

VICTORIA: So let's just kick this off. And Dr. Smith, tell me a little bit more about your Finding Center app.

+ +

DR. SMITH: So I created the Finding Center app really a little bit selfishly because I wanted to create what didn't exist for me 10 or 15 years ago when I was really struggling with food and my body. And I'm very by the book, you know, tell me what to do, and I'll follow that. And there just wasn't something like that at that time of my life.

+ +

And so I created the Finding Center app to give people who are struggling with their bodies and their relationship with food a way to follow a plan, a way to understand a path forward, and to be able to see themselves getting through this, you know, getting to a healthier tomorrow. And that's what I really wanted for myself, and that's what I hope to build here.

+ +

VICTORIA: Well, I love that it came out of a personal issue you were having. And what was the gap between that type of content versus what already existed in the market?

+ +

DR. SMITH: Back at that time, you know, this is probably dating all of us here a little bit. But at that time, [chuckles] apps were a little bit newer; technology was, of course, you know, things are growing so quickly. And there were things like books, so you could read something on your own. Or you might be able to go see a therapist or a counselor, but they may not specialize in this kind of thing. And so there really was sort of this DIY, like piece things together, figure it out, try a book, try a workbook, maybe they'll go together, maybe they won't. Or go see a provider, and they may or may not specialize.

+ +

But there really wasn't something that was going to be a direct guide for these issues. And certainly, at that time, and still exists today, there's this huge lack of available things that are respectful to body diversity and size diversity. And so, really looking for something that wasn't going to be further stigmatizing, it was and still is an extremely huge challenge in this marketplace.

+ +

VICTORIA: Great. And tell me more about, you know, you've mentioned intuitive eating. And how is that different from a diet or from your regular food tracking apps?

+ +

DR. SMITH: That's such a great question. So intuitive eating is really the most old school [laughs] kind of style of eating because it's what we're all born doing. If you've spent any time around toddlers, you know that they'll have a couple of bites of a sandwich, a little bit of apple, half a cookie, and then they'll go run and play. Kids are natural intuitive eaters, and that starts to fade as we get older. And we start to have this morality around food and morality around body and this pressure to change and have things different. And we kind of lose that intuitive ability to have half a cookie and go play because I'm done right now, and maybe I'll come back to it, maybe I won't.

+ +

Intuitive eating really is about this recognition that that's what you were born with. That's what your birthright is, and you still have that. And it's really kind of pulling away these kinds of stigmas and biases that culture puts on top of our relationships with food and our relationships with our bodies. And when we can pull that back, there's this beautiful natural ability to eat what we want and to find a balanced way of nourishing ourselves. And that's really what intuitive eating is about is getting back to that.

+ +

VICTORIA: I love that. And how did you go about taking what seems like even though it's a basic, like, at its most [laughs] basic concept, but it's this very big, different way of conceptualizing food and boil that down into like an application? [laughs]

+ +

DR. SMITH: I have to be very clear here. I did not do this on my own. [chuckles] So intuitive eating has been around for a long time. It was started by a couple of dieticians, Evelyn Tribole and Elyse Resch. They've recently been in The New York Times recently and in other places. So it's becoming a little bit of a hot thing, which is great. But I had those resources.

+ +

So I've been following people who kind of are in this space. And they are one of those people who had a book and a workbook, so you weren't able to get that kind of personalized walk-through. But these resources have existed, and those are some of the resources that are the ones I mentioned, you know, that I started putting together when there wasn't something like this app that existed.

+ +

So it's really borrowing from them and then tying intuitive eating into body acceptance, and body liberation, and radical self-love, you know, tying intuitive eating in with these things, with our bodies because body shame and how we treat our bodies in terms of nourishment these are really integrated concepts. And I wanted to bring them together in a very intentional and overt kind of way.

+ +

VICTORIA: I think that's wonderful. And I'm curious, Jordyn, if you have any thoughts on if you were meeting with a founder who had just built this app, what would be your first questions you would ask?

+ +

JORDYN: Frankly, a lot of what I would ask is what you've already asked. But the sort of next thing I would focus on are questions around who are your users? How did you figure out who to bring this to first? How did you make that decision?

+ +

DR. SMITH: That's a great question. So when I was building this, you know, I think I mentioned that I was really building it from this place of what would I have needed at that time? And so I'm really looking for people who kind of think similarly, you know, who really want structure, who want multimedia kind of support. I wanted journaling activities, and I wanted education, and I wanted something to think about or some mindfulness. I really wanted a lot of things because I learn in a lot of different ways. So I'm looking for people who like to learn that way.

+ +

And I'm also the type of person that when I do something, I really want to do it. I want to dive in. I want to figure it out, you know, I really want to show up for it, and this is that kind of thing. And so it was pretty natural to think about the type of, you know, maybe personality who would be a great fit for this.

+ +

And then, in terms of who it's for, I really started with people I knew. So the first program that I ran through it was an intensive version of the app, which meant that there were weekend group meetings with everyone. And there was live Q&A and a place for us to ask questions and respond back to each other and share.

+ +

And I really started with people that I knew and friends of friends because a lot of people, you know, I think if we all think about our networks, a lot of people struggle in their relationships with food and in their relationships with body. And so the first place I started was with the people I already knew and saying, "Do you know anyone else who would be a good fit for this?" And it has kind of blossomed from there.

+ +

JORDYN: What's been one of the more unexpected things you've learned from your users as you've gotten more people into the app using it?

+ +

DR. SMITH: I think one of the things that isn't necessarily unexpected at all but is really striking to me in terms of how impactful it is is how much medical stigma impacts everyone and especially those who are in larger bodies, or bodies who are marginalized for other reasons because of their health status, or racial status, or age, or other factors like that.

+ +

As a health psychologist, I like to think of my work and my workplace as being somewhere that people can come and feel safe, and feel heard, and feel understood. And now I'm seeing, you know, I work in a doctor's office, yet my experience of being in a doctor's office is so different from other people's experiences and the stories that I heard from others about how they went in for some kind of pain and weren't even offered physical therapy, you know, were offered a diet instead of that. And those kinds of stories, how many of those I've heard, has been really striking and really surprising to me how impactful that has been and how much work we really need to do to improve the experience for patients.

+ +

JORDYN: Given that finding of the importance of safety, how has that idea informed how you've gone about designing and building the app?

+ +

DR. SMITH: Of course, with a project like this, you know, I think a lot of founders on here have shared kind of building the airplane while you fly it. [chuckles] And so I've gone and, of course, recorded a lesson or made a journal entry activity or something like that. And then I am going back, and I'm adding things to those. So I'm doing a re-recording or adding a piece, or adjusting the journal prompts or the mindfulness activity, really to make some very clear statements there around if you've heard this kind of thing, you're not alone.

+ +

If you have experienced this type of being shamed, let's really bring that out of the darkness. Let's bring it into the light because shame is something that lives in the dark. And so really wanting to help people excavate the parts of that shame that they are willing and comfortable and wanting to bring out into the light and creating a space for that has become really important for me.

+ +

It is making sure that we're able to talk about these things and say, "No, yeah, I think my provider is a great person. I do think they care about me. And at the same time, they're living in this weight bias and this stigma place too. And these are the recommendations they gave me. And that was a person that I thought would be safe." And so really trying to have those balanced discussions around why that might happen and giving people a place to talk about that.

+ +

VICTORIA: And one example I've seen in, I think, in your marketing materials is a measurement like the BMI or the Body Mass Index. And that's one that even myself I've experienced being used on me in a way where it's like, "Well, the index is saying you're overweight." And I'm like, "Well, clearly, I'm not. [laughter] Something is wrong with this measurement." And I can't even...you probably have a greater understanding of the harm that causes in communities.

+ +

DR. SMITH: Yeah, that's such a great point. I have looked at that myself. And I remember the very first time that someone said that, like, "Well, you're overweight. Have you considered losing weight?" And I was coming in...I think I was coming in to talk about something related to my period, something like that. And I thought, why are we talking about this? What is going on? [laughs] Where did this come from? I just wanted to talk about switching my birth control. And it just comes into every conversation.

+ +

And I think even someone like me, even someone who's in this space where I'm going, well, this is a bunch of crap; I think we all know at this point BMI is a bunch of crap. But even knowing that there's still this part of me that...and maybe you relate to this too of just, well, I do live in this culture. And you're saying these words about me like overweight. And my immediate thought, even though the one coming after that is frustration, my immediate thought is, oh no, what's wrong with my body? It's to be afraid. How am I going to be treated? Or does this mean something bad about my health?

+ +

And so even these metrics like BMI do a terrible job at acknowledging body diversity and actual health and all of those things. They're still scary still. And I think in a body acceptance space; it's really important for us to also acknowledge that even though we want to be body-accepting and be advocates for ourselves, it's still really normal when someone gives us that kind of information, especially someone in a position of power like a health care provider, that when someone is saying those kinds of things to us that it can still hurt. Even though we know, maybe intellectually, this is where that's coming from, that it doesn't need to hurt, it still does.

+ +

VICTORIA: And it can have financial implications as well if they're indicating that you're not "healthy" quote, unquote, because of a statistic like that that is meaningless. [laughs] But yeah, that can affect your insurance and all other kinds of things, so...

+ +

DR. SMITH: Yeah. And I think the financial piece that you're bringing up there is such a good point because there's so much power and control dynamics that can occur around finances. We really are limited by [laughs] what we can afford and not afford to do. And so people who are limited in terms of what they're able to pursue for their health will have to go along with lots of things that they may not believe in or may not want to follow up on because that's what their doctor is telling them is within their insurance to do. And that's a really hard thing.

+ +

VICTORIA: Sounds like the app gives patients or people the tools to be able to push back in some of those scenarios and also furthering body acceptance and an understanding of eating habits. What is the kind of immediate goals for your app? What does success look like in the next six months? And then maybe what does success look like five years from now?

+ +

DR. SMITH: When you started asking that question, I almost felt like a magician or a stage performer putting on 18 different hats all at once. [laughs] And I thought, from which of these should I respond to that question? [laughs] And so there's the health care provider inside of me going, well, as many people getting the support that they need, that's the benefit. So if one person gets it, that's great. I want anyone who can feel greater liberation to have that.

+ +

And then that hat pops off, and the marketer hat that I've been wearing kind of pops on and is like, well, these are the metrics in terms of growth and collaboration with other people in this space that I want to do. I want to collaborate with more people who are working here, and there are metrics around that that I want to pursue. And then the person inside of me that has to make money goes, okay, well, this many sales.

+ +

And so I think success is a really hard thing for me to pin down. But if I were to summarize, trying to kind of encapsulate all of those roles, it really just is having more people experience the app, having more people experience the education there, and being able to get that feedback to make it better. This is the first year of growth, and so there's going to be so much learning. I don't know yet what's going to be the next big thing that makes me go, oh my gosh, how did I not put that in there? And I'm just so excited to get to that point where I'm getting more of that feedback so that I can continue to make it better and better.

+ +

VICTORIA: I love that. And I think that it's a great place to be, [laughs] and you have an app that has a meaning for people. And then you also have other ways to measure your success. And, Jordyn, I'm wondering if you have any thoughts on an initial strategy to kind of meet some of the goals that Stephanie is laying out.

+ +

JORDYN: I was actually going to go backward in time first, if you don't mind, and ask, as a person with an application now out in the world who does not have a technical background, could you tell us the story of how you went from this idea to those first steps of making it happen in the world? What did you do? Where did you go?

+ +

DR. SMITH: [laughs] Yeah, so this is, on my end anyway, kind of a wild story though it may be typical for those of you who have been in this space. But so for me, I had this idea that I wanted to do to take the classes that I already do...because I already teach classes and I teach them live, and I love to do it. It's so much fun for me. But I wanted to take those and make them accessible for more people. And I wanted to make them in such a way where people could go at their own pace, you know, kind of follow through.

+ +

And so I've had this idea for, I want to say, something like five years, but I just wasn't finding the right platform. A lot of the online courses and things like that I do like them, but they didn't feel as flexible as I wanted them to be. For me, when I'm listening to an app and learning information, I want to be able to listen offline. I want to be able to watch it sometimes. I'm really looking for a lot of flexibility.

+ +

And I didn't even have the thought of an app, but that's what an app gives you, you know, it gives you this ability to be flexible, to be on the go, to kind of make your learning what you want it to be. And so I didn't really know what I was looking for, but I knew that I hadn't found it.

+ +

And then I saw this program that helps you build apps. I think I saw an ad for it on Instagram or on Facebook, you know, just one of those very random things. And I saw the ad, and I went, oh, that's kind of interesting. And I went on the platform, and they do this thing which I think makes a lot of sense. And they say, "Well, here's a 30-day free trial. Do our educational thing to learn how to build an app. And then, if it's not for you, cancel at the end of 30 days, no big deal." So I thought, all right, that sounds good.

+ +

And what I didn't realize that they were doing...I don't know if you've heard this metaphor before, but maybe it's this concept that if you want to take the island, you have to burn the boats. Basically, it's this general kind of showing up on this island with the army and saying, "Okay, well, if we want to take the island, the best way to get my troops to be able to do that is to make it so that there's no way to go back basically." And that is what this program did.

+ +

It wound up walking me through these steps that were actually slowly burning the boats because about halfway through that free trial month, they said, "Okay, now we're going to post something online about this. And we're actually going to post every day for a week." And I'm just following the steps and going, wait a second, now I have to do this because now I've said I'm going to.

+ +

And so it finally kind of got me out of this hemming and hawing, and I don't know what to do and very much launched me into this, okay, well, now this is happening kind of place. And so it was really interesting to see that happen to myself. [laughs] I could kind of see it happening a little bit. And yeah, that's how it happened.

+ +

JORDYN: That's great. I love how you made sense of the process as a person going through it. And burning the boats to take the island metaphor is one I've never heard before. But now I have to know what the platform was [laughter] because it sounds like they did a really good job of getting you to put something out there.

+ +

DR. SMITH: Yeah, they really did. The platform is called Passion.io. And they are actually a platform that I think targets health and wellness influencers which, as you know from talking with me or if you follow my things, you know sometimes I have some beef with some of the things that they might share. We might not have the same idea about how to go about those things. But Passion.io was the platform, and they have a ton of learning tools. They've got a lot of different resources on there for walking you through the initial stages of creating something.

+ +

And then they also walk you through a little bit more high-level things. And one of the pieces that I really like about it is that underneath all of this how-to is this bolstering. Because I think for a lot of people, certainly for myself, there's this thing, this imposter syndrome that we all have of, well, I'm not good enough, or no one's going to like it. Or what if I'm embarrassed? Just the many, many places of doubt that we have.

+ +

And underneath all of the how-to is really this space of you've got this. You've got a good idea. If you don't try, you'll never know. And so that's really the undercurrent of all of that. And I found that combination of this is what to do, and here's why it's meaningful to you, and here's why you are in the best place to do it, and that was really helpful.

+ +

JORDYN: Yeah, I really love that. That's a lot of my work with early-stage founders is that. It is constantly saying, "You've got this. This is your space. You know it better than most. Just because you don't know everything there is to know about starting a tech business doesn't mean you aren't qualified to engage with your customer. So like, "If not you, who? And if not now, when?" is always [laughs] kind of what I'm asking. And it sounds like this platform does a lot of that coaching.

+ +

DR. SMITH: Yeah. And, Jordyn, I just want to comment, too; I'm sure for you, if you do this a lot, you may get to points where you go; gosh, do I still need to be giving the same kind of reassurance? And I just want to say on the end of someone receiving that reassurance, yes, [laughs] we still need it. And so that work that you're able to do of just providing that consistent I'm here for you, and you are here for you, and we're going to do this. It's amazing to me how much I have needed that, and I still need that. And I just appreciate anyone who is out there doing that because it is really, really, really hard to be that vulnerable.

+ +

JORDYN: Oh, 100%. And this is hard-won for me. I've been a founder twice and a very early employee at other startups twice. And what's amazing about that particular journey is that just when you feel like you're getting your footing at one stage, the stage changes.

+ +

DR. SMITH: [laughs] Yes.

+ +

JORDYN: So, to your point, you never stop needing that bolstering and that sort of just the coaching and the cheering on because the situation you find yourself in is constantly shifting under your feet. So 100% agree.

+ +

DR. SMITH: Yes. [laughs] It sounds like you absolutely have the experience to be the person [laughs] to shepherd people through this, which, thank goodness, somebody's got to do it. [laughs]

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

JORDYN: I just feel like with a lot of things...and as a mental health professional, you're in a better place than many to understand this, but with any big undertaking like starting a business, really just anything, training for a marathon, you name it, some very significant percentage of the challenge is mental is yourself. It is getting yourself into the mindset where you can keep doing it. And I feel like a lot of folks just focus on the tactical stuff, here's how to do this, here's what to do, which is great. And you need those things.

+ +

At least half the battle is inside of us. It is emotional. It is mental. And any amount of being able to acknowledge that and grapple with those feelings as they arise is going to just make everybody that much more effective, which I feel like it's great when folks are working on apps where that's built into the mission like yours is because it's like, you can't lose sight of that. It's actually your life's work.

+ +

DR. SMITH: Yeah. And this is going to be such a psychologist comment, so forgive me for [laughs] it. But it's such an interesting thing that you're pointing out because what we're really talking about, from my perspective, is this place on the graph where vulnerability meets your highest ability to perform. And so I think for a lot of industries, not just mine, it's that crossroad where I'm at optimum vulnerability to really be able to connect.

+ +

Because when we're not vulnerable, if I keep myself too safe, then I'm not going to be able to position myself in a place to reach the most people or produce something that's going to be the most meaningful. And so I have to be willing to say, "This is going to be [laughs] really scary. This is going to really suck for me sometimes, and I'm going to get it wrong. And it's still worth it to do that because of this meaning that I'm wanting to do."

+ +

And I don't think all times in someone's life is the time [chuckles] to do that, you know, this happens to be the time for me, which is wonderful, and scary, and hard, and terrible, [laughs] and all of the rest. But it's, I think, just being conscious that there is a necessary amount of vulnerability to achieve the potential with something like this that you want to achieve and acknowledging I am just going to be sitting in a lot of hard, and that means I'm doing it right.

+ +

JORDYN: Absolutely. Yeah. And it's sort of without meeting a challenge we don't achieve. But to your point, it's that right mix of challenge and vulnerability. You don't want either of those things getting too out of balance. That is kind of the art of this journey, but 100% agree.

+ +

DR. SMITH: Yeah, I was thinking just earlier today about stress because this is stressful. It's so difficult to do. And I was talking to a friend the other day, and I was saying, "Yeah, you know, I've just been stressed with all of these things that I was doing." And this person said, "You know, well, if you tried blah, blah, blah thing, it will take the stress away." [laughs] A substance you could use to take the stress away. And I said, "You know, I haven't thought about that, and I guess I could."

+ +

But I thought in my mind how quickly we went from talking about the particular things that I was dealing with that were causing stress to trying to fix for stress and how much that's a part of our culture. And I thought, you know, the level of stress that I'm having is appropriate to the situation. I don't actually want to dull that level of stress because I need it in the same way that a car might benefit from a backup camera. When it starts to beep louder, [chuckles] I want to hear that because that's letting me know I'm heading for a crash, and I want to be conscious of that.

+ +

So certainly, as a mental health provider, I think that's one of the things that's helping me move through. It's just that sensitivity to there's a certain level of stress and a certain utility to stress. That's important when you're building something because you're also needing to maintain yourself as a person, and you've got to monitor that pretty closely.

+ +

JORDYN: You're still in private practice.

+ +

DR. SMITH: Yeah. Yeah.

+ +

JORDYN: It sounds like you've got, and I think you alluded to this earlier, a lot of hats that you're wearing.

+ +

DR. SMITH: [laughs] Yes.

+ +

JORDYN: How has it gone balancing the launch of this app with the rest of the work that you're doing?

+ +

DR. SMITH: [sighs] Well, it's been a lot. So I am a private practice psychologist. I also have a nine-to-five. I work in a hospital as a health psychologist, and, you know, building the app and doing all of those things. And I think the biggest thing that's been important for me to be able to remind myself again, and again, and again, and again is just if it stops being what I want to do, even just in a moment, don't do it; do the next thing.

+ +

Because for me in this space, as much as I might say, you know, I've burned the boats...and that is motivating for me to get through particular things. I also have to recognize that just like my body will tell me what I need with food, my body is going to let me know when I've had too much for the day or when I've been doing too much of one thing. And I need to go for a walk, or I need to just go the heck to sleep, or I need to do whatever. I need to do a different project, toss the marketing down and take a look at some of the patient notes or whatever.

+ +

For me, because I love all of what I do, everything is important to me. I think I get something from all of that, and that is important to me too. You know, not every day is roses. There are days where I just want to say, screw all of it. I'm moving to Tahiti or whatever, whatever the fantasy is. But honestly, when it comes down to it, I do it because I love it. These things are meaningful to me, and being able to share in the world in all of the myriad ways that I do that I get a lot of meaning from that.

+ +

And I would start to become concerned about that for myself if I stopped getting something back. And I think this is basically how we feel in anything that we invest in, whether I'm investing time or love, or money, or whatever we invest because we also get back, and when that stops happening, that's the time when I reevaluate. And so far, that hasn't happened yet. So far, I've been able to pivot and stay conscious of where I'm at and switch from one thing that I love to something else that I love. And then I find when I do that; I do always want to go back.

+ +

VICTORIA: That's the benefit of wearing multiple hats, right? You can pick one up and put on a different one if you're matching your energy levels.

+ +

DR. SMITH: Yeah. They say...one of the quotes that I've always related to for better or for [laughs] worse is if you want something done, give it to someone who's busy, and I think that's true for me. I'm one of those people where I like a level of busy. I thrive on that; I enjoy it. And it's just staying conscious of the balance.

+ +

VICTORIA: And I think that's great. And we talk to founders about that a lot, actually, about how to balance their time. And it's interesting to hear from a psychologist's perspective.

+ +

DR. SMITH: Yeah, it's been an interesting thing going through this as a psychologist because when I do say things like, "Well, yeah, I've been stressed," People say, "What? But you're a psychologist. You're not supposed to feel stress." And I always think this is hilarious because I go, "What the heck do you think psychologists [laughs] are?" Stress is a normal part of life. I'm going to be stressed and ticked off, and irritable, and all of the things just like everyone else.

+ +

I am very fortunate to have additional skills for how to manage it when those feelings come up, which I'm extremely, extremely grateful for. But being stressed, or upset, or sad, or any of the range of unpleasant but completely normal human emotions, we all feel those [laughs] too. Those are just as natural for us.

+ +

VICTORIA: Like, I never thought the goal of psychology was to never be stressed.

+ +

[laughter]

+ +

DR. SMITH: Right. Yeah, it's just to become increasingly better able to manage it.

+ +

VICTORIA: That makes sense. With your approach to your app, are there experiments that you're designing in the app to see what your clients relate to more, or how are you building that?

+ +

DR. SMITH: Yeah, absolutely. So one of the things that I am kind of balancing right now is that there's this space with intuitive eating. It really covers nourishing yourself, and a lot of that is around food. But our relationships with how we nourish ourselves and how we relate to our bodies also impacts how we move our bodies or not, how we are intimate with our bodies or not, how we are in much, much broader spaces in the world.

+ +

There's a quote that says something like, "It's not about food, but food is sort of the stage where we enact what we're going through," kind of where we enact the deeper things going on for us. And so for me, really, what I'm experimenting with and balancing is how much do we want to focus completely on foodstuff? And how much do we also want to recognize that food is going to also dovetail into movement, and also dovetail into mental health, and also dovetail into how you manage stress at the end of the day, and also dovetail into the intimacy that you have in relationships, and the pleasure that you allow yourself or not, or that you think that you deserve?

+ +

So I think really what I'm doing now and probably what I'll be doing forever with it is finding the right balance of those things and making sure to be respectful of all that's impacted by someone when we talk about just their relationship with food and their bodies. We're talking about their whole lives and really wanting to be able to go deeply with that and not keep it just on the surface.

+ +

VICTORIA: That makes sense and an interesting thing to try to measure and experiment out within an application, right?

+ +

DR. SMITH: Mm-hmm. So one aspect of the app, and probably the most meaningful one, is the courses. And there's another aspect of the app, which is a subscription. And so that's weekly lessons that are similar to the courses in that they're journaling, and a lesson, and mindfulness, and different components to them. But rather than being step by step by step like the courses, they are kind of on different topics each week. And so that's really been a space for me to experiment with some of that and to see what people are into and what really resonates with folks.

+ +

And also, of course, to use places like social media, I'll use Instagram, and I'll do a reel on this topic, and a reel on this topic, and see how that goes or a visual or whatever. And I think it's really been an interesting process within the app and also in the other places where I'm able to advertise for it, like on social media, just to see what's meaningful for people. So much of this process is finding your people and creating things that are meaningful for them, and I'm still learning how to do that.

+ +

VICTORIA: I think that's great. And I love to hear you're experimenting on a weekly basis for what content really resonates with people. I'm wondering, Jordyn, if you have any advice or tips for how to find your market, how to find your people.

+ +

JORDYN: Well, in this scenario, since you've got folks using the app already, it's great because you basically have leads, trails to follow, breadcrumbs to [laughs] chase down. So I don't know how many users you have already. And you don't have to tell us if you don't want to.

+ +

DR. SMITH: [laughs]

+ +

JORDYN: But I would basically look at the patterns of their usage and find those folks who are really using the app in the way you feel it is most useful and follow up with them. Who are they? Interview them if you can. But if you can find out things about them anyway, zero in on those folks as a specific niche and see if you can get as many people who look like them and can be defined in any way. It really depends on the characteristics of the folks themselves. And it could be geographic. It could be some component of their identity. It could be anything.

+ +

But basically, those folks who are really getting the most out of your app in the ways that you are sort of locating value for them really double down on those folks. Can you find more people like that? Can you find out more about how they're using the app? Why it's resonating. That's what I would be doing right now, and it's possible that's what you're doing. [laughs]

+ +

DR. SMITH: Well, I'm kind of curious about how to do that, you know, because anything you ask of people is one more thing. [laughs] And I think the truth for a lot of us is that we have a lot of things. And so I have a hesitancy in saying, "Well, do I send a survey that someone has to fill out? Do I try to take some of their time over the phone or ask for an email?" Because, of course, anything that takes time is something someone needs to put into their lives.

+ +

And as willing, as I think people are to be helpful, and certainly I'm very fortunate to be around just incredible people, there's a limit to that. You don't want to be asking for too much. And so I would be curious from your perspective, Jordyn, if you think there's a right way to do that, if there's a way that you think is kind of the right way or a way [laughs] to try to strike that balance.

+ +

JORDYN: Yeah, definitely. And that dynamic is something you've got to be sensitive to. People are busy, and you are asking them for something. But at this very early stage, that's kind of the beauty of this stage of the work is that it's an opportunity to really build with people, to invite them into the process so that they feel like they're co-creating something with you.

+ +

And that's why focusing on those users who appear to be getting the most out of the app is the best place to go because they're going to be the most likely to want...if they're getting something out of it, they probably are pretty excited about that. They're probably going to be excited to talk to you about it, et cetera. But that said, you should do something to compensate, and I don't mean that necessarily with money but compensate them for their time and their effort.

+ +

But in a mission-driven context like yours, it's really a great opportunity to kind of bring the community along with you. These folks are your first champions. You'll be surprised. In my experience, the people who are the most sort of impassioned about what you're doing and are benefiting from it the most are more than excited to help. And the channels how you make this ask just totally depends on the details of these folks and how they prefer to communicate.

+ +

So with regard to the question around a survey versus getting people to talk on the phone, it's a little bit of trial and error. Send out a survey, see if people respond. Putting a survey in the app is great, especially if it's just one question or two questions right after some key interaction. So maybe they've done today's lesson, or this week's lesson, or this week's activity, and right afterward, asking them one question about how they're finding the app.

+ +

And then, if they engage with that, then the follow-up can be, "Hey, thank you so much for giving me that feedback. If you're willing, I'd love to chat for 20 minutes with you about this. I really want to be creating this with my customers and my users. So no big deal if you don't have time; I get it. But it would be really valuable."

+ +

And you'll be surprised, I think, [laughs] how many people are more than excited because they really do feel it's a signal to them that you care deeply about their experience and that you really are trying to make that experience the best thing for them. It's sort of unintuitive. It feels like you're asking them to give you something, but what you're giving them is you're leaning in to co-creating with them.

+ +

DR. SMITH: Yeah. Jordyn, I love that. I think that's such a great idea. And from a mental health perspective, it's so authentic, too, because, of course, you want to offer people the opportunity to share about what they've learned and to be able to process it out loud. And you're right, that will be helpful to me, but it is also a service that's not dissimilar to what sometimes people come to therapy for, you know, is to just be able to process their experience out loud and be heard...and some of those things for themselves. So, Jordyn, I think that's such a great approach to that, and I really appreciate that. That's great.

+ +

JORDYN: Absolutely. And I would only add that it's another signal...who ends up responding positively to that is another signal for you on who your best collaborators are in the app. I mean, you can look at how they're using it to answer that question. But it's another signal to you like, oh, these are the folks who are really finding this useful. They're finding it so useful if they want to talk to me about it. And that will then additionally help you double down on those folks.

+ +

DR. SMITH: I'm curious for you, Jordyn, and I'm curious about how to reach a broader audience. So, certainly, I know people, and people who know me are much more comfortable reaching out to use the app or to be part of things because they know me and trust that it's going to be good. But expanding that to people that I don't know or that aren't, you know, through somebody, through a direct connection, that part is more challenging, of course. Because how would they know to trust me, especially when they've been around providers, as we were talking about, where sometimes that trust can be broken in some of these very vulnerable areas?

+ +

I've been experimenting with some things like creating an Instagram and things like that because I wanted to create a space for people to see what is this person all about? What is this messaging? But I'm curious if there are other ways that you would recommend to reach people who don't know me who would be then willing to take a chance on something like a course, which is often a kind of a high-ticket high-investment type of thing.

+ +

JORDYN: Well, there are myriad ways to do that, too, that come to mind, the kind that sort of define the ends of the spectrum. One of them is along the lines of what you're doing with Instagram, basically, advertise. Do a Google ad, do an ad on Instagram. You're going to capture a certain segment of people who are maybe not as focused on relationship-based referrals, who maybe are suffering in isolation, maybe they're not talking to anyone about this. So that's sort of one end.

+ +

But the other, I would say, is reaching out to fellow clinicians who you have a good relationship with and saying, "Hey, is this something you'd be willing to recommend to your patients or the folks that you work with? If not, why not?" Basically, activate your professional network in terms of adding this as another resource that they recommend to folks because then you're kind of multiplying that people you know effect, and that can be very powerful.

+ +

DR. SMITH: Yeah, it's such an interesting thing too because as you were talking, I started noticing, in my own mind, that little piece that we were talking about before of this kind of like, ah, well, I don't want to burden anyone. I don't want to give them one more thing to do. Then I thought, well, I love resources for my patients; that's only to the good. [laughs] I love having those things.

+ +

And so it was so interesting just to kind of observe that kind of process happening in real-time in my mind of this little bit of doubt that makes me go, oh, that makes me nervous, and then having to dig down to what you're actually telling me [laughs] because this is value-added.

+ +

JORDYN: 100%. And I'm glad that you noticed that and brought it up because I think this is especially for underrepresented founders, so women, people of color, so much self-doubt. And that hurdle is sometimes the biggest hurdle. And what I did, this is funny; this is fairly tactical.

+ +

DR. SMITH: [laughs]

+ +

JORDYN: When I was a founder, I made a document that was basically a reminder to myself. I would look at it before almost every call I had with anybody about what I was working on. But it was basically, hey, Jordyn, why are you doing this? [laughs] And it was like, why does this thing need to exist? Why am I the right person to be making it? Sort of a series of those things. And just to remind myself every time that what I was doing was valuable and that I'm not out there trying to get people to do something for me. I'm trying to get them to do something for themselves.

+ +

I'm taking a problem they're already trying to solve for themselves and just giving them another tool. That's it. And if they don't want to pick it up right now, that's fine. It might not be the right time. But reaching out to other practitioners and saying, "Hey, I have this tool. And the tool was developed out of a lot of the same things I'm imagining all of you are experiencing in your practices." A significant number of them are going to be like, "Oh great," just what you said, "Great, another tool. I can add this one. And maybe it won't be right for every one of my patients, but it might be right for some of them."

+ +

And just getting around that in your heart of, like, you're not asking them for something. You're giving them another resource. And in fact, not doing that sells yourself short, sells them short, frankly. You're not making this for you. This isn't merely about satisfying your own ego. I'm sure there's a little bit of that in there.

+ +

DR. SMITH: [laughs]

+ +

JORDYN: There always is. But for the most part, you're trying to help people, and by not telling them about what you're doing or offering it to them as a resource, it sort of defeats the purpose.

+ +

DR. SMITH: Yeah, it's such an important reframe. And like we were talking about before, it's one of those things that I think just needs to be on loop, [laughs] in the heads for founders. And probably some version of this on loop for all of us, you know, just as we're going through life kind of reminding ourselves my presence is not a burden. [laughs] It reminds me a little bit of what Sonya Renee Taylor kind of started with, "The Body is Not An Apology." And I think this is basically kind of going off of that topic. You know, I'm not a burden.

+ +

JORDYN: Absolutely. And I love that frame. You're doing this for a reason. You're not a burden. Your app that is out there helping people is not a burden; quite the opposite.

+ +

DR. SMITH: Right. It's amazing how [laughs] important that reminder is.

+ +

VICTORIA: Yeah, I love that. And, Jordyn, you also have our incubator program coming up soon for other founders. Do you want to mention that real quick?

+ +

JORDYN: Of course, I would love to. thoughtbot has a new incubator program launching this year. We have our first run of it starting in mid-March. Who this is for is non-technical founding teams. So you might be a solo person. You might have a team, but you haven't found that technical co-founder or partner yet, but your business idea involves building an app or building software of some kind. And basically, you're at the early stages. You haven't launched anything. You've identified the opportunity, maybe you've talked to a bunch of your potential users or customers, but you're not sure if there's a there there and what to do about it. That's the ideal sort of stage and persona.

+ +

And the program is really about helping those non-technical founding teams validate the market opportunity, do some experiments with product, basically build a couple of features, maybe a landing page that expresses the value proposition, et cetera, just to learn as much as they can about what the opportunity is and how they might need it with software. Get them used to working with a technical team and then help them with their planning for next steps, maybe that's raising capital, or maybe it is finding a technical co-founder. We can help with that. That's the idea. It's an eight-week program. Everybody who sees themselves in what I just said should apply. And the URL to apply is thoughtbot.com/incubator.

+ +

VICTORIA: Great. Thank you so much, Jordyn. And thank you for all your advice and your questions that you brought to the episode today. And, Stephanie, is there any final takeaways you'd like to leave our listeners with?

+ +

DR. SMITH: No, I just think this was such an excellent opportunity. I feel like I learned a lot from it. And I want to thank you both so much for taking the time. It's really been a pleasure.

+ +

VICTORIA: Wonderful. All right. Yes, thank you both so much for joining me today.

+ +

And for our listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Dr. Stephanie Smith and Jordyn Bonds.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dr. Stephanie Smith is Clinical Psychologist and Founder of the Finding Center app, the first intuitive eating classes app.

+ +

Victoria, along with surprise co-host thoughtbot's Director of Product Strategy, Jordyn Bonds talks to Dr. Stephanie about creating the Finding Center app to give people who are struggling with their bodies and their relationship with food a way to follow a plan, understand a path forward, and be able to see themselves getting healthier.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Dr. Stephanie Smith, Clinical Psychologist and Founder of the Finding Center app, the first intuitive eating classes app. Thank you for joining me.

+ +

DR. SMITH: Yeah, it's a pleasure to be here. It's nice to see you.

+ +

VICTORIA: Nice to see you too. And we also have Jordyn, our Director of Product Strategy at thoughtbot. Hi, Jordyn.

+ +

JORDYN: Hello.

+ +

VICTORIA: So let's just kick this off. And Dr. Smith, tell me a little bit more about your Finding Center app.

+ +

DR. SMITH: So I created the Finding Center app really a little bit selfishly because I wanted to create what didn't exist for me 10 or 15 years ago when I was really struggling with food and my body. And I'm very by the book, you know, tell me what to do, and I'll follow that. And there just wasn't something like that at that time of my life.

+ +

And so I created the Finding Center app to give people who are struggling with their bodies and their relationship with food a way to follow a plan, a way to understand a path forward, and to be able to see themselves getting through this, you know, getting to a healthier tomorrow. And that's what I really wanted for myself, and that's what I hope to build here.

+ +

VICTORIA: Well, I love that it came out of a personal issue you were having. And what was the gap between that type of content versus what already existed in the market?

+ +

DR. SMITH: Back at that time, you know, this is probably dating all of us here a little bit. But at that time, [chuckles] apps were a little bit newer; technology was, of course, you know, things are growing so quickly. And there were things like books, so you could read something on your own. Or you might be able to go see a therapist or a counselor, but they may not specialize in this kind of thing. And so there really was sort of this DIY, like piece things together, figure it out, try a book, try a workbook, maybe they'll go together, maybe they won't. Or go see a provider, and they may or may not specialize.

+ +

But there really wasn't something that was going to be a direct guide for these issues. And certainly, at that time, and still exists today, there's this huge lack of available things that are respectful to body diversity and size diversity. And so, really looking for something that wasn't going to be further stigmatizing, it was and still is an extremely huge challenge in this marketplace.

+ +

VICTORIA: Great. And tell me more about, you know, you've mentioned intuitive eating. And how is that different from a diet or from your regular food tracking apps?

+ +

DR. SMITH: That's such a great question. So intuitive eating is really the most old school [laughs] kind of style of eating because it's what we're all born doing. If you've spent any time around toddlers, you know that they'll have a couple of bites of a sandwich, a little bit of apple, half a cookie, and then they'll go run and play. Kids are natural intuitive eaters, and that starts to fade as we get older. And we start to have this morality around food and morality around body and this pressure to change and have things different. And we kind of lose that intuitive ability to have half a cookie and go play because I'm done right now, and maybe I'll come back to it, maybe I won't.

+ +

Intuitive eating really is about this recognition that that's what you were born with. That's what your birthright is, and you still have that. And it's really kind of pulling away these kinds of stigmas and biases that culture puts on top of our relationships with food and our relationships with our bodies. And when we can pull that back, there's this beautiful natural ability to eat what we want and to find a balanced way of nourishing ourselves. And that's really what intuitive eating is about is getting back to that.

+ +

VICTORIA: I love that. And how did you go about taking what seems like even though it's a basic, like, at its most [laughs] basic concept, but it's this very big, different way of conceptualizing food and boil that down into like an application? [laughs]

+ +

DR. SMITH: I have to be very clear here. I did not do this on my own. [chuckles] So intuitive eating has been around for a long time. It was started by a couple of dieticians, Evelyn Tribole and Elyse Resch. They've recently been in The New York Times recently and in other places. So it's becoming a little bit of a hot thing, which is great. But I had those resources.

+ +

So I've been following people who kind of are in this space. And they are one of those people who had a book and a workbook, so you weren't able to get that kind of personalized walk-through. But these resources have existed, and those are some of the resources that are the ones I mentioned, you know, that I started putting together when there wasn't something like this app that existed.

+ +

So it's really borrowing from them and then tying intuitive eating into body acceptance, and body liberation, and radical self-love, you know, tying intuitive eating in with these things, with our bodies because body shame and how we treat our bodies in terms of nourishment these are really integrated concepts. And I wanted to bring them together in a very intentional and overt kind of way.

+ +

VICTORIA: I think that's wonderful. And I'm curious, Jordyn, if you have any thoughts on if you were meeting with a founder who had just built this app, what would be your first questions you would ask?

+ +

JORDYN: Frankly, a lot of what I would ask is what you've already asked. But the sort of next thing I would focus on are questions around who are your users? How did you figure out who to bring this to first? How did you make that decision?

+ +

DR. SMITH: That's a great question. So when I was building this, you know, I think I mentioned that I was really building it from this place of what would I have needed at that time? And so I'm really looking for people who kind of think similarly, you know, who really want structure, who want multimedia kind of support. I wanted journaling activities, and I wanted education, and I wanted something to think about or some mindfulness. I really wanted a lot of things because I learn in a lot of different ways. So I'm looking for people who like to learn that way.

+ +

And I'm also the type of person that when I do something, I really want to do it. I want to dive in. I want to figure it out, you know, I really want to show up for it, and this is that kind of thing. And so it was pretty natural to think about the type of, you know, maybe personality who would be a great fit for this.

+ +

And then, in terms of who it's for, I really started with people I knew. So the first program that I ran through it was an intensive version of the app, which meant that there were weekend group meetings with everyone. And there was live Q&A and a place for us to ask questions and respond back to each other and share.

+ +

And I really started with people that I knew and friends of friends because a lot of people, you know, I think if we all think about our networks, a lot of people struggle in their relationships with food and in their relationships with body. And so the first place I started was with the people I already knew and saying, "Do you know anyone else who would be a good fit for this?" And it has kind of blossomed from there.

+ +

JORDYN: What's been one of the more unexpected things you've learned from your users as you've gotten more people into the app using it?

+ +

DR. SMITH: I think one of the things that isn't necessarily unexpected at all but is really striking to me in terms of how impactful it is is how much medical stigma impacts everyone and especially those who are in larger bodies, or bodies who are marginalized for other reasons because of their health status, or racial status, or age, or other factors like that.

+ +

As a health psychologist, I like to think of my work and my workplace as being somewhere that people can come and feel safe, and feel heard, and feel understood. And now I'm seeing, you know, I work in a doctor's office, yet my experience of being in a doctor's office is so different from other people's experiences and the stories that I heard from others about how they went in for some kind of pain and weren't even offered physical therapy, you know, were offered a diet instead of that. And those kinds of stories, how many of those I've heard, has been really striking and really surprising to me how impactful that has been and how much work we really need to do to improve the experience for patients.

+ +

JORDYN: Given that finding of the importance of safety, how has that idea informed how you've gone about designing and building the app?

+ +

DR. SMITH: Of course, with a project like this, you know, I think a lot of founders on here have shared kind of building the airplane while you fly it. [chuckles] And so I've gone and, of course, recorded a lesson or made a journal entry activity or something like that. And then I am going back, and I'm adding things to those. So I'm doing a re-recording or adding a piece, or adjusting the journal prompts or the mindfulness activity, really to make some very clear statements there around if you've heard this kind of thing, you're not alone.

+ +

If you have experienced this type of being shamed, let's really bring that out of the darkness. Let's bring it into the light because shame is something that lives in the dark. And so really wanting to help people excavate the parts of that shame that they are willing and comfortable and wanting to bring out into the light and creating a space for that has become really important for me.

+ +

It is making sure that we're able to talk about these things and say, "No, yeah, I think my provider is a great person. I do think they care about me. And at the same time, they're living in this weight bias and this stigma place too. And these are the recommendations they gave me. And that was a person that I thought would be safe." And so really trying to have those balanced discussions around why that might happen and giving people a place to talk about that.

+ +

VICTORIA: And one example I've seen in, I think, in your marketing materials is a measurement like the BMI or the Body Mass Index. And that's one that even myself I've experienced being used on me in a way where it's like, "Well, the index is saying you're overweight." And I'm like, "Well, clearly, I'm not. [laughter] Something is wrong with this measurement." And I can't even...you probably have a greater understanding of the harm that causes in communities.

+ +

DR. SMITH: Yeah, that's such a great point. I have looked at that myself. And I remember the very first time that someone said that, like, "Well, you're overweight. Have you considered losing weight?" And I was coming in...I think I was coming in to talk about something related to my period, something like that. And I thought, why are we talking about this? What is going on? [laughs] Where did this come from? I just wanted to talk about switching my birth control. And it just comes into every conversation.

+ +

And I think even someone like me, even someone who's in this space where I'm going, well, this is a bunch of crap; I think we all know at this point BMI is a bunch of crap. But even knowing that there's still this part of me that...and maybe you relate to this too of just, well, I do live in this culture. And you're saying these words about me like overweight. And my immediate thought, even though the one coming after that is frustration, my immediate thought is, oh no, what's wrong with my body? It's to be afraid. How am I going to be treated? Or does this mean something bad about my health?

+ +

And so even these metrics like BMI do a terrible job at acknowledging body diversity and actual health and all of those things. They're still scary still. And I think in a body acceptance space; it's really important for us to also acknowledge that even though we want to be body-accepting and be advocates for ourselves, it's still really normal when someone gives us that kind of information, especially someone in a position of power like a health care provider, that when someone is saying those kinds of things to us that it can still hurt. Even though we know, maybe intellectually, this is where that's coming from, that it doesn't need to hurt, it still does.

+ +

VICTORIA: And it can have financial implications as well if they're indicating that you're not "healthy" quote, unquote, because of a statistic like that that is meaningless. [laughs] But yeah, that can affect your insurance and all other kinds of things, so...

+ +

DR. SMITH: Yeah. And I think the financial piece that you're bringing up there is such a good point because there's so much power and control dynamics that can occur around finances. We really are limited by [laughs] what we can afford and not afford to do. And so people who are limited in terms of what they're able to pursue for their health will have to go along with lots of things that they may not believe in or may not want to follow up on because that's what their doctor is telling them is within their insurance to do. And that's a really hard thing.

+ +

VICTORIA: Sounds like the app gives patients or people the tools to be able to push back in some of those scenarios and also furthering body acceptance and an understanding of eating habits. What is the kind of immediate goals for your app? What does success look like in the next six months? And then maybe what does success look like five years from now?

+ +

DR. SMITH: When you started asking that question, I almost felt like a magician or a stage performer putting on 18 different hats all at once. [laughs] And I thought, from which of these should I respond to that question? [laughs] And so there's the health care provider inside of me going, well, as many people getting the support that they need, that's the benefit. So if one person gets it, that's great. I want anyone who can feel greater liberation to have that.

+ +

And then that hat pops off, and the marketer hat that I've been wearing kind of pops on and is like, well, these are the metrics in terms of growth and collaboration with other people in this space that I want to do. I want to collaborate with more people who are working here, and there are metrics around that that I want to pursue. And then the person inside of me that has to make money goes, okay, well, this many sales.

+ +

And so I think success is a really hard thing for me to pin down. But if I were to summarize, trying to kind of encapsulate all of those roles, it really just is having more people experience the app, having more people experience the education there, and being able to get that feedback to make it better. This is the first year of growth, and so there's going to be so much learning. I don't know yet what's going to be the next big thing that makes me go, oh my gosh, how did I not put that in there? And I'm just so excited to get to that point where I'm getting more of that feedback so that I can continue to make it better and better.

+ +

VICTORIA: I love that. And I think that it's a great place to be, [laughs] and you have an app that has a meaning for people. And then you also have other ways to measure your success. And, Jordyn, I'm wondering if you have any thoughts on an initial strategy to kind of meet some of the goals that Stephanie is laying out.

+ +

JORDYN: I was actually going to go backward in time first, if you don't mind, and ask, as a person with an application now out in the world who does not have a technical background, could you tell us the story of how you went from this idea to those first steps of making it happen in the world? What did you do? Where did you go?

+ +

DR. SMITH: [laughs] Yeah, so this is, on my end anyway, kind of a wild story though it may be typical for those of you who have been in this space. But so for me, I had this idea that I wanted to do to take the classes that I already do...because I already teach classes and I teach them live, and I love to do it. It's so much fun for me. But I wanted to take those and make them accessible for more people. And I wanted to make them in such a way where people could go at their own pace, you know, kind of follow through.

+ +

And so I've had this idea for, I want to say, something like five years, but I just wasn't finding the right platform. A lot of the online courses and things like that I do like them, but they didn't feel as flexible as I wanted them to be. For me, when I'm listening to an app and learning information, I want to be able to listen offline. I want to be able to watch it sometimes. I'm really looking for a lot of flexibility.

+ +

And I didn't even have the thought of an app, but that's what an app gives you, you know, it gives you this ability to be flexible, to be on the go, to kind of make your learning what you want it to be. And so I didn't really know what I was looking for, but I knew that I hadn't found it.

+ +

And then I saw this program that helps you build apps. I think I saw an ad for it on Instagram or on Facebook, you know, just one of those very random things. And I saw the ad, and I went, oh, that's kind of interesting. And I went on the platform, and they do this thing which I think makes a lot of sense. And they say, "Well, here's a 30-day free trial. Do our educational thing to learn how to build an app. And then, if it's not for you, cancel at the end of 30 days, no big deal." So I thought, all right, that sounds good.

+ +

And what I didn't realize that they were doing...I don't know if you've heard this metaphor before, but maybe it's this concept that if you want to take the island, you have to burn the boats. Basically, it's this general kind of showing up on this island with the army and saying, "Okay, well, if we want to take the island, the best way to get my troops to be able to do that is to make it so that there's no way to go back basically." And that is what this program did.

+ +

It wound up walking me through these steps that were actually slowly burning the boats because about halfway through that free trial month, they said, "Okay, now we're going to post something online about this. And we're actually going to post every day for a week." And I'm just following the steps and going, wait a second, now I have to do this because now I've said I'm going to.

+ +

And so it finally kind of got me out of this hemming and hawing, and I don't know what to do and very much launched me into this, okay, well, now this is happening kind of place. And so it was really interesting to see that happen to myself. [laughs] I could kind of see it happening a little bit. And yeah, that's how it happened.

+ +

JORDYN: That's great. I love how you made sense of the process as a person going through it. And burning the boats to take the island metaphor is one I've never heard before. But now I have to know what the platform was [laughter] because it sounds like they did a really good job of getting you to put something out there.

+ +

DR. SMITH: Yeah, they really did. The platform is called Passion.io. And they are actually a platform that I think targets health and wellness influencers which, as you know from talking with me or if you follow my things, you know sometimes I have some beef with some of the things that they might share. We might not have the same idea about how to go about those things. But Passion.io was the platform, and they have a ton of learning tools. They've got a lot of different resources on there for walking you through the initial stages of creating something.

+ +

And then they also walk you through a little bit more high-level things. And one of the pieces that I really like about it is that underneath all of this how-to is this bolstering. Because I think for a lot of people, certainly for myself, there's this thing, this imposter syndrome that we all have of, well, I'm not good enough, or no one's going to like it. Or what if I'm embarrassed? Just the many, many places of doubt that we have.

+ +

And underneath all of the how-to is really this space of you've got this. You've got a good idea. If you don't try, you'll never know. And so that's really the undercurrent of all of that. And I found that combination of this is what to do, and here's why it's meaningful to you, and here's why you are in the best place to do it, and that was really helpful.

+ +

JORDYN: Yeah, I really love that. That's a lot of my work with early-stage founders is that. It is constantly saying, "You've got this. This is your space. You know it better than most. Just because you don't know everything there is to know about starting a tech business doesn't mean you aren't qualified to engage with your customer. So like, "If not you, who? And if not now, when?" is always [laughs] kind of what I'm asking. And it sounds like this platform does a lot of that coaching.

+ +

DR. SMITH: Yeah. And, Jordyn, I just want to comment, too; I'm sure for you, if you do this a lot, you may get to points where you go; gosh, do I still need to be giving the same kind of reassurance? And I just want to say on the end of someone receiving that reassurance, yes, [laughs] we still need it. And so that work that you're able to do of just providing that consistent I'm here for you, and you are here for you, and we're going to do this. It's amazing to me how much I have needed that, and I still need that. And I just appreciate anyone who is out there doing that because it is really, really, really hard to be that vulnerable.

+ +

JORDYN: Oh, 100%. And this is hard-won for me. I've been a founder twice and a very early employee at other startups twice. And what's amazing about that particular journey is that just when you feel like you're getting your footing at one stage, the stage changes.

+ +

DR. SMITH: [laughs] Yes.

+ +

JORDYN: So, to your point, you never stop needing that bolstering and that sort of just the coaching and the cheering on because the situation you find yourself in is constantly shifting under your feet. So 100% agree.

+ +

DR. SMITH: Yes. [laughs] It sounds like you absolutely have the experience to be the person [laughs] to shepherd people through this, which, thank goodness, somebody's got to do it. [laughs]

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

JORDYN: I just feel like with a lot of things...and as a mental health professional, you're in a better place than many to understand this, but with any big undertaking like starting a business, really just anything, training for a marathon, you name it, some very significant percentage of the challenge is mental is yourself. It is getting yourself into the mindset where you can keep doing it. And I feel like a lot of folks just focus on the tactical stuff, here's how to do this, here's what to do, which is great. And you need those things.

+ +

At least half the battle is inside of us. It is emotional. It is mental. And any amount of being able to acknowledge that and grapple with those feelings as they arise is going to just make everybody that much more effective, which I feel like it's great when folks are working on apps where that's built into the mission like yours is because it's like, you can't lose sight of that. It's actually your life's work.

+ +

DR. SMITH: Yeah. And this is going to be such a psychologist comment, so forgive me for [laughs] it. But it's such an interesting thing that you're pointing out because what we're really talking about, from my perspective, is this place on the graph where vulnerability meets your highest ability to perform. And so I think for a lot of industries, not just mine, it's that crossroad where I'm at optimum vulnerability to really be able to connect.

+ +

Because when we're not vulnerable, if I keep myself too safe, then I'm not going to be able to position myself in a place to reach the most people or produce something that's going to be the most meaningful. And so I have to be willing to say, "This is going to be [laughs] really scary. This is going to really suck for me sometimes, and I'm going to get it wrong. And it's still worth it to do that because of this meaning that I'm wanting to do."

+ +

And I don't think all times in someone's life is the time [chuckles] to do that, you know, this happens to be the time for me, which is wonderful, and scary, and hard, and terrible, [laughs] and all of the rest. But it's, I think, just being conscious that there is a necessary amount of vulnerability to achieve the potential with something like this that you want to achieve and acknowledging I am just going to be sitting in a lot of hard, and that means I'm doing it right.

+ +

JORDYN: Absolutely. Yeah. And it's sort of without meeting a challenge we don't achieve. But to your point, it's that right mix of challenge and vulnerability. You don't want either of those things getting too out of balance. That is kind of the art of this journey, but 100% agree.

+ +

DR. SMITH: Yeah, I was thinking just earlier today about stress because this is stressful. It's so difficult to do. And I was talking to a friend the other day, and I was saying, "Yeah, you know, I've just been stressed with all of these things that I was doing." And this person said, "You know, well, if you tried blah, blah, blah thing, it will take the stress away." [laughs] A substance you could use to take the stress away. And I said, "You know, I haven't thought about that, and I guess I could."

+ +

But I thought in my mind how quickly we went from talking about the particular things that I was dealing with that were causing stress to trying to fix for stress and how much that's a part of our culture. And I thought, you know, the level of stress that I'm having is appropriate to the situation. I don't actually want to dull that level of stress because I need it in the same way that a car might benefit from a backup camera. When it starts to beep louder, [chuckles] I want to hear that because that's letting me know I'm heading for a crash, and I want to be conscious of that.

+ +

So certainly, as a mental health provider, I think that's one of the things that's helping me move through. It's just that sensitivity to there's a certain level of stress and a certain utility to stress. That's important when you're building something because you're also needing to maintain yourself as a person, and you've got to monitor that pretty closely.

+ +

JORDYN: You're still in private practice.

+ +

DR. SMITH: Yeah. Yeah.

+ +

JORDYN: It sounds like you've got, and I think you alluded to this earlier, a lot of hats that you're wearing.

+ +

DR. SMITH: [laughs] Yes.

+ +

JORDYN: How has it gone balancing the launch of this app with the rest of the work that you're doing?

+ +

DR. SMITH: [sighs] Well, it's been a lot. So I am a private practice psychologist. I also have a nine-to-five. I work in a hospital as a health psychologist, and, you know, building the app and doing all of those things. And I think the biggest thing that's been important for me to be able to remind myself again, and again, and again, and again is just if it stops being what I want to do, even just in a moment, don't do it; do the next thing.

+ +

Because for me in this space, as much as I might say, you know, I've burned the boats...and that is motivating for me to get through particular things. I also have to recognize that just like my body will tell me what I need with food, my body is going to let me know when I've had too much for the day or when I've been doing too much of one thing. And I need to go for a walk, or I need to just go the heck to sleep, or I need to do whatever. I need to do a different project, toss the marketing down and take a look at some of the patient notes or whatever.

+ +

For me, because I love all of what I do, everything is important to me. I think I get something from all of that, and that is important to me too. You know, not every day is roses. There are days where I just want to say, screw all of it. I'm moving to Tahiti or whatever, whatever the fantasy is. But honestly, when it comes down to it, I do it because I love it. These things are meaningful to me, and being able to share in the world in all of the myriad ways that I do that I get a lot of meaning from that.

+ +

And I would start to become concerned about that for myself if I stopped getting something back. And I think this is basically how we feel in anything that we invest in, whether I'm investing time or love, or money, or whatever we invest because we also get back, and when that stops happening, that's the time when I reevaluate. And so far, that hasn't happened yet. So far, I've been able to pivot and stay conscious of where I'm at and switch from one thing that I love to something else that I love. And then I find when I do that; I do always want to go back.

+ +

VICTORIA: That's the benefit of wearing multiple hats, right? You can pick one up and put on a different one if you're matching your energy levels.

+ +

DR. SMITH: Yeah. They say...one of the quotes that I've always related to for better or for [laughs] worse is if you want something done, give it to someone who's busy, and I think that's true for me. I'm one of those people where I like a level of busy. I thrive on that; I enjoy it. And it's just staying conscious of the balance.

+ +

VICTORIA: And I think that's great. And we talk to founders about that a lot, actually, about how to balance their time. And it's interesting to hear from a psychologist's perspective.

+ +

DR. SMITH: Yeah, it's been an interesting thing going through this as a psychologist because when I do say things like, "Well, yeah, I've been stressed," People say, "What? But you're a psychologist. You're not supposed to feel stress." And I always think this is hilarious because I go, "What the heck do you think psychologists [laughs] are?" Stress is a normal part of life. I'm going to be stressed and ticked off, and irritable, and all of the things just like everyone else.

+ +

I am very fortunate to have additional skills for how to manage it when those feelings come up, which I'm extremely, extremely grateful for. But being stressed, or upset, or sad, or any of the range of unpleasant but completely normal human emotions, we all feel those [laughs] too. Those are just as natural for us.

+ +

VICTORIA: Like, I never thought the goal of psychology was to never be stressed.

+ +

[laughter]

+ +

DR. SMITH: Right. Yeah, it's just to become increasingly better able to manage it.

+ +

VICTORIA: That makes sense. With your approach to your app, are there experiments that you're designing in the app to see what your clients relate to more, or how are you building that?

+ +

DR. SMITH: Yeah, absolutely. So one of the things that I am kind of balancing right now is that there's this space with intuitive eating. It really covers nourishing yourself, and a lot of that is around food. But our relationships with how we nourish ourselves and how we relate to our bodies also impacts how we move our bodies or not, how we are intimate with our bodies or not, how we are in much, much broader spaces in the world.

+ +

There's a quote that says something like, "It's not about food, but food is sort of the stage where we enact what we're going through," kind of where we enact the deeper things going on for us. And so for me, really, what I'm experimenting with and balancing is how much do we want to focus completely on foodstuff? And how much do we also want to recognize that food is going to also dovetail into movement, and also dovetail into mental health, and also dovetail into how you manage stress at the end of the day, and also dovetail into the intimacy that you have in relationships, and the pleasure that you allow yourself or not, or that you think that you deserve?

+ +

So I think really what I'm doing now and probably what I'll be doing forever with it is finding the right balance of those things and making sure to be respectful of all that's impacted by someone when we talk about just their relationship with food and their bodies. We're talking about their whole lives and really wanting to be able to go deeply with that and not keep it just on the surface.

+ +

VICTORIA: That makes sense and an interesting thing to try to measure and experiment out within an application, right?

+ +

DR. SMITH: Mm-hmm. So one aspect of the app, and probably the most meaningful one, is the courses. And there's another aspect of the app, which is a subscription. And so that's weekly lessons that are similar to the courses in that they're journaling, and a lesson, and mindfulness, and different components to them. But rather than being step by step by step like the courses, they are kind of on different topics each week. And so that's really been a space for me to experiment with some of that and to see what people are into and what really resonates with folks.

+ +

And also, of course, to use places like social media, I'll use Instagram, and I'll do a reel on this topic, and a reel on this topic, and see how that goes or a visual or whatever. And I think it's really been an interesting process within the app and also in the other places where I'm able to advertise for it, like on social media, just to see what's meaningful for people. So much of this process is finding your people and creating things that are meaningful for them, and I'm still learning how to do that.

+ +

VICTORIA: I think that's great. And I love to hear you're experimenting on a weekly basis for what content really resonates with people. I'm wondering, Jordyn, if you have any advice or tips for how to find your market, how to find your people.

+ +

JORDYN: Well, in this scenario, since you've got folks using the app already, it's great because you basically have leads, trails to follow, breadcrumbs to [laughs] chase down. So I don't know how many users you have already. And you don't have to tell us if you don't want to.

+ +

DR. SMITH: [laughs]

+ +

JORDYN: But I would basically look at the patterns of their usage and find those folks who are really using the app in the way you feel it is most useful and follow up with them. Who are they? Interview them if you can. But if you can find out things about them anyway, zero in on those folks as a specific niche and see if you can get as many people who look like them and can be defined in any way. It really depends on the characteristics of the folks themselves. And it could be geographic. It could be some component of their identity. It could be anything.

+ +

But basically, those folks who are really getting the most out of your app in the ways that you are sort of locating value for them really double down on those folks. Can you find more people like that? Can you find out more about how they're using the app? Why it's resonating. That's what I would be doing right now, and it's possible that's what you're doing. [laughs]

+ +

DR. SMITH: Well, I'm kind of curious about how to do that, you know, because anything you ask of people is one more thing. [laughs] And I think the truth for a lot of us is that we have a lot of things. And so I have a hesitancy in saying, "Well, do I send a survey that someone has to fill out? Do I try to take some of their time over the phone or ask for an email?" Because, of course, anything that takes time is something someone needs to put into their lives.

+ +

And as willing, as I think people are to be helpful, and certainly I'm very fortunate to be around just incredible people, there's a limit to that. You don't want to be asking for too much. And so I would be curious from your perspective, Jordyn, if you think there's a right way to do that, if there's a way that you think is kind of the right way or a way [laughs] to try to strike that balance.

+ +

JORDYN: Yeah, definitely. And that dynamic is something you've got to be sensitive to. People are busy, and you are asking them for something. But at this very early stage, that's kind of the beauty of this stage of the work is that it's an opportunity to really build with people, to invite them into the process so that they feel like they're co-creating something with you.

+ +

And that's why focusing on those users who appear to be getting the most out of the app is the best place to go because they're going to be the most likely to want...if they're getting something out of it, they probably are pretty excited about that. They're probably going to be excited to talk to you about it, et cetera. But that said, you should do something to compensate, and I don't mean that necessarily with money but compensate them for their time and their effort.

+ +

But in a mission-driven context like yours, it's really a great opportunity to kind of bring the community along with you. These folks are your first champions. You'll be surprised. In my experience, the people who are the most sort of impassioned about what you're doing and are benefiting from it the most are more than excited to help. And the channels how you make this ask just totally depends on the details of these folks and how they prefer to communicate.

+ +

So with regard to the question around a survey versus getting people to talk on the phone, it's a little bit of trial and error. Send out a survey, see if people respond. Putting a survey in the app is great, especially if it's just one question or two questions right after some key interaction. So maybe they've done today's lesson, or this week's lesson, or this week's activity, and right afterward, asking them one question about how they're finding the app.

+ +

And then, if they engage with that, then the follow-up can be, "Hey, thank you so much for giving me that feedback. If you're willing, I'd love to chat for 20 minutes with you about this. I really want to be creating this with my customers and my users. So no big deal if you don't have time; I get it. But it would be really valuable."

+ +

And you'll be surprised, I think, [laughs] how many people are more than excited because they really do feel it's a signal to them that you care deeply about their experience and that you really are trying to make that experience the best thing for them. It's sort of unintuitive. It feels like you're asking them to give you something, but what you're giving them is you're leaning in to co-creating with them.

+ +

DR. SMITH: Yeah. Jordyn, I love that. I think that's such a great idea. And from a mental health perspective, it's so authentic, too, because, of course, you want to offer people the opportunity to share about what they've learned and to be able to process it out loud. And you're right, that will be helpful to me, but it is also a service that's not dissimilar to what sometimes people come to therapy for, you know, is to just be able to process their experience out loud and be heard...and some of those things for themselves. So, Jordyn, I think that's such a great approach to that, and I really appreciate that. That's great.

+ +

JORDYN: Absolutely. And I would only add that it's another signal...who ends up responding positively to that is another signal for you on who your best collaborators are in the app. I mean, you can look at how they're using it to answer that question. But it's another signal to you like, oh, these are the folks who are really finding this useful. They're finding it so useful if they want to talk to me about it. And that will then additionally help you double down on those folks.

+ +

DR. SMITH: I'm curious for you, Jordyn, and I'm curious about how to reach a broader audience. So, certainly, I know people, and people who know me are much more comfortable reaching out to use the app or to be part of things because they know me and trust that it's going to be good. But expanding that to people that I don't know or that aren't, you know, through somebody, through a direct connection, that part is more challenging, of course. Because how would they know to trust me, especially when they've been around providers, as we were talking about, where sometimes that trust can be broken in some of these very vulnerable areas?

+ +

I've been experimenting with some things like creating an Instagram and things like that because I wanted to create a space for people to see what is this person all about? What is this messaging? But I'm curious if there are other ways that you would recommend to reach people who don't know me who would be then willing to take a chance on something like a course, which is often a kind of a high-ticket high-investment type of thing.

+ +

JORDYN: Well, there are myriad ways to do that, too, that come to mind, the kind that sort of define the ends of the spectrum. One of them is along the lines of what you're doing with Instagram, basically, advertise. Do a Google ad, do an ad on Instagram. You're going to capture a certain segment of people who are maybe not as focused on relationship-based referrals, who maybe are suffering in isolation, maybe they're not talking to anyone about this. So that's sort of one end.

+ +

But the other, I would say, is reaching out to fellow clinicians who you have a good relationship with and saying, "Hey, is this something you'd be willing to recommend to your patients or the folks that you work with? If not, why not?" Basically, activate your professional network in terms of adding this as another resource that they recommend to folks because then you're kind of multiplying that people you know effect, and that can be very powerful.

+ +

DR. SMITH: Yeah, it's such an interesting thing too because as you were talking, I started noticing, in my own mind, that little piece that we were talking about before of this kind of like, ah, well, I don't want to burden anyone. I don't want to give them one more thing to do. Then I thought, well, I love resources for my patients; that's only to the good. [laughs] I love having those things.

+ +

And so it was so interesting just to kind of observe that kind of process happening in real-time in my mind of this little bit of doubt that makes me go, oh, that makes me nervous, and then having to dig down to what you're actually telling me [laughs] because this is value-added.

+ +

JORDYN: 100%. And I'm glad that you noticed that and brought it up because I think this is especially for underrepresented founders, so women, people of color, so much self-doubt. And that hurdle is sometimes the biggest hurdle. And what I did, this is funny; this is fairly tactical.

+ +

DR. SMITH: [laughs]

+ +

JORDYN: When I was a founder, I made a document that was basically a reminder to myself. I would look at it before almost every call I had with anybody about what I was working on. But it was basically, hey, Jordyn, why are you doing this? [laughs] And it was like, why does this thing need to exist? Why am I the right person to be making it? Sort of a series of those things. And just to remind myself every time that what I was doing was valuable and that I'm not out there trying to get people to do something for me. I'm trying to get them to do something for themselves.

+ +

I'm taking a problem they're already trying to solve for themselves and just giving them another tool. That's it. And if they don't want to pick it up right now, that's fine. It might not be the right time. But reaching out to other practitioners and saying, "Hey, I have this tool. And the tool was developed out of a lot of the same things I'm imagining all of you are experiencing in your practices." A significant number of them are going to be like, "Oh great," just what you said, "Great, another tool. I can add this one. And maybe it won't be right for every one of my patients, but it might be right for some of them."

+ +

And just getting around that in your heart of, like, you're not asking them for something. You're giving them another resource. And in fact, not doing that sells yourself short, sells them short, frankly. You're not making this for you. This isn't merely about satisfying your own ego. I'm sure there's a little bit of that in there.

+ +

DR. SMITH: [laughs]

+ +

JORDYN: There always is. But for the most part, you're trying to help people, and by not telling them about what you're doing or offering it to them as a resource, it sort of defeats the purpose.

+ +

DR. SMITH: Yeah, it's such an important reframe. And like we were talking about before, it's one of those things that I think just needs to be on loop, [laughs] in the heads for founders. And probably some version of this on loop for all of us, you know, just as we're going through life kind of reminding ourselves my presence is not a burden. [laughs] It reminds me a little bit of what Sonya Renee Taylor kind of started with, "The Body is Not An Apology." And I think this is basically kind of going off of that topic. You know, I'm not a burden.

+ +

JORDYN: Absolutely. And I love that frame. You're doing this for a reason. You're not a burden. Your app that is out there helping people is not a burden; quite the opposite.

+ +

DR. SMITH: Right. It's amazing how [laughs] important that reminder is.

+ +

VICTORIA: Yeah, I love that. And, Jordyn, you also have our incubator program coming up soon for other founders. Do you want to mention that real quick?

+ +

JORDYN: Of course, I would love to. thoughtbot has a new incubator program launching this year. We have our first run of it starting in mid-March. Who this is for is non-technical founding teams. So you might be a solo person. You might have a team, but you haven't found that technical co-founder or partner yet, but your business idea involves building an app or building software of some kind. And basically, you're at the early stages. You haven't launched anything. You've identified the opportunity, maybe you've talked to a bunch of your potential users or customers, but you're not sure if there's a there there and what to do about it. That's the ideal sort of stage and persona.

+ +

And the program is really about helping those non-technical founding teams validate the market opportunity, do some experiments with product, basically build a couple of features, maybe a landing page that expresses the value proposition, et cetera, just to learn as much as they can about what the opportunity is and how they might need it with software. Get them used to working with a technical team and then help them with their planning for next steps, maybe that's raising capital, or maybe it is finding a technical co-founder. We can help with that. That's the idea. It's an eight-week program. Everybody who sees themselves in what I just said should apply. And the URL to apply is thoughtbot.com/incubator.

+ +

VICTORIA: Great. Thank you so much, Jordyn. And thank you for all your advice and your questions that you brought to the episode today. And, Stephanie, is there any final takeaways you'd like to leave our listeners with?

+ +

DR. SMITH: No, I just think this was such an excellent opportunity. I feel like I learned a lot from it. And I want to thank you both so much for taking the time. It's really been a pleasure.

+ +

VICTORIA: Wonderful. All right. Yes, thank you both so much for joining me today.

+ +

And for our listeners, you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Dr. Stephanie Smith and Jordyn Bonds.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+eeZ2faRD + + ]]> + + Victoria Guido + Jordyn Bonds + Dr. Stephanie Smith + + + 465: Playroom with Michele Veldsman + https://podcast.thoughtbot.com/465 + 65d73218-4f57-46d4-a274-c5cf73ed823b + Thu, 09 Mar 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Michele Veldsman is Director of Neuroscience R&D at Cambridge Cognition and Founder and CEO of Playroom, an invitation-only secure social network for families. + +Victoria talks to Michele about the premise of Playroom and its goal of giving parents a network, a safe social community where parents are able to know and easily communicate with people associated with their children and also provide specific options to maintain boundaries when it comes to their privacy and safety, the challenges families face in raising kids and maintaining a career, and new features she wants the app to include, such as finding nearby restrooms while out and about. + 30:53 + no + + + Michele Veldsman is Director of Neuroscience R&D at Cambridge Cognition and Founder and CEO of Playroom, an invitation-only secure social network for families. +Victoria talks to Michele about the premise of Playroom and its goal of giving parents a network, a safe social community where parents are able to know and easily communicate with people associated with their children and also provide specific options to maintain boundaries when it comes to their privacy and safety, the challenges families face in raising kids and maintaining a career, and new features she wants the app to include, such as finding nearby restrooms while out and about. +Playroom (https://www.playroom-app.com/) +Follow Playroom on LinkedIn (https://www.linkedin.com/company/playroom-app/) or Twitter (https://twitter.com/playroom_app). +Follow Michele Veldsman on LinkedIn (https://www.linkedin.com/in/micheleveldsman/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Michele Veldsman, Director of Neuroscience R&D at Cambridge Cognition and Founder and CEO of playroom, an invitation-only secure social network for your family. Michele, thank you for joining me. +MICHELE: Thank you for having me. +VICTORIA: Tell me a little bit about your journey. How did all of this get started? +MICHELE: I had some kids, and I realized quite quickly that raising children is really difficult. I don't have family close by to support me. They are a couple of hours away. But trying to manage being a professional working in a fairly intense job, looking after my kids, making sure they have everything that they need and that they can socialize, and that I have a support network around me turned out to be really difficult. And so I wanted to find a way to solve that essentially. +VICTORIA: Right. So you identified a problem from your own life in trying to manage your career, and you're raising your children without that close, immediate support. +MICHELE: Yeah, exactly, yeah. And I realized this is a problem for a lot of people that increasingly, we don't live in these sort of small communities where we're surrounded by friends and family. Increasingly, people are moving to different cities, different countries. And that support network isn't there, but there are still all of the challenges of raising kids and trying to have a career at the same time. +VICTORIA: Right. And like we were talking before we recorded, I just got back from visiting my family in Virginia, and I live in California now. So I'm familiar with some of the challenges my brother and sister-in-law are facing with childcare. Can you tell us some of the things that specifically you found really difficult in this situation? +MICHELE: A lot of the time in my working life, I found there were loads and loads of tech to kind of try and make things easier to organize things. There's just a lot out there just for my working life but not much to support my family life, of which there are actually many, many more challenges because I'm kind of trying to juggle. I'm making sure that my kids their healthcare is all right, that they're getting their vaccinations on time, that I'm applying to school places on time, that I'm making sure that they're meeting other kids their age, and they're having play dates, and organizing birthday parties, all of those things. +And then to try and fit that all into the wider day-to-day life, I found this really difficult. I spoke to other parents, and they also found it really difficult. In fact, I did some research with over 120 parents, and 70% of them found parenting really difficult or extremely difficult. +VICTORIA: That's a lot of cognitive load on a person to manage all of these different things like school, and medical, and all the things you need to buy, [laughs] and what brands are the best. +MICHELE: [laughs] Yeah, exactly. And actually, just trying to build this community around yourself is more difficult than you anticipate. So, for example, my kids went to nursery. And this is the time that they're starting to socialize and making these important connections that are really important to their development. And so as a parent, you're hearing from your three-year-old, oh, they've got this new best friend, but you have no idea how to connect to the parents of that child. And the nurseries daycare can't give out that information because, of course, there are privacy issues. +So it's really difficult to make connections to other parents to be able to do these things like play dates. Organizing a birthday party, I found what you have to do is just take an invitation, give it to the nursery or the daycare center. Hopefully, they put it in the bags of the children that are friends with your kids, and then you kind of hope that they've got it and the right people are coming. You don't know who's coming to your kid's birthday party. And this just all seemed like there could be easy solutions to solve this to really build communities that center around your children. +VICTORIA: And I love that the purpose of playroom is to really build that community of social support that you need for parents. You mentioned you started to do some research on what that would look like. And I'm wondering if there was anything that surprised you as a result of that research. +MICHELE: Yes, I was quite surprised by...I suppose in some ways, it's reassuring actually as well that a lot of parents are going through similar struggles, struggling to connect to other families and not sort of in that way of, like, as you're...it's kind of a strange thing when you have kids because when they're very young, you can still socialize with your friends and people that you meet, maybe work colleagues. +But as they get older, the focus becomes a little more around them and their friends, so making those connections are a little bit more difficult. So a lot of people struggle with that. A lot of people struggled with just keeping on top of everything. As you're saying, that cognitive load is very large; just trying to remember organizing dentist appointments, doctor's appointments, all of those things. It's a large cognitive load. And we've got enough tech now that we shouldn't have to...we should be able to put that load on to technology that can support us. +VICTORIA: And so you feel like it was reassuring almost that this was a common problem [laughs], and it wasn't just you. +MICHELE: Yeah, it's reassuring. It's always reassuring when you connect with other people to realize that they're going through similar things. It's not just you that's, you know, somehow not able to manage it all. +But the other thing I found interesting is that there's a very large spectrum of how people feel about images and media associated with their children. So you've got a really wide spectrum of people who...some parents are very happy to share a lot about their children's lives, and their photos, and things that they're proud of on the major social media platforms. +And other parents are a lot more guarded, and they don't want to share those pictures or have other people share them on platforms. So there's a massive spectrum of how people feel about the use of images and media associated with their children and also related to that of data associated with their children. +VICTORIA: Yes, and I wanted to ask you about how privacy played into your planning on how you built the application. +MICHELE: This was important to me because I had both that experience, and also, I started to become more aware of the darker sides of the major platforms where there's perhaps not as much protection for children and that, of course, children can't consent. So I found...having spoken to all of these parents, the spectrum was very wide on what people were willing to share, and how much they knew about how their data was used, and how much privacy they had on these platforms. I really wanted to ensure that that spectrum was reflected. +In playroom, within the app, it's built so that you have control over how much privacy, how openly your images, for example, of your child, can be shared. So it can be from having any images to be shared with anybody. You know, maybe we're at a birthday party, and there are a lot of children there. So there are lots of pictures where your child is in there; some people are very happy for those to be shared. Others are not wanting that shared anywhere. +So within the app, you have control over how far those sorts of pictures can be shared and with whom. But the premise of playroom is that you're essentially in a network, a community where you know everybody associated with your children. So it's not that sort of massively open network. It's very much closed and associated with just the people you know are surrounding your children. +VICTORIA: That's great, and it's very relevant for me. I just got a new camera, and I offered to take pictures for my niece's birthday party last weekend. And now I have all these photos that, I'm not sure how to share them with the parents and in a way that would be secure and provide those options. So I can understand the value of what you've built here. +MICHELE: Within playroom, there are bubbles. So if your child, for example, goes to nursery or daycare, they usually are in a room with children of a similar age, a playroom, that forms a bubble. So the nursery gives you a secure code that connects you to the other parents in that playroom. So that forms this bubble of parents associated with your children. +So if you're taking photos at an event, so let's say you have a birthday party, you take photos. There are lots of other children in those photos. You can share those photos with the people in that bubble and in that bubble alone. And then, you can set your own personal media sharing settings so that you can make it clear to other parents that I don't want you to share this to wider social media. Watermark everything, very strongly watermarked or not downloadable. Or I'm happy for you to share it within playroom itself with other people that I know. So those settings are sort of adjustable depending on your preferences. +VICTORIA: Were there any obstacles that you faced from maybe a technology or a process perspective with implementing or building the app? +MICHELE: Yeah, so there are a couple of challenges. The biggest one is data and privacy. So, of course, security is a huge priority. That's going to be the center of priorities, really, so that everything is very, very secure. Parents, of course, are conscious of security surrounding their children. To be honest, as I was saying before, with sharing of media, it's quite on the spectrum, but either way, the priority is security and then privacy. +So the use of data is an interesting one because a lot of traditional social networks, social media rely on the monetization of data. And again, this works on a spectrum where some parents flat out don't want any data associated with their children used or monetized in any way. Others are a lot more liberal about that. +My personal view and from having spoken to a lot of parents, I think there's a good middle ground in which data is used in a responsible way for the purposes of actually benefiting parents in some way. So maybe it's the use of data rather than constant targeted ads, the use of data for the provision of services. Maybe within an area, you've got a high proportion of children there, and there needs to be better childcare provisions or play activity provisions. +VICTORIA: That makes sense. So make the data more relevant in the way that it's used to provide better services to parents, right? +MICHELE: Exactly, yeah, rather than that strict sort of targeted advertising. +VICTORIA: That makes sense. And so you've had to adjust your plan for monetization based on the needs of your users regarding privacy and security, and we love to hear that founders really care about privacy and security at thoughtbot, so... +MICHELE: Yes, exactly. Yeah, I think it's really, really important, and even more so now. There's really this acknowledgment of the very large open networks that they were never really built around children, of course. I mean, why would they be? But there's been a lot of controversy recently over parents having images and their children featured in videos and things online. The child accounts run by parents have millions of followers and videos, images, and things get saved thousands of times and commented in ways that are a little uncomfortable. +So there is this sort of growing feeling that these large open networks...mostly parents just don't really know. And they do...when you become a parent, you're really excited, and you're proud, and you want to share these things with the world. And you perhaps don't think about those kinds of darker sides of things. That's really coming into the forefront now. So I think a sort of more closed community-based network is important. +VICTORIA: I agree. I've spent some time volunteering for organizations that work with children and privacy and human trafficking situations. And when you start to understand really how dark it can get for children, maybe too dark for this podcast, but security and privacy becomes the penultimate goal. +MID-ROLL AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. That's tbot.io/incubator. +VICTORIA: You mentioned learning all of this as part of your journey on building the app. I'm curious what you brought from your background in neuroscience into the creation of the app and maybe how that played into how you built certain behaviors and things into the features. +MICHELE: Yeah, it's kind of interesting. So my neuroscience background, I guess, has really informed how I think about child development and brain development and the importance of the developmental stages of socializing with children. It was always at the front of my mind, and one of the things that really spurred me on to create this is really knowing that as children are developing, they are learning these really important social skills, and I just wanted to foster that as much as possible. And I thought, you know, it's actually really difficult to foster that social side of things if you don't have a community naturally around you. +So I guess that's the main way that it's fed into my thinking about playroom. Other than that, I'm not too sure, actually. I think it's early stages, but I think it will probably influence some of the UX decisions, which is a big part of what I do in my day job, not the UX itself but the kind of psychology and neuroscience behind certain behaviors and how we interact with technology. +VICTORIA: I love to see founders and people who find their way into technology roles that usually come from a wide variety of backgrounds. And for me, neuroscience makes a lot of sense when you're doing these studies. Because you really are even, you know, from a scientific perspective, setting up a study and experiment to see how people will react to it. And you're proving your theory of is this how people will actually relate and connect inside the application? +MICHELE: Yes, absolutely, yeah. A lot of my job is data science. So I'm really excited to just get data in that I can really make decisions based on. I'm very much a kind of evidence-based person from my science background definitely. +VICTORIA: Yes, excellent. And maybe you could tell me more about a decision you had to make maybe early on in the development of the app that was challenging for you or you had to put a lot of time and thought into. +MICHELE: One of the things I found tricky, I suppose, is kind of being a solo founder, actually. Early on, I spent a lot of time trying to find a co-founder, and I really wanted somebody like a technical co-founder that could kind of fill the gap that I have. I don't have any formal experience in app development or anything like that, although a lot of my job involves coding and the data science side of things. +Yeah, I spent a lot of time trying to find a technical co-founder and just really struggled to find somebody that had interest, and passion, and vision that would work for playroom. And so, after a while and after speaking to a couple of mentors, I decided to save that energy of trying to find somebody and just go at it alone for now. So, you know, open to finding somebody who has a similar vision for it, but yeah, that was really a difficult thing; it always is being a solo founder. But I just am really passionate about it and kind of filled the gaps with mentors and with advisors who can help me along the way. +VICTORIA: That's so interesting. I think deciding about who you're going to bring into your inner circle when you're passionate about an idea sounds like a very difficult decision. +MICHELE: Yeah, it is, yeah, and it's a strange sort of space as well because by no means does it need somebody who has children or has an interest there. But I think it does help with the passion because it's a really specific problem. And yeah, I just haven't found anyone yet. +VICTORIA: But you have found several mentors. That sounds like it's meeting your needs in that way for now. How did you go about finding the right people to give you advice in that way? +MICHELE: A combination really of just kind of stalking through LinkedIn and connecting to people, and just chatting to people, and then also through networks of other founders, and going through accelerators, things like that where I'm kind of formally introduced to mentors. They've maybe given me warm introductions, amazing women's network where people have either given warm introductions or volunteered themselves to give advice. That's been really, really great. You sort of feel like you've got a community there already. +VICTORIA: That's great. And did you focus on local groups in the UK, or did you go just online virtual groups? Which was easier for you? +MICHELE: A combination. So I went through an accelerator that was based in London, and so that introduced me to a few people more locally and quite a wide network, actually. I also joined a women of color network called Founderland, and they're based in Berlin. And they are a really amazing support network that has quite a wide international reach but really gives you a lot of support and guidance and is completely free and just really feels like a nice, supportive community. +VICTORIA: Sounds like building a community of founders is as important as building a community for people raising children, right? [laughs] +MICHELE: Yeah, definitely. [laughs] Yeah, I think so. I think any aspect of your life that is difficult benefits from a community really because, in almost all areas, there are people who have gone through something before that want to make it easy for you or who are going through something at the same time and want somebody to talk to or to support each other. +VICTORIA: The most important thing we can be doing is building community. You have your full-time position, and then you also have your children that you're raising, and you are founding this company. How do you make time for yourself and for your own peace of mind in the week? +[laughter] +MICHELE: With great difficulty, yeah, [laughter] and a very supportive partner. It's a real struggle, and things sometimes have to be slower than I would like. I've got an amazing team of app developers who are absolutely brilliant and are usually chasing me rather than me chasing them, which is always really great. Again, a fantastic support network, a big community of other parent founders who know how difficult it all is. And then it's just like a lot of working evenings, taking a day off to focus on things. +VICTORIA: Yes, we're learning a technique at thoughtbot with energy coaching and coaching people on when to take breaks and how to make sure you have time for lunch and take vacations, and all of that, which I think is important for your long-term ability to maintain your momentum. +MICHELE: Yes, definitely. +VICTORIA: But I've heard from many founders, you know, the support network is one of the most important things to be able to balance everything. +MICHELE: Yes, it really is, yeah. I am susceptible to burnout, and I know it now. And I should know better because I know the kind of neuroscience of it as well. And so I do have to be really careful. I don't push myself too much. One of the good things actually, you know, my kids are school age now. So they have these half-term breaks. They have regular breaks from school, and then summer holidays, of course, Christmas, all of that, and that sort of forces a time for you to break and then spend really quality time with the kids. So it's really, really good in that way. +VICTORIA: I appreciate kind of enforced time off. [laughs] +MICHELE: Yeah, I know. [laughs] +VICTORIA: And really committing to it. It makes sense, yeah. [laughter] +MICHELE: I just realized that. +VICTORIA: UK people are better at that than I think in the U.S. generally, but it's certainly something I strive for. Sometimes even just going to a place where there's no internet access, [laughs] so good luck trying to reach me. +MICHELE: Oh yes, yeah. +VICTORIA: Well, tell me more about your interaction with your developers' team. And you mentioned how wonderful they are. What is your communication patterns with them? Do you have regular meetings set up, or what is that like? +MICHELE: So it's a company that I met through YC summer school program, got sort of chatting to them. They're really, really great with communication. So we communicate on Slack every day, get updates, have little videos of updates, and work through any issues, and then kind of weekly meetings. And yeah, it's been a really, really positive experience. +I also have recently...on top of working full-time, and doing this, and having two kids I recently had...my husband was very ill and in hospital for two months just over Christmas. And then he came out of hospital for three days over Christmas, but then I was ill and in hospital for a month. So it's been absolutely crazy just trying to look after the kids and get work going, all of this. And they've been really consistent throughout. They've just kept everything ticking away. So that's been really, really great to have that, knowing that that continues on when I've had lots of life things going on. +VICTORIA: That ability for the team to manage themselves and be proactive in their communication is something I would always advise founders to look for in a development partner. You want to see that activity on a daily basis and see the product fairly often as well. You don't want to be surprised three months later with what they built and have it not be correct, what you're looking for. +MICHELE: Yeah, it's literally been back and forth of details that need ironing out. There's always a list that I can get to in my time, and there's the acknowledgment that I'm kind of working around a full-time job. +VICTORIA: Well, what are you most excited about in your features roadmap that you could share with us? +MICHELE: I'm so excited by all of it. I have two things that I'm really excited about. The first is the bubble, so that's just the ability to immediately connect to parents in different contexts. So I can immediately connect to all the parents in my child's nursery. It makes it really easy to organize birthday parties, play dates in other contexts as well. Say, for example, my daughter started a gymnastics course. We pay for the whole gymnastics course. She then didn't really want to do it because she didn't know anybody there. +And so I think we managed about two lessons before she just really didn't want to do it anymore. And, again, I had this sort of feeling that if we were able to talk to the other parents and encourage some friendships and things, that would be really helpful for her. And just as things go along, the kids do become friends, and it's nice to be able to connect to the other parents in those contexts as well. Same thing for summer camps, any kind of setting where your kids are making new friends. And you want to get to know the parents of those friends and be able to connect to other families. +And then the other feature that I'm really excited about is just being able to with one click find things nearby, toilets, cafes, supermarkets really easily. Usually, you have, one, holding a baby, pushing a pram, toddler has to suddenly use the toilet, no idea where to find one. So just being able to one click of a button find that really near me, I think, will be really, really useful. So I'm really excited about that feature and just seeing it working nicely. +VICTORIA: Great. And then you'll get to use it in real life. [laughs] +MICHELE: Yeah, exactly. +VICTORIA: Build the change you want to see in the world. I love it. And then, if you could go back in time and give yourself some advice when this all started now that you have this hindsight, what would you tell yourself? +MICHELE: I probably would tell myself to just keep at it. Maybe don't waste time trying to fill perceived gaps in your own abilities because I can learn stuff, and I can find support, and advisors, and mentors. So probably, that's what I would focus on. I spent a lot of time and energy trying to find a co-founder that would fill these gaps that I felt like I had. +I'd come from an academic and a neuroscience background, less commercial experience, so I worried about needing somebody who would have that business side, needing somebody to have that technical side. But, in fact, I've got a lot of those skills from my career and from my jobs anyway. I can learn a lot. I managed to get myself a Ph.D. in neuroscience from Cambridge University, so I can probably pick things up. [laughs] And I also can fill in any gaps with really great mentors and advisors. +VICTORIA: I love that. And I love that this problem that you had drove you to find the solution and to push forward even if you didn't know all the answers. +MICHELE: Yeah. Exactly, yeah. +VICTORIA: Wonderful. What does success look like for playroom in the next six months or five years? +MICHELE: Six months is having the app in some of the nurseries that we've been working with so out with parents and making those communities. In five years, it's having hundreds of thousands of parents in communities and having them supported, connected to other parents, feeling like they have a safe space for themselves and their kids. +VICTORIA: I love it. And maybe you can mention even more about what the impact that can have on a parent who might be struggling to keep it all together. +MICHELE: Oh, a huge impact. So I know this personally because my husband was ill, and then I was ill. So we had three months, you know, a five-year-old and a two-year-old, each of us solo parenting and each of us with quite serious illnesses. And it was incredibly difficult. I was lucky enough that my next-door neighbor her kids are the same age and go to the same school. And actually, that's when I met them. So even though we were neighbors, we hadn't even met. +But when she found out that my husband was unwell and I was looking after the kids on my own, really stepped up and helped look after my daughter, take some of the burden off of doing all the parenting on my own, plus visiting my husband in the hospital. And then reached out to a wider community within the area, like her friends that she knows from the school, and these parents really stepped up and helped me so much, like bringing food around and being that community that everybody wants and needs. +And I feel like a lot of it came about sort of accidentally because I was in this really difficult situation, but it helped me so much. I can't even describe how much. And I just think if I can do that for lots of other parents, it will make a huge impact because it is really difficult for some people, for a lot of people. +VICTORIA: I think the impact can't be underestimated enough. I know recently I signed up for Big Sisters and Big Brothers San Diego, so it's mentorship for children in the local county. And taking some of the training courses, they say in the U.S. alone, there are 3 million children who are just neglected or abused every year. Neglect could come from not having that social support network and not being able to look after your kids or not having other ways to connect with parents to get the support you need. So I think it's a really amazing product that you're building. +MICHELE: Oh, thank you. Yeah, I completely agree that there are so many ways that it can help and actually in just bringing together communities just, sort of locally centered around your children. And yeah, as you're saying, that neglect when there are situations where people actually...parents can't cope or need help and won't reach out. It's a sort of more natural way to have a community around you. +VICTORIA: Are there any other final takeaways you'd like to leave for listeners? +MICHELE: Well, I guess for the parents, parenting is hard, and it can be lonely, and that's okay. Just try and reach out to people as much as you can and go join playroom. +VICTORIA: Wonderful. Thank you so much, Michele. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Michele Veldsman. + + + Michele Veldsman is Director of Neuroscience R&D at Cambridge Cognition and Founder and CEO of Playroom, an invitation-only secure social network for families.

+ +

Victoria talks to Michele about the premise of Playroom and its goal of giving parents a network, a safe social community where parents are able to know and easily communicate with people associated with their children and also provide specific options to maintain boundaries when it comes to their privacy and safety, the challenges families face in raising kids and maintaining a career, and new features she wants the app to include, such as finding nearby restrooms while out and about.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Michele Veldsman, Director of Neuroscience R&D at Cambridge Cognition and Founder and CEO of playroom, an invitation-only secure social network for your family. Michele, thank you for joining me.

+ +

MICHELE: Thank you for having me.

+ +

VICTORIA: Tell me a little bit about your journey. How did all of this get started?

+ +

MICHELE: I had some kids, and I realized quite quickly that raising children is really difficult. I don't have family close by to support me. They are a couple of hours away. But trying to manage being a professional working in a fairly intense job, looking after my kids, making sure they have everything that they need and that they can socialize, and that I have a support network around me turned out to be really difficult. And so I wanted to find a way to solve that essentially.

+ +

VICTORIA: Right. So you identified a problem from your own life in trying to manage your career, and you're raising your children without that close, immediate support.

+ +

MICHELE: Yeah, exactly, yeah. And I realized this is a problem for a lot of people that increasingly, we don't live in these sort of small communities where we're surrounded by friends and family. Increasingly, people are moving to different cities, different countries. And that support network isn't there, but there are still all of the challenges of raising kids and trying to have a career at the same time.

+ +

VICTORIA: Right. And like we were talking before we recorded, I just got back from visiting my family in Virginia, and I live in California now. So I'm familiar with some of the challenges my brother and sister-in-law are facing with childcare. Can you tell us some of the things that specifically you found really difficult in this situation?

+ +

MICHELE: A lot of the time in my working life, I found there were loads and loads of tech to kind of try and make things easier to organize things. There's just a lot out there just for my working life but not much to support my family life, of which there are actually many, many more challenges because I'm kind of trying to juggle. I'm making sure that my kids their healthcare is all right, that they're getting their vaccinations on time, that I'm applying to school places on time, that I'm making sure that they're meeting other kids their age, and they're having play dates, and organizing birthday parties, all of those things.

+ +

And then to try and fit that all into the wider day-to-day life, I found this really difficult. I spoke to other parents, and they also found it really difficult. In fact, I did some research with over 120 parents, and 70% of them found parenting really difficult or extremely difficult.

+ +

VICTORIA: That's a lot of cognitive load on a person to manage all of these different things like school, and medical, and all the things you need to buy, [laughs] and what brands are the best.

+ +

MICHELE: [laughs] Yeah, exactly. And actually, just trying to build this community around yourself is more difficult than you anticipate. So, for example, my kids went to nursery. And this is the time that they're starting to socialize and making these important connections that are really important to their development. And so as a parent, you're hearing from your three-year-old, oh, they've got this new best friend, but you have no idea how to connect to the parents of that child. And the nurseries daycare can't give out that information because, of course, there are privacy issues.

+ +

So it's really difficult to make connections to other parents to be able to do these things like play dates. Organizing a birthday party, I found what you have to do is just take an invitation, give it to the nursery or the daycare center. Hopefully, they put it in the bags of the children that are friends with your kids, and then you kind of hope that they've got it and the right people are coming. You don't know who's coming to your kid's birthday party. And this just all seemed like there could be easy solutions to solve this to really build communities that center around your children.

+ +

VICTORIA: And I love that the purpose of playroom is to really build that community of social support that you need for parents. You mentioned you started to do some research on what that would look like. And I'm wondering if there was anything that surprised you as a result of that research.

+ +

MICHELE: Yes, I was quite surprised by...I suppose in some ways, it's reassuring actually as well that a lot of parents are going through similar struggles, struggling to connect to other families and not sort of in that way of, like, as you're...it's kind of a strange thing when you have kids because when they're very young, you can still socialize with your friends and people that you meet, maybe work colleagues.

+ +

But as they get older, the focus becomes a little more around them and their friends, so making those connections are a little bit more difficult. So a lot of people struggle with that. A lot of people struggled with just keeping on top of everything. As you're saying, that cognitive load is very large; just trying to remember organizing dentist appointments, doctor's appointments, all of those things. It's a large cognitive load. And we've got enough tech now that we shouldn't have to...we should be able to put that load on to technology that can support us.

+ +

VICTORIA: And so you feel like it was reassuring almost that this was a common problem [laughs], and it wasn't just you.

+ +

MICHELE: Yeah, it's reassuring. It's always reassuring when you connect with other people to realize that they're going through similar things. It's not just you that's, you know, somehow not able to manage it all.

+ +

But the other thing I found interesting is that there's a very large spectrum of how people feel about images and media associated with their children. So you've got a really wide spectrum of people who...some parents are very happy to share a lot about their children's lives, and their photos, and things that they're proud of on the major social media platforms.

+ +

And other parents are a lot more guarded, and they don't want to share those pictures or have other people share them on platforms. So there's a massive spectrum of how people feel about the use of images and media associated with their children and also related to that of data associated with their children.

+ +

VICTORIA: Yes, and I wanted to ask you about how privacy played into your planning on how you built the application.

+ +

MICHELE: This was important to me because I had both that experience, and also, I started to become more aware of the darker sides of the major platforms where there's perhaps not as much protection for children and that, of course, children can't consent. So I found...having spoken to all of these parents, the spectrum was very wide on what people were willing to share, and how much they knew about how their data was used, and how much privacy they had on these platforms. I really wanted to ensure that that spectrum was reflected.

+ +

In playroom, within the app, it's built so that you have control over how much privacy, how openly your images, for example, of your child, can be shared. So it can be from having any images to be shared with anybody. You know, maybe we're at a birthday party, and there are a lot of children there. So there are lots of pictures where your child is in there; some people are very happy for those to be shared. Others are not wanting that shared anywhere.

+ +

So within the app, you have control over how far those sorts of pictures can be shared and with whom. But the premise of playroom is that you're essentially in a network, a community where you know everybody associated with your children. So it's not that sort of massively open network. It's very much closed and associated with just the people you know are surrounding your children.

+ +

VICTORIA: That's great, and it's very relevant for me. I just got a new camera, and I offered to take pictures for my niece's birthday party last weekend. And now I have all these photos that, I'm not sure how to share them with the parents and in a way that would be secure and provide those options. So I can understand the value of what you've built here.

+ +

MICHELE: Within playroom, there are bubbles. So if your child, for example, goes to nursery or daycare, they usually are in a room with children of a similar age, a playroom, that forms a bubble. So the nursery gives you a secure code that connects you to the other parents in that playroom. So that forms this bubble of parents associated with your children.

+ +

So if you're taking photos at an event, so let's say you have a birthday party, you take photos. There are lots of other children in those photos. You can share those photos with the people in that bubble and in that bubble alone. And then, you can set your own personal media sharing settings so that you can make it clear to other parents that I don't want you to share this to wider social media. Watermark everything, very strongly watermarked or not downloadable. Or I'm happy for you to share it within playroom itself with other people that I know. So those settings are sort of adjustable depending on your preferences.

+ +

VICTORIA: Were there any obstacles that you faced from maybe a technology or a process perspective with implementing or building the app?

+ +

MICHELE: Yeah, so there are a couple of challenges. The biggest one is data and privacy. So, of course, security is a huge priority. That's going to be the center of priorities, really, so that everything is very, very secure. Parents, of course, are conscious of security surrounding their children. To be honest, as I was saying before, with sharing of media, it's quite on the spectrum, but either way, the priority is security and then privacy.

+ +

So the use of data is an interesting one because a lot of traditional social networks, social media rely on the monetization of data. And again, this works on a spectrum where some parents flat out don't want any data associated with their children used or monetized in any way. Others are a lot more liberal about that.

+ +

My personal view and from having spoken to a lot of parents, I think there's a good middle ground in which data is used in a responsible way for the purposes of actually benefiting parents in some way. So maybe it's the use of data rather than constant targeted ads, the use of data for the provision of services. Maybe within an area, you've got a high proportion of children there, and there needs to be better childcare provisions or play activity provisions.

+ +

VICTORIA: That makes sense. So make the data more relevant in the way that it's used to provide better services to parents, right?

+ +

MICHELE: Exactly, yeah, rather than that strict sort of targeted advertising.

+ +

VICTORIA: That makes sense. And so you've had to adjust your plan for monetization based on the needs of your users regarding privacy and security, and we love to hear that founders really care about privacy and security at thoughtbot, so...

+ +

MICHELE: Yes, exactly. Yeah, I think it's really, really important, and even more so now. There's really this acknowledgment of the very large open networks that they were never really built around children, of course. I mean, why would they be? But there's been a lot of controversy recently over parents having images and their children featured in videos and things online. The child accounts run by parents have millions of followers and videos, images, and things get saved thousands of times and commented in ways that are a little uncomfortable.

+ +

So there is this sort of growing feeling that these large open networks...mostly parents just don't really know. And they do...when you become a parent, you're really excited, and you're proud, and you want to share these things with the world. And you perhaps don't think about those kinds of darker sides of things. That's really coming into the forefront now. So I think a sort of more closed community-based network is important.

+ +

VICTORIA: I agree. I've spent some time volunteering for organizations that work with children and privacy and human trafficking situations. And when you start to understand really how dark it can get for children, maybe too dark for this podcast, but security and privacy becomes the penultimate goal.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. That's tbot.io/incubator.

+ +

VICTORIA: You mentioned learning all of this as part of your journey on building the app. I'm curious what you brought from your background in neuroscience into the creation of the app and maybe how that played into how you built certain behaviors and things into the features.

+ +

MICHELE: Yeah, it's kind of interesting. So my neuroscience background, I guess, has really informed how I think about child development and brain development and the importance of the developmental stages of socializing with children. It was always at the front of my mind, and one of the things that really spurred me on to create this is really knowing that as children are developing, they are learning these really important social skills, and I just wanted to foster that as much as possible. And I thought, you know, it's actually really difficult to foster that social side of things if you don't have a community naturally around you.

+ +

So I guess that's the main way that it's fed into my thinking about playroom. Other than that, I'm not too sure, actually. I think it's early stages, but I think it will probably influence some of the UX decisions, which is a big part of what I do in my day job, not the UX itself but the kind of psychology and neuroscience behind certain behaviors and how we interact with technology.

+ +

VICTORIA: I love to see founders and people who find their way into technology roles that usually come from a wide variety of backgrounds. And for me, neuroscience makes a lot of sense when you're doing these studies. Because you really are even, you know, from a scientific perspective, setting up a study and experiment to see how people will react to it. And you're proving your theory of is this how people will actually relate and connect inside the application?

+ +

MICHELE: Yes, absolutely, yeah. A lot of my job is data science. So I'm really excited to just get data in that I can really make decisions based on. I'm very much a kind of evidence-based person from my science background definitely.

+ +

VICTORIA: Yes, excellent. And maybe you could tell me more about a decision you had to make maybe early on in the development of the app that was challenging for you or you had to put a lot of time and thought into.

+ +

MICHELE: One of the things I found tricky, I suppose, is kind of being a solo founder, actually. Early on, I spent a lot of time trying to find a co-founder, and I really wanted somebody like a technical co-founder that could kind of fill the gap that I have. I don't have any formal experience in app development or anything like that, although a lot of my job involves coding and the data science side of things.

+ +

Yeah, I spent a lot of time trying to find a technical co-founder and just really struggled to find somebody that had interest, and passion, and vision that would work for playroom. And so, after a while and after speaking to a couple of mentors, I decided to save that energy of trying to find somebody and just go at it alone for now. So, you know, open to finding somebody who has a similar vision for it, but yeah, that was really a difficult thing; it always is being a solo founder. But I just am really passionate about it and kind of filled the gaps with mentors and with advisors who can help me along the way.

+ +

VICTORIA: That's so interesting. I think deciding about who you're going to bring into your inner circle when you're passionate about an idea sounds like a very difficult decision.

+ +

MICHELE: Yeah, it is, yeah, and it's a strange sort of space as well because by no means does it need somebody who has children or has an interest there. But I think it does help with the passion because it's a really specific problem. And yeah, I just haven't found anyone yet.

+ +

VICTORIA: But you have found several mentors. That sounds like it's meeting your needs in that way for now. How did you go about finding the right people to give you advice in that way?

+ +

MICHELE: A combination really of just kind of stalking through LinkedIn and connecting to people, and just chatting to people, and then also through networks of other founders, and going through accelerators, things like that where I'm kind of formally introduced to mentors. They've maybe given me warm introductions, amazing women's network where people have either given warm introductions or volunteered themselves to give advice. That's been really, really great. You sort of feel like you've got a community there already.

+ +

VICTORIA: That's great. And did you focus on local groups in the UK, or did you go just online virtual groups? Which was easier for you?

+ +

MICHELE: A combination. So I went through an accelerator that was based in London, and so that introduced me to a few people more locally and quite a wide network, actually. I also joined a women of color network called Founderland, and they're based in Berlin. And they are a really amazing support network that has quite a wide international reach but really gives you a lot of support and guidance and is completely free and just really feels like a nice, supportive community.

+ +

VICTORIA: Sounds like building a community of founders is as important as building a community for people raising children, right? [laughs]

+ +

MICHELE: Yeah, definitely. [laughs] Yeah, I think so. I think any aspect of your life that is difficult benefits from a community really because, in almost all areas, there are people who have gone through something before that want to make it easy for you or who are going through something at the same time and want somebody to talk to or to support each other.

+ +

VICTORIA: The most important thing we can be doing is building community. You have your full-time position, and then you also have your children that you're raising, and you are founding this company. How do you make time for yourself and for your own peace of mind in the week?

+ +

[laughter]

+ +

MICHELE: With great difficulty, yeah, [laughter] and a very supportive partner. It's a real struggle, and things sometimes have to be slower than I would like. I've got an amazing team of app developers who are absolutely brilliant and are usually chasing me rather than me chasing them, which is always really great. Again, a fantastic support network, a big community of other parent founders who know how difficult it all is. And then it's just like a lot of working evenings, taking a day off to focus on things.

+ +

VICTORIA: Yes, we're learning a technique at thoughtbot with energy coaching and coaching people on when to take breaks and how to make sure you have time for lunch and take vacations, and all of that, which I think is important for your long-term ability to maintain your momentum.

+ +

MICHELE: Yes, definitely.

+ +

VICTORIA: But I've heard from many founders, you know, the support network is one of the most important things to be able to balance everything.

+ +

MICHELE: Yes, it really is, yeah. I am susceptible to burnout, and I know it now. And I should know better because I know the kind of neuroscience of it as well. And so I do have to be really careful. I don't push myself too much. One of the good things actually, you know, my kids are school age now. So they have these half-term breaks. They have regular breaks from school, and then summer holidays, of course, Christmas, all of that, and that sort of forces a time for you to break and then spend really quality time with the kids. So it's really, really good in that way.

+ +

VICTORIA: I appreciate kind of enforced time off. [laughs]

+ +

MICHELE: Yeah, I know. [laughs]

+ +

VICTORIA: And really committing to it. It makes sense, yeah. [laughter]

+ +

MICHELE: I just realized that.

+ +

VICTORIA: UK people are better at that than I think in the U.S. generally, but it's certainly something I strive for. Sometimes even just going to a place where there's no internet access, [laughs] so good luck trying to reach me.

+ +

MICHELE: Oh yes, yeah.

+ +

VICTORIA: Well, tell me more about your interaction with your developers' team. And you mentioned how wonderful they are. What is your communication patterns with them? Do you have regular meetings set up, or what is that like?

+ +

MICHELE: So it's a company that I met through YC summer school program, got sort of chatting to them. They're really, really great with communication. So we communicate on Slack every day, get updates, have little videos of updates, and work through any issues, and then kind of weekly meetings. And yeah, it's been a really, really positive experience.

+ +

I also have recently...on top of working full-time, and doing this, and having two kids I recently had...my husband was very ill and in hospital for two months just over Christmas. And then he came out of hospital for three days over Christmas, but then I was ill and in hospital for a month. So it's been absolutely crazy just trying to look after the kids and get work going, all of this. And they've been really consistent throughout. They've just kept everything ticking away. So that's been really, really great to have that, knowing that that continues on when I've had lots of life things going on.

+ +

VICTORIA: That ability for the team to manage themselves and be proactive in their communication is something I would always advise founders to look for in a development partner. You want to see that activity on a daily basis and see the product fairly often as well. You don't want to be surprised three months later with what they built and have it not be correct, what you're looking for.

+ +

MICHELE: Yeah, it's literally been back and forth of details that need ironing out. There's always a list that I can get to in my time, and there's the acknowledgment that I'm kind of working around a full-time job.

+ +

VICTORIA: Well, what are you most excited about in your features roadmap that you could share with us?

+ +

MICHELE: I'm so excited by all of it. I have two things that I'm really excited about. The first is the bubble, so that's just the ability to immediately connect to parents in different contexts. So I can immediately connect to all the parents in my child's nursery. It makes it really easy to organize birthday parties, play dates in other contexts as well. Say, for example, my daughter started a gymnastics course. We pay for the whole gymnastics course. She then didn't really want to do it because she didn't know anybody there.

+ +

And so I think we managed about two lessons before she just really didn't want to do it anymore. And, again, I had this sort of feeling that if we were able to talk to the other parents and encourage some friendships and things, that would be really helpful for her. And just as things go along, the kids do become friends, and it's nice to be able to connect to the other parents in those contexts as well. Same thing for summer camps, any kind of setting where your kids are making new friends. And you want to get to know the parents of those friends and be able to connect to other families.

+ +

And then the other feature that I'm really excited about is just being able to with one click find things nearby, toilets, cafes, supermarkets really easily. Usually, you have, one, holding a baby, pushing a pram, toddler has to suddenly use the toilet, no idea where to find one. So just being able to one click of a button find that really near me, I think, will be really, really useful. So I'm really excited about that feature and just seeing it working nicely.

+ +

VICTORIA: Great. And then you'll get to use it in real life. [laughs]

+ +

MICHELE: Yeah, exactly.

+ +

VICTORIA: Build the change you want to see in the world. I love it. And then, if you could go back in time and give yourself some advice when this all started now that you have this hindsight, what would you tell yourself?

+ +

MICHELE: I probably would tell myself to just keep at it. Maybe don't waste time trying to fill perceived gaps in your own abilities because I can learn stuff, and I can find support, and advisors, and mentors. So probably, that's what I would focus on. I spent a lot of time and energy trying to find a co-founder that would fill these gaps that I felt like I had.

+ +

I'd come from an academic and a neuroscience background, less commercial experience, so I worried about needing somebody who would have that business side, needing somebody to have that technical side. But, in fact, I've got a lot of those skills from my career and from my jobs anyway. I can learn a lot. I managed to get myself a Ph.D. in neuroscience from Cambridge University, so I can probably pick things up. [laughs] And I also can fill in any gaps with really great mentors and advisors.

+ +

VICTORIA: I love that. And I love that this problem that you had drove you to find the solution and to push forward even if you didn't know all the answers.

+ +

MICHELE: Yeah. Exactly, yeah.

+ +

VICTORIA: Wonderful. What does success look like for playroom in the next six months or five years?

+ +

MICHELE: Six months is having the app in some of the nurseries that we've been working with so out with parents and making those communities. In five years, it's having hundreds of thousands of parents in communities and having them supported, connected to other parents, feeling like they have a safe space for themselves and their kids.

+ +

VICTORIA: I love it. And maybe you can mention even more about what the impact that can have on a parent who might be struggling to keep it all together.

+ +

MICHELE: Oh, a huge impact. So I know this personally because my husband was ill, and then I was ill. So we had three months, you know, a five-year-old and a two-year-old, each of us solo parenting and each of us with quite serious illnesses. And it was incredibly difficult. I was lucky enough that my next-door neighbor her kids are the same age and go to the same school. And actually, that's when I met them. So even though we were neighbors, we hadn't even met.

+ +

But when she found out that my husband was unwell and I was looking after the kids on my own, really stepped up and helped look after my daughter, take some of the burden off of doing all the parenting on my own, plus visiting my husband in the hospital. And then reached out to a wider community within the area, like her friends that she knows from the school, and these parents really stepped up and helped me so much, like bringing food around and being that community that everybody wants and needs.

+ +

And I feel like a lot of it came about sort of accidentally because I was in this really difficult situation, but it helped me so much. I can't even describe how much. And I just think if I can do that for lots of other parents, it will make a huge impact because it is really difficult for some people, for a lot of people.

+ +

VICTORIA: I think the impact can't be underestimated enough. I know recently I signed up for Big Sisters and Big Brothers San Diego, so it's mentorship for children in the local county. And taking some of the training courses, they say in the U.S. alone, there are 3 million children who are just neglected or abused every year. Neglect could come from not having that social support network and not being able to look after your kids or not having other ways to connect with parents to get the support you need. So I think it's a really amazing product that you're building.

+ +

MICHELE: Oh, thank you. Yeah, I completely agree that there are so many ways that it can help and actually in just bringing together communities just, sort of locally centered around your children. And yeah, as you're saying, that neglect when there are situations where people actually...parents can't cope or need help and won't reach out. It's a sort of more natural way to have a community around you.

+ +

VICTORIA: Are there any other final takeaways you'd like to leave for listeners?

+ +

MICHELE: Well, I guess for the parents, parenting is hard, and it can be lonely, and that's okay. Just try and reach out to people as much as you can and go join playroom.

+ +

VICTORIA: Wonderful. Thank you so much, Michele.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Michele Veldsman.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Michele Veldsman is Director of Neuroscience R&D at Cambridge Cognition and Founder and CEO of Playroom, an invitation-only secure social network for families.

+ +

Victoria talks to Michele about the premise of Playroom and its goal of giving parents a network, a safe social community where parents are able to know and easily communicate with people associated with their children and also provide specific options to maintain boundaries when it comes to their privacy and safety, the challenges families face in raising kids and maintaining a career, and new features she wants the app to include, such as finding nearby restrooms while out and about.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Michele Veldsman, Director of Neuroscience R&D at Cambridge Cognition and Founder and CEO of playroom, an invitation-only secure social network for your family. Michele, thank you for joining me.

+ +

MICHELE: Thank you for having me.

+ +

VICTORIA: Tell me a little bit about your journey. How did all of this get started?

+ +

MICHELE: I had some kids, and I realized quite quickly that raising children is really difficult. I don't have family close by to support me. They are a couple of hours away. But trying to manage being a professional working in a fairly intense job, looking after my kids, making sure they have everything that they need and that they can socialize, and that I have a support network around me turned out to be really difficult. And so I wanted to find a way to solve that essentially.

+ +

VICTORIA: Right. So you identified a problem from your own life in trying to manage your career, and you're raising your children without that close, immediate support.

+ +

MICHELE: Yeah, exactly, yeah. And I realized this is a problem for a lot of people that increasingly, we don't live in these sort of small communities where we're surrounded by friends and family. Increasingly, people are moving to different cities, different countries. And that support network isn't there, but there are still all of the challenges of raising kids and trying to have a career at the same time.

+ +

VICTORIA: Right. And like we were talking before we recorded, I just got back from visiting my family in Virginia, and I live in California now. So I'm familiar with some of the challenges my brother and sister-in-law are facing with childcare. Can you tell us some of the things that specifically you found really difficult in this situation?

+ +

MICHELE: A lot of the time in my working life, I found there were loads and loads of tech to kind of try and make things easier to organize things. There's just a lot out there just for my working life but not much to support my family life, of which there are actually many, many more challenges because I'm kind of trying to juggle. I'm making sure that my kids their healthcare is all right, that they're getting their vaccinations on time, that I'm applying to school places on time, that I'm making sure that they're meeting other kids their age, and they're having play dates, and organizing birthday parties, all of those things.

+ +

And then to try and fit that all into the wider day-to-day life, I found this really difficult. I spoke to other parents, and they also found it really difficult. In fact, I did some research with over 120 parents, and 70% of them found parenting really difficult or extremely difficult.

+ +

VICTORIA: That's a lot of cognitive load on a person to manage all of these different things like school, and medical, and all the things you need to buy, [laughs] and what brands are the best.

+ +

MICHELE: [laughs] Yeah, exactly. And actually, just trying to build this community around yourself is more difficult than you anticipate. So, for example, my kids went to nursery. And this is the time that they're starting to socialize and making these important connections that are really important to their development. And so as a parent, you're hearing from your three-year-old, oh, they've got this new best friend, but you have no idea how to connect to the parents of that child. And the nurseries daycare can't give out that information because, of course, there are privacy issues.

+ +

So it's really difficult to make connections to other parents to be able to do these things like play dates. Organizing a birthday party, I found what you have to do is just take an invitation, give it to the nursery or the daycare center. Hopefully, they put it in the bags of the children that are friends with your kids, and then you kind of hope that they've got it and the right people are coming. You don't know who's coming to your kid's birthday party. And this just all seemed like there could be easy solutions to solve this to really build communities that center around your children.

+ +

VICTORIA: And I love that the purpose of playroom is to really build that community of social support that you need for parents. You mentioned you started to do some research on what that would look like. And I'm wondering if there was anything that surprised you as a result of that research.

+ +

MICHELE: Yes, I was quite surprised by...I suppose in some ways, it's reassuring actually as well that a lot of parents are going through similar struggles, struggling to connect to other families and not sort of in that way of, like, as you're...it's kind of a strange thing when you have kids because when they're very young, you can still socialize with your friends and people that you meet, maybe work colleagues.

+ +

But as they get older, the focus becomes a little more around them and their friends, so making those connections are a little bit more difficult. So a lot of people struggle with that. A lot of people struggled with just keeping on top of everything. As you're saying, that cognitive load is very large; just trying to remember organizing dentist appointments, doctor's appointments, all of those things. It's a large cognitive load. And we've got enough tech now that we shouldn't have to...we should be able to put that load on to technology that can support us.

+ +

VICTORIA: And so you feel like it was reassuring almost that this was a common problem [laughs], and it wasn't just you.

+ +

MICHELE: Yeah, it's reassuring. It's always reassuring when you connect with other people to realize that they're going through similar things. It's not just you that's, you know, somehow not able to manage it all.

+ +

But the other thing I found interesting is that there's a very large spectrum of how people feel about images and media associated with their children. So you've got a really wide spectrum of people who...some parents are very happy to share a lot about their children's lives, and their photos, and things that they're proud of on the major social media platforms.

+ +

And other parents are a lot more guarded, and they don't want to share those pictures or have other people share them on platforms. So there's a massive spectrum of how people feel about the use of images and media associated with their children and also related to that of data associated with their children.

+ +

VICTORIA: Yes, and I wanted to ask you about how privacy played into your planning on how you built the application.

+ +

MICHELE: This was important to me because I had both that experience, and also, I started to become more aware of the darker sides of the major platforms where there's perhaps not as much protection for children and that, of course, children can't consent. So I found...having spoken to all of these parents, the spectrum was very wide on what people were willing to share, and how much they knew about how their data was used, and how much privacy they had on these platforms. I really wanted to ensure that that spectrum was reflected.

+ +

In playroom, within the app, it's built so that you have control over how much privacy, how openly your images, for example, of your child, can be shared. So it can be from having any images to be shared with anybody. You know, maybe we're at a birthday party, and there are a lot of children there. So there are lots of pictures where your child is in there; some people are very happy for those to be shared. Others are not wanting that shared anywhere.

+ +

So within the app, you have control over how far those sorts of pictures can be shared and with whom. But the premise of playroom is that you're essentially in a network, a community where you know everybody associated with your children. So it's not that sort of massively open network. It's very much closed and associated with just the people you know are surrounding your children.

+ +

VICTORIA: That's great, and it's very relevant for me. I just got a new camera, and I offered to take pictures for my niece's birthday party last weekend. And now I have all these photos that, I'm not sure how to share them with the parents and in a way that would be secure and provide those options. So I can understand the value of what you've built here.

+ +

MICHELE: Within playroom, there are bubbles. So if your child, for example, goes to nursery or daycare, they usually are in a room with children of a similar age, a playroom, that forms a bubble. So the nursery gives you a secure code that connects you to the other parents in that playroom. So that forms this bubble of parents associated with your children.

+ +

So if you're taking photos at an event, so let's say you have a birthday party, you take photos. There are lots of other children in those photos. You can share those photos with the people in that bubble and in that bubble alone. And then, you can set your own personal media sharing settings so that you can make it clear to other parents that I don't want you to share this to wider social media. Watermark everything, very strongly watermarked or not downloadable. Or I'm happy for you to share it within playroom itself with other people that I know. So those settings are sort of adjustable depending on your preferences.

+ +

VICTORIA: Were there any obstacles that you faced from maybe a technology or a process perspective with implementing or building the app?

+ +

MICHELE: Yeah, so there are a couple of challenges. The biggest one is data and privacy. So, of course, security is a huge priority. That's going to be the center of priorities, really, so that everything is very, very secure. Parents, of course, are conscious of security surrounding their children. To be honest, as I was saying before, with sharing of media, it's quite on the spectrum, but either way, the priority is security and then privacy.

+ +

So the use of data is an interesting one because a lot of traditional social networks, social media rely on the monetization of data. And again, this works on a spectrum where some parents flat out don't want any data associated with their children used or monetized in any way. Others are a lot more liberal about that.

+ +

My personal view and from having spoken to a lot of parents, I think there's a good middle ground in which data is used in a responsible way for the purposes of actually benefiting parents in some way. So maybe it's the use of data rather than constant targeted ads, the use of data for the provision of services. Maybe within an area, you've got a high proportion of children there, and there needs to be better childcare provisions or play activity provisions.

+ +

VICTORIA: That makes sense. So make the data more relevant in the way that it's used to provide better services to parents, right?

+ +

MICHELE: Exactly, yeah, rather than that strict sort of targeted advertising.

+ +

VICTORIA: That makes sense. And so you've had to adjust your plan for monetization based on the needs of your users regarding privacy and security, and we love to hear that founders really care about privacy and security at thoughtbot, so...

+ +

MICHELE: Yes, exactly. Yeah, I think it's really, really important, and even more so now. There's really this acknowledgment of the very large open networks that they were never really built around children, of course. I mean, why would they be? But there's been a lot of controversy recently over parents having images and their children featured in videos and things online. The child accounts run by parents have millions of followers and videos, images, and things get saved thousands of times and commented in ways that are a little uncomfortable.

+ +

So there is this sort of growing feeling that these large open networks...mostly parents just don't really know. And they do...when you become a parent, you're really excited, and you're proud, and you want to share these things with the world. And you perhaps don't think about those kinds of darker sides of things. That's really coming into the forefront now. So I think a sort of more closed community-based network is important.

+ +

VICTORIA: I agree. I've spent some time volunteering for organizations that work with children and privacy and human trafficking situations. And when you start to understand really how dark it can get for children, maybe too dark for this podcast, but security and privacy becomes the penultimate goal.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. That's tbot.io/incubator.

+ +

VICTORIA: You mentioned learning all of this as part of your journey on building the app. I'm curious what you brought from your background in neuroscience into the creation of the app and maybe how that played into how you built certain behaviors and things into the features.

+ +

MICHELE: Yeah, it's kind of interesting. So my neuroscience background, I guess, has really informed how I think about child development and brain development and the importance of the developmental stages of socializing with children. It was always at the front of my mind, and one of the things that really spurred me on to create this is really knowing that as children are developing, they are learning these really important social skills, and I just wanted to foster that as much as possible. And I thought, you know, it's actually really difficult to foster that social side of things if you don't have a community naturally around you.

+ +

So I guess that's the main way that it's fed into my thinking about playroom. Other than that, I'm not too sure, actually. I think it's early stages, but I think it will probably influence some of the UX decisions, which is a big part of what I do in my day job, not the UX itself but the kind of psychology and neuroscience behind certain behaviors and how we interact with technology.

+ +

VICTORIA: I love to see founders and people who find their way into technology roles that usually come from a wide variety of backgrounds. And for me, neuroscience makes a lot of sense when you're doing these studies. Because you really are even, you know, from a scientific perspective, setting up a study and experiment to see how people will react to it. And you're proving your theory of is this how people will actually relate and connect inside the application?

+ +

MICHELE: Yes, absolutely, yeah. A lot of my job is data science. So I'm really excited to just get data in that I can really make decisions based on. I'm very much a kind of evidence-based person from my science background definitely.

+ +

VICTORIA: Yes, excellent. And maybe you could tell me more about a decision you had to make maybe early on in the development of the app that was challenging for you or you had to put a lot of time and thought into.

+ +

MICHELE: One of the things I found tricky, I suppose, is kind of being a solo founder, actually. Early on, I spent a lot of time trying to find a co-founder, and I really wanted somebody like a technical co-founder that could kind of fill the gap that I have. I don't have any formal experience in app development or anything like that, although a lot of my job involves coding and the data science side of things.

+ +

Yeah, I spent a lot of time trying to find a technical co-founder and just really struggled to find somebody that had interest, and passion, and vision that would work for playroom. And so, after a while and after speaking to a couple of mentors, I decided to save that energy of trying to find somebody and just go at it alone for now. So, you know, open to finding somebody who has a similar vision for it, but yeah, that was really a difficult thing; it always is being a solo founder. But I just am really passionate about it and kind of filled the gaps with mentors and with advisors who can help me along the way.

+ +

VICTORIA: That's so interesting. I think deciding about who you're going to bring into your inner circle when you're passionate about an idea sounds like a very difficult decision.

+ +

MICHELE: Yeah, it is, yeah, and it's a strange sort of space as well because by no means does it need somebody who has children or has an interest there. But I think it does help with the passion because it's a really specific problem. And yeah, I just haven't found anyone yet.

+ +

VICTORIA: But you have found several mentors. That sounds like it's meeting your needs in that way for now. How did you go about finding the right people to give you advice in that way?

+ +

MICHELE: A combination really of just kind of stalking through LinkedIn and connecting to people, and just chatting to people, and then also through networks of other founders, and going through accelerators, things like that where I'm kind of formally introduced to mentors. They've maybe given me warm introductions, amazing women's network where people have either given warm introductions or volunteered themselves to give advice. That's been really, really great. You sort of feel like you've got a community there already.

+ +

VICTORIA: That's great. And did you focus on local groups in the UK, or did you go just online virtual groups? Which was easier for you?

+ +

MICHELE: A combination. So I went through an accelerator that was based in London, and so that introduced me to a few people more locally and quite a wide network, actually. I also joined a women of color network called Founderland, and they're based in Berlin. And they are a really amazing support network that has quite a wide international reach but really gives you a lot of support and guidance and is completely free and just really feels like a nice, supportive community.

+ +

VICTORIA: Sounds like building a community of founders is as important as building a community for people raising children, right? [laughs]

+ +

MICHELE: Yeah, definitely. [laughs] Yeah, I think so. I think any aspect of your life that is difficult benefits from a community really because, in almost all areas, there are people who have gone through something before that want to make it easy for you or who are going through something at the same time and want somebody to talk to or to support each other.

+ +

VICTORIA: The most important thing we can be doing is building community. You have your full-time position, and then you also have your children that you're raising, and you are founding this company. How do you make time for yourself and for your own peace of mind in the week?

+ +

[laughter]

+ +

MICHELE: With great difficulty, yeah, [laughter] and a very supportive partner. It's a real struggle, and things sometimes have to be slower than I would like. I've got an amazing team of app developers who are absolutely brilliant and are usually chasing me rather than me chasing them, which is always really great. Again, a fantastic support network, a big community of other parent founders who know how difficult it all is. And then it's just like a lot of working evenings, taking a day off to focus on things.

+ +

VICTORIA: Yes, we're learning a technique at thoughtbot with energy coaching and coaching people on when to take breaks and how to make sure you have time for lunch and take vacations, and all of that, which I think is important for your long-term ability to maintain your momentum.

+ +

MICHELE: Yes, definitely.

+ +

VICTORIA: But I've heard from many founders, you know, the support network is one of the most important things to be able to balance everything.

+ +

MICHELE: Yes, it really is, yeah. I am susceptible to burnout, and I know it now. And I should know better because I know the kind of neuroscience of it as well. And so I do have to be really careful. I don't push myself too much. One of the good things actually, you know, my kids are school age now. So they have these half-term breaks. They have regular breaks from school, and then summer holidays, of course, Christmas, all of that, and that sort of forces a time for you to break and then spend really quality time with the kids. So it's really, really good in that way.

+ +

VICTORIA: I appreciate kind of enforced time off. [laughs]

+ +

MICHELE: Yeah, I know. [laughs]

+ +

VICTORIA: And really committing to it. It makes sense, yeah. [laughter]

+ +

MICHELE: I just realized that.

+ +

VICTORIA: UK people are better at that than I think in the U.S. generally, but it's certainly something I strive for. Sometimes even just going to a place where there's no internet access, [laughs] so good luck trying to reach me.

+ +

MICHELE: Oh yes, yeah.

+ +

VICTORIA: Well, tell me more about your interaction with your developers' team. And you mentioned how wonderful they are. What is your communication patterns with them? Do you have regular meetings set up, or what is that like?

+ +

MICHELE: So it's a company that I met through YC summer school program, got sort of chatting to them. They're really, really great with communication. So we communicate on Slack every day, get updates, have little videos of updates, and work through any issues, and then kind of weekly meetings. And yeah, it's been a really, really positive experience.

+ +

I also have recently...on top of working full-time, and doing this, and having two kids I recently had...my husband was very ill and in hospital for two months just over Christmas. And then he came out of hospital for three days over Christmas, but then I was ill and in hospital for a month. So it's been absolutely crazy just trying to look after the kids and get work going, all of this. And they've been really consistent throughout. They've just kept everything ticking away. So that's been really, really great to have that, knowing that that continues on when I've had lots of life things going on.

+ +

VICTORIA: That ability for the team to manage themselves and be proactive in their communication is something I would always advise founders to look for in a development partner. You want to see that activity on a daily basis and see the product fairly often as well. You don't want to be surprised three months later with what they built and have it not be correct, what you're looking for.

+ +

MICHELE: Yeah, it's literally been back and forth of details that need ironing out. There's always a list that I can get to in my time, and there's the acknowledgment that I'm kind of working around a full-time job.

+ +

VICTORIA: Well, what are you most excited about in your features roadmap that you could share with us?

+ +

MICHELE: I'm so excited by all of it. I have two things that I'm really excited about. The first is the bubble, so that's just the ability to immediately connect to parents in different contexts. So I can immediately connect to all the parents in my child's nursery. It makes it really easy to organize birthday parties, play dates in other contexts as well. Say, for example, my daughter started a gymnastics course. We pay for the whole gymnastics course. She then didn't really want to do it because she didn't know anybody there.

+ +

And so I think we managed about two lessons before she just really didn't want to do it anymore. And, again, I had this sort of feeling that if we were able to talk to the other parents and encourage some friendships and things, that would be really helpful for her. And just as things go along, the kids do become friends, and it's nice to be able to connect to the other parents in those contexts as well. Same thing for summer camps, any kind of setting where your kids are making new friends. And you want to get to know the parents of those friends and be able to connect to other families.

+ +

And then the other feature that I'm really excited about is just being able to with one click find things nearby, toilets, cafes, supermarkets really easily. Usually, you have, one, holding a baby, pushing a pram, toddler has to suddenly use the toilet, no idea where to find one. So just being able to one click of a button find that really near me, I think, will be really, really useful. So I'm really excited about that feature and just seeing it working nicely.

+ +

VICTORIA: Great. And then you'll get to use it in real life. [laughs]

+ +

MICHELE: Yeah, exactly.

+ +

VICTORIA: Build the change you want to see in the world. I love it. And then, if you could go back in time and give yourself some advice when this all started now that you have this hindsight, what would you tell yourself?

+ +

MICHELE: I probably would tell myself to just keep at it. Maybe don't waste time trying to fill perceived gaps in your own abilities because I can learn stuff, and I can find support, and advisors, and mentors. So probably, that's what I would focus on. I spent a lot of time and energy trying to find a co-founder that would fill these gaps that I felt like I had.

+ +

I'd come from an academic and a neuroscience background, less commercial experience, so I worried about needing somebody who would have that business side, needing somebody to have that technical side. But, in fact, I've got a lot of those skills from my career and from my jobs anyway. I can learn a lot. I managed to get myself a Ph.D. in neuroscience from Cambridge University, so I can probably pick things up. [laughs] And I also can fill in any gaps with really great mentors and advisors.

+ +

VICTORIA: I love that. And I love that this problem that you had drove you to find the solution and to push forward even if you didn't know all the answers.

+ +

MICHELE: Yeah. Exactly, yeah.

+ +

VICTORIA: Wonderful. What does success look like for playroom in the next six months or five years?

+ +

MICHELE: Six months is having the app in some of the nurseries that we've been working with so out with parents and making those communities. In five years, it's having hundreds of thousands of parents in communities and having them supported, connected to other parents, feeling like they have a safe space for themselves and their kids.

+ +

VICTORIA: I love it. And maybe you can mention even more about what the impact that can have on a parent who might be struggling to keep it all together.

+ +

MICHELE: Oh, a huge impact. So I know this personally because my husband was ill, and then I was ill. So we had three months, you know, a five-year-old and a two-year-old, each of us solo parenting and each of us with quite serious illnesses. And it was incredibly difficult. I was lucky enough that my next-door neighbor her kids are the same age and go to the same school. And actually, that's when I met them. So even though we were neighbors, we hadn't even met.

+ +

But when she found out that my husband was unwell and I was looking after the kids on my own, really stepped up and helped look after my daughter, take some of the burden off of doing all the parenting on my own, plus visiting my husband in the hospital. And then reached out to a wider community within the area, like her friends that she knows from the school, and these parents really stepped up and helped me so much, like bringing food around and being that community that everybody wants and needs.

+ +

And I feel like a lot of it came about sort of accidentally because I was in this really difficult situation, but it helped me so much. I can't even describe how much. And I just think if I can do that for lots of other parents, it will make a huge impact because it is really difficult for some people, for a lot of people.

+ +

VICTORIA: I think the impact can't be underestimated enough. I know recently I signed up for Big Sisters and Big Brothers San Diego, so it's mentorship for children in the local county. And taking some of the training courses, they say in the U.S. alone, there are 3 million children who are just neglected or abused every year. Neglect could come from not having that social support network and not being able to look after your kids or not having other ways to connect with parents to get the support you need. So I think it's a really amazing product that you're building.

+ +

MICHELE: Oh, thank you. Yeah, I completely agree that there are so many ways that it can help and actually in just bringing together communities just, sort of locally centered around your children. And yeah, as you're saying, that neglect when there are situations where people actually...parents can't cope or need help and won't reach out. It's a sort of more natural way to have a community around you.

+ +

VICTORIA: Are there any other final takeaways you'd like to leave for listeners?

+ +

MICHELE: Well, I guess for the parents, parenting is hard, and it can be lonely, and that's okay. Just try and reach out to people as much as you can and go join playroom.

+ +

VICTORIA: Wonderful. Thank you so much, Michele.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Michele Veldsman.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+TS5vQI4t + + ]]> + + Victoria Guido + Michele Veldsman + + + 464: IVP with Zack Willis and Eric Liaw + https://podcast.thoughtbot.com/464 + 0b7deb3c-ddb3-49b0-a653-8e349d934b62 + Thu, 02 Mar 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Eric Liaw and Zack Willis are part of IVP, a leading venture firm with a 43-year history of partnering with entrepreneurs who are undaunted on the path to innovation. + +Will talks to Eric and Zack about what has made IVP so long-lasting in the Venture Capital industry, how they help companies' portfolios, and the accomplishments they are most proud of. + 38:19 + no + + + Eric Liaw and Zack Willis are part of IVP, a leading venture firm with a 43-year history of partnering with entrepreneurs who are undaunted on the path to innovation. +Will talks to Eric and Zack about what has made IVP so long-lasting in the Venture Capital industry, how they help companies' portfolios, and the accomplishments they are most proud of. +Follow Eric on LinkedIn (https://www.linkedin.com/in/ericliaw/) or Twitter (https://twitter.com/eliaw). +Follow Zack on LinkedIn (https://www.linkedin.com/in/zwill/) or Twitter (https://twitter.com/zwill). +IVP (https://www.ivp.com/) +Follow IVP on LinkedIn (https://www.linkedin.com/company/ivpvc/), Twitter (https://twitter.com/ivp), or Facebook (https://www.facebook.com/ivpvc/). +Follow Aarish Shah on LinkedIn (https://www.linkedin.com/in/adsinuk/) or Twitter (https://twitter.com/adsinuk). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Eric Liaw and Zack Willis, who are part of IVP, a leading venture firm with a 43-year history of partnering with entrepreneurs who are undaunted on the path to innovation. Zack, Eric, thank you for joining me. +ERIC: Thanks, Will. It's great to be here, really appreciate it. And I got to say, as the Giant Robot Podcast, as a kid growing up, Transformers were my favorite toys. So this may be the closest I ever get to being a Transformer by being part of Giant Robots, so thank you for the opportunity. +[laughter] +WILL: Love it. We love robots here, so it's perfect. All right, let's start here. For folks who may not know, tell us about IVP and what's on deck for 2023. +ERIC: Well, you gave a great intro, so let me just add to that a little bit. You know, we're really proud of our history and our firm. We've been around since 1980. So we're one of the sort of original Silicon Valley venture firms. But when I speak about the firm in that context, I don't think it does justice to how the firm has expanded over the years and how our investment activity now encompasses not only the Bay Area but major U.S. markets like New York and LA. We have investments in Canada, Australia, and a number in Western and Central Europe as well. +And the common theme for us is that we're focused on working with entrepreneurs who, as you pointed out, are undaunted as they innovate and are pursuing dreams to create companies that will become recognizable in households and companies across the world, not just today but tomorrow as well. So that's really what IVP is all about. And it's what we're looking forward to in 2023 despite obviously the fact that the world is a little more challenging these days, a little bit more uncertain in, particular in the venture category. +But we're really excited about the things that we're working on. We invested a lot in our team over a number of years. And, believe it or not, despite what you might read in headlines around venture activity, we are very much open for business in 2023 because we think that great entrepreneurs and great ideas come together at all times, regardless of whether the stock market is up or down. And our job is to find them, work with them, and become partners for three, four, or five, six, seven years, sometimes longer than that. So really, there's no bad time to start a company and get to know venture investors like us. +WILL: Yeah, definitely. Your company has been around for 43 years. Can you kind of tell me what has made you last that long, for 43 years? That's a long time to be in the venture capitalist world, especially before it was popular and fun. +ERIC: You know, it's a great question. I've been at the firm for 11 years now. So a lot of the credit goes to people that...our founder, Reid Dennis, who started the firm. He's in his 90s now, so he has since retired, but a lot of credit goes to people that came before me and before Zack. And I think that's a common theme for any kind of organization or institution, no pun intended, because that's what the I in IVP stands for. But it goes to that sort of common thread. You have to evolve, especially in technology. +The technology markets that were successful for IVP in the early '80s that's not really cutting-edge venture anymore. As an example, Seagate was one of our first investments ever when people weren't sure that personal hard drive technology would actually work or whether or not they're getting market demand. I mean, who would actually want storage themselves carried around with them at all times? And now, think about how much storage you have in your pocket. It's pretty gnarly to think about how much technology has advanced. +But if you kept only thinking about, okay, I'm going to invest in the next hard drive, you would have really gotten stuck after that. And obviously, the things that have come since out of the minds of technology entrepreneurs have far exceeded what people at the time of the founding of IVP would have thought was possible. So I think that evolution is really important, staying fresh; technology trends evolve. In the early days of IVP and in Silicon Valley, there was a saying among venture capitalists that if you couldn't drive to the board meeting within 30 minutes, you didn't make the investment. That's just not true anymore. There's no way. +WILL: [laughs] +ERIC: And I think COVID has certainly proved that because investments are being made around the world. Now, maybe in hindsight, that was too fast. There was too much capital flowing around just to resume dating if you will. But the underlying theme is evolution, and I think it's teamwork. Because our founder, Reid, wanted the organization and firm to thrive well beyond his days as an active investor, and you can only do that with building a team that's multigenerational. And I'm proud and lucky to be part of an organization that's done that. +WILL: Awesome, awesome. Well, tell me about you. Tell me more about your background. How did you get started in the VC world? +ERIC: You know, child of immigrants who came to the United States in the '70s from Taiwan. They met in New York City. Like many other people, moved to the burbs and they started a family. So I was born in New Jersey. My brother and I were both born there. I moved to LA when I was 12. I lived in Southern California until I went to college. Had the miraculous fortune to somehow get into Stanford and went to school sort of in the late '90s into the early 2000s, as good fortune would have it, in the middle of the internet bubble. +So I had kind of a front-row seat to that era of technology, innovation not knowing anything about tech when I showed up in Palo Alto in the fall of '96. I got exposed to venture capital while I was in school. There was a pretty memorable, at least for me, speech that I went to. John Doerr, now retired from Kleiner Perkins, was on stage in the engineering auditorium and gave a speech about how Amazon was going to change the world. And this was probably in the fall of '98. +And he was right. I just think maybe the timeframe was slightly off, but he was right. I mean, at the time, it was books and CDs, and to some of our listeners, CDs was actually how you used to listen to music. +WILL: [laughs] +ERIC: But you sort of had this really expansive vision. And it was a really exciting way to understand that there are ways to be involved in the technology ecosystem without necessarily being a software engineer. Because I tried my hand at that, and I wasn't anywhere close to being top of the class, let's put it that way. And so, I wanted to be involved in the industry but also kind of think about how I could play to whatever strengths I had. +And then the sort of window into venture capital sort of started to open in terms of my awareness of it. I ended up working at Morgan Stanley for a couple of years out of college, where I got to learn more about technology from a business lens. But I always knew I had an angle or a desire to become a venture capitalist. So got into the industry; it'll be 20 years ago this summer. And I've been fortunate enough to keep doing it for that period of time. So that's kind of the medium-length answer to how I got started [laughs] in the business. +ZACK: I don't have quite the story that Eric does there. [laughs] But venture capital was never on my radar. I went to college to be a programmer, and that's where I started out. My first real job was at Anheuser-Busch in Los Angeles, and go Lakers. +WILL: [laughs] +ZACK: Me and Eric have some LA routes [laughter], so that was a great job. I had a ton of fun. And I just got a call from a recruiter one day that a VC firm was looking for a job as an IT manager. I was very unqualified for the position, went through the interview process. It took like six months. I think I met everybody at the firm, got the job. And that was, like Eric, that was about 20 years ago now. And I have just been in the industry ever since. So it's a great place to be, and I have no plans on leaving. +WILL: Oh, that's amazing. I love it. So tell me this, beyond dollars invested...because honestly, when I think of venture capitalists, it is mostly about the money. Hey, how much money have you done? How much money have you sent in? What does that look like? But I don't think we ever cover the next step. What else is there? So beyond dollars, what does IVP do to help companies' portfolio? +ERIC: Capital is definitely part of it. It's venture capital, so let's be real. You can't ignore that part of it. But I do think that it is only a part of it because what I think sometimes people don't really think through...because the media in particular likes to write about the day a company goes public or if there's a big acquisition like it all just happened at that one moment, but that is so far from the truth. +I mean, the amount of work that entrepreneurs and people at startups put in to drive to those outcomes that sort of culminate in that moment is really one of the things I respect most and enjoy most to be part of as a venture capitalist. And so what our role in that can often be is actually quite varied because no two companies are the same. I mean, there are some common themes, but no two companies are the same. And so how we try and get involved is tailored to what a given company needs at a given point in time. +Now, some of the common threads might be working with companies to help build out their teams. We do a lot of that because, ultimately, the team is who's at a company every day. I mean, investors aren't there every day and frankly, if we are, probably something's gone wrong. +WILL: [laughs] +ERIC: That team is important. And we like to think about getting involved in high-leverage moments. And there are a number of different ones, and Zack is part of this too. So a high-leverage hire is probably someone at the C-level or VP-level because that person then recruits and builds out a team. It's different...not to say that individual contributors aren't also important, but we're trying to think about those key players, moments where we can help, I guess, in a biblical turn, teach people how to fish instead of fish for them. That's our mentality, and recruiting is part of it. +Sometimes these are partnerships that can drive significant revenue lines. Sometimes it's debating what a business model should be in a given company. A great example on some of these is at both Coinbase and Discord; there was debate around what the business models ought to look like. Coinbase is very transactional. We pushed them to sort of think through a recurring revenue component, some other services that they could have so that their revenue could be a little smoother and not just dependent on transaction volumes. +At Discord, they were thinking through raising money to start an in-house gaming studio. We kind of said, "You know, that's a really competitive industry, and the content creation costs just keep going up. How about a different model? Maybe we can think about a subscription service." And that became what drives the revenue today around buying advanced features for your private servers and things like that. +There are a lot of moments...unfortunately, sometimes our companies become targets of bad actors, which brings Zack back to the forefront. Part of the benefit of having a portfolio is we see a lot of these different incidents. And Zack is someone that we sort of unleash with our companies when they face some of these challenges, you know, I got a hack, or I have this going on, and Zack jumps in. You should talk about some of the situations that you've had to deal with. And the bat phone rings when those things happen, and we send them straight to Zack. +WILL: [laughs] +ZACK: Yeah, I mean, we definitely do everything we can. There definitely have been times where it's, all right; this happened to us; what do we do? How can we help this company? And I've really been deeply involved in security most of my career, and it's kind of where I wanted to go. And I pride myself on that. And we have great security here, and we try to instill the same in our portfolio companies. +And recently, we developed these jump guides, which is another way we're helping portfolio companies. So they're kind of like how-to lists. So there would be how to hire your first CFO, how to go IPO, that sort of stuff, and I just authored a couple, actually, that are about how to keep your company safe and how to keep your employees safe. And it's all just tips. It's nothing revolutionary, mind-blowing, but it's just stuff that every company should be doing to keep themselves safe. +And so that's really the message that we try to give to our portfolio companies. We definitely internalize it as well. I think really the key to good security is there's a partnership. There has to be a partnership between you with, the security team, and all the employees. You can have all the layers of defense you want. You can have your firewalls, your antivirus, et cetera, but if your employees don't understand the value of security and why they shouldn't click on that link or they shouldn't download that file, it's meaningless. +It's very important to instill that, just have open communication. And what I tell everybody at IVP is that security is in your hands. We're doing what we can, but it's in your hands. So, ultimately, it falls on them. And it's a scary time, you know, new stuff coming out all the time. But, yeah, we do our best to keep on top of it and our portfolio companies as well. +ERIC: Zack is being very modest. But if you take a step back, if you think about, you know, in any of our own lives, which there's a parallel, I think for companies, there are certain moments when you're facing a tough spot, and people that were there for you and helped you are the ones that are most memorable. And when there are good days, things are pretty easy. And those hard days are where we want to make sure that we're there for our companies. +And some of those hard days are in times like these where companies have to make some tough decisions around their cost structure because the environment has changed; some of these are, as Zack points out when they're facing a hack or a breach of some sort. And so, ideally, some of those you're preventing before they happen. But in the moment, Zack is a great ally and asset for a lot of our companies. +And some of these also happen on a day-to-day basis. It works great to have someone like Zack on our team. He can kick around and be a source for feedback for some product testing, which he does with a lot of companies that are in the portfolio. And actually, he does that when we're evaluating companies too, and sometimes they don't score so well on the Zack Willis meter. [laughter] And then we have productive feedback to give them to think about things as they refine what they're working on. +So it's one of those things where there are high-leverage moments, but we really focus on trying to be involved but also available. And again, this is repetitive to what I said earlier; no two companies are the same. And these are long-term partnerships. We want to make sure that we help them succeed, and that's what it's about. +ZACK: I agree, and availability for sure. It can be around the clock. You don't know when these things are going to happen. And definitely, we pride ourselves on that, on being available for our companies when they need us. +WILL: That's amazing. It sounds like maybe the secret sauce is your long-term relationship with the company. It's not just drop millions of dollars into the company and see you later. Hopefully, you sell out; whatever, you make money. We'll get it back. It's not the day-to-day, but when it gets hard when we can help you when we can support you. +And we kind of have that same mindset with thoughtbot. We don't just try to build software and say, "Hey, you're on your way." But, no, hey, can we help you hire developers, anyone to help you with this and make sure that it's not going to fall off as soon as we leave? But that long-term thing. So sometimes, when you're in a long-term game, it can get kind of messy. So, professionally speaking, what keeps you up at night? +ERIC: One of the challenges of being an investor is that you can never be too happy or too sad, particularly when we have a portfolio. So if you think about it, to your point about being involved, it's not just writing a check or investing and then say, "Here's the money; call me later." We're active partners. We take board seats in two-thirds of the companies that we invest in. And that's not a stat I throw out there to say it's a contest to see how many boards you're on. No, it's actually a reflection that when you're on a board, you have a responsibility to be helpful and involved and help steward the entire company on behalf of all shareholders. +And so that's part of being involved in a portfolio of 80 or 100 companies that are active right now. There are going to be some that are having good quarters and some that are having tougher quarters. And so, collectively, we try and be even-keeled as long as we're making forward progress. And Zack is a guy who runs sub three-hour marathons, but some miles are harder than others. And he can talk more about that. But there are going to be some periods in a company's journey that are harder than others. +And so we just try and make sure we're sort of focused in the right direction and ultimately that the right goal is in mind. And right now, probably what's topical is it's harder for companies to raise money at any scale. You see, this sort of capital markets have really reversed course, and this is by design with the Fed raising rates and trying to intentionally slow the economy down for a whole host of reasons we probably don't have to get into on this podcast, but it's working. +And what does that mean for our companies? It's harder to generate revenue. People are watching their budgets, whether they're consumers or enterprises, which then means that they need to watch their operating budgets. And that's why you've seen a lot of the layoffs that have happened across the technology sector, in particular over the last nine months. And it's not just startups, you know, it's Google announcing one of the biggest cuts that they've ever had in their history. Microsoft did that yesterday. +So it is a more challenging time, and it's something a lot of people in the industry hadn't been through because we've had the benefit of such a long bull market run. But for better or for worse, at this point in my career, I've seen it more than a few times. And so this is, I think, an area where we can be a guide partner, sometimes just a sounding board because it's not easy to make these decisions. +ZACK: First of all, I'll give thoughtbot a quick plug since you guys really helped us out. I guess this was about seven years ago now. We worked with you guys a couple years to get the first iteration of this system that we have that helps us...kind of part of our secret sauce that helps us find companies to invest in. So I'm very thankful for that. +And as far as what keeps me up at night, I mean, aside from my cat, and my dog, and my anxiety, [laughs] it's going back to what we talked about before; it's really security. Did we do everything? Are we staying on top of the latest threats? Are we helping out our companies enough? There was an interesting article that just came out a few days ago that talked about how PE companies and some VCs, private equity and venture capital, are requiring security audits of their firms before they invest in them. +And so before they'll make the acquisition, they'll run into an audit, and they'll say, "Okay, well, you're missing these things. We're not going to invest in you until you do these things, until you have two-factor authentication until you have this, until you have that." I think that's an interesting trend. For PE, it's a little bit of a bigger deal since they acquire the company. It's still a way that I believe that we can protect ourselves and our portfolio companies. It helps protect our reputation, helps protect their reputation, and it really gives us the chance to get in there at the beginning and say, "Hey, these things are missing. This is what you should focus on security-wise. +WILL: That's amazing, amazing. +MID-ROLL AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +WILL: I wanted to take a step back; when you mentioned Coinbase and Discord, and you said that you helped them set the direction going forward. Honestly, we may not even know those companies if their original plan would have gone forward. How much has your 43 years of experience helped guide that direction with Coinbase and Discord? +ERIC: You know, there's a saying that history doesn't repeat itself, but it often rhymes. And so I think that's probably the mentality that we try and take from our collective experience as a team that we try to bring to each company. And we meet as a team on Mondays and Thursdays, and it's a very broad meeting compared to most of the investment world in terms of who attends that meeting internally. And so we talk about companies that we're considering and contemplating. We talk about companies we've already invested in. +And I think one of our core cultural attributes that is a great strength is putting our best thinking against some of these problems. Again, when things are going well, those are short conversations. But when someone says, "Hey, you know, I'm working with this company, and we're kind of facing this issue. What do people think? What have we seen that's kind of analogous?" And that's where we get some of these ideas from. +So, for example, on the Coinbase example, we've been involved in a lot of marketplace businesses and exchange businesses. Those are great business models. And Coinbase has a fantastic management team. But thinking about this, this is pre-IPO and pre-direct listing, and when they want to be public one day, you know, there is a benefit to having a recurring revenue stream, a little more visibility. And so, how could we layer that on and make that, hopefully, over time, a bigger and bigger part of the business? +I think in Discord; we had some perspective that led us to invest in the company. In the first place, we've had a lot of success in gaming companies like Zynga, and Supercell, and Niantic, amongst others. We could see how passionate gamers are and, how they come in all different shapes, sizes, flavors, geographies, and how having a communication tool like Discord is really a benefit. +However, we also saw that the cost of producing games continues to go up. And if it's not kind of your full-time job, the likelihood you're going to nail something that a very competitive and discerning universe of gamers wants to play is probably not that high. So how do we think about harnessing that energy, and the talent, and the platform you build in a different way? So I'd say those are kind of some examples where we could think about things we've seen in our perspective but apply it to what's relevant for a specific company. +WILL: That's amazing. I love it. Yeah, I've heard the gaming business can be brutal. What IVP accomplishments are you most proud of? +ERIC: Well, maybe I'll break that into two parts. I think inside and outside the firm; I'm really proud of the team that we've built. And when I joined the firm 11 years ago, we were probably 20 people, 25 people in total. Now we're 65 people. And that doesn't seem like a lot in comparison to big tech companies or hyper-growth startups. But in a business-like venture capital, really what we're doing in addition to providing capital, internally, it's a lot of discussion, decision-making, ideas, thinking. That is hard to do the way that we do it if we get too big. +And that goes back to the size of our Monday meetings, which is rather large and includes a wide representation of the firm. But I'm really proud of the team that we've built. I'm really proud of the capabilities that we've enhanced on the technology side. Really, Zack drove a lot of this in the time that he's been with the firm, and we're leaps and bounds ahead of where we were with your help as well. I think Zack was alluding to what we think is one of our secret weapons, our early detection system, so we're really proud of that. +And then I'd say externally, or with our companies, we've had 131 of them go public. We had 15 of them do that in 2021, none did in '22. So the market's changed quite a bit. Those are accomplishments that, like I pointed to previously, they're milestone events. The pride comes in knowing that these companies that we've worked with have put in the work over years, at minimum, years, to get to that point. And that gives, I think, all of us a collective sense of accomplishment. +WILL: That's amazing. +ZACK: Yeah, I definitely agree with that. In my, I guess, almost eight years here now, we've grown a ton in our hiring. Our team is amazing. It's really the reason why I'm still here, why our turnover is basically nothing. We hire great people. And during that time, we've raised some great funds. We've invested in amazing companies. We've helped out a lot of entrepreneurs. It's just across the board. I've been in this industry a while. I feel like IVP is definitely a unique VC firm, and I'm proud of what we do. +WILL: That's amazing. One of my favorite questions that I like to ask on the podcast is, if you could go back in time at the very beginning and give yourself advice, what would it be? +ZACK: For me, it's stay relevant, I think. And to me, it just means being more involved in everything. Put yourself out there. Be bold. Learn about different areas in the company. Try to attend different meetings. Talk to different departments, and really just make yourself visible. When you do that, I think the rest just kind of falls into place. And it took me quite a while in my career to really realize that. And it's still tough now, but it's something that I'm always trying to do. Historically, I'm a very shy person, but just putting myself out there and doing the best I can in any situation that I find myself in. +ERIC: I think a couple of things, balance, and patience are probably two things, not trying to force it. So I think there's a lot of Yoda Jedi wisdom that probably would be useful. So if you're sort of...when I was first starting out, you're younger and impetuous at times and want to make things happen because you have such a strong desire to try and do something the right way and make a positive impact. But the hardest thing to learn is sometimes the right thing to do is actually to do nothing in the investment world. That is a hard thing for a lot of motivated, energetic Type A people to do, and yet it's sometimes the exact right thing you should be doing. +So I think it's hard to hear that when you're starting out in your 20s. And now that I'm a little older than that, [laughs] I think I can look back and appreciate it. But that's probably, as I think through that question, maybe the best piece of advice. And yet, like a lot of things, we were all taught while we were younger from people who had more experience, or age, or wisdom, or whatever, there are just some things you hear, and it's not real until you've kind of lived it. +And sometimes, in some of those dimensions, you have to make your mistakes before you appreciate them. You guys probably had this experience writing code. Like, there's got to be...I could just do it this way, and it'd be fast. And then you realize it wasn't really that sound or forward-compatible or something. You had to go back and rewrite your architecture, and that's a pain. So I think it's that same approach, thinking with balance. +ZACK: Just to add to what I was saying before, too, I think one of the things also would have been, you know, find something you're passionate about and do it every day. That wasn't the case early on in my career, and I turned to running, and I turned to working out. And I do something every morning, and that really, really grounds me. It helps me focus helps me plan out the day. And it's really just my time that's crucial. And whether it's running, whether it's meditating but just taking some time for yourself, you know, energize yourself, take care of yourself. And that goes a long way in the workplace as well. +WILL: I love it, yeah. That's why it was one of my favorite questions, just learning from your mistakes, learning from what you did in the past. It's amazing. So I love that. +ERIC: Yeah, I mean, since Zack brought up the Lakers, [laughter] and this isn't the Lakers, but it's basketball-related, you guys might remember this old Michael Jordan commercial. He talks about I've missed this many free throws and this many shots and something like, my team has trusted me 80 times to win the game in the fourth quarter, and I've missed. The tagline is something like, I have failed over and over and over and over again, and that is why I succeed. There's definitely some of that in the venture business and the advice I think we could all give to our younger selves. +WILL: Oh, yeah, getting back up. Keep going, yeah. +ERIC: The same thing with Dwyane Wade commercial, you know, get knocked down eight times, get up nine, kind of the same thing. +WILL: Love it. What's something you would love the audience to know about IVP? +ZACK: I think our team and just the way we hire. We hire amazing people. They're smart. They're kind. They're low ego. They're thoughtful. I'm not going to say it's completely different from others, but it is, in my experience, a different culture. And we all get along great. We mesh really well, and we continue to hire great. We hired almost 20 People in the last year and a half. That's a lot, but we still manage to maintain the same level of talent. We help our portfolio companies do hires as well. I think that's one of our benefits. We know talent, and we know it internally, and we know it externally. And it's just a great culture to be a part of. +WILL: Amazing. +ERIC: The thing to think about with us is if you're an entrepreneur building a company, it's tough. Sometimes it's really lonely. We aspire to be partners with entrepreneurs in good times and in bad. We're not the flashiest ones out there. We're not trying to see who has the most Twitter followers. But when you need something, we're there. I think that is something people lost sight of or didn't care as much about in the last couple of years when things were easy. They're not so easy now. +And we take pride in these long-term partnerships, which is why we're highly selective in the number of companies we invest in every year. We're never going to be the most active, but we put a lot of our work, time, effort, energy, mental capacity alongside the capital that we bring to our companies. And I think that's been a great formula for us over our history, and it'll continue to be. +WILL: That's amazing. To summarize, I know each VC firm has their own DNA. What makes IVP different from its competitors? +ERIC: I'd say a couple of things. And again, I've only worked at two firms, and so there are a lot of firms I haven't worked at, so I don't want to attempt to speak too much into the intricacies of how they work. But I'd say inside our four walls, our culture of teamwork and collective outcome and benefit and effort is really special. Every investment we approach has access to the entire firm's resources and capabilities. And I think it's really different. +I mean, we're very happy to partner with one another internally, help each other out, help companies that we might not be mostly directly involved with for the benefit of our firm, and our investors, and the companies that we work with. And I think that is something that a lot of firms talk about. I don't think it's always true at a lot of firms. And so, for us, it's really special and something that we've worked really hard to build as a culture, and keep as a culture, and preserve every day. +Because I think it's easy to feel like you're on an island in this business at times, but we want to make sure that we feel that connectivity as a team. For our entrepreneurs, we are here to work with you and support you, probably not daily because I think, again, that goes back to having the right people, but weekly, monthly, quarterly, over years, that's our approach. We believe great things take time to build. +WILL: That's amazing. Zack, I want to summarize this portion with you. How do you keep your firm and your employees safe from online threats? Do you share that with your portfolio companies? Because I know especially in the tech world and in the news, you're hearing about those scammers, those threats, summarize it for me, like, how do you do that? +ZACK: There are a lot of pieces, of course. And as I was talking about before, I think the most important thing is really just getting buy-in from the whole firm. Me and my team we definitely try out the latest products, get the top-of-the-line security stuff, and really make sure that that stack is solid and that we're monitoring everything and getting the buy-in. +So it's a lot of training. It's keeping them up to date. It's instilling the messages. Like, when I first started here, I did a security training. The firm had never done a security training. We were pretty light on security at the time. And so, I tried to make the presentation fun and a little scary. So I brought in the FBI. +WILL: Wow. +ZACK: The FBI scared everybody a little bit. And then I came on and just talked about what to do and not to do. And I actually had a song composed [laughs] about security and what employees should be doing. It was just a funny jingle that people still sing today. [laughter] But yeah, I think just making it memorable. And we have a Slack channel called Tech Talks. I'm always updating the latest information on there on different breaches and different attacks we're seeing, and what we can do to prevent that, and what our employers should be doing. And absolutely, that extends to our portfolio companies. +And those jump guides, I believe they're out now with all my technical recommendations. We use those internally. I definitely gave those to the firm but also to our portfolio companies. And there's some interesting stuff in there that you may not think of, like removing your information from the internet. Like, get a company, Optery, something like that, which we pay for for all our employees, and it scrubs the internet of your information, and that's great. It cuts back on phishing, spam calls, you know, just going beyond too. +We also have this product that we use that monitors employees' personal email addresses for breaches. So we're not just caring about IVP. We're also caring about what someone's doing in their personal life because that can also lead to a breach of IVP. So yeah, so someone's Gmail account gets exposed, and we're going to know about it, and we can let them know. +And then, really, it's just staying on top of things. One of the things we just did, you know, passwords are the worst, everyone knows that, and so we just rolled out this product called Beyond Identity. And it's a password list provider. The difference between them and other password list providers is they offer a layer of security on top of the password list. So it's not just convenient; it's also added security, which was always my worry about going password list; it's just more convenient and less secure. But this company does it right. And it's things like that, just staying ahead of it. All right, passwords are a problem? Let's get rid of passwords. Following those trends and keeping up to date. +ERIC: I mean, Zack is a very tough critic. So he's given a couple of shout-outs which means he really likes those products, and I'm glad that we have them. And I very much remember that training session that he did for us or organized. And we did a refresh of it a couple of years ago. I think we've done at least two of them now. It sounds really boring [laughs], and maybe I'm just kind of a geek in that way, but that was one of the most memorable training sessions that I've ever been part of in my time at IVP. +And we had Zack's buddy from the FBI come in and give kind of an overview of all the vulnerabilities that they see, and that's obviously very, very cutting edge. And they had some footage of people sort of passing off USB sticks here and there in subways in New York City. So you can kind of see them go in in one entrance. They got a different shot of the camera while they're on the tracks, and they go their separate ways. +I mean, this is straight out of some spy stuff, and it's happening. It makes you think...that's an extreme; we know we're talking about sort of most likely state-sponsored bad guys, but the ones that are commercially oriented, I think maybe they're not as frequent...they're more frequent, and so we have to be on guard all the time, especially as a firm that does have access to and move around a lot of money. +I'm geeking out because I learned a lot from it. And Zack also likes to keep all of us on our toes with a lot of sort of...it's like the security equivalent of pop quizzes. He's always planting fake links and stuff to see who clicks on them. [laughter] And then he's pretty kind because he doesn't out you by name when we talk about them on Mondays. [laughter] +But he says something like, "Hey, you know, there are 65 people who got this test, and the good news is that 50 of you passed. The bad news is that 15 people didn't, which means that could have resulted in a lot of different intrusions. So try and be better," so stuff like that. And it is actually kind of fun and reminds us that while we're a venture capital firm, we are people that comprise the firm just like everybody else, and we got to be vigilant. +ZACK: That's a good point, too, just about the FBI and them showing us all the crazy stuff. I mean, one of the things that they really tried to drill in, and I still talk to my friend in the FBI today, is VCs are a target. VCs are absolutely a target. And it's not necessarily what you have; it's what you're perceived to have. +And so, okay, they probably think we have a lot of IP and a lot of things like that that we don't necessarily have, but they're still going to try to get in. They're still going to try to hack their way in. And I think that's important, too, just instilling that message like, yeah, we're a VC firm. We're a target; you need to understand that; here's why. And that's true for most firms. We're not special. But it's definitely something you need to instill. +ERIC: Oh, Zack's probably going to cringe if he hears me say this, but I definitely take the point that you know, you don't have to be faster than the bear; you just got to be faster than the next guy. So you just have [laughter] to be more secure and more of a pain to try and penetrate, and they'll move on to somebody else. +ZACK: I mean, that's totally true. That's a big part of security. If they come knocking on your door, and you have that deadbolt, and the next house doesn't, then yeah, they're going to go the easier path. So that's absolutely true, Eric. +WILL: Well, you're doing something right because he remembered the training, and he enjoys it. [laughter] You're doing something right. +ERIC: I guess I'm just weird in that way, but it was actually kind of fun. +WILL: Well, thank you, Eric and Zack, for being on here. It was amazing. Where can the audience find more information about you, connect with you? +ERIC: www.ivp.com is probably the best place. It sounds so old school, but it's the most relevant. Follow us on Twitter, LinkedIn. But I've had a great time talking with you. This has been a lot of fun. Hopefully, you got some nuggets for your audience, too. +ZACK: Yeah, I agree. Thank you very much for having us. This was a lot of fun. +WILL: Yeah, I've really enjoyed it, so thank you. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guests: Eric Liaw and Zack Willis. + + + Eric Liaw and Zack Willis are part of IVP, a leading venture firm with a 43-year history of partnering with entrepreneurs who are undaunted on the path to innovation.

+ +

Will talks to Eric and Zack about what has made IVP so long-lasting in the Venture Capital industry, how they help companies' portfolios, and the accomplishments they are most proud of.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Eric Liaw and Zack Willis, who are part of IVP, a leading venture firm with a 43-year history of partnering with entrepreneurs who are undaunted on the path to innovation. Zack, Eric, thank you for joining me.

+ +

ERIC: Thanks, Will. It's great to be here, really appreciate it. And I got to say, as the Giant Robot Podcast, as a kid growing up, Transformers were my favorite toys. So this may be the closest I ever get to being a Transformer by being part of Giant Robots, so thank you for the opportunity.

+ +

[laughter]

+ +

WILL: Love it. We love robots here, so it's perfect. All right, let's start here. For folks who may not know, tell us about IVP and what's on deck for 2023.

+ +

ERIC: Well, you gave a great intro, so let me just add to that a little bit. You know, we're really proud of our history and our firm. We've been around since 1980. So we're one of the sort of original Silicon Valley venture firms. But when I speak about the firm in that context, I don't think it does justice to how the firm has expanded over the years and how our investment activity now encompasses not only the Bay Area but major U.S. markets like New York and LA. We have investments in Canada, Australia, and a number in Western and Central Europe as well.

+ +

And the common theme for us is that we're focused on working with entrepreneurs who, as you pointed out, are undaunted as they innovate and are pursuing dreams to create companies that will become recognizable in households and companies across the world, not just today but tomorrow as well. So that's really what IVP is all about. And it's what we're looking forward to in 2023 despite obviously the fact that the world is a little more challenging these days, a little bit more uncertain in, particular in the venture category.

+ +

But we're really excited about the things that we're working on. We invested a lot in our team over a number of years. And, believe it or not, despite what you might read in headlines around venture activity, we are very much open for business in 2023 because we think that great entrepreneurs and great ideas come together at all times, regardless of whether the stock market is up or down. And our job is to find them, work with them, and become partners for three, four, or five, six, seven years, sometimes longer than that. So really, there's no bad time to start a company and get to know venture investors like us.

+ +

WILL: Yeah, definitely. Your company has been around for 43 years. Can you kind of tell me what has made you last that long, for 43 years? That's a long time to be in the venture capitalist world, especially before it was popular and fun.

+ +

ERIC: You know, it's a great question. I've been at the firm for 11 years now. So a lot of the credit goes to people that...our founder, Reid Dennis, who started the firm. He's in his 90s now, so he has since retired, but a lot of credit goes to people that came before me and before Zack. And I think that's a common theme for any kind of organization or institution, no pun intended, because that's what the I in IVP stands for. But it goes to that sort of common thread. You have to evolve, especially in technology.

+ +

The technology markets that were successful for IVP in the early '80s that's not really cutting-edge venture anymore. As an example, Seagate was one of our first investments ever when people weren't sure that personal hard drive technology would actually work or whether or not they're getting market demand. I mean, who would actually want storage themselves carried around with them at all times? And now, think about how much storage you have in your pocket. It's pretty gnarly to think about how much technology has advanced.

+ +

But if you kept only thinking about, okay, I'm going to invest in the next hard drive, you would have really gotten stuck after that. And obviously, the things that have come since out of the minds of technology entrepreneurs have far exceeded what people at the time of the founding of IVP would have thought was possible. So I think that evolution is really important, staying fresh; technology trends evolve. In the early days of IVP and in Silicon Valley, there was a saying among venture capitalists that if you couldn't drive to the board meeting within 30 minutes, you didn't make the investment. That's just not true anymore. There's no way.

+ +

WILL: [laughs]

+ +

ERIC: And I think COVID has certainly proved that because investments are being made around the world. Now, maybe in hindsight, that was too fast. There was too much capital flowing around just to resume dating if you will. But the underlying theme is evolution, and I think it's teamwork. Because our founder, Reid, wanted the organization and firm to thrive well beyond his days as an active investor, and you can only do that with building a team that's multigenerational. And I'm proud and lucky to be part of an organization that's done that.

+ +

WILL: Awesome, awesome. Well, tell me about you. Tell me more about your background. How did you get started in the VC world?

+ +

ERIC: You know, child of immigrants who came to the United States in the '70s from Taiwan. They met in New York City. Like many other people, moved to the burbs and they started a family. So I was born in New Jersey. My brother and I were both born there. I moved to LA when I was 12. I lived in Southern California until I went to college. Had the miraculous fortune to somehow get into Stanford and went to school sort of in the late '90s into the early 2000s, as good fortune would have it, in the middle of the internet bubble.

+ +

So I had kind of a front-row seat to that era of technology, innovation not knowing anything about tech when I showed up in Palo Alto in the fall of '96. I got exposed to venture capital while I was in school. There was a pretty memorable, at least for me, speech that I went to. John Doerr, now retired from Kleiner Perkins, was on stage in the engineering auditorium and gave a speech about how Amazon was going to change the world. And this was probably in the fall of '98.

+ +

And he was right. I just think maybe the timeframe was slightly off, but he was right. I mean, at the time, it was books and CDs, and to some of our listeners, CDs was actually how you used to listen to music.

+ +

WILL: [laughs]

+ +

ERIC: But you sort of had this really expansive vision. And it was a really exciting way to understand that there are ways to be involved in the technology ecosystem without necessarily being a software engineer. Because I tried my hand at that, and I wasn't anywhere close to being top of the class, let's put it that way. And so, I wanted to be involved in the industry but also kind of think about how I could play to whatever strengths I had.

+ +

And then the sort of window into venture capital sort of started to open in terms of my awareness of it. I ended up working at Morgan Stanley for a couple of years out of college, where I got to learn more about technology from a business lens. But I always knew I had an angle or a desire to become a venture capitalist. So got into the industry; it'll be 20 years ago this summer. And I've been fortunate enough to keep doing it for that period of time. So that's kind of the medium-length answer to how I got started [laughs] in the business.

+ +

ZACK: I don't have quite the story that Eric does there. [laughs] But venture capital was never on my radar. I went to college to be a programmer, and that's where I started out. My first real job was at Anheuser-Busch in Los Angeles, and go Lakers.

+ +

WILL: [laughs]

+ +

ZACK: Me and Eric have some LA routes [laughter], so that was a great job. I had a ton of fun. And I just got a call from a recruiter one day that a VC firm was looking for a job as an IT manager. I was very unqualified for the position, went through the interview process. It took like six months. I think I met everybody at the firm, got the job. And that was, like Eric, that was about 20 years ago now. And I have just been in the industry ever since. So it's a great place to be, and I have no plans on leaving.

+ +

WILL: Oh, that's amazing. I love it. So tell me this, beyond dollars invested...because honestly, when I think of venture capitalists, it is mostly about the money. Hey, how much money have you done? How much money have you sent in? What does that look like? But I don't think we ever cover the next step. What else is there? So beyond dollars, what does IVP do to help companies' portfolio?

+ +

ERIC: Capital is definitely part of it. It's venture capital, so let's be real. You can't ignore that part of it. But I do think that it is only a part of it because what I think sometimes people don't really think through...because the media in particular likes to write about the day a company goes public or if there's a big acquisition like it all just happened at that one moment, but that is so far from the truth.

+ +

I mean, the amount of work that entrepreneurs and people at startups put in to drive to those outcomes that sort of culminate in that moment is really one of the things I respect most and enjoy most to be part of as a venture capitalist. And so what our role in that can often be is actually quite varied because no two companies are the same. I mean, there are some common themes, but no two companies are the same. And so how we try and get involved is tailored to what a given company needs at a given point in time.

+ +

Now, some of the common threads might be working with companies to help build out their teams. We do a lot of that because, ultimately, the team is who's at a company every day. I mean, investors aren't there every day and frankly, if we are, probably something's gone wrong.

+ +

WILL: [laughs]

+ +

ERIC: That team is important. And we like to think about getting involved in high-leverage moments. And there are a number of different ones, and Zack is part of this too. So a high-leverage hire is probably someone at the C-level or VP-level because that person then recruits and builds out a team. It's different...not to say that individual contributors aren't also important, but we're trying to think about those key players, moments where we can help, I guess, in a biblical turn, teach people how to fish instead of fish for them. That's our mentality, and recruiting is part of it.

+ +

Sometimes these are partnerships that can drive significant revenue lines. Sometimes it's debating what a business model should be in a given company. A great example on some of these is at both Coinbase and Discord; there was debate around what the business models ought to look like. Coinbase is very transactional. We pushed them to sort of think through a recurring revenue component, some other services that they could have so that their revenue could be a little smoother and not just dependent on transaction volumes.

+ +

At Discord, they were thinking through raising money to start an in-house gaming studio. We kind of said, "You know, that's a really competitive industry, and the content creation costs just keep going up. How about a different model? Maybe we can think about a subscription service." And that became what drives the revenue today around buying advanced features for your private servers and things like that.

+ +

There are a lot of moments...unfortunately, sometimes our companies become targets of bad actors, which brings Zack back to the forefront. Part of the benefit of having a portfolio is we see a lot of these different incidents. And Zack is someone that we sort of unleash with our companies when they face some of these challenges, you know, I got a hack, or I have this going on, and Zack jumps in. You should talk about some of the situations that you've had to deal with. And the bat phone rings when those things happen, and we send them straight to Zack.

+ +

WILL: [laughs]

+ +

ZACK: Yeah, I mean, we definitely do everything we can. There definitely have been times where it's, all right; this happened to us; what do we do? How can we help this company? And I've really been deeply involved in security most of my career, and it's kind of where I wanted to go. And I pride myself on that. And we have great security here, and we try to instill the same in our portfolio companies.

+ +

And recently, we developed these jump guides, which is another way we're helping portfolio companies. So they're kind of like how-to lists. So there would be how to hire your first CFO, how to go IPO, that sort of stuff, and I just authored a couple, actually, that are about how to keep your company safe and how to keep your employees safe. And it's all just tips. It's nothing revolutionary, mind-blowing, but it's just stuff that every company should be doing to keep themselves safe.

+ +

And so that's really the message that we try to give to our portfolio companies. We definitely internalize it as well. I think really the key to good security is there's a partnership. There has to be a partnership between you with, the security team, and all the employees. You can have all the layers of defense you want. You can have your firewalls, your antivirus, et cetera, but if your employees don't understand the value of security and why they shouldn't click on that link or they shouldn't download that file, it's meaningless.

+ +

It's very important to instill that, just have open communication. And what I tell everybody at IVP is that security is in your hands. We're doing what we can, but it's in your hands. So, ultimately, it falls on them. And it's a scary time, you know, new stuff coming out all the time. But, yeah, we do our best to keep on top of it and our portfolio companies as well.

+ +

ERIC: Zack is being very modest. But if you take a step back, if you think about, you know, in any of our own lives, which there's a parallel, I think for companies, there are certain moments when you're facing a tough spot, and people that were there for you and helped you are the ones that are most memorable. And when there are good days, things are pretty easy. And those hard days are where we want to make sure that we're there for our companies.

+ +

And some of those hard days are in times like these where companies have to make some tough decisions around their cost structure because the environment has changed; some of these are, as Zack points out when they're facing a hack or a breach of some sort. And so, ideally, some of those you're preventing before they happen. But in the moment, Zack is a great ally and asset for a lot of our companies.

+ +

And some of these also happen on a day-to-day basis. It works great to have someone like Zack on our team. He can kick around and be a source for feedback for some product testing, which he does with a lot of companies that are in the portfolio. And actually, he does that when we're evaluating companies too, and sometimes they don't score so well on the Zack Willis meter. [laughter] And then we have productive feedback to give them to think about things as they refine what they're working on.

+ +

So it's one of those things where there are high-leverage moments, but we really focus on trying to be involved but also available. And again, this is repetitive to what I said earlier; no two companies are the same. And these are long-term partnerships. We want to make sure that we help them succeed, and that's what it's about.

+ +

ZACK: I agree, and availability for sure. It can be around the clock. You don't know when these things are going to happen. And definitely, we pride ourselves on that, on being available for our companies when they need us.

+ +

WILL: That's amazing. It sounds like maybe the secret sauce is your long-term relationship with the company. It's not just drop millions of dollars into the company and see you later. Hopefully, you sell out; whatever, you make money. We'll get it back. It's not the day-to-day, but when it gets hard when we can help you when we can support you.

+ +

And we kind of have that same mindset with thoughtbot. We don't just try to build software and say, "Hey, you're on your way." But, no, hey, can we help you hire developers, anyone to help you with this and make sure that it's not going to fall off as soon as we leave? But that long-term thing. So sometimes, when you're in a long-term game, it can get kind of messy. So, professionally speaking, what keeps you up at night?

+ +

ERIC: One of the challenges of being an investor is that you can never be too happy or too sad, particularly when we have a portfolio. So if you think about it, to your point about being involved, it's not just writing a check or investing and then say, "Here's the money; call me later." We're active partners. We take board seats in two-thirds of the companies that we invest in. And that's not a stat I throw out there to say it's a contest to see how many boards you're on. No, it's actually a reflection that when you're on a board, you have a responsibility to be helpful and involved and help steward the entire company on behalf of all shareholders.

+ +

And so that's part of being involved in a portfolio of 80 or 100 companies that are active right now. There are going to be some that are having good quarters and some that are having tougher quarters. And so, collectively, we try and be even-keeled as long as we're making forward progress. And Zack is a guy who runs sub three-hour marathons, but some miles are harder than others. And he can talk more about that. But there are going to be some periods in a company's journey that are harder than others.

+ +

And so we just try and make sure we're sort of focused in the right direction and ultimately that the right goal is in mind. And right now, probably what's topical is it's harder for companies to raise money at any scale. You see, this sort of capital markets have really reversed course, and this is by design with the Fed raising rates and trying to intentionally slow the economy down for a whole host of reasons we probably don't have to get into on this podcast, but it's working.

+ +

And what does that mean for our companies? It's harder to generate revenue. People are watching their budgets, whether they're consumers or enterprises, which then means that they need to watch their operating budgets. And that's why you've seen a lot of the layoffs that have happened across the technology sector, in particular over the last nine months. And it's not just startups, you know, it's Google announcing one of the biggest cuts that they've ever had in their history. Microsoft did that yesterday.

+ +

So it is a more challenging time, and it's something a lot of people in the industry hadn't been through because we've had the benefit of such a long bull market run. But for better or for worse, at this point in my career, I've seen it more than a few times. And so this is, I think, an area where we can be a guide partner, sometimes just a sounding board because it's not easy to make these decisions.

+ +

ZACK: First of all, I'll give thoughtbot a quick plug since you guys really helped us out. I guess this was about seven years ago now. We worked with you guys a couple years to get the first iteration of this system that we have that helps us...kind of part of our secret sauce that helps us find companies to invest in. So I'm very thankful for that.

+ +

And as far as what keeps me up at night, I mean, aside from my cat, and my dog, and my anxiety, [laughs] it's going back to what we talked about before; it's really security. Did we do everything? Are we staying on top of the latest threats? Are we helping out our companies enough? There was an interesting article that just came out a few days ago that talked about how PE companies and some VCs, private equity and venture capital, are requiring security audits of their firms before they invest in them.

+ +

And so before they'll make the acquisition, they'll run into an audit, and they'll say, "Okay, well, you're missing these things. We're not going to invest in you until you do these things, until you have two-factor authentication until you have this, until you have that." I think that's an interesting trend. For PE, it's a little bit of a bigger deal since they acquire the company. It's still a way that I believe that we can protect ourselves and our portfolio companies. It helps protect our reputation, helps protect their reputation, and it really gives us the chance to get in there at the beginning and say, "Hey, these things are missing. This is what you should focus on security-wise.

+ +

WILL: That's amazing, amazing.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

WILL: I wanted to take a step back; when you mentioned Coinbase and Discord, and you said that you helped them set the direction going forward. Honestly, we may not even know those companies if their original plan would have gone forward. How much has your 43 years of experience helped guide that direction with Coinbase and Discord?

+ +

ERIC: You know, there's a saying that history doesn't repeat itself, but it often rhymes. And so I think that's probably the mentality that we try and take from our collective experience as a team that we try to bring to each company. And we meet as a team on Mondays and Thursdays, and it's a very broad meeting compared to most of the investment world in terms of who attends that meeting internally. And so we talk about companies that we're considering and contemplating. We talk about companies we've already invested in.

+ +

And I think one of our core cultural attributes that is a great strength is putting our best thinking against some of these problems. Again, when things are going well, those are short conversations. But when someone says, "Hey, you know, I'm working with this company, and we're kind of facing this issue. What do people think? What have we seen that's kind of analogous?" And that's where we get some of these ideas from.

+ +

So, for example, on the Coinbase example, we've been involved in a lot of marketplace businesses and exchange businesses. Those are great business models. And Coinbase has a fantastic management team. But thinking about this, this is pre-IPO and pre-direct listing, and when they want to be public one day, you know, there is a benefit to having a recurring revenue stream, a little more visibility. And so, how could we layer that on and make that, hopefully, over time, a bigger and bigger part of the business?

+ +

I think in Discord; we had some perspective that led us to invest in the company. In the first place, we've had a lot of success in gaming companies like Zynga, and Supercell, and Niantic, amongst others. We could see how passionate gamers are and, how they come in all different shapes, sizes, flavors, geographies, and how having a communication tool like Discord is really a benefit.

+ +

However, we also saw that the cost of producing games continues to go up. And if it's not kind of your full-time job, the likelihood you're going to nail something that a very competitive and discerning universe of gamers wants to play is probably not that high. So how do we think about harnessing that energy, and the talent, and the platform you build in a different way? So I'd say those are kind of some examples where we could think about things we've seen in our perspective but apply it to what's relevant for a specific company.

+ +

WILL: That's amazing. I love it. Yeah, I've heard the gaming business can be brutal. What IVP accomplishments are you most proud of?

+ +

ERIC: Well, maybe I'll break that into two parts. I think inside and outside the firm; I'm really proud of the team that we've built. And when I joined the firm 11 years ago, we were probably 20 people, 25 people in total. Now we're 65 people. And that doesn't seem like a lot in comparison to big tech companies or hyper-growth startups. But in a business-like venture capital, really what we're doing in addition to providing capital, internally, it's a lot of discussion, decision-making, ideas, thinking. That is hard to do the way that we do it if we get too big.

+ +

And that goes back to the size of our Monday meetings, which is rather large and includes a wide representation of the firm. But I'm really proud of the team that we've built. I'm really proud of the capabilities that we've enhanced on the technology side. Really, Zack drove a lot of this in the time that he's been with the firm, and we're leaps and bounds ahead of where we were with your help as well. I think Zack was alluding to what we think is one of our secret weapons, our early detection system, so we're really proud of that.

+ +

And then I'd say externally, or with our companies, we've had 131 of them go public. We had 15 of them do that in 2021, none did in '22. So the market's changed quite a bit. Those are accomplishments that, like I pointed to previously, they're milestone events. The pride comes in knowing that these companies that we've worked with have put in the work over years, at minimum, years, to get to that point. And that gives, I think, all of us a collective sense of accomplishment.

+ +

WILL: That's amazing.

+ +

ZACK: Yeah, I definitely agree with that. In my, I guess, almost eight years here now, we've grown a ton in our hiring. Our team is amazing. It's really the reason why I'm still here, why our turnover is basically nothing. We hire great people. And during that time, we've raised some great funds. We've invested in amazing companies. We've helped out a lot of entrepreneurs. It's just across the board. I've been in this industry a while. I feel like IVP is definitely a unique VC firm, and I'm proud of what we do.

+ +

WILL: That's amazing. One of my favorite questions that I like to ask on the podcast is, if you could go back in time at the very beginning and give yourself advice, what would it be?

+ +

ZACK: For me, it's stay relevant, I think. And to me, it just means being more involved in everything. Put yourself out there. Be bold. Learn about different areas in the company. Try to attend different meetings. Talk to different departments, and really just make yourself visible. When you do that, I think the rest just kind of falls into place. And it took me quite a while in my career to really realize that. And it's still tough now, but it's something that I'm always trying to do. Historically, I'm a very shy person, but just putting myself out there and doing the best I can in any situation that I find myself in.

+ +

ERIC: I think a couple of things, balance, and patience are probably two things, not trying to force it. So I think there's a lot of Yoda Jedi wisdom that probably would be useful. So if you're sort of...when I was first starting out, you're younger and impetuous at times and want to make things happen because you have such a strong desire to try and do something the right way and make a positive impact. But the hardest thing to learn is sometimes the right thing to do is actually to do nothing in the investment world. That is a hard thing for a lot of motivated, energetic Type A people to do, and yet it's sometimes the exact right thing you should be doing.

+ +

So I think it's hard to hear that when you're starting out in your 20s. And now that I'm a little older than that, [laughs] I think I can look back and appreciate it. But that's probably, as I think through that question, maybe the best piece of advice. And yet, like a lot of things, we were all taught while we were younger from people who had more experience, or age, or wisdom, or whatever, there are just some things you hear, and it's not real until you've kind of lived it.

+ +

And sometimes, in some of those dimensions, you have to make your mistakes before you appreciate them. You guys probably had this experience writing code. Like, there's got to be...I could just do it this way, and it'd be fast. And then you realize it wasn't really that sound or forward-compatible or something. You had to go back and rewrite your architecture, and that's a pain. So I think it's that same approach, thinking with balance.

+ +

ZACK: Just to add to what I was saying before, too, I think one of the things also would have been, you know, find something you're passionate about and do it every day. That wasn't the case early on in my career, and I turned to running, and I turned to working out. And I do something every morning, and that really, really grounds me. It helps me focus helps me plan out the day. And it's really just my time that's crucial. And whether it's running, whether it's meditating but just taking some time for yourself, you know, energize yourself, take care of yourself. And that goes a long way in the workplace as well.

+ +

WILL: I love it, yeah. That's why it was one of my favorite questions, just learning from your mistakes, learning from what you did in the past. It's amazing. So I love that.

+ +

ERIC: Yeah, I mean, since Zack brought up the Lakers, [laughter] and this isn't the Lakers, but it's basketball-related, you guys might remember this old Michael Jordan commercial. He talks about I've missed this many free throws and this many shots and something like, my team has trusted me 80 times to win the game in the fourth quarter, and I've missed. The tagline is something like, I have failed over and over and over and over again, and that is why I succeed. There's definitely some of that in the venture business and the advice I think we could all give to our younger selves.

+ +

WILL: Oh, yeah, getting back up. Keep going, yeah.

+ +

ERIC: The same thing with Dwyane Wade commercial, you know, get knocked down eight times, get up nine, kind of the same thing.

+ +

WILL: Love it. What's something you would love the audience to know about IVP?

+ +

ZACK: I think our team and just the way we hire. We hire amazing people. They're smart. They're kind. They're low ego. They're thoughtful. I'm not going to say it's completely different from others, but it is, in my experience, a different culture. And we all get along great. We mesh really well, and we continue to hire great. We hired almost 20 People in the last year and a half. That's a lot, but we still manage to maintain the same level of talent. We help our portfolio companies do hires as well. I think that's one of our benefits. We know talent, and we know it internally, and we know it externally. And it's just a great culture to be a part of.

+ +

WILL: Amazing.

+ +

ERIC: The thing to think about with us is if you're an entrepreneur building a company, it's tough. Sometimes it's really lonely. We aspire to be partners with entrepreneurs in good times and in bad. We're not the flashiest ones out there. We're not trying to see who has the most Twitter followers. But when you need something, we're there. I think that is something people lost sight of or didn't care as much about in the last couple of years when things were easy. They're not so easy now.

+ +

And we take pride in these long-term partnerships, which is why we're highly selective in the number of companies we invest in every year. We're never going to be the most active, but we put a lot of our work, time, effort, energy, mental capacity alongside the capital that we bring to our companies. And I think that's been a great formula for us over our history, and it'll continue to be.

+ +

WILL: That's amazing. To summarize, I know each VC firm has their own DNA. What makes IVP different from its competitors?

+ +

ERIC: I'd say a couple of things. And again, I've only worked at two firms, and so there are a lot of firms I haven't worked at, so I don't want to attempt to speak too much into the intricacies of how they work. But I'd say inside our four walls, our culture of teamwork and collective outcome and benefit and effort is really special. Every investment we approach has access to the entire firm's resources and capabilities. And I think it's really different.

+ +

I mean, we're very happy to partner with one another internally, help each other out, help companies that we might not be mostly directly involved with for the benefit of our firm, and our investors, and the companies that we work with. And I think that is something that a lot of firms talk about. I don't think it's always true at a lot of firms. And so, for us, it's really special and something that we've worked really hard to build as a culture, and keep as a culture, and preserve every day.

+ +

Because I think it's easy to feel like you're on an island in this business at times, but we want to make sure that we feel that connectivity as a team. For our entrepreneurs, we are here to work with you and support you, probably not daily because I think, again, that goes back to having the right people, but weekly, monthly, quarterly, over years, that's our approach. We believe great things take time to build.

+ +

WILL: That's amazing. Zack, I want to summarize this portion with you. How do you keep your firm and your employees safe from online threats? Do you share that with your portfolio companies? Because I know especially in the tech world and in the news, you're hearing about those scammers, those threats, summarize it for me, like, how do you do that?

+ +

ZACK: There are a lot of pieces, of course. And as I was talking about before, I think the most important thing is really just getting buy-in from the whole firm. Me and my team we definitely try out the latest products, get the top-of-the-line security stuff, and really make sure that that stack is solid and that we're monitoring everything and getting the buy-in.

+ +

So it's a lot of training. It's keeping them up to date. It's instilling the messages. Like, when I first started here, I did a security training. The firm had never done a security training. We were pretty light on security at the time. And so, I tried to make the presentation fun and a little scary. So I brought in the FBI.

+ +

WILL: Wow.

+ +

ZACK: The FBI scared everybody a little bit. And then I came on and just talked about what to do and not to do. And I actually had a song composed [laughs] about security and what employees should be doing. It was just a funny jingle that people still sing today. [laughter] But yeah, I think just making it memorable. And we have a Slack channel called Tech Talks. I'm always updating the latest information on there on different breaches and different attacks we're seeing, and what we can do to prevent that, and what our employers should be doing. And absolutely, that extends to our portfolio companies.

+ +

And those jump guides, I believe they're out now with all my technical recommendations. We use those internally. I definitely gave those to the firm but also to our portfolio companies. And there's some interesting stuff in there that you may not think of, like removing your information from the internet. Like, get a company, Optery, something like that, which we pay for for all our employees, and it scrubs the internet of your information, and that's great. It cuts back on phishing, spam calls, you know, just going beyond too.

+ +

We also have this product that we use that monitors employees' personal email addresses for breaches. So we're not just caring about IVP. We're also caring about what someone's doing in their personal life because that can also lead to a breach of IVP. So yeah, so someone's Gmail account gets exposed, and we're going to know about it, and we can let them know.

+ +

And then, really, it's just staying on top of things. One of the things we just did, you know, passwords are the worst, everyone knows that, and so we just rolled out this product called Beyond Identity. And it's a password list provider. The difference between them and other password list providers is they offer a layer of security on top of the password list. So it's not just convenient; it's also added security, which was always my worry about going password list; it's just more convenient and less secure. But this company does it right. And it's things like that, just staying ahead of it. All right, passwords are a problem? Let's get rid of passwords. Following those trends and keeping up to date.

+ +

ERIC: I mean, Zack is a very tough critic. So he's given a couple of shout-outs which means he really likes those products, and I'm glad that we have them. And I very much remember that training session that he did for us or organized. And we did a refresh of it a couple of years ago. I think we've done at least two of them now. It sounds really boring [laughs], and maybe I'm just kind of a geek in that way, but that was one of the most memorable training sessions that I've ever been part of in my time at IVP.

+ +

And we had Zack's buddy from the FBI come in and give kind of an overview of all the vulnerabilities that they see, and that's obviously very, very cutting edge. And they had some footage of people sort of passing off USB sticks here and there in subways in New York City. So you can kind of see them go in in one entrance. They got a different shot of the camera while they're on the tracks, and they go their separate ways.

+ +

I mean, this is straight out of some spy stuff, and it's happening. It makes you think...that's an extreme; we know we're talking about sort of most likely state-sponsored bad guys, but the ones that are commercially oriented, I think maybe they're not as frequent...they're more frequent, and so we have to be on guard all the time, especially as a firm that does have access to and move around a lot of money.

+ +

I'm geeking out because I learned a lot from it. And Zack also likes to keep all of us on our toes with a lot of sort of...it's like the security equivalent of pop quizzes. He's always planting fake links and stuff to see who clicks on them. [laughter] And then he's pretty kind because he doesn't out you by name when we talk about them on Mondays. [laughter]

+ +

But he says something like, "Hey, you know, there are 65 people who got this test, and the good news is that 50 of you passed. The bad news is that 15 people didn't, which means that could have resulted in a lot of different intrusions. So try and be better," so stuff like that. And it is actually kind of fun and reminds us that while we're a venture capital firm, we are people that comprise the firm just like everybody else, and we got to be vigilant.

+ +

ZACK: That's a good point, too, just about the FBI and them showing us all the crazy stuff. I mean, one of the things that they really tried to drill in, and I still talk to my friend in the FBI today, is VCs are a target. VCs are absolutely a target. And it's not necessarily what you have; it's what you're perceived to have.

+ +

And so, okay, they probably think we have a lot of IP and a lot of things like that that we don't necessarily have, but they're still going to try to get in. They're still going to try to hack their way in. And I think that's important, too, just instilling that message like, yeah, we're a VC firm. We're a target; you need to understand that; here's why. And that's true for most firms. We're not special. But it's definitely something you need to instill.

+ +

ERIC: Oh, Zack's probably going to cringe if he hears me say this, but I definitely take the point that you know, you don't have to be faster than the bear; you just got to be faster than the next guy. So you just have [laughter] to be more secure and more of a pain to try and penetrate, and they'll move on to somebody else.

+ +

ZACK: I mean, that's totally true. That's a big part of security. If they come knocking on your door, and you have that deadbolt, and the next house doesn't, then yeah, they're going to go the easier path. So that's absolutely true, Eric.

+ +

WILL: Well, you're doing something right because he remembered the training, and he enjoys it. [laughter] You're doing something right.

+ +

ERIC: I guess I'm just weird in that way, but it was actually kind of fun.

+ +

WILL: Well, thank you, Eric and Zack, for being on here. It was amazing. Where can the audience find more information about you, connect with you?

+ +

ERIC: www.ivp.com is probably the best place. It sounds so old school, but it's the most relevant. Follow us on Twitter, LinkedIn. But I've had a great time talking with you. This has been a lot of fun. Hopefully, you got some nuggets for your audience, too.

+ +

ZACK: Yeah, I agree. Thank you very much for having us. This was a lot of fun.

+ +

WILL: Yeah, I've really enjoyed it, so thank you.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Eric Liaw and Zack Willis.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Eric Liaw and Zack Willis are part of IVP, a leading venture firm with a 43-year history of partnering with entrepreneurs who are undaunted on the path to innovation.

+ +

Will talks to Eric and Zack about what has made IVP so long-lasting in the Venture Capital industry, how they help companies' portfolios, and the accomplishments they are most proud of.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Eric Liaw and Zack Willis, who are part of IVP, a leading venture firm with a 43-year history of partnering with entrepreneurs who are undaunted on the path to innovation. Zack, Eric, thank you for joining me.

+ +

ERIC: Thanks, Will. It's great to be here, really appreciate it. And I got to say, as the Giant Robot Podcast, as a kid growing up, Transformers were my favorite toys. So this may be the closest I ever get to being a Transformer by being part of Giant Robots, so thank you for the opportunity.

+ +

[laughter]

+ +

WILL: Love it. We love robots here, so it's perfect. All right, let's start here. For folks who may not know, tell us about IVP and what's on deck for 2023.

+ +

ERIC: Well, you gave a great intro, so let me just add to that a little bit. You know, we're really proud of our history and our firm. We've been around since 1980. So we're one of the sort of original Silicon Valley venture firms. But when I speak about the firm in that context, I don't think it does justice to how the firm has expanded over the years and how our investment activity now encompasses not only the Bay Area but major U.S. markets like New York and LA. We have investments in Canada, Australia, and a number in Western and Central Europe as well.

+ +

And the common theme for us is that we're focused on working with entrepreneurs who, as you pointed out, are undaunted as they innovate and are pursuing dreams to create companies that will become recognizable in households and companies across the world, not just today but tomorrow as well. So that's really what IVP is all about. And it's what we're looking forward to in 2023 despite obviously the fact that the world is a little more challenging these days, a little bit more uncertain in, particular in the venture category.

+ +

But we're really excited about the things that we're working on. We invested a lot in our team over a number of years. And, believe it or not, despite what you might read in headlines around venture activity, we are very much open for business in 2023 because we think that great entrepreneurs and great ideas come together at all times, regardless of whether the stock market is up or down. And our job is to find them, work with them, and become partners for three, four, or five, six, seven years, sometimes longer than that. So really, there's no bad time to start a company and get to know venture investors like us.

+ +

WILL: Yeah, definitely. Your company has been around for 43 years. Can you kind of tell me what has made you last that long, for 43 years? That's a long time to be in the venture capitalist world, especially before it was popular and fun.

+ +

ERIC: You know, it's a great question. I've been at the firm for 11 years now. So a lot of the credit goes to people that...our founder, Reid Dennis, who started the firm. He's in his 90s now, so he has since retired, but a lot of credit goes to people that came before me and before Zack. And I think that's a common theme for any kind of organization or institution, no pun intended, because that's what the I in IVP stands for. But it goes to that sort of common thread. You have to evolve, especially in technology.

+ +

The technology markets that were successful for IVP in the early '80s that's not really cutting-edge venture anymore. As an example, Seagate was one of our first investments ever when people weren't sure that personal hard drive technology would actually work or whether or not they're getting market demand. I mean, who would actually want storage themselves carried around with them at all times? And now, think about how much storage you have in your pocket. It's pretty gnarly to think about how much technology has advanced.

+ +

But if you kept only thinking about, okay, I'm going to invest in the next hard drive, you would have really gotten stuck after that. And obviously, the things that have come since out of the minds of technology entrepreneurs have far exceeded what people at the time of the founding of IVP would have thought was possible. So I think that evolution is really important, staying fresh; technology trends evolve. In the early days of IVP and in Silicon Valley, there was a saying among venture capitalists that if you couldn't drive to the board meeting within 30 minutes, you didn't make the investment. That's just not true anymore. There's no way.

+ +

WILL: [laughs]

+ +

ERIC: And I think COVID has certainly proved that because investments are being made around the world. Now, maybe in hindsight, that was too fast. There was too much capital flowing around just to resume dating if you will. But the underlying theme is evolution, and I think it's teamwork. Because our founder, Reid, wanted the organization and firm to thrive well beyond his days as an active investor, and you can only do that with building a team that's multigenerational. And I'm proud and lucky to be part of an organization that's done that.

+ +

WILL: Awesome, awesome. Well, tell me about you. Tell me more about your background. How did you get started in the VC world?

+ +

ERIC: You know, child of immigrants who came to the United States in the '70s from Taiwan. They met in New York City. Like many other people, moved to the burbs and they started a family. So I was born in New Jersey. My brother and I were both born there. I moved to LA when I was 12. I lived in Southern California until I went to college. Had the miraculous fortune to somehow get into Stanford and went to school sort of in the late '90s into the early 2000s, as good fortune would have it, in the middle of the internet bubble.

+ +

So I had kind of a front-row seat to that era of technology, innovation not knowing anything about tech when I showed up in Palo Alto in the fall of '96. I got exposed to venture capital while I was in school. There was a pretty memorable, at least for me, speech that I went to. John Doerr, now retired from Kleiner Perkins, was on stage in the engineering auditorium and gave a speech about how Amazon was going to change the world. And this was probably in the fall of '98.

+ +

And he was right. I just think maybe the timeframe was slightly off, but he was right. I mean, at the time, it was books and CDs, and to some of our listeners, CDs was actually how you used to listen to music.

+ +

WILL: [laughs]

+ +

ERIC: But you sort of had this really expansive vision. And it was a really exciting way to understand that there are ways to be involved in the technology ecosystem without necessarily being a software engineer. Because I tried my hand at that, and I wasn't anywhere close to being top of the class, let's put it that way. And so, I wanted to be involved in the industry but also kind of think about how I could play to whatever strengths I had.

+ +

And then the sort of window into venture capital sort of started to open in terms of my awareness of it. I ended up working at Morgan Stanley for a couple of years out of college, where I got to learn more about technology from a business lens. But I always knew I had an angle or a desire to become a venture capitalist. So got into the industry; it'll be 20 years ago this summer. And I've been fortunate enough to keep doing it for that period of time. So that's kind of the medium-length answer to how I got started [laughs] in the business.

+ +

ZACK: I don't have quite the story that Eric does there. [laughs] But venture capital was never on my radar. I went to college to be a programmer, and that's where I started out. My first real job was at Anheuser-Busch in Los Angeles, and go Lakers.

+ +

WILL: [laughs]

+ +

ZACK: Me and Eric have some LA routes [laughter], so that was a great job. I had a ton of fun. And I just got a call from a recruiter one day that a VC firm was looking for a job as an IT manager. I was very unqualified for the position, went through the interview process. It took like six months. I think I met everybody at the firm, got the job. And that was, like Eric, that was about 20 years ago now. And I have just been in the industry ever since. So it's a great place to be, and I have no plans on leaving.

+ +

WILL: Oh, that's amazing. I love it. So tell me this, beyond dollars invested...because honestly, when I think of venture capitalists, it is mostly about the money. Hey, how much money have you done? How much money have you sent in? What does that look like? But I don't think we ever cover the next step. What else is there? So beyond dollars, what does IVP do to help companies' portfolio?

+ +

ERIC: Capital is definitely part of it. It's venture capital, so let's be real. You can't ignore that part of it. But I do think that it is only a part of it because what I think sometimes people don't really think through...because the media in particular likes to write about the day a company goes public or if there's a big acquisition like it all just happened at that one moment, but that is so far from the truth.

+ +

I mean, the amount of work that entrepreneurs and people at startups put in to drive to those outcomes that sort of culminate in that moment is really one of the things I respect most and enjoy most to be part of as a venture capitalist. And so what our role in that can often be is actually quite varied because no two companies are the same. I mean, there are some common themes, but no two companies are the same. And so how we try and get involved is tailored to what a given company needs at a given point in time.

+ +

Now, some of the common threads might be working with companies to help build out their teams. We do a lot of that because, ultimately, the team is who's at a company every day. I mean, investors aren't there every day and frankly, if we are, probably something's gone wrong.

+ +

WILL: [laughs]

+ +

ERIC: That team is important. And we like to think about getting involved in high-leverage moments. And there are a number of different ones, and Zack is part of this too. So a high-leverage hire is probably someone at the C-level or VP-level because that person then recruits and builds out a team. It's different...not to say that individual contributors aren't also important, but we're trying to think about those key players, moments where we can help, I guess, in a biblical turn, teach people how to fish instead of fish for them. That's our mentality, and recruiting is part of it.

+ +

Sometimes these are partnerships that can drive significant revenue lines. Sometimes it's debating what a business model should be in a given company. A great example on some of these is at both Coinbase and Discord; there was debate around what the business models ought to look like. Coinbase is very transactional. We pushed them to sort of think through a recurring revenue component, some other services that they could have so that their revenue could be a little smoother and not just dependent on transaction volumes.

+ +

At Discord, they were thinking through raising money to start an in-house gaming studio. We kind of said, "You know, that's a really competitive industry, and the content creation costs just keep going up. How about a different model? Maybe we can think about a subscription service." And that became what drives the revenue today around buying advanced features for your private servers and things like that.

+ +

There are a lot of moments...unfortunately, sometimes our companies become targets of bad actors, which brings Zack back to the forefront. Part of the benefit of having a portfolio is we see a lot of these different incidents. And Zack is someone that we sort of unleash with our companies when they face some of these challenges, you know, I got a hack, or I have this going on, and Zack jumps in. You should talk about some of the situations that you've had to deal with. And the bat phone rings when those things happen, and we send them straight to Zack.

+ +

WILL: [laughs]

+ +

ZACK: Yeah, I mean, we definitely do everything we can. There definitely have been times where it's, all right; this happened to us; what do we do? How can we help this company? And I've really been deeply involved in security most of my career, and it's kind of where I wanted to go. And I pride myself on that. And we have great security here, and we try to instill the same in our portfolio companies.

+ +

And recently, we developed these jump guides, which is another way we're helping portfolio companies. So they're kind of like how-to lists. So there would be how to hire your first CFO, how to go IPO, that sort of stuff, and I just authored a couple, actually, that are about how to keep your company safe and how to keep your employees safe. And it's all just tips. It's nothing revolutionary, mind-blowing, but it's just stuff that every company should be doing to keep themselves safe.

+ +

And so that's really the message that we try to give to our portfolio companies. We definitely internalize it as well. I think really the key to good security is there's a partnership. There has to be a partnership between you with, the security team, and all the employees. You can have all the layers of defense you want. You can have your firewalls, your antivirus, et cetera, but if your employees don't understand the value of security and why they shouldn't click on that link or they shouldn't download that file, it's meaningless.

+ +

It's very important to instill that, just have open communication. And what I tell everybody at IVP is that security is in your hands. We're doing what we can, but it's in your hands. So, ultimately, it falls on them. And it's a scary time, you know, new stuff coming out all the time. But, yeah, we do our best to keep on top of it and our portfolio companies as well.

+ +

ERIC: Zack is being very modest. But if you take a step back, if you think about, you know, in any of our own lives, which there's a parallel, I think for companies, there are certain moments when you're facing a tough spot, and people that were there for you and helped you are the ones that are most memorable. And when there are good days, things are pretty easy. And those hard days are where we want to make sure that we're there for our companies.

+ +

And some of those hard days are in times like these where companies have to make some tough decisions around their cost structure because the environment has changed; some of these are, as Zack points out when they're facing a hack or a breach of some sort. And so, ideally, some of those you're preventing before they happen. But in the moment, Zack is a great ally and asset for a lot of our companies.

+ +

And some of these also happen on a day-to-day basis. It works great to have someone like Zack on our team. He can kick around and be a source for feedback for some product testing, which he does with a lot of companies that are in the portfolio. And actually, he does that when we're evaluating companies too, and sometimes they don't score so well on the Zack Willis meter. [laughter] And then we have productive feedback to give them to think about things as they refine what they're working on.

+ +

So it's one of those things where there are high-leverage moments, but we really focus on trying to be involved but also available. And again, this is repetitive to what I said earlier; no two companies are the same. And these are long-term partnerships. We want to make sure that we help them succeed, and that's what it's about.

+ +

ZACK: I agree, and availability for sure. It can be around the clock. You don't know when these things are going to happen. And definitely, we pride ourselves on that, on being available for our companies when they need us.

+ +

WILL: That's amazing. It sounds like maybe the secret sauce is your long-term relationship with the company. It's not just drop millions of dollars into the company and see you later. Hopefully, you sell out; whatever, you make money. We'll get it back. It's not the day-to-day, but when it gets hard when we can help you when we can support you.

+ +

And we kind of have that same mindset with thoughtbot. We don't just try to build software and say, "Hey, you're on your way." But, no, hey, can we help you hire developers, anyone to help you with this and make sure that it's not going to fall off as soon as we leave? But that long-term thing. So sometimes, when you're in a long-term game, it can get kind of messy. So, professionally speaking, what keeps you up at night?

+ +

ERIC: One of the challenges of being an investor is that you can never be too happy or too sad, particularly when we have a portfolio. So if you think about it, to your point about being involved, it's not just writing a check or investing and then say, "Here's the money; call me later." We're active partners. We take board seats in two-thirds of the companies that we invest in. And that's not a stat I throw out there to say it's a contest to see how many boards you're on. No, it's actually a reflection that when you're on a board, you have a responsibility to be helpful and involved and help steward the entire company on behalf of all shareholders.

+ +

And so that's part of being involved in a portfolio of 80 or 100 companies that are active right now. There are going to be some that are having good quarters and some that are having tougher quarters. And so, collectively, we try and be even-keeled as long as we're making forward progress. And Zack is a guy who runs sub three-hour marathons, but some miles are harder than others. And he can talk more about that. But there are going to be some periods in a company's journey that are harder than others.

+ +

And so we just try and make sure we're sort of focused in the right direction and ultimately that the right goal is in mind. And right now, probably what's topical is it's harder for companies to raise money at any scale. You see, this sort of capital markets have really reversed course, and this is by design with the Fed raising rates and trying to intentionally slow the economy down for a whole host of reasons we probably don't have to get into on this podcast, but it's working.

+ +

And what does that mean for our companies? It's harder to generate revenue. People are watching their budgets, whether they're consumers or enterprises, which then means that they need to watch their operating budgets. And that's why you've seen a lot of the layoffs that have happened across the technology sector, in particular over the last nine months. And it's not just startups, you know, it's Google announcing one of the biggest cuts that they've ever had in their history. Microsoft did that yesterday.

+ +

So it is a more challenging time, and it's something a lot of people in the industry hadn't been through because we've had the benefit of such a long bull market run. But for better or for worse, at this point in my career, I've seen it more than a few times. And so this is, I think, an area where we can be a guide partner, sometimes just a sounding board because it's not easy to make these decisions.

+ +

ZACK: First of all, I'll give thoughtbot a quick plug since you guys really helped us out. I guess this was about seven years ago now. We worked with you guys a couple years to get the first iteration of this system that we have that helps us...kind of part of our secret sauce that helps us find companies to invest in. So I'm very thankful for that.

+ +

And as far as what keeps me up at night, I mean, aside from my cat, and my dog, and my anxiety, [laughs] it's going back to what we talked about before; it's really security. Did we do everything? Are we staying on top of the latest threats? Are we helping out our companies enough? There was an interesting article that just came out a few days ago that talked about how PE companies and some VCs, private equity and venture capital, are requiring security audits of their firms before they invest in them.

+ +

And so before they'll make the acquisition, they'll run into an audit, and they'll say, "Okay, well, you're missing these things. We're not going to invest in you until you do these things, until you have two-factor authentication until you have this, until you have that." I think that's an interesting trend. For PE, it's a little bit of a bigger deal since they acquire the company. It's still a way that I believe that we can protect ourselves and our portfolio companies. It helps protect our reputation, helps protect their reputation, and it really gives us the chance to get in there at the beginning and say, "Hey, these things are missing. This is what you should focus on security-wise.

+ +

WILL: That's amazing, amazing.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

WILL: I wanted to take a step back; when you mentioned Coinbase and Discord, and you said that you helped them set the direction going forward. Honestly, we may not even know those companies if their original plan would have gone forward. How much has your 43 years of experience helped guide that direction with Coinbase and Discord?

+ +

ERIC: You know, there's a saying that history doesn't repeat itself, but it often rhymes. And so I think that's probably the mentality that we try and take from our collective experience as a team that we try to bring to each company. And we meet as a team on Mondays and Thursdays, and it's a very broad meeting compared to most of the investment world in terms of who attends that meeting internally. And so we talk about companies that we're considering and contemplating. We talk about companies we've already invested in.

+ +

And I think one of our core cultural attributes that is a great strength is putting our best thinking against some of these problems. Again, when things are going well, those are short conversations. But when someone says, "Hey, you know, I'm working with this company, and we're kind of facing this issue. What do people think? What have we seen that's kind of analogous?" And that's where we get some of these ideas from.

+ +

So, for example, on the Coinbase example, we've been involved in a lot of marketplace businesses and exchange businesses. Those are great business models. And Coinbase has a fantastic management team. But thinking about this, this is pre-IPO and pre-direct listing, and when they want to be public one day, you know, there is a benefit to having a recurring revenue stream, a little more visibility. And so, how could we layer that on and make that, hopefully, over time, a bigger and bigger part of the business?

+ +

I think in Discord; we had some perspective that led us to invest in the company. In the first place, we've had a lot of success in gaming companies like Zynga, and Supercell, and Niantic, amongst others. We could see how passionate gamers are and, how they come in all different shapes, sizes, flavors, geographies, and how having a communication tool like Discord is really a benefit.

+ +

However, we also saw that the cost of producing games continues to go up. And if it's not kind of your full-time job, the likelihood you're going to nail something that a very competitive and discerning universe of gamers wants to play is probably not that high. So how do we think about harnessing that energy, and the talent, and the platform you build in a different way? So I'd say those are kind of some examples where we could think about things we've seen in our perspective but apply it to what's relevant for a specific company.

+ +

WILL: That's amazing. I love it. Yeah, I've heard the gaming business can be brutal. What IVP accomplishments are you most proud of?

+ +

ERIC: Well, maybe I'll break that into two parts. I think inside and outside the firm; I'm really proud of the team that we've built. And when I joined the firm 11 years ago, we were probably 20 people, 25 people in total. Now we're 65 people. And that doesn't seem like a lot in comparison to big tech companies or hyper-growth startups. But in a business-like venture capital, really what we're doing in addition to providing capital, internally, it's a lot of discussion, decision-making, ideas, thinking. That is hard to do the way that we do it if we get too big.

+ +

And that goes back to the size of our Monday meetings, which is rather large and includes a wide representation of the firm. But I'm really proud of the team that we've built. I'm really proud of the capabilities that we've enhanced on the technology side. Really, Zack drove a lot of this in the time that he's been with the firm, and we're leaps and bounds ahead of where we were with your help as well. I think Zack was alluding to what we think is one of our secret weapons, our early detection system, so we're really proud of that.

+ +

And then I'd say externally, or with our companies, we've had 131 of them go public. We had 15 of them do that in 2021, none did in '22. So the market's changed quite a bit. Those are accomplishments that, like I pointed to previously, they're milestone events. The pride comes in knowing that these companies that we've worked with have put in the work over years, at minimum, years, to get to that point. And that gives, I think, all of us a collective sense of accomplishment.

+ +

WILL: That's amazing.

+ +

ZACK: Yeah, I definitely agree with that. In my, I guess, almost eight years here now, we've grown a ton in our hiring. Our team is amazing. It's really the reason why I'm still here, why our turnover is basically nothing. We hire great people. And during that time, we've raised some great funds. We've invested in amazing companies. We've helped out a lot of entrepreneurs. It's just across the board. I've been in this industry a while. I feel like IVP is definitely a unique VC firm, and I'm proud of what we do.

+ +

WILL: That's amazing. One of my favorite questions that I like to ask on the podcast is, if you could go back in time at the very beginning and give yourself advice, what would it be?

+ +

ZACK: For me, it's stay relevant, I think. And to me, it just means being more involved in everything. Put yourself out there. Be bold. Learn about different areas in the company. Try to attend different meetings. Talk to different departments, and really just make yourself visible. When you do that, I think the rest just kind of falls into place. And it took me quite a while in my career to really realize that. And it's still tough now, but it's something that I'm always trying to do. Historically, I'm a very shy person, but just putting myself out there and doing the best I can in any situation that I find myself in.

+ +

ERIC: I think a couple of things, balance, and patience are probably two things, not trying to force it. So I think there's a lot of Yoda Jedi wisdom that probably would be useful. So if you're sort of...when I was first starting out, you're younger and impetuous at times and want to make things happen because you have such a strong desire to try and do something the right way and make a positive impact. But the hardest thing to learn is sometimes the right thing to do is actually to do nothing in the investment world. That is a hard thing for a lot of motivated, energetic Type A people to do, and yet it's sometimes the exact right thing you should be doing.

+ +

So I think it's hard to hear that when you're starting out in your 20s. And now that I'm a little older than that, [laughs] I think I can look back and appreciate it. But that's probably, as I think through that question, maybe the best piece of advice. And yet, like a lot of things, we were all taught while we were younger from people who had more experience, or age, or wisdom, or whatever, there are just some things you hear, and it's not real until you've kind of lived it.

+ +

And sometimes, in some of those dimensions, you have to make your mistakes before you appreciate them. You guys probably had this experience writing code. Like, there's got to be...I could just do it this way, and it'd be fast. And then you realize it wasn't really that sound or forward-compatible or something. You had to go back and rewrite your architecture, and that's a pain. So I think it's that same approach, thinking with balance.

+ +

ZACK: Just to add to what I was saying before, too, I think one of the things also would have been, you know, find something you're passionate about and do it every day. That wasn't the case early on in my career, and I turned to running, and I turned to working out. And I do something every morning, and that really, really grounds me. It helps me focus helps me plan out the day. And it's really just my time that's crucial. And whether it's running, whether it's meditating but just taking some time for yourself, you know, energize yourself, take care of yourself. And that goes a long way in the workplace as well.

+ +

WILL: I love it, yeah. That's why it was one of my favorite questions, just learning from your mistakes, learning from what you did in the past. It's amazing. So I love that.

+ +

ERIC: Yeah, I mean, since Zack brought up the Lakers, [laughter] and this isn't the Lakers, but it's basketball-related, you guys might remember this old Michael Jordan commercial. He talks about I've missed this many free throws and this many shots and something like, my team has trusted me 80 times to win the game in the fourth quarter, and I've missed. The tagline is something like, I have failed over and over and over and over again, and that is why I succeed. There's definitely some of that in the venture business and the advice I think we could all give to our younger selves.

+ +

WILL: Oh, yeah, getting back up. Keep going, yeah.

+ +

ERIC: The same thing with Dwyane Wade commercial, you know, get knocked down eight times, get up nine, kind of the same thing.

+ +

WILL: Love it. What's something you would love the audience to know about IVP?

+ +

ZACK: I think our team and just the way we hire. We hire amazing people. They're smart. They're kind. They're low ego. They're thoughtful. I'm not going to say it's completely different from others, but it is, in my experience, a different culture. And we all get along great. We mesh really well, and we continue to hire great. We hired almost 20 People in the last year and a half. That's a lot, but we still manage to maintain the same level of talent. We help our portfolio companies do hires as well. I think that's one of our benefits. We know talent, and we know it internally, and we know it externally. And it's just a great culture to be a part of.

+ +

WILL: Amazing.

+ +

ERIC: The thing to think about with us is if you're an entrepreneur building a company, it's tough. Sometimes it's really lonely. We aspire to be partners with entrepreneurs in good times and in bad. We're not the flashiest ones out there. We're not trying to see who has the most Twitter followers. But when you need something, we're there. I think that is something people lost sight of or didn't care as much about in the last couple of years when things were easy. They're not so easy now.

+ +

And we take pride in these long-term partnerships, which is why we're highly selective in the number of companies we invest in every year. We're never going to be the most active, but we put a lot of our work, time, effort, energy, mental capacity alongside the capital that we bring to our companies. And I think that's been a great formula for us over our history, and it'll continue to be.

+ +

WILL: That's amazing. To summarize, I know each VC firm has their own DNA. What makes IVP different from its competitors?

+ +

ERIC: I'd say a couple of things. And again, I've only worked at two firms, and so there are a lot of firms I haven't worked at, so I don't want to attempt to speak too much into the intricacies of how they work. But I'd say inside our four walls, our culture of teamwork and collective outcome and benefit and effort is really special. Every investment we approach has access to the entire firm's resources and capabilities. And I think it's really different.

+ +

I mean, we're very happy to partner with one another internally, help each other out, help companies that we might not be mostly directly involved with for the benefit of our firm, and our investors, and the companies that we work with. And I think that is something that a lot of firms talk about. I don't think it's always true at a lot of firms. And so, for us, it's really special and something that we've worked really hard to build as a culture, and keep as a culture, and preserve every day.

+ +

Because I think it's easy to feel like you're on an island in this business at times, but we want to make sure that we feel that connectivity as a team. For our entrepreneurs, we are here to work with you and support you, probably not daily because I think, again, that goes back to having the right people, but weekly, monthly, quarterly, over years, that's our approach. We believe great things take time to build.

+ +

WILL: That's amazing. Zack, I want to summarize this portion with you. How do you keep your firm and your employees safe from online threats? Do you share that with your portfolio companies? Because I know especially in the tech world and in the news, you're hearing about those scammers, those threats, summarize it for me, like, how do you do that?

+ +

ZACK: There are a lot of pieces, of course. And as I was talking about before, I think the most important thing is really just getting buy-in from the whole firm. Me and my team we definitely try out the latest products, get the top-of-the-line security stuff, and really make sure that that stack is solid and that we're monitoring everything and getting the buy-in.

+ +

So it's a lot of training. It's keeping them up to date. It's instilling the messages. Like, when I first started here, I did a security training. The firm had never done a security training. We were pretty light on security at the time. And so, I tried to make the presentation fun and a little scary. So I brought in the FBI.

+ +

WILL: Wow.

+ +

ZACK: The FBI scared everybody a little bit. And then I came on and just talked about what to do and not to do. And I actually had a song composed [laughs] about security and what employees should be doing. It was just a funny jingle that people still sing today. [laughter] But yeah, I think just making it memorable. And we have a Slack channel called Tech Talks. I'm always updating the latest information on there on different breaches and different attacks we're seeing, and what we can do to prevent that, and what our employers should be doing. And absolutely, that extends to our portfolio companies.

+ +

And those jump guides, I believe they're out now with all my technical recommendations. We use those internally. I definitely gave those to the firm but also to our portfolio companies. And there's some interesting stuff in there that you may not think of, like removing your information from the internet. Like, get a company, Optery, something like that, which we pay for for all our employees, and it scrubs the internet of your information, and that's great. It cuts back on phishing, spam calls, you know, just going beyond too.

+ +

We also have this product that we use that monitors employees' personal email addresses for breaches. So we're not just caring about IVP. We're also caring about what someone's doing in their personal life because that can also lead to a breach of IVP. So yeah, so someone's Gmail account gets exposed, and we're going to know about it, and we can let them know.

+ +

And then, really, it's just staying on top of things. One of the things we just did, you know, passwords are the worst, everyone knows that, and so we just rolled out this product called Beyond Identity. And it's a password list provider. The difference between them and other password list providers is they offer a layer of security on top of the password list. So it's not just convenient; it's also added security, which was always my worry about going password list; it's just more convenient and less secure. But this company does it right. And it's things like that, just staying ahead of it. All right, passwords are a problem? Let's get rid of passwords. Following those trends and keeping up to date.

+ +

ERIC: I mean, Zack is a very tough critic. So he's given a couple of shout-outs which means he really likes those products, and I'm glad that we have them. And I very much remember that training session that he did for us or organized. And we did a refresh of it a couple of years ago. I think we've done at least two of them now. It sounds really boring [laughs], and maybe I'm just kind of a geek in that way, but that was one of the most memorable training sessions that I've ever been part of in my time at IVP.

+ +

And we had Zack's buddy from the FBI come in and give kind of an overview of all the vulnerabilities that they see, and that's obviously very, very cutting edge. And they had some footage of people sort of passing off USB sticks here and there in subways in New York City. So you can kind of see them go in in one entrance. They got a different shot of the camera while they're on the tracks, and they go their separate ways.

+ +

I mean, this is straight out of some spy stuff, and it's happening. It makes you think...that's an extreme; we know we're talking about sort of most likely state-sponsored bad guys, but the ones that are commercially oriented, I think maybe they're not as frequent...they're more frequent, and so we have to be on guard all the time, especially as a firm that does have access to and move around a lot of money.

+ +

I'm geeking out because I learned a lot from it. And Zack also likes to keep all of us on our toes with a lot of sort of...it's like the security equivalent of pop quizzes. He's always planting fake links and stuff to see who clicks on them. [laughter] And then he's pretty kind because he doesn't out you by name when we talk about them on Mondays. [laughter]

+ +

But he says something like, "Hey, you know, there are 65 people who got this test, and the good news is that 50 of you passed. The bad news is that 15 people didn't, which means that could have resulted in a lot of different intrusions. So try and be better," so stuff like that. And it is actually kind of fun and reminds us that while we're a venture capital firm, we are people that comprise the firm just like everybody else, and we got to be vigilant.

+ +

ZACK: That's a good point, too, just about the FBI and them showing us all the crazy stuff. I mean, one of the things that they really tried to drill in, and I still talk to my friend in the FBI today, is VCs are a target. VCs are absolutely a target. And it's not necessarily what you have; it's what you're perceived to have.

+ +

And so, okay, they probably think we have a lot of IP and a lot of things like that that we don't necessarily have, but they're still going to try to get in. They're still going to try to hack their way in. And I think that's important, too, just instilling that message like, yeah, we're a VC firm. We're a target; you need to understand that; here's why. And that's true for most firms. We're not special. But it's definitely something you need to instill.

+ +

ERIC: Oh, Zack's probably going to cringe if he hears me say this, but I definitely take the point that you know, you don't have to be faster than the bear; you just got to be faster than the next guy. So you just have [laughter] to be more secure and more of a pain to try and penetrate, and they'll move on to somebody else.

+ +

ZACK: I mean, that's totally true. That's a big part of security. If they come knocking on your door, and you have that deadbolt, and the next house doesn't, then yeah, they're going to go the easier path. So that's absolutely true, Eric.

+ +

WILL: Well, you're doing something right because he remembered the training, and he enjoys it. [laughter] You're doing something right.

+ +

ERIC: I guess I'm just weird in that way, but it was actually kind of fun.

+ +

WILL: Well, thank you, Eric and Zack, for being on here. It was amazing. Where can the audience find more information about you, connect with you?

+ +

ERIC: www.ivp.com is probably the best place. It sounds so old school, but it's the most relevant. Follow us on Twitter, LinkedIn. But I've had a great time talking with you. This has been a lot of fun. Hopefully, you got some nuggets for your audience, too.

+ +

ZACK: Yeah, I agree. Thank you very much for having us. This was a lot of fun.

+ +

WILL: Yeah, I've really enjoyed it, so thank you.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guests: Eric Liaw and Zack Willis.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+e_vxafq5 + + ]]> + + Will Larry + Eric Liaw + Zack Willis + + + 463: EmergeOne with Aarish Shah + https://podcast.thoughtbot.com/463 + 1bfd0d9d-2966-4a8c-9ced-40a304f5d99f + Thu, 23 Feb 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Aarish Shah is the Founder of EmergeOne and Projected.ai and host of Off Balance and Nothing Ventured Podcast. + +Will talks to Aarish about having the venture capitalist money idea and having that "aha!" moment that it could work, what drives him and having a purpose of helping others, and using his podcast to teach lessons that he's learned along the way. + 31:45 + no + + + Aarish Shah is the Founder of EmergeOne and Projected.ai and host of Off Balance and Nothing Ventured Podcast. +Will talks to Aarish about having the venture capitalist money idea and having that "aha!" moment that it could work, what drives him and having a purpose of helping others, and using his podcast to teach lessons that he's learned along the way. +EmergeOne (http://emergeone.co.uk/) +Projected.ai (https://projected.ai/) +Off Balance and Nothing Ventured Podcast (https://nothingventured.tech/off-balance) +Follow EmergeOne on LinkedIn (https://www.linkedin.com/company/emergeone/), Facebook (https://www.facebook.com/EmergeOneUK/), YouTube (https://www.youtube.com/channel/UCfrtssmo3LELM6QDFOkU1Ug/featured), or Twitter (https://twitter.com/emergeone_uk). +Follow Aarish Shah on LinkedIn (https://www.linkedin.com/in/adsinuk/) or Twitter (https://twitter.com/adsinuk). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Aarish Shah, Founder of EmergeOne and Projected.ai and host of Off Balance and Nothing Ventured Podcast. Aarish, thank you for joining me. +AARISH: It's great to be here, Will. Really happy to be talking to you today. +WILL: Yeah, I'm excited. I can't wait to dive in and learn more about you. Tell me about your journey, how it all started. +AARISH: Wow, it's a bit of a long run. I'll try and condense it. But I am 44 years old at the moment. About 20 years ago, I came out of uni with a degree in languages which I found was sort of useful but not essential. So I ended up for a few years doing kind of the normal corporate thing. I worked with PriceWaterhouseCoopers, Nortel Networks, and then Deutsche Bank. And I qualified as an accountant along the way, so I'm effectively what you guys would consider a CPA over in the U.S. +I then kind of up sticks, and I spent the next ten years of my life running a group of manufacturing and trading businesses alongside a property portfolio out in Papua New Guinea, which is a very, very interesting place to be, definitely one of the hardest environments to be building and running businesses for many reasons. I've had everything from people coming into one of my offices with guns. I had one of my factories burned to the ground and everything in between. So really, really great learning experience and certainly amazing to learn about physical products, you know, the manufacturing and distribution and sales and so on of actual physical products. +And then, in 2015, I came back to the UK. I didn't really know what I wanted to do. And so I had a bunch of coffees with people and ended up as founding CFO in an EdTech venture, which was a joint venture between Eton College, which is one of the premier schools here in the UK where famously all of our Prime Ministers seem to come from, and Founders Factory which is an accelerator that was founded by Brent Hoberman of lastminute.com fame. So that was really exciting. +I was straight off the boat from Papua New Guinea, sitting 10 feet away from Brent Hoberman, learning everything that there was to learn about the tech sector here in the UK and beyond. And had a really great couple of years working in that business and learning really everything there was to know about the VCA ecosystem, the early stage ecosystem, how to build products, how to finance them, how to sell into new territories (We were operating in China at the time.) and all sorts of other things. +And then, in 2017, I decided it was time to move on. And I became what you guys would probably call a fractional CFO. So I worked across C through Series C businesses, everything from EdTech to FinTech, D2C, B2B marketplaces, beauty tech, you name it, kind of been there, seen it, and done it. And in 2019 and 2020, started getting approached by FDs and CFOs that wanted to work with me. And I really doubled down at that stage and decided to build EmergeOne into what it is today, which is a consultancy providing CFO services to venture-backed tech startups and scaleups. +So we work with a huge bunch of businesses here in the UK that are backed by VCs, some of the big names here like Hoxton Ventures, Stride, Octopus, Outlier, Founders Factory, and others. And I'm really, really passionate about helping founders build their businesses in a scalable and sensible way, I guess, especially in the current environment. And so we're really lucky that we're trusted by these VCs and the founders that we work with to deliver really great services to them. +And then, a couple of years ago, because I've been working kind of in the tech sector for so long, I started noodling around with a couple of ideas of projects that I wanted to move forward with. I raised a really small kind of pre-seed back in 2021 and started building a product, which is today Projected.ai, which we have just launched. We're in the process of launching at the moment. +And what that is is effectively an email newsletter, if you can believe it, providing internal and external data to our client businesses. So effectively, it's like a flash report of your financials alongside some really sort of personalized news about what's going on in your industry, alongside some other sort of bits and bobs that we're currently building in. +On top of that, a couple of years ago, again, I realized that I had a really good network of people that I had relationships with, and I decided to launch the Nothing Ventured Podcast to start speaking with people that operated in the VC ecosystem here in the UK and beyond. So I've been really fortunate to have guests like Hussein Kanji from Hoxton Ventures, Mac Conwell from RareBreed ventures in the U.S., and various others. And I really got to talk to them about why they got into venture, what they see is happening in the market, what are they excited about. And all those sorts of things. +Because, to be honest, I'm really passionate about learning and understanding about where people are coming from, why they do what they do, what drives them, what they're passionate about, but equally, the sort of challenges they've also faced. And that's been going now for 60-odd episodes. We're launching Season 4 shortly. And I'm really lucky and fortunate to have been able to do that. +And then finally, at the back end of 2022, so in December, actually, just as I was jumping on a plane, I sort of released something on LinkedIn, which was like 100 lessons that I've learned as a CEO and CFO over the last 20 years of operating. And unexpectedly, the thing went viral. I've had close to a million views on it, thousands of likes, hundreds of comments, and reshares. +And I decided to turn what was effectively just a list into a short-form podcast, which has turned into Off Balance. So we're releasing that daily and kind of expanding on each and every one of those topics that I went through in that list. So, yeah, look, I mean, I'm someone with a finger in a lot of pies. I'm a massive generalist, so I love getting involved in different projects at different times. But I'm really fortunate to be able to do what I love doing. It's just been a wild journey for the last seven years, certainly, but the whole 20 years of my life. +WILL: I love it. I love it. I love every idea that you had weaves into that venture capitalist money idea. So let's start at EmergeOne. When did you have that aha moment that this could work? +AARISH: So I work a lot in strategy, so there are two forms of strategies, emergent and there's defined. So most people know about a strategy that is written down; it's a playbook. They go out, and they pursue it. For me, it was really emergent. Firstly, I realized that there were not that many great CFOs operating in tech, certainly here in the UK, because it's, to an extent, a nascent industry. And whilst there are great accountants, and there are great finance leaders in larger businesses, actually doing that in a startup or a scaleup is very, very different. +Now, don't get me wrong, there are some great CFOs out there. It's just that I think there are far fewer than many people [laughs] assume there to be. So that was kind of the first thing that twigged with me. And I was seeing a lot of businesses picking up people and calling them a CFO when I knew for a fact there was no way that they really had the experience to be able to call themselves a CFO or to operate as one. So I guess that was the first aha moment. +And the second aha moment was as I started talking to more and more VCs via the podcast, and just generally because I was out in the ecosystem talking to them, I realized that actually, the work that I was doing was not being driven necessarily by the client companies but actually by the VCs themselves because they wanted to make sure that having invested 1,2,5, 10 million pounds or dollars that those companies were in good hands and safe hands and that capital was being managed effectively and efficiently. +And obviously, we're sitting in January of 2023 now. Never has that been more appropriate. More and more businesses are struggling. They're struggling to raise. They're having to extend their runways and figure out how to manage their cash in a much, much more significant way than maybe they had to two or three years ago. And so, for us, that's like a massively important thing. And having a great CFO in your business is going to help you do that. +And therefore, we are getting approached more and more both by VCs as well as by companies that are just on the lookout for someone to help them. It was sort of a series of aha moments. But as I said earlier, it was an emergent strategy. It was something that kind of developed over time. But also, I'm someone that learned quite early on in my life to back myself. +I think I took the punt on building this agency, if you like because it felt right. And it felt like something that I would enjoy doing, and it felt like something that I could actually make a difference in. And I think all of those things kind of culminated in really making EmergeOne what it is today, and I'm really proud of what we've been able to achieve. +WILL: Yeah, I love that idea because I feel like, especially in startups, like you said, that excellent CFO is really hard to find. It's really hard to find. But if you don't have the numbers, you don't have a business. Let's be honest, the numbers you just don't have it. +AARISH: Yeah, it's crazy to me that over the last decade or so, we've had, obviously, this period of super cheap money, super cheap capital. People have been raising at very inflated valuations. But we're seeing all of that come home to roost. We're seeing that in the public markets. A lot of these companies that IPOed over the last several years, obviously, have had their valuations drop significantly, you know, companies like Peloton, I guess, and others. +People are starting to realize that actually cash is king. They need to understand how the cash is flowing through their business and to know that they need to have an intimate knowledge of their numbers. And, in fact, a lot of our role as a CFO in a business is to kind of coach the founder to make sure that they do understand those numbers and how they need to present them to internal stakeholders, external stakeholders, whether that's your board, whether that's investors, or whether that's your employees to make sure that people have a good idea of not only how they're tracking but where they're heading and where the end goal is. And I think it's massively important. +I've always been a massive advocate for people getting to grips with their numbers, even if you're not a numbers person. Because especially if you're a founder or you're the leader in the business, the CEO, ultimately, the buck stops with you. You've got to know those numbers. It's not good enough to say, "Well, my CFO, my accountant has a handle on them." Like, if you're sitting in an investor meeting trying to pitch them to raise 5 to 10 million bucks, you're going to need to know those numbers inside out. And it's astonishing how many people actually ignore those. And what I would say is, you know, ignore them at your peril. +WILL: Yeah, that just blows my mind because if I put myself in an investor seat if I'm giving you money, I want the head person, the CEO, to know exactly how to handle that money. So yeah, I love that idea, and I love what you're doing. Let's go on Projected.ai. And if I understand this correctly, this is more of a kind of [inaudible 10:51] the words. +AARISH: So it's like a newsletter on steroids. +WILL: Yeah, but it's to be honest about your numbers to board members and investors, correct? +AARISH: Yeah. So Projected.ai was born out of this understanding that I guess I have, which is that CFOs and finance professionals working in startups and scaleups and SMEs they have dashboard fatigue. We interviewed CFOs, and they're operating off like 20 different dashboards, each of them giving them different numbers, each of them telling them something different. And they don't even have time to look at those dashboards, let alone make decisions based on the numbers that are coming out of them. +So what we wanted to do with Projected was provide a touch point for that CFO where they could check in with their numbers in a really easy way on a consistent, regular basis. When I thought about this really clearly, I don't live in dashboards; where I live is in the tools I communicate in, so that's my emails, that may be my Slack channel, that may be WhatsApp or iMessage, or whatever it is that you use. But certainly, for business, it's going to be email and Slack for the most part. +So I thought, what is the easiest way to communicate with someone in their business? It is via one of those channels. And what are the things that they want to know? Well, they want to know what's happening in their business, what's changed in their numbers over the last week, or two weeks, or month, but also what's happening outside their business. +Because often, in startups, we get so kind of tunnel-visioned into what's happening inside the business. We don't take the time to look outside and figure out what others are doing or what may be happening in the macro environment that may have an impact on our business. And an obvious case of that at the moment is interest rates having moved up quite significantly over the last several months and still going to, as well as sort of inflation numbers also on their way up, and central banks everywhere trying to rein those in. +All of that is going to have an impact on your business, especially if you're a consumer business, for example. And if you don't factor in all of those things or if you don't look at all of the things that could impact your business, you're going to make decisions with imperfect information, and, therefore, you'll make imperfect decisions. Now, you're never going to have perfect information. But the more information, the more pertinent information you have, the more transparent you can be, exactly as you said, to your board, to your shareholders. Tell them exactly what's happening, and get their advice to help you through those rough patches. +Ultimately, we've got some tricks up our sleeves in terms of what we're going to be doing with those numbers, and how we're going to be presenting them, and how we're going to be manipulating them when we do show them to our users. But I kind of felt like we've moved past that time where CFOs were only about the numbers looking backwards. A really great CFO today is all about communication, information. It's about turning data into information, turning numbers into a narrative. Yeah, that's what we wanted to build, a tool that could support them and help them really be the best CFO they can be. +WILL: Yeah, that's amazing. Transparency is the word I was looking for. So you nailed it, yeah. So I love that idea, the transparency of the numbers of the business just using AI. So that's amazing. It makes it a lot easier to send it out and to make it happen. So I love that idea. +AARISH: Yeah. I mean, the interesting thing is; obviously, we've all been hearing a lot about generative AI and large language models at the moment. And we've definitely got plans to incorporate that into what we're doing. But the other side of that is you got to be really, really careful, obviously, because, as we all know, there are biases that can creep into any of those sort of AI-driven models. But equally, there are inaccuracies. +And, in fact, a lot of those models tend to be great with words, not great with numbers. So one has to be really, really careful about bringing those tools into play. And because we know what we're doing, we can assess for that and make sure that the information that we're putting out there is the right sort of information, but actually, what we can do in terms of modeling our cash flows and revenue and effectively forecasting out a business. +Because bearing in mind a lot of startups, most startups, most scaleups, most SMEs don't have the balance sheet. They don't have the money to go out there and build an AI tool themselves. They just simply don't. And they may not have the wherewithal in-house, but they almost certainly don't have the cash. So what we're doing is hopefully providing a bridge for them to get better information in terms of what's happening today but also maybe an inkling of what might happen tomorrow, which helps them, again, to plan better. +And, again, it comes back to this whole thing around decision making, transparency, and making sure that they're able to look at their numbers with confidence and communicate those to others with confidence, and really understand what's driving those numbers as they keep building their businesses. +But everything we do at Projected, everything I do definitely as a founder and as someone that operates in this ecosystem, is all driven by how do we make the ecosystem better? How do we help founders? How do we help their companies? How do we make sure we can drive that number down from 90% of startups failing within the first three or five years? How do we turn that number into 70%, 60%, or less? So that's all about information. It's all about giving those hard-won lessons, hard-learned lessons back to founders and guiding them, I guess, in the best way we can. +WILL: Yeah, I love that. I love that. +MID-ROLL AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +WILL: Let's transition to talking a little bit about you. I love to just ask questions to the founders because, honestly, what founders go through just amazes me that you continue to go. You wake up, and you do it over and over again. So it's amazing, so kudos to you. So let's talk about that; why? Why do you wake up every morning and do EmergeOne, do Projected.ai, do the podcasts? What's your why? +AARISH: I'm in therapy trying to figure that answer out myself. +WILL: [laughs] +AARISH: No, look, I mean, I think what drives me, again, it's that sense of purpose of helping others. It's also scratching the itch. I think a lot of founders, it's about scratching that itch. There is something that you can see that is wrong in the universe, and you want to fix it. And if I think about those various sorts of businesses or podcasts, each of them attracts me in different ways. +So EmergeOne, we get to help lots of businesses, providing them really, really significant support. And we're working with great VCs, with great clients, great startups, and scaleups. At Projected, we get to expand that range because you're no longer reliant on one person providing a CFO service or a bench of 20 people or whatever. We can now do that across hundreds, thousands of startups if need be. +With the podcasts, it's a combination of learning and hopefully also providing some learning to others, helping them understand a bit more. So the Off Balance podcast these are like two-minute short episodes, which go into the detail of those 100 lessons that I've learned. And some of them are very, very personal to me, but they're probably applicable across most businesses. And all I'm doing is exploring those in a bit more detail and hopefully passing that on so that some other founder somewhere doesn't have to go through the same pain of learning that lesson. They can look out for the signals and figure out how to deal with it in advance. +And Nothing Ventured scratches my itch to learn more about the VC ecosystem. If you imagine I'd spent ten years out in New Guinea, I had no idea what venture capital was out there. I really didn't understand what the tech ecosystem was. When I arrived there, we were still on dial-up. There were no mobile telephones. It wasn't until 2008, 2009, that mobile telephony really kind of picked up over there. +So when I came back to the UK, I was just surrounded by all of this stuff which I was massively curious about. And so everything I've done since then is about scratching that curiosity and learning. And I think that that drives pretty much everything that I do in life in general, which is this huge passion to learn and understand the world a bit better and to hopefully pass on whatever I can to others because I think life's too short to hold it all for yourself. The more you can give, the better the world is. +WILL: Yeah, definitely, definitely. Let's give a sneak peek into Off Balance. You said that you use that to teach lessons that you've learned along the way. What have been some of the big obstacles that you've come across? +AARISH: Oh wow. I mean, there are 100 lessons in there, [laughs] so I'm going to have to pick a couple of my favorites. Okay, so one which actually I posted about today on LinkedIn it was like the episode we dropped today, which is "Hire Slow, Fire Fast." And I got a lot of flak about this actually talking about it on LinkedIn when I first posted it. +And the reason I think that I got a lot of flak was all people read were those four words: hire slow, fire fast. And they just assumed what I was saying was you should fire in the vein of a lot of the larger tech businesses over the last couple of years where maybe they've sent a mass text message or email and just sacked a bunch of people. And that's absolutely not what I'm advocating for. I think you should always be human when you are dealing with people all the time. +But the things that I've really learned is if you don't have a process to hire people well, you end up hiring the wrong people. And you end up hiring people that either don't have a fit in the business or are just not the right people in terms of their ability to do what you need them to do. And we're all probably aware of this fact by now, but it bears repeating, right? All of us when we are talking to other people, we look for reflections of ourselves. +So when we are hiring people, we look for people that emulate how we see ourselves, whether that's in the way they talk, in the way they dress, whether they look like us, or whether they come from a similar background. And I think those are all obviously negative biases that we all need to remove. And the way you can remove those is in a couple of ways, so, one, use data wherever possible and use data points. +Secondly, have a process that makes sure that you have a really strong top-of-the-funnel, bringing in candidates from across all sectors, all experiences. I make sure that there are several people involved in that process so that you're all giving your feedback on an individual so that you can make sure that, actually, I thought this person was going to be great in this role, but maybe my CTO thinks they're not; they're going to be mediocre. +We can have that conversation and understand where those challenges have come up, and hopefully get to a place where we either decide actually, yeah, you know what? We shouldn't hire this person. Or, actually, yeah, you know what? I think you're right. I'm convinced that this is the right person. We should go for them. +But I think the point is companies can lose hundreds of thousands of dollars hiring the wrong person, that's in recruitment fees, in training fees, and lost time, et cetera, et cetera. So it makes sense to do it right, right from the beginning. And the flip side of that is if you have hired someone and they turn out to be a toxic person or not fit for purpose in terms of the role that they're doing; the point is not to then just send them an SMS and say, you know, "You're fired." The point is, you know, Donald Trump style, no. +WILL: [laughs] +AARISH: The point is actually to take the decision really quickly. So if you realize that that person is not working out, then make the decision and execute on that decision as quickly as possible because I've seen it too often and have done it myself to the business' detriment. I've seen too often people sitting on a decision to move someone on. And that's ended up leading to problems in the business because other employees, other members of the team will recognize that toxicity or that person isn't pulling their weight, or they aren't able to do the job even. +And that will just lead to negative impact on the rest of the business as well. So that's definitely one I would always come back to is, like, hire slow, fire fast. I think I'm happy to take more flak on it because I strongly believe it is something that more founders and more businesses should take heed of. +And the other one, I think it was number one on my list for a reason, and that's cash trumps everything and today, even more so than anything else. I think businesses over the last, certainly in the venture ecosystem, over the last sort of five years, growth at all costs has been the mantra, and that's throwing dollars at marketing and just building new customers, or buying new customers, I should say, to supercharge growth when actually that isn't sustainable. And it doesn't necessarily lead to good outcomes in the future. +My preference is twofold, one, spend as much time and money as you can in cultivating your existing customers, make sure you're really giving them delight in whatever product or service you're providing them because that means that they're going to stay with you longer. They're going to pay themselves back in terms of how much it costs to acquire, and hopefully, they're going to be advocates for your business. And all of that basically leads to a better cash bottom line. +And today, always, but today over and above any other period, I think over the last 5, 10 years cash trumps everything because you are only as good as your runway. And when you run out of money in this market, it is very hard to go out and try and raise additional capital, and raising capital at the sort of valuations that people have also been used to over the last several years is getting harder and harder, if not impossible. +So those are probably the two that I would always come back to; it's the hire slow, fire fast, cash trumps everything. And it's better to spend money retaining and loving your customers than trying to constantly acquire new ones. +WILL: Yeah, I love that. I love that. Let's flip it to the other side, what have been some of your biggest wins in life? +AARISH: I mean, I'm going to say the obvious one. My biggest wins are my family, you know, my wife, my kids. I've got two beautiful daughters, one's 21, one's 15. I hope we've raised them to be well-adjusted children. We've given them, I think, the ability to go out and do what they want in life. And that's really important to me. My wife, her, and I have been together for 20 years. We've had our ups and downs, but today I think we make an amazing team. And I'm really fortunate to have her in my life. +If I think about wins and success in business, it's really hard for me and, again, because I think success is a state of mind. It's not something that you can chase. And I think too many people get caught up in this sort of idea of I'll be successful when. And what I mean is I'll be successful when I've raised that big series A, or I'll be successful when I've exited my business, or I'll be successful when I've made that huge sale, or when I've hired that rockstar employee or made it to founder, or whatever it is. +If you approach success with the attitude of you are already a success, whatever you're doing, you are alive today, living in one of the most exciting times on the planet. You are a successful human being; whatever anyone else says, that's a major win in itself. And understanding that state of mind that you have to be in is something that it takes a really long time to understand and really internalize. +And I think the way that I've managed to get to that place is I've realized that in the past, either I was chasing success or I was waiting for someone else to tell me that I've been successful. When in reality, if I judge success based on my own benchmarks, then it's impossible for me to look at what I've done and say I haven't been successful. I've got two businesses, two podcasts. Who knows? One of those businesses may fall over, one of those podcasts may not get a single listener or whatever. +But the mere fact that I've shown up and broken ground on all of that stuff for me is, I think, an indication of success. It's something I'm really proud of. And as I move forward in life, I'm always going to try to do better. But I already know that whatever successes or failures I may have in the future, I've already been successful. And I think that's the thing that all of us should hold on to in life. +WILL: Yeah, I totally agree with that, and I really, really like that. So I'm going to close it out with this: what advice would you go back and give yourself when you first started at the very beginning knowing what you know now? +AARISH: I would say from the age of like 15 to the age of getting on 37, 38, I was a product of what other people wanted, what I did at school, what I studied...well, what I studied at university was what I wanted to do, but it was almost in retaliation for what others wanted me to do. Where I worked, the sort of path that I trode was very much based on culturally, familiarly what was expected of me kind of growing up in a very middle-class and privileged background. +It wasn't until I came back to the UK from Papua New Guinea, where I basically came back with nothing to my name and no idea what I was going to do, and I started doing things that I wanted to do and started backing myself in spite of what other people were saying. So even when I left that first job working at the EdTech business, one of my cousins turned around and said, "Why are you leaving that job? It is paying you a really good salary. Like, why would you leave that to do this thing?" +And I had someone else, an angel investor who's one of my closest friends; she turned around and said, "Well, if one of my portfolio companies came and said, oh, they're looking to bring in a CFO, I'd tell them they're stupid and spend their money elsewhere." And I was like, "No, I can see that there is something to be done in this space. I'm going to go and do it." And, lo and behold, again, it's paid off. +And so I think the one piece of advice I would have given to myself, and I would give to everyone, is back yourself early on. You may not have the experience to do everything. You may not have the network. You may not have the cash. You may not have the friends and family that can invest in you or whatever it might be. But take that first step, back yourself because ultimately, if you can't back yourself, no one else is going to. +WILL: Wow, that's really good, really good. Wow, I really like that. Yeah. Yeah, I really liked that because it's kind of the initial stage of that self-care, especially as a founder. Like, if you don't believe in yourself, how can you even ask someone else for it? Because they can see, like, well, is this a good investment? Are you going to see it through, or are you going to quit? +AARISH: Yeah, and in fact, I'd add to that one of the other things I've said is, but I came to this late in life, is if my mind and my body aren't healthy, then my business can't be either. I realized quite late in life, as I say, probably mid-30s, again, that I'd probably done more damage to my body than I needed to through my diet, through whatever proclivities I may have had. +The most amazing I've ever felt is today, where I'm exercising daily, where I'm taking care of myself mentally, taking the time to think about what is important to me, and to show gratitude for a lot of stuff as well. And exactly as you say, if you're not looking after yourself, it's really, really hard to look after a business, to look after team members. +And certainly, when other people are looking at you, they're going to kind of sit there and say, "Well, how safe is my money in this guy's hands? Or do I think that this person is going to be able to see it through?" So 100% the two things are back yourself and look after yourself. I think those are two really important things. +WILL: All right, to close out the podcast, is there anything that you would like to share with the audience? +AARISH: I mean, I think it's been awesome speaking to you. I would love for everyone to come and check out Nothing Ventured and the Off Balance Podcast. And please connect with me on LinkedIn, follow me, follow me on Twitter. My handle is @adsinuk, so that's @A-D-S-I-N-U-K, both on LinkedIn and on Twitter. You can find me at Aarish Shah on LinkedIn, obviously, as well. I'm always keen to hear from people, learn from people, talk to them. All I would ask is be gentle with each other. Come find me. Come have a chat. And, yeah, it's been awesome speaking to you today. +WILL: Yeah, it's been great talking to you too. And I'm going to lead by leadership. And I'm going to look you up on LinkedIn, Twitter; check out the podcast. I'm excited about that. So I'm looking forward to it. +AARISH: Amazing. Thanks, man. +WILL: Yeah, thank you. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Aarish Shah. + + + Aarish Shah is the Founder of EmergeOne and Projected.ai and host of Off Balance and Nothing Ventured Podcast.

+ +

Will talks to Aarish about having the venture capitalist money idea and having that "aha!" moment that it could work, what drives him and having a purpose of helping others, and using his podcast to teach lessons that he's learned along the way.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Aarish Shah, Founder of EmergeOne and Projected.ai and host of Off Balance and Nothing Ventured Podcast. Aarish, thank you for joining me.

+ +

AARISH: It's great to be here, Will. Really happy to be talking to you today.

+ +

WILL: Yeah, I'm excited. I can't wait to dive in and learn more about you. Tell me about your journey, how it all started.

+ +

AARISH: Wow, it's a bit of a long run. I'll try and condense it. But I am 44 years old at the moment. About 20 years ago, I came out of uni with a degree in languages which I found was sort of useful but not essential. So I ended up for a few years doing kind of the normal corporate thing. I worked with PriceWaterhouseCoopers, Nortel Networks, and then Deutsche Bank. And I qualified as an accountant along the way, so I'm effectively what you guys would consider a CPA over in the U.S.

+ +

I then kind of up sticks, and I spent the next ten years of my life running a group of manufacturing and trading businesses alongside a property portfolio out in Papua New Guinea, which is a very, very interesting place to be, definitely one of the hardest environments to be building and running businesses for many reasons. I've had everything from people coming into one of my offices with guns. I had one of my factories burned to the ground and everything in between. So really, really great learning experience and certainly amazing to learn about physical products, you know, the manufacturing and distribution and sales and so on of actual physical products.

+ +

And then, in 2015, I came back to the UK. I didn't really know what I wanted to do. And so I had a bunch of coffees with people and ended up as founding CFO in an EdTech venture, which was a joint venture between Eton College, which is one of the premier schools here in the UK where famously all of our Prime Ministers seem to come from, and Founders Factory which is an accelerator that was founded by Brent Hoberman of lastminute.com fame. So that was really exciting.

+ +

I was straight off the boat from Papua New Guinea, sitting 10 feet away from Brent Hoberman, learning everything that there was to learn about the tech sector here in the UK and beyond. And had a really great couple of years working in that business and learning really everything there was to know about the VCA ecosystem, the early stage ecosystem, how to build products, how to finance them, how to sell into new territories (We were operating in China at the time.) and all sorts of other things.

+ +

And then, in 2017, I decided it was time to move on. And I became what you guys would probably call a fractional CFO. So I worked across C through Series C businesses, everything from EdTech to FinTech, D2C, B2B marketplaces, beauty tech, you name it, kind of been there, seen it, and done it. And in 2019 and 2020, started getting approached by FDs and CFOs that wanted to work with me. And I really doubled down at that stage and decided to build EmergeOne into what it is today, which is a consultancy providing CFO services to venture-backed tech startups and scaleups.

+ +

So we work with a huge bunch of businesses here in the UK that are backed by VCs, some of the big names here like Hoxton Ventures, Stride, Octopus, Outlier, Founders Factory, and others. And I'm really, really passionate about helping founders build their businesses in a scalable and sensible way, I guess, especially in the current environment. And so we're really lucky that we're trusted by these VCs and the founders that we work with to deliver really great services to them.

+ +

And then, a couple of years ago, because I've been working kind of in the tech sector for so long, I started noodling around with a couple of ideas of projects that I wanted to move forward with. I raised a really small kind of pre-seed back in 2021 and started building a product, which is today Projected.ai, which we have just launched. We're in the process of launching at the moment.

+ +

And what that is is effectively an email newsletter, if you can believe it, providing internal and external data to our client businesses. So effectively, it's like a flash report of your financials alongside some really sort of personalized news about what's going on in your industry, alongside some other sort of bits and bobs that we're currently building in.

+ +

On top of that, a couple of years ago, again, I realized that I had a really good network of people that I had relationships with, and I decided to launch the Nothing Ventured Podcast to start speaking with people that operated in the VC ecosystem here in the UK and beyond. So I've been really fortunate to have guests like Hussein Kanji from Hoxton Ventures, Mac Conwell from RareBreed ventures in the U.S., and various others. And I really got to talk to them about why they got into venture, what they see is happening in the market, what are they excited about. And all those sorts of things.

+ +

Because, to be honest, I'm really passionate about learning and understanding about where people are coming from, why they do what they do, what drives them, what they're passionate about, but equally, the sort of challenges they've also faced. And that's been going now for 60-odd episodes. We're launching Season 4 shortly. And I'm really lucky and fortunate to have been able to do that.

+ +

And then finally, at the back end of 2022, so in December, actually, just as I was jumping on a plane, I sort of released something on LinkedIn, which was like 100 lessons that I've learned as a CEO and CFO over the last 20 years of operating. And unexpectedly, the thing went viral. I've had close to a million views on it, thousands of likes, hundreds of comments, and reshares.

+ +

And I decided to turn what was effectively just a list into a short-form podcast, which has turned into Off Balance. So we're releasing that daily and kind of expanding on each and every one of those topics that I went through in that list. So, yeah, look, I mean, I'm someone with a finger in a lot of pies. I'm a massive generalist, so I love getting involved in different projects at different times. But I'm really fortunate to be able to do what I love doing. It's just been a wild journey for the last seven years, certainly, but the whole 20 years of my life.

+ +

WILL: I love it. I love it. I love every idea that you had weaves into that venture capitalist money idea. So let's start at EmergeOne. When did you have that aha moment that this could work?

+ +

AARISH: So I work a lot in strategy, so there are two forms of strategies, emergent and there's defined. So most people know about a strategy that is written down; it's a playbook. They go out, and they pursue it. For me, it was really emergent. Firstly, I realized that there were not that many great CFOs operating in tech, certainly here in the UK, because it's, to an extent, a nascent industry. And whilst there are great accountants, and there are great finance leaders in larger businesses, actually doing that in a startup or a scaleup is very, very different.

+ +

Now, don't get me wrong, there are some great CFOs out there. It's just that I think there are far fewer than many people [laughs] assume there to be. So that was kind of the first thing that twigged with me. And I was seeing a lot of businesses picking up people and calling them a CFO when I knew for a fact there was no way that they really had the experience to be able to call themselves a CFO or to operate as one. So I guess that was the first aha moment.

+ +

And the second aha moment was as I started talking to more and more VCs via the podcast, and just generally because I was out in the ecosystem talking to them, I realized that actually, the work that I was doing was not being driven necessarily by the client companies but actually by the VCs themselves because they wanted to make sure that having invested 1,2,5, 10 million pounds or dollars that those companies were in good hands and safe hands and that capital was being managed effectively and efficiently.

+ +

And obviously, we're sitting in January of 2023 now. Never has that been more appropriate. More and more businesses are struggling. They're struggling to raise. They're having to extend their runways and figure out how to manage their cash in a much, much more significant way than maybe they had to two or three years ago. And so, for us, that's like a massively important thing. And having a great CFO in your business is going to help you do that.

+ +

And therefore, we are getting approached more and more both by VCs as well as by companies that are just on the lookout for someone to help them. It was sort of a series of aha moments. But as I said earlier, it was an emergent strategy. It was something that kind of developed over time. But also, I'm someone that learned quite early on in my life to back myself.

+ +

I think I took the punt on building this agency, if you like because it felt right. And it felt like something that I would enjoy doing, and it felt like something that I could actually make a difference in. And I think all of those things kind of culminated in really making EmergeOne what it is today, and I'm really proud of what we've been able to achieve.

+ +

WILL: Yeah, I love that idea because I feel like, especially in startups, like you said, that excellent CFO is really hard to find. It's really hard to find. But if you don't have the numbers, you don't have a business. Let's be honest, the numbers you just don't have it.

+ +

AARISH: Yeah, it's crazy to me that over the last decade or so, we've had, obviously, this period of super cheap money, super cheap capital. People have been raising at very inflated valuations. But we're seeing all of that come home to roost. We're seeing that in the public markets. A lot of these companies that IPOed over the last several years, obviously, have had their valuations drop significantly, you know, companies like Peloton, I guess, and others.

+ +

People are starting to realize that actually cash is king. They need to understand how the cash is flowing through their business and to know that they need to have an intimate knowledge of their numbers. And, in fact, a lot of our role as a CFO in a business is to kind of coach the founder to make sure that they do understand those numbers and how they need to present them to internal stakeholders, external stakeholders, whether that's your board, whether that's investors, or whether that's your employees to make sure that people have a good idea of not only how they're tracking but where they're heading and where the end goal is. And I think it's massively important.

+ +

I've always been a massive advocate for people getting to grips with their numbers, even if you're not a numbers person. Because especially if you're a founder or you're the leader in the business, the CEO, ultimately, the buck stops with you. You've got to know those numbers. It's not good enough to say, "Well, my CFO, my accountant has a handle on them." Like, if you're sitting in an investor meeting trying to pitch them to raise 5 to 10 million bucks, you're going to need to know those numbers inside out. And it's astonishing how many people actually ignore those. And what I would say is, you know, ignore them at your peril.

+ +

WILL: Yeah, that just blows my mind because if I put myself in an investor seat if I'm giving you money, I want the head person, the CEO, to know exactly how to handle that money. So yeah, I love that idea, and I love what you're doing. Let's go on Projected.ai. And if I understand this correctly, this is more of a kind of [inaudible 10:51] the words.

+ +

AARISH: So it's like a newsletter on steroids.

+ +

WILL: Yeah, but it's to be honest about your numbers to board members and investors, correct?

+ +

AARISH: Yeah. So Projected.ai was born out of this understanding that I guess I have, which is that CFOs and finance professionals working in startups and scaleups and SMEs they have dashboard fatigue. We interviewed CFOs, and they're operating off like 20 different dashboards, each of them giving them different numbers, each of them telling them something different. And they don't even have time to look at those dashboards, let alone make decisions based on the numbers that are coming out of them.

+ +

So what we wanted to do with Projected was provide a touch point for that CFO where they could check in with their numbers in a really easy way on a consistent, regular basis. When I thought about this really clearly, I don't live in dashboards; where I live is in the tools I communicate in, so that's my emails, that may be my Slack channel, that may be WhatsApp or iMessage, or whatever it is that you use. But certainly, for business, it's going to be email and Slack for the most part.

+ +

So I thought, what is the easiest way to communicate with someone in their business? It is via one of those channels. And what are the things that they want to know? Well, they want to know what's happening in their business, what's changed in their numbers over the last week, or two weeks, or month, but also what's happening outside their business.

+ +

Because often, in startups, we get so kind of tunnel-visioned into what's happening inside the business. We don't take the time to look outside and figure out what others are doing or what may be happening in the macro environment that may have an impact on our business. And an obvious case of that at the moment is interest rates having moved up quite significantly over the last several months and still going to, as well as sort of inflation numbers also on their way up, and central banks everywhere trying to rein those in.

+ +

All of that is going to have an impact on your business, especially if you're a consumer business, for example. And if you don't factor in all of those things or if you don't look at all of the things that could impact your business, you're going to make decisions with imperfect information, and, therefore, you'll make imperfect decisions. Now, you're never going to have perfect information. But the more information, the more pertinent information you have, the more transparent you can be, exactly as you said, to your board, to your shareholders. Tell them exactly what's happening, and get their advice to help you through those rough patches.

+ +

Ultimately, we've got some tricks up our sleeves in terms of what we're going to be doing with those numbers, and how we're going to be presenting them, and how we're going to be manipulating them when we do show them to our users. But I kind of felt like we've moved past that time where CFOs were only about the numbers looking backwards. A really great CFO today is all about communication, information. It's about turning data into information, turning numbers into a narrative. Yeah, that's what we wanted to build, a tool that could support them and help them really be the best CFO they can be.

+ +

WILL: Yeah, that's amazing. Transparency is the word I was looking for. So you nailed it, yeah. So I love that idea, the transparency of the numbers of the business just using AI. So that's amazing. It makes it a lot easier to send it out and to make it happen. So I love that idea.

+ +

AARISH: Yeah. I mean, the interesting thing is; obviously, we've all been hearing a lot about generative AI and large language models at the moment. And we've definitely got plans to incorporate that into what we're doing. But the other side of that is you got to be really, really careful, obviously, because, as we all know, there are biases that can creep into any of those sort of AI-driven models. But equally, there are inaccuracies.

+ +

And, in fact, a lot of those models tend to be great with words, not great with numbers. So one has to be really, really careful about bringing those tools into play. And because we know what we're doing, we can assess for that and make sure that the information that we're putting out there is the right sort of information, but actually, what we can do in terms of modeling our cash flows and revenue and effectively forecasting out a business.

+ +

Because bearing in mind a lot of startups, most startups, most scaleups, most SMEs don't have the balance sheet. They don't have the money to go out there and build an AI tool themselves. They just simply don't. And they may not have the wherewithal in-house, but they almost certainly don't have the cash. So what we're doing is hopefully providing a bridge for them to get better information in terms of what's happening today but also maybe an inkling of what might happen tomorrow, which helps them, again, to plan better.

+ +

And, again, it comes back to this whole thing around decision making, transparency, and making sure that they're able to look at their numbers with confidence and communicate those to others with confidence, and really understand what's driving those numbers as they keep building their businesses.

+ +

But everything we do at Projected, everything I do definitely as a founder and as someone that operates in this ecosystem, is all driven by how do we make the ecosystem better? How do we help founders? How do we help their companies? How do we make sure we can drive that number down from 90% of startups failing within the first three or five years? How do we turn that number into 70%, 60%, or less? So that's all about information. It's all about giving those hard-won lessons, hard-learned lessons back to founders and guiding them, I guess, in the best way we can.

+ +

WILL: Yeah, I love that. I love that.

+ +

MID-ROLL AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

WILL: Let's transition to talking a little bit about you. I love to just ask questions to the founders because, honestly, what founders go through just amazes me that you continue to go. You wake up, and you do it over and over again. So it's amazing, so kudos to you. So let's talk about that; why? Why do you wake up every morning and do EmergeOne, do Projected.ai, do the podcasts? What's your why?

+ +

AARISH: I'm in therapy trying to figure that answer out myself.

+ +

WILL: [laughs]

+ +

AARISH: No, look, I mean, I think what drives me, again, it's that sense of purpose of helping others. It's also scratching the itch. I think a lot of founders, it's about scratching that itch. There is something that you can see that is wrong in the universe, and you want to fix it. And if I think about those various sorts of businesses or podcasts, each of them attracts me in different ways.

+ +

So EmergeOne, we get to help lots of businesses, providing them really, really significant support. And we're working with great VCs, with great clients, great startups, and scaleups. At Projected, we get to expand that range because you're no longer reliant on one person providing a CFO service or a bench of 20 people or whatever. We can now do that across hundreds, thousands of startups if need be.

+ +

With the podcasts, it's a combination of learning and hopefully also providing some learning to others, helping them understand a bit more. So the Off Balance podcast these are like two-minute short episodes, which go into the detail of those 100 lessons that I've learned. And some of them are very, very personal to me, but they're probably applicable across most businesses. And all I'm doing is exploring those in a bit more detail and hopefully passing that on so that some other founder somewhere doesn't have to go through the same pain of learning that lesson. They can look out for the signals and figure out how to deal with it in advance.

+ +

And Nothing Ventured scratches my itch to learn more about the VC ecosystem. If you imagine I'd spent ten years out in New Guinea, I had no idea what venture capital was out there. I really didn't understand what the tech ecosystem was. When I arrived there, we were still on dial-up. There were no mobile telephones. It wasn't until 2008, 2009, that mobile telephony really kind of picked up over there.

+ +

So when I came back to the UK, I was just surrounded by all of this stuff which I was massively curious about. And so everything I've done since then is about scratching that curiosity and learning. And I think that that drives pretty much everything that I do in life in general, which is this huge passion to learn and understand the world a bit better and to hopefully pass on whatever I can to others because I think life's too short to hold it all for yourself. The more you can give, the better the world is.

+ +

WILL: Yeah, definitely, definitely. Let's give a sneak peek into Off Balance. You said that you use that to teach lessons that you've learned along the way. What have been some of the big obstacles that you've come across?

+ +

AARISH: Oh wow. I mean, there are 100 lessons in there, [laughs] so I'm going to have to pick a couple of my favorites. Okay, so one which actually I posted about today on LinkedIn it was like the episode we dropped today, which is "Hire Slow, Fire Fast." And I got a lot of flak about this actually talking about it on LinkedIn when I first posted it.

+ +

And the reason I think that I got a lot of flak was all people read were those four words: hire slow, fire fast. And they just assumed what I was saying was you should fire in the vein of a lot of the larger tech businesses over the last couple of years where maybe they've sent a mass text message or email and just sacked a bunch of people. And that's absolutely not what I'm advocating for. I think you should always be human when you are dealing with people all the time.

+ +

But the things that I've really learned is if you don't have a process to hire people well, you end up hiring the wrong people. And you end up hiring people that either don't have a fit in the business or are just not the right people in terms of their ability to do what you need them to do. And we're all probably aware of this fact by now, but it bears repeating, right? All of us when we are talking to other people, we look for reflections of ourselves.

+ +

So when we are hiring people, we look for people that emulate how we see ourselves, whether that's in the way they talk, in the way they dress, whether they look like us, or whether they come from a similar background. And I think those are all obviously negative biases that we all need to remove. And the way you can remove those is in a couple of ways, so, one, use data wherever possible and use data points.

+ +

Secondly, have a process that makes sure that you have a really strong top-of-the-funnel, bringing in candidates from across all sectors, all experiences. I make sure that there are several people involved in that process so that you're all giving your feedback on an individual so that you can make sure that, actually, I thought this person was going to be great in this role, but maybe my CTO thinks they're not; they're going to be mediocre.

+ +

We can have that conversation and understand where those challenges have come up, and hopefully get to a place where we either decide actually, yeah, you know what? We shouldn't hire this person. Or, actually, yeah, you know what? I think you're right. I'm convinced that this is the right person. We should go for them.

+ +

But I think the point is companies can lose hundreds of thousands of dollars hiring the wrong person, that's in recruitment fees, in training fees, and lost time, et cetera, et cetera. So it makes sense to do it right, right from the beginning. And the flip side of that is if you have hired someone and they turn out to be a toxic person or not fit for purpose in terms of the role that they're doing; the point is not to then just send them an SMS and say, you know, "You're fired." The point is, you know, Donald Trump style, no.

+ +

WILL: [laughs]

+ +

AARISH: The point is actually to take the decision really quickly. So if you realize that that person is not working out, then make the decision and execute on that decision as quickly as possible because I've seen it too often and have done it myself to the business' detriment. I've seen too often people sitting on a decision to move someone on. And that's ended up leading to problems in the business because other employees, other members of the team will recognize that toxicity or that person isn't pulling their weight, or they aren't able to do the job even.

+ +

And that will just lead to negative impact on the rest of the business as well. So that's definitely one I would always come back to is, like, hire slow, fire fast. I think I'm happy to take more flak on it because I strongly believe it is something that more founders and more businesses should take heed of.

+ +

And the other one, I think it was number one on my list for a reason, and that's cash trumps everything and today, even more so than anything else. I think businesses over the last, certainly in the venture ecosystem, over the last sort of five years, growth at all costs has been the mantra, and that's throwing dollars at marketing and just building new customers, or buying new customers, I should say, to supercharge growth when actually that isn't sustainable. And it doesn't necessarily lead to good outcomes in the future.

+ +

My preference is twofold, one, spend as much time and money as you can in cultivating your existing customers, make sure you're really giving them delight in whatever product or service you're providing them because that means that they're going to stay with you longer. They're going to pay themselves back in terms of how much it costs to acquire, and hopefully, they're going to be advocates for your business. And all of that basically leads to a better cash bottom line.

+ +

And today, always, but today over and above any other period, I think over the last 5, 10 years cash trumps everything because you are only as good as your runway. And when you run out of money in this market, it is very hard to go out and try and raise additional capital, and raising capital at the sort of valuations that people have also been used to over the last several years is getting harder and harder, if not impossible.

+ +

So those are probably the two that I would always come back to; it's the hire slow, fire fast, cash trumps everything. And it's better to spend money retaining and loving your customers than trying to constantly acquire new ones.

+ +

WILL: Yeah, I love that. I love that. Let's flip it to the other side, what have been some of your biggest wins in life?

+ +

AARISH: I mean, I'm going to say the obvious one. My biggest wins are my family, you know, my wife, my kids. I've got two beautiful daughters, one's 21, one's 15. I hope we've raised them to be well-adjusted children. We've given them, I think, the ability to go out and do what they want in life. And that's really important to me. My wife, her, and I have been together for 20 years. We've had our ups and downs, but today I think we make an amazing team. And I'm really fortunate to have her in my life.

+ +

If I think about wins and success in business, it's really hard for me and, again, because I think success is a state of mind. It's not something that you can chase. And I think too many people get caught up in this sort of idea of I'll be successful when. And what I mean is I'll be successful when I've raised that big series A, or I'll be successful when I've exited my business, or I'll be successful when I've made that huge sale, or when I've hired that rockstar employee or made it to founder, or whatever it is.

+ +

If you approach success with the attitude of you are already a success, whatever you're doing, you are alive today, living in one of the most exciting times on the planet. You are a successful human being; whatever anyone else says, that's a major win in itself. And understanding that state of mind that you have to be in is something that it takes a really long time to understand and really internalize.

+ +

And I think the way that I've managed to get to that place is I've realized that in the past, either I was chasing success or I was waiting for someone else to tell me that I've been successful. When in reality, if I judge success based on my own benchmarks, then it's impossible for me to look at what I've done and say I haven't been successful. I've got two businesses, two podcasts. Who knows? One of those businesses may fall over, one of those podcasts may not get a single listener or whatever.

+ +

But the mere fact that I've shown up and broken ground on all of that stuff for me is, I think, an indication of success. It's something I'm really proud of. And as I move forward in life, I'm always going to try to do better. But I already know that whatever successes or failures I may have in the future, I've already been successful. And I think that's the thing that all of us should hold on to in life.

+ +

WILL: Yeah, I totally agree with that, and I really, really like that. So I'm going to close it out with this: what advice would you go back and give yourself when you first started at the very beginning knowing what you know now?

+ +

AARISH: I would say from the age of like 15 to the age of getting on 37, 38, I was a product of what other people wanted, what I did at school, what I studied...well, what I studied at university was what I wanted to do, but it was almost in retaliation for what others wanted me to do. Where I worked, the sort of path that I trode was very much based on culturally, familiarly what was expected of me kind of growing up in a very middle-class and privileged background.

+ +

It wasn't until I came back to the UK from Papua New Guinea, where I basically came back with nothing to my name and no idea what I was going to do, and I started doing things that I wanted to do and started backing myself in spite of what other people were saying. So even when I left that first job working at the EdTech business, one of my cousins turned around and said, "Why are you leaving that job? It is paying you a really good salary. Like, why would you leave that to do this thing?"

+ +

And I had someone else, an angel investor who's one of my closest friends; she turned around and said, "Well, if one of my portfolio companies came and said, oh, they're looking to bring in a CFO, I'd tell them they're stupid and spend their money elsewhere." And I was like, "No, I can see that there is something to be done in this space. I'm going to go and do it." And, lo and behold, again, it's paid off.

+ +

And so I think the one piece of advice I would have given to myself, and I would give to everyone, is back yourself early on. You may not have the experience to do everything. You may not have the network. You may not have the cash. You may not have the friends and family that can invest in you or whatever it might be. But take that first step, back yourself because ultimately, if you can't back yourself, no one else is going to.

+ +

WILL: Wow, that's really good, really good. Wow, I really like that. Yeah. Yeah, I really liked that because it's kind of the initial stage of that self-care, especially as a founder. Like, if you don't believe in yourself, how can you even ask someone else for it? Because they can see, like, well, is this a good investment? Are you going to see it through, or are you going to quit?

+ +

AARISH: Yeah, and in fact, I'd add to that one of the other things I've said is, but I came to this late in life, is if my mind and my body aren't healthy, then my business can't be either. I realized quite late in life, as I say, probably mid-30s, again, that I'd probably done more damage to my body than I needed to through my diet, through whatever proclivities I may have had.

+ +

The most amazing I've ever felt is today, where I'm exercising daily, where I'm taking care of myself mentally, taking the time to think about what is important to me, and to show gratitude for a lot of stuff as well. And exactly as you say, if you're not looking after yourself, it's really, really hard to look after a business, to look after team members.

+ +

And certainly, when other people are looking at you, they're going to kind of sit there and say, "Well, how safe is my money in this guy's hands? Or do I think that this person is going to be able to see it through?" So 100% the two things are back yourself and look after yourself. I think those are two really important things.

+ +

WILL: All right, to close out the podcast, is there anything that you would like to share with the audience?

+ +

AARISH: I mean, I think it's been awesome speaking to you. I would love for everyone to come and check out Nothing Ventured and the Off Balance Podcast. And please connect with me on LinkedIn, follow me, follow me on Twitter. My handle is @adsinuk, so that's @A-D-S-I-N-U-K, both on LinkedIn and on Twitter. You can find me at Aarish Shah on LinkedIn, obviously, as well. I'm always keen to hear from people, learn from people, talk to them. All I would ask is be gentle with each other. Come find me. Come have a chat. And, yeah, it's been awesome speaking to you today.

+ +

WILL: Yeah, it's been great talking to you too. And I'm going to lead by leadership. And I'm going to look you up on LinkedIn, Twitter; check out the podcast. I'm excited about that. So I'm looking forward to it.

+ +

AARISH: Amazing. Thanks, man.

+ +

WILL: Yeah, thank you. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Aarish Shah.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Aarish Shah is the Founder of EmergeOne and Projected.ai and host of Off Balance and Nothing Ventured Podcast.

+ +

Will talks to Aarish about having the venture capitalist money idea and having that "aha!" moment that it could work, what drives him and having a purpose of helping others, and using his podcast to teach lessons that he's learned along the way.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Aarish Shah, Founder of EmergeOne and Projected.ai and host of Off Balance and Nothing Ventured Podcast. Aarish, thank you for joining me.

+ +

AARISH: It's great to be here, Will. Really happy to be talking to you today.

+ +

WILL: Yeah, I'm excited. I can't wait to dive in and learn more about you. Tell me about your journey, how it all started.

+ +

AARISH: Wow, it's a bit of a long run. I'll try and condense it. But I am 44 years old at the moment. About 20 years ago, I came out of uni with a degree in languages which I found was sort of useful but not essential. So I ended up for a few years doing kind of the normal corporate thing. I worked with PriceWaterhouseCoopers, Nortel Networks, and then Deutsche Bank. And I qualified as an accountant along the way, so I'm effectively what you guys would consider a CPA over in the U.S.

+ +

I then kind of up sticks, and I spent the next ten years of my life running a group of manufacturing and trading businesses alongside a property portfolio out in Papua New Guinea, which is a very, very interesting place to be, definitely one of the hardest environments to be building and running businesses for many reasons. I've had everything from people coming into one of my offices with guns. I had one of my factories burned to the ground and everything in between. So really, really great learning experience and certainly amazing to learn about physical products, you know, the manufacturing and distribution and sales and so on of actual physical products.

+ +

And then, in 2015, I came back to the UK. I didn't really know what I wanted to do. And so I had a bunch of coffees with people and ended up as founding CFO in an EdTech venture, which was a joint venture between Eton College, which is one of the premier schools here in the UK where famously all of our Prime Ministers seem to come from, and Founders Factory which is an accelerator that was founded by Brent Hoberman of lastminute.com fame. So that was really exciting.

+ +

I was straight off the boat from Papua New Guinea, sitting 10 feet away from Brent Hoberman, learning everything that there was to learn about the tech sector here in the UK and beyond. And had a really great couple of years working in that business and learning really everything there was to know about the VCA ecosystem, the early stage ecosystem, how to build products, how to finance them, how to sell into new territories (We were operating in China at the time.) and all sorts of other things.

+ +

And then, in 2017, I decided it was time to move on. And I became what you guys would probably call a fractional CFO. So I worked across C through Series C businesses, everything from EdTech to FinTech, D2C, B2B marketplaces, beauty tech, you name it, kind of been there, seen it, and done it. And in 2019 and 2020, started getting approached by FDs and CFOs that wanted to work with me. And I really doubled down at that stage and decided to build EmergeOne into what it is today, which is a consultancy providing CFO services to venture-backed tech startups and scaleups.

+ +

So we work with a huge bunch of businesses here in the UK that are backed by VCs, some of the big names here like Hoxton Ventures, Stride, Octopus, Outlier, Founders Factory, and others. And I'm really, really passionate about helping founders build their businesses in a scalable and sensible way, I guess, especially in the current environment. And so we're really lucky that we're trusted by these VCs and the founders that we work with to deliver really great services to them.

+ +

And then, a couple of years ago, because I've been working kind of in the tech sector for so long, I started noodling around with a couple of ideas of projects that I wanted to move forward with. I raised a really small kind of pre-seed back in 2021 and started building a product, which is today Projected.ai, which we have just launched. We're in the process of launching at the moment.

+ +

And what that is is effectively an email newsletter, if you can believe it, providing internal and external data to our client businesses. So effectively, it's like a flash report of your financials alongside some really sort of personalized news about what's going on in your industry, alongside some other sort of bits and bobs that we're currently building in.

+ +

On top of that, a couple of years ago, again, I realized that I had a really good network of people that I had relationships with, and I decided to launch the Nothing Ventured Podcast to start speaking with people that operated in the VC ecosystem here in the UK and beyond. So I've been really fortunate to have guests like Hussein Kanji from Hoxton Ventures, Mac Conwell from RareBreed ventures in the U.S., and various others. And I really got to talk to them about why they got into venture, what they see is happening in the market, what are they excited about. And all those sorts of things.

+ +

Because, to be honest, I'm really passionate about learning and understanding about where people are coming from, why they do what they do, what drives them, what they're passionate about, but equally, the sort of challenges they've also faced. And that's been going now for 60-odd episodes. We're launching Season 4 shortly. And I'm really lucky and fortunate to have been able to do that.

+ +

And then finally, at the back end of 2022, so in December, actually, just as I was jumping on a plane, I sort of released something on LinkedIn, which was like 100 lessons that I've learned as a CEO and CFO over the last 20 years of operating. And unexpectedly, the thing went viral. I've had close to a million views on it, thousands of likes, hundreds of comments, and reshares.

+ +

And I decided to turn what was effectively just a list into a short-form podcast, which has turned into Off Balance. So we're releasing that daily and kind of expanding on each and every one of those topics that I went through in that list. So, yeah, look, I mean, I'm someone with a finger in a lot of pies. I'm a massive generalist, so I love getting involved in different projects at different times. But I'm really fortunate to be able to do what I love doing. It's just been a wild journey for the last seven years, certainly, but the whole 20 years of my life.

+ +

WILL: I love it. I love it. I love every idea that you had weaves into that venture capitalist money idea. So let's start at EmergeOne. When did you have that aha moment that this could work?

+ +

AARISH: So I work a lot in strategy, so there are two forms of strategies, emergent and there's defined. So most people know about a strategy that is written down; it's a playbook. They go out, and they pursue it. For me, it was really emergent. Firstly, I realized that there were not that many great CFOs operating in tech, certainly here in the UK, because it's, to an extent, a nascent industry. And whilst there are great accountants, and there are great finance leaders in larger businesses, actually doing that in a startup or a scaleup is very, very different.

+ +

Now, don't get me wrong, there are some great CFOs out there. It's just that I think there are far fewer than many people [laughs] assume there to be. So that was kind of the first thing that twigged with me. And I was seeing a lot of businesses picking up people and calling them a CFO when I knew for a fact there was no way that they really had the experience to be able to call themselves a CFO or to operate as one. So I guess that was the first aha moment.

+ +

And the second aha moment was as I started talking to more and more VCs via the podcast, and just generally because I was out in the ecosystem talking to them, I realized that actually, the work that I was doing was not being driven necessarily by the client companies but actually by the VCs themselves because they wanted to make sure that having invested 1,2,5, 10 million pounds or dollars that those companies were in good hands and safe hands and that capital was being managed effectively and efficiently.

+ +

And obviously, we're sitting in January of 2023 now. Never has that been more appropriate. More and more businesses are struggling. They're struggling to raise. They're having to extend their runways and figure out how to manage their cash in a much, much more significant way than maybe they had to two or three years ago. And so, for us, that's like a massively important thing. And having a great CFO in your business is going to help you do that.

+ +

And therefore, we are getting approached more and more both by VCs as well as by companies that are just on the lookout for someone to help them. It was sort of a series of aha moments. But as I said earlier, it was an emergent strategy. It was something that kind of developed over time. But also, I'm someone that learned quite early on in my life to back myself.

+ +

I think I took the punt on building this agency, if you like because it felt right. And it felt like something that I would enjoy doing, and it felt like something that I could actually make a difference in. And I think all of those things kind of culminated in really making EmergeOne what it is today, and I'm really proud of what we've been able to achieve.

+ +

WILL: Yeah, I love that idea because I feel like, especially in startups, like you said, that excellent CFO is really hard to find. It's really hard to find. But if you don't have the numbers, you don't have a business. Let's be honest, the numbers you just don't have it.

+ +

AARISH: Yeah, it's crazy to me that over the last decade or so, we've had, obviously, this period of super cheap money, super cheap capital. People have been raising at very inflated valuations. But we're seeing all of that come home to roost. We're seeing that in the public markets. A lot of these companies that IPOed over the last several years, obviously, have had their valuations drop significantly, you know, companies like Peloton, I guess, and others.

+ +

People are starting to realize that actually cash is king. They need to understand how the cash is flowing through their business and to know that they need to have an intimate knowledge of their numbers. And, in fact, a lot of our role as a CFO in a business is to kind of coach the founder to make sure that they do understand those numbers and how they need to present them to internal stakeholders, external stakeholders, whether that's your board, whether that's investors, or whether that's your employees to make sure that people have a good idea of not only how they're tracking but where they're heading and where the end goal is. And I think it's massively important.

+ +

I've always been a massive advocate for people getting to grips with their numbers, even if you're not a numbers person. Because especially if you're a founder or you're the leader in the business, the CEO, ultimately, the buck stops with you. You've got to know those numbers. It's not good enough to say, "Well, my CFO, my accountant has a handle on them." Like, if you're sitting in an investor meeting trying to pitch them to raise 5 to 10 million bucks, you're going to need to know those numbers inside out. And it's astonishing how many people actually ignore those. And what I would say is, you know, ignore them at your peril.

+ +

WILL: Yeah, that just blows my mind because if I put myself in an investor seat if I'm giving you money, I want the head person, the CEO, to know exactly how to handle that money. So yeah, I love that idea, and I love what you're doing. Let's go on Projected.ai. And if I understand this correctly, this is more of a kind of [inaudible 10:51] the words.

+ +

AARISH: So it's like a newsletter on steroids.

+ +

WILL: Yeah, but it's to be honest about your numbers to board members and investors, correct?

+ +

AARISH: Yeah. So Projected.ai was born out of this understanding that I guess I have, which is that CFOs and finance professionals working in startups and scaleups and SMEs they have dashboard fatigue. We interviewed CFOs, and they're operating off like 20 different dashboards, each of them giving them different numbers, each of them telling them something different. And they don't even have time to look at those dashboards, let alone make decisions based on the numbers that are coming out of them.

+ +

So what we wanted to do with Projected was provide a touch point for that CFO where they could check in with their numbers in a really easy way on a consistent, regular basis. When I thought about this really clearly, I don't live in dashboards; where I live is in the tools I communicate in, so that's my emails, that may be my Slack channel, that may be WhatsApp or iMessage, or whatever it is that you use. But certainly, for business, it's going to be email and Slack for the most part.

+ +

So I thought, what is the easiest way to communicate with someone in their business? It is via one of those channels. And what are the things that they want to know? Well, they want to know what's happening in their business, what's changed in their numbers over the last week, or two weeks, or month, but also what's happening outside their business.

+ +

Because often, in startups, we get so kind of tunnel-visioned into what's happening inside the business. We don't take the time to look outside and figure out what others are doing or what may be happening in the macro environment that may have an impact on our business. And an obvious case of that at the moment is interest rates having moved up quite significantly over the last several months and still going to, as well as sort of inflation numbers also on their way up, and central banks everywhere trying to rein those in.

+ +

All of that is going to have an impact on your business, especially if you're a consumer business, for example. And if you don't factor in all of those things or if you don't look at all of the things that could impact your business, you're going to make decisions with imperfect information, and, therefore, you'll make imperfect decisions. Now, you're never going to have perfect information. But the more information, the more pertinent information you have, the more transparent you can be, exactly as you said, to your board, to your shareholders. Tell them exactly what's happening, and get their advice to help you through those rough patches.

+ +

Ultimately, we've got some tricks up our sleeves in terms of what we're going to be doing with those numbers, and how we're going to be presenting them, and how we're going to be manipulating them when we do show them to our users. But I kind of felt like we've moved past that time where CFOs were only about the numbers looking backwards. A really great CFO today is all about communication, information. It's about turning data into information, turning numbers into a narrative. Yeah, that's what we wanted to build, a tool that could support them and help them really be the best CFO they can be.

+ +

WILL: Yeah, that's amazing. Transparency is the word I was looking for. So you nailed it, yeah. So I love that idea, the transparency of the numbers of the business just using AI. So that's amazing. It makes it a lot easier to send it out and to make it happen. So I love that idea.

+ +

AARISH: Yeah. I mean, the interesting thing is; obviously, we've all been hearing a lot about generative AI and large language models at the moment. And we've definitely got plans to incorporate that into what we're doing. But the other side of that is you got to be really, really careful, obviously, because, as we all know, there are biases that can creep into any of those sort of AI-driven models. But equally, there are inaccuracies.

+ +

And, in fact, a lot of those models tend to be great with words, not great with numbers. So one has to be really, really careful about bringing those tools into play. And because we know what we're doing, we can assess for that and make sure that the information that we're putting out there is the right sort of information, but actually, what we can do in terms of modeling our cash flows and revenue and effectively forecasting out a business.

+ +

Because bearing in mind a lot of startups, most startups, most scaleups, most SMEs don't have the balance sheet. They don't have the money to go out there and build an AI tool themselves. They just simply don't. And they may not have the wherewithal in-house, but they almost certainly don't have the cash. So what we're doing is hopefully providing a bridge for them to get better information in terms of what's happening today but also maybe an inkling of what might happen tomorrow, which helps them, again, to plan better.

+ +

And, again, it comes back to this whole thing around decision making, transparency, and making sure that they're able to look at their numbers with confidence and communicate those to others with confidence, and really understand what's driving those numbers as they keep building their businesses.

+ +

But everything we do at Projected, everything I do definitely as a founder and as someone that operates in this ecosystem, is all driven by how do we make the ecosystem better? How do we help founders? How do we help their companies? How do we make sure we can drive that number down from 90% of startups failing within the first three or five years? How do we turn that number into 70%, 60%, or less? So that's all about information. It's all about giving those hard-won lessons, hard-learned lessons back to founders and guiding them, I guess, in the best way we can.

+ +

WILL: Yeah, I love that. I love that.

+ +

MID-ROLL AD:
+thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

WILL: Let's transition to talking a little bit about you. I love to just ask questions to the founders because, honestly, what founders go through just amazes me that you continue to go. You wake up, and you do it over and over again. So it's amazing, so kudos to you. So let's talk about that; why? Why do you wake up every morning and do EmergeOne, do Projected.ai, do the podcasts? What's your why?

+ +

AARISH: I'm in therapy trying to figure that answer out myself.

+ +

WILL: [laughs]

+ +

AARISH: No, look, I mean, I think what drives me, again, it's that sense of purpose of helping others. It's also scratching the itch. I think a lot of founders, it's about scratching that itch. There is something that you can see that is wrong in the universe, and you want to fix it. And if I think about those various sorts of businesses or podcasts, each of them attracts me in different ways.

+ +

So EmergeOne, we get to help lots of businesses, providing them really, really significant support. And we're working with great VCs, with great clients, great startups, and scaleups. At Projected, we get to expand that range because you're no longer reliant on one person providing a CFO service or a bench of 20 people or whatever. We can now do that across hundreds, thousands of startups if need be.

+ +

With the podcasts, it's a combination of learning and hopefully also providing some learning to others, helping them understand a bit more. So the Off Balance podcast these are like two-minute short episodes, which go into the detail of those 100 lessons that I've learned. And some of them are very, very personal to me, but they're probably applicable across most businesses. And all I'm doing is exploring those in a bit more detail and hopefully passing that on so that some other founder somewhere doesn't have to go through the same pain of learning that lesson. They can look out for the signals and figure out how to deal with it in advance.

+ +

And Nothing Ventured scratches my itch to learn more about the VC ecosystem. If you imagine I'd spent ten years out in New Guinea, I had no idea what venture capital was out there. I really didn't understand what the tech ecosystem was. When I arrived there, we were still on dial-up. There were no mobile telephones. It wasn't until 2008, 2009, that mobile telephony really kind of picked up over there.

+ +

So when I came back to the UK, I was just surrounded by all of this stuff which I was massively curious about. And so everything I've done since then is about scratching that curiosity and learning. And I think that that drives pretty much everything that I do in life in general, which is this huge passion to learn and understand the world a bit better and to hopefully pass on whatever I can to others because I think life's too short to hold it all for yourself. The more you can give, the better the world is.

+ +

WILL: Yeah, definitely, definitely. Let's give a sneak peek into Off Balance. You said that you use that to teach lessons that you've learned along the way. What have been some of the big obstacles that you've come across?

+ +

AARISH: Oh wow. I mean, there are 100 lessons in there, [laughs] so I'm going to have to pick a couple of my favorites. Okay, so one which actually I posted about today on LinkedIn it was like the episode we dropped today, which is "Hire Slow, Fire Fast." And I got a lot of flak about this actually talking about it on LinkedIn when I first posted it.

+ +

And the reason I think that I got a lot of flak was all people read were those four words: hire slow, fire fast. And they just assumed what I was saying was you should fire in the vein of a lot of the larger tech businesses over the last couple of years where maybe they've sent a mass text message or email and just sacked a bunch of people. And that's absolutely not what I'm advocating for. I think you should always be human when you are dealing with people all the time.

+ +

But the things that I've really learned is if you don't have a process to hire people well, you end up hiring the wrong people. And you end up hiring people that either don't have a fit in the business or are just not the right people in terms of their ability to do what you need them to do. And we're all probably aware of this fact by now, but it bears repeating, right? All of us when we are talking to other people, we look for reflections of ourselves.

+ +

So when we are hiring people, we look for people that emulate how we see ourselves, whether that's in the way they talk, in the way they dress, whether they look like us, or whether they come from a similar background. And I think those are all obviously negative biases that we all need to remove. And the way you can remove those is in a couple of ways, so, one, use data wherever possible and use data points.

+ +

Secondly, have a process that makes sure that you have a really strong top-of-the-funnel, bringing in candidates from across all sectors, all experiences. I make sure that there are several people involved in that process so that you're all giving your feedback on an individual so that you can make sure that, actually, I thought this person was going to be great in this role, but maybe my CTO thinks they're not; they're going to be mediocre.

+ +

We can have that conversation and understand where those challenges have come up, and hopefully get to a place where we either decide actually, yeah, you know what? We shouldn't hire this person. Or, actually, yeah, you know what? I think you're right. I'm convinced that this is the right person. We should go for them.

+ +

But I think the point is companies can lose hundreds of thousands of dollars hiring the wrong person, that's in recruitment fees, in training fees, and lost time, et cetera, et cetera. So it makes sense to do it right, right from the beginning. And the flip side of that is if you have hired someone and they turn out to be a toxic person or not fit for purpose in terms of the role that they're doing; the point is not to then just send them an SMS and say, you know, "You're fired." The point is, you know, Donald Trump style, no.

+ +

WILL: [laughs]

+ +

AARISH: The point is actually to take the decision really quickly. So if you realize that that person is not working out, then make the decision and execute on that decision as quickly as possible because I've seen it too often and have done it myself to the business' detriment. I've seen too often people sitting on a decision to move someone on. And that's ended up leading to problems in the business because other employees, other members of the team will recognize that toxicity or that person isn't pulling their weight, or they aren't able to do the job even.

+ +

And that will just lead to negative impact on the rest of the business as well. So that's definitely one I would always come back to is, like, hire slow, fire fast. I think I'm happy to take more flak on it because I strongly believe it is something that more founders and more businesses should take heed of.

+ +

And the other one, I think it was number one on my list for a reason, and that's cash trumps everything and today, even more so than anything else. I think businesses over the last, certainly in the venture ecosystem, over the last sort of five years, growth at all costs has been the mantra, and that's throwing dollars at marketing and just building new customers, or buying new customers, I should say, to supercharge growth when actually that isn't sustainable. And it doesn't necessarily lead to good outcomes in the future.

+ +

My preference is twofold, one, spend as much time and money as you can in cultivating your existing customers, make sure you're really giving them delight in whatever product or service you're providing them because that means that they're going to stay with you longer. They're going to pay themselves back in terms of how much it costs to acquire, and hopefully, they're going to be advocates for your business. And all of that basically leads to a better cash bottom line.

+ +

And today, always, but today over and above any other period, I think over the last 5, 10 years cash trumps everything because you are only as good as your runway. And when you run out of money in this market, it is very hard to go out and try and raise additional capital, and raising capital at the sort of valuations that people have also been used to over the last several years is getting harder and harder, if not impossible.

+ +

So those are probably the two that I would always come back to; it's the hire slow, fire fast, cash trumps everything. And it's better to spend money retaining and loving your customers than trying to constantly acquire new ones.

+ +

WILL: Yeah, I love that. I love that. Let's flip it to the other side, what have been some of your biggest wins in life?

+ +

AARISH: I mean, I'm going to say the obvious one. My biggest wins are my family, you know, my wife, my kids. I've got two beautiful daughters, one's 21, one's 15. I hope we've raised them to be well-adjusted children. We've given them, I think, the ability to go out and do what they want in life. And that's really important to me. My wife, her, and I have been together for 20 years. We've had our ups and downs, but today I think we make an amazing team. And I'm really fortunate to have her in my life.

+ +

If I think about wins and success in business, it's really hard for me and, again, because I think success is a state of mind. It's not something that you can chase. And I think too many people get caught up in this sort of idea of I'll be successful when. And what I mean is I'll be successful when I've raised that big series A, or I'll be successful when I've exited my business, or I'll be successful when I've made that huge sale, or when I've hired that rockstar employee or made it to founder, or whatever it is.

+ +

If you approach success with the attitude of you are already a success, whatever you're doing, you are alive today, living in one of the most exciting times on the planet. You are a successful human being; whatever anyone else says, that's a major win in itself. And understanding that state of mind that you have to be in is something that it takes a really long time to understand and really internalize.

+ +

And I think the way that I've managed to get to that place is I've realized that in the past, either I was chasing success or I was waiting for someone else to tell me that I've been successful. When in reality, if I judge success based on my own benchmarks, then it's impossible for me to look at what I've done and say I haven't been successful. I've got two businesses, two podcasts. Who knows? One of those businesses may fall over, one of those podcasts may not get a single listener or whatever.

+ +

But the mere fact that I've shown up and broken ground on all of that stuff for me is, I think, an indication of success. It's something I'm really proud of. And as I move forward in life, I'm always going to try to do better. But I already know that whatever successes or failures I may have in the future, I've already been successful. And I think that's the thing that all of us should hold on to in life.

+ +

WILL: Yeah, I totally agree with that, and I really, really like that. So I'm going to close it out with this: what advice would you go back and give yourself when you first started at the very beginning knowing what you know now?

+ +

AARISH: I would say from the age of like 15 to the age of getting on 37, 38, I was a product of what other people wanted, what I did at school, what I studied...well, what I studied at university was what I wanted to do, but it was almost in retaliation for what others wanted me to do. Where I worked, the sort of path that I trode was very much based on culturally, familiarly what was expected of me kind of growing up in a very middle-class and privileged background.

+ +

It wasn't until I came back to the UK from Papua New Guinea, where I basically came back with nothing to my name and no idea what I was going to do, and I started doing things that I wanted to do and started backing myself in spite of what other people were saying. So even when I left that first job working at the EdTech business, one of my cousins turned around and said, "Why are you leaving that job? It is paying you a really good salary. Like, why would you leave that to do this thing?"

+ +

And I had someone else, an angel investor who's one of my closest friends; she turned around and said, "Well, if one of my portfolio companies came and said, oh, they're looking to bring in a CFO, I'd tell them they're stupid and spend their money elsewhere." And I was like, "No, I can see that there is something to be done in this space. I'm going to go and do it." And, lo and behold, again, it's paid off.

+ +

And so I think the one piece of advice I would have given to myself, and I would give to everyone, is back yourself early on. You may not have the experience to do everything. You may not have the network. You may not have the cash. You may not have the friends and family that can invest in you or whatever it might be. But take that first step, back yourself because ultimately, if you can't back yourself, no one else is going to.

+ +

WILL: Wow, that's really good, really good. Wow, I really like that. Yeah. Yeah, I really liked that because it's kind of the initial stage of that self-care, especially as a founder. Like, if you don't believe in yourself, how can you even ask someone else for it? Because they can see, like, well, is this a good investment? Are you going to see it through, or are you going to quit?

+ +

AARISH: Yeah, and in fact, I'd add to that one of the other things I've said is, but I came to this late in life, is if my mind and my body aren't healthy, then my business can't be either. I realized quite late in life, as I say, probably mid-30s, again, that I'd probably done more damage to my body than I needed to through my diet, through whatever proclivities I may have had.

+ +

The most amazing I've ever felt is today, where I'm exercising daily, where I'm taking care of myself mentally, taking the time to think about what is important to me, and to show gratitude for a lot of stuff as well. And exactly as you say, if you're not looking after yourself, it's really, really hard to look after a business, to look after team members.

+ +

And certainly, when other people are looking at you, they're going to kind of sit there and say, "Well, how safe is my money in this guy's hands? Or do I think that this person is going to be able to see it through?" So 100% the two things are back yourself and look after yourself. I think those are two really important things.

+ +

WILL: All right, to close out the podcast, is there anything that you would like to share with the audience?

+ +

AARISH: I mean, I think it's been awesome speaking to you. I would love for everyone to come and check out Nothing Ventured and the Off Balance Podcast. And please connect with me on LinkedIn, follow me, follow me on Twitter. My handle is @adsinuk, so that's @A-D-S-I-N-U-K, both on LinkedIn and on Twitter. You can find me at Aarish Shah on LinkedIn, obviously, as well. I'm always keen to hear from people, learn from people, talk to them. All I would ask is be gentle with each other. Come find me. Come have a chat. And, yeah, it's been awesome speaking to you today.

+ +

WILL: Yeah, it's been great talking to you too. And I'm going to lead by leadership. And I'm going to look you up on LinkedIn, Twitter; check out the podcast. I'm excited about that. So I'm looking forward to it.

+ +

AARISH: Amazing. Thanks, man.

+ +

WILL: Yeah, thank you. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Aarish Shah.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dAiqsmpU + + ]]> + + Will Larry + Aarish Shah + + + 462: StoryGraph with Nadia Odunayo + https://podcast.thoughtbot.com/462 + 80de0af8-6b1c-4eff-8940-66c7a752c426 + Thu, 16 Feb 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Nadia Odunayo is the Founder and CEO of The StoryGraph, a new website and app for avid book readers because life's too short for a book you're not in the mood for. The StoryGraph helps you track your reading and choose your next book based on your mood, favorite topics, and themes. + +Victoria talks to Nadia about coming up with a product based on the concept of mood, what you're in the mood for to read, i.e., this book made me feel this way. How do I find a book that makes me feel similar? They also talk about keeping yourself open to feedback, the ability to flow and change direction, and developing a reviewing system that keeps biases in check. + 43:27 + no + + + Nadia Odunayo is the Founder and CEO of The StoryGraph, a new website and app for avid book readers because life's too short for a book you're not in the mood for. The StoryGraph helps you track your reading and choose your next book based on your mood, favorite topics, and themes. +Victoria talks to Nadia about coming up with a product based on the concept of mood, what you're in the mood for to read, i.e., this book made me feel this way. How do I find a book that makes me feel similar? They also talk about keeping yourself open to feedback, the ability to flow and change direction, and developing a reviewing system that keeps biases in check. +StoryGraph (https://thestorygraph.com/) +Follow StoryGraph on LinkedIn (https://www.linkedin.com/company/the-storygraph-limited/), Instagram (https://www.instagram.com/the.storygraph/), or Twitter (https://twitter.com/thestorygraph). +Follow Nadia Odunayo on LinkedIn (https://www.linkedin.com/in/nodunayo/) or Twitter (https://twitter.com/nodunayo). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Nadia Odunayo, Founder and CEO of StoryGraph, a new website and app for avid book readers because life's too short for a book you're not in the mood for. StoryGraph helps you track your reading and choose your next book based on your mood and your favorite topics and themes. Nadia, thank you for joining me. +NADIA: Thank you for having me. +VICTORIA: And you are a repeat guest at Giant Robots. But for those who missed that episode, tell me a little bit about your journey. And how did this all get started? +NADIA: Okay. Yeah, so that first time was in 2015, and that was not too long after I had just got into tech. I did a bootcamp in London in 2014, Makers Academy, and that's where I learned to code. My degree was in philosophy, politics, and economics, so rather different. I worked at Pivotal for about a year and a half after I graduated from Makers Academy. And during my time at Pivotal, I got into conference speaking, and my first talk was around game theory. +So I took my favorite topic in economics, game theory, and I combined that with distributed systems because that's what I was working on at the time in Pivotal on their Cloud Foundry PaaS. I think I gave it at RailsConf, and I think someone there recommended me to Giant Robots. And so Ben Orenstein interviewed me, and it was all about different types of conference talks and that kind of thing. +So after Pivotal, I left and started a hybrid kind of consultancy/product company with a colleague, did that for about a year, left that, worked for about a year with my friend, Saron Yitbarek, on her company CodeNewbie. And then, when that partnership ended, I essentially had five years of runway from money that I got from the company that I started after Pivotal because we did some consulting with a bank. +I'd always been entrepreneurial. I'd been doing various entrepreneurial things since secondary school, actually, high school. It was time for me to just have time on my side projects. And so I started hacking away on one of my side projects at the beginning of 2019 in January, and I haven't stopped since. That's what the StoryGraph has developed into. +VICTORIA: Wonderful. And yes, I saw that the very early stages of StoryGraph started as a creative writing e-publication. Is that right? +NADIA: So what happened was when I was at university, I started a creative writing e-publication, came up with the name The StoryGraph. Because we had won or we were going for some grant funding or something like that, I set up a corporate entity. And when I stopped working on that e-publication, I remember my mom saying to me, "Don't shut down the entity. I really like the name. I feel like you'll use it for something," that was in 2012. +And so fast forward to 2019, and the side project that I was working on was called Read Lists. And it was very specifically focused on tracking and sharing progress through reading lists on a dashboard. But when I was doing customer research, and the scope of the project grew, Read Lists didn't fit anymore. And that's when I realized, oh, I can use The StoryGraph thing again. And so it's basically had two different lives or two different forms, the StoryGraph company. +VICTORIA: That's wonderful. And I'm reading about StoryGraph and how it's an Amazon-free alternative to Goodreads. Can you talk a little bit more about the product and why people would want to use it? +NADIA: So, as I said, it started life as a very specific focused side project. And I just had so much fun working on it and working in the book space. I'd always been a reader since I was a kid such that I said to myself, I need to find a way to make me building a books product a full-time thing. And so that's when customer research came in because the only way that you're going to make sure that you don't build something that people don't want is by talking to people. +As I was doing customer research and figuring out, are there pain points amongst readers, people who track their reading? What would happen was the pain points that came up drove me towards building a more fully fledged reading, tracking, and recommendations product. It actually started as a very focused recommendations product. And then, we got to the point where we needed to build more around it for it to be a compelling product. +And as it was growing, we never advertised ourselves as a Goodreads alternative or as an Amazon-free alternative to what was out there. But that was clearly a pain point in the market. There were tweets about us saying, "Finally a Goodreads alternative. It's small; it's independent; it's Amazon-free. And so thousands and thousands, hundreds of thousands of people have come to us because of that. +VICTORIA: Wow. +NADIA: And so it got to the point...mainly when we launched our payment plan, and we were trying to figure out the reasons why people were pre-ordering the plan, it was at that point where we decided to lean into the Amazon-free Goodreads alternative because that was what the market wanted. +VICTORIA: Was that surprising for you? Or were there other things that came out of your research on your marketplace that kind of were different than what you thought it would be going in? +NADIA: I think the most interesting thing about the product development journey was that I at least originally felt like I was building a product that wasn't for me. So what I mean by that is in my earliest rounds of research, what I was finding was that people still didn't think that they had one place to get consistently good book recommendations. And so then I started to explore, well, how do you even give somebody consistently good book recommendations? +And one of the factors that kept on coming up was this concept of mood, what you're in the mood for. This book made me feel this way. How do I find a book that makes me feel similar? And so it got to the point where I said to myself, oh wow, I'm building a product for mood readers right now; that seems to be the gap, that seems to be the thing that nothing out there yet had properly attacked. And I had never considered myself a mood reader. I just thought I'm a planner. I'm an organized person. I typically decide what book I want to read, and then I read it. +And so there was a point where I was concerned, and I thought, wait, am I now building something that is not for me? But then, as I started to work and do more research and talk to more and more people and thinking about my reading experiences, I developed the hypothesis or the viewpoint rather that I think everybody's a mood reader; it's just the scale. Because there are probably some books that I may have rated lowly in the past that if I had read it in a different frame of mind, or at a different time in my life, different circumstance, it probably would have resonated with me a lot more. +Now, that's not to say that's true for every single book. There are some books that are just not going to work for you, no matter what. But I do think we're all on the scale of mood reading. And sometimes we say a book is a bad book, but we just read it at not the right time. And so I think the most surprising thing for me is going on that journey of realizing that, oh, I am a mood reader too. +VICTORIA: [laughs] +NADIA: And I ended up building an app that's a lot less focused on just the pure ratings. I was someone who, on Goodreads, if it had less than four stars, I'm not interested. And the ethos of the product is more about, well, hang on; these ratings are very subjective. And someone else's two, three-star could be your next five-star. What are the factors that really matter? Do you want something dark, adventurous? Are you looking for something funny, light? And then what kind of topics do you want to discover? And then it doesn't matter if the five people before you thought it was average; you might think it's excellent. +VICTORIA: Yeah, it reminds me thinking about how bias can come in with authors and writing as well. So a simple five-star system might be more susceptible to bias against different genders or different types of names. Whereas if you have more complex numbers or complex rating systems, it might be easier to have different types of authors stand out in a different way. +NADIA: That actually relates to what was going through my mind when I was developing the reviewing system on StoryGraph. You can just, if you want, leave your star rating and say no more, but the star rating is lower down on the page. And up front, we say this book would be great for someone who's in the mood for something...and then you've got checkboxes. And how would you rate the pace of the book? +And if it's a fiction book, we ask you, "Are the characters lovable?" Is there a flawed narrator? Is it plot-driven or character-driven?" Questions like that because the thinking is it doesn't matter whether you are going to give the book two stars in your own personal star rating. You can still help someone else find a book that's good for them because they will be looking at the summary on the StoryGraph book page, and they'll go, "Oh wow, 80% of people said it's lovable. There's a diverse range of characters, and it's funny. So the topics fit things I'm interested in, so I care less about the average rating being like 3.5 because everything else seems perfect. Let me see for myself." +And actually, we've also had a lot of feedback from people saying that "Oh, normally, I never know how to review a book or what to say. And this system has really helped me, almost give me prompts to get started about explaining the book, reviewing it for other people to help them decide if it's for them. So that's great." +VICTORIA: That makes sense to me because I read a lot of books, maybe not as much as I would like to recently. But not all books that I love I can easily recommend to friends, but it's hard for me to say why. [laughs] You know, like, "This is a very complicated book." So I love it. I'll have to check it out later. It's been four years since you've been full-time or since 2019, almost five then. +NADIA: Yes. +VICTORIA: If you could travel back in time to when you first started to make this a full-time role, what advice would you give yourself now, having all of this foresight? +NADIA: Have patience, trust the process because I can sometimes be impatient with, ah, I want this to happen now. I want this to pick up now. I want these features done now. I'm a solo dev on the project. I started it solo. I have a co-founder now, but I'm still the solo dev. And there were so many things, especially now that we've got a much larger user base, that people complained about or say is not quite right. And that can be really tough to just have to keep hearing when you're like, I know, but I don't have the resource to fix it right now or to improve it. +But I think one of the things is, yeah, having faith in the process. Keep going through the cycles of listening to the customers, prioritizing the work, getting the work done, getting the feedback, and just keep going through that loop. And the product will keep getting better. Because sometimes it can feel, particularly in the first year when I was so low, you sometimes have moments of doubt. Or if a customer research round doesn't go super well, you start to wonder, is this only a nice-to-have? And is this going to go anywhere? And so that's one piece of advice. +And I think the other one is knowing that there are several right paths because I think sometimes I would agonize over I want to do the right thing. I want to make sure I make the right choice right now. And, I mean, there are some things that are not good to do. You want to make sure that you're setting up your customer interviews in a non-leading way. You want to make sure that there are certain standards in the product in terms of the technical side and all that kind of stuff, so there's that. +But I think it's understanding that you kind of just have to make a decision. And if you set yourself up to be able to be adaptive and responsive to change, then you'll be fine. Because you can always change course if the response you're getting back or the data you're getting back is going in the wrong direction. +VICTORIA: I love that. And I want to pull on that thread about being open to changing your mind. I think that many founders start the company because they're so excited about this idea and this problem that they found. But how do you keep yourself open to feedback and keeping that ability to flow and to change direction? +NADIA: I mean, I didn't set out to build a Goodreads alternative, and here I am. +VICTORIA: [laughs] +NADIA: I just wanted to build this specific side project or this specific...it was a companion app, in fact. Like, the first version of the thing I built, the first thing you had to do was sign in and connect your Goodreads account so that we could pull in your shelves and start creating the dashboards. So as a solo bootstrapping founder, building a Goodreads alternative was not something that I thought was going to lead to success. +But through years of experience, and just hearing other people's stories, and research, I just learned that it's such a hard space just running a startup in general, and 90% of startups fail. And I just said to myself that, okay, the only way I can kind of survive for longer is if I am open to feedback, I'm open to change course, I'm patient, and I trust the process. These are the things I can do to just increase my chances of success. +And so that's why I kind of feel it's imperative if you want to go down this route and you want to be successful, it's vital that you're open to completely changing the product, completely changing your direction, completely going back on a decision. You'll either lose customers or you'll run out of money, whatever it is. And so yeah, you've got to just basically be quite ruthless in the things that are just going to minimize your chances of failing. +VICTORIA: That makes sense. And now, I have a two-part question for you. What's the wind in your sails? Like, the thing that keeps you going and keeps you motivated to keep working on this? And then, conversely, what's kind of holding you back? What are the obstacles and challenges that you're facing? +NADIA: I think this kind of role...so I'm like founder, CEO, and developer. In general, I think I thrive under pressure and pushing myself, and trying to always be better and improve. So I'm always trying to be like, how can I improve my productivity? Or how can I run the company better? All these kinds of things. So I feel like I'm getting to explore maximizing my full potential as someone in the world of work through doing this. So that just intrinsically is motivating to me. +I love books, and I love reading. I think it's such an amazing hobby. And the fact that I get to make other readers happy is awesome. So even just as the product has grown, the messages that we get about if someone got a perfect recommendation from StoryGraph, or they hadn't read for years, and now an easy form of, you know, what are you in the mood for? Check a few boxes, and we'll show you some books that fit, whatever it is. That's just so...it's so awesome just to be able to enhance readers' lives that way in terms of the things they're reading and getting them excited about reading again or keeping them excited. +So those are the things that keep me going, both the personal nature of enjoying my work and enjoying trying to be the best founder and CEO that I can and building a great product. It's always great when you build something, and people just enjoy using it and like using it. So I'm always incentivized to keep making the product better, the experience better. +I'm currently mid a redesign. And I'm just so excited to get it out because it's going to touch on a lot of repeated pain points that we've been having for years. And I just can't wait for everyone to see it and see that we've listened to them. And we're making progress still like three and a bit years on since we launched out of beta. +What's tough? Previously, what's been tough is navigating, remaining independent, and bootstrapped with just personally trying to make money to just live my life. So I had five years of runway. And it was this tricky situation about when I had a couple of years left, I'm thinking, wow, I really like doing this, but I'm going to need to start earning money soon. But I also don't want to get investment. I don't want to stop doing this. I can't stop doing this. We've got hundreds of thousands of customers. +And so kind of trying to balance my personal needs and life situations with the work I've been doing because I've been working so hard on it for so long that in the last couple of years, it's gotten to a point where it's like, how do I craft the life I want out of a product that is very not set up to be an indie bootstrapped product? [laughs] Typically, you want to do a B2B. You want to start earning money from your product as early as possible. And I feel like I've landed in a product that's typically funded, VC-backed, that kind of thing. So kind of navigating that has been a fun challenge. +There's not been anything that's kind of demoralized me or held me back, or made me think I shouldn't do it. And it's just kind of been a fun challenge trying to...yeah, just navigate that. And we've been doing things like we're currently in the process of transitioning our...we have a Plus Plan. And when we launched it, it was essentially a grab bag of features. We're completely changing the feature set. And we right now have six and a half thousand people who are on that plan. But we don't have product market fit on that plan, and I can tell from when I do certain surveys the responses I get back. +And so we're completely transitioning that to focus in on our most popular feature, which is the stats that we offer. And so that's kind of scary, but it's part of making that Plus Plan more sticky and easier to sell because it's going to be for your power users who love data. So they want all the data when they are reading. +And then the other thing is, okay, what kind of business avenue can we start which fits in with the ethos of the product but brings in more revenue for StoryGraph? And so, we launched a giveaway segment in our app where publishers and authors can pay to list competitions for users to win copies of their books. And it's essentially a win-win-win because publishers and authors get another channel to market their books. Users get to win free books, and readers love winning free books. And StoryGraph has another revenue source that helps us stay independent and profitable, and sustainable in the long run. +VICTORIA: That's wonderful. And there are two tracks I want to follow up on there; one is your decision not to seek funding; if you could just tell me a little more about the reasoning and your thought process behind that. And you've already touched on a little bit of the other ways you're looking at monetizing the app. +NADIA: Since I was a teenager, I've always been interested in business, economics, entrepreneurship. I've always felt very entrepreneurial. I've read so many founder stories and startup stories over the years. And you hear about venture capitalists who come in, and even if it's fine for the first year or two, ultimately, they want a return. And at some point, that could come at odds with your mission or your goals for your company. +And when I think about two things, the kind of life I want and also the nature of the product I'm building as well, VC just doesn't fit. And I know there are so many different funding programs and styles right now, a lot more friendlier [laughs] than VC. But I'm just focusing on VC because when I was younger, I used to think that was a marker of success. VC funding that was the track I thought I was going to go down, and that was what I kind of idolized as, oh my gosh, yes, getting a funding round of millions and millions and then building this huge company. That was how I used to be, so it's so interesting how I've completely gone to the other side. +That idea that you could have mismatched goals and how it's ruined companies, once you take the first round of funding and you grow and expand, then you've got to keep taking more to just stay alive until some liquidation event. That just doesn't appeal to me. And I just think there's something ultimately very powerful and valuable about building a product without giving up any ownership to anybody else and being able to make it into something that people love, and that's profitable, and can give the people who run it great lifestyles. I just think that's a mark of an excellent product, and I just want to build one of those. +And then I think also the nature of the product itself being a book tracking app. I think the product has done well because it is run and built so closely by myself and Rob. And so it's like, people talk about how, oh, you can tell it's built for readers by readers by people who care. And I run the company's Instagram, and it's not just me talking about the product. +I'm talking with a bunch of our users about books and what we're reading. And it really feels like it's just got such a great community feel. And I worry that that can get lost with certain types of investment that I've previously thought that I wanted in my life. And so, yeah, that's the reason why I've kind of strayed away from the investment world. +And then it's gotten to the point, like, now we're at the point where we don't need funding because we've been able to get to profitability by ourselves. So we don't need any type of funding. And we're just going to try and keep doing things to keep making the product better, to convert more people to the Plus Plan. +And, hopefully, our giveaways platform grows in the way we want such that our goal is to just stay profitable and independent forever for as long as possible. And we think that way, we're going to have the most fun running the company, and the product is going to be the best it can be because there's not going to be competing incentives or goals for the product. +VICTORIA: That makes sense. And it sounds like, in reality, in the real case, you had a team, and you had the skills yourself to be able to move the product forward without having to take on funding or take on additional support, which is awesome. And I actually really like your background. I also have a degree in economics. So I'm curious if the economics and philosophy, all of that, really lends itself to your skills as a founder. Is that accurate? +NADIA: I don't think so. +VICTORIA: [laughs] +NADIA: I love my degree. I get sad when I meet econ grads or econ majors, and they're like, "Oh, I hated it. Oh, it was so boring," or whatever. I'm like, "No, it was so great." I'm a big microeconomics fan, so I was all about...I didn't like macro that much. I was all about the game theory and the microeconomic theory, that kind of stuff. +I don't think there's anything that really ties into my skills as a founder. I feel like that's more to do with my upbringing and personality than what I studied. But, I mean, one of the reasons I did love my degree is because there are elements that do crop up. It's such a widely applicable...the subjects I did are so widely applicable, philosophy, different ways of seeing the world and thinking and approaching different people. +And then, obviously, economics that's essentially behavior, and how markets work, and incentives, and all that kind of stuff. And when you get to pricing and all those sorts of things, and business, and then politics as well, I mean, everything is politics, right? People interacting. So there are definitely things and conversations I had at university, which I see things crop up day to day that I can tie back to it. But yeah, I think it doesn't really...my specific degree, I don't think it's made me a better founder than I would have been if I'd studied, I don't know, English or Math or something. +VICTORIA: Right, yeah. I think economics is one of those where it's kind of so broadly applicable. You're kind of using it, but you don't even realize it sometimes. [laughs] +NADIA: Yeah. +MID-ROLL AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. +VICTORIA: So what made you decide to go to a bootcamp right after finishing school? +NADIA: So I'd always been entrepreneurial. I remember...I don't know where exactly it started from, whether I got it from my mom. I know she's always been very entrepreneurial and into business. The earliest memory I have of doing something that was very specifically business-oriented was in what we call sixth form in the UK, which is essentially the last two years of high school before you go to university or college; we had this scheme called Young Enterprise. +And essentially, you got into teams of people, small teams, or they could be quite big, actually. It could be up to 20 people. And you started a business, and there were trade shows, and pitch meetings, and all that kind of stuff, so I remember getting involved in all that sort of stuff at school. +But I'd always been on the investment banking track because when I was young...so my parents...we come from a poor background. And so my parents were very much like, you know, try and find high-paying careers to go into so that you can pay for whatever you want and you have a much better lifestyle. So I had gotten onto the investment banking track from the age of 14 when I went with a friend...at the school, I went to, there was a Take Your Daughter to Work Day. +My dad said, "Oh, you want to go to try and find someone whose parent works in an investment bank or something like that. That's like a great career to go into." And so I went with a friend's dad to UBS. And I remember being blown away, like, wow, this is so fascinating. Because I think everything seems so impressive when you're 14, and you're walking into a space like that, and everything seems very lively. And everyone's walking around dressed sharp. They've got their BlackBerries. +So from the age of 14 until 20, it would have been, I was very much I am going to work in an investment bank. And I did all the things that you would do, like all the schemes, the spring programs. And it got to my final internship. And I just remember at the internship being rather disillusioned and disappointed by the experience. I remember thinking, is this it? I was studying at Oxford, and I put so much into my studies. And I remember thinking; I'm working so hard. And this is what I come to? Is this it? +And so around the time as well, I was also meeting a lot of people in the entrepreneurship space, social enterprises, people doing their own ventures. And I just remember thinking, oh, I feel like I've got to go down that track. And I ended up winning a place on a coding course. It was set up specifically to help more women get into tech. And it was called Code First Girls. I won a place that started...it was just part-time. +What I did was I actually...I got the banking job from Deutsche Bank, it was, but I decided to turn it down. It was a very risky decision. I turned it down, and I stayed in Oxford after graduating and worked in the academic office for a while. And then, twice a week, I would go to London and do this coding course. And during it, on Twitter, I remember seeing a competition for a full-paid place at this bootcamp called Makers Academy. And I just thought to myself, having tech skills, I'd heard the feedback that it's a very powerful thing to have. +And I remember thinking I should go for this competition. And I went for the competition, and I won a free place at the bootcamp. If I didn't win a free place at the bootcamp, I'm not sure what would have happened because I'm not sure whether at that point I would have thought, oh, paying £8,000 to go to a software bootcamp is what I should do. I'm not sure I would have got there. So that's how I got there, essentially. I won a competition for a bootcamp after having a taste of what coding was like and seeing how freeing it was to just be able to have a computer and an internet connection and build something. +VICTORIA: Oh, that's wonderful. I love that story. And I've spent a lot of time with Women Who Code and trying to get women excited about coding. And that's exactly the story is that once you have it, it's a tool in your toolset. And if you want to build something, you can make it happen. And that's why it's important to continue the education and get access for people who might not normally have it. And you continue to do some of that work as well, right? You're involved in organizations like this? +NADIA: Like Code First Girls? No. I did some years ago. I would go and attend Rails Girls workshops and be a mentor at them, at those. And while I was at Pivotal, I helped with events like codebar, which were essentially evenings where people who were learning to code or more junior could come and pair with someone more senior on whatever project they wanted to. +So I did a bunch of that stuff in the years after leaving Makers Academy. And I was even a TA for a short time for a couple of weeks at Makers Academy as well after I graduated. But in more recent years, I haven't done much in that space, but I would love to do more at some point. I don't have the bandwidth to right now. [laughs] +VICTORIA: And you're still a major speaker going and keynoting events all around the world. Have you done any recently, or have any coming up that you're excited about? +NADIA: So before the pandemic, my last talk, I keynoted RubyWorld in Japan. That was in November 2019. And then the pandemic hit, and 2020 June, July was when StoryGraph had some viral tweets, and so we kicked off. And amongst all of that, I was being invited to speak at remote events, but it just didn't make sense for me. Not only was I so busy with work, but I put a lot of hours into my talks. And part of the fun is being there, hallway track, meeting people, being on stage. And so it just didn't appeal to me to spend so much time developing the talk to just deliver it at home. +And so, I just spent all the time on StoryGraph. And I remember when events started happening again; I wondered whether I would even be invited to speak because I felt more detached from the Ruby community. Most of the conferences that I did were in the Ruby community. StoryGraph is built on Rails. Yeah, I just thought maybe I'll get back to that later. +But all of a sudden, I had a series of amazing invitations. Andrew Culver started up The Rails SaaS Conference in LA in October, and I was invited to speak at that. And then, I was invited to keynote RubyConf, that was recently held in Houston, Texas, and also invited to keynote the satellite conference, RubyConf Mini in Providence, that happened a couple of weeks earlier. And so I had a very busy October and November, a lot of travel. +I developed two new talks, a Ruby talk and a StoryGraph talk. It was my first ever time giving a talk on StoryGraph. It was a lot of work and amongst a lot of StoryGraph work that I needed to do. All of the talks went well, and it was so much fun to be back on the circuit again. And I'm looking forward to whatever speaking things crop up this year. +VICTORIA: That's wonderful. I'm excited. I'll have to see if I can find a recording and get caught up myself. Going back to an earlier question, you mentioned quite a few times about market research and talking to the customers. And I'm just curious if you have a method or a set of tools that you use to run those experiments and collect that feedback and information. +NADIA: Yes. So I remember one of the first things I did years ago was I read "The Mom Test" by Rob Fitzpatrick. And that's great for just getting the foundation of when you talk to customers; you don't want to lead them on in any shape or form. You just want to get the raw truth and go from there. So that's the underpinning of everything I do. +And then, I learned from friends I made through Pivotal about how you put together a script for a customer research. You can't just have bullet points or whatever. You should have a script. And the foundation of that script is a hypothesis about what you're trying to find out in that round of research. And once you figure out your hypothesis, then you can put together the questions you want to ask and understand how you're going to measure the output. +So the first ever thing I was trying to find out when I first started interviewing people was just very general. It was just like, are there any pain points? I was just trying to figure out are there any pain points among the avid reader group of people? And then I remember the results from that were, "No place for consistent, high-quality recommendations." And so then I said, okay, how are people finding recommendations now, or what are the factors that lead to people thinking a book was great for them? And that's how I ended up getting to the moods and pace. +But when I do my interviews, I record them all. I watch them back. And I condense everything on sticky notes. And I use a virtual tool. And I try to take word for word. When I summarize, I still just try and use their specific words as much as possible. So I'm not adding my own editing over what they say. Every single interviewee has a different color. +And I essentially group them into themes, and that's how I unlock whatever the answers are for that round. And then I use that...I might have been trying to find out what to build next or whether we should go down a certain product direction or not. And so, depending on the outcome, that helps me make up my mind about what to do. So that's the high-level process that I follow. +VICTORIA: Well, that sounds very methodical, and interesting for me to hear your perspective on that. And you mentioned that you do have a redesign coming out soon for StoryGraph. Are there any other particular products or features that you're really excited to talk about coming up soon? +NADIA: Yeah, I'm so excited about the redesign because we're bringing out...it's not just a UI improvement; it's a user experience improvement as well. So there are a lot of little features that have been asked for over the years. And actually, it was trying to deliver one of them that sparked the whole redesign. So people really want a marked as finished button. There's no way to mark as finished. You just toggle a book back to read. And some people find this quite counterintuitive, or it doesn't quite explain what they're doing. +And so when I came to deliver the mark as finished button, this was months and months ago now, I realized that the book pane was just becoming so cluttered, and I was trying to fight with it to squeeze in this link. And I remember thinking; this is not the only thing people want to see on the book pane. They also want to see when they read the book without having to go into the book page. They also want to be able to add it to their next queue. +And I just said, you know what? I need to redesign this whole thing. And so I was able to luckily work with Saron Yitbarek, who is married to my co-founder, Rob. There's a funny story about all of that. And she helped me do this redesign based on all my customer research. And so I'm just so excited to get it out because the other thing that we're bringing with it is dark mode, which is our most requested feature in history. +And it's funny because I've always felt like, ah, that's a nice-to-have. But obviously, for some people, it's not a nice-to-have; it's an accessibility issue. And even me, I'm quite strict with my bedtime. I try and be offline an hour before bed. In bed by 11, up at 6, and even me if I want to track my pages, I'm like, ooh, this is a bit bright. +And my phone itself is set on adaptive, so it's light mode during the day and dark mode during the night. And even me, I can see why people really want this and why it would just improve their experience, especially if everything else on your phone is dark. So I'm really excited to get that out, mainly for the UX improvements. +And the other thing I'm really excited to do is transition the Plus Plan to being the advanced stats package rather than the random selection of features right now. Because not only will the people who pay us get more complex stats functionalities such that they feel like, wow, the subscription fee that I pay not only does it still make me feel like I'm supporting an alternative to Goodreads, an independent alternative to Goodreads I also get such value from these extra features. +But the other thing is what I found from my customer research is that if you're a Plus customer, there's often one or two of the Plus features that you love and that you don't really use the others. But they're all really great features. And so what I'm really excited about is that we're going to make all the non-stats features free for everybody. And so I'm so excited for, like, we have a feature where if you put in a group of usernames, we look at all of your to-read lists and suggest great books for you to buddy-read together. +Now, there's a bunch of Plus users who aren't social and don't care about it. But there's going to be a bunch of our free users who are so excited about that feature, probably will use it with their book clubs, things like that. We have up-next suggestions where we suggest what you should pick up next from your to-read pile based on a range of factors. It could be, oh, you're behind on your reading goal; here's a fast-paced book. Or this book is very similar to the one that you just finished, so if you want something the same, pick up this one. And, again, that's behind a paywall right now, and I'm just so excited for everybody to be able to use that. +When I remember starting out with StoryGraph, I remember thinking, wow, the way this is going, wouldn't it be so cool if we could just suggest books that would be the next perfect read for you? Because a lot of people have a pile of books by their bedside table or on their shelves, and they're just like, well, which one should I start with? And this tool literally helps you to do that. And so I can't wait for everyone to be able to try it. And so that's why I'm excited about that transition because the Plus Plan will be better, and the free product will be better. +VICTORIA: That sounds amazing. And I'm thinking in my head like, oh, I should start a book club with thoughtbot. Because there are some engineering management and other types of books we want to read, so maybe we could use StoryGraph to manage that and keep ourselves motivated to actually finish them. [laughs] +NADIA: Cool. +VICTORIA: No, this is wonderful. And what books are on your reading list coming up? +NADIA: Yes. I am excited to read...I'm not sure...I'm blanking on the series' name. But the first book is called "The Poppy War." I don't know whether it's called "The Burning God" or if that's the third book in the series. But it's this very popular trilogy, and I'm excited to read that soon. I'm doing a slow chronological read of Toni Morrison's fiction. I recently read "Song of Solomon," which was great, really, really good. And so I'm excited to read more of her novels this year. +I'm also on a kind of narrative nonfiction kick right now. I love narrative nonfiction. So I just finished reading "American Kingpin," which is about Silk Road. And I've picked up "Black Edge," which is about SAC Capital and Steve Cohen and that whole hedge fund insider trading situation. So I'm probably going to look for more of the same afterwards. +VICTORIA: Well, that's very exciting. And it's inspiring that as a founder, you also still have time to read [laughs] and probably because StoryGraph makes it easy and motivating for you to do so. +NADIA: Yeah, everyone thought that my reading would tank once I started the company, but, in fact, it's multiplied severalfold. And a couple of reasons; one is it's very important in general for me to make time for me because I'm in a situation that could easily become very stressful and could lead to burnout. So I make sure that I make time for me to read and to go to dance class regularly, which is my other main hobby. +But then, secondly, I feel like I can justify it as work. Because I say, wow, me being a reader and being able to communicate with people on Instagram and on Twitter about books, not just the product, adds legitimacy to me as the founder and developer of this product. And so it's important that I keep reading. And it also helps the product be better because I understand what features are needed. So, for example, I never used to listen to audiobooks. I'm a big podcast person; I love music. So between those two, when does audio fit in? +And also, I didn't like the idea that I could just be absent-minded sometimes with some podcasts, but with a book, you don't want spoilers. It could get confusing. But I started listening to audiobooks because we had a large audiobook user base. And they would ask for certain features, and it was really hard for me to relate and to understand their needs. +And now that I have started listening to audiobooks as well, we made some great audiobook listeners-focused additions to the app last year, including you can track your minutes. So you can literally get you read this many pages in a day, but you also listened to this many minutes. You can set an hours goal for the year, so not just a reading goal or a pages goal. You can set an hours goal. +Or maybe you're someone like me, where audiobooks are the smaller proportion of your reading, and you just want it all calculated as pages. And so I've got it on the setting where it's like, even when I track an audiobook in StoryGraph, convert it to pages for me, and I just have my nice, all-round page number at the end of the year. +VICTORIA: That's so cool. Really interesting. And I've had such a nice time chatting with you today. Is there anything else that you'd like to share as a final takeaway for our listeners? +NADIA: If you are someone who wants to start a company, maybe you want to bootstrap, you've got a product idea, I think it's honestly just trust the process. It will take time. But if you trust the process, you listen to customers and really listen to them...research ways to talk to customers, and don't cut corners with the process. There have been so many times when I've done a whole round of research, and then I say, oh, do I have to go through all these now and actually do a synthesis? I think anecdotally; I can figure out what the gist was; no, do the research. You don't know what insights you're going to find. +And I think if you just trust that process...and I think the other thing is before you get to that stage, start building up a runway. Having a runway is so powerful. And so whether it's saving a bit more or diverting funds from something else if you have a runway and you can give yourself a couple of years, a few years without worrying about your next paycheck, that is incredibly valuable to getting started on your bootstrapping journey. +VICTORIA: Thank you. That's so wonderful. And I appreciate you coming on today to be with us. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Mastodon at Victoria Guido. +This podcast is brought to by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Nadia Odunayo. + + + Nadia Odunayo is the Founder and CEO of The StoryGraph, a new website and app for avid book readers because life's too short for a book you're not in the mood for. The StoryGraph helps you track your reading and choose your next book based on your mood, favorite topics, and themes.

+ +

Victoria talks to Nadia about coming up with a product based on the concept of mood, what you're in the mood for to read, i.e., this book made me feel this way. How do I find a book that makes me feel similar? They also talk about keeping yourself open to feedback, the ability to flow and change direction, and developing a reviewing system that keeps biases in check.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Nadia Odunayo, Founder and CEO of StoryGraph, a new website and app for avid book readers because life's too short for a book you're not in the mood for. StoryGraph helps you track your reading and choose your next book based on your mood and your favorite topics and themes. Nadia, thank you for joining me.

+ +

NADIA: Thank you for having me.

+ +

VICTORIA: And you are a repeat guest at Giant Robots. But for those who missed that episode, tell me a little bit about your journey. And how did this all get started?

+ +

NADIA: Okay. Yeah, so that first time was in 2015, and that was not too long after I had just got into tech. I did a bootcamp in London in 2014, Makers Academy, and that's where I learned to code. My degree was in philosophy, politics, and economics, so rather different. I worked at Pivotal for about a year and a half after I graduated from Makers Academy. And during my time at Pivotal, I got into conference speaking, and my first talk was around game theory.

+ +

So I took my favorite topic in economics, game theory, and I combined that with distributed systems because that's what I was working on at the time in Pivotal on their Cloud Foundry PaaS. I think I gave it at RailsConf, and I think someone there recommended me to Giant Robots. And so Ben Orenstein interviewed me, and it was all about different types of conference talks and that kind of thing.

+ +

So after Pivotal, I left and started a hybrid kind of consultancy/product company with a colleague, did that for about a year, left that, worked for about a year with my friend, Saron Yitbarek, on her company CodeNewbie. And then, when that partnership ended, I essentially had five years of runway from money that I got from the company that I started after Pivotal because we did some consulting with a bank.

+ +

I'd always been entrepreneurial. I'd been doing various entrepreneurial things since secondary school, actually, high school. It was time for me to just have time on my side projects. And so I started hacking away on one of my side projects at the beginning of 2019 in January, and I haven't stopped since. That's what the StoryGraph has developed into.

+ +

VICTORIA: Wonderful. And yes, I saw that the very early stages of StoryGraph started as a creative writing e-publication. Is that right?

+ +

NADIA: So what happened was when I was at university, I started a creative writing e-publication, came up with the name The StoryGraph. Because we had won or we were going for some grant funding or something like that, I set up a corporate entity. And when I stopped working on that e-publication, I remember my mom saying to me, "Don't shut down the entity. I really like the name. I feel like you'll use it for something," that was in 2012.

+ +

And so fast forward to 2019, and the side project that I was working on was called Read Lists. And it was very specifically focused on tracking and sharing progress through reading lists on a dashboard. But when I was doing customer research, and the scope of the project grew, Read Lists didn't fit anymore. And that's when I realized, oh, I can use The StoryGraph thing again. And so it's basically had two different lives or two different forms, the StoryGraph company.

+ +

VICTORIA: That's wonderful. And I'm reading about StoryGraph and how it's an Amazon-free alternative to Goodreads. Can you talk a little bit more about the product and why people would want to use it?

+ +

NADIA: So, as I said, it started life as a very specific focused side project. And I just had so much fun working on it and working in the book space. I'd always been a reader since I was a kid such that I said to myself, I need to find a way to make me building a books product a full-time thing. And so that's when customer research came in because the only way that you're going to make sure that you don't build something that people don't want is by talking to people.

+ +

As I was doing customer research and figuring out, are there pain points amongst readers, people who track their reading? What would happen was the pain points that came up drove me towards building a more fully fledged reading, tracking, and recommendations product. It actually started as a very focused recommendations product. And then, we got to the point where we needed to build more around it for it to be a compelling product.

+ +

And as it was growing, we never advertised ourselves as a Goodreads alternative or as an Amazon-free alternative to what was out there. But that was clearly a pain point in the market. There were tweets about us saying, "Finally a Goodreads alternative. It's small; it's independent; it's Amazon-free. And so thousands and thousands, hundreds of thousands of people have come to us because of that.

+ +

VICTORIA: Wow.

+ +

NADIA: And so it got to the point...mainly when we launched our payment plan, and we were trying to figure out the reasons why people were pre-ordering the plan, it was at that point where we decided to lean into the Amazon-free Goodreads alternative because that was what the market wanted.

+ +

VICTORIA: Was that surprising for you? Or were there other things that came out of your research on your marketplace that kind of were different than what you thought it would be going in?

+ +

NADIA: I think the most interesting thing about the product development journey was that I at least originally felt like I was building a product that wasn't for me. So what I mean by that is in my earliest rounds of research, what I was finding was that people still didn't think that they had one place to get consistently good book recommendations. And so then I started to explore, well, how do you even give somebody consistently good book recommendations?

+ +

And one of the factors that kept on coming up was this concept of mood, what you're in the mood for. This book made me feel this way. How do I find a book that makes me feel similar? And so it got to the point where I said to myself, oh wow, I'm building a product for mood readers right now; that seems to be the gap, that seems to be the thing that nothing out there yet had properly attacked. And I had never considered myself a mood reader. I just thought I'm a planner. I'm an organized person. I typically decide what book I want to read, and then I read it.

+ +

And so there was a point where I was concerned, and I thought, wait, am I now building something that is not for me? But then, as I started to work and do more research and talk to more and more people and thinking about my reading experiences, I developed the hypothesis or the viewpoint rather that I think everybody's a mood reader; it's just the scale. Because there are probably some books that I may have rated lowly in the past that if I had read it in a different frame of mind, or at a different time in my life, different circumstance, it probably would have resonated with me a lot more.

+ +

Now, that's not to say that's true for every single book. There are some books that are just not going to work for you, no matter what. But I do think we're all on the scale of mood reading. And sometimes we say a book is a bad book, but we just read it at not the right time. And so I think the most surprising thing for me is going on that journey of realizing that, oh, I am a mood reader too.

+ +

VICTORIA: [laughs]

+ +

NADIA: And I ended up building an app that's a lot less focused on just the pure ratings. I was someone who, on Goodreads, if it had less than four stars, I'm not interested. And the ethos of the product is more about, well, hang on; these ratings are very subjective. And someone else's two, three-star could be your next five-star. What are the factors that really matter? Do you want something dark, adventurous? Are you looking for something funny, light? And then what kind of topics do you want to discover? And then it doesn't matter if the five people before you thought it was average; you might think it's excellent.

+ +

VICTORIA: Yeah, it reminds me thinking about how bias can come in with authors and writing as well. So a simple five-star system might be more susceptible to bias against different genders or different types of names. Whereas if you have more complex numbers or complex rating systems, it might be easier to have different types of authors stand out in a different way.

+ +

NADIA: That actually relates to what was going through my mind when I was developing the reviewing system on StoryGraph. You can just, if you want, leave your star rating and say no more, but the star rating is lower down on the page. And up front, we say this book would be great for someone who's in the mood for something...and then you've got checkboxes. And how would you rate the pace of the book?

+ +

And if it's a fiction book, we ask you, "Are the characters lovable?" Is there a flawed narrator? Is it plot-driven or character-driven?" Questions like that because the thinking is it doesn't matter whether you are going to give the book two stars in your own personal star rating. You can still help someone else find a book that's good for them because they will be looking at the summary on the StoryGraph book page, and they'll go, "Oh wow, 80% of people said it's lovable. There's a diverse range of characters, and it's funny. So the topics fit things I'm interested in, so I care less about the average rating being like 3.5 because everything else seems perfect. Let me see for myself."

+ +

And actually, we've also had a lot of feedback from people saying that "Oh, normally, I never know how to review a book or what to say. And this system has really helped me, almost give me prompts to get started about explaining the book, reviewing it for other people to help them decide if it's for them. So that's great."

+ +

VICTORIA: That makes sense to me because I read a lot of books, maybe not as much as I would like to recently. But not all books that I love I can easily recommend to friends, but it's hard for me to say why. [laughs] You know, like, "This is a very complicated book." So I love it. I'll have to check it out later. It's been four years since you've been full-time or since 2019, almost five then.

+ +

NADIA: Yes.

+ +

VICTORIA: If you could travel back in time to when you first started to make this a full-time role, what advice would you give yourself now, having all of this foresight?

+ +

NADIA: Have patience, trust the process because I can sometimes be impatient with, ah, I want this to happen now. I want this to pick up now. I want these features done now. I'm a solo dev on the project. I started it solo. I have a co-founder now, but I'm still the solo dev. And there were so many things, especially now that we've got a much larger user base, that people complained about or say is not quite right. And that can be really tough to just have to keep hearing when you're like, I know, but I don't have the resource to fix it right now or to improve it.

+ +

But I think one of the things is, yeah, having faith in the process. Keep going through the cycles of listening to the customers, prioritizing the work, getting the work done, getting the feedback, and just keep going through that loop. And the product will keep getting better. Because sometimes it can feel, particularly in the first year when I was so low, you sometimes have moments of doubt. Or if a customer research round doesn't go super well, you start to wonder, is this only a nice-to-have? And is this going to go anywhere? And so that's one piece of advice.

+ +

And I think the other one is knowing that there are several right paths because I think sometimes I would agonize over I want to do the right thing. I want to make sure I make the right choice right now. And, I mean, there are some things that are not good to do. You want to make sure that you're setting up your customer interviews in a non-leading way. You want to make sure that there are certain standards in the product in terms of the technical side and all that kind of stuff, so there's that.

+ +

But I think it's understanding that you kind of just have to make a decision. And if you set yourself up to be able to be adaptive and responsive to change, then you'll be fine. Because you can always change course if the response you're getting back or the data you're getting back is going in the wrong direction.

+ +

VICTORIA: I love that. And I want to pull on that thread about being open to changing your mind. I think that many founders start the company because they're so excited about this idea and this problem that they found. But how do you keep yourself open to feedback and keeping that ability to flow and to change direction?

+ +

NADIA: I mean, I didn't set out to build a Goodreads alternative, and here I am.

+ +

VICTORIA: [laughs]

+ +

NADIA: I just wanted to build this specific side project or this specific...it was a companion app, in fact. Like, the first version of the thing I built, the first thing you had to do was sign in and connect your Goodreads account so that we could pull in your shelves and start creating the dashboards. So as a solo bootstrapping founder, building a Goodreads alternative was not something that I thought was going to lead to success.

+ +

But through years of experience, and just hearing other people's stories, and research, I just learned that it's such a hard space just running a startup in general, and 90% of startups fail. And I just said to myself that, okay, the only way I can kind of survive for longer is if I am open to feedback, I'm open to change course, I'm patient, and I trust the process. These are the things I can do to just increase my chances of success.

+ +

And so that's why I kind of feel it's imperative if you want to go down this route and you want to be successful, it's vital that you're open to completely changing the product, completely changing your direction, completely going back on a decision. You'll either lose customers or you'll run out of money, whatever it is. And so yeah, you've got to just basically be quite ruthless in the things that are just going to minimize your chances of failing.

+ +

VICTORIA: That makes sense. And now, I have a two-part question for you. What's the wind in your sails? Like, the thing that keeps you going and keeps you motivated to keep working on this? And then, conversely, what's kind of holding you back? What are the obstacles and challenges that you're facing?

+ +

NADIA: I think this kind of role...so I'm like founder, CEO, and developer. In general, I think I thrive under pressure and pushing myself, and trying to always be better and improve. So I'm always trying to be like, how can I improve my productivity? Or how can I run the company better? All these kinds of things. So I feel like I'm getting to explore maximizing my full potential as someone in the world of work through doing this. So that just intrinsically is motivating to me.

+ +

I love books, and I love reading. I think it's such an amazing hobby. And the fact that I get to make other readers happy is awesome. So even just as the product has grown, the messages that we get about if someone got a perfect recommendation from StoryGraph, or they hadn't read for years, and now an easy form of, you know, what are you in the mood for? Check a few boxes, and we'll show you some books that fit, whatever it is. That's just so...it's so awesome just to be able to enhance readers' lives that way in terms of the things they're reading and getting them excited about reading again or keeping them excited.

+ +

So those are the things that keep me going, both the personal nature of enjoying my work and enjoying trying to be the best founder and CEO that I can and building a great product. It's always great when you build something, and people just enjoy using it and like using it. So I'm always incentivized to keep making the product better, the experience better.

+ +

I'm currently mid a redesign. And I'm just so excited to get it out because it's going to touch on a lot of repeated pain points that we've been having for years. And I just can't wait for everyone to see it and see that we've listened to them. And we're making progress still like three and a bit years on since we launched out of beta.

+ +

What's tough? Previously, what's been tough is navigating, remaining independent, and bootstrapped with just personally trying to make money to just live my life. So I had five years of runway. And it was this tricky situation about when I had a couple of years left, I'm thinking, wow, I really like doing this, but I'm going to need to start earning money soon. But I also don't want to get investment. I don't want to stop doing this. I can't stop doing this. We've got hundreds of thousands of customers.

+ +

And so kind of trying to balance my personal needs and life situations with the work I've been doing because I've been working so hard on it for so long that in the last couple of years, it's gotten to a point where it's like, how do I craft the life I want out of a product that is very not set up to be an indie bootstrapped product? [laughs] Typically, you want to do a B2B. You want to start earning money from your product as early as possible. And I feel like I've landed in a product that's typically funded, VC-backed, that kind of thing. So kind of navigating that has been a fun challenge.

+ +

There's not been anything that's kind of demoralized me or held me back, or made me think I shouldn't do it. And it's just kind of been a fun challenge trying to...yeah, just navigate that. And we've been doing things like we're currently in the process of transitioning our...we have a Plus Plan. And when we launched it, it was essentially a grab bag of features. We're completely changing the feature set. And we right now have six and a half thousand people who are on that plan. But we don't have product market fit on that plan, and I can tell from when I do certain surveys the responses I get back.

+ +

And so we're completely transitioning that to focus in on our most popular feature, which is the stats that we offer. And so that's kind of scary, but it's part of making that Plus Plan more sticky and easier to sell because it's going to be for your power users who love data. So they want all the data when they are reading.

+ +

And then the other thing is, okay, what kind of business avenue can we start which fits in with the ethos of the product but brings in more revenue for StoryGraph? And so, we launched a giveaway segment in our app where publishers and authors can pay to list competitions for users to win copies of their books. And it's essentially a win-win-win because publishers and authors get another channel to market their books. Users get to win free books, and readers love winning free books. And StoryGraph has another revenue source that helps us stay independent and profitable, and sustainable in the long run.

+ +

VICTORIA: That's wonderful. And there are two tracks I want to follow up on there; one is your decision not to seek funding; if you could just tell me a little more about the reasoning and your thought process behind that. And you've already touched on a little bit of the other ways you're looking at monetizing the app.

+ +

NADIA: Since I was a teenager, I've always been interested in business, economics, entrepreneurship. I've always felt very entrepreneurial. I've read so many founder stories and startup stories over the years. And you hear about venture capitalists who come in, and even if it's fine for the first year or two, ultimately, they want a return. And at some point, that could come at odds with your mission or your goals for your company.

+ +

And when I think about two things, the kind of life I want and also the nature of the product I'm building as well, VC just doesn't fit. And I know there are so many different funding programs and styles right now, a lot more friendlier [laughs] than VC. But I'm just focusing on VC because when I was younger, I used to think that was a marker of success. VC funding that was the track I thought I was going to go down, and that was what I kind of idolized as, oh my gosh, yes, getting a funding round of millions and millions and then building this huge company. That was how I used to be, so it's so interesting how I've completely gone to the other side.

+ +

That idea that you could have mismatched goals and how it's ruined companies, once you take the first round of funding and you grow and expand, then you've got to keep taking more to just stay alive until some liquidation event. That just doesn't appeal to me. And I just think there's something ultimately very powerful and valuable about building a product without giving up any ownership to anybody else and being able to make it into something that people love, and that's profitable, and can give the people who run it great lifestyles. I just think that's a mark of an excellent product, and I just want to build one of those.

+ +

And then I think also the nature of the product itself being a book tracking app. I think the product has done well because it is run and built so closely by myself and Rob. And so it's like, people talk about how, oh, you can tell it's built for readers by readers by people who care. And I run the company's Instagram, and it's not just me talking about the product.

+ +

I'm talking with a bunch of our users about books and what we're reading. And it really feels like it's just got such a great community feel. And I worry that that can get lost with certain types of investment that I've previously thought that I wanted in my life. And so, yeah, that's the reason why I've kind of strayed away from the investment world.

+ +

And then it's gotten to the point, like, now we're at the point where we don't need funding because we've been able to get to profitability by ourselves. So we don't need any type of funding. And we're just going to try and keep doing things to keep making the product better, to convert more people to the Plus Plan.

+ +

And, hopefully, our giveaways platform grows in the way we want such that our goal is to just stay profitable and independent forever for as long as possible. And we think that way, we're going to have the most fun running the company, and the product is going to be the best it can be because there's not going to be competing incentives or goals for the product.

+ +

VICTORIA: That makes sense. And it sounds like, in reality, in the real case, you had a team, and you had the skills yourself to be able to move the product forward without having to take on funding or take on additional support, which is awesome. And I actually really like your background. I also have a degree in economics. So I'm curious if the economics and philosophy, all of that, really lends itself to your skills as a founder. Is that accurate?

+ +

NADIA: I don't think so.

+ +

VICTORIA: [laughs]

+ +

NADIA: I love my degree. I get sad when I meet econ grads or econ majors, and they're like, "Oh, I hated it. Oh, it was so boring," or whatever. I'm like, "No, it was so great." I'm a big microeconomics fan, so I was all about...I didn't like macro that much. I was all about the game theory and the microeconomic theory, that kind of stuff.

+ +

I don't think there's anything that really ties into my skills as a founder. I feel like that's more to do with my upbringing and personality than what I studied. But, I mean, one of the reasons I did love my degree is because there are elements that do crop up. It's such a widely applicable...the subjects I did are so widely applicable, philosophy, different ways of seeing the world and thinking and approaching different people.

+ +

And then, obviously, economics that's essentially behavior, and how markets work, and incentives, and all that kind of stuff. And when you get to pricing and all those sorts of things, and business, and then politics as well, I mean, everything is politics, right? People interacting. So there are definitely things and conversations I had at university, which I see things crop up day to day that I can tie back to it. But yeah, I think it doesn't really...my specific degree, I don't think it's made me a better founder than I would have been if I'd studied, I don't know, English or Math or something.

+ +

VICTORIA: Right, yeah. I think economics is one of those where it's kind of so broadly applicable. You're kind of using it, but you don't even realize it sometimes. [laughs]

+ +

NADIA: Yeah.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

VICTORIA: So what made you decide to go to a bootcamp right after finishing school?

+ +

NADIA: So I'd always been entrepreneurial. I remember...I don't know where exactly it started from, whether I got it from my mom. I know she's always been very entrepreneurial and into business. The earliest memory I have of doing something that was very specifically business-oriented was in what we call sixth form in the UK, which is essentially the last two years of high school before you go to university or college; we had this scheme called Young Enterprise.

+ +

And essentially, you got into teams of people, small teams, or they could be quite big, actually. It could be up to 20 people. And you started a business, and there were trade shows, and pitch meetings, and all that kind of stuff, so I remember getting involved in all that sort of stuff at school.

+ +

But I'd always been on the investment banking track because when I was young...so my parents...we come from a poor background. And so my parents were very much like, you know, try and find high-paying careers to go into so that you can pay for whatever you want and you have a much better lifestyle. So I had gotten onto the investment banking track from the age of 14 when I went with a friend...at the school, I went to, there was a Take Your Daughter to Work Day.

+ +

My dad said, "Oh, you want to go to try and find someone whose parent works in an investment bank or something like that. That's like a great career to go into." And so I went with a friend's dad to UBS. And I remember being blown away, like, wow, this is so fascinating. Because I think everything seems so impressive when you're 14, and you're walking into a space like that, and everything seems very lively. And everyone's walking around dressed sharp. They've got their BlackBerries.

+ +

So from the age of 14 until 20, it would have been, I was very much I am going to work in an investment bank. And I did all the things that you would do, like all the schemes, the spring programs. And it got to my final internship. And I just remember at the internship being rather disillusioned and disappointed by the experience. I remember thinking, is this it? I was studying at Oxford, and I put so much into my studies. And I remember thinking; I'm working so hard. And this is what I come to? Is this it?

+ +

And so around the time as well, I was also meeting a lot of people in the entrepreneurship space, social enterprises, people doing their own ventures. And I just remember thinking, oh, I feel like I've got to go down that track. And I ended up winning a place on a coding course. It was set up specifically to help more women get into tech. And it was called Code First Girls. I won a place that started...it was just part-time.

+ +

What I did was I actually...I got the banking job from Deutsche Bank, it was, but I decided to turn it down. It was a very risky decision. I turned it down, and I stayed in Oxford after graduating and worked in the academic office for a while. And then, twice a week, I would go to London and do this coding course. And during it, on Twitter, I remember seeing a competition for a full-paid place at this bootcamp called Makers Academy. And I just thought to myself, having tech skills, I'd heard the feedback that it's a very powerful thing to have.

+ +

And I remember thinking I should go for this competition. And I went for the competition, and I won a free place at the bootcamp. If I didn't win a free place at the bootcamp, I'm not sure what would have happened because I'm not sure whether at that point I would have thought, oh, paying £8,000 to go to a software bootcamp is what I should do. I'm not sure I would have got there. So that's how I got there, essentially. I won a competition for a bootcamp after having a taste of what coding was like and seeing how freeing it was to just be able to have a computer and an internet connection and build something.

+ +

VICTORIA: Oh, that's wonderful. I love that story. And I've spent a lot of time with Women Who Code and trying to get women excited about coding. And that's exactly the story is that once you have it, it's a tool in your toolset. And if you want to build something, you can make it happen. And that's why it's important to continue the education and get access for people who might not normally have it. And you continue to do some of that work as well, right? You're involved in organizations like this?

+ +

NADIA: Like Code First Girls? No. I did some years ago. I would go and attend Rails Girls workshops and be a mentor at them, at those. And while I was at Pivotal, I helped with events like codebar, which were essentially evenings where people who were learning to code or more junior could come and pair with someone more senior on whatever project they wanted to.

+ +

So I did a bunch of that stuff in the years after leaving Makers Academy. And I was even a TA for a short time for a couple of weeks at Makers Academy as well after I graduated. But in more recent years, I haven't done much in that space, but I would love to do more at some point. I don't have the bandwidth to right now. [laughs]

+ +

VICTORIA: And you're still a major speaker going and keynoting events all around the world. Have you done any recently, or have any coming up that you're excited about?

+ +

NADIA: So before the pandemic, my last talk, I keynoted RubyWorld in Japan. That was in November 2019. And then the pandemic hit, and 2020 June, July was when StoryGraph had some viral tweets, and so we kicked off. And amongst all of that, I was being invited to speak at remote events, but it just didn't make sense for me. Not only was I so busy with work, but I put a lot of hours into my talks. And part of the fun is being there, hallway track, meeting people, being on stage. And so it just didn't appeal to me to spend so much time developing the talk to just deliver it at home.

+ +

And so, I just spent all the time on StoryGraph. And I remember when events started happening again; I wondered whether I would even be invited to speak because I felt more detached from the Ruby community. Most of the conferences that I did were in the Ruby community. StoryGraph is built on Rails. Yeah, I just thought maybe I'll get back to that later.

+ +

But all of a sudden, I had a series of amazing invitations. Andrew Culver started up The Rails SaaS Conference in LA in October, and I was invited to speak at that. And then, I was invited to keynote RubyConf, that was recently held in Houston, Texas, and also invited to keynote the satellite conference, RubyConf Mini in Providence, that happened a couple of weeks earlier. And so I had a very busy October and November, a lot of travel.

+ +

I developed two new talks, a Ruby talk and a StoryGraph talk. It was my first ever time giving a talk on StoryGraph. It was a lot of work and amongst a lot of StoryGraph work that I needed to do. All of the talks went well, and it was so much fun to be back on the circuit again. And I'm looking forward to whatever speaking things crop up this year.

+ +

VICTORIA: That's wonderful. I'm excited. I'll have to see if I can find a recording and get caught up myself. Going back to an earlier question, you mentioned quite a few times about market research and talking to the customers. And I'm just curious if you have a method or a set of tools that you use to run those experiments and collect that feedback and information.

+ +

NADIA: Yes. So I remember one of the first things I did years ago was I read "The Mom Test" by Rob Fitzpatrick. And that's great for just getting the foundation of when you talk to customers; you don't want to lead them on in any shape or form. You just want to get the raw truth and go from there. So that's the underpinning of everything I do.

+ +

And then, I learned from friends I made through Pivotal about how you put together a script for a customer research. You can't just have bullet points or whatever. You should have a script. And the foundation of that script is a hypothesis about what you're trying to find out in that round of research. And once you figure out your hypothesis, then you can put together the questions you want to ask and understand how you're going to measure the output.

+ +

So the first ever thing I was trying to find out when I first started interviewing people was just very general. It was just like, are there any pain points? I was just trying to figure out are there any pain points among the avid reader group of people? And then I remember the results from that were, "No place for consistent, high-quality recommendations." And so then I said, okay, how are people finding recommendations now, or what are the factors that lead to people thinking a book was great for them? And that's how I ended up getting to the moods and pace.

+ +

But when I do my interviews, I record them all. I watch them back. And I condense everything on sticky notes. And I use a virtual tool. And I try to take word for word. When I summarize, I still just try and use their specific words as much as possible. So I'm not adding my own editing over what they say. Every single interviewee has a different color.

+ +

And I essentially group them into themes, and that's how I unlock whatever the answers are for that round. And then I use that...I might have been trying to find out what to build next or whether we should go down a certain product direction or not. And so, depending on the outcome, that helps me make up my mind about what to do. So that's the high-level process that I follow.

+ +

VICTORIA: Well, that sounds very methodical, and interesting for me to hear your perspective on that. And you mentioned that you do have a redesign coming out soon for StoryGraph. Are there any other particular products or features that you're really excited to talk about coming up soon?

+ +

NADIA: Yeah, I'm so excited about the redesign because we're bringing out...it's not just a UI improvement; it's a user experience improvement as well. So there are a lot of little features that have been asked for over the years. And actually, it was trying to deliver one of them that sparked the whole redesign. So people really want a marked as finished button. There's no way to mark as finished. You just toggle a book back to read. And some people find this quite counterintuitive, or it doesn't quite explain what they're doing.

+ +

And so when I came to deliver the mark as finished button, this was months and months ago now, I realized that the book pane was just becoming so cluttered, and I was trying to fight with it to squeeze in this link. And I remember thinking; this is not the only thing people want to see on the book pane. They also want to see when they read the book without having to go into the book page. They also want to be able to add it to their next queue.

+ +

And I just said, you know what? I need to redesign this whole thing. And so I was able to luckily work with Saron Yitbarek, who is married to my co-founder, Rob. There's a funny story about all of that. And she helped me do this redesign based on all my customer research. And so I'm just so excited to get it out because the other thing that we're bringing with it is dark mode, which is our most requested feature in history.

+ +

And it's funny because I've always felt like, ah, that's a nice-to-have. But obviously, for some people, it's not a nice-to-have; it's an accessibility issue. And even me, I'm quite strict with my bedtime. I try and be offline an hour before bed. In bed by 11, up at 6, and even me if I want to track my pages, I'm like, ooh, this is a bit bright.

+ +

And my phone itself is set on adaptive, so it's light mode during the day and dark mode during the night. And even me, I can see why people really want this and why it would just improve their experience, especially if everything else on your phone is dark. So I'm really excited to get that out, mainly for the UX improvements.

+ +

And the other thing I'm really excited to do is transition the Plus Plan to being the advanced stats package rather than the random selection of features right now. Because not only will the people who pay us get more complex stats functionalities such that they feel like, wow, the subscription fee that I pay not only does it still make me feel like I'm supporting an alternative to Goodreads, an independent alternative to Goodreads I also get such value from these extra features.

+ +

But the other thing is what I found from my customer research is that if you're a Plus customer, there's often one or two of the Plus features that you love and that you don't really use the others. But they're all really great features. And so what I'm really excited about is that we're going to make all the non-stats features free for everybody. And so I'm so excited for, like, we have a feature where if you put in a group of usernames, we look at all of your to-read lists and suggest great books for you to buddy-read together.

+ +

Now, there's a bunch of Plus users who aren't social and don't care about it. But there's going to be a bunch of our free users who are so excited about that feature, probably will use it with their book clubs, things like that. We have up-next suggestions where we suggest what you should pick up next from your to-read pile based on a range of factors. It could be, oh, you're behind on your reading goal; here's a fast-paced book. Or this book is very similar to the one that you just finished, so if you want something the same, pick up this one. And, again, that's behind a paywall right now, and I'm just so excited for everybody to be able to use that.

+ +

When I remember starting out with StoryGraph, I remember thinking, wow, the way this is going, wouldn't it be so cool if we could just suggest books that would be the next perfect read for you? Because a lot of people have a pile of books by their bedside table or on their shelves, and they're just like, well, which one should I start with? And this tool literally helps you to do that. And so I can't wait for everyone to be able to try it. And so that's why I'm excited about that transition because the Plus Plan will be better, and the free product will be better.

+ +

VICTORIA: That sounds amazing. And I'm thinking in my head like, oh, I should start a book club with thoughtbot. Because there are some engineering management and other types of books we want to read, so maybe we could use StoryGraph to manage that and keep ourselves motivated to actually finish them. [laughs]

+ +

NADIA: Cool.

+ +

VICTORIA: No, this is wonderful. And what books are on your reading list coming up?

+ +

NADIA: Yes. I am excited to read...I'm not sure...I'm blanking on the series' name. But the first book is called "The Poppy War." I don't know whether it's called "The Burning God" or if that's the third book in the series. But it's this very popular trilogy, and I'm excited to read that soon. I'm doing a slow chronological read of Toni Morrison's fiction. I recently read "Song of Solomon," which was great, really, really good. And so I'm excited to read more of her novels this year.

+ +

I'm also on a kind of narrative nonfiction kick right now. I love narrative nonfiction. So I just finished reading "American Kingpin," which is about Silk Road. And I've picked up "Black Edge," which is about SAC Capital and Steve Cohen and that whole hedge fund insider trading situation. So I'm probably going to look for more of the same afterwards.

+ +

VICTORIA: Well, that's very exciting. And it's inspiring that as a founder, you also still have time to read [laughs] and probably because StoryGraph makes it easy and motivating for you to do so.

+ +

NADIA: Yeah, everyone thought that my reading would tank once I started the company, but, in fact, it's multiplied severalfold. And a couple of reasons; one is it's very important in general for me to make time for me because I'm in a situation that could easily become very stressful and could lead to burnout. So I make sure that I make time for me to read and to go to dance class regularly, which is my other main hobby.

+ +

But then, secondly, I feel like I can justify it as work. Because I say, wow, me being a reader and being able to communicate with people on Instagram and on Twitter about books, not just the product, adds legitimacy to me as the founder and developer of this product. And so it's important that I keep reading. And it also helps the product be better because I understand what features are needed. So, for example, I never used to listen to audiobooks. I'm a big podcast person; I love music. So between those two, when does audio fit in?

+ +

And also, I didn't like the idea that I could just be absent-minded sometimes with some podcasts, but with a book, you don't want spoilers. It could get confusing. But I started listening to audiobooks because we had a large audiobook user base. And they would ask for certain features, and it was really hard for me to relate and to understand their needs.

+ +

And now that I have started listening to audiobooks as well, we made some great audiobook listeners-focused additions to the app last year, including you can track your minutes. So you can literally get you read this many pages in a day, but you also listened to this many minutes. You can set an hours goal for the year, so not just a reading goal or a pages goal. You can set an hours goal.

+ +

Or maybe you're someone like me, where audiobooks are the smaller proportion of your reading, and you just want it all calculated as pages. And so I've got it on the setting where it's like, even when I track an audiobook in StoryGraph, convert it to pages for me, and I just have my nice, all-round page number at the end of the year.

+ +

VICTORIA: That's so cool. Really interesting. And I've had such a nice time chatting with you today. Is there anything else that you'd like to share as a final takeaway for our listeners?

+ +

NADIA: If you are someone who wants to start a company, maybe you want to bootstrap, you've got a product idea, I think it's honestly just trust the process. It will take time. But if you trust the process, you listen to customers and really listen to them...research ways to talk to customers, and don't cut corners with the process. There have been so many times when I've done a whole round of research, and then I say, oh, do I have to go through all these now and actually do a synthesis? I think anecdotally; I can figure out what the gist was; no, do the research. You don't know what insights you're going to find.

+ +

And I think if you just trust that process...and I think the other thing is before you get to that stage, start building up a runway. Having a runway is so powerful. And so whether it's saving a bit more or diverting funds from something else if you have a runway and you can give yourself a couple of years, a few years without worrying about your next paycheck, that is incredibly valuable to getting started on your bootstrapping journey.

+ +

VICTORIA: Thank you. That's so wonderful. And I appreciate you coming on today to be with us.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Mastodon at Victoria Guido.

+ +

This podcast is brought to by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Nadia Odunayo.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Nadia Odunayo is the Founder and CEO of The StoryGraph, a new website and app for avid book readers because life's too short for a book you're not in the mood for. The StoryGraph helps you track your reading and choose your next book based on your mood, favorite topics, and themes.

+ +

Victoria talks to Nadia about coming up with a product based on the concept of mood, what you're in the mood for to read, i.e., this book made me feel this way. How do I find a book that makes me feel similar? They also talk about keeping yourself open to feedback, the ability to flow and change direction, and developing a reviewing system that keeps biases in check.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Nadia Odunayo, Founder and CEO of StoryGraph, a new website and app for avid book readers because life's too short for a book you're not in the mood for. StoryGraph helps you track your reading and choose your next book based on your mood and your favorite topics and themes. Nadia, thank you for joining me.

+ +

NADIA: Thank you for having me.

+ +

VICTORIA: And you are a repeat guest at Giant Robots. But for those who missed that episode, tell me a little bit about your journey. And how did this all get started?

+ +

NADIA: Okay. Yeah, so that first time was in 2015, and that was not too long after I had just got into tech. I did a bootcamp in London in 2014, Makers Academy, and that's where I learned to code. My degree was in philosophy, politics, and economics, so rather different. I worked at Pivotal for about a year and a half after I graduated from Makers Academy. And during my time at Pivotal, I got into conference speaking, and my first talk was around game theory.

+ +

So I took my favorite topic in economics, game theory, and I combined that with distributed systems because that's what I was working on at the time in Pivotal on their Cloud Foundry PaaS. I think I gave it at RailsConf, and I think someone there recommended me to Giant Robots. And so Ben Orenstein interviewed me, and it was all about different types of conference talks and that kind of thing.

+ +

So after Pivotal, I left and started a hybrid kind of consultancy/product company with a colleague, did that for about a year, left that, worked for about a year with my friend, Saron Yitbarek, on her company CodeNewbie. And then, when that partnership ended, I essentially had five years of runway from money that I got from the company that I started after Pivotal because we did some consulting with a bank.

+ +

I'd always been entrepreneurial. I'd been doing various entrepreneurial things since secondary school, actually, high school. It was time for me to just have time on my side projects. And so I started hacking away on one of my side projects at the beginning of 2019 in January, and I haven't stopped since. That's what the StoryGraph has developed into.

+ +

VICTORIA: Wonderful. And yes, I saw that the very early stages of StoryGraph started as a creative writing e-publication. Is that right?

+ +

NADIA: So what happened was when I was at university, I started a creative writing e-publication, came up with the name The StoryGraph. Because we had won or we were going for some grant funding or something like that, I set up a corporate entity. And when I stopped working on that e-publication, I remember my mom saying to me, "Don't shut down the entity. I really like the name. I feel like you'll use it for something," that was in 2012.

+ +

And so fast forward to 2019, and the side project that I was working on was called Read Lists. And it was very specifically focused on tracking and sharing progress through reading lists on a dashboard. But when I was doing customer research, and the scope of the project grew, Read Lists didn't fit anymore. And that's when I realized, oh, I can use The StoryGraph thing again. And so it's basically had two different lives or two different forms, the StoryGraph company.

+ +

VICTORIA: That's wonderful. And I'm reading about StoryGraph and how it's an Amazon-free alternative to Goodreads. Can you talk a little bit more about the product and why people would want to use it?

+ +

NADIA: So, as I said, it started life as a very specific focused side project. And I just had so much fun working on it and working in the book space. I'd always been a reader since I was a kid such that I said to myself, I need to find a way to make me building a books product a full-time thing. And so that's when customer research came in because the only way that you're going to make sure that you don't build something that people don't want is by talking to people.

+ +

As I was doing customer research and figuring out, are there pain points amongst readers, people who track their reading? What would happen was the pain points that came up drove me towards building a more fully fledged reading, tracking, and recommendations product. It actually started as a very focused recommendations product. And then, we got to the point where we needed to build more around it for it to be a compelling product.

+ +

And as it was growing, we never advertised ourselves as a Goodreads alternative or as an Amazon-free alternative to what was out there. But that was clearly a pain point in the market. There were tweets about us saying, "Finally a Goodreads alternative. It's small; it's independent; it's Amazon-free. And so thousands and thousands, hundreds of thousands of people have come to us because of that.

+ +

VICTORIA: Wow.

+ +

NADIA: And so it got to the point...mainly when we launched our payment plan, and we were trying to figure out the reasons why people were pre-ordering the plan, it was at that point where we decided to lean into the Amazon-free Goodreads alternative because that was what the market wanted.

+ +

VICTORIA: Was that surprising for you? Or were there other things that came out of your research on your marketplace that kind of were different than what you thought it would be going in?

+ +

NADIA: I think the most interesting thing about the product development journey was that I at least originally felt like I was building a product that wasn't for me. So what I mean by that is in my earliest rounds of research, what I was finding was that people still didn't think that they had one place to get consistently good book recommendations. And so then I started to explore, well, how do you even give somebody consistently good book recommendations?

+ +

And one of the factors that kept on coming up was this concept of mood, what you're in the mood for. This book made me feel this way. How do I find a book that makes me feel similar? And so it got to the point where I said to myself, oh wow, I'm building a product for mood readers right now; that seems to be the gap, that seems to be the thing that nothing out there yet had properly attacked. And I had never considered myself a mood reader. I just thought I'm a planner. I'm an organized person. I typically decide what book I want to read, and then I read it.

+ +

And so there was a point where I was concerned, and I thought, wait, am I now building something that is not for me? But then, as I started to work and do more research and talk to more and more people and thinking about my reading experiences, I developed the hypothesis or the viewpoint rather that I think everybody's a mood reader; it's just the scale. Because there are probably some books that I may have rated lowly in the past that if I had read it in a different frame of mind, or at a different time in my life, different circumstance, it probably would have resonated with me a lot more.

+ +

Now, that's not to say that's true for every single book. There are some books that are just not going to work for you, no matter what. But I do think we're all on the scale of mood reading. And sometimes we say a book is a bad book, but we just read it at not the right time. And so I think the most surprising thing for me is going on that journey of realizing that, oh, I am a mood reader too.

+ +

VICTORIA: [laughs]

+ +

NADIA: And I ended up building an app that's a lot less focused on just the pure ratings. I was someone who, on Goodreads, if it had less than four stars, I'm not interested. And the ethos of the product is more about, well, hang on; these ratings are very subjective. And someone else's two, three-star could be your next five-star. What are the factors that really matter? Do you want something dark, adventurous? Are you looking for something funny, light? And then what kind of topics do you want to discover? And then it doesn't matter if the five people before you thought it was average; you might think it's excellent.

+ +

VICTORIA: Yeah, it reminds me thinking about how bias can come in with authors and writing as well. So a simple five-star system might be more susceptible to bias against different genders or different types of names. Whereas if you have more complex numbers or complex rating systems, it might be easier to have different types of authors stand out in a different way.

+ +

NADIA: That actually relates to what was going through my mind when I was developing the reviewing system on StoryGraph. You can just, if you want, leave your star rating and say no more, but the star rating is lower down on the page. And up front, we say this book would be great for someone who's in the mood for something...and then you've got checkboxes. And how would you rate the pace of the book?

+ +

And if it's a fiction book, we ask you, "Are the characters lovable?" Is there a flawed narrator? Is it plot-driven or character-driven?" Questions like that because the thinking is it doesn't matter whether you are going to give the book two stars in your own personal star rating. You can still help someone else find a book that's good for them because they will be looking at the summary on the StoryGraph book page, and they'll go, "Oh wow, 80% of people said it's lovable. There's a diverse range of characters, and it's funny. So the topics fit things I'm interested in, so I care less about the average rating being like 3.5 because everything else seems perfect. Let me see for myself."

+ +

And actually, we've also had a lot of feedback from people saying that "Oh, normally, I never know how to review a book or what to say. And this system has really helped me, almost give me prompts to get started about explaining the book, reviewing it for other people to help them decide if it's for them. So that's great."

+ +

VICTORIA: That makes sense to me because I read a lot of books, maybe not as much as I would like to recently. But not all books that I love I can easily recommend to friends, but it's hard for me to say why. [laughs] You know, like, "This is a very complicated book." So I love it. I'll have to check it out later. It's been four years since you've been full-time or since 2019, almost five then.

+ +

NADIA: Yes.

+ +

VICTORIA: If you could travel back in time to when you first started to make this a full-time role, what advice would you give yourself now, having all of this foresight?

+ +

NADIA: Have patience, trust the process because I can sometimes be impatient with, ah, I want this to happen now. I want this to pick up now. I want these features done now. I'm a solo dev on the project. I started it solo. I have a co-founder now, but I'm still the solo dev. And there were so many things, especially now that we've got a much larger user base, that people complained about or say is not quite right. And that can be really tough to just have to keep hearing when you're like, I know, but I don't have the resource to fix it right now or to improve it.

+ +

But I think one of the things is, yeah, having faith in the process. Keep going through the cycles of listening to the customers, prioritizing the work, getting the work done, getting the feedback, and just keep going through that loop. And the product will keep getting better. Because sometimes it can feel, particularly in the first year when I was so low, you sometimes have moments of doubt. Or if a customer research round doesn't go super well, you start to wonder, is this only a nice-to-have? And is this going to go anywhere? And so that's one piece of advice.

+ +

And I think the other one is knowing that there are several right paths because I think sometimes I would agonize over I want to do the right thing. I want to make sure I make the right choice right now. And, I mean, there are some things that are not good to do. You want to make sure that you're setting up your customer interviews in a non-leading way. You want to make sure that there are certain standards in the product in terms of the technical side and all that kind of stuff, so there's that.

+ +

But I think it's understanding that you kind of just have to make a decision. And if you set yourself up to be able to be adaptive and responsive to change, then you'll be fine. Because you can always change course if the response you're getting back or the data you're getting back is going in the wrong direction.

+ +

VICTORIA: I love that. And I want to pull on that thread about being open to changing your mind. I think that many founders start the company because they're so excited about this idea and this problem that they found. But how do you keep yourself open to feedback and keeping that ability to flow and to change direction?

+ +

NADIA: I mean, I didn't set out to build a Goodreads alternative, and here I am.

+ +

VICTORIA: [laughs]

+ +

NADIA: I just wanted to build this specific side project or this specific...it was a companion app, in fact. Like, the first version of the thing I built, the first thing you had to do was sign in and connect your Goodreads account so that we could pull in your shelves and start creating the dashboards. So as a solo bootstrapping founder, building a Goodreads alternative was not something that I thought was going to lead to success.

+ +

But through years of experience, and just hearing other people's stories, and research, I just learned that it's such a hard space just running a startup in general, and 90% of startups fail. And I just said to myself that, okay, the only way I can kind of survive for longer is if I am open to feedback, I'm open to change course, I'm patient, and I trust the process. These are the things I can do to just increase my chances of success.

+ +

And so that's why I kind of feel it's imperative if you want to go down this route and you want to be successful, it's vital that you're open to completely changing the product, completely changing your direction, completely going back on a decision. You'll either lose customers or you'll run out of money, whatever it is. And so yeah, you've got to just basically be quite ruthless in the things that are just going to minimize your chances of failing.

+ +

VICTORIA: That makes sense. And now, I have a two-part question for you. What's the wind in your sails? Like, the thing that keeps you going and keeps you motivated to keep working on this? And then, conversely, what's kind of holding you back? What are the obstacles and challenges that you're facing?

+ +

NADIA: I think this kind of role...so I'm like founder, CEO, and developer. In general, I think I thrive under pressure and pushing myself, and trying to always be better and improve. So I'm always trying to be like, how can I improve my productivity? Or how can I run the company better? All these kinds of things. So I feel like I'm getting to explore maximizing my full potential as someone in the world of work through doing this. So that just intrinsically is motivating to me.

+ +

I love books, and I love reading. I think it's such an amazing hobby. And the fact that I get to make other readers happy is awesome. So even just as the product has grown, the messages that we get about if someone got a perfect recommendation from StoryGraph, or they hadn't read for years, and now an easy form of, you know, what are you in the mood for? Check a few boxes, and we'll show you some books that fit, whatever it is. That's just so...it's so awesome just to be able to enhance readers' lives that way in terms of the things they're reading and getting them excited about reading again or keeping them excited.

+ +

So those are the things that keep me going, both the personal nature of enjoying my work and enjoying trying to be the best founder and CEO that I can and building a great product. It's always great when you build something, and people just enjoy using it and like using it. So I'm always incentivized to keep making the product better, the experience better.

+ +

I'm currently mid a redesign. And I'm just so excited to get it out because it's going to touch on a lot of repeated pain points that we've been having for years. And I just can't wait for everyone to see it and see that we've listened to them. And we're making progress still like three and a bit years on since we launched out of beta.

+ +

What's tough? Previously, what's been tough is navigating, remaining independent, and bootstrapped with just personally trying to make money to just live my life. So I had five years of runway. And it was this tricky situation about when I had a couple of years left, I'm thinking, wow, I really like doing this, but I'm going to need to start earning money soon. But I also don't want to get investment. I don't want to stop doing this. I can't stop doing this. We've got hundreds of thousands of customers.

+ +

And so kind of trying to balance my personal needs and life situations with the work I've been doing because I've been working so hard on it for so long that in the last couple of years, it's gotten to a point where it's like, how do I craft the life I want out of a product that is very not set up to be an indie bootstrapped product? [laughs] Typically, you want to do a B2B. You want to start earning money from your product as early as possible. And I feel like I've landed in a product that's typically funded, VC-backed, that kind of thing. So kind of navigating that has been a fun challenge.

+ +

There's not been anything that's kind of demoralized me or held me back, or made me think I shouldn't do it. And it's just kind of been a fun challenge trying to...yeah, just navigate that. And we've been doing things like we're currently in the process of transitioning our...we have a Plus Plan. And when we launched it, it was essentially a grab bag of features. We're completely changing the feature set. And we right now have six and a half thousand people who are on that plan. But we don't have product market fit on that plan, and I can tell from when I do certain surveys the responses I get back.

+ +

And so we're completely transitioning that to focus in on our most popular feature, which is the stats that we offer. And so that's kind of scary, but it's part of making that Plus Plan more sticky and easier to sell because it's going to be for your power users who love data. So they want all the data when they are reading.

+ +

And then the other thing is, okay, what kind of business avenue can we start which fits in with the ethos of the product but brings in more revenue for StoryGraph? And so, we launched a giveaway segment in our app where publishers and authors can pay to list competitions for users to win copies of their books. And it's essentially a win-win-win because publishers and authors get another channel to market their books. Users get to win free books, and readers love winning free books. And StoryGraph has another revenue source that helps us stay independent and profitable, and sustainable in the long run.

+ +

VICTORIA: That's wonderful. And there are two tracks I want to follow up on there; one is your decision not to seek funding; if you could just tell me a little more about the reasoning and your thought process behind that. And you've already touched on a little bit of the other ways you're looking at monetizing the app.

+ +

NADIA: Since I was a teenager, I've always been interested in business, economics, entrepreneurship. I've always felt very entrepreneurial. I've read so many founder stories and startup stories over the years. And you hear about venture capitalists who come in, and even if it's fine for the first year or two, ultimately, they want a return. And at some point, that could come at odds with your mission or your goals for your company.

+ +

And when I think about two things, the kind of life I want and also the nature of the product I'm building as well, VC just doesn't fit. And I know there are so many different funding programs and styles right now, a lot more friendlier [laughs] than VC. But I'm just focusing on VC because when I was younger, I used to think that was a marker of success. VC funding that was the track I thought I was going to go down, and that was what I kind of idolized as, oh my gosh, yes, getting a funding round of millions and millions and then building this huge company. That was how I used to be, so it's so interesting how I've completely gone to the other side.

+ +

That idea that you could have mismatched goals and how it's ruined companies, once you take the first round of funding and you grow and expand, then you've got to keep taking more to just stay alive until some liquidation event. That just doesn't appeal to me. And I just think there's something ultimately very powerful and valuable about building a product without giving up any ownership to anybody else and being able to make it into something that people love, and that's profitable, and can give the people who run it great lifestyles. I just think that's a mark of an excellent product, and I just want to build one of those.

+ +

And then I think also the nature of the product itself being a book tracking app. I think the product has done well because it is run and built so closely by myself and Rob. And so it's like, people talk about how, oh, you can tell it's built for readers by readers by people who care. And I run the company's Instagram, and it's not just me talking about the product.

+ +

I'm talking with a bunch of our users about books and what we're reading. And it really feels like it's just got such a great community feel. And I worry that that can get lost with certain types of investment that I've previously thought that I wanted in my life. And so, yeah, that's the reason why I've kind of strayed away from the investment world.

+ +

And then it's gotten to the point, like, now we're at the point where we don't need funding because we've been able to get to profitability by ourselves. So we don't need any type of funding. And we're just going to try and keep doing things to keep making the product better, to convert more people to the Plus Plan.

+ +

And, hopefully, our giveaways platform grows in the way we want such that our goal is to just stay profitable and independent forever for as long as possible. And we think that way, we're going to have the most fun running the company, and the product is going to be the best it can be because there's not going to be competing incentives or goals for the product.

+ +

VICTORIA: That makes sense. And it sounds like, in reality, in the real case, you had a team, and you had the skills yourself to be able to move the product forward without having to take on funding or take on additional support, which is awesome. And I actually really like your background. I also have a degree in economics. So I'm curious if the economics and philosophy, all of that, really lends itself to your skills as a founder. Is that accurate?

+ +

NADIA: I don't think so.

+ +

VICTORIA: [laughs]

+ +

NADIA: I love my degree. I get sad when I meet econ grads or econ majors, and they're like, "Oh, I hated it. Oh, it was so boring," or whatever. I'm like, "No, it was so great." I'm a big microeconomics fan, so I was all about...I didn't like macro that much. I was all about the game theory and the microeconomic theory, that kind of stuff.

+ +

I don't think there's anything that really ties into my skills as a founder. I feel like that's more to do with my upbringing and personality than what I studied. But, I mean, one of the reasons I did love my degree is because there are elements that do crop up. It's such a widely applicable...the subjects I did are so widely applicable, philosophy, different ways of seeing the world and thinking and approaching different people.

+ +

And then, obviously, economics that's essentially behavior, and how markets work, and incentives, and all that kind of stuff. And when you get to pricing and all those sorts of things, and business, and then politics as well, I mean, everything is politics, right? People interacting. So there are definitely things and conversations I had at university, which I see things crop up day to day that I can tie back to it. But yeah, I think it doesn't really...my specific degree, I don't think it's made me a better founder than I would have been if I'd studied, I don't know, English or Math or something.

+ +

VICTORIA: Right, yeah. I think economics is one of those where it's kind of so broadly applicable. You're kind of using it, but you don't even realize it sometimes. [laughs]

+ +

NADIA: Yeah.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator.

+ +

VICTORIA: So what made you decide to go to a bootcamp right after finishing school?

+ +

NADIA: So I'd always been entrepreneurial. I remember...I don't know where exactly it started from, whether I got it from my mom. I know she's always been very entrepreneurial and into business. The earliest memory I have of doing something that was very specifically business-oriented was in what we call sixth form in the UK, which is essentially the last two years of high school before you go to university or college; we had this scheme called Young Enterprise.

+ +

And essentially, you got into teams of people, small teams, or they could be quite big, actually. It could be up to 20 people. And you started a business, and there were trade shows, and pitch meetings, and all that kind of stuff, so I remember getting involved in all that sort of stuff at school.

+ +

But I'd always been on the investment banking track because when I was young...so my parents...we come from a poor background. And so my parents were very much like, you know, try and find high-paying careers to go into so that you can pay for whatever you want and you have a much better lifestyle. So I had gotten onto the investment banking track from the age of 14 when I went with a friend...at the school, I went to, there was a Take Your Daughter to Work Day.

+ +

My dad said, "Oh, you want to go to try and find someone whose parent works in an investment bank or something like that. That's like a great career to go into." And so I went with a friend's dad to UBS. And I remember being blown away, like, wow, this is so fascinating. Because I think everything seems so impressive when you're 14, and you're walking into a space like that, and everything seems very lively. And everyone's walking around dressed sharp. They've got their BlackBerries.

+ +

So from the age of 14 until 20, it would have been, I was very much I am going to work in an investment bank. And I did all the things that you would do, like all the schemes, the spring programs. And it got to my final internship. And I just remember at the internship being rather disillusioned and disappointed by the experience. I remember thinking, is this it? I was studying at Oxford, and I put so much into my studies. And I remember thinking; I'm working so hard. And this is what I come to? Is this it?

+ +

And so around the time as well, I was also meeting a lot of people in the entrepreneurship space, social enterprises, people doing their own ventures. And I just remember thinking, oh, I feel like I've got to go down that track. And I ended up winning a place on a coding course. It was set up specifically to help more women get into tech. And it was called Code First Girls. I won a place that started...it was just part-time.

+ +

What I did was I actually...I got the banking job from Deutsche Bank, it was, but I decided to turn it down. It was a very risky decision. I turned it down, and I stayed in Oxford after graduating and worked in the academic office for a while. And then, twice a week, I would go to London and do this coding course. And during it, on Twitter, I remember seeing a competition for a full-paid place at this bootcamp called Makers Academy. And I just thought to myself, having tech skills, I'd heard the feedback that it's a very powerful thing to have.

+ +

And I remember thinking I should go for this competition. And I went for the competition, and I won a free place at the bootcamp. If I didn't win a free place at the bootcamp, I'm not sure what would have happened because I'm not sure whether at that point I would have thought, oh, paying £8,000 to go to a software bootcamp is what I should do. I'm not sure I would have got there. So that's how I got there, essentially. I won a competition for a bootcamp after having a taste of what coding was like and seeing how freeing it was to just be able to have a computer and an internet connection and build something.

+ +

VICTORIA: Oh, that's wonderful. I love that story. And I've spent a lot of time with Women Who Code and trying to get women excited about coding. And that's exactly the story is that once you have it, it's a tool in your toolset. And if you want to build something, you can make it happen. And that's why it's important to continue the education and get access for people who might not normally have it. And you continue to do some of that work as well, right? You're involved in organizations like this?

+ +

NADIA: Like Code First Girls? No. I did some years ago. I would go and attend Rails Girls workshops and be a mentor at them, at those. And while I was at Pivotal, I helped with events like codebar, which were essentially evenings where people who were learning to code or more junior could come and pair with someone more senior on whatever project they wanted to.

+ +

So I did a bunch of that stuff in the years after leaving Makers Academy. And I was even a TA for a short time for a couple of weeks at Makers Academy as well after I graduated. But in more recent years, I haven't done much in that space, but I would love to do more at some point. I don't have the bandwidth to right now. [laughs]

+ +

VICTORIA: And you're still a major speaker going and keynoting events all around the world. Have you done any recently, or have any coming up that you're excited about?

+ +

NADIA: So before the pandemic, my last talk, I keynoted RubyWorld in Japan. That was in November 2019. And then the pandemic hit, and 2020 June, July was when StoryGraph had some viral tweets, and so we kicked off. And amongst all of that, I was being invited to speak at remote events, but it just didn't make sense for me. Not only was I so busy with work, but I put a lot of hours into my talks. And part of the fun is being there, hallway track, meeting people, being on stage. And so it just didn't appeal to me to spend so much time developing the talk to just deliver it at home.

+ +

And so, I just spent all the time on StoryGraph. And I remember when events started happening again; I wondered whether I would even be invited to speak because I felt more detached from the Ruby community. Most of the conferences that I did were in the Ruby community. StoryGraph is built on Rails. Yeah, I just thought maybe I'll get back to that later.

+ +

But all of a sudden, I had a series of amazing invitations. Andrew Culver started up The Rails SaaS Conference in LA in October, and I was invited to speak at that. And then, I was invited to keynote RubyConf, that was recently held in Houston, Texas, and also invited to keynote the satellite conference, RubyConf Mini in Providence, that happened a couple of weeks earlier. And so I had a very busy October and November, a lot of travel.

+ +

I developed two new talks, a Ruby talk and a StoryGraph talk. It was my first ever time giving a talk on StoryGraph. It was a lot of work and amongst a lot of StoryGraph work that I needed to do. All of the talks went well, and it was so much fun to be back on the circuit again. And I'm looking forward to whatever speaking things crop up this year.

+ +

VICTORIA: That's wonderful. I'm excited. I'll have to see if I can find a recording and get caught up myself. Going back to an earlier question, you mentioned quite a few times about market research and talking to the customers. And I'm just curious if you have a method or a set of tools that you use to run those experiments and collect that feedback and information.

+ +

NADIA: Yes. So I remember one of the first things I did years ago was I read "The Mom Test" by Rob Fitzpatrick. And that's great for just getting the foundation of when you talk to customers; you don't want to lead them on in any shape or form. You just want to get the raw truth and go from there. So that's the underpinning of everything I do.

+ +

And then, I learned from friends I made through Pivotal about how you put together a script for a customer research. You can't just have bullet points or whatever. You should have a script. And the foundation of that script is a hypothesis about what you're trying to find out in that round of research. And once you figure out your hypothesis, then you can put together the questions you want to ask and understand how you're going to measure the output.

+ +

So the first ever thing I was trying to find out when I first started interviewing people was just very general. It was just like, are there any pain points? I was just trying to figure out are there any pain points among the avid reader group of people? And then I remember the results from that were, "No place for consistent, high-quality recommendations." And so then I said, okay, how are people finding recommendations now, or what are the factors that lead to people thinking a book was great for them? And that's how I ended up getting to the moods and pace.

+ +

But when I do my interviews, I record them all. I watch them back. And I condense everything on sticky notes. And I use a virtual tool. And I try to take word for word. When I summarize, I still just try and use their specific words as much as possible. So I'm not adding my own editing over what they say. Every single interviewee has a different color.

+ +

And I essentially group them into themes, and that's how I unlock whatever the answers are for that round. And then I use that...I might have been trying to find out what to build next or whether we should go down a certain product direction or not. And so, depending on the outcome, that helps me make up my mind about what to do. So that's the high-level process that I follow.

+ +

VICTORIA: Well, that sounds very methodical, and interesting for me to hear your perspective on that. And you mentioned that you do have a redesign coming out soon for StoryGraph. Are there any other particular products or features that you're really excited to talk about coming up soon?

+ +

NADIA: Yeah, I'm so excited about the redesign because we're bringing out...it's not just a UI improvement; it's a user experience improvement as well. So there are a lot of little features that have been asked for over the years. And actually, it was trying to deliver one of them that sparked the whole redesign. So people really want a marked as finished button. There's no way to mark as finished. You just toggle a book back to read. And some people find this quite counterintuitive, or it doesn't quite explain what they're doing.

+ +

And so when I came to deliver the mark as finished button, this was months and months ago now, I realized that the book pane was just becoming so cluttered, and I was trying to fight with it to squeeze in this link. And I remember thinking; this is not the only thing people want to see on the book pane. They also want to see when they read the book without having to go into the book page. They also want to be able to add it to their next queue.

+ +

And I just said, you know what? I need to redesign this whole thing. And so I was able to luckily work with Saron Yitbarek, who is married to my co-founder, Rob. There's a funny story about all of that. And she helped me do this redesign based on all my customer research. And so I'm just so excited to get it out because the other thing that we're bringing with it is dark mode, which is our most requested feature in history.

+ +

And it's funny because I've always felt like, ah, that's a nice-to-have. But obviously, for some people, it's not a nice-to-have; it's an accessibility issue. And even me, I'm quite strict with my bedtime. I try and be offline an hour before bed. In bed by 11, up at 6, and even me if I want to track my pages, I'm like, ooh, this is a bit bright.

+ +

And my phone itself is set on adaptive, so it's light mode during the day and dark mode during the night. And even me, I can see why people really want this and why it would just improve their experience, especially if everything else on your phone is dark. So I'm really excited to get that out, mainly for the UX improvements.

+ +

And the other thing I'm really excited to do is transition the Plus Plan to being the advanced stats package rather than the random selection of features right now. Because not only will the people who pay us get more complex stats functionalities such that they feel like, wow, the subscription fee that I pay not only does it still make me feel like I'm supporting an alternative to Goodreads, an independent alternative to Goodreads I also get such value from these extra features.

+ +

But the other thing is what I found from my customer research is that if you're a Plus customer, there's often one or two of the Plus features that you love and that you don't really use the others. But they're all really great features. And so what I'm really excited about is that we're going to make all the non-stats features free for everybody. And so I'm so excited for, like, we have a feature where if you put in a group of usernames, we look at all of your to-read lists and suggest great books for you to buddy-read together.

+ +

Now, there's a bunch of Plus users who aren't social and don't care about it. But there's going to be a bunch of our free users who are so excited about that feature, probably will use it with their book clubs, things like that. We have up-next suggestions where we suggest what you should pick up next from your to-read pile based on a range of factors. It could be, oh, you're behind on your reading goal; here's a fast-paced book. Or this book is very similar to the one that you just finished, so if you want something the same, pick up this one. And, again, that's behind a paywall right now, and I'm just so excited for everybody to be able to use that.

+ +

When I remember starting out with StoryGraph, I remember thinking, wow, the way this is going, wouldn't it be so cool if we could just suggest books that would be the next perfect read for you? Because a lot of people have a pile of books by their bedside table or on their shelves, and they're just like, well, which one should I start with? And this tool literally helps you to do that. And so I can't wait for everyone to be able to try it. And so that's why I'm excited about that transition because the Plus Plan will be better, and the free product will be better.

+ +

VICTORIA: That sounds amazing. And I'm thinking in my head like, oh, I should start a book club with thoughtbot. Because there are some engineering management and other types of books we want to read, so maybe we could use StoryGraph to manage that and keep ourselves motivated to actually finish them. [laughs]

+ +

NADIA: Cool.

+ +

VICTORIA: No, this is wonderful. And what books are on your reading list coming up?

+ +

NADIA: Yes. I am excited to read...I'm not sure...I'm blanking on the series' name. But the first book is called "The Poppy War." I don't know whether it's called "The Burning God" or if that's the third book in the series. But it's this very popular trilogy, and I'm excited to read that soon. I'm doing a slow chronological read of Toni Morrison's fiction. I recently read "Song of Solomon," which was great, really, really good. And so I'm excited to read more of her novels this year.

+ +

I'm also on a kind of narrative nonfiction kick right now. I love narrative nonfiction. So I just finished reading "American Kingpin," which is about Silk Road. And I've picked up "Black Edge," which is about SAC Capital and Steve Cohen and that whole hedge fund insider trading situation. So I'm probably going to look for more of the same afterwards.

+ +

VICTORIA: Well, that's very exciting. And it's inspiring that as a founder, you also still have time to read [laughs] and probably because StoryGraph makes it easy and motivating for you to do so.

+ +

NADIA: Yeah, everyone thought that my reading would tank once I started the company, but, in fact, it's multiplied severalfold. And a couple of reasons; one is it's very important in general for me to make time for me because I'm in a situation that could easily become very stressful and could lead to burnout. So I make sure that I make time for me to read and to go to dance class regularly, which is my other main hobby.

+ +

But then, secondly, I feel like I can justify it as work. Because I say, wow, me being a reader and being able to communicate with people on Instagram and on Twitter about books, not just the product, adds legitimacy to me as the founder and developer of this product. And so it's important that I keep reading. And it also helps the product be better because I understand what features are needed. So, for example, I never used to listen to audiobooks. I'm a big podcast person; I love music. So between those two, when does audio fit in?

+ +

And also, I didn't like the idea that I could just be absent-minded sometimes with some podcasts, but with a book, you don't want spoilers. It could get confusing. But I started listening to audiobooks because we had a large audiobook user base. And they would ask for certain features, and it was really hard for me to relate and to understand their needs.

+ +

And now that I have started listening to audiobooks as well, we made some great audiobook listeners-focused additions to the app last year, including you can track your minutes. So you can literally get you read this many pages in a day, but you also listened to this many minutes. You can set an hours goal for the year, so not just a reading goal or a pages goal. You can set an hours goal.

+ +

Or maybe you're someone like me, where audiobooks are the smaller proportion of your reading, and you just want it all calculated as pages. And so I've got it on the setting where it's like, even when I track an audiobook in StoryGraph, convert it to pages for me, and I just have my nice, all-round page number at the end of the year.

+ +

VICTORIA: That's so cool. Really interesting. And I've had such a nice time chatting with you today. Is there anything else that you'd like to share as a final takeaway for our listeners?

+ +

NADIA: If you are someone who wants to start a company, maybe you want to bootstrap, you've got a product idea, I think it's honestly just trust the process. It will take time. But if you trust the process, you listen to customers and really listen to them...research ways to talk to customers, and don't cut corners with the process. There have been so many times when I've done a whole round of research, and then I say, oh, do I have to go through all these now and actually do a synthesis? I think anecdotally; I can figure out what the gist was; no, do the research. You don't know what insights you're going to find.

+ +

And I think if you just trust that process...and I think the other thing is before you get to that stage, start building up a runway. Having a runway is so powerful. And so whether it's saving a bit more or diverting funds from something else if you have a runway and you can give yourself a couple of years, a few years without worrying about your next paycheck, that is incredibly valuable to getting started on your bootstrapping journey.

+ +

VICTORIA: Thank you. That's so wonderful. And I appreciate you coming on today to be with us.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Mastodon at Victoria Guido.

+ +

This podcast is brought to by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Nadia Odunayo.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hrsc610s + + ]]> + + Victoria Guido + Nadia Odunayo + + + 461: PSYONIC with Dr. Aadeel Akhtar + https://podcast.thoughtbot.com/461 + 60938a48-3a53-4117-8f09-33a7de5988ba + Thu, 09 Feb 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Dr. Aadeel Akhtar is the Founder and CEO of PSYONIC, a company whose mission is to develop advanced prostheses that are affordable for everyone. + +Victoria talks to Dr. Akhtar about the gaps in the market he saw in current prosthetic ability, advancements PSYONIC has been able to make since commercialization, and essential principles and values when you were building out the team. + 34:01 + no + + + Dr. Aadeel Akhtar is the Founder and CEO of PSYONIC, a company whose mission is to develop advanced prostheses that are affordable for everyone. +Victoria talks to Dr. Akhtar about the gaps in the market he saw in current prosthetic ability, advancements PSYONIC has been able to make since commercialization, and essential principles and values that were important to him when building out the PSYONIC team. +PSYONIC (https://www.psyonic.io/) +Follow PSYONIC on LinkedIn (https://www.linkedin.com/company/psyonicinc/) or Twitter (https://twitter.com/PSYONICinc). +Follow Dr. Aadeel Akhtar on LinkedIn (https://www.linkedin.com/in/aadeelakhtar/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host Victoria Guido. And with me today is Dr. Aadeel Akhtar, Founder and CEO of PSYONIC, a company whose mission is to develop advanced prostheses that are affordable for everyone. Aadeel, thank you for joining me. +DR. AADEEL: Thank you for having me, Victoria. This is fun. +VICTORIA: Yes, I'm excited to meet you. So I actually ran into you earlier this week at a San Diego tech meetup. And I'm curious just to hear more about your company PSYONIC. +DR. AADEEL: So, as you mentioned, we develop advanced bionic limbs that are affordable and accessible. And this is actually something I've wanted to do my whole life ever since I was seven years old. My parents are from Pakistan. I was born in the Chicago suburbs. But I was visiting, and that was the first time I met someone missing a limb; and she was my age missing her right leg, using a tree branch as a crutch, living in poverty. And that's kind of what inspired me to go into this field. +VICTORIA: Wonderful. And maybe you can start with what gaps in the market did you see in current prosthetic ability? +DR. AADEEL: When we first started making these prosthetic devices, we were 3D printing them. And we thought that the biggest issue with prosthetic devices was that they were way too expensive and saw that with 3D printing, we'd be able to reduce the prices on them. And that's true; it was actually one of the biggest issues, but it wasn't the biggest issue. +After talking with hundreds of patients and clinicians, the number one thing that we found that patients and clinicians would raise issue with was that their super expensive bionic hands were breaking all the time. And these were made with injection molded plastics and custom-machined steel. And they weren't doing anything crazy with it. They would accidentally hit the hand against the side of a table, but because they were made out of rigid components, they would end up snapping up those joints. +And a natural hand, for example, if you bang a natural hand against a table or a rigid object, then it flexes out of the way. It has compliance in it, and that's why it's able to survive those types of hits and impacts a little bit more. It forced us to think outside the box of how can we still leverage the low-cost manufacturing of 3D printing but make this hand more robust than anything out there? And that's when I started looking into soft robotics. +And with soft robotics, instead of making rigid links in your robot, so instead of having rigid joints and components, you'd use soft materials like silicone that are more akin to your skin and your own biological tissues that are more flexible and compliant. So we started making the fingers out of rubber and silicone. +And now we've been able to do things like punch through flaming boards, and I dropped it from the roof of my house 30 feet up in the air, and it survived. We put it in a dryer for 10 minutes, and it survived tumbling around in a dryer. I've arm wrestled against the para-triathlete national champion and lost. So this thing was built to survive a lot more than just hitting your hand against the side of a table. +VICTORIA: Wow, that sounds incredible. And I love that you started with a premise, and then you got feedback from your users and found a completely different problem, even though that same problem still existed [laughs] about the low cost. +DR. AADEEL: Absolutely. +VICTORIA: Wow. So taking it back a little bit more to the beginning, so you knew you always wanted to do prosthetics since you grew up in Pakistan and saw people without their limbs. Take me a little bit more from the beginning of the journey. When did you decide to start the company officially? +DR. AADEEL: And just to clarify, I was just visiting Pakistan for the summer, but I grew up and was raised here in the U.S. So I went to Loyola University Chicago for undergrad, and I got a bachelor's degree in biology there, followed by a master's in computer science. And the original plan was to actually become an MD working with patients with amputations and developing prosthetics for them. +But while I was an undergraduate student at Loyola, I took my first computer science class, and I absolutely loved it. I loved everything about coding, and programming, and engineering. And I realized that if I became a straight-up MD, I wouldn't get to do any of the cool things that I was learning in my computer science classes. And I wanted to figure out a way to combine my passions in engineering and computer science with clinical medicine and prosthetics. +And right down the street at a hospital formerly known as The Rehabilitation Institute of Chicago...it's now the Shirley Ryan AbilityLab. It's the number-one rehabilitation hospital in the U.S. for the last 31 years. They made these huge breakthroughs in mind control bionic limbs where they were doing a surgery where they would reroute your nerves to other muscles that you already have on your body. And then, when you try to imagine bending your phantom elbow or making a phantom fist, your chest muscles would contract. And then you could use those signals to then control this robotic limb that was designed by Dean Kamen that was sponsored by DARPA and cost hundreds of thousands of dollars. That was just absolutely incredible. +And it was this perfect mixture of engineering and clinical medicine, and it was exactly what I wanted to get into. But, as you'd mentioned, we're all about accessibility, and a $100,000 cost hand would not cut it. And so I ended up finishing a master's in computer science. I taught at Loyola for a couple of years and then went to the University of Illinois at Urbana-Champaign, where I got another master's in electrical and computer engineering, a Ph.D. in neuroscience. And then I finished the first year of medical school before I left to run PSYONIC because it is a lot more fun building bionic limbs [laughs] than finishing medical school. +And while I was a graduate student, we started 3D printing our own prosthetic hands, and we got the chance in 2014 to go down to Quito, Ecuador, where we were working with a nonprofit organization called The Range of Motion Project. And their whole mission is to provide prosthetics to those who can't afford them in the U.S., Guatemala, and Ecuador. +And we went down there, and we were working with a patient who had lost his left hand 35 years prior due to machine gunfire from a helicopter; he was in the Ecuadorian Army. And there was a border war between Ecuador and Peru. And Juan, our patient, in front of international news stations, said that he felt as though a part of him had come back. And that was because he actually made a pinch with his left hand for the first time in 35 years. +And you have to imagine the hand at that time was three times the size of an average natural hand, adult human hand. Had wires going everywhere, breadboards, power supplies, the walls, you name it. And despite that, he said that a part of him had come back. And he actually forgot how to make a pinch with his left hand, and we had to retrain his brain by placing a mirror in front of his left side reflecting his right hand, tricking his brain into thinking that his left hand was actually there. +And he would make a pinch with both sides, and it would reactivate the muscles in his forearm on his left side. And when he said that, that's when I realized that if I stay in academia, then this just ends up as a journal paper. And if we want everyone to feel the same way that Juan did, we had to commercialize the technology. And so that's when PSYONIC was born. +VICTORIA: I love that you're working on that as someone who's from Washington, D.C., and has done a lot of work in veterans and homeless organizations and seen how life-changing getting access to limbs and regaining capability can be for people. +DR. AADEEL: Absolutely. In fact, our first user in the U.S. is a U.S. Army sergeant who lost his hand in Iraq in 2005 due to roadside bombs, Sergeant Garrett Anderson. He used a hook on a daily basis, and with our hand, he's actually able to feel his daughter's hand, which is something that he wasn't able to do with any other prosthesis. And for him to tell us that that is why we do what we do. +VICTORIA: Right. And I saw on your website that you have several patents and have talked about the advances you've been able to make in what I'm going to call the sensorimotor bionic limbs. Can you tell me a little bit more about some of the advancements you've been able to make since you decided to commercialize this? +DR. AADEEL: The first thing that usually users notice is that, and clinicians notice as well, is that the hand is the fastest bionic hand in the world. So the fingers close in about 200 milliseconds. And to put that into context, we can wink our eyes in about 300 milliseconds. So it's technically faster than the blink of an eye, which is kind of a cool statistic there. So it's super fast. And the fingers are super resistant to impact, so they're very durable. And so we've got a couple of patents on both of those items in particular. +And then there's the touch feedback aspect. So this is the only hand on the market that gives users touch feedback. And so the methods that we have to mold the fingers to enable that sensory feedback that is what our third patent is on for the hand, and it just looks really cool. It's got like this black carbon fiber on it that just looks really futuristic and bionic. +And it just gives users the confidence that this isn't something to be pitied; this is something that's really cool. And especially for our war heroes, that's something to be celebrated that I lost my hand for our country, and now I've got this really cool one that can do all of the things that my hand used to do. +VICTORIA: And I also saw that it's reimbursable by Medicare in the U.S. And I was curious if you had any lessons learned from that process for getting eligible for that. +DR. AADEEL: Yeah. And that was part of the goal from the very beginning. After we did our customer discovery process, where we figured out what the pain points are and found out that durability was one of the biggest issues, obviously, one of the other issues was the really expensive price of the other hands, and typically what we call a multi-articulated hand, so that's one where each one of the fingers move individually. +Those are only covered by the VA, so if you're in the military or workman's comp so if you had a workplace accident. And that only accounted for about 10% of the U.S. market. And what the clinicians kept telling us over and over again was that if you can get the hand covered by Medicare, then usually all the other insurance companies will follow suit, like your Blue Cross Blue Shield, your Aetna, your Kaiser, et cetera. +So that was our design goal from the beginning. So how can we hit a price point that Medicare would cover but also make this fully featured that no other hand can do any of these other things? What it primarily came down to was hitting that price point. And as long as we hit that price point, then Medicare was going to be fine with it. So we invented a lot of the manufacturing methods that we use in-house to make the hand in particular. +So we do all the silicone molding. We do all the carbon fiber work. We do all the fabric work. We do all the assembly of it in-house in our warehouse here in San Diego. And by being so vertically integrated, we're able to then iterate very quickly and make these innovations happen at a much more rapid scale so that we can get them out there faster and then help more people who need it. +VICTORIA: So you've really grown tremendously from when you first had the project, and now you have a team here in San Diego. Do you have any lessons learned for enabling your team to drive faster in that innovation? +DR. AADEEL: Yeah, the biggest thing that I feel like a lot of things come down to is just having grit. So especially with a startup, it's always going to be a roller coaster ride. And for us, I think one of the big motivating factors for us is the patients themselves when they get to do these things that they weren't able to do before. +So another one of our first patients, Tina, had just become a grandmother, and she was able to feed her granddaughter for the first time because she was able to hold the bottle with her bionic hand, The Ability Hand, and then hold her granddaughter with her natural hand and then feed her using The Ability Hand. It's, like I said, moments like that is why we do what we're doing. It gives us that motivation to work those long hours, make those deadlines so that we can help as many people as possible. +VICTORIA: Right. So you have that motivating power behind your idea, which makes a lot of sense. What else in your customer discovery sprint was surprising to you as you moved through that process? +DR. AADEEL: So there was definitely the robustness that was surprising. There was the cost that wasn't necessarily the highest priority thing, which we thought would be the highest priority. And the speed and just having to rely on visual feedback, you have to kind of look at the hand as you're doing the task that you're doing, but you have to look at it very intently. So that takes a lot of cognitive load. You have to pay attention very specifically to am I doing the right movement with my hand? In ways that you wouldn't necessarily have to do with a natural hand. +And by making the hand move so responsive as it is and move so quickly, in addition to having that touch feedback, that reduces, or at least we believe it'll reduce a lot of that cognitive load for our patients so that they don't have to be constantly monitoring exactly what the hand is doing in order to do a lot of the tasks or the activities of daily living that they're doing on a day to day basis. The whole customer discovery process drove what features we were going to focus on in actually making this hand a reality. +VICTORIA: Yeah, that makes sense. And I love hearing about what came up that surprised people. And I appreciate your commitment to that process to really drive your business idea and to solve this problem that happens to so many people in the United States. Well, how widespread is this issue? And, of course, I'm sure you're targeting more than just the United States with rollout, but... +DR. AADEEL: So, globally, there are over 10 million people with hand amputations, and 80% of them actually live in developing nations, and less than 3% have access to affordable rehabilitative care. So it's a huge need worldwide, and we want to make sure that everyone has access to the best available prosthetic devices. +VICTORIA: That makes sense. So I guess commercializing this product leads to more room, more availability across for everyone. +DR. AADEEL: Absolutely. And interesting thing about that, too, is that as we were developing these, the hand in particular, we've optimized it for humans to do human tasks. And we have a programming interface that we put on it that allows researchers to control each one of the fingers like you control the speed, the position, and the force from each one of those fingers as well as you can stream all of the touch sensors like over Bluetooth or over a USB connection, and then also the location of each one of those fingers as well. +A lot of robotics researchers who are building humanoid robots and robot arms to do other tasks like manufacturing and robotic surgery and things like that have been purchasing our hand too. So notably, for example, NASA and Meta, so Facebook Meta, have purchased our hands, and NASA is putting it on a humanoid astronaut robot, which hopefully will eventually go into space. And then, on Earth, they'd be able to control it and then manipulate objects in space. +And it's opened up an entirely new market, but the critical thing here is that it's the exact same hand that the humans are getting that the robots are getting. And what this allows us to do is just expand our volume of production and our sales so that we can actually further drive down the costs and the pricing for the human side of things as well. +So if we're talking about places like India, or Pakistan, or Guatemala, or Ecuador where there are no government incentives in place to reimburse at a rate that they might in the U.S., then we can actually get the price point to one that's actually affordable in those areas as well. And I'm really excited about those prospects. +VICTORIA: That's so cool that future robot astronauts will be financing people who have no ability [laughs] to go into space or anything like that. That's a cool business idea. I wonder, when did that happen for you, or what was that like when you realized that there was this other potential untapped market for robotic limbs? +DR. AADEEL: It's interesting. It was always in the back of our minds because, as I was a Ph.D. student, I was in the Ph.D. group that focused on robotics, in particular more so than prosthetics. And I was the first one in the group to actually kind of have the prosthetic spin on things. And so I had an idea of where the market was for the robotic side of things. And I had some connections as well. +And so I was actually giving a talk at Georgia Tech early last year. The Director of the Georgia Tech Robotics Institute, Dr. Seth Hutchinson, he was telling me that...he was like, "You should go to the big robotics conference, ICRA, because people are going to be like...absolutely love this product for their robots." And we were just like, huh, we never considered that. +And so we decided to go, and it was just absolutely nuts. We've had researchers from all over the world being like, "How can I get this hand?" And compared to a lot of the robotic hands that are out there, even on the robotic side, this is a much lower price point than what they've been dealing with. And by solving a lot of the problems on the human side, like durability, and sensory feedback, and dexterity, and the pricing, it actually solved a lot of the problems on the robotic side as well. So I was just like...after we had gone to that conference, we realized that, yeah, we can actually make this work as well. +VICTORIA: That's really cool. And it sounds like tapping into this robotics market and networking really worked for you. What else about your market research or strategy seem to be effective in your business growth? +DR. AADEEL: This is interesting as well. So half of our sales actually come from social media, which for a medical device company is usually unheard of. [laughs] Because usually the model is, for medical devices, where you have a group of sales reps located across the regions that you're selling and so across the U.S. And they would visit each one of the clinics, and then they would work with the clinicians directly in getting these on the patients. That usually accounts for like 99% of sales. And so for us, for half of them to come from social media, it was a goal that we had set out to, but it was also surprising that that accounted for so much of our volumes and our revenue. +The way we set it up was that we wanted to make videos of our hand that highlighted things that our hand could do that were novel and unique. And so, for example, we wanted to highlight the durability of the hand as well as the dexterity and the touch feedback. And so some of the first videos that we made were like arm wrestling against a bionic hand. And what's cool about that is that the general public just found that very interesting in general. +But also, when a clinician and a patient sees that, wow, this hand can actually withstand the forces of an actual arm wrestling match, then they're also just as impressed. And the same thing with punching through three wooden boards that we set on fire; if it can handle that, then it can handle activities of daily living. General public seizes, and they're just like, "Whoa, that's so cool." +But then clinicians and the patients they see that, and they were like, "My prosthetic hand couldn't do this before." And so then they contact us, and we're like, "How can we get your hand?" And then we'll either put them in contact with a clinician, or we'll work with one of the clinicians that they are already working with then go through their insurance that way. And so it's just been a really exciting and fun way to generate, like, expand our market and generate sales that we didn't necessarily think was going to be a viable way from the start. +VICTORIA: Right. I totally get it. I mean, I want one, and both my hands still work. +MID-ROLL AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator, that's tbot.io/incubator. +VICTORIA: Have you ever seen someone rock climb with the prosthetic hand? +DR. AADEEL: Not yet, but that is something that is definitely on our docket. +VICTORIA: Okay, well, we need to do it. Since we're both in San Diego, I can help you. [laughs] +DR. AADEEL: Sweet. I love it. [laughs] +VICTORIA: Yeah, we can figure that out because there are, especially in the climbing gyms, there are usually groups that come in and climb with prosthetic limbs on a regular basis since it's a kind of a surprisingly accessible sport. [laughs] +DR. AADEEL: So one of the great things about being here in San Diego is that there's like a ton of incredible resources for building prosthetics and then for users of them as well. So the Challenged Athletes Foundation is located 10 minutes from us. So we're located in Scripps Ranch. And the Challenged Athletes Foundation they're like over in the Sorrento Valley area. They hold the para-triathlon every year. +And so we just went to their event a couple of months ago, and it was absolutely incredible. And so we've got like a five-year goal of making an ability leg. So we have The Ability Hand right now. So the ability leg, we want to actually be able to perform a triathlon, so run, bike, and swim with the leg. And I think that would be a phenomenal goal. And all the pieces are here in San Diego. +We got the military hospital, and so we've got the veteran population. We've got the Challenged Athletes Foundation. We've got UCSD, and they're incredible at engineering. We've got two prosthetic schools right around LA, so Loma Linda University in California State University, Dominguez Hills. And there are only 11 in the entire nation, and two of them just happen to be right around here. +It's a med tech hub. There's like a bunch of med tech companies and both startups and huge ones like NuVasive that are in the area. And it's a huge engineering place, too, with Qualcomm. And so we want to bring all of those resources together. And it's my goal to turn San Diego into the bionics capital of the world, where people from all over the world are coming here to have the most advanced devices ever created. +VICTORIA: Oh, I love that idea. And you just moved to San Diego a few years ago. Is that right? +DR. AADEEL: Actually, six months ago, so it's very new for us. +VICTORIA: Six months? [laughter] Well, you sound like me when I moved to San Diego. I was like; it's great here. [laughter] +DR. AADEEL: Well, I hope you still find it to be great. [laughs] +VICTORIA: Yeah, I love it. I've been here for two years now. And, yes, there's more to it than just the weather being good all the time. [laughter] There's a lot here. +DR. AADEEL: [laughs] It doesn't hurt, though, right? +VICTORIA: Yeah. And, I mean, I love that I can still do my networking events outdoors all year long, so going on hikes and stuff versus being indoors in the winter. But I find it fascinating that San Diego has just so much biotech all around, and I will happily support how I can [laughs] turning it into a bionic limb capital. I think that's a great idea. +Well, so I wanted to get back...we're talking about the future right now. I wanted to ask about building your team. So you started the company almost seven years ago, and you've grown the team a lot since then. Did you have any essential principles or values that you started with when you were building out your team? +DR. AADEEL: Yeah. So when we were first hiring, I was still a Ph.D. student when I started the company. Our first employee was actually my undergraduate student. He's currently our Director of Engineering, Jesse Cornman. And we specifically were recruiting people that did stuff outside of the lab, so the electrical engineers and the mechanical engineers that we initially hired. We wanted to make sure that it wasn't just like the university projects that they were working on. +And we would find a lot of our early people from like car team so like this was like building like a solar car, so Illini Solar Car was one of our places where we'd get a lot of our early employees as well as the electrical vehicle concept team and design, build, fly, and these student organizations where they had like competitions, and they had to build real, tangible things to compete in with. And the thing is that those are the people who do this stuff for fun, and you learn the most when you're having fun doing this stuff. And so we would always look for that stuff in particular. +And there were some litmus tests that we'd have to be able to weed out very quickly what people know what. And so for electrical engineers, we would always ask if they know surface mount soldering because it's not like your typical soldering on a perf board or even like using a breadboard. It's like you have a circuit board, and you have to solder these very small components on there. And if you know how to solder those small components, you typically know how to code them as well. So they have some embedded systems background as well and some PCB design experience as well. And so that was like a quick litmus test that we use for the electrical engineers. +For the mechanical engineers, it was typically if they knew how to do surface modeling. And so we would ask them, "How would you make the palm of a hand where you got these complex structures and these complex surfaces that have different geometries and different curvature?" And if they were able to do a surface modeling, then we knew that they'd be able to CAD that up pretty quickly. They probably have some sort of 3D printing experience from that as well, and that they can just rapidly iterate and prototype on the devices. +And so that worked really, really well. And so we were able to get a lot of bright engineers who early on in the company...and many who were student interns at the time that eventually even went on to Microsoft and Google or some of the students went to MIT and places like that. And we were very fortunate to be in the University of Illinois at Urbana-Champaign's ecosystem, where it was just one of the best engineering schools in the world to develop this kind of stuff. +VICTORIA: That's great. So you had really specific skills that you needed. [laughs] And you kind of knew the type of work or an experience that led to that. As you've expanded your team and you're building a culture of collaboration, how do you set expectations with how you all work together? +DR. AADEEL: As a startup, we all wear many, many hats. So my job, I feel like, is to fill in all the gaps. And so some days, I might be doing marketing; some days, I might be visiting a clinic and doing sales. Other times I'm working with the engineering team to make sure that we're on track over there. And it's like all this stuff in between. +And so being able to work cohesively like that and put on those many hats so that you know every part of the process from the marketing and sales sides but also the engineering and operations side, I think that's really allowed us to get to the point where we have by doing all these different functions together. +VICTORIA: That makes sense. So you are all located in San Diego now, so you have to be in person to work on robot hands? +DR. AADEEL: Yeah, we found that it was much easier to build a physical object in person than it was to do things remotely. At the beginning of COVID, we actually did try to, like, you know, we moved 3D printers out into people's houses and the manufacturing equipment. And then I remember just to put together a power switch that usually took like one hour to do in the lab. It took us a day and a half because one person had the circuit board, the other person had the enclosure, the other person had the thing to program it. And then each thing depended on each other. So you had to keep carting that small piece back and forth between houses, and it was just a nightmare to do that. +And so after a couple of months, we ended up moving back into the offices and manufacturing there with staggered work hours or whatever. And at that point, we were just like, okay, this is much more efficient when we're all in person. And honestly, a lot of our best ideas have come from just me sitting here and then just walking over to one of the engineers and being like, "Hey, what do you think of this idea?" And it's a lot harder to do when you're all remote, right? +VICTORIA: That makes sense. Yeah, just the need to physically put pieces together [laughs] as a group makes it hard to be fully remote. And you get a lot of those ideas flowing when you're in person. What is on the horizon for you? What are you most excited about in your upcoming feature set? +DR. AADEEL: Like I said, one of the reasons why we moved here was to work with the military hospital, and so some of the work that we're doing with them is particularly exciting. The way you typically wear these prosthetic devices...so you'll have muscle sensors that are embedded in a...it's like a shell that goes around your residual limb. We call it the socket. Think about it as like a shoe for your residual limb. +And the thing is, as you're wearing this throughout the day, it starts to get sweaty. It starts to get uncomfortable. Things shift around. Your signals don't control the hand as well because of all these changes and everything. And with the military hospital, we're working on something called osseointegration. So instead of having this socket that's molded to your residual limb that you shove your arm into, you have a titanium implant that goes inside your bones and then comes out of your body, and then you directly attach the hand to your bones like a limb naturally should be. +And then, on top of that, instead of using these muscles sensors on the outside of your body, we're actually working on implanted electrodes with some of our collaborators. For example, at University of Chicago, they're doing brain implants to control prosthetic limbs. And a company in Dallas called Nerves Incorporated that's working with the University of Minnesota and UT Southwestern; they're doing nerve implants in your forearm and in your upper arm to control prosthetic limbs. +And with those, you get much more fine control, so it's not like you're just controlling different grips, like preset grips in the hand, but you're actually doing individual finger control. And then, when you touch the finger, it's actually stimulating your nerves to make it feel like it's coming from your hand that you no longer have anymore. And this is where we're heading with all of this stuff in the future. +And so we built The Ability Hand to work with clinically available systems now, like sockets, and muscle sensors, and vibration motors that are all outside of the body. But then also, when these future technologies come up that are more invasive that are directly implanted on your nerves as well as into your bones as well, we're really excited about those prospects coming out in the horizon. +VICTORIA: That's really cool. [laughs] I mean, that would be really life-changing for a lot of people, I'm sure, to have that ability to really control your fingers and get that extra comfort as well. How do you manage quality into your process, especially when you're getting invasive and putting in nerve implants? What kind of testing and other types of things do you all do? +DR. AADEEL: With The Ability Hand itself, there was actually an FDA Class I exempt device, meaning that we didn't have to go through the formal approval process that you typically do. And that was primarily because it's attached to your residual limb as opposed to going invasive. But with going invasive, with our clinical partners they're actually doing FDA clinical trials right now. And so they've gone through a lot of those processes. We're starting to enroll some of our patients who are using The Ability Hand to get these implanted electrodes. We're kind of navigating that whole process ourselves right now too. +So I think that was one of the reasons why we moved to San Diego, to work with and leverage a lot of the expertise from people who've done it already, from the med tech device companies that are big that have gone through those processes and can guide us through that process as well. So we're excited to be able to leverage those resources in order to streamline these clinical trial processes so that we can get these devices out there more quickly. +VICTORIA: That's very cool. I'm super excited to hear about that and to learn more about PSYONIC. Is there anything else you want to share with our audience today as a final takeaway? +DR. AADEEL: Absolutely. So in order to make all this stuff happen, we're actually in the middle of raising a round right now. Our biggest issue right now is actually that we've got more demand than we can produce, so we're working on scaling our manufacturing here in San Diego. So we're in the middle of an equity crowdfunding round. +And we're all about accessibility, so about making our hand accessible to as many people as possible. So we were like, why don't we make the company accessible as well? And one of the most beautiful things about doing this as an equity crowdfunding round is our patients actually have invested in the company as well. And so it's like, we're making these devices for them, and then they get to be a part of it as well. And it's just this beautiful synergy that I couldn't have asked for anything more out of a crowdfunding campaign. +And so we've raised over 750k already on StartEngine. And you can find out more and invest for as little as $250 at psyonic.io, so that's psyonic.io/invest. And the other thing I was going to mention, especially Victoria since you're in San Diego as well, is that I happily give tours to anyone who is in the area. So if anyone wants to see how we build all these bionic hands and just a cool robotics startup in general, we'd be happy to have you come visit us. +VICTORIA: That's very cool. I'll have to connect with you later and schedule a tour myself. [laughs] That's wonderful. I'm excited to hear all the things you're working on and hope to see you more in the San Diego community coming up. And we'll share links to the funding page and other information about PSYONIC in our show notes. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Mastodon at Victoria Guido. +And this podcast is brought to by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Aadeel Akhtar. + + + Dr. Aadeel Akhtar is the Founder and CEO of PSYONIC, a company whose mission is to develop advanced prostheses that are affordable for everyone.

+ +

Victoria talks to Dr. Akhtar about the gaps in the market he saw in current prosthetic ability, advancements PSYONIC has been able to make since commercialization, and essential principles and values that were important to him when building out the PSYONIC team.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host Victoria Guido. And with me today is Dr. Aadeel Akhtar, Founder and CEO of PSYONIC, a company whose mission is to develop advanced prostheses that are affordable for everyone. Aadeel, thank you for joining me.

+ +

DR. AADEEL: Thank you for having me, Victoria. This is fun.

+ +

VICTORIA: Yes, I'm excited to meet you. So I actually ran into you earlier this week at a San Diego tech meetup. And I'm curious just to hear more about your company PSYONIC.

+ +

DR. AADEEL: So, as you mentioned, we develop advanced bionic limbs that are affordable and accessible. And this is actually something I've wanted to do my whole life ever since I was seven years old. My parents are from Pakistan. I was born in the Chicago suburbs. But I was visiting, and that was the first time I met someone missing a limb; and she was my age missing her right leg, using a tree branch as a crutch, living in poverty. And that's kind of what inspired me to go into this field.

+ +

VICTORIA: Wonderful. And maybe you can start with what gaps in the market did you see in current prosthetic ability?

+ +

DR. AADEEL: When we first started making these prosthetic devices, we were 3D printing them. And we thought that the biggest issue with prosthetic devices was that they were way too expensive and saw that with 3D printing, we'd be able to reduce the prices on them. And that's true; it was actually one of the biggest issues, but it wasn't the biggest issue.

+ +

After talking with hundreds of patients and clinicians, the number one thing that we found that patients and clinicians would raise issue with was that their super expensive bionic hands were breaking all the time. And these were made with injection molded plastics and custom-machined steel. And they weren't doing anything crazy with it. They would accidentally hit the hand against the side of a table, but because they were made out of rigid components, they would end up snapping up those joints.

+ +

And a natural hand, for example, if you bang a natural hand against a table or a rigid object, then it flexes out of the way. It has compliance in it, and that's why it's able to survive those types of hits and impacts a little bit more. It forced us to think outside the box of how can we still leverage the low-cost manufacturing of 3D printing but make this hand more robust than anything out there? And that's when I started looking into soft robotics.

+ +

And with soft robotics, instead of making rigid links in your robot, so instead of having rigid joints and components, you'd use soft materials like silicone that are more akin to your skin and your own biological tissues that are more flexible and compliant. So we started making the fingers out of rubber and silicone.

+ +

And now we've been able to do things like punch through flaming boards, and I dropped it from the roof of my house 30 feet up in the air, and it survived. We put it in a dryer for 10 minutes, and it survived tumbling around in a dryer. I've arm wrestled against the para-triathlete national champion and lost. So this thing was built to survive a lot more than just hitting your hand against the side of a table.

+ +

VICTORIA: Wow, that sounds incredible. And I love that you started with a premise, and then you got feedback from your users and found a completely different problem, even though that same problem still existed [laughs] about the low cost.

+ +

DR. AADEEL: Absolutely.

+ +

VICTORIA: Wow. So taking it back a little bit more to the beginning, so you knew you always wanted to do prosthetics since you grew up in Pakistan and saw people without their limbs. Take me a little bit more from the beginning of the journey. When did you decide to start the company officially?

+ +

DR. AADEEL: And just to clarify, I was just visiting Pakistan for the summer, but I grew up and was raised here in the U.S. So I went to Loyola University Chicago for undergrad, and I got a bachelor's degree in biology there, followed by a master's in computer science. And the original plan was to actually become an MD working with patients with amputations and developing prosthetics for them.

+ +

But while I was an undergraduate student at Loyola, I took my first computer science class, and I absolutely loved it. I loved everything about coding, and programming, and engineering. And I realized that if I became a straight-up MD, I wouldn't get to do any of the cool things that I was learning in my computer science classes. And I wanted to figure out a way to combine my passions in engineering and computer science with clinical medicine and prosthetics.

+ +

And right down the street at a hospital formerly known as The Rehabilitation Institute of Chicago...it's now the Shirley Ryan AbilityLab. It's the number-one rehabilitation hospital in the U.S. for the last 31 years. They made these huge breakthroughs in mind control bionic limbs where they were doing a surgery where they would reroute your nerves to other muscles that you already have on your body. And then, when you try to imagine bending your phantom elbow or making a phantom fist, your chest muscles would contract. And then you could use those signals to then control this robotic limb that was designed by Dean Kamen that was sponsored by DARPA and cost hundreds of thousands of dollars. That was just absolutely incredible.

+ +

And it was this perfect mixture of engineering and clinical medicine, and it was exactly what I wanted to get into. But, as you'd mentioned, we're all about accessibility, and a $100,000 cost hand would not cut it. And so I ended up finishing a master's in computer science. I taught at Loyola for a couple of years and then went to the University of Illinois at Urbana-Champaign, where I got another master's in electrical and computer engineering, a Ph.D. in neuroscience. And then I finished the first year of medical school before I left to run PSYONIC because it is a lot more fun building bionic limbs [laughs] than finishing medical school.

+ +

And while I was a graduate student, we started 3D printing our own prosthetic hands, and we got the chance in 2014 to go down to Quito, Ecuador, where we were working with a nonprofit organization called The Range of Motion Project. And their whole mission is to provide prosthetics to those who can't afford them in the U.S., Guatemala, and Ecuador.

+ +

And we went down there, and we were working with a patient who had lost his left hand 35 years prior due to machine gunfire from a helicopter; he was in the Ecuadorian Army. And there was a border war between Ecuador and Peru. And Juan, our patient, in front of international news stations, said that he felt as though a part of him had come back. And that was because he actually made a pinch with his left hand for the first time in 35 years.

+ +

And you have to imagine the hand at that time was three times the size of an average natural hand, adult human hand. Had wires going everywhere, breadboards, power supplies, the walls, you name it. And despite that, he said that a part of him had come back. And he actually forgot how to make a pinch with his left hand, and we had to retrain his brain by placing a mirror in front of his left side reflecting his right hand, tricking his brain into thinking that his left hand was actually there.

+ +

And he would make a pinch with both sides, and it would reactivate the muscles in his forearm on his left side. And when he said that, that's when I realized that if I stay in academia, then this just ends up as a journal paper. And if we want everyone to feel the same way that Juan did, we had to commercialize the technology. And so that's when PSYONIC was born.

+ +

VICTORIA: I love that you're working on that as someone who's from Washington, D.C., and has done a lot of work in veterans and homeless organizations and seen how life-changing getting access to limbs and regaining capability can be for people.

+ +

DR. AADEEL: Absolutely. In fact, our first user in the U.S. is a U.S. Army sergeant who lost his hand in Iraq in 2005 due to roadside bombs, Sergeant Garrett Anderson. He used a hook on a daily basis, and with our hand, he's actually able to feel his daughter's hand, which is something that he wasn't able to do with any other prosthesis. And for him to tell us that that is why we do what we do.

+ +

VICTORIA: Right. And I saw on your website that you have several patents and have talked about the advances you've been able to make in what I'm going to call the sensorimotor bionic limbs. Can you tell me a little bit more about some of the advancements you've been able to make since you decided to commercialize this?

+ +

DR. AADEEL: The first thing that usually users notice is that, and clinicians notice as well, is that the hand is the fastest bionic hand in the world. So the fingers close in about 200 milliseconds. And to put that into context, we can wink our eyes in about 300 milliseconds. So it's technically faster than the blink of an eye, which is kind of a cool statistic there. So it's super fast. And the fingers are super resistant to impact, so they're very durable. And so we've got a couple of patents on both of those items in particular.

+ +

And then there's the touch feedback aspect. So this is the only hand on the market that gives users touch feedback. And so the methods that we have to mold the fingers to enable that sensory feedback that is what our third patent is on for the hand, and it just looks really cool. It's got like this black carbon fiber on it that just looks really futuristic and bionic.

+ +

And it just gives users the confidence that this isn't something to be pitied; this is something that's really cool. And especially for our war heroes, that's something to be celebrated that I lost my hand for our country, and now I've got this really cool one that can do all of the things that my hand used to do.

+ +

VICTORIA: And I also saw that it's reimbursable by Medicare in the U.S. And I was curious if you had any lessons learned from that process for getting eligible for that.

+ +

DR. AADEEL: Yeah. And that was part of the goal from the very beginning. After we did our customer discovery process, where we figured out what the pain points are and found out that durability was one of the biggest issues, obviously, one of the other issues was the really expensive price of the other hands, and typically what we call a multi-articulated hand, so that's one where each one of the fingers move individually.

+ +

Those are only covered by the VA, so if you're in the military or workman's comp so if you had a workplace accident. And that only accounted for about 10% of the U.S. market. And what the clinicians kept telling us over and over again was that if you can get the hand covered by Medicare, then usually all the other insurance companies will follow suit, like your Blue Cross Blue Shield, your Aetna, your Kaiser, et cetera.

+ +

So that was our design goal from the beginning. So how can we hit a price point that Medicare would cover but also make this fully featured that no other hand can do any of these other things? What it primarily came down to was hitting that price point. And as long as we hit that price point, then Medicare was going to be fine with it. So we invented a lot of the manufacturing methods that we use in-house to make the hand in particular.

+ +

So we do all the silicone molding. We do all the carbon fiber work. We do all the fabric work. We do all the assembly of it in-house in our warehouse here in San Diego. And by being so vertically integrated, we're able to then iterate very quickly and make these innovations happen at a much more rapid scale so that we can get them out there faster and then help more people who need it.

+ +

VICTORIA: So you've really grown tremendously from when you first had the project, and now you have a team here in San Diego. Do you have any lessons learned for enabling your team to drive faster in that innovation?

+ +

DR. AADEEL: Yeah, the biggest thing that I feel like a lot of things come down to is just having grit. So especially with a startup, it's always going to be a roller coaster ride. And for us, I think one of the big motivating factors for us is the patients themselves when they get to do these things that they weren't able to do before.

+ +

So another one of our first patients, Tina, had just become a grandmother, and she was able to feed her granddaughter for the first time because she was able to hold the bottle with her bionic hand, The Ability Hand, and then hold her granddaughter with her natural hand and then feed her using The Ability Hand. It's, like I said, moments like that is why we do what we're doing. It gives us that motivation to work those long hours, make those deadlines so that we can help as many people as possible.

+ +

VICTORIA: Right. So you have that motivating power behind your idea, which makes a lot of sense. What else in your customer discovery sprint was surprising to you as you moved through that process?

+ +

DR. AADEEL: So there was definitely the robustness that was surprising. There was the cost that wasn't necessarily the highest priority thing, which we thought would be the highest priority. And the speed and just having to rely on visual feedback, you have to kind of look at the hand as you're doing the task that you're doing, but you have to look at it very intently. So that takes a lot of cognitive load. You have to pay attention very specifically to am I doing the right movement with my hand? In ways that you wouldn't necessarily have to do with a natural hand.

+ +

And by making the hand move so responsive as it is and move so quickly, in addition to having that touch feedback, that reduces, or at least we believe it'll reduce a lot of that cognitive load for our patients so that they don't have to be constantly monitoring exactly what the hand is doing in order to do a lot of the tasks or the activities of daily living that they're doing on a day to day basis. The whole customer discovery process drove what features we were going to focus on in actually making this hand a reality.

+ +

VICTORIA: Yeah, that makes sense. And I love hearing about what came up that surprised people. And I appreciate your commitment to that process to really drive your business idea and to solve this problem that happens to so many people in the United States. Well, how widespread is this issue? And, of course, I'm sure you're targeting more than just the United States with rollout, but...

+ +

DR. AADEEL: So, globally, there are over 10 million people with hand amputations, and 80% of them actually live in developing nations, and less than 3% have access to affordable rehabilitative care. So it's a huge need worldwide, and we want to make sure that everyone has access to the best available prosthetic devices.

+ +

VICTORIA: That makes sense. So I guess commercializing this product leads to more room, more availability across for everyone.

+ +

DR. AADEEL: Absolutely. And interesting thing about that, too, is that as we were developing these, the hand in particular, we've optimized it for humans to do human tasks. And we have a programming interface that we put on it that allows researchers to control each one of the fingers like you control the speed, the position, and the force from each one of those fingers as well as you can stream all of the touch sensors like over Bluetooth or over a USB connection, and then also the location of each one of those fingers as well.

+ +

A lot of robotics researchers who are building humanoid robots and robot arms to do other tasks like manufacturing and robotic surgery and things like that have been purchasing our hand too. So notably, for example, NASA and Meta, so Facebook Meta, have purchased our hands, and NASA is putting it on a humanoid astronaut robot, which hopefully will eventually go into space. And then, on Earth, they'd be able to control it and then manipulate objects in space.

+ +

And it's opened up an entirely new market, but the critical thing here is that it's the exact same hand that the humans are getting that the robots are getting. And what this allows us to do is just expand our volume of production and our sales so that we can actually further drive down the costs and the pricing for the human side of things as well.

+ +

So if we're talking about places like India, or Pakistan, or Guatemala, or Ecuador where there are no government incentives in place to reimburse at a rate that they might in the U.S., then we can actually get the price point to one that's actually affordable in those areas as well. And I'm really excited about those prospects.

+ +

VICTORIA: That's so cool that future robot astronauts will be financing people who have no ability [laughs] to go into space or anything like that. That's a cool business idea. I wonder, when did that happen for you, or what was that like when you realized that there was this other potential untapped market for robotic limbs?

+ +

DR. AADEEL: It's interesting. It was always in the back of our minds because, as I was a Ph.D. student, I was in the Ph.D. group that focused on robotics, in particular more so than prosthetics. And I was the first one in the group to actually kind of have the prosthetic spin on things. And so I had an idea of where the market was for the robotic side of things. And I had some connections as well.

+ +

And so I was actually giving a talk at Georgia Tech early last year. The Director of the Georgia Tech Robotics Institute, Dr. Seth Hutchinson, he was telling me that...he was like, "You should go to the big robotics conference, ICRA, because people are going to be like...absolutely love this product for their robots." And we were just like, huh, we never considered that.

+ +

And so we decided to go, and it was just absolutely nuts. We've had researchers from all over the world being like, "How can I get this hand?" And compared to a lot of the robotic hands that are out there, even on the robotic side, this is a much lower price point than what they've been dealing with. And by solving a lot of the problems on the human side, like durability, and sensory feedback, and dexterity, and the pricing, it actually solved a lot of the problems on the robotic side as well. So I was just like...after we had gone to that conference, we realized that, yeah, we can actually make this work as well.

+ +

VICTORIA: That's really cool. And it sounds like tapping into this robotics market and networking really worked for you. What else about your market research or strategy seem to be effective in your business growth?

+ +

DR. AADEEL: This is interesting as well. So half of our sales actually come from social media, which for a medical device company is usually unheard of. [laughs] Because usually the model is, for medical devices, where you have a group of sales reps located across the regions that you're selling and so across the U.S. And they would visit each one of the clinics, and then they would work with the clinicians directly in getting these on the patients. That usually accounts for like 99% of sales. And so for us, for half of them to come from social media, it was a goal that we had set out to, but it was also surprising that that accounted for so much of our volumes and our revenue.

+ +

The way we set it up was that we wanted to make videos of our hand that highlighted things that our hand could do that were novel and unique. And so, for example, we wanted to highlight the durability of the hand as well as the dexterity and the touch feedback. And so some of the first videos that we made were like arm wrestling against a bionic hand. And what's cool about that is that the general public just found that very interesting in general.

+ +

But also, when a clinician and a patient sees that, wow, this hand can actually withstand the forces of an actual arm wrestling match, then they're also just as impressed. And the same thing with punching through three wooden boards that we set on fire; if it can handle that, then it can handle activities of daily living. General public seizes, and they're just like, "Whoa, that's so cool."

+ +

But then clinicians and the patients they see that, and they were like, "My prosthetic hand couldn't do this before." And so then they contact us, and we're like, "How can we get your hand?" And then we'll either put them in contact with a clinician, or we'll work with one of the clinicians that they are already working with then go through their insurance that way. And so it's just been a really exciting and fun way to generate, like, expand our market and generate sales that we didn't necessarily think was going to be a viable way from the start.

+ +

VICTORIA: Right. I totally get it. I mean, I want one, and both my hands still work.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator, that's tbot.io/incubator.

+ +

VICTORIA: Have you ever seen someone rock climb with the prosthetic hand?

+ +

DR. AADEEL: Not yet, but that is something that is definitely on our docket.

+ +

VICTORIA: Okay, well, we need to do it. Since we're both in San Diego, I can help you. [laughs]

+ +

DR. AADEEL: Sweet. I love it. [laughs]

+ +

VICTORIA: Yeah, we can figure that out because there are, especially in the climbing gyms, there are usually groups that come in and climb with prosthetic limbs on a regular basis since it's a kind of a surprisingly accessible sport. [laughs]

+ +

DR. AADEEL: So one of the great things about being here in San Diego is that there's like a ton of incredible resources for building prosthetics and then for users of them as well. So the Challenged Athletes Foundation is located 10 minutes from us. So we're located in Scripps Ranch. And the Challenged Athletes Foundation they're like over in the Sorrento Valley area. They hold the para-triathlon every year.

+ +

And so we just went to their event a couple of months ago, and it was absolutely incredible. And so we've got like a five-year goal of making an ability leg. So we have The Ability Hand right now. So the ability leg, we want to actually be able to perform a triathlon, so run, bike, and swim with the leg. And I think that would be a phenomenal goal. And all the pieces are here in San Diego.

+ +

We got the military hospital, and so we've got the veteran population. We've got the Challenged Athletes Foundation. We've got UCSD, and they're incredible at engineering. We've got two prosthetic schools right around LA, so Loma Linda University in California State University, Dominguez Hills. And there are only 11 in the entire nation, and two of them just happen to be right around here.

+ +

It's a med tech hub. There's like a bunch of med tech companies and both startups and huge ones like NuVasive that are in the area. And it's a huge engineering place, too, with Qualcomm. And so we want to bring all of those resources together. And it's my goal to turn San Diego into the bionics capital of the world, where people from all over the world are coming here to have the most advanced devices ever created.

+ +

VICTORIA: Oh, I love that idea. And you just moved to San Diego a few years ago. Is that right?

+ +

DR. AADEEL: Actually, six months ago, so it's very new for us.

+ +

VICTORIA: Six months? [laughter] Well, you sound like me when I moved to San Diego. I was like; it's great here. [laughter]

+ +

DR. AADEEL: Well, I hope you still find it to be great. [laughs]

+ +

VICTORIA: Yeah, I love it. I've been here for two years now. And, yes, there's more to it than just the weather being good all the time. [laughter] There's a lot here.

+ +

DR. AADEEL: [laughs] It doesn't hurt, though, right?

+ +

VICTORIA: Yeah. And, I mean, I love that I can still do my networking events outdoors all year long, so going on hikes and stuff versus being indoors in the winter. But I find it fascinating that San Diego has just so much biotech all around, and I will happily support how I can [laughs] turning it into a bionic limb capital. I think that's a great idea.

+ +

Well, so I wanted to get back...we're talking about the future right now. I wanted to ask about building your team. So you started the company almost seven years ago, and you've grown the team a lot since then. Did you have any essential principles or values that you started with when you were building out your team?

+ +

DR. AADEEL: Yeah. So when we were first hiring, I was still a Ph.D. student when I started the company. Our first employee was actually my undergraduate student. He's currently our Director of Engineering, Jesse Cornman. And we specifically were recruiting people that did stuff outside of the lab, so the electrical engineers and the mechanical engineers that we initially hired. We wanted to make sure that it wasn't just like the university projects that they were working on.

+ +

And we would find a lot of our early people from like car team so like this was like building like a solar car, so Illini Solar Car was one of our places where we'd get a lot of our early employees as well as the electrical vehicle concept team and design, build, fly, and these student organizations where they had like competitions, and they had to build real, tangible things to compete in with. And the thing is that those are the people who do this stuff for fun, and you learn the most when you're having fun doing this stuff. And so we would always look for that stuff in particular.

+ +

And there were some litmus tests that we'd have to be able to weed out very quickly what people know what. And so for electrical engineers, we would always ask if they know surface mount soldering because it's not like your typical soldering on a perf board or even like using a breadboard. It's like you have a circuit board, and you have to solder these very small components on there. And if you know how to solder those small components, you typically know how to code them as well. So they have some embedded systems background as well and some PCB design experience as well. And so that was like a quick litmus test that we use for the electrical engineers.

+ +

For the mechanical engineers, it was typically if they knew how to do surface modeling. And so we would ask them, "How would you make the palm of a hand where you got these complex structures and these complex surfaces that have different geometries and different curvature?" And if they were able to do a surface modeling, then we knew that they'd be able to CAD that up pretty quickly. They probably have some sort of 3D printing experience from that as well, and that they can just rapidly iterate and prototype on the devices.

+ +

And so that worked really, really well. And so we were able to get a lot of bright engineers who early on in the company...and many who were student interns at the time that eventually even went on to Microsoft and Google or some of the students went to MIT and places like that. And we were very fortunate to be in the University of Illinois at Urbana-Champaign's ecosystem, where it was just one of the best engineering schools in the world to develop this kind of stuff.

+ +

VICTORIA: That's great. So you had really specific skills that you needed. [laughs] And you kind of knew the type of work or an experience that led to that. As you've expanded your team and you're building a culture of collaboration, how do you set expectations with how you all work together?

+ +

DR. AADEEL: As a startup, we all wear many, many hats. So my job, I feel like, is to fill in all the gaps. And so some days, I might be doing marketing; some days, I might be visiting a clinic and doing sales. Other times I'm working with the engineering team to make sure that we're on track over there. And it's like all this stuff in between.

+ +

And so being able to work cohesively like that and put on those many hats so that you know every part of the process from the marketing and sales sides but also the engineering and operations side, I think that's really allowed us to get to the point where we have by doing all these different functions together.

+ +

VICTORIA: That makes sense. So you are all located in San Diego now, so you have to be in person to work on robot hands?

+ +

DR. AADEEL: Yeah, we found that it was much easier to build a physical object in person than it was to do things remotely. At the beginning of COVID, we actually did try to, like, you know, we moved 3D printers out into people's houses and the manufacturing equipment. And then I remember just to put together a power switch that usually took like one hour to do in the lab. It took us a day and a half because one person had the circuit board, the other person had the enclosure, the other person had the thing to program it. And then each thing depended on each other. So you had to keep carting that small piece back and forth between houses, and it was just a nightmare to do that.

+ +

And so after a couple of months, we ended up moving back into the offices and manufacturing there with staggered work hours or whatever. And at that point, we were just like, okay, this is much more efficient when we're all in person. And honestly, a lot of our best ideas have come from just me sitting here and then just walking over to one of the engineers and being like, "Hey, what do you think of this idea?" And it's a lot harder to do when you're all remote, right?

+ +

VICTORIA: That makes sense. Yeah, just the need to physically put pieces together [laughs] as a group makes it hard to be fully remote. And you get a lot of those ideas flowing when you're in person. What is on the horizon for you? What are you most excited about in your upcoming feature set?

+ +

DR. AADEEL: Like I said, one of the reasons why we moved here was to work with the military hospital, and so some of the work that we're doing with them is particularly exciting. The way you typically wear these prosthetic devices...so you'll have muscle sensors that are embedded in a...it's like a shell that goes around your residual limb. We call it the socket. Think about it as like a shoe for your residual limb.

+ +

And the thing is, as you're wearing this throughout the day, it starts to get sweaty. It starts to get uncomfortable. Things shift around. Your signals don't control the hand as well because of all these changes and everything. And with the military hospital, we're working on something called osseointegration. So instead of having this socket that's molded to your residual limb that you shove your arm into, you have a titanium implant that goes inside your bones and then comes out of your body, and then you directly attach the hand to your bones like a limb naturally should be.

+ +

And then, on top of that, instead of using these muscles sensors on the outside of your body, we're actually working on implanted electrodes with some of our collaborators. For example, at University of Chicago, they're doing brain implants to control prosthetic limbs. And a company in Dallas called Nerves Incorporated that's working with the University of Minnesota and UT Southwestern; they're doing nerve implants in your forearm and in your upper arm to control prosthetic limbs.

+ +

And with those, you get much more fine control, so it's not like you're just controlling different grips, like preset grips in the hand, but you're actually doing individual finger control. And then, when you touch the finger, it's actually stimulating your nerves to make it feel like it's coming from your hand that you no longer have anymore. And this is where we're heading with all of this stuff in the future.

+ +

And so we built The Ability Hand to work with clinically available systems now, like sockets, and muscle sensors, and vibration motors that are all outside of the body. But then also, when these future technologies come up that are more invasive that are directly implanted on your nerves as well as into your bones as well, we're really excited about those prospects coming out in the horizon.

+ +

VICTORIA: That's really cool. [laughs] I mean, that would be really life-changing for a lot of people, I'm sure, to have that ability to really control your fingers and get that extra comfort as well. How do you manage quality into your process, especially when you're getting invasive and putting in nerve implants? What kind of testing and other types of things do you all do?

+ +

DR. AADEEL: With The Ability Hand itself, there was actually an FDA Class I exempt device, meaning that we didn't have to go through the formal approval process that you typically do. And that was primarily because it's attached to your residual limb as opposed to going invasive. But with going invasive, with our clinical partners they're actually doing FDA clinical trials right now. And so they've gone through a lot of those processes. We're starting to enroll some of our patients who are using The Ability Hand to get these implanted electrodes. We're kind of navigating that whole process ourselves right now too.

+ +

So I think that was one of the reasons why we moved to San Diego, to work with and leverage a lot of the expertise from people who've done it already, from the med tech device companies that are big that have gone through those processes and can guide us through that process as well. So we're excited to be able to leverage those resources in order to streamline these clinical trial processes so that we can get these devices out there more quickly.

+ +

VICTORIA: That's very cool. I'm super excited to hear about that and to learn more about PSYONIC. Is there anything else you want to share with our audience today as a final takeaway?

+ +

DR. AADEEL: Absolutely. So in order to make all this stuff happen, we're actually in the middle of raising a round right now. Our biggest issue right now is actually that we've got more demand than we can produce, so we're working on scaling our manufacturing here in San Diego. So we're in the middle of an equity crowdfunding round.

+ +

And we're all about accessibility, so about making our hand accessible to as many people as possible. So we were like, why don't we make the company accessible as well? And one of the most beautiful things about doing this as an equity crowdfunding round is our patients actually have invested in the company as well. And so it's like, we're making these devices for them, and then they get to be a part of it as well. And it's just this beautiful synergy that I couldn't have asked for anything more out of a crowdfunding campaign.

+ +

And so we've raised over 750k already on StartEngine. And you can find out more and invest for as little as $250 at psyonic.io, so that's psyonic.io/invest. And the other thing I was going to mention, especially Victoria since you're in San Diego as well, is that I happily give tours to anyone who is in the area. So if anyone wants to see how we build all these bionic hands and just a cool robotics startup in general, we'd be happy to have you come visit us.

+ +

VICTORIA: That's very cool. I'll have to connect with you later and schedule a tour myself. [laughs] That's wonderful. I'm excited to hear all the things you're working on and hope to see you more in the San Diego community coming up. And we'll share links to the funding page and other information about PSYONIC in our show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Mastodon at Victoria Guido.

+ +

And this podcast is brought to by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Aadeel Akhtar.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dr. Aadeel Akhtar is the Founder and CEO of PSYONIC, a company whose mission is to develop advanced prostheses that are affordable for everyone.

+ +

Victoria talks to Dr. Akhtar about the gaps in the market he saw in current prosthetic ability, advancements PSYONIC has been able to make since commercialization, and essential principles and values that were important to him when building out the PSYONIC team.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host Victoria Guido. And with me today is Dr. Aadeel Akhtar, Founder and CEO of PSYONIC, a company whose mission is to develop advanced prostheses that are affordable for everyone. Aadeel, thank you for joining me.

+ +

DR. AADEEL: Thank you for having me, Victoria. This is fun.

+ +

VICTORIA: Yes, I'm excited to meet you. So I actually ran into you earlier this week at a San Diego tech meetup. And I'm curious just to hear more about your company PSYONIC.

+ +

DR. AADEEL: So, as you mentioned, we develop advanced bionic limbs that are affordable and accessible. And this is actually something I've wanted to do my whole life ever since I was seven years old. My parents are from Pakistan. I was born in the Chicago suburbs. But I was visiting, and that was the first time I met someone missing a limb; and she was my age missing her right leg, using a tree branch as a crutch, living in poverty. And that's kind of what inspired me to go into this field.

+ +

VICTORIA: Wonderful. And maybe you can start with what gaps in the market did you see in current prosthetic ability?

+ +

DR. AADEEL: When we first started making these prosthetic devices, we were 3D printing them. And we thought that the biggest issue with prosthetic devices was that they were way too expensive and saw that with 3D printing, we'd be able to reduce the prices on them. And that's true; it was actually one of the biggest issues, but it wasn't the biggest issue.

+ +

After talking with hundreds of patients and clinicians, the number one thing that we found that patients and clinicians would raise issue with was that their super expensive bionic hands were breaking all the time. And these were made with injection molded plastics and custom-machined steel. And they weren't doing anything crazy with it. They would accidentally hit the hand against the side of a table, but because they were made out of rigid components, they would end up snapping up those joints.

+ +

And a natural hand, for example, if you bang a natural hand against a table or a rigid object, then it flexes out of the way. It has compliance in it, and that's why it's able to survive those types of hits and impacts a little bit more. It forced us to think outside the box of how can we still leverage the low-cost manufacturing of 3D printing but make this hand more robust than anything out there? And that's when I started looking into soft robotics.

+ +

And with soft robotics, instead of making rigid links in your robot, so instead of having rigid joints and components, you'd use soft materials like silicone that are more akin to your skin and your own biological tissues that are more flexible and compliant. So we started making the fingers out of rubber and silicone.

+ +

And now we've been able to do things like punch through flaming boards, and I dropped it from the roof of my house 30 feet up in the air, and it survived. We put it in a dryer for 10 minutes, and it survived tumbling around in a dryer. I've arm wrestled against the para-triathlete national champion and lost. So this thing was built to survive a lot more than just hitting your hand against the side of a table.

+ +

VICTORIA: Wow, that sounds incredible. And I love that you started with a premise, and then you got feedback from your users and found a completely different problem, even though that same problem still existed [laughs] about the low cost.

+ +

DR. AADEEL: Absolutely.

+ +

VICTORIA: Wow. So taking it back a little bit more to the beginning, so you knew you always wanted to do prosthetics since you grew up in Pakistan and saw people without their limbs. Take me a little bit more from the beginning of the journey. When did you decide to start the company officially?

+ +

DR. AADEEL: And just to clarify, I was just visiting Pakistan for the summer, but I grew up and was raised here in the U.S. So I went to Loyola University Chicago for undergrad, and I got a bachelor's degree in biology there, followed by a master's in computer science. And the original plan was to actually become an MD working with patients with amputations and developing prosthetics for them.

+ +

But while I was an undergraduate student at Loyola, I took my first computer science class, and I absolutely loved it. I loved everything about coding, and programming, and engineering. And I realized that if I became a straight-up MD, I wouldn't get to do any of the cool things that I was learning in my computer science classes. And I wanted to figure out a way to combine my passions in engineering and computer science with clinical medicine and prosthetics.

+ +

And right down the street at a hospital formerly known as The Rehabilitation Institute of Chicago...it's now the Shirley Ryan AbilityLab. It's the number-one rehabilitation hospital in the U.S. for the last 31 years. They made these huge breakthroughs in mind control bionic limbs where they were doing a surgery where they would reroute your nerves to other muscles that you already have on your body. And then, when you try to imagine bending your phantom elbow or making a phantom fist, your chest muscles would contract. And then you could use those signals to then control this robotic limb that was designed by Dean Kamen that was sponsored by DARPA and cost hundreds of thousands of dollars. That was just absolutely incredible.

+ +

And it was this perfect mixture of engineering and clinical medicine, and it was exactly what I wanted to get into. But, as you'd mentioned, we're all about accessibility, and a $100,000 cost hand would not cut it. And so I ended up finishing a master's in computer science. I taught at Loyola for a couple of years and then went to the University of Illinois at Urbana-Champaign, where I got another master's in electrical and computer engineering, a Ph.D. in neuroscience. And then I finished the first year of medical school before I left to run PSYONIC because it is a lot more fun building bionic limbs [laughs] than finishing medical school.

+ +

And while I was a graduate student, we started 3D printing our own prosthetic hands, and we got the chance in 2014 to go down to Quito, Ecuador, where we were working with a nonprofit organization called The Range of Motion Project. And their whole mission is to provide prosthetics to those who can't afford them in the U.S., Guatemala, and Ecuador.

+ +

And we went down there, and we were working with a patient who had lost his left hand 35 years prior due to machine gunfire from a helicopter; he was in the Ecuadorian Army. And there was a border war between Ecuador and Peru. And Juan, our patient, in front of international news stations, said that he felt as though a part of him had come back. And that was because he actually made a pinch with his left hand for the first time in 35 years.

+ +

And you have to imagine the hand at that time was three times the size of an average natural hand, adult human hand. Had wires going everywhere, breadboards, power supplies, the walls, you name it. And despite that, he said that a part of him had come back. And he actually forgot how to make a pinch with his left hand, and we had to retrain his brain by placing a mirror in front of his left side reflecting his right hand, tricking his brain into thinking that his left hand was actually there.

+ +

And he would make a pinch with both sides, and it would reactivate the muscles in his forearm on his left side. And when he said that, that's when I realized that if I stay in academia, then this just ends up as a journal paper. And if we want everyone to feel the same way that Juan did, we had to commercialize the technology. And so that's when PSYONIC was born.

+ +

VICTORIA: I love that you're working on that as someone who's from Washington, D.C., and has done a lot of work in veterans and homeless organizations and seen how life-changing getting access to limbs and regaining capability can be for people.

+ +

DR. AADEEL: Absolutely. In fact, our first user in the U.S. is a U.S. Army sergeant who lost his hand in Iraq in 2005 due to roadside bombs, Sergeant Garrett Anderson. He used a hook on a daily basis, and with our hand, he's actually able to feel his daughter's hand, which is something that he wasn't able to do with any other prosthesis. And for him to tell us that that is why we do what we do.

+ +

VICTORIA: Right. And I saw on your website that you have several patents and have talked about the advances you've been able to make in what I'm going to call the sensorimotor bionic limbs. Can you tell me a little bit more about some of the advancements you've been able to make since you decided to commercialize this?

+ +

DR. AADEEL: The first thing that usually users notice is that, and clinicians notice as well, is that the hand is the fastest bionic hand in the world. So the fingers close in about 200 milliseconds. And to put that into context, we can wink our eyes in about 300 milliseconds. So it's technically faster than the blink of an eye, which is kind of a cool statistic there. So it's super fast. And the fingers are super resistant to impact, so they're very durable. And so we've got a couple of patents on both of those items in particular.

+ +

And then there's the touch feedback aspect. So this is the only hand on the market that gives users touch feedback. And so the methods that we have to mold the fingers to enable that sensory feedback that is what our third patent is on for the hand, and it just looks really cool. It's got like this black carbon fiber on it that just looks really futuristic and bionic.

+ +

And it just gives users the confidence that this isn't something to be pitied; this is something that's really cool. And especially for our war heroes, that's something to be celebrated that I lost my hand for our country, and now I've got this really cool one that can do all of the things that my hand used to do.

+ +

VICTORIA: And I also saw that it's reimbursable by Medicare in the U.S. And I was curious if you had any lessons learned from that process for getting eligible for that.

+ +

DR. AADEEL: Yeah. And that was part of the goal from the very beginning. After we did our customer discovery process, where we figured out what the pain points are and found out that durability was one of the biggest issues, obviously, one of the other issues was the really expensive price of the other hands, and typically what we call a multi-articulated hand, so that's one where each one of the fingers move individually.

+ +

Those are only covered by the VA, so if you're in the military or workman's comp so if you had a workplace accident. And that only accounted for about 10% of the U.S. market. And what the clinicians kept telling us over and over again was that if you can get the hand covered by Medicare, then usually all the other insurance companies will follow suit, like your Blue Cross Blue Shield, your Aetna, your Kaiser, et cetera.

+ +

So that was our design goal from the beginning. So how can we hit a price point that Medicare would cover but also make this fully featured that no other hand can do any of these other things? What it primarily came down to was hitting that price point. And as long as we hit that price point, then Medicare was going to be fine with it. So we invented a lot of the manufacturing methods that we use in-house to make the hand in particular.

+ +

So we do all the silicone molding. We do all the carbon fiber work. We do all the fabric work. We do all the assembly of it in-house in our warehouse here in San Diego. And by being so vertically integrated, we're able to then iterate very quickly and make these innovations happen at a much more rapid scale so that we can get them out there faster and then help more people who need it.

+ +

VICTORIA: So you've really grown tremendously from when you first had the project, and now you have a team here in San Diego. Do you have any lessons learned for enabling your team to drive faster in that innovation?

+ +

DR. AADEEL: Yeah, the biggest thing that I feel like a lot of things come down to is just having grit. So especially with a startup, it's always going to be a roller coaster ride. And for us, I think one of the big motivating factors for us is the patients themselves when they get to do these things that they weren't able to do before.

+ +

So another one of our first patients, Tina, had just become a grandmother, and she was able to feed her granddaughter for the first time because she was able to hold the bottle with her bionic hand, The Ability Hand, and then hold her granddaughter with her natural hand and then feed her using The Ability Hand. It's, like I said, moments like that is why we do what we're doing. It gives us that motivation to work those long hours, make those deadlines so that we can help as many people as possible.

+ +

VICTORIA: Right. So you have that motivating power behind your idea, which makes a lot of sense. What else in your customer discovery sprint was surprising to you as you moved through that process?

+ +

DR. AADEEL: So there was definitely the robustness that was surprising. There was the cost that wasn't necessarily the highest priority thing, which we thought would be the highest priority. And the speed and just having to rely on visual feedback, you have to kind of look at the hand as you're doing the task that you're doing, but you have to look at it very intently. So that takes a lot of cognitive load. You have to pay attention very specifically to am I doing the right movement with my hand? In ways that you wouldn't necessarily have to do with a natural hand.

+ +

And by making the hand move so responsive as it is and move so quickly, in addition to having that touch feedback, that reduces, or at least we believe it'll reduce a lot of that cognitive load for our patients so that they don't have to be constantly monitoring exactly what the hand is doing in order to do a lot of the tasks or the activities of daily living that they're doing on a day to day basis. The whole customer discovery process drove what features we were going to focus on in actually making this hand a reality.

+ +

VICTORIA: Yeah, that makes sense. And I love hearing about what came up that surprised people. And I appreciate your commitment to that process to really drive your business idea and to solve this problem that happens to so many people in the United States. Well, how widespread is this issue? And, of course, I'm sure you're targeting more than just the United States with rollout, but...

+ +

DR. AADEEL: So, globally, there are over 10 million people with hand amputations, and 80% of them actually live in developing nations, and less than 3% have access to affordable rehabilitative care. So it's a huge need worldwide, and we want to make sure that everyone has access to the best available prosthetic devices.

+ +

VICTORIA: That makes sense. So I guess commercializing this product leads to more room, more availability across for everyone.

+ +

DR. AADEEL: Absolutely. And interesting thing about that, too, is that as we were developing these, the hand in particular, we've optimized it for humans to do human tasks. And we have a programming interface that we put on it that allows researchers to control each one of the fingers like you control the speed, the position, and the force from each one of those fingers as well as you can stream all of the touch sensors like over Bluetooth or over a USB connection, and then also the location of each one of those fingers as well.

+ +

A lot of robotics researchers who are building humanoid robots and robot arms to do other tasks like manufacturing and robotic surgery and things like that have been purchasing our hand too. So notably, for example, NASA and Meta, so Facebook Meta, have purchased our hands, and NASA is putting it on a humanoid astronaut robot, which hopefully will eventually go into space. And then, on Earth, they'd be able to control it and then manipulate objects in space.

+ +

And it's opened up an entirely new market, but the critical thing here is that it's the exact same hand that the humans are getting that the robots are getting. And what this allows us to do is just expand our volume of production and our sales so that we can actually further drive down the costs and the pricing for the human side of things as well.

+ +

So if we're talking about places like India, or Pakistan, or Guatemala, or Ecuador where there are no government incentives in place to reimburse at a rate that they might in the U.S., then we can actually get the price point to one that's actually affordable in those areas as well. And I'm really excited about those prospects.

+ +

VICTORIA: That's so cool that future robot astronauts will be financing people who have no ability [laughs] to go into space or anything like that. That's a cool business idea. I wonder, when did that happen for you, or what was that like when you realized that there was this other potential untapped market for robotic limbs?

+ +

DR. AADEEL: It's interesting. It was always in the back of our minds because, as I was a Ph.D. student, I was in the Ph.D. group that focused on robotics, in particular more so than prosthetics. And I was the first one in the group to actually kind of have the prosthetic spin on things. And so I had an idea of where the market was for the robotic side of things. And I had some connections as well.

+ +

And so I was actually giving a talk at Georgia Tech early last year. The Director of the Georgia Tech Robotics Institute, Dr. Seth Hutchinson, he was telling me that...he was like, "You should go to the big robotics conference, ICRA, because people are going to be like...absolutely love this product for their robots." And we were just like, huh, we never considered that.

+ +

And so we decided to go, and it was just absolutely nuts. We've had researchers from all over the world being like, "How can I get this hand?" And compared to a lot of the robotic hands that are out there, even on the robotic side, this is a much lower price point than what they've been dealing with. And by solving a lot of the problems on the human side, like durability, and sensory feedback, and dexterity, and the pricing, it actually solved a lot of the problems on the robotic side as well. So I was just like...after we had gone to that conference, we realized that, yeah, we can actually make this work as well.

+ +

VICTORIA: That's really cool. And it sounds like tapping into this robotics market and networking really worked for you. What else about your market research or strategy seem to be effective in your business growth?

+ +

DR. AADEEL: This is interesting as well. So half of our sales actually come from social media, which for a medical device company is usually unheard of. [laughs] Because usually the model is, for medical devices, where you have a group of sales reps located across the regions that you're selling and so across the U.S. And they would visit each one of the clinics, and then they would work with the clinicians directly in getting these on the patients. That usually accounts for like 99% of sales. And so for us, for half of them to come from social media, it was a goal that we had set out to, but it was also surprising that that accounted for so much of our volumes and our revenue.

+ +

The way we set it up was that we wanted to make videos of our hand that highlighted things that our hand could do that were novel and unique. And so, for example, we wanted to highlight the durability of the hand as well as the dexterity and the touch feedback. And so some of the first videos that we made were like arm wrestling against a bionic hand. And what's cool about that is that the general public just found that very interesting in general.

+ +

But also, when a clinician and a patient sees that, wow, this hand can actually withstand the forces of an actual arm wrestling match, then they're also just as impressed. And the same thing with punching through three wooden boards that we set on fire; if it can handle that, then it can handle activities of daily living. General public seizes, and they're just like, "Whoa, that's so cool."

+ +

But then clinicians and the patients they see that, and they were like, "My prosthetic hand couldn't do this before." And so then they contact us, and we're like, "How can we get your hand?" And then we'll either put them in contact with a clinician, or we'll work with one of the clinicians that they are already working with then go through their insurance that way. And so it's just been a really exciting and fun way to generate, like, expand our market and generate sales that we didn't necessarily think was going to be a viable way from the start.

+ +

VICTORIA: Right. I totally get it. I mean, I want one, and both my hands still work.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator, that's tbot.io/incubator.

+ +

VICTORIA: Have you ever seen someone rock climb with the prosthetic hand?

+ +

DR. AADEEL: Not yet, but that is something that is definitely on our docket.

+ +

VICTORIA: Okay, well, we need to do it. Since we're both in San Diego, I can help you. [laughs]

+ +

DR. AADEEL: Sweet. I love it. [laughs]

+ +

VICTORIA: Yeah, we can figure that out because there are, especially in the climbing gyms, there are usually groups that come in and climb with prosthetic limbs on a regular basis since it's a kind of a surprisingly accessible sport. [laughs]

+ +

DR. AADEEL: So one of the great things about being here in San Diego is that there's like a ton of incredible resources for building prosthetics and then for users of them as well. So the Challenged Athletes Foundation is located 10 minutes from us. So we're located in Scripps Ranch. And the Challenged Athletes Foundation they're like over in the Sorrento Valley area. They hold the para-triathlon every year.

+ +

And so we just went to their event a couple of months ago, and it was absolutely incredible. And so we've got like a five-year goal of making an ability leg. So we have The Ability Hand right now. So the ability leg, we want to actually be able to perform a triathlon, so run, bike, and swim with the leg. And I think that would be a phenomenal goal. And all the pieces are here in San Diego.

+ +

We got the military hospital, and so we've got the veteran population. We've got the Challenged Athletes Foundation. We've got UCSD, and they're incredible at engineering. We've got two prosthetic schools right around LA, so Loma Linda University in California State University, Dominguez Hills. And there are only 11 in the entire nation, and two of them just happen to be right around here.

+ +

It's a med tech hub. There's like a bunch of med tech companies and both startups and huge ones like NuVasive that are in the area. And it's a huge engineering place, too, with Qualcomm. And so we want to bring all of those resources together. And it's my goal to turn San Diego into the bionics capital of the world, where people from all over the world are coming here to have the most advanced devices ever created.

+ +

VICTORIA: Oh, I love that idea. And you just moved to San Diego a few years ago. Is that right?

+ +

DR. AADEEL: Actually, six months ago, so it's very new for us.

+ +

VICTORIA: Six months? [laughter] Well, you sound like me when I moved to San Diego. I was like; it's great here. [laughter]

+ +

DR. AADEEL: Well, I hope you still find it to be great. [laughs]

+ +

VICTORIA: Yeah, I love it. I've been here for two years now. And, yes, there's more to it than just the weather being good all the time. [laughter] There's a lot here.

+ +

DR. AADEEL: [laughs] It doesn't hurt, though, right?

+ +

VICTORIA: Yeah. And, I mean, I love that I can still do my networking events outdoors all year long, so going on hikes and stuff versus being indoors in the winter. But I find it fascinating that San Diego has just so much biotech all around, and I will happily support how I can [laughs] turning it into a bionic limb capital. I think that's a great idea.

+ +

Well, so I wanted to get back...we're talking about the future right now. I wanted to ask about building your team. So you started the company almost seven years ago, and you've grown the team a lot since then. Did you have any essential principles or values that you started with when you were building out your team?

+ +

DR. AADEEL: Yeah. So when we were first hiring, I was still a Ph.D. student when I started the company. Our first employee was actually my undergraduate student. He's currently our Director of Engineering, Jesse Cornman. And we specifically were recruiting people that did stuff outside of the lab, so the electrical engineers and the mechanical engineers that we initially hired. We wanted to make sure that it wasn't just like the university projects that they were working on.

+ +

And we would find a lot of our early people from like car team so like this was like building like a solar car, so Illini Solar Car was one of our places where we'd get a lot of our early employees as well as the electrical vehicle concept team and design, build, fly, and these student organizations where they had like competitions, and they had to build real, tangible things to compete in with. And the thing is that those are the people who do this stuff for fun, and you learn the most when you're having fun doing this stuff. And so we would always look for that stuff in particular.

+ +

And there were some litmus tests that we'd have to be able to weed out very quickly what people know what. And so for electrical engineers, we would always ask if they know surface mount soldering because it's not like your typical soldering on a perf board or even like using a breadboard. It's like you have a circuit board, and you have to solder these very small components on there. And if you know how to solder those small components, you typically know how to code them as well. So they have some embedded systems background as well and some PCB design experience as well. And so that was like a quick litmus test that we use for the electrical engineers.

+ +

For the mechanical engineers, it was typically if they knew how to do surface modeling. And so we would ask them, "How would you make the palm of a hand where you got these complex structures and these complex surfaces that have different geometries and different curvature?" And if they were able to do a surface modeling, then we knew that they'd be able to CAD that up pretty quickly. They probably have some sort of 3D printing experience from that as well, and that they can just rapidly iterate and prototype on the devices.

+ +

And so that worked really, really well. And so we were able to get a lot of bright engineers who early on in the company...and many who were student interns at the time that eventually even went on to Microsoft and Google or some of the students went to MIT and places like that. And we were very fortunate to be in the University of Illinois at Urbana-Champaign's ecosystem, where it was just one of the best engineering schools in the world to develop this kind of stuff.

+ +

VICTORIA: That's great. So you had really specific skills that you needed. [laughs] And you kind of knew the type of work or an experience that led to that. As you've expanded your team and you're building a culture of collaboration, how do you set expectations with how you all work together?

+ +

DR. AADEEL: As a startup, we all wear many, many hats. So my job, I feel like, is to fill in all the gaps. And so some days, I might be doing marketing; some days, I might be visiting a clinic and doing sales. Other times I'm working with the engineering team to make sure that we're on track over there. And it's like all this stuff in between.

+ +

And so being able to work cohesively like that and put on those many hats so that you know every part of the process from the marketing and sales sides but also the engineering and operations side, I think that's really allowed us to get to the point where we have by doing all these different functions together.

+ +

VICTORIA: That makes sense. So you are all located in San Diego now, so you have to be in person to work on robot hands?

+ +

DR. AADEEL: Yeah, we found that it was much easier to build a physical object in person than it was to do things remotely. At the beginning of COVID, we actually did try to, like, you know, we moved 3D printers out into people's houses and the manufacturing equipment. And then I remember just to put together a power switch that usually took like one hour to do in the lab. It took us a day and a half because one person had the circuit board, the other person had the enclosure, the other person had the thing to program it. And then each thing depended on each other. So you had to keep carting that small piece back and forth between houses, and it was just a nightmare to do that.

+ +

And so after a couple of months, we ended up moving back into the offices and manufacturing there with staggered work hours or whatever. And at that point, we were just like, okay, this is much more efficient when we're all in person. And honestly, a lot of our best ideas have come from just me sitting here and then just walking over to one of the engineers and being like, "Hey, what do you think of this idea?" And it's a lot harder to do when you're all remote, right?

+ +

VICTORIA: That makes sense. Yeah, just the need to physically put pieces together [laughs] as a group makes it hard to be fully remote. And you get a lot of those ideas flowing when you're in person. What is on the horizon for you? What are you most excited about in your upcoming feature set?

+ +

DR. AADEEL: Like I said, one of the reasons why we moved here was to work with the military hospital, and so some of the work that we're doing with them is particularly exciting. The way you typically wear these prosthetic devices...so you'll have muscle sensors that are embedded in a...it's like a shell that goes around your residual limb. We call it the socket. Think about it as like a shoe for your residual limb.

+ +

And the thing is, as you're wearing this throughout the day, it starts to get sweaty. It starts to get uncomfortable. Things shift around. Your signals don't control the hand as well because of all these changes and everything. And with the military hospital, we're working on something called osseointegration. So instead of having this socket that's molded to your residual limb that you shove your arm into, you have a titanium implant that goes inside your bones and then comes out of your body, and then you directly attach the hand to your bones like a limb naturally should be.

+ +

And then, on top of that, instead of using these muscles sensors on the outside of your body, we're actually working on implanted electrodes with some of our collaborators. For example, at University of Chicago, they're doing brain implants to control prosthetic limbs. And a company in Dallas called Nerves Incorporated that's working with the University of Minnesota and UT Southwestern; they're doing nerve implants in your forearm and in your upper arm to control prosthetic limbs.

+ +

And with those, you get much more fine control, so it's not like you're just controlling different grips, like preset grips in the hand, but you're actually doing individual finger control. And then, when you touch the finger, it's actually stimulating your nerves to make it feel like it's coming from your hand that you no longer have anymore. And this is where we're heading with all of this stuff in the future.

+ +

And so we built The Ability Hand to work with clinically available systems now, like sockets, and muscle sensors, and vibration motors that are all outside of the body. But then also, when these future technologies come up that are more invasive that are directly implanted on your nerves as well as into your bones as well, we're really excited about those prospects coming out in the horizon.

+ +

VICTORIA: That's really cool. [laughs] I mean, that would be really life-changing for a lot of people, I'm sure, to have that ability to really control your fingers and get that extra comfort as well. How do you manage quality into your process, especially when you're getting invasive and putting in nerve implants? What kind of testing and other types of things do you all do?

+ +

DR. AADEEL: With The Ability Hand itself, there was actually an FDA Class I exempt device, meaning that we didn't have to go through the formal approval process that you typically do. And that was primarily because it's attached to your residual limb as opposed to going invasive. But with going invasive, with our clinical partners they're actually doing FDA clinical trials right now. And so they've gone through a lot of those processes. We're starting to enroll some of our patients who are using The Ability Hand to get these implanted electrodes. We're kind of navigating that whole process ourselves right now too.

+ +

So I think that was one of the reasons why we moved to San Diego, to work with and leverage a lot of the expertise from people who've done it already, from the med tech device companies that are big that have gone through those processes and can guide us through that process as well. So we're excited to be able to leverage those resources in order to streamline these clinical trial processes so that we can get these devices out there more quickly.

+ +

VICTORIA: That's very cool. I'm super excited to hear about that and to learn more about PSYONIC. Is there anything else you want to share with our audience today as a final takeaway?

+ +

DR. AADEEL: Absolutely. So in order to make all this stuff happen, we're actually in the middle of raising a round right now. Our biggest issue right now is actually that we've got more demand than we can produce, so we're working on scaling our manufacturing here in San Diego. So we're in the middle of an equity crowdfunding round.

+ +

And we're all about accessibility, so about making our hand accessible to as many people as possible. So we were like, why don't we make the company accessible as well? And one of the most beautiful things about doing this as an equity crowdfunding round is our patients actually have invested in the company as well. And so it's like, we're making these devices for them, and then they get to be a part of it as well. And it's just this beautiful synergy that I couldn't have asked for anything more out of a crowdfunding campaign.

+ +

And so we've raised over 750k already on StartEngine. And you can find out more and invest for as little as $250 at psyonic.io, so that's psyonic.io/invest. And the other thing I was going to mention, especially Victoria since you're in San Diego as well, is that I happily give tours to anyone who is in the area. So if anyone wants to see how we build all these bionic hands and just a cool robotics startup in general, we'd be happy to have you come visit us.

+ +

VICTORIA: That's very cool. I'll have to connect with you later and schedule a tour myself. [laughs] That's wonderful. I'm excited to hear all the things you're working on and hope to see you more in the San Diego community coming up. And we'll share links to the funding page and other information about PSYONIC in our show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Mastodon at Victoria Guido.

+ +

And this podcast is brought to by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Aadeel Akhtar.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+iIZhBz9n + + ]]> + + Victoria Guido + Aadeel Akhtar + + + 460: Frontrow Health with Irfan Alam + https://podcast.thoughtbot.com/460 + ca86d1fb-67e9-422f-aae5-9fe4a78bda39 + Thu, 02 Feb 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Irfan Alam is the CEO of Frontrow Health, a startup with a mission to finally put Americans in the front row of their own healthcare. + +Will and Victoria talk to Irfan about his background in business strategy and development for healthcare companies, how he went about searching for and building the perfect team, and how he started the culture of Frontrow Health on a level where there is balance and people want to join because it has a good culture. + 48:40 + no + + + Irfan Alam is the CEO of Frontrow Health, a startup with a mission to finally put Americans in the front row of their own healthcare. +Will and Victoria talk to Irfan about his background in business strategy and development for healthcare companies, how he went about searching for and building the perfect team, and how he started the culture of Frontrow Health on a level where there is balance and people want to join because it has a good culture. +Frontrow Health (https://thefrontrowhealth.com/) +Follow Frontrow Health LinkedIn (https://www.linkedin.com/company/frontrowhealth/). +Follow Irfan Alam on LinkedIn (https://www.linkedin.com/in/irfanalam12/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Irfan Alam, Founder, and CEO at Frontrow Health, a startup with a mission to finally put Americans in the front row of their own healthcare. +WILL: Hi, Irfan. Thank you for joining us. +IRFAN: Thanks for having me; super excited to chat more about the whole process of building and launching Frontrow Health. +VICTORIA: Yes, we're super excited. Of course, I know you as a client of thoughtbot, and I'm excited to hear your story. And you have this background in business strategy and development for healthcare companies. But what led you to decide to start your own platform? +IRFAN: I think it was a combination of two things; one was a lived experience being inspired by the power of entrepreneurship with my family and then working at Everlywell. And then two, it was discovering and being reminded of a critical problem that I saw in the industry that I then became excited about solving. +So growing up, I was raised by my two parents and my grandparents. My grandfather was an entrepreneur himself and also an immigrant and kind of brought our whole legacy of my family into the U.S. from Southeast Asia. He has always motivated me to take risks and to build something great for the world, and that's what he's always wanted for me. +And so I joined Everlywell, a small digital health startup, back in 2019 because I was excited to get my feet wet in the world of startups. It was just within a number of months after that I had joined where COVID-19 hit, and Everlywell, a home lab testing company based out of Austin, got swept up into the storm of COVID and, in a lot of ways, threw ourselves into the center of the storm when we ended up launching the first home COVID-19 test. +And it was that summer of 2020 when I probably had the most profound personal and professional growing experience of my life, just trying to handle this chaos and confusing world that we were all living in. But then also simultaneously watching how a small team could make an outsized impact in the world during a time of need. And that really led me to want to pursue my own startup ambitions. +So I started thinking about business school. The founder and CEO, Julia Cheek, went to Harvard Business School in 2009 and publicly talks about it being sort of this magical moment in time where people were flooding in from the downturn economy, excited about solving new problems. And her class of graduates is sort of like a famous class of entrepreneurs. And so I brought it up with her, and she was super supportive. And I went through the process and got super lucky. And I decided to take the summer off in 2021 before coming to HBS and moving back to Boston. +And it was during that summer where I started thinking about the problems that companies like Everlywell and direct-to-consumer health brands faced that I realized was not just at the fault of their own but because the industry didn't have the right digital tools necessary to succeed. That's sort of the origin of how Frontrow Health came to be. +WILL: Sweet. So perfect segue; tell us more about the mission of Frontrow Health. +IRFAN: We're on a mission to put people on the front row of their own healthcare. And we really just want to reimagine how people shop for their healthcare online. What I learned at Everlywell was that this boom of consumer health which means people who are taking charge of their own health and are able to do that directly through these digital health companies was a form of healthcare that could create a tremendous amount of value in people's lives. But that was only really accessible to a small niche audience. And it didn't feel like it was equitably accessible to the average American. +And so some of those barriers that I realized as a part of my work at Everlywell for why the average American wasn't engaging with consumer health, this otherwise really powerful form of taking charge of your own health and wellness, was because of these three blockers that we're trying to address at Frontrow Health. The first being that people just don't know about what kinds of solutions are out there that can address their health issues beyond just taking a prescription medication given to them by the doctor that they visit in their office. +The second is if they do know, they don't know what to trust. They don't know whether this spam of healthcare companies that they're getting advertisements on from Instagram are the right companies, whether these products are safe and effective for them uniquely because of their unique health issues their unique health history. +And then finally, even if they are aware and they do trust the health product, at the end of the day, a lot of Americans just can't afford to spend money out of pocket to pay for these consumer health and wellness products like consumables, devices, virtual services, et cetera. And so Frontrow Health is all about trying to break down those barriers in order to unleash consumer health to the average American. +VICTORIA: And were you always drawn to that healthcare industry from the beginning? +IRFAN: Yeah. So I grew up very privileged with two parents who are physicians. My mom is a psychiatrist, which is quite rare for women of color, specifically of South Asian descent, to be a psychiatrist. And then my dad was a gastroenterologist. They were always the gut-brain connection between the two. And so, growing up, I somewhat classically assumed that I was going to be a doctor. Got to college, thought that that was going to be my path. I realized quickly that there is a whole world outside of being a physician yourself that I could still be a part of in healthcare without being a doctor. +My parents actually, interestingly enough, began to encourage me to think beyond just being a doctor, with them both feeling like the amount of scale of impact that they could have would never be the same as someone who could do that through business or policy or these other facets that are important to healthcare. And so I got to undergrad, started studying policy economics. I started doing internships at different healthcare consulting firms. +And I ended up first working at a life science business strategy consulting firm out of college. And it was great, but it ended up not being what I was most excited about because it was really focused on the biopharmaceutical and medical device industry. And what I realized when I got there was I just had this growing passion for digital health and technology, as I saw that it was kind of the future of how people were going to be able to take more preventative charge and improve their health over the long term. +And so I was working on this digital health white paper with a partner at the consulting firm I was at, and I was doing research and stumbled upon Everlywell. And then, they had a job opening for this business strategy role. So that's why I ended up taking the leap into the startup world, into the digital health world, and just loved it and kept wanting to continue to grow my experience in that space. +WILL: That's amazing. Your parents encouraged you to step outside of just the doctor-physician role and to think higher. So, as a founder, you know, it was amazing that your parents, as physicians, encouraged you to think higher and think into different roles. And as a founder, what were some of the decisions you had to make? What were some of the easier ones? What were some that were surprisingly difficult? +IRFAN: I think the biggest misnomer of the founding experience is that founding a company is extremely linear. Sometimes you go one direction forward, and then you take a direction diagonally back, and then you go horizontally straight, and that was my story. When I do my pitch about Frontrow, I try to make it feel a little bit more linear, so it makes sense to people. +But the truth is the quote, unquote, "hardest decisions" were about every time there was a direction changing point, and it required a decision about is this the right idea? Do I want to spend more time on another idea? Have I validated this enough? Should I validate it differently? Should I pursue this one further? What does that pursuit look like? Who should I pursue it with? Is it time to raise money? Do I drop out of school? Like, those direction-changing points that then create this much more complex map of the founder experience versus a linear line up into the right is, I think, the more challenging parts of being a founder. +VICTORIA: That makes a lot of sense that you have to really go through this iterative process to figure out where are you spending your time, is it in the right place? A lot of hard decisions to make. And while you were founding Frontrow Health, you were also a part-time investor at Rock Health and reviewing other healthcare startup proposals. So did you see any trends or patterns that influenced how you progressed as a founder? +IRFAN: Totally, yeah. That was actually instrumental to Frontrow Health. So the story is when I took the summer off before business school, I started thinking about different problems in the world, healthcare, and non-healthcare. Or actually, to be clear, I started thinking about lots of different solutions and ideas and then quickly began to realize that that was not the right approach to founding. I think the first step is to think about problems, problems you've seen, problems you've experienced, that you know others are experiencing, and then work to a solution from there by starting with what the user is experiencing. +And so as I was going through that hacky journey over the summer, just randomly, a number of small healthcare companies started reaching out to me asking me for my opinion and advice about how or whether they should go direct-to-consumer, whether they should sell healthcare products direct to the consumer, which is what I did a lot of work on at Everlywell as one of the pioneering consumer health brands in the space. +And I started to notice this trend of me telling these companies, "No, don't do it. It's really expensive. It's really ineffective and unprofitable to acquire customers through traditional paid media avenues like Instagram, TikTok, Snapchat, Facebook, et cetera." And, unsurprisingly, you could imagine Everlywell was trying to sell a home diabetes test for people who are type 2 diabetics but were only able to target people based on their interest in yoga and running, which is not really a substitute for a severe chronic condition. +And as a result, thousands of people would see our ads every day that had no clinical relevance to our solution. And that was one of the deep problems of why consumer health companies weren't able to reach out to the audiences that actually really needed their solutions. And so when I got to Rock Health at the first semester in business school, doing this sort of part-time investor gig, on the first day, the partners basically told me, "Oh, we don't invest in consumer health." +And I was like, "Oh, whoa, okay, that's my jam. That's a bummer. That's like [laughs] the only thing that I know about." And as I started to see the data and the pipeline of companies that were looking for investments and understanding what their unit economics looked like, what their go-to-market approaches looked like, that's when I started to put the dots together that this was not just an Everlywell problem; this was an industry problem. Mark Zuckerberg didn't build Facebook so that direct-to-consumer healthcare companies can cost-effectively target clinically relevant patients online. That just happens to be what it's being used for today. And so that's when I started to realize that there had to be a quote-unquote, "better way." +WILL: You bring up social media at Frontrow Health. Have you had to combat the medical advice of social media? +IRFAN: Yeah. You mean like this concept of quote, unquote, "Instagram medicine?" +WILL: Yes. Yes. +IRFAN: It's a great question. So as the story continues, I began to think about what is the right solution to this problem? And instead of Everlywell, I started thinking about the right solution to this problem. What I realized was instead of Everlywell wasting away millions of dollars to big tech companies that wasn't going to improving the health of anybody, what if we gave that money back to the consumer in reward for sharing their health information which would allow us to target them with the right clinically relevant products? +That was the first version of Frontrow Health. I called it Health Mart back then. And so I basically started to get people to fill out a Google Form with their health data. And then I worked with my parents to send weekly product recommendations over email based on their unique health needs; you know, I want to sleep better; I'm a diabetic, whatever it is. +And then, I wanted to see if I was just going to Venmo them cashback upon purchase if they were going to be any more likely to buy these products for these health brands. And at first, people were incrementally more likely to buy. It wasn't mind-blowing. And so, as I started to talk to the participants of the study, I started saying, "You know, you said that you have high cholesterol. These supplements have active ingredients that have been shown to reduce LDL levels. It's pretty cheap. I'm giving you 25-30% cashback. Why haven't you bought it?" +And what they started saying was, "Well, I don't know what these active ingredients are. And before I put that in my body, I want to check with my doctor first." And so that was the final aha moment that led us to Frontrow Health, which is, what if we could bring the doctor into the fold? And instead of consumers just experiencing this Instagram medicine where they're just being blasted with Instagram ads every day about different health products, and they don't know what to trust, that second barrier that I talked about earlier, what if the doctor could instead of just being a guide for what prescription medications you should be taking could also be a guide on what health and wellness products you can be using? +And so I added my dad to the email thread, and I said, "Okay, you can talk to an independent medical provider and ask them questions about the products that you're being recommended." And that's when people started buying because then they were able to find the trust in the products that were being curated based on their unique information. +WILL: Wow, that's really neat. So to help the audience understand your iteration today, so the first iteration was just giving products and then Venmoing them back cashback. And then the second was bringing in a provider. So what does the product look like today? +IRFAN: We went through, like you mentioned, a lot of different iterations of this. There were even prior iterations to this that are more representative of that founder map versus the linear line that you've sort of just heard now. But in terms of where the story went from there, I began to think about how to validate this idea further. I came into winter break; the pilot went well. People were buying a lot of products. +And so, I decided to sunset my part-time investor gig at Rock Health and decided to reallocate all my time to working on Health Mart at the time. What I started to think about was, well, what if the doctor was able to earn compensation for writing private product reviews regardless of their opinions? So that was the next iteration was like, how do you incentivize a doctor to take time out of their day to do this new behavior that doesn't exist? +Doctors are not writing personalized private product reviews for their patients on supplements, home medical devices, apps, et cetera. And how could we get them to? And so, I started thinking about what are the different motivations of providers? Their time is extremely valuable. How do you incentivize them correctly without incentivizing them to give good or bad feedback but just honest feedback? +Then I started basically having my dad recommend Health Mart to his patients every day to see would patients sign up. Like, if doctors were intrinsically motivated to get their patients on the platform so that they can help them get away from Instagram medicine and at the same time earn compensation for themselves as an additional revenue stream, could independent medical providers see that as valuable and a good use of their time? +And the first piece of that about whether patients would sign up worked unsurprisingly very well. If your doctor is telling you to sign up for something, or it's free to sign up, and you only pay when you want to buy a product, and they're going to, for the user, be able to ask for feedback from the provider, they were pretty excited. +But then the question of would doctors sign up, I started...basically, I had my mom. The next iteration was I had my mom make a couple of posts in these doctor Facebook groups. I put together a little website, a very ugly version of what we have today for a provider marketing page. And I had my mom drop the link in a couple of different doctor Facebook groups. And we actually started getting signups from the doctors. +And then, as we started talking to them, what we realized was two things; it was like a win-win. The doctor was happy because they were getting compensated, and they were happy because their patients' health was improving. So when Obama was in administration, he passed a really fundamentally important piece of legislation called The Sunshine Act. And that basically ended this quote, unquote, "golden era" of pharma companies giving kickbacks to doctors. +WILL: Oh wow. +IRFAN: And so since then, doctors have been very eager to find additional revenue streams that they can leverage their decades of medical expertise to earn. They got medical bills to pay off loans to pay off. They spent 20 years training for this job. And so they were excited about an additional revenue stream that leveraged their medical expertise and also helped their patient. Because they also started saying things like, "Well, my patients are always asking me like, 'What about these supplements I saw for these ads online?'" And the doctor says, "I don't know what these supplements are. +WILL: [laughs] +IRFAN: I don't have the data in front of me. I don't know what the ingredients are. I don't know whether to trust the company or not." And we are building a platform where it's all streamlined for the provider. The provider is able to review the clinical information. They're able to review their patient information. They're able to really quickly write reviews. We give them templates. We give them suggestions. They're able to reapply recent reviews. And so that was sort of the next iteration. And that's actually when thoughtbot came in and when I started thinking about raising a small round, getting a dev shop to help me build the MVP. And that's kind of how the semester ended up closing out. +VICTORIA: I love that your mom and dad were so supportive, it sounds like, of you going full-time on this startup. Was that scary for them for you to do that? +IRFAN: It's so funny, yeah. So what happened next was I decided I wanted to start raising a small round because I had the conviction that there was a problem to be solved for consumers, for doctors, and for health brands. And we could build this one unique multi-sided marketplace to solve them. I ended up going back to Austin for spring break partially to visit my family and partially because I wanted to pitch to Julia, the founder of Everlywell, who I thought of all people on planet Earth would understand what I'm trying to do. She would get it because I am building a SaaS solution for health brands like Everlywell and her consumers. +And she got it. She was jazzed. And so, she decided to angel invest. And that basically spurred a ton of interest from venture capital firms. I wasn't originally thinking about raising an institutional round but was very lucky with the timing. Just before the market crashed, it was a very hot market. And so we ended up closing a real seed round with the question on hand about whether I should pursue this full-time because the capital that I raised necessitated building a real team. Or should I just take a smaller amount of money and go back to school? +And it's unsurprisingly, every different person in my life had some opinion about this, from my wife to my investors, to my parents, to my friends. What I wanted was somewhere nestled in between all of those things. And when I caught my dad up on the phone a couple of weeks after spring break and told him of all the crazy stuff that had been happening...and it was just happening and unfolding so quickly. I was like, "Okay, dad. I'm laying out all my cards here. You have full liberty to be mad at me for wanting to drop out of Harvard." +And his first reaction was, "Well, you know, I don't really see the downside. Like, you could either start a company that you're really passionate about and it could go well, or you could be the worst entrepreneur of all time and then just come back to school during this leave of absence," or deferral thing that I'm on right now. And that was the first time where I was like, "Oh, you know what? I think you're right." And the truth was I decided to just continue to let the summer go by to think about the decision a little bit more before I formally submitted my deferral to HBS. +As the markets turned, we realized that we needed to hire internally to save on cash burn a little bit. And so once I had built this really awesome team that I'm so lucky to be surrounded by, that's when I was, you know, without a doubt in my mind, I was like, I got to keep pushing for this because now we have this awesome team that just wants to keep driving this mission forward. And we were getting traction. We were talking to hundreds of doctors over the summer. We were talking to health brands. And it really felt like we were onto something. +MID-ROLL AD: +thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. +We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. That's T-B-O-T.I-OVICTORIA: I-N-C-U-B-A-T-O-R. +WILL: I hear you have an amazing product team. How did you go about searching and building the right team? +IRFAN: We got lucky in a second way because of timing, where the first time was I raised the capital when the market was really hot in April. And then, I started hiring when the market crashed. And, unfortunately, as you all know, lots of people have been getting laid off since the summer, particularly in the tech world: designers, engineers, marketers, et cetera. +Now, all of a sudden, there was a flood of really great talent on the market. And that was also what spurred me to start thinking about hiring sooner than I was originally planning to. My forecast was to hire people end of this year, maybe in a month or so from now, to start that process. Versus, we ended up making our first full-time hire, I guess in July, maybe. +And it was...the best way I can describe it is like dominoes falling where once you get the first one in, then it builds trust and credibility, and then the next one comes, and the next one. And so the first couple of folks were these two brilliant engineers who were close friends of my interim CTO and classmate, Amit, who was helping us build the foundation of the product this past summer. +He did an amazing job of basically recruiting one engineer, Anand, our first engineer who started his career as a PM at Microsoft and then turned into a software engineer at a number of different startups and studied comp sci and electrical engineering at Berkeley with Amit, where they first met. +And then the second engineer was Nupur, who was a colleague of Amit, a machine learning engineer at Google Brain and the moonshot X team at Alphabet. And they were both, I think, just kind of tired of big tech and were ready to bet on the upside and their career. And the timing was right based on where the market conditions were. And so they decided to take the leap of faith with me. +And then after that, or around that time, kind of in the middle, we were able to bring on our head of design, Jakub, who is like a unicorn human with so much rich experience in the product world. So he was a computer animator and then studied visual arts, but then started his career very early in the coupon website space as a product designer actually. And then led product design as a founding designer at a number of different startups. And then, most recently, was a senior product designer at Roman, which is a really large digital health company similar to Everlywell. +And Ro, Everlywell, Truepill, all these companies had mass layoffs in the middle of the summer. And so when Jakub took my call...He talks about a really funny story where he wasn't taking me seriously at all. Convincing these excellent, talented people to come join my dinky startup at the time was not easy. +WILL: [laughs] +IRFAN: And so he just kind of took it because there was a mutual connection. Or he just said, okay, I'll explore what's going on given how crazy the market is. But once he heard what we were building, he was immediately on board, actually, because Roman has also struggled with the same customer acquisition problems. And it's a huge reason why a lot of these digital health companies continue to remain unprofitable. And so he understood the problem deeper than I think anyone because of the experience he had in the same space that we were in. And he realized that there was an opportunity to build a solution to solve these problems. +So that was the first core team. And then from there, it kind of just snowballed, you know, there was more and more interest from other folks to join. And we brought in a great junior product designer. We just hired our platform engineer. But that was the original core team from the summer who took the big leap of faith and joined because of the market conditions, the belief in the space. +And we actually just met up in San Diego for the first time for a company retreat in person. And it was just fun meeting everyone in person for the first time because now I get to know them as real people and see all their personalities. And we're really psyched about coming to product launch pretty soon here. +VICTORIA: That's wonderful and, you know, that compelling vision and having those first initial people join and brought in everyone else. You know, I think part of the reason people are hesitant to join startups is because there is that reputation for kind of unhealthy work-life balance. So you're a healthcare startup. So how do you start the culture of your company on a level where there is that balance and people want to join because it has a good culture? +IRFAN: It's a super interesting question that we spent a lot of time actually talking about in San Diego as a team. And it was brought up because I have a somewhat unhealthy relationship with work. And I am constantly working. And this is the most important thing right now in our life. And so Nupur, one of our engineers, had a phenomenal analogy that I think is the right framework to think about this from a company culture perspective. +Because I've always tried to share with a team, like, I don't expect them to work nearly as much as I do, and I don't want them to either. I think the analogy was such a fun, helpful way to think about why that was the case. And so she kind of said, "I'm like the aunt, and you're like the single father. And the aunt doesn't have to take care of the baby at nighttime and on the weekends, but the single father does. And it's not that the aunt doesn't care about the company, but there's some space and boundary in that relationship." +And so that's actually our motto right now is like, yeah, we all care about this product and this company, quote, unquote, "baby," but there's always biologically intrinsically going to be a deeper relationship between me and this company, for good reason. And so that is going to require me to work harder and longer than anyone else, probably for a long, long time. And I had to be ready for that. My wife and I had to be ready for that. +And so far, honestly, I've never been busier. But I've also never been...or, like, I've never had this ratio between busyness and stress where I'm really busy but not that stressed. And I think it's just because I love what I'm doing every day. I haven't ever found this happy balance where I actually just enjoy what I do. And I'm constantly excited about continuing to build the right product to help people. +WILL: Wow. +VICTORIA: I'm actually babysitting my niece and nephew this weekend. [laughter] My brother would say, "You need to be here on the weekends with them." +IRFAN: Maybe not the perfect analogy. But-- +VICTORIA: I like it, though. It makes sense. [laughs] +WILL: There's a difference. [laughter] +VICTORIA: Oh yeah. Will knows; he's a dad. +WILL: Yeah. I know company values can be so...we have them. Do we follow them? Or sometimes they get put on the shelf. I was reading your company values, "People first, bias for curiosity, and dream big." For Frontrow Health, how does that play a role in the day-to-day? +IRFAN: When Jakub, Nupur, and Anand had all joined like that first core team, we actually spent time writing all this out and creating a document that discussed what the company culture and values were. And we looked at different examples of other companies. Amazon famously has, I don't know, these 16 principles. And we kind of said, okay, we want to pick just a couple because you can't always focus on everything at the same time. And we need some sort of guiding North Star if you will. +And so these were the three that we came up with, the ones that you mentioned. So we are people first; we have a bias for curiosity, and we want to dream big. So people first to us means that our mission like we talked about, we want to increase access to healthcare at home for the average American. And so every decision that we make at the company has to pass that litmus test first. +Whatever feature we're building, whatever business model approach we're taking, whatever go–to–market approach that we're taking, is what we're doing going to increase access to healthcare at home for the average American? Yes? Then we continue onwards, and then we continue deliberating and deciding; if not, we pass. And so that is how we determine whether we can continue to be people first because that is our mission. +And as we're going down that thread, we want to push ourselves to constantly be bettering and asking questions about how we can be better. That is the bias for curiosity. That was one of Everlywell's company values and was the one that I resonated with the most. I find tremendous value in asking questions. Nupur on our team, one of our engineers, is a great example of bias for curiosity. She's constantly challenging and asking the right questions. And that helps us be better at being people first and increasing access even more than we can because we're never settled with what exists today. +And then dreaming big is about finding answers to those questions and not settling for the tried and true paths. Some of the greatest companies that have ever been created are the ones that invent new behaviors that have never existed before. So Airbnb, now all of a sudden, people are comfortable with strangers living in their homes. Uber, now all of a sudden, people are comfortable driving in a stranger's car. +At Frontrow Health, we're dreaming big in a world where doctors are not currently engaging with their patients related to their home health and wellness journeys when they leave the four walls of their clinic. How can we change the behavior where doctors are more involved in that relationship in a way that doesn't exist today? And so that's a part of what we're trying to do, and dreaming big to go and increase access, like I said, is our ultimate North Star. +WILL: Wow. You said something I think that was...it seemed very small, but I think it said a lot about you and your company. You said that you encourage your engineer to ask the hard questions. I think so many times, people hate the hard questions. They are fearful of that. But I think in your field, you have to be able to ask the hard questions. So that's amazing that you brought that up, and you're talking about that. +IRFAN: Yeah. And it doesn't...it's not just me, for sure. I think my team is...and it's kind of you to point that out. But yeah, my team does such a great job of holding true to these values on their own and pushing me to remind myself of these values. Nupur actually is Slacking me right now about some thought that she had coming out of a meeting. +WILL: [laughs] +IRFAN: And two points about different alternative ways to think about things. And yeah, I want to keep encouraging them and our future employees to do that. Because you look at the worst examples in healthcare, in particular, tech as well, the worst examples of companies are the ones where the employees were not able to or encouraged to ask questions; that's when things go south. +So Theranos is the simplest example of this where they were hiding everything from their employees, and people had questions constantly but never asked them. And that's when more and more bad decisions were made. So I don't want that to be the case for Frontrow. And so it has to start with, yeah, this bias for curiosity. +VICTORIA: That makes sense. And I wonder if that's part of your success, being someone who doesn't have a background in engineering or programming specifically and enabling your technical team to build what they need to get done. +IRFAN: Yeah. I can't honestly explain to you guys how much I've learned over the past six months from my product and dev team. And you're right that I think one could see my lack of programming as a weakness which, in a lot of ways, it is. But what has also manifested as a result of that is I have naturally had to lean more heavily on my dev team to be owners of decisions that affect our business and to challenge them to think about are we being people first if we build and design solutions in the way that you're describing? +I don't know the right approach about how to build this, or on what tech stack, or in what capacity we have the ability to. You guys have to take ownership of thinking through those, solving those problems, and coming up with the right decision. And as a founder, that's scary to do. You're giving up control of the decisions to others. But at the same time, by giving them that autonomy and encouraging them to take ownership of it, they feel I think more and more invested in what we're building. And that hopefully builds the habit of what you guys were talking about around wanting to constantly seek better solutions, challenge because they know that they have a voice in how things turn out. +VICTORIA: Right. Maybe you've discovered this naturally or through your education and background. But studies that are done around high-performing technology organizations find that no matter what processes or tools you have if you have that high-trust environment, you'll have better security, more software development throughput, all of those things. So I think you're doing it right by setting your values and creating that kind of high-trust environment. +IRFAN: Super interesting. I didn't know that, actually, but it makes sense. [laughs] We've been seeing it. I actually want to give some credit to thoughtbot because thoughtbot helped us set a lot of this important engineering culture at the very beginning, where I had to rely on my thoughtbot engineers, folks like Jesse, Dave, and others, to help me make the best decision for my company. +They taught me a lot of these things at the earliest stage back in May around, okay, like, you guys are a consulting firm at the end of the day, technically speaking. But they pushed me to think of it more as how do we co-make these decisions? Like, how do we leverage each other's strengths to make the right decisions? +The thoughtbot design team and engineering team...one of our designers through thoughtbot, Steven, is so funny because...and I gave him this feedback, which is great feedback, which is like, he constantly asked questions. And if he hears this, he'll laugh because he's constantly pushing, like, "Why are we designing it this way? Why do you think it should be this way? Where is the evidence that the user wants it to be this way?" And it was a great setup for when our internal team came on because I just kept up that momentum. And then they just kind of took with it and ran. +VICTORIA: How did you find us, or how did you find the right technical partners in the very beginning to help you build your vision? +IRFAN: It was not an immediately simple process. But when I found thoughtbot, it kind of unraveled quite quickly in a good way. So I was working with Amit like I mentioned, who'll become our interim CTO, one of my classmates at HBS. And he helped me put together an RFP where we outlined all the different feature requirements, all the different intentions for our solution or timeline, our costs, et cetera. +And I just did a lot of Google research about different dev shops, and I started talking to dev shops in lots of different locations, U.S.-based, European-based, Asian-based, Latin America-based, started comparing prices. We had questions where we wanted to see their creativity in developing solutions. We started accepting proposals, reviewing those proposals. +I somehow stumbled upon thoughtbot's website during this process. And I noticed that Everlywell was one of thoughtbot's clients, Everlywell, the home lab testing company that I used to work at before business school. I was like, oh wow. I knew that our engineering team and our engineering leadership had a really high bar for when we worked with outsourced talent. And so I thought that that spoke volumes about choosing thoughtbot. +And so then we actually ended up asking Everlywell CTO an unprompted question of like, "If you had to pick any dev house that you've known or have worked with, et cetera, that was supposed to build you custom software from scratch, who would you pick?" And he said, "thoughtbot." It wasn't even like a question of, what do you think of thoughtbot? Or, what was your experience? It was just like, imagine you had to pick, and, unprompted, he said thoughtbot. So that was actually what did it for me. +And I kind of threw aside all the other logistical hoopla that we were going through and said, you know, I got to trust the people who I know and trust, and having verbal confirmation of that was huge. And then, of course, I enjoyed speaking with Dawn at thoughtbot, who was helping broker the whole discussion, and it felt easy. And their proposal was also quite strong. And then, as I dug deeper into thoughtbot, it became clear that no pun intended, you guys are kind of the thought leaders in a lot of ways. +WILL: [laughs] +IRFAN: It's funny, our head of design, Jakub, when I mentioned that he's a unicorn, it's because he also taught himself coding and programming. +WILL: Wow. +IRFAN: So he's like a pseudo designer and programmer. He can do a little bit of everything. And he actually...when I told him that we were working with thoughtbot, he was like, "Oh, I learned Ruby on Rails back in the day from thoughtbot with whatever content they had published back in time." And then, as I spoke to other dev shops about going with thoughtbot, they started saying things like, "Oh, thoughtbot, yeah, they're kind of the OGs of Rails and a lot of the core tech stack that's been around for a while." And so it was just continued validation of the right approach. +And then, we started working with the team in May, right after my second semester of business school ended. And it's been an incredible process. We have never missed any deadlines, and we're actually two months ahead of schedule. And it's not just because they're good at what they do, but it's also because of the culture and the teaching me about the best way to run retros, and sprint planning, and things to think about in terms of trust in your engineer and building that trust, and all the soft, intangible things. It wasn't just like thoughtbot came in and built code. It was thoughtbot came in and helped establish the company in a lot of ways. +VICTORIA: That's great to hear. Thank you for saying all those wonderful things. I'm sure me and Will agree 100%. +[laughter] +IRFAN: Yeah, it's been an awesome process. And yeah, we've even ended up basically bringing on as a full-time independent contractor someone who worked through thoughtbot because we love them so much. And they were just so excellent at what they did. And just, yeah, I think that probably speaks the most volumes about the kind of organization that you guys are running. +WILL: I appreciate you saying that. That means a lot. It really does. I want to take a second to kind of circle back and kind of talk about how you find the providers because I think, for me, one of the most influential classes I had in college was my professor said, "Hey, meet me at the pharmacy." So we went to the pharmacy, and he started asking us questions. And he was like, "What medicine do you think would be the most impactful?" And we would try to pull it out. He taught us how to compare the active ingredients. +IRFAN: Wow. +WILL: Like how some stuff is just marketing, and it's not really helpful and things like that. But I also saw the side, you know, the amazing providers like your parents. You talking about your parents just reminded me of my parents and how supportive they are. So it's just amazing. You had your parents as providers. How did you find providers beyond that that you have to extend that trust to them? +IRFAN: I guess two reactions. The first is how do we talk to doctors to get feedback on our solution as we're building it? And then how do we get doctors to sign up and use our solution with their patients? Those are the two chronological steps. So for the first one, we very liberally use a platform called usertesting.com, which we used at Everlywell, where I first got introduced to it. And it's amazing. +We have the unlimited package, and we run tons of user tests a day. So, over the summer, we were literally having unmoderated tests from medical professionals, about ten healthcare professionals a day who were coming to our website, coming to our product, giving their feedback through these unmoderated tests. We were quantitatively assessing qualitatively assessing their responses to specific questions that we were asking them. +Like, was it easy enough to write a review? What were you expecting to see? How did that compare to what you did see? Like, all the traditional kind of user research. They really helped us build the product, and then we were able to follow up with them, get on the phone with them, ask them more questions about their experience, about their current experience in their clinic, whether patients are asking them about these things, about their interest in certain supplements, et cetera. +And then we actually had one medical provider, a family practice nurse practitioner from Vermont, who was so excited about what we were building. She was sending me all this other information and content about how to reach out to other doctors and stuff. And then, at the end of the summer, when we were just about ready to start getting our beta off the ground, we were going to choose one provider to work with who was going to recommend it to their patients, and they were going to slowly kind of monitor the experience. +This nurse practitioner actually just happened to reach back out, and we happened to connect again. And she's like, "Okay, what are you guys up to? Are you guys done with your product? I really want to use it." And I was like, "Oh, wow. Well, it's great timing because we're looking for our first medical provider." +WILL: [laughs] +IRFAN: And so that's where we ended up launching beta with, which was awesome. And since then, I've been spending a lot of time thinking about the go-to-market approach beyond just one medical provider. How do we scale to thousands of medical providers? And luckily, selling to doctors is a solved problem, like; the biopharma and medical device industry has been doing this for decades. +And so it was really just a part of me brushing up on a lot of the work that I was doing in life science consulting about helping Big Pharma and whatnot go to market and just stealing a lot of notes out of their playbook. So, for example, there are companies that allow you to run ads online that just target physicians. So instead of my dad seeing a Lululemon ad while he's reading The Wall Street Journal, he'll see an ad for Frontrow Health. +And so we actually run marketing tests over the summer, towards the end of the summer, with a newer provider landing page that we had built to see what percent were going to click on the ads, what percent were going to come to the website and sign up, and then how much cost would that be per acquisition of a provider. And the results were actually much better than we thought. It was half as expensive as what we originally predicted, which is awesome. +WILL: Wow. +IRFAN: And that was before Jakub, our new head of design, had even touched the website. We're actually just revamping it right now because he's been going through and revamping other aspects of our product and marketing experience. And now we're at the provider part. So we're actually going to be just about a week or so away from launching the marketing tests and actually getting every day more providers on the platform. +The product is now done, so they can start getting their patients on the platform. We just signed our first health brand. So now people are getting real product recommendations and getting ability to earn cashback. And we can be revenue generating, which is also super exciting that we're, like I said, a couple of months ahead of schedule, actually. +VICTORIA: That's really exciting, and that certainly sounds like enough on your plate. But is there anything else on the horizon for Frontrow Health that you're excited about? +IRFAN: Yes. We are super excited that we're just coming out of stealth mode and launching our full product experience for consumers, medical providers, and DTC health brands. Going forward into 2023, we're really looking to try to find this quote, unquote, "product market fit." Are doctors excited about signing up and getting their patients on the platform? Are those patients excited about the products that we're selling on our marketplace? And are we delivering new lifetime customers for these health brands at a more cost-effective rate than they've ever seen before? And solving that original problem that came to me while I was at Everlywell. +And by doing all three of those things, hopefully, we'll begin to increase access to healthcare at home where people who are not suburban high-income folks who can afford to pay out of pocket for preventative healthcare; we can now make that more equitable by bringing down the cost through the cashback, by introducing the element of trust, by engaging with a medical provider, and by opening up people's eyes to thousands of different consumer health and wellness companies that now exist in the world that we want to be able to connect the right products to the right people with. +VICTORIA: That's so exciting. I'm really glad we got a chance to talk to you today and hear more about your story. Is there anything else that you want to add before we wrap up? +IRFAN: This has been super fun being able to even just reflect and think about our whole story. For anyone else listening who's interested or excited about entrepreneurship, there's a really good book that I read last summer as I started thinking about entrepreneurship for the first time called "The Hard Thing About Hard Things" written by Ben Horowitz, who co-founded the VC fund, Andreessen Horowitz. He was an entrepreneur himself. +And it's one of my favorite books because, as the title [laughs] explains, it just talks about the difficulty of the experience and the journey that's still ahead of me. But I think the overall takeaway of the book and my experience over the past year is that it's just the single greatest learning experience of my life. +And that's actually really all I'm trying to optimize for personally is I want to keep growing and learning, and learning about the space, learning about myself, learning about how to work on a team, how to lead a team, how to grow a team. And if you're at all interested in any of those things, keep trying to think about all the right problems that are being experienced in the world. And we still live in a world wrought with problems and don't have nearly enough founders trying to go and solve all of them. +VICTORIA: That's a really great perspective, I think, to bring to it about your own personal growth. And that's what it's really all about. [laughs] And hopefully, we're able to solve some big challenging problems along the way. +IRFAN: Hope so. +WILL: You can subscribe to this show and find notes along with a complete transcript for this episode at giantrobots.fm. +VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm. +WILL: You can find me on Twitter @will23larry. +VICTORIA: And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +WILL: Thanks for listening. See you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Irfan Alam. + + + Irfan Alam is the CEO of Frontrow Health, a startup with a mission to finally put Americans in the front row of their own healthcare.

+ +

Will and Victoria talk to Irfan about his background in business strategy and development for healthcare companies, how he went about searching for and building the perfect team, and how he started the culture of Frontrow Health on a level where there is balance and people want to join because it has a good culture.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Irfan Alam, Founder, and CEO at Frontrow Health, a startup with a mission to finally put Americans in the front row of their own healthcare.

+ +

WILL: Hi, Irfan. Thank you for joining us.

+ +

IRFAN: Thanks for having me; super excited to chat more about the whole process of building and launching Frontrow Health.

+ +

VICTORIA: Yes, we're super excited. Of course, I know you as a client of thoughtbot, and I'm excited to hear your story. And you have this background in business strategy and development for healthcare companies. But what led you to decide to start your own platform?

+ +

IRFAN: I think it was a combination of two things; one was a lived experience being inspired by the power of entrepreneurship with my family and then working at Everlywell. And then two, it was discovering and being reminded of a critical problem that I saw in the industry that I then became excited about solving.

+ +

So growing up, I was raised by my two parents and my grandparents. My grandfather was an entrepreneur himself and also an immigrant and kind of brought our whole legacy of my family into the U.S. from Southeast Asia. He has always motivated me to take risks and to build something great for the world, and that's what he's always wanted for me.

+ +

And so I joined Everlywell, a small digital health startup, back in 2019 because I was excited to get my feet wet in the world of startups. It was just within a number of months after that I had joined where COVID-19 hit, and Everlywell, a home lab testing company based out of Austin, got swept up into the storm of COVID and, in a lot of ways, threw ourselves into the center of the storm when we ended up launching the first home COVID-19 test.

+ +

And it was that summer of 2020 when I probably had the most profound personal and professional growing experience of my life, just trying to handle this chaos and confusing world that we were all living in. But then also simultaneously watching how a small team could make an outsized impact in the world during a time of need. And that really led me to want to pursue my own startup ambitions.

+ +

So I started thinking about business school. The founder and CEO, Julia Cheek, went to Harvard Business School in 2009 and publicly talks about it being sort of this magical moment in time where people were flooding in from the downturn economy, excited about solving new problems. And her class of graduates is sort of like a famous class of entrepreneurs. And so I brought it up with her, and she was super supportive. And I went through the process and got super lucky. And I decided to take the summer off in 2021 before coming to HBS and moving back to Boston.

+ +

And it was during that summer where I started thinking about the problems that companies like Everlywell and direct-to-consumer health brands faced that I realized was not just at the fault of their own but because the industry didn't have the right digital tools necessary to succeed. That's sort of the origin of how Frontrow Health came to be.

+ +

WILL: Sweet. So perfect segue; tell us more about the mission of Frontrow Health.

+ +

IRFAN: We're on a mission to put people on the front row of their own healthcare. And we really just want to reimagine how people shop for their healthcare online. What I learned at Everlywell was that this boom of consumer health which means people who are taking charge of their own health and are able to do that directly through these digital health companies was a form of healthcare that could create a tremendous amount of value in people's lives. But that was only really accessible to a small niche audience. And it didn't feel like it was equitably accessible to the average American.

+ +

And so some of those barriers that I realized as a part of my work at Everlywell for why the average American wasn't engaging with consumer health, this otherwise really powerful form of taking charge of your own health and wellness, was because of these three blockers that we're trying to address at Frontrow Health. The first being that people just don't know about what kinds of solutions are out there that can address their health issues beyond just taking a prescription medication given to them by the doctor that they visit in their office.

+ +

The second is if they do know, they don't know what to trust. They don't know whether this spam of healthcare companies that they're getting advertisements on from Instagram are the right companies, whether these products are safe and effective for them uniquely because of their unique health issues their unique health history.

+ +

And then finally, even if they are aware and they do trust the health product, at the end of the day, a lot of Americans just can't afford to spend money out of pocket to pay for these consumer health and wellness products like consumables, devices, virtual services, et cetera. And so Frontrow Health is all about trying to break down those barriers in order to unleash consumer health to the average American.

+ +

VICTORIA: And were you always drawn to that healthcare industry from the beginning?

+ +

IRFAN: Yeah. So I grew up very privileged with two parents who are physicians. My mom is a psychiatrist, which is quite rare for women of color, specifically of South Asian descent, to be a psychiatrist. And then my dad was a gastroenterologist. They were always the gut-brain connection between the two. And so, growing up, I somewhat classically assumed that I was going to be a doctor. Got to college, thought that that was going to be my path. I realized quickly that there is a whole world outside of being a physician yourself that I could still be a part of in healthcare without being a doctor.

+ +

My parents actually, interestingly enough, began to encourage me to think beyond just being a doctor, with them both feeling like the amount of scale of impact that they could have would never be the same as someone who could do that through business or policy or these other facets that are important to healthcare. And so I got to undergrad, started studying policy economics. I started doing internships at different healthcare consulting firms.

+ +

And I ended up first working at a life science business strategy consulting firm out of college. And it was great, but it ended up not being what I was most excited about because it was really focused on the biopharmaceutical and medical device industry. And what I realized when I got there was I just had this growing passion for digital health and technology, as I saw that it was kind of the future of how people were going to be able to take more preventative charge and improve their health over the long term.

+ +

And so I was working on this digital health white paper with a partner at the consulting firm I was at, and I was doing research and stumbled upon Everlywell. And then, they had a job opening for this business strategy role. So that's why I ended up taking the leap into the startup world, into the digital health world, and just loved it and kept wanting to continue to grow my experience in that space.

+ +

WILL: That's amazing. Your parents encouraged you to step outside of just the doctor-physician role and to think higher. So, as a founder, you know, it was amazing that your parents, as physicians, encouraged you to think higher and think into different roles. And as a founder, what were some of the decisions you had to make? What were some of the easier ones? What were some that were surprisingly difficult?

+ +

IRFAN: I think the biggest misnomer of the founding experience is that founding a company is extremely linear. Sometimes you go one direction forward, and then you take a direction diagonally back, and then you go horizontally straight, and that was my story. When I do my pitch about Frontrow, I try to make it feel a little bit more linear, so it makes sense to people.

+ +

But the truth is the quote, unquote, "hardest decisions" were about every time there was a direction changing point, and it required a decision about is this the right idea? Do I want to spend more time on another idea? Have I validated this enough? Should I validate it differently? Should I pursue this one further? What does that pursuit look like? Who should I pursue it with? Is it time to raise money? Do I drop out of school? Like, those direction-changing points that then create this much more complex map of the founder experience versus a linear line up into the right is, I think, the more challenging parts of being a founder.

+ +

VICTORIA: That makes a lot of sense that you have to really go through this iterative process to figure out where are you spending your time, is it in the right place? A lot of hard decisions to make. And while you were founding Frontrow Health, you were also a part-time investor at Rock Health and reviewing other healthcare startup proposals. So did you see any trends or patterns that influenced how you progressed as a founder?

+ +

IRFAN: Totally, yeah. That was actually instrumental to Frontrow Health. So the story is when I took the summer off before business school, I started thinking about different problems in the world, healthcare, and non-healthcare. Or actually, to be clear, I started thinking about lots of different solutions and ideas and then quickly began to realize that that was not the right approach to founding. I think the first step is to think about problems, problems you've seen, problems you've experienced, that you know others are experiencing, and then work to a solution from there by starting with what the user is experiencing.

+ +

And so as I was going through that hacky journey over the summer, just randomly, a number of small healthcare companies started reaching out to me asking me for my opinion and advice about how or whether they should go direct-to-consumer, whether they should sell healthcare products direct to the consumer, which is what I did a lot of work on at Everlywell as one of the pioneering consumer health brands in the space.

+ +

And I started to notice this trend of me telling these companies, "No, don't do it. It's really expensive. It's really ineffective and unprofitable to acquire customers through traditional paid media avenues like Instagram, TikTok, Snapchat, Facebook, et cetera." And, unsurprisingly, you could imagine Everlywell was trying to sell a home diabetes test for people who are type 2 diabetics but were only able to target people based on their interest in yoga and running, which is not really a substitute for a severe chronic condition.

+ +

And as a result, thousands of people would see our ads every day that had no clinical relevance to our solution. And that was one of the deep problems of why consumer health companies weren't able to reach out to the audiences that actually really needed their solutions. And so when I got to Rock Health at the first semester in business school, doing this sort of part-time investor gig, on the first day, the partners basically told me, "Oh, we don't invest in consumer health."

+ +

And I was like, "Oh, whoa, okay, that's my jam. That's a bummer. That's like [laughs] the only thing that I know about." And as I started to see the data and the pipeline of companies that were looking for investments and understanding what their unit economics looked like, what their go-to-market approaches looked like, that's when I started to put the dots together that this was not just an Everlywell problem; this was an industry problem. Mark Zuckerberg didn't build Facebook so that direct-to-consumer healthcare companies can cost-effectively target clinically relevant patients online. That just happens to be what it's being used for today. And so that's when I started to realize that there had to be a quote-unquote, "better way."

+ +

WILL: You bring up social media at Frontrow Health. Have you had to combat the medical advice of social media?

+ +

IRFAN: Yeah. You mean like this concept of quote, unquote, "Instagram medicine?"

+ +

WILL: Yes. Yes.

+ +

IRFAN: It's a great question. So as the story continues, I began to think about what is the right solution to this problem? And instead of Everlywell, I started thinking about the right solution to this problem. What I realized was instead of Everlywell wasting away millions of dollars to big tech companies that wasn't going to improving the health of anybody, what if we gave that money back to the consumer in reward for sharing their health information which would allow us to target them with the right clinically relevant products?

+ +

That was the first version of Frontrow Health. I called it Health Mart back then. And so I basically started to get people to fill out a Google Form with their health data. And then I worked with my parents to send weekly product recommendations over email based on their unique health needs; you know, I want to sleep better; I'm a diabetic, whatever it is.

+ +

And then, I wanted to see if I was just going to Venmo them cashback upon purchase if they were going to be any more likely to buy these products for these health brands. And at first, people were incrementally more likely to buy. It wasn't mind-blowing. And so, as I started to talk to the participants of the study, I started saying, "You know, you said that you have high cholesterol. These supplements have active ingredients that have been shown to reduce LDL levels. It's pretty cheap. I'm giving you 25-30% cashback. Why haven't you bought it?"

+ +

And what they started saying was, "Well, I don't know what these active ingredients are. And before I put that in my body, I want to check with my doctor first." And so that was the final aha moment that led us to Frontrow Health, which is, what if we could bring the doctor into the fold? And instead of consumers just experiencing this Instagram medicine where they're just being blasted with Instagram ads every day about different health products, and they don't know what to trust, that second barrier that I talked about earlier, what if the doctor could instead of just being a guide for what prescription medications you should be taking could also be a guide on what health and wellness products you can be using?

+ +

And so I added my dad to the email thread, and I said, "Okay, you can talk to an independent medical provider and ask them questions about the products that you're being recommended." And that's when people started buying because then they were able to find the trust in the products that were being curated based on their unique information.

+ +

WILL: Wow, that's really neat. So to help the audience understand your iteration today, so the first iteration was just giving products and then Venmoing them back cashback. And then the second was bringing in a provider. So what does the product look like today?

+ +

IRFAN: We went through, like you mentioned, a lot of different iterations of this. There were even prior iterations to this that are more representative of that founder map versus the linear line that you've sort of just heard now. But in terms of where the story went from there, I began to think about how to validate this idea further. I came into winter break; the pilot went well. People were buying a lot of products.

+ +

And so, I decided to sunset my part-time investor gig at Rock Health and decided to reallocate all my time to working on Health Mart at the time. What I started to think about was, well, what if the doctor was able to earn compensation for writing private product reviews regardless of their opinions? So that was the next iteration was like, how do you incentivize a doctor to take time out of their day to do this new behavior that doesn't exist?

+ +

Doctors are not writing personalized private product reviews for their patients on supplements, home medical devices, apps, et cetera. And how could we get them to? And so, I started thinking about what are the different motivations of providers? Their time is extremely valuable. How do you incentivize them correctly without incentivizing them to give good or bad feedback but just honest feedback?

+ +

Then I started basically having my dad recommend Health Mart to his patients every day to see would patients sign up. Like, if doctors were intrinsically motivated to get their patients on the platform so that they can help them get away from Instagram medicine and at the same time earn compensation for themselves as an additional revenue stream, could independent medical providers see that as valuable and a good use of their time?

+ +

And the first piece of that about whether patients would sign up worked unsurprisingly very well. If your doctor is telling you to sign up for something, or it's free to sign up, and you only pay when you want to buy a product, and they're going to, for the user, be able to ask for feedback from the provider, they were pretty excited.

+ +

But then the question of would doctors sign up, I started...basically, I had my mom. The next iteration was I had my mom make a couple of posts in these doctor Facebook groups. I put together a little website, a very ugly version of what we have today for a provider marketing page. And I had my mom drop the link in a couple of different doctor Facebook groups. And we actually started getting signups from the doctors.

+ +

And then, as we started talking to them, what we realized was two things; it was like a win-win. The doctor was happy because they were getting compensated, and they were happy because their patients' health was improving. So when Obama was in administration, he passed a really fundamentally important piece of legislation called The Sunshine Act. And that basically ended this quote, unquote, "golden era" of pharma companies giving kickbacks to doctors.

+ +

WILL: Oh wow.

+ +

IRFAN: And so since then, doctors have been very eager to find additional revenue streams that they can leverage their decades of medical expertise to earn. They got medical bills to pay off loans to pay off. They spent 20 years training for this job. And so they were excited about an additional revenue stream that leveraged their medical expertise and also helped their patient. Because they also started saying things like, "Well, my patients are always asking me like, 'What about these supplements I saw for these ads online?'" And the doctor says, "I don't know what these supplements are.

+ +

WILL: [laughs]

+ +

IRFAN: I don't have the data in front of me. I don't know what the ingredients are. I don't know whether to trust the company or not." And we are building a platform where it's all streamlined for the provider. The provider is able to review the clinical information. They're able to review their patient information. They're able to really quickly write reviews. We give them templates. We give them suggestions. They're able to reapply recent reviews. And so that was sort of the next iteration. And that's actually when thoughtbot came in and when I started thinking about raising a small round, getting a dev shop to help me build the MVP. And that's kind of how the semester ended up closing out.

+ +

VICTORIA: I love that your mom and dad were so supportive, it sounds like, of you going full-time on this startup. Was that scary for them for you to do that?

+ +

IRFAN: It's so funny, yeah. So what happened next was I decided I wanted to start raising a small round because I had the conviction that there was a problem to be solved for consumers, for doctors, and for health brands. And we could build this one unique multi-sided marketplace to solve them. I ended up going back to Austin for spring break partially to visit my family and partially because I wanted to pitch to Julia, the founder of Everlywell, who I thought of all people on planet Earth would understand what I'm trying to do. She would get it because I am building a SaaS solution for health brands like Everlywell and her consumers.

+ +

And she got it. She was jazzed. And so, she decided to angel invest. And that basically spurred a ton of interest from venture capital firms. I wasn't originally thinking about raising an institutional round but was very lucky with the timing. Just before the market crashed, it was a very hot market. And so we ended up closing a real seed round with the question on hand about whether I should pursue this full-time because the capital that I raised necessitated building a real team. Or should I just take a smaller amount of money and go back to school?

+ +

And it's unsurprisingly, every different person in my life had some opinion about this, from my wife to my investors, to my parents, to my friends. What I wanted was somewhere nestled in between all of those things. And when I caught my dad up on the phone a couple of weeks after spring break and told him of all the crazy stuff that had been happening...and it was just happening and unfolding so quickly. I was like, "Okay, dad. I'm laying out all my cards here. You have full liberty to be mad at me for wanting to drop out of Harvard."

+ +

And his first reaction was, "Well, you know, I don't really see the downside. Like, you could either start a company that you're really passionate about and it could go well, or you could be the worst entrepreneur of all time and then just come back to school during this leave of absence," or deferral thing that I'm on right now. And that was the first time where I was like, "Oh, you know what? I think you're right." And the truth was I decided to just continue to let the summer go by to think about the decision a little bit more before I formally submitted my deferral to HBS.

+ +

As the markets turned, we realized that we needed to hire internally to save on cash burn a little bit. And so once I had built this really awesome team that I'm so lucky to be surrounded by, that's when I was, you know, without a doubt in my mind, I was like, I got to keep pushing for this because now we have this awesome team that just wants to keep driving this mission forward. And we were getting traction. We were talking to hundreds of doctors over the summer. We were talking to health brands. And it really felt like we were onto something.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. That's T-B-O-T.I-OVICTORIA: I-N-C-U-B-A-T-O-R.

+ +

WILL: I hear you have an amazing product team. How did you go about searching and building the right team?

+ +

IRFAN: We got lucky in a second way because of timing, where the first time was I raised the capital when the market was really hot in April. And then, I started hiring when the market crashed. And, unfortunately, as you all know, lots of people have been getting laid off since the summer, particularly in the tech world: designers, engineers, marketers, et cetera.

+ +

Now, all of a sudden, there was a flood of really great talent on the market. And that was also what spurred me to start thinking about hiring sooner than I was originally planning to. My forecast was to hire people end of this year, maybe in a month or so from now, to start that process. Versus, we ended up making our first full-time hire, I guess in July, maybe.

+ +

And it was...the best way I can describe it is like dominoes falling where once you get the first one in, then it builds trust and credibility, and then the next one comes, and the next one. And so the first couple of folks were these two brilliant engineers who were close friends of my interim CTO and classmate, Amit, who was helping us build the foundation of the product this past summer.

+ +

He did an amazing job of basically recruiting one engineer, Anand, our first engineer who started his career as a PM at Microsoft and then turned into a software engineer at a number of different startups and studied comp sci and electrical engineering at Berkeley with Amit, where they first met.

+ +

And then the second engineer was Nupur, who was a colleague of Amit, a machine learning engineer at Google Brain and the moonshot X team at Alphabet. And they were both, I think, just kind of tired of big tech and were ready to bet on the upside and their career. And the timing was right based on where the market conditions were. And so they decided to take the leap of faith with me.

+ +

And then after that, or around that time, kind of in the middle, we were able to bring on our head of design, Jakub, who is like a unicorn human with so much rich experience in the product world. So he was a computer animator and then studied visual arts, but then started his career very early in the coupon website space as a product designer actually. And then led product design as a founding designer at a number of different startups. And then, most recently, was a senior product designer at Roman, which is a really large digital health company similar to Everlywell.

+ +

And Ro, Everlywell, Truepill, all these companies had mass layoffs in the middle of the summer. And so when Jakub took my call...He talks about a really funny story where he wasn't taking me seriously at all. Convincing these excellent, talented people to come join my dinky startup at the time was not easy.

+ +

WILL: [laughs]

+ +

IRFAN: And so he just kind of took it because there was a mutual connection. Or he just said, okay, I'll explore what's going on given how crazy the market is. But once he heard what we were building, he was immediately on board, actually, because Roman has also struggled with the same customer acquisition problems. And it's a huge reason why a lot of these digital health companies continue to remain unprofitable. And so he understood the problem deeper than I think anyone because of the experience he had in the same space that we were in. And he realized that there was an opportunity to build a solution to solve these problems.

+ +

So that was the first core team. And then from there, it kind of just snowballed, you know, there was more and more interest from other folks to join. And we brought in a great junior product designer. We just hired our platform engineer. But that was the original core team from the summer who took the big leap of faith and joined because of the market conditions, the belief in the space.

+ +

And we actually just met up in San Diego for the first time for a company retreat in person. And it was just fun meeting everyone in person for the first time because now I get to know them as real people and see all their personalities. And we're really psyched about coming to product launch pretty soon here.

+ +

VICTORIA: That's wonderful and, you know, that compelling vision and having those first initial people join and brought in everyone else. You know, I think part of the reason people are hesitant to join startups is because there is that reputation for kind of unhealthy work-life balance. So you're a healthcare startup. So how do you start the culture of your company on a level where there is that balance and people want to join because it has a good culture?

+ +

IRFAN: It's a super interesting question that we spent a lot of time actually talking about in San Diego as a team. And it was brought up because I have a somewhat unhealthy relationship with work. And I am constantly working. And this is the most important thing right now in our life. And so Nupur, one of our engineers, had a phenomenal analogy that I think is the right framework to think about this from a company culture perspective.

+ +

Because I've always tried to share with a team, like, I don't expect them to work nearly as much as I do, and I don't want them to either. I think the analogy was such a fun, helpful way to think about why that was the case. And so she kind of said, "I'm like the aunt, and you're like the single father. And the aunt doesn't have to take care of the baby at nighttime and on the weekends, but the single father does. And it's not that the aunt doesn't care about the company, but there's some space and boundary in that relationship."

+ +

And so that's actually our motto right now is like, yeah, we all care about this product and this company, quote, unquote, "baby," but there's always biologically intrinsically going to be a deeper relationship between me and this company, for good reason. And so that is going to require me to work harder and longer than anyone else, probably for a long, long time. And I had to be ready for that. My wife and I had to be ready for that.

+ +

And so far, honestly, I've never been busier. But I've also never been...or, like, I've never had this ratio between busyness and stress where I'm really busy but not that stressed. And I think it's just because I love what I'm doing every day. I haven't ever found this happy balance where I actually just enjoy what I do. And I'm constantly excited about continuing to build the right product to help people.

+ +

WILL: Wow.

+ +

VICTORIA: I'm actually babysitting my niece and nephew this weekend. [laughter] My brother would say, "You need to be here on the weekends with them."

+ +

IRFAN: Maybe not the perfect analogy. But--

+ +

VICTORIA: I like it, though. It makes sense. [laughs]

+ +

WILL: There's a difference. [laughter]

+ +

VICTORIA: Oh yeah. Will knows; he's a dad.

+ +

WILL: Yeah. I know company values can be so...we have them. Do we follow them? Or sometimes they get put on the shelf. I was reading your company values, "People first, bias for curiosity, and dream big." For Frontrow Health, how does that play a role in the day-to-day?

+ +

IRFAN: When Jakub, Nupur, and Anand had all joined like that first core team, we actually spent time writing all this out and creating a document that discussed what the company culture and values were. And we looked at different examples of other companies. Amazon famously has, I don't know, these 16 principles. And we kind of said, okay, we want to pick just a couple because you can't always focus on everything at the same time. And we need some sort of guiding North Star if you will.

+ +

And so these were the three that we came up with, the ones that you mentioned. So we are people first; we have a bias for curiosity, and we want to dream big. So people first to us means that our mission like we talked about, we want to increase access to healthcare at home for the average American. And so every decision that we make at the company has to pass that litmus test first.

+ +

Whatever feature we're building, whatever business model approach we're taking, whatever go–to–market approach that we're taking, is what we're doing going to increase access to healthcare at home for the average American? Yes? Then we continue onwards, and then we continue deliberating and deciding; if not, we pass. And so that is how we determine whether we can continue to be people first because that is our mission.

+ +

And as we're going down that thread, we want to push ourselves to constantly be bettering and asking questions about how we can be better. That is the bias for curiosity. That was one of Everlywell's company values and was the one that I resonated with the most. I find tremendous value in asking questions. Nupur on our team, one of our engineers, is a great example of bias for curiosity. She's constantly challenging and asking the right questions. And that helps us be better at being people first and increasing access even more than we can because we're never settled with what exists today.

+ +

And then dreaming big is about finding answers to those questions and not settling for the tried and true paths. Some of the greatest companies that have ever been created are the ones that invent new behaviors that have never existed before. So Airbnb, now all of a sudden, people are comfortable with strangers living in their homes. Uber, now all of a sudden, people are comfortable driving in a stranger's car.

+ +

At Frontrow Health, we're dreaming big in a world where doctors are not currently engaging with their patients related to their home health and wellness journeys when they leave the four walls of their clinic. How can we change the behavior where doctors are more involved in that relationship in a way that doesn't exist today? And so that's a part of what we're trying to do, and dreaming big to go and increase access, like I said, is our ultimate North Star.

+ +

WILL: Wow. You said something I think that was...it seemed very small, but I think it said a lot about you and your company. You said that you encourage your engineer to ask the hard questions. I think so many times, people hate the hard questions. They are fearful of that. But I think in your field, you have to be able to ask the hard questions. So that's amazing that you brought that up, and you're talking about that.

+ +

IRFAN: Yeah. And it doesn't...it's not just me, for sure. I think my team is...and it's kind of you to point that out. But yeah, my team does such a great job of holding true to these values on their own and pushing me to remind myself of these values. Nupur actually is Slacking me right now about some thought that she had coming out of a meeting.

+ +

WILL: [laughs]

+ +

IRFAN: And two points about different alternative ways to think about things. And yeah, I want to keep encouraging them and our future employees to do that. Because you look at the worst examples in healthcare, in particular, tech as well, the worst examples of companies are the ones where the employees were not able to or encouraged to ask questions; that's when things go south.

+ +

So Theranos is the simplest example of this where they were hiding everything from their employees, and people had questions constantly but never asked them. And that's when more and more bad decisions were made. So I don't want that to be the case for Frontrow. And so it has to start with, yeah, this bias for curiosity.

+ +

VICTORIA: That makes sense. And I wonder if that's part of your success, being someone who doesn't have a background in engineering or programming specifically and enabling your technical team to build what they need to get done.

+ +

IRFAN: Yeah. I can't honestly explain to you guys how much I've learned over the past six months from my product and dev team. And you're right that I think one could see my lack of programming as a weakness which, in a lot of ways, it is. But what has also manifested as a result of that is I have naturally had to lean more heavily on my dev team to be owners of decisions that affect our business and to challenge them to think about are we being people first if we build and design solutions in the way that you're describing?

+ +

I don't know the right approach about how to build this, or on what tech stack, or in what capacity we have the ability to. You guys have to take ownership of thinking through those, solving those problems, and coming up with the right decision. And as a founder, that's scary to do. You're giving up control of the decisions to others. But at the same time, by giving them that autonomy and encouraging them to take ownership of it, they feel I think more and more invested in what we're building. And that hopefully builds the habit of what you guys were talking about around wanting to constantly seek better solutions, challenge because they know that they have a voice in how things turn out.

+ +

VICTORIA: Right. Maybe you've discovered this naturally or through your education and background. But studies that are done around high-performing technology organizations find that no matter what processes or tools you have if you have that high-trust environment, you'll have better security, more software development throughput, all of those things. So I think you're doing it right by setting your values and creating that kind of high-trust environment.

+ +

IRFAN: Super interesting. I didn't know that, actually, but it makes sense. [laughs] We've been seeing it. I actually want to give some credit to thoughtbot because thoughtbot helped us set a lot of this important engineering culture at the very beginning, where I had to rely on my thoughtbot engineers, folks like Jesse, Dave, and others, to help me make the best decision for my company.

+ +

They taught me a lot of these things at the earliest stage back in May around, okay, like, you guys are a consulting firm at the end of the day, technically speaking. But they pushed me to think of it more as how do we co-make these decisions? Like, how do we leverage each other's strengths to make the right decisions?

+ +

The thoughtbot design team and engineering team...one of our designers through thoughtbot, Steven, is so funny because...and I gave him this feedback, which is great feedback, which is like, he constantly asked questions. And if he hears this, he'll laugh because he's constantly pushing, like, "Why are we designing it this way? Why do you think it should be this way? Where is the evidence that the user wants it to be this way?" And it was a great setup for when our internal team came on because I just kept up that momentum. And then they just kind of took with it and ran.

+ +

VICTORIA: How did you find us, or how did you find the right technical partners in the very beginning to help you build your vision?

+ +

IRFAN: It was not an immediately simple process. But when I found thoughtbot, it kind of unraveled quite quickly in a good way. So I was working with Amit like I mentioned, who'll become our interim CTO, one of my classmates at HBS. And he helped me put together an RFP where we outlined all the different feature requirements, all the different intentions for our solution or timeline, our costs, et cetera.

+ +

And I just did a lot of Google research about different dev shops, and I started talking to dev shops in lots of different locations, U.S.-based, European-based, Asian-based, Latin America-based, started comparing prices. We had questions where we wanted to see their creativity in developing solutions. We started accepting proposals, reviewing those proposals.

+ +

I somehow stumbled upon thoughtbot's website during this process. And I noticed that Everlywell was one of thoughtbot's clients, Everlywell, the home lab testing company that I used to work at before business school. I was like, oh wow. I knew that our engineering team and our engineering leadership had a really high bar for when we worked with outsourced talent. And so I thought that that spoke volumes about choosing thoughtbot.

+ +

And so then we actually ended up asking Everlywell CTO an unprompted question of like, "If you had to pick any dev house that you've known or have worked with, et cetera, that was supposed to build you custom software from scratch, who would you pick?" And he said, "thoughtbot." It wasn't even like a question of, what do you think of thoughtbot? Or, what was your experience? It was just like, imagine you had to pick, and, unprompted, he said thoughtbot. So that was actually what did it for me.

+ +

And I kind of threw aside all the other logistical hoopla that we were going through and said, you know, I got to trust the people who I know and trust, and having verbal confirmation of that was huge. And then, of course, I enjoyed speaking with Dawn at thoughtbot, who was helping broker the whole discussion, and it felt easy. And their proposal was also quite strong. And then, as I dug deeper into thoughtbot, it became clear that no pun intended, you guys are kind of the thought leaders in a lot of ways.

+ +

WILL: [laughs]

+ +

IRFAN: It's funny, our head of design, Jakub, when I mentioned that he's a unicorn, it's because he also taught himself coding and programming.

+ +

WILL: Wow.

+ +

IRFAN: So he's like a pseudo designer and programmer. He can do a little bit of everything. And he actually...when I told him that we were working with thoughtbot, he was like, "Oh, I learned Ruby on Rails back in the day from thoughtbot with whatever content they had published back in time." And then, as I spoke to other dev shops about going with thoughtbot, they started saying things like, "Oh, thoughtbot, yeah, they're kind of the OGs of Rails and a lot of the core tech stack that's been around for a while." And so it was just continued validation of the right approach.

+ +

And then, we started working with the team in May, right after my second semester of business school ended. And it's been an incredible process. We have never missed any deadlines, and we're actually two months ahead of schedule. And it's not just because they're good at what they do, but it's also because of the culture and the teaching me about the best way to run retros, and sprint planning, and things to think about in terms of trust in your engineer and building that trust, and all the soft, intangible things. It wasn't just like thoughtbot came in and built code. It was thoughtbot came in and helped establish the company in a lot of ways.

+ +

VICTORIA: That's great to hear. Thank you for saying all those wonderful things. I'm sure me and Will agree 100%.

+ +

[laughter]

+ +

IRFAN: Yeah, it's been an awesome process. And yeah, we've even ended up basically bringing on as a full-time independent contractor someone who worked through thoughtbot because we love them so much. And they were just so excellent at what they did. And just, yeah, I think that probably speaks the most volumes about the kind of organization that you guys are running.

+ +

WILL: I appreciate you saying that. That means a lot. It really does. I want to take a second to kind of circle back and kind of talk about how you find the providers because I think, for me, one of the most influential classes I had in college was my professor said, "Hey, meet me at the pharmacy." So we went to the pharmacy, and he started asking us questions. And he was like, "What medicine do you think would be the most impactful?" And we would try to pull it out. He taught us how to compare the active ingredients.

+ +

IRFAN: Wow.

+ +

WILL: Like how some stuff is just marketing, and it's not really helpful and things like that. But I also saw the side, you know, the amazing providers like your parents. You talking about your parents just reminded me of my parents and how supportive they are. So it's just amazing. You had your parents as providers. How did you find providers beyond that that you have to extend that trust to them?

+ +

IRFAN: I guess two reactions. The first is how do we talk to doctors to get feedback on our solution as we're building it? And then how do we get doctors to sign up and use our solution with their patients? Those are the two chronological steps. So for the first one, we very liberally use a platform called usertesting.com, which we used at Everlywell, where I first got introduced to it. And it's amazing.

+ +

We have the unlimited package, and we run tons of user tests a day. So, over the summer, we were literally having unmoderated tests from medical professionals, about ten healthcare professionals a day who were coming to our website, coming to our product, giving their feedback through these unmoderated tests. We were quantitatively assessing qualitatively assessing their responses to specific questions that we were asking them.

+ +

Like, was it easy enough to write a review? What were you expecting to see? How did that compare to what you did see? Like, all the traditional kind of user research. They really helped us build the product, and then we were able to follow up with them, get on the phone with them, ask them more questions about their experience, about their current experience in their clinic, whether patients are asking them about these things, about their interest in certain supplements, et cetera.

+ +

And then we actually had one medical provider, a family practice nurse practitioner from Vermont, who was so excited about what we were building. She was sending me all this other information and content about how to reach out to other doctors and stuff. And then, at the end of the summer, when we were just about ready to start getting our beta off the ground, we were going to choose one provider to work with who was going to recommend it to their patients, and they were going to slowly kind of monitor the experience.

+ +

This nurse practitioner actually just happened to reach back out, and we happened to connect again. And she's like, "Okay, what are you guys up to? Are you guys done with your product? I really want to use it." And I was like, "Oh, wow. Well, it's great timing because we're looking for our first medical provider."

+ +

WILL: [laughs]

+ +

IRFAN: And so that's where we ended up launching beta with, which was awesome. And since then, I've been spending a lot of time thinking about the go-to-market approach beyond just one medical provider. How do we scale to thousands of medical providers? And luckily, selling to doctors is a solved problem, like; the biopharma and medical device industry has been doing this for decades.

+ +

And so it was really just a part of me brushing up on a lot of the work that I was doing in life science consulting about helping Big Pharma and whatnot go to market and just stealing a lot of notes out of their playbook. So, for example, there are companies that allow you to run ads online that just target physicians. So instead of my dad seeing a Lululemon ad while he's reading The Wall Street Journal, he'll see an ad for Frontrow Health.

+ +

And so we actually run marketing tests over the summer, towards the end of the summer, with a newer provider landing page that we had built to see what percent were going to click on the ads, what percent were going to come to the website and sign up, and then how much cost would that be per acquisition of a provider. And the results were actually much better than we thought. It was half as expensive as what we originally predicted, which is awesome.

+ +

WILL: Wow.

+ +

IRFAN: And that was before Jakub, our new head of design, had even touched the website. We're actually just revamping it right now because he's been going through and revamping other aspects of our product and marketing experience. And now we're at the provider part. So we're actually going to be just about a week or so away from launching the marketing tests and actually getting every day more providers on the platform.

+ +

The product is now done, so they can start getting their patients on the platform. We just signed our first health brand. So now people are getting real product recommendations and getting ability to earn cashback. And we can be revenue generating, which is also super exciting that we're, like I said, a couple of months ahead of schedule, actually.

+ +

VICTORIA: That's really exciting, and that certainly sounds like enough on your plate. But is there anything else on the horizon for Frontrow Health that you're excited about?

+ +

IRFAN: Yes. We are super excited that we're just coming out of stealth mode and launching our full product experience for consumers, medical providers, and DTC health brands. Going forward into 2023, we're really looking to try to find this quote, unquote, "product market fit." Are doctors excited about signing up and getting their patients on the platform? Are those patients excited about the products that we're selling on our marketplace? And are we delivering new lifetime customers for these health brands at a more cost-effective rate than they've ever seen before? And solving that original problem that came to me while I was at Everlywell.

+ +

And by doing all three of those things, hopefully, we'll begin to increase access to healthcare at home where people who are not suburban high-income folks who can afford to pay out of pocket for preventative healthcare; we can now make that more equitable by bringing down the cost through the cashback, by introducing the element of trust, by engaging with a medical provider, and by opening up people's eyes to thousands of different consumer health and wellness companies that now exist in the world that we want to be able to connect the right products to the right people with.

+ +

VICTORIA: That's so exciting. I'm really glad we got a chance to talk to you today and hear more about your story. Is there anything else that you want to add before we wrap up?

+ +

IRFAN: This has been super fun being able to even just reflect and think about our whole story. For anyone else listening who's interested or excited about entrepreneurship, there's a really good book that I read last summer as I started thinking about entrepreneurship for the first time called "The Hard Thing About Hard Things" written by Ben Horowitz, who co-founded the VC fund, Andreessen Horowitz. He was an entrepreneur himself.

+ +

And it's one of my favorite books because, as the title [laughs] explains, it just talks about the difficulty of the experience and the journey that's still ahead of me. But I think the overall takeaway of the book and my experience over the past year is that it's just the single greatest learning experience of my life.

+ +

And that's actually really all I'm trying to optimize for personally is I want to keep growing and learning, and learning about the space, learning about myself, learning about how to work on a team, how to lead a team, how to grow a team. And if you're at all interested in any of those things, keep trying to think about all the right problems that are being experienced in the world. And we still live in a world wrought with problems and don't have nearly enough founders trying to go and solve all of them.

+ +

VICTORIA: That's a really great perspective, I think, to bring to it about your own personal growth. And that's what it's really all about. [laughs] And hopefully, we're able to solve some big challenging problems along the way.

+ +

IRFAN: Hope so.

+ +

WILL: You can subscribe to this show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

WILL: You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

WILL: Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Irfan Alam.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Irfan Alam is the CEO of Frontrow Health, a startup with a mission to finally put Americans in the front row of their own healthcare.

+ +

Will and Victoria talk to Irfan about his background in business strategy and development for healthcare companies, how he went about searching for and building the perfect team, and how he started the culture of Frontrow Health on a level where there is balance and people want to join because it has a good culture.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Irfan Alam, Founder, and CEO at Frontrow Health, a startup with a mission to finally put Americans in the front row of their own healthcare.

+ +

WILL: Hi, Irfan. Thank you for joining us.

+ +

IRFAN: Thanks for having me; super excited to chat more about the whole process of building and launching Frontrow Health.

+ +

VICTORIA: Yes, we're super excited. Of course, I know you as a client of thoughtbot, and I'm excited to hear your story. And you have this background in business strategy and development for healthcare companies. But what led you to decide to start your own platform?

+ +

IRFAN: I think it was a combination of two things; one was a lived experience being inspired by the power of entrepreneurship with my family and then working at Everlywell. And then two, it was discovering and being reminded of a critical problem that I saw in the industry that I then became excited about solving.

+ +

So growing up, I was raised by my two parents and my grandparents. My grandfather was an entrepreneur himself and also an immigrant and kind of brought our whole legacy of my family into the U.S. from Southeast Asia. He has always motivated me to take risks and to build something great for the world, and that's what he's always wanted for me.

+ +

And so I joined Everlywell, a small digital health startup, back in 2019 because I was excited to get my feet wet in the world of startups. It was just within a number of months after that I had joined where COVID-19 hit, and Everlywell, a home lab testing company based out of Austin, got swept up into the storm of COVID and, in a lot of ways, threw ourselves into the center of the storm when we ended up launching the first home COVID-19 test.

+ +

And it was that summer of 2020 when I probably had the most profound personal and professional growing experience of my life, just trying to handle this chaos and confusing world that we were all living in. But then also simultaneously watching how a small team could make an outsized impact in the world during a time of need. And that really led me to want to pursue my own startup ambitions.

+ +

So I started thinking about business school. The founder and CEO, Julia Cheek, went to Harvard Business School in 2009 and publicly talks about it being sort of this magical moment in time where people were flooding in from the downturn economy, excited about solving new problems. And her class of graduates is sort of like a famous class of entrepreneurs. And so I brought it up with her, and she was super supportive. And I went through the process and got super lucky. And I decided to take the summer off in 2021 before coming to HBS and moving back to Boston.

+ +

And it was during that summer where I started thinking about the problems that companies like Everlywell and direct-to-consumer health brands faced that I realized was not just at the fault of their own but because the industry didn't have the right digital tools necessary to succeed. That's sort of the origin of how Frontrow Health came to be.

+ +

WILL: Sweet. So perfect segue; tell us more about the mission of Frontrow Health.

+ +

IRFAN: We're on a mission to put people on the front row of their own healthcare. And we really just want to reimagine how people shop for their healthcare online. What I learned at Everlywell was that this boom of consumer health which means people who are taking charge of their own health and are able to do that directly through these digital health companies was a form of healthcare that could create a tremendous amount of value in people's lives. But that was only really accessible to a small niche audience. And it didn't feel like it was equitably accessible to the average American.

+ +

And so some of those barriers that I realized as a part of my work at Everlywell for why the average American wasn't engaging with consumer health, this otherwise really powerful form of taking charge of your own health and wellness, was because of these three blockers that we're trying to address at Frontrow Health. The first being that people just don't know about what kinds of solutions are out there that can address their health issues beyond just taking a prescription medication given to them by the doctor that they visit in their office.

+ +

The second is if they do know, they don't know what to trust. They don't know whether this spam of healthcare companies that they're getting advertisements on from Instagram are the right companies, whether these products are safe and effective for them uniquely because of their unique health issues their unique health history.

+ +

And then finally, even if they are aware and they do trust the health product, at the end of the day, a lot of Americans just can't afford to spend money out of pocket to pay for these consumer health and wellness products like consumables, devices, virtual services, et cetera. And so Frontrow Health is all about trying to break down those barriers in order to unleash consumer health to the average American.

+ +

VICTORIA: And were you always drawn to that healthcare industry from the beginning?

+ +

IRFAN: Yeah. So I grew up very privileged with two parents who are physicians. My mom is a psychiatrist, which is quite rare for women of color, specifically of South Asian descent, to be a psychiatrist. And then my dad was a gastroenterologist. They were always the gut-brain connection between the two. And so, growing up, I somewhat classically assumed that I was going to be a doctor. Got to college, thought that that was going to be my path. I realized quickly that there is a whole world outside of being a physician yourself that I could still be a part of in healthcare without being a doctor.

+ +

My parents actually, interestingly enough, began to encourage me to think beyond just being a doctor, with them both feeling like the amount of scale of impact that they could have would never be the same as someone who could do that through business or policy or these other facets that are important to healthcare. And so I got to undergrad, started studying policy economics. I started doing internships at different healthcare consulting firms.

+ +

And I ended up first working at a life science business strategy consulting firm out of college. And it was great, but it ended up not being what I was most excited about because it was really focused on the biopharmaceutical and medical device industry. And what I realized when I got there was I just had this growing passion for digital health and technology, as I saw that it was kind of the future of how people were going to be able to take more preventative charge and improve their health over the long term.

+ +

And so I was working on this digital health white paper with a partner at the consulting firm I was at, and I was doing research and stumbled upon Everlywell. And then, they had a job opening for this business strategy role. So that's why I ended up taking the leap into the startup world, into the digital health world, and just loved it and kept wanting to continue to grow my experience in that space.

+ +

WILL: That's amazing. Your parents encouraged you to step outside of just the doctor-physician role and to think higher. So, as a founder, you know, it was amazing that your parents, as physicians, encouraged you to think higher and think into different roles. And as a founder, what were some of the decisions you had to make? What were some of the easier ones? What were some that were surprisingly difficult?

+ +

IRFAN: I think the biggest misnomer of the founding experience is that founding a company is extremely linear. Sometimes you go one direction forward, and then you take a direction diagonally back, and then you go horizontally straight, and that was my story. When I do my pitch about Frontrow, I try to make it feel a little bit more linear, so it makes sense to people.

+ +

But the truth is the quote, unquote, "hardest decisions" were about every time there was a direction changing point, and it required a decision about is this the right idea? Do I want to spend more time on another idea? Have I validated this enough? Should I validate it differently? Should I pursue this one further? What does that pursuit look like? Who should I pursue it with? Is it time to raise money? Do I drop out of school? Like, those direction-changing points that then create this much more complex map of the founder experience versus a linear line up into the right is, I think, the more challenging parts of being a founder.

+ +

VICTORIA: That makes a lot of sense that you have to really go through this iterative process to figure out where are you spending your time, is it in the right place? A lot of hard decisions to make. And while you were founding Frontrow Health, you were also a part-time investor at Rock Health and reviewing other healthcare startup proposals. So did you see any trends or patterns that influenced how you progressed as a founder?

+ +

IRFAN: Totally, yeah. That was actually instrumental to Frontrow Health. So the story is when I took the summer off before business school, I started thinking about different problems in the world, healthcare, and non-healthcare. Or actually, to be clear, I started thinking about lots of different solutions and ideas and then quickly began to realize that that was not the right approach to founding. I think the first step is to think about problems, problems you've seen, problems you've experienced, that you know others are experiencing, and then work to a solution from there by starting with what the user is experiencing.

+ +

And so as I was going through that hacky journey over the summer, just randomly, a number of small healthcare companies started reaching out to me asking me for my opinion and advice about how or whether they should go direct-to-consumer, whether they should sell healthcare products direct to the consumer, which is what I did a lot of work on at Everlywell as one of the pioneering consumer health brands in the space.

+ +

And I started to notice this trend of me telling these companies, "No, don't do it. It's really expensive. It's really ineffective and unprofitable to acquire customers through traditional paid media avenues like Instagram, TikTok, Snapchat, Facebook, et cetera." And, unsurprisingly, you could imagine Everlywell was trying to sell a home diabetes test for people who are type 2 diabetics but were only able to target people based on their interest in yoga and running, which is not really a substitute for a severe chronic condition.

+ +

And as a result, thousands of people would see our ads every day that had no clinical relevance to our solution. And that was one of the deep problems of why consumer health companies weren't able to reach out to the audiences that actually really needed their solutions. And so when I got to Rock Health at the first semester in business school, doing this sort of part-time investor gig, on the first day, the partners basically told me, "Oh, we don't invest in consumer health."

+ +

And I was like, "Oh, whoa, okay, that's my jam. That's a bummer. That's like [laughs] the only thing that I know about." And as I started to see the data and the pipeline of companies that were looking for investments and understanding what their unit economics looked like, what their go-to-market approaches looked like, that's when I started to put the dots together that this was not just an Everlywell problem; this was an industry problem. Mark Zuckerberg didn't build Facebook so that direct-to-consumer healthcare companies can cost-effectively target clinically relevant patients online. That just happens to be what it's being used for today. And so that's when I started to realize that there had to be a quote-unquote, "better way."

+ +

WILL: You bring up social media at Frontrow Health. Have you had to combat the medical advice of social media?

+ +

IRFAN: Yeah. You mean like this concept of quote, unquote, "Instagram medicine?"

+ +

WILL: Yes. Yes.

+ +

IRFAN: It's a great question. So as the story continues, I began to think about what is the right solution to this problem? And instead of Everlywell, I started thinking about the right solution to this problem. What I realized was instead of Everlywell wasting away millions of dollars to big tech companies that wasn't going to improving the health of anybody, what if we gave that money back to the consumer in reward for sharing their health information which would allow us to target them with the right clinically relevant products?

+ +

That was the first version of Frontrow Health. I called it Health Mart back then. And so I basically started to get people to fill out a Google Form with their health data. And then I worked with my parents to send weekly product recommendations over email based on their unique health needs; you know, I want to sleep better; I'm a diabetic, whatever it is.

+ +

And then, I wanted to see if I was just going to Venmo them cashback upon purchase if they were going to be any more likely to buy these products for these health brands. And at first, people were incrementally more likely to buy. It wasn't mind-blowing. And so, as I started to talk to the participants of the study, I started saying, "You know, you said that you have high cholesterol. These supplements have active ingredients that have been shown to reduce LDL levels. It's pretty cheap. I'm giving you 25-30% cashback. Why haven't you bought it?"

+ +

And what they started saying was, "Well, I don't know what these active ingredients are. And before I put that in my body, I want to check with my doctor first." And so that was the final aha moment that led us to Frontrow Health, which is, what if we could bring the doctor into the fold? And instead of consumers just experiencing this Instagram medicine where they're just being blasted with Instagram ads every day about different health products, and they don't know what to trust, that second barrier that I talked about earlier, what if the doctor could instead of just being a guide for what prescription medications you should be taking could also be a guide on what health and wellness products you can be using?

+ +

And so I added my dad to the email thread, and I said, "Okay, you can talk to an independent medical provider and ask them questions about the products that you're being recommended." And that's when people started buying because then they were able to find the trust in the products that were being curated based on their unique information.

+ +

WILL: Wow, that's really neat. So to help the audience understand your iteration today, so the first iteration was just giving products and then Venmoing them back cashback. And then the second was bringing in a provider. So what does the product look like today?

+ +

IRFAN: We went through, like you mentioned, a lot of different iterations of this. There were even prior iterations to this that are more representative of that founder map versus the linear line that you've sort of just heard now. But in terms of where the story went from there, I began to think about how to validate this idea further. I came into winter break; the pilot went well. People were buying a lot of products.

+ +

And so, I decided to sunset my part-time investor gig at Rock Health and decided to reallocate all my time to working on Health Mart at the time. What I started to think about was, well, what if the doctor was able to earn compensation for writing private product reviews regardless of their opinions? So that was the next iteration was like, how do you incentivize a doctor to take time out of their day to do this new behavior that doesn't exist?

+ +

Doctors are not writing personalized private product reviews for their patients on supplements, home medical devices, apps, et cetera. And how could we get them to? And so, I started thinking about what are the different motivations of providers? Their time is extremely valuable. How do you incentivize them correctly without incentivizing them to give good or bad feedback but just honest feedback?

+ +

Then I started basically having my dad recommend Health Mart to his patients every day to see would patients sign up. Like, if doctors were intrinsically motivated to get their patients on the platform so that they can help them get away from Instagram medicine and at the same time earn compensation for themselves as an additional revenue stream, could independent medical providers see that as valuable and a good use of their time?

+ +

And the first piece of that about whether patients would sign up worked unsurprisingly very well. If your doctor is telling you to sign up for something, or it's free to sign up, and you only pay when you want to buy a product, and they're going to, for the user, be able to ask for feedback from the provider, they were pretty excited.

+ +

But then the question of would doctors sign up, I started...basically, I had my mom. The next iteration was I had my mom make a couple of posts in these doctor Facebook groups. I put together a little website, a very ugly version of what we have today for a provider marketing page. And I had my mom drop the link in a couple of different doctor Facebook groups. And we actually started getting signups from the doctors.

+ +

And then, as we started talking to them, what we realized was two things; it was like a win-win. The doctor was happy because they were getting compensated, and they were happy because their patients' health was improving. So when Obama was in administration, he passed a really fundamentally important piece of legislation called The Sunshine Act. And that basically ended this quote, unquote, "golden era" of pharma companies giving kickbacks to doctors.

+ +

WILL: Oh wow.

+ +

IRFAN: And so since then, doctors have been very eager to find additional revenue streams that they can leverage their decades of medical expertise to earn. They got medical bills to pay off loans to pay off. They spent 20 years training for this job. And so they were excited about an additional revenue stream that leveraged their medical expertise and also helped their patient. Because they also started saying things like, "Well, my patients are always asking me like, 'What about these supplements I saw for these ads online?'" And the doctor says, "I don't know what these supplements are.

+ +

WILL: [laughs]

+ +

IRFAN: I don't have the data in front of me. I don't know what the ingredients are. I don't know whether to trust the company or not." And we are building a platform where it's all streamlined for the provider. The provider is able to review the clinical information. They're able to review their patient information. They're able to really quickly write reviews. We give them templates. We give them suggestions. They're able to reapply recent reviews. And so that was sort of the next iteration. And that's actually when thoughtbot came in and when I started thinking about raising a small round, getting a dev shop to help me build the MVP. And that's kind of how the semester ended up closing out.

+ +

VICTORIA: I love that your mom and dad were so supportive, it sounds like, of you going full-time on this startup. Was that scary for them for you to do that?

+ +

IRFAN: It's so funny, yeah. So what happened next was I decided I wanted to start raising a small round because I had the conviction that there was a problem to be solved for consumers, for doctors, and for health brands. And we could build this one unique multi-sided marketplace to solve them. I ended up going back to Austin for spring break partially to visit my family and partially because I wanted to pitch to Julia, the founder of Everlywell, who I thought of all people on planet Earth would understand what I'm trying to do. She would get it because I am building a SaaS solution for health brands like Everlywell and her consumers.

+ +

And she got it. She was jazzed. And so, she decided to angel invest. And that basically spurred a ton of interest from venture capital firms. I wasn't originally thinking about raising an institutional round but was very lucky with the timing. Just before the market crashed, it was a very hot market. And so we ended up closing a real seed round with the question on hand about whether I should pursue this full-time because the capital that I raised necessitated building a real team. Or should I just take a smaller amount of money and go back to school?

+ +

And it's unsurprisingly, every different person in my life had some opinion about this, from my wife to my investors, to my parents, to my friends. What I wanted was somewhere nestled in between all of those things. And when I caught my dad up on the phone a couple of weeks after spring break and told him of all the crazy stuff that had been happening...and it was just happening and unfolding so quickly. I was like, "Okay, dad. I'm laying out all my cards here. You have full liberty to be mad at me for wanting to drop out of Harvard."

+ +

And his first reaction was, "Well, you know, I don't really see the downside. Like, you could either start a company that you're really passionate about and it could go well, or you could be the worst entrepreneur of all time and then just come back to school during this leave of absence," or deferral thing that I'm on right now. And that was the first time where I was like, "Oh, you know what? I think you're right." And the truth was I decided to just continue to let the summer go by to think about the decision a little bit more before I formally submitted my deferral to HBS.

+ +

As the markets turned, we realized that we needed to hire internally to save on cash burn a little bit. And so once I had built this really awesome team that I'm so lucky to be surrounded by, that's when I was, you know, without a doubt in my mind, I was like, I got to keep pushing for this because now we have this awesome team that just wants to keep driving this mission forward. And we were getting traction. We were talking to hundreds of doctors over the summer. We were talking to health brands. And it really felt like we were onto something.

+ +

MID-ROLL AD:

+ +

thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program.

+ +

We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. That's T-B-O-T.I-OVICTORIA: I-N-C-U-B-A-T-O-R.

+ +

WILL: I hear you have an amazing product team. How did you go about searching and building the right team?

+ +

IRFAN: We got lucky in a second way because of timing, where the first time was I raised the capital when the market was really hot in April. And then, I started hiring when the market crashed. And, unfortunately, as you all know, lots of people have been getting laid off since the summer, particularly in the tech world: designers, engineers, marketers, et cetera.

+ +

Now, all of a sudden, there was a flood of really great talent on the market. And that was also what spurred me to start thinking about hiring sooner than I was originally planning to. My forecast was to hire people end of this year, maybe in a month or so from now, to start that process. Versus, we ended up making our first full-time hire, I guess in July, maybe.

+ +

And it was...the best way I can describe it is like dominoes falling where once you get the first one in, then it builds trust and credibility, and then the next one comes, and the next one. And so the first couple of folks were these two brilliant engineers who were close friends of my interim CTO and classmate, Amit, who was helping us build the foundation of the product this past summer.

+ +

He did an amazing job of basically recruiting one engineer, Anand, our first engineer who started his career as a PM at Microsoft and then turned into a software engineer at a number of different startups and studied comp sci and electrical engineering at Berkeley with Amit, where they first met.

+ +

And then the second engineer was Nupur, who was a colleague of Amit, a machine learning engineer at Google Brain and the moonshot X team at Alphabet. And they were both, I think, just kind of tired of big tech and were ready to bet on the upside and their career. And the timing was right based on where the market conditions were. And so they decided to take the leap of faith with me.

+ +

And then after that, or around that time, kind of in the middle, we were able to bring on our head of design, Jakub, who is like a unicorn human with so much rich experience in the product world. So he was a computer animator and then studied visual arts, but then started his career very early in the coupon website space as a product designer actually. And then led product design as a founding designer at a number of different startups. And then, most recently, was a senior product designer at Roman, which is a really large digital health company similar to Everlywell.

+ +

And Ro, Everlywell, Truepill, all these companies had mass layoffs in the middle of the summer. And so when Jakub took my call...He talks about a really funny story where he wasn't taking me seriously at all. Convincing these excellent, talented people to come join my dinky startup at the time was not easy.

+ +

WILL: [laughs]

+ +

IRFAN: And so he just kind of took it because there was a mutual connection. Or he just said, okay, I'll explore what's going on given how crazy the market is. But once he heard what we were building, he was immediately on board, actually, because Roman has also struggled with the same customer acquisition problems. And it's a huge reason why a lot of these digital health companies continue to remain unprofitable. And so he understood the problem deeper than I think anyone because of the experience he had in the same space that we were in. And he realized that there was an opportunity to build a solution to solve these problems.

+ +

So that was the first core team. And then from there, it kind of just snowballed, you know, there was more and more interest from other folks to join. And we brought in a great junior product designer. We just hired our platform engineer. But that was the original core team from the summer who took the big leap of faith and joined because of the market conditions, the belief in the space.

+ +

And we actually just met up in San Diego for the first time for a company retreat in person. And it was just fun meeting everyone in person for the first time because now I get to know them as real people and see all their personalities. And we're really psyched about coming to product launch pretty soon here.

+ +

VICTORIA: That's wonderful and, you know, that compelling vision and having those first initial people join and brought in everyone else. You know, I think part of the reason people are hesitant to join startups is because there is that reputation for kind of unhealthy work-life balance. So you're a healthcare startup. So how do you start the culture of your company on a level where there is that balance and people want to join because it has a good culture?

+ +

IRFAN: It's a super interesting question that we spent a lot of time actually talking about in San Diego as a team. And it was brought up because I have a somewhat unhealthy relationship with work. And I am constantly working. And this is the most important thing right now in our life. And so Nupur, one of our engineers, had a phenomenal analogy that I think is the right framework to think about this from a company culture perspective.

+ +

Because I've always tried to share with a team, like, I don't expect them to work nearly as much as I do, and I don't want them to either. I think the analogy was such a fun, helpful way to think about why that was the case. And so she kind of said, "I'm like the aunt, and you're like the single father. And the aunt doesn't have to take care of the baby at nighttime and on the weekends, but the single father does. And it's not that the aunt doesn't care about the company, but there's some space and boundary in that relationship."

+ +

And so that's actually our motto right now is like, yeah, we all care about this product and this company, quote, unquote, "baby," but there's always biologically intrinsically going to be a deeper relationship between me and this company, for good reason. And so that is going to require me to work harder and longer than anyone else, probably for a long, long time. And I had to be ready for that. My wife and I had to be ready for that.

+ +

And so far, honestly, I've never been busier. But I've also never been...or, like, I've never had this ratio between busyness and stress where I'm really busy but not that stressed. And I think it's just because I love what I'm doing every day. I haven't ever found this happy balance where I actually just enjoy what I do. And I'm constantly excited about continuing to build the right product to help people.

+ +

WILL: Wow.

+ +

VICTORIA: I'm actually babysitting my niece and nephew this weekend. [laughter] My brother would say, "You need to be here on the weekends with them."

+ +

IRFAN: Maybe not the perfect analogy. But--

+ +

VICTORIA: I like it, though. It makes sense. [laughs]

+ +

WILL: There's a difference. [laughter]

+ +

VICTORIA: Oh yeah. Will knows; he's a dad.

+ +

WILL: Yeah. I know company values can be so...we have them. Do we follow them? Or sometimes they get put on the shelf. I was reading your company values, "People first, bias for curiosity, and dream big." For Frontrow Health, how does that play a role in the day-to-day?

+ +

IRFAN: When Jakub, Nupur, and Anand had all joined like that first core team, we actually spent time writing all this out and creating a document that discussed what the company culture and values were. And we looked at different examples of other companies. Amazon famously has, I don't know, these 16 principles. And we kind of said, okay, we want to pick just a couple because you can't always focus on everything at the same time. And we need some sort of guiding North Star if you will.

+ +

And so these were the three that we came up with, the ones that you mentioned. So we are people first; we have a bias for curiosity, and we want to dream big. So people first to us means that our mission like we talked about, we want to increase access to healthcare at home for the average American. And so every decision that we make at the company has to pass that litmus test first.

+ +

Whatever feature we're building, whatever business model approach we're taking, whatever go–to–market approach that we're taking, is what we're doing going to increase access to healthcare at home for the average American? Yes? Then we continue onwards, and then we continue deliberating and deciding; if not, we pass. And so that is how we determine whether we can continue to be people first because that is our mission.

+ +

And as we're going down that thread, we want to push ourselves to constantly be bettering and asking questions about how we can be better. That is the bias for curiosity. That was one of Everlywell's company values and was the one that I resonated with the most. I find tremendous value in asking questions. Nupur on our team, one of our engineers, is a great example of bias for curiosity. She's constantly challenging and asking the right questions. And that helps us be better at being people first and increasing access even more than we can because we're never settled with what exists today.

+ +

And then dreaming big is about finding answers to those questions and not settling for the tried and true paths. Some of the greatest companies that have ever been created are the ones that invent new behaviors that have never existed before. So Airbnb, now all of a sudden, people are comfortable with strangers living in their homes. Uber, now all of a sudden, people are comfortable driving in a stranger's car.

+ +

At Frontrow Health, we're dreaming big in a world where doctors are not currently engaging with their patients related to their home health and wellness journeys when they leave the four walls of their clinic. How can we change the behavior where doctors are more involved in that relationship in a way that doesn't exist today? And so that's a part of what we're trying to do, and dreaming big to go and increase access, like I said, is our ultimate North Star.

+ +

WILL: Wow. You said something I think that was...it seemed very small, but I think it said a lot about you and your company. You said that you encourage your engineer to ask the hard questions. I think so many times, people hate the hard questions. They are fearful of that. But I think in your field, you have to be able to ask the hard questions. So that's amazing that you brought that up, and you're talking about that.

+ +

IRFAN: Yeah. And it doesn't...it's not just me, for sure. I think my team is...and it's kind of you to point that out. But yeah, my team does such a great job of holding true to these values on their own and pushing me to remind myself of these values. Nupur actually is Slacking me right now about some thought that she had coming out of a meeting.

+ +

WILL: [laughs]

+ +

IRFAN: And two points about different alternative ways to think about things. And yeah, I want to keep encouraging them and our future employees to do that. Because you look at the worst examples in healthcare, in particular, tech as well, the worst examples of companies are the ones where the employees were not able to or encouraged to ask questions; that's when things go south.

+ +

So Theranos is the simplest example of this where they were hiding everything from their employees, and people had questions constantly but never asked them. And that's when more and more bad decisions were made. So I don't want that to be the case for Frontrow. And so it has to start with, yeah, this bias for curiosity.

+ +

VICTORIA: That makes sense. And I wonder if that's part of your success, being someone who doesn't have a background in engineering or programming specifically and enabling your technical team to build what they need to get done.

+ +

IRFAN: Yeah. I can't honestly explain to you guys how much I've learned over the past six months from my product and dev team. And you're right that I think one could see my lack of programming as a weakness which, in a lot of ways, it is. But what has also manifested as a result of that is I have naturally had to lean more heavily on my dev team to be owners of decisions that affect our business and to challenge them to think about are we being people first if we build and design solutions in the way that you're describing?

+ +

I don't know the right approach about how to build this, or on what tech stack, or in what capacity we have the ability to. You guys have to take ownership of thinking through those, solving those problems, and coming up with the right decision. And as a founder, that's scary to do. You're giving up control of the decisions to others. But at the same time, by giving them that autonomy and encouraging them to take ownership of it, they feel I think more and more invested in what we're building. And that hopefully builds the habit of what you guys were talking about around wanting to constantly seek better solutions, challenge because they know that they have a voice in how things turn out.

+ +

VICTORIA: Right. Maybe you've discovered this naturally or through your education and background. But studies that are done around high-performing technology organizations find that no matter what processes or tools you have if you have that high-trust environment, you'll have better security, more software development throughput, all of those things. So I think you're doing it right by setting your values and creating that kind of high-trust environment.

+ +

IRFAN: Super interesting. I didn't know that, actually, but it makes sense. [laughs] We've been seeing it. I actually want to give some credit to thoughtbot because thoughtbot helped us set a lot of this important engineering culture at the very beginning, where I had to rely on my thoughtbot engineers, folks like Jesse, Dave, and others, to help me make the best decision for my company.

+ +

They taught me a lot of these things at the earliest stage back in May around, okay, like, you guys are a consulting firm at the end of the day, technically speaking. But they pushed me to think of it more as how do we co-make these decisions? Like, how do we leverage each other's strengths to make the right decisions?

+ +

The thoughtbot design team and engineering team...one of our designers through thoughtbot, Steven, is so funny because...and I gave him this feedback, which is great feedback, which is like, he constantly asked questions. And if he hears this, he'll laugh because he's constantly pushing, like, "Why are we designing it this way? Why do you think it should be this way? Where is the evidence that the user wants it to be this way?" And it was a great setup for when our internal team came on because I just kept up that momentum. And then they just kind of took with it and ran.

+ +

VICTORIA: How did you find us, or how did you find the right technical partners in the very beginning to help you build your vision?

+ +

IRFAN: It was not an immediately simple process. But when I found thoughtbot, it kind of unraveled quite quickly in a good way. So I was working with Amit like I mentioned, who'll become our interim CTO, one of my classmates at HBS. And he helped me put together an RFP where we outlined all the different feature requirements, all the different intentions for our solution or timeline, our costs, et cetera.

+ +

And I just did a lot of Google research about different dev shops, and I started talking to dev shops in lots of different locations, U.S.-based, European-based, Asian-based, Latin America-based, started comparing prices. We had questions where we wanted to see their creativity in developing solutions. We started accepting proposals, reviewing those proposals.

+ +

I somehow stumbled upon thoughtbot's website during this process. And I noticed that Everlywell was one of thoughtbot's clients, Everlywell, the home lab testing company that I used to work at before business school. I was like, oh wow. I knew that our engineering team and our engineering leadership had a really high bar for when we worked with outsourced talent. And so I thought that that spoke volumes about choosing thoughtbot.

+ +

And so then we actually ended up asking Everlywell CTO an unprompted question of like, "If you had to pick any dev house that you've known or have worked with, et cetera, that was supposed to build you custom software from scratch, who would you pick?" And he said, "thoughtbot." It wasn't even like a question of, what do you think of thoughtbot? Or, what was your experience? It was just like, imagine you had to pick, and, unprompted, he said thoughtbot. So that was actually what did it for me.

+ +

And I kind of threw aside all the other logistical hoopla that we were going through and said, you know, I got to trust the people who I know and trust, and having verbal confirmation of that was huge. And then, of course, I enjoyed speaking with Dawn at thoughtbot, who was helping broker the whole discussion, and it felt easy. And their proposal was also quite strong. And then, as I dug deeper into thoughtbot, it became clear that no pun intended, you guys are kind of the thought leaders in a lot of ways.

+ +

WILL: [laughs]

+ +

IRFAN: It's funny, our head of design, Jakub, when I mentioned that he's a unicorn, it's because he also taught himself coding and programming.

+ +

WILL: Wow.

+ +

IRFAN: So he's like a pseudo designer and programmer. He can do a little bit of everything. And he actually...when I told him that we were working with thoughtbot, he was like, "Oh, I learned Ruby on Rails back in the day from thoughtbot with whatever content they had published back in time." And then, as I spoke to other dev shops about going with thoughtbot, they started saying things like, "Oh, thoughtbot, yeah, they're kind of the OGs of Rails and a lot of the core tech stack that's been around for a while." And so it was just continued validation of the right approach.

+ +

And then, we started working with the team in May, right after my second semester of business school ended. And it's been an incredible process. We have never missed any deadlines, and we're actually two months ahead of schedule. And it's not just because they're good at what they do, but it's also because of the culture and the teaching me about the best way to run retros, and sprint planning, and things to think about in terms of trust in your engineer and building that trust, and all the soft, intangible things. It wasn't just like thoughtbot came in and built code. It was thoughtbot came in and helped establish the company in a lot of ways.

+ +

VICTORIA: That's great to hear. Thank you for saying all those wonderful things. I'm sure me and Will agree 100%.

+ +

[laughter]

+ +

IRFAN: Yeah, it's been an awesome process. And yeah, we've even ended up basically bringing on as a full-time independent contractor someone who worked through thoughtbot because we love them so much. And they were just so excellent at what they did. And just, yeah, I think that probably speaks the most volumes about the kind of organization that you guys are running.

+ +

WILL: I appreciate you saying that. That means a lot. It really does. I want to take a second to kind of circle back and kind of talk about how you find the providers because I think, for me, one of the most influential classes I had in college was my professor said, "Hey, meet me at the pharmacy." So we went to the pharmacy, and he started asking us questions. And he was like, "What medicine do you think would be the most impactful?" And we would try to pull it out. He taught us how to compare the active ingredients.

+ +

IRFAN: Wow.

+ +

WILL: Like how some stuff is just marketing, and it's not really helpful and things like that. But I also saw the side, you know, the amazing providers like your parents. You talking about your parents just reminded me of my parents and how supportive they are. So it's just amazing. You had your parents as providers. How did you find providers beyond that that you have to extend that trust to them?

+ +

IRFAN: I guess two reactions. The first is how do we talk to doctors to get feedback on our solution as we're building it? And then how do we get doctors to sign up and use our solution with their patients? Those are the two chronological steps. So for the first one, we very liberally use a platform called usertesting.com, which we used at Everlywell, where I first got introduced to it. And it's amazing.

+ +

We have the unlimited package, and we run tons of user tests a day. So, over the summer, we were literally having unmoderated tests from medical professionals, about ten healthcare professionals a day who were coming to our website, coming to our product, giving their feedback through these unmoderated tests. We were quantitatively assessing qualitatively assessing their responses to specific questions that we were asking them.

+ +

Like, was it easy enough to write a review? What were you expecting to see? How did that compare to what you did see? Like, all the traditional kind of user research. They really helped us build the product, and then we were able to follow up with them, get on the phone with them, ask them more questions about their experience, about their current experience in their clinic, whether patients are asking them about these things, about their interest in certain supplements, et cetera.

+ +

And then we actually had one medical provider, a family practice nurse practitioner from Vermont, who was so excited about what we were building. She was sending me all this other information and content about how to reach out to other doctors and stuff. And then, at the end of the summer, when we were just about ready to start getting our beta off the ground, we were going to choose one provider to work with who was going to recommend it to their patients, and they were going to slowly kind of monitor the experience.

+ +

This nurse practitioner actually just happened to reach back out, and we happened to connect again. And she's like, "Okay, what are you guys up to? Are you guys done with your product? I really want to use it." And I was like, "Oh, wow. Well, it's great timing because we're looking for our first medical provider."

+ +

WILL: [laughs]

+ +

IRFAN: And so that's where we ended up launching beta with, which was awesome. And since then, I've been spending a lot of time thinking about the go-to-market approach beyond just one medical provider. How do we scale to thousands of medical providers? And luckily, selling to doctors is a solved problem, like; the biopharma and medical device industry has been doing this for decades.

+ +

And so it was really just a part of me brushing up on a lot of the work that I was doing in life science consulting about helping Big Pharma and whatnot go to market and just stealing a lot of notes out of their playbook. So, for example, there are companies that allow you to run ads online that just target physicians. So instead of my dad seeing a Lululemon ad while he's reading The Wall Street Journal, he'll see an ad for Frontrow Health.

+ +

And so we actually run marketing tests over the summer, towards the end of the summer, with a newer provider landing page that we had built to see what percent were going to click on the ads, what percent were going to come to the website and sign up, and then how much cost would that be per acquisition of a provider. And the results were actually much better than we thought. It was half as expensive as what we originally predicted, which is awesome.

+ +

WILL: Wow.

+ +

IRFAN: And that was before Jakub, our new head of design, had even touched the website. We're actually just revamping it right now because he's been going through and revamping other aspects of our product and marketing experience. And now we're at the provider part. So we're actually going to be just about a week or so away from launching the marketing tests and actually getting every day more providers on the platform.

+ +

The product is now done, so they can start getting their patients on the platform. We just signed our first health brand. So now people are getting real product recommendations and getting ability to earn cashback. And we can be revenue generating, which is also super exciting that we're, like I said, a couple of months ahead of schedule, actually.

+ +

VICTORIA: That's really exciting, and that certainly sounds like enough on your plate. But is there anything else on the horizon for Frontrow Health that you're excited about?

+ +

IRFAN: Yes. We are super excited that we're just coming out of stealth mode and launching our full product experience for consumers, medical providers, and DTC health brands. Going forward into 2023, we're really looking to try to find this quote, unquote, "product market fit." Are doctors excited about signing up and getting their patients on the platform? Are those patients excited about the products that we're selling on our marketplace? And are we delivering new lifetime customers for these health brands at a more cost-effective rate than they've ever seen before? And solving that original problem that came to me while I was at Everlywell.

+ +

And by doing all three of those things, hopefully, we'll begin to increase access to healthcare at home where people who are not suburban high-income folks who can afford to pay out of pocket for preventative healthcare; we can now make that more equitable by bringing down the cost through the cashback, by introducing the element of trust, by engaging with a medical provider, and by opening up people's eyes to thousands of different consumer health and wellness companies that now exist in the world that we want to be able to connect the right products to the right people with.

+ +

VICTORIA: That's so exciting. I'm really glad we got a chance to talk to you today and hear more about your story. Is there anything else that you want to add before we wrap up?

+ +

IRFAN: This has been super fun being able to even just reflect and think about our whole story. For anyone else listening who's interested or excited about entrepreneurship, there's a really good book that I read last summer as I started thinking about entrepreneurship for the first time called "The Hard Thing About Hard Things" written by Ben Horowitz, who co-founded the VC fund, Andreessen Horowitz. He was an entrepreneur himself.

+ +

And it's one of my favorite books because, as the title [laughs] explains, it just talks about the difficulty of the experience and the journey that's still ahead of me. But I think the overall takeaway of the book and my experience over the past year is that it's just the single greatest learning experience of my life.

+ +

And that's actually really all I'm trying to optimize for personally is I want to keep growing and learning, and learning about the space, learning about myself, learning about how to work on a team, how to lead a team, how to grow a team. And if you're at all interested in any of those things, keep trying to think about all the right problems that are being experienced in the world. And we still live in a world wrought with problems and don't have nearly enough founders trying to go and solve all of them.

+ +

VICTORIA: That's a really great perspective, I think, to bring to it about your own personal growth. And that's what it's really all about. [laughs] And hopefully, we're able to solve some big challenging problems along the way.

+ +

IRFAN: Hope so.

+ +

WILL: You can subscribe to this show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

WILL: You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

WILL: Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Irfan Alam.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8AIfJfC6 + + ]]> + + Will Larry + Victoria Guido + Irfan Alam + + + 459: Adobe Express with Kasha Stewart + https://podcast.thoughtbot.com/459 + 7a4217a3-3fd3-4082-99c4-40f503c263e3 + Thu, 26 Jan 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Kasha Stewart is the Director of Growth Engagement at Adobe Express. + +Victoria talks to Kasha about finding advocates that encourage her to chase problems, getting more women into product development and why it's essential to bring different perspectives into this area, and ways to bring connection between the end users and customers, engineering teams, and the rest of the organization to the business. + 50:41 + no + + + Kasha Stewart is the Director of Growth Engagement at Adobe Express. +Victoria talks to Kasha about finding advocates that encourage her to chase problems, getting more women into product development and why it's essential to bring different perspectives into this area, and ways to bring connection between the end users and customers, engineering teams, and the rest of the organization to the business. +Adobe Express (https://www.adobe.com/express/) +Follow Adobe LinkedIn (https://www.linkedin.com/company/adobe/) or Twitter (https://twitter.com/AdobeExpress). +Follow Kasha Stewart on LinkedIn (https://www.linkedin.com/in/kashastewart/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido and with us today is Kasha Stewart, Director of Growth Engagement at Adobe Express. Kasha, thank you for joining us. +KASHA: Well, thank you for having me. +VICTORIA: Well, I thought I'd start off by asking you to tell me a little bit more about your background and how you found your way to product from starting out in film and video production. +KASHA: I originally started...I have a fine arts background and did a lot of digital story narrative, post-production. Back in the day (I'm going to date myself.), you had to do...it was a very manual process of chroma keying and removing backgrounds, or refining someone's skin, or some type of background. That was where I kind of...it was my bread and butter. I really loved it. It was creative. +Then in 2008, 2009, the housing market crashed, and the recession happened. And I thought, you know, I'm not a homeowner. What does it have to do with me? I'm taking these freelance jobs. I had just finished my grad program. And then all the jobs kind of disappeared. And I was thinking; here I was; I had gone to grad school. I had a really specific skill set. And then everything just poofed overnight, disappeared. And I thought, okay, well, what's more stable? Like, what could I do to secure a little bit more stability in my job, career? +So I started applying for jobs in all these very different tech, like, they wanted people to be what we used to call a preditor, like, a producer and editor, someone that knew how to do this but also knew how to like FTP massive asset files and also knew how to flag something for when things were going wrong. And so I thought, okay, well, let me just apply for one of these. I have some of the skills. I tick the box on some of the requirements. +And there was a job...it was actually on Craigslist. I actually didn't even know if it was a real job or if it was a scam situation, but I applied. It had a very unusual title; I think it was content distribution editor. And I thought, okay, well, this is interesting. And it was for abc.com. And this is about 2010. I applied. They called me. I thought, okay, why is ABC on Craigslist? But never mind, it was a legitimate job. +And I got into what we call content distribution, so understanding content management systems. And I would be the last person that would actually process the content that would then be delivered to Hulu platforms, abc.com, many different affiliates. There were also Verizon mobile deals at this time, where the cell phone carriers had their own television networks that they tried to stand up. +In that process, I started to really learn about licensing, how content is distributed, meta-tagging, and then also the architecture of a CMS. And I just for the life of me couldn't understand why this was built this way. It was a very cumbersome tool. And like clockwork, around 11:00 p.m. at night, it would crash. And if you hadn't saved your metadata on a notepad or in a spreadsheet, you're basically starting over from scratch. +And I remember asking all these questions, and they were like, "Well, it's proprietary software, and it was built in Seattle." And I was like, "Yeah, but did they ever talk to the, you know..." I didn't know the terminology like end user at the time. But they never talked to any of us that were part of this small team that had this really pivotal role of publishing the content. +And I remember asking all these questions. I had a supervisor at the time. And he jokingly said, "Well, you should go into product management since you love to ask questions." I didn't even know what product management was. I was like, well, I'm on a producer's track; that's my goal. I have this film and narrative background. And a role came up internally, and it was for a product specialist. I would say I needed a little bit of convincing to apply. +I had some advocates in HR that saw this role and thought I would be perfect for it. And I was like, I don't know, it has all this data analytics. And what does this have to do with people and storytelling? And they were like, "We think you should apply for it." And I made the transition, which is rare sometimes in corporate and internal transitions. But I did make the transition, and I became a product specialist. +And I kind of dived deep in into understanding consumer products from a front-end experience. So before, it was more from a distribution and back end. And now it was really focusing on the UX flow, the UI. What are the targets? And how do we position the content? And then, what are our consumers saying about the content? So I did open up a whole new world for me. +I went ahead, and I made plenty of mistakes. There were times that I was like, I don't know if I'm for this if this is right for me. And people definitely weren't shy then. They would tell me, "You don't look like a product manager." Or "You don't have that background of CS or data and analytics person." And I totally didn't, and I never sold myself as a false representation. But what I did have was I had this really strong inclination of really understanding from the consumer perspective. +I always took it back to even in my own circle. And I think I'm an early adopter. I love technology. But I also have friends that are still using Yahoo or Hotmail. And I'd be like, "Oh no, you got to try Gmail, or what about Gchat? This thing came out. You have to check it out." And I would think...back when I was building out these products, and this was, to level set, this is around the time of Web 2.0. I would think, oh, well, how would my friend in New York use this? Or how would my mom find her content? Or, how would my brother... +And I think sometimes we get very seduced when you're building something, especially as a product manager, that everything is from your lens and from your perspective. And the data and then also the feedback was telling us that we weren't really hitting it where consumers were. They weren't able to find the content as easily as we hoped. +And from there, I jumped into kind of entertainment streaming platforms, building out architecture, CMS, and then eventually transitioning into growth-led roles and then leadership roles later in my career. And so I've had the pleasure of working for startups like Beachbody, which was a fitness company big in the fitness space but smaller on the digital perspective, all the way to going back to Disney leading a team at Movies Anywhere. And now, I'm leading a growth team at Adobe. +VICTORIA: Wow, thank you so much. That's so interesting. And we have a couple of different tracks we could get into here. One thing I want to note that I thought was interesting is when you got into your new role, what really kind of presented itself to you is that you identified a problem in the UX. Like, you kind of lateral moved, and then you found this problem, then you had advocates who pushed you to go in that direction. And so, if you have advice for people who are looking to make that transition, how do you find those advocates that encourage you to chase the problems that you find? +KASHA: Oh, that's a great question. People ask me this frequently because I think on paper, it is hard. And no one's going to find you in your cubicle...or now a lot of us are working remotely in our houses. So you have to be your best cheerleader and campaign manager. I also think, like, what is it that is on your top three lists? In product, we have nice-to-have, must-haves, and then we kind of prioritize or stack rank our work backwards from that. +So I ask people, "What's the most important thing for your next role?" And then those are the things that you need to either lean in and start to amplify that you're already doing and how you would make a great candidate. I think internal candidates do have an advantage because they know the culture, or they may know the players, or they may see something from a different perspective, but they know what the company's challenges are. +So I would start by first talking to your manager, and you can have a great manager or not-so-great manager, but start there. Show them that, you know, I'm on this track plan, but I really want to be here. Are there things that I can do in my current role that would support that transition? Are there people that you can recommend? And sometimes, you can get traction with your manager, but if you can't, then start to search within your network. +And if there's a product manager who's maybe in your org or actually would be maybe at the same leveling or someone new, start to explain to them, "Hey, I would love to set up a coffee chat, a 15-minute informational just to hear how you did it or what's your perspective?" And constantly, as you're taking notes...people usually like it when they get an opportunity to share their story or talk about themselves. And as you take notes, "Ah, I am actually looking to transition to that. Do you have any advice for me? If you had something in an open role, what would you want from that candidate?" +And so you're constantly planting those seeds of like, I am this candidate, here's why. And product managers and, I think, also hiring managers, we have a room full of distractions. But if something's laid out to me in concise language and it's showing results of like, oh, well, I did this on the content management side, and I think this would be transferable, and here's why. And you don't have to be long-winded. I'm not into people writing dissertations and producing 20-page decks. I don't always have the time to read that, as lovely as it sounds. +Drive in on your skills. How are they relatable or transferable? And then, what are the goals that you've been able to achieve in your current role? And what are you looking to do in your next role? And I think if you start to place yourself there...and definitely get out and start talking to people in your employee resource groups. +And then also, internally, there's always, at some companies, there are HR or employee resource groups that will have at least a blog post on how to transition within the company, and if they don't, search out those people. And it's not an overnight process. I've seen people where it's been a flip of the switch, and they're on a rocket. And I've seen other people where it's taken time, but they've built those rapports with people that started to get to know them outside of their current role. +VICTORIA: That makes a lot of sense. And you're also involved in many professional networks. And so, do you also get a benefit for your career growth from that? +KASHA: Yes. I feel like I never stop learning. As much as there's always something new coming out, I mean like now I'm into the chatbots and AI. And I'm like, okay, here's another thing I got to learn. Let me [laughs] add this to my to-do list. So I never want to take that for granted. +So I feel like the communities kind of keep me, you know, it's a temperature check of what's going on, either from a challenge perspective or what type of new technologies people are integrating into their existing platforms, and how it's actually growing or benefiting them, whether it's from a machine learning and building out recommendation engines that have saved time, and then actually gets smarter. And we're building out algorithms all the way to, you know, what would it be like to have AI enhancements on an existing platform and still help drive that high-value consumer experience? +So I don't take for granted. I also recommend people that, even if you're not in product to, join product communities so that you start to hear the language and you start to see how product managers think and how hiring and leadership think. And LinkedIn is a great resource. I belong to Women in Product, Black Product Managers. There's a slew of Tech Ladies. And I'm always kind of looking. +There are newsletters that I love, Lenny's Newsletter. And I'm always like, oh, that's a nice one. Let me take that away for my team, or, oh, I didn't actually see that. I didn't think about that. I didn't see that playing out with NFTs in that way; hmm, really interesting. Or that TikTok is taking over search. And now I'm like, okay, how can my product that I'm growing from an engagement standpoint also have really strong representation on TikTok in a way that's authentic and users can find us, and we can continue to engage with users that way? +Start small. Find the right community that works for you. There's also Product-Led Growth, Product Alliances. There are so many of them. And I think you just start to kind of join them if you can. Some of them are free, some of them have dues. And they're really worth it. It's a value add. And you never know who's going to be posting in these Slack community groups too. You might see something where they're okay with associate level or okay with someone transitioning, or looking to help someone transition. +And I often mentor and direct some of my mentees in that direction so that they don't feel like they're in the passenger seat of their career and waiting for something to happen. You have to be active in this pursuit. And you also have to be a driver in it. +VICTORIA: Right. I felt that myself in my career. I felt like my network was my number one source of learning like you said. And also, when you're considering a career change, sometimes you don't even know what else is out there or what other types of jobs are out there. [laughs] I love what you said about that. And you also mentioned Women in Product and Black Women in Product. How can we promote those groups more [laughs] as we get more women in product? And why is it important to bring a different perspective into product? +KASHA: Yeah, that's a great question. I mean, I think podcasts like this, you know, letting people know. And then also, when I do a post on LinkedIn, I do the hashtags of all the groups that either I belong to, or I might tag them. One thing that I do when I do start to mentor someone I say "Be active in the community, share your voice. You're going to start to get comfortable." +Product managers have it...it's not a career for the weak, I'll say that. [laughs] And you have to have an opinion, so start small and start promoting yourself in those groups or hearing what people are saying. And even if my company is hiring or someone else, another hiring manager, and it has a post, I'll say, "Oh, did you think about posting this or adding this hashtag to this? This would definitely help give you a different type of candidate and also get more traffic." +And it's important to me because if I think about the world population and how we're changing, and who's showing up, you want that representation of the people that are working on it. They're going to be thinking about it from a different lens that I didn't even realize that that was an issue or oh, wow, we need to really tap into that. Or actually, we should promote this in a different way because we're going to cast a wider net, or we're going to cast a really specific net. With this demo, it can grow by 10x. Versus us thinking very generally and saying, "Well, we're happy with a 2x growth." +So that's why it's important to me. I'm also always balancing, like, do I have enough representation of women? And do I have enough representation of men on the team too? I don't want to go one side too far and then I'm out of balance and I'm just hiring the same people that are like me. It is kind of challenging sometimes because I have to think about what does the team need? What is the team dynamics missing? And who is that person that can bring in or usher in that different perspective? And then also work cohesively with the existing team. +And so that's a lot of balancing act that I do in my current role and really thinking about okay, well, we're serving small businesses. We're serving social entrepreneurs. Has anybody ever done that? We can be very kind of elitist in tech, especially in product of, like, well, I do it this way. I've [laughs] got Discord, and I have all the NFTs that I've ever wanted to collect. And I can hear and listen to all that, and I can geek out. +But then I'm like, if I go back to my friends, they'll be, "Kasha, what are you talking about? Can you speak English to us?" [laughs] And they'll be like, "Can you please calm down?" And I'm like, "Oh, but there's this thing." And then I'm like, well, maybe I need to have someone who is not like me because they're going to be thinking of that person who really just has a simple task they're trying to solve for. They have a limited amount of time, and they also have limited patience. They're not in a place where they want to learn and go on YouTube and watch a tutorial. +They're really just, you know, "Hey, I need to get this birthday card or this invitation out for my kids. And this was a free product that I saw from SEO results, and I'm here." And that's the value in finding that person and then carrying them through a journey. Me, I'm going to be picky. I'm going to probably research. I'm going to look at reviews. I'm going to look at two other competitors that I'm going to start to line up. [laughter] And then you've lost me by that point. You want to get that person, and you want to make it a frictionless experience. +So I do encourage, when I'm building teams, to think about the dynamics, always going for people that are, you know, want to be there and that are really dedicated to the product but also bring a different perspective than I did. And I come from an untraditional background in tech, so I think that's probably why I'm so conscious of this and how we can make these changes. And I think, historically, or the data proves that diverse teams often excel faster and better than traditional teams. +VICTORIA: Right. And teams that are diverse and are in an inclusive environment where they feel like they can bring their authentic selves. +KASHA: Correct. Yeah, it's one thing to have diversity, but then it's also another, you know, the counterbalance of inclusion. And how do you set people up for success that have different backgrounds? And I have a great strong team of rock stars, as I say, but they all are different. They all need different things. They all have different kinds of needs from a coaching or leadership perspective. Some I'm more hands-on, others I'm hands-off. But as a leader, it's being perceptive of that and saying, okay, well, this person likes to run their own ship. I'm going to be here on the sidelines. And this person I'm going to be out front. I'm going to be walking with them side by side. +I don't know why I have all these sports analogies because I was terrible at sports in junior high, in high school. But I always feel like I'm this coach out here with a whistle and a clipboard. And I'm telling them I'm like, okay, I'm going to set this person up. This person is going to happen here. And that's how I look at it from a growth perspective. +When I'm really assessing the roadmap and the backlog and what's going to be our impact, I'm also thinking about, well, how is everybody working cohesively? And is there a way that we can have shared experiences so that that way, oh, we learned from such and such an experiment, and that's going to influence the other half of my team? Or, actually, I'm going to have them focus, or I know that we're going to have too many mobile tests at the end of Q2 because the monetization team is also trying to test something very similar. So it's a constant juggling act in my role. +VICTORIA: Right. I very much relate to that. I was a competitive rock climbing coach a few years ago on top of my full-time job. +KASHA: Oooh. +VICTORIA: And my kids would ask me if I was also a motivational speaker [laughs] because I was always pumping people up while they're climbing. So yeah, I find it fascinating how you think about the needs of your team and your own growth from an individual contributor into a leader. And how do you coach people in your team along that path, like making that transition from being really strong in product to managing a team of product people? +KASHA: Oh, that's a great question. And I love that you're like a rock climbing...I love that. I'm like, [laughs] what we call thumbs. I would just be looking; I mean, just thinking about rock climbing, my hands are probably getting sweaty right now. [laughs] +And for my team, I do have people that they're getting to a senior PM level, and they're like, "What's next?" And I really like to do an assessment of, like, "Well, what do you think is next? And what is really going to help your career growth?" And some of them are like, "Well, I want to do leadership. I want to do this." And I ask, just like I ask in any product question, "What's the why behind that? Is it a financial contribution? Is it a recognition? Or is it that you are really invested in people development?" +Because one thing I do like to preference, especially people that are in early or mid-level careers, is that managing a product versus managing people are two different skill sets. And I didn't even understand that when I started to get into management; I kind of fell into it. I had a leader that exited the company, and it was like, "Oh, gosh, what will we do next?" And I was just like, "I think we should still continue to pursue the roadmap [laughs] is what I would think to do first." +So one of the things I do say is that your work is going to change. I don't PM, and I'm not regularly with the engineering team on a day-to-day basis. And so I will say to the team that first, at certain points, you can balance it. You'll have both where you might own still part of the portfolio, but then you have maybe one or two direct parts. +But as you start to grow, you will start to transition out of the day-to-day or building individual features or initiatives. And I do ask my PMS, are they ready for that? And if they check all the boxes and say that they have a strong why, then I start off by, okay, well, let's see if our team is eligible for an internship. We're going to open up an internship this summer, and instead of this intern reporting to me, they're going to report to you. +What's your onboarding plan? What's your growth strategy for this person? And then, what do you want this person to accomplish at the end of the internship? And it's a baby step for them to kind of get their feet wet on what is it like to lead someone? And then also, what are the challenges? There's always a perfect storm where things go great. +But what about the times when things are not going great, and how do you communicate with that person? What are the nudges that they need to give for them to either redirect them, or what are the things that you need to do to kind of show them the happy path to success? So those are where I start. We have international teams and people onboarding. I work for a huge company, so there are more opportunities there. +But then I will also say if someone wants to drive and be in a leadership role, what are the mentoring opportunities within the company? So, how would you mentor somebody? And what would be your advice? How do you set up a weekly cadence? What are your expectations of this? How should they measure success and goals? All these are things that are going to be transferable when that opportunity comes up. +And then also, too, what is the right situation? Is it a mix of where I'm 50% IC and then I'm, you know, this other 40%-50% of people management? I encourage them to look at opportunities internally, even if I'm at the sacrifice of losing what I call one of my rock stars. I know that it's inevitable for people to grow. And I never want to be the person that held someone back out of jealousy, or fear, or my own insecurities. +And I do have a strong network that when I post something, I get so many candidates. It's almost to the sense of like, wow, this person is greater. Wow, this person...wow, they went to Stanford, and they did this, and now they're transitioning. And I'm like, oh my gosh, they want to work with me. And so that's always very exciting. So I never want to get so trapped in the ideology that the team is only great with these people. +I'm like; the team starts with me and my leadership. So I need to be able to build a team. I need to be able to grow a team. And sometimes, you might have a great talent pool, and other times you don't, and then what do you do in those? I mean, that's what leadership really is. It's not always when you have everybody applying for your job, and you have all this funding, and your P&Ls are going incredible. +It's those times where they come back to you and say, "Yeah, we're not going to get that done this sprint, so you'll just have to figure it out." Or someone's resigning that you didn't see coming. And then you're like, okay, I might have to roll up my sleeves and take over their part of the roadmap just as a stopgap till I have someone. And that's the things that can make or break your leadership. +VICTORIA: Yeah, it's easy when everything is going great. [laughter] +KASHA: Yes. Don't we love that? [laughter] +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: You mentioned a few times, switching more into your approach to product management about the experiments that you run. Sometimes those go great, and sometimes they don't go so great. So can you tell me about a time you ran an experiment, and the results were really different than what you expected, and what did you do from that? +KASHA: Oh gosh, yeah. There are so many. I'm trying to think of what's the best example. Gosh, I'm like, do I go for mobile? No, web. [laughs] Well, I think in growth, a part of your experiment should fail because if they're not failing, that also means to me you're not taking enough risk. And you're taking things that you already know, in some ways, are like low-hanging fruit, and you're very comfortable in it. +And I do encourage my team to take a big risk of how do we start to find something? We recently had something to help users on the AI side. It was a really unique feature. A user uploads an image, and AI automatically spits out templates with this user-generated content. And we were so excited. We were watching the demos, I felt like on replay, you know, as we got out the meaning. +It didn't necessarily do what we thought it would do. And so then we had to take a pause, like, what happened? And one of the things that we learned from the test is that people just didn't understand what they were supposed to do. They didn't understand the process of their workflow. And they also weren't engaged with what the results came back. +So I think that's one thing that, you know, I know there's a lot of chatter in the space about AI taking over and where are we going to be. And I still think we need to have that human perspective, that person that is like, hey, these search results are really not what the consumer is looking for. And yes, it solved a requirement of picture upload output, but the output is not matching what the consumer's needs were. It didn't solve their problem. And we have to constantly continue to filter and refine the algorithm. +So our first output back was not great. But what we learned is that we have to have more variety of the type of output of content and that we also have to do more hand-holding. As much as we think that people are going to dive right in because it's in the press, and it's in TechCrunch and on Verge, that is not our general population. +I can talk to my girlfriend; she's a doctor. And she's like, "Hey, I'm just really trying to do this for my local women physicians network." All this other stuff, she's like, "It's kind of overwhelming to me." And I didn't even see that. I was just like, "Aren't you excited that you have five options? She's like, "No, I just kind of needed the one thing with the squiggly backgrounds [laughs] and the template that I could alter." She's like, "These don't actually really speak to me." +And so we had to come back and re-define the algorithm and also think about less choices for people; as much as we were like, we can randomize it; we can output more types of templates. It's really about finding the cues that the user is giving us to find that right match, and it's not something that I think we're going to get...and knowing from the test, we're not going to get on the first try. We're going to continue to test this, and that's what's going to make it better because we stress-test it. +I mean, in growth, sometimes, I tell my team, like, don't get our hopes up, our hearts set into it because we can spend a lot of time in crafting the experiment and doing the 50% and then the other 50% control and variants, and then when it comes back, they're just not excited, or the consumer just didn't really gravitate or attach to it. +And so then we have to stop, and I think, okay, there's a lesson here. Is it the education? Is it the guidance? Isn't the language that we use? You'd be surprised how one word can throw off someone's context. And they're turned off, or they don't want to do it. Or they like, "Oh, this is kind of cool. Oh, I didn't realize that this was a free service." Or, "Oh, I didn't realize that I could save this, and it's removing the background for me. And then now I have all these options." +Growth is a hard challenge. I mean, we move so fast, which is what I love, but then we're always kind of looking at the data and having to constantly pivot and transition based off of our previous tests. [laughs] Now I'm thinking about a time when I was at Beachbody, and I was so excited because I got to do native app development on mobile platforms, and I'd never done that before. +We were all excited. We had an iOS product that was really strong. And, of course, many of the people that worked in the office were all iOS users. So they weren't even thinking about Android. And we had just missed the mark as a company not really focusing on building out a great Android native app experience. And we were just kind of relying on the mobile web experience. +And I remember thinking like, oh, okay, well, you have something. And then I went into a Facebook community group, and I just saw all the complaints. I saw all the people's frustrations. I saw also all these user-generated hacks. People were sharing what to do when your video stops. And I just was like, oh my gosh, we need to get on this. +And so from that experience, I was able to champion and be one of the people that was like, hey, we need to help drive this. On Android, we need to really, like, this is really a problem. We could set ourselves up for success. And then we can also grow in other markets outside of the U.S. And I remember looking at the first designs, and they were all done by our creators' team, which were iOS users. +So even in that situation, I think of that as more of growth internally versus putting something out user-facing to the consumer. It still was a challenge. Like, how do I influence? How do I show that this is not the right path? How do I show that, hey, we're not using material design or best practices, and this is going to hurt us in the long run? Because people that are on these platforms on Android they're used to seeing things in this manner. And we're presenting it to them in another way, and then now we're wondering why they're confused. +VICTORIA: Right, right. And you mentioned a couple of different tactics to connect to that consumer voice. What other ways do you try to bring that connection between the end user and the customer, to the engineering teams, to the rest of the organization, to the business? +KASHA: I'm very privileged in my organization. We have a really strong user research team as well. As we're doing our experiments, depending on how large or how much time we'll invest into an experiment, we will do a prototype kind of test in a smaller pool, let's say, before we go out to A/B test or have a controlled and variant situation. +And sometimes those are the little things that I can take back, a video, or likes, comments, and send it. I don't even need to wait for it to be polished into a presentation or to a Confluence page, or even in Jira. And I can say to my counterpart, "Hey, Ganesh, do you see this? This is what I'm trying to solve for." And then it's like that aha moment. And I can say, and, you know, and engineers are always delightful. And they'll say, "Well, that's only one data point." And I'm like, "Yes, but it is a significant point. And I think if we tested this more, we will see more people are struggling with this." And how can we change that? What are their solutions? +And I'm really big on collaboration. Product owns kind of the deliverables and the path and is accountable for the results. But this is a joint effort between design, between data and analytics, and engineering. So early on, I present the problem. This is the why; here's kind of our best path. But what do you think? +And that to me and my career has always yielded such a higher result instead of coming from an authoritative or dictatorship of, "Well, this is the way that I've envisioned it. Here's my mocks, here are my wires, and this is why," and then kind of leaving it out to pasture or throwing it over the fence and saying, "Okay, and I need it in a week and a half." +And I've been on both sides of different product teams, and different engineering teams work differently. But I have found that when you get people to buy in, to care, and then also give them that consumer value of that person is frustrated; I mean, that's what was the trigger for me when I went into the Facebook groups. I really didn't have the biggest inclination that we were having such a problem on Android. I was an iOS user. I was happy with the product; I could get my workouts in, or I could find what I was looking for. And then, when I did that, I started screenshotting. And then, I started to share this out in the Slack channel. +And then there are also ways...now we have so many things where you can have bots that will record the feedback if someone says something in the App Store. That's one way to kind of bring it up to people. And then, if you don't have the funding or have an in-house user research, there's always usertesting.com. That is one way that you can start. Even if you work with design, and you guys are a small team, "Hey, I am so committed to this working. But I really would love to run a test." +And then also running a survey after people test or even in product, you know, what did they think about the experience? And if you can't even get that, you can always do thumbs up, thumbs down. [laughs] You can always do is this a four-star experience or a five-star? Would you like to tell us more? +I would say that sometimes we have blindness to surveys and to people asking for our opinions because you just want to get to that thing. But that small sampling of people that do respond, I think, is a way for you to kind of, if you're not sure, think about this directionally. I was leaning more towards this, but, wow, this user research came back, and I think people are going to really appreciate having this extra step. +Which is something like an oxymoron for me because I'm always thinking about, well, what's the easiest path? Or what's the least path of resistance to getting the user into the experience? And then sometimes you're dropping them into a whole new what we call canvas or experience, and they have no idea what to do. +VICTORIA: I liked the way you described your approach or how not to do it was like, just throw things over a wall [laughs] and say, "This is the way." +KASHA: [laughs] Yes. +VICTORIA: One of my questions that I like to ask people who have design and product backgrounds is just what does product design have to do with DevOps? +KASHA: Yeah, so everybody has to have a starting point. And a lot of times, I was definitely a product manager when I was more in the day-to-day, and I see where...in my mind, I like to figure things out on my own. And that way, I like to come with this pretty package of, like, I thought of all the different angles. I thought of the best use case and the worst use case. +And as much as that was delightful for me, I noticed that the people in engineering would kind of check a box too, and they'd be like, okay, done. And then we might get to a certain point, and they would be like, "Oh, well..." one time when I was building something for Beachbody, and, again, it was on Android, and it was the search. And I didn't think anything of it. I was just like, oh yeah, top result, then stack rank alphabetically. +And then I hadn't thought about new content. And I remember thinking, like, why didn't my engineer say this? Because this is something that we do on iOS. And they said, "Well, you never asked us." [laughs] And I was there, you know, "But you work on the product too." And they're like, "Oh yeah, but you run the show. So this is what you wanted, so this is what I coded." +And I just remember feeling like I had egg on my face in a meeting because now we had all this new content coming out, and the search results weren't accommodating for new content. They were accommodating for the existing metadata. And I just remember thinking like, never again. And from a DevOps perspective, I think of there's a lot of change in the industry where we also have product ops people as well. +And I think of it as additional layering; it can be good and bad. I think there are positives and advantages. I think there are always growing points. And I think you have to give what is the ultimate goal? Like, if you do have a DevOps team, are they also early in the iteration? Are they part of the brainstorms? That's how I run my small pod. We have design, analytics, and engineering part of our early brainstorms. +So instead of us kind of holding our ideas in a huddle, we will kind of tee up, let's say, our top five and say, "Hey, directionally, this is the direction that we're going." And we're framing it to the problems that are most important for us to solve. So we don't turn it into a hackathon where people are trying to build a spaceship in a brainstorm. That's not the goal. +The goal is that, hey, we have these particular problems. This is the direction that we want to go in, and this is how we carry it through. And then, what do you guys think? And then we're in a Miro board in real-time. And we put the timer on and then get everybody's opinions. And some product groups I've seen where product team doesn't actually talk to the engineering. They just talk to the technical PM, which then translates out what the actual specs and requirements are. +I haven't been part of that type of org yet in my career. I have been traditionally where it's a one-to-one ratio where if there's a product manager, there's going to be a data and analytics analyst assigned to them. There's going to be an engineer assigned to them. There's also going to be a designer. And that's been my sweet spot. And I've had a lot of gains and tractions for that. +In my mind, ideas can come from anywhere. It doesn't have to start with product, but product is going to be the leader. And I don't want to think of it as a gatekeeping situation. But we're the ones that are going to drive it through with our own cross-functional teams as a partnership. So I hope that answers the question about DevOps; I'm not sure. Sometimes I can get into a little bit of a tangent [laughs] and start talking about my own experience. +VICTORIA: I love talking about it because some product, people will say nothing. [laughter] +KASHA: Oh really? +VICTORIA: And I'm like, no, you're supposed to talk to people. Bring everybody in, and that's the whole philosophy of it. And I like that you mentioned product ops and design ops as well, thinking about how you can automate the process of what you're doing or how the information flows across your team. I'm sure with your designs and end product, and everything is more on the product ops side. +KASHA: And I think having an ops, you know, it does have like one central point of contact. So if you want to think about alleviating steps, or reducing the white noise, or the friction that you may have in the organization, you have one kind of point of contact. And that person will own it, and they'll almost become a mini pod and then distribute the information, which is definitely like a gain and a positive. +I just wonder on the reverse side, though, how does that engineer or how does that designer then surface, "Hey, what about this?" Or "I think this is a better way," or "Actually, we tested this two years ago, and the results weren't great." And so that's the only thing where how does that two way-communication go back and forth when you have ops? +I think ops definitely gives more structure. You're definitely in a high performance. Everybody knows what their marching orders are. We know who's on first. And we also know from an accountability and an escalation process where all these pieces are working together. So I can see the benefits to it. I'm not opposed to it. I just want to make sure that the people that are actually building the product also have time to have a say and have an opinion. +And whether that helps change me, I want to at least hear the feedback first. And then as a product leader and as a product manager, it's up to that person to make the decision of, like, okay, you know what? I've thought about this looking at the data, or this person raised a really significant point that I hadn't considered. I do think that we need to think about this and focus. That's the advantage for me, I feel like, of having that bottoms-up approach to development and then running your teams. +VICTORIA: I think that makes sense. And you're right; I think it can be successful. But I think there's a good warning there about...and people do this with DevOps teams as well where they create a DevOps team and then put them in a silo, right? [laughs] +KASHA: Yeah. +VICTORIA: And that's kind of missing the point about the whole thing. It's like we want to power these people. +KASHA: Yeah, everything new is old again. I remember when I didn't even talk to an engineer. And I remember...and this was early in my product when I had the product specialist. I would be at my cube writing requirements. I thought they were great. And then we switched to an agile format, and I remember going into a meeting thinking, okay, we're just going to go over the stuff that's next. And they had all these questions for me, and it terrified me. [laughter] +Because it made me think, like, maybe I don't know what I'm talking about or, yeah, I didn't think about the error messaging. Oh, okay, yeah, what happens if someone loses internet connection during that session and they've started the process? Oh, I don't know. What should happen? [laughs] And so there were all these kinds of questions. +But before, I would just process my requirements, put it in a Jira ticket. And then you might get some Jira comments, but there wasn't this back-and-forth in real-time. And then, I had to really step up and write my requirements better. Because at that point, I had just had like, oh, this happens in check one. This happens at step two. And then step three, the end. That was my own kind of naive perspective at the time when I was writing requirements. +And I didn't know that the engineers had all these questions because we had that layer of...they didn't call it a DevOps person. I think they called it, you know, an engineering lead where he would just take the tickets, and then they were doing their own sub tickets to make it make sense. And so then, when we started to transition into more of an agile and rating things and giving value to them, I really had to change. +And it helped me grow. And it was definitely uncomfortable. But it definitely pushed me into thinking, okay, someone's reading this. They're an engineer. They're not thinking about this. How can I get as clear as possible but also still think about the consumer or the persona that I'm thinking about that is trying to solve this problem? +VICTORIA: That makes sense. It reminds me of one of my first jobs actually was in Washington, D.C., which you went to undergrad there. I would actually pass by Howard University on the bus every day to work. [laughs] +KASHA: Oh wow. [laughs] +VICTORIA: I wonder, are you familiar with BisonHacks and their annual hackathon that they have there? I know you're from the film department. But the computer science does a hackathon there every year. +KASHA: I am not familiar with that specific one. But I participated; I mean, we have some at Adobe. We have our regular hackathons internally. But I would love to hear more about the one that you're describing. It sounds pretty fascinating. Do they have an ultimate goal? Are they building from an existing product, or is this something new? +VICTORIA: I think it's something new. So I believe that they come together to create solutions to help improve the livelihood of the DMV community. +KASHA: Oh wow. +VICTORIA: So I think every year they make it a different purpose. +KASHA: Okay, I got it. +VICTORIA: But they interact with students and do different projects. And it's a super fun organization. So, yeah, I'll send you a link. We'll share it in the show notes as well. [laughs] +KASHA: Yeah. I love it. I love it. This podcast I'm already growing [laughter] in the short time we've talked, so I love that. +VICTORIA: And we're coming to the end of our time here. I have one final question before I ask you if you have any other final takeaways. [laughs] But what are you most excited about on the roadmap for Adobe Express that you have coming? +KASHA: Well, I'm excited...gosh, what can I share? [laughs] I'm like, I see legal tapping me on the shoulder. [laughs] I'm excited that we are making so many improvements to really simplify the experience and that we're also diversifying our use cases of the types of people that will be coming to the platform. +So when I say that, let's say we've been focused on what we call the social creator, or the small business owner, or hustler, I really want to lean more into that and expand that. We also have more of what we call our pro users coming to Adobe Express. So if you think of someone that's a professional graphic designer that may need something where they need to have a collaborator, we're enhancing that process. +And then also, I'm most excited coming into 2023 is that Adobe's Express is going to be what we think of as the doorway to all the Adobe ecosystem. So whether you start with Express on a small scale and building out a template, you can really grow with this product. And whether you use it for your everyday either social needs or even in your everyday work or marketing, you can start to have people come to the platform and collaborate on it. +We have so many exciting things that it's interesting because my team is focused on activation and repeat engagement, and how do those two worlds kind of marry each other? Getting the user in from having them on a first great day one experience and then carrying them through for when they return. +And one thing that I'm excited for is that we've had this recent pivot, and this came out of user research. We don't have to wait for the user to leave the platform to remind them of all the great things that we can do. And I'm really excited about having machine learning capabilities on the platform; where, if your next step is this, what's the next best available action? And then how does that help enhance not only your experience of the product but then also starting to plant those seeds of you can schedule this in advance or creating this type of content once a week will drive exponentially your growth on your platform? +And that, to me, is making us stronger and really looking at it not only from I want the consumer to do these series of high-value actions, but I really want to see them grow on their own personal platform level. And here's a tool that can help you do everything that you need to. +And whether you're someone that posts once a week, or whether you're someone in an office that is collaborating for a marketing meeting, or if you're a professional that has something that, you know, I just really want to use a template. I have an aesthetic. I know how to use Photoshop. I know how to use Illustrator. But let me put this in Express. I can send it to the client. They can make comments, and then they can also feel like they're part of the creative process. +That makes me happy because I was this fine arts major. It feels like 100 years ago. [laughs] And I remember thinking like, oh wow, I love these products. They're expensive, or saving up for them. And then now there are so many different plans. There are so many different ways. And I would have loved an opportunity to have a free product that allowed me to just start to understand my own type of style and capabilities without having this feeling that I have to be a designer and that everything has to be perfect. So I'm excited for that. +We have so much growth planned, new, exciting ways on the platform. And, also, you'll see some new looks. I can't share too much more than that. [laughter] So I hope the little bit of tidbit doesn't get me in trouble. But sometimes you got to break some rules. You got to break some eggs to make an omelet. +[laughter] +VICTORIA: Any other final thoughts for our listeners today? +KASHA: I would love for, you know, to give me feedback. I always love doing these. I'm active on LinkedIn. You can find me at Kasha Stewart. Shoot me a note. I get a healthy amount of mail, but I promise I will reply back to you if you have questions and what your biggest challenges are. Check out Adobe Express. It's free, by the way. +And continue to, you know; I just remember being this, like, early in my career and having these questions, and at different points, I was afraid to ask questions because I was like, I don't want to sound silly. Or maybe I'm not understanding that, or, you know, maybe I should have been a CS major. And I say to people now, like, you have to have a starting point. You never know what is next on the horizon. Or that everybody had been thinking about that and they were just waiting for the person to raise their hand. That's one of the things that I always want to encourage people and to check out these products, communities. +And thank you to this podcast for allowing me to share my journey and my story. It's always a pleasure. I learned something, and I'm like, oh yeah, I did actually do that. But that was a while ago that; I might forget. So it's good. It's like having my own little mini retro. So I thank you for inviting me here and to, you know, share my journey. +VICTORIA: Well, thank you. That's a very powerful message, and I appreciate you coming on today to share it with us. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thank you for listening. We'll see you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. Special Guest: Kasha Stewart. + + + Kasha Stewart is the Director of Growth Engagement at Adobe Express.

+ +

Victoria talks to Kasha about finding advocates that encourage her to chase problems, getting more women into product development and why it's essential to bring different perspectives into this area, and ways to bring connection between the end users and customers, engineering teams, and the rest of the organization to the business.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido and with us today is Kasha Stewart, Director of Growth Engagement at Adobe Express. Kasha, thank you for joining us.

+ +

KASHA: Well, thank you for having me.

+ +

VICTORIA: Well, I thought I'd start off by asking you to tell me a little bit more about your background and how you found your way to product from starting out in film and video production.

+ +

KASHA: I originally started...I have a fine arts background and did a lot of digital story narrative, post-production. Back in the day (I'm going to date myself.), you had to do...it was a very manual process of chroma keying and removing backgrounds, or refining someone's skin, or some type of background. That was where I kind of...it was my bread and butter. I really loved it. It was creative.

+ +

Then in 2008, 2009, the housing market crashed, and the recession happened. And I thought, you know, I'm not a homeowner. What does it have to do with me? I'm taking these freelance jobs. I had just finished my grad program. And then all the jobs kind of disappeared. And I was thinking; here I was; I had gone to grad school. I had a really specific skill set. And then everything just poofed overnight, disappeared. And I thought, okay, well, what's more stable? Like, what could I do to secure a little bit more stability in my job, career?

+ +

So I started applying for jobs in all these very different tech, like, they wanted people to be what we used to call a preditor, like, a producer and editor, someone that knew how to do this but also knew how to like FTP massive asset files and also knew how to flag something for when things were going wrong. And so I thought, okay, well, let me just apply for one of these. I have some of the skills. I tick the box on some of the requirements.

+ +

And there was a job...it was actually on Craigslist. I actually didn't even know if it was a real job or if it was a scam situation, but I applied. It had a very unusual title; I think it was content distribution editor. And I thought, okay, well, this is interesting. And it was for abc.com. And this is about 2010. I applied. They called me. I thought, okay, why is ABC on Craigslist? But never mind, it was a legitimate job.

+ +

And I got into what we call content distribution, so understanding content management systems. And I would be the last person that would actually process the content that would then be delivered to Hulu platforms, abc.com, many different affiliates. There were also Verizon mobile deals at this time, where the cell phone carriers had their own television networks that they tried to stand up.

+ +

In that process, I started to really learn about licensing, how content is distributed, meta-tagging, and then also the architecture of a CMS. And I just for the life of me couldn't understand why this was built this way. It was a very cumbersome tool. And like clockwork, around 11:00 p.m. at night, it would crash. And if you hadn't saved your metadata on a notepad or in a spreadsheet, you're basically starting over from scratch.

+ +

And I remember asking all these questions, and they were like, "Well, it's proprietary software, and it was built in Seattle." And I was like, "Yeah, but did they ever talk to the, you know..." I didn't know the terminology like end user at the time. But they never talked to any of us that were part of this small team that had this really pivotal role of publishing the content.

+ +

And I remember asking all these questions. I had a supervisor at the time. And he jokingly said, "Well, you should go into product management since you love to ask questions." I didn't even know what product management was. I was like, well, I'm on a producer's track; that's my goal. I have this film and narrative background. And a role came up internally, and it was for a product specialist. I would say I needed a little bit of convincing to apply.

+ +

I had some advocates in HR that saw this role and thought I would be perfect for it. And I was like, I don't know, it has all this data analytics. And what does this have to do with people and storytelling? And they were like, "We think you should apply for it." And I made the transition, which is rare sometimes in corporate and internal transitions. But I did make the transition, and I became a product specialist.

+ +

And I kind of dived deep in into understanding consumer products from a front-end experience. So before, it was more from a distribution and back end. And now it was really focusing on the UX flow, the UI. What are the targets? And how do we position the content? And then, what are our consumers saying about the content? So I did open up a whole new world for me.

+ +

I went ahead, and I made plenty of mistakes. There were times that I was like, I don't know if I'm for this if this is right for me. And people definitely weren't shy then. They would tell me, "You don't look like a product manager." Or "You don't have that background of CS or data and analytics person." And I totally didn't, and I never sold myself as a false representation. But what I did have was I had this really strong inclination of really understanding from the consumer perspective.

+ +

I always took it back to even in my own circle. And I think I'm an early adopter. I love technology. But I also have friends that are still using Yahoo or Hotmail. And I'd be like, "Oh no, you got to try Gmail, or what about Gchat? This thing came out. You have to check it out." And I would think...back when I was building out these products, and this was, to level set, this is around the time of Web 2.0. I would think, oh, well, how would my friend in New York use this? Or how would my mom find her content? Or, how would my brother...

+ +

And I think sometimes we get very seduced when you're building something, especially as a product manager, that everything is from your lens and from your perspective. And the data and then also the feedback was telling us that we weren't really hitting it where consumers were. They weren't able to find the content as easily as we hoped.

+ +

And from there, I jumped into kind of entertainment streaming platforms, building out architecture, CMS, and then eventually transitioning into growth-led roles and then leadership roles later in my career. And so I've had the pleasure of working for startups like Beachbody, which was a fitness company big in the fitness space but smaller on the digital perspective, all the way to going back to Disney leading a team at Movies Anywhere. And now, I'm leading a growth team at Adobe.

+ +

VICTORIA: Wow, thank you so much. That's so interesting. And we have a couple of different tracks we could get into here. One thing I want to note that I thought was interesting is when you got into your new role, what really kind of presented itself to you is that you identified a problem in the UX. Like, you kind of lateral moved, and then you found this problem, then you had advocates who pushed you to go in that direction. And so, if you have advice for people who are looking to make that transition, how do you find those advocates that encourage you to chase the problems that you find?

+ +

KASHA: Oh, that's a great question. People ask me this frequently because I think on paper, it is hard. And no one's going to find you in your cubicle...or now a lot of us are working remotely in our houses. So you have to be your best cheerleader and campaign manager. I also think, like, what is it that is on your top three lists? In product, we have nice-to-have, must-haves, and then we kind of prioritize or stack rank our work backwards from that.

+ +

So I ask people, "What's the most important thing for your next role?" And then those are the things that you need to either lean in and start to amplify that you're already doing and how you would make a great candidate. I think internal candidates do have an advantage because they know the culture, or they may know the players, or they may see something from a different perspective, but they know what the company's challenges are.

+ +

So I would start by first talking to your manager, and you can have a great manager or not-so-great manager, but start there. Show them that, you know, I'm on this track plan, but I really want to be here. Are there things that I can do in my current role that would support that transition? Are there people that you can recommend? And sometimes, you can get traction with your manager, but if you can't, then start to search within your network.

+ +

And if there's a product manager who's maybe in your org or actually would be maybe at the same leveling or someone new, start to explain to them, "Hey, I would love to set up a coffee chat, a 15-minute informational just to hear how you did it or what's your perspective?" And constantly, as you're taking notes...people usually like it when they get an opportunity to share their story or talk about themselves. And as you take notes, "Ah, I am actually looking to transition to that. Do you have any advice for me? If you had something in an open role, what would you want from that candidate?"

+ +

And so you're constantly planting those seeds of like, I am this candidate, here's why. And product managers and, I think, also hiring managers, we have a room full of distractions. But if something's laid out to me in concise language and it's showing results of like, oh, well, I did this on the content management side, and I think this would be transferable, and here's why. And you don't have to be long-winded. I'm not into people writing dissertations and producing 20-page decks. I don't always have the time to read that, as lovely as it sounds.

+ +

Drive in on your skills. How are they relatable or transferable? And then, what are the goals that you've been able to achieve in your current role? And what are you looking to do in your next role? And I think if you start to place yourself there...and definitely get out and start talking to people in your employee resource groups.

+ +

And then also, internally, there's always, at some companies, there are HR or employee resource groups that will have at least a blog post on how to transition within the company, and if they don't, search out those people. And it's not an overnight process. I've seen people where it's been a flip of the switch, and they're on a rocket. And I've seen other people where it's taken time, but they've built those rapports with people that started to get to know them outside of their current role.

+ +

VICTORIA: That makes a lot of sense. And you're also involved in many professional networks. And so, do you also get a benefit for your career growth from that?

+ +

KASHA: Yes. I feel like I never stop learning. As much as there's always something new coming out, I mean like now I'm into the chatbots and AI. And I'm like, okay, here's another thing I got to learn. Let me [laughs] add this to my to-do list. So I never want to take that for granted.

+ +

So I feel like the communities kind of keep me, you know, it's a temperature check of what's going on, either from a challenge perspective or what type of new technologies people are integrating into their existing platforms, and how it's actually growing or benefiting them, whether it's from a machine learning and building out recommendation engines that have saved time, and then actually gets smarter. And we're building out algorithms all the way to, you know, what would it be like to have AI enhancements on an existing platform and still help drive that high-value consumer experience?

+ +

So I don't take for granted. I also recommend people that, even if you're not in product to, join product communities so that you start to hear the language and you start to see how product managers think and how hiring and leadership think. And LinkedIn is a great resource. I belong to Women in Product, Black Product Managers. There's a slew of Tech Ladies. And I'm always kind of looking.

+ +

There are newsletters that I love, Lenny's Newsletter. And I'm always like, oh, that's a nice one. Let me take that away for my team, or, oh, I didn't actually see that. I didn't think about that. I didn't see that playing out with NFTs in that way; hmm, really interesting. Or that TikTok is taking over search. And now I'm like, okay, how can my product that I'm growing from an engagement standpoint also have really strong representation on TikTok in a way that's authentic and users can find us, and we can continue to engage with users that way?

+ +

Start small. Find the right community that works for you. There's also Product-Led Growth, Product Alliances. There are so many of them. And I think you just start to kind of join them if you can. Some of them are free, some of them have dues. And they're really worth it. It's a value add. And you never know who's going to be posting in these Slack community groups too. You might see something where they're okay with associate level or okay with someone transitioning, or looking to help someone transition.

+ +

And I often mentor and direct some of my mentees in that direction so that they don't feel like they're in the passenger seat of their career and waiting for something to happen. You have to be active in this pursuit. And you also have to be a driver in it.

+ +

VICTORIA: Right. I felt that myself in my career. I felt like my network was my number one source of learning like you said. And also, when you're considering a career change, sometimes you don't even know what else is out there or what other types of jobs are out there. [laughs] I love what you said about that. And you also mentioned Women in Product and Black Women in Product. How can we promote those groups more [laughs] as we get more women in product? And why is it important to bring a different perspective into product?

+ +

KASHA: Yeah, that's a great question. I mean, I think podcasts like this, you know, letting people know. And then also, when I do a post on LinkedIn, I do the hashtags of all the groups that either I belong to, or I might tag them. One thing that I do when I do start to mentor someone I say "Be active in the community, share your voice. You're going to start to get comfortable."

+ +

Product managers have it...it's not a career for the weak, I'll say that. [laughs] And you have to have an opinion, so start small and start promoting yourself in those groups or hearing what people are saying. And even if my company is hiring or someone else, another hiring manager, and it has a post, I'll say, "Oh, did you think about posting this or adding this hashtag to this? This would definitely help give you a different type of candidate and also get more traffic."

+ +

And it's important to me because if I think about the world population and how we're changing, and who's showing up, you want that representation of the people that are working on it. They're going to be thinking about it from a different lens that I didn't even realize that that was an issue or oh, wow, we need to really tap into that. Or actually, we should promote this in a different way because we're going to cast a wider net, or we're going to cast a really specific net. With this demo, it can grow by 10x. Versus us thinking very generally and saying, "Well, we're happy with a 2x growth."

+ +

So that's why it's important to me. I'm also always balancing, like, do I have enough representation of women? And do I have enough representation of men on the team too? I don't want to go one side too far and then I'm out of balance and I'm just hiring the same people that are like me. It is kind of challenging sometimes because I have to think about what does the team need? What is the team dynamics missing? And who is that person that can bring in or usher in that different perspective? And then also work cohesively with the existing team.

+ +

And so that's a lot of balancing act that I do in my current role and really thinking about okay, well, we're serving small businesses. We're serving social entrepreneurs. Has anybody ever done that? We can be very kind of elitist in tech, especially in product of, like, well, I do it this way. I've [laughs] got Discord, and I have all the NFTs that I've ever wanted to collect. And I can hear and listen to all that, and I can geek out.

+ +

But then I'm like, if I go back to my friends, they'll be, "Kasha, what are you talking about? Can you speak English to us?" [laughs] And they'll be like, "Can you please calm down?" And I'm like, "Oh, but there's this thing." And then I'm like, well, maybe I need to have someone who is not like me because they're going to be thinking of that person who really just has a simple task they're trying to solve for. They have a limited amount of time, and they also have limited patience. They're not in a place where they want to learn and go on YouTube and watch a tutorial.

+ +

They're really just, you know, "Hey, I need to get this birthday card or this invitation out for my kids. And this was a free product that I saw from SEO results, and I'm here." And that's the value in finding that person and then carrying them through a journey. Me, I'm going to be picky. I'm going to probably research. I'm going to look at reviews. I'm going to look at two other competitors that I'm going to start to line up. [laughter] And then you've lost me by that point. You want to get that person, and you want to make it a frictionless experience.

+ +

So I do encourage, when I'm building teams, to think about the dynamics, always going for people that are, you know, want to be there and that are really dedicated to the product but also bring a different perspective than I did. And I come from an untraditional background in tech, so I think that's probably why I'm so conscious of this and how we can make these changes. And I think, historically, or the data proves that diverse teams often excel faster and better than traditional teams.

+ +

VICTORIA: Right. And teams that are diverse and are in an inclusive environment where they feel like they can bring their authentic selves.

+ +

KASHA: Correct. Yeah, it's one thing to have diversity, but then it's also another, you know, the counterbalance of inclusion. And how do you set people up for success that have different backgrounds? And I have a great strong team of rock stars, as I say, but they all are different. They all need different things. They all have different kinds of needs from a coaching or leadership perspective. Some I'm more hands-on, others I'm hands-off. But as a leader, it's being perceptive of that and saying, okay, well, this person likes to run their own ship. I'm going to be here on the sidelines. And this person I'm going to be out front. I'm going to be walking with them side by side.

+ +

I don't know why I have all these sports analogies because I was terrible at sports in junior high, in high school. But I always feel like I'm this coach out here with a whistle and a clipboard. And I'm telling them I'm like, okay, I'm going to set this person up. This person is going to happen here. And that's how I look at it from a growth perspective.

+ +

When I'm really assessing the roadmap and the backlog and what's going to be our impact, I'm also thinking about, well, how is everybody working cohesively? And is there a way that we can have shared experiences so that that way, oh, we learned from such and such an experiment, and that's going to influence the other half of my team? Or, actually, I'm going to have them focus, or I know that we're going to have too many mobile tests at the end of Q2 because the monetization team is also trying to test something very similar. So it's a constant juggling act in my role.

+ +

VICTORIA: Right. I very much relate to that. I was a competitive rock climbing coach a few years ago on top of my full-time job.

+ +

KASHA: Oooh.

+ +

VICTORIA: And my kids would ask me if I was also a motivational speaker [laughs] because I was always pumping people up while they're climbing. So yeah, I find it fascinating how you think about the needs of your team and your own growth from an individual contributor into a leader. And how do you coach people in your team along that path, like making that transition from being really strong in product to managing a team of product people?

+ +

KASHA: Oh, that's a great question. And I love that you're like a rock climbing...I love that. I'm like, [laughs] what we call thumbs. I would just be looking; I mean, just thinking about rock climbing, my hands are probably getting sweaty right now. [laughs]

+ +

And for my team, I do have people that they're getting to a senior PM level, and they're like, "What's next?" And I really like to do an assessment of, like, "Well, what do you think is next? And what is really going to help your career growth?" And some of them are like, "Well, I want to do leadership. I want to do this." And I ask, just like I ask in any product question, "What's the why behind that? Is it a financial contribution? Is it a recognition? Or is it that you are really invested in people development?"

+ +

Because one thing I do like to preference, especially people that are in early or mid-level careers, is that managing a product versus managing people are two different skill sets. And I didn't even understand that when I started to get into management; I kind of fell into it. I had a leader that exited the company, and it was like, "Oh, gosh, what will we do next?" And I was just like, "I think we should still continue to pursue the roadmap [laughs] is what I would think to do first."

+ +

So one of the things I do say is that your work is going to change. I don't PM, and I'm not regularly with the engineering team on a day-to-day basis. And so I will say to the team that first, at certain points, you can balance it. You'll have both where you might own still part of the portfolio, but then you have maybe one or two direct parts.

+ +

But as you start to grow, you will start to transition out of the day-to-day or building individual features or initiatives. And I do ask my PMS, are they ready for that? And if they check all the boxes and say that they have a strong why, then I start off by, okay, well, let's see if our team is eligible for an internship. We're going to open up an internship this summer, and instead of this intern reporting to me, they're going to report to you.

+ +

What's your onboarding plan? What's your growth strategy for this person? And then, what do you want this person to accomplish at the end of the internship? And it's a baby step for them to kind of get their feet wet on what is it like to lead someone? And then also, what are the challenges? There's always a perfect storm where things go great.

+ +

But what about the times when things are not going great, and how do you communicate with that person? What are the nudges that they need to give for them to either redirect them, or what are the things that you need to do to kind of show them the happy path to success? So those are where I start. We have international teams and people onboarding. I work for a huge company, so there are more opportunities there.

+ +

But then I will also say if someone wants to drive and be in a leadership role, what are the mentoring opportunities within the company? So, how would you mentor somebody? And what would be your advice? How do you set up a weekly cadence? What are your expectations of this? How should they measure success and goals? All these are things that are going to be transferable when that opportunity comes up.

+ +

And then also, too, what is the right situation? Is it a mix of where I'm 50% IC and then I'm, you know, this other 40%-50% of people management? I encourage them to look at opportunities internally, even if I'm at the sacrifice of losing what I call one of my rock stars. I know that it's inevitable for people to grow. And I never want to be the person that held someone back out of jealousy, or fear, or my own insecurities.

+ +

And I do have a strong network that when I post something, I get so many candidates. It's almost to the sense of like, wow, this person is greater. Wow, this person...wow, they went to Stanford, and they did this, and now they're transitioning. And I'm like, oh my gosh, they want to work with me. And so that's always very exciting. So I never want to get so trapped in the ideology that the team is only great with these people.

+ +

I'm like; the team starts with me and my leadership. So I need to be able to build a team. I need to be able to grow a team. And sometimes, you might have a great talent pool, and other times you don't, and then what do you do in those? I mean, that's what leadership really is. It's not always when you have everybody applying for your job, and you have all this funding, and your P&Ls are going incredible.

+ +

It's those times where they come back to you and say, "Yeah, we're not going to get that done this sprint, so you'll just have to figure it out." Or someone's resigning that you didn't see coming. And then you're like, okay, I might have to roll up my sleeves and take over their part of the roadmap just as a stopgap till I have someone. And that's the things that can make or break your leadership.

+ +

VICTORIA: Yeah, it's easy when everything is going great. [laughter]

+ +

KASHA: Yes. Don't we love that? [laughter]

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: You mentioned a few times, switching more into your approach to product management about the experiments that you run. Sometimes those go great, and sometimes they don't go so great. So can you tell me about a time you ran an experiment, and the results were really different than what you expected, and what did you do from that?

+ +

KASHA: Oh gosh, yeah. There are so many. I'm trying to think of what's the best example. Gosh, I'm like, do I go for mobile? No, web. [laughs] Well, I think in growth, a part of your experiment should fail because if they're not failing, that also means to me you're not taking enough risk. And you're taking things that you already know, in some ways, are like low-hanging fruit, and you're very comfortable in it.

+ +

And I do encourage my team to take a big risk of how do we start to find something? We recently had something to help users on the AI side. It was a really unique feature. A user uploads an image, and AI automatically spits out templates with this user-generated content. And we were so excited. We were watching the demos, I felt like on replay, you know, as we got out the meaning.

+ +

It didn't necessarily do what we thought it would do. And so then we had to take a pause, like, what happened? And one of the things that we learned from the test is that people just didn't understand what they were supposed to do. They didn't understand the process of their workflow. And they also weren't engaged with what the results came back.

+ +

So I think that's one thing that, you know, I know there's a lot of chatter in the space about AI taking over and where are we going to be. And I still think we need to have that human perspective, that person that is like, hey, these search results are really not what the consumer is looking for. And yes, it solved a requirement of picture upload output, but the output is not matching what the consumer's needs were. It didn't solve their problem. And we have to constantly continue to filter and refine the algorithm.

+ +

So our first output back was not great. But what we learned is that we have to have more variety of the type of output of content and that we also have to do more hand-holding. As much as we think that people are going to dive right in because it's in the press, and it's in TechCrunch and on Verge, that is not our general population.

+ +

I can talk to my girlfriend; she's a doctor. And she's like, "Hey, I'm just really trying to do this for my local women physicians network." All this other stuff, she's like, "It's kind of overwhelming to me." And I didn't even see that. I was just like, "Aren't you excited that you have five options? She's like, "No, I just kind of needed the one thing with the squiggly backgrounds [laughs] and the template that I could alter." She's like, "These don't actually really speak to me."

+ +

And so we had to come back and re-define the algorithm and also think about less choices for people; as much as we were like, we can randomize it; we can output more types of templates. It's really about finding the cues that the user is giving us to find that right match, and it's not something that I think we're going to get...and knowing from the test, we're not going to get on the first try. We're going to continue to test this, and that's what's going to make it better because we stress-test it.

+ +

I mean, in growth, sometimes, I tell my team, like, don't get our hopes up, our hearts set into it because we can spend a lot of time in crafting the experiment and doing the 50% and then the other 50% control and variants, and then when it comes back, they're just not excited, or the consumer just didn't really gravitate or attach to it.

+ +

And so then we have to stop, and I think, okay, there's a lesson here. Is it the education? Is it the guidance? Isn't the language that we use? You'd be surprised how one word can throw off someone's context. And they're turned off, or they don't want to do it. Or they like, "Oh, this is kind of cool. Oh, I didn't realize that this was a free service." Or, "Oh, I didn't realize that I could save this, and it's removing the background for me. And then now I have all these options."

+ +

Growth is a hard challenge. I mean, we move so fast, which is what I love, but then we're always kind of looking at the data and having to constantly pivot and transition based off of our previous tests. [laughs] Now I'm thinking about a time when I was at Beachbody, and I was so excited because I got to do native app development on mobile platforms, and I'd never done that before.

+ +

We were all excited. We had an iOS product that was really strong. And, of course, many of the people that worked in the office were all iOS users. So they weren't even thinking about Android. And we had just missed the mark as a company not really focusing on building out a great Android native app experience. And we were just kind of relying on the mobile web experience.

+ +

And I remember thinking like, oh, okay, well, you have something. And then I went into a Facebook community group, and I just saw all the complaints. I saw all the people's frustrations. I saw also all these user-generated hacks. People were sharing what to do when your video stops. And I just was like, oh my gosh, we need to get on this.

+ +

And so from that experience, I was able to champion and be one of the people that was like, hey, we need to help drive this. On Android, we need to really, like, this is really a problem. We could set ourselves up for success. And then we can also grow in other markets outside of the U.S. And I remember looking at the first designs, and they were all done by our creators' team, which were iOS users.

+ +

So even in that situation, I think of that as more of growth internally versus putting something out user-facing to the consumer. It still was a challenge. Like, how do I influence? How do I show that this is not the right path? How do I show that, hey, we're not using material design or best practices, and this is going to hurt us in the long run? Because people that are on these platforms on Android they're used to seeing things in this manner. And we're presenting it to them in another way, and then now we're wondering why they're confused.

+ +

VICTORIA: Right, right. And you mentioned a couple of different tactics to connect to that consumer voice. What other ways do you try to bring that connection between the end user and the customer, to the engineering teams, to the rest of the organization, to the business?

+ +

KASHA: I'm very privileged in my organization. We have a really strong user research team as well. As we're doing our experiments, depending on how large or how much time we'll invest into an experiment, we will do a prototype kind of test in a smaller pool, let's say, before we go out to A/B test or have a controlled and variant situation.

+ +

And sometimes those are the little things that I can take back, a video, or likes, comments, and send it. I don't even need to wait for it to be polished into a presentation or to a Confluence page, or even in Jira. And I can say to my counterpart, "Hey, Ganesh, do you see this? This is what I'm trying to solve for." And then it's like that aha moment. And I can say, and, you know, and engineers are always delightful. And they'll say, "Well, that's only one data point." And I'm like, "Yes, but it is a significant point. And I think if we tested this more, we will see more people are struggling with this." And how can we change that? What are their solutions?

+ +

And I'm really big on collaboration. Product owns kind of the deliverables and the path and is accountable for the results. But this is a joint effort between design, between data and analytics, and engineering. So early on, I present the problem. This is the why; here's kind of our best path. But what do you think?

+ +

And that to me and my career has always yielded such a higher result instead of coming from an authoritative or dictatorship of, "Well, this is the way that I've envisioned it. Here's my mocks, here are my wires, and this is why," and then kind of leaving it out to pasture or throwing it over the fence and saying, "Okay, and I need it in a week and a half."

+ +

And I've been on both sides of different product teams, and different engineering teams work differently. But I have found that when you get people to buy in, to care, and then also give them that consumer value of that person is frustrated; I mean, that's what was the trigger for me when I went into the Facebook groups. I really didn't have the biggest inclination that we were having such a problem on Android. I was an iOS user. I was happy with the product; I could get my workouts in, or I could find what I was looking for. And then, when I did that, I started screenshotting. And then, I started to share this out in the Slack channel.

+ +

And then there are also ways...now we have so many things where you can have bots that will record the feedback if someone says something in the App Store. That's one way to kind of bring it up to people. And then, if you don't have the funding or have an in-house user research, there's always usertesting.com. That is one way that you can start. Even if you work with design, and you guys are a small team, "Hey, I am so committed to this working. But I really would love to run a test."

+ +

And then also running a survey after people test or even in product, you know, what did they think about the experience? And if you can't even get that, you can always do thumbs up, thumbs down. [laughs] You can always do is this a four-star experience or a five-star? Would you like to tell us more?

+ +

I would say that sometimes we have blindness to surveys and to people asking for our opinions because you just want to get to that thing. But that small sampling of people that do respond, I think, is a way for you to kind of, if you're not sure, think about this directionally. I was leaning more towards this, but, wow, this user research came back, and I think people are going to really appreciate having this extra step.

+ +

Which is something like an oxymoron for me because I'm always thinking about, well, what's the easiest path? Or what's the least path of resistance to getting the user into the experience? And then sometimes you're dropping them into a whole new what we call canvas or experience, and they have no idea what to do.

+ +

VICTORIA: I liked the way you described your approach or how not to do it was like, just throw things over a wall [laughs] and say, "This is the way."

+ +

KASHA: [laughs] Yes.

+ +

VICTORIA: One of my questions that I like to ask people who have design and product backgrounds is just what does product design have to do with DevOps?

+ +

KASHA: Yeah, so everybody has to have a starting point. And a lot of times, I was definitely a product manager when I was more in the day-to-day, and I see where...in my mind, I like to figure things out on my own. And that way, I like to come with this pretty package of, like, I thought of all the different angles. I thought of the best use case and the worst use case.

+ +

And as much as that was delightful for me, I noticed that the people in engineering would kind of check a box too, and they'd be like, okay, done. And then we might get to a certain point, and they would be like, "Oh, well..." one time when I was building something for Beachbody, and, again, it was on Android, and it was the search. And I didn't think anything of it. I was just like, oh yeah, top result, then stack rank alphabetically.

+ +

And then I hadn't thought about new content. And I remember thinking, like, why didn't my engineer say this? Because this is something that we do on iOS. And they said, "Well, you never asked us." [laughs] And I was there, you know, "But you work on the product too." And they're like, "Oh yeah, but you run the show. So this is what you wanted, so this is what I coded."

+ +

And I just remember feeling like I had egg on my face in a meeting because now we had all this new content coming out, and the search results weren't accommodating for new content. They were accommodating for the existing metadata. And I just remember thinking like, never again. And from a DevOps perspective, I think of there's a lot of change in the industry where we also have product ops people as well.

+ +

And I think of it as additional layering; it can be good and bad. I think there are positives and advantages. I think there are always growing points. And I think you have to give what is the ultimate goal? Like, if you do have a DevOps team, are they also early in the iteration? Are they part of the brainstorms? That's how I run my small pod. We have design, analytics, and engineering part of our early brainstorms.

+ +

So instead of us kind of holding our ideas in a huddle, we will kind of tee up, let's say, our top five and say, "Hey, directionally, this is the direction that we're going." And we're framing it to the problems that are most important for us to solve. So we don't turn it into a hackathon where people are trying to build a spaceship in a brainstorm. That's not the goal.

+ +

The goal is that, hey, we have these particular problems. This is the direction that we want to go in, and this is how we carry it through. And then, what do you guys think? And then we're in a Miro board in real-time. And we put the timer on and then get everybody's opinions. And some product groups I've seen where product team doesn't actually talk to the engineering. They just talk to the technical PM, which then translates out what the actual specs and requirements are.

+ +

I haven't been part of that type of org yet in my career. I have been traditionally where it's a one-to-one ratio where if there's a product manager, there's going to be a data and analytics analyst assigned to them. There's going to be an engineer assigned to them. There's also going to be a designer. And that's been my sweet spot. And I've had a lot of gains and tractions for that.

+ +

In my mind, ideas can come from anywhere. It doesn't have to start with product, but product is going to be the leader. And I don't want to think of it as a gatekeeping situation. But we're the ones that are going to drive it through with our own cross-functional teams as a partnership. So I hope that answers the question about DevOps; I'm not sure. Sometimes I can get into a little bit of a tangent [laughs] and start talking about my own experience.

+ +

VICTORIA: I love talking about it because some product, people will say nothing. [laughter]

+ +

KASHA: Oh really?

+ +

VICTORIA: And I'm like, no, you're supposed to talk to people. Bring everybody in, and that's the whole philosophy of it. And I like that you mentioned product ops and design ops as well, thinking about how you can automate the process of what you're doing or how the information flows across your team. I'm sure with your designs and end product, and everything is more on the product ops side.

+ +

KASHA: And I think having an ops, you know, it does have like one central point of contact. So if you want to think about alleviating steps, or reducing the white noise, or the friction that you may have in the organization, you have one kind of point of contact. And that person will own it, and they'll almost become a mini pod and then distribute the information, which is definitely like a gain and a positive.

+ +

I just wonder on the reverse side, though, how does that engineer or how does that designer then surface, "Hey, what about this?" Or "I think this is a better way," or "Actually, we tested this two years ago, and the results weren't great." And so that's the only thing where how does that two way-communication go back and forth when you have ops?

+ +

I think ops definitely gives more structure. You're definitely in a high performance. Everybody knows what their marching orders are. We know who's on first. And we also know from an accountability and an escalation process where all these pieces are working together. So I can see the benefits to it. I'm not opposed to it. I just want to make sure that the people that are actually building the product also have time to have a say and have an opinion.

+ +

And whether that helps change me, I want to at least hear the feedback first. And then as a product leader and as a product manager, it's up to that person to make the decision of, like, okay, you know what? I've thought about this looking at the data, or this person raised a really significant point that I hadn't considered. I do think that we need to think about this and focus. That's the advantage for me, I feel like, of having that bottoms-up approach to development and then running your teams.

+ +

VICTORIA: I think that makes sense. And you're right; I think it can be successful. But I think there's a good warning there about...and people do this with DevOps teams as well where they create a DevOps team and then put them in a silo, right? [laughs]

+ +

KASHA: Yeah.

+ +

VICTORIA: And that's kind of missing the point about the whole thing. It's like we want to power these people.

+ +

KASHA: Yeah, everything new is old again. I remember when I didn't even talk to an engineer. And I remember...and this was early in my product when I had the product specialist. I would be at my cube writing requirements. I thought they were great. And then we switched to an agile format, and I remember going into a meeting thinking, okay, we're just going to go over the stuff that's next. And they had all these questions for me, and it terrified me. [laughter]

+ +

Because it made me think, like, maybe I don't know what I'm talking about or, yeah, I didn't think about the error messaging. Oh, okay, yeah, what happens if someone loses internet connection during that session and they've started the process? Oh, I don't know. What should happen? [laughs] And so there were all these kinds of questions.

+ +

But before, I would just process my requirements, put it in a Jira ticket. And then you might get some Jira comments, but there wasn't this back-and-forth in real-time. And then, I had to really step up and write my requirements better. Because at that point, I had just had like, oh, this happens in check one. This happens at step two. And then step three, the end. That was my own kind of naive perspective at the time when I was writing requirements.

+ +

And I didn't know that the engineers had all these questions because we had that layer of...they didn't call it a DevOps person. I think they called it, you know, an engineering lead where he would just take the tickets, and then they were doing their own sub tickets to make it make sense. And so then, when we started to transition into more of an agile and rating things and giving value to them, I really had to change.

+ +

And it helped me grow. And it was definitely uncomfortable. But it definitely pushed me into thinking, okay, someone's reading this. They're an engineer. They're not thinking about this. How can I get as clear as possible but also still think about the consumer or the persona that I'm thinking about that is trying to solve this problem?

+ +

VICTORIA: That makes sense. It reminds me of one of my first jobs actually was in Washington, D.C., which you went to undergrad there. I would actually pass by Howard University on the bus every day to work. [laughs]

+ +

KASHA: Oh wow. [laughs]

+ +

VICTORIA: I wonder, are you familiar with BisonHacks and their annual hackathon that they have there? I know you're from the film department. But the computer science does a hackathon there every year.

+ +

KASHA: I am not familiar with that specific one. But I participated; I mean, we have some at Adobe. We have our regular hackathons internally. But I would love to hear more about the one that you're describing. It sounds pretty fascinating. Do they have an ultimate goal? Are they building from an existing product, or is this something new?

+ +

VICTORIA: I think it's something new. So I believe that they come together to create solutions to help improve the livelihood of the DMV community.

+ +

KASHA: Oh wow.

+ +

VICTORIA: So I think every year they make it a different purpose.

+ +

KASHA: Okay, I got it.

+ +

VICTORIA: But they interact with students and do different projects. And it's a super fun organization. So, yeah, I'll send you a link. We'll share it in the show notes as well. [laughs]

+ +

KASHA: Yeah. I love it. I love it. This podcast I'm already growing [laughter] in the short time we've talked, so I love that.

+ +

VICTORIA: And we're coming to the end of our time here. I have one final question before I ask you if you have any other final takeaways. [laughs] But what are you most excited about on the roadmap for Adobe Express that you have coming?

+ +

KASHA: Well, I'm excited...gosh, what can I share? [laughs] I'm like, I see legal tapping me on the shoulder. [laughs] I'm excited that we are making so many improvements to really simplify the experience and that we're also diversifying our use cases of the types of people that will be coming to the platform.

+ +

So when I say that, let's say we've been focused on what we call the social creator, or the small business owner, or hustler, I really want to lean more into that and expand that. We also have more of what we call our pro users coming to Adobe Express. So if you think of someone that's a professional graphic designer that may need something where they need to have a collaborator, we're enhancing that process.

+ +

And then also, I'm most excited coming into 2023 is that Adobe's Express is going to be what we think of as the doorway to all the Adobe ecosystem. So whether you start with Express on a small scale and building out a template, you can really grow with this product. And whether you use it for your everyday either social needs or even in your everyday work or marketing, you can start to have people come to the platform and collaborate on it.

+ +

We have so many exciting things that it's interesting because my team is focused on activation and repeat engagement, and how do those two worlds kind of marry each other? Getting the user in from having them on a first great day one experience and then carrying them through for when they return.

+ +

And one thing that I'm excited for is that we've had this recent pivot, and this came out of user research. We don't have to wait for the user to leave the platform to remind them of all the great things that we can do. And I'm really excited about having machine learning capabilities on the platform; where, if your next step is this, what's the next best available action? And then how does that help enhance not only your experience of the product but then also starting to plant those seeds of you can schedule this in advance or creating this type of content once a week will drive exponentially your growth on your platform?

+ +

And that, to me, is making us stronger and really looking at it not only from I want the consumer to do these series of high-value actions, but I really want to see them grow on their own personal platform level. And here's a tool that can help you do everything that you need to.

+ +

And whether you're someone that posts once a week, or whether you're someone in an office that is collaborating for a marketing meeting, or if you're a professional that has something that, you know, I just really want to use a template. I have an aesthetic. I know how to use Photoshop. I know how to use Illustrator. But let me put this in Express. I can send it to the client. They can make comments, and then they can also feel like they're part of the creative process.

+ +

That makes me happy because I was this fine arts major. It feels like 100 years ago. [laughs] And I remember thinking like, oh wow, I love these products. They're expensive, or saving up for them. And then now there are so many different plans. There are so many different ways. And I would have loved an opportunity to have a free product that allowed me to just start to understand my own type of style and capabilities without having this feeling that I have to be a designer and that everything has to be perfect. So I'm excited for that.

+ +

We have so much growth planned, new, exciting ways on the platform. And, also, you'll see some new looks. I can't share too much more than that. [laughter] So I hope the little bit of tidbit doesn't get me in trouble. But sometimes you got to break some rules. You got to break some eggs to make an omelet.

+ +

[laughter]

+ +

VICTORIA: Any other final thoughts for our listeners today?

+ +

KASHA: I would love for, you know, to give me feedback. I always love doing these. I'm active on LinkedIn. You can find me at Kasha Stewart. Shoot me a note. I get a healthy amount of mail, but I promise I will reply back to you if you have questions and what your biggest challenges are. Check out Adobe Express. It's free, by the way.

+ +

And continue to, you know; I just remember being this, like, early in my career and having these questions, and at different points, I was afraid to ask questions because I was like, I don't want to sound silly. Or maybe I'm not understanding that, or, you know, maybe I should have been a CS major. And I say to people now, like, you have to have a starting point. You never know what is next on the horizon. Or that everybody had been thinking about that and they were just waiting for the person to raise their hand. That's one of the things that I always want to encourage people and to check out these products, communities.

+ +

And thank you to this podcast for allowing me to share my journey and my story. It's always a pleasure. I learned something, and I'm like, oh yeah, I did actually do that. But that was a while ago that; I might forget. So it's good. It's like having my own little mini retro. So I thank you for inviting me here and to, you know, share my journey.

+ +

VICTORIA: Well, thank you. That's a very powerful message, and I appreciate you coming on today to share it with us.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you for listening. We'll see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Kasha Stewart.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Kasha Stewart is the Director of Growth Engagement at Adobe Express.

+ +

Victoria talks to Kasha about finding advocates that encourage her to chase problems, getting more women into product development and why it's essential to bring different perspectives into this area, and ways to bring connection between the end users and customers, engineering teams, and the rest of the organization to the business.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido and with us today is Kasha Stewart, Director of Growth Engagement at Adobe Express. Kasha, thank you for joining us.

+ +

KASHA: Well, thank you for having me.

+ +

VICTORIA: Well, I thought I'd start off by asking you to tell me a little bit more about your background and how you found your way to product from starting out in film and video production.

+ +

KASHA: I originally started...I have a fine arts background and did a lot of digital story narrative, post-production. Back in the day (I'm going to date myself.), you had to do...it was a very manual process of chroma keying and removing backgrounds, or refining someone's skin, or some type of background. That was where I kind of...it was my bread and butter. I really loved it. It was creative.

+ +

Then in 2008, 2009, the housing market crashed, and the recession happened. And I thought, you know, I'm not a homeowner. What does it have to do with me? I'm taking these freelance jobs. I had just finished my grad program. And then all the jobs kind of disappeared. And I was thinking; here I was; I had gone to grad school. I had a really specific skill set. And then everything just poofed overnight, disappeared. And I thought, okay, well, what's more stable? Like, what could I do to secure a little bit more stability in my job, career?

+ +

So I started applying for jobs in all these very different tech, like, they wanted people to be what we used to call a preditor, like, a producer and editor, someone that knew how to do this but also knew how to like FTP massive asset files and also knew how to flag something for when things were going wrong. And so I thought, okay, well, let me just apply for one of these. I have some of the skills. I tick the box on some of the requirements.

+ +

And there was a job...it was actually on Craigslist. I actually didn't even know if it was a real job or if it was a scam situation, but I applied. It had a very unusual title; I think it was content distribution editor. And I thought, okay, well, this is interesting. And it was for abc.com. And this is about 2010. I applied. They called me. I thought, okay, why is ABC on Craigslist? But never mind, it was a legitimate job.

+ +

And I got into what we call content distribution, so understanding content management systems. And I would be the last person that would actually process the content that would then be delivered to Hulu platforms, abc.com, many different affiliates. There were also Verizon mobile deals at this time, where the cell phone carriers had their own television networks that they tried to stand up.

+ +

In that process, I started to really learn about licensing, how content is distributed, meta-tagging, and then also the architecture of a CMS. And I just for the life of me couldn't understand why this was built this way. It was a very cumbersome tool. And like clockwork, around 11:00 p.m. at night, it would crash. And if you hadn't saved your metadata on a notepad or in a spreadsheet, you're basically starting over from scratch.

+ +

And I remember asking all these questions, and they were like, "Well, it's proprietary software, and it was built in Seattle." And I was like, "Yeah, but did they ever talk to the, you know..." I didn't know the terminology like end user at the time. But they never talked to any of us that were part of this small team that had this really pivotal role of publishing the content.

+ +

And I remember asking all these questions. I had a supervisor at the time. And he jokingly said, "Well, you should go into product management since you love to ask questions." I didn't even know what product management was. I was like, well, I'm on a producer's track; that's my goal. I have this film and narrative background. And a role came up internally, and it was for a product specialist. I would say I needed a little bit of convincing to apply.

+ +

I had some advocates in HR that saw this role and thought I would be perfect for it. And I was like, I don't know, it has all this data analytics. And what does this have to do with people and storytelling? And they were like, "We think you should apply for it." And I made the transition, which is rare sometimes in corporate and internal transitions. But I did make the transition, and I became a product specialist.

+ +

And I kind of dived deep in into understanding consumer products from a front-end experience. So before, it was more from a distribution and back end. And now it was really focusing on the UX flow, the UI. What are the targets? And how do we position the content? And then, what are our consumers saying about the content? So I did open up a whole new world for me.

+ +

I went ahead, and I made plenty of mistakes. There were times that I was like, I don't know if I'm for this if this is right for me. And people definitely weren't shy then. They would tell me, "You don't look like a product manager." Or "You don't have that background of CS or data and analytics person." And I totally didn't, and I never sold myself as a false representation. But what I did have was I had this really strong inclination of really understanding from the consumer perspective.

+ +

I always took it back to even in my own circle. And I think I'm an early adopter. I love technology. But I also have friends that are still using Yahoo or Hotmail. And I'd be like, "Oh no, you got to try Gmail, or what about Gchat? This thing came out. You have to check it out." And I would think...back when I was building out these products, and this was, to level set, this is around the time of Web 2.0. I would think, oh, well, how would my friend in New York use this? Or how would my mom find her content? Or, how would my brother...

+ +

And I think sometimes we get very seduced when you're building something, especially as a product manager, that everything is from your lens and from your perspective. And the data and then also the feedback was telling us that we weren't really hitting it where consumers were. They weren't able to find the content as easily as we hoped.

+ +

And from there, I jumped into kind of entertainment streaming platforms, building out architecture, CMS, and then eventually transitioning into growth-led roles and then leadership roles later in my career. And so I've had the pleasure of working for startups like Beachbody, which was a fitness company big in the fitness space but smaller on the digital perspective, all the way to going back to Disney leading a team at Movies Anywhere. And now, I'm leading a growth team at Adobe.

+ +

VICTORIA: Wow, thank you so much. That's so interesting. And we have a couple of different tracks we could get into here. One thing I want to note that I thought was interesting is when you got into your new role, what really kind of presented itself to you is that you identified a problem in the UX. Like, you kind of lateral moved, and then you found this problem, then you had advocates who pushed you to go in that direction. And so, if you have advice for people who are looking to make that transition, how do you find those advocates that encourage you to chase the problems that you find?

+ +

KASHA: Oh, that's a great question. People ask me this frequently because I think on paper, it is hard. And no one's going to find you in your cubicle...or now a lot of us are working remotely in our houses. So you have to be your best cheerleader and campaign manager. I also think, like, what is it that is on your top three lists? In product, we have nice-to-have, must-haves, and then we kind of prioritize or stack rank our work backwards from that.

+ +

So I ask people, "What's the most important thing for your next role?" And then those are the things that you need to either lean in and start to amplify that you're already doing and how you would make a great candidate. I think internal candidates do have an advantage because they know the culture, or they may know the players, or they may see something from a different perspective, but they know what the company's challenges are.

+ +

So I would start by first talking to your manager, and you can have a great manager or not-so-great manager, but start there. Show them that, you know, I'm on this track plan, but I really want to be here. Are there things that I can do in my current role that would support that transition? Are there people that you can recommend? And sometimes, you can get traction with your manager, but if you can't, then start to search within your network.

+ +

And if there's a product manager who's maybe in your org or actually would be maybe at the same leveling or someone new, start to explain to them, "Hey, I would love to set up a coffee chat, a 15-minute informational just to hear how you did it or what's your perspective?" And constantly, as you're taking notes...people usually like it when they get an opportunity to share their story or talk about themselves. And as you take notes, "Ah, I am actually looking to transition to that. Do you have any advice for me? If you had something in an open role, what would you want from that candidate?"

+ +

And so you're constantly planting those seeds of like, I am this candidate, here's why. And product managers and, I think, also hiring managers, we have a room full of distractions. But if something's laid out to me in concise language and it's showing results of like, oh, well, I did this on the content management side, and I think this would be transferable, and here's why. And you don't have to be long-winded. I'm not into people writing dissertations and producing 20-page decks. I don't always have the time to read that, as lovely as it sounds.

+ +

Drive in on your skills. How are they relatable or transferable? And then, what are the goals that you've been able to achieve in your current role? And what are you looking to do in your next role? And I think if you start to place yourself there...and definitely get out and start talking to people in your employee resource groups.

+ +

And then also, internally, there's always, at some companies, there are HR or employee resource groups that will have at least a blog post on how to transition within the company, and if they don't, search out those people. And it's not an overnight process. I've seen people where it's been a flip of the switch, and they're on a rocket. And I've seen other people where it's taken time, but they've built those rapports with people that started to get to know them outside of their current role.

+ +

VICTORIA: That makes a lot of sense. And you're also involved in many professional networks. And so, do you also get a benefit for your career growth from that?

+ +

KASHA: Yes. I feel like I never stop learning. As much as there's always something new coming out, I mean like now I'm into the chatbots and AI. And I'm like, okay, here's another thing I got to learn. Let me [laughs] add this to my to-do list. So I never want to take that for granted.

+ +

So I feel like the communities kind of keep me, you know, it's a temperature check of what's going on, either from a challenge perspective or what type of new technologies people are integrating into their existing platforms, and how it's actually growing or benefiting them, whether it's from a machine learning and building out recommendation engines that have saved time, and then actually gets smarter. And we're building out algorithms all the way to, you know, what would it be like to have AI enhancements on an existing platform and still help drive that high-value consumer experience?

+ +

So I don't take for granted. I also recommend people that, even if you're not in product to, join product communities so that you start to hear the language and you start to see how product managers think and how hiring and leadership think. And LinkedIn is a great resource. I belong to Women in Product, Black Product Managers. There's a slew of Tech Ladies. And I'm always kind of looking.

+ +

There are newsletters that I love, Lenny's Newsletter. And I'm always like, oh, that's a nice one. Let me take that away for my team, or, oh, I didn't actually see that. I didn't think about that. I didn't see that playing out with NFTs in that way; hmm, really interesting. Or that TikTok is taking over search. And now I'm like, okay, how can my product that I'm growing from an engagement standpoint also have really strong representation on TikTok in a way that's authentic and users can find us, and we can continue to engage with users that way?

+ +

Start small. Find the right community that works for you. There's also Product-Led Growth, Product Alliances. There are so many of them. And I think you just start to kind of join them if you can. Some of them are free, some of them have dues. And they're really worth it. It's a value add. And you never know who's going to be posting in these Slack community groups too. You might see something where they're okay with associate level or okay with someone transitioning, or looking to help someone transition.

+ +

And I often mentor and direct some of my mentees in that direction so that they don't feel like they're in the passenger seat of their career and waiting for something to happen. You have to be active in this pursuit. And you also have to be a driver in it.

+ +

VICTORIA: Right. I felt that myself in my career. I felt like my network was my number one source of learning like you said. And also, when you're considering a career change, sometimes you don't even know what else is out there or what other types of jobs are out there. [laughs] I love what you said about that. And you also mentioned Women in Product and Black Women in Product. How can we promote those groups more [laughs] as we get more women in product? And why is it important to bring a different perspective into product?

+ +

KASHA: Yeah, that's a great question. I mean, I think podcasts like this, you know, letting people know. And then also, when I do a post on LinkedIn, I do the hashtags of all the groups that either I belong to, or I might tag them. One thing that I do when I do start to mentor someone I say "Be active in the community, share your voice. You're going to start to get comfortable."

+ +

Product managers have it...it's not a career for the weak, I'll say that. [laughs] And you have to have an opinion, so start small and start promoting yourself in those groups or hearing what people are saying. And even if my company is hiring or someone else, another hiring manager, and it has a post, I'll say, "Oh, did you think about posting this or adding this hashtag to this? This would definitely help give you a different type of candidate and also get more traffic."

+ +

And it's important to me because if I think about the world population and how we're changing, and who's showing up, you want that representation of the people that are working on it. They're going to be thinking about it from a different lens that I didn't even realize that that was an issue or oh, wow, we need to really tap into that. Or actually, we should promote this in a different way because we're going to cast a wider net, or we're going to cast a really specific net. With this demo, it can grow by 10x. Versus us thinking very generally and saying, "Well, we're happy with a 2x growth."

+ +

So that's why it's important to me. I'm also always balancing, like, do I have enough representation of women? And do I have enough representation of men on the team too? I don't want to go one side too far and then I'm out of balance and I'm just hiring the same people that are like me. It is kind of challenging sometimes because I have to think about what does the team need? What is the team dynamics missing? And who is that person that can bring in or usher in that different perspective? And then also work cohesively with the existing team.

+ +

And so that's a lot of balancing act that I do in my current role and really thinking about okay, well, we're serving small businesses. We're serving social entrepreneurs. Has anybody ever done that? We can be very kind of elitist in tech, especially in product of, like, well, I do it this way. I've [laughs] got Discord, and I have all the NFTs that I've ever wanted to collect. And I can hear and listen to all that, and I can geek out.

+ +

But then I'm like, if I go back to my friends, they'll be, "Kasha, what are you talking about? Can you speak English to us?" [laughs] And they'll be like, "Can you please calm down?" And I'm like, "Oh, but there's this thing." And then I'm like, well, maybe I need to have someone who is not like me because they're going to be thinking of that person who really just has a simple task they're trying to solve for. They have a limited amount of time, and they also have limited patience. They're not in a place where they want to learn and go on YouTube and watch a tutorial.

+ +

They're really just, you know, "Hey, I need to get this birthday card or this invitation out for my kids. And this was a free product that I saw from SEO results, and I'm here." And that's the value in finding that person and then carrying them through a journey. Me, I'm going to be picky. I'm going to probably research. I'm going to look at reviews. I'm going to look at two other competitors that I'm going to start to line up. [laughter] And then you've lost me by that point. You want to get that person, and you want to make it a frictionless experience.

+ +

So I do encourage, when I'm building teams, to think about the dynamics, always going for people that are, you know, want to be there and that are really dedicated to the product but also bring a different perspective than I did. And I come from an untraditional background in tech, so I think that's probably why I'm so conscious of this and how we can make these changes. And I think, historically, or the data proves that diverse teams often excel faster and better than traditional teams.

+ +

VICTORIA: Right. And teams that are diverse and are in an inclusive environment where they feel like they can bring their authentic selves.

+ +

KASHA: Correct. Yeah, it's one thing to have diversity, but then it's also another, you know, the counterbalance of inclusion. And how do you set people up for success that have different backgrounds? And I have a great strong team of rock stars, as I say, but they all are different. They all need different things. They all have different kinds of needs from a coaching or leadership perspective. Some I'm more hands-on, others I'm hands-off. But as a leader, it's being perceptive of that and saying, okay, well, this person likes to run their own ship. I'm going to be here on the sidelines. And this person I'm going to be out front. I'm going to be walking with them side by side.

+ +

I don't know why I have all these sports analogies because I was terrible at sports in junior high, in high school. But I always feel like I'm this coach out here with a whistle and a clipboard. And I'm telling them I'm like, okay, I'm going to set this person up. This person is going to happen here. And that's how I look at it from a growth perspective.

+ +

When I'm really assessing the roadmap and the backlog and what's going to be our impact, I'm also thinking about, well, how is everybody working cohesively? And is there a way that we can have shared experiences so that that way, oh, we learned from such and such an experiment, and that's going to influence the other half of my team? Or, actually, I'm going to have them focus, or I know that we're going to have too many mobile tests at the end of Q2 because the monetization team is also trying to test something very similar. So it's a constant juggling act in my role.

+ +

VICTORIA: Right. I very much relate to that. I was a competitive rock climbing coach a few years ago on top of my full-time job.

+ +

KASHA: Oooh.

+ +

VICTORIA: And my kids would ask me if I was also a motivational speaker [laughs] because I was always pumping people up while they're climbing. So yeah, I find it fascinating how you think about the needs of your team and your own growth from an individual contributor into a leader. And how do you coach people in your team along that path, like making that transition from being really strong in product to managing a team of product people?

+ +

KASHA: Oh, that's a great question. And I love that you're like a rock climbing...I love that. I'm like, [laughs] what we call thumbs. I would just be looking; I mean, just thinking about rock climbing, my hands are probably getting sweaty right now. [laughs]

+ +

And for my team, I do have people that they're getting to a senior PM level, and they're like, "What's next?" And I really like to do an assessment of, like, "Well, what do you think is next? And what is really going to help your career growth?" And some of them are like, "Well, I want to do leadership. I want to do this." And I ask, just like I ask in any product question, "What's the why behind that? Is it a financial contribution? Is it a recognition? Or is it that you are really invested in people development?"

+ +

Because one thing I do like to preference, especially people that are in early or mid-level careers, is that managing a product versus managing people are two different skill sets. And I didn't even understand that when I started to get into management; I kind of fell into it. I had a leader that exited the company, and it was like, "Oh, gosh, what will we do next?" And I was just like, "I think we should still continue to pursue the roadmap [laughs] is what I would think to do first."

+ +

So one of the things I do say is that your work is going to change. I don't PM, and I'm not regularly with the engineering team on a day-to-day basis. And so I will say to the team that first, at certain points, you can balance it. You'll have both where you might own still part of the portfolio, but then you have maybe one or two direct parts.

+ +

But as you start to grow, you will start to transition out of the day-to-day or building individual features or initiatives. And I do ask my PMS, are they ready for that? And if they check all the boxes and say that they have a strong why, then I start off by, okay, well, let's see if our team is eligible for an internship. We're going to open up an internship this summer, and instead of this intern reporting to me, they're going to report to you.

+ +

What's your onboarding plan? What's your growth strategy for this person? And then, what do you want this person to accomplish at the end of the internship? And it's a baby step for them to kind of get their feet wet on what is it like to lead someone? And then also, what are the challenges? There's always a perfect storm where things go great.

+ +

But what about the times when things are not going great, and how do you communicate with that person? What are the nudges that they need to give for them to either redirect them, or what are the things that you need to do to kind of show them the happy path to success? So those are where I start. We have international teams and people onboarding. I work for a huge company, so there are more opportunities there.

+ +

But then I will also say if someone wants to drive and be in a leadership role, what are the mentoring opportunities within the company? So, how would you mentor somebody? And what would be your advice? How do you set up a weekly cadence? What are your expectations of this? How should they measure success and goals? All these are things that are going to be transferable when that opportunity comes up.

+ +

And then also, too, what is the right situation? Is it a mix of where I'm 50% IC and then I'm, you know, this other 40%-50% of people management? I encourage them to look at opportunities internally, even if I'm at the sacrifice of losing what I call one of my rock stars. I know that it's inevitable for people to grow. And I never want to be the person that held someone back out of jealousy, or fear, or my own insecurities.

+ +

And I do have a strong network that when I post something, I get so many candidates. It's almost to the sense of like, wow, this person is greater. Wow, this person...wow, they went to Stanford, and they did this, and now they're transitioning. And I'm like, oh my gosh, they want to work with me. And so that's always very exciting. So I never want to get so trapped in the ideology that the team is only great with these people.

+ +

I'm like; the team starts with me and my leadership. So I need to be able to build a team. I need to be able to grow a team. And sometimes, you might have a great talent pool, and other times you don't, and then what do you do in those? I mean, that's what leadership really is. It's not always when you have everybody applying for your job, and you have all this funding, and your P&Ls are going incredible.

+ +

It's those times where they come back to you and say, "Yeah, we're not going to get that done this sprint, so you'll just have to figure it out." Or someone's resigning that you didn't see coming. And then you're like, okay, I might have to roll up my sleeves and take over their part of the roadmap just as a stopgap till I have someone. And that's the things that can make or break your leadership.

+ +

VICTORIA: Yeah, it's easy when everything is going great. [laughter]

+ +

KASHA: Yes. Don't we love that? [laughter]

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: You mentioned a few times, switching more into your approach to product management about the experiments that you run. Sometimes those go great, and sometimes they don't go so great. So can you tell me about a time you ran an experiment, and the results were really different than what you expected, and what did you do from that?

+ +

KASHA: Oh gosh, yeah. There are so many. I'm trying to think of what's the best example. Gosh, I'm like, do I go for mobile? No, web. [laughs] Well, I think in growth, a part of your experiment should fail because if they're not failing, that also means to me you're not taking enough risk. And you're taking things that you already know, in some ways, are like low-hanging fruit, and you're very comfortable in it.

+ +

And I do encourage my team to take a big risk of how do we start to find something? We recently had something to help users on the AI side. It was a really unique feature. A user uploads an image, and AI automatically spits out templates with this user-generated content. And we were so excited. We were watching the demos, I felt like on replay, you know, as we got out the meaning.

+ +

It didn't necessarily do what we thought it would do. And so then we had to take a pause, like, what happened? And one of the things that we learned from the test is that people just didn't understand what they were supposed to do. They didn't understand the process of their workflow. And they also weren't engaged with what the results came back.

+ +

So I think that's one thing that, you know, I know there's a lot of chatter in the space about AI taking over and where are we going to be. And I still think we need to have that human perspective, that person that is like, hey, these search results are really not what the consumer is looking for. And yes, it solved a requirement of picture upload output, but the output is not matching what the consumer's needs were. It didn't solve their problem. And we have to constantly continue to filter and refine the algorithm.

+ +

So our first output back was not great. But what we learned is that we have to have more variety of the type of output of content and that we also have to do more hand-holding. As much as we think that people are going to dive right in because it's in the press, and it's in TechCrunch and on Verge, that is not our general population.

+ +

I can talk to my girlfriend; she's a doctor. And she's like, "Hey, I'm just really trying to do this for my local women physicians network." All this other stuff, she's like, "It's kind of overwhelming to me." And I didn't even see that. I was just like, "Aren't you excited that you have five options? She's like, "No, I just kind of needed the one thing with the squiggly backgrounds [laughs] and the template that I could alter." She's like, "These don't actually really speak to me."

+ +

And so we had to come back and re-define the algorithm and also think about less choices for people; as much as we were like, we can randomize it; we can output more types of templates. It's really about finding the cues that the user is giving us to find that right match, and it's not something that I think we're going to get...and knowing from the test, we're not going to get on the first try. We're going to continue to test this, and that's what's going to make it better because we stress-test it.

+ +

I mean, in growth, sometimes, I tell my team, like, don't get our hopes up, our hearts set into it because we can spend a lot of time in crafting the experiment and doing the 50% and then the other 50% control and variants, and then when it comes back, they're just not excited, or the consumer just didn't really gravitate or attach to it.

+ +

And so then we have to stop, and I think, okay, there's a lesson here. Is it the education? Is it the guidance? Isn't the language that we use? You'd be surprised how one word can throw off someone's context. And they're turned off, or they don't want to do it. Or they like, "Oh, this is kind of cool. Oh, I didn't realize that this was a free service." Or, "Oh, I didn't realize that I could save this, and it's removing the background for me. And then now I have all these options."

+ +

Growth is a hard challenge. I mean, we move so fast, which is what I love, but then we're always kind of looking at the data and having to constantly pivot and transition based off of our previous tests. [laughs] Now I'm thinking about a time when I was at Beachbody, and I was so excited because I got to do native app development on mobile platforms, and I'd never done that before.

+ +

We were all excited. We had an iOS product that was really strong. And, of course, many of the people that worked in the office were all iOS users. So they weren't even thinking about Android. And we had just missed the mark as a company not really focusing on building out a great Android native app experience. And we were just kind of relying on the mobile web experience.

+ +

And I remember thinking like, oh, okay, well, you have something. And then I went into a Facebook community group, and I just saw all the complaints. I saw all the people's frustrations. I saw also all these user-generated hacks. People were sharing what to do when your video stops. And I just was like, oh my gosh, we need to get on this.

+ +

And so from that experience, I was able to champion and be one of the people that was like, hey, we need to help drive this. On Android, we need to really, like, this is really a problem. We could set ourselves up for success. And then we can also grow in other markets outside of the U.S. And I remember looking at the first designs, and they were all done by our creators' team, which were iOS users.

+ +

So even in that situation, I think of that as more of growth internally versus putting something out user-facing to the consumer. It still was a challenge. Like, how do I influence? How do I show that this is not the right path? How do I show that, hey, we're not using material design or best practices, and this is going to hurt us in the long run? Because people that are on these platforms on Android they're used to seeing things in this manner. And we're presenting it to them in another way, and then now we're wondering why they're confused.

+ +

VICTORIA: Right, right. And you mentioned a couple of different tactics to connect to that consumer voice. What other ways do you try to bring that connection between the end user and the customer, to the engineering teams, to the rest of the organization, to the business?

+ +

KASHA: I'm very privileged in my organization. We have a really strong user research team as well. As we're doing our experiments, depending on how large or how much time we'll invest into an experiment, we will do a prototype kind of test in a smaller pool, let's say, before we go out to A/B test or have a controlled and variant situation.

+ +

And sometimes those are the little things that I can take back, a video, or likes, comments, and send it. I don't even need to wait for it to be polished into a presentation or to a Confluence page, or even in Jira. And I can say to my counterpart, "Hey, Ganesh, do you see this? This is what I'm trying to solve for." And then it's like that aha moment. And I can say, and, you know, and engineers are always delightful. And they'll say, "Well, that's only one data point." And I'm like, "Yes, but it is a significant point. And I think if we tested this more, we will see more people are struggling with this." And how can we change that? What are their solutions?

+ +

And I'm really big on collaboration. Product owns kind of the deliverables and the path and is accountable for the results. But this is a joint effort between design, between data and analytics, and engineering. So early on, I present the problem. This is the why; here's kind of our best path. But what do you think?

+ +

And that to me and my career has always yielded such a higher result instead of coming from an authoritative or dictatorship of, "Well, this is the way that I've envisioned it. Here's my mocks, here are my wires, and this is why," and then kind of leaving it out to pasture or throwing it over the fence and saying, "Okay, and I need it in a week and a half."

+ +

And I've been on both sides of different product teams, and different engineering teams work differently. But I have found that when you get people to buy in, to care, and then also give them that consumer value of that person is frustrated; I mean, that's what was the trigger for me when I went into the Facebook groups. I really didn't have the biggest inclination that we were having such a problem on Android. I was an iOS user. I was happy with the product; I could get my workouts in, or I could find what I was looking for. And then, when I did that, I started screenshotting. And then, I started to share this out in the Slack channel.

+ +

And then there are also ways...now we have so many things where you can have bots that will record the feedback if someone says something in the App Store. That's one way to kind of bring it up to people. And then, if you don't have the funding or have an in-house user research, there's always usertesting.com. That is one way that you can start. Even if you work with design, and you guys are a small team, "Hey, I am so committed to this working. But I really would love to run a test."

+ +

And then also running a survey after people test or even in product, you know, what did they think about the experience? And if you can't even get that, you can always do thumbs up, thumbs down. [laughs] You can always do is this a four-star experience or a five-star? Would you like to tell us more?

+ +

I would say that sometimes we have blindness to surveys and to people asking for our opinions because you just want to get to that thing. But that small sampling of people that do respond, I think, is a way for you to kind of, if you're not sure, think about this directionally. I was leaning more towards this, but, wow, this user research came back, and I think people are going to really appreciate having this extra step.

+ +

Which is something like an oxymoron for me because I'm always thinking about, well, what's the easiest path? Or what's the least path of resistance to getting the user into the experience? And then sometimes you're dropping them into a whole new what we call canvas or experience, and they have no idea what to do.

+ +

VICTORIA: I liked the way you described your approach or how not to do it was like, just throw things over a wall [laughs] and say, "This is the way."

+ +

KASHA: [laughs] Yes.

+ +

VICTORIA: One of my questions that I like to ask people who have design and product backgrounds is just what does product design have to do with DevOps?

+ +

KASHA: Yeah, so everybody has to have a starting point. And a lot of times, I was definitely a product manager when I was more in the day-to-day, and I see where...in my mind, I like to figure things out on my own. And that way, I like to come with this pretty package of, like, I thought of all the different angles. I thought of the best use case and the worst use case.

+ +

And as much as that was delightful for me, I noticed that the people in engineering would kind of check a box too, and they'd be like, okay, done. And then we might get to a certain point, and they would be like, "Oh, well..." one time when I was building something for Beachbody, and, again, it was on Android, and it was the search. And I didn't think anything of it. I was just like, oh yeah, top result, then stack rank alphabetically.

+ +

And then I hadn't thought about new content. And I remember thinking, like, why didn't my engineer say this? Because this is something that we do on iOS. And they said, "Well, you never asked us." [laughs] And I was there, you know, "But you work on the product too." And they're like, "Oh yeah, but you run the show. So this is what you wanted, so this is what I coded."

+ +

And I just remember feeling like I had egg on my face in a meeting because now we had all this new content coming out, and the search results weren't accommodating for new content. They were accommodating for the existing metadata. And I just remember thinking like, never again. And from a DevOps perspective, I think of there's a lot of change in the industry where we also have product ops people as well.

+ +

And I think of it as additional layering; it can be good and bad. I think there are positives and advantages. I think there are always growing points. And I think you have to give what is the ultimate goal? Like, if you do have a DevOps team, are they also early in the iteration? Are they part of the brainstorms? That's how I run my small pod. We have design, analytics, and engineering part of our early brainstorms.

+ +

So instead of us kind of holding our ideas in a huddle, we will kind of tee up, let's say, our top five and say, "Hey, directionally, this is the direction that we're going." And we're framing it to the problems that are most important for us to solve. So we don't turn it into a hackathon where people are trying to build a spaceship in a brainstorm. That's not the goal.

+ +

The goal is that, hey, we have these particular problems. This is the direction that we want to go in, and this is how we carry it through. And then, what do you guys think? And then we're in a Miro board in real-time. And we put the timer on and then get everybody's opinions. And some product groups I've seen where product team doesn't actually talk to the engineering. They just talk to the technical PM, which then translates out what the actual specs and requirements are.

+ +

I haven't been part of that type of org yet in my career. I have been traditionally where it's a one-to-one ratio where if there's a product manager, there's going to be a data and analytics analyst assigned to them. There's going to be an engineer assigned to them. There's also going to be a designer. And that's been my sweet spot. And I've had a lot of gains and tractions for that.

+ +

In my mind, ideas can come from anywhere. It doesn't have to start with product, but product is going to be the leader. And I don't want to think of it as a gatekeeping situation. But we're the ones that are going to drive it through with our own cross-functional teams as a partnership. So I hope that answers the question about DevOps; I'm not sure. Sometimes I can get into a little bit of a tangent [laughs] and start talking about my own experience.

+ +

VICTORIA: I love talking about it because some product, people will say nothing. [laughter]

+ +

KASHA: Oh really?

+ +

VICTORIA: And I'm like, no, you're supposed to talk to people. Bring everybody in, and that's the whole philosophy of it. And I like that you mentioned product ops and design ops as well, thinking about how you can automate the process of what you're doing or how the information flows across your team. I'm sure with your designs and end product, and everything is more on the product ops side.

+ +

KASHA: And I think having an ops, you know, it does have like one central point of contact. So if you want to think about alleviating steps, or reducing the white noise, or the friction that you may have in the organization, you have one kind of point of contact. And that person will own it, and they'll almost become a mini pod and then distribute the information, which is definitely like a gain and a positive.

+ +

I just wonder on the reverse side, though, how does that engineer or how does that designer then surface, "Hey, what about this?" Or "I think this is a better way," or "Actually, we tested this two years ago, and the results weren't great." And so that's the only thing where how does that two way-communication go back and forth when you have ops?

+ +

I think ops definitely gives more structure. You're definitely in a high performance. Everybody knows what their marching orders are. We know who's on first. And we also know from an accountability and an escalation process where all these pieces are working together. So I can see the benefits to it. I'm not opposed to it. I just want to make sure that the people that are actually building the product also have time to have a say and have an opinion.

+ +

And whether that helps change me, I want to at least hear the feedback first. And then as a product leader and as a product manager, it's up to that person to make the decision of, like, okay, you know what? I've thought about this looking at the data, or this person raised a really significant point that I hadn't considered. I do think that we need to think about this and focus. That's the advantage for me, I feel like, of having that bottoms-up approach to development and then running your teams.

+ +

VICTORIA: I think that makes sense. And you're right; I think it can be successful. But I think there's a good warning there about...and people do this with DevOps teams as well where they create a DevOps team and then put them in a silo, right? [laughs]

+ +

KASHA: Yeah.

+ +

VICTORIA: And that's kind of missing the point about the whole thing. It's like we want to power these people.

+ +

KASHA: Yeah, everything new is old again. I remember when I didn't even talk to an engineer. And I remember...and this was early in my product when I had the product specialist. I would be at my cube writing requirements. I thought they were great. And then we switched to an agile format, and I remember going into a meeting thinking, okay, we're just going to go over the stuff that's next. And they had all these questions for me, and it terrified me. [laughter]

+ +

Because it made me think, like, maybe I don't know what I'm talking about or, yeah, I didn't think about the error messaging. Oh, okay, yeah, what happens if someone loses internet connection during that session and they've started the process? Oh, I don't know. What should happen? [laughs] And so there were all these kinds of questions.

+ +

But before, I would just process my requirements, put it in a Jira ticket. And then you might get some Jira comments, but there wasn't this back-and-forth in real-time. And then, I had to really step up and write my requirements better. Because at that point, I had just had like, oh, this happens in check one. This happens at step two. And then step three, the end. That was my own kind of naive perspective at the time when I was writing requirements.

+ +

And I didn't know that the engineers had all these questions because we had that layer of...they didn't call it a DevOps person. I think they called it, you know, an engineering lead where he would just take the tickets, and then they were doing their own sub tickets to make it make sense. And so then, when we started to transition into more of an agile and rating things and giving value to them, I really had to change.

+ +

And it helped me grow. And it was definitely uncomfortable. But it definitely pushed me into thinking, okay, someone's reading this. They're an engineer. They're not thinking about this. How can I get as clear as possible but also still think about the consumer or the persona that I'm thinking about that is trying to solve this problem?

+ +

VICTORIA: That makes sense. It reminds me of one of my first jobs actually was in Washington, D.C., which you went to undergrad there. I would actually pass by Howard University on the bus every day to work. [laughs]

+ +

KASHA: Oh wow. [laughs]

+ +

VICTORIA: I wonder, are you familiar with BisonHacks and their annual hackathon that they have there? I know you're from the film department. But the computer science does a hackathon there every year.

+ +

KASHA: I am not familiar with that specific one. But I participated; I mean, we have some at Adobe. We have our regular hackathons internally. But I would love to hear more about the one that you're describing. It sounds pretty fascinating. Do they have an ultimate goal? Are they building from an existing product, or is this something new?

+ +

VICTORIA: I think it's something new. So I believe that they come together to create solutions to help improve the livelihood of the DMV community.

+ +

KASHA: Oh wow.

+ +

VICTORIA: So I think every year they make it a different purpose.

+ +

KASHA: Okay, I got it.

+ +

VICTORIA: But they interact with students and do different projects. And it's a super fun organization. So, yeah, I'll send you a link. We'll share it in the show notes as well. [laughs]

+ +

KASHA: Yeah. I love it. I love it. This podcast I'm already growing [laughter] in the short time we've talked, so I love that.

+ +

VICTORIA: And we're coming to the end of our time here. I have one final question before I ask you if you have any other final takeaways. [laughs] But what are you most excited about on the roadmap for Adobe Express that you have coming?

+ +

KASHA: Well, I'm excited...gosh, what can I share? [laughs] I'm like, I see legal tapping me on the shoulder. [laughs] I'm excited that we are making so many improvements to really simplify the experience and that we're also diversifying our use cases of the types of people that will be coming to the platform.

+ +

So when I say that, let's say we've been focused on what we call the social creator, or the small business owner, or hustler, I really want to lean more into that and expand that. We also have more of what we call our pro users coming to Adobe Express. So if you think of someone that's a professional graphic designer that may need something where they need to have a collaborator, we're enhancing that process.

+ +

And then also, I'm most excited coming into 2023 is that Adobe's Express is going to be what we think of as the doorway to all the Adobe ecosystem. So whether you start with Express on a small scale and building out a template, you can really grow with this product. And whether you use it for your everyday either social needs or even in your everyday work or marketing, you can start to have people come to the platform and collaborate on it.

+ +

We have so many exciting things that it's interesting because my team is focused on activation and repeat engagement, and how do those two worlds kind of marry each other? Getting the user in from having them on a first great day one experience and then carrying them through for when they return.

+ +

And one thing that I'm excited for is that we've had this recent pivot, and this came out of user research. We don't have to wait for the user to leave the platform to remind them of all the great things that we can do. And I'm really excited about having machine learning capabilities on the platform; where, if your next step is this, what's the next best available action? And then how does that help enhance not only your experience of the product but then also starting to plant those seeds of you can schedule this in advance or creating this type of content once a week will drive exponentially your growth on your platform?

+ +

And that, to me, is making us stronger and really looking at it not only from I want the consumer to do these series of high-value actions, but I really want to see them grow on their own personal platform level. And here's a tool that can help you do everything that you need to.

+ +

And whether you're someone that posts once a week, or whether you're someone in an office that is collaborating for a marketing meeting, or if you're a professional that has something that, you know, I just really want to use a template. I have an aesthetic. I know how to use Photoshop. I know how to use Illustrator. But let me put this in Express. I can send it to the client. They can make comments, and then they can also feel like they're part of the creative process.

+ +

That makes me happy because I was this fine arts major. It feels like 100 years ago. [laughs] And I remember thinking like, oh wow, I love these products. They're expensive, or saving up for them. And then now there are so many different plans. There are so many different ways. And I would have loved an opportunity to have a free product that allowed me to just start to understand my own type of style and capabilities without having this feeling that I have to be a designer and that everything has to be perfect. So I'm excited for that.

+ +

We have so much growth planned, new, exciting ways on the platform. And, also, you'll see some new looks. I can't share too much more than that. [laughter] So I hope the little bit of tidbit doesn't get me in trouble. But sometimes you got to break some rules. You got to break some eggs to make an omelet.

+ +

[laughter]

+ +

VICTORIA: Any other final thoughts for our listeners today?

+ +

KASHA: I would love for, you know, to give me feedback. I always love doing these. I'm active on LinkedIn. You can find me at Kasha Stewart. Shoot me a note. I get a healthy amount of mail, but I promise I will reply back to you if you have questions and what your biggest challenges are. Check out Adobe Express. It's free, by the way.

+ +

And continue to, you know; I just remember being this, like, early in my career and having these questions, and at different points, I was afraid to ask questions because I was like, I don't want to sound silly. Or maybe I'm not understanding that, or, you know, maybe I should have been a CS major. And I say to people now, like, you have to have a starting point. You never know what is next on the horizon. Or that everybody had been thinking about that and they were just waiting for the person to raise their hand. That's one of the things that I always want to encourage people and to check out these products, communities.

+ +

And thank you to this podcast for allowing me to share my journey and my story. It's always a pleasure. I learned something, and I'm like, oh yeah, I did actually do that. But that was a while ago that; I might forget. So it's good. It's like having my own little mini retro. So I thank you for inviting me here and to, you know, share my journey.

+ +

VICTORIA: Well, thank you. That's a very powerful message, and I appreciate you coming on today to share it with us.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you for listening. We'll see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Special Guest: Kasha Stewart.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+3li9tWFl + + ]]> + + Victoria Guido + Kasha Stewart + + + 458: Cofertility with Lauren Makler + https://podcast.thoughtbot.com/458 + e02ec4b9-aa29-40dd-8cb5-827e36f80bee + Thu, 19 Jan 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Lauren Makler is Co-Founder, and CEO of Cofertility, a human-first fertility ecosystem rewriting the egg freezing and egg donation experience. + +Victoria talks to Lauren about tackling the access issues around egg freezing and donation and hoping to bring down the cost, leaving a company like Uber and starting her own business, and figuring out a go-to-market approach and what that strategy should look like. + 37:27 + no + + + Lauren Makler is Co-Founder, and CEO of Cofertility, a human-first fertility ecosystem rewriting the egg freezing and egg donation experience. +Victoria talks to Lauren about tackling the access issues around egg freezing and donation and hoping to bring down the cost, leaving a company like Uber and starting her own business, and figuring out a go-to-market approach and what that strategy should look like. +Cofertility (https://www.cofertility.com/) +Follow Cofertility on LinkedIn (https://www.linkedin.com/company/cofertility/) or Twitter (https://twitter.com/cofertility). +Follow Lauren Makler on LinkedIn (https://www.linkedin.com/in/laurenmakler/), Instagram (https://www.instagram.com/laurenmakler/), or Twitter (https://twitter.com/laurenmakler). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Lauren Makler, Co-Founder, and CEO of Cofertility, a human-first fertility ecosystem rewriting the egg freezing and egg donation experience. Lauren, thank you for joining me. +LAUREN: Thanks for having me. I'm so excited for this. +VICTORIA: Me too. I want to hear all about Cofertility. Can you tell me a little bit more about the platform that you built? +LAUREN: Absolutely. Cofertility is really like you said; we're a fertility ecosystem. And at our core, we're enabling women to freeze their eggs for free when they donate half of the eggs retrieved to a family that can't otherwise conceive, providing support and education for everyone involved along the way. You know, we're serving two very different audiences. One side of our business, our Freeze by Co, is targeted at women between the ages of 21 and 40 who might be interested in preserving their fertility. +We know that really the best time to freeze your eggs, unfortunately, is when you can least afford it. And so we've really taken on this access issue and hoping to bring down the cost on that front. And then our Family by Co business is for intended parents who need the help of an egg donor to have a child, so that could be anyone from people who struggle with infertility, or gay dads, cancer survivors, et cetera. +There are a lot of people that really rely on third-party reproduction to have a family, and we think it's time to really move that industry forward, and we're doing that in a lot of ways. So that's at a high level; happy to dig in more on any part of that. But we launched in October, and things have been going well ever since. +VICTORIA: Wonderful. Yeah, I want to ask you more about...you mentioned the problem that you identified with when people who are most ready to freeze their eggs probably can't afford it. [laughs] But how did you really identify that problem and think I should start a company around this? +LAUREN: Yeah, so it's a two-part problem. I think we see a big problem on the egg-freezing side, which is truly cost. I think we know that women are starting families later than ever. For the first time in U.S. history, the average age of women giving birth now is 30, which is the highest on record. And the experimental label from egg freezing was removed in 2012, and so it's become much more mainstream for women to do it. +However, the cost to do it in the U.S. is between; I want to say, $12,000-20,000 to do it, plus yearly storage fees. And there are some women who have access to doing it through their large employer, but for the majority of people, that's just not the case. And so, for women who are really trying to prioritize their career or their education or maybe haven't found a partner yet, egg freezing can be a great option. +And certainly, it's not an insurance policy by any means, and it's not a guarantee. But studies show that if you experience infertility later in life and you did freeze your eggs, you're much more likely to have a child than not. And so we see it as a great backup option. But again, cost is just truly a huge problem. +And then, on the egg donation side, there are tons of families that rely on egg donation to have a baby. And I'm someone...I should mention, too, personally, years ago...I'll make a very long story very short here. Years ago, I was diagnosed with an incredibly rare abdominal disease that put into question my ability to have a biological child someday. And so, I started to look into what my options might be, and egg donation came up. +And when I looked at what was happening in the space, I just couldn't believe how antiquated it was. And truly, for lack of a better word, how icky it felt. It seemed really transactional and impersonal for everyone involved. And what I realized was that it was really rooted in the stigma around egg donation that comes from cash compensation for donors. +So traditionally, a donor is paid anywhere from $8,000 to $100,000 for her eggs, depending on, unfortunately, her pedigree or sometimes her heritage. Something that might be, you know, a donor that's harder to find might require more compensation the way it's done today. And so we actually saw that many women who are interested in helping another family grow through egg donation can actually be off-put by this idea of cash for their eggs. It's like, ooh, am I selling my eggs, or how do I feel about that? And it actually turns people off when it might otherwise have been something they wanted to explore. +It also, I think, leaves intended parents without options that they need and really hurts the LGBTQ community that relies on egg donation for family planning. So there's a lot there. And we felt that that was something that if we remove cash compensation, perhaps it's something that really opens up the pie of women that are open to and interested in egg donation. And it also might really honor the donor-conceived person on the end of it more than what's happening today. +Studies have come out that show that donor-conceived adults find the exchange of money for donor eggs to be wrong and that they can actually find it disturbing that money was exchanged for their own conception. So our model takes out cash compensation and instead gives women something that they're excited about, which is preserving their own fertility as well and really sets up everyone involved for success. +VICTORIA: Yeah. I saw that in your literature, you bring this human-centered design to how you built the platform, which I think speaks to a little bit of what you're describing there. And do you think that being a woman founder yourself allows you to relate and empathize with women who have this unique perspective or a different perspective on how egg donation should work? +LAUREN: Yes, egg donation and egg freezing, honestly. I think I mentioned a little bit about my own experience. Both of my two co-founders have also really, really been through it when it comes to their journeys to parenthood; both of them have been through IVF. And one of them says, you know, her biggest regret in life is that she didn't freeze her eggs at 25. And now, instead of just sitting in that, she's building a company to help other women not have that same regret. +So building the company we wished existed when we were younger lets us build something that truly is empathetic and human-centered. And it's unfortunate that so much of healthcare is built and designed by people who, while maybe they have good intentions, they're not building from a place of experience, and I think reproductive health is one of those. I think women need to be involved in designing those solutions, and too often, they're not. +VICTORIA: Right. Yes. That makes a lot of sense to me. And I want to talk more about you and your three co-founders and how quickly all this has come together. So, how did you know that your team of co-founders was the right team that these are the people you wanted to start this with? +LAUREN: Yeah, it's an interesting question on so many fronts. I think there are people who spend a really long time, like co-founder dating, and use frameworks for evaluating co-founders, and the truth of it for us is that it all happened very quickly. Halle, who is the person who connected the three of us, she is one of my co-founders, and she's just someone I had long admired in digital health and women's health. +And there was a day where...we peripherally knew each other. And she slid into my DMs on Instagram. Like, you never know where a great contact may come from. And she asked me what I was up to, what I was working on, and the rest is history. I told her I had just left...I spent eight and a half years at Uber and launched new markets of Uber across the East Coast and then started a business line at Uber called Uber Health, and Halle had always followed my trajectory there. +And when she reached out to me, it was like, [gasps] what's it going to be about? And when it ended up that she had an idea centered around egg freezing and egg donation, given the experience I had had with my own fertility journey, it just felt like how could this not be the right thing for me to go build? So I would say gut instinct is really what it comes down to. +Halle and Arielle, our third co-founder, had worked together a bit in their past lives. Halle built a company called Natalist, which is fertility, pregnancy tests, ovulation kits, and prenatal vitamins, things like that. And Arielle had actually built the first iteration of Cofertility, which was a fertility content site. And they had had that rapport already, and so that was something that I valued quite a bit. Really talking to some references and getting opinions of people you trust, but your gut, more than anything, will help you answer that question. +VICTORIA: Right. And sounds like there's that shared experience and mutual respect, which goes a long way. [laughs] +LAUREN: Yeah, that and also a shared vision. Like, if you're aligned with someone in the first month or so of talking about an idea, and when it goes from a little kernel to snowballing and becoming something real, I think it's a good signal. But if you're butting heads and disagreeing in that first really crucial time, it's probably a good idea to go in a different direction. +VICTORIA: Yeah. And thinking along those lines, were there decisions that were really easy to make, and what were those? And the second part of the question is what decisions were kind of challenging to make, and what made those decisions challenging? +LAUREN: It's funny. Halle was just like, "This idea is going to work, and I know it. Let's do it." I am someone who likes to see evidence before making a decision. And so I suggested in those first two weeks, like, let's get a survey together. Let's ask women, "Hey, would you actually be interested in egg donation if it meant that you got to keep half of the eggs for yourself and that there was no cash compensation involved?" So we asked a few influencers on Instagram to put out our Typeform, and within, like, I don't know, 24 hours, we had over 700 responses. +VICTORIA: Wow. +LAUREN: And it was a very resounding like, yes, this is something women were interested in. That gave me all the conviction I needed to go at this full force. And so I think having that proof point not only was valuable to help me get there, but it also helped investors get on board. I think some of the easy decisions were like there were certain investors that after meeting I just knew like, yes, this is someone I want to be working with over the next few years. This is someone who sees the same vision that we see. +And there were a few conversations with other potential investors where I was like, you know what? That's not who I want to work with. Again, it's like, I'm very big on my instincts as it relates to people and trusting that. +VICTORIA: Right. Yeah, that makes a lot of sense. And congratulations on raising your seed funding. +LAUREN: Thank you. +VICTORIA: And was that a stressful process? How did you feel after that happened? +LAUREN: Parts of it were stressful, for sure. I think the fact that I had never done it before was stressful. I like to call myself...before this, I was an intrapreneur. I pitched the idea of Uber Health to Uber executive leadership with a deck that was very similar to what you would pitch external investors with in a scenario like this. So I had gone through a little bit of that but never before had I done anything quite like this. +And so I felt very lucky to have Halle by my side through that process because it wasn't her first rodeo. But I would say trusting yourself and trusting that you can figure this out. It seems so much more intimidating than it needs to be. No one is expecting you to fully know how all of this stuff works. It's very figureoutable. +VICTORIA: And what obstacles did you face in the last year that you've been working on this? +LAUREN: The biggest obstacle, I would say, honestly came down to having the time to both get a company off the ground...and I like to imagine an aeroplane. You have to figure out what kind of plane you're building; then you have to find all the parts, then you have to build the plane. And then the goal upon launch, I can imagine it when I close my eyes. It is like getting the plane off the ground. +And with a startup, like you can imagine, there's always a bit of building the plane while you're flying it. But doing all of that over the last year, plus finding the right people to hire, is two full-time jobs. You're sourcing incredible candidates. You're meeting with them. You're pitching them the business. But you also need to evaluate whether or not they're as great as their resume makes them seem. Then you have to convince them to join your seed-stage startup, then check their references, and then put together their offer package, and then do all of their paperwork. +And it was like all of these things that I took for granted at Uber for so long of having recruiters, and having an HR team, [laughs] and all of those things that truly it is a full-time job plus building a company. So that, for me, was the hardest. And hiring just at that early stage is so, so important because you add one person, and that's like such a huge percentage of your team. So every hire has to be a great one, but you also can't wait too long to hire because then you miss your goals. +VICTORIA: Right. Yes. And there's lots of uncertainty going on in the world as well. I'm sure that makes hiring extra exciting. +LAUREN: Yes. I mean, exciting and also scary. I think exciting from the fact that there's great talent that's looking in a way that wasn't necessarily the case six months ago, but scary in that you have to...one of my biggest or things that keeps me up at night is like, what's the right timing to bring on new people so that your business scales appropriately but not too soon that you have people waiting around for the work to come? +VICTORIA: Right, yes. And speaking of scary, I can imagine the choice to leave a company like Uber and go and start your own business was thrilling. [laughs] Can you tell me more about how that happened, or what was the order of operations there? +LAUREN: I'll go back to my personal story a little bit. So I ended up with this disease that I had been diagnosed with. It was so rare and so not a lot of data on this disease that I decided it was...or these doctors were like, "You know what? Do you have a sister by any chance?" I was like, "What do you mean?" They were like, "You know, it's too risky for you to freeze your eggs just because we don't have any data on your disease. But if you have your sister freeze her eggs and donate them to you, you have them as a backup should you need them." So my incredible sister did that. +And I learned a lot about the process of donation even through that experience. And went on to have three surgeries and ultimately was able to conceive without using my sister's eggs which was crazy and exciting and definitely gave my doctors a shock, which was great. And when I had my daughter, it was like this light bulb went off of, like, I have to build something in reproductive health. If I'm spending my time building something, I want it to be spent giving people who want to have a child this amazing gift that I've been given. +And it was like an immediate amount of clarity. And so, after my maternity leave, I gave notice at Uber without a plan. I did not have a business idea. I did not have a job lined up. I was fortunate enough to be able to do that. But I almost think releasing myself of that is what gave me the freedom to think about other things. And it was within a day that Halle sent me that DM on Instagram without knowing I had given notice. So the universe works in mysterious ways. +VICTORIA: That's wonderful and so exciting and that you just had a baby and then to be in a position where you could start a company and almost feel like I don't have enough to do; [laughter] I want to start a new company too. [laughs] +LAUREN: I know. I ended up...the day we pitched our lead investors was my daughter's six-month birthday. +VICTORIA: That's amazing. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: How do you balance that, like, those needs of being a mom and maybe being sleep deprived, but also starting this incredibly important business that you're passionate about? +LAUREN: I mean, I'm very lucky that I have an amazing husband and sort of partner in all of this. We both are very involved in each other's work, and I highly recommend that if that's something you're open to. I think it gives you an outlet and someone to be invested in it with you but also more to talk about with your partner. [laughs] +But other than that, too, I think having boundaries. So I've been really, really specific with myself and with my team about what windows of time I'm with my daughter, and I'm meticulous about it. If that means on certain days, I wake up before she does so that I can get some work done so that I have two hours with her first thing in the morning, and then I'm off between the hours of 4:00 to 7:00 so that I can spend time with her. If that means getting back online at night, I'm down to do that. I just won't compromise the time with her. +And my team has been really respectful and honoring of that. And in turn, I really encourage everyone on my team to have a life outside work, whether that's with their children or their pets, or having physical activity, or things like that in their life. I think it's so important that we're not entirely defined by our startups. I think that's how people burn out really quickly. And it's like 2023, right? We don't need to be in this hustle culture where 100% of our time is focused on building our company. It's just not sustainable. +VICTORIA: Right. I like that you mentioned sustainability. And that's been a recurring theme I've seen where, yeah, the hustle culture leads to burnout. It isn't sustainable. So are there other cultural or values that you impart onto your team, this new team, that you're standing up to create that sustainability in that innovation that you want? +LAUREN: Yeah. I think one thing we've implemented...I would highly recommend actually Matt Mochary's CEO Curriculum. You can find it by Googling it, or I can share the link with you. And within his curriculum, he has something called The Magic Questions. And the magic questions it's like five or six questions where you ask everyone on your team, like, how would they rate their life at work? How would they rate working with the team? How's their personal life going? Like, you know, questions that you can quickly get to the root of something. +But then, aside from giving a rating for each of those questions, it asks like, "How would you take it to the next level?" And what I think implementing these questions has done is it's like each time we do it, it gives the leadership team something to act on of like, "Hey, I noticed a theme amongst the employees with this set of magic questions. Like, here are some things we can address to improve that for everyone." +And then there are also opportunities with each individual to say, "Hey, manager of this person, so and so called out that they're really struggling with prioritization this month, or they're really struggling with being split on these two projects. How can we help relieve that, or how can we dig in with that person so that the next time we ask these questions, that's not still an issue and that we've been able to take swift action to help improve that?" +I think that really helps to just stay close to what people are feeling and thinking. And it also gives people, I think, more self-awareness of how they're doing and what they can be intentional about and address for themselves as well. +VICTORIA: I like that. I'll have to look up that book and share it in our show notes as well and -- +LAUREN: It's actually even all online. It's like a Google Doc you can look at. +VICTORIA: That's awesome. +LAUREN: And there's also a book called The Great CEO Within by Matt Mochary. But I love the book and the Google Doc version. +VICTORIA: That's awesome. And it sounds like you really pulled everything together so fast. [laughs] I'm curious about your background if you feel like there were...you mentioned that you pitched inwardly to Uber. But what else about your background kind of lends you to this leadership-founder skill set? +LAUREN: I mean, I joined Uber in 2013 when we had, I think, fewer than 200 employees, and we were in about 12 cities. So I very much knew startup life. And I understood this idea of sort of building the plane while you're flying it and saw that. And so I think that certainly has contributed to this. It's important when you're a founder to surround yourself with other founders and to have people that you can tap into at any point. +I'm in a few different Slack groups with different founders; some are healthcare founders, some women founders, some through the VCs that we've worked with where it's really easy to say, "Hey, which payroll tool are you using?" Or "Hey, like, how do I measure employee NPS?" Or "What tools are you using for this or that?" And if you can tap into other founders, you really can move a lot faster. You don't have to write your entire employee handbook from scratch because you can borrow from other people. I think that's one of the best hacks that I would recommend. +And then some of these books that I found that really do, you know, within that Matt Mochary book, it's like, here's a way to make candidate offers. Obviously, the book isn't doing the work for you, but it certainly is helping to give you a framework. And then the other piece is like, aside from your own team, I think bringing in some advisors who you trust and can go to for certain things. So two of our advisors are people I worked incredibly closely with at Uber and would trust with my life and so why not trust them with my company? So bringing them into the mix has been a real relief. +And then just sort of about your community. I think it takes a village to raise...I think, actually, I would compare launching a company to having a baby. So if having a baby takes a village, so does launching a company. +VICTORIA: Right. Or no founder is an island. [laughs] +LAUREN: Yeah, exactly. +VICTORIA: There's like a community, a whole group around that. I've heard, even in the episodes I've recorded, that it's a common theme among successful founders, which is heartwarming and understandable. So last question about just how it all got started. But if you could travel back in time to when you first decided you wanted to go after this opportunity, what advice would you give yourself now that you have all your present knowledge? +LAUREN: I say this even to our intended parents who are grappling with this decision of using an egg donor to have a baby: remain steadfast on the vision or the end goal and be flexible on the how. So if you're an intended parent, it's like, remain flexible, like, steadfast on this idea that you want to become a parent, but be flexible on the how. +With a company, I think stay true to what that ultimate vision is. So, for us, it's like help more people have babies on their own timeline and be flexible on the how, so exactly what our business model was, or exactly what our go-to-market approach would be, or exactly which product we were going to use to get there. I wish I had been a little bit more open to it being a winding road than I realized I needed to be at the beginning. So now I know that, and I'm open to any possibility as long as it gets us to the same place. +VICTORIA: Right, gotcha. Yeah, well, let me ask you then about your go-to-market strategy since you mentioned it. What was unique in your strategy there, especially to target the specific consumers that you want to with this app? +LAUREN: So I did follow a bit of an Uber approach, which is this idea of a soft launch. And the reason for that...so basically what we did was for the Freeze by Co side of our business, so for women who are interested in freezing, they have the option to join our split program where they donate half to intended parents and do it for free. Or they can join our Keep Program, where they freeze their eggs but keep 100% of the eggs for themselves. And we help do that along the way. +However, basically, we couldn't launch Family by Co to help people find donors until we had donors. So it made sense to launch the Freeze by Co side of our business first. And I wanted the ability to market to them when we didn't have the eyes of the whole industry on us, or we didn't have tons and tons of consumers reading our press or things like that just yet. +And so by soft launching with a quick beta Squarespace page, we were able to test our hypothesis, test our messaging, test our funnel, test our experience before really putting a ton of marketing spend behind it or having a ton of visibility into what we were doing. And I'm so, so grateful we did that. +It led us, like, we went through probably five different versions of our funnel before we got to our public launch, and our soft launch really afforded us the opportunity to do that. So by the time we turned on the Family by Co side of our business, we already had over 50 donors on day one for them because we had already gotten these women through the funnel. +VICTORIA: I love that. And that's something we talk a lot about with founders at thoughtbot is that idea of validating your product, and you talked about it with your Instagram poll that you did with influencers. And the way you're talking about your go-to-market strategy is that you wanted to make sure that even though you knew this is what you wanted to do, that you had the right approach and that you could create something that consumers actually wanted to buy and had trust in. +LAUREN: Mm-hmm, totally. +VICTORIA: You launched in October 2022. Are there any results post-launch that surprised you? +LAUREN: I feel so grateful that our launch truly exceeded my expectations. So the interest from women in our programs has been overwhelming, like overwhelming in a good way. And then intended parents are thrilled about it. So we are making matches every day of these intended parents and these donors. And every time we make a match, I'm like, oh my God, it feels like Christmas morning. You're helping people find their path towards growing their family, and there's nothing that feels better than that. I don't think that feeling is ever going to go away, so I'm thrilled about it. +But it doesn't mean that it's not hard. I think back to that analogy of like having a baby, you know, you launch this company. You hope it's received. You count ten fingers, ten toes, hope that it's received, hope that it's received. It is, but then you have the demand, and you have inbound on partnership opportunities, and you have managing the demand and handling the leads and things like that. And it's like so much more than you expect. +It's like the same feeling of having a newborn of, like, [gasps] how are we going to do all this? Am I going to stay up all night to manage this? Or how do we handle what we're seeing? And so it's a lot, and figuring out what this new normal is is something that my team and I are working through every day. +VICTORIA: What's wonderful is that the surprise feels even better than you thought it would. [laughs] +LAUREN: Yes. +VICTORIA: Wonderful. For myself, as I'm in my 30s and I'm married and, you know, I'm not thinking it about at some point in the future. But what advice do you think you want women to think about regarding their fertility at any age, like if you could talk to consumers directly like you are now? [laughs] +LAUREN: Totally. Just that it's never too soon to ask those questions. And the information you need and should want is like inside your body but ready to be shared with you. So by having a consult with a fertility clinic, and that's something my team could help you with, you can learn about your prospects for having a baby and understanding how fertile you are. +And just because, you know, they say, "Oh, as long as you're under a certain age, you shouldn't have a problem," doesn't mean that that's the case. One of my co-founders was 28 when she started trying to conceive and was completely blindsided that this was going to be a real struggle for her, and that breaks my heart. It doesn't need to be like that. If we're more proactive and we start asking these questions younger, then we can actually do something about it. +So your fertility is really about your egg quantity and your egg quality, and both of those things are things that can be tested and measured. And I think I'm someone who loves data. And having that data, I think, can help enable you to make decisions about how you can best move forward, and for some, it might mean having a baby soon. For others, it might mean freezing your eggs. For others, it might be a waiting scenario. But that's something that you can make a more informed decision about if you have that data. +VICTORIA: That makes a lot of sense. And I'll be sharing this episode with all of my friends and everything on Instagram as well. +LAUREN: [laughs] +VICTORIA: Great information to put out there. And what's on the horizon for you? What are the big challenges that you see coming up for Cofertility in the next months or year? +LAUREN: I think really like scale is what we're focused on. So we've started making matches; it feels great. I want us to be prepared to do those at scale. We are seeing no slowdown in terms of people who are interested in this. And so, making sure that our team is ready and able to handle that demand is my absolute top priority. So I think scale is top of mind. +I think making sure we're optimizing our experience for that is really important. So how do we make sure that everyone is having a magical, smooth experience, both through our digital experience but also if they're on the phone with someone from our team or if they're reading our materials at the fertility clinic? Like, how do we ensure that that's a great experience all around? +VICTORIA: Right, that makes sense. And right now, is Cofertility specific to a certain location, or is it nationwide? +LAUREN: Nationwide throughout the U.S. +VICTORIA: Wonderful. And you yourself are based in California, right? +LAUREN: Yes, I'm based in Los Angeles. And our team is fully remote, which has been a really exciting thing to do. We're in different time zones and have a lot of opportunity to visit people in different cities, which is nice. +VICTORIA: Oh, that's great, yeah. How do you help build that culture remotely with a brand-new team? +LAUREN: So, for us, I think we're very intentional about having team off sites at least twice a year. We also get together for different things like planning meetings or conferences that are really relevant to us. But I think part of it, too, is really around different touchpoints throughout the day. And we have a daily stand-up. +We also are clear about which hours everyone sort of overlaps based on their time zones and making sure that people are available during those windows and then giving everyone flexibility otherwise in terms of when it makes the most sense to do their work, not being too prescriptive. And really, again, encouraging people to have a life outside work, I think, makes it so that we get the best out of our team. +VICTORIA: Right, that makes a lot of sense. Yeah, we've got similar...at thoughtbot, we have in-person meetups once or twice a year and then go to different conferences and things together. And I think some people do miss a little bit of the office experience, but for the most part, everyone is happy to put it that way. [laughs] +LAUREN: Yeah, it's definitely...I think for sure it has its pros and cons. I think what I love about it is that we're not limited with talent. Our team truly, like, [laughs] we have people...we have someone in Oakland, someone in Miami, someone in Charleston, someone in Boston, someone in New York City. Like, the fact that we're not limited because of geography feels great. And I admittedly really love the ability to see my daughter throughout the day and feel like I don't have to stress over how much time I'm spending commuting. So I can't see myself ever going back. +VICTORIA: That's right, and LA is certainly a place to have a long commute. [laughter] And have you gotten any benefit out of local networking and community around Los Angeles or Southern California? +LAUREN: Yes, absolutely. Even this Friday night, I'm going to a female founder dinner. I have something coming up in a couple of weeks with this group of women's health founders that I really love. It's so, so valuable to have people in your network that are both local and get the life that you're living while you're doing it. I think having people understand why your life is the way it is while you're building a company is really quite nice. So there are founder communities everywhere but seeking those out early is definitely helpful. +VICTORIA: And then if you have a remote team, then each team member can have that local community, so you're 10x-ing. [laughs] +LAUREN: Completely. +VICTORIA: Yeah, wonderful. Is there anything else, anything that you think I should have asked you that I haven't asked yet? +LAUREN: No. I think one thing I would encourage is when you're trying to figure out your go-to-market approach, what the strategy is going to be. I'm a big fan of getting everything really in slides. Get it in slides and bring in some people you trust. Talk to your advisors, talk to your investors, talk to your co-founders or your team and say, "Hey, these are the three ways this could go. Here are pros and cons of each one," and making a decision that way. +I think when we try to do it where it's like all in someone's head, and you're not getting it out on paper with pros and cons, it can feel like a really, really hard decision. But when you see things on paper, and you're able to get the opinion of people you trust, everything is able to come to fruition much more quickly, and you can get to a decision faster. +VICTORIA: Right. So you're probably really buzzing with ideas early on and finding ways to communicate those and get it so that you can practice talking about it to somebody else. Makes sense. +LAUREN: Yeah. It's like, how do you socialize it? That's a great way to do it. +VICTORIA: Yeah, well, wonderful. This has been a really enjoyable conversation. I appreciate you coming on the show so much, and thank you for sharing all about Cofertility with us. Any other final takeaways for our listeners? +LAUREN: Thanks so much for having me. If you're interested at all in what we're doing or it would be helpful to connect, our website is cofertility.com. You can find me on Instagram at @laurenmakler, L-A-U-R-E-N-M-A-K-L-E-R. Happy to chat really about anything as it relates to building a company, or your fertility, or just questions you have in general. I would love to chat. +VICTORIA: Thank you so much. And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening, and see you next time. +ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com. + + + Lauren Makler is Co-Founder, and CEO of Cofertility, a human-first fertility ecosystem rewriting the egg freezing and egg donation experience.

+ +

Victoria talks to Lauren about tackling the access issues around egg freezing and donation and hoping to bring down the cost, leaving a company like Uber and starting her own business, and figuring out a go-to-market approach and what that strategy should look like.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Lauren Makler, Co-Founder, and CEO of Cofertility, a human-first fertility ecosystem rewriting the egg freezing and egg donation experience. Lauren, thank you for joining me.

+ +

LAUREN: Thanks for having me. I'm so excited for this.

+ +

VICTORIA: Me too. I want to hear all about Cofertility. Can you tell me a little bit more about the platform that you built?

+ +

LAUREN: Absolutely. Cofertility is really like you said; we're a fertility ecosystem. And at our core, we're enabling women to freeze their eggs for free when they donate half of the eggs retrieved to a family that can't otherwise conceive, providing support and education for everyone involved along the way. You know, we're serving two very different audiences. One side of our business, our Freeze by Co, is targeted at women between the ages of 21 and 40 who might be interested in preserving their fertility.

+ +

We know that really the best time to freeze your eggs, unfortunately, is when you can least afford it. And so we've really taken on this access issue and hoping to bring down the cost on that front. And then our Family by Co business is for intended parents who need the help of an egg donor to have a child, so that could be anyone from people who struggle with infertility, or gay dads, cancer survivors, et cetera.

+ +

There are a lot of people that really rely on third-party reproduction to have a family, and we think it's time to really move that industry forward, and we're doing that in a lot of ways. So that's at a high level; happy to dig in more on any part of that. But we launched in October, and things have been going well ever since.

+ +

VICTORIA: Wonderful. Yeah, I want to ask you more about...you mentioned the problem that you identified with when people who are most ready to freeze their eggs probably can't afford it. [laughs] But how did you really identify that problem and think I should start a company around this?

+ +

LAUREN: Yeah, so it's a two-part problem. I think we see a big problem on the egg-freezing side, which is truly cost. I think we know that women are starting families later than ever. For the first time in U.S. history, the average age of women giving birth now is 30, which is the highest on record. And the experimental label from egg freezing was removed in 2012, and so it's become much more mainstream for women to do it.

+ +

However, the cost to do it in the U.S. is between; I want to say, $12,000-20,000 to do it, plus yearly storage fees. And there are some women who have access to doing it through their large employer, but for the majority of people, that's just not the case. And so, for women who are really trying to prioritize their career or their education or maybe haven't found a partner yet, egg freezing can be a great option.

+ +

And certainly, it's not an insurance policy by any means, and it's not a guarantee. But studies show that if you experience infertility later in life and you did freeze your eggs, you're much more likely to have a child than not. And so we see it as a great backup option. But again, cost is just truly a huge problem.

+ +

And then, on the egg donation side, there are tons of families that rely on egg donation to have a baby. And I'm someone...I should mention, too, personally, years ago...I'll make a very long story very short here. Years ago, I was diagnosed with an incredibly rare abdominal disease that put into question my ability to have a biological child someday. And so, I started to look into what my options might be, and egg donation came up.

+ +

And when I looked at what was happening in the space, I just couldn't believe how antiquated it was. And truly, for lack of a better word, how icky it felt. It seemed really transactional and impersonal for everyone involved. And what I realized was that it was really rooted in the stigma around egg donation that comes from cash compensation for donors.

+ +

So traditionally, a donor is paid anywhere from $8,000 to $100,000 for her eggs, depending on, unfortunately, her pedigree or sometimes her heritage. Something that might be, you know, a donor that's harder to find might require more compensation the way it's done today. And so we actually saw that many women who are interested in helping another family grow through egg donation can actually be off-put by this idea of cash for their eggs. It's like, ooh, am I selling my eggs, or how do I feel about that? And it actually turns people off when it might otherwise have been something they wanted to explore.

+ +

It also, I think, leaves intended parents without options that they need and really hurts the LGBTQ community that relies on egg donation for family planning. So there's a lot there. And we felt that that was something that if we remove cash compensation, perhaps it's something that really opens up the pie of women that are open to and interested in egg donation. And it also might really honor the donor-conceived person on the end of it more than what's happening today.

+ +

Studies have come out that show that donor-conceived adults find the exchange of money for donor eggs to be wrong and that they can actually find it disturbing that money was exchanged for their own conception. So our model takes out cash compensation and instead gives women something that they're excited about, which is preserving their own fertility as well and really sets up everyone involved for success.

+ +

VICTORIA: Yeah. I saw that in your literature, you bring this human-centered design to how you built the platform, which I think speaks to a little bit of what you're describing there. And do you think that being a woman founder yourself allows you to relate and empathize with women who have this unique perspective or a different perspective on how egg donation should work?

+ +

LAUREN: Yes, egg donation and egg freezing, honestly. I think I mentioned a little bit about my own experience. Both of my two co-founders have also really, really been through it when it comes to their journeys to parenthood; both of them have been through IVF. And one of them says, you know, her biggest regret in life is that she didn't freeze her eggs at 25. And now, instead of just sitting in that, she's building a company to help other women not have that same regret.

+ +

So building the company we wished existed when we were younger lets us build something that truly is empathetic and human-centered. And it's unfortunate that so much of healthcare is built and designed by people who, while maybe they have good intentions, they're not building from a place of experience, and I think reproductive health is one of those. I think women need to be involved in designing those solutions, and too often, they're not.

+ +

VICTORIA: Right. Yes. That makes a lot of sense to me. And I want to talk more about you and your three co-founders and how quickly all this has come together. So, how did you know that your team of co-founders was the right team that these are the people you wanted to start this with?

+ +

LAUREN: Yeah, it's an interesting question on so many fronts. I think there are people who spend a really long time, like co-founder dating, and use frameworks for evaluating co-founders, and the truth of it for us is that it all happened very quickly. Halle, who is the person who connected the three of us, she is one of my co-founders, and she's just someone I had long admired in digital health and women's health.

+ +

And there was a day where...we peripherally knew each other. And she slid into my DMs on Instagram. Like, you never know where a great contact may come from. And she asked me what I was up to, what I was working on, and the rest is history. I told her I had just left...I spent eight and a half years at Uber and launched new markets of Uber across the East Coast and then started a business line at Uber called Uber Health, and Halle had always followed my trajectory there.

+ +

And when she reached out to me, it was like, [gasps] what's it going to be about? And when it ended up that she had an idea centered around egg freezing and egg donation, given the experience I had had with my own fertility journey, it just felt like how could this not be the right thing for me to go build? So I would say gut instinct is really what it comes down to.

+ +

Halle and Arielle, our third co-founder, had worked together a bit in their past lives. Halle built a company called Natalist, which is fertility, pregnancy tests, ovulation kits, and prenatal vitamins, things like that. And Arielle had actually built the first iteration of Cofertility, which was a fertility content site. And they had had that rapport already, and so that was something that I valued quite a bit. Really talking to some references and getting opinions of people you trust, but your gut, more than anything, will help you answer that question.

+ +

VICTORIA: Right. And sounds like there's that shared experience and mutual respect, which goes a long way. [laughs]

+ +

LAUREN: Yeah, that and also a shared vision. Like, if you're aligned with someone in the first month or so of talking about an idea, and when it goes from a little kernel to snowballing and becoming something real, I think it's a good signal. But if you're butting heads and disagreeing in that first really crucial time, it's probably a good idea to go in a different direction.

+ +

VICTORIA: Yeah. And thinking along those lines, were there decisions that were really easy to make, and what were those? And the second part of the question is what decisions were kind of challenging to make, and what made those decisions challenging?

+ +

LAUREN: It's funny. Halle was just like, "This idea is going to work, and I know it. Let's do it." I am someone who likes to see evidence before making a decision. And so I suggested in those first two weeks, like, let's get a survey together. Let's ask women, "Hey, would you actually be interested in egg donation if it meant that you got to keep half of the eggs for yourself and that there was no cash compensation involved?" So we asked a few influencers on Instagram to put out our Typeform, and within, like, I don't know, 24 hours, we had over 700 responses.

+ +

VICTORIA: Wow.

+ +

LAUREN: And it was a very resounding like, yes, this is something women were interested in. That gave me all the conviction I needed to go at this full force. And so I think having that proof point not only was valuable to help me get there, but it also helped investors get on board. I think some of the easy decisions were like there were certain investors that after meeting I just knew like, yes, this is someone I want to be working with over the next few years. This is someone who sees the same vision that we see.

+ +

And there were a few conversations with other potential investors where I was like, you know what? That's not who I want to work with. Again, it's like, I'm very big on my instincts as it relates to people and trusting that.

+ +

VICTORIA: Right. Yeah, that makes a lot of sense. And congratulations on raising your seed funding.

+ +

LAUREN: Thank you.

+ +

VICTORIA: And was that a stressful process? How did you feel after that happened?

+ +

LAUREN: Parts of it were stressful, for sure. I think the fact that I had never done it before was stressful. I like to call myself...before this, I was an intrapreneur. I pitched the idea of Uber Health to Uber executive leadership with a deck that was very similar to what you would pitch external investors with in a scenario like this. So I had gone through a little bit of that but never before had I done anything quite like this.

+ +

And so I felt very lucky to have Halle by my side through that process because it wasn't her first rodeo. But I would say trusting yourself and trusting that you can figure this out. It seems so much more intimidating than it needs to be. No one is expecting you to fully know how all of this stuff works. It's very figureoutable.

+ +

VICTORIA: And what obstacles did you face in the last year that you've been working on this?

+ +

LAUREN: The biggest obstacle, I would say, honestly came down to having the time to both get a company off the ground...and I like to imagine an aeroplane. You have to figure out what kind of plane you're building; then you have to find all the parts, then you have to build the plane. And then the goal upon launch, I can imagine it when I close my eyes. It is like getting the plane off the ground.

+ +

And with a startup, like you can imagine, there's always a bit of building the plane while you're flying it. But doing all of that over the last year, plus finding the right people to hire, is two full-time jobs. You're sourcing incredible candidates. You're meeting with them. You're pitching them the business. But you also need to evaluate whether or not they're as great as their resume makes them seem. Then you have to convince them to join your seed-stage startup, then check their references, and then put together their offer package, and then do all of their paperwork.

+ +

And it was like all of these things that I took for granted at Uber for so long of having recruiters, and having an HR team, [laughs] and all of those things that truly it is a full-time job plus building a company. So that, for me, was the hardest. And hiring just at that early stage is so, so important because you add one person, and that's like such a huge percentage of your team. So every hire has to be a great one, but you also can't wait too long to hire because then you miss your goals.

+ +

VICTORIA: Right. Yes. And there's lots of uncertainty going on in the world as well. I'm sure that makes hiring extra exciting.

+ +

LAUREN: Yes. I mean, exciting and also scary. I think exciting from the fact that there's great talent that's looking in a way that wasn't necessarily the case six months ago, but scary in that you have to...one of my biggest or things that keeps me up at night is like, what's the right timing to bring on new people so that your business scales appropriately but not too soon that you have people waiting around for the work to come?

+ +

VICTORIA: Right, yes. And speaking of scary, I can imagine the choice to leave a company like Uber and go and start your own business was thrilling. [laughs] Can you tell me more about how that happened, or what was the order of operations there?

+ +

LAUREN: I'll go back to my personal story a little bit. So I ended up with this disease that I had been diagnosed with. It was so rare and so not a lot of data on this disease that I decided it was...or these doctors were like, "You know what? Do you have a sister by any chance?" I was like, "What do you mean?" They were like, "You know, it's too risky for you to freeze your eggs just because we don't have any data on your disease. But if you have your sister freeze her eggs and donate them to you, you have them as a backup should you need them." So my incredible sister did that.

+ +

And I learned a lot about the process of donation even through that experience. And went on to have three surgeries and ultimately was able to conceive without using my sister's eggs which was crazy and exciting and definitely gave my doctors a shock, which was great. And when I had my daughter, it was like this light bulb went off of, like, I have to build something in reproductive health. If I'm spending my time building something, I want it to be spent giving people who want to have a child this amazing gift that I've been given.

+ +

And it was like an immediate amount of clarity. And so, after my maternity leave, I gave notice at Uber without a plan. I did not have a business idea. I did not have a job lined up. I was fortunate enough to be able to do that. But I almost think releasing myself of that is what gave me the freedom to think about other things. And it was within a day that Halle sent me that DM on Instagram without knowing I had given notice. So the universe works in mysterious ways.

+ +

VICTORIA: That's wonderful and so exciting and that you just had a baby and then to be in a position where you could start a company and almost feel like I don't have enough to do; [laughter] I want to start a new company too. [laughs]

+ +

LAUREN: I know. I ended up...the day we pitched our lead investors was my daughter's six-month birthday.

+ +

VICTORIA: That's amazing.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: How do you balance that, like, those needs of being a mom and maybe being sleep deprived, but also starting this incredibly important business that you're passionate about?

+ +

LAUREN: I mean, I'm very lucky that I have an amazing husband and sort of partner in all of this. We both are very involved in each other's work, and I highly recommend that if that's something you're open to. I think it gives you an outlet and someone to be invested in it with you but also more to talk about with your partner. [laughs]

+ +

But other than that, too, I think having boundaries. So I've been really, really specific with myself and with my team about what windows of time I'm with my daughter, and I'm meticulous about it. If that means on certain days, I wake up before she does so that I can get some work done so that I have two hours with her first thing in the morning, and then I'm off between the hours of 4:00 to 7:00 so that I can spend time with her. If that means getting back online at night, I'm down to do that. I just won't compromise the time with her.

+ +

And my team has been really respectful and honoring of that. And in turn, I really encourage everyone on my team to have a life outside work, whether that's with their children or their pets, or having physical activity, or things like that in their life. I think it's so important that we're not entirely defined by our startups. I think that's how people burn out really quickly. And it's like 2023, right? We don't need to be in this hustle culture where 100% of our time is focused on building our company. It's just not sustainable.

+ +

VICTORIA: Right. I like that you mentioned sustainability. And that's been a recurring theme I've seen where, yeah, the hustle culture leads to burnout. It isn't sustainable. So are there other cultural or values that you impart onto your team, this new team, that you're standing up to create that sustainability in that innovation that you want?

+ +

LAUREN: Yeah. I think one thing we've implemented...I would highly recommend actually Matt Mochary's CEO Curriculum. You can find it by Googling it, or I can share the link with you. And within his curriculum, he has something called The Magic Questions. And the magic questions it's like five or six questions where you ask everyone on your team, like, how would they rate their life at work? How would they rate working with the team? How's their personal life going? Like, you know, questions that you can quickly get to the root of something.

+ +

But then, aside from giving a rating for each of those questions, it asks like, "How would you take it to the next level?" And what I think implementing these questions has done is it's like each time we do it, it gives the leadership team something to act on of like, "Hey, I noticed a theme amongst the employees with this set of magic questions. Like, here are some things we can address to improve that for everyone."

+ +

And then there are also opportunities with each individual to say, "Hey, manager of this person, so and so called out that they're really struggling with prioritization this month, or they're really struggling with being split on these two projects. How can we help relieve that, or how can we dig in with that person so that the next time we ask these questions, that's not still an issue and that we've been able to take swift action to help improve that?"

+ +

I think that really helps to just stay close to what people are feeling and thinking. And it also gives people, I think, more self-awareness of how they're doing and what they can be intentional about and address for themselves as well.

+ +

VICTORIA: I like that. I'll have to look up that book and share it in our show notes as well and --

+ +

LAUREN: It's actually even all online. It's like a Google Doc you can look at.

+ +

VICTORIA: That's awesome.

+ +

LAUREN: And there's also a book called The Great CEO Within by Matt Mochary. But I love the book and the Google Doc version.

+ +

VICTORIA: That's awesome. And it sounds like you really pulled everything together so fast. [laughs] I'm curious about your background if you feel like there were...you mentioned that you pitched inwardly to Uber. But what else about your background kind of lends you to this leadership-founder skill set?

+ +

LAUREN: I mean, I joined Uber in 2013 when we had, I think, fewer than 200 employees, and we were in about 12 cities. So I very much knew startup life. And I understood this idea of sort of building the plane while you're flying it and saw that. And so I think that certainly has contributed to this. It's important when you're a founder to surround yourself with other founders and to have people that you can tap into at any point.

+ +

I'm in a few different Slack groups with different founders; some are healthcare founders, some women founders, some through the VCs that we've worked with where it's really easy to say, "Hey, which payroll tool are you using?" Or "Hey, like, how do I measure employee NPS?" Or "What tools are you using for this or that?" And if you can tap into other founders, you really can move a lot faster. You don't have to write your entire employee handbook from scratch because you can borrow from other people. I think that's one of the best hacks that I would recommend.

+ +

And then some of these books that I found that really do, you know, within that Matt Mochary book, it's like, here's a way to make candidate offers. Obviously, the book isn't doing the work for you, but it certainly is helping to give you a framework. And then the other piece is like, aside from your own team, I think bringing in some advisors who you trust and can go to for certain things. So two of our advisors are people I worked incredibly closely with at Uber and would trust with my life and so why not trust them with my company? So bringing them into the mix has been a real relief.

+ +

And then just sort of about your community. I think it takes a village to raise...I think, actually, I would compare launching a company to having a baby. So if having a baby takes a village, so does launching a company.

+ +

VICTORIA: Right. Or no founder is an island. [laughs]

+ +

LAUREN: Yeah, exactly.

+ +

VICTORIA: There's like a community, a whole group around that. I've heard, even in the episodes I've recorded, that it's a common theme among successful founders, which is heartwarming and understandable. So last question about just how it all got started. But if you could travel back in time to when you first decided you wanted to go after this opportunity, what advice would you give yourself now that you have all your present knowledge?

+ +

LAUREN: I say this even to our intended parents who are grappling with this decision of using an egg donor to have a baby: remain steadfast on the vision or the end goal and be flexible on the how. So if you're an intended parent, it's like, remain flexible, like, steadfast on this idea that you want to become a parent, but be flexible on the how.

+ +

With a company, I think stay true to what that ultimate vision is. So, for us, it's like help more people have babies on their own timeline and be flexible on the how, so exactly what our business model was, or exactly what our go-to-market approach would be, or exactly which product we were going to use to get there. I wish I had been a little bit more open to it being a winding road than I realized I needed to be at the beginning. So now I know that, and I'm open to any possibility as long as it gets us to the same place.

+ +

VICTORIA: Right, gotcha. Yeah, well, let me ask you then about your go-to-market strategy since you mentioned it. What was unique in your strategy there, especially to target the specific consumers that you want to with this app?

+ +

LAUREN: So I did follow a bit of an Uber approach, which is this idea of a soft launch. And the reason for that...so basically what we did was for the Freeze by Co side of our business, so for women who are interested in freezing, they have the option to join our split program where they donate half to intended parents and do it for free. Or they can join our Keep Program, where they freeze their eggs but keep 100% of the eggs for themselves. And we help do that along the way.

+ +

However, basically, we couldn't launch Family by Co to help people find donors until we had donors. So it made sense to launch the Freeze by Co side of our business first. And I wanted the ability to market to them when we didn't have the eyes of the whole industry on us, or we didn't have tons and tons of consumers reading our press or things like that just yet.

+ +

And so by soft launching with a quick beta Squarespace page, we were able to test our hypothesis, test our messaging, test our funnel, test our experience before really putting a ton of marketing spend behind it or having a ton of visibility into what we were doing. And I'm so, so grateful we did that.

+ +

It led us, like, we went through probably five different versions of our funnel before we got to our public launch, and our soft launch really afforded us the opportunity to do that. So by the time we turned on the Family by Co side of our business, we already had over 50 donors on day one for them because we had already gotten these women through the funnel.

+ +

VICTORIA: I love that. And that's something we talk a lot about with founders at thoughtbot is that idea of validating your product, and you talked about it with your Instagram poll that you did with influencers. And the way you're talking about your go-to-market strategy is that you wanted to make sure that even though you knew this is what you wanted to do, that you had the right approach and that you could create something that consumers actually wanted to buy and had trust in.

+ +

LAUREN: Mm-hmm, totally.

+ +

VICTORIA: You launched in October 2022. Are there any results post-launch that surprised you?

+ +

LAUREN: I feel so grateful that our launch truly exceeded my expectations. So the interest from women in our programs has been overwhelming, like overwhelming in a good way. And then intended parents are thrilled about it. So we are making matches every day of these intended parents and these donors. And every time we make a match, I'm like, oh my God, it feels like Christmas morning. You're helping people find their path towards growing their family, and there's nothing that feels better than that. I don't think that feeling is ever going to go away, so I'm thrilled about it.

+ +

But it doesn't mean that it's not hard. I think back to that analogy of like having a baby, you know, you launch this company. You hope it's received. You count ten fingers, ten toes, hope that it's received, hope that it's received. It is, but then you have the demand, and you have inbound on partnership opportunities, and you have managing the demand and handling the leads and things like that. And it's like so much more than you expect.

+ +

It's like the same feeling of having a newborn of, like, [gasps] how are we going to do all this? Am I going to stay up all night to manage this? Or how do we handle what we're seeing? And so it's a lot, and figuring out what this new normal is is something that my team and I are working through every day.

+ +

VICTORIA: What's wonderful is that the surprise feels even better than you thought it would. [laughs]

+ +

LAUREN: Yes.

+ +

VICTORIA: Wonderful. For myself, as I'm in my 30s and I'm married and, you know, I'm not thinking it about at some point in the future. But what advice do you think you want women to think about regarding their fertility at any age, like if you could talk to consumers directly like you are now? [laughs]

+ +

LAUREN: Totally. Just that it's never too soon to ask those questions. And the information you need and should want is like inside your body but ready to be shared with you. So by having a consult with a fertility clinic, and that's something my team could help you with, you can learn about your prospects for having a baby and understanding how fertile you are.

+ +

And just because, you know, they say, "Oh, as long as you're under a certain age, you shouldn't have a problem," doesn't mean that that's the case. One of my co-founders was 28 when she started trying to conceive and was completely blindsided that this was going to be a real struggle for her, and that breaks my heart. It doesn't need to be like that. If we're more proactive and we start asking these questions younger, then we can actually do something about it.

+ +

So your fertility is really about your egg quantity and your egg quality, and both of those things are things that can be tested and measured. And I think I'm someone who loves data. And having that data, I think, can help enable you to make decisions about how you can best move forward, and for some, it might mean having a baby soon. For others, it might mean freezing your eggs. For others, it might be a waiting scenario. But that's something that you can make a more informed decision about if you have that data.

+ +

VICTORIA: That makes a lot of sense. And I'll be sharing this episode with all of my friends and everything on Instagram as well.

+ +

LAUREN: [laughs]

+ +

VICTORIA: Great information to put out there. And what's on the horizon for you? What are the big challenges that you see coming up for Cofertility in the next months or year?

+ +

LAUREN: I think really like scale is what we're focused on. So we've started making matches; it feels great. I want us to be prepared to do those at scale. We are seeing no slowdown in terms of people who are interested in this. And so, making sure that our team is ready and able to handle that demand is my absolute top priority. So I think scale is top of mind.

+ +

I think making sure we're optimizing our experience for that is really important. So how do we make sure that everyone is having a magical, smooth experience, both through our digital experience but also if they're on the phone with someone from our team or if they're reading our materials at the fertility clinic? Like, how do we ensure that that's a great experience all around?

+ +

VICTORIA: Right, that makes sense. And right now, is Cofertility specific to a certain location, or is it nationwide?

+ +

LAUREN: Nationwide throughout the U.S.

+ +

VICTORIA: Wonderful. And you yourself are based in California, right?

+ +

LAUREN: Yes, I'm based in Los Angeles. And our team is fully remote, which has been a really exciting thing to do. We're in different time zones and have a lot of opportunity to visit people in different cities, which is nice.

+ +

VICTORIA: Oh, that's great, yeah. How do you help build that culture remotely with a brand-new team?

+ +

LAUREN: So, for us, I think we're very intentional about having team off sites at least twice a year. We also get together for different things like planning meetings or conferences that are really relevant to us. But I think part of it, too, is really around different touchpoints throughout the day. And we have a daily stand-up.

+ +

We also are clear about which hours everyone sort of overlaps based on their time zones and making sure that people are available during those windows and then giving everyone flexibility otherwise in terms of when it makes the most sense to do their work, not being too prescriptive. And really, again, encouraging people to have a life outside work, I think, makes it so that we get the best out of our team.

+ +

VICTORIA: Right, that makes a lot of sense. Yeah, we've got similar...at thoughtbot, we have in-person meetups once or twice a year and then go to different conferences and things together. And I think some people do miss a little bit of the office experience, but for the most part, everyone is happy to put it that way. [laughs]

+ +

LAUREN: Yeah, it's definitely...I think for sure it has its pros and cons. I think what I love about it is that we're not limited with talent. Our team truly, like, [laughs] we have people...we have someone in Oakland, someone in Miami, someone in Charleston, someone in Boston, someone in New York City. Like, the fact that we're not limited because of geography feels great. And I admittedly really love the ability to see my daughter throughout the day and feel like I don't have to stress over how much time I'm spending commuting. So I can't see myself ever going back.

+ +

VICTORIA: That's right, and LA is certainly a place to have a long commute. [laughter] And have you gotten any benefit out of local networking and community around Los Angeles or Southern California?

+ +

LAUREN: Yes, absolutely. Even this Friday night, I'm going to a female founder dinner. I have something coming up in a couple of weeks with this group of women's health founders that I really love. It's so, so valuable to have people in your network that are both local and get the life that you're living while you're doing it. I think having people understand why your life is the way it is while you're building a company is really quite nice. So there are founder communities everywhere but seeking those out early is definitely helpful.

+ +

VICTORIA: And then if you have a remote team, then each team member can have that local community, so you're 10x-ing. [laughs]

+ +

LAUREN: Completely.

+ +

VICTORIA: Yeah, wonderful. Is there anything else, anything that you think I should have asked you that I haven't asked yet?

+ +

LAUREN: No. I think one thing I would encourage is when you're trying to figure out your go-to-market approach, what the strategy is going to be. I'm a big fan of getting everything really in slides. Get it in slides and bring in some people you trust. Talk to your advisors, talk to your investors, talk to your co-founders or your team and say, "Hey, these are the three ways this could go. Here are pros and cons of each one," and making a decision that way.

+ +

I think when we try to do it where it's like all in someone's head, and you're not getting it out on paper with pros and cons, it can feel like a really, really hard decision. But when you see things on paper, and you're able to get the opinion of people you trust, everything is able to come to fruition much more quickly, and you can get to a decision faster.

+ +

VICTORIA: Right. So you're probably really buzzing with ideas early on and finding ways to communicate those and get it so that you can practice talking about it to somebody else. Makes sense.

+ +

LAUREN: Yeah. It's like, how do you socialize it? That's a great way to do it.

+ +

VICTORIA: Yeah, well, wonderful. This has been a really enjoyable conversation. I appreciate you coming on the show so much, and thank you for sharing all about Cofertility with us. Any other final takeaways for our listeners?

+ +

LAUREN: Thanks so much for having me. If you're interested at all in what we're doing or it would be helpful to connect, our website is cofertility.com. You can find me on Instagram at @laurenmakler, L-A-U-R-E-N-M-A-K-L-E-R. Happy to chat really about anything as it relates to building a company, or your fertility, or just questions you have in general. I would love to chat.

+ +

VICTORIA: Thank you so much. And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening, and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lauren Makler is Co-Founder, and CEO of Cofertility, a human-first fertility ecosystem rewriting the egg freezing and egg donation experience.

+ +

Victoria talks to Lauren about tackling the access issues around egg freezing and donation and hoping to bring down the cost, leaving a company like Uber and starting her own business, and figuring out a go-to-market approach and what that strategy should look like.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Lauren Makler, Co-Founder, and CEO of Cofertility, a human-first fertility ecosystem rewriting the egg freezing and egg donation experience. Lauren, thank you for joining me.

+ +

LAUREN: Thanks for having me. I'm so excited for this.

+ +

VICTORIA: Me too. I want to hear all about Cofertility. Can you tell me a little bit more about the platform that you built?

+ +

LAUREN: Absolutely. Cofertility is really like you said; we're a fertility ecosystem. And at our core, we're enabling women to freeze their eggs for free when they donate half of the eggs retrieved to a family that can't otherwise conceive, providing support and education for everyone involved along the way. You know, we're serving two very different audiences. One side of our business, our Freeze by Co, is targeted at women between the ages of 21 and 40 who might be interested in preserving their fertility.

+ +

We know that really the best time to freeze your eggs, unfortunately, is when you can least afford it. And so we've really taken on this access issue and hoping to bring down the cost on that front. And then our Family by Co business is for intended parents who need the help of an egg donor to have a child, so that could be anyone from people who struggle with infertility, or gay dads, cancer survivors, et cetera.

+ +

There are a lot of people that really rely on third-party reproduction to have a family, and we think it's time to really move that industry forward, and we're doing that in a lot of ways. So that's at a high level; happy to dig in more on any part of that. But we launched in October, and things have been going well ever since.

+ +

VICTORIA: Wonderful. Yeah, I want to ask you more about...you mentioned the problem that you identified with when people who are most ready to freeze their eggs probably can't afford it. [laughs] But how did you really identify that problem and think I should start a company around this?

+ +

LAUREN: Yeah, so it's a two-part problem. I think we see a big problem on the egg-freezing side, which is truly cost. I think we know that women are starting families later than ever. For the first time in U.S. history, the average age of women giving birth now is 30, which is the highest on record. And the experimental label from egg freezing was removed in 2012, and so it's become much more mainstream for women to do it.

+ +

However, the cost to do it in the U.S. is between; I want to say, $12,000-20,000 to do it, plus yearly storage fees. And there are some women who have access to doing it through their large employer, but for the majority of people, that's just not the case. And so, for women who are really trying to prioritize their career or their education or maybe haven't found a partner yet, egg freezing can be a great option.

+ +

And certainly, it's not an insurance policy by any means, and it's not a guarantee. But studies show that if you experience infertility later in life and you did freeze your eggs, you're much more likely to have a child than not. And so we see it as a great backup option. But again, cost is just truly a huge problem.

+ +

And then, on the egg donation side, there are tons of families that rely on egg donation to have a baby. And I'm someone...I should mention, too, personally, years ago...I'll make a very long story very short here. Years ago, I was diagnosed with an incredibly rare abdominal disease that put into question my ability to have a biological child someday. And so, I started to look into what my options might be, and egg donation came up.

+ +

And when I looked at what was happening in the space, I just couldn't believe how antiquated it was. And truly, for lack of a better word, how icky it felt. It seemed really transactional and impersonal for everyone involved. And what I realized was that it was really rooted in the stigma around egg donation that comes from cash compensation for donors.

+ +

So traditionally, a donor is paid anywhere from $8,000 to $100,000 for her eggs, depending on, unfortunately, her pedigree or sometimes her heritage. Something that might be, you know, a donor that's harder to find might require more compensation the way it's done today. And so we actually saw that many women who are interested in helping another family grow through egg donation can actually be off-put by this idea of cash for their eggs. It's like, ooh, am I selling my eggs, or how do I feel about that? And it actually turns people off when it might otherwise have been something they wanted to explore.

+ +

It also, I think, leaves intended parents without options that they need and really hurts the LGBTQ community that relies on egg donation for family planning. So there's a lot there. And we felt that that was something that if we remove cash compensation, perhaps it's something that really opens up the pie of women that are open to and interested in egg donation. And it also might really honor the donor-conceived person on the end of it more than what's happening today.

+ +

Studies have come out that show that donor-conceived adults find the exchange of money for donor eggs to be wrong and that they can actually find it disturbing that money was exchanged for their own conception. So our model takes out cash compensation and instead gives women something that they're excited about, which is preserving their own fertility as well and really sets up everyone involved for success.

+ +

VICTORIA: Yeah. I saw that in your literature, you bring this human-centered design to how you built the platform, which I think speaks to a little bit of what you're describing there. And do you think that being a woman founder yourself allows you to relate and empathize with women who have this unique perspective or a different perspective on how egg donation should work?

+ +

LAUREN: Yes, egg donation and egg freezing, honestly. I think I mentioned a little bit about my own experience. Both of my two co-founders have also really, really been through it when it comes to their journeys to parenthood; both of them have been through IVF. And one of them says, you know, her biggest regret in life is that she didn't freeze her eggs at 25. And now, instead of just sitting in that, she's building a company to help other women not have that same regret.

+ +

So building the company we wished existed when we were younger lets us build something that truly is empathetic and human-centered. And it's unfortunate that so much of healthcare is built and designed by people who, while maybe they have good intentions, they're not building from a place of experience, and I think reproductive health is one of those. I think women need to be involved in designing those solutions, and too often, they're not.

+ +

VICTORIA: Right. Yes. That makes a lot of sense to me. And I want to talk more about you and your three co-founders and how quickly all this has come together. So, how did you know that your team of co-founders was the right team that these are the people you wanted to start this with?

+ +

LAUREN: Yeah, it's an interesting question on so many fronts. I think there are people who spend a really long time, like co-founder dating, and use frameworks for evaluating co-founders, and the truth of it for us is that it all happened very quickly. Halle, who is the person who connected the three of us, she is one of my co-founders, and she's just someone I had long admired in digital health and women's health.

+ +

And there was a day where...we peripherally knew each other. And she slid into my DMs on Instagram. Like, you never know where a great contact may come from. And she asked me what I was up to, what I was working on, and the rest is history. I told her I had just left...I spent eight and a half years at Uber and launched new markets of Uber across the East Coast and then started a business line at Uber called Uber Health, and Halle had always followed my trajectory there.

+ +

And when she reached out to me, it was like, [gasps] what's it going to be about? And when it ended up that she had an idea centered around egg freezing and egg donation, given the experience I had had with my own fertility journey, it just felt like how could this not be the right thing for me to go build? So I would say gut instinct is really what it comes down to.

+ +

Halle and Arielle, our third co-founder, had worked together a bit in their past lives. Halle built a company called Natalist, which is fertility, pregnancy tests, ovulation kits, and prenatal vitamins, things like that. And Arielle had actually built the first iteration of Cofertility, which was a fertility content site. And they had had that rapport already, and so that was something that I valued quite a bit. Really talking to some references and getting opinions of people you trust, but your gut, more than anything, will help you answer that question.

+ +

VICTORIA: Right. And sounds like there's that shared experience and mutual respect, which goes a long way. [laughs]

+ +

LAUREN: Yeah, that and also a shared vision. Like, if you're aligned with someone in the first month or so of talking about an idea, and when it goes from a little kernel to snowballing and becoming something real, I think it's a good signal. But if you're butting heads and disagreeing in that first really crucial time, it's probably a good idea to go in a different direction.

+ +

VICTORIA: Yeah. And thinking along those lines, were there decisions that were really easy to make, and what were those? And the second part of the question is what decisions were kind of challenging to make, and what made those decisions challenging?

+ +

LAUREN: It's funny. Halle was just like, "This idea is going to work, and I know it. Let's do it." I am someone who likes to see evidence before making a decision. And so I suggested in those first two weeks, like, let's get a survey together. Let's ask women, "Hey, would you actually be interested in egg donation if it meant that you got to keep half of the eggs for yourself and that there was no cash compensation involved?" So we asked a few influencers on Instagram to put out our Typeform, and within, like, I don't know, 24 hours, we had over 700 responses.

+ +

VICTORIA: Wow.

+ +

LAUREN: And it was a very resounding like, yes, this is something women were interested in. That gave me all the conviction I needed to go at this full force. And so I think having that proof point not only was valuable to help me get there, but it also helped investors get on board. I think some of the easy decisions were like there were certain investors that after meeting I just knew like, yes, this is someone I want to be working with over the next few years. This is someone who sees the same vision that we see.

+ +

And there were a few conversations with other potential investors where I was like, you know what? That's not who I want to work with. Again, it's like, I'm very big on my instincts as it relates to people and trusting that.

+ +

VICTORIA: Right. Yeah, that makes a lot of sense. And congratulations on raising your seed funding.

+ +

LAUREN: Thank you.

+ +

VICTORIA: And was that a stressful process? How did you feel after that happened?

+ +

LAUREN: Parts of it were stressful, for sure. I think the fact that I had never done it before was stressful. I like to call myself...before this, I was an intrapreneur. I pitched the idea of Uber Health to Uber executive leadership with a deck that was very similar to what you would pitch external investors with in a scenario like this. So I had gone through a little bit of that but never before had I done anything quite like this.

+ +

And so I felt very lucky to have Halle by my side through that process because it wasn't her first rodeo. But I would say trusting yourself and trusting that you can figure this out. It seems so much more intimidating than it needs to be. No one is expecting you to fully know how all of this stuff works. It's very figureoutable.

+ +

VICTORIA: And what obstacles did you face in the last year that you've been working on this?

+ +

LAUREN: The biggest obstacle, I would say, honestly came down to having the time to both get a company off the ground...and I like to imagine an aeroplane. You have to figure out what kind of plane you're building; then you have to find all the parts, then you have to build the plane. And then the goal upon launch, I can imagine it when I close my eyes. It is like getting the plane off the ground.

+ +

And with a startup, like you can imagine, there's always a bit of building the plane while you're flying it. But doing all of that over the last year, plus finding the right people to hire, is two full-time jobs. You're sourcing incredible candidates. You're meeting with them. You're pitching them the business. But you also need to evaluate whether or not they're as great as their resume makes them seem. Then you have to convince them to join your seed-stage startup, then check their references, and then put together their offer package, and then do all of their paperwork.

+ +

And it was like all of these things that I took for granted at Uber for so long of having recruiters, and having an HR team, [laughs] and all of those things that truly it is a full-time job plus building a company. So that, for me, was the hardest. And hiring just at that early stage is so, so important because you add one person, and that's like such a huge percentage of your team. So every hire has to be a great one, but you also can't wait too long to hire because then you miss your goals.

+ +

VICTORIA: Right. Yes. And there's lots of uncertainty going on in the world as well. I'm sure that makes hiring extra exciting.

+ +

LAUREN: Yes. I mean, exciting and also scary. I think exciting from the fact that there's great talent that's looking in a way that wasn't necessarily the case six months ago, but scary in that you have to...one of my biggest or things that keeps me up at night is like, what's the right timing to bring on new people so that your business scales appropriately but not too soon that you have people waiting around for the work to come?

+ +

VICTORIA: Right, yes. And speaking of scary, I can imagine the choice to leave a company like Uber and go and start your own business was thrilling. [laughs] Can you tell me more about how that happened, or what was the order of operations there?

+ +

LAUREN: I'll go back to my personal story a little bit. So I ended up with this disease that I had been diagnosed with. It was so rare and so not a lot of data on this disease that I decided it was...or these doctors were like, "You know what? Do you have a sister by any chance?" I was like, "What do you mean?" They were like, "You know, it's too risky for you to freeze your eggs just because we don't have any data on your disease. But if you have your sister freeze her eggs and donate them to you, you have them as a backup should you need them." So my incredible sister did that.

+ +

And I learned a lot about the process of donation even through that experience. And went on to have three surgeries and ultimately was able to conceive without using my sister's eggs which was crazy and exciting and definitely gave my doctors a shock, which was great. And when I had my daughter, it was like this light bulb went off of, like, I have to build something in reproductive health. If I'm spending my time building something, I want it to be spent giving people who want to have a child this amazing gift that I've been given.

+ +

And it was like an immediate amount of clarity. And so, after my maternity leave, I gave notice at Uber without a plan. I did not have a business idea. I did not have a job lined up. I was fortunate enough to be able to do that. But I almost think releasing myself of that is what gave me the freedom to think about other things. And it was within a day that Halle sent me that DM on Instagram without knowing I had given notice. So the universe works in mysterious ways.

+ +

VICTORIA: That's wonderful and so exciting and that you just had a baby and then to be in a position where you could start a company and almost feel like I don't have enough to do; [laughter] I want to start a new company too. [laughs]

+ +

LAUREN: I know. I ended up...the day we pitched our lead investors was my daughter's six-month birthday.

+ +

VICTORIA: That's amazing.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: How do you balance that, like, those needs of being a mom and maybe being sleep deprived, but also starting this incredibly important business that you're passionate about?

+ +

LAUREN: I mean, I'm very lucky that I have an amazing husband and sort of partner in all of this. We both are very involved in each other's work, and I highly recommend that if that's something you're open to. I think it gives you an outlet and someone to be invested in it with you but also more to talk about with your partner. [laughs]

+ +

But other than that, too, I think having boundaries. So I've been really, really specific with myself and with my team about what windows of time I'm with my daughter, and I'm meticulous about it. If that means on certain days, I wake up before she does so that I can get some work done so that I have two hours with her first thing in the morning, and then I'm off between the hours of 4:00 to 7:00 so that I can spend time with her. If that means getting back online at night, I'm down to do that. I just won't compromise the time with her.

+ +

And my team has been really respectful and honoring of that. And in turn, I really encourage everyone on my team to have a life outside work, whether that's with their children or their pets, or having physical activity, or things like that in their life. I think it's so important that we're not entirely defined by our startups. I think that's how people burn out really quickly. And it's like 2023, right? We don't need to be in this hustle culture where 100% of our time is focused on building our company. It's just not sustainable.

+ +

VICTORIA: Right. I like that you mentioned sustainability. And that's been a recurring theme I've seen where, yeah, the hustle culture leads to burnout. It isn't sustainable. So are there other cultural or values that you impart onto your team, this new team, that you're standing up to create that sustainability in that innovation that you want?

+ +

LAUREN: Yeah. I think one thing we've implemented...I would highly recommend actually Matt Mochary's CEO Curriculum. You can find it by Googling it, or I can share the link with you. And within his curriculum, he has something called The Magic Questions. And the magic questions it's like five or six questions where you ask everyone on your team, like, how would they rate their life at work? How would they rate working with the team? How's their personal life going? Like, you know, questions that you can quickly get to the root of something.

+ +

But then, aside from giving a rating for each of those questions, it asks like, "How would you take it to the next level?" And what I think implementing these questions has done is it's like each time we do it, it gives the leadership team something to act on of like, "Hey, I noticed a theme amongst the employees with this set of magic questions. Like, here are some things we can address to improve that for everyone."

+ +

And then there are also opportunities with each individual to say, "Hey, manager of this person, so and so called out that they're really struggling with prioritization this month, or they're really struggling with being split on these two projects. How can we help relieve that, or how can we dig in with that person so that the next time we ask these questions, that's not still an issue and that we've been able to take swift action to help improve that?"

+ +

I think that really helps to just stay close to what people are feeling and thinking. And it also gives people, I think, more self-awareness of how they're doing and what they can be intentional about and address for themselves as well.

+ +

VICTORIA: I like that. I'll have to look up that book and share it in our show notes as well and --

+ +

LAUREN: It's actually even all online. It's like a Google Doc you can look at.

+ +

VICTORIA: That's awesome.

+ +

LAUREN: And there's also a book called The Great CEO Within by Matt Mochary. But I love the book and the Google Doc version.

+ +

VICTORIA: That's awesome. And it sounds like you really pulled everything together so fast. [laughs] I'm curious about your background if you feel like there were...you mentioned that you pitched inwardly to Uber. But what else about your background kind of lends you to this leadership-founder skill set?

+ +

LAUREN: I mean, I joined Uber in 2013 when we had, I think, fewer than 200 employees, and we were in about 12 cities. So I very much knew startup life. And I understood this idea of sort of building the plane while you're flying it and saw that. And so I think that certainly has contributed to this. It's important when you're a founder to surround yourself with other founders and to have people that you can tap into at any point.

+ +

I'm in a few different Slack groups with different founders; some are healthcare founders, some women founders, some through the VCs that we've worked with where it's really easy to say, "Hey, which payroll tool are you using?" Or "Hey, like, how do I measure employee NPS?" Or "What tools are you using for this or that?" And if you can tap into other founders, you really can move a lot faster. You don't have to write your entire employee handbook from scratch because you can borrow from other people. I think that's one of the best hacks that I would recommend.

+ +

And then some of these books that I found that really do, you know, within that Matt Mochary book, it's like, here's a way to make candidate offers. Obviously, the book isn't doing the work for you, but it certainly is helping to give you a framework. And then the other piece is like, aside from your own team, I think bringing in some advisors who you trust and can go to for certain things. So two of our advisors are people I worked incredibly closely with at Uber and would trust with my life and so why not trust them with my company? So bringing them into the mix has been a real relief.

+ +

And then just sort of about your community. I think it takes a village to raise...I think, actually, I would compare launching a company to having a baby. So if having a baby takes a village, so does launching a company.

+ +

VICTORIA: Right. Or no founder is an island. [laughs]

+ +

LAUREN: Yeah, exactly.

+ +

VICTORIA: There's like a community, a whole group around that. I've heard, even in the episodes I've recorded, that it's a common theme among successful founders, which is heartwarming and understandable. So last question about just how it all got started. But if you could travel back in time to when you first decided you wanted to go after this opportunity, what advice would you give yourself now that you have all your present knowledge?

+ +

LAUREN: I say this even to our intended parents who are grappling with this decision of using an egg donor to have a baby: remain steadfast on the vision or the end goal and be flexible on the how. So if you're an intended parent, it's like, remain flexible, like, steadfast on this idea that you want to become a parent, but be flexible on the how.

+ +

With a company, I think stay true to what that ultimate vision is. So, for us, it's like help more people have babies on their own timeline and be flexible on the how, so exactly what our business model was, or exactly what our go-to-market approach would be, or exactly which product we were going to use to get there. I wish I had been a little bit more open to it being a winding road than I realized I needed to be at the beginning. So now I know that, and I'm open to any possibility as long as it gets us to the same place.

+ +

VICTORIA: Right, gotcha. Yeah, well, let me ask you then about your go-to-market strategy since you mentioned it. What was unique in your strategy there, especially to target the specific consumers that you want to with this app?

+ +

LAUREN: So I did follow a bit of an Uber approach, which is this idea of a soft launch. And the reason for that...so basically what we did was for the Freeze by Co side of our business, so for women who are interested in freezing, they have the option to join our split program where they donate half to intended parents and do it for free. Or they can join our Keep Program, where they freeze their eggs but keep 100% of the eggs for themselves. And we help do that along the way.

+ +

However, basically, we couldn't launch Family by Co to help people find donors until we had donors. So it made sense to launch the Freeze by Co side of our business first. And I wanted the ability to market to them when we didn't have the eyes of the whole industry on us, or we didn't have tons and tons of consumers reading our press or things like that just yet.

+ +

And so by soft launching with a quick beta Squarespace page, we were able to test our hypothesis, test our messaging, test our funnel, test our experience before really putting a ton of marketing spend behind it or having a ton of visibility into what we were doing. And I'm so, so grateful we did that.

+ +

It led us, like, we went through probably five different versions of our funnel before we got to our public launch, and our soft launch really afforded us the opportunity to do that. So by the time we turned on the Family by Co side of our business, we already had over 50 donors on day one for them because we had already gotten these women through the funnel.

+ +

VICTORIA: I love that. And that's something we talk a lot about with founders at thoughtbot is that idea of validating your product, and you talked about it with your Instagram poll that you did with influencers. And the way you're talking about your go-to-market strategy is that you wanted to make sure that even though you knew this is what you wanted to do, that you had the right approach and that you could create something that consumers actually wanted to buy and had trust in.

+ +

LAUREN: Mm-hmm, totally.

+ +

VICTORIA: You launched in October 2022. Are there any results post-launch that surprised you?

+ +

LAUREN: I feel so grateful that our launch truly exceeded my expectations. So the interest from women in our programs has been overwhelming, like overwhelming in a good way. And then intended parents are thrilled about it. So we are making matches every day of these intended parents and these donors. And every time we make a match, I'm like, oh my God, it feels like Christmas morning. You're helping people find their path towards growing their family, and there's nothing that feels better than that. I don't think that feeling is ever going to go away, so I'm thrilled about it.

+ +

But it doesn't mean that it's not hard. I think back to that analogy of like having a baby, you know, you launch this company. You hope it's received. You count ten fingers, ten toes, hope that it's received, hope that it's received. It is, but then you have the demand, and you have inbound on partnership opportunities, and you have managing the demand and handling the leads and things like that. And it's like so much more than you expect.

+ +

It's like the same feeling of having a newborn of, like, [gasps] how are we going to do all this? Am I going to stay up all night to manage this? Or how do we handle what we're seeing? And so it's a lot, and figuring out what this new normal is is something that my team and I are working through every day.

+ +

VICTORIA: What's wonderful is that the surprise feels even better than you thought it would. [laughs]

+ +

LAUREN: Yes.

+ +

VICTORIA: Wonderful. For myself, as I'm in my 30s and I'm married and, you know, I'm not thinking it about at some point in the future. But what advice do you think you want women to think about regarding their fertility at any age, like if you could talk to consumers directly like you are now? [laughs]

+ +

LAUREN: Totally. Just that it's never too soon to ask those questions. And the information you need and should want is like inside your body but ready to be shared with you. So by having a consult with a fertility clinic, and that's something my team could help you with, you can learn about your prospects for having a baby and understanding how fertile you are.

+ +

And just because, you know, they say, "Oh, as long as you're under a certain age, you shouldn't have a problem," doesn't mean that that's the case. One of my co-founders was 28 when she started trying to conceive and was completely blindsided that this was going to be a real struggle for her, and that breaks my heart. It doesn't need to be like that. If we're more proactive and we start asking these questions younger, then we can actually do something about it.

+ +

So your fertility is really about your egg quantity and your egg quality, and both of those things are things that can be tested and measured. And I think I'm someone who loves data. And having that data, I think, can help enable you to make decisions about how you can best move forward, and for some, it might mean having a baby soon. For others, it might mean freezing your eggs. For others, it might be a waiting scenario. But that's something that you can make a more informed decision about if you have that data.

+ +

VICTORIA: That makes a lot of sense. And I'll be sharing this episode with all of my friends and everything on Instagram as well.

+ +

LAUREN: [laughs]

+ +

VICTORIA: Great information to put out there. And what's on the horizon for you? What are the big challenges that you see coming up for Cofertility in the next months or year?

+ +

LAUREN: I think really like scale is what we're focused on. So we've started making matches; it feels great. I want us to be prepared to do those at scale. We are seeing no slowdown in terms of people who are interested in this. And so, making sure that our team is ready and able to handle that demand is my absolute top priority. So I think scale is top of mind.

+ +

I think making sure we're optimizing our experience for that is really important. So how do we make sure that everyone is having a magical, smooth experience, both through our digital experience but also if they're on the phone with someone from our team or if they're reading our materials at the fertility clinic? Like, how do we ensure that that's a great experience all around?

+ +

VICTORIA: Right, that makes sense. And right now, is Cofertility specific to a certain location, or is it nationwide?

+ +

LAUREN: Nationwide throughout the U.S.

+ +

VICTORIA: Wonderful. And you yourself are based in California, right?

+ +

LAUREN: Yes, I'm based in Los Angeles. And our team is fully remote, which has been a really exciting thing to do. We're in different time zones and have a lot of opportunity to visit people in different cities, which is nice.

+ +

VICTORIA: Oh, that's great, yeah. How do you help build that culture remotely with a brand-new team?

+ +

LAUREN: So, for us, I think we're very intentional about having team off sites at least twice a year. We also get together for different things like planning meetings or conferences that are really relevant to us. But I think part of it, too, is really around different touchpoints throughout the day. And we have a daily stand-up.

+ +

We also are clear about which hours everyone sort of overlaps based on their time zones and making sure that people are available during those windows and then giving everyone flexibility otherwise in terms of when it makes the most sense to do their work, not being too prescriptive. And really, again, encouraging people to have a life outside work, I think, makes it so that we get the best out of our team.

+ +

VICTORIA: Right, that makes a lot of sense. Yeah, we've got similar...at thoughtbot, we have in-person meetups once or twice a year and then go to different conferences and things together. And I think some people do miss a little bit of the office experience, but for the most part, everyone is happy to put it that way. [laughs]

+ +

LAUREN: Yeah, it's definitely...I think for sure it has its pros and cons. I think what I love about it is that we're not limited with talent. Our team truly, like, [laughs] we have people...we have someone in Oakland, someone in Miami, someone in Charleston, someone in Boston, someone in New York City. Like, the fact that we're not limited because of geography feels great. And I admittedly really love the ability to see my daughter throughout the day and feel like I don't have to stress over how much time I'm spending commuting. So I can't see myself ever going back.

+ +

VICTORIA: That's right, and LA is certainly a place to have a long commute. [laughter] And have you gotten any benefit out of local networking and community around Los Angeles or Southern California?

+ +

LAUREN: Yes, absolutely. Even this Friday night, I'm going to a female founder dinner. I have something coming up in a couple of weeks with this group of women's health founders that I really love. It's so, so valuable to have people in your network that are both local and get the life that you're living while you're doing it. I think having people understand why your life is the way it is while you're building a company is really quite nice. So there are founder communities everywhere but seeking those out early is definitely helpful.

+ +

VICTORIA: And then if you have a remote team, then each team member can have that local community, so you're 10x-ing. [laughs]

+ +

LAUREN: Completely.

+ +

VICTORIA: Yeah, wonderful. Is there anything else, anything that you think I should have asked you that I haven't asked yet?

+ +

LAUREN: No. I think one thing I would encourage is when you're trying to figure out your go-to-market approach, what the strategy is going to be. I'm a big fan of getting everything really in slides. Get it in slides and bring in some people you trust. Talk to your advisors, talk to your investors, talk to your co-founders or your team and say, "Hey, these are the three ways this could go. Here are pros and cons of each one," and making a decision that way.

+ +

I think when we try to do it where it's like all in someone's head, and you're not getting it out on paper with pros and cons, it can feel like a really, really hard decision. But when you see things on paper, and you're able to get the opinion of people you trust, everything is able to come to fruition much more quickly, and you can get to a decision faster.

+ +

VICTORIA: Right. So you're probably really buzzing with ideas early on and finding ways to communicate those and get it so that you can practice talking about it to somebody else. Makes sense.

+ +

LAUREN: Yeah. It's like, how do you socialize it? That's a great way to do it.

+ +

VICTORIA: Yeah, well, wonderful. This has been a really enjoyable conversation. I appreciate you coming on the show so much, and thank you for sharing all about Cofertility with us. Any other final takeaways for our listeners?

+ +

LAUREN: Thanks so much for having me. If you're interested at all in what we're doing or it would be helpful to connect, our website is cofertility.com. You can find me on Instagram at @laurenmakler, L-A-U-R-E-N-M-A-K-L-E-R. Happy to chat really about anything as it relates to building a company, or your fertility, or just questions you have in general. I would love to chat.

+ +

VICTORIA: Thank you so much. And you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening, and see you next time.

+ +

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GzTnPmbu + + ]]> + + Victoria Guido + + + 457: We Take Part with Shaila Sahai + https://podcast.thoughtbot.com/457 + faa43c0a-3052-4543-9781-cbdb51028097 + Thu, 12 Jan 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Shaila Sahai is the Founder of We Take Part, an investment crowdfunding platform that connects eco-conscious investors and green tech entrepreneurs throughout Europe, including European overseas territories. + +Victoria talks to Shaila about focusing on clean tech and climate tech solutions exclusively, goals of contributing to the acceleration of the process of decarbonization, and how the idea of a crowd-investing platform that targets only green tech is welcome from the fintech ecosystem and potential investors. + 28:38 + no + + + Shaila Sahai is the Founder of We Take Part, an investment crowdfunding platform that connects eco-conscious investors and green tech entrepreneurs throughout Europe, including European overseas territories. +Victoria talks to Shaila about focusing on clean tech and climate tech solutions exclusively, goals of contributing to the acceleration of the process of decarbonization, and how the idea of a crowd-investing platform that targets only green tech is welcome from the fintech ecosystem and potential investors. +Follow We Take Part on LinkedIn (https://www.linkedin.com/company/wetakepart/). +Follow Shaila Sahai on LinkedIn (https://www.linkedin.com/in/shailasahai/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Shaila Sahai, Founder of We Take Part, an investment crowdfunding platform that connects eco-conscious investors and green tech entrepreneurs throughout Europe, including European overseas territories. Shaila, thank you for joining me. +SHAILA: Thank you for having me. +VICTORIA: So, can you start off just telling me a little bit more about We Take Part? +SHAILA: We Take part is a crowdinvesting platform based in France. We will be connecting eco-conscious investors, who could be individuals but also institutions, with startups from the green tech ecosystem in France and in Europe. We're going to use projects such as equities. It could be also bonds, green bonds. So basically, it will be investing in a company in exchange of shares in those startups. +VICTORIA: Great. And you have a background in financial services. What led you to get the idea to start this platform? +SHAILA: Yes. So I come from the financial services world professionally, so I worked in equity services. So basically, my job was to make sure that trades were correctly made and settled in the stock exchange markets. Then I also went to work in the financial management corporate side in banking. I had, after some years, a global vision of finance management that led me to after some time, I quit my job and started working for myself as a financial management consultant. So basically, it was financial consulting. +And after some time, I specialized in working with small companies and startups, helping them in financial optimization and also in financial development strategies. And I wanted to do more for those companies after some time, so more than consulting and helping them internally. I wanted to develop tools for them to find more financing solutions than just going to a bank asking for a loan, for example. Most of the time, I could see them feeling blocked when they could not, for example, get a loan from the bank. That led me to develop a crowdfunding solution for them to help them. +Also, the fact that we chose to target only green tech startups comes from a personal conviction of mine that we should really focus on and prioritize climate change solutions right now. And we should, as a society but also in the economy, focus on sustainable solutions to help and contribute actively to the decarbonization of the economy in general. +VICTORIA: That makes a lot of sense. And can you give me an example of a type of green tech that is being crowdfunded, or you want to be crowdfunded on this platform fund? +SHAILA: We want to focus on clean tech and climate tech solutions exclusively. A lot of competitors and investors right now focus on renewable energy, and, of course, this is a very important problem. We want to give access to other startups that develop solutions to clean, for example, the atmosphere or oceans and also the earth for agriculture matters. We want to give them access to investments too. Also, to include people in the investment process because the subjects such as, for example, agriculture, or transportation, construction solutions also are a priority, and they really interest people directly. +Some matters, such as renewable energy some people understand those matters, but most of them don't feel really connected to those problems because they seem like far from their daily preoccupations. So we want to focus on solutions that will directly help people in their...affect and impact people in their daily solutions. +VICTORIA: Right. So not only are you democratizing this investment into green energy and green tech, but you're also expanding the idea of what does that mean? What types of projects are we doing besides just alternative fuels, right? +SHAILA: Exactly. It is true that fossil fuels and all those high carbon emissions energy industries represent three-quarters of the carbon emissions globally. There still is one quarter that we need to transform that needs to be totally, yes, changed. So we need to go further than that, and we need to take part. And that's also the reason for the name of the company. We need to take part in the whole action change plan. +VICTORIA: Right. And I think about that when I've talked to my friends about climate change and how it affects people and the fact that it is already affecting people. And that certain neighborhoods and certain communities are taking a disproportionate share of the impact of climate change. +SHAILA: Absolutely. I personally come from an island. So I'm from the Caribbean, from an island called Guadeloupe. It's a French territory. In the Caribbean, for example, or South America as we know, as we see in the media, the consequences of global warming and fossil industries are extremely visible, and the impacts are huge. The landscape, for example, is changing dramatically. The air pollution is awful. Forests are disappearing. So those are very visible effects. +That's also a reason why it was important for us to include green tech solutions from those places because a lot of innovators are from there because they live with the direct consequences. They innovate in those areas. But those territories, unfortunately, are mostly forgotten, even by big countries, so that's also a reason why someone has to get interested in them. +VICTORIA: Right. I could imagine that it's difficult to find capital if you're from that area and you're solving a problem that's not one of the big ones, [laughs], right? +SHAILA: Exactly. +VICTORIA: Are the projects that you're looking to crowdfund; do they tend to be small? Are they large? Or what's the size of the projects that they're looking for? +SHAILA: So exactly for that reason of accessibility, we decided to first of all, from an investor point of view, we decided to make the investment ticket to set it to €100. But also from a company in funding needs, we decided to also set the minimum funding amount to €50,000. So that means that we really want to support early-stage companies which are not necessarily attractive to big investors or banks, which are not profitable yet but still have good potential of development to support their solution because most of them really deserve to be supported and need to get their product out. +Obviously, the aim of our company, of our solution is to make profit and also to lead investors to make profitable investments. So we will have, of course, financial criterias before selecting startups getting into our funding process. But the main focus will be to give them access to investments that would not be attractive, very attractive to big investors or banks. +VICTORIA: Right. And you just founded this back in April, and you're at pre-seed stage. How are you feeling? [laughs] +SHAILA: Well, I feel overwhelmed [laughs] because there's a lot of, you know, this is a good thing that this area of operations is very regulated. That comes with a lot of paperwork. So I have to go through this right now before really launching publicly the activities. But, in the meantime, I feel very excited because I am personally motivated. +The aim is bigger than making profits. The aim is to contribute to the acceleration of the whole process of decarbonization. It's also to give more sense, more meaning to investment in general but also to give access to new people to investment. And by that, I mean people who are climate-conscious, people who want to make a change, to see direct changes in their environments because I know that the cause is greater than me. I'm very excited as well as exhausted. +VICTORIA: [laughs] That's good. I think you'll need that passion to keep you going. Have you had anyone tell you that you should consider a nonprofit, and why have you decided to make it for-profit? +SHAILA: No, so no one has told me this [laughter] yet. I guess that's because of my background. I come from finance. My partners or people that I meet because of this project know that I eventually know what I'm doing. They are not suggesting nonprofit. Also, I truly believe in making good business. I think that this is possible, and I want to be part of those people who make it possible. +For a long time, prosperity, economic prosperity was a synonym for just aggressive business and huge industries, globalization, et cetera. And now, because of the climate emergency, we understand that something needs to be done. But I think that globally, the system is still scared of making a radical change because of profits reasons. Profit can be made while making a sustainable business. So I wouldn't even consider a nonprofit because we need to change the narrative. I think doing good is not going to mean doing things like being idealistic or following just a dream. We need to make it a reality. +VICTORIA: Right. And when you're in a for-profit business with a meaningful impact, you can focus on making the business work versus trying to find donors or trying to always prove how much you're giving back to the community. It'll make good business sense, and I really like that's the path that you're taking. +SHAILA: Exactly. +VICTORIA: Wonderful. What has your process been for validating this idea? Do you interview lots of different people? How do you know that it's the right market fit? +SHAILA: In the last years, I have seen the whole narrative change. That is what I was talking about in the way business needs to be made. When I was working in banking, I have seen those new standards, ESG standards coming, appearing. I also know that this is going to be a norm very soon. That means that the way we do business is really going to change like in reality in corporate practices. +So, first of all, this is the right path because literally corporate practices are going to change and are going to align more and more with ESG criterias. Very soon, it will not be possible at all to continue to operate business without sustainable practices, obviously the way the large groups are going to change and are changing already. And small businesses are going to be built with ESG standards in mind too. +Another part of the change is coming from the solutions. Are they sustainable? Are they energy efficient? Are they contributing to decarbonization, or are they polluting more? Is it possible to fund them because of that? So I think there is a whole transformation of the economy, and we need to be ready to follow up with the change. And we all need to be ready to fund this economy, not only governments but also private and small private institutions, individuals. +Also, the green tech ecosystem, in general, is just exploding. This is a fact. For example, in France in 2020, we had a number of 800 green tech startups in France. In 2021, those startups increased, and the number of startups increased. And we could count 1,800 startups just one year after. This ecosystem also is growing massively, and the market is there. +VICTORIA: That's really exciting. And what is the startup community in Paris like? +SHAILA: Well, the startup community is very active in Paris. France is a huge generator of startups. As you may know, Station F is the biggest incubator in the world. It is a very dynamic ecosystem. Innovations are appearing every day. And France supports the startups a lot. Yes, it's very dynamic. +A lot of things are being made, and it's an ecosystem where we know each other. We meet each other, and we know what needs to be done. We talk with each other, especially at Station F, where I am not located, but still, a lot of meetups are there, a lot of events are going on there. So this is a place for startup founders to meet and talk. So we know that a lot of things are going to happen. +VICTORIA: That's very exciting. +SHAILA: Yes, it is really, very encouraging. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint +VICTORIA: Have you found a lot of people get your idea right away? Do you feel people are excited about your product when you talk to them about it? +SHAILA: Yes, that was very, very surprising to me. Everybody I talked to was getting the idea very quickly. I haven't met any reservation from people around me or from partners, from people I was approaching business-wise. Well, I think the climate emergency is such that people get the idea immediately. Also, fundings, for now, are not enough for the green tech ecosystem. So the idea of a crowdinvesting platform that targets only green tech is really welcome from the ecosystem, the fintech ecosystem, but also from potential investors too. +VICTORIA: That's great. It must make you feel validated that you know you're on the right path. [laughs] +SHAILA: Yes, this is very helpful to me, yes. +VICTORIA: Wonderful. And what's next on your roadmap? What's the biggest challenge you see ahead of you? +SHAILA: So, yes, the next step for us, once we receive all the green lights to operate on the French and European market, will be to build our investors community. For now, we are waiting for this green light from the financial authorities to start publishing and communicating at a large scale to the public about what we are going to do. So our next challenge is really to reach out to people to convince them to join us and also to make sustainable investment understandable and accessible to first-time investors. +VICTORIA: Do you feel like you have the tools to do that? What do you think is going to be difficult about that process? +SHAILA: On that part, I think the most difficult part will be a traditional aspect of the business, which is competition. The thing is we need, in this particular area, we need currently to face two problems. The first one is the greenwashing problem that a lot of companies use, and we are not aligned with those greenwashing practices, and this could be confusing for people. Because the truth is as much as the climate change emergency is real, there is also a trend of offering all types of green services and products, so this could be confusing for consumers, for people. +The first challenge will be to differentiate and really to make people understand that sustainability is in our core values, but it's also our why that this is the reason why we're doing this. This is not a greenwashing opportunity for us. Also, yes, in this competition matter, the other thing is that we are not going to focus only on renewable energy. So there is some type of education we need to provide about our products, about the meaning of the solutions, and the impacts of the solutions we're going to finance, even when they are not renewable energy related. +VICTORIA: Those sound like exciting challenges to work on. [laughs] +SHAILA: Yes, really. +VICTORIA: Once all the paperwork is finished. +SHAILA: Exactly. So this will be basically marketing, marketing, and communication issues. +VICTORIA: Wonderful. Why crowdfunding versus regular government funding for these types of projects? +SHAILA: It is important to enhance alternative financing solutions because the reality is that most businesses in their early stage will not be financially strong enough to ask for financing solutions such as bank loans, for example. That means that they don't have enough capital at first to engage in more debts. What they need is to reinforce their capital in an early stage. +When the founders, for example, do not have basically the money themselves to fund their own company, calling the crowd to help is a very good solution to reinforce their capital. So they have more power after that to go for other types of financing solutions such as fundraising huge amounts from investors, from institutions, or to ask for, for example, bank loans. They are strong enough then to go for more and to develop their solutions and scale up. +VICTORIA: That makes a lot of sense. And I'm wondering if, in your process, since April, have there been any pivots you had to make where you were going in one direction, and then you learned something and decided you needed to go a completely different direction? +SHAILA: Yes, to be honest, my first idea was to target startups from the European overseas territories only. So that was my first idea. When I did my market study, I discovered that the market was too small. It was a very interesting market because those startups are far from the countries they are related to. French Caribbean islands are geographically far from the French territory, French country in Europe. They have some localization barrier, for example, to reach the national market. And that is the case for any other overseas European territory. +So my first idea was to give them access and give them visibility in the national territory because crowdfunding is an online solution, but, well, the market was too small, for example. So this was not a good path to go. And I had to reevaluate and do another market study because also my main goal was to answer an environmental need. +VICTORIA: That makes a lot of sense. And it is interesting how your idea of the market evolves once you really start building something and start getting information about it. +SHAILA: I can give you another example of a switch of the idea, of the initial idea I had. We wanted to start operating immediately in all Europe. We learned that because of the European regulations of the markets, we need to go step by step and country by country. This made us focus first on the French market. And we know now that we will be able to reach the other European ecosystems one by one. That helped us refine our marketing strategy. +VICTORIA: Interesting. So when you started building your product or building the idea, and you went country by country, was there a concern about getting too specific to that country? Or was it easy to build out to a new country once you were ready to move on? +SHAILA: It's quite easy in the conceptual stage because the European Union has really standardized a lot of economic or financial regulations. So we have a system of like an economic or business passport which makes it quite easy. But the main problem is really being able to adapt to different languages, Spanish, or German, or English, or Italian, to adapt to those markets with their specificities, which are linked not only to their language but those still are marketing aspects. But other than that, thanks to the European Union system, it is quite easy to really build a whole European strategy. +VICTORIA: Right. I feel like that should be a part of an ad or marketing [laughter] just for the European Union. +SHAILA: It could be. It could be, right. +VICTORIA: Well, that makes a lot of sense. And we understand as well, being an international company, that being able to adapt to different languages does present its own challenges. +SHAILA: Exactly. +VICTORIA: Well, wonderful. What advice would you give to yourself at the beginning of this project if you could go back in time? +SHAILA: You know, it's funny because I have been familiar to business for a long time. I come from a businessmen family. And also, I've been working as a financial management consultant for small companies and startups for some years before. But still, I didn't maybe gather enough money at first to start this very capital-consuming business. So I would advise myself to gather twice the money I had before. [chuckles] Even if we found solutions and we are totally equipped, but well, I was maybe...I didn't prepare enough capital at first. +And also another advice would have been from the start to not forget to sleep [laughs] because this is really crucial to maintain good health when you start a new project, and especially a very energy-consuming one. The health of your project and of your company also depends on your own health. +VICTORIA: Wonderful advice. [laughs] Everyone who's working on something they're passionate about should remember that. You're 100% right. It's dependent on your own health first, right? +SHAILA: Exactly. It could be the passion drives you so much that...and you know the amount of work you effectively have to do, so you can really get caught in the amount of work. But sleep is a very good strategy to keep going. +VICTORIA: I love sleep. I'm a big fan. My sleep schedule is a little messed up because I was in the Azores last week. +SHAILA: So the jetlag was big. +VICTORIA: Yeah, but it helps me because we're kind of an early riser family anyways. Yeah, I can have time to have my coffee before I start work. [laughs] +SHAILA: Right. I see, yeah. +VICTORIA: Is there any other final takeaways you want to give to our audience? +SHAILA: I would ask the people who listen to really join us as soon as we are ready to launch and to talk about We Take Part to their friends and family. Also, to reach out because we could help understand more what we can do, how we can help, and how investing and supporting sustainable business how important it is. And when it's correctly made, and it is profitable, it is profitable for everyone, for the whole society, not only for an economic system. +VICTORIA: Wonderful. And we'll have the opportunity to include any links or marketing in our show notes. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thought. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Shaila Sahai is the Founder of We Take Part, an investment crowdfunding platform that connects eco-conscious investors and green tech entrepreneurs throughout Europe, including European overseas territories.

+ +

Victoria talks to Shaila about focusing on clean tech and climate tech solutions exclusively, goals of contributing to the acceleration of the process of decarbonization, and how the idea of a crowd-investing platform that targets only green tech is welcome from the fintech ecosystem and potential investors.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Shaila Sahai, Founder of We Take Part, an investment crowdfunding platform that connects eco-conscious investors and green tech entrepreneurs throughout Europe, including European overseas territories. Shaila, thank you for joining me.

+ +

SHAILA: Thank you for having me.

+ +

VICTORIA: So, can you start off just telling me a little bit more about We Take Part?

+ +

SHAILA: We Take part is a crowdinvesting platform based in France. We will be connecting eco-conscious investors, who could be individuals but also institutions, with startups from the green tech ecosystem in France and in Europe. We're going to use projects such as equities. It could be also bonds, green bonds. So basically, it will be investing in a company in exchange of shares in those startups.

+ +

VICTORIA: Great. And you have a background in financial services. What led you to get the idea to start this platform?

+ +

SHAILA: Yes. So I come from the financial services world professionally, so I worked in equity services. So basically, my job was to make sure that trades were correctly made and settled in the stock exchange markets. Then I also went to work in the financial management corporate side in banking. I had, after some years, a global vision of finance management that led me to after some time, I quit my job and started working for myself as a financial management consultant. So basically, it was financial consulting.

+ +

And after some time, I specialized in working with small companies and startups, helping them in financial optimization and also in financial development strategies. And I wanted to do more for those companies after some time, so more than consulting and helping them internally. I wanted to develop tools for them to find more financing solutions than just going to a bank asking for a loan, for example. Most of the time, I could see them feeling blocked when they could not, for example, get a loan from the bank. That led me to develop a crowdfunding solution for them to help them.

+ +

Also, the fact that we chose to target only green tech startups comes from a personal conviction of mine that we should really focus on and prioritize climate change solutions right now. And we should, as a society but also in the economy, focus on sustainable solutions to help and contribute actively to the decarbonization of the economy in general.

+ +

VICTORIA: That makes a lot of sense. And can you give me an example of a type of green tech that is being crowdfunded, or you want to be crowdfunded on this platform fund?

+ +

SHAILA: We want to focus on clean tech and climate tech solutions exclusively. A lot of competitors and investors right now focus on renewable energy, and, of course, this is a very important problem. We want to give access to other startups that develop solutions to clean, for example, the atmosphere or oceans and also the earth for agriculture matters. We want to give them access to investments too. Also, to include people in the investment process because the subjects such as, for example, agriculture, or transportation, construction solutions also are a priority, and they really interest people directly.

+ +

Some matters, such as renewable energy some people understand those matters, but most of them don't feel really connected to those problems because they seem like far from their daily preoccupations. So we want to focus on solutions that will directly help people in their...affect and impact people in their daily solutions.

+ +

VICTORIA: Right. So not only are you democratizing this investment into green energy and green tech, but you're also expanding the idea of what does that mean? What types of projects are we doing besides just alternative fuels, right?

+ +

SHAILA: Exactly. It is true that fossil fuels and all those high carbon emissions energy industries represent three-quarters of the carbon emissions globally. There still is one quarter that we need to transform that needs to be totally, yes, changed. So we need to go further than that, and we need to take part. And that's also the reason for the name of the company. We need to take part in the whole action change plan.

+ +

VICTORIA: Right. And I think about that when I've talked to my friends about climate change and how it affects people and the fact that it is already affecting people. And that certain neighborhoods and certain communities are taking a disproportionate share of the impact of climate change.

+ +

SHAILA: Absolutely. I personally come from an island. So I'm from the Caribbean, from an island called Guadeloupe. It's a French territory. In the Caribbean, for example, or South America as we know, as we see in the media, the consequences of global warming and fossil industries are extremely visible, and the impacts are huge. The landscape, for example, is changing dramatically. The air pollution is awful. Forests are disappearing. So those are very visible effects.

+ +

That's also a reason why it was important for us to include green tech solutions from those places because a lot of innovators are from there because they live with the direct consequences. They innovate in those areas. But those territories, unfortunately, are mostly forgotten, even by big countries, so that's also a reason why someone has to get interested in them.

+ +

VICTORIA: Right. I could imagine that it's difficult to find capital if you're from that area and you're solving a problem that's not one of the big ones, [laughs], right?

+ +

SHAILA: Exactly.

+ +

VICTORIA: Are the projects that you're looking to crowdfund; do they tend to be small? Are they large? Or what's the size of the projects that they're looking for?

+ +

SHAILA: So exactly for that reason of accessibility, we decided to first of all, from an investor point of view, we decided to make the investment ticket to set it to €100. But also from a company in funding needs, we decided to also set the minimum funding amount to €50,000. So that means that we really want to support early-stage companies which are not necessarily attractive to big investors or banks, which are not profitable yet but still have good potential of development to support their solution because most of them really deserve to be supported and need to get their product out.

+ +

Obviously, the aim of our company, of our solution is to make profit and also to lead investors to make profitable investments. So we will have, of course, financial criterias before selecting startups getting into our funding process. But the main focus will be to give them access to investments that would not be attractive, very attractive to big investors or banks.

+ +

VICTORIA: Right. And you just founded this back in April, and you're at pre-seed stage. How are you feeling? [laughs]

+ +

SHAILA: Well, I feel overwhelmed [laughs] because there's a lot of, you know, this is a good thing that this area of operations is very regulated. That comes with a lot of paperwork. So I have to go through this right now before really launching publicly the activities. But, in the meantime, I feel very excited because I am personally motivated.

+ +

The aim is bigger than making profits. The aim is to contribute to the acceleration of the whole process of decarbonization. It's also to give more sense, more meaning to investment in general but also to give access to new people to investment. And by that, I mean people who are climate-conscious, people who want to make a change, to see direct changes in their environments because I know that the cause is greater than me. I'm very excited as well as exhausted.

+ +

VICTORIA: [laughs] That's good. I think you'll need that passion to keep you going. Have you had anyone tell you that you should consider a nonprofit, and why have you decided to make it for-profit?

+ +

SHAILA: No, so no one has told me this [laughter] yet. I guess that's because of my background. I come from finance. My partners or people that I meet because of this project know that I eventually know what I'm doing. They are not suggesting nonprofit. Also, I truly believe in making good business. I think that this is possible, and I want to be part of those people who make it possible.

+ +

For a long time, prosperity, economic prosperity was a synonym for just aggressive business and huge industries, globalization, et cetera. And now, because of the climate emergency, we understand that something needs to be done. But I think that globally, the system is still scared of making a radical change because of profits reasons. Profit can be made while making a sustainable business. So I wouldn't even consider a nonprofit because we need to change the narrative. I think doing good is not going to mean doing things like being idealistic or following just a dream. We need to make it a reality.

+ +

VICTORIA: Right. And when you're in a for-profit business with a meaningful impact, you can focus on making the business work versus trying to find donors or trying to always prove how much you're giving back to the community. It'll make good business sense, and I really like that's the path that you're taking.

+ +

SHAILA: Exactly.

+ +

VICTORIA: Wonderful. What has your process been for validating this idea? Do you interview lots of different people? How do you know that it's the right market fit?

+ +

SHAILA: In the last years, I have seen the whole narrative change. That is what I was talking about in the way business needs to be made. When I was working in banking, I have seen those new standards, ESG standards coming, appearing. I also know that this is going to be a norm very soon. That means that the way we do business is really going to change like in reality in corporate practices.

+ +

So, first of all, this is the right path because literally corporate practices are going to change and are going to align more and more with ESG criterias. Very soon, it will not be possible at all to continue to operate business without sustainable practices, obviously the way the large groups are going to change and are changing already. And small businesses are going to be built with ESG standards in mind too.

+ +

Another part of the change is coming from the solutions. Are they sustainable? Are they energy efficient? Are they contributing to decarbonization, or are they polluting more? Is it possible to fund them because of that? So I think there is a whole transformation of the economy, and we need to be ready to follow up with the change. And we all need to be ready to fund this economy, not only governments but also private and small private institutions, individuals.

+ +

Also, the green tech ecosystem, in general, is just exploding. This is a fact. For example, in France in 2020, we had a number of 800 green tech startups in France. In 2021, those startups increased, and the number of startups increased. And we could count 1,800 startups just one year after. This ecosystem also is growing massively, and the market is there.

+ +

VICTORIA: That's really exciting. And what is the startup community in Paris like?

+ +

SHAILA: Well, the startup community is very active in Paris. France is a huge generator of startups. As you may know, Station F is the biggest incubator in the world. It is a very dynamic ecosystem. Innovations are appearing every day. And France supports the startups a lot. Yes, it's very dynamic.

+ +

A lot of things are being made, and it's an ecosystem where we know each other. We meet each other, and we know what needs to be done. We talk with each other, especially at Station F, where I am not located, but still, a lot of meetups are there, a lot of events are going on there. So this is a place for startup founders to meet and talk. So we know that a lot of things are going to happen.

+ +

VICTORIA: That's very exciting.

+ +

SHAILA: Yes, it is really, very encouraging.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: Have you found a lot of people get your idea right away? Do you feel people are excited about your product when you talk to them about it?

+ +

SHAILA: Yes, that was very, very surprising to me. Everybody I talked to was getting the idea very quickly. I haven't met any reservation from people around me or from partners, from people I was approaching business-wise. Well, I think the climate emergency is such that people get the idea immediately. Also, fundings, for now, are not enough for the green tech ecosystem. So the idea of a crowdinvesting platform that targets only green tech is really welcome from the ecosystem, the fintech ecosystem, but also from potential investors too.

+ +

VICTORIA: That's great. It must make you feel validated that you know you're on the right path. [laughs]

+ +

SHAILA: Yes, this is very helpful to me, yes.

+ +

VICTORIA: Wonderful. And what's next on your roadmap? What's the biggest challenge you see ahead of you?

+ +

SHAILA: So, yes, the next step for us, once we receive all the green lights to operate on the French and European market, will be to build our investors community. For now, we are waiting for this green light from the financial authorities to start publishing and communicating at a large scale to the public about what we are going to do. So our next challenge is really to reach out to people to convince them to join us and also to make sustainable investment understandable and accessible to first-time investors.

+ +

VICTORIA: Do you feel like you have the tools to do that? What do you think is going to be difficult about that process?

+ +

SHAILA: On that part, I think the most difficult part will be a traditional aspect of the business, which is competition. The thing is we need, in this particular area, we need currently to face two problems. The first one is the greenwashing problem that a lot of companies use, and we are not aligned with those greenwashing practices, and this could be confusing for people. Because the truth is as much as the climate change emergency is real, there is also a trend of offering all types of green services and products, so this could be confusing for consumers, for people.

+ +

The first challenge will be to differentiate and really to make people understand that sustainability is in our core values, but it's also our why that this is the reason why we're doing this. This is not a greenwashing opportunity for us. Also, yes, in this competition matter, the other thing is that we are not going to focus only on renewable energy. So there is some type of education we need to provide about our products, about the meaning of the solutions, and the impacts of the solutions we're going to finance, even when they are not renewable energy related.

+ +

VICTORIA: Those sound like exciting challenges to work on. [laughs]

+ +

SHAILA: Yes, really.

+ +

VICTORIA: Once all the paperwork is finished.

+ +

SHAILA: Exactly. So this will be basically marketing, marketing, and communication issues.

+ +

VICTORIA: Wonderful. Why crowdfunding versus regular government funding for these types of projects?

+ +

SHAILA: It is important to enhance alternative financing solutions because the reality is that most businesses in their early stage will not be financially strong enough to ask for financing solutions such as bank loans, for example. That means that they don't have enough capital at first to engage in more debts. What they need is to reinforce their capital in an early stage.

+ +

When the founders, for example, do not have basically the money themselves to fund their own company, calling the crowd to help is a very good solution to reinforce their capital. So they have more power after that to go for other types of financing solutions such as fundraising huge amounts from investors, from institutions, or to ask for, for example, bank loans. They are strong enough then to go for more and to develop their solutions and scale up.

+ +

VICTORIA: That makes a lot of sense. And I'm wondering if, in your process, since April, have there been any pivots you had to make where you were going in one direction, and then you learned something and decided you needed to go a completely different direction?

+ +

SHAILA: Yes, to be honest, my first idea was to target startups from the European overseas territories only. So that was my first idea. When I did my market study, I discovered that the market was too small. It was a very interesting market because those startups are far from the countries they are related to. French Caribbean islands are geographically far from the French territory, French country in Europe. They have some localization barrier, for example, to reach the national market. And that is the case for any other overseas European territory.

+ +

So my first idea was to give them access and give them visibility in the national territory because crowdfunding is an online solution, but, well, the market was too small, for example. So this was not a good path to go. And I had to reevaluate and do another market study because also my main goal was to answer an environmental need.

+ +

VICTORIA: That makes a lot of sense. And it is interesting how your idea of the market evolves once you really start building something and start getting information about it.

+ +

SHAILA: I can give you another example of a switch of the idea, of the initial idea I had. We wanted to start operating immediately in all Europe. We learned that because of the European regulations of the markets, we need to go step by step and country by country. This made us focus first on the French market. And we know now that we will be able to reach the other European ecosystems one by one. That helped us refine our marketing strategy.

+ +

VICTORIA: Interesting. So when you started building your product or building the idea, and you went country by country, was there a concern about getting too specific to that country? Or was it easy to build out to a new country once you were ready to move on?

+ +

SHAILA: It's quite easy in the conceptual stage because the European Union has really standardized a lot of economic or financial regulations. So we have a system of like an economic or business passport which makes it quite easy. But the main problem is really being able to adapt to different languages, Spanish, or German, or English, or Italian, to adapt to those markets with their specificities, which are linked not only to their language but those still are marketing aspects. But other than that, thanks to the European Union system, it is quite easy to really build a whole European strategy.

+ +

VICTORIA: Right. I feel like that should be a part of an ad or marketing [laughter] just for the European Union.

+ +

SHAILA: It could be. It could be, right.

+ +

VICTORIA: Well, that makes a lot of sense. And we understand as well, being an international company, that being able to adapt to different languages does present its own challenges.

+ +

SHAILA: Exactly.

+ +

VICTORIA: Well, wonderful. What advice would you give to yourself at the beginning of this project if you could go back in time?

+ +

SHAILA: You know, it's funny because I have been familiar to business for a long time. I come from a businessmen family. And also, I've been working as a financial management consultant for small companies and startups for some years before. But still, I didn't maybe gather enough money at first to start this very capital-consuming business. So I would advise myself to gather twice the money I had before. [chuckles] Even if we found solutions and we are totally equipped, but well, I was maybe...I didn't prepare enough capital at first.

+ +

And also another advice would have been from the start to not forget to sleep [laughs] because this is really crucial to maintain good health when you start a new project, and especially a very energy-consuming one. The health of your project and of your company also depends on your own health.

+ +

VICTORIA: Wonderful advice. [laughs] Everyone who's working on something they're passionate about should remember that. You're 100% right. It's dependent on your own health first, right?

+ +

SHAILA: Exactly. It could be the passion drives you so much that...and you know the amount of work you effectively have to do, so you can really get caught in the amount of work. But sleep is a very good strategy to keep going.

+ +

VICTORIA: I love sleep. I'm a big fan. My sleep schedule is a little messed up because I was in the Azores last week.

+ +

SHAILA: So the jetlag was big.

+ +

VICTORIA: Yeah, but it helps me because we're kind of an early riser family anyways. Yeah, I can have time to have my coffee before I start work. [laughs]

+ +

SHAILA: Right. I see, yeah.

+ +

VICTORIA: Is there any other final takeaways you want to give to our audience?

+ +

SHAILA: I would ask the people who listen to really join us as soon as we are ready to launch and to talk about We Take Part to their friends and family. Also, to reach out because we could help understand more what we can do, how we can help, and how investing and supporting sustainable business how important it is. And when it's correctly made, and it is profitable, it is profitable for everyone, for the whole society, not only for an economic system.

+ +

VICTORIA: Wonderful. And we'll have the opportunity to include any links or marketing in our show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thought. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Shaila Sahai is the Founder of We Take Part, an investment crowdfunding platform that connects eco-conscious investors and green tech entrepreneurs throughout Europe, including European overseas territories.

+ +

Victoria talks to Shaila about focusing on clean tech and climate tech solutions exclusively, goals of contributing to the acceleration of the process of decarbonization, and how the idea of a crowd-investing platform that targets only green tech is welcome from the fintech ecosystem and potential investors.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Shaila Sahai, Founder of We Take Part, an investment crowdfunding platform that connects eco-conscious investors and green tech entrepreneurs throughout Europe, including European overseas territories. Shaila, thank you for joining me.

+ +

SHAILA: Thank you for having me.

+ +

VICTORIA: So, can you start off just telling me a little bit more about We Take Part?

+ +

SHAILA: We Take part is a crowdinvesting platform based in France. We will be connecting eco-conscious investors, who could be individuals but also institutions, with startups from the green tech ecosystem in France and in Europe. We're going to use projects such as equities. It could be also bonds, green bonds. So basically, it will be investing in a company in exchange of shares in those startups.

+ +

VICTORIA: Great. And you have a background in financial services. What led you to get the idea to start this platform?

+ +

SHAILA: Yes. So I come from the financial services world professionally, so I worked in equity services. So basically, my job was to make sure that trades were correctly made and settled in the stock exchange markets. Then I also went to work in the financial management corporate side in banking. I had, after some years, a global vision of finance management that led me to after some time, I quit my job and started working for myself as a financial management consultant. So basically, it was financial consulting.

+ +

And after some time, I specialized in working with small companies and startups, helping them in financial optimization and also in financial development strategies. And I wanted to do more for those companies after some time, so more than consulting and helping them internally. I wanted to develop tools for them to find more financing solutions than just going to a bank asking for a loan, for example. Most of the time, I could see them feeling blocked when they could not, for example, get a loan from the bank. That led me to develop a crowdfunding solution for them to help them.

+ +

Also, the fact that we chose to target only green tech startups comes from a personal conviction of mine that we should really focus on and prioritize climate change solutions right now. And we should, as a society but also in the economy, focus on sustainable solutions to help and contribute actively to the decarbonization of the economy in general.

+ +

VICTORIA: That makes a lot of sense. And can you give me an example of a type of green tech that is being crowdfunded, or you want to be crowdfunded on this platform fund?

+ +

SHAILA: We want to focus on clean tech and climate tech solutions exclusively. A lot of competitors and investors right now focus on renewable energy, and, of course, this is a very important problem. We want to give access to other startups that develop solutions to clean, for example, the atmosphere or oceans and also the earth for agriculture matters. We want to give them access to investments too. Also, to include people in the investment process because the subjects such as, for example, agriculture, or transportation, construction solutions also are a priority, and they really interest people directly.

+ +

Some matters, such as renewable energy some people understand those matters, but most of them don't feel really connected to those problems because they seem like far from their daily preoccupations. So we want to focus on solutions that will directly help people in their...affect and impact people in their daily solutions.

+ +

VICTORIA: Right. So not only are you democratizing this investment into green energy and green tech, but you're also expanding the idea of what does that mean? What types of projects are we doing besides just alternative fuels, right?

+ +

SHAILA: Exactly. It is true that fossil fuels and all those high carbon emissions energy industries represent three-quarters of the carbon emissions globally. There still is one quarter that we need to transform that needs to be totally, yes, changed. So we need to go further than that, and we need to take part. And that's also the reason for the name of the company. We need to take part in the whole action change plan.

+ +

VICTORIA: Right. And I think about that when I've talked to my friends about climate change and how it affects people and the fact that it is already affecting people. And that certain neighborhoods and certain communities are taking a disproportionate share of the impact of climate change.

+ +

SHAILA: Absolutely. I personally come from an island. So I'm from the Caribbean, from an island called Guadeloupe. It's a French territory. In the Caribbean, for example, or South America as we know, as we see in the media, the consequences of global warming and fossil industries are extremely visible, and the impacts are huge. The landscape, for example, is changing dramatically. The air pollution is awful. Forests are disappearing. So those are very visible effects.

+ +

That's also a reason why it was important for us to include green tech solutions from those places because a lot of innovators are from there because they live with the direct consequences. They innovate in those areas. But those territories, unfortunately, are mostly forgotten, even by big countries, so that's also a reason why someone has to get interested in them.

+ +

VICTORIA: Right. I could imagine that it's difficult to find capital if you're from that area and you're solving a problem that's not one of the big ones, [laughs], right?

+ +

SHAILA: Exactly.

+ +

VICTORIA: Are the projects that you're looking to crowdfund; do they tend to be small? Are they large? Or what's the size of the projects that they're looking for?

+ +

SHAILA: So exactly for that reason of accessibility, we decided to first of all, from an investor point of view, we decided to make the investment ticket to set it to €100. But also from a company in funding needs, we decided to also set the minimum funding amount to €50,000. So that means that we really want to support early-stage companies which are not necessarily attractive to big investors or banks, which are not profitable yet but still have good potential of development to support their solution because most of them really deserve to be supported and need to get their product out.

+ +

Obviously, the aim of our company, of our solution is to make profit and also to lead investors to make profitable investments. So we will have, of course, financial criterias before selecting startups getting into our funding process. But the main focus will be to give them access to investments that would not be attractive, very attractive to big investors or banks.

+ +

VICTORIA: Right. And you just founded this back in April, and you're at pre-seed stage. How are you feeling? [laughs]

+ +

SHAILA: Well, I feel overwhelmed [laughs] because there's a lot of, you know, this is a good thing that this area of operations is very regulated. That comes with a lot of paperwork. So I have to go through this right now before really launching publicly the activities. But, in the meantime, I feel very excited because I am personally motivated.

+ +

The aim is bigger than making profits. The aim is to contribute to the acceleration of the whole process of decarbonization. It's also to give more sense, more meaning to investment in general but also to give access to new people to investment. And by that, I mean people who are climate-conscious, people who want to make a change, to see direct changes in their environments because I know that the cause is greater than me. I'm very excited as well as exhausted.

+ +

VICTORIA: [laughs] That's good. I think you'll need that passion to keep you going. Have you had anyone tell you that you should consider a nonprofit, and why have you decided to make it for-profit?

+ +

SHAILA: No, so no one has told me this [laughter] yet. I guess that's because of my background. I come from finance. My partners or people that I meet because of this project know that I eventually know what I'm doing. They are not suggesting nonprofit. Also, I truly believe in making good business. I think that this is possible, and I want to be part of those people who make it possible.

+ +

For a long time, prosperity, economic prosperity was a synonym for just aggressive business and huge industries, globalization, et cetera. And now, because of the climate emergency, we understand that something needs to be done. But I think that globally, the system is still scared of making a radical change because of profits reasons. Profit can be made while making a sustainable business. So I wouldn't even consider a nonprofit because we need to change the narrative. I think doing good is not going to mean doing things like being idealistic or following just a dream. We need to make it a reality.

+ +

VICTORIA: Right. And when you're in a for-profit business with a meaningful impact, you can focus on making the business work versus trying to find donors or trying to always prove how much you're giving back to the community. It'll make good business sense, and I really like that's the path that you're taking.

+ +

SHAILA: Exactly.

+ +

VICTORIA: Wonderful. What has your process been for validating this idea? Do you interview lots of different people? How do you know that it's the right market fit?

+ +

SHAILA: In the last years, I have seen the whole narrative change. That is what I was talking about in the way business needs to be made. When I was working in banking, I have seen those new standards, ESG standards coming, appearing. I also know that this is going to be a norm very soon. That means that the way we do business is really going to change like in reality in corporate practices.

+ +

So, first of all, this is the right path because literally corporate practices are going to change and are going to align more and more with ESG criterias. Very soon, it will not be possible at all to continue to operate business without sustainable practices, obviously the way the large groups are going to change and are changing already. And small businesses are going to be built with ESG standards in mind too.

+ +

Another part of the change is coming from the solutions. Are they sustainable? Are they energy efficient? Are they contributing to decarbonization, or are they polluting more? Is it possible to fund them because of that? So I think there is a whole transformation of the economy, and we need to be ready to follow up with the change. And we all need to be ready to fund this economy, not only governments but also private and small private institutions, individuals.

+ +

Also, the green tech ecosystem, in general, is just exploding. This is a fact. For example, in France in 2020, we had a number of 800 green tech startups in France. In 2021, those startups increased, and the number of startups increased. And we could count 1,800 startups just one year after. This ecosystem also is growing massively, and the market is there.

+ +

VICTORIA: That's really exciting. And what is the startup community in Paris like?

+ +

SHAILA: Well, the startup community is very active in Paris. France is a huge generator of startups. As you may know, Station F is the biggest incubator in the world. It is a very dynamic ecosystem. Innovations are appearing every day. And France supports the startups a lot. Yes, it's very dynamic.

+ +

A lot of things are being made, and it's an ecosystem where we know each other. We meet each other, and we know what needs to be done. We talk with each other, especially at Station F, where I am not located, but still, a lot of meetups are there, a lot of events are going on there. So this is a place for startup founders to meet and talk. So we know that a lot of things are going to happen.

+ +

VICTORIA: That's very exciting.

+ +

SHAILA: Yes, it is really, very encouraging.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

VICTORIA: Have you found a lot of people get your idea right away? Do you feel people are excited about your product when you talk to them about it?

+ +

SHAILA: Yes, that was very, very surprising to me. Everybody I talked to was getting the idea very quickly. I haven't met any reservation from people around me or from partners, from people I was approaching business-wise. Well, I think the climate emergency is such that people get the idea immediately. Also, fundings, for now, are not enough for the green tech ecosystem. So the idea of a crowdinvesting platform that targets only green tech is really welcome from the ecosystem, the fintech ecosystem, but also from potential investors too.

+ +

VICTORIA: That's great. It must make you feel validated that you know you're on the right path. [laughs]

+ +

SHAILA: Yes, this is very helpful to me, yes.

+ +

VICTORIA: Wonderful. And what's next on your roadmap? What's the biggest challenge you see ahead of you?

+ +

SHAILA: So, yes, the next step for us, once we receive all the green lights to operate on the French and European market, will be to build our investors community. For now, we are waiting for this green light from the financial authorities to start publishing and communicating at a large scale to the public about what we are going to do. So our next challenge is really to reach out to people to convince them to join us and also to make sustainable investment understandable and accessible to first-time investors.

+ +

VICTORIA: Do you feel like you have the tools to do that? What do you think is going to be difficult about that process?

+ +

SHAILA: On that part, I think the most difficult part will be a traditional aspect of the business, which is competition. The thing is we need, in this particular area, we need currently to face two problems. The first one is the greenwashing problem that a lot of companies use, and we are not aligned with those greenwashing practices, and this could be confusing for people. Because the truth is as much as the climate change emergency is real, there is also a trend of offering all types of green services and products, so this could be confusing for consumers, for people.

+ +

The first challenge will be to differentiate and really to make people understand that sustainability is in our core values, but it's also our why that this is the reason why we're doing this. This is not a greenwashing opportunity for us. Also, yes, in this competition matter, the other thing is that we are not going to focus only on renewable energy. So there is some type of education we need to provide about our products, about the meaning of the solutions, and the impacts of the solutions we're going to finance, even when they are not renewable energy related.

+ +

VICTORIA: Those sound like exciting challenges to work on. [laughs]

+ +

SHAILA: Yes, really.

+ +

VICTORIA: Once all the paperwork is finished.

+ +

SHAILA: Exactly. So this will be basically marketing, marketing, and communication issues.

+ +

VICTORIA: Wonderful. Why crowdfunding versus regular government funding for these types of projects?

+ +

SHAILA: It is important to enhance alternative financing solutions because the reality is that most businesses in their early stage will not be financially strong enough to ask for financing solutions such as bank loans, for example. That means that they don't have enough capital at first to engage in more debts. What they need is to reinforce their capital in an early stage.

+ +

When the founders, for example, do not have basically the money themselves to fund their own company, calling the crowd to help is a very good solution to reinforce their capital. So they have more power after that to go for other types of financing solutions such as fundraising huge amounts from investors, from institutions, or to ask for, for example, bank loans. They are strong enough then to go for more and to develop their solutions and scale up.

+ +

VICTORIA: That makes a lot of sense. And I'm wondering if, in your process, since April, have there been any pivots you had to make where you were going in one direction, and then you learned something and decided you needed to go a completely different direction?

+ +

SHAILA: Yes, to be honest, my first idea was to target startups from the European overseas territories only. So that was my first idea. When I did my market study, I discovered that the market was too small. It was a very interesting market because those startups are far from the countries they are related to. French Caribbean islands are geographically far from the French territory, French country in Europe. They have some localization barrier, for example, to reach the national market. And that is the case for any other overseas European territory.

+ +

So my first idea was to give them access and give them visibility in the national territory because crowdfunding is an online solution, but, well, the market was too small, for example. So this was not a good path to go. And I had to reevaluate and do another market study because also my main goal was to answer an environmental need.

+ +

VICTORIA: That makes a lot of sense. And it is interesting how your idea of the market evolves once you really start building something and start getting information about it.

+ +

SHAILA: I can give you another example of a switch of the idea, of the initial idea I had. We wanted to start operating immediately in all Europe. We learned that because of the European regulations of the markets, we need to go step by step and country by country. This made us focus first on the French market. And we know now that we will be able to reach the other European ecosystems one by one. That helped us refine our marketing strategy.

+ +

VICTORIA: Interesting. So when you started building your product or building the idea, and you went country by country, was there a concern about getting too specific to that country? Or was it easy to build out to a new country once you were ready to move on?

+ +

SHAILA: It's quite easy in the conceptual stage because the European Union has really standardized a lot of economic or financial regulations. So we have a system of like an economic or business passport which makes it quite easy. But the main problem is really being able to adapt to different languages, Spanish, or German, or English, or Italian, to adapt to those markets with their specificities, which are linked not only to their language but those still are marketing aspects. But other than that, thanks to the European Union system, it is quite easy to really build a whole European strategy.

+ +

VICTORIA: Right. I feel like that should be a part of an ad or marketing [laughter] just for the European Union.

+ +

SHAILA: It could be. It could be, right.

+ +

VICTORIA: Well, that makes a lot of sense. And we understand as well, being an international company, that being able to adapt to different languages does present its own challenges.

+ +

SHAILA: Exactly.

+ +

VICTORIA: Well, wonderful. What advice would you give to yourself at the beginning of this project if you could go back in time?

+ +

SHAILA: You know, it's funny because I have been familiar to business for a long time. I come from a businessmen family. And also, I've been working as a financial management consultant for small companies and startups for some years before. But still, I didn't maybe gather enough money at first to start this very capital-consuming business. So I would advise myself to gather twice the money I had before. [chuckles] Even if we found solutions and we are totally equipped, but well, I was maybe...I didn't prepare enough capital at first.

+ +

And also another advice would have been from the start to not forget to sleep [laughs] because this is really crucial to maintain good health when you start a new project, and especially a very energy-consuming one. The health of your project and of your company also depends on your own health.

+ +

VICTORIA: Wonderful advice. [laughs] Everyone who's working on something they're passionate about should remember that. You're 100% right. It's dependent on your own health first, right?

+ +

SHAILA: Exactly. It could be the passion drives you so much that...and you know the amount of work you effectively have to do, so you can really get caught in the amount of work. But sleep is a very good strategy to keep going.

+ +

VICTORIA: I love sleep. I'm a big fan. My sleep schedule is a little messed up because I was in the Azores last week.

+ +

SHAILA: So the jetlag was big.

+ +

VICTORIA: Yeah, but it helps me because we're kind of an early riser family anyways. Yeah, I can have time to have my coffee before I start work. [laughs]

+ +

SHAILA: Right. I see, yeah.

+ +

VICTORIA: Is there any other final takeaways you want to give to our audience?

+ +

SHAILA: I would ask the people who listen to really join us as soon as we are ready to launch and to talk about We Take Part to their friends and family. Also, to reach out because we could help understand more what we can do, how we can help, and how investing and supporting sustainable business how important it is. And when it's correctly made, and it is profitable, it is profitable for everyone, for the whole society, not only for an economic system.

+ +

VICTORIA: Wonderful. And we'll have the opportunity to include any links or marketing in our show notes.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thought. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+LJ_kZBSY + + ]]> + + Victoria Guido + + + 456: Jeli.io with Laura Maguire + https://podcast.thoughtbot.com/456 + 0e77ab23-35be-435c-b4ab-19f5e67b4801 + Thu, 05 Jan 2023 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Laura Maguire is a Researcher at Jeli.io, the first dedicated incident analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems. + +Victoria talks to Laura about incident management, giving companies a powerful tool to learn from their incidents, and what types of customers are ideal for taking on a platform like Jeli.io. + 46:37 + no + + + Laura Maguire is a Researcher at Jeli.io, the first dedicated incident analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems. +Victoria talks to Laura about incident management, giving companies a powerful tool to learn from their incidents, and what types of customers are ideal for taking on a platform like Jeli.io. +Jeli.io (https://www.jeli.io/) +Follow Jeli.io on Instagram (https://www.instagram.com/jeli_io/), Twitter (https://twitter.com/jeli_io) or LinkedIn (https://www.linkedin.com/company/jeli-inc/). +Follow Laura Maguire on Twitter (https://twitter.com/LauraMDMaguire) or LinkedIn (https://www.linkedin.com/in/lauramaguire/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Laura Maguire, Researcher at Jeli, the first dedicated instant analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems. Laura, thank you for joining me. +LAURA: Thanks for having me, Victoria. +VICTORIA: This might be a very introductory level question but just right off the bat, what is an incident? +LAURA: What we find is a lot of companies define this very differently across the space, but typically, it's where they are seeing an impact, either a customer impact or a degradation of their service. This can be either formally, it kind of impacts their SLOs or their SLAs, or informally it's something that someone on the team notices or someone, you know, one of their users notice as being degraded performance or something not working as intended. +VICTORIA: Gotcha. From my background being in IT operations, I'm familiar with incidents, and it's been a practice in IT for a long time. But what brought you to be a part of building this platform and creating a product around incidents? +LAURA: I am a, let's say, recovering safety professional. +VICTORIA: [chuckles] +LAURA: I started my career in the safety and risk management realm within natural resource industries in the physical world. And so I worked with people who were at the sharp end in high-risk, high-consequence type work. And they were really navigating risk and navigating safety in the real world. And as I was working in this domain, I noticed that there was a delta between what was being said, created safety, and helped risk management and what I was actually seeing with the people that I was working with on the front lines. +And so I started to pull the thread on this, and I thought, is work as done really the same as work as written or work as prescribed? And what I found was a whole field of research, a whole field of practice around thinking about safety and risk management in the world of cognitive work. And so this is how people think about risk, how they manage risk, and how do they interpret change and events in the world around them. +And so as I started to do my master's degree in human factors and system safety and then later my Ph.D. in cognitive systems engineering, I realized that whether you are on the frontlines of a wildland fire or you're on the frontlines of responding to an incident in the software realm, the ways in which people detect, diagnose, and repair the issues that they're facing are quite similar in terms of the cognitive work. +And so when I was starting my Ph.D. work, I was working with Dr. David Woods at the Cognitive Systems Engineering Lab at The Ohio State University. And I came into it, and I was thinking I'm going to work with astronauts, or with fighter pilots, or emergency room doctors, these really exciting domains. And he was like, "We're going to have you work with software engineers." +And at first, I really failed to see the connection there, but as I started to learn more about site reliability engineering, about DevOps, about the continuous deployment, continuous integration world, I realized software engineers are really at the forefront of managing critical digital infrastructure. They're keeping up the systems that run society, both for recreation and pleasure in the sense of Netflix, for example, as well as the critical functions within society like our 911 call routing systems, our financial markets. +And so the ability to study how software engineers detect outages, manage outages, and work together collaboratively across the team was really giving us a way to study this kind of work that could actually feed back into other types of domains like emergency response, like emergency rooms, and even back to the fighter pilots and astronauts. +VICTORIA: Wow, that's so interesting. And so is your research that went into your Ph.D. did that help you help define the product strategy and kind of market fit for what you've been building at Jeli? +LAURA: Yeah, absolutely. So Nora Jones, who is the founder and CEO of Jeli, reached out to me at a conference and told me a little bit about what she was thinking about, about how she wanted to support software engineers using a lot of this literature and a lot of the learnings from these other domains to build this product to help support incident management in software engineering. +So we base a lot of our thinking around how to help support this cognitive work and how to help resilient performance in these very dynamic, these very changing large scale, you know, distributed software systems on this research, as well as the research that we do with our own users and with our own members from learning from incidents in software engineering Slack community that Nora and several other fairly prominent names within the software community started, Lorin Hochstein, John Allspaw Dr. Richard Cook, Jessica DeVita, Ryan Kitchens, and I may be missing someone else but...and myself, oh, Will Galego as well. +Yeah, we based a lot of our understandings, really deep qualitative understandings of what is work like for software engineers when they're, you know, in continuous deployment type environments. And we've translated this into building a product that we think helps but not hinders by getting in the way of engineers while they're under time pressure and there's a lot of uncertainty. And there's often quite a bit of stress involved with responding to incidents. +VICTORIA: Right. And you mentioned resilience engineering. And for those who don't know, David Woods, who you worked on with your Ph.D., wrote "Resilience Engineering: Concepts and Precepts." So maybe you could talk a little bit about resilience engineering and what that really means, not just in technology but in the people who were running the tools, right? +LAURA: Yeah. So resilience engineering is different from how we think about protecting and defending our software systems. And it's different in the sense that we aren't just thinking about how do we prevent incidents from happening again, like, how do we fix things that have happened to us in the past? But how do we better understand the ways in which our systems operate under a wide variety of conditions? So that includes normal operating conditions as well as abnormal or anomalous operating conditions, such as an incident response. +And so resilience engineering was kind of this way of thinking differently about predicting failure, about managing failure, and navigating these kinds of worlds. And one of the fundamental differences about it is it sees people as being the most adaptive component within the system of work. So we can have really good processes and practices around deploying code; we can institute things like cross-checking and peer review of code; we can have really good robust backup and failover systems, but ultimately, it's very likely that in these kinds of complex and adaptive always-changing systems that you're going to encounter problems that you weren't able to anticipate. +And so this is where the resilience part comes in because if you're faced with a novel problem, if you're faced with an issue you've never seen before, or a hidden dependency within your system, or an unanticipated failure mode, you have to adapt. You have to be able to take all of the information that's available to you in the moment. You have to interpret that in real-time. You have to think of who else might have skills, knowledge, expertise, access to information, or access to certain kinds of systems or software components. And you have to bring all of those people together in real-time to be able to manage the problem at hand. +And so this is really quite a different way of thinking about supporting this work than just let's keep the runbooks updated, and let's make sure that we can write prescriptive processes for everything that we're going to encounter. Because this really is the difference that I saw when I was talking about earlier about that work is done versus work is prescribed. The rules don't cover all of the situations. And so you have to think of how do you help people adapt? How do you help people access information in real-time to be able to handle unforeseen failures? +VICTORIA: Right. That makes a lot of sense. It's an interesting evolution of site reliability engineering where you're thinking about the users' experience of your site. It's also thinking about the people who are running your site and what their experience is, and what freedom they have to be able to solve the problems that you wouldn't be able to predict, right? +LAURA: Yeah, it's a really good point, actually, because there is sort of this double layer in the product that we are building. So, as you mentioned earlier, we are an incident analysis platform, and so what does that mean? Well, it means that we pull in data whenever there's been an incident, and we help you to look at it a little bit more deeply than you may if you're just following a template and sort of reconstructing a timeline. +And so we pull in the actual Slack data that, you know, say, an ops channel or an incident channel that's been spun up following a report of a degraded performance or of an outage. And we look very closely at how did people talk to one another? Who did they bring into the incident? What kinds of things did they think were relevant and important at different points in time? And in doing this, it helps us to understand what information was available to people at different points in time. +Because after the incident and after it's been resolved, people often look back and say, "Oh, there's nothing we can learn from that. We figured out what it was." But if we go back and we start looking at how people detected it, how they diagnosed it, who they brought into the event, we can start to unpack these patterns and these ways of understanding how do people work together? What information is useful at different points in time? Which helps us get a deeper understanding of how our systems actually work and how they actually fail. +VICTORIA: Right. And I see there are a few different ways the platform does that: there's a narrative builder, a people view, and also a visual timeline. So, do you find that combining all those things together really gives companies a powerful tool to learn from their incidents? +LAURA: Yeah. So let me talk a little bit about each of those different components. Our MVP of the product we started out with this understanding of the incident analyst and the incident investigator who, you know, was ready to dive in and ready to understand their incident and apply some qualitative analysis techniques to thinking about their incidents. And what we found was there are a number of these people who are really interested in this deep dive within the software industry. But there's a broader subset of folks that they work with who maybe only do these kinds of incident analysis every once in a while, and they're not as interested in going quite as deep. +And so the narrative builder is really this kind of bridge between those two types of users. And what it does is helps construct a timeline which is typically what most companies do to help drive the discussion that they might have in a post-mortem or to drive their kind of findings in their summary report. And it helps them take this closer look at the interactions that happened in that slack transcript and raise questions about what kinds of uncertainties there were, point out who was involved, or interesting aspects of the event at that point in time. +And it helps them to summarize what was happening. What did people think was happening at this point in time to create this story about the incident? And the story element is really important because we all learn from stories. It helps bring to life some of the details about what was hard, who was involved, how did they get brought in, what the sources of technical failure were, and whether those were easy or difficult to understand and to repair once the source of the failure was actually understood. And so that narrative builder helps reconstruct this timeline in a much richer way but also do it very efficiently. +And as you mentioned, the visual timeline is something that we've created to help that lightweight user or that every once in a while user to go a little bit deeper on their analysis. And how we do that is because it lays out the progression of the event in a way that helps you see, oh, this maybe wasn't straightforward. We didn't detect it in the beginning, and then diagnose it, and then repair it at the end. What happened actually was the detection was intermittent. The signals about what was going wrong was intermittent, and so that was going on in parallel with the diagnosis. The diagnosis took a really long time, and that may have been because we can also see the repair was happening concurrently. +And so it starts to show these kinds of characteristics about whether the incident was difficult, whether it was challenging and hard, or whether it was simple and straightforward. This helps lend a bit more depth to metrics like MTTR and TTD by saying, oh, there was a lot more going on in this incident than we initially thought. +The last thing that you mentioned was the people view, and so that really sets our product apart from other products in that we look at the sociotechnical system. So it's not just about the software that broke; it is about who was involved in managing that system, in repairing that system, and in communicating about that system outwardly. And so the people view this kind of pulls in some HR data. It helps us to understand who was involved. How long have they been in their role? Were they on-call? Were they not on-call? And other kinds of irrelevant details that show us what was their engagement or their interaction with this event. +And so when we start to bring in the socio part of the sociotechnical system, we can identify things like what knowledge do we have within the organization? Is that knowledge well-distributed, or is it just isolated in one or two people? And so those people are constantly getting pulled into incidents when they may be not on-call, which can start to show us whether or not these folks are in danger of burning out or whether their knowledge might need to be transferred more broadly throughout the organization. +So this is kind of where the resilience piece comes in because it helps us to distribute knowledge. It helps us to identify who is relevant and useful and how do they partner and collaborate with other people, and their knowledge and skill sets to be able to manage some of the outages that they face? +VICTORIA: That's wonderful because one of my follow-up questions would be, as a CEO, as a founder, what kind of insights or choices do you get to make now that you have this insight to help make your team more resilient? [laughs] +LAURA: So if this is a manager, or a founder, or a CEO that is looking at their data in Jeli, they can start to understand how to resource their teams more appropriately, as I mentioned, how to spread that knowledge around. They can start to see what parts of their system are creating the most problems or what parts of their system do they have maybe less insight into how it works, how it interacts with other parts of the system, and what this actually means for their ability to meet their SLOs or their SLAs. So it gives you a more in-depth understanding of how your business is actually operating on both the technical side of things, as well as on the people side of things. +VICTORIA: That makes a lot of sense. Thank you for that overview of the platform. There's the incident analysis platform, and you also have the bot, the response chatbot. Can you tell me a little bit more about that? +LAURA: Yeah, absolutely. We think that incident management should be conducted wherever your work actually takes place, and so for most of our customers and a lot of folks that we know about in the industry, that's Slack. And so, if you are communicating in real-time with your team in Slack, we think that you should stay there. +And so, we built this incident management bot that is free and will be free for the lifetime of the product. Because we think that this is really the fundamental basis for helping you manage your incidents more efficiently and more effectively. So it's a pretty lightweight bot. It gives kind of some guardrails or some guidance around collaboration by spinning up a new incident channel, helping you to bring the right kinds of responders into that, helping you to communicate to interested stakeholders by broadcasting to channels they might be in. +It kind of nudges you to think about how to communicate about what's happening during different stages of the event progression. And so it's prompting you in a very lightweight way; hey, do you have a status update? Do you have a summary of what the current thinking is? What are the hypotheses about what's going on? Who's conducting what kinds of activities right now? So that if I'm a responder that's coming into the event after 20-30 minutes after it started, I can very quickly come up to speed, understand what's going on, who's doing what, and figure out what's useful for me to do to help step in and not disrupt the incident management that's underway right now. +Our users can choose to use the bot independently of the incident analysis platform. But of course, being able to ingest that incident into Jeli it helps you understand who's been involved in the incident, if they've been involved in similar incidents in the past, and helps them start to see some patterns and some themes that emerge over time when you start to look at incidents across the organization. +VICTORIA: That makes sense. And I love that it's free and that there's something for every type of organization to take advantage of there. And I wonder if at Jeli you have data about what type of customer is it who'd be targeted or really ideal to take on this kind of platform. +LAURA: So most organizations...I was actually recently at SREcon EMEA, and there was a really interesting series of talks; one was SRE for Enterprise, and the next talk was SRE for Startups. And so it was a very thought-provoking discussion around is SRE for everyone, so site reliability engineering? Even smaller teams are starting to have to be responsible for reliability and responsible for running their service. +And so we kind of have built our platform thinking about how do we help not just big enterprises or organizations that may have dedicated teams for this but also small startups to learn from their incidents. So internally, we actually call incidents opportunities as in they are learning opportunities for checking out how does your system actually work? How do your people work together? What things were difficult and challenging about the incident? And how do you talk about those things as a team to help create more resilient performance in future? +So in terms of an ideal customer, it's really folks that are interested in conducting these sort of lightweight but in-depth looks at how their system actually works on both the people side of things and the technical side of things. Those who we found are most successful with our product are interested in not so much figuring out who did the thing and who can they blame for the incident itself but rather how do they learn from what happened? +And would another engineer, or another product owner, another customer service representative, whoever the incident may be sort of focused around, would another person in their shoes have taken the same actions that they took or made the same decisions that they made? Which helps us understand from a systems level how do we repair or how do we adjust the system of work surrounding folks so that they are better supported when they're faced with uncertainty, or with that kind of time pressure, or that ambiguity about what's actually going on? +VICTORIA: And I love that you said that because part of the reason [laughs] I invited you on to the podcast is that a lot of companies I have experience with don't think about incidents until it happens to them, and then it can be a scramble. It can impact their customer base. It can stress their team out. But if you go about creating...the term obviously you all use is psychological safety on your team, and maybe you use some of the free tools from Jeli like the Post-Incident Guide and the Incident Analysis 101 blog to set your team up for success from the beginning, then you can increase your customer loyalty and your team loyalty as well to the company. Is that your experience? +LAURA: Yeah, absolutely. So one thing that I have learned throughout my career, you know, starting way back in forestry and looking at safety and risk in that domain, was as soon as there is an accident or even a serious near miss, right away, everybody gets sweaty palms. Everybody is concerned about, uh-oh, am I going to get blamed for this? Am I going to get fired? Am I going to get publicly shamed for the decisions that I made when I was in this situation? +And what that response, that reaction does is it drives a lot of the communication and a lot of the understanding of the conditions that that person was in. It drives that underground. And it's important to allow people to talk about here's what I was seeing, here's what I was experiencing because, in these kinds of complex systems, information is not readily available to people. The signals are not always coming through loud and clear about what's going on or about what the appropriate actions to take are. Instead, it's messy; it's loud, it's noisy. +There are usually multiple different demands on that person's attention and on their time, and they're often managing trade-offs: do I keep the system down so that I can gather more information about what's actually going on, or do I just try and bring it up as quickly as I can so that there's less impact to users? Those kinds of decisions are having to be made under pressure. So when we create these conditions of psychological safety, when we say you know what? This happened. We want to learn from it. We've already made this investment. +Richard Cook mentioned in the very first SNAFU Catchers Report, which was a report that came out of Ohio State, that incidents are unplanned investments into understanding how your system works. And so you've already had the incident. You've already paid the price of that downtime or of that outage. So you might as well extract some learning from it so that you can help create a safer and more resilient system in the future. +So by helping people to reconstruct what was actually happening in real-time, not what they were retrospectively saying, "Oh, I should have done this," well, you didn't do that. So let's understand why you thought at that moment in time that was the right way to respond because, more than likely, other people in that same position would have made that same choice. And so it helps us to think more broadly about ways that we can support decision-making and sense-making under conditions of stress and uncertainty. And ultimately, that helps your system be more resilient and be more reliable for your customers. +VICTORIA: What a great reframing: unplanned investment. [laughs] And if you don't learn from it, then you're going to lose out on what you've already invested that time in resolving it, right? +LAURA: Absolutely. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +VICTORIA: Getting more into that psychological safety and how to create that culture where people feel safe telling about what really happened, but how does that relate to...Jeli says that they are a people software. [laughs] Talk to me more about that. Like, what advice do you give founders and CEOs on how to create that psychological safety which makes them be more resilient in these types of incidents? +LAURA: So you mentioned the Howie Guide that we published last year, and this is our guidance around how to do incident analysis, how to help your team start to learn from their incidents, and Howie stands for how we got here. And that's really important, that language because what it says is there's a history that led up to this incident. And most teams, when they've had an outage, they'll kind of look backwards from that outage, maybe an hour, maybe a day, maybe to the last deploy. +But they don't think about how the decisions got made to use that piece of software in the first place. They don't think about how did engineers actually get on-boarded to being on-call. They don't necessarily think about what kinds of skills, and knowledge, and expertise when we're hiring a DevOps engineer, and I'm using air quotes here or an SRE. What kinds of skills and knowledge do they actually have? Those are very broad terms. And what it means to be a DevOps engineer or an SRE is quite underspecified. +And so the knowledge behind the folks that you might hire into the company is going to necessarily be very diverse. It's going to be partial and incomplete in many ways because not everyone can know everything about the system. And so, we need to have multiple diverse perspectives about how the system works, how our customers use that system, what kinds of pressures and constraints exist within our company that allow us some possibilities over others. We need to bring all of those perspectives together to get a more reflective picture of what was actually happening before this incident took place and how we actually got here. +This reframing helps a lot of people disarm that initial defensiveness response or that initial, oh, shoot; I'm going to get in trouble for this kind of response. And it says to them, "Hey, you're a part of this bigger system of work. You are only one piece of this puzzle. And what we want to try and do is understand what was happening within the company, not just what you did, what you said, and what you decided." +So once people realize that you're not just trying to find fault or place blame, but you're really trying to understand their work, and you're trying to understand their work with other teams and other vendors, and trying to understand their work relative to the competing demands that were going on, so those are some of the things that help create psychological safety. +About ten years ago, John Allspaw and the team at Etsy put out The Etsy Debriefing Facilitation Guide, which also poses a number of questions and helps to frame the post-incident learnings in a way that moves it from the individual and looks more collectively at the company as a whole. And so these things are helpful for founders or for CEOs to help bring forward more information about what's really going on, more information about what are the real risks and threats and opportunities within the company, and gives you an opportunity to step back and do what we call microlearning, which is sharing knowledge about how the system works, sharing understandings of what people think is going on, and what people know about the system. +We don't typically talk about those things unless there's a reason to, and incidents kind of give us that reason because they're uncomfortable and they can be painful. They can be very public. They can be very disruptive to what we think about how resilient and reliable we actually are. And so if you can kind of step away from this defensiveness and step away from this need to place blame and instead try and understand the conditions, you will get a lot more learning and a lot more resilience and reliability out of your teams and out of your systems. +VICTORIA: That makes sense to me. And I'd like to draw a connection between that and some other things you mentioned with The 2022 Accelerate State of DevOps Report that highlights that the people who are often responding to those incidents or in that high-stress situation tend to be historically underrepresented or historically excluded groups. And so do you see that having this insight into both who is actually taking on a lot of the work when these incidents happen and creating that psychological safety can make a better environment for diversity, equity, inclusion at a company as well? +LAURA: Well, I think anytime you work to establish trust and transparency, and you focus on recognizing the skills that people do have, the knowledge that they do have, and not over assuming that someone knows something or that they have been involved in the discussions that may have been relevant to an incident, anytime you focus on that trust and transparency you are really signaling to people within your organization that you value their contributions and that you recognize that they've come to work and trying to do a good job. But they have multiple competing demands on their attention and on their time. +And so we're not making assumptions about people being complacent, or people being reckless or being sloppy in their work. So that creates an environment where people feel more willing to speak up and to talk about some of the challenges that they might face, to talk about the ways in which it's not clear to them how certain parts of the system work or how certain teams actually operate. +So you're just opening the channels for communication, which helps to share more knowledge. It helps to share more information about what teams are doing at different points in time. And this helps people to preemptively anticipate how a change that they might be making in their part of the system could be influencing up or downstream teams. And so this helps create more resilience because now you're thinking laterally about your system and about your involvement across teams and across boundary lines. +And an example of this is if a marketing team...this is a story that Nora tells quite a bit; if a marketing team is, say, launching a Super Bowl commercial for their company but they don't actually tell the engineers on-call that that is about to happen, you can create all sorts of breakdowns when all of a sudden you have this surge of traffic to your website because people see the Super Bowl commercial and they want to go to the site. And then you have a single person who's trying to respond to that in real-time. +So, instead, when you do start thinking about that trust and transparency, you're helping teams to help each other and to think more broadly about how their work is actually impacting other parts of the system. So from a diversity and inclusion and underrepresented groups perspective, this is creating the conditions for more people to be involved, more people to feel like their voice is going to be heard, and that their perspective actually matters. +VICTORIA: That sounds really powerful, and I'm glad we were able to touch on that. Shifting gears a little bit, I wanted to talk about two different questions; so one is if you could travel back in time to when Jeli first started, what advice would you give yourself, your past self? +LAURA: I would encourage myself to recognize that our ability to experiment is fundamental to our ability to learn. And learning is what helps us to iterate faster. Learning is what helps us to reflect on the tool that we're building or the feature that we're building and what this actually means to our users. I actually copped that advice to myself from CEO Zoran Perkov of the Long-Term Stock Exchange. They launched a whole new stock market during the pandemic with a fully remote team. +And I had interviewed him for an article that I wrote about resilient leadership. And he said to me, like, "My job as a CEO is 100% about protecting our ability to experiment as a company because if we stop learning, we're not going to be able to iterate. We're not going to be able to adapt to the changes that we see in the market and in our users." So I think I would tell myself to continually experiment. +One of the things that I talk to our customers about a lot because many of them are implementing new incident management programs or they're trying to level up their engineering teams around incident analysis, and I would say, "This doesn't have to be a fully-fleshed out program where you know all of the ways in which this is going to unfold." It's really about trying experiments, conduct some training, start small. Do one incident analysis on a really particularly spicy incident that you may have had or a really challenging incident where a lot of people were surprised by what happened. +Bring together that group and say, "Hey, we're going to try something a little bit different here. We'll use some questions from the Howie Guide. We'll use the format and the structure from the Etsy Debriefing Guide. And we're just going to try and learn what we can about this event. We're not going to try and place blame. We're not going to try and generate corrective actions. We just want to see what we can learn from this." Then ask people that were involved, "How did this go? What did we learn from it? What should we do differently next time?" +And continually iterate on those small, little experiments so that you can grow your product and grow your team's capacity. I think it took us a little bit of time to figure that out within the organization, but once we did, we were just able to collaborate more effectively work more effectively by integrating some of the feedback that we were getting from our users. +And then the last piece of advice that I would give myself is to really invest in cross-discipline coordination and collaboration. Engineers, designers, researchers, CEOs they all have a different view of the product. They all have a different understanding of what the goals and priorities are. And those mental models of the product and of what the right thing to do is are constantly changing. And they all have different language that they use to talk about the product and to talk about their processes for integrating this understanding of the changing conditions and the changing user into the product. +And so I would say invest in establishing common ground across the different disciplines within your team to be able to talk about what people are seeing, to be able to stop and identify when we're making assumptions about what other people know or what other people's orientation towards the problem or towards the product are. And spend a little bit of time saying, "When I say this is important, I'm saying it's important because of XYZ, not just this is important." So spending a little bit of time elaborating on what your mental model is and where you're drawing from can help the teams work more effectively together across those disciplines. +VICTORIA: That's pretty powerful advice. You're iterating and experimenting at Jeli. What's on the horizon that you are...what new experiments are you excited about? +LAURA: One of the things that has been front and center for us since we started is this idea of cross-incident analysis. And so we've kind of built out a number of different features within the product, being able to help tag the incident with the relevant services and technologies that were involved, being able to identify which teams were involved, and also being able to identify different kinds of themes or patterns that emerge from individual incidents. +So all of this data that we can get from mostly just from the ingested incident itself or from the incident that you bring into Jeli but also from the analysis that you do on it this helps us start to be able to see across incidents what's happening not just with the technical side of things. So is it always Travis that is causing a problem? Are there components that work together that kind of have these really hidden and strange interdependencies that are really hard for the team to actually cope with? What kinds of themes are emerging across your suite of opportunities, your suite of incidents that you've ingested? +Some of the things that we're starting to see from those experiments is an ability to look at where are your knowledge islands within your organization? Do you have an engineer who, if they were to leave, would take the majority of your systems knowledge about your database, or about your users, or about some critical aspect of your system that would disappear with all of that tacit knowledge? Or are there engineers that work really effectively together during really difficult incidents? +And so you can start to unpack what are these characteristics of these people, and of these teams, and of these technologies that offer both opportunities or threats to your organization? So basically, what we're doing is we're helping you to see how your system performs under different kinds of conditions, which I think as a safety and risk professional working in a variety of different domains for the last 15 years, I think this is really where the rubber hits the road in helping teams be more reliable, and be more resilient, and more proactive about where investments in maintenance, or training, or headcount are going to have the biggest bang for your buck. +VICTORIA: That makes a lot of sense. In my experience, sometimes those decisions are made more on intuition or on limited data so having a more full picture to rely on probably produces better results. [laughs] +LAURA: Yeah, and I think that we all want to be data-driven, thinking about not only the quantitative data is how many incidents do we have around certain parts of the system, or certain teams, or certain services? But also, the qualitative side of things is what does this actually mean? And what does this mean to our ability to grow and change over time and to scale? The partnership of that quantitative data and qualitative data means we're being data-driven on a whole other level. +VICTORIA: Wonderful. And it seems like we're getting close to the end of our time here. Is there anything else you want to give as a final takeaway to our listeners? +LAURA: Yeah. So I think that we are, you know, as a domain, as a field, software engineering is increasingly becoming responsible for not only critical infrastructure within society, but we have a responsibility to our users and to each other within our companies to help make work better, help make our services more reliable and more resilient over time. +And there's a variety of lessons that we can learn from other domains. As I mentioned before, aviation, healthcare, nuclear power all of those kinds of domains have been thinking about supporting cognitive work and supporting frontline operators. And we can learn from this history and this literature that exists out there. +There is a GitHub repo that Lorin Hochstein has curated with a number of other folks with the industry that points to some of these resources. And as well, we'll be hosting the first Learning From Incidents in Software Engineering Conference in Denver in February, February 15 and 16th. And one feature of this conference that I'm super excited about is affectionately called CasesConf. And it is going to be an opportunity for software engineers from a variety of organizations to tell real stories about incidents that they had, how they handled them, what was challenging, what went surprisingly well, and just what is actually going on within their organizations. +And this is kind of a new thing for the software industry to be talking very publicly about failures and sharing the messy details of our incidents. This won't be a recorded part of the conference. It is going to be conducted under the Chatham House Rule, which is participants who are in the room while these stories are being told can share some of the stories but not any identifying details about the company or the engineers that were involved. +And so this kind of real-world situations helps us to, as I talked about before, with that psychological safety, helps us to say this is the reality of operating complex systems. They're going to fail. We're going to have to learn from them. And the more that we can talk at an industry level about what's going on and about what kinds of things are creating problems or opportunities for each other, the more we're going to be able to lift the bar for the industry as a whole. So you can check out register.learningfromincidents.io for more information about the conference. And we can link Lorin's resilience engineering GitHub repo in the notes as well. +VICTORIA: Wonderful. Well, I was looking for an excuse to come to Denver in February anyways. +LAURA: We would love to have ya. +VICTORIA: Thank you. And thank you so much for taking time to share with us today, Laura. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Laura Maguire. + + + Laura Maguire is a Researcher at Jeli.io, the first dedicated incident analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems.

+ +

Victoria talks to Laura about incident management, giving companies a powerful tool to learn from their incidents, and what types of customers are ideal for taking on a platform like Jeli.io.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Laura Maguire, Researcher at Jeli, the first dedicated instant analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems. Laura, thank you for joining me.

+ +

LAURA: Thanks for having me, Victoria.

+ +

VICTORIA: This might be a very introductory level question but just right off the bat, what is an incident?

+ +

LAURA: What we find is a lot of companies define this very differently across the space, but typically, it's where they are seeing an impact, either a customer impact or a degradation of their service. This can be either formally, it kind of impacts their SLOs or their SLAs, or informally it's something that someone on the team notices or someone, you know, one of their users notice as being degraded performance or something not working as intended.

+ +

VICTORIA: Gotcha. From my background being in IT operations, I'm familiar with incidents, and it's been a practice in IT for a long time. But what brought you to be a part of building this platform and creating a product around incidents?

+ +

LAURA: I am a, let's say, recovering safety professional.

+ +

VICTORIA: [chuckles]

+ +

LAURA: I started my career in the safety and risk management realm within natural resource industries in the physical world. And so I worked with people who were at the sharp end in high-risk, high-consequence type work. And they were really navigating risk and navigating safety in the real world. And as I was working in this domain, I noticed that there was a delta between what was being said, created safety, and helped risk management and what I was actually seeing with the people that I was working with on the front lines.

+ +

And so I started to pull the thread on this, and I thought, is work as done really the same as work as written or work as prescribed? And what I found was a whole field of research, a whole field of practice around thinking about safety and risk management in the world of cognitive work. And so this is how people think about risk, how they manage risk, and how do they interpret change and events in the world around them.

+ +

And so as I started to do my master's degree in human factors and system safety and then later my Ph.D. in cognitive systems engineering, I realized that whether you are on the frontlines of a wildland fire or you're on the frontlines of responding to an incident in the software realm, the ways in which people detect, diagnose, and repair the issues that they're facing are quite similar in terms of the cognitive work.

+ +

And so when I was starting my Ph.D. work, I was working with Dr. David Woods at the Cognitive Systems Engineering Lab at The Ohio State University. And I came into it, and I was thinking I'm going to work with astronauts, or with fighter pilots, or emergency room doctors, these really exciting domains. And he was like, "We're going to have you work with software engineers."

+ +

And at first, I really failed to see the connection there, but as I started to learn more about site reliability engineering, about DevOps, about the continuous deployment, continuous integration world, I realized software engineers are really at the forefront of managing critical digital infrastructure. They're keeping up the systems that run society, both for recreation and pleasure in the sense of Netflix, for example, as well as the critical functions within society like our 911 call routing systems, our financial markets.

+ +

And so the ability to study how software engineers detect outages, manage outages, and work together collaboratively across the team was really giving us a way to study this kind of work that could actually feed back into other types of domains like emergency response, like emergency rooms, and even back to the fighter pilots and astronauts.

+ +

VICTORIA: Wow, that's so interesting. And so is your research that went into your Ph.D. did that help you help define the product strategy and kind of market fit for what you've been building at Jeli?

+ +

LAURA: Yeah, absolutely. So Nora Jones, who is the founder and CEO of Jeli, reached out to me at a conference and told me a little bit about what she was thinking about, about how she wanted to support software engineers using a lot of this literature and a lot of the learnings from these other domains to build this product to help support incident management in software engineering.

+ +

So we base a lot of our thinking around how to help support this cognitive work and how to help resilient performance in these very dynamic, these very changing large scale, you know, distributed software systems on this research, as well as the research that we do with our own users and with our own members from learning from incidents in software engineering Slack community that Nora and several other fairly prominent names within the software community started, Lorin Hochstein, John Allspaw Dr. Richard Cook, Jessica DeVita, Ryan Kitchens, and I may be missing someone else but...and myself, oh, Will Galego as well.

+ +

Yeah, we based a lot of our understandings, really deep qualitative understandings of what is work like for software engineers when they're, you know, in continuous deployment type environments. And we've translated this into building a product that we think helps but not hinders by getting in the way of engineers while they're under time pressure and there's a lot of uncertainty. And there's often quite a bit of stress involved with responding to incidents.

+ +

VICTORIA: Right. And you mentioned resilience engineering. And for those who don't know, David Woods, who you worked on with your Ph.D., wrote "Resilience Engineering: Concepts and Precepts." So maybe you could talk a little bit about resilience engineering and what that really means, not just in technology but in the people who were running the tools, right?

+ +

LAURA: Yeah. So resilience engineering is different from how we think about protecting and defending our software systems. And it's different in the sense that we aren't just thinking about how do we prevent incidents from happening again, like, how do we fix things that have happened to us in the past? But how do we better understand the ways in which our systems operate under a wide variety of conditions? So that includes normal operating conditions as well as abnormal or anomalous operating conditions, such as an incident response.

+ +

And so resilience engineering was kind of this way of thinking differently about predicting failure, about managing failure, and navigating these kinds of worlds. And one of the fundamental differences about it is it sees people as being the most adaptive component within the system of work. So we can have really good processes and practices around deploying code; we can institute things like cross-checking and peer review of code; we can have really good robust backup and failover systems, but ultimately, it's very likely that in these kinds of complex and adaptive always-changing systems that you're going to encounter problems that you weren't able to anticipate.

+ +

And so this is where the resilience part comes in because if you're faced with a novel problem, if you're faced with an issue you've never seen before, or a hidden dependency within your system, or an unanticipated failure mode, you have to adapt. You have to be able to take all of the information that's available to you in the moment. You have to interpret that in real-time. You have to think of who else might have skills, knowledge, expertise, access to information, or access to certain kinds of systems or software components. And you have to bring all of those people together in real-time to be able to manage the problem at hand.

+ +

And so this is really quite a different way of thinking about supporting this work than just let's keep the runbooks updated, and let's make sure that we can write prescriptive processes for everything that we're going to encounter. Because this really is the difference that I saw when I was talking about earlier about that work is done versus work is prescribed. The rules don't cover all of the situations. And so you have to think of how do you help people adapt? How do you help people access information in real-time to be able to handle unforeseen failures?

+ +

VICTORIA: Right. That makes a lot of sense. It's an interesting evolution of site reliability engineering where you're thinking about the users' experience of your site. It's also thinking about the people who are running your site and what their experience is, and what freedom they have to be able to solve the problems that you wouldn't be able to predict, right?

+ +

LAURA: Yeah, it's a really good point, actually, because there is sort of this double layer in the product that we are building. So, as you mentioned earlier, we are an incident analysis platform, and so what does that mean? Well, it means that we pull in data whenever there's been an incident, and we help you to look at it a little bit more deeply than you may if you're just following a template and sort of reconstructing a timeline.

+ +

And so we pull in the actual Slack data that, you know, say, an ops channel or an incident channel that's been spun up following a report of a degraded performance or of an outage. And we look very closely at how did people talk to one another? Who did they bring into the incident? What kinds of things did they think were relevant and important at different points in time? And in doing this, it helps us to understand what information was available to people at different points in time.

+ +

Because after the incident and after it's been resolved, people often look back and say, "Oh, there's nothing we can learn from that. We figured out what it was." But if we go back and we start looking at how people detected it, how they diagnosed it, who they brought into the event, we can start to unpack these patterns and these ways of understanding how do people work together? What information is useful at different points in time? Which helps us get a deeper understanding of how our systems actually work and how they actually fail.

+ +

VICTORIA: Right. And I see there are a few different ways the platform does that: there's a narrative builder, a people view, and also a visual timeline. So, do you find that combining all those things together really gives companies a powerful tool to learn from their incidents?

+ +

LAURA: Yeah. So let me talk a little bit about each of those different components. Our MVP of the product we started out with this understanding of the incident analyst and the incident investigator who, you know, was ready to dive in and ready to understand their incident and apply some qualitative analysis techniques to thinking about their incidents. And what we found was there are a number of these people who are really interested in this deep dive within the software industry. But there's a broader subset of folks that they work with who maybe only do these kinds of incident analysis every once in a while, and they're not as interested in going quite as deep.

+ +

And so the narrative builder is really this kind of bridge between those two types of users. And what it does is helps construct a timeline which is typically what most companies do to help drive the discussion that they might have in a post-mortem or to drive their kind of findings in their summary report. And it helps them take this closer look at the interactions that happened in that slack transcript and raise questions about what kinds of uncertainties there were, point out who was involved, or interesting aspects of the event at that point in time.

+ +

And it helps them to summarize what was happening. What did people think was happening at this point in time to create this story about the incident? And the story element is really important because we all learn from stories. It helps bring to life some of the details about what was hard, who was involved, how did they get brought in, what the sources of technical failure were, and whether those were easy or difficult to understand and to repair once the source of the failure was actually understood. And so that narrative builder helps reconstruct this timeline in a much richer way but also do it very efficiently.

+ +

And as you mentioned, the visual timeline is something that we've created to help that lightweight user or that every once in a while user to go a little bit deeper on their analysis. And how we do that is because it lays out the progression of the event in a way that helps you see, oh, this maybe wasn't straightforward. We didn't detect it in the beginning, and then diagnose it, and then repair it at the end. What happened actually was the detection was intermittent. The signals about what was going wrong was intermittent, and so that was going on in parallel with the diagnosis. The diagnosis took a really long time, and that may have been because we can also see the repair was happening concurrently.

+ +

And so it starts to show these kinds of characteristics about whether the incident was difficult, whether it was challenging and hard, or whether it was simple and straightforward. This helps lend a bit more depth to metrics like MTTR and TTD by saying, oh, there was a lot more going on in this incident than we initially thought.

+ +

The last thing that you mentioned was the people view, and so that really sets our product apart from other products in that we look at the sociotechnical system. So it's not just about the software that broke; it is about who was involved in managing that system, in repairing that system, and in communicating about that system outwardly. And so the people view this kind of pulls in some HR data. It helps us to understand who was involved. How long have they been in their role? Were they on-call? Were they not on-call? And other kinds of irrelevant details that show us what was their engagement or their interaction with this event.

+ +

And so when we start to bring in the socio part of the sociotechnical system, we can identify things like what knowledge do we have within the organization? Is that knowledge well-distributed, or is it just isolated in one or two people? And so those people are constantly getting pulled into incidents when they may be not on-call, which can start to show us whether or not these folks are in danger of burning out or whether their knowledge might need to be transferred more broadly throughout the organization.

+ +

So this is kind of where the resilience piece comes in because it helps us to distribute knowledge. It helps us to identify who is relevant and useful and how do they partner and collaborate with other people, and their knowledge and skill sets to be able to manage some of the outages that they face?

+ +

VICTORIA: That's wonderful because one of my follow-up questions would be, as a CEO, as a founder, what kind of insights or choices do you get to make now that you have this insight to help make your team more resilient? [laughs]

+ +

LAURA: So if this is a manager, or a founder, or a CEO that is looking at their data in Jeli, they can start to understand how to resource their teams more appropriately, as I mentioned, how to spread that knowledge around. They can start to see what parts of their system are creating the most problems or what parts of their system do they have maybe less insight into how it works, how it interacts with other parts of the system, and what this actually means for their ability to meet their SLOs or their SLAs. So it gives you a more in-depth understanding of how your business is actually operating on both the technical side of things, as well as on the people side of things.

+ +

VICTORIA: That makes a lot of sense. Thank you for that overview of the platform. There's the incident analysis platform, and you also have the bot, the response chatbot. Can you tell me a little bit more about that?

+ +

LAURA: Yeah, absolutely. We think that incident management should be conducted wherever your work actually takes place, and so for most of our customers and a lot of folks that we know about in the industry, that's Slack. And so, if you are communicating in real-time with your team in Slack, we think that you should stay there.

+ +

And so, we built this incident management bot that is free and will be free for the lifetime of the product. Because we think that this is really the fundamental basis for helping you manage your incidents more efficiently and more effectively. So it's a pretty lightweight bot. It gives kind of some guardrails or some guidance around collaboration by spinning up a new incident channel, helping you to bring the right kinds of responders into that, helping you to communicate to interested stakeholders by broadcasting to channels they might be in.

+ +

It kind of nudges you to think about how to communicate about what's happening during different stages of the event progression. And so it's prompting you in a very lightweight way; hey, do you have a status update? Do you have a summary of what the current thinking is? What are the hypotheses about what's going on? Who's conducting what kinds of activities right now? So that if I'm a responder that's coming into the event after 20-30 minutes after it started, I can very quickly come up to speed, understand what's going on, who's doing what, and figure out what's useful for me to do to help step in and not disrupt the incident management that's underway right now.

+ +

Our users can choose to use the bot independently of the incident analysis platform. But of course, being able to ingest that incident into Jeli it helps you understand who's been involved in the incident, if they've been involved in similar incidents in the past, and helps them start to see some patterns and some themes that emerge over time when you start to look at incidents across the organization.

+ +

VICTORIA: That makes sense. And I love that it's free and that there's something for every type of organization to take advantage of there. And I wonder if at Jeli you have data about what type of customer is it who'd be targeted or really ideal to take on this kind of platform.

+ +

LAURA: So most organizations...I was actually recently at SREcon EMEA, and there was a really interesting series of talks; one was SRE for Enterprise, and the next talk was SRE for Startups. And so it was a very thought-provoking discussion around is SRE for everyone, so site reliability engineering? Even smaller teams are starting to have to be responsible for reliability and responsible for running their service.

+ +

And so we kind of have built our platform thinking about how do we help not just big enterprises or organizations that may have dedicated teams for this but also small startups to learn from their incidents. So internally, we actually call incidents opportunities as in they are learning opportunities for checking out how does your system actually work? How do your people work together? What things were difficult and challenging about the incident? And how do you talk about those things as a team to help create more resilient performance in future?

+ +

So in terms of an ideal customer, it's really folks that are interested in conducting these sort of lightweight but in-depth looks at how their system actually works on both the people side of things and the technical side of things. Those who we found are most successful with our product are interested in not so much figuring out who did the thing and who can they blame for the incident itself but rather how do they learn from what happened?

+ +

And would another engineer, or another product owner, another customer service representative, whoever the incident may be sort of focused around, would another person in their shoes have taken the same actions that they took or made the same decisions that they made? Which helps us understand from a systems level how do we repair or how do we adjust the system of work surrounding folks so that they are better supported when they're faced with uncertainty, or with that kind of time pressure, or that ambiguity about what's actually going on?

+ +

VICTORIA: And I love that you said that because part of the reason [laughs] I invited you on to the podcast is that a lot of companies I have experience with don't think about incidents until it happens to them, and then it can be a scramble. It can impact their customer base. It can stress their team out. But if you go about creating...the term obviously you all use is psychological safety on your team, and maybe you use some of the free tools from Jeli like the Post-Incident Guide and the Incident Analysis 101 blog to set your team up for success from the beginning, then you can increase your customer loyalty and your team loyalty as well to the company. Is that your experience?

+ +

LAURA: Yeah, absolutely. So one thing that I have learned throughout my career, you know, starting way back in forestry and looking at safety and risk in that domain, was as soon as there is an accident or even a serious near miss, right away, everybody gets sweaty palms. Everybody is concerned about, uh-oh, am I going to get blamed for this? Am I going to get fired? Am I going to get publicly shamed for the decisions that I made when I was in this situation?

+ +

And what that response, that reaction does is it drives a lot of the communication and a lot of the understanding of the conditions that that person was in. It drives that underground. And it's important to allow people to talk about here's what I was seeing, here's what I was experiencing because, in these kinds of complex systems, information is not readily available to people. The signals are not always coming through loud and clear about what's going on or about what the appropriate actions to take are. Instead, it's messy; it's loud, it's noisy.

+ +

There are usually multiple different demands on that person's attention and on their time, and they're often managing trade-offs: do I keep the system down so that I can gather more information about what's actually going on, or do I just try and bring it up as quickly as I can so that there's less impact to users? Those kinds of decisions are having to be made under pressure. So when we create these conditions of psychological safety, when we say you know what? This happened. We want to learn from it. We've already made this investment.

+ +

Richard Cook mentioned in the very first SNAFU Catchers Report, which was a report that came out of Ohio State, that incidents are unplanned investments into understanding how your system works. And so you've already had the incident. You've already paid the price of that downtime or of that outage. So you might as well extract some learning from it so that you can help create a safer and more resilient system in the future.

+ +

So by helping people to reconstruct what was actually happening in real-time, not what they were retrospectively saying, "Oh, I should have done this," well, you didn't do that. So let's understand why you thought at that moment in time that was the right way to respond because, more than likely, other people in that same position would have made that same choice. And so it helps us to think more broadly about ways that we can support decision-making and sense-making under conditions of stress and uncertainty. And ultimately, that helps your system be more resilient and be more reliable for your customers.

+ +

VICTORIA: What a great reframing: unplanned investment. [laughs] And if you don't learn from it, then you're going to lose out on what you've already invested that time in resolving it, right?

+ +

LAURA: Absolutely.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: Getting more into that psychological safety and how to create that culture where people feel safe telling about what really happened, but how does that relate to...Jeli says that they are a people software. [laughs] Talk to me more about that. Like, what advice do you give founders and CEOs on how to create that psychological safety which makes them be more resilient in these types of incidents?

+ +

LAURA: So you mentioned the Howie Guide that we published last year, and this is our guidance around how to do incident analysis, how to help your team start to learn from their incidents, and Howie stands for how we got here. And that's really important, that language because what it says is there's a history that led up to this incident. And most teams, when they've had an outage, they'll kind of look backwards from that outage, maybe an hour, maybe a day, maybe to the last deploy.

+ +

But they don't think about how the decisions got made to use that piece of software in the first place. They don't think about how did engineers actually get on-boarded to being on-call. They don't necessarily think about what kinds of skills, and knowledge, and expertise when we're hiring a DevOps engineer, and I'm using air quotes here or an SRE. What kinds of skills and knowledge do they actually have? Those are very broad terms. And what it means to be a DevOps engineer or an SRE is quite underspecified.

+ +

And so the knowledge behind the folks that you might hire into the company is going to necessarily be very diverse. It's going to be partial and incomplete in many ways because not everyone can know everything about the system. And so, we need to have multiple diverse perspectives about how the system works, how our customers use that system, what kinds of pressures and constraints exist within our company that allow us some possibilities over others. We need to bring all of those perspectives together to get a more reflective picture of what was actually happening before this incident took place and how we actually got here.

+ +

This reframing helps a lot of people disarm that initial defensiveness response or that initial, oh, shoot; I'm going to get in trouble for this kind of response. And it says to them, "Hey, you're a part of this bigger system of work. You are only one piece of this puzzle. And what we want to try and do is understand what was happening within the company, not just what you did, what you said, and what you decided."

+ +

So once people realize that you're not just trying to find fault or place blame, but you're really trying to understand their work, and you're trying to understand their work with other teams and other vendors, and trying to understand their work relative to the competing demands that were going on, so those are some of the things that help create psychological safety.

+ +

About ten years ago, John Allspaw and the team at Etsy put out The Etsy Debriefing Facilitation Guide, which also poses a number of questions and helps to frame the post-incident learnings in a way that moves it from the individual and looks more collectively at the company as a whole. And so these things are helpful for founders or for CEOs to help bring forward more information about what's really going on, more information about what are the real risks and threats and opportunities within the company, and gives you an opportunity to step back and do what we call microlearning, which is sharing knowledge about how the system works, sharing understandings of what people think is going on, and what people know about the system.

+ +

We don't typically talk about those things unless there's a reason to, and incidents kind of give us that reason because they're uncomfortable and they can be painful. They can be very public. They can be very disruptive to what we think about how resilient and reliable we actually are. And so if you can kind of step away from this defensiveness and step away from this need to place blame and instead try and understand the conditions, you will get a lot more learning and a lot more resilience and reliability out of your teams and out of your systems.

+ +

VICTORIA: That makes sense to me. And I'd like to draw a connection between that and some other things you mentioned with The 2022 Accelerate State of DevOps Report that highlights that the people who are often responding to those incidents or in that high-stress situation tend to be historically underrepresented or historically excluded groups. And so do you see that having this insight into both who is actually taking on a lot of the work when these incidents happen and creating that psychological safety can make a better environment for diversity, equity, inclusion at a company as well?

+ +

LAURA: Well, I think anytime you work to establish trust and transparency, and you focus on recognizing the skills that people do have, the knowledge that they do have, and not over assuming that someone knows something or that they have been involved in the discussions that may have been relevant to an incident, anytime you focus on that trust and transparency you are really signaling to people within your organization that you value their contributions and that you recognize that they've come to work and trying to do a good job. But they have multiple competing demands on their attention and on their time.

+ +

And so we're not making assumptions about people being complacent, or people being reckless or being sloppy in their work. So that creates an environment where people feel more willing to speak up and to talk about some of the challenges that they might face, to talk about the ways in which it's not clear to them how certain parts of the system work or how certain teams actually operate.

+ +

So you're just opening the channels for communication, which helps to share more knowledge. It helps to share more information about what teams are doing at different points in time. And this helps people to preemptively anticipate how a change that they might be making in their part of the system could be influencing up or downstream teams. And so this helps create more resilience because now you're thinking laterally about your system and about your involvement across teams and across boundary lines.

+ +

And an example of this is if a marketing team...this is a story that Nora tells quite a bit; if a marketing team is, say, launching a Super Bowl commercial for their company but they don't actually tell the engineers on-call that that is about to happen, you can create all sorts of breakdowns when all of a sudden you have this surge of traffic to your website because people see the Super Bowl commercial and they want to go to the site. And then you have a single person who's trying to respond to that in real-time.

+ +

So, instead, when you do start thinking about that trust and transparency, you're helping teams to help each other and to think more broadly about how their work is actually impacting other parts of the system. So from a diversity and inclusion and underrepresented groups perspective, this is creating the conditions for more people to be involved, more people to feel like their voice is going to be heard, and that their perspective actually matters.

+ +

VICTORIA: That sounds really powerful, and I'm glad we were able to touch on that. Shifting gears a little bit, I wanted to talk about two different questions; so one is if you could travel back in time to when Jeli first started, what advice would you give yourself, your past self?

+ +

LAURA: I would encourage myself to recognize that our ability to experiment is fundamental to our ability to learn. And learning is what helps us to iterate faster. Learning is what helps us to reflect on the tool that we're building or the feature that we're building and what this actually means to our users. I actually copped that advice to myself from CEO Zoran Perkov of the Long-Term Stock Exchange. They launched a whole new stock market during the pandemic with a fully remote team.

+ +

And I had interviewed him for an article that I wrote about resilient leadership. And he said to me, like, "My job as a CEO is 100% about protecting our ability to experiment as a company because if we stop learning, we're not going to be able to iterate. We're not going to be able to adapt to the changes that we see in the market and in our users." So I think I would tell myself to continually experiment.

+ +

One of the things that I talk to our customers about a lot because many of them are implementing new incident management programs or they're trying to level up their engineering teams around incident analysis, and I would say, "This doesn't have to be a fully-fleshed out program where you know all of the ways in which this is going to unfold." It's really about trying experiments, conduct some training, start small. Do one incident analysis on a really particularly spicy incident that you may have had or a really challenging incident where a lot of people were surprised by what happened.

+ +

Bring together that group and say, "Hey, we're going to try something a little bit different here. We'll use some questions from the Howie Guide. We'll use the format and the structure from the Etsy Debriefing Guide. And we're just going to try and learn what we can about this event. We're not going to try and place blame. We're not going to try and generate corrective actions. We just want to see what we can learn from this." Then ask people that were involved, "How did this go? What did we learn from it? What should we do differently next time?"

+ +

And continually iterate on those small, little experiments so that you can grow your product and grow your team's capacity. I think it took us a little bit of time to figure that out within the organization, but once we did, we were just able to collaborate more effectively work more effectively by integrating some of the feedback that we were getting from our users.

+ +

And then the last piece of advice that I would give myself is to really invest in cross-discipline coordination and collaboration. Engineers, designers, researchers, CEOs they all have a different view of the product. They all have a different understanding of what the goals and priorities are. And those mental models of the product and of what the right thing to do is are constantly changing. And they all have different language that they use to talk about the product and to talk about their processes for integrating this understanding of the changing conditions and the changing user into the product.

+ +

And so I would say invest in establishing common ground across the different disciplines within your team to be able to talk about what people are seeing, to be able to stop and identify when we're making assumptions about what other people know or what other people's orientation towards the problem or towards the product are. And spend a little bit of time saying, "When I say this is important, I'm saying it's important because of XYZ, not just this is important." So spending a little bit of time elaborating on what your mental model is and where you're drawing from can help the teams work more effectively together across those disciplines.

+ +

VICTORIA: That's pretty powerful advice. You're iterating and experimenting at Jeli. What's on the horizon that you are...what new experiments are you excited about?

+ +

LAURA: One of the things that has been front and center for us since we started is this idea of cross-incident analysis. And so we've kind of built out a number of different features within the product, being able to help tag the incident with the relevant services and technologies that were involved, being able to identify which teams were involved, and also being able to identify different kinds of themes or patterns that emerge from individual incidents.

+ +

So all of this data that we can get from mostly just from the ingested incident itself or from the incident that you bring into Jeli but also from the analysis that you do on it this helps us start to be able to see across incidents what's happening not just with the technical side of things. So is it always Travis that is causing a problem? Are there components that work together that kind of have these really hidden and strange interdependencies that are really hard for the team to actually cope with? What kinds of themes are emerging across your suite of opportunities, your suite of incidents that you've ingested?

+ +

Some of the things that we're starting to see from those experiments is an ability to look at where are your knowledge islands within your organization? Do you have an engineer who, if they were to leave, would take the majority of your systems knowledge about your database, or about your users, or about some critical aspect of your system that would disappear with all of that tacit knowledge? Or are there engineers that work really effectively together during really difficult incidents?

+ +

And so you can start to unpack what are these characteristics of these people, and of these teams, and of these technologies that offer both opportunities or threats to your organization? So basically, what we're doing is we're helping you to see how your system performs under different kinds of conditions, which I think as a safety and risk professional working in a variety of different domains for the last 15 years, I think this is really where the rubber hits the road in helping teams be more reliable, and be more resilient, and more proactive about where investments in maintenance, or training, or headcount are going to have the biggest bang for your buck.

+ +

VICTORIA: That makes a lot of sense. In my experience, sometimes those decisions are made more on intuition or on limited data so having a more full picture to rely on probably produces better results. [laughs]

+ +

LAURA: Yeah, and I think that we all want to be data-driven, thinking about not only the quantitative data is how many incidents do we have around certain parts of the system, or certain teams, or certain services? But also, the qualitative side of things is what does this actually mean? And what does this mean to our ability to grow and change over time and to scale? The partnership of that quantitative data and qualitative data means we're being data-driven on a whole other level.

+ +

VICTORIA: Wonderful. And it seems like we're getting close to the end of our time here. Is there anything else you want to give as a final takeaway to our listeners?

+ +

LAURA: Yeah. So I think that we are, you know, as a domain, as a field, software engineering is increasingly becoming responsible for not only critical infrastructure within society, but we have a responsibility to our users and to each other within our companies to help make work better, help make our services more reliable and more resilient over time.

+ +

And there's a variety of lessons that we can learn from other domains. As I mentioned before, aviation, healthcare, nuclear power all of those kinds of domains have been thinking about supporting cognitive work and supporting frontline operators. And we can learn from this history and this literature that exists out there.

+ +

There is a GitHub repo that Lorin Hochstein has curated with a number of other folks with the industry that points to some of these resources. And as well, we'll be hosting the first Learning From Incidents in Software Engineering Conference in Denver in February, February 15 and 16th. And one feature of this conference that I'm super excited about is affectionately called CasesConf. And it is going to be an opportunity for software engineers from a variety of organizations to tell real stories about incidents that they had, how they handled them, what was challenging, what went surprisingly well, and just what is actually going on within their organizations.

+ +

And this is kind of a new thing for the software industry to be talking very publicly about failures and sharing the messy details of our incidents. This won't be a recorded part of the conference. It is going to be conducted under the Chatham House Rule, which is participants who are in the room while these stories are being told can share some of the stories but not any identifying details about the company or the engineers that were involved.

+ +

And so this kind of real-world situations helps us to, as I talked about before, with that psychological safety, helps us to say this is the reality of operating complex systems. They're going to fail. We're going to have to learn from them. And the more that we can talk at an industry level about what's going on and about what kinds of things are creating problems or opportunities for each other, the more we're going to be able to lift the bar for the industry as a whole. So you can check out register.learningfromincidents.io for more information about the conference. And we can link Lorin's resilience engineering GitHub repo in the notes as well.

+ +

VICTORIA: Wonderful. Well, I was looking for an excuse to come to Denver in February anyways.

+ +

LAURA: We would love to have ya.

+ +

VICTORIA: Thank you. And thank you so much for taking time to share with us today, Laura.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Laura Maguire.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Laura Maguire is a Researcher at Jeli.io, the first dedicated incident analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems.

+ +

Victoria talks to Laura about incident management, giving companies a powerful tool to learn from their incidents, and what types of customers are ideal for taking on a platform like Jeli.io.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Laura Maguire, Researcher at Jeli, the first dedicated instant analysis platform that combines more comprehensive data to deliver more proactive solutions and identify problems. Laura, thank you for joining me.

+ +

LAURA: Thanks for having me, Victoria.

+ +

VICTORIA: This might be a very introductory level question but just right off the bat, what is an incident?

+ +

LAURA: What we find is a lot of companies define this very differently across the space, but typically, it's where they are seeing an impact, either a customer impact or a degradation of their service. This can be either formally, it kind of impacts their SLOs or their SLAs, or informally it's something that someone on the team notices or someone, you know, one of their users notice as being degraded performance or something not working as intended.

+ +

VICTORIA: Gotcha. From my background being in IT operations, I'm familiar with incidents, and it's been a practice in IT for a long time. But what brought you to be a part of building this platform and creating a product around incidents?

+ +

LAURA: I am a, let's say, recovering safety professional.

+ +

VICTORIA: [chuckles]

+ +

LAURA: I started my career in the safety and risk management realm within natural resource industries in the physical world. And so I worked with people who were at the sharp end in high-risk, high-consequence type work. And they were really navigating risk and navigating safety in the real world. And as I was working in this domain, I noticed that there was a delta between what was being said, created safety, and helped risk management and what I was actually seeing with the people that I was working with on the front lines.

+ +

And so I started to pull the thread on this, and I thought, is work as done really the same as work as written or work as prescribed? And what I found was a whole field of research, a whole field of practice around thinking about safety and risk management in the world of cognitive work. And so this is how people think about risk, how they manage risk, and how do they interpret change and events in the world around them.

+ +

And so as I started to do my master's degree in human factors and system safety and then later my Ph.D. in cognitive systems engineering, I realized that whether you are on the frontlines of a wildland fire or you're on the frontlines of responding to an incident in the software realm, the ways in which people detect, diagnose, and repair the issues that they're facing are quite similar in terms of the cognitive work.

+ +

And so when I was starting my Ph.D. work, I was working with Dr. David Woods at the Cognitive Systems Engineering Lab at The Ohio State University. And I came into it, and I was thinking I'm going to work with astronauts, or with fighter pilots, or emergency room doctors, these really exciting domains. And he was like, "We're going to have you work with software engineers."

+ +

And at first, I really failed to see the connection there, but as I started to learn more about site reliability engineering, about DevOps, about the continuous deployment, continuous integration world, I realized software engineers are really at the forefront of managing critical digital infrastructure. They're keeping up the systems that run society, both for recreation and pleasure in the sense of Netflix, for example, as well as the critical functions within society like our 911 call routing systems, our financial markets.

+ +

And so the ability to study how software engineers detect outages, manage outages, and work together collaboratively across the team was really giving us a way to study this kind of work that could actually feed back into other types of domains like emergency response, like emergency rooms, and even back to the fighter pilots and astronauts.

+ +

VICTORIA: Wow, that's so interesting. And so is your research that went into your Ph.D. did that help you help define the product strategy and kind of market fit for what you've been building at Jeli?

+ +

LAURA: Yeah, absolutely. So Nora Jones, who is the founder and CEO of Jeli, reached out to me at a conference and told me a little bit about what she was thinking about, about how she wanted to support software engineers using a lot of this literature and a lot of the learnings from these other domains to build this product to help support incident management in software engineering.

+ +

So we base a lot of our thinking around how to help support this cognitive work and how to help resilient performance in these very dynamic, these very changing large scale, you know, distributed software systems on this research, as well as the research that we do with our own users and with our own members from learning from incidents in software engineering Slack community that Nora and several other fairly prominent names within the software community started, Lorin Hochstein, John Allspaw Dr. Richard Cook, Jessica DeVita, Ryan Kitchens, and I may be missing someone else but...and myself, oh, Will Galego as well.

+ +

Yeah, we based a lot of our understandings, really deep qualitative understandings of what is work like for software engineers when they're, you know, in continuous deployment type environments. And we've translated this into building a product that we think helps but not hinders by getting in the way of engineers while they're under time pressure and there's a lot of uncertainty. And there's often quite a bit of stress involved with responding to incidents.

+ +

VICTORIA: Right. And you mentioned resilience engineering. And for those who don't know, David Woods, who you worked on with your Ph.D., wrote "Resilience Engineering: Concepts and Precepts." So maybe you could talk a little bit about resilience engineering and what that really means, not just in technology but in the people who were running the tools, right?

+ +

LAURA: Yeah. So resilience engineering is different from how we think about protecting and defending our software systems. And it's different in the sense that we aren't just thinking about how do we prevent incidents from happening again, like, how do we fix things that have happened to us in the past? But how do we better understand the ways in which our systems operate under a wide variety of conditions? So that includes normal operating conditions as well as abnormal or anomalous operating conditions, such as an incident response.

+ +

And so resilience engineering was kind of this way of thinking differently about predicting failure, about managing failure, and navigating these kinds of worlds. And one of the fundamental differences about it is it sees people as being the most adaptive component within the system of work. So we can have really good processes and practices around deploying code; we can institute things like cross-checking and peer review of code; we can have really good robust backup and failover systems, but ultimately, it's very likely that in these kinds of complex and adaptive always-changing systems that you're going to encounter problems that you weren't able to anticipate.

+ +

And so this is where the resilience part comes in because if you're faced with a novel problem, if you're faced with an issue you've never seen before, or a hidden dependency within your system, or an unanticipated failure mode, you have to adapt. You have to be able to take all of the information that's available to you in the moment. You have to interpret that in real-time. You have to think of who else might have skills, knowledge, expertise, access to information, or access to certain kinds of systems or software components. And you have to bring all of those people together in real-time to be able to manage the problem at hand.

+ +

And so this is really quite a different way of thinking about supporting this work than just let's keep the runbooks updated, and let's make sure that we can write prescriptive processes for everything that we're going to encounter. Because this really is the difference that I saw when I was talking about earlier about that work is done versus work is prescribed. The rules don't cover all of the situations. And so you have to think of how do you help people adapt? How do you help people access information in real-time to be able to handle unforeseen failures?

+ +

VICTORIA: Right. That makes a lot of sense. It's an interesting evolution of site reliability engineering where you're thinking about the users' experience of your site. It's also thinking about the people who are running your site and what their experience is, and what freedom they have to be able to solve the problems that you wouldn't be able to predict, right?

+ +

LAURA: Yeah, it's a really good point, actually, because there is sort of this double layer in the product that we are building. So, as you mentioned earlier, we are an incident analysis platform, and so what does that mean? Well, it means that we pull in data whenever there's been an incident, and we help you to look at it a little bit more deeply than you may if you're just following a template and sort of reconstructing a timeline.

+ +

And so we pull in the actual Slack data that, you know, say, an ops channel or an incident channel that's been spun up following a report of a degraded performance or of an outage. And we look very closely at how did people talk to one another? Who did they bring into the incident? What kinds of things did they think were relevant and important at different points in time? And in doing this, it helps us to understand what information was available to people at different points in time.

+ +

Because after the incident and after it's been resolved, people often look back and say, "Oh, there's nothing we can learn from that. We figured out what it was." But if we go back and we start looking at how people detected it, how they diagnosed it, who they brought into the event, we can start to unpack these patterns and these ways of understanding how do people work together? What information is useful at different points in time? Which helps us get a deeper understanding of how our systems actually work and how they actually fail.

+ +

VICTORIA: Right. And I see there are a few different ways the platform does that: there's a narrative builder, a people view, and also a visual timeline. So, do you find that combining all those things together really gives companies a powerful tool to learn from their incidents?

+ +

LAURA: Yeah. So let me talk a little bit about each of those different components. Our MVP of the product we started out with this understanding of the incident analyst and the incident investigator who, you know, was ready to dive in and ready to understand their incident and apply some qualitative analysis techniques to thinking about their incidents. And what we found was there are a number of these people who are really interested in this deep dive within the software industry. But there's a broader subset of folks that they work with who maybe only do these kinds of incident analysis every once in a while, and they're not as interested in going quite as deep.

+ +

And so the narrative builder is really this kind of bridge between those two types of users. And what it does is helps construct a timeline which is typically what most companies do to help drive the discussion that they might have in a post-mortem or to drive their kind of findings in their summary report. And it helps them take this closer look at the interactions that happened in that slack transcript and raise questions about what kinds of uncertainties there were, point out who was involved, or interesting aspects of the event at that point in time.

+ +

And it helps them to summarize what was happening. What did people think was happening at this point in time to create this story about the incident? And the story element is really important because we all learn from stories. It helps bring to life some of the details about what was hard, who was involved, how did they get brought in, what the sources of technical failure were, and whether those were easy or difficult to understand and to repair once the source of the failure was actually understood. And so that narrative builder helps reconstruct this timeline in a much richer way but also do it very efficiently.

+ +

And as you mentioned, the visual timeline is something that we've created to help that lightweight user or that every once in a while user to go a little bit deeper on their analysis. And how we do that is because it lays out the progression of the event in a way that helps you see, oh, this maybe wasn't straightforward. We didn't detect it in the beginning, and then diagnose it, and then repair it at the end. What happened actually was the detection was intermittent. The signals about what was going wrong was intermittent, and so that was going on in parallel with the diagnosis. The diagnosis took a really long time, and that may have been because we can also see the repair was happening concurrently.

+ +

And so it starts to show these kinds of characteristics about whether the incident was difficult, whether it was challenging and hard, or whether it was simple and straightforward. This helps lend a bit more depth to metrics like MTTR and TTD by saying, oh, there was a lot more going on in this incident than we initially thought.

+ +

The last thing that you mentioned was the people view, and so that really sets our product apart from other products in that we look at the sociotechnical system. So it's not just about the software that broke; it is about who was involved in managing that system, in repairing that system, and in communicating about that system outwardly. And so the people view this kind of pulls in some HR data. It helps us to understand who was involved. How long have they been in their role? Were they on-call? Were they not on-call? And other kinds of irrelevant details that show us what was their engagement or their interaction with this event.

+ +

And so when we start to bring in the socio part of the sociotechnical system, we can identify things like what knowledge do we have within the organization? Is that knowledge well-distributed, or is it just isolated in one or two people? And so those people are constantly getting pulled into incidents when they may be not on-call, which can start to show us whether or not these folks are in danger of burning out or whether their knowledge might need to be transferred more broadly throughout the organization.

+ +

So this is kind of where the resilience piece comes in because it helps us to distribute knowledge. It helps us to identify who is relevant and useful and how do they partner and collaborate with other people, and their knowledge and skill sets to be able to manage some of the outages that they face?

+ +

VICTORIA: That's wonderful because one of my follow-up questions would be, as a CEO, as a founder, what kind of insights or choices do you get to make now that you have this insight to help make your team more resilient? [laughs]

+ +

LAURA: So if this is a manager, or a founder, or a CEO that is looking at their data in Jeli, they can start to understand how to resource their teams more appropriately, as I mentioned, how to spread that knowledge around. They can start to see what parts of their system are creating the most problems or what parts of their system do they have maybe less insight into how it works, how it interacts with other parts of the system, and what this actually means for their ability to meet their SLOs or their SLAs. So it gives you a more in-depth understanding of how your business is actually operating on both the technical side of things, as well as on the people side of things.

+ +

VICTORIA: That makes a lot of sense. Thank you for that overview of the platform. There's the incident analysis platform, and you also have the bot, the response chatbot. Can you tell me a little bit more about that?

+ +

LAURA: Yeah, absolutely. We think that incident management should be conducted wherever your work actually takes place, and so for most of our customers and a lot of folks that we know about in the industry, that's Slack. And so, if you are communicating in real-time with your team in Slack, we think that you should stay there.

+ +

And so, we built this incident management bot that is free and will be free for the lifetime of the product. Because we think that this is really the fundamental basis for helping you manage your incidents more efficiently and more effectively. So it's a pretty lightweight bot. It gives kind of some guardrails or some guidance around collaboration by spinning up a new incident channel, helping you to bring the right kinds of responders into that, helping you to communicate to interested stakeholders by broadcasting to channels they might be in.

+ +

It kind of nudges you to think about how to communicate about what's happening during different stages of the event progression. And so it's prompting you in a very lightweight way; hey, do you have a status update? Do you have a summary of what the current thinking is? What are the hypotheses about what's going on? Who's conducting what kinds of activities right now? So that if I'm a responder that's coming into the event after 20-30 minutes after it started, I can very quickly come up to speed, understand what's going on, who's doing what, and figure out what's useful for me to do to help step in and not disrupt the incident management that's underway right now.

+ +

Our users can choose to use the bot independently of the incident analysis platform. But of course, being able to ingest that incident into Jeli it helps you understand who's been involved in the incident, if they've been involved in similar incidents in the past, and helps them start to see some patterns and some themes that emerge over time when you start to look at incidents across the organization.

+ +

VICTORIA: That makes sense. And I love that it's free and that there's something for every type of organization to take advantage of there. And I wonder if at Jeli you have data about what type of customer is it who'd be targeted or really ideal to take on this kind of platform.

+ +

LAURA: So most organizations...I was actually recently at SREcon EMEA, and there was a really interesting series of talks; one was SRE for Enterprise, and the next talk was SRE for Startups. And so it was a very thought-provoking discussion around is SRE for everyone, so site reliability engineering? Even smaller teams are starting to have to be responsible for reliability and responsible for running their service.

+ +

And so we kind of have built our platform thinking about how do we help not just big enterprises or organizations that may have dedicated teams for this but also small startups to learn from their incidents. So internally, we actually call incidents opportunities as in they are learning opportunities for checking out how does your system actually work? How do your people work together? What things were difficult and challenging about the incident? And how do you talk about those things as a team to help create more resilient performance in future?

+ +

So in terms of an ideal customer, it's really folks that are interested in conducting these sort of lightweight but in-depth looks at how their system actually works on both the people side of things and the technical side of things. Those who we found are most successful with our product are interested in not so much figuring out who did the thing and who can they blame for the incident itself but rather how do they learn from what happened?

+ +

And would another engineer, or another product owner, another customer service representative, whoever the incident may be sort of focused around, would another person in their shoes have taken the same actions that they took or made the same decisions that they made? Which helps us understand from a systems level how do we repair or how do we adjust the system of work surrounding folks so that they are better supported when they're faced with uncertainty, or with that kind of time pressure, or that ambiguity about what's actually going on?

+ +

VICTORIA: And I love that you said that because part of the reason [laughs] I invited you on to the podcast is that a lot of companies I have experience with don't think about incidents until it happens to them, and then it can be a scramble. It can impact their customer base. It can stress their team out. But if you go about creating...the term obviously you all use is psychological safety on your team, and maybe you use some of the free tools from Jeli like the Post-Incident Guide and the Incident Analysis 101 blog to set your team up for success from the beginning, then you can increase your customer loyalty and your team loyalty as well to the company. Is that your experience?

+ +

LAURA: Yeah, absolutely. So one thing that I have learned throughout my career, you know, starting way back in forestry and looking at safety and risk in that domain, was as soon as there is an accident or even a serious near miss, right away, everybody gets sweaty palms. Everybody is concerned about, uh-oh, am I going to get blamed for this? Am I going to get fired? Am I going to get publicly shamed for the decisions that I made when I was in this situation?

+ +

And what that response, that reaction does is it drives a lot of the communication and a lot of the understanding of the conditions that that person was in. It drives that underground. And it's important to allow people to talk about here's what I was seeing, here's what I was experiencing because, in these kinds of complex systems, information is not readily available to people. The signals are not always coming through loud and clear about what's going on or about what the appropriate actions to take are. Instead, it's messy; it's loud, it's noisy.

+ +

There are usually multiple different demands on that person's attention and on their time, and they're often managing trade-offs: do I keep the system down so that I can gather more information about what's actually going on, or do I just try and bring it up as quickly as I can so that there's less impact to users? Those kinds of decisions are having to be made under pressure. So when we create these conditions of psychological safety, when we say you know what? This happened. We want to learn from it. We've already made this investment.

+ +

Richard Cook mentioned in the very first SNAFU Catchers Report, which was a report that came out of Ohio State, that incidents are unplanned investments into understanding how your system works. And so you've already had the incident. You've already paid the price of that downtime or of that outage. So you might as well extract some learning from it so that you can help create a safer and more resilient system in the future.

+ +

So by helping people to reconstruct what was actually happening in real-time, not what they were retrospectively saying, "Oh, I should have done this," well, you didn't do that. So let's understand why you thought at that moment in time that was the right way to respond because, more than likely, other people in that same position would have made that same choice. And so it helps us to think more broadly about ways that we can support decision-making and sense-making under conditions of stress and uncertainty. And ultimately, that helps your system be more resilient and be more reliable for your customers.

+ +

VICTORIA: What a great reframing: unplanned investment. [laughs] And if you don't learn from it, then you're going to lose out on what you've already invested that time in resolving it, right?

+ +

LAURA: Absolutely.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: Getting more into that psychological safety and how to create that culture where people feel safe telling about what really happened, but how does that relate to...Jeli says that they are a people software. [laughs] Talk to me more about that. Like, what advice do you give founders and CEOs on how to create that psychological safety which makes them be more resilient in these types of incidents?

+ +

LAURA: So you mentioned the Howie Guide that we published last year, and this is our guidance around how to do incident analysis, how to help your team start to learn from their incidents, and Howie stands for how we got here. And that's really important, that language because what it says is there's a history that led up to this incident. And most teams, when they've had an outage, they'll kind of look backwards from that outage, maybe an hour, maybe a day, maybe to the last deploy.

+ +

But they don't think about how the decisions got made to use that piece of software in the first place. They don't think about how did engineers actually get on-boarded to being on-call. They don't necessarily think about what kinds of skills, and knowledge, and expertise when we're hiring a DevOps engineer, and I'm using air quotes here or an SRE. What kinds of skills and knowledge do they actually have? Those are very broad terms. And what it means to be a DevOps engineer or an SRE is quite underspecified.

+ +

And so the knowledge behind the folks that you might hire into the company is going to necessarily be very diverse. It's going to be partial and incomplete in many ways because not everyone can know everything about the system. And so, we need to have multiple diverse perspectives about how the system works, how our customers use that system, what kinds of pressures and constraints exist within our company that allow us some possibilities over others. We need to bring all of those perspectives together to get a more reflective picture of what was actually happening before this incident took place and how we actually got here.

+ +

This reframing helps a lot of people disarm that initial defensiveness response or that initial, oh, shoot; I'm going to get in trouble for this kind of response. And it says to them, "Hey, you're a part of this bigger system of work. You are only one piece of this puzzle. And what we want to try and do is understand what was happening within the company, not just what you did, what you said, and what you decided."

+ +

So once people realize that you're not just trying to find fault or place blame, but you're really trying to understand their work, and you're trying to understand their work with other teams and other vendors, and trying to understand their work relative to the competing demands that were going on, so those are some of the things that help create psychological safety.

+ +

About ten years ago, John Allspaw and the team at Etsy put out The Etsy Debriefing Facilitation Guide, which also poses a number of questions and helps to frame the post-incident learnings in a way that moves it from the individual and looks more collectively at the company as a whole. And so these things are helpful for founders or for CEOs to help bring forward more information about what's really going on, more information about what are the real risks and threats and opportunities within the company, and gives you an opportunity to step back and do what we call microlearning, which is sharing knowledge about how the system works, sharing understandings of what people think is going on, and what people know about the system.

+ +

We don't typically talk about those things unless there's a reason to, and incidents kind of give us that reason because they're uncomfortable and they can be painful. They can be very public. They can be very disruptive to what we think about how resilient and reliable we actually are. And so if you can kind of step away from this defensiveness and step away from this need to place blame and instead try and understand the conditions, you will get a lot more learning and a lot more resilience and reliability out of your teams and out of your systems.

+ +

VICTORIA: That makes sense to me. And I'd like to draw a connection between that and some other things you mentioned with The 2022 Accelerate State of DevOps Report that highlights that the people who are often responding to those incidents or in that high-stress situation tend to be historically underrepresented or historically excluded groups. And so do you see that having this insight into both who is actually taking on a lot of the work when these incidents happen and creating that psychological safety can make a better environment for diversity, equity, inclusion at a company as well?

+ +

LAURA: Well, I think anytime you work to establish trust and transparency, and you focus on recognizing the skills that people do have, the knowledge that they do have, and not over assuming that someone knows something or that they have been involved in the discussions that may have been relevant to an incident, anytime you focus on that trust and transparency you are really signaling to people within your organization that you value their contributions and that you recognize that they've come to work and trying to do a good job. But they have multiple competing demands on their attention and on their time.

+ +

And so we're not making assumptions about people being complacent, or people being reckless or being sloppy in their work. So that creates an environment where people feel more willing to speak up and to talk about some of the challenges that they might face, to talk about the ways in which it's not clear to them how certain parts of the system work or how certain teams actually operate.

+ +

So you're just opening the channels for communication, which helps to share more knowledge. It helps to share more information about what teams are doing at different points in time. And this helps people to preemptively anticipate how a change that they might be making in their part of the system could be influencing up or downstream teams. And so this helps create more resilience because now you're thinking laterally about your system and about your involvement across teams and across boundary lines.

+ +

And an example of this is if a marketing team...this is a story that Nora tells quite a bit; if a marketing team is, say, launching a Super Bowl commercial for their company but they don't actually tell the engineers on-call that that is about to happen, you can create all sorts of breakdowns when all of a sudden you have this surge of traffic to your website because people see the Super Bowl commercial and they want to go to the site. And then you have a single person who's trying to respond to that in real-time.

+ +

So, instead, when you do start thinking about that trust and transparency, you're helping teams to help each other and to think more broadly about how their work is actually impacting other parts of the system. So from a diversity and inclusion and underrepresented groups perspective, this is creating the conditions for more people to be involved, more people to feel like their voice is going to be heard, and that their perspective actually matters.

+ +

VICTORIA: That sounds really powerful, and I'm glad we were able to touch on that. Shifting gears a little bit, I wanted to talk about two different questions; so one is if you could travel back in time to when Jeli first started, what advice would you give yourself, your past self?

+ +

LAURA: I would encourage myself to recognize that our ability to experiment is fundamental to our ability to learn. And learning is what helps us to iterate faster. Learning is what helps us to reflect on the tool that we're building or the feature that we're building and what this actually means to our users. I actually copped that advice to myself from CEO Zoran Perkov of the Long-Term Stock Exchange. They launched a whole new stock market during the pandemic with a fully remote team.

+ +

And I had interviewed him for an article that I wrote about resilient leadership. And he said to me, like, "My job as a CEO is 100% about protecting our ability to experiment as a company because if we stop learning, we're not going to be able to iterate. We're not going to be able to adapt to the changes that we see in the market and in our users." So I think I would tell myself to continually experiment.

+ +

One of the things that I talk to our customers about a lot because many of them are implementing new incident management programs or they're trying to level up their engineering teams around incident analysis, and I would say, "This doesn't have to be a fully-fleshed out program where you know all of the ways in which this is going to unfold." It's really about trying experiments, conduct some training, start small. Do one incident analysis on a really particularly spicy incident that you may have had or a really challenging incident where a lot of people were surprised by what happened.

+ +

Bring together that group and say, "Hey, we're going to try something a little bit different here. We'll use some questions from the Howie Guide. We'll use the format and the structure from the Etsy Debriefing Guide. And we're just going to try and learn what we can about this event. We're not going to try and place blame. We're not going to try and generate corrective actions. We just want to see what we can learn from this." Then ask people that were involved, "How did this go? What did we learn from it? What should we do differently next time?"

+ +

And continually iterate on those small, little experiments so that you can grow your product and grow your team's capacity. I think it took us a little bit of time to figure that out within the organization, but once we did, we were just able to collaborate more effectively work more effectively by integrating some of the feedback that we were getting from our users.

+ +

And then the last piece of advice that I would give myself is to really invest in cross-discipline coordination and collaboration. Engineers, designers, researchers, CEOs they all have a different view of the product. They all have a different understanding of what the goals and priorities are. And those mental models of the product and of what the right thing to do is are constantly changing. And they all have different language that they use to talk about the product and to talk about their processes for integrating this understanding of the changing conditions and the changing user into the product.

+ +

And so I would say invest in establishing common ground across the different disciplines within your team to be able to talk about what people are seeing, to be able to stop and identify when we're making assumptions about what other people know or what other people's orientation towards the problem or towards the product are. And spend a little bit of time saying, "When I say this is important, I'm saying it's important because of XYZ, not just this is important." So spending a little bit of time elaborating on what your mental model is and where you're drawing from can help the teams work more effectively together across those disciplines.

+ +

VICTORIA: That's pretty powerful advice. You're iterating and experimenting at Jeli. What's on the horizon that you are...what new experiments are you excited about?

+ +

LAURA: One of the things that has been front and center for us since we started is this idea of cross-incident analysis. And so we've kind of built out a number of different features within the product, being able to help tag the incident with the relevant services and technologies that were involved, being able to identify which teams were involved, and also being able to identify different kinds of themes or patterns that emerge from individual incidents.

+ +

So all of this data that we can get from mostly just from the ingested incident itself or from the incident that you bring into Jeli but also from the analysis that you do on it this helps us start to be able to see across incidents what's happening not just with the technical side of things. So is it always Travis that is causing a problem? Are there components that work together that kind of have these really hidden and strange interdependencies that are really hard for the team to actually cope with? What kinds of themes are emerging across your suite of opportunities, your suite of incidents that you've ingested?

+ +

Some of the things that we're starting to see from those experiments is an ability to look at where are your knowledge islands within your organization? Do you have an engineer who, if they were to leave, would take the majority of your systems knowledge about your database, or about your users, or about some critical aspect of your system that would disappear with all of that tacit knowledge? Or are there engineers that work really effectively together during really difficult incidents?

+ +

And so you can start to unpack what are these characteristics of these people, and of these teams, and of these technologies that offer both opportunities or threats to your organization? So basically, what we're doing is we're helping you to see how your system performs under different kinds of conditions, which I think as a safety and risk professional working in a variety of different domains for the last 15 years, I think this is really where the rubber hits the road in helping teams be more reliable, and be more resilient, and more proactive about where investments in maintenance, or training, or headcount are going to have the biggest bang for your buck.

+ +

VICTORIA: That makes a lot of sense. In my experience, sometimes those decisions are made more on intuition or on limited data so having a more full picture to rely on probably produces better results. [laughs]

+ +

LAURA: Yeah, and I think that we all want to be data-driven, thinking about not only the quantitative data is how many incidents do we have around certain parts of the system, or certain teams, or certain services? But also, the qualitative side of things is what does this actually mean? And what does this mean to our ability to grow and change over time and to scale? The partnership of that quantitative data and qualitative data means we're being data-driven on a whole other level.

+ +

VICTORIA: Wonderful. And it seems like we're getting close to the end of our time here. Is there anything else you want to give as a final takeaway to our listeners?

+ +

LAURA: Yeah. So I think that we are, you know, as a domain, as a field, software engineering is increasingly becoming responsible for not only critical infrastructure within society, but we have a responsibility to our users and to each other within our companies to help make work better, help make our services more reliable and more resilient over time.

+ +

And there's a variety of lessons that we can learn from other domains. As I mentioned before, aviation, healthcare, nuclear power all of those kinds of domains have been thinking about supporting cognitive work and supporting frontline operators. And we can learn from this history and this literature that exists out there.

+ +

There is a GitHub repo that Lorin Hochstein has curated with a number of other folks with the industry that points to some of these resources. And as well, we'll be hosting the first Learning From Incidents in Software Engineering Conference in Denver in February, February 15 and 16th. And one feature of this conference that I'm super excited about is affectionately called CasesConf. And it is going to be an opportunity for software engineers from a variety of organizations to tell real stories about incidents that they had, how they handled them, what was challenging, what went surprisingly well, and just what is actually going on within their organizations.

+ +

And this is kind of a new thing for the software industry to be talking very publicly about failures and sharing the messy details of our incidents. This won't be a recorded part of the conference. It is going to be conducted under the Chatham House Rule, which is participants who are in the room while these stories are being told can share some of the stories but not any identifying details about the company or the engineers that were involved.

+ +

And so this kind of real-world situations helps us to, as I talked about before, with that psychological safety, helps us to say this is the reality of operating complex systems. They're going to fail. We're going to have to learn from them. And the more that we can talk at an industry level about what's going on and about what kinds of things are creating problems or opportunities for each other, the more we're going to be able to lift the bar for the industry as a whole. So you can check out register.learningfromincidents.io for more information about the conference. And we can link Lorin's resilience engineering GitHub repo in the notes as well.

+ +

VICTORIA: Wonderful. Well, I was looking for an excuse to come to Denver in February anyways.

+ +

LAURA: We would love to have ya.

+ +

VICTORIA: Thank you. And thank you so much for taking time to share with us today, Laura.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Laura Maguire.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+t6DsUMpU + + ]]> + + Victoria Guido + Laura Maguire + + + 455: Hello Inside with Anne Latz + https://podcast.thoughtbot.com/455 + a7610941-b5d0-4d62-9e21-61b250f160ec + Thu, 29 Dec 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Dr. Anne Latz is Co-Founder and Chief Medical Officer at Hello Inside, a company that specializes in scientific self-care. + +Will talks to Dr. Latz about why glucose?, being a business-person first and what drove her to become a medical doctor, and where she sees wearable technology going in the in the next 5-10 years. + 32:19 + no + + + Dr. Anne Latz is Co-Founder and Chief Medical Officer at Hello Inside, a company that specializes in scientific self-care. +Will talks to Dr. Latz about why glucose?, being a business-person first and what drove her to become a medical doctor, and where she sees wearable technology going in the in the next 5-10 years. +Hello Inside (https://helloinside.com/) +Follow Hello Inside on Instagram (https://www.instagram.com/helloinsideofficial/) or LinkedIn (https://www.linkedin.com/company/helloinside/about/). +Follow Dr. Anne Latz on LinkedIn (https://www.linkedin.com/in/drannelatz/). Check out her Linktree (https://linktr.ee/anne.ella)! +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with us today is Dr. Anne Latz, Co-Founder and Chief Medical Officer at Hello Inside, a company that specializes in scientific self-care. Anne, thank you for joining us. +DR. LATZ: Thank you for hosting me today, Will. +WILL: Yeah, I'm excited to talk about Hello Inside. And let's start there; give us a quick summary about Hello Inside. +DR. LATZ: So we are a German-Austrian startup, so we are based all over Europe, actually, all over the world, I have to say. And we help people by means of technology to understand their bodies best so to really become an expert of their bodies. And the technology we use is not only a smartphone app that shows data but a sensor that's called continuous glucose monitoring sensor that's like a little window you put on your arm that shows you in real-time your glucose data. +And we at Hello Inside have then an app and the service around that that really helps you to understand your data and become an expert of your body because this data really gives you immediate feedback on what you do in the sense of eating, moving, but also how well you slept, how stressed you are. +WILL: Wow, that's really neat. You said you had the continuous glucose monitor. The body is so complex, and there are so many ways that you probably could measure activity of the body. Why the glucose portion? Why are you doing glucose? +DR. LATZ: I think that there are two, maybe even three, reasons to that. The first one is we do not have so many tools like biosensors or technology on the market, which enable us to give really continuous data on different biofluids or markers in the body. So the first one is just that the market here is quite mature because we usually know glucose from the context of diabetes patients, and the technology has been developed years and years ago for those people. And that's why we have really, really good technology, really good sensors, which have high accuracy. The prices get lower and lower, so more and more people can really access this technology. And we just know already a lot about glucose management. +The second is it's a super, super potent marker. So I'm a medical doctor from my background. And I do not know so many markers in the body; maybe it's the heart rate variability or pulse that give us really immediate feedback to so many lifestyle pillars. So I think eating is quite intuitive that it does something to our blood glucose, but also movement does, also sleep and stress. And all these pillars immediately affect us, and we often know that. But this marker really gives us a take on how we can really visualize in the moment and then create a change from that. +And the third is probably that it's just a really hot topic, the glucose monitoring, currently, and that's actually not a good thing. But we have really not only an obesity epidemic but really a metabolic health crisis. So a lot of people have problems with their glucose levels, not aware of it. A lot of people have, in general, problems with managing; yeah, I would say, their metabolism and have an energy crisis in their body. You could put it like that. +And that's why we are really interested in glucose because if you manage glucose in the sense that you stabilize it, you can really improve your health in the short term and how much energy you have, midterm in the sense of what your weight is, and of course, long term to prevent diseases like diabetes or heart disease. +WILL: Yeah, definitely. I think you're correct; you know, glucose is the one thing, especially for me, it's diabetes, and I know it in that direction. But also that after lunch drag that you hit, the wall that you hit whenever your glucose spikes and then it comes down and spikes, I mean, then crashes. I think that's the other direction people understand glucose from. +DR. LATZ: Yeah, for sure. I mean, you bring up a great example, like the food coma after lunch. Everybody knows that, like, this energy and fatigue in the afternoon. But, I mean, you seem to be a little bit familiar with the technology, but a lot of people do not even connect the dots. They cannot really bring together what they eat and their behavior, for example, at lunchtime, how it really impacts them hours later. +And what we love so much about the technology and what we can also use the Hello Inside servers a lot for is really to find out what you do, like, what you think is healthy often. A good example is a smoothie you drink that might spike your blood glucose, but you don't really understand it because you thought it was a healthy choice. So it gives me more nuance as to what is healthy for you because it's...and we didn't even stress that, but it's also highly personalized. So you and I would eat the same lunch, and we would react completely differently to it. +So there's so much actionable data from it; that's what we love. And yeah, it's a little bit like running a lab test every few minutes of the day [chuckles] and give you the responses really on your smartphone to your hand and also some alternatives of how to create change there. +WILL: Yeah, definitely. And I'm glad you brought that up because one of the questions I had for you is, with Hello Inside, how do you see it combating the bad advice around self-care and dieting when you're getting great scientific data? It's kind of hard to argue with the data and the numbers. +DR. LATZ: For sure, yeah. I mean, we all know health, wellness, lifestyle. It all gets very close together, which has good sides and bad sides. But of course, people are still so confused in what is really good for them and their bodies. Because healthy, yeah, it's not a very specific term, especially in, let's stay with the example of food, what you put in, and different diet regimes you have. We see that there's so much frustration also in the market because all these one-size-fits-all recommendations in diet regimes or fasting regimes do not work for all people. +And that's really why these personalized approaches, and as you say, data-driven approaches, are so crucial because then you really get power back in trusting your body and understanding how your personal health and well-being is really influenced. At the same time, it's super hard because some of these trends and fad diets have existed for a long time and have a huge community who really love them. But we see it really as a conversation, like a conversation we have with the users, but also a conversation that users have with their bodies. +Because we know that creating change, especially behavior change, is like the holy grail for all health and also weight management tools. But it's also something that just takes a little longer because you need some experimenting. You need to find out what really works for you. But I'm quite convinced that when you see the data that's based on your body, that's something that you do not forget. If you see the foods that really spike you, surprisingly, this is really powerful. +WILL: Yeah, definitely. And I can understand the benefit of it, especially, you know, you're working out two weeks, and your body really is not showing you any signs of change. But I can see how this could help in showing you the change, even if it's small, how you can say, hey, you're on the right track. +DR. LATZ: Exactly. Yeah, it's like these small nudges. I mean, it's a monitor that already shows you the shortcuts and the little tweaks you make. For a lot of people, I always say if you find one food, one spiking element in your day and change that for the rest of your life, that's so much. For a lot of people, it's already in the breakfast. They jump on the blood glucose rollercoaster in the morning because they eat maybe porridge without any added protein to it. So it is very carb heavy, and they think it's super healthy and drink the oat milk latte. +I mean, in general, there's nothing wrong with those foods, but you can combine them even better and add something to it and not really eliminate stuff but just add a nice mix of protein and fat to your carbs. And you will be so much fitter during the day. You will not have this huge spike putting you on the roller coaster in the morning. As we are very habitual people, I mean, people eat like 60 different foods per week, which is not a lot; once you find out what really works for you, that's super, super nice for the rest of your life. +WILL: Yeah, definitely. And to be honest, I have been guilty of, oh, I just ate a very healthy meal. And then I go back and look at the nutritional facts, and I was like, what did I just eat? Because this was not healthy. +DR. LATZ: Yeah, we should always learn and make mistakes and learn again. And it's like a jungle out there. I mean, health, in general, the healthcare market is quite complicated. And I think that doesn't only apply to Germany but definitely to where I'm based but also to the U.S. and all the different markets. And for food, it's the same; I mean, that's a little bit the enemy we all are trying to deal with because the food industry is so powerful. It has so much lobby. And you get so confusing information that this is really what we can use our tools now for to understand what really these, I would say, not always healthy but claimed healthy foods do to us. +WILL: So, I have a question around wearable technology. So the last couple of years, there's been a trend of wearable technologies, the Garmins, the Apple Watches. This takes it to the next level. This is way more accurate than any of the wearables. Do you see this as the future in the next 5 or 10 years? +DR. LATZ: Yeah, probably in the next 5 or 10 years, we will see even more to it in the sense of personalization. And also, I personally believe that we really have a toolbox here of different markers we use. Maybe some are still invasive, like the CGM you put on your arm that really measures the fluids invasively. But also, there will be an array of other things we can really include into our daily health checks. +But this is definitely the next level of, as you said, Garmin and all these tracking tools because now we not only track data and have data, but we make them so actionable because we really put them into an immediate setting. So we can really calculate them now. I'm currently wearing my sensor, and I can have a look at my phone after we've finished recording and see, okay, what happened just now in my body? How did I respond to the setting? Was I super stressed? How is my lunch (because here it is early afternoon) affecting our body? +We really had already the switch of not only measuring stuff but making it really approachable, actionable. And yeah, I think CGM will be one of the first tools where we can really make this approachable for the broad public; then, we will have a lot of different markers and sensors to look at. And in respect to glucose management, I really am looking forward to when we get the press announcement of some company that we can also non-invasively and continuously measure blood glucose, which is currently not feasible, and a lot of companies are working on it. So this would be very exciting in the next years. +WILL: That's exciting. And I love how complex the human body is. +DR. LATZ: Oh yeah. +WILL: Like you just said, "How stressed was I?" And you can get that from your glucose level. +DR. LATZ: Yeah, it's super complex, and it really takes the time to also figure out what...because just measuring data is not really exciting anymore. Then you have a lot of data, and then you're like, so what? So to really figure how interdependent these lifestyle pillars are of movement, sleep, food, et cetera, that really takes some time, but once you understand it, it makes so much sense. +For example, stress is like this fight or flight response we've all heard about, and of course, you need energy for it. And that's why your blood glucose might go up because your body gives you energy to, for example, run away, [chuckles] or be alert. And then always breaking down to why our body does things always helps me to also make sense of the data. +WILL: That's amazing. Really amazing. +MID-ROLL AD: +Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. +Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff. +WILL: So tell me what excites you about Hello Inside, the company. +DR. LATZ: I mean, we founded this company with a very clear vision that we really want to help people to become experts of their body and really learn their body's language because this is a quite messed up system. We do not really understand our bodies' signals in the daily life. For example, hunger or thirst, a lot of people cannot really tell what the body is talking to them, so we think it's a super emotional topic. +And especially the combination of these really approachable, emotional, real-life moments with newest tech is, I think, an amazing combination because we can reach people really where they are. We can give personalized insights of your personal body. This is also something that makes you so much more reliable and compliant in what you do. Then we can really display the data in a way that you can experientially learn from it. +To give you an example, in our Hello Inside app, one of the favorite features of mine is the experiment feature, so you would have a food event. Let's make it super simple, eat an apple and feel your body in the next two or three hours. So that's usually when we take into account the response to that food. And then you compare that to one factor you change, so you eat the apple with some nuts or nut butter. I would suggest to most people, but of course, it's hyper individual, and what extent it changes in the blood glucose response just because you included the nuts, which include fat and protein. +You can put these two graphs, these two blood glucose curves together, and you really see the gap between it just from including nuts in your diet. And this is this nice combination of visualization, data-driven insights, and also something where you, I mean, people love to take pictures of their food. And that's what you can usually do here. +WILL: Wow, that's amazing. You were talking about your story behind using Hello Inside, the CGM. Do you or any of your clients have any success stories that you would like to talk about? +DR. LATZ: Yeah, for sure. I mean, we are quite a young company. We launched only in June and are live now in seven European countries. And actually, I have some really, really cool stories. We launched with a very strong focus on women's health. So we have developed a program which is called Hello Hormones, which helps women along the cycle via the Hello Inside app. And this continuous glucose monitor really improves symptoms like PMS, which can be like bloating, pains, et cetera. +And a lot of women didn't really understand (And how would they?) that your body has a very variable response to foods depending on the menstrual cycle. To visualize that, a very simple example would be eat in the first half of your cycle, before your ovulation, a banana, and eat the banana in the second half of the cycle. And I can promise you; you will have a different response to it which is super physiological. It has to do with insulin sensitivity. But you cannot really make sense of that (You feel differently in the phases.) which you now can really do when you saw in the data, really compared it, that you have higher levels of blood glucose maybe in the second half. +And you can make small tweaks which help you then to really increase well-being also in the second phase of the cycle before you have your period, which can be by reducing inflammation by changing how you move during that time, et cetera. And this is what a lot of people, a lot of women, resonated with trying out the program. And then, of course, we have these super nice glucose hacks you might have heard about also, where some of my favorites are definitely also always connecting what you eat with movement, so moving your muscles after your meal. +And I would say daily, we have such a high blast of user-generated content because people try it out, try the hacks, and then share their blood glucose response with us on social media. And this is so crazy to see. Also, people who are really into their bodies say, "I have these aha moments all the time just because I now understood, okay, it makes sense to have this type of breakfast. It makes sense how I eat my carbs, in which order I eat my food." +We have next to the social media content also some coaching sections we offer for our clients where we also hear a lot of those stories that they're really often so, so surprised and so happy that they finally made sense of their body signals. +WILL: Yeah, that's amazing. I'm a science geek; I'm just going to say it. +DR. LATZ: [laughs] +WILL: So I love how you can run your own scientific hypothesis and stuff. Like, you eat a banana at this time, how did it affect me? Okay, at this time, let me eat another banana. I just love that aspect because I don't think we have anything accurate enough right now that I know of besides actual drawing your blood in the lab or something like that that can actually give you that type of information. +DR. LATZ: Yeah, and especially if you take a lab just like once a month or once a quarter, then it's also really like a snapshot of the situation and might even have depended on how much did you drink? How was the night before? Like, what did you eat? And put some markers even there. And now you really have the ability to make it, yeah, it's a little bit more playful. Because of course, we recommend experiments you can make, start with an apple, eat the chocolate, do the pasta versus the rice. +But then you can customize it because it doesn't make sense to do experiments and try stuff out that you would never do in your daily life. So we always recommend start from where you really are. Wear the sensor for two, three days, just observe, and then look at what you really think is the problem for you. For a lot of people, it's the afternoon fatigue. So what could be the labor here? Where can we make a small change? +And then you really, as you say, a little bit of research on your own body and experiment around and tweak here, tweak there and that's the nice part. Then you come to changes that you also stick with. This is what we have also seen on our team, which are like the early adopters, and we worked on it for over a year. We really see that we get better blood glucose response in the mornings. And we just changed a little bit what order we eat. +If we go for ice cream, we just do a walk with the ice cream and all these small things which are really feasible and very, very contrary to what we also have in the diet culture, a lot of restrictive things. You cannot do that; you shouldn't do that. I always say it's very positive psychology; add that, combine it here, do some habits tweaking here. And you can really include that in your life further on. +WILL: That's amazing. Let's transition and talk about the starting of Hello Inside. What's the story? How did...because I think it's you and three other founders. How did y'all come about starting Hello Inside? +DR. LATZ: We are actually from very, very different backgrounds, but we have had some friends in common and some contacts, and, I mean, as I said, I'm a medical doctor. I have a digital health background. So I worked in digital health and other startups for over three years. My other co-founder is very much into the product and growth marketing. He was with Runtastic, which is now part of Adidas. So he has a sports lifestyle background and also expertise for the product. +The other one is responsible for brand and community investor relations. He really built also his own companies before. And the fourth is the tech guy who also worked in a medical startup and had his own agencies. So really, as you see, different backgrounds but very nice combination because we bring a lot of skills together and combine them from very different angles, and yeah, this is also, I would say, our power, and of course, it's also at the same time a challenge because not everybody is familiar in the same depth with the topics. +But I think that's often the point with diverse teams that you just have to communicate well to help the other people understand where you're coming from. We have to remind him to make research very understandable and really also explain that the tempo there sometimes is a little bit different, whereas I learn so, so much on what it means to build a product really at a high speed, to really iterate here and there. +So when we met, of course, the idea was to do something really with impact, to do something in the healthcare space but not too far into med tech. And we're really, really focused on this preventative field. I mean, you always say there's no glory in prevention. Prevention is super unsexy [laughs] for the individual but also the society, and we really want to change that. +Of course, Hello Inside was not Hello Inside from the beginning on then we found the name. And we're super happy with the company name, with the case we can make with looking inside, et cetera. Yeah, we're very much looking forward to building an even bigger company in the next years. +WILL: That's amazing. Your background is the medical portion of it. And you have experience in patient care in private and public healthcare, so tell us more about that. Are you still practicing? And how did you get into becoming a medical doctor? What was that drive for you to become a medical doctor? +DR. LATZ: To be frank, I was a business person first. [chuckles] +WILL: Oh. +DR. LATZ: I did first business bachelor, but that was like, for me, ages ago; [laughs] it feels like it. And after I finished my bachelor's, I was like yeah, okay, I want to do something else and applied for medical school, which was never on my mind before. And that's how it all started. I also had the chance to do my master's in business at the same time. So I always was like very open to look left and right. +And then, I started working in patient care, just very classical, like in a university hospital in psychotherapy. And I loved it a lot. But also, I was missing something to bring in this more innovative, creative part of my interests. I had the chance in a startup to work at some time in the U.S. It's called AMBOSS. It's an ad-tech startup. That's where I came really in the startup field and understood from a very junior position more and more about what it means to build a company. +Then I worked, coming back to Germany, for the ministry actually a little bit in the field of public health and prevention for diabetes. So here you see also how it now very well fits with what we're doing now, but of course, I can only say that now looking back. And I got certified in nutritional lifestyle medicine. And this is also something that really fascinates me a lot, like how these pillars really affect our lives all day, every day. And we do not learn so much also medical school about it, and that's where I learned for myself that this is really why I want to double down on these topics. +And a little bit before the first pandemic wave started, I found my way into digital health for a startup, being one of the first employees there, and had two years then to really learn on the market, with the market what it means to create a digital health company, and did my postgraduate certificate in Harvard at that time. So I learned patient safety, quality, informatics, and leadership. +And all these puzzle pieces then really fit well together last year when I met my co-founders, and we really iterated the idea more to build a company that combines all that, like, digital health and health and prevention with also metabolic health and lifestyle medicine, and, of course, all the innovative things we didn't know that they exist before and we are now learning on the market with. So this is how it all happened to me, and looking back, it all makes sense. But of course, there were a lot of segues. There were a lot of decisions to make on that journey. +WILL: Yeah, which I'm glad you brought up the decisions. That was my next question. What have been some of the toughest times in the startup? And what have been some of the most exciting times in the startup? +DR. LATZ: Yeah, I mean, I would even broaden up a little bit because just this week, we will launch a book which is in German but will also be in English soon, which really is quite personal. I wrote it with two other doctors, which is called Beyond Bedside. You could translate it. So we are all medical doctors who left bedside and found some new pathways, and two of us also as entrepreneurs. +And we had a lot of those hard decisions to take. I think one of the biggest learnings is always...and I think that also applies well for the startups: what got you here won't get you there. So you need this willingness to unlearn. You need to really understand, okay, now I'm a medical doctor, and I learned a lot, but in the startup, I'm just one of many, and I need to learn from the others. And I need to be really, really humble about what I can and cannot do. +I think this is always a problem of running a company. You want to be speedy because that's why you're a startup, but you also, especially in the healthcare space, need to do everything properly. And you have to navigate between really having a high quality, having everything according to guidelines because you're always working with people. It's always something you really need to be responsible of. This is also something that we need a lot of patience for a lot of things. +But yeah, in general, I would say we did quite a good job as we are a remote-first company. So it was during the pandemic that we founded the company. We have people all over the world working for us. I mean, that's not really specific for our company. But from what I know from colleagues as well, you just need to communicate, and communicate, and overcommunicate in different time zones to really make everybody really aware of the vision, the mission, repeat it again. And strategic decisions need to be clear to everyone. +So we put a high effort also on building a nice company culture and working on our ideas together and also get some on-sites where everybody can meet up. And yeah, this is sometimes really hard when you're so in your daily struggle, and there's so much to do. But then we need to take a step back and really say, okay, we need to invest in building an even better team. +WILL: Yeah, definitely. Wow. Wow, wow, wow, that's amazing. You've done medical school. You've practiced, and you've founded. Those are hard. Let's just be honest; those are hard things that you have accomplished, so congratulations on that. +DR. LATZ: Thanks, Will. +WILL: What has been some of the best advice that you received to help you keep going when those things got hard? +DR. LATZ: Do not ask the people who are in the very classical fit for...let me give you an example; I would not ask my chief when I worked in a hospital if I should leave the hospital because people who have always done it like that they would never recommend you to drop out and do something new and be innovative, and maybe also a little bit braver. So maybe the good advice from it would be ask the right people, ask a lot of people. +And then, looking back, one thing I really learned myself is also it's really hard times you have, and sometimes it's really you're doubting yourself. You're really overwhelmed. There's a lot going on. Especially those times will be, looking back, the ones that can be your hero story. Those are the ones that make you an even better person in the sense of being a coach for others and also for yourself later on. So you really need those struggles to understand and carve out what really moves your heart and where you really want to be invested. And there's also, and this is probably also still hard for me, saying no to a lot of things. +WILL: Hmm, that's really good advice, yes. Especially because you have experience in so many different areas, you can quickly overwhelm yourself by saying, "Yes." So, wow, I really like that advice. So in closing, is there anything else that you would like to share with us or with the audience? +DR. LATZ: Maybe something that I observe, I mean, I don't know if it's in U.S. the same, but I could imagine it's like a trend that's going on. Everybody thinks he or she needs to be an entrepreneur, founder, like own something, be by yourself. It's just not for everyone. I think that's okay. And I think that it's great that it's not for everyone. We need all the diverse roles. We need all the diverse employees. And being something for the sake of just being it is not a good motivation. +I think that nobody should really try to force him or herself into a role just because he or she thinks it's cool. There are many things you can do in your life and that you really should trust your gut and be also really brutally honest to yourself. And, like, I just want to be really...now it sounds better to say, "I just want to be a doctor," that's great. We need doctors; we need teachers; we need employees. There are so many great jobs, and there are so many days where I wish exactly the same. +At the same time, entrepreneurship gives you so much freedom of thinking. You learn so much on the job from other people, from your whole team. So there are many roads in crazy town. [laughs] There are many roads in the world. And this is really something we need to be aware of, this exactly, that it is really, really cool that we can do so many things and have really diverse roles in our society. +WILL: I love that advice because I 100% agree with you. Because I think there are people that are CEOs and they love to get out in front of people and talk and sell the company. But then you have a CFO or a CEO that's like, I just want to run the day-to-day, the books, or whatever that is, that's what I'm great at. So I love that advice. +DR. LATZ: Yeah, exactly. +WILL: Wow. Anne, it's been amazing talking to you about Hello Inside and just getting to know your company and you better. Thank you so much for being on the podcast today. +DR. LATZ: Thank you for your great questions, Will. +WILL: I appreciate it. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Dr. Anne Latz is Co-Founder and Chief Medical Officer at Hello Inside, a company that specializes in scientific self-care.

+ +

Will talks to Dr. Latz about why glucose?, being a business-person first and what drove her to become a medical doctor, and where she sees wearable technology going in the in the next 5-10 years.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with us today is Dr. Anne Latz, Co-Founder and Chief Medical Officer at Hello Inside, a company that specializes in scientific self-care. Anne, thank you for joining us.

+ +

DR. LATZ: Thank you for hosting me today, Will.

+ +

WILL: Yeah, I'm excited to talk about Hello Inside. And let's start there; give us a quick summary about Hello Inside.

+ +

DR. LATZ: So we are a German-Austrian startup, so we are based all over Europe, actually, all over the world, I have to say. And we help people by means of technology to understand their bodies best so to really become an expert of their bodies. And the technology we use is not only a smartphone app that shows data but a sensor that's called continuous glucose monitoring sensor that's like a little window you put on your arm that shows you in real-time your glucose data.

+ +

And we at Hello Inside have then an app and the service around that that really helps you to understand your data and become an expert of your body because this data really gives you immediate feedback on what you do in the sense of eating, moving, but also how well you slept, how stressed you are.

+ +

WILL: Wow, that's really neat. You said you had the continuous glucose monitor. The body is so complex, and there are so many ways that you probably could measure activity of the body. Why the glucose portion? Why are you doing glucose?

+ +

DR. LATZ: I think that there are two, maybe even three, reasons to that. The first one is we do not have so many tools like biosensors or technology on the market, which enable us to give really continuous data on different biofluids or markers in the body. So the first one is just that the market here is quite mature because we usually know glucose from the context of diabetes patients, and the technology has been developed years and years ago for those people. And that's why we have really, really good technology, really good sensors, which have high accuracy. The prices get lower and lower, so more and more people can really access this technology. And we just know already a lot about glucose management.

+ +

The second is it's a super, super potent marker. So I'm a medical doctor from my background. And I do not know so many markers in the body; maybe it's the heart rate variability or pulse that give us really immediate feedback to so many lifestyle pillars. So I think eating is quite intuitive that it does something to our blood glucose, but also movement does, also sleep and stress. And all these pillars immediately affect us, and we often know that. But this marker really gives us a take on how we can really visualize in the moment and then create a change from that.

+ +

And the third is probably that it's just a really hot topic, the glucose monitoring, currently, and that's actually not a good thing. But we have really not only an obesity epidemic but really a metabolic health crisis. So a lot of people have problems with their glucose levels, not aware of it. A lot of people have, in general, problems with managing; yeah, I would say, their metabolism and have an energy crisis in their body. You could put it like that.

+ +

And that's why we are really interested in glucose because if you manage glucose in the sense that you stabilize it, you can really improve your health in the short term and how much energy you have, midterm in the sense of what your weight is, and of course, long term to prevent diseases like diabetes or heart disease.

+ +

WILL: Yeah, definitely. I think you're correct; you know, glucose is the one thing, especially for me, it's diabetes, and I know it in that direction. But also that after lunch drag that you hit, the wall that you hit whenever your glucose spikes and then it comes down and spikes, I mean, then crashes. I think that's the other direction people understand glucose from.

+ +

DR. LATZ: Yeah, for sure. I mean, you bring up a great example, like the food coma after lunch. Everybody knows that, like, this energy and fatigue in the afternoon. But, I mean, you seem to be a little bit familiar with the technology, but a lot of people do not even connect the dots. They cannot really bring together what they eat and their behavior, for example, at lunchtime, how it really impacts them hours later.

+ +

And what we love so much about the technology and what we can also use the Hello Inside servers a lot for is really to find out what you do, like, what you think is healthy often. A good example is a smoothie you drink that might spike your blood glucose, but you don't really understand it because you thought it was a healthy choice. So it gives me more nuance as to what is healthy for you because it's...and we didn't even stress that, but it's also highly personalized. So you and I would eat the same lunch, and we would react completely differently to it.

+ +

So there's so much actionable data from it; that's what we love. And yeah, it's a little bit like running a lab test every few minutes of the day [chuckles] and give you the responses really on your smartphone to your hand and also some alternatives of how to create change there.

+ +

WILL: Yeah, definitely. And I'm glad you brought that up because one of the questions I had for you is, with Hello Inside, how do you see it combating the bad advice around self-care and dieting when you're getting great scientific data? It's kind of hard to argue with the data and the numbers.

+ +

DR. LATZ: For sure, yeah. I mean, we all know health, wellness, lifestyle. It all gets very close together, which has good sides and bad sides. But of course, people are still so confused in what is really good for them and their bodies. Because healthy, yeah, it's not a very specific term, especially in, let's stay with the example of food, what you put in, and different diet regimes you have. We see that there's so much frustration also in the market because all these one-size-fits-all recommendations in diet regimes or fasting regimes do not work for all people.

+ +

And that's really why these personalized approaches, and as you say, data-driven approaches, are so crucial because then you really get power back in trusting your body and understanding how your personal health and well-being is really influenced. At the same time, it's super hard because some of these trends and fad diets have existed for a long time and have a huge community who really love them. But we see it really as a conversation, like a conversation we have with the users, but also a conversation that users have with their bodies.

+ +

Because we know that creating change, especially behavior change, is like the holy grail for all health and also weight management tools. But it's also something that just takes a little longer because you need some experimenting. You need to find out what really works for you. But I'm quite convinced that when you see the data that's based on your body, that's something that you do not forget. If you see the foods that really spike you, surprisingly, this is really powerful.

+ +

WILL: Yeah, definitely. And I can understand the benefit of it, especially, you know, you're working out two weeks, and your body really is not showing you any signs of change. But I can see how this could help in showing you the change, even if it's small, how you can say, hey, you're on the right track.

+ +

DR. LATZ: Exactly. Yeah, it's like these small nudges. I mean, it's a monitor that already shows you the shortcuts and the little tweaks you make. For a lot of people, I always say if you find one food, one spiking element in your day and change that for the rest of your life, that's so much. For a lot of people, it's already in the breakfast. They jump on the blood glucose rollercoaster in the morning because they eat maybe porridge without any added protein to it. So it is very carb heavy, and they think it's super healthy and drink the oat milk latte.

+ +

I mean, in general, there's nothing wrong with those foods, but you can combine them even better and add something to it and not really eliminate stuff but just add a nice mix of protein and fat to your carbs. And you will be so much fitter during the day. You will not have this huge spike putting you on the roller coaster in the morning. As we are very habitual people, I mean, people eat like 60 different foods per week, which is not a lot; once you find out what really works for you, that's super, super nice for the rest of your life.

+ +

WILL: Yeah, definitely. And to be honest, I have been guilty of, oh, I just ate a very healthy meal. And then I go back and look at the nutritional facts, and I was like, what did I just eat? Because this was not healthy.

+ +

DR. LATZ: Yeah, we should always learn and make mistakes and learn again. And it's like a jungle out there. I mean, health, in general, the healthcare market is quite complicated. And I think that doesn't only apply to Germany but definitely to where I'm based but also to the U.S. and all the different markets. And for food, it's the same; I mean, that's a little bit the enemy we all are trying to deal with because the food industry is so powerful. It has so much lobby. And you get so confusing information that this is really what we can use our tools now for to understand what really these, I would say, not always healthy but claimed healthy foods do to us.

+ +

WILL: So, I have a question around wearable technology. So the last couple of years, there's been a trend of wearable technologies, the Garmins, the Apple Watches. This takes it to the next level. This is way more accurate than any of the wearables. Do you see this as the future in the next 5 or 10 years?

+ +

DR. LATZ: Yeah, probably in the next 5 or 10 years, we will see even more to it in the sense of personalization. And also, I personally believe that we really have a toolbox here of different markers we use. Maybe some are still invasive, like the CGM you put on your arm that really measures the fluids invasively. But also, there will be an array of other things we can really include into our daily health checks.

+ +

But this is definitely the next level of, as you said, Garmin and all these tracking tools because now we not only track data and have data, but we make them so actionable because we really put them into an immediate setting. So we can really calculate them now. I'm currently wearing my sensor, and I can have a look at my phone after we've finished recording and see, okay, what happened just now in my body? How did I respond to the setting? Was I super stressed? How is my lunch (because here it is early afternoon) affecting our body?

+ +

We really had already the switch of not only measuring stuff but making it really approachable, actionable. And yeah, I think CGM will be one of the first tools where we can really make this approachable for the broad public; then, we will have a lot of different markers and sensors to look at. And in respect to glucose management, I really am looking forward to when we get the press announcement of some company that we can also non-invasively and continuously measure blood glucose, which is currently not feasible, and a lot of companies are working on it. So this would be very exciting in the next years.

+ +

WILL: That's exciting. And I love how complex the human body is.

+ +

DR. LATZ: Oh yeah.

+ +

WILL: Like you just said, "How stressed was I?" And you can get that from your glucose level.

+ +

DR. LATZ: Yeah, it's super complex, and it really takes the time to also figure out what...because just measuring data is not really exciting anymore. Then you have a lot of data, and then you're like, so what? So to really figure how interdependent these lifestyle pillars are of movement, sleep, food, et cetera, that really takes some time, but once you understand it, it makes so much sense.

+ +

For example, stress is like this fight or flight response we've all heard about, and of course, you need energy for it. And that's why your blood glucose might go up because your body gives you energy to, for example, run away, [chuckles] or be alert. And then always breaking down to why our body does things always helps me to also make sense of the data.

+ +

WILL: That's amazing. Really amazing.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff.

+ +

WILL: So tell me what excites you about Hello Inside, the company.

+ +

DR. LATZ: I mean, we founded this company with a very clear vision that we really want to help people to become experts of their body and really learn their body's language because this is a quite messed up system. We do not really understand our bodies' signals in the daily life. For example, hunger or thirst, a lot of people cannot really tell what the body is talking to them, so we think it's a super emotional topic.

+ +

And especially the combination of these really approachable, emotional, real-life moments with newest tech is, I think, an amazing combination because we can reach people really where they are. We can give personalized insights of your personal body. This is also something that makes you so much more reliable and compliant in what you do. Then we can really display the data in a way that you can experientially learn from it.

+ +

To give you an example, in our Hello Inside app, one of the favorite features of mine is the experiment feature, so you would have a food event. Let's make it super simple, eat an apple and feel your body in the next two or three hours. So that's usually when we take into account the response to that food. And then you compare that to one factor you change, so you eat the apple with some nuts or nut butter. I would suggest to most people, but of course, it's hyper individual, and what extent it changes in the blood glucose response just because you included the nuts, which include fat and protein.

+ +

You can put these two graphs, these two blood glucose curves together, and you really see the gap between it just from including nuts in your diet. And this is this nice combination of visualization, data-driven insights, and also something where you, I mean, people love to take pictures of their food. And that's what you can usually do here.

+ +

WILL: Wow, that's amazing. You were talking about your story behind using Hello Inside, the CGM. Do you or any of your clients have any success stories that you would like to talk about?

+ +

DR. LATZ: Yeah, for sure. I mean, we are quite a young company. We launched only in June and are live now in seven European countries. And actually, I have some really, really cool stories. We launched with a very strong focus on women's health. So we have developed a program which is called Hello Hormones, which helps women along the cycle via the Hello Inside app. And this continuous glucose monitor really improves symptoms like PMS, which can be like bloating, pains, et cetera.

+ +

And a lot of women didn't really understand (And how would they?) that your body has a very variable response to foods depending on the menstrual cycle. To visualize that, a very simple example would be eat in the first half of your cycle, before your ovulation, a banana, and eat the banana in the second half of the cycle. And I can promise you; you will have a different response to it which is super physiological. It has to do with insulin sensitivity. But you cannot really make sense of that (You feel differently in the phases.) which you now can really do when you saw in the data, really compared it, that you have higher levels of blood glucose maybe in the second half.

+ +

And you can make small tweaks which help you then to really increase well-being also in the second phase of the cycle before you have your period, which can be by reducing inflammation by changing how you move during that time, et cetera. And this is what a lot of people, a lot of women, resonated with trying out the program. And then, of course, we have these super nice glucose hacks you might have heard about also, where some of my favorites are definitely also always connecting what you eat with movement, so moving your muscles after your meal.

+ +

And I would say daily, we have such a high blast of user-generated content because people try it out, try the hacks, and then share their blood glucose response with us on social media. And this is so crazy to see. Also, people who are really into their bodies say, "I have these aha moments all the time just because I now understood, okay, it makes sense to have this type of breakfast. It makes sense how I eat my carbs, in which order I eat my food."

+ +

We have next to the social media content also some coaching sections we offer for our clients where we also hear a lot of those stories that they're really often so, so surprised and so happy that they finally made sense of their body signals.

+ +

WILL: Yeah, that's amazing. I'm a science geek; I'm just going to say it.

+ +

DR. LATZ: [laughs]

+ +

WILL: So I love how you can run your own scientific hypothesis and stuff. Like, you eat a banana at this time, how did it affect me? Okay, at this time, let me eat another banana. I just love that aspect because I don't think we have anything accurate enough right now that I know of besides actual drawing your blood in the lab or something like that that can actually give you that type of information.

+ +

DR. LATZ: Yeah, and especially if you take a lab just like once a month or once a quarter, then it's also really like a snapshot of the situation and might even have depended on how much did you drink? How was the night before? Like, what did you eat? And put some markers even there. And now you really have the ability to make it, yeah, it's a little bit more playful. Because of course, we recommend experiments you can make, start with an apple, eat the chocolate, do the pasta versus the rice.

+ +

But then you can customize it because it doesn't make sense to do experiments and try stuff out that you would never do in your daily life. So we always recommend start from where you really are. Wear the sensor for two, three days, just observe, and then look at what you really think is the problem for you. For a lot of people, it's the afternoon fatigue. So what could be the labor here? Where can we make a small change?

+ +

And then you really, as you say, a little bit of research on your own body and experiment around and tweak here, tweak there and that's the nice part. Then you come to changes that you also stick with. This is what we have also seen on our team, which are like the early adopters, and we worked on it for over a year. We really see that we get better blood glucose response in the mornings. And we just changed a little bit what order we eat.

+ +

If we go for ice cream, we just do a walk with the ice cream and all these small things which are really feasible and very, very contrary to what we also have in the diet culture, a lot of restrictive things. You cannot do that; you shouldn't do that. I always say it's very positive psychology; add that, combine it here, do some habits tweaking here. And you can really include that in your life further on.

+ +

WILL: That's amazing. Let's transition and talk about the starting of Hello Inside. What's the story? How did...because I think it's you and three other founders. How did y'all come about starting Hello Inside?

+ +

DR. LATZ: We are actually from very, very different backgrounds, but we have had some friends in common and some contacts, and, I mean, as I said, I'm a medical doctor. I have a digital health background. So I worked in digital health and other startups for over three years. My other co-founder is very much into the product and growth marketing. He was with Runtastic, which is now part of Adidas. So he has a sports lifestyle background and also expertise for the product.

+ +

The other one is responsible for brand and community investor relations. He really built also his own companies before. And the fourth is the tech guy who also worked in a medical startup and had his own agencies. So really, as you see, different backgrounds but very nice combination because we bring a lot of skills together and combine them from very different angles, and yeah, this is also, I would say, our power, and of course, it's also at the same time a challenge because not everybody is familiar in the same depth with the topics.

+ +

But I think that's often the point with diverse teams that you just have to communicate well to help the other people understand where you're coming from. We have to remind him to make research very understandable and really also explain that the tempo there sometimes is a little bit different, whereas I learn so, so much on what it means to build a product really at a high speed, to really iterate here and there.

+ +

So when we met, of course, the idea was to do something really with impact, to do something in the healthcare space but not too far into med tech. And we're really, really focused on this preventative field. I mean, you always say there's no glory in prevention. Prevention is super unsexy [laughs] for the individual but also the society, and we really want to change that.

+ +

Of course, Hello Inside was not Hello Inside from the beginning on then we found the name. And we're super happy with the company name, with the case we can make with looking inside, et cetera. Yeah, we're very much looking forward to building an even bigger company in the next years.

+ +

WILL: That's amazing. Your background is the medical portion of it. And you have experience in patient care in private and public healthcare, so tell us more about that. Are you still practicing? And how did you get into becoming a medical doctor? What was that drive for you to become a medical doctor?

+ +

DR. LATZ: To be frank, I was a business person first. [chuckles]

+ +

WILL: Oh.

+ +

DR. LATZ: I did first business bachelor, but that was like, for me, ages ago; [laughs] it feels like it. And after I finished my bachelor's, I was like yeah, okay, I want to do something else and applied for medical school, which was never on my mind before. And that's how it all started. I also had the chance to do my master's in business at the same time. So I always was like very open to look left and right.

+ +

And then, I started working in patient care, just very classical, like in a university hospital in psychotherapy. And I loved it a lot. But also, I was missing something to bring in this more innovative, creative part of my interests. I had the chance in a startup to work at some time in the U.S. It's called AMBOSS. It's an ad-tech startup. That's where I came really in the startup field and understood from a very junior position more and more about what it means to build a company.

+ +

Then I worked, coming back to Germany, for the ministry actually a little bit in the field of public health and prevention for diabetes. So here you see also how it now very well fits with what we're doing now, but of course, I can only say that now looking back. And I got certified in nutritional lifestyle medicine. And this is also something that really fascinates me a lot, like how these pillars really affect our lives all day, every day. And we do not learn so much also medical school about it, and that's where I learned for myself that this is really why I want to double down on these topics.

+ +

And a little bit before the first pandemic wave started, I found my way into digital health for a startup, being one of the first employees there, and had two years then to really learn on the market, with the market what it means to create a digital health company, and did my postgraduate certificate in Harvard at that time. So I learned patient safety, quality, informatics, and leadership.

+ +

And all these puzzle pieces then really fit well together last year when I met my co-founders, and we really iterated the idea more to build a company that combines all that, like, digital health and health and prevention with also metabolic health and lifestyle medicine, and, of course, all the innovative things we didn't know that they exist before and we are now learning on the market with. So this is how it all happened to me, and looking back, it all makes sense. But of course, there were a lot of segues. There were a lot of decisions to make on that journey.

+ +

WILL: Yeah, which I'm glad you brought up the decisions. That was my next question. What have been some of the toughest times in the startup? And what have been some of the most exciting times in the startup?

+ +

DR. LATZ: Yeah, I mean, I would even broaden up a little bit because just this week, we will launch a book which is in German but will also be in English soon, which really is quite personal. I wrote it with two other doctors, which is called Beyond Bedside. You could translate it. So we are all medical doctors who left bedside and found some new pathways, and two of us also as entrepreneurs.

+ +

And we had a lot of those hard decisions to take. I think one of the biggest learnings is always...and I think that also applies well for the startups: what got you here won't get you there. So you need this willingness to unlearn. You need to really understand, okay, now I'm a medical doctor, and I learned a lot, but in the startup, I'm just one of many, and I need to learn from the others. And I need to be really, really humble about what I can and cannot do.

+ +

I think this is always a problem of running a company. You want to be speedy because that's why you're a startup, but you also, especially in the healthcare space, need to do everything properly. And you have to navigate between really having a high quality, having everything according to guidelines because you're always working with people. It's always something you really need to be responsible of. This is also something that we need a lot of patience for a lot of things.

+ +

But yeah, in general, I would say we did quite a good job as we are a remote-first company. So it was during the pandemic that we founded the company. We have people all over the world working for us. I mean, that's not really specific for our company. But from what I know from colleagues as well, you just need to communicate, and communicate, and overcommunicate in different time zones to really make everybody really aware of the vision, the mission, repeat it again. And strategic decisions need to be clear to everyone.

+ +

So we put a high effort also on building a nice company culture and working on our ideas together and also get some on-sites where everybody can meet up. And yeah, this is sometimes really hard when you're so in your daily struggle, and there's so much to do. But then we need to take a step back and really say, okay, we need to invest in building an even better team.

+ +

WILL: Yeah, definitely. Wow. Wow, wow, wow, that's amazing. You've done medical school. You've practiced, and you've founded. Those are hard. Let's just be honest; those are hard things that you have accomplished, so congratulations on that.

+ +

DR. LATZ: Thanks, Will.

+ +

WILL: What has been some of the best advice that you received to help you keep going when those things got hard?

+ +

DR. LATZ: Do not ask the people who are in the very classical fit for...let me give you an example; I would not ask my chief when I worked in a hospital if I should leave the hospital because people who have always done it like that they would never recommend you to drop out and do something new and be innovative, and maybe also a little bit braver. So maybe the good advice from it would be ask the right people, ask a lot of people.

+ +

And then, looking back, one thing I really learned myself is also it's really hard times you have, and sometimes it's really you're doubting yourself. You're really overwhelmed. There's a lot going on. Especially those times will be, looking back, the ones that can be your hero story. Those are the ones that make you an even better person in the sense of being a coach for others and also for yourself later on. So you really need those struggles to understand and carve out what really moves your heart and where you really want to be invested. And there's also, and this is probably also still hard for me, saying no to a lot of things.

+ +

WILL: Hmm, that's really good advice, yes. Especially because you have experience in so many different areas, you can quickly overwhelm yourself by saying, "Yes." So, wow, I really like that advice. So in closing, is there anything else that you would like to share with us or with the audience?

+ +

DR. LATZ: Maybe something that I observe, I mean, I don't know if it's in U.S. the same, but I could imagine it's like a trend that's going on. Everybody thinks he or she needs to be an entrepreneur, founder, like own something, be by yourself. It's just not for everyone. I think that's okay. And I think that it's great that it's not for everyone. We need all the diverse roles. We need all the diverse employees. And being something for the sake of just being it is not a good motivation.

+ +

I think that nobody should really try to force him or herself into a role just because he or she thinks it's cool. There are many things you can do in your life and that you really should trust your gut and be also really brutally honest to yourself. And, like, I just want to be really...now it sounds better to say, "I just want to be a doctor," that's great. We need doctors; we need teachers; we need employees. There are so many great jobs, and there are so many days where I wish exactly the same.

+ +

At the same time, entrepreneurship gives you so much freedom of thinking. You learn so much on the job from other people, from your whole team. So there are many roads in crazy town. [laughs] There are many roads in the world. And this is really something we need to be aware of, this exactly, that it is really, really cool that we can do so many things and have really diverse roles in our society.

+ +

WILL: I love that advice because I 100% agree with you. Because I think there are people that are CEOs and they love to get out in front of people and talk and sell the company. But then you have a CFO or a CEO that's like, I just want to run the day-to-day, the books, or whatever that is, that's what I'm great at. So I love that advice.

+ +

DR. LATZ: Yeah, exactly.

+ +

WILL: Wow. Anne, it's been amazing talking to you about Hello Inside and just getting to know your company and you better. Thank you so much for being on the podcast today.

+ +

DR. LATZ: Thank you for your great questions, Will.

+ +

WILL: I appreciate it.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dr. Anne Latz is Co-Founder and Chief Medical Officer at Hello Inside, a company that specializes in scientific self-care.

+ +

Will talks to Dr. Latz about why glucose?, being a business-person first and what drove her to become a medical doctor, and where she sees wearable technology going in the in the next 5-10 years.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with us today is Dr. Anne Latz, Co-Founder and Chief Medical Officer at Hello Inside, a company that specializes in scientific self-care. Anne, thank you for joining us.

+ +

DR. LATZ: Thank you for hosting me today, Will.

+ +

WILL: Yeah, I'm excited to talk about Hello Inside. And let's start there; give us a quick summary about Hello Inside.

+ +

DR. LATZ: So we are a German-Austrian startup, so we are based all over Europe, actually, all over the world, I have to say. And we help people by means of technology to understand their bodies best so to really become an expert of their bodies. And the technology we use is not only a smartphone app that shows data but a sensor that's called continuous glucose monitoring sensor that's like a little window you put on your arm that shows you in real-time your glucose data.

+ +

And we at Hello Inside have then an app and the service around that that really helps you to understand your data and become an expert of your body because this data really gives you immediate feedback on what you do in the sense of eating, moving, but also how well you slept, how stressed you are.

+ +

WILL: Wow, that's really neat. You said you had the continuous glucose monitor. The body is so complex, and there are so many ways that you probably could measure activity of the body. Why the glucose portion? Why are you doing glucose?

+ +

DR. LATZ: I think that there are two, maybe even three, reasons to that. The first one is we do not have so many tools like biosensors or technology on the market, which enable us to give really continuous data on different biofluids or markers in the body. So the first one is just that the market here is quite mature because we usually know glucose from the context of diabetes patients, and the technology has been developed years and years ago for those people. And that's why we have really, really good technology, really good sensors, which have high accuracy. The prices get lower and lower, so more and more people can really access this technology. And we just know already a lot about glucose management.

+ +

The second is it's a super, super potent marker. So I'm a medical doctor from my background. And I do not know so many markers in the body; maybe it's the heart rate variability or pulse that give us really immediate feedback to so many lifestyle pillars. So I think eating is quite intuitive that it does something to our blood glucose, but also movement does, also sleep and stress. And all these pillars immediately affect us, and we often know that. But this marker really gives us a take on how we can really visualize in the moment and then create a change from that.

+ +

And the third is probably that it's just a really hot topic, the glucose monitoring, currently, and that's actually not a good thing. But we have really not only an obesity epidemic but really a metabolic health crisis. So a lot of people have problems with their glucose levels, not aware of it. A lot of people have, in general, problems with managing; yeah, I would say, their metabolism and have an energy crisis in their body. You could put it like that.

+ +

And that's why we are really interested in glucose because if you manage glucose in the sense that you stabilize it, you can really improve your health in the short term and how much energy you have, midterm in the sense of what your weight is, and of course, long term to prevent diseases like diabetes or heart disease.

+ +

WILL: Yeah, definitely. I think you're correct; you know, glucose is the one thing, especially for me, it's diabetes, and I know it in that direction. But also that after lunch drag that you hit, the wall that you hit whenever your glucose spikes and then it comes down and spikes, I mean, then crashes. I think that's the other direction people understand glucose from.

+ +

DR. LATZ: Yeah, for sure. I mean, you bring up a great example, like the food coma after lunch. Everybody knows that, like, this energy and fatigue in the afternoon. But, I mean, you seem to be a little bit familiar with the technology, but a lot of people do not even connect the dots. They cannot really bring together what they eat and their behavior, for example, at lunchtime, how it really impacts them hours later.

+ +

And what we love so much about the technology and what we can also use the Hello Inside servers a lot for is really to find out what you do, like, what you think is healthy often. A good example is a smoothie you drink that might spike your blood glucose, but you don't really understand it because you thought it was a healthy choice. So it gives me more nuance as to what is healthy for you because it's...and we didn't even stress that, but it's also highly personalized. So you and I would eat the same lunch, and we would react completely differently to it.

+ +

So there's so much actionable data from it; that's what we love. And yeah, it's a little bit like running a lab test every few minutes of the day [chuckles] and give you the responses really on your smartphone to your hand and also some alternatives of how to create change there.

+ +

WILL: Yeah, definitely. And I'm glad you brought that up because one of the questions I had for you is, with Hello Inside, how do you see it combating the bad advice around self-care and dieting when you're getting great scientific data? It's kind of hard to argue with the data and the numbers.

+ +

DR. LATZ: For sure, yeah. I mean, we all know health, wellness, lifestyle. It all gets very close together, which has good sides and bad sides. But of course, people are still so confused in what is really good for them and their bodies. Because healthy, yeah, it's not a very specific term, especially in, let's stay with the example of food, what you put in, and different diet regimes you have. We see that there's so much frustration also in the market because all these one-size-fits-all recommendations in diet regimes or fasting regimes do not work for all people.

+ +

And that's really why these personalized approaches, and as you say, data-driven approaches, are so crucial because then you really get power back in trusting your body and understanding how your personal health and well-being is really influenced. At the same time, it's super hard because some of these trends and fad diets have existed for a long time and have a huge community who really love them. But we see it really as a conversation, like a conversation we have with the users, but also a conversation that users have with their bodies.

+ +

Because we know that creating change, especially behavior change, is like the holy grail for all health and also weight management tools. But it's also something that just takes a little longer because you need some experimenting. You need to find out what really works for you. But I'm quite convinced that when you see the data that's based on your body, that's something that you do not forget. If you see the foods that really spike you, surprisingly, this is really powerful.

+ +

WILL: Yeah, definitely. And I can understand the benefit of it, especially, you know, you're working out two weeks, and your body really is not showing you any signs of change. But I can see how this could help in showing you the change, even if it's small, how you can say, hey, you're on the right track.

+ +

DR. LATZ: Exactly. Yeah, it's like these small nudges. I mean, it's a monitor that already shows you the shortcuts and the little tweaks you make. For a lot of people, I always say if you find one food, one spiking element in your day and change that for the rest of your life, that's so much. For a lot of people, it's already in the breakfast. They jump on the blood glucose rollercoaster in the morning because they eat maybe porridge without any added protein to it. So it is very carb heavy, and they think it's super healthy and drink the oat milk latte.

+ +

I mean, in general, there's nothing wrong with those foods, but you can combine them even better and add something to it and not really eliminate stuff but just add a nice mix of protein and fat to your carbs. And you will be so much fitter during the day. You will not have this huge spike putting you on the roller coaster in the morning. As we are very habitual people, I mean, people eat like 60 different foods per week, which is not a lot; once you find out what really works for you, that's super, super nice for the rest of your life.

+ +

WILL: Yeah, definitely. And to be honest, I have been guilty of, oh, I just ate a very healthy meal. And then I go back and look at the nutritional facts, and I was like, what did I just eat? Because this was not healthy.

+ +

DR. LATZ: Yeah, we should always learn and make mistakes and learn again. And it's like a jungle out there. I mean, health, in general, the healthcare market is quite complicated. And I think that doesn't only apply to Germany but definitely to where I'm based but also to the U.S. and all the different markets. And for food, it's the same; I mean, that's a little bit the enemy we all are trying to deal with because the food industry is so powerful. It has so much lobby. And you get so confusing information that this is really what we can use our tools now for to understand what really these, I would say, not always healthy but claimed healthy foods do to us.

+ +

WILL: So, I have a question around wearable technology. So the last couple of years, there's been a trend of wearable technologies, the Garmins, the Apple Watches. This takes it to the next level. This is way more accurate than any of the wearables. Do you see this as the future in the next 5 or 10 years?

+ +

DR. LATZ: Yeah, probably in the next 5 or 10 years, we will see even more to it in the sense of personalization. And also, I personally believe that we really have a toolbox here of different markers we use. Maybe some are still invasive, like the CGM you put on your arm that really measures the fluids invasively. But also, there will be an array of other things we can really include into our daily health checks.

+ +

But this is definitely the next level of, as you said, Garmin and all these tracking tools because now we not only track data and have data, but we make them so actionable because we really put them into an immediate setting. So we can really calculate them now. I'm currently wearing my sensor, and I can have a look at my phone after we've finished recording and see, okay, what happened just now in my body? How did I respond to the setting? Was I super stressed? How is my lunch (because here it is early afternoon) affecting our body?

+ +

We really had already the switch of not only measuring stuff but making it really approachable, actionable. And yeah, I think CGM will be one of the first tools where we can really make this approachable for the broad public; then, we will have a lot of different markers and sensors to look at. And in respect to glucose management, I really am looking forward to when we get the press announcement of some company that we can also non-invasively and continuously measure blood glucose, which is currently not feasible, and a lot of companies are working on it. So this would be very exciting in the next years.

+ +

WILL: That's exciting. And I love how complex the human body is.

+ +

DR. LATZ: Oh yeah.

+ +

WILL: Like you just said, "How stressed was I?" And you can get that from your glucose level.

+ +

DR. LATZ: Yeah, it's super complex, and it really takes the time to also figure out what...because just measuring data is not really exciting anymore. Then you have a lot of data, and then you're like, so what? So to really figure how interdependent these lifestyle pillars are of movement, sleep, food, et cetera, that really takes some time, but once you understand it, it makes so much sense.

+ +

For example, stress is like this fight or flight response we've all heard about, and of course, you need energy for it. And that's why your blood glucose might go up because your body gives you energy to, for example, run away, [chuckles] or be alert. And then always breaking down to why our body does things always helps me to also make sense of the data.

+ +

WILL: That's amazing. Really amazing.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff.

+ +

WILL: So tell me what excites you about Hello Inside, the company.

+ +

DR. LATZ: I mean, we founded this company with a very clear vision that we really want to help people to become experts of their body and really learn their body's language because this is a quite messed up system. We do not really understand our bodies' signals in the daily life. For example, hunger or thirst, a lot of people cannot really tell what the body is talking to them, so we think it's a super emotional topic.

+ +

And especially the combination of these really approachable, emotional, real-life moments with newest tech is, I think, an amazing combination because we can reach people really where they are. We can give personalized insights of your personal body. This is also something that makes you so much more reliable and compliant in what you do. Then we can really display the data in a way that you can experientially learn from it.

+ +

To give you an example, in our Hello Inside app, one of the favorite features of mine is the experiment feature, so you would have a food event. Let's make it super simple, eat an apple and feel your body in the next two or three hours. So that's usually when we take into account the response to that food. And then you compare that to one factor you change, so you eat the apple with some nuts or nut butter. I would suggest to most people, but of course, it's hyper individual, and what extent it changes in the blood glucose response just because you included the nuts, which include fat and protein.

+ +

You can put these two graphs, these two blood glucose curves together, and you really see the gap between it just from including nuts in your diet. And this is this nice combination of visualization, data-driven insights, and also something where you, I mean, people love to take pictures of their food. And that's what you can usually do here.

+ +

WILL: Wow, that's amazing. You were talking about your story behind using Hello Inside, the CGM. Do you or any of your clients have any success stories that you would like to talk about?

+ +

DR. LATZ: Yeah, for sure. I mean, we are quite a young company. We launched only in June and are live now in seven European countries. And actually, I have some really, really cool stories. We launched with a very strong focus on women's health. So we have developed a program which is called Hello Hormones, which helps women along the cycle via the Hello Inside app. And this continuous glucose monitor really improves symptoms like PMS, which can be like bloating, pains, et cetera.

+ +

And a lot of women didn't really understand (And how would they?) that your body has a very variable response to foods depending on the menstrual cycle. To visualize that, a very simple example would be eat in the first half of your cycle, before your ovulation, a banana, and eat the banana in the second half of the cycle. And I can promise you; you will have a different response to it which is super physiological. It has to do with insulin sensitivity. But you cannot really make sense of that (You feel differently in the phases.) which you now can really do when you saw in the data, really compared it, that you have higher levels of blood glucose maybe in the second half.

+ +

And you can make small tweaks which help you then to really increase well-being also in the second phase of the cycle before you have your period, which can be by reducing inflammation by changing how you move during that time, et cetera. And this is what a lot of people, a lot of women, resonated with trying out the program. And then, of course, we have these super nice glucose hacks you might have heard about also, where some of my favorites are definitely also always connecting what you eat with movement, so moving your muscles after your meal.

+ +

And I would say daily, we have such a high blast of user-generated content because people try it out, try the hacks, and then share their blood glucose response with us on social media. And this is so crazy to see. Also, people who are really into their bodies say, "I have these aha moments all the time just because I now understood, okay, it makes sense to have this type of breakfast. It makes sense how I eat my carbs, in which order I eat my food."

+ +

We have next to the social media content also some coaching sections we offer for our clients where we also hear a lot of those stories that they're really often so, so surprised and so happy that they finally made sense of their body signals.

+ +

WILL: Yeah, that's amazing. I'm a science geek; I'm just going to say it.

+ +

DR. LATZ: [laughs]

+ +

WILL: So I love how you can run your own scientific hypothesis and stuff. Like, you eat a banana at this time, how did it affect me? Okay, at this time, let me eat another banana. I just love that aspect because I don't think we have anything accurate enough right now that I know of besides actual drawing your blood in the lab or something like that that can actually give you that type of information.

+ +

DR. LATZ: Yeah, and especially if you take a lab just like once a month or once a quarter, then it's also really like a snapshot of the situation and might even have depended on how much did you drink? How was the night before? Like, what did you eat? And put some markers even there. And now you really have the ability to make it, yeah, it's a little bit more playful. Because of course, we recommend experiments you can make, start with an apple, eat the chocolate, do the pasta versus the rice.

+ +

But then you can customize it because it doesn't make sense to do experiments and try stuff out that you would never do in your daily life. So we always recommend start from where you really are. Wear the sensor for two, three days, just observe, and then look at what you really think is the problem for you. For a lot of people, it's the afternoon fatigue. So what could be the labor here? Where can we make a small change?

+ +

And then you really, as you say, a little bit of research on your own body and experiment around and tweak here, tweak there and that's the nice part. Then you come to changes that you also stick with. This is what we have also seen on our team, which are like the early adopters, and we worked on it for over a year. We really see that we get better blood glucose response in the mornings. And we just changed a little bit what order we eat.

+ +

If we go for ice cream, we just do a walk with the ice cream and all these small things which are really feasible and very, very contrary to what we also have in the diet culture, a lot of restrictive things. You cannot do that; you shouldn't do that. I always say it's very positive psychology; add that, combine it here, do some habits tweaking here. And you can really include that in your life further on.

+ +

WILL: That's amazing. Let's transition and talk about the starting of Hello Inside. What's the story? How did...because I think it's you and three other founders. How did y'all come about starting Hello Inside?

+ +

DR. LATZ: We are actually from very, very different backgrounds, but we have had some friends in common and some contacts, and, I mean, as I said, I'm a medical doctor. I have a digital health background. So I worked in digital health and other startups for over three years. My other co-founder is very much into the product and growth marketing. He was with Runtastic, which is now part of Adidas. So he has a sports lifestyle background and also expertise for the product.

+ +

The other one is responsible for brand and community investor relations. He really built also his own companies before. And the fourth is the tech guy who also worked in a medical startup and had his own agencies. So really, as you see, different backgrounds but very nice combination because we bring a lot of skills together and combine them from very different angles, and yeah, this is also, I would say, our power, and of course, it's also at the same time a challenge because not everybody is familiar in the same depth with the topics.

+ +

But I think that's often the point with diverse teams that you just have to communicate well to help the other people understand where you're coming from. We have to remind him to make research very understandable and really also explain that the tempo there sometimes is a little bit different, whereas I learn so, so much on what it means to build a product really at a high speed, to really iterate here and there.

+ +

So when we met, of course, the idea was to do something really with impact, to do something in the healthcare space but not too far into med tech. And we're really, really focused on this preventative field. I mean, you always say there's no glory in prevention. Prevention is super unsexy [laughs] for the individual but also the society, and we really want to change that.

+ +

Of course, Hello Inside was not Hello Inside from the beginning on then we found the name. And we're super happy with the company name, with the case we can make with looking inside, et cetera. Yeah, we're very much looking forward to building an even bigger company in the next years.

+ +

WILL: That's amazing. Your background is the medical portion of it. And you have experience in patient care in private and public healthcare, so tell us more about that. Are you still practicing? And how did you get into becoming a medical doctor? What was that drive for you to become a medical doctor?

+ +

DR. LATZ: To be frank, I was a business person first. [chuckles]

+ +

WILL: Oh.

+ +

DR. LATZ: I did first business bachelor, but that was like, for me, ages ago; [laughs] it feels like it. And after I finished my bachelor's, I was like yeah, okay, I want to do something else and applied for medical school, which was never on my mind before. And that's how it all started. I also had the chance to do my master's in business at the same time. So I always was like very open to look left and right.

+ +

And then, I started working in patient care, just very classical, like in a university hospital in psychotherapy. And I loved it a lot. But also, I was missing something to bring in this more innovative, creative part of my interests. I had the chance in a startup to work at some time in the U.S. It's called AMBOSS. It's an ad-tech startup. That's where I came really in the startup field and understood from a very junior position more and more about what it means to build a company.

+ +

Then I worked, coming back to Germany, for the ministry actually a little bit in the field of public health and prevention for diabetes. So here you see also how it now very well fits with what we're doing now, but of course, I can only say that now looking back. And I got certified in nutritional lifestyle medicine. And this is also something that really fascinates me a lot, like how these pillars really affect our lives all day, every day. And we do not learn so much also medical school about it, and that's where I learned for myself that this is really why I want to double down on these topics.

+ +

And a little bit before the first pandemic wave started, I found my way into digital health for a startup, being one of the first employees there, and had two years then to really learn on the market, with the market what it means to create a digital health company, and did my postgraduate certificate in Harvard at that time. So I learned patient safety, quality, informatics, and leadership.

+ +

And all these puzzle pieces then really fit well together last year when I met my co-founders, and we really iterated the idea more to build a company that combines all that, like, digital health and health and prevention with also metabolic health and lifestyle medicine, and, of course, all the innovative things we didn't know that they exist before and we are now learning on the market with. So this is how it all happened to me, and looking back, it all makes sense. But of course, there were a lot of segues. There were a lot of decisions to make on that journey.

+ +

WILL: Yeah, which I'm glad you brought up the decisions. That was my next question. What have been some of the toughest times in the startup? And what have been some of the most exciting times in the startup?

+ +

DR. LATZ: Yeah, I mean, I would even broaden up a little bit because just this week, we will launch a book which is in German but will also be in English soon, which really is quite personal. I wrote it with two other doctors, which is called Beyond Bedside. You could translate it. So we are all medical doctors who left bedside and found some new pathways, and two of us also as entrepreneurs.

+ +

And we had a lot of those hard decisions to take. I think one of the biggest learnings is always...and I think that also applies well for the startups: what got you here won't get you there. So you need this willingness to unlearn. You need to really understand, okay, now I'm a medical doctor, and I learned a lot, but in the startup, I'm just one of many, and I need to learn from the others. And I need to be really, really humble about what I can and cannot do.

+ +

I think this is always a problem of running a company. You want to be speedy because that's why you're a startup, but you also, especially in the healthcare space, need to do everything properly. And you have to navigate between really having a high quality, having everything according to guidelines because you're always working with people. It's always something you really need to be responsible of. This is also something that we need a lot of patience for a lot of things.

+ +

But yeah, in general, I would say we did quite a good job as we are a remote-first company. So it was during the pandemic that we founded the company. We have people all over the world working for us. I mean, that's not really specific for our company. But from what I know from colleagues as well, you just need to communicate, and communicate, and overcommunicate in different time zones to really make everybody really aware of the vision, the mission, repeat it again. And strategic decisions need to be clear to everyone.

+ +

So we put a high effort also on building a nice company culture and working on our ideas together and also get some on-sites where everybody can meet up. And yeah, this is sometimes really hard when you're so in your daily struggle, and there's so much to do. But then we need to take a step back and really say, okay, we need to invest in building an even better team.

+ +

WILL: Yeah, definitely. Wow. Wow, wow, wow, that's amazing. You've done medical school. You've practiced, and you've founded. Those are hard. Let's just be honest; those are hard things that you have accomplished, so congratulations on that.

+ +

DR. LATZ: Thanks, Will.

+ +

WILL: What has been some of the best advice that you received to help you keep going when those things got hard?

+ +

DR. LATZ: Do not ask the people who are in the very classical fit for...let me give you an example; I would not ask my chief when I worked in a hospital if I should leave the hospital because people who have always done it like that they would never recommend you to drop out and do something new and be innovative, and maybe also a little bit braver. So maybe the good advice from it would be ask the right people, ask a lot of people.

+ +

And then, looking back, one thing I really learned myself is also it's really hard times you have, and sometimes it's really you're doubting yourself. You're really overwhelmed. There's a lot going on. Especially those times will be, looking back, the ones that can be your hero story. Those are the ones that make you an even better person in the sense of being a coach for others and also for yourself later on. So you really need those struggles to understand and carve out what really moves your heart and where you really want to be invested. And there's also, and this is probably also still hard for me, saying no to a lot of things.

+ +

WILL: Hmm, that's really good advice, yes. Especially because you have experience in so many different areas, you can quickly overwhelm yourself by saying, "Yes." So, wow, I really like that advice. So in closing, is there anything else that you would like to share with us or with the audience?

+ +

DR. LATZ: Maybe something that I observe, I mean, I don't know if it's in U.S. the same, but I could imagine it's like a trend that's going on. Everybody thinks he or she needs to be an entrepreneur, founder, like own something, be by yourself. It's just not for everyone. I think that's okay. And I think that it's great that it's not for everyone. We need all the diverse roles. We need all the diverse employees. And being something for the sake of just being it is not a good motivation.

+ +

I think that nobody should really try to force him or herself into a role just because he or she thinks it's cool. There are many things you can do in your life and that you really should trust your gut and be also really brutally honest to yourself. And, like, I just want to be really...now it sounds better to say, "I just want to be a doctor," that's great. We need doctors; we need teachers; we need employees. There are so many great jobs, and there are so many days where I wish exactly the same.

+ +

At the same time, entrepreneurship gives you so much freedom of thinking. You learn so much on the job from other people, from your whole team. So there are many roads in crazy town. [laughs] There are many roads in the world. And this is really something we need to be aware of, this exactly, that it is really, really cool that we can do so many things and have really diverse roles in our society.

+ +

WILL: I love that advice because I 100% agree with you. Because I think there are people that are CEOs and they love to get out in front of people and talk and sell the company. But then you have a CFO or a CEO that's like, I just want to run the day-to-day, the books, or whatever that is, that's what I'm great at. So I love that advice.

+ +

DR. LATZ: Yeah, exactly.

+ +

WILL: Wow. Anne, it's been amazing talking to you about Hello Inside and just getting to know your company and you better. Thank you so much for being on the podcast today.

+ +

DR. LATZ: Thank you for your great questions, Will.

+ +

WILL: I appreciate it.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+UgnC-W4d + + ]]> + + Will Larry + + + 454: The Global Collective with Stacy Kehren Idema + https://podcast.thoughtbot.com/454 + 4c5e611e-2436-4539-8921-e3dbb393110d + Thu, 22 Dec 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Stacy Kehren Idema is the Founder and Managing Director of Global Collective, which is revolutionizing how men and women do business. + +Chad talks to Stacy about the work Global Collective does, starting a company based in the U.K, and the differences between doing business in the U.S. and the U.K. + 35:50 + no + + + Stacy Kehren Idema is the Founder and Managing Director of Global Collective, which is revolutionizing how men and women do business. +Chad talks to Stacy about the work Global Collective does, starting a company based in the U.K, and the differences between doing business in the U.S. and the U.K. +The Global Collective (https://www.globalcollective.global/) +Follow The Global Collective on LinkedIn (https://www.linkedin.com/company/global-collective-global/). +Follow Stacy on Twitter (https://twitter.com/stacyidema) or LinkedIn (https://www.linkedin.com/in/stacykehrenidema/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Stacy Kehren Idema, the Founder and Managing Director of Global Collective, which is revolutionizing how men and women do business. Stacy, thank you for joining me. +STACY: Chad, it is a pleasure. How are you today? +CHAD: I'm well. I'm well. [laughs] I wasn't going to bring it up, but since you asked, I feel like whenever someone asks that question, I feel like I need to give an honest answer. +STACY: Of course. +CHAD: Because I think, so often, we don't answer honestly. We just sort of...so what's going on in my life right now is, unfortunately, even though we got our fourth boosters three weeks ago, my wife tested positive for COVID yesterday. +STACY: Oh no. +CHAD: And so she feels fine. She feels mostly fine. But we have kids and everything, so it throws a huge wrench into life right now. We're very fortunate that we've got vaccines, and it'll be mild and everything, but it is a big wrench in our life. +STACY: It is. +CHAD: Today, tomorrow, for the next week, so... +STACY: I'm sorry. +CHAD: Yeah, so she's in a different part of the house, quarantining away from all of us, and we're hoping for the best. +STACY: Me too. +CHAD: We could probably do a whole hour around how life is for all of us right now, coming in this different stage of the pandemic. I hesitate now to ask you, how are you today? [laughs] +STACY: I'm here in London, so, for me, it's the end of my day. And fortunately, I haven't had COVID in a few months. But I know that experience and being even alone was enough to put a wrench in everything. So I get it. +CHAD: Yeah. Yeah. Well, let's get back to Global Collective. I gave just a brief snippet. But can you tell people a little bit more about what it is you're actually doing? +STACY: Yes, I would be honored. So the mission of The Global Collective is to revolutionize really how investment companies invest in female-founded and led businesses, and there are three key areas of that. It's really about changing gender perceptions by actually connecting the unique strengths of each gender. And if you were to even remove the gender piece, it's really talking about the core masculine and the feminine energies of how and what resides in all of us. How can we bring more of the flow and the creativity into business? +The mission is also designed to eliminate the diversity gap. How can we make things better, more equitable, easier both for the men and the women, you know, going back to the genders? And something that's very near and dear to my heart is really about increasing the financial benefit and, frankly, the mental well-being in business because one thing that we don't talk enough about is the impact that mental health can have not only on our personal life but on business and vice versa. And I think it's starting to come out more and more. +But with founders, with entrepreneurs, and with executives, that mental illness journey has actually increased, and there are some really interesting statistics on it. So, how can we make it a non-shaming conversation? And how can we actually help each other in this area? So the mission is really about transforming business into something different that I think we're all feeling the need for. +And how it actually came about was from my 50 years of business and personal experience. I was born into business owners, into a family of business basically. My first husband was a generational business owner and had the hard position to be in, and he had to choose family over business. And then I, in my corporate career, had a really long tenured corporate career. +I worked 26 years in companies as small as 40 as well as at Fortune 7 companies where we even did new initiatives, new businesses, startups within those. And modestly, most of my time was actually spent with male executives. And I'm a woman in business. I've been in business a really long time. So that's a little bit about the mission and how The Global Collective came about. +CHAD: You're not the first guest we've had on the show that's talked about these issues. But I'm curious because it is more of a conversation right now. It's something that we've been talking about on the show. Is there something that people in that environment that maybe people still don't realize or that you need to just reiterate over and over again here are the challenges, here are the differences, here's what's happening in the real world right now? +STACY: Specific to the mental health piece? +CHAD: Either the mental health piece or just women in business and what it's like for them. +STACY: Well, I think this is where I love to talk a little bit about the extremes and where those extremes are actually very similar. I believe that men feel like there's this weight of the world on their shoulders and that they have to provide, and serve, and do. And I also believe women do as well, you know, provide for their family, protect for their family. For many women, they may even be a single parent, and with that, they want to be able to go out and provide for themselves and do. +So you have this desire, this deep desire to do both of those things differently, yet, we're going at it both parallel. And at some point, I think the convergence and really where things start to explode in a beautiful way is when we get to come together. Because if we go about it in a very myopic fashion, we often miss the things that are going on around us that could be a benefit. +So from a very specific where I'm very focused on in the venture capital and investment space, so much of what has happened over the course of business time, if you will, and when venture capital investments started, which is, you know, I would imagine hundreds and hundreds of years, it has been mostly men that have done that investment. And when you look at the world as it exists today, it is mostly men that...I don't want to say control the money, but they're the ones in that business. +So when you continue on doing the same thing that you've always done and you don't do anything new, that's telling us a couple of things: you don't know how, or you're afraid. And women, on the other hand, are going about doing their thing, working really, really hard. They're probably even more so working harder because it takes longer for them to earn just as much as a man. If they get funded, it takes longer to get funded, and then they actually get less, but they get to that point. +And in the meantime, they've had to either endure additional risks to their family by not spending time with their family, or giving up their family and focusing on the business, or focusing solely on their family and giving up the business. So we don't have to do things the way that we're doing them now. +And the other element, and where the mental health piece comes in, is this thought that we still have to do these things in these linear ways when we can actually come together and learn the beauty of what men do well in business and the beauty of what women do well in business, and figure out how to do it differently. +CHAD: You mentioned you have a lot of experience working for other companies. So I'm curious, when did you start to feel like you needed to do something to solve this problem and potentially create a new company around it? +STACY: I've always had a deep desire to do business differently. And what I didn't know at the time in my corporate career was why I didn't feel like I fit in. Having grown up in that business world and knowing what it was like before cell phones and you still had your landline, and a Sunday evening, the telephone rings, and you're sitting at dinner, and your parents dare not answer the phone because the phone will keep ringing until somebody answers. That's just how it happened in the small town I grew up in. +Knowing that stress and that pain and watching them go through that to being married to a small business owner, and then being in the rooms and the spaces of the people and hearing the stress and the pain, there was this thing that followed me all the way through that knew that business had to be done differently. And I attempted to insert it a lot in my corporate career, and for most, because I wasn't a box-checker, I didn't fit in. +But the deep desire to finally do it differently was in 2019 when I was made redundant. I had been working and doing coaching on the side, and it was my goal to finally go into business for myself. But in 2020, I divorced myself and decided to take myself on a journey. My children are a little older; they're in their early 20s. And I decided to just kind of come back to myself and understand what did I need to do this business for me and to do with what was deeply passionate within me. And could I do it in another country? +So in 2021, I spent six months in London and, as part of that journey, did some work for a woman who owns a diversity, & inclusion, and belonging company. And through that experience and listening to her, along with a few other women, talk about that journey to get invested, there was something inside of me that just clicked. It was as if I was reliving sitting in front of capitol committees in my corporate world and listening to the same stories. I'm like, you know, that's just not how things have to happen. +It was that moment that I knew it wasn't for me just about helping the women in business and helping them scale their business; it was something bigger than that because, in order to do that, to make that change, and to really make a meaningful change, you have to bring the men along for the journey. You have to help them. I know there are many men out there that are all for women-owned businesses, co-founded businesses, women-led businesses, and many of them come to me privately and talk to me about it. And my response is I need you not to tell me; I need you to show me. +And with that, I've also learned that many of them are afraid. They're afraid to do something different, which tells me that we have to create a space for both the men and the women to thrive. Otherwise, we'll just keep spinning our wheels and doing the same thing over and over again. And it will be far more difficult to get to where we need to get to than how we can get to where we want to go doing it a different way. +CHAD: So, what does the work Global Collective does look like? Is it coaching? Is it more than that? Is it different than that? +STACY: My end vision, the bigger vision, is really this end-to-end ecosystem. So there are roughly five elements or five stages of a business idea: start, sustain, scale, and exit. The focus right now is on the scale and working through pilots with investors and with women in business to learn what and how we do it differently. Coaching will be a component of it, the mental health journey and navigating how that works for the founder and the business owner executive also becomes part of it. +But it also is extensive external networks and communities that we bring into that ecosystem that can support both the investors and their journey and the women in business and their journey. Because the other elements that I have learned along the way is when these investors invest in these all-male-led firms, they don't even know how to help those businesses diversify. They themselves even know and have that challenge. +Let's take, for example, a woman founder who would like to go on maternity leave. It's more often that she will leave that business because the pressure from the investors to stay in the business and choose business over family is great. Wouldn't it be fantastic if there was a collection of fractional C-suite individuals that get to come in and help that business along on that journey? +And not only does the female founder get to be part of deciding who and what will be taken on and for how long, but the investor and the business. And then that way, everyone is along on that journey and is in agreement of what's going to happen. So there isn't that pressure to have to choose between business and family for anyone. +CHAD: I guess that's part of where the collective idea and name comes from. +STACY: Yeah. +CHAD: That's great. You mentioned you moved to the UK as part of this journey. Are you working with companies primarily focused on the UK, or are you doing it globally? +STACY: My focus right now is the U.S. and the UK. So I actually started a brand new business. I secured my own visa. And as part of that visa, I had to start a new business, which was this business. So yeah, the primary locations right now have been UK and U.S. If an opportunity came up in a different country, that would be fantastic, exciting, but that's where I've been focused are in those two areas. +CHAD: When thoughtbot was getting started in Europe, like most locations that started for us, it was driven by someone who was from there originally and wanted to go back. So when we were getting started, me and my family...my wife was working for a company based in France at the time, and so we were able to go over for the summer. The kids were out of school for the summer. And so we spent several months there, and we loved it. +And we're fully remote now, but when we had an office there, I would go about once a month. There's probably a small list of places where I could see myself living [laughs], and that's at the top of the list. Was that the case for you? Did something particularly resonate for you? +STACY: You know, I had never been to Europe. And when I was looking at where I would go, I wanted a place that would be culturally diverse. I wanted a place where I could learn, just even be more immersed in history, and feel safe as a single woman in a foreign country. I'm grateful for my family. They're always very concerned about me, and frankly, so are my boys. Having two young adult men, I worried about them, but now they worry about me has started to come into play. +For me, it was really about where can I be that would be safe, culturally diverse, and allow me the ability to travel, and to your point, to just go explore new things, really to take a different perspective even outside of the gender diversity piece, the cultural, the language, all of those things? And so this place is home, and I didn't know that when I set off. +I thought it just would be; I'll go see how it is for three months. And then I wasn't even here a week, and I said three months wouldn't be enough and stayed six. And it was about five weeks into that journey that I said six months won't be enough; I need to be here longer. And then that's when I did more due diligence from the visa standpoint. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +CHAD: Is there anything that either has stood out to you or surprised you about differences between business in the U.S. and the UK? +STACY: It's fascinating to see how much they complain. The U.S. and the UK complain about each other and their work standards, yet how much they like what each other does. So I would say some of the biggest differences is that the city truly never seems to sleep, yet they definitely take time away from work and business and are very family-focused. That's probably some of the biggest things that I have learned as part of it, and especially having grown up in the culture that I grew up in, in corporate, where it was very much the grind of the nine-to-five plus. +So there are some slight differences. I think, if anything, there's just so much more culture and people here that have come from so many other different parts of the world that that's probably the thing that I noticed the most. +CHAD: Do you think that the work you're doing is ready to be received more or less in either of the places? +STACY: I think different parts of it are more ready to be received in different parts in each country. +CHAD: Can you tell me more about that? +STACY: Yeah, there's probably more heavy gender influences here in the UK, especially with Scandinavian countries that are much more gender equitable. So I think that piece is very much a belief here. And there are other elements that support both sets of parents from a family standpoint in this country. So I think that is more readily received. +I also do know that women-owned businesses are significantly less here and certainly less from getting funded. I think that's where the U.S. is further ahead in that game. However, the number of businesses that are started by women are significantly more than what they are here. It becomes more about who's louder with certain pieces. I think the U.S. is louder in that area. I think the UK is more open and receptive. +CHAD: One of the things that I learned about investment in general between the U.S. and the UK is there's not, I mean, it's just not as big of a place as the U.S. The amounts are often less. And I'll say, speaking a little bit more generally, I would say people in the UK, investors in the UK, are a little bit focused on different things. They're maybe a little bit more risk-averse, or they're focused on different markets. So the investment community is a little bit different between the two different places. Does that make the opportunity for founders, particularly women founders, any different between the two different places? +STACY: From the research that I've done through some interviewing with investors and then the research I've done on my own, there's a lot of little, smaller type of investment for female founders in the U.S. than there is in the UK. But that said, one thing that seems to be very prevalent is how much Europe, in general, talks about London being the epicenter for Europe and investment. You're asking a great question that I hadn't thought about in that framework. +CHAD: Yeah, and I don't know the answer either [laughs], so... +STACY: What I do know is in the U.S., there are more female-founded investment companies and female-led. However, I do know many of them are very much sticking to U.S. companies. But what I do know is that the UK is starting to leverage more and work in more partnership with U.S. investment companies. +CHAD: So if I am an investment firm, chances are that my entire, especially the leaders in the firm, are probably all men, maybe not, but if not all men, then the majority. So if I was sitting in that seat, how do we get started on this journey? Contact you? +[laughter] +STACY: Yeah, contact me. [laughs] Honestly, it begins with a conversation. This is the really interesting piece that I don't think that we've yet talked about is women believe that men have control of all the money. And while they may be the ones that are leading more of these investment firms, it's not just up to them, if you will. +There is this piece of the puzzle that, yes, we have these male-led investment firms, and they have repeatedly invested in mostly male-led businesses. But we have these women who have these beautiful businesses. Women are known for going to market with products and services that have fewer competitors in the market because 70% to 90% of consumer buying decisions around the globe are made by women. And so when they're out there buying and they see a gap, that's where a lot of these women start these businesses is based off of this gap that they see in the market, but they do have the power. +How can I, as part of this...and even the men because I know I wouldn't be where I am today without the male mentors and influencers in my life encouraging me to be bolder and to be better. And they could see in me some things I wasn't yet willing to acknowledge. We, women, have to do the same for each other. We have to help each other be bolder, be braver, not assume that we are at the mercy of somebody else; we're not. We get to be in partnership with each other as women, and we get to go have these conversations with these men. So I think that's the part that's missing in that. +So back to your question about if men want to get started in this, what do they do? Contact me, yeah, because let's start to have a conversation. There are so many men that know that they want to do different; they just don't know how. And when they do even see a woman come through the door, it's most often as a co-founder. They're not even sure what to do different to attract more of that. +So that's when we get to talk about what is it that they're doing today? Where are they going to look? Who are they calling in? And how does that change their business? Because, at the end of the day, it's not as easy as just investing in women-owned businesses. And I get this question a lot; the question is, "Hey, Stace, are you going to bring us a list of women-owned businesses that we can invest in?" And my response is always with a smile. However, what I say is "No," or "You would have already done that because the list is already available to you." +How they do business will transform. And that's the part that they get to go on this journey with The Global Collective is how do they transform their business as part of that? And that's scary to think. You've done something for so long. You do it really well. You make a lot of money doing it. Yes, there's risk, and as part of this, there's something even greater that would transform how you do business. So it becomes a longer conversation. It's not just about contacting me; I think that's the point I'm trying to get out. [laughter] It's a long-term relationship, and most don't consider that. And I certainly know that women don't either. +CHAD: So, speaking of that, what is the flip side of this if I'm a woman thinking about doing something new or already working on something? What do I do to get started with this and position myself differently or better? +STACY: It's A, building your network. And this is where it gets really uncomfortable for women because the fear of asking for money from men it's a real fear with this perception that they have control. But it's really our own mindset around money and the fact that there's enough of it available. So how do we create diversity in who we talk with, who we talk to? What is it that we are looking to bring to market? Doing some research but not doing so much that you get caught in your own bubble if you will. +I would imagine, Chad, that especially those that you've interviewed and even on your own journey doing this as a founder or even being an executive, it can get kind of lonely. And sometimes we get into that I'm just going to do it, and I'm just going to do it. And I'm going to do it until it's perfect and kind of forget that along the way; we need checkpoints. +So for women, it's the mindset factor of going in and doing something different, which means doing things that they've never done before: getting help, getting a coach, getting a mentor, putting together an advisory board, people that will hold you accountable, maybe even see your blind spots. It also is understanding that if you go pitch to one investment company, or one investment firm, or one investor and they say "No," okay, that doesn't mean that it's the end of the world. They just may not be for you at that time. And there's plenty more out there. +So keep refining. Keep doing your thing. Continue to build your community. Continue to build your voice. And with that, also know that...and this is even part of my journey. You have to be confident in what it is that you're doing. You don't have to be confident in everything that you have to do to get it done, but you have to be grounded in what it is that you're bringing and what it is that you offer. +Because the one thing that isn't talked about enough, and I've heard this enough with investors, is they're actually investing in the person. Yes, they're investing in a business, but they're investing in a person at the end of the day. And that part is overlooked. It's not just bringing something to market to bring it to market if you will. +CHAD: I hear that a lot. I think you're absolutely right. And I think that that gets too close, maybe, to what one of the core problems is. I think if investors are used to investing in people rather than the product and the stream of people that they're used to investing in looks a certain way or behaves a certain way, they're making decisions heuristically, oh, this makes a successful co-founding pair, or this makes us successful founder. And when something shows up that doesn't match the rest of what they see or the heuristic that they have, they really aren't able to think that that will be successful. +STACY: I know myself even being in the rooms that I've been in and doing the work that I did; this journey has been nothing short of a beautiful journey of learning. And the craziest things have happened, as in, they're more difficult than I would have ever imagined mostly because I got in my own way. Or it has required me to learn the nomenclature that's applicable to the investor world, that's very similar to working with capital committees and finance and corporate. However, they use the word slightly. They use either slightly different words or they use them in a different way. +So I've been very lucky. One of my advisors is actually a serial tech entrepreneur who has gone for funding alone half a dozen times, and so even when he and I will sit and talk about things, I continue to learn from him every single time. I said it this way. It would resonate more in this way. Which when you think about that, that doesn't mean I change my story, and my belief, and my confidence, and my grounding, and what it is that I'm bringing; it just means that I'm learning to speak different languages, and/or to be able to assimilate in an easier way. +If what I say doesn't resonate with one investor, I can find another way to describe what it is that I'm attempting to describe in a language that might resonate more with him. It's not just about here's my business. Here's how we're going to make money, and the bottom line number says I'm making revenue. It's about the bigger pieces of it. It's about being confident in your story, what it is that you're offering, what it is that your strengths are, frankly. And I think there's a disconnect there. +Wow, this could be a whole topic of its own, the perception that the founder has to know how to do everything or that we believe that we have to do everything. And then, what's your staying power in all of this? And I think that's even lost on itself. It's not for the faint at heart. And you learn not to take things personal, and you develop a thicker skin. But you still have to remain rooted in your core values. +CHAD: On that note of the misconception or the perception that founders need to know or do everything, there's something that I'm curious about that's sort of an extension of that for you. I've had other guests on the show where they're coming at it from a perspective of a lot of the same issues, but they're focused on getting more founders of color access to investment on both sides of that equation. +The language you use is around gender and men and women, but we know there are people that don't fit into those boxes specifically, either. So how have you chosen what you've decided to focus on? And how do you not get overwhelmed from all the sorts of the landscape and how big this problem is? +STACY: That's a great question because you're right, and I think about that often. I speak more in the norm, the heterosexual norm, genders. I am starting to talk more about the energies that really take away from the men and the women and really speak more about the masculine and the feminine. For me, that piece of it is where I'm staying focused because it's where I know I can do and make the most impact. +However, I believe that when we start to make traction in this way, we also get to make traction from a race and a color...and this is where the corporate culture is starting, I think, to understand and become more well-versed in the masculine and feminine energies. And when you can speak more in that language about the benefits that every single person has regardless of gender, when we get to speak in that language that is more inclusive, then I also believe that we get to include more people, more humans because, at the end of the day, we're all human. That's the one thing that we all [laughs] have in common. We get to speak in that language. +But I think the fact that my end vision...the end goal is so big that to your question about how do I not get lost in the rest of it, I know that will come along as part of it. Even though it may not be the language that I use, I know deep in my heart that creating this opportunity and the shift for people to see those perspectives and for me as a founder to also ensure that within my values, I look to have inclusivity in other ways other than gender myself will be of value. +And in the meantime, those external...the business partnerships, the other elements of my business and who I get to work with or who we get to work with as a collective will include those that are more well-rounded into the language, and I can learn from them. And we get to do these things together, so I do believe that it comes together. I've really led with that so that I don't get so overwhelmed in attempting to accomplish everything. +CHAD: Yeah. And I think the things you're working on feel different than just creating another business or another product like a SaaS product or that kind of thing, but I think a lot of the same principles still apply. And if you come out with something that is meant to be everything to everybody and you're not building from your experience, chances are good you're not going to be as successful as if you could focus and build from your experience and find your niche, and find the people who can help you do what you want to do and have the impact you want to have and then grow from there, as opposed to doing everything all at once. +STACY: Yeah, I agree. +CHAD: But it's tough because it's hard to say, "No, I'm not working on that now," because it is still important. +STACY: It is. The one thing I did, unknowing that this was going to happen but almost three years ago, while in my former life and in my corporate career, I led global teams and worked with different teams across the globe and had a little bit more of that cultural experience. The one thing that I really got hung up on when I first started was figuring out what my niche was because I've had all of that experience. But what I do know is that you get to create your own niche. That was something that took me a really long time to figure out. +I was so centered on conforming to what everyone else told me would be my niche. And I knew that there was something missing. And so part of what I do now, which is the beauty of living where I live now because there's so many different pockets of the culture pieces of it, race, religion, and ethnic backgrounds, I get to continue to build my network and my community with that thought in mind of being able to look for partnerships and have conversations, whether I'm here, whether it's those that are in the U.S. now that I have the attention of. It's all those things, and that just makes it better. +CHAD: Yeah. Well, if this has resonated with people and they want to find out more, they want to get in touch with you, they want to start that conversation, where should they go to do that? +STACY: They will find me...website is globalcollective.global. You will also find me on LinkedIn under Stacy Kehren Idema, as well as on Instagram under stacykehrenidema. +CHAD: Stacy, I really appreciate you joining the show and sharing with us. I appreciate the impact that Global Collective seeks to have. And I wish you all the best, I really do. So, thank you so much. +STACY: Thank you. It's been a pleasure. Thanks, Chad. +CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and I'll see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Stacy Kehren Idema. + + + Stacy Kehren Idema is the Founder and Managing Director of Global Collective, which is revolutionizing how men and women do business.

+ +

Chad talks to Stacy about the work Global Collective does, starting a company based in the U.K, and the differences between doing business in the U.S. and the U.K.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Stacy Kehren Idema, the Founder and Managing Director of Global Collective, which is revolutionizing how men and women do business. Stacy, thank you for joining me.

+ +

STACY: Chad, it is a pleasure. How are you today?

+ +

CHAD: I'm well. I'm well. [laughs] I wasn't going to bring it up, but since you asked, I feel like whenever someone asks that question, I feel like I need to give an honest answer.

+ +

STACY: Of course.

+ +

CHAD: Because I think, so often, we don't answer honestly. We just sort of...so what's going on in my life right now is, unfortunately, even though we got our fourth boosters three weeks ago, my wife tested positive for COVID yesterday.

+ +

STACY: Oh no.

+ +

CHAD: And so she feels fine. She feels mostly fine. But we have kids and everything, so it throws a huge wrench into life right now. We're very fortunate that we've got vaccines, and it'll be mild and everything, but it is a big wrench in our life.

+ +

STACY: It is.

+ +

CHAD: Today, tomorrow, for the next week, so...

+ +

STACY: I'm sorry.

+ +

CHAD: Yeah, so she's in a different part of the house, quarantining away from all of us, and we're hoping for the best.

+ +

STACY: Me too.

+ +

CHAD: We could probably do a whole hour around how life is for all of us right now, coming in this different stage of the pandemic. I hesitate now to ask you, how are you today? [laughs]

+ +

STACY: I'm here in London, so, for me, it's the end of my day. And fortunately, I haven't had COVID in a few months. But I know that experience and being even alone was enough to put a wrench in everything. So I get it.

+ +

CHAD: Yeah. Yeah. Well, let's get back to Global Collective. I gave just a brief snippet. But can you tell people a little bit more about what it is you're actually doing?

+ +

STACY: Yes, I would be honored. So the mission of The Global Collective is to revolutionize really how investment companies invest in female-founded and led businesses, and there are three key areas of that. It's really about changing gender perceptions by actually connecting the unique strengths of each gender. And if you were to even remove the gender piece, it's really talking about the core masculine and the feminine energies of how and what resides in all of us. How can we bring more of the flow and the creativity into business?

+ +

The mission is also designed to eliminate the diversity gap. How can we make things better, more equitable, easier both for the men and the women, you know, going back to the genders? And something that's very near and dear to my heart is really about increasing the financial benefit and, frankly, the mental well-being in business because one thing that we don't talk enough about is the impact that mental health can have not only on our personal life but on business and vice versa. And I think it's starting to come out more and more.

+ +

But with founders, with entrepreneurs, and with executives, that mental illness journey has actually increased, and there are some really interesting statistics on it. So, how can we make it a non-shaming conversation? And how can we actually help each other in this area? So the mission is really about transforming business into something different that I think we're all feeling the need for.

+ +

And how it actually came about was from my 50 years of business and personal experience. I was born into business owners, into a family of business basically. My first husband was a generational business owner and had the hard position to be in, and he had to choose family over business. And then I, in my corporate career, had a really long tenured corporate career.

+ +

I worked 26 years in companies as small as 40 as well as at Fortune 7 companies where we even did new initiatives, new businesses, startups within those. And modestly, most of my time was actually spent with male executives. And I'm a woman in business. I've been in business a really long time. So that's a little bit about the mission and how The Global Collective came about.

+ +

CHAD: You're not the first guest we've had on the show that's talked about these issues. But I'm curious because it is more of a conversation right now. It's something that we've been talking about on the show. Is there something that people in that environment that maybe people still don't realize or that you need to just reiterate over and over again here are the challenges, here are the differences, here's what's happening in the real world right now?

+ +

STACY: Specific to the mental health piece?

+ +

CHAD: Either the mental health piece or just women in business and what it's like for them.

+ +

STACY: Well, I think this is where I love to talk a little bit about the extremes and where those extremes are actually very similar. I believe that men feel like there's this weight of the world on their shoulders and that they have to provide, and serve, and do. And I also believe women do as well, you know, provide for their family, protect for their family. For many women, they may even be a single parent, and with that, they want to be able to go out and provide for themselves and do.

+ +

So you have this desire, this deep desire to do both of those things differently, yet, we're going at it both parallel. And at some point, I think the convergence and really where things start to explode in a beautiful way is when we get to come together. Because if we go about it in a very myopic fashion, we often miss the things that are going on around us that could be a benefit.

+ +

So from a very specific where I'm very focused on in the venture capital and investment space, so much of what has happened over the course of business time, if you will, and when venture capital investments started, which is, you know, I would imagine hundreds and hundreds of years, it has been mostly men that have done that investment. And when you look at the world as it exists today, it is mostly men that...I don't want to say control the money, but they're the ones in that business.

+ +

So when you continue on doing the same thing that you've always done and you don't do anything new, that's telling us a couple of things: you don't know how, or you're afraid. And women, on the other hand, are going about doing their thing, working really, really hard. They're probably even more so working harder because it takes longer for them to earn just as much as a man. If they get funded, it takes longer to get funded, and then they actually get less, but they get to that point.

+ +

And in the meantime, they've had to either endure additional risks to their family by not spending time with their family, or giving up their family and focusing on the business, or focusing solely on their family and giving up the business. So we don't have to do things the way that we're doing them now.

+ +

And the other element, and where the mental health piece comes in, is this thought that we still have to do these things in these linear ways when we can actually come together and learn the beauty of what men do well in business and the beauty of what women do well in business, and figure out how to do it differently.

+ +

CHAD: You mentioned you have a lot of experience working for other companies. So I'm curious, when did you start to feel like you needed to do something to solve this problem and potentially create a new company around it?

+ +

STACY: I've always had a deep desire to do business differently. And what I didn't know at the time in my corporate career was why I didn't feel like I fit in. Having grown up in that business world and knowing what it was like before cell phones and you still had your landline, and a Sunday evening, the telephone rings, and you're sitting at dinner, and your parents dare not answer the phone because the phone will keep ringing until somebody answers. That's just how it happened in the small town I grew up in.

+ +

Knowing that stress and that pain and watching them go through that to being married to a small business owner, and then being in the rooms and the spaces of the people and hearing the stress and the pain, there was this thing that followed me all the way through that knew that business had to be done differently. And I attempted to insert it a lot in my corporate career, and for most, because I wasn't a box-checker, I didn't fit in.

+ +

But the deep desire to finally do it differently was in 2019 when I was made redundant. I had been working and doing coaching on the side, and it was my goal to finally go into business for myself. But in 2020, I divorced myself and decided to take myself on a journey. My children are a little older; they're in their early 20s. And I decided to just kind of come back to myself and understand what did I need to do this business for me and to do with what was deeply passionate within me. And could I do it in another country?

+ +

So in 2021, I spent six months in London and, as part of that journey, did some work for a woman who owns a diversity, & inclusion, and belonging company. And through that experience and listening to her, along with a few other women, talk about that journey to get invested, there was something inside of me that just clicked. It was as if I was reliving sitting in front of capitol committees in my corporate world and listening to the same stories. I'm like, you know, that's just not how things have to happen.

+ +

It was that moment that I knew it wasn't for me just about helping the women in business and helping them scale their business; it was something bigger than that because, in order to do that, to make that change, and to really make a meaningful change, you have to bring the men along for the journey. You have to help them. I know there are many men out there that are all for women-owned businesses, co-founded businesses, women-led businesses, and many of them come to me privately and talk to me about it. And my response is I need you not to tell me; I need you to show me.

+ +

And with that, I've also learned that many of them are afraid. They're afraid to do something different, which tells me that we have to create a space for both the men and the women to thrive. Otherwise, we'll just keep spinning our wheels and doing the same thing over and over again. And it will be far more difficult to get to where we need to get to than how we can get to where we want to go doing it a different way.

+ +

CHAD: So, what does the work Global Collective does look like? Is it coaching? Is it more than that? Is it different than that?

+ +

STACY: My end vision, the bigger vision, is really this end-to-end ecosystem. So there are roughly five elements or five stages of a business idea: start, sustain, scale, and exit. The focus right now is on the scale and working through pilots with investors and with women in business to learn what and how we do it differently. Coaching will be a component of it, the mental health journey and navigating how that works for the founder and the business owner executive also becomes part of it.

+ +

But it also is extensive external networks and communities that we bring into that ecosystem that can support both the investors and their journey and the women in business and their journey. Because the other elements that I have learned along the way is when these investors invest in these all-male-led firms, they don't even know how to help those businesses diversify. They themselves even know and have that challenge.

+ +

Let's take, for example, a woman founder who would like to go on maternity leave. It's more often that she will leave that business because the pressure from the investors to stay in the business and choose business over family is great. Wouldn't it be fantastic if there was a collection of fractional C-suite individuals that get to come in and help that business along on that journey?

+ +

And not only does the female founder get to be part of deciding who and what will be taken on and for how long, but the investor and the business. And then that way, everyone is along on that journey and is in agreement of what's going to happen. So there isn't that pressure to have to choose between business and family for anyone.

+ +

CHAD: I guess that's part of where the collective idea and name comes from.

+ +

STACY: Yeah.

+ +

CHAD: That's great. You mentioned you moved to the UK as part of this journey. Are you working with companies primarily focused on the UK, or are you doing it globally?

+ +

STACY: My focus right now is the U.S. and the UK. So I actually started a brand new business. I secured my own visa. And as part of that visa, I had to start a new business, which was this business. So yeah, the primary locations right now have been UK and U.S. If an opportunity came up in a different country, that would be fantastic, exciting, but that's where I've been focused are in those two areas.

+ +

CHAD: When thoughtbot was getting started in Europe, like most locations that started for us, it was driven by someone who was from there originally and wanted to go back. So when we were getting started, me and my family...my wife was working for a company based in France at the time, and so we were able to go over for the summer. The kids were out of school for the summer. And so we spent several months there, and we loved it.

+ +

And we're fully remote now, but when we had an office there, I would go about once a month. There's probably a small list of places where I could see myself living [laughs], and that's at the top of the list. Was that the case for you? Did something particularly resonate for you?

+ +

STACY: You know, I had never been to Europe. And when I was looking at where I would go, I wanted a place that would be culturally diverse. I wanted a place where I could learn, just even be more immersed in history, and feel safe as a single woman in a foreign country. I'm grateful for my family. They're always very concerned about me, and frankly, so are my boys. Having two young adult men, I worried about them, but now they worry about me has started to come into play.

+ +

For me, it was really about where can I be that would be safe, culturally diverse, and allow me the ability to travel, and to your point, to just go explore new things, really to take a different perspective even outside of the gender diversity piece, the cultural, the language, all of those things? And so this place is home, and I didn't know that when I set off.

+ +

I thought it just would be; I'll go see how it is for three months. And then I wasn't even here a week, and I said three months wouldn't be enough and stayed six. And it was about five weeks into that journey that I said six months won't be enough; I need to be here longer. And then that's when I did more due diligence from the visa standpoint.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: Is there anything that either has stood out to you or surprised you about differences between business in the U.S. and the UK?

+ +

STACY: It's fascinating to see how much they complain. The U.S. and the UK complain about each other and their work standards, yet how much they like what each other does. So I would say some of the biggest differences is that the city truly never seems to sleep, yet they definitely take time away from work and business and are very family-focused. That's probably some of the biggest things that I have learned as part of it, and especially having grown up in the culture that I grew up in, in corporate, where it was very much the grind of the nine-to-five plus.

+ +

So there are some slight differences. I think, if anything, there's just so much more culture and people here that have come from so many other different parts of the world that that's probably the thing that I noticed the most.

+ +

CHAD: Do you think that the work you're doing is ready to be received more or less in either of the places?

+ +

STACY: I think different parts of it are more ready to be received in different parts in each country.

+ +

CHAD: Can you tell me more about that?

+ +

STACY: Yeah, there's probably more heavy gender influences here in the UK, especially with Scandinavian countries that are much more gender equitable. So I think that piece is very much a belief here. And there are other elements that support both sets of parents from a family standpoint in this country. So I think that is more readily received.

+ +

I also do know that women-owned businesses are significantly less here and certainly less from getting funded. I think that's where the U.S. is further ahead in that game. However, the number of businesses that are started by women are significantly more than what they are here. It becomes more about who's louder with certain pieces. I think the U.S. is louder in that area. I think the UK is more open and receptive.

+ +

CHAD: One of the things that I learned about investment in general between the U.S. and the UK is there's not, I mean, it's just not as big of a place as the U.S. The amounts are often less. And I'll say, speaking a little bit more generally, I would say people in the UK, investors in the UK, are a little bit focused on different things. They're maybe a little bit more risk-averse, or they're focused on different markets. So the investment community is a little bit different between the two different places. Does that make the opportunity for founders, particularly women founders, any different between the two different places?

+ +

STACY: From the research that I've done through some interviewing with investors and then the research I've done on my own, there's a lot of little, smaller type of investment for female founders in the U.S. than there is in the UK. But that said, one thing that seems to be very prevalent is how much Europe, in general, talks about London being the epicenter for Europe and investment. You're asking a great question that I hadn't thought about in that framework.

+ +

CHAD: Yeah, and I don't know the answer either [laughs], so...

+ +

STACY: What I do know is in the U.S., there are more female-founded investment companies and female-led. However, I do know many of them are very much sticking to U.S. companies. But what I do know is that the UK is starting to leverage more and work in more partnership with U.S. investment companies.

+ +

CHAD: So if I am an investment firm, chances are that my entire, especially the leaders in the firm, are probably all men, maybe not, but if not all men, then the majority. So if I was sitting in that seat, how do we get started on this journey? Contact you?

+ +

[laughter]

+ +

STACY: Yeah, contact me. [laughs] Honestly, it begins with a conversation. This is the really interesting piece that I don't think that we've yet talked about is women believe that men have control of all the money. And while they may be the ones that are leading more of these investment firms, it's not just up to them, if you will.

+ +

There is this piece of the puzzle that, yes, we have these male-led investment firms, and they have repeatedly invested in mostly male-led businesses. But we have these women who have these beautiful businesses. Women are known for going to market with products and services that have fewer competitors in the market because 70% to 90% of consumer buying decisions around the globe are made by women. And so when they're out there buying and they see a gap, that's where a lot of these women start these businesses is based off of this gap that they see in the market, but they do have the power.

+ +

How can I, as part of this...and even the men because I know I wouldn't be where I am today without the male mentors and influencers in my life encouraging me to be bolder and to be better. And they could see in me some things I wasn't yet willing to acknowledge. We, women, have to do the same for each other. We have to help each other be bolder, be braver, not assume that we are at the mercy of somebody else; we're not. We get to be in partnership with each other as women, and we get to go have these conversations with these men. So I think that's the part that's missing in that.

+ +

So back to your question about if men want to get started in this, what do they do? Contact me, yeah, because let's start to have a conversation. There are so many men that know that they want to do different; they just don't know how. And when they do even see a woman come through the door, it's most often as a co-founder. They're not even sure what to do different to attract more of that.

+ +

So that's when we get to talk about what is it that they're doing today? Where are they going to look? Who are they calling in? And how does that change their business? Because, at the end of the day, it's not as easy as just investing in women-owned businesses. And I get this question a lot; the question is, "Hey, Stace, are you going to bring us a list of women-owned businesses that we can invest in?" And my response is always with a smile. However, what I say is "No," or "You would have already done that because the list is already available to you."

+ +

How they do business will transform. And that's the part that they get to go on this journey with The Global Collective is how do they transform their business as part of that? And that's scary to think. You've done something for so long. You do it really well. You make a lot of money doing it. Yes, there's risk, and as part of this, there's something even greater that would transform how you do business. So it becomes a longer conversation. It's not just about contacting me; I think that's the point I'm trying to get out. [laughter] It's a long-term relationship, and most don't consider that. And I certainly know that women don't either.

+ +

CHAD: So, speaking of that, what is the flip side of this if I'm a woman thinking about doing something new or already working on something? What do I do to get started with this and position myself differently or better?

+ +

STACY: It's A, building your network. And this is where it gets really uncomfortable for women because the fear of asking for money from men it's a real fear with this perception that they have control. But it's really our own mindset around money and the fact that there's enough of it available. So how do we create diversity in who we talk with, who we talk to? What is it that we are looking to bring to market? Doing some research but not doing so much that you get caught in your own bubble if you will.

+ +

I would imagine, Chad, that especially those that you've interviewed and even on your own journey doing this as a founder or even being an executive, it can get kind of lonely. And sometimes we get into that I'm just going to do it, and I'm just going to do it. And I'm going to do it until it's perfect and kind of forget that along the way; we need checkpoints.

+ +

So for women, it's the mindset factor of going in and doing something different, which means doing things that they've never done before: getting help, getting a coach, getting a mentor, putting together an advisory board, people that will hold you accountable, maybe even see your blind spots. It also is understanding that if you go pitch to one investment company, or one investment firm, or one investor and they say "No," okay, that doesn't mean that it's the end of the world. They just may not be for you at that time. And there's plenty more out there.

+ +

So keep refining. Keep doing your thing. Continue to build your community. Continue to build your voice. And with that, also know that...and this is even part of my journey. You have to be confident in what it is that you're doing. You don't have to be confident in everything that you have to do to get it done, but you have to be grounded in what it is that you're bringing and what it is that you offer.

+ +

Because the one thing that isn't talked about enough, and I've heard this enough with investors, is they're actually investing in the person. Yes, they're investing in a business, but they're investing in a person at the end of the day. And that part is overlooked. It's not just bringing something to market to bring it to market if you will.

+ +

CHAD: I hear that a lot. I think you're absolutely right. And I think that that gets too close, maybe, to what one of the core problems is. I think if investors are used to investing in people rather than the product and the stream of people that they're used to investing in looks a certain way or behaves a certain way, they're making decisions heuristically, oh, this makes a successful co-founding pair, or this makes us successful founder. And when something shows up that doesn't match the rest of what they see or the heuristic that they have, they really aren't able to think that that will be successful.

+ +

STACY: I know myself even being in the rooms that I've been in and doing the work that I did; this journey has been nothing short of a beautiful journey of learning. And the craziest things have happened, as in, they're more difficult than I would have ever imagined mostly because I got in my own way. Or it has required me to learn the nomenclature that's applicable to the investor world, that's very similar to working with capital committees and finance and corporate. However, they use the word slightly. They use either slightly different words or they use them in a different way.

+ +

So I've been very lucky. One of my advisors is actually a serial tech entrepreneur who has gone for funding alone half a dozen times, and so even when he and I will sit and talk about things, I continue to learn from him every single time. I said it this way. It would resonate more in this way. Which when you think about that, that doesn't mean I change my story, and my belief, and my confidence, and my grounding, and what it is that I'm bringing; it just means that I'm learning to speak different languages, and/or to be able to assimilate in an easier way.

+ +

If what I say doesn't resonate with one investor, I can find another way to describe what it is that I'm attempting to describe in a language that might resonate more with him. It's not just about here's my business. Here's how we're going to make money, and the bottom line number says I'm making revenue. It's about the bigger pieces of it. It's about being confident in your story, what it is that you're offering, what it is that your strengths are, frankly. And I think there's a disconnect there.

+ +

Wow, this could be a whole topic of its own, the perception that the founder has to know how to do everything or that we believe that we have to do everything. And then, what's your staying power in all of this? And I think that's even lost on itself. It's not for the faint at heart. And you learn not to take things personal, and you develop a thicker skin. But you still have to remain rooted in your core values.

+ +

CHAD: On that note of the misconception or the perception that founders need to know or do everything, there's something that I'm curious about that's sort of an extension of that for you. I've had other guests on the show where they're coming at it from a perspective of a lot of the same issues, but they're focused on getting more founders of color access to investment on both sides of that equation.

+ +

The language you use is around gender and men and women, but we know there are people that don't fit into those boxes specifically, either. So how have you chosen what you've decided to focus on? And how do you not get overwhelmed from all the sorts of the landscape and how big this problem is?

+ +

STACY: That's a great question because you're right, and I think about that often. I speak more in the norm, the heterosexual norm, genders. I am starting to talk more about the energies that really take away from the men and the women and really speak more about the masculine and the feminine. For me, that piece of it is where I'm staying focused because it's where I know I can do and make the most impact.

+ +

However, I believe that when we start to make traction in this way, we also get to make traction from a race and a color...and this is where the corporate culture is starting, I think, to understand and become more well-versed in the masculine and feminine energies. And when you can speak more in that language about the benefits that every single person has regardless of gender, when we get to speak in that language that is more inclusive, then I also believe that we get to include more people, more humans because, at the end of the day, we're all human. That's the one thing that we all [laughs] have in common. We get to speak in that language.

+ +

But I think the fact that my end vision...the end goal is so big that to your question about how do I not get lost in the rest of it, I know that will come along as part of it. Even though it may not be the language that I use, I know deep in my heart that creating this opportunity and the shift for people to see those perspectives and for me as a founder to also ensure that within my values, I look to have inclusivity in other ways other than gender myself will be of value.

+ +

And in the meantime, those external...the business partnerships, the other elements of my business and who I get to work with or who we get to work with as a collective will include those that are more well-rounded into the language, and I can learn from them. And we get to do these things together, so I do believe that it comes together. I've really led with that so that I don't get so overwhelmed in attempting to accomplish everything.

+ +

CHAD: Yeah. And I think the things you're working on feel different than just creating another business or another product like a SaaS product or that kind of thing, but I think a lot of the same principles still apply. And if you come out with something that is meant to be everything to everybody and you're not building from your experience, chances are good you're not going to be as successful as if you could focus and build from your experience and find your niche, and find the people who can help you do what you want to do and have the impact you want to have and then grow from there, as opposed to doing everything all at once.

+ +

STACY: Yeah, I agree.

+ +

CHAD: But it's tough because it's hard to say, "No, I'm not working on that now," because it is still important.

+ +

STACY: It is. The one thing I did, unknowing that this was going to happen but almost three years ago, while in my former life and in my corporate career, I led global teams and worked with different teams across the globe and had a little bit more of that cultural experience. The one thing that I really got hung up on when I first started was figuring out what my niche was because I've had all of that experience. But what I do know is that you get to create your own niche. That was something that took me a really long time to figure out.

+ +

I was so centered on conforming to what everyone else told me would be my niche. And I knew that there was something missing. And so part of what I do now, which is the beauty of living where I live now because there's so many different pockets of the culture pieces of it, race, religion, and ethnic backgrounds, I get to continue to build my network and my community with that thought in mind of being able to look for partnerships and have conversations, whether I'm here, whether it's those that are in the U.S. now that I have the attention of. It's all those things, and that just makes it better.

+ +

CHAD: Yeah. Well, if this has resonated with people and they want to find out more, they want to get in touch with you, they want to start that conversation, where should they go to do that?

+ +

STACY: They will find me...website is globalcollective.global. You will also find me on LinkedIn under Stacy Kehren Idema, as well as on Instagram under stacykehrenidema.

+ +

CHAD: Stacy, I really appreciate you joining the show and sharing with us. I appreciate the impact that Global Collective seeks to have. And I wish you all the best, I really do. So, thank you so much.

+ +

STACY: Thank you. It's been a pleasure. Thanks, Chad.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and I'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Stacy Kehren Idema.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Stacy Kehren Idema is the Founder and Managing Director of Global Collective, which is revolutionizing how men and women do business.

+ +

Chad talks to Stacy about the work Global Collective does, starting a company based in the U.K, and the differences between doing business in the U.S. and the U.K.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Stacy Kehren Idema, the Founder and Managing Director of Global Collective, which is revolutionizing how men and women do business. Stacy, thank you for joining me.

+ +

STACY: Chad, it is a pleasure. How are you today?

+ +

CHAD: I'm well. I'm well. [laughs] I wasn't going to bring it up, but since you asked, I feel like whenever someone asks that question, I feel like I need to give an honest answer.

+ +

STACY: Of course.

+ +

CHAD: Because I think, so often, we don't answer honestly. We just sort of...so what's going on in my life right now is, unfortunately, even though we got our fourth boosters three weeks ago, my wife tested positive for COVID yesterday.

+ +

STACY: Oh no.

+ +

CHAD: And so she feels fine. She feels mostly fine. But we have kids and everything, so it throws a huge wrench into life right now. We're very fortunate that we've got vaccines, and it'll be mild and everything, but it is a big wrench in our life.

+ +

STACY: It is.

+ +

CHAD: Today, tomorrow, for the next week, so...

+ +

STACY: I'm sorry.

+ +

CHAD: Yeah, so she's in a different part of the house, quarantining away from all of us, and we're hoping for the best.

+ +

STACY: Me too.

+ +

CHAD: We could probably do a whole hour around how life is for all of us right now, coming in this different stage of the pandemic. I hesitate now to ask you, how are you today? [laughs]

+ +

STACY: I'm here in London, so, for me, it's the end of my day. And fortunately, I haven't had COVID in a few months. But I know that experience and being even alone was enough to put a wrench in everything. So I get it.

+ +

CHAD: Yeah. Yeah. Well, let's get back to Global Collective. I gave just a brief snippet. But can you tell people a little bit more about what it is you're actually doing?

+ +

STACY: Yes, I would be honored. So the mission of The Global Collective is to revolutionize really how investment companies invest in female-founded and led businesses, and there are three key areas of that. It's really about changing gender perceptions by actually connecting the unique strengths of each gender. And if you were to even remove the gender piece, it's really talking about the core masculine and the feminine energies of how and what resides in all of us. How can we bring more of the flow and the creativity into business?

+ +

The mission is also designed to eliminate the diversity gap. How can we make things better, more equitable, easier both for the men and the women, you know, going back to the genders? And something that's very near and dear to my heart is really about increasing the financial benefit and, frankly, the mental well-being in business because one thing that we don't talk enough about is the impact that mental health can have not only on our personal life but on business and vice versa. And I think it's starting to come out more and more.

+ +

But with founders, with entrepreneurs, and with executives, that mental illness journey has actually increased, and there are some really interesting statistics on it. So, how can we make it a non-shaming conversation? And how can we actually help each other in this area? So the mission is really about transforming business into something different that I think we're all feeling the need for.

+ +

And how it actually came about was from my 50 years of business and personal experience. I was born into business owners, into a family of business basically. My first husband was a generational business owner and had the hard position to be in, and he had to choose family over business. And then I, in my corporate career, had a really long tenured corporate career.

+ +

I worked 26 years in companies as small as 40 as well as at Fortune 7 companies where we even did new initiatives, new businesses, startups within those. And modestly, most of my time was actually spent with male executives. And I'm a woman in business. I've been in business a really long time. So that's a little bit about the mission and how The Global Collective came about.

+ +

CHAD: You're not the first guest we've had on the show that's talked about these issues. But I'm curious because it is more of a conversation right now. It's something that we've been talking about on the show. Is there something that people in that environment that maybe people still don't realize or that you need to just reiterate over and over again here are the challenges, here are the differences, here's what's happening in the real world right now?

+ +

STACY: Specific to the mental health piece?

+ +

CHAD: Either the mental health piece or just women in business and what it's like for them.

+ +

STACY: Well, I think this is where I love to talk a little bit about the extremes and where those extremes are actually very similar. I believe that men feel like there's this weight of the world on their shoulders and that they have to provide, and serve, and do. And I also believe women do as well, you know, provide for their family, protect for their family. For many women, they may even be a single parent, and with that, they want to be able to go out and provide for themselves and do.

+ +

So you have this desire, this deep desire to do both of those things differently, yet, we're going at it both parallel. And at some point, I think the convergence and really where things start to explode in a beautiful way is when we get to come together. Because if we go about it in a very myopic fashion, we often miss the things that are going on around us that could be a benefit.

+ +

So from a very specific where I'm very focused on in the venture capital and investment space, so much of what has happened over the course of business time, if you will, and when venture capital investments started, which is, you know, I would imagine hundreds and hundreds of years, it has been mostly men that have done that investment. And when you look at the world as it exists today, it is mostly men that...I don't want to say control the money, but they're the ones in that business.

+ +

So when you continue on doing the same thing that you've always done and you don't do anything new, that's telling us a couple of things: you don't know how, or you're afraid. And women, on the other hand, are going about doing their thing, working really, really hard. They're probably even more so working harder because it takes longer for them to earn just as much as a man. If they get funded, it takes longer to get funded, and then they actually get less, but they get to that point.

+ +

And in the meantime, they've had to either endure additional risks to their family by not spending time with their family, or giving up their family and focusing on the business, or focusing solely on their family and giving up the business. So we don't have to do things the way that we're doing them now.

+ +

And the other element, and where the mental health piece comes in, is this thought that we still have to do these things in these linear ways when we can actually come together and learn the beauty of what men do well in business and the beauty of what women do well in business, and figure out how to do it differently.

+ +

CHAD: You mentioned you have a lot of experience working for other companies. So I'm curious, when did you start to feel like you needed to do something to solve this problem and potentially create a new company around it?

+ +

STACY: I've always had a deep desire to do business differently. And what I didn't know at the time in my corporate career was why I didn't feel like I fit in. Having grown up in that business world and knowing what it was like before cell phones and you still had your landline, and a Sunday evening, the telephone rings, and you're sitting at dinner, and your parents dare not answer the phone because the phone will keep ringing until somebody answers. That's just how it happened in the small town I grew up in.

+ +

Knowing that stress and that pain and watching them go through that to being married to a small business owner, and then being in the rooms and the spaces of the people and hearing the stress and the pain, there was this thing that followed me all the way through that knew that business had to be done differently. And I attempted to insert it a lot in my corporate career, and for most, because I wasn't a box-checker, I didn't fit in.

+ +

But the deep desire to finally do it differently was in 2019 when I was made redundant. I had been working and doing coaching on the side, and it was my goal to finally go into business for myself. But in 2020, I divorced myself and decided to take myself on a journey. My children are a little older; they're in their early 20s. And I decided to just kind of come back to myself and understand what did I need to do this business for me and to do with what was deeply passionate within me. And could I do it in another country?

+ +

So in 2021, I spent six months in London and, as part of that journey, did some work for a woman who owns a diversity, & inclusion, and belonging company. And through that experience and listening to her, along with a few other women, talk about that journey to get invested, there was something inside of me that just clicked. It was as if I was reliving sitting in front of capitol committees in my corporate world and listening to the same stories. I'm like, you know, that's just not how things have to happen.

+ +

It was that moment that I knew it wasn't for me just about helping the women in business and helping them scale their business; it was something bigger than that because, in order to do that, to make that change, and to really make a meaningful change, you have to bring the men along for the journey. You have to help them. I know there are many men out there that are all for women-owned businesses, co-founded businesses, women-led businesses, and many of them come to me privately and talk to me about it. And my response is I need you not to tell me; I need you to show me.

+ +

And with that, I've also learned that many of them are afraid. They're afraid to do something different, which tells me that we have to create a space for both the men and the women to thrive. Otherwise, we'll just keep spinning our wheels and doing the same thing over and over again. And it will be far more difficult to get to where we need to get to than how we can get to where we want to go doing it a different way.

+ +

CHAD: So, what does the work Global Collective does look like? Is it coaching? Is it more than that? Is it different than that?

+ +

STACY: My end vision, the bigger vision, is really this end-to-end ecosystem. So there are roughly five elements or five stages of a business idea: start, sustain, scale, and exit. The focus right now is on the scale and working through pilots with investors and with women in business to learn what and how we do it differently. Coaching will be a component of it, the mental health journey and navigating how that works for the founder and the business owner executive also becomes part of it.

+ +

But it also is extensive external networks and communities that we bring into that ecosystem that can support both the investors and their journey and the women in business and their journey. Because the other elements that I have learned along the way is when these investors invest in these all-male-led firms, they don't even know how to help those businesses diversify. They themselves even know and have that challenge.

+ +

Let's take, for example, a woman founder who would like to go on maternity leave. It's more often that she will leave that business because the pressure from the investors to stay in the business and choose business over family is great. Wouldn't it be fantastic if there was a collection of fractional C-suite individuals that get to come in and help that business along on that journey?

+ +

And not only does the female founder get to be part of deciding who and what will be taken on and for how long, but the investor and the business. And then that way, everyone is along on that journey and is in agreement of what's going to happen. So there isn't that pressure to have to choose between business and family for anyone.

+ +

CHAD: I guess that's part of where the collective idea and name comes from.

+ +

STACY: Yeah.

+ +

CHAD: That's great. You mentioned you moved to the UK as part of this journey. Are you working with companies primarily focused on the UK, or are you doing it globally?

+ +

STACY: My focus right now is the U.S. and the UK. So I actually started a brand new business. I secured my own visa. And as part of that visa, I had to start a new business, which was this business. So yeah, the primary locations right now have been UK and U.S. If an opportunity came up in a different country, that would be fantastic, exciting, but that's where I've been focused are in those two areas.

+ +

CHAD: When thoughtbot was getting started in Europe, like most locations that started for us, it was driven by someone who was from there originally and wanted to go back. So when we were getting started, me and my family...my wife was working for a company based in France at the time, and so we were able to go over for the summer. The kids were out of school for the summer. And so we spent several months there, and we loved it.

+ +

And we're fully remote now, but when we had an office there, I would go about once a month. There's probably a small list of places where I could see myself living [laughs], and that's at the top of the list. Was that the case for you? Did something particularly resonate for you?

+ +

STACY: You know, I had never been to Europe. And when I was looking at where I would go, I wanted a place that would be culturally diverse. I wanted a place where I could learn, just even be more immersed in history, and feel safe as a single woman in a foreign country. I'm grateful for my family. They're always very concerned about me, and frankly, so are my boys. Having two young adult men, I worried about them, but now they worry about me has started to come into play.

+ +

For me, it was really about where can I be that would be safe, culturally diverse, and allow me the ability to travel, and to your point, to just go explore new things, really to take a different perspective even outside of the gender diversity piece, the cultural, the language, all of those things? And so this place is home, and I didn't know that when I set off.

+ +

I thought it just would be; I'll go see how it is for three months. And then I wasn't even here a week, and I said three months wouldn't be enough and stayed six. And it was about five weeks into that journey that I said six months won't be enough; I need to be here longer. And then that's when I did more due diligence from the visa standpoint.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: Is there anything that either has stood out to you or surprised you about differences between business in the U.S. and the UK?

+ +

STACY: It's fascinating to see how much they complain. The U.S. and the UK complain about each other and their work standards, yet how much they like what each other does. So I would say some of the biggest differences is that the city truly never seems to sleep, yet they definitely take time away from work and business and are very family-focused. That's probably some of the biggest things that I have learned as part of it, and especially having grown up in the culture that I grew up in, in corporate, where it was very much the grind of the nine-to-five plus.

+ +

So there are some slight differences. I think, if anything, there's just so much more culture and people here that have come from so many other different parts of the world that that's probably the thing that I noticed the most.

+ +

CHAD: Do you think that the work you're doing is ready to be received more or less in either of the places?

+ +

STACY: I think different parts of it are more ready to be received in different parts in each country.

+ +

CHAD: Can you tell me more about that?

+ +

STACY: Yeah, there's probably more heavy gender influences here in the UK, especially with Scandinavian countries that are much more gender equitable. So I think that piece is very much a belief here. And there are other elements that support both sets of parents from a family standpoint in this country. So I think that is more readily received.

+ +

I also do know that women-owned businesses are significantly less here and certainly less from getting funded. I think that's where the U.S. is further ahead in that game. However, the number of businesses that are started by women are significantly more than what they are here. It becomes more about who's louder with certain pieces. I think the U.S. is louder in that area. I think the UK is more open and receptive.

+ +

CHAD: One of the things that I learned about investment in general between the U.S. and the UK is there's not, I mean, it's just not as big of a place as the U.S. The amounts are often less. And I'll say, speaking a little bit more generally, I would say people in the UK, investors in the UK, are a little bit focused on different things. They're maybe a little bit more risk-averse, or they're focused on different markets. So the investment community is a little bit different between the two different places. Does that make the opportunity for founders, particularly women founders, any different between the two different places?

+ +

STACY: From the research that I've done through some interviewing with investors and then the research I've done on my own, there's a lot of little, smaller type of investment for female founders in the U.S. than there is in the UK. But that said, one thing that seems to be very prevalent is how much Europe, in general, talks about London being the epicenter for Europe and investment. You're asking a great question that I hadn't thought about in that framework.

+ +

CHAD: Yeah, and I don't know the answer either [laughs], so...

+ +

STACY: What I do know is in the U.S., there are more female-founded investment companies and female-led. However, I do know many of them are very much sticking to U.S. companies. But what I do know is that the UK is starting to leverage more and work in more partnership with U.S. investment companies.

+ +

CHAD: So if I am an investment firm, chances are that my entire, especially the leaders in the firm, are probably all men, maybe not, but if not all men, then the majority. So if I was sitting in that seat, how do we get started on this journey? Contact you?

+ +

[laughter]

+ +

STACY: Yeah, contact me. [laughs] Honestly, it begins with a conversation. This is the really interesting piece that I don't think that we've yet talked about is women believe that men have control of all the money. And while they may be the ones that are leading more of these investment firms, it's not just up to them, if you will.

+ +

There is this piece of the puzzle that, yes, we have these male-led investment firms, and they have repeatedly invested in mostly male-led businesses. But we have these women who have these beautiful businesses. Women are known for going to market with products and services that have fewer competitors in the market because 70% to 90% of consumer buying decisions around the globe are made by women. And so when they're out there buying and they see a gap, that's where a lot of these women start these businesses is based off of this gap that they see in the market, but they do have the power.

+ +

How can I, as part of this...and even the men because I know I wouldn't be where I am today without the male mentors and influencers in my life encouraging me to be bolder and to be better. And they could see in me some things I wasn't yet willing to acknowledge. We, women, have to do the same for each other. We have to help each other be bolder, be braver, not assume that we are at the mercy of somebody else; we're not. We get to be in partnership with each other as women, and we get to go have these conversations with these men. So I think that's the part that's missing in that.

+ +

So back to your question about if men want to get started in this, what do they do? Contact me, yeah, because let's start to have a conversation. There are so many men that know that they want to do different; they just don't know how. And when they do even see a woman come through the door, it's most often as a co-founder. They're not even sure what to do different to attract more of that.

+ +

So that's when we get to talk about what is it that they're doing today? Where are they going to look? Who are they calling in? And how does that change their business? Because, at the end of the day, it's not as easy as just investing in women-owned businesses. And I get this question a lot; the question is, "Hey, Stace, are you going to bring us a list of women-owned businesses that we can invest in?" And my response is always with a smile. However, what I say is "No," or "You would have already done that because the list is already available to you."

+ +

How they do business will transform. And that's the part that they get to go on this journey with The Global Collective is how do they transform their business as part of that? And that's scary to think. You've done something for so long. You do it really well. You make a lot of money doing it. Yes, there's risk, and as part of this, there's something even greater that would transform how you do business. So it becomes a longer conversation. It's not just about contacting me; I think that's the point I'm trying to get out. [laughter] It's a long-term relationship, and most don't consider that. And I certainly know that women don't either.

+ +

CHAD: So, speaking of that, what is the flip side of this if I'm a woman thinking about doing something new or already working on something? What do I do to get started with this and position myself differently or better?

+ +

STACY: It's A, building your network. And this is where it gets really uncomfortable for women because the fear of asking for money from men it's a real fear with this perception that they have control. But it's really our own mindset around money and the fact that there's enough of it available. So how do we create diversity in who we talk with, who we talk to? What is it that we are looking to bring to market? Doing some research but not doing so much that you get caught in your own bubble if you will.

+ +

I would imagine, Chad, that especially those that you've interviewed and even on your own journey doing this as a founder or even being an executive, it can get kind of lonely. And sometimes we get into that I'm just going to do it, and I'm just going to do it. And I'm going to do it until it's perfect and kind of forget that along the way; we need checkpoints.

+ +

So for women, it's the mindset factor of going in and doing something different, which means doing things that they've never done before: getting help, getting a coach, getting a mentor, putting together an advisory board, people that will hold you accountable, maybe even see your blind spots. It also is understanding that if you go pitch to one investment company, or one investment firm, or one investor and they say "No," okay, that doesn't mean that it's the end of the world. They just may not be for you at that time. And there's plenty more out there.

+ +

So keep refining. Keep doing your thing. Continue to build your community. Continue to build your voice. And with that, also know that...and this is even part of my journey. You have to be confident in what it is that you're doing. You don't have to be confident in everything that you have to do to get it done, but you have to be grounded in what it is that you're bringing and what it is that you offer.

+ +

Because the one thing that isn't talked about enough, and I've heard this enough with investors, is they're actually investing in the person. Yes, they're investing in a business, but they're investing in a person at the end of the day. And that part is overlooked. It's not just bringing something to market to bring it to market if you will.

+ +

CHAD: I hear that a lot. I think you're absolutely right. And I think that that gets too close, maybe, to what one of the core problems is. I think if investors are used to investing in people rather than the product and the stream of people that they're used to investing in looks a certain way or behaves a certain way, they're making decisions heuristically, oh, this makes a successful co-founding pair, or this makes us successful founder. And when something shows up that doesn't match the rest of what they see or the heuristic that they have, they really aren't able to think that that will be successful.

+ +

STACY: I know myself even being in the rooms that I've been in and doing the work that I did; this journey has been nothing short of a beautiful journey of learning. And the craziest things have happened, as in, they're more difficult than I would have ever imagined mostly because I got in my own way. Or it has required me to learn the nomenclature that's applicable to the investor world, that's very similar to working with capital committees and finance and corporate. However, they use the word slightly. They use either slightly different words or they use them in a different way.

+ +

So I've been very lucky. One of my advisors is actually a serial tech entrepreneur who has gone for funding alone half a dozen times, and so even when he and I will sit and talk about things, I continue to learn from him every single time. I said it this way. It would resonate more in this way. Which when you think about that, that doesn't mean I change my story, and my belief, and my confidence, and my grounding, and what it is that I'm bringing; it just means that I'm learning to speak different languages, and/or to be able to assimilate in an easier way.

+ +

If what I say doesn't resonate with one investor, I can find another way to describe what it is that I'm attempting to describe in a language that might resonate more with him. It's not just about here's my business. Here's how we're going to make money, and the bottom line number says I'm making revenue. It's about the bigger pieces of it. It's about being confident in your story, what it is that you're offering, what it is that your strengths are, frankly. And I think there's a disconnect there.

+ +

Wow, this could be a whole topic of its own, the perception that the founder has to know how to do everything or that we believe that we have to do everything. And then, what's your staying power in all of this? And I think that's even lost on itself. It's not for the faint at heart. And you learn not to take things personal, and you develop a thicker skin. But you still have to remain rooted in your core values.

+ +

CHAD: On that note of the misconception or the perception that founders need to know or do everything, there's something that I'm curious about that's sort of an extension of that for you. I've had other guests on the show where they're coming at it from a perspective of a lot of the same issues, but they're focused on getting more founders of color access to investment on both sides of that equation.

+ +

The language you use is around gender and men and women, but we know there are people that don't fit into those boxes specifically, either. So how have you chosen what you've decided to focus on? And how do you not get overwhelmed from all the sorts of the landscape and how big this problem is?

+ +

STACY: That's a great question because you're right, and I think about that often. I speak more in the norm, the heterosexual norm, genders. I am starting to talk more about the energies that really take away from the men and the women and really speak more about the masculine and the feminine. For me, that piece of it is where I'm staying focused because it's where I know I can do and make the most impact.

+ +

However, I believe that when we start to make traction in this way, we also get to make traction from a race and a color...and this is where the corporate culture is starting, I think, to understand and become more well-versed in the masculine and feminine energies. And when you can speak more in that language about the benefits that every single person has regardless of gender, when we get to speak in that language that is more inclusive, then I also believe that we get to include more people, more humans because, at the end of the day, we're all human. That's the one thing that we all [laughs] have in common. We get to speak in that language.

+ +

But I think the fact that my end vision...the end goal is so big that to your question about how do I not get lost in the rest of it, I know that will come along as part of it. Even though it may not be the language that I use, I know deep in my heart that creating this opportunity and the shift for people to see those perspectives and for me as a founder to also ensure that within my values, I look to have inclusivity in other ways other than gender myself will be of value.

+ +

And in the meantime, those external...the business partnerships, the other elements of my business and who I get to work with or who we get to work with as a collective will include those that are more well-rounded into the language, and I can learn from them. And we get to do these things together, so I do believe that it comes together. I've really led with that so that I don't get so overwhelmed in attempting to accomplish everything.

+ +

CHAD: Yeah. And I think the things you're working on feel different than just creating another business or another product like a SaaS product or that kind of thing, but I think a lot of the same principles still apply. And if you come out with something that is meant to be everything to everybody and you're not building from your experience, chances are good you're not going to be as successful as if you could focus and build from your experience and find your niche, and find the people who can help you do what you want to do and have the impact you want to have and then grow from there, as opposed to doing everything all at once.

+ +

STACY: Yeah, I agree.

+ +

CHAD: But it's tough because it's hard to say, "No, I'm not working on that now," because it is still important.

+ +

STACY: It is. The one thing I did, unknowing that this was going to happen but almost three years ago, while in my former life and in my corporate career, I led global teams and worked with different teams across the globe and had a little bit more of that cultural experience. The one thing that I really got hung up on when I first started was figuring out what my niche was because I've had all of that experience. But what I do know is that you get to create your own niche. That was something that took me a really long time to figure out.

+ +

I was so centered on conforming to what everyone else told me would be my niche. And I knew that there was something missing. And so part of what I do now, which is the beauty of living where I live now because there's so many different pockets of the culture pieces of it, race, religion, and ethnic backgrounds, I get to continue to build my network and my community with that thought in mind of being able to look for partnerships and have conversations, whether I'm here, whether it's those that are in the U.S. now that I have the attention of. It's all those things, and that just makes it better.

+ +

CHAD: Yeah. Well, if this has resonated with people and they want to find out more, they want to get in touch with you, they want to start that conversation, where should they go to do that?

+ +

STACY: They will find me...website is globalcollective.global. You will also find me on LinkedIn under Stacy Kehren Idema, as well as on Instagram under stacykehrenidema.

+ +

CHAD: Stacy, I really appreciate you joining the show and sharing with us. I appreciate the impact that Global Collective seeks to have. And I wish you all the best, I really do. So, thank you so much.

+ +

STACY: Thank you. It's been a pleasure. Thanks, Chad.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and I'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Stacy Kehren Idema.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+1W6bdvpt + + ]]> + + Chad Pytel + Stacy Kehren Idema + + + 453: Greenpixie with John Ridd + https://podcast.thoughtbot.com/453 + fe857ba5-2b1a-4851-a7d8-e6a93cfeeca8 + Thu, 15 Dec 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + John Ridd is the Co-Founder and CEO of Greenpixie, which is building solutions to reveal and reduce cloud emissions. + +Chad and Will talk to John about giving a clearer view of AWS emissions down to the service level, why cloud emissions are a much bigger sustainability issue than most people realize, and how this will be the next big issue of the climate crisis. + 28:33 + no + + + John Ridd is the Co-Founder and CEO of Greenpixie, which is building solutions to reveal and reduce cloud emissions. +Chad and Will talk to John about giving a clearer view of AWS emissions down to the service level, why cloud emissions are a much bigger sustainability issue than most people realize, and how this will be the next big issue of the climate crisis. +Greenpixie (https://greenpixie.com/) +Follow Greenpixie on Twitter (https://twitter.com/greenpixiehq), Instagram (https://www.instagram.com/greenpixiehq/), or LinkedIn (https://www.linkedin.com/company/greenpixie/). +Follow John on LinkedIn (https://www.linkedin.com/in/john-c-ridd/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. +WILL: And I'm your other host, Will Larry. And with us today is John Ridd, the Co-Founder, and CEO of Greenpixie, which is building solutions to reveal and reduce the emissions of the cloud. +CHAD: John, thank you so much for joining us. I have to admit that as a developer, this is something that I've been thinking a lot about recently. We practice test-driven development. We run continuous integration, even the things that we have running in the cloud in terms of the websites that we run and that kind of thing. +I'm also just really becoming aware of when I make a new branch in everything that I run, and I'm making a code change and pushing that up to GitHub; it then kicks off a build every single time any team member is doing that. And I can just see the impact that even just a single software product can have potentially on our environment. And I've started to become more and more guilty about that. So I'm excited to talk to you about how [laughs] we might be able to fix that problem. +JOHN: Yeah, absolutely. I think one of the big reasons that we've really seen the opportunity in the cloud emissions space is this disconnect really between how developers are incentivized to think, and rightfully so. They need to build and innovate at all costs; that's what drives the innovation in any tech company or any company. But the sustainability way of thinking and thinking, what am I building? What servers am I using and turning on? Just hasn't been in the conversation with developers. And they're the ones who are making these decisions using cloud providers to build out the products that the company needs. So it's great to hear that you're now aware of this impending issue from development. +CHAD: So I'm excited to dig more into the product. But I'm curious, you were doing digital marketing before starting Greenpixie, right? +JOHN: Yeah, I ran my own marketing consultancy, worked with a number of companies, big and small. And where I found my knack was sort of demand generation; really, starting off projects from nothing is what I've always done. It's clear now that...so Greenpixie was a bootstrap startup. Really using that ability to at least come up with an idea and take it from zero to one, bring demand to an issue, that's how Greenpixie started. +And it actually started with the head of engineering, Chris, who I met at my co-working space, and really we traded ideas through a hackathon on the weekend. And I had this idea when it came to website emissions and just knew that there was a software and a product play there. And what we do is connect into Google Analytics, put it through some carbon algorithms, and give them the ability to see how much digital carbon the website is producing. And from my marketing background, we've developed our own marketing, internal marketing software, which is a combination of we've built our own email servers with a high inbox. And we do semantic web scraping to find relevant prospects in the sustainability space. +So we built the MVP and put this idea for Greenpixie out to the world, and the overwhelming response that we got was people being shocked at the idea of digital carbon and how their digital operations do have a sustainability impact. It really gave us the confidence to think there's demand for this idea of emissions. And since then, we've now moved into carbon emissions down the carbon rabbit hole. But my marketing experience explains how it started in the first place. +CHAD: So how does...sometimes when faced with, I think, all kinds of climate issues, people can feel overwhelmed or helpless or feeling like what do I do as an individual to have an impact? So what does Greenpixie and Cloud NetZero enable an individual, team, or company, or developer to actually see and do? +JOHN: Cloud NetZero connects into the leading cloud providers. So at this stage, we can give a clearer view of your AWS emissions down to the service level. And this is a key first step. So we take a you can't affect what you can't measure philosophy. And that was a big, big step for us. And by cutting into the cost and usage reports and putting it through our carbon algorithms, we can then get visibility to engineers. +So everything you're building up in the cloud, we then give a full transparent view of the associated emissions that are being created from that by using our algorithms and methodology to convert the electricity used from the computation and storage and take into account the geographic location of the data centers of which you're using. As you can imagine, there are different carbon intensities in different countries during different times of the day. +So we actually hook up into an API that gives us this carbon intensity data down to the hour. So we give a really comprehensive view of your carbon emissions footprint, which is what we consider the gold standard in sustainability. Because what makes the digital vertical so unique within sustainability is we've got data coming out of our ears. [chuckles] The data is there to connect into the software, so we can give this crystal clear picture. +Whereas in other branches of sustainability, if you're into supply chains, et cetera, you've got real-world problems that you have to put real-time into. So that's the first step that we do is giving you this clear picture of your emissions. And from that, we then proceed to suggest reduction strategies to reduce those emissions. +WILL: John, I'll be honest. Before getting on the podcast with you, I never thought about my cloud emissions as a developer. Now I'm seeing, wow, there is a lot there with that. On your Twitter, I saw this stat: imagine driving 1.3 billion miles all the way to Saturn. The carbon you would release would be about the same as the amount from all of these streams of Netflix's top 10 shows in the month that were released, 6 billion hours of viewing. I'm just mind-blown just thinking about that. For someone who is just now thinking about my cloud emissions, what would you tell me as a developer or any CEO that's listening to the podcast? +JOHN: So yeah, you're right. This is a much bigger sustainability issue than most people realize. Currently, it's estimated around 2% of global emissions are from the cloud and data centers use, which puts it near the level of the aviation industry. And because the cloud is so esoteric and it's called the cloud, you think it's light and fluffy, and you're like, okay, it's over there; it's fine. +But there's a hard infrastructure that makes up the digital world that we enjoy, and that's thousands of racks of servers. That's so much gallons, like, millions of gallons of water used to cool these data centers. And because of this, there are countries such as Ireland and Singapore that have now begun to ban further construction of data centers. Because in Ireland, over 10% of the grid is taken up by these, well, I believe there was an article in The Telegraph that referred to these data centers as vampires, [laughs] vampires on the grid sucking all this energy up. +And the reason that this exists is it comes down to a company level or to a developer level. You're renting these data centers in order to grow your operations. And this aggregate demand goes straight into why these data centers exist and how much electricity they're using. But what you can do for a certain output...because we're a tech company and we love tech. And that makes us different to maybe some sustainability, really hardline sustainability environmental point of view because we actually think you can achieve the same output for 40% less energy use. +So there's waste that is pretty rife across the cloud space, and that also comes with the amount of money spent on the cloud. There can be servers that have been left turned on that are no longer used. There can be non-essential computation that could be moved to low carbon intensity hours of the day. And there's so much that can be done and still basically enjoy and build the tech that we all aspire to build. +CHAD: I'm going to resist taking a tangent into What We Do in the Shadows and the energy vampire, or we can call them Colin, I guess, instead of vampires. +JOHN: Yeah, yeah. +[laughter] +CHAD: So I used the calculator that you have on the website on our website, thoughtbot.com. I was pleased to see that it produces less carbon than 95% of websites. What goes into that calculation, though? +JOHN: So what we do on the estimator, on the webpage, the calculator, so we take into account whether your server being used is green or standard based on requesting that homepage. And then, really, there's a lot of overlap with PageSpeed optimization, rightfully, so the heavier the web pages, the more images. And if it's been coded lazily and it's heavy, which it hasn't been in your case, which I'm sure you're really happy about, that basically does have an effect on the electricity used in order to serve the website. And we also provide a website carbon report, which goes a step further and takes into account your Google Analytics, which goes for all your pageviews and takes into account some other factors too. +CHAD: When you're looking at the carbon footprint of a website, am I understanding that you're also taking into account the carbon footprint of the people viewing what it takes to view the website on the client too? +JOHN: It's very interesting, and we are going into the client side of emissions. That is definitely something that we're looking into and continue to do so. But now we focus more on the cloud. We stuck with websites as our main priority, that would mean the next step was going into client side, and it can, and that logic does go up. And it shows the ability of measuring sustainability impact when it comes to digital because, of course, you can get device information from Google Analytics, and that can then be used to give an accurate prediction. But that is something that we would definitely consider doing in the future. But you see the potential. It can go in all these different directions. +CHAD: A little bit of a meta question, then, so the calculator is running on people's websites. What is the carbon footprint of running the calculator on the site? [laughs] +JOHN: Well, that's the thing; we do have transparency of our own operations. So we're a seed-stage startup, and our operations might get a lot bigger. But for now, and given the sustainable approach, we take with how we run our cloud and run these tools, around two tons of CO2 we produce in a month from operations. But looking into other tech companies, you can imagine how AWS can get when it comes to the bigger companies and everything in between. It can really be hundreds or tens of tons. That has been currently unaccounted for and not addressed, which put into perspective, it's acting on your carbon emissions as an individual. +And let's say you're a developer who has the power to do this. You can have the effect of like ten times going vegan or not using air travel. So it's just really we really love the idea of combating carbon emissions, and developers, particularly combating carbon emissions is, using your unique skills in order to fight the climate crisis in a way that a non-technical person couldn't. +CHAD: So what are some of the things that you're doing as a company to solve that for yourself? Are there particular cloud hosting providers that are actually better than others? +JOHN: Yes, it does vary. So there are the big cloud providers, and we are on AWS due to the startup credit scheme, which, as you can imagine, that's very beneficial when you're starting from a bootstrapped model. And within AWS, you can actually...so choosing the geographic location of where you're spinning up the servers is one way you can reduce that. So our servers are in Ireland. So we're part of that issue actually, now that I think about it, because they have a relatively low carbon intensity. And that's one way that we ensure the carbon we're using is minimized. But there's a whole spectrum. +So if you wanted to go at all costs and convenience and costs are out the window, there are niche carbon fighters, which actually are off-grid renewable power data centers. If you have the means, that is the optimum you can go in terms of the carbon intensity. But in terms of how we build, so just the typical making sure that we're turning off products, features, and servers that we don't use and being mindful of that, putting non-essential compute to low-carbon intensity periods in the day and just minimizing costs and using computation for a certain output is how we take that philosophy. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +WILL: On your website, I see that 127 billion is wasted in idle cloud spend, so obviously, one of your goals is to reduce that amount. What other goals is your company looking forward to solving? +JOHN: I would say our main goal is to reduce millions of tons of needless cloud emissions using scalable software. That is our guiding light. But within that, it correlates largely with cost savings for companies. So we could actually save companies millions of pounds as well or millions of dollars. So I'm from the UK; [laughter] I went for pounds. Yeah, that's the big push; that's our guiding light. +And we really want to be the torchbearers for digital sustainability as an idea. So having the awareness, we take responsibility for driving awareness for the issue also. As a team, we have a great combination of technical minds but also creative and marketing, getting the message out there and demystifying carbon emissions. So it's a technical issue because there's a technical issue when you dig into it. But we want to put it in a way that a non-technical decision maker in the C-suite would understand the issue in terms of the effects that you can have as a company in a sustainability drive. +CHAD: So you mentioned you got started from that original hackathon idea. And how did things progress for you from there? You now have a team of people working. Did you end up taking some investment in order to continue on? +JOHN: We did. We actually started it...so we started it as a passion project from that hackathon, saw the potential. I saw a small business opportunity through the website measuring. And we saw there was demand out there, so we started there. Then we saw it as a side project and continued to see potential and made the call to basically...the initial team was three of us. We went full-time and said let's see what we can do with this. +Then I came from a marketing consultancy...I self-funded it to the means that I could for the first six months. It's an interesting experience when you get possessed by an idea, and it's just I need to see this through. I see the potential. It's for a great cause. I think there's a big business opportunity here. And then, really, it came to that point, and we did start going down the investment route. +We were part of an incubator associated with the University of Cambridge called Carbon13. It's a really interesting program where they put together experts in climate science, the developers. And you come together to try and come up with these big ideas to basically reduce millions of tons of emissions as a startup. And there was plenty. There was, for example, there was offsetting companies, there was carbon credit startups, everything you can imagine. +And it was there that we got put on the investment journey because at the end of the program, you get what was an £80,000 investment to then move on and then go down the VC route. Turns out we didn't get the investment despite us being one of the favorites. It didn't work out for various reasons. And then we were in a situation where I was like, okay, we need to get this investment in order to keep going and scaling the team. +And we ended up being VC-backed for our pre-seed from a company in London called Ascension. So we did a £250,000 pre-seed round to get things going. And that's why we have a team who is now working on this full-time. And it's been a bit of a journey, but the trials and tribulations of startups is just the game. And now we're looking to get our seed round. We're hoping to be closing by the end of the year. +CHAD: Congratulations on the progress so far. Why do you think Ascension was interested in investing in you? +JOHN: So, really, at pre-seed stage, I've talked to VCs and said market, founder, co-founders, anything else is just too early to really know with any certainty. So I think they saw that we were committed, enthusiastic about the idea. Will, the other co-founder, and CTO, is a full-stack developer. It's his second startup. And with my demand generation background, we thought we were a good fit. +But really, I think a lot of time and thinking, and commitment has gone into (blood, sweat, and tears) has gone into thinking how we can create a product or software company that addresses carbon emissions. And I think investors have a good radar of when people are really committed, and that's what we were. +WILL: You've recently done a soft launch of Cloud NetZero. Can you give me more information around that? +JOHN: Yeah, absolutely. We did our soft launch, so this is after the pre-seed investment. We got the 250,000. And we built the product that we laid out in that pitch, which was a software that integrates to AWS and gives you this granular breakdown of your emissions by service. And that was what we presented on our soft launch. We did an in-person event, which we just got a small room and managed to...so around 50 people turned up, which we're pretty proud of. And people do seem to be attracted to this idea. We use my marketing background [laughs] to kind of bolster those numbers. +But it was a really great experience. So it was actually on the side of our co-working space where we did a hackathon originally. And it was a bit of an experience, quite a heartwarming experience that everyone has come together. I'm just like, oh, it was in that room that it started as an idea, and now 50 people coming from VC backgrounds, from sustainability, from tech are all coming together. And considering we started in COVID times, to have everyone in the room was just great. So it was great. Yeah, thanks for highlighting it. I really have good memories of that soft launch. +CHAD: So people can get a demo and sign up now. +JOHN: Yeah, absolutely. So the product is up and running. It went from idea to reality which we're very, very proud of the product team for hitting it on time as well. So we did a 100-day push, and on the 100th day, it was ready for us. And we actually got a big update Monday next week, which is going to be the V 1.1. I call it V2, and then my CTO says, "No, it's V 1.1." [laughter] +CHAD: Oh, you need to make your CTO understand that for marketing purposes, you need to make your version numbers bigger. +JOHN: Yeah, yeah, he's just like, "If you think that's V2, you don't know what you're saying." [laughter] You can contact us, and we can basically show you the onboarding to get you closer to your cloud provider. And you can have a crystal clear picture of your carbon emissions. And the companies we're talking to now so software companies, so pretty well-known brands. We're now in conversation with as well as just your heavy-duty tech companies. And they're really our ideal client we're looking to now because they have a large amount of carbon emissions, and they want to be really measuring them for their sustainability initiatives. +They are actually going to be required to...from the beginning of next year, there's regulation creeping in that's going to make companies measure their Scope 3 emissions, and we have the product to do that. And once we go over that first stage of measurement, then the next step is giving you recommendations to reduce it ultimately, and that will be both in cloud emissions and costs. So we actually are a cost-saving software ultimately because we can highlight wasted cloud spend, and there's a lot of it in these tech companies. +CHAD: So you've launched. It sounds like you're focused on getting customers and making sales. How does the pricing work for the product? +JOHN: At the moment, we are charging 10K a year to use the software. This is for...so it would be your mid-sized tech company is really who that's aimed for. Anything that goes into really heavy-duty cloud emissions analysis would be probably just down the road just because the complication gets considerably...there's a lot more computing that we need to do on our end, which there are costs associated with that. And there's a lot more, as you can imagine, a lot more hand-holding in order to get integrated and that type of thing. So the pricing would be larger for those more developed companies who have huge AWS accounts. +CHAD: A lot of companies' pricing is one of the things that they struggle with early on. I assume you'll learn, and your pricing model will change. But is there something that particularly you weren't sure about when it came to the pricing? +JOHN: So the pricing it's really what we're seeing from other parallel softwares on the market more towards the cost reduction side of the cloud. They don't focus on emissions. It's...we'll plug the right place for that. And I think given the opportunity cost, especially from the sustainability and measurement perspective, the alternative is companies are spending a lot of money on sustainability consultants to try and figure out these emissions for the reporting means, and our software does the heavy lifting for you, as any good product does. And with the cost savings on top of that, it's about right for now. +But as we improve the product and can accommodate these bigger enterprise clients, the price model will evolve and probably get more expensive. But not to overcomplicate; it is the logic at this point. And once we do have the ability to take on these more complex arrangements, the pricing would reflect that. Yeah, so that's the plan. +WILL: Well, John, I thank you for coming on the podcast and being a part of it. Is there anything else that you would like our audience to know? +JOHN: We're shouting from the rooftops about carbon emissions. This is going to be the next big issue of the climate crisis. So I truly believe that there are estimates that digital emissions will rise past 10% of global emissions by 2030. Our thirst for data isn't going anywhere. And there's a real chance that computing principles such as Moore's Law that have allowed these improvements in hardware to keep up with the demand for data won't necessarily last forever. +And from that, we need to really wake up to the fact that the digital world, despite it being, yeah, it seems like it happens by magic, there is real sustainability impact. But the good news is we think that using the scalability of software...because the scalability of software that has seen so much success for companies can be used to have an equally positive impact on the planet and prevent this issue of digital emissions by using the inherent scalability of digital and availability of data. +So that's really what I'm preaching at the moment. And we believe the best first step for that would be a product called NetZero because it gives transparency over these emissions. You can see it in front of your eyes, and then decisions can be made in order to reduce them. That's what I chose to be my soapbox moment. +[laughter] +CHAD: That's great. John, if folks want to find out more, see that demo, get in touch with you; where are all the different places that they can do that? +JOHN: greenpixie.com is where you can just contact us, and we'll be straight on the phone with you. Another place to see what we're really up to and get more ideas of digital sustainability the best place is probably our LinkedIn company page. We're quite active on there. If you want to take your first steps into digital sustainability, start there. And if you think your company is ready to act on their carbon emissions or you just want to find out a little bit more, then yeah, just contact us through our website, and we'll have a chat. +CHAD: Awesome. Everything that John just mentioned is going to be linked in the show notes, along with a complete transcript for this episode. You can subscribe to the show and find all of that at giantrobots.fm. +WILL: If you have any questions or comments, email us at hosts@giantrobots.fm. +CHAD: You can find me on Twitter @cpytel. +WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +CHAD: Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: John Ridd. + + + John Ridd is the Co-Founder and CEO of Greenpixie, which is building solutions to reveal and reduce cloud emissions.

+ +

Chad and Will talk to John about giving a clearer view of AWS emissions down to the service level, why cloud emissions are a much bigger sustainability issue than most people realize, and how this will be the next big issue of the climate crisis.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

WILL: And I'm your other host, Will Larry. And with us today is John Ridd, the Co-Founder, and CEO of Greenpixie, which is building solutions to reveal and reduce the emissions of the cloud.

+ +

CHAD: John, thank you so much for joining us. I have to admit that as a developer, this is something that I've been thinking a lot about recently. We practice test-driven development. We run continuous integration, even the things that we have running in the cloud in terms of the websites that we run and that kind of thing.

+ +

I'm also just really becoming aware of when I make a new branch in everything that I run, and I'm making a code change and pushing that up to GitHub; it then kicks off a build every single time any team member is doing that. And I can just see the impact that even just a single software product can have potentially on our environment. And I've started to become more and more guilty about that. So I'm excited to talk to you about how [laughs] we might be able to fix that problem.

+ +

JOHN: Yeah, absolutely. I think one of the big reasons that we've really seen the opportunity in the cloud emissions space is this disconnect really between how developers are incentivized to think, and rightfully so. They need to build and innovate at all costs; that's what drives the innovation in any tech company or any company. But the sustainability way of thinking and thinking, what am I building? What servers am I using and turning on? Just hasn't been in the conversation with developers. And they're the ones who are making these decisions using cloud providers to build out the products that the company needs. So it's great to hear that you're now aware of this impending issue from development.

+ +

CHAD: So I'm excited to dig more into the product. But I'm curious, you were doing digital marketing before starting Greenpixie, right?

+ +

JOHN: Yeah, I ran my own marketing consultancy, worked with a number of companies, big and small. And where I found my knack was sort of demand generation; really, starting off projects from nothing is what I've always done. It's clear now that...so Greenpixie was a bootstrap startup. Really using that ability to at least come up with an idea and take it from zero to one, bring demand to an issue, that's how Greenpixie started.

+ +

And it actually started with the head of engineering, Chris, who I met at my co-working space, and really we traded ideas through a hackathon on the weekend. And I had this idea when it came to website emissions and just knew that there was a software and a product play there. And what we do is connect into Google Analytics, put it through some carbon algorithms, and give them the ability to see how much digital carbon the website is producing. And from my marketing background, we've developed our own marketing, internal marketing software, which is a combination of we've built our own email servers with a high inbox. And we do semantic web scraping to find relevant prospects in the sustainability space.

+ +

So we built the MVP and put this idea for Greenpixie out to the world, and the overwhelming response that we got was people being shocked at the idea of digital carbon and how their digital operations do have a sustainability impact. It really gave us the confidence to think there's demand for this idea of emissions. And since then, we've now moved into carbon emissions down the carbon rabbit hole. But my marketing experience explains how it started in the first place.

+ +

CHAD: So how does...sometimes when faced with, I think, all kinds of climate issues, people can feel overwhelmed or helpless or feeling like what do I do as an individual to have an impact? So what does Greenpixie and Cloud NetZero enable an individual, team, or company, or developer to actually see and do?

+ +

JOHN: Cloud NetZero connects into the leading cloud providers. So at this stage, we can give a clearer view of your AWS emissions down to the service level. And this is a key first step. So we take a you can't affect what you can't measure philosophy. And that was a big, big step for us. And by cutting into the cost and usage reports and putting it through our carbon algorithms, we can then get visibility to engineers.

+ +

So everything you're building up in the cloud, we then give a full transparent view of the associated emissions that are being created from that by using our algorithms and methodology to convert the electricity used from the computation and storage and take into account the geographic location of the data centers of which you're using. As you can imagine, there are different carbon intensities in different countries during different times of the day.

+ +

So we actually hook up into an API that gives us this carbon intensity data down to the hour. So we give a really comprehensive view of your carbon emissions footprint, which is what we consider the gold standard in sustainability. Because what makes the digital vertical so unique within sustainability is we've got data coming out of our ears. [chuckles] The data is there to connect into the software, so we can give this crystal clear picture.

+ +

Whereas in other branches of sustainability, if you're into supply chains, et cetera, you've got real-world problems that you have to put real-time into. So that's the first step that we do is giving you this clear picture of your emissions. And from that, we then proceed to suggest reduction strategies to reduce those emissions.

+ +

WILL: John, I'll be honest. Before getting on the podcast with you, I never thought about my cloud emissions as a developer. Now I'm seeing, wow, there is a lot there with that. On your Twitter, I saw this stat: imagine driving 1.3 billion miles all the way to Saturn. The carbon you would release would be about the same as the amount from all of these streams of Netflix's top 10 shows in the month that were released, 6 billion hours of viewing. I'm just mind-blown just thinking about that. For someone who is just now thinking about my cloud emissions, what would you tell me as a developer or any CEO that's listening to the podcast?

+ +

JOHN: So yeah, you're right. This is a much bigger sustainability issue than most people realize. Currently, it's estimated around 2% of global emissions are from the cloud and data centers use, which puts it near the level of the aviation industry. And because the cloud is so esoteric and it's called the cloud, you think it's light and fluffy, and you're like, okay, it's over there; it's fine.

+ +

But there's a hard infrastructure that makes up the digital world that we enjoy, and that's thousands of racks of servers. That's so much gallons, like, millions of gallons of water used to cool these data centers. And because of this, there are countries such as Ireland and Singapore that have now begun to ban further construction of data centers. Because in Ireland, over 10% of the grid is taken up by these, well, I believe there was an article in The Telegraph that referred to these data centers as vampires, [laughs] vampires on the grid sucking all this energy up.

+ +

And the reason that this exists is it comes down to a company level or to a developer level. You're renting these data centers in order to grow your operations. And this aggregate demand goes straight into why these data centers exist and how much electricity they're using. But what you can do for a certain output...because we're a tech company and we love tech. And that makes us different to maybe some sustainability, really hardline sustainability environmental point of view because we actually think you can achieve the same output for 40% less energy use.

+ +

So there's waste that is pretty rife across the cloud space, and that also comes with the amount of money spent on the cloud. There can be servers that have been left turned on that are no longer used. There can be non-essential computation that could be moved to low carbon intensity hours of the day. And there's so much that can be done and still basically enjoy and build the tech that we all aspire to build.

+ +

CHAD: I'm going to resist taking a tangent into What We Do in the Shadows and the energy vampire, or we can call them Colin, I guess, instead of vampires.

+ +

JOHN: Yeah, yeah.

+ +

[laughter]

+ +

CHAD: So I used the calculator that you have on the website on our website, thoughtbot.com. I was pleased to see that it produces less carbon than 95% of websites. What goes into that calculation, though?

+ +

JOHN: So what we do on the estimator, on the webpage, the calculator, so we take into account whether your server being used is green or standard based on requesting that homepage. And then, really, there's a lot of overlap with PageSpeed optimization, rightfully, so the heavier the web pages, the more images. And if it's been coded lazily and it's heavy, which it hasn't been in your case, which I'm sure you're really happy about, that basically does have an effect on the electricity used in order to serve the website. And we also provide a website carbon report, which goes a step further and takes into account your Google Analytics, which goes for all your pageviews and takes into account some other factors too.

+ +

CHAD: When you're looking at the carbon footprint of a website, am I understanding that you're also taking into account the carbon footprint of the people viewing what it takes to view the website on the client too?

+ +

JOHN: It's very interesting, and we are going into the client side of emissions. That is definitely something that we're looking into and continue to do so. But now we focus more on the cloud. We stuck with websites as our main priority, that would mean the next step was going into client side, and it can, and that logic does go up. And it shows the ability of measuring sustainability impact when it comes to digital because, of course, you can get device information from Google Analytics, and that can then be used to give an accurate prediction. But that is something that we would definitely consider doing in the future. But you see the potential. It can go in all these different directions.

+ +

CHAD: A little bit of a meta question, then, so the calculator is running on people's websites. What is the carbon footprint of running the calculator on the site? [laughs]

+ +

JOHN: Well, that's the thing; we do have transparency of our own operations. So we're a seed-stage startup, and our operations might get a lot bigger. But for now, and given the sustainable approach, we take with how we run our cloud and run these tools, around two tons of CO2 we produce in a month from operations. But looking into other tech companies, you can imagine how AWS can get when it comes to the bigger companies and everything in between. It can really be hundreds or tens of tons. That has been currently unaccounted for and not addressed, which put into perspective, it's acting on your carbon emissions as an individual.

+ +

And let's say you're a developer who has the power to do this. You can have the effect of like ten times going vegan or not using air travel. So it's just really we really love the idea of combating carbon emissions, and developers, particularly combating carbon emissions is, using your unique skills in order to fight the climate crisis in a way that a non-technical person couldn't.

+ +

CHAD: So what are some of the things that you're doing as a company to solve that for yourself? Are there particular cloud hosting providers that are actually better than others?

+ +

JOHN: Yes, it does vary. So there are the big cloud providers, and we are on AWS due to the startup credit scheme, which, as you can imagine, that's very beneficial when you're starting from a bootstrapped model. And within AWS, you can actually...so choosing the geographic location of where you're spinning up the servers is one way you can reduce that. So our servers are in Ireland. So we're part of that issue actually, now that I think about it, because they have a relatively low carbon intensity. And that's one way that we ensure the carbon we're using is minimized. But there's a whole spectrum.

+ +

So if you wanted to go at all costs and convenience and costs are out the window, there are niche carbon fighters, which actually are off-grid renewable power data centers. If you have the means, that is the optimum you can go in terms of the carbon intensity. But in terms of how we build, so just the typical making sure that we're turning off products, features, and servers that we don't use and being mindful of that, putting non-essential compute to low-carbon intensity periods in the day and just minimizing costs and using computation for a certain output is how we take that philosophy.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: On your website, I see that 127 billion is wasted in idle cloud spend, so obviously, one of your goals is to reduce that amount. What other goals is your company looking forward to solving?

+ +

JOHN: I would say our main goal is to reduce millions of tons of needless cloud emissions using scalable software. That is our guiding light. But within that, it correlates largely with cost savings for companies. So we could actually save companies millions of pounds as well or millions of dollars. So I'm from the UK; [laughter] I went for pounds. Yeah, that's the big push; that's our guiding light.

+ +

And we really want to be the torchbearers for digital sustainability as an idea. So having the awareness, we take responsibility for driving awareness for the issue also. As a team, we have a great combination of technical minds but also creative and marketing, getting the message out there and demystifying carbon emissions. So it's a technical issue because there's a technical issue when you dig into it. But we want to put it in a way that a non-technical decision maker in the C-suite would understand the issue in terms of the effects that you can have as a company in a sustainability drive.

+ +

CHAD: So you mentioned you got started from that original hackathon idea. And how did things progress for you from there? You now have a team of people working. Did you end up taking some investment in order to continue on?

+ +

JOHN: We did. We actually started it...so we started it as a passion project from that hackathon, saw the potential. I saw a small business opportunity through the website measuring. And we saw there was demand out there, so we started there. Then we saw it as a side project and continued to see potential and made the call to basically...the initial team was three of us. We went full-time and said let's see what we can do with this.

+ +

Then I came from a marketing consultancy...I self-funded it to the means that I could for the first six months. It's an interesting experience when you get possessed by an idea, and it's just I need to see this through. I see the potential. It's for a great cause. I think there's a big business opportunity here. And then, really, it came to that point, and we did start going down the investment route.

+ +

We were part of an incubator associated with the University of Cambridge called Carbon13. It's a really interesting program where they put together experts in climate science, the developers. And you come together to try and come up with these big ideas to basically reduce millions of tons of emissions as a startup. And there was plenty. There was, for example, there was offsetting companies, there was carbon credit startups, everything you can imagine.

+ +

And it was there that we got put on the investment journey because at the end of the program, you get what was an £80,000 investment to then move on and then go down the VC route. Turns out we didn't get the investment despite us being one of the favorites. It didn't work out for various reasons. And then we were in a situation where I was like, okay, we need to get this investment in order to keep going and scaling the team.

+ +

And we ended up being VC-backed for our pre-seed from a company in London called Ascension. So we did a £250,000 pre-seed round to get things going. And that's why we have a team who is now working on this full-time. And it's been a bit of a journey, but the trials and tribulations of startups is just the game. And now we're looking to get our seed round. We're hoping to be closing by the end of the year.

+ +

CHAD: Congratulations on the progress so far. Why do you think Ascension was interested in investing in you?

+ +

JOHN: So, really, at pre-seed stage, I've talked to VCs and said market, founder, co-founders, anything else is just too early to really know with any certainty. So I think they saw that we were committed, enthusiastic about the idea. Will, the other co-founder, and CTO, is a full-stack developer. It's his second startup. And with my demand generation background, we thought we were a good fit.

+ +

But really, I think a lot of time and thinking, and commitment has gone into (blood, sweat, and tears) has gone into thinking how we can create a product or software company that addresses carbon emissions. And I think investors have a good radar of when people are really committed, and that's what we were.

+ +

WILL: You've recently done a soft launch of Cloud NetZero. Can you give me more information around that?

+ +

JOHN: Yeah, absolutely. We did our soft launch, so this is after the pre-seed investment. We got the 250,000. And we built the product that we laid out in that pitch, which was a software that integrates to AWS and gives you this granular breakdown of your emissions by service. And that was what we presented on our soft launch. We did an in-person event, which we just got a small room and managed to...so around 50 people turned up, which we're pretty proud of. And people do seem to be attracted to this idea. We use my marketing background [laughs] to kind of bolster those numbers.

+ +

But it was a really great experience. So it was actually on the side of our co-working space where we did a hackathon originally. And it was a bit of an experience, quite a heartwarming experience that everyone has come together. I'm just like, oh, it was in that room that it started as an idea, and now 50 people coming from VC backgrounds, from sustainability, from tech are all coming together. And considering we started in COVID times, to have everyone in the room was just great. So it was great. Yeah, thanks for highlighting it. I really have good memories of that soft launch.

+ +

CHAD: So people can get a demo and sign up now.

+ +

JOHN: Yeah, absolutely. So the product is up and running. It went from idea to reality which we're very, very proud of the product team for hitting it on time as well. So we did a 100-day push, and on the 100th day, it was ready for us. And we actually got a big update Monday next week, which is going to be the V 1.1. I call it V2, and then my CTO says, "No, it's V 1.1." [laughter]

+ +

CHAD: Oh, you need to make your CTO understand that for marketing purposes, you need to make your version numbers bigger.

+ +

JOHN: Yeah, yeah, he's just like, "If you think that's V2, you don't know what you're saying." [laughter] You can contact us, and we can basically show you the onboarding to get you closer to your cloud provider. And you can have a crystal clear picture of your carbon emissions. And the companies we're talking to now so software companies, so pretty well-known brands. We're now in conversation with as well as just your heavy-duty tech companies. And they're really our ideal client we're looking to now because they have a large amount of carbon emissions, and they want to be really measuring them for their sustainability initiatives.

+ +

They are actually going to be required to...from the beginning of next year, there's regulation creeping in that's going to make companies measure their Scope 3 emissions, and we have the product to do that. And once we go over that first stage of measurement, then the next step is giving you recommendations to reduce it ultimately, and that will be both in cloud emissions and costs. So we actually are a cost-saving software ultimately because we can highlight wasted cloud spend, and there's a lot of it in these tech companies.

+ +

CHAD: So you've launched. It sounds like you're focused on getting customers and making sales. How does the pricing work for the product?

+ +

JOHN: At the moment, we are charging 10K a year to use the software. This is for...so it would be your mid-sized tech company is really who that's aimed for. Anything that goes into really heavy-duty cloud emissions analysis would be probably just down the road just because the complication gets considerably...there's a lot more computing that we need to do on our end, which there are costs associated with that. And there's a lot more, as you can imagine, a lot more hand-holding in order to get integrated and that type of thing. So the pricing would be larger for those more developed companies who have huge AWS accounts.

+ +

CHAD: A lot of companies' pricing is one of the things that they struggle with early on. I assume you'll learn, and your pricing model will change. But is there something that particularly you weren't sure about when it came to the pricing?

+ +

JOHN: So the pricing it's really what we're seeing from other parallel softwares on the market more towards the cost reduction side of the cloud. They don't focus on emissions. It's...we'll plug the right place for that. And I think given the opportunity cost, especially from the sustainability and measurement perspective, the alternative is companies are spending a lot of money on sustainability consultants to try and figure out these emissions for the reporting means, and our software does the heavy lifting for you, as any good product does. And with the cost savings on top of that, it's about right for now.

+ +

But as we improve the product and can accommodate these bigger enterprise clients, the price model will evolve and probably get more expensive. But not to overcomplicate; it is the logic at this point. And once we do have the ability to take on these more complex arrangements, the pricing would reflect that. Yeah, so that's the plan.

+ +

WILL: Well, John, I thank you for coming on the podcast and being a part of it. Is there anything else that you would like our audience to know?

+ +

JOHN: We're shouting from the rooftops about carbon emissions. This is going to be the next big issue of the climate crisis. So I truly believe that there are estimates that digital emissions will rise past 10% of global emissions by 2030. Our thirst for data isn't going anywhere. And there's a real chance that computing principles such as Moore's Law that have allowed these improvements in hardware to keep up with the demand for data won't necessarily last forever.

+ +

And from that, we need to really wake up to the fact that the digital world, despite it being, yeah, it seems like it happens by magic, there is real sustainability impact. But the good news is we think that using the scalability of software...because the scalability of software that has seen so much success for companies can be used to have an equally positive impact on the planet and prevent this issue of digital emissions by using the inherent scalability of digital and availability of data.

+ +

So that's really what I'm preaching at the moment. And we believe the best first step for that would be a product called NetZero because it gives transparency over these emissions. You can see it in front of your eyes, and then decisions can be made in order to reduce them. That's what I chose to be my soapbox moment.

+ +

[laughter]

+ +

CHAD: That's great. John, if folks want to find out more, see that demo, get in touch with you; where are all the different places that they can do that?

+ +

JOHN: greenpixie.com is where you can just contact us, and we'll be straight on the phone with you. Another place to see what we're really up to and get more ideas of digital sustainability the best place is probably our LinkedIn company page. We're quite active on there. If you want to take your first steps into digital sustainability, start there. And if you think your company is ready to act on their carbon emissions or you just want to find out a little bit more, then yeah, just contact us through our website, and we'll have a chat.

+ +

CHAD: Awesome. Everything that John just mentioned is going to be linked in the show notes, along with a complete transcript for this episode. You can subscribe to the show and find all of that at giantrobots.fm.

+ +

WILL: If you have any questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Twitter @cpytel.

+ +

WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: John Ridd.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + John Ridd is the Co-Founder and CEO of Greenpixie, which is building solutions to reveal and reduce cloud emissions.

+ +

Chad and Will talk to John about giving a clearer view of AWS emissions down to the service level, why cloud emissions are a much bigger sustainability issue than most people realize, and how this will be the next big issue of the climate crisis.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

WILL: And I'm your other host, Will Larry. And with us today is John Ridd, the Co-Founder, and CEO of Greenpixie, which is building solutions to reveal and reduce the emissions of the cloud.

+ +

CHAD: John, thank you so much for joining us. I have to admit that as a developer, this is something that I've been thinking a lot about recently. We practice test-driven development. We run continuous integration, even the things that we have running in the cloud in terms of the websites that we run and that kind of thing.

+ +

I'm also just really becoming aware of when I make a new branch in everything that I run, and I'm making a code change and pushing that up to GitHub; it then kicks off a build every single time any team member is doing that. And I can just see the impact that even just a single software product can have potentially on our environment. And I've started to become more and more guilty about that. So I'm excited to talk to you about how [laughs] we might be able to fix that problem.

+ +

JOHN: Yeah, absolutely. I think one of the big reasons that we've really seen the opportunity in the cloud emissions space is this disconnect really between how developers are incentivized to think, and rightfully so. They need to build and innovate at all costs; that's what drives the innovation in any tech company or any company. But the sustainability way of thinking and thinking, what am I building? What servers am I using and turning on? Just hasn't been in the conversation with developers. And they're the ones who are making these decisions using cloud providers to build out the products that the company needs. So it's great to hear that you're now aware of this impending issue from development.

+ +

CHAD: So I'm excited to dig more into the product. But I'm curious, you were doing digital marketing before starting Greenpixie, right?

+ +

JOHN: Yeah, I ran my own marketing consultancy, worked with a number of companies, big and small. And where I found my knack was sort of demand generation; really, starting off projects from nothing is what I've always done. It's clear now that...so Greenpixie was a bootstrap startup. Really using that ability to at least come up with an idea and take it from zero to one, bring demand to an issue, that's how Greenpixie started.

+ +

And it actually started with the head of engineering, Chris, who I met at my co-working space, and really we traded ideas through a hackathon on the weekend. And I had this idea when it came to website emissions and just knew that there was a software and a product play there. And what we do is connect into Google Analytics, put it through some carbon algorithms, and give them the ability to see how much digital carbon the website is producing. And from my marketing background, we've developed our own marketing, internal marketing software, which is a combination of we've built our own email servers with a high inbox. And we do semantic web scraping to find relevant prospects in the sustainability space.

+ +

So we built the MVP and put this idea for Greenpixie out to the world, and the overwhelming response that we got was people being shocked at the idea of digital carbon and how their digital operations do have a sustainability impact. It really gave us the confidence to think there's demand for this idea of emissions. And since then, we've now moved into carbon emissions down the carbon rabbit hole. But my marketing experience explains how it started in the first place.

+ +

CHAD: So how does...sometimes when faced with, I think, all kinds of climate issues, people can feel overwhelmed or helpless or feeling like what do I do as an individual to have an impact? So what does Greenpixie and Cloud NetZero enable an individual, team, or company, or developer to actually see and do?

+ +

JOHN: Cloud NetZero connects into the leading cloud providers. So at this stage, we can give a clearer view of your AWS emissions down to the service level. And this is a key first step. So we take a you can't affect what you can't measure philosophy. And that was a big, big step for us. And by cutting into the cost and usage reports and putting it through our carbon algorithms, we can then get visibility to engineers.

+ +

So everything you're building up in the cloud, we then give a full transparent view of the associated emissions that are being created from that by using our algorithms and methodology to convert the electricity used from the computation and storage and take into account the geographic location of the data centers of which you're using. As you can imagine, there are different carbon intensities in different countries during different times of the day.

+ +

So we actually hook up into an API that gives us this carbon intensity data down to the hour. So we give a really comprehensive view of your carbon emissions footprint, which is what we consider the gold standard in sustainability. Because what makes the digital vertical so unique within sustainability is we've got data coming out of our ears. [chuckles] The data is there to connect into the software, so we can give this crystal clear picture.

+ +

Whereas in other branches of sustainability, if you're into supply chains, et cetera, you've got real-world problems that you have to put real-time into. So that's the first step that we do is giving you this clear picture of your emissions. And from that, we then proceed to suggest reduction strategies to reduce those emissions.

+ +

WILL: John, I'll be honest. Before getting on the podcast with you, I never thought about my cloud emissions as a developer. Now I'm seeing, wow, there is a lot there with that. On your Twitter, I saw this stat: imagine driving 1.3 billion miles all the way to Saturn. The carbon you would release would be about the same as the amount from all of these streams of Netflix's top 10 shows in the month that were released, 6 billion hours of viewing. I'm just mind-blown just thinking about that. For someone who is just now thinking about my cloud emissions, what would you tell me as a developer or any CEO that's listening to the podcast?

+ +

JOHN: So yeah, you're right. This is a much bigger sustainability issue than most people realize. Currently, it's estimated around 2% of global emissions are from the cloud and data centers use, which puts it near the level of the aviation industry. And because the cloud is so esoteric and it's called the cloud, you think it's light and fluffy, and you're like, okay, it's over there; it's fine.

+ +

But there's a hard infrastructure that makes up the digital world that we enjoy, and that's thousands of racks of servers. That's so much gallons, like, millions of gallons of water used to cool these data centers. And because of this, there are countries such as Ireland and Singapore that have now begun to ban further construction of data centers. Because in Ireland, over 10% of the grid is taken up by these, well, I believe there was an article in The Telegraph that referred to these data centers as vampires, [laughs] vampires on the grid sucking all this energy up.

+ +

And the reason that this exists is it comes down to a company level or to a developer level. You're renting these data centers in order to grow your operations. And this aggregate demand goes straight into why these data centers exist and how much electricity they're using. But what you can do for a certain output...because we're a tech company and we love tech. And that makes us different to maybe some sustainability, really hardline sustainability environmental point of view because we actually think you can achieve the same output for 40% less energy use.

+ +

So there's waste that is pretty rife across the cloud space, and that also comes with the amount of money spent on the cloud. There can be servers that have been left turned on that are no longer used. There can be non-essential computation that could be moved to low carbon intensity hours of the day. And there's so much that can be done and still basically enjoy and build the tech that we all aspire to build.

+ +

CHAD: I'm going to resist taking a tangent into What We Do in the Shadows and the energy vampire, or we can call them Colin, I guess, instead of vampires.

+ +

JOHN: Yeah, yeah.

+ +

[laughter]

+ +

CHAD: So I used the calculator that you have on the website on our website, thoughtbot.com. I was pleased to see that it produces less carbon than 95% of websites. What goes into that calculation, though?

+ +

JOHN: So what we do on the estimator, on the webpage, the calculator, so we take into account whether your server being used is green or standard based on requesting that homepage. And then, really, there's a lot of overlap with PageSpeed optimization, rightfully, so the heavier the web pages, the more images. And if it's been coded lazily and it's heavy, which it hasn't been in your case, which I'm sure you're really happy about, that basically does have an effect on the electricity used in order to serve the website. And we also provide a website carbon report, which goes a step further and takes into account your Google Analytics, which goes for all your pageviews and takes into account some other factors too.

+ +

CHAD: When you're looking at the carbon footprint of a website, am I understanding that you're also taking into account the carbon footprint of the people viewing what it takes to view the website on the client too?

+ +

JOHN: It's very interesting, and we are going into the client side of emissions. That is definitely something that we're looking into and continue to do so. But now we focus more on the cloud. We stuck with websites as our main priority, that would mean the next step was going into client side, and it can, and that logic does go up. And it shows the ability of measuring sustainability impact when it comes to digital because, of course, you can get device information from Google Analytics, and that can then be used to give an accurate prediction. But that is something that we would definitely consider doing in the future. But you see the potential. It can go in all these different directions.

+ +

CHAD: A little bit of a meta question, then, so the calculator is running on people's websites. What is the carbon footprint of running the calculator on the site? [laughs]

+ +

JOHN: Well, that's the thing; we do have transparency of our own operations. So we're a seed-stage startup, and our operations might get a lot bigger. But for now, and given the sustainable approach, we take with how we run our cloud and run these tools, around two tons of CO2 we produce in a month from operations. But looking into other tech companies, you can imagine how AWS can get when it comes to the bigger companies and everything in between. It can really be hundreds or tens of tons. That has been currently unaccounted for and not addressed, which put into perspective, it's acting on your carbon emissions as an individual.

+ +

And let's say you're a developer who has the power to do this. You can have the effect of like ten times going vegan or not using air travel. So it's just really we really love the idea of combating carbon emissions, and developers, particularly combating carbon emissions is, using your unique skills in order to fight the climate crisis in a way that a non-technical person couldn't.

+ +

CHAD: So what are some of the things that you're doing as a company to solve that for yourself? Are there particular cloud hosting providers that are actually better than others?

+ +

JOHN: Yes, it does vary. So there are the big cloud providers, and we are on AWS due to the startup credit scheme, which, as you can imagine, that's very beneficial when you're starting from a bootstrapped model. And within AWS, you can actually...so choosing the geographic location of where you're spinning up the servers is one way you can reduce that. So our servers are in Ireland. So we're part of that issue actually, now that I think about it, because they have a relatively low carbon intensity. And that's one way that we ensure the carbon we're using is minimized. But there's a whole spectrum.

+ +

So if you wanted to go at all costs and convenience and costs are out the window, there are niche carbon fighters, which actually are off-grid renewable power data centers. If you have the means, that is the optimum you can go in terms of the carbon intensity. But in terms of how we build, so just the typical making sure that we're turning off products, features, and servers that we don't use and being mindful of that, putting non-essential compute to low-carbon intensity periods in the day and just minimizing costs and using computation for a certain output is how we take that philosophy.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: On your website, I see that 127 billion is wasted in idle cloud spend, so obviously, one of your goals is to reduce that amount. What other goals is your company looking forward to solving?

+ +

JOHN: I would say our main goal is to reduce millions of tons of needless cloud emissions using scalable software. That is our guiding light. But within that, it correlates largely with cost savings for companies. So we could actually save companies millions of pounds as well or millions of dollars. So I'm from the UK; [laughter] I went for pounds. Yeah, that's the big push; that's our guiding light.

+ +

And we really want to be the torchbearers for digital sustainability as an idea. So having the awareness, we take responsibility for driving awareness for the issue also. As a team, we have a great combination of technical minds but also creative and marketing, getting the message out there and demystifying carbon emissions. So it's a technical issue because there's a technical issue when you dig into it. But we want to put it in a way that a non-technical decision maker in the C-suite would understand the issue in terms of the effects that you can have as a company in a sustainability drive.

+ +

CHAD: So you mentioned you got started from that original hackathon idea. And how did things progress for you from there? You now have a team of people working. Did you end up taking some investment in order to continue on?

+ +

JOHN: We did. We actually started it...so we started it as a passion project from that hackathon, saw the potential. I saw a small business opportunity through the website measuring. And we saw there was demand out there, so we started there. Then we saw it as a side project and continued to see potential and made the call to basically...the initial team was three of us. We went full-time and said let's see what we can do with this.

+ +

Then I came from a marketing consultancy...I self-funded it to the means that I could for the first six months. It's an interesting experience when you get possessed by an idea, and it's just I need to see this through. I see the potential. It's for a great cause. I think there's a big business opportunity here. And then, really, it came to that point, and we did start going down the investment route.

+ +

We were part of an incubator associated with the University of Cambridge called Carbon13. It's a really interesting program where they put together experts in climate science, the developers. And you come together to try and come up with these big ideas to basically reduce millions of tons of emissions as a startup. And there was plenty. There was, for example, there was offsetting companies, there was carbon credit startups, everything you can imagine.

+ +

And it was there that we got put on the investment journey because at the end of the program, you get what was an £80,000 investment to then move on and then go down the VC route. Turns out we didn't get the investment despite us being one of the favorites. It didn't work out for various reasons. And then we were in a situation where I was like, okay, we need to get this investment in order to keep going and scaling the team.

+ +

And we ended up being VC-backed for our pre-seed from a company in London called Ascension. So we did a £250,000 pre-seed round to get things going. And that's why we have a team who is now working on this full-time. And it's been a bit of a journey, but the trials and tribulations of startups is just the game. And now we're looking to get our seed round. We're hoping to be closing by the end of the year.

+ +

CHAD: Congratulations on the progress so far. Why do you think Ascension was interested in investing in you?

+ +

JOHN: So, really, at pre-seed stage, I've talked to VCs and said market, founder, co-founders, anything else is just too early to really know with any certainty. So I think they saw that we were committed, enthusiastic about the idea. Will, the other co-founder, and CTO, is a full-stack developer. It's his second startup. And with my demand generation background, we thought we were a good fit.

+ +

But really, I think a lot of time and thinking, and commitment has gone into (blood, sweat, and tears) has gone into thinking how we can create a product or software company that addresses carbon emissions. And I think investors have a good radar of when people are really committed, and that's what we were.

+ +

WILL: You've recently done a soft launch of Cloud NetZero. Can you give me more information around that?

+ +

JOHN: Yeah, absolutely. We did our soft launch, so this is after the pre-seed investment. We got the 250,000. And we built the product that we laid out in that pitch, which was a software that integrates to AWS and gives you this granular breakdown of your emissions by service. And that was what we presented on our soft launch. We did an in-person event, which we just got a small room and managed to...so around 50 people turned up, which we're pretty proud of. And people do seem to be attracted to this idea. We use my marketing background [laughs] to kind of bolster those numbers.

+ +

But it was a really great experience. So it was actually on the side of our co-working space where we did a hackathon originally. And it was a bit of an experience, quite a heartwarming experience that everyone has come together. I'm just like, oh, it was in that room that it started as an idea, and now 50 people coming from VC backgrounds, from sustainability, from tech are all coming together. And considering we started in COVID times, to have everyone in the room was just great. So it was great. Yeah, thanks for highlighting it. I really have good memories of that soft launch.

+ +

CHAD: So people can get a demo and sign up now.

+ +

JOHN: Yeah, absolutely. So the product is up and running. It went from idea to reality which we're very, very proud of the product team for hitting it on time as well. So we did a 100-day push, and on the 100th day, it was ready for us. And we actually got a big update Monday next week, which is going to be the V 1.1. I call it V2, and then my CTO says, "No, it's V 1.1." [laughter]

+ +

CHAD: Oh, you need to make your CTO understand that for marketing purposes, you need to make your version numbers bigger.

+ +

JOHN: Yeah, yeah, he's just like, "If you think that's V2, you don't know what you're saying." [laughter] You can contact us, and we can basically show you the onboarding to get you closer to your cloud provider. And you can have a crystal clear picture of your carbon emissions. And the companies we're talking to now so software companies, so pretty well-known brands. We're now in conversation with as well as just your heavy-duty tech companies. And they're really our ideal client we're looking to now because they have a large amount of carbon emissions, and they want to be really measuring them for their sustainability initiatives.

+ +

They are actually going to be required to...from the beginning of next year, there's regulation creeping in that's going to make companies measure their Scope 3 emissions, and we have the product to do that. And once we go over that first stage of measurement, then the next step is giving you recommendations to reduce it ultimately, and that will be both in cloud emissions and costs. So we actually are a cost-saving software ultimately because we can highlight wasted cloud spend, and there's a lot of it in these tech companies.

+ +

CHAD: So you've launched. It sounds like you're focused on getting customers and making sales. How does the pricing work for the product?

+ +

JOHN: At the moment, we are charging 10K a year to use the software. This is for...so it would be your mid-sized tech company is really who that's aimed for. Anything that goes into really heavy-duty cloud emissions analysis would be probably just down the road just because the complication gets considerably...there's a lot more computing that we need to do on our end, which there are costs associated with that. And there's a lot more, as you can imagine, a lot more hand-holding in order to get integrated and that type of thing. So the pricing would be larger for those more developed companies who have huge AWS accounts.

+ +

CHAD: A lot of companies' pricing is one of the things that they struggle with early on. I assume you'll learn, and your pricing model will change. But is there something that particularly you weren't sure about when it came to the pricing?

+ +

JOHN: So the pricing it's really what we're seeing from other parallel softwares on the market more towards the cost reduction side of the cloud. They don't focus on emissions. It's...we'll plug the right place for that. And I think given the opportunity cost, especially from the sustainability and measurement perspective, the alternative is companies are spending a lot of money on sustainability consultants to try and figure out these emissions for the reporting means, and our software does the heavy lifting for you, as any good product does. And with the cost savings on top of that, it's about right for now.

+ +

But as we improve the product and can accommodate these bigger enterprise clients, the price model will evolve and probably get more expensive. But not to overcomplicate; it is the logic at this point. And once we do have the ability to take on these more complex arrangements, the pricing would reflect that. Yeah, so that's the plan.

+ +

WILL: Well, John, I thank you for coming on the podcast and being a part of it. Is there anything else that you would like our audience to know?

+ +

JOHN: We're shouting from the rooftops about carbon emissions. This is going to be the next big issue of the climate crisis. So I truly believe that there are estimates that digital emissions will rise past 10% of global emissions by 2030. Our thirst for data isn't going anywhere. And there's a real chance that computing principles such as Moore's Law that have allowed these improvements in hardware to keep up with the demand for data won't necessarily last forever.

+ +

And from that, we need to really wake up to the fact that the digital world, despite it being, yeah, it seems like it happens by magic, there is real sustainability impact. But the good news is we think that using the scalability of software...because the scalability of software that has seen so much success for companies can be used to have an equally positive impact on the planet and prevent this issue of digital emissions by using the inherent scalability of digital and availability of data.

+ +

So that's really what I'm preaching at the moment. And we believe the best first step for that would be a product called NetZero because it gives transparency over these emissions. You can see it in front of your eyes, and then decisions can be made in order to reduce them. That's what I chose to be my soapbox moment.

+ +

[laughter]

+ +

CHAD: That's great. John, if folks want to find out more, see that demo, get in touch with you; where are all the different places that they can do that?

+ +

JOHN: greenpixie.com is where you can just contact us, and we'll be straight on the phone with you. Another place to see what we're really up to and get more ideas of digital sustainability the best place is probably our LinkedIn company page. We're quite active on there. If you want to take your first steps into digital sustainability, start there. And if you think your company is ready to act on their carbon emissions or you just want to find out a little bit more, then yeah, just contact us through our website, and we'll have a chat.

+ +

CHAD: Awesome. Everything that John just mentioned is going to be linked in the show notes, along with a complete transcript for this episode. You can subscribe to the show and find all of that at giantrobots.fm.

+ +

WILL: If you have any questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Twitter @cpytel.

+ +

WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: John Ridd.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+nkSKO3vT + + ]]> + + Will Larry + Chad Pytel + John Ridd + + + 452: SHEMATTERS with Jade Kearney + https://podcast.thoughtbot.com/452 + d66714ec-398b-48ea-be31-5b974addcd69 + Thu, 08 Dec 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Jade Kearney is the Co-Founder and CEO of She Matters, a digital health platform designed to improve postpartum comorbidities for Black women through community, culturally competent healthcare providers, and culturally relevant resources. + +Victoria and Will talk to Jade about why postpartum depression is so dangerous for women, her experience as a mother and why she founded She Matters, and what culturally competent care looks like for Black women. + 26:04 + no + + + Jade Kearney is the Co-Founder and CEO of She Matters, a digital health platform designed to improve postpartum comorbidities for Black women through community, culturally competent healthcare providers, and culturally relevant resources. +Victoria and Will talk to Jade about why postpartum depression is so dangerous for women, her experience as a mother and why she founded She Matters, and what culturally competent care looks like for Black women. +SHEMATTERS (https://www.shematters.health/) +Follow SHEMATTERS on Instagram (https://www.instagram.com/shematters.io/), Facebook (https://www.facebook.com/shematters.io/), or LinkedIn (https://www.linkedin.com/company/she-matters-inc/about/), or YouTube (https://www.youtube.com/channel/UC3_drWpk9DaXakn5d1jHjIg). +Follow Jade on LinkedIn (https-//www.linkedin.com/in/jadekearney/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +WILL: This is the Giant Robot Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Jade Kearney, the Co-Founder, and CEO of She Matters, a digital health platform designed to improve postpartum comorbidities for Black women through community, culturally competent healthcare providers, and culturally relevant resources. +WILL: Jade, thank you for joining us. +JADE: Thank you for having me. +WILL: So I want to start off the podcast and really talk about the issues that you're working to solve because, to be honest, before I was a dad, I had no idea about any of the things that you're trying to solve, but now that I am a dad, I am very well aware of it. So, can you explain to our audience exactly what you're working to solve? +JADE: No problem. What we're working to solve is we're trying to decrease the incidence of Black maternal morbidity and what that means is how Black women are treated in the delivery room and postpartum. I'm not sure if anybody is aware, so I always try to give the statistics upfront: Black women are four times more likely to die during pregnancy and after pregnancy than White counterparts. And here in the state of New York, we're 12 times more likely to die. +So what we're doing as a company is we're looking to decrease postpartum comorbidities through culturally relevant resources, community, and culturally competent healthcare providers that we supply through our She Matters app. +WILL: Those stats are so devastating to hear. You hear the stats and postpartum and things like that. Why is postpartum so dangerous? +JADE: Postpartum is dangerous because postpartum starts the moment you have a child. And when you first have a child as any type of woman, Black, White, Asian, your focus is on the child, and you're not paying attention to the signs of your body. Also, postpartum is not talked about that much. After you have a baby, the focus is on the baby, and a lot of women don't understand what they're experiencing when they're experiencing it. So there may be some very, very alarming signs that are happening that are going off in your body or mind because we're talking about mental health and physical health that a woman doesn't resonate with because no one's talked to her about it. So there's no information. +So a woman is experiencing...has an out-of-body experience having postpartum anxiety and depression and doesn't know what's going on because there's been no information given about it. It can be a silent killer, really, when you think about eclampsia, and you think about HELLP syndrome, which is like high blood pressure during and postpartum. These are the top killers of all women. And if you don't know the signs of that, if you don't know what to look for, you may very well think it's a part of postpartum when you're actually in danger. +VICTORIA: And that sounds so important to increase awareness in the education and community around these issues. Can you tell me more about what culturally competent care actually looks like for Black women? +JADE: So culturally competent care means that you are receiving care from a health provider that understands the stuff that I'm conversing with you guys about. They understand Black maternal morbidity; they understand it is due to systemic racism. They understand that cultural competence is the first step toward communication and trust. So they're meeting Black women where they are. +For instance, culturally, a Black person may say, a Black mother, in particular, may say, "God told me this wasn't normal." Some people may see that as psychosis, so the person may be having terrible mental health issues. In our culture, that's something that we may just say. So to be culturally competent, you have to be aware that, oh, that's a colloquialism used in the Black community, and so I really should be focused on how this mom is feeling instead of maybe she needs to go to the psych ward. There are little differences and nuances like that that cultural competency changes the trust barrier, and it changes the communication barrier for both the healthcare provider and the mother. +VICTORIA: Right. That makes sense to me. And for myself being from Maryland, I have friends who have gone to doctors who just wouldn't believe them when they brought up that they were in pain. Or if another doctor referred them to get an MRI, the new doctor wouldn't want to provide that service. And so your app is trying to bridge that gap and that systemic racism that's built into the system as well. +JADE: Absolutely. That's a common complaint of Black women or Black people, but really Black women, that when we are in distress, when we are in pain, that people just don't believe us because people aren't comfortable with us being in pain, and that goes back to systemic racism. And if you're not culturally competent, you may be unaware of your cultural biases just because you've never had the conversation. And so, 89% of procedures done to Black women are done without their full consent, so Black women are not comfortable. They didn't want to have the procedure. They were coerced into the procedure because people don't listen. Doctors don't listen to us. +WILL: Jade, let's take a second because I love your passion behind it. Where does your passion come from for this situation? Tell us about your experience as a mother and why you founded She Matters. +JADE: Well, my passion comes from becoming a mother, becoming a Black mother to a Black child when I had my first daughter. The first doctor I went to treated me like a statistic, and she was a Black doctor. I felt so scared all the time that I knew it wasn't the right practice for me, and I switched practices at 27 weeks. And when I got to my next practice, I was able to talk to my doctor, Dr. Garfinkel, in Morristown, New Jersey, who is a Jewish man, but was culturally competent, knew the statistics, understood the system and promised me that he would do everything in his power to make sure I had a healthy birth. +I did have preeclampsia. I did have an emergency birth. But my daughter and I made it out of that situation healthy. The issue was during my postpartum period; I had nowhere to go. I didn't understand that the mental illness that I was facing around postpartum OCD, where you have terrible ruminating thoughts about your child or yourself, so harming your child or harming yourself, I didn't understand that that can happen during postpartum and really felt like I was losing my mind. +I felt like I was failing as a mom, and I felt a lot of shame. I went to both my family and friends, and because of the stigma around mental health in the Black community, I didn't find any support there. What I did find was shaming. I found disbelief and really just avoidance of the problem. Like, my mom said to me, "We're Black women. We don't have time for this. You have to go back to work. You need your health insurance." +When I reached out to my healthcare provider at the time, I was told, "I'm going to send you Zoloft and check in with you in six weeks." That's not what I needed to hear. Because I'm a Black woman, I wasn't comfortable with taking an antidepressant. I also was uncomfortable not speaking to my healthcare provider. And I knew that there was a disconnect right there. I couldn't go to family and friends. And I couldn't go to the healthcare system because I was being completely neglected by psychiatrists, by the emergency room, by doctors. +And I created She Matters because I never wanted any other Black woman to feel the way that I felt during my first 12 months of being a mother. I thought we need culturally competent healthcare providers. We need communication with each other, community so we can validate our experiences when we're having these weird things that happen to your mind or body. +And we need culturally relevant resources because when I was on the internet, I couldn't find anything where Black women were talking about our problems because of the stigma. I couldn't find a lot of information around the postpartum state of Black women because we're neglected in healthcare. So that's why I founded She Matters. +VICTORIA: And you founded it over four years ago. And at the time, I believe you were in the process of one of your master's degrees. And looking at the degrees you have, it almost seemed like you planned on founding a company like this. [laughter] But yeah, can you tell me more about your education and how that feeds into your ability to perform as a founder? +JADE: Sure, I did not plan this. [laughter] I was definitely being over-educated, didn't want to leave school; I love to learn. And so I have a degree in diversity and inclusion management and digital media design from NYU. And at the time, I thought I was going to create continuing education platforms or blended learning programs for K through 12. I didn't know that this would be my trajectory. +And so everything I did around diversity and around digital media has helped me launch She Matters. It's really allowed me to cultivate who I am as a CEO and not look at the problem only as a Black mother who experiences these things but also as a business person, also as a tech founder, and be able to zoom out and see what adjustments need to be made that aren't personal to my story. +VICTORIA: And that probably is why you've been so successful, and congratulations on your most recent round of funding. What are you most excited about to be working on with your new capacity? +JADE: I am most excited about working with the thousands of healthcare providers that we're getting ready to work with. It's so important that cultural competency be something that's not a new wave or something popular, but it becomes ingrained in the healthcare system. I love when hospitals are open to making these changes, and they're aware of the problems within hospitals. +I'm also really excited about our new symptom tracker that can be connected to wearables. So preeclampsia, eclampsia, and HELLP syndrome are some of the things that I talked about. And we've created a system tracker on our app that can help mothers get to the hospital faster. I'm really excited about unveiling that on our version two of the app. +WILL: What causes these issues in the Black community? Why are they so overlooked? +JADE: Why are they so overlooked in the Black community, by Black people, or in general? +WILL: Just in general. So you said that you were overlooked and your doctor was a Black lady. But then you had a Jewish doctor that said, "I'm going to take care of you." From your understanding and your view, what do you think caused that? +JADE: It's systemic racism. So the status quo...systemic racism doesn't change because you're Black. We're all part of the system. And that's why cultural competency is needed. Everyone needs that regardless of your race because when you're part of the system, sometimes you're unaware of your biases. People are doing what's been done, and what's been done is unfair. There's no health equity. +People are comfortable with the level of pain Black women experience. People are comfortable with the stats being where they are. Things are just now starting to change. People are just becoming uncomfortable, and that's going to take some years for everyone to become uncomfortable. But it is because this is the system as it is, and people are comfortable with the current system, Black, White, or other. +VICTORIA: Right. And you talked about what new features you're excited about for your platform. And how does the app that you've created start to increase that cultural competency? Like, how does it really work within a healthcare system? +JADE: The app is for our community of moms, and our learning management system is where healthcare providers go. So that's where you get the experience of the culturally competent certification. And you get the curriculum, and you get the experts in health equity leading the classes and talking about Black maternal morbidity and making connections between systemic racism and health outcomes. Our LMS system is the most important part of our training. +And our app is the most important part to communicate with our moms and offer a listserv of these doctors who are taking our certification, the resources that we talked about, and those symptom trackers that we talked about. Without technology, none of this would be happening. +VICTORIA: That's great. So you have really two user groups, right? You have your Black women mothers and then also hospitals that you're designing for. +JADE: Yes. +VICTORIA: And I wonder if you found any interesting design challenges for either group. +JADE: And this is my life. The most challenging thing for the mothers is engagement because you have to understand being a mom is full-time. It's like a full-time and a part-time job together. So how do you create programming at an engagement level that's fair for moms? How do you measure a mom's engagement? It's going to be a little bit different because if you have one child or four children, your time on an app is going to be different, not to mention if you have a full-time job. +So it's just about creating engaging programming that mothers will take their downtime to utilize. And I feel like we have a little bit of secret sauce there; it's around our ability to connect to our moms and to bring experts in healthcare to our mothers. When it comes to healthcare professionals, I think healthcare professionals are more than willing to take a course. +It is explaining to hospitals that Black women are worth the investment because, remember, they've been comfortable with the situation as is. Having to convince people that the demographic that you've ignored is important is a job. I also feel like once a hospital decides to come on board with us, I have this huge sigh of relief because trying to explain to people why Black women deserve to live through birth and after can be taxing. +VICTORIA: I can imagine being a mom yourself and having this startup and having to do that difficult work of explaining to people how systemic racism affects their healthcare and why they should care is exhausting. So how do you recharge and find time for yourself and balance your life if it's possible? [laughs] +JADE: I have a great support system; I cannot lie to you, like, between the people who helped me with my children, my team here at She Matters, our board. Like, some people talk about their boards...my board is like family in terms of the support that they give to my co-founder and I. They've been committed to helping us change maternal morbidity in the United States and to have their support and to have the support of everyone in my life is most important. +And I often say to founders, "You cannot do this without support. I don't care how much money you raise. You will lose your shit no matter what your venture is." Because being a founder, being a CEO is very lonely. It doesn't look like anything that's been done before, and you don't have punch-in and punch-out hours. So support is the way that I keep my mind healthy. I'm able to have downtime for myself, and the way that I'm able to be the best person I can be so I can be the best mom. +MID-ROLL AD: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +WILL: You know, you're from Newark, New Jersey. What is your favorite thing about that area? +JADE: I love Newark. In Newark, we say 'nurk.' I know outsiders say 'noo-urk.' But I love being from Newark because I saw kind of the best of both worlds. Newark has such a rich history. And there are so many problems currently around just systemic racism, whether it's education, healthcare, the judicial system, and you kind of see both things play out where you have great private schools, and you have great universities. Shout out to Rutgers; I went to Rutgers, Newark. And then you have all the problems that the country has. +So it gave me a different lens. I own where I'm from, but I also saw the greatness of where I'm from. And I believe it's helped propel me to where I am because I have lived both lives firsthand. And I know what it's like to go to a school that's not receiving funding, to go to a hospital that's coined a Black hospital and to be treated unfairly, and then to go right into another town in Essex County and be treated differently because it's quote, unquote, "a White hospital." Newark has given me the duality that I have as a person to experience both lives. +WILL: Wow, you speak of systemic racism. And in my opinion, I think there are almost two sides of it. I think you have the side that that's their beliefs and the way that they comprehend it, and that's what they're going to believe. And then you have a different side that's like; I had no idea because I've been in my bubble for so long. +And correct me if I'm wrong if I'm missing a category, but in my experience, it's almost the two that I see. And especially with 2020, I think a lot of that slowly started peeling back. And so it seems like you're dealing with that head-on. How have you been received by the doctors and the hospitals in that area? +JADE: It just depends on the doctors and the hospitals. Sometimes people say, "This is what we really want, oh my God, because we don't know what to do." And this is such a huge problem speaking to Black maternal morbidity. With the Black Momnibus Act that was passed in November 2021, there's been $3 trillion put into the pipeline to make these changes. So hospitals are paying attention. +But paying attention and providing your healthcare professionals with the service are two different things. I've been received in both ways; wow, you guys are the second coming. And yeah, this is great, but we're not really focused on it right now. We want to pretend that we're focused on it, but we're really not. It's difficult. +And I do think those two sides of the coin of systemic racism exist where there are people who are proponents of it and who know what they're doing, and there are people who have no idea. Either way, training is necessary so that you can treat people equally. +WILL: Yes, I totally agree with that. Totally agree with that. If you had one message you had, you know, however long you want, what would be the one message that you would want the audience to know about She Matters and what you're solving? +JADE: She Matters is solving for an American problem. This is an American healthcare problem. And people assume when you say Black maternal morbidity that it is not an American problem. Black people are Americans. And I know that sounds crazy because if you're born here, you're an American. But it's not crazy. People act like this is a separate problem from themselves. No, this is our problem, everyone's problem. When women are dying, that's everyone's problem. When there are health inequities in your hospital, it's everybody's problem. We should all care about Black women dying, period. +VICTORIA: Yeah, I think there's a book out this year that calculates the cost of systemic racism, and this area, in particular, the amount of death and the hospital costs related to this is, for no other moral reason, it's very expensive. And addressing it and protecting our community keeps us all healthy, and safe, and good. +I love what you're doing with the app. And I think it's so important, and I'm really glad you came on the show to tell us about it. I'm curious, if you could travel back in time to when you first started, what advice would you give yourself? +JADE: Prepare for the long haul, prepare for the long journey, prepare for the long road. Pace yourself. This is a marathon, not a sprint. It is going to be harder than you think. I didn't think it was easy at all. But I did think that people would understand the severity of the problem we're solving for, and that's just not the case. [laughs] So the convincing part, like I mentioned earlier, is very taxing. I become exhausted with explaining the value of my life as a Black woman. It's exhausting. +WILL: Wow. If you can sum up (This is a two-part question.) your toughest decision or time since you founded She Matters, and let's end it on your best, successful, happy moments since you founded She Matters. +JADE: Okay. The toughest was raising our most recent round. There's a lot of systemic racism there as well. Black women get less than half a percentage point of the venture capital given to startups. And knowing that challenge and speaking to investors who claim that they have interest in people of color and women of color, and when you get in front of them, it becomes the same stats that you use for all startup and tech companies when this is different. This is not a chip. This is not something that people are familiar with. +So people not understanding that when it comes to something like this, which has not been done before, sometimes you have to use a different metric system. We should present to you in a way that is comfortable in Silicon Valley. So I'm not saying we shouldn't do anything that everybody else does; no, we should. But when we're presenting to you, you have to understand the hurdles and the challenges that it took for us to get in front of you. If Black founders are in front of venture capitalists, we are unicorns. We're the best of the best because for us to get there, we had to go through hell and fire. So that's the one thing. +And when it comes to the most positive thing, it would be the amazing feedback we get from mothers and from healthcare professionals. Some people send us donations; some people just volunteer their medical experience, which is expensive. Anytime a healthcare professional says, "I have 10 hours that I can volunteer to a Black mom," that's huge for us. A therapist saying, "I'll offer any She Matters community member 45 minutes free," do you know how much my therapy is? [laughter] I'm like, oh my God, that's so amazing. +And those things matter to me. Like, it's not about revenue for me as much as it is about getting the women the help that they need. And so every time what I say lands with a healthcare system or professional, it warms my heart. Every time a mother is helped, it warms my heart. +VICTORIA: Well, that's wonderful. It's been amazing to hear more on this issue. And I hope our listeners appreciate getting educated on this topic. Is there anything else you want to promote or take a second to leave our audience walking away with? +JADE: Yeah, sure. Just go to shematters.health to learn more about what we're doing. And if you're a Black mother, download the app. If you're a healthcare professional, sign up for our next cohort November 7th. If you just want to learn more, send us an email. Follow us on social media, @shematters.io, on Instagram. We're around, and we love to hear people's feedback. We're here for the volunteering. We're here for it all. We're here if you just want to learn more really. +WILL: Jade, thank you so much for, one, being on the podcast, but most importantly, the impact that you are having on our community, the United States, the world because I think you are going to have that impact on the world the longer you're in this, and the more you go. So just thank you. Thank you for everything. +JADE: Thank you, guys, for giving us a platform to reach more people, and thank you for caring enough to have me speak for Black mothers and for She Matters. I appreciate it. +VICTORIA: Well, thank you so much. I really enjoyed our conversation today. +WILL: You can subscribe to this show and find notes along with a complete transcript for this episode at giantrobots.fm. +VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm. +WILL: You can find me on Twitter @will23larry. +VICTORIA: And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +WILL: Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Jade Kearney. + + + Jade Kearney is the Co-Founder and CEO of She Matters, a digital health platform designed to improve postpartum comorbidities for Black women through community, culturally competent healthcare providers, and culturally relevant resources.

+ +

Victoria and Will talk to Jade about why postpartum depression is so dangerous for women, her experience as a mother and why she founded She Matters, and what culturally competent care looks like for Black women.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robot Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Jade Kearney, the Co-Founder, and CEO of She Matters, a digital health platform designed to improve postpartum comorbidities for Black women through community, culturally competent healthcare providers, and culturally relevant resources.

+ +

WILL: Jade, thank you for joining us.

+ +

JADE: Thank you for having me.

+ +

WILL: So I want to start off the podcast and really talk about the issues that you're working to solve because, to be honest, before I was a dad, I had no idea about any of the things that you're trying to solve, but now that I am a dad, I am very well aware of it. So, can you explain to our audience exactly what you're working to solve?

+ +

JADE: No problem. What we're working to solve is we're trying to decrease the incidence of Black maternal morbidity and what that means is how Black women are treated in the delivery room and postpartum. I'm not sure if anybody is aware, so I always try to give the statistics upfront: Black women are four times more likely to die during pregnancy and after pregnancy than White counterparts. And here in the state of New York, we're 12 times more likely to die.

+ +

So what we're doing as a company is we're looking to decrease postpartum comorbidities through culturally relevant resources, community, and culturally competent healthcare providers that we supply through our She Matters app.

+ +

WILL: Those stats are so devastating to hear. You hear the stats and postpartum and things like that. Why is postpartum so dangerous?

+ +

JADE: Postpartum is dangerous because postpartum starts the moment you have a child. And when you first have a child as any type of woman, Black, White, Asian, your focus is on the child, and you're not paying attention to the signs of your body. Also, postpartum is not talked about that much. After you have a baby, the focus is on the baby, and a lot of women don't understand what they're experiencing when they're experiencing it. So there may be some very, very alarming signs that are happening that are going off in your body or mind because we're talking about mental health and physical health that a woman doesn't resonate with because no one's talked to her about it. So there's no information.

+ +

So a woman is experiencing...has an out-of-body experience having postpartum anxiety and depression and doesn't know what's going on because there's been no information given about it. It can be a silent killer, really, when you think about eclampsia, and you think about HELLP syndrome, which is like high blood pressure during and postpartum. These are the top killers of all women. And if you don't know the signs of that, if you don't know what to look for, you may very well think it's a part of postpartum when you're actually in danger.

+ +

VICTORIA: And that sounds so important to increase awareness in the education and community around these issues. Can you tell me more about what culturally competent care actually looks like for Black women?

+ +

JADE: So culturally competent care means that you are receiving care from a health provider that understands the stuff that I'm conversing with you guys about. They understand Black maternal morbidity; they understand it is due to systemic racism. They understand that cultural competence is the first step toward communication and trust. So they're meeting Black women where they are.

+ +

For instance, culturally, a Black person may say, a Black mother, in particular, may say, "God told me this wasn't normal." Some people may see that as psychosis, so the person may be having terrible mental health issues. In our culture, that's something that we may just say. So to be culturally competent, you have to be aware that, oh, that's a colloquialism used in the Black community, and so I really should be focused on how this mom is feeling instead of maybe she needs to go to the psych ward. There are little differences and nuances like that that cultural competency changes the trust barrier, and it changes the communication barrier for both the healthcare provider and the mother.

+ +

VICTORIA: Right. That makes sense to me. And for myself being from Maryland, I have friends who have gone to doctors who just wouldn't believe them when they brought up that they were in pain. Or if another doctor referred them to get an MRI, the new doctor wouldn't want to provide that service. And so your app is trying to bridge that gap and that systemic racism that's built into the system as well.

+ +

JADE: Absolutely. That's a common complaint of Black women or Black people, but really Black women, that when we are in distress, when we are in pain, that people just don't believe us because people aren't comfortable with us being in pain, and that goes back to systemic racism. And if you're not culturally competent, you may be unaware of your cultural biases just because you've never had the conversation. And so, 89% of procedures done to Black women are done without their full consent, so Black women are not comfortable. They didn't want to have the procedure. They were coerced into the procedure because people don't listen. Doctors don't listen to us.

+ +

WILL: Jade, let's take a second because I love your passion behind it. Where does your passion come from for this situation? Tell us about your experience as a mother and why you founded She Matters.

+ +

JADE: Well, my passion comes from becoming a mother, becoming a Black mother to a Black child when I had my first daughter. The first doctor I went to treated me like a statistic, and she was a Black doctor. I felt so scared all the time that I knew it wasn't the right practice for me, and I switched practices at 27 weeks. And when I got to my next practice, I was able to talk to my doctor, Dr. Garfinkel, in Morristown, New Jersey, who is a Jewish man, but was culturally competent, knew the statistics, understood the system and promised me that he would do everything in his power to make sure I had a healthy birth.

+ +

I did have preeclampsia. I did have an emergency birth. But my daughter and I made it out of that situation healthy. The issue was during my postpartum period; I had nowhere to go. I didn't understand that the mental illness that I was facing around postpartum OCD, where you have terrible ruminating thoughts about your child or yourself, so harming your child or harming yourself, I didn't understand that that can happen during postpartum and really felt like I was losing my mind.

+ +

I felt like I was failing as a mom, and I felt a lot of shame. I went to both my family and friends, and because of the stigma around mental health in the Black community, I didn't find any support there. What I did find was shaming. I found disbelief and really just avoidance of the problem. Like, my mom said to me, "We're Black women. We don't have time for this. You have to go back to work. You need your health insurance."

+ +

When I reached out to my healthcare provider at the time, I was told, "I'm going to send you Zoloft and check in with you in six weeks." That's not what I needed to hear. Because I'm a Black woman, I wasn't comfortable with taking an antidepressant. I also was uncomfortable not speaking to my healthcare provider. And I knew that there was a disconnect right there. I couldn't go to family and friends. And I couldn't go to the healthcare system because I was being completely neglected by psychiatrists, by the emergency room, by doctors.

+ +

And I created She Matters because I never wanted any other Black woman to feel the way that I felt during my first 12 months of being a mother. I thought we need culturally competent healthcare providers. We need communication with each other, community so we can validate our experiences when we're having these weird things that happen to your mind or body.

+ +

And we need culturally relevant resources because when I was on the internet, I couldn't find anything where Black women were talking about our problems because of the stigma. I couldn't find a lot of information around the postpartum state of Black women because we're neglected in healthcare. So that's why I founded She Matters.

+ +

VICTORIA: And you founded it over four years ago. And at the time, I believe you were in the process of one of your master's degrees. And looking at the degrees you have, it almost seemed like you planned on founding a company like this. [laughter] But yeah, can you tell me more about your education and how that feeds into your ability to perform as a founder?

+ +

JADE: Sure, I did not plan this. [laughter] I was definitely being over-educated, didn't want to leave school; I love to learn. And so I have a degree in diversity and inclusion management and digital media design from NYU. And at the time, I thought I was going to create continuing education platforms or blended learning programs for K through 12. I didn't know that this would be my trajectory.

+ +

And so everything I did around diversity and around digital media has helped me launch She Matters. It's really allowed me to cultivate who I am as a CEO and not look at the problem only as a Black mother who experiences these things but also as a business person, also as a tech founder, and be able to zoom out and see what adjustments need to be made that aren't personal to my story.

+ +

VICTORIA: And that probably is why you've been so successful, and congratulations on your most recent round of funding. What are you most excited about to be working on with your new capacity?

+ +

JADE: I am most excited about working with the thousands of healthcare providers that we're getting ready to work with. It's so important that cultural competency be something that's not a new wave or something popular, but it becomes ingrained in the healthcare system. I love when hospitals are open to making these changes, and they're aware of the problems within hospitals.

+ +

I'm also really excited about our new symptom tracker that can be connected to wearables. So preeclampsia, eclampsia, and HELLP syndrome are some of the things that I talked about. And we've created a system tracker on our app that can help mothers get to the hospital faster. I'm really excited about unveiling that on our version two of the app.

+ +

WILL: What causes these issues in the Black community? Why are they so overlooked?

+ +

JADE: Why are they so overlooked in the Black community, by Black people, or in general?

+ +

WILL: Just in general. So you said that you were overlooked and your doctor was a Black lady. But then you had a Jewish doctor that said, "I'm going to take care of you." From your understanding and your view, what do you think caused that?

+ +

JADE: It's systemic racism. So the status quo...systemic racism doesn't change because you're Black. We're all part of the system. And that's why cultural competency is needed. Everyone needs that regardless of your race because when you're part of the system, sometimes you're unaware of your biases. People are doing what's been done, and what's been done is unfair. There's no health equity.

+ +

People are comfortable with the level of pain Black women experience. People are comfortable with the stats being where they are. Things are just now starting to change. People are just becoming uncomfortable, and that's going to take some years for everyone to become uncomfortable. But it is because this is the system as it is, and people are comfortable with the current system, Black, White, or other.

+ +

VICTORIA: Right. And you talked about what new features you're excited about for your platform. And how does the app that you've created start to increase that cultural competency? Like, how does it really work within a healthcare system?

+ +

JADE: The app is for our community of moms, and our learning management system is where healthcare providers go. So that's where you get the experience of the culturally competent certification. And you get the curriculum, and you get the experts in health equity leading the classes and talking about Black maternal morbidity and making connections between systemic racism and health outcomes. Our LMS system is the most important part of our training.

+ +

And our app is the most important part to communicate with our moms and offer a listserv of these doctors who are taking our certification, the resources that we talked about, and those symptom trackers that we talked about. Without technology, none of this would be happening.

+ +

VICTORIA: That's great. So you have really two user groups, right? You have your Black women mothers and then also hospitals that you're designing for.

+ +

JADE: Yes.

+ +

VICTORIA: And I wonder if you found any interesting design challenges for either group.

+ +

JADE: And this is my life. The most challenging thing for the mothers is engagement because you have to understand being a mom is full-time. It's like a full-time and a part-time job together. So how do you create programming at an engagement level that's fair for moms? How do you measure a mom's engagement? It's going to be a little bit different because if you have one child or four children, your time on an app is going to be different, not to mention if you have a full-time job.

+ +

So it's just about creating engaging programming that mothers will take their downtime to utilize. And I feel like we have a little bit of secret sauce there; it's around our ability to connect to our moms and to bring experts in healthcare to our mothers. When it comes to healthcare professionals, I think healthcare professionals are more than willing to take a course.

+ +

It is explaining to hospitals that Black women are worth the investment because, remember, they've been comfortable with the situation as is. Having to convince people that the demographic that you've ignored is important is a job. I also feel like once a hospital decides to come on board with us, I have this huge sigh of relief because trying to explain to people why Black women deserve to live through birth and after can be taxing.

+ +

VICTORIA: I can imagine being a mom yourself and having this startup and having to do that difficult work of explaining to people how systemic racism affects their healthcare and why they should care is exhausting. So how do you recharge and find time for yourself and balance your life if it's possible? [laughs]

+ +

JADE: I have a great support system; I cannot lie to you, like, between the people who helped me with my children, my team here at She Matters, our board. Like, some people talk about their boards...my board is like family in terms of the support that they give to my co-founder and I. They've been committed to helping us change maternal morbidity in the United States and to have their support and to have the support of everyone in my life is most important.

+ +

And I often say to founders, "You cannot do this without support. I don't care how much money you raise. You will lose your shit no matter what your venture is." Because being a founder, being a CEO is very lonely. It doesn't look like anything that's been done before, and you don't have punch-in and punch-out hours. So support is the way that I keep my mind healthy. I'm able to have downtime for myself, and the way that I'm able to be the best person I can be so I can be the best mom.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: You know, you're from Newark, New Jersey. What is your favorite thing about that area?

+ +

JADE: I love Newark. In Newark, we say 'nurk.' I know outsiders say 'noo-urk.' But I love being from Newark because I saw kind of the best of both worlds. Newark has such a rich history. And there are so many problems currently around just systemic racism, whether it's education, healthcare, the judicial system, and you kind of see both things play out where you have great private schools, and you have great universities. Shout out to Rutgers; I went to Rutgers, Newark. And then you have all the problems that the country has.

+ +

So it gave me a different lens. I own where I'm from, but I also saw the greatness of where I'm from. And I believe it's helped propel me to where I am because I have lived both lives firsthand. And I know what it's like to go to a school that's not receiving funding, to go to a hospital that's coined a Black hospital and to be treated unfairly, and then to go right into another town in Essex County and be treated differently because it's quote, unquote, "a White hospital." Newark has given me the duality that I have as a person to experience both lives.

+ +

WILL: Wow, you speak of systemic racism. And in my opinion, I think there are almost two sides of it. I think you have the side that that's their beliefs and the way that they comprehend it, and that's what they're going to believe. And then you have a different side that's like; I had no idea because I've been in my bubble for so long.

+ +

And correct me if I'm wrong if I'm missing a category, but in my experience, it's almost the two that I see. And especially with 2020, I think a lot of that slowly started peeling back. And so it seems like you're dealing with that head-on. How have you been received by the doctors and the hospitals in that area?

+ +

JADE: It just depends on the doctors and the hospitals. Sometimes people say, "This is what we really want, oh my God, because we don't know what to do." And this is such a huge problem speaking to Black maternal morbidity. With the Black Momnibus Act that was passed in November 2021, there's been $3 trillion put into the pipeline to make these changes. So hospitals are paying attention.

+ +

But paying attention and providing your healthcare professionals with the service are two different things. I've been received in both ways; wow, you guys are the second coming. And yeah, this is great, but we're not really focused on it right now. We want to pretend that we're focused on it, but we're really not. It's difficult.

+ +

And I do think those two sides of the coin of systemic racism exist where there are people who are proponents of it and who know what they're doing, and there are people who have no idea. Either way, training is necessary so that you can treat people equally.

+ +

WILL: Yes, I totally agree with that. Totally agree with that. If you had one message you had, you know, however long you want, what would be the one message that you would want the audience to know about She Matters and what you're solving?

+ +

JADE: She Matters is solving for an American problem. This is an American healthcare problem. And people assume when you say Black maternal morbidity that it is not an American problem. Black people are Americans. And I know that sounds crazy because if you're born here, you're an American. But it's not crazy. People act like this is a separate problem from themselves. No, this is our problem, everyone's problem. When women are dying, that's everyone's problem. When there are health inequities in your hospital, it's everybody's problem. We should all care about Black women dying, period.

+ +

VICTORIA: Yeah, I think there's a book out this year that calculates the cost of systemic racism, and this area, in particular, the amount of death and the hospital costs related to this is, for no other moral reason, it's very expensive. And addressing it and protecting our community keeps us all healthy, and safe, and good.

+ +

I love what you're doing with the app. And I think it's so important, and I'm really glad you came on the show to tell us about it. I'm curious, if you could travel back in time to when you first started, what advice would you give yourself?

+ +

JADE: Prepare for the long haul, prepare for the long journey, prepare for the long road. Pace yourself. This is a marathon, not a sprint. It is going to be harder than you think. I didn't think it was easy at all. But I did think that people would understand the severity of the problem we're solving for, and that's just not the case. [laughs] So the convincing part, like I mentioned earlier, is very taxing. I become exhausted with explaining the value of my life as a Black woman. It's exhausting.

+ +

WILL: Wow. If you can sum up (This is a two-part question.) your toughest decision or time since you founded She Matters, and let's end it on your best, successful, happy moments since you founded She Matters.

+ +

JADE: Okay. The toughest was raising our most recent round. There's a lot of systemic racism there as well. Black women get less than half a percentage point of the venture capital given to startups. And knowing that challenge and speaking to investors who claim that they have interest in people of color and women of color, and when you get in front of them, it becomes the same stats that you use for all startup and tech companies when this is different. This is not a chip. This is not something that people are familiar with.

+ +

So people not understanding that when it comes to something like this, which has not been done before, sometimes you have to use a different metric system. We should present to you in a way that is comfortable in Silicon Valley. So I'm not saying we shouldn't do anything that everybody else does; no, we should. But when we're presenting to you, you have to understand the hurdles and the challenges that it took for us to get in front of you. If Black founders are in front of venture capitalists, we are unicorns. We're the best of the best because for us to get there, we had to go through hell and fire. So that's the one thing.

+ +

And when it comes to the most positive thing, it would be the amazing feedback we get from mothers and from healthcare professionals. Some people send us donations; some people just volunteer their medical experience, which is expensive. Anytime a healthcare professional says, "I have 10 hours that I can volunteer to a Black mom," that's huge for us. A therapist saying, "I'll offer any She Matters community member 45 minutes free," do you know how much my therapy is? [laughter] I'm like, oh my God, that's so amazing.

+ +

And those things matter to me. Like, it's not about revenue for me as much as it is about getting the women the help that they need. And so every time what I say lands with a healthcare system or professional, it warms my heart. Every time a mother is helped, it warms my heart.

+ +

VICTORIA: Well, that's wonderful. It's been amazing to hear more on this issue. And I hope our listeners appreciate getting educated on this topic. Is there anything else you want to promote or take a second to leave our audience walking away with?

+ +

JADE: Yeah, sure. Just go to shematters.health to learn more about what we're doing. And if you're a Black mother, download the app. If you're a healthcare professional, sign up for our next cohort November 7th. If you just want to learn more, send us an email. Follow us on social media, @shematters.io, on Instagram. We're around, and we love to hear people's feedback. We're here for the volunteering. We're here for it all. We're here if you just want to learn more really.

+ +

WILL: Jade, thank you so much for, one, being on the podcast, but most importantly, the impact that you are having on our community, the United States, the world because I think you are going to have that impact on the world the longer you're in this, and the more you go. So just thank you. Thank you for everything.

+ +

JADE: Thank you, guys, for giving us a platform to reach more people, and thank you for caring enough to have me speak for Black mothers and for She Matters. I appreciate it.

+ +

VICTORIA: Well, thank you so much. I really enjoyed our conversation today.

+ +

WILL: You can subscribe to this show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

WILL: You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

WILL: Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jade Kearney.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jade Kearney is the Co-Founder and CEO of She Matters, a digital health platform designed to improve postpartum comorbidities for Black women through community, culturally competent healthcare providers, and culturally relevant resources.

+ +

Victoria and Will talk to Jade about why postpartum depression is so dangerous for women, her experience as a mother and why she founded She Matters, and what culturally competent care looks like for Black women.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

WILL: This is the Giant Robot Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Jade Kearney, the Co-Founder, and CEO of She Matters, a digital health platform designed to improve postpartum comorbidities for Black women through community, culturally competent healthcare providers, and culturally relevant resources.

+ +

WILL: Jade, thank you for joining us.

+ +

JADE: Thank you for having me.

+ +

WILL: So I want to start off the podcast and really talk about the issues that you're working to solve because, to be honest, before I was a dad, I had no idea about any of the things that you're trying to solve, but now that I am a dad, I am very well aware of it. So, can you explain to our audience exactly what you're working to solve?

+ +

JADE: No problem. What we're working to solve is we're trying to decrease the incidence of Black maternal morbidity and what that means is how Black women are treated in the delivery room and postpartum. I'm not sure if anybody is aware, so I always try to give the statistics upfront: Black women are four times more likely to die during pregnancy and after pregnancy than White counterparts. And here in the state of New York, we're 12 times more likely to die.

+ +

So what we're doing as a company is we're looking to decrease postpartum comorbidities through culturally relevant resources, community, and culturally competent healthcare providers that we supply through our She Matters app.

+ +

WILL: Those stats are so devastating to hear. You hear the stats and postpartum and things like that. Why is postpartum so dangerous?

+ +

JADE: Postpartum is dangerous because postpartum starts the moment you have a child. And when you first have a child as any type of woman, Black, White, Asian, your focus is on the child, and you're not paying attention to the signs of your body. Also, postpartum is not talked about that much. After you have a baby, the focus is on the baby, and a lot of women don't understand what they're experiencing when they're experiencing it. So there may be some very, very alarming signs that are happening that are going off in your body or mind because we're talking about mental health and physical health that a woman doesn't resonate with because no one's talked to her about it. So there's no information.

+ +

So a woman is experiencing...has an out-of-body experience having postpartum anxiety and depression and doesn't know what's going on because there's been no information given about it. It can be a silent killer, really, when you think about eclampsia, and you think about HELLP syndrome, which is like high blood pressure during and postpartum. These are the top killers of all women. And if you don't know the signs of that, if you don't know what to look for, you may very well think it's a part of postpartum when you're actually in danger.

+ +

VICTORIA: And that sounds so important to increase awareness in the education and community around these issues. Can you tell me more about what culturally competent care actually looks like for Black women?

+ +

JADE: So culturally competent care means that you are receiving care from a health provider that understands the stuff that I'm conversing with you guys about. They understand Black maternal morbidity; they understand it is due to systemic racism. They understand that cultural competence is the first step toward communication and trust. So they're meeting Black women where they are.

+ +

For instance, culturally, a Black person may say, a Black mother, in particular, may say, "God told me this wasn't normal." Some people may see that as psychosis, so the person may be having terrible mental health issues. In our culture, that's something that we may just say. So to be culturally competent, you have to be aware that, oh, that's a colloquialism used in the Black community, and so I really should be focused on how this mom is feeling instead of maybe she needs to go to the psych ward. There are little differences and nuances like that that cultural competency changes the trust barrier, and it changes the communication barrier for both the healthcare provider and the mother.

+ +

VICTORIA: Right. That makes sense to me. And for myself being from Maryland, I have friends who have gone to doctors who just wouldn't believe them when they brought up that they were in pain. Or if another doctor referred them to get an MRI, the new doctor wouldn't want to provide that service. And so your app is trying to bridge that gap and that systemic racism that's built into the system as well.

+ +

JADE: Absolutely. That's a common complaint of Black women or Black people, but really Black women, that when we are in distress, when we are in pain, that people just don't believe us because people aren't comfortable with us being in pain, and that goes back to systemic racism. And if you're not culturally competent, you may be unaware of your cultural biases just because you've never had the conversation. And so, 89% of procedures done to Black women are done without their full consent, so Black women are not comfortable. They didn't want to have the procedure. They were coerced into the procedure because people don't listen. Doctors don't listen to us.

+ +

WILL: Jade, let's take a second because I love your passion behind it. Where does your passion come from for this situation? Tell us about your experience as a mother and why you founded She Matters.

+ +

JADE: Well, my passion comes from becoming a mother, becoming a Black mother to a Black child when I had my first daughter. The first doctor I went to treated me like a statistic, and she was a Black doctor. I felt so scared all the time that I knew it wasn't the right practice for me, and I switched practices at 27 weeks. And when I got to my next practice, I was able to talk to my doctor, Dr. Garfinkel, in Morristown, New Jersey, who is a Jewish man, but was culturally competent, knew the statistics, understood the system and promised me that he would do everything in his power to make sure I had a healthy birth.

+ +

I did have preeclampsia. I did have an emergency birth. But my daughter and I made it out of that situation healthy. The issue was during my postpartum period; I had nowhere to go. I didn't understand that the mental illness that I was facing around postpartum OCD, where you have terrible ruminating thoughts about your child or yourself, so harming your child or harming yourself, I didn't understand that that can happen during postpartum and really felt like I was losing my mind.

+ +

I felt like I was failing as a mom, and I felt a lot of shame. I went to both my family and friends, and because of the stigma around mental health in the Black community, I didn't find any support there. What I did find was shaming. I found disbelief and really just avoidance of the problem. Like, my mom said to me, "We're Black women. We don't have time for this. You have to go back to work. You need your health insurance."

+ +

When I reached out to my healthcare provider at the time, I was told, "I'm going to send you Zoloft and check in with you in six weeks." That's not what I needed to hear. Because I'm a Black woman, I wasn't comfortable with taking an antidepressant. I also was uncomfortable not speaking to my healthcare provider. And I knew that there was a disconnect right there. I couldn't go to family and friends. And I couldn't go to the healthcare system because I was being completely neglected by psychiatrists, by the emergency room, by doctors.

+ +

And I created She Matters because I never wanted any other Black woman to feel the way that I felt during my first 12 months of being a mother. I thought we need culturally competent healthcare providers. We need communication with each other, community so we can validate our experiences when we're having these weird things that happen to your mind or body.

+ +

And we need culturally relevant resources because when I was on the internet, I couldn't find anything where Black women were talking about our problems because of the stigma. I couldn't find a lot of information around the postpartum state of Black women because we're neglected in healthcare. So that's why I founded She Matters.

+ +

VICTORIA: And you founded it over four years ago. And at the time, I believe you were in the process of one of your master's degrees. And looking at the degrees you have, it almost seemed like you planned on founding a company like this. [laughter] But yeah, can you tell me more about your education and how that feeds into your ability to perform as a founder?

+ +

JADE: Sure, I did not plan this. [laughter] I was definitely being over-educated, didn't want to leave school; I love to learn. And so I have a degree in diversity and inclusion management and digital media design from NYU. And at the time, I thought I was going to create continuing education platforms or blended learning programs for K through 12. I didn't know that this would be my trajectory.

+ +

And so everything I did around diversity and around digital media has helped me launch She Matters. It's really allowed me to cultivate who I am as a CEO and not look at the problem only as a Black mother who experiences these things but also as a business person, also as a tech founder, and be able to zoom out and see what adjustments need to be made that aren't personal to my story.

+ +

VICTORIA: And that probably is why you've been so successful, and congratulations on your most recent round of funding. What are you most excited about to be working on with your new capacity?

+ +

JADE: I am most excited about working with the thousands of healthcare providers that we're getting ready to work with. It's so important that cultural competency be something that's not a new wave or something popular, but it becomes ingrained in the healthcare system. I love when hospitals are open to making these changes, and they're aware of the problems within hospitals.

+ +

I'm also really excited about our new symptom tracker that can be connected to wearables. So preeclampsia, eclampsia, and HELLP syndrome are some of the things that I talked about. And we've created a system tracker on our app that can help mothers get to the hospital faster. I'm really excited about unveiling that on our version two of the app.

+ +

WILL: What causes these issues in the Black community? Why are they so overlooked?

+ +

JADE: Why are they so overlooked in the Black community, by Black people, or in general?

+ +

WILL: Just in general. So you said that you were overlooked and your doctor was a Black lady. But then you had a Jewish doctor that said, "I'm going to take care of you." From your understanding and your view, what do you think caused that?

+ +

JADE: It's systemic racism. So the status quo...systemic racism doesn't change because you're Black. We're all part of the system. And that's why cultural competency is needed. Everyone needs that regardless of your race because when you're part of the system, sometimes you're unaware of your biases. People are doing what's been done, and what's been done is unfair. There's no health equity.

+ +

People are comfortable with the level of pain Black women experience. People are comfortable with the stats being where they are. Things are just now starting to change. People are just becoming uncomfortable, and that's going to take some years for everyone to become uncomfortable. But it is because this is the system as it is, and people are comfortable with the current system, Black, White, or other.

+ +

VICTORIA: Right. And you talked about what new features you're excited about for your platform. And how does the app that you've created start to increase that cultural competency? Like, how does it really work within a healthcare system?

+ +

JADE: The app is for our community of moms, and our learning management system is where healthcare providers go. So that's where you get the experience of the culturally competent certification. And you get the curriculum, and you get the experts in health equity leading the classes and talking about Black maternal morbidity and making connections between systemic racism and health outcomes. Our LMS system is the most important part of our training.

+ +

And our app is the most important part to communicate with our moms and offer a listserv of these doctors who are taking our certification, the resources that we talked about, and those symptom trackers that we talked about. Without technology, none of this would be happening.

+ +

VICTORIA: That's great. So you have really two user groups, right? You have your Black women mothers and then also hospitals that you're designing for.

+ +

JADE: Yes.

+ +

VICTORIA: And I wonder if you found any interesting design challenges for either group.

+ +

JADE: And this is my life. The most challenging thing for the mothers is engagement because you have to understand being a mom is full-time. It's like a full-time and a part-time job together. So how do you create programming at an engagement level that's fair for moms? How do you measure a mom's engagement? It's going to be a little bit different because if you have one child or four children, your time on an app is going to be different, not to mention if you have a full-time job.

+ +

So it's just about creating engaging programming that mothers will take their downtime to utilize. And I feel like we have a little bit of secret sauce there; it's around our ability to connect to our moms and to bring experts in healthcare to our mothers. When it comes to healthcare professionals, I think healthcare professionals are more than willing to take a course.

+ +

It is explaining to hospitals that Black women are worth the investment because, remember, they've been comfortable with the situation as is. Having to convince people that the demographic that you've ignored is important is a job. I also feel like once a hospital decides to come on board with us, I have this huge sigh of relief because trying to explain to people why Black women deserve to live through birth and after can be taxing.

+ +

VICTORIA: I can imagine being a mom yourself and having this startup and having to do that difficult work of explaining to people how systemic racism affects their healthcare and why they should care is exhausting. So how do you recharge and find time for yourself and balance your life if it's possible? [laughs]

+ +

JADE: I have a great support system; I cannot lie to you, like, between the people who helped me with my children, my team here at She Matters, our board. Like, some people talk about their boards...my board is like family in terms of the support that they give to my co-founder and I. They've been committed to helping us change maternal morbidity in the United States and to have their support and to have the support of everyone in my life is most important.

+ +

And I often say to founders, "You cannot do this without support. I don't care how much money you raise. You will lose your shit no matter what your venture is." Because being a founder, being a CEO is very lonely. It doesn't look like anything that's been done before, and you don't have punch-in and punch-out hours. So support is the way that I keep my mind healthy. I'm able to have downtime for myself, and the way that I'm able to be the best person I can be so I can be the best mom.

+ +

MID-ROLL AD:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

WILL: You know, you're from Newark, New Jersey. What is your favorite thing about that area?

+ +

JADE: I love Newark. In Newark, we say 'nurk.' I know outsiders say 'noo-urk.' But I love being from Newark because I saw kind of the best of both worlds. Newark has such a rich history. And there are so many problems currently around just systemic racism, whether it's education, healthcare, the judicial system, and you kind of see both things play out where you have great private schools, and you have great universities. Shout out to Rutgers; I went to Rutgers, Newark. And then you have all the problems that the country has.

+ +

So it gave me a different lens. I own where I'm from, but I also saw the greatness of where I'm from. And I believe it's helped propel me to where I am because I have lived both lives firsthand. And I know what it's like to go to a school that's not receiving funding, to go to a hospital that's coined a Black hospital and to be treated unfairly, and then to go right into another town in Essex County and be treated differently because it's quote, unquote, "a White hospital." Newark has given me the duality that I have as a person to experience both lives.

+ +

WILL: Wow, you speak of systemic racism. And in my opinion, I think there are almost two sides of it. I think you have the side that that's their beliefs and the way that they comprehend it, and that's what they're going to believe. And then you have a different side that's like; I had no idea because I've been in my bubble for so long.

+ +

And correct me if I'm wrong if I'm missing a category, but in my experience, it's almost the two that I see. And especially with 2020, I think a lot of that slowly started peeling back. And so it seems like you're dealing with that head-on. How have you been received by the doctors and the hospitals in that area?

+ +

JADE: It just depends on the doctors and the hospitals. Sometimes people say, "This is what we really want, oh my God, because we don't know what to do." And this is such a huge problem speaking to Black maternal morbidity. With the Black Momnibus Act that was passed in November 2021, there's been $3 trillion put into the pipeline to make these changes. So hospitals are paying attention.

+ +

But paying attention and providing your healthcare professionals with the service are two different things. I've been received in both ways; wow, you guys are the second coming. And yeah, this is great, but we're not really focused on it right now. We want to pretend that we're focused on it, but we're really not. It's difficult.

+ +

And I do think those two sides of the coin of systemic racism exist where there are people who are proponents of it and who know what they're doing, and there are people who have no idea. Either way, training is necessary so that you can treat people equally.

+ +

WILL: Yes, I totally agree with that. Totally agree with that. If you had one message you had, you know, however long you want, what would be the one message that you would want the audience to know about She Matters and what you're solving?

+ +

JADE: She Matters is solving for an American problem. This is an American healthcare problem. And people assume when you say Black maternal morbidity that it is not an American problem. Black people are Americans. And I know that sounds crazy because if you're born here, you're an American. But it's not crazy. People act like this is a separate problem from themselves. No, this is our problem, everyone's problem. When women are dying, that's everyone's problem. When there are health inequities in your hospital, it's everybody's problem. We should all care about Black women dying, period.

+ +

VICTORIA: Yeah, I think there's a book out this year that calculates the cost of systemic racism, and this area, in particular, the amount of death and the hospital costs related to this is, for no other moral reason, it's very expensive. And addressing it and protecting our community keeps us all healthy, and safe, and good.

+ +

I love what you're doing with the app. And I think it's so important, and I'm really glad you came on the show to tell us about it. I'm curious, if you could travel back in time to when you first started, what advice would you give yourself?

+ +

JADE: Prepare for the long haul, prepare for the long journey, prepare for the long road. Pace yourself. This is a marathon, not a sprint. It is going to be harder than you think. I didn't think it was easy at all. But I did think that people would understand the severity of the problem we're solving for, and that's just not the case. [laughs] So the convincing part, like I mentioned earlier, is very taxing. I become exhausted with explaining the value of my life as a Black woman. It's exhausting.

+ +

WILL: Wow. If you can sum up (This is a two-part question.) your toughest decision or time since you founded She Matters, and let's end it on your best, successful, happy moments since you founded She Matters.

+ +

JADE: Okay. The toughest was raising our most recent round. There's a lot of systemic racism there as well. Black women get less than half a percentage point of the venture capital given to startups. And knowing that challenge and speaking to investors who claim that they have interest in people of color and women of color, and when you get in front of them, it becomes the same stats that you use for all startup and tech companies when this is different. This is not a chip. This is not something that people are familiar with.

+ +

So people not understanding that when it comes to something like this, which has not been done before, sometimes you have to use a different metric system. We should present to you in a way that is comfortable in Silicon Valley. So I'm not saying we shouldn't do anything that everybody else does; no, we should. But when we're presenting to you, you have to understand the hurdles and the challenges that it took for us to get in front of you. If Black founders are in front of venture capitalists, we are unicorns. We're the best of the best because for us to get there, we had to go through hell and fire. So that's the one thing.

+ +

And when it comes to the most positive thing, it would be the amazing feedback we get from mothers and from healthcare professionals. Some people send us donations; some people just volunteer their medical experience, which is expensive. Anytime a healthcare professional says, "I have 10 hours that I can volunteer to a Black mom," that's huge for us. A therapist saying, "I'll offer any She Matters community member 45 minutes free," do you know how much my therapy is? [laughter] I'm like, oh my God, that's so amazing.

+ +

And those things matter to me. Like, it's not about revenue for me as much as it is about getting the women the help that they need. And so every time what I say lands with a healthcare system or professional, it warms my heart. Every time a mother is helped, it warms my heart.

+ +

VICTORIA: Well, that's wonderful. It's been amazing to hear more on this issue. And I hope our listeners appreciate getting educated on this topic. Is there anything else you want to promote or take a second to leave our audience walking away with?

+ +

JADE: Yeah, sure. Just go to shematters.health to learn more about what we're doing. And if you're a Black mother, download the app. If you're a healthcare professional, sign up for our next cohort November 7th. If you just want to learn more, send us an email. Follow us on social media, @shematters.io, on Instagram. We're around, and we love to hear people's feedback. We're here for the volunteering. We're here for it all. We're here if you just want to learn more really.

+ +

WILL: Jade, thank you so much for, one, being on the podcast, but most importantly, the impact that you are having on our community, the United States, the world because I think you are going to have that impact on the world the longer you're in this, and the more you go. So just thank you. Thank you for everything.

+ +

JADE: Thank you, guys, for giving us a platform to reach more people, and thank you for caring enough to have me speak for Black mothers and for She Matters. I appreciate it.

+ +

VICTORIA: Well, thank you so much. I really enjoyed our conversation today.

+ +

WILL: You can subscribe to this show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

WILL: You can find me on Twitter @will23larry.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

WILL: Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jade Kearney.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kxovzml4 + + ]]> + + Victoria Guido + Will Larry + Jade Kearney + + + 451: Product Strategy with Jordyn Bonds + https://podcast.thoughtbot.com/451 + ae2ecbf5-ddcf-49c6-b916-88ab58480694 + Thu, 01 Dec 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Jordyn Bonds is the Director of Product Strategy at thoughtbot. Jordyn helps companies validate new product opportunities and reach that first key milestone, from validating an early adopter market to creating a pitch deck to building a prototype, proof of concept, or an MVP launch. + +Chad talks to Jordyn about what a Director of Product Strategy does, how Jordyn's career has evolved (She got to build madonna.com for the Confessions on the Dance Floor release and tour!!), and finding practices that keep you motivated and inspired to be working towards long-term, large goals. + 39:29 + no + + + Jordyn Bonds is the Director of Product Strategy at thoughtbot. Jordyn helps companies validate new product opportunities and reach that first key milestone, from validating an early adopter market to creating a pitch deck to building a prototype, proof of concept, or an MVP launch. +Chad talks to Jordyn about what a Director of Product Strategy does, how Jordyn's career has evolved (She got to build madonna.com for the Confessions on the Dance Floor release and tour!!), and finding practices that keep you motivated and inspired to be working towards long-term, large goals. +Follow Jordyn on Twitter (https://twitter.com/skybondsor) or LinkedIn (https://www.linkedin.com/in/skybondsor/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jordyn Bonds, the Director of Product Strategy at thoughtbot. Jordyn helps companies validate new product opportunities and reach that first key milestone, from validating an early adopter market to creating a pitch deck to building a prototype, proof of concept, or an MVP launch. +Jordyn, thank you for joining me not only on this podcast but at thoughtbot. +JORDYN: Thank you. It's wonderful to be here. +CHAD: You joined us in September of this year. And it's been really fun to watch...well, let me say it's always fun to watch people come into the company and begin to digest everything that's there, begin to, like, okay, I can see how this is working, and then to start to make your mark on things. And so thank you for everything you've done so far. And I look forward to seeing everything in the future too. +JORDYN: I look forward to it too. It's been a super interesting experience. I think thoughtbot has a really unique culture, and it's been really fun to get on-boarded into it. +CHAD: Cool. I'd love to talk a little bit more about that in a bit. But you have joined us as the Director of Product Strategy, which is actually a new position for us in the Ignite team, which is the team that focuses on those early-stage ideas, products, companies. Obviously, if we added the position, we thought it was important. We don't take those things lightly. What led you and made you perfect for that position? +JORDYN: [laughs] I think taking something from a nascent notion, whatever that is, an idea for a product or newly identified market opportunity to that first concrete thing out in the world is a really special phase of the work of new product launches. And it is, over the course of my career, just the thing I have really zeroed in on professionally over time. That's kind of my wheelhouse. And so I think that's thing number one. But what makes it special is that I like to think of it like it's almost like the first few seconds of the existence of the universe after the Big Bang... +CHAD: [laughs] +JORDYN: where you are inventing the ground rules of the thing you are building as you are building it. And that is a very...it's just a really special time. And some people love it, and some people despise it. There's a lot of chaos and uncertainty, and you have to move forward despite all of that chaos and uncertainty. And some of us love the; I don't know, there's just this feeling that anything is possible, a sort of sense of newness and really paving the road while you're hacking through the jungle, and I just love that. +And I feel like I want to help other companies love that phase too. [laughs] It's like a weird thing to say. I'm almost like an evangelist for that time. But I'm an evangelist for it because I feel like it's really important to make sure that you're tying the mission and vision of the business; you're weaving it into what it is you're doing in the product ASAP. Do it early. Make sure you're thinking about this stuff from the jump. And if I can be an evangelist for that kind of thinking and the processes that make it possible, it's just a really exciting thing for me to be able to do. +CHAD: That's really cool. You saying that made me think about this sense that I have that oftentimes when you're faced with that period of time where everything is possible, and you're literally defining what the product and the business is going to be, maybe there are more than two buckets. But I think, generally, people fall into one of two buckets. There are the people who look at that and say, "Okay, here's what we're not going to do." And they're really good at saying no to things and narrowing down from that. Another group of people who maybe even really struggle with all of the possibility, and their reaction is to say "Yes," to everything. +JORDYN: Right. Yep. +CHAD: And you can probably say judged by the way that I introduced the concept which one I think is better. +JORDYN: [laughs] +CHAD: But that's the two buckets I see. Do you see that too? +JORDYN: Oh, absolutely. And I will say partly why I am so enthusiastic about this phase is that I was a bucket number two person and worked very hard to become a bucket number one person because that's the mindset you have to get in. But it's a real delicate balance. It's not always clear; you have to be open to things changing. But saying no is way more important than saying yes in the sense that, you know, I think the phrase people like to use in startup land is you can't boil the ocean, and that is true. +So it's much easier...the path is much easier and clearer if you start small. But if you're an entrepreneur, by nature, that's going to feel really uncomfortable to you because what you see out in the world is possibility and probably endless possibility, right? +CHAD: Right. +JORDYN: So the notion that you are going to squeeze yourself into the tiniest space to start when you see the giant opportunity. And PS, everyone is asking you to articulate that giant opportunity. You need to be able to tell that story so that you can recruit people to your cause. But at the same time, you need to be ruthlessly focused in the here and now on the small things, like, the constrained things you're going to do, for now, all the things you're going to say no to for now while keeping your eyes on this larger, expansive prize. It is just a really...it's an art; it is a hard thing to do. +CHAD: How did you shift your mindset? +JORDYN: Through failure. +CHAD: [laughs] +JORDYN: It was through painfully failing at doing this. [laughs] I made every textbook mistake, some of them fairly recently. [laughs] So there's a lot of folks out there who their first venture, their first foray into this world, was a success, and that's wonderful for them. That's great. But their advice is sort of suspect for me and for a lot of founders because it's like, well, you didn't... [laughs] maybe it was skill, maybe it was luck; it was probably a combination of both. Like, good for you that you did this. +But if you've started a business, launched a product one time, and it was wildly successful, how are you in a position to teach me who might be on failure number two, or three, or whatever, how I need to change in order to be successful, what needs to change in order for me to be successful? Like, you're not going to be that useful to me. And so I find I'm in a much better position to help other people not fall into the same potholes that I did because I fell into them. +I can look at folks and say, "I know what you're thinking. I know you've got your eyes on this large market opportunity. And you can see the mass market future ten years from now for this thing that you're building, that's great. But you have to start with the narrowest of early adopters." And you have to start with a pain point that is, quote, "hair on fire" is another phrase people like to use, like, just some pain point that people have that is just so painful for people right now that they are willing to pay someone to fix it. +You got to focus on that despite this large, open-ended opportunity that's in the future. I can only really give that advice to folks credibly because I have done the opposite so many times that I can both empathize with where they're at in that impulse to boil the ocean, but I can also tell them how one way of disabusing yourself of that mindset. +So I think back to actually...so I have an older sister. She was really terrible at math when we were younger. [laughs] And she was the best math teacher for me because it didn't come easy for her. Going to someone who's a math genius to help teach you what greater than or less than is is [laughs] not going to help you because it's self-evident to them. Like, how are they going to break that down for you? My sister was a great math teacher for me because her understanding of math was quite hard-won. So if I came to her and said, "Hey, I don't understand greater than or less than," which, PS, is truly what happened. +CHAD: [laughs] +JORDYN: I was like, I don't really...however, it was being explained to me did not [laughs] resonate. She was a great person to go to because she would not judge me for not understanding it, first of all, and she would have ways of breaking that down. So I'm that person for new founders, people just starting out trying to come up with a new product or explore a new opportunity. I have learned all the painful lessons on their behalf. So it's not like I'm coming to them with advice; that's just boilerplate advice I have read somewhere, and I'm now repeating to them. No, I have painfully learned these lessons. [laughs] Let me help you avoid that. +CHAD: And you said it earlier...you used the phrase like not now or not yet. And I think that's a great way of just slightly...no doesn't mean no forever. [laughs] It just means not right now, not yet. Now's not the right time. +JORDYN: Exactly. +CHAD: And I think that's a healthy way of reframing it. You're trying to strike that balance between the opportunity and the future and what you're doing today to make the product successful and get it out the door. +JORDYN: And you can do a lot of work around those bright, shiny, attractive future possibilities that make it feel...you can basically say, "Not yet, and here's what will have to happen for it to become now." You can kind of nurture those opportunities over time, and what will be the criteria to make them something you want to pursue now. It can kind of sate your desire to pursue them if you nurture the plan over time. So it's not like you just say, "Not yet," you say, "Not yet, and here's the evolving set of things that will tell us it's the right time." +And having that shared alignment on the team around what those things are but keeping your eyes on them, actively monitoring the situation to be on the lookout when now is the time can satisfy your urge to be working toward that. I think that's what's really hard for founders who really have their eyes on this big opportunity is you can sometimes feel like you're not making any progress toward it because the progress is so incremental. +So finding those practices that feed that thing for you, that keep you motivated and inspired to be working toward that long-term large goal, finding those ways to keep at it, to see the progress, keep refining why it is you're doing what you're doing and how it is you're getting there, can make you feel like you're pursuing and even when you're not [laughs] if that makes any sense. I just acknowledge that people need to do something. Just telling yourself or your team not yet is sometimes not enough because you're in it for that big vision, right? +CHAD: Right. Yeah, that's great. One of the things that stood out to me when we first met was the variety of different experiences that you've held, different positions, different roles, different things you've done. You started doing web development. You've done user experience, product management, you've been CTO, you've been CEO of companies. You did product lead and VP of product. That variety of experience, I think is more than I have. [laughs] You have held those different roles. How has that evolved for you in your career? What's been driving that forward for you? +JORDYN: I was always this product strategy person inside. I didn't necessarily know it. I didn't really even know. I mean, back in the early days of the web, a product mindset wasn't even really a thing, and advertising got a hold of the internet first. And so it was really about graphic design for a long time and a bunch of other things. But throughout that first decade that I spent as an engineer, as a front-end engineer, I was just constantly that annoying person on the team who was like, "Why are we building this? Who are we building it for? Why are we building this?" +Because what I learned is as much as I liked to code, and I liked the puzzle of solving the problem of how to turn a design into a thing people could click on, that was really fun for me, but it was only fun for a while before I started to become really sad, disappointed that we would launch things that would be market failures in the sense of, yeah, we launched a thing, and we checked the box, but no one was using it. +And I would come back and say...and I was mostly doing agency work at the time, and so there was not a lot of follow-up. We'd launch something, and then it was, like, move on to the next project. I wanted to know, was this successful? Did people use it? Are people using it? Like, how are they using it? Is it easy to use? And I wanted to answer those questions. And then, when I started to do more of that follow-up work, and then I was finding that most of the things we were launching were failures by my standards. No one cared about them. No one was using them. They were hard to use. +And I wanted to make impactful things. And so I kept asking the questions, and I kept asking them earlier and earlier. This is how I ended up in user experience design. I was like, well, can we answer these questions first? Can we make a plan before we ever put pixels to screen, so to speak, [laughs] before we start building? Can we know something so that when we do build...which I had intimate understanding of how much work it is to build software. It's not nothing. It's a big investment of time and energy. And what I wanted increasingly was for that to be time and energy well spent for the entire team and for the universe. [laughs] +And so that's how I ended up...I think of it as like swimming upstream in the sense that there's still a lot of waterfall process going on in software. And I was just constantly asking why and for whom earlier and earlier in the process, just so that we could make sure that what we were building was "The Right It," to quote a book title that a lot of folks [laughs] in startup land have read. +Like, let's make sure it's "The Right It" before we invest a lot of time and energy, and, frankly, emotion into building something. That was really where this was coming from for me is that I think at heart, secretly or not so secretly, I'm still that engineer, that front-end engineer. And I want cool projects. I want to work on cool projects with cool people that are impactful. And I think that's true of most engineers. [laughs] +No one is purely satisfied to just be given an assignment that they're supposed to execute without thinking about it. And getting into UX and then getting into product management was for me almost like a mission to make sure that by the time something got to engineering, it was a good idea. I just wanted to save engineers from terrible projects; that was my whole mission. [laughs] +CHAD: Well, at thoughtbot, we have a set of core values, and one of them is fulfillment. And in the writing around that, the phrase we often use is we want to work on products that we believe deserve to exist. +JORDYN: Yes. +CHAD: And that doesn't just mean that they have a positive impact on the world instead of a negative impact. But we're very intentional about the words we use, so there's a double meaning to that phrase. It's having a positive impact on the world, but it also means that it's the right product. This is what we should be building that it deserves to exist. +JORDYN: Yes, because you all know, we know how hard it is to make software. It's actually really hard. I think certainly building new products, you know, what a new product meant in 1920 is a very different thing than what [laughs] it means in 2022. And while it is a lot easier to bring new products into the world, like software products, internet products, it doesn't mean it's just easy. There's a lot of effort and resources that go into doing this, so let's make sure we're spending those things wisely. +Is the product idea good? Does it deserve to exist, but also, have we done our homework to validate that people want this, that they're going to use it? And to the extent that you can. There are limits to the ability of any team to forecast that. But when you bring more of this experimental mindset to it as soon as possible, it's like you up the odds that you'll end up building something valuable. And like you were saying about the word deserve, the word valuable to me is very broad, valuable to users, valuable to the business, valuable to the world. Let's create things of value if we're going to go to the trouble of creating things. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +CHAD: Have you found any tools, or techniques, or things that work particularly well for doing that? +JORDYN: Yeah, and it's probably not going to be all that satisfying. There are no shortcuts, I think, is what's challenging about this. [laughs] The tool and the process that I always start with and come back to is talking to customers and talking to users if those two people are not the same. Talk to people, not about your product idea; talk to them about their lives. Talk to them about what is difficult for them, what is easy for them, what they value, and you will seldom go wrong if you start and return to that process and truly listen. +This whole thing of talking to customers and talking to users is an art in and of itself. It's not idle, you know; it's not just a thing you toss off once in a while. [laughs] It's a skill. It's an art. And that is where you begin in it. Now, that is not the whole thing. But if you're starting there or returning there, you can always do this. I talk to teams all the time who have whiffed on this step of the process, and it's fine. Like, people who are builders, especially entrepreneurs, just want to get in there and start making something, like, I get that. +CHAD: Well, I think it's the combination of really wanting to move quickly and get to something really, really quickly. But I also think there is an element of fear... +JORDYN: [laughs] Yes. +CHAD: that causes people so that these two things combined really set people up to not do this... +JORDYN: To not do this, yes. +CHAD: because they're afraid of what they'll learn. And so it's much easier to just say, "Well, I know what to build. Let's build it. And you don't need to actually talk to people who might tell you something that isn't aligned with what you think the product should be." +JORDYN: 100%, 100%. Getting over that fear is hard, and you probably will just have to fail really hard without getting over it. I mean, that was certainly my experience, I mean, like several times. [laughs] I tried to build things without talking to anyone about it. I also was one of these people that built something that...and I can get into the story, but I built something that was successful enough without talking to a single person about it. And it really sent me down a fool's path for a while because I thought that's how it worked. But yeah, that fear is real. +But I think the thing that got me around it eventually and gets me around it now is there's the rational side of this which is, well, wouldn't you rather know sooner than later that something is not a good idea or this is not a pain point? Sure. But the more visceral, emotional thing that got me around it is good ideas are actually a dime a dozen. You'll have good ideas. You'll have ten good ideas tomorrow morning. Your one idea that you have decided to explore and build out and build a company around it won't be your only idea. It is not the only good idea. [laughs] You will have more of those. If you had 1, you'll have 10. +So talking to users means you'll figure out...you'll have the opportunity to come up with more of those ideas, and one of them will be the winner. All of them are probably good ideas on some level. Having ideas isn't the problem. People are afraid of talking to customers and learning that their idea is not good, but you got to turn that on your head. You talk to customers to learn what they need, and then you'll have 20 ideas about how to solve that for them, solve that need. +The real fool's path here is to get attached to your first one idea that you had to solve a problem. It's to get attached to your problem before you have validated it. That's another pitfall here. But then to think that the first thought you had and how to solve it is going to be your only good idea, nah, you have lots of good ideas; we all do. [laughs] You'll have more. +So really just focusing on that pain point and listening to people and then really doing the work to generate more and more ideas. Even if you think you have a good solution now, it's always worth thinking about what other solutions might be constantly because your solution that you've come up with might have some feasibility issues. It might have other problems that you haven't seen yet. So it's always good to have more solutions in the hopper in case the one that you're pursuing right now doesn't turn out to be the right one. +CHAD: This is something that I don't know the answer to, and that is I do know you didn't originally start out as a developer, and it's not what your education is in. +JORDYN: [laughs] No. +CHAD: But how did you get into development? +JORDYN: [laughs] I was in college. This was just such a lucky, random thing. But I was in college, and I was in a band, a rock band. And this was early '98, maybe even fall '97. We were just at practice one day, and someone in the band was like, "We need a website." And this was when this was like a new thing that people did. [laughs] And everyone in the room just turned and looked at me. And I was like, "Oh, I'm making the website? Okay." +CHAD: Why? Were you a tech person in their mind? +JORDYN: I don't know, I guess because I seemed scrappy and capable even then. I have no idea. But I was like, all right, I'll see what I can figure out. So I wandered into the computer lab and just went to the person running the computer lab and was like, "Hey, how do I make a website?" [laughs] And this guy whose name I don't remember which is horrible, I really wish I could reach out to this guy and be like, "Hey, I have a career because of you, thank you." +CHAD: [laughs] +JORDYN: He was like, "Oh, cool. Here's what you do." And he basically opened up Netscape and was like, "Hey, there's like a..." there was like an editor. I don't even remember what it was called now. If you recall, there was an editor in Netscape. He was like, "Here's the basics of this. And here's a website," which was the... [laughs] What was the name of this website? All of the articles on this website were titled something like, so you want to make a webpage? Or so you want to make an interactive image replacement? Or so you want to host a website on a server? Whatever, like, that was all the articles. +And that website taught me how to code, and that guy put me on a path, and I just immediately was like, this is the most fun thing ever. I was like, I love this. [laughs] And it wasn't like two months before I had built the websites for a couple of departments on campus. My mom had a recruiting business at the time. She was like, "Can you make my recruiting business website?" It was just like, off to the races, which was great. But I graduated into the dot-com bust, which meant I could not get a job doing this. It's like entry-level folks always see a recession coming first, right? +CHAD: Right. +JORDYN: And everyone was like, "Oh my God, you can write HTML. You're going to get a six-figure job immediately," whatever. [laughs] And I was like, that is not what's happening here. I would have a job interview at someplace, and then they'd stop calling me. And I would find out that the company went under the day after I interviewed. That was what was happening. +So I couldn't get a job, a professional job doing this for a while. But I kept doing it on the side basically for my friends and family and eventually managed to get back into some professional [laughs] aboveboard real roles doing this work, but it was a struggle at first. And it was only just because I just really loved doing it, which, again, to circle back to something we talked about before, was kind of a liability for me for a while. Liking coding makes you really unthoughtful about what you're coding because you're always happy to do it, right? [laughs] +CHAD: Oh, I speak from personal experience, yes. [laughs] +JORDYN: Yes, right. I just wasn't thinking, is this a good idea? I was thinking great, cool; I get to code more. I love this. That was fine early on because I did get a lot of experience. And the first real job I got doing this work was at a company that was building websites for musicians, and our main client was Warner Brothers music. And so I got to build the My Chemical Romance website. +CHAD: Cool. +JORDYN: I got to build madonna.com for the Confessions on the Dance Floor release and tour. +CHAD: That's really cool. +JORDYN: Like, it was really fun. And basically, I got to build a new website every two weeks for three years which was amazing bootcamp for me. The designers there were just fantastic. I learned more than I can ever even probably understand about doing that. But partly what I learned was [laughs] this feeling of this was where that feeling began where I was like, is this the right thing? Are we building the right thing? Or is this successful? That's when I started to ask those questions: is what we're doing what people want? So anyway, it was very fun. I got into it because I was in rock bands, which is strange. I don't think people typically find lucrative careers being in rock bands. [laughs] +CHAD: I talk to a lot of people over the years through our apprenticeship program, through different things where there are people out there who connect with programming like you did and like I did. The difference is that, for whatever reason, I had that experience when I was 10. [laughs] And other people just never get the opportunity to be exposed to that until later. But it's remarkable when it happens, and you get that connection where it just connects with you at a level that almost nothing has before. It's like a constant dopamine hit when you're programming. +JORDYN: Oh, it is. Yeah, I used to joke that, basically, I felt like I got to play video games for a living because that's what it felt like. It was just one puzzle game after another. It just didn't feel like work. I got to go to work every day and solve what felt like really interesting problems and puzzles. And at the end, there was a thing people used or could look at. It just felt like I'd hit pay dirt. I felt so lucky to have found it. +But yeah, I haven't done this since the pandemic. But for several years before that, I was a Girls Who Code instructor, and being able to pay that experience forward and help middle school, high school-aged girls who hadn't necessarily had this experience yet find themselves in coding, that was really the mission me and my co-teacher had decided that was really what we were after. We didn't care if they walked away from doing this with any hard coding skills. What we wanted them to have in their minds was I can be a programmer, and that seems like fun or possible for me. That was all we wanted. +And it was so amazing to see that moment where it clicked for them where they were like, "Oh, there's like a pattern here." And yeah, see that dopamine hit thing start to set up, you know, in their brains and know that it was only going to help them. I mean, I often said to them, "Major in whatever you want in college, but get a minor in computer science; that's where your job is. [laughter] Sorry to break this to you, but this is where your job is." [laughs] +CHAD: Another thing that you've done is you've advised a lot of companies through a few different organizations: Underscore VC, the Harvard Innovation Lab. What makes a good advisor as opposed to a bad advisor? +JORDYN: This is a really hard question, actually, because it's not often entirely clear in the moment whether a given advisor is...if you feel a lot of rapport with someone and they're helping you out in the moment, that's great. But often, one finds that something an advisor told you that did not land at all at the time comes back later to be something that's really useful. So I want to say up front that what makes a good advisor is really idiosyncratic to the founder, and to the advisor, and to the moment they find themselves together in. +So with that as a big caveat, I think what I bring to this, what I go out of my way to bring to it, is that I've been in the trenches. I know what that feels like. And I trust founders, like, my job there is to just add some perspective. I've participated in building over 30 products, so I can help them. They might be doing their first product or business, and all I'm there to do is bring a bunch of other experience for them to pick some insights from. It's not actually my job, I don't think, to pre-filter that stuff for them. +I'm very practical and hands-on. They bring a problem to me, and I'm like, "Okay, here's three times I've seen that situation before. And here are three things that happened." And I basically multiply their historical experience that they can draw from; that's sort of what I bring to this. +There's another thing here when I've had valuable advisors, this thing that's kind of hard to articulate. But it's like, often early on, what you need is just someone to take you seriously, just really take you seriously as a founder and a leader. I go way out of my way to make it clear that I am doing that with them and that it is my assumption 100% that they will rise to that occasion, that they will figure out who they need to be, what resources they need to bring to bear in order to be successful. +And doing that, taking them seriously and taking their ideas seriously, taking their experiences seriously, and really demonstrating that I think they have what it takes and I think that they can rise to this occasion, I think is probably the most valuable thing because most people don't do that. They come to your idea looking to tear it down, and I think it's well-meaning. They want to stress test you and your idea. That's all well and good. But, I mean, I'm often advising underrepresented founders and what they need is confidence. They need to be built up, not torn down. +That doesn't mean I don't bring skepticism and help them try to think evermore clearly about what it is they're doing and why; I definitely do that. But there's this baseline of I think you are capable of doing this. I think you are a person who gets to do this; that is not in question for me. And that alone I think is probably the most valuable thing you can get from an advisor, [laughs] is just someone to take you seriously. +CHAD: That's great. So for folks who have been familiar with thoughtbot for a while, we have a lot of advice out there in the world for how to build products, how to validate things, exercises to run, all that kind of stuff. And we bundle all of that up in what we call our playbook. And now, as we're sort of almost 20 years into this now, that's a big resource. +And so we're doing something new, which is extracting the information that we have specifically targeted towards those earliest stages of a new product or a business into a separate playbook. You're taking your wisdom, and you're going to be able to add it to that as well. And it's going to be a little bit more targeted. So we've just launched that. And you can find it at thoughtbot.com/research-strategy-playbook. I would encourage folks to check that out. +Jordyn, when it comes to sharing, we're big at that at thoughtbot, and I'm excited to have you as part of that. Is there something that you think our approach from the fact that we're a consulting company or an agency makes it either in good ways or bad ways different than joining a product company and what you might do in a new role, or in sharing, or in working on things that we work on? +JORDYN: Yeah. I mean, I'm sure I'll have more to say about this when I've been here for a year. Having been here for a month, [laughter] this answer might be suspect. So far, anyway, the way I think about the differences here is that our role in working with product companies is to help them build the muscles to do this work, not to do it for them because they need to be able to do it going forward. We're not going to embed with them for the rest of time. +So that's a big difference, and that's both good and bad in the sense that we can maintain a certain amount of perspective because we can bring a kind of insider-outsider, like, we've done this lots and lots of times. We've seen the myriad ways that can go. And so we can bring that experience to bear while also remaining somewhat, I mean, objective is maybe a problematic word here, but some flavor of that while remaining outside of the everyday operational reality of the business. So that can be a really helpful perspective. +But I think the sort of risk there that I see is not being able to fully appreciate...that's the wrong word, but it's like, maybe not having the credibility we could have because we aren't going to be around to see this thing through. There's really, especially at early stages with projects, you really need people who are in it to win it, in it for the long haul. And so, I can see this looking like a tough sell for certain founders. +But from what I know so far, what I know about myself, what I know about thoughtbot so far is that that couldn't be further from the truth for us. We really are invested in folks' long-term success. And we do want to leverage our ability to focus and stand slightly outside of day-to-day operations to help them gain that perspective. But that is really the give and take, I think, of being a consultant rather than being part of the company. +CHAD: Now, it does make us...there are companies out there that that's not the goal, the goal is to make you dependent on them. +JORDYN: Yes, right. [laughs] +CHAD: That definitely is one of the unique things about thoughtbot is that that is not our goal. Our goal is to teach people to do what we do. But we do sometimes get criticized for, in those early stages, exactly that. It's like, where's your sense of urgency or your passion about this? And actually, we do have it. It's just the analogy I often use is we're like a professional sports team. [laughs] We make it look easy because we're really good at it. +And a lot of environments are ones where in order to make things happen, you need to create an environment of stress or those kinds of things. And that's what people are used to. And so when they start working with us, and they don't see that, they think something is wrong. +JORDYN: Yes, yes. 100%. And that is a huge cultural challenge with working with startups in general, where there is a real fire-fighting mentality. Like, let's get in there and make some stuff happen. Things are shifting constantly, and you've got to react. And I'm working 80-hour weeks to just make sure everything gets done. And I would hope..., and I've seen this to a certain extent in my month here so far, but the goal is for us to help folks work smarter, not harder, in the sense that more output does not mean more success. +We do have the experience of having worked on so many products, each of us individually and then collectively as a company. It is our goal, and it is my personal sincere hope that we can help these companies see how to do this work better and more sustainably without burning yourself out. If you happen to be successful while focused on this kind of work more output, it's only by chance you were successful there. It wasn't because you worked that hard. [laughs] And it's hard to see. +There is a lot of like hustle culture stuff out there that makes you feel like unless you are burning your candle at both ends, you're not doing it right. I think thoughtbot has the depth of experience to say," No, we can say otherwise," and to help companies figure out how to do that. I can absolutely see what you mean that people are like; these people don't have the fire in their belly, which couldn't be further from the truth. But it does feel very different from the inside. +CHAD: I feel like I could talk to you all day, [laughs] but we have to keep the episode somewhat within our normal constraints. Jordyn, thank you so much. If folks want to follow along with you or get in touch with you, where are the best places for them to do that? +JORDYN: So I am @skybondsor S-K-Y-B-O-N-D-S-O-R pretty much everywhere that you might want to... [laughter] A friend of mine gave me that nickname years ago. That's my handle pretty much everywhere. I spend a lot of time on Twitter, so that's probably the best place if you want to follow me or interact with me. But I'm also on LinkedIn and a lot of other places. +CHAD: And you can subscribe to the show, find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at, not as an exciting username as @skybondsor, but @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and we'll see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot; thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Jordyn Bonds. + + + Jordyn Bonds is the Director of Product Strategy at thoughtbot. Jordyn helps companies validate new product opportunities and reach that first key milestone, from validating an early adopter market to creating a pitch deck to building a prototype, proof of concept, or an MVP launch.

+ +

Chad talks to Jordyn about what a Director of Product Strategy does, how Jordyn's career has evolved (She got to build madonna.com for the Confessions on the Dance Floor release and tour!!), and finding practices that keep you motivated and inspired to be working towards long-term, large goals.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jordyn Bonds, the Director of Product Strategy at thoughtbot. Jordyn helps companies validate new product opportunities and reach that first key milestone, from validating an early adopter market to creating a pitch deck to building a prototype, proof of concept, or an MVP launch.

+ +

Jordyn, thank you for joining me not only on this podcast but at thoughtbot.

+ +

JORDYN: Thank you. It's wonderful to be here.

+ +

CHAD: You joined us in September of this year. And it's been really fun to watch...well, let me say it's always fun to watch people come into the company and begin to digest everything that's there, begin to, like, okay, I can see how this is working, and then to start to make your mark on things. And so thank you for everything you've done so far. And I look forward to seeing everything in the future too.

+ +

JORDYN: I look forward to it too. It's been a super interesting experience. I think thoughtbot has a really unique culture, and it's been really fun to get on-boarded into it.

+ +

CHAD: Cool. I'd love to talk a little bit more about that in a bit. But you have joined us as the Director of Product Strategy, which is actually a new position for us in the Ignite team, which is the team that focuses on those early-stage ideas, products, companies. Obviously, if we added the position, we thought it was important. We don't take those things lightly. What led you and made you perfect for that position?

+ +

JORDYN: [laughs] I think taking something from a nascent notion, whatever that is, an idea for a product or newly identified market opportunity to that first concrete thing out in the world is a really special phase of the work of new product launches. And it is, over the course of my career, just the thing I have really zeroed in on professionally over time. That's kind of my wheelhouse. And so I think that's thing number one. But what makes it special is that I like to think of it like it's almost like the first few seconds of the existence of the universe after the Big Bang...

+ +

CHAD: [laughs]

+ +

JORDYN: where you are inventing the ground rules of the thing you are building as you are building it. And that is a very...it's just a really special time. And some people love it, and some people despise it. There's a lot of chaos and uncertainty, and you have to move forward despite all of that chaos and uncertainty. And some of us love the; I don't know, there's just this feeling that anything is possible, a sort of sense of newness and really paving the road while you're hacking through the jungle, and I just love that.

+ +

And I feel like I want to help other companies love that phase too. [laughs] It's like a weird thing to say. I'm almost like an evangelist for that time. But I'm an evangelist for it because I feel like it's really important to make sure that you're tying the mission and vision of the business; you're weaving it into what it is you're doing in the product ASAP. Do it early. Make sure you're thinking about this stuff from the jump. And if I can be an evangelist for that kind of thinking and the processes that make it possible, it's just a really exciting thing for me to be able to do.

+ +

CHAD: That's really cool. You saying that made me think about this sense that I have that oftentimes when you're faced with that period of time where everything is possible, and you're literally defining what the product and the business is going to be, maybe there are more than two buckets. But I think, generally, people fall into one of two buckets. There are the people who look at that and say, "Okay, here's what we're not going to do." And they're really good at saying no to things and narrowing down from that. Another group of people who maybe even really struggle with all of the possibility, and their reaction is to say "Yes," to everything.

+ +

JORDYN: Right. Yep.

+ +

CHAD: And you can probably say judged by the way that I introduced the concept which one I think is better.

+ +

JORDYN: [laughs]

+ +

CHAD: But that's the two buckets I see. Do you see that too?

+ +

JORDYN: Oh, absolutely. And I will say partly why I am so enthusiastic about this phase is that I was a bucket number two person and worked very hard to become a bucket number one person because that's the mindset you have to get in. But it's a real delicate balance. It's not always clear; you have to be open to things changing. But saying no is way more important than saying yes in the sense that, you know, I think the phrase people like to use in startup land is you can't boil the ocean, and that is true.

+ +

So it's much easier...the path is much easier and clearer if you start small. But if you're an entrepreneur, by nature, that's going to feel really uncomfortable to you because what you see out in the world is possibility and probably endless possibility, right?

+ +

CHAD: Right.

+ +

JORDYN: So the notion that you are going to squeeze yourself into the tiniest space to start when you see the giant opportunity. And PS, everyone is asking you to articulate that giant opportunity. You need to be able to tell that story so that you can recruit people to your cause. But at the same time, you need to be ruthlessly focused in the here and now on the small things, like, the constrained things you're going to do, for now, all the things you're going to say no to for now while keeping your eyes on this larger, expansive prize. It is just a really...it's an art; it is a hard thing to do.

+ +

CHAD: How did you shift your mindset?

+ +

JORDYN: Through failure.

+ +

CHAD: [laughs]

+ +

JORDYN: It was through painfully failing at doing this. [laughs] I made every textbook mistake, some of them fairly recently. [laughs] So there's a lot of folks out there who their first venture, their first foray into this world, was a success, and that's wonderful for them. That's great. But their advice is sort of suspect for me and for a lot of founders because it's like, well, you didn't... [laughs] maybe it was skill, maybe it was luck; it was probably a combination of both. Like, good for you that you did this.

+ +

But if you've started a business, launched a product one time, and it was wildly successful, how are you in a position to teach me who might be on failure number two, or three, or whatever, how I need to change in order to be successful, what needs to change in order for me to be successful? Like, you're not going to be that useful to me. And so I find I'm in a much better position to help other people not fall into the same potholes that I did because I fell into them.

+ +

I can look at folks and say, "I know what you're thinking. I know you've got your eyes on this large market opportunity. And you can see the mass market future ten years from now for this thing that you're building, that's great. But you have to start with the narrowest of early adopters." And you have to start with a pain point that is, quote, "hair on fire" is another phrase people like to use, like, just some pain point that people have that is just so painful for people right now that they are willing to pay someone to fix it.

+ +

You got to focus on that despite this large, open-ended opportunity that's in the future. I can only really give that advice to folks credibly because I have done the opposite so many times that I can both empathize with where they're at in that impulse to boil the ocean, but I can also tell them how one way of disabusing yourself of that mindset.

+ +

So I think back to actually...so I have an older sister. She was really terrible at math when we were younger. [laughs] And she was the best math teacher for me because it didn't come easy for her. Going to someone who's a math genius to help teach you what greater than or less than is is [laughs] not going to help you because it's self-evident to them. Like, how are they going to break that down for you? My sister was a great math teacher for me because her understanding of math was quite hard-won. So if I came to her and said, "Hey, I don't understand greater than or less than," which, PS, is truly what happened.

+ +

CHAD: [laughs]

+ +

JORDYN: I was like, I don't really...however, it was being explained to me did not [laughs] resonate. She was a great person to go to because she would not judge me for not understanding it, first of all, and she would have ways of breaking that down. So I'm that person for new founders, people just starting out trying to come up with a new product or explore a new opportunity. I have learned all the painful lessons on their behalf. So it's not like I'm coming to them with advice; that's just boilerplate advice I have read somewhere, and I'm now repeating to them. No, I have painfully learned these lessons. [laughs] Let me help you avoid that.

+ +

CHAD: And you said it earlier...you used the phrase like not now or not yet. And I think that's a great way of just slightly...no doesn't mean no forever. [laughs] It just means not right now, not yet. Now's not the right time.

+ +

JORDYN: Exactly.

+ +

CHAD: And I think that's a healthy way of reframing it. You're trying to strike that balance between the opportunity and the future and what you're doing today to make the product successful and get it out the door.

+ +

JORDYN: And you can do a lot of work around those bright, shiny, attractive future possibilities that make it feel...you can basically say, "Not yet, and here's what will have to happen for it to become now." You can kind of nurture those opportunities over time, and what will be the criteria to make them something you want to pursue now. It can kind of sate your desire to pursue them if you nurture the plan over time. So it's not like you just say, "Not yet," you say, "Not yet, and here's the evolving set of things that will tell us it's the right time."

+ +

And having that shared alignment on the team around what those things are but keeping your eyes on them, actively monitoring the situation to be on the lookout when now is the time can satisfy your urge to be working toward that. I think that's what's really hard for founders who really have their eyes on this big opportunity is you can sometimes feel like you're not making any progress toward it because the progress is so incremental.

+ +

So finding those practices that feed that thing for you, that keep you motivated and inspired to be working toward that long-term large goal, finding those ways to keep at it, to see the progress, keep refining why it is you're doing what you're doing and how it is you're getting there, can make you feel like you're pursuing and even when you're not [laughs] if that makes any sense. I just acknowledge that people need to do something. Just telling yourself or your team not yet is sometimes not enough because you're in it for that big vision, right?

+ +

CHAD: Right. Yeah, that's great. One of the things that stood out to me when we first met was the variety of different experiences that you've held, different positions, different roles, different things you've done. You started doing web development. You've done user experience, product management, you've been CTO, you've been CEO of companies. You did product lead and VP of product. That variety of experience, I think is more than I have. [laughs] You have held those different roles. How has that evolved for you in your career? What's been driving that forward for you?

+ +

JORDYN: I was always this product strategy person inside. I didn't necessarily know it. I didn't really even know. I mean, back in the early days of the web, a product mindset wasn't even really a thing, and advertising got a hold of the internet first. And so it was really about graphic design for a long time and a bunch of other things. But throughout that first decade that I spent as an engineer, as a front-end engineer, I was just constantly that annoying person on the team who was like, "Why are we building this? Who are we building it for? Why are we building this?"

+ +

Because what I learned is as much as I liked to code, and I liked the puzzle of solving the problem of how to turn a design into a thing people could click on, that was really fun for me, but it was only fun for a while before I started to become really sad, disappointed that we would launch things that would be market failures in the sense of, yeah, we launched a thing, and we checked the box, but no one was using it.

+ +

And I would come back and say...and I was mostly doing agency work at the time, and so there was not a lot of follow-up. We'd launch something, and then it was, like, move on to the next project. I wanted to know, was this successful? Did people use it? Are people using it? Like, how are they using it? Is it easy to use? And I wanted to answer those questions. And then, when I started to do more of that follow-up work, and then I was finding that most of the things we were launching were failures by my standards. No one cared about them. No one was using them. They were hard to use.

+ +

And I wanted to make impactful things. And so I kept asking the questions, and I kept asking them earlier and earlier. This is how I ended up in user experience design. I was like, well, can we answer these questions first? Can we make a plan before we ever put pixels to screen, so to speak, [laughs] before we start building? Can we know something so that when we do build...which I had intimate understanding of how much work it is to build software. It's not nothing. It's a big investment of time and energy. And what I wanted increasingly was for that to be time and energy well spent for the entire team and for the universe. [laughs]

+ +

And so that's how I ended up...I think of it as like swimming upstream in the sense that there's still a lot of waterfall process going on in software. And I was just constantly asking why and for whom earlier and earlier in the process, just so that we could make sure that what we were building was "The Right It," to quote a book title that a lot of folks [laughs] in startup land have read.

+ +

Like, let's make sure it's "The Right It" before we invest a lot of time and energy, and, frankly, emotion into building something. That was really where this was coming from for me is that I think at heart, secretly or not so secretly, I'm still that engineer, that front-end engineer. And I want cool projects. I want to work on cool projects with cool people that are impactful. And I think that's true of most engineers. [laughs]

+ +

No one is purely satisfied to just be given an assignment that they're supposed to execute without thinking about it. And getting into UX and then getting into product management was for me almost like a mission to make sure that by the time something got to engineering, it was a good idea. I just wanted to save engineers from terrible projects; that was my whole mission. [laughs]

+ +

CHAD: Well, at thoughtbot, we have a set of core values, and one of them is fulfillment. And in the writing around that, the phrase we often use is we want to work on products that we believe deserve to exist.

+ +

JORDYN: Yes.

+ +

CHAD: And that doesn't just mean that they have a positive impact on the world instead of a negative impact. But we're very intentional about the words we use, so there's a double meaning to that phrase. It's having a positive impact on the world, but it also means that it's the right product. This is what we should be building that it deserves to exist.

+ +

JORDYN: Yes, because you all know, we know how hard it is to make software. It's actually really hard. I think certainly building new products, you know, what a new product meant in 1920 is a very different thing than what [laughs] it means in 2022. And while it is a lot easier to bring new products into the world, like software products, internet products, it doesn't mean it's just easy. There's a lot of effort and resources that go into doing this, so let's make sure we're spending those things wisely.

+ +

Is the product idea good? Does it deserve to exist, but also, have we done our homework to validate that people want this, that they're going to use it? And to the extent that you can. There are limits to the ability of any team to forecast that. But when you bring more of this experimental mindset to it as soon as possible, it's like you up the odds that you'll end up building something valuable. And like you were saying about the word deserve, the word valuable to me is very broad, valuable to users, valuable to the business, valuable to the world. Let's create things of value if we're going to go to the trouble of creating things.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: Have you found any tools, or techniques, or things that work particularly well for doing that?

+ +

JORDYN: Yeah, and it's probably not going to be all that satisfying. There are no shortcuts, I think, is what's challenging about this. [laughs] The tool and the process that I always start with and come back to is talking to customers and talking to users if those two people are not the same. Talk to people, not about your product idea; talk to them about their lives. Talk to them about what is difficult for them, what is easy for them, what they value, and you will seldom go wrong if you start and return to that process and truly listen.

+ +

This whole thing of talking to customers and talking to users is an art in and of itself. It's not idle, you know; it's not just a thing you toss off once in a while. [laughs] It's a skill. It's an art. And that is where you begin in it. Now, that is not the whole thing. But if you're starting there or returning there, you can always do this. I talk to teams all the time who have whiffed on this step of the process, and it's fine. Like, people who are builders, especially entrepreneurs, just want to get in there and start making something, like, I get that.

+ +

CHAD: Well, I think it's the combination of really wanting to move quickly and get to something really, really quickly. But I also think there is an element of fear...

+ +

JORDYN: [laughs] Yes.

+ +

CHAD: that causes people so that these two things combined really set people up to not do this...

+ +

JORDYN: To not do this, yes.

+ +

CHAD: because they're afraid of what they'll learn. And so it's much easier to just say, "Well, I know what to build. Let's build it. And you don't need to actually talk to people who might tell you something that isn't aligned with what you think the product should be."

+ +

JORDYN: 100%, 100%. Getting over that fear is hard, and you probably will just have to fail really hard without getting over it. I mean, that was certainly my experience, I mean, like several times. [laughs] I tried to build things without talking to anyone about it. I also was one of these people that built something that...and I can get into the story, but I built something that was successful enough without talking to a single person about it. And it really sent me down a fool's path for a while because I thought that's how it worked. But yeah, that fear is real.

+ +

But I think the thing that got me around it eventually and gets me around it now is there's the rational side of this which is, well, wouldn't you rather know sooner than later that something is not a good idea or this is not a pain point? Sure. But the more visceral, emotional thing that got me around it is good ideas are actually a dime a dozen. You'll have good ideas. You'll have ten good ideas tomorrow morning. Your one idea that you have decided to explore and build out and build a company around it won't be your only idea. It is not the only good idea. [laughs] You will have more of those. If you had 1, you'll have 10.

+ +

So talking to users means you'll figure out...you'll have the opportunity to come up with more of those ideas, and one of them will be the winner. All of them are probably good ideas on some level. Having ideas isn't the problem. People are afraid of talking to customers and learning that their idea is not good, but you got to turn that on your head. You talk to customers to learn what they need, and then you'll have 20 ideas about how to solve that for them, solve that need.

+ +

The real fool's path here is to get attached to your first one idea that you had to solve a problem. It's to get attached to your problem before you have validated it. That's another pitfall here. But then to think that the first thought you had and how to solve it is going to be your only good idea, nah, you have lots of good ideas; we all do. [laughs] You'll have more.

+ +

So really just focusing on that pain point and listening to people and then really doing the work to generate more and more ideas. Even if you think you have a good solution now, it's always worth thinking about what other solutions might be constantly because your solution that you've come up with might have some feasibility issues. It might have other problems that you haven't seen yet. So it's always good to have more solutions in the hopper in case the one that you're pursuing right now doesn't turn out to be the right one.

+ +

CHAD: This is something that I don't know the answer to, and that is I do know you didn't originally start out as a developer, and it's not what your education is in.

+ +

JORDYN: [laughs] No.

+ +

CHAD: But how did you get into development?

+ +

JORDYN: [laughs] I was in college. This was just such a lucky, random thing. But I was in college, and I was in a band, a rock band. And this was early '98, maybe even fall '97. We were just at practice one day, and someone in the band was like, "We need a website." And this was when this was like a new thing that people did. [laughs] And everyone in the room just turned and looked at me. And I was like, "Oh, I'm making the website? Okay."

+ +

CHAD: Why? Were you a tech person in their mind?

+ +

JORDYN: I don't know, I guess because I seemed scrappy and capable even then. I have no idea. But I was like, all right, I'll see what I can figure out. So I wandered into the computer lab and just went to the person running the computer lab and was like, "Hey, how do I make a website?" [laughs] And this guy whose name I don't remember which is horrible, I really wish I could reach out to this guy and be like, "Hey, I have a career because of you, thank you."

+ +

CHAD: [laughs]

+ +

JORDYN: He was like, "Oh, cool. Here's what you do." And he basically opened up Netscape and was like, "Hey, there's like a..." there was like an editor. I don't even remember what it was called now. If you recall, there was an editor in Netscape. He was like, "Here's the basics of this. And here's a website," which was the... [laughs] What was the name of this website? All of the articles on this website were titled something like, so you want to make a webpage? Or so you want to make an interactive image replacement? Or so you want to host a website on a server? Whatever, like, that was all the articles.

+ +

And that website taught me how to code, and that guy put me on a path, and I just immediately was like, this is the most fun thing ever. I was like, I love this. [laughs] And it wasn't like two months before I had built the websites for a couple of departments on campus. My mom had a recruiting business at the time. She was like, "Can you make my recruiting business website?" It was just like, off to the races, which was great. But I graduated into the dot-com bust, which meant I could not get a job doing this. It's like entry-level folks always see a recession coming first, right?

+ +

CHAD: Right.

+ +

JORDYN: And everyone was like, "Oh my God, you can write HTML. You're going to get a six-figure job immediately," whatever. [laughs] And I was like, that is not what's happening here. I would have a job interview at someplace, and then they'd stop calling me. And I would find out that the company went under the day after I interviewed. That was what was happening.

+ +

So I couldn't get a job, a professional job doing this for a while. But I kept doing it on the side basically for my friends and family and eventually managed to get back into some professional [laughs] aboveboard real roles doing this work, but it was a struggle at first. And it was only just because I just really loved doing it, which, again, to circle back to something we talked about before, was kind of a liability for me for a while. Liking coding makes you really unthoughtful about what you're coding because you're always happy to do it, right? [laughs]

+ +

CHAD: Oh, I speak from personal experience, yes. [laughs]

+ +

JORDYN: Yes, right. I just wasn't thinking, is this a good idea? I was thinking great, cool; I get to code more. I love this. That was fine early on because I did get a lot of experience. And the first real job I got doing this work was at a company that was building websites for musicians, and our main client was Warner Brothers music. And so I got to build the My Chemical Romance website.

+ +

CHAD: Cool.

+ +

JORDYN: I got to build madonna.com for the Confessions on the Dance Floor release and tour.

+ +

CHAD: That's really cool.

+ +

JORDYN: Like, it was really fun. And basically, I got to build a new website every two weeks for three years which was amazing bootcamp for me. The designers there were just fantastic. I learned more than I can ever even probably understand about doing that. But partly what I learned was [laughs] this feeling of this was where that feeling began where I was like, is this the right thing? Are we building the right thing? Or is this successful? That's when I started to ask those questions: is what we're doing what people want? So anyway, it was very fun. I got into it because I was in rock bands, which is strange. I don't think people typically find lucrative careers being in rock bands. [laughs]

+ +

CHAD: I talk to a lot of people over the years through our apprenticeship program, through different things where there are people out there who connect with programming like you did and like I did. The difference is that, for whatever reason, I had that experience when I was 10. [laughs] And other people just never get the opportunity to be exposed to that until later. But it's remarkable when it happens, and you get that connection where it just connects with you at a level that almost nothing has before. It's like a constant dopamine hit when you're programming.

+ +

JORDYN: Oh, it is. Yeah, I used to joke that, basically, I felt like I got to play video games for a living because that's what it felt like. It was just one puzzle game after another. It just didn't feel like work. I got to go to work every day and solve what felt like really interesting problems and puzzles. And at the end, there was a thing people used or could look at. It just felt like I'd hit pay dirt. I felt so lucky to have found it.

+ +

But yeah, I haven't done this since the pandemic. But for several years before that, I was a Girls Who Code instructor, and being able to pay that experience forward and help middle school, high school-aged girls who hadn't necessarily had this experience yet find themselves in coding, that was really the mission me and my co-teacher had decided that was really what we were after. We didn't care if they walked away from doing this with any hard coding skills. What we wanted them to have in their minds was I can be a programmer, and that seems like fun or possible for me. That was all we wanted.

+ +

And it was so amazing to see that moment where it clicked for them where they were like, "Oh, there's like a pattern here." And yeah, see that dopamine hit thing start to set up, you know, in their brains and know that it was only going to help them. I mean, I often said to them, "Major in whatever you want in college, but get a minor in computer science; that's where your job is. [laughter] Sorry to break this to you, but this is where your job is." [laughs]

+ +

CHAD: Another thing that you've done is you've advised a lot of companies through a few different organizations: Underscore VC, the Harvard Innovation Lab. What makes a good advisor as opposed to a bad advisor?

+ +

JORDYN: This is a really hard question, actually, because it's not often entirely clear in the moment whether a given advisor is...if you feel a lot of rapport with someone and they're helping you out in the moment, that's great. But often, one finds that something an advisor told you that did not land at all at the time comes back later to be something that's really useful. So I want to say up front that what makes a good advisor is really idiosyncratic to the founder, and to the advisor, and to the moment they find themselves together in.

+ +

So with that as a big caveat, I think what I bring to this, what I go out of my way to bring to it, is that I've been in the trenches. I know what that feels like. And I trust founders, like, my job there is to just add some perspective. I've participated in building over 30 products, so I can help them. They might be doing their first product or business, and all I'm there to do is bring a bunch of other experience for them to pick some insights from. It's not actually my job, I don't think, to pre-filter that stuff for them.

+ +

I'm very practical and hands-on. They bring a problem to me, and I'm like, "Okay, here's three times I've seen that situation before. And here are three things that happened." And I basically multiply their historical experience that they can draw from; that's sort of what I bring to this.

+ +

There's another thing here when I've had valuable advisors, this thing that's kind of hard to articulate. But it's like, often early on, what you need is just someone to take you seriously, just really take you seriously as a founder and a leader. I go way out of my way to make it clear that I am doing that with them and that it is my assumption 100% that they will rise to that occasion, that they will figure out who they need to be, what resources they need to bring to bear in order to be successful.

+ +

And doing that, taking them seriously and taking their ideas seriously, taking their experiences seriously, and really demonstrating that I think they have what it takes and I think that they can rise to this occasion, I think is probably the most valuable thing because most people don't do that. They come to your idea looking to tear it down, and I think it's well-meaning. They want to stress test you and your idea. That's all well and good. But, I mean, I'm often advising underrepresented founders and what they need is confidence. They need to be built up, not torn down.

+ +

That doesn't mean I don't bring skepticism and help them try to think evermore clearly about what it is they're doing and why; I definitely do that. But there's this baseline of I think you are capable of doing this. I think you are a person who gets to do this; that is not in question for me. And that alone I think is probably the most valuable thing you can get from an advisor, [laughs] is just someone to take you seriously.

+ +

CHAD: That's great. So for folks who have been familiar with thoughtbot for a while, we have a lot of advice out there in the world for how to build products, how to validate things, exercises to run, all that kind of stuff. And we bundle all of that up in what we call our playbook. And now, as we're sort of almost 20 years into this now, that's a big resource.

+ +

And so we're doing something new, which is extracting the information that we have specifically targeted towards those earliest stages of a new product or a business into a separate playbook. You're taking your wisdom, and you're going to be able to add it to that as well. And it's going to be a little bit more targeted. So we've just launched that. And you can find it at thoughtbot.com/research-strategy-playbook. I would encourage folks to check that out.

+ +

Jordyn, when it comes to sharing, we're big at that at thoughtbot, and I'm excited to have you as part of that. Is there something that you think our approach from the fact that we're a consulting company or an agency makes it either in good ways or bad ways different than joining a product company and what you might do in a new role, or in sharing, or in working on things that we work on?

+ +

JORDYN: Yeah. I mean, I'm sure I'll have more to say about this when I've been here for a year. Having been here for a month, [laughter] this answer might be suspect. So far, anyway, the way I think about the differences here is that our role in working with product companies is to help them build the muscles to do this work, not to do it for them because they need to be able to do it going forward. We're not going to embed with them for the rest of time.

+ +

So that's a big difference, and that's both good and bad in the sense that we can maintain a certain amount of perspective because we can bring a kind of insider-outsider, like, we've done this lots and lots of times. We've seen the myriad ways that can go. And so we can bring that experience to bear while also remaining somewhat, I mean, objective is maybe a problematic word here, but some flavor of that while remaining outside of the everyday operational reality of the business. So that can be a really helpful perspective.

+ +

But I think the sort of risk there that I see is not being able to fully appreciate...that's the wrong word, but it's like, maybe not having the credibility we could have because we aren't going to be around to see this thing through. There's really, especially at early stages with projects, you really need people who are in it to win it, in it for the long haul. And so, I can see this looking like a tough sell for certain founders.

+ +

But from what I know so far, what I know about myself, what I know about thoughtbot so far is that that couldn't be further from the truth for us. We really are invested in folks' long-term success. And we do want to leverage our ability to focus and stand slightly outside of day-to-day operations to help them gain that perspective. But that is really the give and take, I think, of being a consultant rather than being part of the company.

+ +

CHAD: Now, it does make us...there are companies out there that that's not the goal, the goal is to make you dependent on them.

+ +

JORDYN: Yes, right. [laughs]

+ +

CHAD: That definitely is one of the unique things about thoughtbot is that that is not our goal. Our goal is to teach people to do what we do. But we do sometimes get criticized for, in those early stages, exactly that. It's like, where's your sense of urgency or your passion about this? And actually, we do have it. It's just the analogy I often use is we're like a professional sports team. [laughs] We make it look easy because we're really good at it.

+ +

And a lot of environments are ones where in order to make things happen, you need to create an environment of stress or those kinds of things. And that's what people are used to. And so when they start working with us, and they don't see that, they think something is wrong.

+ +

JORDYN: Yes, yes. 100%. And that is a huge cultural challenge with working with startups in general, where there is a real fire-fighting mentality. Like, let's get in there and make some stuff happen. Things are shifting constantly, and you've got to react. And I'm working 80-hour weeks to just make sure everything gets done. And I would hope..., and I've seen this to a certain extent in my month here so far, but the goal is for us to help folks work smarter, not harder, in the sense that more output does not mean more success.

+ +

We do have the experience of having worked on so many products, each of us individually and then collectively as a company. It is our goal, and it is my personal sincere hope that we can help these companies see how to do this work better and more sustainably without burning yourself out. If you happen to be successful while focused on this kind of work more output, it's only by chance you were successful there. It wasn't because you worked that hard. [laughs] And it's hard to see.

+ +

There is a lot of like hustle culture stuff out there that makes you feel like unless you are burning your candle at both ends, you're not doing it right. I think thoughtbot has the depth of experience to say," No, we can say otherwise," and to help companies figure out how to do that. I can absolutely see what you mean that people are like; these people don't have the fire in their belly, which couldn't be further from the truth. But it does feel very different from the inside.

+ +

CHAD: I feel like I could talk to you all day, [laughs] but we have to keep the episode somewhat within our normal constraints. Jordyn, thank you so much. If folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

JORDYN: So I am @skybondsor S-K-Y-B-O-N-D-S-O-R pretty much everywhere that you might want to... [laughter] A friend of mine gave me that nickname years ago. That's my handle pretty much everywhere. I spend a lot of time on Twitter, so that's probably the best place if you want to follow me or interact with me. But I'm also on LinkedIn and a lot of other places.

+ +

CHAD: And you can subscribe to the show, find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at, not as an exciting username as @skybondsor, but @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and we'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot; thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jordyn Bonds.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jordyn Bonds is the Director of Product Strategy at thoughtbot. Jordyn helps companies validate new product opportunities and reach that first key milestone, from validating an early adopter market to creating a pitch deck to building a prototype, proof of concept, or an MVP launch.

+ +

Chad talks to Jordyn about what a Director of Product Strategy does, how Jordyn's career has evolved (She got to build madonna.com for the Confessions on the Dance Floor release and tour!!), and finding practices that keep you motivated and inspired to be working towards long-term, large goals.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jordyn Bonds, the Director of Product Strategy at thoughtbot. Jordyn helps companies validate new product opportunities and reach that first key milestone, from validating an early adopter market to creating a pitch deck to building a prototype, proof of concept, or an MVP launch.

+ +

Jordyn, thank you for joining me not only on this podcast but at thoughtbot.

+ +

JORDYN: Thank you. It's wonderful to be here.

+ +

CHAD: You joined us in September of this year. And it's been really fun to watch...well, let me say it's always fun to watch people come into the company and begin to digest everything that's there, begin to, like, okay, I can see how this is working, and then to start to make your mark on things. And so thank you for everything you've done so far. And I look forward to seeing everything in the future too.

+ +

JORDYN: I look forward to it too. It's been a super interesting experience. I think thoughtbot has a really unique culture, and it's been really fun to get on-boarded into it.

+ +

CHAD: Cool. I'd love to talk a little bit more about that in a bit. But you have joined us as the Director of Product Strategy, which is actually a new position for us in the Ignite team, which is the team that focuses on those early-stage ideas, products, companies. Obviously, if we added the position, we thought it was important. We don't take those things lightly. What led you and made you perfect for that position?

+ +

JORDYN: [laughs] I think taking something from a nascent notion, whatever that is, an idea for a product or newly identified market opportunity to that first concrete thing out in the world is a really special phase of the work of new product launches. And it is, over the course of my career, just the thing I have really zeroed in on professionally over time. That's kind of my wheelhouse. And so I think that's thing number one. But what makes it special is that I like to think of it like it's almost like the first few seconds of the existence of the universe after the Big Bang...

+ +

CHAD: [laughs]

+ +

JORDYN: where you are inventing the ground rules of the thing you are building as you are building it. And that is a very...it's just a really special time. And some people love it, and some people despise it. There's a lot of chaos and uncertainty, and you have to move forward despite all of that chaos and uncertainty. And some of us love the; I don't know, there's just this feeling that anything is possible, a sort of sense of newness and really paving the road while you're hacking through the jungle, and I just love that.

+ +

And I feel like I want to help other companies love that phase too. [laughs] It's like a weird thing to say. I'm almost like an evangelist for that time. But I'm an evangelist for it because I feel like it's really important to make sure that you're tying the mission and vision of the business; you're weaving it into what it is you're doing in the product ASAP. Do it early. Make sure you're thinking about this stuff from the jump. And if I can be an evangelist for that kind of thinking and the processes that make it possible, it's just a really exciting thing for me to be able to do.

+ +

CHAD: That's really cool. You saying that made me think about this sense that I have that oftentimes when you're faced with that period of time where everything is possible, and you're literally defining what the product and the business is going to be, maybe there are more than two buckets. But I think, generally, people fall into one of two buckets. There are the people who look at that and say, "Okay, here's what we're not going to do." And they're really good at saying no to things and narrowing down from that. Another group of people who maybe even really struggle with all of the possibility, and their reaction is to say "Yes," to everything.

+ +

JORDYN: Right. Yep.

+ +

CHAD: And you can probably say judged by the way that I introduced the concept which one I think is better.

+ +

JORDYN: [laughs]

+ +

CHAD: But that's the two buckets I see. Do you see that too?

+ +

JORDYN: Oh, absolutely. And I will say partly why I am so enthusiastic about this phase is that I was a bucket number two person and worked very hard to become a bucket number one person because that's the mindset you have to get in. But it's a real delicate balance. It's not always clear; you have to be open to things changing. But saying no is way more important than saying yes in the sense that, you know, I think the phrase people like to use in startup land is you can't boil the ocean, and that is true.

+ +

So it's much easier...the path is much easier and clearer if you start small. But if you're an entrepreneur, by nature, that's going to feel really uncomfortable to you because what you see out in the world is possibility and probably endless possibility, right?

+ +

CHAD: Right.

+ +

JORDYN: So the notion that you are going to squeeze yourself into the tiniest space to start when you see the giant opportunity. And PS, everyone is asking you to articulate that giant opportunity. You need to be able to tell that story so that you can recruit people to your cause. But at the same time, you need to be ruthlessly focused in the here and now on the small things, like, the constrained things you're going to do, for now, all the things you're going to say no to for now while keeping your eyes on this larger, expansive prize. It is just a really...it's an art; it is a hard thing to do.

+ +

CHAD: How did you shift your mindset?

+ +

JORDYN: Through failure.

+ +

CHAD: [laughs]

+ +

JORDYN: It was through painfully failing at doing this. [laughs] I made every textbook mistake, some of them fairly recently. [laughs] So there's a lot of folks out there who their first venture, their first foray into this world, was a success, and that's wonderful for them. That's great. But their advice is sort of suspect for me and for a lot of founders because it's like, well, you didn't... [laughs] maybe it was skill, maybe it was luck; it was probably a combination of both. Like, good for you that you did this.

+ +

But if you've started a business, launched a product one time, and it was wildly successful, how are you in a position to teach me who might be on failure number two, or three, or whatever, how I need to change in order to be successful, what needs to change in order for me to be successful? Like, you're not going to be that useful to me. And so I find I'm in a much better position to help other people not fall into the same potholes that I did because I fell into them.

+ +

I can look at folks and say, "I know what you're thinking. I know you've got your eyes on this large market opportunity. And you can see the mass market future ten years from now for this thing that you're building, that's great. But you have to start with the narrowest of early adopters." And you have to start with a pain point that is, quote, "hair on fire" is another phrase people like to use, like, just some pain point that people have that is just so painful for people right now that they are willing to pay someone to fix it.

+ +

You got to focus on that despite this large, open-ended opportunity that's in the future. I can only really give that advice to folks credibly because I have done the opposite so many times that I can both empathize with where they're at in that impulse to boil the ocean, but I can also tell them how one way of disabusing yourself of that mindset.

+ +

So I think back to actually...so I have an older sister. She was really terrible at math when we were younger. [laughs] And she was the best math teacher for me because it didn't come easy for her. Going to someone who's a math genius to help teach you what greater than or less than is is [laughs] not going to help you because it's self-evident to them. Like, how are they going to break that down for you? My sister was a great math teacher for me because her understanding of math was quite hard-won. So if I came to her and said, "Hey, I don't understand greater than or less than," which, PS, is truly what happened.

+ +

CHAD: [laughs]

+ +

JORDYN: I was like, I don't really...however, it was being explained to me did not [laughs] resonate. She was a great person to go to because she would not judge me for not understanding it, first of all, and she would have ways of breaking that down. So I'm that person for new founders, people just starting out trying to come up with a new product or explore a new opportunity. I have learned all the painful lessons on their behalf. So it's not like I'm coming to them with advice; that's just boilerplate advice I have read somewhere, and I'm now repeating to them. No, I have painfully learned these lessons. [laughs] Let me help you avoid that.

+ +

CHAD: And you said it earlier...you used the phrase like not now or not yet. And I think that's a great way of just slightly...no doesn't mean no forever. [laughs] It just means not right now, not yet. Now's not the right time.

+ +

JORDYN: Exactly.

+ +

CHAD: And I think that's a healthy way of reframing it. You're trying to strike that balance between the opportunity and the future and what you're doing today to make the product successful and get it out the door.

+ +

JORDYN: And you can do a lot of work around those bright, shiny, attractive future possibilities that make it feel...you can basically say, "Not yet, and here's what will have to happen for it to become now." You can kind of nurture those opportunities over time, and what will be the criteria to make them something you want to pursue now. It can kind of sate your desire to pursue them if you nurture the plan over time. So it's not like you just say, "Not yet," you say, "Not yet, and here's the evolving set of things that will tell us it's the right time."

+ +

And having that shared alignment on the team around what those things are but keeping your eyes on them, actively monitoring the situation to be on the lookout when now is the time can satisfy your urge to be working toward that. I think that's what's really hard for founders who really have their eyes on this big opportunity is you can sometimes feel like you're not making any progress toward it because the progress is so incremental.

+ +

So finding those practices that feed that thing for you, that keep you motivated and inspired to be working toward that long-term large goal, finding those ways to keep at it, to see the progress, keep refining why it is you're doing what you're doing and how it is you're getting there, can make you feel like you're pursuing and even when you're not [laughs] if that makes any sense. I just acknowledge that people need to do something. Just telling yourself or your team not yet is sometimes not enough because you're in it for that big vision, right?

+ +

CHAD: Right. Yeah, that's great. One of the things that stood out to me when we first met was the variety of different experiences that you've held, different positions, different roles, different things you've done. You started doing web development. You've done user experience, product management, you've been CTO, you've been CEO of companies. You did product lead and VP of product. That variety of experience, I think is more than I have. [laughs] You have held those different roles. How has that evolved for you in your career? What's been driving that forward for you?

+ +

JORDYN: I was always this product strategy person inside. I didn't necessarily know it. I didn't really even know. I mean, back in the early days of the web, a product mindset wasn't even really a thing, and advertising got a hold of the internet first. And so it was really about graphic design for a long time and a bunch of other things. But throughout that first decade that I spent as an engineer, as a front-end engineer, I was just constantly that annoying person on the team who was like, "Why are we building this? Who are we building it for? Why are we building this?"

+ +

Because what I learned is as much as I liked to code, and I liked the puzzle of solving the problem of how to turn a design into a thing people could click on, that was really fun for me, but it was only fun for a while before I started to become really sad, disappointed that we would launch things that would be market failures in the sense of, yeah, we launched a thing, and we checked the box, but no one was using it.

+ +

And I would come back and say...and I was mostly doing agency work at the time, and so there was not a lot of follow-up. We'd launch something, and then it was, like, move on to the next project. I wanted to know, was this successful? Did people use it? Are people using it? Like, how are they using it? Is it easy to use? And I wanted to answer those questions. And then, when I started to do more of that follow-up work, and then I was finding that most of the things we were launching were failures by my standards. No one cared about them. No one was using them. They were hard to use.

+ +

And I wanted to make impactful things. And so I kept asking the questions, and I kept asking them earlier and earlier. This is how I ended up in user experience design. I was like, well, can we answer these questions first? Can we make a plan before we ever put pixels to screen, so to speak, [laughs] before we start building? Can we know something so that when we do build...which I had intimate understanding of how much work it is to build software. It's not nothing. It's a big investment of time and energy. And what I wanted increasingly was for that to be time and energy well spent for the entire team and for the universe. [laughs]

+ +

And so that's how I ended up...I think of it as like swimming upstream in the sense that there's still a lot of waterfall process going on in software. And I was just constantly asking why and for whom earlier and earlier in the process, just so that we could make sure that what we were building was "The Right It," to quote a book title that a lot of folks [laughs] in startup land have read.

+ +

Like, let's make sure it's "The Right It" before we invest a lot of time and energy, and, frankly, emotion into building something. That was really where this was coming from for me is that I think at heart, secretly or not so secretly, I'm still that engineer, that front-end engineer. And I want cool projects. I want to work on cool projects with cool people that are impactful. And I think that's true of most engineers. [laughs]

+ +

No one is purely satisfied to just be given an assignment that they're supposed to execute without thinking about it. And getting into UX and then getting into product management was for me almost like a mission to make sure that by the time something got to engineering, it was a good idea. I just wanted to save engineers from terrible projects; that was my whole mission. [laughs]

+ +

CHAD: Well, at thoughtbot, we have a set of core values, and one of them is fulfillment. And in the writing around that, the phrase we often use is we want to work on products that we believe deserve to exist.

+ +

JORDYN: Yes.

+ +

CHAD: And that doesn't just mean that they have a positive impact on the world instead of a negative impact. But we're very intentional about the words we use, so there's a double meaning to that phrase. It's having a positive impact on the world, but it also means that it's the right product. This is what we should be building that it deserves to exist.

+ +

JORDYN: Yes, because you all know, we know how hard it is to make software. It's actually really hard. I think certainly building new products, you know, what a new product meant in 1920 is a very different thing than what [laughs] it means in 2022. And while it is a lot easier to bring new products into the world, like software products, internet products, it doesn't mean it's just easy. There's a lot of effort and resources that go into doing this, so let's make sure we're spending those things wisely.

+ +

Is the product idea good? Does it deserve to exist, but also, have we done our homework to validate that people want this, that they're going to use it? And to the extent that you can. There are limits to the ability of any team to forecast that. But when you bring more of this experimental mindset to it as soon as possible, it's like you up the odds that you'll end up building something valuable. And like you were saying about the word deserve, the word valuable to me is very broad, valuable to users, valuable to the business, valuable to the world. Let's create things of value if we're going to go to the trouble of creating things.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: Have you found any tools, or techniques, or things that work particularly well for doing that?

+ +

JORDYN: Yeah, and it's probably not going to be all that satisfying. There are no shortcuts, I think, is what's challenging about this. [laughs] The tool and the process that I always start with and come back to is talking to customers and talking to users if those two people are not the same. Talk to people, not about your product idea; talk to them about their lives. Talk to them about what is difficult for them, what is easy for them, what they value, and you will seldom go wrong if you start and return to that process and truly listen.

+ +

This whole thing of talking to customers and talking to users is an art in and of itself. It's not idle, you know; it's not just a thing you toss off once in a while. [laughs] It's a skill. It's an art. And that is where you begin in it. Now, that is not the whole thing. But if you're starting there or returning there, you can always do this. I talk to teams all the time who have whiffed on this step of the process, and it's fine. Like, people who are builders, especially entrepreneurs, just want to get in there and start making something, like, I get that.

+ +

CHAD: Well, I think it's the combination of really wanting to move quickly and get to something really, really quickly. But I also think there is an element of fear...

+ +

JORDYN: [laughs] Yes.

+ +

CHAD: that causes people so that these two things combined really set people up to not do this...

+ +

JORDYN: To not do this, yes.

+ +

CHAD: because they're afraid of what they'll learn. And so it's much easier to just say, "Well, I know what to build. Let's build it. And you don't need to actually talk to people who might tell you something that isn't aligned with what you think the product should be."

+ +

JORDYN: 100%, 100%. Getting over that fear is hard, and you probably will just have to fail really hard without getting over it. I mean, that was certainly my experience, I mean, like several times. [laughs] I tried to build things without talking to anyone about it. I also was one of these people that built something that...and I can get into the story, but I built something that was successful enough without talking to a single person about it. And it really sent me down a fool's path for a while because I thought that's how it worked. But yeah, that fear is real.

+ +

But I think the thing that got me around it eventually and gets me around it now is there's the rational side of this which is, well, wouldn't you rather know sooner than later that something is not a good idea or this is not a pain point? Sure. But the more visceral, emotional thing that got me around it is good ideas are actually a dime a dozen. You'll have good ideas. You'll have ten good ideas tomorrow morning. Your one idea that you have decided to explore and build out and build a company around it won't be your only idea. It is not the only good idea. [laughs] You will have more of those. If you had 1, you'll have 10.

+ +

So talking to users means you'll figure out...you'll have the opportunity to come up with more of those ideas, and one of them will be the winner. All of them are probably good ideas on some level. Having ideas isn't the problem. People are afraid of talking to customers and learning that their idea is not good, but you got to turn that on your head. You talk to customers to learn what they need, and then you'll have 20 ideas about how to solve that for them, solve that need.

+ +

The real fool's path here is to get attached to your first one idea that you had to solve a problem. It's to get attached to your problem before you have validated it. That's another pitfall here. But then to think that the first thought you had and how to solve it is going to be your only good idea, nah, you have lots of good ideas; we all do. [laughs] You'll have more.

+ +

So really just focusing on that pain point and listening to people and then really doing the work to generate more and more ideas. Even if you think you have a good solution now, it's always worth thinking about what other solutions might be constantly because your solution that you've come up with might have some feasibility issues. It might have other problems that you haven't seen yet. So it's always good to have more solutions in the hopper in case the one that you're pursuing right now doesn't turn out to be the right one.

+ +

CHAD: This is something that I don't know the answer to, and that is I do know you didn't originally start out as a developer, and it's not what your education is in.

+ +

JORDYN: [laughs] No.

+ +

CHAD: But how did you get into development?

+ +

JORDYN: [laughs] I was in college. This was just such a lucky, random thing. But I was in college, and I was in a band, a rock band. And this was early '98, maybe even fall '97. We were just at practice one day, and someone in the band was like, "We need a website." And this was when this was like a new thing that people did. [laughs] And everyone in the room just turned and looked at me. And I was like, "Oh, I'm making the website? Okay."

+ +

CHAD: Why? Were you a tech person in their mind?

+ +

JORDYN: I don't know, I guess because I seemed scrappy and capable even then. I have no idea. But I was like, all right, I'll see what I can figure out. So I wandered into the computer lab and just went to the person running the computer lab and was like, "Hey, how do I make a website?" [laughs] And this guy whose name I don't remember which is horrible, I really wish I could reach out to this guy and be like, "Hey, I have a career because of you, thank you."

+ +

CHAD: [laughs]

+ +

JORDYN: He was like, "Oh, cool. Here's what you do." And he basically opened up Netscape and was like, "Hey, there's like a..." there was like an editor. I don't even remember what it was called now. If you recall, there was an editor in Netscape. He was like, "Here's the basics of this. And here's a website," which was the... [laughs] What was the name of this website? All of the articles on this website were titled something like, so you want to make a webpage? Or so you want to make an interactive image replacement? Or so you want to host a website on a server? Whatever, like, that was all the articles.

+ +

And that website taught me how to code, and that guy put me on a path, and I just immediately was like, this is the most fun thing ever. I was like, I love this. [laughs] And it wasn't like two months before I had built the websites for a couple of departments on campus. My mom had a recruiting business at the time. She was like, "Can you make my recruiting business website?" It was just like, off to the races, which was great. But I graduated into the dot-com bust, which meant I could not get a job doing this. It's like entry-level folks always see a recession coming first, right?

+ +

CHAD: Right.

+ +

JORDYN: And everyone was like, "Oh my God, you can write HTML. You're going to get a six-figure job immediately," whatever. [laughs] And I was like, that is not what's happening here. I would have a job interview at someplace, and then they'd stop calling me. And I would find out that the company went under the day after I interviewed. That was what was happening.

+ +

So I couldn't get a job, a professional job doing this for a while. But I kept doing it on the side basically for my friends and family and eventually managed to get back into some professional [laughs] aboveboard real roles doing this work, but it was a struggle at first. And it was only just because I just really loved doing it, which, again, to circle back to something we talked about before, was kind of a liability for me for a while. Liking coding makes you really unthoughtful about what you're coding because you're always happy to do it, right? [laughs]

+ +

CHAD: Oh, I speak from personal experience, yes. [laughs]

+ +

JORDYN: Yes, right. I just wasn't thinking, is this a good idea? I was thinking great, cool; I get to code more. I love this. That was fine early on because I did get a lot of experience. And the first real job I got doing this work was at a company that was building websites for musicians, and our main client was Warner Brothers music. And so I got to build the My Chemical Romance website.

+ +

CHAD: Cool.

+ +

JORDYN: I got to build madonna.com for the Confessions on the Dance Floor release and tour.

+ +

CHAD: That's really cool.

+ +

JORDYN: Like, it was really fun. And basically, I got to build a new website every two weeks for three years which was amazing bootcamp for me. The designers there were just fantastic. I learned more than I can ever even probably understand about doing that. But partly what I learned was [laughs] this feeling of this was where that feeling began where I was like, is this the right thing? Are we building the right thing? Or is this successful? That's when I started to ask those questions: is what we're doing what people want? So anyway, it was very fun. I got into it because I was in rock bands, which is strange. I don't think people typically find lucrative careers being in rock bands. [laughs]

+ +

CHAD: I talk to a lot of people over the years through our apprenticeship program, through different things where there are people out there who connect with programming like you did and like I did. The difference is that, for whatever reason, I had that experience when I was 10. [laughs] And other people just never get the opportunity to be exposed to that until later. But it's remarkable when it happens, and you get that connection where it just connects with you at a level that almost nothing has before. It's like a constant dopamine hit when you're programming.

+ +

JORDYN: Oh, it is. Yeah, I used to joke that, basically, I felt like I got to play video games for a living because that's what it felt like. It was just one puzzle game after another. It just didn't feel like work. I got to go to work every day and solve what felt like really interesting problems and puzzles. And at the end, there was a thing people used or could look at. It just felt like I'd hit pay dirt. I felt so lucky to have found it.

+ +

But yeah, I haven't done this since the pandemic. But for several years before that, I was a Girls Who Code instructor, and being able to pay that experience forward and help middle school, high school-aged girls who hadn't necessarily had this experience yet find themselves in coding, that was really the mission me and my co-teacher had decided that was really what we were after. We didn't care if they walked away from doing this with any hard coding skills. What we wanted them to have in their minds was I can be a programmer, and that seems like fun or possible for me. That was all we wanted.

+ +

And it was so amazing to see that moment where it clicked for them where they were like, "Oh, there's like a pattern here." And yeah, see that dopamine hit thing start to set up, you know, in their brains and know that it was only going to help them. I mean, I often said to them, "Major in whatever you want in college, but get a minor in computer science; that's where your job is. [laughter] Sorry to break this to you, but this is where your job is." [laughs]

+ +

CHAD: Another thing that you've done is you've advised a lot of companies through a few different organizations: Underscore VC, the Harvard Innovation Lab. What makes a good advisor as opposed to a bad advisor?

+ +

JORDYN: This is a really hard question, actually, because it's not often entirely clear in the moment whether a given advisor is...if you feel a lot of rapport with someone and they're helping you out in the moment, that's great. But often, one finds that something an advisor told you that did not land at all at the time comes back later to be something that's really useful. So I want to say up front that what makes a good advisor is really idiosyncratic to the founder, and to the advisor, and to the moment they find themselves together in.

+ +

So with that as a big caveat, I think what I bring to this, what I go out of my way to bring to it, is that I've been in the trenches. I know what that feels like. And I trust founders, like, my job there is to just add some perspective. I've participated in building over 30 products, so I can help them. They might be doing their first product or business, and all I'm there to do is bring a bunch of other experience for them to pick some insights from. It's not actually my job, I don't think, to pre-filter that stuff for them.

+ +

I'm very practical and hands-on. They bring a problem to me, and I'm like, "Okay, here's three times I've seen that situation before. And here are three things that happened." And I basically multiply their historical experience that they can draw from; that's sort of what I bring to this.

+ +

There's another thing here when I've had valuable advisors, this thing that's kind of hard to articulate. But it's like, often early on, what you need is just someone to take you seriously, just really take you seriously as a founder and a leader. I go way out of my way to make it clear that I am doing that with them and that it is my assumption 100% that they will rise to that occasion, that they will figure out who they need to be, what resources they need to bring to bear in order to be successful.

+ +

And doing that, taking them seriously and taking their ideas seriously, taking their experiences seriously, and really demonstrating that I think they have what it takes and I think that they can rise to this occasion, I think is probably the most valuable thing because most people don't do that. They come to your idea looking to tear it down, and I think it's well-meaning. They want to stress test you and your idea. That's all well and good. But, I mean, I'm often advising underrepresented founders and what they need is confidence. They need to be built up, not torn down.

+ +

That doesn't mean I don't bring skepticism and help them try to think evermore clearly about what it is they're doing and why; I definitely do that. But there's this baseline of I think you are capable of doing this. I think you are a person who gets to do this; that is not in question for me. And that alone I think is probably the most valuable thing you can get from an advisor, [laughs] is just someone to take you seriously.

+ +

CHAD: That's great. So for folks who have been familiar with thoughtbot for a while, we have a lot of advice out there in the world for how to build products, how to validate things, exercises to run, all that kind of stuff. And we bundle all of that up in what we call our playbook. And now, as we're sort of almost 20 years into this now, that's a big resource.

+ +

And so we're doing something new, which is extracting the information that we have specifically targeted towards those earliest stages of a new product or a business into a separate playbook. You're taking your wisdom, and you're going to be able to add it to that as well. And it's going to be a little bit more targeted. So we've just launched that. And you can find it at thoughtbot.com/research-strategy-playbook. I would encourage folks to check that out.

+ +

Jordyn, when it comes to sharing, we're big at that at thoughtbot, and I'm excited to have you as part of that. Is there something that you think our approach from the fact that we're a consulting company or an agency makes it either in good ways or bad ways different than joining a product company and what you might do in a new role, or in sharing, or in working on things that we work on?

+ +

JORDYN: Yeah. I mean, I'm sure I'll have more to say about this when I've been here for a year. Having been here for a month, [laughter] this answer might be suspect. So far, anyway, the way I think about the differences here is that our role in working with product companies is to help them build the muscles to do this work, not to do it for them because they need to be able to do it going forward. We're not going to embed with them for the rest of time.

+ +

So that's a big difference, and that's both good and bad in the sense that we can maintain a certain amount of perspective because we can bring a kind of insider-outsider, like, we've done this lots and lots of times. We've seen the myriad ways that can go. And so we can bring that experience to bear while also remaining somewhat, I mean, objective is maybe a problematic word here, but some flavor of that while remaining outside of the everyday operational reality of the business. So that can be a really helpful perspective.

+ +

But I think the sort of risk there that I see is not being able to fully appreciate...that's the wrong word, but it's like, maybe not having the credibility we could have because we aren't going to be around to see this thing through. There's really, especially at early stages with projects, you really need people who are in it to win it, in it for the long haul. And so, I can see this looking like a tough sell for certain founders.

+ +

But from what I know so far, what I know about myself, what I know about thoughtbot so far is that that couldn't be further from the truth for us. We really are invested in folks' long-term success. And we do want to leverage our ability to focus and stand slightly outside of day-to-day operations to help them gain that perspective. But that is really the give and take, I think, of being a consultant rather than being part of the company.

+ +

CHAD: Now, it does make us...there are companies out there that that's not the goal, the goal is to make you dependent on them.

+ +

JORDYN: Yes, right. [laughs]

+ +

CHAD: That definitely is one of the unique things about thoughtbot is that that is not our goal. Our goal is to teach people to do what we do. But we do sometimes get criticized for, in those early stages, exactly that. It's like, where's your sense of urgency or your passion about this? And actually, we do have it. It's just the analogy I often use is we're like a professional sports team. [laughs] We make it look easy because we're really good at it.

+ +

And a lot of environments are ones where in order to make things happen, you need to create an environment of stress or those kinds of things. And that's what people are used to. And so when they start working with us, and they don't see that, they think something is wrong.

+ +

JORDYN: Yes, yes. 100%. And that is a huge cultural challenge with working with startups in general, where there is a real fire-fighting mentality. Like, let's get in there and make some stuff happen. Things are shifting constantly, and you've got to react. And I'm working 80-hour weeks to just make sure everything gets done. And I would hope..., and I've seen this to a certain extent in my month here so far, but the goal is for us to help folks work smarter, not harder, in the sense that more output does not mean more success.

+ +

We do have the experience of having worked on so many products, each of us individually and then collectively as a company. It is our goal, and it is my personal sincere hope that we can help these companies see how to do this work better and more sustainably without burning yourself out. If you happen to be successful while focused on this kind of work more output, it's only by chance you were successful there. It wasn't because you worked that hard. [laughs] And it's hard to see.

+ +

There is a lot of like hustle culture stuff out there that makes you feel like unless you are burning your candle at both ends, you're not doing it right. I think thoughtbot has the depth of experience to say," No, we can say otherwise," and to help companies figure out how to do that. I can absolutely see what you mean that people are like; these people don't have the fire in their belly, which couldn't be further from the truth. But it does feel very different from the inside.

+ +

CHAD: I feel like I could talk to you all day, [laughs] but we have to keep the episode somewhat within our normal constraints. Jordyn, thank you so much. If folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

JORDYN: So I am @skybondsor S-K-Y-B-O-N-D-S-O-R pretty much everywhere that you might want to... [laughter] A friend of mine gave me that nickname years ago. That's my handle pretty much everywhere. I spend a lot of time on Twitter, so that's probably the best place if you want to follow me or interact with me. But I'm also on LinkedIn and a lot of other places.

+ +

CHAD: And you can subscribe to the show, find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at, not as an exciting username as @skybondsor, but @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and we'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot; thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jordyn Bonds.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+lklFbQCg + + ]]> + + Chad Pytel + Jordyn Bonds + + + 450: StoryFile with Heather Maio-Smith + https://podcast.thoughtbot.com/450 + 59ebff7b-52ed-4b5b-b061-a46585fc0849 + Wed, 23 Nov 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Heather Maio-Smith is the Co-Founder, President, and Chief Visionary Officer at StoryFile, bringing global audiences an interactive ecosystem that records and preserves human conversations in a way that removes the traditional boundaries of time and space. + +Victoria talks to Heather about why this product needed to exist in the world, supporting human connection and storytelling, and the journey to get funding, expand, and plan what's next for StoryFile. + 35:22 + no + + + Heather Maio-Smith is the Co-Founder, President, and Chief Visionary Officer at StoryFile, bringing global audiences an interactive ecosystem that records and preserves human conversations in a way that removes the traditional boundaries of time and space. +Victoria talks to Heather about why this product needed to exist in the world, supporting human connection and storytelling, and the journey to get funding, expand, and plan what's next for StoryFile. +StoryFile (https://storyfile.com/) +Follow StoryFile on Twitter (https://twitter.com/storyfile), Instagram (https://www.instagram.com/storyfile/), Facebook (https://www.facebook.com/StoryFileApp), or LinkedIn (https://www.linkedin.com/company/storyfile/), or TikTok (https://www.tiktok.com/@storyfile). +Follow Heather on LinkedIn (https://www.linkedin.com/in/heather-maio-smith/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Heather Maio-Smith, Co-Founder, President, and Chief Visionary Officer at StoryFile, bringing global audiences an interactive ecosystem that records and preserves human conversations in a way that removes the traditional boundaries of time and space. Heather, thank you for joining us. +HEATHER: Thank you for having me, Victoria. I'm excited to have a conversation with you. +VICTORIA: Yes, I am really excited to learn about StoryFile and your product Conversa. Tell me a little bit about it. +HEATHER: You did a great job on the introduction; thank you. The one thing that I would add is that it's very important that people know that this is video. And this is the differentiator between us and maybe a traditional chatbot, for example. We are video-based. That could mean an actual human being creates the content. The video content is always preferable. [laughs] But you can also do it in some sneaky other ways too [laughs], so it's very interesting. +VICTORIA: Right. So as I understand it, and correct me if I'm wrong, you can record a video of a conversation and then use Conversa to turn that into an interactive video where a user has the freedom to ask their own questions. +HEATHER: Correct. Essentially, what you do is you answer whatever questions that you like. You're in charge of the storyline script. You create all the questions. The interviewee answers all of the questions via video record, and then all of those video clips are put into a database. Anyone can ask you basically any conversation. Most of them are open-ended conversations. If there are shorter, like, let's say you've only [inaudible 02:03] questions, and it's kind of a focus, you have a point, and it's a focused line of questioning, then that's obviously going to be you can't ask anything. +But we usually have the individual introduce it and say, "For example, this is my bio. I've answered a few questions about my life and my career and me personally, so feel free to ask me anything about my career or my life." Then the individuals will know what the parameters are for that conversation. And you could just ask anything, learn anything anytime you want. So it's in real-time for you. +No going on Google and searching through 20 pages to get an answer anymore. You should be able to talk the ideas. You should be able to talk to someone who's lived that experience or has that knowledge, ask them a question, and find out the information that you want to find out, or get to know somebody that you would never have the opportunity to talk to. +VICTORIA: What an interesting idea. And what led you to think that this was a product that needed to exist in the world? +HEATHER: Well, they say that necessity is the mother of invention. I happened to be in Holocaust education back in the early 2000s. And one of the main things that the entire field was concerned about is what are we going to do when the Holocaust survivors are no longer alive? They had spent over 60 years in the public telling their story, talking to students, for example the public. They've done documentaries; they've done books; they've done interviews. The Shoah Foundation at USC has 55,000 narrative interviews. So it's very well-documented. +But the one thing that we weren't able to replicate yet, and this is what we were worried about, was they couldn't make that personal connection. And how do they make that personal connection? It's through people asking their own questions and actually engaging with those individuals that that's when the real magic happened. I mean, that's when people felt connected to these individuals and that story, that history. That was what I didn't want to lose after they had passed away. +And so I thought to myself, there's got to be a way to replicate the Q&A, you know, the question and answer conversation where I can ask my own question, which leads me to learn deeper than if I was passively watching a video or even listening to a lecture. +So I went to the Shoah Foundation, and I said, "There's got to be a way to do this." They said after many conversations, "Okay. You might not be crazy. [laughs] or as crazy as we thought you were at the beginning. But we still don't know how you're going to do it. So go away and figure out how you're going to do it, and then come back to us when you've figured it out." That was my challenge. +And luckily, I found an amazing team to help us all figure out how to do it. And we got to the part where we had to take these individuals, like, the video recordings, and we had to have people actually ask them questions and have these conversations so that we could populate the database for a more accurate conversation. And so I was in the public for a couple of years all over the world. +And the one question I kept getting the most was, "This is amazing. Can I do this myself? And can I do this with my parents? Can I do this with my grandparents? Can I do this with the founder of our company?" And people came to me, and they had so many ideas. "This would be great for this. Oh my gosh, could you imagine doing this?" And after a while, you say to yourself, okay, what would it look like if we did this for everyone? What would it look like if we made it ubiquitous, allow everybody to replace their FAQs? +Every leader in this country, every CEO, every influencer, or any individual who's got something to say that we can all learn from, which, by the way, is pretty much everyone on the planet. They can tell their story, and they can talk about their experiences, and we can learn from that. Even saving time on interviewing future candidates in person. You narrow it down to 10 people. You have them do StoryFiles. You actually engage with their StoryFile, and then you just choose two that you want to meet in person, possibly saving you hours and hours of time. +It's just about asking questions and getting an answer in the moment when you need it, not waiting for an email, not going through 20 pages of Google. And it's also about connecting with a real person instead of these chatbots that everybody's trying to move away from. And I think they're trying to move towards avatars because they're more visual, but it's still not a human being. So it's still kind of an automated voice, and they're not real. And there's no emotion, and you don't have any body language. +So what if you could just ask a person? You probably get asked some of the same questions. And in the next 2 minutes, you could probably think of 10 questions that you get asked almost daily. So what if you did a StoryFile? You answered all those ten questions and maybe more, and then you never had to have that conversation again. Think of all the time that those people now, if they get in front of you, they don't have to waste time asking any of those typical, basic questions. They can just get right into a deeper conversation with you. +VICTORIA: I love it. Yeah, I'm already thinking in the back of my mind, like, oh, I could use these for what if you're trying to show what it's like to work at thoughtbot? And you just want to ask someone at thoughtbot a question, and you could play with StoryFile. Yeah, I think it's enormously useful. And I love the story starts with a hugely impactful mission of capturing those stories. And I wonder how that experience of the importance of storytelling has had on your ability to get funding and get this project through as a founder. +HEATHER: It's been a journey. [laughter] First of all, let me say that I think it has been slightly more complex than most startups because, from the onset or the get-go, or whatever you want to call it, this technology has been meant for consumers and businesses alike. So you've got a B2C play, and you've got a B2B play, which is very complicated for investors to understand maybe and really get the vision in its totality. +So it's been a struggle to communicate it in a way that people really understand this can be done. You're creating a whole new medium. This is not an I'm creating a new rocking chair type of thing that's better than the other chair that you had. I'm creating a chair. It's a new kind of chair. And you have to take these people on a journey to understanding how much better their lives can be and how much time they can save if they just invest a little bit of time, which they kind of have to do anyway. +I mean, look at it, you spend so much time writing FAQs for a website and finding all the answers, and then putting them all together and putting them in the website. You could spend the same amount of time actually getting all those questions, recording yourself answering them. In fact, it probably would take less time. Record the answer, and then, bam, you have it. Everybody can actually talk to you, ask you those questions, and you can guide them. And they get the benefit of actually feeling as though they've talked to a human being. They've connected with you emotionally, and everyone's better off for it. +The investors have been...they either absolutely get behind you 100% and love what you're doing and want to be on the journey with you, or they are a bit we'll wait and see. There hasn't been one investor, though, that has said, "You're not onto something. I don't believe in what you're doing, and your idea is not going to work," not one. So we know it has legs. And we just have to build the body and get it from the walking stage, walk to run. +VICTORIA: Right. And I see you have quite an impressive client list already. And you recently won an award for best software as a service product for education and nonprofits in the learning and CSR category, so that's impressive. And I want to hear more about how that process has been scaling from you had one initial customer who was the Holocaust Museum, and now you've expanded, and what kind of lessons you might have about that experience, getting to the walking stage, and what you have planned coming ahead. +HEATHER: I don't know if I have much advice, actually. [laughter] I could probably use more advice than I can give. Every day, you know, you take it one day at a time, and you move forward. We haven't forgotten where we started, which was in enabling audiences through museums and public spaces to enable them to have these conversations with people that they would not normally get to talk to. +There's this studio professional services side of this as well. Then you have, all right, we had to have a back end. We had to have a platform in order to run our business. What if we made that platform available to other companies? Okay, what does that mean? And how does one build that? Then is it built intuitively and easily enough for people to actually do what they want to do with it, which is create these interactive conversational video AI modules (We call them StoryFiles.) for a variety of different cases? +I mean, think about every kid can talk to one of the best teachers in the world and learn from them. Every possible person that wants to go on a date could actually talk to potential people. And those people don't even know that they're having these first-date conversations with them, so it saves you that first meeting, that awkward first date. But it also allows you to make a better choice for that first date or, like I said, screening or even onboarding and corporate training. +All those manuals that people have written everything and all the information that's in there, nobody wants to go to a manual and look up an answer. No, you're going to go to someone that you think knows the answer, and you're going to ask them. So why not just pull out your phone and do that on your phone, you know? Like, Walmart has this amazing thing that they call financial mentor. They did StoryFiles for new store managers. It's all around answering those questions that you would get as a new manager that you would have running the day-to-day of a Walmart store. +So they can literally pull out their phone. They've got their own Walmart learning management system on the phone, and they can talk to a financial mentor and ask them questions. So, what do I do if I have a register that's this? Or I forgot what the form is that you use for this. Or what do I do if my endcaps aren't really churning enough buzz and businesses I think it should be? All those questions that you're going to ask in the first couple of years of taking on a new position. So it's basically anywhere that you have questions and people normally give you answers, you can do a StoryFile. +VICTORIA: Yeah, it sounds like a real change to the way people do business and how you can automate some of those conversations and provide a more human touch too. +HEATHER: Yeah, it's all about that human touch, isn't it? The one reason I think that people now, you know, for the last three years, everybody's been obsessed with these avatar chatbots, but they're not really solving the problem. The problem is the chatbots don't seem real. You don't feel as if you're having a conversation with an actual person, and that's what frustrates you the most because they don't understand. They don't seem like they're being empathetic. They don't seem like you're relatable. And there's also the uncanny valley, and then the automated voices, and the cadence, and all of that. So this solves all that. +VICTORIA: 80% of communication is non-verbal, right? +HEATHER: Yeah, yeah, exactly, exactly, but nobody really thinks about that. [laughter] We do digital recreations; notice I'm not calling it an avatar because we do an authentic version of an individual. And most of the time, 99% of the time, the person's not alive anymore. But we work with the archives; we work with the foundations; we work with the families. Nothing that we have that digital recreation say is anything that we've made up. It's always based on what they've actually said and the way that they've said it. +So we review, like, we did one digital recreation that we reviewed over 1,700 hours of video. The key thing was getting an actor that physically looked like the individual, and it has to be a method actor. The method actor also reviews some of those videos and really gets a sense of who that individual was. Then they form the basis for the digital recreation for the body language, for the facial expressions, for the cadence of the voice. +And then, you do the face mapping and other special effects that you might have to do to the body. Then you do the voice cloning so that you get the person's actual voice. So it's a really detailed process. And what you end up with is probably the most authentic version of an individual that can be created. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +VICTORIA: You mentioned avatars. But that process also sounds different than what I've heard about deepfakes as well. Do you want to -- +HEATHER: Yeah. Well, our digital recreations are based on more authentic...they're probably as authentic as you can get to the actual individual. It's not based on, you know, avatars still; even if you do one that's based on 10 minutes of video of yourself, you will still have the uncanny valley. You will still have the broken cadence. You'll still have an automated voice where it sounds automated. They are getting better, and they'll continue to get better. +But there's no avatar that you can honestly tell me is going to accurately convey emotion and those non-verbal cues. They can't do it. A computer cannot intuit it. You have to have the individual. You have to have something based from the actual person in order to get the most accurate you can get. An avatar who you're basically treating as a visual chatbot you're just typing in the answers. So there's no emotional connection. There's no body language or cadence that you can connect with in that. +VICTORIA: That makes sense. And I can clearly see the...we've talked about the business use cases a little bit. But on the individual consumer side, I'm thinking about making a StoryFile of my grandpa from Pasadena and the value what that would be like to have that family member have a realistic portrayal of them for future generations to interact with. +HEATHER: It's priceless. And he's still alive, right? +VICTORIA: Yeah. +HEATHER: So it's not a realistic portrait. It is him. You could do a StoryFile life. You'd go to StoryFile life. You'd pick out all the questions you wanted to ask him, add your own questions. Every family has got those five stories that individuals always tell at the dinner table during Thanksgiving or something. So you want to make sure you capture all of those. +Let's say that he responds to a question that you've asked. And the beauty of it, by the way, is these are questions that you probably would not normally ask somebody in daily conversation. So you really get a sense of who they are from day one, you know, from their childhood all the way through their life today. +If they say something that you're like, wait a minute, stop, [laughs] you've got to explain that, you can add a question, add a follow-up question and just say, "Can you tell me more about that?" or "Explain yourself. Like, how did you come to that? How did you make that decision? What went into this move and this shift?" or whatever you want to know more about. "Or how did that affect your family?" you know, so many questions. So it allows you to ask all of those questions. +You record your grandfather, which, by the way, is an amazing experience for you; forget him, [laughter], but it's an amazing experience for you. And I guarantee you; you will learn something. To date, I have not had one family say that they haven't learned something or heard a story that they never heard before. +So it's a really interesting process. And you feel bonded to that individual after you're done talking and doing this interview in a way that you didn't before. Then you have that recording of this individual that your grandchildren, your great-grandchildren will be able to get a sense of who this individual was, and what their life was like, and who they were to you even. +That's priceless to be able to give, you know, we hang on, you go into ancestry.com; you pull up a ship's manifest. And you see your relative's signature. Okay, fine. But what do you really know about that person? Nothing. You know they came over on a ship. [laughs] And you see maybe how their signature looked, but that doesn't really tell you anything. So we want to change all that. We want to flip it all out. We want you to know all of your ancestors. We want your kids to know everybody and learn from them. +VICTORIA: I love that. And it's an interesting intersection of this very core human emotion to AI technology or this leading-edge technology. And I wonder, what has surprised you in the technology building side about what ways it easily supports making this human connection and other ways where it's still a challenge to make everything connect? +HEATHER: I would have loved to have gotten at least three PhDs [laughs], and then I can think over the last 12 years. Okay, so I started this in 2009. So you got to remember there was no Skype, really. I mean, Skype came into its own...it existed in 2008, but it didn't really come into its own until 2012. +Speech recognition wasn't really a thing. We knew it was going to happen, but it wasn't there yet. That was one of the big things that people had to really take a leap of faith with me that we could even get this to work. We didn't know if it would do what we thought it would do. And we were doing this completely...it was a passion play. It was; let's see if we can do this type of thing. We actually did. It did fulfill what I envisioned it being and doing. It did finally fulfill, and I realized that in 2016, so it took that long. +And in order to make it ubiquitous for everyone, and you know this because you build software, and you help people with products: to do something for the general public and to make it ubiquitous, and make it scalable, that's a whole nother ballgame. We're taking a process that was incredibly manual...everyone says, "Oh, AI is going to take over the world." No, it's not. No, it's not. It's not even close. It's still so manual. It's based on data. And whatever you manually put in is what you get out. +In order to take that and make it automated in whatever ways you can and then keep dreaming about a day where, for example, the follow-up questions that I talked to you about. One day on our roadmap, God willing, next year, you will be able to get that follow-up question actually suggested to you because the computer will know what that individual has said. And the computer will figure out here's a question that you might want to ask, which has never been done before. +And there are several things that we have on our roadmap that haven't been done before, but we've been in this zone where you know, other companies have tried. One of our advisors was president of Google Americas. And when she came on board with us, she said, "Google tried to do something similar to this in the early 2000s." But it was just a little too early, and they couldn't figure it out. So they scrapped the whole thing. +And with software, timing has a lot to do with it. Your expectations and what you think you can do and when you can do it have to be constantly monitored and constantly re-evaluated. And do the best you can with what is technically available at the moment, and then plan to see how you might make that evolve or improve that or add to that. For example, the field of natural language processing it's at one stage right now, but we have things that we want to do with it and advances that we'd like to see happen. And we're going to have to make those happen if we want to see those happen. +VICTORIA: You had both the timing and the need and just enough technology progression to make something happen when you did, and you were able to grow it. It sounds like your family is also involved in helping you along the journey. And I was curious to hear about how that has been for you and -- +HEATHER: Okay, so it's not really fair because I grew up in a family-owned business. I'm totally used to it. Everybody asked me, "What's it like working with your husband, and what's it like?" You know, along this journey, we've had various family members working for us, and honestly, that's mostly been a necessity. They happened to be the most skilled and the most talented people to do the job at the moment that I had access to. They got it, you know, it's sort of like the game, okay, tag, you're it. [laughs] +Some of them have gone on to do other things; one started her own app called Camber. The other started a PR agency and is doing very well. The other went on to do structural engineering, and the other one is still working for us. And Stephen's my husband's oldest, and I have told her many times even though she does want to go to law school at some point, I said, "No, I'm never letting you leave. [laughter] You're never leaving me." +Yeah, it's kind of not fair because we happen to have the ideal situation where Stephen and I are both passionate and have a very clear vision of what we want to do and how to get there, which I think you do need. We respect each other tremendously. I'm in awe of him almost every day. I can see where in a lot of families, it would be problematic but somehow not for us. It worked really well. +With investors, it is kind of tricky because you don't want to seem like you're a mom-and-pop shop, either. That's definitely not what we are. We're very focused, and we're very intentional. To some investors, it might seem like we're all over the place because of the B2C and the B2B thing, but it's really not. We explained to them that we're actually building one thing, and that's conversational video. That's what we're doing. It's a big vision, that's all, and it's a massive market. +VICTORIA: Yeah, I believe it. I mean, having people in your corner who believe in your vision and you have respect for working for each other, whether they're your blood family or your chosen family, that's what really you need to be successful. And I think it's a common theme we see across people who are able to create these products is that they have a team around them. [laughs] It's never just one person. +HEATHER: Yeah, no, it's never just one person. And I've been really, really fortunate. You talk about family that you've chosen. I've been really fortunate to have a lot of the team members who were on this journey with me back in 2010. So that's how far we all go with this and trying to evolve this technology and build this medium and this way of communicating. We're in it. We're all in it for better or worse. +VICTORIA: Yeah, I agree. And I assume that that amount of loyalty from your team over that long time is a pro point for investors as well. And I'm curious, so if you could record a StoryFile for yourself now to send back in time to when you were first starting this up, I wonder what questions you would ask yourself [laughs] to be able to give you the advice you needed when you were just starting. +HEATHER: To give me advice now? +VICTORIA: If you were going to create a StoryFile for when you were starting out if you could be able to ask yourself questions from the future. [laughs] +HEATHER: I think it would probably be very interesting to see where I was at, and what I was thinking, what we were dealing with at the time because I think it's some of the things you forget, you know, how you were feeling. We did a lot of video recording back in the early days, especially around different milestones and then different lows and highs. +But if I could give myself some advice now, knowing what I know now, it would be your typical don't give up. There are days when you feel like that's it; I can't go any longer. It's not sustainable. You just don't know how it's going to turn out. And you have customers that you're really, really...we're very customer-oriented, so we work really closely with them to make them successful. And there have been times when what they've wanted to do hasn't been something that we were able to achieve entirely. +So I would say just keep your head down, keep doing the work every day. Keep moving forward, and just believe in how you're ultimately going to change the world with this. So I think that I believed that 100% ten years ago as well. [laughs] I probably would have said the same thing, actually. +There was a woman that had told me she wanted to do a StoryFile with her 10-year-old. And then she wanted to do the same script every five years, but especially do the same thing right before they go to college and then when they come back when they've finished college and do the same interview. I said, "It's a brilliant idea, but why specifically before they go to college and when they get back?" She says, "I want them to see how much they've changed." That makes me cry every time. It's so true. +I don't know if you have kids; between Stephen and I, we have five, and they're all 20 to 31. And that time in their lives, from 17 to 22 to 24, you change so radically. I mean, it's almost like you go back, and it's almost like you've got a one-year-old to see how much they changed by the time they're six. It's that radical. I thought that was just a beautiful thing on her part to think of, you know, think of doing. +VICTORIA: Yeah, that sounds great. I don't have any kids myself. I do have a two-year-old and a one-year-old niece and nephew. Maybe we'll create one for them when they get a little bit older. +HEATHER: Well, then you have to do...is your grandfather their great-grandfather? +VICTORIA: No, he's my husband's grandpa, actually. +HEATHER: Because when you do your grandfather, then they'll get to know them. You know, there's something about our identity, and it's made up of our parents, you know, our lives, our influences on our lives, and everybody that lived before us. So our point is, why not get to know those people the best way you can? And is that by reading their story? Is it listening to a voicemail that they left you before they passed away in order to get a sense of who they are? Or is it a video of them on a vacation, you know, a video clip? Or is it a story? +Or would you want a StoryFile where you can actually have a conversation? You can feel as if you're sitting down at a kitchen table, talking and asking them questions about their life. We want you to do it with everybody, [laughs] even your boss. +[laughter] +VICTORIA: Right? I think it's a hugely powerful way to connect with people. And if I can get my grandpa to stop watching tennis for long enough to do it, I'll do it. [laughs] +HEATHER: I definitely guarantee you can do that. [laughs] +VICTORIA: Right? I think we can. I think we can do it. I think you'll enjoy it as much as I will. So I really appreciate you sharing this capability with us. And is there a way you want to shout out how people can connect with the tool? +HEATHER: Go to storyfile.com. If it's for your family, for you personally, go to StoryFile Life from that website. And if you're a business, you can go to Conversa also from that website and ask for a free demo. +VICTORIA: Excellent. And is there anything you want to give as a final takeaway to our listeners today? +HEATHER: It's easy to do. And it's always better to personally connect with someone if you can. Give them the opportunity to really see you, and listen to you, and hear you, the real you. And it doesn't take a lot of time. Everyone has a story to tell or knowledge to impart, experiences to talk about. There's no one on the planet that doesn't, honestly. But you probably doing these podcasts every one you talk to you learn from. It's sharing our knowledge. It's sharing humanity's experiences and knowledge so that we absorb that and we have that. It influences us, hopefully, in a good way. +VICTORIA: I think that's beautiful. Thank you so much for sharing with us and being with us here today. +HEATHER: Thank you for having me. Keep up the great work, you guys. +VICTORIA: Oh, thank you. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Heather Maio-Smith. + + + Heather Maio-Smith is the Co-Founder, President, and Chief Visionary Officer at StoryFile, bringing global audiences an interactive ecosystem that records and preserves human conversations in a way that removes the traditional boundaries of time and space.

+ +

Victoria talks to Heather about why this product needed to exist in the world, supporting human connection and storytelling, and the journey to get funding, expand, and plan what's next for StoryFile.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Heather Maio-Smith, Co-Founder, President, and Chief Visionary Officer at StoryFile, bringing global audiences an interactive ecosystem that records and preserves human conversations in a way that removes the traditional boundaries of time and space. Heather, thank you for joining us.

+ +

HEATHER: Thank you for having me, Victoria. I'm excited to have a conversation with you.

+ +

VICTORIA: Yes, I am really excited to learn about StoryFile and your product Conversa. Tell me a little bit about it.

+ +

HEATHER: You did a great job on the introduction; thank you. The one thing that I would add is that it's very important that people know that this is video. And this is the differentiator between us and maybe a traditional chatbot, for example. We are video-based. That could mean an actual human being creates the content. The video content is always preferable. [laughs] But you can also do it in some sneaky other ways too [laughs], so it's very interesting.

+ +

VICTORIA: Right. So as I understand it, and correct me if I'm wrong, you can record a video of a conversation and then use Conversa to turn that into an interactive video where a user has the freedom to ask their own questions.

+ +

HEATHER: Correct. Essentially, what you do is you answer whatever questions that you like. You're in charge of the storyline script. You create all the questions. The interviewee answers all of the questions via video record, and then all of those video clips are put into a database. Anyone can ask you basically any conversation. Most of them are open-ended conversations. If there are shorter, like, let's say you've only [inaudible 02:03] questions, and it's kind of a focus, you have a point, and it's a focused line of questioning, then that's obviously going to be you can't ask anything.

+ +

But we usually have the individual introduce it and say, "For example, this is my bio. I've answered a few questions about my life and my career and me personally, so feel free to ask me anything about my career or my life." Then the individuals will know what the parameters are for that conversation. And you could just ask anything, learn anything anytime you want. So it's in real-time for you.

+ +

No going on Google and searching through 20 pages to get an answer anymore. You should be able to talk the ideas. You should be able to talk to someone who's lived that experience or has that knowledge, ask them a question, and find out the information that you want to find out, or get to know somebody that you would never have the opportunity to talk to.

+ +

VICTORIA: What an interesting idea. And what led you to think that this was a product that needed to exist in the world?

+ +

HEATHER: Well, they say that necessity is the mother of invention. I happened to be in Holocaust education back in the early 2000s. And one of the main things that the entire field was concerned about is what are we going to do when the Holocaust survivors are no longer alive? They had spent over 60 years in the public telling their story, talking to students, for example the public. They've done documentaries; they've done books; they've done interviews. The Shoah Foundation at USC has 55,000 narrative interviews. So it's very well-documented.

+ +

But the one thing that we weren't able to replicate yet, and this is what we were worried about, was they couldn't make that personal connection. And how do they make that personal connection? It's through people asking their own questions and actually engaging with those individuals that that's when the real magic happened. I mean, that's when people felt connected to these individuals and that story, that history. That was what I didn't want to lose after they had passed away.

+ +

And so I thought to myself, there's got to be a way to replicate the Q&A, you know, the question and answer conversation where I can ask my own question, which leads me to learn deeper than if I was passively watching a video or even listening to a lecture.

+ +

So I went to the Shoah Foundation, and I said, "There's got to be a way to do this." They said after many conversations, "Okay. You might not be crazy. [laughs] or as crazy as we thought you were at the beginning. But we still don't know how you're going to do it. So go away and figure out how you're going to do it, and then come back to us when you've figured it out." That was my challenge.

+ +

And luckily, I found an amazing team to help us all figure out how to do it. And we got to the part where we had to take these individuals, like, the video recordings, and we had to have people actually ask them questions and have these conversations so that we could populate the database for a more accurate conversation. And so I was in the public for a couple of years all over the world.

+ +

And the one question I kept getting the most was, "This is amazing. Can I do this myself? And can I do this with my parents? Can I do this with my grandparents? Can I do this with the founder of our company?" And people came to me, and they had so many ideas. "This would be great for this. Oh my gosh, could you imagine doing this?" And after a while, you say to yourself, okay, what would it look like if we did this for everyone? What would it look like if we made it ubiquitous, allow everybody to replace their FAQs?

+ +

Every leader in this country, every CEO, every influencer, or any individual who's got something to say that we can all learn from, which, by the way, is pretty much everyone on the planet. They can tell their story, and they can talk about their experiences, and we can learn from that. Even saving time on interviewing future candidates in person. You narrow it down to 10 people. You have them do StoryFiles. You actually engage with their StoryFile, and then you just choose two that you want to meet in person, possibly saving you hours and hours of time.

+ +

It's just about asking questions and getting an answer in the moment when you need it, not waiting for an email, not going through 20 pages of Google. And it's also about connecting with a real person instead of these chatbots that everybody's trying to move away from. And I think they're trying to move towards avatars because they're more visual, but it's still not a human being. So it's still kind of an automated voice, and they're not real. And there's no emotion, and you don't have any body language.

+ +

So what if you could just ask a person? You probably get asked some of the same questions. And in the next 2 minutes, you could probably think of 10 questions that you get asked almost daily. So what if you did a StoryFile? You answered all those ten questions and maybe more, and then you never had to have that conversation again. Think of all the time that those people now, if they get in front of you, they don't have to waste time asking any of those typical, basic questions. They can just get right into a deeper conversation with you.

+ +

VICTORIA: I love it. Yeah, I'm already thinking in the back of my mind, like, oh, I could use these for what if you're trying to show what it's like to work at thoughtbot? And you just want to ask someone at thoughtbot a question, and you could play with StoryFile. Yeah, I think it's enormously useful. And I love the story starts with a hugely impactful mission of capturing those stories. And I wonder how that experience of the importance of storytelling has had on your ability to get funding and get this project through as a founder.

+ +

HEATHER: It's been a journey. [laughter] First of all, let me say that I think it has been slightly more complex than most startups because, from the onset or the get-go, or whatever you want to call it, this technology has been meant for consumers and businesses alike. So you've got a B2C play, and you've got a B2B play, which is very complicated for investors to understand maybe and really get the vision in its totality.

+ +

So it's been a struggle to communicate it in a way that people really understand this can be done. You're creating a whole new medium. This is not an I'm creating a new rocking chair type of thing that's better than the other chair that you had. I'm creating a chair. It's a new kind of chair. And you have to take these people on a journey to understanding how much better their lives can be and how much time they can save if they just invest a little bit of time, which they kind of have to do anyway.

+ +

I mean, look at it, you spend so much time writing FAQs for a website and finding all the answers, and then putting them all together and putting them in the website. You could spend the same amount of time actually getting all those questions, recording yourself answering them. In fact, it probably would take less time. Record the answer, and then, bam, you have it. Everybody can actually talk to you, ask you those questions, and you can guide them. And they get the benefit of actually feeling as though they've talked to a human being. They've connected with you emotionally, and everyone's better off for it.

+ +

The investors have been...they either absolutely get behind you 100% and love what you're doing and want to be on the journey with you, or they are a bit we'll wait and see. There hasn't been one investor, though, that has said, "You're not onto something. I don't believe in what you're doing, and your idea is not going to work," not one. So we know it has legs. And we just have to build the body and get it from the walking stage, walk to run.

+ +

VICTORIA: Right. And I see you have quite an impressive client list already. And you recently won an award for best software as a service product for education and nonprofits in the learning and CSR category, so that's impressive. And I want to hear more about how that process has been scaling from you had one initial customer who was the Holocaust Museum, and now you've expanded, and what kind of lessons you might have about that experience, getting to the walking stage, and what you have planned coming ahead.

+ +

HEATHER: I don't know if I have much advice, actually. [laughter] I could probably use more advice than I can give. Every day, you know, you take it one day at a time, and you move forward. We haven't forgotten where we started, which was in enabling audiences through museums and public spaces to enable them to have these conversations with people that they would not normally get to talk to.

+ +

There's this studio professional services side of this as well. Then you have, all right, we had to have a back end. We had to have a platform in order to run our business. What if we made that platform available to other companies? Okay, what does that mean? And how does one build that? Then is it built intuitively and easily enough for people to actually do what they want to do with it, which is create these interactive conversational video AI modules (We call them StoryFiles.) for a variety of different cases?

+ +

I mean, think about every kid can talk to one of the best teachers in the world and learn from them. Every possible person that wants to go on a date could actually talk to potential people. And those people don't even know that they're having these first-date conversations with them, so it saves you that first meeting, that awkward first date. But it also allows you to make a better choice for that first date or, like I said, screening or even onboarding and corporate training.

+ +

All those manuals that people have written everything and all the information that's in there, nobody wants to go to a manual and look up an answer. No, you're going to go to someone that you think knows the answer, and you're going to ask them. So why not just pull out your phone and do that on your phone, you know? Like, Walmart has this amazing thing that they call financial mentor. They did StoryFiles for new store managers. It's all around answering those questions that you would get as a new manager that you would have running the day-to-day of a Walmart store.

+ +

So they can literally pull out their phone. They've got their own Walmart learning management system on the phone, and they can talk to a financial mentor and ask them questions. So, what do I do if I have a register that's this? Or I forgot what the form is that you use for this. Or what do I do if my endcaps aren't really churning enough buzz and businesses I think it should be? All those questions that you're going to ask in the first couple of years of taking on a new position. So it's basically anywhere that you have questions and people normally give you answers, you can do a StoryFile.

+ +

VICTORIA: Yeah, it sounds like a real change to the way people do business and how you can automate some of those conversations and provide a more human touch too.

+ +

HEATHER: Yeah, it's all about that human touch, isn't it? The one reason I think that people now, you know, for the last three years, everybody's been obsessed with these avatar chatbots, but they're not really solving the problem. The problem is the chatbots don't seem real. You don't feel as if you're having a conversation with an actual person, and that's what frustrates you the most because they don't understand. They don't seem like they're being empathetic. They don't seem like you're relatable. And there's also the uncanny valley, and then the automated voices, and the cadence, and all of that. So this solves all that.

+ +

VICTORIA: 80% of communication is non-verbal, right?

+ +

HEATHER: Yeah, yeah, exactly, exactly, but nobody really thinks about that. [laughter] We do digital recreations; notice I'm not calling it an avatar because we do an authentic version of an individual. And most of the time, 99% of the time, the person's not alive anymore. But we work with the archives; we work with the foundations; we work with the families. Nothing that we have that digital recreation say is anything that we've made up. It's always based on what they've actually said and the way that they've said it.

+ +

So we review, like, we did one digital recreation that we reviewed over 1,700 hours of video. The key thing was getting an actor that physically looked like the individual, and it has to be a method actor. The method actor also reviews some of those videos and really gets a sense of who that individual was. Then they form the basis for the digital recreation for the body language, for the facial expressions, for the cadence of the voice.

+ +

And then, you do the face mapping and other special effects that you might have to do to the body. Then you do the voice cloning so that you get the person's actual voice. So it's a really detailed process. And what you end up with is probably the most authentic version of an individual that can be created.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: You mentioned avatars. But that process also sounds different than what I've heard about deepfakes as well. Do you want to --

+ +

HEATHER: Yeah. Well, our digital recreations are based on more authentic...they're probably as authentic as you can get to the actual individual. It's not based on, you know, avatars still; even if you do one that's based on 10 minutes of video of yourself, you will still have the uncanny valley. You will still have the broken cadence. You'll still have an automated voice where it sounds automated. They are getting better, and they'll continue to get better.

+ +

But there's no avatar that you can honestly tell me is going to accurately convey emotion and those non-verbal cues. They can't do it. A computer cannot intuit it. You have to have the individual. You have to have something based from the actual person in order to get the most accurate you can get. An avatar who you're basically treating as a visual chatbot you're just typing in the answers. So there's no emotional connection. There's no body language or cadence that you can connect with in that.

+ +

VICTORIA: That makes sense. And I can clearly see the...we've talked about the business use cases a little bit. But on the individual consumer side, I'm thinking about making a StoryFile of my grandpa from Pasadena and the value what that would be like to have that family member have a realistic portrayal of them for future generations to interact with.

+ +

HEATHER: It's priceless. And he's still alive, right?

+ +

VICTORIA: Yeah.

+ +

HEATHER: So it's not a realistic portrait. It is him. You could do a StoryFile life. You'd go to StoryFile life. You'd pick out all the questions you wanted to ask him, add your own questions. Every family has got those five stories that individuals always tell at the dinner table during Thanksgiving or something. So you want to make sure you capture all of those.

+ +

Let's say that he responds to a question that you've asked. And the beauty of it, by the way, is these are questions that you probably would not normally ask somebody in daily conversation. So you really get a sense of who they are from day one, you know, from their childhood all the way through their life today.

+ +

If they say something that you're like, wait a minute, stop, [laughs] you've got to explain that, you can add a question, add a follow-up question and just say, "Can you tell me more about that?" or "Explain yourself. Like, how did you come to that? How did you make that decision? What went into this move and this shift?" or whatever you want to know more about. "Or how did that affect your family?" you know, so many questions. So it allows you to ask all of those questions.

+ +

You record your grandfather, which, by the way, is an amazing experience for you; forget him, [laughter], but it's an amazing experience for you. And I guarantee you; you will learn something. To date, I have not had one family say that they haven't learned something or heard a story that they never heard before.

+ +

So it's a really interesting process. And you feel bonded to that individual after you're done talking and doing this interview in a way that you didn't before. Then you have that recording of this individual that your grandchildren, your great-grandchildren will be able to get a sense of who this individual was, and what their life was like, and who they were to you even.

+ +

That's priceless to be able to give, you know, we hang on, you go into ancestry.com; you pull up a ship's manifest. And you see your relative's signature. Okay, fine. But what do you really know about that person? Nothing. You know they came over on a ship. [laughs] And you see maybe how their signature looked, but that doesn't really tell you anything. So we want to change all that. We want to flip it all out. We want you to know all of your ancestors. We want your kids to know everybody and learn from them.

+ +

VICTORIA: I love that. And it's an interesting intersection of this very core human emotion to AI technology or this leading-edge technology. And I wonder, what has surprised you in the technology building side about what ways it easily supports making this human connection and other ways where it's still a challenge to make everything connect?

+ +

HEATHER: I would have loved to have gotten at least three PhDs [laughs], and then I can think over the last 12 years. Okay, so I started this in 2009. So you got to remember there was no Skype, really. I mean, Skype came into its own...it existed in 2008, but it didn't really come into its own until 2012.

+ +

Speech recognition wasn't really a thing. We knew it was going to happen, but it wasn't there yet. That was one of the big things that people had to really take a leap of faith with me that we could even get this to work. We didn't know if it would do what we thought it would do. And we were doing this completely...it was a passion play. It was; let's see if we can do this type of thing. We actually did. It did fulfill what I envisioned it being and doing. It did finally fulfill, and I realized that in 2016, so it took that long.

+ +

And in order to make it ubiquitous for everyone, and you know this because you build software, and you help people with products: to do something for the general public and to make it ubiquitous, and make it scalable, that's a whole nother ballgame. We're taking a process that was incredibly manual...everyone says, "Oh, AI is going to take over the world." No, it's not. No, it's not. It's not even close. It's still so manual. It's based on data. And whatever you manually put in is what you get out.

+ +

In order to take that and make it automated in whatever ways you can and then keep dreaming about a day where, for example, the follow-up questions that I talked to you about. One day on our roadmap, God willing, next year, you will be able to get that follow-up question actually suggested to you because the computer will know what that individual has said. And the computer will figure out here's a question that you might want to ask, which has never been done before.

+ +

And there are several things that we have on our roadmap that haven't been done before, but we've been in this zone where you know, other companies have tried. One of our advisors was president of Google Americas. And when she came on board with us, she said, "Google tried to do something similar to this in the early 2000s." But it was just a little too early, and they couldn't figure it out. So they scrapped the whole thing.

+ +

And with software, timing has a lot to do with it. Your expectations and what you think you can do and when you can do it have to be constantly monitored and constantly re-evaluated. And do the best you can with what is technically available at the moment, and then plan to see how you might make that evolve or improve that or add to that. For example, the field of natural language processing it's at one stage right now, but we have things that we want to do with it and advances that we'd like to see happen. And we're going to have to make those happen if we want to see those happen.

+ +

VICTORIA: You had both the timing and the need and just enough technology progression to make something happen when you did, and you were able to grow it. It sounds like your family is also involved in helping you along the journey. And I was curious to hear about how that has been for you and --

+ +

HEATHER: Okay, so it's not really fair because I grew up in a family-owned business. I'm totally used to it. Everybody asked me, "What's it like working with your husband, and what's it like?" You know, along this journey, we've had various family members working for us, and honestly, that's mostly been a necessity. They happened to be the most skilled and the most talented people to do the job at the moment that I had access to. They got it, you know, it's sort of like the game, okay, tag, you're it. [laughs]

+ +

Some of them have gone on to do other things; one started her own app called Camber. The other started a PR agency and is doing very well. The other went on to do structural engineering, and the other one is still working for us. And Stephen's my husband's oldest, and I have told her many times even though she does want to go to law school at some point, I said, "No, I'm never letting you leave. [laughter] You're never leaving me."

+ +

Yeah, it's kind of not fair because we happen to have the ideal situation where Stephen and I are both passionate and have a very clear vision of what we want to do and how to get there, which I think you do need. We respect each other tremendously. I'm in awe of him almost every day. I can see where in a lot of families, it would be problematic but somehow not for us. It worked really well.

+ +

With investors, it is kind of tricky because you don't want to seem like you're a mom-and-pop shop, either. That's definitely not what we are. We're very focused, and we're very intentional. To some investors, it might seem like we're all over the place because of the B2C and the B2B thing, but it's really not. We explained to them that we're actually building one thing, and that's conversational video. That's what we're doing. It's a big vision, that's all, and it's a massive market.

+ +

VICTORIA: Yeah, I believe it. I mean, having people in your corner who believe in your vision and you have respect for working for each other, whether they're your blood family or your chosen family, that's what really you need to be successful. And I think it's a common theme we see across people who are able to create these products is that they have a team around them. [laughs] It's never just one person.

+ +

HEATHER: Yeah, no, it's never just one person. And I've been really, really fortunate. You talk about family that you've chosen. I've been really fortunate to have a lot of the team members who were on this journey with me back in 2010. So that's how far we all go with this and trying to evolve this technology and build this medium and this way of communicating. We're in it. We're all in it for better or worse.

+ +

VICTORIA: Yeah, I agree. And I assume that that amount of loyalty from your team over that long time is a pro point for investors as well. And I'm curious, so if you could record a StoryFile for yourself now to send back in time to when you were first starting this up, I wonder what questions you would ask yourself [laughs] to be able to give you the advice you needed when you were just starting.

+ +

HEATHER: To give me advice now?

+ +

VICTORIA: If you were going to create a StoryFile for when you were starting out if you could be able to ask yourself questions from the future. [laughs]

+ +

HEATHER: I think it would probably be very interesting to see where I was at, and what I was thinking, what we were dealing with at the time because I think it's some of the things you forget, you know, how you were feeling. We did a lot of video recording back in the early days, especially around different milestones and then different lows and highs.

+ +

But if I could give myself some advice now, knowing what I know now, it would be your typical don't give up. There are days when you feel like that's it; I can't go any longer. It's not sustainable. You just don't know how it's going to turn out. And you have customers that you're really, really...we're very customer-oriented, so we work really closely with them to make them successful. And there have been times when what they've wanted to do hasn't been something that we were able to achieve entirely.

+ +

So I would say just keep your head down, keep doing the work every day. Keep moving forward, and just believe in how you're ultimately going to change the world with this. So I think that I believed that 100% ten years ago as well. [laughs] I probably would have said the same thing, actually.

+ +

There was a woman that had told me she wanted to do a StoryFile with her 10-year-old. And then she wanted to do the same script every five years, but especially do the same thing right before they go to college and then when they come back when they've finished college and do the same interview. I said, "It's a brilliant idea, but why specifically before they go to college and when they get back?" She says, "I want them to see how much they've changed." That makes me cry every time. It's so true.

+ +

I don't know if you have kids; between Stephen and I, we have five, and they're all 20 to 31. And that time in their lives, from 17 to 22 to 24, you change so radically. I mean, it's almost like you go back, and it's almost like you've got a one-year-old to see how much they changed by the time they're six. It's that radical. I thought that was just a beautiful thing on her part to think of, you know, think of doing.

+ +

VICTORIA: Yeah, that sounds great. I don't have any kids myself. I do have a two-year-old and a one-year-old niece and nephew. Maybe we'll create one for them when they get a little bit older.

+ +

HEATHER: Well, then you have to do...is your grandfather their great-grandfather?

+ +

VICTORIA: No, he's my husband's grandpa, actually.

+ +

HEATHER: Because when you do your grandfather, then they'll get to know them. You know, there's something about our identity, and it's made up of our parents, you know, our lives, our influences on our lives, and everybody that lived before us. So our point is, why not get to know those people the best way you can? And is that by reading their story? Is it listening to a voicemail that they left you before they passed away in order to get a sense of who they are? Or is it a video of them on a vacation, you know, a video clip? Or is it a story?

+ +

Or would you want a StoryFile where you can actually have a conversation? You can feel as if you're sitting down at a kitchen table, talking and asking them questions about their life. We want you to do it with everybody, [laughs] even your boss.

+ +

[laughter]

+ +

VICTORIA: Right? I think it's a hugely powerful way to connect with people. And if I can get my grandpa to stop watching tennis for long enough to do it, I'll do it. [laughs]

+ +

HEATHER: I definitely guarantee you can do that. [laughs]

+ +

VICTORIA: Right? I think we can. I think we can do it. I think you'll enjoy it as much as I will. So I really appreciate you sharing this capability with us. And is there a way you want to shout out how people can connect with the tool?

+ +

HEATHER: Go to storyfile.com. If it's for your family, for you personally, go to StoryFile Life from that website. And if you're a business, you can go to Conversa also from that website and ask for a free demo.

+ +

VICTORIA: Excellent. And is there anything you want to give as a final takeaway to our listeners today?

+ +

HEATHER: It's easy to do. And it's always better to personally connect with someone if you can. Give them the opportunity to really see you, and listen to you, and hear you, the real you. And it doesn't take a lot of time. Everyone has a story to tell or knowledge to impart, experiences to talk about. There's no one on the planet that doesn't, honestly. But you probably doing these podcasts every one you talk to you learn from. It's sharing our knowledge. It's sharing humanity's experiences and knowledge so that we absorb that and we have that. It influences us, hopefully, in a good way.

+ +

VICTORIA: I think that's beautiful. Thank you so much for sharing with us and being with us here today.

+ +

HEATHER: Thank you for having me. Keep up the great work, you guys.

+ +

VICTORIA: Oh, thank you. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Heather Maio-Smith.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Heather Maio-Smith is the Co-Founder, President, and Chief Visionary Officer at StoryFile, bringing global audiences an interactive ecosystem that records and preserves human conversations in a way that removes the traditional boundaries of time and space.

+ +

Victoria talks to Heather about why this product needed to exist in the world, supporting human connection and storytelling, and the journey to get funding, expand, and plan what's next for StoryFile.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Heather Maio-Smith, Co-Founder, President, and Chief Visionary Officer at StoryFile, bringing global audiences an interactive ecosystem that records and preserves human conversations in a way that removes the traditional boundaries of time and space. Heather, thank you for joining us.

+ +

HEATHER: Thank you for having me, Victoria. I'm excited to have a conversation with you.

+ +

VICTORIA: Yes, I am really excited to learn about StoryFile and your product Conversa. Tell me a little bit about it.

+ +

HEATHER: You did a great job on the introduction; thank you. The one thing that I would add is that it's very important that people know that this is video. And this is the differentiator between us and maybe a traditional chatbot, for example. We are video-based. That could mean an actual human being creates the content. The video content is always preferable. [laughs] But you can also do it in some sneaky other ways too [laughs], so it's very interesting.

+ +

VICTORIA: Right. So as I understand it, and correct me if I'm wrong, you can record a video of a conversation and then use Conversa to turn that into an interactive video where a user has the freedom to ask their own questions.

+ +

HEATHER: Correct. Essentially, what you do is you answer whatever questions that you like. You're in charge of the storyline script. You create all the questions. The interviewee answers all of the questions via video record, and then all of those video clips are put into a database. Anyone can ask you basically any conversation. Most of them are open-ended conversations. If there are shorter, like, let's say you've only [inaudible 02:03] questions, and it's kind of a focus, you have a point, and it's a focused line of questioning, then that's obviously going to be you can't ask anything.

+ +

But we usually have the individual introduce it and say, "For example, this is my bio. I've answered a few questions about my life and my career and me personally, so feel free to ask me anything about my career or my life." Then the individuals will know what the parameters are for that conversation. And you could just ask anything, learn anything anytime you want. So it's in real-time for you.

+ +

No going on Google and searching through 20 pages to get an answer anymore. You should be able to talk the ideas. You should be able to talk to someone who's lived that experience or has that knowledge, ask them a question, and find out the information that you want to find out, or get to know somebody that you would never have the opportunity to talk to.

+ +

VICTORIA: What an interesting idea. And what led you to think that this was a product that needed to exist in the world?

+ +

HEATHER: Well, they say that necessity is the mother of invention. I happened to be in Holocaust education back in the early 2000s. And one of the main things that the entire field was concerned about is what are we going to do when the Holocaust survivors are no longer alive? They had spent over 60 years in the public telling their story, talking to students, for example the public. They've done documentaries; they've done books; they've done interviews. The Shoah Foundation at USC has 55,000 narrative interviews. So it's very well-documented.

+ +

But the one thing that we weren't able to replicate yet, and this is what we were worried about, was they couldn't make that personal connection. And how do they make that personal connection? It's through people asking their own questions and actually engaging with those individuals that that's when the real magic happened. I mean, that's when people felt connected to these individuals and that story, that history. That was what I didn't want to lose after they had passed away.

+ +

And so I thought to myself, there's got to be a way to replicate the Q&A, you know, the question and answer conversation where I can ask my own question, which leads me to learn deeper than if I was passively watching a video or even listening to a lecture.

+ +

So I went to the Shoah Foundation, and I said, "There's got to be a way to do this." They said after many conversations, "Okay. You might not be crazy. [laughs] or as crazy as we thought you were at the beginning. But we still don't know how you're going to do it. So go away and figure out how you're going to do it, and then come back to us when you've figured it out." That was my challenge.

+ +

And luckily, I found an amazing team to help us all figure out how to do it. And we got to the part where we had to take these individuals, like, the video recordings, and we had to have people actually ask them questions and have these conversations so that we could populate the database for a more accurate conversation. And so I was in the public for a couple of years all over the world.

+ +

And the one question I kept getting the most was, "This is amazing. Can I do this myself? And can I do this with my parents? Can I do this with my grandparents? Can I do this with the founder of our company?" And people came to me, and they had so many ideas. "This would be great for this. Oh my gosh, could you imagine doing this?" And after a while, you say to yourself, okay, what would it look like if we did this for everyone? What would it look like if we made it ubiquitous, allow everybody to replace their FAQs?

+ +

Every leader in this country, every CEO, every influencer, or any individual who's got something to say that we can all learn from, which, by the way, is pretty much everyone on the planet. They can tell their story, and they can talk about their experiences, and we can learn from that. Even saving time on interviewing future candidates in person. You narrow it down to 10 people. You have them do StoryFiles. You actually engage with their StoryFile, and then you just choose two that you want to meet in person, possibly saving you hours and hours of time.

+ +

It's just about asking questions and getting an answer in the moment when you need it, not waiting for an email, not going through 20 pages of Google. And it's also about connecting with a real person instead of these chatbots that everybody's trying to move away from. And I think they're trying to move towards avatars because they're more visual, but it's still not a human being. So it's still kind of an automated voice, and they're not real. And there's no emotion, and you don't have any body language.

+ +

So what if you could just ask a person? You probably get asked some of the same questions. And in the next 2 minutes, you could probably think of 10 questions that you get asked almost daily. So what if you did a StoryFile? You answered all those ten questions and maybe more, and then you never had to have that conversation again. Think of all the time that those people now, if they get in front of you, they don't have to waste time asking any of those typical, basic questions. They can just get right into a deeper conversation with you.

+ +

VICTORIA: I love it. Yeah, I'm already thinking in the back of my mind, like, oh, I could use these for what if you're trying to show what it's like to work at thoughtbot? And you just want to ask someone at thoughtbot a question, and you could play with StoryFile. Yeah, I think it's enormously useful. And I love the story starts with a hugely impactful mission of capturing those stories. And I wonder how that experience of the importance of storytelling has had on your ability to get funding and get this project through as a founder.

+ +

HEATHER: It's been a journey. [laughter] First of all, let me say that I think it has been slightly more complex than most startups because, from the onset or the get-go, or whatever you want to call it, this technology has been meant for consumers and businesses alike. So you've got a B2C play, and you've got a B2B play, which is very complicated for investors to understand maybe and really get the vision in its totality.

+ +

So it's been a struggle to communicate it in a way that people really understand this can be done. You're creating a whole new medium. This is not an I'm creating a new rocking chair type of thing that's better than the other chair that you had. I'm creating a chair. It's a new kind of chair. And you have to take these people on a journey to understanding how much better their lives can be and how much time they can save if they just invest a little bit of time, which they kind of have to do anyway.

+ +

I mean, look at it, you spend so much time writing FAQs for a website and finding all the answers, and then putting them all together and putting them in the website. You could spend the same amount of time actually getting all those questions, recording yourself answering them. In fact, it probably would take less time. Record the answer, and then, bam, you have it. Everybody can actually talk to you, ask you those questions, and you can guide them. And they get the benefit of actually feeling as though they've talked to a human being. They've connected with you emotionally, and everyone's better off for it.

+ +

The investors have been...they either absolutely get behind you 100% and love what you're doing and want to be on the journey with you, or they are a bit we'll wait and see. There hasn't been one investor, though, that has said, "You're not onto something. I don't believe in what you're doing, and your idea is not going to work," not one. So we know it has legs. And we just have to build the body and get it from the walking stage, walk to run.

+ +

VICTORIA: Right. And I see you have quite an impressive client list already. And you recently won an award for best software as a service product for education and nonprofits in the learning and CSR category, so that's impressive. And I want to hear more about how that process has been scaling from you had one initial customer who was the Holocaust Museum, and now you've expanded, and what kind of lessons you might have about that experience, getting to the walking stage, and what you have planned coming ahead.

+ +

HEATHER: I don't know if I have much advice, actually. [laughter] I could probably use more advice than I can give. Every day, you know, you take it one day at a time, and you move forward. We haven't forgotten where we started, which was in enabling audiences through museums and public spaces to enable them to have these conversations with people that they would not normally get to talk to.

+ +

There's this studio professional services side of this as well. Then you have, all right, we had to have a back end. We had to have a platform in order to run our business. What if we made that platform available to other companies? Okay, what does that mean? And how does one build that? Then is it built intuitively and easily enough for people to actually do what they want to do with it, which is create these interactive conversational video AI modules (We call them StoryFiles.) for a variety of different cases?

+ +

I mean, think about every kid can talk to one of the best teachers in the world and learn from them. Every possible person that wants to go on a date could actually talk to potential people. And those people don't even know that they're having these first-date conversations with them, so it saves you that first meeting, that awkward first date. But it also allows you to make a better choice for that first date or, like I said, screening or even onboarding and corporate training.

+ +

All those manuals that people have written everything and all the information that's in there, nobody wants to go to a manual and look up an answer. No, you're going to go to someone that you think knows the answer, and you're going to ask them. So why not just pull out your phone and do that on your phone, you know? Like, Walmart has this amazing thing that they call financial mentor. They did StoryFiles for new store managers. It's all around answering those questions that you would get as a new manager that you would have running the day-to-day of a Walmart store.

+ +

So they can literally pull out their phone. They've got their own Walmart learning management system on the phone, and they can talk to a financial mentor and ask them questions. So, what do I do if I have a register that's this? Or I forgot what the form is that you use for this. Or what do I do if my endcaps aren't really churning enough buzz and businesses I think it should be? All those questions that you're going to ask in the first couple of years of taking on a new position. So it's basically anywhere that you have questions and people normally give you answers, you can do a StoryFile.

+ +

VICTORIA: Yeah, it sounds like a real change to the way people do business and how you can automate some of those conversations and provide a more human touch too.

+ +

HEATHER: Yeah, it's all about that human touch, isn't it? The one reason I think that people now, you know, for the last three years, everybody's been obsessed with these avatar chatbots, but they're not really solving the problem. The problem is the chatbots don't seem real. You don't feel as if you're having a conversation with an actual person, and that's what frustrates you the most because they don't understand. They don't seem like they're being empathetic. They don't seem like you're relatable. And there's also the uncanny valley, and then the automated voices, and the cadence, and all of that. So this solves all that.

+ +

VICTORIA: 80% of communication is non-verbal, right?

+ +

HEATHER: Yeah, yeah, exactly, exactly, but nobody really thinks about that. [laughter] We do digital recreations; notice I'm not calling it an avatar because we do an authentic version of an individual. And most of the time, 99% of the time, the person's not alive anymore. But we work with the archives; we work with the foundations; we work with the families. Nothing that we have that digital recreation say is anything that we've made up. It's always based on what they've actually said and the way that they've said it.

+ +

So we review, like, we did one digital recreation that we reviewed over 1,700 hours of video. The key thing was getting an actor that physically looked like the individual, and it has to be a method actor. The method actor also reviews some of those videos and really gets a sense of who that individual was. Then they form the basis for the digital recreation for the body language, for the facial expressions, for the cadence of the voice.

+ +

And then, you do the face mapping and other special effects that you might have to do to the body. Then you do the voice cloning so that you get the person's actual voice. So it's a really detailed process. And what you end up with is probably the most authentic version of an individual that can be created.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

VICTORIA: You mentioned avatars. But that process also sounds different than what I've heard about deepfakes as well. Do you want to --

+ +

HEATHER: Yeah. Well, our digital recreations are based on more authentic...they're probably as authentic as you can get to the actual individual. It's not based on, you know, avatars still; even if you do one that's based on 10 minutes of video of yourself, you will still have the uncanny valley. You will still have the broken cadence. You'll still have an automated voice where it sounds automated. They are getting better, and they'll continue to get better.

+ +

But there's no avatar that you can honestly tell me is going to accurately convey emotion and those non-verbal cues. They can't do it. A computer cannot intuit it. You have to have the individual. You have to have something based from the actual person in order to get the most accurate you can get. An avatar who you're basically treating as a visual chatbot you're just typing in the answers. So there's no emotional connection. There's no body language or cadence that you can connect with in that.

+ +

VICTORIA: That makes sense. And I can clearly see the...we've talked about the business use cases a little bit. But on the individual consumer side, I'm thinking about making a StoryFile of my grandpa from Pasadena and the value what that would be like to have that family member have a realistic portrayal of them for future generations to interact with.

+ +

HEATHER: It's priceless. And he's still alive, right?

+ +

VICTORIA: Yeah.

+ +

HEATHER: So it's not a realistic portrait. It is him. You could do a StoryFile life. You'd go to StoryFile life. You'd pick out all the questions you wanted to ask him, add your own questions. Every family has got those five stories that individuals always tell at the dinner table during Thanksgiving or something. So you want to make sure you capture all of those.

+ +

Let's say that he responds to a question that you've asked. And the beauty of it, by the way, is these are questions that you probably would not normally ask somebody in daily conversation. So you really get a sense of who they are from day one, you know, from their childhood all the way through their life today.

+ +

If they say something that you're like, wait a minute, stop, [laughs] you've got to explain that, you can add a question, add a follow-up question and just say, "Can you tell me more about that?" or "Explain yourself. Like, how did you come to that? How did you make that decision? What went into this move and this shift?" or whatever you want to know more about. "Or how did that affect your family?" you know, so many questions. So it allows you to ask all of those questions.

+ +

You record your grandfather, which, by the way, is an amazing experience for you; forget him, [laughter], but it's an amazing experience for you. And I guarantee you; you will learn something. To date, I have not had one family say that they haven't learned something or heard a story that they never heard before.

+ +

So it's a really interesting process. And you feel bonded to that individual after you're done talking and doing this interview in a way that you didn't before. Then you have that recording of this individual that your grandchildren, your great-grandchildren will be able to get a sense of who this individual was, and what their life was like, and who they were to you even.

+ +

That's priceless to be able to give, you know, we hang on, you go into ancestry.com; you pull up a ship's manifest. And you see your relative's signature. Okay, fine. But what do you really know about that person? Nothing. You know they came over on a ship. [laughs] And you see maybe how their signature looked, but that doesn't really tell you anything. So we want to change all that. We want to flip it all out. We want you to know all of your ancestors. We want your kids to know everybody and learn from them.

+ +

VICTORIA: I love that. And it's an interesting intersection of this very core human emotion to AI technology or this leading-edge technology. And I wonder, what has surprised you in the technology building side about what ways it easily supports making this human connection and other ways where it's still a challenge to make everything connect?

+ +

HEATHER: I would have loved to have gotten at least three PhDs [laughs], and then I can think over the last 12 years. Okay, so I started this in 2009. So you got to remember there was no Skype, really. I mean, Skype came into its own...it existed in 2008, but it didn't really come into its own until 2012.

+ +

Speech recognition wasn't really a thing. We knew it was going to happen, but it wasn't there yet. That was one of the big things that people had to really take a leap of faith with me that we could even get this to work. We didn't know if it would do what we thought it would do. And we were doing this completely...it was a passion play. It was; let's see if we can do this type of thing. We actually did. It did fulfill what I envisioned it being and doing. It did finally fulfill, and I realized that in 2016, so it took that long.

+ +

And in order to make it ubiquitous for everyone, and you know this because you build software, and you help people with products: to do something for the general public and to make it ubiquitous, and make it scalable, that's a whole nother ballgame. We're taking a process that was incredibly manual...everyone says, "Oh, AI is going to take over the world." No, it's not. No, it's not. It's not even close. It's still so manual. It's based on data. And whatever you manually put in is what you get out.

+ +

In order to take that and make it automated in whatever ways you can and then keep dreaming about a day where, for example, the follow-up questions that I talked to you about. One day on our roadmap, God willing, next year, you will be able to get that follow-up question actually suggested to you because the computer will know what that individual has said. And the computer will figure out here's a question that you might want to ask, which has never been done before.

+ +

And there are several things that we have on our roadmap that haven't been done before, but we've been in this zone where you know, other companies have tried. One of our advisors was president of Google Americas. And when she came on board with us, she said, "Google tried to do something similar to this in the early 2000s." But it was just a little too early, and they couldn't figure it out. So they scrapped the whole thing.

+ +

And with software, timing has a lot to do with it. Your expectations and what you think you can do and when you can do it have to be constantly monitored and constantly re-evaluated. And do the best you can with what is technically available at the moment, and then plan to see how you might make that evolve or improve that or add to that. For example, the field of natural language processing it's at one stage right now, but we have things that we want to do with it and advances that we'd like to see happen. And we're going to have to make those happen if we want to see those happen.

+ +

VICTORIA: You had both the timing and the need and just enough technology progression to make something happen when you did, and you were able to grow it. It sounds like your family is also involved in helping you along the journey. And I was curious to hear about how that has been for you and --

+ +

HEATHER: Okay, so it's not really fair because I grew up in a family-owned business. I'm totally used to it. Everybody asked me, "What's it like working with your husband, and what's it like?" You know, along this journey, we've had various family members working for us, and honestly, that's mostly been a necessity. They happened to be the most skilled and the most talented people to do the job at the moment that I had access to. They got it, you know, it's sort of like the game, okay, tag, you're it. [laughs]

+ +

Some of them have gone on to do other things; one started her own app called Camber. The other started a PR agency and is doing very well. The other went on to do structural engineering, and the other one is still working for us. And Stephen's my husband's oldest, and I have told her many times even though she does want to go to law school at some point, I said, "No, I'm never letting you leave. [laughter] You're never leaving me."

+ +

Yeah, it's kind of not fair because we happen to have the ideal situation where Stephen and I are both passionate and have a very clear vision of what we want to do and how to get there, which I think you do need. We respect each other tremendously. I'm in awe of him almost every day. I can see where in a lot of families, it would be problematic but somehow not for us. It worked really well.

+ +

With investors, it is kind of tricky because you don't want to seem like you're a mom-and-pop shop, either. That's definitely not what we are. We're very focused, and we're very intentional. To some investors, it might seem like we're all over the place because of the B2C and the B2B thing, but it's really not. We explained to them that we're actually building one thing, and that's conversational video. That's what we're doing. It's a big vision, that's all, and it's a massive market.

+ +

VICTORIA: Yeah, I believe it. I mean, having people in your corner who believe in your vision and you have respect for working for each other, whether they're your blood family or your chosen family, that's what really you need to be successful. And I think it's a common theme we see across people who are able to create these products is that they have a team around them. [laughs] It's never just one person.

+ +

HEATHER: Yeah, no, it's never just one person. And I've been really, really fortunate. You talk about family that you've chosen. I've been really fortunate to have a lot of the team members who were on this journey with me back in 2010. So that's how far we all go with this and trying to evolve this technology and build this medium and this way of communicating. We're in it. We're all in it for better or worse.

+ +

VICTORIA: Yeah, I agree. And I assume that that amount of loyalty from your team over that long time is a pro point for investors as well. And I'm curious, so if you could record a StoryFile for yourself now to send back in time to when you were first starting this up, I wonder what questions you would ask yourself [laughs] to be able to give you the advice you needed when you were just starting.

+ +

HEATHER: To give me advice now?

+ +

VICTORIA: If you were going to create a StoryFile for when you were starting out if you could be able to ask yourself questions from the future. [laughs]

+ +

HEATHER: I think it would probably be very interesting to see where I was at, and what I was thinking, what we were dealing with at the time because I think it's some of the things you forget, you know, how you were feeling. We did a lot of video recording back in the early days, especially around different milestones and then different lows and highs.

+ +

But if I could give myself some advice now, knowing what I know now, it would be your typical don't give up. There are days when you feel like that's it; I can't go any longer. It's not sustainable. You just don't know how it's going to turn out. And you have customers that you're really, really...we're very customer-oriented, so we work really closely with them to make them successful. And there have been times when what they've wanted to do hasn't been something that we were able to achieve entirely.

+ +

So I would say just keep your head down, keep doing the work every day. Keep moving forward, and just believe in how you're ultimately going to change the world with this. So I think that I believed that 100% ten years ago as well. [laughs] I probably would have said the same thing, actually.

+ +

There was a woman that had told me she wanted to do a StoryFile with her 10-year-old. And then she wanted to do the same script every five years, but especially do the same thing right before they go to college and then when they come back when they've finished college and do the same interview. I said, "It's a brilliant idea, but why specifically before they go to college and when they get back?" She says, "I want them to see how much they've changed." That makes me cry every time. It's so true.

+ +

I don't know if you have kids; between Stephen and I, we have five, and they're all 20 to 31. And that time in their lives, from 17 to 22 to 24, you change so radically. I mean, it's almost like you go back, and it's almost like you've got a one-year-old to see how much they changed by the time they're six. It's that radical. I thought that was just a beautiful thing on her part to think of, you know, think of doing.

+ +

VICTORIA: Yeah, that sounds great. I don't have any kids myself. I do have a two-year-old and a one-year-old niece and nephew. Maybe we'll create one for them when they get a little bit older.

+ +

HEATHER: Well, then you have to do...is your grandfather their great-grandfather?

+ +

VICTORIA: No, he's my husband's grandpa, actually.

+ +

HEATHER: Because when you do your grandfather, then they'll get to know them. You know, there's something about our identity, and it's made up of our parents, you know, our lives, our influences on our lives, and everybody that lived before us. So our point is, why not get to know those people the best way you can? And is that by reading their story? Is it listening to a voicemail that they left you before they passed away in order to get a sense of who they are? Or is it a video of them on a vacation, you know, a video clip? Or is it a story?

+ +

Or would you want a StoryFile where you can actually have a conversation? You can feel as if you're sitting down at a kitchen table, talking and asking them questions about their life. We want you to do it with everybody, [laughs] even your boss.

+ +

[laughter]

+ +

VICTORIA: Right? I think it's a hugely powerful way to connect with people. And if I can get my grandpa to stop watching tennis for long enough to do it, I'll do it. [laughs]

+ +

HEATHER: I definitely guarantee you can do that. [laughs]

+ +

VICTORIA: Right? I think we can. I think we can do it. I think you'll enjoy it as much as I will. So I really appreciate you sharing this capability with us. And is there a way you want to shout out how people can connect with the tool?

+ +

HEATHER: Go to storyfile.com. If it's for your family, for you personally, go to StoryFile Life from that website. And if you're a business, you can go to Conversa also from that website and ask for a free demo.

+ +

VICTORIA: Excellent. And is there anything you want to give as a final takeaway to our listeners today?

+ +

HEATHER: It's easy to do. And it's always better to personally connect with someone if you can. Give them the opportunity to really see you, and listen to you, and hear you, the real you. And it doesn't take a lot of time. Everyone has a story to tell or knowledge to impart, experiences to talk about. There's no one on the planet that doesn't, honestly. But you probably doing these podcasts every one you talk to you learn from. It's sharing our knowledge. It's sharing humanity's experiences and knowledge so that we absorb that and we have that. It influences us, hopefully, in a good way.

+ +

VICTORIA: I think that's beautiful. Thank you so much for sharing with us and being with us here today.

+ +

HEATHER: Thank you for having me. Keep up the great work, you guys.

+ +

VICTORIA: Oh, thank you. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Heather Maio-Smith.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ylwGmFP6 + + ]]> + + Victoria Guido + Heather Maio-Smith + + + 449: Welcome, Will Larry! + https://podcast.thoughtbot.com/449 + 2f92206e-e949-49b1-a353-ab81304d1631 + Thu, 17 Nov 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Will Larry, Software Developer at thoughtbot, joins Giant Robots as host! 🎉 + +Will talks about how he got into tech, how everything is going so far at thoughtbot, interviewing at thoughtbot previously but not getting the job, and why he decided to interview again (and snagging the job!) + 35:43 + no + + + Will Larry, Software Developer at thoughtbot, joins Giant Robots as host! 🎉 +Will talks about how he got into tech, how everything is going so far at thoughtbot, interviewing at thoughtbot previously, but not getting the job, and why he decided to interview again (and snagged the job!) +Follow Will on Twitter (https://twitter.com/will23larry) and LinkedIn (https://www.linkedin.com/in/william-larry/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. +VICTORIA: I'm your other host, Victoria Guido. And with us today is our brand new third co-host, Will Larry. Will is a React and React Native developer at thoughtbot. And we're so excited to have him join us as a co-host of the show. +CHAD: Will, thank you so much for joining us. Congratulations and welcome. Woo-hoo. +[applause] +WILL: Thank you for having me. I'm excited. +CHAD: Will, I was so excited when I put out the call for people to join as co-hosts, and Victoria raised her hand, and then you did as well. You were on parental leave when all that started to happen. And so congratulations again on your new family member, and I'm glad we could finally have you join us. +WILL: Yeah, I was excited about it. When I thought about joining, there are two things that came about: the excitement of joining and just the fear of it. +CHAD: [laughs] +WILL: And I was like, I need to do this. I need to do this because it will make me better. So I'm excited to be here. +VICTORIA: That's a lot of change to navigate in one year, Will. [laughs] How's that got going for you, and how's everything so far in your first time here at thoughtbot? +WILL: Yes, change, change, change, that's what has been this year. I changed and started working at thoughtbot, our third kid. This year, we moved to Florida, just a lot of change. But I've learned along the way that change is life, and so we just embraced it. And I'm hoping that we're kind of settling out a little bit, but it's been good. It's been great for our kids. I think they're ready for some consistency and just the same thing over and over for a little bit. But it's been good. And we made it through. We're on the other side. +CHAD: Was there a grand plan to all the change? Like, did you have everything planned out in advance? Or did it all sort of just happen one thing after the other? +WILL: Yes. If you know anything about me, I'm a very big planner. My wife, my spouse she is the one that pushes me to be more spontaneous, but this was too big to be spontaneous, so it was definitely planned. It actually got changed. We were supposed to move in September, but with the birth of my son, we decided to move it up and move sooner. +VICTORIA: Right. I'm going to ask you the same question but about your career. So you made a big change from operations into mobile development, and was that part of a grand plan, or did you happen upon it? How did you make that change? +WILL: That change was kind of out of desperation. I was in operations working for a nonprofit; I loved it. My spouse was working at the same company, and I was a promotion ahead of her. It was an amazing opportunity. But the teams are so small that we couldn't be on the same team. So they had multiple locations throughout the country. And you don't have to step off the team, but if she's going to take this promotion, you have to step off the team. There potentially is a way that, down the road, you can come back. +And Katie is my spouse. She has been so supportive of everything that I've ever done. And I just felt this was a time, a great time for me to show that I support her in everything she did. But it was probably one of the toughest times in my life. I didn't have a job. I thought that I can easily jump back into it and find a job. I ended up working at a clothing store, which is not my strong suit. I really struggled working there. I think I worked there a month, and I was like, I can't do this. And then, I went to work at a different company, a travel insurance company, and so I would process the data. +I was miserable, and that's an understatement. I was so miserable. One day my spouse came in, and she said, "Hey, we got to change this. You're not doing well. Let's dream a little bit." And normally, that's not my personality. Normally I'm like Xs and Os. I know what's coming. And I was so out of it. I was like, let's do this. And she asked me a couple of questions. And one of the questions was, "If you could do anything, what would you do?" I thought about it. +And I came from a small town in Louisiana. And I never had the opportunity to work with computers. It was just the resources weren't there. And so that was one of the things I said, "Hey, I want to work with computers in any way that I can." She was like, "Go figure it out, whatever it takes." And then I told her I was like, "It's going to cost some money for me to do this," because I went to bootcamp. And she was like, "Go do it. Let's invest in you. Let's make this happen." +I ended up going through the bootcamp and came out on the other side. Interesting story; it's interesting how things come back around. My first interview was at thoughtbot. I bombed it. [laughter] I wasn't on thoughtbot's team at that point. But the way that it was handled, I got a glimpse of the culture. +I remember walking out that day and saying I'll be back. I will be back to be a part of this company because I bombed it. But they still spent time with me explaining things, teaching me the things that I bombed. And so I was like, wow, that's what I want to do in this field. So yeah, that's how I got into development. Here I am. +CHAD: Was there anything that surprised you about development, about the tech world? +WILL: Yes, yes. I think the biggest thing was the growth in development. So in any of my other jobs, I was able to take in expectations and make a plan and, like, okay, check off. I can knock that out and be successful. And I tried that in development, and every one of my bosses would say, "Slow down. It takes time. It takes time." And I just didn't realize how long it would take for me to grow in my coding skills. +That was the biggest surprise for me because I just couldn't come through, and okay, I got it, let's go. Because I'm very big on I know my expectations, okay, I can meet those expectations, and then I'll go over and beyond. But I couldn't do that in this field. And I think that was the biggest surprise for me that I couldn't just show up at work and do my task and still be a great developer. +VICTORIA: Right. And I love that you're sharing that story. Because with the people I've worked with at Women Who Code, it's a very common struggle when you're starting out in your first time as a developer and getting comfortable with being not great for the first six months or a year, or however long it takes. And I think that it's important to share that and make sure that other people feel the same way. And you might feel that way for a long time and maybe forever [laughs] if you keep switching up your roles in tech. +WILL: Yeah, definitely. And it was a very humbling experience also because, in most of my other jobs, I was the leader. I was the person that had direct reports and leading people. But in this job, I started at the very bottom. I remember there were days when I couldn't even get through my tasks and had to really lean on others to help me through it. You know, my senior developer, I was like, "Hey, it's that time. I got some questions for you." And so, I had to learn how does Will learn and what's the best way for me to excel in this field? The things that I've done before, I couldn't do it going forward. +CHAD: Bootcamps are pretty popular. And they are an avenue that certainly didn't exist when I was learning. You said when you were having the conversation with your wife that it sounds like that was just right there as the path forward. But did you consider an alternative path? +WILL: Yeah. So at that time, I felt like there were probably three paths: there was the bootcamp, there was the college degree, and there was the self-learning path. So the college degree, I thought about it because, at that time, I felt like a lot of companies were still like, hey, you have to have a degree to be hired and be a part of it. So whenever I thought about going back, I didn't know if it was going to cut me off from other jobs, so that was one of the reasons why I really decided, or I really thought about going the degree route. +And I decided against it because I did a lot of research, and there were companies at that time that were like, you don't need a college degree because I already had a college degree in sports medicine. And so most of them were like, you just have to have a degree. And I was like, okay, I don't think I'm going to be stuck in this position because I didn't have a computer science degree. +The other way was self-taught. I didn't think that I could put in the time and the work. One thing I learned very, very early on is there were a lot of things that I just didn't know about the field. I didn't know HTML. I didn't know CSS. I didn't know how to get a server started. I didn't know anything. If I knew anything about computers, it was more about the hardware side of it and nothing about the software side. So I knew very quickly that the self-learning aspect wouldn't work for me, and so that's kind of why I decided to go the bootcamp route. +I asked a lot of mentors, "Hey, what's the best way?" And they're like, "Bootcamp." And they're like, "Go to the one that teaches you the most." And so, at that time, the bootcamp I went to was two years long, but I was able to probably eight months in get a job in tech. And then, I completed it while going to work at that tech company. +VICTORIA: Oh, that's great. +CHAD: I mean, this might be a little bit of a hot take, but I'm going to say it anyway, which is I think that if you don't know how to code at all, or very little university programs, computer science programs aren't really set up to teach you that in a great way. It's more likely that someone with that level of experience will really struggle going into a computer science program not really having coded before. +Bootcamps are much more conducive to learning from scratch along with other people. It's not even necessarily about the programs, but going into a CS degree, so many people already do know how to program. And so it's really hard for them to make a well-balanced program that works for everybody. +WILL: I totally agree with that. +VICTORIA: I could see it. It's both ways. The way I've always heard it explained is a computer science degree will teach you a lot about the underlying principles that you might wish you knew later after you have finished your bootcamp. But a bootcamp will prepare you for on-the-job performance like day one, more likely to just give you the full breadth. +I mean, I've taken computer science 101 at University of Maryland, and I learned HTML, CSS, how to get a basic website up, some simple things that can get you up to speed. I think you could start from scratch and go that route. But it's hard to keep it up to speed with current technology trends in a college atmosphere. And so I think you'll see a lot of partnerships with universities now. And obviously, bootcamps were created to address that gap. +You got a job while you were still in bootcamp, and I'm curious how that went for you, that job search. That's a huge hurdle to just getting from the bootcamp to the first job; if you have any advice for people who are in a similar situation right now. +WILL: Yes, it was very challenging at the time. I think I applied to over 400 positions. My biggest thing that I would say is stay the course, hang in there. Keep going. There are a lot of down days that I was like, am I supposed to be in this field? Am I supposed to be here? The other thing that I learned very quickly was resources. Who did I know in the tech field? Who could I reach out to help me with it? Because that was another thing that I learned. I thought whenever I first took my junior dev job that I would come in and be able to really implement tickets and items. +And I quickly realized that they hired me because of my character and who I was going to be long-term and that I can offer very little at that moment of, hey, coming in, and doing a ticket, and really shipping a feature I cannot do that as a junior dev. But hopefully, in six months or two, three months, however long their time period was that I could ship a portion of a feature. +VICTORIA: Right. And that's always been...for me, someone hiring for technical roles and the entry-level point, sometimes I would prefer someone who has professional experience. Especially working in consulting, you have the ability to communicate your ideas well and work with clients, but you're still learning the technology side of it. That's a lot less than hiring a new college graduate who hasn't ever worked before [laughs] but may have a computer science degree. It's a totally different value that you're bringing to the role, I think. +CHAD: And that persistence really pays off. Just to make sure that timeline is clear, I think you interviewed with us for the first time five years ago or so, so I really appreciate you sticking with it and eventually coming back to us. That makes me super, super happy. +WILL: Yeah, and one thing that I learned along the way is there are different companies out there, and depending on your purpose and your goal, there are great fits depending on what your goal is. And my goal in my career was to learn and to be with a great company that had a great culture. +And I felt like thoughtbot was a good fit for me with that because I want to enjoy the people that I work with. I want to get to know them. I want to help them be a mentor, be a mentee, and thoughtbot was a good fit with that. That was one of the reasons why I put it on my list of hey, whenever that opportunity comes back, apply, apply, apply back to them. +CHAD: You originally interviewed with us as a Rails developer for a Rails development position. But along the way, you joined us as a React and React Native developer. So tell us a little bit about that journey along the way. +WILL: Yeah, so I did as a Rails developer, and I quickly realized that at that point in my career, Rails was harder for me to comprehend. There was nothing visual that I could really understand. And going back to what Victoria said with universities being able to keep up, at the end of my bootcamp, that was when React was on the rise. And so they actually released a module for React, and so I was able to really pick up that module. +And at that point, I thought React and front end was going to be a lot easier for me to comprehend and easier to get a job in the field, and so that's kind of why I went that front-end developer way. And then it's interesting now because I'm coming back around learning more Rails and, hopefully, be able to contribute to client work with the Rails side. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +CHAD: thoughbot's not the first agency that you worked at. Before you joined, you were working at another agency. Was there something in particular that gravitated towards this kind of work as opposed to working at maybe a technology startup working on a specific product? +WILL: Yeah. The two first jobs that I had in tech was typical software as a service products. I enjoyed it, but I felt like we were building on the same thing over and over again. And it was okay, but I know for me that I'm a big-time learner. And so I felt for me, I'm a big-time learner, and so I felt going the agency route would give me the opportunity to be exposed to different aspects of tech. +So at the last agency, I did some Rails work. It was very, very minimal, but I was able to do that. I was able to learn a lot about React Native and React and probably worked on a handful of jobs. Even at thoughtbot, I've worked on jobs and contracts that range from a month to six months. And I know potentially, I can work on a contract for two years, but it still gives me enough change to where I feel like the tech field will not leave me behind. +So I can work on a job or a contract for a year and then reset and say, "Oh, React released XYZ." And I can implement that into this new product or contract I'm working on. So that part right there is what really excited me about working for an agency and being a part of the company. +CHAD: Yeah, that's a big part of that variety, even both on the tech side but also just being able to work with different people and not be bound always to the same thing is one of the reasons why I've been able to do this so long I believe. +WILL: That's a good point because I love meeting new people. I love getting to know them. And it gives me that opportunity to work for a client, get to know them, and stay in contact with them but even go to a new client. If I was working at a product, I'm with the same company inside the four walls of that company. And so I love that aspect of getting to meet new people and getting to help companies deliver their dreams to the world. I really enjoy that. +CHAD: And that's what you're going to get to do as part of the host of the show too. +WILL: Yes. I'm excited about that too. +VICTORIA: I was going to say the same. You're going to meet so many cool people. [laughs] I've already met a lot of really interesting people in the last two months. So let's ask you a fun question. You're meeting new people; maybe you're introducing a new podcast guest. What's your favorite icebreaker question to ask? +WILL: I think my favorite question to ask podcast guests is why they do what they do. And the reason why is because it's very interesting seeing what propels people to go and do the things that they do. I guess I'm a student of people and humans. I love understanding the greatest people like Tom Brady, Michael Jordan. I know that may be up for debate. +VICTORIA: [laughs] +WILL: But just what makes them click. Also, for our guests, there are so many different aspects and products that people are coming up with, and so it's amazing to hear why they're doing what they do. And a lot of them, I'm like, oh, why didn't I think of that? That's a great idea. [laughter] And so I think that's my favorite question by far is why do you do what you do? +VICTORIA: I like that, yeah. As soon as I come on, I'm like, "So you're the founder of this. And why did you do that? [laughs] Tell me." But it's always an interesting story, just the right person, and the right place, the right problem to solve, and the right group of people around them to figure it out. +WILL: Yeah, and definitely the sacrifice that they're making. Being a CEO or founder of a company is not a nine-to-five job. You're sacrificing a lot of time, a lot of effort, resources. So yes, why do you do what you do? Because you're sacrificing so much. So why did you do that to get to this point? I love it. +VICTORIA: We could ask Chad that. [laughs] Why did you start thoughtbot, Chad? [laughs] +CHAD: I ask myself that every day. +[laughter] +VICTORIA: I know. +CHAD: No, I'm kidding. Oh, we have a whole episode on that we recorded for our anniversary with the original co-founders that I had, and we did the history of thoughtbot. So I like to point that out every once in a while, Episode 262 from February 12th, 2018. Time flies when you're having fun. I didn't think it was that long ago. +WILL: [laughs] +CHAD: We're currently on Episode 442. +VICTORIA: I will say it is a productive podcast. There are a lot of great episodes that come out. I'm excited to have Will on to help share the experience of [laughs] creating them. +CHAD: Yeah. And speaking a little bit of meta, this is the first time we've ever had three co-hosts. We have an appetite, the three of us, for trying some new things with this new sort of season that we're embarking on. But we also love the show as it is, and so we're going to keep things sort of going like they are with some rotations and doing some joint episodes and that kind of thing. +But I wouldn't be surprised if, after a couple of months, we start to layer something new on. I'm not quite sure what that will be yet, whether it will be just maybe episodes with just the three of us, and not a guest, talking about some thoughtbot stuff or some things we want to talk about. Or maybe it could be something else. What do you all think? +WILL: I love that idea. I love being able to have different options and opening that out. I think it's a great idea. Like you said, I don't know what that looks like, but I'm excited that we have the opportunity to bring different aspects, different podcasts to our guests. +VICTORIA: Yeah, I'm already thinking of people I can voluntell at thoughtbot [laughter] and talking about topics that I'm interested in. [laughs] There's a lot we could do with that. And yeah, I think it'd be good to mix it up. How has working at thoughtbot supported your work-life balance with your family? +WILL: It's been amazing. At the time of this recording, I have three kids; their ages are three, two, and a couple of months. And so, from the very beginning of parental leave, being able to take that time and be with my son and take care of all his needs was amazing. And not having to worry about work, yeah, it was top-notch because I was able to really just focus on him and my other two kids. Because when you have a baby and other siblings, it gets tough, so I felt like most of my parental leave was just keeping my baby alive. [laughter] +The older siblings were amazing and actually surprised me. I thought that they would be jealous, and why is this new human in our house taking your attention? But it was actually the exact opposite. They wanted to hold the baby. +VICTORIA: Aww. +WILL: They wanted to be with him. And so it was like, okay, I'll let you hold them, but I got to be here with you, and I got to help you. And my two older kids are very independent. And so that was tough, but it's amazing to see how much they love their younger brother. +VICTORIA: Aww. +WILL: Yeah. So that has been amazing. But to continue on the work-life balance, it has been really amazing working at thoughtbot because we are a remote culture, and especially the clients that I've worked with the flexibility of the schedule. So yes, we have meetings that I have to make it to and be a part of the team. But for the most part, as long as I get my work done, I am in a good position. +So, to be honest, with the newborn, sometimes I'm up at midnight. And I'm able to work while I'm up with my son because that's the time that he wants to get up and eat and hang out, so I'm like, okay, let's hang out. So that flexibility has been amazing for me. I love the remote aspect of it because I am a big family person. So I love being able to be home with my kids as they're growing up, eating lunch with them, going on a walk with them. So yes, it has been amazing. To be honest, I don't know if I can ask for anything more than what thoughtbot provides to me as a parent. So I'm really thankful for that. +CHAD: That brings back a lot of memories for me because when our son was born, I also was up with him, and it would be one of those scenarios where you finally get him to sleep in the bounce chair or the chair, and you're like, okay, what do I do now? Because he's going to be up again at any moment. I was like, okay, I'll do some coding now, and it's like midnight, one in the morning, or whatever. +And I got a little bit of a reputation for these pull requests coming in at night but this general sense of understanding about why that's happening. And like, okay, now I'm not in in the morning because this was the schedule that I was on and a real flexibility and understanding of that. But it really brings back memories for me. I'm glad I'm well past that point now. +[laughter] +WILL: And I am thankful that thoughtbot is thinking about those things. Like you said, you're past that point, but you still are thinking about those things. And that means a lot to me that it's not in your forethought, but it's still very important to have that culture. And you're remembering how it was when you were a parent. That means a lot to me. +VICTORIA: Yeah. And I think that if you look at the state of the October's reports and see when developers are actually submitting pull requests, the windows are much longer. So post-pandemic with that giant shift to remote work, you will see them in earlier hours of the day or later hours in the night, but there are longer breaks in between. And I think for knowledge work especially; it's hard to just work an eight-hour block and be able to constantly be outputting during that time. [laughs] So it makes sense from a work-life balance but also a productivity overall balance as well. +CHAD: That's really interesting. I hadn't seen that report, but it resonates with me as true or resonates with me. And we've always talked about the concept of sustainable pace, and when we were in offices, that often meant Monday through Friday, eight to five, nine to five. This is the schedule we're all keeping. And if someone was deviating from that, it was like, oh, you may not be working sustainably. +Now, in a remote environment, it is much more about flexibility and recognizing that as long as people are working in a sustainable pace, variety in hours and flexibility is totally okay. And like you said, Will, it's about the work that you're getting done. Like, if there's a problem with what I'm delivering or what I'm able to do, let's have that conversation. Conversation shouldn't be about when I'm working or the hours that I'm working, the amount I'm working. +WILL: And as a human, your first thought is, is this person working the hours they're supposed to? And I think that's the first thought for a lot of people. But the one thing that I do like about thoughtbot is that trust that we have with our developers. Okay, there may not be their eight-hour block during the day, but are they getting their work done? +If they're getting the work done, why should I even say anything to them? Because they're being successful. That's what we asked them to do, get the work done. Are their clients happy? If their client is happy, I'm happy. And so I think that's one thing. The trust that thoughtbot has given to me as a developer means a lot to me, too, because I can work at midnight and still be productive and get my work done. +CHAD: I think it's telling. It's very rare for us to have a conversation with someone about maybe not working enough. It's almost always the opposite which is checking in with people and making sure that they're working sustainably. +VICTORIA: And I'm curious, Chad, about the policy of the four days of consulting and having Fridays for investment time; how that decision was made at thoughtbot. It's been a policy for a long time. +CHAD: Well, it comes from our value of continuous improvement. When we were 16 people, all designers, and developers, working client work five days a week, there was no time, strictly speaking, within a sustainable pace to reflect on the way that we were working, to make improvements, to learn new things, to create the open source that we were doing and the blogging that we were doing. +And so, if we were honest with ourselves, a lot of that stuff was happening outside of normal working time in addition to the five days of client work we were doing. And so I think it was Joe Ferris who said, like, if we believe in continuous improvement, we've got to carve out time and sustainable pace. We've got to carve out time within the week in order to be able to do those things. +The truth of the matter is a lot of our most popular open-source projects were actually created at a time when we didn't have investment time. And so, like I said, I think if we're honest with ourselves, we were really stretching ourselves thin at that point. So working on client work four days a week made us not only more sustainable but ultimately because it's continuous improvement...and so when you have a feedback cycle where short iterations, you can reflect on the way that you're working or that you have time set aside for making improvements, it makes you better the rest of the time as well. +And so now it's part of our secret sauce is the reason why we're able to be as productive as we are in that time that we have is because of that time set aside for improvement. The reason why we're able to make the open source and the blog posts that we do which make us have a bigger reputation and make our client work faster because we're able to use open source is because of that schedule. And so it's a self-fulfilling virtuous cycle of improvement. So that's where it comes from and why we've been so successful with it. +WILL: And that's actually a huge reason why I wanted to work at thoughtbot because one of my first jobs in tech, I would come in and knock out tickets, and I really thought that that was enough to be successful in the field. But then I quickly learned that yes, I was learning the tickets that I was working on, but there was so much more that I did not know, did not understand. And at that point, that's when I had my first son, and we were working five days a week. +So the biggest question for me was, with a newborn son and working five days a week, when do I fit in that investment time? When do I learn the outside aspect that we're not doing in the everyday grind of our tickets? And I quickly learned that I had to do it on the weekends. I had to do it outside of the hours that I was working. And it was hard. It was not a sustainable pace. +With thoughtbot, one of my criterias was being able to learn, being able to be mentored, and thoughtbot checked that off. But not only did they check that off, but they gave me the opportunity, the space to be mentored and to learn. So I love Friday's investment time. It's been huge in my career. +CHAD: I'm giving away all the secrets here, but it's okay because it's the execution that matters. But the reason why at your previous places you weren't necessarily able to do that is because that's not their product. Their product was the SaaS product that you were working on. And so when a company like that thinks about where they're investing, the investments that they're going to make are in their product. +It's one of the reasons why we call investment time investment time because I wanted to communicate that we are investing in our product, but our product is the way that we work. It is our people and our process, and the tools that we use. And so when we think about making investments as a company, that's what the product that we're in the market with is. And so we can afford to invest in improving that product in the same way that a company whose product is software can afford to invest in that software and has trouble investing in making the people, and the process, and the tools, and the culture better. +VICTORIA: That makes sense to me. And what I've found so far in having that four-day workweek and the way it comes out from a pricing perspective for clients is that you're paying maybe a premium for hours. But your team is able to get more work done in less amount of time because it's so focused. And then overall, you're getting a higher quality work product in a short amount of time. And I think it just makes a lot of sense to me. +And I've been working in many consulting companies, and they all have this problem. They all want to put out a lot of knowledge articles and blog posts and be known for their expertise but don't commit to making that time to it or spending the money on investing in people to build those products. So it's something I was really excited about for thoughtbot too. [laughs] +CHAD: This is great fodder for future episodes with just the three of us. [laughs] +VICTORIA: Yeah. +WILL: Love it. +CHAD: Will, thanks again for joining the show. If we don't get to play D&D again together for a while, this will be a secondary substitute for that. +WILL: Yes, I do plan on coming back. That was huge also, so don't count me out. +[laughter] +CHAD: I won't count you out. +You can subscribe to the show and find notes for this episode, along with a complete transcript, at giantrobots.fm. +VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm. +CHAD: You can find me on Twitter @cyptel. +VICTORIA: And you can find me on Twitter @victori_ousg. +CHAD: And, Will, if folks want to follow along with you, where are all the places that they can do that? +WILL: Yeah. You can follow me on Twitter @will23larry. And I would love to interact and chat with you. +CHAD: Is the 23 for Michael Jordan? +WILL: Always. +[laughter] +CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +VICTORIA: Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Will Larry, Software Developer at thoughtbot, joins Giant Robots as host! 🎉

+ +

Will talks about how he got into tech, how everything is going so far at thoughtbot, interviewing at thoughtbot previously, but not getting the job, and why he decided to interview again (and snagged the job!)

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

VICTORIA: I'm your other host, Victoria Guido. And with us today is our brand new third co-host, Will Larry. Will is a React and React Native developer at thoughtbot. And we're so excited to have him join us as a co-host of the show.

+ +

CHAD: Will, thank you so much for joining us. Congratulations and welcome. Woo-hoo.

+ +

[applause]

+ +

WILL: Thank you for having me. I'm excited.

+ +

CHAD: Will, I was so excited when I put out the call for people to join as co-hosts, and Victoria raised her hand, and then you did as well. You were on parental leave when all that started to happen. And so congratulations again on your new family member, and I'm glad we could finally have you join us.

+ +

WILL: Yeah, I was excited about it. When I thought about joining, there are two things that came about: the excitement of joining and just the fear of it.

+ +

CHAD: [laughs]

+ +

WILL: And I was like, I need to do this. I need to do this because it will make me better. So I'm excited to be here.

+ +

VICTORIA: That's a lot of change to navigate in one year, Will. [laughs] How's that got going for you, and how's everything so far in your first time here at thoughtbot?

+ +

WILL: Yes, change, change, change, that's what has been this year. I changed and started working at thoughtbot, our third kid. This year, we moved to Florida, just a lot of change. But I've learned along the way that change is life, and so we just embraced it. And I'm hoping that we're kind of settling out a little bit, but it's been good. It's been great for our kids. I think they're ready for some consistency and just the same thing over and over for a little bit. But it's been good. And we made it through. We're on the other side.

+ +

CHAD: Was there a grand plan to all the change? Like, did you have everything planned out in advance? Or did it all sort of just happen one thing after the other?

+ +

WILL: Yes. If you know anything about me, I'm a very big planner. My wife, my spouse she is the one that pushes me to be more spontaneous, but this was too big to be spontaneous, so it was definitely planned. It actually got changed. We were supposed to move in September, but with the birth of my son, we decided to move it up and move sooner.

+ +

VICTORIA: Right. I'm going to ask you the same question but about your career. So you made a big change from operations into mobile development, and was that part of a grand plan, or did you happen upon it? How did you make that change?

+ +

WILL: That change was kind of out of desperation. I was in operations working for a nonprofit; I loved it. My spouse was working at the same company, and I was a promotion ahead of her. It was an amazing opportunity. But the teams are so small that we couldn't be on the same team. So they had multiple locations throughout the country. And you don't have to step off the team, but if she's going to take this promotion, you have to step off the team. There potentially is a way that, down the road, you can come back.

+ +

And Katie is my spouse. She has been so supportive of everything that I've ever done. And I just felt this was a time, a great time for me to show that I support her in everything she did. But it was probably one of the toughest times in my life. I didn't have a job. I thought that I can easily jump back into it and find a job. I ended up working at a clothing store, which is not my strong suit. I really struggled working there. I think I worked there a month, and I was like, I can't do this. And then, I went to work at a different company, a travel insurance company, and so I would process the data.

+ +

I was miserable, and that's an understatement. I was so miserable. One day my spouse came in, and she said, "Hey, we got to change this. You're not doing well. Let's dream a little bit." And normally, that's not my personality. Normally I'm like Xs and Os. I know what's coming. And I was so out of it. I was like, let's do this. And she asked me a couple of questions. And one of the questions was, "If you could do anything, what would you do?" I thought about it.

+ +

And I came from a small town in Louisiana. And I never had the opportunity to work with computers. It was just the resources weren't there. And so that was one of the things I said, "Hey, I want to work with computers in any way that I can." She was like, "Go figure it out, whatever it takes." And then I told her I was like, "It's going to cost some money for me to do this," because I went to bootcamp. And she was like, "Go do it. Let's invest in you. Let's make this happen."

+ +

I ended up going through the bootcamp and came out on the other side. Interesting story; it's interesting how things come back around. My first interview was at thoughtbot. I bombed it. [laughter] I wasn't on thoughtbot's team at that point. But the way that it was handled, I got a glimpse of the culture.

+ +

I remember walking out that day and saying I'll be back. I will be back to be a part of this company because I bombed it. But they still spent time with me explaining things, teaching me the things that I bombed. And so I was like, wow, that's what I want to do in this field. So yeah, that's how I got into development. Here I am.

+ +

CHAD: Was there anything that surprised you about development, about the tech world?

+ +

WILL: Yes, yes. I think the biggest thing was the growth in development. So in any of my other jobs, I was able to take in expectations and make a plan and, like, okay, check off. I can knock that out and be successful. And I tried that in development, and every one of my bosses would say, "Slow down. It takes time. It takes time." And I just didn't realize how long it would take for me to grow in my coding skills.

+ +

That was the biggest surprise for me because I just couldn't come through, and okay, I got it, let's go. Because I'm very big on I know my expectations, okay, I can meet those expectations, and then I'll go over and beyond. But I couldn't do that in this field. And I think that was the biggest surprise for me that I couldn't just show up at work and do my task and still be a great developer.

+ +

VICTORIA: Right. And I love that you're sharing that story. Because with the people I've worked with at Women Who Code, it's a very common struggle when you're starting out in your first time as a developer and getting comfortable with being not great for the first six months or a year, or however long it takes. And I think that it's important to share that and make sure that other people feel the same way. And you might feel that way for a long time and maybe forever [laughs] if you keep switching up your roles in tech.

+ +

WILL: Yeah, definitely. And it was a very humbling experience also because, in most of my other jobs, I was the leader. I was the person that had direct reports and leading people. But in this job, I started at the very bottom. I remember there were days when I couldn't even get through my tasks and had to really lean on others to help me through it. You know, my senior developer, I was like, "Hey, it's that time. I got some questions for you." And so, I had to learn how does Will learn and what's the best way for me to excel in this field? The things that I've done before, I couldn't do it going forward.

+ +

CHAD: Bootcamps are pretty popular. And they are an avenue that certainly didn't exist when I was learning. You said when you were having the conversation with your wife that it sounds like that was just right there as the path forward. But did you consider an alternative path?

+ +

WILL: Yeah. So at that time, I felt like there were probably three paths: there was the bootcamp, there was the college degree, and there was the self-learning path. So the college degree, I thought about it because, at that time, I felt like a lot of companies were still like, hey, you have to have a degree to be hired and be a part of it. So whenever I thought about going back, I didn't know if it was going to cut me off from other jobs, so that was one of the reasons why I really decided, or I really thought about going the degree route.

+ +

And I decided against it because I did a lot of research, and there were companies at that time that were like, you don't need a college degree because I already had a college degree in sports medicine. And so most of them were like, you just have to have a degree. And I was like, okay, I don't think I'm going to be stuck in this position because I didn't have a computer science degree.

+ +

The other way was self-taught. I didn't think that I could put in the time and the work. One thing I learned very, very early on is there were a lot of things that I just didn't know about the field. I didn't know HTML. I didn't know CSS. I didn't know how to get a server started. I didn't know anything. If I knew anything about computers, it was more about the hardware side of it and nothing about the software side. So I knew very quickly that the self-learning aspect wouldn't work for me, and so that's kind of why I decided to go the bootcamp route.

+ +

I asked a lot of mentors, "Hey, what's the best way?" And they're like, "Bootcamp." And they're like, "Go to the one that teaches you the most." And so, at that time, the bootcamp I went to was two years long, but I was able to probably eight months in get a job in tech. And then, I completed it while going to work at that tech company.

+ +

VICTORIA: Oh, that's great.

+ +

CHAD: I mean, this might be a little bit of a hot take, but I'm going to say it anyway, which is I think that if you don't know how to code at all, or very little university programs, computer science programs aren't really set up to teach you that in a great way. It's more likely that someone with that level of experience will really struggle going into a computer science program not really having coded before.

+ +

Bootcamps are much more conducive to learning from scratch along with other people. It's not even necessarily about the programs, but going into a CS degree, so many people already do know how to program. And so it's really hard for them to make a well-balanced program that works for everybody.

+ +

WILL: I totally agree with that.

+ +

VICTORIA: I could see it. It's both ways. The way I've always heard it explained is a computer science degree will teach you a lot about the underlying principles that you might wish you knew later after you have finished your bootcamp. But a bootcamp will prepare you for on-the-job performance like day one, more likely to just give you the full breadth.

+ +

I mean, I've taken computer science 101 at University of Maryland, and I learned HTML, CSS, how to get a basic website up, some simple things that can get you up to speed. I think you could start from scratch and go that route. But it's hard to keep it up to speed with current technology trends in a college atmosphere. And so I think you'll see a lot of partnerships with universities now. And obviously, bootcamps were created to address that gap.

+ +

You got a job while you were still in bootcamp, and I'm curious how that went for you, that job search. That's a huge hurdle to just getting from the bootcamp to the first job; if you have any advice for people who are in a similar situation right now.

+ +

WILL: Yes, it was very challenging at the time. I think I applied to over 400 positions. My biggest thing that I would say is stay the course, hang in there. Keep going. There are a lot of down days that I was like, am I supposed to be in this field? Am I supposed to be here? The other thing that I learned very quickly was resources. Who did I know in the tech field? Who could I reach out to help me with it? Because that was another thing that I learned. I thought whenever I first took my junior dev job that I would come in and be able to really implement tickets and items.

+ +

And I quickly realized that they hired me because of my character and who I was going to be long-term and that I can offer very little at that moment of, hey, coming in, and doing a ticket, and really shipping a feature I cannot do that as a junior dev. But hopefully, in six months or two, three months, however long their time period was that I could ship a portion of a feature.

+ +

VICTORIA: Right. And that's always been...for me, someone hiring for technical roles and the entry-level point, sometimes I would prefer someone who has professional experience. Especially working in consulting, you have the ability to communicate your ideas well and work with clients, but you're still learning the technology side of it. That's a lot less than hiring a new college graduate who hasn't ever worked before [laughs] but may have a computer science degree. It's a totally different value that you're bringing to the role, I think.

+ +

CHAD: And that persistence really pays off. Just to make sure that timeline is clear, I think you interviewed with us for the first time five years ago or so, so I really appreciate you sticking with it and eventually coming back to us. That makes me super, super happy.

+ +

WILL: Yeah, and one thing that I learned along the way is there are different companies out there, and depending on your purpose and your goal, there are great fits depending on what your goal is. And my goal in my career was to learn and to be with a great company that had a great culture.

+ +

And I felt like thoughtbot was a good fit for me with that because I want to enjoy the people that I work with. I want to get to know them. I want to help them be a mentor, be a mentee, and thoughtbot was a good fit with that. That was one of the reasons why I put it on my list of hey, whenever that opportunity comes back, apply, apply, apply back to them.

+ +

CHAD: You originally interviewed with us as a Rails developer for a Rails development position. But along the way, you joined us as a React and React Native developer. So tell us a little bit about that journey along the way.

+ +

WILL: Yeah, so I did as a Rails developer, and I quickly realized that at that point in my career, Rails was harder for me to comprehend. There was nothing visual that I could really understand. And going back to what Victoria said with universities being able to keep up, at the end of my bootcamp, that was when React was on the rise. And so they actually released a module for React, and so I was able to really pick up that module.

+ +

And at that point, I thought React and front end was going to be a lot easier for me to comprehend and easier to get a job in the field, and so that's kind of why I went that front-end developer way. And then it's interesting now because I'm coming back around learning more Rails and, hopefully, be able to contribute to client work with the Rails side.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: thoughbot's not the first agency that you worked at. Before you joined, you were working at another agency. Was there something in particular that gravitated towards this kind of work as opposed to working at maybe a technology startup working on a specific product?

+ +

WILL: Yeah. The two first jobs that I had in tech was typical software as a service products. I enjoyed it, but I felt like we were building on the same thing over and over again. And it was okay, but I know for me that I'm a big-time learner. And so I felt for me, I'm a big-time learner, and so I felt going the agency route would give me the opportunity to be exposed to different aspects of tech.

+ +

So at the last agency, I did some Rails work. It was very, very minimal, but I was able to do that. I was able to learn a lot about React Native and React and probably worked on a handful of jobs. Even at thoughtbot, I've worked on jobs and contracts that range from a month to six months. And I know potentially, I can work on a contract for two years, but it still gives me enough change to where I feel like the tech field will not leave me behind.

+ +

So I can work on a job or a contract for a year and then reset and say, "Oh, React released XYZ." And I can implement that into this new product or contract I'm working on. So that part right there is what really excited me about working for an agency and being a part of the company.

+ +

CHAD: Yeah, that's a big part of that variety, even both on the tech side but also just being able to work with different people and not be bound always to the same thing is one of the reasons why I've been able to do this so long I believe.

+ +

WILL: That's a good point because I love meeting new people. I love getting to know them. And it gives me that opportunity to work for a client, get to know them, and stay in contact with them but even go to a new client. If I was working at a product, I'm with the same company inside the four walls of that company. And so I love that aspect of getting to meet new people and getting to help companies deliver their dreams to the world. I really enjoy that.

+ +

CHAD: And that's what you're going to get to do as part of the host of the show too.

+ +

WILL: Yes. I'm excited about that too.

+ +

VICTORIA: I was going to say the same. You're going to meet so many cool people. [laughs] I've already met a lot of really interesting people in the last two months. So let's ask you a fun question. You're meeting new people; maybe you're introducing a new podcast guest. What's your favorite icebreaker question to ask?

+ +

WILL: I think my favorite question to ask podcast guests is why they do what they do. And the reason why is because it's very interesting seeing what propels people to go and do the things that they do. I guess I'm a student of people and humans. I love understanding the greatest people like Tom Brady, Michael Jordan. I know that may be up for debate.

+ +

VICTORIA: [laughs]

+ +

WILL: But just what makes them click. Also, for our guests, there are so many different aspects and products that people are coming up with, and so it's amazing to hear why they're doing what they do. And a lot of them, I'm like, oh, why didn't I think of that? That's a great idea. [laughter] And so I think that's my favorite question by far is why do you do what you do?

+ +

VICTORIA: I like that, yeah. As soon as I come on, I'm like, "So you're the founder of this. And why did you do that? [laughs] Tell me." But it's always an interesting story, just the right person, and the right place, the right problem to solve, and the right group of people around them to figure it out.

+ +

WILL: Yeah, and definitely the sacrifice that they're making. Being a CEO or founder of a company is not a nine-to-five job. You're sacrificing a lot of time, a lot of effort, resources. So yes, why do you do what you do? Because you're sacrificing so much. So why did you do that to get to this point? I love it.

+ +

VICTORIA: We could ask Chad that. [laughs] Why did you start thoughtbot, Chad? [laughs]

+ +

CHAD: I ask myself that every day.

+ +

[laughter]

+ +

VICTORIA: I know.

+ +

CHAD: No, I'm kidding. Oh, we have a whole episode on that we recorded for our anniversary with the original co-founders that I had, and we did the history of thoughtbot. So I like to point that out every once in a while, Episode 262 from February 12th, 2018. Time flies when you're having fun. I didn't think it was that long ago.

+ +

WILL: [laughs]

+ +

CHAD: We're currently on Episode 442.

+ +

VICTORIA: I will say it is a productive podcast. There are a lot of great episodes that come out. I'm excited to have Will on to help share the experience of [laughs] creating them.

+ +

CHAD: Yeah. And speaking a little bit of meta, this is the first time we've ever had three co-hosts. We have an appetite, the three of us, for trying some new things with this new sort of season that we're embarking on. But we also love the show as it is, and so we're going to keep things sort of going like they are with some rotations and doing some joint episodes and that kind of thing.

+ +

But I wouldn't be surprised if, after a couple of months, we start to layer something new on. I'm not quite sure what that will be yet, whether it will be just maybe episodes with just the three of us, and not a guest, talking about some thoughtbot stuff or some things we want to talk about. Or maybe it could be something else. What do you all think?

+ +

WILL: I love that idea. I love being able to have different options and opening that out. I think it's a great idea. Like you said, I don't know what that looks like, but I'm excited that we have the opportunity to bring different aspects, different podcasts to our guests.

+ +

VICTORIA: Yeah, I'm already thinking of people I can voluntell at thoughtbot [laughter] and talking about topics that I'm interested in. [laughs] There's a lot we could do with that. And yeah, I think it'd be good to mix it up. How has working at thoughtbot supported your work-life balance with your family?

+ +

WILL: It's been amazing. At the time of this recording, I have three kids; their ages are three, two, and a couple of months. And so, from the very beginning of parental leave, being able to take that time and be with my son and take care of all his needs was amazing. And not having to worry about work, yeah, it was top-notch because I was able to really just focus on him and my other two kids. Because when you have a baby and other siblings, it gets tough, so I felt like most of my parental leave was just keeping my baby alive. [laughter]

+ +

The older siblings were amazing and actually surprised me. I thought that they would be jealous, and why is this new human in our house taking your attention? But it was actually the exact opposite. They wanted to hold the baby.

+ +

VICTORIA: Aww.

+ +

WILL: They wanted to be with him. And so it was like, okay, I'll let you hold them, but I got to be here with you, and I got to help you. And my two older kids are very independent. And so that was tough, but it's amazing to see how much they love their younger brother.

+ +

VICTORIA: Aww.

+ +

WILL: Yeah. So that has been amazing. But to continue on the work-life balance, it has been really amazing working at thoughtbot because we are a remote culture, and especially the clients that I've worked with the flexibility of the schedule. So yes, we have meetings that I have to make it to and be a part of the team. But for the most part, as long as I get my work done, I am in a good position.

+ +

So, to be honest, with the newborn, sometimes I'm up at midnight. And I'm able to work while I'm up with my son because that's the time that he wants to get up and eat and hang out, so I'm like, okay, let's hang out. So that flexibility has been amazing for me. I love the remote aspect of it because I am a big family person. So I love being able to be home with my kids as they're growing up, eating lunch with them, going on a walk with them. So yes, it has been amazing. To be honest, I don't know if I can ask for anything more than what thoughtbot provides to me as a parent. So I'm really thankful for that.

+ +

CHAD: That brings back a lot of memories for me because when our son was born, I also was up with him, and it would be one of those scenarios where you finally get him to sleep in the bounce chair or the chair, and you're like, okay, what do I do now? Because he's going to be up again at any moment. I was like, okay, I'll do some coding now, and it's like midnight, one in the morning, or whatever.

+ +

And I got a little bit of a reputation for these pull requests coming in at night but this general sense of understanding about why that's happening. And like, okay, now I'm not in in the morning because this was the schedule that I was on and a real flexibility and understanding of that. But it really brings back memories for me. I'm glad I'm well past that point now.

+ +

[laughter]

+ +

WILL: And I am thankful that thoughtbot is thinking about those things. Like you said, you're past that point, but you still are thinking about those things. And that means a lot to me that it's not in your forethought, but it's still very important to have that culture. And you're remembering how it was when you were a parent. That means a lot to me.

+ +

VICTORIA: Yeah. And I think that if you look at the state of the October's reports and see when developers are actually submitting pull requests, the windows are much longer. So post-pandemic with that giant shift to remote work, you will see them in earlier hours of the day or later hours in the night, but there are longer breaks in between. And I think for knowledge work especially; it's hard to just work an eight-hour block and be able to constantly be outputting during that time. [laughs] So it makes sense from a work-life balance but also a productivity overall balance as well.

+ +

CHAD: That's really interesting. I hadn't seen that report, but it resonates with me as true or resonates with me. And we've always talked about the concept of sustainable pace, and when we were in offices, that often meant Monday through Friday, eight to five, nine to five. This is the schedule we're all keeping. And if someone was deviating from that, it was like, oh, you may not be working sustainably.

+ +

Now, in a remote environment, it is much more about flexibility and recognizing that as long as people are working in a sustainable pace, variety in hours and flexibility is totally okay. And like you said, Will, it's about the work that you're getting done. Like, if there's a problem with what I'm delivering or what I'm able to do, let's have that conversation. Conversation shouldn't be about when I'm working or the hours that I'm working, the amount I'm working.

+ +

WILL: And as a human, your first thought is, is this person working the hours they're supposed to? And I think that's the first thought for a lot of people. But the one thing that I do like about thoughtbot is that trust that we have with our developers. Okay, there may not be their eight-hour block during the day, but are they getting their work done?

+ +

If they're getting the work done, why should I even say anything to them? Because they're being successful. That's what we asked them to do, get the work done. Are their clients happy? If their client is happy, I'm happy. And so I think that's one thing. The trust that thoughtbot has given to me as a developer means a lot to me, too, because I can work at midnight and still be productive and get my work done.

+ +

CHAD: I think it's telling. It's very rare for us to have a conversation with someone about maybe not working enough. It's almost always the opposite which is checking in with people and making sure that they're working sustainably.

+ +

VICTORIA: And I'm curious, Chad, about the policy of the four days of consulting and having Fridays for investment time; how that decision was made at thoughtbot. It's been a policy for a long time.

+ +

CHAD: Well, it comes from our value of continuous improvement. When we were 16 people, all designers, and developers, working client work five days a week, there was no time, strictly speaking, within a sustainable pace to reflect on the way that we were working, to make improvements, to learn new things, to create the open source that we were doing and the blogging that we were doing.

+ +

And so, if we were honest with ourselves, a lot of that stuff was happening outside of normal working time in addition to the five days of client work we were doing. And so I think it was Joe Ferris who said, like, if we believe in continuous improvement, we've got to carve out time and sustainable pace. We've got to carve out time within the week in order to be able to do those things.

+ +

The truth of the matter is a lot of our most popular open-source projects were actually created at a time when we didn't have investment time. And so, like I said, I think if we're honest with ourselves, we were really stretching ourselves thin at that point. So working on client work four days a week made us not only more sustainable but ultimately because it's continuous improvement...and so when you have a feedback cycle where short iterations, you can reflect on the way that you're working or that you have time set aside for making improvements, it makes you better the rest of the time as well.

+ +

And so now it's part of our secret sauce is the reason why we're able to be as productive as we are in that time that we have is because of that time set aside for improvement. The reason why we're able to make the open source and the blog posts that we do which make us have a bigger reputation and make our client work faster because we're able to use open source is because of that schedule. And so it's a self-fulfilling virtuous cycle of improvement. So that's where it comes from and why we've been so successful with it.

+ +

WILL: And that's actually a huge reason why I wanted to work at thoughtbot because one of my first jobs in tech, I would come in and knock out tickets, and I really thought that that was enough to be successful in the field. But then I quickly learned that yes, I was learning the tickets that I was working on, but there was so much more that I did not know, did not understand. And at that point, that's when I had my first son, and we were working five days a week.

+ +

So the biggest question for me was, with a newborn son and working five days a week, when do I fit in that investment time? When do I learn the outside aspect that we're not doing in the everyday grind of our tickets? And I quickly learned that I had to do it on the weekends. I had to do it outside of the hours that I was working. And it was hard. It was not a sustainable pace.

+ +

With thoughtbot, one of my criterias was being able to learn, being able to be mentored, and thoughtbot checked that off. But not only did they check that off, but they gave me the opportunity, the space to be mentored and to learn. So I love Friday's investment time. It's been huge in my career.

+ +

CHAD: I'm giving away all the secrets here, but it's okay because it's the execution that matters. But the reason why at your previous places you weren't necessarily able to do that is because that's not their product. Their product was the SaaS product that you were working on. And so when a company like that thinks about where they're investing, the investments that they're going to make are in their product.

+ +

It's one of the reasons why we call investment time investment time because I wanted to communicate that we are investing in our product, but our product is the way that we work. It is our people and our process, and the tools that we use. And so when we think about making investments as a company, that's what the product that we're in the market with is. And so we can afford to invest in improving that product in the same way that a company whose product is software can afford to invest in that software and has trouble investing in making the people, and the process, and the tools, and the culture better.

+ +

VICTORIA: That makes sense to me. And what I've found so far in having that four-day workweek and the way it comes out from a pricing perspective for clients is that you're paying maybe a premium for hours. But your team is able to get more work done in less amount of time because it's so focused. And then overall, you're getting a higher quality work product in a short amount of time. And I think it just makes a lot of sense to me.

+ +

And I've been working in many consulting companies, and they all have this problem. They all want to put out a lot of knowledge articles and blog posts and be known for their expertise but don't commit to making that time to it or spending the money on investing in people to build those products. So it's something I was really excited about for thoughtbot too. [laughs]

+ +

CHAD: This is great fodder for future episodes with just the three of us. [laughs]

+ +

VICTORIA: Yeah.

+ +

WILL: Love it.

+ +

CHAD: Will, thanks again for joining the show. If we don't get to play D&D again together for a while, this will be a secondary substitute for that.

+ +

WILL: Yes, I do plan on coming back. That was huge also, so don't count me out.

+ +

[laughter]

+ +

CHAD: I won't count you out.

+ +

You can subscribe to the show and find notes for this episode, along with a complete transcript, at giantrobots.fm.

+ +

VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Twitter @cyptel.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

CHAD: And, Will, if folks want to follow along with you, where are all the places that they can do that?

+ +

WILL: Yeah. You can follow me on Twitter @will23larry. And I would love to interact and chat with you.

+ +

CHAD: Is the 23 for Michael Jordan?

+ +

WILL: Always.

+ +

[laughter]

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

VICTORIA: Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Will Larry, Software Developer at thoughtbot, joins Giant Robots as host! 🎉

+ +

Will talks about how he got into tech, how everything is going so far at thoughtbot, interviewing at thoughtbot previously, but not getting the job, and why he decided to interview again (and snagged the job!)

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

VICTORIA: I'm your other host, Victoria Guido. And with us today is our brand new third co-host, Will Larry. Will is a React and React Native developer at thoughtbot. And we're so excited to have him join us as a co-host of the show.

+ +

CHAD: Will, thank you so much for joining us. Congratulations and welcome. Woo-hoo.

+ +

[applause]

+ +

WILL: Thank you for having me. I'm excited.

+ +

CHAD: Will, I was so excited when I put out the call for people to join as co-hosts, and Victoria raised her hand, and then you did as well. You were on parental leave when all that started to happen. And so congratulations again on your new family member, and I'm glad we could finally have you join us.

+ +

WILL: Yeah, I was excited about it. When I thought about joining, there are two things that came about: the excitement of joining and just the fear of it.

+ +

CHAD: [laughs]

+ +

WILL: And I was like, I need to do this. I need to do this because it will make me better. So I'm excited to be here.

+ +

VICTORIA: That's a lot of change to navigate in one year, Will. [laughs] How's that got going for you, and how's everything so far in your first time here at thoughtbot?

+ +

WILL: Yes, change, change, change, that's what has been this year. I changed and started working at thoughtbot, our third kid. This year, we moved to Florida, just a lot of change. But I've learned along the way that change is life, and so we just embraced it. And I'm hoping that we're kind of settling out a little bit, but it's been good. It's been great for our kids. I think they're ready for some consistency and just the same thing over and over for a little bit. But it's been good. And we made it through. We're on the other side.

+ +

CHAD: Was there a grand plan to all the change? Like, did you have everything planned out in advance? Or did it all sort of just happen one thing after the other?

+ +

WILL: Yes. If you know anything about me, I'm a very big planner. My wife, my spouse she is the one that pushes me to be more spontaneous, but this was too big to be spontaneous, so it was definitely planned. It actually got changed. We were supposed to move in September, but with the birth of my son, we decided to move it up and move sooner.

+ +

VICTORIA: Right. I'm going to ask you the same question but about your career. So you made a big change from operations into mobile development, and was that part of a grand plan, or did you happen upon it? How did you make that change?

+ +

WILL: That change was kind of out of desperation. I was in operations working for a nonprofit; I loved it. My spouse was working at the same company, and I was a promotion ahead of her. It was an amazing opportunity. But the teams are so small that we couldn't be on the same team. So they had multiple locations throughout the country. And you don't have to step off the team, but if she's going to take this promotion, you have to step off the team. There potentially is a way that, down the road, you can come back.

+ +

And Katie is my spouse. She has been so supportive of everything that I've ever done. And I just felt this was a time, a great time for me to show that I support her in everything she did. But it was probably one of the toughest times in my life. I didn't have a job. I thought that I can easily jump back into it and find a job. I ended up working at a clothing store, which is not my strong suit. I really struggled working there. I think I worked there a month, and I was like, I can't do this. And then, I went to work at a different company, a travel insurance company, and so I would process the data.

+ +

I was miserable, and that's an understatement. I was so miserable. One day my spouse came in, and she said, "Hey, we got to change this. You're not doing well. Let's dream a little bit." And normally, that's not my personality. Normally I'm like Xs and Os. I know what's coming. And I was so out of it. I was like, let's do this. And she asked me a couple of questions. And one of the questions was, "If you could do anything, what would you do?" I thought about it.

+ +

And I came from a small town in Louisiana. And I never had the opportunity to work with computers. It was just the resources weren't there. And so that was one of the things I said, "Hey, I want to work with computers in any way that I can." She was like, "Go figure it out, whatever it takes." And then I told her I was like, "It's going to cost some money for me to do this," because I went to bootcamp. And she was like, "Go do it. Let's invest in you. Let's make this happen."

+ +

I ended up going through the bootcamp and came out on the other side. Interesting story; it's interesting how things come back around. My first interview was at thoughtbot. I bombed it. [laughter] I wasn't on thoughtbot's team at that point. But the way that it was handled, I got a glimpse of the culture.

+ +

I remember walking out that day and saying I'll be back. I will be back to be a part of this company because I bombed it. But they still spent time with me explaining things, teaching me the things that I bombed. And so I was like, wow, that's what I want to do in this field. So yeah, that's how I got into development. Here I am.

+ +

CHAD: Was there anything that surprised you about development, about the tech world?

+ +

WILL: Yes, yes. I think the biggest thing was the growth in development. So in any of my other jobs, I was able to take in expectations and make a plan and, like, okay, check off. I can knock that out and be successful. And I tried that in development, and every one of my bosses would say, "Slow down. It takes time. It takes time." And I just didn't realize how long it would take for me to grow in my coding skills.

+ +

That was the biggest surprise for me because I just couldn't come through, and okay, I got it, let's go. Because I'm very big on I know my expectations, okay, I can meet those expectations, and then I'll go over and beyond. But I couldn't do that in this field. And I think that was the biggest surprise for me that I couldn't just show up at work and do my task and still be a great developer.

+ +

VICTORIA: Right. And I love that you're sharing that story. Because with the people I've worked with at Women Who Code, it's a very common struggle when you're starting out in your first time as a developer and getting comfortable with being not great for the first six months or a year, or however long it takes. And I think that it's important to share that and make sure that other people feel the same way. And you might feel that way for a long time and maybe forever [laughs] if you keep switching up your roles in tech.

+ +

WILL: Yeah, definitely. And it was a very humbling experience also because, in most of my other jobs, I was the leader. I was the person that had direct reports and leading people. But in this job, I started at the very bottom. I remember there were days when I couldn't even get through my tasks and had to really lean on others to help me through it. You know, my senior developer, I was like, "Hey, it's that time. I got some questions for you." And so, I had to learn how does Will learn and what's the best way for me to excel in this field? The things that I've done before, I couldn't do it going forward.

+ +

CHAD: Bootcamps are pretty popular. And they are an avenue that certainly didn't exist when I was learning. You said when you were having the conversation with your wife that it sounds like that was just right there as the path forward. But did you consider an alternative path?

+ +

WILL: Yeah. So at that time, I felt like there were probably three paths: there was the bootcamp, there was the college degree, and there was the self-learning path. So the college degree, I thought about it because, at that time, I felt like a lot of companies were still like, hey, you have to have a degree to be hired and be a part of it. So whenever I thought about going back, I didn't know if it was going to cut me off from other jobs, so that was one of the reasons why I really decided, or I really thought about going the degree route.

+ +

And I decided against it because I did a lot of research, and there were companies at that time that were like, you don't need a college degree because I already had a college degree in sports medicine. And so most of them were like, you just have to have a degree. And I was like, okay, I don't think I'm going to be stuck in this position because I didn't have a computer science degree.

+ +

The other way was self-taught. I didn't think that I could put in the time and the work. One thing I learned very, very early on is there were a lot of things that I just didn't know about the field. I didn't know HTML. I didn't know CSS. I didn't know how to get a server started. I didn't know anything. If I knew anything about computers, it was more about the hardware side of it and nothing about the software side. So I knew very quickly that the self-learning aspect wouldn't work for me, and so that's kind of why I decided to go the bootcamp route.

+ +

I asked a lot of mentors, "Hey, what's the best way?" And they're like, "Bootcamp." And they're like, "Go to the one that teaches you the most." And so, at that time, the bootcamp I went to was two years long, but I was able to probably eight months in get a job in tech. And then, I completed it while going to work at that tech company.

+ +

VICTORIA: Oh, that's great.

+ +

CHAD: I mean, this might be a little bit of a hot take, but I'm going to say it anyway, which is I think that if you don't know how to code at all, or very little university programs, computer science programs aren't really set up to teach you that in a great way. It's more likely that someone with that level of experience will really struggle going into a computer science program not really having coded before.

+ +

Bootcamps are much more conducive to learning from scratch along with other people. It's not even necessarily about the programs, but going into a CS degree, so many people already do know how to program. And so it's really hard for them to make a well-balanced program that works for everybody.

+ +

WILL: I totally agree with that.

+ +

VICTORIA: I could see it. It's both ways. The way I've always heard it explained is a computer science degree will teach you a lot about the underlying principles that you might wish you knew later after you have finished your bootcamp. But a bootcamp will prepare you for on-the-job performance like day one, more likely to just give you the full breadth.

+ +

I mean, I've taken computer science 101 at University of Maryland, and I learned HTML, CSS, how to get a basic website up, some simple things that can get you up to speed. I think you could start from scratch and go that route. But it's hard to keep it up to speed with current technology trends in a college atmosphere. And so I think you'll see a lot of partnerships with universities now. And obviously, bootcamps were created to address that gap.

+ +

You got a job while you were still in bootcamp, and I'm curious how that went for you, that job search. That's a huge hurdle to just getting from the bootcamp to the first job; if you have any advice for people who are in a similar situation right now.

+ +

WILL: Yes, it was very challenging at the time. I think I applied to over 400 positions. My biggest thing that I would say is stay the course, hang in there. Keep going. There are a lot of down days that I was like, am I supposed to be in this field? Am I supposed to be here? The other thing that I learned very quickly was resources. Who did I know in the tech field? Who could I reach out to help me with it? Because that was another thing that I learned. I thought whenever I first took my junior dev job that I would come in and be able to really implement tickets and items.

+ +

And I quickly realized that they hired me because of my character and who I was going to be long-term and that I can offer very little at that moment of, hey, coming in, and doing a ticket, and really shipping a feature I cannot do that as a junior dev. But hopefully, in six months or two, three months, however long their time period was that I could ship a portion of a feature.

+ +

VICTORIA: Right. And that's always been...for me, someone hiring for technical roles and the entry-level point, sometimes I would prefer someone who has professional experience. Especially working in consulting, you have the ability to communicate your ideas well and work with clients, but you're still learning the technology side of it. That's a lot less than hiring a new college graduate who hasn't ever worked before [laughs] but may have a computer science degree. It's a totally different value that you're bringing to the role, I think.

+ +

CHAD: And that persistence really pays off. Just to make sure that timeline is clear, I think you interviewed with us for the first time five years ago or so, so I really appreciate you sticking with it and eventually coming back to us. That makes me super, super happy.

+ +

WILL: Yeah, and one thing that I learned along the way is there are different companies out there, and depending on your purpose and your goal, there are great fits depending on what your goal is. And my goal in my career was to learn and to be with a great company that had a great culture.

+ +

And I felt like thoughtbot was a good fit for me with that because I want to enjoy the people that I work with. I want to get to know them. I want to help them be a mentor, be a mentee, and thoughtbot was a good fit with that. That was one of the reasons why I put it on my list of hey, whenever that opportunity comes back, apply, apply, apply back to them.

+ +

CHAD: You originally interviewed with us as a Rails developer for a Rails development position. But along the way, you joined us as a React and React Native developer. So tell us a little bit about that journey along the way.

+ +

WILL: Yeah, so I did as a Rails developer, and I quickly realized that at that point in my career, Rails was harder for me to comprehend. There was nothing visual that I could really understand. And going back to what Victoria said with universities being able to keep up, at the end of my bootcamp, that was when React was on the rise. And so they actually released a module for React, and so I was able to really pick up that module.

+ +

And at that point, I thought React and front end was going to be a lot easier for me to comprehend and easier to get a job in the field, and so that's kind of why I went that front-end developer way. And then it's interesting now because I'm coming back around learning more Rails and, hopefully, be able to contribute to client work with the Rails side.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: thoughbot's not the first agency that you worked at. Before you joined, you were working at another agency. Was there something in particular that gravitated towards this kind of work as opposed to working at maybe a technology startup working on a specific product?

+ +

WILL: Yeah. The two first jobs that I had in tech was typical software as a service products. I enjoyed it, but I felt like we were building on the same thing over and over again. And it was okay, but I know for me that I'm a big-time learner. And so I felt for me, I'm a big-time learner, and so I felt going the agency route would give me the opportunity to be exposed to different aspects of tech.

+ +

So at the last agency, I did some Rails work. It was very, very minimal, but I was able to do that. I was able to learn a lot about React Native and React and probably worked on a handful of jobs. Even at thoughtbot, I've worked on jobs and contracts that range from a month to six months. And I know potentially, I can work on a contract for two years, but it still gives me enough change to where I feel like the tech field will not leave me behind.

+ +

So I can work on a job or a contract for a year and then reset and say, "Oh, React released XYZ." And I can implement that into this new product or contract I'm working on. So that part right there is what really excited me about working for an agency and being a part of the company.

+ +

CHAD: Yeah, that's a big part of that variety, even both on the tech side but also just being able to work with different people and not be bound always to the same thing is one of the reasons why I've been able to do this so long I believe.

+ +

WILL: That's a good point because I love meeting new people. I love getting to know them. And it gives me that opportunity to work for a client, get to know them, and stay in contact with them but even go to a new client. If I was working at a product, I'm with the same company inside the four walls of that company. And so I love that aspect of getting to meet new people and getting to help companies deliver their dreams to the world. I really enjoy that.

+ +

CHAD: And that's what you're going to get to do as part of the host of the show too.

+ +

WILL: Yes. I'm excited about that too.

+ +

VICTORIA: I was going to say the same. You're going to meet so many cool people. [laughs] I've already met a lot of really interesting people in the last two months. So let's ask you a fun question. You're meeting new people; maybe you're introducing a new podcast guest. What's your favorite icebreaker question to ask?

+ +

WILL: I think my favorite question to ask podcast guests is why they do what they do. And the reason why is because it's very interesting seeing what propels people to go and do the things that they do. I guess I'm a student of people and humans. I love understanding the greatest people like Tom Brady, Michael Jordan. I know that may be up for debate.

+ +

VICTORIA: [laughs]

+ +

WILL: But just what makes them click. Also, for our guests, there are so many different aspects and products that people are coming up with, and so it's amazing to hear why they're doing what they do. And a lot of them, I'm like, oh, why didn't I think of that? That's a great idea. [laughter] And so I think that's my favorite question by far is why do you do what you do?

+ +

VICTORIA: I like that, yeah. As soon as I come on, I'm like, "So you're the founder of this. And why did you do that? [laughs] Tell me." But it's always an interesting story, just the right person, and the right place, the right problem to solve, and the right group of people around them to figure it out.

+ +

WILL: Yeah, and definitely the sacrifice that they're making. Being a CEO or founder of a company is not a nine-to-five job. You're sacrificing a lot of time, a lot of effort, resources. So yes, why do you do what you do? Because you're sacrificing so much. So why did you do that to get to this point? I love it.

+ +

VICTORIA: We could ask Chad that. [laughs] Why did you start thoughtbot, Chad? [laughs]

+ +

CHAD: I ask myself that every day.

+ +

[laughter]

+ +

VICTORIA: I know.

+ +

CHAD: No, I'm kidding. Oh, we have a whole episode on that we recorded for our anniversary with the original co-founders that I had, and we did the history of thoughtbot. So I like to point that out every once in a while, Episode 262 from February 12th, 2018. Time flies when you're having fun. I didn't think it was that long ago.

+ +

WILL: [laughs]

+ +

CHAD: We're currently on Episode 442.

+ +

VICTORIA: I will say it is a productive podcast. There are a lot of great episodes that come out. I'm excited to have Will on to help share the experience of [laughs] creating them.

+ +

CHAD: Yeah. And speaking a little bit of meta, this is the first time we've ever had three co-hosts. We have an appetite, the three of us, for trying some new things with this new sort of season that we're embarking on. But we also love the show as it is, and so we're going to keep things sort of going like they are with some rotations and doing some joint episodes and that kind of thing.

+ +

But I wouldn't be surprised if, after a couple of months, we start to layer something new on. I'm not quite sure what that will be yet, whether it will be just maybe episodes with just the three of us, and not a guest, talking about some thoughtbot stuff or some things we want to talk about. Or maybe it could be something else. What do you all think?

+ +

WILL: I love that idea. I love being able to have different options and opening that out. I think it's a great idea. Like you said, I don't know what that looks like, but I'm excited that we have the opportunity to bring different aspects, different podcasts to our guests.

+ +

VICTORIA: Yeah, I'm already thinking of people I can voluntell at thoughtbot [laughter] and talking about topics that I'm interested in. [laughs] There's a lot we could do with that. And yeah, I think it'd be good to mix it up. How has working at thoughtbot supported your work-life balance with your family?

+ +

WILL: It's been amazing. At the time of this recording, I have three kids; their ages are three, two, and a couple of months. And so, from the very beginning of parental leave, being able to take that time and be with my son and take care of all his needs was amazing. And not having to worry about work, yeah, it was top-notch because I was able to really just focus on him and my other two kids. Because when you have a baby and other siblings, it gets tough, so I felt like most of my parental leave was just keeping my baby alive. [laughter]

+ +

The older siblings were amazing and actually surprised me. I thought that they would be jealous, and why is this new human in our house taking your attention? But it was actually the exact opposite. They wanted to hold the baby.

+ +

VICTORIA: Aww.

+ +

WILL: They wanted to be with him. And so it was like, okay, I'll let you hold them, but I got to be here with you, and I got to help you. And my two older kids are very independent. And so that was tough, but it's amazing to see how much they love their younger brother.

+ +

VICTORIA: Aww.

+ +

WILL: Yeah. So that has been amazing. But to continue on the work-life balance, it has been really amazing working at thoughtbot because we are a remote culture, and especially the clients that I've worked with the flexibility of the schedule. So yes, we have meetings that I have to make it to and be a part of the team. But for the most part, as long as I get my work done, I am in a good position.

+ +

So, to be honest, with the newborn, sometimes I'm up at midnight. And I'm able to work while I'm up with my son because that's the time that he wants to get up and eat and hang out, so I'm like, okay, let's hang out. So that flexibility has been amazing for me. I love the remote aspect of it because I am a big family person. So I love being able to be home with my kids as they're growing up, eating lunch with them, going on a walk with them. So yes, it has been amazing. To be honest, I don't know if I can ask for anything more than what thoughtbot provides to me as a parent. So I'm really thankful for that.

+ +

CHAD: That brings back a lot of memories for me because when our son was born, I also was up with him, and it would be one of those scenarios where you finally get him to sleep in the bounce chair or the chair, and you're like, okay, what do I do now? Because he's going to be up again at any moment. I was like, okay, I'll do some coding now, and it's like midnight, one in the morning, or whatever.

+ +

And I got a little bit of a reputation for these pull requests coming in at night but this general sense of understanding about why that's happening. And like, okay, now I'm not in in the morning because this was the schedule that I was on and a real flexibility and understanding of that. But it really brings back memories for me. I'm glad I'm well past that point now.

+ +

[laughter]

+ +

WILL: And I am thankful that thoughtbot is thinking about those things. Like you said, you're past that point, but you still are thinking about those things. And that means a lot to me that it's not in your forethought, but it's still very important to have that culture. And you're remembering how it was when you were a parent. That means a lot to me.

+ +

VICTORIA: Yeah. And I think that if you look at the state of the October's reports and see when developers are actually submitting pull requests, the windows are much longer. So post-pandemic with that giant shift to remote work, you will see them in earlier hours of the day or later hours in the night, but there are longer breaks in between. And I think for knowledge work especially; it's hard to just work an eight-hour block and be able to constantly be outputting during that time. [laughs] So it makes sense from a work-life balance but also a productivity overall balance as well.

+ +

CHAD: That's really interesting. I hadn't seen that report, but it resonates with me as true or resonates with me. And we've always talked about the concept of sustainable pace, and when we were in offices, that often meant Monday through Friday, eight to five, nine to five. This is the schedule we're all keeping. And if someone was deviating from that, it was like, oh, you may not be working sustainably.

+ +

Now, in a remote environment, it is much more about flexibility and recognizing that as long as people are working in a sustainable pace, variety in hours and flexibility is totally okay. And like you said, Will, it's about the work that you're getting done. Like, if there's a problem with what I'm delivering or what I'm able to do, let's have that conversation. Conversation shouldn't be about when I'm working or the hours that I'm working, the amount I'm working.

+ +

WILL: And as a human, your first thought is, is this person working the hours they're supposed to? And I think that's the first thought for a lot of people. But the one thing that I do like about thoughtbot is that trust that we have with our developers. Okay, there may not be their eight-hour block during the day, but are they getting their work done?

+ +

If they're getting the work done, why should I even say anything to them? Because they're being successful. That's what we asked them to do, get the work done. Are their clients happy? If their client is happy, I'm happy. And so I think that's one thing. The trust that thoughtbot has given to me as a developer means a lot to me, too, because I can work at midnight and still be productive and get my work done.

+ +

CHAD: I think it's telling. It's very rare for us to have a conversation with someone about maybe not working enough. It's almost always the opposite which is checking in with people and making sure that they're working sustainably.

+ +

VICTORIA: And I'm curious, Chad, about the policy of the four days of consulting and having Fridays for investment time; how that decision was made at thoughtbot. It's been a policy for a long time.

+ +

CHAD: Well, it comes from our value of continuous improvement. When we were 16 people, all designers, and developers, working client work five days a week, there was no time, strictly speaking, within a sustainable pace to reflect on the way that we were working, to make improvements, to learn new things, to create the open source that we were doing and the blogging that we were doing.

+ +

And so, if we were honest with ourselves, a lot of that stuff was happening outside of normal working time in addition to the five days of client work we were doing. And so I think it was Joe Ferris who said, like, if we believe in continuous improvement, we've got to carve out time and sustainable pace. We've got to carve out time within the week in order to be able to do those things.

+ +

The truth of the matter is a lot of our most popular open-source projects were actually created at a time when we didn't have investment time. And so, like I said, I think if we're honest with ourselves, we were really stretching ourselves thin at that point. So working on client work four days a week made us not only more sustainable but ultimately because it's continuous improvement...and so when you have a feedback cycle where short iterations, you can reflect on the way that you're working or that you have time set aside for making improvements, it makes you better the rest of the time as well.

+ +

And so now it's part of our secret sauce is the reason why we're able to be as productive as we are in that time that we have is because of that time set aside for improvement. The reason why we're able to make the open source and the blog posts that we do which make us have a bigger reputation and make our client work faster because we're able to use open source is because of that schedule. And so it's a self-fulfilling virtuous cycle of improvement. So that's where it comes from and why we've been so successful with it.

+ +

WILL: And that's actually a huge reason why I wanted to work at thoughtbot because one of my first jobs in tech, I would come in and knock out tickets, and I really thought that that was enough to be successful in the field. But then I quickly learned that yes, I was learning the tickets that I was working on, but there was so much more that I did not know, did not understand. And at that point, that's when I had my first son, and we were working five days a week.

+ +

So the biggest question for me was, with a newborn son and working five days a week, when do I fit in that investment time? When do I learn the outside aspect that we're not doing in the everyday grind of our tickets? And I quickly learned that I had to do it on the weekends. I had to do it outside of the hours that I was working. And it was hard. It was not a sustainable pace.

+ +

With thoughtbot, one of my criterias was being able to learn, being able to be mentored, and thoughtbot checked that off. But not only did they check that off, but they gave me the opportunity, the space to be mentored and to learn. So I love Friday's investment time. It's been huge in my career.

+ +

CHAD: I'm giving away all the secrets here, but it's okay because it's the execution that matters. But the reason why at your previous places you weren't necessarily able to do that is because that's not their product. Their product was the SaaS product that you were working on. And so when a company like that thinks about where they're investing, the investments that they're going to make are in their product.

+ +

It's one of the reasons why we call investment time investment time because I wanted to communicate that we are investing in our product, but our product is the way that we work. It is our people and our process, and the tools that we use. And so when we think about making investments as a company, that's what the product that we're in the market with is. And so we can afford to invest in improving that product in the same way that a company whose product is software can afford to invest in that software and has trouble investing in making the people, and the process, and the tools, and the culture better.

+ +

VICTORIA: That makes sense to me. And what I've found so far in having that four-day workweek and the way it comes out from a pricing perspective for clients is that you're paying maybe a premium for hours. But your team is able to get more work done in less amount of time because it's so focused. And then overall, you're getting a higher quality work product in a short amount of time. And I think it just makes a lot of sense to me.

+ +

And I've been working in many consulting companies, and they all have this problem. They all want to put out a lot of knowledge articles and blog posts and be known for their expertise but don't commit to making that time to it or spending the money on investing in people to build those products. So it's something I was really excited about for thoughtbot too. [laughs]

+ +

CHAD: This is great fodder for future episodes with just the three of us. [laughs]

+ +

VICTORIA: Yeah.

+ +

WILL: Love it.

+ +

CHAD: Will, thanks again for joining the show. If we don't get to play D&D again together for a while, this will be a secondary substitute for that.

+ +

WILL: Yes, I do plan on coming back. That was huge also, so don't count me out.

+ +

[laughter]

+ +

CHAD: I won't count you out.

+ +

You can subscribe to the show and find notes for this episode, along with a complete transcript, at giantrobots.fm.

+ +

VICTORIA: If you have questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Twitter @cyptel.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

CHAD: And, Will, if folks want to follow along with you, where are all the places that they can do that?

+ +

WILL: Yeah. You can follow me on Twitter @will23larry. And I would love to interact and chat with you.

+ +

CHAD: Is the 23 for Michael Jordan?

+ +

WILL: Always.

+ +

[laughter]

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

VICTORIA: Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+fdNEyMqT + + ]]> + + Will Larry + Victoria Guido + Chad Pytel + + + 448: AIEDC with Leonard S. Johnson + https://podcast.thoughtbot.com/448 + a93fb7c8-defe-4a2c-bc31-6eeae79c5180 + Thu, 10 Nov 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Leonard S. Johnson is the Founder and CEO of AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses. + +Victoria talks to Leonard about using artificial intelligence for good, bringing the power of AI to local economics, and truly democratizing AI. + 53:34 + no + + + Leonard S. Johnson is the Founder and CEO of AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses. +Victoria talks to Leonard about using artificial intelligence for good, bringing the power of AI to local economics, and truly democratizing AI. +The Artificial Intelligence Economic Development Corporation (AIEDC) (https://netcapital.com/companies/aiedc) +Follow AIEDC on Twitter (https://twitter.com/netcapital), Instagram (https://www.instagram.com/netcapital/), Facebook (https://www.facebook.com/Netcapital/), or LinkedIn (https://www.linkedin.com/company/aiedc/). +Follow Leonard on Twitter (https://twitter.com/LeonardSJ) and LinkedIn (https://www.linkedin.com/in/leonardsjohnson84047/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Leonard S. Johnson or LS, Founder and CEO AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses. Leonard, thanks for being with us today. +LEONARD: Thank you for having me, Victoria. +VICTORIA: I should say LS, thank you for being with us today. +LEONARD: It's okay. It's fine. +VICTORIA: Great. So tell us a little more about AIEDC. +LEONARD: Well, AIEDC stands for Artificial Intelligence Economic Development Corporation. And the original premise that I founded it for...I founded it after completing my postgraduate work at Stanford, and that was 2016. And it was to use AI for economic development, and therefore use AI for good versus just hearing about artificial intelligence and some of the different movies that either take over the world, and Skynet, and watch data privacy, and these other things which are true, and it's very evident, they exist, and they're out there. +But at the end of the day, I've always looked at life as a growth strategy and the improvement of what we could do and focusing on what we could do practically. You do it tactically, then you do it strategically over time, and you're able to implement things. That's why I think we keep building collectively as humanity, no matter what part of the world you're in. +VICTORIA: Right. So you went to Stanford, and you're from South Central LA. And what about that background led you to pursue AI for good in particular? +LEONARD: So growing up in the inner city of Los Angeles, you know, that South Central area, Compton area, it taught me a lot. And then after that, after I completed high school...and not in South Central because I moved around a lot. I grew up with a single mother, never knew my real father, and then my home life with my single mother wasn't good because of just circumstances all the time. +And so I just started understanding that even as a young kid, you put your brain...you utilize something because you had two choices. It's very simple or binary, you know, A or B. A, you do something with yourself, or B, you go out and be social in a certain neighborhood. And I'm African American, so high probability that you'll end up dead, or in a gang, or in crime because that's what it was at that time. It's just that's just a situation. Or you're able to challenge those energies and put them toward a use that's productive and positive for yourself, and that's what I did, which is utilizing a way to learn. +I could always pick up things when I was very young. And a lot of teachers, my younger teachers, were like, "You're very, very bright," or "You're very smart." And there weren't many programs because I'm older than 42. So there weren't as many programs as there are today. So I really like all of the programs. So I want to clarify the context. Today there's a lot more engagement and identification of kids that might be sharper, smarter, whatever their personal issues are, good or bad. And it's a way to sort of separate them. So you're not just teaching the whole group as a whole and putting them all in one basket, but back then, there was not. +And so I just used to go home a lot, do a lot of reading, do a lot of studying, and just knick-knack with things in tech. And then I just started understanding that even as a young kid in the inner city, you see economics very early, but they don't understand that's really what they're studying. They see economics. They can see inflation because making two ends meet is very difficult. They may see gang violence and drugs or whatever it might end up being. And a lot of that, in my opinion, is always an underlining economic foundation. +And so people would say, "Oh, why is this industry like this?" And so forth. "Why does this keep happening?" It's because they can't function. And sometimes, it's just them and their family, but they can't function because it's an economic system. So I started focusing on that and then went into the Marine Corps. And then, after the Marine Corps, I went to Europe. I lived in Europe for a while to do my undergrad studies in the Netherlands in Holland. +VICTORIA: So having that experience of taking a challenge or taking these forces around you and turning into a force for good, that's led you to bring the power of AI to local economics. And is that the direction that you went eventually? +LEONARD: So economics was always something that I understood and had a fascination prior to even starting my company. I started in 2017. And we're crowdfunding now, and I can get into that later. But I self-funded it since 2017 to...I think I only started crowdfunding when COVID hit, which was 2020, and just to get awareness and people out there because I couldn't go to a lot of events. +So I'm like, okay, how can I get exposure? But yeah, it was a matter of looking at it from that standpoint of economics always factored into me, even when I was in the military when I was in the Marine Corps. I would see that...we would go to different countries, and you could just see the difference of how they lived and survived. +And another side note, my son's mother is from Ethiopia, Africa. And I have a good relationship with my son and his mother, even though we've been apart for over 15 years, divorced for over 15 years or so or longer. But trying to keep that, you can just see this dichotomy. You go out to these different countries, and even in the military, it's just so extreme from the U.S. and any part of the U.S, but that then always focused on economics. +And then technology, I just always kept up with, like, back in the '80s when the mobile brick phone came out, I had to figure out how to get one. [laughs] And then I took it apart and then put it back together just to see how it works, so yeah. But it was a huge one, by the way. I mean, it was like someone got another and broke it, and they thought it was broken. And they're like, "This doesn't work. You could take this piece of junk." I'm like, "Okay." [laughs] +VICTORIA: Like, oh, great. I sure will, yeah. Now, I love technology. And I think a lot of people perceive artificial intelligence as being this super futuristic, potentially harmful, maybe economic negative impact. So what, from your perspective, can AI do for local economics or for people who may not have access to that advanced technology? +LEONARD: Well, that's the key, and that's what we're looking to do with AIEDC. When you look at the small and midsize businesses, it's not what people think, or their perception is. A lot of those in the U.S. it's the backbone of the United States, our economy, literally. And in other parts of the world, it's the same where it could be a one or two mom-and-pop shops. That's where that name comes from; it's literally two people. +And they're trying to start something to build their own life over time because they're using their labor to maybe build wealth or somehow a little bit not. And when I mean wealth, it's always relative. It's enough to sustain themselves or just put food on the table and be able to control their own destiny to the best of their ability. +And so what we're looking to do is make a mobile app maker that's 5G that lives in the cloud, that's 5G compliant, that will allow small and midsize businesses to create their own iOS or Android mobile app with no-code or low-code, basically like creating an email. That's how simple we want it to be. When you create your own email, whether you use Microsoft, Google, or whatever you do, and you make it that simple. And there's a simple version, and there could be complexity added to it if they want. That would be the back office digitization or customization, but that then gets them on board with digitization. +It's intriguing that McKinsey just came out with a report stating that in 2023, in order to be economically viable, and this was very recent, that all companies would need to have a digitization strategy. And so when you look at small businesses, and you look at things like COVID-19, or the COVID current ongoing issue and that disruption, this is global. And you look at even the Ukrainian War or the Russian-Ukrainian War, however you term it, invasion, war, special operation, these are disruptions. +And then, on top of that, we look at climate change which has been accelerating in the last two years more so than it was prior to this that we've experienced. So this is something that everyone can see is self-evident. I'm not even focused on the cause of the problem. My brain and the way I think, and my team, we like to focus on solutions. My chairman is a former program director of NASA who managed 1,200 engineers that built the International Space Station; what was it? 20-30 years ago, however, that is. And he helped lead and build that from Johnson Center. +And so you're focused on solutions because if you're building the International Space Station, you can only focus on solutions and anticipate the problems but not dwell on them. And so that kind of mindset is what I am, and it's looking to help small businesses do that to get them on board with digitization and then in customization. And then beyond that, use our system, which is called M.I.N.D. So we own these...we own patents, three patents, trademarks, and service marks related to artificial intelligence that are in the field of economics. +And we will utilize DEVS...we plan to do that which is a suite of system specifications to predict regional economic issues like the weather in a proactive way, not reactive. A lot of economic situations are reactive. It's reactive to the Federal Reserve raising interest rates or lowering rates, Wall Street, you know, moving money or not moving money. It is what it is. I mean, I don't judge it. I think it's like financial engineering, and that's fine. It's profitability. +But then, at the end of the day, if you're building something, it's like when we're going to go to space. When rockets launch, they have to do what they're intended to do. Like, I know that Blue Origin just blew up recently. Or if they don't, they have a default, and at least I heard that the Blue Origin satellite, if it were carrying passengers, the passengers would have been safe because it disembarked when it detected its own problem. +So when you anticipate these kinds of problems and you apply them to the local small business person, you can help them forecast and predict better like what weather prediction has done. And we're always improving that collectively for weather prediction, especially with climate change, so that it can get to near real-time as soon as possible or close a window versus two weeks out versus two days out as an example. +VICTORIA: Right. Those examples of what you call a narrow economic prediction. +LEONARD: Correct. It is intriguing when you say narrow economic because it wouldn't be narrow AI. But it would actually get into AGI if you added more variables, which we would. The more variables you added in tenancies...so if you're looking at events, the system events discretion so discrete event system specification you would specify what they really, really need to do to have those variables. +But at some point, you're working on a system, what I would call AGI. But AGI, in my mind, the circles I run in at least or at least most of the scientists I talk to it's not artificial superintelligence. And so the general public thinks AGI...and I've said this to Stephen Ibaraki, who's the founder of AI for Good at Global Summit at the United Nations, and one of his interviews as well. It's just Artificial General Intelligence, I think, has been put out a lot by Hollywood and entertainment and so forth, and some scientists say certain things. We won't be at artificial superintelligence. +We might get to Artificial General Intelligence by 2030 easily, in my opinion. But that will be narrow AI, but it will cover what we look at it in the field as cross-domain, teaching a system to look at different variables because right now, it's really narrow. Like natural language processing, it's just going to look at language and infer from there, and then you've got backward propagation that's credit assignment and fraud and detection. Those are narrow data points. +But when you start looking at something cross-domain...who am I thinking of? Pedro Domingos who wrote the Master Algorithm, which actually, Xi Jinping has a copy of, the President of China, on his bookshelf in his office because they've talked about that, and these great minds because Stephen Ibaraki has interviewed these...and the founder of Google Brain and all of these guys. +And so there's always this debate in the scientific community of what is narrow AI what it's not. But at the end of the day, I just like Pedro's definition of it because he says the master algorithm will be combining all five, so you're really crossing domains, which AI hasn't done that. And to me, that will be AGI, but that's not artificial superintelligence. And artificial superintelligence is when it becomes very, you know, like some of the movies could say, if we as humanity just let it run wild, it could be crazy. +VICTORIA: One of my questions is the future of AI more like iRobot or Bicentennial Man? +LEONARD: Well, you know, interesting. That's a great question, Victoria. I see most of AI literally as iRobot, as a tool more than anything, except at the end when it implied...so it kind of did two things in that movie, but a wonderful movie to bring up. And I like Will Smith perfectly. Well, I liked him a lot more before -- +VICTORIA: I think iRobot is really the better movie. +LEONARD: Yeah, so if people haven't seen iRobot, I liked Will Smith, the actor. But iRobot showed you two things, and it showed you, one, it showed hope. Literally, the robot...because a lot of people put AI and robots. And AI by itself is the brain or the mind; I should say hardware are the robots or the brain. Software...AI in and of itself is software. It's the mind itself. That's why we have M.I.N.D Machine Intelligence NeuralNetwork Database. We literally have that. That's our acronym and our slogan and everything. And it's part of our patents. But its machine intelligence is M.I.N.D, and we own that, you know; the company owns it. +And so M.I.N.D...we always say AI powered by M.I.N.D. We're talking about that software side of, like, what your mind does; it iterates and thinks, the ability to think itself. Now it's enclosed within a structure called, you know, for the human, it's called a brain, the physical part of it, and that brain is enclosed within the body. So when you look at robots...and my chairman was the key person for robotics for the International Space Station. So when you look at robotics, you are putting that software into hardware, just like your cell phone. You have the physical, and then you have the actual iOS, which is the operating system. +So when you think about that, yeah, iRobot was good because it showed how these can be tools, and they were very, in the beginning of the movie, very helpful, very beneficial to humanity. But then it went to a darker side and showed where V.I.K.I, which was an acronym as well, I think was Virtual Interactive Kinetic technology of something. Yeah, I believe it was Virtual Interactive Kinetic inference or technology or something like that, V.I.K.I; I forgot the last I. But that's what it stood for. +It was an acronym to say...and then V.I.K.I just became all aware and started killing everyone with robots and just wanted to say, you know, this is futile. But then, at the very, very end, V.I.K.I learned from itself and says, "Okay, I guess this isn't right." Or the other robot who could think differently argued with V.I.K.I, and they destroyed her. And it made V.I.K.I a woman in the movie, and then the robot was the guy. But that shows that it can get out of hand. +But it was intriguing to me that they had her contained within one building. This wouldn't be artificial superintelligence. And I think sometimes Hollywood says, "Just take over everything from one building," no. It wouldn't be on earth if it could. But that is something we always have to think about. We have to think about the worst-case scenarios. +I think every prudent scientist or business person or anyone should do that, even investors, I mean, if you're investing something for the future. But you also don't focus on it. You don't think about the best-case scenario, either. But there's a lot of dwelling on the worst-case scenario versus the good that we can do given we're looking at where humanity is today. I mean, we're in 2022, and we're still fighting wars that we fought in 1914. +VICTORIA: Right. Which brings me to my next question, which is both, what are the most exciting opportunities to innovate in the AI space currently? And conversely, what are the biggest challenges that are facing innovation in that field? +LEONARD: Ooh, that's a good question. I think, in my opinion, it's almost the same answer; one is...but I'm in a special field. And I'm surprised there's not a lot of competition for our company. I mean, it's very good for me and the company's sense. It's like when Mark Zuckerberg did Facebook, there was Friendster, and there was Myspace, but they were different. They were different verticals. And I think Mark figured out how to do it horizontally, good or bad. I'm talking about the beginning of when he started Facebook, now called Meta. +But I'm saying utilizing AI in economics because a lot of times AI is used in FinTech and consumerism, but not economic growth where we're really talking about growing something organically, or it's called endogenous growth. Because I studied Paul Romer's work, who won the Nobel Prize in 2018 for economic science. And he talked about the nature of ideas. And we were working on something like that in Stanford. +And I put out a book in 2017 of January talking about cryptocurrencies, artificial intelligence but about the utilization of it, but not the speculation. I never talked about speculation. I don't own any crypto; I would not. It's only once it's utilized in its PureTech form will it create something that it was envisioned to do by the protocol that Satoshi Nakamoto sort of created. And it still fascinates me that people follow Bitcoin protocol, even for the tech and the non-tech, but they don't know who Satoshi is. +But yeah, it's a white paper. You're just following a white paper because I think logically, the world is going towards that iteration of evolution. And that's how AI could be utilized for good in an area to focus on it with economics and solving current problems. And then going forward to build a new economy where it's not debt-based driven or consumer purchase only because that leaves a natural imbalance in the current world structure. +The western countries are great. We do okay, and we go up and down. But the emerging and developing countries just get stuck, and they seem to go into a circular loop. And then there are wars as a result of these things and territory fights and so forth. So that's an area I think where it could be more advanced is AI in the economic realm, not so much the consumer FinTech room, which is fine. +But consumer FinTech, in my mind, is you're using AI to process PayPal. That's where I think Elon just iterated later because PayPal is using it for finance. You're just moving things back and forth, and you're just authenticating everything. But then he starts going on to SpaceX next because he's like, well, let me use technology in a different way. And I do think he's using AI on all of his projects now. +VICTORIA: Right. So how can that tech solve real problems today? Do you see anything even particular about Southern California, where we're both at right now, where you think AI could help predict some outcomes for small businesses or that community? +LEONARD: I'm looking to do it regionally then globally. So I'm part of this Southern Cal Innovation Hub, which is just AI. It's an artificial intelligence coordination between literally San Diego County, Orange County, and Los Angeles County. And so there's a SoCal Innovation Hub that's kind of bringing it together. But there are all three groups, like; I think the CEO in Orange County is the CEO of Leadership Alliance. And then in San Diego, there's another group I can't remember their name off the top of my head, and I'm talking about the county itself. So each one's representing a county because, you know. +And then there's one in Northern California that I'm also associated with where if you look at California as its own economy in the U.S., it's still pretty significant as an economic cycle in the United States, period. That's why so many politicians like California because they can sway the votes. So yeah, we're looking to do that once, you know, we are raising capital. We're crowdfunding currently. Our total raise is about 6 million. And so we're talking to venture capitalists, private, high net worth investors as well. +Our federal funding is smaller. It's just like several hundred thousand because most people can only invest a few thousand. But I always like to try to give back. If you tell people...if you're Steve Jobs, like, okay, I've got this Apple company. In several years, you'll see the potential. And people are like, ah, whatever, but then they kick themselves 15 years later. [laughs] Like, oh, I wish I thought about that Apple stock for $15 when I could. But you give people a chance, and you get the word out, and you see what happens. +Once you build a system, you share it. There are some open-source projects. But I think the open source, like OpenAI, as an example, Elon Musk funds that as well as Microsoft. They both put a billion dollars into it. It is an open-source project. OpenAI claims...but some of the research does go back to Microsoft to be able to see it. And DeepMind is another research for AI, but they're owned by Google. +And so, I'm also very focused on democratizing artificial intelligence for the benefit of everyone. I really believe that needs to be democratized in a sense of tying it to economics and making it utilized for everyone that may need it for the benefit of humanity where it's profitable and makes money, but it's not just usurping. +MID-ROLL AD: +As life moves online, brick-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: With that democratizing it, is there also a need to increase the understanding of the ethics around it and when there are certain known use cases for AI where it actually is discriminatory and plays to systemic problems in our society? Are you familiar with that as well? +LEONARD: Yes, absolutely. Well, that's my whole point. And, Victoria, you just hit the nail on the head. Truly democratizing AI in my mind and in my brain the way it works is it has opened up for everyone. Because if you really roll it back, okay, companies now we're learning...we used to call it several years ago UGC, User Generated Content. And now a lot of people are like, okay, if you're on Facebook, you're the product, right? Or if you're on Instagram, you're the product. And they're using you, and you're using your data to sell, et cetera, et cetera. +But user-generated content it's always been that. It's just a matter of the sharing of the economic. That's why I keep going back to economics. So if people were, you know, you wouldn't have to necessarily do advertising if you had stakeholders with advertising, the users and the company, as an example. If it's a social media company, just throwing it out there, so let's say you have a social media...and this has been talked about, but I'm not the first to introduce this. This has been talked about for over ten years, at least over 15 years. +And it's you share as a triangle in three ways. So you have the user and everything else. So take your current social media, and I won't pick on Facebook, but I'll just use them, Facebook, Instagram, or Twitter. Twitter's having issues recently because Elon is trying to buy them or get out of buying them. But you just looked at that data, and then you share with the user base. What's the revenue model? And there needs to be one; let me be very clear. There has to be incentive, and there has to be profitability for people that joined you earlier, you know, joined the corporation, or become shareholders, or investors, or become users, or become customers. +They have to be able to have some benefit, not extreme greater than everyone else but a great benefit from coming in earlier by what they contributed at the time. And that is what makes this system holistic in my opinion, like Reddit or any of these bloggers. But you make it where they use their time and the users, and you share it with the company and then the data and so forth, and whatever revenue economic model you have, and it's a sort of a three-way split. It's just not always equal. +And that's something that I think in economics, we're still on a zero-sum game, I win, you lose sort of economic model globally. That's why there's a winner of a war and a loser of a war. But in reality, as you know, Victoria, there are no winners of any war. So it's funny, [laughs] I was just saying, well, you know, because of the economic mode, but Von Neumann, who talked about that, also talked about something called a non-zero-sum game when he talked about it in mathematics that you can win, and I can win; we just don't win equally because they never will match that. +So if I win, I may win 60; you win 40. Or you may win 60, I win 40, and we agree to settle on that. It's an agreement versus I'm just going to be 99, and you'll be 1%, or I'm just going to be 100, and you're at 0. And I think that our economic model tends to be a lot of that, like, when you push forth and there needs to be more of that. +When you talk about the core of economics...and I go way back, you know, prior to the Federal Reserve even being started. I just look at the world, and it's always sort of been this land territorial issue of what goods are under the country. But we've got technology where we can mitigate a lot of things and do the collective of help the earth, and then let's go off to space, all of space. That's where my brain is focused on. +VICTORIA: Hmm. Oh yeah, that makes sense to me. I think that we're all going to have to evolve our economic models here in the future. I wonder, too, as you're building your startup and you're building your company, what are some of the technology trade-offs you're having to make in the stack of the AI software that you're building? +LEONARD: Hmm. Good question. But clarify, this may be a lot deeper dive because that's a general question. And I don't want to...yeah, go ahead. +VICTORIA: Because when you're building AI, and you're going to be processing a lot of data, I know many data scientists that are familiar with tools like Jupyter Notebooks, and R, and Python. And one issue that I'm aware of is keeping the environments the same, so everything that goes into building your app and having those infrastructure as code for your data science applications, being able to afford to process all that data. [laughs] +And there are just so many factors that go into building an AI app versus building something that's more easy, like a web-based user form. So just curious if you've encountered those types of trade-offs or questions about, okay, how are we going to actually build an app that we can put out on everybody's phone and that works responsibly? +LEONARD: Oh, okay. So let me be very clear, but I won't give too much of the secret sauce away. But I can define this technically because this is a technical audience. This is not...so what you're really talking about is two things, and I'm clear about this, though. So the app maker won't really read and write a lot of data. It'll just be the app where people could just get on board digitalization simple, you know, process payments, maybe connect with someone like American Express square, MasterCard, whatever. And so that's just letting them function. That's sort of small FinTech in my mind, you know, just transaction A to B, B to A, et cetera. +And it doesn't need to be peer-to-peer and all of the crypto. It doesn't even need to go that level yet. That's just level one. Then they will sign up for a service, which is because we're really focused on artificial intelligence as a service. And that, to me, is the next iteration for AI. I've been talking about this for about three or four years now, literally, in different conferences and so forth for people who haven't hit it. But that we will get to that point where AI will become AI as a service, just like SaaS is. +We're still at the, you know, most of the world on the legacy systems are still software as a service. We're about to hit AI as a service because the world is evolving. And this is true; they did shut it down. But you did have okay, so there are two case points which I can bring up. So JP Morgan did create something called a Coin, and it was using AI. And it was a coin like crypto, coin like a token, but they called it a coin. +But it could process, I think, something like...I may be off on this, so to the sticklers that will be listening, please, I'm telling you I may be off on the exact quote, but I think it was about...it was something crazy to me, like 200,000 of legal hours and seconds that it could process because it was basically taking the corporate legal structure of JP Morgan, one of the biggest banks. I think they are the biggest bank in the U.S. JPMorgan Chase. +And they were explaining in 2017 how we created this, and it's going to alleviate this many hours of legal work for the bank. And I think politically; something happened because they just pulled away. I still have the original press release when they put it out, and it was in the media. And then it went away. I mean, no implementation [laughs] because I think there was going to be a big loss of jobs for it. And they basically would have been white-collar legal jobs, most specifically lawyers literally that were working for the bank. +And when they were talking towards investment, it was a committee. I was at a conference. And I was like, I was fascinated by that. And they were basically using Bitcoin protocol as the tokenization protocol, but they were using AI to process it. And it was basically looking at...because legal contracts are basically...you can teach it with natural language processing and be able to encode and almost output it itself and then be able to speak with each other. +Another case point was Facebook. They had...what was it? Two AI systems. They began to create their own language. I don't know if you remember that story or heard about it, and Facebook shut it down. And this was more like two years ago, I think, when they were saying Facebook was talking, you know, when they were Facebook, not Meta, so maybe it was three years ago. And they were talking, and they were like, "Oh, Facebook has a language. It's talking to each other." And it created its own little site language because it was two AI bots going back and forth. And then the engineers at Facebook said, "We got to shut this down because this is kind of getting out of the box." +So when you talk about AI as a service, yes, the good and the bad, and what you take away is AWS, Oracle, Google Cloud they do have services where it doesn't need to cost you as much anymore as it used to in the beginning if you know what you're doing ahead of time. And you're not just running iterations or data processing because you're doing guesswork versus, in my opinion, versus actually knowing exactly specifically what you're looking for and the data set you're looking to get out of it. +And then you're talking about just basically putting in containers and clustering it because it gets different operations. And so what you're really looking at is something called an N-scale graph data that can process data in maybe sub seconds at that level, excuse me. And one of my advisors is the head of that anyway at AGI laboratory. So he's got an N graph database that can process...when we implement it, we'll be able to process data at the petabyte level at sub-seconds, and it can run on platforms like Azure or AWS, and so forth. +VICTORIA: Oh, that's interesting. So it sounds like cloud providers are making compute services more affordable. You've got data, the N-scale graph data, that can run more transactions more quickly. And I'm curious if you see any future trends since I know you're a futurist around quantum computing and how that could affect capacity for -- +LEONARD: Oh [laughs] We haven't even gotten there yet. Yes. Well, if you look at N-scale, if you know what you're doing and you know what to look for, then the quantum just starts going across different domains as well but at a higher hit rate. So there's been some quantum computers online. There's been several...well, Google has their quantum computer coming online, and they've been working on it, and Google has enough data, of course, to process. So yeah, they've got that data, lots of data. And quantum needs, you know, if it's going to do something, it needs lots of data. +But then the inference will still be, I think, quantum is very good at processing large, large, large amounts of data. We can just keep going if you really have a good quantum computer. But it's really narrow. You have to tell it exactly what it wants, and it will do it in what we call...which is great like in P or NP square or P over NP which is you want to do it in polynomial time, not non-polynomial, polynomial time which is...now speaking too fast. Okay, my brain is going faster than my lips. Let me slow it down. +So when you start thinking about processing, if we as humans, let's say if I was going to process A to Z, and I'm like, okay, here is this equation, if I tell you it takes 1000 years, it's of no use to us, to me and you Victoria because we're living now. Now, the earth may benefit in 1000 years, but it's still of no use. But if I could take this large amount of data and have it process within minutes, you know, worst case hours...but then I'll even go down to seconds or sub-seconds, then that's really a benefit to humanity now, today in present term. +And so, as a futurist, yes, as the world, we will continue to add data. We're doing it every day, and we already knew this was coming ten years ago, 15 years ago, 20 years ago, even actually in the '50s when we were in the AI winter. We're now in AI summer. In my words, I call it the AI summer. So as you're doing this, that data is going to continue to increase, and quantum will be needed for that. But then the specific need...quantum is very good at looking at a specific issue, specifically for that very narrow. +Like if you were going to do the trajectory to Jupiter or if we wanted to send a probe to Jupiter or something, I think we're sending something out there now from NASA, and so forth, then you need to process all the variables, but it's got one trajectory. It's going one place only. +VICTORIA: Gotcha. Well, that's so interesting. I'm glad I asked you that question. And speaking of rockets going off to space, have you ever seen a SpaceX launch from LA? +LEONARD: Actually, I saw one land but not a launch. I need to go over there. It's not too far from me. But you got to give credit where credit's due and Elon has a reusable rocket. See, that's where technology is solving real-world problems. Because NASA and I have, you know, my chairman, his name is Alexander Nawrocki, you know, he's Ph.D., but I call him Rocki. He goes by Rocki like I go by LS. +But it's just we talk about this like NASA's budget. [laughs] How can you reduce this? And Elon says they will come up with a reusable rocket that won't cost this much and be able to...and that's the key. That was the kind of Holy Grail where you can reuse the same rocket itself and then add some little variables on top of it. But the core, you wouldn't constantly be paying for it. +And so I think where the world is going...and let me be clear, Elon pushes a lot out there. He's just very good at it. But I'm also that kind of guy that I know that Tesla itself was started by two Stanford engineers. Elon came on later, like six months, and then he invested, and he became CEO, which was a great investment for Elon Musk. +And then CEO I just think it just fit his personality because it was something he loved. But I also have studied for years Nikola Tesla, and I understand what his contributions created where we are today with all the patents that he had. And so he's basically the father of WiFi and why we're able to communicate in a lot of this. We've perfected it or improved it, but it was created by him in the 1800s. +VICTORIA: Right. And I don't think he came from as fortunate a background as Elon Musk, either. Sometimes I wonder what I could have done born in similar circumstances. [laughter] And you certainly have made quite a name for yourself. +LEONARD: Well, I'm just saying, yeah, he came from very...he did come from a poor area of Russia which is called the Russian territory, to be very honest, Eastern Europe, definitely Eastern Europe. But yeah, I don't know once you start thinking about that [laughs]. You're making me laugh, Victoria. You're making me laugh. +VICTORIA: No, I actually went camping, a backpacking trip to the Catalina Island, and there happened to be a SpaceX launch that night, and we thought it was aliens because it looked wild. I didn't realize what it was. But then we figured it was a launch, so it was really great. I love being here and being close to some of this technology and the advancements that are going on. +I'm curious if you have some thoughts about...I hear a lot about or you used to hear about Silicon Valley Tech like very Northern California, San Francisco focus. But what is the difference in SoCal? What do you find in those two communities that makes SoCal special? [laughs] +LEONARD: Well, I think it's actually...so democratizing AI. I've been in a moment like that because, in 2015, I was in Dubai, and they were talking about creating silicon oasis. And so there's always been this model of, you know, because they were always, you know, the whole Palo Alto thing is people would say it and it is true. I mean, I experienced it. Because I was in a two-year program, post-graduate program executive, but we would go up there...I wasn't living up there. I had to go there maybe once every month for like three weeks, every other month or something. +But when you're up there, it is the air in the water. It's just like, people just breathe certain things. Because around the world, and I would travel to Japan, and China, and other different parts of Asia, Vietnam, et cetera and in Africa of course, and let's say you see this and people are like, so what is it about Silicon Valley? And of course, the show, there is the Hollywood show about it, which is pretty a lot accurate, which is interesting, the HBO show. +But you would see that, and you would think, how are they able to just replicate this? And a lot of it is a convergence. By default, they hear about these companies' access because the key is access, and that's what we're...like this podcast. I love the concept around it because giving awareness, knowledge, and access allows other people to spread it and democratize it. So it's just not one physical location, or you have to be in that particular area only to benefit. I mean, you could benefit in that area, or you could benefit from any part of the world. +But since they started, people would go there; engineers would go there. They built company PCs, et cetera. Now that's starting to spread in other areas like Southern Cal are creating their own innovation hubs to be able to bring all three together. And those three are the engineers and founders, and idea makers and startups. And you then need the expertise. I'm older than 42; I'm not 22. [laughs] So I'm just keeping it 100, keeping it real. So I'm not coming out at 19. I mean, my son's 18. And I'm not coming out, okay, this my new startup, bam, give me a billion dollars, I'm good. And let me just write off the next half. +But when you look at that, there's that experience because even if you look at Mark Zuckerberg, I always tell people that give credit where credit is due. He brought a senior team with him when he was younger, and he didn't have the experience. And his only job has been Facebook out of college. He's had no other job. And now he's been CEO of a multi-billion dollar corporation; that's a fact. Sometimes it hurts people's feelings. Like, you know what? He's had no other job. Now that can be good and bad, [laughs] but he's had no other jobs. +And so that's just a credit, like, if you can surround yourself with the right people and be focused on something, it can work to the good or the bad for your own personal success but then having that open architecture. And I think he's been trying to learn and others versus like an Elon Musk, who embraces everything. He's just very open in that sense. But then you have to come from these different backgrounds. +But let's say Elon Musk, Mark Zuckerberg, let's take a guy like myself or whatever who didn't grow up with all of that who had to make these two ends meet, figure out how to do the next day, not just get to the next year, but get to the next day, get to the next week, get to the next month, then get to the next year. It just gives a different perspective as well. Humanity's always dealing with that. +Because we had a lot of great engineers back in the early 1900s. They're good or bad, you know, you did have Nikola Tesla. You had Edison. I'm talking about circa around 1907 or 1909, prior to World War I. America had a lot of industries. They were the innovators then, even though there were innovations happening in Europe, and Africa, and China, as well and Asia. But the innovation hub kind of created as the America, quote, unquote, "industrial revolution." And I think we're about to begin a new revolution sort of tech and an industrial revolution that's going to take us to maybe from 20...we're 2022 now, but I'll say it takes us from 2020 to 2040 in my head. +VICTORIA: So now that communities can really communicate across time zones and locations, maybe the hubs are more about solving specific problems. There are regional issues. That makes a lot more sense. +LEONARD: Yes. And collaborating together, working together, because scientists, you know, COVID taught us that. People thought you had to be in a certain place, but then a lot of collaboration came out of COVID; even though it was bad globally, even though we're still bad, if people were at home, they start collaborating, and scientists will talk to scientists, you know, businesses, entrepreneurs, and so forth. +But if Orange County is bringing together the mentors, the venture capital, or at least Southern California innovation and any other place, I want to say that's not just Silicon Valley because Silicon Valley already has it; we know that. And that's that region. It's San Jose all the way up to...I forgot how far north it's past San Francisco, actually. But it's that region of area where they encompass the real valley of Silicon Valley if you're really there. And you talk about these regions. +Yes, I think we're going to get to a more regional growth area, and then it'll go more micro to actually cities later in the future. But regional growth, I think it's going to be extremely important globally in the very near term. I'm literally saying from tomorrow to the next, maybe ten years, regional will really matter. And then whatever you have can scale globally anyway, like this podcast we're doing. This can be distributed to anyone in the world, and they can listen at ease when they have time. +VICTORIA: Yeah, I love it. It's both exciting and also intimidating. [laughs] And you mentioned your son a little bit earlier. And I'm curious, as a founder and someone who spent a good amount of time in graduate and Ph.D. programs, if you feel like it's easy to connect with your son and maintain that balance and focusing on your family while you're building a company and investing in yourself very heavily. +LEONARD: Well, I'm older, [laughs] so it's okay. I mean, I've mentored him, you know. And me and his mom have a relationship that works. I would say we have a better relationship now than when we were together. It is what it is. But we have a communication level. And I think she was just a great person because I never knew my real father, ever. I supposedly met him when I was two or one; I don't know. But I have no memories, no photos, nothing. And that was just the environment I grew up in. +But with my son, he knows the truth of everything about that. He's actually in college. I don't like to name the school because it's on the East Coast, and it's some Ivy League school; that's what I will say. And he didn't want to stay on the West Coast because I'm in Orange County and his mom's in Orange County. He's like, "I want to get away from both of you people." [laughter] And that's a joke, but he's very independent. He's doing well. When he graduated high school, he graduated with 4.8 honors. He made the valedictorian. He was at a STEM school. +VICTORIA: Wow. +LEONARD: And he has a high GPA. He's studying computer science and economics as well at an Ivy League, and he's already made two or three apps at college. And I said, "You're not Mark, so calm down." [laughter] But anyway, that was a recent conversation. I won't go there. But then some people say, "LS, you should be so happy." What is it? The apple doesn't fall far from the tree. +But this was something he chose around 10 or 11. I'm like, whatever you want to do, you do; I'll support you no matter what. And his mom says, "Oh no, I think you programmed him to be like you." [laughs] I'm like, no, I can't do that. I just told him the truth about life. And he's pretty tall. +VICTORIA: You must have -- +LEONARD: He played basketball in high school a lot. I'm sorry? +VICTORIA: I was going to say you must have inspired him. +LEONARD: Yeah. Well, he's tall. He did emulate me in a lot of ways. I don't know why. I told him just be yourself. But yes, he does tell me I'm an inspiration to that; I think because of all the struggles I've gone through when I was younger. And you're always going through struggles. I mean, it's just who you are. I tell people, you know, you're building a company. You have success. You can see the future, but sometimes people can't see it, [laughs] which I shouldn't really say, but I'm saying anyway because I do that. +I said this the other night to some friends. I said, "Oh, Jeff Bezo's rocket blew up," going, you know, Blue Origin rocket or something. And then I said Elon will tell Jeff, "Well, you only have one rocket blow up. I had three, [laughter] SpaceX had three." So these are billionaires talking to billionaires about, you know, most people don't even care. You're worth X hundred billion dollars. I mean, they're worth 100 billion-plus, right? +VICTORIA: Right. +LEONARD: I think Elon is around 260 billion, and Jeff is 160 or something. Who cares about your rocket blowing up? But it's funny because the issues are still always going to be there. I've learned that. I'm still learning. It doesn't matter how much wealth you have. You just want to create wealth for other people and better their lives. The more you search on bettering lives, you're just going to have to wake up every day, be humble with it, and treat it as a new day and go forward and solve the next crisis or problem because there will be one. +There is not where there are no problems, is what I'm trying to say, this panacea or a utopia where you personally, like, oh yeah, I have all this wealth and health, and I'm just great. Because Elon has had divorce issues, so did Jeff Bezos. So I told my son a lot about this, like, you never get to this world where it's perfect in your head. You're always going to be doing things. +VICTORIA: That sounds like an accurate future prediction if I ever heard one. [laughs] Like, there will be problems. No matter where you end up or what you choose to do, you'll still have problems. They'll just be different. [laughs] +LEONARD: Yeah, and then this is for women and men. It means you don't give up. You just keep hope alive, and you keep going. And I believe personally in God, and I'm a scientist who actually does. But I look at it more in a Godly aspect. But yeah, I just think you just keep going, and you keep building because that's what we do as humanity. It's what we've done. It's why we're here. And we're standing on the shoulders of giants, and I just always considered that from physicists and everyone. +VICTORIA: Great. And if people are interested in building something with you, you have that opportunity right now to invest via the crowdfunding app, correct? +LEONARD: Yes, yes, yes. They can do that because the company is still the same company because eventually, we're going to branch out. My complete vision for AIEDC is using artificial intelligence for economic development, and that will spread horizontally, not just vertically. Vertically right now, just focus on just a mobile app maker digitization and get...because there are so many businesses even globally, and I'm not talking only e-commerce. +So when I say small to midsize business, it can be a service business, car insurance, health insurance, anything. It doesn't have to be selling a particular widget or project, you know, product. And I'm not saying there's nothing wrong with that, you know, interest rates and consumerism. But I'm not thinking about Shopify, and that's fine, but I'm talking about small businesses. And there's the back office which is there are a lot of tools for back offices for small businesses. +But I'm talking about they create their own mobile app more as a way to communicate with their customers, update them with their customers, and that's key, especially if there are disruptions. So let's say that there have been fires in California. In Mississippi or something, they're out of water. In Texas, last year, they had a winter storm, electricity went out. So all of these things are disruptions. This is just in the U.S., +And of course, I won't even talk about Pakistan, what's going on there and the flooding and just all these devastating things, or even in China where there's drought where there are these disruptions, and that's not counting COVID disrupts, the cycle of business. It literally does. And it doesn't bubble up until later when maybe the central banks and governments pay attention to it, just like in Japan when that nuclear, unfortunately, that nuclear meltdown happened because of the earthquake; I think it was 2011. +And that affected that economy for five years, which is why the government has lower interest rates, negative interest rates, because they have to try to get it back up. But if there are tools and everyone's using more mobile apps and wearables...and we're going to go to the metaverse and all of that. So the internet of things can help communicate that. So when these types of disruptions happen, the flow of business can continue, at least at a smaller level, for an affordable cost for the business. I'm not talking about absorbing costs because that's meaningless to me. +VICTORIA: Yeah, well, that sounds like a really exciting project. And I'm so grateful to have this time to chat with you today. Is there anything else you want to leave for our listeners? +LEONARD: If they want to get involved, maybe they can go to our crowdfunding page, or if they've got questions, ask about it and spread the word. Because I think sometimes, you know, they talk about the success of all these companies, but a lot of it starts with the founder...but not a founder. If you're talking about a startup, it starts with the founder. +But it also stops with the innovators that are around that founder, male or female, whoever they are. And it also starts with their community, building a collective community together. And that's why Silicon Valley is always looked at around the world as this sort of test case of this is how you create something from nothing and make it worth great value in the future. And I think that's starting to really spread around the world, and more people are opening up to this. It's like the crowdfunding concept. +I think it's a great idea, like more podcasts. I think this is a wonderful idea, podcasts in and of themselves, so people can learn from people versus where in the past you would only see an interview on the business news network, or NBC, or Fortune, or something like that, and that's all you would understand. But this is a way where organically things can grow. I think the growth will continue, and I think the future's bright. We just have to know that it takes work to get there. +VICTORIA: That's great. Thank you so much for saying that and for sharing your time with us today. I learned a lot myself, and I think our listeners will enjoy it as well. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobot.fm. You can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Leonard S. Johnson. + + + Leonard S. Johnson is the Founder and CEO of AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses.

+ +

Victoria talks to Leonard about using artificial intelligence for good, bringing the power of AI to local economics, and truly democratizing AI.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Leonard S. Johnson or LS, Founder and CEO AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses. Leonard, thanks for being with us today.

+ +

LEONARD: Thank you for having me, Victoria.

+ +

VICTORIA: I should say LS, thank you for being with us today.

+ +

LEONARD: It's okay. It's fine.

+ +

VICTORIA: Great. So tell us a little more about AIEDC.

+ +

LEONARD: Well, AIEDC stands for Artificial Intelligence Economic Development Corporation. And the original premise that I founded it for...I founded it after completing my postgraduate work at Stanford, and that was 2016. And it was to use AI for economic development, and therefore use AI for good versus just hearing about artificial intelligence and some of the different movies that either take over the world, and Skynet, and watch data privacy, and these other things which are true, and it's very evident, they exist, and they're out there.

+ +

But at the end of the day, I've always looked at life as a growth strategy and the improvement of what we could do and focusing on what we could do practically. You do it tactically, then you do it strategically over time, and you're able to implement things. That's why I think we keep building collectively as humanity, no matter what part of the world you're in.

+ +

VICTORIA: Right. So you went to Stanford, and you're from South Central LA. And what about that background led you to pursue AI for good in particular?

+ +

LEONARD: So growing up in the inner city of Los Angeles, you know, that South Central area, Compton area, it taught me a lot. And then after that, after I completed high school...and not in South Central because I moved around a lot. I grew up with a single mother, never knew my real father, and then my home life with my single mother wasn't good because of just circumstances all the time.

+ +

And so I just started understanding that even as a young kid, you put your brain...you utilize something because you had two choices. It's very simple or binary, you know, A or B. A, you do something with yourself, or B, you go out and be social in a certain neighborhood. And I'm African American, so high probability that you'll end up dead, or in a gang, or in crime because that's what it was at that time. It's just that's just a situation. Or you're able to challenge those energies and put them toward a use that's productive and positive for yourself, and that's what I did, which is utilizing a way to learn.

+ +

I could always pick up things when I was very young. And a lot of teachers, my younger teachers, were like, "You're very, very bright," or "You're very smart." And there weren't many programs because I'm older than 42. So there weren't as many programs as there are today. So I really like all of the programs. So I want to clarify the context. Today there's a lot more engagement and identification of kids that might be sharper, smarter, whatever their personal issues are, good or bad. And it's a way to sort of separate them. So you're not just teaching the whole group as a whole and putting them all in one basket, but back then, there was not.

+ +

And so I just used to go home a lot, do a lot of reading, do a lot of studying, and just knick-knack with things in tech. And then I just started understanding that even as a young kid in the inner city, you see economics very early, but they don't understand that's really what they're studying. They see economics. They can see inflation because making two ends meet is very difficult. They may see gang violence and drugs or whatever it might end up being. And a lot of that, in my opinion, is always an underlining economic foundation.

+ +

And so people would say, "Oh, why is this industry like this?" And so forth. "Why does this keep happening?" It's because they can't function. And sometimes, it's just them and their family, but they can't function because it's an economic system. So I started focusing on that and then went into the Marine Corps. And then, after the Marine Corps, I went to Europe. I lived in Europe for a while to do my undergrad studies in the Netherlands in Holland.

+ +

VICTORIA: So having that experience of taking a challenge or taking these forces around you and turning into a force for good, that's led you to bring the power of AI to local economics. And is that the direction that you went eventually?

+ +

LEONARD: So economics was always something that I understood and had a fascination prior to even starting my company. I started in 2017. And we're crowdfunding now, and I can get into that later. But I self-funded it since 2017 to...I think I only started crowdfunding when COVID hit, which was 2020, and just to get awareness and people out there because I couldn't go to a lot of events.

+ +

So I'm like, okay, how can I get exposure? But yeah, it was a matter of looking at it from that standpoint of economics always factored into me, even when I was in the military when I was in the Marine Corps. I would see that...we would go to different countries, and you could just see the difference of how they lived and survived.

+ +

And another side note, my son's mother is from Ethiopia, Africa. And I have a good relationship with my son and his mother, even though we've been apart for over 15 years, divorced for over 15 years or so or longer. But trying to keep that, you can just see this dichotomy. You go out to these different countries, and even in the military, it's just so extreme from the U.S. and any part of the U.S, but that then always focused on economics.

+ +

And then technology, I just always kept up with, like, back in the '80s when the mobile brick phone came out, I had to figure out how to get one. [laughs] And then I took it apart and then put it back together just to see how it works, so yeah. But it was a huge one, by the way. I mean, it was like someone got another and broke it, and they thought it was broken. And they're like, "This doesn't work. You could take this piece of junk." I'm like, "Okay." [laughs]

+ +

VICTORIA: Like, oh, great. I sure will, yeah. Now, I love technology. And I think a lot of people perceive artificial intelligence as being this super futuristic, potentially harmful, maybe economic negative impact. So what, from your perspective, can AI do for local economics or for people who may not have access to that advanced technology?

+ +

LEONARD: Well, that's the key, and that's what we're looking to do with AIEDC. When you look at the small and midsize businesses, it's not what people think, or their perception is. A lot of those in the U.S. it's the backbone of the United States, our economy, literally. And in other parts of the world, it's the same where it could be a one or two mom-and-pop shops. That's where that name comes from; it's literally two people.

+ +

And they're trying to start something to build their own life over time because they're using their labor to maybe build wealth or somehow a little bit not. And when I mean wealth, it's always relative. It's enough to sustain themselves or just put food on the table and be able to control their own destiny to the best of their ability.

+ +

And so what we're looking to do is make a mobile app maker that's 5G that lives in the cloud, that's 5G compliant, that will allow small and midsize businesses to create their own iOS or Android mobile app with no-code or low-code, basically like creating an email. That's how simple we want it to be. When you create your own email, whether you use Microsoft, Google, or whatever you do, and you make it that simple. And there's a simple version, and there could be complexity added to it if they want. That would be the back office digitization or customization, but that then gets them on board with digitization.

+ +

It's intriguing that McKinsey just came out with a report stating that in 2023, in order to be economically viable, and this was very recent, that all companies would need to have a digitization strategy. And so when you look at small businesses, and you look at things like COVID-19, or the COVID current ongoing issue and that disruption, this is global. And you look at even the Ukrainian War or the Russian-Ukrainian War, however you term it, invasion, war, special operation, these are disruptions.

+ +

And then, on top of that, we look at climate change which has been accelerating in the last two years more so than it was prior to this that we've experienced. So this is something that everyone can see is self-evident. I'm not even focused on the cause of the problem. My brain and the way I think, and my team, we like to focus on solutions. My chairman is a former program director of NASA who managed 1,200 engineers that built the International Space Station; what was it? 20-30 years ago, however, that is. And he helped lead and build that from Johnson Center.

+ +

And so you're focused on solutions because if you're building the International Space Station, you can only focus on solutions and anticipate the problems but not dwell on them. And so that kind of mindset is what I am, and it's looking to help small businesses do that to get them on board with digitization and then in customization. And then beyond that, use our system, which is called M.I.N.D. So we own these...we own patents, three patents, trademarks, and service marks related to artificial intelligence that are in the field of economics.

+ +

And we will utilize DEVS...we plan to do that which is a suite of system specifications to predict regional economic issues like the weather in a proactive way, not reactive. A lot of economic situations are reactive. It's reactive to the Federal Reserve raising interest rates or lowering rates, Wall Street, you know, moving money or not moving money. It is what it is. I mean, I don't judge it. I think it's like financial engineering, and that's fine. It's profitability.

+ +

But then, at the end of the day, if you're building something, it's like when we're going to go to space. When rockets launch, they have to do what they're intended to do. Like, I know that Blue Origin just blew up recently. Or if they don't, they have a default, and at least I heard that the Blue Origin satellite, if it were carrying passengers, the passengers would have been safe because it disembarked when it detected its own problem.

+ +

So when you anticipate these kinds of problems and you apply them to the local small business person, you can help them forecast and predict better like what weather prediction has done. And we're always improving that collectively for weather prediction, especially with climate change, so that it can get to near real-time as soon as possible or close a window versus two weeks out versus two days out as an example.

+ +

VICTORIA: Right. Those examples of what you call a narrow economic prediction.

+ +

LEONARD: Correct. It is intriguing when you say narrow economic because it wouldn't be narrow AI. But it would actually get into AGI if you added more variables, which we would. The more variables you added in tenancies...so if you're looking at events, the system events discretion so discrete event system specification you would specify what they really, really need to do to have those variables.

+ +

But at some point, you're working on a system, what I would call AGI. But AGI, in my mind, the circles I run in at least or at least most of the scientists I talk to it's not artificial superintelligence. And so the general public thinks AGI...and I've said this to Stephen Ibaraki, who's the founder of AI for Good at Global Summit at the United Nations, and one of his interviews as well. It's just Artificial General Intelligence, I think, has been put out a lot by Hollywood and entertainment and so forth, and some scientists say certain things. We won't be at artificial superintelligence.

+ +

We might get to Artificial General Intelligence by 2030 easily, in my opinion. But that will be narrow AI, but it will cover what we look at it in the field as cross-domain, teaching a system to look at different variables because right now, it's really narrow. Like natural language processing, it's just going to look at language and infer from there, and then you've got backward propagation that's credit assignment and fraud and detection. Those are narrow data points.

+ +

But when you start looking at something cross-domain...who am I thinking of? Pedro Domingos who wrote the Master Algorithm, which actually, Xi Jinping has a copy of, the President of China, on his bookshelf in his office because they've talked about that, and these great minds because Stephen Ibaraki has interviewed these...and the founder of Google Brain and all of these guys.

+ +

And so there's always this debate in the scientific community of what is narrow AI what it's not. But at the end of the day, I just like Pedro's definition of it because he says the master algorithm will be combining all five, so you're really crossing domains, which AI hasn't done that. And to me, that will be AGI, but that's not artificial superintelligence. And artificial superintelligence is when it becomes very, you know, like some of the movies could say, if we as humanity just let it run wild, it could be crazy.

+ +

VICTORIA: One of my questions is the future of AI more like iRobot or Bicentennial Man?

+ +

LEONARD: Well, you know, interesting. That's a great question, Victoria. I see most of AI literally as iRobot, as a tool more than anything, except at the end when it implied...so it kind of did two things in that movie, but a wonderful movie to bring up. And I like Will Smith perfectly. Well, I liked him a lot more before --

+ +

VICTORIA: I think iRobot is really the better movie.

+ +

LEONARD: Yeah, so if people haven't seen iRobot, I liked Will Smith, the actor. But iRobot showed you two things, and it showed you, one, it showed hope. Literally, the robot...because a lot of people put AI and robots. And AI by itself is the brain or the mind; I should say hardware are the robots or the brain. Software...AI in and of itself is software. It's the mind itself. That's why we have M.I.N.D Machine Intelligence NeuralNetwork Database. We literally have that. That's our acronym and our slogan and everything. And it's part of our patents. But its machine intelligence is M.I.N.D, and we own that, you know; the company owns it.

+ +

And so M.I.N.D...we always say AI powered by M.I.N.D. We're talking about that software side of, like, what your mind does; it iterates and thinks, the ability to think itself. Now it's enclosed within a structure called, you know, for the human, it's called a brain, the physical part of it, and that brain is enclosed within the body. So when you look at robots...and my chairman was the key person for robotics for the International Space Station. So when you look at robotics, you are putting that software into hardware, just like your cell phone. You have the physical, and then you have the actual iOS, which is the operating system.

+ +

So when you think about that, yeah, iRobot was good because it showed how these can be tools, and they were very, in the beginning of the movie, very helpful, very beneficial to humanity. But then it went to a darker side and showed where V.I.K.I, which was an acronym as well, I think was Virtual Interactive Kinetic technology of something. Yeah, I believe it was Virtual Interactive Kinetic inference or technology or something like that, V.I.K.I; I forgot the last I. But that's what it stood for.

+ +

It was an acronym to say...and then V.I.K.I just became all aware and started killing everyone with robots and just wanted to say, you know, this is futile. But then, at the very, very end, V.I.K.I learned from itself and says, "Okay, I guess this isn't right." Or the other robot who could think differently argued with V.I.K.I, and they destroyed her. And it made V.I.K.I a woman in the movie, and then the robot was the guy. But that shows that it can get out of hand.

+ +

But it was intriguing to me that they had her contained within one building. This wouldn't be artificial superintelligence. And I think sometimes Hollywood says, "Just take over everything from one building," no. It wouldn't be on earth if it could. But that is something we always have to think about. We have to think about the worst-case scenarios.

+ +

I think every prudent scientist or business person or anyone should do that, even investors, I mean, if you're investing something for the future. But you also don't focus on it. You don't think about the best-case scenario, either. But there's a lot of dwelling on the worst-case scenario versus the good that we can do given we're looking at where humanity is today. I mean, we're in 2022, and we're still fighting wars that we fought in 1914.

+ +

VICTORIA: Right. Which brings me to my next question, which is both, what are the most exciting opportunities to innovate in the AI space currently? And conversely, what are the biggest challenges that are facing innovation in that field?

+ +

LEONARD: Ooh, that's a good question. I think, in my opinion, it's almost the same answer; one is...but I'm in a special field. And I'm surprised there's not a lot of competition for our company. I mean, it's very good for me and the company's sense. It's like when Mark Zuckerberg did Facebook, there was Friendster, and there was Myspace, but they were different. They were different verticals. And I think Mark figured out how to do it horizontally, good or bad. I'm talking about the beginning of when he started Facebook, now called Meta.

+ +

But I'm saying utilizing AI in economics because a lot of times AI is used in FinTech and consumerism, but not economic growth where we're really talking about growing something organically, or it's called endogenous growth. Because I studied Paul Romer's work, who won the Nobel Prize in 2018 for economic science. And he talked about the nature of ideas. And we were working on something like that in Stanford.

+ +

And I put out a book in 2017 of January talking about cryptocurrencies, artificial intelligence but about the utilization of it, but not the speculation. I never talked about speculation. I don't own any crypto; I would not. It's only once it's utilized in its PureTech form will it create something that it was envisioned to do by the protocol that Satoshi Nakamoto sort of created. And it still fascinates me that people follow Bitcoin protocol, even for the tech and the non-tech, but they don't know who Satoshi is.

+ +

But yeah, it's a white paper. You're just following a white paper because I think logically, the world is going towards that iteration of evolution. And that's how AI could be utilized for good in an area to focus on it with economics and solving current problems. And then going forward to build a new economy where it's not debt-based driven or consumer purchase only because that leaves a natural imbalance in the current world structure.

+ +

The western countries are great. We do okay, and we go up and down. But the emerging and developing countries just get stuck, and they seem to go into a circular loop. And then there are wars as a result of these things and territory fights and so forth. So that's an area I think where it could be more advanced is AI in the economic realm, not so much the consumer FinTech room, which is fine.

+ +

But consumer FinTech, in my mind, is you're using AI to process PayPal. That's where I think Elon just iterated later because PayPal is using it for finance. You're just moving things back and forth, and you're just authenticating everything. But then he starts going on to SpaceX next because he's like, well, let me use technology in a different way. And I do think he's using AI on all of his projects now.

+ +

VICTORIA: Right. So how can that tech solve real problems today? Do you see anything even particular about Southern California, where we're both at right now, where you think AI could help predict some outcomes for small businesses or that community?

+ +

LEONARD: I'm looking to do it regionally then globally. So I'm part of this Southern Cal Innovation Hub, which is just AI. It's an artificial intelligence coordination between literally San Diego County, Orange County, and Los Angeles County. And so there's a SoCal Innovation Hub that's kind of bringing it together. But there are all three groups, like; I think the CEO in Orange County is the CEO of Leadership Alliance. And then in San Diego, there's another group I can't remember their name off the top of my head, and I'm talking about the county itself. So each one's representing a county because, you know.

+ +

And then there's one in Northern California that I'm also associated with where if you look at California as its own economy in the U.S., it's still pretty significant as an economic cycle in the United States, period. That's why so many politicians like California because they can sway the votes. So yeah, we're looking to do that once, you know, we are raising capital. We're crowdfunding currently. Our total raise is about 6 million. And so we're talking to venture capitalists, private, high net worth investors as well.

+ +

Our federal funding is smaller. It's just like several hundred thousand because most people can only invest a few thousand. But I always like to try to give back. If you tell people...if you're Steve Jobs, like, okay, I've got this Apple company. In several years, you'll see the potential. And people are like, ah, whatever, but then they kick themselves 15 years later. [laughs] Like, oh, I wish I thought about that Apple stock for $15 when I could. But you give people a chance, and you get the word out, and you see what happens.

+ +

Once you build a system, you share it. There are some open-source projects. But I think the open source, like OpenAI, as an example, Elon Musk funds that as well as Microsoft. They both put a billion dollars into it. It is an open-source project. OpenAI claims...but some of the research does go back to Microsoft to be able to see it. And DeepMind is another research for AI, but they're owned by Google.

+ +

And so, I'm also very focused on democratizing artificial intelligence for the benefit of everyone. I really believe that needs to be democratized in a sense of tying it to economics and making it utilized for everyone that may need it for the benefit of humanity where it's profitable and makes money, but it's not just usurping.

+ +

MID-ROLL AD:

+ +

As life moves online, brick-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: With that democratizing it, is there also a need to increase the understanding of the ethics around it and when there are certain known use cases for AI where it actually is discriminatory and plays to systemic problems in our society? Are you familiar with that as well?

+ +

LEONARD: Yes, absolutely. Well, that's my whole point. And, Victoria, you just hit the nail on the head. Truly democratizing AI in my mind and in my brain the way it works is it has opened up for everyone. Because if you really roll it back, okay, companies now we're learning...we used to call it several years ago UGC, User Generated Content. And now a lot of people are like, okay, if you're on Facebook, you're the product, right? Or if you're on Instagram, you're the product. And they're using you, and you're using your data to sell, et cetera, et cetera.

+ +

But user-generated content it's always been that. It's just a matter of the sharing of the economic. That's why I keep going back to economics. So if people were, you know, you wouldn't have to necessarily do advertising if you had stakeholders with advertising, the users and the company, as an example. If it's a social media company, just throwing it out there, so let's say you have a social media...and this has been talked about, but I'm not the first to introduce this. This has been talked about for over ten years, at least over 15 years.

+ +

And it's you share as a triangle in three ways. So you have the user and everything else. So take your current social media, and I won't pick on Facebook, but I'll just use them, Facebook, Instagram, or Twitter. Twitter's having issues recently because Elon is trying to buy them or get out of buying them. But you just looked at that data, and then you share with the user base. What's the revenue model? And there needs to be one; let me be very clear. There has to be incentive, and there has to be profitability for people that joined you earlier, you know, joined the corporation, or become shareholders, or investors, or become users, or become customers.

+ +

They have to be able to have some benefit, not extreme greater than everyone else but a great benefit from coming in earlier by what they contributed at the time. And that is what makes this system holistic in my opinion, like Reddit or any of these bloggers. But you make it where they use their time and the users, and you share it with the company and then the data and so forth, and whatever revenue economic model you have, and it's a sort of a three-way split. It's just not always equal.

+ +

And that's something that I think in economics, we're still on a zero-sum game, I win, you lose sort of economic model globally. That's why there's a winner of a war and a loser of a war. But in reality, as you know, Victoria, there are no winners of any war. So it's funny, [laughs] I was just saying, well, you know, because of the economic mode, but Von Neumann, who talked about that, also talked about something called a non-zero-sum game when he talked about it in mathematics that you can win, and I can win; we just don't win equally because they never will match that.

+ +

So if I win, I may win 60; you win 40. Or you may win 60, I win 40, and we agree to settle on that. It's an agreement versus I'm just going to be 99, and you'll be 1%, or I'm just going to be 100, and you're at 0. And I think that our economic model tends to be a lot of that, like, when you push forth and there needs to be more of that.

+ +

When you talk about the core of economics...and I go way back, you know, prior to the Federal Reserve even being started. I just look at the world, and it's always sort of been this land territorial issue of what goods are under the country. But we've got technology where we can mitigate a lot of things and do the collective of help the earth, and then let's go off to space, all of space. That's where my brain is focused on.

+ +

VICTORIA: Hmm. Oh yeah, that makes sense to me. I think that we're all going to have to evolve our economic models here in the future. I wonder, too, as you're building your startup and you're building your company, what are some of the technology trade-offs you're having to make in the stack of the AI software that you're building?

+ +

LEONARD: Hmm. Good question. But clarify, this may be a lot deeper dive because that's a general question. And I don't want to...yeah, go ahead.

+ +

VICTORIA: Because when you're building AI, and you're going to be processing a lot of data, I know many data scientists that are familiar with tools like Jupyter Notebooks, and R, and Python. And one issue that I'm aware of is keeping the environments the same, so everything that goes into building your app and having those infrastructure as code for your data science applications, being able to afford to process all that data. [laughs]

+ +

And there are just so many factors that go into building an AI app versus building something that's more easy, like a web-based user form. So just curious if you've encountered those types of trade-offs or questions about, okay, how are we going to actually build an app that we can put out on everybody's phone and that works responsibly?

+ +

LEONARD: Oh, okay. So let me be very clear, but I won't give too much of the secret sauce away. But I can define this technically because this is a technical audience. This is not...so what you're really talking about is two things, and I'm clear about this, though. So the app maker won't really read and write a lot of data. It'll just be the app where people could just get on board digitalization simple, you know, process payments, maybe connect with someone like American Express square, MasterCard, whatever. And so that's just letting them function. That's sort of small FinTech in my mind, you know, just transaction A to B, B to A, et cetera.

+ +

And it doesn't need to be peer-to-peer and all of the crypto. It doesn't even need to go that level yet. That's just level one. Then they will sign up for a service, which is because we're really focused on artificial intelligence as a service. And that, to me, is the next iteration for AI. I've been talking about this for about three or four years now, literally, in different conferences and so forth for people who haven't hit it. But that we will get to that point where AI will become AI as a service, just like SaaS is.

+ +

We're still at the, you know, most of the world on the legacy systems are still software as a service. We're about to hit AI as a service because the world is evolving. And this is true; they did shut it down. But you did have okay, so there are two case points which I can bring up. So JP Morgan did create something called a Coin, and it was using AI. And it was a coin like crypto, coin like a token, but they called it a coin.

+ +

But it could process, I think, something like...I may be off on this, so to the sticklers that will be listening, please, I'm telling you I may be off on the exact quote, but I think it was about...it was something crazy to me, like 200,000 of legal hours and seconds that it could process because it was basically taking the corporate legal structure of JP Morgan, one of the biggest banks. I think they are the biggest bank in the U.S. JPMorgan Chase.

+ +

And they were explaining in 2017 how we created this, and it's going to alleviate this many hours of legal work for the bank. And I think politically; something happened because they just pulled away. I still have the original press release when they put it out, and it was in the media. And then it went away. I mean, no implementation [laughs] because I think there was going to be a big loss of jobs for it. And they basically would have been white-collar legal jobs, most specifically lawyers literally that were working for the bank.

+ +

And when they were talking towards investment, it was a committee. I was at a conference. And I was like, I was fascinated by that. And they were basically using Bitcoin protocol as the tokenization protocol, but they were using AI to process it. And it was basically looking at...because legal contracts are basically...you can teach it with natural language processing and be able to encode and almost output it itself and then be able to speak with each other.

+ +

Another case point was Facebook. They had...what was it? Two AI systems. They began to create their own language. I don't know if you remember that story or heard about it, and Facebook shut it down. And this was more like two years ago, I think, when they were saying Facebook was talking, you know, when they were Facebook, not Meta, so maybe it was three years ago. And they were talking, and they were like, "Oh, Facebook has a language. It's talking to each other." And it created its own little site language because it was two AI bots going back and forth. And then the engineers at Facebook said, "We got to shut this down because this is kind of getting out of the box."

+ +

So when you talk about AI as a service, yes, the good and the bad, and what you take away is AWS, Oracle, Google Cloud they do have services where it doesn't need to cost you as much anymore as it used to in the beginning if you know what you're doing ahead of time. And you're not just running iterations or data processing because you're doing guesswork versus, in my opinion, versus actually knowing exactly specifically what you're looking for and the data set you're looking to get out of it.

+ +

And then you're talking about just basically putting in containers and clustering it because it gets different operations. And so what you're really looking at is something called an N-scale graph data that can process data in maybe sub seconds at that level, excuse me. And one of my advisors is the head of that anyway at AGI laboratory. So he's got an N graph database that can process...when we implement it, we'll be able to process data at the petabyte level at sub-seconds, and it can run on platforms like Azure or AWS, and so forth.

+ +

VICTORIA: Oh, that's interesting. So it sounds like cloud providers are making compute services more affordable. You've got data, the N-scale graph data, that can run more transactions more quickly. And I'm curious if you see any future trends since I know you're a futurist around quantum computing and how that could affect capacity for --

+ +

LEONARD: Oh [laughs] We haven't even gotten there yet. Yes. Well, if you look at N-scale, if you know what you're doing and you know what to look for, then the quantum just starts going across different domains as well but at a higher hit rate. So there's been some quantum computers online. There's been several...well, Google has their quantum computer coming online, and they've been working on it, and Google has enough data, of course, to process. So yeah, they've got that data, lots of data. And quantum needs, you know, if it's going to do something, it needs lots of data.

+ +

But then the inference will still be, I think, quantum is very good at processing large, large, large amounts of data. We can just keep going if you really have a good quantum computer. But it's really narrow. You have to tell it exactly what it wants, and it will do it in what we call...which is great like in P or NP square or P over NP which is you want to do it in polynomial time, not non-polynomial, polynomial time which is...now speaking too fast. Okay, my brain is going faster than my lips. Let me slow it down.

+ +

So when you start thinking about processing, if we as humans, let's say if I was going to process A to Z, and I'm like, okay, here is this equation, if I tell you it takes 1000 years, it's of no use to us, to me and you Victoria because we're living now. Now, the earth may benefit in 1000 years, but it's still of no use. But if I could take this large amount of data and have it process within minutes, you know, worst case hours...but then I'll even go down to seconds or sub-seconds, then that's really a benefit to humanity now, today in present term.

+ +

And so, as a futurist, yes, as the world, we will continue to add data. We're doing it every day, and we already knew this was coming ten years ago, 15 years ago, 20 years ago, even actually in the '50s when we were in the AI winter. We're now in AI summer. In my words, I call it the AI summer. So as you're doing this, that data is going to continue to increase, and quantum will be needed for that. But then the specific need...quantum is very good at looking at a specific issue, specifically for that very narrow.

+ +

Like if you were going to do the trajectory to Jupiter or if we wanted to send a probe to Jupiter or something, I think we're sending something out there now from NASA, and so forth, then you need to process all the variables, but it's got one trajectory. It's going one place only.

+ +

VICTORIA: Gotcha. Well, that's so interesting. I'm glad I asked you that question. And speaking of rockets going off to space, have you ever seen a SpaceX launch from LA?

+ +

LEONARD: Actually, I saw one land but not a launch. I need to go over there. It's not too far from me. But you got to give credit where credit's due and Elon has a reusable rocket. See, that's where technology is solving real-world problems. Because NASA and I have, you know, my chairman, his name is Alexander Nawrocki, you know, he's Ph.D., but I call him Rocki. He goes by Rocki like I go by LS.

+ +

But it's just we talk about this like NASA's budget. [laughs] How can you reduce this? And Elon says they will come up with a reusable rocket that won't cost this much and be able to...and that's the key. That was the kind of Holy Grail where you can reuse the same rocket itself and then add some little variables on top of it. But the core, you wouldn't constantly be paying for it.

+ +

And so I think where the world is going...and let me be clear, Elon pushes a lot out there. He's just very good at it. But I'm also that kind of guy that I know that Tesla itself was started by two Stanford engineers. Elon came on later, like six months, and then he invested, and he became CEO, which was a great investment for Elon Musk.

+ +

And then CEO I just think it just fit his personality because it was something he loved. But I also have studied for years Nikola Tesla, and I understand what his contributions created where we are today with all the patents that he had. And so he's basically the father of WiFi and why we're able to communicate in a lot of this. We've perfected it or improved it, but it was created by him in the 1800s.

+ +

VICTORIA: Right. And I don't think he came from as fortunate a background as Elon Musk, either. Sometimes I wonder what I could have done born in similar circumstances. [laughter] And you certainly have made quite a name for yourself.

+ +

LEONARD: Well, I'm just saying, yeah, he came from very...he did come from a poor area of Russia which is called the Russian territory, to be very honest, Eastern Europe, definitely Eastern Europe. But yeah, I don't know once you start thinking about that [laughs]. You're making me laugh, Victoria. You're making me laugh.

+ +

VICTORIA: No, I actually went camping, a backpacking trip to the Catalina Island, and there happened to be a SpaceX launch that night, and we thought it was aliens because it looked wild. I didn't realize what it was. But then we figured it was a launch, so it was really great. I love being here and being close to some of this technology and the advancements that are going on.

+ +

I'm curious if you have some thoughts about...I hear a lot about or you used to hear about Silicon Valley Tech like very Northern California, San Francisco focus. But what is the difference in SoCal? What do you find in those two communities that makes SoCal special? [laughs]

+ +

LEONARD: Well, I think it's actually...so democratizing AI. I've been in a moment like that because, in 2015, I was in Dubai, and they were talking about creating silicon oasis. And so there's always been this model of, you know, because they were always, you know, the whole Palo Alto thing is people would say it and it is true. I mean, I experienced it. Because I was in a two-year program, post-graduate program executive, but we would go up there...I wasn't living up there. I had to go there maybe once every month for like three weeks, every other month or something.

+ +

But when you're up there, it is the air in the water. It's just like, people just breathe certain things. Because around the world, and I would travel to Japan, and China, and other different parts of Asia, Vietnam, et cetera and in Africa of course, and let's say you see this and people are like, so what is it about Silicon Valley? And of course, the show, there is the Hollywood show about it, which is pretty a lot accurate, which is interesting, the HBO show.

+ +

But you would see that, and you would think, how are they able to just replicate this? And a lot of it is a convergence. By default, they hear about these companies' access because the key is access, and that's what we're...like this podcast. I love the concept around it because giving awareness, knowledge, and access allows other people to spread it and democratize it. So it's just not one physical location, or you have to be in that particular area only to benefit. I mean, you could benefit in that area, or you could benefit from any part of the world.

+ +

But since they started, people would go there; engineers would go there. They built company PCs, et cetera. Now that's starting to spread in other areas like Southern Cal are creating their own innovation hubs to be able to bring all three together. And those three are the engineers and founders, and idea makers and startups. And you then need the expertise. I'm older than 42; I'm not 22. [laughs] So I'm just keeping it 100, keeping it real. So I'm not coming out at 19. I mean, my son's 18. And I'm not coming out, okay, this my new startup, bam, give me a billion dollars, I'm good. And let me just write off the next half.

+ +

But when you look at that, there's that experience because even if you look at Mark Zuckerberg, I always tell people that give credit where credit is due. He brought a senior team with him when he was younger, and he didn't have the experience. And his only job has been Facebook out of college. He's had no other job. And now he's been CEO of a multi-billion dollar corporation; that's a fact. Sometimes it hurts people's feelings. Like, you know what? He's had no other job. Now that can be good and bad, [laughs] but he's had no other jobs.

+ +

And so that's just a credit, like, if you can surround yourself with the right people and be focused on something, it can work to the good or the bad for your own personal success but then having that open architecture. And I think he's been trying to learn and others versus like an Elon Musk, who embraces everything. He's just very open in that sense. But then you have to come from these different backgrounds.

+ +

But let's say Elon Musk, Mark Zuckerberg, let's take a guy like myself or whatever who didn't grow up with all of that who had to make these two ends meet, figure out how to do the next day, not just get to the next year, but get to the next day, get to the next week, get to the next month, then get to the next year. It just gives a different perspective as well. Humanity's always dealing with that.

+ +

Because we had a lot of great engineers back in the early 1900s. They're good or bad, you know, you did have Nikola Tesla. You had Edison. I'm talking about circa around 1907 or 1909, prior to World War I. America had a lot of industries. They were the innovators then, even though there were innovations happening in Europe, and Africa, and China, as well and Asia. But the innovation hub kind of created as the America, quote, unquote, "industrial revolution." And I think we're about to begin a new revolution sort of tech and an industrial revolution that's going to take us to maybe from 20...we're 2022 now, but I'll say it takes us from 2020 to 2040 in my head.

+ +

VICTORIA: So now that communities can really communicate across time zones and locations, maybe the hubs are more about solving specific problems. There are regional issues. That makes a lot more sense.

+ +

LEONARD: Yes. And collaborating together, working together, because scientists, you know, COVID taught us that. People thought you had to be in a certain place, but then a lot of collaboration came out of COVID; even though it was bad globally, even though we're still bad, if people were at home, they start collaborating, and scientists will talk to scientists, you know, businesses, entrepreneurs, and so forth.

+ +

But if Orange County is bringing together the mentors, the venture capital, or at least Southern California innovation and any other place, I want to say that's not just Silicon Valley because Silicon Valley already has it; we know that. And that's that region. It's San Jose all the way up to...I forgot how far north it's past San Francisco, actually. But it's that region of area where they encompass the real valley of Silicon Valley if you're really there. And you talk about these regions.

+ +

Yes, I think we're going to get to a more regional growth area, and then it'll go more micro to actually cities later in the future. But regional growth, I think it's going to be extremely important globally in the very near term. I'm literally saying from tomorrow to the next, maybe ten years, regional will really matter. And then whatever you have can scale globally anyway, like this podcast we're doing. This can be distributed to anyone in the world, and they can listen at ease when they have time.

+ +

VICTORIA: Yeah, I love it. It's both exciting and also intimidating. [laughs] And you mentioned your son a little bit earlier. And I'm curious, as a founder and someone who spent a good amount of time in graduate and Ph.D. programs, if you feel like it's easy to connect with your son and maintain that balance and focusing on your family while you're building a company and investing in yourself very heavily.

+ +

LEONARD: Well, I'm older, [laughs] so it's okay. I mean, I've mentored him, you know. And me and his mom have a relationship that works. I would say we have a better relationship now than when we were together. It is what it is. But we have a communication level. And I think she was just a great person because I never knew my real father, ever. I supposedly met him when I was two or one; I don't know. But I have no memories, no photos, nothing. And that was just the environment I grew up in.

+ +

But with my son, he knows the truth of everything about that. He's actually in college. I don't like to name the school because it's on the East Coast, and it's some Ivy League school; that's what I will say. And he didn't want to stay on the West Coast because I'm in Orange County and his mom's in Orange County. He's like, "I want to get away from both of you people." [laughter] And that's a joke, but he's very independent. He's doing well. When he graduated high school, he graduated with 4.8 honors. He made the valedictorian. He was at a STEM school.

+ +

VICTORIA: Wow.

+ +

LEONARD: And he has a high GPA. He's studying computer science and economics as well at an Ivy League, and he's already made two or three apps at college. And I said, "You're not Mark, so calm down." [laughter] But anyway, that was a recent conversation. I won't go there. But then some people say, "LS, you should be so happy." What is it? The apple doesn't fall far from the tree.

+ +

But this was something he chose around 10 or 11. I'm like, whatever you want to do, you do; I'll support you no matter what. And his mom says, "Oh no, I think you programmed him to be like you." [laughs] I'm like, no, I can't do that. I just told him the truth about life. And he's pretty tall.

+ +

VICTORIA: You must have --

+ +

LEONARD: He played basketball in high school a lot. I'm sorry?

+ +

VICTORIA: I was going to say you must have inspired him.

+ +

LEONARD: Yeah. Well, he's tall. He did emulate me in a lot of ways. I don't know why. I told him just be yourself. But yes, he does tell me I'm an inspiration to that; I think because of all the struggles I've gone through when I was younger. And you're always going through struggles. I mean, it's just who you are. I tell people, you know, you're building a company. You have success. You can see the future, but sometimes people can't see it, [laughs] which I shouldn't really say, but I'm saying anyway because I do that.

+ +

I said this the other night to some friends. I said, "Oh, Jeff Bezo's rocket blew up," going, you know, Blue Origin rocket or something. And then I said Elon will tell Jeff, "Well, you only have one rocket blow up. I had three, [laughter] SpaceX had three." So these are billionaires talking to billionaires about, you know, most people don't even care. You're worth X hundred billion dollars. I mean, they're worth 100 billion-plus, right?

+ +

VICTORIA: Right.

+ +

LEONARD: I think Elon is around 260 billion, and Jeff is 160 or something. Who cares about your rocket blowing up? But it's funny because the issues are still always going to be there. I've learned that. I'm still learning. It doesn't matter how much wealth you have. You just want to create wealth for other people and better their lives. The more you search on bettering lives, you're just going to have to wake up every day, be humble with it, and treat it as a new day and go forward and solve the next crisis or problem because there will be one.

+ +

There is not where there are no problems, is what I'm trying to say, this panacea or a utopia where you personally, like, oh yeah, I have all this wealth and health, and I'm just great. Because Elon has had divorce issues, so did Jeff Bezos. So I told my son a lot about this, like, you never get to this world where it's perfect in your head. You're always going to be doing things.

+ +

VICTORIA: That sounds like an accurate future prediction if I ever heard one. [laughs] Like, there will be problems. No matter where you end up or what you choose to do, you'll still have problems. They'll just be different. [laughs]

+ +

LEONARD: Yeah, and then this is for women and men. It means you don't give up. You just keep hope alive, and you keep going. And I believe personally in God, and I'm a scientist who actually does. But I look at it more in a Godly aspect. But yeah, I just think you just keep going, and you keep building because that's what we do as humanity. It's what we've done. It's why we're here. And we're standing on the shoulders of giants, and I just always considered that from physicists and everyone.

+ +

VICTORIA: Great. And if people are interested in building something with you, you have that opportunity right now to invest via the crowdfunding app, correct?

+ +

LEONARD: Yes, yes, yes. They can do that because the company is still the same company because eventually, we're going to branch out. My complete vision for AIEDC is using artificial intelligence for economic development, and that will spread horizontally, not just vertically. Vertically right now, just focus on just a mobile app maker digitization and get...because there are so many businesses even globally, and I'm not talking only e-commerce.

+ +

So when I say small to midsize business, it can be a service business, car insurance, health insurance, anything. It doesn't have to be selling a particular widget or project, you know, product. And I'm not saying there's nothing wrong with that, you know, interest rates and consumerism. But I'm not thinking about Shopify, and that's fine, but I'm talking about small businesses. And there's the back office which is there are a lot of tools for back offices for small businesses.

+ +

But I'm talking about they create their own mobile app more as a way to communicate with their customers, update them with their customers, and that's key, especially if there are disruptions. So let's say that there have been fires in California. In Mississippi or something, they're out of water. In Texas, last year, they had a winter storm, electricity went out. So all of these things are disruptions. This is just in the U.S.,

+ +

And of course, I won't even talk about Pakistan, what's going on there and the flooding and just all these devastating things, or even in China where there's drought where there are these disruptions, and that's not counting COVID disrupts, the cycle of business. It literally does. And it doesn't bubble up until later when maybe the central banks and governments pay attention to it, just like in Japan when that nuclear, unfortunately, that nuclear meltdown happened because of the earthquake; I think it was 2011.

+ +

And that affected that economy for five years, which is why the government has lower interest rates, negative interest rates, because they have to try to get it back up. But if there are tools and everyone's using more mobile apps and wearables...and we're going to go to the metaverse and all of that. So the internet of things can help communicate that. So when these types of disruptions happen, the flow of business can continue, at least at a smaller level, for an affordable cost for the business. I'm not talking about absorbing costs because that's meaningless to me.

+ +

VICTORIA: Yeah, well, that sounds like a really exciting project. And I'm so grateful to have this time to chat with you today. Is there anything else you want to leave for our listeners?

+ +

LEONARD: If they want to get involved, maybe they can go to our crowdfunding page, or if they've got questions, ask about it and spread the word. Because I think sometimes, you know, they talk about the success of all these companies, but a lot of it starts with the founder...but not a founder. If you're talking about a startup, it starts with the founder.

+ +

But it also stops with the innovators that are around that founder, male or female, whoever they are. And it also starts with their community, building a collective community together. And that's why Silicon Valley is always looked at around the world as this sort of test case of this is how you create something from nothing and make it worth great value in the future. And I think that's starting to really spread around the world, and more people are opening up to this. It's like the crowdfunding concept.

+ +

I think it's a great idea, like more podcasts. I think this is a wonderful idea, podcasts in and of themselves, so people can learn from people versus where in the past you would only see an interview on the business news network, or NBC, or Fortune, or something like that, and that's all you would understand. But this is a way where organically things can grow. I think the growth will continue, and I think the future's bright. We just have to know that it takes work to get there.

+ +

VICTORIA: That's great. Thank you so much for saying that and for sharing your time with us today. I learned a lot myself, and I think our listeners will enjoy it as well.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobot.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Leonard S. Johnson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Leonard S. Johnson is the Founder and CEO of AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses.

+ +

Victoria talks to Leonard about using artificial intelligence for good, bringing the power of AI to local economics, and truly democratizing AI.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Leonard S. Johnson or LS, Founder and CEO AIEDC, a 5G Cloud Mobile App Maker and Service Provider with Machine Learning to help small and midsize businesses create their own iOS and Android mobile apps with no-code or low-code so they can engage and service their customer base, as well as provide front and back office digitization services for small businesses. Leonard, thanks for being with us today.

+ +

LEONARD: Thank you for having me, Victoria.

+ +

VICTORIA: I should say LS, thank you for being with us today.

+ +

LEONARD: It's okay. It's fine.

+ +

VICTORIA: Great. So tell us a little more about AIEDC.

+ +

LEONARD: Well, AIEDC stands for Artificial Intelligence Economic Development Corporation. And the original premise that I founded it for...I founded it after completing my postgraduate work at Stanford, and that was 2016. And it was to use AI for economic development, and therefore use AI for good versus just hearing about artificial intelligence and some of the different movies that either take over the world, and Skynet, and watch data privacy, and these other things which are true, and it's very evident, they exist, and they're out there.

+ +

But at the end of the day, I've always looked at life as a growth strategy and the improvement of what we could do and focusing on what we could do practically. You do it tactically, then you do it strategically over time, and you're able to implement things. That's why I think we keep building collectively as humanity, no matter what part of the world you're in.

+ +

VICTORIA: Right. So you went to Stanford, and you're from South Central LA. And what about that background led you to pursue AI for good in particular?

+ +

LEONARD: So growing up in the inner city of Los Angeles, you know, that South Central area, Compton area, it taught me a lot. And then after that, after I completed high school...and not in South Central because I moved around a lot. I grew up with a single mother, never knew my real father, and then my home life with my single mother wasn't good because of just circumstances all the time.

+ +

And so I just started understanding that even as a young kid, you put your brain...you utilize something because you had two choices. It's very simple or binary, you know, A or B. A, you do something with yourself, or B, you go out and be social in a certain neighborhood. And I'm African American, so high probability that you'll end up dead, or in a gang, or in crime because that's what it was at that time. It's just that's just a situation. Or you're able to challenge those energies and put them toward a use that's productive and positive for yourself, and that's what I did, which is utilizing a way to learn.

+ +

I could always pick up things when I was very young. And a lot of teachers, my younger teachers, were like, "You're very, very bright," or "You're very smart." And there weren't many programs because I'm older than 42. So there weren't as many programs as there are today. So I really like all of the programs. So I want to clarify the context. Today there's a lot more engagement and identification of kids that might be sharper, smarter, whatever their personal issues are, good or bad. And it's a way to sort of separate them. So you're not just teaching the whole group as a whole and putting them all in one basket, but back then, there was not.

+ +

And so I just used to go home a lot, do a lot of reading, do a lot of studying, and just knick-knack with things in tech. And then I just started understanding that even as a young kid in the inner city, you see economics very early, but they don't understand that's really what they're studying. They see economics. They can see inflation because making two ends meet is very difficult. They may see gang violence and drugs or whatever it might end up being. And a lot of that, in my opinion, is always an underlining economic foundation.

+ +

And so people would say, "Oh, why is this industry like this?" And so forth. "Why does this keep happening?" It's because they can't function. And sometimes, it's just them and their family, but they can't function because it's an economic system. So I started focusing on that and then went into the Marine Corps. And then, after the Marine Corps, I went to Europe. I lived in Europe for a while to do my undergrad studies in the Netherlands in Holland.

+ +

VICTORIA: So having that experience of taking a challenge or taking these forces around you and turning into a force for good, that's led you to bring the power of AI to local economics. And is that the direction that you went eventually?

+ +

LEONARD: So economics was always something that I understood and had a fascination prior to even starting my company. I started in 2017. And we're crowdfunding now, and I can get into that later. But I self-funded it since 2017 to...I think I only started crowdfunding when COVID hit, which was 2020, and just to get awareness and people out there because I couldn't go to a lot of events.

+ +

So I'm like, okay, how can I get exposure? But yeah, it was a matter of looking at it from that standpoint of economics always factored into me, even when I was in the military when I was in the Marine Corps. I would see that...we would go to different countries, and you could just see the difference of how they lived and survived.

+ +

And another side note, my son's mother is from Ethiopia, Africa. And I have a good relationship with my son and his mother, even though we've been apart for over 15 years, divorced for over 15 years or so or longer. But trying to keep that, you can just see this dichotomy. You go out to these different countries, and even in the military, it's just so extreme from the U.S. and any part of the U.S, but that then always focused on economics.

+ +

And then technology, I just always kept up with, like, back in the '80s when the mobile brick phone came out, I had to figure out how to get one. [laughs] And then I took it apart and then put it back together just to see how it works, so yeah. But it was a huge one, by the way. I mean, it was like someone got another and broke it, and they thought it was broken. And they're like, "This doesn't work. You could take this piece of junk." I'm like, "Okay." [laughs]

+ +

VICTORIA: Like, oh, great. I sure will, yeah. Now, I love technology. And I think a lot of people perceive artificial intelligence as being this super futuristic, potentially harmful, maybe economic negative impact. So what, from your perspective, can AI do for local economics or for people who may not have access to that advanced technology?

+ +

LEONARD: Well, that's the key, and that's what we're looking to do with AIEDC. When you look at the small and midsize businesses, it's not what people think, or their perception is. A lot of those in the U.S. it's the backbone of the United States, our economy, literally. And in other parts of the world, it's the same where it could be a one or two mom-and-pop shops. That's where that name comes from; it's literally two people.

+ +

And they're trying to start something to build their own life over time because they're using their labor to maybe build wealth or somehow a little bit not. And when I mean wealth, it's always relative. It's enough to sustain themselves or just put food on the table and be able to control their own destiny to the best of their ability.

+ +

And so what we're looking to do is make a mobile app maker that's 5G that lives in the cloud, that's 5G compliant, that will allow small and midsize businesses to create their own iOS or Android mobile app with no-code or low-code, basically like creating an email. That's how simple we want it to be. When you create your own email, whether you use Microsoft, Google, or whatever you do, and you make it that simple. And there's a simple version, and there could be complexity added to it if they want. That would be the back office digitization or customization, but that then gets them on board with digitization.

+ +

It's intriguing that McKinsey just came out with a report stating that in 2023, in order to be economically viable, and this was very recent, that all companies would need to have a digitization strategy. And so when you look at small businesses, and you look at things like COVID-19, or the COVID current ongoing issue and that disruption, this is global. And you look at even the Ukrainian War or the Russian-Ukrainian War, however you term it, invasion, war, special operation, these are disruptions.

+ +

And then, on top of that, we look at climate change which has been accelerating in the last two years more so than it was prior to this that we've experienced. So this is something that everyone can see is self-evident. I'm not even focused on the cause of the problem. My brain and the way I think, and my team, we like to focus on solutions. My chairman is a former program director of NASA who managed 1,200 engineers that built the International Space Station; what was it? 20-30 years ago, however, that is. And he helped lead and build that from Johnson Center.

+ +

And so you're focused on solutions because if you're building the International Space Station, you can only focus on solutions and anticipate the problems but not dwell on them. And so that kind of mindset is what I am, and it's looking to help small businesses do that to get them on board with digitization and then in customization. And then beyond that, use our system, which is called M.I.N.D. So we own these...we own patents, three patents, trademarks, and service marks related to artificial intelligence that are in the field of economics.

+ +

And we will utilize DEVS...we plan to do that which is a suite of system specifications to predict regional economic issues like the weather in a proactive way, not reactive. A lot of economic situations are reactive. It's reactive to the Federal Reserve raising interest rates or lowering rates, Wall Street, you know, moving money or not moving money. It is what it is. I mean, I don't judge it. I think it's like financial engineering, and that's fine. It's profitability.

+ +

But then, at the end of the day, if you're building something, it's like when we're going to go to space. When rockets launch, they have to do what they're intended to do. Like, I know that Blue Origin just blew up recently. Or if they don't, they have a default, and at least I heard that the Blue Origin satellite, if it were carrying passengers, the passengers would have been safe because it disembarked when it detected its own problem.

+ +

So when you anticipate these kinds of problems and you apply them to the local small business person, you can help them forecast and predict better like what weather prediction has done. And we're always improving that collectively for weather prediction, especially with climate change, so that it can get to near real-time as soon as possible or close a window versus two weeks out versus two days out as an example.

+ +

VICTORIA: Right. Those examples of what you call a narrow economic prediction.

+ +

LEONARD: Correct. It is intriguing when you say narrow economic because it wouldn't be narrow AI. But it would actually get into AGI if you added more variables, which we would. The more variables you added in tenancies...so if you're looking at events, the system events discretion so discrete event system specification you would specify what they really, really need to do to have those variables.

+ +

But at some point, you're working on a system, what I would call AGI. But AGI, in my mind, the circles I run in at least or at least most of the scientists I talk to it's not artificial superintelligence. And so the general public thinks AGI...and I've said this to Stephen Ibaraki, who's the founder of AI for Good at Global Summit at the United Nations, and one of his interviews as well. It's just Artificial General Intelligence, I think, has been put out a lot by Hollywood and entertainment and so forth, and some scientists say certain things. We won't be at artificial superintelligence.

+ +

We might get to Artificial General Intelligence by 2030 easily, in my opinion. But that will be narrow AI, but it will cover what we look at it in the field as cross-domain, teaching a system to look at different variables because right now, it's really narrow. Like natural language processing, it's just going to look at language and infer from there, and then you've got backward propagation that's credit assignment and fraud and detection. Those are narrow data points.

+ +

But when you start looking at something cross-domain...who am I thinking of? Pedro Domingos who wrote the Master Algorithm, which actually, Xi Jinping has a copy of, the President of China, on his bookshelf in his office because they've talked about that, and these great minds because Stephen Ibaraki has interviewed these...and the founder of Google Brain and all of these guys.

+ +

And so there's always this debate in the scientific community of what is narrow AI what it's not. But at the end of the day, I just like Pedro's definition of it because he says the master algorithm will be combining all five, so you're really crossing domains, which AI hasn't done that. And to me, that will be AGI, but that's not artificial superintelligence. And artificial superintelligence is when it becomes very, you know, like some of the movies could say, if we as humanity just let it run wild, it could be crazy.

+ +

VICTORIA: One of my questions is the future of AI more like iRobot or Bicentennial Man?

+ +

LEONARD: Well, you know, interesting. That's a great question, Victoria. I see most of AI literally as iRobot, as a tool more than anything, except at the end when it implied...so it kind of did two things in that movie, but a wonderful movie to bring up. And I like Will Smith perfectly. Well, I liked him a lot more before --

+ +

VICTORIA: I think iRobot is really the better movie.

+ +

LEONARD: Yeah, so if people haven't seen iRobot, I liked Will Smith, the actor. But iRobot showed you two things, and it showed you, one, it showed hope. Literally, the robot...because a lot of people put AI and robots. And AI by itself is the brain or the mind; I should say hardware are the robots or the brain. Software...AI in and of itself is software. It's the mind itself. That's why we have M.I.N.D Machine Intelligence NeuralNetwork Database. We literally have that. That's our acronym and our slogan and everything. And it's part of our patents. But its machine intelligence is M.I.N.D, and we own that, you know; the company owns it.

+ +

And so M.I.N.D...we always say AI powered by M.I.N.D. We're talking about that software side of, like, what your mind does; it iterates and thinks, the ability to think itself. Now it's enclosed within a structure called, you know, for the human, it's called a brain, the physical part of it, and that brain is enclosed within the body. So when you look at robots...and my chairman was the key person for robotics for the International Space Station. So when you look at robotics, you are putting that software into hardware, just like your cell phone. You have the physical, and then you have the actual iOS, which is the operating system.

+ +

So when you think about that, yeah, iRobot was good because it showed how these can be tools, and they were very, in the beginning of the movie, very helpful, very beneficial to humanity. But then it went to a darker side and showed where V.I.K.I, which was an acronym as well, I think was Virtual Interactive Kinetic technology of something. Yeah, I believe it was Virtual Interactive Kinetic inference or technology or something like that, V.I.K.I; I forgot the last I. But that's what it stood for.

+ +

It was an acronym to say...and then V.I.K.I just became all aware and started killing everyone with robots and just wanted to say, you know, this is futile. But then, at the very, very end, V.I.K.I learned from itself and says, "Okay, I guess this isn't right." Or the other robot who could think differently argued with V.I.K.I, and they destroyed her. And it made V.I.K.I a woman in the movie, and then the robot was the guy. But that shows that it can get out of hand.

+ +

But it was intriguing to me that they had her contained within one building. This wouldn't be artificial superintelligence. And I think sometimes Hollywood says, "Just take over everything from one building," no. It wouldn't be on earth if it could. But that is something we always have to think about. We have to think about the worst-case scenarios.

+ +

I think every prudent scientist or business person or anyone should do that, even investors, I mean, if you're investing something for the future. But you also don't focus on it. You don't think about the best-case scenario, either. But there's a lot of dwelling on the worst-case scenario versus the good that we can do given we're looking at where humanity is today. I mean, we're in 2022, and we're still fighting wars that we fought in 1914.

+ +

VICTORIA: Right. Which brings me to my next question, which is both, what are the most exciting opportunities to innovate in the AI space currently? And conversely, what are the biggest challenges that are facing innovation in that field?

+ +

LEONARD: Ooh, that's a good question. I think, in my opinion, it's almost the same answer; one is...but I'm in a special field. And I'm surprised there's not a lot of competition for our company. I mean, it's very good for me and the company's sense. It's like when Mark Zuckerberg did Facebook, there was Friendster, and there was Myspace, but they were different. They were different verticals. And I think Mark figured out how to do it horizontally, good or bad. I'm talking about the beginning of when he started Facebook, now called Meta.

+ +

But I'm saying utilizing AI in economics because a lot of times AI is used in FinTech and consumerism, but not economic growth where we're really talking about growing something organically, or it's called endogenous growth. Because I studied Paul Romer's work, who won the Nobel Prize in 2018 for economic science. And he talked about the nature of ideas. And we were working on something like that in Stanford.

+ +

And I put out a book in 2017 of January talking about cryptocurrencies, artificial intelligence but about the utilization of it, but not the speculation. I never talked about speculation. I don't own any crypto; I would not. It's only once it's utilized in its PureTech form will it create something that it was envisioned to do by the protocol that Satoshi Nakamoto sort of created. And it still fascinates me that people follow Bitcoin protocol, even for the tech and the non-tech, but they don't know who Satoshi is.

+ +

But yeah, it's a white paper. You're just following a white paper because I think logically, the world is going towards that iteration of evolution. And that's how AI could be utilized for good in an area to focus on it with economics and solving current problems. And then going forward to build a new economy where it's not debt-based driven or consumer purchase only because that leaves a natural imbalance in the current world structure.

+ +

The western countries are great. We do okay, and we go up and down. But the emerging and developing countries just get stuck, and they seem to go into a circular loop. And then there are wars as a result of these things and territory fights and so forth. So that's an area I think where it could be more advanced is AI in the economic realm, not so much the consumer FinTech room, which is fine.

+ +

But consumer FinTech, in my mind, is you're using AI to process PayPal. That's where I think Elon just iterated later because PayPal is using it for finance. You're just moving things back and forth, and you're just authenticating everything. But then he starts going on to SpaceX next because he's like, well, let me use technology in a different way. And I do think he's using AI on all of his projects now.

+ +

VICTORIA: Right. So how can that tech solve real problems today? Do you see anything even particular about Southern California, where we're both at right now, where you think AI could help predict some outcomes for small businesses or that community?

+ +

LEONARD: I'm looking to do it regionally then globally. So I'm part of this Southern Cal Innovation Hub, which is just AI. It's an artificial intelligence coordination between literally San Diego County, Orange County, and Los Angeles County. And so there's a SoCal Innovation Hub that's kind of bringing it together. But there are all three groups, like; I think the CEO in Orange County is the CEO of Leadership Alliance. And then in San Diego, there's another group I can't remember their name off the top of my head, and I'm talking about the county itself. So each one's representing a county because, you know.

+ +

And then there's one in Northern California that I'm also associated with where if you look at California as its own economy in the U.S., it's still pretty significant as an economic cycle in the United States, period. That's why so many politicians like California because they can sway the votes. So yeah, we're looking to do that once, you know, we are raising capital. We're crowdfunding currently. Our total raise is about 6 million. And so we're talking to venture capitalists, private, high net worth investors as well.

+ +

Our federal funding is smaller. It's just like several hundred thousand because most people can only invest a few thousand. But I always like to try to give back. If you tell people...if you're Steve Jobs, like, okay, I've got this Apple company. In several years, you'll see the potential. And people are like, ah, whatever, but then they kick themselves 15 years later. [laughs] Like, oh, I wish I thought about that Apple stock for $15 when I could. But you give people a chance, and you get the word out, and you see what happens.

+ +

Once you build a system, you share it. There are some open-source projects. But I think the open source, like OpenAI, as an example, Elon Musk funds that as well as Microsoft. They both put a billion dollars into it. It is an open-source project. OpenAI claims...but some of the research does go back to Microsoft to be able to see it. And DeepMind is another research for AI, but they're owned by Google.

+ +

And so, I'm also very focused on democratizing artificial intelligence for the benefit of everyone. I really believe that needs to be democratized in a sense of tying it to economics and making it utilized for everyone that may need it for the benefit of humanity where it's profitable and makes money, but it's not just usurping.

+ +

MID-ROLL AD:

+ +

As life moves online, brick-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: With that democratizing it, is there also a need to increase the understanding of the ethics around it and when there are certain known use cases for AI where it actually is discriminatory and plays to systemic problems in our society? Are you familiar with that as well?

+ +

LEONARD: Yes, absolutely. Well, that's my whole point. And, Victoria, you just hit the nail on the head. Truly democratizing AI in my mind and in my brain the way it works is it has opened up for everyone. Because if you really roll it back, okay, companies now we're learning...we used to call it several years ago UGC, User Generated Content. And now a lot of people are like, okay, if you're on Facebook, you're the product, right? Or if you're on Instagram, you're the product. And they're using you, and you're using your data to sell, et cetera, et cetera.

+ +

But user-generated content it's always been that. It's just a matter of the sharing of the economic. That's why I keep going back to economics. So if people were, you know, you wouldn't have to necessarily do advertising if you had stakeholders with advertising, the users and the company, as an example. If it's a social media company, just throwing it out there, so let's say you have a social media...and this has been talked about, but I'm not the first to introduce this. This has been talked about for over ten years, at least over 15 years.

+ +

And it's you share as a triangle in three ways. So you have the user and everything else. So take your current social media, and I won't pick on Facebook, but I'll just use them, Facebook, Instagram, or Twitter. Twitter's having issues recently because Elon is trying to buy them or get out of buying them. But you just looked at that data, and then you share with the user base. What's the revenue model? And there needs to be one; let me be very clear. There has to be incentive, and there has to be profitability for people that joined you earlier, you know, joined the corporation, or become shareholders, or investors, or become users, or become customers.

+ +

They have to be able to have some benefit, not extreme greater than everyone else but a great benefit from coming in earlier by what they contributed at the time. And that is what makes this system holistic in my opinion, like Reddit or any of these bloggers. But you make it where they use their time and the users, and you share it with the company and then the data and so forth, and whatever revenue economic model you have, and it's a sort of a three-way split. It's just not always equal.

+ +

And that's something that I think in economics, we're still on a zero-sum game, I win, you lose sort of economic model globally. That's why there's a winner of a war and a loser of a war. But in reality, as you know, Victoria, there are no winners of any war. So it's funny, [laughs] I was just saying, well, you know, because of the economic mode, but Von Neumann, who talked about that, also talked about something called a non-zero-sum game when he talked about it in mathematics that you can win, and I can win; we just don't win equally because they never will match that.

+ +

So if I win, I may win 60; you win 40. Or you may win 60, I win 40, and we agree to settle on that. It's an agreement versus I'm just going to be 99, and you'll be 1%, or I'm just going to be 100, and you're at 0. And I think that our economic model tends to be a lot of that, like, when you push forth and there needs to be more of that.

+ +

When you talk about the core of economics...and I go way back, you know, prior to the Federal Reserve even being started. I just look at the world, and it's always sort of been this land territorial issue of what goods are under the country. But we've got technology where we can mitigate a lot of things and do the collective of help the earth, and then let's go off to space, all of space. That's where my brain is focused on.

+ +

VICTORIA: Hmm. Oh yeah, that makes sense to me. I think that we're all going to have to evolve our economic models here in the future. I wonder, too, as you're building your startup and you're building your company, what are some of the technology trade-offs you're having to make in the stack of the AI software that you're building?

+ +

LEONARD: Hmm. Good question. But clarify, this may be a lot deeper dive because that's a general question. And I don't want to...yeah, go ahead.

+ +

VICTORIA: Because when you're building AI, and you're going to be processing a lot of data, I know many data scientists that are familiar with tools like Jupyter Notebooks, and R, and Python. And one issue that I'm aware of is keeping the environments the same, so everything that goes into building your app and having those infrastructure as code for your data science applications, being able to afford to process all that data. [laughs]

+ +

And there are just so many factors that go into building an AI app versus building something that's more easy, like a web-based user form. So just curious if you've encountered those types of trade-offs or questions about, okay, how are we going to actually build an app that we can put out on everybody's phone and that works responsibly?

+ +

LEONARD: Oh, okay. So let me be very clear, but I won't give too much of the secret sauce away. But I can define this technically because this is a technical audience. This is not...so what you're really talking about is two things, and I'm clear about this, though. So the app maker won't really read and write a lot of data. It'll just be the app where people could just get on board digitalization simple, you know, process payments, maybe connect with someone like American Express square, MasterCard, whatever. And so that's just letting them function. That's sort of small FinTech in my mind, you know, just transaction A to B, B to A, et cetera.

+ +

And it doesn't need to be peer-to-peer and all of the crypto. It doesn't even need to go that level yet. That's just level one. Then they will sign up for a service, which is because we're really focused on artificial intelligence as a service. And that, to me, is the next iteration for AI. I've been talking about this for about three or four years now, literally, in different conferences and so forth for people who haven't hit it. But that we will get to that point where AI will become AI as a service, just like SaaS is.

+ +

We're still at the, you know, most of the world on the legacy systems are still software as a service. We're about to hit AI as a service because the world is evolving. And this is true; they did shut it down. But you did have okay, so there are two case points which I can bring up. So JP Morgan did create something called a Coin, and it was using AI. And it was a coin like crypto, coin like a token, but they called it a coin.

+ +

But it could process, I think, something like...I may be off on this, so to the sticklers that will be listening, please, I'm telling you I may be off on the exact quote, but I think it was about...it was something crazy to me, like 200,000 of legal hours and seconds that it could process because it was basically taking the corporate legal structure of JP Morgan, one of the biggest banks. I think they are the biggest bank in the U.S. JPMorgan Chase.

+ +

And they were explaining in 2017 how we created this, and it's going to alleviate this many hours of legal work for the bank. And I think politically; something happened because they just pulled away. I still have the original press release when they put it out, and it was in the media. And then it went away. I mean, no implementation [laughs] because I think there was going to be a big loss of jobs for it. And they basically would have been white-collar legal jobs, most specifically lawyers literally that were working for the bank.

+ +

And when they were talking towards investment, it was a committee. I was at a conference. And I was like, I was fascinated by that. And they were basically using Bitcoin protocol as the tokenization protocol, but they were using AI to process it. And it was basically looking at...because legal contracts are basically...you can teach it with natural language processing and be able to encode and almost output it itself and then be able to speak with each other.

+ +

Another case point was Facebook. They had...what was it? Two AI systems. They began to create their own language. I don't know if you remember that story or heard about it, and Facebook shut it down. And this was more like two years ago, I think, when they were saying Facebook was talking, you know, when they were Facebook, not Meta, so maybe it was three years ago. And they were talking, and they were like, "Oh, Facebook has a language. It's talking to each other." And it created its own little site language because it was two AI bots going back and forth. And then the engineers at Facebook said, "We got to shut this down because this is kind of getting out of the box."

+ +

So when you talk about AI as a service, yes, the good and the bad, and what you take away is AWS, Oracle, Google Cloud they do have services where it doesn't need to cost you as much anymore as it used to in the beginning if you know what you're doing ahead of time. And you're not just running iterations or data processing because you're doing guesswork versus, in my opinion, versus actually knowing exactly specifically what you're looking for and the data set you're looking to get out of it.

+ +

And then you're talking about just basically putting in containers and clustering it because it gets different operations. And so what you're really looking at is something called an N-scale graph data that can process data in maybe sub seconds at that level, excuse me. And one of my advisors is the head of that anyway at AGI laboratory. So he's got an N graph database that can process...when we implement it, we'll be able to process data at the petabyte level at sub-seconds, and it can run on platforms like Azure or AWS, and so forth.

+ +

VICTORIA: Oh, that's interesting. So it sounds like cloud providers are making compute services more affordable. You've got data, the N-scale graph data, that can run more transactions more quickly. And I'm curious if you see any future trends since I know you're a futurist around quantum computing and how that could affect capacity for --

+ +

LEONARD: Oh [laughs] We haven't even gotten there yet. Yes. Well, if you look at N-scale, if you know what you're doing and you know what to look for, then the quantum just starts going across different domains as well but at a higher hit rate. So there's been some quantum computers online. There's been several...well, Google has their quantum computer coming online, and they've been working on it, and Google has enough data, of course, to process. So yeah, they've got that data, lots of data. And quantum needs, you know, if it's going to do something, it needs lots of data.

+ +

But then the inference will still be, I think, quantum is very good at processing large, large, large amounts of data. We can just keep going if you really have a good quantum computer. But it's really narrow. You have to tell it exactly what it wants, and it will do it in what we call...which is great like in P or NP square or P over NP which is you want to do it in polynomial time, not non-polynomial, polynomial time which is...now speaking too fast. Okay, my brain is going faster than my lips. Let me slow it down.

+ +

So when you start thinking about processing, if we as humans, let's say if I was going to process A to Z, and I'm like, okay, here is this equation, if I tell you it takes 1000 years, it's of no use to us, to me and you Victoria because we're living now. Now, the earth may benefit in 1000 years, but it's still of no use. But if I could take this large amount of data and have it process within minutes, you know, worst case hours...but then I'll even go down to seconds or sub-seconds, then that's really a benefit to humanity now, today in present term.

+ +

And so, as a futurist, yes, as the world, we will continue to add data. We're doing it every day, and we already knew this was coming ten years ago, 15 years ago, 20 years ago, even actually in the '50s when we were in the AI winter. We're now in AI summer. In my words, I call it the AI summer. So as you're doing this, that data is going to continue to increase, and quantum will be needed for that. But then the specific need...quantum is very good at looking at a specific issue, specifically for that very narrow.

+ +

Like if you were going to do the trajectory to Jupiter or if we wanted to send a probe to Jupiter or something, I think we're sending something out there now from NASA, and so forth, then you need to process all the variables, but it's got one trajectory. It's going one place only.

+ +

VICTORIA: Gotcha. Well, that's so interesting. I'm glad I asked you that question. And speaking of rockets going off to space, have you ever seen a SpaceX launch from LA?

+ +

LEONARD: Actually, I saw one land but not a launch. I need to go over there. It's not too far from me. But you got to give credit where credit's due and Elon has a reusable rocket. See, that's where technology is solving real-world problems. Because NASA and I have, you know, my chairman, his name is Alexander Nawrocki, you know, he's Ph.D., but I call him Rocki. He goes by Rocki like I go by LS.

+ +

But it's just we talk about this like NASA's budget. [laughs] How can you reduce this? And Elon says they will come up with a reusable rocket that won't cost this much and be able to...and that's the key. That was the kind of Holy Grail where you can reuse the same rocket itself and then add some little variables on top of it. But the core, you wouldn't constantly be paying for it.

+ +

And so I think where the world is going...and let me be clear, Elon pushes a lot out there. He's just very good at it. But I'm also that kind of guy that I know that Tesla itself was started by two Stanford engineers. Elon came on later, like six months, and then he invested, and he became CEO, which was a great investment for Elon Musk.

+ +

And then CEO I just think it just fit his personality because it was something he loved. But I also have studied for years Nikola Tesla, and I understand what his contributions created where we are today with all the patents that he had. And so he's basically the father of WiFi and why we're able to communicate in a lot of this. We've perfected it or improved it, but it was created by him in the 1800s.

+ +

VICTORIA: Right. And I don't think he came from as fortunate a background as Elon Musk, either. Sometimes I wonder what I could have done born in similar circumstances. [laughter] And you certainly have made quite a name for yourself.

+ +

LEONARD: Well, I'm just saying, yeah, he came from very...he did come from a poor area of Russia which is called the Russian territory, to be very honest, Eastern Europe, definitely Eastern Europe. But yeah, I don't know once you start thinking about that [laughs]. You're making me laugh, Victoria. You're making me laugh.

+ +

VICTORIA: No, I actually went camping, a backpacking trip to the Catalina Island, and there happened to be a SpaceX launch that night, and we thought it was aliens because it looked wild. I didn't realize what it was. But then we figured it was a launch, so it was really great. I love being here and being close to some of this technology and the advancements that are going on.

+ +

I'm curious if you have some thoughts about...I hear a lot about or you used to hear about Silicon Valley Tech like very Northern California, San Francisco focus. But what is the difference in SoCal? What do you find in those two communities that makes SoCal special? [laughs]

+ +

LEONARD: Well, I think it's actually...so democratizing AI. I've been in a moment like that because, in 2015, I was in Dubai, and they were talking about creating silicon oasis. And so there's always been this model of, you know, because they were always, you know, the whole Palo Alto thing is people would say it and it is true. I mean, I experienced it. Because I was in a two-year program, post-graduate program executive, but we would go up there...I wasn't living up there. I had to go there maybe once every month for like three weeks, every other month or something.

+ +

But when you're up there, it is the air in the water. It's just like, people just breathe certain things. Because around the world, and I would travel to Japan, and China, and other different parts of Asia, Vietnam, et cetera and in Africa of course, and let's say you see this and people are like, so what is it about Silicon Valley? And of course, the show, there is the Hollywood show about it, which is pretty a lot accurate, which is interesting, the HBO show.

+ +

But you would see that, and you would think, how are they able to just replicate this? And a lot of it is a convergence. By default, they hear about these companies' access because the key is access, and that's what we're...like this podcast. I love the concept around it because giving awareness, knowledge, and access allows other people to spread it and democratize it. So it's just not one physical location, or you have to be in that particular area only to benefit. I mean, you could benefit in that area, or you could benefit from any part of the world.

+ +

But since they started, people would go there; engineers would go there. They built company PCs, et cetera. Now that's starting to spread in other areas like Southern Cal are creating their own innovation hubs to be able to bring all three together. And those three are the engineers and founders, and idea makers and startups. And you then need the expertise. I'm older than 42; I'm not 22. [laughs] So I'm just keeping it 100, keeping it real. So I'm not coming out at 19. I mean, my son's 18. And I'm not coming out, okay, this my new startup, bam, give me a billion dollars, I'm good. And let me just write off the next half.

+ +

But when you look at that, there's that experience because even if you look at Mark Zuckerberg, I always tell people that give credit where credit is due. He brought a senior team with him when he was younger, and he didn't have the experience. And his only job has been Facebook out of college. He's had no other job. And now he's been CEO of a multi-billion dollar corporation; that's a fact. Sometimes it hurts people's feelings. Like, you know what? He's had no other job. Now that can be good and bad, [laughs] but he's had no other jobs.

+ +

And so that's just a credit, like, if you can surround yourself with the right people and be focused on something, it can work to the good or the bad for your own personal success but then having that open architecture. And I think he's been trying to learn and others versus like an Elon Musk, who embraces everything. He's just very open in that sense. But then you have to come from these different backgrounds.

+ +

But let's say Elon Musk, Mark Zuckerberg, let's take a guy like myself or whatever who didn't grow up with all of that who had to make these two ends meet, figure out how to do the next day, not just get to the next year, but get to the next day, get to the next week, get to the next month, then get to the next year. It just gives a different perspective as well. Humanity's always dealing with that.

+ +

Because we had a lot of great engineers back in the early 1900s. They're good or bad, you know, you did have Nikola Tesla. You had Edison. I'm talking about circa around 1907 or 1909, prior to World War I. America had a lot of industries. They were the innovators then, even though there were innovations happening in Europe, and Africa, and China, as well and Asia. But the innovation hub kind of created as the America, quote, unquote, "industrial revolution." And I think we're about to begin a new revolution sort of tech and an industrial revolution that's going to take us to maybe from 20...we're 2022 now, but I'll say it takes us from 2020 to 2040 in my head.

+ +

VICTORIA: So now that communities can really communicate across time zones and locations, maybe the hubs are more about solving specific problems. There are regional issues. That makes a lot more sense.

+ +

LEONARD: Yes. And collaborating together, working together, because scientists, you know, COVID taught us that. People thought you had to be in a certain place, but then a lot of collaboration came out of COVID; even though it was bad globally, even though we're still bad, if people were at home, they start collaborating, and scientists will talk to scientists, you know, businesses, entrepreneurs, and so forth.

+ +

But if Orange County is bringing together the mentors, the venture capital, or at least Southern California innovation and any other place, I want to say that's not just Silicon Valley because Silicon Valley already has it; we know that. And that's that region. It's San Jose all the way up to...I forgot how far north it's past San Francisco, actually. But it's that region of area where they encompass the real valley of Silicon Valley if you're really there. And you talk about these regions.

+ +

Yes, I think we're going to get to a more regional growth area, and then it'll go more micro to actually cities later in the future. But regional growth, I think it's going to be extremely important globally in the very near term. I'm literally saying from tomorrow to the next, maybe ten years, regional will really matter. And then whatever you have can scale globally anyway, like this podcast we're doing. This can be distributed to anyone in the world, and they can listen at ease when they have time.

+ +

VICTORIA: Yeah, I love it. It's both exciting and also intimidating. [laughs] And you mentioned your son a little bit earlier. And I'm curious, as a founder and someone who spent a good amount of time in graduate and Ph.D. programs, if you feel like it's easy to connect with your son and maintain that balance and focusing on your family while you're building a company and investing in yourself very heavily.

+ +

LEONARD: Well, I'm older, [laughs] so it's okay. I mean, I've mentored him, you know. And me and his mom have a relationship that works. I would say we have a better relationship now than when we were together. It is what it is. But we have a communication level. And I think she was just a great person because I never knew my real father, ever. I supposedly met him when I was two or one; I don't know. But I have no memories, no photos, nothing. And that was just the environment I grew up in.

+ +

But with my son, he knows the truth of everything about that. He's actually in college. I don't like to name the school because it's on the East Coast, and it's some Ivy League school; that's what I will say. And he didn't want to stay on the West Coast because I'm in Orange County and his mom's in Orange County. He's like, "I want to get away from both of you people." [laughter] And that's a joke, but he's very independent. He's doing well. When he graduated high school, he graduated with 4.8 honors. He made the valedictorian. He was at a STEM school.

+ +

VICTORIA: Wow.

+ +

LEONARD: And he has a high GPA. He's studying computer science and economics as well at an Ivy League, and he's already made two or three apps at college. And I said, "You're not Mark, so calm down." [laughter] But anyway, that was a recent conversation. I won't go there. But then some people say, "LS, you should be so happy." What is it? The apple doesn't fall far from the tree.

+ +

But this was something he chose around 10 or 11. I'm like, whatever you want to do, you do; I'll support you no matter what. And his mom says, "Oh no, I think you programmed him to be like you." [laughs] I'm like, no, I can't do that. I just told him the truth about life. And he's pretty tall.

+ +

VICTORIA: You must have --

+ +

LEONARD: He played basketball in high school a lot. I'm sorry?

+ +

VICTORIA: I was going to say you must have inspired him.

+ +

LEONARD: Yeah. Well, he's tall. He did emulate me in a lot of ways. I don't know why. I told him just be yourself. But yes, he does tell me I'm an inspiration to that; I think because of all the struggles I've gone through when I was younger. And you're always going through struggles. I mean, it's just who you are. I tell people, you know, you're building a company. You have success. You can see the future, but sometimes people can't see it, [laughs] which I shouldn't really say, but I'm saying anyway because I do that.

+ +

I said this the other night to some friends. I said, "Oh, Jeff Bezo's rocket blew up," going, you know, Blue Origin rocket or something. And then I said Elon will tell Jeff, "Well, you only have one rocket blow up. I had three, [laughter] SpaceX had three." So these are billionaires talking to billionaires about, you know, most people don't even care. You're worth X hundred billion dollars. I mean, they're worth 100 billion-plus, right?

+ +

VICTORIA: Right.

+ +

LEONARD: I think Elon is around 260 billion, and Jeff is 160 or something. Who cares about your rocket blowing up? But it's funny because the issues are still always going to be there. I've learned that. I'm still learning. It doesn't matter how much wealth you have. You just want to create wealth for other people and better their lives. The more you search on bettering lives, you're just going to have to wake up every day, be humble with it, and treat it as a new day and go forward and solve the next crisis or problem because there will be one.

+ +

There is not where there are no problems, is what I'm trying to say, this panacea or a utopia where you personally, like, oh yeah, I have all this wealth and health, and I'm just great. Because Elon has had divorce issues, so did Jeff Bezos. So I told my son a lot about this, like, you never get to this world where it's perfect in your head. You're always going to be doing things.

+ +

VICTORIA: That sounds like an accurate future prediction if I ever heard one. [laughs] Like, there will be problems. No matter where you end up or what you choose to do, you'll still have problems. They'll just be different. [laughs]

+ +

LEONARD: Yeah, and then this is for women and men. It means you don't give up. You just keep hope alive, and you keep going. And I believe personally in God, and I'm a scientist who actually does. But I look at it more in a Godly aspect. But yeah, I just think you just keep going, and you keep building because that's what we do as humanity. It's what we've done. It's why we're here. And we're standing on the shoulders of giants, and I just always considered that from physicists and everyone.

+ +

VICTORIA: Great. And if people are interested in building something with you, you have that opportunity right now to invest via the crowdfunding app, correct?

+ +

LEONARD: Yes, yes, yes. They can do that because the company is still the same company because eventually, we're going to branch out. My complete vision for AIEDC is using artificial intelligence for economic development, and that will spread horizontally, not just vertically. Vertically right now, just focus on just a mobile app maker digitization and get...because there are so many businesses even globally, and I'm not talking only e-commerce.

+ +

So when I say small to midsize business, it can be a service business, car insurance, health insurance, anything. It doesn't have to be selling a particular widget or project, you know, product. And I'm not saying there's nothing wrong with that, you know, interest rates and consumerism. But I'm not thinking about Shopify, and that's fine, but I'm talking about small businesses. And there's the back office which is there are a lot of tools for back offices for small businesses.

+ +

But I'm talking about they create their own mobile app more as a way to communicate with their customers, update them with their customers, and that's key, especially if there are disruptions. So let's say that there have been fires in California. In Mississippi or something, they're out of water. In Texas, last year, they had a winter storm, electricity went out. So all of these things are disruptions. This is just in the U.S.,

+ +

And of course, I won't even talk about Pakistan, what's going on there and the flooding and just all these devastating things, or even in China where there's drought where there are these disruptions, and that's not counting COVID disrupts, the cycle of business. It literally does. And it doesn't bubble up until later when maybe the central banks and governments pay attention to it, just like in Japan when that nuclear, unfortunately, that nuclear meltdown happened because of the earthquake; I think it was 2011.

+ +

And that affected that economy for five years, which is why the government has lower interest rates, negative interest rates, because they have to try to get it back up. But if there are tools and everyone's using more mobile apps and wearables...and we're going to go to the metaverse and all of that. So the internet of things can help communicate that. So when these types of disruptions happen, the flow of business can continue, at least at a smaller level, for an affordable cost for the business. I'm not talking about absorbing costs because that's meaningless to me.

+ +

VICTORIA: Yeah, well, that sounds like a really exciting project. And I'm so grateful to have this time to chat with you today. Is there anything else you want to leave for our listeners?

+ +

LEONARD: If they want to get involved, maybe they can go to our crowdfunding page, or if they've got questions, ask about it and spread the word. Because I think sometimes, you know, they talk about the success of all these companies, but a lot of it starts with the founder...but not a founder. If you're talking about a startup, it starts with the founder.

+ +

But it also stops with the innovators that are around that founder, male or female, whoever they are. And it also starts with their community, building a collective community together. And that's why Silicon Valley is always looked at around the world as this sort of test case of this is how you create something from nothing and make it worth great value in the future. And I think that's starting to really spread around the world, and more people are opening up to this. It's like the crowdfunding concept.

+ +

I think it's a great idea, like more podcasts. I think this is a wonderful idea, podcasts in and of themselves, so people can learn from people versus where in the past you would only see an interview on the business news network, or NBC, or Fortune, or something like that, and that's all you would understand. But this is a way where organically things can grow. I think the growth will continue, and I think the future's bright. We just have to know that it takes work to get there.

+ +

VICTORIA: That's great. Thank you so much for saying that and for sharing your time with us today. I learned a lot myself, and I think our listeners will enjoy it as well.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobot.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Leonard S. Johnson.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+vPxRugq6 + + ]]> + + Victoria Guido + Leonard S. Johnson + + + 447: Gembah with Neil Macqueen + https://podcast.thoughtbot.com/447 + 8205dab5-880f-4cf3-80d3-b87fd44e3e64 + Thu, 03 Nov 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Neil Macqueen is a leading industrial designer with 78 patents to his name, having previously spent ten years at Dyson and is now the Head of Design at Gembah, the world's first global marketplace for product development. + +Chad talks to Neil about being focused on industrial design or actual physical products as opposed to interfaces and digital products, working with designers and developers, and design to manufacture as a process. + 28:57 + no + + + Neil Macqueen is a leading industrial designer with 78 patents to his name, having previously spent ten years at Dyson and is now the Head of Design at Gembah, the world's first global marketplace for product development. +Chad talks to Neil about being focused on industrial design or actual physical products as opposed to interfaces and digital products, working designers and developers, and design to manufacture as a process. +Gembah (https://gembah.com/) +Follow Gembah on Twitter (https://twitter.com/MadeWithGembah), Instagram (https://www.instagram.com/madewithgembah/), Facebook (https://www.facebook.com/MadeWithGembah/), or LinkedIn (https://www.linkedin.com/company/gembah-inc/), or YouTube (https://www.youtube.com/channel/UCfZ77_SRz9Q3-qIjmmY7xGg). +Follow Neil on Twitter (https://twitter.com/neilmacqueen) and LinkedIn (https://www.linkedin.com/in/neilmacqueen/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Neil Macqueen, a leading industrial designer with 78 patents to his name, having previously spent ten years at Dyson and who is now the Head of Design at Gembah, the world's first global marketplace for product development. Neil, thank you so much for joining me. +NEIL: Oh, it's great to be here with you today, Chad. Thank you for having me. +CHAD: One distinction I feel like we always need to make, and this is one of the things we struggle with at thoughtbot; people want to put themselves out in the community and say, "Here's what I do," and people use the word product design. And there's actually a pretty big, you know, some designers are, or product developers are industrial design physical products and others are digital. What do you do at Gembah? +NEIL: For me, myself, what I do at Gembah explicitly is far more focused around industrial design or actual physical products as opposed to interfaces and digital products. +CHAD: And as the world's, you know, the self-described first global marketplace for product development, what does that actually mean? +NEIL: What it means is that Gembah provides a platform in which anybody with an idea or an aspiration to even have an idea has a single source by which you can tap into all the resources you need to get your product to market. So I think a good metaphor for it would be that it's very easy for myself, yourself, any of the listeners today to become a seller. Like, I can set myself up with an eBay or an Amazon account this afternoon and start selling a product. There are very low barriers to doing that. +Whereas if you want to become a product creator, that is a very disjointed process. And what you'll see from large companies like my experience at Dyson and other companies is that they have a vertically integrated business. They own each part of that product creation, development, engineering, production, logistics. It is all very integrated. And what we try and do and provide to creators is that single integrated structure by which you can have an idea, work with a designer, develop that in conjunction with a manufacturer, and then very seamlessly move over into your production and logistics. +CHAD: You mentioned Dyson, and you spent ten years there and moved through various design roles. I definitely want to touch on that in a little bit. But what attracted you to Gembah? +NEIL: I think, as with all people who are interested in ideas, whether digital or physical, it's the process of creating something that really attracted me, has attracted me to all my roles in the past, and certainly to Gembah. In as much as what I just described previously, it is a world first, like, it is a category-defining company. +So I think what really attracted me to Gembah was the fact that what we're doing here is not only building lots of very interesting products and helping entrepreneurs, and product creators, and businesses, but what we're doing is developing a platform which is entirely unique and one of its kind. +CHAD: I have to admit, I did a little bit of research on you, as I always do. And I looked at your Twitter, and I saw that a lot of your tweets were, I think, back from 2016, where you yourself designed...how would you describe it? A coffee press stand? +NEIL: Exactly. And AeroPress stand. +CHAD: Having been through that process and launching it on Kickstarter, is that part of what...you said I want to help other people do this. +NEIL: Absolutely. And it is probably a very congregating experience in terms of people who go through crowdfunding campaigns and then try and do it yourself. And certainly, my experience, you know, Kickstarter is a wonderful platform. But everything thereafter for me as a creator doing something in my spare time and my evenings outside of my normal nine to five was incredibly challenging, you know, dealing with factories who had very broken English or really struggled to communicate both my idea and their complications accurately. And just how that unfolded into trying to get a product to market without somebody to help and guide me through that process, doing it entirely by yourself. +So I think that was certainly a very challenging experience in terms of getting that coffee stand to market. And I think the same is true for lots of first-time creators and even businesses in trying to reduce costs, up efficiency of getting to market quickly. Like, who are the partners and people that you can work with and businesses you can partner with to help provide you with those benefits? And that's really what we try and provide at Gembah. And I think, as you mentioned at the start, certainly my past experiences make me think that what we're building here today certainly does bring a lot of benefit. +CHAD: I've had quite a few people on the show who launched physical products themselves on Kickstarter or other crowdfunding platforms. And often, the conversation turns to how difficult it actually was from a supply chain perspective from a manufacturing perspective. +One of the things that struck me about Gembah is that it is not a small operation. It has headquarters in the U.S, but team members live and work all over the world. Their website says there are 150-plus team members globally, so given that reach, it seems like it probably can be really helpful to people solving those challenges. I'm curious who the ideal customers of Gembah are. What is the profile of someone who works with Gembah? +NEIL: For our ideal client at the moment, I think that's one topic, and we can go into that. But what we're really trying to do in terms of the company vision is to democratize the design process and creating a product that gets to market. So as much as for us as a company, you know, having gone through a series A funding round and heading towards a series B, yes, we have got a fairly focused view of who is our ideal client profile and persona. +However, what we're really aiming towards is providing this vertically integrated system of design and marketplace resources to absolutely everybody. That is the vision, the vision that anybody can become a product creator for the first time. In as much as, like my metaphor said earlier, you can become a seller on eBay, you should be able to have as easy access to the resources that enable that product creation. +CHAD: So there's an example I always like to use; it has legs a little bit, which is thoughtbot is a well-respected design and development company. And there's an opportunity, you know, we're working designers and developers. And as people who do this work, we often either buy products and see how they could be improved or have ideas for our own, whether it be notepads, or pens, or even mechanical keyboards are a really interesting thing. If we wanted to pursue something like that, how might we do that? +NEIL: In the context of Gembah? +CHAD: Yeah, or beyond. But yes. +NEIL: So I think the first thing for anybody with an idea is to really have some very clear goals at the outset in terms of...and for anybody who is interested in user-centered design, three of the guiding principles for that are three things I always really lean on which is feasibility, viability, and desirability. So within all of those things, what are your ambitions for your product? In terms of ideally, every product should be desirable; people should want to buy it. +Have you got the means by which to get it to market? And once you've got it there, will it provide you enough of a margin to have a sustainable business? So the viability of the product. And can you actually make it? You know, it's not made out of unobtainium, or it [laughter] might be. +So I think a very easy starting point for absolutely everybody is to really go via those three guiding principles in terms of the desirability, viability, and feasibility of your idea. Where do you think you score on that matrix? And then if you think you really have got something in terms of an idea that really has merit and that you have the wherewithal that you want to see it through to fruition, certainly just picking up the phone and calling Gembah, that's a great second step. +CHAD: Okay. So at Gembah, if someone picks up the phone before going through those three steps and is talking to you, do you help them take a step back and answer those three questions? +NEIL: Absolutely. So I think what we really try and do is not only facilitate your product development journey. We're not a service provider; we're a service facilitator. We want to connect you with all of the resources within our platform and marketplace. And what we really try and steer towards is what is the product development journey that best suits your needs. And I think, typically speaking, if we were to use a broad brush, it falls into three camps which is, do you want to speed to market? And the fact you want to sell an idea very quickly. +So, could you potentially white-label your product? So we provide these options to people. So there's a white labeling route. There's then a customized route which is to say, is there something fairly similar already commercially available in the market and that factories provide, and that you could adjust the feature set for your idea by perhaps 10%? That would actually then mean that you could get your idea customized in the factory and into market. So that's the customized route. +Versus then an entirely unique product which is to say that you need to both develop the design and tooling for the product from the ground up. Intuitively, I would hope from white labeling all the way through to unique product development; you have a fairly matched scale of time and cost. The more involved, the more detail, the more unique, the more time, and the more cost proportionally increases. +CHAD: How would you say that designing within a company like Dyson is different than being outside? +NEIL: The thing that working for a company like Dyson and others like it really affords you is the freedom to research without the means of having to really focus on what is my next launch in a year's time. And what I mean by that is Dyson and other large, successful companies have exclusive product development innovation hubs and idea teams who, for every 100 products they develop, potentially only get one through to market and into the global markets. +So I think as a designer, what you're really afforded there is the space and creativity to explore lots of ideas without the pressure of I have to have something out in this next six-month period into the market. I think that's very different to a small to medium-sized enterprise who have a set product line, and this may be your only product line. +Like, you really need to be laser-focused in what is my incremental product development here so that I can maintain the attention of the public? As well as then trying to work concurrently on how do I evolve my product line to then broaden out my audience? So I think that's quite different in terms you have to be very focused. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +CHAD: You started at Dyson as a design engineer, and you moved through up into a senior design engineer, then concept lead, to design manager of new product innovation. What was the journey from design engineer to eventually design manager? And what are the differences between those roles? +NEIL: I think the key thing that changes within those roles is the level of autonomy and responsibility. And I think what scales up through each of those rungs is essentially how you can demonstrate competency for your core responsibility set. So as a design engineer, you're responsible for part-level designs like, here is, you know, you mentioned the mechanical keyboard earlier in the conversation. In that scenario, you would have a team of potentially four design engineers seeing that through to fruition. You would have a subset of those parts which you're exclusively responsible for. +CHAD: So you might just be responsible for designing the best keycaps. +NEIL: Exactly, exactly. So one chap will be just looking at the springs, and the tension, and how do they feel. Another one will be looking at the structural integrity; another one will be looking at the ergonomics. So I think you have the individual part and function. And what then levels up from that is as you go then into an advanced design engineer or a senior engineer is that you begin being responsible for the full assembly. So instead of having your keycap, you're now responsible for leading the whole team doing the whole keyboard. +And then as you then progress through that, having demonstrated competency and reliability of delivering things, you then become a concept lead, which is to say that you have multiple projects on at the same time. You're leading the teams to do that. And then as you progress through that into design and management role, you then level that up again in terms of you're typically managing portfolios of projects within different market sectors. +So I think if that answers your question directly enough, what it really builds on is for anyone aspiring, is you really need to focus on the basics first, like making sure that you are fundamentally a good designer and a good engineer who can demonstrate and communicate your logic and your thought process. And I think if you already underpin yourself with those sorts of fundamental competencies, that serves you really well as you move up through the ranks. +CHAD: Some people I talk with, as they move up through those ranks, they feel like they are getting further and further away from what they actually love to do, which was design products. Is that something that you felt, or how did you not feel that? +NEIL: I think as you move up through the management hierarchy, at the same time, typically the people that do that, I find and who are successful at it have a fairly focused view of what are their goals, what are they trying to achieve, and what is almost their trademark that they're known for. So for myself, how I've avoided that is...you asked me why I'm interested in Gembah, and that's because what I have very instinctively done both at Dyson and here is make sure that I've positioned myself to solve real problems. Probably everybody in a senior management position sometimes still misses getting on CAD or coding and just having the afternoon with no meetings. [laughs] +CHAD: Yeah. +NEIL: I think there's an element of that that you can't get away from. However, what really enthuses and keeps me really engaged and motivated in what I am doing now is to say I'm still solving problems, which is the fundamental heart of everything. So instead of designing the best keyboard for somebody who has carpal syndrome or hand problems, what we're now designing and developing is a platform that solves problems for a whole very broad user base. +As long as you are always focused in your role in terms of how can I best serve and provide solutions to problems, I think what people will find is that you're actually always very fulfilled as a creator, maybe not as a mechanical engineer or electrical engineer, depending on your background, or a coder. But if you're fundamentally interested in solving problems and bringing solutions, you can still hold on to that very tightly. +CHAD: Yeah. As head of design now, what does your day-to-day look like? +NEIL: The majority of what it looks like is what I almost just mentioned with regards to how are we both developing and sustaining a business that provides and develops better solutions for our clientele as well as then dipping in and out of projects which require support and a little bit of extra attention? As I mentioned, as a design manager at Dyson, looking across portfolios of projects. +My role now is really around making sure that all of our category leads, who are people looking after multiple projects that they, all have the support and tools that they need and require, as well as, as I mentioned, in particular cases, giving attention to some design projects that need help. And then roadmapping out, like, what is the future? What are the next incremental steps of functionality and platform features that we want to develop as a company and facilitate and bring to market for our customers? +CHAD: What are some of those things that you're seeing across the portfolio that are needs that you're hoping to meet? +NEIL: I think a very interesting new thing that we're bringing to market at the moment is what we call design to manufacture as a process. And what we really try and do there is we see in the market at the moment that people have a real sensitivity around cost-effectiveness with the global economies where they're at and supply chain. Like, how do I, number one, potentially diversify my supply chain? Or number two, how do I actually launch a new product with as little cost to myself as a business as possible? +And what we do there is a report, a product opportunity report that profiles you as a business and a brand, and then overlaps that almost in a Venn diagram of where's the sweet spot in terms of available products in the markets that you could customize that would really suit your brand and that we could really effectively customize, and develop with a manufacturer and with a design team and get to market really quick, really cheap, but is still uniquely your own and has your special touch to it? +CHAD: Obviously, a thing that has happened in this market or this industry over the last decade or so is crowdfunding and Kickstarter specifically. How have you seen that change things for people? +NEIL: I think what it's meant is people get access to funds in a way that would have taken a very long time previously. And I think the other thing is people get feedback on ideas quite quickly as well, which maybe isn't the case across the broad spectrum. But for people who have an idea and want to very quickly test it with the markets in terms of does, this resonate with my user groups that I'm interested in? Like, is this a real set of user problems which I believe I've solved? Is that actually true? +I think what it's provided product, you know, industrial design is typically, or any other type of product creator is this very quick access to people with capital who can invest and seeing their products through to fruition, which otherwise was actually a really hard and arduous task, not only getting feedback but then trying to raise capital separately. +CHAD: In your opinion, what's the ideal point that something actually goes to crowdfunding? +NEIL: The ideal timing for your crowdfunding campaign is where you have the first iterations of a working and demonstrated functional prototype where it's not just all idea but that you can demonstrate the fact that you're committed to this, that you can demonstrate the functionality of it, and show that you've considered how it's going to be made and that it's not actually going to change massively. Because I think what you can sometimes see is people can go to Kickstarter prematurely. And then when they're actually getting into the manufacturer of the product, there are some fairly large compromises that need to be made or the fact that the idea isn't feasible and they can't make it. +The ideal time to go to a Kickstarter is where you've already thought through all your user scenarios. You've got a very clear perspective on what the problem set is that you're solving and that you can then demonstrate that with a working prototype. And that doesn't need to be pretty or visually pleasing because you can have your beautiful render next to your functional prototype. I think that's a great time. +CHAD: And concrete information on the feasibility of manufacturing it. +NEIL: Absolutely. So I think in part of informing your working prototype, I think you need to have early what you'd call DFM, design for manufacture feedback which is where you've spoken to a manufacturer or a tooling engineer and said, "What are the key considerations I should take into building this assembly?" And often is, the case for people who perhaps haven't gone down that road very, very far is that there are some fairly significant adjustments that you need to make to either the visuals or the functionality of your design. At least having a few initial conversations with those factories very clearly integrated into your product considerations is really, really critical. +CHAD: So I have to ask, is there something that you're personally pursuing now and working on? +NEIL: At the moment, not via Kickstarter. I think the thing actually I'm doing in my spare time is a bit of a passion project with regards to furniture. I think certainly, from my perspective, every designer can pay homage to architecture as the mother of all design. What more is an in-depth user experience and journey than the spaces we're all sitting in every day? And a big part of that is furniture. So I'm designing an armchair in my spare time. This is a way to, [laughs] as you mentioned earlier, with my current role as how it is just making sure I keep sharp my sketching skills and design skills, even if it's just for myself. +CHAD: What does that look like for you? Is it sketching on paper now? And how far do you think you'll take it? +NEIL: At the moment, it's just sketching on paper and asking my kids which ones they like, they dislike. [laughter] And I think, thankfully, with the abilities I've developed and some of the resources I have access to, we'll probably build a functioning prototype just so I can have a nice new armchair in the kitchen. +CHAD: Does that mean creating it yourself, or what does that look like? +NEIL: Again, I can only speak for myself. But being a creator and having come from my past, as we mentioned at Dyson, I think my true passion is creation, so keeping my hands very familiar with materials and screwing things together. So I think what that will look like for me is actually just getting all the raw materials myself within the woodwork, the metalwork, and doing all that work myself. I haven't got much of a passion yet for upholstery, so I'll probably outsource that part. There's something really rewarding in physically making something with your hands which I've never let go of, and I think I'll always enjoy. +CHAD: That's great. I want to come back, as we wrap up, to those three pillars that you outlined, which I thought were really great. What does someone do who's really passionate about the idea that they have, but they hit roadblocks on one or more of those pillars? +NEIL: Hmm, if somebody wants to start just themselves and you have an idea, and you don't want to necessarily engage with a company or service providers yet, I think what you can really do and start with is engaging with groups and doing research yourself so around desirability and feasibility. There is a world of products and reviews out there. There are a lot of resources there. So what I would encourage if somebody has said...you know, let's use your keyboard example again. +CHAD: Yep. +NEIL: What are the best-selling keyboards out there? And is there a silver lining in between all of them in terms of what makes them sell so well? Is it their functionality? Is it their design? Is it the ergonomics? So I think people can really do a lot of research around what develops and constitutes a really desirable product. As well as then in terms of the feasibility, like, are the things you're putting together can you find them freely on, say, a website like Alibaba? Or can you fundamentally make a keyboard out of wood at scale? Again, there are a lot of resources online that you can do for yourself. +And then around viability in terms of, like, what would your margins have to be? Again, I think there's quite a lot you can do there with yourself with regards to what is available on the market today? What are their unique selling points? What are their suggested selling prices? And where do you think you could competitively position yourself? +Typically, how I find that works out is a matrix of ideas. And I think people really need to not be precious about the one idea they have but really be adventurous around, like, what are all the ways that I could potentially solve for this problem set? And then just market against that matrix of desirability, feasibility, and viability and see which one is enough of all of those that actually gives you your best shot at success? +I think, typically, you see a lot of creators who are very precious about an idea. And actually, maybe, again, it's entirely machined out of aluminum. Well, you know, you're really going to struggle to make that at a competitive price. +CHAD: Right. You're not necessarily Apple. [laughs] +NEIL: Exactly. You haven't got that economy of scale available to you. [laughs] So I think having a very clear goal in terms of, like, where do I think I can position this in the market? Do I think people will like it? And could I make it for that much? +CHAD: Yeah, I think that that's true across the entire spectrum of digital and physical product design and development. We work with a lot of founders who have an idea. And compromise problem-solving through the many challenges that you face is critical. And if you're not able to do that, it's very difficult to actually get a product to market in any reasonable time frame or financial sustainability. +NEIL: I completely agree. +CHAD: Well, I really appreciate you stopping by the show and sharing with us, Neil. +NEIL: Thank you so much for having me today. It's been a great conversation, and I've really enjoyed it. +CHAD: If folks want to get in touch with you, or follow along, or learn more about Gembah or anything else, where are all the different places that they can do that? +NEIL: So you can certainly find and connect with me on LinkedIn if anyone would like to follow up with me personally. And if you're really serious about getting a product to market and engaging around that process, you can just look us up at gembah.com. +CHAD: And I can also personally say if you like looking at pretty things for inspiration, Neil's Instagram is also pretty good for that. [laughter] +You can subscribe to the show and find notes for everything that we just mentioned, along with links and a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Neil Macqueen. + + + Neil Macqueen is a leading industrial designer with 78 patents to his name, having previously spent ten years at Dyson and is now the Head of Design at Gembah, the world's first global marketplace for product development.

+ +

Chad talks to Neil about being focused on industrial design or actual physical products as opposed to interfaces and digital products, working designers and developers, and design to manufacture as a process.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Neil Macqueen, a leading industrial designer with 78 patents to his name, having previously spent ten years at Dyson and who is now the Head of Design at Gembah, the world's first global marketplace for product development. Neil, thank you so much for joining me.

+ +

NEIL: Oh, it's great to be here with you today, Chad. Thank you for having me.

+ +

CHAD: One distinction I feel like we always need to make, and this is one of the things we struggle with at thoughtbot; people want to put themselves out in the community and say, "Here's what I do," and people use the word product design. And there's actually a pretty big, you know, some designers are, or product developers are industrial design physical products and others are digital. What do you do at Gembah?

+ +

NEIL: For me, myself, what I do at Gembah explicitly is far more focused around industrial design or actual physical products as opposed to interfaces and digital products.

+ +

CHAD: And as the world's, you know, the self-described first global marketplace for product development, what does that actually mean?

+ +

NEIL: What it means is that Gembah provides a platform in which anybody with an idea or an aspiration to even have an idea has a single source by which you can tap into all the resources you need to get your product to market. So I think a good metaphor for it would be that it's very easy for myself, yourself, any of the listeners today to become a seller. Like, I can set myself up with an eBay or an Amazon account this afternoon and start selling a product. There are very low barriers to doing that.

+ +

Whereas if you want to become a product creator, that is a very disjointed process. And what you'll see from large companies like my experience at Dyson and other companies is that they have a vertically integrated business. They own each part of that product creation, development, engineering, production, logistics. It is all very integrated. And what we try and do and provide to creators is that single integrated structure by which you can have an idea, work with a designer, develop that in conjunction with a manufacturer, and then very seamlessly move over into your production and logistics.

+ +

CHAD: You mentioned Dyson, and you spent ten years there and moved through various design roles. I definitely want to touch on that in a little bit. But what attracted you to Gembah?

+ +

NEIL: I think, as with all people who are interested in ideas, whether digital or physical, it's the process of creating something that really attracted me, has attracted me to all my roles in the past, and certainly to Gembah. In as much as what I just described previously, it is a world first, like, it is a category-defining company.

+ +

So I think what really attracted me to Gembah was the fact that what we're doing here is not only building lots of very interesting products and helping entrepreneurs, and product creators, and businesses, but what we're doing is developing a platform which is entirely unique and one of its kind.

+ +

CHAD: I have to admit, I did a little bit of research on you, as I always do. And I looked at your Twitter, and I saw that a lot of your tweets were, I think, back from 2016, where you yourself designed...how would you describe it? A coffee press stand?

+ +

NEIL: Exactly. And AeroPress stand.

+ +

CHAD: Having been through that process and launching it on Kickstarter, is that part of what...you said I want to help other people do this.

+ +

NEIL: Absolutely. And it is probably a very congregating experience in terms of people who go through crowdfunding campaigns and then try and do it yourself. And certainly, my experience, you know, Kickstarter is a wonderful platform. But everything thereafter for me as a creator doing something in my spare time and my evenings outside of my normal nine to five was incredibly challenging, you know, dealing with factories who had very broken English or really struggled to communicate both my idea and their complications accurately. And just how that unfolded into trying to get a product to market without somebody to help and guide me through that process, doing it entirely by yourself.

+ +

So I think that was certainly a very challenging experience in terms of getting that coffee stand to market. And I think the same is true for lots of first-time creators and even businesses in trying to reduce costs, up efficiency of getting to market quickly. Like, who are the partners and people that you can work with and businesses you can partner with to help provide you with those benefits? And that's really what we try and provide at Gembah. And I think, as you mentioned at the start, certainly my past experiences make me think that what we're building here today certainly does bring a lot of benefit.

+ +

CHAD: I've had quite a few people on the show who launched physical products themselves on Kickstarter or other crowdfunding platforms. And often, the conversation turns to how difficult it actually was from a supply chain perspective from a manufacturing perspective.

+ +

One of the things that struck me about Gembah is that it is not a small operation. It has headquarters in the U.S, but team members live and work all over the world. Their website says there are 150-plus team members globally, so given that reach, it seems like it probably can be really helpful to people solving those challenges. I'm curious who the ideal customers of Gembah are. What is the profile of someone who works with Gembah?

+ +

NEIL: For our ideal client at the moment, I think that's one topic, and we can go into that. But what we're really trying to do in terms of the company vision is to democratize the design process and creating a product that gets to market. So as much as for us as a company, you know, having gone through a series A funding round and heading towards a series B, yes, we have got a fairly focused view of who is our ideal client profile and persona.

+ +

However, what we're really aiming towards is providing this vertically integrated system of design and marketplace resources to absolutely everybody. That is the vision, the vision that anybody can become a product creator for the first time. In as much as, like my metaphor said earlier, you can become a seller on eBay, you should be able to have as easy access to the resources that enable that product creation.

+ +

CHAD: So there's an example I always like to use; it has legs a little bit, which is thoughtbot is a well-respected design and development company. And there's an opportunity, you know, we're working designers and developers. And as people who do this work, we often either buy products and see how they could be improved or have ideas for our own, whether it be notepads, or pens, or even mechanical keyboards are a really interesting thing. If we wanted to pursue something like that, how might we do that?

+ +

NEIL: In the context of Gembah?

+ +

CHAD: Yeah, or beyond. But yes.

+ +

NEIL: So I think the first thing for anybody with an idea is to really have some very clear goals at the outset in terms of...and for anybody who is interested in user-centered design, three of the guiding principles for that are three things I always really lean on which is feasibility, viability, and desirability. So within all of those things, what are your ambitions for your product? In terms of ideally, every product should be desirable; people should want to buy it.

+ +

Have you got the means by which to get it to market? And once you've got it there, will it provide you enough of a margin to have a sustainable business? So the viability of the product. And can you actually make it? You know, it's not made out of unobtainium, or it [laughter] might be.

+ +

So I think a very easy starting point for absolutely everybody is to really go via those three guiding principles in terms of the desirability, viability, and feasibility of your idea. Where do you think you score on that matrix? And then if you think you really have got something in terms of an idea that really has merit and that you have the wherewithal that you want to see it through to fruition, certainly just picking up the phone and calling Gembah, that's a great second step.

+ +

CHAD: Okay. So at Gembah, if someone picks up the phone before going through those three steps and is talking to you, do you help them take a step back and answer those three questions?

+ +

NEIL: Absolutely. So I think what we really try and do is not only facilitate your product development journey. We're not a service provider; we're a service facilitator. We want to connect you with all of the resources within our platform and marketplace. And what we really try and steer towards is what is the product development journey that best suits your needs. And I think, typically speaking, if we were to use a broad brush, it falls into three camps which is, do you want to speed to market? And the fact you want to sell an idea very quickly.

+ +

So, could you potentially white-label your product? So we provide these options to people. So there's a white labeling route. There's then a customized route which is to say, is there something fairly similar already commercially available in the market and that factories provide, and that you could adjust the feature set for your idea by perhaps 10%? That would actually then mean that you could get your idea customized in the factory and into market. So that's the customized route.

+ +

Versus then an entirely unique product which is to say that you need to both develop the design and tooling for the product from the ground up. Intuitively, I would hope from white labeling all the way through to unique product development; you have a fairly matched scale of time and cost. The more involved, the more detail, the more unique, the more time, and the more cost proportionally increases.

+ +

CHAD: How would you say that designing within a company like Dyson is different than being outside?

+ +

NEIL: The thing that working for a company like Dyson and others like it really affords you is the freedom to research without the means of having to really focus on what is my next launch in a year's time. And what I mean by that is Dyson and other large, successful companies have exclusive product development innovation hubs and idea teams who, for every 100 products they develop, potentially only get one through to market and into the global markets.

+ +

So I think as a designer, what you're really afforded there is the space and creativity to explore lots of ideas without the pressure of I have to have something out in this next six-month period into the market. I think that's very different to a small to medium-sized enterprise who have a set product line, and this may be your only product line.

+ +

Like, you really need to be laser-focused in what is my incremental product development here so that I can maintain the attention of the public? As well as then trying to work concurrently on how do I evolve my product line to then broaden out my audience? So I think that's quite different in terms you have to be very focused.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

CHAD: You started at Dyson as a design engineer, and you moved through up into a senior design engineer, then concept lead, to design manager of new product innovation. What was the journey from design engineer to eventually design manager? And what are the differences between those roles?

+ +

NEIL: I think the key thing that changes within those roles is the level of autonomy and responsibility. And I think what scales up through each of those rungs is essentially how you can demonstrate competency for your core responsibility set. So as a design engineer, you're responsible for part-level designs like, here is, you know, you mentioned the mechanical keyboard earlier in the conversation. In that scenario, you would have a team of potentially four design engineers seeing that through to fruition. You would have a subset of those parts which you're exclusively responsible for.

+ +

CHAD: So you might just be responsible for designing the best keycaps.

+ +

NEIL: Exactly, exactly. So one chap will be just looking at the springs, and the tension, and how do they feel. Another one will be looking at the structural integrity; another one will be looking at the ergonomics. So I think you have the individual part and function. And what then levels up from that is as you go then into an advanced design engineer or a senior engineer is that you begin being responsible for the full assembly. So instead of having your keycap, you're now responsible for leading the whole team doing the whole keyboard.

+ +

And then as you then progress through that, having demonstrated competency and reliability of delivering things, you then become a concept lead, which is to say that you have multiple projects on at the same time. You're leading the teams to do that. And then as you progress through that into design and management role, you then level that up again in terms of you're typically managing portfolios of projects within different market sectors.

+ +

So I think if that answers your question directly enough, what it really builds on is for anyone aspiring, is you really need to focus on the basics first, like making sure that you are fundamentally a good designer and a good engineer who can demonstrate and communicate your logic and your thought process. And I think if you already underpin yourself with those sorts of fundamental competencies, that serves you really well as you move up through the ranks.

+ +

CHAD: Some people I talk with, as they move up through those ranks, they feel like they are getting further and further away from what they actually love to do, which was design products. Is that something that you felt, or how did you not feel that?

+ +

NEIL: I think as you move up through the management hierarchy, at the same time, typically the people that do that, I find and who are successful at it have a fairly focused view of what are their goals, what are they trying to achieve, and what is almost their trademark that they're known for. So for myself, how I've avoided that is...you asked me why I'm interested in Gembah, and that's because what I have very instinctively done both at Dyson and here is make sure that I've positioned myself to solve real problems. Probably everybody in a senior management position sometimes still misses getting on CAD or coding and just having the afternoon with no meetings. [laughs]

+ +

CHAD: Yeah.

+ +

NEIL: I think there's an element of that that you can't get away from. However, what really enthuses and keeps me really engaged and motivated in what I am doing now is to say I'm still solving problems, which is the fundamental heart of everything. So instead of designing the best keyboard for somebody who has carpal syndrome or hand problems, what we're now designing and developing is a platform that solves problems for a whole very broad user base.

+ +

As long as you are always focused in your role in terms of how can I best serve and provide solutions to problems, I think what people will find is that you're actually always very fulfilled as a creator, maybe not as a mechanical engineer or electrical engineer, depending on your background, or a coder. But if you're fundamentally interested in solving problems and bringing solutions, you can still hold on to that very tightly.

+ +

CHAD: Yeah. As head of design now, what does your day-to-day look like?

+ +

NEIL: The majority of what it looks like is what I almost just mentioned with regards to how are we both developing and sustaining a business that provides and develops better solutions for our clientele as well as then dipping in and out of projects which require support and a little bit of extra attention? As I mentioned, as a design manager at Dyson, looking across portfolios of projects.

+ +

My role now is really around making sure that all of our category leads, who are people looking after multiple projects that they, all have the support and tools that they need and require, as well as, as I mentioned, in particular cases, giving attention to some design projects that need help. And then roadmapping out, like, what is the future? What are the next incremental steps of functionality and platform features that we want to develop as a company and facilitate and bring to market for our customers?

+ +

CHAD: What are some of those things that you're seeing across the portfolio that are needs that you're hoping to meet?

+ +

NEIL: I think a very interesting new thing that we're bringing to market at the moment is what we call design to manufacture as a process. And what we really try and do there is we see in the market at the moment that people have a real sensitivity around cost-effectiveness with the global economies where they're at and supply chain. Like, how do I, number one, potentially diversify my supply chain? Or number two, how do I actually launch a new product with as little cost to myself as a business as possible?

+ +

And what we do there is a report, a product opportunity report that profiles you as a business and a brand, and then overlaps that almost in a Venn diagram of where's the sweet spot in terms of available products in the markets that you could customize that would really suit your brand and that we could really effectively customize, and develop with a manufacturer and with a design team and get to market really quick, really cheap, but is still uniquely your own and has your special touch to it?

+ +

CHAD: Obviously, a thing that has happened in this market or this industry over the last decade or so is crowdfunding and Kickstarter specifically. How have you seen that change things for people?

+ +

NEIL: I think what it's meant is people get access to funds in a way that would have taken a very long time previously. And I think the other thing is people get feedback on ideas quite quickly as well, which maybe isn't the case across the broad spectrum. But for people who have an idea and want to very quickly test it with the markets in terms of does, this resonate with my user groups that I'm interested in? Like, is this a real set of user problems which I believe I've solved? Is that actually true?

+ +

I think what it's provided product, you know, industrial design is typically, or any other type of product creator is this very quick access to people with capital who can invest and seeing their products through to fruition, which otherwise was actually a really hard and arduous task, not only getting feedback but then trying to raise capital separately.

+ +

CHAD: In your opinion, what's the ideal point that something actually goes to crowdfunding?

+ +

NEIL: The ideal timing for your crowdfunding campaign is where you have the first iterations of a working and demonstrated functional prototype where it's not just all idea but that you can demonstrate the fact that you're committed to this, that you can demonstrate the functionality of it, and show that you've considered how it's going to be made and that it's not actually going to change massively. Because I think what you can sometimes see is people can go to Kickstarter prematurely. And then when they're actually getting into the manufacturer of the product, there are some fairly large compromises that need to be made or the fact that the idea isn't feasible and they can't make it.

+ +

The ideal time to go to a Kickstarter is where you've already thought through all your user scenarios. You've got a very clear perspective on what the problem set is that you're solving and that you can then demonstrate that with a working prototype. And that doesn't need to be pretty or visually pleasing because you can have your beautiful render next to your functional prototype. I think that's a great time.

+ +

CHAD: And concrete information on the feasibility of manufacturing it.

+ +

NEIL: Absolutely. So I think in part of informing your working prototype, I think you need to have early what you'd call DFM, design for manufacture feedback which is where you've spoken to a manufacturer or a tooling engineer and said, "What are the key considerations I should take into building this assembly?" And often is, the case for people who perhaps haven't gone down that road very, very far is that there are some fairly significant adjustments that you need to make to either the visuals or the functionality of your design. At least having a few initial conversations with those factories very clearly integrated into your product considerations is really, really critical.

+ +

CHAD: So I have to ask, is there something that you're personally pursuing now and working on?

+ +

NEIL: At the moment, not via Kickstarter. I think the thing actually I'm doing in my spare time is a bit of a passion project with regards to furniture. I think certainly, from my perspective, every designer can pay homage to architecture as the mother of all design. What more is an in-depth user experience and journey than the spaces we're all sitting in every day? And a big part of that is furniture. So I'm designing an armchair in my spare time. This is a way to, [laughs] as you mentioned earlier, with my current role as how it is just making sure I keep sharp my sketching skills and design skills, even if it's just for myself.

+ +

CHAD: What does that look like for you? Is it sketching on paper now? And how far do you think you'll take it?

+ +

NEIL: At the moment, it's just sketching on paper and asking my kids which ones they like, they dislike. [laughter] And I think, thankfully, with the abilities I've developed and some of the resources I have access to, we'll probably build a functioning prototype just so I can have a nice new armchair in the kitchen.

+ +

CHAD: Does that mean creating it yourself, or what does that look like?

+ +

NEIL: Again, I can only speak for myself. But being a creator and having come from my past, as we mentioned at Dyson, I think my true passion is creation, so keeping my hands very familiar with materials and screwing things together. So I think what that will look like for me is actually just getting all the raw materials myself within the woodwork, the metalwork, and doing all that work myself. I haven't got much of a passion yet for upholstery, so I'll probably outsource that part. There's something really rewarding in physically making something with your hands which I've never let go of, and I think I'll always enjoy.

+ +

CHAD: That's great. I want to come back, as we wrap up, to those three pillars that you outlined, which I thought were really great. What does someone do who's really passionate about the idea that they have, but they hit roadblocks on one or more of those pillars?

+ +

NEIL: Hmm, if somebody wants to start just themselves and you have an idea, and you don't want to necessarily engage with a company or service providers yet, I think what you can really do and start with is engaging with groups and doing research yourself so around desirability and feasibility. There is a world of products and reviews out there. There are a lot of resources there. So what I would encourage if somebody has said...you know, let's use your keyboard example again.

+ +

CHAD: Yep.

+ +

NEIL: What are the best-selling keyboards out there? And is there a silver lining in between all of them in terms of what makes them sell so well? Is it their functionality? Is it their design? Is it the ergonomics? So I think people can really do a lot of research around what develops and constitutes a really desirable product. As well as then in terms of the feasibility, like, are the things you're putting together can you find them freely on, say, a website like Alibaba? Or can you fundamentally make a keyboard out of wood at scale? Again, there are a lot of resources online that you can do for yourself.

+ +

And then around viability in terms of, like, what would your margins have to be? Again, I think there's quite a lot you can do there with yourself with regards to what is available on the market today? What are their unique selling points? What are their suggested selling prices? And where do you think you could competitively position yourself?

+ +

Typically, how I find that works out is a matrix of ideas. And I think people really need to not be precious about the one idea they have but really be adventurous around, like, what are all the ways that I could potentially solve for this problem set? And then just market against that matrix of desirability, feasibility, and viability and see which one is enough of all of those that actually gives you your best shot at success?

+ +

I think, typically, you see a lot of creators who are very precious about an idea. And actually, maybe, again, it's entirely machined out of aluminum. Well, you know, you're really going to struggle to make that at a competitive price.

+ +

CHAD: Right. You're not necessarily Apple. [laughs]

+ +

NEIL: Exactly. You haven't got that economy of scale available to you. [laughs] So I think having a very clear goal in terms of, like, where do I think I can position this in the market? Do I think people will like it? And could I make it for that much?

+ +

CHAD: Yeah, I think that that's true across the entire spectrum of digital and physical product design and development. We work with a lot of founders who have an idea. And compromise problem-solving through the many challenges that you face is critical. And if you're not able to do that, it's very difficult to actually get a product to market in any reasonable time frame or financial sustainability.

+ +

NEIL: I completely agree.

+ +

CHAD: Well, I really appreciate you stopping by the show and sharing with us, Neil.

+ +

NEIL: Thank you so much for having me today. It's been a great conversation, and I've really enjoyed it.

+ +

CHAD: If folks want to get in touch with you, or follow along, or learn more about Gembah or anything else, where are all the different places that they can do that?

+ +

NEIL: So you can certainly find and connect with me on LinkedIn if anyone would like to follow up with me personally. And if you're really serious about getting a product to market and engaging around that process, you can just look us up at gembah.com.

+ +

CHAD: And I can also personally say if you like looking at pretty things for inspiration, Neil's Instagram is also pretty good for that. [laughter]

+ +

You can subscribe to the show and find notes for everything that we just mentioned, along with links and a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Neil Macqueen.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Neil Macqueen is a leading industrial designer with 78 patents to his name, having previously spent ten years at Dyson and is now the Head of Design at Gembah, the world's first global marketplace for product development.

+ +

Chad talks to Neil about being focused on industrial design or actual physical products as opposed to interfaces and digital products, working designers and developers, and design to manufacture as a process.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Neil Macqueen, a leading industrial designer with 78 patents to his name, having previously spent ten years at Dyson and who is now the Head of Design at Gembah, the world's first global marketplace for product development. Neil, thank you so much for joining me.

+ +

NEIL: Oh, it's great to be here with you today, Chad. Thank you for having me.

+ +

CHAD: One distinction I feel like we always need to make, and this is one of the things we struggle with at thoughtbot; people want to put themselves out in the community and say, "Here's what I do," and people use the word product design. And there's actually a pretty big, you know, some designers are, or product developers are industrial design physical products and others are digital. What do you do at Gembah?

+ +

NEIL: For me, myself, what I do at Gembah explicitly is far more focused around industrial design or actual physical products as opposed to interfaces and digital products.

+ +

CHAD: And as the world's, you know, the self-described first global marketplace for product development, what does that actually mean?

+ +

NEIL: What it means is that Gembah provides a platform in which anybody with an idea or an aspiration to even have an idea has a single source by which you can tap into all the resources you need to get your product to market. So I think a good metaphor for it would be that it's very easy for myself, yourself, any of the listeners today to become a seller. Like, I can set myself up with an eBay or an Amazon account this afternoon and start selling a product. There are very low barriers to doing that.

+ +

Whereas if you want to become a product creator, that is a very disjointed process. And what you'll see from large companies like my experience at Dyson and other companies is that they have a vertically integrated business. They own each part of that product creation, development, engineering, production, logistics. It is all very integrated. And what we try and do and provide to creators is that single integrated structure by which you can have an idea, work with a designer, develop that in conjunction with a manufacturer, and then very seamlessly move over into your production and logistics.

+ +

CHAD: You mentioned Dyson, and you spent ten years there and moved through various design roles. I definitely want to touch on that in a little bit. But what attracted you to Gembah?

+ +

NEIL: I think, as with all people who are interested in ideas, whether digital or physical, it's the process of creating something that really attracted me, has attracted me to all my roles in the past, and certainly to Gembah. In as much as what I just described previously, it is a world first, like, it is a category-defining company.

+ +

So I think what really attracted me to Gembah was the fact that what we're doing here is not only building lots of very interesting products and helping entrepreneurs, and product creators, and businesses, but what we're doing is developing a platform which is entirely unique and one of its kind.

+ +

CHAD: I have to admit, I did a little bit of research on you, as I always do. And I looked at your Twitter, and I saw that a lot of your tweets were, I think, back from 2016, where you yourself designed...how would you describe it? A coffee press stand?

+ +

NEIL: Exactly. And AeroPress stand.

+ +

CHAD: Having been through that process and launching it on Kickstarter, is that part of what...you said I want to help other people do this.

+ +

NEIL: Absolutely. And it is probably a very congregating experience in terms of people who go through crowdfunding campaigns and then try and do it yourself. And certainly, my experience, you know, Kickstarter is a wonderful platform. But everything thereafter for me as a creator doing something in my spare time and my evenings outside of my normal nine to five was incredibly challenging, you know, dealing with factories who had very broken English or really struggled to communicate both my idea and their complications accurately. And just how that unfolded into trying to get a product to market without somebody to help and guide me through that process, doing it entirely by yourself.

+ +

So I think that was certainly a very challenging experience in terms of getting that coffee stand to market. And I think the same is true for lots of first-time creators and even businesses in trying to reduce costs, up efficiency of getting to market quickly. Like, who are the partners and people that you can work with and businesses you can partner with to help provide you with those benefits? And that's really what we try and provide at Gembah. And I think, as you mentioned at the start, certainly my past experiences make me think that what we're building here today certainly does bring a lot of benefit.

+ +

CHAD: I've had quite a few people on the show who launched physical products themselves on Kickstarter or other crowdfunding platforms. And often, the conversation turns to how difficult it actually was from a supply chain perspective from a manufacturing perspective.

+ +

One of the things that struck me about Gembah is that it is not a small operation. It has headquarters in the U.S, but team members live and work all over the world. Their website says there are 150-plus team members globally, so given that reach, it seems like it probably can be really helpful to people solving those challenges. I'm curious who the ideal customers of Gembah are. What is the profile of someone who works with Gembah?

+ +

NEIL: For our ideal client at the moment, I think that's one topic, and we can go into that. But what we're really trying to do in terms of the company vision is to democratize the design process and creating a product that gets to market. So as much as for us as a company, you know, having gone through a series A funding round and heading towards a series B, yes, we have got a fairly focused view of who is our ideal client profile and persona.

+ +

However, what we're really aiming towards is providing this vertically integrated system of design and marketplace resources to absolutely everybody. That is the vision, the vision that anybody can become a product creator for the first time. In as much as, like my metaphor said earlier, you can become a seller on eBay, you should be able to have as easy access to the resources that enable that product creation.

+ +

CHAD: So there's an example I always like to use; it has legs a little bit, which is thoughtbot is a well-respected design and development company. And there's an opportunity, you know, we're working designers and developers. And as people who do this work, we often either buy products and see how they could be improved or have ideas for our own, whether it be notepads, or pens, or even mechanical keyboards are a really interesting thing. If we wanted to pursue something like that, how might we do that?

+ +

NEIL: In the context of Gembah?

+ +

CHAD: Yeah, or beyond. But yes.

+ +

NEIL: So I think the first thing for anybody with an idea is to really have some very clear goals at the outset in terms of...and for anybody who is interested in user-centered design, three of the guiding principles for that are three things I always really lean on which is feasibility, viability, and desirability. So within all of those things, what are your ambitions for your product? In terms of ideally, every product should be desirable; people should want to buy it.

+ +

Have you got the means by which to get it to market? And once you've got it there, will it provide you enough of a margin to have a sustainable business? So the viability of the product. And can you actually make it? You know, it's not made out of unobtainium, or it [laughter] might be.

+ +

So I think a very easy starting point for absolutely everybody is to really go via those three guiding principles in terms of the desirability, viability, and feasibility of your idea. Where do you think you score on that matrix? And then if you think you really have got something in terms of an idea that really has merit and that you have the wherewithal that you want to see it through to fruition, certainly just picking up the phone and calling Gembah, that's a great second step.

+ +

CHAD: Okay. So at Gembah, if someone picks up the phone before going through those three steps and is talking to you, do you help them take a step back and answer those three questions?

+ +

NEIL: Absolutely. So I think what we really try and do is not only facilitate your product development journey. We're not a service provider; we're a service facilitator. We want to connect you with all of the resources within our platform and marketplace. And what we really try and steer towards is what is the product development journey that best suits your needs. And I think, typically speaking, if we were to use a broad brush, it falls into three camps which is, do you want to speed to market? And the fact you want to sell an idea very quickly.

+ +

So, could you potentially white-label your product? So we provide these options to people. So there's a white labeling route. There's then a customized route which is to say, is there something fairly similar already commercially available in the market and that factories provide, and that you could adjust the feature set for your idea by perhaps 10%? That would actually then mean that you could get your idea customized in the factory and into market. So that's the customized route.

+ +

Versus then an entirely unique product which is to say that you need to both develop the design and tooling for the product from the ground up. Intuitively, I would hope from white labeling all the way through to unique product development; you have a fairly matched scale of time and cost. The more involved, the more detail, the more unique, the more time, and the more cost proportionally increases.

+ +

CHAD: How would you say that designing within a company like Dyson is different than being outside?

+ +

NEIL: The thing that working for a company like Dyson and others like it really affords you is the freedom to research without the means of having to really focus on what is my next launch in a year's time. And what I mean by that is Dyson and other large, successful companies have exclusive product development innovation hubs and idea teams who, for every 100 products they develop, potentially only get one through to market and into the global markets.

+ +

So I think as a designer, what you're really afforded there is the space and creativity to explore lots of ideas without the pressure of I have to have something out in this next six-month period into the market. I think that's very different to a small to medium-sized enterprise who have a set product line, and this may be your only product line.

+ +

Like, you really need to be laser-focused in what is my incremental product development here so that I can maintain the attention of the public? As well as then trying to work concurrently on how do I evolve my product line to then broaden out my audience? So I think that's quite different in terms you have to be very focused.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

CHAD: You started at Dyson as a design engineer, and you moved through up into a senior design engineer, then concept lead, to design manager of new product innovation. What was the journey from design engineer to eventually design manager? And what are the differences between those roles?

+ +

NEIL: I think the key thing that changes within those roles is the level of autonomy and responsibility. And I think what scales up through each of those rungs is essentially how you can demonstrate competency for your core responsibility set. So as a design engineer, you're responsible for part-level designs like, here is, you know, you mentioned the mechanical keyboard earlier in the conversation. In that scenario, you would have a team of potentially four design engineers seeing that through to fruition. You would have a subset of those parts which you're exclusively responsible for.

+ +

CHAD: So you might just be responsible for designing the best keycaps.

+ +

NEIL: Exactly, exactly. So one chap will be just looking at the springs, and the tension, and how do they feel. Another one will be looking at the structural integrity; another one will be looking at the ergonomics. So I think you have the individual part and function. And what then levels up from that is as you go then into an advanced design engineer or a senior engineer is that you begin being responsible for the full assembly. So instead of having your keycap, you're now responsible for leading the whole team doing the whole keyboard.

+ +

And then as you then progress through that, having demonstrated competency and reliability of delivering things, you then become a concept lead, which is to say that you have multiple projects on at the same time. You're leading the teams to do that. And then as you progress through that into design and management role, you then level that up again in terms of you're typically managing portfolios of projects within different market sectors.

+ +

So I think if that answers your question directly enough, what it really builds on is for anyone aspiring, is you really need to focus on the basics first, like making sure that you are fundamentally a good designer and a good engineer who can demonstrate and communicate your logic and your thought process. And I think if you already underpin yourself with those sorts of fundamental competencies, that serves you really well as you move up through the ranks.

+ +

CHAD: Some people I talk with, as they move up through those ranks, they feel like they are getting further and further away from what they actually love to do, which was design products. Is that something that you felt, or how did you not feel that?

+ +

NEIL: I think as you move up through the management hierarchy, at the same time, typically the people that do that, I find and who are successful at it have a fairly focused view of what are their goals, what are they trying to achieve, and what is almost their trademark that they're known for. So for myself, how I've avoided that is...you asked me why I'm interested in Gembah, and that's because what I have very instinctively done both at Dyson and here is make sure that I've positioned myself to solve real problems. Probably everybody in a senior management position sometimes still misses getting on CAD or coding and just having the afternoon with no meetings. [laughs]

+ +

CHAD: Yeah.

+ +

NEIL: I think there's an element of that that you can't get away from. However, what really enthuses and keeps me really engaged and motivated in what I am doing now is to say I'm still solving problems, which is the fundamental heart of everything. So instead of designing the best keyboard for somebody who has carpal syndrome or hand problems, what we're now designing and developing is a platform that solves problems for a whole very broad user base.

+ +

As long as you are always focused in your role in terms of how can I best serve and provide solutions to problems, I think what people will find is that you're actually always very fulfilled as a creator, maybe not as a mechanical engineer or electrical engineer, depending on your background, or a coder. But if you're fundamentally interested in solving problems and bringing solutions, you can still hold on to that very tightly.

+ +

CHAD: Yeah. As head of design now, what does your day-to-day look like?

+ +

NEIL: The majority of what it looks like is what I almost just mentioned with regards to how are we both developing and sustaining a business that provides and develops better solutions for our clientele as well as then dipping in and out of projects which require support and a little bit of extra attention? As I mentioned, as a design manager at Dyson, looking across portfolios of projects.

+ +

My role now is really around making sure that all of our category leads, who are people looking after multiple projects that they, all have the support and tools that they need and require, as well as, as I mentioned, in particular cases, giving attention to some design projects that need help. And then roadmapping out, like, what is the future? What are the next incremental steps of functionality and platform features that we want to develop as a company and facilitate and bring to market for our customers?

+ +

CHAD: What are some of those things that you're seeing across the portfolio that are needs that you're hoping to meet?

+ +

NEIL: I think a very interesting new thing that we're bringing to market at the moment is what we call design to manufacture as a process. And what we really try and do there is we see in the market at the moment that people have a real sensitivity around cost-effectiveness with the global economies where they're at and supply chain. Like, how do I, number one, potentially diversify my supply chain? Or number two, how do I actually launch a new product with as little cost to myself as a business as possible?

+ +

And what we do there is a report, a product opportunity report that profiles you as a business and a brand, and then overlaps that almost in a Venn diagram of where's the sweet spot in terms of available products in the markets that you could customize that would really suit your brand and that we could really effectively customize, and develop with a manufacturer and with a design team and get to market really quick, really cheap, but is still uniquely your own and has your special touch to it?

+ +

CHAD: Obviously, a thing that has happened in this market or this industry over the last decade or so is crowdfunding and Kickstarter specifically. How have you seen that change things for people?

+ +

NEIL: I think what it's meant is people get access to funds in a way that would have taken a very long time previously. And I think the other thing is people get feedback on ideas quite quickly as well, which maybe isn't the case across the broad spectrum. But for people who have an idea and want to very quickly test it with the markets in terms of does, this resonate with my user groups that I'm interested in? Like, is this a real set of user problems which I believe I've solved? Is that actually true?

+ +

I think what it's provided product, you know, industrial design is typically, or any other type of product creator is this very quick access to people with capital who can invest and seeing their products through to fruition, which otherwise was actually a really hard and arduous task, not only getting feedback but then trying to raise capital separately.

+ +

CHAD: In your opinion, what's the ideal point that something actually goes to crowdfunding?

+ +

NEIL: The ideal timing for your crowdfunding campaign is where you have the first iterations of a working and demonstrated functional prototype where it's not just all idea but that you can demonstrate the fact that you're committed to this, that you can demonstrate the functionality of it, and show that you've considered how it's going to be made and that it's not actually going to change massively. Because I think what you can sometimes see is people can go to Kickstarter prematurely. And then when they're actually getting into the manufacturer of the product, there are some fairly large compromises that need to be made or the fact that the idea isn't feasible and they can't make it.

+ +

The ideal time to go to a Kickstarter is where you've already thought through all your user scenarios. You've got a very clear perspective on what the problem set is that you're solving and that you can then demonstrate that with a working prototype. And that doesn't need to be pretty or visually pleasing because you can have your beautiful render next to your functional prototype. I think that's a great time.

+ +

CHAD: And concrete information on the feasibility of manufacturing it.

+ +

NEIL: Absolutely. So I think in part of informing your working prototype, I think you need to have early what you'd call DFM, design for manufacture feedback which is where you've spoken to a manufacturer or a tooling engineer and said, "What are the key considerations I should take into building this assembly?" And often is, the case for people who perhaps haven't gone down that road very, very far is that there are some fairly significant adjustments that you need to make to either the visuals or the functionality of your design. At least having a few initial conversations with those factories very clearly integrated into your product considerations is really, really critical.

+ +

CHAD: So I have to ask, is there something that you're personally pursuing now and working on?

+ +

NEIL: At the moment, not via Kickstarter. I think the thing actually I'm doing in my spare time is a bit of a passion project with regards to furniture. I think certainly, from my perspective, every designer can pay homage to architecture as the mother of all design. What more is an in-depth user experience and journey than the spaces we're all sitting in every day? And a big part of that is furniture. So I'm designing an armchair in my spare time. This is a way to, [laughs] as you mentioned earlier, with my current role as how it is just making sure I keep sharp my sketching skills and design skills, even if it's just for myself.

+ +

CHAD: What does that look like for you? Is it sketching on paper now? And how far do you think you'll take it?

+ +

NEIL: At the moment, it's just sketching on paper and asking my kids which ones they like, they dislike. [laughter] And I think, thankfully, with the abilities I've developed and some of the resources I have access to, we'll probably build a functioning prototype just so I can have a nice new armchair in the kitchen.

+ +

CHAD: Does that mean creating it yourself, or what does that look like?

+ +

NEIL: Again, I can only speak for myself. But being a creator and having come from my past, as we mentioned at Dyson, I think my true passion is creation, so keeping my hands very familiar with materials and screwing things together. So I think what that will look like for me is actually just getting all the raw materials myself within the woodwork, the metalwork, and doing all that work myself. I haven't got much of a passion yet for upholstery, so I'll probably outsource that part. There's something really rewarding in physically making something with your hands which I've never let go of, and I think I'll always enjoy.

+ +

CHAD: That's great. I want to come back, as we wrap up, to those three pillars that you outlined, which I thought were really great. What does someone do who's really passionate about the idea that they have, but they hit roadblocks on one or more of those pillars?

+ +

NEIL: Hmm, if somebody wants to start just themselves and you have an idea, and you don't want to necessarily engage with a company or service providers yet, I think what you can really do and start with is engaging with groups and doing research yourself so around desirability and feasibility. There is a world of products and reviews out there. There are a lot of resources there. So what I would encourage if somebody has said...you know, let's use your keyboard example again.

+ +

CHAD: Yep.

+ +

NEIL: What are the best-selling keyboards out there? And is there a silver lining in between all of them in terms of what makes them sell so well? Is it their functionality? Is it their design? Is it the ergonomics? So I think people can really do a lot of research around what develops and constitutes a really desirable product. As well as then in terms of the feasibility, like, are the things you're putting together can you find them freely on, say, a website like Alibaba? Or can you fundamentally make a keyboard out of wood at scale? Again, there are a lot of resources online that you can do for yourself.

+ +

And then around viability in terms of, like, what would your margins have to be? Again, I think there's quite a lot you can do there with yourself with regards to what is available on the market today? What are their unique selling points? What are their suggested selling prices? And where do you think you could competitively position yourself?

+ +

Typically, how I find that works out is a matrix of ideas. And I think people really need to not be precious about the one idea they have but really be adventurous around, like, what are all the ways that I could potentially solve for this problem set? And then just market against that matrix of desirability, feasibility, and viability and see which one is enough of all of those that actually gives you your best shot at success?

+ +

I think, typically, you see a lot of creators who are very precious about an idea. And actually, maybe, again, it's entirely machined out of aluminum. Well, you know, you're really going to struggle to make that at a competitive price.

+ +

CHAD: Right. You're not necessarily Apple. [laughs]

+ +

NEIL: Exactly. You haven't got that economy of scale available to you. [laughs] So I think having a very clear goal in terms of, like, where do I think I can position this in the market? Do I think people will like it? And could I make it for that much?

+ +

CHAD: Yeah, I think that that's true across the entire spectrum of digital and physical product design and development. We work with a lot of founders who have an idea. And compromise problem-solving through the many challenges that you face is critical. And if you're not able to do that, it's very difficult to actually get a product to market in any reasonable time frame or financial sustainability.

+ +

NEIL: I completely agree.

+ +

CHAD: Well, I really appreciate you stopping by the show and sharing with us, Neil.

+ +

NEIL: Thank you so much for having me today. It's been a great conversation, and I've really enjoyed it.

+ +

CHAD: If folks want to get in touch with you, or follow along, or learn more about Gembah or anything else, where are all the different places that they can do that?

+ +

NEIL: So you can certainly find and connect with me on LinkedIn if anyone would like to follow up with me personally. And if you're really serious about getting a product to market and engaging around that process, you can just look us up at gembah.com.

+ +

CHAD: And I can also personally say if you like looking at pretty things for inspiration, Neil's Instagram is also pretty good for that. [laughter]

+ +

You can subscribe to the show and find notes for everything that we just mentioned, along with links and a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Neil Macqueen.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+3ytckiqq + + ]]> + + Chad Pytel + Neil Macqueen + + + 446: Plants and Perks with Chloe Sweden + https://podcast.thoughtbot.com/446 + fa635908-953c-4a60-a384-0f1a1ee22727 + Thu, 27 Oct 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Chloe Sweden is the Founder and CEO of Plants and Perks, a service for rewarding employees with sustainable perks. + +Chad talks to Chloe about supporting employees on plant-based sustainability journies by gifting free samples and high-value prizes, choosing a co-founder, and being strategic with the types of businesses they've approached. + 43:22 + no + + + Chloe Sweden is the Founder and CEO of Plants and Perks, a service for rewarding employees with sustainable perks. +Chad talks to Chloe about supporting employees on plant-based sustainability journies by gifting free samples and high-value prizes, choosing a co-founder, and being strategic with the types of businesses they've approached. +Plants and Perks (https://www.plantsandperks.com/) +Follow Plants and Perks on Instagram (https://www.instagram.com/@plantsandperks/), Facebook (https://www.facebook.com/plantsandperks), or LinkedIn (https://www.linkedin.com/company/plantsandperks/). +Follow Chloe on LinkedIn (https://www.linkedin.com/in/chloe-sweden-014/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Chloe Sweden, the Founder, and CEO of Plants and Perks, a service for rewarding employees with sustainable perks. Chloe, thank you so much for joining me. +CHLOE: Thank you for having me. +CHAD: So you officially started Plants and Perks, at least according to your LinkedIn, in July of 2020. But I'm sure, like many entrepreneurs, you incubated the idea. The idea was in your head for longer than that. So, where does the idea from Plants and Perks come from? And when did you start to noodle it? +CHLOE: It's a really, really good question. I also think that the LinkedIn algorithm isn't 100% correct. +CHAD: [laughs] +CHLOE: And it always seems to add time. I always get this sort of like, "Oh my God, you've been doing this for like two years?" I'm like, "No, I'm sure it can't be. It must be shorter than that." So Plants and Perks, Plants and Perks originally started out life as the Green Shoot Institute, which, I think, if you Google us, still there's remnants of the Green Shoot Institute that exists. That is still our company holding name. And that was kind of, I guess, the first thought of the idea. +I was at the time heading up commercial relationships at a large parenting platform in the UK. And we had started to go on our own plant-based journey, so thinking about cutting back on meat and dairy consumption. I guess that was sort of my own personal journey that started to make me, as a parent, and as a consumer, and as a senior leader within business to, start to think about things outside of myself, and my family, and my business. And really, that was kind of the spark of thinking about how we, as employers, don't really do much to support employees on the plant-based sustainability journey. That was the sort of the embryo of the idea. +And that came from the fact that I had spent 20 years of my life in advertising, marketing, and then ten years within that in talent as a former head of talent and culture really thinking about how we embed talent and how we help employees, and how culture is so important to businesses, and how we get employees really to be the face of our brands. But we don't really do much to invest in people beyond the kind of traditional benefits that exist but also in terms of training and things like that. +That was kind of where things were coming together, sort of thinking about the future of work and thinking about how people go through these huge life moments and how the businesses really support them. So that was kind of the start. I won't give the whole game away, but that was, I guess, the beginning of a kind of, hmm, there's something there. And I didn't really know what it was at the time. +But yeah, I guess it wasn't so much before I actually incorporated the company. I incorporated in September 2020. That's what it says on my Company's House printout that I have on the wall just to remind me of when that momentous day happened. But pretty quickly, from coming up with an idea, I incorporated the business and just went, this is something I have to do. +CHAD: Yeah, the feeling of this is something I have to do is something that I've felt myself and that I hear from a lot of entrepreneurs and guests of the show. You were working at Mumsnet at the time. How did you start while also having another job? +CHLOE: Not just having another job, running a large sales team, and homeschooling two children during a pandemic. +CHAD: Oh, homeschooling. Okay, yeah. +CHLOE: And my son was definitely diagnosed with having additional needs at the time as well. I guess it was all of those things that kind of came together that made me realize, I mean, I had joined Mumsnet actually to head up Mumsnet's talent function, which was all about creating a flexible working product platform for parents and those looking for flexible jobs to bring them together in a marketplace. But Mumsnet wasn't going to actually continue to invest in that product, and I moved to a more commercial role. +But I moved there to build a product. And that's what really triggered it for me. I realized in that moment when I'm homeschooling, and I'm running a large sales team, and I'm doing all of these things, that wasn't why I moved to this role. I actually moved because I'm at the point in my career where I want to build something, that I have it in me to create something, and build, and connect people, and do something bigger than myself and bigger than a day-to-day job. And so that itch was there. +I was also, as part of that role, going out and speaking to heads of HR in large enterprise organizations and talking to them about what was troubling them. And funny enough, looking after their working parents was not troubling them, but sustainability came up a lot, and general well-being came up a lot. And so that was kind of, I guess, it started the percolation. But really, I guess with most things, the idea came about in its most embryonic stage, and then I took it to market really quickly. I basically gave it a name and then just reached out on LinkedIn to anybody I knew and people I didn't know as well just literally reached out to those people. +And I spoke to one person who I won't name her or the company but probably one of the largest global companies in the world and at a very senior level. And she was actually working out of the States. And she said to me, you know, "This is new. [laughs] You need to do this. Nobody is doing this. We need this in our lives. And I haven't heard of anybody doing this in the States. You need to go and build this." And that was, I guess, the impetus to do it. +And so I worked weekends. I actually was working four days a week at Mumsnet. But my fifth day, I was working full time for Mumsnet but not being paid. And so I clawed back my fifth day where I wasn't being paid, and I worked all weekends, and I worked all evenings. And I just worked and worked, and I haven't stopped until this conversation. [laughs] +CHAD: To actually work on it, did you start to gather a team, a group of people? Who were the first people that you brought on to help you? +CHLOE: So my co-founder, Ellen, we were on the senior leadership team of a creative agency. I was the head of talent and culture. She was the head of operation. So we had worked side by side in this organization. So we kept in touch. And she had contacted me about some health issues. And we were talking about cutting back on meat and dairy as one of the things that she could look at, given my own experiences with it. And that really bonded us. +And because I am marketing, sales, creative, and she is digital, tech, product, it kind of made sense, in the beginning, to bring her on. And I just said to her like, "I'd really like you on this journey with me." And she resisted it for quite some time. [laughs] We are very different personality-wise, very, very different. I'm yes, she's no, and so in that way, we're very much yin and yang. +CHAD: Oh, but I think that that can be the perfect combination for a co-founder team. I know that I've needed that in the past for myself. Someone who balances the risk-taking with reality can be very helpful. +CHLOE: Yeah, absolutely. And I think I'm actually not a risk taker, but I am a natural optimist. And so I'll have a meeting, and I'll be like, "It's amazing. It's solved all of our problems." And she'll be just like, "No, it hasn't. What's changed? Nothing's changed. There's no contract, nothing signed," [laughs] which I think in the moment is really not helpful. [laughs] But it's really helpful as we grow the business. It really is a good balance. +I bring all of that energy and drive to get us very quickly to the next level. And she brings all of the understanding, all of the pauses, all of the rigor, all of the data, all the things that are just the complete opposite of me. So I brought her on pretty quickly. And then we had a bit of a false start around getting a CTO on board. But we knew we needed to build the product quickly. And in the end, we built the product ourselves on a no-code/low-code platform, just the two of us. And I recommend any entrepreneur to do that because you learn a lot. [laughs] +CHAD: Is that the reason...so you learning...because I think that that is super important, whether it be someone like yourself actually building the product or just being very close to it. When I've seen entrepreneurs get too far away from the product too soon, they end up regretting it later on. +CHLOE: Yeah, I think -- +CHAD: Or building the wrong thing. +CHLOE: Or building the wrong thing. I do really believe in you've got to do every job in order to then understand who you need to hire and to then have an appreciation of that role. So obviously the product evolved very much and very quickly. We were very lucky that one of our first clients was Lacoste, who we launched to here in the UK with our MVP. But we also did some other paid consultancy work with Uber and with other clients as well. And then PopSockets came on in the States as well. We weren't ready to launch in the States, but they really wanted us to. So we're like, you know, let's do it. [laughs] +CHAD: I noticed those three names on your website. And I do think that social...being able to have those testimonials there with names people recognize lends a lot of credibility to the product. +CHLOE: And they were my first three clients, [laughs] genuinely my first three clients. +CHAD: So, did you seek that out, or did it just happen? How did that work out? +CHLOE: Obviously, my background is commercial sales, so it's not something that I shy away from. It was connections; it was talking to people. And we were recommended to PopSockets, which was amazing. They came on as an early investor as well, which was phenomenal. Again, having clients who love what you do so much they want to invest is brilliant because you get to have some really interesting conversations and backers in your corner. +But yeah, of course, we've been quite strategic with the types of businesses that we've approached, but we are very lucky that we are attracting the right type of businesses as well, which is lovely. I mean, talk a little bit more about what Plants and Perks does, but the way in which we have evolved the product and evolved the types of clients that we're talking to is not an accident. And I think it goes back to the conversation we were just having about building the product yourself. Really being in the weeds, I think, is really important. +Now, it's going to be a challenge to me as a founder moving forward to make sure I'm extricating myself from the weeds as time goes on, although I'm pretty happy to step away when needed. [laughs] But knowing that and being able to talk to your clients and being really clear, well, this is what this client likes; this is what's happening here; this is what's working well here, I think is really important. You've got to know your product. You've got to know your audience. +We've got two...actually, we have three clients, technically. We have clients; we have employees; we have client employers; we have employees; and we also have Perks' partners. We have sustainable...we promote sustainable products and services on our platform. So we also have partners as well as our clients. And I think you've got to know them all really well. +Now, I was a head of talent and culture, so I know the employee piece quite well because I was always advocating for the employee. I spent 20 years downsizing, so I ran client accounts. So I know how to look after clients, I guess, from that perspective and work in large organizations. I also used to literally do the marketing for PepsiCo and Wrigley's and big brands. So I can do the partner piece quite well. And I think it's really important that you've done that and you've lived through it. +And I've never built a tech product, but I did literally roll my sleeves up and get stuck in to build the MVP, which was kind of the bit that I was missing. Now, I haven't built the app; that is beyond me. [laughs] But luckily, we've got a brilliant team around us now, which we've built up since our last raise that's enabled us to get that talent in. And yeah, and it's just been an amazing team effort to get us to where we are now. +CHAD: That's great. I want to dig into more about what the product actually is. But you've already alluded a couple of times -- +CHLOE: No, let's keep it mysterious. +[laughter] +CHAD: You've alluded a few times to the evolution. And one thing that's stuck out to me as you were talking about that is that going to the website now; it's not specifically about eating less meat and dairy. You're talking more about sustainability. +CHLOE: Yes. +CHAD: I'm sure that's still a component of it. +CHLOE: 100%. +CHAD: But what drove that change? +CHLOE: Oh my God, [laughs] about a two-week period where we had an existential crisis. I think this is really interesting, I think, for our journey, and I think us as founders as well. So we ideologically always believed in the reduction of meat and dairy as the number one thing you can do for personal and planetary health. That's it. Like, that was it. +We were all about eat plants, get perks. We encourage employees to cut back on their meat and dairy consumption, and we reward them with plant-based perks. That was the product. That was the concept. Tested really well. People really bought into it. People liked that they were being rewarded with perks. They absolutely understood that it is unsustainable to consume meat and dairy in the way that we are moving forward for the planet and also for personal health. +So when we're having these conversations, everyone was like, thumbs up, get it, love it, buy into it, it's all great. And then what was happening is that I kind of got to a point where I was like, we've had all these really positive conversations, but no one's biting. Everyone's sort of saying yes to me and then nothing. +I'm actually really proud of us as a team for very, very quickly going and identifying the problem and fixing it because we could have stuck to our ideological guns and gone, no, no, no, but we are all about the reduction of meat and dairy consumption as the number one thing. But no one was telling us that it was that that was the problem. +What we had to do was read between the lines because nobody would ever tell us that. But what they would say was, "Well, how would it land with a 58-year-old man working in our distribution center?" And we're like, "Really well, why?" [laughter] But I had to understand what was coming behind that question. And what was coming behind the question was I don't want to launch a benefit where I feel like we're judging somebody's life choices. Like, that's not going to wash. +So the people we were talking to were super keen on it, then when they took it up the line, they were essentially saying, "Well, this is a plant-based benefit, Plants and Perks." And I think that's where the sort of record scratched, and it didn't go any further. But no one was feeding this back to us. This we had to discover ourselves. +And so we had this kind of existential crisis where we're like, well, we've always been about sustainability, like, absolutely the reduction in meat and dairy is all because it's unsustainable for us to consume meat and dairy and fish in the way that we are. So why don't we broaden ourselves out to more? We already held sustainable products and services on our platform anyway. It was just the language; it really was. It wasn't actually as big a pivot as it sounded. It really was just softening the language. +So we don't talk about plant-based; we talk about planet-friendly. And we just kind of expanded out some of the articles and content that we contained anyway. And that unblocked everything, like genuinely overnight unblocked everything. So it became something that what we were hearing was that companies wanted to introduce a new green benefit, and now they felt that they could because there wasn't the kind of...and we always said that this is non-judgmental. This is completely supportive. These are very small changes that you could make. You don't have to sort of introduce me to it. +But now it makes sense to everybody. And I think we as a business just needed to go through that moment where we were like, is this the type of business that we want to be running? Is this the business that we want to be owning? And we were like, absolutely, because this is still...our mission actually didn't change at all. Our mission is to help a million employees live healthier, more sustainable lives. That has not changed. And so the fact that our mission hadn't changed, it was just some of the language needed to change to make it more palatable to a wider audience, that's fine. We could live with that. +CHAD: Yeah, that's great. So now, what does that actually mean in terms of what the product is? Companies sign up. +CHLOE: Yep. +CHAD: And what do employees do? +CHLOE: Yeah, so it's a really good question. So the other sort of big moment, I guess, inflection point that we had is that we introduced a freemium model. And that, from a product perspective, was quite a big thing because I started realizing in conversations as well we were giving too much value away. And actually, some of the value that we were giving away clients didn't necessarily want. Some clients really wanted it, and some clients didn't need it. +And so we introduced three different products. So we introduced free, so we now have a completely free Plants and Perks app that any employer can take on for their employee base. And it will give them discounts of sustainable products and services. It will give them article content on how to live more sustainably, embrace more sustainable living. And it will give them planet-friendly recipes on essentially more sustainable, healthy ways to eat. And that's the core free product that we've created. +CHAD: And are you still making revenue on that through partner relationship? +CHLOE: Yeah, absolutely. So, although, you know, we're not about excess consumption. What we are about is...I think what we really realized is with Plants and Perks; we are bang smack in the middle of a cost of living crisis. And actually, what we can do is level the playing field when it comes to green and sustainable products. +There's kind of like this green tax that gets applied. And what we're trying to do is very much look at price parity. So what we talk about is it's harder than ever to make the most sensible choices when costs are spiraling all around us. And so what the reductions of planet-friendly products does is enables you to just try things that you might not have tried before because of cost, and it mitigates against that. +So we do go into relationship with partners, and they can promote their products through the platform. But there are also chances for employees to put their reviews and tell them what they think. So it isn't just set up for advertisers in that way at all. But what we found is there's an amazing thing which is that brands need to connect with a new, wider audience. They don't just want to talk to early adopters within the sustainability or plant-based space. And we are talking to every man and every woman in large-scale organizations. +So it's actually quite difficult to access those people if you're these niche brands who may not even have listings necessarily in large retailers yet. Or if you do have distribution, it's really difficult to get a sell-through. So we enable those partners to offer sampling, to offer freebies, to offer significant discounts, and to offer in-store redemptions as well. So we are offering quite a significant route to market for sustainable and plant-based products and services. +CHAD: That's great. Okay, and so what is the second tier up? +CHLOE: The second tier is plus and what that gives you is we start to give employees plant points, and you collect plant points. It's incredibly gamified. You can collect badges. Every action you do basically has a reaction. So when you read an article, you basically can answer some questions on the article, and you'll be rewarded with points. You can rate a recipe; you can like a recipe, try a recipe. You can buy a product or a service. You can also get a free...in the UK, at the moment, you'll be able to get a free meal once a week, like a free lunch through one of our partners, and loads of freebies as well. +So the value is much more significant in the plus model. That's kind of our core offering. And we talk about rewarding employees with sustainable perks. And during the time at the moment, employers are really looking for ways in which they can support their employees through the cost of living crisis. How can we give our employees free stuff, interesting stuff, whilst also helping them on the sustainability journey? And so therefore, this is something that genuinely really works for both employers and employees. So that's the plus model. +CHAD: One thing I noticed as you lay out the benefits that you get under this model, I'm surprised then by the per-employee cost. It seemed very low to me [laughs] when I saw it. Can you talk more about that? +CHLOE: Yeah, so that is a from price. And I do think I need to make it; I mean, I do say it's from, and I think I do say there's a bit of an asterisk. I do think I need to potentially change it as well. So it's good [laughs] feedback because I think quite a few people say that. So that is for large-scale employers. So we are talking to large retailers with 20,000, 30,000 40,000 employees. So that is the cost that they would pay. It is a sliding scale back from that cost. But, I mean, we've purposely priced ourselves to be reasonable. We are a mission-led company, and for any investors listening, don't worry; we are also revenue-generating. +CHAD: [laughs] +CHLOE: But for us, it's really important that we are an affordable benefit. We're very aware of the costs on everyone. So, for sure, that price is pretty low. But we think that it represents quite good value, incredible value for the client. But it's something that makes sense for them to bring on. It should be a no-brainer; that's basically what we say. Like, it's a no-brainer. In terms of the amount of freebies that you're getting for your employee, it's certainly a no-brainer in terms of the return on investment. +On the pro version, by the way, the added value on the pro version is that it's fully ring-fenced for that organization. So it's fully branded. They get full account management. It looks like their platform, essentially. And employees can talk and access the information together. So it might be that Bob in IT in Denver has uploaded a photo of himself cycling to work, and somebody else can comment on it. Somebody else has uploaded a curry recipe in Scotland, and someone else has gone, "Well, I tried that recipe." "But, you know, how was it? How much chili did you put in it?" +So people are kind of joining together and really creating that space to talk about sustainability in a much more accessible way. So that's the pro version. And also we're then building on sustainability metrics and also sustainability reporting. So we'll be able to talk about employees' own carbon footprint and also how that scales up to the overall company's sustainability goals. +CHAD: You mentioned that the mission is to help one million employees on their sustainability journey. Can you tell me where you are [laughs] along that metric? +CHLOE: Yeah. So, look, the app launch is tomorrow, so [laughs] ask me in a couple of months. And we're really...actually; we're genuinely new. +CHAD: You've been in private beta, I guess, is the way to describe it. +CHLOE: Yeah. We're basically with the MVP. We've been helping a couple of thousand employees up until this point. We got around 25,000. About 30-plus companies join our waiting list, which was then around 25,000-30,000 employees that represented. We've just confirmed that we're going to be launching with a very large retailer in the UK as well, so that will then -- +CHAD: Congratulations. +CHLOE: Thank you. That will then double, so it will be about 50,000 employees that we'll be hitting this year. And then we are in quite far down the line talks with quite a few other companies that would take us to potentially just under our target, which, by the way, the million employees is not like it's a target for 2022. It's like a...it's our ongoing mission. [laughs] +CHAD: Right, a long-term vision. +CHLOE: It's a long-term vision. So we're significantly further ahead than I thought we would be on that. I mean, look, what we've said from the start is the million is a sort of fairly arbitrary number but what it is is it's scale. So we're not here just to look after, you know, we're not here just to help very, very small companies; we can now with our free product, which is great, but it gives us that scale. +And it shows that we, as a business, want to be global, want to be talking to enterprise clients and then helping them live healthier, more sustainable lives. For us, it's both of those things. You can't just live a healthy life, and you can't just live a sustainable life. It needs to be a life of purpose. And so the mission really keeps us true to those things. +MID-ROLL AD: +Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. +Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff. +CHAD: You mentioned you have essentially three client bases: you have the employers, the employees, and the partners, which essentially means you have a multi-sided marketplace. +CHLOE: Yes. +CHAD: And one of the challenges of building any marketplace, especially the more sides you have, is bootstrapping it, you know, creating a momentum. The partners want to know, hey, how many people are on the platform that we're going to be bringing into? And in the early days, you don't have much to offer there. So how have you made that work? +CHLOE: Well, so firstly, we don't see ourselves as a marketplace, which we should. [laughter] We should see ourselves as a marketplace. Secondly, I learned all about building a marketplace because, in 2010, I launched a dating app before there were apps. Actually, it was a dating website...and completely on my own. It was complete madness. And I totally did not understand the power of a network. +I didn't understand the marketplace dynamic. I didn't understand that you needed buyers and you needed sellers. You needed, in this case, men seeking women and women seeking men. [laughs] You needed both sides of the equation. And you needed volume on both sides straight out of the gate. I just didn't get that. I was like, build it, and they will come. [laughs] And so I was fully burnt from that experience. So that was still ringing in my head. +So I think what was important was building up, firstly, building up our partners. So it was really, really important to build up the number of partners that we have on the platform. And for them, it's a completely low-risk strategy. It's like, come on the platform and offer discounts and people who are interested in sustainability. Like, that's really easy. We can do that. +And then for the companies, we've got everything...beyond the partners, we still have loads and loads of value. We still have value in the articles. We still have value in the gamification. We have value in the recipe. So there's still value even if there wasn't value in the perks. But what we've done is we've been able to build up both sides. +So actually, we've got over 200 brands, which represents about 45,000-plus individual discounts on the platform. And now we're building up the number of employees. Now we're able to revenue generate more off the partners because we've got the volume on the other side. +CHAD: You mentioned that you are primarily focused on the UK now. But you've had interest from the U.S. and demand that you've not rejected. What does that look like for you now? And how do you balance that going forward? +CHLOE: Yeah, I have got quite a lot of interest from the States. And it's really hard not to be pulled over there. And we see a lot of interest from there. We have to -- +CHAD: Why are you holding back? +CHLOE: Because we just don't have the team size at the moment, and we need to get the...there's two things really. Well, there are a number of things. There are about 22 things. [laughter] I know I said there are two things; there are like a million reasons. We need to make sure that we've got the best product possible; that's number one. We need to test in our home market. We need to make sure that we've got the robust mechanic with the Perk's partners and with the employees. We need to get all of that working really well because the States is a completely different market because of the nature of the products and services. We're not on the ground there. +So it's easier for us to have really good relationships with partners now. There's going to be a conference on Wednesday in London, so I'm going to be meeting a lot of our partners there; super easy. It's like 20 minutes on the train for me. Harder to go to the States and make sure that we have really robust relationships with partners there; not impossible, just it would be time and effort to be able to build it in the States. I think we'd be able to find the clients actually more easily or, I guess, quicker if that makes sense because I think there's a need in the States. +And then there are just cultural nuances. So we just need to make sure that all of our content is really relevant culturally. So PopSockets, we are with PopSockets in the States, and I think they're quite fairly near you in Boulder. So we are already aware of some of those cultural nuances. And our editorial teams are quite good at making sure that we're representing that. +So, yeah, so I think it's just about making sure that we do a good job of it. The hard thing, I think, is actually launching across Europe because of the language barrier and because of the very different cultural nuances when it comes to sustainability, local government policy. +CHAD: Also, expectations around employee benefits and how they work. +CHLOE: Exactly. Expectations around employee benefits and also attitudes to food as well because obviously food is still a part of what we do, and so all of those things actually make Europe slightly harder. So I think, for us, it would be a launch to the U.S. before we would go to continental Europe, but, again, not impossible. +Interestingly, our clients massively want us to be global quickly because they are all looking for global benefits. They want to be able to homogenize their benefits offerings globally. They do not want to have one thing being offered in the UK, something being offered in the States, especially when it comes to benefits. Things like pensions, things like healthcare are so different in those countries, and they won't change. Just in terms of how many holiday days you guys have versus us, they can't make it a level playing field on many things. +So if they could have a level playing field when it comes to sustainable benefits, they would love to do that. So there is a real need driving us to go global very quickly. And, look, going right back to the conversation we had at the beginning, I'd do it tomorrow. I'd move my family to the U.S. and just start building it. But my very kind advisors are like, slow down. [laughs] Get it right in the UK. +CHAD: Well, I think that is a good indicator that you do have a marketplace business because all of the pressures around scaling are the same ones that marketplaces have. +CHLOE: Yeah. [laughs] +CHAD: And marketplace businesses very often benefit from in the early days focusing on specific markets. +CHLOE: No, you're 100% right. I think I've had an epiphany on this podcast [laughter] that I'm running a marketplace. +CHAD: I want to come back to the actual tech of the product as we wrap up here. I'm super impressed that you used a low-code platform to build the MVP yourself, and that has taken you through today. So how did you go about moving beyond that? +CHLOE: [laughs] So we always knew we'd have to ditch it, so we were very aware. And that's the beauty of doing an MVP which is you don't fall in love with it. So that was great because we knew we were going to ditch it. We didn't fall in love with it. So how did we go about it? So we've got ourselves...we got a CTO on board that Ellen had worked with before. And we've got an amazing UX-UI designer. And we've got some devs. +And we just ran at it. We just said, right, what are we taking from the MVP that we want to put into...and we knew it had to be an app really quickly. We actually weren't going to develop the app this year, but then it was sort of, you know, the demand there was all for the app. So we've gone app first. So we just said, "What's important from the MVP that we want to be taking here?" +We knew that perks was going to be the first thing that we wanted to launch with because of the cost of living crisis. And we wanted to make it really about perks, which is why I know it sounds silly when it's obvious to you that we're a marketplace. It actually isn't that obvious to us because before perks, none of those things are marketplace. All of the other products and services that we offer aren't marketplace. +CHAD: You mean the content and that kind of thing. +CHLOE: The content, the gamification. We've got a whole thing coming down the line all about how to calculate your carbon footprint. Like, none of that is marketplace. But because we've really leant heavily on the perks because we know that there's a massive need for that, I guess that's why it's a surprise to me [laughs] that we're a marketplace. But yeah, so we knew we wanted to get perks out first. +So then we built a product with perks at the heart because that was testing really well. And then yeah, and then we've just kind of literally just gone hell for leather head down. The team has been in build mode. We've been in sell mode and creation mode. And, yeah, we've just gone really, really fast. It's not in our natures to sort of go slow on these things. And we just need to be out there. People love what we're doing. And now it's the real test. Now it's literally employees now getting access to it, and that's the scary time. +CHAD: Has it been what you expected actually, you know, building custom software in terms of time, and cost, and that kind of thing? Or has it been different than what you expected? +CHLOE: Yeah, that's a good question. So I guess over the years, I've had the opportunity to build products internally in companies. You're always in a waiting list for other people that need other stuff. So in a way, it's been quicker because it's my team, and they've got nothing else to concentrate on except this. +I'm really open with what I don't know. So I'm like, okay, could I do, just out of interest, how easy is it for us to switch off that function and launch this? Is it a week? Is it a month? Is it like a year? Like, I just have no idea on timings and scale on that. So I try to work that out quite quickly. +But I think it's been quicker than I thought it might be. And if you've got an internal team, then it's cheaper. As soon as we started to look at external teams, it was prohibitively expensive and no control. And I think we knew quite early on that we wanted to build it internally. +CHAD: How has it compared to the process of using the low-code tool to get started? +CHLOE: [laughs] In a way, if I had an idea, it was up and live an hour later...[laughs] and, you know, I guess there's much more pushback now. It's like, "Do you really need that feature?" And I'm like, "Yeah, you know, just do it. What's so difficult?" So I guess I've had to put more rigor and thinking behind some of the features and functions that we now have versus just sticking it up there. +I mean, look, we were really, really frustrated with low-code. We were really frustrated with what it could do. It is so limited really in what we were trying to do, but it got us to a certain point. I'll always be forever grateful to it. [laughs] And my partner and I were able to completely tag team on it. So I would do all of the front end, and she'd do all the back end. It worked really well from that perspective. +But we've got a great team now who are really engaged in what we're trying to do and trying to achieve. I guess I want everything yesterday. So as with most things, I'm getting updates going, "This is broken, and I'm having to turn this off for the launch." And I'm like, "No, I want it there. I want it in there." +CHAD: So, on that note, why do you have a specific launch date? +CHLOE: We've got a client we're launching to next week. [laughter] So we're launching -- +CHAD: So you've made a commitment to launch for a particular client, and so you need to hit that date. +CHLOE: Yeah. We are. We're launching it to...yeah, we've got quite a lot of clients, actually. We've got launches almost every day from next week. So this week is friends and family launch. So we need to get it out and get it tested. And then it goes into the hands of real-life users, which is scary and interesting. +CHAD: I wish you all the best with that. I really appreciate you taking the time. +CHLOE: Any advice? +CHAD: Well, what I was going to say is a question I often like to ask. And I'm curious, before launch, is there something that you wish you could have done differently or realized sooner? I'm sure this question might be different post-launch. The answer to this question might be different post-launch. But from where you sit today, is there something that you wish you would have done differently? +CHLOE: Oh my God. I almost want to say everything and nothing. I don't want to go, no, I don't regret anything; everything's been a learning experience, [laughs] so there's nothing I would have done differently because it's all led me to this point. But then, on the other hand, I think we've made the right decisions with the data that we've had. I think we need to...there's stuff that we need to be doing much more rigorously now moving forwards, which is making sure that we are very, very data-driven with what's coming back. +Now we're in the hands of real users in a meaningful way with the app. We need to be taking all of that feedback on and not just relying on the gut instinct with a lot of things. It needs to be much more data-driven now that we've got the data coming in. So I don't think that's a regret necessarily because I think you've got to kind of go with your gut to get a product out the door because you could be completely hamstrung by research. And that would have taken us into a whole nother territory. So I think...does that make sense? So whilst I'm not regretting but like -- +CHAD: It does make sense. And you asked me for any advice that I have. And this is a very small piece of advice, but it's one thing that I've made the mistake of myself and seen many other teams do. If you want to seek metrics on something and you don't instrument it, you don't set up those metrics; then you don't have them. +CHLOE: So true. +CHAD: And you realize, oh, we should have been tracking this click, or that click, or this flow. And then you put it in place once you realize that it's not there, and you have to wait 30-60 days in order to get the data. And that time feels terrible while you're waiting for that data to accrue. +And so my general advice is to instrument basically everything. Instrument as much as possible, even if you think you're not going to need it. Track as many clicks as possible in the app so that you can really then say, oh, we didn't know we wanted to track this flow. And you already have the data where you can piece it together instead of waiting. +CHLOE: Yeah, 100%. So we were challenged by...so we're backed by sustainable ventures on the accelerator program. And we were challenged by them to make sure that we've got all of our KPI metrics in place for the product. Of course, we've just been head down building it. And actually, it was a great moment where it's kind of like, but how many points do you want your users to collect in a day? Maybe there's an upper limit that you want, which we hadn't really thought about. Well, I don't know; we just want them to collect points. Like, you know, we want them to live their best life. +And so in setting the KPIs, we've also had to set what we're measuring, but it was like two pages long. [laughs] There are so many things that we're trying to...what our KPIs are. And I think we can also...I think a learning is that maybe we need to be a little bit more focused with also what we're trying to measure and also what we were trying to see because we, again, can't focus on everything. We can't update and upgrade and iterate absolutely everything as a priority. +What's going to shift the dial the most? What's going to have the biggest impact? Yes, we can change the color of that, or we can make that button bigger. But actually, if that's not going to lead to the KPI that we're trying to measure, then actually, there's no point. So yeah, so I think that's been a learning as well. I mean, there are so many thousands, billion learnings on this whole journey. [laughs] I could write a book. I don't think anyone will read it, but I could definitely write a book. [laughter] And I don't have time to write it. If I had time to write it and if anyone wants to read it, I'll do it. [laughs] +CHAD: Okay. Well, maybe a few years from now, you can write that book. +CHLOE: Yeah. +CHAD: And, Chloe, thank you so much for joining the show and for telling us all about your journey. I really wish you and Plants and Perks the best over these important next couple of months. +CHLOE: Thank you. We're raising, by the way. We're just about to go into our seed round, so yeah. +CHAD: Seed round. +CHLOE: Yeah. +CHAD: Perfect. +CHLOE: I know, perfect for Plants and Perks. That's the next inflection point whilst obviously also launching an app. And we don't do things by halves, so that will be the next learning journey. +CHAD: If folks want to find out more, to follow along with you, to get in touch with the company, where are all the different places that they can do that? +CHLOE: Don't look at the website because we're in the process of updating that. [laughter] And, frankly, now I'm going to change the pricing after this conversation. [laughs] But yeah, no, don't do that. Just email me; it's the easiest way. Or find me on LinkedIn; LinkedIn is probably the number one way. Or email chloe@plantsandperks.com. I love; literally, I love hearing feedback: negative, positive, anything. I love having conversations. I love doing partnerships. I love helping people on their journeys; just reach out. +CHAD: Wonderful. +And you can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Chloe Sweden. + + + Chloe Sweden is the Founder and CEO of Plants and Perks, a service for rewarding employees with sustainable perks.

+ +

Chad talks to Chloe about supporting employees on plant-based sustainability journies by gifting free samples and high-value prizes, choosing a co-founder, and being strategic with the types of businesses they've approached.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Chloe Sweden, the Founder, and CEO of Plants and Perks, a service for rewarding employees with sustainable perks. Chloe, thank you so much for joining me.

+ +

CHLOE: Thank you for having me.

+ +

CHAD: So you officially started Plants and Perks, at least according to your LinkedIn, in July of 2020. But I'm sure, like many entrepreneurs, you incubated the idea. The idea was in your head for longer than that. So, where does the idea from Plants and Perks come from? And when did you start to noodle it?

+ +

CHLOE: It's a really, really good question. I also think that the LinkedIn algorithm isn't 100% correct.

+ +

CHAD: [laughs]

+ +

CHLOE: And it always seems to add time. I always get this sort of like, "Oh my God, you've been doing this for like two years?" I'm like, "No, I'm sure it can't be. It must be shorter than that." So Plants and Perks, Plants and Perks originally started out life as the Green Shoot Institute, which, I think, if you Google us, still there's remnants of the Green Shoot Institute that exists. That is still our company holding name. And that was kind of, I guess, the first thought of the idea.

+ +

I was at the time heading up commercial relationships at a large parenting platform in the UK. And we had started to go on our own plant-based journey, so thinking about cutting back on meat and dairy consumption. I guess that was sort of my own personal journey that started to make me, as a parent, and as a consumer, and as a senior leader within business to, start to think about things outside of myself, and my family, and my business. And really, that was kind of the spark of thinking about how we, as employers, don't really do much to support employees on the plant-based sustainability journey. That was the sort of the embryo of the idea.

+ +

And that came from the fact that I had spent 20 years of my life in advertising, marketing, and then ten years within that in talent as a former head of talent and culture really thinking about how we embed talent and how we help employees, and how culture is so important to businesses, and how we get employees really to be the face of our brands. But we don't really do much to invest in people beyond the kind of traditional benefits that exist but also in terms of training and things like that.

+ +

That was kind of where things were coming together, sort of thinking about the future of work and thinking about how people go through these huge life moments and how the businesses really support them. So that was kind of the start. I won't give the whole game away, but that was, I guess, the beginning of a kind of, hmm, there's something there. And I didn't really know what it was at the time.

+ +

But yeah, I guess it wasn't so much before I actually incorporated the company. I incorporated in September 2020. That's what it says on my Company's House printout that I have on the wall just to remind me of when that momentous day happened. But pretty quickly, from coming up with an idea, I incorporated the business and just went, this is something I have to do.

+ +

CHAD: Yeah, the feeling of this is something I have to do is something that I've felt myself and that I hear from a lot of entrepreneurs and guests of the show. You were working at Mumsnet at the time. How did you start while also having another job?

+ +

CHLOE: Not just having another job, running a large sales team, and homeschooling two children during a pandemic.

+ +

CHAD: Oh, homeschooling. Okay, yeah.

+ +

CHLOE: And my son was definitely diagnosed with having additional needs at the time as well. I guess it was all of those things that kind of came together that made me realize, I mean, I had joined Mumsnet actually to head up Mumsnet's talent function, which was all about creating a flexible working product platform for parents and those looking for flexible jobs to bring them together in a marketplace. But Mumsnet wasn't going to actually continue to invest in that product, and I moved to a more commercial role.

+ +

But I moved there to build a product. And that's what really triggered it for me. I realized in that moment when I'm homeschooling, and I'm running a large sales team, and I'm doing all of these things, that wasn't why I moved to this role. I actually moved because I'm at the point in my career where I want to build something, that I have it in me to create something, and build, and connect people, and do something bigger than myself and bigger than a day-to-day job. And so that itch was there.

+ +

I was also, as part of that role, going out and speaking to heads of HR in large enterprise organizations and talking to them about what was troubling them. And funny enough, looking after their working parents was not troubling them, but sustainability came up a lot, and general well-being came up a lot. And so that was kind of, I guess, it started the percolation. But really, I guess with most things, the idea came about in its most embryonic stage, and then I took it to market really quickly. I basically gave it a name and then just reached out on LinkedIn to anybody I knew and people I didn't know as well just literally reached out to those people.

+ +

And I spoke to one person who I won't name her or the company but probably one of the largest global companies in the world and at a very senior level. And she was actually working out of the States. And she said to me, you know, "This is new. [laughs] You need to do this. Nobody is doing this. We need this in our lives. And I haven't heard of anybody doing this in the States. You need to go and build this." And that was, I guess, the impetus to do it.

+ +

And so I worked weekends. I actually was working four days a week at Mumsnet. But my fifth day, I was working full time for Mumsnet but not being paid. And so I clawed back my fifth day where I wasn't being paid, and I worked all weekends, and I worked all evenings. And I just worked and worked, and I haven't stopped until this conversation. [laughs]

+ +

CHAD: To actually work on it, did you start to gather a team, a group of people? Who were the first people that you brought on to help you?

+ +

CHLOE: So my co-founder, Ellen, we were on the senior leadership team of a creative agency. I was the head of talent and culture. She was the head of operation. So we had worked side by side in this organization. So we kept in touch. And she had contacted me about some health issues. And we were talking about cutting back on meat and dairy as one of the things that she could look at, given my own experiences with it. And that really bonded us.

+ +

And because I am marketing, sales, creative, and she is digital, tech, product, it kind of made sense, in the beginning, to bring her on. And I just said to her like, "I'd really like you on this journey with me." And she resisted it for quite some time. [laughs] We are very different personality-wise, very, very different. I'm yes, she's no, and so in that way, we're very much yin and yang.

+ +

CHAD: Oh, but I think that that can be the perfect combination for a co-founder team. I know that I've needed that in the past for myself. Someone who balances the risk-taking with reality can be very helpful.

+ +

CHLOE: Yeah, absolutely. And I think I'm actually not a risk taker, but I am a natural optimist. And so I'll have a meeting, and I'll be like, "It's amazing. It's solved all of our problems." And she'll be just like, "No, it hasn't. What's changed? Nothing's changed. There's no contract, nothing signed," [laughs] which I think in the moment is really not helpful. [laughs] But it's really helpful as we grow the business. It really is a good balance.

+ +

I bring all of that energy and drive to get us very quickly to the next level. And she brings all of the understanding, all of the pauses, all of the rigor, all of the data, all the things that are just the complete opposite of me. So I brought her on pretty quickly. And then we had a bit of a false start around getting a CTO on board. But we knew we needed to build the product quickly. And in the end, we built the product ourselves on a no-code/low-code platform, just the two of us. And I recommend any entrepreneur to do that because you learn a lot. [laughs]

+ +

CHAD: Is that the reason...so you learning...because I think that that is super important, whether it be someone like yourself actually building the product or just being very close to it. When I've seen entrepreneurs get too far away from the product too soon, they end up regretting it later on.

+ +

CHLOE: Yeah, I think --

+ +

CHAD: Or building the wrong thing.

+ +

CHLOE: Or building the wrong thing. I do really believe in you've got to do every job in order to then understand who you need to hire and to then have an appreciation of that role. So obviously the product evolved very much and very quickly. We were very lucky that one of our first clients was Lacoste, who we launched to here in the UK with our MVP. But we also did some other paid consultancy work with Uber and with other clients as well. And then PopSockets came on in the States as well. We weren't ready to launch in the States, but they really wanted us to. So we're like, you know, let's do it. [laughs]

+ +

CHAD: I noticed those three names on your website. And I do think that social...being able to have those testimonials there with names people recognize lends a lot of credibility to the product.

+ +

CHLOE: And they were my first three clients, [laughs] genuinely my first three clients.

+ +

CHAD: So, did you seek that out, or did it just happen? How did that work out?

+ +

CHLOE: Obviously, my background is commercial sales, so it's not something that I shy away from. It was connections; it was talking to people. And we were recommended to PopSockets, which was amazing. They came on as an early investor as well, which was phenomenal. Again, having clients who love what you do so much they want to invest is brilliant because you get to have some really interesting conversations and backers in your corner.

+ +

But yeah, of course, we've been quite strategic with the types of businesses that we've approached, but we are very lucky that we are attracting the right type of businesses as well, which is lovely. I mean, talk a little bit more about what Plants and Perks does, but the way in which we have evolved the product and evolved the types of clients that we're talking to is not an accident. And I think it goes back to the conversation we were just having about building the product yourself. Really being in the weeds, I think, is really important.

+ +

Now, it's going to be a challenge to me as a founder moving forward to make sure I'm extricating myself from the weeds as time goes on, although I'm pretty happy to step away when needed. [laughs] But knowing that and being able to talk to your clients and being really clear, well, this is what this client likes; this is what's happening here; this is what's working well here, I think is really important. You've got to know your product. You've got to know your audience.

+ +

We've got two...actually, we have three clients, technically. We have clients; we have employees; we have client employers; we have employees; and we also have Perks' partners. We have sustainable...we promote sustainable products and services on our platform. So we also have partners as well as our clients. And I think you've got to know them all really well.

+ +

Now, I was a head of talent and culture, so I know the employee piece quite well because I was always advocating for the employee. I spent 20 years downsizing, so I ran client accounts. So I know how to look after clients, I guess, from that perspective and work in large organizations. I also used to literally do the marketing for PepsiCo and Wrigley's and big brands. So I can do the partner piece quite well. And I think it's really important that you've done that and you've lived through it.

+ +

And I've never built a tech product, but I did literally roll my sleeves up and get stuck in to build the MVP, which was kind of the bit that I was missing. Now, I haven't built the app; that is beyond me. [laughs] But luckily, we've got a brilliant team around us now, which we've built up since our last raise that's enabled us to get that talent in. And yeah, and it's just been an amazing team effort to get us to where we are now.

+ +

CHAD: That's great. I want to dig into more about what the product actually is. But you've already alluded a couple of times --

+ +

CHLOE: No, let's keep it mysterious.

+ +

[laughter]

+ +

CHAD: You've alluded a few times to the evolution. And one thing that's stuck out to me as you were talking about that is that going to the website now; it's not specifically about eating less meat and dairy. You're talking more about sustainability.

+ +

CHLOE: Yes.

+ +

CHAD: I'm sure that's still a component of it.

+ +

CHLOE: 100%.

+ +

CHAD: But what drove that change?

+ +

CHLOE: Oh my God, [laughs] about a two-week period where we had an existential crisis. I think this is really interesting, I think, for our journey, and I think us as founders as well. So we ideologically always believed in the reduction of meat and dairy as the number one thing you can do for personal and planetary health. That's it. Like, that was it.

+ +

We were all about eat plants, get perks. We encourage employees to cut back on their meat and dairy consumption, and we reward them with plant-based perks. That was the product. That was the concept. Tested really well. People really bought into it. People liked that they were being rewarded with perks. They absolutely understood that it is unsustainable to consume meat and dairy in the way that we are moving forward for the planet and also for personal health.

+ +

So when we're having these conversations, everyone was like, thumbs up, get it, love it, buy into it, it's all great. And then what was happening is that I kind of got to a point where I was like, we've had all these really positive conversations, but no one's biting. Everyone's sort of saying yes to me and then nothing.

+ +

I'm actually really proud of us as a team for very, very quickly going and identifying the problem and fixing it because we could have stuck to our ideological guns and gone, no, no, no, but we are all about the reduction of meat and dairy consumption as the number one thing. But no one was telling us that it was that that was the problem.

+ +

What we had to do was read between the lines because nobody would ever tell us that. But what they would say was, "Well, how would it land with a 58-year-old man working in our distribution center?" And we're like, "Really well, why?" [laughter] But I had to understand what was coming behind that question. And what was coming behind the question was I don't want to launch a benefit where I feel like we're judging somebody's life choices. Like, that's not going to wash.

+ +

So the people we were talking to were super keen on it, then when they took it up the line, they were essentially saying, "Well, this is a plant-based benefit, Plants and Perks." And I think that's where the sort of record scratched, and it didn't go any further. But no one was feeding this back to us. This we had to discover ourselves.

+ +

And so we had this kind of existential crisis where we're like, well, we've always been about sustainability, like, absolutely the reduction in meat and dairy is all because it's unsustainable for us to consume meat and dairy and fish in the way that we are. So why don't we broaden ourselves out to more? We already held sustainable products and services on our platform anyway. It was just the language; it really was. It wasn't actually as big a pivot as it sounded. It really was just softening the language.

+ +

So we don't talk about plant-based; we talk about planet-friendly. And we just kind of expanded out some of the articles and content that we contained anyway. And that unblocked everything, like genuinely overnight unblocked everything. So it became something that what we were hearing was that companies wanted to introduce a new green benefit, and now they felt that they could because there wasn't the kind of...and we always said that this is non-judgmental. This is completely supportive. These are very small changes that you could make. You don't have to sort of introduce me to it.

+ +

But now it makes sense to everybody. And I think we as a business just needed to go through that moment where we were like, is this the type of business that we want to be running? Is this the business that we want to be owning? And we were like, absolutely, because this is still...our mission actually didn't change at all. Our mission is to help a million employees live healthier, more sustainable lives. That has not changed. And so the fact that our mission hadn't changed, it was just some of the language needed to change to make it more palatable to a wider audience, that's fine. We could live with that.

+ +

CHAD: Yeah, that's great. So now, what does that actually mean in terms of what the product is? Companies sign up.

+ +

CHLOE: Yep.

+ +

CHAD: And what do employees do?

+ +

CHLOE: Yeah, so it's a really good question. So the other sort of big moment, I guess, inflection point that we had is that we introduced a freemium model. And that, from a product perspective, was quite a big thing because I started realizing in conversations as well we were giving too much value away. And actually, some of the value that we were giving away clients didn't necessarily want. Some clients really wanted it, and some clients didn't need it.

+ +

And so we introduced three different products. So we introduced free, so we now have a completely free Plants and Perks app that any employer can take on for their employee base. And it will give them discounts of sustainable products and services. It will give them article content on how to live more sustainably, embrace more sustainable living. And it will give them planet-friendly recipes on essentially more sustainable, healthy ways to eat. And that's the core free product that we've created.

+ +

CHAD: And are you still making revenue on that through partner relationship?

+ +

CHLOE: Yeah, absolutely. So, although, you know, we're not about excess consumption. What we are about is...I think what we really realized is with Plants and Perks; we are bang smack in the middle of a cost of living crisis. And actually, what we can do is level the playing field when it comes to green and sustainable products.

+ +

There's kind of like this green tax that gets applied. And what we're trying to do is very much look at price parity. So what we talk about is it's harder than ever to make the most sensible choices when costs are spiraling all around us. And so what the reductions of planet-friendly products does is enables you to just try things that you might not have tried before because of cost, and it mitigates against that.

+ +

So we do go into relationship with partners, and they can promote their products through the platform. But there are also chances for employees to put their reviews and tell them what they think. So it isn't just set up for advertisers in that way at all. But what we found is there's an amazing thing which is that brands need to connect with a new, wider audience. They don't just want to talk to early adopters within the sustainability or plant-based space. And we are talking to every man and every woman in large-scale organizations.

+ +

So it's actually quite difficult to access those people if you're these niche brands who may not even have listings necessarily in large retailers yet. Or if you do have distribution, it's really difficult to get a sell-through. So we enable those partners to offer sampling, to offer freebies, to offer significant discounts, and to offer in-store redemptions as well. So we are offering quite a significant route to market for sustainable and plant-based products and services.

+ +

CHAD: That's great. Okay, and so what is the second tier up?

+ +

CHLOE: The second tier is plus and what that gives you is we start to give employees plant points, and you collect plant points. It's incredibly gamified. You can collect badges. Every action you do basically has a reaction. So when you read an article, you basically can answer some questions on the article, and you'll be rewarded with points. You can rate a recipe; you can like a recipe, try a recipe. You can buy a product or a service. You can also get a free...in the UK, at the moment, you'll be able to get a free meal once a week, like a free lunch through one of our partners, and loads of freebies as well.

+ +

So the value is much more significant in the plus model. That's kind of our core offering. And we talk about rewarding employees with sustainable perks. And during the time at the moment, employers are really looking for ways in which they can support their employees through the cost of living crisis. How can we give our employees free stuff, interesting stuff, whilst also helping them on the sustainability journey? And so therefore, this is something that genuinely really works for both employers and employees. So that's the plus model.

+ +

CHAD: One thing I noticed as you lay out the benefits that you get under this model, I'm surprised then by the per-employee cost. It seemed very low to me [laughs] when I saw it. Can you talk more about that?

+ +

CHLOE: Yeah, so that is a from price. And I do think I need to make it; I mean, I do say it's from, and I think I do say there's a bit of an asterisk. I do think I need to potentially change it as well. So it's good [laughs] feedback because I think quite a few people say that. So that is for large-scale employers. So we are talking to large retailers with 20,000, 30,000 40,000 employees. So that is the cost that they would pay. It is a sliding scale back from that cost. But, I mean, we've purposely priced ourselves to be reasonable. We are a mission-led company, and for any investors listening, don't worry; we are also revenue-generating.

+ +

CHAD: [laughs]

+ +

CHLOE: But for us, it's really important that we are an affordable benefit. We're very aware of the costs on everyone. So, for sure, that price is pretty low. But we think that it represents quite good value, incredible value for the client. But it's something that makes sense for them to bring on. It should be a no-brainer; that's basically what we say. Like, it's a no-brainer. In terms of the amount of freebies that you're getting for your employee, it's certainly a no-brainer in terms of the return on investment.

+ +

On the pro version, by the way, the added value on the pro version is that it's fully ring-fenced for that organization. So it's fully branded. They get full account management. It looks like their platform, essentially. And employees can talk and access the information together. So it might be that Bob in IT in Denver has uploaded a photo of himself cycling to work, and somebody else can comment on it. Somebody else has uploaded a curry recipe in Scotland, and someone else has gone, "Well, I tried that recipe." "But, you know, how was it? How much chili did you put in it?"

+ +

So people are kind of joining together and really creating that space to talk about sustainability in a much more accessible way. So that's the pro version. And also we're then building on sustainability metrics and also sustainability reporting. So we'll be able to talk about employees' own carbon footprint and also how that scales up to the overall company's sustainability goals.

+ +

CHAD: You mentioned that the mission is to help one million employees on their sustainability journey. Can you tell me where you are [laughs] along that metric?

+ +

CHLOE: Yeah. So, look, the app launch is tomorrow, so [laughs] ask me in a couple of months. And we're really...actually; we're genuinely new.

+ +

CHAD: You've been in private beta, I guess, is the way to describe it.

+ +

CHLOE: Yeah. We're basically with the MVP. We've been helping a couple of thousand employees up until this point. We got around 25,000. About 30-plus companies join our waiting list, which was then around 25,000-30,000 employees that represented. We've just confirmed that we're going to be launching with a very large retailer in the UK as well, so that will then --

+ +

CHAD: Congratulations.

+ +

CHLOE: Thank you. That will then double, so it will be about 50,000 employees that we'll be hitting this year. And then we are in quite far down the line talks with quite a few other companies that would take us to potentially just under our target, which, by the way, the million employees is not like it's a target for 2022. It's like a...it's our ongoing mission. [laughs]

+ +

CHAD: Right, a long-term vision.

+ +

CHLOE: It's a long-term vision. So we're significantly further ahead than I thought we would be on that. I mean, look, what we've said from the start is the million is a sort of fairly arbitrary number but what it is is it's scale. So we're not here just to look after, you know, we're not here just to help very, very small companies; we can now with our free product, which is great, but it gives us that scale.

+ +

And it shows that we, as a business, want to be global, want to be talking to enterprise clients and then helping them live healthier, more sustainable lives. For us, it's both of those things. You can't just live a healthy life, and you can't just live a sustainable life. It needs to be a life of purpose. And so the mission really keeps us true to those things.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff.

+ +

CHAD: You mentioned you have essentially three client bases: you have the employers, the employees, and the partners, which essentially means you have a multi-sided marketplace.

+ +

CHLOE: Yes.

+ +

CHAD: And one of the challenges of building any marketplace, especially the more sides you have, is bootstrapping it, you know, creating a momentum. The partners want to know, hey, how many people are on the platform that we're going to be bringing into? And in the early days, you don't have much to offer there. So how have you made that work?

+ +

CHLOE: Well, so firstly, we don't see ourselves as a marketplace, which we should. [laughter] We should see ourselves as a marketplace. Secondly, I learned all about building a marketplace because, in 2010, I launched a dating app before there were apps. Actually, it was a dating website...and completely on my own. It was complete madness. And I totally did not understand the power of a network.

+ +

I didn't understand the marketplace dynamic. I didn't understand that you needed buyers and you needed sellers. You needed, in this case, men seeking women and women seeking men. [laughs] You needed both sides of the equation. And you needed volume on both sides straight out of the gate. I just didn't get that. I was like, build it, and they will come. [laughs] And so I was fully burnt from that experience. So that was still ringing in my head.

+ +

So I think what was important was building up, firstly, building up our partners. So it was really, really important to build up the number of partners that we have on the platform. And for them, it's a completely low-risk strategy. It's like, come on the platform and offer discounts and people who are interested in sustainability. Like, that's really easy. We can do that.

+ +

And then for the companies, we've got everything...beyond the partners, we still have loads and loads of value. We still have value in the articles. We still have value in the gamification. We have value in the recipe. So there's still value even if there wasn't value in the perks. But what we've done is we've been able to build up both sides.

+ +

So actually, we've got over 200 brands, which represents about 45,000-plus individual discounts on the platform. And now we're building up the number of employees. Now we're able to revenue generate more off the partners because we've got the volume on the other side.

+ +

CHAD: You mentioned that you are primarily focused on the UK now. But you've had interest from the U.S. and demand that you've not rejected. What does that look like for you now? And how do you balance that going forward?

+ +

CHLOE: Yeah, I have got quite a lot of interest from the States. And it's really hard not to be pulled over there. And we see a lot of interest from there. We have to --

+ +

CHAD: Why are you holding back?

+ +

CHLOE: Because we just don't have the team size at the moment, and we need to get the...there's two things really. Well, there are a number of things. There are about 22 things. [laughter] I know I said there are two things; there are like a million reasons. We need to make sure that we've got the best product possible; that's number one. We need to test in our home market. We need to make sure that we've got the robust mechanic with the Perk's partners and with the employees. We need to get all of that working really well because the States is a completely different market because of the nature of the products and services. We're not on the ground there.

+ +

So it's easier for us to have really good relationships with partners now. There's going to be a conference on Wednesday in London, so I'm going to be meeting a lot of our partners there; super easy. It's like 20 minutes on the train for me. Harder to go to the States and make sure that we have really robust relationships with partners there; not impossible, just it would be time and effort to be able to build it in the States. I think we'd be able to find the clients actually more easily or, I guess, quicker if that makes sense because I think there's a need in the States.

+ +

And then there are just cultural nuances. So we just need to make sure that all of our content is really relevant culturally. So PopSockets, we are with PopSockets in the States, and I think they're quite fairly near you in Boulder. So we are already aware of some of those cultural nuances. And our editorial teams are quite good at making sure that we're representing that.

+ +

So, yeah, so I think it's just about making sure that we do a good job of it. The hard thing, I think, is actually launching across Europe because of the language barrier and because of the very different cultural nuances when it comes to sustainability, local government policy.

+ +

CHAD: Also, expectations around employee benefits and how they work.

+ +

CHLOE: Exactly. Expectations around employee benefits and also attitudes to food as well because obviously food is still a part of what we do, and so all of those things actually make Europe slightly harder. So I think, for us, it would be a launch to the U.S. before we would go to continental Europe, but, again, not impossible.

+ +

Interestingly, our clients massively want us to be global quickly because they are all looking for global benefits. They want to be able to homogenize their benefits offerings globally. They do not want to have one thing being offered in the UK, something being offered in the States, especially when it comes to benefits. Things like pensions, things like healthcare are so different in those countries, and they won't change. Just in terms of how many holiday days you guys have versus us, they can't make it a level playing field on many things.

+ +

So if they could have a level playing field when it comes to sustainable benefits, they would love to do that. So there is a real need driving us to go global very quickly. And, look, going right back to the conversation we had at the beginning, I'd do it tomorrow. I'd move my family to the U.S. and just start building it. But my very kind advisors are like, slow down. [laughs] Get it right in the UK.

+ +

CHAD: Well, I think that is a good indicator that you do have a marketplace business because all of the pressures around scaling are the same ones that marketplaces have.

+ +

CHLOE: Yeah. [laughs]

+ +

CHAD: And marketplace businesses very often benefit from in the early days focusing on specific markets.

+ +

CHLOE: No, you're 100% right. I think I've had an epiphany on this podcast [laughter] that I'm running a marketplace.

+ +

CHAD: I want to come back to the actual tech of the product as we wrap up here. I'm super impressed that you used a low-code platform to build the MVP yourself, and that has taken you through today. So how did you go about moving beyond that?

+ +

CHLOE: [laughs] So we always knew we'd have to ditch it, so we were very aware. And that's the beauty of doing an MVP which is you don't fall in love with it. So that was great because we knew we were going to ditch it. We didn't fall in love with it. So how did we go about it? So we've got ourselves...we got a CTO on board that Ellen had worked with before. And we've got an amazing UX-UI designer. And we've got some devs.

+ +

And we just ran at it. We just said, right, what are we taking from the MVP that we want to put into...and we knew it had to be an app really quickly. We actually weren't going to develop the app this year, but then it was sort of, you know, the demand there was all for the app. So we've gone app first. So we just said, "What's important from the MVP that we want to be taking here?"

+ +

We knew that perks was going to be the first thing that we wanted to launch with because of the cost of living crisis. And we wanted to make it really about perks, which is why I know it sounds silly when it's obvious to you that we're a marketplace. It actually isn't that obvious to us because before perks, none of those things are marketplace. All of the other products and services that we offer aren't marketplace.

+ +

CHAD: You mean the content and that kind of thing.

+ +

CHLOE: The content, the gamification. We've got a whole thing coming down the line all about how to calculate your carbon footprint. Like, none of that is marketplace. But because we've really leant heavily on the perks because we know that there's a massive need for that, I guess that's why it's a surprise to me [laughs] that we're a marketplace. But yeah, so we knew we wanted to get perks out first.

+ +

So then we built a product with perks at the heart because that was testing really well. And then yeah, and then we've just kind of literally just gone hell for leather head down. The team has been in build mode. We've been in sell mode and creation mode. And, yeah, we've just gone really, really fast. It's not in our natures to sort of go slow on these things. And we just need to be out there. People love what we're doing. And now it's the real test. Now it's literally employees now getting access to it, and that's the scary time.

+ +

CHAD: Has it been what you expected actually, you know, building custom software in terms of time, and cost, and that kind of thing? Or has it been different than what you expected?

+ +

CHLOE: Yeah, that's a good question. So I guess over the years, I've had the opportunity to build products internally in companies. You're always in a waiting list for other people that need other stuff. So in a way, it's been quicker because it's my team, and they've got nothing else to concentrate on except this.

+ +

I'm really open with what I don't know. So I'm like, okay, could I do, just out of interest, how easy is it for us to switch off that function and launch this? Is it a week? Is it a month? Is it like a year? Like, I just have no idea on timings and scale on that. So I try to work that out quite quickly.

+ +

But I think it's been quicker than I thought it might be. And if you've got an internal team, then it's cheaper. As soon as we started to look at external teams, it was prohibitively expensive and no control. And I think we knew quite early on that we wanted to build it internally.

+ +

CHAD: How has it compared to the process of using the low-code tool to get started?

+ +

CHLOE: [laughs] In a way, if I had an idea, it was up and live an hour later...[laughs] and, you know, I guess there's much more pushback now. It's like, "Do you really need that feature?" And I'm like, "Yeah, you know, just do it. What's so difficult?" So I guess I've had to put more rigor and thinking behind some of the features and functions that we now have versus just sticking it up there.

+ +

I mean, look, we were really, really frustrated with low-code. We were really frustrated with what it could do. It is so limited really in what we were trying to do, but it got us to a certain point. I'll always be forever grateful to it. [laughs] And my partner and I were able to completely tag team on it. So I would do all of the front end, and she'd do all the back end. It worked really well from that perspective.

+ +

But we've got a great team now who are really engaged in what we're trying to do and trying to achieve. I guess I want everything yesterday. So as with most things, I'm getting updates going, "This is broken, and I'm having to turn this off for the launch." And I'm like, "No, I want it there. I want it in there."

+ +

CHAD: So, on that note, why do you have a specific launch date?

+ +

CHLOE: We've got a client we're launching to next week. [laughter] So we're launching --

+ +

CHAD: So you've made a commitment to launch for a particular client, and so you need to hit that date.

+ +

CHLOE: Yeah. We are. We're launching it to...yeah, we've got quite a lot of clients, actually. We've got launches almost every day from next week. So this week is friends and family launch. So we need to get it out and get it tested. And then it goes into the hands of real-life users, which is scary and interesting.

+ +

CHAD: I wish you all the best with that. I really appreciate you taking the time.

+ +

CHLOE: Any advice?

+ +

CHAD: Well, what I was going to say is a question I often like to ask. And I'm curious, before launch, is there something that you wish you could have done differently or realized sooner? I'm sure this question might be different post-launch. The answer to this question might be different post-launch. But from where you sit today, is there something that you wish you would have done differently?

+ +

CHLOE: Oh my God. I almost want to say everything and nothing. I don't want to go, no, I don't regret anything; everything's been a learning experience, [laughs] so there's nothing I would have done differently because it's all led me to this point. But then, on the other hand, I think we've made the right decisions with the data that we've had. I think we need to...there's stuff that we need to be doing much more rigorously now moving forwards, which is making sure that we are very, very data-driven with what's coming back.

+ +

Now we're in the hands of real users in a meaningful way with the app. We need to be taking all of that feedback on and not just relying on the gut instinct with a lot of things. It needs to be much more data-driven now that we've got the data coming in. So I don't think that's a regret necessarily because I think you've got to kind of go with your gut to get a product out the door because you could be completely hamstrung by research. And that would have taken us into a whole nother territory. So I think...does that make sense? So whilst I'm not regretting but like --

+ +

CHAD: It does make sense. And you asked me for any advice that I have. And this is a very small piece of advice, but it's one thing that I've made the mistake of myself and seen many other teams do. If you want to seek metrics on something and you don't instrument it, you don't set up those metrics; then you don't have them.

+ +

CHLOE: So true.

+ +

CHAD: And you realize, oh, we should have been tracking this click, or that click, or this flow. And then you put it in place once you realize that it's not there, and you have to wait 30-60 days in order to get the data. And that time feels terrible while you're waiting for that data to accrue.

+ +

And so my general advice is to instrument basically everything. Instrument as much as possible, even if you think you're not going to need it. Track as many clicks as possible in the app so that you can really then say, oh, we didn't know we wanted to track this flow. And you already have the data where you can piece it together instead of waiting.

+ +

CHLOE: Yeah, 100%. So we were challenged by...so we're backed by sustainable ventures on the accelerator program. And we were challenged by them to make sure that we've got all of our KPI metrics in place for the product. Of course, we've just been head down building it. And actually, it was a great moment where it's kind of like, but how many points do you want your users to collect in a day? Maybe there's an upper limit that you want, which we hadn't really thought about. Well, I don't know; we just want them to collect points. Like, you know, we want them to live their best life.

+ +

And so in setting the KPIs, we've also had to set what we're measuring, but it was like two pages long. [laughs] There are so many things that we're trying to...what our KPIs are. And I think we can also...I think a learning is that maybe we need to be a little bit more focused with also what we're trying to measure and also what we were trying to see because we, again, can't focus on everything. We can't update and upgrade and iterate absolutely everything as a priority.

+ +

What's going to shift the dial the most? What's going to have the biggest impact? Yes, we can change the color of that, or we can make that button bigger. But actually, if that's not going to lead to the KPI that we're trying to measure, then actually, there's no point. So yeah, so I think that's been a learning as well. I mean, there are so many thousands, billion learnings on this whole journey. [laughs] I could write a book. I don't think anyone will read it, but I could definitely write a book. [laughter] And I don't have time to write it. If I had time to write it and if anyone wants to read it, I'll do it. [laughs]

+ +

CHAD: Okay. Well, maybe a few years from now, you can write that book.

+ +

CHLOE: Yeah.

+ +

CHAD: And, Chloe, thank you so much for joining the show and for telling us all about your journey. I really wish you and Plants and Perks the best over these important next couple of months.

+ +

CHLOE: Thank you. We're raising, by the way. We're just about to go into our seed round, so yeah.

+ +

CHAD: Seed round.

+ +

CHLOE: Yeah.

+ +

CHAD: Perfect.

+ +

CHLOE: I know, perfect for Plants and Perks. That's the next inflection point whilst obviously also launching an app. And we don't do things by halves, so that will be the next learning journey.

+ +

CHAD: If folks want to find out more, to follow along with you, to get in touch with the company, where are all the different places that they can do that?

+ +

CHLOE: Don't look at the website because we're in the process of updating that. [laughter] And, frankly, now I'm going to change the pricing after this conversation. [laughs] But yeah, no, don't do that. Just email me; it's the easiest way. Or find me on LinkedIn; LinkedIn is probably the number one way. Or email chloe@plantsandperks.com. I love; literally, I love hearing feedback: negative, positive, anything. I love having conversations. I love doing partnerships. I love helping people on their journeys; just reach out.

+ +

CHAD: Wonderful.

+ +

And you can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Chloe Sweden.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chloe Sweden is the Founder and CEO of Plants and Perks, a service for rewarding employees with sustainable perks.

+ +

Chad talks to Chloe about supporting employees on plant-based sustainability journies by gifting free samples and high-value prizes, choosing a co-founder, and being strategic with the types of businesses they've approached.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Chloe Sweden, the Founder, and CEO of Plants and Perks, a service for rewarding employees with sustainable perks. Chloe, thank you so much for joining me.

+ +

CHLOE: Thank you for having me.

+ +

CHAD: So you officially started Plants and Perks, at least according to your LinkedIn, in July of 2020. But I'm sure, like many entrepreneurs, you incubated the idea. The idea was in your head for longer than that. So, where does the idea from Plants and Perks come from? And when did you start to noodle it?

+ +

CHLOE: It's a really, really good question. I also think that the LinkedIn algorithm isn't 100% correct.

+ +

CHAD: [laughs]

+ +

CHLOE: And it always seems to add time. I always get this sort of like, "Oh my God, you've been doing this for like two years?" I'm like, "No, I'm sure it can't be. It must be shorter than that." So Plants and Perks, Plants and Perks originally started out life as the Green Shoot Institute, which, I think, if you Google us, still there's remnants of the Green Shoot Institute that exists. That is still our company holding name. And that was kind of, I guess, the first thought of the idea.

+ +

I was at the time heading up commercial relationships at a large parenting platform in the UK. And we had started to go on our own plant-based journey, so thinking about cutting back on meat and dairy consumption. I guess that was sort of my own personal journey that started to make me, as a parent, and as a consumer, and as a senior leader within business to, start to think about things outside of myself, and my family, and my business. And really, that was kind of the spark of thinking about how we, as employers, don't really do much to support employees on the plant-based sustainability journey. That was the sort of the embryo of the idea.

+ +

And that came from the fact that I had spent 20 years of my life in advertising, marketing, and then ten years within that in talent as a former head of talent and culture really thinking about how we embed talent and how we help employees, and how culture is so important to businesses, and how we get employees really to be the face of our brands. But we don't really do much to invest in people beyond the kind of traditional benefits that exist but also in terms of training and things like that.

+ +

That was kind of where things were coming together, sort of thinking about the future of work and thinking about how people go through these huge life moments and how the businesses really support them. So that was kind of the start. I won't give the whole game away, but that was, I guess, the beginning of a kind of, hmm, there's something there. And I didn't really know what it was at the time.

+ +

But yeah, I guess it wasn't so much before I actually incorporated the company. I incorporated in September 2020. That's what it says on my Company's House printout that I have on the wall just to remind me of when that momentous day happened. But pretty quickly, from coming up with an idea, I incorporated the business and just went, this is something I have to do.

+ +

CHAD: Yeah, the feeling of this is something I have to do is something that I've felt myself and that I hear from a lot of entrepreneurs and guests of the show. You were working at Mumsnet at the time. How did you start while also having another job?

+ +

CHLOE: Not just having another job, running a large sales team, and homeschooling two children during a pandemic.

+ +

CHAD: Oh, homeschooling. Okay, yeah.

+ +

CHLOE: And my son was definitely diagnosed with having additional needs at the time as well. I guess it was all of those things that kind of came together that made me realize, I mean, I had joined Mumsnet actually to head up Mumsnet's talent function, which was all about creating a flexible working product platform for parents and those looking for flexible jobs to bring them together in a marketplace. But Mumsnet wasn't going to actually continue to invest in that product, and I moved to a more commercial role.

+ +

But I moved there to build a product. And that's what really triggered it for me. I realized in that moment when I'm homeschooling, and I'm running a large sales team, and I'm doing all of these things, that wasn't why I moved to this role. I actually moved because I'm at the point in my career where I want to build something, that I have it in me to create something, and build, and connect people, and do something bigger than myself and bigger than a day-to-day job. And so that itch was there.

+ +

I was also, as part of that role, going out and speaking to heads of HR in large enterprise organizations and talking to them about what was troubling them. And funny enough, looking after their working parents was not troubling them, but sustainability came up a lot, and general well-being came up a lot. And so that was kind of, I guess, it started the percolation. But really, I guess with most things, the idea came about in its most embryonic stage, and then I took it to market really quickly. I basically gave it a name and then just reached out on LinkedIn to anybody I knew and people I didn't know as well just literally reached out to those people.

+ +

And I spoke to one person who I won't name her or the company but probably one of the largest global companies in the world and at a very senior level. And she was actually working out of the States. And she said to me, you know, "This is new. [laughs] You need to do this. Nobody is doing this. We need this in our lives. And I haven't heard of anybody doing this in the States. You need to go and build this." And that was, I guess, the impetus to do it.

+ +

And so I worked weekends. I actually was working four days a week at Mumsnet. But my fifth day, I was working full time for Mumsnet but not being paid. And so I clawed back my fifth day where I wasn't being paid, and I worked all weekends, and I worked all evenings. And I just worked and worked, and I haven't stopped until this conversation. [laughs]

+ +

CHAD: To actually work on it, did you start to gather a team, a group of people? Who were the first people that you brought on to help you?

+ +

CHLOE: So my co-founder, Ellen, we were on the senior leadership team of a creative agency. I was the head of talent and culture. She was the head of operation. So we had worked side by side in this organization. So we kept in touch. And she had contacted me about some health issues. And we were talking about cutting back on meat and dairy as one of the things that she could look at, given my own experiences with it. And that really bonded us.

+ +

And because I am marketing, sales, creative, and she is digital, tech, product, it kind of made sense, in the beginning, to bring her on. And I just said to her like, "I'd really like you on this journey with me." And she resisted it for quite some time. [laughs] We are very different personality-wise, very, very different. I'm yes, she's no, and so in that way, we're very much yin and yang.

+ +

CHAD: Oh, but I think that that can be the perfect combination for a co-founder team. I know that I've needed that in the past for myself. Someone who balances the risk-taking with reality can be very helpful.

+ +

CHLOE: Yeah, absolutely. And I think I'm actually not a risk taker, but I am a natural optimist. And so I'll have a meeting, and I'll be like, "It's amazing. It's solved all of our problems." And she'll be just like, "No, it hasn't. What's changed? Nothing's changed. There's no contract, nothing signed," [laughs] which I think in the moment is really not helpful. [laughs] But it's really helpful as we grow the business. It really is a good balance.

+ +

I bring all of that energy and drive to get us very quickly to the next level. And she brings all of the understanding, all of the pauses, all of the rigor, all of the data, all the things that are just the complete opposite of me. So I brought her on pretty quickly. And then we had a bit of a false start around getting a CTO on board. But we knew we needed to build the product quickly. And in the end, we built the product ourselves on a no-code/low-code platform, just the two of us. And I recommend any entrepreneur to do that because you learn a lot. [laughs]

+ +

CHAD: Is that the reason...so you learning...because I think that that is super important, whether it be someone like yourself actually building the product or just being very close to it. When I've seen entrepreneurs get too far away from the product too soon, they end up regretting it later on.

+ +

CHLOE: Yeah, I think --

+ +

CHAD: Or building the wrong thing.

+ +

CHLOE: Or building the wrong thing. I do really believe in you've got to do every job in order to then understand who you need to hire and to then have an appreciation of that role. So obviously the product evolved very much and very quickly. We were very lucky that one of our first clients was Lacoste, who we launched to here in the UK with our MVP. But we also did some other paid consultancy work with Uber and with other clients as well. And then PopSockets came on in the States as well. We weren't ready to launch in the States, but they really wanted us to. So we're like, you know, let's do it. [laughs]

+ +

CHAD: I noticed those three names on your website. And I do think that social...being able to have those testimonials there with names people recognize lends a lot of credibility to the product.

+ +

CHLOE: And they were my first three clients, [laughs] genuinely my first three clients.

+ +

CHAD: So, did you seek that out, or did it just happen? How did that work out?

+ +

CHLOE: Obviously, my background is commercial sales, so it's not something that I shy away from. It was connections; it was talking to people. And we were recommended to PopSockets, which was amazing. They came on as an early investor as well, which was phenomenal. Again, having clients who love what you do so much they want to invest is brilliant because you get to have some really interesting conversations and backers in your corner.

+ +

But yeah, of course, we've been quite strategic with the types of businesses that we've approached, but we are very lucky that we are attracting the right type of businesses as well, which is lovely. I mean, talk a little bit more about what Plants and Perks does, but the way in which we have evolved the product and evolved the types of clients that we're talking to is not an accident. And I think it goes back to the conversation we were just having about building the product yourself. Really being in the weeds, I think, is really important.

+ +

Now, it's going to be a challenge to me as a founder moving forward to make sure I'm extricating myself from the weeds as time goes on, although I'm pretty happy to step away when needed. [laughs] But knowing that and being able to talk to your clients and being really clear, well, this is what this client likes; this is what's happening here; this is what's working well here, I think is really important. You've got to know your product. You've got to know your audience.

+ +

We've got two...actually, we have three clients, technically. We have clients; we have employees; we have client employers; we have employees; and we also have Perks' partners. We have sustainable...we promote sustainable products and services on our platform. So we also have partners as well as our clients. And I think you've got to know them all really well.

+ +

Now, I was a head of talent and culture, so I know the employee piece quite well because I was always advocating for the employee. I spent 20 years downsizing, so I ran client accounts. So I know how to look after clients, I guess, from that perspective and work in large organizations. I also used to literally do the marketing for PepsiCo and Wrigley's and big brands. So I can do the partner piece quite well. And I think it's really important that you've done that and you've lived through it.

+ +

And I've never built a tech product, but I did literally roll my sleeves up and get stuck in to build the MVP, which was kind of the bit that I was missing. Now, I haven't built the app; that is beyond me. [laughs] But luckily, we've got a brilliant team around us now, which we've built up since our last raise that's enabled us to get that talent in. And yeah, and it's just been an amazing team effort to get us to where we are now.

+ +

CHAD: That's great. I want to dig into more about what the product actually is. But you've already alluded a couple of times --

+ +

CHLOE: No, let's keep it mysterious.

+ +

[laughter]

+ +

CHAD: You've alluded a few times to the evolution. And one thing that's stuck out to me as you were talking about that is that going to the website now; it's not specifically about eating less meat and dairy. You're talking more about sustainability.

+ +

CHLOE: Yes.

+ +

CHAD: I'm sure that's still a component of it.

+ +

CHLOE: 100%.

+ +

CHAD: But what drove that change?

+ +

CHLOE: Oh my God, [laughs] about a two-week period where we had an existential crisis. I think this is really interesting, I think, for our journey, and I think us as founders as well. So we ideologically always believed in the reduction of meat and dairy as the number one thing you can do for personal and planetary health. That's it. Like, that was it.

+ +

We were all about eat plants, get perks. We encourage employees to cut back on their meat and dairy consumption, and we reward them with plant-based perks. That was the product. That was the concept. Tested really well. People really bought into it. People liked that they were being rewarded with perks. They absolutely understood that it is unsustainable to consume meat and dairy in the way that we are moving forward for the planet and also for personal health.

+ +

So when we're having these conversations, everyone was like, thumbs up, get it, love it, buy into it, it's all great. And then what was happening is that I kind of got to a point where I was like, we've had all these really positive conversations, but no one's biting. Everyone's sort of saying yes to me and then nothing.

+ +

I'm actually really proud of us as a team for very, very quickly going and identifying the problem and fixing it because we could have stuck to our ideological guns and gone, no, no, no, but we are all about the reduction of meat and dairy consumption as the number one thing. But no one was telling us that it was that that was the problem.

+ +

What we had to do was read between the lines because nobody would ever tell us that. But what they would say was, "Well, how would it land with a 58-year-old man working in our distribution center?" And we're like, "Really well, why?" [laughter] But I had to understand what was coming behind that question. And what was coming behind the question was I don't want to launch a benefit where I feel like we're judging somebody's life choices. Like, that's not going to wash.

+ +

So the people we were talking to were super keen on it, then when they took it up the line, they were essentially saying, "Well, this is a plant-based benefit, Plants and Perks." And I think that's where the sort of record scratched, and it didn't go any further. But no one was feeding this back to us. This we had to discover ourselves.

+ +

And so we had this kind of existential crisis where we're like, well, we've always been about sustainability, like, absolutely the reduction in meat and dairy is all because it's unsustainable for us to consume meat and dairy and fish in the way that we are. So why don't we broaden ourselves out to more? We already held sustainable products and services on our platform anyway. It was just the language; it really was. It wasn't actually as big a pivot as it sounded. It really was just softening the language.

+ +

So we don't talk about plant-based; we talk about planet-friendly. And we just kind of expanded out some of the articles and content that we contained anyway. And that unblocked everything, like genuinely overnight unblocked everything. So it became something that what we were hearing was that companies wanted to introduce a new green benefit, and now they felt that they could because there wasn't the kind of...and we always said that this is non-judgmental. This is completely supportive. These are very small changes that you could make. You don't have to sort of introduce me to it.

+ +

But now it makes sense to everybody. And I think we as a business just needed to go through that moment where we were like, is this the type of business that we want to be running? Is this the business that we want to be owning? And we were like, absolutely, because this is still...our mission actually didn't change at all. Our mission is to help a million employees live healthier, more sustainable lives. That has not changed. And so the fact that our mission hadn't changed, it was just some of the language needed to change to make it more palatable to a wider audience, that's fine. We could live with that.

+ +

CHAD: Yeah, that's great. So now, what does that actually mean in terms of what the product is? Companies sign up.

+ +

CHLOE: Yep.

+ +

CHAD: And what do employees do?

+ +

CHLOE: Yeah, so it's a really good question. So the other sort of big moment, I guess, inflection point that we had is that we introduced a freemium model. And that, from a product perspective, was quite a big thing because I started realizing in conversations as well we were giving too much value away. And actually, some of the value that we were giving away clients didn't necessarily want. Some clients really wanted it, and some clients didn't need it.

+ +

And so we introduced three different products. So we introduced free, so we now have a completely free Plants and Perks app that any employer can take on for their employee base. And it will give them discounts of sustainable products and services. It will give them article content on how to live more sustainably, embrace more sustainable living. And it will give them planet-friendly recipes on essentially more sustainable, healthy ways to eat. And that's the core free product that we've created.

+ +

CHAD: And are you still making revenue on that through partner relationship?

+ +

CHLOE: Yeah, absolutely. So, although, you know, we're not about excess consumption. What we are about is...I think what we really realized is with Plants and Perks; we are bang smack in the middle of a cost of living crisis. And actually, what we can do is level the playing field when it comes to green and sustainable products.

+ +

There's kind of like this green tax that gets applied. And what we're trying to do is very much look at price parity. So what we talk about is it's harder than ever to make the most sensible choices when costs are spiraling all around us. And so what the reductions of planet-friendly products does is enables you to just try things that you might not have tried before because of cost, and it mitigates against that.

+ +

So we do go into relationship with partners, and they can promote their products through the platform. But there are also chances for employees to put their reviews and tell them what they think. So it isn't just set up for advertisers in that way at all. But what we found is there's an amazing thing which is that brands need to connect with a new, wider audience. They don't just want to talk to early adopters within the sustainability or plant-based space. And we are talking to every man and every woman in large-scale organizations.

+ +

So it's actually quite difficult to access those people if you're these niche brands who may not even have listings necessarily in large retailers yet. Or if you do have distribution, it's really difficult to get a sell-through. So we enable those partners to offer sampling, to offer freebies, to offer significant discounts, and to offer in-store redemptions as well. So we are offering quite a significant route to market for sustainable and plant-based products and services.

+ +

CHAD: That's great. Okay, and so what is the second tier up?

+ +

CHLOE: The second tier is plus and what that gives you is we start to give employees plant points, and you collect plant points. It's incredibly gamified. You can collect badges. Every action you do basically has a reaction. So when you read an article, you basically can answer some questions on the article, and you'll be rewarded with points. You can rate a recipe; you can like a recipe, try a recipe. You can buy a product or a service. You can also get a free...in the UK, at the moment, you'll be able to get a free meal once a week, like a free lunch through one of our partners, and loads of freebies as well.

+ +

So the value is much more significant in the plus model. That's kind of our core offering. And we talk about rewarding employees with sustainable perks. And during the time at the moment, employers are really looking for ways in which they can support their employees through the cost of living crisis. How can we give our employees free stuff, interesting stuff, whilst also helping them on the sustainability journey? And so therefore, this is something that genuinely really works for both employers and employees. So that's the plus model.

+ +

CHAD: One thing I noticed as you lay out the benefits that you get under this model, I'm surprised then by the per-employee cost. It seemed very low to me [laughs] when I saw it. Can you talk more about that?

+ +

CHLOE: Yeah, so that is a from price. And I do think I need to make it; I mean, I do say it's from, and I think I do say there's a bit of an asterisk. I do think I need to potentially change it as well. So it's good [laughs] feedback because I think quite a few people say that. So that is for large-scale employers. So we are talking to large retailers with 20,000, 30,000 40,000 employees. So that is the cost that they would pay. It is a sliding scale back from that cost. But, I mean, we've purposely priced ourselves to be reasonable. We are a mission-led company, and for any investors listening, don't worry; we are also revenue-generating.

+ +

CHAD: [laughs]

+ +

CHLOE: But for us, it's really important that we are an affordable benefit. We're very aware of the costs on everyone. So, for sure, that price is pretty low. But we think that it represents quite good value, incredible value for the client. But it's something that makes sense for them to bring on. It should be a no-brainer; that's basically what we say. Like, it's a no-brainer. In terms of the amount of freebies that you're getting for your employee, it's certainly a no-brainer in terms of the return on investment.

+ +

On the pro version, by the way, the added value on the pro version is that it's fully ring-fenced for that organization. So it's fully branded. They get full account management. It looks like their platform, essentially. And employees can talk and access the information together. So it might be that Bob in IT in Denver has uploaded a photo of himself cycling to work, and somebody else can comment on it. Somebody else has uploaded a curry recipe in Scotland, and someone else has gone, "Well, I tried that recipe." "But, you know, how was it? How much chili did you put in it?"

+ +

So people are kind of joining together and really creating that space to talk about sustainability in a much more accessible way. So that's the pro version. And also we're then building on sustainability metrics and also sustainability reporting. So we'll be able to talk about employees' own carbon footprint and also how that scales up to the overall company's sustainability goals.

+ +

CHAD: You mentioned that the mission is to help one million employees on their sustainability journey. Can you tell me where you are [laughs] along that metric?

+ +

CHLOE: Yeah. So, look, the app launch is tomorrow, so [laughs] ask me in a couple of months. And we're really...actually; we're genuinely new.

+ +

CHAD: You've been in private beta, I guess, is the way to describe it.

+ +

CHLOE: Yeah. We're basically with the MVP. We've been helping a couple of thousand employees up until this point. We got around 25,000. About 30-plus companies join our waiting list, which was then around 25,000-30,000 employees that represented. We've just confirmed that we're going to be launching with a very large retailer in the UK as well, so that will then --

+ +

CHAD: Congratulations.

+ +

CHLOE: Thank you. That will then double, so it will be about 50,000 employees that we'll be hitting this year. And then we are in quite far down the line talks with quite a few other companies that would take us to potentially just under our target, which, by the way, the million employees is not like it's a target for 2022. It's like a...it's our ongoing mission. [laughs]

+ +

CHAD: Right, a long-term vision.

+ +

CHLOE: It's a long-term vision. So we're significantly further ahead than I thought we would be on that. I mean, look, what we've said from the start is the million is a sort of fairly arbitrary number but what it is is it's scale. So we're not here just to look after, you know, we're not here just to help very, very small companies; we can now with our free product, which is great, but it gives us that scale.

+ +

And it shows that we, as a business, want to be global, want to be talking to enterprise clients and then helping them live healthier, more sustainable lives. For us, it's both of those things. You can't just live a healthy life, and you can't just live a sustainable life. It needs to be a life of purpose. And so the mission really keeps us true to those things.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff.

+ +

CHAD: You mentioned you have essentially three client bases: you have the employers, the employees, and the partners, which essentially means you have a multi-sided marketplace.

+ +

CHLOE: Yes.

+ +

CHAD: And one of the challenges of building any marketplace, especially the more sides you have, is bootstrapping it, you know, creating a momentum. The partners want to know, hey, how many people are on the platform that we're going to be bringing into? And in the early days, you don't have much to offer there. So how have you made that work?

+ +

CHLOE: Well, so firstly, we don't see ourselves as a marketplace, which we should. [laughter] We should see ourselves as a marketplace. Secondly, I learned all about building a marketplace because, in 2010, I launched a dating app before there were apps. Actually, it was a dating website...and completely on my own. It was complete madness. And I totally did not understand the power of a network.

+ +

I didn't understand the marketplace dynamic. I didn't understand that you needed buyers and you needed sellers. You needed, in this case, men seeking women and women seeking men. [laughs] You needed both sides of the equation. And you needed volume on both sides straight out of the gate. I just didn't get that. I was like, build it, and they will come. [laughs] And so I was fully burnt from that experience. So that was still ringing in my head.

+ +

So I think what was important was building up, firstly, building up our partners. So it was really, really important to build up the number of partners that we have on the platform. And for them, it's a completely low-risk strategy. It's like, come on the platform and offer discounts and people who are interested in sustainability. Like, that's really easy. We can do that.

+ +

And then for the companies, we've got everything...beyond the partners, we still have loads and loads of value. We still have value in the articles. We still have value in the gamification. We have value in the recipe. So there's still value even if there wasn't value in the perks. But what we've done is we've been able to build up both sides.

+ +

So actually, we've got over 200 brands, which represents about 45,000-plus individual discounts on the platform. And now we're building up the number of employees. Now we're able to revenue generate more off the partners because we've got the volume on the other side.

+ +

CHAD: You mentioned that you are primarily focused on the UK now. But you've had interest from the U.S. and demand that you've not rejected. What does that look like for you now? And how do you balance that going forward?

+ +

CHLOE: Yeah, I have got quite a lot of interest from the States. And it's really hard not to be pulled over there. And we see a lot of interest from there. We have to --

+ +

CHAD: Why are you holding back?

+ +

CHLOE: Because we just don't have the team size at the moment, and we need to get the...there's two things really. Well, there are a number of things. There are about 22 things. [laughter] I know I said there are two things; there are like a million reasons. We need to make sure that we've got the best product possible; that's number one. We need to test in our home market. We need to make sure that we've got the robust mechanic with the Perk's partners and with the employees. We need to get all of that working really well because the States is a completely different market because of the nature of the products and services. We're not on the ground there.

+ +

So it's easier for us to have really good relationships with partners now. There's going to be a conference on Wednesday in London, so I'm going to be meeting a lot of our partners there; super easy. It's like 20 minutes on the train for me. Harder to go to the States and make sure that we have really robust relationships with partners there; not impossible, just it would be time and effort to be able to build it in the States. I think we'd be able to find the clients actually more easily or, I guess, quicker if that makes sense because I think there's a need in the States.

+ +

And then there are just cultural nuances. So we just need to make sure that all of our content is really relevant culturally. So PopSockets, we are with PopSockets in the States, and I think they're quite fairly near you in Boulder. So we are already aware of some of those cultural nuances. And our editorial teams are quite good at making sure that we're representing that.

+ +

So, yeah, so I think it's just about making sure that we do a good job of it. The hard thing, I think, is actually launching across Europe because of the language barrier and because of the very different cultural nuances when it comes to sustainability, local government policy.

+ +

CHAD: Also, expectations around employee benefits and how they work.

+ +

CHLOE: Exactly. Expectations around employee benefits and also attitudes to food as well because obviously food is still a part of what we do, and so all of those things actually make Europe slightly harder. So I think, for us, it would be a launch to the U.S. before we would go to continental Europe, but, again, not impossible.

+ +

Interestingly, our clients massively want us to be global quickly because they are all looking for global benefits. They want to be able to homogenize their benefits offerings globally. They do not want to have one thing being offered in the UK, something being offered in the States, especially when it comes to benefits. Things like pensions, things like healthcare are so different in those countries, and they won't change. Just in terms of how many holiday days you guys have versus us, they can't make it a level playing field on many things.

+ +

So if they could have a level playing field when it comes to sustainable benefits, they would love to do that. So there is a real need driving us to go global very quickly. And, look, going right back to the conversation we had at the beginning, I'd do it tomorrow. I'd move my family to the U.S. and just start building it. But my very kind advisors are like, slow down. [laughs] Get it right in the UK.

+ +

CHAD: Well, I think that is a good indicator that you do have a marketplace business because all of the pressures around scaling are the same ones that marketplaces have.

+ +

CHLOE: Yeah. [laughs]

+ +

CHAD: And marketplace businesses very often benefit from in the early days focusing on specific markets.

+ +

CHLOE: No, you're 100% right. I think I've had an epiphany on this podcast [laughter] that I'm running a marketplace.

+ +

CHAD: I want to come back to the actual tech of the product as we wrap up here. I'm super impressed that you used a low-code platform to build the MVP yourself, and that has taken you through today. So how did you go about moving beyond that?

+ +

CHLOE: [laughs] So we always knew we'd have to ditch it, so we were very aware. And that's the beauty of doing an MVP which is you don't fall in love with it. So that was great because we knew we were going to ditch it. We didn't fall in love with it. So how did we go about it? So we've got ourselves...we got a CTO on board that Ellen had worked with before. And we've got an amazing UX-UI designer. And we've got some devs.

+ +

And we just ran at it. We just said, right, what are we taking from the MVP that we want to put into...and we knew it had to be an app really quickly. We actually weren't going to develop the app this year, but then it was sort of, you know, the demand there was all for the app. So we've gone app first. So we just said, "What's important from the MVP that we want to be taking here?"

+ +

We knew that perks was going to be the first thing that we wanted to launch with because of the cost of living crisis. And we wanted to make it really about perks, which is why I know it sounds silly when it's obvious to you that we're a marketplace. It actually isn't that obvious to us because before perks, none of those things are marketplace. All of the other products and services that we offer aren't marketplace.

+ +

CHAD: You mean the content and that kind of thing.

+ +

CHLOE: The content, the gamification. We've got a whole thing coming down the line all about how to calculate your carbon footprint. Like, none of that is marketplace. But because we've really leant heavily on the perks because we know that there's a massive need for that, I guess that's why it's a surprise to me [laughs] that we're a marketplace. But yeah, so we knew we wanted to get perks out first.

+ +

So then we built a product with perks at the heart because that was testing really well. And then yeah, and then we've just kind of literally just gone hell for leather head down. The team has been in build mode. We've been in sell mode and creation mode. And, yeah, we've just gone really, really fast. It's not in our natures to sort of go slow on these things. And we just need to be out there. People love what we're doing. And now it's the real test. Now it's literally employees now getting access to it, and that's the scary time.

+ +

CHAD: Has it been what you expected actually, you know, building custom software in terms of time, and cost, and that kind of thing? Or has it been different than what you expected?

+ +

CHLOE: Yeah, that's a good question. So I guess over the years, I've had the opportunity to build products internally in companies. You're always in a waiting list for other people that need other stuff. So in a way, it's been quicker because it's my team, and they've got nothing else to concentrate on except this.

+ +

I'm really open with what I don't know. So I'm like, okay, could I do, just out of interest, how easy is it for us to switch off that function and launch this? Is it a week? Is it a month? Is it like a year? Like, I just have no idea on timings and scale on that. So I try to work that out quite quickly.

+ +

But I think it's been quicker than I thought it might be. And if you've got an internal team, then it's cheaper. As soon as we started to look at external teams, it was prohibitively expensive and no control. And I think we knew quite early on that we wanted to build it internally.

+ +

CHAD: How has it compared to the process of using the low-code tool to get started?

+ +

CHLOE: [laughs] In a way, if I had an idea, it was up and live an hour later...[laughs] and, you know, I guess there's much more pushback now. It's like, "Do you really need that feature?" And I'm like, "Yeah, you know, just do it. What's so difficult?" So I guess I've had to put more rigor and thinking behind some of the features and functions that we now have versus just sticking it up there.

+ +

I mean, look, we were really, really frustrated with low-code. We were really frustrated with what it could do. It is so limited really in what we were trying to do, but it got us to a certain point. I'll always be forever grateful to it. [laughs] And my partner and I were able to completely tag team on it. So I would do all of the front end, and she'd do all the back end. It worked really well from that perspective.

+ +

But we've got a great team now who are really engaged in what we're trying to do and trying to achieve. I guess I want everything yesterday. So as with most things, I'm getting updates going, "This is broken, and I'm having to turn this off for the launch." And I'm like, "No, I want it there. I want it in there."

+ +

CHAD: So, on that note, why do you have a specific launch date?

+ +

CHLOE: We've got a client we're launching to next week. [laughter] So we're launching --

+ +

CHAD: So you've made a commitment to launch for a particular client, and so you need to hit that date.

+ +

CHLOE: Yeah. We are. We're launching it to...yeah, we've got quite a lot of clients, actually. We've got launches almost every day from next week. So this week is friends and family launch. So we need to get it out and get it tested. And then it goes into the hands of real-life users, which is scary and interesting.

+ +

CHAD: I wish you all the best with that. I really appreciate you taking the time.

+ +

CHLOE: Any advice?

+ +

CHAD: Well, what I was going to say is a question I often like to ask. And I'm curious, before launch, is there something that you wish you could have done differently or realized sooner? I'm sure this question might be different post-launch. The answer to this question might be different post-launch. But from where you sit today, is there something that you wish you would have done differently?

+ +

CHLOE: Oh my God. I almost want to say everything and nothing. I don't want to go, no, I don't regret anything; everything's been a learning experience, [laughs] so there's nothing I would have done differently because it's all led me to this point. But then, on the other hand, I think we've made the right decisions with the data that we've had. I think we need to...there's stuff that we need to be doing much more rigorously now moving forwards, which is making sure that we are very, very data-driven with what's coming back.

+ +

Now we're in the hands of real users in a meaningful way with the app. We need to be taking all of that feedback on and not just relying on the gut instinct with a lot of things. It needs to be much more data-driven now that we've got the data coming in. So I don't think that's a regret necessarily because I think you've got to kind of go with your gut to get a product out the door because you could be completely hamstrung by research. And that would have taken us into a whole nother territory. So I think...does that make sense? So whilst I'm not regretting but like --

+ +

CHAD: It does make sense. And you asked me for any advice that I have. And this is a very small piece of advice, but it's one thing that I've made the mistake of myself and seen many other teams do. If you want to seek metrics on something and you don't instrument it, you don't set up those metrics; then you don't have them.

+ +

CHLOE: So true.

+ +

CHAD: And you realize, oh, we should have been tracking this click, or that click, or this flow. And then you put it in place once you realize that it's not there, and you have to wait 30-60 days in order to get the data. And that time feels terrible while you're waiting for that data to accrue.

+ +

And so my general advice is to instrument basically everything. Instrument as much as possible, even if you think you're not going to need it. Track as many clicks as possible in the app so that you can really then say, oh, we didn't know we wanted to track this flow. And you already have the data where you can piece it together instead of waiting.

+ +

CHLOE: Yeah, 100%. So we were challenged by...so we're backed by sustainable ventures on the accelerator program. And we were challenged by them to make sure that we've got all of our KPI metrics in place for the product. Of course, we've just been head down building it. And actually, it was a great moment where it's kind of like, but how many points do you want your users to collect in a day? Maybe there's an upper limit that you want, which we hadn't really thought about. Well, I don't know; we just want them to collect points. Like, you know, we want them to live their best life.

+ +

And so in setting the KPIs, we've also had to set what we're measuring, but it was like two pages long. [laughs] There are so many things that we're trying to...what our KPIs are. And I think we can also...I think a learning is that maybe we need to be a little bit more focused with also what we're trying to measure and also what we were trying to see because we, again, can't focus on everything. We can't update and upgrade and iterate absolutely everything as a priority.

+ +

What's going to shift the dial the most? What's going to have the biggest impact? Yes, we can change the color of that, or we can make that button bigger. But actually, if that's not going to lead to the KPI that we're trying to measure, then actually, there's no point. So yeah, so I think that's been a learning as well. I mean, there are so many thousands, billion learnings on this whole journey. [laughs] I could write a book. I don't think anyone will read it, but I could definitely write a book. [laughter] And I don't have time to write it. If I had time to write it and if anyone wants to read it, I'll do it. [laughs]

+ +

CHAD: Okay. Well, maybe a few years from now, you can write that book.

+ +

CHLOE: Yeah.

+ +

CHAD: And, Chloe, thank you so much for joining the show and for telling us all about your journey. I really wish you and Plants and Perks the best over these important next couple of months.

+ +

CHLOE: Thank you. We're raising, by the way. We're just about to go into our seed round, so yeah.

+ +

CHAD: Seed round.

+ +

CHLOE: Yeah.

+ +

CHAD: Perfect.

+ +

CHLOE: I know, perfect for Plants and Perks. That's the next inflection point whilst obviously also launching an app. And we don't do things by halves, so that will be the next learning journey.

+ +

CHAD: If folks want to find out more, to follow along with you, to get in touch with the company, where are all the different places that they can do that?

+ +

CHLOE: Don't look at the website because we're in the process of updating that. [laughter] And, frankly, now I'm going to change the pricing after this conversation. [laughs] But yeah, no, don't do that. Just email me; it's the easiest way. Or find me on LinkedIn; LinkedIn is probably the number one way. Or email chloe@plantsandperks.com. I love; literally, I love hearing feedback: negative, positive, anything. I love having conversations. I love doing partnerships. I love helping people on their journeys; just reach out.

+ +

CHAD: Wonderful.

+ +

And you can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Chloe Sweden.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+BsQ9kfsS + + ]]> + + Chad Pytel + Chloe Sweden + + + 445: Classcraft with Shawn Young + https://podcast.thoughtbot.com/445 + 459b2c7d-d40e-481c-8bf9-0b564b46dc02 + Thu, 20 Oct 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Shawn Young is the CEO and Co-Founder of Classcraft, an innovative platform that motivates students using the culture and mechanics of games. + +Victoria talks to Shawn about edtech, behavior intervention, and the challenges he's faced with going from a homegrown tool to something big and out there in the world. + 40:58 + no + + + Shawn Young is the CEO and Co-Founder of Classcraft, an innovative platform that motivates students using the culture and mechanics of games. +Victoria talks to Shawn about edtech, behavior intervention, and the challenges he's faced with going from a homegrown tool to something big and out there in the world. +Classcraft (https://www.classcraft.com/) +Follow Classcraft on Twitter (https://twitter.com/classcraftgame), Instagram (https://www.instagram.com/classcraftgame/), Facebook (https://www.facebook.com/classcraftgame), YouTube (https://www.youtube.com/c/classcraftgame), or LinkedIn (https://www.linkedin.com/company/classcraft-studios/). +Follow Shawn on Twitter (https://twitter.com/_shawnyoung_) or LinkedIn (https://www.linkedin.com/in/shawnyoung1/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Shawn Young, the CEO, and Co-Founder at Classcraft, an innovative platform that motivates students using the culture and mechanics of games. Shawn, thank you for joining us. +SHAWN: Thank you. Thanks for having me, Victoria. I'm happy to be here. +VICTORIA: Wonderful, yes. So just tell me a little bit about yourself and maybe what brought you to start out as a teacher initially. +SHAWN: [laughs] I have an interesting journey. I was originally a physicist, a physics major. Although I loved physics because it really gives you a deep understanding of the world, I realized that physics research in a basement with machines just on your own [laughs] wasn't for me, so that's when I started substitute teaching. I really wasn't going to go into education at all. It was just there was availability, lack of teachers. +And it's kind of ironic. I really did not enjoy school. High school, in particular, was just a really challenging time for me, mostly because I just didn't see the point of it. I didn't have any problems in school. I had great grades, but I just was bored out of my mind. And so, as a teacher, I became really, really obsessed with making school meaningful for the students that were there, and because so many kids, so many learners just don't see the point. +And so I did a lot of really cool project-based learning type of stuff. So that's where instead of lecturing the kids, you get them doing things and learning by doing. And so I was teaching physics, obviously. And so we were building hot air balloons and cannons and all kinds of stuff to study Newtonian physics. And kids were super happy to come to the class because we were doing some cool stuff. +But I realized as that was happening that another part of meaning generation for kids and learners is the community and the social aspects. And so, I started thinking about how I can build community in the classroom, make the social experience of school relevant for them? And that's how Classcraft was born, really. I kind of put together my interest in motivating and building community with kids. I was a developer at the time as well, so I was able to develop a platform. And, of course, I'm a gamer, so I kind of put all those things together and built this platform in my classroom. +VICTORIA: That's great. I was going to ask what skills or experiences from your teaching background translated to being a founder. +SHAWN: That's interesting because clearly in the product...Classcraft was never meant to be a company. I already had a company. [laughs] I was freelancing as a developer for pretty large clients in New York. I was working with my brother, who's a creative director there. And we worked for Chanel for three years building apps and websites, and that was probably our biggest client. I wasn't looking to make a company. I just built it for me. It was my quest to make school meaningful and relevant. +And after three years of just tinkering around with it with my students, I realized it was having a massive impact on their outlook, on the way they collaborated together, on their motivation. And because Classcraft is a platform that basically gamifies education, so kids level up and they earn points. They're on teams. They have a character class. All the things you would see in an RPG are translating to how teachers are running a school. +And so I made a website just to talk about it after three years of this garage project I had going on. And the day that website went online, 130,000 people came to the website. It just started trending on Reddit gaming. And overnight, a lot of people were asking, "How do I download this?" I'm like, "You can't. There's no company." [laughter] So that's how the company started. +Teaching is an interesting profession. I think that teaching is a job that requires you to, A, motivate and manage a whole bunch of people, so there's a lot similarility there to management. It's a group of humans that you want to work together to get to their full potential, just like your team should be. But then there's also independent planning. As a teacher, you have a set amount of time to get through X amount of curriculum. So you're always, you know, project management basically, 101 is the same thing as running a curriculum through the year. +So there are a lot of those types of soft skills that translate really easily to entrepreneurship. And ultimately, as a teacher, you're responsible on your own for your own successes and failures, which is the type of attitude you need to have if you're going to be a successful entrepreneur is to be responsible, you know, [laughs] take control of your destiny a little bit. +VICTORIA: Right. I hadn't thought about it from that angle. It makes a lot of sense. You're really an independent owner of that classroom, right? [laughs] +SHAWN: Yeah, exactly, exactly. And trying to get humans to collaborate and do stuff sounds a lot like running a company. [laughs] +VICTORIA: Right. I saw the tagline on Classcraft: relationships are everything. And I was like, that's a perfect DevOps kind of statement. [laughs] +SHAWN: Yeah, that's funny. [laughs] We're thinking more like human relationships, but that's so funny [laughs] from the DevOps side for sure. +VICTORIA: In and outside of the classroom, you need...it doesn't matter how great your technology is or your strategy. If the people aren't talking to each other and you don't have the right relationships, you're not going to be successful. +SHAWN: Correct. And ultimately, that's the value proposition of Classcraft. Schools that don't build good relationships between students that don't do it between teachers and students, that don't do it between teachers and administration are dysfunctional. And what we're seeing in education today is one of the fundamental breakdowns that's happening and, you know, that's proxy for what's happening at large, and society is relationships are quite strange right now in schools, and that's making it really hard for them to be effective. +VICTORIA: Right. It sounds like this app was built out of your direct experience and your direct experience working with these students. What do you find is unique in working with students, and how do you appeal to them as a user base? +SHAWN: What's really special about edtech is that your buyer or the user that makes the decision to use the product is not the end user, and that's true in all B2B, SaaS. The decision maker who purchases the software isn't necessarily the employee who's going to use it. But in education, there are multiple levels. Like, if we sell to a district, they're the ones buying, but ultimately, they need to get the teachers to use it. And then, at the end of the day, the actual real users are the students. +And so, there are a lot of design considerations when you think of UX. And even when you think of user permissions, there's a lot of complexity there in education because our goal is to build as much motivation and engagement mechanics as we can for kids. And so that means leveling up, and random loot drops, and all these things you see in video games but applying that to school. +But then you need to build all this plumbing [laughs] basically to make it usable by a user who's the teacher who doesn't really know much about games, and that's changing as the teacher...average age of teachers is going down, a lot of retirements, et cetera, so that's changing. But at the base of it, the kids are really well versed in games, game mechanics, game culture, but the teacher who's running it is not. +So we have to speak two languages, one of pedagogy, and classroom tools, and data, and saving time. These are the things that educators care about. And incidentally, they care about motivation and motivating the kids, and all of those things. But for kids, we're talking about avatars, and pets, and gear, and leveling up, and all this whole other set of language. +And so when you think of design considerations, we always have to be thinking about how do I make this as motivating and engaging as possible for the kids, but how do I make it as easy to use and not complicated for teachers? Because if the teachers don't use it, then these kids aren't going to see the value anyways. So it's pretty complex because we don't have one single end user. +VICTORIA: And so you have the challenge of making it fun for kids and then also providing useful and understandable data for teachers and probably parents and other people, right? +SHAWN: Yeah, yeah, exactly. There are lots of stakeholders. +[laughter] +VICTORIA: So I want to ask more about how you make it fun, and then I also want to know more about the teacher's perspective, so whichever one you want to start with first. +SHAWN: Perfect. I mean, those two questions are literally the placement of what Classcraft is. Classcraft is the Venn diagram between what in education is behavior intervention, so managing kids' behavior and motivation. And so, from a motivation angle, how do we make it engaging for kids? In essence, kids are earning points in Classcraft for things that they're doing in school that we want them to do. And by we, schools can configure whatever it is, but it'll be things like handing in homework, being respectful, being inclusive, participating, being on time, these behaviors that they want to see in kids to make them better learners. +When those behaviors occur, teachers can give them points. And the points allow them to level up. As they level up, they each have a character. They have an avatar, and they can be warriors, healers, or mages. And based on that character class, they have a different role in the team. So they're playing in teams just like in an MMORPG or on a football team. And everybody has a different role within the team. And you win as a team. +And so school is quite competitive. Kids are always compared to the class average and their grades. And there's a lot of competition happening in schools. What we've built is a way for kids to be motivated by collaboration. And so they're playing on teams. If they do good things, they get these points, and they level up. And there are millions of combinations of gear that they could buy for their avatar, but they're also unlocking real-life powers. +And so these powers are things like, you know, in a video game, power could be like you could shoot a fireball. In Classcraft, shoot a fireball is the equivalent of you can skip a question on an exam, or you can go to the bathroom, or you can hand in homework a day late, or you can listen to music while you're doing your classwork, so giving them real-life privileges as they level up. And these aren't one-offs; they're skills that they have that they can trigger whenever they want, just like in a game. +And some of those skills are things like being able to heal up your teammate because kids can also lose lives if they do negative things. So if you're late or you're rude, or whatever it is, just like in Mario, what's failing in Mario is falling in a hole, and what's failing as a student, it's not doing what you're supposed to do, or being a bully to other kids. And so, as that happens, they can lose lives. But then they can come in to help each other out. There are boss battles where they can fight monsters by answering quiz questions, et cetera. +So all these motions that are ultimately the things that are happening anyways in school, what we're saying is instead of punishing kids or forcing them to do this stuff, make it feel like a game. Speak their language, use the same mechanics that we know are super effective at motivating players. Nobody is forcing people to play video games. Everybody's doing that of their own volition. It's the most popular cultural medium that exists today, well surpassing film, movies, music. And so, why are games so good at doing that? It's because they fulfill fundamental needs: being in control, feeling like we're progressing, social relatedness. That's what we're bringing to school. So that's the student side of it. +The other side of it, behavior intervention, is...well, one of the biggest challenges for teachers is managing kids. It's not like showing you how to do a math problem; it's getting you to care about it, listen to it, stop disturbing other people. And so, a lot of time and energy is spent on classroom management for teachers. And so what we do is we use best practices there. For example, there's a lot of research out there in education that says that praising kids for good behavior is a lot more effective than punishing them. +And so games are really good at praising you. You level up, and you gain points. It tells you your score. What we're doing here is giving them that framework but applying that to classroom management. And so instead of saying, "Hey, Victoria, stop goofing off," or "You're not dressed well, go to the principal," or whatever it is that's happening in schools, what we're telling teachers to do instead is say, "Hey if Victoria does something good, recognize her. Give her a high five." And in Classcraft, a high five is gaining points. +And so we're shifting and applying this pedagogy, shifting towards a positive reinforcement mindset. And at the same time, because these high fives are digital, then you get all the data so you can know which behaviors did Victoria do at which time with which teacher? Hey, she didn't get a lot of points this week. What's going on with her? Maybe we should talk to her and see what's going on before her behavior escalates. And so there's a lot of value from a behavior intervention standpoint. But ultimately, it's super effective because the kids really care about it in a way that they don't normally care about classroom management. +VICTORIA: Well, that makes a lot of sense. And I'm hearing something I've studied before when looking at technology organizations which is that growth mindset I think you're describing, the positive reinforcement, praising the effort for something versus their intrinsic skills. And that's something I love about teaching. I think that really, really translates to running a technology organization. +SHAWN: Yeah, totally. Ultimately, what we're doing is giving schools and teachers a platform for really effective culture building. And what you're talking about is culture within a company, in essence, and it's really the same thing. It goes back to what I was saying earlier about managing a group of kids [laughs], and managing employees is super similar. It's all about what type of positive culture you are building. +VICTORIA: I think there's something really universal about that. It's actually even true with dog training. I have a dog, and it's the same kind of motivational theory that works for them too. [laughs] +SHAWN: Yep, yep. +VICTORIA: I love it. And you mentioned that you built this tool yourself, and then suddenly, it became very popular, and now it's really, I'm sure, scaling. So what challenges have you faced with going from this homegrown tool to something big and out there in the world? +SHAWN: Lots of challenges. [laughs] I would say working in education itself is a challenge. It's a pretty challenging vertical to work in. It's ripe for disruption at the same time, pretty conservative. There are a lot of forces working in education systemically not have it move forward. Working with schools and districts is challenging. They have a lot of requirements. And, of course, they're custodians of kids, so that's legitimate, but it does make it more challenging. +One of the things that we had to evolve was we were very much a teacher-only tool when we started. I had built it as a teacher. Our user in mind was a teacher. Even our business model initially was selling to teachers basically. There was a free version, and they could upgrade to a paid version. And as we got more and more scale, you know, we have ten million-plus kids in the platform now. As we got more and more scale, what ended up happening was we were working more and more with schools and districts. +And so we went from a B2C go-to-market and product vision to a B2B/enterprise where we have to roster 10,000 or 100,000 kids in one shot, so all the user provisioning, connecting to information systems that these districts have, et cetera, all of this ginormous plumbing that needs to happen in order for it to continue to be easy to use for every single teacher. And alongside with that, the other challenge is we were super appealing to teachers that were interested in games. [laughs] +And so when you think of some teacher who's in their 60s and has never really played any games and just thinks that they're a silly waste of time, there's a different sales pitch that needs to happen there to get them on board and a different onboarding. One of the things we had to completely overhaul was the onboarding to make it really progressive. Classcraft, now when you start it, there's no avatar. It starts super lean on the feature side so that these teachers that are, you know, we're basically educating them as they're using the platform, educating them on all this game stuff. +There are a lot of learnings in terms of what's our actual target audience. And if our target audience starts to be enterprise customers, how do we evolve our platform to appeal to a much more diverse type of persona from a teacher standpoint? +VICTORIA: I was thinking, actually, a good friend of mine who is a teacher and has been running Dungeons & Dragons campaigns for us for several years. +[laughter] +SHAWN: There you go. +VICTORIA: And, like, you'll love it. [laughs] +SHAWN: Exactly. +[laughter] +VICTORIA: But I could see that being a challenge now that you're shifting your target business model, really, and how do you adapt to that? +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode. +VICTORIA: What else are you looking ahead with Classcraft? What's on the horizon? +SHAWN: There's a lot. Like I said, we have 10 million kids in the platform plus. But we have teachers in every single country you could imagine, and there's a universality to what we're proposing. We're not saying here's the best tool for fifth-grade math in the U.S. We're saying, solve this universal human problem that's prevalent in education. And so we have teachers in, you name it, Taiwan, and Australia, and Singapore, and all over Europe using Classcraft. And so there's definitely opportunity for us to look at the international landscape and identify opportunities. +Another frontier beyond going out of North America is going beyond the brick-and-mortar experience of the classroom. A lot of what's happening in and around your software is actually not happening 18 inches from the screen. It's happening in this context where there are 30 other kids, and there are all these interactions going on. For example, if you made a reading app, you can imagine the kids sitting in a quiet space on their sofa at home reading this thing, but the reality that's happening is they're in a really loud classroom [laughs] with lots of other kids around them, et cetera. And so the design context for designing for edtech is really interesting. +We have some views that are meant to be only on a projector in front of the class. And when that happens, the font size needs to be 80 point because a kid in the back needs to be able to see it. So the screen real estate you're playing with is pretty unique scenarios. Like, what does this look like at 120 feet, let's say, because people are using it in the gym? So interesting design challenges, but they have been really ensconced in the idea that a lot of how people are using Classcraft is with real-life physical situations. +But Classcraft, in essence, we have an API. So you can also imagine behaviors that are not brick and mortar behaviors, like, if I'm being participative, that's something that a teacher would see and observe and give you points for. But there are 3,000 edtech platforms, and all of them have digital behaviors that teachers want to see. They want to see kids handing in homework in these platforms. They want to go see them complete assignments. They want to go see them participating in digital communities. These are all basically the new frontier for digital behaviors that are a part now post-pandemic of the ecosystem of education. +And so we're really interested in connecting to other platforms. I don't need kids to be in Classcraft; I just need them every day. I need them to be earning points. And I'm happy if they're doing that in other platforms and that those interactions are rewarding them experience points and points in Classcraft. And ideally, automatically, that way, the teachers don't have to do anything. +VICTORIA: And so you're integrating with all these different platforms, and you're working with all these different school districts. So you've had to make some difficult technology choices in your stack. Do you have any examples of those? +SHAWN: Yeah, absolutely. When I started the company, I'd come out of programming in...I started building cool websites in ActionScript, [laughs] so that dates me a little bit. But I'd just come out of a decade of ActionScript and PHP. And I'm like, PHP does not scale, and it doesn't afford the same type of real-time interactions that you'd expect from a game. When I decided what the tech stack would be, right at the outset, it was, okay, we're going to do this all JavaScript. It's going to be Node. And at that time...now that's a pretty, like, anybody would make that decision. But this was nine years ago, and it wasn't as mature as it is now. +And so that was a pretty ballsy move and one that we never looked back on. But we had a lot of things that we had to build ourselves because the libraries didn't exist yet. And we were really pushing the edge of what was possible in a browser, especially in a browser in school with a crappy internet connection. And often, they are on older browsers. Although it was the right decision to lean into the leading edge on the tech stack, it did afford us with a lot of specific challenges that we might not have had if we'd said, oh, let's just keep this super old school. +Some other things that we've been challenged with over the years is just scaling the number of concurrent users is always a thing. When we started, we had a single database, one server, and I was doing all the DevOps. And a lot of what we've done since that is just move everything to services. So we've got, you know, MongoDB database-as-a-service. [laughs] We're all on Google Cloud now. +From an IT standpoint, we think a lot about what stack we're going to be using. And to me, what really matters is build the product as fast as you can and as well as you can. So outsourcing all of the DevOps pieces to cloud providers is, in my opinion, [laughs] a really good use of funds versus maintaining it yourself and spending tons of money on sys engineers and architects. +The reality is that for most products today, what exists as a service in the cloud already bundled is, you know, and we've got auto-scaling. When there are too many concurrent users, it automatically spins up new Docker servers, et cetera. So we've really evolved from this monolithic single-server approach to this imminently highly scalable solution that is all virtualized, but in doing that, moved all of it to services. +And I think that's the right move because we're not, you know, if I was really, really core, if was, I don't know, [chuckles] an online video game, then the speed of connections and all these things become super important. But in our case, reliability, scalability is more important than the fine-tuning to a precise degree of specific tech infrastructure. +And I'm seeing more and more founders now, Victoria, as well go-to codeless solutions as well. I think we're kind of abstracting a lot of what was core to product development from a tech side. You know, first, it was the DevOps, then it was the cloud, and even now, code, I think, is moving in the direction where we're systematizing, bundling, and having other services generate code more and more. I think we're moving towards that just in software in general. +VICTORIA: Yeah, I think that is becoming prevalent. I do think low-code automation has also been coming around every 5 or 10 years or so. [laughs] I have the belief that technology never disappears; it just keeps building, and new tech gets created, and the user base shifts around a little bit. And, of course, for you as a technical founder, putting it all in Docker and setting up the auto scaling on Google is probably within your reach, whereas a lot of founders, that might be something more challenging, and you might need to have some support for. +But that's essentially what we work on for Mission Control as well is helping teams set up their platform so that it will scale automatically that if there's an issue, you know about it in advance. [laughs] You can take care of it before it falls over, and that way, your users just see a reliable, happy system. +SHAWN: I'm so grateful that I am a technical founder. [laughs] I know a lot of founders, and the ones that don't know how to code really are at the mercy of so many unknown variables. I'm not coding anymore, but I'm very aware of what's going on in the platform. And I think that helps me make better business decisions every day. So I have a lot of gratitude when I compare myself in that regard. +VICTORIA: And I think it's really about communication then too. Like, having a good understanding of your system is helpful but being able to understand it well enough to then communicate it to other people, and what the value is, and how you want to invest money in different parts of the system. I think those are two things that having maybe a little bit more of experience in technology and then also having a teacher experience, I think, sets you up to be successful. +But we also, of course, at thoughtbot, we offer a lot of that technical expertise to help founders navigate some of that. So there's a little pitch just for us. [laughs] But let's see, let me go through...I think I've gone through a good amount of questions. Here's one that I like to ask everybody. But if you could travel back in time to when you first started Classcraft, what would be the main piece of advice you would give yourself? +SHAWN: If I could go back, there are some big lessons that have been learned. I've been for almost a decade now as a founder and CEO. One of the things we didn't do early enough was user testing. If I split the life of Classcraft into three eras, there's the first third we didn't need to because we had all of my own experience. But once we started moving past what was the initial product that I had built in my own classroom, we continued to make assumptions. +And we, of course, always listen to our users, but now we're super systematic about it, and any new feature has research behind it and a really solid UX practice that we should have implemented much earlier. I think we're making much better roadmap decisions today than we were three years ago. A lot of companies hire UX people super late, and I would do that early or at least develop the chops to do it myself as early as possible. So I think that's one thing. +I think as well...and maybe this is tied to that. I think we should have and could have iterated faster as well. A lot of startups in the tech scene talk about iteration, but there's a difference between incrementally iterating and just adding on, adding on, adding on, and actually making the kind of iterative decisions that, for example, pulling part of the product and discontinuing it for example. And we've done some of those moves, but I think we could have done them faster. And we should have done them faster if we'd had that UX research data to help us make decisions faster. +So it's more than, like, common truism is like, oh, listen to your users and listen to their feedback. Like, yes, that's true, and we were doing that. But I'd say go further and create robust structures to get that data faster, not just wait for it to come in but actually go out and get it and digest it in a way that's actually usable. Because you have a whole bunch of testimonials and feedback, but if it's not organized, it's not somebody's job to make sense of it. It's just kind of sitting there. So there's a lot of value from that perspective that you can quickly generate for your users and, therefore, for your business. +VICTORIA: Right. Save you some time and some money, probably in validating your ideas, right? +SHAWN: Yeah. And the problem with education is that it's a yearly cycle, right? +VICTORIA: Mmm-hmm. +SHAWN: We're not looking at monthly scales; we're looking at the whole school year. So back to school happens once a year, and that's when you get a ton of data because that's when there's the most activity. Like, right now, August, September, October, these are the moments where we're getting the most data. And then when you make changes, you got to wait all the way back to the next back to school. +So, in particular, in education, I think the cycles are long versus, let's say, more B2C-type consumer verticals where the test length is like a week. [laughs] So if it's coming once a year, you better make sure you're organized, I guess, is what I'm saying. [laughs] +VICTORIA: Because we only have one shot. [laughs] +SHAWN: Yeah, exactly. +VICTORIA: That makes sense. Well, thank you so much for sharing all those insights. And I want to give you a chance to promote anything else you'd like to share with our listeners. +SHAWN: Thank you so much for the conversation, Victoria. I appreciate it. I think if anybody wants to find out about Classcraft, classcraft.com, tons of content and resources that we're generating about these topics of building meaningful relationships in school but in general with human beings. +Classcraft is a B Corp, and so for people who don't know what that is, it's a certification around impact. And so we have built-in commitment to generate good in the world. And it's a pretty hard certification to get, so we're pretty proud about it. But I think that this commitment that we have of generating meaningful relationships both with kids but also with our employees, with our community, with our different stakeholders, has been really core to a lot of the decisions we make and how we make them, and how we approach different problems. +And so I think that as a tech founder, sometimes we can lose sight of what are we actually generating in the world. And so I would encourage people to think about, you know, if you're thinking about starting a company or thinking about your own company and the impact its having to look up that certification. But also, just look up triple bottom line, these types of concepts that are becoming more and more prevalent that really give meaning to the endeavor. +Starting a company and running it is a lot of work. You need to believe in what you're doing. [laughs] And I think having a mission that generates impact in that way is a good way to motivate yourself and your team to go the extra mile and deliver. +VICTORIA: I love that. And did we really cover the full impact this app has had on kids that are using it in schools? +SHAWN: There's a ton of research about Classcraft; actually, that's been done by pedagogy professors in colleges. Literally, thousands of papers have been written on Classcraft because there just aren't a lot of...everybody's interested in student motivation. There aren't a lot of scalable systems for doing that other than Classcraft. And so a lot of research that's been done about that topic incidentally happens to be using Classcraft. And a recent meta-study about Classcraft was conducted, and they saw a significant statistical impact on student motivation and learner outcomes. +And so it's hard in education to really understand impact easily because it's social sciences. So you need a lot of big data samples, and you need the control groups. It's complicated. So we're pretty proud about that because a lot of companies that work in education don't have that kind of hard data. It's like, okay, it seems to be having an impact. We've got pretty hard proof; literally hundreds of millions of positive behaviors that kids have done that are being reinforced every single year. And when you think about that, most kids don't get any positive feedback. +The kids that get the most attention are the ones that are acting out and being the worst. So 90% of teacher energy is being directed at 10% of the kids, and so most kids go through school without ever feeling a sense of belonging, or accomplishment, or praise. And we've had kids write us saying, "I was suicidal. Classcraft changed my life," like these types of user testimonies where the impact, the human impact of the approach, is really, really real. And for teachers as well, like, "I was so demotivated with teaching. I found the spark again thanks to Classcraft because school is fun again." [laughs] So there's a lot to be proud of there, for sure. +VICTORIA: That's wonderful and really powerful that you've had that impact and have been able to see it both from a scientific perspective and from those user testimonies. So I think that's wonderful. And I think it's an inspiring story. And that's probably why you're also so involved; it seems, in leadership groups in edtech and in other communities in Quebec. Is that right? +SHAWN: Yeah, totally. I mean the reality...so I'm the president of the Edtech Association here in Quebec, which I helped co-found. We've got 100-plus organizations working in edtech that are part of the association. I'm also Co-chair for The Global Collective for Social Emotional Learning, Digital Learning for UNESCO. And I have been involved in numerous different systemic endeavors in education throughout the years. +The truth is changing education is hard, and the way we're going to succeed is...it's fundamentally something I believe that we should really be focusing on as a society is improving education, education outcomes. All the positive changes we need to see to tackle the incredible challenges that are upcoming for us as a species are going to happen through education. But for that to happen, we need to make education evolve, and for education to evolve, we need to all work together. +So the association is interesting because it's like a coopetition [laughs] in a sense. All these entrepreneurs we're all competing for the same budget dollars, but we're looking at education problems in different ways. And if we're more successful as an industry, individually, everybody's going to be more successful, and more kids are going to be impacted. So I just believe that and this is true specifically for education, but I do believe this for any vertical. If businesses are collaborating to elevate, if the water rises, everybody's boat goes up. I really believe that that's true in business in general and in education in particular. +VICTORIA: It reminds me when I was at Pluribus Digital in my last position. We were a part of the Digital Services Coalition, which is another coopetition group of federal contractors who are going after the same money. But we are all trying to see the government be better, part of that collaboration which sounds like what Classcraft is all about too. We're all in it together. [laughs] +SHAWN: Yeah. And if that's not the case, especially for incumbents, then what happens is status quo. And for startups, for tech companies, usually the status quo [laughs] is bad. That's where you're trying to generate opportunity from. But sometimes the systems that are there, government systems in particular...we've seen a lot in health as well over the last few years in clean tech. All of these impact tech sectors part of what they're fighting against are market forces of status quo. And so it's only by all working together that we can really move that. +VICTORIA: Yeah, absolutely. I'm sure we could keep talking about that for a long time. [laughs] But unless you have anything else you'd like to share, I'll go ahead and wrap up. +You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Shawn Young. + + + Shawn Young is the CEO and Co-Founder of Classcraft, an innovative platform that motivates students using the culture and mechanics of games.

+ +

Victoria talks to Shawn about edtech, behavior intervention, and the challenges he's faced with going from a homegrown tool to something big and out there in the world.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Shawn Young, the CEO, and Co-Founder at Classcraft, an innovative platform that motivates students using the culture and mechanics of games. Shawn, thank you for joining us.

+ +

SHAWN: Thank you. Thanks for having me, Victoria. I'm happy to be here.

+ +

VICTORIA: Wonderful, yes. So just tell me a little bit about yourself and maybe what brought you to start out as a teacher initially.

+ +

SHAWN: [laughs] I have an interesting journey. I was originally a physicist, a physics major. Although I loved physics because it really gives you a deep understanding of the world, I realized that physics research in a basement with machines just on your own [laughs] wasn't for me, so that's when I started substitute teaching. I really wasn't going to go into education at all. It was just there was availability, lack of teachers.

+ +

And it's kind of ironic. I really did not enjoy school. High school, in particular, was just a really challenging time for me, mostly because I just didn't see the point of it. I didn't have any problems in school. I had great grades, but I just was bored out of my mind. And so, as a teacher, I became really, really obsessed with making school meaningful for the students that were there, and because so many kids, so many learners just don't see the point.

+ +

And so I did a lot of really cool project-based learning type of stuff. So that's where instead of lecturing the kids, you get them doing things and learning by doing. And so I was teaching physics, obviously. And so we were building hot air balloons and cannons and all kinds of stuff to study Newtonian physics. And kids were super happy to come to the class because we were doing some cool stuff.

+ +

But I realized as that was happening that another part of meaning generation for kids and learners is the community and the social aspects. And so, I started thinking about how I can build community in the classroom, make the social experience of school relevant for them? And that's how Classcraft was born, really. I kind of put together my interest in motivating and building community with kids. I was a developer at the time as well, so I was able to develop a platform. And, of course, I'm a gamer, so I kind of put all those things together and built this platform in my classroom.

+ +

VICTORIA: That's great. I was going to ask what skills or experiences from your teaching background translated to being a founder.

+ +

SHAWN: That's interesting because clearly in the product...Classcraft was never meant to be a company. I already had a company. [laughs] I was freelancing as a developer for pretty large clients in New York. I was working with my brother, who's a creative director there. And we worked for Chanel for three years building apps and websites, and that was probably our biggest client. I wasn't looking to make a company. I just built it for me. It was my quest to make school meaningful and relevant.

+ +

And after three years of just tinkering around with it with my students, I realized it was having a massive impact on their outlook, on the way they collaborated together, on their motivation. And because Classcraft is a platform that basically gamifies education, so kids level up and they earn points. They're on teams. They have a character class. All the things you would see in an RPG are translating to how teachers are running a school.

+ +

And so I made a website just to talk about it after three years of this garage project I had going on. And the day that website went online, 130,000 people came to the website. It just started trending on Reddit gaming. And overnight, a lot of people were asking, "How do I download this?" I'm like, "You can't. There's no company." [laughter] So that's how the company started.

+ +

Teaching is an interesting profession. I think that teaching is a job that requires you to, A, motivate and manage a whole bunch of people, so there's a lot similarility there to management. It's a group of humans that you want to work together to get to their full potential, just like your team should be. But then there's also independent planning. As a teacher, you have a set amount of time to get through X amount of curriculum. So you're always, you know, project management basically, 101 is the same thing as running a curriculum through the year.

+ +

So there are a lot of those types of soft skills that translate really easily to entrepreneurship. And ultimately, as a teacher, you're responsible on your own for your own successes and failures, which is the type of attitude you need to have if you're going to be a successful entrepreneur is to be responsible, you know, [laughs] take control of your destiny a little bit.

+ +

VICTORIA: Right. I hadn't thought about it from that angle. It makes a lot of sense. You're really an independent owner of that classroom, right? [laughs]

+ +

SHAWN: Yeah, exactly, exactly. And trying to get humans to collaborate and do stuff sounds a lot like running a company. [laughs]

+ +

VICTORIA: Right. I saw the tagline on Classcraft: relationships are everything. And I was like, that's a perfect DevOps kind of statement. [laughs]

+ +

SHAWN: Yeah, that's funny. [laughs] We're thinking more like human relationships, but that's so funny [laughs] from the DevOps side for sure.

+ +

VICTORIA: In and outside of the classroom, you need...it doesn't matter how great your technology is or your strategy. If the people aren't talking to each other and you don't have the right relationships, you're not going to be successful.

+ +

SHAWN: Correct. And ultimately, that's the value proposition of Classcraft. Schools that don't build good relationships between students that don't do it between teachers and students, that don't do it between teachers and administration are dysfunctional. And what we're seeing in education today is one of the fundamental breakdowns that's happening and, you know, that's proxy for what's happening at large, and society is relationships are quite strange right now in schools, and that's making it really hard for them to be effective.

+ +

VICTORIA: Right. It sounds like this app was built out of your direct experience and your direct experience working with these students. What do you find is unique in working with students, and how do you appeal to them as a user base?

+ +

SHAWN: What's really special about edtech is that your buyer or the user that makes the decision to use the product is not the end user, and that's true in all B2B, SaaS. The decision maker who purchases the software isn't necessarily the employee who's going to use it. But in education, there are multiple levels. Like, if we sell to a district, they're the ones buying, but ultimately, they need to get the teachers to use it. And then, at the end of the day, the actual real users are the students.

+ +

And so, there are a lot of design considerations when you think of UX. And even when you think of user permissions, there's a lot of complexity there in education because our goal is to build as much motivation and engagement mechanics as we can for kids. And so that means leveling up, and random loot drops, and all these things you see in video games but applying that to school.

+ +

But then you need to build all this plumbing [laughs] basically to make it usable by a user who's the teacher who doesn't really know much about games, and that's changing as the teacher...average age of teachers is going down, a lot of retirements, et cetera, so that's changing. But at the base of it, the kids are really well versed in games, game mechanics, game culture, but the teacher who's running it is not.

+ +

So we have to speak two languages, one of pedagogy, and classroom tools, and data, and saving time. These are the things that educators care about. And incidentally, they care about motivation and motivating the kids, and all of those things. But for kids, we're talking about avatars, and pets, and gear, and leveling up, and all this whole other set of language.

+ +

And so when you think of design considerations, we always have to be thinking about how do I make this as motivating and engaging as possible for the kids, but how do I make it as easy to use and not complicated for teachers? Because if the teachers don't use it, then these kids aren't going to see the value anyways. So it's pretty complex because we don't have one single end user.

+ +

VICTORIA: And so you have the challenge of making it fun for kids and then also providing useful and understandable data for teachers and probably parents and other people, right?

+ +

SHAWN: Yeah, yeah, exactly. There are lots of stakeholders.

+ +

[laughter]

+ +

VICTORIA: So I want to ask more about how you make it fun, and then I also want to know more about the teacher's perspective, so whichever one you want to start with first.

+ +

SHAWN: Perfect. I mean, those two questions are literally the placement of what Classcraft is. Classcraft is the Venn diagram between what in education is behavior intervention, so managing kids' behavior and motivation. And so, from a motivation angle, how do we make it engaging for kids? In essence, kids are earning points in Classcraft for things that they're doing in school that we want them to do. And by we, schools can configure whatever it is, but it'll be things like handing in homework, being respectful, being inclusive, participating, being on time, these behaviors that they want to see in kids to make them better learners.

+ +

When those behaviors occur, teachers can give them points. And the points allow them to level up. As they level up, they each have a character. They have an avatar, and they can be warriors, healers, or mages. And based on that character class, they have a different role in the team. So they're playing in teams just like in an MMORPG or on a football team. And everybody has a different role within the team. And you win as a team.

+ +

And so school is quite competitive. Kids are always compared to the class average and their grades. And there's a lot of competition happening in schools. What we've built is a way for kids to be motivated by collaboration. And so they're playing on teams. If they do good things, they get these points, and they level up. And there are millions of combinations of gear that they could buy for their avatar, but they're also unlocking real-life powers.

+ +

And so these powers are things like, you know, in a video game, power could be like you could shoot a fireball. In Classcraft, shoot a fireball is the equivalent of you can skip a question on an exam, or you can go to the bathroom, or you can hand in homework a day late, or you can listen to music while you're doing your classwork, so giving them real-life privileges as they level up. And these aren't one-offs; they're skills that they have that they can trigger whenever they want, just like in a game.

+ +

And some of those skills are things like being able to heal up your teammate because kids can also lose lives if they do negative things. So if you're late or you're rude, or whatever it is, just like in Mario, what's failing in Mario is falling in a hole, and what's failing as a student, it's not doing what you're supposed to do, or being a bully to other kids. And so, as that happens, they can lose lives. But then they can come in to help each other out. There are boss battles where they can fight monsters by answering quiz questions, et cetera.

+ +

So all these motions that are ultimately the things that are happening anyways in school, what we're saying is instead of punishing kids or forcing them to do this stuff, make it feel like a game. Speak their language, use the same mechanics that we know are super effective at motivating players. Nobody is forcing people to play video games. Everybody's doing that of their own volition. It's the most popular cultural medium that exists today, well surpassing film, movies, music. And so, why are games so good at doing that? It's because they fulfill fundamental needs: being in control, feeling like we're progressing, social relatedness. That's what we're bringing to school. So that's the student side of it.

+ +

The other side of it, behavior intervention, is...well, one of the biggest challenges for teachers is managing kids. It's not like showing you how to do a math problem; it's getting you to care about it, listen to it, stop disturbing other people. And so, a lot of time and energy is spent on classroom management for teachers. And so what we do is we use best practices there. For example, there's a lot of research out there in education that says that praising kids for good behavior is a lot more effective than punishing them.

+ +

And so games are really good at praising you. You level up, and you gain points. It tells you your score. What we're doing here is giving them that framework but applying that to classroom management. And so instead of saying, "Hey, Victoria, stop goofing off," or "You're not dressed well, go to the principal," or whatever it is that's happening in schools, what we're telling teachers to do instead is say, "Hey if Victoria does something good, recognize her. Give her a high five." And in Classcraft, a high five is gaining points.

+ +

And so we're shifting and applying this pedagogy, shifting towards a positive reinforcement mindset. And at the same time, because these high fives are digital, then you get all the data so you can know which behaviors did Victoria do at which time with which teacher? Hey, she didn't get a lot of points this week. What's going on with her? Maybe we should talk to her and see what's going on before her behavior escalates. And so there's a lot of value from a behavior intervention standpoint. But ultimately, it's super effective because the kids really care about it in a way that they don't normally care about classroom management.

+ +

VICTORIA: Well, that makes a lot of sense. And I'm hearing something I've studied before when looking at technology organizations which is that growth mindset I think you're describing, the positive reinforcement, praising the effort for something versus their intrinsic skills. And that's something I love about teaching. I think that really, really translates to running a technology organization.

+ +

SHAWN: Yeah, totally. Ultimately, what we're doing is giving schools and teachers a platform for really effective culture building. And what you're talking about is culture within a company, in essence, and it's really the same thing. It goes back to what I was saying earlier about managing a group of kids [laughs], and managing employees is super similar. It's all about what type of positive culture you are building.

+ +

VICTORIA: I think there's something really universal about that. It's actually even true with dog training. I have a dog, and it's the same kind of motivational theory that works for them too. [laughs]

+ +

SHAWN: Yep, yep.

+ +

VICTORIA: I love it. And you mentioned that you built this tool yourself, and then suddenly, it became very popular, and now it's really, I'm sure, scaling. So what challenges have you faced with going from this homegrown tool to something big and out there in the world?

+ +

SHAWN: Lots of challenges. [laughs] I would say working in education itself is a challenge. It's a pretty challenging vertical to work in. It's ripe for disruption at the same time, pretty conservative. There are a lot of forces working in education systemically not have it move forward. Working with schools and districts is challenging. They have a lot of requirements. And, of course, they're custodians of kids, so that's legitimate, but it does make it more challenging.

+ +

One of the things that we had to evolve was we were very much a teacher-only tool when we started. I had built it as a teacher. Our user in mind was a teacher. Even our business model initially was selling to teachers basically. There was a free version, and they could upgrade to a paid version. And as we got more and more scale, you know, we have ten million-plus kids in the platform now. As we got more and more scale, what ended up happening was we were working more and more with schools and districts.

+And so we went from a B2C go-to-market and product vision to a B2B/enterprise where we have to roster 10,000 or 100,000 kids in one shot, so all the user provisioning, connecting to information systems that these districts have, et cetera, all of this ginormous plumbing that needs to happen in order for it to continue to be easy to use for every single teacher. And alongside with that, the other challenge is we were super appealing to teachers that were interested in games. [laughs]

+ +

And so when you think of some teacher who's in their 60s and has never really played any games and just thinks that they're a silly waste of time, there's a different sales pitch that needs to happen there to get them on board and a different onboarding. One of the things we had to completely overhaul was the onboarding to make it really progressive. Classcraft, now when you start it, there's no avatar. It starts super lean on the feature side so that these teachers that are, you know, we're basically educating them as they're using the platform, educating them on all this game stuff.

+ +

There are a lot of learnings in terms of what's our actual target audience. And if our target audience starts to be enterprise customers, how do we evolve our platform to appeal to a much more diverse type of persona from a teacher standpoint?

+ +

VICTORIA: I was thinking, actually, a good friend of mine who is a teacher and has been running Dungeons & Dragons campaigns for us for several years.

+ +

[laughter]

+ +

SHAWN: There you go.

+ +

VICTORIA: And, like, you'll love it. [laughs]

+ +

SHAWN: Exactly.

+ +

[laughter]

+ +

VICTORIA: But I could see that being a challenge now that you're shifting your target business model, really, and how do you adapt to that?

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: What else are you looking ahead with Classcraft? What's on the horizon?

+ +

SHAWN: There's a lot. Like I said, we have 10 million kids in the platform plus. But we have teachers in every single country you could imagine, and there's a universality to what we're proposing. We're not saying here's the best tool for fifth-grade math in the U.S. We're saying, solve this universal human problem that's prevalent in education. And so we have teachers in, you name it, Taiwan, and Australia, and Singapore, and all over Europe using Classcraft. And so there's definitely opportunity for us to look at the international landscape and identify opportunities.

+ +

Another frontier beyond going out of North America is going beyond the brick-and-mortar experience of the classroom. A lot of what's happening in and around your software is actually not happening 18 inches from the screen. It's happening in this context where there are 30 other kids, and there are all these interactions going on. For example, if you made a reading app, you can imagine the kids sitting in a quiet space on their sofa at home reading this thing, but the reality that's happening is they're in a really loud classroom [laughs] with lots of other kids around them, et cetera. And so the design context for designing for edtech is really interesting.

+ +

We have some views that are meant to be only on a projector in front of the class. And when that happens, the font size needs to be 80 point because a kid in the back needs to be able to see it. So the screen real estate you're playing with is pretty unique scenarios. Like, what does this look like at 120 feet, let's say, because people are using it in the gym? So interesting design challenges, but they have been really ensconced in the idea that a lot of how people are using Classcraft is with real-life physical situations.

+ +

But Classcraft, in essence, we have an API. So you can also imagine behaviors that are not brick and mortar behaviors, like, if I'm being participative, that's something that a teacher would see and observe and give you points for. But there are 3,000 edtech platforms, and all of them have digital behaviors that teachers want to see. They want to see kids handing in homework in these platforms. They want to go see them complete assignments. They want to go see them participating in digital communities. These are all basically the new frontier for digital behaviors that are a part now post-pandemic of the ecosystem of education.

+ +

And so we're really interested in connecting to other platforms. I don't need kids to be in Classcraft; I just need them every day. I need them to be earning points. And I'm happy if they're doing that in other platforms and that those interactions are rewarding them experience points and points in Classcraft. And ideally, automatically, that way, the teachers don't have to do anything.

+ +

VICTORIA: And so you're integrating with all these different platforms, and you're working with all these different school districts. So you've had to make some difficult technology choices in your stack. Do you have any examples of those?

+ +

SHAWN: Yeah, absolutely. When I started the company, I'd come out of programming in...I started building cool websites in ActionScript, [laughs] so that dates me a little bit. But I'd just come out of a decade of ActionScript and PHP. And I'm like, PHP does not scale, and it doesn't afford the same type of real-time interactions that you'd expect from a game. When I decided what the tech stack would be, right at the outset, it was, okay, we're going to do this all JavaScript. It's going to be Node. And at that time...now that's a pretty, like, anybody would make that decision. But this was nine years ago, and it wasn't as mature as it is now.

+ +

And so that was a pretty ballsy move and one that we never looked back on. But we had a lot of things that we had to build ourselves because the libraries didn't exist yet. And we were really pushing the edge of what was possible in a browser, especially in a browser in school with a crappy internet connection. And often, they are on older browsers. Although it was the right decision to lean into the leading edge on the tech stack, it did afford us with a lot of specific challenges that we might not have had if we'd said, oh, let's just keep this super old school.

+ +

Some other things that we've been challenged with over the years is just scaling the number of concurrent users is always a thing. When we started, we had a single database, one server, and I was doing all the DevOps. And a lot of what we've done since that is just move everything to services. So we've got, you know, MongoDB database-as-a-service. [laughs] We're all on Google Cloud now.

+ +

From an IT standpoint, we think a lot about what stack we're going to be using. And to me, what really matters is build the product as fast as you can and as well as you can. So outsourcing all of the DevOps pieces to cloud providers is, in my opinion, [laughs] a really good use of funds versus maintaining it yourself and spending tons of money on sys engineers and architects.

+ +

The reality is that for most products today, what exists as a service in the cloud already bundled is, you know, and we've got auto-scaling. When there are too many concurrent users, it automatically spins up new Docker servers, et cetera. So we've really evolved from this monolithic single-server approach to this imminently highly scalable solution that is all virtualized, but in doing that, moved all of it to services.

+ +

And I think that's the right move because we're not, you know, if I was really, really core, if was, I don't know, [chuckles] an online video game, then the speed of connections and all these things become super important. But in our case, reliability, scalability is more important than the fine-tuning to a precise degree of specific tech infrastructure.

+ +

And I'm seeing more and more founders now, Victoria, as well go-to codeless solutions as well. I think we're kind of abstracting a lot of what was core to product development from a tech side. You know, first, it was the DevOps, then it was the cloud, and even now, code, I think, is moving in the direction where we're systematizing, bundling, and having other services generate code more and more. I think we're moving towards that just in software in general.

+ +

VICTORIA: Yeah, I think that is becoming prevalent. I do think low-code automation has also been coming around every 5 or 10 years or so. [laughs] I have the belief that technology never disappears; it just keeps building, and new tech gets created, and the user base shifts around a little bit. And, of course, for you as a technical founder, putting it all in Docker and setting up the auto scaling on Google is probably within your reach, whereas a lot of founders, that might be something more challenging, and you might need to have some support for.

+ +

But that's essentially what we work on for Mission Control as well is helping teams set up their platform so that it will scale automatically that if there's an issue, you know about it in advance. [laughs] You can take care of it before it falls over, and that way, your users just see a reliable, happy system.

+ +

SHAWN: I'm so grateful that I am a technical founder. [laughs] I know a lot of founders, and the ones that don't know how to code really are at the mercy of so many unknown variables. I'm not coding anymore, but I'm very aware of what's going on in the platform. And I think that helps me make better business decisions every day. So I have a lot of gratitude when I compare myself in that regard.

+ +

VICTORIA: And I think it's really about communication then too. Like, having a good understanding of your system is helpful but being able to understand it well enough to then communicate it to other people, and what the value is, and how you want to invest money in different parts of the system. I think those are two things that having maybe a little bit more of experience in technology and then also having a teacher experience, I think, sets you up to be successful.

+ +

But we also, of course, at thoughtbot, we offer a lot of that technical expertise to help founders navigate some of that. So there's a little pitch just for us. [laughs] But let's see, let me go through...I think I've gone through a good amount of questions. Here's one that I like to ask everybody. But if you could travel back in time to when you first started Classcraft, what would be the main piece of advice you would give yourself?

+ +

SHAWN: If I could go back, there are some big lessons that have been learned. I've been for almost a decade now as a founder and CEO. One of the things we didn't do early enough was user testing. If I split the life of Classcraft into three eras, there's the first third we didn't need to because we had all of my own experience. But once we started moving past what was the initial product that I had built in my own classroom, we continued to make assumptions.

+ +

And we, of course, always listen to our users, but now we're super systematic about it, and any new feature has research behind it and a really solid UX practice that we should have implemented much earlier. I think we're making much better roadmap decisions today than we were three years ago. A lot of companies hire UX people super late, and I would do that early or at least develop the chops to do it myself as early as possible. So I think that's one thing.

+ +

I think as well...and maybe this is tied to that. I think we should have and could have iterated faster as well. A lot of startups in the tech scene talk about iteration, but there's a difference between incrementally iterating and just adding on, adding on, adding on, and actually making the kind of iterative decisions that, for example, pulling part of the product and discontinuing it for example. And we've done some of those moves, but I think we could have done them faster. And we should have done them faster if we'd had that UX research data to help us make decisions faster.

+ +

So it's more than, like, common truism is like, oh, listen to your users and listen to their feedback. Like, yes, that's true, and we were doing that. But I'd say go further and create robust structures to get that data faster, not just wait for it to come in but actually go out and get it and digest it in a way that's actually usable. Because you have a whole bunch of testimonials and feedback, but if it's not organized, it's not somebody's job to make sense of it. It's just kind of sitting there. So there's a lot of value from that perspective that you can quickly generate for your users and, therefore, for your business.

+ +

VICTORIA: Right. Save you some time and some money, probably in validating your ideas, right?

+ +

SHAWN: Yeah. And the problem with education is that it's a yearly cycle, right?

+ +

VICTORIA: Mmm-hmm.

+ +

SHAWN: We're not looking at monthly scales; we're looking at the whole school year. So back to school happens once a year, and that's when you get a ton of data because that's when there's the most activity. Like, right now, August, September, October, these are the moments where we're getting the most data. And then when you make changes, you got to wait all the way back to the next back to school.

+ +

So, in particular, in education, I think the cycles are long versus, let's say, more B2C-type consumer verticals where the test length is like a week. [laughs] So if it's coming once a year, you better make sure you're organized, I guess, is what I'm saying. [laughs]

+ +

VICTORIA: Because we only have one shot. [laughs]

+ +

SHAWN: Yeah, exactly.

+ +

VICTORIA: That makes sense. Well, thank you so much for sharing all those insights. And I want to give you a chance to promote anything else you'd like to share with our listeners.

+ +

SHAWN: Thank you so much for the conversation, Victoria. I appreciate it. I think if anybody wants to find out about Classcraft, classcraft.com, tons of content and resources that we're generating about these topics of building meaningful relationships in school but in general with human beings.

+ +

Classcraft is a B Corp, and so for people who don't know what that is, it's a certification around impact. And so we have built-in commitment to generate good in the world. And it's a pretty hard certification to get, so we're pretty proud about it. But I think that this commitment that we have of generating meaningful relationships both with kids but also with our employees, with our community, with our different stakeholders, has been really core to a lot of the decisions we make and how we make them, and how we approach different problems.

+ +

And so I think that as a tech founder, sometimes we can lose sight of what are we actually generating in the world. And so I would encourage people to think about, you know, if you're thinking about starting a company or thinking about your own company and the impact its having to look up that certification. But also, just look up triple bottom line, these types of concepts that are becoming more and more prevalent that really give meaning to the endeavor.

+ +

Starting a company and running it is a lot of work. You need to believe in what you're doing. [laughs] And I think having a mission that generates impact in that way is a good way to motivate yourself and your team to go the extra mile and deliver.

+ +

VICTORIA: I love that. And did we really cover the full impact this app has had on kids that are using it in schools?

+ +

SHAWN: There's a ton of research about Classcraft; actually, that's been done by pedagogy professors in colleges. Literally, thousands of papers have been written on Classcraft because there just aren't a lot of...everybody's interested in student motivation. There aren't a lot of scalable systems for doing that other than Classcraft. And so a lot of research that's been done about that topic incidentally happens to be using Classcraft. And a recent meta-study about Classcraft was conducted, and they saw a significant statistical impact on student motivation and learner outcomes.

+ +

And so it's hard in education to really understand impact easily because it's social sciences. So you need a lot of big data samples, and you need the control groups. It's complicated. So we're pretty proud about that because a lot of companies that work in education don't have that kind of hard data. It's like, okay, it seems to be having an impact. We've got pretty hard proof; literally hundreds of millions of positive behaviors that kids have done that are being reinforced every single year. And when you think about that, most kids don't get any positive feedback.

+ +

The kids that get the most attention are the ones that are acting out and being the worst. So 90% of teacher energy is being directed at 10% of the kids, and so most kids go through school without ever feeling a sense of belonging, or accomplishment, or praise. And we've had kids write us saying, "I was suicidal. Classcraft changed my life," like these types of user testimonies where the impact, the human impact of the approach, is really, really real. And for teachers as well, like, "I was so demotivated with teaching. I found the spark again thanks to Classcraft because school is fun again." [laughs] So there's a lot to be proud of there, for sure.

+ +

VICTORIA: That's wonderful and really powerful that you've had that impact and have been able to see it both from a scientific perspective and from those user testimonies. So I think that's wonderful. And I think it's an inspiring story. And that's probably why you're also so involved; it seems, in leadership groups in edtech and in other communities in Quebec. Is that right?

+ +

SHAWN: Yeah, totally. I mean the reality...so I'm the president of the Edtech Association here in Quebec, which I helped co-found. We've got 100-plus organizations working in edtech that are part of the association. I'm also Co-chair for The Global Collective for Social Emotional Learning, Digital Learning for UNESCO. And I have been involved in numerous different systemic endeavors in education throughout the years.

+ +

The truth is changing education is hard, and the way we're going to succeed is...it's fundamentally something I believe that we should really be focusing on as a society is improving education, education outcomes. All the positive changes we need to see to tackle the incredible challenges that are upcoming for us as a species are going to happen through education. But for that to happen, we need to make education evolve, and for education to evolve, we need to all work together.

+ +

So the association is interesting because it's like a coopetition [laughs] in a sense. All these entrepreneurs we're all competing for the same budget dollars, but we're looking at education problems in different ways. And if we're more successful as an industry, individually, everybody's going to be more successful, and more kids are going to be impacted. So I just believe that and this is true specifically for education, but I do believe this for any vertical. If businesses are collaborating to elevate, if the water rises, everybody's boat goes up. I really believe that that's true in business in general and in education in particular.

+ +

VICTORIA: It reminds me when I was at Pluribus Digital in my last position. We were a part of the Digital Services Coalition, which is another coopetition group of federal contractors who are going after the same money. But we are all trying to see the government be better, part of that collaboration which sounds like what Classcraft is all about too. We're all in it together. [laughs]

+ +

SHAWN: Yeah. And if that's not the case, especially for incumbents, then what happens is status quo. And for startups, for tech companies, usually the status quo [laughs] is bad. That's where you're trying to generate opportunity from. But sometimes the systems that are there, government systems in particular...we've seen a lot in health as well over the last few years in clean tech. All of these impact tech sectors part of what they're fighting against are market forces of status quo. And so it's only by all working together that we can really move that.

+ +

VICTORIA: Yeah, absolutely. I'm sure we could keep talking about that for a long time. [laughs] But unless you have anything else you'd like to share, I'll go ahead and wrap up.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Shawn Young.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Shawn Young is the CEO and Co-Founder of Classcraft, an innovative platform that motivates students using the culture and mechanics of games.

+ +

Victoria talks to Shawn about edtech, behavior intervention, and the challenges he's faced with going from a homegrown tool to something big and out there in the world.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Shawn Young, the CEO, and Co-Founder at Classcraft, an innovative platform that motivates students using the culture and mechanics of games. Shawn, thank you for joining us.

+ +

SHAWN: Thank you. Thanks for having me, Victoria. I'm happy to be here.

+ +

VICTORIA: Wonderful, yes. So just tell me a little bit about yourself and maybe what brought you to start out as a teacher initially.

+ +

SHAWN: [laughs] I have an interesting journey. I was originally a physicist, a physics major. Although I loved physics because it really gives you a deep understanding of the world, I realized that physics research in a basement with machines just on your own [laughs] wasn't for me, so that's when I started substitute teaching. I really wasn't going to go into education at all. It was just there was availability, lack of teachers.

+ +

And it's kind of ironic. I really did not enjoy school. High school, in particular, was just a really challenging time for me, mostly because I just didn't see the point of it. I didn't have any problems in school. I had great grades, but I just was bored out of my mind. And so, as a teacher, I became really, really obsessed with making school meaningful for the students that were there, and because so many kids, so many learners just don't see the point.

+ +

And so I did a lot of really cool project-based learning type of stuff. So that's where instead of lecturing the kids, you get them doing things and learning by doing. And so I was teaching physics, obviously. And so we were building hot air balloons and cannons and all kinds of stuff to study Newtonian physics. And kids were super happy to come to the class because we were doing some cool stuff.

+ +

But I realized as that was happening that another part of meaning generation for kids and learners is the community and the social aspects. And so, I started thinking about how I can build community in the classroom, make the social experience of school relevant for them? And that's how Classcraft was born, really. I kind of put together my interest in motivating and building community with kids. I was a developer at the time as well, so I was able to develop a platform. And, of course, I'm a gamer, so I kind of put all those things together and built this platform in my classroom.

+ +

VICTORIA: That's great. I was going to ask what skills or experiences from your teaching background translated to being a founder.

+ +

SHAWN: That's interesting because clearly in the product...Classcraft was never meant to be a company. I already had a company. [laughs] I was freelancing as a developer for pretty large clients in New York. I was working with my brother, who's a creative director there. And we worked for Chanel for three years building apps and websites, and that was probably our biggest client. I wasn't looking to make a company. I just built it for me. It was my quest to make school meaningful and relevant.

+ +

And after three years of just tinkering around with it with my students, I realized it was having a massive impact on their outlook, on the way they collaborated together, on their motivation. And because Classcraft is a platform that basically gamifies education, so kids level up and they earn points. They're on teams. They have a character class. All the things you would see in an RPG are translating to how teachers are running a school.

+ +

And so I made a website just to talk about it after three years of this garage project I had going on. And the day that website went online, 130,000 people came to the website. It just started trending on Reddit gaming. And overnight, a lot of people were asking, "How do I download this?" I'm like, "You can't. There's no company." [laughter] So that's how the company started.

+ +

Teaching is an interesting profession. I think that teaching is a job that requires you to, A, motivate and manage a whole bunch of people, so there's a lot similarility there to management. It's a group of humans that you want to work together to get to their full potential, just like your team should be. But then there's also independent planning. As a teacher, you have a set amount of time to get through X amount of curriculum. So you're always, you know, project management basically, 101 is the same thing as running a curriculum through the year.

+ +

So there are a lot of those types of soft skills that translate really easily to entrepreneurship. And ultimately, as a teacher, you're responsible on your own for your own successes and failures, which is the type of attitude you need to have if you're going to be a successful entrepreneur is to be responsible, you know, [laughs] take control of your destiny a little bit.

+ +

VICTORIA: Right. I hadn't thought about it from that angle. It makes a lot of sense. You're really an independent owner of that classroom, right? [laughs]

+ +

SHAWN: Yeah, exactly, exactly. And trying to get humans to collaborate and do stuff sounds a lot like running a company. [laughs]

+ +

VICTORIA: Right. I saw the tagline on Classcraft: relationships are everything. And I was like, that's a perfect DevOps kind of statement. [laughs]

+ +

SHAWN: Yeah, that's funny. [laughs] We're thinking more like human relationships, but that's so funny [laughs] from the DevOps side for sure.

+ +

VICTORIA: In and outside of the classroom, you need...it doesn't matter how great your technology is or your strategy. If the people aren't talking to each other and you don't have the right relationships, you're not going to be successful.

+ +

SHAWN: Correct. And ultimately, that's the value proposition of Classcraft. Schools that don't build good relationships between students that don't do it between teachers and students, that don't do it between teachers and administration are dysfunctional. And what we're seeing in education today is one of the fundamental breakdowns that's happening and, you know, that's proxy for what's happening at large, and society is relationships are quite strange right now in schools, and that's making it really hard for them to be effective.

+ +

VICTORIA: Right. It sounds like this app was built out of your direct experience and your direct experience working with these students. What do you find is unique in working with students, and how do you appeal to them as a user base?

+ +

SHAWN: What's really special about edtech is that your buyer or the user that makes the decision to use the product is not the end user, and that's true in all B2B, SaaS. The decision maker who purchases the software isn't necessarily the employee who's going to use it. But in education, there are multiple levels. Like, if we sell to a district, they're the ones buying, but ultimately, they need to get the teachers to use it. And then, at the end of the day, the actual real users are the students.

+ +

And so, there are a lot of design considerations when you think of UX. And even when you think of user permissions, there's a lot of complexity there in education because our goal is to build as much motivation and engagement mechanics as we can for kids. And so that means leveling up, and random loot drops, and all these things you see in video games but applying that to school.

+ +

But then you need to build all this plumbing [laughs] basically to make it usable by a user who's the teacher who doesn't really know much about games, and that's changing as the teacher...average age of teachers is going down, a lot of retirements, et cetera, so that's changing. But at the base of it, the kids are really well versed in games, game mechanics, game culture, but the teacher who's running it is not.

+ +

So we have to speak two languages, one of pedagogy, and classroom tools, and data, and saving time. These are the things that educators care about. And incidentally, they care about motivation and motivating the kids, and all of those things. But for kids, we're talking about avatars, and pets, and gear, and leveling up, and all this whole other set of language.

+ +

And so when you think of design considerations, we always have to be thinking about how do I make this as motivating and engaging as possible for the kids, but how do I make it as easy to use and not complicated for teachers? Because if the teachers don't use it, then these kids aren't going to see the value anyways. So it's pretty complex because we don't have one single end user.

+ +

VICTORIA: And so you have the challenge of making it fun for kids and then also providing useful and understandable data for teachers and probably parents and other people, right?

+ +

SHAWN: Yeah, yeah, exactly. There are lots of stakeholders.

+ +

[laughter]

+ +

VICTORIA: So I want to ask more about how you make it fun, and then I also want to know more about the teacher's perspective, so whichever one you want to start with first.

+ +

SHAWN: Perfect. I mean, those two questions are literally the placement of what Classcraft is. Classcraft is the Venn diagram between what in education is behavior intervention, so managing kids' behavior and motivation. And so, from a motivation angle, how do we make it engaging for kids? In essence, kids are earning points in Classcraft for things that they're doing in school that we want them to do. And by we, schools can configure whatever it is, but it'll be things like handing in homework, being respectful, being inclusive, participating, being on time, these behaviors that they want to see in kids to make them better learners.

+ +

When those behaviors occur, teachers can give them points. And the points allow them to level up. As they level up, they each have a character. They have an avatar, and they can be warriors, healers, or mages. And based on that character class, they have a different role in the team. So they're playing in teams just like in an MMORPG or on a football team. And everybody has a different role within the team. And you win as a team.

+ +

And so school is quite competitive. Kids are always compared to the class average and their grades. And there's a lot of competition happening in schools. What we've built is a way for kids to be motivated by collaboration. And so they're playing on teams. If they do good things, they get these points, and they level up. And there are millions of combinations of gear that they could buy for their avatar, but they're also unlocking real-life powers.

+ +

And so these powers are things like, you know, in a video game, power could be like you could shoot a fireball. In Classcraft, shoot a fireball is the equivalent of you can skip a question on an exam, or you can go to the bathroom, or you can hand in homework a day late, or you can listen to music while you're doing your classwork, so giving them real-life privileges as they level up. And these aren't one-offs; they're skills that they have that they can trigger whenever they want, just like in a game.

+ +

And some of those skills are things like being able to heal up your teammate because kids can also lose lives if they do negative things. So if you're late or you're rude, or whatever it is, just like in Mario, what's failing in Mario is falling in a hole, and what's failing as a student, it's not doing what you're supposed to do, or being a bully to other kids. And so, as that happens, they can lose lives. But then they can come in to help each other out. There are boss battles where they can fight monsters by answering quiz questions, et cetera.

+ +

So all these motions that are ultimately the things that are happening anyways in school, what we're saying is instead of punishing kids or forcing them to do this stuff, make it feel like a game. Speak their language, use the same mechanics that we know are super effective at motivating players. Nobody is forcing people to play video games. Everybody's doing that of their own volition. It's the most popular cultural medium that exists today, well surpassing film, movies, music. And so, why are games so good at doing that? It's because they fulfill fundamental needs: being in control, feeling like we're progressing, social relatedness. That's what we're bringing to school. So that's the student side of it.

+ +

The other side of it, behavior intervention, is...well, one of the biggest challenges for teachers is managing kids. It's not like showing you how to do a math problem; it's getting you to care about it, listen to it, stop disturbing other people. And so, a lot of time and energy is spent on classroom management for teachers. And so what we do is we use best practices there. For example, there's a lot of research out there in education that says that praising kids for good behavior is a lot more effective than punishing them.

+ +

And so games are really good at praising you. You level up, and you gain points. It tells you your score. What we're doing here is giving them that framework but applying that to classroom management. And so instead of saying, "Hey, Victoria, stop goofing off," or "You're not dressed well, go to the principal," or whatever it is that's happening in schools, what we're telling teachers to do instead is say, "Hey if Victoria does something good, recognize her. Give her a high five." And in Classcraft, a high five is gaining points.

+ +

And so we're shifting and applying this pedagogy, shifting towards a positive reinforcement mindset. And at the same time, because these high fives are digital, then you get all the data so you can know which behaviors did Victoria do at which time with which teacher? Hey, she didn't get a lot of points this week. What's going on with her? Maybe we should talk to her and see what's going on before her behavior escalates. And so there's a lot of value from a behavior intervention standpoint. But ultimately, it's super effective because the kids really care about it in a way that they don't normally care about classroom management.

+ +

VICTORIA: Well, that makes a lot of sense. And I'm hearing something I've studied before when looking at technology organizations which is that growth mindset I think you're describing, the positive reinforcement, praising the effort for something versus their intrinsic skills. And that's something I love about teaching. I think that really, really translates to running a technology organization.

+ +

SHAWN: Yeah, totally. Ultimately, what we're doing is giving schools and teachers a platform for really effective culture building. And what you're talking about is culture within a company, in essence, and it's really the same thing. It goes back to what I was saying earlier about managing a group of kids [laughs], and managing employees is super similar. It's all about what type of positive culture you are building.

+ +

VICTORIA: I think there's something really universal about that. It's actually even true with dog training. I have a dog, and it's the same kind of motivational theory that works for them too. [laughs]

+ +

SHAWN: Yep, yep.

+ +

VICTORIA: I love it. And you mentioned that you built this tool yourself, and then suddenly, it became very popular, and now it's really, I'm sure, scaling. So what challenges have you faced with going from this homegrown tool to something big and out there in the world?

+ +

SHAWN: Lots of challenges. [laughs] I would say working in education itself is a challenge. It's a pretty challenging vertical to work in. It's ripe for disruption at the same time, pretty conservative. There are a lot of forces working in education systemically not have it move forward. Working with schools and districts is challenging. They have a lot of requirements. And, of course, they're custodians of kids, so that's legitimate, but it does make it more challenging.

+ +

One of the things that we had to evolve was we were very much a teacher-only tool when we started. I had built it as a teacher. Our user in mind was a teacher. Even our business model initially was selling to teachers basically. There was a free version, and they could upgrade to a paid version. And as we got more and more scale, you know, we have ten million-plus kids in the platform now. As we got more and more scale, what ended up happening was we were working more and more with schools and districts.

+And so we went from a B2C go-to-market and product vision to a B2B/enterprise where we have to roster 10,000 or 100,000 kids in one shot, so all the user provisioning, connecting to information systems that these districts have, et cetera, all of this ginormous plumbing that needs to happen in order for it to continue to be easy to use for every single teacher. And alongside with that, the other challenge is we were super appealing to teachers that were interested in games. [laughs]

+ +

And so when you think of some teacher who's in their 60s and has never really played any games and just thinks that they're a silly waste of time, there's a different sales pitch that needs to happen there to get them on board and a different onboarding. One of the things we had to completely overhaul was the onboarding to make it really progressive. Classcraft, now when you start it, there's no avatar. It starts super lean on the feature side so that these teachers that are, you know, we're basically educating them as they're using the platform, educating them on all this game stuff.

+ +

There are a lot of learnings in terms of what's our actual target audience. And if our target audience starts to be enterprise customers, how do we evolve our platform to appeal to a much more diverse type of persona from a teacher standpoint?

+ +

VICTORIA: I was thinking, actually, a good friend of mine who is a teacher and has been running Dungeons & Dragons campaigns for us for several years.

+ +

[laughter]

+ +

SHAWN: There you go.

+ +

VICTORIA: And, like, you'll love it. [laughs]

+ +

SHAWN: Exactly.

+ +

[laughter]

+ +

VICTORIA: But I could see that being a challenge now that you're shifting your target business model, really, and how do you adapt to that?

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.

+ +

VICTORIA: What else are you looking ahead with Classcraft? What's on the horizon?

+ +

SHAWN: There's a lot. Like I said, we have 10 million kids in the platform plus. But we have teachers in every single country you could imagine, and there's a universality to what we're proposing. We're not saying here's the best tool for fifth-grade math in the U.S. We're saying, solve this universal human problem that's prevalent in education. And so we have teachers in, you name it, Taiwan, and Australia, and Singapore, and all over Europe using Classcraft. And so there's definitely opportunity for us to look at the international landscape and identify opportunities.

+ +

Another frontier beyond going out of North America is going beyond the brick-and-mortar experience of the classroom. A lot of what's happening in and around your software is actually not happening 18 inches from the screen. It's happening in this context where there are 30 other kids, and there are all these interactions going on. For example, if you made a reading app, you can imagine the kids sitting in a quiet space on their sofa at home reading this thing, but the reality that's happening is they're in a really loud classroom [laughs] with lots of other kids around them, et cetera. And so the design context for designing for edtech is really interesting.

+ +

We have some views that are meant to be only on a projector in front of the class. And when that happens, the font size needs to be 80 point because a kid in the back needs to be able to see it. So the screen real estate you're playing with is pretty unique scenarios. Like, what does this look like at 120 feet, let's say, because people are using it in the gym? So interesting design challenges, but they have been really ensconced in the idea that a lot of how people are using Classcraft is with real-life physical situations.

+ +

But Classcraft, in essence, we have an API. So you can also imagine behaviors that are not brick and mortar behaviors, like, if I'm being participative, that's something that a teacher would see and observe and give you points for. But there are 3,000 edtech platforms, and all of them have digital behaviors that teachers want to see. They want to see kids handing in homework in these platforms. They want to go see them complete assignments. They want to go see them participating in digital communities. These are all basically the new frontier for digital behaviors that are a part now post-pandemic of the ecosystem of education.

+ +

And so we're really interested in connecting to other platforms. I don't need kids to be in Classcraft; I just need them every day. I need them to be earning points. And I'm happy if they're doing that in other platforms and that those interactions are rewarding them experience points and points in Classcraft. And ideally, automatically, that way, the teachers don't have to do anything.

+ +

VICTORIA: And so you're integrating with all these different platforms, and you're working with all these different school districts. So you've had to make some difficult technology choices in your stack. Do you have any examples of those?

+ +

SHAWN: Yeah, absolutely. When I started the company, I'd come out of programming in...I started building cool websites in ActionScript, [laughs] so that dates me a little bit. But I'd just come out of a decade of ActionScript and PHP. And I'm like, PHP does not scale, and it doesn't afford the same type of real-time interactions that you'd expect from a game. When I decided what the tech stack would be, right at the outset, it was, okay, we're going to do this all JavaScript. It's going to be Node. And at that time...now that's a pretty, like, anybody would make that decision. But this was nine years ago, and it wasn't as mature as it is now.

+ +

And so that was a pretty ballsy move and one that we never looked back on. But we had a lot of things that we had to build ourselves because the libraries didn't exist yet. And we were really pushing the edge of what was possible in a browser, especially in a browser in school with a crappy internet connection. And often, they are on older browsers. Although it was the right decision to lean into the leading edge on the tech stack, it did afford us with a lot of specific challenges that we might not have had if we'd said, oh, let's just keep this super old school.

+ +

Some other things that we've been challenged with over the years is just scaling the number of concurrent users is always a thing. When we started, we had a single database, one server, and I was doing all the DevOps. And a lot of what we've done since that is just move everything to services. So we've got, you know, MongoDB database-as-a-service. [laughs] We're all on Google Cloud now.

+ +

From an IT standpoint, we think a lot about what stack we're going to be using. And to me, what really matters is build the product as fast as you can and as well as you can. So outsourcing all of the DevOps pieces to cloud providers is, in my opinion, [laughs] a really good use of funds versus maintaining it yourself and spending tons of money on sys engineers and architects.

+ +

The reality is that for most products today, what exists as a service in the cloud already bundled is, you know, and we've got auto-scaling. When there are too many concurrent users, it automatically spins up new Docker servers, et cetera. So we've really evolved from this monolithic single-server approach to this imminently highly scalable solution that is all virtualized, but in doing that, moved all of it to services.

+ +

And I think that's the right move because we're not, you know, if I was really, really core, if was, I don't know, [chuckles] an online video game, then the speed of connections and all these things become super important. But in our case, reliability, scalability is more important than the fine-tuning to a precise degree of specific tech infrastructure.

+ +

And I'm seeing more and more founders now, Victoria, as well go-to codeless solutions as well. I think we're kind of abstracting a lot of what was core to product development from a tech side. You know, first, it was the DevOps, then it was the cloud, and even now, code, I think, is moving in the direction where we're systematizing, bundling, and having other services generate code more and more. I think we're moving towards that just in software in general.

+ +

VICTORIA: Yeah, I think that is becoming prevalent. I do think low-code automation has also been coming around every 5 or 10 years or so. [laughs] I have the belief that technology never disappears; it just keeps building, and new tech gets created, and the user base shifts around a little bit. And, of course, for you as a technical founder, putting it all in Docker and setting up the auto scaling on Google is probably within your reach, whereas a lot of founders, that might be something more challenging, and you might need to have some support for.

+ +

But that's essentially what we work on for Mission Control as well is helping teams set up their platform so that it will scale automatically that if there's an issue, you know about it in advance. [laughs] You can take care of it before it falls over, and that way, your users just see a reliable, happy system.

+ +

SHAWN: I'm so grateful that I am a technical founder. [laughs] I know a lot of founders, and the ones that don't know how to code really are at the mercy of so many unknown variables. I'm not coding anymore, but I'm very aware of what's going on in the platform. And I think that helps me make better business decisions every day. So I have a lot of gratitude when I compare myself in that regard.

+ +

VICTORIA: And I think it's really about communication then too. Like, having a good understanding of your system is helpful but being able to understand it well enough to then communicate it to other people, and what the value is, and how you want to invest money in different parts of the system. I think those are two things that having maybe a little bit more of experience in technology and then also having a teacher experience, I think, sets you up to be successful.

+ +

But we also, of course, at thoughtbot, we offer a lot of that technical expertise to help founders navigate some of that. So there's a little pitch just for us. [laughs] But let's see, let me go through...I think I've gone through a good amount of questions. Here's one that I like to ask everybody. But if you could travel back in time to when you first started Classcraft, what would be the main piece of advice you would give yourself?

+ +

SHAWN: If I could go back, there are some big lessons that have been learned. I've been for almost a decade now as a founder and CEO. One of the things we didn't do early enough was user testing. If I split the life of Classcraft into three eras, there's the first third we didn't need to because we had all of my own experience. But once we started moving past what was the initial product that I had built in my own classroom, we continued to make assumptions.

+ +

And we, of course, always listen to our users, but now we're super systematic about it, and any new feature has research behind it and a really solid UX practice that we should have implemented much earlier. I think we're making much better roadmap decisions today than we were three years ago. A lot of companies hire UX people super late, and I would do that early or at least develop the chops to do it myself as early as possible. So I think that's one thing.

+ +

I think as well...and maybe this is tied to that. I think we should have and could have iterated faster as well. A lot of startups in the tech scene talk about iteration, but there's a difference between incrementally iterating and just adding on, adding on, adding on, and actually making the kind of iterative decisions that, for example, pulling part of the product and discontinuing it for example. And we've done some of those moves, but I think we could have done them faster. And we should have done them faster if we'd had that UX research data to help us make decisions faster.

+ +

So it's more than, like, common truism is like, oh, listen to your users and listen to their feedback. Like, yes, that's true, and we were doing that. But I'd say go further and create robust structures to get that data faster, not just wait for it to come in but actually go out and get it and digest it in a way that's actually usable. Because you have a whole bunch of testimonials and feedback, but if it's not organized, it's not somebody's job to make sense of it. It's just kind of sitting there. So there's a lot of value from that perspective that you can quickly generate for your users and, therefore, for your business.

+ +

VICTORIA: Right. Save you some time and some money, probably in validating your ideas, right?

+ +

SHAWN: Yeah. And the problem with education is that it's a yearly cycle, right?

+ +

VICTORIA: Mmm-hmm.

+ +

SHAWN: We're not looking at monthly scales; we're looking at the whole school year. So back to school happens once a year, and that's when you get a ton of data because that's when there's the most activity. Like, right now, August, September, October, these are the moments where we're getting the most data. And then when you make changes, you got to wait all the way back to the next back to school.

+ +

So, in particular, in education, I think the cycles are long versus, let's say, more B2C-type consumer verticals where the test length is like a week. [laughs] So if it's coming once a year, you better make sure you're organized, I guess, is what I'm saying. [laughs]

+ +

VICTORIA: Because we only have one shot. [laughs]

+ +

SHAWN: Yeah, exactly.

+ +

VICTORIA: That makes sense. Well, thank you so much for sharing all those insights. And I want to give you a chance to promote anything else you'd like to share with our listeners.

+ +

SHAWN: Thank you so much for the conversation, Victoria. I appreciate it. I think if anybody wants to find out about Classcraft, classcraft.com, tons of content and resources that we're generating about these topics of building meaningful relationships in school but in general with human beings.

+ +

Classcraft is a B Corp, and so for people who don't know what that is, it's a certification around impact. And so we have built-in commitment to generate good in the world. And it's a pretty hard certification to get, so we're pretty proud about it. But I think that this commitment that we have of generating meaningful relationships both with kids but also with our employees, with our community, with our different stakeholders, has been really core to a lot of the decisions we make and how we make them, and how we approach different problems.

+ +

And so I think that as a tech founder, sometimes we can lose sight of what are we actually generating in the world. And so I would encourage people to think about, you know, if you're thinking about starting a company or thinking about your own company and the impact its having to look up that certification. But also, just look up triple bottom line, these types of concepts that are becoming more and more prevalent that really give meaning to the endeavor.

+ +

Starting a company and running it is a lot of work. You need to believe in what you're doing. [laughs] And I think having a mission that generates impact in that way is a good way to motivate yourself and your team to go the extra mile and deliver.

+ +

VICTORIA: I love that. And did we really cover the full impact this app has had on kids that are using it in schools?

+ +

SHAWN: There's a ton of research about Classcraft; actually, that's been done by pedagogy professors in colleges. Literally, thousands of papers have been written on Classcraft because there just aren't a lot of...everybody's interested in student motivation. There aren't a lot of scalable systems for doing that other than Classcraft. And so a lot of research that's been done about that topic incidentally happens to be using Classcraft. And a recent meta-study about Classcraft was conducted, and they saw a significant statistical impact on student motivation and learner outcomes.

+ +

And so it's hard in education to really understand impact easily because it's social sciences. So you need a lot of big data samples, and you need the control groups. It's complicated. So we're pretty proud about that because a lot of companies that work in education don't have that kind of hard data. It's like, okay, it seems to be having an impact. We've got pretty hard proof; literally hundreds of millions of positive behaviors that kids have done that are being reinforced every single year. And when you think about that, most kids don't get any positive feedback.

+ +

The kids that get the most attention are the ones that are acting out and being the worst. So 90% of teacher energy is being directed at 10% of the kids, and so most kids go through school without ever feeling a sense of belonging, or accomplishment, or praise. And we've had kids write us saying, "I was suicidal. Classcraft changed my life," like these types of user testimonies where the impact, the human impact of the approach, is really, really real. And for teachers as well, like, "I was so demotivated with teaching. I found the spark again thanks to Classcraft because school is fun again." [laughs] So there's a lot to be proud of there, for sure.

+ +

VICTORIA: That's wonderful and really powerful that you've had that impact and have been able to see it both from a scientific perspective and from those user testimonies. So I think that's wonderful. And I think it's an inspiring story. And that's probably why you're also so involved; it seems, in leadership groups in edtech and in other communities in Quebec. Is that right?

+ +

SHAWN: Yeah, totally. I mean the reality...so I'm the president of the Edtech Association here in Quebec, which I helped co-found. We've got 100-plus organizations working in edtech that are part of the association. I'm also Co-chair for The Global Collective for Social Emotional Learning, Digital Learning for UNESCO. And I have been involved in numerous different systemic endeavors in education throughout the years.

+ +

The truth is changing education is hard, and the way we're going to succeed is...it's fundamentally something I believe that we should really be focusing on as a society is improving education, education outcomes. All the positive changes we need to see to tackle the incredible challenges that are upcoming for us as a species are going to happen through education. But for that to happen, we need to make education evolve, and for education to evolve, we need to all work together.

+ +

So the association is interesting because it's like a coopetition [laughs] in a sense. All these entrepreneurs we're all competing for the same budget dollars, but we're looking at education problems in different ways. And if we're more successful as an industry, individually, everybody's going to be more successful, and more kids are going to be impacted. So I just believe that and this is true specifically for education, but I do believe this for any vertical. If businesses are collaborating to elevate, if the water rises, everybody's boat goes up. I really believe that that's true in business in general and in education in particular.

+ +

VICTORIA: It reminds me when I was at Pluribus Digital in my last position. We were a part of the Digital Services Coalition, which is another coopetition group of federal contractors who are going after the same money. But we are all trying to see the government be better, part of that collaboration which sounds like what Classcraft is all about too. We're all in it together. [laughs]

+ +

SHAWN: Yeah. And if that's not the case, especially for incumbents, then what happens is status quo. And for startups, for tech companies, usually the status quo [laughs] is bad. That's where you're trying to generate opportunity from. But sometimes the systems that are there, government systems in particular...we've seen a lot in health as well over the last few years in clean tech. All of these impact tech sectors part of what they're fighting against are market forces of status quo. And so it's only by all working together that we can really move that.

+ +

VICTORIA: Yeah, absolutely. I'm sure we could keep talking about that for a long time. [laughs] But unless you have anything else you'd like to share, I'll go ahead and wrap up.

+ +

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Shawn Young.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+qvPonLvb + + ]]> + + Victoria Guido + Shawn Young + + + 444: Paddle with Daniëlle Keeven + https://podcast.thoughtbot.com/444 + 6fb563c3-6945-4a0b-ada2-6e5816a0b1b2 + Thu, 13 Oct 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Daniëlle Keeven is VP of Finance at Paddle, the only complete payments infrastructure provider for SaaS companies. + +Victoria talks to Daniëlle about helping companies with taxes while assuming the liability and risks associated with global tax compliance, financial literacy, and taking proactive measures and steps to manage cost effectively before it is required. + 28:26 + no + + + Hello UK Giant Robots listeners! Our next event allows you to hear from and connect with both Founders and Investors on all things Fundraising. The event will be 1 part panel discussion and 1 part breakout sessions. We hope you can make it! Register today at: tbot.io/fundraising-uk (https://thoughtbot.com/events/fundraising-uk-event?utm_source=socials&utm_medium=socials&utm_campaign=UK%20fundraising%20event) +Daniëlle Keeven is VP of Finance at Paddle, the only complete payments infrastructure provider for SaaS companies. +Victoria talks to Daniëlle about helping companies with taxes while assuming the liability and risks associated with global tax compliance, financial literacy, and taking proactive measures and steps to manage cost effectively before it is required. +Paddle (https://www.paddle.com/) +Follow Paddle on Twitter (https://twitter.com/PaddleHQ), Instagram (https://www.instagram.com/paddleteam/), Facebook (https://www.facebook.com/paddlehq/), YouTube (https://www.youtube.com/channel/UCK1qyXbgE-kcGA4LMGdL7PA), or LinkedIn (https://www.linkedin.com/company/paddle/). +Follow Daniëlle on LinkedIn (https://www.linkedin.com/in/danielle-keeven/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +Hello, United Kingdom Giant Robots listeners! Our next event allows you to hear from and connect with both founders and investors on all things fundraising. The event will be one part panel discussion and one-part breakout sessions. We hope you can make it. Register today at tbot.io/fundraising-uk. +VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Daniëlle Keeven, VP of Finance at Paddle, the only complete payments infrastructure provider for SaaS companies. Daniëlle, thank you for joining us. +DANIËLLE: Hi, Victoria. Thank you for having me. Super excited to be here. +VICTORIA: Wonderful. Yes, I'm excited to have you here and to hear a little bit about your background. I was curious how it was different going from a finance role in a large corporation like Marriott to the startup world and to Paddle. +DANIËLLE: Well, Victoria, I was actually quite fortunate because even in the Marriotts and the Hyatts that I've been in in hospitality, I've been exposed to a lot of in the trench type of accounting and finance. Being in the Caribbean and just a Latam market, you learn to look at situations differently and make sure you work towards compliance. So I think that's really groomed me for stepping into the tech space as well, where I think following the money is the first directive of any finance professional walking into a scale-up or startup. So I think it's groomed me for the move. +Booking was a little bit easier because it was also a little bit of leisure and travel. When I stepped into a telecom for MessageBird and then Paddle as a payments end-to-end provider of infrastructure, there was a little bit of a challenge there. But I love being part of a company now that's completely a finance product which has really given finance roles a partnership with product and engineering to partner in the way forward and design of the product. +VICTORIA: Yes, that's exciting for us as well. And tell us a little bit about Paddle, actually. +DANIËLLE: So Paddle is an end-to-end platform. We strive not to just help software companies; we strive to do the work for them to be able to roll out globally. So basically, Paddle is the only end-to-end infrastructure that will enable you to invoice your customers and get payments support, offering different payment methods, as well as make sure you're globally compliant and file your taxes so that you don't have to. +I think what sets Paddle apart from a lot of other companies that are helping companies with tax is that we actually do it for you. In addition to that, we assume the full liability and risks associated to global tax compliance. +VICTORIA: Right. Yes. And I saw a product that you all have or information that you shared called the Sales Tax Agony Index. Can you tell me a little bit about that? +DANIËLLE: Well, I think, in general, tax is painful. [laughs] I think personal tax is painful. Anything that has to do with business tax is amplified significantly. And I think for software companies, often, you build a great product, and you want to bring it up to market. But then you're limited and slowed down from really expanding globally. I mean, that is where we come in to really take up the tax burden for software creators to be able to look at it as a stepping stone instead of a roadblock if that makes sense. +VICTORIA: I think that makes a lot of sense. And it's interesting where we are right now with the current climate and economics that companies may be focusing on their finances to reduce cost but also to identify new areas to invest in, right? +DANIËLLE: Yeah, right. And I think that's super interesting to me, which I keep saying I'm not sure why not all of the software world is on Paddle. Because I think if you look out there in the market, there's such a piecemeal solution to everything. So you have to, for example, if you're going to not build your own billing, you have to outsource buying software for your billing. You have to go find a payment provider that's compatible and then the resources to get them into your platform to make sure checkout is seamless. +Then you have to get an accountant to reconcile your payment. You have to get customer support to support your customer payments. You have to get more additional headcount to make sure your chargebacks and your fraud rates stay down. And all of this, Paddle just does it for you, which I think especially in this climate where cost is becoming a subject, I think Paddle is a great business partner to enable software companies to grow at a reasonable cost and pricing, and really explore all of the global market out there versus having to do it yourself. +VICTORIA: Right. And Paddle could maybe help you identify where your spend also has a high return on investment. Is that right? +DANIËLLE: We do put you in direct contact with your customer, so your customers are not masked or anything like that. So you do have access to all of your customer data. And in addition to that, we've recently made an additional acquisition to grow the Paddle family by adding ProfitWell, which is really an expert in anything that has to do with retention and pricing. And we are working to integrate this product and make it available to our Paddle customers as well. So that is not something that is there today but soon will be. +VICTORIA: Oh, interesting. And I read a recent interview that you did, and I liked how you connected retaining your customer base to your billing and invoicing process because that might be an afterthought for a lot of startups and founders. But it is really key in keeping your customers happy is having that easy billing and invoice process. Is that your perspective? +DANIËLLE: Yeah. I definitely think that with any SaaS company, there's definitely something known as well as an abandoned cart like somebody that will, you know, maybe we do it ourselves as well when we go out shopping online. We drop stuff in our cart, and we never make it to checkout. And I think to make sure you optimize your checkout, and your revenue is to make sure that the process is as seamless as possible, that your customers can just flow through this process and not have any challenges during that journey to make sure that your conversion rates stay high. +VICTORIA: Right. That makes a lot of sense. Do you have other insights about customer retention that may relate to the Paddle platform? +DANIËLLE: I think what's unique for me as a finance professional looking at the Paddle product...given I am by little biased because I do work here, and I'm a big fan of our product. But I think, and I've talked about this often, there are so many software solutions or tools that finance folks are trying to be sold. We get them sold to us, like, oh, this will automate 100%, and this will reduce this, or this will reduce that. +I think what Paddle does well and how we are uniquely positioned is that what should be automated is automated and what needs a human touch has a human touch. And what I mean with that as well is in the sense of your customers making a payment and having a challenge we actually offer customer support with real people. And we do support your customers to make sure that they have a pleasant journey in the checkout process or resolve any payment issues that they have. So I think we balance the two out. +And it's similar to, for example, taxes as well. We automate what we can, but we have a team of tax analysts really looking at the data and making sure everything is running correctly and is exactly compliant as it should be. So I think we bring together the best of both worlds in saying we automate a portion of the journey and where we can use and should use the human touch and intellect we do so. So we're not promising 100% percent automation. We just promise that we will do it for you by combining the best of both worlds. +VICTORIA: That makes sense, right? Because, at some point, the automation can become more effective than hiring. But how can you scale your business without having to double your finance reporting and your tax teams, right? +DANIËLLE: And I fully agree. And I think you bring up a very interesting point. I think from my past; I had been at Booking where you were in a situation where you have an endless means of cash flow that you can really build your dream automation tools. I think a lot of the big automation that Booking has achieved in finance is really admirable, and a majority of it has been done in-house. So I think they've done a really great job with that. +But then, when you step out of an organization like that into a smaller startup scale-up, you do not have infinite funds. You are talking mostly about cash burn and then your cash runway. And you do have to optimize between a decision of should I invest in tooling to automate? Or does it make sense for me to hire a person because hiring a person is more cost-effective than automating? +I think in a cash-tight environment, you do have to evaluate what makes more sense; sometimes, it is hiring a person. Sometimes hiring one person will get you scaled for two years. And other times, if you looked at you will have to hire one or five people per year to do a certain task, then it makes sense definitely to invest in automation because the cost will be upfront, but the benefits will be scalable, and you'll have definitely benefits from that point. +VICTORIA: And there's a mix of you need people to do the work, but you also need to give them the tools to be able to do their job, right? +DANIËLLE: Yes, I think most of us in finance still find that Excel is our best friend. [laughs] +VICTORIA: Well, I won't complain about Excel myself. I have a background in economics, an undergraduate, so I'm an Excel pro. +DANIËLLE: Yeah, I think definitely Excel has brought us all a very long way. [laughs] +VICTORIA: So what's different about your customers that you're targeting with Paddle? What's unique about them? +DANIËLLE: I think what is unique about them is that we want to really bring the creator of softwares their dreams to life, which means it's almost like we want to dream with them if that makes sense. We want to make sure that whatever they build becomes available to the world, whether they are a small startup or a small company or if they are a giant in the industry and very good at their skills. +So we want to target the entire market for software. And I think what makes them unique is that our customers are usually a fan of our product, but we are a fan of theirs. So I think, typically, that works both ways really well. +VICTORIA: Yeah, that makes a lot of sense. And do you find that your customers are facing a different set of challenges today than they might have a year ago? +DANIËLLE: I think the SaaS industry has changed. I think it's no secret that definitely the economic landscape has shifted. I think we were very fortunate to close our Series D in very favorable circumstances before the climate changed. I do think it will change back, and I don't think this is all doom and gloom. But I also do think that we are all facing the situation where we should be taking proactive measures and steps to manage our cost effectively before it is actually required. For some of the SaaS industries, it may already be required, and for others, I think even those doing well should be mindful to take steps where possible. +Cutting costs does not necessarily mean cutting quality or immediately reducing staff. I think it just is more taking a step back and critically looking at your spend to see, do I have opportunity to renegotiate existing contracts? Are there, especially in my cost of goods sold, can I get this reduced somehow without reducing the quality of my product and what we're delivering as a business? And I think these are very good and big opportunities that we can definitely seize in addition to our operational spend. Just taking a critical look at this can really go a long way. +VICTORIA: That makes sense. It sounds like, as a VP of finance, those are things that you might be able to bring to the table. Or tell me more about how the role of a finance person plays in a startup in making some of those decisions. +DANIËLLE: I think the role of a finance person is super critical in the sense of you're looking back to see what the spend was and where we've been and to look forward to what the trends will be. You're also trying to inspire vision and strategy and work together with the sales team to both have realistic forecasts on what we will do, can do, and what we'll actually deliver. +And I think as a finance leader, more than ever, it is so needed for us to partner with the business instead of being chucked away in a corner somewhere processing financial reports or looking at them. So I think the finance literacy is definitely something that we can add to our organizations. I'll give you an example, as we rolled out our budget, it wasn't just to deliver it to the board or to our executive committee, but it was also to talk about it with our senior leadership. +I think the senior leadership is also so critical to any organization to say, "Hey, we are going to commit together with our own leaders to make sure that we're executing the plan and that we will also get all of our teams to partner and create that buy-in as a company." +So I think as a finance leader, it's not just my job to go out there and say, "Hey, we have to cut costs," but also to explain what is happening to the economic climate, why we have to cut costs, and what are the benefits of doing it before it is needed. And definitely paving the road to say, "Hey, this is beneficial for all of us because these are our financial goals that we can achieve, but we can only achieve them together." +So I think creating that buy-in and building that team across the organization that is committed to the correct finance management is super critical in this day and age. It used to be that it was just finance's role to watch the finances; I think now it's a collaborative effort of the entire company. +VICTORIA: I really like that I have a background in DevOps, and that's breaking down silos between different parts of the organization. And so I love to hear that finance is getting really involved and be a part of the overall decisions that everyone's making in the company, right? +DANIËLLE: Yeah, definitely. +VICTORIA: How does Paddle build stakeholder buy-in within the company? What does that process look like for you all? +DANIËLLE: I think very early on, we identified that, obviously, our executive team is key. I think this is the tip of the arrow really leading the organization in giving vision and direction. I find that we've been very fortunate, in my humble opinion, because we have a great CEO and a great COO. And I really enjoy working with the entire executive team. They're just a wonderful group of people. Besides being amazing professionals, they're just generally nice, [chuckles] which is always great. +But we've identified early on that actually your senior leadership right underneath that is so critical to your company's culture, how you hire, how you buy, how you move, how you invest, but also how would your future be like. Because while the executive team definitely is key in giving the direction, the vision, and mission, I think the team right underneath that, the senior leadership team, is really the one that is going to go out there and materialize that dream and vision, and really live that dream, and really get the right people and to get the job done. +So I think what we've identified early on is to make everybody an active stakeholder, do the planning together. Like, before the executive team rolls out a mission and vision, it's not going to be a total surprise to the senior leadership. We've all taken part of it, and we've all supported it, and we've discussed it, and we've fine-tuned it. So I think definitely taking people along in the journey goes a long way. +The other thing I think that is very critical is just being transparent and being honest. At the end of the day, we're people. We want to know what's happening, why it's happening, and what we're working towards. And I think that is something that Paddle has done very well as well internally as a team. We have great values and great focus on what we want to deliver, where we want to go, and we definitely are focused on doing so together. +VICTORIA: That sounds great. You all have a shared vision of where you're going and where you are currently. And that probably helps get everyone on board with what we're working on in the future. It gets everyone motivated a little bit more, right? +DANIËLLE: Correct. Exactly. +VICTORIA: So, is there anything particularly exciting coming up with Paddle that you are looking forward to? +DANIËLLE: I think I'm super excited to see what ProfitWell, how it will integrate, and the product that it will offer, and the opportunities that it will offer to our Paddle customers. I'm super excited to see that materialize and seeing all of this come together. We've been waiting, and we've been working towards this deal for a very long time, so seeing it materialize is quite exciting. And I'm definitely looking forward to that. +VICTORIA: And do you think that that cultural strength you mentioned with Paddle and having that transparency and quality of support from the leadership does that help translate when you're doing big deals like that and closing deals with other companies? +DANIËLLE: Yeah, it definitely does. I think, in general, the finance team has had quite an exciting first half of the year. I want to say, you know, being in Series D, having due diligence done, ProfitWell, at the same time preparing for an audit, having your financial team build out your reporting. I think we've had so many things run at the same time, and the pressures are quite high. So I think just having that positive culture together as a team gives you strength as well together to be your best self under pressure instead of really crumbling or not getting along and struggling with it. +VICTORIA: Yeah, that makes total sense. If you feel like you're supported by other humans in your company, [laughs] then when you're stressed, it makes it easier to get along. That makes a lot of sense. Do you have any other advice for finance leaders or startups who are navigating the economic downturn at this time? +DANIËLLE: I would say keep an eye open. Do not stop investing. Do be critical about your ROI. Make sure that where you're spending your money is where it makes the most sense for the business, and just keep an eye out for opportunity. Because just because the climate has turned does not mean that it will not turn back, and it does mean that there are loads of opportunities out there that we can still seize as a business. +VICTORIA: Right. It means that different markets are more active, right? [laughs] +DANIËLLE: Usually. Correct. +VICTORIA: Do you have any questions for me or for thoughtbot? +DANIËLLE: I'm just curious, for you as well, what's your favorite subject that you discuss on thoughtbot? +VICTORIA: Ooh, a favorite subject. That's tough because I love hearing from our designers and our developers. We have many developers who are some core contributors to Rails, and so they are very knowledgeable about things like we have random meetups that happen at thoughtbot. So you can sign up and just randomly pair up with somebody else in the company. +And the first random meetup I had, I met up with someone who is like the expert on security [laughs] and dotfiles and helped me finish setting up my developer environment. And so I love that at thoughtbot, you can start a random conversation with someone, and they'll end up having this wealth of knowledge around a particular subject that you might have been struggling with and can just immediately solve your problem. +I also like the fun parts. There's actually a blog that just captures all of our jokes from Slack [laughter] just… So it's a part of like making it fun and being human at work and kind of showing up with your whole self. I think that adds a cultural strength for those moments like you describe when things are difficult, or you have a hard project. You feel bonded to your teammates and feel like you're all working together, and that positivity stays throughout. +DANIËLLE: Yes, definitely. +VICTORIA: So, are you currently in Amsterdam? Is that right? +DANIËLLE: I am based in the Netherlands. I'm actually based in Alkmaar, which is 30 minutes outside of Amsterdam, but I typically say Amsterdam because that's the city that most people know where it's at. [laughs] +VICTORIA: Same for me. I go with San Diego, but I'm actually in Encinitas. It's a little bit further north. So is there a difference, or what is the startup environment or community like in Europe then? +DANIËLLE: I think I'm quite impressed because before moving to the Netherlands, I wasn't aware there was so much happening, but there are actually some channels called Silicon Canals, so the canals for the boats, so it's a bit of a play on words. And there's such a vibrant startup and scale-up community in the Netherlands, which was quite surprising for me to run into. So I do think by nature...I was born in the Netherlands, and I moved to Aruba when I was five. So I wasn't raised here. +But I think if I look at the Dutch culture, it is quite innovative. And they do tend to find different ways of doing things when it comes to water or building dams. And I think that curiosity and innovation has moved over to the tech space. So I think that Amsterdam is definitely a city to watch in terms of scale-ups that pop up and the progress that they make. +VICTORIA: I've heard a lot about new technologies and new solutions coming out of the Netherlands with agriculture specifically, but I am not surprised that there's a burgeoning startup community there. [laughs] That's wonderful. +DANIËLLE: Yeah, it's quite exciting. +VICTORIA: That's very cool. All right, is there anything that you expected me to ask that I did not ask? +DANIËLLE: No, I can't think of anything off the top of my head. I think we covered quite a bit. +VICTORIA: Yes. I'm watching the time and making sure that I'm giving you enough time. +DANIËLLE: [laughs] +VICTORIA: I liked this quote from your blog, actually, so I'll repeat it here, "Bad companies are destroyed by crises, good companies survive them, and great companies are improved by them." +DANIËLLE: Yes, that is definitely one of my favorites. +VICTORIA: Do you have an example of a company where they went through a crisis, and they came out great afterwards? +DANIËLLE: I have a friend of mine, actually, that started a company called Limelights. And I think when he started this, he was so focused on marketing and development and so on. When the COVID crisis hit...and he's actually the one that shared that quote with me, we're close friends. He was sharing with me that quote and how he has completely revamped his company from a marketing company, which is basically the first thing that most companies...the expense they started cutting, to an online learning platform, and events, and team development program. +So I think he's done this so successfully that his business started thriving during the COVID period. And still now, after when things are relatively normalized in the tech space and just the overall spend, he is doing better than he did before this happened. His story of his company was so inspirational to me. And we were talking about that quote, and I'm just like, that's it. That's exactly that innovative culture that you want to see in times of crisis. +You don't want people to back down and say, "Oh, times are hard. Let's just ride this out." You want people to start looking around, like, how can we do this differently? And how can we navigate these new waters that we're in? And proactively be engaged with your environment to really find alternatives to what is happening. +VICTORIA: I would guess that having a clear picture on your finances and your customer information would help you be able to make those pivots. Is that right? And how Paddle can help you get out of those [inaudible 23:21] +DANIËLLE: Yes, that is definitely correct. [laughs] Like I said, we're an end-to-end platform. So you can literally have all of your data at the tip of your fingers to make sure that you make the right financial decisions in addition to us taking off some of the financial tasks off of your plate. Like I said, we want to do it for our customers, make sure that everything is running smoothly. So I think this is a massive opportunity for companies to have additional support in their processes because we take them over to a degree as well as indeed have clarity and transparency into their financial reporting and how their revenue streams are doing. +VICTORIA: Right. Because I imagine that task that work to put all that together would take up a lot of founder's time. +DANIËLLE: Yes. +VICTORIA: So freeing up that time and giving you a chance to understand where you're at now, and where you can go, and be able to pivot in those times of crisis. +DANIËLLE: Exactly. +VICTORIA: That makes a lot of sense. Has Paddle found that offering free information or these tools like the Sales Tax Agony Index does that help you bring customers into your platform? +DANIËLLE: Yes, definitely. I think there's a bit of humor here as well. Obviously, this was not put together by a finance person. [laughs] But I do love that our sales and marketing team is super creative in bringing the finance story and the tax story to life. I think as soon as people hear tax, if you can tune out, you do. So I think they've done a great job at pointing out the Sales Tax Agony Index, and they are not exaggerating. [laughs] +In many of the jurisdictions, it is quite challenging. And I think one thing that makes it challenging as well...so while software is not new to most of us as users, software is still quite new to most governments, and most countries are not certain when or how to tax this. So I think everybody is trying to figure this out globally, which is where we can step into the space, as well as we do monitor the global landscape for taxes. +The changes happen fast. They happen continuously. And implementation of taxes is not always logical because taxes are not always logical. So I think looking at the tax agony that our sales and marketing team has put together is definitely not an over-exaggeration. I think the risks are real for misunderstanding or misreading the tax laws that are in place, and so that's where we come in to really bring our experts and really dissect some of the meanings of these. We have partners globally to ensure compliance. +I think that the tax that is charged on software can be so variable that, as a business by yourself, it's going to be super tricky to monitor. Like in some countries, the software is taxed locally only if you sell to a local customer. It is not taxed locally if it's sold internationally. So there are so many little hooks and needles. In some countries, you don't have to pay tax unless you exceed X amount of sales on your software. So all of these rules and regulations can be quite obstacles and blockers to rolling out your business globally. +VICTORIA: Right. I hadn't even thought about a lot of that complexity. One of the things I'm excited about most with thoughtbot is that it's an international company. And so I'm out of my DC bubble, and we have customers in England and team members all over the world. So I think it's exciting that there's a product out there that can help you navigate things like taxes across all different countries, which I wouldn't have even thought would be that big of a problem, but apparently, it is. [laughs] +DANIËLLE: And I think especially when you talk about the tax agony panel, you can also see what the challenges are, and worst penalties, and fines, and prison. +VICTORIA: [laughs] Yeah, right? It's like, it's very difficult, and the agony is high, and the penalty is high. [laughter] So that's...you don't want to go to prison for accidentally misunderstanding the tax code. That's a real serious risk that you'd face. +DANIËLLE: Yes, it is. [laughs] +VICTORIA: Awesome. Do you want to do any final takeaways for our listeners today? +DANIËLLE: I would say chin up. The economic downturn is not going to last forever. While it's good to look for opportunity to save costs, it's also a great opportunity and moment to look for the right investments to make to grow your company. +VICTORIA: Wonderful. Well, thank you so much, Daniëlle. I really enjoyed our conversation. +DANIËLLE: Thank you, Victoria. It was great meeting you. +VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Daniëlle Keeven. + + + Hello UK Giant Robots listeners! Our next event allows you to hear from and connect with both Founders and Investors on all things Fundraising. The event will be 1 part panel discussion and 1 part breakout sessions. We hope you can make it! Register today at: tbot.io/fundraising-uk

+ +

Daniëlle Keeven is VP of Finance at Paddle, the only complete payments infrastructure provider for SaaS companies.

+ +

Victoria talks to Daniëlle about helping companies with taxes while assuming the liability and risks associated with global tax compliance, financial literacy, and taking proactive measures and steps to manage cost effectively before it is required.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

Hello, United Kingdom Giant Robots listeners! Our next event allows you to hear from and connect with both founders and investors on all things fundraising. The event will be one part panel discussion and one-part breakout sessions. We hope you can make it. Register today at tbot.io/fundraising-uk.

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Daniëlle Keeven, VP of Finance at Paddle, the only complete payments infrastructure provider for SaaS companies. Daniëlle, thank you for joining us.

+ +

DANIËLLE: Hi, Victoria. Thank you for having me. Super excited to be here.

+ +

VICTORIA: Wonderful. Yes, I'm excited to have you here and to hear a little bit about your background. I was curious how it was different going from a finance role in a large corporation like Marriott to the startup world and to Paddle.

+ +

DANIËLLE: Well, Victoria, I was actually quite fortunate because even in the Marriotts and the Hyatts that I've been in in hospitality, I've been exposed to a lot of in the trench type of accounting and finance. Being in the Caribbean and just a Latam market, you learn to look at situations differently and make sure you work towards compliance. So I think that's really groomed me for stepping into the tech space as well, where I think following the money is the first directive of any finance professional walking into a scale-up or startup. So I think it's groomed me for the move.

+ +

Booking was a little bit easier because it was also a little bit of leisure and travel. When I stepped into a telecom for MessageBird and then Paddle as a payments end-to-end provider of infrastructure, there was a little bit of a challenge there. But I love being part of a company now that's completely a finance product which has really given finance roles a partnership with product and engineering to partner in the way forward and design of the product.

+ +

VICTORIA: Yes, that's exciting for us as well. And tell us a little bit about Paddle, actually.

+ +

DANIËLLE: So Paddle is an end-to-end platform. We strive not to just help software companies; we strive to do the work for them to be able to roll out globally. So basically, Paddle is the only end-to-end infrastructure that will enable you to invoice your customers and get payments support, offering different payment methods, as well as make sure you're globally compliant and file your taxes so that you don't have to.

+ +

I think what sets Paddle apart from a lot of other companies that are helping companies with tax is that we actually do it for you. In addition to that, we assume the full liability and risks associated to global tax compliance.

+ +

VICTORIA: Right. Yes. And I saw a product that you all have or information that you shared called the Sales Tax Agony Index. Can you tell me a little bit about that?

+ +

DANIËLLE: Well, I think, in general, tax is painful. [laughs] I think personal tax is painful. Anything that has to do with business tax is amplified significantly. And I think for software companies, often, you build a great product, and you want to bring it up to market. But then you're limited and slowed down from really expanding globally. I mean, that is where we come in to really take up the tax burden for software creators to be able to look at it as a stepping stone instead of a roadblock if that makes sense.

+ +

VICTORIA: I think that makes a lot of sense. And it's interesting where we are right now with the current climate and economics that companies may be focusing on their finances to reduce cost but also to identify new areas to invest in, right?

+ +

DANIËLLE: Yeah, right. And I think that's super interesting to me, which I keep saying I'm not sure why not all of the software world is on Paddle. Because I think if you look out there in the market, there's such a piecemeal solution to everything. So you have to, for example, if you're going to not build your own billing, you have to outsource buying software for your billing. You have to go find a payment provider that's compatible and then the resources to get them into your platform to make sure checkout is seamless.

+ +

Then you have to get an accountant to reconcile your payment. You have to get customer support to support your customer payments. You have to get more additional headcount to make sure your chargebacks and your fraud rates stay down. And all of this, Paddle just does it for you, which I think especially in this climate where cost is becoming a subject, I think Paddle is a great business partner to enable software companies to grow at a reasonable cost and pricing, and really explore all of the global market out there versus having to do it yourself.

+ +

VICTORIA: Right. And Paddle could maybe help you identify where your spend also has a high return on investment. Is that right?

+ +

DANIËLLE: We do put you in direct contact with your customer, so your customers are not masked or anything like that. So you do have access to all of your customer data. And in addition to that, we've recently made an additional acquisition to grow the Paddle family by adding ProfitWell, which is really an expert in anything that has to do with retention and pricing. And we are working to integrate this product and make it available to our Paddle customers as well. So that is not something that is there today but soon will be.

+ +

VICTORIA: Oh, interesting. And I read a recent interview that you did, and I liked how you connected retaining your customer base to your billing and invoicing process because that might be an afterthought for a lot of startups and founders. But it is really key in keeping your customers happy is having that easy billing and invoice process. Is that your perspective?

+ +

DANIËLLE: Yeah. I definitely think that with any SaaS company, there's definitely something known as well as an abandoned cart like somebody that will, you know, maybe we do it ourselves as well when we go out shopping online. We drop stuff in our cart, and we never make it to checkout. And I think to make sure you optimize your checkout, and your revenue is to make sure that the process is as seamless as possible, that your customers can just flow through this process and not have any challenges during that journey to make sure that your conversion rates stay high.

+ +

VICTORIA: Right. That makes a lot of sense. Do you have other insights about customer retention that may relate to the Paddle platform?

+ +

DANIËLLE: I think what's unique for me as a finance professional looking at the Paddle product...given I am by little biased because I do work here, and I'm a big fan of our product. But I think, and I've talked about this often, there are so many software solutions or tools that finance folks are trying to be sold. We get them sold to us, like, oh, this will automate 100%, and this will reduce this, or this will reduce that.

+ +

I think what Paddle does well and how we are uniquely positioned is that what should be automated is automated and what needs a human touch has a human touch. And what I mean with that as well is in the sense of your customers making a payment and having a challenge we actually offer customer support with real people. And we do support your customers to make sure that they have a pleasant journey in the checkout process or resolve any payment issues that they have. So I think we balance the two out.

+ +

And it's similar to, for example, taxes as well. We automate what we can, but we have a team of tax analysts really looking at the data and making sure everything is running correctly and is exactly compliant as it should be. So I think we bring together the best of both worlds in saying we automate a portion of the journey and where we can use and should use the human touch and intellect we do so. So we're not promising 100% percent automation. We just promise that we will do it for you by combining the best of both worlds.

+ +

VICTORIA: That makes sense, right? Because, at some point, the automation can become more effective than hiring. But how can you scale your business without having to double your finance reporting and your tax teams, right?

+ +

DANIËLLE: And I fully agree. And I think you bring up a very interesting point. I think from my past; I had been at Booking where you were in a situation where you have an endless means of cash flow that you can really build your dream automation tools. I think a lot of the big automation that Booking has achieved in finance is really admirable, and a majority of it has been done in-house. So I think they've done a really great job with that.

+ +

But then, when you step out of an organization like that into a smaller startup scale-up, you do not have infinite funds. You are talking mostly about cash burn and then your cash runway. And you do have to optimize between a decision of should I invest in tooling to automate? Or does it make sense for me to hire a person because hiring a person is more cost-effective than automating?

+ +

I think in a cash-tight environment, you do have to evaluate what makes more sense; sometimes, it is hiring a person. Sometimes hiring one person will get you scaled for two years. And other times, if you looked at you will have to hire one or five people per year to do a certain task, then it makes sense definitely to invest in automation because the cost will be upfront, but the benefits will be scalable, and you'll have definitely benefits from that point.

+ +

VICTORIA: And there's a mix of you need people to do the work, but you also need to give them the tools to be able to do their job, right?

+ +

DANIËLLE: Yes, I think most of us in finance still find that Excel is our best friend. [laughs]

+ +

VICTORIA: Well, I won't complain about Excel myself. I have a background in economics, an undergraduate, so I'm an Excel pro.

+ +

DANIËLLE: Yeah, I think definitely Excel has brought us all a very long way. [laughs]

+ +

VICTORIA: So what's different about your customers that you're targeting with Paddle? What's unique about them?

+ +

DANIËLLE: I think what is unique about them is that we want to really bring the creator of softwares their dreams to life, which means it's almost like we want to dream with them if that makes sense. We want to make sure that whatever they build becomes available to the world, whether they are a small startup or a small company or if they are a giant in the industry and very good at their skills.

+ +

So we want to target the entire market for software. And I think what makes them unique is that our customers are usually a fan of our product, but we are a fan of theirs. So I think, typically, that works both ways really well.

+ +

VICTORIA: Yeah, that makes a lot of sense. And do you find that your customers are facing a different set of challenges today than they might have a year ago?

+ +

DANIËLLE: I think the SaaS industry has changed. I think it's no secret that definitely the economic landscape has shifted. I think we were very fortunate to close our Series D in very favorable circumstances before the climate changed. I do think it will change back, and I don't think this is all doom and gloom. But I also do think that we are all facing the situation where we should be taking proactive measures and steps to manage our cost effectively before it is actually required. For some of the SaaS industries, it may already be required, and for others, I think even those doing well should be mindful to take steps where possible.

+ +

Cutting costs does not necessarily mean cutting quality or immediately reducing staff. I think it just is more taking a step back and critically looking at your spend to see, do I have opportunity to renegotiate existing contracts? Are there, especially in my cost of goods sold, can I get this reduced somehow without reducing the quality of my product and what we're delivering as a business? And I think these are very good and big opportunities that we can definitely seize in addition to our operational spend. Just taking a critical look at this can really go a long way.

+ +

VICTORIA: That makes sense. It sounds like, as a VP of finance, those are things that you might be able to bring to the table. Or tell me more about how the role of a finance person plays in a startup in making some of those decisions.

+ +

DANIËLLE: I think the role of a finance person is super critical in the sense of you're looking back to see what the spend was and where we've been and to look forward to what the trends will be. You're also trying to inspire vision and strategy and work together with the sales team to both have realistic forecasts on what we will do, can do, and what we'll actually deliver.

+ +

And I think as a finance leader, more than ever, it is so needed for us to partner with the business instead of being chucked away in a corner somewhere processing financial reports or looking at them. So I think the finance literacy is definitely something that we can add to our organizations. I'll give you an example, as we rolled out our budget, it wasn't just to deliver it to the board or to our executive committee, but it was also to talk about it with our senior leadership.

+ +

I think the senior leadership is also so critical to any organization to say, "Hey, we are going to commit together with our own leaders to make sure that we're executing the plan and that we will also get all of our teams to partner and create that buy-in as a company."

+ +

So I think as a finance leader, it's not just my job to go out there and say, "Hey, we have to cut costs," but also to explain what is happening to the economic climate, why we have to cut costs, and what are the benefits of doing it before it is needed. And definitely paving the road to say, "Hey, this is beneficial for all of us because these are our financial goals that we can achieve, but we can only achieve them together."

+ +

So I think creating that buy-in and building that team across the organization that is committed to the correct finance management is super critical in this day and age. It used to be that it was just finance's role to watch the finances; I think now it's a collaborative effort of the entire company.

+ +

VICTORIA: I really like that I have a background in DevOps, and that's breaking down silos between different parts of the organization. And so I love to hear that finance is getting really involved and be a part of the overall decisions that everyone's making in the company, right?

+ +

DANIËLLE: Yeah, definitely.

+ +

VICTORIA: How does Paddle build stakeholder buy-in within the company? What does that process look like for you all?

+ +

DANIËLLE: I think very early on, we identified that, obviously, our executive team is key. I think this is the tip of the arrow really leading the organization in giving vision and direction. I find that we've been very fortunate, in my humble opinion, because we have a great CEO and a great COO. And I really enjoy working with the entire executive team. They're just a wonderful group of people. Besides being amazing professionals, they're just generally nice, [chuckles] which is always great.

+ +

But we've identified early on that actually your senior leadership right underneath that is so critical to your company's culture, how you hire, how you buy, how you move, how you invest, but also how would your future be like. Because while the executive team definitely is key in giving the direction, the vision, and mission, I think the team right underneath that, the senior leadership team, is really the one that is going to go out there and materialize that dream and vision, and really live that dream, and really get the right people and to get the job done.

+ +

So I think what we've identified early on is to make everybody an active stakeholder, do the planning together. Like, before the executive team rolls out a mission and vision, it's not going to be a total surprise to the senior leadership. We've all taken part of it, and we've all supported it, and we've discussed it, and we've fine-tuned it. So I think definitely taking people along in the journey goes a long way.

+ +

The other thing I think that is very critical is just being transparent and being honest. At the end of the day, we're people. We want to know what's happening, why it's happening, and what we're working towards. And I think that is something that Paddle has done very well as well internally as a team. We have great values and great focus on what we want to deliver, where we want to go, and we definitely are focused on doing so together.

+ +

VICTORIA: That sounds great. You all have a shared vision of where you're going and where you are currently. And that probably helps get everyone on board with what we're working on in the future. It gets everyone motivated a little bit more, right?

+ +

DANIËLLE: Correct. Exactly.

+ +

VICTORIA: So, is there anything particularly exciting coming up with Paddle that you are looking forward to?

+ +

DANIËLLE: I think I'm super excited to see what ProfitWell, how it will integrate, and the product that it will offer, and the opportunities that it will offer to our Paddle customers. I'm super excited to see that materialize and seeing all of this come together. We've been waiting, and we've been working towards this deal for a very long time, so seeing it materialize is quite exciting. And I'm definitely looking forward to that.

+ +

VICTORIA: And do you think that that cultural strength you mentioned with Paddle and having that transparency and quality of support from the leadership does that help translate when you're doing big deals like that and closing deals with other companies?

+ +

DANIËLLE: Yeah, it definitely does. I think, in general, the finance team has had quite an exciting first half of the year. I want to say, you know, being in Series D, having due diligence done, ProfitWell, at the same time preparing for an audit, having your financial team build out your reporting. I think we've had so many things run at the same time, and the pressures are quite high. So I think just having that positive culture together as a team gives you strength as well together to be your best self under pressure instead of really crumbling or not getting along and struggling with it.

+ +

VICTORIA: Yeah, that makes total sense. If you feel like you're supported by other humans in your company, [laughs] then when you're stressed, it makes it easier to get along. That makes a lot of sense. Do you have any other advice for finance leaders or startups who are navigating the economic downturn at this time?

+ +

DANIËLLE: I would say keep an eye open. Do not stop investing. Do be critical about your ROI. Make sure that where you're spending your money is where it makes the most sense for the business, and just keep an eye out for opportunity. Because just because the climate has turned does not mean that it will not turn back, and it does mean that there are loads of opportunities out there that we can still seize as a business.

+ +

VICTORIA: Right. It means that different markets are more active, right? [laughs]

+ +

DANIËLLE: Usually. Correct.

+ +

VICTORIA: Do you have any questions for me or for thoughtbot?

+ +

DANIËLLE: I'm just curious, for you as well, what's your favorite subject that you discuss on thoughtbot?

+ +

VICTORIA: Ooh, a favorite subject. That's tough because I love hearing from our designers and our developers. We have many developers who are some core contributors to Rails, and so they are very knowledgeable about things like we have random meetups that happen at thoughtbot. So you can sign up and just randomly pair up with somebody else in the company.

+ +

And the first random meetup I had, I met up with someone who is like the expert on security [laughs] and dotfiles and helped me finish setting up my developer environment. And so I love that at thoughtbot, you can start a random conversation with someone, and they'll end up having this wealth of knowledge around a particular subject that you might have been struggling with and can just immediately solve your problem.

+ +

I also like the fun parts. There's actually a blog that just captures all of our jokes from Slack [laughter] just… So it's a part of like making it fun and being human at work and kind of showing up with your whole self. I think that adds a cultural strength for those moments like you describe when things are difficult, or you have a hard project. You feel bonded to your teammates and feel like you're all working together, and that positivity stays throughout.

+ +

DANIËLLE: Yes, definitely.

+ +

VICTORIA: So, are you currently in Amsterdam? Is that right?

+ +

DANIËLLE: I am based in the Netherlands. I'm actually based in Alkmaar, which is 30 minutes outside of Amsterdam, but I typically say Amsterdam because that's the city that most people know where it's at. [laughs]

+ +

VICTORIA: Same for me. I go with San Diego, but I'm actually in Encinitas. It's a little bit further north. So is there a difference, or what is the startup environment or community like in Europe then?

+ +

DANIËLLE: I think I'm quite impressed because before moving to the Netherlands, I wasn't aware there was so much happening, but there are actually some channels called Silicon Canals, so the canals for the boats, so it's a bit of a play on words. And there's such a vibrant startup and scale-up community in the Netherlands, which was quite surprising for me to run into. So I do think by nature...I was born in the Netherlands, and I moved to Aruba when I was five. So I wasn't raised here.

+ +

But I think if I look at the Dutch culture, it is quite innovative. And they do tend to find different ways of doing things when it comes to water or building dams. And I think that curiosity and innovation has moved over to the tech space. So I think that Amsterdam is definitely a city to watch in terms of scale-ups that pop up and the progress that they make.

+ +

VICTORIA: I've heard a lot about new technologies and new solutions coming out of the Netherlands with agriculture specifically, but I am not surprised that there's a burgeoning startup community there. [laughs] That's wonderful.

+ +

DANIËLLE: Yeah, it's quite exciting.

+ +

VICTORIA: That's very cool. All right, is there anything that you expected me to ask that I did not ask?

+ +

DANIËLLE: No, I can't think of anything off the top of my head. I think we covered quite a bit.

+ +

VICTORIA: Yes. I'm watching the time and making sure that I'm giving you enough time.

+ +

DANIËLLE: [laughs]

+ +

VICTORIA: I liked this quote from your blog, actually, so I'll repeat it here, "Bad companies are destroyed by crises, good companies survive them, and great companies are improved by them."

+ +

DANIËLLE: Yes, that is definitely one of my favorites.

+ +

VICTORIA: Do you have an example of a company where they went through a crisis, and they came out great afterwards?

+ +

DANIËLLE: I have a friend of mine, actually, that started a company called Limelights. And I think when he started this, he was so focused on marketing and development and so on. When the COVID crisis hit...and he's actually the one that shared that quote with me, we're close friends. He was sharing with me that quote and how he has completely revamped his company from a marketing company, which is basically the first thing that most companies...the expense they started cutting, to an online learning platform, and events, and team development program.

+ +

So I think he's done this so successfully that his business started thriving during the COVID period. And still now, after when things are relatively normalized in the tech space and just the overall spend, he is doing better than he did before this happened. His story of his company was so inspirational to me. And we were talking about that quote, and I'm just like, that's it. That's exactly that innovative culture that you want to see in times of crisis.

+ +

You don't want people to back down and say, "Oh, times are hard. Let's just ride this out." You want people to start looking around, like, how can we do this differently? And how can we navigate these new waters that we're in? And proactively be engaged with your environment to really find alternatives to what is happening.

+ +

VICTORIA: I would guess that having a clear picture on your finances and your customer information would help you be able to make those pivots. Is that right? And how Paddle can help you get out of those [inaudible 23:21]

+ +

DANIËLLE: Yes, that is definitely correct. [laughs] Like I said, we're an end-to-end platform. So you can literally have all of your data at the tip of your fingers to make sure that you make the right financial decisions in addition to us taking off some of the financial tasks off of your plate. Like I said, we want to do it for our customers, make sure that everything is running smoothly. So I think this is a massive opportunity for companies to have additional support in their processes because we take them over to a degree as well as indeed have clarity and transparency into their financial reporting and how their revenue streams are doing.

+ +

VICTORIA: Right. Because I imagine that task that work to put all that together would take up a lot of founder's time.

+ +

DANIËLLE: Yes.

+ +

VICTORIA: So freeing up that time and giving you a chance to understand where you're at now, and where you can go, and be able to pivot in those times of crisis.

+ +

DANIËLLE: Exactly.

+ +

VICTORIA: That makes a lot of sense. Has Paddle found that offering free information or these tools like the Sales Tax Agony Index does that help you bring customers into your platform?

+ +

DANIËLLE: Yes, definitely. I think there's a bit of humor here as well. Obviously, this was not put together by a finance person. [laughs] But I do love that our sales and marketing team is super creative in bringing the finance story and the tax story to life. I think as soon as people hear tax, if you can tune out, you do. So I think they've done a great job at pointing out the Sales Tax Agony Index, and they are not exaggerating. [laughs]

+ +

In many of the jurisdictions, it is quite challenging. And I think one thing that makes it challenging as well...so while software is not new to most of us as users, software is still quite new to most governments, and most countries are not certain when or how to tax this. So I think everybody is trying to figure this out globally, which is where we can step into the space, as well as we do monitor the global landscape for taxes.

+ +

The changes happen fast. They happen continuously. And implementation of taxes is not always logical because taxes are not always logical. So I think looking at the tax agony that our sales and marketing team has put together is definitely not an over-exaggeration. I think the risks are real for misunderstanding or misreading the tax laws that are in place, and so that's where we come in to really bring our experts and really dissect some of the meanings of these. We have partners globally to ensure compliance.

+ +

I think that the tax that is charged on software can be so variable that, as a business by yourself, it's going to be super tricky to monitor. Like in some countries, the software is taxed locally only if you sell to a local customer. It is not taxed locally if it's sold internationally. So there are so many little hooks and needles. In some countries, you don't have to pay tax unless you exceed X amount of sales on your software. So all of these rules and regulations can be quite obstacles and blockers to rolling out your business globally.

+ +

VICTORIA: Right. I hadn't even thought about a lot of that complexity. One of the things I'm excited about most with thoughtbot is that it's an international company. And so I'm out of my DC bubble, and we have customers in England and team members all over the world. So I think it's exciting that there's a product out there that can help you navigate things like taxes across all different countries, which I wouldn't have even thought would be that big of a problem, but apparently, it is. [laughs]

+ +

DANIËLLE: And I think especially when you talk about the tax agony panel, you can also see what the challenges are, and worst penalties, and fines, and prison.

+ +

VICTORIA: [laughs] Yeah, right? It's like, it's very difficult, and the agony is high, and the penalty is high. [laughter] So that's...you don't want to go to prison for accidentally misunderstanding the tax code. That's a real serious risk that you'd face.

+ +

DANIËLLE: Yes, it is. [laughs]

+ +

VICTORIA: Awesome. Do you want to do any final takeaways for our listeners today?

+ +

DANIËLLE: I would say chin up. The economic downturn is not going to last forever. While it's good to look for opportunity to save costs, it's also a great opportunity and moment to look for the right investments to make to grow your company.

+ +

VICTORIA: Wonderful. Well, thank you so much, Daniëlle. I really enjoyed our conversation.

+ +

DANIËLLE: Thank you, Victoria. It was great meeting you.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Daniëlle Keeven.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hello UK Giant Robots listeners! Our next event allows you to hear from and connect with both Founders and Investors on all things Fundraising. The event will be 1 part panel discussion and 1 part breakout sessions. We hope you can make it! Register today at: tbot.io/fundraising-uk

+ +

Daniëlle Keeven is VP of Finance at Paddle, the only complete payments infrastructure provider for SaaS companies.

+ +

Victoria talks to Daniëlle about helping companies with taxes while assuming the liability and risks associated with global tax compliance, financial literacy, and taking proactive measures and steps to manage cost effectively before it is required.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

Hello, United Kingdom Giant Robots listeners! Our next event allows you to hear from and connect with both founders and investors on all things fundraising. The event will be one part panel discussion and one-part breakout sessions. We hope you can make it. Register today at tbot.io/fundraising-uk.

+ +

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Daniëlle Keeven, VP of Finance at Paddle, the only complete payments infrastructure provider for SaaS companies. Daniëlle, thank you for joining us.

+ +

DANIËLLE: Hi, Victoria. Thank you for having me. Super excited to be here.

+ +

VICTORIA: Wonderful. Yes, I'm excited to have you here and to hear a little bit about your background. I was curious how it was different going from a finance role in a large corporation like Marriott to the startup world and to Paddle.

+ +

DANIËLLE: Well, Victoria, I was actually quite fortunate because even in the Marriotts and the Hyatts that I've been in in hospitality, I've been exposed to a lot of in the trench type of accounting and finance. Being in the Caribbean and just a Latam market, you learn to look at situations differently and make sure you work towards compliance. So I think that's really groomed me for stepping into the tech space as well, where I think following the money is the first directive of any finance professional walking into a scale-up or startup. So I think it's groomed me for the move.

+ +

Booking was a little bit easier because it was also a little bit of leisure and travel. When I stepped into a telecom for MessageBird and then Paddle as a payments end-to-end provider of infrastructure, there was a little bit of a challenge there. But I love being part of a company now that's completely a finance product which has really given finance roles a partnership with product and engineering to partner in the way forward and design of the product.

+ +

VICTORIA: Yes, that's exciting for us as well. And tell us a little bit about Paddle, actually.

+ +

DANIËLLE: So Paddle is an end-to-end platform. We strive not to just help software companies; we strive to do the work for them to be able to roll out globally. So basically, Paddle is the only end-to-end infrastructure that will enable you to invoice your customers and get payments support, offering different payment methods, as well as make sure you're globally compliant and file your taxes so that you don't have to.

+ +

I think what sets Paddle apart from a lot of other companies that are helping companies with tax is that we actually do it for you. In addition to that, we assume the full liability and risks associated to global tax compliance.

+ +

VICTORIA: Right. Yes. And I saw a product that you all have or information that you shared called the Sales Tax Agony Index. Can you tell me a little bit about that?

+ +

DANIËLLE: Well, I think, in general, tax is painful. [laughs] I think personal tax is painful. Anything that has to do with business tax is amplified significantly. And I think for software companies, often, you build a great product, and you want to bring it up to market. But then you're limited and slowed down from really expanding globally. I mean, that is where we come in to really take up the tax burden for software creators to be able to look at it as a stepping stone instead of a roadblock if that makes sense.

+ +

VICTORIA: I think that makes a lot of sense. And it's interesting where we are right now with the current climate and economics that companies may be focusing on their finances to reduce cost but also to identify new areas to invest in, right?

+ +

DANIËLLE: Yeah, right. And I think that's super interesting to me, which I keep saying I'm not sure why not all of the software world is on Paddle. Because I think if you look out there in the market, there's such a piecemeal solution to everything. So you have to, for example, if you're going to not build your own billing, you have to outsource buying software for your billing. You have to go find a payment provider that's compatible and then the resources to get them into your platform to make sure checkout is seamless.

+ +

Then you have to get an accountant to reconcile your payment. You have to get customer support to support your customer payments. You have to get more additional headcount to make sure your chargebacks and your fraud rates stay down. And all of this, Paddle just does it for you, which I think especially in this climate where cost is becoming a subject, I think Paddle is a great business partner to enable software companies to grow at a reasonable cost and pricing, and really explore all of the global market out there versus having to do it yourself.

+ +

VICTORIA: Right. And Paddle could maybe help you identify where your spend also has a high return on investment. Is that right?

+ +

DANIËLLE: We do put you in direct contact with your customer, so your customers are not masked or anything like that. So you do have access to all of your customer data. And in addition to that, we've recently made an additional acquisition to grow the Paddle family by adding ProfitWell, which is really an expert in anything that has to do with retention and pricing. And we are working to integrate this product and make it available to our Paddle customers as well. So that is not something that is there today but soon will be.

+ +

VICTORIA: Oh, interesting. And I read a recent interview that you did, and I liked how you connected retaining your customer base to your billing and invoicing process because that might be an afterthought for a lot of startups and founders. But it is really key in keeping your customers happy is having that easy billing and invoice process. Is that your perspective?

+ +

DANIËLLE: Yeah. I definitely think that with any SaaS company, there's definitely something known as well as an abandoned cart like somebody that will, you know, maybe we do it ourselves as well when we go out shopping online. We drop stuff in our cart, and we never make it to checkout. And I think to make sure you optimize your checkout, and your revenue is to make sure that the process is as seamless as possible, that your customers can just flow through this process and not have any challenges during that journey to make sure that your conversion rates stay high.

+ +

VICTORIA: Right. That makes a lot of sense. Do you have other insights about customer retention that may relate to the Paddle platform?

+ +

DANIËLLE: I think what's unique for me as a finance professional looking at the Paddle product...given I am by little biased because I do work here, and I'm a big fan of our product. But I think, and I've talked about this often, there are so many software solutions or tools that finance folks are trying to be sold. We get them sold to us, like, oh, this will automate 100%, and this will reduce this, or this will reduce that.

+ +

I think what Paddle does well and how we are uniquely positioned is that what should be automated is automated and what needs a human touch has a human touch. And what I mean with that as well is in the sense of your customers making a payment and having a challenge we actually offer customer support with real people. And we do support your customers to make sure that they have a pleasant journey in the checkout process or resolve any payment issues that they have. So I think we balance the two out.

+ +

And it's similar to, for example, taxes as well. We automate what we can, but we have a team of tax analysts really looking at the data and making sure everything is running correctly and is exactly compliant as it should be. So I think we bring together the best of both worlds in saying we automate a portion of the journey and where we can use and should use the human touch and intellect we do so. So we're not promising 100% percent automation. We just promise that we will do it for you by combining the best of both worlds.

+ +

VICTORIA: That makes sense, right? Because, at some point, the automation can become more effective than hiring. But how can you scale your business without having to double your finance reporting and your tax teams, right?

+ +

DANIËLLE: And I fully agree. And I think you bring up a very interesting point. I think from my past; I had been at Booking where you were in a situation where you have an endless means of cash flow that you can really build your dream automation tools. I think a lot of the big automation that Booking has achieved in finance is really admirable, and a majority of it has been done in-house. So I think they've done a really great job with that.

+ +

But then, when you step out of an organization like that into a smaller startup scale-up, you do not have infinite funds. You are talking mostly about cash burn and then your cash runway. And you do have to optimize between a decision of should I invest in tooling to automate? Or does it make sense for me to hire a person because hiring a person is more cost-effective than automating?

+ +

I think in a cash-tight environment, you do have to evaluate what makes more sense; sometimes, it is hiring a person. Sometimes hiring one person will get you scaled for two years. And other times, if you looked at you will have to hire one or five people per year to do a certain task, then it makes sense definitely to invest in automation because the cost will be upfront, but the benefits will be scalable, and you'll have definitely benefits from that point.

+ +

VICTORIA: And there's a mix of you need people to do the work, but you also need to give them the tools to be able to do their job, right?

+ +

DANIËLLE: Yes, I think most of us in finance still find that Excel is our best friend. [laughs]

+ +

VICTORIA: Well, I won't complain about Excel myself. I have a background in economics, an undergraduate, so I'm an Excel pro.

+ +

DANIËLLE: Yeah, I think definitely Excel has brought us all a very long way. [laughs]

+ +

VICTORIA: So what's different about your customers that you're targeting with Paddle? What's unique about them?

+ +

DANIËLLE: I think what is unique about them is that we want to really bring the creator of softwares their dreams to life, which means it's almost like we want to dream with them if that makes sense. We want to make sure that whatever they build becomes available to the world, whether they are a small startup or a small company or if they are a giant in the industry and very good at their skills.

+ +

So we want to target the entire market for software. And I think what makes them unique is that our customers are usually a fan of our product, but we are a fan of theirs. So I think, typically, that works both ways really well.

+ +

VICTORIA: Yeah, that makes a lot of sense. And do you find that your customers are facing a different set of challenges today than they might have a year ago?

+ +

DANIËLLE: I think the SaaS industry has changed. I think it's no secret that definitely the economic landscape has shifted. I think we were very fortunate to close our Series D in very favorable circumstances before the climate changed. I do think it will change back, and I don't think this is all doom and gloom. But I also do think that we are all facing the situation where we should be taking proactive measures and steps to manage our cost effectively before it is actually required. For some of the SaaS industries, it may already be required, and for others, I think even those doing well should be mindful to take steps where possible.

+ +

Cutting costs does not necessarily mean cutting quality or immediately reducing staff. I think it just is more taking a step back and critically looking at your spend to see, do I have opportunity to renegotiate existing contracts? Are there, especially in my cost of goods sold, can I get this reduced somehow without reducing the quality of my product and what we're delivering as a business? And I think these are very good and big opportunities that we can definitely seize in addition to our operational spend. Just taking a critical look at this can really go a long way.

+ +

VICTORIA: That makes sense. It sounds like, as a VP of finance, those are things that you might be able to bring to the table. Or tell me more about how the role of a finance person plays in a startup in making some of those decisions.

+ +

DANIËLLE: I think the role of a finance person is super critical in the sense of you're looking back to see what the spend was and where we've been and to look forward to what the trends will be. You're also trying to inspire vision and strategy and work together with the sales team to both have realistic forecasts on what we will do, can do, and what we'll actually deliver.

+ +

And I think as a finance leader, more than ever, it is so needed for us to partner with the business instead of being chucked away in a corner somewhere processing financial reports or looking at them. So I think the finance literacy is definitely something that we can add to our organizations. I'll give you an example, as we rolled out our budget, it wasn't just to deliver it to the board or to our executive committee, but it was also to talk about it with our senior leadership.

+ +

I think the senior leadership is also so critical to any organization to say, "Hey, we are going to commit together with our own leaders to make sure that we're executing the plan and that we will also get all of our teams to partner and create that buy-in as a company."

+ +

So I think as a finance leader, it's not just my job to go out there and say, "Hey, we have to cut costs," but also to explain what is happening to the economic climate, why we have to cut costs, and what are the benefits of doing it before it is needed. And definitely paving the road to say, "Hey, this is beneficial for all of us because these are our financial goals that we can achieve, but we can only achieve them together."

+ +

So I think creating that buy-in and building that team across the organization that is committed to the correct finance management is super critical in this day and age. It used to be that it was just finance's role to watch the finances; I think now it's a collaborative effort of the entire company.

+ +

VICTORIA: I really like that I have a background in DevOps, and that's breaking down silos between different parts of the organization. And so I love to hear that finance is getting really involved and be a part of the overall decisions that everyone's making in the company, right?

+ +

DANIËLLE: Yeah, definitely.

+ +

VICTORIA: How does Paddle build stakeholder buy-in within the company? What does that process look like for you all?

+ +

DANIËLLE: I think very early on, we identified that, obviously, our executive team is key. I think this is the tip of the arrow really leading the organization in giving vision and direction. I find that we've been very fortunate, in my humble opinion, because we have a great CEO and a great COO. And I really enjoy working with the entire executive team. They're just a wonderful group of people. Besides being amazing professionals, they're just generally nice, [chuckles] which is always great.

+ +

But we've identified early on that actually your senior leadership right underneath that is so critical to your company's culture, how you hire, how you buy, how you move, how you invest, but also how would your future be like. Because while the executive team definitely is key in giving the direction, the vision, and mission, I think the team right underneath that, the senior leadership team, is really the one that is going to go out there and materialize that dream and vision, and really live that dream, and really get the right people and to get the job done.

+ +

So I think what we've identified early on is to make everybody an active stakeholder, do the planning together. Like, before the executive team rolls out a mission and vision, it's not going to be a total surprise to the senior leadership. We've all taken part of it, and we've all supported it, and we've discussed it, and we've fine-tuned it. So I think definitely taking people along in the journey goes a long way.

+ +

The other thing I think that is very critical is just being transparent and being honest. At the end of the day, we're people. We want to know what's happening, why it's happening, and what we're working towards. And I think that is something that Paddle has done very well as well internally as a team. We have great values and great focus on what we want to deliver, where we want to go, and we definitely are focused on doing so together.

+ +

VICTORIA: That sounds great. You all have a shared vision of where you're going and where you are currently. And that probably helps get everyone on board with what we're working on in the future. It gets everyone motivated a little bit more, right?

+ +

DANIËLLE: Correct. Exactly.

+ +

VICTORIA: So, is there anything particularly exciting coming up with Paddle that you are looking forward to?

+ +

DANIËLLE: I think I'm super excited to see what ProfitWell, how it will integrate, and the product that it will offer, and the opportunities that it will offer to our Paddle customers. I'm super excited to see that materialize and seeing all of this come together. We've been waiting, and we've been working towards this deal for a very long time, so seeing it materialize is quite exciting. And I'm definitely looking forward to that.

+ +

VICTORIA: And do you think that that cultural strength you mentioned with Paddle and having that transparency and quality of support from the leadership does that help translate when you're doing big deals like that and closing deals with other companies?

+ +

DANIËLLE: Yeah, it definitely does. I think, in general, the finance team has had quite an exciting first half of the year. I want to say, you know, being in Series D, having due diligence done, ProfitWell, at the same time preparing for an audit, having your financial team build out your reporting. I think we've had so many things run at the same time, and the pressures are quite high. So I think just having that positive culture together as a team gives you strength as well together to be your best self under pressure instead of really crumbling or not getting along and struggling with it.

+ +

VICTORIA: Yeah, that makes total sense. If you feel like you're supported by other humans in your company, [laughs] then when you're stressed, it makes it easier to get along. That makes a lot of sense. Do you have any other advice for finance leaders or startups who are navigating the economic downturn at this time?

+ +

DANIËLLE: I would say keep an eye open. Do not stop investing. Do be critical about your ROI. Make sure that where you're spending your money is where it makes the most sense for the business, and just keep an eye out for opportunity. Because just because the climate has turned does not mean that it will not turn back, and it does mean that there are loads of opportunities out there that we can still seize as a business.

+ +

VICTORIA: Right. It means that different markets are more active, right? [laughs]

+ +

DANIËLLE: Usually. Correct.

+ +

VICTORIA: Do you have any questions for me or for thoughtbot?

+ +

DANIËLLE: I'm just curious, for you as well, what's your favorite subject that you discuss on thoughtbot?

+ +

VICTORIA: Ooh, a favorite subject. That's tough because I love hearing from our designers and our developers. We have many developers who are some core contributors to Rails, and so they are very knowledgeable about things like we have random meetups that happen at thoughtbot. So you can sign up and just randomly pair up with somebody else in the company.

+ +

And the first random meetup I had, I met up with someone who is like the expert on security [laughs] and dotfiles and helped me finish setting up my developer environment. And so I love that at thoughtbot, you can start a random conversation with someone, and they'll end up having this wealth of knowledge around a particular subject that you might have been struggling with and can just immediately solve your problem.

+ +

I also like the fun parts. There's actually a blog that just captures all of our jokes from Slack [laughter] just… So it's a part of like making it fun and being human at work and kind of showing up with your whole self. I think that adds a cultural strength for those moments like you describe when things are difficult, or you have a hard project. You feel bonded to your teammates and feel like you're all working together, and that positivity stays throughout.

+ +

DANIËLLE: Yes, definitely.

+ +

VICTORIA: So, are you currently in Amsterdam? Is that right?

+ +

DANIËLLE: I am based in the Netherlands. I'm actually based in Alkmaar, which is 30 minutes outside of Amsterdam, but I typically say Amsterdam because that's the city that most people know where it's at. [laughs]

+ +

VICTORIA: Same for me. I go with San Diego, but I'm actually in Encinitas. It's a little bit further north. So is there a difference, or what is the startup environment or community like in Europe then?

+ +

DANIËLLE: I think I'm quite impressed because before moving to the Netherlands, I wasn't aware there was so much happening, but there are actually some channels called Silicon Canals, so the canals for the boats, so it's a bit of a play on words. And there's such a vibrant startup and scale-up community in the Netherlands, which was quite surprising for me to run into. So I do think by nature...I was born in the Netherlands, and I moved to Aruba when I was five. So I wasn't raised here.

+ +

But I think if I look at the Dutch culture, it is quite innovative. And they do tend to find different ways of doing things when it comes to water or building dams. And I think that curiosity and innovation has moved over to the tech space. So I think that Amsterdam is definitely a city to watch in terms of scale-ups that pop up and the progress that they make.

+ +

VICTORIA: I've heard a lot about new technologies and new solutions coming out of the Netherlands with agriculture specifically, but I am not surprised that there's a burgeoning startup community there. [laughs] That's wonderful.

+ +

DANIËLLE: Yeah, it's quite exciting.

+ +

VICTORIA: That's very cool. All right, is there anything that you expected me to ask that I did not ask?

+ +

DANIËLLE: No, I can't think of anything off the top of my head. I think we covered quite a bit.

+ +

VICTORIA: Yes. I'm watching the time and making sure that I'm giving you enough time.

+ +

DANIËLLE: [laughs]

+ +

VICTORIA: I liked this quote from your blog, actually, so I'll repeat it here, "Bad companies are destroyed by crises, good companies survive them, and great companies are improved by them."

+ +

DANIËLLE: Yes, that is definitely one of my favorites.

+ +

VICTORIA: Do you have an example of a company where they went through a crisis, and they came out great afterwards?

+ +

DANIËLLE: I have a friend of mine, actually, that started a company called Limelights. And I think when he started this, he was so focused on marketing and development and so on. When the COVID crisis hit...and he's actually the one that shared that quote with me, we're close friends. He was sharing with me that quote and how he has completely revamped his company from a marketing company, which is basically the first thing that most companies...the expense they started cutting, to an online learning platform, and events, and team development program.

+ +

So I think he's done this so successfully that his business started thriving during the COVID period. And still now, after when things are relatively normalized in the tech space and just the overall spend, he is doing better than he did before this happened. His story of his company was so inspirational to me. And we were talking about that quote, and I'm just like, that's it. That's exactly that innovative culture that you want to see in times of crisis.

+ +

You don't want people to back down and say, "Oh, times are hard. Let's just ride this out." You want people to start looking around, like, how can we do this differently? And how can we navigate these new waters that we're in? And proactively be engaged with your environment to really find alternatives to what is happening.

+ +

VICTORIA: I would guess that having a clear picture on your finances and your customer information would help you be able to make those pivots. Is that right? And how Paddle can help you get out of those [inaudible 23:21]

+ +

DANIËLLE: Yes, that is definitely correct. [laughs] Like I said, we're an end-to-end platform. So you can literally have all of your data at the tip of your fingers to make sure that you make the right financial decisions in addition to us taking off some of the financial tasks off of your plate. Like I said, we want to do it for our customers, make sure that everything is running smoothly. So I think this is a massive opportunity for companies to have additional support in their processes because we take them over to a degree as well as indeed have clarity and transparency into their financial reporting and how their revenue streams are doing.

+ +

VICTORIA: Right. Because I imagine that task that work to put all that together would take up a lot of founder's time.

+ +

DANIËLLE: Yes.

+ +

VICTORIA: So freeing up that time and giving you a chance to understand where you're at now, and where you can go, and be able to pivot in those times of crisis.

+ +

DANIËLLE: Exactly.

+ +

VICTORIA: That makes a lot of sense. Has Paddle found that offering free information or these tools like the Sales Tax Agony Index does that help you bring customers into your platform?

+ +

DANIËLLE: Yes, definitely. I think there's a bit of humor here as well. Obviously, this was not put together by a finance person. [laughs] But I do love that our sales and marketing team is super creative in bringing the finance story and the tax story to life. I think as soon as people hear tax, if you can tune out, you do. So I think they've done a great job at pointing out the Sales Tax Agony Index, and they are not exaggerating. [laughs]

+ +

In many of the jurisdictions, it is quite challenging. And I think one thing that makes it challenging as well...so while software is not new to most of us as users, software is still quite new to most governments, and most countries are not certain when or how to tax this. So I think everybody is trying to figure this out globally, which is where we can step into the space, as well as we do monitor the global landscape for taxes.

+ +

The changes happen fast. They happen continuously. And implementation of taxes is not always logical because taxes are not always logical. So I think looking at the tax agony that our sales and marketing team has put together is definitely not an over-exaggeration. I think the risks are real for misunderstanding or misreading the tax laws that are in place, and so that's where we come in to really bring our experts and really dissect some of the meanings of these. We have partners globally to ensure compliance.

+ +

I think that the tax that is charged on software can be so variable that, as a business by yourself, it's going to be super tricky to monitor. Like in some countries, the software is taxed locally only if you sell to a local customer. It is not taxed locally if it's sold internationally. So there are so many little hooks and needles. In some countries, you don't have to pay tax unless you exceed X amount of sales on your software. So all of these rules and regulations can be quite obstacles and blockers to rolling out your business globally.

+ +

VICTORIA: Right. I hadn't even thought about a lot of that complexity. One of the things I'm excited about most with thoughtbot is that it's an international company. And so I'm out of my DC bubble, and we have customers in England and team members all over the world. So I think it's exciting that there's a product out there that can help you navigate things like taxes across all different countries, which I wouldn't have even thought would be that big of a problem, but apparently, it is. [laughs]

+ +

DANIËLLE: And I think especially when you talk about the tax agony panel, you can also see what the challenges are, and worst penalties, and fines, and prison.

+ +

VICTORIA: [laughs] Yeah, right? It's like, it's very difficult, and the agony is high, and the penalty is high. [laughter] So that's...you don't want to go to prison for accidentally misunderstanding the tax code. That's a real serious risk that you'd face.

+ +

DANIËLLE: Yes, it is. [laughs]

+ +

VICTORIA: Awesome. Do you want to do any final takeaways for our listeners today?

+ +

DANIËLLE: I would say chin up. The economic downturn is not going to last forever. While it's good to look for opportunity to save costs, it's also a great opportunity and moment to look for the right investments to make to grow your company.

+ +

VICTORIA: Wonderful. Well, thank you so much, Daniëlle. I really enjoyed our conversation.

+ +

DANIËLLE: Thank you, Victoria. It was great meeting you.

+ +

VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Daniëlle Keeven.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+UO20ps0g + + ]]> + + Victoria Guido + Daniëlle Keeven + + + 443: Airbrake with Göran Sandahl + https://podcast.thoughtbot.com/443 + 4ab43741-7b12-4838-bcd3-e74cf389fe8b + Thu, 06 Oct 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Göran Sandahl is Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack. + +Victoria talks to Göran about having a product-led growth engine, how Airbrake can help developers identify and solve errors and bugs in applications, and developing a product geared towards a specific segment of the market. + 22:36 + no + + + Hello UK Giant Robots listeners! Our next event allows you to hear from and connect with both Founders and Investors on all things Fundraising. The event will be 1 part panel discussion and 1 part breakout sessions. We hope you can make it! Register today at: tbot.io/fundraising-uk (https://thoughtbot.com/events/fundraising-uk-event?utm_source=socials&utm_medium=socials&utm_campaign=UK%20fundraising%20event) +Göran Sandahl is Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack. +Victoria talks to Göran about having a product-led growth engine, how Airbrake can help developers identify and solve errors and bugs in applications, and developing a product geared towards a specific segment of the market. +Airbrake (https://www.airbrake.io/) +Follow Airbrake on Twitter (https://twitter.com/airbrake/), GitHub (https://github.com/airbrake/), Facebook (https://www.facebook.com/airbrake.io), YouTube (https://www.youtube.com/c/airbrakechannel), or LinkedIn (https://www.linkedin.com/company/airbrake-io/). +Follow Göran on Twitter (https://twitter.com/gsandahl) or LinkedIn (https://www.linkedin.com/in/goransandahl/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Göran Sandahl, Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack. Göran, thank you for joining us. +GÖRAN: Thanks for having me. +VICTORIA: Wonderful. So just tell me a little bit more about Airbrake and how it all got started. +GÖRAN: So Airbrake is, as you said, an error and performance monitoring tool. It was actually, funnily enough, started as a side-project within thoughtbot. So it's a little bit full circle here joining this podcast here. But I'm a recent addition to Airbrake, so I don't know the details of the time when they started over ten years ago. So talking about Airbrake and the journey since then, lots of things have happened with Airbrake. +It has gone through multiple acquisitions since then, both from industry players on the infrastructure side to various venture capital investors buying the company. And now Airbrake is owned by LogicMonitor, who bought Airbrake somewhat like a year ago. And it focuses exclusively on the developer audience for LogicMonitor. +And I lead growth, so I work with our growth team. We have a product-led growth engine. So we don't do a lot of traditional sales or anything like that, so a lot of it is word of mouth. And this is something that drew me to Airbrake was its strong kind of grassroots movement in Ruby and other web and application languages. So that's what I know about Airbrake's early days, which isn't a lot. +VICTORIA: Right. It was the very first exception monitoring service in the world. And we grew it to have three people working full time on it. And then, like what you said, it was sold to someone else who went on to continue to grow it. And it has been through several acquisitions. And from your perspective today, where is this service originally called Hoptoad [laughs], and then now it's Airbrake? And what kind of scale are you seeing? What are your customers like today? +GÖRAN: Obviously, I don't know exactly how the product looked like back then. But a lot of it, I think, has stayed the same. It focuses on simple error monitoring, simple performance monitoring, and simple deployment tracking. So it's pretty much the same focus I believe in the product. This is what makes it stand out still today. +We can talk about observability, and happy to do that. This is my third company that I've been working for as a monitoring company, so I know fairly a bit about it. Airbrake today is heavily focused on...we focus on what we call lean dev teams. We focus on the teams that try to move a little bit quicker, maybe than what they may, doesn't necessarily have the backup of an ops team or a DevOps team. +So we really focus on building a product that is fully self-service that you can get started within a minute on your own. So that implies good UX, good documentation, and also that we can meet our users where they are. So we're focusing today on things like community building and those things for supporting our users. So we have lots of customers, really good brand names. First and foremost, super interesting stories from many of our customers who navigate that art of building product quickly. +VICTORIA: That's great. I like that you phrased it as your user experience, which is your development teams, right? And do you have more of a perspective around the developer experience and how to capture that and really create something that's useful when you're delivering in those high-velocity environments? +GÖRAN: As I said, I've been working for three monitoring companies. The first one I founded was 12 years ago. We built a product that we tried to coin the market called algorithmic monitoring, that later turned into something called AIOps. Yeah, there are a lot of buzzwords around that, applying AI to identifying problems in software. We were really early on that. +One thing that we learned from that journey...we ended up selling that company to LogicMonitor, which is why I'm eventually here. What we learned then is that you can have a really good monitoring product, but ultimately, the people that fix the problem that gets discovered is the most important person for a monitoring tool to get into true effectiveness. +So when I came across Airbrake, when they were acquired by LogicMonitor, and I had the opportunity to join, that's what drove me to decide to join. It's really that simplicity in terms of I think there are two schools, right? Either you promote a tool that all your software engineers should use, and you try to build centralized, structured processes around that. You make the template thing and things like that so that everybody can get up and running really quickly with monitoring. +Or you take the approach of something like Airbrake, where it's built to be easy. If you know the language, if you know the code, then you know how to basically instrument it. And these features are simple enough to get going on your own. So that's the path that Airbrake is on. So it's built to be simple from the gate, so to speak. +Now, Airbrake and monitoring and observability is a complicated problem when you have software issues. They're not always easy to diagnose or get to the root cause of. So there's a lot of struggle for users to unwind the bugs and actually fix them. But we try to do the best to provide enough context so they can take the next step. +VICTORIA: And maybe you have an example or something to illustrate how that tool can help developers identify and solve those errors and bugs in the application. +GÖRAN: All software has issues, right? There are bugs in all kinds of software. I've always been fascinated with something called latent bugs, or dark death is another framing of it, which is essentially the bugs that are hidden in your code. And when we have an outage, something triggers that bug to happen, but that bug was there. +So if we think about it like that, that all of our software, all the code we run, all the commits we do is probably adding a lot of value, but they're also adding fragility or potential for problems, then you need to be really good at identifying when those bugs get activated. And sometimes, actually in, the majority of times...so that's why you need error monitoring, right? Just the ability to see that there is an error, there's a new error in production or in our staging environment, or wherever it might be. So that's error monitoring. +It turns out about 80% of outages are self-inflicted in a way. They're caused by the changes when we build software or when we reconfigure things. And 80% that means that you need to be able to track changes really well. So you need to understand how and when changes happen so you can understand if what you did worked or didn't, so that's why we have deployment tracking, to be able to correlate those errors with the release, the commit, the line of code you added to the codebase. +And then, of course, performance monitoring which is the ability to see where you have bottlenecks, which is not maybe bugs but where you have poor performance or poor experience for users. And it could be in a shopping cart checkout job. It could also be a scheduled cron job that's supposed to clean up stuff that is late. It could be just a rendering time of something that is longer than usual, and you just want to be aware of it. So that is kind of performance monitoring. +So those are the three main focuses for us as a product. We like to believe that it is easy to get going within a couple of minutes. And that's what we're kind of focusing on providing. +VICTORIA: Yeah, that makes a lot of sense to me. And your tool is able to just spin up quickly, be able to quickly get that insight into what's happening as you're deploying code and as you're pushing changes to production. Do you call that all observability? Or, in your mind, what is observability? And what are the really key things that you think that all developers should be watching? +GÖRAN: That is a good question. Part of what fascinates me about the Airbrake userbase and what I've got to learn about Ruby and some of those languages which were a little bit foreign to me as a backend engineer, like an algorithm junkie, so to speak...so what fascinates me is how little monitoring is typically done by many teams that's working on web applications. So coming from the infrastructure monitoring side, that's where this term observability grew. And you have these metrics, logs, and traces kind of triad. And every web application, every web browser has had tracing built in the developer console or the web browser. +So some of these tools that are available now to infrastructure monitoring teams in the form of observability have been available to web developers for quite some time, so I don't necessarily think observability is a term that explains a lot for applications and web developers. But for infrastructure, more infrastructure-oriented teams where you have lots of microservices and things like that, we needed a term to explain the full range of capabilities we needed. But I'm not so sure we need the similar amount of complexity because there is a lot of complexity in those tools and lots of data. +But I'm not so sure we need the same complexity when speaking about monitoring on slightly more lightweight applications and web apps. That said, we're starting to mimic a lot of the architectural paradigms of the infrastructure, such as microservices, in terms of micro frontends. So a lot of that complexity is entering into the web as well. So, who knows? [laughs] +MIDROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. +VICTORIA: So the customer or clients for Airbrake are developers who are doing web applications and need that kind of just the information they need [chuckles] to be able to make sure their changes to code is not affecting the production and that your product is trending towards observability practices that might be a little overmatch to what you will need. +GÖRAN: Yeah, that is what we're focusing on. But when you have a lot of customers and a lot of users, there's always this exotic, for us, exotic use cases. So I'm 100% sure there are really large customers that are using us in a more traditional DevOps fashion and not on web apps. I mean, we have support for most of the languages from Go to Python to .NET to Ruby. So there's nothing keeping Go developers from adopting something like Airbrake. +But we do know that we're particularly strong within JavaScript and Ruby, and I think that speaks for the experience that it's easy to get going, et cetera, rather than something like Grafana or another more traditional observability tool that's a little bit out of reach maybe for the web or application developer. +VICTORIA: So when you're developing your product towards this specific segment of the market, what other differences do you notice between who you're targeting or who you're expecting your customer to be versus the wider range of people you could be marketing this towards? +GÖRAN: So I think everybody wants to go after the developer and the needs of the developer. This is, so to speak, trendy nowadays. And it's obvious because so much of the value and innovation happening is done [chuckles] in the editor. So it's natural that a lot of the focus is being placed there. +We're focusing on where we're strong, and I think that's the best way to do it unless the market is small. And I see application development growing for the foreseeable future. I think we're seeing trends of things like no-code, or low-code, or whatever we choose to call it. The infrastructure is being abstracted more and more. +So from that perspective, I think we have a good strategy for providing that simplicity that users come to expect when building modern apps today. We're pairing with other kinds of innovations on how you build code, basically from things like Vercel to Webflow to whatever it might be, right? +VICTORIA: Right. And do you find that collaborative approach is more effective in business-to-business sales for this type of client? +GÖRAN: We're very focused on this just try it kind of approach, so that's how we do most of our direct communications with our users. So we want to let the app speak for itself. And we believe that once usage happens, then additional needs will happen or will arise that we can maybe serve in other ways. +So we do have a free tier, free forever free tier, so you can use Airbrake pretty much forever but in a small scale. And then, like normal, when you start adding colleagues or lots of errors and lots of projects, then you need to upgrade to a paid plan. And we're also launching some new tiers here in the foreseeable future as well. +VICTORIA: Oh, tell me more about that. +GÖRAN: As teams mature...I don't know if that's the right word, but at some point, a lot of these teams may want a little bit more structure when they do monitoring. So I mentioned that we're pretty much self-service, completely self-service. But at some point, when you start using a product a lot, you start to integrate it into your core processes. So new things start to matter, things like who did that change? Who reconfigured that? Who logged in the last time? Has anybody seen that thing? But also to things like payment things. The different issues that can arise change, right? +VICTORIA: Mm-hmm. +GÖRAN: So we're launching a pro tier in the future that will cater to a little bit more of the needs of the team that has grown into maybe having a manager that asks questions about how things are set up, et cetera, but also, where you can control teams and people a little bit better, where you can also control your costs a little bit. +So one of the features is on-demand billing. So the more errors you pay on your tier...you can produce up to a certain set of errors and performance events, and if you go above that, you pay an on-demand fee. And there are some protections built in for that if you're on the pro plan and things like that. So it's about catering to growing needs of a little bit larger teams but still the team that wants to move fast. +VICTORIA: Right. And I believe you said that you have plans to communicate and engage with the community, and that probably helps you understand some of those needs. And so what kind of plans do you have coming up that you'd like to share? +GÖRAN: So one of the things we know is with all the Airbrake use, we probably have a lot of fans out there, but we might not have been the best to actually tap into that and serve that community. So we want to really invest in understanding, getting to know that community, and serving that in the best way we can. So we will see exactly which form that will take. +But it starts with the basics, opening up a Slack community that we can allow users to join and ask questions or maybe hopefully get value out of their peers without talking to us maybe. But we can also serve them in various ways with support, et cetera. So it will start pretty basic, but I think it's a pretty standard playbook nowadays. +But for us, it's really about we're genuinely...we think our users are awesome, and we would love to be able to share their stories and connect them with other peers. So I think that's the driving motivation. And then, of course, we have some data that also shows that it is a good investment in itself, that the stories our customers tell are much better than the stories we tell. So yeah, we're excited about that for sure. +And it's connected to this bottoms up motion from where Airbrake grew from, that it grew as a solution that served the community really well. And we want to go back to those roots and be the best tool for that kind of user. +VICTORIA: Oh, I love that. It sounds like a really great, full-circle journey for the product. And is there anything else you want to share about entrepreneurship and starting up products like this? What advice would you give to someone who had developed this type of product that served the community well and wanted to turn it into a product and a business? +GÖRAN: So I think the community building is relatively new for us, so I'm not sure the advice there is so valuable. But in terms of entrepreneurship, I think this is one of the more important decisions you make as an entrepreneur or founder is how will you grow demand for your product and how will you distribute the product? And how will you ultimately monetize the product? And there are so many different ways. +And depending on what your growth expectations are, you might be asked to go in one direction or another one. And my advice would be to really find product-market fit and that I think happens best by staying close to the end users, and then you can look at strategies for monetization, including direct sales or channel or, as Airbrake does, product-led freemium basically. But reach product-market fit first so you can decide with knowing how your product dynamics and adoption dynamics works, and let that influence the kind of strategy for the business strategy basically rather than the other way around. +VICTORIA: Right. That makes sense. And then, if your product is geared towards developers, they're just like any other users. And you have to reach them and get their feedback and understand how the product fits into the market. +GÖRAN: Yeah, exactly. +VICTORIA: Yeah. Great. All right. Do you have any questions for me at this time? +GÖRAN: Not really. It was a pleasure being on the podcast. I'm a fan so hope you can cover up my errors there. +[laughter] +VICTORIA: I think that if you want to go back and remove, we totally can. But are there any other major takeaways you want people to walk away with about Airbrake or, in general, about entrepreneurship? +GÖRAN: That's about it, I think. +VICTORIA: All right. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Göran Sandahl. + + + Hello UK Giant Robots listeners! Our next event allows you to hear from and connect with both Founders and Investors on all things Fundraising. The event will be 1 part panel discussion and 1 part breakout sessions. We hope you can make it! Register today at: tbot.io/fundraising-uk

+ +

Göran Sandahl is Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack.

+ +

Victoria talks to Göran about having a product-led growth engine, how Airbrake can help developers identify and solve errors and bugs in applications, and developing a product geared towards a specific segment of the market.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Göran Sandahl, Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack. Göran, thank you for joining us.

+ +

GÖRAN: Thanks for having me.

+ +

VICTORIA: Wonderful. So just tell me a little bit more about Airbrake and how it all got started.

+ +

GÖRAN: So Airbrake is, as you said, an error and performance monitoring tool. It was actually, funnily enough, started as a side-project within thoughtbot. So it's a little bit full circle here joining this podcast here. But I'm a recent addition to Airbrake, so I don't know the details of the time when they started over ten years ago. So talking about Airbrake and the journey since then, lots of things have happened with Airbrake.

+ +

It has gone through multiple acquisitions since then, both from industry players on the infrastructure side to various venture capital investors buying the company. And now Airbrake is owned by LogicMonitor, who bought Airbrake somewhat like a year ago. And it focuses exclusively on the developer audience for LogicMonitor.

+ +

And I lead growth, so I work with our growth team. We have a product-led growth engine. So we don't do a lot of traditional sales or anything like that, so a lot of it is word of mouth. And this is something that drew me to Airbrake was its strong kind of grassroots movement in Ruby and other web and application languages. So that's what I know about Airbrake's early days, which isn't a lot.

+ +

VICTORIA: Right. It was the very first exception monitoring service in the world. And we grew it to have three people working full time on it. And then, like what you said, it was sold to someone else who went on to continue to grow it. And it has been through several acquisitions. And from your perspective today, where is this service originally called Hoptoad [laughs], and then now it's Airbrake? And what kind of scale are you seeing? What are your customers like today?

+ +

GÖRAN: Obviously, I don't know exactly how the product looked like back then. But a lot of it, I think, has stayed the same. It focuses on simple error monitoring, simple performance monitoring, and simple deployment tracking. So it's pretty much the same focus I believe in the product. This is what makes it stand out still today.

+ +

We can talk about observability, and happy to do that. This is my third company that I've been working for as a monitoring company, so I know fairly a bit about it. Airbrake today is heavily focused on...we focus on what we call lean dev teams. We focus on the teams that try to move a little bit quicker, maybe than what they may, doesn't necessarily have the backup of an ops team or a DevOps team.

+ +

So we really focus on building a product that is fully self-service that you can get started within a minute on your own. So that implies good UX, good documentation, and also that we can meet our users where they are. So we're focusing today on things like community building and those things for supporting our users. So we have lots of customers, really good brand names. First and foremost, super interesting stories from many of our customers who navigate that art of building product quickly.

+ +

VICTORIA: That's great. I like that you phrased it as your user experience, which is your development teams, right? And do you have more of a perspective around the developer experience and how to capture that and really create something that's useful when you're delivering in those high-velocity environments?

+ +

GÖRAN: As I said, I've been working for three monitoring companies. The first one I founded was 12 years ago. We built a product that we tried to coin the market called algorithmic monitoring, that later turned into something called AIOps. Yeah, there are a lot of buzzwords around that, applying AI to identifying problems in software. We were really early on that.

+ +

One thing that we learned from that journey...we ended up selling that company to LogicMonitor, which is why I'm eventually here. What we learned then is that you can have a really good monitoring product, but ultimately, the people that fix the problem that gets discovered is the most important person for a monitoring tool to get into true effectiveness.

+ +

So when I came across Airbrake, when they were acquired by LogicMonitor, and I had the opportunity to join, that's what drove me to decide to join. It's really that simplicity in terms of I think there are two schools, right? Either you promote a tool that all your software engineers should use, and you try to build centralized, structured processes around that. You make the template thing and things like that so that everybody can get up and running really quickly with monitoring.

+ +

Or you take the approach of something like Airbrake, where it's built to be easy. If you know the language, if you know the code, then you know how to basically instrument it. And these features are simple enough to get going on your own. So that's the path that Airbrake is on. So it's built to be simple from the gate, so to speak.

+ +

Now, Airbrake and monitoring and observability is a complicated problem when you have software issues. They're not always easy to diagnose or get to the root cause of. So there's a lot of struggle for users to unwind the bugs and actually fix them. But we try to do the best to provide enough context so they can take the next step.

+ +

VICTORIA: And maybe you have an example or something to illustrate how that tool can help developers identify and solve those errors and bugs in the application.

+ +

GÖRAN: All software has issues, right? There are bugs in all kinds of software. I've always been fascinated with something called latent bugs, or dark death is another framing of it, which is essentially the bugs that are hidden in your code. And when we have an outage, something triggers that bug to happen, but that bug was there.

+ +

So if we think about it like that, that all of our software, all the code we run, all the commits we do is probably adding a lot of value, but they're also adding fragility or potential for problems, then you need to be really good at identifying when those bugs get activated. And sometimes, actually in, the majority of times...so that's why you need error monitoring, right? Just the ability to see that there is an error, there's a new error in production or in our staging environment, or wherever it might be. So that's error monitoring.

+ +

It turns out about 80% of outages are self-inflicted in a way. They're caused by the changes when we build software or when we reconfigure things. And 80% that means that you need to be able to track changes really well. So you need to understand how and when changes happen so you can understand if what you did worked or didn't, so that's why we have deployment tracking, to be able to correlate those errors with the release, the commit, the line of code you added to the codebase.

+ +

And then, of course, performance monitoring which is the ability to see where you have bottlenecks, which is not maybe bugs but where you have poor performance or poor experience for users. And it could be in a shopping cart checkout job. It could also be a scheduled cron job that's supposed to clean up stuff that is late. It could be just a rendering time of something that is longer than usual, and you just want to be aware of it. So that is kind of performance monitoring.

+ +

So those are the three main focuses for us as a product. We like to believe that it is easy to get going within a couple of minutes. And that's what we're kind of focusing on providing.

+ +

VICTORIA: Yeah, that makes a lot of sense to me. And your tool is able to just spin up quickly, be able to quickly get that insight into what's happening as you're deploying code and as you're pushing changes to production. Do you call that all observability? Or, in your mind, what is observability? And what are the really key things that you think that all developers should be watching?

+ +

GÖRAN: That is a good question. Part of what fascinates me about the Airbrake userbase and what I've got to learn about Ruby and some of those languages which were a little bit foreign to me as a backend engineer, like an algorithm junkie, so to speak...so what fascinates me is how little monitoring is typically done by many teams that's working on web applications. So coming from the infrastructure monitoring side, that's where this term observability grew. And you have these metrics, logs, and traces kind of triad. And every web application, every web browser has had tracing built in the developer console or the web browser.

+ +

So some of these tools that are available now to infrastructure monitoring teams in the form of observability have been available to web developers for quite some time, so I don't necessarily think observability is a term that explains a lot for applications and web developers. But for infrastructure, more infrastructure-oriented teams where you have lots of microservices and things like that, we needed a term to explain the full range of capabilities we needed. But I'm not so sure we need the similar amount of complexity because there is a lot of complexity in those tools and lots of data.

+ +

But I'm not so sure we need the same complexity when speaking about monitoring on slightly more lightweight applications and web apps. That said, we're starting to mimic a lot of the architectural paradigms of the infrastructure, such as microservices, in terms of micro frontends. So a lot of that complexity is entering into the web as well. So, who knows? [laughs]

+ +

MIDROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So the customer or clients for Airbrake are developers who are doing web applications and need that kind of just the information they need [chuckles] to be able to make sure their changes to code is not affecting the production and that your product is trending towards observability practices that might be a little overmatch to what you will need.

+ +

GÖRAN: Yeah, that is what we're focusing on. But when you have a lot of customers and a lot of users, there's always this exotic, for us, exotic use cases. So I'm 100% sure there are really large customers that are using us in a more traditional DevOps fashion and not on web apps. I mean, we have support for most of the languages from Go to Python to .NET to Ruby. So there's nothing keeping Go developers from adopting something like Airbrake.

+ +

But we do know that we're particularly strong within JavaScript and Ruby, and I think that speaks for the experience that it's easy to get going, et cetera, rather than something like Grafana or another more traditional observability tool that's a little bit out of reach maybe for the web or application developer.

+ +

VICTORIA: So when you're developing your product towards this specific segment of the market, what other differences do you notice between who you're targeting or who you're expecting your customer to be versus the wider range of people you could be marketing this towards?

+ +

GÖRAN: So I think everybody wants to go after the developer and the needs of the developer. This is, so to speak, trendy nowadays. And it's obvious because so much of the value and innovation happening is done [chuckles] in the editor. So it's natural that a lot of the focus is being placed there.

+ +

We're focusing on where we're strong, and I think that's the best way to do it unless the market is small. And I see application development growing for the foreseeable future. I think we're seeing trends of things like no-code, or low-code, or whatever we choose to call it. The infrastructure is being abstracted more and more.

+ +

So from that perspective, I think we have a good strategy for providing that simplicity that users come to expect when building modern apps today. We're pairing with other kinds of innovations on how you build code, basically from things like Vercel to Webflow to whatever it might be, right?

+ +

VICTORIA: Right. And do you find that collaborative approach is more effective in business-to-business sales for this type of client?

+ +

GÖRAN: We're very focused on this just try it kind of approach, so that's how we do most of our direct communications with our users. So we want to let the app speak for itself. And we believe that once usage happens, then additional needs will happen or will arise that we can maybe serve in other ways.

+ +

So we do have a free tier, free forever free tier, so you can use Airbrake pretty much forever but in a small scale. And then, like normal, when you start adding colleagues or lots of errors and lots of projects, then you need to upgrade to a paid plan. And we're also launching some new tiers here in the foreseeable future as well.

+ +

VICTORIA: Oh, tell me more about that.

+ +

GÖRAN: As teams mature...I don't know if that's the right word, but at some point, a lot of these teams may want a little bit more structure when they do monitoring. So I mentioned that we're pretty much self-service, completely self-service. But at some point, when you start using a product a lot, you start to integrate it into your core processes. So new things start to matter, things like who did that change? Who reconfigured that? Who logged in the last time? Has anybody seen that thing? But also to things like payment things. The different issues that can arise change, right?

+ +

VICTORIA: Mm-hmm.

+ +

GÖRAN: So we're launching a pro tier in the future that will cater to a little bit more of the needs of the team that has grown into maybe having a manager that asks questions about how things are set up, et cetera, but also, where you can control teams and people a little bit better, where you can also control your costs a little bit.

+ +

So one of the features is on-demand billing. So the more errors you pay on your tier...you can produce up to a certain set of errors and performance events, and if you go above that, you pay an on-demand fee. And there are some protections built in for that if you're on the pro plan and things like that. So it's about catering to growing needs of a little bit larger teams but still the team that wants to move fast.

+ +

VICTORIA: Right. And I believe you said that you have plans to communicate and engage with the community, and that probably helps you understand some of those needs. And so what kind of plans do you have coming up that you'd like to share?

+ +

GÖRAN: So one of the things we know is with all the Airbrake use, we probably have a lot of fans out there, but we might not have been the best to actually tap into that and serve that community. So we want to really invest in understanding, getting to know that community, and serving that in the best way we can. So we will see exactly which form that will take.

+ +

But it starts with the basics, opening up a Slack community that we can allow users to join and ask questions or maybe hopefully get value out of their peers without talking to us maybe. But we can also serve them in various ways with support, et cetera. So it will start pretty basic, but I think it's a pretty standard playbook nowadays.

+ +

But for us, it's really about we're genuinely...we think our users are awesome, and we would love to be able to share their stories and connect them with other peers. So I think that's the driving motivation. And then, of course, we have some data that also shows that it is a good investment in itself, that the stories our customers tell are much better than the stories we tell. So yeah, we're excited about that for sure.

+ +

And it's connected to this bottoms up motion from where Airbrake grew from, that it grew as a solution that served the community really well. And we want to go back to those roots and be the best tool for that kind of user.

+ +

VICTORIA: Oh, I love that. It sounds like a really great, full-circle journey for the product. And is there anything else you want to share about entrepreneurship and starting up products like this? What advice would you give to someone who had developed this type of product that served the community well and wanted to turn it into a product and a business?

+ +

GÖRAN: So I think the community building is relatively new for us, so I'm not sure the advice there is so valuable. But in terms of entrepreneurship, I think this is one of the more important decisions you make as an entrepreneur or founder is how will you grow demand for your product and how will you distribute the product? And how will you ultimately monetize the product? And there are so many different ways.

+ +

And depending on what your growth expectations are, you might be asked to go in one direction or another one. And my advice would be to really find product-market fit and that I think happens best by staying close to the end users, and then you can look at strategies for monetization, including direct sales or channel or, as Airbrake does, product-led freemium basically. But reach product-market fit first so you can decide with knowing how your product dynamics and adoption dynamics works, and let that influence the kind of strategy for the business strategy basically rather than the other way around.

+ +

VICTORIA: Right. That makes sense. And then, if your product is geared towards developers, they're just like any other users. And you have to reach them and get their feedback and understand how the product fits into the market.

+ +

GÖRAN: Yeah, exactly.

+ +

VICTORIA: Yeah. Great. All right. Do you have any questions for me at this time?

+ +

GÖRAN: Not really. It was a pleasure being on the podcast. I'm a fan so hope you can cover up my errors there.

+ +

[laughter]

+ +

VICTORIA: I think that if you want to go back and remove, we totally can. But are there any other major takeaways you want people to walk away with about Airbrake or, in general, about entrepreneurship?

+ +

GÖRAN: That's about it, I think.

+ +

VICTORIA: All right. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Göran Sandahl.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Hello UK Giant Robots listeners! Our next event allows you to hear from and connect with both Founders and Investors on all things Fundraising. The event will be 1 part panel discussion and 1 part breakout sessions. We hope you can make it! Register today at: tbot.io/fundraising-uk

+ +

Göran Sandahl is Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack.

+ +

Victoria talks to Göran about having a product-led growth engine, how Airbrake can help developers identify and solve errors and bugs in applications, and developing a product geared towards a specific segment of the market.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

VICTORIA: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Göran Sandahl, Director of Growth at Airbrake LogicMonitor, frictionless error monitoring and performance insights for your entire app stack. Göran, thank you for joining us.

+ +

GÖRAN: Thanks for having me.

+ +

VICTORIA: Wonderful. So just tell me a little bit more about Airbrake and how it all got started.

+ +

GÖRAN: So Airbrake is, as you said, an error and performance monitoring tool. It was actually, funnily enough, started as a side-project within thoughtbot. So it's a little bit full circle here joining this podcast here. But I'm a recent addition to Airbrake, so I don't know the details of the time when they started over ten years ago. So talking about Airbrake and the journey since then, lots of things have happened with Airbrake.

+ +

It has gone through multiple acquisitions since then, both from industry players on the infrastructure side to various venture capital investors buying the company. And now Airbrake is owned by LogicMonitor, who bought Airbrake somewhat like a year ago. And it focuses exclusively on the developer audience for LogicMonitor.

+ +

And I lead growth, so I work with our growth team. We have a product-led growth engine. So we don't do a lot of traditional sales or anything like that, so a lot of it is word of mouth. And this is something that drew me to Airbrake was its strong kind of grassroots movement in Ruby and other web and application languages. So that's what I know about Airbrake's early days, which isn't a lot.

+ +

VICTORIA: Right. It was the very first exception monitoring service in the world. And we grew it to have three people working full time on it. And then, like what you said, it was sold to someone else who went on to continue to grow it. And it has been through several acquisitions. And from your perspective today, where is this service originally called Hoptoad [laughs], and then now it's Airbrake? And what kind of scale are you seeing? What are your customers like today?

+ +

GÖRAN: Obviously, I don't know exactly how the product looked like back then. But a lot of it, I think, has stayed the same. It focuses on simple error monitoring, simple performance monitoring, and simple deployment tracking. So it's pretty much the same focus I believe in the product. This is what makes it stand out still today.

+ +

We can talk about observability, and happy to do that. This is my third company that I've been working for as a monitoring company, so I know fairly a bit about it. Airbrake today is heavily focused on...we focus on what we call lean dev teams. We focus on the teams that try to move a little bit quicker, maybe than what they may, doesn't necessarily have the backup of an ops team or a DevOps team.

+ +

So we really focus on building a product that is fully self-service that you can get started within a minute on your own. So that implies good UX, good documentation, and also that we can meet our users where they are. So we're focusing today on things like community building and those things for supporting our users. So we have lots of customers, really good brand names. First and foremost, super interesting stories from many of our customers who navigate that art of building product quickly.

+ +

VICTORIA: That's great. I like that you phrased it as your user experience, which is your development teams, right? And do you have more of a perspective around the developer experience and how to capture that and really create something that's useful when you're delivering in those high-velocity environments?

+ +

GÖRAN: As I said, I've been working for three monitoring companies. The first one I founded was 12 years ago. We built a product that we tried to coin the market called algorithmic monitoring, that later turned into something called AIOps. Yeah, there are a lot of buzzwords around that, applying AI to identifying problems in software. We were really early on that.

+ +

One thing that we learned from that journey...we ended up selling that company to LogicMonitor, which is why I'm eventually here. What we learned then is that you can have a really good monitoring product, but ultimately, the people that fix the problem that gets discovered is the most important person for a monitoring tool to get into true effectiveness.

+ +

So when I came across Airbrake, when they were acquired by LogicMonitor, and I had the opportunity to join, that's what drove me to decide to join. It's really that simplicity in terms of I think there are two schools, right? Either you promote a tool that all your software engineers should use, and you try to build centralized, structured processes around that. You make the template thing and things like that so that everybody can get up and running really quickly with monitoring.

+ +

Or you take the approach of something like Airbrake, where it's built to be easy. If you know the language, if you know the code, then you know how to basically instrument it. And these features are simple enough to get going on your own. So that's the path that Airbrake is on. So it's built to be simple from the gate, so to speak.

+ +

Now, Airbrake and monitoring and observability is a complicated problem when you have software issues. They're not always easy to diagnose or get to the root cause of. So there's a lot of struggle for users to unwind the bugs and actually fix them. But we try to do the best to provide enough context so they can take the next step.

+ +

VICTORIA: And maybe you have an example or something to illustrate how that tool can help developers identify and solve those errors and bugs in the application.

+ +

GÖRAN: All software has issues, right? There are bugs in all kinds of software. I've always been fascinated with something called latent bugs, or dark death is another framing of it, which is essentially the bugs that are hidden in your code. And when we have an outage, something triggers that bug to happen, but that bug was there.

+ +

So if we think about it like that, that all of our software, all the code we run, all the commits we do is probably adding a lot of value, but they're also adding fragility or potential for problems, then you need to be really good at identifying when those bugs get activated. And sometimes, actually in, the majority of times...so that's why you need error monitoring, right? Just the ability to see that there is an error, there's a new error in production or in our staging environment, or wherever it might be. So that's error monitoring.

+ +

It turns out about 80% of outages are self-inflicted in a way. They're caused by the changes when we build software or when we reconfigure things. And 80% that means that you need to be able to track changes really well. So you need to understand how and when changes happen so you can understand if what you did worked or didn't, so that's why we have deployment tracking, to be able to correlate those errors with the release, the commit, the line of code you added to the codebase.

+ +

And then, of course, performance monitoring which is the ability to see where you have bottlenecks, which is not maybe bugs but where you have poor performance or poor experience for users. And it could be in a shopping cart checkout job. It could also be a scheduled cron job that's supposed to clean up stuff that is late. It could be just a rendering time of something that is longer than usual, and you just want to be aware of it. So that is kind of performance monitoring.

+ +

So those are the three main focuses for us as a product. We like to believe that it is easy to get going within a couple of minutes. And that's what we're kind of focusing on providing.

+ +

VICTORIA: Yeah, that makes a lot of sense to me. And your tool is able to just spin up quickly, be able to quickly get that insight into what's happening as you're deploying code and as you're pushing changes to production. Do you call that all observability? Or, in your mind, what is observability? And what are the really key things that you think that all developers should be watching?

+ +

GÖRAN: That is a good question. Part of what fascinates me about the Airbrake userbase and what I've got to learn about Ruby and some of those languages which were a little bit foreign to me as a backend engineer, like an algorithm junkie, so to speak...so what fascinates me is how little monitoring is typically done by many teams that's working on web applications. So coming from the infrastructure monitoring side, that's where this term observability grew. And you have these metrics, logs, and traces kind of triad. And every web application, every web browser has had tracing built in the developer console or the web browser.

+ +

So some of these tools that are available now to infrastructure monitoring teams in the form of observability have been available to web developers for quite some time, so I don't necessarily think observability is a term that explains a lot for applications and web developers. But for infrastructure, more infrastructure-oriented teams where you have lots of microservices and things like that, we needed a term to explain the full range of capabilities we needed. But I'm not so sure we need the similar amount of complexity because there is a lot of complexity in those tools and lots of data.

+ +

But I'm not so sure we need the same complexity when speaking about monitoring on slightly more lightweight applications and web apps. That said, we're starting to mimic a lot of the architectural paradigms of the infrastructure, such as microservices, in terms of micro frontends. So a lot of that complexity is entering into the web as well. So, who knows? [laughs]

+ +

MIDROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

+ +

VICTORIA: So the customer or clients for Airbrake are developers who are doing web applications and need that kind of just the information they need [chuckles] to be able to make sure their changes to code is not affecting the production and that your product is trending towards observability practices that might be a little overmatch to what you will need.

+ +

GÖRAN: Yeah, that is what we're focusing on. But when you have a lot of customers and a lot of users, there's always this exotic, for us, exotic use cases. So I'm 100% sure there are really large customers that are using us in a more traditional DevOps fashion and not on web apps. I mean, we have support for most of the languages from Go to Python to .NET to Ruby. So there's nothing keeping Go developers from adopting something like Airbrake.

+ +

But we do know that we're particularly strong within JavaScript and Ruby, and I think that speaks for the experience that it's easy to get going, et cetera, rather than something like Grafana or another more traditional observability tool that's a little bit out of reach maybe for the web or application developer.

+ +

VICTORIA: So when you're developing your product towards this specific segment of the market, what other differences do you notice between who you're targeting or who you're expecting your customer to be versus the wider range of people you could be marketing this towards?

+ +

GÖRAN: So I think everybody wants to go after the developer and the needs of the developer. This is, so to speak, trendy nowadays. And it's obvious because so much of the value and innovation happening is done [chuckles] in the editor. So it's natural that a lot of the focus is being placed there.

+ +

We're focusing on where we're strong, and I think that's the best way to do it unless the market is small. And I see application development growing for the foreseeable future. I think we're seeing trends of things like no-code, or low-code, or whatever we choose to call it. The infrastructure is being abstracted more and more.

+ +

So from that perspective, I think we have a good strategy for providing that simplicity that users come to expect when building modern apps today. We're pairing with other kinds of innovations on how you build code, basically from things like Vercel to Webflow to whatever it might be, right?

+ +

VICTORIA: Right. And do you find that collaborative approach is more effective in business-to-business sales for this type of client?

+ +

GÖRAN: We're very focused on this just try it kind of approach, so that's how we do most of our direct communications with our users. So we want to let the app speak for itself. And we believe that once usage happens, then additional needs will happen or will arise that we can maybe serve in other ways.

+ +

So we do have a free tier, free forever free tier, so you can use Airbrake pretty much forever but in a small scale. And then, like normal, when you start adding colleagues or lots of errors and lots of projects, then you need to upgrade to a paid plan. And we're also launching some new tiers here in the foreseeable future as well.

+ +

VICTORIA: Oh, tell me more about that.

+ +

GÖRAN: As teams mature...I don't know if that's the right word, but at some point, a lot of these teams may want a little bit more structure when they do monitoring. So I mentioned that we're pretty much self-service, completely self-service. But at some point, when you start using a product a lot, you start to integrate it into your core processes. So new things start to matter, things like who did that change? Who reconfigured that? Who logged in the last time? Has anybody seen that thing? But also to things like payment things. The different issues that can arise change, right?

+ +

VICTORIA: Mm-hmm.

+ +

GÖRAN: So we're launching a pro tier in the future that will cater to a little bit more of the needs of the team that has grown into maybe having a manager that asks questions about how things are set up, et cetera, but also, where you can control teams and people a little bit better, where you can also control your costs a little bit.

+ +

So one of the features is on-demand billing. So the more errors you pay on your tier...you can produce up to a certain set of errors and performance events, and if you go above that, you pay an on-demand fee. And there are some protections built in for that if you're on the pro plan and things like that. So it's about catering to growing needs of a little bit larger teams but still the team that wants to move fast.

+ +

VICTORIA: Right. And I believe you said that you have plans to communicate and engage with the community, and that probably helps you understand some of those needs. And so what kind of plans do you have coming up that you'd like to share?

+ +

GÖRAN: So one of the things we know is with all the Airbrake use, we probably have a lot of fans out there, but we might not have been the best to actually tap into that and serve that community. So we want to really invest in understanding, getting to know that community, and serving that in the best way we can. So we will see exactly which form that will take.

+ +

But it starts with the basics, opening up a Slack community that we can allow users to join and ask questions or maybe hopefully get value out of their peers without talking to us maybe. But we can also serve them in various ways with support, et cetera. So it will start pretty basic, but I think it's a pretty standard playbook nowadays.

+ +

But for us, it's really about we're genuinely...we think our users are awesome, and we would love to be able to share their stories and connect them with other peers. So I think that's the driving motivation. And then, of course, we have some data that also shows that it is a good investment in itself, that the stories our customers tell are much better than the stories we tell. So yeah, we're excited about that for sure.

+ +

And it's connected to this bottoms up motion from where Airbrake grew from, that it grew as a solution that served the community really well. And we want to go back to those roots and be the best tool for that kind of user.

+ +

VICTORIA: Oh, I love that. It sounds like a really great, full-circle journey for the product. And is there anything else you want to share about entrepreneurship and starting up products like this? What advice would you give to someone who had developed this type of product that served the community well and wanted to turn it into a product and a business?

+ +

GÖRAN: So I think the community building is relatively new for us, so I'm not sure the advice there is so valuable. But in terms of entrepreneurship, I think this is one of the more important decisions you make as an entrepreneur or founder is how will you grow demand for your product and how will you distribute the product? And how will you ultimately monetize the product? And there are so many different ways.

+ +

And depending on what your growth expectations are, you might be asked to go in one direction or another one. And my advice would be to really find product-market fit and that I think happens best by staying close to the end users, and then you can look at strategies for monetization, including direct sales or channel or, as Airbrake does, product-led freemium basically. But reach product-market fit first so you can decide with knowing how your product dynamics and adoption dynamics works, and let that influence the kind of strategy for the business strategy basically rather than the other way around.

+ +

VICTORIA: Right. That makes sense. And then, if your product is geared towards developers, they're just like any other users. And you have to reach them and get their feedback and understand how the product fits into the market.

+ +

GÖRAN: Yeah, exactly.

+ +

VICTORIA: Yeah. Great. All right. Do you have any questions for me at this time?

+ +

GÖRAN: Not really. It was a pleasure being on the podcast. I'm a fan so hope you can cover up my errors there.

+ +

[laughter]

+ +

VICTORIA: I think that if you want to go back and remove, we totally can. But are there any other major takeaways you want people to walk away with about Airbrake or, in general, about entrepreneurship?

+ +

GÖRAN: That's about it, I think.

+ +

VICTORIA: All right. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Göran Sandahl.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+trGmmw-Y + + ]]> + + Victoria Guido + Göran Sandahl + + + 442: Zedosh & The Attention Exchange with Guillaume Kendall + https://podcast.thoughtbot.com/442 + fe47007b-cab6-4608-8e11-445533cdc791 + Thu, 29 Sep 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Guillaume Kendall is the Founder of Zedosh and Attention Exchange, which is working to build a safe place for advertisers, publishers, and consumers to all benefit from fair access to human attention. + +Chad talks with Guillaume about open banking, changing up who the beneficiaries of consumer attention and data are, and giving companies opportunities to advertise without interrupting consumers with ads. + 36:43 + no + + + Guillaume Kendall is the Founder of Zedosh and Attention Exchange, which is working to build a safe place for advertisers, publishers, and consumers to all benefit from fair access to human attention. +Chad talks with Guillaume about open banking, changing up who the beneficiaries of consumer attention and data are, and giving companies opportunities to advertise without interrupting consumers with ads. +Zedosh (https://zedosh.com/) +The Attention Exchange (https://attentionexchange.co.uk/) +Follow The Attention Exchange on Twitter (https://twitter.com/attnexchange) or LinkedIn (https://www.linkedin.com/company/the-attention-exchange/). +Follow Guillaume on LinkedIn (https://www.linkedin.com/in/guillaumekendall/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Guillaume Kendall, the Founder of Zedosh and the Attention Exchange, which is working to build a safe place for advertisers, publishers, and consumers to all benefit from fair access to human attention. Guillaume, thank you for joining me. +GUILLAUME: Thank you so much for having me. It's a real privilege. +CHAD: If I'm not mistaken, you and I first met in person for lunch one time in London when I was visiting London in; I think it was...I went back and looked at my calendar. It was March 10th, 2020, if I'm not mistaken, either that or it was that Friday of that week. +GUILLAUME: It must have been one of the last weeks pre-pandemic. +CHAD: It was. I literally woke up on Saturday morning for my flight to come back to the U.S. to the headlines that all flights from Europe were being shut down. [laughs] And I almost dropped my phone until I realized, oh, that's the headline, but the real detail is I can get back. It's all the rest of Europe, not the UK, yet. That was the following week. I made it home, and then the world changed. +GUILLAUME: I sure did, didn't it? [laughs] It's funny, isn't it? Because the two-year period in between seems to have flown by. It feels like just yesterday. I remember I think, even what I ate. +CHAD: [laughs] And at the time, you were working on a new application, and we were talking about that. But I want to fast forward a little bit to today. Tell me more about Attention Exchange, and then we're going to rewind a bit to how you've arrived. +GUILLAUME: So the Attention Exchange...by way of background, I come from the fintech space rather than adtech. And it really, ultimately, the Attention Exchange is a matching engine, using financial terms, that matches the right video content to the right consumer based on their spending data rather than their browsing data. So it's a matching engine. +And it looks at rules that ultimately we're able to derive, or actually, I better use the phrase, we can bridge the gap between attention and intention based on our audience's spending patterns. And the reason we can access those is because they give us explicit permission. We have something called open banking here in the UK. It's actually across most of Europe now. But it enables the consumer to own their data and share it outside the bank if they so wish to with other regulated third parties. +So we're such a regulated third party, and they share that data with us, as I said, to be matched with video content from brands that are relevant to their spending instead of their browsing. What it ultimately means is we're very well-positioned in this apparent post-cookie world that seems to be heading our way eventually because we don't rely on any other tracking technology to spy on our audience. They voluntarily give it to us. +And I guess the kicker which is...people are probably asking themselves, why would they do that? That's because they get paid. So we put cash directly into the bank account or one of the bank accounts they've connected to our platform in exchange for their immutably valuable attention to that content. +CHAD: So correct me if I'm wrong, but I feel like open banking has had a significant impact not only on the data sharing that you're describing but just on the banking ecosystem in general in the United Kingdom and now Europe. +GUILLAUME: So I think if you were to speak to the purveyors of open banking, it hasn't had as big an impact as they felt it would have had. I think we reached earlier this year only to fact-check this, but about 6 million people in the UK now utilize open banking in one form or another. +But I think what was very interesting is that the ecosystem that sprung up around it was mostly around changing the user experience for the end consumer to have a better handle on their financial health, which is a really important topic. And the reason that is is that before, it wasn't really in the bank's interests to tell you if you're about to hit your overdraft or go over your overdraft because they'd charge you an extra 20 pounds for an unplanned loan, and then you'd have to pay it. Your balances (This is going back a little. I'm showing my age. ) was always two or three days out of date, which was weird. +So open banking; the first thing that sprung up around it is we'll connect your bank accounts. We'll give you this holistic view of your mortgages, your credit, your debit, your net worth really across various assets. And we've moved progressively towards more of open finance rather than just open banking. You can connect via APIs a lot of your financial identity to these open banking providers. +But having said that, no one has looked at it in the way that we have, which is actually this is an advertising play, and it could be potentially a real change maker in the way that consumers benefit from this $400 billion industry which is advertising rather than all the fintech stuff that's been happening around open banking. +But yes, so it's not to be sniffed at, you know, several million people are using open banking. But most people, I don't even think, realize they're using open banking. They open the Revolut app, and it says, "Do you want to see your Monzo balance inside our app?" You say, "Well, yeah, okay, that means I don't have to open Monzo." And lo and behold, you share that data. +CHAD: Right. Yeah, that's a really good perspective. I think from my perspective; I was thinking it's sort of made it...there's a separation between the banking backends and the user experience, and I think that in part has given rise to these challenger banks and made it more possible for them to do that. +GUILLAUME: Yeah, that's a very fair point. I think, certainly, if nothing else, it certainly forced the incumbent players, those that have been around for a few hundred years, to really buckle up their ideas and think about how to react to this new threat. At first, they thought, geez, open banking is going to cause us all sorts of problems, but I think as it's gone full circle. You find that, actually, most people are looking for that user experience, and the banks have been forced to provide it within their existing ecosystem. +So now, most banking apps provide really super UI or UX, meaning that you don't have to go use third-party tools to get such a lens. And in fact, the most interesting one I've seen of late, which I think is definitely worth a mention, is a company called Cogo; and Cogo used open banking to carbon score your spending and let you offset it. So if you spent four pounds at McDonald's, it would guess that that's X kilos of carbon and give you several options to offset it. +And actually, in the end, NatWest formed a partnership with them. This is a classic use case where actually, now the carbons offseter is available within that NatWest app, and you don't really have any idea it's Cogo. That's what you're seeing is ironically, those who have had success in innovative, exciting use cases have been pulled back into the ecosystem being offered because they still want the scale overnight. They had access to 8 million NatWest customers or whatever the number is. +So, yes, I think; certainly, all banking apps have had to, even the banks themselves, have had to reorganize and rethink how they deliver technology to retail consumers who probably had had very little churn in the past because the options were very limited. +CHAD: That's great. So tell me about the genesis for this idea and realizing that you could use open banking to view people's financial information and to develop a profile that could be used to opt into advertising. Where's the genesis of that idea for you? +GUILLAUME: Sure. So actually, several threads came together very neatly in quite a tight timescale, the first of which is I spent a lot of money, relatively speaking, on a company called Patch Plants. And Patch Plants deliver plants to your house, [laughter] and they have quite a nice way to go about it. All the plants have got human names, and they come with little booklets about how to look after them. +And I felt very positive about the relationship I felt I had with Patch Plants until for the three, maybe four months following that purchase, there wasn't a website, or a social feed that I was on that didn't have Patch Plants all over it. And I really took note of my sentiment towards them [laughs] where I thought, go away, Patch Plants. I'm a customer. Why don't you know better? With the amount of data that we provide to the web, you just assume...and maybe this is where it all starts to click into place that actually, it's not that smart. +CHAD: The interesting thing is I think it is possible for companies to on target you once they decide to do it, but it seems like nobody does that. [laughs] And it's like, I've just bought a stove. Why am I seeing stoves all over the place? [laughs] I'm not going to buy another one. +GUILLAUME: Yeah, again, I think it comes from the underlying infrastructure, which is basically this concept of cookies, which we accept on every single website before we can do anything with it. And you've probably got a number of unchecked-out stoves across the web. And it's not locking on to the fact you've got one checked-out stove. +But of course, we're connected to the bank account. And so when we see that transaction, we see the counterparties. We know for a fact that that person has made that transaction with that vendor, and therefore, you probably need to change the message. And that goes from daily purchases right through to the massive, heavy items we can see when people started a car leasing agreement. +Well, if you want to get them to think about considering your brand of vehicle in two or three years or three or four years, there's probably a journey that you should take that person on. But then again, once they've made the purchase, don't keep hassling them. So that's the first thing. If you saw my bank account...so I worked with open banking innovation [laughs]. I guess that's pretty important. +CHAD: [laughs] +GUILLAUME: So I was acutely aware of how the data could be shared and analyzed, so that's the first point. And then, pretty much at the same time, Netflix brought out this documentary, The Social Dilemma, really putting across that these social media applications were basically designed, maybe it's not a surprise, but pretty much as gambling apps. They're exceptionally addictive. And the reason they're addictive is because the longer you spend on them, the more advertising they can slide into; now, I think one in every four posts. +And now that we've moved on to short-form video content, there's infinite scroll. We're all on these apps for hours a day. But the only way they generate revenues is through advertising, and the only way they get advertising is by you spending more time. And it sort of didn't sit too well with me, especially after we had the Euro Championship in football or soccer here. And there was a ton of racist abuse that went out to players across social media. Lots of brands and advertisers started pulling away from it for a very short period of time to express their protest. +But I realized then that, actually, there is no alternative. If you want to attract attention, you have to fund social media or Google, and that's kind of it. Those are your options as a brand or an advertiser. And the former being social media is really not a very healthy place to spend time. Sure, some good comes out of it. But I would argue that the bad that comes out of it far outweighs any of the good that's come from social media, certainly in the last five years or so, I believe. It's at the center of some major divisions in our communities. But it's all funded through advertising revenue. +So that was the second point is that there really is no alternative. And why should Mark Zuckerberg be the beneficiary of my attention, my data, my value whilst putting absolutely no effort in changing or being an arbiter of the content? They're keeping their hands up saying, hey, we're not a publisher. If that content is there, it's there. And it becomes a very complicated argument very quickly around free speech and all of this sort of stuff. But ultimately, there's a ton of really nasty stuff. +And then we had a family friend, specifically, who really put herself in a lot of danger, a young girl. And that was a very real impact on human life close to us that was all driven from what she was able to access with alarming ease via Instagram. So those sorts of threads all came together. And then the more sort of...it's one of those things, right? Once you see a yellow car, you're looking out for a yellow car. You keep seeing them. But I don't think I was proactively looking out for it too much. +But it seemed that every day almost, there was a new-new story in the front pages of the papers where Facebook was in some sort of trouble, and that obviously materialized last year with the Facebook leaks. And everything we've been just discussing now they've known about. They know about it. They're choosing not to make a difference. +So we had a really powerful motivation to try and bring about a different mechanism for this $400 billion industry to operate. And rather than exploit our data, exploit our mental well-being, exploit our communities and everything else in order to drive advertising revenue, maybe the advertiser could have a more direct relationship, a fair and more transparent relationship with the consumer with whom they want a dialogue. +And I think it's been the biggest learning curve for us is that brands and advertisers feel weird about paying consumers to pay attention. But we're saying we think it is weirder that you pay Google and Facebook to track these people all over the web and interrupt them everywhere they don't want to be spoken to. Why not just pay them to have a fair, transparent dialogue? I know you have money. I know you spend it with my competitors who are in my market. I want your attention, and this is what I have to tell you. There we go. So that was the sort of the kernel, the genesis. +CHAD: I can totally see why advertisers are...scared is not the right word. Just, you know, it's just they've never had a relationship where they're paying the consumer directly for any kind of advertising that they do [chuckles] whether it be TV historically. There's always an intermediary. And the idea of paying people directly is not only different, but in some ways, I can imagine people view it as crude. Like, it's one thing if it's going through an intermediary and you're paying them, and advertising is being run, but it's another to just pay someone to pay attention to you. +GUILLAUME: Yeah, but I think this is the point about the open banking. I completely agree with you; if you're paying somebody based on their cookies or any of the other data, the first-party data or third-party data, that's abstracted several layers from that pair of eyeballs that you know has a tendency to buy X on Y time horizon. That's never been possible before. +And so through your television, it's scale. You're paying the broadcaster because they've got 3 million people watching Coronation Street on, I don't know, whatever. But it's always based on these tiny, tiny fractions of engagement, and that's always been the way it is. So you need the intermediary for scale. +But I think what I'm hoping, what I've literally bet my house on [laughter], that's one thing that's going to change. I sold my house since we started to do this. All those marketplaces are completely saturated, and they are not getting less busy; they're getting more busy. And so okay, TikToks appeared, but the medium through which video content is provided to the consumer, you're lucky to get a quarter of a second or half a second with that person. +And so you're right, but what is now the alternative to actually getting a minute, a minute and a half, two minutes with somebody where they're not skipping; they're not going past? You know they're a real person. You know they're human. All of our consumers have to have a bank account. They have to have transactions, and they have to have an income in order to be valuable and receive any adverts into their feed. So it's just never been possible before. +The scale play, the intermediary, was always sort of, I think, accepted, and it still is today. There's going to be a bunch of fraud. I think there's like 15 cents in every dollar spent online digitally for advertising is lost. I think it's a $100 billion problem by next year. So I guess the point I'm making is the intermediaries historically and to today have existed because you need to reach millions of eyeballs in order to get a very low interaction rate. +With our model, we're able to target thousands of people and achieve a 19.6% average click-through rate even after a minute and a half worth of content because they're engaged and you're not interrupting them. So we think it's a relatively elegant model for what is a saturated, noisy world where eventually also the very mechanism by which they do track and target you is going to be replaced at some stage by Google and Chrome. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. +CHAD: You have this idea. It's really challenging the status quo. You're working in open banking innovation at the time. What did you start to do then, to try to bring your idea to life? +GUILLAUME: So the first thing was actually my background is in sales and business development but within the fintech and open banking space. So I've worked with a lot of very smart people. And the first thing I really needed to do was quickly validate whether or not this is something. So a guy that we brought on...he's not so much a co-founder, but the other director of the business is a guy called Matt McBride, who's this global head of UX at a company I used to work for. +And that was really the first thing is to try and rapidly prototype what the experience would look like and ultimately go out to our target audience, which was Gen Z here in the UK, and ask them whether or not this is the sort of thing they'd engage with. And the responses were actually really very positive. "Hang on; you're going to pay me to watch ads that are relevant to me? No-brainer, please do." +And then, we were able to raise 100 grand, 150 grand, which enabled us to take that prototype and build it into something that, after a few obstacles with Apple in the App Store, we were able to get live. So that was really the first thing, I guess is, figuring out the way and the people that I needed to help me out to take this idea into something tangible and then tested it before I went much further with it. +I was very fortunate, or I am very fortunate, that my partner is a corporate lawyer; my wife, sorry, now; we've been married since we started. [laughs] And so, actually, the mechanism through which we were able to raise the really earliest funds meant that we didn't have to give very much of the business away at such an early stage, which I think was a key learning point that I certainly share with other founders is you don't have to go give away 25% of your business for a little bit of money just to get it off PowerPoint. There are other ways. +CHAD: So I think I remember what I told you when we met and talked. Do you remember what it was? +GUILLAUME: You shared lots of very valuable insights with me. +CHAD: My memory is that at the time, it was only advertisements in the app. And I think I said, "I get that people are going to want to be paid to look at these things." +GUILLAUME: Oh yes, right. +CHAD: "But if there's nothing else here, it's going to be really hard to bring people back to do that." And we had seen that in another client of ours that was paying people to browse. And what they'd do is they do it for a while, and they'd hit whatever monthly cap of return that they could get, an amount that they thought made sense. And then, they would switch back to their other browser because it was a better browsing experience. So they were only using it because they were getting paid. And as soon as that incentive went away, they would stop using it. +GUILLAUME: Yeah, so I remember that. And you were right. And I guess there are a few things that came about from that, so the first thing is that Apple agreed. So we couldn't get the app onto the App Store if it was just a feed of adverts that remunerated the user to watch them, incentivized the user. So we put quite a lot of additional features, I guess more traditional fintech features, open banking features within the application in order to give the user insights into their spending, week-on-week analysis, and categorization of spend. +And we also built this what we call the level up section where every week, you get refreshed pieces of content around, you know, very Gen Z-focused again, but what's the difference between a credit card and a loan? Is buy now, pay later a good idea? What's open banking? So we generate all this content, which they don't get paid to consume but is there, and they do. +But more importantly, I think what we realized is that actually what we've got...this is the difference, I guess, between the Attention Exchange and Zedosh being the app; it's the plumbing and the matching that is the real value here. It is the models we're building that understand people's behavior and propensity or intent to buy something based on the data they're sharing with us. +And so, actually, what we've built is a solution where you should be able to log in to any publisher that has the additional content, and experience, and value that you're speaking about there, places you ordinarily already browse and frequent. But if you want to, there's a separate tab where there are ads waiting for you that remunerate you, but you go into that tab. So we're trying to remove the interruption, you know, the pop-up even having to accept cookies from your user experience with the publisher moving into a separate, dedicated tab. +And the reason the consumer is still going to go click on that tab is because they know that there's some content that's relevant and pays them, but they're still able to enjoy all the other benefits that the publisher provides. So it's kind of weirdly trying to flip this premium subscription model where you pay not to have ads. Actually, you're the first recipient of the ad income, and you share that with the publisher. +CHAD: I think this is really cool, and yet I think it also rubs up against or hits up against something that is just so different than the status quo. The idea that companies would not interrupt you with advertising is probably so foreign [laughs] to people that I imagine you get reluctance to that. +GUILLAUME: The last two years have been a steeper learning curve for us and all the advertisers and agencies, and players we've been speaking to. But what I'm grateful for is the fact that what we term the ad-pocalypse is coming. And so I was just at an event called MAD//Fest last week, which is basically all the advertising industry got together in London, the UK advertising industry. And every single panel discussion talk was about the post-cookie era. +And all that most people are speaking about is how do we gather more data in other ways from the consumer in order to keep doing more of the same? And all of a sudden, when we're talking about the fact that our users give us their banking transactions, we see how much they earn and where they spend it and, therefore, can also attribute without the use of cookies, which is the holy grail of advertising. We started generating an awful lot of interest from really big players. +So I think you're right; the status quo is having the rug pulled from underneath them, right? Look at Meta's share price this year. I haven't checked it this week, but last time I checked, it was down 52%. And that's because iOS app tracking transparency is stopping the ability to track and monitor and, increasingly, ultimately, the ability for the user to remain more private. And they all are doing it. Why would they want to be less private in order to benefit Meta? In our platform, they're opting into their most intimate data being shared because they stand to be rewarded fairly for it. +So I completely agree; up to this point, "What? No way." This is how it works. And certainly, the thing that will probably remain true is to do more with less isn't of interest because agencies get paid a percentage of the budget. They don't want to do [laughs] the same with less budget. But my point remains that with iOS app tracking transparency...apparently, Android is going the same way, and Chrome is replacing third-party cookies. The status quo simply cannot continue. Something has to change. +And so I think with this identity solution often is what we're building. The consumer stands a chance of being the first in line to receive a reward for their attention. And I'm very pleased actually we've got some competition as well since we last spoke, which is new. But this concept of rewarding consumers for attention, I think, will just...how else are you going to get their time? They're not listening to you on TikTok. [laughs] +CHAD: I'm happy to hear that you're viewing competition as a positive thing. And I agree competition raises awareness that this is a thing and a potential, and most people will shop around or research it further. And that's a chance for them to discover you. +GUILLAUME: I hope so. This company has done a big advertising campaign all over. It's on TV, radio, and the underground in London. And the amount of people who've reached out to me... "Is this company doing what you're doing?" And ultimately, they're paying users in a way for their attention to advertising. But they don't use open banking, and they don't have the data that we have. +CHAD: That's an important distinction. One of the things that I've seen our clients worry about...and I saw it happen to one. Even though lots of people worry about it, I've only ever seen it happen one time, but it's still a risk, and that is when competitors come along. And unbeknownst to you, they dramatically over raise and therefore are just able to flood the market, saturate the attention, and build way bigger and faster at a loss than you are willing to do. +GUILLAUME: Yeah, or able to do. [laughs] +CHAD: Or able to do, right? Because they've raised 500 million [chuckles] or something like that. That's what happened with our client, who was in the group buying space at the same time as Groupon and LivingSocial. And so that's the only time I've ever seen it happen, but it's something that people are worried about. How are you...is that something on your mind? +GUILLAUME: It's interesting. So they've raised 15 million Series A, and they've been around since 2012. So they've been around a long time. And it almost feels like they... [laughs] I'm not saying they did, but it almost feels like they landed on my LinkedIn. And we're very anti-social media. The message is really strong on anti-social media. But ultimately, they built an app. +And so I think we've already matured past the point that in terms of our scaling and our ability to integrate with any platform, our strategy already goes beyond competing on a direct basis of an app that serves ads. In fact, if anything, at some stage, I'm hoping that they could plug into our engine and our pipes and add an extra layer of data and personalization to the adverts that they serve. +So ultimately, when they came, and it was during the Champions League final that they had their first big launch because one of the backers is a football player, my phone just went berserk. Because it was like, wait, what? And at first, I was a bit worried but ultimately, no. I only really, really see it as a positive at this stage. +But obviously, yes, they can advertise. They can speak to brands. They've got much more market presence. Everywhere you go on the underground, there are those posters. But we have a very clear, distinct proposition that is quite different. As I said, really, this pulling apart what Zedosh is and what the Attention Exchange is; the Attention Exchange is really potentially the plumbing, the rails for this post-cookie advertising model. +CHAD: So that being said, you are doing some fundraising now. That's right? +GUILLAUME: Yes. In fact, I don't think I've stopped fundraising [laughter] since this started. And certainly, that wasn't something I was anticipating despite the fact that...I mentioned I'm married to a corporate lawyer. She told me, "Your role as a CEO, as a founder, you're just going to be fundraising." I thought, yeah, well, I'll get some money in, and then we can focus on doing the stuff. But every time money comes in, most often you sort of have already spent it. It's allocated; it's gone. You need to look for the next lot. +But yes, we are fundraising. Currently, we're still focused majoritively on angels. We're looking to prove our scalability model with this existing raise, at which point I think we’ll be ready and looking for institutional funds. But we use something called EIS funding which is UK-specific but is so, so rewarding for UK taxpayers. Basically, they get 30% back off the tax amount of their tax return, which is a great incentive, and all the gains from the equity is free of capital gains tax as well. +So it almost becomes a no-brainer for people who have money that they're looking to invest in early-stage risky businesses. They're already really risking. The capital risk is under 50% of what they put in because there's also an insurance element; if the company goes bust that you've invested, there's something called loss relief. +CHAD: So it's really attractive to angel-level investors. +GUILLAUME: Correct. So you have to be a UK taxpayer as an individual to benefit from this specific relief. Of course, I mean, we have had some non-UK people still invest through the same sort of advanced subscription agreement. But yes, it's very attractive for UK taxpayers. +CHAD: And do you think...[laughs] you've already answered this question. But I guess when do you think you'll stop fundraising? +GUILLAUME: We're looking to change the way the internet works. [laughter] +CHAD: Right. +GUILLAUME: And so if we're mildly successful even redistributing the 100 billion of ad fraud which is currently being lost out there, we're entering a very cash-rich market looking for solutions at this moment in time. So if we're to raise some cash that enables us to put in place the plumbing and the pipes that we're looking to connect to, then actually, we should be relatively profitable relatively quickly, at which point, I guess we'd no longer need to fundraise. But at which point we'd probably say, "Well, actually, the U.S. is now ready for this. Let's go." +CHAD: [laughs] +GUILLAUME: I don't think we're particularly a cash-thirsty business. It's all built on AWS. +CHAD: And you're right. That's why I asked the question because if your model is working, if you're having the impact you want, there's a lot of money in advertising. And so you should get to the point where you're able to do that profitably. +GUILLAUME: Absolutely. +CHAD: And start being as big as Google, right? [laughs] +GUILLAUME: Yeah. I read a book called Life After Google. I don't know if I shared that with you the last time we met. But it's weird. It was written five or six years ago, but it's coming true. I think this whole premise of Web3, and this decentralization of data, and the ownership of data, the profiting of data at the individual level, is coming to the fore. And I can think of no better way to bridge your value and identity online than having it connected to your real-world assets, income, and spending behavior. +CHAD: I was wondering whether you are going to mention Web3. [laughs] +GUILLAUME: Huh. +CHAD: Because this decentralization of the advertising money directly to users is a very Web3 idea. +GUILLAUME: I agree. +CHAD: [laughs] So how much do you talk about Web3 in your pitch or when you're talking about it? It hasn't come up until now in this conversation, so maybe not so much. +GUILLAUME: It's a double-edged sword, I feel, because I think most people think Web3. They think crypto. +CHAD: Yes. +GUILLAUME: And we're paying cash in fiat, and although there's every possibility we could have a token-based solution, we're not looking at that because the core immutable value of your attention is linked in your spending behavior on earth and online, but through real transactions with real merchants. 99.999% of transactions, I imagine, aren't crypto yet and don't live on a blockchain, so until that point, I think we steer clear of it. +Whether we could have raised more money more quickly if we [laughs] had mentioned it more, I don't know. But for me, there are quite a few steps to go in our journey as I see it having matured from the app to the plumbing, the plumbing now going to more publishers, more publishers meaning more audience, more audience meaning more attention, more advertising. At which point, as I said, the U.S. will probably be there with open banking. There are a lot of things in Web 2.0 that could be resolved. And yeah, if we make it that far, I think we'll be in an awesome position to have an identity solution for Web3 or Web5. [laughs] +CHAD: Well, I wish you all the best in that journey. And I really appreciate you stopping by and sharing with us. +GUILLAUME: My pleasure. It's been real great and nice to hear from you again. And I hope our paths cross in the real world soon enough. +CHAD: Yeah. If folks want to get in touch or learn more or get in touch with you, where are all the different places that they can do that? +GUILLAUME: We have two websites, so zedosh.com is the consumer app, attentionexchange.co.uk is our other website. Otherwise, feel free to reach out to me on LinkedIn. And on Twitter, I'm @G_Zedosh. I'm not massive on Twitter. There are a lot of bots on that. +CHAD: [laughs] I guess I'm not that surprised. +So you can subscribe to the show, find links to everything that was just mentioned along with notes and a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. I'm also not very active these days. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Guillaume Kendall. + + + Guillaume Kendall is the Founder of Zedosh and Attention Exchange, which is working to build a safe place for advertisers, publishers, and consumers to all benefit from fair access to human attention.

+ +

Chad talks with Guillaume about open banking, changing up who the beneficiaries of consumer attention and data are, and giving companies opportunities to advertise without interrupting consumers with ads.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Guillaume Kendall, the Founder of Zedosh and the Attention Exchange, which is working to build a safe place for advertisers, publishers, and consumers to all benefit from fair access to human attention. Guillaume, thank you for joining me.

+ +

GUILLAUME: Thank you so much for having me. It's a real privilege.

+ +

CHAD: If I'm not mistaken, you and I first met in person for lunch one time in London when I was visiting London in; I think it was...I went back and looked at my calendar. It was March 10th, 2020, if I'm not mistaken, either that or it was that Friday of that week.

+ +

GUILLAUME: It must have been one of the last weeks pre-pandemic.

+ +

CHAD: It was. I literally woke up on Saturday morning for my flight to come back to the U.S. to the headlines that all flights from Europe were being shut down. [laughs] And I almost dropped my phone until I realized, oh, that's the headline, but the real detail is I can get back. It's all the rest of Europe, not the UK, yet. That was the following week. I made it home, and then the world changed.

+ +

GUILLAUME: I sure did, didn't it? [laughs] It's funny, isn't it? Because the two-year period in between seems to have flown by. It feels like just yesterday. I remember I think, even what I ate.

+ +

CHAD: [laughs] And at the time, you were working on a new application, and we were talking about that. But I want to fast forward a little bit to today. Tell me more about Attention Exchange, and then we're going to rewind a bit to how you've arrived.

+ +

GUILLAUME: So the Attention Exchange...by way of background, I come from the fintech space rather than adtech. And it really, ultimately, the Attention Exchange is a matching engine, using financial terms, that matches the right video content to the right consumer based on their spending data rather than their browsing data. So it's a matching engine.

+ +

And it looks at rules that ultimately we're able to derive, or actually, I better use the phrase, we can bridge the gap between attention and intention based on our audience's spending patterns. And the reason we can access those is because they give us explicit permission. We have something called open banking here in the UK. It's actually across most of Europe now. But it enables the consumer to own their data and share it outside the bank if they so wish to with other regulated third parties.

+ +

So we're such a regulated third party, and they share that data with us, as I said, to be matched with video content from brands that are relevant to their spending instead of their browsing. What it ultimately means is we're very well-positioned in this apparent post-cookie world that seems to be heading our way eventually because we don't rely on any other tracking technology to spy on our audience. They voluntarily give it to us.

+ +

And I guess the kicker which is...people are probably asking themselves, why would they do that? That's because they get paid. So we put cash directly into the bank account or one of the bank accounts they've connected to our platform in exchange for their immutably valuable attention to that content.

+ +

CHAD: So correct me if I'm wrong, but I feel like open banking has had a significant impact not only on the data sharing that you're describing but just on the banking ecosystem in general in the United Kingdom and now Europe.

+ +

GUILLAUME: So I think if you were to speak to the purveyors of open banking, it hasn't had as big an impact as they felt it would have had. I think we reached earlier this year only to fact-check this, but about 6 million people in the UK now utilize open banking in one form or another.

+ +

But I think what was very interesting is that the ecosystem that sprung up around it was mostly around changing the user experience for the end consumer to have a better handle on their financial health, which is a really important topic. And the reason that is is that before, it wasn't really in the bank's interests to tell you if you're about to hit your overdraft or go over your overdraft because they'd charge you an extra 20 pounds for an unplanned loan, and then you'd have to pay it. Your balances (This is going back a little. I'm showing my age. ) was always two or three days out of date, which was weird.

+ +

So open banking; the first thing that sprung up around it is we'll connect your bank accounts. We'll give you this holistic view of your mortgages, your credit, your debit, your net worth really across various assets. And we've moved progressively towards more of open finance rather than just open banking. You can connect via APIs a lot of your financial identity to these open banking providers.

+ +

But having said that, no one has looked at it in the way that we have, which is actually this is an advertising play, and it could be potentially a real change maker in the way that consumers benefit from this $400 billion industry which is advertising rather than all the fintech stuff that's been happening around open banking.

+ +

But yes, so it's not to be sniffed at, you know, several million people are using open banking. But most people, I don't even think, realize they're using open banking. They open the Revolut app, and it says, "Do you want to see your Monzo balance inside our app?" You say, "Well, yeah, okay, that means I don't have to open Monzo." And lo and behold, you share that data.

+ +

CHAD: Right. Yeah, that's a really good perspective. I think from my perspective; I was thinking it's sort of made it...there's a separation between the banking backends and the user experience, and I think that in part has given rise to these challenger banks and made it more possible for them to do that.

+ +

GUILLAUME: Yeah, that's a very fair point. I think, certainly, if nothing else, it certainly forced the incumbent players, those that have been around for a few hundred years, to really buckle up their ideas and think about how to react to this new threat. At first, they thought, geez, open banking is going to cause us all sorts of problems, but I think as it's gone full circle. You find that, actually, most people are looking for that user experience, and the banks have been forced to provide it within their existing ecosystem.

+ +

So now, most banking apps provide really super UI or UX, meaning that you don't have to go use third-party tools to get such a lens. And in fact, the most interesting one I've seen of late, which I think is definitely worth a mention, is a company called Cogo; and Cogo used open banking to carbon score your spending and let you offset it. So if you spent four pounds at McDonald's, it would guess that that's X kilos of carbon and give you several options to offset it.

+ +

And actually, in the end, NatWest formed a partnership with them. This is a classic use case where actually, now the carbons offseter is available within that NatWest app, and you don't really have any idea it's Cogo. That's what you're seeing is ironically, those who have had success in innovative, exciting use cases have been pulled back into the ecosystem being offered because they still want the scale overnight. They had access to 8 million NatWest customers or whatever the number is.

+ +

So, yes, I think; certainly, all banking apps have had to, even the banks themselves, have had to reorganize and rethink how they deliver technology to retail consumers who probably had had very little churn in the past because the options were very limited.

+ +

CHAD: That's great. So tell me about the genesis for this idea and realizing that you could use open banking to view people's financial information and to develop a profile that could be used to opt into advertising. Where's the genesis of that idea for you?

+ +

GUILLAUME: Sure. So actually, several threads came together very neatly in quite a tight timescale, the first of which is I spent a lot of money, relatively speaking, on a company called Patch Plants. And Patch Plants deliver plants to your house, [laughter] and they have quite a nice way to go about it. All the plants have got human names, and they come with little booklets about how to look after them.

+ +

And I felt very positive about the relationship I felt I had with Patch Plants until for the three, maybe four months following that purchase, there wasn't a website, or a social feed that I was on that didn't have Patch Plants all over it. And I really took note of my sentiment towards them [laughs] where I thought, go away, Patch Plants. I'm a customer. Why don't you know better? With the amount of data that we provide to the web, you just assume...and maybe this is where it all starts to click into place that actually, it's not that smart.

+ +

CHAD: The interesting thing is I think it is possible for companies to on target you once they decide to do it, but it seems like nobody does that. [laughs] And it's like, I've just bought a stove. Why am I seeing stoves all over the place? [laughs] I'm not going to buy another one.

+ +

GUILLAUME: Yeah, again, I think it comes from the underlying infrastructure, which is basically this concept of cookies, which we accept on every single website before we can do anything with it. And you've probably got a number of unchecked-out stoves across the web. And it's not locking on to the fact you've got one checked-out stove.

+ +

But of course, we're connected to the bank account. And so when we see that transaction, we see the counterparties. We know for a fact that that person has made that transaction with that vendor, and therefore, you probably need to change the message. And that goes from daily purchases right through to the massive, heavy items we can see when people started a car leasing agreement.

+ +

Well, if you want to get them to think about considering your brand of vehicle in two or three years or three or four years, there's probably a journey that you should take that person on. But then again, once they've made the purchase, don't keep hassling them. So that's the first thing. If you saw my bank account...so I worked with open banking innovation [laughs]. I guess that's pretty important.

+ +

CHAD: [laughs]

+ +

GUILLAUME: So I was acutely aware of how the data could be shared and analyzed, so that's the first point. And then, pretty much at the same time, Netflix brought out this documentary, The Social Dilemma, really putting across that these social media applications were basically designed, maybe it's not a surprise, but pretty much as gambling apps. They're exceptionally addictive. And the reason they're addictive is because the longer you spend on them, the more advertising they can slide into; now, I think one in every four posts.

+ +

And now that we've moved on to short-form video content, there's infinite scroll. We're all on these apps for hours a day. But the only way they generate revenues is through advertising, and the only way they get advertising is by you spending more time. And it sort of didn't sit too well with me, especially after we had the Euro Championship in football or soccer here. And there was a ton of racist abuse that went out to players across social media. Lots of brands and advertisers started pulling away from it for a very short period of time to express their protest.

+ +

But I realized then that, actually, there is no alternative. If you want to attract attention, you have to fund social media or Google, and that's kind of it. Those are your options as a brand or an advertiser. And the former being social media is really not a very healthy place to spend time. Sure, some good comes out of it. But I would argue that the bad that comes out of it far outweighs any of the good that's come from social media, certainly in the last five years or so, I believe. It's at the center of some major divisions in our communities. But it's all funded through advertising revenue.

+ +

So that was the second point is that there really is no alternative. And why should Mark Zuckerberg be the beneficiary of my attention, my data, my value whilst putting absolutely no effort in changing or being an arbiter of the content? They're keeping their hands up saying, hey, we're not a publisher. If that content is there, it's there. And it becomes a very complicated argument very quickly around free speech and all of this sort of stuff. But ultimately, there's a ton of really nasty stuff.

+ +

And then we had a family friend, specifically, who really put herself in a lot of danger, a young girl. And that was a very real impact on human life close to us that was all driven from what she was able to access with alarming ease via Instagram. So those sorts of threads all came together. And then the more sort of...it's one of those things, right? Once you see a yellow car, you're looking out for a yellow car. You keep seeing them. But I don't think I was proactively looking out for it too much.

+ +

But it seemed that every day almost, there was a new-new story in the front pages of the papers where Facebook was in some sort of trouble, and that obviously materialized last year with the Facebook leaks. And everything we've been just discussing now they've known about. They know about it. They're choosing not to make a difference.

+ +

So we had a really powerful motivation to try and bring about a different mechanism for this $400 billion industry to operate. And rather than exploit our data, exploit our mental well-being, exploit our communities and everything else in order to drive advertising revenue, maybe the advertiser could have a more direct relationship, a fair and more transparent relationship with the consumer with whom they want a dialogue.

+ +

And I think it's been the biggest learning curve for us is that brands and advertisers feel weird about paying consumers to pay attention. But we're saying we think it is weirder that you pay Google and Facebook to track these people all over the web and interrupt them everywhere they don't want to be spoken to. Why not just pay them to have a fair, transparent dialogue? I know you have money. I know you spend it with my competitors who are in my market. I want your attention, and this is what I have to tell you. There we go. So that was the sort of the kernel, the genesis.

+ +

CHAD: I can totally see why advertisers are...scared is not the right word. Just, you know, it's just they've never had a relationship where they're paying the consumer directly for any kind of advertising that they do [chuckles] whether it be TV historically. There's always an intermediary. And the idea of paying people directly is not only different, but in some ways, I can imagine people view it as crude. Like, it's one thing if it's going through an intermediary and you're paying them, and advertising is being run, but it's another to just pay someone to pay attention to you.

+ +

GUILLAUME: Yeah, but I think this is the point about the open banking. I completely agree with you; if you're paying somebody based on their cookies or any of the other data, the first-party data or third-party data, that's abstracted several layers from that pair of eyeballs that you know has a tendency to buy X on Y time horizon. That's never been possible before.

+ +

And so through your television, it's scale. You're paying the broadcaster because they've got 3 million people watching Coronation Street on, I don't know, whatever. But it's always based on these tiny, tiny fractions of engagement, and that's always been the way it is. So you need the intermediary for scale.

+ +

But I think what I'm hoping, what I've literally bet my house on [laughter], that's one thing that's going to change. I sold my house since we started to do this. All those marketplaces are completely saturated, and they are not getting less busy; they're getting more busy. And so okay, TikToks appeared, but the medium through which video content is provided to the consumer, you're lucky to get a quarter of a second or half a second with that person.

+ +

And so you're right, but what is now the alternative to actually getting a minute, a minute and a half, two minutes with somebody where they're not skipping; they're not going past? You know they're a real person. You know they're human. All of our consumers have to have a bank account. They have to have transactions, and they have to have an income in order to be valuable and receive any adverts into their feed. So it's just never been possible before.

+ +

The scale play, the intermediary, was always sort of, I think, accepted, and it still is today. There's going to be a bunch of fraud. I think there's like 15 cents in every dollar spent online digitally for advertising is lost. I think it's a $100 billion problem by next year. So I guess the point I'm making is the intermediaries historically and to today have existed because you need to reach millions of eyeballs in order to get a very low interaction rate.

+ +

With our model, we're able to target thousands of people and achieve a 19.6% average click-through rate even after a minute and a half worth of content because they're engaged and you're not interrupting them. So we think it's a relatively elegant model for what is a saturated, noisy world where eventually also the very mechanism by which they do track and target you is going to be replaced at some stage by Google and Chrome.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: You have this idea. It's really challenging the status quo. You're working in open banking innovation at the time. What did you start to do then, to try to bring your idea to life?

+ +

GUILLAUME: So the first thing was actually my background is in sales and business development but within the fintech and open banking space. So I've worked with a lot of very smart people. And the first thing I really needed to do was quickly validate whether or not this is something. So a guy that we brought on...he's not so much a co-founder, but the other director of the business is a guy called Matt McBride, who's this global head of UX at a company I used to work for.

+ +

And that was really the first thing is to try and rapidly prototype what the experience would look like and ultimately go out to our target audience, which was Gen Z here in the UK, and ask them whether or not this is the sort of thing they'd engage with. And the responses were actually really very positive. "Hang on; you're going to pay me to watch ads that are relevant to me? No-brainer, please do."

+ +

And then, we were able to raise 100 grand, 150 grand, which enabled us to take that prototype and build it into something that, after a few obstacles with Apple in the App Store, we were able to get live. So that was really the first thing, I guess is, figuring out the way and the people that I needed to help me out to take this idea into something tangible and then tested it before I went much further with it.

+ +

I was very fortunate, or I am very fortunate, that my partner is a corporate lawyer; my wife, sorry, now; we've been married since we started. [laughs] And so, actually, the mechanism through which we were able to raise the really earliest funds meant that we didn't have to give very much of the business away at such an early stage, which I think was a key learning point that I certainly share with other founders is you don't have to go give away 25% of your business for a little bit of money just to get it off PowerPoint. There are other ways.

+ +

CHAD: So I think I remember what I told you when we met and talked. Do you remember what it was?

+ +

GUILLAUME: You shared lots of very valuable insights with me.

+ +

CHAD: My memory is that at the time, it was only advertisements in the app. And I think I said, "I get that people are going to want to be paid to look at these things."

+ +

GUILLAUME: Oh yes, right.

+ +

CHAD: "But if there's nothing else here, it's going to be really hard to bring people back to do that." And we had seen that in another client of ours that was paying people to browse. And what they'd do is they do it for a while, and they'd hit whatever monthly cap of return that they could get, an amount that they thought made sense. And then, they would switch back to their other browser because it was a better browsing experience. So they were only using it because they were getting paid. And as soon as that incentive went away, they would stop using it.

+ +

GUILLAUME: Yeah, so I remember that. And you were right. And I guess there are a few things that came about from that, so the first thing is that Apple agreed. So we couldn't get the app onto the App Store if it was just a feed of adverts that remunerated the user to watch them, incentivized the user. So we put quite a lot of additional features, I guess more traditional fintech features, open banking features within the application in order to give the user insights into their spending, week-on-week analysis, and categorization of spend.

+ +

And we also built this what we call the level up section where every week, you get refreshed pieces of content around, you know, very Gen Z-focused again, but what's the difference between a credit card and a loan? Is buy now, pay later a good idea? What's open banking? So we generate all this content, which they don't get paid to consume but is there, and they do.

+ +

But more importantly, I think what we realized is that actually what we've got...this is the difference, I guess, between the Attention Exchange and Zedosh being the app; it's the plumbing and the matching that is the real value here. It is the models we're building that understand people's behavior and propensity or intent to buy something based on the data they're sharing with us.

+ +

And so, actually, what we've built is a solution where you should be able to log in to any publisher that has the additional content, and experience, and value that you're speaking about there, places you ordinarily already browse and frequent. But if you want to, there's a separate tab where there are ads waiting for you that remunerate you, but you go into that tab. So we're trying to remove the interruption, you know, the pop-up even having to accept cookies from your user experience with the publisher moving into a separate, dedicated tab.

+ +

And the reason the consumer is still going to go click on that tab is because they know that there's some content that's relevant and pays them, but they're still able to enjoy all the other benefits that the publisher provides. So it's kind of weirdly trying to flip this premium subscription model where you pay not to have ads. Actually, you're the first recipient of the ad income, and you share that with the publisher.

+ +

CHAD: I think this is really cool, and yet I think it also rubs up against or hits up against something that is just so different than the status quo. The idea that companies would not interrupt you with advertising is probably so foreign [laughs] to people that I imagine you get reluctance to that.

+ +

GUILLAUME: The last two years have been a steeper learning curve for us and all the advertisers and agencies, and players we've been speaking to. But what I'm grateful for is the fact that what we term the ad-pocalypse is coming. And so I was just at an event called MAD//Fest last week, which is basically all the advertising industry got together in London, the UK advertising industry. And every single panel discussion talk was about the post-cookie era.

+ +

And all that most people are speaking about is how do we gather more data in other ways from the consumer in order to keep doing more of the same? And all of a sudden, when we're talking about the fact that our users give us their banking transactions, we see how much they earn and where they spend it and, therefore, can also attribute without the use of cookies, which is the holy grail of advertising. We started generating an awful lot of interest from really big players.

+ +

So I think you're right; the status quo is having the rug pulled from underneath them, right? Look at Meta's share price this year. I haven't checked it this week, but last time I checked, it was down 52%. And that's because iOS app tracking transparency is stopping the ability to track and monitor and, increasingly, ultimately, the ability for the user to remain more private. And they all are doing it. Why would they want to be less private in order to benefit Meta? In our platform, they're opting into their most intimate data being shared because they stand to be rewarded fairly for it.

+ +

So I completely agree; up to this point, "What? No way." This is how it works. And certainly, the thing that will probably remain true is to do more with less isn't of interest because agencies get paid a percentage of the budget. They don't want to do [laughs] the same with less budget. But my point remains that with iOS app tracking transparency...apparently, Android is going the same way, and Chrome is replacing third-party cookies. The status quo simply cannot continue. Something has to change.

+ +

And so I think with this identity solution often is what we're building. The consumer stands a chance of being the first in line to receive a reward for their attention. And I'm very pleased actually we've got some competition as well since we last spoke, which is new. But this concept of rewarding consumers for attention, I think, will just...how else are you going to get their time? They're not listening to you on TikTok. [laughs]

+ +

CHAD: I'm happy to hear that you're viewing competition as a positive thing. And I agree competition raises awareness that this is a thing and a potential, and most people will shop around or research it further. And that's a chance for them to discover you.

+ +

GUILLAUME: I hope so. This company has done a big advertising campaign all over. It's on TV, radio, and the underground in London. And the amount of people who've reached out to me... "Is this company doing what you're doing?" And ultimately, they're paying users in a way for their attention to advertising. But they don't use open banking, and they don't have the data that we have.

+ +

CHAD: That's an important distinction. One of the things that I've seen our clients worry about...and I saw it happen to one. Even though lots of people worry about it, I've only ever seen it happen one time, but it's still a risk, and that is when competitors come along. And unbeknownst to you, they dramatically over raise and therefore are just able to flood the market, saturate the attention, and build way bigger and faster at a loss than you are willing to do.

+ +

GUILLAUME: Yeah, or able to do. [laughs]

+ +

CHAD: Or able to do, right? Because they've raised 500 million [chuckles] or something like that. That's what happened with our client, who was in the group buying space at the same time as Groupon and LivingSocial. And so that's the only time I've ever seen it happen, but it's something that people are worried about. How are you...is that something on your mind?

+ +

GUILLAUME: It's interesting. So they've raised 15 million Series A, and they've been around since 2012. So they've been around a long time. And it almost feels like they... [laughs] I'm not saying they did, but it almost feels like they landed on my LinkedIn. And we're very anti-social media. The message is really strong on anti-social media. But ultimately, they built an app.

+ +

And so I think we've already matured past the point that in terms of our scaling and our ability to integrate with any platform, our strategy already goes beyond competing on a direct basis of an app that serves ads. In fact, if anything, at some stage, I'm hoping that they could plug into our engine and our pipes and add an extra layer of data and personalization to the adverts that they serve.

+ +

So ultimately, when they came, and it was during the Champions League final that they had their first big launch because one of the backers is a football player, my phone just went berserk. Because it was like, wait, what? And at first, I was a bit worried but ultimately, no. I only really, really see it as a positive at this stage.

+ +

But obviously, yes, they can advertise. They can speak to brands. They've got much more market presence. Everywhere you go on the underground, there are those posters. But we have a very clear, distinct proposition that is quite different. As I said, really, this pulling apart what Zedosh is and what the Attention Exchange is; the Attention Exchange is really potentially the plumbing, the rails for this post-cookie advertising model.

+ +

CHAD: So that being said, you are doing some fundraising now. That's right?

+ +

GUILLAUME: Yes. In fact, I don't think I've stopped fundraising [laughter] since this started. And certainly, that wasn't something I was anticipating despite the fact that...I mentioned I'm married to a corporate lawyer. She told me, "Your role as a CEO, as a founder, you're just going to be fundraising." I thought, yeah, well, I'll get some money in, and then we can focus on doing the stuff. But every time money comes in, most often you sort of have already spent it. It's allocated; it's gone. You need to look for the next lot.

+ +

But yes, we are fundraising. Currently, we're still focused majoritively on angels. We're looking to prove our scalability model with this existing raise, at which point I think we’ll be ready and looking for institutional funds. But we use something called EIS funding which is UK-specific but is so, so rewarding for UK taxpayers. Basically, they get 30% back off the tax amount of their tax return, which is a great incentive, and all the gains from the equity is free of capital gains tax as well.

+ +

So it almost becomes a no-brainer for people who have money that they're looking to invest in early-stage risky businesses. They're already really risking. The capital risk is under 50% of what they put in because there's also an insurance element; if the company goes bust that you've invested, there's something called loss relief.

+ +

CHAD: So it's really attractive to angel-level investors.

+ +

GUILLAUME: Correct. So you have to be a UK taxpayer as an individual to benefit from this specific relief. Of course, I mean, we have had some non-UK people still invest through the same sort of advanced subscription agreement. But yes, it's very attractive for UK taxpayers.

+ +

CHAD: And do you think...[laughs] you've already answered this question. But I guess when do you think you'll stop fundraising?

+ +

GUILLAUME: We're looking to change the way the internet works. [laughter]

+ +

CHAD: Right.

+ +

GUILLAUME: And so if we're mildly successful even redistributing the 100 billion of ad fraud which is currently being lost out there, we're entering a very cash-rich market looking for solutions at this moment in time. So if we're to raise some cash that enables us to put in place the plumbing and the pipes that we're looking to connect to, then actually, we should be relatively profitable relatively quickly, at which point, I guess we'd no longer need to fundraise. But at which point we'd probably say, "Well, actually, the U.S. is now ready for this. Let's go."

+ +

CHAD: [laughs]

+ +

GUILLAUME: I don't think we're particularly a cash-thirsty business. It's all built on AWS.

+ +

CHAD: And you're right. That's why I asked the question because if your model is working, if you're having the impact you want, there's a lot of money in advertising. And so you should get to the point where you're able to do that profitably.

+ +

GUILLAUME: Absolutely.

+ +

CHAD: And start being as big as Google, right? [laughs]

+ +

GUILLAUME: Yeah. I read a book called Life After Google. I don't know if I shared that with you the last time we met. But it's weird. It was written five or six years ago, but it's coming true. I think this whole premise of Web3, and this decentralization of data, and the ownership of data, the profiting of data at the individual level, is coming to the fore. And I can think of no better way to bridge your value and identity online than having it connected to your real-world assets, income, and spending behavior.

+ +

CHAD: I was wondering whether you are going to mention Web3. [laughs]

+ +

GUILLAUME: Huh.

+ +

CHAD: Because this decentralization of the advertising money directly to users is a very Web3 idea.

+ +

GUILLAUME: I agree.

+ +

CHAD: [laughs] So how much do you talk about Web3 in your pitch or when you're talking about it? It hasn't come up until now in this conversation, so maybe not so much.

+ +

GUILLAUME: It's a double-edged sword, I feel, because I think most people think Web3. They think crypto.

+ +

CHAD: Yes.

+ +

GUILLAUME: And we're paying cash in fiat, and although there's every possibility we could have a token-based solution, we're not looking at that because the core immutable value of your attention is linked in your spending behavior on earth and online, but through real transactions with real merchants. 99.999% of transactions, I imagine, aren't crypto yet and don't live on a blockchain, so until that point, I think we steer clear of it.

+ +

Whether we could have raised more money more quickly if we [laughs] had mentioned it more, I don't know. But for me, there are quite a few steps to go in our journey as I see it having matured from the app to the plumbing, the plumbing now going to more publishers, more publishers meaning more audience, more audience meaning more attention, more advertising. At which point, as I said, the U.S. will probably be there with open banking. There are a lot of things in Web 2.0 that could be resolved. And yeah, if we make it that far, I think we'll be in an awesome position to have an identity solution for Web3 or Web5. [laughs]

+ +

CHAD: Well, I wish you all the best in that journey. And I really appreciate you stopping by and sharing with us.

+ +

GUILLAUME: My pleasure. It's been real great and nice to hear from you again. And I hope our paths cross in the real world soon enough.

+ +

CHAD: Yeah. If folks want to get in touch or learn more or get in touch with you, where are all the different places that they can do that?

+ +

GUILLAUME: We have two websites, so zedosh.com is the consumer app, attentionexchange.co.uk is our other website. Otherwise, feel free to reach out to me on LinkedIn. And on Twitter, I'm @G_Zedosh. I'm not massive on Twitter. There are a lot of bots on that.

+ +

CHAD: [laughs] I guess I'm not that surprised.

+ +

So you can subscribe to the show, find links to everything that was just mentioned along with notes and a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. I'm also not very active these days.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Guillaume Kendall.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Guillaume Kendall is the Founder of Zedosh and Attention Exchange, which is working to build a safe place for advertisers, publishers, and consumers to all benefit from fair access to human attention.

+ +

Chad talks with Guillaume about open banking, changing up who the beneficiaries of consumer attention and data are, and giving companies opportunities to advertise without interrupting consumers with ads.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Guillaume Kendall, the Founder of Zedosh and the Attention Exchange, which is working to build a safe place for advertisers, publishers, and consumers to all benefit from fair access to human attention. Guillaume, thank you for joining me.

+ +

GUILLAUME: Thank you so much for having me. It's a real privilege.

+ +

CHAD: If I'm not mistaken, you and I first met in person for lunch one time in London when I was visiting London in; I think it was...I went back and looked at my calendar. It was March 10th, 2020, if I'm not mistaken, either that or it was that Friday of that week.

+ +

GUILLAUME: It must have been one of the last weeks pre-pandemic.

+ +

CHAD: It was. I literally woke up on Saturday morning for my flight to come back to the U.S. to the headlines that all flights from Europe were being shut down. [laughs] And I almost dropped my phone until I realized, oh, that's the headline, but the real detail is I can get back. It's all the rest of Europe, not the UK, yet. That was the following week. I made it home, and then the world changed.

+ +

GUILLAUME: I sure did, didn't it? [laughs] It's funny, isn't it? Because the two-year period in between seems to have flown by. It feels like just yesterday. I remember I think, even what I ate.

+ +

CHAD: [laughs] And at the time, you were working on a new application, and we were talking about that. But I want to fast forward a little bit to today. Tell me more about Attention Exchange, and then we're going to rewind a bit to how you've arrived.

+ +

GUILLAUME: So the Attention Exchange...by way of background, I come from the fintech space rather than adtech. And it really, ultimately, the Attention Exchange is a matching engine, using financial terms, that matches the right video content to the right consumer based on their spending data rather than their browsing data. So it's a matching engine.

+ +

And it looks at rules that ultimately we're able to derive, or actually, I better use the phrase, we can bridge the gap between attention and intention based on our audience's spending patterns. And the reason we can access those is because they give us explicit permission. We have something called open banking here in the UK. It's actually across most of Europe now. But it enables the consumer to own their data and share it outside the bank if they so wish to with other regulated third parties.

+ +

So we're such a regulated third party, and they share that data with us, as I said, to be matched with video content from brands that are relevant to their spending instead of their browsing. What it ultimately means is we're very well-positioned in this apparent post-cookie world that seems to be heading our way eventually because we don't rely on any other tracking technology to spy on our audience. They voluntarily give it to us.

+ +

And I guess the kicker which is...people are probably asking themselves, why would they do that? That's because they get paid. So we put cash directly into the bank account or one of the bank accounts they've connected to our platform in exchange for their immutably valuable attention to that content.

+ +

CHAD: So correct me if I'm wrong, but I feel like open banking has had a significant impact not only on the data sharing that you're describing but just on the banking ecosystem in general in the United Kingdom and now Europe.

+ +

GUILLAUME: So I think if you were to speak to the purveyors of open banking, it hasn't had as big an impact as they felt it would have had. I think we reached earlier this year only to fact-check this, but about 6 million people in the UK now utilize open banking in one form or another.

+ +

But I think what was very interesting is that the ecosystem that sprung up around it was mostly around changing the user experience for the end consumer to have a better handle on their financial health, which is a really important topic. And the reason that is is that before, it wasn't really in the bank's interests to tell you if you're about to hit your overdraft or go over your overdraft because they'd charge you an extra 20 pounds for an unplanned loan, and then you'd have to pay it. Your balances (This is going back a little. I'm showing my age. ) was always two or three days out of date, which was weird.

+ +

So open banking; the first thing that sprung up around it is we'll connect your bank accounts. We'll give you this holistic view of your mortgages, your credit, your debit, your net worth really across various assets. And we've moved progressively towards more of open finance rather than just open banking. You can connect via APIs a lot of your financial identity to these open banking providers.

+ +

But having said that, no one has looked at it in the way that we have, which is actually this is an advertising play, and it could be potentially a real change maker in the way that consumers benefit from this $400 billion industry which is advertising rather than all the fintech stuff that's been happening around open banking.

+ +

But yes, so it's not to be sniffed at, you know, several million people are using open banking. But most people, I don't even think, realize they're using open banking. They open the Revolut app, and it says, "Do you want to see your Monzo balance inside our app?" You say, "Well, yeah, okay, that means I don't have to open Monzo." And lo and behold, you share that data.

+ +

CHAD: Right. Yeah, that's a really good perspective. I think from my perspective; I was thinking it's sort of made it...there's a separation between the banking backends and the user experience, and I think that in part has given rise to these challenger banks and made it more possible for them to do that.

+ +

GUILLAUME: Yeah, that's a very fair point. I think, certainly, if nothing else, it certainly forced the incumbent players, those that have been around for a few hundred years, to really buckle up their ideas and think about how to react to this new threat. At first, they thought, geez, open banking is going to cause us all sorts of problems, but I think as it's gone full circle. You find that, actually, most people are looking for that user experience, and the banks have been forced to provide it within their existing ecosystem.

+ +

So now, most banking apps provide really super UI or UX, meaning that you don't have to go use third-party tools to get such a lens. And in fact, the most interesting one I've seen of late, which I think is definitely worth a mention, is a company called Cogo; and Cogo used open banking to carbon score your spending and let you offset it. So if you spent four pounds at McDonald's, it would guess that that's X kilos of carbon and give you several options to offset it.

+ +

And actually, in the end, NatWest formed a partnership with them. This is a classic use case where actually, now the carbons offseter is available within that NatWest app, and you don't really have any idea it's Cogo. That's what you're seeing is ironically, those who have had success in innovative, exciting use cases have been pulled back into the ecosystem being offered because they still want the scale overnight. They had access to 8 million NatWest customers or whatever the number is.

+ +

So, yes, I think; certainly, all banking apps have had to, even the banks themselves, have had to reorganize and rethink how they deliver technology to retail consumers who probably had had very little churn in the past because the options were very limited.

+ +

CHAD: That's great. So tell me about the genesis for this idea and realizing that you could use open banking to view people's financial information and to develop a profile that could be used to opt into advertising. Where's the genesis of that idea for you?

+ +

GUILLAUME: Sure. So actually, several threads came together very neatly in quite a tight timescale, the first of which is I spent a lot of money, relatively speaking, on a company called Patch Plants. And Patch Plants deliver plants to your house, [laughter] and they have quite a nice way to go about it. All the plants have got human names, and they come with little booklets about how to look after them.

+ +

And I felt very positive about the relationship I felt I had with Patch Plants until for the three, maybe four months following that purchase, there wasn't a website, or a social feed that I was on that didn't have Patch Plants all over it. And I really took note of my sentiment towards them [laughs] where I thought, go away, Patch Plants. I'm a customer. Why don't you know better? With the amount of data that we provide to the web, you just assume...and maybe this is where it all starts to click into place that actually, it's not that smart.

+ +

CHAD: The interesting thing is I think it is possible for companies to on target you once they decide to do it, but it seems like nobody does that. [laughs] And it's like, I've just bought a stove. Why am I seeing stoves all over the place? [laughs] I'm not going to buy another one.

+ +

GUILLAUME: Yeah, again, I think it comes from the underlying infrastructure, which is basically this concept of cookies, which we accept on every single website before we can do anything with it. And you've probably got a number of unchecked-out stoves across the web. And it's not locking on to the fact you've got one checked-out stove.

+ +

But of course, we're connected to the bank account. And so when we see that transaction, we see the counterparties. We know for a fact that that person has made that transaction with that vendor, and therefore, you probably need to change the message. And that goes from daily purchases right through to the massive, heavy items we can see when people started a car leasing agreement.

+ +

Well, if you want to get them to think about considering your brand of vehicle in two or three years or three or four years, there's probably a journey that you should take that person on. But then again, once they've made the purchase, don't keep hassling them. So that's the first thing. If you saw my bank account...so I worked with open banking innovation [laughs]. I guess that's pretty important.

+ +

CHAD: [laughs]

+ +

GUILLAUME: So I was acutely aware of how the data could be shared and analyzed, so that's the first point. And then, pretty much at the same time, Netflix brought out this documentary, The Social Dilemma, really putting across that these social media applications were basically designed, maybe it's not a surprise, but pretty much as gambling apps. They're exceptionally addictive. And the reason they're addictive is because the longer you spend on them, the more advertising they can slide into; now, I think one in every four posts.

+ +

And now that we've moved on to short-form video content, there's infinite scroll. We're all on these apps for hours a day. But the only way they generate revenues is through advertising, and the only way they get advertising is by you spending more time. And it sort of didn't sit too well with me, especially after we had the Euro Championship in football or soccer here. And there was a ton of racist abuse that went out to players across social media. Lots of brands and advertisers started pulling away from it for a very short period of time to express their protest.

+ +

But I realized then that, actually, there is no alternative. If you want to attract attention, you have to fund social media or Google, and that's kind of it. Those are your options as a brand or an advertiser. And the former being social media is really not a very healthy place to spend time. Sure, some good comes out of it. But I would argue that the bad that comes out of it far outweighs any of the good that's come from social media, certainly in the last five years or so, I believe. It's at the center of some major divisions in our communities. But it's all funded through advertising revenue.

+ +

So that was the second point is that there really is no alternative. And why should Mark Zuckerberg be the beneficiary of my attention, my data, my value whilst putting absolutely no effort in changing or being an arbiter of the content? They're keeping their hands up saying, hey, we're not a publisher. If that content is there, it's there. And it becomes a very complicated argument very quickly around free speech and all of this sort of stuff. But ultimately, there's a ton of really nasty stuff.

+ +

And then we had a family friend, specifically, who really put herself in a lot of danger, a young girl. And that was a very real impact on human life close to us that was all driven from what she was able to access with alarming ease via Instagram. So those sorts of threads all came together. And then the more sort of...it's one of those things, right? Once you see a yellow car, you're looking out for a yellow car. You keep seeing them. But I don't think I was proactively looking out for it too much.

+ +

But it seemed that every day almost, there was a new-new story in the front pages of the papers where Facebook was in some sort of trouble, and that obviously materialized last year with the Facebook leaks. And everything we've been just discussing now they've known about. They know about it. They're choosing not to make a difference.

+ +

So we had a really powerful motivation to try and bring about a different mechanism for this $400 billion industry to operate. And rather than exploit our data, exploit our mental well-being, exploit our communities and everything else in order to drive advertising revenue, maybe the advertiser could have a more direct relationship, a fair and more transparent relationship with the consumer with whom they want a dialogue.

+ +

And I think it's been the biggest learning curve for us is that brands and advertisers feel weird about paying consumers to pay attention. But we're saying we think it is weirder that you pay Google and Facebook to track these people all over the web and interrupt them everywhere they don't want to be spoken to. Why not just pay them to have a fair, transparent dialogue? I know you have money. I know you spend it with my competitors who are in my market. I want your attention, and this is what I have to tell you. There we go. So that was the sort of the kernel, the genesis.

+ +

CHAD: I can totally see why advertisers are...scared is not the right word. Just, you know, it's just they've never had a relationship where they're paying the consumer directly for any kind of advertising that they do [chuckles] whether it be TV historically. There's always an intermediary. And the idea of paying people directly is not only different, but in some ways, I can imagine people view it as crude. Like, it's one thing if it's going through an intermediary and you're paying them, and advertising is being run, but it's another to just pay someone to pay attention to you.

+ +

GUILLAUME: Yeah, but I think this is the point about the open banking. I completely agree with you; if you're paying somebody based on their cookies or any of the other data, the first-party data or third-party data, that's abstracted several layers from that pair of eyeballs that you know has a tendency to buy X on Y time horizon. That's never been possible before.

+ +

And so through your television, it's scale. You're paying the broadcaster because they've got 3 million people watching Coronation Street on, I don't know, whatever. But it's always based on these tiny, tiny fractions of engagement, and that's always been the way it is. So you need the intermediary for scale.

+ +

But I think what I'm hoping, what I've literally bet my house on [laughter], that's one thing that's going to change. I sold my house since we started to do this. All those marketplaces are completely saturated, and they are not getting less busy; they're getting more busy. And so okay, TikToks appeared, but the medium through which video content is provided to the consumer, you're lucky to get a quarter of a second or half a second with that person.

+ +

And so you're right, but what is now the alternative to actually getting a minute, a minute and a half, two minutes with somebody where they're not skipping; they're not going past? You know they're a real person. You know they're human. All of our consumers have to have a bank account. They have to have transactions, and they have to have an income in order to be valuable and receive any adverts into their feed. So it's just never been possible before.

+ +

The scale play, the intermediary, was always sort of, I think, accepted, and it still is today. There's going to be a bunch of fraud. I think there's like 15 cents in every dollar spent online digitally for advertising is lost. I think it's a $100 billion problem by next year. So I guess the point I'm making is the intermediaries historically and to today have existed because you need to reach millions of eyeballs in order to get a very low interaction rate.

+ +

With our model, we're able to target thousands of people and achieve a 19.6% average click-through rate even after a minute and a half worth of content because they're engaged and you're not interrupting them. So we think it's a relatively elegant model for what is a saturated, noisy world where eventually also the very mechanism by which they do track and target you is going to be replaced at some stage by Google and Chrome.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint.

+ +

CHAD: You have this idea. It's really challenging the status quo. You're working in open banking innovation at the time. What did you start to do then, to try to bring your idea to life?

+ +

GUILLAUME: So the first thing was actually my background is in sales and business development but within the fintech and open banking space. So I've worked with a lot of very smart people. And the first thing I really needed to do was quickly validate whether or not this is something. So a guy that we brought on...he's not so much a co-founder, but the other director of the business is a guy called Matt McBride, who's this global head of UX at a company I used to work for.

+ +

And that was really the first thing is to try and rapidly prototype what the experience would look like and ultimately go out to our target audience, which was Gen Z here in the UK, and ask them whether or not this is the sort of thing they'd engage with. And the responses were actually really very positive. "Hang on; you're going to pay me to watch ads that are relevant to me? No-brainer, please do."

+ +

And then, we were able to raise 100 grand, 150 grand, which enabled us to take that prototype and build it into something that, after a few obstacles with Apple in the App Store, we were able to get live. So that was really the first thing, I guess is, figuring out the way and the people that I needed to help me out to take this idea into something tangible and then tested it before I went much further with it.

+ +

I was very fortunate, or I am very fortunate, that my partner is a corporate lawyer; my wife, sorry, now; we've been married since we started. [laughs] And so, actually, the mechanism through which we were able to raise the really earliest funds meant that we didn't have to give very much of the business away at such an early stage, which I think was a key learning point that I certainly share with other founders is you don't have to go give away 25% of your business for a little bit of money just to get it off PowerPoint. There are other ways.

+ +

CHAD: So I think I remember what I told you when we met and talked. Do you remember what it was?

+ +

GUILLAUME: You shared lots of very valuable insights with me.

+ +

CHAD: My memory is that at the time, it was only advertisements in the app. And I think I said, "I get that people are going to want to be paid to look at these things."

+ +

GUILLAUME: Oh yes, right.

+ +

CHAD: "But if there's nothing else here, it's going to be really hard to bring people back to do that." And we had seen that in another client of ours that was paying people to browse. And what they'd do is they do it for a while, and they'd hit whatever monthly cap of return that they could get, an amount that they thought made sense. And then, they would switch back to their other browser because it was a better browsing experience. So they were only using it because they were getting paid. And as soon as that incentive went away, they would stop using it.

+ +

GUILLAUME: Yeah, so I remember that. And you were right. And I guess there are a few things that came about from that, so the first thing is that Apple agreed. So we couldn't get the app onto the App Store if it was just a feed of adverts that remunerated the user to watch them, incentivized the user. So we put quite a lot of additional features, I guess more traditional fintech features, open banking features within the application in order to give the user insights into their spending, week-on-week analysis, and categorization of spend.

+ +

And we also built this what we call the level up section where every week, you get refreshed pieces of content around, you know, very Gen Z-focused again, but what's the difference between a credit card and a loan? Is buy now, pay later a good idea? What's open banking? So we generate all this content, which they don't get paid to consume but is there, and they do.

+ +

But more importantly, I think what we realized is that actually what we've got...this is the difference, I guess, between the Attention Exchange and Zedosh being the app; it's the plumbing and the matching that is the real value here. It is the models we're building that understand people's behavior and propensity or intent to buy something based on the data they're sharing with us.

+ +

And so, actually, what we've built is a solution where you should be able to log in to any publisher that has the additional content, and experience, and value that you're speaking about there, places you ordinarily already browse and frequent. But if you want to, there's a separate tab where there are ads waiting for you that remunerate you, but you go into that tab. So we're trying to remove the interruption, you know, the pop-up even having to accept cookies from your user experience with the publisher moving into a separate, dedicated tab.

+ +

And the reason the consumer is still going to go click on that tab is because they know that there's some content that's relevant and pays them, but they're still able to enjoy all the other benefits that the publisher provides. So it's kind of weirdly trying to flip this premium subscription model where you pay not to have ads. Actually, you're the first recipient of the ad income, and you share that with the publisher.

+ +

CHAD: I think this is really cool, and yet I think it also rubs up against or hits up against something that is just so different than the status quo. The idea that companies would not interrupt you with advertising is probably so foreign [laughs] to people that I imagine you get reluctance to that.

+ +

GUILLAUME: The last two years have been a steeper learning curve for us and all the advertisers and agencies, and players we've been speaking to. But what I'm grateful for is the fact that what we term the ad-pocalypse is coming. And so I was just at an event called MAD//Fest last week, which is basically all the advertising industry got together in London, the UK advertising industry. And every single panel discussion talk was about the post-cookie era.

+ +

And all that most people are speaking about is how do we gather more data in other ways from the consumer in order to keep doing more of the same? And all of a sudden, when we're talking about the fact that our users give us their banking transactions, we see how much they earn and where they spend it and, therefore, can also attribute without the use of cookies, which is the holy grail of advertising. We started generating an awful lot of interest from really big players.

+ +

So I think you're right; the status quo is having the rug pulled from underneath them, right? Look at Meta's share price this year. I haven't checked it this week, but last time I checked, it was down 52%. And that's because iOS app tracking transparency is stopping the ability to track and monitor and, increasingly, ultimately, the ability for the user to remain more private. And they all are doing it. Why would they want to be less private in order to benefit Meta? In our platform, they're opting into their most intimate data being shared because they stand to be rewarded fairly for it.

+ +

So I completely agree; up to this point, "What? No way." This is how it works. And certainly, the thing that will probably remain true is to do more with less isn't of interest because agencies get paid a percentage of the budget. They don't want to do [laughs] the same with less budget. But my point remains that with iOS app tracking transparency...apparently, Android is going the same way, and Chrome is replacing third-party cookies. The status quo simply cannot continue. Something has to change.

+ +

And so I think with this identity solution often is what we're building. The consumer stands a chance of being the first in line to receive a reward for their attention. And I'm very pleased actually we've got some competition as well since we last spoke, which is new. But this concept of rewarding consumers for attention, I think, will just...how else are you going to get their time? They're not listening to you on TikTok. [laughs]

+ +

CHAD: I'm happy to hear that you're viewing competition as a positive thing. And I agree competition raises awareness that this is a thing and a potential, and most people will shop around or research it further. And that's a chance for them to discover you.

+ +

GUILLAUME: I hope so. This company has done a big advertising campaign all over. It's on TV, radio, and the underground in London. And the amount of people who've reached out to me... "Is this company doing what you're doing?" And ultimately, they're paying users in a way for their attention to advertising. But they don't use open banking, and they don't have the data that we have.

+ +

CHAD: That's an important distinction. One of the things that I've seen our clients worry about...and I saw it happen to one. Even though lots of people worry about it, I've only ever seen it happen one time, but it's still a risk, and that is when competitors come along. And unbeknownst to you, they dramatically over raise and therefore are just able to flood the market, saturate the attention, and build way bigger and faster at a loss than you are willing to do.

+ +

GUILLAUME: Yeah, or able to do. [laughs]

+ +

CHAD: Or able to do, right? Because they've raised 500 million [chuckles] or something like that. That's what happened with our client, who was in the group buying space at the same time as Groupon and LivingSocial. And so that's the only time I've ever seen it happen, but it's something that people are worried about. How are you...is that something on your mind?

+ +

GUILLAUME: It's interesting. So they've raised 15 million Series A, and they've been around since 2012. So they've been around a long time. And it almost feels like they... [laughs] I'm not saying they did, but it almost feels like they landed on my LinkedIn. And we're very anti-social media. The message is really strong on anti-social media. But ultimately, they built an app.

+ +

And so I think we've already matured past the point that in terms of our scaling and our ability to integrate with any platform, our strategy already goes beyond competing on a direct basis of an app that serves ads. In fact, if anything, at some stage, I'm hoping that they could plug into our engine and our pipes and add an extra layer of data and personalization to the adverts that they serve.

+ +

So ultimately, when they came, and it was during the Champions League final that they had their first big launch because one of the backers is a football player, my phone just went berserk. Because it was like, wait, what? And at first, I was a bit worried but ultimately, no. I only really, really see it as a positive at this stage.

+ +

But obviously, yes, they can advertise. They can speak to brands. They've got much more market presence. Everywhere you go on the underground, there are those posters. But we have a very clear, distinct proposition that is quite different. As I said, really, this pulling apart what Zedosh is and what the Attention Exchange is; the Attention Exchange is really potentially the plumbing, the rails for this post-cookie advertising model.

+ +

CHAD: So that being said, you are doing some fundraising now. That's right?

+ +

GUILLAUME: Yes. In fact, I don't think I've stopped fundraising [laughter] since this started. And certainly, that wasn't something I was anticipating despite the fact that...I mentioned I'm married to a corporate lawyer. She told me, "Your role as a CEO, as a founder, you're just going to be fundraising." I thought, yeah, well, I'll get some money in, and then we can focus on doing the stuff. But every time money comes in, most often you sort of have already spent it. It's allocated; it's gone. You need to look for the next lot.

+ +

But yes, we are fundraising. Currently, we're still focused majoritively on angels. We're looking to prove our scalability model with this existing raise, at which point I think we’ll be ready and looking for institutional funds. But we use something called EIS funding which is UK-specific but is so, so rewarding for UK taxpayers. Basically, they get 30% back off the tax amount of their tax return, which is a great incentive, and all the gains from the equity is free of capital gains tax as well.

+ +

So it almost becomes a no-brainer for people who have money that they're looking to invest in early-stage risky businesses. They're already really risking. The capital risk is under 50% of what they put in because there's also an insurance element; if the company goes bust that you've invested, there's something called loss relief.

+ +

CHAD: So it's really attractive to angel-level investors.

+ +

GUILLAUME: Correct. So you have to be a UK taxpayer as an individual to benefit from this specific relief. Of course, I mean, we have had some non-UK people still invest through the same sort of advanced subscription agreement. But yes, it's very attractive for UK taxpayers.

+ +

CHAD: And do you think...[laughs] you've already answered this question. But I guess when do you think you'll stop fundraising?

+ +

GUILLAUME: We're looking to change the way the internet works. [laughter]

+ +

CHAD: Right.

+ +

GUILLAUME: And so if we're mildly successful even redistributing the 100 billion of ad fraud which is currently being lost out there, we're entering a very cash-rich market looking for solutions at this moment in time. So if we're to raise some cash that enables us to put in place the plumbing and the pipes that we're looking to connect to, then actually, we should be relatively profitable relatively quickly, at which point, I guess we'd no longer need to fundraise. But at which point we'd probably say, "Well, actually, the U.S. is now ready for this. Let's go."

+ +

CHAD: [laughs]

+ +

GUILLAUME: I don't think we're particularly a cash-thirsty business. It's all built on AWS.

+ +

CHAD: And you're right. That's why I asked the question because if your model is working, if you're having the impact you want, there's a lot of money in advertising. And so you should get to the point where you're able to do that profitably.

+ +

GUILLAUME: Absolutely.

+ +

CHAD: And start being as big as Google, right? [laughs]

+ +

GUILLAUME: Yeah. I read a book called Life After Google. I don't know if I shared that with you the last time we met. But it's weird. It was written five or six years ago, but it's coming true. I think this whole premise of Web3, and this decentralization of data, and the ownership of data, the profiting of data at the individual level, is coming to the fore. And I can think of no better way to bridge your value and identity online than having it connected to your real-world assets, income, and spending behavior.

+ +

CHAD: I was wondering whether you are going to mention Web3. [laughs]

+ +

GUILLAUME: Huh.

+ +

CHAD: Because this decentralization of the advertising money directly to users is a very Web3 idea.

+ +

GUILLAUME: I agree.

+ +

CHAD: [laughs] So how much do you talk about Web3 in your pitch or when you're talking about it? It hasn't come up until now in this conversation, so maybe not so much.

+ +

GUILLAUME: It's a double-edged sword, I feel, because I think most people think Web3. They think crypto.

+ +

CHAD: Yes.

+ +

GUILLAUME: And we're paying cash in fiat, and although there's every possibility we could have a token-based solution, we're not looking at that because the core immutable value of your attention is linked in your spending behavior on earth and online, but through real transactions with real merchants. 99.999% of transactions, I imagine, aren't crypto yet and don't live on a blockchain, so until that point, I think we steer clear of it.

+ +

Whether we could have raised more money more quickly if we [laughs] had mentioned it more, I don't know. But for me, there are quite a few steps to go in our journey as I see it having matured from the app to the plumbing, the plumbing now going to more publishers, more publishers meaning more audience, more audience meaning more attention, more advertising. At which point, as I said, the U.S. will probably be there with open banking. There are a lot of things in Web 2.0 that could be resolved. And yeah, if we make it that far, I think we'll be in an awesome position to have an identity solution for Web3 or Web5. [laughs]

+ +

CHAD: Well, I wish you all the best in that journey. And I really appreciate you stopping by and sharing with us.

+ +

GUILLAUME: My pleasure. It's been real great and nice to hear from you again. And I hope our paths cross in the real world soon enough.

+ +

CHAD: Yeah. If folks want to get in touch or learn more or get in touch with you, where are all the different places that they can do that?

+ +

GUILLAUME: We have two websites, so zedosh.com is the consumer app, attentionexchange.co.uk is our other website. Otherwise, feel free to reach out to me on LinkedIn. And on Twitter, I'm @G_Zedosh. I'm not massive on Twitter. There are a lot of bots on that.

+ +

CHAD: [laughs] I guess I'm not that surprised.

+ +

So you can subscribe to the show, find links to everything that was just mentioned along with notes and a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. I'm also not very active these days.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Guillaume Kendall.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+4ZtXP_ox + + ]]> + + Chad Pytel + Guillaume Kendall + + + 441: Creative Startups with Alice Loy + https://podcast.thoughtbot.com/441 + 3495055b-1ae1-4805-a44f-19d9834392fb + Thu, 22 Sep 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Alice Loy is a Founding Partner at DaVinci Ventures and the Co-Founder and CEO of Creative Startups, the leading global startup accelerator and company builder for design, food, immersive, and creative companies. + +Victoria and Chad talk with Alice about what she means by creative companies, how much judgment she must pass as an investor with a love for the "weird and wonderful," and some of the challenges faced in bringing diversity to the rest of the accelerator world. + 40:47 + no + + + Alice Loy is a Founding Partner at DaVinci Ventures and the Co-Founder and CEO of Creative Startups, the leading global startup accelerator and company builder for design, food, immersive, and creative companies. +Victoria and Chad talk with Alice about what she means by creative companies, how much judgment she must pass as an investor with a love for the "weird and wonderful," and some of the challenges faced in bringing diversity to the rest of the accelerator world. +DaVinci Ventures (https://www.davinciventures.co/) +Creative Startups (https://www.creativestartups.org/) +Follow Creative Startups on Twitter (https://twitter.com/createstartups), Instagram (https://www.instagram.com/createstartups/), Facebook (https://www.facebook.com/createstartups/), Substack (https://creativestartups.substack.com/), YouTube (https://www.youtube.com/channel/UC1SCTGPWdes6ArrYJU0YJ-g), or LinkedIn (https://www.linkedin.com/company/global-center-for-cultural-entrepreneurship/). +Follow Alice on Twitter (https://twitter.com/aliceloy) or LinkedIn (https://www.linkedin.com/in/aliceloy/). +Alice's Blog (http://www.aliceloy.com/) +Etkie (https://etkie.com/) +Embodied Labs (https://www.embodiedlabs.com/) +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Alice Loy, Founding Partner at DaVinci Ventures and the Co-Founder and CEO of Creative Startups, the leading global startup accelerator and company builder for design, food, immersive, and creative companies. +CHAD: Alice, thank you so much for joining us. +ALICE: Thanks for having me. +CHAD: Can you tell us a little bit more about Creative Startups in general but also what you mean by creative companies specifically? Like, isn't every company creative? [laughs] +ALICE: Yeah, it's so funny. That's often the first question. And sometimes people I can feel their sense of indignation in thinking maybe I think they're not creative. +CHAD: [laughs] +ALICE: First of all, the creative industries are pretty well defined globally by the World Bank and entities like that. I'll come back to that. Yes, all human beings are creative. I like to joke that that's what got us out of caves in the first place. But more importantly, all entrepreneurs are very creative regardless of what sector you're operating in. +So when we're talking about creative, we're just referencing the set of industries that are measured as the quote, "creative industries." They include film, our museums, design certainly is a core element of that. Increasingly, we're seeing more and more people move toward the creative industries as mechanized labor takes over things like building cars or even running data analysis. +CHAD: Has getting support and funding and that kind of thing traditionally been easy in the creative space or hard? +ALICE: No. I know you know the answer to that question because you're a designer. [laughs] +CHAD: I usually don't ask questions that I don't know the answers to, so... [laughs] +ALICE: But it's a great question because actually what it uncovers, you guys, is that it has changed dramatically for people who I call creatives or creators in the last two or three years. It's a little tough to measure with the pandemic, but we know at least $2 billion have gone into platforms that support creators, businesses led by creators. The creative industry has really turned a corner. +So when we started this work 15-16 years ago, I co-founded the organization with a gentleman named Tom, who is now in his 80s. But he had come out of what's called the cultural economy, which was the precursor to the creative economy. And, of course, now we're all living in the creator economy. So like every other industry, it evolves. And one turn in this evolution is that creatives are now understood as economic drivers, not just people who add nice flourishes to things at the end. +When you're building new products, people think about engineers, but it's really a creative process. And people increasingly bring in creatives from the outset to think about how the design process can be more humanized, can be more effective to solve people's problems so that your products really delight customers instead of just get the job done. +CHAD: Is there something you can point to that triggered or pushed along that turning point? +ALICE: Well, not to be overly philosophical, but I would say the general sense in the U.S. and increasingly in other countries where we work is that human beings don't want to be cogs in a wheel. They don't want to just be bit parts in a system. When you talk to Gen Zers, they understand that they are complete human beings. And somehow, I think older generations bought into the idea that you have the same job for 40 years. You go to work at 8:00; you come home at 5:00. You repeat the next day. +I think the sense in the economy is that people want to be fulfilled. If they're going to give that much time to a job, they want it to be meaningful and valuable. And they want it to solve some of the big problems. Frankly, big tech is not approaching the world in that way these days. And so I think younger people are looking for values-aligned opportunities. +And the creative economy is a space where values tend to align with really reaching the full potential of each human being instead of just extracting their physical and occasionally mental labor toward building a capitalist system. And so I think that zeitgeist has helped open the door. +I also then think when you look at the kinds of technologies that are being utilized, they're still fundamentally about communicating ideas, and art, and inspiration. That's what Facebook is. That's what TikTok is. That's what even news channels are. And as more people come into the world of saying, "Oh, I can share my ideas, my art, my jokes, my music, my whatever," they see themselves as creatives, and they go, "I wonder how I could get paid for that?" I mean, there are a multitude of factors weaving together to shift. +I also think, quite frankly, the SaaS investment area has become so saturated. I mean, if you walk down the street in San Francisco, if you don't bump into three venture capitalists who are SaaS investors, it's like, what are you doing? And so I think other types of investors with a different background maybe are saying, hmm, what about this area over here? How could we make money? So that would be another thread I would say is helping drive. +CHAD: It strikes me that what you've shared sort of creates a self-fulfilling cycle too. +ALICE: Yes. +CHAD: Because once creatives have examples of other creatives that have done this, it becomes an aspirational thing that they understand that they, too, could do themselves. +ALICE: Yeah, 100%. So our goal when we started the startup accelerator...we launched the first accelerator for creative founders in 2013 in the world. And we said to ourselves, if we get one company that becomes the poster child for this creative movement and demonstrating that you can be, as we like to say, weird and wonderful and build a company, then we will unleash a flood of people who now see themselves in that light. +We were very fortunate in that we got that one poster child, and that has really helped us paint a picture that's clear for a lot of people where they see themselves as entrepreneurs, even though they're a tattoo artist or they're a hard rock Navajo metal band from the reservation or whatever their background is. Now they look and go, "Oh yeah, I could do that," and they certainly could. Being an entrepreneur is really hard but not intellectually challenging; it's more heart-challenging. +CHAD: Oh, that's really interesting, more heart challenging. +ALICE: Yeah. I mean, you're an entrepreneur. You guys have built a business, so you know that being an entrepreneur is more about being able to just sort of stay calm in the waves than it is about building the world's best boat and being able to steer toward that destination no matter how the winds blow. +CHAD: Yeah, I've often referred to it almost as grit, like the ability to, no matter what happened yesterday, get up and do it again. +ALICE: Get up, yeah. And unfortunately, I think there's a myth, maybe at least in the U.S., that what drives most people to get up and go, again, is money. And I don't think that's true at all. I think what drives people to get up and go again is their love of customers or end users. And their feeling they're just irrefutable despite there being no evidence feeling that this is going to work. This is going to make a difference in people's lives. And that's why the sort of slog. +And there are days when...one of the things we always start a Creative Startup's program with is find your tribe. Cling to the people who believe in you. Ignore the naysayers. The naysayers are ten to one. Blow them off and cling to the people who say, "Wow, dude, that sounds cool. I bet you could do that." Yes, do another coffee meeting with that person. [laughs] +Because sometimes you just need people who can say, "You got this. You got this. Just do another day, man." What do you guys do? Let me ask, what do you guys do when things get really rocky for you? How do you guys collect that internal okay, I'm going to get back in the saddle. +CHAD: I've talked about this with people before, and I actually think that this is going to be a non-answer, but I'll do my best. I actually don't know exactly what does this for me. But I do know a side effect is I also don't celebrate the wins as much as other people wish that I did. And I think it's because I just move on very quickly from things. I don't dwell on the downs as much. I also don't dwell on the highs as much. And so I don't know if it's just something about me that does it or I just trained myself to do that. But it does have some downsides to it. +ALICE: That was a real answer. That wasn't a non-answer at all. +CHAD: [laughs] +ALICE: Victoria, what about you? +VICTORIA: I think to add on to what Chad said is kind of that thoughtbot mentality of viewing things as an experiment. And so if you come in with that mentality, like, this is the experiment. We'll see if it works or it doesn't. And if it doesn't work, there are some lessons to be learned, and we can grow from that and do better next time. And if it does work, great; [chuckles] this is cool. +And I actually like to celebrate the wins a lot. I like to really dwell in those moments and feel like we did something right. We should remember this and learn from that as well and then try to repeat it, right? +ALICE: Yeah. Oh, I love that. +CHAD: You mentioned that when you were first starting Creative Startups, you hoped to get one win, and you did. Which one was it? +ALICE: To be clear, as a mom, we don't have favorite children, okay? [laughter] And there are different companies that have had enormous impact in different ways, so let me tick some off. Let me name first Etkie. It's a design company built by a woman named Sydney, who grew up in rural New Mexico with a passion for working with indigenous communities. +Her design company makes spectacular handmade bracelets, average price point around 250 bucks. And she sells in about 100 different high-end galleries around the world. She creates 40 jobs for Navajo women on the reservation at twice the annual pay that they would receive if they worked any other job there. Pretty astounding, pretty astounding. +Those women have gone on to reinvest their money in things like rebuilding the school, putting in wells for family. The Navajo Nation lacks drinking water all over the place. So really fundamentally shifting the economic and social trajectory of that community. +She designs every single bracelet with a woman, and you'll see they're named after the women. And they just do a recollection process where the woman recalls something from her childhood, and they weave a story around that. And then, they create the bracelet design. They're beautiful, Etkie, E-T-K-I-E. +The next one I would say that has really inspired me is founded by another woman who does...now she's doing more XR AR, But they started as a virtual reality company doing films for medical providers who needed to better understand the disease experience of their patients in order to come up with not just solutions to their lived experience but actual medical procedures, and technologies, and pharmaceuticals that could shape the outcomes of that patient. +So that company is called Embodied Labs, founded by a woman named Carrie and her team out of LA. And they're now selling to hospital systems across California and increasingly in the Midwest, et cetera, changing thousands of lives. +And then the one that most people do point to us and say, "Hey, good job," is a company called Meow Wolf. We were their first investor back in 2014. They've gone on to raise upwards of $250 million. They're kind of a competitor now to Disney. So they're in the immersive art and experience realm. They had a million visitors in their Denver spot. So far this year, they've had about a million visitors in their Las Vegas spot. +They were founded here in Santa Fe, our hometown. And we didn't even know they existed. They didn't know we existed. [chuckles] The night before our application was to close, somebody wandered into a meeting they were having where they were talking about dissolving the art collective. And somebody said, "Oh before you guys make a decision, you should check out this thing." [laughs] +So in some ways, it was angels on our shoulders in that it's a homegrown company, and Santa Fe is a small city. We needed a shift here around our creative economy. And they needed somebody to believe in them. They had gone to every business support organization they could find and had been told, "Well, you're probably trying to start an arts nonprofit." And they thought, "That's not really our vision. That's not...we want to build a company. We think art is something people will pay for if it's put forward in a way that blows your mind," and Meow certainly blows your mind. +CHAD: That's really interesting. I mean, I totally get why people would say that just because...but that's like saying...when Disney was getting started [chuckles] people saying "It sounds like you're trying to create an arts nonprofit." +ALICE: Yes. And I'm guessing a lot of people did. The future happens when we're all looking backwards, and very few people are looking forwards. And so I think it's important for entrepreneurs to keep in mind you're probably just statistically talking to somebody who's looking backwards because human beings tend to do that more than they look forward. +And so better to find people early on who say, "You know, I'm not exactly sure what you're talking about because you're the expert in your startup, and I'm not. But let me ask you this, how could I be helpful?" That's the right question. If they give you an answer and they don't even know what you're talking about, you probably don't need their help. +And that's hard for entrepreneurs because there are so many doubters out there that you have to kind of keep plucking through to find the one or two people who say, "That's really interesting. That seems like it might work. How could I help?" Did you guys have somebody at thoughtbot early on who you can remember sort of said, "Huh, that's interesting. How could I help?" +CHAD: I think it was our early clients who most did that. +ALICE: Oooh, yeah. +CHAD: Because we're a consulting company, because we're an agency, finding clients who believed in us and wanted to work with us in part because they liked us was an important aspect to that. If it wasn't for those early clients, no amount of passion would have kept us going because we needed to support ourselves. +ALICE: What a great insight, honestly. I think the sort of rhetoric around passion is really abused. Because there's now this sense that, well, if you have passion, you can build a business, and that's just not true. That's not true. I hate to say it, and people are always stunned when I say it because they think that I lead Creative Startups; I must be the core passion champion. +But here's what I would say is if you have a passion for solving your client or your customers' problems, then you might have a business. [laughs] There's a huge difference there. There's a difference between well; this is what I want to make. This is what I love doing. That is not necessarily going to answer the question is anybody paying you to do that? +And I like to encourage people to think about if you have passion for doing something, you probably have a hobby. If you do stuff that people want to pay you to do, you might have a business. And crossing that bridge is an analytical and a heart-wrenching process. Because usually, what you end up with is I mostly get to do what I love to do. But I do a lot of stuff I don't want to do because that's what building a business is, just like being a parent or any other really amazing, wonderful thing in life. +Running a business is not just about doing what you love doing all day; it's mostly about doing what people want to pay you to do. And if you're doing what people want to pay you to do and you love it, that is beautiful. That is a blessed position to be in. It's rare. And you have to ask yourself very real questions and be brutally honest with yourself, or you could waste your retirement savings. You could spend a year or two away from your family before you figure that out, not to be depressing. [laughs] +But we always say from our programs we look...not from our more advanced accelerator programs, but we also provide programs that are more; how do you figure out this idea? You have this idea, or you have what we call lucky revenue. A lot of creatives get lucky revenue where their friend sees them doing something, and they go, "Man, would you do one for me?" And then somebody else wants one, and now they have lucky revenue. And they're ready to say, "I think this might be a business." +And those people we say you have three outcomes from our programs. One, you realize this is not a business. It's just not going to make any money. The business model does not pan out. Two, this might be a business if I do it differently, and now I need to figure out if I want to do it differently. And three is, yeah, I'm on track. Now I got to go grow it. And all three are valid outcomes. +Because we've worked with people who came to us late, took out a loan. And we said, "Well, what's your plan for paying it back?" "Well, we don't know." That's bad. That's really dangerous. That can ruin families' economic futures. And so we're much happier to catch people before that happens so they can ask those critical questions about is this really a market opportunity? Is this a business I want to build? Is this, therefore, a business opportunity for me? And those questions are deceptively simple. +In our more advanced programs, we focus on, okay, you've got revenue, you've got traction. You're ready to start maybe thinking about what's the next three years? Where are your cash flow gaps? Where's your, as people like to call it, the valley of death that you have to cross as you grow? What kind of financing can you go raise to help cross that valley? How do you get to 10 million in revenue, 50 million in revenue? People are at different stages of growing a business. +MID-ROLL AD: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs. +CHAD: How much judgment do you pass as an investor as people who are reading applications about who gets into the accelerator program? How much judgment do you pass, and how do you strike that balance? +ALICE: That's kind of a peek behind the curtain; how do people really pick companies? Different people do it differently. For us, we really hue toward weird and wonderful. We actually prefer...and this goes against what people say you should do, [laughs] but we kind of go against the grain in general. And it's worked out. +We prefer to look at things that we don't totally understand partly because often creatives don't speak business speak. So I'm pretty turned off by (I'm going to make something up.) the Harvard Business School grad who has a music-sharing platform and doesn't play music. I'm like, how would you know about a music-sharing platform? +Whereas a musician who comes with their garage band and they happen to have a computer science degree from the college down the road and they've invented this thing and all of a sudden, it's taking off, and they're not even sure why. I'm listening, and I'm like, oh, that's really interesting. +A lot of creatives tend to pick up on opportunities in the market, and they don't frame it so much as a business opportunity because that's just not the language that they've learned to speak yet. But they have an insight into a particular sector or a need that people who are not really in that space... +It feels like a lot of the startup world has been overtaken by people who want to be startup founders but don't necessarily have their hands dirty in a particular sector where they know how to really solve a problem that either a lot of people have, or that very few people have but that a lot of people have in the future if you build the market. And that's where you make a lot of money is if you build a market. So we look for things like that. +So what does that mean when we're reading applications? We don't ask for financial statements. We ask, how much money did you make last year, and where do you think most of that money came from? We're more interested in are they interested in analyzing their business so they understand where growth could come from next? Instead of, what is your financial statements? +Most of the entrepreneurs who come through our programs don't have financial statements. They might not even have a cash flow projection, which is really exciting. We have entrepreneurs who come to us who...I'll tell you a story. We had an entrepreneur come to us who ran underground music clubs in old houses in Denver. And he was like, "I think this is a business, but I don't know anything about business. I just started hosting these a few years ago." +And I said, "Well, how many people...like, if you took an average year..." and I said, "You don't charge anything?" And he said, "No, people just hear about it." And I'm thinking, okay, so you get a couple thousand. "How many people in an average year come to your basement music club thing?" "50,000." [laughs] Yeah, I think you might have a business. +I mean, those are the kinds of things that you think, wow, why did that take off? What is going on there? That's really interesting. Let's talk. And he had a mohawk. He played in a metal band. Business was not his deal. And so that wasn't the lens he was applying. +I think a lot of designers and a lot of people who invent products and solutions start with; I'm doing this for myself, wouldn't this be rad? Without even knowing that, they touched a nerve in the market that now is kind of catching on fire. Those are really exciting entrepreneurs for us to work with. +They do have to turn a corner on I'm building a business now. I'm not just doing something that's cool with my friends. And that can be a difficult place because it means you have to cross a bridge into the world of finance, and you're probably going to have to hire product managers. And now you go hire that Harvard Business School grad and they work for you. +And a lot of people frankly don't want to turn that corner. And I get it because when you come back to that topic of, is this values-aligned? A lot of that world is not yet totally values-aligned. That's shifting, more impact investors, more investors who want to see more different types of people starting companies, but we're not there yet. +And so there's this cultural clash. When creatives walk toward that space, they go, ew, I've been fighting against the man my whole life. And now you want me to get in the car and go on a long road trip with them? No thanks. [laughs] And I'm sitting there with the Doritos going, yeah, man, but I got all the good munchies, let's go. It often does work out. But I also understand why people say, "You know, that's just not my deal now." +VICTORIA: Yeah. And you have a tremendous amount of diversity in your alumni. +ALICE: We do, yeah. +VICTORIA: And so do you find that there are some challenges in bringing in that group to the rest of the accelerator world? +ALICE: Yeah, you know, funny, I was thinking about that yesterday. So about 70% of our alumni, and this has been true across the board from day one, are people of color or women. At one point, it was around 30% were women of color. I haven't looked at that number in a while. We've worked with about 550 companies worldwide. +In the Middle East, half of our alumni are women-led companies. In the U.S., we are fortunate to be able to work with a lot of indigenous communities. New Mexico is home to a large indigenous population. And it's a lot of the reason our culture is so dynamic and beautiful. +So for us, that was always a no-brainer that that was where a lot of the interesting creativity would come from and that that was where the rising markets were. We, for example, accelerated and were the first investor in a company called Native Realities, which is a comic book. And they founded the first indigenous Comic Con, which is now called Indigenous Pop X worldwide. +And they saw obviously before even Black Panther, and it became kind of like people said, "Oh yeah, superheroes come from all communities." They saw that that market was rising. There are 300 million indigenous people worldwide. There are two comic book companies. Let that sink in. [laughs] It's like, oh my God, what is the possibility then not just around comic books, but gaming, animation, all kinds of creative tools, film, music? That's a huge market that has not been served at all. +And we understood early on that that was an area where people want to tell their own stories. People want to understand the stories of other people. And then people want to build new stories together across those cultural or geographic boundaries. And the technology had shifted such that that was possible. +In 1980, that wasn't really possible. The distribution channels of film were such that you had to raise money in Hollywood and have Tom Hanks and whatever. That's just not true anymore. So we saw that early on, and that has helped attract a lot of entrepreneurs who share our passion for really telling those stories. +However, I would say for people who want to support rising entrepreneurs out of what I'm going to call distressed communities or communities that have been literally discouraged from becoming their own economic leaders is that the burden that most of the people bear who are building businesses, for example, from Black communities, or native communities, or women in the Middle East, those people tend to bear a larger burden than someone from a more privileged background like myself. +They're often the person in their family and for their community who is helping to ensure that people get the health care they need, that that kid was able to visit the college that they wanted to apply to. They become that sort of anchor of support for more people than in situations where we have more support and more what I call margin. They have really little margin. +And so to ask them to, for example, join an accelerator full-time for 12 weeks that just doesn't work. Because the decision that they're making, you know, from a very privileged position, we can say, "Well, either you're dedicated to your business, or you're not." But really, what we're saying to them is, well, either you do your business, or you love your family and your culture. That's the question we're asking them, and that's a totally unfair question. That's a ridiculous question. Every single one of us would say, "I love my family. Thanks, see ya." +CHAD: So how do you balance that? +ALICE: Well, it's tough. I mean, first of all, we have adopted in the programs where it's more for early-stage entrepreneurs, and we're opening doors to entrepreneurship. And we are being first and foremost patient, patient with they're crossing that threshold. +We understand that our core outcome is that people come always saying, "I'm an entrepreneur. I'm ready for the journey." That means we do things like, first of all, we do all online. If possible, we do a meeting upfront, so everybody meets each other in person because that kind of sets a tone of just it's a lot of fun. We have food and drink, and we have a good time. And then we do 6 to 12 weeks online, and then we do a gathering at the end. And we build a community first and foremost of people who are understanding how they can help one another. +So Creative Startups is a little different in how we do accelerators. We do not ever have people stand at the front of the room and tell people what they should do with their business partly because we're educators first and foremost, and we understand...I have a Ph.D. in entrepreneurship. I understand that entrepreneurs tend to be experiential learners, not all but many. +And we're not going to be there in a year building their business. They're going to be building their business. We have to build their self-confidence. We have to build their ability to say, "I know how to row the boat. You're along for the ride." I'm just along for the ride. [laughs] +That requires us to do things like, okay, so let's work on your business model and really carefully chunk out here's one piece of that. Let's go deeply into understanding that. Let's tackle the vocabulary. Let's look at how people talk about it online. Let's open that door culturally so that you can take that into your experiences and say, "Oh, I already kind of do that. I just use a different language," which is what a lot of designers do. +A lot of designers, whatever your background, already do entrepreneurial processes. They use different language, and it's just a translation. It's literally just vocabulary. So we help people understand that the best way to figure out your client's needs are by listening; all people know that. If you want to understand someone else, listen, and unpacking that into then business speak a little bit, and then giving them opportunities to go do that in the real world. +And being patient with how they might do that or why they couldn't get it done this week. Or maybe they want to come back with a different way of describing it than maybe a White person like me might describe what they experienced. And just giving a lot of latitude to people to have that own experience themselves. +That honestly...I know that sounds very philosophical. But it breaks down into tactical things that we do in an accelerator that opens the door to a lot more entrepreneurs. And our Net Promoter Score is 9. Over 90% of people would recommend our program. People love our programs. And 70% of our alumni are still in business. So I think it's working. We have a lot of learning to do. We're doing an indigenous accelerator right now, and it's a lot of learning for me. It's very eye-opening. +CHAD: As an accelerator specific to indigenous peoples, what made you decide to do that? Some people I know, thoughtbot included, sometimes hesitate to do things like that because we don't want...there's some hesitation around doing something like that. +ALICE: So we share all of those hesitations, and we think they're spot on. We are doing this in partnership with a group called Creative Nations out of Colorado. They are all indigenous people. They're a new group. And we envision Creative Startups moving more toward a place of being kind of like the intel, you know, the old intel inside. We are inside, and we're an engine within another organization. +So here in Santa Fe, we partnered with Vital Spaces, which serves Black and Brown creative entrepreneurs and artists. And our goal is to help build their capacity to be able to keep doing programs as they see fit for entrepreneurs. And we're standing by as they would like us to help. So we took that same approach with working with Creative Nations. It's been a fantastic partnership. +The lead working with us is a woman named Kelly Holmes. She is Lakota Sioux. She's from the Cheyenne River Reservation. And she founded Native Max Media, which publishes Native Max Magazine, the world's first fashion magazine for indigenous entrepreneurs. She is a brilliant, creative entrepreneur. She is self-taught. She eked it out. She has been around ten years now. It's astounding. +And you see the magazine, and it's spectacular. It is high glamour, beautiful. And it is reshaping the way not only indigenous people see themselves but how White people see indigenous people. And those reframed stories are so important to building a more equitable society. So I was over the moon to partner with her. Then I learned her mom is one of the few Lakota language teachers. +So Lakota is her first language. Her mother teaches Lakota and teaches teachers how to teach Lakota. So she grew up with an educator. So she has taken to building this, again, patient, very exploratory online environment for indigenous entrepreneurs. And then I bring sometimes the more technical like, oh, you're asking a specific question about how to do structured interviews with customers. Sure, let me talk a little bit about that. +But as we started out this conversation, you guys, entrepreneurship is not an intellectual challenge usually; it's a heart challenge. I don't mean that in a way to disparage how important it is to be really strategic and smart about your business. But I think at the outset especially, you just have to be able to hang in there and keep doing it. And then, as you grow into that opportunity, you start to see that the intellectual challenges unfold because your opportunities become more complex. +But at this outset with Kelly, it's been a conversation with people who are frankly reframing themselves as business leaders, people who own businesses and have employees based on their creative output. And that's a really exciting space to work in. We wouldn't work in this space if we didn't have a partner who shared our vision and who wanted to be that native leader of a program like this. It just wouldn't really feel exciting. +CHAD: I think that that's great advice and a framing that helps me think about the things that we've tried to do in the past and the things that we hope to do in the future and realizing that really genuinely partnering with someone in the actual community that we're trying to serve or to have an impact with is sometimes an important missing component that we need to incorporate. That'll help solve a lot of the hesitations that we might have around doing something. +ALICE: Yeah, yeah. +VICTORIA: Right. And we've all heard before that culture eats strategy for breakfast, which I think -- [laughs] +ALICE: That's my favorite line, Victoria. You nailed it. +VICTORIA: It makes sense that the more connected you are to your culture and to your community, that's where you'll be the most successful when your heart is in it. +ALICE: Yeah. And I want to give sort of a plug for stepping outside of the zone of the way...I went to business school. I have an MBA. I'm really well-versed in that whole world. I'm married to a venture capitalist. He teaches how to do venture capital at Stanford. That whole world is very familiar to me. And it seems to not be helping us solve the problems that we have now as a society. +And so one of the reasons I encourage people to go to those partners, go to those places where you're like, I don't fit in here; I don't understand what's going on here; these people speak a different cultural language, form, way of doing things, I encourage that because I think that for people who want to build a different world, we have to stop looking to the world that we already have. And we have to say, "Well, who does things differently? What could we learn?" +One of the most beautiful things about working with the entrepreneurs in the cohort right now, the indigenous cohort, is they first talk about taking care of their people, that's first. And it's like, wow, if that's your entire frame, you start to make really different decisions in business. If you're talking about well, I want to take care of the people in my community; I want people to be healthy and happy and be able to pursue their own dreams; that's a really different frame of mind for a baseline for decision making. +The other thing that Kelly talks about that I love (I'm stealing it from her.) is she talks about fighting for her business, fighting for her business. And that, to me, is such a great way to feel like, okay, if I'm fighting for my business, I know how much Creative Startups has achieved. I'm not fighting for myself. It's not my ego. It's none of that. It's fighting for my business so my business can keep having the impact. +Everything that I think about now in terms of working with indigenous entrepreneurs is this has nothing to do with me. Their frame is very much my community, my people, my business, which is over there. And it's a humble way of understanding one's place. And that is a really exciting reframe for me to think about how we can solve problems like the climate crisis, like the disparity between rich and poor, like the disintegration of our democracy. What if we had a different frame? How could we solve problems differently, maybe better? +So for us, these partnerships unlock a whole vast area of new thinking, new ways of doing business, new ways of taking care of other people. And at the end of the day, that's what gets me back in the rowboat [laughs] is this idea of, wow, we are having an impact on other people. And doing it with people who have a different starting point has really shaped a lot of the work that we do. +CHAD: Well, I'm sorry that we have to wrap up. Otherwise, we could keep on going and solve the climate crisis and unraveling of our democracy, but -- [laughs] +ALICE: Yeah, I have an appointment at 2:00 where I'm doing climate crisis. So I'll let you know how it goes. +CHAD: Okay, wonderful. +ALICE: [laughs] +CHAD: Alice, thank you so much for joining the show and sharing everything with us. We really appreciate it. +ALICE: Yeah, I was delighted to be with you guys and hope to continue the conversation. +CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +VICTORIA: And if you have questions or comments, email us at hosts@giantrobots.fm. +CHAD: You can find me on Twitter at @cpytel. +VICTORIA: And you can find me on Twitter @victori_ousg +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +CHAD: Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Alice Loy. + + + Alice Loy is a Founding Partner at DaVinci Ventures and the Co-Founder and CEO of Creative Startups, the leading global startup accelerator and company builder for design, food, immersive, and creative companies.

+ +

Victoria and Chad talk with Alice about what she means by creative companies, how much judgment she must pass as an investor with a love for the "weird and wonderful," and some of the challenges faced in bringing diversity to the rest of the accelerator world.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Alice Loy, Founding Partner at DaVinci Ventures and the Co-Founder and CEO of Creative Startups, the leading global startup accelerator and company builder for design, food, immersive, and creative companies.

+ +

CHAD: Alice, thank you so much for joining us.

+ +

ALICE: Thanks for having me.

+ +

CHAD: Can you tell us a little bit more about Creative Startups in general but also what you mean by creative companies specifically? Like, isn't every company creative? [laughs]

+ +

ALICE: Yeah, it's so funny. That's often the first question. And sometimes people I can feel their sense of indignation in thinking maybe I think they're not creative.

+ +

CHAD: [laughs]

+ +

ALICE: First of all, the creative industries are pretty well defined globally by the World Bank and entities like that. I'll come back to that. Yes, all human beings are creative. I like to joke that that's what got us out of caves in the first place. But more importantly, all entrepreneurs are very creative regardless of what sector you're operating in.

+ +

So when we're talking about creative, we're just referencing the set of industries that are measured as the quote, "creative industries." They include film, our museums, design certainly is a core element of that. Increasingly, we're seeing more and more people move toward the creative industries as mechanized labor takes over things like building cars or even running data analysis.

+ +

CHAD: Has getting support and funding and that kind of thing traditionally been easy in the creative space or hard?

+ +

ALICE: No. I know you know the answer to that question because you're a designer. [laughs]

+ +

CHAD: I usually don't ask questions that I don't know the answers to, so... [laughs]

+ +

ALICE: But it's a great question because actually what it uncovers, you guys, is that it has changed dramatically for people who I call creatives or creators in the last two or three years. It's a little tough to measure with the pandemic, but we know at least $2 billion have gone into platforms that support creators, businesses led by creators. The creative industry has really turned a corner.

+ +

So when we started this work 15-16 years ago, I co-founded the organization with a gentleman named Tom, who is now in his 80s. But he had come out of what's called the cultural economy, which was the precursor to the creative economy. And, of course, now we're all living in the creator economy. So like every other industry, it evolves. And one turn in this evolution is that creatives are now understood as economic drivers, not just people who add nice flourishes to things at the end.

+ +

When you're building new products, people think about engineers, but it's really a creative process. And people increasingly bring in creatives from the outset to think about how the design process can be more humanized, can be more effective to solve people's problems so that your products really delight customers instead of just get the job done.

+ +

CHAD: Is there something you can point to that triggered or pushed along that turning point?

+ +

ALICE: Well, not to be overly philosophical, but I would say the general sense in the U.S. and increasingly in other countries where we work is that human beings don't want to be cogs in a wheel. They don't want to just be bit parts in a system. When you talk to Gen Zers, they understand that they are complete human beings. And somehow, I think older generations bought into the idea that you have the same job for 40 years. You go to work at 8:00; you come home at 5:00. You repeat the next day.

+ +

I think the sense in the economy is that people want to be fulfilled. If they're going to give that much time to a job, they want it to be meaningful and valuable. And they want it to solve some of the big problems. Frankly, big tech is not approaching the world in that way these days. And so I think younger people are looking for values-aligned opportunities.

+ +

And the creative economy is a space where values tend to align with really reaching the full potential of each human being instead of just extracting their physical and occasionally mental labor toward building a capitalist system. And so I think that zeitgeist has helped open the door.

+ +

I also then think when you look at the kinds of technologies that are being utilized, they're still fundamentally about communicating ideas, and art, and inspiration. That's what Facebook is. That's what TikTok is. That's what even news channels are. And as more people come into the world of saying, "Oh, I can share my ideas, my art, my jokes, my music, my whatever," they see themselves as creatives, and they go, "I wonder how I could get paid for that?" I mean, there are a multitude of factors weaving together to shift.

+ +

I also think, quite frankly, the SaaS investment area has become so saturated. I mean, if you walk down the street in San Francisco, if you don't bump into three venture capitalists who are SaaS investors, it's like, what are you doing? And so I think other types of investors with a different background maybe are saying, hmm, what about this area over here? How could we make money? So that would be another thread I would say is helping drive.

+ +

CHAD: It strikes me that what you've shared sort of creates a self-fulfilling cycle too.

+ +

ALICE: Yes.

+ +

CHAD: Because once creatives have examples of other creatives that have done this, it becomes an aspirational thing that they understand that they, too, could do themselves.

+ +

ALICE: Yeah, 100%. So our goal when we started the startup accelerator...we launched the first accelerator for creative founders in 2013 in the world. And we said to ourselves, if we get one company that becomes the poster child for this creative movement and demonstrating that you can be, as we like to say, weird and wonderful and build a company, then we will unleash a flood of people who now see themselves in that light.

+ +

We were very fortunate in that we got that one poster child, and that has really helped us paint a picture that's clear for a lot of people where they see themselves as entrepreneurs, even though they're a tattoo artist or they're a hard rock Navajo metal band from the reservation or whatever their background is. Now they look and go, "Oh yeah, I could do that," and they certainly could. Being an entrepreneur is really hard but not intellectually challenging; it's more heart-challenging.

+ +

CHAD: Oh, that's really interesting, more heart challenging.

+ +

ALICE: Yeah. I mean, you're an entrepreneur. You guys have built a business, so you know that being an entrepreneur is more about being able to just sort of stay calm in the waves than it is about building the world's best boat and being able to steer toward that destination no matter how the winds blow.

+ +

CHAD: Yeah, I've often referred to it almost as grit, like the ability to, no matter what happened yesterday, get up and do it again.

+ +

ALICE: Get up, yeah. And unfortunately, I think there's a myth, maybe at least in the U.S., that what drives most people to get up and go, again, is money. And I don't think that's true at all. I think what drives people to get up and go again is their love of customers or end users. And their feeling they're just irrefutable despite there being no evidence feeling that this is going to work. This is going to make a difference in people's lives. And that's why the sort of slog.

+ +

And there are days when...one of the things we always start a Creative Startup's program with is find your tribe. Cling to the people who believe in you. Ignore the naysayers. The naysayers are ten to one. Blow them off and cling to the people who say, "Wow, dude, that sounds cool. I bet you could do that." Yes, do another coffee meeting with that person. [laughs]

+ +

Because sometimes you just need people who can say, "You got this. You got this. Just do another day, man." What do you guys do? Let me ask, what do you guys do when things get really rocky for you? How do you guys collect that internal okay, I'm going to get back in the saddle.

+ +

CHAD: I've talked about this with people before, and I actually think that this is going to be a non-answer, but I'll do my best. I actually don't know exactly what does this for me. But I do know a side effect is I also don't celebrate the wins as much as other people wish that I did. And I think it's because I just move on very quickly from things. I don't dwell on the downs as much. I also don't dwell on the highs as much. And so I don't know if it's just something about me that does it or I just trained myself to do that. But it does have some downsides to it.

+ +

ALICE: That was a real answer. That wasn't a non-answer at all.

+ +

CHAD: [laughs]

+ +

ALICE: Victoria, what about you?

+ +

VICTORIA: I think to add on to what Chad said is kind of that thoughtbot mentality of viewing things as an experiment. And so if you come in with that mentality, like, this is the experiment. We'll see if it works or it doesn't. And if it doesn't work, there are some lessons to be learned, and we can grow from that and do better next time. And if it does work, great; [chuckles] this is cool.

+ +

And I actually like to celebrate the wins a lot. I like to really dwell in those moments and feel like we did something right. We should remember this and learn from that as well and then try to repeat it, right?

+ +

ALICE: Yeah. Oh, I love that.

+ +

CHAD: You mentioned that when you were first starting Creative Startups, you hoped to get one win, and you did. Which one was it?

+ +

ALICE: To be clear, as a mom, we don't have favorite children, okay? [laughter] And there are different companies that have had enormous impact in different ways, so let me tick some off. Let me name first Etkie. It's a design company built by a woman named Sydney, who grew up in rural New Mexico with a passion for working with indigenous communities.

+ +

Her design company makes spectacular handmade bracelets, average price point around 250 bucks. And she sells in about 100 different high-end galleries around the world. She creates 40 jobs for Navajo women on the reservation at twice the annual pay that they would receive if they worked any other job there. Pretty astounding, pretty astounding.

+ +

Those women have gone on to reinvest their money in things like rebuilding the school, putting in wells for family. The Navajo Nation lacks drinking water all over the place. So really fundamentally shifting the economic and social trajectory of that community.

+ +

She designs every single bracelet with a woman, and you'll see they're named after the women. And they just do a recollection process where the woman recalls something from her childhood, and they weave a story around that. And then, they create the bracelet design. They're beautiful, Etkie, E-T-K-I-E.

+ +

The next one I would say that has really inspired me is founded by another woman who does...now she's doing more XR AR, But they started as a virtual reality company doing films for medical providers who needed to better understand the disease experience of their patients in order to come up with not just solutions to their lived experience but actual medical procedures, and technologies, and pharmaceuticals that could shape the outcomes of that patient.

+ +

So that company is called Embodied Labs, founded by a woman named Carrie and her team out of LA. And they're now selling to hospital systems across California and increasingly in the Midwest, et cetera, changing thousands of lives.

+ +

And then the one that most people do point to us and say, "Hey, good job," is a company called Meow Wolf. We were their first investor back in 2014. They've gone on to raise upwards of $250 million. They're kind of a competitor now to Disney. So they're in the immersive art and experience realm. They had a million visitors in their Denver spot. So far this year, they've had about a million visitors in their Las Vegas spot.

+ +

They were founded here in Santa Fe, our hometown. And we didn't even know they existed. They didn't know we existed. [chuckles] The night before our application was to close, somebody wandered into a meeting they were having where they were talking about dissolving the art collective. And somebody said, "Oh before you guys make a decision, you should check out this thing." [laughs]

+ +

So in some ways, it was angels on our shoulders in that it's a homegrown company, and Santa Fe is a small city. We needed a shift here around our creative economy. And they needed somebody to believe in them. They had gone to every business support organization they could find and had been told, "Well, you're probably trying to start an arts nonprofit." And they thought, "That's not really our vision. That's not...we want to build a company. We think art is something people will pay for if it's put forward in a way that blows your mind," and Meow certainly blows your mind.

+ +

CHAD: That's really interesting. I mean, I totally get why people would say that just because...but that's like saying...when Disney was getting started [chuckles] people saying "It sounds like you're trying to create an arts nonprofit."

+ +

ALICE: Yes. And I'm guessing a lot of people did. The future happens when we're all looking backwards, and very few people are looking forwards. And so I think it's important for entrepreneurs to keep in mind you're probably just statistically talking to somebody who's looking backwards because human beings tend to do that more than they look forward.

+ +

And so better to find people early on who say, "You know, I'm not exactly sure what you're talking about because you're the expert in your startup, and I'm not. But let me ask you this, how could I be helpful?" That's the right question. If they give you an answer and they don't even know what you're talking about, you probably don't need their help.

+ +

And that's hard for entrepreneurs because there are so many doubters out there that you have to kind of keep plucking through to find the one or two people who say, "That's really interesting. That seems like it might work. How could I help?" Did you guys have somebody at thoughtbot early on who you can remember sort of said, "Huh, that's interesting. How could I help?"

+ +

CHAD: I think it was our early clients who most did that.

+ +

ALICE: Oooh, yeah.

+ +

CHAD: Because we're a consulting company, because we're an agency, finding clients who believed in us and wanted to work with us in part because they liked us was an important aspect to that. If it wasn't for those early clients, no amount of passion would have kept us going because we needed to support ourselves.

+ +

ALICE: What a great insight, honestly. I think the sort of rhetoric around passion is really abused. Because there's now this sense that, well, if you have passion, you can build a business, and that's just not true. That's not true. I hate to say it, and people are always stunned when I say it because they think that I lead Creative Startups; I must be the core passion champion.

+ +

But here's what I would say is if you have a passion for solving your client or your customers' problems, then you might have a business. [laughs] There's a huge difference there. There's a difference between well; this is what I want to make. This is what I love doing. That is not necessarily going to answer the question is anybody paying you to do that?

+ +

And I like to encourage people to think about if you have passion for doing something, you probably have a hobby. If you do stuff that people want to pay you to do, you might have a business. And crossing that bridge is an analytical and a heart-wrenching process. Because usually, what you end up with is I mostly get to do what I love to do. But I do a lot of stuff I don't want to do because that's what building a business is, just like being a parent or any other really amazing, wonderful thing in life.

+ +

Running a business is not just about doing what you love doing all day; it's mostly about doing what people want to pay you to do. And if you're doing what people want to pay you to do and you love it, that is beautiful. That is a blessed position to be in. It's rare. And you have to ask yourself very real questions and be brutally honest with yourself, or you could waste your retirement savings. You could spend a year or two away from your family before you figure that out, not to be depressing. [laughs]

+ +

But we always say from our programs we look...not from our more advanced accelerator programs, but we also provide programs that are more; how do you figure out this idea? You have this idea, or you have what we call lucky revenue. A lot of creatives get lucky revenue where their friend sees them doing something, and they go, "Man, would you do one for me?" And then somebody else wants one, and now they have lucky revenue. And they're ready to say, "I think this might be a business."

+ +

And those people we say you have three outcomes from our programs. One, you realize this is not a business. It's just not going to make any money. The business model does not pan out. Two, this might be a business if I do it differently, and now I need to figure out if I want to do it differently. And three is, yeah, I'm on track. Now I got to go grow it. And all three are valid outcomes.

+ +

Because we've worked with people who came to us late, took out a loan. And we said, "Well, what's your plan for paying it back?" "Well, we don't know." That's bad. That's really dangerous. That can ruin families' economic futures. And so we're much happier to catch people before that happens so they can ask those critical questions about is this really a market opportunity? Is this a business I want to build? Is this, therefore, a business opportunity for me? And those questions are deceptively simple.

+ +

In our more advanced programs, we focus on, okay, you've got revenue, you've got traction. You're ready to start maybe thinking about what's the next three years? Where are your cash flow gaps? Where's your, as people like to call it, the valley of death that you have to cross as you grow? What kind of financing can you go raise to help cross that valley? How do you get to 10 million in revenue, 50 million in revenue? People are at different stages of growing a business.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

CHAD: How much judgment do you pass as an investor as people who are reading applications about who gets into the accelerator program? How much judgment do you pass, and how do you strike that balance?

+ +

ALICE: That's kind of a peek behind the curtain; how do people really pick companies? Different people do it differently. For us, we really hue toward weird and wonderful. We actually prefer...and this goes against what people say you should do, [laughs] but we kind of go against the grain in general. And it's worked out.

+ +

We prefer to look at things that we don't totally understand partly because often creatives don't speak business speak. So I'm pretty turned off by (I'm going to make something up.) the Harvard Business School grad who has a music-sharing platform and doesn't play music. I'm like, how would you know about a music-sharing platform?

+ +

Whereas a musician who comes with their garage band and they happen to have a computer science degree from the college down the road and they've invented this thing and all of a sudden, it's taking off, and they're not even sure why. I'm listening, and I'm like, oh, that's really interesting.

+ +

A lot of creatives tend to pick up on opportunities in the market, and they don't frame it so much as a business opportunity because that's just not the language that they've learned to speak yet. But they have an insight into a particular sector or a need that people who are not really in that space...

+ +

It feels like a lot of the startup world has been overtaken by people who want to be startup founders but don't necessarily have their hands dirty in a particular sector where they know how to really solve a problem that either a lot of people have, or that very few people have but that a lot of people have in the future if you build the market. And that's where you make a lot of money is if you build a market. So we look for things like that.

+ +

So what does that mean when we're reading applications? We don't ask for financial statements. We ask, how much money did you make last year, and where do you think most of that money came from? We're more interested in are they interested in analyzing their business so they understand where growth could come from next? Instead of, what is your financial statements?

+ +

Most of the entrepreneurs who come through our programs don't have financial statements. They might not even have a cash flow projection, which is really exciting. We have entrepreneurs who come to us who...I'll tell you a story. We had an entrepreneur come to us who ran underground music clubs in old houses in Denver. And he was like, "I think this is a business, but I don't know anything about business. I just started hosting these a few years ago."

+ +

And I said, "Well, how many people...like, if you took an average year..." and I said, "You don't charge anything?" And he said, "No, people just hear about it." And I'm thinking, okay, so you get a couple thousand. "How many people in an average year come to your basement music club thing?" "50,000." [laughs] Yeah, I think you might have a business.

+ +

I mean, those are the kinds of things that you think, wow, why did that take off? What is going on there? That's really interesting. Let's talk. And he had a mohawk. He played in a metal band. Business was not his deal. And so that wasn't the lens he was applying.

+ +

I think a lot of designers and a lot of people who invent products and solutions start with; I'm doing this for myself, wouldn't this be rad? Without even knowing that, they touched a nerve in the market that now is kind of catching on fire. Those are really exciting entrepreneurs for us to work with.

+ +

They do have to turn a corner on I'm building a business now. I'm not just doing something that's cool with my friends. And that can be a difficult place because it means you have to cross a bridge into the world of finance, and you're probably going to have to hire product managers. And now you go hire that Harvard Business School grad and they work for you.

+ +

And a lot of people frankly don't want to turn that corner. And I get it because when you come back to that topic of, is this values-aligned? A lot of that world is not yet totally values-aligned. That's shifting, more impact investors, more investors who want to see more different types of people starting companies, but we're not there yet.

+ +

And so there's this cultural clash. When creatives walk toward that space, they go, ew, I've been fighting against the man my whole life. And now you want me to get in the car and go on a long road trip with them? No thanks. [laughs] And I'm sitting there with the Doritos going, yeah, man, but I got all the good munchies, let's go. It often does work out. But I also understand why people say, "You know, that's just not my deal now."

+ +

VICTORIA: Yeah. And you have a tremendous amount of diversity in your alumni.

+ +

ALICE: We do, yeah.

+ +

VICTORIA: And so do you find that there are some challenges in bringing in that group to the rest of the accelerator world?

+ +

ALICE: Yeah, you know, funny, I was thinking about that yesterday. So about 70% of our alumni, and this has been true across the board from day one, are people of color or women. At one point, it was around 30% were women of color. I haven't looked at that number in a while. We've worked with about 550 companies worldwide.

+ +

In the Middle East, half of our alumni are women-led companies. In the U.S., we are fortunate to be able to work with a lot of indigenous communities. New Mexico is home to a large indigenous population. And it's a lot of the reason our culture is so dynamic and beautiful.

+ +

So for us, that was always a no-brainer that that was where a lot of the interesting creativity would come from and that that was where the rising markets were. We, for example, accelerated and were the first investor in a company called Native Realities, which is a comic book. And they founded the first indigenous Comic Con, which is now called Indigenous Pop X worldwide.

+ +

And they saw obviously before even Black Panther, and it became kind of like people said, "Oh yeah, superheroes come from all communities." They saw that that market was rising. There are 300 million indigenous people worldwide. There are two comic book companies. Let that sink in. [laughs] It's like, oh my God, what is the possibility then not just around comic books, but gaming, animation, all kinds of creative tools, film, music? That's a huge market that has not been served at all.

+ +

And we understood early on that that was an area where people want to tell their own stories. People want to understand the stories of other people. And then people want to build new stories together across those cultural or geographic boundaries. And the technology had shifted such that that was possible.

+ +

In 1980, that wasn't really possible. The distribution channels of film were such that you had to raise money in Hollywood and have Tom Hanks and whatever. That's just not true anymore. So we saw that early on, and that has helped attract a lot of entrepreneurs who share our passion for really telling those stories.

+ +

However, I would say for people who want to support rising entrepreneurs out of what I'm going to call distressed communities or communities that have been literally discouraged from becoming their own economic leaders is that the burden that most of the people bear who are building businesses, for example, from Black communities, or native communities, or women in the Middle East, those people tend to bear a larger burden than someone from a more privileged background like myself.

+ +

They're often the person in their family and for their community who is helping to ensure that people get the health care they need, that that kid was able to visit the college that they wanted to apply to. They become that sort of anchor of support for more people than in situations where we have more support and more what I call margin. They have really little margin.

+ +

And so to ask them to, for example, join an accelerator full-time for 12 weeks that just doesn't work. Because the decision that they're making, you know, from a very privileged position, we can say, "Well, either you're dedicated to your business, or you're not." But really, what we're saying to them is, well, either you do your business, or you love your family and your culture. That's the question we're asking them, and that's a totally unfair question. That's a ridiculous question. Every single one of us would say, "I love my family. Thanks, see ya."

+ +

CHAD: So how do you balance that?

+ +

ALICE: Well, it's tough. I mean, first of all, we have adopted in the programs where it's more for early-stage entrepreneurs, and we're opening doors to entrepreneurship. And we are being first and foremost patient, patient with they're crossing that threshold.

+ +

We understand that our core outcome is that people come always saying, "I'm an entrepreneur. I'm ready for the journey." That means we do things like, first of all, we do all online. If possible, we do a meeting upfront, so everybody meets each other in person because that kind of sets a tone of just it's a lot of fun. We have food and drink, and we have a good time. And then we do 6 to 12 weeks online, and then we do a gathering at the end. And we build a community first and foremost of people who are understanding how they can help one another.

+ +

So Creative Startups is a little different in how we do accelerators. We do not ever have people stand at the front of the room and tell people what they should do with their business partly because we're educators first and foremost, and we understand...I have a Ph.D. in entrepreneurship. I understand that entrepreneurs tend to be experiential learners, not all but many.

+ +

And we're not going to be there in a year building their business. They're going to be building their business. We have to build their self-confidence. We have to build their ability to say, "I know how to row the boat. You're along for the ride." I'm just along for the ride. [laughs]

+ +

That requires us to do things like, okay, so let's work on your business model and really carefully chunk out here's one piece of that. Let's go deeply into understanding that. Let's tackle the vocabulary. Let's look at how people talk about it online. Let's open that door culturally so that you can take that into your experiences and say, "Oh, I already kind of do that. I just use a different language," which is what a lot of designers do.

+ +

A lot of designers, whatever your background, already do entrepreneurial processes. They use different language, and it's just a translation. It's literally just vocabulary. So we help people understand that the best way to figure out your client's needs are by listening; all people know that. If you want to understand someone else, listen, and unpacking that into then business speak a little bit, and then giving them opportunities to go do that in the real world.

+ +

And being patient with how they might do that or why they couldn't get it done this week. Or maybe they want to come back with a different way of describing it than maybe a White person like me might describe what they experienced. And just giving a lot of latitude to people to have that own experience themselves.

+ +

That honestly...I know that sounds very philosophical. But it breaks down into tactical things that we do in an accelerator that opens the door to a lot more entrepreneurs. And our Net Promoter Score is 9. Over 90% of people would recommend our program. People love our programs. And 70% of our alumni are still in business. So I think it's working. We have a lot of learning to do. We're doing an indigenous accelerator right now, and it's a lot of learning for me. It's very eye-opening.

+ +

CHAD: As an accelerator specific to indigenous peoples, what made you decide to do that? Some people I know, thoughtbot included, sometimes hesitate to do things like that because we don't want...there's some hesitation around doing something like that.

+ +

ALICE: So we share all of those hesitations, and we think they're spot on. We are doing this in partnership with a group called Creative Nations out of Colorado. They are all indigenous people. They're a new group. And we envision Creative Startups moving more toward a place of being kind of like the intel, you know, the old intel inside. We are inside, and we're an engine within another organization.

+ +

So here in Santa Fe, we partnered with Vital Spaces, which serves Black and Brown creative entrepreneurs and artists. And our goal is to help build their capacity to be able to keep doing programs as they see fit for entrepreneurs. And we're standing by as they would like us to help. So we took that same approach with working with Creative Nations. It's been a fantastic partnership.

+ +

The lead working with us is a woman named Kelly Holmes. She is Lakota Sioux. She's from the Cheyenne River Reservation. And she founded Native Max Media, which publishes Native Max Magazine, the world's first fashion magazine for indigenous entrepreneurs. She is a brilliant, creative entrepreneur. She is self-taught. She eked it out. She has been around ten years now. It's astounding.

+ +

And you see the magazine, and it's spectacular. It is high glamour, beautiful. And it is reshaping the way not only indigenous people see themselves but how White people see indigenous people. And those reframed stories are so important to building a more equitable society. So I was over the moon to partner with her. Then I learned her mom is one of the few Lakota language teachers.

+ +

So Lakota is her first language. Her mother teaches Lakota and teaches teachers how to teach Lakota. So she grew up with an educator. So she has taken to building this, again, patient, very exploratory online environment for indigenous entrepreneurs. And then I bring sometimes the more technical like, oh, you're asking a specific question about how to do structured interviews with customers. Sure, let me talk a little bit about that.

+ +

But as we started out this conversation, you guys, entrepreneurship is not an intellectual challenge usually; it's a heart challenge. I don't mean that in a way to disparage how important it is to be really strategic and smart about your business. But I think at the outset especially, you just have to be able to hang in there and keep doing it. And then, as you grow into that opportunity, you start to see that the intellectual challenges unfold because your opportunities become more complex.

+ +

But at this outset with Kelly, it's been a conversation with people who are frankly reframing themselves as business leaders, people who own businesses and have employees based on their creative output. And that's a really exciting space to work in. We wouldn't work in this space if we didn't have a partner who shared our vision and who wanted to be that native leader of a program like this. It just wouldn't really feel exciting.

+ +

CHAD: I think that that's great advice and a framing that helps me think about the things that we've tried to do in the past and the things that we hope to do in the future and realizing that really genuinely partnering with someone in the actual community that we're trying to serve or to have an impact with is sometimes an important missing component that we need to incorporate. That'll help solve a lot of the hesitations that we might have around doing something.

+ +

ALICE: Yeah, yeah.

+ +

VICTORIA: Right. And we've all heard before that culture eats strategy for breakfast, which I think -- [laughs]

+ +

ALICE: That's my favorite line, Victoria. You nailed it.

+ +

VICTORIA: It makes sense that the more connected you are to your culture and to your community, that's where you'll be the most successful when your heart is in it.

+ +

ALICE: Yeah. And I want to give sort of a plug for stepping outside of the zone of the way...I went to business school. I have an MBA. I'm really well-versed in that whole world. I'm married to a venture capitalist. He teaches how to do venture capital at Stanford. That whole world is very familiar to me. And it seems to not be helping us solve the problems that we have now as a society.

+ +

And so one of the reasons I encourage people to go to those partners, go to those places where you're like, I don't fit in here; I don't understand what's going on here; these people speak a different cultural language, form, way of doing things, I encourage that because I think that for people who want to build a different world, we have to stop looking to the world that we already have. And we have to say, "Well, who does things differently? What could we learn?"

+ +

One of the most beautiful things about working with the entrepreneurs in the cohort right now, the indigenous cohort, is they first talk about taking care of their people, that's first. And it's like, wow, if that's your entire frame, you start to make really different decisions in business. If you're talking about well, I want to take care of the people in my community; I want people to be healthy and happy and be able to pursue their own dreams; that's a really different frame of mind for a baseline for decision making.

+ +

The other thing that Kelly talks about that I love (I'm stealing it from her.) is she talks about fighting for her business, fighting for her business. And that, to me, is such a great way to feel like, okay, if I'm fighting for my business, I know how much Creative Startups has achieved. I'm not fighting for myself. It's not my ego. It's none of that. It's fighting for my business so my business can keep having the impact.

+ +

Everything that I think about now in terms of working with indigenous entrepreneurs is this has nothing to do with me. Their frame is very much my community, my people, my business, which is over there. And it's a humble way of understanding one's place. And that is a really exciting reframe for me to think about how we can solve problems like the climate crisis, like the disparity between rich and poor, like the disintegration of our democracy. What if we had a different frame? How could we solve problems differently, maybe better?

+ +

So for us, these partnerships unlock a whole vast area of new thinking, new ways of doing business, new ways of taking care of other people. And at the end of the day, that's what gets me back in the rowboat [laughs] is this idea of, wow, we are having an impact on other people. And doing it with people who have a different starting point has really shaped a lot of the work that we do.

+ +

CHAD: Well, I'm sorry that we have to wrap up. Otherwise, we could keep on going and solve the climate crisis and unraveling of our democracy, but -- [laughs]

+ +

ALICE: Yeah, I have an appointment at 2:00 where I'm doing climate crisis. So I'll let you know how it goes.

+ +

CHAD: Okay, wonderful.

+ +

ALICE: [laughs]

+ +

CHAD: Alice, thank you so much for joining the show and sharing everything with us. We really appreciate it.

+ +

ALICE: Yeah, I was delighted to be with you guys and hope to continue the conversation.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

VICTORIA: And if you have questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Twitter at @cpytel.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Alice Loy.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Alice Loy is a Founding Partner at DaVinci Ventures and the Co-Founder and CEO of Creative Startups, the leading global startup accelerator and company builder for design, food, immersive, and creative companies.

+ +

Victoria and Chad talk with Alice about what she means by creative companies, how much judgment she must pass as an investor with a love for the "weird and wonderful," and some of the challenges faced in bringing diversity to the rest of the accelerator world.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Alice Loy, Founding Partner at DaVinci Ventures and the Co-Founder and CEO of Creative Startups, the leading global startup accelerator and company builder for design, food, immersive, and creative companies.

+ +

CHAD: Alice, thank you so much for joining us.

+ +

ALICE: Thanks for having me.

+ +

CHAD: Can you tell us a little bit more about Creative Startups in general but also what you mean by creative companies specifically? Like, isn't every company creative? [laughs]

+ +

ALICE: Yeah, it's so funny. That's often the first question. And sometimes people I can feel their sense of indignation in thinking maybe I think they're not creative.

+ +

CHAD: [laughs]

+ +

ALICE: First of all, the creative industries are pretty well defined globally by the World Bank and entities like that. I'll come back to that. Yes, all human beings are creative. I like to joke that that's what got us out of caves in the first place. But more importantly, all entrepreneurs are very creative regardless of what sector you're operating in.

+ +

So when we're talking about creative, we're just referencing the set of industries that are measured as the quote, "creative industries." They include film, our museums, design certainly is a core element of that. Increasingly, we're seeing more and more people move toward the creative industries as mechanized labor takes over things like building cars or even running data analysis.

+ +

CHAD: Has getting support and funding and that kind of thing traditionally been easy in the creative space or hard?

+ +

ALICE: No. I know you know the answer to that question because you're a designer. [laughs]

+ +

CHAD: I usually don't ask questions that I don't know the answers to, so... [laughs]

+ +

ALICE: But it's a great question because actually what it uncovers, you guys, is that it has changed dramatically for people who I call creatives or creators in the last two or three years. It's a little tough to measure with the pandemic, but we know at least $2 billion have gone into platforms that support creators, businesses led by creators. The creative industry has really turned a corner.

+ +

So when we started this work 15-16 years ago, I co-founded the organization with a gentleman named Tom, who is now in his 80s. But he had come out of what's called the cultural economy, which was the precursor to the creative economy. And, of course, now we're all living in the creator economy. So like every other industry, it evolves. And one turn in this evolution is that creatives are now understood as economic drivers, not just people who add nice flourishes to things at the end.

+ +

When you're building new products, people think about engineers, but it's really a creative process. And people increasingly bring in creatives from the outset to think about how the design process can be more humanized, can be more effective to solve people's problems so that your products really delight customers instead of just get the job done.

+ +

CHAD: Is there something you can point to that triggered or pushed along that turning point?

+ +

ALICE: Well, not to be overly philosophical, but I would say the general sense in the U.S. and increasingly in other countries where we work is that human beings don't want to be cogs in a wheel. They don't want to just be bit parts in a system. When you talk to Gen Zers, they understand that they are complete human beings. And somehow, I think older generations bought into the idea that you have the same job for 40 years. You go to work at 8:00; you come home at 5:00. You repeat the next day.

+ +

I think the sense in the economy is that people want to be fulfilled. If they're going to give that much time to a job, they want it to be meaningful and valuable. And they want it to solve some of the big problems. Frankly, big tech is not approaching the world in that way these days. And so I think younger people are looking for values-aligned opportunities.

+ +

And the creative economy is a space where values tend to align with really reaching the full potential of each human being instead of just extracting their physical and occasionally mental labor toward building a capitalist system. And so I think that zeitgeist has helped open the door.

+ +

I also then think when you look at the kinds of technologies that are being utilized, they're still fundamentally about communicating ideas, and art, and inspiration. That's what Facebook is. That's what TikTok is. That's what even news channels are. And as more people come into the world of saying, "Oh, I can share my ideas, my art, my jokes, my music, my whatever," they see themselves as creatives, and they go, "I wonder how I could get paid for that?" I mean, there are a multitude of factors weaving together to shift.

+ +

I also think, quite frankly, the SaaS investment area has become so saturated. I mean, if you walk down the street in San Francisco, if you don't bump into three venture capitalists who are SaaS investors, it's like, what are you doing? And so I think other types of investors with a different background maybe are saying, hmm, what about this area over here? How could we make money? So that would be another thread I would say is helping drive.

+ +

CHAD: It strikes me that what you've shared sort of creates a self-fulfilling cycle too.

+ +

ALICE: Yes.

+ +

CHAD: Because once creatives have examples of other creatives that have done this, it becomes an aspirational thing that they understand that they, too, could do themselves.

+ +

ALICE: Yeah, 100%. So our goal when we started the startup accelerator...we launched the first accelerator for creative founders in 2013 in the world. And we said to ourselves, if we get one company that becomes the poster child for this creative movement and demonstrating that you can be, as we like to say, weird and wonderful and build a company, then we will unleash a flood of people who now see themselves in that light.

+ +

We were very fortunate in that we got that one poster child, and that has really helped us paint a picture that's clear for a lot of people where they see themselves as entrepreneurs, even though they're a tattoo artist or they're a hard rock Navajo metal band from the reservation or whatever their background is. Now they look and go, "Oh yeah, I could do that," and they certainly could. Being an entrepreneur is really hard but not intellectually challenging; it's more heart-challenging.

+ +

CHAD: Oh, that's really interesting, more heart challenging.

+ +

ALICE: Yeah. I mean, you're an entrepreneur. You guys have built a business, so you know that being an entrepreneur is more about being able to just sort of stay calm in the waves than it is about building the world's best boat and being able to steer toward that destination no matter how the winds blow.

+ +

CHAD: Yeah, I've often referred to it almost as grit, like the ability to, no matter what happened yesterday, get up and do it again.

+ +

ALICE: Get up, yeah. And unfortunately, I think there's a myth, maybe at least in the U.S., that what drives most people to get up and go, again, is money. And I don't think that's true at all. I think what drives people to get up and go again is their love of customers or end users. And their feeling they're just irrefutable despite there being no evidence feeling that this is going to work. This is going to make a difference in people's lives. And that's why the sort of slog.

+ +

And there are days when...one of the things we always start a Creative Startup's program with is find your tribe. Cling to the people who believe in you. Ignore the naysayers. The naysayers are ten to one. Blow them off and cling to the people who say, "Wow, dude, that sounds cool. I bet you could do that." Yes, do another coffee meeting with that person. [laughs]

+ +

Because sometimes you just need people who can say, "You got this. You got this. Just do another day, man." What do you guys do? Let me ask, what do you guys do when things get really rocky for you? How do you guys collect that internal okay, I'm going to get back in the saddle.

+ +

CHAD: I've talked about this with people before, and I actually think that this is going to be a non-answer, but I'll do my best. I actually don't know exactly what does this for me. But I do know a side effect is I also don't celebrate the wins as much as other people wish that I did. And I think it's because I just move on very quickly from things. I don't dwell on the downs as much. I also don't dwell on the highs as much. And so I don't know if it's just something about me that does it or I just trained myself to do that. But it does have some downsides to it.

+ +

ALICE: That was a real answer. That wasn't a non-answer at all.

+ +

CHAD: [laughs]

+ +

ALICE: Victoria, what about you?

+ +

VICTORIA: I think to add on to what Chad said is kind of that thoughtbot mentality of viewing things as an experiment. And so if you come in with that mentality, like, this is the experiment. We'll see if it works or it doesn't. And if it doesn't work, there are some lessons to be learned, and we can grow from that and do better next time. And if it does work, great; [chuckles] this is cool.

+ +

And I actually like to celebrate the wins a lot. I like to really dwell in those moments and feel like we did something right. We should remember this and learn from that as well and then try to repeat it, right?

+ +

ALICE: Yeah. Oh, I love that.

+ +

CHAD: You mentioned that when you were first starting Creative Startups, you hoped to get one win, and you did. Which one was it?

+ +

ALICE: To be clear, as a mom, we don't have favorite children, okay? [laughter] And there are different companies that have had enormous impact in different ways, so let me tick some off. Let me name first Etkie. It's a design company built by a woman named Sydney, who grew up in rural New Mexico with a passion for working with indigenous communities.

+ +

Her design company makes spectacular handmade bracelets, average price point around 250 bucks. And she sells in about 100 different high-end galleries around the world. She creates 40 jobs for Navajo women on the reservation at twice the annual pay that they would receive if they worked any other job there. Pretty astounding, pretty astounding.

+ +

Those women have gone on to reinvest their money in things like rebuilding the school, putting in wells for family. The Navajo Nation lacks drinking water all over the place. So really fundamentally shifting the economic and social trajectory of that community.

+ +

She designs every single bracelet with a woman, and you'll see they're named after the women. And they just do a recollection process where the woman recalls something from her childhood, and they weave a story around that. And then, they create the bracelet design. They're beautiful, Etkie, E-T-K-I-E.

+ +

The next one I would say that has really inspired me is founded by another woman who does...now she's doing more XR AR, But they started as a virtual reality company doing films for medical providers who needed to better understand the disease experience of their patients in order to come up with not just solutions to their lived experience but actual medical procedures, and technologies, and pharmaceuticals that could shape the outcomes of that patient.

+ +

So that company is called Embodied Labs, founded by a woman named Carrie and her team out of LA. And they're now selling to hospital systems across California and increasingly in the Midwest, et cetera, changing thousands of lives.

+ +

And then the one that most people do point to us and say, "Hey, good job," is a company called Meow Wolf. We were their first investor back in 2014. They've gone on to raise upwards of $250 million. They're kind of a competitor now to Disney. So they're in the immersive art and experience realm. They had a million visitors in their Denver spot. So far this year, they've had about a million visitors in their Las Vegas spot.

+ +

They were founded here in Santa Fe, our hometown. And we didn't even know they existed. They didn't know we existed. [chuckles] The night before our application was to close, somebody wandered into a meeting they were having where they were talking about dissolving the art collective. And somebody said, "Oh before you guys make a decision, you should check out this thing." [laughs]

+ +

So in some ways, it was angels on our shoulders in that it's a homegrown company, and Santa Fe is a small city. We needed a shift here around our creative economy. And they needed somebody to believe in them. They had gone to every business support organization they could find and had been told, "Well, you're probably trying to start an arts nonprofit." And they thought, "That's not really our vision. That's not...we want to build a company. We think art is something people will pay for if it's put forward in a way that blows your mind," and Meow certainly blows your mind.

+ +

CHAD: That's really interesting. I mean, I totally get why people would say that just because...but that's like saying...when Disney was getting started [chuckles] people saying "It sounds like you're trying to create an arts nonprofit."

+ +

ALICE: Yes. And I'm guessing a lot of people did. The future happens when we're all looking backwards, and very few people are looking forwards. And so I think it's important for entrepreneurs to keep in mind you're probably just statistically talking to somebody who's looking backwards because human beings tend to do that more than they look forward.

+ +

And so better to find people early on who say, "You know, I'm not exactly sure what you're talking about because you're the expert in your startup, and I'm not. But let me ask you this, how could I be helpful?" That's the right question. If they give you an answer and they don't even know what you're talking about, you probably don't need their help.

+ +

And that's hard for entrepreneurs because there are so many doubters out there that you have to kind of keep plucking through to find the one or two people who say, "That's really interesting. That seems like it might work. How could I help?" Did you guys have somebody at thoughtbot early on who you can remember sort of said, "Huh, that's interesting. How could I help?"

+ +

CHAD: I think it was our early clients who most did that.

+ +

ALICE: Oooh, yeah.

+ +

CHAD: Because we're a consulting company, because we're an agency, finding clients who believed in us and wanted to work with us in part because they liked us was an important aspect to that. If it wasn't for those early clients, no amount of passion would have kept us going because we needed to support ourselves.

+ +

ALICE: What a great insight, honestly. I think the sort of rhetoric around passion is really abused. Because there's now this sense that, well, if you have passion, you can build a business, and that's just not true. That's not true. I hate to say it, and people are always stunned when I say it because they think that I lead Creative Startups; I must be the core passion champion.

+ +

But here's what I would say is if you have a passion for solving your client or your customers' problems, then you might have a business. [laughs] There's a huge difference there. There's a difference between well; this is what I want to make. This is what I love doing. That is not necessarily going to answer the question is anybody paying you to do that?

+ +

And I like to encourage people to think about if you have passion for doing something, you probably have a hobby. If you do stuff that people want to pay you to do, you might have a business. And crossing that bridge is an analytical and a heart-wrenching process. Because usually, what you end up with is I mostly get to do what I love to do. But I do a lot of stuff I don't want to do because that's what building a business is, just like being a parent or any other really amazing, wonderful thing in life.

+ +

Running a business is not just about doing what you love doing all day; it's mostly about doing what people want to pay you to do. And if you're doing what people want to pay you to do and you love it, that is beautiful. That is a blessed position to be in. It's rare. And you have to ask yourself very real questions and be brutally honest with yourself, or you could waste your retirement savings. You could spend a year or two away from your family before you figure that out, not to be depressing. [laughs]

+ +

But we always say from our programs we look...not from our more advanced accelerator programs, but we also provide programs that are more; how do you figure out this idea? You have this idea, or you have what we call lucky revenue. A lot of creatives get lucky revenue where their friend sees them doing something, and they go, "Man, would you do one for me?" And then somebody else wants one, and now they have lucky revenue. And they're ready to say, "I think this might be a business."

+ +

And those people we say you have three outcomes from our programs. One, you realize this is not a business. It's just not going to make any money. The business model does not pan out. Two, this might be a business if I do it differently, and now I need to figure out if I want to do it differently. And three is, yeah, I'm on track. Now I got to go grow it. And all three are valid outcomes.

+ +

Because we've worked with people who came to us late, took out a loan. And we said, "Well, what's your plan for paying it back?" "Well, we don't know." That's bad. That's really dangerous. That can ruin families' economic futures. And so we're much happier to catch people before that happens so they can ask those critical questions about is this really a market opportunity? Is this a business I want to build? Is this, therefore, a business opportunity for me? And those questions are deceptively simple.

+ +

In our more advanced programs, we focus on, okay, you've got revenue, you've got traction. You're ready to start maybe thinking about what's the next three years? Where are your cash flow gaps? Where's your, as people like to call it, the valley of death that you have to cross as you grow? What kind of financing can you go raise to help cross that valley? How do you get to 10 million in revenue, 50 million in revenue? People are at different stages of growing a business.

+ +

MID-ROLL AD:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs.

+ +

CHAD: How much judgment do you pass as an investor as people who are reading applications about who gets into the accelerator program? How much judgment do you pass, and how do you strike that balance?

+ +

ALICE: That's kind of a peek behind the curtain; how do people really pick companies? Different people do it differently. For us, we really hue toward weird and wonderful. We actually prefer...and this goes against what people say you should do, [laughs] but we kind of go against the grain in general. And it's worked out.

+ +

We prefer to look at things that we don't totally understand partly because often creatives don't speak business speak. So I'm pretty turned off by (I'm going to make something up.) the Harvard Business School grad who has a music-sharing platform and doesn't play music. I'm like, how would you know about a music-sharing platform?

+ +

Whereas a musician who comes with their garage band and they happen to have a computer science degree from the college down the road and they've invented this thing and all of a sudden, it's taking off, and they're not even sure why. I'm listening, and I'm like, oh, that's really interesting.

+ +

A lot of creatives tend to pick up on opportunities in the market, and they don't frame it so much as a business opportunity because that's just not the language that they've learned to speak yet. But they have an insight into a particular sector or a need that people who are not really in that space...

+ +

It feels like a lot of the startup world has been overtaken by people who want to be startup founders but don't necessarily have their hands dirty in a particular sector where they know how to really solve a problem that either a lot of people have, or that very few people have but that a lot of people have in the future if you build the market. And that's where you make a lot of money is if you build a market. So we look for things like that.

+ +

So what does that mean when we're reading applications? We don't ask for financial statements. We ask, how much money did you make last year, and where do you think most of that money came from? We're more interested in are they interested in analyzing their business so they understand where growth could come from next? Instead of, what is your financial statements?

+ +

Most of the entrepreneurs who come through our programs don't have financial statements. They might not even have a cash flow projection, which is really exciting. We have entrepreneurs who come to us who...I'll tell you a story. We had an entrepreneur come to us who ran underground music clubs in old houses in Denver. And he was like, "I think this is a business, but I don't know anything about business. I just started hosting these a few years ago."

+ +

And I said, "Well, how many people...like, if you took an average year..." and I said, "You don't charge anything?" And he said, "No, people just hear about it." And I'm thinking, okay, so you get a couple thousand. "How many people in an average year come to your basement music club thing?" "50,000." [laughs] Yeah, I think you might have a business.

+ +

I mean, those are the kinds of things that you think, wow, why did that take off? What is going on there? That's really interesting. Let's talk. And he had a mohawk. He played in a metal band. Business was not his deal. And so that wasn't the lens he was applying.

+ +

I think a lot of designers and a lot of people who invent products and solutions start with; I'm doing this for myself, wouldn't this be rad? Without even knowing that, they touched a nerve in the market that now is kind of catching on fire. Those are really exciting entrepreneurs for us to work with.

+ +

They do have to turn a corner on I'm building a business now. I'm not just doing something that's cool with my friends. And that can be a difficult place because it means you have to cross a bridge into the world of finance, and you're probably going to have to hire product managers. And now you go hire that Harvard Business School grad and they work for you.

+ +

And a lot of people frankly don't want to turn that corner. And I get it because when you come back to that topic of, is this values-aligned? A lot of that world is not yet totally values-aligned. That's shifting, more impact investors, more investors who want to see more different types of people starting companies, but we're not there yet.

+ +

And so there's this cultural clash. When creatives walk toward that space, they go, ew, I've been fighting against the man my whole life. And now you want me to get in the car and go on a long road trip with them? No thanks. [laughs] And I'm sitting there with the Doritos going, yeah, man, but I got all the good munchies, let's go. It often does work out. But I also understand why people say, "You know, that's just not my deal now."

+ +

VICTORIA: Yeah. And you have a tremendous amount of diversity in your alumni.

+ +

ALICE: We do, yeah.

+ +

VICTORIA: And so do you find that there are some challenges in bringing in that group to the rest of the accelerator world?

+ +

ALICE: Yeah, you know, funny, I was thinking about that yesterday. So about 70% of our alumni, and this has been true across the board from day one, are people of color or women. At one point, it was around 30% were women of color. I haven't looked at that number in a while. We've worked with about 550 companies worldwide.

+ +

In the Middle East, half of our alumni are women-led companies. In the U.S., we are fortunate to be able to work with a lot of indigenous communities. New Mexico is home to a large indigenous population. And it's a lot of the reason our culture is so dynamic and beautiful.

+ +

So for us, that was always a no-brainer that that was where a lot of the interesting creativity would come from and that that was where the rising markets were. We, for example, accelerated and were the first investor in a company called Native Realities, which is a comic book. And they founded the first indigenous Comic Con, which is now called Indigenous Pop X worldwide.

+ +

And they saw obviously before even Black Panther, and it became kind of like people said, "Oh yeah, superheroes come from all communities." They saw that that market was rising. There are 300 million indigenous people worldwide. There are two comic book companies. Let that sink in. [laughs] It's like, oh my God, what is the possibility then not just around comic books, but gaming, animation, all kinds of creative tools, film, music? That's a huge market that has not been served at all.

+ +

And we understood early on that that was an area where people want to tell their own stories. People want to understand the stories of other people. And then people want to build new stories together across those cultural or geographic boundaries. And the technology had shifted such that that was possible.

+ +

In 1980, that wasn't really possible. The distribution channels of film were such that you had to raise money in Hollywood and have Tom Hanks and whatever. That's just not true anymore. So we saw that early on, and that has helped attract a lot of entrepreneurs who share our passion for really telling those stories.

+ +

However, I would say for people who want to support rising entrepreneurs out of what I'm going to call distressed communities or communities that have been literally discouraged from becoming their own economic leaders is that the burden that most of the people bear who are building businesses, for example, from Black communities, or native communities, or women in the Middle East, those people tend to bear a larger burden than someone from a more privileged background like myself.

+ +

They're often the person in their family and for their community who is helping to ensure that people get the health care they need, that that kid was able to visit the college that they wanted to apply to. They become that sort of anchor of support for more people than in situations where we have more support and more what I call margin. They have really little margin.

+ +

And so to ask them to, for example, join an accelerator full-time for 12 weeks that just doesn't work. Because the decision that they're making, you know, from a very privileged position, we can say, "Well, either you're dedicated to your business, or you're not." But really, what we're saying to them is, well, either you do your business, or you love your family and your culture. That's the question we're asking them, and that's a totally unfair question. That's a ridiculous question. Every single one of us would say, "I love my family. Thanks, see ya."

+ +

CHAD: So how do you balance that?

+ +

ALICE: Well, it's tough. I mean, first of all, we have adopted in the programs where it's more for early-stage entrepreneurs, and we're opening doors to entrepreneurship. And we are being first and foremost patient, patient with they're crossing that threshold.

+ +

We understand that our core outcome is that people come always saying, "I'm an entrepreneur. I'm ready for the journey." That means we do things like, first of all, we do all online. If possible, we do a meeting upfront, so everybody meets each other in person because that kind of sets a tone of just it's a lot of fun. We have food and drink, and we have a good time. And then we do 6 to 12 weeks online, and then we do a gathering at the end. And we build a community first and foremost of people who are understanding how they can help one another.

+ +

So Creative Startups is a little different in how we do accelerators. We do not ever have people stand at the front of the room and tell people what they should do with their business partly because we're educators first and foremost, and we understand...I have a Ph.D. in entrepreneurship. I understand that entrepreneurs tend to be experiential learners, not all but many.

+ +

And we're not going to be there in a year building their business. They're going to be building their business. We have to build their self-confidence. We have to build their ability to say, "I know how to row the boat. You're along for the ride." I'm just along for the ride. [laughs]

+ +

That requires us to do things like, okay, so let's work on your business model and really carefully chunk out here's one piece of that. Let's go deeply into understanding that. Let's tackle the vocabulary. Let's look at how people talk about it online. Let's open that door culturally so that you can take that into your experiences and say, "Oh, I already kind of do that. I just use a different language," which is what a lot of designers do.

+ +

A lot of designers, whatever your background, already do entrepreneurial processes. They use different language, and it's just a translation. It's literally just vocabulary. So we help people understand that the best way to figure out your client's needs are by listening; all people know that. If you want to understand someone else, listen, and unpacking that into then business speak a little bit, and then giving them opportunities to go do that in the real world.

+ +

And being patient with how they might do that or why they couldn't get it done this week. Or maybe they want to come back with a different way of describing it than maybe a White person like me might describe what they experienced. And just giving a lot of latitude to people to have that own experience themselves.

+ +

That honestly...I know that sounds very philosophical. But it breaks down into tactical things that we do in an accelerator that opens the door to a lot more entrepreneurs. And our Net Promoter Score is 9. Over 90% of people would recommend our program. People love our programs. And 70% of our alumni are still in business. So I think it's working. We have a lot of learning to do. We're doing an indigenous accelerator right now, and it's a lot of learning for me. It's very eye-opening.

+ +

CHAD: As an accelerator specific to indigenous peoples, what made you decide to do that? Some people I know, thoughtbot included, sometimes hesitate to do things like that because we don't want...there's some hesitation around doing something like that.

+ +

ALICE: So we share all of those hesitations, and we think they're spot on. We are doing this in partnership with a group called Creative Nations out of Colorado. They are all indigenous people. They're a new group. And we envision Creative Startups moving more toward a place of being kind of like the intel, you know, the old intel inside. We are inside, and we're an engine within another organization.

+ +

So here in Santa Fe, we partnered with Vital Spaces, which serves Black and Brown creative entrepreneurs and artists. And our goal is to help build their capacity to be able to keep doing programs as they see fit for entrepreneurs. And we're standing by as they would like us to help. So we took that same approach with working with Creative Nations. It's been a fantastic partnership.

+ +

The lead working with us is a woman named Kelly Holmes. She is Lakota Sioux. She's from the Cheyenne River Reservation. And she founded Native Max Media, which publishes Native Max Magazine, the world's first fashion magazine for indigenous entrepreneurs. She is a brilliant, creative entrepreneur. She is self-taught. She eked it out. She has been around ten years now. It's astounding.

+ +

And you see the magazine, and it's spectacular. It is high glamour, beautiful. And it is reshaping the way not only indigenous people see themselves but how White people see indigenous people. And those reframed stories are so important to building a more equitable society. So I was over the moon to partner with her. Then I learned her mom is one of the few Lakota language teachers.

+ +

So Lakota is her first language. Her mother teaches Lakota and teaches teachers how to teach Lakota. So she grew up with an educator. So she has taken to building this, again, patient, very exploratory online environment for indigenous entrepreneurs. And then I bring sometimes the more technical like, oh, you're asking a specific question about how to do structured interviews with customers. Sure, let me talk a little bit about that.

+ +

But as we started out this conversation, you guys, entrepreneurship is not an intellectual challenge usually; it's a heart challenge. I don't mean that in a way to disparage how important it is to be really strategic and smart about your business. But I think at the outset especially, you just have to be able to hang in there and keep doing it. And then, as you grow into that opportunity, you start to see that the intellectual challenges unfold because your opportunities become more complex.

+ +

But at this outset with Kelly, it's been a conversation with people who are frankly reframing themselves as business leaders, people who own businesses and have employees based on their creative output. And that's a really exciting space to work in. We wouldn't work in this space if we didn't have a partner who shared our vision and who wanted to be that native leader of a program like this. It just wouldn't really feel exciting.

+ +

CHAD: I think that that's great advice and a framing that helps me think about the things that we've tried to do in the past and the things that we hope to do in the future and realizing that really genuinely partnering with someone in the actual community that we're trying to serve or to have an impact with is sometimes an important missing component that we need to incorporate. That'll help solve a lot of the hesitations that we might have around doing something.

+ +

ALICE: Yeah, yeah.

+ +

VICTORIA: Right. And we've all heard before that culture eats strategy for breakfast, which I think -- [laughs]

+ +

ALICE: That's my favorite line, Victoria. You nailed it.

+ +

VICTORIA: It makes sense that the more connected you are to your culture and to your community, that's where you'll be the most successful when your heart is in it.

+ +

ALICE: Yeah. And I want to give sort of a plug for stepping outside of the zone of the way...I went to business school. I have an MBA. I'm really well-versed in that whole world. I'm married to a venture capitalist. He teaches how to do venture capital at Stanford. That whole world is very familiar to me. And it seems to not be helping us solve the problems that we have now as a society.

+ +

And so one of the reasons I encourage people to go to those partners, go to those places where you're like, I don't fit in here; I don't understand what's going on here; these people speak a different cultural language, form, way of doing things, I encourage that because I think that for people who want to build a different world, we have to stop looking to the world that we already have. And we have to say, "Well, who does things differently? What could we learn?"

+ +

One of the most beautiful things about working with the entrepreneurs in the cohort right now, the indigenous cohort, is they first talk about taking care of their people, that's first. And it's like, wow, if that's your entire frame, you start to make really different decisions in business. If you're talking about well, I want to take care of the people in my community; I want people to be healthy and happy and be able to pursue their own dreams; that's a really different frame of mind for a baseline for decision making.

+ +

The other thing that Kelly talks about that I love (I'm stealing it from her.) is she talks about fighting for her business, fighting for her business. And that, to me, is such a great way to feel like, okay, if I'm fighting for my business, I know how much Creative Startups has achieved. I'm not fighting for myself. It's not my ego. It's none of that. It's fighting for my business so my business can keep having the impact.

+ +

Everything that I think about now in terms of working with indigenous entrepreneurs is this has nothing to do with me. Their frame is very much my community, my people, my business, which is over there. And it's a humble way of understanding one's place. And that is a really exciting reframe for me to think about how we can solve problems like the climate crisis, like the disparity between rich and poor, like the disintegration of our democracy. What if we had a different frame? How could we solve problems differently, maybe better?

+ +

So for us, these partnerships unlock a whole vast area of new thinking, new ways of doing business, new ways of taking care of other people. And at the end of the day, that's what gets me back in the rowboat [laughs] is this idea of, wow, we are having an impact on other people. And doing it with people who have a different starting point has really shaped a lot of the work that we do.

+ +

CHAD: Well, I'm sorry that we have to wrap up. Otherwise, we could keep on going and solve the climate crisis and unraveling of our democracy, but -- [laughs]

+ +

ALICE: Yeah, I have an appointment at 2:00 where I'm doing climate crisis. So I'll let you know how it goes.

+ +

CHAD: Okay, wonderful.

+ +

ALICE: [laughs]

+ +

CHAD: Alice, thank you so much for joining the show and sharing everything with us. We really appreciate it.

+ +

ALICE: Yeah, I was delighted to be with you guys and hope to continue the conversation.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

VICTORIA: And if you have questions or comments, email us at hosts@giantrobots.fm.

+ +

CHAD: You can find me on Twitter at @cpytel.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Alice Loy.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+apFVBdAp + + ]]> + + Victoria Guido + Chad Pytel + Alice Loy + + + 440: The LGBTQ+ Family Connections Center with Joe Barb + https://podcast.thoughtbot.com/440 + 8205d79c-49dc-46f4-baeb-6befc25c31b5 + Thu, 15 Sep 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Joe Barb is Executive Director and Founder of LGBTQ+ Family Connections Center. They have a mission to strengthen and empower all youth, however they identify, to overcome obstacles by providing housing, supportive counseling, community education, and advocacy. + +Victoria and Chad talk with Joe about identifying needs for the center, his own lived experience and connection to the LGBTQ+ community, and deciding what services to provide and evaluating which are most impactful. + 20:49 + no + + + Joe Barb is Executive Director and Founder of LGBTQ+ Family Connections Center. They have a mission to strengthen and empower all youth, however they identify, to overcome obstacles by providing housing, supportive counseling, community education, and advocacy. +Victoria and Chad talk with Joe about identifying needs for the center, his own lived experience and connection to the LGBTQ+ community, and deciding what services to provide and evaluating which are most impactful. +LGBTQ+ Family Connections Center (https://lgbtqfamilyconnectionscenter.net/) +Follow the LGBTQ+ Family Connections Center on Twitter (https://twitter.com/center_lgbtq), Instagram (https://www.instagram.com/lgbtqfamilyconnectionscenter/), Facebook (https://www.facebook.com/LGBTQFamilyConnectionCenter), or LinkedIn (https://www.linkedin.com/company/lgbtq-family-connections-center/). +Follow Joe on LinkedIn (https://www.linkedin.com/in/joe-barb-978ba0204/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. +VICTORIA: And I'm your other host, Victoria Guido. And with us today is Joe Barb, Executive Director and Founder of LGBTQ+ Family Connections Center, with a mission to strengthen and empower all youth however they identify to overcome obstacles by providing housing, supportive counseling, community education, and advocacy. Joe, thank you for joining us. +JOE: Thank you. I appreciate it. +VICTORIA: Wonderful. So you started the center over two years ago. If you could go back in time and give yourself advice to when you were first starting out, what would you tell yourself? +JOE: Wow, very similar to for-profit companies, having the tenacity to keep knocking on doors, never accepting no for an answer, and understanding that tenacity is everything. Nothing happens without continuing the fight every day. +VICTORIA: Great. And how did you first identify that need for the center? +JOE: A million years ago, when I was a late teenager, my parents had a pastor in their church suggest to them that in order to bring me back to God and back to their church, that they should cut me off financially, you know, I was a young freshman in college prod me in that direction. So my parents took the advice, and I found myself in my second semester of college with no funding. The check for the second semester had been canceled from my family, and I didn't know what to do. +So I called a friend in South Dakota that we had met on vacation. And she said, "You know what? I have an apartment building here. I just had an apartment become vacant. Why don't you move to South Dakota, and then we'll work on everything else?" So that lived experience kind of proded the whole thing. And then meeting the youth who had been displaced from home for being a trans youth caused the rest. +CHAD: Well, I'm really sorry for that personal experience that you had. But it's pretty powerful and that you've gone on to help others in similar situations is really admirable. +JOE: Yeah, it's been quite a journey. And my lived experience, honestly, I was with stability within 24 hours. The more I became comfortable and complacent in my life and then met somebody who wasn't; it brought me back to that. And then just looking at statistics, looking at how youth end up in a houseless situation created something in me that I had to address. +VICTORIA: So you had your own lived experience and that connection to your community which helped you identify that need and start out on the center. Did you find there were a lot of resources for building nonprofits? +JOE: There isn't. And it's really something that when you go into it, you believe that when you create a nonprofit and you finish that application, you send it into the IRS, and you get approval, that you put a great idea out there and that the community will respond and that everyone will immediately jump on it and say, "You know what? You're right. This is needed. We need housing. We need to make sure that youth are safe." And that's not the way it works. It doesn't work that way at all. +It's a lot of connections and community and getting involved and putting the statistics and the numbers out there so that people are aware of it. But it's mostly connecting the stories. The more youth that I've met and worked with and connected them to a story and told their story, the more people respond. +VICTORIA: Right. And so, what have you found to be the most impactful in sharing that story and in managing that content to get to the right people who can help you with this need? +JOE: The most impactful part is people just aren't aware. We all know that there's a homeless population. No matter where you live, there's a homeless population, and it impacts communities. But what we aren't aware of is we all typically believe that the government is funding these things and it's being taken care of and that maybe those people just chose homelessness and don't realize that the resources are very limited. Until those resources are able to show a data of need, that person may not be counted that you saw on the corner. +CHAD: You're pretty active socially online. I think where I first saw you was through a mutual connection on LinkedIn, and your posts started to be in my feed, and I liked and subscribed, I guess. How much of the awareness that you're putting out there is coming from social networks and online versus in-person and local communities? +JOE: I'd say it's probably a good mixture of both. Locally, obviously, I'm deeply involved with other service providers, and I'm involved with local government. I'm on any kind of board that you can think of that impacts youth homelessness. So there's that within my community but having those LinkedIn...just this weekend, we had our pride, and at our pride, someone walked over to me, started talking at our booth. And he said, "Well, I know you from LinkedIn. +CHAD: [chuckles] +JOE: I noticed your picture with Sylvan Lake behind you from your LinkedIn, and I just had to come over to meet you and say hi." And I thought, how impactful is social media that someone who lives in Florida happened to be in South Dakota came to pride and recognized me from a picture? +VICTORIA: Wow. Yeah, it makes our world feel a little smaller sometimes, doesn't it? +JOE: Absolutely. +VICTORIA: And the problem of youth homelessness and LGBTQ+ homelessness is very complex. And I think other nonprofit founders might be interested in how you decide what services you're going to provide and how you evaluate to see which ones are the most impactful. +JOE: We did things kind of backwards. So I formed the board of directors, and typically what happens with the board of directors is they want to become your advisors. And I thought these people have great professional experience. We have doctors; we have PhDs, we have scientists literally on our board. And those people don't have the lived experience. So I thought, who do we go to to develop programming and support for people that are in need? And the answer was glaringly clear; it had to be the people who were in need. +So I formed a Youth Action Board with the State Continuum of Care. And it comprises of youth ages 13 to 24 who have lived experience. We keep it at 66% have to have lived experience. And technically, most of them have even much more than that. But we connect with them through service providers who assist youth. And those were the people that we used to formulate what they needed, decide what was most beneficial to help them during vulnerable points, and then help them get out of situations. +VICTORIA: Right. And I think that user experience, that experience bringing that into the products and services that you're creating, just makes a lot of sense for us, and that's what we bring into our design as well. +JOE: Yeah, I mean, we do it in almost every industry. Whatever you create, whatever product you create, whether it's something tangible that you hold or whether it's a service, you bring in a test group. And that test group typically is people that you're seeking to utilize or buy your service or your product. And in doing that, we end up developing a better product. +It's the same thing with a nonprofit. We had to get the voice of those who we would be serving in order to make sure that we were doing what they needed, not what we thought as professional people or personal opinions was the way forward. +CHAD: Was there something as you were talking to people and learning that surprised you? +JOE: Probably the same thing that everyone develops is an opinion of homelessness. We all think that people that experience homelessness it's typically through some self-inflicted issue; typically, drugs and alcohol come to mind and some type of cause that brought you there that you had influence on. And I've learned that most of the kids that we serve had no influence on their homelessness other than to be born where they were or to who they were born. +A lot of our youth are coming from, oh, they've lived in shelters, or foster care, or aged out of foster care. It just changed my dichotomy of thinking that we would be serving people that had addiction problems or alcohol problems when in case of the youth...currently we're at, I think 68 youth served. I've only met one youth that had a previous addiction. +CHAD: It's really just that lack of a safety net. And all it takes is your family not supporting you and not having a safety net. +JOE: Absolutely. And that's just it. You said it very well. Most of us, when we have an incident in our life that we need some help because there's a vulnerability, we have people around us that we go back to. We have either family or close friends that we can say, "You know what? I lost my job. I need a little bit of help here," or "This medical incident happened, and could you assist us?" +And we get a response from our family or friends that typically is supportive and helps us find a way. A lot of youth, especially youth that experience homelessness, don't have that connection to family. So that's where we need to bring in community to support them. +VICTORIA: Right. And do you find there are unique challenges to supporting youth experiencing homelessness in the Midwest in South Dakota where you are versus in more urban areas? +JOE: Absolutely. Carl Siciliano is my TA advisor. He created the Ali Forney Center in New York, which is the largest housing support for homeless youth for...they specifically only target LGBTQ youth in the United States. And in talking to him and in looking at our demographics, it was very different. For them, people in larger cities will just seek out their services. They learn about it word of mouth. They find out that there's a shelter in place. +Here, our homeless population is much more hidden. And typically, what happens here is youth will gather together. And it'll be six or eight of them who will become friendly, and they will try to support each other by one of them will get a hotel, and then six or eight of them will live together. Or they're doubled up in one person's apartment, six or eight people live in somebody else's apartment, which truly isn't housed because it's not their place. And they try to support each other. So they're very hidden in our communities. +CHAD: It's unfortunate there's a lot of stuff happening in the U.S. and worldwide with legislation being passed now anti-transgender. I think South Dakota was the first state in the country to pass an anti-transgender bill this year. Are there particular challenges to doing the work that you do in today's climate? +JOE: Accessing mental health services, we had to overcome that obstacle by forming relationships with counseling services so that we could make sure that any youth, whether they were insured or underinsured, or uninsured, could immediately access mental health. And that took quite a bit of work on our part in order to make that happen. It should be easy. It should be easy to access mental health. +And that's probably one of the biggest challenges because I can stabilize anyone tomorrow with either a hotel, or a house, or an apartment. But if you don't have mental health to help with what got you there, you're still living in trauma. If you're living in trauma, how can you focus on things like going back to school or having a career or what even tomorrow means for you? Because you're living in trauma today. So, absolutely, to answer your question, mental health. +CHAD: And is that a matter of providers not wanting to provide services or not being able to pay for it? +JOE: Not being able to pay for it. There are things that you can access if you're uninsured or underinsured if you meet the guidelines to get into mental health access. The problem with that is if you need to help today, that's a process. We wanted to skip the process. We wanted to make sure that if you walked into our drop-in center today that this afternoon I can have you with a therapist of your choice. +MID-ROLL AD: +Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now, and can scale in the future. +thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. +As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. +Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. +CHAD: You have a website. You collect donations online. And we definitely want to link all of that stuff in the show notes. It will be there, and I hope people contribute. But when it comes to the tactical stuff on the product and business side, are there particular tools or resources you were able to draw upon to put together online donations, the website, that kind of thing? +JOE: As far as platforms, is that what you're asking? +CHAD: Yeah. +JOE: There are some great platforms that have been built specifically for nonprofits in order to help get the word out and help fundraise. That for us hasn't been the primary. In this type of nonprofit, typically, most of our donations are not donations or grants. They're things that we...like, I just spent two years on a grant that is quite substantial. But it was two years of work, literally 40 hours a week for two years. +So there are those tools, there's the GoFundMe, and there are all kinds of tools for sharing on social media in order to get people to donate. They're great, but you have to have a large circle in order to utilize those. And you have to have people that are willing to do that as well. So I don't think we have the tool that's the best tool yet socially. +CHAD: What would something that was better look like for you? +JOE: It's more getting corporations and businesses and private companies involved in what a lot of companies are already doing. They will seek from their employees giving initiatives. And they will seek information to what does the company want to support as a community? Because that's what their employees care about. +I think those things have a more sustainable development and a more sustainable footprint for nonprofits that when organizations get involved that are private and then offer to their employees a way to donate, that works best. +CHAD: Yeah. For thoughtbot, to honor Pride Month, we collected a series of donations that we were going to make. And there was team suggestion...because we have teams all over the place, we wanted to have a local impact. And then when it came to actually doing those donations, I think we had 10 to 20 organizations that we wanted to donate, not a huge amount of money to each one but hopefully, it makes a difference. +And the way that we needed to do that a person at thoughtbot needed to go and either find the donate link, the place to do it, and some of them didn't even have it. And we wanted to, you know, maybe it's a place in Brazil or something, and we need to get them the money somehow, wiring it or something. And so that was a fair amount of manual work to figure that out and then to make the payments. +JOE: And I think because it goes along with we're learning as organizations that we have to take care of the social and emotional part of employees just as well as we do the work environment. It's part of the work environment. So I think that that kind of goes back to HR, which is my background. HR should look at those things in advance and find local nonprofits to support local ideas and then maybe some national ones as well. +We all know of The Trevor Project and some of the great broader campaigns that do a lot of really good work. And have that ready so that when somebody joins your company you can show them and say, "Hey, by the way, these are some local organizations that we can do a payroll deduction for if you like, or we can buy annual contributions," and let the employees see that the company cares about the local area and also cares about things on a national platform that impact employees. +VICTORIA: I love that. I think that's a great way to involve corporations in giving back and connecting employees to their local communities and the local groups that need support. Is there anything else that you want to tell our listeners in order to support the LGBTQ+ Center or in general? +JOE: The majority of our youth are LGBTQ+. And that's because statistically, across the United States, the majority of youth seeking housing services unaccompanied are LGBTQ+, up to 40%. But we don't turn away any youth. It doesn't matter how they identify. It doesn't matter what their circumstances are. The only thing that we ask is if you're telling us you're homeless, then we're going to assist in that. +We do have age criteria of 16 to 24 because that matches the federal guidelines for the programming that we're in through federal dollars. So other than that, I mean, we still would help anyone of any age, but that's the big thing to know is that we help any youth however they identify. +And what could listeners do? Obviously, on our website or look into your community as well and see what is a support in your area and find something that you can contribute to. +VICTORIA: That sounds great. Thank you so much. Do you have any questions for me or Chad? +JOE: I think that what you're doing is great. I like that you are thinking of nonprofits as a company as well because a lot of people view it differently when it's actually a company. You have to figure out a way to sustain funding and bring money in just like any other organization in order to do the work. +CHAD: Yeah, I think that's a common misconception that people have. And I'm sure it's not the case with you and your organization. But I like to remind people that nonprofit really just means that it can't show a profit. So there are lots of nonprofits out there that just end up spending all of the money that they have. That is really also technically what it means sometimes. +JOE: And you bring up a great point. There's an IRS website to look up any nonprofit organization, and you can look at how they spend their money. I do that all the time before I make a donation. Because we've all heard those stories of CEOs, who make 30 million a year or whatever crazy number. You can always look up any organization and see how they spend their money. +CHAD: Yeah, that's a really good tip for people to do before you get involved with an organization with donations or your time and really making sure it matches your values and that kind of thing. +VICTORIA: Great. All right. I think we're about at time. So with that, I will wrap us up and let everyone know you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. +CHAD: If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel. +VICTORIA: And you can find me on Twitter @victori_ousg. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +CHAD: Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Joe Barb. + + + Joe Barb is Executive Director and Founder of LGBTQ+ Family Connections Center. They have a mission to strengthen and empower all youth, however they identify, to overcome obstacles by providing housing, supportive counseling, community education, and advocacy.

+ +

Victoria and Chad talk with Joe about identifying needs for the center, his own lived experience and connection to the LGBTQ+ community, and deciding what services to provide and evaluating which are most impactful.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Joe Barb, Executive Director and Founder of LGBTQ+ Family Connections Center, with a mission to strengthen and empower all youth however they identify to overcome obstacles by providing housing, supportive counseling, community education, and advocacy. Joe, thank you for joining us.

+ +

JOE: Thank you. I appreciate it.

+ +

VICTORIA: Wonderful. So you started the center over two years ago. If you could go back in time and give yourself advice to when you were first starting out, what would you tell yourself?

+ +

JOE: Wow, very similar to for-profit companies, having the tenacity to keep knocking on doors, never accepting no for an answer, and understanding that tenacity is everything. Nothing happens without continuing the fight every day.

+ +

VICTORIA: Great. And how did you first identify that need for the center?

+ +

JOE: A million years ago, when I was a late teenager, my parents had a pastor in their church suggest to them that in order to bring me back to God and back to their church, that they should cut me off financially, you know, I was a young freshman in college prod me in that direction. So my parents took the advice, and I found myself in my second semester of college with no funding. The check for the second semester had been canceled from my family, and I didn't know what to do.

+ +

So I called a friend in South Dakota that we had met on vacation. And she said, "You know what? I have an apartment building here. I just had an apartment become vacant. Why don't you move to South Dakota, and then we'll work on everything else?" So that lived experience kind of proded the whole thing. And then meeting the youth who had been displaced from home for being a trans youth caused the rest.

+ +

CHAD: Well, I'm really sorry for that personal experience that you had. But it's pretty powerful and that you've gone on to help others in similar situations is really admirable.

+ +

JOE: Yeah, it's been quite a journey. And my lived experience, honestly, I was with stability within 24 hours. The more I became comfortable and complacent in my life and then met somebody who wasn't; it brought me back to that. And then just looking at statistics, looking at how youth end up in a houseless situation created something in me that I had to address.

+ +

VICTORIA: So you had your own lived experience and that connection to your community which helped you identify that need and start out on the center. Did you find there were a lot of resources for building nonprofits?

+ +

JOE: There isn't. And it's really something that when you go into it, you believe that when you create a nonprofit and you finish that application, you send it into the IRS, and you get approval, that you put a great idea out there and that the community will respond and that everyone will immediately jump on it and say, "You know what? You're right. This is needed. We need housing. We need to make sure that youth are safe." And that's not the way it works. It doesn't work that way at all.

+ +

It's a lot of connections and community and getting involved and putting the statistics and the numbers out there so that people are aware of it. But it's mostly connecting the stories. The more youth that I've met and worked with and connected them to a story and told their story, the more people respond.

+ +

VICTORIA: Right. And so, what have you found to be the most impactful in sharing that story and in managing that content to get to the right people who can help you with this need?

+ +

JOE: The most impactful part is people just aren't aware. We all know that there's a homeless population. No matter where you live, there's a homeless population, and it impacts communities. But what we aren't aware of is we all typically believe that the government is funding these things and it's being taken care of and that maybe those people just chose homelessness and don't realize that the resources are very limited. Until those resources are able to show a data of need, that person may not be counted that you saw on the corner.

+ +

CHAD: You're pretty active socially online. I think where I first saw you was through a mutual connection on LinkedIn, and your posts started to be in my feed, and I liked and subscribed, I guess. How much of the awareness that you're putting out there is coming from social networks and online versus in-person and local communities?

+ +

JOE: I'd say it's probably a good mixture of both. Locally, obviously, I'm deeply involved with other service providers, and I'm involved with local government. I'm on any kind of board that you can think of that impacts youth homelessness. So there's that within my community but having those LinkedIn...just this weekend, we had our pride, and at our pride, someone walked over to me, started talking at our booth. And he said, "Well, I know you from LinkedIn.

+ +

CHAD: [chuckles]

+ +

JOE: I noticed your picture with Sylvan Lake behind you from your LinkedIn, and I just had to come over to meet you and say hi." And I thought, how impactful is social media that someone who lives in Florida happened to be in South Dakota came to pride and recognized me from a picture?

+ +

VICTORIA: Wow. Yeah, it makes our world feel a little smaller sometimes, doesn't it?

+ +

JOE: Absolutely.

+ +

VICTORIA: And the problem of youth homelessness and LGBTQ+ homelessness is very complex. And I think other nonprofit founders might be interested in how you decide what services you're going to provide and how you evaluate to see which ones are the most impactful.

+ +

JOE: We did things kind of backwards. So I formed the board of directors, and typically what happens with the board of directors is they want to become your advisors. And I thought these people have great professional experience. We have doctors; we have PhDs, we have scientists literally on our board. And those people don't have the lived experience. So I thought, who do we go to to develop programming and support for people that are in need? And the answer was glaringly clear; it had to be the people who were in need.

+ +

So I formed a Youth Action Board with the State Continuum of Care. And it comprises of youth ages 13 to 24 who have lived experience. We keep it at 66% have to have lived experience. And technically, most of them have even much more than that. But we connect with them through service providers who assist youth. And those were the people that we used to formulate what they needed, decide what was most beneficial to help them during vulnerable points, and then help them get out of situations.

+ +

VICTORIA: Right. And I think that user experience, that experience bringing that into the products and services that you're creating, just makes a lot of sense for us, and that's what we bring into our design as well.

+ +

JOE: Yeah, I mean, we do it in almost every industry. Whatever you create, whatever product you create, whether it's something tangible that you hold or whether it's a service, you bring in a test group. And that test group typically is people that you're seeking to utilize or buy your service or your product. And in doing that, we end up developing a better product.

+ +

It's the same thing with a nonprofit. We had to get the voice of those who we would be serving in order to make sure that we were doing what they needed, not what we thought as professional people or personal opinions was the way forward.

+ +

CHAD: Was there something as you were talking to people and learning that surprised you?

+ +

JOE: Probably the same thing that everyone develops is an opinion of homelessness. We all think that people that experience homelessness it's typically through some self-inflicted issue; typically, drugs and alcohol come to mind and some type of cause that brought you there that you had influence on. And I've learned that most of the kids that we serve had no influence on their homelessness other than to be born where they were or to who they were born.

+ +

A lot of our youth are coming from, oh, they've lived in shelters, or foster care, or aged out of foster care. It just changed my dichotomy of thinking that we would be serving people that had addiction problems or alcohol problems when in case of the youth...currently we're at, I think 68 youth served. I've only met one youth that had a previous addiction.

+ +

CHAD: It's really just that lack of a safety net. And all it takes is your family not supporting you and not having a safety net.

+ +

JOE: Absolutely. And that's just it. You said it very well. Most of us, when we have an incident in our life that we need some help because there's a vulnerability, we have people around us that we go back to. We have either family or close friends that we can say, "You know what? I lost my job. I need a little bit of help here," or "This medical incident happened, and could you assist us?"

+ +

And we get a response from our family or friends that typically is supportive and helps us find a way. A lot of youth, especially youth that experience homelessness, don't have that connection to family. So that's where we need to bring in community to support them.

+ +

VICTORIA: Right. And do you find there are unique challenges to supporting youth experiencing homelessness in the Midwest in South Dakota where you are versus in more urban areas?

+ +

JOE: Absolutely. Carl Siciliano is my TA advisor. He created the Ali Forney Center in New York, which is the largest housing support for homeless youth for...they specifically only target LGBTQ youth in the United States. And in talking to him and in looking at our demographics, it was very different. For them, people in larger cities will just seek out their services. They learn about it word of mouth. They find out that there's a shelter in place.

+ +

Here, our homeless population is much more hidden. And typically, what happens here is youth will gather together. And it'll be six or eight of them who will become friendly, and they will try to support each other by one of them will get a hotel, and then six or eight of them will live together. Or they're doubled up in one person's apartment, six or eight people live in somebody else's apartment, which truly isn't housed because it's not their place. And they try to support each other. So they're very hidden in our communities.

+ +

CHAD: It's unfortunate there's a lot of stuff happening in the U.S. and worldwide with legislation being passed now anti-transgender. I think South Dakota was the first state in the country to pass an anti-transgender bill this year. Are there particular challenges to doing the work that you do in today's climate?

+ +

JOE: Accessing mental health services, we had to overcome that obstacle by forming relationships with counseling services so that we could make sure that any youth, whether they were insured or underinsured, or uninsured, could immediately access mental health. And that took quite a bit of work on our part in order to make that happen. It should be easy. It should be easy to access mental health.

+ +

And that's probably one of the biggest challenges because I can stabilize anyone tomorrow with either a hotel, or a house, or an apartment. But if you don't have mental health to help with what got you there, you're still living in trauma. If you're living in trauma, how can you focus on things like going back to school or having a career or what even tomorrow means for you? Because you're living in trauma today. So, absolutely, to answer your question, mental health.

+ +

CHAD: And is that a matter of providers not wanting to provide services or not being able to pay for it?

+ +

JOE: Not being able to pay for it. There are things that you can access if you're uninsured or underinsured if you meet the guidelines to get into mental health access. The problem with that is if you need to help today, that's a process. We wanted to skip the process. We wanted to make sure that if you walked into our drop-in center today that this afternoon I can have you with a therapist of your choice.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now, and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: You have a website. You collect donations online. And we definitely want to link all of that stuff in the show notes. It will be there, and I hope people contribute. But when it comes to the tactical stuff on the product and business side, are there particular tools or resources you were able to draw upon to put together online donations, the website, that kind of thing?

+ +

JOE: As far as platforms, is that what you're asking?

+ +

CHAD: Yeah.

+ +

JOE: There are some great platforms that have been built specifically for nonprofits in order to help get the word out and help fundraise. That for us hasn't been the primary. In this type of nonprofit, typically, most of our donations are not donations or grants. They're things that we...like, I just spent two years on a grant that is quite substantial. But it was two years of work, literally 40 hours a week for two years.

+ +

So there are those tools, there's the GoFundMe, and there are all kinds of tools for sharing on social media in order to get people to donate. They're great, but you have to have a large circle in order to utilize those. And you have to have people that are willing to do that as well. So I don't think we have the tool that's the best tool yet socially.

+ +

CHAD: What would something that was better look like for you?

+ +

JOE: It's more getting corporations and businesses and private companies involved in what a lot of companies are already doing. They will seek from their employees giving initiatives. And they will seek information to what does the company want to support as a community? Because that's what their employees care about.

+ +

I think those things have a more sustainable development and a more sustainable footprint for nonprofits that when organizations get involved that are private and then offer to their employees a way to donate, that works best.

+ +

CHAD: Yeah. For thoughtbot, to honor Pride Month, we collected a series of donations that we were going to make. And there was team suggestion...because we have teams all over the place, we wanted to have a local impact. And then when it came to actually doing those donations, I think we had 10 to 20 organizations that we wanted to donate, not a huge amount of money to each one but hopefully, it makes a difference.

+ +

And the way that we needed to do that a person at thoughtbot needed to go and either find the donate link, the place to do it, and some of them didn't even have it. And we wanted to, you know, maybe it's a place in Brazil or something, and we need to get them the money somehow, wiring it or something. And so that was a fair amount of manual work to figure that out and then to make the payments.

+ +

JOE: And I think because it goes along with we're learning as organizations that we have to take care of the social and emotional part of employees just as well as we do the work environment. It's part of the work environment. So I think that that kind of goes back to HR, which is my background. HR should look at those things in advance and find local nonprofits to support local ideas and then maybe some national ones as well.

+ +

We all know of The Trevor Project and some of the great broader campaigns that do a lot of really good work. And have that ready so that when somebody joins your company you can show them and say, "Hey, by the way, these are some local organizations that we can do a payroll deduction for if you like, or we can buy annual contributions," and let the employees see that the company cares about the local area and also cares about things on a national platform that impact employees.

+ +

VICTORIA: I love that. I think that's a great way to involve corporations in giving back and connecting employees to their local communities and the local groups that need support. Is there anything else that you want to tell our listeners in order to support the LGBTQ+ Center or in general?

+ +

JOE: The majority of our youth are LGBTQ+. And that's because statistically, across the United States, the majority of youth seeking housing services unaccompanied are LGBTQ+, up to 40%. But we don't turn away any youth. It doesn't matter how they identify. It doesn't matter what their circumstances are. The only thing that we ask is if you're telling us you're homeless, then we're going to assist in that.

+ +

We do have age criteria of 16 to 24 because that matches the federal guidelines for the programming that we're in through federal dollars. So other than that, I mean, we still would help anyone of any age, but that's the big thing to know is that we help any youth however they identify.

+ +

And what could listeners do? Obviously, on our website or look into your community as well and see what is a support in your area and find something that you can contribute to.

+ +

VICTORIA: That sounds great. Thank you so much. Do you have any questions for me or Chad?

+ +

JOE: I think that what you're doing is great. I like that you are thinking of nonprofits as a company as well because a lot of people view it differently when it's actually a company. You have to figure out a way to sustain funding and bring money in just like any other organization in order to do the work.

+ +

CHAD: Yeah, I think that's a common misconception that people have. And I'm sure it's not the case with you and your organization. But I like to remind people that nonprofit really just means that it can't show a profit. So there are lots of nonprofits out there that just end up spending all of the money that they have. That is really also technically what it means sometimes.

+ +

JOE: And you bring up a great point. There's an IRS website to look up any nonprofit organization, and you can look at how they spend their money. I do that all the time before I make a donation. Because we've all heard those stories of CEOs, who make 30 million a year or whatever crazy number. You can always look up any organization and see how they spend their money.

+ +

CHAD: Yeah, that's a really good tip for people to do before you get involved with an organization with donations or your time and really making sure it matches your values and that kind of thing.

+ +

VICTORIA: Great. All right. I think we're about at time. So with that, I will wrap us up and let everyone know you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

CHAD: If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Joe Barb.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Joe Barb is Executive Director and Founder of LGBTQ+ Family Connections Center. They have a mission to strengthen and empower all youth, however they identify, to overcome obstacles by providing housing, supportive counseling, community education, and advocacy.

+ +

Victoria and Chad talk with Joe about identifying needs for the center, his own lived experience and connection to the LGBTQ+ community, and deciding what services to provide and evaluating which are most impactful.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

VICTORIA: And I'm your other host, Victoria Guido. And with us today is Joe Barb, Executive Director and Founder of LGBTQ+ Family Connections Center, with a mission to strengthen and empower all youth however they identify to overcome obstacles by providing housing, supportive counseling, community education, and advocacy. Joe, thank you for joining us.

+ +

JOE: Thank you. I appreciate it.

+ +

VICTORIA: Wonderful. So you started the center over two years ago. If you could go back in time and give yourself advice to when you were first starting out, what would you tell yourself?

+ +

JOE: Wow, very similar to for-profit companies, having the tenacity to keep knocking on doors, never accepting no for an answer, and understanding that tenacity is everything. Nothing happens without continuing the fight every day.

+ +

VICTORIA: Great. And how did you first identify that need for the center?

+ +

JOE: A million years ago, when I was a late teenager, my parents had a pastor in their church suggest to them that in order to bring me back to God and back to their church, that they should cut me off financially, you know, I was a young freshman in college prod me in that direction. So my parents took the advice, and I found myself in my second semester of college with no funding. The check for the second semester had been canceled from my family, and I didn't know what to do.

+ +

So I called a friend in South Dakota that we had met on vacation. And she said, "You know what? I have an apartment building here. I just had an apartment become vacant. Why don't you move to South Dakota, and then we'll work on everything else?" So that lived experience kind of proded the whole thing. And then meeting the youth who had been displaced from home for being a trans youth caused the rest.

+ +

CHAD: Well, I'm really sorry for that personal experience that you had. But it's pretty powerful and that you've gone on to help others in similar situations is really admirable.

+ +

JOE: Yeah, it's been quite a journey. And my lived experience, honestly, I was with stability within 24 hours. The more I became comfortable and complacent in my life and then met somebody who wasn't; it brought me back to that. And then just looking at statistics, looking at how youth end up in a houseless situation created something in me that I had to address.

+ +

VICTORIA: So you had your own lived experience and that connection to your community which helped you identify that need and start out on the center. Did you find there were a lot of resources for building nonprofits?

+ +

JOE: There isn't. And it's really something that when you go into it, you believe that when you create a nonprofit and you finish that application, you send it into the IRS, and you get approval, that you put a great idea out there and that the community will respond and that everyone will immediately jump on it and say, "You know what? You're right. This is needed. We need housing. We need to make sure that youth are safe." And that's not the way it works. It doesn't work that way at all.

+ +

It's a lot of connections and community and getting involved and putting the statistics and the numbers out there so that people are aware of it. But it's mostly connecting the stories. The more youth that I've met and worked with and connected them to a story and told their story, the more people respond.

+ +

VICTORIA: Right. And so, what have you found to be the most impactful in sharing that story and in managing that content to get to the right people who can help you with this need?

+ +

JOE: The most impactful part is people just aren't aware. We all know that there's a homeless population. No matter where you live, there's a homeless population, and it impacts communities. But what we aren't aware of is we all typically believe that the government is funding these things and it's being taken care of and that maybe those people just chose homelessness and don't realize that the resources are very limited. Until those resources are able to show a data of need, that person may not be counted that you saw on the corner.

+ +

CHAD: You're pretty active socially online. I think where I first saw you was through a mutual connection on LinkedIn, and your posts started to be in my feed, and I liked and subscribed, I guess. How much of the awareness that you're putting out there is coming from social networks and online versus in-person and local communities?

+ +

JOE: I'd say it's probably a good mixture of both. Locally, obviously, I'm deeply involved with other service providers, and I'm involved with local government. I'm on any kind of board that you can think of that impacts youth homelessness. So there's that within my community but having those LinkedIn...just this weekend, we had our pride, and at our pride, someone walked over to me, started talking at our booth. And he said, "Well, I know you from LinkedIn.

+ +

CHAD: [chuckles]

+ +

JOE: I noticed your picture with Sylvan Lake behind you from your LinkedIn, and I just had to come over to meet you and say hi." And I thought, how impactful is social media that someone who lives in Florida happened to be in South Dakota came to pride and recognized me from a picture?

+ +

VICTORIA: Wow. Yeah, it makes our world feel a little smaller sometimes, doesn't it?

+ +

JOE: Absolutely.

+ +

VICTORIA: And the problem of youth homelessness and LGBTQ+ homelessness is very complex. And I think other nonprofit founders might be interested in how you decide what services you're going to provide and how you evaluate to see which ones are the most impactful.

+ +

JOE: We did things kind of backwards. So I formed the board of directors, and typically what happens with the board of directors is they want to become your advisors. And I thought these people have great professional experience. We have doctors; we have PhDs, we have scientists literally on our board. And those people don't have the lived experience. So I thought, who do we go to to develop programming and support for people that are in need? And the answer was glaringly clear; it had to be the people who were in need.

+ +

So I formed a Youth Action Board with the State Continuum of Care. And it comprises of youth ages 13 to 24 who have lived experience. We keep it at 66% have to have lived experience. And technically, most of them have even much more than that. But we connect with them through service providers who assist youth. And those were the people that we used to formulate what they needed, decide what was most beneficial to help them during vulnerable points, and then help them get out of situations.

+ +

VICTORIA: Right. And I think that user experience, that experience bringing that into the products and services that you're creating, just makes a lot of sense for us, and that's what we bring into our design as well.

+ +

JOE: Yeah, I mean, we do it in almost every industry. Whatever you create, whatever product you create, whether it's something tangible that you hold or whether it's a service, you bring in a test group. And that test group typically is people that you're seeking to utilize or buy your service or your product. And in doing that, we end up developing a better product.

+ +

It's the same thing with a nonprofit. We had to get the voice of those who we would be serving in order to make sure that we were doing what they needed, not what we thought as professional people or personal opinions was the way forward.

+ +

CHAD: Was there something as you were talking to people and learning that surprised you?

+ +

JOE: Probably the same thing that everyone develops is an opinion of homelessness. We all think that people that experience homelessness it's typically through some self-inflicted issue; typically, drugs and alcohol come to mind and some type of cause that brought you there that you had influence on. And I've learned that most of the kids that we serve had no influence on their homelessness other than to be born where they were or to who they were born.

+ +

A lot of our youth are coming from, oh, they've lived in shelters, or foster care, or aged out of foster care. It just changed my dichotomy of thinking that we would be serving people that had addiction problems or alcohol problems when in case of the youth...currently we're at, I think 68 youth served. I've only met one youth that had a previous addiction.

+ +

CHAD: It's really just that lack of a safety net. And all it takes is your family not supporting you and not having a safety net.

+ +

JOE: Absolutely. And that's just it. You said it very well. Most of us, when we have an incident in our life that we need some help because there's a vulnerability, we have people around us that we go back to. We have either family or close friends that we can say, "You know what? I lost my job. I need a little bit of help here," or "This medical incident happened, and could you assist us?"

+ +

And we get a response from our family or friends that typically is supportive and helps us find a way. A lot of youth, especially youth that experience homelessness, don't have that connection to family. So that's where we need to bring in community to support them.

+ +

VICTORIA: Right. And do you find there are unique challenges to supporting youth experiencing homelessness in the Midwest in South Dakota where you are versus in more urban areas?

+ +

JOE: Absolutely. Carl Siciliano is my TA advisor. He created the Ali Forney Center in New York, which is the largest housing support for homeless youth for...they specifically only target LGBTQ youth in the United States. And in talking to him and in looking at our demographics, it was very different. For them, people in larger cities will just seek out their services. They learn about it word of mouth. They find out that there's a shelter in place.

+ +

Here, our homeless population is much more hidden. And typically, what happens here is youth will gather together. And it'll be six or eight of them who will become friendly, and they will try to support each other by one of them will get a hotel, and then six or eight of them will live together. Or they're doubled up in one person's apartment, six or eight people live in somebody else's apartment, which truly isn't housed because it's not their place. And they try to support each other. So they're very hidden in our communities.

+ +

CHAD: It's unfortunate there's a lot of stuff happening in the U.S. and worldwide with legislation being passed now anti-transgender. I think South Dakota was the first state in the country to pass an anti-transgender bill this year. Are there particular challenges to doing the work that you do in today's climate?

+ +

JOE: Accessing mental health services, we had to overcome that obstacle by forming relationships with counseling services so that we could make sure that any youth, whether they were insured or underinsured, or uninsured, could immediately access mental health. And that took quite a bit of work on our part in order to make that happen. It should be easy. It should be easy to access mental health.

+ +

And that's probably one of the biggest challenges because I can stabilize anyone tomorrow with either a hotel, or a house, or an apartment. But if you don't have mental health to help with what got you there, you're still living in trauma. If you're living in trauma, how can you focus on things like going back to school or having a career or what even tomorrow means for you? Because you're living in trauma today. So, absolutely, to answer your question, mental health.

+ +

CHAD: And is that a matter of providers not wanting to provide services or not being able to pay for it?

+ +

JOE: Not being able to pay for it. There are things that you can access if you're uninsured or underinsured if you meet the guidelines to get into mental health access. The problem with that is if you need to help today, that's a process. We wanted to skip the process. We wanted to make sure that if you walked into our drop-in center today that this afternoon I can have you with a therapist of your choice.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now, and can scale in the future.

+ +

thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success.

+ +

As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices.

+ +

Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff.

+ +

CHAD: You have a website. You collect donations online. And we definitely want to link all of that stuff in the show notes. It will be there, and I hope people contribute. But when it comes to the tactical stuff on the product and business side, are there particular tools or resources you were able to draw upon to put together online donations, the website, that kind of thing?

+ +

JOE: As far as platforms, is that what you're asking?

+ +

CHAD: Yeah.

+ +

JOE: There are some great platforms that have been built specifically for nonprofits in order to help get the word out and help fundraise. That for us hasn't been the primary. In this type of nonprofit, typically, most of our donations are not donations or grants. They're things that we...like, I just spent two years on a grant that is quite substantial. But it was two years of work, literally 40 hours a week for two years.

+ +

So there are those tools, there's the GoFundMe, and there are all kinds of tools for sharing on social media in order to get people to donate. They're great, but you have to have a large circle in order to utilize those. And you have to have people that are willing to do that as well. So I don't think we have the tool that's the best tool yet socially.

+ +

CHAD: What would something that was better look like for you?

+ +

JOE: It's more getting corporations and businesses and private companies involved in what a lot of companies are already doing. They will seek from their employees giving initiatives. And they will seek information to what does the company want to support as a community? Because that's what their employees care about.

+ +

I think those things have a more sustainable development and a more sustainable footprint for nonprofits that when organizations get involved that are private and then offer to their employees a way to donate, that works best.

+ +

CHAD: Yeah. For thoughtbot, to honor Pride Month, we collected a series of donations that we were going to make. And there was team suggestion...because we have teams all over the place, we wanted to have a local impact. And then when it came to actually doing those donations, I think we had 10 to 20 organizations that we wanted to donate, not a huge amount of money to each one but hopefully, it makes a difference.

+ +

And the way that we needed to do that a person at thoughtbot needed to go and either find the donate link, the place to do it, and some of them didn't even have it. And we wanted to, you know, maybe it's a place in Brazil or something, and we need to get them the money somehow, wiring it or something. And so that was a fair amount of manual work to figure that out and then to make the payments.

+ +

JOE: And I think because it goes along with we're learning as organizations that we have to take care of the social and emotional part of employees just as well as we do the work environment. It's part of the work environment. So I think that that kind of goes back to HR, which is my background. HR should look at those things in advance and find local nonprofits to support local ideas and then maybe some national ones as well.

+ +

We all know of The Trevor Project and some of the great broader campaigns that do a lot of really good work. And have that ready so that when somebody joins your company you can show them and say, "Hey, by the way, these are some local organizations that we can do a payroll deduction for if you like, or we can buy annual contributions," and let the employees see that the company cares about the local area and also cares about things on a national platform that impact employees.

+ +

VICTORIA: I love that. I think that's a great way to involve corporations in giving back and connecting employees to their local communities and the local groups that need support. Is there anything else that you want to tell our listeners in order to support the LGBTQ+ Center or in general?

+ +

JOE: The majority of our youth are LGBTQ+. And that's because statistically, across the United States, the majority of youth seeking housing services unaccompanied are LGBTQ+, up to 40%. But we don't turn away any youth. It doesn't matter how they identify. It doesn't matter what their circumstances are. The only thing that we ask is if you're telling us you're homeless, then we're going to assist in that.

+ +

We do have age criteria of 16 to 24 because that matches the federal guidelines for the programming that we're in through federal dollars. So other than that, I mean, we still would help anyone of any age, but that's the big thing to know is that we help any youth however they identify.

+ +

And what could listeners do? Obviously, on our website or look into your community as well and see what is a support in your area and find something that you can contribute to.

+ +

VICTORIA: That sounds great. Thank you so much. Do you have any questions for me or Chad?

+ +

JOE: I think that what you're doing is great. I like that you are thinking of nonprofits as a company as well because a lot of people view it differently when it's actually a company. You have to figure out a way to sustain funding and bring money in just like any other organization in order to do the work.

+ +

CHAD: Yeah, I think that's a common misconception that people have. And I'm sure it's not the case with you and your organization. But I like to remind people that nonprofit really just means that it can't show a profit. So there are lots of nonprofits out there that just end up spending all of the money that they have. That is really also technically what it means sometimes.

+ +

JOE: And you bring up a great point. There's an IRS website to look up any nonprofit organization, and you can look at how they spend their money. I do that all the time before I make a donation. Because we've all heard those stories of CEOs, who make 30 million a year or whatever crazy number. You can always look up any organization and see how they spend their money.

+ +

CHAD: Yeah, that's a really good tip for people to do before you get involved with an organization with donations or your time and really making sure it matches your values and that kind of thing.

+ +

VICTORIA: Great. All right. I think we're about at time. So with that, I will wrap us up and let everyone know you can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm.

+ +

CHAD: If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel.

+ +

VICTORIA: And you can find me on Twitter @victori_ousg.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

CHAD: Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Joe Barb.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Pmzci2ec + + ]]> + + Chad Pytel + Victoria Guido + Joe Barb + + + 439: LOANHOOD with Lucy Hall + https://podcast.thoughtbot.com/439 + 80ef1663-e0bc-4bb8-9ad8-dd7855f891b1 + Thu, 08 Sep 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Lucy Hall is the Co-Founder of LOANHOOD, an online fashion rental platform and community that allows users to loan inclusive, diverse, and creative styles for an affordable price. + +Chad talks with Lucy about being a peer-to-peer fashion rental app, building a community, and reducing the impacts of the fashion industry on the planet and people by helping to create a sustainable future. + 31:14 + no + + + Lucy Hall is the Co-Founder of LOANHOOD, an online fashion rental platform and community that allows users to loan inclusive, diverse, and creative styles for an affordable price. +Chad talks with Lucy about being a peer-to-peer fashion rental app, building a community, and reducing the impacts of the fashion industry on the planet and people by helping to create a sustainable future. +LOANHOOD (https://www.loanhood.com/) +Follow LOANHOOD on Twitter (https://twitter.com/loanhoodlondon), Instagram (https://www.instagram.com/loanhood/), Facebook (https://www.facebook.com/loanhood), TikTok (https://www.tiktok.com/@loanhood), YouTube (https://www.youtube.com/channel/UCCzWBlASKUfH1OsdPEJOKxg), or LinkedIn (https://www.linkedin.com/company/loanhood/). +Follow Lucy on LinkedIn (https://www.linkedin.com/in/lucy-hall-616b1614/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Lucy Hall, the Co-Founder of LOANHOOD, who are changing the face of fashion. Lucy, thank you so much for joining me. +LUCY: Thank you so much for having me, Chad. +CHAD: How are some of the ways that LOANHOOD is changing the face of fashion? +LUCY: So we're starting off with a peer-to-peer fashion rental app, which we just launched ten days ago now. +CHAD: Congratulations on the launch. +LUCY: It's been a long time in the making. And, like I said, we're starting with a fashion rental app. But there are so many different ways that we want to change the face of fashion. It definitely needs a facelift. +CHAD: What caused you to start with the rental platform? +LUCY: It was something that we were really passionate about. So my co-founders and I actually worked in the fashion industry for the majority of our careers. So we could see first-hand how it was changing, how it's developing. And sustainability started coming into our lives, and we could see that things had to change. +And we know that the fashion industry is quite archaic. Big fashion businesses are like these huge ships. It's so hard for them to change their course and to actually implement sustainability into their supply chains or their values. And we knew that we could do it quicker and better and faster than them. +So we started testing the idea of circular fashion by doing clothes swaps which is a kind of an entry-level way to circulate fashion for free or relatively cheaply. And we started getting this amazing feedback from people like, "Oh, we would love to do this again. And have you thought about monetizing it?" And, of course, that was our...to get to scale, we knew that we had to monetize this sharing of clothes. And that's how our peer-to-peer fashion rental app grew and was born. +CHAD: That's great. So you have two co-founders. +LUCY: I do. +CHAD: Jade and Jen. Were the three of you working together at the time? +LUCY: Funny story, Jade and I are actually best friends. And Jade was my model back in the day. So Jade has been a fashion model for 12-plus years. And she was on Britain's Next Top Model. And I was a model agent. She came into my agency as one of the runner-uppers, and we forged a lifelong friendship from there. And we've both been passionate about fashion. And then, as I said, our career paths, we could see the detrimental effect of the planet. +And Jade decided to go back to university and start studying. She did her master's in fashion futures at London College of Fashion. And that's where she started seeing sustainability. And the idea of a peer-to-peer rental came from that course. She was studying the future of fashion, and she knew that this was the only way we can move forward. +And Jen was a friend of Jade and is a graphic designer by trade and is an amazing brand builder and amazing designer. So we were asking her for some advice. And she came on as a co-founder at the beginning because she just knew this was the right path for her. +CHAD: You started with these swaps. Were you doing the swaps as friends because you felt it was the right thing to do? Or did you have an eye towards this could be something more? +LUCY: Well, we knew from the beginning that we wanted to do something big. We knew we'd got to a certain point in our careers where we were like, right, let's use our skills to really make a change. But we were also working, and we all had jobs, so we were kind of doing it as a side hustle, just testing the idea and going, "Oh yeah, we'll do this." And then it started picking up, and we got a contract with a local council. And we were like, wow, people are really interested in this. Let's keep going, and then the pandemic hit. +CHAD: How did the pandemic affect you? +LUCY: [chuckles] Well, as you can imagine, people weren't really doing clothes swaps or renting or even thinking about those things at the beginning of the pandemic anyhow. So we kind of just put it on hold and did what everyone did in the pandemic, hunkered down. +And we started learning as much as we could about the circular economy, about sharing economy, trust economy, marketing, product, really teaching ourselves from the bottom up what it takes to make a global brand. So we were quite lucky in the respect that we had that time away to really hone our skills and focus on what we wanted in the long term. +So post-pandemic, when we came out of the lockdowns, although there were multiple back and forth, as you know, it was definitely a stop-start for us, but we knew that it actually...it just allowed us that time to really focus our minds on what we wanted and a long-term plan, not just like, oh, let's try this out. We know what we want for the next 5 to 10 years, basically. +CHAD: At what point did you decide, okay, we have to make an app? +LUCY: It was a difficult one because we thought Shopify, Sharetribe there are all these amazing platforms. You can just get a business at the click of your fingers. However, for peer-to-peer fashion rental, it's a much more complex model. Even Sharetribe, which is supposed to be for those kinds of models it's not as detailed as we needed it to be. So we tried to build a website from scratch. And, again, we just knew that we're very much focused on Gen Z. +And when we were talking to our audience, we knew that they wanted an app. So we just scrapped it and said let's just go for it. But having no technical background was a real difficult decision for us because we had no funding. We'd all just left our jobs. The pandemic had happened, so we didn't have any savings really. So we had some money from the clothes swaps. +And we did a rewards-based Crowdfunder, and we raised £14,000 from friends and family in our community that were buying free rentals for the future and just believed in the mission that we were on. And we were able to get that £14,000 and put it into the start of building an app. And as you're aware, apps cost a lot of money. +CHAD: [laughs] +LUCY: We didn't get that far. And we learned a lot of lessons with the build because we tried to project manage it ourselves. Having no technical background, that was tricky. And we offshored it to a team in India who were lovely and amazing but not as skilled as we needed them to be. Because we had no technical background, we really needed somebody to lead that for us. +So we had a starting point, but we knew that we had to actually get a technical lead on board pretty soon. And we were lucky enough to find a partner in a company called ON, who are based in the UK. And with them on board, they led the tech from there on. +CHAD: Continuing to work with that team in India, or did they actually provide the entire team at that point? +LUCY: We switched to another offshore team because it costs so much money here in the UK. +CHAD: So when was this all happening? +LUCY: Last year, mainly. 2021. +CHAD: To give folks an idea, you make the decision to start building an app. You start doing that in 2021. You just launched. But your business is more than just the app. Were you right up to the wire with the app being ready? +LUCY: Like you said, we're building a community. And what we learned from the pandemic is that you can't rely on one part of your business to help you succeed. You need multiple things. And what we're passionate about more than anything is community. And what we found with the fashion industry is that it can be quite elitist. +And if you want to work in the fashion industry, you have to move to London or New York or Paris, and you have to probably know somebody in the fashion industry, and we wanted to change that. We wanted you to be able to start your own fashion journey wherever you are based. +And what we also saw was that all this money that people were spending on fashion was going to big fashion businesses and to probably one guy at the top of that chain, whereas, with peer-to-peer rental, you can actually circulate that money within communities. You're lifting communities up so they can create their own sustainable fashion future. So what was really important to us was to have community as one of our main pillars going forward. +CHAD: And how have you gone about building that community? +LUCY: Organically so far, which has been really nice. And again, the events that we do have been part of that. But to scale, we really need to start building out ambassador programs, referral systems that can help us hit those kinds of network effects. +CHAD: So I know you're only in the UK. +LUCY: Correct. +CHAD: What are the limiting factors to expansion beyond the UK? +LUCY: Money, obviously. +CHAD: [laughs] Okay. +LUCY: We’re on a funding journey at the moment, and that's a ride for sure. So we kind of use the Depop playbook. Do you know Depop? You're probably over 25, so that's probably why you don't know it. +CHAD: [laughs] Yes. +LUCY: A third of 16 to 25-year-olds are on Depop in the UK. It's the 10th most-searched-for resale platform in the U.S. And they started off in the UK, and they organically grew into the U.S., which is nuts. We probably won't do that, of course, but we plan to go to the U.S. potentially next. But it depends on investment, on what our audience is saying, where they're based. +What we find with our audiences, the universities that we partner with we have a lot of international students. So they're taking that idea back to their hometowns, which is really interesting. But on a tech front, going into the U.S. is easier because it's an English-speaking country. Going into Europe is a bit more complex because you have lots of different languages, although you have one single currency, which is helpful. +CHAD: Since your model is peer-to-peer, individuals are sending the rented item directly to the person who's renting it, right? +LUCY: That's correct, yeah. +CHAD: And so I suppose one potential barrier is you don't need to be able to receive centrally or to handle things in the United States. But you need enough people in the U.S. to make it worthwhile for individuals to be sending each other things to have enough rentals and activity. +LUCY: Always, the problem with the marketplace is the cold start problem. There is a great book by Andrew Chen called The Cold Start Problem. And we really need to build both the supply side, which we call the loaner, and the demand side, which we call the borrower. So we have been working really hard in the UK to get as many of the supply side on board because we know the people that we want to be on the platform, so emerging designers, young makers, and creators. +And because we have our fashion backgrounds, we can identify those people quite quickly. And we've done things that are totally not scalable, like messaging them on Instagram and scouting people in the streets. But as a small startup, you kind of have to do those scrappy things as well just to kind of build the supply side. +CHAD: Right. And I think that's why so many marketplaces end up focusing on particular geographies even if they could expand because that focus helps you do those unscalable things that you need to do in the early days to bootstrap that community that you need for the marketplace. +It hadn't occurred to me until you just said it that I've been thinking that this would totally be individuals, but for an emerging fashion designer to be on your community offering up their clothing for rental, that hadn't even occurred to me as a possibility. +LUCY: Something that we're passionate about, especially post-pandemic, a lot of young people that are either at university and didn't get the real university experience had to make some extra money started these side hustles of teaching themselves to crochet or teaching themselves to knit. And now they have these amazing pieces, and they're open to renting them out as well as doing their retail side of it. +And what we found from the resale people, so the Depopers or people on Vinted, was that they'd get this kind of seller's remorse. So they'd upload the item, take amazing pictures, and they'd sell it once. But with rental, you upload it, and you can rent it out over and over and over again. And you still get to keep it and wear it yourself, so a bit of a no-brainer. +CHAD: Yeah. So you went on the journey of creating the app, creating the community. You've just launched. So are you actively fundraising? +LUCY: We are actively fundraising. We're just closing our pre-seed round. And we were very lucky to have an incredible lead investor come on board. He just got the idea instantly. What we found difficult is being female founders who don't have tech backgrounds; it's definitely a couple of negatives against us. [laughs] But we're going to use it to our advantage, and the people that are on the journey with us now 100% are behind us and believe in what we're doing. Because we're an impact business as well as we want to have profit alongside people and planet, that's what's important to us to make impact socially, environmentally, and through the industry. +So the next step of our fundraising journey will be a crowdfund, an equity-based crowdfund. So we did the rewards-based crowdfunder last year. This year, it's going to be equity-based because we really believe that we're building this platform for our community, our audience. So they should be able to invest in us and come on that journey with us. And hopefully, the business grows to huge proportions, and that they can get some money back out of that later in their lives. +CHAD: Are you going to be using a platform to do that? +LUCY: We are undecided, although I'm leaning over to between one and another. There are only two platforms really in the UK, so Seedrs and Crowdcube. And I've spoken to some other founders that have done both platforms. And I've spoken to both the companies. I've looked at articles trying to find which one's the best fit for us. +One interesting thing that we had with the Crowdfunder was we were deciding between Kickstarter and Crowdfunder UK. And Kickstarter is very much more focused on men, more sports, definitely a male demographic, so that's why we went with Crowdfunder. +With Seedrs and Crowdcube, they don't have that; it's a very equal split. So it's just on the feedback that we've had from other people that have used those platforms. So I'm leaning towards one, but I won't say yet because I haven't fully decided. +CHAD: So you're only allowed to do that with people in the UK? +LUCY: I think it can be global, actually. +CHAD: Are you planning on having it be global? +LUCY: We have friends and family all across the world. I spoke to somebody today in Lithuania. I spoke to somebody the other day in Australia. I speak to people in the U.S. all the time that are like, "When are you coming to us?" [chuckles] +CHAD: Yeah, that'll be interesting; the fact that you're able to do the equity crowdfund anywhere, but people won't be able to actually use the product right away. You know, it's sort of a catch-22; you've got to have one before you can have the other. And so, hopefully, people go along on the journey. +LUCY: Chicken and the egg. We need the money to build the tech, to build the audience. But we need the audience and the tech to show the investors that we've got engagement and traction. And yeah, there's always something. I think we're doing pretty good. +MID-ROLL AD: +As life moves online, brick-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. +CHAD: You mentioned that your three female founders have faced some bias, it sounds like, especially in talking with potential investors and seeking to grow your community. How has that been for you? +LUCY: You know, I don't want to put it down to being a female founder. I actually think the statistics tell us that, unfortunately. But I think what's the problem is that most of the people that I speak to in investment, either VCs or angels are guys, middle-aged guys between, say, late 30s to the 60s, and they are investing in businesses that they get. +They don't generally get a peer-to-peer fashion rental app for Gen Z. They're like, "Oh, they're going to want to ship things to each other, and like, what about the packaging?" And they've never heard of Depop. It just got bought by Etsy for $1.62 billion. It's a huge industry, and rental is just an evolution of resale. And they're like, "Oh, okay, kind of get it," but they don't really. We have to hand-hold them a lot through the pitch deck and get them excited. But that's, the problem is that we don't have enough women in the investment space or ex-founders. +I know in the U.S., it's a lot different. They have a lot more ex-founders investing, especially angel investors, which is great because they get the journey. Whereas if you have somebody with a financial services background, all they care about is the math of it. And it's like, you know what? Startups don't always just succeed on the math; it's the vision, it's the idea, it's the network effects, it's the audience. There are so many different things at play here. And if you've never started a business yourself, you just don't get that. +CHAD: There's a lot that goes into creating a company. And it may not be the fact that your female founders directly contribute to it but in an environment where they're looking for a reason not to invest. +LUCY: Exactly. +CHAD: That bias can creep into all of the excuses or differences that someone might point to and say, "Oh, this isn't going to work," or "I don't get this." +LUCY: 100%. If you've got a good business idea and you've got a strong pitch deck and a strong financial model, then that business will do well, for sure. However, there are so many other factors at play. And when there are so many great businesses competing against one another, they unbiasedly go with one over the other. +CHAD: So you also mentioned you have another excuse that people might use is you just don't have a technical founder on the founding team. +LUCY: That's definitely a struggle. We will be bringing in a CTO later in the year, which will be really exciting because it's definitely the missing piece to the puzzle. We have domain expertise in fashion. We have that side of it down. But yeah, the technical side of things, I think all the founders that I have spoken to that do have a CTO in the founding team or even have brought their technical team in-house just say it's a game changer. +When somebody is invested in your company, and they're using the platform every single day, they can see the bugs. I mean, Chaz from Fat Llama, which is a great rental app, said that his developers would pull out a laptop in the pub and be like, "Oh, I just saw a bug. Let me quickly fix it." I mean, wow, that would be insane. +Our developers finish at a certain time, and that's it; they're gone. So if we have a problem on an evening or even because they are in India they have a different time, we can't get hold of them. It's so frustrating. +CHAD: So when you start to build a team, will you be doing it based in the UK? +LUCY: Or based in Europe, at least. I think another thing to come out of the pandemic is this remote work, and I think that's great. I think there's so much talent across Europe, across the world. But for the timezone issue, I think Europe is definitely a better fit for us because we don't want to be having the same issues that we're having now with the time differences with India. But yeah, there's so much talent across the whole of Europe. +CHAD: Yeah, that's what we do at thoughtbot. We are all throughout the Americas, all throughout Europe, Middle East, and Africa. We've built our team. But we're grouped in by timezone. So people work with clients and with each other. And there, it's based on the timezone that they're in. And so that does make a big difference around how communication can work and how a part of the team you're able to feel because you're online at the same time as each other. +LUCY: Yeah. Definitely, that's a great show. +CHAD: But I definitely recommend casting as wide as possible. It definitely allows you to hire the best person for the job. +LUCY: Yeah, I think we need to find somebody that's passionate about the mission and who understands working with three co-founders that don't have a tech background that we probably do need a little bit more hand-holding than another founder would. We're learning so much as we go. Hopefully, we'll be coders one day. +[laughter] +CHAD: I actually don't think that. Some people might say, "Oh, you really should learn to code yourself." And I think that that does a disservice to what you are bringing to the table with your domain expertise and with your ability to really understand the industry and know what needs to happen from a business perspective. +LUCY: Yeah, I would totally agree. You can't be an expert in every part of the field. You can't be an accountant; you can't be a CTO. You need to be good at exactly what you do. And I'm the CEO, so I have an overview of everything. And that's what I love is kind of have a little finger on each little project that's going on and really get an understanding of across the board. +But you need those people that are drilling into, like, we have my co-founder, Jen, who's a graphic designer by trade, but she's our Chief Creative Officer. And she really drills down into the creative side of things. And she knows what she's talking about. And she is the expert in that, and that's so valuable. +CHAD: And I think that that's the important thing to founders to do early on is to really understand what their product and business are. You don't necessarily need to learn how to code. But I do think it's a mistake when early founders start stepping away from the product too early. +LUCY: Yeah, you need to be super close to the product. And you need good communication across all different divisions. So marketing and product have to talk to each other all the time, so we can tell our audience what's happening in the product, and then we can build the features that we need to grow from the marketing side of things. It's all about communication. +And it's so hard as a startup because there are so many different things going on and so many people pulling you from left to right. There are metrics to hit; there are bills to pay, there's audience, the community to keep happy. And it's like, oh, you can't drop the ball on anything. You really have to just do as much as you can. But if you communicate to each of those stakeholders, we're doing our best. +I mean, we had a mail-out the other day that said this is a business built by hands. It's built by people. I know we're a tech company, but there are real developers there hammering on their laptops. We're all here writing the copy and doing everything that we can to make this the most successful business so we can make real impact on the climate change and communities. +CHAD: I want to talk about that impact, but before we do, I'm curious, so you're all in the same general London area? +LUCY: No, we're not, actually. So Jade and Jen are based in London. And I actually moved out of London a couple of years ago, and I live in New York in the north of England. +CHAD: Oh, okay. +LUCY: See, definitely a different dynamic. And another reason why I'm passionate about bringing the fashion industry outside of London is because I travel up and down all the time, and I'm lucky it's like an hour 50 on the train. But that becomes expensive, and it's difficult to travel all the time. +CHAD: So, are you meeting in person with each other? +LUCY: We try. I just saw the girls last week. I'm seeing them again at the weekend. We speak every single day on Slack, WhatsApp. We have weekly calls, and we jump on pretty much video calls to each other every day. And that's, again, another thing from the pandemic that's been a game changer. +Because when I actually left, it was just before the pandemic. We were like, oh my God, how is this going to work? But I knew that it was the right decision for me. And then the pandemic hit, and everyone was on video calls. And we were like, oh, this is so easy. This is great. [laughs] +CHAD: Yeah, it really opened that up to everyone's expectations. +LUCY: Yeah, and I think it's great. I think it's much more flexible. And we will get an office for sure. But I would love to have an office here and an office in London so we can have teams across the nation. Because I think we don't all have to go and live in a capital city to get the same out of the fashion industry. +CHAD: Yeah. So let's talk about sustainability, the environment, and climate change. I am somewhat aware that an enormous amount of resources goes into creating new items of clothing. +LUCY: It's crazy. So the fashion industry accounts for 10% of the global greenhouse gas emissions at the moment. And if nothing changes by 2050, it will use a quarter of the world's carbon budget. It is insane, and it affects not only the planet but people. The garment workers are paid nothing. They're treated badly. And this is all part of the supply chains of fashion businesses. +And like I said, when I started in the fashion industry, e-commerce really was only just starting, and Jade, who is the model, was working for Asos, which is a big fashion brand and big fast fashion brand. So when she started working for them, she was shooting like 10-15 items, 20 items a day, and when she left, so five years later, they were shooting like 70 items per day. They were just churning out more and more fashion, more options. +And you can imagine most of the clothes are made...well, we have this whole disconnect about clothes. So I actually had a restaurant for three years in between my fashion career. And that's where I found sustainability because you have that connection with food. And you know that eating organic or eating locally and seasonally is better for you and better for the planet. +But nobody thinks that your clothes come from the ground. They're made from plants. Or if they're not made from plants, they're made from oil. It's nuts that people don't have as much education around it. And that's partly because the fashion industry doesn't want people to know, and it's a lot of smoke and mirrors. It's a very opaque industry. We went to one university, and they said that they thought all clothes were made from machines. They had no idea that there was cotton and linen. And so, like, wow, this is crazy. +CHAD: So given that it's the magnitude of the size of the problem but also the industry, there are two ways of looking at that, I'm sure, one is the potential for your impact is huge. The other is how do you get started? How can we have an impact there? So how are you tackling that? +LUCY: I get asked a lot by people, like, how can I start my sustainability journey? I feel so much pressure to do things. I should be vegan, or I'm not recycling enough. I got a plastic bag, oh, I feel terrible. And it's like we are all on a journey. And you just have to start one day at a time and just be more conscious. +So whether that's instead of buying one dress for a wedding that you are probably just going to stick in your wardrobe, why don't you rent it? Try one of the platforms that are out there, and you can rent a really cool dress, and that's probably someone else is going to rent it, and someone else is going to rent it. And by prolonging the life of an item, you can save so much energy and water. And those small things that we can each do will make a huge impact globally. +There's a lot of mindset shifting and behavioral change that needs to come with rental. As we saw with Airbnb when they started, people were like, "Oh God, I don't want someone sleeping in my bed," and now I Airbnb in my house all the time. And it's a great source of secondary income, especially for a startup founder [chuckles] but also giving people the opportunity to have these experiences in small communities, which I love. +And that's what we want to see with fashion is that people will start being more conscious. And how LOANHOOD is different to other more traditional rental systems is it's much more affordable. And it's much more accessible because you can meet in person. +So how we see it growing is these hyperlocal communities where you can meet people in person, a bit like Facebook Marketplace. They've done super well in more of the suburban areas. You can drop off your dress to somebody around the corner. So you're reducing the cost of delivery and reducing the emissions by meeting in person. So those hyperlocal communities will be really important in helping people adopt this behavior. +CHAD: Are you worried from a business perspective that if it's just renting to someone around the corner that they might not want to do it through LOANHOOD? +LUCY: I think people will still do it through the platform because of the added value that we give, you know, rental protection. I could go and borrow people's clothes like my friends in the area. I wouldn't do that. I might do it once or twice. I think if it's not somebody that you're really friendly with, then you would definitely do it through the platform. +CHAD: Yeah. And by rental protection, you mean if something gets damaged or that kind of thing, it's protected. +LUCY: We don't have full insurance yet because, again, the sharing economy is a new economy. And, of course, insurers are very old school. And it's hard for them to grasp the fact that there's a new industry here, but that is changing. And as soon as we have more data, we'll be able to get full insurance for these items. But right now, we do it in-house and protect items, minor damage, or repairs. And if it isn't returned or damaged beyond repair by the person that's renting it, then they have to cover the retail price of it. +CHAD: Yeah, makes sense. What's beyond rental platform in terms of this is where you decided to start, but your goal is to change the face of fashion? What's beyond? +LUCY: There are lots of different verticals that we can do within rental or in fashion. So we're really passionate about digital fashion. Jade, my business partner, is actually doing her Ph.D. in digital transformation in the metaverse. So how can we bring sustainability and ethical practices into the metaverse with fashion is something that we're really passionate about and something that we're exploring, renting different things so femtech, or skiwear, activewear, all those kind of things and then just creating a space for our community to grow creatively. +So entrepreneurship is really important to us as well, and giving people the opportunity to be...especially Gen Z they have this way that's called pay to create. So they're passionate about making money out of things that they can do themselves, whether that's creating content, renting out the things they own, upcycling. We want to expand on that and give them the tools to actually create their own career paths. +You don't have to go down the traditional university routes. We see a world where there's a LOANHOOD campus where you can come and learn how to be content creators or all sorts of different things. It's a really exciting time. And our 10-year plan keeps getting more bigger and bigger. And we're like, oh God, it's just exciting. +CHAD: Yet do you worry about spreading yourself too thin and compromising on the early steps? +LUCY: We always come back to the point of why we're doing this and who we're doing this for because what's the point? Otherwise, we're doing this to reduce impacts of the fashion industry on the planet and people. And we are doing this for our community and to give them the options and give them the power back. +As we've seen with governments around the world, people in leadership roles are not doing enough, and we can't rely on them. So if we want to create our own sustainable future, we have to do it ourselves. And we want to give people the tools to do that. +CHAD: Well, I wish you the best of luck in that. I'm very confident that you're going to have the impact you're looking for along the way, and I wish you the best in that. Thank you for stopping by and sharing with us. I really appreciate it. +LUCY: Thank you so much for having me. It was great to chat too. +CHAD: If folks want to find out more or get in touch with you or follow along, where are all the different places that they can do that? +LUCY: Check out our website, loanhood.com. If you are a founder and you want to talk about funding or building a product, marketing, you can email me lucy (L-U-C-Y) at lucy@loanhood.com. And we are on Instagram and TikTok @loanhood. +CHAD: Wonderful. You can subscribe to the show and find notes which include a link to everything that Lucy just mentioned along with a complete transcript for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and I'll see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Lucy Hall is the Co-Founder of LOANHOOD, an online fashion rental platform and community that allows users to loan inclusive, diverse, and creative styles for an affordable price.

+ +

Chad talks with Lucy about being a peer-to-peer fashion rental app, building a community, and reducing the impacts of the fashion industry on the planet and people by helping to create a sustainable future.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Lucy Hall, the Co-Founder of LOANHOOD, who are changing the face of fashion. Lucy, thank you so much for joining me.

+ +

LUCY: Thank you so much for having me, Chad.

+ +

CHAD: How are some of the ways that LOANHOOD is changing the face of fashion?

+ +

LUCY: So we're starting off with a peer-to-peer fashion rental app, which we just launched ten days ago now.

+ +

CHAD: Congratulations on the launch.

+ +

LUCY: It's been a long time in the making. And, like I said, we're starting with a fashion rental app. But there are so many different ways that we want to change the face of fashion. It definitely needs a facelift.

+ +

CHAD: What caused you to start with the rental platform?

+ +

LUCY: It was something that we were really passionate about. So my co-founders and I actually worked in the fashion industry for the majority of our careers. So we could see first-hand how it was changing, how it's developing. And sustainability started coming into our lives, and we could see that things had to change.

+ +

And we know that the fashion industry is quite archaic. Big fashion businesses are like these huge ships. It's so hard for them to change their course and to actually implement sustainability into their supply chains or their values. And we knew that we could do it quicker and better and faster than them.

+ +

So we started testing the idea of circular fashion by doing clothes swaps which is a kind of an entry-level way to circulate fashion for free or relatively cheaply. And we started getting this amazing feedback from people like, "Oh, we would love to do this again. And have you thought about monetizing it?" And, of course, that was our...to get to scale, we knew that we had to monetize this sharing of clothes. And that's how our peer-to-peer fashion rental app grew and was born.

+ +

CHAD: That's great. So you have two co-founders.

+ +

LUCY: I do.

+ +

CHAD: Jade and Jen. Were the three of you working together at the time?

+ +

LUCY: Funny story, Jade and I are actually best friends. And Jade was my model back in the day. So Jade has been a fashion model for 12-plus years. And she was on Britain's Next Top Model. And I was a model agent. She came into my agency as one of the runner-uppers, and we forged a lifelong friendship from there. And we've both been passionate about fashion. And then, as I said, our career paths, we could see the detrimental effect of the planet.

+ +

And Jade decided to go back to university and start studying. She did her master's in fashion futures at London College of Fashion. And that's where she started seeing sustainability. And the idea of a peer-to-peer rental came from that course. She was studying the future of fashion, and she knew that this was the only way we can move forward.

+ +

And Jen was a friend of Jade and is a graphic designer by trade and is an amazing brand builder and amazing designer. So we were asking her for some advice. And she came on as a co-founder at the beginning because she just knew this was the right path for her.

+ +

CHAD: You started with these swaps. Were you doing the swaps as friends because you felt it was the right thing to do? Or did you have an eye towards this could be something more?

+ +

LUCY: Well, we knew from the beginning that we wanted to do something big. We knew we'd got to a certain point in our careers where we were like, right, let's use our skills to really make a change. But we were also working, and we all had jobs, so we were kind of doing it as a side hustle, just testing the idea and going, "Oh yeah, we'll do this." And then it started picking up, and we got a contract with a local council. And we were like, wow, people are really interested in this. Let's keep going, and then the pandemic hit.

+ +

CHAD: How did the pandemic affect you?

+ +

LUCY: [chuckles] Well, as you can imagine, people weren't really doing clothes swaps or renting or even thinking about those things at the beginning of the pandemic anyhow. So we kind of just put it on hold and did what everyone did in the pandemic, hunkered down.

+ +

And we started learning as much as we could about the circular economy, about sharing economy, trust economy, marketing, product, really teaching ourselves from the bottom up what it takes to make a global brand. So we were quite lucky in the respect that we had that time away to really hone our skills and focus on what we wanted in the long term.

+ +

So post-pandemic, when we came out of the lockdowns, although there were multiple back and forth, as you know, it was definitely a stop-start for us, but we knew that it actually...it just allowed us that time to really focus our minds on what we wanted and a long-term plan, not just like, oh, let's try this out. We know what we want for the next 5 to 10 years, basically.

+ +

CHAD: At what point did you decide, okay, we have to make an app?

+ +

LUCY: It was a difficult one because we thought Shopify, Sharetribe there are all these amazing platforms. You can just get a business at the click of your fingers. However, for peer-to-peer fashion rental, it's a much more complex model. Even Sharetribe, which is supposed to be for those kinds of models it's not as detailed as we needed it to be. So we tried to build a website from scratch. And, again, we just knew that we're very much focused on Gen Z.

+ +

And when we were talking to our audience, we knew that they wanted an app. So we just scrapped it and said let's just go for it. But having no technical background was a real difficult decision for us because we had no funding. We'd all just left our jobs. The pandemic had happened, so we didn't have any savings really. So we had some money from the clothes swaps.

+ +

And we did a rewards-based Crowdfunder, and we raised £14,000 from friends and family in our community that were buying free rentals for the future and just believed in the mission that we were on. And we were able to get that £14,000 and put it into the start of building an app. And as you're aware, apps cost a lot of money.

+ +

CHAD: [laughs]

+ +

LUCY: We didn't get that far. And we learned a lot of lessons with the build because we tried to project manage it ourselves. Having no technical background, that was tricky. And we offshored it to a team in India who were lovely and amazing but not as skilled as we needed them to be. Because we had no technical background, we really needed somebody to lead that for us.

+ +

So we had a starting point, but we knew that we had to actually get a technical lead on board pretty soon. And we were lucky enough to find a partner in a company called ON, who are based in the UK. And with them on board, they led the tech from there on.

+ +

CHAD: Continuing to work with that team in India, or did they actually provide the entire team at that point?

+ +

LUCY: We switched to another offshore team because it costs so much money here in the UK.

+ +

CHAD: So when was this all happening?

+ +

LUCY: Last year, mainly. 2021.

+ +

CHAD: To give folks an idea, you make the decision to start building an app. You start doing that in 2021. You just launched. But your business is more than just the app. Were you right up to the wire with the app being ready?

+ +

LUCY: Like you said, we're building a community. And what we learned from the pandemic is that you can't rely on one part of your business to help you succeed. You need multiple things. And what we're passionate about more than anything is community. And what we found with the fashion industry is that it can be quite elitist.

+ +

And if you want to work in the fashion industry, you have to move to London or New York or Paris, and you have to probably know somebody in the fashion industry, and we wanted to change that. We wanted you to be able to start your own fashion journey wherever you are based.

+ +

And what we also saw was that all this money that people were spending on fashion was going to big fashion businesses and to probably one guy at the top of that chain, whereas, with peer-to-peer rental, you can actually circulate that money within communities. You're lifting communities up so they can create their own sustainable fashion future. So what was really important to us was to have community as one of our main pillars going forward.

+ +

CHAD: And how have you gone about building that community?

+ +

LUCY: Organically so far, which has been really nice. And again, the events that we do have been part of that. But to scale, we really need to start building out ambassador programs, referral systems that can help us hit those kinds of network effects.

+ +

CHAD: So I know you're only in the UK.

+ +

LUCY: Correct.

+ +

CHAD: What are the limiting factors to expansion beyond the UK?

+ +

LUCY: Money, obviously.

+ +

CHAD: [laughs] Okay.

+ +

LUCY: We’re on a funding journey at the moment, and that's a ride for sure. So we kind of use the Depop playbook. Do you know Depop? You're probably over 25, so that's probably why you don't know it.

+ +

CHAD: [laughs] Yes.

+ +

LUCY: A third of 16 to 25-year-olds are on Depop in the UK. It's the 10th most-searched-for resale platform in the U.S. And they started off in the UK, and they organically grew into the U.S., which is nuts. We probably won't do that, of course, but we plan to go to the U.S. potentially next. But it depends on investment, on what our audience is saying, where they're based.

+ +

What we find with our audiences, the universities that we partner with we have a lot of international students. So they're taking that idea back to their hometowns, which is really interesting. But on a tech front, going into the U.S. is easier because it's an English-speaking country. Going into Europe is a bit more complex because you have lots of different languages, although you have one single currency, which is helpful.

+ +

CHAD: Since your model is peer-to-peer, individuals are sending the rented item directly to the person who's renting it, right?

+ +

LUCY: That's correct, yeah.

+ +

CHAD: And so I suppose one potential barrier is you don't need to be able to receive centrally or to handle things in the United States. But you need enough people in the U.S. to make it worthwhile for individuals to be sending each other things to have enough rentals and activity.

+ +

LUCY: Always, the problem with the marketplace is the cold start problem. There is a great book by Andrew Chen called The Cold Start Problem. And we really need to build both the supply side, which we call the loaner, and the demand side, which we call the borrower. So we have been working really hard in the UK to get as many of the supply side on board because we know the people that we want to be on the platform, so emerging designers, young makers, and creators.

+ +

And because we have our fashion backgrounds, we can identify those people quite quickly. And we've done things that are totally not scalable, like messaging them on Instagram and scouting people in the streets. But as a small startup, you kind of have to do those scrappy things as well just to kind of build the supply side.

+ +

CHAD: Right. And I think that's why so many marketplaces end up focusing on particular geographies even if they could expand because that focus helps you do those unscalable things that you need to do in the early days to bootstrap that community that you need for the marketplace.

+ +

It hadn't occurred to me until you just said it that I've been thinking that this would totally be individuals, but for an emerging fashion designer to be on your community offering up their clothing for rental, that hadn't even occurred to me as a possibility.

+ +

LUCY: Something that we're passionate about, especially post-pandemic, a lot of young people that are either at university and didn't get the real university experience had to make some extra money started these side hustles of teaching themselves to crochet or teaching themselves to knit. And now they have these amazing pieces, and they're open to renting them out as well as doing their retail side of it.

+ +

And what we found from the resale people, so the Depopers or people on Vinted, was that they'd get this kind of seller's remorse. So they'd upload the item, take amazing pictures, and they'd sell it once. But with rental, you upload it, and you can rent it out over and over and over again. And you still get to keep it and wear it yourself, so a bit of a no-brainer.

+ +

CHAD: Yeah. So you went on the journey of creating the app, creating the community. You've just launched. So are you actively fundraising?

+ +

LUCY: We are actively fundraising. We're just closing our pre-seed round. And we were very lucky to have an incredible lead investor come on board. He just got the idea instantly. What we found difficult is being female founders who don't have tech backgrounds; it's definitely a couple of negatives against us. [laughs] But we're going to use it to our advantage, and the people that are on the journey with us now 100% are behind us and believe in what we're doing. Because we're an impact business as well as we want to have profit alongside people and planet, that's what's important to us to make impact socially, environmentally, and through the industry.

+ +

So the next step of our fundraising journey will be a crowdfund, an equity-based crowdfund. So we did the rewards-based crowdfunder last year. This year, it's going to be equity-based because we really believe that we're building this platform for our community, our audience. So they should be able to invest in us and come on that journey with us. And hopefully, the business grows to huge proportions, and that they can get some money back out of that later in their lives.

+ +

CHAD: Are you going to be using a platform to do that?

+ +

LUCY: We are undecided, although I'm leaning over to between one and another. There are only two platforms really in the UK, so Seedrs and Crowdcube. And I've spoken to some other founders that have done both platforms. And I've spoken to both the companies. I've looked at articles trying to find which one's the best fit for us.

+ +

One interesting thing that we had with the Crowdfunder was we were deciding between Kickstarter and Crowdfunder UK. And Kickstarter is very much more focused on men, more sports, definitely a male demographic, so that's why we went with Crowdfunder.

+ +

With Seedrs and Crowdcube, they don't have that; it's a very equal split. So it's just on the feedback that we've had from other people that have used those platforms. So I'm leaning towards one, but I won't say yet because I haven't fully decided.

+ +

CHAD: So you're only allowed to do that with people in the UK?

+ +

LUCY: I think it can be global, actually.

+ +

CHAD: Are you planning on having it be global?

+ +

LUCY: We have friends and family all across the world. I spoke to somebody today in Lithuania. I spoke to somebody the other day in Australia. I speak to people in the U.S. all the time that are like, "When are you coming to us?" [chuckles]

+ +

CHAD: Yeah, that'll be interesting; the fact that you're able to do the equity crowdfund anywhere, but people won't be able to actually use the product right away. You know, it's sort of a catch-22; you've got to have one before you can have the other. And so, hopefully, people go along on the journey.

+ +

LUCY: Chicken and the egg. We need the money to build the tech, to build the audience. But we need the audience and the tech to show the investors that we've got engagement and traction. And yeah, there's always something. I think we're doing pretty good.
+MID-ROLL AD:

+ +

As life moves online, brick-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

CHAD: You mentioned that your three female founders have faced some bias, it sounds like, especially in talking with potential investors and seeking to grow your community. How has that been for you?

+ +

LUCY: You know, I don't want to put it down to being a female founder. I actually think the statistics tell us that, unfortunately. But I think what's the problem is that most of the people that I speak to in investment, either VCs or angels are guys, middle-aged guys between, say, late 30s to the 60s, and they are investing in businesses that they get.

+ +

They don't generally get a peer-to-peer fashion rental app for Gen Z. They're like, "Oh, they're going to want to ship things to each other, and like, what about the packaging?" And they've never heard of Depop. It just got bought by Etsy for $1.62 billion. It's a huge industry, and rental is just an evolution of resale. And they're like, "Oh, okay, kind of get it," but they don't really. We have to hand-hold them a lot through the pitch deck and get them excited. But that's, the problem is that we don't have enough women in the investment space or ex-founders.

+ +

I know in the U.S., it's a lot different. They have a lot more ex-founders investing, especially angel investors, which is great because they get the journey. Whereas if you have somebody with a financial services background, all they care about is the math of it. And it's like, you know what? Startups don't always just succeed on the math; it's the vision, it's the idea, it's the network effects, it's the audience. There are so many different things at play here. And if you've never started a business yourself, you just don't get that.

+ +

CHAD: There's a lot that goes into creating a company. And it may not be the fact that your female founders directly contribute to it but in an environment where they're looking for a reason not to invest.

+ +

LUCY: Exactly.

+ +

CHAD: That bias can creep into all of the excuses or differences that someone might point to and say, "Oh, this isn't going to work," or "I don't get this."

+ +

LUCY: 100%. If you've got a good business idea and you've got a strong pitch deck and a strong financial model, then that business will do well, for sure. However, there are so many other factors at play. And when there are so many great businesses competing against one another, they unbiasedly go with one over the other.

+ +

CHAD: So you also mentioned you have another excuse that people might use is you just don't have a technical founder on the founding team.

+ +

LUCY: That's definitely a struggle. We will be bringing in a CTO later in the year, which will be really exciting because it's definitely the missing piece to the puzzle. We have domain expertise in fashion. We have that side of it down. But yeah, the technical side of things, I think all the founders that I have spoken to that do have a CTO in the founding team or even have brought their technical team in-house just say it's a game changer.

+ +

When somebody is invested in your company, and they're using the platform every single day, they can see the bugs. I mean, Chaz from Fat Llama, which is a great rental app, said that his developers would pull out a laptop in the pub and be like, "Oh, I just saw a bug. Let me quickly fix it." I mean, wow, that would be insane.

+ +

Our developers finish at a certain time, and that's it; they're gone. So if we have a problem on an evening or even because they are in India they have a different time, we can't get hold of them. It's so frustrating.

+ +

CHAD: So when you start to build a team, will you be doing it based in the UK?

+ +

LUCY: Or based in Europe, at least. I think another thing to come out of the pandemic is this remote work, and I think that's great. I think there's so much talent across Europe, across the world. But for the timezone issue, I think Europe is definitely a better fit for us because we don't want to be having the same issues that we're having now with the time differences with India. But yeah, there's so much talent across the whole of Europe.

+ +

CHAD: Yeah, that's what we do at thoughtbot. We are all throughout the Americas, all throughout Europe, Middle East, and Africa. We've built our team. But we're grouped in by timezone. So people work with clients and with each other. And there, it's based on the timezone that they're in. And so that does make a big difference around how communication can work and how a part of the team you're able to feel because you're online at the same time as each other.

+ +

LUCY: Yeah. Definitely, that's a great show.

+ +

CHAD: But I definitely recommend casting as wide as possible. It definitely allows you to hire the best person for the job.

+ +

LUCY: Yeah, I think we need to find somebody that's passionate about the mission and who understands working with three co-founders that don't have a tech background that we probably do need a little bit more hand-holding than another founder would. We're learning so much as we go. Hopefully, we'll be coders one day.

+ +

[laughter]

+ +

CHAD: I actually don't think that. Some people might say, "Oh, you really should learn to code yourself." And I think that that does a disservice to what you are bringing to the table with your domain expertise and with your ability to really understand the industry and know what needs to happen from a business perspective.

+ +

LUCY: Yeah, I would totally agree. You can't be an expert in every part of the field. You can't be an accountant; you can't be a CTO. You need to be good at exactly what you do. And I'm the CEO, so I have an overview of everything. And that's what I love is kind of have a little finger on each little project that's going on and really get an understanding of across the board.

+ +

But you need those people that are drilling into, like, we have my co-founder, Jen, who's a graphic designer by trade, but she's our Chief Creative Officer. And she really drills down into the creative side of things. And she knows what she's talking about. And she is the expert in that, and that's so valuable.

+ +

CHAD: And I think that that's the important thing to founders to do early on is to really understand what their product and business are. You don't necessarily need to learn how to code. But I do think it's a mistake when early founders start stepping away from the product too early.

+ +

LUCY: Yeah, you need to be super close to the product. And you need good communication across all different divisions. So marketing and product have to talk to each other all the time, so we can tell our audience what's happening in the product, and then we can build the features that we need to grow from the marketing side of things. It's all about communication.

+ +

And it's so hard as a startup because there are so many different things going on and so many people pulling you from left to right. There are metrics to hit; there are bills to pay, there's audience, the community to keep happy. And it's like, oh, you can't drop the ball on anything. You really have to just do as much as you can. But if you communicate to each of those stakeholders, we're doing our best.

+ +

I mean, we had a mail-out the other day that said this is a business built by hands. It's built by people. I know we're a tech company, but there are real developers there hammering on their laptops. We're all here writing the copy and doing everything that we can to make this the most successful business so we can make real impact on the climate change and communities.

+ +

CHAD: I want to talk about that impact, but before we do, I'm curious, so you're all in the same general London area?

+ +

LUCY: No, we're not, actually. So Jade and Jen are based in London. And I actually moved out of London a couple of years ago, and I live in New York in the north of England.

+ +

CHAD: Oh, okay.

+ +

LUCY: See, definitely a different dynamic. And another reason why I'm passionate about bringing the fashion industry outside of London is because I travel up and down all the time, and I'm lucky it's like an hour 50 on the train. But that becomes expensive, and it's difficult to travel all the time.

+ +

CHAD: So, are you meeting in person with each other?

+ +

LUCY: We try. I just saw the girls last week. I'm seeing them again at the weekend. We speak every single day on Slack, WhatsApp. We have weekly calls, and we jump on pretty much video calls to each other every day. And that's, again, another thing from the pandemic that's been a game changer.

+ +

Because when I actually left, it was just before the pandemic. We were like, oh my God, how is this going to work? But I knew that it was the right decision for me. And then the pandemic hit, and everyone was on video calls. And we were like, oh, this is so easy. This is great. [laughs]

+ +

CHAD: Yeah, it really opened that up to everyone's expectations.

+ +

LUCY: Yeah, and I think it's great. I think it's much more flexible. And we will get an office for sure. But I would love to have an office here and an office in London so we can have teams across the nation. Because I think we don't all have to go and live in a capital city to get the same out of the fashion industry.

+ +

CHAD: Yeah. So let's talk about sustainability, the environment, and climate change. I am somewhat aware that an enormous amount of resources goes into creating new items of clothing.

+ +

LUCY: It's crazy. So the fashion industry accounts for 10% of the global greenhouse gas emissions at the moment. And if nothing changes by 2050, it will use a quarter of the world's carbon budget. It is insane, and it affects not only the planet but people. The garment workers are paid nothing. They're treated badly. And this is all part of the supply chains of fashion businesses.

+ +

And like I said, when I started in the fashion industry, e-commerce really was only just starting, and Jade, who is the model, was working for Asos, which is a big fashion brand and big fast fashion brand. So when she started working for them, she was shooting like 10-15 items, 20 items a day, and when she left, so five years later, they were shooting like 70 items per day. They were just churning out more and more fashion, more options.

+ +

And you can imagine most of the clothes are made...well, we have this whole disconnect about clothes. So I actually had a restaurant for three years in between my fashion career. And that's where I found sustainability because you have that connection with food. And you know that eating organic or eating locally and seasonally is better for you and better for the planet.

+ +

But nobody thinks that your clothes come from the ground. They're made from plants. Or if they're not made from plants, they're made from oil. It's nuts that people don't have as much education around it. And that's partly because the fashion industry doesn't want people to know, and it's a lot of smoke and mirrors. It's a very opaque industry. We went to one university, and they said that they thought all clothes were made from machines. They had no idea that there was cotton and linen. And so, like, wow, this is crazy.

+ +

CHAD: So given that it's the magnitude of the size of the problem but also the industry, there are two ways of looking at that, I'm sure, one is the potential for your impact is huge. The other is how do you get started? How can we have an impact there? So how are you tackling that?

+ +

LUCY: I get asked a lot by people, like, how can I start my sustainability journey? I feel so much pressure to do things. I should be vegan, or I'm not recycling enough. I got a plastic bag, oh, I feel terrible. And it's like we are all on a journey. And you just have to start one day at a time and just be more conscious.

+ +

So whether that's instead of buying one dress for a wedding that you are probably just going to stick in your wardrobe, why don't you rent it? Try one of the platforms that are out there, and you can rent a really cool dress, and that's probably someone else is going to rent it, and someone else is going to rent it. And by prolonging the life of an item, you can save so much energy and water. And those small things that we can each do will make a huge impact globally.

+ +

There's a lot of mindset shifting and behavioral change that needs to come with rental. As we saw with Airbnb when they started, people were like, "Oh God, I don't want someone sleeping in my bed," and now I Airbnb in my house all the time. And it's a great source of secondary income, especially for a startup founder [chuckles] but also giving people the opportunity to have these experiences in small communities, which I love.

+ +

And that's what we want to see with fashion is that people will start being more conscious. And how LOANHOOD is different to other more traditional rental systems is it's much more affordable. And it's much more accessible because you can meet in person.

+ +

So how we see it growing is these hyperlocal communities where you can meet people in person, a bit like Facebook Marketplace. They've done super well in more of the suburban areas. You can drop off your dress to somebody around the corner. So you're reducing the cost of delivery and reducing the emissions by meeting in person. So those hyperlocal communities will be really important in helping people adopt this behavior.

+ +

CHAD: Are you worried from a business perspective that if it's just renting to someone around the corner that they might not want to do it through LOANHOOD?

+ +

LUCY: I think people will still do it through the platform because of the added value that we give, you know, rental protection. I could go and borrow people's clothes like my friends in the area. I wouldn't do that. I might do it once or twice. I think if it's not somebody that you're really friendly with, then you would definitely do it through the platform.

+ +

CHAD: Yeah. And by rental protection, you mean if something gets damaged or that kind of thing, it's protected.

+ +

LUCY: We don't have full insurance yet because, again, the sharing economy is a new economy. And, of course, insurers are very old school. And it's hard for them to grasp the fact that there's a new industry here, but that is changing. And as soon as we have more data, we'll be able to get full insurance for these items. But right now, we do it in-house and protect items, minor damage, or repairs. And if it isn't returned or damaged beyond repair by the person that's renting it, then they have to cover the retail price of it.

+ +

CHAD: Yeah, makes sense. What's beyond rental platform in terms of this is where you decided to start, but your goal is to change the face of fashion? What's beyond?

+ +

LUCY: There are lots of different verticals that we can do within rental or in fashion. So we're really passionate about digital fashion. Jade, my business partner, is actually doing her Ph.D. in digital transformation in the metaverse. So how can we bring sustainability and ethical practices into the metaverse with fashion is something that we're really passionate about and something that we're exploring, renting different things so femtech, or skiwear, activewear, all those kind of things and then just creating a space for our community to grow creatively.

+ +

So entrepreneurship is really important to us as well, and giving people the opportunity to be...especially Gen Z they have this way that's called pay to create. So they're passionate about making money out of things that they can do themselves, whether that's creating content, renting out the things they own, upcycling. We want to expand on that and give them the tools to actually create their own career paths.

+ +

You don't have to go down the traditional university routes. We see a world where there's a LOANHOOD campus where you can come and learn how to be content creators or all sorts of different things. It's a really exciting time. And our 10-year plan keeps getting more bigger and bigger. And we're like, oh God, it's just exciting.

+ +

CHAD: Yet do you worry about spreading yourself too thin and compromising on the early steps?

+ +

LUCY: We always come back to the point of why we're doing this and who we're doing this for because what's the point? Otherwise, we're doing this to reduce impacts of the fashion industry on the planet and people. And we are doing this for our community and to give them the options and give them the power back.

+ +

As we've seen with governments around the world, people in leadership roles are not doing enough, and we can't rely on them. So if we want to create our own sustainable future, we have to do it ourselves. And we want to give people the tools to do that.

+ +

CHAD: Well, I wish you the best of luck in that. I'm very confident that you're going to have the impact you're looking for along the way, and I wish you the best in that. Thank you for stopping by and sharing with us. I really appreciate it.

+ +

LUCY: Thank you so much for having me. It was great to chat too.

+ +

CHAD: If folks want to find out more or get in touch with you or follow along, where are all the different places that they can do that?

+ +

LUCY: Check out our website, loanhood.com. If you are a founder and you want to talk about funding or building a product, marketing, you can email me lucy (L-U-C-Y) at lucy@loanhood.com. And we are on Instagram and TikTok @loanhood.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes which include a link to everything that Lucy just mentioned along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and I'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lucy Hall is the Co-Founder of LOANHOOD, an online fashion rental platform and community that allows users to loan inclusive, diverse, and creative styles for an affordable price.

+ +

Chad talks with Lucy about being a peer-to-peer fashion rental app, building a community, and reducing the impacts of the fashion industry on the planet and people by helping to create a sustainable future.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Lucy Hall, the Co-Founder of LOANHOOD, who are changing the face of fashion. Lucy, thank you so much for joining me.

+ +

LUCY: Thank you so much for having me, Chad.

+ +

CHAD: How are some of the ways that LOANHOOD is changing the face of fashion?

+ +

LUCY: So we're starting off with a peer-to-peer fashion rental app, which we just launched ten days ago now.

+ +

CHAD: Congratulations on the launch.

+ +

LUCY: It's been a long time in the making. And, like I said, we're starting with a fashion rental app. But there are so many different ways that we want to change the face of fashion. It definitely needs a facelift.

+ +

CHAD: What caused you to start with the rental platform?

+ +

LUCY: It was something that we were really passionate about. So my co-founders and I actually worked in the fashion industry for the majority of our careers. So we could see first-hand how it was changing, how it's developing. And sustainability started coming into our lives, and we could see that things had to change.

+ +

And we know that the fashion industry is quite archaic. Big fashion businesses are like these huge ships. It's so hard for them to change their course and to actually implement sustainability into their supply chains or their values. And we knew that we could do it quicker and better and faster than them.

+ +

So we started testing the idea of circular fashion by doing clothes swaps which is a kind of an entry-level way to circulate fashion for free or relatively cheaply. And we started getting this amazing feedback from people like, "Oh, we would love to do this again. And have you thought about monetizing it?" And, of course, that was our...to get to scale, we knew that we had to monetize this sharing of clothes. And that's how our peer-to-peer fashion rental app grew and was born.

+ +

CHAD: That's great. So you have two co-founders.

+ +

LUCY: I do.

+ +

CHAD: Jade and Jen. Were the three of you working together at the time?

+ +

LUCY: Funny story, Jade and I are actually best friends. And Jade was my model back in the day. So Jade has been a fashion model for 12-plus years. And she was on Britain's Next Top Model. And I was a model agent. She came into my agency as one of the runner-uppers, and we forged a lifelong friendship from there. And we've both been passionate about fashion. And then, as I said, our career paths, we could see the detrimental effect of the planet.

+ +

And Jade decided to go back to university and start studying. She did her master's in fashion futures at London College of Fashion. And that's where she started seeing sustainability. And the idea of a peer-to-peer rental came from that course. She was studying the future of fashion, and she knew that this was the only way we can move forward.

+ +

And Jen was a friend of Jade and is a graphic designer by trade and is an amazing brand builder and amazing designer. So we were asking her for some advice. And she came on as a co-founder at the beginning because she just knew this was the right path for her.

+ +

CHAD: You started with these swaps. Were you doing the swaps as friends because you felt it was the right thing to do? Or did you have an eye towards this could be something more?

+ +

LUCY: Well, we knew from the beginning that we wanted to do something big. We knew we'd got to a certain point in our careers where we were like, right, let's use our skills to really make a change. But we were also working, and we all had jobs, so we were kind of doing it as a side hustle, just testing the idea and going, "Oh yeah, we'll do this." And then it started picking up, and we got a contract with a local council. And we were like, wow, people are really interested in this. Let's keep going, and then the pandemic hit.

+ +

CHAD: How did the pandemic affect you?

+ +

LUCY: [chuckles] Well, as you can imagine, people weren't really doing clothes swaps or renting or even thinking about those things at the beginning of the pandemic anyhow. So we kind of just put it on hold and did what everyone did in the pandemic, hunkered down.

+ +

And we started learning as much as we could about the circular economy, about sharing economy, trust economy, marketing, product, really teaching ourselves from the bottom up what it takes to make a global brand. So we were quite lucky in the respect that we had that time away to really hone our skills and focus on what we wanted in the long term.

+ +

So post-pandemic, when we came out of the lockdowns, although there were multiple back and forth, as you know, it was definitely a stop-start for us, but we knew that it actually...it just allowed us that time to really focus our minds on what we wanted and a long-term plan, not just like, oh, let's try this out. We know what we want for the next 5 to 10 years, basically.

+ +

CHAD: At what point did you decide, okay, we have to make an app?

+ +

LUCY: It was a difficult one because we thought Shopify, Sharetribe there are all these amazing platforms. You can just get a business at the click of your fingers. However, for peer-to-peer fashion rental, it's a much more complex model. Even Sharetribe, which is supposed to be for those kinds of models it's not as detailed as we needed it to be. So we tried to build a website from scratch. And, again, we just knew that we're very much focused on Gen Z.

+ +

And when we were talking to our audience, we knew that they wanted an app. So we just scrapped it and said let's just go for it. But having no technical background was a real difficult decision for us because we had no funding. We'd all just left our jobs. The pandemic had happened, so we didn't have any savings really. So we had some money from the clothes swaps.

+ +

And we did a rewards-based Crowdfunder, and we raised £14,000 from friends and family in our community that were buying free rentals for the future and just believed in the mission that we were on. And we were able to get that £14,000 and put it into the start of building an app. And as you're aware, apps cost a lot of money.

+ +

CHAD: [laughs]

+ +

LUCY: We didn't get that far. And we learned a lot of lessons with the build because we tried to project manage it ourselves. Having no technical background, that was tricky. And we offshored it to a team in India who were lovely and amazing but not as skilled as we needed them to be. Because we had no technical background, we really needed somebody to lead that for us.

+ +

So we had a starting point, but we knew that we had to actually get a technical lead on board pretty soon. And we were lucky enough to find a partner in a company called ON, who are based in the UK. And with them on board, they led the tech from there on.

+ +

CHAD: Continuing to work with that team in India, or did they actually provide the entire team at that point?

+ +

LUCY: We switched to another offshore team because it costs so much money here in the UK.

+ +

CHAD: So when was this all happening?

+ +

LUCY: Last year, mainly. 2021.

+ +

CHAD: To give folks an idea, you make the decision to start building an app. You start doing that in 2021. You just launched. But your business is more than just the app. Were you right up to the wire with the app being ready?

+ +

LUCY: Like you said, we're building a community. And what we learned from the pandemic is that you can't rely on one part of your business to help you succeed. You need multiple things. And what we're passionate about more than anything is community. And what we found with the fashion industry is that it can be quite elitist.

+ +

And if you want to work in the fashion industry, you have to move to London or New York or Paris, and you have to probably know somebody in the fashion industry, and we wanted to change that. We wanted you to be able to start your own fashion journey wherever you are based.

+ +

And what we also saw was that all this money that people were spending on fashion was going to big fashion businesses and to probably one guy at the top of that chain, whereas, with peer-to-peer rental, you can actually circulate that money within communities. You're lifting communities up so they can create their own sustainable fashion future. So what was really important to us was to have community as one of our main pillars going forward.

+ +

CHAD: And how have you gone about building that community?

+ +

LUCY: Organically so far, which has been really nice. And again, the events that we do have been part of that. But to scale, we really need to start building out ambassador programs, referral systems that can help us hit those kinds of network effects.

+ +

CHAD: So I know you're only in the UK.

+ +

LUCY: Correct.

+ +

CHAD: What are the limiting factors to expansion beyond the UK?

+ +

LUCY: Money, obviously.

+ +

CHAD: [laughs] Okay.

+ +

LUCY: We’re on a funding journey at the moment, and that's a ride for sure. So we kind of use the Depop playbook. Do you know Depop? You're probably over 25, so that's probably why you don't know it.

+ +

CHAD: [laughs] Yes.

+ +

LUCY: A third of 16 to 25-year-olds are on Depop in the UK. It's the 10th most-searched-for resale platform in the U.S. And they started off in the UK, and they organically grew into the U.S., which is nuts. We probably won't do that, of course, but we plan to go to the U.S. potentially next. But it depends on investment, on what our audience is saying, where they're based.

+ +

What we find with our audiences, the universities that we partner with we have a lot of international students. So they're taking that idea back to their hometowns, which is really interesting. But on a tech front, going into the U.S. is easier because it's an English-speaking country. Going into Europe is a bit more complex because you have lots of different languages, although you have one single currency, which is helpful.

+ +

CHAD: Since your model is peer-to-peer, individuals are sending the rented item directly to the person who's renting it, right?

+ +

LUCY: That's correct, yeah.

+ +

CHAD: And so I suppose one potential barrier is you don't need to be able to receive centrally or to handle things in the United States. But you need enough people in the U.S. to make it worthwhile for individuals to be sending each other things to have enough rentals and activity.

+ +

LUCY: Always, the problem with the marketplace is the cold start problem. There is a great book by Andrew Chen called The Cold Start Problem. And we really need to build both the supply side, which we call the loaner, and the demand side, which we call the borrower. So we have been working really hard in the UK to get as many of the supply side on board because we know the people that we want to be on the platform, so emerging designers, young makers, and creators.

+ +

And because we have our fashion backgrounds, we can identify those people quite quickly. And we've done things that are totally not scalable, like messaging them on Instagram and scouting people in the streets. But as a small startup, you kind of have to do those scrappy things as well just to kind of build the supply side.

+ +

CHAD: Right. And I think that's why so many marketplaces end up focusing on particular geographies even if they could expand because that focus helps you do those unscalable things that you need to do in the early days to bootstrap that community that you need for the marketplace.

+ +

It hadn't occurred to me until you just said it that I've been thinking that this would totally be individuals, but for an emerging fashion designer to be on your community offering up their clothing for rental, that hadn't even occurred to me as a possibility.

+ +

LUCY: Something that we're passionate about, especially post-pandemic, a lot of young people that are either at university and didn't get the real university experience had to make some extra money started these side hustles of teaching themselves to crochet or teaching themselves to knit. And now they have these amazing pieces, and they're open to renting them out as well as doing their retail side of it.

+ +

And what we found from the resale people, so the Depopers or people on Vinted, was that they'd get this kind of seller's remorse. So they'd upload the item, take amazing pictures, and they'd sell it once. But with rental, you upload it, and you can rent it out over and over and over again. And you still get to keep it and wear it yourself, so a bit of a no-brainer.

+ +

CHAD: Yeah. So you went on the journey of creating the app, creating the community. You've just launched. So are you actively fundraising?

+ +

LUCY: We are actively fundraising. We're just closing our pre-seed round. And we were very lucky to have an incredible lead investor come on board. He just got the idea instantly. What we found difficult is being female founders who don't have tech backgrounds; it's definitely a couple of negatives against us. [laughs] But we're going to use it to our advantage, and the people that are on the journey with us now 100% are behind us and believe in what we're doing. Because we're an impact business as well as we want to have profit alongside people and planet, that's what's important to us to make impact socially, environmentally, and through the industry.

+ +

So the next step of our fundraising journey will be a crowdfund, an equity-based crowdfund. So we did the rewards-based crowdfunder last year. This year, it's going to be equity-based because we really believe that we're building this platform for our community, our audience. So they should be able to invest in us and come on that journey with us. And hopefully, the business grows to huge proportions, and that they can get some money back out of that later in their lives.

+ +

CHAD: Are you going to be using a platform to do that?

+ +

LUCY: We are undecided, although I'm leaning over to between one and another. There are only two platforms really in the UK, so Seedrs and Crowdcube. And I've spoken to some other founders that have done both platforms. And I've spoken to both the companies. I've looked at articles trying to find which one's the best fit for us.

+ +

One interesting thing that we had with the Crowdfunder was we were deciding between Kickstarter and Crowdfunder UK. And Kickstarter is very much more focused on men, more sports, definitely a male demographic, so that's why we went with Crowdfunder.

+ +

With Seedrs and Crowdcube, they don't have that; it's a very equal split. So it's just on the feedback that we've had from other people that have used those platforms. So I'm leaning towards one, but I won't say yet because I haven't fully decided.

+ +

CHAD: So you're only allowed to do that with people in the UK?

+ +

LUCY: I think it can be global, actually.

+ +

CHAD: Are you planning on having it be global?

+ +

LUCY: We have friends and family all across the world. I spoke to somebody today in Lithuania. I spoke to somebody the other day in Australia. I speak to people in the U.S. all the time that are like, "When are you coming to us?" [chuckles]

+ +

CHAD: Yeah, that'll be interesting; the fact that you're able to do the equity crowdfund anywhere, but people won't be able to actually use the product right away. You know, it's sort of a catch-22; you've got to have one before you can have the other. And so, hopefully, people go along on the journey.

+ +

LUCY: Chicken and the egg. We need the money to build the tech, to build the audience. But we need the audience and the tech to show the investors that we've got engagement and traction. And yeah, there's always something. I think we're doing pretty good.
+MID-ROLL AD:

+ +

As life moves online, brick-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode.

+ +

CHAD: You mentioned that your three female founders have faced some bias, it sounds like, especially in talking with potential investors and seeking to grow your community. How has that been for you?

+ +

LUCY: You know, I don't want to put it down to being a female founder. I actually think the statistics tell us that, unfortunately. But I think what's the problem is that most of the people that I speak to in investment, either VCs or angels are guys, middle-aged guys between, say, late 30s to the 60s, and they are investing in businesses that they get.

+ +

They don't generally get a peer-to-peer fashion rental app for Gen Z. They're like, "Oh, they're going to want to ship things to each other, and like, what about the packaging?" And they've never heard of Depop. It just got bought by Etsy for $1.62 billion. It's a huge industry, and rental is just an evolution of resale. And they're like, "Oh, okay, kind of get it," but they don't really. We have to hand-hold them a lot through the pitch deck and get them excited. But that's, the problem is that we don't have enough women in the investment space or ex-founders.

+ +

I know in the U.S., it's a lot different. They have a lot more ex-founders investing, especially angel investors, which is great because they get the journey. Whereas if you have somebody with a financial services background, all they care about is the math of it. And it's like, you know what? Startups don't always just succeed on the math; it's the vision, it's the idea, it's the network effects, it's the audience. There are so many different things at play here. And if you've never started a business yourself, you just don't get that.

+ +

CHAD: There's a lot that goes into creating a company. And it may not be the fact that your female founders directly contribute to it but in an environment where they're looking for a reason not to invest.

+ +

LUCY: Exactly.

+ +

CHAD: That bias can creep into all of the excuses or differences that someone might point to and say, "Oh, this isn't going to work," or "I don't get this."

+ +

LUCY: 100%. If you've got a good business idea and you've got a strong pitch deck and a strong financial model, then that business will do well, for sure. However, there are so many other factors at play. And when there are so many great businesses competing against one another, they unbiasedly go with one over the other.

+ +

CHAD: So you also mentioned you have another excuse that people might use is you just don't have a technical founder on the founding team.

+ +

LUCY: That's definitely a struggle. We will be bringing in a CTO later in the year, which will be really exciting because it's definitely the missing piece to the puzzle. We have domain expertise in fashion. We have that side of it down. But yeah, the technical side of things, I think all the founders that I have spoken to that do have a CTO in the founding team or even have brought their technical team in-house just say it's a game changer.

+ +

When somebody is invested in your company, and they're using the platform every single day, they can see the bugs. I mean, Chaz from Fat Llama, which is a great rental app, said that his developers would pull out a laptop in the pub and be like, "Oh, I just saw a bug. Let me quickly fix it." I mean, wow, that would be insane.

+ +

Our developers finish at a certain time, and that's it; they're gone. So if we have a problem on an evening or even because they are in India they have a different time, we can't get hold of them. It's so frustrating.

+ +

CHAD: So when you start to build a team, will you be doing it based in the UK?

+ +

LUCY: Or based in Europe, at least. I think another thing to come out of the pandemic is this remote work, and I think that's great. I think there's so much talent across Europe, across the world. But for the timezone issue, I think Europe is definitely a better fit for us because we don't want to be having the same issues that we're having now with the time differences with India. But yeah, there's so much talent across the whole of Europe.

+ +

CHAD: Yeah, that's what we do at thoughtbot. We are all throughout the Americas, all throughout Europe, Middle East, and Africa. We've built our team. But we're grouped in by timezone. So people work with clients and with each other. And there, it's based on the timezone that they're in. And so that does make a big difference around how communication can work and how a part of the team you're able to feel because you're online at the same time as each other.

+ +

LUCY: Yeah. Definitely, that's a great show.

+ +

CHAD: But I definitely recommend casting as wide as possible. It definitely allows you to hire the best person for the job.

+ +

LUCY: Yeah, I think we need to find somebody that's passionate about the mission and who understands working with three co-founders that don't have a tech background that we probably do need a little bit more hand-holding than another founder would. We're learning so much as we go. Hopefully, we'll be coders one day.

+ +

[laughter]

+ +

CHAD: I actually don't think that. Some people might say, "Oh, you really should learn to code yourself." And I think that that does a disservice to what you are bringing to the table with your domain expertise and with your ability to really understand the industry and know what needs to happen from a business perspective.

+ +

LUCY: Yeah, I would totally agree. You can't be an expert in every part of the field. You can't be an accountant; you can't be a CTO. You need to be good at exactly what you do. And I'm the CEO, so I have an overview of everything. And that's what I love is kind of have a little finger on each little project that's going on and really get an understanding of across the board.

+ +

But you need those people that are drilling into, like, we have my co-founder, Jen, who's a graphic designer by trade, but she's our Chief Creative Officer. And she really drills down into the creative side of things. And she knows what she's talking about. And she is the expert in that, and that's so valuable.

+ +

CHAD: And I think that that's the important thing to founders to do early on is to really understand what their product and business are. You don't necessarily need to learn how to code. But I do think it's a mistake when early founders start stepping away from the product too early.

+ +

LUCY: Yeah, you need to be super close to the product. And you need good communication across all different divisions. So marketing and product have to talk to each other all the time, so we can tell our audience what's happening in the product, and then we can build the features that we need to grow from the marketing side of things. It's all about communication.

+ +

And it's so hard as a startup because there are so many different things going on and so many people pulling you from left to right. There are metrics to hit; there are bills to pay, there's audience, the community to keep happy. And it's like, oh, you can't drop the ball on anything. You really have to just do as much as you can. But if you communicate to each of those stakeholders, we're doing our best.

+ +

I mean, we had a mail-out the other day that said this is a business built by hands. It's built by people. I know we're a tech company, but there are real developers there hammering on their laptops. We're all here writing the copy and doing everything that we can to make this the most successful business so we can make real impact on the climate change and communities.

+ +

CHAD: I want to talk about that impact, but before we do, I'm curious, so you're all in the same general London area?

+ +

LUCY: No, we're not, actually. So Jade and Jen are based in London. And I actually moved out of London a couple of years ago, and I live in New York in the north of England.

+ +

CHAD: Oh, okay.

+ +

LUCY: See, definitely a different dynamic. And another reason why I'm passionate about bringing the fashion industry outside of London is because I travel up and down all the time, and I'm lucky it's like an hour 50 on the train. But that becomes expensive, and it's difficult to travel all the time.

+ +

CHAD: So, are you meeting in person with each other?

+ +

LUCY: We try. I just saw the girls last week. I'm seeing them again at the weekend. We speak every single day on Slack, WhatsApp. We have weekly calls, and we jump on pretty much video calls to each other every day. And that's, again, another thing from the pandemic that's been a game changer.

+ +

Because when I actually left, it was just before the pandemic. We were like, oh my God, how is this going to work? But I knew that it was the right decision for me. And then the pandemic hit, and everyone was on video calls. And we were like, oh, this is so easy. This is great. [laughs]

+ +

CHAD: Yeah, it really opened that up to everyone's expectations.

+ +

LUCY: Yeah, and I think it's great. I think it's much more flexible. And we will get an office for sure. But I would love to have an office here and an office in London so we can have teams across the nation. Because I think we don't all have to go and live in a capital city to get the same out of the fashion industry.

+ +

CHAD: Yeah. So let's talk about sustainability, the environment, and climate change. I am somewhat aware that an enormous amount of resources goes into creating new items of clothing.

+ +

LUCY: It's crazy. So the fashion industry accounts for 10% of the global greenhouse gas emissions at the moment. And if nothing changes by 2050, it will use a quarter of the world's carbon budget. It is insane, and it affects not only the planet but people. The garment workers are paid nothing. They're treated badly. And this is all part of the supply chains of fashion businesses.

+ +

And like I said, when I started in the fashion industry, e-commerce really was only just starting, and Jade, who is the model, was working for Asos, which is a big fashion brand and big fast fashion brand. So when she started working for them, she was shooting like 10-15 items, 20 items a day, and when she left, so five years later, they were shooting like 70 items per day. They were just churning out more and more fashion, more options.

+ +

And you can imagine most of the clothes are made...well, we have this whole disconnect about clothes. So I actually had a restaurant for three years in between my fashion career. And that's where I found sustainability because you have that connection with food. And you know that eating organic or eating locally and seasonally is better for you and better for the planet.

+ +

But nobody thinks that your clothes come from the ground. They're made from plants. Or if they're not made from plants, they're made from oil. It's nuts that people don't have as much education around it. And that's partly because the fashion industry doesn't want people to know, and it's a lot of smoke and mirrors. It's a very opaque industry. We went to one university, and they said that they thought all clothes were made from machines. They had no idea that there was cotton and linen. And so, like, wow, this is crazy.

+ +

CHAD: So given that it's the magnitude of the size of the problem but also the industry, there are two ways of looking at that, I'm sure, one is the potential for your impact is huge. The other is how do you get started? How can we have an impact there? So how are you tackling that?

+ +

LUCY: I get asked a lot by people, like, how can I start my sustainability journey? I feel so much pressure to do things. I should be vegan, or I'm not recycling enough. I got a plastic bag, oh, I feel terrible. And it's like we are all on a journey. And you just have to start one day at a time and just be more conscious.

+ +

So whether that's instead of buying one dress for a wedding that you are probably just going to stick in your wardrobe, why don't you rent it? Try one of the platforms that are out there, and you can rent a really cool dress, and that's probably someone else is going to rent it, and someone else is going to rent it. And by prolonging the life of an item, you can save so much energy and water. And those small things that we can each do will make a huge impact globally.

+ +

There's a lot of mindset shifting and behavioral change that needs to come with rental. As we saw with Airbnb when they started, people were like, "Oh God, I don't want someone sleeping in my bed," and now I Airbnb in my house all the time. And it's a great source of secondary income, especially for a startup founder [chuckles] but also giving people the opportunity to have these experiences in small communities, which I love.

+ +

And that's what we want to see with fashion is that people will start being more conscious. And how LOANHOOD is different to other more traditional rental systems is it's much more affordable. And it's much more accessible because you can meet in person.

+ +

So how we see it growing is these hyperlocal communities where you can meet people in person, a bit like Facebook Marketplace. They've done super well in more of the suburban areas. You can drop off your dress to somebody around the corner. So you're reducing the cost of delivery and reducing the emissions by meeting in person. So those hyperlocal communities will be really important in helping people adopt this behavior.

+ +

CHAD: Are you worried from a business perspective that if it's just renting to someone around the corner that they might not want to do it through LOANHOOD?

+ +

LUCY: I think people will still do it through the platform because of the added value that we give, you know, rental protection. I could go and borrow people's clothes like my friends in the area. I wouldn't do that. I might do it once or twice. I think if it's not somebody that you're really friendly with, then you would definitely do it through the platform.

+ +

CHAD: Yeah. And by rental protection, you mean if something gets damaged or that kind of thing, it's protected.

+ +

LUCY: We don't have full insurance yet because, again, the sharing economy is a new economy. And, of course, insurers are very old school. And it's hard for them to grasp the fact that there's a new industry here, but that is changing. And as soon as we have more data, we'll be able to get full insurance for these items. But right now, we do it in-house and protect items, minor damage, or repairs. And if it isn't returned or damaged beyond repair by the person that's renting it, then they have to cover the retail price of it.

+ +

CHAD: Yeah, makes sense. What's beyond rental platform in terms of this is where you decided to start, but your goal is to change the face of fashion? What's beyond?

+ +

LUCY: There are lots of different verticals that we can do within rental or in fashion. So we're really passionate about digital fashion. Jade, my business partner, is actually doing her Ph.D. in digital transformation in the metaverse. So how can we bring sustainability and ethical practices into the metaverse with fashion is something that we're really passionate about and something that we're exploring, renting different things so femtech, or skiwear, activewear, all those kind of things and then just creating a space for our community to grow creatively.

+ +

So entrepreneurship is really important to us as well, and giving people the opportunity to be...especially Gen Z they have this way that's called pay to create. So they're passionate about making money out of things that they can do themselves, whether that's creating content, renting out the things they own, upcycling. We want to expand on that and give them the tools to actually create their own career paths.

+ +

You don't have to go down the traditional university routes. We see a world where there's a LOANHOOD campus where you can come and learn how to be content creators or all sorts of different things. It's a really exciting time. And our 10-year plan keeps getting more bigger and bigger. And we're like, oh God, it's just exciting.

+ +

CHAD: Yet do you worry about spreading yourself too thin and compromising on the early steps?

+ +

LUCY: We always come back to the point of why we're doing this and who we're doing this for because what's the point? Otherwise, we're doing this to reduce impacts of the fashion industry on the planet and people. And we are doing this for our community and to give them the options and give them the power back.

+ +

As we've seen with governments around the world, people in leadership roles are not doing enough, and we can't rely on them. So if we want to create our own sustainable future, we have to do it ourselves. And we want to give people the tools to do that.

+ +

CHAD: Well, I wish you the best of luck in that. I'm very confident that you're going to have the impact you're looking for along the way, and I wish you the best in that. Thank you for stopping by and sharing with us. I really appreciate it.

+ +

LUCY: Thank you so much for having me. It was great to chat too.

+ +

CHAD: If folks want to find out more or get in touch with you or follow along, where are all the different places that they can do that?

+ +

LUCY: Check out our website, loanhood.com. If you are a founder and you want to talk about funding or building a product, marketing, you can email me lucy (L-U-C-Y) at lucy@loanhood.com. And we are on Instagram and TikTok @loanhood.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes which include a link to everything that Lucy just mentioned along with a complete transcript for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and I'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jcgLPRb4 + + ]]> + + Chad Pytel + + + 438: Bright Ventures with Lenore Champagne Beirne + https://podcast.thoughtbot.com/438 + f2384a39-7a90-49af-a56f-e3e5d0686cbe + Thu, 01 Sep 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Lenore Champagne Beirne is Founder and Managing Partner at Bright Ventures, a groundbreaking space for transformation in people, companies, and industries with coaching, capital, and community. + +Chad talks with Lenore about being at the intersection of all three of those services, providing support for diverse entrepreneurs, and staying intentional about the kind of company and culture they're creating. + 24:56 + no + + + Lenore Champagne Beirne is Founder and Managing Partner at Bright Ventures, a groundbreaking space for transformation in people, companies, and industries with coaching, capital, and community. +Chad talks with Lenore about being at the intersection of all three of those services, providing support for diverse entrepreneurs, and staying intentional about the kind of company and culture they're creating. +Bright Ventures (https://www.brightventures.io/) +Follow Bright Ventures on Twitter (https://twitter.com/brightventures2), Instagram (https://www.instagram.com/brightventuresnyc/), Medium (https://brightventures.medium.com/about), or LinkedIn (https://www.linkedin.com/company/bright-ventures-io/). +Follow Lenore on LinkedIn (https://www.linkedin.com/in/lenorechampagnebeirne/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Lenore Champagne Beirne, Founder and Managing Partner at Bright Ventures, a groundbreaking space for transformation in people, companies, and industries with coaching, capital, and community. Lenore, thank you so much for joining me. +LENORE: Absolutely. Thanks for having me, Chad. +CHAD: Bright Ventures, I love the three things: coaching, capital, and community. Would you say at the core you are a venture capital firm? Or is it really the intersection of all three of those services? +LENORE: It is truly the intersection of all three of those services. In fact, I started Bright Ventures because of a gap that I saw in the capital markets. But the first thing that we came to market with was coaching. And we learned so much from coaching diverse entrepreneurs and investors, and operators that we saw ways to add value to those groups and ultimately built the accelerator and venture capital fund and a number of other programs. +CHAD: Like most companies, I think what you have is relatively unique. Most companies are a coaching company or a venture capital fund. Do you get pushback, or are there concerns about doing too much? +LENORE: We've heard that question, although I don't know that the same question would be posed, at least in the same way, to a man, especially if it were a White man. But that aside, the reason we get the question is because I personally have led the launch of each new phase of the company. And what has really given our investors and also our partners comfort is that as we've expanded, we've also massively expanded the leadership and the skill set of the Bright Ventures team. +So I would say at our heart, we are a transformation company. We make inclusive innovation possible. We define that as building a future that works for all of us together. We make that possible. And we know that because that's a huge, gnarly, complex, nuanced issue, you have to have a multipronged solution. And so, for us, the combination of individual and systems transformation through coaching, community where we can practice and learn, and capital that actually shifts how businesses can operate is the right set of interventions. +CHAD: So one of the things venture capitalists often give feedback to their clients about is either doing too much or mixing business models. So like, oh, you shouldn't do consulting because what you have is a product company. They are different revenue streams, and different ways of working, and different ways of generating money. How do you balance those different business models that are within your organization? +LENORE: Well, I think, as I mentioned, the business models that we have inside of Bright Ventures are intended to solve the same really big problem in different ways through different angles. So what we have found is that there are a lot of early-stage ventures that would benefit from the kind of coaching that we offer. +But coaching is typically a really high-dollar item, only available to kind of an exclusive few. And so, it became clear to us that building a community with more scalable programs could meet the need of the stakeholder that we're interested in. And that has driven, time and time again, the business models that drive and organize our work at Bright Ventures. +CHAD: Yeah, I realize part of what's on my mind is say you're working with a founder and you invest in that founder or a founding team and a founding company, do they no longer become a coaching client that's actually paying you money for coaching? Or do they get it for free? +LENORE: Mm-hmm. So founders in our venture portfolio have access to the full suite of our services. And obviously, it's in the Bright Ventures entities' best interest to see those companies win and to give them all the resources and support that they need. You're asking these questions about business models. +One thing I should clarify is that we don't have just a single business operating entity at Bright Ventures. The venture fund entity is a traditional GP LP structure that exists to invest in, yes, maybe some of the companies that we serve through our services business, but also a broad swath of companies across the U.S. at early stage. +There's then a pretty straightforward consulting firm that we have that also goes by the name Bright Ventures but is a different legal and operational entity. So there's no proprietary information shared across those lines that are different management teams. What unites the Bright Ventures entities is a commitment to inclusive innovation and a set of frameworks that we have seen now proven to drive inclusive outcomes as a competitive advantage in venture. +CHAD: Oh, that's awesome clarification. One of the things that we've struggled with a little bit at thoughtbot is we do a lot at thoughtbot. It's probably one of the reasons why I'm asking these questions about balancing. And sometimes, I do think, oh, it could benefit us if they were separate entities. +LENORE: How have you all thought about that so far? +CHAD: For the most part, what we do is we run separate P&Ls for the different business lines or the different offerings, but it's all actually one entity as long as it doesn't cross country boundaries. We have a different entity for Europe. +LENORE: Got it. I asked because I'm curious because, at some point in the next couple of years, we'll probably do one more entity. And we're talking internally now about the moment that that will be the right thing to do, not yet. But good to hear that you're thinking about that as well. +CHAD: Yeah. What was the part of your journey where...you mentioned you started to see this need. How did that need or seeing that need jump from that to I'm starting out; this is a real thing? +LENORE: It's blurry. The lines are blurry for me, particularly as the founder of Bright, because I have been working on effectively pulling the same threads as long as I can remember, even before Bright Ventures had a name and was an entity. And so, for as long as I can remember, I've been confounded, frustrated [laughs] by and working on the inequity of access to capital and to opportunity in entrepreneurship and in many other expressions of wealth creation. +I've also, for as long as I can remember, thought a lot about how people think, and how they relate to themselves, and how they relate to other people. And truly, I can remember experimenting with these ideas when I was really young, maybe even less than ten years old. I then remember experimenting with them in college and trying to create a major for myself because I was trying to understand the intersections of these questions. +Officially, it was in 2014 that I launched Bright Ventures as the strategic advisory firm that I mentioned we came to market with. And that was because I had just come off of a really important career experience. I was living and working in Haiti on a program funded by the U.S. government to invest in and then provide support for entrepreneur organizations so like small businesses, social enterprises in Haiti. And I loved that work. It was super challenging, really rewarding, really interesting. +But it also opened up in me this question about what entrepreneurs actually needed for support and how to support other investors and seeing potential where I saw it but that the markets might be missing it. And so, in 2014, I had enough of an idea about some of what was missing to get started. And to the point of the line or, like, okay, I'm going do this now, that's when that happened. +CHAD: I've had a whole bunch of guests on who talk about issues of inclusion, and particularly access or being excluded from funding and opportunity. And I'm curious, from your perspective, what kind of support do founders who are typically excluded or underrepresented most need, especially on day one? +LENORE: Well, one thing that I have found really fascinating about support for diverse entrepreneurs is that we often, as a whole, I'm speaking like we in a very big sense, tend to assume that there is a homogenous set of supports that are required. And this gets to that question about business models and how we make sure that we actually have at Bright Ventures a diversity of ways to help people. +What we've learned is that diverse entrepreneurs are not a particularly homogenous bunch. And there are a couple of things that seem to be consistent for certain groups that we have worked hard to build frameworks and models for. One of those things is mindset shift and personal leadership development. That was executive coaching for us. We developed a specialty in helping people who are systematically in out-of-power positions move into in-power positions, and that was through a series of coaching frameworks and leadership frameworks that we would deliver. +We also learned that in order to do that durably and sustainably, you also had to go and coach and train the people who might be excluding those entrepreneurs. So we started to develop expertise in working directly with investors and helping them see the brilliance and maybe overlooked opportunity in diverse entrepreneurs. Those were two. +We also have some skill-based programming where we help people inside large organizations and also brand new ones think about how to tactically build inclusion into the way that they run their day-to-day. And we finally, of course, have some capital programs where we invest directly in diverse entrepreneurs, which we know are vastly underrepresented in the capital markets. +CHAD: You use the word tactical, which I think is a really interesting one because a lot of times, especially on the show, we might talk about strategic things, which is different than tactical. So what does tactical inclusion mean to you? +LENORE: So it does start with the strategy. There has to be a business model that makes inclusion possible. Otherwise, we're kind of putting a Band-Aid on a really big open wound. But if there's a business model that makes it possible to take reasonable care of your employees and leave your customers better off than they were before they met you, then tactical inclusion is things like understanding how to delegate, how to give feedback, how to hold meetings in ways that actually bring out the best in your team, and how to collect product feedback that's truly representative of the full swath of people who not only use your product today but maybe are impacted by it throughout your value chain, or might use it tomorrow if you made some innovative choices in product design and development. +And so we say tactical, and we highlight that because what we have found is that much of the conversation about inclusion and certainly about diversity lives at this very theoretical level. It ends up being like an ideology, an aspiration, and we don't think that's sufficient. We think you have to actually make it how you behave. And so that tends to be where we focus both in our training and in our evaluation of inclusion in other companies. +CHAD: One of the problems that we sometimes see, and we see it in our clients, too, is not everybody responds to training in the same way, particularly if it's like, watch this video. Sometimes there will be not very much participation in that at all. Or even if you're just watching it, maybe you're not giving it your full attention. What does the training that you give actually look like? +LENORE: What you just said is exactly why we looked for other things to name what we do because training gets such a bad rap. +CHAD: [laughs] Yeah. +LENORE: But what we learned about training is, I mean, this seems so obvious, Chad, but it has to actually be a skill that the person will obviously benefit from implementing immediately. So the first thing is like, do you need to and want to and recognize the need to learn this? We only go in with training when we can see that there's general consensus that it'll provide real value, business value, personal value, cultural value in the company. +The second thing is that we recognize that people's attention spans are shorter on average. And so what we do with training is make it highly experiential. We'll introduce a concept and then show you a way to practice it right away, as in, within the same 20-minute span. We also then give folks an opportunity to practice live and get feedback. And we only apply training to real-life decisions that managers or leaders are thinking about right in that moment. So for us, again, you asked about this word tactical. It really comes down to how deeply we can tie the training to the person's motivation and their ability to apply it. +Mid-Roll Ad: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops +CHAD: Another pressure I see in the startup world, in general, is this idea of we don't have time to stop. We've got to go. We've got to do this. We've got to do that. And taking the time to actually be really intentional about the kind of company and the kind of culture you're creating when you may be so focused on the business you're creating or the product you're creating sometimes goes by the wayside. Do you spend time trying to fix that problem? Or do you seek out people who are ready for what you have? +LENORE: We do an assessment in the beginning, at Bright Ventures, we called it culture audit, to determine the readiness of a culture for the depth of work that we can bring. And we have different ways of engaging depending on where the company is today. We also ask companies to self-identify. Like, how deep are you really interested in going? What kind of outcomes are important to you? And so there's a bit of we've built our frameworks in a modular way so that we can mix and match them to the environment, the strategy, the leadership, the goals of each of our clients. +CHAD: I'm curious, from an investor standpoint then, what makes pre-seed, seed companies potential when you have your investor hat on the right kind of companies for Bright Ventures? +LENORE: Yeah, we're really excited about companies that have an early signal of building inclusion into the fabric of the business model. And you can usually see that based on the way that the founder is building a team. It's not always...sometimes it's so few people that it's just not enough people to really assess diversity, as is sometimes the case. But you can tell how a founder thinks about divergent opinions, about different perspectives, and about the pipeline of people that they're seeking out to build a company with. +The other way that we look for inclusion in the pre-seed and seed stage is really in the business model. And again, the word tactical, like, is this product or service...who is it designed to serve? And how is it designed to leave them? Are the questions that we tend to ask. And what we have found is that if you invest for inclusion, 85% of the time, that is overlapped with investing in diverse founders, but it's not 100% of the time. And again, our lens on that is that inclusion is a behavior, not an identity. +And so we're looking for any founder who's building inside of the paradigms I mentioned earlier, irrespective of demographics. And we particularly get excited; in the next ten years, we think there's a lot to be built in digital health and in FinTech, in the broadest sense, Web3 and Web2 FinTech for I think a lot of inclusive business models to emerge there. Also really excited about future of work as a place where I think inclusion will be a massive competitive advantage. +CHAD: So many companies are starting remote or are fully remote. Is the training that you give or the advice you're providing in terms of tactical inclusion does it differ for in-person versus remote companies? +LENORE: There's a consistent framework or set of questions that you can answer those questions in lots of ways. So if I ask the question like, how does your team get to know one another? The answer to that could be very different if your company sits together every day and actually you unwind on Fridays together. Versus if you're a fully remote company in multiple time zones, sometimes even multiple languages, the answer can be different, but we still know that the team feeling cohesive is a key ingredient for inclusion. +And so we're looking for how your company does it and that your company does it, not that it does it in a certain way. So we try to help our clients see their companies as systems in the way that we do so that they can see how is the fact that your team feels cohesive related to the way your team generates new ideas or brings new products to market? And then, we trust management and leadership to design the right specific ways to have that expressed in that company. +CHAD: What advice...someone who is just getting started and is just getting started out maybe has an idea, maybe it's a founding team, a team of co-founders. They're very early stage. Are there some things that you would recommend that they either do or avoid doing in order to lay a good groundwork for an inclusive team and company? +LENORE: Yeah, absolutely. The building block, like the fundamental input for inclusion, is listening, and so we have done a ton of resources on how to practice listening, how to know if you are listening. But you can't build a system that dynamically includes other groups without really understanding those groups. Listening is really important. Another thing is I find that it helps people build more inclusively when they go through the exercise of seeking out opinions that really differ from their own. And beyond, I think what people typically mean when they say playing devil's advocate, really trying to understand like, why does that work? +So one of the things that founders who have built inclusively have really interrogated is who their target market is. And I have found that it's really useful to go through the exercise of making it incredibly narrow, like very exclusive, so you understand your assumptions around who your target market is. And then asking yourself, what does that group, that very narrowly defined group, have in common with other groups that I've crossed off the list? Looking through the lens of what unites diverse cohorts of people tends to net new insights about how to build an inclusive company. +CHAD: That's really interesting. Can you give an example? +LENORE: Let's say there's a haircare company, and the founder of a haircare company really wants to build and sell shampoo for people with blue hair. Exciting, great. This founder has quit their job to build this blue haircare shampoo company. When we meet that founder, we ask them to, again, narrowly define a target market, people with blue hair, and then go through the inclusion assumption exercise of saying, well, what is it about those people with blue hair that's going to make them come and buy your product time and time and time and time again? And what is so motivating about this problem that you are willing to quit your job to build this company? +What we have often found is that the founder gets to the place of saying, "Oh, it's actually not that it's blue hair. It's that the person is really proud of the color of their hair. It's a pride in hair color that has me buy this particular shampoo. And it is the sense of community and affinity with other people who have made non-traditional hair choices." Cool. That's a way bigger target market than just people with blue hair. How do we build that company? +And so that's the pivot from we want a narrowly defined target market because it shows you what you already know. And then challenge your assumptions by digging even deeper and seeing how actually people with blue hair and people with orange hair might have something really interesting in common that we may have overlooked historically and might have left a lot of value on the table. +CHAD: I think that's a great example. It's also an example for me of the kind of benefit that having someone external can bring to you, whether it be a coach or a mentor and even someone like yourself who will be brought in to explicitly do it. Sometimes, especially founders, have a hard time really thinking critically about what it is they're trying to build. And having an outside perspective, in my experience, can be really helpful. +LENORE: Yeah, I if I could give one gift to every founder, it would be to have a coach. I think so many founders are brilliant at their business. And it is so helpful to have an external perspective because we all have blind spots. And having a person looking for your blind spots, supporting you in seeing them, and then practicing living in them, so they're no longer blind spots is, I think, a really transformative experience personally and professionally. +CHAD: You've been growing Bright for several years now. As you look ahead into the future for yourself and for the company, what are some of the things that you're excited about? +LENORE: I am so incredibly proud of the team that has been building Bright with me. And we have some additions to that team coming that I'm over the moon about, so I'm really excited about that. And by extension, we're growing the Bright Ventures community. So we used to do almost exclusively in-person work in New York City, where I live. But like many groups, through the pandemic, we started to experiment with digital formats for delivering some of our frameworks, and programs, and insights. And we found some things that really resonate. +So we're now expanding the Bright Ventures community to allow many, many, many more people, even globally, to build an inclusive economy with us. The community has well-being events, which is a critical part of building inclusively. If we're not well, it's hard to include others. It also will have skill-based trainings like some of the ones we described. +And we think a huge opportunity is to help people build connections across networks that they wouldn't necessarily have access to otherwise, so that I'm really proud of, really looking forward to. And then finally, always excited to see the portfolio founders that we back grow and fully express their ideas and bring their, in some cases, finally first bring their companies to market publicly. +CHAD: Is that community something that people listening might be able to sign up for now? +LENORE: Absolutely. I would say if you're even inclusion curious, like, you just want to understand what inclusion actually means and why it's not a boring thing that you have to sit through a mandated training on, or why even if you're already in the streets marching you should get involved in understanding how inclusion shows up in tech, we would love to have you. And it's a low or even no commitment experience. Drop in, see what resonates, provide us some feedback. We'd love to have folks participate. +CHAD: Yeah, we'll link it in the show notes. But can you tell people where folks go to sign up? +LENORE: Yeah, we'll link a waitlist. We're inviting people in in segments to make sure that everyone has a really good experience. So we will provide that waitlist link. I actually don't know the URL. +CHAD: [laughs] That's fair enough. Fair enough. Well, on that note, if folks want to get in touch with you, or follow along, or find out more about Bright, where are all the different places that they can do that? +LENORE: The best place is LinkedIn. My name Lenore Champagne Beirne is really easy to find. I'm the only one. And I'd love to have you all connect there. You can also submit...if you have a startup idea or an existing company that you're interested in bringing into Bright Venture's view, please feel free to submit that on our website, which is www.brightventures.io. And you could technically find me on Twitter, but I won't really be there. [laughs] So I hesitate to suggest it as a place to communicate with me. +CHAD: We're going to link all of that in the show notes as well, along with a complete transcript for this episode. You can find all of that at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can technically find me on Twitter as well at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening. +Lenore, thank you so much for joining me. I really appreciate it. +LENORE: So great to be here. Thanks again, Chad, for the questions. +CHAD: And see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Lenore Champagne Beirne. + + + Lenore Champagne Beirne is Founder and Managing Partner at Bright Ventures, a groundbreaking space for transformation in people, companies, and industries with coaching, capital, and community.

+ +

Chad talks with Lenore about being at the intersection of all three of those services, providing support for diverse entrepreneurs, and staying intentional about the kind of company and culture they're creating.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Lenore Champagne Beirne, Founder and Managing Partner at Bright Ventures, a groundbreaking space for transformation in people, companies, and industries with coaching, capital, and community. Lenore, thank you so much for joining me.

+ +

LENORE: Absolutely. Thanks for having me, Chad.

+ +

CHAD: Bright Ventures, I love the three things: coaching, capital, and community. Would you say at the core you are a venture capital firm? Or is it really the intersection of all three of those services?

+ +

LENORE: It is truly the intersection of all three of those services. In fact, I started Bright Ventures because of a gap that I saw in the capital markets. But the first thing that we came to market with was coaching. And we learned so much from coaching diverse entrepreneurs and investors, and operators that we saw ways to add value to those groups and ultimately built the accelerator and venture capital fund and a number of other programs.

+ +

CHAD: Like most companies, I think what you have is relatively unique. Most companies are a coaching company or a venture capital fund. Do you get pushback, or are there concerns about doing too much?

+ +

LENORE: We've heard that question, although I don't know that the same question would be posed, at least in the same way, to a man, especially if it were a White man. But that aside, the reason we get the question is because I personally have led the launch of each new phase of the company. And what has really given our investors and also our partners comfort is that as we've expanded, we've also massively expanded the leadership and the skill set of the Bright Ventures team.

+ +

So I would say at our heart, we are a transformation company. We make inclusive innovation possible. We define that as building a future that works for all of us together. We make that possible. And we know that because that's a huge, gnarly, complex, nuanced issue, you have to have a multipronged solution. And so, for us, the combination of individual and systems transformation through coaching, community where we can practice and learn, and capital that actually shifts how businesses can operate is the right set of interventions.

+ +

CHAD: So one of the things venture capitalists often give feedback to their clients about is either doing too much or mixing business models. So like, oh, you shouldn't do consulting because what you have is a product company. They are different revenue streams, and different ways of working, and different ways of generating money. How do you balance those different business models that are within your organization?

+ +

LENORE: Well, I think, as I mentioned, the business models that we have inside of Bright Ventures are intended to solve the same really big problem in different ways through different angles. So what we have found is that there are a lot of early-stage ventures that would benefit from the kind of coaching that we offer.

+ +

But coaching is typically a really high-dollar item, only available to kind of an exclusive few. And so, it became clear to us that building a community with more scalable programs could meet the need of the stakeholder that we're interested in. And that has driven, time and time again, the business models that drive and organize our work at Bright Ventures.

+ +

CHAD: Yeah, I realize part of what's on my mind is say you're working with a founder and you invest in that founder or a founding team and a founding company, do they no longer become a coaching client that's actually paying you money for coaching? Or do they get it for free?

+ +

LENORE: Mm-hmm. So founders in our venture portfolio have access to the full suite of our services. And obviously, it's in the Bright Ventures entities' best interest to see those companies win and to give them all the resources and support that they need. You're asking these questions about business models.

+ +

One thing I should clarify is that we don't have just a single business operating entity at Bright Ventures. The venture fund entity is a traditional GP LP structure that exists to invest in, yes, maybe some of the companies that we serve through our services business, but also a broad swath of companies across the U.S. at early stage.

+ +

There's then a pretty straightforward consulting firm that we have that also goes by the name Bright Ventures but is a different legal and operational entity. So there's no proprietary information shared across those lines that are different management teams. What unites the Bright Ventures entities is a commitment to inclusive innovation and a set of frameworks that we have seen now proven to drive inclusive outcomes as a competitive advantage in venture.

+ +

CHAD: Oh, that's awesome clarification. One of the things that we've struggled with a little bit at thoughtbot is we do a lot at thoughtbot. It's probably one of the reasons why I'm asking these questions about balancing. And sometimes, I do think, oh, it could benefit us if they were separate entities.

+ +

LENORE: How have you all thought about that so far?

+ +

CHAD: For the most part, what we do is we run separate P&Ls for the different business lines or the different offerings, but it's all actually one entity as long as it doesn't cross country boundaries. We have a different entity for Europe.

+ +

LENORE: Got it. I asked because I'm curious because, at some point in the next couple of years, we'll probably do one more entity. And we're talking internally now about the moment that that will be the right thing to do, not yet. But good to hear that you're thinking about that as well.

+ +

CHAD: Yeah. What was the part of your journey where...you mentioned you started to see this need. How did that need or seeing that need jump from that to I'm starting out; this is a real thing?

+ +

LENORE: It's blurry. The lines are blurry for me, particularly as the founder of Bright, because I have been working on effectively pulling the same threads as long as I can remember, even before Bright Ventures had a name and was an entity. And so, for as long as I can remember, I've been confounded, frustrated [laughs] by and working on the inequity of access to capital and to opportunity in entrepreneurship and in many other expressions of wealth creation.

+ +

I've also, for as long as I can remember, thought a lot about how people think, and how they relate to themselves, and how they relate to other people. And truly, I can remember experimenting with these ideas when I was really young, maybe even less than ten years old. I then remember experimenting with them in college and trying to create a major for myself because I was trying to understand the intersections of these questions.

+ +

Officially, it was in 2014 that I launched Bright Ventures as the strategic advisory firm that I mentioned we came to market with. And that was because I had just come off of a really important career experience. I was living and working in Haiti on a program funded by the U.S. government to invest in and then provide support for entrepreneur organizations so like small businesses, social enterprises in Haiti. And I loved that work. It was super challenging, really rewarding, really interesting.

+ +

But it also opened up in me this question about what entrepreneurs actually needed for support and how to support other investors and seeing potential where I saw it but that the markets might be missing it. And so, in 2014, I had enough of an idea about some of what was missing to get started. And to the point of the line or, like, okay, I'm going do this now, that's when that happened.

+ +

CHAD: I've had a whole bunch of guests on who talk about issues of inclusion, and particularly access or being excluded from funding and opportunity. And I'm curious, from your perspective, what kind of support do founders who are typically excluded or underrepresented most need, especially on day one?

+ +

LENORE: Well, one thing that I have found really fascinating about support for diverse entrepreneurs is that we often, as a whole, I'm speaking like we in a very big sense, tend to assume that there is a homogenous set of supports that are required. And this gets to that question about business models and how we make sure that we actually have at Bright Ventures a diversity of ways to help people.

+ +

What we've learned is that diverse entrepreneurs are not a particularly homogenous bunch. And there are a couple of things that seem to be consistent for certain groups that we have worked hard to build frameworks and models for. One of those things is mindset shift and personal leadership development. That was executive coaching for us. We developed a specialty in helping people who are systematically in out-of-power positions move into in-power positions, and that was through a series of coaching frameworks and leadership frameworks that we would deliver.

+ +

We also learned that in order to do that durably and sustainably, you also had to go and coach and train the people who might be excluding those entrepreneurs. So we started to develop expertise in working directly with investors and helping them see the brilliance and maybe overlooked opportunity in diverse entrepreneurs. Those were two.

+ +

We also have some skill-based programming where we help people inside large organizations and also brand new ones think about how to tactically build inclusion into the way that they run their day-to-day. And we finally, of course, have some capital programs where we invest directly in diverse entrepreneurs, which we know are vastly underrepresented in the capital markets.

+ +

CHAD: You use the word tactical, which I think is a really interesting one because a lot of times, especially on the show, we might talk about strategic things, which is different than tactical. So what does tactical inclusion mean to you?

+ +

LENORE: So it does start with the strategy. There has to be a business model that makes inclusion possible. Otherwise, we're kind of putting a Band-Aid on a really big open wound. But if there's a business model that makes it possible to take reasonable care of your employees and leave your customers better off than they were before they met you, then tactical inclusion is things like understanding how to delegate, how to give feedback, how to hold meetings in ways that actually bring out the best in your team, and how to collect product feedback that's truly representative of the full swath of people who not only use your product today but maybe are impacted by it throughout your value chain, or might use it tomorrow if you made some innovative choices in product design and development.

+ +

And so we say tactical, and we highlight that because what we have found is that much of the conversation about inclusion and certainly about diversity lives at this very theoretical level. It ends up being like an ideology, an aspiration, and we don't think that's sufficient. We think you have to actually make it how you behave. And so that tends to be where we focus both in our training and in our evaluation of inclusion in other companies.

+ +

CHAD: One of the problems that we sometimes see, and we see it in our clients, too, is not everybody responds to training in the same way, particularly if it's like, watch this video. Sometimes there will be not very much participation in that at all. Or even if you're just watching it, maybe you're not giving it your full attention. What does the training that you give actually look like?

+ +

LENORE: What you just said is exactly why we looked for other things to name what we do because training gets such a bad rap.

+ +

CHAD: [laughs] Yeah.

+ +

LENORE: But what we learned about training is, I mean, this seems so obvious, Chad, but it has to actually be a skill that the person will obviously benefit from implementing immediately. So the first thing is like, do you need to and want to and recognize the need to learn this? We only go in with training when we can see that there's general consensus that it'll provide real value, business value, personal value, cultural value in the company.

+ +

The second thing is that we recognize that people's attention spans are shorter on average. And so what we do with training is make it highly experiential. We'll introduce a concept and then show you a way to practice it right away, as in, within the same 20-minute span. We also then give folks an opportunity to practice live and get feedback. And we only apply training to real-life decisions that managers or leaders are thinking about right in that moment. So for us, again, you asked about this word tactical. It really comes down to how deeply we can tie the training to the person's motivation and their ability to apply it.

+ +

Mid-Roll Ad:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops

+ +

CHAD: Another pressure I see in the startup world, in general, is this idea of we don't have time to stop. We've got to go. We've got to do this. We've got to do that. And taking the time to actually be really intentional about the kind of company and the kind of culture you're creating when you may be so focused on the business you're creating or the product you're creating sometimes goes by the wayside. Do you spend time trying to fix that problem? Or do you seek out people who are ready for what you have?

+ +

LENORE: We do an assessment in the beginning, at Bright Ventures, we called it culture audit, to determine the readiness of a culture for the depth of work that we can bring. And we have different ways of engaging depending on where the company is today. We also ask companies to self-identify. Like, how deep are you really interested in going? What kind of outcomes are important to you? And so there's a bit of we've built our frameworks in a modular way so that we can mix and match them to the environment, the strategy, the leadership, the goals of each of our clients.

+ +

CHAD: I'm curious, from an investor standpoint then, what makes pre-seed, seed companies potential when you have your investor hat on the right kind of companies for Bright Ventures?

+ +

LENORE: Yeah, we're really excited about companies that have an early signal of building inclusion into the fabric of the business model. And you can usually see that based on the way that the founder is building a team. It's not always...sometimes it's so few people that it's just not enough people to really assess diversity, as is sometimes the case. But you can tell how a founder thinks about divergent opinions, about different perspectives, and about the pipeline of people that they're seeking out to build a company with.

+ +

The other way that we look for inclusion in the pre-seed and seed stage is really in the business model. And again, the word tactical, like, is this product or service...who is it designed to serve? And how is it designed to leave them? Are the questions that we tend to ask. And what we have found is that if you invest for inclusion, 85% of the time, that is overlapped with investing in diverse founders, but it's not 100% of the time. And again, our lens on that is that inclusion is a behavior, not an identity.

+ +

And so we're looking for any founder who's building inside of the paradigms I mentioned earlier, irrespective of demographics. And we particularly get excited; in the next ten years, we think there's a lot to be built in digital health and in FinTech, in the broadest sense, Web3 and Web2 FinTech for I think a lot of inclusive business models to emerge there. Also really excited about future of work as a place where I think inclusion will be a massive competitive advantage.

+ +

CHAD: So many companies are starting remote or are fully remote. Is the training that you give or the advice you're providing in terms of tactical inclusion does it differ for in-person versus remote companies?

+ +

LENORE: There's a consistent framework or set of questions that you can answer those questions in lots of ways. So if I ask the question like, how does your team get to know one another? The answer to that could be very different if your company sits together every day and actually you unwind on Fridays together. Versus if you're a fully remote company in multiple time zones, sometimes even multiple languages, the answer can be different, but we still know that the team feeling cohesive is a key ingredient for inclusion.

+ +

And so we're looking for how your company does it and that your company does it, not that it does it in a certain way. So we try to help our clients see their companies as systems in the way that we do so that they can see how is the fact that your team feels cohesive related to the way your team generates new ideas or brings new products to market? And then, we trust management and leadership to design the right specific ways to have that expressed in that company.

+ +

CHAD: What advice...someone who is just getting started and is just getting started out maybe has an idea, maybe it's a founding team, a team of co-founders. They're very early stage. Are there some things that you would recommend that they either do or avoid doing in order to lay a good groundwork for an inclusive team and company?

+ +

LENORE: Yeah, absolutely. The building block, like the fundamental input for inclusion, is listening, and so we have done a ton of resources on how to practice listening, how to know if you are listening. But you can't build a system that dynamically includes other groups without really understanding those groups. Listening is really important. Another thing is I find that it helps people build more inclusively when they go through the exercise of seeking out opinions that really differ from their own. And beyond, I think what people typically mean when they say playing devil's advocate, really trying to understand like, why does that work?

+ +

So one of the things that founders who have built inclusively have really interrogated is who their target market is. And I have found that it's really useful to go through the exercise of making it incredibly narrow, like very exclusive, so you understand your assumptions around who your target market is. And then asking yourself, what does that group, that very narrowly defined group, have in common with other groups that I've crossed off the list? Looking through the lens of what unites diverse cohorts of people tends to net new insights about how to build an inclusive company.

+ +

CHAD: That's really interesting. Can you give an example?

+ +

LENORE: Let's say there's a haircare company, and the founder of a haircare company really wants to build and sell shampoo for people with blue hair. Exciting, great. This founder has quit their job to build this blue haircare shampoo company. When we meet that founder, we ask them to, again, narrowly define a target market, people with blue hair, and then go through the inclusion assumption exercise of saying, well, what is it about those people with blue hair that's going to make them come and buy your product time and time and time and time again? And what is so motivating about this problem that you are willing to quit your job to build this company?

+ +

What we have often found is that the founder gets to the place of saying, "Oh, it's actually not that it's blue hair. It's that the person is really proud of the color of their hair. It's a pride in hair color that has me buy this particular shampoo. And it is the sense of community and affinity with other people who have made non-traditional hair choices." Cool. That's a way bigger target market than just people with blue hair. How do we build that company?

+ +

And so that's the pivot from we want a narrowly defined target market because it shows you what you already know. And then challenge your assumptions by digging even deeper and seeing how actually people with blue hair and people with orange hair might have something really interesting in common that we may have overlooked historically and might have left a lot of value on the table.

+ +

CHAD: I think that's a great example. It's also an example for me of the kind of benefit that having someone external can bring to you, whether it be a coach or a mentor and even someone like yourself who will be brought in to explicitly do it. Sometimes, especially founders, have a hard time really thinking critically about what it is they're trying to build. And having an outside perspective, in my experience, can be really helpful.

+ +

LENORE: Yeah, I if I could give one gift to every founder, it would be to have a coach. I think so many founders are brilliant at their business. And it is so helpful to have an external perspective because we all have blind spots. And having a person looking for your blind spots, supporting you in seeing them, and then practicing living in them, so they're no longer blind spots is, I think, a really transformative experience personally and professionally.

+ +

CHAD: You've been growing Bright for several years now. As you look ahead into the future for yourself and for the company, what are some of the things that you're excited about?

+ +

LENORE: I am so incredibly proud of the team that has been building Bright with me. And we have some additions to that team coming that I'm over the moon about, so I'm really excited about that. And by extension, we're growing the Bright Ventures community. So we used to do almost exclusively in-person work in New York City, where I live. But like many groups, through the pandemic, we started to experiment with digital formats for delivering some of our frameworks, and programs, and insights. And we found some things that really resonate.

+ +

So we're now expanding the Bright Ventures community to allow many, many, many more people, even globally, to build an inclusive economy with us. The community has well-being events, which is a critical part of building inclusively. If we're not well, it's hard to include others. It also will have skill-based trainings like some of the ones we described.

+ +

And we think a huge opportunity is to help people build connections across networks that they wouldn't necessarily have access to otherwise, so that I'm really proud of, really looking forward to. And then finally, always excited to see the portfolio founders that we back grow and fully express their ideas and bring their, in some cases, finally first bring their companies to market publicly.

+ +

CHAD: Is that community something that people listening might be able to sign up for now?

+ +

LENORE: Absolutely. I would say if you're even inclusion curious, like, you just want to understand what inclusion actually means and why it's not a boring thing that you have to sit through a mandated training on, or why even if you're already in the streets marching you should get involved in understanding how inclusion shows up in tech, we would love to have you. And it's a low or even no commitment experience. Drop in, see what resonates, provide us some feedback. We'd love to have folks participate.

+ +

CHAD: Yeah, we'll link it in the show notes. But can you tell people where folks go to sign up?

+ +

LENORE: Yeah, we'll link a waitlist. We're inviting people in in segments to make sure that everyone has a really good experience. So we will provide that waitlist link. I actually don't know the URL.

+ +

CHAD: [laughs] That's fair enough. Fair enough. Well, on that note, if folks want to get in touch with you, or follow along, or find out more about Bright, where are all the different places that they can do that?

+ +

LENORE: The best place is LinkedIn. My name Lenore Champagne Beirne is really easy to find. I'm the only one. And I'd love to have you all connect there. You can also submit...if you have a startup idea or an existing company that you're interested in bringing into Bright Venture's view, please feel free to submit that on our website, which is www.brightventures.io. And you could technically find me on Twitter, but I won't really be there. [laughs] So I hesitate to suggest it as a place to communicate with me.

+ +

CHAD: We're going to link all of that in the show notes as well, along with a complete transcript for this episode. You can find all of that at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can technically find me on Twitter as well at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening.

+ +

Lenore, thank you so much for joining me. I really appreciate it.

+ +

LENORE: So great to be here. Thanks again, Chad, for the questions.

+ +

CHAD: And see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Lenore Champagne Beirne.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lenore Champagne Beirne is Founder and Managing Partner at Bright Ventures, a groundbreaking space for transformation in people, companies, and industries with coaching, capital, and community.

+ +

Chad talks with Lenore about being at the intersection of all three of those services, providing support for diverse entrepreneurs, and staying intentional about the kind of company and culture they're creating.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Lenore Champagne Beirne, Founder and Managing Partner at Bright Ventures, a groundbreaking space for transformation in people, companies, and industries with coaching, capital, and community. Lenore, thank you so much for joining me.

+ +

LENORE: Absolutely. Thanks for having me, Chad.

+ +

CHAD: Bright Ventures, I love the three things: coaching, capital, and community. Would you say at the core you are a venture capital firm? Or is it really the intersection of all three of those services?

+ +

LENORE: It is truly the intersection of all three of those services. In fact, I started Bright Ventures because of a gap that I saw in the capital markets. But the first thing that we came to market with was coaching. And we learned so much from coaching diverse entrepreneurs and investors, and operators that we saw ways to add value to those groups and ultimately built the accelerator and venture capital fund and a number of other programs.

+ +

CHAD: Like most companies, I think what you have is relatively unique. Most companies are a coaching company or a venture capital fund. Do you get pushback, or are there concerns about doing too much?

+ +

LENORE: We've heard that question, although I don't know that the same question would be posed, at least in the same way, to a man, especially if it were a White man. But that aside, the reason we get the question is because I personally have led the launch of each new phase of the company. And what has really given our investors and also our partners comfort is that as we've expanded, we've also massively expanded the leadership and the skill set of the Bright Ventures team.

+ +

So I would say at our heart, we are a transformation company. We make inclusive innovation possible. We define that as building a future that works for all of us together. We make that possible. And we know that because that's a huge, gnarly, complex, nuanced issue, you have to have a multipronged solution. And so, for us, the combination of individual and systems transformation through coaching, community where we can practice and learn, and capital that actually shifts how businesses can operate is the right set of interventions.

+ +

CHAD: So one of the things venture capitalists often give feedback to their clients about is either doing too much or mixing business models. So like, oh, you shouldn't do consulting because what you have is a product company. They are different revenue streams, and different ways of working, and different ways of generating money. How do you balance those different business models that are within your organization?

+ +

LENORE: Well, I think, as I mentioned, the business models that we have inside of Bright Ventures are intended to solve the same really big problem in different ways through different angles. So what we have found is that there are a lot of early-stage ventures that would benefit from the kind of coaching that we offer.

+ +

But coaching is typically a really high-dollar item, only available to kind of an exclusive few. And so, it became clear to us that building a community with more scalable programs could meet the need of the stakeholder that we're interested in. And that has driven, time and time again, the business models that drive and organize our work at Bright Ventures.

+ +

CHAD: Yeah, I realize part of what's on my mind is say you're working with a founder and you invest in that founder or a founding team and a founding company, do they no longer become a coaching client that's actually paying you money for coaching? Or do they get it for free?

+ +

LENORE: Mm-hmm. So founders in our venture portfolio have access to the full suite of our services. And obviously, it's in the Bright Ventures entities' best interest to see those companies win and to give them all the resources and support that they need. You're asking these questions about business models.

+ +

One thing I should clarify is that we don't have just a single business operating entity at Bright Ventures. The venture fund entity is a traditional GP LP structure that exists to invest in, yes, maybe some of the companies that we serve through our services business, but also a broad swath of companies across the U.S. at early stage.

+ +

There's then a pretty straightforward consulting firm that we have that also goes by the name Bright Ventures but is a different legal and operational entity. So there's no proprietary information shared across those lines that are different management teams. What unites the Bright Ventures entities is a commitment to inclusive innovation and a set of frameworks that we have seen now proven to drive inclusive outcomes as a competitive advantage in venture.

+ +

CHAD: Oh, that's awesome clarification. One of the things that we've struggled with a little bit at thoughtbot is we do a lot at thoughtbot. It's probably one of the reasons why I'm asking these questions about balancing. And sometimes, I do think, oh, it could benefit us if they were separate entities.

+ +

LENORE: How have you all thought about that so far?

+ +

CHAD: For the most part, what we do is we run separate P&Ls for the different business lines or the different offerings, but it's all actually one entity as long as it doesn't cross country boundaries. We have a different entity for Europe.

+ +

LENORE: Got it. I asked because I'm curious because, at some point in the next couple of years, we'll probably do one more entity. And we're talking internally now about the moment that that will be the right thing to do, not yet. But good to hear that you're thinking about that as well.

+ +

CHAD: Yeah. What was the part of your journey where...you mentioned you started to see this need. How did that need or seeing that need jump from that to I'm starting out; this is a real thing?

+ +

LENORE: It's blurry. The lines are blurry for me, particularly as the founder of Bright, because I have been working on effectively pulling the same threads as long as I can remember, even before Bright Ventures had a name and was an entity. And so, for as long as I can remember, I've been confounded, frustrated [laughs] by and working on the inequity of access to capital and to opportunity in entrepreneurship and in many other expressions of wealth creation.

+ +

I've also, for as long as I can remember, thought a lot about how people think, and how they relate to themselves, and how they relate to other people. And truly, I can remember experimenting with these ideas when I was really young, maybe even less than ten years old. I then remember experimenting with them in college and trying to create a major for myself because I was trying to understand the intersections of these questions.

+ +

Officially, it was in 2014 that I launched Bright Ventures as the strategic advisory firm that I mentioned we came to market with. And that was because I had just come off of a really important career experience. I was living and working in Haiti on a program funded by the U.S. government to invest in and then provide support for entrepreneur organizations so like small businesses, social enterprises in Haiti. And I loved that work. It was super challenging, really rewarding, really interesting.

+ +

But it also opened up in me this question about what entrepreneurs actually needed for support and how to support other investors and seeing potential where I saw it but that the markets might be missing it. And so, in 2014, I had enough of an idea about some of what was missing to get started. And to the point of the line or, like, okay, I'm going do this now, that's when that happened.

+ +

CHAD: I've had a whole bunch of guests on who talk about issues of inclusion, and particularly access or being excluded from funding and opportunity. And I'm curious, from your perspective, what kind of support do founders who are typically excluded or underrepresented most need, especially on day one?

+ +

LENORE: Well, one thing that I have found really fascinating about support for diverse entrepreneurs is that we often, as a whole, I'm speaking like we in a very big sense, tend to assume that there is a homogenous set of supports that are required. And this gets to that question about business models and how we make sure that we actually have at Bright Ventures a diversity of ways to help people.

+ +

What we've learned is that diverse entrepreneurs are not a particularly homogenous bunch. And there are a couple of things that seem to be consistent for certain groups that we have worked hard to build frameworks and models for. One of those things is mindset shift and personal leadership development. That was executive coaching for us. We developed a specialty in helping people who are systematically in out-of-power positions move into in-power positions, and that was through a series of coaching frameworks and leadership frameworks that we would deliver.

+ +

We also learned that in order to do that durably and sustainably, you also had to go and coach and train the people who might be excluding those entrepreneurs. So we started to develop expertise in working directly with investors and helping them see the brilliance and maybe overlooked opportunity in diverse entrepreneurs. Those were two.

+ +

We also have some skill-based programming where we help people inside large organizations and also brand new ones think about how to tactically build inclusion into the way that they run their day-to-day. And we finally, of course, have some capital programs where we invest directly in diverse entrepreneurs, which we know are vastly underrepresented in the capital markets.

+ +

CHAD: You use the word tactical, which I think is a really interesting one because a lot of times, especially on the show, we might talk about strategic things, which is different than tactical. So what does tactical inclusion mean to you?

+ +

LENORE: So it does start with the strategy. There has to be a business model that makes inclusion possible. Otherwise, we're kind of putting a Band-Aid on a really big open wound. But if there's a business model that makes it possible to take reasonable care of your employees and leave your customers better off than they were before they met you, then tactical inclusion is things like understanding how to delegate, how to give feedback, how to hold meetings in ways that actually bring out the best in your team, and how to collect product feedback that's truly representative of the full swath of people who not only use your product today but maybe are impacted by it throughout your value chain, or might use it tomorrow if you made some innovative choices in product design and development.

+ +

And so we say tactical, and we highlight that because what we have found is that much of the conversation about inclusion and certainly about diversity lives at this very theoretical level. It ends up being like an ideology, an aspiration, and we don't think that's sufficient. We think you have to actually make it how you behave. And so that tends to be where we focus both in our training and in our evaluation of inclusion in other companies.

+ +

CHAD: One of the problems that we sometimes see, and we see it in our clients, too, is not everybody responds to training in the same way, particularly if it's like, watch this video. Sometimes there will be not very much participation in that at all. Or even if you're just watching it, maybe you're not giving it your full attention. What does the training that you give actually look like?

+ +

LENORE: What you just said is exactly why we looked for other things to name what we do because training gets such a bad rap.

+ +

CHAD: [laughs] Yeah.

+ +

LENORE: But what we learned about training is, I mean, this seems so obvious, Chad, but it has to actually be a skill that the person will obviously benefit from implementing immediately. So the first thing is like, do you need to and want to and recognize the need to learn this? We only go in with training when we can see that there's general consensus that it'll provide real value, business value, personal value, cultural value in the company.

+ +

The second thing is that we recognize that people's attention spans are shorter on average. And so what we do with training is make it highly experiential. We'll introduce a concept and then show you a way to practice it right away, as in, within the same 20-minute span. We also then give folks an opportunity to practice live and get feedback. And we only apply training to real-life decisions that managers or leaders are thinking about right in that moment. So for us, again, you asked about this word tactical. It really comes down to how deeply we can tie the training to the person's motivation and their ability to apply it.

+ +

Mid-Roll Ad:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops

+ +

CHAD: Another pressure I see in the startup world, in general, is this idea of we don't have time to stop. We've got to go. We've got to do this. We've got to do that. And taking the time to actually be really intentional about the kind of company and the kind of culture you're creating when you may be so focused on the business you're creating or the product you're creating sometimes goes by the wayside. Do you spend time trying to fix that problem? Or do you seek out people who are ready for what you have?

+ +

LENORE: We do an assessment in the beginning, at Bright Ventures, we called it culture audit, to determine the readiness of a culture for the depth of work that we can bring. And we have different ways of engaging depending on where the company is today. We also ask companies to self-identify. Like, how deep are you really interested in going? What kind of outcomes are important to you? And so there's a bit of we've built our frameworks in a modular way so that we can mix and match them to the environment, the strategy, the leadership, the goals of each of our clients.

+ +

CHAD: I'm curious, from an investor standpoint then, what makes pre-seed, seed companies potential when you have your investor hat on the right kind of companies for Bright Ventures?

+ +

LENORE: Yeah, we're really excited about companies that have an early signal of building inclusion into the fabric of the business model. And you can usually see that based on the way that the founder is building a team. It's not always...sometimes it's so few people that it's just not enough people to really assess diversity, as is sometimes the case. But you can tell how a founder thinks about divergent opinions, about different perspectives, and about the pipeline of people that they're seeking out to build a company with.

+ +

The other way that we look for inclusion in the pre-seed and seed stage is really in the business model. And again, the word tactical, like, is this product or service...who is it designed to serve? And how is it designed to leave them? Are the questions that we tend to ask. And what we have found is that if you invest for inclusion, 85% of the time, that is overlapped with investing in diverse founders, but it's not 100% of the time. And again, our lens on that is that inclusion is a behavior, not an identity.

+ +

And so we're looking for any founder who's building inside of the paradigms I mentioned earlier, irrespective of demographics. And we particularly get excited; in the next ten years, we think there's a lot to be built in digital health and in FinTech, in the broadest sense, Web3 and Web2 FinTech for I think a lot of inclusive business models to emerge there. Also really excited about future of work as a place where I think inclusion will be a massive competitive advantage.

+ +

CHAD: So many companies are starting remote or are fully remote. Is the training that you give or the advice you're providing in terms of tactical inclusion does it differ for in-person versus remote companies?

+ +

LENORE: There's a consistent framework or set of questions that you can answer those questions in lots of ways. So if I ask the question like, how does your team get to know one another? The answer to that could be very different if your company sits together every day and actually you unwind on Fridays together. Versus if you're a fully remote company in multiple time zones, sometimes even multiple languages, the answer can be different, but we still know that the team feeling cohesive is a key ingredient for inclusion.

+ +

And so we're looking for how your company does it and that your company does it, not that it does it in a certain way. So we try to help our clients see their companies as systems in the way that we do so that they can see how is the fact that your team feels cohesive related to the way your team generates new ideas or brings new products to market? And then, we trust management and leadership to design the right specific ways to have that expressed in that company.

+ +

CHAD: What advice...someone who is just getting started and is just getting started out maybe has an idea, maybe it's a founding team, a team of co-founders. They're very early stage. Are there some things that you would recommend that they either do or avoid doing in order to lay a good groundwork for an inclusive team and company?

+ +

LENORE: Yeah, absolutely. The building block, like the fundamental input for inclusion, is listening, and so we have done a ton of resources on how to practice listening, how to know if you are listening. But you can't build a system that dynamically includes other groups without really understanding those groups. Listening is really important. Another thing is I find that it helps people build more inclusively when they go through the exercise of seeking out opinions that really differ from their own. And beyond, I think what people typically mean when they say playing devil's advocate, really trying to understand like, why does that work?

+ +

So one of the things that founders who have built inclusively have really interrogated is who their target market is. And I have found that it's really useful to go through the exercise of making it incredibly narrow, like very exclusive, so you understand your assumptions around who your target market is. And then asking yourself, what does that group, that very narrowly defined group, have in common with other groups that I've crossed off the list? Looking through the lens of what unites diverse cohorts of people tends to net new insights about how to build an inclusive company.

+ +

CHAD: That's really interesting. Can you give an example?

+ +

LENORE: Let's say there's a haircare company, and the founder of a haircare company really wants to build and sell shampoo for people with blue hair. Exciting, great. This founder has quit their job to build this blue haircare shampoo company. When we meet that founder, we ask them to, again, narrowly define a target market, people with blue hair, and then go through the inclusion assumption exercise of saying, well, what is it about those people with blue hair that's going to make them come and buy your product time and time and time and time again? And what is so motivating about this problem that you are willing to quit your job to build this company?

+ +

What we have often found is that the founder gets to the place of saying, "Oh, it's actually not that it's blue hair. It's that the person is really proud of the color of their hair. It's a pride in hair color that has me buy this particular shampoo. And it is the sense of community and affinity with other people who have made non-traditional hair choices." Cool. That's a way bigger target market than just people with blue hair. How do we build that company?

+ +

And so that's the pivot from we want a narrowly defined target market because it shows you what you already know. And then challenge your assumptions by digging even deeper and seeing how actually people with blue hair and people with orange hair might have something really interesting in common that we may have overlooked historically and might have left a lot of value on the table.

+ +

CHAD: I think that's a great example. It's also an example for me of the kind of benefit that having someone external can bring to you, whether it be a coach or a mentor and even someone like yourself who will be brought in to explicitly do it. Sometimes, especially founders, have a hard time really thinking critically about what it is they're trying to build. And having an outside perspective, in my experience, can be really helpful.

+ +

LENORE: Yeah, I if I could give one gift to every founder, it would be to have a coach. I think so many founders are brilliant at their business. And it is so helpful to have an external perspective because we all have blind spots. And having a person looking for your blind spots, supporting you in seeing them, and then practicing living in them, so they're no longer blind spots is, I think, a really transformative experience personally and professionally.

+ +

CHAD: You've been growing Bright for several years now. As you look ahead into the future for yourself and for the company, what are some of the things that you're excited about?

+ +

LENORE: I am so incredibly proud of the team that has been building Bright with me. And we have some additions to that team coming that I'm over the moon about, so I'm really excited about that. And by extension, we're growing the Bright Ventures community. So we used to do almost exclusively in-person work in New York City, where I live. But like many groups, through the pandemic, we started to experiment with digital formats for delivering some of our frameworks, and programs, and insights. And we found some things that really resonate.

+ +

So we're now expanding the Bright Ventures community to allow many, many, many more people, even globally, to build an inclusive economy with us. The community has well-being events, which is a critical part of building inclusively. If we're not well, it's hard to include others. It also will have skill-based trainings like some of the ones we described.

+ +

And we think a huge opportunity is to help people build connections across networks that they wouldn't necessarily have access to otherwise, so that I'm really proud of, really looking forward to. And then finally, always excited to see the portfolio founders that we back grow and fully express their ideas and bring their, in some cases, finally first bring their companies to market publicly.

+ +

CHAD: Is that community something that people listening might be able to sign up for now?

+ +

LENORE: Absolutely. I would say if you're even inclusion curious, like, you just want to understand what inclusion actually means and why it's not a boring thing that you have to sit through a mandated training on, or why even if you're already in the streets marching you should get involved in understanding how inclusion shows up in tech, we would love to have you. And it's a low or even no commitment experience. Drop in, see what resonates, provide us some feedback. We'd love to have folks participate.

+ +

CHAD: Yeah, we'll link it in the show notes. But can you tell people where folks go to sign up?

+ +

LENORE: Yeah, we'll link a waitlist. We're inviting people in in segments to make sure that everyone has a really good experience. So we will provide that waitlist link. I actually don't know the URL.

+ +

CHAD: [laughs] That's fair enough. Fair enough. Well, on that note, if folks want to get in touch with you, or follow along, or find out more about Bright, where are all the different places that they can do that?

+ +

LENORE: The best place is LinkedIn. My name Lenore Champagne Beirne is really easy to find. I'm the only one. And I'd love to have you all connect there. You can also submit...if you have a startup idea or an existing company that you're interested in bringing into Bright Venture's view, please feel free to submit that on our website, which is www.brightventures.io. And you could technically find me on Twitter, but I won't really be there. [laughs] So I hesitate to suggest it as a place to communicate with me.

+ +

CHAD: We're going to link all of that in the show notes as well, along with a complete transcript for this episode. You can find all of that at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can technically find me on Twitter as well at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening.

+ +

Lenore, thank you so much for joining me. I really appreciate it.

+ +

LENORE: So great to be here. Thanks again, Chad, for the questions.

+ +

CHAD: And see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Lenore Champagne Beirne.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bjteCc_y + + ]]> + + Chad Pytel + Lenore Champagne Beirne + + + 437: Hello Prenup with Sarabeth Jaffe + https://podcast.thoughtbot.com/437 + 3c76b9c4-358c-47ea-9f73-4e2bc9a280b7 + Thu, 25 Aug 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Sarabeth Jaffe is CTO and Co-Founder at HelloPrenup, the digital prenup platform designed to get couples on the same page. + +Chad talks with Sarabeth about dogfooding her own product, completely starting over from a technical perspective using Bubble, a low-code/no-code platform, and appearing on the ABC hit series Shark Tank. + 30:40 + no + + + Sarabeth Jaffe is CTO and Co-Founder at HelloPrenup, the digital prenup platform designed to get couples on the same page. +Chad talks with Sarabeth about dogfooding her own product, completely starting over from a technical perspective using Bubble, a low-code/no-code platform, and appearing on the ABC hit series Shark Tank. +Hello Prenup (https://helloprenup.com/) +Follow Hello Prenup on Twitter (https://twitter.com/HelloPrenup), Instagram (https://www.instagram.com/helloprenup/), YouTube (https://www.youtube.com/channel/UCqe-NOs0xV7yEebsg8om27A), Pinterest (https://www.pinterest.com/HelloPrenup/), or LinkedIn (https://www.linkedin.com/company/helloprenup/). +Follow Sarabeth on Twitter (https://twitter.com/sarabethjaffe) or LinkedIn (https://www.linkedin.com/in/sarabethjaffe/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Sarabeth Jaffe, CTO, and Co-Founder at HelloPrenup, the digital prenup platform designed to get couples on the same page. Sarabeth, thank you so much for joining me. +SARABETH: Thank you so much for having me. +CHAD: I can't say that I was aware of your...or that I wanted to think about prenups and seeking out a product around prenups. But it's super interesting to me. And I'm sure that that's part of both the challenge and opportunity with HelloPrenup. So, tell us a little bit about the product. +SARABETH: So, as you mentioned, HelloPrenup is really the first of its kind. It's a digital platform that allows couples to create a prenuptial agreement that they're both happy with completely online and for a fraction of the cost of going to an attorney. So why is that interesting for folks these days? Really it's because couples are talking about their finances a lot more before they go into marriage. People are getting married later in life, so they have more assets to protect, or in many couples' cases, they have a lot of existing student loans or other liabilities that they can actually protect their partner from. +So I think a lot of couples are becoming more open to prenuptial agreements as a way to kind of start off their marriage with a clean slate. And I can actually speak to our customers because I actually built HelloPrenup after I got engaged. And I was looking into getting a prenup. My fiancé and I we've been together for over seven years; we've known each other for over ten years. And we've always been really transparent about everything and especially our finances. +And I love being financially savvy, looking at my investment portfolio, and being really frugal and everything. So to me, getting a prenup was always just the smart move. Being kind of a realistic person whose parents are actually divorced now, I view marriage as a partnership that, if it's working, when it's working, that's amazing. But if things don't work out, I think there should be a different path that you're able to take seamlessly. +So when we did get engaged, I started looking into how to get a prenup, and it was a really confusing process. If you want to get a prenup without using HelloPrenup, you have to contact a divorce attorney before you're even married, which kind of starts the precedent of your marital journey off kind of a little weird. And also, hiring a divorce attorney for your prenup can cost a lot of money. The average cost is like $300 an hour. So it kind of depends on how complex your prenup is. +But if you're planning your wedding, buying an engagement ring, maybe trying to buy a house soon, you're going to put a prenup on the back burner because of the costs, even though it's a really important financial planning tool. So that's why I came up with the idea. I'm a software engineer. This is something that I think I could build is a platform for couples who want to get a prenup done really conveniently and for a fraction of the cost. +So I started working on HelloPrenup on my own in February of 2021, so a little bit over a year ago. And of course, I quickly found out that I don't know all the laws required, [chuckles] and I don't know how to write a good prenup contract. So I need either a legal advisor or an attorney to really help me figure these things out, especially because the law per state actually is different. +CHAD: Just so I understand the timeline, did you start it before you got married? Or did you end up doing a prenup through an attorney for yourself? +SARABETH: Ah, yes. So actually, we're getting married this Saturday. +CHAD: Wow. Okay. Congratulations. +SARABETH: Thank you so much. And we are HelloPrenup users. +CHAD: Okay, wow. +SARABETH: So we did our prenup with our platform. +CHAD: So you managed to get the product done before you got married so that you could use it? +SARABETH: Yes, yes. I wasn't going to get married without the prenup and going through an attorney. [laughs] I gotta...what is the expression? Like, reap what you sow or something like that. +CHAD: Yeah, or eat your own dog food is another one. +SARABETH: Yes. Dogfooding our own product has been amazingly beneficial for our team. So that's kind of where I left off in our story so far. I needed to find an attorney. +CHAD: I'm curious, you know, I'm a software developer too. I think we all have ideas. How did it become just from an idea to a thing you were really going to do? Where was that sort of switch? When did that switch get flipped? +SARABETH: When I came up with the idea for a digital prenup platform, I was actually unemployed. So this was kind of in the middle of the pandemic. I was previously working at a really awesome startup based in Seattle, Washington. But unfortunately, I was actually going through a lot of depression, and I felt really disconnected from my work. So I ended up quitting that job in November. So I took about three months off to recenter myself and figure out what I wanted to do next. +So when I thought of the idea for a prenup platform, I had the mental capacity to dig into the problem. And when I figured that it would probably be a profitable business, that's when I started to work on it full time. And I didn't have another job, so I was able to jump into it. +CHAD: Okay, so you then needed to find an attorney. You realized that was something you lacked. +SARABETH: Yeah, so I started doing some Googling while I was deciding whether this was something I definitely wanted to commit to, to see if there were competitor platforms. And I actually found HelloPrenup at that time. Of course, I wasn't involved with it. And so my co-founder now her name is Julia Rodgers Esquire. So she is a divorce attorney based out of Massachusetts. She actually had been building this product, which was completely aligned with my envisioning of what I was going to build. But of course, she had the legal background of it. +So I found her platform, and I noticed when I tried to sign up for the platform that the system was under maintenance. So I was like, huh, maybe they need technical help. So I actually ended up cold emailing her to see whether she needed any software help with the hopes that we could team up. And the next day, we just hopped on a Zoom. It's interesting talking to someone who you've never met before about possibly teaming up on something or potentially being a competitor to them. I made it very clear that I would much rather team up with her rather than try to figure this out on my own. +CHAD: That sort of sounds like a threat. +[laughter] +SARABETH: Oh my God. +CHAD: I'd much rather team up with you than have to do this on my own. [laughs] +SARABETH: Well, I really respected what she had built at that point. So she had put a lot of time into actually writing a lot of content and blogs around prenuptial agreements. So she had a really good base for the business. But it was really the software that she was running into issues with. So she had been struggling and working with overseas developers. So as an attorney, she didn't have a lot of experience project managing a software project like that. And especially with contract developers, you can't say, "I want this to be built in a sustainable, scalable fashion." +So there were a lot of bugs with the platform. The way I saw it was like, hey, she kind of has this MVP. And she's an attorney, so I think we would make an amazing team. I was also really excited at the prospect of being able to work with another woman entrepreneur. And we hit it off really quickly on our Zoom call. And yeah, so we've been working together since about March of 2021. +CHAD: Did you end up keeping what she already had from a technical perspective, or did you start over? +SARABETH: We completely started over. I tried to salvage the codebase that they had used. It was like Angular, which I actually despise Angular framework in general. I tried my best to clean it up, but they had no tests. They had a bunch of copy and pasted code. It was just kind of a mess. So that's when I really decided that Bubble would be a great option for us. +CHAD: Well, for those who don't know, Bubble is like a low-code/no-code platform. +SARABETH: Yes. So it's called Bubble.io. It is, as Chad just said, you know, it's a low-code platform which allows you to actually build full-stack web applications. So unlike other website builders like Squarespace or Wix, you actually have a database or a back-end component to your application. And of course, for the majority of applications, that's really a requirement to build something actually useful for people. +So I'd been playing around with Bubble.io before we scrapped the codebase. And it was a good starting point because I'm still currently the only full-time developer on our team. And because we are using a low-code platform, we're able to move a lot faster with a lot of our feature development because there are a lot of things that had been done for us. So there are a lot of drag and drop features that we can leverage via different plugins. +CHAD: It's an interesting choice to me, not because I don't think it makes sense, but I think a lot of developers...you are a developer; you know how to code. +SARABETH: [chuckles] +CHAD: And I think a lot of developers, when faced with that choice, can't resist writing custom software. +SARABETH: Yeah. [chuckles] You know, I've always been torn between the development and the product world. And for a while, that was really a struggle for me deciding whether I wanted to be a product manager or a software engineer. So I settled on being a product-driven software engineer. So to me, the use case of like, I could write the traditional code, but it'll be a lot slower, or I could build the product a lot faster by using this tooling. That's where I land most of the time, like, the more time-efficient way to do things. +CHAD: From deciding to work together and starting to work together to okay, I'm going to rewrite this in Bubble; what point were you back online with the new version? How long did that take? +SARABETH: Yeah, so that took us about three months to get it relaunched, and so I was pretty happy with that. I mean, of course, there's still a ton of work that we're doing to build out the product, but to really get it back up and running and also in a more scalable way so that we actually can provide prenups across multiple different states now. So it's a lot more flexible in the way that it was built. So it took about three months to get it relaunched. +CHAD: So at what point then did you go on Shark Tank? [laughs] +SARABETH: So [chuckles] there were a lot of variables in play. And so, I was really thankful that we chose to use Bubble because the speed at which I needed to develop this was even more reduced. So we started talking to producers pretty quickly after we decided to team up together. It's a really unusual entrepreneur journey, I would say. I knew that it would make a good story because prenups are kind of taboo, as you mentioned. Television loves something a little spicy, a little bit dramatic. +So we started talking to producers, I want to say, in June or July, maybe even in May. And at that point, we hadn't relaunched the product. So we were really just pitching the idea. And we were pitching ourselves as founders to the producers and the exciting concept of how will the American public perceive a product that is a little bit taboo talking about prenuptial agreements before you get married? +If you're familiar with Shark Tank, you probably see that they have a lot of wedding-related companies that go on. But we were kind of flipping the script on that. So while I was rewriting the entire software, we were also going through the auditioning process of Shark Tank. +CHAD: I can imagine that's pretty intense. +SARABETH: Yes. +CHAD: I think the closest thing I can think of is when you enter into an accelerator or something like that. You might be in it for three months. You're going to have demo day at the end. But with that, you're presenting to a group of people. It's not broadcast on national television. +SARABETH: Yes. [laughs] +CHAD: It's probably a little bit of a different thing, and there are no producers involved, that kind of thing. +SARABETH: Yeah, yeah, exactly. By the time we had gotten on the set of Shark Tank to pitch our products, we'd only really been relaunched for about a month and a half. [laughs] So we were flying...I'm so bad at expressions. +CHAD: [laughs] +SARABETH: We were pitching... +CHAD: By the seat of your pants. +SARABETH: Yes, that one. Thank you so much. [laughter] So we were really pitching the potential of our product. And we were just so ecstatic to be there. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint +CHAD: When you went on Shark Tank, how much of what you said and those kinds of things was all you, or how much is it put together for the show? +SARABETH: Really, the only thing that is heavily vetted by producers is your pitch. So when you walk into the tank, and you give your 30-second to 2-minute spiel that's a bit more theatrical, you practice that over and over and over again. And it was really a fascinating experience. Because as a fellow software engineer, you know we're kind of more chill people, [laughs] more realistic. But they kept saying, "Bring more energy to it. Do big movements, maybe even do a dance or something." [laughter] I'm kind of living this double life where I'm writing software, and then I'm -- +CHAD: In between rehearsals, you're opening your laptop and making another thing happen on the app, I'm sure. +SARABETH: Exactly. It's like, oh, okay, we have pitch practice tonight, and now I'm going to work on this core feature. Without it, we literally don't have a product. So the producers are very involved in your initial pitch. But then when you jump into the Q&A, when the Sharks start asking you questions, that's all you. +CHAD: That's really cool. So are you happy that you went on Shark Tank? +SARABETH: Yes, I'm so happy that we went on. I've always been a Shark Tank fan. I think it's been on for over ten years. Shark Tank has been something that's kind of kept me interested in being an entrepreneur. When I started learning how to code, I knew that I always wanted to start a business. And just seeing the number of ideas and the variety of businesses that people are able to build and putting that on a show is just a fascinating concept. So I was really happy to go on the show. And, of course, the impact on our business has been tremendous. +Really, it changed the trajectory of our business. We gain most of our customers through organic search. So most of our customers come in through Google saying like, how do I get an online prenup? By getting on national television, we are really thankful that news stations were now interested in talking to us. So by linking to our website, that helped boost our search engine optimization rankings. And so now we're actually a profitable business due to Shark Tank. +CHAD: That's awesome. So is the tech team still just you? +SARABETH: The tech team is me. And I have started working with another Bubble developer on a contract basis. But calling out to any software engineers or low-code developers, if you're interested in joining a legal tech company that's growing a lot, feel free to reach out to me. So I really do need to be hiring another developer. At this point, I am really the main developer working on things for a variety of reasons. +The first reason is that Bubble, while it is very quick to develop a product on your own from a technical perspective, it is lacking in features when it comes to collaboration with other developers. So with traditional code, you'll do code reviews on GitHub, and you'll just do like a diff. But the branching and the version control is definitely a little bit lacking. +So I'm trying to wait out the Bubble team. They have some stuff coming down the pipeline that will make it easier to do collaboration. But for that reason, it is a little bit easier as an entrepreneur using a low-code platform to be the sole developer because you kind of know exactly how everything works. +And then also, developers are really expensive. So we are actually a completely self-funded company at this point. So we're bootstrapped. We haven't actually accepted any investment at this point. We're a really conservative team. If we hire a developer, we want to make sure that we're able to provide them with a competitive salary and competitive package. And we're able to do that now. It's just a matter of finding the right person, which is actually a really interesting space because low-code developers are still on the up and up right now. +CHAD: I know you can't see the future. But do you foresee a point where either Bubble doesn't take you where you want to go, or you need to start augmenting it in some way? +SARABETH: I would like to push Bubble as far as I can. I think now that Bubble is getting a lot more recognition...and they just got another round of funding that was pretty substantial. I think that they're going to be improving a lot of things, especially when it comes to, like I mentioned, collaborating with other developers on the platform and performance. A lot of pushback that people give with low-code platforms is like, oh, the page won't load as quickly as if I wrote it with pure React or something like that. So I want to try and stay on the platform as long as possible. +If we really continue to grow, I would be willing to move back to traditional code. And we'd actually be set up for success in that way because we would have a fully functioning product, and half of development is figuring out what feature to build next. So we'd kind of say, all right, here's how it works. And then, while we're kind of maintaining our Bubble application, we can have a development team build it within our own platform. Does that make sense? +CHAD: It does. And I think with Bubble, it doesn't need to be all or nothing, right? +SARABETH: Mm-hmm. +CHAD: You can use APIs. Or you can basically extend it with custom code if you really needed to using webhooks and that kind of thing, right? +SARABETH: Exactly. And that's the way that we've done it. So actually, the contract generation is written in Node.js JavaScript. And the reason I did that is because it's easier to process data in a sequential order with traditional code versus Bubble. And you can also hook into other APIs, like for us, we do a conversion of the HTML of the contract into a Word doc. +So we're able to call into a conversion API and then save it on AWS with traditional code, and you can do all that with Bubble. But it's a little bit more straightforward when you know what you're doing with just like JavaScript; you know a few lines here and there. Does that make sense? +CHAD: It does, yeah. I'll be super interested to see how far you're able to push it and what those things you need to do outside of Bubble are. +SARABETH: Yeah, I'm really excited to try to push Bubble as an option for entrepreneurs. We were actually the first low-code platform to be shown on Shark Tank. So every Bubble developer on Twitter was really excited about it. +CHAD: [laughs] +SARABETH: So I think it's a really interesting spot to be in right now. +CHAD: Yeah, from a technology perspective, I think that that's one thing we've talked about. And you addressed the other thing that sometimes people say is a promise. Like, it is a commercial platform. It's not an open-source platform, and you're building entirely on top of it. And so that presents a certain amount of risk that like, they might go out of business. You know, they're a VC-backed company, and maybe they'll go out of business. And then where would you be? The fact that they've just raised a significant additional round of funding mitigates that somewhat, but it's still a concern, right? +SARABETH: Yeah, it's definitely a concern. And it's something that, as a software engineer, it's terrifying to know that you're relying on someone else for your livelihood and now the livelihood of multiple people on our team. So it is really scary. You cannot export your code from Bubble. But I believe they have said that if for some reason they go out of business, they will allow you to do that. +I'm sure whatever code you export from it is not going to be very pretty to look at. So it probably makes sense to write it from scratch. But I think at this point, I'm really happy with where we're at. I like remaining a really lean team. And using different tools in simple ways and trying to keep our product as simple as possible has really helped us grow. +CHAD: What's next for HelloPrenup? Where are you setting your sights on? What's keeping you up at night now? +SARABETH: Ooh, so many things. We do have an exciting investor coming on. I can't say exactly who, but they were really involved in building one of the largest legal tech platforms out there today. So we're really excited to be partnering with them and be building out our network across all 50 states. Right now, we're actually in, I believe, 32 states. You can use our platform to create your prenuptial agreement. And so, we're excited to be starting to onboard attorneys to the platform. So that's one of the things. +Another thing that's on our radar is keeping up with, you know, it's hard to say the trends of what's going on with Web3. But we do have some things that are related to Web3 that we'll be tackling in the next probably a year or a couple of years when it comes to financial data. Yeah, so those things are kind of on our radar of our product. +And then, on the near term, we are doing a lot of work to try and normalize the entire conversation around prenuptial agreements. We partnered with The Knot, which is one of the largest online wedding registry websites. And we've been writing a lot of blogs on their website that talk about the educational side of prenups. And we're actually going to be launching gift cards. +CHAD: [chuckles] +SARABETH: So you can list a prenuptial agreement on your wedding registry, and people can help support it. So there are a lot of initiatives that we're going to be doing on the product development side and then also kind of on the marketing education side of the business. As we start to grow, I'm trying to pull my attention away from those things. But sometimes, it's really hard because some parts of the business that aren't technical are fun to get involved in. And I'm sure you run into that or when you were scaling thoughtbot getting distracted by other parts of the business because they were just interesting. But there's a lot going on right now. +CHAD: That's exciting. You mentioned earlier that you hadn't taken investors yet. And so is it about that scale that's causing you to take one on now, or what's going on there? +SARABETH: So we're profitable. We don't need an investor, which is we're so thankful for that. So it's really a strategic partnership for us. +CHAD: Well, that's really cool. I'm excited to hear everything you have going on. And I really wish you luck in everything that you're doing. +SARABETH: Thank you so much. +CHAD: So if folks want to find out more about HelloPrenup, follow along with you, get in touch with you; where are all the best places for them to do that? +SARABETH: You can check us out on helloprenup.com. And we're on Twitter, Instagram, LinkedIn. Just tweet at us @HelloPrenup, and one of us will respond. It'll probably be myself or Julia. So you're able to get into contact with us if you have any questions. And of course, if you are a developer who is looking to join a really fun, women-led legal tech company, hit me up. +CHAD: Awesome. You can subscribe to the show and find notes with links for everything that Sarabeth just mentioned, along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments for me, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thank you so much for joining me, Sarabeth. I really appreciate it. +SARABETH: Thank you so much. +CHAD: And thank you for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Sarabeth Jaffe. + + + Sarabeth Jaffe is CTO and Co-Founder at HelloPrenup, the digital prenup platform designed to get couples on the same page.

+ +

Chad talks with Sarabeth about dogfooding her own product, completely starting over from a technical perspective using Bubble, a low-code/no-code platform, and appearing on the ABC hit series Shark Tank.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Sarabeth Jaffe, CTO, and Co-Founder at HelloPrenup, the digital prenup platform designed to get couples on the same page. Sarabeth, thank you so much for joining me.

+ +

SARABETH: Thank you so much for having me.

+ +

CHAD: I can't say that I was aware of your...or that I wanted to think about prenups and seeking out a product around prenups. But it's super interesting to me. And I'm sure that that's part of both the challenge and opportunity with HelloPrenup. So, tell us a little bit about the product.

+ +

SARABETH: So, as you mentioned, HelloPrenup is really the first of its kind. It's a digital platform that allows couples to create a prenuptial agreement that they're both happy with completely online and for a fraction of the cost of going to an attorney. So why is that interesting for folks these days? Really it's because couples are talking about their finances a lot more before they go into marriage. People are getting married later in life, so they have more assets to protect, or in many couples' cases, they have a lot of existing student loans or other liabilities that they can actually protect their partner from.

+ +

So I think a lot of couples are becoming more open to prenuptial agreements as a way to kind of start off their marriage with a clean slate. And I can actually speak to our customers because I actually built HelloPrenup after I got engaged. And I was looking into getting a prenup. My fiancé and I we've been together for over seven years; we've known each other for over ten years. And we've always been really transparent about everything and especially our finances.

+ +

And I love being financially savvy, looking at my investment portfolio, and being really frugal and everything. So to me, getting a prenup was always just the smart move. Being kind of a realistic person whose parents are actually divorced now, I view marriage as a partnership that, if it's working, when it's working, that's amazing. But if things don't work out, I think there should be a different path that you're able to take seamlessly.

+ +

So when we did get engaged, I started looking into how to get a prenup, and it was a really confusing process. If you want to get a prenup without using HelloPrenup, you have to contact a divorce attorney before you're even married, which kind of starts the precedent of your marital journey off kind of a little weird. And also, hiring a divorce attorney for your prenup can cost a lot of money. The average cost is like $300 an hour. So it kind of depends on how complex your prenup is.

+ +

But if you're planning your wedding, buying an engagement ring, maybe trying to buy a house soon, you're going to put a prenup on the back burner because of the costs, even though it's a really important financial planning tool. So that's why I came up with the idea. I'm a software engineer. This is something that I think I could build is a platform for couples who want to get a prenup done really conveniently and for a fraction of the cost.

+ +

So I started working on HelloPrenup on my own in February of 2021, so a little bit over a year ago. And of course, I quickly found out that I don't know all the laws required, [chuckles] and I don't know how to write a good prenup contract. So I need either a legal advisor or an attorney to really help me figure these things out, especially because the law per state actually is different.

+ +

CHAD: Just so I understand the timeline, did you start it before you got married? Or did you end up doing a prenup through an attorney for yourself?

+ +

SARABETH: Ah, yes. So actually, we're getting married this Saturday.

+ +

CHAD: Wow. Okay. Congratulations.

+ +

SARABETH: Thank you so much. And we are HelloPrenup users.

+ +

CHAD: Okay, wow.

+ +

SARABETH: So we did our prenup with our platform.

+ +

CHAD: So you managed to get the product done before you got married so that you could use it?

+ +

SARABETH: Yes, yes. I wasn't going to get married without the prenup and going through an attorney. [laughs] I gotta...what is the expression? Like, reap what you sow or something like that.

+ +

CHAD: Yeah, or eat your own dog food is another one.

+ +

SARABETH: Yes. Dogfooding our own product has been amazingly beneficial for our team. So that's kind of where I left off in our story so far. I needed to find an attorney.

+ +

CHAD: I'm curious, you know, I'm a software developer too. I think we all have ideas. How did it become just from an idea to a thing you were really going to do? Where was that sort of switch? When did that switch get flipped?

+ +

SARABETH: When I came up with the idea for a digital prenup platform, I was actually unemployed. So this was kind of in the middle of the pandemic. I was previously working at a really awesome startup based in Seattle, Washington. But unfortunately, I was actually going through a lot of depression, and I felt really disconnected from my work. So I ended up quitting that job in November. So I took about three months off to recenter myself and figure out what I wanted to do next.

+ +

So when I thought of the idea for a prenup platform, I had the mental capacity to dig into the problem. And when I figured that it would probably be a profitable business, that's when I started to work on it full time. And I didn't have another job, so I was able to jump into it.

+ +

CHAD: Okay, so you then needed to find an attorney. You realized that was something you lacked.

+ +

SARABETH: Yeah, so I started doing some Googling while I was deciding whether this was something I definitely wanted to commit to, to see if there were competitor platforms. And I actually found HelloPrenup at that time. Of course, I wasn't involved with it. And so my co-founder now her name is Julia Rodgers Esquire. So she is a divorce attorney based out of Massachusetts. She actually had been building this product, which was completely aligned with my envisioning of what I was going to build. But of course, she had the legal background of it.

+ +

So I found her platform, and I noticed when I tried to sign up for the platform that the system was under maintenance. So I was like, huh, maybe they need technical help. So I actually ended up cold emailing her to see whether she needed any software help with the hopes that we could team up. And the next day, we just hopped on a Zoom. It's interesting talking to someone who you've never met before about possibly teaming up on something or potentially being a competitor to them. I made it very clear that I would much rather team up with her rather than try to figure this out on my own.

+ +

CHAD: That sort of sounds like a threat.

+ +

[laughter]

+ +

SARABETH: Oh my God.

+ +

CHAD: I'd much rather team up with you than have to do this on my own. [laughs]

+ +

SARABETH: Well, I really respected what she had built at that point. So she had put a lot of time into actually writing a lot of content and blogs around prenuptial agreements. So she had a really good base for the business. But it was really the software that she was running into issues with. So she had been struggling and working with overseas developers. So as an attorney, she didn't have a lot of experience project managing a software project like that. And especially with contract developers, you can't say, "I want this to be built in a sustainable, scalable fashion."

+ +

So there were a lot of bugs with the platform. The way I saw it was like, hey, she kind of has this MVP. And she's an attorney, so I think we would make an amazing team. I was also really excited at the prospect of being able to work with another woman entrepreneur. And we hit it off really quickly on our Zoom call. And yeah, so we've been working together since about March of 2021.

+ +

CHAD: Did you end up keeping what she already had from a technical perspective, or did you start over?

+ +

SARABETH: We completely started over. I tried to salvage the codebase that they had used. It was like Angular, which I actually despise Angular framework in general. I tried my best to clean it up, but they had no tests. They had a bunch of copy and pasted code. It was just kind of a mess. So that's when I really decided that Bubble would be a great option for us.

+ +

CHAD: Well, for those who don't know, Bubble is like a low-code/no-code platform.

+ +

SARABETH: Yes. So it's called Bubble.io. It is, as Chad just said, you know, it's a low-code platform which allows you to actually build full-stack web applications. So unlike other website builders like Squarespace or Wix, you actually have a database or a back-end component to your application. And of course, for the majority of applications, that's really a requirement to build something actually useful for people.

+ +

So I'd been playing around with Bubble.io before we scrapped the codebase. And it was a good starting point because I'm still currently the only full-time developer on our team. And because we are using a low-code platform, we're able to move a lot faster with a lot of our feature development because there are a lot of things that had been done for us. So there are a lot of drag and drop features that we can leverage via different plugins.

+ +

CHAD: It's an interesting choice to me, not because I don't think it makes sense, but I think a lot of developers...you are a developer; you know how to code.

+ +

SARABETH: [chuckles]

+ +

CHAD: And I think a lot of developers, when faced with that choice, can't resist writing custom software.

+ +

SARABETH: Yeah. [chuckles] You know, I've always been torn between the development and the product world. And for a while, that was really a struggle for me deciding whether I wanted to be a product manager or a software engineer. So I settled on being a product-driven software engineer. So to me, the use case of like, I could write the traditional code, but it'll be a lot slower, or I could build the product a lot faster by using this tooling. That's where I land most of the time, like, the more time-efficient way to do things.

+ +

CHAD: From deciding to work together and starting to work together to okay, I'm going to rewrite this in Bubble; what point were you back online with the new version? How long did that take?

+ +

SARABETH: Yeah, so that took us about three months to get it relaunched, and so I was pretty happy with that. I mean, of course, there's still a ton of work that we're doing to build out the product, but to really get it back up and running and also in a more scalable way so that we actually can provide prenups across multiple different states now. So it's a lot more flexible in the way that it was built. So it took about three months to get it relaunched.

+ +

CHAD: So at what point then did you go on Shark Tank? [laughs]

+ +

SARABETH: So [chuckles] there were a lot of variables in play. And so, I was really thankful that we chose to use Bubble because the speed at which I needed to develop this was even more reduced. So we started talking to producers pretty quickly after we decided to team up together. It's a really unusual entrepreneur journey, I would say. I knew that it would make a good story because prenups are kind of taboo, as you mentioned. Television loves something a little spicy, a little bit dramatic.

+ +

So we started talking to producers, I want to say, in June or July, maybe even in May. And at that point, we hadn't relaunched the product. So we were really just pitching the idea. And we were pitching ourselves as founders to the producers and the exciting concept of how will the American public perceive a product that is a little bit taboo talking about prenuptial agreements before you get married?

+ +

If you're familiar with Shark Tank, you probably see that they have a lot of wedding-related companies that go on. But we were kind of flipping the script on that. So while I was rewriting the entire software, we were also going through the auditioning process of Shark Tank.

+ +

CHAD: I can imagine that's pretty intense.

+ +

SARABETH: Yes.

+ +

CHAD: I think the closest thing I can think of is when you enter into an accelerator or something like that. You might be in it for three months. You're going to have demo day at the end. But with that, you're presenting to a group of people. It's not broadcast on national television.

+ +

SARABETH: Yes. [laughs]

+ +

CHAD: It's probably a little bit of a different thing, and there are no producers involved, that kind of thing.

+ +

SARABETH: Yeah, yeah, exactly. By the time we had gotten on the set of Shark Tank to pitch our products, we'd only really been relaunched for about a month and a half. [laughs] So we were flying...I'm so bad at expressions.

+ +

CHAD: [laughs]

+ +

SARABETH: We were pitching...

+ +

CHAD: By the seat of your pants.

+ +

SARABETH: Yes, that one. Thank you so much. [laughter] So we were really pitching the potential of our product. And we were just so ecstatic to be there.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

CHAD: When you went on Shark Tank, how much of what you said and those kinds of things was all you, or how much is it put together for the show?

+ +

SARABETH: Really, the only thing that is heavily vetted by producers is your pitch. So when you walk into the tank, and you give your 30-second to 2-minute spiel that's a bit more theatrical, you practice that over and over and over again. And it was really a fascinating experience. Because as a fellow software engineer, you know we're kind of more chill people, [laughs] more realistic. But they kept saying, "Bring more energy to it. Do big movements, maybe even do a dance or something." [laughter] I'm kind of living this double life where I'm writing software, and then I'm --

+ +

CHAD: In between rehearsals, you're opening your laptop and making another thing happen on the app, I'm sure.

+ +

SARABETH: Exactly. It's like, oh, okay, we have pitch practice tonight, and now I'm going to work on this core feature. Without it, we literally don't have a product. So the producers are very involved in your initial pitch. But then when you jump into the Q&A, when the Sharks start asking you questions, that's all you.

+ +

CHAD: That's really cool. So are you happy that you went on Shark Tank?

+ +

SARABETH: Yes, I'm so happy that we went on. I've always been a Shark Tank fan. I think it's been on for over ten years. Shark Tank has been something that's kind of kept me interested in being an entrepreneur. When I started learning how to code, I knew that I always wanted to start a business. And just seeing the number of ideas and the variety of businesses that people are able to build and putting that on a show is just a fascinating concept. So I was really happy to go on the show. And, of course, the impact on our business has been tremendous.

+ +

Really, it changed the trajectory of our business. We gain most of our customers through organic search. So most of our customers come in through Google saying like, how do I get an online prenup? By getting on national television, we are really thankful that news stations were now interested in talking to us. So by linking to our website, that helped boost our search engine optimization rankings. And so now we're actually a profitable business due to Shark Tank.

+ +

CHAD: That's awesome. So is the tech team still just you?

+ +

SARABETH: The tech team is me. And I have started working with another Bubble developer on a contract basis. But calling out to any software engineers or low-code developers, if you're interested in joining a legal tech company that's growing a lot, feel free to reach out to me. So I really do need to be hiring another developer. At this point, I am really the main developer working on things for a variety of reasons.

+ +

The first reason is that Bubble, while it is very quick to develop a product on your own from a technical perspective, it is lacking in features when it comes to collaboration with other developers. So with traditional code, you'll do code reviews on GitHub, and you'll just do like a diff. But the branching and the version control is definitely a little bit lacking.

+ +

So I'm trying to wait out the Bubble team. They have some stuff coming down the pipeline that will make it easier to do collaboration. But for that reason, it is a little bit easier as an entrepreneur using a low-code platform to be the sole developer because you kind of know exactly how everything works.

+ +

And then also, developers are really expensive. So we are actually a completely self-funded company at this point. So we're bootstrapped. We haven't actually accepted any investment at this point. We're a really conservative team. If we hire a developer, we want to make sure that we're able to provide them with a competitive salary and competitive package. And we're able to do that now. It's just a matter of finding the right person, which is actually a really interesting space because low-code developers are still on the up and up right now.

+ +

CHAD: I know you can't see the future. But do you foresee a point where either Bubble doesn't take you where you want to go, or you need to start augmenting it in some way?

+ +

SARABETH: I would like to push Bubble as far as I can. I think now that Bubble is getting a lot more recognition...and they just got another round of funding that was pretty substantial. I think that they're going to be improving a lot of things, especially when it comes to, like I mentioned, collaborating with other developers on the platform and performance. A lot of pushback that people give with low-code platforms is like, oh, the page won't load as quickly as if I wrote it with pure React or something like that. So I want to try and stay on the platform as long as possible.

+ +

If we really continue to grow, I would be willing to move back to traditional code. And we'd actually be set up for success in that way because we would have a fully functioning product, and half of development is figuring out what feature to build next. So we'd kind of say, all right, here's how it works. And then, while we're kind of maintaining our Bubble application, we can have a development team build it within our own platform. Does that make sense?

+ +

CHAD: It does. And I think with Bubble, it doesn't need to be all or nothing, right?

+ +

SARABETH: Mm-hmm.

+ +

CHAD: You can use APIs. Or you can basically extend it with custom code if you really needed to using webhooks and that kind of thing, right?

+ +

SARABETH: Exactly. And that's the way that we've done it. So actually, the contract generation is written in Node.js JavaScript. And the reason I did that is because it's easier to process data in a sequential order with traditional code versus Bubble. And you can also hook into other APIs, like for us, we do a conversion of the HTML of the contract into a Word doc.

+ +

So we're able to call into a conversion API and then save it on AWS with traditional code, and you can do all that with Bubble. But it's a little bit more straightforward when you know what you're doing with just like JavaScript; you know a few lines here and there. Does that make sense?

+ +

CHAD: It does, yeah. I'll be super interested to see how far you're able to push it and what those things you need to do outside of Bubble are.

+ +

SARABETH: Yeah, I'm really excited to try to push Bubble as an option for entrepreneurs. We were actually the first low-code platform to be shown on Shark Tank. So every Bubble developer on Twitter was really excited about it.

+ +

CHAD: [laughs]

+ +

SARABETH: So I think it's a really interesting spot to be in right now.

+ +

CHAD: Yeah, from a technology perspective, I think that that's one thing we've talked about. And you addressed the other thing that sometimes people say is a promise. Like, it is a commercial platform. It's not an open-source platform, and you're building entirely on top of it. And so that presents a certain amount of risk that like, they might go out of business. You know, they're a VC-backed company, and maybe they'll go out of business. And then where would you be? The fact that they've just raised a significant additional round of funding mitigates that somewhat, but it's still a concern, right?

+ +

SARABETH: Yeah, it's definitely a concern. And it's something that, as a software engineer, it's terrifying to know that you're relying on someone else for your livelihood and now the livelihood of multiple people on our team. So it is really scary. You cannot export your code from Bubble. But I believe they have said that if for some reason they go out of business, they will allow you to do that.

+ +

I'm sure whatever code you export from it is not going to be very pretty to look at. So it probably makes sense to write it from scratch. But I think at this point, I'm really happy with where we're at. I like remaining a really lean team. And using different tools in simple ways and trying to keep our product as simple as possible has really helped us grow.

+ +

CHAD: What's next for HelloPrenup? Where are you setting your sights on? What's keeping you up at night now?

+ +

SARABETH: Ooh, so many things. We do have an exciting investor coming on. I can't say exactly who, but they were really involved in building one of the largest legal tech platforms out there today. So we're really excited to be partnering with them and be building out our network across all 50 states. Right now, we're actually in, I believe, 32 states. You can use our platform to create your prenuptial agreement. And so, we're excited to be starting to onboard attorneys to the platform. So that's one of the things.

+ +

Another thing that's on our radar is keeping up with, you know, it's hard to say the trends of what's going on with Web3. But we do have some things that are related to Web3 that we'll be tackling in the next probably a year or a couple of years when it comes to financial data. Yeah, so those things are kind of on our radar of our product.

+ +

And then, on the near term, we are doing a lot of work to try and normalize the entire conversation around prenuptial agreements. We partnered with The Knot, which is one of the largest online wedding registry websites. And we've been writing a lot of blogs on their website that talk about the educational side of prenups. And we're actually going to be launching gift cards.

+ +

CHAD: [chuckles]

+ +

SARABETH: So you can list a prenuptial agreement on your wedding registry, and people can help support it. So there are a lot of initiatives that we're going to be doing on the product development side and then also kind of on the marketing education side of the business. As we start to grow, I'm trying to pull my attention away from those things. But sometimes, it's really hard because some parts of the business that aren't technical are fun to get involved in. And I'm sure you run into that or when you were scaling thoughtbot getting distracted by other parts of the business because they were just interesting. But there's a lot going on right now.

+ +

CHAD: That's exciting. You mentioned earlier that you hadn't taken investors yet. And so is it about that scale that's causing you to take one on now, or what's going on there?

+ +

SARABETH: So we're profitable. We don't need an investor, which is we're so thankful for that. So it's really a strategic partnership for us.

+ +

CHAD: Well, that's really cool. I'm excited to hear everything you have going on. And I really wish you luck in everything that you're doing.

+ +

SARABETH: Thank you so much.

+ +

CHAD: So if folks want to find out more about HelloPrenup, follow along with you, get in touch with you; where are all the best places for them to do that?

+ +

SARABETH: You can check us out on helloprenup.com. And we're on Twitter, Instagram, LinkedIn. Just tweet at us @HelloPrenup, and one of us will respond. It'll probably be myself or Julia. So you're able to get into contact with us if you have any questions. And of course, if you are a developer who is looking to join a really fun, women-led legal tech company, hit me up.

+ +

CHAD: Awesome. You can subscribe to the show and find notes with links for everything that Sarabeth just mentioned, along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments for me, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you so much for joining me, Sarabeth. I really appreciate it.

+ +

SARABETH: Thank you so much.

+ +

CHAD: And thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Sarabeth Jaffe.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sarabeth Jaffe is CTO and Co-Founder at HelloPrenup, the digital prenup platform designed to get couples on the same page.

+ +

Chad talks with Sarabeth about dogfooding her own product, completely starting over from a technical perspective using Bubble, a low-code/no-code platform, and appearing on the ABC hit series Shark Tank.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Sarabeth Jaffe, CTO, and Co-Founder at HelloPrenup, the digital prenup platform designed to get couples on the same page. Sarabeth, thank you so much for joining me.

+ +

SARABETH: Thank you so much for having me.

+ +

CHAD: I can't say that I was aware of your...or that I wanted to think about prenups and seeking out a product around prenups. But it's super interesting to me. And I'm sure that that's part of both the challenge and opportunity with HelloPrenup. So, tell us a little bit about the product.

+ +

SARABETH: So, as you mentioned, HelloPrenup is really the first of its kind. It's a digital platform that allows couples to create a prenuptial agreement that they're both happy with completely online and for a fraction of the cost of going to an attorney. So why is that interesting for folks these days? Really it's because couples are talking about their finances a lot more before they go into marriage. People are getting married later in life, so they have more assets to protect, or in many couples' cases, they have a lot of existing student loans or other liabilities that they can actually protect their partner from.

+ +

So I think a lot of couples are becoming more open to prenuptial agreements as a way to kind of start off their marriage with a clean slate. And I can actually speak to our customers because I actually built HelloPrenup after I got engaged. And I was looking into getting a prenup. My fiancé and I we've been together for over seven years; we've known each other for over ten years. And we've always been really transparent about everything and especially our finances.

+ +

And I love being financially savvy, looking at my investment portfolio, and being really frugal and everything. So to me, getting a prenup was always just the smart move. Being kind of a realistic person whose parents are actually divorced now, I view marriage as a partnership that, if it's working, when it's working, that's amazing. But if things don't work out, I think there should be a different path that you're able to take seamlessly.

+ +

So when we did get engaged, I started looking into how to get a prenup, and it was a really confusing process. If you want to get a prenup without using HelloPrenup, you have to contact a divorce attorney before you're even married, which kind of starts the precedent of your marital journey off kind of a little weird. And also, hiring a divorce attorney for your prenup can cost a lot of money. The average cost is like $300 an hour. So it kind of depends on how complex your prenup is.

+ +

But if you're planning your wedding, buying an engagement ring, maybe trying to buy a house soon, you're going to put a prenup on the back burner because of the costs, even though it's a really important financial planning tool. So that's why I came up with the idea. I'm a software engineer. This is something that I think I could build is a platform for couples who want to get a prenup done really conveniently and for a fraction of the cost.

+ +

So I started working on HelloPrenup on my own in February of 2021, so a little bit over a year ago. And of course, I quickly found out that I don't know all the laws required, [chuckles] and I don't know how to write a good prenup contract. So I need either a legal advisor or an attorney to really help me figure these things out, especially because the law per state actually is different.

+ +

CHAD: Just so I understand the timeline, did you start it before you got married? Or did you end up doing a prenup through an attorney for yourself?

+ +

SARABETH: Ah, yes. So actually, we're getting married this Saturday.

+ +

CHAD: Wow. Okay. Congratulations.

+ +

SARABETH: Thank you so much. And we are HelloPrenup users.

+ +

CHAD: Okay, wow.

+ +

SARABETH: So we did our prenup with our platform.

+ +

CHAD: So you managed to get the product done before you got married so that you could use it?

+ +

SARABETH: Yes, yes. I wasn't going to get married without the prenup and going through an attorney. [laughs] I gotta...what is the expression? Like, reap what you sow or something like that.

+ +

CHAD: Yeah, or eat your own dog food is another one.

+ +

SARABETH: Yes. Dogfooding our own product has been amazingly beneficial for our team. So that's kind of where I left off in our story so far. I needed to find an attorney.

+ +

CHAD: I'm curious, you know, I'm a software developer too. I think we all have ideas. How did it become just from an idea to a thing you were really going to do? Where was that sort of switch? When did that switch get flipped?

+ +

SARABETH: When I came up with the idea for a digital prenup platform, I was actually unemployed. So this was kind of in the middle of the pandemic. I was previously working at a really awesome startup based in Seattle, Washington. But unfortunately, I was actually going through a lot of depression, and I felt really disconnected from my work. So I ended up quitting that job in November. So I took about three months off to recenter myself and figure out what I wanted to do next.

+ +

So when I thought of the idea for a prenup platform, I had the mental capacity to dig into the problem. And when I figured that it would probably be a profitable business, that's when I started to work on it full time. And I didn't have another job, so I was able to jump into it.

+ +

CHAD: Okay, so you then needed to find an attorney. You realized that was something you lacked.

+ +

SARABETH: Yeah, so I started doing some Googling while I was deciding whether this was something I definitely wanted to commit to, to see if there were competitor platforms. And I actually found HelloPrenup at that time. Of course, I wasn't involved with it. And so my co-founder now her name is Julia Rodgers Esquire. So she is a divorce attorney based out of Massachusetts. She actually had been building this product, which was completely aligned with my envisioning of what I was going to build. But of course, she had the legal background of it.

+ +

So I found her platform, and I noticed when I tried to sign up for the platform that the system was under maintenance. So I was like, huh, maybe they need technical help. So I actually ended up cold emailing her to see whether she needed any software help with the hopes that we could team up. And the next day, we just hopped on a Zoom. It's interesting talking to someone who you've never met before about possibly teaming up on something or potentially being a competitor to them. I made it very clear that I would much rather team up with her rather than try to figure this out on my own.

+ +

CHAD: That sort of sounds like a threat.

+ +

[laughter]

+ +

SARABETH: Oh my God.

+ +

CHAD: I'd much rather team up with you than have to do this on my own. [laughs]

+ +

SARABETH: Well, I really respected what she had built at that point. So she had put a lot of time into actually writing a lot of content and blogs around prenuptial agreements. So she had a really good base for the business. But it was really the software that she was running into issues with. So she had been struggling and working with overseas developers. So as an attorney, she didn't have a lot of experience project managing a software project like that. And especially with contract developers, you can't say, "I want this to be built in a sustainable, scalable fashion."

+ +

So there were a lot of bugs with the platform. The way I saw it was like, hey, she kind of has this MVP. And she's an attorney, so I think we would make an amazing team. I was also really excited at the prospect of being able to work with another woman entrepreneur. And we hit it off really quickly on our Zoom call. And yeah, so we've been working together since about March of 2021.

+ +

CHAD: Did you end up keeping what she already had from a technical perspective, or did you start over?

+ +

SARABETH: We completely started over. I tried to salvage the codebase that they had used. It was like Angular, which I actually despise Angular framework in general. I tried my best to clean it up, but they had no tests. They had a bunch of copy and pasted code. It was just kind of a mess. So that's when I really decided that Bubble would be a great option for us.

+ +

CHAD: Well, for those who don't know, Bubble is like a low-code/no-code platform.

+ +

SARABETH: Yes. So it's called Bubble.io. It is, as Chad just said, you know, it's a low-code platform which allows you to actually build full-stack web applications. So unlike other website builders like Squarespace or Wix, you actually have a database or a back-end component to your application. And of course, for the majority of applications, that's really a requirement to build something actually useful for people.

+ +

So I'd been playing around with Bubble.io before we scrapped the codebase. And it was a good starting point because I'm still currently the only full-time developer on our team. And because we are using a low-code platform, we're able to move a lot faster with a lot of our feature development because there are a lot of things that had been done for us. So there are a lot of drag and drop features that we can leverage via different plugins.

+ +

CHAD: It's an interesting choice to me, not because I don't think it makes sense, but I think a lot of developers...you are a developer; you know how to code.

+ +

SARABETH: [chuckles]

+ +

CHAD: And I think a lot of developers, when faced with that choice, can't resist writing custom software.

+ +

SARABETH: Yeah. [chuckles] You know, I've always been torn between the development and the product world. And for a while, that was really a struggle for me deciding whether I wanted to be a product manager or a software engineer. So I settled on being a product-driven software engineer. So to me, the use case of like, I could write the traditional code, but it'll be a lot slower, or I could build the product a lot faster by using this tooling. That's where I land most of the time, like, the more time-efficient way to do things.

+ +

CHAD: From deciding to work together and starting to work together to okay, I'm going to rewrite this in Bubble; what point were you back online with the new version? How long did that take?

+ +

SARABETH: Yeah, so that took us about three months to get it relaunched, and so I was pretty happy with that. I mean, of course, there's still a ton of work that we're doing to build out the product, but to really get it back up and running and also in a more scalable way so that we actually can provide prenups across multiple different states now. So it's a lot more flexible in the way that it was built. So it took about three months to get it relaunched.

+ +

CHAD: So at what point then did you go on Shark Tank? [laughs]

+ +

SARABETH: So [chuckles] there were a lot of variables in play. And so, I was really thankful that we chose to use Bubble because the speed at which I needed to develop this was even more reduced. So we started talking to producers pretty quickly after we decided to team up together. It's a really unusual entrepreneur journey, I would say. I knew that it would make a good story because prenups are kind of taboo, as you mentioned. Television loves something a little spicy, a little bit dramatic.

+ +

So we started talking to producers, I want to say, in June or July, maybe even in May. And at that point, we hadn't relaunched the product. So we were really just pitching the idea. And we were pitching ourselves as founders to the producers and the exciting concept of how will the American public perceive a product that is a little bit taboo talking about prenuptial agreements before you get married?

+ +

If you're familiar with Shark Tank, you probably see that they have a lot of wedding-related companies that go on. But we were kind of flipping the script on that. So while I was rewriting the entire software, we were also going through the auditioning process of Shark Tank.

+ +

CHAD: I can imagine that's pretty intense.

+ +

SARABETH: Yes.

+ +

CHAD: I think the closest thing I can think of is when you enter into an accelerator or something like that. You might be in it for three months. You're going to have demo day at the end. But with that, you're presenting to a group of people. It's not broadcast on national television.

+ +

SARABETH: Yes. [laughs]

+ +

CHAD: It's probably a little bit of a different thing, and there are no producers involved, that kind of thing.

+ +

SARABETH: Yeah, yeah, exactly. By the time we had gotten on the set of Shark Tank to pitch our products, we'd only really been relaunched for about a month and a half. [laughs] So we were flying...I'm so bad at expressions.

+ +

CHAD: [laughs]

+ +

SARABETH: We were pitching...

+ +

CHAD: By the seat of your pants.

+ +

SARABETH: Yes, that one. Thank you so much. [laughter] So we were really pitching the potential of our product. And we were just so ecstatic to be there.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint

+ +

CHAD: When you went on Shark Tank, how much of what you said and those kinds of things was all you, or how much is it put together for the show?

+ +

SARABETH: Really, the only thing that is heavily vetted by producers is your pitch. So when you walk into the tank, and you give your 30-second to 2-minute spiel that's a bit more theatrical, you practice that over and over and over again. And it was really a fascinating experience. Because as a fellow software engineer, you know we're kind of more chill people, [laughs] more realistic. But they kept saying, "Bring more energy to it. Do big movements, maybe even do a dance or something." [laughter] I'm kind of living this double life where I'm writing software, and then I'm --

+ +

CHAD: In between rehearsals, you're opening your laptop and making another thing happen on the app, I'm sure.

+ +

SARABETH: Exactly. It's like, oh, okay, we have pitch practice tonight, and now I'm going to work on this core feature. Without it, we literally don't have a product. So the producers are very involved in your initial pitch. But then when you jump into the Q&A, when the Sharks start asking you questions, that's all you.

+ +

CHAD: That's really cool. So are you happy that you went on Shark Tank?

+ +

SARABETH: Yes, I'm so happy that we went on. I've always been a Shark Tank fan. I think it's been on for over ten years. Shark Tank has been something that's kind of kept me interested in being an entrepreneur. When I started learning how to code, I knew that I always wanted to start a business. And just seeing the number of ideas and the variety of businesses that people are able to build and putting that on a show is just a fascinating concept. So I was really happy to go on the show. And, of course, the impact on our business has been tremendous.

+ +

Really, it changed the trajectory of our business. We gain most of our customers through organic search. So most of our customers come in through Google saying like, how do I get an online prenup? By getting on national television, we are really thankful that news stations were now interested in talking to us. So by linking to our website, that helped boost our search engine optimization rankings. And so now we're actually a profitable business due to Shark Tank.

+ +

CHAD: That's awesome. So is the tech team still just you?

+ +

SARABETH: The tech team is me. And I have started working with another Bubble developer on a contract basis. But calling out to any software engineers or low-code developers, if you're interested in joining a legal tech company that's growing a lot, feel free to reach out to me. So I really do need to be hiring another developer. At this point, I am really the main developer working on things for a variety of reasons.

+ +

The first reason is that Bubble, while it is very quick to develop a product on your own from a technical perspective, it is lacking in features when it comes to collaboration with other developers. So with traditional code, you'll do code reviews on GitHub, and you'll just do like a diff. But the branching and the version control is definitely a little bit lacking.

+ +

So I'm trying to wait out the Bubble team. They have some stuff coming down the pipeline that will make it easier to do collaboration. But for that reason, it is a little bit easier as an entrepreneur using a low-code platform to be the sole developer because you kind of know exactly how everything works.

+ +

And then also, developers are really expensive. So we are actually a completely self-funded company at this point. So we're bootstrapped. We haven't actually accepted any investment at this point. We're a really conservative team. If we hire a developer, we want to make sure that we're able to provide them with a competitive salary and competitive package. And we're able to do that now. It's just a matter of finding the right person, which is actually a really interesting space because low-code developers are still on the up and up right now.

+ +

CHAD: I know you can't see the future. But do you foresee a point where either Bubble doesn't take you where you want to go, or you need to start augmenting it in some way?

+ +

SARABETH: I would like to push Bubble as far as I can. I think now that Bubble is getting a lot more recognition...and they just got another round of funding that was pretty substantial. I think that they're going to be improving a lot of things, especially when it comes to, like I mentioned, collaborating with other developers on the platform and performance. A lot of pushback that people give with low-code platforms is like, oh, the page won't load as quickly as if I wrote it with pure React or something like that. So I want to try and stay on the platform as long as possible.

+ +

If we really continue to grow, I would be willing to move back to traditional code. And we'd actually be set up for success in that way because we would have a fully functioning product, and half of development is figuring out what feature to build next. So we'd kind of say, all right, here's how it works. And then, while we're kind of maintaining our Bubble application, we can have a development team build it within our own platform. Does that make sense?

+ +

CHAD: It does. And I think with Bubble, it doesn't need to be all or nothing, right?

+ +

SARABETH: Mm-hmm.

+ +

CHAD: You can use APIs. Or you can basically extend it with custom code if you really needed to using webhooks and that kind of thing, right?

+ +

SARABETH: Exactly. And that's the way that we've done it. So actually, the contract generation is written in Node.js JavaScript. And the reason I did that is because it's easier to process data in a sequential order with traditional code versus Bubble. And you can also hook into other APIs, like for us, we do a conversion of the HTML of the contract into a Word doc.

+ +

So we're able to call into a conversion API and then save it on AWS with traditional code, and you can do all that with Bubble. But it's a little bit more straightforward when you know what you're doing with just like JavaScript; you know a few lines here and there. Does that make sense?

+ +

CHAD: It does, yeah. I'll be super interested to see how far you're able to push it and what those things you need to do outside of Bubble are.

+ +

SARABETH: Yeah, I'm really excited to try to push Bubble as an option for entrepreneurs. We were actually the first low-code platform to be shown on Shark Tank. So every Bubble developer on Twitter was really excited about it.

+ +

CHAD: [laughs]

+ +

SARABETH: So I think it's a really interesting spot to be in right now.

+ +

CHAD: Yeah, from a technology perspective, I think that that's one thing we've talked about. And you addressed the other thing that sometimes people say is a promise. Like, it is a commercial platform. It's not an open-source platform, and you're building entirely on top of it. And so that presents a certain amount of risk that like, they might go out of business. You know, they're a VC-backed company, and maybe they'll go out of business. And then where would you be? The fact that they've just raised a significant additional round of funding mitigates that somewhat, but it's still a concern, right?

+ +

SARABETH: Yeah, it's definitely a concern. And it's something that, as a software engineer, it's terrifying to know that you're relying on someone else for your livelihood and now the livelihood of multiple people on our team. So it is really scary. You cannot export your code from Bubble. But I believe they have said that if for some reason they go out of business, they will allow you to do that.

+ +

I'm sure whatever code you export from it is not going to be very pretty to look at. So it probably makes sense to write it from scratch. But I think at this point, I'm really happy with where we're at. I like remaining a really lean team. And using different tools in simple ways and trying to keep our product as simple as possible has really helped us grow.

+ +

CHAD: What's next for HelloPrenup? Where are you setting your sights on? What's keeping you up at night now?

+ +

SARABETH: Ooh, so many things. We do have an exciting investor coming on. I can't say exactly who, but they were really involved in building one of the largest legal tech platforms out there today. So we're really excited to be partnering with them and be building out our network across all 50 states. Right now, we're actually in, I believe, 32 states. You can use our platform to create your prenuptial agreement. And so, we're excited to be starting to onboard attorneys to the platform. So that's one of the things.

+ +

Another thing that's on our radar is keeping up with, you know, it's hard to say the trends of what's going on with Web3. But we do have some things that are related to Web3 that we'll be tackling in the next probably a year or a couple of years when it comes to financial data. Yeah, so those things are kind of on our radar of our product.

+ +

And then, on the near term, we are doing a lot of work to try and normalize the entire conversation around prenuptial agreements. We partnered with The Knot, which is one of the largest online wedding registry websites. And we've been writing a lot of blogs on their website that talk about the educational side of prenups. And we're actually going to be launching gift cards.

+ +

CHAD: [chuckles]

+ +

SARABETH: So you can list a prenuptial agreement on your wedding registry, and people can help support it. So there are a lot of initiatives that we're going to be doing on the product development side and then also kind of on the marketing education side of the business. As we start to grow, I'm trying to pull my attention away from those things. But sometimes, it's really hard because some parts of the business that aren't technical are fun to get involved in. And I'm sure you run into that or when you were scaling thoughtbot getting distracted by other parts of the business because they were just interesting. But there's a lot going on right now.

+ +

CHAD: That's exciting. You mentioned earlier that you hadn't taken investors yet. And so is it about that scale that's causing you to take one on now, or what's going on there?

+ +

SARABETH: So we're profitable. We don't need an investor, which is we're so thankful for that. So it's really a strategic partnership for us.

+ +

CHAD: Well, that's really cool. I'm excited to hear everything you have going on. And I really wish you luck in everything that you're doing.

+ +

SARABETH: Thank you so much.

+ +

CHAD: So if folks want to find out more about HelloPrenup, follow along with you, get in touch with you; where are all the best places for them to do that?

+ +

SARABETH: You can check us out on helloprenup.com. And we're on Twitter, Instagram, LinkedIn. Just tweet at us @HelloPrenup, and one of us will respond. It'll probably be myself or Julia. So you're able to get into contact with us if you have any questions. And of course, if you are a developer who is looking to join a really fun, women-led legal tech company, hit me up.

+ +

CHAD: Awesome. You can subscribe to the show and find notes with links for everything that Sarabeth just mentioned, along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments for me, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thank you so much for joining me, Sarabeth. I really appreciate it.

+ +

SARABETH: Thank you so much.

+ +

CHAD: And thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Sarabeth Jaffe.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pflH9-jx + + ]]> + + Chad Pytel + Sarabeth Jaffe + + + 436: Welcoming our new co-host Victoria Guido + https://podcast.thoughtbot.com/436 + 968bcac1-7fee-4d38-9e17-a97bd29998a9 + Thu, 18 Aug 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Victoria Guido is the new Associate Director of Business Development and DevOps Strategy at thoughtbot, and is joining Chad as co-host of the show! + +Chad talks with Victoria about getting involved in DevOps work, transitioning to agile, moving away from her old community which was based on geography, and tips for people onboarding into a new role. + 24:58 + no + + + Victoria Guido is the new Associate Director of Business Development and DevOps Strategy at thoughtbot, and is joining Chad as co-host of the show! +Chad talks with Victoria about getting involved in DevOps work, transitioning to agile, moving away from her old community which was based on geography, and tips for people onboarding into a new role. +Follow Victoria on Twitter (https://twitter.com/victori_ousg) or LinkedIn (https://www.linkedin.com/in/victorialguido/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Victoria Guido, the new Associate Director of Business Development and DevOps Strategy at thoughtbot, and wait for it, the new co-host of this very podcast with me. Victoria, thank you for joining me on the show for this episode, for joining me at thoughtbot, and now for joining me as the co-host of the show. +VICTORIA: You're welcome. Thank you for having me. +CHAD: You do all of those things, right? [laughs] +VICTORIA: Yes, yes. +CHAD: So I'm hoping that we can introduce folks to you. I'm excited to have you on the show and for the audience to get to know you. Let's start with your role at thoughtbot. I think maybe you have the esteem of having the longest title at thoughtbot right now. [chuckles] +VICTORIA: Yes, I love it, Associate Director of Business Development and DevOps Strategy. So I'm not only doing business development but also planning our DevOps services and how we do that at thoughtbot. +CHAD: And you're on the Mission Control team, which for folks who follow along or want to go back and listen, we had Joe, who is the CTO of thoughtbot and the interim Managing Director of the Mission Control team, which is our new DevOps team and Site Reliability Engineering team, that's Episode 403. So I will link that in the show notes, but it's at giantrobots.fm/403 as well. So, how did you get involved in DevOps work? +VICTORIA: Right. So I first went to my first DevOps meetup in 2017 when I was living in Washington, D.C. I had been working in IT and operations for about 5 or 10 years at that point. And I went to a DevOps meetup and met some really nice guys, and they were very...what I liked about it was that it was both the technology side and about culture. +And it was about how do we break down silos between different groups, and then bring in the automation and start to do next level type of operations? So that's how I started to get involved. And I started attending the meetups regularly and then became an organizer for the meetup and for the conference series. And that's when I became like the biggest DevOps person in D.C. probably. [laughs] +CHAD: Did you end up moving from the general IT work that you were doing into more DevOps focus work along that way? +VICTORIA: Yeah, at that time, that was when as a federal contractor, you know, agile had been around for quite a while. And I had been through several agile transformations with large program teams. And now DevOps was becoming more of a thing. And the project that I was on at the time was managing a large set of federal websites and was managing the build pipeline and process for how they got their code into the public's view and how they managed the servers and all the other back-end services that supported those applications. +So DevOps was both top of mind for the government. [laughs] They were trying to now be able to deploy as frequently as they were able to build new features. And it was part of the work that I was performing as well. +CHAD: You mentioned you were doing government work at the time. What was that like? What kind of work was it? +VICTORIA: Yeah, actually, my first job after college, my first full-time job, was at Citizenship and Immigration Services. And it was about a 200-person program. Some of the applications were actually written in Siebel. And so we had just a variety of different applications from Siebel to Java. And they had just transitioned to agile. And so that was taking a team that was managing Oracle releases and bringing them into a kanban style workflow and figuring out how do we be agile when we're in maintenance mode, and bring the team along with me? +And I worked my way up from a process engineer to project management and did a little bit of testing and a little bit of development in between. So it was interesting because it was a major transformational shift for that agency and still getting steeped in ITIL processes and how to do unit testing, acceptance testing, and all of those other kinds of critical processes for building applications. It was good. +CHAD: What does transitioning to agile mean when you talk about groups that size? You're talking about unit tests and that kind of thing, which can be part of agile, but I assume isn't the only aspect of it. +VICTORIA: Yeah, I think for that group, it was about changing the way we planned and managed work and figuring out what processes could we automate. So is there testing that we could automate or test data creation we could automate? And I think there are some concepts from agile that helped our planning, for example, making a physical board to manage which environments has which versions of Oracle in it. +Those types of concepts of just kind of stepping away from your computer and getting together with the group every day to talk about what issues they're running into that's kind of what it was. But there was still, of course, documentation requirements, big documentation requirements, and everything like that. So it was an interesting sort of half transition or tailored approach to doing agile with that type of team. +CHAD: And then from there, you moved into ongoing sort of consulting companies that worked with government. +VICTORIA: Yes, I worked for two pseudo-government financial organizations, Pension Benefit Guaranty Corporation and Fannie Mae, so my next two roles as a project manager and system engineer. So at Pension Benefit Guaranty Corporation, I got exposed to more system engineering and security engineering, working with their mobile device management policy, and actually designing the mobile device management to match DISA STIG. Sorry, I'm doing a lot of acronyms out here. [laughter] You can stop me if I use too many. +But that was really interesting and also upgrading their system, they were using to manage change for the organization so their ITIL services management tool. Going through the process of upgrading that project and coordinating across all the teams who delivered software at the agency was fascinating. +I went on to Fannie Mae, where I started to really build knowledge bases and start to build out actually using SharePoint at the time. [laughs] But figuring out ways to share knowledge across large teams and other large production support services teams, and how to get them collaborating so they could improve themselves and do continuous improvement, and learn what other groups are doing. +CHAD: That's one area where I honestly don't have a ton of experience. Most of my professional experience has been at thoughtbot or other smaller organizations. How do you manage that, or what are the big differences between large organizations like that and something at the thoughtbot size or smaller? +VICTORIA: The biggest difference between a large organization like that and a small one like thoughtbot would be I think of how change gets generated and started. In a small organization with a culture like thoughtbot, change can come from anywhere and very quickly have permeated the entire organization. With a larger organization, you can have leaders try to force change from the top down. +And you'll see individuals some will be 100% on board. Others will figure out how to qualify what they're already doing to fit that change. And some others will just be full-on resistance and just kind of be waiting for the next leader to come in so they can switch into whatever they were doing before. +And there is also that organic change that comes from individuals and then pushes up to the rest of the organization. But I think it's much harder, and you have to have a lot of will and a lot of support from leadership that they're accepting of those types of ideas. +CHAD: I think it's the nature of groups and companies to want to grow. Do you think that there's any way to preserve that smaller culture as an organization grows? +VICTORIA: I think so. I think it's possible if you integrate it into part of your core values, and that becomes a part of how you interview, and how you do performance reviews, and how you build your culture as a company. I think you can build it on those tenets. +I think in some organizations, there's usually some form of acquisition where you acquired a team from a contracting company, or you acquired a team of federal employees from another agency when you restructured. So it makes it a little bit more challenging to really integrate that part of your culture into every step, but it is possible. And you also have to accept that not everyone might be on board all the time. +CHAD: Well, I think that that is probably the biggest challenge is even in a larger organization, if you foster a culture where change can happen from anywhere, it's not necessarily top down. Transferring that knowledge or that practice throughout the whole organization is really difficult. Like if it's thousands or tens of thousands of people, adopting a change seems really difficult to me. So even if things are really organic coming from all levels of the company, you could end up in a scenario where everything is being done differently, everywhere. +VICTORIA: Yeah, and I think, too, when you're in a larger organization, there's more context for every unit. And so you can think this is a change we're going to do. This is going to be great. But then, once you actually see the way that people work, that change might not actually help them that much. And so I think that if people have autonomy to be able to make changes that make sense for them, that's more likely to be effective than if we tried to push change from the top down necessarily. And being in my position as a contractor, I really don't have authority to make a lot of changes. +CHAD: [chuckles] Right. +VICTORIA: So either I have someone backing me up, or I really get to know the individuals that I'm working with. And I can demonstrate and show them that there's a better way of doing it and do it in a way that gives it to them as an option so they can choose to adopt it. And that's usually the only option I have to give anyway, [laughs] so that's been effective because people do want to be better at their jobs or be more efficient. But a lot of times, I think the changes aren't really addressing their problem, and so it can be easy to push it aside. +Mid-Roll Ad: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs +CHAD: So you mentioned you got involved in DevOps DC and then as an organizer. I know you also started to work with Women Who Code. Why did you get involved in the organization of DevOps DC and that kind of thing? Was there a business or a personal reason to do it? +VICTORIA: It was both. It made sense from a networking perspective, both in potential customers or clients and in recruiting. But also, I think it made sense. For me personally, the people who were showing up regularly were my kind of people, you know, [laughs] people who cared about blameless post mortems or feeling open or making me feel welcome when I came to the meetup. That was a big reason why I got involved. And it just made sense for me, too, because I was coming from an operations background. I'm like, oh, DevOps, this is the way that we're supposed to be doing things. [laughs] +CHAD: So you were really involved in the D.C. community and had been there for a while. But you recently moved to California. +VICTORIA: Yes, yeah. I've been in San Diego for almost two years, about a year and a half at this point. Yeah, big moves. +CHAD: What was it like to move away from your old community, which was so based on geography? +VICTORIA: Yeah, it was sad, but it was interesting how it worked out with the pandemic because when we found out we were going to move, was when everything shut down, and we went slowly remote anyways. And so I continued running DevOps DC remotely and some Women Who Code events for about a year afterwards. +And then, when I decided it was time to really shift away and actually be more present in the San Diego community, especially when the other meetups started going back to in-person meetups, that was actually really hard to say goodbye and to say that I wasn't going to be organizing anymore. And I really miss all my past organizers and people who would come to the events. +CHAD: Has it been difficult to form a new community locally given the pandemic? +VICTORIA: Yeah, I've looked at quite a few meetups. There are a number of good meetups here in San Diego, and LA has a great scene as well. But yeah, it's been hard for myself to just get out of the house and to find similar groups that have those same interests. That's been a challenge, but I think it's coming along, and we'll get there. +CHAD: And along the way, you joined thoughtbot. I'm curious, what were the things, in particular, that attracted you to the role or to thoughtbot? What were you looking for personally? +VICTORIA: Personally, I knew that business development was an area that fit my skill sets really well, and the things I like to do like going out, and networking, and talking to people. And this role, in particular with the DevOps strategy in there, really excited me because I could use all of these hours and hours I've spent in meetups and conferences to good use to help develop services within thoughtbot that are really tailored to our specific user groups and needs. And to work with highly skilled, highly regarded engineers and developers on developing these products I thought was really exciting. +And then thoughtbot as a company, in particular, I found the interview process to be really well thought out with, for example, I knew that it was going to be a long interview process. So there is a compensation that you can receive just for interviewing. And I thought that was something that was really nice [laughs] and also just showed that approach of being aware of the candidate's experience and wanting to have that be a good experience and a worthwhile endeavor. So that was part of why I liked thoughtbot. +Open source was a big consideration for me. I wanted to work somewhere where they were passionate about giving back to the open-source community, and all that together brought me here and made the most sense. +CHAD: Cool. Do you have any tips for people onboarding into a new role? Or maybe even if it's not tips, was there something that you did intentionally when day one or day minus one you're thinking about, okay, tomorrow I'm getting started? How did you approach that? +VICTORIA: One of the biggest advice I give to people who are starting a new role is to schedule one on ones with members of your team and get to know them as individuals, especially in remote environment since you don't necessarily have a chance to go out for coffee, [chuckles] just to have a quick one on one and get to know them a little bit more in your role and figure out where you can start to add value. I think that's a great way to start. And then to just develop your list of ideas for where you think you can add value, some outstanding questions for where you need to understand more. +And I think the other advice would be to engage in the social channels. I think my first day, I posted a picture of my dog on the dogs' channel. [laughter] And just like, let your personality show a little bit. And don't be afraid to post in a large channel, especially if you know the culture of the company is open to that kind of collaboration. And then people start to see your face and get to know you a little bit more, and you feel more connected to your company. +CHAD: Were you nervous when you joined on your first day? +VICTORIA: Yeah, a little nervous. And I'm also aware of just having been a federal contractor that some people might hear that and have an impression of my style or the way I like to work. And so I'm a little aware of like, oh, I definitely don't want to wear a blazer. I don't want to look too corporate. +[laughter] +CHAD: That's funny. Yeah, one time, we were meeting in sales meetings with clients, and we wanted to establish that we were not a typical consulting company. And so intentionally going to a sales meeting wearing a t-shirt or something like that was a statement, like an intentional choice we were making to subtly communicate what kind of company we are. So that resonates with me. +VICTORIA: Right. [laughs] +CHAD: So now that you've been here for...oh, geez, how long has it been? [chuckles] +VICTORIA: It's almost a month. +CHAD: Almost a month. Was there anything that surprised you? +VICTORIA: There have been a few small things that I'm probably way too happy about. One is just the actual page count in contracts is just way lower than what I've had to work with in the past, [laughter] which is very exciting for me. I was really happy to see...I went to go add a custom Slack emoji, and there were already like 2,000-plus Slack emojis. So that was really exciting for me. [laughs] +Surprising...the part that's interesting is, in some cases, as a consulting company, it is the same problems that we're trying to solve for. So, in that case, it's almost expected, but it's interesting. So to see some things like what thoughtbot has, a playbook in GitHub, and anyone can edit it. And that was something I was really trying to work on at my last position. +And you're 5 or 10 years down the road where you've solved some of the issues where you have a nice editor so that people can go in and edit pages without using Markdown or pull requests. But it's still difficult. So it's interesting to see that some challenges have progressed a little and have still some different issues. +CHAD: Yeah, it's always interesting to get a new person's perspective with fresh eyes. I've been doing this for a long time, and joining a new company remotely is different. Back when you were joining a Boston team or a San Francisco team, you could go into the office. And your first day, you'd be sitting right next to somebody and going to lunch with them. And that kind of thing is clearly very different now than it was then. +VICTORIA: Right. And I did get to see everyone at Summit for one night. So that's exciting. +CHAD: Yeah, that was exciting. So we happened to...I think the week before you started, or maybe two weeks before you started, we were having our company-wide in-person get-together in the United Kingdom. And you happened to be going to Germany for a wedding, right? +VICTORIA: Mm-hmm. +CHAD: So we tacked on to that trip and stole you for a day, and we were able to see each other in person. That was exciting. +VICTORIA: It was really cool. Although I had a lot of FOMO once, I saw the next day was like D&D and a bunch of games and hanging out. I was like, wow, I'd really like to stay longer. [laughs] +CHAD: Yeah, yeah. Well, we'll do it again next year. [laughs] +VICTORIA: Yeah, that's true. +CHAD: Mission control is the one team at thoughtbot that works on clients that is cross time zone, so most of the teams overlap with clients 100% with time zone. So it'll be people in the Americas work with clients in the Americas. But the Mission Control so that we could provide a wide swath of time zone coverage for that infrastructure work, for that support that we do, crosses the teams. So one person on your team is in Nigeria, and you're all the way in San Diego. What's that like? How do you manage that? +VICTORIA: Yes, well, everyone on the team makes sure to update their availability in their calendars so that we aren't accidentally scheduling meetings really late in the day for folks who are on that UK time zone. It's been all right, though. I'm used to asynchronous communication, and so is the team. So I think that we're really good at being able to use Jira and Confluence and Slack to communicate. And we are open with each other on where we're flexible if we need to make meetings a little bit later. +And everyone's been really supportive of not trying to have meetings too early with me, which I appreciate, [laughter] 8:00 o'clock is totally fine, though. It's actually been good. I'm used to the asynchronous communication. I actually would even be open to more meetings that are done just over Slack and just when people wake up. +CHAD: I think there are different philosophies here. But I'm very much in the camp of assuming we want to work a sustainable pace, which we do, then you can't build a culture around synchronous meetings where everyone needs to be on the meeting together because it's basically impossible. Those two things are at odds. Someone will be outside of their regular work hours, and that's really hard to continue on sustainably. +So I'm very much in the camp of having a culture of asynchronous communication. And that doesn't mean that you never talk. [laughs] It doesn't mean that you don't work with each other. But maybe those times should be focused on what can't be replicated asynchronously, which is sometimes the social connections, the cultural connections of the team. +VICTORIA: Yeah, and I think we get a kick out of saying like, "Good morning, Victoria, and good evening, Olamide." [laughs] +CHAD: Cool. Well, I'm sure folks will get to know you more over the course of the next episodes. I really appreciate you joining the show. If folks want to follow along with you or get in touch with you, where are the best places for them to do that? +VICTORIA: I'm more active on Twitter, and so you can follow me there. And I tend to like and retweet a bunch of DevOps-related events and Women Who Code events. And I'm also on LinkedIn. +CHAD: So what's that Twitter handle? +VICTORIA: It's @victori_ousg. +CHAD: Okay. We'll include a link to that in the show notes. You can subscribe to the show and find notes along with an entire transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And I'm so excited it's not just going to be me on that email list anymore. So definitely send an email. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening. +Victoria, thank you again. +VICTORIA: Thank you +CHAD: And see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Victoria Guido is the new Associate Director of Business Development and DevOps Strategy at thoughtbot, and is joining Chad as co-host of the show!

+ +

Chad talks with Victoria about getting involved in DevOps work, transitioning to agile, moving away from her old community which was based on geography, and tips for people onboarding into a new role.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Victoria Guido, the new Associate Director of Business Development and DevOps Strategy at thoughtbot, and wait for it, the new co-host of this very podcast with me. Victoria, thank you for joining me on the show for this episode, for joining me at thoughtbot, and now for joining me as the co-host of the show.

+ +

VICTORIA: You're welcome. Thank you for having me.

+ +

CHAD: You do all of those things, right? [laughs]

+ +

VICTORIA: Yes, yes.

+ +

CHAD: So I'm hoping that we can introduce folks to you. I'm excited to have you on the show and for the audience to get to know you. Let's start with your role at thoughtbot. I think maybe you have the esteem of having the longest title at thoughtbot right now. [chuckles]

+ +

VICTORIA: Yes, I love it, Associate Director of Business Development and DevOps Strategy. So I'm not only doing business development but also planning our DevOps services and how we do that at thoughtbot.

+ +

CHAD: And you're on the Mission Control team, which for folks who follow along or want to go back and listen, we had Joe, who is the CTO of thoughtbot and the interim Managing Director of the Mission Control team, which is our new DevOps team and Site Reliability Engineering team, that's Episode 403. So I will link that in the show notes, but it's at giantrobots.fm/403 as well. So, how did you get involved in DevOps work?

+ +

VICTORIA: Right. So I first went to my first DevOps meetup in 2017 when I was living in Washington, D.C. I had been working in IT and operations for about 5 or 10 years at that point. And I went to a DevOps meetup and met some really nice guys, and they were very...what I liked about it was that it was both the technology side and about culture.

+ +

And it was about how do we break down silos between different groups, and then bring in the automation and start to do next level type of operations? So that's how I started to get involved. And I started attending the meetups regularly and then became an organizer for the meetup and for the conference series. And that's when I became like the biggest DevOps person in D.C. probably. [laughs]

+ +

CHAD: Did you end up moving from the general IT work that you were doing into more DevOps focus work along that way?

+ +

VICTORIA: Yeah, at that time, that was when as a federal contractor, you know, agile had been around for quite a while. And I had been through several agile transformations with large program teams. And now DevOps was becoming more of a thing. And the project that I was on at the time was managing a large set of federal websites and was managing the build pipeline and process for how they got their code into the public's view and how they managed the servers and all the other back-end services that supported those applications.

+ +

So DevOps was both top of mind for the government. [laughs] They were trying to now be able to deploy as frequently as they were able to build new features. And it was part of the work that I was performing as well.

+ +

CHAD: You mentioned you were doing government work at the time. What was that like? What kind of work was it?

+ +

VICTORIA: Yeah, actually, my first job after college, my first full-time job, was at Citizenship and Immigration Services. And it was about a 200-person program. Some of the applications were actually written in Siebel. And so we had just a variety of different applications from Siebel to Java. And they had just transitioned to agile. And so that was taking a team that was managing Oracle releases and bringing them into a kanban style workflow and figuring out how do we be agile when we're in maintenance mode, and bring the team along with me?

+ +

And I worked my way up from a process engineer to project management and did a little bit of testing and a little bit of development in between. So it was interesting because it was a major transformational shift for that agency and still getting steeped in ITIL processes and how to do unit testing, acceptance testing, and all of those other kinds of critical processes for building applications. It was good.

+ +

CHAD: What does transitioning to agile mean when you talk about groups that size? You're talking about unit tests and that kind of thing, which can be part of agile, but I assume isn't the only aspect of it.

+ +

VICTORIA: Yeah, I think for that group, it was about changing the way we planned and managed work and figuring out what processes could we automate. So is there testing that we could automate or test data creation we could automate? And I think there are some concepts from agile that helped our planning, for example, making a physical board to manage which environments has which versions of Oracle in it.

+ +

Those types of concepts of just kind of stepping away from your computer and getting together with the group every day to talk about what issues they're running into that's kind of what it was. But there was still, of course, documentation requirements, big documentation requirements, and everything like that. So it was an interesting sort of half transition or tailored approach to doing agile with that type of team.

+ +

CHAD: And then from there, you moved into ongoing sort of consulting companies that worked with government.

+ +

VICTORIA: Yes, I worked for two pseudo-government financial organizations, Pension Benefit Guaranty Corporation and Fannie Mae, so my next two roles as a project manager and system engineer. So at Pension Benefit Guaranty Corporation, I got exposed to more system engineering and security engineering, working with their mobile device management policy, and actually designing the mobile device management to match DISA STIG. Sorry, I'm doing a lot of acronyms out here. [laughter] You can stop me if I use too many.

+ +

But that was really interesting and also upgrading their system, they were using to manage change for the organization so their ITIL services management tool. Going through the process of upgrading that project and coordinating across all the teams who delivered software at the agency was fascinating.

+ +

I went on to Fannie Mae, where I started to really build knowledge bases and start to build out actually using SharePoint at the time. [laughs] But figuring out ways to share knowledge across large teams and other large production support services teams, and how to get them collaborating so they could improve themselves and do continuous improvement, and learn what other groups are doing.

+ +

CHAD: That's one area where I honestly don't have a ton of experience. Most of my professional experience has been at thoughtbot or other smaller organizations. How do you manage that, or what are the big differences between large organizations like that and something at the thoughtbot size or smaller?

+ +

VICTORIA: The biggest difference between a large organization like that and a small one like thoughtbot would be I think of how change gets generated and started. In a small organization with a culture like thoughtbot, change can come from anywhere and very quickly have permeated the entire organization. With a larger organization, you can have leaders try to force change from the top down.

+ +

And you'll see individuals some will be 100% on board. Others will figure out how to qualify what they're already doing to fit that change. And some others will just be full-on resistance and just kind of be waiting for the next leader to come in so they can switch into whatever they were doing before.

+ +

And there is also that organic change that comes from individuals and then pushes up to the rest of the organization. But I think it's much harder, and you have to have a lot of will and a lot of support from leadership that they're accepting of those types of ideas.

+ +

CHAD: I think it's the nature of groups and companies to want to grow. Do you think that there's any way to preserve that smaller culture as an organization grows?

+ +

VICTORIA: I think so. I think it's possible if you integrate it into part of your core values, and that becomes a part of how you interview, and how you do performance reviews, and how you build your culture as a company. I think you can build it on those tenets.

+ +

I think in some organizations, there's usually some form of acquisition where you acquired a team from a contracting company, or you acquired a team of federal employees from another agency when you restructured. So it makes it a little bit more challenging to really integrate that part of your culture into every step, but it is possible. And you also have to accept that not everyone might be on board all the time.

+ +

CHAD: Well, I think that that is probably the biggest challenge is even in a larger organization, if you foster a culture where change can happen from anywhere, it's not necessarily top down. Transferring that knowledge or that practice throughout the whole organization is really difficult. Like if it's thousands or tens of thousands of people, adopting a change seems really difficult to me. So even if things are really organic coming from all levels of the company, you could end up in a scenario where everything is being done differently, everywhere.

+ +

VICTORIA: Yeah, and I think, too, when you're in a larger organization, there's more context for every unit. And so you can think this is a change we're going to do. This is going to be great. But then, once you actually see the way that people work, that change might not actually help them that much. And so I think that if people have autonomy to be able to make changes that make sense for them, that's more likely to be effective than if we tried to push change from the top down necessarily. And being in my position as a contractor, I really don't have authority to make a lot of changes.

+ +

CHAD: [chuckles] Right.

+ +

VICTORIA: So either I have someone backing me up, or I really get to know the individuals that I'm working with. And I can demonstrate and show them that there's a better way of doing it and do it in a way that gives it to them as an option so they can choose to adopt it. And that's usually the only option I have to give anyway, [laughs] so that's been effective because people do want to be better at their jobs or be more efficient. But a lot of times, I think the changes aren't really addressing their problem, and so it can be easy to push it aside.

+ +

Mid-Roll Ad:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs

+ +

CHAD: So you mentioned you got involved in DevOps DC and then as an organizer. I know you also started to work with Women Who Code. Why did you get involved in the organization of DevOps DC and that kind of thing? Was there a business or a personal reason to do it?

+ +

VICTORIA: It was both. It made sense from a networking perspective, both in potential customers or clients and in recruiting. But also, I think it made sense. For me personally, the people who were showing up regularly were my kind of people, you know, [laughs] people who cared about blameless post mortems or feeling open or making me feel welcome when I came to the meetup. That was a big reason why I got involved. And it just made sense for me, too, because I was coming from an operations background. I'm like, oh, DevOps, this is the way that we're supposed to be doing things. [laughs]

+ +

CHAD: So you were really involved in the D.C. community and had been there for a while. But you recently moved to California.

+ +

VICTORIA: Yes, yeah. I've been in San Diego for almost two years, about a year and a half at this point. Yeah, big moves.

+ +

CHAD: What was it like to move away from your old community, which was so based on geography?

+ +

VICTORIA: Yeah, it was sad, but it was interesting how it worked out with the pandemic because when we found out we were going to move, was when everything shut down, and we went slowly remote anyways. And so I continued running DevOps DC remotely and some Women Who Code events for about a year afterwards.

+ +

And then, when I decided it was time to really shift away and actually be more present in the San Diego community, especially when the other meetups started going back to in-person meetups, that was actually really hard to say goodbye and to say that I wasn't going to be organizing anymore. And I really miss all my past organizers and people who would come to the events.

+ +

CHAD: Has it been difficult to form a new community locally given the pandemic?

+ +

VICTORIA: Yeah, I've looked at quite a few meetups. There are a number of good meetups here in San Diego, and LA has a great scene as well. But yeah, it's been hard for myself to just get out of the house and to find similar groups that have those same interests. That's been a challenge, but I think it's coming along, and we'll get there.

+ +

CHAD: And along the way, you joined thoughtbot. I'm curious, what were the things, in particular, that attracted you to the role or to thoughtbot? What were you looking for personally?

+ +

VICTORIA: Personally, I knew that business development was an area that fit my skill sets really well, and the things I like to do like going out, and networking, and talking to people. And this role, in particular with the DevOps strategy in there, really excited me because I could use all of these hours and hours I've spent in meetups and conferences to good use to help develop services within thoughtbot that are really tailored to our specific user groups and needs. And to work with highly skilled, highly regarded engineers and developers on developing these products I thought was really exciting.

+ +

And then thoughtbot as a company, in particular, I found the interview process to be really well thought out with, for example, I knew that it was going to be a long interview process. So there is a compensation that you can receive just for interviewing. And I thought that was something that was really nice [laughs] and also just showed that approach of being aware of the candidate's experience and wanting to have that be a good experience and a worthwhile endeavor. So that was part of why I liked thoughtbot.

+ +

Open source was a big consideration for me. I wanted to work somewhere where they were passionate about giving back to the open-source community, and all that together brought me here and made the most sense.

+ +

CHAD: Cool. Do you have any tips for people onboarding into a new role? Or maybe even if it's not tips, was there something that you did intentionally when day one or day minus one you're thinking about, okay, tomorrow I'm getting started? How did you approach that?

+ +

VICTORIA: One of the biggest advice I give to people who are starting a new role is to schedule one on ones with members of your team and get to know them as individuals, especially in remote environment since you don't necessarily have a chance to go out for coffee, [chuckles] just to have a quick one on one and get to know them a little bit more in your role and figure out where you can start to add value. I think that's a great way to start. And then to just develop your list of ideas for where you think you can add value, some outstanding questions for where you need to understand more.

+ +

And I think the other advice would be to engage in the social channels. I think my first day, I posted a picture of my dog on the dogs' channel. [laughter] And just like, let your personality show a little bit. And don't be afraid to post in a large channel, especially if you know the culture of the company is open to that kind of collaboration. And then people start to see your face and get to know you a little bit more, and you feel more connected to your company.

+ +

CHAD: Were you nervous when you joined on your first day?

+ +

VICTORIA: Yeah, a little nervous. And I'm also aware of just having been a federal contractor that some people might hear that and have an impression of my style or the way I like to work. And so I'm a little aware of like, oh, I definitely don't want to wear a blazer. I don't want to look too corporate.

+ +

[laughter]

+ +

CHAD: That's funny. Yeah, one time, we were meeting in sales meetings with clients, and we wanted to establish that we were not a typical consulting company. And so intentionally going to a sales meeting wearing a t-shirt or something like that was a statement, like an intentional choice we were making to subtly communicate what kind of company we are. So that resonates with me.

+ +

VICTORIA: Right. [laughs]

+ +

CHAD: So now that you've been here for...oh, geez, how long has it been? [chuckles]

+ +

VICTORIA: It's almost a month.

+ +

CHAD: Almost a month. Was there anything that surprised you?

+ +

VICTORIA: There have been a few small things that I'm probably way too happy about. One is just the actual page count in contracts is just way lower than what I've had to work with in the past, [laughter] which is very exciting for me. I was really happy to see...I went to go add a custom Slack emoji, and there were already like 2,000-plus Slack emojis. So that was really exciting for me. [laughs]

+ +

Surprising...the part that's interesting is, in some cases, as a consulting company, it is the same problems that we're trying to solve for. So, in that case, it's almost expected, but it's interesting. So to see some things like what thoughtbot has, a playbook in GitHub, and anyone can edit it. And that was something I was really trying to work on at my last position.

+ +

And you're 5 or 10 years down the road where you've solved some of the issues where you have a nice editor so that people can go in and edit pages without using Markdown or pull requests. But it's still difficult. So it's interesting to see that some challenges have progressed a little and have still some different issues.

+ +

CHAD: Yeah, it's always interesting to get a new person's perspective with fresh eyes. I've been doing this for a long time, and joining a new company remotely is different. Back when you were joining a Boston team or a San Francisco team, you could go into the office. And your first day, you'd be sitting right next to somebody and going to lunch with them. And that kind of thing is clearly very different now than it was then.

+ +

VICTORIA: Right. And I did get to see everyone at Summit for one night. So that's exciting.

+ +

CHAD: Yeah, that was exciting. So we happened to...I think the week before you started, or maybe two weeks before you started, we were having our company-wide in-person get-together in the United Kingdom. And you happened to be going to Germany for a wedding, right?

+ +

VICTORIA: Mm-hmm.

+ +

CHAD: So we tacked on to that trip and stole you for a day, and we were able to see each other in person. That was exciting.

+ +

VICTORIA: It was really cool. Although I had a lot of FOMO once, I saw the next day was like D&D and a bunch of games and hanging out. I was like, wow, I'd really like to stay longer. [laughs]

+ +

CHAD: Yeah, yeah. Well, we'll do it again next year. [laughs]

+ +

VICTORIA: Yeah, that's true.

+ +

CHAD: Mission control is the one team at thoughtbot that works on clients that is cross time zone, so most of the teams overlap with clients 100% with time zone. So it'll be people in the Americas work with clients in the Americas. But the Mission Control so that we could provide a wide swath of time zone coverage for that infrastructure work, for that support that we do, crosses the teams. So one person on your team is in Nigeria, and you're all the way in San Diego. What's that like? How do you manage that?

+ +

VICTORIA: Yes, well, everyone on the team makes sure to update their availability in their calendars so that we aren't accidentally scheduling meetings really late in the day for folks who are on that UK time zone. It's been all right, though. I'm used to asynchronous communication, and so is the team. So I think that we're really good at being able to use Jira and Confluence and Slack to communicate. And we are open with each other on where we're flexible if we need to make meetings a little bit later.

+ +

And everyone's been really supportive of not trying to have meetings too early with me, which I appreciate, [laughter] 8:00 o'clock is totally fine, though. It's actually been good. I'm used to the asynchronous communication. I actually would even be open to more meetings that are done just over Slack and just when people wake up.

+ +

CHAD: I think there are different philosophies here. But I'm very much in the camp of assuming we want to work a sustainable pace, which we do, then you can't build a culture around synchronous meetings where everyone needs to be on the meeting together because it's basically impossible. Those two things are at odds. Someone will be outside of their regular work hours, and that's really hard to continue on sustainably.

+ +

So I'm very much in the camp of having a culture of asynchronous communication. And that doesn't mean that you never talk. [laughs] It doesn't mean that you don't work with each other. But maybe those times should be focused on what can't be replicated asynchronously, which is sometimes the social connections, the cultural connections of the team.

+ +

VICTORIA: Yeah, and I think we get a kick out of saying like, "Good morning, Victoria, and good evening, Olamide." [laughs]

+ +

CHAD: Cool. Well, I'm sure folks will get to know you more over the course of the next episodes. I really appreciate you joining the show. If folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

VICTORIA: I'm more active on Twitter, and so you can follow me there. And I tend to like and retweet a bunch of DevOps-related events and Women Who Code events. And I'm also on LinkedIn.

+ +

CHAD: So what's that Twitter handle?

+ +

VICTORIA: It's @victori_ousg.

+ +

CHAD: Okay. We'll include a link to that in the show notes. You can subscribe to the show and find notes along with an entire transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And I'm so excited it's not just going to be me on that email list anymore. So definitely send an email. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening.

+ +

Victoria, thank you again.

+ +

VICTORIA: Thank you

+ +

CHAD: And see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Victoria Guido is the new Associate Director of Business Development and DevOps Strategy at thoughtbot, and is joining Chad as co-host of the show!

+ +

Chad talks with Victoria about getting involved in DevOps work, transitioning to agile, moving away from her old community which was based on geography, and tips for people onboarding into a new role.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Victoria Guido, the new Associate Director of Business Development and DevOps Strategy at thoughtbot, and wait for it, the new co-host of this very podcast with me. Victoria, thank you for joining me on the show for this episode, for joining me at thoughtbot, and now for joining me as the co-host of the show.

+ +

VICTORIA: You're welcome. Thank you for having me.

+ +

CHAD: You do all of those things, right? [laughs]

+ +

VICTORIA: Yes, yes.

+ +

CHAD: So I'm hoping that we can introduce folks to you. I'm excited to have you on the show and for the audience to get to know you. Let's start with your role at thoughtbot. I think maybe you have the esteem of having the longest title at thoughtbot right now. [chuckles]

+ +

VICTORIA: Yes, I love it, Associate Director of Business Development and DevOps Strategy. So I'm not only doing business development but also planning our DevOps services and how we do that at thoughtbot.

+ +

CHAD: And you're on the Mission Control team, which for folks who follow along or want to go back and listen, we had Joe, who is the CTO of thoughtbot and the interim Managing Director of the Mission Control team, which is our new DevOps team and Site Reliability Engineering team, that's Episode 403. So I will link that in the show notes, but it's at giantrobots.fm/403 as well. So, how did you get involved in DevOps work?

+ +

VICTORIA: Right. So I first went to my first DevOps meetup in 2017 when I was living in Washington, D.C. I had been working in IT and operations for about 5 or 10 years at that point. And I went to a DevOps meetup and met some really nice guys, and they were very...what I liked about it was that it was both the technology side and about culture.

+ +

And it was about how do we break down silos between different groups, and then bring in the automation and start to do next level type of operations? So that's how I started to get involved. And I started attending the meetups regularly and then became an organizer for the meetup and for the conference series. And that's when I became like the biggest DevOps person in D.C. probably. [laughs]

+ +

CHAD: Did you end up moving from the general IT work that you were doing into more DevOps focus work along that way?

+ +

VICTORIA: Yeah, at that time, that was when as a federal contractor, you know, agile had been around for quite a while. And I had been through several agile transformations with large program teams. And now DevOps was becoming more of a thing. And the project that I was on at the time was managing a large set of federal websites and was managing the build pipeline and process for how they got their code into the public's view and how they managed the servers and all the other back-end services that supported those applications.

+ +

So DevOps was both top of mind for the government. [laughs] They were trying to now be able to deploy as frequently as they were able to build new features. And it was part of the work that I was performing as well.

+ +

CHAD: You mentioned you were doing government work at the time. What was that like? What kind of work was it?

+ +

VICTORIA: Yeah, actually, my first job after college, my first full-time job, was at Citizenship and Immigration Services. And it was about a 200-person program. Some of the applications were actually written in Siebel. And so we had just a variety of different applications from Siebel to Java. And they had just transitioned to agile. And so that was taking a team that was managing Oracle releases and bringing them into a kanban style workflow and figuring out how do we be agile when we're in maintenance mode, and bring the team along with me?

+ +

And I worked my way up from a process engineer to project management and did a little bit of testing and a little bit of development in between. So it was interesting because it was a major transformational shift for that agency and still getting steeped in ITIL processes and how to do unit testing, acceptance testing, and all of those other kinds of critical processes for building applications. It was good.

+ +

CHAD: What does transitioning to agile mean when you talk about groups that size? You're talking about unit tests and that kind of thing, which can be part of agile, but I assume isn't the only aspect of it.

+ +

VICTORIA: Yeah, I think for that group, it was about changing the way we planned and managed work and figuring out what processes could we automate. So is there testing that we could automate or test data creation we could automate? And I think there are some concepts from agile that helped our planning, for example, making a physical board to manage which environments has which versions of Oracle in it.

+ +

Those types of concepts of just kind of stepping away from your computer and getting together with the group every day to talk about what issues they're running into that's kind of what it was. But there was still, of course, documentation requirements, big documentation requirements, and everything like that. So it was an interesting sort of half transition or tailored approach to doing agile with that type of team.

+ +

CHAD: And then from there, you moved into ongoing sort of consulting companies that worked with government.

+ +

VICTORIA: Yes, I worked for two pseudo-government financial organizations, Pension Benefit Guaranty Corporation and Fannie Mae, so my next two roles as a project manager and system engineer. So at Pension Benefit Guaranty Corporation, I got exposed to more system engineering and security engineering, working with their mobile device management policy, and actually designing the mobile device management to match DISA STIG. Sorry, I'm doing a lot of acronyms out here. [laughter] You can stop me if I use too many.

+ +

But that was really interesting and also upgrading their system, they were using to manage change for the organization so their ITIL services management tool. Going through the process of upgrading that project and coordinating across all the teams who delivered software at the agency was fascinating.

+ +

I went on to Fannie Mae, where I started to really build knowledge bases and start to build out actually using SharePoint at the time. [laughs] But figuring out ways to share knowledge across large teams and other large production support services teams, and how to get them collaborating so they could improve themselves and do continuous improvement, and learn what other groups are doing.

+ +

CHAD: That's one area where I honestly don't have a ton of experience. Most of my professional experience has been at thoughtbot or other smaller organizations. How do you manage that, or what are the big differences between large organizations like that and something at the thoughtbot size or smaller?

+ +

VICTORIA: The biggest difference between a large organization like that and a small one like thoughtbot would be I think of how change gets generated and started. In a small organization with a culture like thoughtbot, change can come from anywhere and very quickly have permeated the entire organization. With a larger organization, you can have leaders try to force change from the top down.

+ +

And you'll see individuals some will be 100% on board. Others will figure out how to qualify what they're already doing to fit that change. And some others will just be full-on resistance and just kind of be waiting for the next leader to come in so they can switch into whatever they were doing before.

+ +

And there is also that organic change that comes from individuals and then pushes up to the rest of the organization. But I think it's much harder, and you have to have a lot of will and a lot of support from leadership that they're accepting of those types of ideas.

+ +

CHAD: I think it's the nature of groups and companies to want to grow. Do you think that there's any way to preserve that smaller culture as an organization grows?

+ +

VICTORIA: I think so. I think it's possible if you integrate it into part of your core values, and that becomes a part of how you interview, and how you do performance reviews, and how you build your culture as a company. I think you can build it on those tenets.

+ +

I think in some organizations, there's usually some form of acquisition where you acquired a team from a contracting company, or you acquired a team of federal employees from another agency when you restructured. So it makes it a little bit more challenging to really integrate that part of your culture into every step, but it is possible. And you also have to accept that not everyone might be on board all the time.

+ +

CHAD: Well, I think that that is probably the biggest challenge is even in a larger organization, if you foster a culture where change can happen from anywhere, it's not necessarily top down. Transferring that knowledge or that practice throughout the whole organization is really difficult. Like if it's thousands or tens of thousands of people, adopting a change seems really difficult to me. So even if things are really organic coming from all levels of the company, you could end up in a scenario where everything is being done differently, everywhere.

+ +

VICTORIA: Yeah, and I think, too, when you're in a larger organization, there's more context for every unit. And so you can think this is a change we're going to do. This is going to be great. But then, once you actually see the way that people work, that change might not actually help them that much. And so I think that if people have autonomy to be able to make changes that make sense for them, that's more likely to be effective than if we tried to push change from the top down necessarily. And being in my position as a contractor, I really don't have authority to make a lot of changes.

+ +

CHAD: [chuckles] Right.

+ +

VICTORIA: So either I have someone backing me up, or I really get to know the individuals that I'm working with. And I can demonstrate and show them that there's a better way of doing it and do it in a way that gives it to them as an option so they can choose to adopt it. And that's usually the only option I have to give anyway, [laughs] so that's been effective because people do want to be better at their jobs or be more efficient. But a lot of times, I think the changes aren't really addressing their problem, and so it can be easy to push it aside.

+ +

Mid-Roll Ad:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs

+ +

CHAD: So you mentioned you got involved in DevOps DC and then as an organizer. I know you also started to work with Women Who Code. Why did you get involved in the organization of DevOps DC and that kind of thing? Was there a business or a personal reason to do it?

+ +

VICTORIA: It was both. It made sense from a networking perspective, both in potential customers or clients and in recruiting. But also, I think it made sense. For me personally, the people who were showing up regularly were my kind of people, you know, [laughs] people who cared about blameless post mortems or feeling open or making me feel welcome when I came to the meetup. That was a big reason why I got involved. And it just made sense for me, too, because I was coming from an operations background. I'm like, oh, DevOps, this is the way that we're supposed to be doing things. [laughs]

+ +

CHAD: So you were really involved in the D.C. community and had been there for a while. But you recently moved to California.

+ +

VICTORIA: Yes, yeah. I've been in San Diego for almost two years, about a year and a half at this point. Yeah, big moves.

+ +

CHAD: What was it like to move away from your old community, which was so based on geography?

+ +

VICTORIA: Yeah, it was sad, but it was interesting how it worked out with the pandemic because when we found out we were going to move, was when everything shut down, and we went slowly remote anyways. And so I continued running DevOps DC remotely and some Women Who Code events for about a year afterwards.

+ +

And then, when I decided it was time to really shift away and actually be more present in the San Diego community, especially when the other meetups started going back to in-person meetups, that was actually really hard to say goodbye and to say that I wasn't going to be organizing anymore. And I really miss all my past organizers and people who would come to the events.

+ +

CHAD: Has it been difficult to form a new community locally given the pandemic?

+ +

VICTORIA: Yeah, I've looked at quite a few meetups. There are a number of good meetups here in San Diego, and LA has a great scene as well. But yeah, it's been hard for myself to just get out of the house and to find similar groups that have those same interests. That's been a challenge, but I think it's coming along, and we'll get there.

+ +

CHAD: And along the way, you joined thoughtbot. I'm curious, what were the things, in particular, that attracted you to the role or to thoughtbot? What were you looking for personally?

+ +

VICTORIA: Personally, I knew that business development was an area that fit my skill sets really well, and the things I like to do like going out, and networking, and talking to people. And this role, in particular with the DevOps strategy in there, really excited me because I could use all of these hours and hours I've spent in meetups and conferences to good use to help develop services within thoughtbot that are really tailored to our specific user groups and needs. And to work with highly skilled, highly regarded engineers and developers on developing these products I thought was really exciting.

+ +

And then thoughtbot as a company, in particular, I found the interview process to be really well thought out with, for example, I knew that it was going to be a long interview process. So there is a compensation that you can receive just for interviewing. And I thought that was something that was really nice [laughs] and also just showed that approach of being aware of the candidate's experience and wanting to have that be a good experience and a worthwhile endeavor. So that was part of why I liked thoughtbot.

+ +

Open source was a big consideration for me. I wanted to work somewhere where they were passionate about giving back to the open-source community, and all that together brought me here and made the most sense.

+ +

CHAD: Cool. Do you have any tips for people onboarding into a new role? Or maybe even if it's not tips, was there something that you did intentionally when day one or day minus one you're thinking about, okay, tomorrow I'm getting started? How did you approach that?

+ +

VICTORIA: One of the biggest advice I give to people who are starting a new role is to schedule one on ones with members of your team and get to know them as individuals, especially in remote environment since you don't necessarily have a chance to go out for coffee, [chuckles] just to have a quick one on one and get to know them a little bit more in your role and figure out where you can start to add value. I think that's a great way to start. And then to just develop your list of ideas for where you think you can add value, some outstanding questions for where you need to understand more.

+ +

And I think the other advice would be to engage in the social channels. I think my first day, I posted a picture of my dog on the dogs' channel. [laughter] And just like, let your personality show a little bit. And don't be afraid to post in a large channel, especially if you know the culture of the company is open to that kind of collaboration. And then people start to see your face and get to know you a little bit more, and you feel more connected to your company.

+ +

CHAD: Were you nervous when you joined on your first day?

+ +

VICTORIA: Yeah, a little nervous. And I'm also aware of just having been a federal contractor that some people might hear that and have an impression of my style or the way I like to work. And so I'm a little aware of like, oh, I definitely don't want to wear a blazer. I don't want to look too corporate.

+ +

[laughter]

+ +

CHAD: That's funny. Yeah, one time, we were meeting in sales meetings with clients, and we wanted to establish that we were not a typical consulting company. And so intentionally going to a sales meeting wearing a t-shirt or something like that was a statement, like an intentional choice we were making to subtly communicate what kind of company we are. So that resonates with me.

+ +

VICTORIA: Right. [laughs]

+ +

CHAD: So now that you've been here for...oh, geez, how long has it been? [chuckles]

+ +

VICTORIA: It's almost a month.

+ +

CHAD: Almost a month. Was there anything that surprised you?

+ +

VICTORIA: There have been a few small things that I'm probably way too happy about. One is just the actual page count in contracts is just way lower than what I've had to work with in the past, [laughter] which is very exciting for me. I was really happy to see...I went to go add a custom Slack emoji, and there were already like 2,000-plus Slack emojis. So that was really exciting for me. [laughs]

+ +

Surprising...the part that's interesting is, in some cases, as a consulting company, it is the same problems that we're trying to solve for. So, in that case, it's almost expected, but it's interesting. So to see some things like what thoughtbot has, a playbook in GitHub, and anyone can edit it. And that was something I was really trying to work on at my last position.

+ +

And you're 5 or 10 years down the road where you've solved some of the issues where you have a nice editor so that people can go in and edit pages without using Markdown or pull requests. But it's still difficult. So it's interesting to see that some challenges have progressed a little and have still some different issues.

+ +

CHAD: Yeah, it's always interesting to get a new person's perspective with fresh eyes. I've been doing this for a long time, and joining a new company remotely is different. Back when you were joining a Boston team or a San Francisco team, you could go into the office. And your first day, you'd be sitting right next to somebody and going to lunch with them. And that kind of thing is clearly very different now than it was then.

+ +

VICTORIA: Right. And I did get to see everyone at Summit for one night. So that's exciting.

+ +

CHAD: Yeah, that was exciting. So we happened to...I think the week before you started, or maybe two weeks before you started, we were having our company-wide in-person get-together in the United Kingdom. And you happened to be going to Germany for a wedding, right?

+ +

VICTORIA: Mm-hmm.

+ +

CHAD: So we tacked on to that trip and stole you for a day, and we were able to see each other in person. That was exciting.

+ +

VICTORIA: It was really cool. Although I had a lot of FOMO once, I saw the next day was like D&D and a bunch of games and hanging out. I was like, wow, I'd really like to stay longer. [laughs]

+ +

CHAD: Yeah, yeah. Well, we'll do it again next year. [laughs]

+ +

VICTORIA: Yeah, that's true.

+ +

CHAD: Mission control is the one team at thoughtbot that works on clients that is cross time zone, so most of the teams overlap with clients 100% with time zone. So it'll be people in the Americas work with clients in the Americas. But the Mission Control so that we could provide a wide swath of time zone coverage for that infrastructure work, for that support that we do, crosses the teams. So one person on your team is in Nigeria, and you're all the way in San Diego. What's that like? How do you manage that?

+ +

VICTORIA: Yes, well, everyone on the team makes sure to update their availability in their calendars so that we aren't accidentally scheduling meetings really late in the day for folks who are on that UK time zone. It's been all right, though. I'm used to asynchronous communication, and so is the team. So I think that we're really good at being able to use Jira and Confluence and Slack to communicate. And we are open with each other on where we're flexible if we need to make meetings a little bit later.

+ +

And everyone's been really supportive of not trying to have meetings too early with me, which I appreciate, [laughter] 8:00 o'clock is totally fine, though. It's actually been good. I'm used to the asynchronous communication. I actually would even be open to more meetings that are done just over Slack and just when people wake up.

+ +

CHAD: I think there are different philosophies here. But I'm very much in the camp of assuming we want to work a sustainable pace, which we do, then you can't build a culture around synchronous meetings where everyone needs to be on the meeting together because it's basically impossible. Those two things are at odds. Someone will be outside of their regular work hours, and that's really hard to continue on sustainably.

+ +

So I'm very much in the camp of having a culture of asynchronous communication. And that doesn't mean that you never talk. [laughs] It doesn't mean that you don't work with each other. But maybe those times should be focused on what can't be replicated asynchronously, which is sometimes the social connections, the cultural connections of the team.

+ +

VICTORIA: Yeah, and I think we get a kick out of saying like, "Good morning, Victoria, and good evening, Olamide." [laughs]

+ +

CHAD: Cool. Well, I'm sure folks will get to know you more over the course of the next episodes. I really appreciate you joining the show. If folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

VICTORIA: I'm more active on Twitter, and so you can follow me there. And I tend to like and retweet a bunch of DevOps-related events and Women Who Code events. And I'm also on LinkedIn.

+ +

CHAD: So what's that Twitter handle?

+ +

VICTORIA: It's @victori_ousg.

+ +

CHAD: Okay. We'll include a link to that in the show notes. You can subscribe to the show and find notes along with an entire transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And I'm so excited it's not just going to be me on that email list anymore. So definitely send an email. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening.

+ +

Victoria, thank you again.

+ +

VICTORIA: Thank you

+ +

CHAD: And see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+vowQcEzU + + ]]> + + Chad Pytel + + + 435: Numerated with Adam Kenney + https://podcast.thoughtbot.com/435 + f4adb484-995d-40bc-a2e1-ed4213d3b4b3 + Thu, 11 Aug 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Adam Kenney is Chief Product Officer at Numerated, which helps banks and credit unions transform how they lend to businesses. + +Chad talks with Adam about what institutional banks and credit unions are like as a market and customers and what sales cycles look like, going from 17 to more than 130 customers quickly, and the scaling challenges they faced, and how the pandemic affected them as a company. + 34:49 + no + + + Adam Kenney is Chief Product Officer at Numerated, which helps banks and credit unions transform how they lend to businesses. +Chad talks with Adam about what institutional banks and credit unions are like as a market and customers and what sales cycles look like, going from 17 to more than 130 customers quickly, and the scaling challenges they faced, and how the pandemic affected them as a company. +Numerated (https://www.numerated.com/) +Follow Numerated on Twitter (https://twitter.com/numeratedgt), YouTube (https://www.youtube.com/channel/UC4igz9AZqOXJlZxtXUBO-1Q), or LinkedIn (https://www.linkedin.com/company/numerated/). +Follow Adam on Twitter (https://twitter.com/ademski) or LinkedIn (https://www.linkedin.com/in/adam-kenney-ab-cmu/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me, today is Adam Kenney, Chief Product Officer at Numerated, which helps banks and credit unions transform how they lend to businesses. Adam, thanks so much for joining me. +ADAM: Thank you, Chad. Thanks for having me. +CHAD: Let's dive into Numerated a little bit more. How do you help banks and credit unions lend to businesses? +ADAM: I think we're in the middle of what is a pretty meaningful transformation in terms of how businesses are expecting to get access to credit. Really what they want is something that is fast, easy, convenient, largely driven off of the change that has happened in the retail space over the last 10 to 15 years. And in many ways, business lending is still catching up to that, and so our focus is doing that. It's helping the banks and credit unions really change how they interact with their business customers. We use a combination of data and great experiences to make that process as seamless as possible. +We've been noted to, using the combination of data and technology, help banks increase the number of loans that they can do with their existing staff by as much as fourfold. We are also noted for inventing what we like to refer to as the three-minute business loan. It's one of the things we were written up on in the Wall Street Journal back in our days in Eastern Labs, where we've been able to get businesses from the point of application all the way to a funded loan in less than three minutes. And that's a process that historically has taken as long as three weeks. +And so really excited by the ways that we're able to really help change how banks themselves can look at their operations. But more than anything, it's how banks are able to rethink and change how they interact with businesses and help the businesses in your communities grow and get access to the credit that they need. +CHAD: So from a digital product perspective, there's a piece of a product there that banks are actually taking on and white-labeling that provides a lending experience for their clients, right? +ADAM: That's correct. I mean, we're a cloud-based SaaS system. But you're right; they branded as their own. And so if you're going to Eastern Bank's website and clicking through and ultimately going through the application process with us, it's going to look and feel like it's just Eastern's website. And all of the interactions that you have with Eastern or any of our customers are going to feel that way as well. So yes, it is a white-label solution that we sell to the banks, and they provide to their customers. +CHAD: The actual banking industry is not one that I've had a lot of experience in. And so I'm curious what institutional banks, credit unions, that kind of thing what they're like as a market or as customers and what the sales cycle looks like and those kinds of things. +ADAM: It's about as varied as an industry can get, I'll tell you that. [laughs] You have to remember that banks and credit unions can be as small as having a few hundred million dollars in assets, maybe as small as 100 million. And in some of our customers' cases, they're de novo banks, and they're just getting started. And they range up to multiple billions of dollars in assets. And so, these are organizations that scale dramatically. Each of them have their own problems. +They're also going to be made up of very different tech-minded individuals. You're going to have some smaller institutions that are basically managing a book of business that's been a book of business for close to a century and are interested in how technology can make them more efficient. But they are not the technologists that you and I would be used to working with on a day-to-day basis. And then, of course, you have people like ourselves who are really trying to, from inside the bank, change what banking is to their customers. And so, it's a very diverse industry in terms of what they're looking to accomplish. +We've even come up with recently this framework around how we think about and really talk to our customers about how they transform and the levels of transformation that they can go through. And for us, it's essentially a four-level transformation starting with very small and pointed technology innovations that allow them to drive innovation in very fragmented bits and pieces, for lack of a better term, up to and including they're going to transform everything or become a digital bank. And you can imagine there are lots of stops along the way in terms of where a bank is and where they want to end up as part of their strategy. +CHAD: From a product perspective and managing change, do you get a lot of custom features from individual, either clients or potential clients? And how do you manage that if you do? +ADAM: The way I think about it is that we certainly get a lot of requests from our customers, and every customer likes to think that they are different and unique. In reality, there's a strong theme to almost all of the requests that we get. And personally, I think that's part of what our job is as a product leader is to really understand how to create themes out of the individual requests and provide a platform back to the market that addresses as many of those in a more holistic way and drives value across not just the individual asks but across all of the customers. And so yeah, there's some uniqueness. And certainly, we need to provide a platform that allows for that. +So as an example, every bank has a slightly different view into how they want their credit policy to work and be implemented, but the framework around how you make credit decisions, how I get data into the platform. How do I create a credit matrix? And how do I then decide the exact offer terms to drive out of that? Like, that's a standard capability. And so we're innovating on that based on the individual features, but it's really not with an eye towards providing a specific custom feature to individual customers. It's more providing a flexible platform that allows them to configure the nuance but in a general theme that's going to help them be a better business. +CHAD: So in the U.S., we had a specific program launched, PPP loans, in the pandemic to help support businesses. And I know thoughtbot we participated in that and went through that process. I don't think our bank was using Numerated. But I know that the bank really maybe...because they weren't using Numerated, [laughs] they needed to bring together an entirely new application interface very, very quickly in order to be able to take our application to that. And I think that Numerated was right there at the start of that. +ADAM: Yes. +CHAD: Talk about something custom maybe quickly. +ADAM: [laughs] +CHAD: What did pulling that together look like? +ADAM: So maybe to take a step back if I could first and just paint a picture for you because you're right, it was kind of a unique and incredible period of time. We were fortunate in our line of work because we are all about helping banks transform how they lend to businesses. We had the base platform already built and established that allowed businesses to apply for loans on our platform. Even before the pandemic, we were one of the leading technology platforms for processing SBA loans. So we were uniquely positioned for the opportunity as it results to PPP. +At the start of the pandemic, we had approximately 17 customers using our platform. Fast forward six months later, we had 135. And so, to your point around there were a large number of institutions looking for a new application solution overnight, I think that shows you how aggressively banks needed a solution. And there was an opportunity for us to offer our platform to be that. +I think the other thing to recognize as part of the backdrop anyway is this was a crazy time if you think back to where we were in the pandemic. No one knew what life was going to look like in a week. And most businesses, especially smaller ones, didn't know if they were going to have a business. And so for us, that also provided the opportunity and maybe a little bit of the confidence in saying, "You know, we have nothing to lose. We're well-positioned. And what else are we going to do? Because it's not like people are making other loans for the next couple of months. Let's just go own this". +And so I think it was the combination of us making that recognition, having a really good base platform that had familiarity with the SBA, had familiarity with business lending, and with a team that then could really acutely focus on solving this one problem for as many customers as possible. And by the way, have the emotional impact of not only helping banks but knowing that we're basically helping hundreds of thousands of businesses stay afloat through probably the craziest time in our country's history. And so that's really what got us going. +And then there was a ton of work to your point around customization around building out the platform. But the one thing we've tried to do from the beginning is hold true to some of the foundational vision that I mentioned earlier. Like, we don't want to be in the business of custom software. That's not a winning proposition for us or our customers. And so, as much as it was maybe hard at times, throughout PPP, we were always thinking about okay, so we have to make these changes to support this crazy never-before-seen lending program. +But how can we do it in a way that's going to set us up to serve the businesses in a year or two when this whole pandemic thing is over? Because PPP is not going to last forever, but our customers are. The businesses are still going to need credit. So whatever we're doing as much as possible, let's be building a foundation that gets us well beyond PPP. And so we were using it as really a catalyst to build a bigger business even while we were helping customers through the pandemic. +CHAD: One of the things that I really appreciated, and I have an outside perspective on it, but I really...and people can always do better. +ADAM: Yes. [laughs] +CHAD: But I thought it was one of the rare circumstances where everyone realized the urgency of the situation: government, banks, everybody. And there was a real willingness to realize, well, we've got to do something. If we try to figure it out all right now, it's going to take too long. So let's just do something, and we'll work out the details later. And so I think there was a willingness, and from a product perspective, my guess would be that allowed you to work iteratively too. +ADAM: It did. It was [laughs], I think in some ways a blessing and a curse. +CHAD: [laughs] +ADAM: Because I can tell you that the number of times my team would get a set of new capabilities, which listen, were great for the customers. It made everything better for the businesses that needed help, so I would never want it any other way. But the number of times that those new capabilities were announced by the SBA on a Friday night and were expected to be live on Monday morning, let's just say it was more frequent than I would ever like to relive. [laughs] +And I can remember, especially going into the second round of PPP, it just so happened that all that was happening between Thanksgiving and Christmas in a year where all families wanted to do was spend time with each other after a crazy year had gone by. But we didn't get that luxury, unfortunately. We had a job to do, and that was to make sure that we were ready for the next round. And so it did come with a lot of cost in terms of we had to work really hard to make it happen. +But to your point, it allowed us to iterate. And I give the government credit, too, particularly the SBA. They could have, for example, just launched the program and then launched more money into it and stood still, but they didn't do that. To your comment, they had to get live as quick as possible. And so that first round of PPP, there were more technology hiccups. The SBA had some volume constraints. They couldn't really handle the performance. We ended up having to govern our application submissions because otherwise, the SBA couldn't handle it. +There were other challenges in terms of how we were validating data. But that got better month by month. And certainly, by the time we got to the forgiveness part of the process and then the next round of PPP the following winter, they actually invested in completely ripping out their legacy API and providing us in the tech community a modern RESTful interface that was much easier, much more performant. And so, even though the volume got even crazier as we went through the program, it actually became easier for us to deliver. +The first round, we were literally working around the clock because the SBA was having issues. We couldn't get enough documents through DocuSign and whatever else. We did, I want to say, close to 3 times the volume in the next round a year later but at about 15% of the energy because we had just improved that much in less than a year. And it wasn't just Numerated; it was Numerated working with our partners in government and elsewhere to just get the process that much smoother for our customers. +CHAD: Were there things that you needed to do at Numerated? I mean, to go from 17 customers to more than 130 that quickly, I assume that there were some scaling challenges for you along the way. +ADAM: There was. And I will say this: we were blessed to have a really good technical infrastructure in place that allowed us to scale on the infrastructure side without a ton of problems. We were able to essentially stand up new environments in our infrastructure relatively quickly and easily and even handle the peak volume of PPP, which was exponentially higher than anything we had ever done on the platform. That was not a problem for us. Where we had to scale is in two areas, one from a technical standpoint was how we were interacting with our technical partners. +I mentioned already the need to govern how we were submitting applications to the SBA. We worked very closely with DocuSign to essentially put rate caps on how many documents we were generating at any given time and essentially spread the volume because none of us had dealt with that or dealt with that kind of volume before. And that's where we had technical challenges were in the interfaces and working with partners to make sure everything lined up well. So that was one area, got through it pretty well. And ultimately, like I said, for the second round, we were smooth sailing. +The other area to your point around standing up all the banks was how we implemented the customers. Our typical implementation cycles going into the pandemic were multiple months. We had to stand up all over the PPP banks in less than two weeks. And so that took a combination of...I'll call it technical delivery. So we essentially created a cookie-cutter deployment and then used a deployment strategy to push that to all of the new customers all at once that we didn't have before. And we were able to create that relatively quickly. +The other was we had to take a much harder stance with our customers than we had ever done around look; everyone's getting the same thing. It's government-mandated anyway, but it's going to be exactly the same. And other than the white-labeling that we, of course, gave everybody, you might want slightly different process around the workflow, around the approval. +You're going to have to take the same thing that everybody else is because we just don't have time to configure the nuance across 100 banks. And so luckily, to your earlier comment around, everybody just realized we were in this unique time, we do what we have to do, and we got through it. Our banks were very willing to do that. But that was the other change we had to do to really see this scale through. +Mid-Roll Ad: +Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. +Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff +CHAD: If you're comfortable talking about architecture a little bit, do you have a shared sort of platform that everyone is on? Or, for each of the customers you have, do they have their own instance? +ADAM: So we've made the decision, mostly because of our regulated industry; we felt like it was safer, so each customer gets their own database. We do keep everyone's data completely isolated to protect their information and give them the utmost confidence that it is protected. But we have a shared application layer. And so, our web servers are shared multi-tenant instances. And so it's essentially a combined environment where we're both sharing some resources but then also deploying individual databases and then the configuration because outside of PPP, it is unique bank by bank. And so, the configuration gets deployed within each bank's individual environment. +CHAD: Cool. I've worked on systems like that before, and they can certainly present...especially when you need to scale them quickly, and you've got a lot of new customers being added. You better hope that it's been automated. [laughs] +ADAM: Yes. And luckily, we had a good amount of automation in place during PPP or even going into it, I should say, but of course, PPP stretched that. And so we've just continued to get better and better as a couple of years have gone by. +CHAD: So the second PPP came through. It's in the forgiveness period now, so that's winding down. So Numerated were at that point you alluded to earlier, which is when you were doing PPP, you realized it's not going to be around forever. Let's lay the groundwork now to help customers in the future. We're sort of at that point now, right? +ADAM: Yes. +CHAD: So what does that look like for you? +ADAM: So it's essentially expanding the portfolio of loans that our customers can leverage our platform to execute. And maybe to say that better, if you look back prior to PPP, we got our start with small small business lending. And what I mean by that is loans under $250,000 that can be highly automated. That's where Numerated got its start working with Eastern first 15 customers, saw the value in getting extreme efficiency and delivering essentially capital to their businesses in a number of days instead of weeks. +That's what we were great at, very similar to what PPP was, by the way, which was getting money to people in a number of hours in some cases. But we knew that that was never the vision for what we wanted to be or what our banks needed in the business banking segment. Ultimately, they want that same level of use efficiency experience for all of their business loans. But in order to support that, there are a number of capabilities that we needed to build into our platform to handle that. +Underwriting gets increasingly complicated when you are underwriting loans at 500,000, a million, or $5 million. The businesses get more complicated. The collateral gets more complicated. The entire process just becomes more sophisticated. But that's what banks want, and by the way, that's what businesses want. They don't want to have a great experience when they're a little bit smaller, and they've taken out a $100,000 loan and then have the experience be crap two years later when they come back, and they've taken out a million-dollar loan. And so, that has always been our vision. +We've had the fortune of being able to do really well on PPP and essentially just accelerate that vision. And so that's what we're working on right now is really building a loan origination system that allows our customers to transform how they lend to businesses in entirety. We have been building out all of the sophistication I mentioned around underwriting. +We have recently acquired a company called Fincura based out of the Boston area. They automate spreading. If you're not familiar with what spreading is, it basically takes either paper or PDF versions of a bank's financial statements, and it turns them into really critical financial ratios that help banks understand the creditworthiness and the risk associated with the business. So you can imagine what that is. +It's taking OCR, technology, AI, and basically taking what were PDFs and converting them into scores that can then be used to automate and drive efficiency in the credit decision, again, all part of being able to then really transform how banks are doing all of their business lending. But that's what we're working on now, converting all of the PPP customers to use the non-PPP, for lack of a better phrase, parts of the platform and really helping them change how their businesses look at them in terms of the opportunity to access credit. +CHAD: So I think it's probably worth noting you made the decision to join Numerated right before the pandemic hit. +ADAM: That's correct. +CHAD: And so you joined when? +ADAM: My last day at my previous company happened to be the day we closed the office due to the pandemic. I had obviously made the decision prior to that. But then, my first day on the job at Numerated was the second day of PPP. So essentially, you know, call it a week after everybody had gone home for what became the better part of the next year to two years. +CHAD: So I assume making a decision to join a new company, you're going to be the chief product officer. You've had a lot of conversations about what the vision is and what you're going to do. And you're going into a business where hey, there are 17 customers, and we're going to scale. But you probably didn't guess what was going to happen ended up happening. +ADAM: No. [laughs] +CHAD: So I imagine like part of your vision for what you were going to do both as a company and as an individual must have gotten put on hold. +ADAM: It's funny, yes and no. So I will say no to your lead in there. There were certainly times before I started where I was calling Dan our founder and CEO. And I was probing him and pushing him like, is this still a thing? [laughs] Are we really going to go do this? Not realizing what PPP was and really what it was going to mean for our business. So there was that period of time where I wasn't sure. I knew it was going to be different, but I didn't know what that meant yet. +Once I understood what was happening and what we were doing, I actually never felt like it was putting anything on hold. And I can come back to the fact that it put some elements of our business on hold. But for me and why I joined and the vision I had, I was coming to help the team really expand what the platform could do for banks and their business customers and to accelerate the number of ways we could help. I have prior experience working at Capital One and Pegasystems with a lot of the systems and the processes that we were helping to reinvent at Numerated. +And so, my vision was always to come and build off of those past experiences and accelerate what we were doing in this specific small business segment. PPP, in a lot of ways, just accelerated that. It took what would have probably been three to five years’ worth of market adoption in terms of understanding what digital transformation was going to look like, getting customers fully comfortable with a more digital experience, getting comfortable with a more data-driven approach to decision-making. And the pandemic forced all of that to happen in weeks. +CHAD: Well, people couldn't even go into the bank to turn in their paperwork. It had to be done remotely. The staff wasn't there either. +ADAM: And the staff no longer could look at paper financial statements because they couldn't get paper financial statements. And so everything changed overnight. One of our customers has told us at multiple customer events since he's like, "You guys, you let the rabbit out of the hat, and it's not going back." It just changed overnight what was happening in the industry. And then, for us, it gave us all of this extra opportunity to invest and invest more in what we wanted to go do. +Our team, when I joined, was about 40 to 45 people. Our team now is 145 people. And our engineering team went from a little over 20 to just under 60. So we have exponentially changed the rate in which we're innovating and going after things. And so, for me, it's just accelerated and made things more exciting. The one other comment I'll make in terms of putting things on hold it did put some elements of the business on hold because every one of our customers stopped thinking about what I'll call traditional business lending and focused 100% for the better part of 18 months on getting through the pandemic. +And even once PPP was done, there was another six to nine months where banks were trying to figure out, are we really out of the pandemic? Are we ready to start lending the way we used to? Do we need to rethink risk? Because these businesses are all different now than they were two years ago. The things that made a business risky two years ago are different now. +And so there was also a little bit of a hangover as our customers internalized within their own walls what it meant to get back into lending. And so, it did put some elements of that on hold. We were fortunate, though, that we grew so much through PPP. And we actually kept adding what I'll call core customers, not just PPP customers, during that period that our growth actually accelerated. And it's been really good for us. +CHAD: That's great. You mentioned the team growth that you've had. Different companies are organized in different ways. As Chief Product Officer, where do you sit within the organization and relative to the engineering team? +ADAM: So at Numerated, my responsibility includes all of the product management as well as the engineering organization. So I'm responsible with my teams for everything from initial product strategy, the product design. I have all of the UX and design team as well as then all of the execution, the delivery of the platform as well. +CHAD: So does that mean that there's VP of engineering in your organization or some sort of person like that that's working closely with you? +ADAM: Sort of. So I have...basically, it divides more at the director level. So I have a couple of VPs that work for me that have a combination of product and engineering, both experience, expertise, and responsibility. But then their teams have product managers, and then we have directors of engineering that then manage their individuals from teams. I also have a group of former bankers. They're product managers but act as consultants to those organizations. And that's where we get all of our industry expertise. They've worked with the SBA. They've worked in credit offices, and they really help to influence the product roadmap across those teams as well. +CHAD: So the entire engineering structure also being under the chief Product Officer, I would say that and correct me if I'm wrong, I think that's probably not how the majority of companies organize it. Do you agree with that? +ADAM: I have seen both, but I would agree that it is not the majority. +CHAD: I would say if there is a majority, and I agree, I've seen both too, but you might have a CTO and then VP of engineering. And so, the engineering organization goes all the way up to the C-level. And then there's a Chief Product Officer. And here's the product management and product underneath them. Was this an intentional choice from the beginning as you scaled out the team for you to have it all live under you? +ADAM: It was intentional. I will give my personal view on it. I think that as we continue to evolve as technology companies, one of the hardest things for us to achieve is alignment around vision and purpose. And that drives a level of focus that I think maximizes the ability to move the business forward. And based on that premise, the places where I've seen things work the best is when there is a focal point across product and engineering within specialization underneath. Because it drives, I think, the best alignment across the organization. +I will acknowledge, however, that finding leaders that can actually operate effectively in that combined role is extremely difficult because you need people that have a high degree of engineering experience so that they actually know how to build for quality, build for scale, even for things that don't immediately impact the bottom line while having enough business acumen to understand the demands of the business and how to balance those priorities against what we need to grow the business at the same time. +And so, it does create a little bit of a snowflake challenge. I cannot find or replace those roles as we grow and scale nearly as quickly as I can in a divided organization. But I have found that it does help me drive clarity of priorities and purpose and ultimately focus in the organization versus the places I've worked where that hasn't been the case. +CHAD: So I guess given that, then I assume you're hiring. [laughs] +ADAM: We are always hiring. [laughs] We are definitely in growth mode. And we are looking for great people that can help us to build a platform and really transform how our customers are thinking about how they lend to their businesses. +CHAD: Well, I agree. I think there are different structures then that can achieve it. And also, a lot of it comes down to the people but that alignment and that understanding of design, and product, and development or engineering. And ideally, people and all of those skill sets and all those teams who get it and can balance those different priorities with the business is really important, and that alignment of vision. And so there are probably different structures to get it, but that's what you're aiming for. And I think that the structure that you've set up is one which is very helpful to getting that alignment. +ADAM: Agreed. Agreed. I think that while we're on the topic of the team and the culture we're trying to build out, I'll maybe use that as a way to share a few more things that we're really driving towards. You can imagine a company that has scaled the way we have and continues to grow. That presents some other organizational challenges as well. One of my firm beliefs is the fastest way to scale is to create really strong, empowered, decentralized teams. That, again, gets back to the whole vision and focus thing. They have to be rowing in the same direction. But they have to be really independent in the day-to-day. +And so we've really spent a lot of time over the last, I would say, year and a half shifting to that kind of a model to where each of the teams is really embracing what their individual accountabilities are. They are really focused on how they're delivering success for the business and are able to make a lot of the day-to-day decisions. But then it falls to management, leadership, myself to make sure that when they make those decisions, they understand the context in which we're trying to drive the business so that we can do as much as we can as fast as we can but in a way that's high quality and delivers value. +CHAD: Awesome. Well, I sincerely wish you all the best in that. I really appreciate you stopping by and sharing. Thank you. +ADAM: Yeah, my pleasure. I appreciate the time, and good to get to know you a little bit, Chad. +CHAD: If folks want to find out more, maybe apply, follow along with you; where are all the places that they can do that? +ADAM: Yeah, sure. So numerated.com is where they can go and learn more about the business, and they can learn more about where we're hiring. People should check me out on LinkedIn. That's probably where I'm the most active these days. And feel free to message me as well. I'll also give you my email address if anybody wants to reach out. It's pretty simple. It's adam@numerated.com. Whether it's opinions, thoughts, or reactions to anything that I've shared today, or you just want to build a relationship, I'd love to hear from people and get to know you a little bit better. +CHAD: Wonderful. You can find links to all those things, probably not Adam’s email address, in the show notes. +ADAM: [laughs] +CHAD: We want to protect him from those spam crawlers. But you can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Adam Kenney. + + + Adam Kenney is Chief Product Officer at Numerated, which helps banks and credit unions transform how they lend to businesses.

+ +

Chad talks with Adam about what institutional banks and credit unions are like as a market and customers and what sales cycles look like, going from 17 to more than 130 customers quickly, and the scaling challenges they faced, and how the pandemic affected them as a company.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me, today is Adam Kenney, Chief Product Officer at Numerated, which helps banks and credit unions transform how they lend to businesses. Adam, thanks so much for joining me.

+ +

ADAM: Thank you, Chad. Thanks for having me.

+ +

CHAD: Let's dive into Numerated a little bit more. How do you help banks and credit unions lend to businesses?

+ +

ADAM: I think we're in the middle of what is a pretty meaningful transformation in terms of how businesses are expecting to get access to credit. Really what they want is something that is fast, easy, convenient, largely driven off of the change that has happened in the retail space over the last 10 to 15 years. And in many ways, business lending is still catching up to that, and so our focus is doing that. It's helping the banks and credit unions really change how they interact with their business customers. We use a combination of data and great experiences to make that process as seamless as possible.

+ +

We've been noted to, using the combination of data and technology, help banks increase the number of loans that they can do with their existing staff by as much as fourfold. We are also noted for inventing what we like to refer to as the three-minute business loan. It's one of the things we were written up on in the Wall Street Journal back in our days in Eastern Labs, where we've been able to get businesses from the point of application all the way to a funded loan in less than three minutes. And that's a process that historically has taken as long as three weeks.

+ +

And so really excited by the ways that we're able to really help change how banks themselves can look at their operations. But more than anything, it's how banks are able to rethink and change how they interact with businesses and help the businesses in your communities grow and get access to the credit that they need.

+ +

CHAD: So from a digital product perspective, there's a piece of a product there that banks are actually taking on and white-labeling that provides a lending experience for their clients, right?

+ +

ADAM: That's correct. I mean, we're a cloud-based SaaS system. But you're right; they branded as their own. And so if you're going to Eastern Bank's website and clicking through and ultimately going through the application process with us, it's going to look and feel like it's just Eastern's website. And all of the interactions that you have with Eastern or any of our customers are going to feel that way as well. So yes, it is a white-label solution that we sell to the banks, and they provide to their customers.

+ +

CHAD: The actual banking industry is not one that I've had a lot of experience in. And so I'm curious what institutional banks, credit unions, that kind of thing what they're like as a market or as customers and what the sales cycle looks like and those kinds of things.

+ +

ADAM: It's about as varied as an industry can get, I'll tell you that. [laughs] You have to remember that banks and credit unions can be as small as having a few hundred million dollars in assets, maybe as small as 100 million. And in some of our customers' cases, they're de novo banks, and they're just getting started. And they range up to multiple billions of dollars in assets. And so, these are organizations that scale dramatically. Each of them have their own problems.

+ +

They're also going to be made up of very different tech-minded individuals. You're going to have some smaller institutions that are basically managing a book of business that's been a book of business for close to a century and are interested in how technology can make them more efficient. But they are not the technologists that you and I would be used to working with on a day-to-day basis. And then, of course, you have people like ourselves who are really trying to, from inside the bank, change what banking is to their customers. And so, it's a very diverse industry in terms of what they're looking to accomplish.

+ +

We've even come up with recently this framework around how we think about and really talk to our customers about how they transform and the levels of transformation that they can go through. And for us, it's essentially a four-level transformation starting with very small and pointed technology innovations that allow them to drive innovation in very fragmented bits and pieces, for lack of a better term, up to and including they're going to transform everything or become a digital bank. And you can imagine there are lots of stops along the way in terms of where a bank is and where they want to end up as part of their strategy.

+ +

CHAD: From a product perspective and managing change, do you get a lot of custom features from individual, either clients or potential clients? And how do you manage that if you do?

+ +

ADAM: The way I think about it is that we certainly get a lot of requests from our customers, and every customer likes to think that they are different and unique. In reality, there's a strong theme to almost all of the requests that we get. And personally, I think that's part of what our job is as a product leader is to really understand how to create themes out of the individual requests and provide a platform back to the market that addresses as many of those in a more holistic way and drives value across not just the individual asks but across all of the customers. And so yeah, there's some uniqueness. And certainly, we need to provide a platform that allows for that.

+ +

So as an example, every bank has a slightly different view into how they want their credit policy to work and be implemented, but the framework around how you make credit decisions, how I get data into the platform. How do I create a credit matrix? And how do I then decide the exact offer terms to drive out of that? Like, that's a standard capability. And so we're innovating on that based on the individual features, but it's really not with an eye towards providing a specific custom feature to individual customers. It's more providing a flexible platform that allows them to configure the nuance but in a general theme that's going to help them be a better business.

+ +

CHAD: So in the U.S., we had a specific program launched, PPP loans, in the pandemic to help support businesses. And I know thoughtbot we participated in that and went through that process. I don't think our bank was using Numerated. But I know that the bank really maybe...because they weren't using Numerated, [laughs] they needed to bring together an entirely new application interface very, very quickly in order to be able to take our application to that. And I think that Numerated was right there at the start of that.

+ +

ADAM: Yes.

+ +

CHAD: Talk about something custom maybe quickly.

+ +

ADAM: [laughs]

+ +

CHAD: What did pulling that together look like?

+ +

ADAM: So maybe to take a step back if I could first and just paint a picture for you because you're right, it was kind of a unique and incredible period of time. We were fortunate in our line of work because we are all about helping banks transform how they lend to businesses. We had the base platform already built and established that allowed businesses to apply for loans on our platform. Even before the pandemic, we were one of the leading technology platforms for processing SBA loans. So we were uniquely positioned for the opportunity as it results to PPP.

+ +

At the start of the pandemic, we had approximately 17 customers using our platform. Fast forward six months later, we had 135. And so, to your point around there were a large number of institutions looking for a new application solution overnight, I think that shows you how aggressively banks needed a solution. And there was an opportunity for us to offer our platform to be that.

+ +

I think the other thing to recognize as part of the backdrop anyway is this was a crazy time if you think back to where we were in the pandemic. No one knew what life was going to look like in a week. And most businesses, especially smaller ones, didn't know if they were going to have a business. And so for us, that also provided the opportunity and maybe a little bit of the confidence in saying, "You know, we have nothing to lose. We're well-positioned. And what else are we going to do? Because it's not like people are making other loans for the next couple of months. Let's just go own this".

+ +

And so I think it was the combination of us making that recognition, having a really good base platform that had familiarity with the SBA, had familiarity with business lending, and with a team that then could really acutely focus on solving this one problem for as many customers as possible. And by the way, have the emotional impact of not only helping banks but knowing that we're basically helping hundreds of thousands of businesses stay afloat through probably the craziest time in our country's history. And so that's really what got us going.

+ +

And then there was a ton of work to your point around customization around building out the platform. But the one thing we've tried to do from the beginning is hold true to some of the foundational vision that I mentioned earlier. Like, we don't want to be in the business of custom software. That's not a winning proposition for us or our customers. And so, as much as it was maybe hard at times, throughout PPP, we were always thinking about okay, so we have to make these changes to support this crazy never-before-seen lending program.

+ +

But how can we do it in a way that's going to set us up to serve the businesses in a year or two when this whole pandemic thing is over? Because PPP is not going to last forever, but our customers are. The businesses are still going to need credit. So whatever we're doing as much as possible, let's be building a foundation that gets us well beyond PPP. And so we were using it as really a catalyst to build a bigger business even while we were helping customers through the pandemic.

+ +

CHAD: One of the things that I really appreciated, and I have an outside perspective on it, but I really...and people can always do better.

+ +

ADAM: Yes. [laughs]

+ +

CHAD: But I thought it was one of the rare circumstances where everyone realized the urgency of the situation: government, banks, everybody. And there was a real willingness to realize, well, we've got to do something. If we try to figure it out all right now, it's going to take too long. So let's just do something, and we'll work out the details later. And so I think there was a willingness, and from a product perspective, my guess would be that allowed you to work iteratively too.

+ +

ADAM: It did. It was [laughs], I think in some ways a blessing and a curse.

+ +

CHAD: [laughs]

+ +

ADAM: Because I can tell you that the number of times my team would get a set of new capabilities, which listen, were great for the customers. It made everything better for the businesses that needed help, so I would never want it any other way. But the number of times that those new capabilities were announced by the SBA on a Friday night and were expected to be live on Monday morning, let's just say it was more frequent than I would ever like to relive. [laughs]

+ +

And I can remember, especially going into the second round of PPP, it just so happened that all that was happening between Thanksgiving and Christmas in a year where all families wanted to do was spend time with each other after a crazy year had gone by. But we didn't get that luxury, unfortunately. We had a job to do, and that was to make sure that we were ready for the next round. And so it did come with a lot of cost in terms of we had to work really hard to make it happen.

+ +

But to your point, it allowed us to iterate. And I give the government credit, too, particularly the SBA. They could have, for example, just launched the program and then launched more money into it and stood still, but they didn't do that. To your comment, they had to get live as quick as possible. And so that first round of PPP, there were more technology hiccups. The SBA had some volume constraints. They couldn't really handle the performance. We ended up having to govern our application submissions because otherwise, the SBA couldn't handle it.

+ +

There were other challenges in terms of how we were validating data. But that got better month by month. And certainly, by the time we got to the forgiveness part of the process and then the next round of PPP the following winter, they actually invested in completely ripping out their legacy API and providing us in the tech community a modern RESTful interface that was much easier, much more performant. And so, even though the volume got even crazier as we went through the program, it actually became easier for us to deliver.

+ +

The first round, we were literally working around the clock because the SBA was having issues. We couldn't get enough documents through DocuSign and whatever else. We did, I want to say, close to 3 times the volume in the next round a year later but at about 15% of the energy because we had just improved that much in less than a year. And it wasn't just Numerated; it was Numerated working with our partners in government and elsewhere to just get the process that much smoother for our customers.

+ +

CHAD: Were there things that you needed to do at Numerated? I mean, to go from 17 customers to more than 130 that quickly, I assume that there were some scaling challenges for you along the way.

+ +

ADAM: There was. And I will say this: we were blessed to have a really good technical infrastructure in place that allowed us to scale on the infrastructure side without a ton of problems. We were able to essentially stand up new environments in our infrastructure relatively quickly and easily and even handle the peak volume of PPP, which was exponentially higher than anything we had ever done on the platform. That was not a problem for us. Where we had to scale is in two areas, one from a technical standpoint was how we were interacting with our technical partners.

+ +

I mentioned already the need to govern how we were submitting applications to the SBA. We worked very closely with DocuSign to essentially put rate caps on how many documents we were generating at any given time and essentially spread the volume because none of us had dealt with that or dealt with that kind of volume before. And that's where we had technical challenges were in the interfaces and working with partners to make sure everything lined up well. So that was one area, got through it pretty well. And ultimately, like I said, for the second round, we were smooth sailing.

+ +

The other area to your point around standing up all the banks was how we implemented the customers. Our typical implementation cycles going into the pandemic were multiple months. We had to stand up all over the PPP banks in less than two weeks. And so that took a combination of...I'll call it technical delivery. So we essentially created a cookie-cutter deployment and then used a deployment strategy to push that to all of the new customers all at once that we didn't have before. And we were able to create that relatively quickly.

+ +

The other was we had to take a much harder stance with our customers than we had ever done around look; everyone's getting the same thing. It's government-mandated anyway, but it's going to be exactly the same. And other than the white-labeling that we, of course, gave everybody, you might want slightly different process around the workflow, around the approval.

+ +

You're going to have to take the same thing that everybody else is because we just don't have time to configure the nuance across 100 banks. And so luckily, to your earlier comment around, everybody just realized we were in this unique time, we do what we have to do, and we got through it. Our banks were very willing to do that. But that was the other change we had to do to really see this scale through.

+ +

Mid-Roll Ad:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff

+ +

CHAD: If you're comfortable talking about architecture a little bit, do you have a shared sort of platform that everyone is on? Or, for each of the customers you have, do they have their own instance?

+ +

ADAM: So we've made the decision, mostly because of our regulated industry; we felt like it was safer, so each customer gets their own database. We do keep everyone's data completely isolated to protect their information and give them the utmost confidence that it is protected. But we have a shared application layer. And so, our web servers are shared multi-tenant instances. And so it's essentially a combined environment where we're both sharing some resources but then also deploying individual databases and then the configuration because outside of PPP, it is unique bank by bank. And so, the configuration gets deployed within each bank's individual environment.

+ +

CHAD: Cool. I've worked on systems like that before, and they can certainly present...especially when you need to scale them quickly, and you've got a lot of new customers being added. You better hope that it's been automated. [laughs]

+ +

ADAM: Yes. And luckily, we had a good amount of automation in place during PPP or even going into it, I should say, but of course, PPP stretched that. And so we've just continued to get better and better as a couple of years have gone by.

+ +

CHAD: So the second PPP came through. It's in the forgiveness period now, so that's winding down. So Numerated were at that point you alluded to earlier, which is when you were doing PPP, you realized it's not going to be around forever. Let's lay the groundwork now to help customers in the future. We're sort of at that point now, right?

+ +

ADAM: Yes.

+ +

CHAD: So what does that look like for you?

+ +

ADAM: So it's essentially expanding the portfolio of loans that our customers can leverage our platform to execute. And maybe to say that better, if you look back prior to PPP, we got our start with small small business lending. And what I mean by that is loans under $250,000 that can be highly automated. That's where Numerated got its start working with Eastern first 15 customers, saw the value in getting extreme efficiency and delivering essentially capital to their businesses in a number of days instead of weeks.

+ +

That's what we were great at, very similar to what PPP was, by the way, which was getting money to people in a number of hours in some cases. But we knew that that was never the vision for what we wanted to be or what our banks needed in the business banking segment. Ultimately, they want that same level of use efficiency experience for all of their business loans. But in order to support that, there are a number of capabilities that we needed to build into our platform to handle that.

+ +

Underwriting gets increasingly complicated when you are underwriting loans at 500,000, a million, or $5 million. The businesses get more complicated. The collateral gets more complicated. The entire process just becomes more sophisticated. But that's what banks want, and by the way, that's what businesses want. They don't want to have a great experience when they're a little bit smaller, and they've taken out a $100,000 loan and then have the experience be crap two years later when they come back, and they've taken out a million-dollar loan. And so, that has always been our vision.

+ +

We've had the fortune of being able to do really well on PPP and essentially just accelerate that vision. And so that's what we're working on right now is really building a loan origination system that allows our customers to transform how they lend to businesses in entirety. We have been building out all of the sophistication I mentioned around underwriting.

+ +

We have recently acquired a company called Fincura based out of the Boston area. They automate spreading. If you're not familiar with what spreading is, it basically takes either paper or PDF versions of a bank's financial statements, and it turns them into really critical financial ratios that help banks understand the creditworthiness and the risk associated with the business. So you can imagine what that is.

+ +

It's taking OCR, technology, AI, and basically taking what were PDFs and converting them into scores that can then be used to automate and drive efficiency in the credit decision, again, all part of being able to then really transform how banks are doing all of their business lending. But that's what we're working on now, converting all of the PPP customers to use the non-PPP, for lack of a better phrase, parts of the platform and really helping them change how their businesses look at them in terms of the opportunity to access credit.

+ +

CHAD: So I think it's probably worth noting you made the decision to join Numerated right before the pandemic hit.

+ +

ADAM: That's correct.

+ +

CHAD: And so you joined when?

+ +

ADAM: My last day at my previous company happened to be the day we closed the office due to the pandemic. I had obviously made the decision prior to that. But then, my first day on the job at Numerated was the second day of PPP. So essentially, you know, call it a week after everybody had gone home for what became the better part of the next year to two years.

+ +

CHAD: So I assume making a decision to join a new company, you're going to be the chief product officer. You've had a lot of conversations about what the vision is and what you're going to do. And you're going into a business where hey, there are 17 customers, and we're going to scale. But you probably didn't guess what was going to happen ended up happening.

+ +

ADAM: No. [laughs]

+ +

CHAD: So I imagine like part of your vision for what you were going to do both as a company and as an individual must have gotten put on hold.

+ +

ADAM: It's funny, yes and no. So I will say no to your lead in there. There were certainly times before I started where I was calling Dan our founder and CEO. And I was probing him and pushing him like, is this still a thing? [laughs] Are we really going to go do this? Not realizing what PPP was and really what it was going to mean for our business. So there was that period of time where I wasn't sure. I knew it was going to be different, but I didn't know what that meant yet.

+ +

Once I understood what was happening and what we were doing, I actually never felt like it was putting anything on hold. And I can come back to the fact that it put some elements of our business on hold. But for me and why I joined and the vision I had, I was coming to help the team really expand what the platform could do for banks and their business customers and to accelerate the number of ways we could help. I have prior experience working at Capital One and Pegasystems with a lot of the systems and the processes that we were helping to reinvent at Numerated.

+ +

And so, my vision was always to come and build off of those past experiences and accelerate what we were doing in this specific small business segment. PPP, in a lot of ways, just accelerated that. It took what would have probably been three to five years’ worth of market adoption in terms of understanding what digital transformation was going to look like, getting customers fully comfortable with a more digital experience, getting comfortable with a more data-driven approach to decision-making. And the pandemic forced all of that to happen in weeks.

+ +

CHAD: Well, people couldn't even go into the bank to turn in their paperwork. It had to be done remotely. The staff wasn't there either.

+ +

ADAM: And the staff no longer could look at paper financial statements because they couldn't get paper financial statements. And so everything changed overnight. One of our customers has told us at multiple customer events since he's like, "You guys, you let the rabbit out of the hat, and it's not going back." It just changed overnight what was happening in the industry. And then, for us, it gave us all of this extra opportunity to invest and invest more in what we wanted to go do.

+ +

Our team, when I joined, was about 40 to 45 people. Our team now is 145 people. And our engineering team went from a little over 20 to just under 60. So we have exponentially changed the rate in which we're innovating and going after things. And so, for me, it's just accelerated and made things more exciting. The one other comment I'll make in terms of putting things on hold it did put some elements of the business on hold because every one of our customers stopped thinking about what I'll call traditional business lending and focused 100% for the better part of 18 months on getting through the pandemic.

+ +

And even once PPP was done, there was another six to nine months where banks were trying to figure out, are we really out of the pandemic? Are we ready to start lending the way we used to? Do we need to rethink risk? Because these businesses are all different now than they were two years ago. The things that made a business risky two years ago are different now.

+ +

And so there was also a little bit of a hangover as our customers internalized within their own walls what it meant to get back into lending. And so, it did put some elements of that on hold. We were fortunate, though, that we grew so much through PPP. And we actually kept adding what I'll call core customers, not just PPP customers, during that period that our growth actually accelerated. And it's been really good for us.

+ +

CHAD: That's great. You mentioned the team growth that you've had. Different companies are organized in different ways. As Chief Product Officer, where do you sit within the organization and relative to the engineering team?

+ +

ADAM: So at Numerated, my responsibility includes all of the product management as well as the engineering organization. So I'm responsible with my teams for everything from initial product strategy, the product design. I have all of the UX and design team as well as then all of the execution, the delivery of the platform as well.

+ +

CHAD: So does that mean that there's VP of engineering in your organization or some sort of person like that that's working closely with you?

+ +

ADAM: Sort of. So I have...basically, it divides more at the director level. So I have a couple of VPs that work for me that have a combination of product and engineering, both experience, expertise, and responsibility. But then their teams have product managers, and then we have directors of engineering that then manage their individuals from teams. I also have a group of former bankers. They're product managers but act as consultants to those organizations. And that's where we get all of our industry expertise. They've worked with the SBA. They've worked in credit offices, and they really help to influence the product roadmap across those teams as well.

+ +

CHAD: So the entire engineering structure also being under the chief Product Officer, I would say that and correct me if I'm wrong, I think that's probably not how the majority of companies organize it. Do you agree with that?

+ +

ADAM: I have seen both, but I would agree that it is not the majority.

+ +

CHAD: I would say if there is a majority, and I agree, I've seen both too, but you might have a CTO and then VP of engineering. And so, the engineering organization goes all the way up to the C-level. And then there's a Chief Product Officer. And here's the product management and product underneath them. Was this an intentional choice from the beginning as you scaled out the team for you to have it all live under you?

+ +

ADAM: It was intentional. I will give my personal view on it. I think that as we continue to evolve as technology companies, one of the hardest things for us to achieve is alignment around vision and purpose. And that drives a level of focus that I think maximizes the ability to move the business forward. And based on that premise, the places where I've seen things work the best is when there is a focal point across product and engineering within specialization underneath. Because it drives, I think, the best alignment across the organization.

+ +

I will acknowledge, however, that finding leaders that can actually operate effectively in that combined role is extremely difficult because you need people that have a high degree of engineering experience so that they actually know how to build for quality, build for scale, even for things that don't immediately impact the bottom line while having enough business acumen to understand the demands of the business and how to balance those priorities against what we need to grow the business at the same time.

+ +

And so, it does create a little bit of a snowflake challenge. I cannot find or replace those roles as we grow and scale nearly as quickly as I can in a divided organization. But I have found that it does help me drive clarity of priorities and purpose and ultimately focus in the organization versus the places I've worked where that hasn't been the case.

+ +

CHAD: So I guess given that, then I assume you're hiring. [laughs]

+ +

ADAM: We are always hiring. [laughs] We are definitely in growth mode. And we are looking for great people that can help us to build a platform and really transform how our customers are thinking about how they lend to their businesses.

+ +

CHAD: Well, I agree. I think there are different structures then that can achieve it. And also, a lot of it comes down to the people but that alignment and that understanding of design, and product, and development or engineering. And ideally, people and all of those skill sets and all those teams who get it and can balance those different priorities with the business is really important, and that alignment of vision. And so there are probably different structures to get it, but that's what you're aiming for. And I think that the structure that you've set up is one which is very helpful to getting that alignment.

+ +

ADAM: Agreed. Agreed. I think that while we're on the topic of the team and the culture we're trying to build out, I'll maybe use that as a way to share a few more things that we're really driving towards. You can imagine a company that has scaled the way we have and continues to grow. That presents some other organizational challenges as well. One of my firm beliefs is the fastest way to scale is to create really strong, empowered, decentralized teams. That, again, gets back to the whole vision and focus thing. They have to be rowing in the same direction. But they have to be really independent in the day-to-day.

+ +

And so we've really spent a lot of time over the last, I would say, year and a half shifting to that kind of a model to where each of the teams is really embracing what their individual accountabilities are. They are really focused on how they're delivering success for the business and are able to make a lot of the day-to-day decisions. But then it falls to management, leadership, myself to make sure that when they make those decisions, they understand the context in which we're trying to drive the business so that we can do as much as we can as fast as we can but in a way that's high quality and delivers value.

+ +

CHAD: Awesome. Well, I sincerely wish you all the best in that. I really appreciate you stopping by and sharing. Thank you.

+ +

ADAM: Yeah, my pleasure. I appreciate the time, and good to get to know you a little bit, Chad.

+ +

CHAD: If folks want to find out more, maybe apply, follow along with you; where are all the places that they can do that?

+ +

ADAM: Yeah, sure. So numerated.com is where they can go and learn more about the business, and they can learn more about where we're hiring. People should check me out on LinkedIn. That's probably where I'm the most active these days. And feel free to message me as well. I'll also give you my email address if anybody wants to reach out. It's pretty simple. It's adam@numerated.com. Whether it's opinions, thoughts, or reactions to anything that I've shared today, or you just want to build a relationship, I'd love to hear from people and get to know you a little bit better.

+ +

CHAD: Wonderful. You can find links to all those things, probably not Adam’s email address, in the show notes.

+ +

ADAM: [laughs]

+ +

CHAD: We want to protect him from those spam crawlers. But you can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Adam Kenney.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Adam Kenney is Chief Product Officer at Numerated, which helps banks and credit unions transform how they lend to businesses.

+ +

Chad talks with Adam about what institutional banks and credit unions are like as a market and customers and what sales cycles look like, going from 17 to more than 130 customers quickly, and the scaling challenges they faced, and how the pandemic affected them as a company.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me, today is Adam Kenney, Chief Product Officer at Numerated, which helps banks and credit unions transform how they lend to businesses. Adam, thanks so much for joining me.

+ +

ADAM: Thank you, Chad. Thanks for having me.

+ +

CHAD: Let's dive into Numerated a little bit more. How do you help banks and credit unions lend to businesses?

+ +

ADAM: I think we're in the middle of what is a pretty meaningful transformation in terms of how businesses are expecting to get access to credit. Really what they want is something that is fast, easy, convenient, largely driven off of the change that has happened in the retail space over the last 10 to 15 years. And in many ways, business lending is still catching up to that, and so our focus is doing that. It's helping the banks and credit unions really change how they interact with their business customers. We use a combination of data and great experiences to make that process as seamless as possible.

+ +

We've been noted to, using the combination of data and technology, help banks increase the number of loans that they can do with their existing staff by as much as fourfold. We are also noted for inventing what we like to refer to as the three-minute business loan. It's one of the things we were written up on in the Wall Street Journal back in our days in Eastern Labs, where we've been able to get businesses from the point of application all the way to a funded loan in less than three minutes. And that's a process that historically has taken as long as three weeks.

+ +

And so really excited by the ways that we're able to really help change how banks themselves can look at their operations. But more than anything, it's how banks are able to rethink and change how they interact with businesses and help the businesses in your communities grow and get access to the credit that they need.

+ +

CHAD: So from a digital product perspective, there's a piece of a product there that banks are actually taking on and white-labeling that provides a lending experience for their clients, right?

+ +

ADAM: That's correct. I mean, we're a cloud-based SaaS system. But you're right; they branded as their own. And so if you're going to Eastern Bank's website and clicking through and ultimately going through the application process with us, it's going to look and feel like it's just Eastern's website. And all of the interactions that you have with Eastern or any of our customers are going to feel that way as well. So yes, it is a white-label solution that we sell to the banks, and they provide to their customers.

+ +

CHAD: The actual banking industry is not one that I've had a lot of experience in. And so I'm curious what institutional banks, credit unions, that kind of thing what they're like as a market or as customers and what the sales cycle looks like and those kinds of things.

+ +

ADAM: It's about as varied as an industry can get, I'll tell you that. [laughs] You have to remember that banks and credit unions can be as small as having a few hundred million dollars in assets, maybe as small as 100 million. And in some of our customers' cases, they're de novo banks, and they're just getting started. And they range up to multiple billions of dollars in assets. And so, these are organizations that scale dramatically. Each of them have their own problems.

+ +

They're also going to be made up of very different tech-minded individuals. You're going to have some smaller institutions that are basically managing a book of business that's been a book of business for close to a century and are interested in how technology can make them more efficient. But they are not the technologists that you and I would be used to working with on a day-to-day basis. And then, of course, you have people like ourselves who are really trying to, from inside the bank, change what banking is to their customers. And so, it's a very diverse industry in terms of what they're looking to accomplish.

+ +

We've even come up with recently this framework around how we think about and really talk to our customers about how they transform and the levels of transformation that they can go through. And for us, it's essentially a four-level transformation starting with very small and pointed technology innovations that allow them to drive innovation in very fragmented bits and pieces, for lack of a better term, up to and including they're going to transform everything or become a digital bank. And you can imagine there are lots of stops along the way in terms of where a bank is and where they want to end up as part of their strategy.

+ +

CHAD: From a product perspective and managing change, do you get a lot of custom features from individual, either clients or potential clients? And how do you manage that if you do?

+ +

ADAM: The way I think about it is that we certainly get a lot of requests from our customers, and every customer likes to think that they are different and unique. In reality, there's a strong theme to almost all of the requests that we get. And personally, I think that's part of what our job is as a product leader is to really understand how to create themes out of the individual requests and provide a platform back to the market that addresses as many of those in a more holistic way and drives value across not just the individual asks but across all of the customers. And so yeah, there's some uniqueness. And certainly, we need to provide a platform that allows for that.

+ +

So as an example, every bank has a slightly different view into how they want their credit policy to work and be implemented, but the framework around how you make credit decisions, how I get data into the platform. How do I create a credit matrix? And how do I then decide the exact offer terms to drive out of that? Like, that's a standard capability. And so we're innovating on that based on the individual features, but it's really not with an eye towards providing a specific custom feature to individual customers. It's more providing a flexible platform that allows them to configure the nuance but in a general theme that's going to help them be a better business.

+ +

CHAD: So in the U.S., we had a specific program launched, PPP loans, in the pandemic to help support businesses. And I know thoughtbot we participated in that and went through that process. I don't think our bank was using Numerated. But I know that the bank really maybe...because they weren't using Numerated, [laughs] they needed to bring together an entirely new application interface very, very quickly in order to be able to take our application to that. And I think that Numerated was right there at the start of that.

+ +

ADAM: Yes.

+ +

CHAD: Talk about something custom maybe quickly.

+ +

ADAM: [laughs]

+ +

CHAD: What did pulling that together look like?

+ +

ADAM: So maybe to take a step back if I could first and just paint a picture for you because you're right, it was kind of a unique and incredible period of time. We were fortunate in our line of work because we are all about helping banks transform how they lend to businesses. We had the base platform already built and established that allowed businesses to apply for loans on our platform. Even before the pandemic, we were one of the leading technology platforms for processing SBA loans. So we were uniquely positioned for the opportunity as it results to PPP.

+ +

At the start of the pandemic, we had approximately 17 customers using our platform. Fast forward six months later, we had 135. And so, to your point around there were a large number of institutions looking for a new application solution overnight, I think that shows you how aggressively banks needed a solution. And there was an opportunity for us to offer our platform to be that.

+ +

I think the other thing to recognize as part of the backdrop anyway is this was a crazy time if you think back to where we were in the pandemic. No one knew what life was going to look like in a week. And most businesses, especially smaller ones, didn't know if they were going to have a business. And so for us, that also provided the opportunity and maybe a little bit of the confidence in saying, "You know, we have nothing to lose. We're well-positioned. And what else are we going to do? Because it's not like people are making other loans for the next couple of months. Let's just go own this".

+ +

And so I think it was the combination of us making that recognition, having a really good base platform that had familiarity with the SBA, had familiarity with business lending, and with a team that then could really acutely focus on solving this one problem for as many customers as possible. And by the way, have the emotional impact of not only helping banks but knowing that we're basically helping hundreds of thousands of businesses stay afloat through probably the craziest time in our country's history. And so that's really what got us going.

+ +

And then there was a ton of work to your point around customization around building out the platform. But the one thing we've tried to do from the beginning is hold true to some of the foundational vision that I mentioned earlier. Like, we don't want to be in the business of custom software. That's not a winning proposition for us or our customers. And so, as much as it was maybe hard at times, throughout PPP, we were always thinking about okay, so we have to make these changes to support this crazy never-before-seen lending program.

+ +

But how can we do it in a way that's going to set us up to serve the businesses in a year or two when this whole pandemic thing is over? Because PPP is not going to last forever, but our customers are. The businesses are still going to need credit. So whatever we're doing as much as possible, let's be building a foundation that gets us well beyond PPP. And so we were using it as really a catalyst to build a bigger business even while we were helping customers through the pandemic.

+ +

CHAD: One of the things that I really appreciated, and I have an outside perspective on it, but I really...and people can always do better.

+ +

ADAM: Yes. [laughs]

+ +

CHAD: But I thought it was one of the rare circumstances where everyone realized the urgency of the situation: government, banks, everybody. And there was a real willingness to realize, well, we've got to do something. If we try to figure it out all right now, it's going to take too long. So let's just do something, and we'll work out the details later. And so I think there was a willingness, and from a product perspective, my guess would be that allowed you to work iteratively too.

+ +

ADAM: It did. It was [laughs], I think in some ways a blessing and a curse.

+ +

CHAD: [laughs]

+ +

ADAM: Because I can tell you that the number of times my team would get a set of new capabilities, which listen, were great for the customers. It made everything better for the businesses that needed help, so I would never want it any other way. But the number of times that those new capabilities were announced by the SBA on a Friday night and were expected to be live on Monday morning, let's just say it was more frequent than I would ever like to relive. [laughs]

+ +

And I can remember, especially going into the second round of PPP, it just so happened that all that was happening between Thanksgiving and Christmas in a year where all families wanted to do was spend time with each other after a crazy year had gone by. But we didn't get that luxury, unfortunately. We had a job to do, and that was to make sure that we were ready for the next round. And so it did come with a lot of cost in terms of we had to work really hard to make it happen.

+ +

But to your point, it allowed us to iterate. And I give the government credit, too, particularly the SBA. They could have, for example, just launched the program and then launched more money into it and stood still, but they didn't do that. To your comment, they had to get live as quick as possible. And so that first round of PPP, there were more technology hiccups. The SBA had some volume constraints. They couldn't really handle the performance. We ended up having to govern our application submissions because otherwise, the SBA couldn't handle it.

+ +

There were other challenges in terms of how we were validating data. But that got better month by month. And certainly, by the time we got to the forgiveness part of the process and then the next round of PPP the following winter, they actually invested in completely ripping out their legacy API and providing us in the tech community a modern RESTful interface that was much easier, much more performant. And so, even though the volume got even crazier as we went through the program, it actually became easier for us to deliver.

+ +

The first round, we were literally working around the clock because the SBA was having issues. We couldn't get enough documents through DocuSign and whatever else. We did, I want to say, close to 3 times the volume in the next round a year later but at about 15% of the energy because we had just improved that much in less than a year. And it wasn't just Numerated; it was Numerated working with our partners in government and elsewhere to just get the process that much smoother for our customers.

+ +

CHAD: Were there things that you needed to do at Numerated? I mean, to go from 17 customers to more than 130 that quickly, I assume that there were some scaling challenges for you along the way.

+ +

ADAM: There was. And I will say this: we were blessed to have a really good technical infrastructure in place that allowed us to scale on the infrastructure side without a ton of problems. We were able to essentially stand up new environments in our infrastructure relatively quickly and easily and even handle the peak volume of PPP, which was exponentially higher than anything we had ever done on the platform. That was not a problem for us. Where we had to scale is in two areas, one from a technical standpoint was how we were interacting with our technical partners.

+ +

I mentioned already the need to govern how we were submitting applications to the SBA. We worked very closely with DocuSign to essentially put rate caps on how many documents we were generating at any given time and essentially spread the volume because none of us had dealt with that or dealt with that kind of volume before. And that's where we had technical challenges were in the interfaces and working with partners to make sure everything lined up well. So that was one area, got through it pretty well. And ultimately, like I said, for the second round, we were smooth sailing.

+ +

The other area to your point around standing up all the banks was how we implemented the customers. Our typical implementation cycles going into the pandemic were multiple months. We had to stand up all over the PPP banks in less than two weeks. And so that took a combination of...I'll call it technical delivery. So we essentially created a cookie-cutter deployment and then used a deployment strategy to push that to all of the new customers all at once that we didn't have before. And we were able to create that relatively quickly.

+ +

The other was we had to take a much harder stance with our customers than we had ever done around look; everyone's getting the same thing. It's government-mandated anyway, but it's going to be exactly the same. And other than the white-labeling that we, of course, gave everybody, you might want slightly different process around the workflow, around the approval.

+ +

You're going to have to take the same thing that everybody else is because we just don't have time to configure the nuance across 100 banks. And so luckily, to your earlier comment around, everybody just realized we were in this unique time, we do what we have to do, and we got through it. Our banks were very willing to do that. But that was the other change we had to do to really see this scale through.

+ +

Mid-Roll Ad:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff

+ +

CHAD: If you're comfortable talking about architecture a little bit, do you have a shared sort of platform that everyone is on? Or, for each of the customers you have, do they have their own instance?

+ +

ADAM: So we've made the decision, mostly because of our regulated industry; we felt like it was safer, so each customer gets their own database. We do keep everyone's data completely isolated to protect their information and give them the utmost confidence that it is protected. But we have a shared application layer. And so, our web servers are shared multi-tenant instances. And so it's essentially a combined environment where we're both sharing some resources but then also deploying individual databases and then the configuration because outside of PPP, it is unique bank by bank. And so, the configuration gets deployed within each bank's individual environment.

+ +

CHAD: Cool. I've worked on systems like that before, and they can certainly present...especially when you need to scale them quickly, and you've got a lot of new customers being added. You better hope that it's been automated. [laughs]

+ +

ADAM: Yes. And luckily, we had a good amount of automation in place during PPP or even going into it, I should say, but of course, PPP stretched that. And so we've just continued to get better and better as a couple of years have gone by.

+ +

CHAD: So the second PPP came through. It's in the forgiveness period now, so that's winding down. So Numerated were at that point you alluded to earlier, which is when you were doing PPP, you realized it's not going to be around forever. Let's lay the groundwork now to help customers in the future. We're sort of at that point now, right?

+ +

ADAM: Yes.

+ +

CHAD: So what does that look like for you?

+ +

ADAM: So it's essentially expanding the portfolio of loans that our customers can leverage our platform to execute. And maybe to say that better, if you look back prior to PPP, we got our start with small small business lending. And what I mean by that is loans under $250,000 that can be highly automated. That's where Numerated got its start working with Eastern first 15 customers, saw the value in getting extreme efficiency and delivering essentially capital to their businesses in a number of days instead of weeks.

+ +

That's what we were great at, very similar to what PPP was, by the way, which was getting money to people in a number of hours in some cases. But we knew that that was never the vision for what we wanted to be or what our banks needed in the business banking segment. Ultimately, they want that same level of use efficiency experience for all of their business loans. But in order to support that, there are a number of capabilities that we needed to build into our platform to handle that.

+ +

Underwriting gets increasingly complicated when you are underwriting loans at 500,000, a million, or $5 million. The businesses get more complicated. The collateral gets more complicated. The entire process just becomes more sophisticated. But that's what banks want, and by the way, that's what businesses want. They don't want to have a great experience when they're a little bit smaller, and they've taken out a $100,000 loan and then have the experience be crap two years later when they come back, and they've taken out a million-dollar loan. And so, that has always been our vision.

+ +

We've had the fortune of being able to do really well on PPP and essentially just accelerate that vision. And so that's what we're working on right now is really building a loan origination system that allows our customers to transform how they lend to businesses in entirety. We have been building out all of the sophistication I mentioned around underwriting.

+ +

We have recently acquired a company called Fincura based out of the Boston area. They automate spreading. If you're not familiar with what spreading is, it basically takes either paper or PDF versions of a bank's financial statements, and it turns them into really critical financial ratios that help banks understand the creditworthiness and the risk associated with the business. So you can imagine what that is.

+ +

It's taking OCR, technology, AI, and basically taking what were PDFs and converting them into scores that can then be used to automate and drive efficiency in the credit decision, again, all part of being able to then really transform how banks are doing all of their business lending. But that's what we're working on now, converting all of the PPP customers to use the non-PPP, for lack of a better phrase, parts of the platform and really helping them change how their businesses look at them in terms of the opportunity to access credit.

+ +

CHAD: So I think it's probably worth noting you made the decision to join Numerated right before the pandemic hit.

+ +

ADAM: That's correct.

+ +

CHAD: And so you joined when?

+ +

ADAM: My last day at my previous company happened to be the day we closed the office due to the pandemic. I had obviously made the decision prior to that. But then, my first day on the job at Numerated was the second day of PPP. So essentially, you know, call it a week after everybody had gone home for what became the better part of the next year to two years.

+ +

CHAD: So I assume making a decision to join a new company, you're going to be the chief product officer. You've had a lot of conversations about what the vision is and what you're going to do. And you're going into a business where hey, there are 17 customers, and we're going to scale. But you probably didn't guess what was going to happen ended up happening.

+ +

ADAM: No. [laughs]

+ +

CHAD: So I imagine like part of your vision for what you were going to do both as a company and as an individual must have gotten put on hold.

+ +

ADAM: It's funny, yes and no. So I will say no to your lead in there. There were certainly times before I started where I was calling Dan our founder and CEO. And I was probing him and pushing him like, is this still a thing? [laughs] Are we really going to go do this? Not realizing what PPP was and really what it was going to mean for our business. So there was that period of time where I wasn't sure. I knew it was going to be different, but I didn't know what that meant yet.

+ +

Once I understood what was happening and what we were doing, I actually never felt like it was putting anything on hold. And I can come back to the fact that it put some elements of our business on hold. But for me and why I joined and the vision I had, I was coming to help the team really expand what the platform could do for banks and their business customers and to accelerate the number of ways we could help. I have prior experience working at Capital One and Pegasystems with a lot of the systems and the processes that we were helping to reinvent at Numerated.

+ +

And so, my vision was always to come and build off of those past experiences and accelerate what we were doing in this specific small business segment. PPP, in a lot of ways, just accelerated that. It took what would have probably been three to five years’ worth of market adoption in terms of understanding what digital transformation was going to look like, getting customers fully comfortable with a more digital experience, getting comfortable with a more data-driven approach to decision-making. And the pandemic forced all of that to happen in weeks.

+ +

CHAD: Well, people couldn't even go into the bank to turn in their paperwork. It had to be done remotely. The staff wasn't there either.

+ +

ADAM: And the staff no longer could look at paper financial statements because they couldn't get paper financial statements. And so everything changed overnight. One of our customers has told us at multiple customer events since he's like, "You guys, you let the rabbit out of the hat, and it's not going back." It just changed overnight what was happening in the industry. And then, for us, it gave us all of this extra opportunity to invest and invest more in what we wanted to go do.

+ +

Our team, when I joined, was about 40 to 45 people. Our team now is 145 people. And our engineering team went from a little over 20 to just under 60. So we have exponentially changed the rate in which we're innovating and going after things. And so, for me, it's just accelerated and made things more exciting. The one other comment I'll make in terms of putting things on hold it did put some elements of the business on hold because every one of our customers stopped thinking about what I'll call traditional business lending and focused 100% for the better part of 18 months on getting through the pandemic.

+ +

And even once PPP was done, there was another six to nine months where banks were trying to figure out, are we really out of the pandemic? Are we ready to start lending the way we used to? Do we need to rethink risk? Because these businesses are all different now than they were two years ago. The things that made a business risky two years ago are different now.

+ +

And so there was also a little bit of a hangover as our customers internalized within their own walls what it meant to get back into lending. And so, it did put some elements of that on hold. We were fortunate, though, that we grew so much through PPP. And we actually kept adding what I'll call core customers, not just PPP customers, during that period that our growth actually accelerated. And it's been really good for us.

+ +

CHAD: That's great. You mentioned the team growth that you've had. Different companies are organized in different ways. As Chief Product Officer, where do you sit within the organization and relative to the engineering team?

+ +

ADAM: So at Numerated, my responsibility includes all of the product management as well as the engineering organization. So I'm responsible with my teams for everything from initial product strategy, the product design. I have all of the UX and design team as well as then all of the execution, the delivery of the platform as well.

+ +

CHAD: So does that mean that there's VP of engineering in your organization or some sort of person like that that's working closely with you?

+ +

ADAM: Sort of. So I have...basically, it divides more at the director level. So I have a couple of VPs that work for me that have a combination of product and engineering, both experience, expertise, and responsibility. But then their teams have product managers, and then we have directors of engineering that then manage their individuals from teams. I also have a group of former bankers. They're product managers but act as consultants to those organizations. And that's where we get all of our industry expertise. They've worked with the SBA. They've worked in credit offices, and they really help to influence the product roadmap across those teams as well.

+ +

CHAD: So the entire engineering structure also being under the chief Product Officer, I would say that and correct me if I'm wrong, I think that's probably not how the majority of companies organize it. Do you agree with that?

+ +

ADAM: I have seen both, but I would agree that it is not the majority.

+ +

CHAD: I would say if there is a majority, and I agree, I've seen both too, but you might have a CTO and then VP of engineering. And so, the engineering organization goes all the way up to the C-level. And then there's a Chief Product Officer. And here's the product management and product underneath them. Was this an intentional choice from the beginning as you scaled out the team for you to have it all live under you?

+ +

ADAM: It was intentional. I will give my personal view on it. I think that as we continue to evolve as technology companies, one of the hardest things for us to achieve is alignment around vision and purpose. And that drives a level of focus that I think maximizes the ability to move the business forward. And based on that premise, the places where I've seen things work the best is when there is a focal point across product and engineering within specialization underneath. Because it drives, I think, the best alignment across the organization.

+ +

I will acknowledge, however, that finding leaders that can actually operate effectively in that combined role is extremely difficult because you need people that have a high degree of engineering experience so that they actually know how to build for quality, build for scale, even for things that don't immediately impact the bottom line while having enough business acumen to understand the demands of the business and how to balance those priorities against what we need to grow the business at the same time.

+ +

And so, it does create a little bit of a snowflake challenge. I cannot find or replace those roles as we grow and scale nearly as quickly as I can in a divided organization. But I have found that it does help me drive clarity of priorities and purpose and ultimately focus in the organization versus the places I've worked where that hasn't been the case.

+ +

CHAD: So I guess given that, then I assume you're hiring. [laughs]

+ +

ADAM: We are always hiring. [laughs] We are definitely in growth mode. And we are looking for great people that can help us to build a platform and really transform how our customers are thinking about how they lend to their businesses.

+ +

CHAD: Well, I agree. I think there are different structures then that can achieve it. And also, a lot of it comes down to the people but that alignment and that understanding of design, and product, and development or engineering. And ideally, people and all of those skill sets and all those teams who get it and can balance those different priorities with the business is really important, and that alignment of vision. And so there are probably different structures to get it, but that's what you're aiming for. And I think that the structure that you've set up is one which is very helpful to getting that alignment.

+ +

ADAM: Agreed. Agreed. I think that while we're on the topic of the team and the culture we're trying to build out, I'll maybe use that as a way to share a few more things that we're really driving towards. You can imagine a company that has scaled the way we have and continues to grow. That presents some other organizational challenges as well. One of my firm beliefs is the fastest way to scale is to create really strong, empowered, decentralized teams. That, again, gets back to the whole vision and focus thing. They have to be rowing in the same direction. But they have to be really independent in the day-to-day.

+ +

And so we've really spent a lot of time over the last, I would say, year and a half shifting to that kind of a model to where each of the teams is really embracing what their individual accountabilities are. They are really focused on how they're delivering success for the business and are able to make a lot of the day-to-day decisions. But then it falls to management, leadership, myself to make sure that when they make those decisions, they understand the context in which we're trying to drive the business so that we can do as much as we can as fast as we can but in a way that's high quality and delivers value.

+ +

CHAD: Awesome. Well, I sincerely wish you all the best in that. I really appreciate you stopping by and sharing. Thank you.

+ +

ADAM: Yeah, my pleasure. I appreciate the time, and good to get to know you a little bit, Chad.

+ +

CHAD: If folks want to find out more, maybe apply, follow along with you; where are all the places that they can do that?

+ +

ADAM: Yeah, sure. So numerated.com is where they can go and learn more about the business, and they can learn more about where we're hiring. People should check me out on LinkedIn. That's probably where I'm the most active these days. And feel free to message me as well. I'll also give you my email address if anybody wants to reach out. It's pretty simple. It's adam@numerated.com. Whether it's opinions, thoughts, or reactions to anything that I've shared today, or you just want to build a relationship, I'd love to hear from people and get to know you a little bit better.

+ +

CHAD: Wonderful. You can find links to all those things, probably not Adam’s email address, in the show notes.

+ +

ADAM: [laughs]

+ +

CHAD: We want to protect him from those spam crawlers. But you can subscribe to the show and find notes along with a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Adam Kenney.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+BTQuQENB + + ]]> + + Chad Pytel + Adam Kenney + + + 434: SOS with Susanna Twarog + https://podcast.thoughtbot.com/434 + 43bfb560-975d-4efa-afa1-29306f4c4b8d + Thu, 04 Aug 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Susanna Twarog is Co-Founder and Co-CEO of SOS, which is transforming wellness on the go through a network of smart vending machines that deliver just-in-time necessities where and when you need the most. + +Chad talks with Susanna about wellness on the go, the unique business that they're building and what SOS can offer brands, and the biggest hurdles to overcome to get 10,000 machines up and running. + 29:59 + no + + + Susanna Twarog is Co-Founder and Co-CEO of SOS, which is transforming wellness on the go through a network of smart vending machines that deliver just-in-time necessities where and when you need the most. +Chad talks with Susanna about wellness on the go, the unique business that they're building and what SOS can offer brands, and the biggest hurdles to overcome to get 10,000 machines up and running. +SOS (https://www.worldofsos.com/) +Follow SOS on TikTok (https://www.tiktok.com/@world_of_sos), YouTube (https://www.youtube.com/channel/UCzJ_tp6e-M39_6I53xKTu8A), Instagram (https://www.instagram.com/world_of_sos/) or LinkedIn (https://www.linkedin.com/company/world-of-sos/). +Follow Susanna on LinkedIn (https://www.linkedin.com/in/susanna-twarog-2b483ab/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Susanna Twarog, Co-Founder and Co-CEO of SOS, which is transforming wellness on the go through a network of smart vending machines that deliver just-in-time necessities where and when you need the most. Susanna, thank you for joining me. +SUSANNA: Thank you, Chad. It's great to be here. +CHAD: So, what makes the vending machines from SOS smart? +SUSANNA: So what makes our vending machines smart? Well, I think smart and vending are typically not words that go together. And I think when we founded the company, the machines that we were looking at were outdated and old and out of stock. And to be honest, first and foremost, payment methods that are accepted by most vending machines are completely not in line with the modern consumer. +So we were looking at vending machines that take quarters and cash. And as two working women on the trading floor, nobody has quarters or coins or even cash anymore. So first and foremost, we are a cashless, modern vending machine that accepts contactless and modern forms of payment. +CHAD: Let's level-set a little bit about wellness on the go, what that means. What I hear when I look at...which I took a look at the product on the website, which I encourage people to do, and it's worldofsos.com. I think it gives a much better sense of this. But correct me if I'm wrong that what we're talking about here is the vending machines that might typically be in a men's or women's restroom. Is that right? +SUSANNA: Absolutely. So the problem that we are in a mission to solve is to transform outdated, completely broken, ugly hardware that's existed to distribute wellness essentials like menstrual care and other wellness products in public spaces. So those old machines that look like steel box drops [chuckles] that is the business or the distribution channel that we're looking to disrupt. And so, by introducing beautiful design-first tech-enabled hardware into this space, we're completely transforming a distribution channel that has not worked or served anyone for decades at this point. +CHAD: I don't even use those vending machines. But it seems to me like they're often broken, dirty, not even stocked. Is there market reasons why that's the case? +SUSANNA: So, to be quite honest, I think Robina and I, when we founded the company, started to explore why hasn't this problem been solved? And the fact of the matter is the built world, and a lot of commercial real estate is designed and developed by a group of people who don't necessarily menstruate or need these products that are everyday health and wellness essentials for actually what is over half of the world's population. +But the folks who design and plan these spaces are not necessarily coming at the design with a perspective of these needs. And so, honestly, Robina and I set out on a mission to say when we think about inclusive space and the world that we want to live in, we want to live in a world where not just among certain people but all people have access to health and wellness products that they need when they're not at home. +So you may have everything that you need and want from the brands that you love and the ingredients that you trust in your own cabinet. But when you're on the go, and you're at work or you're traveling or entertaining, or spending time in other physical spaces that aren't your home, typically, those products aren't available, and they're very hard to access. So it's a major area for us to innovate and introduce a world that we want to live in where you can access the products you need from brands you already know and love or want to discover and try. +CHAD: So building really any hardware, and I have a lot of guests who have done hardware in the past, can be a challenge, especially starting out. What you talk about in the startup industry is often like starting out small, figuring out the minimum viable product, bringing that to market to early customers, and then learning and refining. And that can be difficult to do when you're shipping something physical. So how did you approach that? +SUSANNA: Robina and I approached this with a lot of intention and a lot of thought. We came from finance, business development, and sales backgrounds. Neither of us are engineers. So when we decided that we were going to found SOS and started to literally sketch out renderings for the type of hardware and design that we wanted to see in the world, initially, we were faced by a lot of people telling us to white-label products that already existed. You know, maybe don't invest in proprietary hardware or designing it yourselves. Try something that already exists. See if there's a product-market fit. +And ultimately, we actually invested in and began to work with an industrial design firm from the beginning. We have seven global design patents on the hardware because we knew that without an elevated design-first piece of hardware, the network would not be well-received, would not be able to grow and exist in the places we knew it needed to be, so to be in grade A commercial real estate where hundreds of millions of dollars are spent on designing and innovating into the built world to make these spaces cutting edge and tech-enabled. +And yet, if we didn't do the same with our hardware, this would just be another vending machine that got relegated to the basement or the back room, and that is not the company that we set out to build. We want to be a piece of integrated, exciting, engaging hardware and tech-enabled experience in these spaces. And so, to do that, we had to forge the path of bringing in and working with and basically investing our own money into designing a proprietary piece of hardware that could deliver the experience we knew was so integral to driving value for the company. +CHAD: I assume that wasn't easy or cheap. Did you fundraise at that point to do it? Or when you say your own money, were you literally the two of you investing yourselves? +SUSANNA: Absolutely. A big point of pride for me and Robina is that from the moment we founded the company through, to be quite honest, I would say the first 18 months of work, we invested our own personal savings. And this wasn't trust fund money that we'd inherited. This was truly just personal savings as young women in finance that we'd put aside, and it was the most money that either of us had ever spent on anything, was investing in ourselves and our own company. So we started...our first investments were in legal work and doing the patent search, and generating ultimately what has now been granted as seven patents for the company. +So patent work was the first money we spent, and then also engaging with an industrial design firm to get our concept into CAD rendering and identify the first contract manufacturer that we worked with on the prototype. So we were able to get pretty far prior to fundraising with our own investment. And trust me, it was a big commitment from both of us. And I think the fact that as co-founders being totally in lockstep with taking some of the biggest financial risks that either of us had ever taken and doing it together, and really having equal passion and commitment and belief in what we were going to build was an exceptional part of our founding story. +CHAD: I imagine you were probably a little nervous, the two of you. [chuckles] +SUSANNA: You know, it felt just like we had to do it. And I think it's kind of like lightning struck in the sense that we had this moment. And from literally the moment that we stepped aside and started to map out the business, there hasn't really been a pause or self-doubt in the sense that we've really known we're going to take this as far as we possibly can. So scary, yes, but it felt like we had the conviction from the very beginning, which I know is rare and not everyone's founding story. But for us, it really was 100% the right thing to do at the time, which was we're going to make this happen. +CHAD: So where did you and Robina meet? +SUSANNA: So we met as colleagues first and foremost. So we were two, I would say at the time, young women working in finance, and she was my counterpart. So she had a role in London, and I was in Boston. And we worked on our basically sales and business development pipelines together as colleagues first. And ultimately, Robina relocated back to the U.S, and we became friends on the same trading floor. So really, it was a friendship that grew out of a business relationship. +CHAD: Do you remember when and where this idea first came from? +SUSANNA: Sure do. [chuckles] It's very close to my heart. I was in the middle of a workday faced with a frustration and inconvenient situation where I couldn't find products that I needed when I needed them at work. And it was interrupting my day for the millionth time. And you know those moments when you have a friend, and you choose the person that you run to when you are, I guess, pissed off for lack of a better word? [laughs] And we just took that moment of me saying, "This is insane. How am I dealing with this? I can't get a tampon when I need one." And our eyes lit up. And we said, "Ah, well, this is a common problem for a very important segment of the world. And we need to do something about it." +CHAD: Now, it's a big leap to go from that frustration to founding a company together and actually working on it. So, how did that happen? +SUSANNA: So we had that moment, and we stepped aside and said, "This is completely insane. I'm too valuable to be wasting my time worrying about this on a daily basis." And the other fun part of our relationship is that we're also two young women with disposable income. We love products; we love travel, we love entertainment. We like to have fun. We work hard; we play hard. +I'm taking those two perspectives, which is like this frustration and universal need combined with consumerism. And this desire to make money, spend money is like combining the two and saying we have an opportunity to capitalize on this need and this consumer at the same time to deliver on a mission and drive value and consumer value for brands at the same time. And that really, I would say, sparked a tremendous amount of excitement and interest from Robina and myself. +How incredible to have an opportunity to build a company that is really driving good, and changing the world, and elevating access to these essential products while also tapping into this consumer interest of ours in products, and brands, and emerging indie brands, and digital content, and tech. And combining them all into one company and doing so with a lot of, I would say, excitement, and optimism, and win-win-win. Making the world a better place fulfilling a passion and interest of ours at the same time and driving value, and building a company. +CHAD: How far along were you in the idea stages, the legwork stages, before you both quit and started working on it full time? +SUSANNA: Took the leap. Yeah, that was a really critical decision and part of our journey. We were very intentional about taking the business as far as we could while protecting our personal financial interests in the sense that, you know, retaining benefits, positioning ourselves so that the company would have the most ability to succeed. And so we actually got through to basically 2020 when we were launching our first machines before we quit and ultimately joined our Techstars Boston 2020 program. +So we were, I would say, nights and weekends absolutely killing ourselves with work. We were able to raise our seed round, our pre-seed round technically, while still employed at the bank. And I would encourage others who are thinking about starting companies to maybe...in some cases; I'd say do what we did. And in other cases, I'd say it might kill you. +CHAD: [laughs] +SUSANNA: But I feel like whether we liked it or not, it put us in a position where we had achieved a tremendous amount of traction. We had our prototypes built and ready to be installed. And they were literally going into some of the most prestigious physical, commercial real estate locations in Boston as we were quitting. So I would say we were taking quite a bit of risk still. But we'd done everything we could to protect the company and make sure that we could get SOS where it needed to be before joining and coming on full-time. +CHAD: How did you find those first places where the machines were going to be installed? +SUSANNA: From the beginning, it was one of the areas of the company that we invested the most of our time in, which was that we had extensive contacts and relationships in financial services; that was our background. We had to start from scratch networking, and telling our story, and telling our vision with commercial real estate partners. +So pre-product, first slide decks, first cold calls, and warm introductions all really focused on commercial real estate. So we gave ourselves a crash course in real estate owner-managers, who the national players were, and started to network a ton, which was just LinkedIn, asking for introductions, having some meetings that were successes, having others that weren't. +But really, I think Robina and I had a and have a very, I guess, strong sense of salesmanship, I would say. That's a strength of ours. And so we were able to really get people excited and to believe in us and not to say sell smoke and mirrors, but we were waiting on a physical product prototype to arrive. And we were able to get believers and commitments before we actually had the product ready to demo in the market. +Mid-Roll Ad: +As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. +We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. +We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. +Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode. +CHAD: So you already said at the beginning of the show your product is targeted or primarily for people who menstruate, and not a lot of property, commercial real estate developers, that kind of thing, are those people. So was that a struggle early on to get people excited or to find the right people? +SUSANNA: It will always be a struggle, or maybe not always, but it continues to be a struggle. I do also want to make sure I share what we have built. And we have a mission to elevate access to menstrual care products, but our product is for everyone. So our actual physical network and machines we actually carry wellness essentials for everyone. So by solving this mission-based problem of access to menstrual care, we're actually building a product that serves everyone. We have products that everybody uses and needs every day. +And what we see in the marketplace is that SOS really is for everyone. But to your point, I think a lot of conversations, particularly early days and even now, still is a lot of educating and educating decision-makers about the need for this amenity in inclusive space and diversity and inclusion goals. And how can you expect or corporations expect to deliver on these important metrics that their leadership teams are being asked when these essential everyday products aren't even available in their space? +So there is a huge education. There are some uncomfortable conversations. Robina and I have gotten very, very good at having these direct conversations with a lot of people who maybe aren't comfortable talking about the products, but it's an important conversation that needs to happen. And if we don't have the conversation, then we're never going to get anywhere, and we're not going to be making progress. +So our goal is to try to make the conversation exciting and engaging and show these leaders or decision-makers that there is a lot of brand equity that can go alongside thinking about the people in their space, what they need, and what can make their experience in physical spaces better. So that's kind of like leading leadership to a place where being part of what we're building is exciting. +And it's an exciting opportunity to deliver an experience that's been long overlooked and is in need of a refresh. And so I think when we find folks who get that and are comfortable and excited to be part of the story, then that's usually where we find our best fit. +CHAD: So you're now a little ways on from that period of time. So what stage would you say you're at from a company and a product perspective and a market perspective? +SUSANNA: We closed our seed round fall of 2021. And that put us in a position, and that capital has taken us to a place where we're a team of 12, and that's across sort of all categories, which is sales, product, marketing, operations. And we're operating in three markets so New York, Boston, and South Florida. We are going to be doubling our network from just over 40 machines to over 100 by the end of summer. And then we'll be looking to get to closer to between 300 and 400 by the end of 2023. +So we are in a phase where our prototypes went from three machines in Boston to, like I mentioned, over 40 machines on walls now across corporate locations, transit, retail, sports, and entertainment. And we are and have been investing in and developing and evolving our tech stack and our product. So we've made some changes to our hardware since our prototypes, of course, and then invested quite a bit in our tech stack on the product side. So we will continue to bring in new best-in-class software partners where appropriate and then also invest in-house in continuing to evolve our product and features that we release to the network. +CHAD: Do you have a sense of, you know, currently the biggest number you mentioned is the 300 to 400 machine target. I imagine that the total possible number of machines that you could have, even just with moderate growth, is actually huge. +SUSANNA: Absolutely huge. So when we talk about our five year-projection, the number that we use is like 10,000 machines. So really, we want SOS to be ubiquitous. We want SOS to be everywhere you go, and so it's a brand that you associate and you trust to deliver just-in-time necessities from brands you love when you're not at home. So that would be across, you know, as people return to offices being an enterprise amenity and being in all leading real estate locations across the categories that I mentioned and really having a connected network. +So I would say, in general, vending is usually associated with white-label machines or mom-and-pop operations with snack machines, and that is really not the goal. We want to deliver an elevated experience as a brand and as a company across all of these locations so that you recognize the SOS machine. You know the experience that you're going to get. You know the perks of interacting and engaging with us as a brand and that there's a real trust and brand awareness that comes with the network as it grows. +CHAD: I totally get that you're trying to do something different in this space. But what are the numbers of those traditional vending machine suppliers like? Is there a big player in this space, or is it a lot of local companies white-labeling? +SUSANNA: It's a lot of local companies. And I think probably a good opportunity for me to highlight probably the biggest component of our business has to do with the media network that we're driving. So our machines are 32-inch touch screens serving interactive digital media when not being used as a point of sale. So, in addition to obviously having contact with cashless payment for the actual transactions and retail at the machines, we are serving direct campaigns and programmatic advertising across the network. +And in terms of the value and the drivers behind what we're building, experiential marketing which can be a combination of digital media and physical retail distribution and sampling. And we have abilities to deliver value to brands looking for both. And in some cases, brands are looking to execute both at the same time. Others will be just looking at SOS as a unique way to drive impressions and brand awareness in spaces, and locations, and audiences that they haven't had access to in the past in this way. +CHAD: What might that look like? That might be a company like an exercise equipment company or something wanting to spread awareness but not necessarily having a product to offer in the vending machine. +SUSANNA: Exactly. It could be fitness, financial services, direct-to-consumer brands where the consumer matches the audience that we're reaching, but the product doesn't belong in the machine at the distribution point. So the digital media and impressions that we can drive in addition to the product type, which is we have touch screens. +So we have first-party data collection opportunities, interactive campaigns, and surveys that run on our screens that are different than, for instance, a billboard that you drive by because this is a physical, interactive network. And with Instagram and Facebook advertising and first-party data being a very hot topic right now, having opt-in first-party data collection mechanisms for brands to offer sampling in a new channel is very valuable right now to a lot of the executives and CPG brands that we're talking to. +CHAD: I assume that from a business perspective, that is pretty attractive to you because the business of physical goods looks like one thing, but the business of advertising is a completely different model. And the combination of those two could be pretty attractive. +SUSANNA: Exactly. It's really unique about the business that we're building and what SOS can offer brands. So in order to, for instance, stand up a sampling campaign with SOS versus potentially having a street marketing team sampling, the cost and the data that we're able to collect by sampling through our network is much more valuable than potentially hiring folks to stand around and pass out product. +CHAD: Yeah, there might even be some brands that aren't necessarily comfortable doing it depending on what it is, a street campaign, or consumers that might not be comfortable taking something from somebody on the street that in the privacy of a restaurant might go over a little better. +SUSANNA: Absolutely. I think there's discretion in this automated retail experience for actual interaction with the physical product. And our machines and the network are, in some cases, in restrooms. In other cases, we're actually public access, and we're in amenity spaces. So these machines and the distribution channel is available in a whole host of appropriate locations and spaces. +CHAD: Cool. So what's your biggest hurdle to getting to 10,000 machines? +SUSANNA: Well, right now, we have a ton of demand, and the hardware is capital intensive. I'm sure there'll be people listening to this who are scared of hardware. And I would say, in general, that is certainly an obstacle to growing a hardware business. +CHAD: Putting a machine in a new location is not immediately profitable. There's an expense to creating that machine and then a timeline for it to pay itself back. +SUSANNA: I would say certainly. At a high level, SOS is a B2B2C business. So it’s a B2B sales lifecycle for you're building relationships selling into institutions in commercial real estate and corporations. That is the first I would say challenge, and funding the hardware and lead times with supply chain and hardware right now. It's a very hot topic, certainly hasn't been easy. +So the lead times on the hardware and then funding the hardware, so exactly if it's going to be a three or four-month potential lead time on hardware and orders. Funding that order before machines are on walls and revenue can be generated on media, and our product sales or amenity fees kick in. The timing of all of that makes, I would say, our business but hardware businesses in general potentially either less attractive to investors who are looking at SaaS companies all day long and have a very different profile in terms of the company. +But we're excited to be in a position where we have a very, very hot pipeline, a lot of inbound interest. I would say we're getting inbounds from best-in-class partners that we could only dream of doing business with. And they're reaching out to us to bring in the amenity. So it's an exciting position as a founder to be in to be opening your inbox and having multiple grade A inbounds a day. That's fantastic. +And moving towards a place where we're happy to report that we have signed and committed machine financing in place for this next period of growth. So that opens up a lot of doors. And in terms of our journey, initially investing our own cash into getting the prototypes ready for installation in 2020 to being in a position now where we have our first machine financing vehicle in place to actually protect our equity as we grow the network, which is what we're looking to do for the remainder of this year and next. I don't know if I answered that accurately. [chuckles] But the challenges of running and operating and funding a hardware capex–intensive business is probably the biggest. +CHAD: Is there a point in time where it really is that or something close to that that's holding you back, and you end up just doing this huge financing round or something in order to completely blow out the scale? +SUSANNA: I think we have, and we're very keenly aware of first-mover advantage in the sense that we have, and COVID and other global macro-economic barriers have basically made it hard for a lot of companies to grow really fast right now in certain industries. So we do have a first-mover advantage right now. And I think we want to look at the next; I would say year to year and a half to get the company to a network size where we're operating profitably and then go to our Series A and really crank on the growth and get the network humming and growing really rapidly after our Series A. +CHAD: So your goal would be to be operating profitably before getting to that next phase of growth. +SUSANNA: We expect to right now based on what we're seeing. So the business and our performance indicates that with this equity, this next...we're basically entering a bridge round, but with this machine financing and a bridge round, we should be in good shape to do so. +CHAD: Yeah, I think there are lots of different ways of doing things. But that seems to be what investors are wanting to see today. But also, I think not only is it from the market, but I think they're a little bit more...not to dwell on specific examples that I don't know too much about, but like, for example, scaling Blue Apron and a lot of the other meal box companies they were doing that when they weren't profitable. So they had never really shown that they could actually be profitable, but there were real costs to scale as well like you have. +SUSANNA: I think for many reasons, it makes sense for us, I think, to get the business to profitability. And a lot of it is selfish, you know, thinking about the company and our current equity stakeholders. But we don't want to be in a position where we dilute ourselves out of the business effectively with growth capital when we haven't proven or made the company profitable. So, anyway, that's our goal. And I think we're feeling pretty optimistic about it right now despite the fact that I know the market and the world feels like it's falling apart [chuckles] for a million different reasons. But we actually, surprisingly and shockingly, feel pretty optimistic right now. +CHAD: Well, I really wish you the best with that, and I look forward to following along and seeing all the good news along the way. If folks want to find out more about SOS or get in touch with you, where are the best places for them to do that? +SUSANNA: So definitely, I think you mentioned our website, that's worldofsos.com. And you can feel free to email us at hello@worldofsos.com. +CHAD: Awesome. Thanks so much for stopping by and sharing your story and your wisdom with us. I really appreciate it. +SUSANNA: Great. Thank you so much for having me. +CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Susanna Twarog. + + + Susanna Twarog is Co-Founder and Co-CEO of SOS, which is transforming wellness on the go through a network of smart vending machines that deliver just-in-time necessities where and when you need the most.

+ +

Chad talks with Susanna about wellness on the go, the unique business that they're building and what SOS can offer brands, and the biggest hurdles to overcome to get 10,000 machines up and running.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Susanna Twarog, Co-Founder and Co-CEO of SOS, which is transforming wellness on the go through a network of smart vending machines that deliver just-in-time necessities where and when you need the most. Susanna, thank you for joining me.

+ +

SUSANNA: Thank you, Chad. It's great to be here.

+ +

CHAD: So, what makes the vending machines from SOS smart?

+ +

SUSANNA: So what makes our vending machines smart? Well, I think smart and vending are typically not words that go together. And I think when we founded the company, the machines that we were looking at were outdated and old and out of stock. And to be honest, first and foremost, payment methods that are accepted by most vending machines are completely not in line with the modern consumer.

+ +

So we were looking at vending machines that take quarters and cash. And as two working women on the trading floor, nobody has quarters or coins or even cash anymore. So first and foremost, we are a cashless, modern vending machine that accepts contactless and modern forms of payment.

+ +

CHAD: Let's level-set a little bit about wellness on the go, what that means. What I hear when I look at...which I took a look at the product on the website, which I encourage people to do, and it's worldofsos.com. I think it gives a much better sense of this. But correct me if I'm wrong that what we're talking about here is the vending machines that might typically be in a men's or women's restroom. Is that right?

+ +

SUSANNA: Absolutely. So the problem that we are in a mission to solve is to transform outdated, completely broken, ugly hardware that's existed to distribute wellness essentials like menstrual care and other wellness products in public spaces. So those old machines that look like steel box drops [chuckles] that is the business or the distribution channel that we're looking to disrupt. And so, by introducing beautiful design-first tech-enabled hardware into this space, we're completely transforming a distribution channel that has not worked or served anyone for decades at this point.

+ +

CHAD: I don't even use those vending machines. But it seems to me like they're often broken, dirty, not even stocked. Is there market reasons why that's the case?

+ +

SUSANNA: So, to be quite honest, I think Robina and I, when we founded the company, started to explore why hasn't this problem been solved? And the fact of the matter is the built world, and a lot of commercial real estate is designed and developed by a group of people who don't necessarily menstruate or need these products that are everyday health and wellness essentials for actually what is over half of the world's population.

+ +

But the folks who design and plan these spaces are not necessarily coming at the design with a perspective of these needs. And so, honestly, Robina and I set out on a mission to say when we think about inclusive space and the world that we want to live in, we want to live in a world where not just among certain people but all people have access to health and wellness products that they need when they're not at home.

+ +

So you may have everything that you need and want from the brands that you love and the ingredients that you trust in your own cabinet. But when you're on the go, and you're at work or you're traveling or entertaining, or spending time in other physical spaces that aren't your home, typically, those products aren't available, and they're very hard to access. So it's a major area for us to innovate and introduce a world that we want to live in where you can access the products you need from brands you already know and love or want to discover and try.

+ +

CHAD: So building really any hardware, and I have a lot of guests who have done hardware in the past, can be a challenge, especially starting out. What you talk about in the startup industry is often like starting out small, figuring out the minimum viable product, bringing that to market to early customers, and then learning and refining. And that can be difficult to do when you're shipping something physical. So how did you approach that?

+ +

SUSANNA: Robina and I approached this with a lot of intention and a lot of thought. We came from finance, business development, and sales backgrounds. Neither of us are engineers. So when we decided that we were going to found SOS and started to literally sketch out renderings for the type of hardware and design that we wanted to see in the world, initially, we were faced by a lot of people telling us to white-label products that already existed. You know, maybe don't invest in proprietary hardware or designing it yourselves. Try something that already exists. See if there's a product-market fit.

+ +

And ultimately, we actually invested in and began to work with an industrial design firm from the beginning. We have seven global design patents on the hardware because we knew that without an elevated design-first piece of hardware, the network would not be well-received, would not be able to grow and exist in the places we knew it needed to be, so to be in grade A commercial real estate where hundreds of millions of dollars are spent on designing and innovating into the built world to make these spaces cutting edge and tech-enabled.

+ +

And yet, if we didn't do the same with our hardware, this would just be another vending machine that got relegated to the basement or the back room, and that is not the company that we set out to build. We want to be a piece of integrated, exciting, engaging hardware and tech-enabled experience in these spaces. And so, to do that, we had to forge the path of bringing in and working with and basically investing our own money into designing a proprietary piece of hardware that could deliver the experience we knew was so integral to driving value for the company.

+ +

CHAD: I assume that wasn't easy or cheap. Did you fundraise at that point to do it? Or when you say your own money, were you literally the two of you investing yourselves?

+ +

SUSANNA: Absolutely. A big point of pride for me and Robina is that from the moment we founded the company through, to be quite honest, I would say the first 18 months of work, we invested our own personal savings. And this wasn't trust fund money that we'd inherited. This was truly just personal savings as young women in finance that we'd put aside, and it was the most money that either of us had ever spent on anything, was investing in ourselves and our own company. So we started...our first investments were in legal work and doing the patent search, and generating ultimately what has now been granted as seven patents for the company.

+ +

So patent work was the first money we spent, and then also engaging with an industrial design firm to get our concept into CAD rendering and identify the first contract manufacturer that we worked with on the prototype. So we were able to get pretty far prior to fundraising with our own investment. And trust me, it was a big commitment from both of us. And I think the fact that as co-founders being totally in lockstep with taking some of the biggest financial risks that either of us had ever taken and doing it together, and really having equal passion and commitment and belief in what we were going to build was an exceptional part of our founding story.

+ +

CHAD: I imagine you were probably a little nervous, the two of you. [chuckles]

+ +

SUSANNA: You know, it felt just like we had to do it. And I think it's kind of like lightning struck in the sense that we had this moment. And from literally the moment that we stepped aside and started to map out the business, there hasn't really been a pause or self-doubt in the sense that we've really known we're going to take this as far as we possibly can. So scary, yes, but it felt like we had the conviction from the very beginning, which I know is rare and not everyone's founding story. But for us, it really was 100% the right thing to do at the time, which was we're going to make this happen.

+ +

CHAD: So where did you and Robina meet?

+ +

SUSANNA: So we met as colleagues first and foremost. So we were two, I would say at the time, young women working in finance, and she was my counterpart. So she had a role in London, and I was in Boston. And we worked on our basically sales and business development pipelines together as colleagues first. And ultimately, Robina relocated back to the U.S, and we became friends on the same trading floor. So really, it was a friendship that grew out of a business relationship.

+ +

CHAD: Do you remember when and where this idea first came from?

+ +

SUSANNA: Sure do. [chuckles] It's very close to my heart. I was in the middle of a workday faced with a frustration and inconvenient situation where I couldn't find products that I needed when I needed them at work. And it was interrupting my day for the millionth time. And you know those moments when you have a friend, and you choose the person that you run to when you are, I guess, pissed off for lack of a better word? [laughs] And we just took that moment of me saying, "This is insane. How am I dealing with this? I can't get a tampon when I need one." And our eyes lit up. And we said, "Ah, well, this is a common problem for a very important segment of the world. And we need to do something about it."

+ +

CHAD: Now, it's a big leap to go from that frustration to founding a company together and actually working on it. So, how did that happen?

+ +

SUSANNA: So we had that moment, and we stepped aside and said, "This is completely insane. I'm too valuable to be wasting my time worrying about this on a daily basis." And the other fun part of our relationship is that we're also two young women with disposable income. We love products; we love travel, we love entertainment. We like to have fun. We work hard; we play hard.

+ +

I'm taking those two perspectives, which is like this frustration and universal need combined with consumerism. And this desire to make money, spend money is like combining the two and saying we have an opportunity to capitalize on this need and this consumer at the same time to deliver on a mission and drive value and consumer value for brands at the same time. And that really, I would say, sparked a tremendous amount of excitement and interest from Robina and myself.

+ +

How incredible to have an opportunity to build a company that is really driving good, and changing the world, and elevating access to these essential products while also tapping into this consumer interest of ours in products, and brands, and emerging indie brands, and digital content, and tech. And combining them all into one company and doing so with a lot of, I would say, excitement, and optimism, and win-win-win. Making the world a better place fulfilling a passion and interest of ours at the same time and driving value, and building a company.

+ +

CHAD: How far along were you in the idea stages, the legwork stages, before you both quit and started working on it full time?

+ +

SUSANNA: Took the leap. Yeah, that was a really critical decision and part of our journey. We were very intentional about taking the business as far as we could while protecting our personal financial interests in the sense that, you know, retaining benefits, positioning ourselves so that the company would have the most ability to succeed. And so we actually got through to basically 2020 when we were launching our first machines before we quit and ultimately joined our Techstars Boston 2020 program.

+ +

So we were, I would say, nights and weekends absolutely killing ourselves with work. We were able to raise our seed round, our pre-seed round technically, while still employed at the bank. And I would encourage others who are thinking about starting companies to maybe...in some cases; I'd say do what we did. And in other cases, I'd say it might kill you.

+ +

CHAD: [laughs]

+ +

SUSANNA: But I feel like whether we liked it or not, it put us in a position where we had achieved a tremendous amount of traction. We had our prototypes built and ready to be installed. And they were literally going into some of the most prestigious physical, commercial real estate locations in Boston as we were quitting. So I would say we were taking quite a bit of risk still. But we'd done everything we could to protect the company and make sure that we could get SOS where it needed to be before joining and coming on full-time.

+ +

CHAD: How did you find those first places where the machines were going to be installed?

+ +

SUSANNA: From the beginning, it was one of the areas of the company that we invested the most of our time in, which was that we had extensive contacts and relationships in financial services; that was our background. We had to start from scratch networking, and telling our story, and telling our vision with commercial real estate partners.

+ +

So pre-product, first slide decks, first cold calls, and warm introductions all really focused on commercial real estate. So we gave ourselves a crash course in real estate owner-managers, who the national players were, and started to network a ton, which was just LinkedIn, asking for introductions, having some meetings that were successes, having others that weren't.

+ +

But really, I think Robina and I had a and have a very, I guess, strong sense of salesmanship, I would say. That's a strength of ours. And so we were able to really get people excited and to believe in us and not to say sell smoke and mirrors, but we were waiting on a physical product prototype to arrive. And we were able to get believers and commitments before we actually had the product ready to demo in the market.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.

+ +

CHAD: So you already said at the beginning of the show your product is targeted or primarily for people who menstruate, and not a lot of property, commercial real estate developers, that kind of thing, are those people. So was that a struggle early on to get people excited or to find the right people?

+ +

SUSANNA: It will always be a struggle, or maybe not always, but it continues to be a struggle. I do also want to make sure I share what we have built. And we have a mission to elevate access to menstrual care products, but our product is for everyone. So our actual physical network and machines we actually carry wellness essentials for everyone. So by solving this mission-based problem of access to menstrual care, we're actually building a product that serves everyone. We have products that everybody uses and needs every day.

+ +

And what we see in the marketplace is that SOS really is for everyone. But to your point, I think a lot of conversations, particularly early days and even now, still is a lot of educating and educating decision-makers about the need for this amenity in inclusive space and diversity and inclusion goals. And how can you expect or corporations expect to deliver on these important metrics that their leadership teams are being asked when these essential everyday products aren't even available in their space?

+ +

So there is a huge education. There are some uncomfortable conversations. Robina and I have gotten very, very good at having these direct conversations with a lot of people who maybe aren't comfortable talking about the products, but it's an important conversation that needs to happen. And if we don't have the conversation, then we're never going to get anywhere, and we're not going to be making progress.

+ +

So our goal is to try to make the conversation exciting and engaging and show these leaders or decision-makers that there is a lot of brand equity that can go alongside thinking about the people in their space, what they need, and what can make their experience in physical spaces better. So that's kind of like leading leadership to a place where being part of what we're building is exciting.

+ +

And it's an exciting opportunity to deliver an experience that's been long overlooked and is in need of a refresh. And so I think when we find folks who get that and are comfortable and excited to be part of the story, then that's usually where we find our best fit.

+ +

CHAD: So you're now a little ways on from that period of time. So what stage would you say you're at from a company and a product perspective and a market perspective?

+ +

SUSANNA: We closed our seed round fall of 2021. And that put us in a position, and that capital has taken us to a place where we're a team of 12, and that's across sort of all categories, which is sales, product, marketing, operations. And we're operating in three markets so New York, Boston, and South Florida. We are going to be doubling our network from just over 40 machines to over 100 by the end of summer. And then we'll be looking to get to closer to between 300 and 400 by the end of 2023.

+ +

So we are in a phase where our prototypes went from three machines in Boston to, like I mentioned, over 40 machines on walls now across corporate locations, transit, retail, sports, and entertainment. And we are and have been investing in and developing and evolving our tech stack and our product. So we've made some changes to our hardware since our prototypes, of course, and then invested quite a bit in our tech stack on the product side. So we will continue to bring in new best-in-class software partners where appropriate and then also invest in-house in continuing to evolve our product and features that we release to the network.

+ +

CHAD: Do you have a sense of, you know, currently the biggest number you mentioned is the 300 to 400 machine target. I imagine that the total possible number of machines that you could have, even just with moderate growth, is actually huge.

+ +

SUSANNA: Absolutely huge. So when we talk about our five year-projection, the number that we use is like 10,000 machines. So really, we want SOS to be ubiquitous. We want SOS to be everywhere you go, and so it's a brand that you associate and you trust to deliver just-in-time necessities from brands you love when you're not at home. So that would be across, you know, as people return to offices being an enterprise amenity and being in all leading real estate locations across the categories that I mentioned and really having a connected network.

+ +

So I would say, in general, vending is usually associated with white-label machines or mom-and-pop operations with snack machines, and that is really not the goal. We want to deliver an elevated experience as a brand and as a company across all of these locations so that you recognize the SOS machine. You know the experience that you're going to get. You know the perks of interacting and engaging with us as a brand and that there's a real trust and brand awareness that comes with the network as it grows.

+ +

CHAD: I totally get that you're trying to do something different in this space. But what are the numbers of those traditional vending machine suppliers like? Is there a big player in this space, or is it a lot of local companies white-labeling?

+ +

SUSANNA: It's a lot of local companies. And I think probably a good opportunity for me to highlight probably the biggest component of our business has to do with the media network that we're driving. So our machines are 32-inch touch screens serving interactive digital media when not being used as a point of sale. So, in addition to obviously having contact with cashless payment for the actual transactions and retail at the machines, we are serving direct campaigns and programmatic advertising across the network.

+ +

And in terms of the value and the drivers behind what we're building, experiential marketing which can be a combination of digital media and physical retail distribution and sampling. And we have abilities to deliver value to brands looking for both. And in some cases, brands are looking to execute both at the same time. Others will be just looking at SOS as a unique way to drive impressions and brand awareness in spaces, and locations, and audiences that they haven't had access to in the past in this way.

+ +

CHAD: What might that look like? That might be a company like an exercise equipment company or something wanting to spread awareness but not necessarily having a product to offer in the vending machine.

+ +

SUSANNA: Exactly. It could be fitness, financial services, direct-to-consumer brands where the consumer matches the audience that we're reaching, but the product doesn't belong in the machine at the distribution point. So the digital media and impressions that we can drive in addition to the product type, which is we have touch screens.

+ +

So we have first-party data collection opportunities, interactive campaigns, and surveys that run on our screens that are different than, for instance, a billboard that you drive by because this is a physical, interactive network. And with Instagram and Facebook advertising and first-party data being a very hot topic right now, having opt-in first-party data collection mechanisms for brands to offer sampling in a new channel is very valuable right now to a lot of the executives and CPG brands that we're talking to.

+ +

CHAD: I assume that from a business perspective, that is pretty attractive to you because the business of physical goods looks like one thing, but the business of advertising is a completely different model. And the combination of those two could be pretty attractive.

+ +

SUSANNA: Exactly. It's really unique about the business that we're building and what SOS can offer brands. So in order to, for instance, stand up a sampling campaign with SOS versus potentially having a street marketing team sampling, the cost and the data that we're able to collect by sampling through our network is much more valuable than potentially hiring folks to stand around and pass out product.

+ +

CHAD: Yeah, there might even be some brands that aren't necessarily comfortable doing it depending on what it is, a street campaign, or consumers that might not be comfortable taking something from somebody on the street that in the privacy of a restaurant might go over a little better.

+ +

SUSANNA: Absolutely. I think there's discretion in this automated retail experience for actual interaction with the physical product. And our machines and the network are, in some cases, in restrooms. In other cases, we're actually public access, and we're in amenity spaces. So these machines and the distribution channel is available in a whole host of appropriate locations and spaces.

+ +

CHAD: Cool. So what's your biggest hurdle to getting to 10,000 machines?

+ +

SUSANNA: Well, right now, we have a ton of demand, and the hardware is capital intensive. I'm sure there'll be people listening to this who are scared of hardware. And I would say, in general, that is certainly an obstacle to growing a hardware business.

+ +

CHAD: Putting a machine in a new location is not immediately profitable. There's an expense to creating that machine and then a timeline for it to pay itself back.

+ +

SUSANNA: I would say certainly. At a high level, SOS is a B2B2C business. So it’s a B2B sales lifecycle for you're building relationships selling into institutions in commercial real estate and corporations. That is the first I would say challenge, and funding the hardware and lead times with supply chain and hardware right now. It's a very hot topic, certainly hasn't been easy.

+ +

So the lead times on the hardware and then funding the hardware, so exactly if it's going to be a three or four-month potential lead time on hardware and orders. Funding that order before machines are on walls and revenue can be generated on media, and our product sales or amenity fees kick in. The timing of all of that makes, I would say, our business but hardware businesses in general potentially either less attractive to investors who are looking at SaaS companies all day long and have a very different profile in terms of the company.

+ +

But we're excited to be in a position where we have a very, very hot pipeline, a lot of inbound interest. I would say we're getting inbounds from best-in-class partners that we could only dream of doing business with. And they're reaching out to us to bring in the amenity. So it's an exciting position as a founder to be in to be opening your inbox and having multiple grade A inbounds a day. That's fantastic.

+ +

And moving towards a place where we're happy to report that we have signed and committed machine financing in place for this next period of growth. So that opens up a lot of doors. And in terms of our journey, initially investing our own cash into getting the prototypes ready for installation in 2020 to being in a position now where we have our first machine financing vehicle in place to actually protect our equity as we grow the network, which is what we're looking to do for the remainder of this year and next. I don't know if I answered that accurately. [chuckles] But the challenges of running and operating and funding a hardware capex–intensive business is probably the biggest.

+ +

CHAD: Is there a point in time where it really is that or something close to that that's holding you back, and you end up just doing this huge financing round or something in order to completely blow out the scale?

+ +

SUSANNA: I think we have, and we're very keenly aware of first-mover advantage in the sense that we have, and COVID and other global macro-economic barriers have basically made it hard for a lot of companies to grow really fast right now in certain industries. So we do have a first-mover advantage right now. And I think we want to look at the next; I would say year to year and a half to get the company to a network size where we're operating profitably and then go to our Series A and really crank on the growth and get the network humming and growing really rapidly after our Series A.

+ +

CHAD: So your goal would be to be operating profitably before getting to that next phase of growth.

+ +

SUSANNA: We expect to right now based on what we're seeing. So the business and our performance indicates that with this equity, this next...we're basically entering a bridge round, but with this machine financing and a bridge round, we should be in good shape to do so.

+ +

CHAD: Yeah, I think there are lots of different ways of doing things. But that seems to be what investors are wanting to see today. But also, I think not only is it from the market, but I think they're a little bit more...not to dwell on specific examples that I don't know too much about, but like, for example, scaling Blue Apron and a lot of the other meal box companies they were doing that when they weren't profitable. So they had never really shown that they could actually be profitable, but there were real costs to scale as well like you have.

+ +

SUSANNA: I think for many reasons, it makes sense for us, I think, to get the business to profitability. And a lot of it is selfish, you know, thinking about the company and our current equity stakeholders. But we don't want to be in a position where we dilute ourselves out of the business effectively with growth capital when we haven't proven or made the company profitable. So, anyway, that's our goal. And I think we're feeling pretty optimistic about it right now despite the fact that I know the market and the world feels like it's falling apart [chuckles] for a million different reasons. But we actually, surprisingly and shockingly, feel pretty optimistic right now.

+ +

CHAD: Well, I really wish you the best with that, and I look forward to following along and seeing all the good news along the way. If folks want to find out more about SOS or get in touch with you, where are the best places for them to do that?

+ +

SUSANNA: So definitely, I think you mentioned our website, that's worldofsos.com. And you can feel free to email us at hello@worldofsos.com.

+ +

CHAD: Awesome. Thanks so much for stopping by and sharing your story and your wisdom with us. I really appreciate it.

+ +

SUSANNA: Great. Thank you so much for having me.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Susanna Twarog.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Susanna Twarog is Co-Founder and Co-CEO of SOS, which is transforming wellness on the go through a network of smart vending machines that deliver just-in-time necessities where and when you need the most.

+ +

Chad talks with Susanna about wellness on the go, the unique business that they're building and what SOS can offer brands, and the biggest hurdles to overcome to get 10,000 machines up and running.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Susanna Twarog, Co-Founder and Co-CEO of SOS, which is transforming wellness on the go through a network of smart vending machines that deliver just-in-time necessities where and when you need the most. Susanna, thank you for joining me.

+ +

SUSANNA: Thank you, Chad. It's great to be here.

+ +

CHAD: So, what makes the vending machines from SOS smart?

+ +

SUSANNA: So what makes our vending machines smart? Well, I think smart and vending are typically not words that go together. And I think when we founded the company, the machines that we were looking at were outdated and old and out of stock. And to be honest, first and foremost, payment methods that are accepted by most vending machines are completely not in line with the modern consumer.

+ +

So we were looking at vending machines that take quarters and cash. And as two working women on the trading floor, nobody has quarters or coins or even cash anymore. So first and foremost, we are a cashless, modern vending machine that accepts contactless and modern forms of payment.

+ +

CHAD: Let's level-set a little bit about wellness on the go, what that means. What I hear when I look at...which I took a look at the product on the website, which I encourage people to do, and it's worldofsos.com. I think it gives a much better sense of this. But correct me if I'm wrong that what we're talking about here is the vending machines that might typically be in a men's or women's restroom. Is that right?

+ +

SUSANNA: Absolutely. So the problem that we are in a mission to solve is to transform outdated, completely broken, ugly hardware that's existed to distribute wellness essentials like menstrual care and other wellness products in public spaces. So those old machines that look like steel box drops [chuckles] that is the business or the distribution channel that we're looking to disrupt. And so, by introducing beautiful design-first tech-enabled hardware into this space, we're completely transforming a distribution channel that has not worked or served anyone for decades at this point.

+ +

CHAD: I don't even use those vending machines. But it seems to me like they're often broken, dirty, not even stocked. Is there market reasons why that's the case?

+ +

SUSANNA: So, to be quite honest, I think Robina and I, when we founded the company, started to explore why hasn't this problem been solved? And the fact of the matter is the built world, and a lot of commercial real estate is designed and developed by a group of people who don't necessarily menstruate or need these products that are everyday health and wellness essentials for actually what is over half of the world's population.

+ +

But the folks who design and plan these spaces are not necessarily coming at the design with a perspective of these needs. And so, honestly, Robina and I set out on a mission to say when we think about inclusive space and the world that we want to live in, we want to live in a world where not just among certain people but all people have access to health and wellness products that they need when they're not at home.

+ +

So you may have everything that you need and want from the brands that you love and the ingredients that you trust in your own cabinet. But when you're on the go, and you're at work or you're traveling or entertaining, or spending time in other physical spaces that aren't your home, typically, those products aren't available, and they're very hard to access. So it's a major area for us to innovate and introduce a world that we want to live in where you can access the products you need from brands you already know and love or want to discover and try.

+ +

CHAD: So building really any hardware, and I have a lot of guests who have done hardware in the past, can be a challenge, especially starting out. What you talk about in the startup industry is often like starting out small, figuring out the minimum viable product, bringing that to market to early customers, and then learning and refining. And that can be difficult to do when you're shipping something physical. So how did you approach that?

+ +

SUSANNA: Robina and I approached this with a lot of intention and a lot of thought. We came from finance, business development, and sales backgrounds. Neither of us are engineers. So when we decided that we were going to found SOS and started to literally sketch out renderings for the type of hardware and design that we wanted to see in the world, initially, we were faced by a lot of people telling us to white-label products that already existed. You know, maybe don't invest in proprietary hardware or designing it yourselves. Try something that already exists. See if there's a product-market fit.

+ +

And ultimately, we actually invested in and began to work with an industrial design firm from the beginning. We have seven global design patents on the hardware because we knew that without an elevated design-first piece of hardware, the network would not be well-received, would not be able to grow and exist in the places we knew it needed to be, so to be in grade A commercial real estate where hundreds of millions of dollars are spent on designing and innovating into the built world to make these spaces cutting edge and tech-enabled.

+ +

And yet, if we didn't do the same with our hardware, this would just be another vending machine that got relegated to the basement or the back room, and that is not the company that we set out to build. We want to be a piece of integrated, exciting, engaging hardware and tech-enabled experience in these spaces. And so, to do that, we had to forge the path of bringing in and working with and basically investing our own money into designing a proprietary piece of hardware that could deliver the experience we knew was so integral to driving value for the company.

+ +

CHAD: I assume that wasn't easy or cheap. Did you fundraise at that point to do it? Or when you say your own money, were you literally the two of you investing yourselves?

+ +

SUSANNA: Absolutely. A big point of pride for me and Robina is that from the moment we founded the company through, to be quite honest, I would say the first 18 months of work, we invested our own personal savings. And this wasn't trust fund money that we'd inherited. This was truly just personal savings as young women in finance that we'd put aside, and it was the most money that either of us had ever spent on anything, was investing in ourselves and our own company. So we started...our first investments were in legal work and doing the patent search, and generating ultimately what has now been granted as seven patents for the company.

+ +

So patent work was the first money we spent, and then also engaging with an industrial design firm to get our concept into CAD rendering and identify the first contract manufacturer that we worked with on the prototype. So we were able to get pretty far prior to fundraising with our own investment. And trust me, it was a big commitment from both of us. And I think the fact that as co-founders being totally in lockstep with taking some of the biggest financial risks that either of us had ever taken and doing it together, and really having equal passion and commitment and belief in what we were going to build was an exceptional part of our founding story.

+ +

CHAD: I imagine you were probably a little nervous, the two of you. [chuckles]

+ +

SUSANNA: You know, it felt just like we had to do it. And I think it's kind of like lightning struck in the sense that we had this moment. And from literally the moment that we stepped aside and started to map out the business, there hasn't really been a pause or self-doubt in the sense that we've really known we're going to take this as far as we possibly can. So scary, yes, but it felt like we had the conviction from the very beginning, which I know is rare and not everyone's founding story. But for us, it really was 100% the right thing to do at the time, which was we're going to make this happen.

+ +

CHAD: So where did you and Robina meet?

+ +

SUSANNA: So we met as colleagues first and foremost. So we were two, I would say at the time, young women working in finance, and she was my counterpart. So she had a role in London, and I was in Boston. And we worked on our basically sales and business development pipelines together as colleagues first. And ultimately, Robina relocated back to the U.S, and we became friends on the same trading floor. So really, it was a friendship that grew out of a business relationship.

+ +

CHAD: Do you remember when and where this idea first came from?

+ +

SUSANNA: Sure do. [chuckles] It's very close to my heart. I was in the middle of a workday faced with a frustration and inconvenient situation where I couldn't find products that I needed when I needed them at work. And it was interrupting my day for the millionth time. And you know those moments when you have a friend, and you choose the person that you run to when you are, I guess, pissed off for lack of a better word? [laughs] And we just took that moment of me saying, "This is insane. How am I dealing with this? I can't get a tampon when I need one." And our eyes lit up. And we said, "Ah, well, this is a common problem for a very important segment of the world. And we need to do something about it."

+ +

CHAD: Now, it's a big leap to go from that frustration to founding a company together and actually working on it. So, how did that happen?

+ +

SUSANNA: So we had that moment, and we stepped aside and said, "This is completely insane. I'm too valuable to be wasting my time worrying about this on a daily basis." And the other fun part of our relationship is that we're also two young women with disposable income. We love products; we love travel, we love entertainment. We like to have fun. We work hard; we play hard.

+ +

I'm taking those two perspectives, which is like this frustration and universal need combined with consumerism. And this desire to make money, spend money is like combining the two and saying we have an opportunity to capitalize on this need and this consumer at the same time to deliver on a mission and drive value and consumer value for brands at the same time. And that really, I would say, sparked a tremendous amount of excitement and interest from Robina and myself.

+ +

How incredible to have an opportunity to build a company that is really driving good, and changing the world, and elevating access to these essential products while also tapping into this consumer interest of ours in products, and brands, and emerging indie brands, and digital content, and tech. And combining them all into one company and doing so with a lot of, I would say, excitement, and optimism, and win-win-win. Making the world a better place fulfilling a passion and interest of ours at the same time and driving value, and building a company.

+ +

CHAD: How far along were you in the idea stages, the legwork stages, before you both quit and started working on it full time?

+ +

SUSANNA: Took the leap. Yeah, that was a really critical decision and part of our journey. We were very intentional about taking the business as far as we could while protecting our personal financial interests in the sense that, you know, retaining benefits, positioning ourselves so that the company would have the most ability to succeed. And so we actually got through to basically 2020 when we were launching our first machines before we quit and ultimately joined our Techstars Boston 2020 program.

+ +

So we were, I would say, nights and weekends absolutely killing ourselves with work. We were able to raise our seed round, our pre-seed round technically, while still employed at the bank. And I would encourage others who are thinking about starting companies to maybe...in some cases; I'd say do what we did. And in other cases, I'd say it might kill you.

+ +

CHAD: [laughs]

+ +

SUSANNA: But I feel like whether we liked it or not, it put us in a position where we had achieved a tremendous amount of traction. We had our prototypes built and ready to be installed. And they were literally going into some of the most prestigious physical, commercial real estate locations in Boston as we were quitting. So I would say we were taking quite a bit of risk still. But we'd done everything we could to protect the company and make sure that we could get SOS where it needed to be before joining and coming on full-time.

+ +

CHAD: How did you find those first places where the machines were going to be installed?

+ +

SUSANNA: From the beginning, it was one of the areas of the company that we invested the most of our time in, which was that we had extensive contacts and relationships in financial services; that was our background. We had to start from scratch networking, and telling our story, and telling our vision with commercial real estate partners.

+ +

So pre-product, first slide decks, first cold calls, and warm introductions all really focused on commercial real estate. So we gave ourselves a crash course in real estate owner-managers, who the national players were, and started to network a ton, which was just LinkedIn, asking for introductions, having some meetings that were successes, having others that weren't.

+ +

But really, I think Robina and I had a and have a very, I guess, strong sense of salesmanship, I would say. That's a strength of ours. And so we were able to really get people excited and to believe in us and not to say sell smoke and mirrors, but we were waiting on a physical product prototype to arrive. And we were able to get believers and commitments before we actually had the product ready to demo in the market.

+ +

Mid-Roll Ad:

+ +

As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust.

+ +

We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust.

+ +

We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers.

+ +

Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.

+ +

CHAD: So you already said at the beginning of the show your product is targeted or primarily for people who menstruate, and not a lot of property, commercial real estate developers, that kind of thing, are those people. So was that a struggle early on to get people excited or to find the right people?

+ +

SUSANNA: It will always be a struggle, or maybe not always, but it continues to be a struggle. I do also want to make sure I share what we have built. And we have a mission to elevate access to menstrual care products, but our product is for everyone. So our actual physical network and machines we actually carry wellness essentials for everyone. So by solving this mission-based problem of access to menstrual care, we're actually building a product that serves everyone. We have products that everybody uses and needs every day.

+ +

And what we see in the marketplace is that SOS really is for everyone. But to your point, I think a lot of conversations, particularly early days and even now, still is a lot of educating and educating decision-makers about the need for this amenity in inclusive space and diversity and inclusion goals. And how can you expect or corporations expect to deliver on these important metrics that their leadership teams are being asked when these essential everyday products aren't even available in their space?

+ +

So there is a huge education. There are some uncomfortable conversations. Robina and I have gotten very, very good at having these direct conversations with a lot of people who maybe aren't comfortable talking about the products, but it's an important conversation that needs to happen. And if we don't have the conversation, then we're never going to get anywhere, and we're not going to be making progress.

+ +

So our goal is to try to make the conversation exciting and engaging and show these leaders or decision-makers that there is a lot of brand equity that can go alongside thinking about the people in their space, what they need, and what can make their experience in physical spaces better. So that's kind of like leading leadership to a place where being part of what we're building is exciting.

+ +

And it's an exciting opportunity to deliver an experience that's been long overlooked and is in need of a refresh. And so I think when we find folks who get that and are comfortable and excited to be part of the story, then that's usually where we find our best fit.

+ +

CHAD: So you're now a little ways on from that period of time. So what stage would you say you're at from a company and a product perspective and a market perspective?

+ +

SUSANNA: We closed our seed round fall of 2021. And that put us in a position, and that capital has taken us to a place where we're a team of 12, and that's across sort of all categories, which is sales, product, marketing, operations. And we're operating in three markets so New York, Boston, and South Florida. We are going to be doubling our network from just over 40 machines to over 100 by the end of summer. And then we'll be looking to get to closer to between 300 and 400 by the end of 2023.

+ +

So we are in a phase where our prototypes went from three machines in Boston to, like I mentioned, over 40 machines on walls now across corporate locations, transit, retail, sports, and entertainment. And we are and have been investing in and developing and evolving our tech stack and our product. So we've made some changes to our hardware since our prototypes, of course, and then invested quite a bit in our tech stack on the product side. So we will continue to bring in new best-in-class software partners where appropriate and then also invest in-house in continuing to evolve our product and features that we release to the network.

+ +

CHAD: Do you have a sense of, you know, currently the biggest number you mentioned is the 300 to 400 machine target. I imagine that the total possible number of machines that you could have, even just with moderate growth, is actually huge.

+ +

SUSANNA: Absolutely huge. So when we talk about our five year-projection, the number that we use is like 10,000 machines. So really, we want SOS to be ubiquitous. We want SOS to be everywhere you go, and so it's a brand that you associate and you trust to deliver just-in-time necessities from brands you love when you're not at home. So that would be across, you know, as people return to offices being an enterprise amenity and being in all leading real estate locations across the categories that I mentioned and really having a connected network.

+ +

So I would say, in general, vending is usually associated with white-label machines or mom-and-pop operations with snack machines, and that is really not the goal. We want to deliver an elevated experience as a brand and as a company across all of these locations so that you recognize the SOS machine. You know the experience that you're going to get. You know the perks of interacting and engaging with us as a brand and that there's a real trust and brand awareness that comes with the network as it grows.

+ +

CHAD: I totally get that you're trying to do something different in this space. But what are the numbers of those traditional vending machine suppliers like? Is there a big player in this space, or is it a lot of local companies white-labeling?

+ +

SUSANNA: It's a lot of local companies. And I think probably a good opportunity for me to highlight probably the biggest component of our business has to do with the media network that we're driving. So our machines are 32-inch touch screens serving interactive digital media when not being used as a point of sale. So, in addition to obviously having contact with cashless payment for the actual transactions and retail at the machines, we are serving direct campaigns and programmatic advertising across the network.

+ +

And in terms of the value and the drivers behind what we're building, experiential marketing which can be a combination of digital media and physical retail distribution and sampling. And we have abilities to deliver value to brands looking for both. And in some cases, brands are looking to execute both at the same time. Others will be just looking at SOS as a unique way to drive impressions and brand awareness in spaces, and locations, and audiences that they haven't had access to in the past in this way.

+ +

CHAD: What might that look like? That might be a company like an exercise equipment company or something wanting to spread awareness but not necessarily having a product to offer in the vending machine.

+ +

SUSANNA: Exactly. It could be fitness, financial services, direct-to-consumer brands where the consumer matches the audience that we're reaching, but the product doesn't belong in the machine at the distribution point. So the digital media and impressions that we can drive in addition to the product type, which is we have touch screens.

+ +

So we have first-party data collection opportunities, interactive campaigns, and surveys that run on our screens that are different than, for instance, a billboard that you drive by because this is a physical, interactive network. And with Instagram and Facebook advertising and first-party data being a very hot topic right now, having opt-in first-party data collection mechanisms for brands to offer sampling in a new channel is very valuable right now to a lot of the executives and CPG brands that we're talking to.

+ +

CHAD: I assume that from a business perspective, that is pretty attractive to you because the business of physical goods looks like one thing, but the business of advertising is a completely different model. And the combination of those two could be pretty attractive.

+ +

SUSANNA: Exactly. It's really unique about the business that we're building and what SOS can offer brands. So in order to, for instance, stand up a sampling campaign with SOS versus potentially having a street marketing team sampling, the cost and the data that we're able to collect by sampling through our network is much more valuable than potentially hiring folks to stand around and pass out product.

+ +

CHAD: Yeah, there might even be some brands that aren't necessarily comfortable doing it depending on what it is, a street campaign, or consumers that might not be comfortable taking something from somebody on the street that in the privacy of a restaurant might go over a little better.

+ +

SUSANNA: Absolutely. I think there's discretion in this automated retail experience for actual interaction with the physical product. And our machines and the network are, in some cases, in restrooms. In other cases, we're actually public access, and we're in amenity spaces. So these machines and the distribution channel is available in a whole host of appropriate locations and spaces.

+ +

CHAD: Cool. So what's your biggest hurdle to getting to 10,000 machines?

+ +

SUSANNA: Well, right now, we have a ton of demand, and the hardware is capital intensive. I'm sure there'll be people listening to this who are scared of hardware. And I would say, in general, that is certainly an obstacle to growing a hardware business.

+ +

CHAD: Putting a machine in a new location is not immediately profitable. There's an expense to creating that machine and then a timeline for it to pay itself back.

+ +

SUSANNA: I would say certainly. At a high level, SOS is a B2B2C business. So it’s a B2B sales lifecycle for you're building relationships selling into institutions in commercial real estate and corporations. That is the first I would say challenge, and funding the hardware and lead times with supply chain and hardware right now. It's a very hot topic, certainly hasn't been easy.

+ +

So the lead times on the hardware and then funding the hardware, so exactly if it's going to be a three or four-month potential lead time on hardware and orders. Funding that order before machines are on walls and revenue can be generated on media, and our product sales or amenity fees kick in. The timing of all of that makes, I would say, our business but hardware businesses in general potentially either less attractive to investors who are looking at SaaS companies all day long and have a very different profile in terms of the company.

+ +

But we're excited to be in a position where we have a very, very hot pipeline, a lot of inbound interest. I would say we're getting inbounds from best-in-class partners that we could only dream of doing business with. And they're reaching out to us to bring in the amenity. So it's an exciting position as a founder to be in to be opening your inbox and having multiple grade A inbounds a day. That's fantastic.

+ +

And moving towards a place where we're happy to report that we have signed and committed machine financing in place for this next period of growth. So that opens up a lot of doors. And in terms of our journey, initially investing our own cash into getting the prototypes ready for installation in 2020 to being in a position now where we have our first machine financing vehicle in place to actually protect our equity as we grow the network, which is what we're looking to do for the remainder of this year and next. I don't know if I answered that accurately. [chuckles] But the challenges of running and operating and funding a hardware capex–intensive business is probably the biggest.

+ +

CHAD: Is there a point in time where it really is that or something close to that that's holding you back, and you end up just doing this huge financing round or something in order to completely blow out the scale?

+ +

SUSANNA: I think we have, and we're very keenly aware of first-mover advantage in the sense that we have, and COVID and other global macro-economic barriers have basically made it hard for a lot of companies to grow really fast right now in certain industries. So we do have a first-mover advantage right now. And I think we want to look at the next; I would say year to year and a half to get the company to a network size where we're operating profitably and then go to our Series A and really crank on the growth and get the network humming and growing really rapidly after our Series A.

+ +

CHAD: So your goal would be to be operating profitably before getting to that next phase of growth.

+ +

SUSANNA: We expect to right now based on what we're seeing. So the business and our performance indicates that with this equity, this next...we're basically entering a bridge round, but with this machine financing and a bridge round, we should be in good shape to do so.

+ +

CHAD: Yeah, I think there are lots of different ways of doing things. But that seems to be what investors are wanting to see today. But also, I think not only is it from the market, but I think they're a little bit more...not to dwell on specific examples that I don't know too much about, but like, for example, scaling Blue Apron and a lot of the other meal box companies they were doing that when they weren't profitable. So they had never really shown that they could actually be profitable, but there were real costs to scale as well like you have.

+ +

SUSANNA: I think for many reasons, it makes sense for us, I think, to get the business to profitability. And a lot of it is selfish, you know, thinking about the company and our current equity stakeholders. But we don't want to be in a position where we dilute ourselves out of the business effectively with growth capital when we haven't proven or made the company profitable. So, anyway, that's our goal. And I think we're feeling pretty optimistic about it right now despite the fact that I know the market and the world feels like it's falling apart [chuckles] for a million different reasons. But we actually, surprisingly and shockingly, feel pretty optimistic right now.

+ +

CHAD: Well, I really wish you the best with that, and I look forward to following along and seeing all the good news along the way. If folks want to find out more about SOS or get in touch with you, where are the best places for them to do that?

+ +

SUSANNA: So definitely, I think you mentioned our website, that's worldofsos.com. And you can feel free to email us at hello@worldofsos.com.

+ +

CHAD: Awesome. Thanks so much for stopping by and sharing your story and your wisdom with us. I really appreciate it.

+ +

SUSANNA: Great. Thank you so much for having me.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Susanna Twarog.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YUq_QQV6 + + ]]> + + Chad Pytel + Susanna Twarog + + + 433: Techie Staffing with Anna Spearman + https://podcast.thoughtbot.com/433 + 3ccf286a-18c6-461c-80d2-c9494d6b96f6 + Thu, 28 Jul 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Anna Spearman is the Founder of Techie Staffing, which connects high-quality technology talent with high-caliber clients. + +Chad talks with Anna about founding and growing the company, immediately after graduating college, during a pandemic, reputation building, and facing skepticism around her lack of track record in recruiting, and finding and providing talent for clients as a white-glove service. + 50:53 + no + + + Anna Spearman is the Founder of Techie Staffing, which connects high-quality technology talent with high-caliber clients. +Chad talks with Anna about founding and growing the company, immediately after graduating college, during a pandemic, reputation building, and facing skepticism around her lack of track record in recruiting, and finding and providing talent for clients as a white-glove service. +Techie Staffing (https://techiestaffing.com/) +Follow Techie Staffing on Twitter (https://twitter.com/StaffingTechie), Facebook (https://www.facebook.com/techiestaffing), Instagram (https://www.instagram.com/techiestaffing/) or LinkedIn (https://www.linkedin.com/company/techie-staffing/). +Follow Anna on LinkedIn (https://www.linkedin.com/in/annaspearman/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Anna Spearman, the Founder of Techie Staffing, which connects high-quality technology talent with high-caliber clients. Anna, thanks so much for joining me. +ANNA: Thank you so much for inviting me, Chad. +CHAD: In theory, at the surface level, Techie Staffing is probably fairly straightforward in terms of what you do. But I'm curious how you got started. +ANNA: Yes, of course. So I can't believe I'm saying this, but it's been two years. Two years ago, I was, during that time, attending the University of Virginia, where I was majoring in computer science with a minor in entrepreneurship. And in the spring of 2020, I was planning on coming back home to...I was born and raised in Los Angeles, and I was planning to come back home for spring break. And I was finishing out my second semester of senior year. So I was planning my [chuckles] victory lap of going back home, taking a little bit of a rest time, and then coming back to UVA to finish my degree, graduate, and move on to a new job in Los Angeles. +But unfortunately, as my plane was landing in Los Angeles, we kept hearing about COVID. And so the pandemic hit in the middle of my spring break. And during that time, I had to finish my second semester of senior year remote. It was very stressful, but when I finished the degree, I was so fulfilled. But unfortunately, there was a rapid dwindling of entry-level tech and product roles. I initially either wanted to be a software engineer or a product manager or be a software engineer that transitioned into a technical product manager. +But unfortunately, once the pandemic hit, companies weren't willing to ramp up entry-level talent. Companies didn't really know what was going to happen in the future, and everybody was remote. So it was just a really confusing time. But while I was searching through different job boards trying to find new opportunities, especially entry-level opportunities, I found just a wealth of senior tech jobs, specifically with companies that were thriving due to the pandemic. During that time, companies like Peloton, Discord, Zoom, they were all soaring due to the pandemic. +So I had heard about contingent recruiting in the past. My biggest dream for a new opportunity for myself graduating out of college was just to learn something new every day because I've always had a very much an interdisciplinary background. I've never been able to stay in one area. I've always loved to try different things. So with a little bit of a background recruiting at a past summer internship as well as wanting to utilize my entrepreneurship minor...I'm actually a fourth-generation woman entrepreneur. So definitely, growing up, creating my own business was my dream. So really, that was my main goal. +I thought I was going to transition from a current role into entrepreneurship, but I had my back against the wall. So I just thought, why not start now? So I created Techie Staffing, a technology staffing agency specializing in direct hire placements nationwide. I basically had my virtual graduation; then I took a week. And then, I got started creating the website, establishing the business paperwork, as well as developing strategic partnerships with senior technical recruiters that had full candidate pipelines to fill incoming job requisitions. +And I basically started off with nothing. I had no contacts, no network, just nothing at all. And I was really starting just fresh. So I really had to really spend a lot of time networking and developing relationships as well as just learning and mastering full lifecycle recruiting, especially with engineering since there's such a supply and demand issue for software engineers. So you're just consistently following up and contacting people that could potentially be interested in your companies. But it really blew up. +As I was establishing everything in 2020 from summer to the end of 2020, it was 2021 when it really blew up where I contacted this founder during the time they had raised a Series B 50 million, which was amazing, and they were going through a hiring sprint. So we got connected fairly quickly. And with just great team synergy, we were actually able to place five people in one month, and it was frontend, backend, and full-stack developers. So that really jump-started Techie Staffing. +And then after that, we worked with...we're now working with Fortune 500 companies as well as high-growth startups and really building a diversified portfolio, and we’re also a certified woman-owned business which I'm so proud of because there aren't really a lot of women or even just women of color that are founders. So I was really happy to get that certification, really proud of that as well. +I always say all the time to everybody it's super stressful, but it's so rewarding at the same time. And I do believe that it's honestly, you know, I know the pandemic has been super hard on people. And it's been such a change and such a shift. But there is still a part of me that is so grateful for making that pivot because I really found something that I feel like I really enjoy doing every day. +CHAD: That's great. I really commend you on everything you've done so far. And I'm excited about what you're going to do in the future. You now have grown where you're multiple people on your team. +ANNA: Yeah, so we actually hired two new people fairly recently. I did have one direct hire recruiter working with me. So now it's officially a team of four. I did develop the strategic part. I do still have some strategic partnerships as well because on that part, at first, I was partnering with recruiters that were independent, so who were a little bit more entrepreneurial so that we could split the placement fee. But it's still better to just have full-time employees. I'm so excited to have two new additional hires, and it's still new for me. +So I'm really looking forward to growing together in terms of growing Techie Staffing and growing into being a full life cycle recruiter because it wasn't that long ago when I was in that same exact spot. And it's so amazing. It still blows my mind to this day how two years ago, thinking about interviewing candidates or selling to clients, and now what I've evolved in. It's been absolutely amazing. +So I'm so happy to see their journey and seeing them transition into being technical recruiters and also making a pivot in their career as well, which that's still blowing my mind a little bit. I'm sure you know founding thoughtbot and really building that from the ground up. So it's just amazing seeing that infrastructure. It just really brings a brighter future as well. +CHAD: So what kind of people do you look for when you're looking to add to your team? Are you bringing on people who have experience with recruiting? Or are you bringing on people who are transitioning into it? +ANNA: I would say for Q1 and Q2 of 2022 and even a little bit beforehand, since there was a surge in demand for everything and tech companies were just scaling like crazy, there was very much a competitive market for recruiters, specifically technical recruiters. Because that's what companies were really looking for to scale their engineering and product teams. So it was very, very competitive to recruit for a technical recruiter. +So now you see agencies now who are hiring people who can have the DNA for a technical recruiter but not necessarily have direct experience, which I think can be really, really cool. Because like I said, like two years ago, I knew absolutely nothing, and now I feel very much confident in the full life cycle. So I think that's really cool to have people be able to pivot into a really cool industry where you're really learning something new every day, and you're speaking to really interesting people. +We specialize in senior up until C-suite, so yeah, learning from people who are senior all the way up to Director, VP. So it's really interesting. So when I was approaching hiring, I really wanted to find someone who had that DNA that can potentially transition to being a technical recruiter. And that DNA would be, you know, it doesn't have to be personality but just really interacting with engineers, just maybe being a self-starter. +I would say great communication, and lastly, I would say just really hungry. Yes, I would say hungry. Because if you're really hungry and you're really willing to learn and be open, so openness as well, then you can really understand the rules or just the lifecycle and the process of being a recruiter, and then you can change people's lives. +I actually had one...It was about a year ago, I was working with a Fortune 500 company, and I recruited this guy, and I led him through the process. And it was about maybe a month later when he told me I had basically changed his life. Him and his family were now moving to Atlanta, and it was a new role, and it was just a fresh start. And he was just telling me how appreciative he was of me, and so that really hit home. So I think for those two new hires, I'm so excited to have them get super engaged and be able to change other people's lives as well under the Techie Staffing name, of course. +CHAD: You mentioned early on that you're contingent recruiting. So correct me if I'm wrong, but that means that you get paid when you place somebody, when someone gets hired from the company that hires them. +ANNA: Yes. +CHAD: But then you also mentioned that these people who you're bringing onto your team are full-time. So how does the compensation structure typically work for them? +ANNA: Oh, compensation, we have them on salary, but they do have commission. So we wanted to really give; like I said, I want us to grow together. So I do provide commission for each placement they'll place just to really provide incentive. Like I said, it's so early. I want us to think of each other just as teammates and a team because we're all building towards the same goal. +So just really wanted to provide incentives where they're really feeling like they're almost owning it full life cycle as well. Because like I said, it's early on, and these can be really strong pillars in the future. So there is salary, but there's also that commission as well to just really provide that incentive. And I know for me personally, incentive can be awesome, so definitely trying to provide that motivation and having them really feel like they're an integral part. +CHAD: What's the harder part of your business? Or are they equally hard, finding new clients versus finding people who want to work with you on the candidate side? +ANNA: On the business development side, I would say it was harder perhaps in the beginning because I just so was starting with nothing, really. I had just graduated from college. And a lot of agency owners they previously have maybe worked at a really cool tech startup, or maybe they've been working on their agencies for the past 5 or 10 years. They have previous years of experience, but I didn't have that. +So I had to convey another method of just really networking, really meeting people, and just really knowing my stuff and having a handle on it. I know maybe a lot of people say, like, just fake it until you make it because then once you make it, and then you get that experience, then you can transfer that experience to new experiences as well. So at first, it was really just building myself up and building the Techie Staffing brand so that we could acquire those clients. +In terms of the candidate side, I would say Techie Staffing, and one of the things and part of our brand that we love to portray is that we are the agency that has the companies with the best employer branding. Because like I said, with the supply and demand issue for the software engineers, it is so competitive to attract them to new opportunities. There are just so many companies that are contacting them multiple times a day. So there has to be at least a little bit of a shine or a little bit of a differentiator for companies that you're recruiting for. +So we actually specialize in companies that are Series B and above that do have that established employer branding where engineers are really interested in joining that company, so that's just the thing. It's like really having companies that have strong employer branding and being able to follow up. Follow-ups are really, really important when it comes to engaging engineers because, like I said, it's just a super competitive market and just trying to provide them a great white-glove experience. There are some agencies that fall a little bit too close to the client-side where the client is always right. +And there are some that fall too much to the candidate side where the candidate is right, but we really want to be a balanced middleman where we're just trying to find the compromise and find the best solution for everybody. So that's the real important part of it of just really providing them with a great experience and showing them that we care and that we're rooting for them. +Because it sometimes does surprise me when candidates can be a little...maybe this is a part of me being new. But that's kind of an advantage, too, because I'm still paying attention to detail. That's where my computer science major comes in. It's like constantly trying to stay in tune with candidates and what they need, so just trying to provide a great experience in general. And I'm sure you feel that way with your clients. You're a consultancy as well where you're trying to be B2B and contact these different companies. So how do you conduct business development and really differentiate yourself? +CHAD: We focused a lot on reputation building, so blogging, creating open source so that we don't need, fortunately, to cold contact people. And when we do, we're fortunate enough that they might already know about us. And so it's an easier conversation to have because they may already be reading our blog, or they may already be using some of our open source in their product. And so it becomes an easier conversation to have. But the majority of our clients actually come to us when they have a need because we're fortunate enough to have worked to be at the top of the list. +ANNA: Definitely, yeah. And I'm still doing that, just reputation building. With one of our Fortune 500, we're doing incredibly well with them to the point where we're filling their pipelines, and we have majority of our candidates in their pipeline. So that's what we're really working on right now is just consistently...and I know like with any business, you have to just constantly build that reputation. So I especially just try to provide a great experience for candidates because they can also be hiring managers as well, so just really providing that white-glove experience. +And also, a cool differentiator we always like to showcase is like, I'm a computer science major. And actually, the two people that I just hired have a tech background. So it's not like tech is entirely foreign to us. We've engaged with programming languages. We've coded projects. So we do have some form of understanding when it comes to certain technologies or certain projects that certain engineers are working on. +And that's what really gets me excited to speak with engineers because it's so cool and interesting hearing about them working on their projects and working on projects that directly affect me and the products that I'm interacting with. So it's so cool to hear about their...I can understand a bit. And so that's another thing we have with Techie Staffing is really finding people who have a bit of a tech background so at least they have a little bit of knowledge or an understanding of what projects and can be able to really share and convey that to clients that are looking for this talent. +CHAD: You mentioned it's a really competitive market now. And as a company who probably has multiple clients, how do you minimize or how do you deal with the potential competition for the limited supply among your own clients? +ANNA: Among my own clients, I will say that right now we don't have...for the roles that we're working on for each client, they're not very similar or too, too similar, which is a good thing. We would like it in the future where we could have the same role, but we can understand how that can be a little tricky as well. +CHAD: And how do they differ then? Are they differing by the technology experience that they're looking for or the sort of level of the role? How are they different? +ANNA: It could be technology, difference of the role. So, for example, for a Fortune 500 company that we're working with, we'll work more with UX, data science, data science roles, as well as...so UX, data science. And then for high-growth startups, mostly with them, they're really looking for back-end engineers, but overall just engineering so frontend, backend, DevOps. We are working potentially to do engineering or more engineering-heavy for our Fortune 500 companies. We have recently been working on a VP of engineering. +So for Fortune 500 for now, we've been working more with leadership roles especially, and for high-growth, it's been more engineering IC. But we would like to transition that in the future to have it kind of...or have roles that maybe some candidates could go to this company, and some candidates can go to that startup. And then another differentiator could be or what makes our clientele different from each other is for high-growth startups, especially for engineering ICs, they're really looking for candidates that come from high-growth startups who just understand the current company where they are, and how they're scaling during that period of time around that series B and series C. That's the time to really scale. +And Fortune 500 companies they can be open to startups, but for the most part, especially sometimes for leaders who need to have a certain amount of direct reports, they're more looking for people from larger companies. So that would be one way to kind of separate it and so we're not having candidates almost be where they have to compete with candidates within our own company. Because with the difference in the leveling of companies, there's just a difference in what kind of candidates that they're looking for. +Mid-Roll Ad: +Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? +We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. +By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. +Save time and money with our DevOps and Maintenance service. Find out more at: url tbot.io/devops +CHAD: When I was first starting thoughtbot, I really felt like I needed to take every client that we could get because we were just starting out. We needed to make money. We needed to build a reputation. And so, I felt like we needed to say yes to every client. Over the years, I learned that that was actually watering us down, and it made us less successful. And the more we were clear about who we were, and what we did, and what clients we were best for, the more successful we were. Have you gotten to the point where you needed to turn down clients? +ANNA: Because I do such targeted biz dev, we will contact companies that we personally want to work with. But I will say in the beginning, there were some companies that were a lot smaller that, just like you said, you just felt the need to want to rack up a client list. And you just are ready to go and wanting to work with someone. It really motivated me to really take a look and really go deep into the type of clients that we want. So, for example, really, really early-stage companies can have a really, really hard time hiring because, like I said, employer branding is so, so important. +And so usually what they'll have is maybe like mission, but they won't really have salary. Or they won't really have the employer branding of the company of candidates either knowing about the company or being able to search the company really quickly and seeing the platform that the company is building and seeing how strong it is. So it's really, really hard to recruit for those stages. I mean, it is possible, but it's just really hard. +And then at the same time for these early-stage companies, they really want to, which I totally understand, you know, when you're having your probably 8th, 9th, or 10th engineer and being on the founding team, you really want a strong engineer because that's your platform, that's your baby. You don't want anybody that, you know, it could potentially maybe cause problems, or they really want somebody there they can trust. And so it's hard, you know like I said -- +CHAD: But they might not be able to afford that. [laughs] +ANNA: Yes, they might either not be able to afford it, or they also cannot interview fast enough in order to just get the offer in their hands. Because I understand they really want to have them speak to the entire team and have them have an in-depth process because it's very much an important role. But these candidates and startups are moving so fast right now where I will speak to a candidate one day, and he or she or they'll probably say, "Oh, you know, I'm passively looking. I'm not really actively looking." And maybe a week and a half to two weeks later, they're like, "Oh, I actually have two offers in hand." +So it goes really, really fast versus earlier stage; it can just go a little bit slower because they're just really taking the time to go more in-depth and see if this prospective candidate is the right fit, which is totally understandable. But it was just really hard for us as contingent trying to find that candidate, that perfect candidate for them as well as trying to keep candidates warm and keep them interested when some companies just have like mission. +So now, in the future, I've just really, like I said, Techie Staffing, we specialize from Series B and above. And I really just make sure during business development exploratory chats that I'm really going in-depth and making sure I understand the roles that they're prioritizing their time to hire. So if they have a long, long interview process and a really, really low salary in terms of the competitive market, then I may not be as interested in that startup as opposed to another startup whose interview process timeline could be about a week and a half to two weeks. +And it doesn't have to be absolutely amazingly competitive base salary but just a fairly competitive salary with a great timeline for time to hire. So that's been my way of just condensing or just being a little bit more pickier in terms of clients in the future. Were there any certain clients for you where you started working with them, and you were like, "Oh, maybe I shouldn't have," that's now caused you to be a little bit more pickier for clients in the future? +CHAD: Part of it was the kind of work. So we really wanted to be writing software. But just starting out, I also had a background in sort of IT support. And so, when I was reaching out, particularly to past clients, they might say, "You built our website. Now can you help us with purchasing a computer or setting up a computer network in our office?" +I felt compelled to say, "Yes," because I felt like we needed all the work we could get. But by doing that work that wasn't really what we wanted to be doing, we were not only less happy in our work, but it was taking time and attention away from the work that we really wanted to be doing. +The other was values and practices, which took a little bit longer to form a real understanding of what our values were and the practices that we believe in. But now there's a pretty clear list of the kinds of companies that...what we say at thoughtbot is that we want to work on things that deserve to exist in the world. +And so there's a whole bunch of industries that they might not even be actively doing harm in the world, but they are the ones that we wouldn't work in. But even if it's just not a positive contribution to the world, it's probably not going to be something that we're excited to work on. +ANNA: That's been an exciting trend, actually, to speak with engineers about. I've started seeing that trend where engineers are saying, "I don't want to create anything evil," or "I just want to do good." And that's been a really awesome selling point for some teams. It definitely is a cherry on top where engineers are really looking for social impact. And the cool part is they have so many opportunities that are coming towards them that they can really pick and choose which one. So to find people who are really looking for social good and just really mission-driven products is amazing to see. +And I'm really happy with the work...I'm actually working with a data science team for AI ethics. And that's been really interesting hearing some people talk about their projects and hearing about how data can really not only just strengthen bias but also can just really produce results that can harm certain groups of people, which is so interesting. And it can be something so, so small that I haven't even noticed at all, but that can lead to a big difference. +CHAD: Yeah, we've had several episodes about that. +ANNA: And it's amazing. And it really is just a huge difference with something so small. And as a woman of color, I'm always aware of what's going on in terms of just ethical practices or just fairness and seeing bias. But in terms of data, seeing something so so small can affect just a whole group of underrepresented people is just amazing to see. But it's also amazing that people or data scientists are now aware of it, and now they're changing it so that it no longer...at least they'll be able to alleviate that bias. +CHAD: I want to ask a little bit more about that, and then I want to talk about some market trends. But if you're comfortable, I'm curious; you already mentioned you were just out of college when you were getting started. So there was skepticism around your lack of track record in recruiting. And you've mentioned that you are a woman of color. +And so I think as engineers, as people in the market, we probably have this image in our head of what a typical recruiter looks like in terms of attitude, and values, and demographics. And you don't fit that mold in almost any way, basically. Is this actually a positive for you now, or is it actually still hard? Are there companies that are actively seeking out to work with you because they want that different approach? Or are you still facing that skepticism? +ANNA: I'm still facing that skepticism. I actually created Techie Staffing around the time of summer 2020, where Black Lives Matter, where George Floyd happened. And it was really interesting because I was entering the corporate workplace. I went to a really wealthy private school in Los Angeles. And I went to the University of Virginia. So I survived two PWIs which means predominantly White institutions. So I thought I had not seen it all, but I thought I had maybe experienced those experiences of bias and understood it a little bit more. +But when I went to the corporate workplace and the diversity inclusion campaigns were happening, it was just really confusing because it's hard specifically for engineering and product specifically because it's so new that there is a really, really hard time to find diverse talent. That's why I honestly believe that it's just really trying to educate underrepresented communities to understanding all of the different diverse types of roles and opportunities that you can encounter in the tech industry so, for example, like UX, UX design, UX research, data science, machine learning, all of that. +So I think I was more contacted or maybe was engaged in business development companies who were looking for me to do diversity which I think it kind of...and I am such a huge proponent for diversity. But it also kind of had my heart drop a little bit because I just felt like people were contacting me because of who I am instead of just thinking like if it was just any other agency, would I be contacted specifically for that? It was more just for exclusive searches, which can be very, very hard for products and engineering. +I think in diversity and inclusion, we really need to focus on different departments and the different problems that underrepresented communities encounter with different departments. So it was just really hard, but in terms of companies contacting me because I am a woman of color owning an agency, no, that didn't really...and it's never really helped. I do wear it as a badge of honor because, like I said, I started out with nothing. So to start out with nothing and have to fight through everything to sit at the table and create something is amazing. +My background didn't really help me. It was really just me, just constantly contacting people. And I was prepared for this because, in my entrepreneurship minor, they said, "You're going to encounter a lot of nos," and so I did. I encountered so many nos, but eventually, I was able to turn those nos into yeses. So now that I turned some of those nos into yeses...and I'm still encountering nos, but I still keep going and still building and building. +And now I do feel a sense of pride now two years later where it is like, wow, I really did have to fight through to make it, and that's where I hold just a huge sense of pride. But no, it was not my background that really...the only thing that my background was maybe appealing was thinking like, oh, okay, I think you can do diversity and inclusion, which I don't want to be profiled in that way. +I just want to be a founder who happens to be a Black woman instead of a Black woman founder. And so, I don't want to be contacted to feel like my race is a part of it. And that was interesting in the corporate workplace, especially when I was trying to navigate different, you know, how to speak, how to build rapport, or how to navigate corporate workplace conversations. +And that's very hard to do with diversity and inclusion because you're fighting with, like, that's racism and misogyny. That's something really deep-rooted, and that has been here for years and years. So it's a really heavy, heavy topic. And that's not some really, really heavy topic that you really want to bring or a lot of people don't really want to bring into the workplace. So that was just hard to encounter. +But overall, I so, so support diversity and inclusion. And the cool part is because I have this awareness and I know that diverse teams are better teams, whenever I'm sourcing, or one of my recruiters is sourcing, I'm just making sure that they have that in the front of their mind, and they're just trying to diversify their candidate pipeline as much as possible. +CHAD: Well, taking it from the candidate side of things, I, unfortunately, I'm of the belief that the hiring process is really ripe for extreme, subtle unconscious biases or conscious ones even to have an impact on the hiring process. So, how have you navigated that on the candidate side? I'm sure you don't want to say anything negative about any of your clients. It's not about, oh, this company is racist. But I think do you agree with the premise that the hiring process at a lot of companies is ripe for some bias to creep in? +ANNA: Of course. I mean, all of the time. And the part that's so, I would say, scary about it is that bias is something that you feel. It's not really tangible. You can't really grab it. I mean, it can be in writing, and [laughs] there has been stuff in writing. But it's very much kind of yeah; it's non-tangible. So it's hard to really call it out specifically of like, hmm, this candidate I don't know why all of a sudden nice to haves become must-haves. Why is there a shift? +Like I said, there are different problems with different departments, but there are also different problems in terms of leveling systems, so leadership roles versus individual contributor roles. There can be a little bit more, you know, maybe there's a little bit more openness on the IC side, but with leadership, it can get a little interesting sometimes. But the hard part is it's not really tangible. So I really have to give it to diversity like DEI specialists because to have to navigate those conversations and really articulate a non-tangible thing is so, so complicated. +So there are tangible things you can do, like having a diverse panel. But what happens if the company doesn't even have the numbers for diversity to have that diverse panel in the first place? So it can get really complicated in terms of trying to navigate the bias within the interview process, and we do try to do our best there, just trying to provide on our side because that's all we can do. It's really up to the companies in terms of their interview processes and how they are going to change it or maintain some stages. +But for us, we're just trying to just submit diverse talent and really just try to provide that white-glove service for them and hope that that bias doesn't seep in. But like I said, it's such a heavy topic. And like I said, with corporate workplace politics, it can be so fragile and really interesting. So it's just hard to really take that and understand where it comes from or being able to even verbalize it. So that's where it gets really interesting. +And so, I do hope that in the future, interview processes are changed where there is able to be a diverse panel, or there is a way to really be able to understand that bias. Because like I said, it's very complicated. And we don't want to claim that any company is specifically racist, but it's just understanding bias and maybe why there's a difference for one candidate versus another candidate, which can be really interesting. +CHAD: I think the first part is recognizing that everybody has biases, and it could be anything. It could be, well, what happens when you come across a resume of someone that went to the same school that you did? What happens to that resume, then? And does that subtly influence how you review that resume? It has nothing to do with their race or the color of their skin or anything. So those biases can creep in, and you need to decide as a company is this something that actually matters to success at the company? Is this something that we want to be using when we make hiring decisions about who gets that first interview or who continues on in the interview process? +For us, we've decided it's not, so we have a completely anonymous screening process where we don't even show the names of schools. We don't show the names of the companies that you worked at previously. We only show the positions that you held at those companies because we've decided that whether you have a degree or not doesn't matter, and the companies that you worked at previously don't matter. It's what you were actually able to do with that experience. +ANNA: Oh yeah. I think that's actually amazing. That's a really great way of doing it. I always just try to tell hiring managers also to just open that candidate pipeline as much as possible because the number one way to really understand someone isn't really through just a piece of paper. +Yes, we want to make sure that the resume is at least a bit aligned. And they have, if it's an engineering role, for example, the right tech stack or maybe the right technologies or the right kind of projects that they've worked on. But other than that, you'll be so amazed what can happen when people just hop on a call with each other. You can really find just that hidden genius in people. +So usually, when it comes to just diversity, it's like just hopping on a quick call with someone, anybody. Like you said, there are so many biases, but just being able to talk to them and see them as a human being can really just surprise you and surprise everybody. So really just, I always say just find that hidden genius through engaging with someone. +CHAD: Yeah. So you've mentioned time to hire is a really important thing moving quickly in today's market when candidates have a lot of opportunity. What are some other ways, either trends or things that are happening in the market or things that you see changing? +ANNA: Well, honey, I'm sure, as you know, there's been a huge amount of layoffs that have happened. Like, recently, about 17,000 workers were laid off from more than 70 tech startups globally in May, and that's been about a 350% jump from April. So I will say it's just due to inflation as well as just the slowing of demand. Startups right now are just really trying to just cut corners and just really trying to just hone in on their runway and their burn rate. +CHAD: Are the candidates that are being laid off finding new work quickly? +ANNA: I'm not sure because it depends on the departments. We're working with engineering mostly in product. So it's really funny because as we are tracking the layoffs, we will contact candidates to see if they're interested in another opportunity. Because fortunately, for our client list, we haven't had anyone have a massive amount of layoffs which has been...we're so happy about that, fortunately. But we've actually contacted engineers. And it's amazing how strong the engineering department is. It does not seem like they really are...that's not a department where there's like significant layoffs because they just have to uphold that platform. +So yeah, so it still is in terms of engineering surprising with all these layoffs. It still is just very much competitive because even the people who have or the companies that have encountered a large amount of layoffs those engineers are still wanting to stay or don't...there are some that may feel the need to depart at a certain point. But for the most part, they are staying. But in terms of how quickly, I'm not entirely sure in terms of for people that are laid off how quickly they are being hired because this is also within early-stage startups or not early-stage; they also have Fortune 500s too. But yeah, I'm not sure about that part. +But in terms of engineering specifically, the jobs are still just growing. The projected growth rate for software engineers is like 22%, and data scientists is 22%, as well as web developers is 13%. So fortunately for us, as an agency who primarily specializes in engineering, there hasn't been a huge difference. +But like I said, specifically with engineering, that time to hire is still super important because these candidates are still encountering offers quickly. And it's just a way to be competitive because if you're just the first offer, you're the first offer in their face instead of, let's say, they have two offers from another company and you're like at the last offer. It's such a big difference there. +CHAD: Are you seeing a lot of remote positions versus in-person positions? +ANNA: Yes, remote is still going strong. I have seen that now there is a little bit of a trend of some startups or companies where you know because I research companies every day...I'll go on Crunchbase, Morning Brew, VentureBeat, TechCrunch, Built-In. I'll go on all of the websites, and I'm seeing who got a fresh new round of funding or who's highly growing, or any new products that companies are offering. +CHAD: You're seeing some companies say that they're hiring hybrid or in person. +ANNA: I am seeing that on startups and companies' career pages, once they've acquired a new round of funding or they're scaling, that on the job boards, you'll start seeing only the headquarters, so just San Francisco or just maybe Boston instead of remote. So it's been a little bit more of a quiet transition because I remember when bigger companies were announcing it like, oh, we're going to transition in the office in February of 2022 or December of 2021, then there would all of a sudden be a mass exodus of people who were seeking remote opportunities. +But I do still feel that remote is still going strong, especially for high-growth startups, you know, yeah, still going strong. There is the option of hybrid. With these engineers that do have these choices, 100% remote is really becoming a great selling point. I mean, I don't even know if it's really a selling point but just standard now. +CHAD: So that's what you're hearing from candidates. Candidates want that. +ANNA: Definitely, candidates want. There's been plenty of candidates that we've interviewed where they've said in terms of their...because we'll ask them what would be their motivation for considering other opportunities and potentially leaving, and then they'll say, "X company is anticipating us to transition into the office, and I just don't want to do that." Their commute may be an hour, and that can be two even maybe three hours out of your day where you're spending your morning driving and then spending your evening driving. +So people just prefer to be remote. Or people are located now in the Midwest. They're going back to their hometowns where they're able to instead of like these big metropolitan cities where now it's really hard to afford a house, so they're going back home and being able to enjoy their family there. So definitely it is a standard and people are really interested in it. And for companies that are having employees transition back into the office, we've consistently heard that there's just a mass exodus of people leaving. +CHAD: What have you seen compensation do over the last year-plus? +ANNA: I would say for compensation, I mean, in my personal opinion, when it was super competitive, it was definitely increasing. Now I feel like we're working with a Fortune 500 company, so compensation hasn't really been too, too much of a problem. So yeah, it hasn't been as competitive. But I do remember when it was maybe around Q1 and Q2 2021 where there was almost this great rehire. And everybody was scaling, and demand was soaring where the salaries were just like, it just increased or were just consistently increasing. We were just so shocked at what some software engineers were making. +But now, it seems to have potentially tamed a little bit. It's not as high as it probably used to be because we were working with that series B Company and their salaries were pretty good, pretty competitive. But all of a sudden, with the demand soaring and these engineers, it started getting even more competitive. Then that's when all of a sudden, you know, the first few placements were fine. And then, all of a sudden, each candidate, like I said, they would say they were passively looking and then the next week... +And this startup their time to hire was actually really great. But even with this competitive market, it was still hard because, like I said, a week later, they would already have an offer. And their salary would probably increase like 20,000-30,000 from their initial target base that they were seeking to now what they were being hired from other companies. So it would definitely increase. But I haven't seen that recently as much. +CHAD: Yeah. I think also the trend to remote changed compensation, too, because it leveled it out. There were people who if you were trying to find a job in Kansas and you were going in an office, that market is very different than the U.S.-wide hiring market. But now, candidates are on the U.S.-wide hiring market. And I think that that brought up the lower end of salaries. +ANNA: Oh yes. Because at first, it was like okay, we can look for...it was 100% remote, which was great, and so they were like, we can look for people in the Midwest. But during that time, companies were paying San Francisco and New York salaries, and they were offering those salaries to people who were located in Kansas and Iowa. +So you would have engineers who were deep, deep in the Midwest who were asking for in terms of target for those metropolitan city salary budgets. And they would get it, which I think is great as well, just they are doing the same work as someone who is located in San Francisco or in New York but maybe with less overhead, of course. But it definitely was a little bit more of a challenge. And you can no longer assume that somebody located in the Midwest that may have lower salary bands aren't at those metropolitan city salary budgets now. +CHAD: Anna, thanks much for stopping by and sharing with us. I really I'm impressed by what you've accomplished so far. And I'm excited about what you're going to be able to do in the future. +ANNA: Thank you. Thank you so much, again, for inviting me. I had a great time speaking with you, and it was so interesting hearing about your time being a consultancy. Because I know being an external vendor, it's really interesting interacting with clients when you're not internal. So that was really interesting hearing about the difference of clients that you're encountering at first versus now. +CHAD: Yeah. If folks want to get in touch with Techie Staffing or get in touch with you, where are the best places for them to do that? +ANNA: So in terms of contacting me, I'll say the best way would be either our website so www.techiestaffing.com. Or you can contact me on LinkedIn; my name is Anna Spearman, A-N-N-A S-P-E-A-R-M-A-N. I'm always active on LinkedIn. So if you're seeking a new opportunity either on the candidate side or either meeting, help and engaging Techie Staffing as a scaling company to fill your engineering, design, UX, and product roles, you can contact me on LinkedIn as well as filling out the forms on the Techie Staffing website. And we also are on Twitter @StaffingTechie. So definitely contact us, and we'd be happy to hear from you. +CHAD: Wonderful. You can subscribe to the show and find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Anna Spearman. + + + Anna Spearman is the Founder of Techie Staffing, which connects high-quality technology talent with high-caliber clients.

+ +

Chad talks with Anna about founding and growing the company, immediately after graduating college, during a pandemic, reputation building, and facing skepticism around her lack of track record in recruiting, and finding and providing talent for clients as a white-glove service.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Anna Spearman, the Founder of Techie Staffing, which connects high-quality technology talent with high-caliber clients. Anna, thanks so much for joining me.

+ +

ANNA: Thank you so much for inviting me, Chad.

+ +

CHAD: In theory, at the surface level, Techie Staffing is probably fairly straightforward in terms of what you do. But I'm curious how you got started.

+ +

ANNA: Yes, of course. So I can't believe I'm saying this, but it's been two years. Two years ago, I was, during that time, attending the University of Virginia, where I was majoring in computer science with a minor in entrepreneurship. And in the spring of 2020, I was planning on coming back home to...I was born and raised in Los Angeles, and I was planning to come back home for spring break. And I was finishing out my second semester of senior year. So I was planning my [chuckles] victory lap of going back home, taking a little bit of a rest time, and then coming back to UVA to finish my degree, graduate, and move on to a new job in Los Angeles.

+ +

But unfortunately, as my plane was landing in Los Angeles, we kept hearing about COVID. And so the pandemic hit in the middle of my spring break. And during that time, I had to finish my second semester of senior year remote. It was very stressful, but when I finished the degree, I was so fulfilled. But unfortunately, there was a rapid dwindling of entry-level tech and product roles. I initially either wanted to be a software engineer or a product manager or be a software engineer that transitioned into a technical product manager.

+ +

But unfortunately, once the pandemic hit, companies weren't willing to ramp up entry-level talent. Companies didn't really know what was going to happen in the future, and everybody was remote. So it was just a really confusing time. But while I was searching through different job boards trying to find new opportunities, especially entry-level opportunities, I found just a wealth of senior tech jobs, specifically with companies that were thriving due to the pandemic. During that time, companies like Peloton, Discord, Zoom, they were all soaring due to the pandemic.

+ +

So I had heard about contingent recruiting in the past. My biggest dream for a new opportunity for myself graduating out of college was just to learn something new every day because I've always had a very much an interdisciplinary background. I've never been able to stay in one area. I've always loved to try different things. So with a little bit of a background recruiting at a past summer internship as well as wanting to utilize my entrepreneurship minor...I'm actually a fourth-generation woman entrepreneur. So definitely, growing up, creating my own business was my dream. So really, that was my main goal.

+ +

I thought I was going to transition from a current role into entrepreneurship, but I had my back against the wall. So I just thought, why not start now? So I created Techie Staffing, a technology staffing agency specializing in direct hire placements nationwide. I basically had my virtual graduation; then I took a week. And then, I got started creating the website, establishing the business paperwork, as well as developing strategic partnerships with senior technical recruiters that had full candidate pipelines to fill incoming job requisitions.

+ +

And I basically started off with nothing. I had no contacts, no network, just nothing at all. And I was really starting just fresh. So I really had to really spend a lot of time networking and developing relationships as well as just learning and mastering full lifecycle recruiting, especially with engineering since there's such a supply and demand issue for software engineers. So you're just consistently following up and contacting people that could potentially be interested in your companies. But it really blew up.

+ +

As I was establishing everything in 2020 from summer to the end of 2020, it was 2021 when it really blew up where I contacted this founder during the time they had raised a Series B 50 million, which was amazing, and they were going through a hiring sprint. So we got connected fairly quickly. And with just great team synergy, we were actually able to place five people in one month, and it was frontend, backend, and full-stack developers. So that really jump-started Techie Staffing.

+ +

And then after that, we worked with...we're now working with Fortune 500 companies as well as high-growth startups and really building a diversified portfolio, and we’re also a certified woman-owned business which I'm so proud of because there aren't really a lot of women or even just women of color that are founders. So I was really happy to get that certification, really proud of that as well.

+ +

I always say all the time to everybody it's super stressful, but it's so rewarding at the same time. And I do believe that it's honestly, you know, I know the pandemic has been super hard on people. And it's been such a change and such a shift. But there is still a part of me that is so grateful for making that pivot because I really found something that I feel like I really enjoy doing every day.

+ +

CHAD: That's great. I really commend you on everything you've done so far. And I'm excited about what you're going to do in the future. You now have grown where you're multiple people on your team.

+ +

ANNA: Yeah, so we actually hired two new people fairly recently. I did have one direct hire recruiter working with me. So now it's officially a team of four. I did develop the strategic part. I do still have some strategic partnerships as well because on that part, at first, I was partnering with recruiters that were independent, so who were a little bit more entrepreneurial so that we could split the placement fee. But it's still better to just have full-time employees. I'm so excited to have two new additional hires, and it's still new for me.

+ +

So I'm really looking forward to growing together in terms of growing Techie Staffing and growing into being a full life cycle recruiter because it wasn't that long ago when I was in that same exact spot. And it's so amazing. It still blows my mind to this day how two years ago, thinking about interviewing candidates or selling to clients, and now what I've evolved in. It's been absolutely amazing.

+ +

So I'm so happy to see their journey and seeing them transition into being technical recruiters and also making a pivot in their career as well, which that's still blowing my mind a little bit. I'm sure you know founding thoughtbot and really building that from the ground up. So it's just amazing seeing that infrastructure. It just really brings a brighter future as well.

+ +

CHAD: So what kind of people do you look for when you're looking to add to your team? Are you bringing on people who have experience with recruiting? Or are you bringing on people who are transitioning into it?

+ +

ANNA: I would say for Q1 and Q2 of 2022 and even a little bit beforehand, since there was a surge in demand for everything and tech companies were just scaling like crazy, there was very much a competitive market for recruiters, specifically technical recruiters. Because that's what companies were really looking for to scale their engineering and product teams. So it was very, very competitive to recruit for a technical recruiter.

+ +

So now you see agencies now who are hiring people who can have the DNA for a technical recruiter but not necessarily have direct experience, which I think can be really, really cool. Because like I said, like two years ago, I knew absolutely nothing, and now I feel very much confident in the full life cycle. So I think that's really cool to have people be able to pivot into a really cool industry where you're really learning something new every day, and you're speaking to really interesting people.

+ +

We specialize in senior up until C-suite, so yeah, learning from people who are senior all the way up to Director, VP. So it's really interesting. So when I was approaching hiring, I really wanted to find someone who had that DNA that can potentially transition to being a technical recruiter. And that DNA would be, you know, it doesn't have to be personality but just really interacting with engineers, just maybe being a self-starter.

+ +

I would say great communication, and lastly, I would say just really hungry. Yes, I would say hungry. Because if you're really hungry and you're really willing to learn and be open, so openness as well, then you can really understand the rules or just the lifecycle and the process of being a recruiter, and then you can change people's lives.

+ +

I actually had one...It was about a year ago, I was working with a Fortune 500 company, and I recruited this guy, and I led him through the process. And it was about maybe a month later when he told me I had basically changed his life. Him and his family were now moving to Atlanta, and it was a new role, and it was just a fresh start. And he was just telling me how appreciative he was of me, and so that really hit home. So I think for those two new hires, I'm so excited to have them get super engaged and be able to change other people's lives as well under the Techie Staffing name, of course.

+ +

CHAD: You mentioned early on that you're contingent recruiting. So correct me if I'm wrong, but that means that you get paid when you place somebody, when someone gets hired from the company that hires them.

+ +

ANNA: Yes.

+ +

CHAD: But then you also mentioned that these people who you're bringing onto your team are full-time. So how does the compensation structure typically work for them?

+ +

ANNA: Oh, compensation, we have them on salary, but they do have commission. So we wanted to really give; like I said, I want us to grow together. So I do provide commission for each placement they'll place just to really provide incentive. Like I said, it's so early. I want us to think of each other just as teammates and a team because we're all building towards the same goal.

+ +

So just really wanted to provide incentives where they're really feeling like they're almost owning it full life cycle as well. Because like I said, it's early on, and these can be really strong pillars in the future. So there is salary, but there's also that commission as well to just really provide that incentive. And I know for me personally, incentive can be awesome, so definitely trying to provide that motivation and having them really feel like they're an integral part.

+ +

CHAD: What's the harder part of your business? Or are they equally hard, finding new clients versus finding people who want to work with you on the candidate side?

+ +

ANNA: On the business development side, I would say it was harder perhaps in the beginning because I just so was starting with nothing, really. I had just graduated from college. And a lot of agency owners they previously have maybe worked at a really cool tech startup, or maybe they've been working on their agencies for the past 5 or 10 years. They have previous years of experience, but I didn't have that.

+ +

So I had to convey another method of just really networking, really meeting people, and just really knowing my stuff and having a handle on it. I know maybe a lot of people say, like, just fake it until you make it because then once you make it, and then you get that experience, then you can transfer that experience to new experiences as well. So at first, it was really just building myself up and building the Techie Staffing brand so that we could acquire those clients.

+ +

In terms of the candidate side, I would say Techie Staffing, and one of the things and part of our brand that we love to portray is that we are the agency that has the companies with the best employer branding. Because like I said, with the supply and demand issue for the software engineers, it is so competitive to attract them to new opportunities. There are just so many companies that are contacting them multiple times a day. So there has to be at least a little bit of a shine or a little bit of a differentiator for companies that you're recruiting for.

+ +

So we actually specialize in companies that are Series B and above that do have that established employer branding where engineers are really interested in joining that company, so that's just the thing. It's like really having companies that have strong employer branding and being able to follow up. Follow-ups are really, really important when it comes to engaging engineers because, like I said, it's just a super competitive market and just trying to provide them a great white-glove experience. There are some agencies that fall a little bit too close to the client-side where the client is always right.

+ +

And there are some that fall too much to the candidate side where the candidate is right, but we really want to be a balanced middleman where we're just trying to find the compromise and find the best solution for everybody. So that's the real important part of it of just really providing them with a great experience and showing them that we care and that we're rooting for them.

+ +

Because it sometimes does surprise me when candidates can be a little...maybe this is a part of me being new. But that's kind of an advantage, too, because I'm still paying attention to detail. That's where my computer science major comes in. It's like constantly trying to stay in tune with candidates and what they need, so just trying to provide a great experience in general. And I'm sure you feel that way with your clients. You're a consultancy as well where you're trying to be B2B and contact these different companies. So how do you conduct business development and really differentiate yourself?

+ +

CHAD: We focused a lot on reputation building, so blogging, creating open source so that we don't need, fortunately, to cold contact people. And when we do, we're fortunate enough that they might already know about us. And so it's an easier conversation to have because they may already be reading our blog, or they may already be using some of our open source in their product. And so it becomes an easier conversation to have. But the majority of our clients actually come to us when they have a need because we're fortunate enough to have worked to be at the top of the list.

+ +

ANNA: Definitely, yeah. And I'm still doing that, just reputation building. With one of our Fortune 500, we're doing incredibly well with them to the point where we're filling their pipelines, and we have majority of our candidates in their pipeline. So that's what we're really working on right now is just consistently...and I know like with any business, you have to just constantly build that reputation. So I especially just try to provide a great experience for candidates because they can also be hiring managers as well, so just really providing that white-glove experience.

+ +

And also, a cool differentiator we always like to showcase is like, I'm a computer science major. And actually, the two people that I just hired have a tech background. So it's not like tech is entirely foreign to us. We've engaged with programming languages. We've coded projects. So we do have some form of understanding when it comes to certain technologies or certain projects that certain engineers are working on.

+ +

And that's what really gets me excited to speak with engineers because it's so cool and interesting hearing about them working on their projects and working on projects that directly affect me and the products that I'm interacting with. So it's so cool to hear about their...I can understand a bit. And so that's another thing we have with Techie Staffing is really finding people who have a bit of a tech background so at least they have a little bit of knowledge or an understanding of what projects and can be able to really share and convey that to clients that are looking for this talent.

+ +

CHAD: You mentioned it's a really competitive market now. And as a company who probably has multiple clients, how do you minimize or how do you deal with the potential competition for the limited supply among your own clients?

+ +

ANNA: Among my own clients, I will say that right now we don't have...for the roles that we're working on for each client, they're not very similar or too, too similar, which is a good thing. We would like it in the future where we could have the same role, but we can understand how that can be a little tricky as well.

+ +

CHAD: And how do they differ then? Are they differing by the technology experience that they're looking for or the sort of level of the role? How are they different?

+ +

ANNA: It could be technology, difference of the role. So, for example, for a Fortune 500 company that we're working with, we'll work more with UX, data science, data science roles, as well as...so UX, data science. And then for high-growth startups, mostly with them, they're really looking for back-end engineers, but overall just engineering so frontend, backend, DevOps. We are working potentially to do engineering or more engineering-heavy for our Fortune 500 companies. We have recently been working on a VP of engineering.

+ +

So for Fortune 500 for now, we've been working more with leadership roles especially, and for high-growth, it's been more engineering IC. But we would like to transition that in the future to have it kind of...or have roles that maybe some candidates could go to this company, and some candidates can go to that startup. And then another differentiator could be or what makes our clientele different from each other is for high-growth startups, especially for engineering ICs, they're really looking for candidates that come from high-growth startups who just understand the current company where they are, and how they're scaling during that period of time around that series B and series C. That's the time to really scale.

+ +

And Fortune 500 companies they can be open to startups, but for the most part, especially sometimes for leaders who need to have a certain amount of direct reports, they're more looking for people from larger companies. So that would be one way to kind of separate it and so we're not having candidates almost be where they have to compete with candidates within our own company. Because with the difference in the leveling of companies, there's just a difference in what kind of candidates that they're looking for.

+ +

Mid-Roll Ad:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: url tbot.io/devops

+ +

CHAD: When I was first starting thoughtbot, I really felt like I needed to take every client that we could get because we were just starting out. We needed to make money. We needed to build a reputation. And so, I felt like we needed to say yes to every client. Over the years, I learned that that was actually watering us down, and it made us less successful. And the more we were clear about who we were, and what we did, and what clients we were best for, the more successful we were. Have you gotten to the point where you needed to turn down clients?

+ +

ANNA: Because I do such targeted biz dev, we will contact companies that we personally want to work with. But I will say in the beginning, there were some companies that were a lot smaller that, just like you said, you just felt the need to want to rack up a client list. And you just are ready to go and wanting to work with someone. It really motivated me to really take a look and really go deep into the type of clients that we want. So, for example, really, really early-stage companies can have a really, really hard time hiring because, like I said, employer branding is so, so important.

+ +

And so usually what they'll have is maybe like mission, but they won't really have salary. Or they won't really have the employer branding of the company of candidates either knowing about the company or being able to search the company really quickly and seeing the platform that the company is building and seeing how strong it is. So it's really, really hard to recruit for those stages. I mean, it is possible, but it's just really hard.

+ +

And then at the same time for these early-stage companies, they really want to, which I totally understand, you know, when you're having your probably 8th, 9th, or 10th engineer and being on the founding team, you really want a strong engineer because that's your platform, that's your baby. You don't want anybody that, you know, it could potentially maybe cause problems, or they really want somebody there they can trust. And so it's hard, you know like I said --

+ +

CHAD: But they might not be able to afford that. [laughs]

+ +

ANNA: Yes, they might either not be able to afford it, or they also cannot interview fast enough in order to just get the offer in their hands. Because I understand they really want to have them speak to the entire team and have them have an in-depth process because it's very much an important role. But these candidates and startups are moving so fast right now where I will speak to a candidate one day, and he or she or they'll probably say, "Oh, you know, I'm passively looking. I'm not really actively looking." And maybe a week and a half to two weeks later, they're like, "Oh, I actually have two offers in hand."

+ +

So it goes really, really fast versus earlier stage; it can just go a little bit slower because they're just really taking the time to go more in-depth and see if this prospective candidate is the right fit, which is totally understandable. But it was just really hard for us as contingent trying to find that candidate, that perfect candidate for them as well as trying to keep candidates warm and keep them interested when some companies just have like mission.

+ +

So now, in the future, I've just really, like I said, Techie Staffing, we specialize from Series B and above. And I really just make sure during business development exploratory chats that I'm really going in-depth and making sure I understand the roles that they're prioritizing their time to hire. So if they have a long, long interview process and a really, really low salary in terms of the competitive market, then I may not be as interested in that startup as opposed to another startup whose interview process timeline could be about a week and a half to two weeks.

+ +

And it doesn't have to be absolutely amazingly competitive base salary but just a fairly competitive salary with a great timeline for time to hire. So that's been my way of just condensing or just being a little bit more pickier in terms of clients in the future. Were there any certain clients for you where you started working with them, and you were like, "Oh, maybe I shouldn't have," that's now caused you to be a little bit more pickier for clients in the future?

+ +

CHAD: Part of it was the kind of work. So we really wanted to be writing software. But just starting out, I also had a background in sort of IT support. And so, when I was reaching out, particularly to past clients, they might say, "You built our website. Now can you help us with purchasing a computer or setting up a computer network in our office?"

+ +

I felt compelled to say, "Yes," because I felt like we needed all the work we could get. But by doing that work that wasn't really what we wanted to be doing, we were not only less happy in our work, but it was taking time and attention away from the work that we really wanted to be doing.

+ +

The other was values and practices, which took a little bit longer to form a real understanding of what our values were and the practices that we believe in. But now there's a pretty clear list of the kinds of companies that...what we say at thoughtbot is that we want to work on things that deserve to exist in the world.

+ +

And so there's a whole bunch of industries that they might not even be actively doing harm in the world, but they are the ones that we wouldn't work in. But even if it's just not a positive contribution to the world, it's probably not going to be something that we're excited to work on.

+ +

ANNA: That's been an exciting trend, actually, to speak with engineers about. I've started seeing that trend where engineers are saying, "I don't want to create anything evil," or "I just want to do good." And that's been a really awesome selling point for some teams. It definitely is a cherry on top where engineers are really looking for social impact. And the cool part is they have so many opportunities that are coming towards them that they can really pick and choose which one. So to find people who are really looking for social good and just really mission-driven products is amazing to see.

+ +

And I'm really happy with the work...I'm actually working with a data science team for AI ethics. And that's been really interesting hearing some people talk about their projects and hearing about how data can really not only just strengthen bias but also can just really produce results that can harm certain groups of people, which is so interesting. And it can be something so, so small that I haven't even noticed at all, but that can lead to a big difference.

+ +

CHAD: Yeah, we've had several episodes about that.

+ +

ANNA: And it's amazing. And it really is just a huge difference with something so small. And as a woman of color, I'm always aware of what's going on in terms of just ethical practices or just fairness and seeing bias. But in terms of data, seeing something so so small can affect just a whole group of underrepresented people is just amazing to see. But it's also amazing that people or data scientists are now aware of it, and now they're changing it so that it no longer...at least they'll be able to alleviate that bias.

+ +

CHAD: I want to ask a little bit more about that, and then I want to talk about some market trends. But if you're comfortable, I'm curious; you already mentioned you were just out of college when you were getting started. So there was skepticism around your lack of track record in recruiting. And you've mentioned that you are a woman of color.

+ +

And so I think as engineers, as people in the market, we probably have this image in our head of what a typical recruiter looks like in terms of attitude, and values, and demographics. And you don't fit that mold in almost any way, basically. Is this actually a positive for you now, or is it actually still hard? Are there companies that are actively seeking out to work with you because they want that different approach? Or are you still facing that skepticism?

+ +

ANNA: I'm still facing that skepticism. I actually created Techie Staffing around the time of summer 2020, where Black Lives Matter, where George Floyd happened. And it was really interesting because I was entering the corporate workplace. I went to a really wealthy private school in Los Angeles. And I went to the University of Virginia. So I survived two PWIs which means predominantly White institutions. So I thought I had not seen it all, but I thought I had maybe experienced those experiences of bias and understood it a little bit more.

+ +

But when I went to the corporate workplace and the diversity inclusion campaigns were happening, it was just really confusing because it's hard specifically for engineering and product specifically because it's so new that there is a really, really hard time to find diverse talent. That's why I honestly believe that it's just really trying to educate underrepresented communities to understanding all of the different diverse types of roles and opportunities that you can encounter in the tech industry so, for example, like UX, UX design, UX research, data science, machine learning, all of that.

+ +

So I think I was more contacted or maybe was engaged in business development companies who were looking for me to do diversity which I think it kind of...and I am such a huge proponent for diversity. But it also kind of had my heart drop a little bit because I just felt like people were contacting me because of who I am instead of just thinking like if it was just any other agency, would I be contacted specifically for that? It was more just for exclusive searches, which can be very, very hard for products and engineering.

+ +

I think in diversity and inclusion, we really need to focus on different departments and the different problems that underrepresented communities encounter with different departments. So it was just really hard, but in terms of companies contacting me because I am a woman of color owning an agency, no, that didn't really...and it's never really helped. I do wear it as a badge of honor because, like I said, I started out with nothing. So to start out with nothing and have to fight through everything to sit at the table and create something is amazing.

+ +

My background didn't really help me. It was really just me, just constantly contacting people. And I was prepared for this because, in my entrepreneurship minor, they said, "You're going to encounter a lot of nos," and so I did. I encountered so many nos, but eventually, I was able to turn those nos into yeses. So now that I turned some of those nos into yeses...and I'm still encountering nos, but I still keep going and still building and building.

+ +

And now I do feel a sense of pride now two years later where it is like, wow, I really did have to fight through to make it, and that's where I hold just a huge sense of pride. But no, it was not my background that really...the only thing that my background was maybe appealing was thinking like, oh, okay, I think you can do diversity and inclusion, which I don't want to be profiled in that way.

+ +

I just want to be a founder who happens to be a Black woman instead of a Black woman founder. And so, I don't want to be contacted to feel like my race is a part of it. And that was interesting in the corporate workplace, especially when I was trying to navigate different, you know, how to speak, how to build rapport, or how to navigate corporate workplace conversations.

+ +

And that's very hard to do with diversity and inclusion because you're fighting with, like, that's racism and misogyny. That's something really deep-rooted, and that has been here for years and years. So it's a really heavy, heavy topic. And that's not some really, really heavy topic that you really want to bring or a lot of people don't really want to bring into the workplace. So that was just hard to encounter.

+ +

But overall, I so, so support diversity and inclusion. And the cool part is because I have this awareness and I know that diverse teams are better teams, whenever I'm sourcing, or one of my recruiters is sourcing, I'm just making sure that they have that in the front of their mind, and they're just trying to diversify their candidate pipeline as much as possible.

+ +

CHAD: Well, taking it from the candidate side of things, I, unfortunately, I'm of the belief that the hiring process is really ripe for extreme, subtle unconscious biases or conscious ones even to have an impact on the hiring process. So, how have you navigated that on the candidate side? I'm sure you don't want to say anything negative about any of your clients. It's not about, oh, this company is racist. But I think do you agree with the premise that the hiring process at a lot of companies is ripe for some bias to creep in?

+ +

ANNA: Of course. I mean, all of the time. And the part that's so, I would say, scary about it is that bias is something that you feel. It's not really tangible. You can't really grab it. I mean, it can be in writing, and [laughs] there has been stuff in writing. But it's very much kind of yeah; it's non-tangible. So it's hard to really call it out specifically of like, hmm, this candidate I don't know why all of a sudden nice to haves become must-haves. Why is there a shift?

+ +

Like I said, there are different problems with different departments, but there are also different problems in terms of leveling systems, so leadership roles versus individual contributor roles. There can be a little bit more, you know, maybe there's a little bit more openness on the IC side, but with leadership, it can get a little interesting sometimes. But the hard part is it's not really tangible. So I really have to give it to diversity like DEI specialists because to have to navigate those conversations and really articulate a non-tangible thing is so, so complicated.

+ +

So there are tangible things you can do, like having a diverse panel. But what happens if the company doesn't even have the numbers for diversity to have that diverse panel in the first place? So it can get really complicated in terms of trying to navigate the bias within the interview process, and we do try to do our best there, just trying to provide on our side because that's all we can do. It's really up to the companies in terms of their interview processes and how they are going to change it or maintain some stages.

+ +

But for us, we're just trying to just submit diverse talent and really just try to provide that white-glove service for them and hope that that bias doesn't seep in. But like I said, it's such a heavy topic. And like I said, with corporate workplace politics, it can be so fragile and really interesting. So it's just hard to really take that and understand where it comes from or being able to even verbalize it. So that's where it gets really interesting.

+ +

And so, I do hope that in the future, interview processes are changed where there is able to be a diverse panel, or there is a way to really be able to understand that bias. Because like I said, it's very complicated. And we don't want to claim that any company is specifically racist, but it's just understanding bias and maybe why there's a difference for one candidate versus another candidate, which can be really interesting.

+ +

CHAD: I think the first part is recognizing that everybody has biases, and it could be anything. It could be, well, what happens when you come across a resume of someone that went to the same school that you did? What happens to that resume, then? And does that subtly influence how you review that resume? It has nothing to do with their race or the color of their skin or anything. So those biases can creep in, and you need to decide as a company is this something that actually matters to success at the company? Is this something that we want to be using when we make hiring decisions about who gets that first interview or who continues on in the interview process?

+ +

For us, we've decided it's not, so we have a completely anonymous screening process where we don't even show the names of schools. We don't show the names of the companies that you worked at previously. We only show the positions that you held at those companies because we've decided that whether you have a degree or not doesn't matter, and the companies that you worked at previously don't matter. It's what you were actually able to do with that experience.

+ +

ANNA: Oh yeah. I think that's actually amazing. That's a really great way of doing it. I always just try to tell hiring managers also to just open that candidate pipeline as much as possible because the number one way to really understand someone isn't really through just a piece of paper.

+ +

Yes, we want to make sure that the resume is at least a bit aligned. And they have, if it's an engineering role, for example, the right tech stack or maybe the right technologies or the right kind of projects that they've worked on. But other than that, you'll be so amazed what can happen when people just hop on a call with each other. You can really find just that hidden genius in people.

+ +

So usually, when it comes to just diversity, it's like just hopping on a quick call with someone, anybody. Like you said, there are so many biases, but just being able to talk to them and see them as a human being can really just surprise you and surprise everybody. So really just, I always say just find that hidden genius through engaging with someone.

+ +

CHAD: Yeah. So you've mentioned time to hire is a really important thing moving quickly in today's market when candidates have a lot of opportunity. What are some other ways, either trends or things that are happening in the market or things that you see changing?

+ +

ANNA: Well, honey, I'm sure, as you know, there's been a huge amount of layoffs that have happened. Like, recently, about 17,000 workers were laid off from more than 70 tech startups globally in May, and that's been about a 350% jump from April. So I will say it's just due to inflation as well as just the slowing of demand. Startups right now are just really trying to just cut corners and just really trying to just hone in on their runway and their burn rate.

+ +

CHAD: Are the candidates that are being laid off finding new work quickly?

+ +

ANNA: I'm not sure because it depends on the departments. We're working with engineering mostly in product. So it's really funny because as we are tracking the layoffs, we will contact candidates to see if they're interested in another opportunity. Because fortunately, for our client list, we haven't had anyone have a massive amount of layoffs which has been...we're so happy about that, fortunately. But we've actually contacted engineers. And it's amazing how strong the engineering department is. It does not seem like they really are...that's not a department where there's like significant layoffs because they just have to uphold that platform.

+ +

So yeah, so it still is in terms of engineering surprising with all these layoffs. It still is just very much competitive because even the people who have or the companies that have encountered a large amount of layoffs those engineers are still wanting to stay or don't...there are some that may feel the need to depart at a certain point. But for the most part, they are staying. But in terms of how quickly, I'm not entirely sure in terms of for people that are laid off how quickly they are being hired because this is also within early-stage startups or not early-stage; they also have Fortune 500s too. But yeah, I'm not sure about that part.

+ +

But in terms of engineering specifically, the jobs are still just growing. The projected growth rate for software engineers is like 22%, and data scientists is 22%, as well as web developers is 13%. So fortunately for us, as an agency who primarily specializes in engineering, there hasn't been a huge difference.

+ +

But like I said, specifically with engineering, that time to hire is still super important because these candidates are still encountering offers quickly. And it's just a way to be competitive because if you're just the first offer, you're the first offer in their face instead of, let's say, they have two offers from another company and you're like at the last offer. It's such a big difference there.

+ +

CHAD: Are you seeing a lot of remote positions versus in-person positions?

+ +

ANNA: Yes, remote is still going strong. I have seen that now there is a little bit of a trend of some startups or companies where you know because I research companies every day...I'll go on Crunchbase, Morning Brew, VentureBeat, TechCrunch, Built-In. I'll go on all of the websites, and I'm seeing who got a fresh new round of funding or who's highly growing, or any new products that companies are offering.

+ +

CHAD: You're seeing some companies say that they're hiring hybrid or in person.

+ +

ANNA: I am seeing that on startups and companies' career pages, once they've acquired a new round of funding or they're scaling, that on the job boards, you'll start seeing only the headquarters, so just San Francisco or just maybe Boston instead of remote. So it's been a little bit more of a quiet transition because I remember when bigger companies were announcing it like, oh, we're going to transition in the office in February of 2022 or December of 2021, then there would all of a sudden be a mass exodus of people who were seeking remote opportunities.

+ +

But I do still feel that remote is still going strong, especially for high-growth startups, you know, yeah, still going strong. There is the option of hybrid. With these engineers that do have these choices, 100% remote is really becoming a great selling point. I mean, I don't even know if it's really a selling point but just standard now.

+ +

CHAD: So that's what you're hearing from candidates. Candidates want that.

+ +

ANNA: Definitely, candidates want. There's been plenty of candidates that we've interviewed where they've said in terms of their...because we'll ask them what would be their motivation for considering other opportunities and potentially leaving, and then they'll say, "X company is anticipating us to transition into the office, and I just don't want to do that." Their commute may be an hour, and that can be two even maybe three hours out of your day where you're spending your morning driving and then spending your evening driving.

+ +

So people just prefer to be remote. Or people are located now in the Midwest. They're going back to their hometowns where they're able to instead of like these big metropolitan cities where now it's really hard to afford a house, so they're going back home and being able to enjoy their family there. So definitely it is a standard and people are really interested in it. And for companies that are having employees transition back into the office, we've consistently heard that there's just a mass exodus of people leaving.

+ +

CHAD: What have you seen compensation do over the last year-plus?

+ +

ANNA: I would say for compensation, I mean, in my personal opinion, when it was super competitive, it was definitely increasing. Now I feel like we're working with a Fortune 500 company, so compensation hasn't really been too, too much of a problem. So yeah, it hasn't been as competitive. But I do remember when it was maybe around Q1 and Q2 2021 where there was almost this great rehire. And everybody was scaling, and demand was soaring where the salaries were just like, it just increased or were just consistently increasing. We were just so shocked at what some software engineers were making.

+ +

But now, it seems to have potentially tamed a little bit. It's not as high as it probably used to be because we were working with that series B Company and their salaries were pretty good, pretty competitive. But all of a sudden, with the demand soaring and these engineers, it started getting even more competitive. Then that's when all of a sudden, you know, the first few placements were fine. And then, all of a sudden, each candidate, like I said, they would say they were passively looking and then the next week...

+ +

And this startup their time to hire was actually really great. But even with this competitive market, it was still hard because, like I said, a week later, they would already have an offer. And their salary would probably increase like 20,000-30,000 from their initial target base that they were seeking to now what they were being hired from other companies. So it would definitely increase. But I haven't seen that recently as much.

+ +

CHAD: Yeah. I think also the trend to remote changed compensation, too, because it leveled it out. There were people who if you were trying to find a job in Kansas and you were going in an office, that market is very different than the U.S.-wide hiring market. But now, candidates are on the U.S.-wide hiring market. And I think that that brought up the lower end of salaries.

+ +

ANNA: Oh yes. Because at first, it was like okay, we can look for...it was 100% remote, which was great, and so they were like, we can look for people in the Midwest. But during that time, companies were paying San Francisco and New York salaries, and they were offering those salaries to people who were located in Kansas and Iowa.

+ +

So you would have engineers who were deep, deep in the Midwest who were asking for in terms of target for those metropolitan city salary budgets. And they would get it, which I think is great as well, just they are doing the same work as someone who is located in San Francisco or in New York but maybe with less overhead, of course. But it definitely was a little bit more of a challenge. And you can no longer assume that somebody located in the Midwest that may have lower salary bands aren't at those metropolitan city salary budgets now.

+ +

CHAD: Anna, thanks much for stopping by and sharing with us. I really I'm impressed by what you've accomplished so far. And I'm excited about what you're going to be able to do in the future.

+ +

ANNA: Thank you. Thank you so much, again, for inviting me. I had a great time speaking with you, and it was so interesting hearing about your time being a consultancy. Because I know being an external vendor, it's really interesting interacting with clients when you're not internal. So that was really interesting hearing about the difference of clients that you're encountering at first versus now.

+ +

CHAD: Yeah. If folks want to get in touch with Techie Staffing or get in touch with you, where are the best places for them to do that?

+ +

ANNA: So in terms of contacting me, I'll say the best way would be either our website so www.techiestaffing.com. Or you can contact me on LinkedIn; my name is Anna Spearman, A-N-N-A S-P-E-A-R-M-A-N. I'm always active on LinkedIn. So if you're seeking a new opportunity either on the candidate side or either meeting, help and engaging Techie Staffing as a scaling company to fill your engineering, design, UX, and product roles, you can contact me on LinkedIn as well as filling out the forms on the Techie Staffing website. And we also are on Twitter @StaffingTechie. So definitely contact us, and we'd be happy to hear from you.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Anna Spearman.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Anna Spearman is the Founder of Techie Staffing, which connects high-quality technology talent with high-caliber clients.

+ +

Chad talks with Anna about founding and growing the company, immediately after graduating college, during a pandemic, reputation building, and facing skepticism around her lack of track record in recruiting, and finding and providing talent for clients as a white-glove service.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Anna Spearman, the Founder of Techie Staffing, which connects high-quality technology talent with high-caliber clients. Anna, thanks so much for joining me.

+ +

ANNA: Thank you so much for inviting me, Chad.

+ +

CHAD: In theory, at the surface level, Techie Staffing is probably fairly straightforward in terms of what you do. But I'm curious how you got started.

+ +

ANNA: Yes, of course. So I can't believe I'm saying this, but it's been two years. Two years ago, I was, during that time, attending the University of Virginia, where I was majoring in computer science with a minor in entrepreneurship. And in the spring of 2020, I was planning on coming back home to...I was born and raised in Los Angeles, and I was planning to come back home for spring break. And I was finishing out my second semester of senior year. So I was planning my [chuckles] victory lap of going back home, taking a little bit of a rest time, and then coming back to UVA to finish my degree, graduate, and move on to a new job in Los Angeles.

+ +

But unfortunately, as my plane was landing in Los Angeles, we kept hearing about COVID. And so the pandemic hit in the middle of my spring break. And during that time, I had to finish my second semester of senior year remote. It was very stressful, but when I finished the degree, I was so fulfilled. But unfortunately, there was a rapid dwindling of entry-level tech and product roles. I initially either wanted to be a software engineer or a product manager or be a software engineer that transitioned into a technical product manager.

+ +

But unfortunately, once the pandemic hit, companies weren't willing to ramp up entry-level talent. Companies didn't really know what was going to happen in the future, and everybody was remote. So it was just a really confusing time. But while I was searching through different job boards trying to find new opportunities, especially entry-level opportunities, I found just a wealth of senior tech jobs, specifically with companies that were thriving due to the pandemic. During that time, companies like Peloton, Discord, Zoom, they were all soaring due to the pandemic.

+ +

So I had heard about contingent recruiting in the past. My biggest dream for a new opportunity for myself graduating out of college was just to learn something new every day because I've always had a very much an interdisciplinary background. I've never been able to stay in one area. I've always loved to try different things. So with a little bit of a background recruiting at a past summer internship as well as wanting to utilize my entrepreneurship minor...I'm actually a fourth-generation woman entrepreneur. So definitely, growing up, creating my own business was my dream. So really, that was my main goal.

+ +

I thought I was going to transition from a current role into entrepreneurship, but I had my back against the wall. So I just thought, why not start now? So I created Techie Staffing, a technology staffing agency specializing in direct hire placements nationwide. I basically had my virtual graduation; then I took a week. And then, I got started creating the website, establishing the business paperwork, as well as developing strategic partnerships with senior technical recruiters that had full candidate pipelines to fill incoming job requisitions.

+ +

And I basically started off with nothing. I had no contacts, no network, just nothing at all. And I was really starting just fresh. So I really had to really spend a lot of time networking and developing relationships as well as just learning and mastering full lifecycle recruiting, especially with engineering since there's such a supply and demand issue for software engineers. So you're just consistently following up and contacting people that could potentially be interested in your companies. But it really blew up.

+ +

As I was establishing everything in 2020 from summer to the end of 2020, it was 2021 when it really blew up where I contacted this founder during the time they had raised a Series B 50 million, which was amazing, and they were going through a hiring sprint. So we got connected fairly quickly. And with just great team synergy, we were actually able to place five people in one month, and it was frontend, backend, and full-stack developers. So that really jump-started Techie Staffing.

+ +

And then after that, we worked with...we're now working with Fortune 500 companies as well as high-growth startups and really building a diversified portfolio, and we’re also a certified woman-owned business which I'm so proud of because there aren't really a lot of women or even just women of color that are founders. So I was really happy to get that certification, really proud of that as well.

+ +

I always say all the time to everybody it's super stressful, but it's so rewarding at the same time. And I do believe that it's honestly, you know, I know the pandemic has been super hard on people. And it's been such a change and such a shift. But there is still a part of me that is so grateful for making that pivot because I really found something that I feel like I really enjoy doing every day.

+ +

CHAD: That's great. I really commend you on everything you've done so far. And I'm excited about what you're going to do in the future. You now have grown where you're multiple people on your team.

+ +

ANNA: Yeah, so we actually hired two new people fairly recently. I did have one direct hire recruiter working with me. So now it's officially a team of four. I did develop the strategic part. I do still have some strategic partnerships as well because on that part, at first, I was partnering with recruiters that were independent, so who were a little bit more entrepreneurial so that we could split the placement fee. But it's still better to just have full-time employees. I'm so excited to have two new additional hires, and it's still new for me.

+ +

So I'm really looking forward to growing together in terms of growing Techie Staffing and growing into being a full life cycle recruiter because it wasn't that long ago when I was in that same exact spot. And it's so amazing. It still blows my mind to this day how two years ago, thinking about interviewing candidates or selling to clients, and now what I've evolved in. It's been absolutely amazing.

+ +

So I'm so happy to see their journey and seeing them transition into being technical recruiters and also making a pivot in their career as well, which that's still blowing my mind a little bit. I'm sure you know founding thoughtbot and really building that from the ground up. So it's just amazing seeing that infrastructure. It just really brings a brighter future as well.

+ +

CHAD: So what kind of people do you look for when you're looking to add to your team? Are you bringing on people who have experience with recruiting? Or are you bringing on people who are transitioning into it?

+ +

ANNA: I would say for Q1 and Q2 of 2022 and even a little bit beforehand, since there was a surge in demand for everything and tech companies were just scaling like crazy, there was very much a competitive market for recruiters, specifically technical recruiters. Because that's what companies were really looking for to scale their engineering and product teams. So it was very, very competitive to recruit for a technical recruiter.

+ +

So now you see agencies now who are hiring people who can have the DNA for a technical recruiter but not necessarily have direct experience, which I think can be really, really cool. Because like I said, like two years ago, I knew absolutely nothing, and now I feel very much confident in the full life cycle. So I think that's really cool to have people be able to pivot into a really cool industry where you're really learning something new every day, and you're speaking to really interesting people.

+ +

We specialize in senior up until C-suite, so yeah, learning from people who are senior all the way up to Director, VP. So it's really interesting. So when I was approaching hiring, I really wanted to find someone who had that DNA that can potentially transition to being a technical recruiter. And that DNA would be, you know, it doesn't have to be personality but just really interacting with engineers, just maybe being a self-starter.

+ +

I would say great communication, and lastly, I would say just really hungry. Yes, I would say hungry. Because if you're really hungry and you're really willing to learn and be open, so openness as well, then you can really understand the rules or just the lifecycle and the process of being a recruiter, and then you can change people's lives.

+ +

I actually had one...It was about a year ago, I was working with a Fortune 500 company, and I recruited this guy, and I led him through the process. And it was about maybe a month later when he told me I had basically changed his life. Him and his family were now moving to Atlanta, and it was a new role, and it was just a fresh start. And he was just telling me how appreciative he was of me, and so that really hit home. So I think for those two new hires, I'm so excited to have them get super engaged and be able to change other people's lives as well under the Techie Staffing name, of course.

+ +

CHAD: You mentioned early on that you're contingent recruiting. So correct me if I'm wrong, but that means that you get paid when you place somebody, when someone gets hired from the company that hires them.

+ +

ANNA: Yes.

+ +

CHAD: But then you also mentioned that these people who you're bringing onto your team are full-time. So how does the compensation structure typically work for them?

+ +

ANNA: Oh, compensation, we have them on salary, but they do have commission. So we wanted to really give; like I said, I want us to grow together. So I do provide commission for each placement they'll place just to really provide incentive. Like I said, it's so early. I want us to think of each other just as teammates and a team because we're all building towards the same goal.

+ +

So just really wanted to provide incentives where they're really feeling like they're almost owning it full life cycle as well. Because like I said, it's early on, and these can be really strong pillars in the future. So there is salary, but there's also that commission as well to just really provide that incentive. And I know for me personally, incentive can be awesome, so definitely trying to provide that motivation and having them really feel like they're an integral part.

+ +

CHAD: What's the harder part of your business? Or are they equally hard, finding new clients versus finding people who want to work with you on the candidate side?

+ +

ANNA: On the business development side, I would say it was harder perhaps in the beginning because I just so was starting with nothing, really. I had just graduated from college. And a lot of agency owners they previously have maybe worked at a really cool tech startup, or maybe they've been working on their agencies for the past 5 or 10 years. They have previous years of experience, but I didn't have that.

+ +

So I had to convey another method of just really networking, really meeting people, and just really knowing my stuff and having a handle on it. I know maybe a lot of people say, like, just fake it until you make it because then once you make it, and then you get that experience, then you can transfer that experience to new experiences as well. So at first, it was really just building myself up and building the Techie Staffing brand so that we could acquire those clients.

+ +

In terms of the candidate side, I would say Techie Staffing, and one of the things and part of our brand that we love to portray is that we are the agency that has the companies with the best employer branding. Because like I said, with the supply and demand issue for the software engineers, it is so competitive to attract them to new opportunities. There are just so many companies that are contacting them multiple times a day. So there has to be at least a little bit of a shine or a little bit of a differentiator for companies that you're recruiting for.

+ +

So we actually specialize in companies that are Series B and above that do have that established employer branding where engineers are really interested in joining that company, so that's just the thing. It's like really having companies that have strong employer branding and being able to follow up. Follow-ups are really, really important when it comes to engaging engineers because, like I said, it's just a super competitive market and just trying to provide them a great white-glove experience. There are some agencies that fall a little bit too close to the client-side where the client is always right.

+ +

And there are some that fall too much to the candidate side where the candidate is right, but we really want to be a balanced middleman where we're just trying to find the compromise and find the best solution for everybody. So that's the real important part of it of just really providing them with a great experience and showing them that we care and that we're rooting for them.

+ +

Because it sometimes does surprise me when candidates can be a little...maybe this is a part of me being new. But that's kind of an advantage, too, because I'm still paying attention to detail. That's where my computer science major comes in. It's like constantly trying to stay in tune with candidates and what they need, so just trying to provide a great experience in general. And I'm sure you feel that way with your clients. You're a consultancy as well where you're trying to be B2B and contact these different companies. So how do you conduct business development and really differentiate yourself?

+ +

CHAD: We focused a lot on reputation building, so blogging, creating open source so that we don't need, fortunately, to cold contact people. And when we do, we're fortunate enough that they might already know about us. And so it's an easier conversation to have because they may already be reading our blog, or they may already be using some of our open source in their product. And so it becomes an easier conversation to have. But the majority of our clients actually come to us when they have a need because we're fortunate enough to have worked to be at the top of the list.

+ +

ANNA: Definitely, yeah. And I'm still doing that, just reputation building. With one of our Fortune 500, we're doing incredibly well with them to the point where we're filling their pipelines, and we have majority of our candidates in their pipeline. So that's what we're really working on right now is just consistently...and I know like with any business, you have to just constantly build that reputation. So I especially just try to provide a great experience for candidates because they can also be hiring managers as well, so just really providing that white-glove experience.

+ +

And also, a cool differentiator we always like to showcase is like, I'm a computer science major. And actually, the two people that I just hired have a tech background. So it's not like tech is entirely foreign to us. We've engaged with programming languages. We've coded projects. So we do have some form of understanding when it comes to certain technologies or certain projects that certain engineers are working on.

+ +

And that's what really gets me excited to speak with engineers because it's so cool and interesting hearing about them working on their projects and working on projects that directly affect me and the products that I'm interacting with. So it's so cool to hear about their...I can understand a bit. And so that's another thing we have with Techie Staffing is really finding people who have a bit of a tech background so at least they have a little bit of knowledge or an understanding of what projects and can be able to really share and convey that to clients that are looking for this talent.

+ +

CHAD: You mentioned it's a really competitive market now. And as a company who probably has multiple clients, how do you minimize or how do you deal with the potential competition for the limited supply among your own clients?

+ +

ANNA: Among my own clients, I will say that right now we don't have...for the roles that we're working on for each client, they're not very similar or too, too similar, which is a good thing. We would like it in the future where we could have the same role, but we can understand how that can be a little tricky as well.

+ +

CHAD: And how do they differ then? Are they differing by the technology experience that they're looking for or the sort of level of the role? How are they different?

+ +

ANNA: It could be technology, difference of the role. So, for example, for a Fortune 500 company that we're working with, we'll work more with UX, data science, data science roles, as well as...so UX, data science. And then for high-growth startups, mostly with them, they're really looking for back-end engineers, but overall just engineering so frontend, backend, DevOps. We are working potentially to do engineering or more engineering-heavy for our Fortune 500 companies. We have recently been working on a VP of engineering.

+ +

So for Fortune 500 for now, we've been working more with leadership roles especially, and for high-growth, it's been more engineering IC. But we would like to transition that in the future to have it kind of...or have roles that maybe some candidates could go to this company, and some candidates can go to that startup. And then another differentiator could be or what makes our clientele different from each other is for high-growth startups, especially for engineering ICs, they're really looking for candidates that come from high-growth startups who just understand the current company where they are, and how they're scaling during that period of time around that series B and series C. That's the time to really scale.

+ +

And Fortune 500 companies they can be open to startups, but for the most part, especially sometimes for leaders who need to have a certain amount of direct reports, they're more looking for people from larger companies. So that would be one way to kind of separate it and so we're not having candidates almost be where they have to compete with candidates within our own company. Because with the difference in the leveling of companies, there's just a difference in what kind of candidates that they're looking for.

+ +

Mid-Roll Ad:

+ +

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

+ +

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

+ +

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

+ +

Save time and money with our DevOps and Maintenance service. Find out more at: url tbot.io/devops

+ +

CHAD: When I was first starting thoughtbot, I really felt like I needed to take every client that we could get because we were just starting out. We needed to make money. We needed to build a reputation. And so, I felt like we needed to say yes to every client. Over the years, I learned that that was actually watering us down, and it made us less successful. And the more we were clear about who we were, and what we did, and what clients we were best for, the more successful we were. Have you gotten to the point where you needed to turn down clients?

+ +

ANNA: Because I do such targeted biz dev, we will contact companies that we personally want to work with. But I will say in the beginning, there were some companies that were a lot smaller that, just like you said, you just felt the need to want to rack up a client list. And you just are ready to go and wanting to work with someone. It really motivated me to really take a look and really go deep into the type of clients that we want. So, for example, really, really early-stage companies can have a really, really hard time hiring because, like I said, employer branding is so, so important.

+ +

And so usually what they'll have is maybe like mission, but they won't really have salary. Or they won't really have the employer branding of the company of candidates either knowing about the company or being able to search the company really quickly and seeing the platform that the company is building and seeing how strong it is. So it's really, really hard to recruit for those stages. I mean, it is possible, but it's just really hard.

+ +

And then at the same time for these early-stage companies, they really want to, which I totally understand, you know, when you're having your probably 8th, 9th, or 10th engineer and being on the founding team, you really want a strong engineer because that's your platform, that's your baby. You don't want anybody that, you know, it could potentially maybe cause problems, or they really want somebody there they can trust. And so it's hard, you know like I said --

+ +

CHAD: But they might not be able to afford that. [laughs]

+ +

ANNA: Yes, they might either not be able to afford it, or they also cannot interview fast enough in order to just get the offer in their hands. Because I understand they really want to have them speak to the entire team and have them have an in-depth process because it's very much an important role. But these candidates and startups are moving so fast right now where I will speak to a candidate one day, and he or she or they'll probably say, "Oh, you know, I'm passively looking. I'm not really actively looking." And maybe a week and a half to two weeks later, they're like, "Oh, I actually have two offers in hand."

+ +

So it goes really, really fast versus earlier stage; it can just go a little bit slower because they're just really taking the time to go more in-depth and see if this prospective candidate is the right fit, which is totally understandable. But it was just really hard for us as contingent trying to find that candidate, that perfect candidate for them as well as trying to keep candidates warm and keep them interested when some companies just have like mission.

+ +

So now, in the future, I've just really, like I said, Techie Staffing, we specialize from Series B and above. And I really just make sure during business development exploratory chats that I'm really going in-depth and making sure I understand the roles that they're prioritizing their time to hire. So if they have a long, long interview process and a really, really low salary in terms of the competitive market, then I may not be as interested in that startup as opposed to another startup whose interview process timeline could be about a week and a half to two weeks.

+ +

And it doesn't have to be absolutely amazingly competitive base salary but just a fairly competitive salary with a great timeline for time to hire. So that's been my way of just condensing or just being a little bit more pickier in terms of clients in the future. Were there any certain clients for you where you started working with them, and you were like, "Oh, maybe I shouldn't have," that's now caused you to be a little bit more pickier for clients in the future?

+ +

CHAD: Part of it was the kind of work. So we really wanted to be writing software. But just starting out, I also had a background in sort of IT support. And so, when I was reaching out, particularly to past clients, they might say, "You built our website. Now can you help us with purchasing a computer or setting up a computer network in our office?"

+ +

I felt compelled to say, "Yes," because I felt like we needed all the work we could get. But by doing that work that wasn't really what we wanted to be doing, we were not only less happy in our work, but it was taking time and attention away from the work that we really wanted to be doing.

+ +

The other was values and practices, which took a little bit longer to form a real understanding of what our values were and the practices that we believe in. But now there's a pretty clear list of the kinds of companies that...what we say at thoughtbot is that we want to work on things that deserve to exist in the world.

+ +

And so there's a whole bunch of industries that they might not even be actively doing harm in the world, but they are the ones that we wouldn't work in. But even if it's just not a positive contribution to the world, it's probably not going to be something that we're excited to work on.

+ +

ANNA: That's been an exciting trend, actually, to speak with engineers about. I've started seeing that trend where engineers are saying, "I don't want to create anything evil," or "I just want to do good." And that's been a really awesome selling point for some teams. It definitely is a cherry on top where engineers are really looking for social impact. And the cool part is they have so many opportunities that are coming towards them that they can really pick and choose which one. So to find people who are really looking for social good and just really mission-driven products is amazing to see.

+ +

And I'm really happy with the work...I'm actually working with a data science team for AI ethics. And that's been really interesting hearing some people talk about their projects and hearing about how data can really not only just strengthen bias but also can just really produce results that can harm certain groups of people, which is so interesting. And it can be something so, so small that I haven't even noticed at all, but that can lead to a big difference.

+ +

CHAD: Yeah, we've had several episodes about that.

+ +

ANNA: And it's amazing. And it really is just a huge difference with something so small. And as a woman of color, I'm always aware of what's going on in terms of just ethical practices or just fairness and seeing bias. But in terms of data, seeing something so so small can affect just a whole group of underrepresented people is just amazing to see. But it's also amazing that people or data scientists are now aware of it, and now they're changing it so that it no longer...at least they'll be able to alleviate that bias.

+ +

CHAD: I want to ask a little bit more about that, and then I want to talk about some market trends. But if you're comfortable, I'm curious; you already mentioned you were just out of college when you were getting started. So there was skepticism around your lack of track record in recruiting. And you've mentioned that you are a woman of color.

+ +

And so I think as engineers, as people in the market, we probably have this image in our head of what a typical recruiter looks like in terms of attitude, and values, and demographics. And you don't fit that mold in almost any way, basically. Is this actually a positive for you now, or is it actually still hard? Are there companies that are actively seeking out to work with you because they want that different approach? Or are you still facing that skepticism?

+ +

ANNA: I'm still facing that skepticism. I actually created Techie Staffing around the time of summer 2020, where Black Lives Matter, where George Floyd happened. And it was really interesting because I was entering the corporate workplace. I went to a really wealthy private school in Los Angeles. And I went to the University of Virginia. So I survived two PWIs which means predominantly White institutions. So I thought I had not seen it all, but I thought I had maybe experienced those experiences of bias and understood it a little bit more.

+ +

But when I went to the corporate workplace and the diversity inclusion campaigns were happening, it was just really confusing because it's hard specifically for engineering and product specifically because it's so new that there is a really, really hard time to find diverse talent. That's why I honestly believe that it's just really trying to educate underrepresented communities to understanding all of the different diverse types of roles and opportunities that you can encounter in the tech industry so, for example, like UX, UX design, UX research, data science, machine learning, all of that.

+ +

So I think I was more contacted or maybe was engaged in business development companies who were looking for me to do diversity which I think it kind of...and I am such a huge proponent for diversity. But it also kind of had my heart drop a little bit because I just felt like people were contacting me because of who I am instead of just thinking like if it was just any other agency, would I be contacted specifically for that? It was more just for exclusive searches, which can be very, very hard for products and engineering.

+ +

I think in diversity and inclusion, we really need to focus on different departments and the different problems that underrepresented communities encounter with different departments. So it was just really hard, but in terms of companies contacting me because I am a woman of color owning an agency, no, that didn't really...and it's never really helped. I do wear it as a badge of honor because, like I said, I started out with nothing. So to start out with nothing and have to fight through everything to sit at the table and create something is amazing.

+ +

My background didn't really help me. It was really just me, just constantly contacting people. And I was prepared for this because, in my entrepreneurship minor, they said, "You're going to encounter a lot of nos," and so I did. I encountered so many nos, but eventually, I was able to turn those nos into yeses. So now that I turned some of those nos into yeses...and I'm still encountering nos, but I still keep going and still building and building.

+ +

And now I do feel a sense of pride now two years later where it is like, wow, I really did have to fight through to make it, and that's where I hold just a huge sense of pride. But no, it was not my background that really...the only thing that my background was maybe appealing was thinking like, oh, okay, I think you can do diversity and inclusion, which I don't want to be profiled in that way.

+ +

I just want to be a founder who happens to be a Black woman instead of a Black woman founder. And so, I don't want to be contacted to feel like my race is a part of it. And that was interesting in the corporate workplace, especially when I was trying to navigate different, you know, how to speak, how to build rapport, or how to navigate corporate workplace conversations.

+ +

And that's very hard to do with diversity and inclusion because you're fighting with, like, that's racism and misogyny. That's something really deep-rooted, and that has been here for years and years. So it's a really heavy, heavy topic. And that's not some really, really heavy topic that you really want to bring or a lot of people don't really want to bring into the workplace. So that was just hard to encounter.

+ +

But overall, I so, so support diversity and inclusion. And the cool part is because I have this awareness and I know that diverse teams are better teams, whenever I'm sourcing, or one of my recruiters is sourcing, I'm just making sure that they have that in the front of their mind, and they're just trying to diversify their candidate pipeline as much as possible.

+ +

CHAD: Well, taking it from the candidate side of things, I, unfortunately, I'm of the belief that the hiring process is really ripe for extreme, subtle unconscious biases or conscious ones even to have an impact on the hiring process. So, how have you navigated that on the candidate side? I'm sure you don't want to say anything negative about any of your clients. It's not about, oh, this company is racist. But I think do you agree with the premise that the hiring process at a lot of companies is ripe for some bias to creep in?

+ +

ANNA: Of course. I mean, all of the time. And the part that's so, I would say, scary about it is that bias is something that you feel. It's not really tangible. You can't really grab it. I mean, it can be in writing, and [laughs] there has been stuff in writing. But it's very much kind of yeah; it's non-tangible. So it's hard to really call it out specifically of like, hmm, this candidate I don't know why all of a sudden nice to haves become must-haves. Why is there a shift?

+ +

Like I said, there are different problems with different departments, but there are also different problems in terms of leveling systems, so leadership roles versus individual contributor roles. There can be a little bit more, you know, maybe there's a little bit more openness on the IC side, but with leadership, it can get a little interesting sometimes. But the hard part is it's not really tangible. So I really have to give it to diversity like DEI specialists because to have to navigate those conversations and really articulate a non-tangible thing is so, so complicated.

+ +

So there are tangible things you can do, like having a diverse panel. But what happens if the company doesn't even have the numbers for diversity to have that diverse panel in the first place? So it can get really complicated in terms of trying to navigate the bias within the interview process, and we do try to do our best there, just trying to provide on our side because that's all we can do. It's really up to the companies in terms of their interview processes and how they are going to change it or maintain some stages.

+ +

But for us, we're just trying to just submit diverse talent and really just try to provide that white-glove service for them and hope that that bias doesn't seep in. But like I said, it's such a heavy topic. And like I said, with corporate workplace politics, it can be so fragile and really interesting. So it's just hard to really take that and understand where it comes from or being able to even verbalize it. So that's where it gets really interesting.

+ +

And so, I do hope that in the future, interview processes are changed where there is able to be a diverse panel, or there is a way to really be able to understand that bias. Because like I said, it's very complicated. And we don't want to claim that any company is specifically racist, but it's just understanding bias and maybe why there's a difference for one candidate versus another candidate, which can be really interesting.

+ +

CHAD: I think the first part is recognizing that everybody has biases, and it could be anything. It could be, well, what happens when you come across a resume of someone that went to the same school that you did? What happens to that resume, then? And does that subtly influence how you review that resume? It has nothing to do with their race or the color of their skin or anything. So those biases can creep in, and you need to decide as a company is this something that actually matters to success at the company? Is this something that we want to be using when we make hiring decisions about who gets that first interview or who continues on in the interview process?

+ +

For us, we've decided it's not, so we have a completely anonymous screening process where we don't even show the names of schools. We don't show the names of the companies that you worked at previously. We only show the positions that you held at those companies because we've decided that whether you have a degree or not doesn't matter, and the companies that you worked at previously don't matter. It's what you were actually able to do with that experience.

+ +

ANNA: Oh yeah. I think that's actually amazing. That's a really great way of doing it. I always just try to tell hiring managers also to just open that candidate pipeline as much as possible because the number one way to really understand someone isn't really through just a piece of paper.

+ +

Yes, we want to make sure that the resume is at least a bit aligned. And they have, if it's an engineering role, for example, the right tech stack or maybe the right technologies or the right kind of projects that they've worked on. But other than that, you'll be so amazed what can happen when people just hop on a call with each other. You can really find just that hidden genius in people.

+ +

So usually, when it comes to just diversity, it's like just hopping on a quick call with someone, anybody. Like you said, there are so many biases, but just being able to talk to them and see them as a human being can really just surprise you and surprise everybody. So really just, I always say just find that hidden genius through engaging with someone.

+ +

CHAD: Yeah. So you've mentioned time to hire is a really important thing moving quickly in today's market when candidates have a lot of opportunity. What are some other ways, either trends or things that are happening in the market or things that you see changing?

+ +

ANNA: Well, honey, I'm sure, as you know, there's been a huge amount of layoffs that have happened. Like, recently, about 17,000 workers were laid off from more than 70 tech startups globally in May, and that's been about a 350% jump from April. So I will say it's just due to inflation as well as just the slowing of demand. Startups right now are just really trying to just cut corners and just really trying to just hone in on their runway and their burn rate.

+ +

CHAD: Are the candidates that are being laid off finding new work quickly?

+ +

ANNA: I'm not sure because it depends on the departments. We're working with engineering mostly in product. So it's really funny because as we are tracking the layoffs, we will contact candidates to see if they're interested in another opportunity. Because fortunately, for our client list, we haven't had anyone have a massive amount of layoffs which has been...we're so happy about that, fortunately. But we've actually contacted engineers. And it's amazing how strong the engineering department is. It does not seem like they really are...that's not a department where there's like significant layoffs because they just have to uphold that platform.

+ +

So yeah, so it still is in terms of engineering surprising with all these layoffs. It still is just very much competitive because even the people who have or the companies that have encountered a large amount of layoffs those engineers are still wanting to stay or don't...there are some that may feel the need to depart at a certain point. But for the most part, they are staying. But in terms of how quickly, I'm not entirely sure in terms of for people that are laid off how quickly they are being hired because this is also within early-stage startups or not early-stage; they also have Fortune 500s too. But yeah, I'm not sure about that part.

+ +

But in terms of engineering specifically, the jobs are still just growing. The projected growth rate for software engineers is like 22%, and data scientists is 22%, as well as web developers is 13%. So fortunately for us, as an agency who primarily specializes in engineering, there hasn't been a huge difference.

+ +

But like I said, specifically with engineering, that time to hire is still super important because these candidates are still encountering offers quickly. And it's just a way to be competitive because if you're just the first offer, you're the first offer in their face instead of, let's say, they have two offers from another company and you're like at the last offer. It's such a big difference there.

+ +

CHAD: Are you seeing a lot of remote positions versus in-person positions?

+ +

ANNA: Yes, remote is still going strong. I have seen that now there is a little bit of a trend of some startups or companies where you know because I research companies every day...I'll go on Crunchbase, Morning Brew, VentureBeat, TechCrunch, Built-In. I'll go on all of the websites, and I'm seeing who got a fresh new round of funding or who's highly growing, or any new products that companies are offering.

+ +

CHAD: You're seeing some companies say that they're hiring hybrid or in person.

+ +

ANNA: I am seeing that on startups and companies' career pages, once they've acquired a new round of funding or they're scaling, that on the job boards, you'll start seeing only the headquarters, so just San Francisco or just maybe Boston instead of remote. So it's been a little bit more of a quiet transition because I remember when bigger companies were announcing it like, oh, we're going to transition in the office in February of 2022 or December of 2021, then there would all of a sudden be a mass exodus of people who were seeking remote opportunities.

+ +

But I do still feel that remote is still going strong, especially for high-growth startups, you know, yeah, still going strong. There is the option of hybrid. With these engineers that do have these choices, 100% remote is really becoming a great selling point. I mean, I don't even know if it's really a selling point but just standard now.

+ +

CHAD: So that's what you're hearing from candidates. Candidates want that.

+ +

ANNA: Definitely, candidates want. There's been plenty of candidates that we've interviewed where they've said in terms of their...because we'll ask them what would be their motivation for considering other opportunities and potentially leaving, and then they'll say, "X company is anticipating us to transition into the office, and I just don't want to do that." Their commute may be an hour, and that can be two even maybe three hours out of your day where you're spending your morning driving and then spending your evening driving.

+ +

So people just prefer to be remote. Or people are located now in the Midwest. They're going back to their hometowns where they're able to instead of like these big metropolitan cities where now it's really hard to afford a house, so they're going back home and being able to enjoy their family there. So definitely it is a standard and people are really interested in it. And for companies that are having employees transition back into the office, we've consistently heard that there's just a mass exodus of people leaving.

+ +

CHAD: What have you seen compensation do over the last year-plus?

+ +

ANNA: I would say for compensation, I mean, in my personal opinion, when it was super competitive, it was definitely increasing. Now I feel like we're working with a Fortune 500 company, so compensation hasn't really been too, too much of a problem. So yeah, it hasn't been as competitive. But I do remember when it was maybe around Q1 and Q2 2021 where there was almost this great rehire. And everybody was scaling, and demand was soaring where the salaries were just like, it just increased or were just consistently increasing. We were just so shocked at what some software engineers were making.

+ +

But now, it seems to have potentially tamed a little bit. It's not as high as it probably used to be because we were working with that series B Company and their salaries were pretty good, pretty competitive. But all of a sudden, with the demand soaring and these engineers, it started getting even more competitive. Then that's when all of a sudden, you know, the first few placements were fine. And then, all of a sudden, each candidate, like I said, they would say they were passively looking and then the next week...

+ +

And this startup their time to hire was actually really great. But even with this competitive market, it was still hard because, like I said, a week later, they would already have an offer. And their salary would probably increase like 20,000-30,000 from their initial target base that they were seeking to now what they were being hired from other companies. So it would definitely increase. But I haven't seen that recently as much.

+ +

CHAD: Yeah. I think also the trend to remote changed compensation, too, because it leveled it out. There were people who if you were trying to find a job in Kansas and you were going in an office, that market is very different than the U.S.-wide hiring market. But now, candidates are on the U.S.-wide hiring market. And I think that that brought up the lower end of salaries.

+ +

ANNA: Oh yes. Because at first, it was like okay, we can look for...it was 100% remote, which was great, and so they were like, we can look for people in the Midwest. But during that time, companies were paying San Francisco and New York salaries, and they were offering those salaries to people who were located in Kansas and Iowa.

+ +

So you would have engineers who were deep, deep in the Midwest who were asking for in terms of target for those metropolitan city salary budgets. And they would get it, which I think is great as well, just they are doing the same work as someone who is located in San Francisco or in New York but maybe with less overhead, of course. But it definitely was a little bit more of a challenge. And you can no longer assume that somebody located in the Midwest that may have lower salary bands aren't at those metropolitan city salary budgets now.

+ +

CHAD: Anna, thanks much for stopping by and sharing with us. I really I'm impressed by what you've accomplished so far. And I'm excited about what you're going to be able to do in the future.

+ +

ANNA: Thank you. Thank you so much, again, for inviting me. I had a great time speaking with you, and it was so interesting hearing about your time being a consultancy. Because I know being an external vendor, it's really interesting interacting with clients when you're not internal. So that was really interesting hearing about the difference of clients that you're encountering at first versus now.

+ +

CHAD: Yeah. If folks want to get in touch with Techie Staffing or get in touch with you, where are the best places for them to do that?

+ +

ANNA: So in terms of contacting me, I'll say the best way would be either our website so www.techiestaffing.com. Or you can contact me on LinkedIn; my name is Anna Spearman, A-N-N-A S-P-E-A-R-M-A-N. I'm always active on LinkedIn. So if you're seeking a new opportunity either on the candidate side or either meeting, help and engaging Techie Staffing as a scaling company to fill your engineering, design, UX, and product roles, you can contact me on LinkedIn as well as filling out the forms on the Techie Staffing website. And we also are on Twitter @StaffingTechie. So definitely contact us, and we'd be happy to hear from you.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes and a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Anna Spearman.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YBvmdMrC + + ]]> + + Chad Pytel + Anna Spearman + + + 432: MustWatch with Chelinde Edouard + https://podcast.thoughtbot.com/432 + 40f4e0c2-89a4-4b7c-b4f6-e7b0d3f74f21 + Thu, 21 Jul 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Chelinde Edouard is Co-Founder and CEO of MustWatch, which connects people through television. + +Chad talks with Che about creating a social and user engagement platform that allows people to come back and constantly use an app without interrupting TV-watching experiences, how they use data to improve user experience, and fundraising and giving investors opportunities to help build out the app, increase marketing, and potentially build an Android version. + 28:20 + no + + + Chelinde Edouard is Co-Founder and CEO of MustWatch, which connects people through television. +Chad talks with Che about creating a social and user engagement platform that allows people to come back and constantly use an app without interrupting TV-watching experiences, how they use data to improve user experience, and fundraising and giving investors opportunities to help build out the app, increase marketing, and potentially build an Android version. +MustWatch (https://mustwatch.com/) +Follow MustWatch on Twitter (https://twitter.com/realmustwatch) or LinkedIn (https://www.linkedin.com/company/realmustwatch/). +Follow Che on LinkedIn (https://www.linkedin.com/in/che-edouard-10013964/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Che Edouard, Co-Founder and CEO of MustWatch, which connects people through television. Che, thank you for joining me. +CHELINDE: Thank you for having me. I appreciate it. +CHAD: So astute listeners of the show will note maybe that name sounds familiar. And that's because you and MustWatch were mentioned on Episode 419, which was about the GK Fund with Michael Benezra. And I asked him for examples of the kinds of companies that he was excited about that they had given their grants to. And you're the one he called out, and so that jumped out at me. And thanks for joining the show. +CHELINDE: Thank you for having me. Really appreciate it. And I definitely want to shout out the GK Fund. They've definitely been a huge support to us since giving us the grant. And they're definitely leading the charge in this new avenue of racial inequality and helping startups in that fashion in Boston. +CHAD: So I'm curious; before we get too far down the road of where you're at today and how you got there, let's take a step back and just remind people what MustWatch is. +CHELINDE: Absolutely. MustWatch is an app that's on the App Store now. So even if you have an iPhone, you can download it. And it's an app that's revolving around TV. So it allows you to see what shows your friends watch, chat with them about them, and send recommendations all in one place. So we think of it as like a social hub for all of your TV needs. +CHAD: I think people who hear this might be like, oh, does this exist already? That kind of thing. And there are a couple of things a little bit like this, but it doesn't seem like there's really anything that's quite like this, right? +CHELINDE: Exactly. So a lot of the social TV apps and other services today focus on one feature, for example, chat or recommendations, or giving reviews about shows, or having a list of them. But our app, we do all of it in one place. So on our app, it can show which shows you like. You can also share with your friends directly; hey, you should go watch this show because I think you should like it. +We also have this feature called watchlist, which is our natural social recommendations of here are all the shows that your friends are watching that you don't watch. And so it's a way to give people a way to find new shows without getting the same recommendations from Netflix and Hulu that are not really accurate today. +CHAD: How did you hit upon this idea? +CHELINDE: Actually, one of my high school friends, we were all brainstorming and coming up with ideas for companies. And then one day, he was at work, and he was trying to talk about Game of Thrones, but his boss wouldn't let him because he wasn't caught up on the season. He wasn't there. +CHAD: [laughs] +CHELINDE: So he was like, how do I find someone or talk to someone who's caught up to where I'm at so I can actually have a conversation? And so we brainstormed, and we tried to solve the problem of let's just create a spoiler-free chat kind of solution that would allow people to talk about shows that they're caught up on. And then that we've iterated and evolved, and that's kind of led to where we're at today. +CHAD: And when was that? +CHELINDE: That was, I want to say, 2014. That was when I graduated from BU. So in the summer of 2014, that's when we first had the idea. And then from there, we just brainstormed, had a bunch of meetings, and then just took a year in stealth mode trying to figure out how we wanted to create a business plan. And then, from there, we hit the ground running. +CHAD: You and your friend, what were your sort of core competencies, the two of you? +CHELINDE: I'm the tech background, so to speak, because, as I mentioned, I went to BU. My degree is in management information systems, which is basically business IT. So I was trying to leverage all my technology skills there and also my business skills to say how do we, one, build the app and two, create a business that can actually support it for the long term? +And he had more of the idea on the customer side of how can we create an experience or a user engagement platform that allows people to constantly come back and constantly want to find more reason to use our app? Because as we know, people watch the show on TV, but the app is a conduit to that. And so, we want to figure out a way to get people to constantly use our app but also not interrupt their TV-watching experience. +CHAD: So you said you're trying to figure out a business plan. You're refining the concept. At what point do you start making the leap to actually writing an app? +CHELINDE: With all apps, you start with this concept called wireframes, and so we built out a bunch of wireframes. Two of my friends from high school we all built the app together. And then one of them went to Miami, and his friend from Miami he's the one that actually helped us develop the app and code. And so we worked with him to actually say, "Hey, these are our wireframes. We're trying to make this into an app. Can you build it out?" And so, we worked with him over a year to make that a reality. +CHAD: And it took about a year to get to launch. +CHELINDE: We actually started on Android, and we were trying to create an MVP or prototype. And so we took that idea like I said, we were working for a year, to this company called Netcapital, which is a crowdfunding platform for startups and companies. And we launched on Netcapital in May of 2020. With that idea, we raised 50k in almost three months. And with that money, we actually built the app from there. And so the app you see in the App Store now is from the money that we've raised on Netcapital. +CHAD: Did you throw away that original version and start over? +CHELINDE: I wouldn't say throw away. We kind of used it as a launching point. But we don't have any Android version right now. We're strictly in iOS. +CHAD: Yeah, that was notable to me. Tell me more about that. +CHELINDE: So going from Android to iOS it was really a business decision there because our developer had knowledge in Android but didn't have the iOS background. And so when we went on Netcapital, we used that money to actually hire a real development team. That's who's building our app now. So we work with them to build our app. And going to iOS has allowed us to, at least in the meantime, expand in the U.S. market a lot quicker. +CHAD: Now, are they building it in first-party frameworks only for iOS, or are they using something that is going to allow you to go expand to Android in the future? +CHELINDE: So right now, we're strictly iOS only. We would like to move to a React Native or a tool that allows us to promote to both. When we first started, we wanted to just focus on iOS, given our costs. +CHAD: These are common problems that a lot of startups or common decisions that a lot of startups have to make. And it's not always straightforward. Were you worried about this? +CHELINDE: Yes. Because that's one of the things now it's we would love to have an Android version. But for me, being more of a purist, I didn't want the code to work in one system and not another. And given that we only had...in my mind, it's like you have one shot to make an impression. And when you go out and launch it on the App Store, I didn't want it to be half-baked in one and half-baked in the other. I'd rather have one be exactly how we want it to look, and then we can adapt as we grow. +CHAD: How has it been working for you, then? +CHELINDE: So far, so good. We're actually in the process of releasing some new features later this month, and so like I said, the watchlist feature, which allows you to add shows that you're going to watch in the future. We also have the ability to create chats through the chat functionality because previously, you had to create a new chat every single time. So we've made it easier for people to start chats, and also you can do group chats as well. So it's not just individuals. You can have a whole group of people in one conversation. +CHAD: So some of these features there must be a backend server powering all of this, right? +CHELINDE: Yes. So we use the Google Cloud Firestore for our backend. And another cool part about our app is we have a lot of analytics about what people are watching. And that's where we take their data from our cloud, the Google Cloud Firestore, and we send it to the BigQuery, also a Google platform. And then we use the Google Analytics that we have on the app to then do our reports around who's watching what, top 10 shows for the past month, the top 10 shows based on if you're male or female, based on what age group. So we have all the analytics on the viewing habits from the data that we've collected. +CHAD: Can you tell me how many users you have now? +CHELINDE: As of right now, we are at 820. We are looking to obviously get a little bit over to that 1,000 users mark, and then we can have a better sense of what kind of insights we can glean from there. +CHAD: Well, hopefully, coming on this show will help you do that. So if you're listening and this sounds interesting to you, where are the best places...so people can search for MustWatch on the App Store, the iOS App Store? +CHELINDE: Yep. And we also have a website mustwatch.com if people want to check that out as well. +CHAD: Yeah, so let's do it. Let's push them over the top and get those numbers up. I'm curious about usage patterns. Are you able to see any patterns in terms of what causes people to either keep using the app or not? +CHELINDE: Yeah. So the main thing that keeps people using the app is having chat groups with people and then also getting recommendations. Like I mentioned before, we have the social recommendations of people just showing you what shows people watch. But there's also direct one-to-one. If you're on the app, I could send you a recommendation. And that's what drives a lot of people to go on the app and find new shows. +Another thing that we see is a lot of people just searching, just looking up the shows that are on the app because our database of shows is actually pretty robust. I was talking to someone yesterday; he's Korean. And he was using his phone to type in a show. And he was using a Korean keyboard, and the show came up. And he was like, "Oh wow, I didn't even know you guys support multiple languages." And I was like, "Yes, we support." Our database of shows is very expansive. So if you're in Korea, if you're in Japan, if you like anime, if you like telenovelas, we have all types of shows on our app as well. +CHAD: Do you get that database from somewhere? +CHELINDE: Yeah, so there's actually a TV show API called TMDB, which pretty much is an open-source, free database that you can pull from. So we use that as our source for shows. +CHAD: That's cool. Speaking of shows, I noticed on the MustWatch website, on the team page, you all list your favorite shows and what you're currently watching. I think you and I have different tastes in shows. [laughter] I have heard of the shows that are your favorite, but I have not watched any of them. +CHELINDE: Oh wow. [laughs] What are your favorite shows? +CHAD: I think actually my shows match the shows listed by Rob, your CFO. +CHELINDE: Oh wow. [laughs] +CHAD: And my all-time favorite show is, I think, The Leftovers. +CHELINDE: Okay. So yeah, and that's the cool thing about this app is like, if you're on the app, you would see Rob's shows on the app too. Because if you download the app, you become friends with all of us immediately, so you have friends on there to start. +CHAD: Oh, that's a cool idea. +CHELINDE: So it gives you a way to just see what the app can look like before...because if you're on there by yourself as one person, it's a social app. It's meant to be with people. It doesn't really give you that clarity. So I bring that up because that's the one cool thing about the app is you always are surprised by what shows people watch, even if they're your friend. It's like, oh, I didn't know you would like that show. Or oh, I liked that show, and you don't like that show. +And it's a very cool icebreaker or just a social connection that you can make because everyone's putting shows on the app. And one way, actually...I was talking to someone the other day thinking about how like Spotify, you put all your playlists and all your shows. This app is kind of like a Spotify but for TV shows and also for movies. So it's not just shows, movies as well. +CHAD: And the cool things that Spotify does in terms of the reports that they release annually to each individual person and everything. Like, that's all stuff you can do too. +CHELINDE: Yep. +CHAD: Yeah, it's cool. So your background actually is in sort of business intelligence, data analysis, and analyst, right? +CHELINDE: Yes, that's correct. For my day job...I just want to back up. I also have a day job while also doing this. And I've primarily been the past couple of years a BI analyst. So previously, I was at HarbourVest, which is a private equity firm here in Boston. And then, I recently joined Liberty Mutual Investments also as BI data analyst. So I've been very involved in the financial services side of data analytics, which has allowed me to just get other insights on how technology works and just also getting exposure to the whole industry as well. +CHAD: So you basically have two reasons why you want to get the number of users up. One is from a co-founder perspective and founder perspective; you want to get the number of users up. But from a data perspective, you want to get the users up so that you have more data to play with. +CHELINDE: Exactly, exactly. The more users we have, the more data we can collect. And then data we can glean insights, and then provide value to our customers as well. Because our app users, if we can know which shows they are liking, we can also then tell them about shows that they also might like. Because once you find commonalities in shows that people are liking, you can then give them better recommendations. +And we think that the social aspect of our app, the fact that we have all of your friends on there and they're giving you recommendations, it's better than just, oh, you've watched this show in the past three years, and it's on Netflix's algorithm of watched shows. That, to us, doesn't really seem as insightful and helpful to people. +Mid-Roll Ad: +When starting a new project, we understand that you want to make the right choices in technology, features, and investment, but that you don’t have all year to do extended research. +In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. +Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: url tbot.io/sprint +CHAD: So you mentioned you have another job in addition to all this work you've been doing on MustWatch. How has that been? You know, starting a company, working on it while also having a full-time job elsewhere? +CHELINDE: Yeah, it's definitely been, I guess, one of the challenging things I would say. It's definitely been rewarding. It takes a lot of time management, I would say, because you have to balance your day job and manage something on the side. I think the biggest hurdle I had was when we were first launching the app on the App Store, meeting with developers, and trying to fundraise all at the same time because I was just pressed for time. +Because of the COVID, COVID happened right when we were launching. So working from home all day everyday kind of helped because I didn't have an hour commute anymore. So I got two hours back in my day. So I could, instead of going to work and just commuting, I had an hour in the morning and an hour after. I could use that time for MustWatch. But I had to definitely sacrifice some of my social life to make that happen. +[laughter] +CHAD: I assume that you have the plans that you would hope that things with MustWatch get to the point where you could do it full time. +CHELINDE: Yes. The goal is to get MustWatch to a point where we can pay our employees and have salaries, and everyone can just be working from the company. But as everyone knows, if you're in a startup, you got to just not pay yourself and make sure everything goes into the company. How I see it is you can't pay yourself until everything else is working. +CHAD: Yeah, I mean, people hear the startup stories of raising a whole bunch of money, working exclusively on it, having more than enough. I think that that's actually not necessarily the norm; that's the outlier. I think it's more common, more widespread to do what you're doing, to have an idea, and to be working on it and growing it while also holding down another job. +CHELINDE: Because as we all know, the bills need to be paid, [laughs] and those don't go away. But I didn't want to give up on the dream. So if you want to make it happen, you can make it happen because while I was at HarbourVest, I also was at Babson getting my master's degree in business analytics. So at one point in time, I was working full-time at grad school and doing MustWatch. To me, that was probably the most busiest period of my life, but I did get through it. [laughs] But definitely took a lot, but now we're here. And we've gotten support from the GK Fund, and I couldn't be happier with where the future lies ahead. +CHAD: One of the things about the GK Fund is that it's a grant. It's not an investment where you're giving up part of your company in order to do it, which I think is really important, especially for very early-stage companies, not to have to give away a significant portion of their company just to get some angel investment or that startup fund. I assume that's one of the reasons why it's been a big impact for you. +CHELINDE: Absolutely. I mean, one, having it not be an investment was a lifesaver for us. At the time, we were still trying to figure out how to just get cash to get to the next stage. And so, for us, a grant was literally the blessing or a miracle at the perfect timing because it allowed us to...it gave us a little kickstart. +Because I mean, as everyone knows, if you're a startup, you're always low on cash. And you're always trying to decide what's the best way to move the company forward? And that just gave us that breathing room without having to worry about paying it back, or a timetable to now let us actually grow and do what we can do best. +CHAD: Do you hope to take a more traditional investment in the future? +CHELINDE: Yes. So we're actually planning to do another fundraising on Netcapital. This time we're planning to raise $450,000. And that's going to help us build out the app, increase our marketing, and then potentially also build an Android version. +CHAD: So I'm not sure that everyone who's listening will know what Netcapital actually is. +CHELINDE: Yep. So Netcapital is a crowdfunding equity platform which allows retail investors to directly invest in startups. So if you're looking for another way to get into early-stage companies, Netcapital is a great place to do that. It's similar to if you've heard of StartEngine. It's a similar concept to that. And it's mainly you pretty much buy shares in a company, and then that company will then take that money to then use it for the funds that they have set in their offering. And you actually get an equity stake in the company. +And so, for us, it's great because typically, those types of fundraising opportunities don't come for us. You need to have VC-backed or some kind of angel investor to get to that level. But having it be open to everybody, there's a larger pool of retail investors that allow you to get to where you need to go. Because if you can get a couple of your family, friends around to give you like a hundred or a couple thousand, it's definitely a better avenue than just going the VC route or just getting a loan from a grant or a startup, an SBA loan, something like that. +CHAD: Traditionally, something like Netcapital was not really possible. But my understanding is that in 2016, the laws changed to allow smaller investments and get actual equity and for companies to offer it in such a way that wasn't possible before. +CHELINDE: Yes, I believe it's called a Reg CF, Regulation Crowdfunding, and that was the law that was passed in 2016. And that is crucial to us being able to have an offering on Netcapital. +CHAD: So it's not like Kickstarter where, you know, in Kickstarter, you're offering a new product or something, and people aren't becoming investors in your actual company. Netcapital is they are actual investors. And so, as an entrepreneur, as a company, what do your obligations to those investors look like? +CHELINDE: So because they're investors, we have to give them quarterly updates. We have to file our annual report. We have to disclose any conflict of interest. There's a whole SEC team that has to approve and review any offering that goes on the platform to make sure that we are following all SEC guidelines. And then also, we are liable because they're investors. So they can email us. They can reach out to us, and we will respond because they are our shareholders. [chuckles] And so we need to make sure they're happy as well. +CHAD: Yeah, with one of the things that Netcapital does is it sort of works like Kickstarter in that if you don't meet the goals that you've set, it doesn't actually happen. +CHELINDE: Yep, there's a minimum investment threshold, so it depends on how much money you're raising. So last time, when we raised 50k, the minimum was 10k. So if we didn't get over $10,000, all the investors would get their money back. But if we got over that threshold, then that's the money that we would be able to use for our company. +CHAD: 450,000 is significantly more than 50,000. What do you feel like you need to do in order to make sure that you hit the goal? +CHELINDE: So one thing is going on podcasts like this to make sure that people know about it. [laughter] Secondly, we're actually going to be partnering with the GK Fund to do some more media exposure there. And then we're also partnering with Silicon Valley Bank because they're actually our partners on the banking side. And so, I'm going to be partnering with their network to leverage their connections as well. And then we're also going to be just doing the classic social media, posting on Facebook, Instagram, LinkedIn, friends, or family. All avenues of media we will be pushing out MustWatch. +CHAD: When do you expect to open up that listing? +CHELINDE: We're targeting mid-July right now. So that's when we're planning on going live on Netcapital pending the compliance review and all the other legal stuff, but that's when we plan to go live. +CHAD: Okay, well, if you're listening to this episode, it's going to be going live in a couple of weeks. And so definitely follow along and check it out. Cool. Well, what are your goals for that next funding round? What do you expect to use it for? +CHELINDE: We expect to use our funding round on improving the iOS experience, so adding more features because we've gotten some customer feedback. And we have a laundry list or a backlog of items we want to add but obviously limited by cash constraints. So once we have the money, we can do what we want to do. +And then we also would like to improve our marketing. So we want to have a real marketing team and improve our SEO. And then we also have a connection with Hollywood. So the writer for Ford and Ferrari, his name is Jason Keller is on our team. And we want to see how we can get our foot in the door with Hollywood as well. +CHAD: That's really cool. What would that look like in your ideal scenario? +CHELINDE: Ideally, we'd have some celebrities or Hollywood A-listers on the app using MustWatch and then promoting their shows or promoting our app in one of their media engagements as well. +CHAD: Or chatting with people about the episode that just came out and that kind of thing. That'd be really cool. +CHELINDE: Yeah, exactly. We want to get people to just engage on the app with celebrities as well. That's definitely one of the avenues we were thinking as well. +CHAD: One of the big trends right now is TV companies making companion podcasts to the shows that they make. I can totally see them doing this kind of thing as well. +CHELINDE: As we all know, user engagement and fan engagement is crucial for these companies, and MustWatch would be a crucial way for a lot of companies to connect easily. +CHAD: This is a little bit of an aside, but I was sort of surprised that you were able to get mustwatch.com. +CHELINDE: It was not cheap. [laughter] I think for some people who were following us for a while, when we first launched, our name was WatchParty. And that's how we originally started our company. But as we evolved, Facebook released a watch party feature; Hulu, Amazon all have these watch party features, and they weren't exactly like our company. And we didn't want to get any confusion in branding. And so we had a long discussion around what name do we change to, and how do we still convey the right feel for the app, and what we want to do? +Because on our app, you're not watching the show on our app, I want to make that very clear. It's all about finding a new show, chatting, and connecting with people, but you're not watching on the app. And so it's tough to...not tough, but we wanted to make sure that people knew that the app was for finding new shows. But also, it has to be like a must-watch. Like, I need to go watch this right now because it's something really good. And so that's how we came across this name. +CHAD: You mentioned earlier on that expenses are tight when you're working on something new. How worried were you about spending money on a domain name? +CHELINDE: So this is also where our partnership with Netcapital came into play because they helped us in terms of getting us off the ground. And we work with them on the business side as well. And this is one of the avenues where they helped support us. +CHAD: Oh, wow. Wow. It's great that you're able to pull together these different resources and get that support. +CHELINDE: Yeah, to us, it's been crucial because, without the support, it's very tough to get your name out there. It's very tough to promote the idea. And so, with Netcapital and the GK Fund, it definitely puts us in a better light than usual. +CHAD: Well, Che, I really wish you the best and MustWatch the best and your whole team. And good luck over the next few weeks as you open up this round on Netcapital. I ask everybody, again, go check out the app. Sometimes we talk to companies of all different stages on the show. And I especially think it's important when we have someone that's just getting started really trying to hit these user numbers that if people could go check it out, that'd be great. +CHELINDE: Really appreciate it. +CHAD: If folks want to follow along with you, get in touch with you, that kind of thing, where are all the different places where they can do that? +CHELINDE: Reach out to me on LinkedIn. I'm on LinkedIn, Che Edouard. You can reach out to us on mustwatch.com. We have a contact us email there. You can also email me at che@mustwatch.com if you want to reach out. I am available on all platforms. +CHAD: Wonderful. And you can subscribe to the show and find notes and a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chelinde Edouard is Co-Founder and CEO of MustWatch, which connects people through television.

+ +

Chad talks with Che about creating a social and user engagement platform that allows people to come back and constantly use an app without interrupting TV-watching experiences, how they use data to improve user experience, and fundraising and giving investors opportunities to help build out the app, increase marketing, and potentially build an Android version.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Che Edouard, Co-Founder and CEO of MustWatch, which connects people through television. Che, thank you for joining me.

+ +

CHELINDE: Thank you for having me. I appreciate it.

+ +

CHAD: So astute listeners of the show will note maybe that name sounds familiar. And that's because you and MustWatch were mentioned on Episode 419, which was about the GK Fund with Michael Benezra. And I asked him for examples of the kinds of companies that he was excited about that they had given their grants to. And you're the one he called out, and so that jumped out at me. And thanks for joining the show.

+ +

CHELINDE: Thank you for having me. Really appreciate it. And I definitely want to shout out the GK Fund. They've definitely been a huge support to us since giving us the grant. And they're definitely leading the charge in this new avenue of racial inequality and helping startups in that fashion in Boston.

+ +

CHAD: So I'm curious; before we get too far down the road of where you're at today and how you got there, let's take a step back and just remind people what MustWatch is.

+ +

CHELINDE: Absolutely. MustWatch is an app that's on the App Store now. So even if you have an iPhone, you can download it. And it's an app that's revolving around TV. So it allows you to see what shows your friends watch, chat with them about them, and send recommendations all in one place. So we think of it as like a social hub for all of your TV needs.

+ +

CHAD: I think people who hear this might be like, oh, does this exist already? That kind of thing. And there are a couple of things a little bit like this, but it doesn't seem like there's really anything that's quite like this, right?

+ +

CHELINDE: Exactly. So a lot of the social TV apps and other services today focus on one feature, for example, chat or recommendations, or giving reviews about shows, or having a list of them. But our app, we do all of it in one place. So on our app, it can show which shows you like. You can also share with your friends directly; hey, you should go watch this show because I think you should like it.

+ +

We also have this feature called watchlist, which is our natural social recommendations of here are all the shows that your friends are watching that you don't watch. And so it's a way to give people a way to find new shows without getting the same recommendations from Netflix and Hulu that are not really accurate today.

+ +

CHAD: How did you hit upon this idea?

+ +

CHELINDE: Actually, one of my high school friends, we were all brainstorming and coming up with ideas for companies. And then one day, he was at work, and he was trying to talk about Game of Thrones, but his boss wouldn't let him because he wasn't caught up on the season. He wasn't there.

+ +

CHAD: [laughs]

+ +

CHELINDE: So he was like, how do I find someone or talk to someone who's caught up to where I'm at so I can actually have a conversation? And so we brainstormed, and we tried to solve the problem of let's just create a spoiler-free chat kind of solution that would allow people to talk about shows that they're caught up on. And then that we've iterated and evolved, and that's kind of led to where we're at today.

+ +

CHAD: And when was that?

+ +

CHELINDE: That was, I want to say, 2014. That was when I graduated from BU. So in the summer of 2014, that's when we first had the idea. And then from there, we just brainstormed, had a bunch of meetings, and then just took a year in stealth mode trying to figure out how we wanted to create a business plan. And then, from there, we hit the ground running.

+ +

CHAD: You and your friend, what were your sort of core competencies, the two of you?

+ +

CHELINDE: I'm the tech background, so to speak, because, as I mentioned, I went to BU. My degree is in management information systems, which is basically business IT. So I was trying to leverage all my technology skills there and also my business skills to say how do we, one, build the app and two, create a business that can actually support it for the long term?

+ +

And he had more of the idea on the customer side of how can we create an experience or a user engagement platform that allows people to constantly come back and constantly want to find more reason to use our app? Because as we know, people watch the show on TV, but the app is a conduit to that. And so, we want to figure out a way to get people to constantly use our app but also not interrupt their TV-watching experience.

+ +

CHAD: So you said you're trying to figure out a business plan. You're refining the concept. At what point do you start making the leap to actually writing an app?

+ +

CHELINDE: With all apps, you start with this concept called wireframes, and so we built out a bunch of wireframes. Two of my friends from high school we all built the app together. And then one of them went to Miami, and his friend from Miami he's the one that actually helped us develop the app and code. And so we worked with him to actually say, "Hey, these are our wireframes. We're trying to make this into an app. Can you build it out?" And so, we worked with him over a year to make that a reality.

+ +

CHAD: And it took about a year to get to launch.

+ +

CHELINDE: We actually started on Android, and we were trying to create an MVP or prototype. And so we took that idea like I said, we were working for a year, to this company called Netcapital, which is a crowdfunding platform for startups and companies. And we launched on Netcapital in May of 2020. With that idea, we raised 50k in almost three months. And with that money, we actually built the app from there. And so the app you see in the App Store now is from the money that we've raised on Netcapital.

+ +

CHAD: Did you throw away that original version and start over?

+ +

CHELINDE: I wouldn't say throw away. We kind of used it as a launching point. But we don't have any Android version right now. We're strictly in iOS.

+ +

CHAD: Yeah, that was notable to me. Tell me more about that.

+ +

CHELINDE: So going from Android to iOS it was really a business decision there because our developer had knowledge in Android but didn't have the iOS background. And so when we went on Netcapital, we used that money to actually hire a real development team. That's who's building our app now. So we work with them to build our app. And going to iOS has allowed us to, at least in the meantime, expand in the U.S. market a lot quicker.

+ +

CHAD: Now, are they building it in first-party frameworks only for iOS, or are they using something that is going to allow you to go expand to Android in the future?

+ +

CHELINDE: So right now, we're strictly iOS only. We would like to move to a React Native or a tool that allows us to promote to both. When we first started, we wanted to just focus on iOS, given our costs.

+ +

CHAD: These are common problems that a lot of startups or common decisions that a lot of startups have to make. And it's not always straightforward. Were you worried about this?

+ +

CHELINDE: Yes. Because that's one of the things now it's we would love to have an Android version. But for me, being more of a purist, I didn't want the code to work in one system and not another. And given that we only had...in my mind, it's like you have one shot to make an impression. And when you go out and launch it on the App Store, I didn't want it to be half-baked in one and half-baked in the other. I'd rather have one be exactly how we want it to look, and then we can adapt as we grow.

+ +

CHAD: How has it been working for you, then?

+ +

CHELINDE: So far, so good. We're actually in the process of releasing some new features later this month, and so like I said, the watchlist feature, which allows you to add shows that you're going to watch in the future. We also have the ability to create chats through the chat functionality because previously, you had to create a new chat every single time. So we've made it easier for people to start chats, and also you can do group chats as well. So it's not just individuals. You can have a whole group of people in one conversation.

+ +

CHAD: So some of these features there must be a backend server powering all of this, right?

+ +

CHELINDE: Yes. So we use the Google Cloud Firestore for our backend. And another cool part about our app is we have a lot of analytics about what people are watching. And that's where we take their data from our cloud, the Google Cloud Firestore, and we send it to the BigQuery, also a Google platform. And then we use the Google Analytics that we have on the app to then do our reports around who's watching what, top 10 shows for the past month, the top 10 shows based on if you're male or female, based on what age group. So we have all the analytics on the viewing habits from the data that we've collected.

+ +

CHAD: Can you tell me how many users you have now?

+ +

CHELINDE: As of right now, we are at 820. We are looking to obviously get a little bit over to that 1,000 users mark, and then we can have a better sense of what kind of insights we can glean from there.

+ +

CHAD: Well, hopefully, coming on this show will help you do that. So if you're listening and this sounds interesting to you, where are the best places...so people can search for MustWatch on the App Store, the iOS App Store?

+ +

CHELINDE: Yep. And we also have a website mustwatch.com if people want to check that out as well.

+ +

CHAD: Yeah, so let's do it. Let's push them over the top and get those numbers up. I'm curious about usage patterns. Are you able to see any patterns in terms of what causes people to either keep using the app or not?

+ +

CHELINDE: Yeah. So the main thing that keeps people using the app is having chat groups with people and then also getting recommendations. Like I mentioned before, we have the social recommendations of people just showing you what shows people watch. But there's also direct one-to-one. If you're on the app, I could send you a recommendation. And that's what drives a lot of people to go on the app and find new shows.

+ +

Another thing that we see is a lot of people just searching, just looking up the shows that are on the app because our database of shows is actually pretty robust. I was talking to someone yesterday; he's Korean. And he was using his phone to type in a show. And he was using a Korean keyboard, and the show came up. And he was like, "Oh wow, I didn't even know you guys support multiple languages." And I was like, "Yes, we support." Our database of shows is very expansive. So if you're in Korea, if you're in Japan, if you like anime, if you like telenovelas, we have all types of shows on our app as well.

+ +

CHAD: Do you get that database from somewhere?

+ +

CHELINDE: Yeah, so there's actually a TV show API called TMDB, which pretty much is an open-source, free database that you can pull from. So we use that as our source for shows.

+ +

CHAD: That's cool. Speaking of shows, I noticed on the MustWatch website, on the team page, you all list your favorite shows and what you're currently watching. I think you and I have different tastes in shows. [laughter] I have heard of the shows that are your favorite, but I have not watched any of them.

+ +

CHELINDE: Oh wow. [laughs] What are your favorite shows?

+ +

CHAD: I think actually my shows match the shows listed by Rob, your CFO.

+ +

CHELINDE: Oh wow. [laughs]

+ +

CHAD: And my all-time favorite show is, I think, The Leftovers.

+ +

CHELINDE: Okay. So yeah, and that's the cool thing about this app is like, if you're on the app, you would see Rob's shows on the app too. Because if you download the app, you become friends with all of us immediately, so you have friends on there to start.

+ +

CHAD: Oh, that's a cool idea.

+ +

CHELINDE: So it gives you a way to just see what the app can look like before...because if you're on there by yourself as one person, it's a social app. It's meant to be with people. It doesn't really give you that clarity. So I bring that up because that's the one cool thing about the app is you always are surprised by what shows people watch, even if they're your friend. It's like, oh, I didn't know you would like that show. Or oh, I liked that show, and you don't like that show.

+ +

And it's a very cool icebreaker or just a social connection that you can make because everyone's putting shows on the app. And one way, actually...I was talking to someone the other day thinking about how like Spotify, you put all your playlists and all your shows. This app is kind of like a Spotify but for TV shows and also for movies. So it's not just shows, movies as well.

+ +

CHAD: And the cool things that Spotify does in terms of the reports that they release annually to each individual person and everything. Like, that's all stuff you can do too.

+ +

CHELINDE: Yep.

+ +

CHAD: Yeah, it's cool. So your background actually is in sort of business intelligence, data analysis, and analyst, right?

+ +

CHELINDE: Yes, that's correct. For my day job...I just want to back up. I also have a day job while also doing this. And I've primarily been the past couple of years a BI analyst. So previously, I was at HarbourVest, which is a private equity firm here in Boston. And then, I recently joined Liberty Mutual Investments also as BI data analyst. So I've been very involved in the financial services side of data analytics, which has allowed me to just get other insights on how technology works and just also getting exposure to the whole industry as well.

+ +

CHAD: So you basically have two reasons why you want to get the number of users up. One is from a co-founder perspective and founder perspective; you want to get the number of users up. But from a data perspective, you want to get the users up so that you have more data to play with.

+ +

CHELINDE: Exactly, exactly. The more users we have, the more data we can collect. And then data we can glean insights, and then provide value to our customers as well. Because our app users, if we can know which shows they are liking, we can also then tell them about shows that they also might like. Because once you find commonalities in shows that people are liking, you can then give them better recommendations.

+ +

And we think that the social aspect of our app, the fact that we have all of your friends on there and they're giving you recommendations, it's better than just, oh, you've watched this show in the past three years, and it's on Netflix's algorithm of watched shows. That, to us, doesn't really seem as insightful and helpful to people.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment, but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: url tbot.io/sprint

+ +

CHAD: So you mentioned you have another job in addition to all this work you've been doing on MustWatch. How has that been? You know, starting a company, working on it while also having a full-time job elsewhere?

+ +

CHELINDE: Yeah, it's definitely been, I guess, one of the challenging things I would say. It's definitely been rewarding. It takes a lot of time management, I would say, because you have to balance your day job and manage something on the side. I think the biggest hurdle I had was when we were first launching the app on the App Store, meeting with developers, and trying to fundraise all at the same time because I was just pressed for time.

+ +

Because of the COVID, COVID happened right when we were launching. So working from home all day everyday kind of helped because I didn't have an hour commute anymore. So I got two hours back in my day. So I could, instead of going to work and just commuting, I had an hour in the morning and an hour after. I could use that time for MustWatch. But I had to definitely sacrifice some of my social life to make that happen.

+ +

[laughter]

+ +

CHAD: I assume that you have the plans that you would hope that things with MustWatch get to the point where you could do it full time.

+ +

CHELINDE: Yes. The goal is to get MustWatch to a point where we can pay our employees and have salaries, and everyone can just be working from the company. But as everyone knows, if you're in a startup, you got to just not pay yourself and make sure everything goes into the company. How I see it is you can't pay yourself until everything else is working.

+ +

CHAD: Yeah, I mean, people hear the startup stories of raising a whole bunch of money, working exclusively on it, having more than enough. I think that that's actually not necessarily the norm; that's the outlier. I think it's more common, more widespread to do what you're doing, to have an idea, and to be working on it and growing it while also holding down another job.

+ +

CHELINDE: Because as we all know, the bills need to be paid, [laughs] and those don't go away. But I didn't want to give up on the dream. So if you want to make it happen, you can make it happen because while I was at HarbourVest, I also was at Babson getting my master's degree in business analytics. So at one point in time, I was working full-time at grad school and doing MustWatch. To me, that was probably the most busiest period of my life, but I did get through it. [laughs] But definitely took a lot, but now we're here. And we've gotten support from the GK Fund, and I couldn't be happier with where the future lies ahead.

+ +

CHAD: One of the things about the GK Fund is that it's a grant. It's not an investment where you're giving up part of your company in order to do it, which I think is really important, especially for very early-stage companies, not to have to give away a significant portion of their company just to get some angel investment or that startup fund. I assume that's one of the reasons why it's been a big impact for you.

+ +

CHELINDE: Absolutely. I mean, one, having it not be an investment was a lifesaver for us. At the time, we were still trying to figure out how to just get cash to get to the next stage. And so, for us, a grant was literally the blessing or a miracle at the perfect timing because it allowed us to...it gave us a little kickstart.

+ +

Because I mean, as everyone knows, if you're a startup, you're always low on cash. And you're always trying to decide what's the best way to move the company forward? And that just gave us that breathing room without having to worry about paying it back, or a timetable to now let us actually grow and do what we can do best.

+ +

CHAD: Do you hope to take a more traditional investment in the future?

+ +

CHELINDE: Yes. So we're actually planning to do another fundraising on Netcapital. This time we're planning to raise $450,000. And that's going to help us build out the app, increase our marketing, and then potentially also build an Android version.

+ +

CHAD: So I'm not sure that everyone who's listening will know what Netcapital actually is.

+ +

CHELINDE: Yep. So Netcapital is a crowdfunding equity platform which allows retail investors to directly invest in startups. So if you're looking for another way to get into early-stage companies, Netcapital is a great place to do that. It's similar to if you've heard of StartEngine. It's a similar concept to that. And it's mainly you pretty much buy shares in a company, and then that company will then take that money to then use it for the funds that they have set in their offering. And you actually get an equity stake in the company.

+ +

And so, for us, it's great because typically, those types of fundraising opportunities don't come for us. You need to have VC-backed or some kind of angel investor to get to that level. But having it be open to everybody, there's a larger pool of retail investors that allow you to get to where you need to go. Because if you can get a couple of your family, friends around to give you like a hundred or a couple thousand, it's definitely a better avenue than just going the VC route or just getting a loan from a grant or a startup, an SBA loan, something like that.

+ +

CHAD: Traditionally, something like Netcapital was not really possible. But my understanding is that in 2016, the laws changed to allow smaller investments and get actual equity and for companies to offer it in such a way that wasn't possible before.

+ +

CHELINDE: Yes, I believe it's called a Reg CF, Regulation Crowdfunding, and that was the law that was passed in 2016. And that is crucial to us being able to have an offering on Netcapital.

+ +

CHAD: So it's not like Kickstarter where, you know, in Kickstarter, you're offering a new product or something, and people aren't becoming investors in your actual company. Netcapital is they are actual investors. And so, as an entrepreneur, as a company, what do your obligations to those investors look like?

+ +

CHELINDE: So because they're investors, we have to give them quarterly updates. We have to file our annual report. We have to disclose any conflict of interest. There's a whole SEC team that has to approve and review any offering that goes on the platform to make sure that we are following all SEC guidelines. And then also, we are liable because they're investors. So they can email us. They can reach out to us, and we will respond because they are our shareholders. [chuckles] And so we need to make sure they're happy as well.

+ +

CHAD: Yeah, with one of the things that Netcapital does is it sort of works like Kickstarter in that if you don't meet the goals that you've set, it doesn't actually happen.

+ +

CHELINDE: Yep, there's a minimum investment threshold, so it depends on how much money you're raising. So last time, when we raised 50k, the minimum was 10k. So if we didn't get over $10,000, all the investors would get their money back. But if we got over that threshold, then that's the money that we would be able to use for our company.

+ +

CHAD: 450,000 is significantly more than 50,000. What do you feel like you need to do in order to make sure that you hit the goal?

+ +

CHELINDE: So one thing is going on podcasts like this to make sure that people know about it. [laughter] Secondly, we're actually going to be partnering with the GK Fund to do some more media exposure there. And then we're also partnering with Silicon Valley Bank because they're actually our partners on the banking side. And so, I'm going to be partnering with their network to leverage their connections as well. And then we're also going to be just doing the classic social media, posting on Facebook, Instagram, LinkedIn, friends, or family. All avenues of media we will be pushing out MustWatch.

+ +

CHAD: When do you expect to open up that listing?

+ +

CHELINDE: We're targeting mid-July right now. So that's when we're planning on going live on Netcapital pending the compliance review and all the other legal stuff, but that's when we plan to go live.

+ +

CHAD: Okay, well, if you're listening to this episode, it's going to be going live in a couple of weeks. And so definitely follow along and check it out. Cool. Well, what are your goals for that next funding round? What do you expect to use it for?

+ +

CHELINDE: We expect to use our funding round on improving the iOS experience, so adding more features because we've gotten some customer feedback. And we have a laundry list or a backlog of items we want to add but obviously limited by cash constraints. So once we have the money, we can do what we want to do.

+ +

And then we also would like to improve our marketing. So we want to have a real marketing team and improve our SEO. And then we also have a connection with Hollywood. So the writer for Ford and Ferrari, his name is Jason Keller is on our team. And we want to see how we can get our foot in the door with Hollywood as well.

+ +

CHAD: That's really cool. What would that look like in your ideal scenario?

+ +

CHELINDE: Ideally, we'd have some celebrities or Hollywood A-listers on the app using MustWatch and then promoting their shows or promoting our app in one of their media engagements as well.

+ +

CHAD: Or chatting with people about the episode that just came out and that kind of thing. That'd be really cool.

+ +

CHELINDE: Yeah, exactly. We want to get people to just engage on the app with celebrities as well. That's definitely one of the avenues we were thinking as well.

+ +

CHAD: One of the big trends right now is TV companies making companion podcasts to the shows that they make. I can totally see them doing this kind of thing as well.

+ +

CHELINDE: As we all know, user engagement and fan engagement is crucial for these companies, and MustWatch would be a crucial way for a lot of companies to connect easily.

+ +

CHAD: This is a little bit of an aside, but I was sort of surprised that you were able to get mustwatch.com.

+ +

CHELINDE: It was not cheap. [laughter] I think for some people who were following us for a while, when we first launched, our name was WatchParty. And that's how we originally started our company. But as we evolved, Facebook released a watch party feature; Hulu, Amazon all have these watch party features, and they weren't exactly like our company. And we didn't want to get any confusion in branding. And so we had a long discussion around what name do we change to, and how do we still convey the right feel for the app, and what we want to do?

+ +

Because on our app, you're not watching the show on our app, I want to make that very clear. It's all about finding a new show, chatting, and connecting with people, but you're not watching on the app. And so it's tough to...not tough, but we wanted to make sure that people knew that the app was for finding new shows. But also, it has to be like a must-watch. Like, I need to go watch this right now because it's something really good. And so that's how we came across this name.

+ +

CHAD: You mentioned earlier on that expenses are tight when you're working on something new. How worried were you about spending money on a domain name?

+ +

CHELINDE: So this is also where our partnership with Netcapital came into play because they helped us in terms of getting us off the ground. And we work with them on the business side as well. And this is one of the avenues where they helped support us.

+ +

CHAD: Oh, wow. Wow. It's great that you're able to pull together these different resources and get that support.

+ +

CHELINDE: Yeah, to us, it's been crucial because, without the support, it's very tough to get your name out there. It's very tough to promote the idea. And so, with Netcapital and the GK Fund, it definitely puts us in a better light than usual.

+ +

CHAD: Well, Che, I really wish you the best and MustWatch the best and your whole team. And good luck over the next few weeks as you open up this round on Netcapital. I ask everybody, again, go check out the app. Sometimes we talk to companies of all different stages on the show. And I especially think it's important when we have someone that's just getting started really trying to hit these user numbers that if people could go check it out, that'd be great.

+ +

CHELINDE: Really appreciate it.

+ +

CHAD: If folks want to follow along with you, get in touch with you, that kind of thing, where are all the different places where they can do that?

+ +

CHELINDE: Reach out to me on LinkedIn. I'm on LinkedIn, Che Edouard. You can reach out to us on mustwatch.com. We have a contact us email there. You can also email me at che@mustwatch.com if you want to reach out. I am available on all platforms.

+ +

CHAD: Wonderful. And you can subscribe to the show and find notes and a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chelinde Edouard is Co-Founder and CEO of MustWatch, which connects people through television.

+ +

Chad talks with Che about creating a social and user engagement platform that allows people to come back and constantly use an app without interrupting TV-watching experiences, how they use data to improve user experience, and fundraising and giving investors opportunities to help build out the app, increase marketing, and potentially build an Android version.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Che Edouard, Co-Founder and CEO of MustWatch, which connects people through television. Che, thank you for joining me.

+ +

CHELINDE: Thank you for having me. I appreciate it.

+ +

CHAD: So astute listeners of the show will note maybe that name sounds familiar. And that's because you and MustWatch were mentioned on Episode 419, which was about the GK Fund with Michael Benezra. And I asked him for examples of the kinds of companies that he was excited about that they had given their grants to. And you're the one he called out, and so that jumped out at me. And thanks for joining the show.

+ +

CHELINDE: Thank you for having me. Really appreciate it. And I definitely want to shout out the GK Fund. They've definitely been a huge support to us since giving us the grant. And they're definitely leading the charge in this new avenue of racial inequality and helping startups in that fashion in Boston.

+ +

CHAD: So I'm curious; before we get too far down the road of where you're at today and how you got there, let's take a step back and just remind people what MustWatch is.

+ +

CHELINDE: Absolutely. MustWatch is an app that's on the App Store now. So even if you have an iPhone, you can download it. And it's an app that's revolving around TV. So it allows you to see what shows your friends watch, chat with them about them, and send recommendations all in one place. So we think of it as like a social hub for all of your TV needs.

+ +

CHAD: I think people who hear this might be like, oh, does this exist already? That kind of thing. And there are a couple of things a little bit like this, but it doesn't seem like there's really anything that's quite like this, right?

+ +

CHELINDE: Exactly. So a lot of the social TV apps and other services today focus on one feature, for example, chat or recommendations, or giving reviews about shows, or having a list of them. But our app, we do all of it in one place. So on our app, it can show which shows you like. You can also share with your friends directly; hey, you should go watch this show because I think you should like it.

+ +

We also have this feature called watchlist, which is our natural social recommendations of here are all the shows that your friends are watching that you don't watch. And so it's a way to give people a way to find new shows without getting the same recommendations from Netflix and Hulu that are not really accurate today.

+ +

CHAD: How did you hit upon this idea?

+ +

CHELINDE: Actually, one of my high school friends, we were all brainstorming and coming up with ideas for companies. And then one day, he was at work, and he was trying to talk about Game of Thrones, but his boss wouldn't let him because he wasn't caught up on the season. He wasn't there.

+ +

CHAD: [laughs]

+ +

CHELINDE: So he was like, how do I find someone or talk to someone who's caught up to where I'm at so I can actually have a conversation? And so we brainstormed, and we tried to solve the problem of let's just create a spoiler-free chat kind of solution that would allow people to talk about shows that they're caught up on. And then that we've iterated and evolved, and that's kind of led to where we're at today.

+ +

CHAD: And when was that?

+ +

CHELINDE: That was, I want to say, 2014. That was when I graduated from BU. So in the summer of 2014, that's when we first had the idea. And then from there, we just brainstormed, had a bunch of meetings, and then just took a year in stealth mode trying to figure out how we wanted to create a business plan. And then, from there, we hit the ground running.

+ +

CHAD: You and your friend, what were your sort of core competencies, the two of you?

+ +

CHELINDE: I'm the tech background, so to speak, because, as I mentioned, I went to BU. My degree is in management information systems, which is basically business IT. So I was trying to leverage all my technology skills there and also my business skills to say how do we, one, build the app and two, create a business that can actually support it for the long term?

+ +

And he had more of the idea on the customer side of how can we create an experience or a user engagement platform that allows people to constantly come back and constantly want to find more reason to use our app? Because as we know, people watch the show on TV, but the app is a conduit to that. And so, we want to figure out a way to get people to constantly use our app but also not interrupt their TV-watching experience.

+ +

CHAD: So you said you're trying to figure out a business plan. You're refining the concept. At what point do you start making the leap to actually writing an app?

+ +

CHELINDE: With all apps, you start with this concept called wireframes, and so we built out a bunch of wireframes. Two of my friends from high school we all built the app together. And then one of them went to Miami, and his friend from Miami he's the one that actually helped us develop the app and code. And so we worked with him to actually say, "Hey, these are our wireframes. We're trying to make this into an app. Can you build it out?" And so, we worked with him over a year to make that a reality.

+ +

CHAD: And it took about a year to get to launch.

+ +

CHELINDE: We actually started on Android, and we were trying to create an MVP or prototype. And so we took that idea like I said, we were working for a year, to this company called Netcapital, which is a crowdfunding platform for startups and companies. And we launched on Netcapital in May of 2020. With that idea, we raised 50k in almost three months. And with that money, we actually built the app from there. And so the app you see in the App Store now is from the money that we've raised on Netcapital.

+ +

CHAD: Did you throw away that original version and start over?

+ +

CHELINDE: I wouldn't say throw away. We kind of used it as a launching point. But we don't have any Android version right now. We're strictly in iOS.

+ +

CHAD: Yeah, that was notable to me. Tell me more about that.

+ +

CHELINDE: So going from Android to iOS it was really a business decision there because our developer had knowledge in Android but didn't have the iOS background. And so when we went on Netcapital, we used that money to actually hire a real development team. That's who's building our app now. So we work with them to build our app. And going to iOS has allowed us to, at least in the meantime, expand in the U.S. market a lot quicker.

+ +

CHAD: Now, are they building it in first-party frameworks only for iOS, or are they using something that is going to allow you to go expand to Android in the future?

+ +

CHELINDE: So right now, we're strictly iOS only. We would like to move to a React Native or a tool that allows us to promote to both. When we first started, we wanted to just focus on iOS, given our costs.

+ +

CHAD: These are common problems that a lot of startups or common decisions that a lot of startups have to make. And it's not always straightforward. Were you worried about this?

+ +

CHELINDE: Yes. Because that's one of the things now it's we would love to have an Android version. But for me, being more of a purist, I didn't want the code to work in one system and not another. And given that we only had...in my mind, it's like you have one shot to make an impression. And when you go out and launch it on the App Store, I didn't want it to be half-baked in one and half-baked in the other. I'd rather have one be exactly how we want it to look, and then we can adapt as we grow.

+ +

CHAD: How has it been working for you, then?

+ +

CHELINDE: So far, so good. We're actually in the process of releasing some new features later this month, and so like I said, the watchlist feature, which allows you to add shows that you're going to watch in the future. We also have the ability to create chats through the chat functionality because previously, you had to create a new chat every single time. So we've made it easier for people to start chats, and also you can do group chats as well. So it's not just individuals. You can have a whole group of people in one conversation.

+ +

CHAD: So some of these features there must be a backend server powering all of this, right?

+ +

CHELINDE: Yes. So we use the Google Cloud Firestore for our backend. And another cool part about our app is we have a lot of analytics about what people are watching. And that's where we take their data from our cloud, the Google Cloud Firestore, and we send it to the BigQuery, also a Google platform. And then we use the Google Analytics that we have on the app to then do our reports around who's watching what, top 10 shows for the past month, the top 10 shows based on if you're male or female, based on what age group. So we have all the analytics on the viewing habits from the data that we've collected.

+ +

CHAD: Can you tell me how many users you have now?

+ +

CHELINDE: As of right now, we are at 820. We are looking to obviously get a little bit over to that 1,000 users mark, and then we can have a better sense of what kind of insights we can glean from there.

+ +

CHAD: Well, hopefully, coming on this show will help you do that. So if you're listening and this sounds interesting to you, where are the best places...so people can search for MustWatch on the App Store, the iOS App Store?

+ +

CHELINDE: Yep. And we also have a website mustwatch.com if people want to check that out as well.

+ +

CHAD: Yeah, so let's do it. Let's push them over the top and get those numbers up. I'm curious about usage patterns. Are you able to see any patterns in terms of what causes people to either keep using the app or not?

+ +

CHELINDE: Yeah. So the main thing that keeps people using the app is having chat groups with people and then also getting recommendations. Like I mentioned before, we have the social recommendations of people just showing you what shows people watch. But there's also direct one-to-one. If you're on the app, I could send you a recommendation. And that's what drives a lot of people to go on the app and find new shows.

+ +

Another thing that we see is a lot of people just searching, just looking up the shows that are on the app because our database of shows is actually pretty robust. I was talking to someone yesterday; he's Korean. And he was using his phone to type in a show. And he was using a Korean keyboard, and the show came up. And he was like, "Oh wow, I didn't even know you guys support multiple languages." And I was like, "Yes, we support." Our database of shows is very expansive. So if you're in Korea, if you're in Japan, if you like anime, if you like telenovelas, we have all types of shows on our app as well.

+ +

CHAD: Do you get that database from somewhere?

+ +

CHELINDE: Yeah, so there's actually a TV show API called TMDB, which pretty much is an open-source, free database that you can pull from. So we use that as our source for shows.

+ +

CHAD: That's cool. Speaking of shows, I noticed on the MustWatch website, on the team page, you all list your favorite shows and what you're currently watching. I think you and I have different tastes in shows. [laughter] I have heard of the shows that are your favorite, but I have not watched any of them.

+ +

CHELINDE: Oh wow. [laughs] What are your favorite shows?

+ +

CHAD: I think actually my shows match the shows listed by Rob, your CFO.

+ +

CHELINDE: Oh wow. [laughs]

+ +

CHAD: And my all-time favorite show is, I think, The Leftovers.

+ +

CHELINDE: Okay. So yeah, and that's the cool thing about this app is like, if you're on the app, you would see Rob's shows on the app too. Because if you download the app, you become friends with all of us immediately, so you have friends on there to start.

+ +

CHAD: Oh, that's a cool idea.

+ +

CHELINDE: So it gives you a way to just see what the app can look like before...because if you're on there by yourself as one person, it's a social app. It's meant to be with people. It doesn't really give you that clarity. So I bring that up because that's the one cool thing about the app is you always are surprised by what shows people watch, even if they're your friend. It's like, oh, I didn't know you would like that show. Or oh, I liked that show, and you don't like that show.

+ +

And it's a very cool icebreaker or just a social connection that you can make because everyone's putting shows on the app. And one way, actually...I was talking to someone the other day thinking about how like Spotify, you put all your playlists and all your shows. This app is kind of like a Spotify but for TV shows and also for movies. So it's not just shows, movies as well.

+ +

CHAD: And the cool things that Spotify does in terms of the reports that they release annually to each individual person and everything. Like, that's all stuff you can do too.

+ +

CHELINDE: Yep.

+ +

CHAD: Yeah, it's cool. So your background actually is in sort of business intelligence, data analysis, and analyst, right?

+ +

CHELINDE: Yes, that's correct. For my day job...I just want to back up. I also have a day job while also doing this. And I've primarily been the past couple of years a BI analyst. So previously, I was at HarbourVest, which is a private equity firm here in Boston. And then, I recently joined Liberty Mutual Investments also as BI data analyst. So I've been very involved in the financial services side of data analytics, which has allowed me to just get other insights on how technology works and just also getting exposure to the whole industry as well.

+ +

CHAD: So you basically have two reasons why you want to get the number of users up. One is from a co-founder perspective and founder perspective; you want to get the number of users up. But from a data perspective, you want to get the users up so that you have more data to play with.

+ +

CHELINDE: Exactly, exactly. The more users we have, the more data we can collect. And then data we can glean insights, and then provide value to our customers as well. Because our app users, if we can know which shows they are liking, we can also then tell them about shows that they also might like. Because once you find commonalities in shows that people are liking, you can then give them better recommendations.

+ +

And we think that the social aspect of our app, the fact that we have all of your friends on there and they're giving you recommendations, it's better than just, oh, you've watched this show in the past three years, and it's on Netflix's algorithm of watched shows. That, to us, doesn't really seem as insightful and helpful to people.

+ +

Mid-Roll Ad:

+ +

When starting a new project, we understand that you want to make the right choices in technology, features, and investment, but that you don’t have all year to do extended research.

+ +

In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts.

+ +

Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: url tbot.io/sprint

+ +

CHAD: So you mentioned you have another job in addition to all this work you've been doing on MustWatch. How has that been? You know, starting a company, working on it while also having a full-time job elsewhere?

+ +

CHELINDE: Yeah, it's definitely been, I guess, one of the challenging things I would say. It's definitely been rewarding. It takes a lot of time management, I would say, because you have to balance your day job and manage something on the side. I think the biggest hurdle I had was when we were first launching the app on the App Store, meeting with developers, and trying to fundraise all at the same time because I was just pressed for time.

+ +

Because of the COVID, COVID happened right when we were launching. So working from home all day everyday kind of helped because I didn't have an hour commute anymore. So I got two hours back in my day. So I could, instead of going to work and just commuting, I had an hour in the morning and an hour after. I could use that time for MustWatch. But I had to definitely sacrifice some of my social life to make that happen.

+ +

[laughter]

+ +

CHAD: I assume that you have the plans that you would hope that things with MustWatch get to the point where you could do it full time.

+ +

CHELINDE: Yes. The goal is to get MustWatch to a point where we can pay our employees and have salaries, and everyone can just be working from the company. But as everyone knows, if you're in a startup, you got to just not pay yourself and make sure everything goes into the company. How I see it is you can't pay yourself until everything else is working.

+ +

CHAD: Yeah, I mean, people hear the startup stories of raising a whole bunch of money, working exclusively on it, having more than enough. I think that that's actually not necessarily the norm; that's the outlier. I think it's more common, more widespread to do what you're doing, to have an idea, and to be working on it and growing it while also holding down another job.

+ +

CHELINDE: Because as we all know, the bills need to be paid, [laughs] and those don't go away. But I didn't want to give up on the dream. So if you want to make it happen, you can make it happen because while I was at HarbourVest, I also was at Babson getting my master's degree in business analytics. So at one point in time, I was working full-time at grad school and doing MustWatch. To me, that was probably the most busiest period of my life, but I did get through it. [laughs] But definitely took a lot, but now we're here. And we've gotten support from the GK Fund, and I couldn't be happier with where the future lies ahead.

+ +

CHAD: One of the things about the GK Fund is that it's a grant. It's not an investment where you're giving up part of your company in order to do it, which I think is really important, especially for very early-stage companies, not to have to give away a significant portion of their company just to get some angel investment or that startup fund. I assume that's one of the reasons why it's been a big impact for you.

+ +

CHELINDE: Absolutely. I mean, one, having it not be an investment was a lifesaver for us. At the time, we were still trying to figure out how to just get cash to get to the next stage. And so, for us, a grant was literally the blessing or a miracle at the perfect timing because it allowed us to...it gave us a little kickstart.

+ +

Because I mean, as everyone knows, if you're a startup, you're always low on cash. And you're always trying to decide what's the best way to move the company forward? And that just gave us that breathing room without having to worry about paying it back, or a timetable to now let us actually grow and do what we can do best.

+ +

CHAD: Do you hope to take a more traditional investment in the future?

+ +

CHELINDE: Yes. So we're actually planning to do another fundraising on Netcapital. This time we're planning to raise $450,000. And that's going to help us build out the app, increase our marketing, and then potentially also build an Android version.

+ +

CHAD: So I'm not sure that everyone who's listening will know what Netcapital actually is.

+ +

CHELINDE: Yep. So Netcapital is a crowdfunding equity platform which allows retail investors to directly invest in startups. So if you're looking for another way to get into early-stage companies, Netcapital is a great place to do that. It's similar to if you've heard of StartEngine. It's a similar concept to that. And it's mainly you pretty much buy shares in a company, and then that company will then take that money to then use it for the funds that they have set in their offering. And you actually get an equity stake in the company.

+ +

And so, for us, it's great because typically, those types of fundraising opportunities don't come for us. You need to have VC-backed or some kind of angel investor to get to that level. But having it be open to everybody, there's a larger pool of retail investors that allow you to get to where you need to go. Because if you can get a couple of your family, friends around to give you like a hundred or a couple thousand, it's definitely a better avenue than just going the VC route or just getting a loan from a grant or a startup, an SBA loan, something like that.

+ +

CHAD: Traditionally, something like Netcapital was not really possible. But my understanding is that in 2016, the laws changed to allow smaller investments and get actual equity and for companies to offer it in such a way that wasn't possible before.

+ +

CHELINDE: Yes, I believe it's called a Reg CF, Regulation Crowdfunding, and that was the law that was passed in 2016. And that is crucial to us being able to have an offering on Netcapital.

+ +

CHAD: So it's not like Kickstarter where, you know, in Kickstarter, you're offering a new product or something, and people aren't becoming investors in your actual company. Netcapital is they are actual investors. And so, as an entrepreneur, as a company, what do your obligations to those investors look like?

+ +

CHELINDE: So because they're investors, we have to give them quarterly updates. We have to file our annual report. We have to disclose any conflict of interest. There's a whole SEC team that has to approve and review any offering that goes on the platform to make sure that we are following all SEC guidelines. And then also, we are liable because they're investors. So they can email us. They can reach out to us, and we will respond because they are our shareholders. [chuckles] And so we need to make sure they're happy as well.

+ +

CHAD: Yeah, with one of the things that Netcapital does is it sort of works like Kickstarter in that if you don't meet the goals that you've set, it doesn't actually happen.

+ +

CHELINDE: Yep, there's a minimum investment threshold, so it depends on how much money you're raising. So last time, when we raised 50k, the minimum was 10k. So if we didn't get over $10,000, all the investors would get their money back. But if we got over that threshold, then that's the money that we would be able to use for our company.

+ +

CHAD: 450,000 is significantly more than 50,000. What do you feel like you need to do in order to make sure that you hit the goal?

+ +

CHELINDE: So one thing is going on podcasts like this to make sure that people know about it. [laughter] Secondly, we're actually going to be partnering with the GK Fund to do some more media exposure there. And then we're also partnering with Silicon Valley Bank because they're actually our partners on the banking side. And so, I'm going to be partnering with their network to leverage their connections as well. And then we're also going to be just doing the classic social media, posting on Facebook, Instagram, LinkedIn, friends, or family. All avenues of media we will be pushing out MustWatch.

+ +

CHAD: When do you expect to open up that listing?

+ +

CHELINDE: We're targeting mid-July right now. So that's when we're planning on going live on Netcapital pending the compliance review and all the other legal stuff, but that's when we plan to go live.

+ +

CHAD: Okay, well, if you're listening to this episode, it's going to be going live in a couple of weeks. And so definitely follow along and check it out. Cool. Well, what are your goals for that next funding round? What do you expect to use it for?

+ +

CHELINDE: We expect to use our funding round on improving the iOS experience, so adding more features because we've gotten some customer feedback. And we have a laundry list or a backlog of items we want to add but obviously limited by cash constraints. So once we have the money, we can do what we want to do.

+ +

And then we also would like to improve our marketing. So we want to have a real marketing team and improve our SEO. And then we also have a connection with Hollywood. So the writer for Ford and Ferrari, his name is Jason Keller is on our team. And we want to see how we can get our foot in the door with Hollywood as well.

+ +

CHAD: That's really cool. What would that look like in your ideal scenario?

+ +

CHELINDE: Ideally, we'd have some celebrities or Hollywood A-listers on the app using MustWatch and then promoting their shows or promoting our app in one of their media engagements as well.

+ +

CHAD: Or chatting with people about the episode that just came out and that kind of thing. That'd be really cool.

+ +

CHELINDE: Yeah, exactly. We want to get people to just engage on the app with celebrities as well. That's definitely one of the avenues we were thinking as well.

+ +

CHAD: One of the big trends right now is TV companies making companion podcasts to the shows that they make. I can totally see them doing this kind of thing as well.

+ +

CHELINDE: As we all know, user engagement and fan engagement is crucial for these companies, and MustWatch would be a crucial way for a lot of companies to connect easily.

+ +

CHAD: This is a little bit of an aside, but I was sort of surprised that you were able to get mustwatch.com.

+ +

CHELINDE: It was not cheap. [laughter] I think for some people who were following us for a while, when we first launched, our name was WatchParty. And that's how we originally started our company. But as we evolved, Facebook released a watch party feature; Hulu, Amazon all have these watch party features, and they weren't exactly like our company. And we didn't want to get any confusion in branding. And so we had a long discussion around what name do we change to, and how do we still convey the right feel for the app, and what we want to do?

+ +

Because on our app, you're not watching the show on our app, I want to make that very clear. It's all about finding a new show, chatting, and connecting with people, but you're not watching on the app. And so it's tough to...not tough, but we wanted to make sure that people knew that the app was for finding new shows. But also, it has to be like a must-watch. Like, I need to go watch this right now because it's something really good. And so that's how we came across this name.

+ +

CHAD: You mentioned earlier on that expenses are tight when you're working on something new. How worried were you about spending money on a domain name?

+ +

CHELINDE: So this is also where our partnership with Netcapital came into play because they helped us in terms of getting us off the ground. And we work with them on the business side as well. And this is one of the avenues where they helped support us.

+ +

CHAD: Oh, wow. Wow. It's great that you're able to pull together these different resources and get that support.

+ +

CHELINDE: Yeah, to us, it's been crucial because, without the support, it's very tough to get your name out there. It's very tough to promote the idea. And so, with Netcapital and the GK Fund, it definitely puts us in a better light than usual.

+ +

CHAD: Well, Che, I really wish you the best and MustWatch the best and your whole team. And good luck over the next few weeks as you open up this round on Netcapital. I ask everybody, again, go check out the app. Sometimes we talk to companies of all different stages on the show. And I especially think it's important when we have someone that's just getting started really trying to hit these user numbers that if people could go check it out, that'd be great.

+ +

CHELINDE: Really appreciate it.

+ +

CHAD: If folks want to follow along with you, get in touch with you, that kind of thing, where are all the different places where they can do that?

+ +

CHELINDE: Reach out to me on LinkedIn. I'm on LinkedIn, Che Edouard. You can reach out to us on mustwatch.com. We have a contact us email there. You can also email me at che@mustwatch.com if you want to reach out. I am available on all platforms.

+ +

CHAD: Wonderful. And you can subscribe to the show and find notes and a complete transcript for the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kZfNArsD + + ]]> + + Chad Pytel + + + 431: DEI at thoughtbot with Geronda Wollack-Spiller + https://podcast.thoughtbot.com/431 + 464267d3-5523-4b97-91ed-a0c74cea2bb9 + Thu, 14 Jul 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Geronda Wollack-Spiller is the DEI Program Manager at thoughtbot. + +Chad talks with Geronda about implementing a successful Diversity, Equity, and Inclusion program at the company by providing a culture of belonging, the challenges, in particular, the tech industry faces, and acknowledging that many of us work in spaces where when we're bringing someone onto a team who has underrepresented identities, they might be the only one. How do we create a space that's as inclusive as possible? + 37:29 + no + + + Geronda Wollack-Spiller is the DEI Program Manager at thoughtbot. +Chad talks with Geronda about implementing a successful Diversity, Equity, and Inclusion program at the company by providing a culture of belonging, the challenges, in particular, the tech industry faces, and acknowledging that many of us work in spaces where when we're bringing someone onto a team who has underrepresented identities, they might be the only one. How do we create a space that's as inclusive as possible? +Diversity, Equity, and Inclusion at thoughtbot (https://thoughtbot.com/playbook/our-company/diversity-equity-and-inclusion) +Follow Geronda on Twitter (https://twitter.com/gerondaws) or LinkedIn (https://www.linkedin.com/in/gerondawollack/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Geronda Wollack-Spiller, the DEI Program Manager at thoughtbot. Geronda, thank you so much for joining me. +GERONDA: Thank you for having me. I appreciate it. +CHAD: In honor of Pride Month, we're doing something extra special for this episode in addition to just having you as an extra special guest. We're recording live in front of thoughtbot remotely. We've got a whole bunch of people watching. I can hear them cheering off in the distance for you as you make your debut on the podcast. +GERONDA: [laughs] +CHAD: Thanks for joining me. +GERONDA: Thank you. Nice. [laughs] +CHAD: So you joined thoughtbot as our first ever DEI program manager back...when was it? +GERONDA: Oh, April, yeah, April fourth. +CHAD: It's been a whirlwind few months. Thank you already for all of the contributions that you've made to the company already. +GERONDA: Oh, thank you. No problem. +CHAD: Tell us a little bit about your role. And then I can provide some fill-in terms of what we were thinking when we added this. But let's start with sharing a little bit about your role. +GERONDA: A lot of my role is about...so it's a lot of understanding the processes that we have, people operations processes, and really thinking about how do we provide more of a...or improve our ability to provide a culture of belonging. And so a lot of what I do is I will partner across with people operations, and I'll look at things like promotions, and who are we promoting? Who are we hiring? Improvements to performance management processes. How are we giving feedback? Who are our managers? +And a lot of what I'll do, too, is execute against the goals that were set by our DEI Council before I had joined, which the council is great. And I'll look to see are there different ways that we should be looking at goals? So one of the things that I'm doing right now is I'm building out a multi-year roadmap for DEI. And I'm incorporating a lot of the goals that the council has already put together, which has been super great. And I want to create a space that feels like a safer or brave space for anyone to come to me with concerns, questions, suggestions. +And I partner a lot with different groups to be able to understand their needs and make sure that we are voicing and amplifying historically marginalized groups but also providing a lot of the education around what DEI means and how we can do that in our everyday jobs. So I am co-chair of the DEI Council. I support that council to take on different projects, build out task force, work with everyone across the company to contribute, and infuse diversity, equity, and inclusion within the company. So that's a lot of what I do. [laughs] Other things involved, but that gives you kind of a high level of my role. +CHAD: Yeah, that's great. I've talked before on the show about the DEI Council in a few different episodes, mostly in passing. And overall, when we started on...the concept of a council came from some consultants that we had worked with previously to do an audit. They provided us with a few different suggestions about how we could continue on from that audit and take action. +And one of the things, especially with our geographic studios, the way that we used to be organized the idea of one person from each of those studios coming together on a council to work together and then bring the work back to their studios for action really resonated with us as a structure that could work pretty well for us given the structure. We've obviously since gone completely remote. And the council is no longer specifically tied to those individual teams or those offices that we no longer have. +But the council is still that, a group of people from a wide array across the company who come together and focus on and organize our work around diversity, equity, and inclusion. And we saw the opportunity in your role to have someone provide continuity and organization and experience to the council to help make it even more effective at thoughtbot. And I think we're just getting started with that. But I think it's been very positive overall, your addition, and like I said at the top of the show, thank you again for your contribution so far. +GERONDA: [laughs] No problem. Thank you for hiring me. Thanks. +CHAD: [laughs] Well, speaking of hiring, you've done a few different things over the years. And I'm curious; you started in more general human resources roles. Was it a goal from the beginning of your career to move into a DEI role, or did that evolve along the way? +GERONDA: Ooh, interesting question. Yeah, it actually evolved along the way. I thought I would be an HR project manager and I would be leading projects across global companies. And when I started in my career, I was an HR operations analyst, and I was doing a lot of the HR product management. But what I discovered is every single time that I would be in a role, I kept looking at things from a DEI lens without realizing that I was. And then, as I started continuing to do that, I fell in love with it. And I was like, okay, this is my place of where I want to be. +So even though I was doing projects related to HR, if I would do recruiting operations, I would look at okay, well, who are we actually targeting, and who are we hiring? And what are the opportunities and gaps? Then I worked in the education space, and I would look at, well, how are we actually...like, what types of demographics are we bringing to the schools? So I would do things in my role that were very diversity, equity, inclusion-focused even though I was an HR product manager or in operations. +And I started realizing I really loved more of the diversity, equity, and inclusion side of things. So instead of continuing to get roles in HR, I was like, I have to get a role in DEI because that's where my passion lended itself more so. I made that decision from my last company that the next role I have, I will not take it unless it's DEI-focused. So it developed and evolved over time. +CHAD: Some people might have the thought...I have to confess sometimes I've also had this thought as like, why can't just DEI be weaved through everything HR does or through everything everybody thinks about all of the time? Why do you need a specific DEI person at a company? And I've come to understand that it's hard to do that. [laughter] But I'm curious if you have any thoughts on that. +GERONDA: It is challenging because you also have to think of it as everybody is in a different place with diversity, equity, and inclusion, which is not necessarily a bad thing. But there are some people who are incredibly passionate about it. And then there are others that are aware of it, but they may want to just kind of focus on their job. Or they might think, well, we just need to treat everybody the same. Like, why is that so hard? +So because everyone's in different places in their level of understanding and the importance of it, it does get tricky to think of things in that lens, especially in your day-to-day job. Your priorities change consistently. So you might be working on a project here. But then you're now shifting to a new team, and you're shifting to all these different places. And it does become challenging to keep it top of mind for a lot of people in the company. +And so I think that the overall almost resolution to that is the more that you start to continue to talk about it, the more that you have accountability. And you're training people like leadership and managers and everyone to be aware of what it means, and what the language is, and how you can think of these things. It takes time, but then it slowly starts to get easier. Sometimes there is an understandable fear of I don't know where to begin, and I don't know what I don't know. I don't want to make a mistake. I don't know how to look at this. And should I be looking at this? +But I think that when there is a lot of the understanding from the leadership level, and it goes down to managers, and you start to infuse it across different spaces, it does come a little bit easier. So I'll say what I like a lot of what thoughtbot does is there's a lot of open communication and transparency around things like goals, around hiring, and trainings that we maybe want to offer. So I do think it can be hard. I don't think that you can also get every single person involved in an expertise level. And you shouldn't expect anyone to be an expert, but starting to think about their job and how this could impact themselves or others, it does take some time. +CHAD: And I already alluded to this earlier, but I think we have an additional challenge which is because the majority of us are all on client work all the time and consultants, that through-line, that continuity of when we identify something, really having someone who can be that continuous force, an organization as people rotate through the council or as people's workload with client work or attention ebbs and flows. I think that that is one of the additional challenges that we have that you help with. +GERONDA: Yeah. And the rotations on the council are super helpful as well and then creating a space for anyone to come to you with questions. I like that we have this anonymous forum where you can submit a question if you're not comfortable asking it publicly, whether it's you want to learn more or something's going on that you want to talk through. I think that's also very, very helpful. +And just continuously educating and giving the space for the practical implementation of what you're trying and what you're doing will also give you a little bit more of that comfortability rather than learning about something and then hoping that you're doing it well. So it's challenging, but we'll get there, and it's worth it. [laughs] And every company has these types of challenges, so it's not unique. +CHAD: So you didn't originally start off working in the tech space. And so I'm curious what you've learned or seen that either is good or bad about the tech space in particular, what challenges this industry has. And it is Pride Month, so I guess there's a lens, particularly of LGBTQ+ challenges. Is tech particularly challenging? +GERONDA: Yeah, I think as an industry, it's particularly challenging. So I worked in education, as I mentioned. I worked in the optometry industry, which I will say has very significant challenges just for the industry itself. But tech is challenging. I think there are moves that are being made in tech. But what I'm starting to notice in terms of challenges for the LGBTQ+ community is a lot of things where there is this sometimes perception, depending on how visible you may be, that you are qualified and not qualified. +And what I mean by that is for the trans community or the transgender community, in particular, it can be very challenging because you may not what they call pass as the gender that you are looking to reassign yourself to. So if you are male, and I hear this a lot from other people, is if I'm male and I want to transition to female, I may still be going through the process. So when somebody looks at me, I might still present masculine features. And there is this misconception or this uncomfortability that I may not be qualified to do a job. +So in the tech space as well, it's really hard during the hiring process sometimes to be taken seriously because of how you might look or how you might present yourself. I will say that in a lot of spaces, the culture in a company in tech what I've noticed is it has this generally casual feeling to it and a sense of you can come in, and you'll be taken seriously. And you can meet with different groups. +But I think what I've noticed is when you're trying to get into tech, there are not a lot of people that are similar to you. And it's really hard to find those types of people because not everyone's going to be out. There are assumptions that are made that if a woman's hair is short, she must be lesbian. So we misgender people. +And when going into the tech space, I think that there's a hesitation because you don't necessarily see a customer base similar to you or other team members similar to you. There could be those things like mental health challenges because you don't know if you can come out in a space, or you don't know if you're going to come out, and that could affect your role. +So a lot of times, you'll hear and what I've been hearing in the tech space, is those who are transgender are usually the only ones on a team that are transgender. If you look at also for the LGBTQ+ community, you have to also consider the varying identities that come with a person. So an experience for a Black woman who is queer could be very different than a white male who is gay. So there are those different identities. +So the vulnerability piece, and in the hiring process, and going into tech, you already hear what's going on and the challenges that are happening for the community. So you may be hesitant or might be a little bit fearful of what that would look like. I think in the tech space as well, a lot of executive leaders or managers are predominantly cis-gendered white males. So when you see that, and there's not as much representation at the top, you kind of have that sense, and you wonder, is this a place that I feel like I can belong and have a generally safe experience? +And then the skill set, too, I think what I've been hearing, and what I've been reading and just researching, and what I've been noticing just speaking to other people is the promotion opportunity for those in the community feels like you have to work much harder to get known and be visible because a lot of times, you may want to promote people that are similar to you. So if you have teams that are more cisgendered White males, you may find that those teams are not as diverse. And the industry itself, I do feel like it is becoming more diverse. I think Lesbians Who Tech, for example, was a conference that I'm so glad that you let me attend because -- [laughter] +CHAD: I didn't let you. That's not permission, or rather I encouraged you to attend. +[laughter] +GERONDA: Better wording. Thank you, Chad. You encouraged me to attend, and you're encouraging me to attend the one in October. But just seeing in my experience and looking at the tech space, I wasn't sure what the demographic would look like. But going to that conference and then going to the one...I'm in Seattle, Washington, and there was a local one in Seattle, Washington. There were hundreds and hundreds and hundreds of gay men, lesbians, transgender, and I didn't even realize that there were so many of us in the community in that space. And it was fantastic and amazing to see. +But I think visibility is another piece that we're struggling with because you want to be able to amplify those voices and give those opportunities. So that's what I'm seeing a lot in the tech space. I do think that we're improving in those areas. But those are the challenges that I see in that space. +CHAD: To go back to one thing that you said, this idea of being the only one puts people in a difficult position. And I think because tech as an industry is not that diverse, to begin with, you end up with that in a lot of different identities, not just LGBTQ+. If you are historically underrepresented or have historically underrepresented identities, it's really likely that you're going to be the only one and especially the intersection of your identities. If you have multiple underrepresented identities, then it's very likely that you might be the only one. +Mid-Roll Ad: +Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. +Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. +Find out how we can help you move the needle at: tbot.io/entrepreneurs +CHAD: As leaders, as companies, as a community that wants to do better, let's solve it all right now, Geronda. +GERONDA: [laughs] +CHAD: No, we're not going to solve it all now. But what are some ways...like acknowledging that many of us work in spaces where we might not have...or when we're bringing someone onto the team who has underrepresented identities, they might be the only one. How do we make a space that's as inclusive as possible for that person? +GERONDA: The big thing that I always like to say is try not to put all of the work on that person to solve it for themselves. And when they come in, I think what's really great and what I've seen work well is having that initial conversation with that person who's joining, get to know them first, and give them an opportunity to say, "If there's anything that you would love to have here or anything that you find challenging, I want you to feel that you can come to me. You can go to HR or DEI program manager, whoever." +So it's providing that space to say if you need support in feeling comfortable, whether it's in your job or just you as an individual, I want to offer that. And so please be as open as you can with me. And it's providing those different spaces to amplify the voice of that person. So, in meetings, if you're noticing maybe that they are more reserved or hesitant to speak, ask for their opinion if they're okay with that. Recognizing the great work that they've done, giving a lot of that recognition, and then also offering different ways that they can get the community that they want. +So what I love is that we have Slack, and we've started ERGs. And so that gives you a lot of opportunity. We have a Slack channel for the LGBTQ+ ERG. But we also have a private channel for LGBTQ so that we can talk about things that are working, not working, working well. And definitely getting their experience and looking for ways that you can involve them and recognize them and continuing to check in with them. +So regular one-on-one checking could just be how are things going? How are you feeling being a part of this team? What are some things that we can do differently to make you feel welcome? And that's a question that you can ask everybody so that it's not feeling like you're just targeting that one person. So asking those questions and checking in with that person is really helpful. And then, considering the people that are coming in, how are things like benefits being provided? So things like if somebody who's transgender comes in or an employee decides they want to transition, are we providing gender-affirming care as part of benefits? +So those are different ways that we can have them be included and offering up the things that we provide that could potentially be a community like Slack, like the DEI Council, like having those different conversations. And when you start to do things like this, like us doing this pride event, that is pretty significant. We didn't just slap a logo on LinkedIn and just say, "Oh, okay, Happy Pride." We had lightning talks. We get education. We learned about the community. You're having me on here to talk more about it. We're doing a big celebration. +And so that in itself is a pretty critical step. But it is checking in and learning about the person and asking pretty frequently their experience, how they're feeling, their needs, and then looking to increase that diversity over time on that team so that you're not feeling tokenized as that person and always being the only. So those are things that I would suggest. +CHAD: One maybe misconception or feeling that people might have...and I think it starts in the hiring process because you're not supposed to talk about these things in the hiring process. You're not allowed, at least in the United States, to ask someone their sexual orientation during the hiring process. Or if someone was transgender and you're interviewing them, it certainly should be a topic that you as a hiring manager don't bring up during the interview. So my sense is, and speaking personally but also broadly, it can then feel like you're not supposed to talk about those things once the person joins either. Why is that wrong? +[laughter] +GERONDA: So a couple of things I'll say about that is so if somebody brings it up, that can open up the conversation. I'm very open at the fact that I have a wife and that I'm lesbian. And I purposely do that, personally, to see what the reaction is going to be and what the company is going to offer. So I can determine if I feel like this is going to be a good space for me. I think that when you're having an interview, it's just like for anyone who may not be in the community. You don't really necessarily ask someone if they're married or "Are you having children?" +You don't necessarily ask like, "Do you fall in this community?" or "Talk about transgender." Because a lot of times, there is this feeling of I have no idea what this space is going to feel like for me. I'm not going to out myself, and you may even out somebody who may not be out in their professional or their personal life yet. And you want to provide that comfortable space. But you don't want to do that either because then that person and across other interviewing spectrums bias can amplify a lot. And you can mislabel someone's gender. You might use the wrong pronouns, and pronouns are always optional. +So I always say look at the person for their experience and what you want to learn more about relating to the job. Of course, you want to learn about them a little bit more personally as well. But it is more harm to try to identify their identity because that could lead to bias and could ultimately lead to discrimination because you don't know what that person's view is in the interview process either. +CHAD: But once someone joins your team and assuming that they're open about their identities, and this applies to all identities, I think, then quote, unquote "treating everybody the same or ignoring people's identities actually does the reverse of what people intend." It makes an environment where people feel like they don't belong, that the identities that they have or what are important to them aren't recognized. And so you're not recognizing the person's full self, and you're not accommodating it and trying to build an inclusive environment. It could actually backfire if you intentionally ignore people's identities, right? +GERONDA: Yes. So it can backfire if you ignore the identities, especially the identities that have been shared openly. So if I'm going to fill out a survey, let's say where identify myself as part of our hiring process, as a manager, I may not say, "Hey, I noticed that you checked off that you're transgender. How can I support you?" But it is going through the onboarding process and other areas to say here's what we offer from ERGs to benefits, to how we work, how we work as a team. +And if that person does disclose that they're transgender, or they're in the LGBTQ+ community, or they mention their culture or what have you, you can then direct them in the right places to say, "Oh, we actually do have this LGBTQ+ ERG if you're interested. I know you may be talked about it in the onboarding process. If you're open to it, you can definitely join us, and here's how." And then, over time, it is really thinking about you may not know the identities of your team but taking time to do things in practice that would touch upon all identities. +So when you're thinking about having team conversations, there may be somebody on your team who is neurodiverse. They might have autism, or they might have ADHD. And how you're communicating...then you start to think about meetings. Do you just do Google Meet meetings? Do you just do Typeform meetings? You have to think about different learning styles and for different identities. Like it's Pride Month right now, just saying Happy Pride Month to everybody. And they may then be open to sharing more about their identity and sharing the activities that are happening in Pride Month, and encouraging them to do things on the council. +So you want to make decisions that could think about different identities, even if you may not know what those identities are. And I also think it's being proactive and being ready that you might have those identities. So things like I had mentioned where you might be providing gender-affirming care, or you might look at your parental leave policies and other things that you have available for that. +So I would say without knowing the identity, I think over time, as you build trust that [inaudible 28:24] start to develop and come out. But it's also if somebody's coming to you in confidence with something, really taking that very, very seriously. If I, God forbid, came to you, Chad, and was like, "Chad, I'm coming out to you. I am lesbian, but I'm not comfortable with sharing with everybody else." I would trust that you wouldn't share that amongst other people. So that's another piece to that as well. +CHAD: Yeah, that's a really good point. I think as people in that position, in management positions, we need proper training around those kinds of situations to ensure that we handle them well. I think training is an important part of being a manager but also just DEI in general training and equipping everybody. +GERONDA: Yes. Having a common language across the board and a common understanding across the board is very important. Because when you think of diversity, equity, and inclusion, everybody may have varying understandings of what those mean. Some people may not know what those mean, and so having that common language across the board and understanding. And then yes, training, of course, and opportunities for you to then practice that training in spaces and getting feedback along the way. +CHAD: So I imagine that there are a lot of people listening who this is really important to them. It's an important topic or a place where they want to make improvement for themselves or their company. They might not have a lot of support or resources at their company. There might not be a DEI Council already. And I know every company is different. Every team is different. But are there some things that individuals or leaders might start thinking about or doing specifically if they're just getting started with this? +GERONDA: So if you're just getting started, I always say there are a lot of great resources out there for you to consider. So whether that's a book...LinkedIn has really great training on just understanding DEI and how to be an inclusive leader or work in an inclusive environment. But I would say a really great place to start is if you don't have this already, think about what your demographic looks like. And what are some things that other companies may be doing? So joining different channels and saying, "We're at the beginning stages. What are some things that we can do?" +But I think what's most helpful to start is you have to gauge where you are as a company and understand your people and the demographic and do something that allows for an open discussion and open forum to get perspectives from other people. So I know things like listening tours where you might talk to different departments or different teams. Or if a company is small enough like our company, you can meet with each person and then think about what are some common themes that you're seeing? That can also create a great space for that. +I'd also say you can put out a survey to see what the experience is. So if you are doing things like engagement surveys, you can absolutely include things in there about what do you think we're missing? What would you hope to see? But I think a lot of it is you have to understand your people and what you have available to you at the company and provide an opportunity for everyone to share their ideas and perspectives to that. +So what I've seen work really well is one, when you start to understand there has to also be this communication and this accountability at the leadership level to say, "This is why we're focusing on this. This is why we think it's important. We want to hear from you." And something that I thought was really unique and helpful is if your company is small enough or even if it's big enough, a lot of companies what they'll do is they'll have the CEO, or they'll have managers host these kinds of forums where you can meet with them, and you can share. +You can ask them a ton of questions. You can share your ideas. You can share what you hope to achieve from this and just starting to get perspectives first. And that may, over time, start to evolve into a council or people wanting to do an ERG. But really get as much as you can from people and then learn a lot from that as well. +CHAD: That's great. I asked that question, and then it turns out it was one of the ones that someone submitted in the chat from a thoughtbot person. +GERONDA: [laughs] +CHAD: So I wanted to acknowledge that even though we overlapped the question, that question technically comes from Amy Wall, a developer at thoughtbot. Another question from Fernando is how can other employees support DEI people like you from a daily perspective? +GERONDA: Just take over my job. [laughter] No, I'm just kidding. So it's always helpful for me to have transparent conversations of where you are. If you want to help me, it's helpful to learn about your experience and come to me with things that you're seeing or ask me questions. Also, don't be afraid either to say, "I really don't know what this means or what this is. Can you help me?" +And it's also bringing learning as well because I'm not a developer, and I'm not a designer. [chuckles] I think that the work that our team does is fantastic. And they're super smart. And when I look at a lot of the things that are happening, like coding and conversations, although I have absolutely no idea what you're talking about, it's really amazing to see. But from your perspective, there may be things that I am suggesting, like, oh, maybe we need to increase accessibility, and we do need to do these things. But be okay to challenge me and say, "I actually don't know that that's going to work well or not." +But I think to support me in my role, the more that I know of the challenges, and the more that I know about you individually, and the more that you continue to bring these things up from a DEI perspective is super helpful. So what I've noticed and what I've really loved about working here is we have those opportunities to have those very open, transparent conversations. And we can post about issues, and we can post about things that we want to change in our handbook. +And sometimes people come to me with questions. And I love that people come to me and say, "This is what I want to work on more. Do you have any suggestions?" That really helps me in my role because as much as I would love to know everything that's happening with every single person, it can be challenging. So be honest with me and just share what's going on and be willing to learn and share resources with me too. Yes, I'm a DEI practitioner, but that doesn't mean I know everything. I know it's very surprising to a lot of people right now that I don't know everything. +CHAD: [laughs] +GERONDA: But share things you're reading. Share things that you've noticed. That helps me a ton. So that's how I say you can help me. And thank you for that question, Fernando. I appreciate that. +CHAD: A thing I would add is recognizing that there are, especially at thoughtbot, multiple levels of ways that you can support and contribute to our efforts. So we try to identify on the council okay, this is the thing we want to work on. The council isn't intended to do everything. But so what we'll often do is we'll say, okay, we're going to gather a group of people in a task force, and we're going to work on this. I think that's another level of contribution. +So showing up for those participating in them when they arrive, and frankly, not signing on to too much because you spread yourself too thin and then can't do a good job doing everything that you want to do. So yeah, those are some tips that I would add. Geronda, thank you so much for joining me on the show. I really appreciate it. +GERONDA: Thank you for having me. I appreciate that. +CHAD: Happy Pride. [laughs] +GERONDA: Yes. Happy Pride. I'm so excited. I feel like I'm a little biased, but this is like my favorite month of the year. [laughter] Lots of fun celebrations. And of course, I recognize other holidays, and I think they are very important. But this one is generally very close to my heart. So thank you. +CHAD: Well, if folks want to follow along with you, get in touch with you, find out more, where are all the places that they can do that? +GERONDA: Yes. Follow me on LinkedIn, Geronda Wollack-Spiller. I'm on Twitter at @gerondaws. And I think those are the two best places to follow me. I'm most active on LinkedIn. And I usually respond there pretty heavily. +CHAD: We'll include those links in the show notes, which you can find attached to this episode. And you can subscribe to the show, find all those notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Thanks for listening. And thanks to all the thoughtbot people who were in the chat, and with the questions, and paid attention and listened to this episode. And see you next time. +GERONDA: Yes. [laughs] +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Geronda Wollack-Spiller. + + + Geronda Wollack-Spiller is the DEI Program Manager at thoughtbot.

+ +

Chad talks with Geronda about implementing a successful Diversity, Equity, and Inclusion program at the company by providing a culture of belonging, the challenges, in particular, the tech industry faces, and acknowledging that many of us work in spaces where when we're bringing someone onto a team who has underrepresented identities, they might be the only one. How do we create a space that's as inclusive as possible?

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Geronda Wollack-Spiller, the DEI Program Manager at thoughtbot. Geronda, thank you so much for joining me.

+ +

GERONDA: Thank you for having me. I appreciate it.

+ +

CHAD: In honor of Pride Month, we're doing something extra special for this episode in addition to just having you as an extra special guest. We're recording live in front of thoughtbot remotely. We've got a whole bunch of people watching. I can hear them cheering off in the distance for you as you make your debut on the podcast.

+ +

GERONDA: [laughs]

+ +

CHAD: Thanks for joining me.

+ +

GERONDA: Thank you. Nice. [laughs]

+ +

CHAD: So you joined thoughtbot as our first ever DEI program manager back...when was it?

+ +

GERONDA: Oh, April, yeah, April fourth.

+ +

CHAD: It's been a whirlwind few months. Thank you already for all of the contributions that you've made to the company already.

+ +

GERONDA: Oh, thank you. No problem.

+ +

CHAD: Tell us a little bit about your role. And then I can provide some fill-in terms of what we were thinking when we added this. But let's start with sharing a little bit about your role.

+ +

GERONDA: A lot of my role is about...so it's a lot of understanding the processes that we have, people operations processes, and really thinking about how do we provide more of a...or improve our ability to provide a culture of belonging. And so a lot of what I do is I will partner across with people operations, and I'll look at things like promotions, and who are we promoting? Who are we hiring? Improvements to performance management processes. How are we giving feedback? Who are our managers?

+ +

And a lot of what I'll do, too, is execute against the goals that were set by our DEI Council before I had joined, which the council is great. And I'll look to see are there different ways that we should be looking at goals? So one of the things that I'm doing right now is I'm building out a multi-year roadmap for DEI. And I'm incorporating a lot of the goals that the council has already put together, which has been super great. And I want to create a space that feels like a safer or brave space for anyone to come to me with concerns, questions, suggestions.

+ +

And I partner a lot with different groups to be able to understand their needs and make sure that we are voicing and amplifying historically marginalized groups but also providing a lot of the education around what DEI means and how we can do that in our everyday jobs. So I am co-chair of the DEI Council. I support that council to take on different projects, build out task force, work with everyone across the company to contribute, and infuse diversity, equity, and inclusion within the company. So that's a lot of what I do. [laughs] Other things involved, but that gives you kind of a high level of my role.

+ +

CHAD: Yeah, that's great. I've talked before on the show about the DEI Council in a few different episodes, mostly in passing. And overall, when we started on...the concept of a council came from some consultants that we had worked with previously to do an audit. They provided us with a few different suggestions about how we could continue on from that audit and take action.

+ +

And one of the things, especially with our geographic studios, the way that we used to be organized the idea of one person from each of those studios coming together on a council to work together and then bring the work back to their studios for action really resonated with us as a structure that could work pretty well for us given the structure. We've obviously since gone completely remote. And the council is no longer specifically tied to those individual teams or those offices that we no longer have.

+ +

But the council is still that, a group of people from a wide array across the company who come together and focus on and organize our work around diversity, equity, and inclusion. And we saw the opportunity in your role to have someone provide continuity and organization and experience to the council to help make it even more effective at thoughtbot. And I think we're just getting started with that. But I think it's been very positive overall, your addition, and like I said at the top of the show, thank you again for your contribution so far.

+ +

GERONDA: [laughs] No problem. Thank you for hiring me. Thanks.

+ +

CHAD: [laughs] Well, speaking of hiring, you've done a few different things over the years. And I'm curious; you started in more general human resources roles. Was it a goal from the beginning of your career to move into a DEI role, or did that evolve along the way?

+ +

GERONDA: Ooh, interesting question. Yeah, it actually evolved along the way. I thought I would be an HR project manager and I would be leading projects across global companies. And when I started in my career, I was an HR operations analyst, and I was doing a lot of the HR product management. But what I discovered is every single time that I would be in a role, I kept looking at things from a DEI lens without realizing that I was. And then, as I started continuing to do that, I fell in love with it. And I was like, okay, this is my place of where I want to be.

+ +

So even though I was doing projects related to HR, if I would do recruiting operations, I would look at okay, well, who are we actually targeting, and who are we hiring? And what are the opportunities and gaps? Then I worked in the education space, and I would look at, well, how are we actually...like, what types of demographics are we bringing to the schools? So I would do things in my role that were very diversity, equity, inclusion-focused even though I was an HR product manager or in operations.

+ +

And I started realizing I really loved more of the diversity, equity, and inclusion side of things. So instead of continuing to get roles in HR, I was like, I have to get a role in DEI because that's where my passion lended itself more so. I made that decision from my last company that the next role I have, I will not take it unless it's DEI-focused. So it developed and evolved over time.

+ +

CHAD: Some people might have the thought...I have to confess sometimes I've also had this thought as like, why can't just DEI be weaved through everything HR does or through everything everybody thinks about all of the time? Why do you need a specific DEI person at a company? And I've come to understand that it's hard to do that. [laughter] But I'm curious if you have any thoughts on that.

+ +

GERONDA: It is challenging because you also have to think of it as everybody is in a different place with diversity, equity, and inclusion, which is not necessarily a bad thing. But there are some people who are incredibly passionate about it. And then there are others that are aware of it, but they may want to just kind of focus on their job. Or they might think, well, we just need to treat everybody the same. Like, why is that so hard?

+ +

So because everyone's in different places in their level of understanding and the importance of it, it does get tricky to think of things in that lens, especially in your day-to-day job. Your priorities change consistently. So you might be working on a project here. But then you're now shifting to a new team, and you're shifting to all these different places. And it does become challenging to keep it top of mind for a lot of people in the company.

+ +

And so I think that the overall almost resolution to that is the more that you start to continue to talk about it, the more that you have accountability. And you're training people like leadership and managers and everyone to be aware of what it means, and what the language is, and how you can think of these things. It takes time, but then it slowly starts to get easier. Sometimes there is an understandable fear of I don't know where to begin, and I don't know what I don't know. I don't want to make a mistake. I don't know how to look at this. And should I be looking at this?

+ +

But I think that when there is a lot of the understanding from the leadership level, and it goes down to managers, and you start to infuse it across different spaces, it does come a little bit easier. So I'll say what I like a lot of what thoughtbot does is there's a lot of open communication and transparency around things like goals, around hiring, and trainings that we maybe want to offer. So I do think it can be hard. I don't think that you can also get every single person involved in an expertise level. And you shouldn't expect anyone to be an expert, but starting to think about their job and how this could impact themselves or others, it does take some time.

+ +

CHAD: And I already alluded to this earlier, but I think we have an additional challenge which is because the majority of us are all on client work all the time and consultants, that through-line, that continuity of when we identify something, really having someone who can be that continuous force, an organization as people rotate through the council or as people's workload with client work or attention ebbs and flows. I think that that is one of the additional challenges that we have that you help with.

+ +

GERONDA: Yeah. And the rotations on the council are super helpful as well and then creating a space for anyone to come to you with questions. I like that we have this anonymous forum where you can submit a question if you're not comfortable asking it publicly, whether it's you want to learn more or something's going on that you want to talk through. I think that's also very, very helpful.

+ +

And just continuously educating and giving the space for the practical implementation of what you're trying and what you're doing will also give you a little bit more of that comfortability rather than learning about something and then hoping that you're doing it well. So it's challenging, but we'll get there, and it's worth it. [laughs] And every company has these types of challenges, so it's not unique.

+ +

CHAD: So you didn't originally start off working in the tech space. And so I'm curious what you've learned or seen that either is good or bad about the tech space in particular, what challenges this industry has. And it is Pride Month, so I guess there's a lens, particularly of LGBTQ+ challenges. Is tech particularly challenging?

+ +

GERONDA: Yeah, I think as an industry, it's particularly challenging. So I worked in education, as I mentioned. I worked in the optometry industry, which I will say has very significant challenges just for the industry itself. But tech is challenging. I think there are moves that are being made in tech. But what I'm starting to notice in terms of challenges for the LGBTQ+ community is a lot of things where there is this sometimes perception, depending on how visible you may be, that you are qualified and not qualified.

+ +

And what I mean by that is for the trans community or the transgender community, in particular, it can be very challenging because you may not what they call pass as the gender that you are looking to reassign yourself to. So if you are male, and I hear this a lot from other people, is if I'm male and I want to transition to female, I may still be going through the process. So when somebody looks at me, I might still present masculine features. And there is this misconception or this uncomfortability that I may not be qualified to do a job.

+ +

So in the tech space as well, it's really hard during the hiring process sometimes to be taken seriously because of how you might look or how you might present yourself. I will say that in a lot of spaces, the culture in a company in tech what I've noticed is it has this generally casual feeling to it and a sense of you can come in, and you'll be taken seriously. And you can meet with different groups.

+ +

But I think what I've noticed is when you're trying to get into tech, there are not a lot of people that are similar to you. And it's really hard to find those types of people because not everyone's going to be out. There are assumptions that are made that if a woman's hair is short, she must be lesbian. So we misgender people.

+ +

And when going into the tech space, I think that there's a hesitation because you don't necessarily see a customer base similar to you or other team members similar to you. There could be those things like mental health challenges because you don't know if you can come out in a space, or you don't know if you're going to come out, and that could affect your role.

+ +

So a lot of times, you'll hear and what I've been hearing in the tech space, is those who are transgender are usually the only ones on a team that are transgender. If you look at also for the LGBTQ+ community, you have to also consider the varying identities that come with a person. So an experience for a Black woman who is queer could be very different than a white male who is gay. So there are those different identities.

+ +

So the vulnerability piece, and in the hiring process, and going into tech, you already hear what's going on and the challenges that are happening for the community. So you may be hesitant or might be a little bit fearful of what that would look like. I think in the tech space as well, a lot of executive leaders or managers are predominantly cis-gendered white males. So when you see that, and there's not as much representation at the top, you kind of have that sense, and you wonder, is this a place that I feel like I can belong and have a generally safe experience?

+ +

And then the skill set, too, I think what I've been hearing, and what I've been reading and just researching, and what I've been noticing just speaking to other people is the promotion opportunity for those in the community feels like you have to work much harder to get known and be visible because a lot of times, you may want to promote people that are similar to you. So if you have teams that are more cisgendered White males, you may find that those teams are not as diverse. And the industry itself, I do feel like it is becoming more diverse. I think Lesbians Who Tech, for example, was a conference that I'm so glad that you let me attend because -- [laughter]

+ +

CHAD: I didn't let you. That's not permission, or rather I encouraged you to attend.

+ +

[laughter]

+ +

GERONDA: Better wording. Thank you, Chad. You encouraged me to attend, and you're encouraging me to attend the one in October. But just seeing in my experience and looking at the tech space, I wasn't sure what the demographic would look like. But going to that conference and then going to the one...I'm in Seattle, Washington, and there was a local one in Seattle, Washington. There were hundreds and hundreds and hundreds of gay men, lesbians, transgender, and I didn't even realize that there were so many of us in the community in that space. And it was fantastic and amazing to see.

+ +

But I think visibility is another piece that we're struggling with because you want to be able to amplify those voices and give those opportunities. So that's what I'm seeing a lot in the tech space. I do think that we're improving in those areas. But those are the challenges that I see in that space.

+ +

CHAD: To go back to one thing that you said, this idea of being the only one puts people in a difficult position. And I think because tech as an industry is not that diverse, to begin with, you end up with that in a lot of different identities, not just LGBTQ+. If you are historically underrepresented or have historically underrepresented identities, it's really likely that you're going to be the only one and especially the intersection of your identities. If you have multiple underrepresented identities, then it's very likely that you might be the only one.

+ +

Mid-Roll Ad:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs

+ +

CHAD: As leaders, as companies, as a community that wants to do better, let's solve it all right now, Geronda.

+ +

GERONDA: [laughs]

+ +

CHAD: No, we're not going to solve it all now. But what are some ways...like acknowledging that many of us work in spaces where we might not have...or when we're bringing someone onto the team who has underrepresented identities, they might be the only one. How do we make a space that's as inclusive as possible for that person?

+ +

GERONDA: The big thing that I always like to say is try not to put all of the work on that person to solve it for themselves. And when they come in, I think what's really great and what I've seen work well is having that initial conversation with that person who's joining, get to know them first, and give them an opportunity to say, "If there's anything that you would love to have here or anything that you find challenging, I want you to feel that you can come to me. You can go to HR or DEI program manager, whoever."

+ +

So it's providing that space to say if you need support in feeling comfortable, whether it's in your job or just you as an individual, I want to offer that. And so please be as open as you can with me. And it's providing those different spaces to amplify the voice of that person. So, in meetings, if you're noticing maybe that they are more reserved or hesitant to speak, ask for their opinion if they're okay with that. Recognizing the great work that they've done, giving a lot of that recognition, and then also offering different ways that they can get the community that they want.

+ +

So what I love is that we have Slack, and we've started ERGs. And so that gives you a lot of opportunity. We have a Slack channel for the LGBTQ+ ERG. But we also have a private channel for LGBTQ so that we can talk about things that are working, not working, working well. And definitely getting their experience and looking for ways that you can involve them and recognize them and continuing to check in with them.

+ +

So regular one-on-one checking could just be how are things going? How are you feeling being a part of this team? What are some things that we can do differently to make you feel welcome? And that's a question that you can ask everybody so that it's not feeling like you're just targeting that one person. So asking those questions and checking in with that person is really helpful. And then, considering the people that are coming in, how are things like benefits being provided? So things like if somebody who's transgender comes in or an employee decides they want to transition, are we providing gender-affirming care as part of benefits?

+ +

So those are different ways that we can have them be included and offering up the things that we provide that could potentially be a community like Slack, like the DEI Council, like having those different conversations. And when you start to do things like this, like us doing this pride event, that is pretty significant. We didn't just slap a logo on LinkedIn and just say, "Oh, okay, Happy Pride." We had lightning talks. We get education. We learned about the community. You're having me on here to talk more about it. We're doing a big celebration.

+ +

And so that in itself is a pretty critical step. But it is checking in and learning about the person and asking pretty frequently their experience, how they're feeling, their needs, and then looking to increase that diversity over time on that team so that you're not feeling tokenized as that person and always being the only. So those are things that I would suggest.

+ +

CHAD: One maybe misconception or feeling that people might have...and I think it starts in the hiring process because you're not supposed to talk about these things in the hiring process. You're not allowed, at least in the United States, to ask someone their sexual orientation during the hiring process. Or if someone was transgender and you're interviewing them, it certainly should be a topic that you as a hiring manager don't bring up during the interview. So my sense is, and speaking personally but also broadly, it can then feel like you're not supposed to talk about those things once the person joins either. Why is that wrong?

+ +

[laughter]

+ +

GERONDA: So a couple of things I'll say about that is so if somebody brings it up, that can open up the conversation. I'm very open at the fact that I have a wife and that I'm lesbian. And I purposely do that, personally, to see what the reaction is going to be and what the company is going to offer. So I can determine if I feel like this is going to be a good space for me. I think that when you're having an interview, it's just like for anyone who may not be in the community. You don't really necessarily ask someone if they're married or "Are you having children?"

+ +

You don't necessarily ask like, "Do you fall in this community?" or "Talk about transgender." Because a lot of times, there is this feeling of I have no idea what this space is going to feel like for me. I'm not going to out myself, and you may even out somebody who may not be out in their professional or their personal life yet. And you want to provide that comfortable space. But you don't want to do that either because then that person and across other interviewing spectrums bias can amplify a lot. And you can mislabel someone's gender. You might use the wrong pronouns, and pronouns are always optional.

+ +

So I always say look at the person for their experience and what you want to learn more about relating to the job. Of course, you want to learn about them a little bit more personally as well. But it is more harm to try to identify their identity because that could lead to bias and could ultimately lead to discrimination because you don't know what that person's view is in the interview process either.

+ +

CHAD: But once someone joins your team and assuming that they're open about their identities, and this applies to all identities, I think, then quote, unquote "treating everybody the same or ignoring people's identities actually does the reverse of what people intend." It makes an environment where people feel like they don't belong, that the identities that they have or what are important to them aren't recognized. And so you're not recognizing the person's full self, and you're not accommodating it and trying to build an inclusive environment. It could actually backfire if you intentionally ignore people's identities, right?

+ +

GERONDA: Yes. So it can backfire if you ignore the identities, especially the identities that have been shared openly. So if I'm going to fill out a survey, let's say where identify myself as part of our hiring process, as a manager, I may not say, "Hey, I noticed that you checked off that you're transgender. How can I support you?" But it is going through the onboarding process and other areas to say here's what we offer from ERGs to benefits, to how we work, how we work as a team.

+ +

And if that person does disclose that they're transgender, or they're in the LGBTQ+ community, or they mention their culture or what have you, you can then direct them in the right places to say, "Oh, we actually do have this LGBTQ+ ERG if you're interested. I know you may be talked about it in the onboarding process. If you're open to it, you can definitely join us, and here's how." And then, over time, it is really thinking about you may not know the identities of your team but taking time to do things in practice that would touch upon all identities.

+ +

So when you're thinking about having team conversations, there may be somebody on your team who is neurodiverse. They might have autism, or they might have ADHD. And how you're communicating...then you start to think about meetings. Do you just do Google Meet meetings? Do you just do Typeform meetings? You have to think about different learning styles and for different identities. Like it's Pride Month right now, just saying Happy Pride Month to everybody. And they may then be open to sharing more about their identity and sharing the activities that are happening in Pride Month, and encouraging them to do things on the council.

+ +

So you want to make decisions that could think about different identities, even if you may not know what those identities are. And I also think it's being proactive and being ready that you might have those identities. So things like I had mentioned where you might be providing gender-affirming care, or you might look at your parental leave policies and other things that you have available for that.

+ +

So I would say without knowing the identity, I think over time, as you build trust that [inaudible 28:24] start to develop and come out. But it's also if somebody's coming to you in confidence with something, really taking that very, very seriously. If I, God forbid, came to you, Chad, and was like, "Chad, I'm coming out to you. I am lesbian, but I'm not comfortable with sharing with everybody else." I would trust that you wouldn't share that amongst other people. So that's another piece to that as well.

+ +

CHAD: Yeah, that's a really good point. I think as people in that position, in management positions, we need proper training around those kinds of situations to ensure that we handle them well. I think training is an important part of being a manager but also just DEI in general training and equipping everybody.

+ +

GERONDA: Yes. Having a common language across the board and a common understanding across the board is very important. Because when you think of diversity, equity, and inclusion, everybody may have varying understandings of what those mean. Some people may not know what those mean, and so having that common language across the board and understanding. And then yes, training, of course, and opportunities for you to then practice that training in spaces and getting feedback along the way.

+ +

CHAD: So I imagine that there are a lot of people listening who this is really important to them. It's an important topic or a place where they want to make improvement for themselves or their company. They might not have a lot of support or resources at their company. There might not be a DEI Council already. And I know every company is different. Every team is different. But are there some things that individuals or leaders might start thinking about or doing specifically if they're just getting started with this?

+ +

GERONDA: So if you're just getting started, I always say there are a lot of great resources out there for you to consider. So whether that's a book...LinkedIn has really great training on just understanding DEI and how to be an inclusive leader or work in an inclusive environment. But I would say a really great place to start is if you don't have this already, think about what your demographic looks like. And what are some things that other companies may be doing? So joining different channels and saying, "We're at the beginning stages. What are some things that we can do?"

+ +

But I think what's most helpful to start is you have to gauge where you are as a company and understand your people and the demographic and do something that allows for an open discussion and open forum to get perspectives from other people. So I know things like listening tours where you might talk to different departments or different teams. Or if a company is small enough like our company, you can meet with each person and then think about what are some common themes that you're seeing? That can also create a great space for that.

+ +

I'd also say you can put out a survey to see what the experience is. So if you are doing things like engagement surveys, you can absolutely include things in there about what do you think we're missing? What would you hope to see? But I think a lot of it is you have to understand your people and what you have available to you at the company and provide an opportunity for everyone to share their ideas and perspectives to that.

+ +

So what I've seen work really well is one, when you start to understand there has to also be this communication and this accountability at the leadership level to say, "This is why we're focusing on this. This is why we think it's important. We want to hear from you." And something that I thought was really unique and helpful is if your company is small enough or even if it's big enough, a lot of companies what they'll do is they'll have the CEO, or they'll have managers host these kinds of forums where you can meet with them, and you can share.

+ +

You can ask them a ton of questions. You can share your ideas. You can share what you hope to achieve from this and just starting to get perspectives first. And that may, over time, start to evolve into a council or people wanting to do an ERG. But really get as much as you can from people and then learn a lot from that as well.

+ +

CHAD: That's great. I asked that question, and then it turns out it was one of the ones that someone submitted in the chat from a thoughtbot person.

+ +

GERONDA: [laughs]

+ +

CHAD: So I wanted to acknowledge that even though we overlapped the question, that question technically comes from Amy Wall, a developer at thoughtbot. Another question from Fernando is how can other employees support DEI people like you from a daily perspective?

+ +

GERONDA: Just take over my job. [laughter] No, I'm just kidding. So it's always helpful for me to have transparent conversations of where you are. If you want to help me, it's helpful to learn about your experience and come to me with things that you're seeing or ask me questions. Also, don't be afraid either to say, "I really don't know what this means or what this is. Can you help me?"

+ +

And it's also bringing learning as well because I'm not a developer, and I'm not a designer. [chuckles] I think that the work that our team does is fantastic. And they're super smart. And when I look at a lot of the things that are happening, like coding and conversations, although I have absolutely no idea what you're talking about, it's really amazing to see. But from your perspective, there may be things that I am suggesting, like, oh, maybe we need to increase accessibility, and we do need to do these things. But be okay to challenge me and say, "I actually don't know that that's going to work well or not."

+ +

But I think to support me in my role, the more that I know of the challenges, and the more that I know about you individually, and the more that you continue to bring these things up from a DEI perspective is super helpful. So what I've noticed and what I've really loved about working here is we have those opportunities to have those very open, transparent conversations. And we can post about issues, and we can post about things that we want to change in our handbook.

+ +

And sometimes people come to me with questions. And I love that people come to me and say, "This is what I want to work on more. Do you have any suggestions?" That really helps me in my role because as much as I would love to know everything that's happening with every single person, it can be challenging. So be honest with me and just share what's going on and be willing to learn and share resources with me too. Yes, I'm a DEI practitioner, but that doesn't mean I know everything. I know it's very surprising to a lot of people right now that I don't know everything.

+ +

CHAD: [laughs]

+ +

GERONDA: But share things you're reading. Share things that you've noticed. That helps me a ton. So that's how I say you can help me. And thank you for that question, Fernando. I appreciate that.

+ +

CHAD: A thing I would add is recognizing that there are, especially at thoughtbot, multiple levels of ways that you can support and contribute to our efforts. So we try to identify on the council okay, this is the thing we want to work on. The council isn't intended to do everything. But so what we'll often do is we'll say, okay, we're going to gather a group of people in a task force, and we're going to work on this. I think that's another level of contribution.

+ +

So showing up for those participating in them when they arrive, and frankly, not signing on to too much because you spread yourself too thin and then can't do a good job doing everything that you want to do. So yeah, those are some tips that I would add. Geronda, thank you so much for joining me on the show. I really appreciate it.

+ +

GERONDA: Thank you for having me. I appreciate that.

+ +

CHAD: Happy Pride. [laughs]

+ +

GERONDA: Yes. Happy Pride. I'm so excited. I feel like I'm a little biased, but this is like my favorite month of the year. [laughter] Lots of fun celebrations. And of course, I recognize other holidays, and I think they are very important. But this one is generally very close to my heart. So thank you.

+ +

CHAD: Well, if folks want to follow along with you, get in touch with you, find out more, where are all the places that they can do that?

+ +

GERONDA: Yes. Follow me on LinkedIn, Geronda Wollack-Spiller. I'm on Twitter at @gerondaws. And I think those are the two best places to follow me. I'm most active on LinkedIn. And I usually respond there pretty heavily.

+ +

CHAD: We'll include those links in the show notes, which you can find attached to this episode. And you can subscribe to the show, find all those notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. And thanks to all the thoughtbot people who were in the chat, and with the questions, and paid attention and listened to this episode. And see you next time.

+ +

GERONDA: Yes. [laughs]

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Geronda Wollack-Spiller.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Geronda Wollack-Spiller is the DEI Program Manager at thoughtbot.

+ +

Chad talks with Geronda about implementing a successful Diversity, Equity, and Inclusion program at the company by providing a culture of belonging, the challenges, in particular, the tech industry faces, and acknowledging that many of us work in spaces where when we're bringing someone onto a team who has underrepresented identities, they might be the only one. How do we create a space that's as inclusive as possible?

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Geronda Wollack-Spiller, the DEI Program Manager at thoughtbot. Geronda, thank you so much for joining me.

+ +

GERONDA: Thank you for having me. I appreciate it.

+ +

CHAD: In honor of Pride Month, we're doing something extra special for this episode in addition to just having you as an extra special guest. We're recording live in front of thoughtbot remotely. We've got a whole bunch of people watching. I can hear them cheering off in the distance for you as you make your debut on the podcast.

+ +

GERONDA: [laughs]

+ +

CHAD: Thanks for joining me.

+ +

GERONDA: Thank you. Nice. [laughs]

+ +

CHAD: So you joined thoughtbot as our first ever DEI program manager back...when was it?

+ +

GERONDA: Oh, April, yeah, April fourth.

+ +

CHAD: It's been a whirlwind few months. Thank you already for all of the contributions that you've made to the company already.

+ +

GERONDA: Oh, thank you. No problem.

+ +

CHAD: Tell us a little bit about your role. And then I can provide some fill-in terms of what we were thinking when we added this. But let's start with sharing a little bit about your role.

+ +

GERONDA: A lot of my role is about...so it's a lot of understanding the processes that we have, people operations processes, and really thinking about how do we provide more of a...or improve our ability to provide a culture of belonging. And so a lot of what I do is I will partner across with people operations, and I'll look at things like promotions, and who are we promoting? Who are we hiring? Improvements to performance management processes. How are we giving feedback? Who are our managers?

+ +

And a lot of what I'll do, too, is execute against the goals that were set by our DEI Council before I had joined, which the council is great. And I'll look to see are there different ways that we should be looking at goals? So one of the things that I'm doing right now is I'm building out a multi-year roadmap for DEI. And I'm incorporating a lot of the goals that the council has already put together, which has been super great. And I want to create a space that feels like a safer or brave space for anyone to come to me with concerns, questions, suggestions.

+ +

And I partner a lot with different groups to be able to understand their needs and make sure that we are voicing and amplifying historically marginalized groups but also providing a lot of the education around what DEI means and how we can do that in our everyday jobs. So I am co-chair of the DEI Council. I support that council to take on different projects, build out task force, work with everyone across the company to contribute, and infuse diversity, equity, and inclusion within the company. So that's a lot of what I do. [laughs] Other things involved, but that gives you kind of a high level of my role.

+ +

CHAD: Yeah, that's great. I've talked before on the show about the DEI Council in a few different episodes, mostly in passing. And overall, when we started on...the concept of a council came from some consultants that we had worked with previously to do an audit. They provided us with a few different suggestions about how we could continue on from that audit and take action.

+ +

And one of the things, especially with our geographic studios, the way that we used to be organized the idea of one person from each of those studios coming together on a council to work together and then bring the work back to their studios for action really resonated with us as a structure that could work pretty well for us given the structure. We've obviously since gone completely remote. And the council is no longer specifically tied to those individual teams or those offices that we no longer have.

+ +

But the council is still that, a group of people from a wide array across the company who come together and focus on and organize our work around diversity, equity, and inclusion. And we saw the opportunity in your role to have someone provide continuity and organization and experience to the council to help make it even more effective at thoughtbot. And I think we're just getting started with that. But I think it's been very positive overall, your addition, and like I said at the top of the show, thank you again for your contribution so far.

+ +

GERONDA: [laughs] No problem. Thank you for hiring me. Thanks.

+ +

CHAD: [laughs] Well, speaking of hiring, you've done a few different things over the years. And I'm curious; you started in more general human resources roles. Was it a goal from the beginning of your career to move into a DEI role, or did that evolve along the way?

+ +

GERONDA: Ooh, interesting question. Yeah, it actually evolved along the way. I thought I would be an HR project manager and I would be leading projects across global companies. And when I started in my career, I was an HR operations analyst, and I was doing a lot of the HR product management. But what I discovered is every single time that I would be in a role, I kept looking at things from a DEI lens without realizing that I was. And then, as I started continuing to do that, I fell in love with it. And I was like, okay, this is my place of where I want to be.

+ +

So even though I was doing projects related to HR, if I would do recruiting operations, I would look at okay, well, who are we actually targeting, and who are we hiring? And what are the opportunities and gaps? Then I worked in the education space, and I would look at, well, how are we actually...like, what types of demographics are we bringing to the schools? So I would do things in my role that were very diversity, equity, inclusion-focused even though I was an HR product manager or in operations.

+ +

And I started realizing I really loved more of the diversity, equity, and inclusion side of things. So instead of continuing to get roles in HR, I was like, I have to get a role in DEI because that's where my passion lended itself more so. I made that decision from my last company that the next role I have, I will not take it unless it's DEI-focused. So it developed and evolved over time.

+ +

CHAD: Some people might have the thought...I have to confess sometimes I've also had this thought as like, why can't just DEI be weaved through everything HR does or through everything everybody thinks about all of the time? Why do you need a specific DEI person at a company? And I've come to understand that it's hard to do that. [laughter] But I'm curious if you have any thoughts on that.

+ +

GERONDA: It is challenging because you also have to think of it as everybody is in a different place with diversity, equity, and inclusion, which is not necessarily a bad thing. But there are some people who are incredibly passionate about it. And then there are others that are aware of it, but they may want to just kind of focus on their job. Or they might think, well, we just need to treat everybody the same. Like, why is that so hard?

+ +

So because everyone's in different places in their level of understanding and the importance of it, it does get tricky to think of things in that lens, especially in your day-to-day job. Your priorities change consistently. So you might be working on a project here. But then you're now shifting to a new team, and you're shifting to all these different places. And it does become challenging to keep it top of mind for a lot of people in the company.

+ +

And so I think that the overall almost resolution to that is the more that you start to continue to talk about it, the more that you have accountability. And you're training people like leadership and managers and everyone to be aware of what it means, and what the language is, and how you can think of these things. It takes time, but then it slowly starts to get easier. Sometimes there is an understandable fear of I don't know where to begin, and I don't know what I don't know. I don't want to make a mistake. I don't know how to look at this. And should I be looking at this?

+ +

But I think that when there is a lot of the understanding from the leadership level, and it goes down to managers, and you start to infuse it across different spaces, it does come a little bit easier. So I'll say what I like a lot of what thoughtbot does is there's a lot of open communication and transparency around things like goals, around hiring, and trainings that we maybe want to offer. So I do think it can be hard. I don't think that you can also get every single person involved in an expertise level. And you shouldn't expect anyone to be an expert, but starting to think about their job and how this could impact themselves or others, it does take some time.

+ +

CHAD: And I already alluded to this earlier, but I think we have an additional challenge which is because the majority of us are all on client work all the time and consultants, that through-line, that continuity of when we identify something, really having someone who can be that continuous force, an organization as people rotate through the council or as people's workload with client work or attention ebbs and flows. I think that that is one of the additional challenges that we have that you help with.

+ +

GERONDA: Yeah. And the rotations on the council are super helpful as well and then creating a space for anyone to come to you with questions. I like that we have this anonymous forum where you can submit a question if you're not comfortable asking it publicly, whether it's you want to learn more or something's going on that you want to talk through. I think that's also very, very helpful.

+ +

And just continuously educating and giving the space for the practical implementation of what you're trying and what you're doing will also give you a little bit more of that comfortability rather than learning about something and then hoping that you're doing it well. So it's challenging, but we'll get there, and it's worth it. [laughs] And every company has these types of challenges, so it's not unique.

+ +

CHAD: So you didn't originally start off working in the tech space. And so I'm curious what you've learned or seen that either is good or bad about the tech space in particular, what challenges this industry has. And it is Pride Month, so I guess there's a lens, particularly of LGBTQ+ challenges. Is tech particularly challenging?

+ +

GERONDA: Yeah, I think as an industry, it's particularly challenging. So I worked in education, as I mentioned. I worked in the optometry industry, which I will say has very significant challenges just for the industry itself. But tech is challenging. I think there are moves that are being made in tech. But what I'm starting to notice in terms of challenges for the LGBTQ+ community is a lot of things where there is this sometimes perception, depending on how visible you may be, that you are qualified and not qualified.

+ +

And what I mean by that is for the trans community or the transgender community, in particular, it can be very challenging because you may not what they call pass as the gender that you are looking to reassign yourself to. So if you are male, and I hear this a lot from other people, is if I'm male and I want to transition to female, I may still be going through the process. So when somebody looks at me, I might still present masculine features. And there is this misconception or this uncomfortability that I may not be qualified to do a job.

+ +

So in the tech space as well, it's really hard during the hiring process sometimes to be taken seriously because of how you might look or how you might present yourself. I will say that in a lot of spaces, the culture in a company in tech what I've noticed is it has this generally casual feeling to it and a sense of you can come in, and you'll be taken seriously. And you can meet with different groups.

+ +

But I think what I've noticed is when you're trying to get into tech, there are not a lot of people that are similar to you. And it's really hard to find those types of people because not everyone's going to be out. There are assumptions that are made that if a woman's hair is short, she must be lesbian. So we misgender people.

+ +

And when going into the tech space, I think that there's a hesitation because you don't necessarily see a customer base similar to you or other team members similar to you. There could be those things like mental health challenges because you don't know if you can come out in a space, or you don't know if you're going to come out, and that could affect your role.

+ +

So a lot of times, you'll hear and what I've been hearing in the tech space, is those who are transgender are usually the only ones on a team that are transgender. If you look at also for the LGBTQ+ community, you have to also consider the varying identities that come with a person. So an experience for a Black woman who is queer could be very different than a white male who is gay. So there are those different identities.

+ +

So the vulnerability piece, and in the hiring process, and going into tech, you already hear what's going on and the challenges that are happening for the community. So you may be hesitant or might be a little bit fearful of what that would look like. I think in the tech space as well, a lot of executive leaders or managers are predominantly cis-gendered white males. So when you see that, and there's not as much representation at the top, you kind of have that sense, and you wonder, is this a place that I feel like I can belong and have a generally safe experience?

+ +

And then the skill set, too, I think what I've been hearing, and what I've been reading and just researching, and what I've been noticing just speaking to other people is the promotion opportunity for those in the community feels like you have to work much harder to get known and be visible because a lot of times, you may want to promote people that are similar to you. So if you have teams that are more cisgendered White males, you may find that those teams are not as diverse. And the industry itself, I do feel like it is becoming more diverse. I think Lesbians Who Tech, for example, was a conference that I'm so glad that you let me attend because -- [laughter]

+ +

CHAD: I didn't let you. That's not permission, or rather I encouraged you to attend.

+ +

[laughter]

+ +

GERONDA: Better wording. Thank you, Chad. You encouraged me to attend, and you're encouraging me to attend the one in October. But just seeing in my experience and looking at the tech space, I wasn't sure what the demographic would look like. But going to that conference and then going to the one...I'm in Seattle, Washington, and there was a local one in Seattle, Washington. There were hundreds and hundreds and hundreds of gay men, lesbians, transgender, and I didn't even realize that there were so many of us in the community in that space. And it was fantastic and amazing to see.

+ +

But I think visibility is another piece that we're struggling with because you want to be able to amplify those voices and give those opportunities. So that's what I'm seeing a lot in the tech space. I do think that we're improving in those areas. But those are the challenges that I see in that space.

+ +

CHAD: To go back to one thing that you said, this idea of being the only one puts people in a difficult position. And I think because tech as an industry is not that diverse, to begin with, you end up with that in a lot of different identities, not just LGBTQ+. If you are historically underrepresented or have historically underrepresented identities, it's really likely that you're going to be the only one and especially the intersection of your identities. If you have multiple underrepresented identities, then it's very likely that you might be the only one.

+ +

Mid-Roll Ad:

+ +

Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps.

+ +

Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success.

+ +

Find out how we can help you move the needle at: tbot.io/entrepreneurs

+ +

CHAD: As leaders, as companies, as a community that wants to do better, let's solve it all right now, Geronda.

+ +

GERONDA: [laughs]

+ +

CHAD: No, we're not going to solve it all now. But what are some ways...like acknowledging that many of us work in spaces where we might not have...or when we're bringing someone onto the team who has underrepresented identities, they might be the only one. How do we make a space that's as inclusive as possible for that person?

+ +

GERONDA: The big thing that I always like to say is try not to put all of the work on that person to solve it for themselves. And when they come in, I think what's really great and what I've seen work well is having that initial conversation with that person who's joining, get to know them first, and give them an opportunity to say, "If there's anything that you would love to have here or anything that you find challenging, I want you to feel that you can come to me. You can go to HR or DEI program manager, whoever."

+ +

So it's providing that space to say if you need support in feeling comfortable, whether it's in your job or just you as an individual, I want to offer that. And so please be as open as you can with me. And it's providing those different spaces to amplify the voice of that person. So, in meetings, if you're noticing maybe that they are more reserved or hesitant to speak, ask for their opinion if they're okay with that. Recognizing the great work that they've done, giving a lot of that recognition, and then also offering different ways that they can get the community that they want.

+ +

So what I love is that we have Slack, and we've started ERGs. And so that gives you a lot of opportunity. We have a Slack channel for the LGBTQ+ ERG. But we also have a private channel for LGBTQ so that we can talk about things that are working, not working, working well. And definitely getting their experience and looking for ways that you can involve them and recognize them and continuing to check in with them.

+ +

So regular one-on-one checking could just be how are things going? How are you feeling being a part of this team? What are some things that we can do differently to make you feel welcome? And that's a question that you can ask everybody so that it's not feeling like you're just targeting that one person. So asking those questions and checking in with that person is really helpful. And then, considering the people that are coming in, how are things like benefits being provided? So things like if somebody who's transgender comes in or an employee decides they want to transition, are we providing gender-affirming care as part of benefits?

+ +

So those are different ways that we can have them be included and offering up the things that we provide that could potentially be a community like Slack, like the DEI Council, like having those different conversations. And when you start to do things like this, like us doing this pride event, that is pretty significant. We didn't just slap a logo on LinkedIn and just say, "Oh, okay, Happy Pride." We had lightning talks. We get education. We learned about the community. You're having me on here to talk more about it. We're doing a big celebration.

+ +

And so that in itself is a pretty critical step. But it is checking in and learning about the person and asking pretty frequently their experience, how they're feeling, their needs, and then looking to increase that diversity over time on that team so that you're not feeling tokenized as that person and always being the only. So those are things that I would suggest.

+ +

CHAD: One maybe misconception or feeling that people might have...and I think it starts in the hiring process because you're not supposed to talk about these things in the hiring process. You're not allowed, at least in the United States, to ask someone their sexual orientation during the hiring process. Or if someone was transgender and you're interviewing them, it certainly should be a topic that you as a hiring manager don't bring up during the interview. So my sense is, and speaking personally but also broadly, it can then feel like you're not supposed to talk about those things once the person joins either. Why is that wrong?

+ +

[laughter]

+ +

GERONDA: So a couple of things I'll say about that is so if somebody brings it up, that can open up the conversation. I'm very open at the fact that I have a wife and that I'm lesbian. And I purposely do that, personally, to see what the reaction is going to be and what the company is going to offer. So I can determine if I feel like this is going to be a good space for me. I think that when you're having an interview, it's just like for anyone who may not be in the community. You don't really necessarily ask someone if they're married or "Are you having children?"

+ +

You don't necessarily ask like, "Do you fall in this community?" or "Talk about transgender." Because a lot of times, there is this feeling of I have no idea what this space is going to feel like for me. I'm not going to out myself, and you may even out somebody who may not be out in their professional or their personal life yet. And you want to provide that comfortable space. But you don't want to do that either because then that person and across other interviewing spectrums bias can amplify a lot. And you can mislabel someone's gender. You might use the wrong pronouns, and pronouns are always optional.

+ +

So I always say look at the person for their experience and what you want to learn more about relating to the job. Of course, you want to learn about them a little bit more personally as well. But it is more harm to try to identify their identity because that could lead to bias and could ultimately lead to discrimination because you don't know what that person's view is in the interview process either.

+ +

CHAD: But once someone joins your team and assuming that they're open about their identities, and this applies to all identities, I think, then quote, unquote "treating everybody the same or ignoring people's identities actually does the reverse of what people intend." It makes an environment where people feel like they don't belong, that the identities that they have or what are important to them aren't recognized. And so you're not recognizing the person's full self, and you're not accommodating it and trying to build an inclusive environment. It could actually backfire if you intentionally ignore people's identities, right?

+ +

GERONDA: Yes. So it can backfire if you ignore the identities, especially the identities that have been shared openly. So if I'm going to fill out a survey, let's say where identify myself as part of our hiring process, as a manager, I may not say, "Hey, I noticed that you checked off that you're transgender. How can I support you?" But it is going through the onboarding process and other areas to say here's what we offer from ERGs to benefits, to how we work, how we work as a team.

+ +

And if that person does disclose that they're transgender, or they're in the LGBTQ+ community, or they mention their culture or what have you, you can then direct them in the right places to say, "Oh, we actually do have this LGBTQ+ ERG if you're interested. I know you may be talked about it in the onboarding process. If you're open to it, you can definitely join us, and here's how." And then, over time, it is really thinking about you may not know the identities of your team but taking time to do things in practice that would touch upon all identities.

+ +

So when you're thinking about having team conversations, there may be somebody on your team who is neurodiverse. They might have autism, or they might have ADHD. And how you're communicating...then you start to think about meetings. Do you just do Google Meet meetings? Do you just do Typeform meetings? You have to think about different learning styles and for different identities. Like it's Pride Month right now, just saying Happy Pride Month to everybody. And they may then be open to sharing more about their identity and sharing the activities that are happening in Pride Month, and encouraging them to do things on the council.

+ +

So you want to make decisions that could think about different identities, even if you may not know what those identities are. And I also think it's being proactive and being ready that you might have those identities. So things like I had mentioned where you might be providing gender-affirming care, or you might look at your parental leave policies and other things that you have available for that.

+ +

So I would say without knowing the identity, I think over time, as you build trust that [inaudible 28:24] start to develop and come out. But it's also if somebody's coming to you in confidence with something, really taking that very, very seriously. If I, God forbid, came to you, Chad, and was like, "Chad, I'm coming out to you. I am lesbian, but I'm not comfortable with sharing with everybody else." I would trust that you wouldn't share that amongst other people. So that's another piece to that as well.

+ +

CHAD: Yeah, that's a really good point. I think as people in that position, in management positions, we need proper training around those kinds of situations to ensure that we handle them well. I think training is an important part of being a manager but also just DEI in general training and equipping everybody.

+ +

GERONDA: Yes. Having a common language across the board and a common understanding across the board is very important. Because when you think of diversity, equity, and inclusion, everybody may have varying understandings of what those mean. Some people may not know what those mean, and so having that common language across the board and understanding. And then yes, training, of course, and opportunities for you to then practice that training in spaces and getting feedback along the way.

+ +

CHAD: So I imagine that there are a lot of people listening who this is really important to them. It's an important topic or a place where they want to make improvement for themselves or their company. They might not have a lot of support or resources at their company. There might not be a DEI Council already. And I know every company is different. Every team is different. But are there some things that individuals or leaders might start thinking about or doing specifically if they're just getting started with this?

+ +

GERONDA: So if you're just getting started, I always say there are a lot of great resources out there for you to consider. So whether that's a book...LinkedIn has really great training on just understanding DEI and how to be an inclusive leader or work in an inclusive environment. But I would say a really great place to start is if you don't have this already, think about what your demographic looks like. And what are some things that other companies may be doing? So joining different channels and saying, "We're at the beginning stages. What are some things that we can do?"

+ +

But I think what's most helpful to start is you have to gauge where you are as a company and understand your people and the demographic and do something that allows for an open discussion and open forum to get perspectives from other people. So I know things like listening tours where you might talk to different departments or different teams. Or if a company is small enough like our company, you can meet with each person and then think about what are some common themes that you're seeing? That can also create a great space for that.

+ +

I'd also say you can put out a survey to see what the experience is. So if you are doing things like engagement surveys, you can absolutely include things in there about what do you think we're missing? What would you hope to see? But I think a lot of it is you have to understand your people and what you have available to you at the company and provide an opportunity for everyone to share their ideas and perspectives to that.

+ +

So what I've seen work really well is one, when you start to understand there has to also be this communication and this accountability at the leadership level to say, "This is why we're focusing on this. This is why we think it's important. We want to hear from you." And something that I thought was really unique and helpful is if your company is small enough or even if it's big enough, a lot of companies what they'll do is they'll have the CEO, or they'll have managers host these kinds of forums where you can meet with them, and you can share.

+ +

You can ask them a ton of questions. You can share your ideas. You can share what you hope to achieve from this and just starting to get perspectives first. And that may, over time, start to evolve into a council or people wanting to do an ERG. But really get as much as you can from people and then learn a lot from that as well.

+ +

CHAD: That's great. I asked that question, and then it turns out it was one of the ones that someone submitted in the chat from a thoughtbot person.

+ +

GERONDA: [laughs]

+ +

CHAD: So I wanted to acknowledge that even though we overlapped the question, that question technically comes from Amy Wall, a developer at thoughtbot. Another question from Fernando is how can other employees support DEI people like you from a daily perspective?

+ +

GERONDA: Just take over my job. [laughter] No, I'm just kidding. So it's always helpful for me to have transparent conversations of where you are. If you want to help me, it's helpful to learn about your experience and come to me with things that you're seeing or ask me questions. Also, don't be afraid either to say, "I really don't know what this means or what this is. Can you help me?"

+ +

And it's also bringing learning as well because I'm not a developer, and I'm not a designer. [chuckles] I think that the work that our team does is fantastic. And they're super smart. And when I look at a lot of the things that are happening, like coding and conversations, although I have absolutely no idea what you're talking about, it's really amazing to see. But from your perspective, there may be things that I am suggesting, like, oh, maybe we need to increase accessibility, and we do need to do these things. But be okay to challenge me and say, "I actually don't know that that's going to work well or not."

+ +

But I think to support me in my role, the more that I know of the challenges, and the more that I know about you individually, and the more that you continue to bring these things up from a DEI perspective is super helpful. So what I've noticed and what I've really loved about working here is we have those opportunities to have those very open, transparent conversations. And we can post about issues, and we can post about things that we want to change in our handbook.

+ +

And sometimes people come to me with questions. And I love that people come to me and say, "This is what I want to work on more. Do you have any suggestions?" That really helps me in my role because as much as I would love to know everything that's happening with every single person, it can be challenging. So be honest with me and just share what's going on and be willing to learn and share resources with me too. Yes, I'm a DEI practitioner, but that doesn't mean I know everything. I know it's very surprising to a lot of people right now that I don't know everything.

+ +

CHAD: [laughs]

+ +

GERONDA: But share things you're reading. Share things that you've noticed. That helps me a ton. So that's how I say you can help me. And thank you for that question, Fernando. I appreciate that.

+ +

CHAD: A thing I would add is recognizing that there are, especially at thoughtbot, multiple levels of ways that you can support and contribute to our efforts. So we try to identify on the council okay, this is the thing we want to work on. The council isn't intended to do everything. But so what we'll often do is we'll say, okay, we're going to gather a group of people in a task force, and we're going to work on this. I think that's another level of contribution.

+ +

So showing up for those participating in them when they arrive, and frankly, not signing on to too much because you spread yourself too thin and then can't do a good job doing everything that you want to do. So yeah, those are some tips that I would add. Geronda, thank you so much for joining me on the show. I really appreciate it.

+ +

GERONDA: Thank you for having me. I appreciate that.

+ +

CHAD: Happy Pride. [laughs]

+ +

GERONDA: Yes. Happy Pride. I'm so excited. I feel like I'm a little biased, but this is like my favorite month of the year. [laughter] Lots of fun celebrations. And of course, I recognize other holidays, and I think they are very important. But this one is generally very close to my heart. So thank you.

+ +

CHAD: Well, if folks want to follow along with you, get in touch with you, find out more, where are all the places that they can do that?

+ +

GERONDA: Yes. Follow me on LinkedIn, Geronda Wollack-Spiller. I'm on Twitter at @gerondaws. And I think those are the two best places to follow me. I'm most active on LinkedIn. And I usually respond there pretty heavily.

+ +

CHAD: We'll include those links in the show notes, which you can find attached to this episode. And you can subscribe to the show, find all those notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Thanks for listening. And thanks to all the thoughtbot people who were in the chat, and with the questions, and paid attention and listened to this episode. And see you next time.

+ +

GERONDA: Yes. [laughs]

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Geronda Wollack-Spiller.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+26fZzVgA + + ]]> + + Chad Pytel + Geronda Wollack-Spiller + + + 430: LearnWorlds with Panos Siozos + https://podcast.thoughtbot.com/430 + 60694341-3d53-4a24-a084-d7683ed5a493 + Thu, 07 Jul 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Panos Siozos is Co-Founder and CEO of LearnWorlds, an online course platform for creating, selling, and promoting online courses. + +Chad talks with Panos about building e-learning platforms dating back to 1999, providing rich feature sets and catering to customers located in lots of different places, and deciding to stop bootstrapping and take investor money. + 37:55 + no + + + Panos Siozos is Co-Founder and CEO of LearnWorlds, an online course platform for creating, selling, and promoting online courses. +Chad talks with Panos about building e-learning platforms dating back to 1999, providing rich feature sets and catering to customers located in lots of different places, and deciding to stop bootstrapping and take investor money. +LearnWorlds (https://www.learnworlds.com/) +Follow LearnWorlds on Twitter (https://twitter.com/learnworlds), Facebook (https://www.facebook.com/learnWorldsCo?fref=ts), Instagram (https://www.instagram.com/learnworlds/), YouTube (https://www.youtube.com/user/learnWorlds), or LinkedIn (https://www.linkedin.com/company/learnworlds/). +Follow Panos on Twitter (https://twitter.com/psiozos) or LinkedIn (https://www.linkedin.com/in/siozos/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giants Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is Panos Siozos, Co-Founder and CEO of LearnWorlds, an online course platform for creating, selling, and promoting online courses. Panos, thank you so much for joining me. +PANOS: Hi, Chad, and thanks for hosting me. +CHAD: You have been working on LearnWorlds for a while now. Where did the idea come from? +PANOS: I guess this has been brewing in our minds, mine and my co-founder's, for many years. We built our very first e-learning platform back in 1999, right after completing our studies in computer science. And we started postgraduate studies in educational technology. So in an academic setting, though, we had built many, many e-learning products, platforms, and authoring tools. And we were always exploring the state of the art. +And we always had it in the back of our minds the possibility and our obligation, I guess, to create a commercial product at some point and try to get the state of the art of e-learning that we were exploring in the academia and put it at the hands of actual trainers, and teachers, and give them the tools to create the best possible online courses that they could. That was always at the back of our minds. +And after completing our Ph.D. studies, after working in different jobs and different roles, we got back together at some point in 2012. And at that point, the conditions for e-learning were very, very mature. It was like bandwidth was in abundance. It was easy to create videos. It was easy to distribute videos. Cloud computing made it even easier to create software as a service platforms. And we understood that it was the perfect moment to come together, take our expertise, and try to put it in an amazing product that would be commercial and help all those people out there that wanted to create online courses. +CHAD: So I think you launched in 2014. +PANOS: Yes, we spent a couple of years. We started building the platform in 2012 in stealth mode. We were, I guess, traditional engineers. We had this build it, and they will come mentality. +CHAD: [chuckles] +PANOS: We had done almost like in the first year almost zero research on customer development and business development. We just had in mind to create the best possible platform that we could, and then obviously, people would just buy it because it's the best. Obviously, things don't always work that way. So we created the platform then we started talking with potential customers. +We launched commercially in 2014. And this is when we had our very first customers, people who had the online courses. They had the online content. They had audiences, but they didn't have a platform. It seemed a huge burden and a huge task to create an actual platform to deliver and sell their courses. And this is where we came in and started providing our tool as a software as a service solution. +CHAD: So in 2014, I'm sure that there were other competing products on the market. Today, there are probably even more. What makes LearnWorlds different from all of those or better from those? +PANOS: In 2014, it was very early, I guess, in online courses. Most people were going to marketplaces like Udemy or Coursera. It was very difficult back then to create your own online school, to own the website. We had people who were either using traditional clunky Jurassic; I would say, learning management systems. +CHAD: [chuckles] +PANOS: And they were trying to adapt them for e-commerce and all the stuff, and it was always very difficult to do. Others were trying to duct tape together WordPress sites and plugins and custom codes. And that was something that wasn't scaling very gracefully. I would say after a couple of 100 users, it was almost impossible to maintain sites like that. +Others were trying to create their own platforms, write code internally or hire a couple of developers. And then a few months or a couple of years and after having spent a couple hundred thousand dollars, they were realizing that this is very difficult to develop a tool like that unless you've done that in the past and you know what you're doing. So it was very timely to bring to the market a product like that. +What differentiated us from the others and what still differentiates us is that we have an obsessive focus on the learner experience. We're probably the only, I don't want to sound presumptuous, but we're probably the only course platform creators or, let's say, founders or co-founders of a course platform who have actually studied that. And we have PhDs in edtech. So we are bringing lots of our academic background into the platform. And we know that initially, this was even detrimental to growing the platform because, in some ways, the platform was even too complex for what people were expecting and could absorb back then in terms of features. +But as the years passed by, we managed to find an excellent balance between how powerful the platform can be in terms of amazing design, offering great, interactive, engaging learning experiences, and also offering the ease of use and all the commercial features that users would expect. So we have a deep product with lots of offering affordances. +For example, people can create amazing interactive videos very easily, just like editing a PowerPoint, I would say. You can just upload a normal video that you shot yourself, perhaps using a mobile phone, and you can convert it into an amazing interactive experience. And this is something very important for the students, the customers that will actually, at the end, consume the content. +So to this day, the platform is very innovative. We're still participating in research projects, and we're seeing what is the state of the art of e-learning? And we're trying to implement that into the platform, obviously, now with amazing feedback from thousands of customers and millions of end-users. So it's an amazing opportunity to give to the people the things that they actually need and use to create the best possible online courses and sell as many of them as possible. +CHAD: One of the things, and it speaks right to the value proposition of the product that you use, is that there are so many features that you can have. And so, if you embark on the journey of creating your own platform, it's really easy to look at the surface level of what that looks like and say, "Oh, that's easy." +PANOS: Yes. +CHAD: But then, when it comes to other features, you have the ability to make mobile applications on LearnWorlds and those kinds of things. Like, that's a rich feature set that is really difficult to deliver on your own, right? +PANOS: It's very difficult to deliver on your own, and some things look deceptively simple. And when you actually see what is under the hood, it is very, very complicated to deliver a super user-friendly and easy tool or platform or authoring environment. So the platform is very powerful because people have all these different needs. +We're talking here this is a platform that can support both the, I don't know, the nice, old lady that wants to sell some knitting courses, and she has a community of a couple of dozen people who follow her and consume her courses, all the way to online schools that run with more than 300,000 users. It's extremely difficult to be able to scale a school to a size like that. +And in many cases, people might start simple. They might even create a nice, simple user interface with a couple of videos. This is something that everybody believes that they can do. And they can do it initially, but once they have a couple of hundred users, or a couple of thousand users, their success becomes problematic. They cannot keep up with all the demands for something like that. And then they need more features. They need more features for doing their marketing. They need analytics. They need the scale and the reliability that a platform that serves a few thousand users requires. There are all sorts of things that people miss. +So we believe that you don't necessarily have to reinvent the wheel, especially when there are amazing ready-made wheels out there, white-labeled wheels where you can just go to a platform like ours. And in a couple of days, you can have an amazing online school customized and optimized for your own case study, for your own audience, for your own language, for your own design. The settings that you need to power your own business model, whether it's selling courses on their own, selling memberships, selling subscriptions, bundles of courses, all those different things that look simple on the outside but they require lots of precision to work great and delivering in scale. +CHAD: So, given the rich feature set, I'm sure that you have a lot of customers located in lots of different places. I'm sure they have different needs, too, different profiles. How do you as a company go about deciding what to work on? And how does the workflow through your organization? +PANOS: This is always a very interesting task, something that we are doing almost every month. We update our roadmap on a quarterly basis. But every month, we go out and check again the feature requests, and the trends in the market and the industry, and all the things that are happening. We receive hundreds of feature requests from our existing customers every week, and these are being organized and prioritized. And we always try, obviously, to help our own existing customer base. But we work with many partners and other platforms as well to create integrations and to deliver features, and uncover needs that people have today. +And in the past couple of years, as you can imagine, with COVID, we had to adapt many changes to the new business models and the new ways that people started creating, delivering, and consuming online courses. For example, when COVID started, almost overnight, there was a huge demand for creating and delivering live courses with no pre-recorded videos. That's something that used to be quite frequent feature requests, let's say. Before COVID, we had it in our roadmap. Once we understood what COVID would mean for the industry, almost overnight, we stopped other things that we were doing and started working hard on delivering, let's say, our Zoom integration. +So in just a matter of a few short weeks, it was super easy for anybody who wanted to teach. You imagine how the situation was amidst the lockdowns. People their businesses were shutting down. They couldn't reach their audiences, their customers. Their revenue streams had ran out. So we brought to the market this integration, and it was super easy for a photography teacher, a yoga teacher, a coach from anywhere to just create an online course, plug in their Zoom account, and be able to deliver courses, either one-on-one, to a small group or even to hundreds of students. +So we had to adapt as the market was adapting, and the same comes when it comes about business models, ways of getting paid, different payment methods. For example, some European countries...as a European company, we're also very attuned to what our European customers need. In several European countries, credit cards, traditional credit cards like Visa and MasterCard are not the most frequently used methods of digital payments. So we have to work with local payment gateways to provide these kinds of solutions. Also, for taxes, taxes in Europe are way more when you're selling from one country to the other. They’re much more difficult and complex than in the U.S., So we have to adapt to the demands from customers and offer solutions like that. +So it's always anticipating, seeing what the actual users need but also keeping a large chunk, I would say, space for innovating, bringing to the product things that people don't actually ask for because they don't even know that they could exist and that they could be helpful. And this is where our expertise, I would say, comes into play. Our team is constantly researching trends and other platforms and how people interact with platforms and other tools. And we try to stay ahead of the curve, not just follow what others are doing but be the leaders in this kind of chase. +And rightly, you mentioned there are dozens of platforms out there. It's great to see so much innovation in so many different platforms. Especially after COVID, I can say that it seems like there is a viral spread of new platforms. We almost see one new platform every week. And it's nice because it seems that the industry is very hot. And there is lots of demand for these kinds of solutions. We do have a head start, and we will continue to improve the product and bring an amazing solution to people who want to use something like that. +MID-ROLL AD: +Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. +thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. +Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff (https://thoughtbot.com/liftoff) +CHAD: One of the features that you have is localization, being able to have your content in lots of different languages. How early on did you add that feature? +PANOS: This is something that we had to do very early on. The first iteration of the platform, before even founding the company when we were just a side project, was built for the Greek market and the Greek language. So that was in a very difficult situation back in 2013, 2014. There was a huge financial crisis in Greece back then. +So once we had the product ready, we realized that nobody wanted to invest in e-learning. It was a very tough situation to be in. So that's probably one of the best things that happened to us. Because almost overnight, like in day two, we had to go to an existing mature market, which was the U.S. market, where people were willing to test a new platform. They really liked what the platform could do. They were ready to risk a product, a new product that was brought into market by a small ragtag team from the other side of the world. And so we had to adapt to a new language. +So that was something that came in very early on and was very helpful in dealing with different markets and different localizations, working with different payment gateways, and becoming an international product from very early on. So right now, we have customers in more than 110 countries; even though U.S. is by far our biggest market, almost half of our market is based in the U.S. But we are very willing and able to work with new markets and help them and help people bring their own localizations and their own translations into the platform. +CHAD: Yeah, that jumped out at me because I've seen other products that don't have that feature. And I think it's in part because a new company started in the United States knows that they have a fairly big addressable market just within the U.S., and they don't necessarily need to support multiple languages. And I thought that, and that's what I heard, was that the fact that you were not in the U.S. compelled you to have localization really early on. You've also mentioned a few other ways in which that has influenced you. How do you think being in Greece and being a European startup has influenced you as a company overall? +PANOS: This is the DNA and the blueprint of how the company eventually grew. For example, we started in Greece amidst a dire financial crisis. We were, from day one, a remote company because of the conditions of the co-founders. So we happened to be in three different cities, two different countries. And we just wanted to work together. We didn't have any long-term plans of how a company would evolve. So from day one, we became a remote company. So as you can imagine, in the next few years, that gave us...and even when COVID came, that gave us an immense advantage because that's the way we had been working. We knew that full remote was an option from day one. +The second thing that really also influenced us is that because we were growing in a situation...amidst this financial crisis, we were a bootstrapped company. We didn't have access to any external funding, which obviously made things much more difficult at the beginning. We couldn't get access to funds and invest in marketing very early on and push the platform heavily. +On the other end, as a bootstrapped company, we developed a mentality of being very resource-efficient, cash-efficient, paying great attention to all of our KPIs and our unit economics, doing lots of unscalable things, as Paul Graham would say, you know, wearing lots of hats, investing a lot in people who didn't have the credentials, let's say, or the experience that one would expect from to hire in a U.S-founded startup. +So we had to invest in the local people, in the local skills, amazing youth. We're talking here back in 2013, 2014. Youth unemployment in Greece was about 70%. So it was a terrible situation. It's like this meme where people were asked to have experience, but nobody was giving them a chance to develop this work experience. So we invested in people like that. And that's the best thing we did. +So we're talking about a remote bootstrapped startup with a can-do mentality with access to amazing people, not specialized or skilled, let's say, or experienced in this particular software as a service role but very smart and willing to work and excel and do better for themselves and for the company. So I think that was the recipe that helped the business grow. +And also, coming from a small market, we had to adapt to a fragmented European market. Europe is a huge market of about 500 million people, a few less now, a few million less now, barring UK. But this is a fragmented market. You don't have a unified market of one language. One currency may be, yes, in most countries, but we're talking different languages, and different tax regimes, and all the staff and different mentality even. So we had to adapt. This is difficult. But also, it gives you the resilience and the flexibility to adapt to all these different cases. +And then going international was very natural to us. It's not that we started in a small market, and then we're trying to create a foothold in a second market or the third market. From day one, we had to look outward to find the people who would use and dare to use a platform like ours and try to be our best selves and try to give them an amazing product. +CHAD: Yeah, that's great. You mentioned that you initially bootstrapped. Have you taken investment since then? +PANOS: Yes, we have. We did a small seed round of about $1.1 million in 2019 with a small local VC. And then last year, about a year ago, we closed a Series A funding round of $32 million with Insight Partners. +CHAD: That's great. Congratulations. What caused you to make the decision to stop bootstrapping and take an investment in that seed round? +PANOS: That was the point when we realized that we needed the extra fuel in order to push the pedal. We were seeing that we already had a great product. We were on to something. It would have been too slow to continue working in a bootstrapped mode with a few resources that we had. We wanted to accelerate. We wanted to accelerate hiring, product development, and all this stuff. So we didn't actually need the money back then for the viability of the company, which is actually, I guess, the best reason to raise money and the best time when we don't actually need it. +So that's how we started. That gave us the extra confidence. It allowed us to bring in a few extra people. We started investing more in hiring professionals that had already done that, who had already experience in SaaS businesses and international businesses. And that gave us a lot more certainty and trust in ourselves to keep growing the product and going further. +And this last round with Insight Partners...Insight Partners is one of the top VCs in the private equity funds. They also bring in an amazing team of operators who can always jump in and help in case we need something. So it helps us expand our horizons, be more aggressive in our hiring, much more confident about what we can do. And that also has given a great boost to the business and the team. +CHAD: This idea of acceleration and going faster is an interesting one. I've seen it in our clients as well where, especially if you're in a competitive market, you could have a good growing reasonable business, but if everyone else around you is raising money, raising capital, and accelerating, that can put you back especially if you don't realize it. Do you feel like that was part of what was causing you to want to accelerate? +PANOS: Yes, yes, definitely. So e-learning is a complex industry, let's say. What we're doing is very competitive because the market is always changing. People demand more. New business models require new features, and everybody wants an all-in-one platform that will keep doing more and more. So you cannot just stand still. It's not like a micro SaaS where you can have a feature the same working for five years, and you can still have people signing up and using that. You have to be ahead. You have to adapt. This is a very fast pacing industry. +And now there are so many different players from all different industries who look at online courses and content delivery in general in new ways and start approaching from different angles, whether they are marketing tools, or video hosting providers, or email marketing providers, or traditional learning management systems. So there are many people around this online course industry. So you need to have a war chest. You need to bring in experts. +You need to keep investing in R&D and improving the product and also customer success, making sure that your amazing customers can perform even better, and they can take advantage of all the features in the platform. So you cannot just stand still; that's not an option. You can perhaps get away with it for two to three years. But eventually, the product will fizzle out. We will not be able to compete with what is happening. +You mentioned all these different platforms coming into the market. You have to stay ahead. And luckily, now, with the recent funding and obviously with the help of our customers, we have all the resources that we needed to implement the vision that we have for the product. All the things that we couldn't do in the past because we were constrained in terms of resources, and time and money, now we are able to innovate much faster, bring many more new features to the platform and to the market, and help people create the best possible online courses. +CHAD: You mentioned that when you raised that initial seed round, you did it with a local investment company. Was that intentional? I took a peek; the company is Marathon Venture Capital. And they specifically say on their website that they day one partner to Greek tech founders, so they're very focused. [laughs] +PANOS: Yes, they're very focused. There is a huge network obviously of Greek founders almost everywhere in the world. So they have a deep pool of people to reach out to and a huge network. It was definitely; also there was a parameter of convenience, you know, them being close, being able to communicate easily, having the same kind of mentality and the same kind of experiences. This obviously makes things much more easier. I guess at that point; it would be much more difficult to go from a bootstrapped remote ragtag team to a fully funded company with a traditional, let's say, Silicon Valley-based VC. +Even explaining back then in 2019 that you are a remote company wasn't easy. It's something that made some people wonder about how serious you are about that. What are your plans going forward? How are you going to hire? How are you going to compete? How are you going to hire people if you don't have these amazing startup offices with the pool tables and all the stuff? But we were saying that it's feasible. You can do it. I mean, you can find the people who want this kind of lifestyle who appreciate this flexibility, who want to be close to their families and work from their small cities somewhere in Greece or in other countries and be close, let's say, online with another team. +We weren't crazy back then. So it was much easier to make these kinds of propositions to a local team. I guess it was convenient, and we had a good match. But already, this investment prepared us a lot in terms of organizing the business, due diligence, taking care of our finance and reporting, and all the stuff, and legal and made us ready to go for a bigger investment later when we needed it and when the time was right. +CHAD: So from three co-founders in 2014, how large is your team now? +PANOS: I think with the recent hires, we're about 120 people right now. We are still fully remote. In fact, in the next few weeks, we will just open a small co-working space in Athens where about half of our staff resides. But this is going to be more of a co-working space kind of experience. I think right now; we have people in our team from 16 different nationalities in 11 different countries. +But still, the majority of the people are based in Greece, so here are the roots of the company. But we are internationalizing fast, getting people everywhere we can find them. People that fit the business, we're happy to bring them on board, and these kinds of remote-first flexible environment that we have is very fitting for some amazing people from all over the world. And they prefer that actually than returning back to an office. +CHAD: For yourself as a leader, how have you needed to grow or change as your team has scaled so much? +PANOS: We're still doing that. +CHAD: [laughs] +PANOS: It's not just me. It's my co-founders as well, my two co-founders, Fanis and Giorgos. I wouldn't have been able, obviously, to do anything alone, neither any one of us, without having the others. Still to this day, we're very hands-on. We're involved in all the projects. In some cases, we were a bit more reluctant to delegate. But still, the team really appreciates that we're still in the trenches with them, learning, solving problems every day, trying to not give solutions from both ad hoc but be with them, solve problems with them. That's something that they appreciate a lot. +And obviously, we are still...every day we are transitioning. We started as a team of three people on a side project that was just taking a few hours of our time per week. And this business came to be the biggest part of our lives, spending 12-plus hours every day and more, and weekends, and everything else with a growing team amidst some very difficult conditions like COVID where things were, you know, in our families and our cities, things were blowing up. +And we had to stay close to our teams and keep delivering a product that was skyrocketing in terms of demand. So we are still learning; that's our motto here in LearnWorlds, getting better every single day, trying to enable our team be more enablers now and better project managers, inspire people in order to help them deliver the best that they can. +We are lucky to be in a great industry with amazing customers, all of them creative people who create great content. They love their products. They love their own customers. So this is something that helps us have a great mission that our employees also share. So they see that it's not just about the numbers or about getting the MRR or getting the sale or whatever. But they really enjoy helping our customers and helping them create amazing little, online businesses and get their products online. +Every day we get amazing feedback from our customers, and that really makes people around here very happy. At the end of the day, they go home, and they know that they helped launch another business or two and help people, in some cases, realize their dream of becoming independent, you know, escaping nine-to-five, or helping a coach or a trainer get some amazing reward for the fruit of their labor and the content that they have created with so much work. So this is a great thing to watch. And it's great being around people who enjoy this kind of business and this kind of environment. +CHAD: Is there anything that when you were starting the company based on your prior experiences, both good or bad, at the other companies that you had worked at along the way in your career or your co-founders’ careers when you said okay, we're starting LearnWorlds. We're starting our own company. We specifically want to not make this mistake or instill this value in our culture that you were very intentional about? +PANOS: There are probably a lot of things. I'm not sure if I can name one in particular, but we always wanted to create a business that we would love being employees of. So we wanted to be in an environment that we would enjoy being ourselves. That's probably kind of egocentric, like, it was about us. But I think there were some unspoken values in some cases or cases where we would see that no, this is bad; we shouldn't go down that path. +We didn't want to replicate ourselves and create a company of people who'd look like us and react to the same things that we would. But we always wanted to have an environment that we would feel happy, and we would love to be part of. So far, at that scale of 120, we have managed, I guess, to do that. In many cases, this is also our number one priority. +Features come and go. People come and go. Customers come and go. But we know that the biggest strength of this company is the minds of the people who work for us. We want them to be happy. We want them to come to work happy every day and bring their best. That is our major priority. And especially in times like that, their mental and physical well-being as well it's a major priority for us. +And we believe that if we create these conditions of safety and trust, the empowerment and learning as well of constant improvement, we will achieve our goal, and we will have a team that will be working for a product that is going to be better every day and every week. +And this shows, at the end of the day, this is something that customers can appreciate, either by seeing a new feature in the platform that they love or by receiving some amazing help from one of our customer support reps or an amazing demo from one of our salespeople. This is something that we are lucky still to show everywhere in the company. This is the mentality of the entire company. Hopefully, we'll be able to preserve these kinds of values and attitude as we scale. +CHAD: That's great. I really wish that for you. Good luck and congratulations on all the success. Thank you so much for coming on the show and sharing your story and your wisdom about scaling the company. If folks want to learn more about LearnWorlds or get in touch with you or follow along, where are all the places that they can do that? +PANOS: You can always come to our website www.learnworlds.com. Our platform offers a 30-day free trial, no credit cards, no strings attached. If you have any questions around online courses or any ideas about what you could build yourself for your business, come to our website. Join us, and we will be happy to help you out and show you what is possible today. +CHAD: Great. And you can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Panos Siozos. + + + Panos Siozos is Co-Founder and CEO of LearnWorlds, an online course platform for creating, selling, and promoting online courses.

+ +

Chad talks with Panos about building e-learning platforms dating back to 1999, providing rich feature sets and catering to customers located in lots of different places, and deciding to stop bootstrapping and take investor money.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giants Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is Panos Siozos, Co-Founder and CEO of LearnWorlds, an online course platform for creating, selling, and promoting online courses. Panos, thank you so much for joining me.

+ +

PANOS: Hi, Chad, and thanks for hosting me.

+ +

CHAD: You have been working on LearnWorlds for a while now. Where did the idea come from?

+ +

PANOS: I guess this has been brewing in our minds, mine and my co-founder's, for many years. We built our very first e-learning platform back in 1999, right after completing our studies in computer science. And we started postgraduate studies in educational technology. So in an academic setting, though, we had built many, many e-learning products, platforms, and authoring tools. And we were always exploring the state of the art.

+ +

And we always had it in the back of our minds the possibility and our obligation, I guess, to create a commercial product at some point and try to get the state of the art of e-learning that we were exploring in the academia and put it at the hands of actual trainers, and teachers, and give them the tools to create the best possible online courses that they could. That was always at the back of our minds.

+ +

And after completing our Ph.D. studies, after working in different jobs and different roles, we got back together at some point in 2012. And at that point, the conditions for e-learning were very, very mature. It was like bandwidth was in abundance. It was easy to create videos. It was easy to distribute videos. Cloud computing made it even easier to create software as a service platforms. And we understood that it was the perfect moment to come together, take our expertise, and try to put it in an amazing product that would be commercial and help all those people out there that wanted to create online courses.

+ +

CHAD: So I think you launched in 2014.

+ +

PANOS: Yes, we spent a couple of years. We started building the platform in 2012 in stealth mode. We were, I guess, traditional engineers. We had this build it, and they will come mentality.

+ +

CHAD: [chuckles]

+ +

PANOS: We had done almost like in the first year almost zero research on customer development and business development. We just had in mind to create the best possible platform that we could, and then obviously, people would just buy it because it's the best. Obviously, things don't always work that way. So we created the platform then we started talking with potential customers.

+ +

We launched commercially in 2014. And this is when we had our very first customers, people who had the online courses. They had the online content. They had audiences, but they didn't have a platform. It seemed a huge burden and a huge task to create an actual platform to deliver and sell their courses. And this is where we came in and started providing our tool as a software as a service solution.

+ +

CHAD: So in 2014, I'm sure that there were other competing products on the market. Today, there are probably even more. What makes LearnWorlds different from all of those or better from those?

+ +

PANOS: In 2014, it was very early, I guess, in online courses. Most people were going to marketplaces like Udemy or Coursera. It was very difficult back then to create your own online school, to own the website. We had people who were either using traditional clunky Jurassic; I would say, learning management systems.

+ +

CHAD: [chuckles]

+ +

PANOS: And they were trying to adapt them for e-commerce and all the stuff, and it was always very difficult to do. Others were trying to duct tape together WordPress sites and plugins and custom codes. And that was something that wasn't scaling very gracefully. I would say after a couple of 100 users, it was almost impossible to maintain sites like that.

+ +

Others were trying to create their own platforms, write code internally or hire a couple of developers. And then a few months or a couple of years and after having spent a couple hundred thousand dollars, they were realizing that this is very difficult to develop a tool like that unless you've done that in the past and you know what you're doing. So it was very timely to bring to the market a product like that.

+ +

What differentiated us from the others and what still differentiates us is that we have an obsessive focus on the learner experience. We're probably the only, I don't want to sound presumptuous, but we're probably the only course platform creators or, let's say, founders or co-founders of a course platform who have actually studied that. And we have PhDs in edtech. So we are bringing lots of our academic background into the platform. And we know that initially, this was even detrimental to growing the platform because, in some ways, the platform was even too complex for what people were expecting and could absorb back then in terms of features.

+ +

But as the years passed by, we managed to find an excellent balance between how powerful the platform can be in terms of amazing design, offering great, interactive, engaging learning experiences, and also offering the ease of use and all the commercial features that users would expect. So we have a deep product with lots of offering affordances.

+ +

For example, people can create amazing interactive videos very easily, just like editing a PowerPoint, I would say. You can just upload a normal video that you shot yourself, perhaps using a mobile phone, and you can convert it into an amazing interactive experience. And this is something very important for the students, the customers that will actually, at the end, consume the content.

+ +

So to this day, the platform is very innovative. We're still participating in research projects, and we're seeing what is the state of the art of e-learning? And we're trying to implement that into the platform, obviously, now with amazing feedback from thousands of customers and millions of end-users. So it's an amazing opportunity to give to the people the things that they actually need and use to create the best possible online courses and sell as many of them as possible.

+ +

CHAD: One of the things, and it speaks right to the value proposition of the product that you use, is that there are so many features that you can have. And so, if you embark on the journey of creating your own platform, it's really easy to look at the surface level of what that looks like and say, "Oh, that's easy."

+ +

PANOS: Yes.

+ +

CHAD: But then, when it comes to other features, you have the ability to make mobile applications on LearnWorlds and those kinds of things. Like, that's a rich feature set that is really difficult to deliver on your own, right?

+ +

PANOS: It's very difficult to deliver on your own, and some things look deceptively simple. And when you actually see what is under the hood, it is very, very complicated to deliver a super user-friendly and easy tool or platform or authoring environment. So the platform is very powerful because people have all these different needs.

+ +

We're talking here this is a platform that can support both the, I don't know, the nice, old lady that wants to sell some knitting courses, and she has a community of a couple of dozen people who follow her and consume her courses, all the way to online schools that run with more than 300,000 users. It's extremely difficult to be able to scale a school to a size like that.

+ +

And in many cases, people might start simple. They might even create a nice, simple user interface with a couple of videos. This is something that everybody believes that they can do. And they can do it initially, but once they have a couple of hundred users, or a couple of thousand users, their success becomes problematic. They cannot keep up with all the demands for something like that. And then they need more features. They need more features for doing their marketing. They need analytics. They need the scale and the reliability that a platform that serves a few thousand users requires. There are all sorts of things that people miss.

+ +

So we believe that you don't necessarily have to reinvent the wheel, especially when there are amazing ready-made wheels out there, white-labeled wheels where you can just go to a platform like ours. And in a couple of days, you can have an amazing online school customized and optimized for your own case study, for your own audience, for your own language, for your own design. The settings that you need to power your own business model, whether it's selling courses on their own, selling memberships, selling subscriptions, bundles of courses, all those different things that look simple on the outside but they require lots of precision to work great and delivering in scale.

+ +

CHAD: So, given the rich feature set, I'm sure that you have a lot of customers located in lots of different places. I'm sure they have different needs, too, different profiles. How do you as a company go about deciding what to work on? And how does the workflow through your organization?

+ +

PANOS: This is always a very interesting task, something that we are doing almost every month. We update our roadmap on a quarterly basis. But every month, we go out and check again the feature requests, and the trends in the market and the industry, and all the things that are happening. We receive hundreds of feature requests from our existing customers every week, and these are being organized and prioritized. And we always try, obviously, to help our own existing customer base. But we work with many partners and other platforms as well to create integrations and to deliver features, and uncover needs that people have today.

+ +

And in the past couple of years, as you can imagine, with COVID, we had to adapt many changes to the new business models and the new ways that people started creating, delivering, and consuming online courses. For example, when COVID started, almost overnight, there was a huge demand for creating and delivering live courses with no pre-recorded videos. That's something that used to be quite frequent feature requests, let's say. Before COVID, we had it in our roadmap. Once we understood what COVID would mean for the industry, almost overnight, we stopped other things that we were doing and started working hard on delivering, let's say, our Zoom integration.

+ +

So in just a matter of a few short weeks, it was super easy for anybody who wanted to teach. You imagine how the situation was amidst the lockdowns. People their businesses were shutting down. They couldn't reach their audiences, their customers. Their revenue streams had ran out. So we brought to the market this integration, and it was super easy for a photography teacher, a yoga teacher, a coach from anywhere to just create an online course, plug in their Zoom account, and be able to deliver courses, either one-on-one, to a small group or even to hundreds of students.

+ +

So we had to adapt as the market was adapting, and the same comes when it comes about business models, ways of getting paid, different payment methods. For example, some European countries...as a European company, we're also very attuned to what our European customers need. In several European countries, credit cards, traditional credit cards like Visa and MasterCard are not the most frequently used methods of digital payments. So we have to work with local payment gateways to provide these kinds of solutions. Also, for taxes, taxes in Europe are way more when you're selling from one country to the other. They’re much more difficult and complex than in the U.S., So we have to adapt to the demands from customers and offer solutions like that.

+ +

So it's always anticipating, seeing what the actual users need but also keeping a large chunk, I would say, space for innovating, bringing to the product things that people don't actually ask for because they don't even know that they could exist and that they could be helpful. And this is where our expertise, I would say, comes into play. Our team is constantly researching trends and other platforms and how people interact with platforms and other tools. And we try to stay ahead of the curve, not just follow what others are doing but be the leaders in this kind of chase.

+ +

And rightly, you mentioned there are dozens of platforms out there. It's great to see so much innovation in so many different platforms. Especially after COVID, I can say that it seems like there is a viral spread of new platforms. We almost see one new platform every week. And it's nice because it seems that the industry is very hot. And there is lots of demand for these kinds of solutions. We do have a head start, and we will continue to improve the product and bring an amazing solution to people who want to use something like that.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff

+ +

CHAD: One of the features that you have is localization, being able to have your content in lots of different languages. How early on did you add that feature?

+ +

PANOS: This is something that we had to do very early on. The first iteration of the platform, before even founding the company when we were just a side project, was built for the Greek market and the Greek language. So that was in a very difficult situation back in 2013, 2014. There was a huge financial crisis in Greece back then.

+ +

So once we had the product ready, we realized that nobody wanted to invest in e-learning. It was a very tough situation to be in. So that's probably one of the best things that happened to us. Because almost overnight, like in day two, we had to go to an existing mature market, which was the U.S. market, where people were willing to test a new platform. They really liked what the platform could do. They were ready to risk a product, a new product that was brought into market by a small ragtag team from the other side of the world. And so we had to adapt to a new language.

+ +

So that was something that came in very early on and was very helpful in dealing with different markets and different localizations, working with different payment gateways, and becoming an international product from very early on. So right now, we have customers in more than 110 countries; even though U.S. is by far our biggest market, almost half of our market is based in the U.S. But we are very willing and able to work with new markets and help them and help people bring their own localizations and their own translations into the platform.

+ +

CHAD: Yeah, that jumped out at me because I've seen other products that don't have that feature. And I think it's in part because a new company started in the United States knows that they have a fairly big addressable market just within the U.S., and they don't necessarily need to support multiple languages. And I thought that, and that's what I heard, was that the fact that you were not in the U.S. compelled you to have localization really early on. You've also mentioned a few other ways in which that has influenced you. How do you think being in Greece and being a European startup has influenced you as a company overall?

+ +

PANOS: This is the DNA and the blueprint of how the company eventually grew. For example, we started in Greece amidst a dire financial crisis. We were, from day one, a remote company because of the conditions of the co-founders. So we happened to be in three different cities, two different countries. And we just wanted to work together. We didn't have any long-term plans of how a company would evolve. So from day one, we became a remote company. So as you can imagine, in the next few years, that gave us...and even when COVID came, that gave us an immense advantage because that's the way we had been working. We knew that full remote was an option from day one.

+ +

The second thing that really also influenced us is that because we were growing in a situation...amidst this financial crisis, we were a bootstrapped company. We didn't have access to any external funding, which obviously made things much more difficult at the beginning. We couldn't get access to funds and invest in marketing very early on and push the platform heavily.

+ +

On the other end, as a bootstrapped company, we developed a mentality of being very resource-efficient, cash-efficient, paying great attention to all of our KPIs and our unit economics, doing lots of unscalable things, as Paul Graham would say, you know, wearing lots of hats, investing a lot in people who didn't have the credentials, let's say, or the experience that one would expect from to hire in a U.S-founded startup.

+ +

So we had to invest in the local people, in the local skills, amazing youth. We're talking here back in 2013, 2014. Youth unemployment in Greece was about 70%. So it was a terrible situation. It's like this meme where people were asked to have experience, but nobody was giving them a chance to develop this work experience. So we invested in people like that. And that's the best thing we did.

+ +

So we're talking about a remote bootstrapped startup with a can-do mentality with access to amazing people, not specialized or skilled, let's say, or experienced in this particular software as a service role but very smart and willing to work and excel and do better for themselves and for the company. So I think that was the recipe that helped the business grow.

+ +

And also, coming from a small market, we had to adapt to a fragmented European market. Europe is a huge market of about 500 million people, a few less now, a few million less now, barring UK. But this is a fragmented market. You don't have a unified market of one language. One currency may be, yes, in most countries, but we're talking different languages, and different tax regimes, and all the staff and different mentality even. So we had to adapt. This is difficult. But also, it gives you the resilience and the flexibility to adapt to all these different cases.

+ +

And then going international was very natural to us. It's not that we started in a small market, and then we're trying to create a foothold in a second market or the third market. From day one, we had to look outward to find the people who would use and dare to use a platform like ours and try to be our best selves and try to give them an amazing product.

+ +

CHAD: Yeah, that's great. You mentioned that you initially bootstrapped. Have you taken investment since then?

+ +

PANOS: Yes, we have. We did a small seed round of about $1.1 million in 2019 with a small local VC. And then last year, about a year ago, we closed a Series A funding round of $32 million with Insight Partners.

+ +

CHAD: That's great. Congratulations. What caused you to make the decision to stop bootstrapping and take an investment in that seed round?

+ +

PANOS: That was the point when we realized that we needed the extra fuel in order to push the pedal. We were seeing that we already had a great product. We were on to something. It would have been too slow to continue working in a bootstrapped mode with a few resources that we had. We wanted to accelerate. We wanted to accelerate hiring, product development, and all this stuff. So we didn't actually need the money back then for the viability of the company, which is actually, I guess, the best reason to raise money and the best time when we don't actually need it.

+ +

So that's how we started. That gave us the extra confidence. It allowed us to bring in a few extra people. We started investing more in hiring professionals that had already done that, who had already experience in SaaS businesses and international businesses. And that gave us a lot more certainty and trust in ourselves to keep growing the product and going further.

+ +

And this last round with Insight Partners...Insight Partners is one of the top VCs in the private equity funds. They also bring in an amazing team of operators who can always jump in and help in case we need something. So it helps us expand our horizons, be more aggressive in our hiring, much more confident about what we can do. And that also has given a great boost to the business and the team.

+ +

CHAD: This idea of acceleration and going faster is an interesting one. I've seen it in our clients as well where, especially if you're in a competitive market, you could have a good growing reasonable business, but if everyone else around you is raising money, raising capital, and accelerating, that can put you back especially if you don't realize it. Do you feel like that was part of what was causing you to want to accelerate?

+ +

PANOS: Yes, yes, definitely. So e-learning is a complex industry, let's say. What we're doing is very competitive because the market is always changing. People demand more. New business models require new features, and everybody wants an all-in-one platform that will keep doing more and more. So you cannot just stand still. It's not like a micro SaaS where you can have a feature the same working for five years, and you can still have people signing up and using that. You have to be ahead. You have to adapt. This is a very fast pacing industry.

+ +

And now there are so many different players from all different industries who look at online courses and content delivery in general in new ways and start approaching from different angles, whether they are marketing tools, or video hosting providers, or email marketing providers, or traditional learning management systems. So there are many people around this online course industry. So you need to have a war chest. You need to bring in experts.

+ +

You need to keep investing in R&D and improving the product and also customer success, making sure that your amazing customers can perform even better, and they can take advantage of all the features in the platform. So you cannot just stand still; that's not an option. You can perhaps get away with it for two to three years. But eventually, the product will fizzle out. We will not be able to compete with what is happening.

+ +

You mentioned all these different platforms coming into the market. You have to stay ahead. And luckily, now, with the recent funding and obviously with the help of our customers, we have all the resources that we needed to implement the vision that we have for the product. All the things that we couldn't do in the past because we were constrained in terms of resources, and time and money, now we are able to innovate much faster, bring many more new features to the platform and to the market, and help people create the best possible online courses.

+ +

CHAD: You mentioned that when you raised that initial seed round, you did it with a local investment company. Was that intentional? I took a peek; the company is Marathon Venture Capital. And they specifically say on their website that they day one partner to Greek tech founders, so they're very focused. [laughs]

+ +

PANOS: Yes, they're very focused. There is a huge network obviously of Greek founders almost everywhere in the world. So they have a deep pool of people to reach out to and a huge network. It was definitely; also there was a parameter of convenience, you know, them being close, being able to communicate easily, having the same kind of mentality and the same kind of experiences. This obviously makes things much more easier. I guess at that point; it would be much more difficult to go from a bootstrapped remote ragtag team to a fully funded company with a traditional, let's say, Silicon Valley-based VC.

+ +

Even explaining back then in 2019 that you are a remote company wasn't easy. It's something that made some people wonder about how serious you are about that. What are your plans going forward? How are you going to hire? How are you going to compete? How are you going to hire people if you don't have these amazing startup offices with the pool tables and all the stuff? But we were saying that it's feasible. You can do it. I mean, you can find the people who want this kind of lifestyle who appreciate this flexibility, who want to be close to their families and work from their small cities somewhere in Greece or in other countries and be close, let's say, online with another team.

+ +

We weren't crazy back then. So it was much easier to make these kinds of propositions to a local team. I guess it was convenient, and we had a good match. But already, this investment prepared us a lot in terms of organizing the business, due diligence, taking care of our finance and reporting, and all the stuff, and legal and made us ready to go for a bigger investment later when we needed it and when the time was right.

+ +

CHAD: So from three co-founders in 2014, how large is your team now?

+ +

PANOS: I think with the recent hires, we're about 120 people right now. We are still fully remote. In fact, in the next few weeks, we will just open a small co-working space in Athens where about half of our staff resides. But this is going to be more of a co-working space kind of experience. I think right now; we have people in our team from 16 different nationalities in 11 different countries.

+ +

But still, the majority of the people are based in Greece, so here are the roots of the company. But we are internationalizing fast, getting people everywhere we can find them. People that fit the business, we're happy to bring them on board, and these kinds of remote-first flexible environment that we have is very fitting for some amazing people from all over the world. And they prefer that actually than returning back to an office.

+ +

CHAD: For yourself as a leader, how have you needed to grow or change as your team has scaled so much?

+ +

PANOS: We're still doing that.

+ +

CHAD: [laughs]

+ +

PANOS: It's not just me. It's my co-founders as well, my two co-founders, Fanis and Giorgos. I wouldn't have been able, obviously, to do anything alone, neither any one of us, without having the others. Still to this day, we're very hands-on. We're involved in all the projects. In some cases, we were a bit more reluctant to delegate. But still, the team really appreciates that we're still in the trenches with them, learning, solving problems every day, trying to not give solutions from both ad hoc but be with them, solve problems with them. That's something that they appreciate a lot.

+ +

And obviously, we are still...every day we are transitioning. We started as a team of three people on a side project that was just taking a few hours of our time per week. And this business came to be the biggest part of our lives, spending 12-plus hours every day and more, and weekends, and everything else with a growing team amidst some very difficult conditions like COVID where things were, you know, in our families and our cities, things were blowing up.

+ +

And we had to stay close to our teams and keep delivering a product that was skyrocketing in terms of demand. So we are still learning; that's our motto here in LearnWorlds, getting better every single day, trying to enable our team be more enablers now and better project managers, inspire people in order to help them deliver the best that they can.

+ +

We are lucky to be in a great industry with amazing customers, all of them creative people who create great content. They love their products. They love their own customers. So this is something that helps us have a great mission that our employees also share. So they see that it's not just about the numbers or about getting the MRR or getting the sale or whatever. But they really enjoy helping our customers and helping them create amazing little, online businesses and get their products online.

+ +

Every day we get amazing feedback from our customers, and that really makes people around here very happy. At the end of the day, they go home, and they know that they helped launch another business or two and help people, in some cases, realize their dream of becoming independent, you know, escaping nine-to-five, or helping a coach or a trainer get some amazing reward for the fruit of their labor and the content that they have created with so much work. So this is a great thing to watch. And it's great being around people who enjoy this kind of business and this kind of environment.

+ +

CHAD: Is there anything that when you were starting the company based on your prior experiences, both good or bad, at the other companies that you had worked at along the way in your career or your co-founders’ careers when you said okay, we're starting LearnWorlds. We're starting our own company. We specifically want to not make this mistake or instill this value in our culture that you were very intentional about?

+ +

PANOS: There are probably a lot of things. I'm not sure if I can name one in particular, but we always wanted to create a business that we would love being employees of. So we wanted to be in an environment that we would enjoy being ourselves. That's probably kind of egocentric, like, it was about us. But I think there were some unspoken values in some cases or cases where we would see that no, this is bad; we shouldn't go down that path.

+ +

We didn't want to replicate ourselves and create a company of people who'd look like us and react to the same things that we would. But we always wanted to have an environment that we would feel happy, and we would love to be part of. So far, at that scale of 120, we have managed, I guess, to do that. In many cases, this is also our number one priority.

+ +

Features come and go. People come and go. Customers come and go. But we know that the biggest strength of this company is the minds of the people who work for us. We want them to be happy. We want them to come to work happy every day and bring their best. That is our major priority. And especially in times like that, their mental and physical well-being as well it's a major priority for us.

+ +

And we believe that if we create these conditions of safety and trust, the empowerment and learning as well of constant improvement, we will achieve our goal, and we will have a team that will be working for a product that is going to be better every day and every week.

+ +

And this shows, at the end of the day, this is something that customers can appreciate, either by seeing a new feature in the platform that they love or by receiving some amazing help from one of our customer support reps or an amazing demo from one of our salespeople. This is something that we are lucky still to show everywhere in the company. This is the mentality of the entire company. Hopefully, we'll be able to preserve these kinds of values and attitude as we scale.

+ +

CHAD: That's great. I really wish that for you. Good luck and congratulations on all the success. Thank you so much for coming on the show and sharing your story and your wisdom about scaling the company. If folks want to learn more about LearnWorlds or get in touch with you or follow along, where are all the places that they can do that?

+ +

PANOS: You can always come to our website www.learnworlds.com. Our platform offers a 30-day free trial, no credit cards, no strings attached. If you have any questions around online courses or any ideas about what you could build yourself for your business, come to our website. Join us, and we will be happy to help you out and show you what is possible today.

+ +

CHAD: Great. And you can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Panos Siozos.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Panos Siozos is Co-Founder and CEO of LearnWorlds, an online course platform for creating, selling, and promoting online courses.

+ +

Chad talks with Panos about building e-learning platforms dating back to 1999, providing rich feature sets and catering to customers located in lots of different places, and deciding to stop bootstrapping and take investor money.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giants Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is Panos Siozos, Co-Founder and CEO of LearnWorlds, an online course platform for creating, selling, and promoting online courses. Panos, thank you so much for joining me.

+ +

PANOS: Hi, Chad, and thanks for hosting me.

+ +

CHAD: You have been working on LearnWorlds for a while now. Where did the idea come from?

+ +

PANOS: I guess this has been brewing in our minds, mine and my co-founder's, for many years. We built our very first e-learning platform back in 1999, right after completing our studies in computer science. And we started postgraduate studies in educational technology. So in an academic setting, though, we had built many, many e-learning products, platforms, and authoring tools. And we were always exploring the state of the art.

+ +

And we always had it in the back of our minds the possibility and our obligation, I guess, to create a commercial product at some point and try to get the state of the art of e-learning that we were exploring in the academia and put it at the hands of actual trainers, and teachers, and give them the tools to create the best possible online courses that they could. That was always at the back of our minds.

+ +

And after completing our Ph.D. studies, after working in different jobs and different roles, we got back together at some point in 2012. And at that point, the conditions for e-learning were very, very mature. It was like bandwidth was in abundance. It was easy to create videos. It was easy to distribute videos. Cloud computing made it even easier to create software as a service platforms. And we understood that it was the perfect moment to come together, take our expertise, and try to put it in an amazing product that would be commercial and help all those people out there that wanted to create online courses.

+ +

CHAD: So I think you launched in 2014.

+ +

PANOS: Yes, we spent a couple of years. We started building the platform in 2012 in stealth mode. We were, I guess, traditional engineers. We had this build it, and they will come mentality.

+ +

CHAD: [chuckles]

+ +

PANOS: We had done almost like in the first year almost zero research on customer development and business development. We just had in mind to create the best possible platform that we could, and then obviously, people would just buy it because it's the best. Obviously, things don't always work that way. So we created the platform then we started talking with potential customers.

+ +

We launched commercially in 2014. And this is when we had our very first customers, people who had the online courses. They had the online content. They had audiences, but they didn't have a platform. It seemed a huge burden and a huge task to create an actual platform to deliver and sell their courses. And this is where we came in and started providing our tool as a software as a service solution.

+ +

CHAD: So in 2014, I'm sure that there were other competing products on the market. Today, there are probably even more. What makes LearnWorlds different from all of those or better from those?

+ +

PANOS: In 2014, it was very early, I guess, in online courses. Most people were going to marketplaces like Udemy or Coursera. It was very difficult back then to create your own online school, to own the website. We had people who were either using traditional clunky Jurassic; I would say, learning management systems.

+ +

CHAD: [chuckles]

+ +

PANOS: And they were trying to adapt them for e-commerce and all the stuff, and it was always very difficult to do. Others were trying to duct tape together WordPress sites and plugins and custom codes. And that was something that wasn't scaling very gracefully. I would say after a couple of 100 users, it was almost impossible to maintain sites like that.

+ +

Others were trying to create their own platforms, write code internally or hire a couple of developers. And then a few months or a couple of years and after having spent a couple hundred thousand dollars, they were realizing that this is very difficult to develop a tool like that unless you've done that in the past and you know what you're doing. So it was very timely to bring to the market a product like that.

+ +

What differentiated us from the others and what still differentiates us is that we have an obsessive focus on the learner experience. We're probably the only, I don't want to sound presumptuous, but we're probably the only course platform creators or, let's say, founders or co-founders of a course platform who have actually studied that. And we have PhDs in edtech. So we are bringing lots of our academic background into the platform. And we know that initially, this was even detrimental to growing the platform because, in some ways, the platform was even too complex for what people were expecting and could absorb back then in terms of features.

+ +

But as the years passed by, we managed to find an excellent balance between how powerful the platform can be in terms of amazing design, offering great, interactive, engaging learning experiences, and also offering the ease of use and all the commercial features that users would expect. So we have a deep product with lots of offering affordances.

+ +

For example, people can create amazing interactive videos very easily, just like editing a PowerPoint, I would say. You can just upload a normal video that you shot yourself, perhaps using a mobile phone, and you can convert it into an amazing interactive experience. And this is something very important for the students, the customers that will actually, at the end, consume the content.

+ +

So to this day, the platform is very innovative. We're still participating in research projects, and we're seeing what is the state of the art of e-learning? And we're trying to implement that into the platform, obviously, now with amazing feedback from thousands of customers and millions of end-users. So it's an amazing opportunity to give to the people the things that they actually need and use to create the best possible online courses and sell as many of them as possible.

+ +

CHAD: One of the things, and it speaks right to the value proposition of the product that you use, is that there are so many features that you can have. And so, if you embark on the journey of creating your own platform, it's really easy to look at the surface level of what that looks like and say, "Oh, that's easy."

+ +

PANOS: Yes.

+ +

CHAD: But then, when it comes to other features, you have the ability to make mobile applications on LearnWorlds and those kinds of things. Like, that's a rich feature set that is really difficult to deliver on your own, right?

+ +

PANOS: It's very difficult to deliver on your own, and some things look deceptively simple. And when you actually see what is under the hood, it is very, very complicated to deliver a super user-friendly and easy tool or platform or authoring environment. So the platform is very powerful because people have all these different needs.

+ +

We're talking here this is a platform that can support both the, I don't know, the nice, old lady that wants to sell some knitting courses, and she has a community of a couple of dozen people who follow her and consume her courses, all the way to online schools that run with more than 300,000 users. It's extremely difficult to be able to scale a school to a size like that.

+ +

And in many cases, people might start simple. They might even create a nice, simple user interface with a couple of videos. This is something that everybody believes that they can do. And they can do it initially, but once they have a couple of hundred users, or a couple of thousand users, their success becomes problematic. They cannot keep up with all the demands for something like that. And then they need more features. They need more features for doing their marketing. They need analytics. They need the scale and the reliability that a platform that serves a few thousand users requires. There are all sorts of things that people miss.

+ +

So we believe that you don't necessarily have to reinvent the wheel, especially when there are amazing ready-made wheels out there, white-labeled wheels where you can just go to a platform like ours. And in a couple of days, you can have an amazing online school customized and optimized for your own case study, for your own audience, for your own language, for your own design. The settings that you need to power your own business model, whether it's selling courses on their own, selling memberships, selling subscriptions, bundles of courses, all those different things that look simple on the outside but they require lots of precision to work great and delivering in scale.

+ +

CHAD: So, given the rich feature set, I'm sure that you have a lot of customers located in lots of different places. I'm sure they have different needs, too, different profiles. How do you as a company go about deciding what to work on? And how does the workflow through your organization?

+ +

PANOS: This is always a very interesting task, something that we are doing almost every month. We update our roadmap on a quarterly basis. But every month, we go out and check again the feature requests, and the trends in the market and the industry, and all the things that are happening. We receive hundreds of feature requests from our existing customers every week, and these are being organized and prioritized. And we always try, obviously, to help our own existing customer base. But we work with many partners and other platforms as well to create integrations and to deliver features, and uncover needs that people have today.

+ +

And in the past couple of years, as you can imagine, with COVID, we had to adapt many changes to the new business models and the new ways that people started creating, delivering, and consuming online courses. For example, when COVID started, almost overnight, there was a huge demand for creating and delivering live courses with no pre-recorded videos. That's something that used to be quite frequent feature requests, let's say. Before COVID, we had it in our roadmap. Once we understood what COVID would mean for the industry, almost overnight, we stopped other things that we were doing and started working hard on delivering, let's say, our Zoom integration.

+ +

So in just a matter of a few short weeks, it was super easy for anybody who wanted to teach. You imagine how the situation was amidst the lockdowns. People their businesses were shutting down. They couldn't reach their audiences, their customers. Their revenue streams had ran out. So we brought to the market this integration, and it was super easy for a photography teacher, a yoga teacher, a coach from anywhere to just create an online course, plug in their Zoom account, and be able to deliver courses, either one-on-one, to a small group or even to hundreds of students.

+ +

So we had to adapt as the market was adapting, and the same comes when it comes about business models, ways of getting paid, different payment methods. For example, some European countries...as a European company, we're also very attuned to what our European customers need. In several European countries, credit cards, traditional credit cards like Visa and MasterCard are not the most frequently used methods of digital payments. So we have to work with local payment gateways to provide these kinds of solutions. Also, for taxes, taxes in Europe are way more when you're selling from one country to the other. They’re much more difficult and complex than in the U.S., So we have to adapt to the demands from customers and offer solutions like that.

+ +

So it's always anticipating, seeing what the actual users need but also keeping a large chunk, I would say, space for innovating, bringing to the product things that people don't actually ask for because they don't even know that they could exist and that they could be helpful. And this is where our expertise, I would say, comes into play. Our team is constantly researching trends and other platforms and how people interact with platforms and other tools. And we try to stay ahead of the curve, not just follow what others are doing but be the leaders in this kind of chase.

+ +

And rightly, you mentioned there are dozens of platforms out there. It's great to see so much innovation in so many different platforms. Especially after COVID, I can say that it seems like there is a viral spread of new platforms. We almost see one new platform every week. And it's nice because it seems that the industry is very hot. And there is lots of demand for these kinds of solutions. We do have a head start, and we will continue to improve the product and bring an amazing solution to people who want to use something like that.

+ +

MID-ROLL AD:

+ +

Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future.

+ +

thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices.

+ +

Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff

+ +

CHAD: One of the features that you have is localization, being able to have your content in lots of different languages. How early on did you add that feature?

+ +

PANOS: This is something that we had to do very early on. The first iteration of the platform, before even founding the company when we were just a side project, was built for the Greek market and the Greek language. So that was in a very difficult situation back in 2013, 2014. There was a huge financial crisis in Greece back then.

+ +

So once we had the product ready, we realized that nobody wanted to invest in e-learning. It was a very tough situation to be in. So that's probably one of the best things that happened to us. Because almost overnight, like in day two, we had to go to an existing mature market, which was the U.S. market, where people were willing to test a new platform. They really liked what the platform could do. They were ready to risk a product, a new product that was brought into market by a small ragtag team from the other side of the world. And so we had to adapt to a new language.

+ +

So that was something that came in very early on and was very helpful in dealing with different markets and different localizations, working with different payment gateways, and becoming an international product from very early on. So right now, we have customers in more than 110 countries; even though U.S. is by far our biggest market, almost half of our market is based in the U.S. But we are very willing and able to work with new markets and help them and help people bring their own localizations and their own translations into the platform.

+ +

CHAD: Yeah, that jumped out at me because I've seen other products that don't have that feature. And I think it's in part because a new company started in the United States knows that they have a fairly big addressable market just within the U.S., and they don't necessarily need to support multiple languages. And I thought that, and that's what I heard, was that the fact that you were not in the U.S. compelled you to have localization really early on. You've also mentioned a few other ways in which that has influenced you. How do you think being in Greece and being a European startup has influenced you as a company overall?

+ +

PANOS: This is the DNA and the blueprint of how the company eventually grew. For example, we started in Greece amidst a dire financial crisis. We were, from day one, a remote company because of the conditions of the co-founders. So we happened to be in three different cities, two different countries. And we just wanted to work together. We didn't have any long-term plans of how a company would evolve. So from day one, we became a remote company. So as you can imagine, in the next few years, that gave us...and even when COVID came, that gave us an immense advantage because that's the way we had been working. We knew that full remote was an option from day one.

+ +

The second thing that really also influenced us is that because we were growing in a situation...amidst this financial crisis, we were a bootstrapped company. We didn't have access to any external funding, which obviously made things much more difficult at the beginning. We couldn't get access to funds and invest in marketing very early on and push the platform heavily.

+ +

On the other end, as a bootstrapped company, we developed a mentality of being very resource-efficient, cash-efficient, paying great attention to all of our KPIs and our unit economics, doing lots of unscalable things, as Paul Graham would say, you know, wearing lots of hats, investing a lot in people who didn't have the credentials, let's say, or the experience that one would expect from to hire in a U.S-founded startup.

+ +

So we had to invest in the local people, in the local skills, amazing youth. We're talking here back in 2013, 2014. Youth unemployment in Greece was about 70%. So it was a terrible situation. It's like this meme where people were asked to have experience, but nobody was giving them a chance to develop this work experience. So we invested in people like that. And that's the best thing we did.

+ +

So we're talking about a remote bootstrapped startup with a can-do mentality with access to amazing people, not specialized or skilled, let's say, or experienced in this particular software as a service role but very smart and willing to work and excel and do better for themselves and for the company. So I think that was the recipe that helped the business grow.

+ +

And also, coming from a small market, we had to adapt to a fragmented European market. Europe is a huge market of about 500 million people, a few less now, a few million less now, barring UK. But this is a fragmented market. You don't have a unified market of one language. One currency may be, yes, in most countries, but we're talking different languages, and different tax regimes, and all the staff and different mentality even. So we had to adapt. This is difficult. But also, it gives you the resilience and the flexibility to adapt to all these different cases.

+ +

And then going international was very natural to us. It's not that we started in a small market, and then we're trying to create a foothold in a second market or the third market. From day one, we had to look outward to find the people who would use and dare to use a platform like ours and try to be our best selves and try to give them an amazing product.

+ +

CHAD: Yeah, that's great. You mentioned that you initially bootstrapped. Have you taken investment since then?

+ +

PANOS: Yes, we have. We did a small seed round of about $1.1 million in 2019 with a small local VC. And then last year, about a year ago, we closed a Series A funding round of $32 million with Insight Partners.

+ +

CHAD: That's great. Congratulations. What caused you to make the decision to stop bootstrapping and take an investment in that seed round?

+ +

PANOS: That was the point when we realized that we needed the extra fuel in order to push the pedal. We were seeing that we already had a great product. We were on to something. It would have been too slow to continue working in a bootstrapped mode with a few resources that we had. We wanted to accelerate. We wanted to accelerate hiring, product development, and all this stuff. So we didn't actually need the money back then for the viability of the company, which is actually, I guess, the best reason to raise money and the best time when we don't actually need it.

+ +

So that's how we started. That gave us the extra confidence. It allowed us to bring in a few extra people. We started investing more in hiring professionals that had already done that, who had already experience in SaaS businesses and international businesses. And that gave us a lot more certainty and trust in ourselves to keep growing the product and going further.

+ +

And this last round with Insight Partners...Insight Partners is one of the top VCs in the private equity funds. They also bring in an amazing team of operators who can always jump in and help in case we need something. So it helps us expand our horizons, be more aggressive in our hiring, much more confident about what we can do. And that also has given a great boost to the business and the team.

+ +

CHAD: This idea of acceleration and going faster is an interesting one. I've seen it in our clients as well where, especially if you're in a competitive market, you could have a good growing reasonable business, but if everyone else around you is raising money, raising capital, and accelerating, that can put you back especially if you don't realize it. Do you feel like that was part of what was causing you to want to accelerate?

+ +

PANOS: Yes, yes, definitely. So e-learning is a complex industry, let's say. What we're doing is very competitive because the market is always changing. People demand more. New business models require new features, and everybody wants an all-in-one platform that will keep doing more and more. So you cannot just stand still. It's not like a micro SaaS where you can have a feature the same working for five years, and you can still have people signing up and using that. You have to be ahead. You have to adapt. This is a very fast pacing industry.

+ +

And now there are so many different players from all different industries who look at online courses and content delivery in general in new ways and start approaching from different angles, whether they are marketing tools, or video hosting providers, or email marketing providers, or traditional learning management systems. So there are many people around this online course industry. So you need to have a war chest. You need to bring in experts.

+ +

You need to keep investing in R&D and improving the product and also customer success, making sure that your amazing customers can perform even better, and they can take advantage of all the features in the platform. So you cannot just stand still; that's not an option. You can perhaps get away with it for two to three years. But eventually, the product will fizzle out. We will not be able to compete with what is happening.

+ +

You mentioned all these different platforms coming into the market. You have to stay ahead. And luckily, now, with the recent funding and obviously with the help of our customers, we have all the resources that we needed to implement the vision that we have for the product. All the things that we couldn't do in the past because we were constrained in terms of resources, and time and money, now we are able to innovate much faster, bring many more new features to the platform and to the market, and help people create the best possible online courses.

+ +

CHAD: You mentioned that when you raised that initial seed round, you did it with a local investment company. Was that intentional? I took a peek; the company is Marathon Venture Capital. And they specifically say on their website that they day one partner to Greek tech founders, so they're very focused. [laughs]

+ +

PANOS: Yes, they're very focused. There is a huge network obviously of Greek founders almost everywhere in the world. So they have a deep pool of people to reach out to and a huge network. It was definitely; also there was a parameter of convenience, you know, them being close, being able to communicate easily, having the same kind of mentality and the same kind of experiences. This obviously makes things much more easier. I guess at that point; it would be much more difficult to go from a bootstrapped remote ragtag team to a fully funded company with a traditional, let's say, Silicon Valley-based VC.

+ +

Even explaining back then in 2019 that you are a remote company wasn't easy. It's something that made some people wonder about how serious you are about that. What are your plans going forward? How are you going to hire? How are you going to compete? How are you going to hire people if you don't have these amazing startup offices with the pool tables and all the stuff? But we were saying that it's feasible. You can do it. I mean, you can find the people who want this kind of lifestyle who appreciate this flexibility, who want to be close to their families and work from their small cities somewhere in Greece or in other countries and be close, let's say, online with another team.

+ +

We weren't crazy back then. So it was much easier to make these kinds of propositions to a local team. I guess it was convenient, and we had a good match. But already, this investment prepared us a lot in terms of organizing the business, due diligence, taking care of our finance and reporting, and all the stuff, and legal and made us ready to go for a bigger investment later when we needed it and when the time was right.

+ +

CHAD: So from three co-founders in 2014, how large is your team now?

+ +

PANOS: I think with the recent hires, we're about 120 people right now. We are still fully remote. In fact, in the next few weeks, we will just open a small co-working space in Athens where about half of our staff resides. But this is going to be more of a co-working space kind of experience. I think right now; we have people in our team from 16 different nationalities in 11 different countries.

+ +

But still, the majority of the people are based in Greece, so here are the roots of the company. But we are internationalizing fast, getting people everywhere we can find them. People that fit the business, we're happy to bring them on board, and these kinds of remote-first flexible environment that we have is very fitting for some amazing people from all over the world. And they prefer that actually than returning back to an office.

+ +

CHAD: For yourself as a leader, how have you needed to grow or change as your team has scaled so much?

+ +

PANOS: We're still doing that.

+ +

CHAD: [laughs]

+ +

PANOS: It's not just me. It's my co-founders as well, my two co-founders, Fanis and Giorgos. I wouldn't have been able, obviously, to do anything alone, neither any one of us, without having the others. Still to this day, we're very hands-on. We're involved in all the projects. In some cases, we were a bit more reluctant to delegate. But still, the team really appreciates that we're still in the trenches with them, learning, solving problems every day, trying to not give solutions from both ad hoc but be with them, solve problems with them. That's something that they appreciate a lot.

+ +

And obviously, we are still...every day we are transitioning. We started as a team of three people on a side project that was just taking a few hours of our time per week. And this business came to be the biggest part of our lives, spending 12-plus hours every day and more, and weekends, and everything else with a growing team amidst some very difficult conditions like COVID where things were, you know, in our families and our cities, things were blowing up.

+ +

And we had to stay close to our teams and keep delivering a product that was skyrocketing in terms of demand. So we are still learning; that's our motto here in LearnWorlds, getting better every single day, trying to enable our team be more enablers now and better project managers, inspire people in order to help them deliver the best that they can.

+ +

We are lucky to be in a great industry with amazing customers, all of them creative people who create great content. They love their products. They love their own customers. So this is something that helps us have a great mission that our employees also share. So they see that it's not just about the numbers or about getting the MRR or getting the sale or whatever. But they really enjoy helping our customers and helping them create amazing little, online businesses and get their products online.

+ +

Every day we get amazing feedback from our customers, and that really makes people around here very happy. At the end of the day, they go home, and they know that they helped launch another business or two and help people, in some cases, realize their dream of becoming independent, you know, escaping nine-to-five, or helping a coach or a trainer get some amazing reward for the fruit of their labor and the content that they have created with so much work. So this is a great thing to watch. And it's great being around people who enjoy this kind of business and this kind of environment.

+ +

CHAD: Is there anything that when you were starting the company based on your prior experiences, both good or bad, at the other companies that you had worked at along the way in your career or your co-founders’ careers when you said okay, we're starting LearnWorlds. We're starting our own company. We specifically want to not make this mistake or instill this value in our culture that you were very intentional about?

+ +

PANOS: There are probably a lot of things. I'm not sure if I can name one in particular, but we always wanted to create a business that we would love being employees of. So we wanted to be in an environment that we would enjoy being ourselves. That's probably kind of egocentric, like, it was about us. But I think there were some unspoken values in some cases or cases where we would see that no, this is bad; we shouldn't go down that path.

+ +

We didn't want to replicate ourselves and create a company of people who'd look like us and react to the same things that we would. But we always wanted to have an environment that we would feel happy, and we would love to be part of. So far, at that scale of 120, we have managed, I guess, to do that. In many cases, this is also our number one priority.

+ +

Features come and go. People come and go. Customers come and go. But we know that the biggest strength of this company is the minds of the people who work for us. We want them to be happy. We want them to come to work happy every day and bring their best. That is our major priority. And especially in times like that, their mental and physical well-being as well it's a major priority for us.

+ +

And we believe that if we create these conditions of safety and trust, the empowerment and learning as well of constant improvement, we will achieve our goal, and we will have a team that will be working for a product that is going to be better every day and every week.

+ +

And this shows, at the end of the day, this is something that customers can appreciate, either by seeing a new feature in the platform that they love or by receiving some amazing help from one of our customer support reps or an amazing demo from one of our salespeople. This is something that we are lucky still to show everywhere in the company. This is the mentality of the entire company. Hopefully, we'll be able to preserve these kinds of values and attitude as we scale.

+ +

CHAD: That's great. I really wish that for you. Good luck and congratulations on all the success. Thank you so much for coming on the show and sharing your story and your wisdom about scaling the company. If folks want to learn more about LearnWorlds or get in touch with you or follow along, where are all the places that they can do that?

+ +

PANOS: You can always come to our website www.learnworlds.com. Our platform offers a 30-day free trial, no credit cards, no strings attached. If you have any questions around online courses or any ideas about what you could build yourself for your business, come to our website. Join us, and we will be happy to help you out and show you what is possible today.

+ +

CHAD: Great. And you can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Panos Siozos.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ZJImwvOY + + ]]> + + Chad Pytel + Panos Siozos + + + 429: 5x with Tarush Aggarwal + https://podcast.thoughtbot.com/429 + 8b80369a-c5f1-4c68-b92a-e1939f17ad2f + Thu, 30 Jun 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Tarush Aggarwal is the Founder and CEO of 5X, the modern data stack as a managed service that enables companies to answer business questions without having to worry about building data infrastructure or bringing in the right data engineering team. + +Chad talks with Tarush about the modern data stack movement, choosing things that make sense on behalf of their customers, and building a team culture at a company with a fairly large time zone distribution. + 31:59 + no + + + Tarush Aggarwal is the Founder and CEO of 5X, the modern data stack as a managed service that enables companies to answer business questions without having to worry about building data infrastructure or bringing in the right data engineering team. +Chad talks with Tarush about the modern data stack movement, choosing things that make sense on behalf of their customers, and building a team culture at a company with a fairly large time zone distribution. +5x (https://5x.co/) +Follow 5x on Twitter (https://twitter.com/DataWith5x), Facebook (https://www.facebook.com/DataWith5x), Instagram (https://www.instagram.com/datawith5x/), YouTube (https://www.youtube.com/channel/UCyOHdgLesV3FesXXl9-8V_w), or LinkedIn (https://www.linkedin.com/company/datawith5x). +Follow Tarush on Twitter (https://twitter.com/tarush) or LinkedIn (https://www.linkedin.com/in/tarushaggarwal/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Tarush Aggarwal, the Founder and CEO of 5X, the modern data stack as a managed service that enables companies to answer business questions without having to worry about building data infrastructure or bringing in the right data engineering team. Tarush, thank you for joining me. +TARUSH: Chad, thank you so much for having me on the show. Really looking forward to being here and hopefully adding some value for your listeners. +CHAD: Yes, I'm sure that they will. I think many companies are either thinking about how they build their data infrastructure or thinking about how they leverage data for their business now. So 5X provides a path for them to do that, and I'd love to dive in. How does 5X, like I said in the intro, enable companies to get started without having to worry about building this infrastructure themselves or this team themselves? +TARUSH: Yeah, totally. It's a great question. Just to kind of zoom out for a quick second, the data space has been really hot for a few years now, and there's this area often called the modern data stack, which is really led by a few vendors mainly around this concept of the data warehouse, reporting tools, and modeling, and ingestion. And this is really a new area for the data space, which has really become popular. So you also have, you know, ten years ago, you had Hadoop and Spark, and all of these different data tools, which in general have become less popular, and the modern data stack movement is one of the big movements happening. +So at a macro level, we have this new movement. If you zoom in, this movement happens to be one of the most fragmented movements. So what that means is for each different layer, you have different vendors. And so, even if you want to do something today as simple as building dashboards, you have to first ingest this data. In your average company, you've got [inaudible] at different sources. You need to put it in. You need to then store it, you need to model it, and then you can build a dashboard. +CHAD: You also need to make all the different choices about which ones you're going to choose at every level. +TARUSH: Exactly. At each of these levels, you have multiple billion-dollar companies today competing. So the thing about fragmentation of the space and, you know, I think data along with maybe DevOps and security are probably the most fragmented spaces. The thing about fragmented spaces is that they are great for extremely savvy customers; think of large tech companies who have 100% data teams. But for 90% of businesses, if you want to get value from data, it makes it much harder because you have to sign multiple contracts with these vendors, architecture, set up security. +So what 5X very, very fundamentally is doing is we're business-focused. We allow you, you know, in a month or two, you better go to 5x.co and add your credit card, and you will have business analytics out of the box. And we can help you make some of these decisions as to what are the best vendors for your price points, for your use cases and give you an end-to-end platform so that you aren't worrying about signing these bills and sort of setting it up. You're focused on your business outcome and your business use cases. +CHAD: Where did...I happen to know, but because I did my research for the episode. [laughs] But you were at WeWork leading data at WeWork, right? +TARUSH: Yes. +CHAD: So I imagine you faced this problem and saw this problem firsthand, right? +TARUSH: You know, I've been fortunate that I've spent my career in the data space. So back in the day at Salesforce and now and most recently at WeWork. And companies like this, in general, are aggressively hiring and aggressively growing these teams. So at WeWork, we had 50 people working on stitching together the platform and finding the best vendors, and being involved in that. So at WeWork, we were really focused on building our own version of the platform. +I think what's interesting is ever since I left and especially over the last 24 months, where the sort of startup space has become so active, I'm still getting pinged on LinkedIn like every day or two with companies looking to get started. And over a period of time, you see the trends that everyone is reinventing the wheel. What do I do first? What's the first use case? What infrastructure do I need? How do I set this up? So the idea of this really came less from WeWork, where we had the team and the expertise. It came more from the other 90% of the companies that don't have the resources that WeWork had, at least at that time. +CHAD: So what do your customers of 5X typically look like then? Are there particular industries or data needs? Or on the tech side, on the development side, what do their development teams look like interacting with 5X? +TARUSH: That's a great question. And again, at a macro level, data is a global phenomenon. It's not industry-specific. Now, different industries have different requirements. So obviously, as a consumer, what you need to collect, the tools and infrastructure you need are quite different from a B2B business. So there is this concept that for each vertical, what stack makes sense, and that's, again, something which we can do. Typically, our customers have found some sort of a product-market fit. They have a business, and now they're looking to go scale the business to get to either entering growth phase, or an optimization phase, or a profitability phase. And in each of these phases, data plays a vital role. +So they are at this point where they know that they want to get value from it. They might even have a data team with 4,5,10 people. And they really might have figured out their first use cases and had the basic dashboards. And, inevitably, they come to this question of what now? What do we do now? So that's one large sort of vertical. And then the other one is they want to go do it. They want to go invest in data, but they have no idea how to do it. And in that case, they're looking at us not just the platform, but we also have this concept of on-demand talent. +Today, we're interviewing thousands of data engineers a week. We get to hire the top 1%, and we pre-train them on different stacks. And then, companies can integrate these lead engineers at a weekly level or completely on-demand and use that to go build out the dashboards. We have never thought of replacing data teams for companies. But it's really interesting to see that some of the early-stage companies are using our platform and our on-demand talent to literally do end-to-end data as a service. +CHAD: So at 5X, you're actually providing those team members, those consulting services? +TARUSH: Yeah, so we look at it less from the consultant point of view, you know, a consultant typically you would go, and you have your statement of work, and that's going to be a three-month project, and it might be a fixed price. And sort of inevitably, they're looking to...they don't work with hundreds of thousands of companies, a few of them might, but in general, we work a little bit differently. +So we have this concept of on-demand talent. So we have these engineers who we hire, and we pre-train them and essentially build software to basically allow people to add these engineers on top of the platform and sort of use them. So they work in one-week sprint cycles. It's fully on-demand. So you can have a group of engineers for one week and the next week not have that. And typically, consultants don't work in that way. And we don't really do the statements of work, and here's what's going to happen. +These engineers are sort of put into these things what we call pods, and pods are three engineers and a product manager. And they operate on these one-week sprints. You can use this end-to-end team or these engineering pods to go build out your use cases, which is similar to what a consultant on the services model does, but we do it in more of a platform-first approach. +CHAD: That's really interesting. I've had some guests on before where they talk about doing consulting or doing services on top of the recurring revenue platform that they've built or not doing it because it's not interesting to them or that their investors say like, "Don't get into that TNM business time and materials business. You want to focus on recurring revenue." How have you balanced that in your business? +TARUSH: The reality is that it doesn't matter which vendor you are in the modern data stack space. You might be Snowflake, or you might be Tableau, or you might be Fivetran or DBT. These are just some of the popular ones. Each of these vendors is just one small part of the stack. And what that means is that they don't have a services model and [inaudible] investors happy. +But in reality, it's because they don't have end-to-end stack exposure; you know, there's no company today which knows what their stack looks like. Snowflake doesn't know what their entire stack looks like. I mean, Snowflake [inaudible] its success in engagement because they just want [inaudible] And what 5X is is, you know, we've had to spin these stacks up from scratch for mid-market companies. You'll be able to map your stack. So you might have a few pieces. We can help you see what's missing. +But again, because we have visibility end-to-end, having that services model, if you want to call it, makes a lot of sense because, ultimately, we're focused on adding business value. And no one's doing data for the sake of doing data. And no one is doing it to build a 50-person data team. They're doing it ultimately to enable the business. So given that we have this end-to-end scope, we look at our on-demand talent as a massive value-add of using the 5X platform is that you have this ability to get engineers end-to-end that are pre-trained on the platform. So we like it a lot. And we think it's a competitive advantage for us. +CHAD: How opinionated is the 5X stack, the default stack? Can you make a lot of choices within it? Are you using lots of different things? You already mentioned Snowflake, Tableau. So it sounds like you're choosing the things that make sense on behalf of your customers. +TARUSH: Yeah, so for launch, we're focused on the core BI stack, which is ingestion, storage, monitoring, reporting, and in this stack, also we have picked the best-in-class vendors so Fivetran, Snowflake, DBT, Preset. In some ways, the usual suspects which you think of as you're looking at the stack. Now our goal and really what we're building is this program called the Certified 5X Program, and that's for vendors. And that program allows us to integrate with different partners and do things like account provisioning, configuration, user management, our billing agreement, workflow setup. +And as we integrate with more and more vendors, the idea is to really have a single form for the modern data stack. So, in ingestion, for now, we might be using Fivetran since they're the [inaudible], but the idea is we're also talking to Plausible, and Airbyte, and Stitch, and all of the other vendors. So at some point, we really kind of pick and choose between any of them. So the idea is, again, there could be a set of different stuff for a company, which is extremely budget-conscious, and if you're looking more for enterprise capability to use a different vendor in that same category. +So ultimately, we're enabling customer freedom in the next few months. At launch, we'll have a smaller selection. But as we get into Q4 and as we get into the next year, we have the next 10-15 vendors lined up who are going to be part of the certified 5X program, and that allows us to add more and more optionality in terms of existing categories. And then, we also will focus on adding new categories like reverse ETL, or data lineage, or augmented analytics. +CHAD: I love the idea of being focused for launch, saying these are the biggest things that we need to hit. How long did it take you to get to launch? When did you start working in earnest on 5X and get to a public launch? +TARUSH: We've been working on this since last June. So we're 11 months old now. What we really did initially is go build relationships with these vendors. And the first thing we did is we started off more as a services business where we sort of built this automatic interview process where we were interviewing hundreds of engineers a week and adding these engineers and training them on the platform. +We would go set up the platform for the customer in a semi-automatic manner. So we have been operational. We're probably working with 15-20 customers at this point, but we did it in a sort of semi-automated way. And over the last few months, as we understood more and more what their needs are, we are transitioning to a platform-first company instead of a services-first company. +CHAD: So that means that you were able to be public and start getting customers fairly early on in your journey. It's only been 11 months since you started. And when did you get your first customer? +TARUSH: 11 months ago. +CHAD: [laughs] So at what point did you find investors and raise money and start to build a team? +TARUSH: We've been fortunate enough that we were producing revenue on day one just looking at the services aspect of the business. So we needed a very tiny fundraise back in October, a very small amount. And now that we're getting closer to the platform launch, we might be announcing something soon. +CHAD: What did you take money for if you were revenue-generating? Was there something specific that caused you to take it and that it was for? +TARUSH: So if you kind of zoom out again and look at this whole concept of building out, you know, I think if we focused on services and focused on growing that part of the business organically, there's no real need for that. But the idea now is we're having a 20-person platform team, building out these integrations, building up software for even things like board management, hiring. The main task today is sort of engineering. So we raised capital to double down on the platform vision and become a platform first. +Mid-Roll Ad: +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So, when it comes to building a team, we're talking today, and you're in Bali. Is that where you spend most of your time now? +TARUSH: I wish I could spend more time here. +CHAD: [laughs] +TARUSH: I'm pretty nomadic, which I really like. And I think we were born in COVID...a fun story; I got stuck in Bali for two years. I came here for vacation, and we were locked up. And it's not the worst place in the world to be stuck, and I felt very lucky that it was not somewhere else. So, in general, we started building the pilot while we were still remote. We have folks in 11 countries now. I spent six months of the year around America. That's where our clients are. +About 80% of our business is from American companies today, and then I spend some time in India, where our engineering teams are aggressively growing in the Southeast Asian market. And 5X is a Singapore company. So we spend time in Singapore, and if I have some time, I come back to Bali. But in general, we are pretty nomadic. And I think as part of our culture, and how we attract people, one of our core values is what we call the hammock value where if I can build it or if you can build it while lying on a hammock in some part of the world, we're not interested in going back to an office. +CHAD: With a fairly large time zone distribution of the team, how do you build a culture? How do people work together? Are people shifting their hours? Or do you build a culture of working asynchronously? +TARUSH: We mostly work asynchronously. In general, the engineering teams are based out of India. So engineers who are working on the platform are in the same time zone. In terms of our pods, what's really cool is today, we hire in South America, we hire in Africa, we hire in Southeast Asia, so three distinct time zones. So you have Europe, you have the Americas, and you have the Asian time zone. +And when we assemble these pods, and a pod has got three engineers and a technical project manager, we try and have at least two different time zones in a pod. So at least two of the engineers are in separate time zones, which means that for our customers, they have more around-the-clock support. They have more hours where they can get work done, which is great for productivity. +So, what that means on our side is that we're really good at being able to communicate asynchronously. We have all this flexibility, and with that, in terms of accountability, the way we do it is we have daily updates. Again, it's asynchronous, so you can send that here's what you did, you know, [inaudible] by. At the end of the week, we do Loom videos really sharing what you've done. We sort focus a lot on like agenda -- +CHAD: And Loom is an asynchronous video sharing. People can record videos and share it with everybody. Is that what Loom is? +TARUSH: Yeah, sorry, I should mention. Loom is a great video platform that allows you to screen share, and it's just a really cool screen-sharing tool that we record these asynchronous videos and really ingraining it inside our culture. Everyone at 5X knows the importance of sending these updates and agenda before a call and summaries in a Zoom video. So that's how we are able to do it. +CHAD: One of the things that we've not struggled with but dealt with at thoughtbot is we've started hiring all throughout the Americas, all throughout Europe, Middle East, and Africa. And we've got team members all over the place. And we want to treat people as employees and give them full benefits. And a lot of people want to work for a local entity and have employment laws and everything. But it's a challenge to do that. We don't necessarily want to set up entities in every country. So one strategy is contracting, another is to work with an international PEO or employer of record. How have you managed that? +TARUSH: We use an international agency which allows us to hire in any country. I'm not sure the name of the platform we're using. Karan, our CFO, would know that. +CHAD: [laughs] +TARUSH: But it allows us on a macro level to be able to hire in all these countries as employees, you know, ask if you have the stock program. And it's also allowing us to give healthcare benefits and things like that, which we really want to have for everyone. And when it comes to the engineers on our network, at the moment, we're hiring them full-time as contractors, but again, we want to extend benefits to them and really, in some ways, give them that flexibility. +Do you want to be inside a local jurisdiction where you can have more healthcare benefits and integrations with local governments, you know, employee programs and things like that? Or do you want to take advantage of our culture and be more nomadic? And these are exciting things which we're sort of figuring out now as we [inaudible] some economies of scale around, you know, having this [inaudible] +CHAD: Yeah, that's great. And for what it's worth, that's the route that we've taken as well is to work with an international employer of record who actually employs people locally. And many people don't realize, like, you highlighted health benefits. A lot of countries have national health care. But it's really common, especially in white-collar or tech industry employment there, to augment that with supplemental insurance, which is not very expensive, but it is expected and oftentimes necessary to get the kind of coverage that you want to have. +TARUSH: I think the world is changing. We're becoming remote-first as well. And the two areas which I believe it's going to affect the most is number one, employment and number two, education. It's just a no-brainer that more and more companies are going to emerge in this space, making it easier to hire remotely and provide benefits and, in some ways, build that operating system for remote entrepreneurs. So I'm not sure if the tools today are great. I think they solve the problem for now. But I expect there to be a lot of innovation in this space over the next few years. +CHAD: Well, and I think that the pandemic has pushed that, accelerated that. There are companies now that existed before, but the scale at which they're able to operate now because so many companies have started to go remote and want to employ people everywhere; it's really driving that growth and investment in that area too. And as a result of that, there's going to be a lot of data [laughs] that these companies generate and need to get a handle on. So maybe they'll become customers of 5X, or maybe they already are. +TARUSH: Yeah. If you look in the last ten years, I think the last ten years were all about digital marketing with social and sort of advertising, making it very obvious that if you don't have a web presence, if you don't care about your customers think, and if you don't find ways to attract customers, you're not going to exist. So ten years later and all those companies which didn't set up websites and they didn't figure out customer acquisition online probably don't exist anymore. In the next five years or in the next ten years, a lot of these will get a lot more sophisticated. And certainly, data comes in as a competitive advantage. +So if you're not focusing on how a customer is using your product and how you personalize and being able to compare the way of spending money in terms of your lead acquisition and really, really optimize at it, what you'll face is that it will become difficult to compete because your competition is getting more and more sophisticated. So a lot of the investment in this is really predicated on becoming more efficient at these core groups of things like go-to-market strategy, engagement, optimizing internal operations as a way to find efficiencies which is typically what technology has enabled. +CHAD: Especially small businesses or businesses that are just getting started, if you don't have experience with that, it can feel really overwhelming. And we talked about how 5X by coming to the table with a stack, with a team that can help do that, that's great. And it helps solve that problem. Say that I'm a founder or a CEO, maybe non-technical, and I really am just getting started, but I have a big need; how do I engage with 5X? What's the best way to think about that? And are there things that I might do as a founder that you would recommend, hey, I recognize you can't do everything, but do this, and you'll avoid some pain later on. +TARUSH: We have some customers today who use us pre-product. They don't have a product. They don't have any customers. They have no data. But they use us because when they launch, they want to have the right tracking and visibility and reports and metrics. So I would have never thought someone that [inaudible] 5X. But it kind of makes sense that you want to have the right [inaudible] knowledge. +You have pros and cons. I think the pros of it is instilling the data culture from day one. Data acts as a bridge between engineering and the business, Chad. It just connects the products from like the business goals. So there is an upside in bringing this on earlier on and building that and instilling that into your culture. I think the flip side of it is that if you don't have product-market fit, if you're shooting darts and seeing what works. +And in general, companies at that point are running more on intuition and trying different things to see what sticks. And having systems in place at that scale, very frankly, could also be unnecessary. And at that point, if you're spending $100, you probably want to spend 80-90 of them on bringing out your product and the design that you've got. And I think they'll want to sign to be able to acquire customers, and that sort of shifts then you see the data spending increase. +So again, we're obviously happy to help, and our technical product managers have a lot of experience. They're the ones who have been data leaders that are growing companies and businesses like Uber, WeWork, Alibaba, top tech companies. They've already been data team members, so they've always been part of that growth. So they're good people, the on-demand talent. You have expertise over there from someone who's seen this before. And a few of our early-stage companies leverage these people more and more, but the flipside of it is focusing on actually building a product first. +CHAD: I love that. I think that that's great advice. And so I assume that there are people who come and to your team or you start talking with them, and you say, "You're not ready for us yet." +TARUSH: Yeah, we sort of have done that. We have told folks, you know, Google this, this, and this, and once you have this in place and you're about to go to market, that's the right time to come engage. But at this point, honestly, it might not be the best time for you to start thinking about [inaudible] +CHAD: Focus on improving your user experience, getting new users, making the best product you can. That's really great advice. +TARUSH: On the flip side of that, I think the problem, not the problem, I don't know if it's the word. I think the mistake a lot of companies make is that they actually get into it too late. The typical fallacy is that the founders are sitting in this gold mine of data. We're just going to have a data scientist come, and he or she is going to start generating all these insights, and we're going to be a data-driven company. And the reality of everything in life is that things take time. You can have the stack from day one, and you can have amazing engineers. But it takes time for you to really understand what's happening in your business. +And initially, your data model that's sort of changing because the understanding of the business is changing. Visibility in your data leads to asking better questions. And with asking better questions, you start changing the mental models of what's happening. It takes three iterations before your data model starts to stabilize. And what that means very, very often is that the founder is expecting in three months that the data is going to have a positive ROI and the output the business is getting from the data team is going to be positive. And that's not really how it works. It takes six to nine months. +You'd have reporting in the first month and the first two months. But as you move from reporting to visibility and to actually optimization and using that data as an insight, we think of that as a three-quarter project. So number one, I think companies don't know that, and they expect that it happens much sooner. And number two is also the mindset around I'm looking at data to provide positive ROI within a small duration, which is also, in reality, not how it is. +CHAD: Tarush, that's really great advice, and I hope people take it to heart. If folks want to get in touch with you or follow along with you or learn more about 5X, where are all the places that they can do that? +TARUSH: So our website is 5x.co. Again, that's 5x.co. You can reach out to me at tarush@5x.co. We're also doing a lot of stuff on YouTube. We're doing a lot of podcasts to educate on the data space. We make weekly videos on different topics on our YouTube channel. I'm sure you can just search for 5X. That's another great way to engage with us. +CHAD: Wonderful. You can subscribe to this show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Tarush Aggarwal. + + + Tarush Aggarwal is the Founder and CEO of 5X, the modern data stack as a managed service that enables companies to answer business questions without having to worry about building data infrastructure or bringing in the right data engineering team.

+ +

Chad talks with Tarush about the modern data stack movement, choosing things that make sense on behalf of their customers, and building a team culture at a company with a fairly large time zone distribution.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Tarush Aggarwal, the Founder and CEO of 5X, the modern data stack as a managed service that enables companies to answer business questions without having to worry about building data infrastructure or bringing in the right data engineering team. Tarush, thank you for joining me.

+ +

TARUSH: Chad, thank you so much for having me on the show. Really looking forward to being here and hopefully adding some value for your listeners.

+ +

CHAD: Yes, I'm sure that they will. I think many companies are either thinking about how they build their data infrastructure or thinking about how they leverage data for their business now. So 5X provides a path for them to do that, and I'd love to dive in. How does 5X, like I said in the intro, enable companies to get started without having to worry about building this infrastructure themselves or this team themselves?

+ +

TARUSH: Yeah, totally. It's a great question. Just to kind of zoom out for a quick second, the data space has been really hot for a few years now, and there's this area often called the modern data stack, which is really led by a few vendors mainly around this concept of the data warehouse, reporting tools, and modeling, and ingestion. And this is really a new area for the data space, which has really become popular. So you also have, you know, ten years ago, you had Hadoop and Spark, and all of these different data tools, which in general have become less popular, and the modern data stack movement is one of the big movements happening.

+ +

So at a macro level, we have this new movement. If you zoom in, this movement happens to be one of the most fragmented movements. So what that means is for each different layer, you have different vendors. And so, even if you want to do something today as simple as building dashboards, you have to first ingest this data. In your average company, you've got [inaudible] at different sources. You need to put it in. You need to then store it, you need to model it, and then you can build a dashboard.

+ +

CHAD: You also need to make all the different choices about which ones you're going to choose at every level.

+ +

TARUSH: Exactly. At each of these levels, you have multiple billion-dollar companies today competing. So the thing about fragmentation of the space and, you know, I think data along with maybe DevOps and security are probably the most fragmented spaces. The thing about fragmented spaces is that they are great for extremely savvy customers; think of large tech companies who have 100% data teams. But for 90% of businesses, if you want to get value from data, it makes it much harder because you have to sign multiple contracts with these vendors, architecture, set up security.

+ +

So what 5X very, very fundamentally is doing is we're business-focused. We allow you, you know, in a month or two, you better go to 5x.co and add your credit card, and you will have business analytics out of the box. And we can help you make some of these decisions as to what are the best vendors for your price points, for your use cases and give you an end-to-end platform so that you aren't worrying about signing these bills and sort of setting it up. You're focused on your business outcome and your business use cases.

+ +

CHAD: Where did...I happen to know, but because I did my research for the episode. [laughs] But you were at WeWork leading data at WeWork, right?

+ +

TARUSH: Yes.

+ +

CHAD: So I imagine you faced this problem and saw this problem firsthand, right?

+ +

TARUSH: You know, I've been fortunate that I've spent my career in the data space. So back in the day at Salesforce and now and most recently at WeWork. And companies like this, in general, are aggressively hiring and aggressively growing these teams. So at WeWork, we had 50 people working on stitching together the platform and finding the best vendors, and being involved in that. So at WeWork, we were really focused on building our own version of the platform.

+ +

I think what's interesting is ever since I left and especially over the last 24 months, where the sort of startup space has become so active, I'm still getting pinged on LinkedIn like every day or two with companies looking to get started. And over a period of time, you see the trends that everyone is reinventing the wheel. What do I do first? What's the first use case? What infrastructure do I need? How do I set this up? So the idea of this really came less from WeWork, where we had the team and the expertise. It came more from the other 90% of the companies that don't have the resources that WeWork had, at least at that time.

+ +

CHAD: So what do your customers of 5X typically look like then? Are there particular industries or data needs? Or on the tech side, on the development side, what do their development teams look like interacting with 5X?

+ +

TARUSH: That's a great question. And again, at a macro level, data is a global phenomenon. It's not industry-specific. Now, different industries have different requirements. So obviously, as a consumer, what you need to collect, the tools and infrastructure you need are quite different from a B2B business. So there is this concept that for each vertical, what stack makes sense, and that's, again, something which we can do. Typically, our customers have found some sort of a product-market fit. They have a business, and now they're looking to go scale the business to get to either entering growth phase, or an optimization phase, or a profitability phase. And in each of these phases, data plays a vital role.

+ +

So they are at this point where they know that they want to get value from it. They might even have a data team with 4,5,10 people. And they really might have figured out their first use cases and had the basic dashboards. And, inevitably, they come to this question of what now? What do we do now? So that's one large sort of vertical. And then the other one is they want to go do it. They want to go invest in data, but they have no idea how to do it. And in that case, they're looking at us not just the platform, but we also have this concept of on-demand talent.

+ +

Today, we're interviewing thousands of data engineers a week. We get to hire the top 1%, and we pre-train them on different stacks. And then, companies can integrate these lead engineers at a weekly level or completely on-demand and use that to go build out the dashboards. We have never thought of replacing data teams for companies. But it's really interesting to see that some of the early-stage companies are using our platform and our on-demand talent to literally do end-to-end data as a service.

+ +

CHAD: So at 5X, you're actually providing those team members, those consulting services?

+ +

TARUSH: Yeah, so we look at it less from the consultant point of view, you know, a consultant typically you would go, and you have your statement of work, and that's going to be a three-month project, and it might be a fixed price. And sort of inevitably, they're looking to...they don't work with hundreds of thousands of companies, a few of them might, but in general, we work a little bit differently.

+ +

So we have this concept of on-demand talent. So we have these engineers who we hire, and we pre-train them and essentially build software to basically allow people to add these engineers on top of the platform and sort of use them. So they work in one-week sprint cycles. It's fully on-demand. So you can have a group of engineers for one week and the next week not have that. And typically, consultants don't work in that way. And we don't really do the statements of work, and here's what's going to happen.

+ +

These engineers are sort of put into these things what we call pods, and pods are three engineers and a product manager. And they operate on these one-week sprints. You can use this end-to-end team or these engineering pods to go build out your use cases, which is similar to what a consultant on the services model does, but we do it in more of a platform-first approach.

+ +

CHAD: That's really interesting. I've had some guests on before where they talk about doing consulting or doing services on top of the recurring revenue platform that they've built or not doing it because it's not interesting to them or that their investors say like, "Don't get into that TNM business time and materials business. You want to focus on recurring revenue." How have you balanced that in your business?

+ +

TARUSH: The reality is that it doesn't matter which vendor you are in the modern data stack space. You might be Snowflake, or you might be Tableau, or you might be Fivetran or DBT. These are just some of the popular ones. Each of these vendors is just one small part of the stack. And what that means is that they don't have a services model and [inaudible] investors happy.

+ +

But in reality, it's because they don't have end-to-end stack exposure; you know, there's no company today which knows what their stack looks like. Snowflake doesn't know what their entire stack looks like. I mean, Snowflake [inaudible] its success in engagement because they just want [inaudible] And what 5X is is, you know, we've had to spin these stacks up from scratch for mid-market companies. You'll be able to map your stack. So you might have a few pieces. We can help you see what's missing.

+ +

But again, because we have visibility end-to-end, having that services model, if you want to call it, makes a lot of sense because, ultimately, we're focused on adding business value. And no one's doing data for the sake of doing data. And no one is doing it to build a 50-person data team. They're doing it ultimately to enable the business. So given that we have this end-to-end scope, we look at our on-demand talent as a massive value-add of using the 5X platform is that you have this ability to get engineers end-to-end that are pre-trained on the platform. So we like it a lot. And we think it's a competitive advantage for us.

+ +

CHAD: How opinionated is the 5X stack, the default stack? Can you make a lot of choices within it? Are you using lots of different things? You already mentioned Snowflake, Tableau. So it sounds like you're choosing the things that make sense on behalf of your customers.

+ +

TARUSH: Yeah, so for launch, we're focused on the core BI stack, which is ingestion, storage, monitoring, reporting, and in this stack, also we have picked the best-in-class vendors so Fivetran, Snowflake, DBT, Preset. In some ways, the usual suspects which you think of as you're looking at the stack. Now our goal and really what we're building is this program called the Certified 5X Program, and that's for vendors. And that program allows us to integrate with different partners and do things like account provisioning, configuration, user management, our billing agreement, workflow setup.

+ +

And as we integrate with more and more vendors, the idea is to really have a single form for the modern data stack. So, in ingestion, for now, we might be using Fivetran since they're the [inaudible], but the idea is we're also talking to Plausible, and Airbyte, and Stitch, and all of the other vendors. So at some point, we really kind of pick and choose between any of them. So the idea is, again, there could be a set of different stuff for a company, which is extremely budget-conscious, and if you're looking more for enterprise capability to use a different vendor in that same category.

+ +

So ultimately, we're enabling customer freedom in the next few months. At launch, we'll have a smaller selection. But as we get into Q4 and as we get into the next year, we have the next 10-15 vendors lined up who are going to be part of the certified 5X program, and that allows us to add more and more optionality in terms of existing categories. And then, we also will focus on adding new categories like reverse ETL, or data lineage, or augmented analytics.

+ +

CHAD: I love the idea of being focused for launch, saying these are the biggest things that we need to hit. How long did it take you to get to launch? When did you start working in earnest on 5X and get to a public launch?

+ +

TARUSH: We've been working on this since last June. So we're 11 months old now. What we really did initially is go build relationships with these vendors. And the first thing we did is we started off more as a services business where we sort of built this automatic interview process where we were interviewing hundreds of engineers a week and adding these engineers and training them on the platform.

+ +

We would go set up the platform for the customer in a semi-automatic manner. So we have been operational. We're probably working with 15-20 customers at this point, but we did it in a sort of semi-automated way. And over the last few months, as we understood more and more what their needs are, we are transitioning to a platform-first company instead of a services-first company.

+ +

CHAD: So that means that you were able to be public and start getting customers fairly early on in your journey. It's only been 11 months since you started. And when did you get your first customer?

+ +

TARUSH: 11 months ago.

+ +

CHAD: [laughs] So at what point did you find investors and raise money and start to build a team?

+ +

TARUSH: We've been fortunate enough that we were producing revenue on day one just looking at the services aspect of the business. So we needed a very tiny fundraise back in October, a very small amount. And now that we're getting closer to the platform launch, we might be announcing something soon.

+ +

CHAD: What did you take money for if you were revenue-generating? Was there something specific that caused you to take it and that it was for?

+ +

TARUSH: So if you kind of zoom out again and look at this whole concept of building out, you know, I think if we focused on services and focused on growing that part of the business organically, there's no real need for that. But the idea now is we're having a 20-person platform team, building out these integrations, building up software for even things like board management, hiring. The main task today is sort of engineering. So we raised capital to double down on the platform vision and become a platform first.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So, when it comes to building a team, we're talking today, and you're in Bali. Is that where you spend most of your time now?

+ +

TARUSH: I wish I could spend more time here.

+ +

CHAD: [laughs]

+ +

TARUSH: I'm pretty nomadic, which I really like. And I think we were born in COVID...a fun story; I got stuck in Bali for two years. I came here for vacation, and we were locked up. And it's not the worst place in the world to be stuck, and I felt very lucky that it was not somewhere else. So, in general, we started building the pilot while we were still remote. We have folks in 11 countries now. I spent six months of the year around America. That's where our clients are.

+ +

About 80% of our business is from American companies today, and then I spend some time in India, where our engineering teams are aggressively growing in the Southeast Asian market. And 5X is a Singapore company. So we spend time in Singapore, and if I have some time, I come back to Bali. But in general, we are pretty nomadic. And I think as part of our culture, and how we attract people, one of our core values is what we call the hammock value where if I can build it or if you can build it while lying on a hammock in some part of the world, we're not interested in going back to an office.

+ +

CHAD: With a fairly large time zone distribution of the team, how do you build a culture? How do people work together? Are people shifting their hours? Or do you build a culture of working asynchronously?

+ +

TARUSH: We mostly work asynchronously. In general, the engineering teams are based out of India. So engineers who are working on the platform are in the same time zone. In terms of our pods, what's really cool is today, we hire in South America, we hire in Africa, we hire in Southeast Asia, so three distinct time zones. So you have Europe, you have the Americas, and you have the Asian time zone.

+ +

And when we assemble these pods, and a pod has got three engineers and a technical project manager, we try and have at least two different time zones in a pod. So at least two of the engineers are in separate time zones, which means that for our customers, they have more around-the-clock support. They have more hours where they can get work done, which is great for productivity.

+ +

So, what that means on our side is that we're really good at being able to communicate asynchronously. We have all this flexibility, and with that, in terms of accountability, the way we do it is we have daily updates. Again, it's asynchronous, so you can send that here's what you did, you know, [inaudible] by. At the end of the week, we do Loom videos really sharing what you've done. We sort focus a lot on like agenda --

+ +

CHAD: And Loom is an asynchronous video sharing. People can record videos and share it with everybody. Is that what Loom is?

+ +

TARUSH: Yeah, sorry, I should mention. Loom is a great video platform that allows you to screen share, and it's just a really cool screen-sharing tool that we record these asynchronous videos and really ingraining it inside our culture. Everyone at 5X knows the importance of sending these updates and agenda before a call and summaries in a Zoom video. So that's how we are able to do it.

+ +

CHAD: One of the things that we've not struggled with but dealt with at thoughtbot is we've started hiring all throughout the Americas, all throughout Europe, Middle East, and Africa. And we've got team members all over the place. And we want to treat people as employees and give them full benefits. And a lot of people want to work for a local entity and have employment laws and everything. But it's a challenge to do that. We don't necessarily want to set up entities in every country. So one strategy is contracting, another is to work with an international PEO or employer of record. How have you managed that?

+ +

TARUSH: We use an international agency which allows us to hire in any country. I'm not sure the name of the platform we're using. Karan, our CFO, would know that.

+ +

CHAD: [laughs]

+ +

TARUSH: But it allows us on a macro level to be able to hire in all these countries as employees, you know, ask if you have the stock program. And it's also allowing us to give healthcare benefits and things like that, which we really want to have for everyone. And when it comes to the engineers on our network, at the moment, we're hiring them full-time as contractors, but again, we want to extend benefits to them and really, in some ways, give them that flexibility.

+ +

Do you want to be inside a local jurisdiction where you can have more healthcare benefits and integrations with local governments, you know, employee programs and things like that? Or do you want to take advantage of our culture and be more nomadic? And these are exciting things which we're sort of figuring out now as we [inaudible] some economies of scale around, you know, having this [inaudible]

+ +

CHAD: Yeah, that's great. And for what it's worth, that's the route that we've taken as well is to work with an international employer of record who actually employs people locally. And many people don't realize, like, you highlighted health benefits. A lot of countries have national health care. But it's really common, especially in white-collar or tech industry employment there, to augment that with supplemental insurance, which is not very expensive, but it is expected and oftentimes necessary to get the kind of coverage that you want to have.

+ +

TARUSH: I think the world is changing. We're becoming remote-first as well. And the two areas which I believe it's going to affect the most is number one, employment and number two, education. It's just a no-brainer that more and more companies are going to emerge in this space, making it easier to hire remotely and provide benefits and, in some ways, build that operating system for remote entrepreneurs. So I'm not sure if the tools today are great. I think they solve the problem for now. But I expect there to be a lot of innovation in this space over the next few years.

+ +

CHAD: Well, and I think that the pandemic has pushed that, accelerated that. There are companies now that existed before, but the scale at which they're able to operate now because so many companies have started to go remote and want to employ people everywhere; it's really driving that growth and investment in that area too. And as a result of that, there's going to be a lot of data [laughs] that these companies generate and need to get a handle on. So maybe they'll become customers of 5X, or maybe they already are.

+ +

TARUSH: Yeah. If you look in the last ten years, I think the last ten years were all about digital marketing with social and sort of advertising, making it very obvious that if you don't have a web presence, if you don't care about your customers think, and if you don't find ways to attract customers, you're not going to exist. So ten years later and all those companies which didn't set up websites and they didn't figure out customer acquisition online probably don't exist anymore. In the next five years or in the next ten years, a lot of these will get a lot more sophisticated. And certainly, data comes in as a competitive advantage.

+ +

So if you're not focusing on how a customer is using your product and how you personalize and being able to compare the way of spending money in terms of your lead acquisition and really, really optimize at it, what you'll face is that it will become difficult to compete because your competition is getting more and more sophisticated. So a lot of the investment in this is really predicated on becoming more efficient at these core groups of things like go-to-market strategy, engagement, optimizing internal operations as a way to find efficiencies which is typically what technology has enabled.

+ +

CHAD: Especially small businesses or businesses that are just getting started, if you don't have experience with that, it can feel really overwhelming. And we talked about how 5X by coming to the table with a stack, with a team that can help do that, that's great. And it helps solve that problem. Say that I'm a founder or a CEO, maybe non-technical, and I really am just getting started, but I have a big need; how do I engage with 5X? What's the best way to think about that? And are there things that I might do as a founder that you would recommend, hey, I recognize you can't do everything, but do this, and you'll avoid some pain later on.

+ +

TARUSH: We have some customers today who use us pre-product. They don't have a product. They don't have any customers. They have no data. But they use us because when they launch, they want to have the right tracking and visibility and reports and metrics. So I would have never thought someone that [inaudible] 5X. But it kind of makes sense that you want to have the right [inaudible] knowledge.

+ +

You have pros and cons. I think the pros of it is instilling the data culture from day one. Data acts as a bridge between engineering and the business, Chad. It just connects the products from like the business goals. So there is an upside in bringing this on earlier on and building that and instilling that into your culture. I think the flip side of it is that if you don't have product-market fit, if you're shooting darts and seeing what works.

+ +

And in general, companies at that point are running more on intuition and trying different things to see what sticks. And having systems in place at that scale, very frankly, could also be unnecessary. And at that point, if you're spending $100, you probably want to spend 80-90 of them on bringing out your product and the design that you've got. And I think they'll want to sign to be able to acquire customers, and that sort of shifts then you see the data spending increase.

+ +

So again, we're obviously happy to help, and our technical product managers have a lot of experience. They're the ones who have been data leaders that are growing companies and businesses like Uber, WeWork, Alibaba, top tech companies. They've already been data team members, so they've always been part of that growth. So they're good people, the on-demand talent. You have expertise over there from someone who's seen this before. And a few of our early-stage companies leverage these people more and more, but the flipside of it is focusing on actually building a product first.

+ +

CHAD: I love that. I think that that's great advice. And so I assume that there are people who come and to your team or you start talking with them, and you say, "You're not ready for us yet."

+ +

TARUSH: Yeah, we sort of have done that. We have told folks, you know, Google this, this, and this, and once you have this in place and you're about to go to market, that's the right time to come engage. But at this point, honestly, it might not be the best time for you to start thinking about [inaudible]

+ +

CHAD: Focus on improving your user experience, getting new users, making the best product you can. That's really great advice.

+ +

TARUSH: On the flip side of that, I think the problem, not the problem, I don't know if it's the word. I think the mistake a lot of companies make is that they actually get into it too late. The typical fallacy is that the founders are sitting in this gold mine of data. We're just going to have a data scientist come, and he or she is going to start generating all these insights, and we're going to be a data-driven company. And the reality of everything in life is that things take time. You can have the stack from day one, and you can have amazing engineers. But it takes time for you to really understand what's happening in your business.

+ +

And initially, your data model that's sort of changing because the understanding of the business is changing. Visibility in your data leads to asking better questions. And with asking better questions, you start changing the mental models of what's happening. It takes three iterations before your data model starts to stabilize. And what that means very, very often is that the founder is expecting in three months that the data is going to have a positive ROI and the output the business is getting from the data team is going to be positive. And that's not really how it works. It takes six to nine months.

+ +

You'd have reporting in the first month and the first two months. But as you move from reporting to visibility and to actually optimization and using that data as an insight, we think of that as a three-quarter project. So number one, I think companies don't know that, and they expect that it happens much sooner. And number two is also the mindset around I'm looking at data to provide positive ROI within a small duration, which is also, in reality, not how it is.

+ +

CHAD: Tarush, that's really great advice, and I hope people take it to heart. If folks want to get in touch with you or follow along with you or learn more about 5X, where are all the places that they can do that?

+ +

TARUSH: So our website is 5x.co. Again, that's 5x.co. You can reach out to me at tarush@5x.co. We're also doing a lot of stuff on YouTube. We're doing a lot of podcasts to educate on the data space. We make weekly videos on different topics on our YouTube channel. I'm sure you can just search for 5X. That's another great way to engage with us.

+ +

CHAD: Wonderful. You can subscribe to this show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Tarush Aggarwal.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Tarush Aggarwal is the Founder and CEO of 5X, the modern data stack as a managed service that enables companies to answer business questions without having to worry about building data infrastructure or bringing in the right data engineering team.

+ +

Chad talks with Tarush about the modern data stack movement, choosing things that make sense on behalf of their customers, and building a team culture at a company with a fairly large time zone distribution.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Tarush Aggarwal, the Founder and CEO of 5X, the modern data stack as a managed service that enables companies to answer business questions without having to worry about building data infrastructure or bringing in the right data engineering team. Tarush, thank you for joining me.

+ +

TARUSH: Chad, thank you so much for having me on the show. Really looking forward to being here and hopefully adding some value for your listeners.

+ +

CHAD: Yes, I'm sure that they will. I think many companies are either thinking about how they build their data infrastructure or thinking about how they leverage data for their business now. So 5X provides a path for them to do that, and I'd love to dive in. How does 5X, like I said in the intro, enable companies to get started without having to worry about building this infrastructure themselves or this team themselves?

+ +

TARUSH: Yeah, totally. It's a great question. Just to kind of zoom out for a quick second, the data space has been really hot for a few years now, and there's this area often called the modern data stack, which is really led by a few vendors mainly around this concept of the data warehouse, reporting tools, and modeling, and ingestion. And this is really a new area for the data space, which has really become popular. So you also have, you know, ten years ago, you had Hadoop and Spark, and all of these different data tools, which in general have become less popular, and the modern data stack movement is one of the big movements happening.

+ +

So at a macro level, we have this new movement. If you zoom in, this movement happens to be one of the most fragmented movements. So what that means is for each different layer, you have different vendors. And so, even if you want to do something today as simple as building dashboards, you have to first ingest this data. In your average company, you've got [inaudible] at different sources. You need to put it in. You need to then store it, you need to model it, and then you can build a dashboard.

+ +

CHAD: You also need to make all the different choices about which ones you're going to choose at every level.

+ +

TARUSH: Exactly. At each of these levels, you have multiple billion-dollar companies today competing. So the thing about fragmentation of the space and, you know, I think data along with maybe DevOps and security are probably the most fragmented spaces. The thing about fragmented spaces is that they are great for extremely savvy customers; think of large tech companies who have 100% data teams. But for 90% of businesses, if you want to get value from data, it makes it much harder because you have to sign multiple contracts with these vendors, architecture, set up security.

+ +

So what 5X very, very fundamentally is doing is we're business-focused. We allow you, you know, in a month or two, you better go to 5x.co and add your credit card, and you will have business analytics out of the box. And we can help you make some of these decisions as to what are the best vendors for your price points, for your use cases and give you an end-to-end platform so that you aren't worrying about signing these bills and sort of setting it up. You're focused on your business outcome and your business use cases.

+ +

CHAD: Where did...I happen to know, but because I did my research for the episode. [laughs] But you were at WeWork leading data at WeWork, right?

+ +

TARUSH: Yes.

+ +

CHAD: So I imagine you faced this problem and saw this problem firsthand, right?

+ +

TARUSH: You know, I've been fortunate that I've spent my career in the data space. So back in the day at Salesforce and now and most recently at WeWork. And companies like this, in general, are aggressively hiring and aggressively growing these teams. So at WeWork, we had 50 people working on stitching together the platform and finding the best vendors, and being involved in that. So at WeWork, we were really focused on building our own version of the platform.

+ +

I think what's interesting is ever since I left and especially over the last 24 months, where the sort of startup space has become so active, I'm still getting pinged on LinkedIn like every day or two with companies looking to get started. And over a period of time, you see the trends that everyone is reinventing the wheel. What do I do first? What's the first use case? What infrastructure do I need? How do I set this up? So the idea of this really came less from WeWork, where we had the team and the expertise. It came more from the other 90% of the companies that don't have the resources that WeWork had, at least at that time.

+ +

CHAD: So what do your customers of 5X typically look like then? Are there particular industries or data needs? Or on the tech side, on the development side, what do their development teams look like interacting with 5X?

+ +

TARUSH: That's a great question. And again, at a macro level, data is a global phenomenon. It's not industry-specific. Now, different industries have different requirements. So obviously, as a consumer, what you need to collect, the tools and infrastructure you need are quite different from a B2B business. So there is this concept that for each vertical, what stack makes sense, and that's, again, something which we can do. Typically, our customers have found some sort of a product-market fit. They have a business, and now they're looking to go scale the business to get to either entering growth phase, or an optimization phase, or a profitability phase. And in each of these phases, data plays a vital role.

+ +

So they are at this point where they know that they want to get value from it. They might even have a data team with 4,5,10 people. And they really might have figured out their first use cases and had the basic dashboards. And, inevitably, they come to this question of what now? What do we do now? So that's one large sort of vertical. And then the other one is they want to go do it. They want to go invest in data, but they have no idea how to do it. And in that case, they're looking at us not just the platform, but we also have this concept of on-demand talent.

+ +

Today, we're interviewing thousands of data engineers a week. We get to hire the top 1%, and we pre-train them on different stacks. And then, companies can integrate these lead engineers at a weekly level or completely on-demand and use that to go build out the dashboards. We have never thought of replacing data teams for companies. But it's really interesting to see that some of the early-stage companies are using our platform and our on-demand talent to literally do end-to-end data as a service.

+ +

CHAD: So at 5X, you're actually providing those team members, those consulting services?

+ +

TARUSH: Yeah, so we look at it less from the consultant point of view, you know, a consultant typically you would go, and you have your statement of work, and that's going to be a three-month project, and it might be a fixed price. And sort of inevitably, they're looking to...they don't work with hundreds of thousands of companies, a few of them might, but in general, we work a little bit differently.

+ +

So we have this concept of on-demand talent. So we have these engineers who we hire, and we pre-train them and essentially build software to basically allow people to add these engineers on top of the platform and sort of use them. So they work in one-week sprint cycles. It's fully on-demand. So you can have a group of engineers for one week and the next week not have that. And typically, consultants don't work in that way. And we don't really do the statements of work, and here's what's going to happen.

+ +

These engineers are sort of put into these things what we call pods, and pods are three engineers and a product manager. And they operate on these one-week sprints. You can use this end-to-end team or these engineering pods to go build out your use cases, which is similar to what a consultant on the services model does, but we do it in more of a platform-first approach.

+ +

CHAD: That's really interesting. I've had some guests on before where they talk about doing consulting or doing services on top of the recurring revenue platform that they've built or not doing it because it's not interesting to them or that their investors say like, "Don't get into that TNM business time and materials business. You want to focus on recurring revenue." How have you balanced that in your business?

+ +

TARUSH: The reality is that it doesn't matter which vendor you are in the modern data stack space. You might be Snowflake, or you might be Tableau, or you might be Fivetran or DBT. These are just some of the popular ones. Each of these vendors is just one small part of the stack. And what that means is that they don't have a services model and [inaudible] investors happy.

+ +

But in reality, it's because they don't have end-to-end stack exposure; you know, there's no company today which knows what their stack looks like. Snowflake doesn't know what their entire stack looks like. I mean, Snowflake [inaudible] its success in engagement because they just want [inaudible] And what 5X is is, you know, we've had to spin these stacks up from scratch for mid-market companies. You'll be able to map your stack. So you might have a few pieces. We can help you see what's missing.

+ +

But again, because we have visibility end-to-end, having that services model, if you want to call it, makes a lot of sense because, ultimately, we're focused on adding business value. And no one's doing data for the sake of doing data. And no one is doing it to build a 50-person data team. They're doing it ultimately to enable the business. So given that we have this end-to-end scope, we look at our on-demand talent as a massive value-add of using the 5X platform is that you have this ability to get engineers end-to-end that are pre-trained on the platform. So we like it a lot. And we think it's a competitive advantage for us.

+ +

CHAD: How opinionated is the 5X stack, the default stack? Can you make a lot of choices within it? Are you using lots of different things? You already mentioned Snowflake, Tableau. So it sounds like you're choosing the things that make sense on behalf of your customers.

+ +

TARUSH: Yeah, so for launch, we're focused on the core BI stack, which is ingestion, storage, monitoring, reporting, and in this stack, also we have picked the best-in-class vendors so Fivetran, Snowflake, DBT, Preset. In some ways, the usual suspects which you think of as you're looking at the stack. Now our goal and really what we're building is this program called the Certified 5X Program, and that's for vendors. And that program allows us to integrate with different partners and do things like account provisioning, configuration, user management, our billing agreement, workflow setup.

+ +

And as we integrate with more and more vendors, the idea is to really have a single form for the modern data stack. So, in ingestion, for now, we might be using Fivetran since they're the [inaudible], but the idea is we're also talking to Plausible, and Airbyte, and Stitch, and all of the other vendors. So at some point, we really kind of pick and choose between any of them. So the idea is, again, there could be a set of different stuff for a company, which is extremely budget-conscious, and if you're looking more for enterprise capability to use a different vendor in that same category.

+ +

So ultimately, we're enabling customer freedom in the next few months. At launch, we'll have a smaller selection. But as we get into Q4 and as we get into the next year, we have the next 10-15 vendors lined up who are going to be part of the certified 5X program, and that allows us to add more and more optionality in terms of existing categories. And then, we also will focus on adding new categories like reverse ETL, or data lineage, or augmented analytics.

+ +

CHAD: I love the idea of being focused for launch, saying these are the biggest things that we need to hit. How long did it take you to get to launch? When did you start working in earnest on 5X and get to a public launch?

+ +

TARUSH: We've been working on this since last June. So we're 11 months old now. What we really did initially is go build relationships with these vendors. And the first thing we did is we started off more as a services business where we sort of built this automatic interview process where we were interviewing hundreds of engineers a week and adding these engineers and training them on the platform.

+ +

We would go set up the platform for the customer in a semi-automatic manner. So we have been operational. We're probably working with 15-20 customers at this point, but we did it in a sort of semi-automated way. And over the last few months, as we understood more and more what their needs are, we are transitioning to a platform-first company instead of a services-first company.

+ +

CHAD: So that means that you were able to be public and start getting customers fairly early on in your journey. It's only been 11 months since you started. And when did you get your first customer?

+ +

TARUSH: 11 months ago.

+ +

CHAD: [laughs] So at what point did you find investors and raise money and start to build a team?

+ +

TARUSH: We've been fortunate enough that we were producing revenue on day one just looking at the services aspect of the business. So we needed a very tiny fundraise back in October, a very small amount. And now that we're getting closer to the platform launch, we might be announcing something soon.

+ +

CHAD: What did you take money for if you were revenue-generating? Was there something specific that caused you to take it and that it was for?

+ +

TARUSH: So if you kind of zoom out again and look at this whole concept of building out, you know, I think if we focused on services and focused on growing that part of the business organically, there's no real need for that. But the idea now is we're having a 20-person platform team, building out these integrations, building up software for even things like board management, hiring. The main task today is sort of engineering. So we raised capital to double down on the platform vision and become a platform first.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So, when it comes to building a team, we're talking today, and you're in Bali. Is that where you spend most of your time now?

+ +

TARUSH: I wish I could spend more time here.

+ +

CHAD: [laughs]

+ +

TARUSH: I'm pretty nomadic, which I really like. And I think we were born in COVID...a fun story; I got stuck in Bali for two years. I came here for vacation, and we were locked up. And it's not the worst place in the world to be stuck, and I felt very lucky that it was not somewhere else. So, in general, we started building the pilot while we were still remote. We have folks in 11 countries now. I spent six months of the year around America. That's where our clients are.

+ +

About 80% of our business is from American companies today, and then I spend some time in India, where our engineering teams are aggressively growing in the Southeast Asian market. And 5X is a Singapore company. So we spend time in Singapore, and if I have some time, I come back to Bali. But in general, we are pretty nomadic. And I think as part of our culture, and how we attract people, one of our core values is what we call the hammock value where if I can build it or if you can build it while lying on a hammock in some part of the world, we're not interested in going back to an office.

+ +

CHAD: With a fairly large time zone distribution of the team, how do you build a culture? How do people work together? Are people shifting their hours? Or do you build a culture of working asynchronously?

+ +

TARUSH: We mostly work asynchronously. In general, the engineering teams are based out of India. So engineers who are working on the platform are in the same time zone. In terms of our pods, what's really cool is today, we hire in South America, we hire in Africa, we hire in Southeast Asia, so three distinct time zones. So you have Europe, you have the Americas, and you have the Asian time zone.

+ +

And when we assemble these pods, and a pod has got three engineers and a technical project manager, we try and have at least two different time zones in a pod. So at least two of the engineers are in separate time zones, which means that for our customers, they have more around-the-clock support. They have more hours where they can get work done, which is great for productivity.

+ +

So, what that means on our side is that we're really good at being able to communicate asynchronously. We have all this flexibility, and with that, in terms of accountability, the way we do it is we have daily updates. Again, it's asynchronous, so you can send that here's what you did, you know, [inaudible] by. At the end of the week, we do Loom videos really sharing what you've done. We sort focus a lot on like agenda --

+ +

CHAD: And Loom is an asynchronous video sharing. People can record videos and share it with everybody. Is that what Loom is?

+ +

TARUSH: Yeah, sorry, I should mention. Loom is a great video platform that allows you to screen share, and it's just a really cool screen-sharing tool that we record these asynchronous videos and really ingraining it inside our culture. Everyone at 5X knows the importance of sending these updates and agenda before a call and summaries in a Zoom video. So that's how we are able to do it.

+ +

CHAD: One of the things that we've not struggled with but dealt with at thoughtbot is we've started hiring all throughout the Americas, all throughout Europe, Middle East, and Africa. And we've got team members all over the place. And we want to treat people as employees and give them full benefits. And a lot of people want to work for a local entity and have employment laws and everything. But it's a challenge to do that. We don't necessarily want to set up entities in every country. So one strategy is contracting, another is to work with an international PEO or employer of record. How have you managed that?

+ +

TARUSH: We use an international agency which allows us to hire in any country. I'm not sure the name of the platform we're using. Karan, our CFO, would know that.

+ +

CHAD: [laughs]

+ +

TARUSH: But it allows us on a macro level to be able to hire in all these countries as employees, you know, ask if you have the stock program. And it's also allowing us to give healthcare benefits and things like that, which we really want to have for everyone. And when it comes to the engineers on our network, at the moment, we're hiring them full-time as contractors, but again, we want to extend benefits to them and really, in some ways, give them that flexibility.

+ +

Do you want to be inside a local jurisdiction where you can have more healthcare benefits and integrations with local governments, you know, employee programs and things like that? Or do you want to take advantage of our culture and be more nomadic? And these are exciting things which we're sort of figuring out now as we [inaudible] some economies of scale around, you know, having this [inaudible]

+ +

CHAD: Yeah, that's great. And for what it's worth, that's the route that we've taken as well is to work with an international employer of record who actually employs people locally. And many people don't realize, like, you highlighted health benefits. A lot of countries have national health care. But it's really common, especially in white-collar or tech industry employment there, to augment that with supplemental insurance, which is not very expensive, but it is expected and oftentimes necessary to get the kind of coverage that you want to have.

+ +

TARUSH: I think the world is changing. We're becoming remote-first as well. And the two areas which I believe it's going to affect the most is number one, employment and number two, education. It's just a no-brainer that more and more companies are going to emerge in this space, making it easier to hire remotely and provide benefits and, in some ways, build that operating system for remote entrepreneurs. So I'm not sure if the tools today are great. I think they solve the problem for now. But I expect there to be a lot of innovation in this space over the next few years.

+ +

CHAD: Well, and I think that the pandemic has pushed that, accelerated that. There are companies now that existed before, but the scale at which they're able to operate now because so many companies have started to go remote and want to employ people everywhere; it's really driving that growth and investment in that area too. And as a result of that, there's going to be a lot of data [laughs] that these companies generate and need to get a handle on. So maybe they'll become customers of 5X, or maybe they already are.

+ +

TARUSH: Yeah. If you look in the last ten years, I think the last ten years were all about digital marketing with social and sort of advertising, making it very obvious that if you don't have a web presence, if you don't care about your customers think, and if you don't find ways to attract customers, you're not going to exist. So ten years later and all those companies which didn't set up websites and they didn't figure out customer acquisition online probably don't exist anymore. In the next five years or in the next ten years, a lot of these will get a lot more sophisticated. And certainly, data comes in as a competitive advantage.

+ +

So if you're not focusing on how a customer is using your product and how you personalize and being able to compare the way of spending money in terms of your lead acquisition and really, really optimize at it, what you'll face is that it will become difficult to compete because your competition is getting more and more sophisticated. So a lot of the investment in this is really predicated on becoming more efficient at these core groups of things like go-to-market strategy, engagement, optimizing internal operations as a way to find efficiencies which is typically what technology has enabled.

+ +

CHAD: Especially small businesses or businesses that are just getting started, if you don't have experience with that, it can feel really overwhelming. And we talked about how 5X by coming to the table with a stack, with a team that can help do that, that's great. And it helps solve that problem. Say that I'm a founder or a CEO, maybe non-technical, and I really am just getting started, but I have a big need; how do I engage with 5X? What's the best way to think about that? And are there things that I might do as a founder that you would recommend, hey, I recognize you can't do everything, but do this, and you'll avoid some pain later on.

+ +

TARUSH: We have some customers today who use us pre-product. They don't have a product. They don't have any customers. They have no data. But they use us because when they launch, they want to have the right tracking and visibility and reports and metrics. So I would have never thought someone that [inaudible] 5X. But it kind of makes sense that you want to have the right [inaudible] knowledge.

+ +

You have pros and cons. I think the pros of it is instilling the data culture from day one. Data acts as a bridge between engineering and the business, Chad. It just connects the products from like the business goals. So there is an upside in bringing this on earlier on and building that and instilling that into your culture. I think the flip side of it is that if you don't have product-market fit, if you're shooting darts and seeing what works.

+ +

And in general, companies at that point are running more on intuition and trying different things to see what sticks. And having systems in place at that scale, very frankly, could also be unnecessary. And at that point, if you're spending $100, you probably want to spend 80-90 of them on bringing out your product and the design that you've got. And I think they'll want to sign to be able to acquire customers, and that sort of shifts then you see the data spending increase.

+ +

So again, we're obviously happy to help, and our technical product managers have a lot of experience. They're the ones who have been data leaders that are growing companies and businesses like Uber, WeWork, Alibaba, top tech companies. They've already been data team members, so they've always been part of that growth. So they're good people, the on-demand talent. You have expertise over there from someone who's seen this before. And a few of our early-stage companies leverage these people more and more, but the flipside of it is focusing on actually building a product first.

+ +

CHAD: I love that. I think that that's great advice. And so I assume that there are people who come and to your team or you start talking with them, and you say, "You're not ready for us yet."

+ +

TARUSH: Yeah, we sort of have done that. We have told folks, you know, Google this, this, and this, and once you have this in place and you're about to go to market, that's the right time to come engage. But at this point, honestly, it might not be the best time for you to start thinking about [inaudible]

+ +

CHAD: Focus on improving your user experience, getting new users, making the best product you can. That's really great advice.

+ +

TARUSH: On the flip side of that, I think the problem, not the problem, I don't know if it's the word. I think the mistake a lot of companies make is that they actually get into it too late. The typical fallacy is that the founders are sitting in this gold mine of data. We're just going to have a data scientist come, and he or she is going to start generating all these insights, and we're going to be a data-driven company. And the reality of everything in life is that things take time. You can have the stack from day one, and you can have amazing engineers. But it takes time for you to really understand what's happening in your business.

+ +

And initially, your data model that's sort of changing because the understanding of the business is changing. Visibility in your data leads to asking better questions. And with asking better questions, you start changing the mental models of what's happening. It takes three iterations before your data model starts to stabilize. And what that means very, very often is that the founder is expecting in three months that the data is going to have a positive ROI and the output the business is getting from the data team is going to be positive. And that's not really how it works. It takes six to nine months.

+ +

You'd have reporting in the first month and the first two months. But as you move from reporting to visibility and to actually optimization and using that data as an insight, we think of that as a three-quarter project. So number one, I think companies don't know that, and they expect that it happens much sooner. And number two is also the mindset around I'm looking at data to provide positive ROI within a small duration, which is also, in reality, not how it is.

+ +

CHAD: Tarush, that's really great advice, and I hope people take it to heart. If folks want to get in touch with you or follow along with you or learn more about 5X, where are all the places that they can do that?

+ +

TARUSH: So our website is 5x.co. Again, that's 5x.co. You can reach out to me at tarush@5x.co. We're also doing a lot of stuff on YouTube. We're doing a lot of podcasts to educate on the data space. We make weekly videos on different topics on our YouTube channel. I'm sure you can just search for 5X. That's another great way to engage with us.

+ +

CHAD: Wonderful. You can subscribe to this show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Tarush Aggarwal.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hocRvyCB + + ]]> + + Chad Pytel + Tarush Aggarwal + + + 428: LGBT YouthLink of CenterLink with Deborah Levine + https://podcast.thoughtbot.com/428 + ee162353-1b22-4aaf-8ca3-d5cee7288bff + Thu, 23 Jun 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Deborah Levine is the Director of LGBT YouthLink at CenterLink, which supports, strengthens, and connects LGBT centers. + +Chad talks with Deborah about working on something new called imi: a free digital research-backed mental health tool intended to support and help LGBTQ+ teens explore and affirm their identity and learn practical ways to cope with their sexual and gender minority stress, founding Q Chat Space, a digital LGBTQ+ center where teens join live-chat, professionally facilitated, online support groups, and how over the time that she's been doing work in LGBTQ+ spaces products and online interaction have changed and evolved. + 25:00 + no + + + Deborah Levine is the Director of LGBT YouthLink at CenterLink, which supports, strengthens, and connects LGBT centers. +Chad talks with Deborah about working on something new called imi: a free digital research-backed mental health tool intended to support and help LGBTQ+ teens explore and affirm their identity and learn practical ways to cope with their sexual and gender minority stress, founding Q Chat Space, a digital LGBTQ+ center where teens join live-chat, professionally facilitated, online support groups, and how over the time that she's been doing work in LGBTQ+ spaces products and online interaction have changed and evolved. +CenterLink (https://www.lgbtcenters.org/) +Follow CenterLink on Twitter (https://twitter.com/CenterLink), Facebook (https://www.facebook.com/CenterLink), Instagram (https://www.instagram.com/lgbtcenterlink/), YouTube (https://www.youtube.com/channel/UCPvnzC7fGKBYKj9p4YlMGNw), or LinkedIn (https://www.linkedin.com/company/2129279/). +LGBT YouthLink (https://www.lgbtcenters.org/Programs/YouthLink) +Q Chat Space (https://www.qchatspace.org/) +HopeLab (https://hopelab.org/) +Follow Deborah on LinkedIn (https://www.linkedin.com/in/deborah-s-levine/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me, today is Deborah Levine, Director of LGBT YouthLink at CenterLink, which supports, strengthens, and connects LGBT centers. Deborah, thank you so much for joining me. +DEBORAH: Thanks, Chad. I appreciate you inviting me. +CHAD: So I was first introduced to you and to CenterLink through the Q Chat Space product. And that's still going, right? +DEBORAH: Yeah. +CHAD: But you're working on something new called imi. +DEBORAH: Mm-hmm. We actually just launched imi on June 1st. +CHAD: Congratulations on the launch. +DEBORAH: Thank you. Yes, it went pretty smoothly. [laughs] +CHAD: That's good. So, what is imi? +DEBORAH: So imi is a free digital research-backed mental health tool. It was developed by Hopelab in partnership with CenterLink, and the It Gets Better Project, as well as hundreds of LGBTQ+ young people across the U.S. It's a little hard to describe, to be perfectly honest. It really is intended to support and help LGBTQ+ teens explore and affirm their identity and learn practical ways to cope with their sexual and gender minority stress. +And we really hope that the tool is helpful, relevant, inclusive, and joyful. It is a web app, but it operates...it's not a lot of reading. It's listening, and doing, and thinking, and really giving youth an opportunity to explore and consider ways that they might help support themselves. +CHAD: That's great. And I suppose it's even a compliment to your prior work at CenterLink and with Q Chat Space, which is an online support community. +DEBORAH: Yes. +CHAD: People can use both. +DEBORAH: Exactly. We actually engaged in a partnership with Hopelab because we recognize that though youths were really excited about and engaged in the support groups that Q Chat Space provides, those are synchronous, and they happen once or twice a day. They last for an hour and a half, but that's all there is. So if you come to the website when a chat isn't happening, then there's not much to do. And we wanted to be able to provide youth with something else, and imi really fills that gap. +CHAD: So when it comes to the product itself, how long was it in development for? +DEBORAH: Great question. Of course, there was the pandemic, so there were some delays related to that. But it was about two and a half years from when Hopelab first approached CenterLink until the actual launch date. +CHAD: That's a fairly significant amount of time. +DEBORAH: It is for when you're working, I think if we were only tech firms, but both Hopelab and CenterLink are nonprofits. And the process included a lot of steps. So we actually had a prototype pretty early. But because we wanted to make sure that we did put something out into the world that actually had the impact we were seeking, we did a randomized controlled trial. We had 270 youth, half of them using a similar-looking website with just resources and the other half using imi. And we did that randomized controlled trial as well as a test of marketing. Those were both pieces that extended our timeline. And then ultimately, we also wanted to launch during Pride Month, so we timed it for that. +CHAD: This idea of a randomized control trial is pretty incredible to me. A lot of product people wouldn't necessarily do that; maybe certain companies do. Why do you think you went in that direction? +DEBORAH: So our goal is not to make money. And ultimately, if that was the goal, then we put something out, we see if people are using it and using it at the rate and the ways...I'm a social worker, so my business lingo is going to be limited. [chuckles] But that's the way to test it. And if youths use it but don't have any impact or potentially even harms them, which is not the case usually; it's just neutral, but if it doesn't have any impact, it's not worth our time. +And so, a randomized controlled trial really allows us to see whether or not it's working and then to make changes if it's not. We're testing not only whether it works in terms of the impact but also whether or not youths were interested and wanted to use it. And those are important elements for us before we're going to go out with something. +CHAD: That's great. That's what I was thinking you [chuckles] would probably say. In your work, correct me if I'm wrong, but your main demographic that you work with is youth. +DEBORAH: Yes. +CHAD: You alluded to this earlier, but how do you make sure that you're building products and things that they want to use? +DEBORAH: For sure. So it's really about involving them in the process. Going back in time to Q Chat Space, the idea for Q Chat Space actually came from focus groups we did with youth. It wasn't an adult who thought this is a good thing to do for youth. We really went to them to see what it was about and then kept youth involved in the process. We had youth involved in the design process. We had youth involved in the conceptualization and design and continue to this day to have a Youth Advisory Board who participate in Q Chat Space chat and give us feedback. And when we want to change something, we look to them. +And similarly, with imi but we have even more resources. We have, over time, including the randomized controlled trial, involved over 600 youth in the production and creation of imi. And really, the process was so deeply embedded with the youth that we used the language of co-creation and really make sure that youth are saying exactly what it is that they want and need and that they'll be willing to do. +So we did qualitative research in 2019 with over 350 youth initially all across the United States, all the way to Anchorage, Alaska, and to Birmingham, Alabama, and a bunch of places in between. And of those interviewed, 61% identified as racial and ethnic minorities. We really did want to make sure that this reached those youth as well as trans and non-binary and gender-nonconforming youth. +So we always oversampled or over-included those youth. And we also engaged with organizations that serve youth and know youth in a daily way, a lot of LGBT centers, and other organizations as well. And really, again, focused on organizations that are made by and are focused on QTBIPOC or queer and trans youth of color. +CHAD: Over the time that you've been doing this work, has expectations around online interaction, what products are, how youth will use them, has that changed? Has it been evolving? +DEBORAH: It certainly has been evolving. I mean, I think it's an interesting question. I'm not sure of the timeframe that you're asking. In terms of the work that I've done, I started doing digital health education in 2007. And I remember very well because the person who interviewed me and became my boss said, "You don't have to even know anything about technology. Don't worry; we'll figure that out." +CHAD: [laughs] +DEBORAH: They didn't expect, and to be honest, I say to people all the time that if somebody came to me now with a resume that I had in 2007 for one of the jobs that I did then, I would not have hired them. Things have changed dramatically. I mean, that's obviously 15 years we're talking about. Things have changed so very dramatically in the last 15 years. +But even I would say thinking about Q Chat Space, because Q Chat Space launched as a pilot in 2018 and then launched nationally in the summer of 2019, and then the pandemic hit 7-8 months later. And the concept of a digital support group we had to explain that to people at Q Chat Space. And now, post-pandemic, we don't have to explain that anymore. And if anything, we have to differentiate ourselves in ways that we never had to. +The irony of Q Chat Space, in particular, is that it was started both because youth identified the need but also our member centers, the LGBT centers, often had inquiries from youth who couldn't access them in person, and many of them started satellite programs, but still, you know, a 13-year-old you could live next door and not be able to get. There are other barriers besides location and distance. And so, at that point, centers really wanted to do something digitally, but they couldn't because they didn't have the resources. They didn't know how to do it, or they were concerned that it would start and then youth from all over the place would be contacting them. +But in a matter of weeks, maybe months, once the pandemic set in and the kids were...just like school figured out how to do things, the LGBT centers did as well. And so now Q Chat Space is one of many virtual programs with many different mechanisms. But I think it's really shifted, and youth are more open to it. Not that they weren't before, they definitely were, but they know more. There are less questions about what's this? What's going on here? I think there's a broader definition of what a virtual experience can look like because youth have been participating in synchronous and asynchronous and in text-only and video, and it's just there are so many ways. +In terms of imi in the last couple of years, all over the pandemic, but imi itself, I think, actually, the landscape for imi hasn't changed. But interestingly enough, Hopelab actually came to us with another product that they had already developed and they were hoping to use as the backend, which was a chatbot. They had created something called Vivibot, and it was helping young cancer survivors build resilience. And we know that resilience is an important quality for any person, but particularly: youth, it's important to develop it. And when someone's young, it's easier, not that it's easy. +[laughter] +And they thought that they would be able to use that technology, but ultimately the testing with young people really revealed that they didn't want a chatbot. If you check out imi, which is imi. guide, you can see that there are actually several chat experiences within that are the last remnants of that initial chatbot that we started with. But youth weren't interested in a chatbot, and I think that's one thing that's changed is that they have much higher expectations for automated communication. +I formerly worked at Planned Parenthood. They have a great product called Roo, that's a chatbot. We talked about it before I left there. I wasn't there when it was started. But there are high expectations for what a chatbot can do. And I think there's also just an understanding, oh, this is a bot, and that's okay. Versus a few years ago, maybe people wanted to pretend that it was a real person. And now it's like, no, it's fine that's it's a bot. I understand, and it's okay that this kind of conversation can happen with a chatbot. So there are a few things that I think have changed, but I'm also not a trend person. +[laughter] +CHAD: No, that's okay. That's great. So when it comes to...we talked a little bit about the timeline and the process you went through to arrive and launch imi. With multiple parties all bringing things to the table, how do you tend to manage the products that you work on? +DEBORAH: Sure. So Hopelab, really, I give almost all credit to Hopelab. I mean, I was really pleased to partner with them. And I definitely feel that CenterLink and It Gets Better bring a lot to the table. But ultimately, Hopelab did something I haven't seen happen very often, which is really helping nonprofits work together in a collaborative manner. It's a struggle. +I think nonprofits are competing for funds and donors. And it's a little bit more difficult to collaborate. But Hopelab really led this process and took us all through it and made sure to really put youth at the center, which I think is the force that we all have to remember when we do have conflicts between nonprofits is that we're all in the same missions, and missions that match each other in terms of helping the community. +Mid-Roll Ad: +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: Do you have people...when it comes to a project like this, are you hiring people? Is it a full-time team working on it? How does it tend to usually shape up? +DEBORAH: No. [laughs] It doesn't shape up like that. At this point with imi, Hopelab really focused on what our current capacity was. They're continuing to support us in a lot of ways. And they do have a full team. But the product that they're handing over to me, me as a non-techie social worker, I can manage it. It's on Squarespace. There are a lot of integrations, but they have made sure that those are things that I can really manage. I mean, I'm not a non-techie, really. I'm underestimating myself. I'm under-selling myself. +But ultimately, I am going to manage that with...I have a staff person who works full-time on Q Chat Space, not a technical person. They're really there to support facilitators and the youth as an administrator and manager, and that person will help me with promotion. But otherwise, imi is a tool that is out there and doesn't...I mean, we'll update it and make changes. But ultimately, it's not a team once it's launched. But the development, yes, it was about 14 people more or less throughout the last two years. +CHAD: I think that that's great and really important. Software isn't cheap. It's not easy. And if you're put in a position where you're putting...I don't know the right word; burden comes to mind. Like, the burden of future work and maintenance and investment in an organization that maybe isn't set up to do that that could be a problem. +DEBORAH: Right. Now talk to me in six months or a year, and I'll know more. [laughter] But that said, even with Q Chat Space, I, with hundreds of people, including folks at thoughtbot and other places, volunteers, and donors, and supporters, really made Q Chat Space a reality, but I was the lead on it. And again, I used, you know, off-the-shelf products, basically. +And I have a developer for the website. But besides that developer, who is a part-time person, we manage. We figure things out ourselves. We get help from volunteers. We bring in a consultant here and there. But we try to keep the technology slim, trim, easy, user-friendly, whatever language we want to use. So that really serves the purpose of the youth. We don't need to be using anything fancy per se. +CHAD: I could be misremembering, but I think when we were first talking, one of the first conversations we had this came up with Q Chat Space. Because if you look at what it does and the problem set, and particularly the market, I think there could be a tendency for someone looking at that especially, I'm a programmer, and so I want to solve problems by programming things. You could say, "We should really build something specific for this. +DEBORAH: [laughs] +CHAD: It's not that difficult. It's just a chat thing. There are lots of these things out there." And I'm right in terms of the actual core functionality. You could bang that out in a little while. But doing that would create a burden then to you have a custom piece of software that you need to constantly evolve, maintain, and those kinds of things. And so I think this was a discussion we had about what was out there in the ecosystem, what open source or other things you could pull together so that we weren't creating that burden. +DEBORAH: Exactly. And interestingly, my developer has said to me many times, "I could just build something for you." [laughter] And I say, "No, like, I don't need that." And ultimately, we did end up going with an open-sourced product; it's Rocket.Chat. We picked Rocket.Chat. This was in 2017, I think. We looked at 30 different products. And there were that many products on the market already, and today, I think there'll be even more. But ultimately, we just took Rocket.Chat because it's highly customizable. For those of you who aren't familiar with Rocket.Chat, it's like Discord. It's actually the same code, from what I understand. It's sort of like Slack. +But in the end, we were able to...because there's a lot of like, turn this on, turn this off, turn this on, turn this off, just a lot of different features, we were able to just make it into what we needed. We're using it in a way that very few people are using Rocket.Chat because we opened up a channel just for that hour and a half, and then it's gone. It's not an ongoing conversation. But Rocket.Chat has been a great supporter. They give us a fabulous nonprofit rate and really appreciate the unusual use case that we have for their product. +CHAD: Yeah, that's great. I think one of the things that hopefully motivates a lot of people is having a positive impact on the world. This is Pride Month. You alluded to it already. And I think it's important that we celebrate Pride. I think you have a great organization that I hope people will get involved in and pay attention to even outside of Pride Month. How has it been for you? And sometimes, it's hard for me to judge are things better or worse in terms of really supporting LGBTQ+ youth today? +DEBORAH: Both. [laughs] It's better, it's worse. There's no question to how far are we going to go back? But there's so much more media representation, and more schools have GSAs, and more people know someone who's LGBTQ. And I think it's different for lesbian, gay, and bisexual folks than it is for trans and non-binary and gender non-conforming folks. There's more acceptance of sexual orientation differences than there are gender differences. But I think culturally, that's changing, and as a result, there is currently quite a large...the word coming to me is flashback, but that's not the right word. Backlash, push back, exactly. +And we are seeing alarming numbers of legislative efforts to particularly limit what transgender and gender nonconforming and non-binary youth can do and what their parents can do. And that is very alarming and certainly highly regressive. But I do think that it comes out of the fact that we have moved forward in so many ways. +So for any young person who's listening or any of you who are listening, you can say this to the young people in your lives like, "You deserve to be yourself. You deserve to be able to be yourself and open. And you deserve a good and strong and mentally healthy life." And that message is really what imi certainly gives, a joyful life. It is about pride. We are proud to be LGBTQ. There's nothing to be ashamed of. And yet there are many forces in our culture and government who do make young people and adults feel shameful about it. So that's really what we're trying to counter. +CHAD: And that's one of the great things I think about when it comes to online tools is because you could be in an environment where you're not supported, where you don't see that support or people like you, or it could be very isolating. And the ability to reach beyond your family boundaries and geographic boundaries and connect with people who can support you is really great. +DEBORAH: It is. And to know ultimately, the tools are really designed to acknowledge that some young people have to keep it a secret or private. They're not ready to come out. Both websites have a quick exit, so a young person can click on that and go right to Google. imi also times out after 10 minutes. +And it's an interesting thing because the folks who are regressive, going back to our last bit, those folks jump on that and say, "Look, they're keeping it a secret from their parents." And we're like, well, if the parents are going to be abusive, then yes, we're going to keep it a secret from their parents. But if the parents want to figure out how to be affirming, we are with them. We want to help them be affirming. +So it really does allow youth...both tools really reach youth who may feel as if they have no one around them. And imi, in particular, provides community in a way youth don't even have to talk to anybody else. But they're going to hear the voices and see the faces of other young people dealing with similar things. imi is rich with those stories as well as other activities. And then on Q Chat Space, they can connect to a real other teenager who's dealing with similar things but maybe in a different state or a different country even. +CHAD: I guess that's another...I think the conversation I was having was very U.S.-centric, too. And you think things are bad here; they're even worse in a lot of other places in terms of LGBTQ rights and support. +DEBORAH: They are. +CHAD: And I guess that's another benefit of online. It really crosses those boundaries too. +DEBORAH: It does. And we have enabled that on Q Chat Space and imi. Both are accessible from anywhere in the world. We have heard from youths in 149 other countries, I believe [laughs] on Q Chat Space. +CHAD: Wow. +DEBORAH: And we just launched imi, so we don't have that data yet, but it is available. Unfortunately, right now, imi is only in English. Q Chat Space, we do have a weekly chat in Spanish. So we welcome any youth who prefer to chat in Spanish on Monday nights. But imi from now is just in English. But other than that, I mean, the reality of colonization is that a lot of youth speak English, even if it was not their first language. So we have had chatters from Korea, Vietnam, Australia, UK, and everywhere in between. +CHAD: That's great. If folks want to get involved, where are the best places for them to do that? +DEBORAH: Sure. So anybody who feels like they can help in any way, whether it's tech help, or with financial support, they can connect with us through the websites. And we will happily figure out ways to get engaged. In terms of your more traditional volunteer situation, I recommend folks go to the LGBT Center Directory that we have on CenterLink's website; CenterLink's website is lgbtcenters.org, and find your local LGBT center. They have many opportunities for volunteers as well as support and tech help. If you check out their website and you think it doesn't look so great, [laughter] offer help with their website. +So there are a lot of ways to get involved in the LGBTQ community between these two products, as well as just the LGBT centers that the two products are really meant to serve. I didn't really mention that, but we have 300+ LGBT centers that are part of the CenterLink network that we work to support, strengthen, and connect. And imi really is a product that none of them would be able to develop on their own. And this way, they're all able to use it as if it was their own. That's one of the beauties that, of course, the greatest impact is for youth. But for our centers to be able to have that kind of resource available to them, we owe a huge thanks to Hopelab for doing that for CenterLink and all of our members. +CHAD: We're going to include links in the show notes for all of the things that you just mentioned. +DEBORAH: Awesome. +CHAD: I really encourage people to if you want to reach out with your time and get involved, that's great. You can also, as Deborah said, go there and donate. If you can't donate your time, but you can donate some money, that'd be great. Deborah, thank you so much for stopping by and sharing with us. I really appreciate it, and I appreciate all the work you do. +DEBORAH: Absolutely. It was a pleasure. Thanks so much. +CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Deborah Levine. + + + Deborah Levine is the Director of LGBT YouthLink at CenterLink, which supports, strengthens, and connects LGBT centers.

+ +

Chad talks with Deborah about working on something new called imi: a free digital research-backed mental health tool intended to support and help LGBTQ+ teens explore and affirm their identity and learn practical ways to cope with their sexual and gender minority stress, founding Q Chat Space, a digital LGBTQ+ center where teens join live-chat, professionally facilitated, online support groups, and how over the time that she's been doing work in LGBTQ+ spaces products and online interaction have changed and evolved.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me, today is Deborah Levine, Director of LGBT YouthLink at CenterLink, which supports, strengthens, and connects LGBT centers. Deborah, thank you so much for joining me.

+ +

DEBORAH: Thanks, Chad. I appreciate you inviting me.

+ +

CHAD: So I was first introduced to you and to CenterLink through the Q Chat Space product. And that's still going, right?

+ +

DEBORAH: Yeah.

+ +

CHAD: But you're working on something new called imi.

+ +

DEBORAH: Mm-hmm. We actually just launched imi on June 1st.

+ +

CHAD: Congratulations on the launch.

+ +

DEBORAH: Thank you. Yes, it went pretty smoothly. [laughs]

+ +

CHAD: That's good. So, what is imi?

+ +

DEBORAH: So imi is a free digital research-backed mental health tool. It was developed by Hopelab in partnership with CenterLink, and the It Gets Better Project, as well as hundreds of LGBTQ+ young people across the U.S. It's a little hard to describe, to be perfectly honest. It really is intended to support and help LGBTQ+ teens explore and affirm their identity and learn practical ways to cope with their sexual and gender minority stress.

+ +

And we really hope that the tool is helpful, relevant, inclusive, and joyful. It is a web app, but it operates...it's not a lot of reading. It's listening, and doing, and thinking, and really giving youth an opportunity to explore and consider ways that they might help support themselves.

+ +

CHAD: That's great. And I suppose it's even a compliment to your prior work at CenterLink and with Q Chat Space, which is an online support community.

+ +

DEBORAH: Yes.

+ +

CHAD: People can use both.

+ +

DEBORAH: Exactly. We actually engaged in a partnership with Hopelab because we recognize that though youths were really excited about and engaged in the support groups that Q Chat Space provides, those are synchronous, and they happen once or twice a day. They last for an hour and a half, but that's all there is. So if you come to the website when a chat isn't happening, then there's not much to do. And we wanted to be able to provide youth with something else, and imi really fills that gap.

+ +

CHAD: So when it comes to the product itself, how long was it in development for?

+ +

DEBORAH: Great question. Of course, there was the pandemic, so there were some delays related to that. But it was about two and a half years from when Hopelab first approached CenterLink until the actual launch date.

+ +

CHAD: That's a fairly significant amount of time.

+ +

DEBORAH: It is for when you're working, I think if we were only tech firms, but both Hopelab and CenterLink are nonprofits. And the process included a lot of steps. So we actually had a prototype pretty early. But because we wanted to make sure that we did put something out into the world that actually had the impact we were seeking, we did a randomized controlled trial. We had 270 youth, half of them using a similar-looking website with just resources and the other half using imi. And we did that randomized controlled trial as well as a test of marketing. Those were both pieces that extended our timeline. And then ultimately, we also wanted to launch during Pride Month, so we timed it for that.

+ +

CHAD: This idea of a randomized control trial is pretty incredible to me. A lot of product people wouldn't necessarily do that; maybe certain companies do. Why do you think you went in that direction?

+ +

DEBORAH: So our goal is not to make money. And ultimately, if that was the goal, then we put something out, we see if people are using it and using it at the rate and the ways...I'm a social worker, so my business lingo is going to be limited. [chuckles] But that's the way to test it. And if youths use it but don't have any impact or potentially even harms them, which is not the case usually; it's just neutral, but if it doesn't have any impact, it's not worth our time.

+ +

And so, a randomized controlled trial really allows us to see whether or not it's working and then to make changes if it's not. We're testing not only whether it works in terms of the impact but also whether or not youths were interested and wanted to use it. And those are important elements for us before we're going to go out with something.

+ +

CHAD: That's great. That's what I was thinking you [chuckles] would probably say. In your work, correct me if I'm wrong, but your main demographic that you work with is youth.

+ +

DEBORAH: Yes.

+ +

CHAD: You alluded to this earlier, but how do you make sure that you're building products and things that they want to use?

+ +

DEBORAH: For sure. So it's really about involving them in the process. Going back in time to Q Chat Space, the idea for Q Chat Space actually came from focus groups we did with youth. It wasn't an adult who thought this is a good thing to do for youth. We really went to them to see what it was about and then kept youth involved in the process. We had youth involved in the design process. We had youth involved in the conceptualization and design and continue to this day to have a Youth Advisory Board who participate in Q Chat Space chat and give us feedback. And when we want to change something, we look to them.

+ +

And similarly, with imi but we have even more resources. We have, over time, including the randomized controlled trial, involved over 600 youth in the production and creation of imi. And really, the process was so deeply embedded with the youth that we used the language of co-creation and really make sure that youth are saying exactly what it is that they want and need and that they'll be willing to do.

+ +

So we did qualitative research in 2019 with over 350 youth initially all across the United States, all the way to Anchorage, Alaska, and to Birmingham, Alabama, and a bunch of places in between. And of those interviewed, 61% identified as racial and ethnic minorities. We really did want to make sure that this reached those youth as well as trans and non-binary and gender-nonconforming youth.

+ +

So we always oversampled or over-included those youth. And we also engaged with organizations that serve youth and know youth in a daily way, a lot of LGBT centers, and other organizations as well. And really, again, focused on organizations that are made by and are focused on QTBIPOC or queer and trans youth of color.

+ +

CHAD: Over the time that you've been doing this work, has expectations around online interaction, what products are, how youth will use them, has that changed? Has it been evolving?

+ +

DEBORAH: It certainly has been evolving. I mean, I think it's an interesting question. I'm not sure of the timeframe that you're asking. In terms of the work that I've done, I started doing digital health education in 2007. And I remember very well because the person who interviewed me and became my boss said, "You don't have to even know anything about technology. Don't worry; we'll figure that out."

+ +

CHAD: [laughs]

+ +

DEBORAH: They didn't expect, and to be honest, I say to people all the time that if somebody came to me now with a resume that I had in 2007 for one of the jobs that I did then, I would not have hired them. Things have changed dramatically. I mean, that's obviously 15 years we're talking about. Things have changed so very dramatically in the last 15 years.

+ +

But even I would say thinking about Q Chat Space, because Q Chat Space launched as a pilot in 2018 and then launched nationally in the summer of 2019, and then the pandemic hit 7-8 months later. And the concept of a digital support group we had to explain that to people at Q Chat Space. And now, post-pandemic, we don't have to explain that anymore. And if anything, we have to differentiate ourselves in ways that we never had to.

+ +

The irony of Q Chat Space, in particular, is that it was started both because youth identified the need but also our member centers, the LGBT centers, often had inquiries from youth who couldn't access them in person, and many of them started satellite programs, but still, you know, a 13-year-old you could live next door and not be able to get. There are other barriers besides location and distance. And so, at that point, centers really wanted to do something digitally, but they couldn't because they didn't have the resources. They didn't know how to do it, or they were concerned that it would start and then youth from all over the place would be contacting them.

+ +

But in a matter of weeks, maybe months, once the pandemic set in and the kids were...just like school figured out how to do things, the LGBT centers did as well. And so now Q Chat Space is one of many virtual programs with many different mechanisms. But I think it's really shifted, and youth are more open to it. Not that they weren't before, they definitely were, but they know more. There are less questions about what's this? What's going on here? I think there's a broader definition of what a virtual experience can look like because youth have been participating in synchronous and asynchronous and in text-only and video, and it's just there are so many ways.

+ +

In terms of imi in the last couple of years, all over the pandemic, but imi itself, I think, actually, the landscape for imi hasn't changed. But interestingly enough, Hopelab actually came to us with another product that they had already developed and they were hoping to use as the backend, which was a chatbot. They had created something called Vivibot, and it was helping young cancer survivors build resilience. And we know that resilience is an important quality for any person, but particularly: youth, it's important to develop it. And when someone's young, it's easier, not that it's easy.

+ +

[laughter]

+ +

And they thought that they would be able to use that technology, but ultimately the testing with young people really revealed that they didn't want a chatbot. If you check out imi, which is imi. guide, you can see that there are actually several chat experiences within that are the last remnants of that initial chatbot that we started with. But youth weren't interested in a chatbot, and I think that's one thing that's changed is that they have much higher expectations for automated communication.

+ +

I formerly worked at Planned Parenthood. They have a great product called Roo, that's a chatbot. We talked about it before I left there. I wasn't there when it was started. But there are high expectations for what a chatbot can do. And I think there's also just an understanding, oh, this is a bot, and that's okay. Versus a few years ago, maybe people wanted to pretend that it was a real person. And now it's like, no, it's fine that's it's a bot. I understand, and it's okay that this kind of conversation can happen with a chatbot. So there are a few things that I think have changed, but I'm also not a trend person.

+ +

[laughter]

+ +

CHAD: No, that's okay. That's great. So when it comes to...we talked a little bit about the timeline and the process you went through to arrive and launch imi. With multiple parties all bringing things to the table, how do you tend to manage the products that you work on?

+ +

DEBORAH: Sure. So Hopelab, really, I give almost all credit to Hopelab. I mean, I was really pleased to partner with them. And I definitely feel that CenterLink and It Gets Better bring a lot to the table. But ultimately, Hopelab did something I haven't seen happen very often, which is really helping nonprofits work together in a collaborative manner. It's a struggle.

+ +

I think nonprofits are competing for funds and donors. And it's a little bit more difficult to collaborate. But Hopelab really led this process and took us all through it and made sure to really put youth at the center, which I think is the force that we all have to remember when we do have conflicts between nonprofits is that we're all in the same missions, and missions that match each other in terms of helping the community.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Do you have people...when it comes to a project like this, are you hiring people? Is it a full-time team working on it? How does it tend to usually shape up?

+ +

DEBORAH: No. [laughs] It doesn't shape up like that. At this point with imi, Hopelab really focused on what our current capacity was. They're continuing to support us in a lot of ways. And they do have a full team. But the product that they're handing over to me, me as a non-techie social worker, I can manage it. It's on Squarespace. There are a lot of integrations, but they have made sure that those are things that I can really manage. I mean, I'm not a non-techie, really. I'm underestimating myself. I'm under-selling myself.

+ +

But ultimately, I am going to manage that with...I have a staff person who works full-time on Q Chat Space, not a technical person. They're really there to support facilitators and the youth as an administrator and manager, and that person will help me with promotion. But otherwise, imi is a tool that is out there and doesn't...I mean, we'll update it and make changes. But ultimately, it's not a team once it's launched. But the development, yes, it was about 14 people more or less throughout the last two years.

+ +

CHAD: I think that that's great and really important. Software isn't cheap. It's not easy. And if you're put in a position where you're putting...I don't know the right word; burden comes to mind. Like, the burden of future work and maintenance and investment in an organization that maybe isn't set up to do that that could be a problem.

+ +

DEBORAH: Right. Now talk to me in six months or a year, and I'll know more. [laughter] But that said, even with Q Chat Space, I, with hundreds of people, including folks at thoughtbot and other places, volunteers, and donors, and supporters, really made Q Chat Space a reality, but I was the lead on it. And again, I used, you know, off-the-shelf products, basically.

+ +

And I have a developer for the website. But besides that developer, who is a part-time person, we manage. We figure things out ourselves. We get help from volunteers. We bring in a consultant here and there. But we try to keep the technology slim, trim, easy, user-friendly, whatever language we want to use. So that really serves the purpose of the youth. We don't need to be using anything fancy per se.

+ +

CHAD: I could be misremembering, but I think when we were first talking, one of the first conversations we had this came up with Q Chat Space. Because if you look at what it does and the problem set, and particularly the market, I think there could be a tendency for someone looking at that especially, I'm a programmer, and so I want to solve problems by programming things. You could say, "We should really build something specific for this.

+ +

DEBORAH: [laughs]

+ +

CHAD: It's not that difficult. It's just a chat thing. There are lots of these things out there." And I'm right in terms of the actual core functionality. You could bang that out in a little while. But doing that would create a burden then to you have a custom piece of software that you need to constantly evolve, maintain, and those kinds of things. And so I think this was a discussion we had about what was out there in the ecosystem, what open source or other things you could pull together so that we weren't creating that burden.

+ +

DEBORAH: Exactly. And interestingly, my developer has said to me many times, "I could just build something for you." [laughter] And I say, "No, like, I don't need that." And ultimately, we did end up going with an open-sourced product; it's Rocket.Chat. We picked Rocket.Chat. This was in 2017, I think. We looked at 30 different products. And there were that many products on the market already, and today, I think there'll be even more. But ultimately, we just took Rocket.Chat because it's highly customizable. For those of you who aren't familiar with Rocket.Chat, it's like Discord. It's actually the same code, from what I understand. It's sort of like Slack.

+ +

But in the end, we were able to...because there's a lot of like, turn this on, turn this off, turn this on, turn this off, just a lot of different features, we were able to just make it into what we needed. We're using it in a way that very few people are using Rocket.Chat because we opened up a channel just for that hour and a half, and then it's gone. It's not an ongoing conversation. But Rocket.Chat has been a great supporter. They give us a fabulous nonprofit rate and really appreciate the unusual use case that we have for their product.

+ +

CHAD: Yeah, that's great. I think one of the things that hopefully motivates a lot of people is having a positive impact on the world. This is Pride Month. You alluded to it already. And I think it's important that we celebrate Pride. I think you have a great organization that I hope people will get involved in and pay attention to even outside of Pride Month. How has it been for you? And sometimes, it's hard for me to judge are things better or worse in terms of really supporting LGBTQ+ youth today?

+ +

DEBORAH: Both. [laughs] It's better, it's worse. There's no question to how far are we going to go back? But there's so much more media representation, and more schools have GSAs, and more people know someone who's LGBTQ. And I think it's different for lesbian, gay, and bisexual folks than it is for trans and non-binary and gender non-conforming folks. There's more acceptance of sexual orientation differences than there are gender differences. But I think culturally, that's changing, and as a result, there is currently quite a large...the word coming to me is flashback, but that's not the right word. Backlash, push back, exactly.

+ +

And we are seeing alarming numbers of legislative efforts to particularly limit what transgender and gender nonconforming and non-binary youth can do and what their parents can do. And that is very alarming and certainly highly regressive. But I do think that it comes out of the fact that we have moved forward in so many ways.

+ +

So for any young person who's listening or any of you who are listening, you can say this to the young people in your lives like, "You deserve to be yourself. You deserve to be able to be yourself and open. And you deserve a good and strong and mentally healthy life." And that message is really what imi certainly gives, a joyful life. It is about pride. We are proud to be LGBTQ. There's nothing to be ashamed of. And yet there are many forces in our culture and government who do make young people and adults feel shameful about it. So that's really what we're trying to counter.

+ +

CHAD: And that's one of the great things I think about when it comes to online tools is because you could be in an environment where you're not supported, where you don't see that support or people like you, or it could be very isolating. And the ability to reach beyond your family boundaries and geographic boundaries and connect with people who can support you is really great.

+ +

DEBORAH: It is. And to know ultimately, the tools are really designed to acknowledge that some young people have to keep it a secret or private. They're not ready to come out. Both websites have a quick exit, so a young person can click on that and go right to Google. imi also times out after 10 minutes.

+ +

And it's an interesting thing because the folks who are regressive, going back to our last bit, those folks jump on that and say, "Look, they're keeping it a secret from their parents." And we're like, well, if the parents are going to be abusive, then yes, we're going to keep it a secret from their parents. But if the parents want to figure out how to be affirming, we are with them. We want to help them be affirming.

+ +

So it really does allow youth...both tools really reach youth who may feel as if they have no one around them. And imi, in particular, provides community in a way youth don't even have to talk to anybody else. But they're going to hear the voices and see the faces of other young people dealing with similar things. imi is rich with those stories as well as other activities. And then on Q Chat Space, they can connect to a real other teenager who's dealing with similar things but maybe in a different state or a different country even.

+ +

CHAD: I guess that's another...I think the conversation I was having was very U.S.-centric, too. And you think things are bad here; they're even worse in a lot of other places in terms of LGBTQ rights and support.

+ +

DEBORAH: They are.

+ +

CHAD: And I guess that's another benefit of online. It really crosses those boundaries too.

+ +

DEBORAH: It does. And we have enabled that on Q Chat Space and imi. Both are accessible from anywhere in the world. We have heard from youths in 149 other countries, I believe [laughs] on Q Chat Space.

+ +

CHAD: Wow.

+ +

DEBORAH: And we just launched imi, so we don't have that data yet, but it is available. Unfortunately, right now, imi is only in English. Q Chat Space, we do have a weekly chat in Spanish. So we welcome any youth who prefer to chat in Spanish on Monday nights. But imi from now is just in English. But other than that, I mean, the reality of colonization is that a lot of youth speak English, even if it was not their first language. So we have had chatters from Korea, Vietnam, Australia, UK, and everywhere in between.

+ +

CHAD: That's great. If folks want to get involved, where are the best places for them to do that?

+ +

DEBORAH: Sure. So anybody who feels like they can help in any way, whether it's tech help, or with financial support, they can connect with us through the websites. And we will happily figure out ways to get engaged. In terms of your more traditional volunteer situation, I recommend folks go to the LGBT Center Directory that we have on CenterLink's website; CenterLink's website is lgbtcenters.org, and find your local LGBT center. They have many opportunities for volunteers as well as support and tech help. If you check out their website and you think it doesn't look so great, [laughter] offer help with their website.

+ +

So there are a lot of ways to get involved in the LGBTQ community between these two products, as well as just the LGBT centers that the two products are really meant to serve. I didn't really mention that, but we have 300+ LGBT centers that are part of the CenterLink network that we work to support, strengthen, and connect. And imi really is a product that none of them would be able to develop on their own. And this way, they're all able to use it as if it was their own. That's one of the beauties that, of course, the greatest impact is for youth. But for our centers to be able to have that kind of resource available to them, we owe a huge thanks to Hopelab for doing that for CenterLink and all of our members.

+ +

CHAD: We're going to include links in the show notes for all of the things that you just mentioned.

+ +

DEBORAH: Awesome.

+ +

CHAD: I really encourage people to if you want to reach out with your time and get involved, that's great. You can also, as Deborah said, go there and donate. If you can't donate your time, but you can donate some money, that'd be great. Deborah, thank you so much for stopping by and sharing with us. I really appreciate it, and I appreciate all the work you do.

+ +

DEBORAH: Absolutely. It was a pleasure. Thanks so much.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Deborah Levine.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Deborah Levine is the Director of LGBT YouthLink at CenterLink, which supports, strengthens, and connects LGBT centers.

+ +

Chad talks with Deborah about working on something new called imi: a free digital research-backed mental health tool intended to support and help LGBTQ+ teens explore and affirm their identity and learn practical ways to cope with their sexual and gender minority stress, founding Q Chat Space, a digital LGBTQ+ center where teens join live-chat, professionally facilitated, online support groups, and how over the time that she's been doing work in LGBTQ+ spaces products and online interaction have changed and evolved.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me, today is Deborah Levine, Director of LGBT YouthLink at CenterLink, which supports, strengthens, and connects LGBT centers. Deborah, thank you so much for joining me.

+ +

DEBORAH: Thanks, Chad. I appreciate you inviting me.

+ +

CHAD: So I was first introduced to you and to CenterLink through the Q Chat Space product. And that's still going, right?

+ +

DEBORAH: Yeah.

+ +

CHAD: But you're working on something new called imi.

+ +

DEBORAH: Mm-hmm. We actually just launched imi on June 1st.

+ +

CHAD: Congratulations on the launch.

+ +

DEBORAH: Thank you. Yes, it went pretty smoothly. [laughs]

+ +

CHAD: That's good. So, what is imi?

+ +

DEBORAH: So imi is a free digital research-backed mental health tool. It was developed by Hopelab in partnership with CenterLink, and the It Gets Better Project, as well as hundreds of LGBTQ+ young people across the U.S. It's a little hard to describe, to be perfectly honest. It really is intended to support and help LGBTQ+ teens explore and affirm their identity and learn practical ways to cope with their sexual and gender minority stress.

+ +

And we really hope that the tool is helpful, relevant, inclusive, and joyful. It is a web app, but it operates...it's not a lot of reading. It's listening, and doing, and thinking, and really giving youth an opportunity to explore and consider ways that they might help support themselves.

+ +

CHAD: That's great. And I suppose it's even a compliment to your prior work at CenterLink and with Q Chat Space, which is an online support community.

+ +

DEBORAH: Yes.

+ +

CHAD: People can use both.

+ +

DEBORAH: Exactly. We actually engaged in a partnership with Hopelab because we recognize that though youths were really excited about and engaged in the support groups that Q Chat Space provides, those are synchronous, and they happen once or twice a day. They last for an hour and a half, but that's all there is. So if you come to the website when a chat isn't happening, then there's not much to do. And we wanted to be able to provide youth with something else, and imi really fills that gap.

+ +

CHAD: So when it comes to the product itself, how long was it in development for?

+ +

DEBORAH: Great question. Of course, there was the pandemic, so there were some delays related to that. But it was about two and a half years from when Hopelab first approached CenterLink until the actual launch date.

+ +

CHAD: That's a fairly significant amount of time.

+ +

DEBORAH: It is for when you're working, I think if we were only tech firms, but both Hopelab and CenterLink are nonprofits. And the process included a lot of steps. So we actually had a prototype pretty early. But because we wanted to make sure that we did put something out into the world that actually had the impact we were seeking, we did a randomized controlled trial. We had 270 youth, half of them using a similar-looking website with just resources and the other half using imi. And we did that randomized controlled trial as well as a test of marketing. Those were both pieces that extended our timeline. And then ultimately, we also wanted to launch during Pride Month, so we timed it for that.

+ +

CHAD: This idea of a randomized control trial is pretty incredible to me. A lot of product people wouldn't necessarily do that; maybe certain companies do. Why do you think you went in that direction?

+ +

DEBORAH: So our goal is not to make money. And ultimately, if that was the goal, then we put something out, we see if people are using it and using it at the rate and the ways...I'm a social worker, so my business lingo is going to be limited. [chuckles] But that's the way to test it. And if youths use it but don't have any impact or potentially even harms them, which is not the case usually; it's just neutral, but if it doesn't have any impact, it's not worth our time.

+ +

And so, a randomized controlled trial really allows us to see whether or not it's working and then to make changes if it's not. We're testing not only whether it works in terms of the impact but also whether or not youths were interested and wanted to use it. And those are important elements for us before we're going to go out with something.

+ +

CHAD: That's great. That's what I was thinking you [chuckles] would probably say. In your work, correct me if I'm wrong, but your main demographic that you work with is youth.

+ +

DEBORAH: Yes.

+ +

CHAD: You alluded to this earlier, but how do you make sure that you're building products and things that they want to use?

+ +

DEBORAH: For sure. So it's really about involving them in the process. Going back in time to Q Chat Space, the idea for Q Chat Space actually came from focus groups we did with youth. It wasn't an adult who thought this is a good thing to do for youth. We really went to them to see what it was about and then kept youth involved in the process. We had youth involved in the design process. We had youth involved in the conceptualization and design and continue to this day to have a Youth Advisory Board who participate in Q Chat Space chat and give us feedback. And when we want to change something, we look to them.

+ +

And similarly, with imi but we have even more resources. We have, over time, including the randomized controlled trial, involved over 600 youth in the production and creation of imi. And really, the process was so deeply embedded with the youth that we used the language of co-creation and really make sure that youth are saying exactly what it is that they want and need and that they'll be willing to do.

+ +

So we did qualitative research in 2019 with over 350 youth initially all across the United States, all the way to Anchorage, Alaska, and to Birmingham, Alabama, and a bunch of places in between. And of those interviewed, 61% identified as racial and ethnic minorities. We really did want to make sure that this reached those youth as well as trans and non-binary and gender-nonconforming youth.

+ +

So we always oversampled or over-included those youth. And we also engaged with organizations that serve youth and know youth in a daily way, a lot of LGBT centers, and other organizations as well. And really, again, focused on organizations that are made by and are focused on QTBIPOC or queer and trans youth of color.

+ +

CHAD: Over the time that you've been doing this work, has expectations around online interaction, what products are, how youth will use them, has that changed? Has it been evolving?

+ +

DEBORAH: It certainly has been evolving. I mean, I think it's an interesting question. I'm not sure of the timeframe that you're asking. In terms of the work that I've done, I started doing digital health education in 2007. And I remember very well because the person who interviewed me and became my boss said, "You don't have to even know anything about technology. Don't worry; we'll figure that out."

+ +

CHAD: [laughs]

+ +

DEBORAH: They didn't expect, and to be honest, I say to people all the time that if somebody came to me now with a resume that I had in 2007 for one of the jobs that I did then, I would not have hired them. Things have changed dramatically. I mean, that's obviously 15 years we're talking about. Things have changed so very dramatically in the last 15 years.

+ +

But even I would say thinking about Q Chat Space, because Q Chat Space launched as a pilot in 2018 and then launched nationally in the summer of 2019, and then the pandemic hit 7-8 months later. And the concept of a digital support group we had to explain that to people at Q Chat Space. And now, post-pandemic, we don't have to explain that anymore. And if anything, we have to differentiate ourselves in ways that we never had to.

+ +

The irony of Q Chat Space, in particular, is that it was started both because youth identified the need but also our member centers, the LGBT centers, often had inquiries from youth who couldn't access them in person, and many of them started satellite programs, but still, you know, a 13-year-old you could live next door and not be able to get. There are other barriers besides location and distance. And so, at that point, centers really wanted to do something digitally, but they couldn't because they didn't have the resources. They didn't know how to do it, or they were concerned that it would start and then youth from all over the place would be contacting them.

+ +

But in a matter of weeks, maybe months, once the pandemic set in and the kids were...just like school figured out how to do things, the LGBT centers did as well. And so now Q Chat Space is one of many virtual programs with many different mechanisms. But I think it's really shifted, and youth are more open to it. Not that they weren't before, they definitely were, but they know more. There are less questions about what's this? What's going on here? I think there's a broader definition of what a virtual experience can look like because youth have been participating in synchronous and asynchronous and in text-only and video, and it's just there are so many ways.

+ +

In terms of imi in the last couple of years, all over the pandemic, but imi itself, I think, actually, the landscape for imi hasn't changed. But interestingly enough, Hopelab actually came to us with another product that they had already developed and they were hoping to use as the backend, which was a chatbot. They had created something called Vivibot, and it was helping young cancer survivors build resilience. And we know that resilience is an important quality for any person, but particularly: youth, it's important to develop it. And when someone's young, it's easier, not that it's easy.

+ +

[laughter]

+ +

And they thought that they would be able to use that technology, but ultimately the testing with young people really revealed that they didn't want a chatbot. If you check out imi, which is imi. guide, you can see that there are actually several chat experiences within that are the last remnants of that initial chatbot that we started with. But youth weren't interested in a chatbot, and I think that's one thing that's changed is that they have much higher expectations for automated communication.

+ +

I formerly worked at Planned Parenthood. They have a great product called Roo, that's a chatbot. We talked about it before I left there. I wasn't there when it was started. But there are high expectations for what a chatbot can do. And I think there's also just an understanding, oh, this is a bot, and that's okay. Versus a few years ago, maybe people wanted to pretend that it was a real person. And now it's like, no, it's fine that's it's a bot. I understand, and it's okay that this kind of conversation can happen with a chatbot. So there are a few things that I think have changed, but I'm also not a trend person.

+ +

[laughter]

+ +

CHAD: No, that's okay. That's great. So when it comes to...we talked a little bit about the timeline and the process you went through to arrive and launch imi. With multiple parties all bringing things to the table, how do you tend to manage the products that you work on?

+ +

DEBORAH: Sure. So Hopelab, really, I give almost all credit to Hopelab. I mean, I was really pleased to partner with them. And I definitely feel that CenterLink and It Gets Better bring a lot to the table. But ultimately, Hopelab did something I haven't seen happen very often, which is really helping nonprofits work together in a collaborative manner. It's a struggle.

+ +

I think nonprofits are competing for funds and donors. And it's a little bit more difficult to collaborate. But Hopelab really led this process and took us all through it and made sure to really put youth at the center, which I think is the force that we all have to remember when we do have conflicts between nonprofits is that we're all in the same missions, and missions that match each other in terms of helping the community.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Do you have people...when it comes to a project like this, are you hiring people? Is it a full-time team working on it? How does it tend to usually shape up?

+ +

DEBORAH: No. [laughs] It doesn't shape up like that. At this point with imi, Hopelab really focused on what our current capacity was. They're continuing to support us in a lot of ways. And they do have a full team. But the product that they're handing over to me, me as a non-techie social worker, I can manage it. It's on Squarespace. There are a lot of integrations, but they have made sure that those are things that I can really manage. I mean, I'm not a non-techie, really. I'm underestimating myself. I'm under-selling myself.

+ +

But ultimately, I am going to manage that with...I have a staff person who works full-time on Q Chat Space, not a technical person. They're really there to support facilitators and the youth as an administrator and manager, and that person will help me with promotion. But otherwise, imi is a tool that is out there and doesn't...I mean, we'll update it and make changes. But ultimately, it's not a team once it's launched. But the development, yes, it was about 14 people more or less throughout the last two years.

+ +

CHAD: I think that that's great and really important. Software isn't cheap. It's not easy. And if you're put in a position where you're putting...I don't know the right word; burden comes to mind. Like, the burden of future work and maintenance and investment in an organization that maybe isn't set up to do that that could be a problem.

+ +

DEBORAH: Right. Now talk to me in six months or a year, and I'll know more. [laughter] But that said, even with Q Chat Space, I, with hundreds of people, including folks at thoughtbot and other places, volunteers, and donors, and supporters, really made Q Chat Space a reality, but I was the lead on it. And again, I used, you know, off-the-shelf products, basically.

+ +

And I have a developer for the website. But besides that developer, who is a part-time person, we manage. We figure things out ourselves. We get help from volunteers. We bring in a consultant here and there. But we try to keep the technology slim, trim, easy, user-friendly, whatever language we want to use. So that really serves the purpose of the youth. We don't need to be using anything fancy per se.

+ +

CHAD: I could be misremembering, but I think when we were first talking, one of the first conversations we had this came up with Q Chat Space. Because if you look at what it does and the problem set, and particularly the market, I think there could be a tendency for someone looking at that especially, I'm a programmer, and so I want to solve problems by programming things. You could say, "We should really build something specific for this.

+ +

DEBORAH: [laughs]

+ +

CHAD: It's not that difficult. It's just a chat thing. There are lots of these things out there." And I'm right in terms of the actual core functionality. You could bang that out in a little while. But doing that would create a burden then to you have a custom piece of software that you need to constantly evolve, maintain, and those kinds of things. And so I think this was a discussion we had about what was out there in the ecosystem, what open source or other things you could pull together so that we weren't creating that burden.

+ +

DEBORAH: Exactly. And interestingly, my developer has said to me many times, "I could just build something for you." [laughter] And I say, "No, like, I don't need that." And ultimately, we did end up going with an open-sourced product; it's Rocket.Chat. We picked Rocket.Chat. This was in 2017, I think. We looked at 30 different products. And there were that many products on the market already, and today, I think there'll be even more. But ultimately, we just took Rocket.Chat because it's highly customizable. For those of you who aren't familiar with Rocket.Chat, it's like Discord. It's actually the same code, from what I understand. It's sort of like Slack.

+ +

But in the end, we were able to...because there's a lot of like, turn this on, turn this off, turn this on, turn this off, just a lot of different features, we were able to just make it into what we needed. We're using it in a way that very few people are using Rocket.Chat because we opened up a channel just for that hour and a half, and then it's gone. It's not an ongoing conversation. But Rocket.Chat has been a great supporter. They give us a fabulous nonprofit rate and really appreciate the unusual use case that we have for their product.

+ +

CHAD: Yeah, that's great. I think one of the things that hopefully motivates a lot of people is having a positive impact on the world. This is Pride Month. You alluded to it already. And I think it's important that we celebrate Pride. I think you have a great organization that I hope people will get involved in and pay attention to even outside of Pride Month. How has it been for you? And sometimes, it's hard for me to judge are things better or worse in terms of really supporting LGBTQ+ youth today?

+ +

DEBORAH: Both. [laughs] It's better, it's worse. There's no question to how far are we going to go back? But there's so much more media representation, and more schools have GSAs, and more people know someone who's LGBTQ. And I think it's different for lesbian, gay, and bisexual folks than it is for trans and non-binary and gender non-conforming folks. There's more acceptance of sexual orientation differences than there are gender differences. But I think culturally, that's changing, and as a result, there is currently quite a large...the word coming to me is flashback, but that's not the right word. Backlash, push back, exactly.

+ +

And we are seeing alarming numbers of legislative efforts to particularly limit what transgender and gender nonconforming and non-binary youth can do and what their parents can do. And that is very alarming and certainly highly regressive. But I do think that it comes out of the fact that we have moved forward in so many ways.

+ +

So for any young person who's listening or any of you who are listening, you can say this to the young people in your lives like, "You deserve to be yourself. You deserve to be able to be yourself and open. And you deserve a good and strong and mentally healthy life." And that message is really what imi certainly gives, a joyful life. It is about pride. We are proud to be LGBTQ. There's nothing to be ashamed of. And yet there are many forces in our culture and government who do make young people and adults feel shameful about it. So that's really what we're trying to counter.

+ +

CHAD: And that's one of the great things I think about when it comes to online tools is because you could be in an environment where you're not supported, where you don't see that support or people like you, or it could be very isolating. And the ability to reach beyond your family boundaries and geographic boundaries and connect with people who can support you is really great.

+ +

DEBORAH: It is. And to know ultimately, the tools are really designed to acknowledge that some young people have to keep it a secret or private. They're not ready to come out. Both websites have a quick exit, so a young person can click on that and go right to Google. imi also times out after 10 minutes.

+ +

And it's an interesting thing because the folks who are regressive, going back to our last bit, those folks jump on that and say, "Look, they're keeping it a secret from their parents." And we're like, well, if the parents are going to be abusive, then yes, we're going to keep it a secret from their parents. But if the parents want to figure out how to be affirming, we are with them. We want to help them be affirming.

+ +

So it really does allow youth...both tools really reach youth who may feel as if they have no one around them. And imi, in particular, provides community in a way youth don't even have to talk to anybody else. But they're going to hear the voices and see the faces of other young people dealing with similar things. imi is rich with those stories as well as other activities. And then on Q Chat Space, they can connect to a real other teenager who's dealing with similar things but maybe in a different state or a different country even.

+ +

CHAD: I guess that's another...I think the conversation I was having was very U.S.-centric, too. And you think things are bad here; they're even worse in a lot of other places in terms of LGBTQ rights and support.

+ +

DEBORAH: They are.

+ +

CHAD: And I guess that's another benefit of online. It really crosses those boundaries too.

+ +

DEBORAH: It does. And we have enabled that on Q Chat Space and imi. Both are accessible from anywhere in the world. We have heard from youths in 149 other countries, I believe [laughs] on Q Chat Space.

+ +

CHAD: Wow.

+ +

DEBORAH: And we just launched imi, so we don't have that data yet, but it is available. Unfortunately, right now, imi is only in English. Q Chat Space, we do have a weekly chat in Spanish. So we welcome any youth who prefer to chat in Spanish on Monday nights. But imi from now is just in English. But other than that, I mean, the reality of colonization is that a lot of youth speak English, even if it was not their first language. So we have had chatters from Korea, Vietnam, Australia, UK, and everywhere in between.

+ +

CHAD: That's great. If folks want to get involved, where are the best places for them to do that?

+ +

DEBORAH: Sure. So anybody who feels like they can help in any way, whether it's tech help, or with financial support, they can connect with us through the websites. And we will happily figure out ways to get engaged. In terms of your more traditional volunteer situation, I recommend folks go to the LGBT Center Directory that we have on CenterLink's website; CenterLink's website is lgbtcenters.org, and find your local LGBT center. They have many opportunities for volunteers as well as support and tech help. If you check out their website and you think it doesn't look so great, [laughter] offer help with their website.

+ +

So there are a lot of ways to get involved in the LGBTQ community between these two products, as well as just the LGBT centers that the two products are really meant to serve. I didn't really mention that, but we have 300+ LGBT centers that are part of the CenterLink network that we work to support, strengthen, and connect. And imi really is a product that none of them would be able to develop on their own. And this way, they're all able to use it as if it was their own. That's one of the beauties that, of course, the greatest impact is for youth. But for our centers to be able to have that kind of resource available to them, we owe a huge thanks to Hopelab for doing that for CenterLink and all of our members.

+ +

CHAD: We're going to include links in the show notes for all of the things that you just mentioned.

+ +

DEBORAH: Awesome.

+ +

CHAD: I really encourage people to if you want to reach out with your time and get involved, that's great. You can also, as Deborah said, go there and donate. If you can't donate your time, but you can donate some money, that'd be great. Deborah, thank you so much for stopping by and sharing with us. I really appreciate it, and I appreciate all the work you do.

+ +

DEBORAH: Absolutely. It was a pleasure. Thanks so much.

+ +

CHAD: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Deborah Levine.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Ypate67P + + ]]> + + Chad Pytel + Deborah Levine + + + 427: BrainStation with Johanna Mikkola + https://podcast.thoughtbot.com/427 + 580f2f68-77f2-4ab5-baf8-0aa075b1fccf + Thu, 16 Jun 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Johanna Mikkola is the Co-Founder and CEO of Wyncode Academy, recently acquired by BrainStation, whose project-based programs have helped over 100,000 professionals launch new careers in the tech industry. + +Chad talks with Johanna about creating a digital skills training bootcamp, the hiring and training market and challenges, and prioritizing inclusion and diversity in the student population. + 41:22 + no + + + Johanna Mikkola is the Co-Founder and CEO of Wyncode Academy, recently acquired by BrainStation, whose project-based programs have helped over 100,000 professionals launch new careers in the tech industry. +Chad talks with Johanna about creating a digital skills training bootcamp, the hiring and training market and challenges, and prioritizing inclusion and diversity in the student population. +BrainStation (https://brainstation.io/) +Follow BrainStation on Twitter (https://twitter.com/brainstation), Facebook (https://www.facebook.com/BrainStation), Instagram (https://www.instagram.com/brainstation/), or LinkedIn (https://www.linkedin.com/school/brainstation/). +Follow Johanna on Twitter (https://twitter.com/JoMikkola) or LinkedIn (https://www.linkedin.com/in/johanna-mikkola/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. And with me today is Jo Mikkola, the Co-Founder, and CEO of Wyncode Academy, recently acquired by BrainStation, whose project-based programs have helped over 100,000 professionals launch new careers in the tech industry. Jo, thank you for joining me. +JOHANNA: So excited to be here. Thank you. +CHAD: I actually think that the weather we're calling from today might not be so different. It's very warm and sunny, and everything in Boston. So I'm pretty happy today. How are things where you are? +JOHANNA: That's great. We're coming to you live from the 305 in Miami, and it's turning into summertime here, which means it's pretty hot and sticky. But I'm originally from Finland, so I can't complain. +CHAD: [laughs] +JOHANNA: The novelty after eight years of living here has not worn off on me. I do enjoy the sunshine and the palm trees. +CHAD: That's great. So we'll definitely circle back and talk about Miami and the tech industry there and everything. But before we do that, I'm curious; you have recently been acquired by BrainStation. Let's rewind a little bit to getting started with Wyncode and what brought you to creating a digital skills training bootcamp. +JOHANNA: It's been quite the journey. It all started back in 2013, and at the time living in Toronto. I, at that point, had been working at the National Hockey League in Toronto for eight years and had just joined the management there on the hockey operations officiating team, which was an amazing chapter of my professional journey, and I love all the individuals that I worked with there. But I got to a point in that career where I didn't quite know what the next step would be professionally, and I was looking at getting an MBA. +But at the same time, while I was working at the NHL, I was helping lead an internal software build project. And it kept coming to the forefront for me that wow, hockey is being disrupted by technology or technology is being very integrated into something I thought, you know, I didn't think I would see that happen. And at the same time, my co-founder, who's also my husband, we're both from Finland. His name is Juha. He was an entrepreneur in the e-commerce sporting goods space, and he actually had joined a coding bootcamp in Toronto, an early one. +And as he was going through the process, we were both kind of at this inflection point professionally about what we were going to do. And so everything he was learning, the transformation of individuals he was witnessing first-hand, him experiencing that himself, and me being a non-technical business person leading a technical project at the NHL, we were like, wow, we're on the cusp of some serious change in the world, and we want to be part of that wave. So we were like, where can we go and be first to market to provide this life-changing, career-changing education and, in turn, really dive into not only education but also the technology space? +And ultimately, we landed on Miami. We had actually looked at Austin, Texas, and Los Angeles as options as well. But we arrived here in Miami, and it was very like a Hollywood thing. We were sitting at the coolest cafe in Miami at the time. We were here on Christmas holiday. And we, on a napkin, started writing ideas and brainstorming. You know, founders get very excited about logos and brainstorming names, or at least I do. +CHAD: [laughs] +JOHANNA: And it all came together really quickly. That was December 2013. We attended a startup meet-up here. We met four key players in this ecosystem, some of which are major drivers today, like the Knight Foundation and Endeavor. We heard their vision, and what they were doing, and how much funding was being put at the time into building a tech ecosystem in Miami. And we were like, wow, we want in. So we went from concept to launch in three months’ time. +And it was a pretty exciting ride. I mean, so much happened in that time [laughs], and obviously, the acquisition came early last year. And so we've kind of seen it go full circle. And for me professionally, I went from being a startup founder working very regionally, being somewhat nationally known but being a strong regional player, to being a global player overnight with BrainStation. So that also has been really exciting. +CHAD: At thoughtbot, we helped create a web development bootcamp around the same time actually. +JOHANNA: Love that. +CHAD: And that was for Kaplan, and they ended up purchasing Dev Bootcamp and then shutting it down. So I have some experience, and not only that, but thoughtbot has hired a lot of people from bootcamps into our apprentice program. +JOHANNA: Love that. +CHAD: So, from a hiring and training perspective, I think it's great. From a business perspective, it seems to have been a very challenging market. How did you weather that? +JOHANNA: Oh yeah. I mean persistence, unwavering commitment to the people we worked with, and the people we were helping gain these skills to change their careers. And like with any startup, there are moments where it's like, wow, you know, this is a big challenge. How are we going to overcome this? But we've always had the mentality of if there is a will, there is a way. And don't get me wrong, it doesn't always work out. But fortunately, now that I have hindsight, I can say that that mentality resulted in where we are today, and it was very positive. +And I have the really fortunate position of looking back on those stressful moments and seeing the lessons now, which is such a gift and maybe also alludes to me being old, I don't know. [laughter] But it really was a great journey. And I mean, the challenges started in the beginning for us, which is turns out it was a federal offense to operate without a license in the state of Florida, you know, lots of details to talk about there. But come full circle, we ended up being the first coding bootcamp to be licensed by a State Department of Education in the entire country. +So even though other people were operating in their states, it was different statutes, different legal requirements. And so, we were the first to be licensed. And as a result, we actually helped advise some of those other big names that we all see in the coding landscape to explain how it worked for us. And shout out to the Florida Department of Education and Commission for Independent Education for working with us to make it all come together. But it started off with a very exciting beginning getting that letter, which was essentially telling us to shut down before we had even begun. [laughter] And it all worked out. And we have a great relationship with them. And we learned a lot there. +And I will say just in the coding landscape, what ended up happening and what's happened with a lot of for-profit education is there was a huge opportunity, and there still is. People really genuinely need these skills. They really need this vocational training, and the companies hiring really need this talent, as you know firsthand. And so a lot of people jumped in and saw that there was money to be made because professionals and maybe also people who can afford it...there are a lot of financing companies that came in. +And so the thing that started wavering is the quality in terms of the training. And that's one of the things that you just, you know, one of the things we were unwilling to compromise at Wyncode and also why BrainStation, I like to say, is our soulmate because they feel the same way. To go from zero to software engineer or zero to UX designer (We also teach data science and digital marketing.), it really takes high-quality education, high-quality educators, and a high-quality network to do that at the level that we want to do that. +And then the other thing that a lot of people fell into is this desire to scale really quickly, so take in too many students which quality goes down, open too many locations, quality goes down. And to be the best, you got to learn from the best, and that means learning from software engineers, product designers, individuals who are really highly sought after right now. So, in the same way that software companies are facing talent issues, for us, that was also a key piece for us to solve and work out. +We're really fortunate that in the space of education, this is such rewarding work. We build such amazing relationships with the people coming through the programs and, in turn, are contributing so much to our local ecosystems that it hasn't been that hard to attract amazing talent to be our educators because it is so rewarding. They're getting an opportunity to apply their craft to something they love and really shape the minds of future technologists. And it's just a wonderful thing to watch and be part of, so really fortunate to be in that space. +CHAD: Correct me if I'm wrong, but I think that's one of the things that has made the space challenging is you come into it with the desire to have that really high quality, but there's a cost to that. And if you don't scale the number of students, you might have trouble covering that cost. How did you balance that? +JOHANNA: In the early days of Wyncode, it was easy because we were self-funded, and we were growing organically. So we were quite conservative about how we scaled and how many people we took on, and we stayed very true to that. And honestly, we stayed very focused on the state of Florida. So at one point, we actually had three locations; we had Miami Beach, Fort Lauderdale, and Miami, and we scaled them down to have a large HQ in Miami. Because we saw that when the team was together, and the community was together, the overall experience from network to learning was better because we were self-funded. +And then, later, when we had partners who were committed to quality, we were able to make decisions for the sake of quality instead of profitability. And then now with BrainStation, I mean, BrainStation is an incredible company. It's been around for ten years. It has been very successful. And right now, what we've been able to do is invest. BrainStation is in a position where we're investing in different pilots to see what things will make learning even better than it already is, although I will say it's at a really high quality right now. +And so we're in a fortunate position where, of course, it still needs to make sense. The unit economics needs to make sense. But we're also doing everything we can to continually iterate and make it a great environment for people to learn in. And I think that has come with taking the approach that we're in a long-term marathon. We're not in a sprint with what we're building right now. And I think a lot of the companies in this space that ran into issues were really sprinting to a certain scale, which is a way of operating that we haven't operated. +CHAD: Well, so based on what you've said so far, I can make certain assumptions about how you answer this next question. +JOHANNA: [laughs] +CHAD: But I think it's an important topic, and so I want to make sure even if it's obvious that we talk about it and that's how to bring in students, how to scale the business while still prioritizing inclusion and diversity in the student population, in your organization. What sort of attention did you put on that? +JOHANNA: Yeah, so this is a really key one. I mean, in the early days of Wyncode, we were able to do things in a different way than we are now with BrainStation. But I would say Miami is naturally a very diverse and international ecosystem. And so, from the beginning, we really wanted to see that reflected in the people who were in our programs because I knew that would, in the long term, provide so much value to building a great ecosystem. +And so, in the beginning, we partnered...we worked very hard to partner with The Knight Foundation to launch what was called The Future Leaders of Tech Fellowship. This is an example of something we did with different groups throughout all the years and continue to do today, but I'll use Knight as the example, which essentially was a full-ride scholarship for underrepresented individuals in technology. So the first iteration we ran of that was a full-ride scholarship because we thought that was the main barrier. +Then we realized that a lot of these individuals who hadn't had the means before and didn't necessarily have the educational training needed a little extra training, and they needed to start working right away. So what we created was a pre-program for them. It was a full-ride scholarship, and then it was a guaranteed three-month paid internship at a tech company. And of all the people who went through that program, the majority transitioned, with the exception of two, transitioned into full-time salaried roles. And those are incredible stories that are truly life-changing. +But I think the important thing there and what we learned over time is people need support, financial and educational, and they need time. So obviously, in an accelerated learning program, you want things to go as quickly as possible but through the help of partners and making it work for certain communities, we were able to do that. We also partnered with the YMW...it's the Women's...YMCA for women. I cannot remember the acronym right now. +CHAD: WYMCA. +JOHANNA: Thank you. Thank you. We provided a program in-house for them specifically. +CHAD: No, it would be the YWCA. +[laughter] +JOHANNA: Yeah. +CHAD: Sorry to interrupt you. +JOHANNA: I'm sorry. I'm not doing you all a good service here. But it's an amazing organization here in Miami. And that was geared specifically towards women from disadvantaged backgrounds, giving them the education they needed. And with that group, we had actually a 70% success rate, which was wonderful. Those are individuals who had no options for any type of white-collar position, many of whom we still keep in touch with today. +So, in the beginning, with diversity and inclusion, we were doing things at a smaller scale, very specialized, and very catered to make sure that they were successful in the hope of eventually building more momentum to do this. And the work very much continues. So BrainStation, larger company, we have a lot more firepower in terms of what we're able to do. +So we've partnered with companies like Ernst & Young, Shutterstock, Microsoft with our Impact Scholarship, which is also full-ride scholarships for the underrepresented communities in technology, and that's been really successful as well. And, again, education is really rewarding, but it's also really rewarding to see, in particular, those success stories. +CHAD: Yeah, one of the things when I speak at bootcamps or when I talk to apprentices who are joining us, I often reinforce or remind them that they bring something to the table, which is really special. I started programming when I was in middle school. I went to school for computer science. Aside from a brief stint as a dishwasher and a checkout person at a grocery store, this is all I've ever done. And I recognize that that has pros and cons. +Like, I just don't have the same perspective and diversity of experience, let alone actual demographic diversity that many of our team members bring to the table. And there's something special in that, whether it be from your experience working in another industry like hospitality or something like that. You bring a perspective. There are so many hospitality startups, for example, that would love to bring a new developer onto their team who actually has industry experience. It makes it very powerful for people. +JOHANNA: Yeah, absolutely. And I think oftentimes, people in anything when you're transitioning a career, there's maybe a little bit of imposter syndrome or a lack of confidence. And I see oftentimes not only minority groups but everyone shying away from their previous professional backgrounds. But technology is built for us, for humans who are very diverse in background experience and the products and services that we need. And so we really try to emphasize at Wyncode and at BrainStation to lean into your past profession. Because if you can bring that through and really focus on the things you learn there, you can provide so much firepower to what you're building with technology, and it’s super important. +And I will say healthtech is big in South Florida. And so we have had various people with some type of health background, whether they were an assistant or worked in a medical office, or we've had a few doctors go through the program. They were, as you can imagine, really sought after for the healthtech companies because not only do they bring technology skills, but they have this understanding that no one else does. So it's really unique. +CHAD: You're part of the tech industry now. [laughter] How has that diversity of background...you mentioned at the beginning, at the top of the episode that you were originally at the NHL, to starting to lead software projects there. How have you leveraged that for yourself and for your business? +JOHANNA: Oh yeah, 100%. So we do an exercise at BrainStation where you have a chart, and you plot out your past professions, and you look at the things that you learned, and the mistakes you made, and the things you didn't like, to start to build a thread of what are things carrying over? And for me, the thing that has come to the forefront is technology or not...and I feel like anyone investing is also saying this all the time, and maybe founders say it too. But it always comes down to people and relationships and how you are listening and taking in the information to then digest it and deliver something. +And so, I think my ability to connect with people and mobilize people around common goals is something that has been a common thread throughout my career. It's interesting. I'll say some of the best things I learned as a founder came from engineers, the first being agile. Like, we weren't operating like an agile company in the beginning because we weren't a software company. And our very first hire was a guy named Ed Toro, an MIT graduate. Shout out to Ed. It's actually his birthday. +CHAD: [laughs] +JOHANNA: Incredible, incredible engineer originally from Boston. He was our lead educator for software for so long. And he just brought so much knowledge to us about how software is built and works. And we integrated that into how we operated as business people and organized the company. I mean, it's amazing. I actually don't remember what it's like to not be organized in that manner anymore. Although I can tell you going from the NHL to Wyncode was a huge jump because NHL, even though we were using and leveraging technology, was still organized very traditionally. +And so I'll give you a simple thing, some software teams...I know a lot of software engineers appreciate transparency. So, in addition to organizing in a very agile method in terms of how we operated the business, we also pivoted to be extremely transparent as a team as well in terms of how the company is doing, which is something that is not common in a multibillion-dollar industry like the NHL. Although you see that more and more with tech companies, which is interesting. +CHAD: How long ago did you join up with BrainStation? +JOHANNA: So we were introduced to the founders and owners of BrainStation really because they were potentially looking at coming to Florida. And a mutual friend, a mutual business person, had said, "Hey, you know, if you guys are looking at Florida, probably you guys should meet Jo and Juha. They built something called Wyncode. You're going to get to know them anyway." And so I would say a little bit over a year and a half ago, we started chatting. And we realized that we had a lot in common in terms of how we had built the businesses, where we wanted to see the business go. And the rest isn't history because we're a year and a half in. +CHAD: [laughs] +JOHANNA: So you know what happened. It all worked out. It's really great but also really excited for the future. Because now with the BrainStation acquisition comes a lot of firepower in terms of experience on the team, much larger team, capital, reach of team. We have students in over 100 countries. So I'm very excited for what we're going to do in the future as well because we can have so much more impact, and that is really exciting as well. +Mid-Roll Ad: +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: You mentioned before you had a very Florida-specific focus previously. Is part of this next stage to be working across BrainStation and really working more globally? +JOHANNA: Yeah, so working regionally with a focus on South Florida but with the know-how and the resources of a global team for sure. And being on the senior leadership team here, I am still 100% focused on Florida, but I get to have perspective from all the other markets. We have five campuses in New York, Toronto, Vancouver, London, and now Miami. So that's very interesting. And I have to say, when we were running Wyncode, we were always like, man, I wonder, how it's going in New York? +CHAD: [laughs] +JOHANNA: Or I wonder how it's going in Vancouver. Well, now I know. So it is really interesting because it also gives you not only a perspective in terms of bootcamps and how that's going but also a perspective on those ecosystems and how the tech companies there are growing and hiring. Because we're at that really interesting spot where we always know everyone's closed a round of funding because they go on a hiring spree. And then we see the bigger companies who are continually hiring. So we always kind of have a little bit of a pulse on what's going on in all of the ecosystems. +And also really, before, we were primarily American students in the southeast, but now as BrainStation, I mean, it's global. So seeing how different everyone is but also still so similar in terms of their end goals and collaborative, it's really special. And yeah, it's been great. +CHAD: So you have the campuses, the geographic locations, and then you have the global students. Are they in different silos, or do the two groups of students interact with each other at all? +JOHANNA: Yeah, great question. So we do execute our..., and we call them diploma programs for the bootcamp programs, both online and in person. So as you can imagine, students in over 100 countries we're executing in all the time zones because of online delivery. But much of that, if they're outside of the geographic region of one of our campuses, they're likely an online student. +CHAD: Are they being taught by an instructor in one of the campuses, or is it a separate thing? +JOHANNA: Yeah, our educators are located in our campuses geographically. +CHAD: How did the pandemic change or not change the experience of students, and what you needed to offer? +JOHANNA: Wyncode, at the time, we were still Wyncode when the pandemic hit. I'll never forget having an all-hands meeting in our conference room and being like, hey...it was a Thursday. We're like, come Monday; we're going fully remote. We weren't a remote educator at that time. Everybody needs special permissions and licenses to also have remote teaching, which most governments made exceptions for because of the pandemic. So we were all good there. +But we were thinking at the time, oh, maybe it'll be a month. Well, two years later, we're just about to have our grand reopening of the space in Miami. Our other campuses have already opened. And it was pretty exciting. When the pandemic hit, there was definitely an oh no moment. Like, people paused their enrollments, understandably. That was March. But as we got into early summer, we actually saw enrollment skyrocket. So huge success was pivoting to go remote. +We were very fortunate that we had a pretty seasoned senior team on our software and UX side. And they had been through the world of remote learning and just being on tech, you know, Yahoo, Google. They had worked at Yahoo, Google, so they knew remote, and they were able to help us and bring that expertise. So the transition to remote was easy. And then we got all these students. And actually, that started a wave which has continued to this day of really people having an appetite for online learning and continuing to want to pivot careers into technology, both out of individuals' interests for technology but also because of the demand. +So the pandemic was terrible. Business-wise for sure, there have been challenges, but there have, I would say, been a lot more successes and opportunities as a result of the pandemic. And for me personally as an entrepreneur, the pandemic got us, you know, we were doing well and having a lot of success, so the pandemic also got us on the radar for BrainStation. We started that conversation, and that was really exciting. And, again, here we are as a global educator now. +CHAD: I've talked to a lot of people and seen it in our applications as well, like, it was really two things: people losing their jobs because of the pandemic and then getting that opportunity to take a look around and say, you know what? I'm not going back to that industry, and I want to learn to code. +And then a lot of other people saying, you know, sort of the great resignation kind of stuff saying like, I want to change and actively switching as well. And you can see it in our applications the number of switchers, the number of people who have taken the last year, year and a half to do a remote bootcamp and make a career transition. It was always high. It's even higher now. +JOHANNA: Yeah, totally agree, like, very respective of what we see as well. And we've had a great relationship with CareerSource South Florida as well. And they fund workforce transformation. And so initially in the pandemic...we're not seeing those layoffs now, but initially, a lot of those people who were getting laid off many of them were able to qualify for CareerSource as well, which also really fueled people's ability to take part in this education. +And South Florida is interesting. I think 65% of the workforce before the pandemic...a lot has changed. Tech has moved in, a lot of big names have moved in. But before the pandemic, 65% of people professionally here were working in hospitality or real estate so it was definitely a big pivot for some people to go into the direction of technology. +CHAD: That's great to hear that they were able to be helped by that because that can be a big impediment to this. I believe that the cost of an average bootcamp for what you actually get and for the impact it can have on your salary or your compensation is worth it. But if you can't afford the tuition, then it's a non-starter. +JOHANNA: Yeah, yeah, exactly. And then it goes without saying, but there are some people...there are a lot of opportunities. There are a lot of jobs. There are a lot of ways to get in, but it doesn't mean that it's for everyone. And I think for us, some of the work that's required to get into the program in our admissions process and our advisors who spend a lot of time with people considering this are also helping people guide this thought process of what they go into and what they're going to do to decide if it's the right direction for them. +And I think ultimately, the large majority who come in have done good research and good work and have really thought it through, and it's a good fit. But again, it's not for everyone. So it goes without saying it's good to go online, do some coding. Download Figma if you're going to go into UX. Tinker around with some stuff. Ask some people, go to some meetups, and then start looking into the education piece. +CHAD: Yeah. Are there ways in which you're exploring how either through partnerships or that kind of thing like it sounds like you've done to make it more accessible to people? +JOHANNA: Yeah, so we put, again, Wyncode and BrainStation now puts a lot of importance on building a diverse, inclusive environment. And the most important thing is just collaborating also with organizations in our various regions that serve communities that are underrepresented in tech so that we can provide certain pathways to this. And one of the key things that we're doing with our Impact Scholarships, I think we've committed over $1.2 million just as BrainStation to giving those pathways. +The other thing that we're piloting right now is what we're calling Tuition Free. So we piloted in London. Miami is the only other city we're testing it with in-person learning, not online, but it being completely tuition-free for the individual coming into the program, which we're calling a trainee. And then working with some amazing partners here in South Florida, in London who essentially, if they opt to hire someone for the program, are going to be paying a percentage training fee for hiring that individual. +So we're really excited to be piloting what's called a reverse model. But more so, training people in a very specific skill set that companies need, eliminating financial barriers as much as possible, and then also providing a very robust, rapid pathway for this incredible talent to then join companies. And maybe we'll do a synopsis in about a year, and I'll let you know how it all went. +CHAD: [laughs] That'd be great. That'd be great. So a common thread throughout this conversation has been Miami, and it's come on my radar recently in terms of the ecosystem there and how it's expanded and grown significantly over the last several years. You mentioned you picked up and moved there because you identified it as a great market. What has it been like for you? +JOHANNA: It's been a whirlwind. I mean, #Miamitechisonfire, literally. +CHAD: [laughs] +JOHANNA: It's a pretty exciting time to be here. I got to say, when we moved in 2014, our campus was and still is based in Wynwood, which is a wonderful creative space but also mixed in with tech companies. +CHAD: Is that why it's called what it's called, Wyncode? +JOHANNA: Yeah, that's right. [laughs] Wyncode and Wynwood, yep. So the landlords knew they really had all the leverage, right? But we have had, and I've always had, an amazing space here. And when we first opened, the biggest complaint we got from people who took the program was there were not enough places to eat. And for anyone who's listening who's from Miami and spent time in Wynwood, that sounds crazy because now all the hottest restaurants are here in Wynwood. And that's happened in the span of, you know, I know we've been here for eight years, but that's happened like in the last five years. +So a lot has changed. Wynwood is kind of an analogy to what's happened in the rest of Miami. It was kind of like a little bit quiet and slow, known for hospitality, awesome partying, real estate, not really known for all of this other stuff. The pandemic, again, was horrible from a business standpoint, terrible for some people, amazing for others. It was amazing for Miami. The state of Florida remained relatively open throughout the pandemic. So that attracted people here. The tax situation, no income tax, has also been very appealing, particularly for anyone who's made a lot of money in tech and crypto, in particular from Miami. +And then we have this incredible Mayor, Mayor Francis Suarez, who, long before what's happening now, has been an advocate and supporter of the tech ecosystem and startup founders here, which I've personally had experience with. He's been amazing. You know, in Silicon Valley, there was some social media going on for anyone who saw it on Twitter, and he tweeted back, and he said, "Hey, Miami would love to have you, guys. How can we help?" +And so there's this tagline in Miami which is how can we help? Trying to be an ecosystem that's here to help that's open to all. And that's been going on now for almost two years. And as a result, there's been a huge number of people in technology in particular who have moved here, both big names like Jon Oringer, Founder of Shutterstock, Keith Rabois, Founders Fund. There are so many people to name down to founders who are like; I'm starting a new startup. I don't want to do it in New York or Silicon Valley. I want to do it in Miami. So that's really exciting. +I can tell you; there's more going on here than I could...before I could keep an Easy Calendar, I knew everyone. I knew what events were going on when and now it's just...there are multiple events, meetups, multiple companies to meet. So it's really, really an exciting time. I think Mayor Francis Suarez has said this, too but definitely making a play to be the capital of crypto. So there's a lot going on in the crypto space here, a lot going on in Web3. Like Web3 being at the beginning, this is still at the beginning. This is a moment that we're hoping to turn into a movement, and I think it's really, really exciting. +I don't think everyone is going to stay here. I don't think Miami is going to be the next Silicon Valley or New York. It has its own character. It has its own vibe. It has its own way of functioning, and that's what it is. Its original kind of environment is also what's attracting people. So it's an evolution right now. It's going to change. +The people who have come here and who have been here are all in the process of evolving to what the next chapter of Miami tech is. But it's definitely an exciting time. It was a place for me where I came to professionally reinvent myself as well and really be a part of building an ecosystem. And that's very much true today for anybody who is coming here. And I think that type of opportunity is really, really exciting. There's definitely an energy, yeah. +CHAD: The state of Florida has passed laws like the Woke Act recently, which can present a challenge to employers strictly speaking. You're not allowed to ask certain questions around diversity or inclusion in interviews now. And that can be uncomfortable or difficult to do business in or to say, "Hey, we're the most welcoming company. Come here. Come to Miami." Is that something that's, you know, I'm not there. So is it a challenge on the ground, or does it not really affect people day-to-day? +JOHANNA: I mean, that's a really good question. I would say I haven't encountered it personally or even on the professional side with how we've been hiring. So it's hard to say from my perspective. I think certainly there are some things going on in Florida that Florida and California are very different. I myself I'm not an American. I'm not as involved in the politics. But it'll be interesting to see what happens in the future and how these things shape. +I will say that employers have a lot of power because they're the ones who are bringing in a lot of money into a state. They're hiring people. And so some of the responsibility is also on the companies and employers who are in their respective areas to advocate for the things that they want to see. And one of those things is diversity, inclusion, which not everybody has made that a number one priority. +And the one thing that I've said in the past is creating an inclusive and diverse ecosystem is the opportunity I think that Miami has because it is a less established tech ecosystem. The canvas isn't fully painted over, so we have an opportunity to be unique and be different and to try to avoid maybe some of the biases that have existed in other tech ecosystems. +But at this point, while there has been progress made and there are some amazing individuals doing amazing things like Leigh-Ann Buchanan leading Tech Equity Miami and JPMorgan Chase coming in to support that in a really big way and Knight Foundation, we're still at a state where the minorities are advocating for the minorities. And that's something I hope to one, personally contribute to changing but as an ecosystem as a whole hope to see that happen. Because, like I said, Miami is attracting people for a certain reason, and that's great. And I think if we could build a diverse ecosystem, that would also attract certain people and retain certain people. +And I am a firm believer, and, I mean, there are also stats to back it up, but the best products are built by the most diverse teams. So it goes without saying that the most diverse ecosystem is going to result in the best companies, best environment, et cetera. And I think that's the big opportunity for Miami, but we still have a lot of work to do to get there. +CHAD: Yeah. Well, if folks want to follow along with you or get in touch with you or learn more about BrainStation, where are all the places that they can do that? +JOHANNA: Yeah. I would love to connect with everyone. On LinkedIn, we have all of our respective social handles just at BrainStation. Even our Wyncode handles are still alive, so that's great. My parting words would be if you know someone amazing, a professional who wants to pivot careers and learn in person, now is an amazing opportunity to apply to BrainStation for incredible education and network. And I'm really looking forward to seeing amazing professionals come through the program. +CHAD: And I assume if you're in a position where you're hiring talent that you should also check out BrainStation. +JOHANNA: Yes, thank you, Chad. We 100% the thing we take the most pride in is connecting this amazing talent with awesome companies. I always like to tell everyone to keep a very wide lens on the type of talent you're hiring for your technology teams because some of the best individuals have very non-traditional tech backgrounds but bring so, so much to the table. +Our team does a lot of work in terms of once we get to know a partner, which I would love for you all to reach out and join; we do a lot of work to make sure that we are connecting curated talent to companies. And if you go to brainstation.io/hiring-partners, you'll be able to sign up there. +CHAD: Wonderful. Jo, thank you so much for joining me. I really appreciate it. +JOHANNA: Great. Thank you so much. Great to be on. +CHAD: You can subscribe to the show and find notes and a transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Johanna Mikkola. + + + Johanna Mikkola is the Co-Founder and CEO of Wyncode Academy, recently acquired by BrainStation, whose project-based programs have helped over 100,000 professionals launch new careers in the tech industry.

+ +

Chad talks with Johanna about creating a digital skills training bootcamp, the hiring and training market and challenges, and prioritizing inclusion and diversity in the student population.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. And with me today is Jo Mikkola, the Co-Founder, and CEO of Wyncode Academy, recently acquired by BrainStation, whose project-based programs have helped over 100,000 professionals launch new careers in the tech industry. Jo, thank you for joining me.

+ +

JOHANNA: So excited to be here. Thank you.

+ +

CHAD: I actually think that the weather we're calling from today might not be so different. It's very warm and sunny, and everything in Boston. So I'm pretty happy today. How are things where you are?

+ +

JOHANNA: That's great. We're coming to you live from the 305 in Miami, and it's turning into summertime here, which means it's pretty hot and sticky. But I'm originally from Finland, so I can't complain.

+ +

CHAD: [laughs]

+ +

JOHANNA: The novelty after eight years of living here has not worn off on me. I do enjoy the sunshine and the palm trees.

+ +

CHAD: That's great. So we'll definitely circle back and talk about Miami and the tech industry there and everything. But before we do that, I'm curious; you have recently been acquired by BrainStation. Let's rewind a little bit to getting started with Wyncode and what brought you to creating a digital skills training bootcamp.

+ +

JOHANNA: It's been quite the journey. It all started back in 2013, and at the time living in Toronto. I, at that point, had been working at the National Hockey League in Toronto for eight years and had just joined the management there on the hockey operations officiating team, which was an amazing chapter of my professional journey, and I love all the individuals that I worked with there. But I got to a point in that career where I didn't quite know what the next step would be professionally, and I was looking at getting an MBA.

+ +

But at the same time, while I was working at the NHL, I was helping lead an internal software build project. And it kept coming to the forefront for me that wow, hockey is being disrupted by technology or technology is being very integrated into something I thought, you know, I didn't think I would see that happen. And at the same time, my co-founder, who's also my husband, we're both from Finland. His name is Juha. He was an entrepreneur in the e-commerce sporting goods space, and he actually had joined a coding bootcamp in Toronto, an early one.

+ +

And as he was going through the process, we were both kind of at this inflection point professionally about what we were going to do. And so everything he was learning, the transformation of individuals he was witnessing first-hand, him experiencing that himself, and me being a non-technical business person leading a technical project at the NHL, we were like, wow, we're on the cusp of some serious change in the world, and we want to be part of that wave. So we were like, where can we go and be first to market to provide this life-changing, career-changing education and, in turn, really dive into not only education but also the technology space?

+ +

And ultimately, we landed on Miami. We had actually looked at Austin, Texas, and Los Angeles as options as well. But we arrived here in Miami, and it was very like a Hollywood thing. We were sitting at the coolest cafe in Miami at the time. We were here on Christmas holiday. And we, on a napkin, started writing ideas and brainstorming. You know, founders get very excited about logos and brainstorming names, or at least I do.

+ +

CHAD: [laughs]

+ +

JOHANNA: And it all came together really quickly. That was December 2013. We attended a startup meet-up here. We met four key players in this ecosystem, some of which are major drivers today, like the Knight Foundation and Endeavor. We heard their vision, and what they were doing, and how much funding was being put at the time into building a tech ecosystem in Miami. And we were like, wow, we want in. So we went from concept to launch in three months’ time.

+ +

And it was a pretty exciting ride. I mean, so much happened in that time [laughs], and obviously, the acquisition came early last year. And so we've kind of seen it go full circle. And for me professionally, I went from being a startup founder working very regionally, being somewhat nationally known but being a strong regional player, to being a global player overnight with BrainStation. So that also has been really exciting.

+ +

CHAD: At thoughtbot, we helped create a web development bootcamp around the same time actually.

+ +

JOHANNA: Love that.

+ +

CHAD: And that was for Kaplan, and they ended up purchasing Dev Bootcamp and then shutting it down. So I have some experience, and not only that, but thoughtbot has hired a lot of people from bootcamps into our apprentice program.

+ +

JOHANNA: Love that.

+ +

CHAD: So, from a hiring and training perspective, I think it's great. From a business perspective, it seems to have been a very challenging market. How did you weather that?

+ +

JOHANNA: Oh yeah. I mean persistence, unwavering commitment to the people we worked with, and the people we were helping gain these skills to change their careers. And like with any startup, there are moments where it's like, wow, you know, this is a big challenge. How are we going to overcome this? But we've always had the mentality of if there is a will, there is a way. And don't get me wrong, it doesn't always work out. But fortunately, now that I have hindsight, I can say that that mentality resulted in where we are today, and it was very positive.

+ +

And I have the really fortunate position of looking back on those stressful moments and seeing the lessons now, which is such a gift and maybe also alludes to me being old, I don't know. [laughter] But it really was a great journey. And I mean, the challenges started in the beginning for us, which is turns out it was a federal offense to operate without a license in the state of Florida, you know, lots of details to talk about there. But come full circle, we ended up being the first coding bootcamp to be licensed by a State Department of Education in the entire country.

+ +

So even though other people were operating in their states, it was different statutes, different legal requirements. And so, we were the first to be licensed. And as a result, we actually helped advise some of those other big names that we all see in the coding landscape to explain how it worked for us. And shout out to the Florida Department of Education and Commission for Independent Education for working with us to make it all come together. But it started off with a very exciting beginning getting that letter, which was essentially telling us to shut down before we had even begun. [laughter] And it all worked out. And we have a great relationship with them. And we learned a lot there.

+ +

And I will say just in the coding landscape, what ended up happening and what's happened with a lot of for-profit education is there was a huge opportunity, and there still is. People really genuinely need these skills. They really need this vocational training, and the companies hiring really need this talent, as you know firsthand. And so a lot of people jumped in and saw that there was money to be made because professionals and maybe also people who can afford it...there are a lot of financing companies that came in.

+ +

And so the thing that started wavering is the quality in terms of the training. And that's one of the things that you just, you know, one of the things we were unwilling to compromise at Wyncode and also why BrainStation, I like to say, is our soulmate because they feel the same way. To go from zero to software engineer or zero to UX designer (We also teach data science and digital marketing.), it really takes high-quality education, high-quality educators, and a high-quality network to do that at the level that we want to do that.

+ +

And then the other thing that a lot of people fell into is this desire to scale really quickly, so take in too many students which quality goes down, open too many locations, quality goes down. And to be the best, you got to learn from the best, and that means learning from software engineers, product designers, individuals who are really highly sought after right now. So, in the same way that software companies are facing talent issues, for us, that was also a key piece for us to solve and work out.

+ +

We're really fortunate that in the space of education, this is such rewarding work. We build such amazing relationships with the people coming through the programs and, in turn, are contributing so much to our local ecosystems that it hasn't been that hard to attract amazing talent to be our educators because it is so rewarding. They're getting an opportunity to apply their craft to something they love and really shape the minds of future technologists. And it's just a wonderful thing to watch and be part of, so really fortunate to be in that space.

+ +

CHAD: Correct me if I'm wrong, but I think that's one of the things that has made the space challenging is you come into it with the desire to have that really high quality, but there's a cost to that. And if you don't scale the number of students, you might have trouble covering that cost. How did you balance that?

+ +

JOHANNA: In the early days of Wyncode, it was easy because we were self-funded, and we were growing organically. So we were quite conservative about how we scaled and how many people we took on, and we stayed very true to that. And honestly, we stayed very focused on the state of Florida. So at one point, we actually had three locations; we had Miami Beach, Fort Lauderdale, and Miami, and we scaled them down to have a large HQ in Miami. Because we saw that when the team was together, and the community was together, the overall experience from network to learning was better because we were self-funded.

+ +

And then, later, when we had partners who were committed to quality, we were able to make decisions for the sake of quality instead of profitability. And then now with BrainStation, I mean, BrainStation is an incredible company. It's been around for ten years. It has been very successful. And right now, what we've been able to do is invest. BrainStation is in a position where we're investing in different pilots to see what things will make learning even better than it already is, although I will say it's at a really high quality right now.

+ +

And so we're in a fortunate position where, of course, it still needs to make sense. The unit economics needs to make sense. But we're also doing everything we can to continually iterate and make it a great environment for people to learn in. And I think that has come with taking the approach that we're in a long-term marathon. We're not in a sprint with what we're building right now. And I think a lot of the companies in this space that ran into issues were really sprinting to a certain scale, which is a way of operating that we haven't operated.

+ +

CHAD: Well, so based on what you've said so far, I can make certain assumptions about how you answer this next question.

+ +

JOHANNA: [laughs]

+ +

CHAD: But I think it's an important topic, and so I want to make sure even if it's obvious that we talk about it and that's how to bring in students, how to scale the business while still prioritizing inclusion and diversity in the student population, in your organization. What sort of attention did you put on that?

+ +

JOHANNA: Yeah, so this is a really key one. I mean, in the early days of Wyncode, we were able to do things in a different way than we are now with BrainStation. But I would say Miami is naturally a very diverse and international ecosystem. And so, from the beginning, we really wanted to see that reflected in the people who were in our programs because I knew that would, in the long term, provide so much value to building a great ecosystem.

+ +

And so, in the beginning, we partnered...we worked very hard to partner with The Knight Foundation to launch what was called The Future Leaders of Tech Fellowship. This is an example of something we did with different groups throughout all the years and continue to do today, but I'll use Knight as the example, which essentially was a full-ride scholarship for underrepresented individuals in technology. So the first iteration we ran of that was a full-ride scholarship because we thought that was the main barrier.

+ +

Then we realized that a lot of these individuals who hadn't had the means before and didn't necessarily have the educational training needed a little extra training, and they needed to start working right away. So what we created was a pre-program for them. It was a full-ride scholarship, and then it was a guaranteed three-month paid internship at a tech company. And of all the people who went through that program, the majority transitioned, with the exception of two, transitioned into full-time salaried roles. And those are incredible stories that are truly life-changing.

+ +

But I think the important thing there and what we learned over time is people need support, financial and educational, and they need time. So obviously, in an accelerated learning program, you want things to go as quickly as possible but through the help of partners and making it work for certain communities, we were able to do that. We also partnered with the YMW...it's the Women's...YMCA for women. I cannot remember the acronym right now.

+ +

CHAD: WYMCA.

+ +

JOHANNA: Thank you. Thank you. We provided a program in-house for them specifically.

+ +

CHAD: No, it would be the YWCA.

+ +

[laughter]

+ +

JOHANNA: Yeah.

+ +

CHAD: Sorry to interrupt you.

+ +

JOHANNA: I'm sorry. I'm not doing you all a good service here. But it's an amazing organization here in Miami. And that was geared specifically towards women from disadvantaged backgrounds, giving them the education they needed. And with that group, we had actually a 70% success rate, which was wonderful. Those are individuals who had no options for any type of white-collar position, many of whom we still keep in touch with today.

+ +

So, in the beginning, with diversity and inclusion, we were doing things at a smaller scale, very specialized, and very catered to make sure that they were successful in the hope of eventually building more momentum to do this. And the work very much continues. So BrainStation, larger company, we have a lot more firepower in terms of what we're able to do.

+ +

So we've partnered with companies like Ernst & Young, Shutterstock, Microsoft with our Impact Scholarship, which is also full-ride scholarships for the underrepresented communities in technology, and that's been really successful as well. And, again, education is really rewarding, but it's also really rewarding to see, in particular, those success stories.

+ +

CHAD: Yeah, one of the things when I speak at bootcamps or when I talk to apprentices who are joining us, I often reinforce or remind them that they bring something to the table, which is really special. I started programming when I was in middle school. I went to school for computer science. Aside from a brief stint as a dishwasher and a checkout person at a grocery store, this is all I've ever done. And I recognize that that has pros and cons.

+ +

Like, I just don't have the same perspective and diversity of experience, let alone actual demographic diversity that many of our team members bring to the table. And there's something special in that, whether it be from your experience working in another industry like hospitality or something like that. You bring a perspective. There are so many hospitality startups, for example, that would love to bring a new developer onto their team who actually has industry experience. It makes it very powerful for people.

+ +

JOHANNA: Yeah, absolutely. And I think oftentimes, people in anything when you're transitioning a career, there's maybe a little bit of imposter syndrome or a lack of confidence. And I see oftentimes not only minority groups but everyone shying away from their previous professional backgrounds. But technology is built for us, for humans who are very diverse in background experience and the products and services that we need. And so we really try to emphasize at Wyncode and at BrainStation to lean into your past profession. Because if you can bring that through and really focus on the things you learn there, you can provide so much firepower to what you're building with technology, and it’s super important.

+ +

And I will say healthtech is big in South Florida. And so we have had various people with some type of health background, whether they were an assistant or worked in a medical office, or we've had a few doctors go through the program. They were, as you can imagine, really sought after for the healthtech companies because not only do they bring technology skills, but they have this understanding that no one else does. So it's really unique.

+ +

CHAD: You're part of the tech industry now. [laughter] How has that diversity of background...you mentioned at the beginning, at the top of the episode that you were originally at the NHL, to starting to lead software projects there. How have you leveraged that for yourself and for your business?

+ +

JOHANNA: Oh yeah, 100%. So we do an exercise at BrainStation where you have a chart, and you plot out your past professions, and you look at the things that you learned, and the mistakes you made, and the things you didn't like, to start to build a thread of what are things carrying over? And for me, the thing that has come to the forefront is technology or not...and I feel like anyone investing is also saying this all the time, and maybe founders say it too. But it always comes down to people and relationships and how you are listening and taking in the information to then digest it and deliver something.

+ +

And so, I think my ability to connect with people and mobilize people around common goals is something that has been a common thread throughout my career. It's interesting. I'll say some of the best things I learned as a founder came from engineers, the first being agile. Like, we weren't operating like an agile company in the beginning because we weren't a software company. And our very first hire was a guy named Ed Toro, an MIT graduate. Shout out to Ed. It's actually his birthday.

+ +

CHAD: [laughs]

+ +

JOHANNA: Incredible, incredible engineer originally from Boston. He was our lead educator for software for so long. And he just brought so much knowledge to us about how software is built and works. And we integrated that into how we operated as business people and organized the company. I mean, it's amazing. I actually don't remember what it's like to not be organized in that manner anymore. Although I can tell you going from the NHL to Wyncode was a huge jump because NHL, even though we were using and leveraging technology, was still organized very traditionally.

+ +

And so I'll give you a simple thing, some software teams...I know a lot of software engineers appreciate transparency. So, in addition to organizing in a very agile method in terms of how we operated the business, we also pivoted to be extremely transparent as a team as well in terms of how the company is doing, which is something that is not common in a multibillion-dollar industry like the NHL. Although you see that more and more with tech companies, which is interesting.

+ +

CHAD: How long ago did you join up with BrainStation?

+ +

JOHANNA: So we were introduced to the founders and owners of BrainStation really because they were potentially looking at coming to Florida. And a mutual friend, a mutual business person, had said, "Hey, you know, if you guys are looking at Florida, probably you guys should meet Jo and Juha. They built something called Wyncode. You're going to get to know them anyway." And so I would say a little bit over a year and a half ago, we started chatting. And we realized that we had a lot in common in terms of how we had built the businesses, where we wanted to see the business go. And the rest isn't history because we're a year and a half in.

+ +

CHAD: [laughs]

+ +

JOHANNA: So you know what happened. It all worked out. It's really great but also really excited for the future. Because now with the BrainStation acquisition comes a lot of firepower in terms of experience on the team, much larger team, capital, reach of team. We have students in over 100 countries. So I'm very excited for what we're going to do in the future as well because we can have so much more impact, and that is really exciting as well.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: You mentioned before you had a very Florida-specific focus previously. Is part of this next stage to be working across BrainStation and really working more globally?

+ +

JOHANNA: Yeah, so working regionally with a focus on South Florida but with the know-how and the resources of a global team for sure. And being on the senior leadership team here, I am still 100% focused on Florida, but I get to have perspective from all the other markets. We have five campuses in New York, Toronto, Vancouver, London, and now Miami. So that's very interesting. And I have to say, when we were running Wyncode, we were always like, man, I wonder, how it's going in New York?

+ +

CHAD: [laughs]

+ +

JOHANNA: Or I wonder how it's going in Vancouver. Well, now I know. So it is really interesting because it also gives you not only a perspective in terms of bootcamps and how that's going but also a perspective on those ecosystems and how the tech companies there are growing and hiring. Because we're at that really interesting spot where we always know everyone's closed a round of funding because they go on a hiring spree. And then we see the bigger companies who are continually hiring. So we always kind of have a little bit of a pulse on what's going on in all of the ecosystems.

+ +

And also really, before, we were primarily American students in the southeast, but now as BrainStation, I mean, it's global. So seeing how different everyone is but also still so similar in terms of their end goals and collaborative, it's really special. And yeah, it's been great.

+ +

CHAD: So you have the campuses, the geographic locations, and then you have the global students. Are they in different silos, or do the two groups of students interact with each other at all?

+ +

JOHANNA: Yeah, great question. So we do execute our..., and we call them diploma programs for the bootcamp programs, both online and in person. So as you can imagine, students in over 100 countries we're executing in all the time zones because of online delivery. But much of that, if they're outside of the geographic region of one of our campuses, they're likely an online student.

+ +

CHAD: Are they being taught by an instructor in one of the campuses, or is it a separate thing?

+ +

JOHANNA: Yeah, our educators are located in our campuses geographically.

+ +

CHAD: How did the pandemic change or not change the experience of students, and what you needed to offer?

+ +

JOHANNA: Wyncode, at the time, we were still Wyncode when the pandemic hit. I'll never forget having an all-hands meeting in our conference room and being like, hey...it was a Thursday. We're like, come Monday; we're going fully remote. We weren't a remote educator at that time. Everybody needs special permissions and licenses to also have remote teaching, which most governments made exceptions for because of the pandemic. So we were all good there.

+ +

But we were thinking at the time, oh, maybe it'll be a month. Well, two years later, we're just about to have our grand reopening of the space in Miami. Our other campuses have already opened. And it was pretty exciting. When the pandemic hit, there was definitely an oh no moment. Like, people paused their enrollments, understandably. That was March. But as we got into early summer, we actually saw enrollment skyrocket. So huge success was pivoting to go remote.

+ +

We were very fortunate that we had a pretty seasoned senior team on our software and UX side. And they had been through the world of remote learning and just being on tech, you know, Yahoo, Google. They had worked at Yahoo, Google, so they knew remote, and they were able to help us and bring that expertise. So the transition to remote was easy. And then we got all these students. And actually, that started a wave which has continued to this day of really people having an appetite for online learning and continuing to want to pivot careers into technology, both out of individuals' interests for technology but also because of the demand.

+ +

So the pandemic was terrible. Business-wise for sure, there have been challenges, but there have, I would say, been a lot more successes and opportunities as a result of the pandemic. And for me personally as an entrepreneur, the pandemic got us, you know, we were doing well and having a lot of success, so the pandemic also got us on the radar for BrainStation. We started that conversation, and that was really exciting. And, again, here we are as a global educator now.

+ +

CHAD: I've talked to a lot of people and seen it in our applications as well, like, it was really two things: people losing their jobs because of the pandemic and then getting that opportunity to take a look around and say, you know what? I'm not going back to that industry, and I want to learn to code.

+ +

And then a lot of other people saying, you know, sort of the great resignation kind of stuff saying like, I want to change and actively switching as well. And you can see it in our applications the number of switchers, the number of people who have taken the last year, year and a half to do a remote bootcamp and make a career transition. It was always high. It's even higher now.

+ +

JOHANNA: Yeah, totally agree, like, very respective of what we see as well. And we've had a great relationship with CareerSource South Florida as well. And they fund workforce transformation. And so initially in the pandemic...we're not seeing those layoffs now, but initially, a lot of those people who were getting laid off many of them were able to qualify for CareerSource as well, which also really fueled people's ability to take part in this education.

+ +

And South Florida is interesting. I think 65% of the workforce before the pandemic...a lot has changed. Tech has moved in, a lot of big names have moved in. But before the pandemic, 65% of people professionally here were working in hospitality or real estate so it was definitely a big pivot for some people to go into the direction of technology.

+ +

CHAD: That's great to hear that they were able to be helped by that because that can be a big impediment to this. I believe that the cost of an average bootcamp for what you actually get and for the impact it can have on your salary or your compensation is worth it. But if you can't afford the tuition, then it's a non-starter.

+ +

JOHANNA: Yeah, yeah, exactly. And then it goes without saying, but there are some people...there are a lot of opportunities. There are a lot of jobs. There are a lot of ways to get in, but it doesn't mean that it's for everyone. And I think for us, some of the work that's required to get into the program in our admissions process and our advisors who spend a lot of time with people considering this are also helping people guide this thought process of what they go into and what they're going to do to decide if it's the right direction for them.

+ +

And I think ultimately, the large majority who come in have done good research and good work and have really thought it through, and it's a good fit. But again, it's not for everyone. So it goes without saying it's good to go online, do some coding. Download Figma if you're going to go into UX. Tinker around with some stuff. Ask some people, go to some meetups, and then start looking into the education piece.

+ +

CHAD: Yeah. Are there ways in which you're exploring how either through partnerships or that kind of thing like it sounds like you've done to make it more accessible to people?

+ +

JOHANNA: Yeah, so we put, again, Wyncode and BrainStation now puts a lot of importance on building a diverse, inclusive environment. And the most important thing is just collaborating also with organizations in our various regions that serve communities that are underrepresented in tech so that we can provide certain pathways to this. And one of the key things that we're doing with our Impact Scholarships, I think we've committed over $1.2 million just as BrainStation to giving those pathways.

+ +

The other thing that we're piloting right now is what we're calling Tuition Free. So we piloted in London. Miami is the only other city we're testing it with in-person learning, not online, but it being completely tuition-free for the individual coming into the program, which we're calling a trainee. And then working with some amazing partners here in South Florida, in London who essentially, if they opt to hire someone for the program, are going to be paying a percentage training fee for hiring that individual.

+ +

So we're really excited to be piloting what's called a reverse model. But more so, training people in a very specific skill set that companies need, eliminating financial barriers as much as possible, and then also providing a very robust, rapid pathway for this incredible talent to then join companies. And maybe we'll do a synopsis in about a year, and I'll let you know how it all went.

+ +

CHAD: [laughs] That'd be great. That'd be great. So a common thread throughout this conversation has been Miami, and it's come on my radar recently in terms of the ecosystem there and how it's expanded and grown significantly over the last several years. You mentioned you picked up and moved there because you identified it as a great market. What has it been like for you?

+ +

JOHANNA: It's been a whirlwind. I mean, #Miamitechisonfire, literally.

+ +

CHAD: [laughs]

+ +

JOHANNA: It's a pretty exciting time to be here. I got to say, when we moved in 2014, our campus was and still is based in Wynwood, which is a wonderful creative space but also mixed in with tech companies.

+ +

CHAD: Is that why it's called what it's called, Wyncode?

+ +

JOHANNA: Yeah, that's right. [laughs] Wyncode and Wynwood, yep. So the landlords knew they really had all the leverage, right? But we have had, and I've always had, an amazing space here. And when we first opened, the biggest complaint we got from people who took the program was there were not enough places to eat. And for anyone who's listening who's from Miami and spent time in Wynwood, that sounds crazy because now all the hottest restaurants are here in Wynwood. And that's happened in the span of, you know, I know we've been here for eight years, but that's happened like in the last five years.

+ +

So a lot has changed. Wynwood is kind of an analogy to what's happened in the rest of Miami. It was kind of like a little bit quiet and slow, known for hospitality, awesome partying, real estate, not really known for all of this other stuff. The pandemic, again, was horrible from a business standpoint, terrible for some people, amazing for others. It was amazing for Miami. The state of Florida remained relatively open throughout the pandemic. So that attracted people here. The tax situation, no income tax, has also been very appealing, particularly for anyone who's made a lot of money in tech and crypto, in particular from Miami.

+ +

And then we have this incredible Mayor, Mayor Francis Suarez, who, long before what's happening now, has been an advocate and supporter of the tech ecosystem and startup founders here, which I've personally had experience with. He's been amazing. You know, in Silicon Valley, there was some social media going on for anyone who saw it on Twitter, and he tweeted back, and he said, "Hey, Miami would love to have you, guys. How can we help?"

+ +

And so there's this tagline in Miami which is how can we help? Trying to be an ecosystem that's here to help that's open to all. And that's been going on now for almost two years. And as a result, there's been a huge number of people in technology in particular who have moved here, both big names like Jon Oringer, Founder of Shutterstock, Keith Rabois, Founders Fund. There are so many people to name down to founders who are like; I'm starting a new startup. I don't want to do it in New York or Silicon Valley. I want to do it in Miami. So that's really exciting.

+ +

I can tell you; there's more going on here than I could...before I could keep an Easy Calendar, I knew everyone. I knew what events were going on when and now it's just...there are multiple events, meetups, multiple companies to meet. So it's really, really an exciting time. I think Mayor Francis Suarez has said this, too but definitely making a play to be the capital of crypto. So there's a lot going on in the crypto space here, a lot going on in Web3. Like Web3 being at the beginning, this is still at the beginning. This is a moment that we're hoping to turn into a movement, and I think it's really, really exciting.

+ +

I don't think everyone is going to stay here. I don't think Miami is going to be the next Silicon Valley or New York. It has its own character. It has its own vibe. It has its own way of functioning, and that's what it is. Its original kind of environment is also what's attracting people. So it's an evolution right now. It's going to change.

+ +

The people who have come here and who have been here are all in the process of evolving to what the next chapter of Miami tech is. But it's definitely an exciting time. It was a place for me where I came to professionally reinvent myself as well and really be a part of building an ecosystem. And that's very much true today for anybody who is coming here. And I think that type of opportunity is really, really exciting. There's definitely an energy, yeah.

+ +

CHAD: The state of Florida has passed laws like the Woke Act recently, which can present a challenge to employers strictly speaking. You're not allowed to ask certain questions around diversity or inclusion in interviews now. And that can be uncomfortable or difficult to do business in or to say, "Hey, we're the most welcoming company. Come here. Come to Miami." Is that something that's, you know, I'm not there. So is it a challenge on the ground, or does it not really affect people day-to-day?

+ +

JOHANNA: I mean, that's a really good question. I would say I haven't encountered it personally or even on the professional side with how we've been hiring. So it's hard to say from my perspective. I think certainly there are some things going on in Florida that Florida and California are very different. I myself I'm not an American. I'm not as involved in the politics. But it'll be interesting to see what happens in the future and how these things shape.

+ +

I will say that employers have a lot of power because they're the ones who are bringing in a lot of money into a state. They're hiring people. And so some of the responsibility is also on the companies and employers who are in their respective areas to advocate for the things that they want to see. And one of those things is diversity, inclusion, which not everybody has made that a number one priority.

+ +

And the one thing that I've said in the past is creating an inclusive and diverse ecosystem is the opportunity I think that Miami has because it is a less established tech ecosystem. The canvas isn't fully painted over, so we have an opportunity to be unique and be different and to try to avoid maybe some of the biases that have existed in other tech ecosystems.

+ +

But at this point, while there has been progress made and there are some amazing individuals doing amazing things like Leigh-Ann Buchanan leading Tech Equity Miami and JPMorgan Chase coming in to support that in a really big way and Knight Foundation, we're still at a state where the minorities are advocating for the minorities. And that's something I hope to one, personally contribute to changing but as an ecosystem as a whole hope to see that happen. Because, like I said, Miami is attracting people for a certain reason, and that's great. And I think if we could build a diverse ecosystem, that would also attract certain people and retain certain people.

+ +

And I am a firm believer, and, I mean, there are also stats to back it up, but the best products are built by the most diverse teams. So it goes without saying that the most diverse ecosystem is going to result in the best companies, best environment, et cetera. And I think that's the big opportunity for Miami, but we still have a lot of work to do to get there.

+ +

CHAD: Yeah. Well, if folks want to follow along with you or get in touch with you or learn more about BrainStation, where are all the places that they can do that?

+ +

JOHANNA: Yeah. I would love to connect with everyone. On LinkedIn, we have all of our respective social handles just at BrainStation. Even our Wyncode handles are still alive, so that's great. My parting words would be if you know someone amazing, a professional who wants to pivot careers and learn in person, now is an amazing opportunity to apply to BrainStation for incredible education and network. And I'm really looking forward to seeing amazing professionals come through the program.

+ +

CHAD: And I assume if you're in a position where you're hiring talent that you should also check out BrainStation.

+ +

JOHANNA: Yes, thank you, Chad. We 100% the thing we take the most pride in is connecting this amazing talent with awesome companies. I always like to tell everyone to keep a very wide lens on the type of talent you're hiring for your technology teams because some of the best individuals have very non-traditional tech backgrounds but bring so, so much to the table.

+ +

Our team does a lot of work in terms of once we get to know a partner, which I would love for you all to reach out and join; we do a lot of work to make sure that we are connecting curated talent to companies. And if you go to brainstation.io/hiring-partners, you'll be able to sign up there.

+ +

CHAD: Wonderful. Jo, thank you so much for joining me. I really appreciate it.

+ +

JOHANNA: Great. Thank you so much. Great to be on.

+ +

CHAD: You can subscribe to the show and find notes and a transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Johanna Mikkola.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Johanna Mikkola is the Co-Founder and CEO of Wyncode Academy, recently acquired by BrainStation, whose project-based programs have helped over 100,000 professionals launch new careers in the tech industry.

+ +

Chad talks with Johanna about creating a digital skills training bootcamp, the hiring and training market and challenges, and prioritizing inclusion and diversity in the student population.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. And with me today is Jo Mikkola, the Co-Founder, and CEO of Wyncode Academy, recently acquired by BrainStation, whose project-based programs have helped over 100,000 professionals launch new careers in the tech industry. Jo, thank you for joining me.

+ +

JOHANNA: So excited to be here. Thank you.

+ +

CHAD: I actually think that the weather we're calling from today might not be so different. It's very warm and sunny, and everything in Boston. So I'm pretty happy today. How are things where you are?

+ +

JOHANNA: That's great. We're coming to you live from the 305 in Miami, and it's turning into summertime here, which means it's pretty hot and sticky. But I'm originally from Finland, so I can't complain.

+ +

CHAD: [laughs]

+ +

JOHANNA: The novelty after eight years of living here has not worn off on me. I do enjoy the sunshine and the palm trees.

+ +

CHAD: That's great. So we'll definitely circle back and talk about Miami and the tech industry there and everything. But before we do that, I'm curious; you have recently been acquired by BrainStation. Let's rewind a little bit to getting started with Wyncode and what brought you to creating a digital skills training bootcamp.

+ +

JOHANNA: It's been quite the journey. It all started back in 2013, and at the time living in Toronto. I, at that point, had been working at the National Hockey League in Toronto for eight years and had just joined the management there on the hockey operations officiating team, which was an amazing chapter of my professional journey, and I love all the individuals that I worked with there. But I got to a point in that career where I didn't quite know what the next step would be professionally, and I was looking at getting an MBA.

+ +

But at the same time, while I was working at the NHL, I was helping lead an internal software build project. And it kept coming to the forefront for me that wow, hockey is being disrupted by technology or technology is being very integrated into something I thought, you know, I didn't think I would see that happen. And at the same time, my co-founder, who's also my husband, we're both from Finland. His name is Juha. He was an entrepreneur in the e-commerce sporting goods space, and he actually had joined a coding bootcamp in Toronto, an early one.

+ +

And as he was going through the process, we were both kind of at this inflection point professionally about what we were going to do. And so everything he was learning, the transformation of individuals he was witnessing first-hand, him experiencing that himself, and me being a non-technical business person leading a technical project at the NHL, we were like, wow, we're on the cusp of some serious change in the world, and we want to be part of that wave. So we were like, where can we go and be first to market to provide this life-changing, career-changing education and, in turn, really dive into not only education but also the technology space?

+ +

And ultimately, we landed on Miami. We had actually looked at Austin, Texas, and Los Angeles as options as well. But we arrived here in Miami, and it was very like a Hollywood thing. We were sitting at the coolest cafe in Miami at the time. We were here on Christmas holiday. And we, on a napkin, started writing ideas and brainstorming. You know, founders get very excited about logos and brainstorming names, or at least I do.

+ +

CHAD: [laughs]

+ +

JOHANNA: And it all came together really quickly. That was December 2013. We attended a startup meet-up here. We met four key players in this ecosystem, some of which are major drivers today, like the Knight Foundation and Endeavor. We heard their vision, and what they were doing, and how much funding was being put at the time into building a tech ecosystem in Miami. And we were like, wow, we want in. So we went from concept to launch in three months’ time.

+ +

And it was a pretty exciting ride. I mean, so much happened in that time [laughs], and obviously, the acquisition came early last year. And so we've kind of seen it go full circle. And for me professionally, I went from being a startup founder working very regionally, being somewhat nationally known but being a strong regional player, to being a global player overnight with BrainStation. So that also has been really exciting.

+ +

CHAD: At thoughtbot, we helped create a web development bootcamp around the same time actually.

+ +

JOHANNA: Love that.

+ +

CHAD: And that was for Kaplan, and they ended up purchasing Dev Bootcamp and then shutting it down. So I have some experience, and not only that, but thoughtbot has hired a lot of people from bootcamps into our apprentice program.

+ +

JOHANNA: Love that.

+ +

CHAD: So, from a hiring and training perspective, I think it's great. From a business perspective, it seems to have been a very challenging market. How did you weather that?

+ +

JOHANNA: Oh yeah. I mean persistence, unwavering commitment to the people we worked with, and the people we were helping gain these skills to change their careers. And like with any startup, there are moments where it's like, wow, you know, this is a big challenge. How are we going to overcome this? But we've always had the mentality of if there is a will, there is a way. And don't get me wrong, it doesn't always work out. But fortunately, now that I have hindsight, I can say that that mentality resulted in where we are today, and it was very positive.

+ +

And I have the really fortunate position of looking back on those stressful moments and seeing the lessons now, which is such a gift and maybe also alludes to me being old, I don't know. [laughter] But it really was a great journey. And I mean, the challenges started in the beginning for us, which is turns out it was a federal offense to operate without a license in the state of Florida, you know, lots of details to talk about there. But come full circle, we ended up being the first coding bootcamp to be licensed by a State Department of Education in the entire country.

+ +

So even though other people were operating in their states, it was different statutes, different legal requirements. And so, we were the first to be licensed. And as a result, we actually helped advise some of those other big names that we all see in the coding landscape to explain how it worked for us. And shout out to the Florida Department of Education and Commission for Independent Education for working with us to make it all come together. But it started off with a very exciting beginning getting that letter, which was essentially telling us to shut down before we had even begun. [laughter] And it all worked out. And we have a great relationship with them. And we learned a lot there.

+ +

And I will say just in the coding landscape, what ended up happening and what's happened with a lot of for-profit education is there was a huge opportunity, and there still is. People really genuinely need these skills. They really need this vocational training, and the companies hiring really need this talent, as you know firsthand. And so a lot of people jumped in and saw that there was money to be made because professionals and maybe also people who can afford it...there are a lot of financing companies that came in.

+ +

And so the thing that started wavering is the quality in terms of the training. And that's one of the things that you just, you know, one of the things we were unwilling to compromise at Wyncode and also why BrainStation, I like to say, is our soulmate because they feel the same way. To go from zero to software engineer or zero to UX designer (We also teach data science and digital marketing.), it really takes high-quality education, high-quality educators, and a high-quality network to do that at the level that we want to do that.

+ +

And then the other thing that a lot of people fell into is this desire to scale really quickly, so take in too many students which quality goes down, open too many locations, quality goes down. And to be the best, you got to learn from the best, and that means learning from software engineers, product designers, individuals who are really highly sought after right now. So, in the same way that software companies are facing talent issues, for us, that was also a key piece for us to solve and work out.

+ +

We're really fortunate that in the space of education, this is such rewarding work. We build such amazing relationships with the people coming through the programs and, in turn, are contributing so much to our local ecosystems that it hasn't been that hard to attract amazing talent to be our educators because it is so rewarding. They're getting an opportunity to apply their craft to something they love and really shape the minds of future technologists. And it's just a wonderful thing to watch and be part of, so really fortunate to be in that space.

+ +

CHAD: Correct me if I'm wrong, but I think that's one of the things that has made the space challenging is you come into it with the desire to have that really high quality, but there's a cost to that. And if you don't scale the number of students, you might have trouble covering that cost. How did you balance that?

+ +

JOHANNA: In the early days of Wyncode, it was easy because we were self-funded, and we were growing organically. So we were quite conservative about how we scaled and how many people we took on, and we stayed very true to that. And honestly, we stayed very focused on the state of Florida. So at one point, we actually had three locations; we had Miami Beach, Fort Lauderdale, and Miami, and we scaled them down to have a large HQ in Miami. Because we saw that when the team was together, and the community was together, the overall experience from network to learning was better because we were self-funded.

+ +

And then, later, when we had partners who were committed to quality, we were able to make decisions for the sake of quality instead of profitability. And then now with BrainStation, I mean, BrainStation is an incredible company. It's been around for ten years. It has been very successful. And right now, what we've been able to do is invest. BrainStation is in a position where we're investing in different pilots to see what things will make learning even better than it already is, although I will say it's at a really high quality right now.

+ +

And so we're in a fortunate position where, of course, it still needs to make sense. The unit economics needs to make sense. But we're also doing everything we can to continually iterate and make it a great environment for people to learn in. And I think that has come with taking the approach that we're in a long-term marathon. We're not in a sprint with what we're building right now. And I think a lot of the companies in this space that ran into issues were really sprinting to a certain scale, which is a way of operating that we haven't operated.

+ +

CHAD: Well, so based on what you've said so far, I can make certain assumptions about how you answer this next question.

+ +

JOHANNA: [laughs]

+ +

CHAD: But I think it's an important topic, and so I want to make sure even if it's obvious that we talk about it and that's how to bring in students, how to scale the business while still prioritizing inclusion and diversity in the student population, in your organization. What sort of attention did you put on that?

+ +

JOHANNA: Yeah, so this is a really key one. I mean, in the early days of Wyncode, we were able to do things in a different way than we are now with BrainStation. But I would say Miami is naturally a very diverse and international ecosystem. And so, from the beginning, we really wanted to see that reflected in the people who were in our programs because I knew that would, in the long term, provide so much value to building a great ecosystem.

+ +

And so, in the beginning, we partnered...we worked very hard to partner with The Knight Foundation to launch what was called The Future Leaders of Tech Fellowship. This is an example of something we did with different groups throughout all the years and continue to do today, but I'll use Knight as the example, which essentially was a full-ride scholarship for underrepresented individuals in technology. So the first iteration we ran of that was a full-ride scholarship because we thought that was the main barrier.

+ +

Then we realized that a lot of these individuals who hadn't had the means before and didn't necessarily have the educational training needed a little extra training, and they needed to start working right away. So what we created was a pre-program for them. It was a full-ride scholarship, and then it was a guaranteed three-month paid internship at a tech company. And of all the people who went through that program, the majority transitioned, with the exception of two, transitioned into full-time salaried roles. And those are incredible stories that are truly life-changing.

+ +

But I think the important thing there and what we learned over time is people need support, financial and educational, and they need time. So obviously, in an accelerated learning program, you want things to go as quickly as possible but through the help of partners and making it work for certain communities, we were able to do that. We also partnered with the YMW...it's the Women's...YMCA for women. I cannot remember the acronym right now.

+ +

CHAD: WYMCA.

+ +

JOHANNA: Thank you. Thank you. We provided a program in-house for them specifically.

+ +

CHAD: No, it would be the YWCA.

+ +

[laughter]

+ +

JOHANNA: Yeah.

+ +

CHAD: Sorry to interrupt you.

+ +

JOHANNA: I'm sorry. I'm not doing you all a good service here. But it's an amazing organization here in Miami. And that was geared specifically towards women from disadvantaged backgrounds, giving them the education they needed. And with that group, we had actually a 70% success rate, which was wonderful. Those are individuals who had no options for any type of white-collar position, many of whom we still keep in touch with today.

+ +

So, in the beginning, with diversity and inclusion, we were doing things at a smaller scale, very specialized, and very catered to make sure that they were successful in the hope of eventually building more momentum to do this. And the work very much continues. So BrainStation, larger company, we have a lot more firepower in terms of what we're able to do.

+ +

So we've partnered with companies like Ernst & Young, Shutterstock, Microsoft with our Impact Scholarship, which is also full-ride scholarships for the underrepresented communities in technology, and that's been really successful as well. And, again, education is really rewarding, but it's also really rewarding to see, in particular, those success stories.

+ +

CHAD: Yeah, one of the things when I speak at bootcamps or when I talk to apprentices who are joining us, I often reinforce or remind them that they bring something to the table, which is really special. I started programming when I was in middle school. I went to school for computer science. Aside from a brief stint as a dishwasher and a checkout person at a grocery store, this is all I've ever done. And I recognize that that has pros and cons.

+ +

Like, I just don't have the same perspective and diversity of experience, let alone actual demographic diversity that many of our team members bring to the table. And there's something special in that, whether it be from your experience working in another industry like hospitality or something like that. You bring a perspective. There are so many hospitality startups, for example, that would love to bring a new developer onto their team who actually has industry experience. It makes it very powerful for people.

+ +

JOHANNA: Yeah, absolutely. And I think oftentimes, people in anything when you're transitioning a career, there's maybe a little bit of imposter syndrome or a lack of confidence. And I see oftentimes not only minority groups but everyone shying away from their previous professional backgrounds. But technology is built for us, for humans who are very diverse in background experience and the products and services that we need. And so we really try to emphasize at Wyncode and at BrainStation to lean into your past profession. Because if you can bring that through and really focus on the things you learn there, you can provide so much firepower to what you're building with technology, and it’s super important.

+ +

And I will say healthtech is big in South Florida. And so we have had various people with some type of health background, whether they were an assistant or worked in a medical office, or we've had a few doctors go through the program. They were, as you can imagine, really sought after for the healthtech companies because not only do they bring technology skills, but they have this understanding that no one else does. So it's really unique.

+ +

CHAD: You're part of the tech industry now. [laughter] How has that diversity of background...you mentioned at the beginning, at the top of the episode that you were originally at the NHL, to starting to lead software projects there. How have you leveraged that for yourself and for your business?

+ +

JOHANNA: Oh yeah, 100%. So we do an exercise at BrainStation where you have a chart, and you plot out your past professions, and you look at the things that you learned, and the mistakes you made, and the things you didn't like, to start to build a thread of what are things carrying over? And for me, the thing that has come to the forefront is technology or not...and I feel like anyone investing is also saying this all the time, and maybe founders say it too. But it always comes down to people and relationships and how you are listening and taking in the information to then digest it and deliver something.

+ +

And so, I think my ability to connect with people and mobilize people around common goals is something that has been a common thread throughout my career. It's interesting. I'll say some of the best things I learned as a founder came from engineers, the first being agile. Like, we weren't operating like an agile company in the beginning because we weren't a software company. And our very first hire was a guy named Ed Toro, an MIT graduate. Shout out to Ed. It's actually his birthday.

+ +

CHAD: [laughs]

+ +

JOHANNA: Incredible, incredible engineer originally from Boston. He was our lead educator for software for so long. And he just brought so much knowledge to us about how software is built and works. And we integrated that into how we operated as business people and organized the company. I mean, it's amazing. I actually don't remember what it's like to not be organized in that manner anymore. Although I can tell you going from the NHL to Wyncode was a huge jump because NHL, even though we were using and leveraging technology, was still organized very traditionally.

+ +

And so I'll give you a simple thing, some software teams...I know a lot of software engineers appreciate transparency. So, in addition to organizing in a very agile method in terms of how we operated the business, we also pivoted to be extremely transparent as a team as well in terms of how the company is doing, which is something that is not common in a multibillion-dollar industry like the NHL. Although you see that more and more with tech companies, which is interesting.

+ +

CHAD: How long ago did you join up with BrainStation?

+ +

JOHANNA: So we were introduced to the founders and owners of BrainStation really because they were potentially looking at coming to Florida. And a mutual friend, a mutual business person, had said, "Hey, you know, if you guys are looking at Florida, probably you guys should meet Jo and Juha. They built something called Wyncode. You're going to get to know them anyway." And so I would say a little bit over a year and a half ago, we started chatting. And we realized that we had a lot in common in terms of how we had built the businesses, where we wanted to see the business go. And the rest isn't history because we're a year and a half in.

+ +

CHAD: [laughs]

+ +

JOHANNA: So you know what happened. It all worked out. It's really great but also really excited for the future. Because now with the BrainStation acquisition comes a lot of firepower in terms of experience on the team, much larger team, capital, reach of team. We have students in over 100 countries. So I'm very excited for what we're going to do in the future as well because we can have so much more impact, and that is really exciting as well.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: You mentioned before you had a very Florida-specific focus previously. Is part of this next stage to be working across BrainStation and really working more globally?

+ +

JOHANNA: Yeah, so working regionally with a focus on South Florida but with the know-how and the resources of a global team for sure. And being on the senior leadership team here, I am still 100% focused on Florida, but I get to have perspective from all the other markets. We have five campuses in New York, Toronto, Vancouver, London, and now Miami. So that's very interesting. And I have to say, when we were running Wyncode, we were always like, man, I wonder, how it's going in New York?

+ +

CHAD: [laughs]

+ +

JOHANNA: Or I wonder how it's going in Vancouver. Well, now I know. So it is really interesting because it also gives you not only a perspective in terms of bootcamps and how that's going but also a perspective on those ecosystems and how the tech companies there are growing and hiring. Because we're at that really interesting spot where we always know everyone's closed a round of funding because they go on a hiring spree. And then we see the bigger companies who are continually hiring. So we always kind of have a little bit of a pulse on what's going on in all of the ecosystems.

+ +

And also really, before, we were primarily American students in the southeast, but now as BrainStation, I mean, it's global. So seeing how different everyone is but also still so similar in terms of their end goals and collaborative, it's really special. And yeah, it's been great.

+ +

CHAD: So you have the campuses, the geographic locations, and then you have the global students. Are they in different silos, or do the two groups of students interact with each other at all?

+ +

JOHANNA: Yeah, great question. So we do execute our..., and we call them diploma programs for the bootcamp programs, both online and in person. So as you can imagine, students in over 100 countries we're executing in all the time zones because of online delivery. But much of that, if they're outside of the geographic region of one of our campuses, they're likely an online student.

+ +

CHAD: Are they being taught by an instructor in one of the campuses, or is it a separate thing?

+ +

JOHANNA: Yeah, our educators are located in our campuses geographically.

+ +

CHAD: How did the pandemic change or not change the experience of students, and what you needed to offer?

+ +

JOHANNA: Wyncode, at the time, we were still Wyncode when the pandemic hit. I'll never forget having an all-hands meeting in our conference room and being like, hey...it was a Thursday. We're like, come Monday; we're going fully remote. We weren't a remote educator at that time. Everybody needs special permissions and licenses to also have remote teaching, which most governments made exceptions for because of the pandemic. So we were all good there.

+ +

But we were thinking at the time, oh, maybe it'll be a month. Well, two years later, we're just about to have our grand reopening of the space in Miami. Our other campuses have already opened. And it was pretty exciting. When the pandemic hit, there was definitely an oh no moment. Like, people paused their enrollments, understandably. That was March. But as we got into early summer, we actually saw enrollment skyrocket. So huge success was pivoting to go remote.

+ +

We were very fortunate that we had a pretty seasoned senior team on our software and UX side. And they had been through the world of remote learning and just being on tech, you know, Yahoo, Google. They had worked at Yahoo, Google, so they knew remote, and they were able to help us and bring that expertise. So the transition to remote was easy. And then we got all these students. And actually, that started a wave which has continued to this day of really people having an appetite for online learning and continuing to want to pivot careers into technology, both out of individuals' interests for technology but also because of the demand.

+ +

So the pandemic was terrible. Business-wise for sure, there have been challenges, but there have, I would say, been a lot more successes and opportunities as a result of the pandemic. And for me personally as an entrepreneur, the pandemic got us, you know, we were doing well and having a lot of success, so the pandemic also got us on the radar for BrainStation. We started that conversation, and that was really exciting. And, again, here we are as a global educator now.

+ +

CHAD: I've talked to a lot of people and seen it in our applications as well, like, it was really two things: people losing their jobs because of the pandemic and then getting that opportunity to take a look around and say, you know what? I'm not going back to that industry, and I want to learn to code.

+ +

And then a lot of other people saying, you know, sort of the great resignation kind of stuff saying like, I want to change and actively switching as well. And you can see it in our applications the number of switchers, the number of people who have taken the last year, year and a half to do a remote bootcamp and make a career transition. It was always high. It's even higher now.

+ +

JOHANNA: Yeah, totally agree, like, very respective of what we see as well. And we've had a great relationship with CareerSource South Florida as well. And they fund workforce transformation. And so initially in the pandemic...we're not seeing those layoffs now, but initially, a lot of those people who were getting laid off many of them were able to qualify for CareerSource as well, which also really fueled people's ability to take part in this education.

+ +

And South Florida is interesting. I think 65% of the workforce before the pandemic...a lot has changed. Tech has moved in, a lot of big names have moved in. But before the pandemic, 65% of people professionally here were working in hospitality or real estate so it was definitely a big pivot for some people to go into the direction of technology.

+ +

CHAD: That's great to hear that they were able to be helped by that because that can be a big impediment to this. I believe that the cost of an average bootcamp for what you actually get and for the impact it can have on your salary or your compensation is worth it. But if you can't afford the tuition, then it's a non-starter.

+ +

JOHANNA: Yeah, yeah, exactly. And then it goes without saying, but there are some people...there are a lot of opportunities. There are a lot of jobs. There are a lot of ways to get in, but it doesn't mean that it's for everyone. And I think for us, some of the work that's required to get into the program in our admissions process and our advisors who spend a lot of time with people considering this are also helping people guide this thought process of what they go into and what they're going to do to decide if it's the right direction for them.

+ +

And I think ultimately, the large majority who come in have done good research and good work and have really thought it through, and it's a good fit. But again, it's not for everyone. So it goes without saying it's good to go online, do some coding. Download Figma if you're going to go into UX. Tinker around with some stuff. Ask some people, go to some meetups, and then start looking into the education piece.

+ +

CHAD: Yeah. Are there ways in which you're exploring how either through partnerships or that kind of thing like it sounds like you've done to make it more accessible to people?

+ +

JOHANNA: Yeah, so we put, again, Wyncode and BrainStation now puts a lot of importance on building a diverse, inclusive environment. And the most important thing is just collaborating also with organizations in our various regions that serve communities that are underrepresented in tech so that we can provide certain pathways to this. And one of the key things that we're doing with our Impact Scholarships, I think we've committed over $1.2 million just as BrainStation to giving those pathways.

+ +

The other thing that we're piloting right now is what we're calling Tuition Free. So we piloted in London. Miami is the only other city we're testing it with in-person learning, not online, but it being completely tuition-free for the individual coming into the program, which we're calling a trainee. And then working with some amazing partners here in South Florida, in London who essentially, if they opt to hire someone for the program, are going to be paying a percentage training fee for hiring that individual.

+ +

So we're really excited to be piloting what's called a reverse model. But more so, training people in a very specific skill set that companies need, eliminating financial barriers as much as possible, and then also providing a very robust, rapid pathway for this incredible talent to then join companies. And maybe we'll do a synopsis in about a year, and I'll let you know how it all went.

+ +

CHAD: [laughs] That'd be great. That'd be great. So a common thread throughout this conversation has been Miami, and it's come on my radar recently in terms of the ecosystem there and how it's expanded and grown significantly over the last several years. You mentioned you picked up and moved there because you identified it as a great market. What has it been like for you?

+ +

JOHANNA: It's been a whirlwind. I mean, #Miamitechisonfire, literally.

+ +

CHAD: [laughs]

+ +

JOHANNA: It's a pretty exciting time to be here. I got to say, when we moved in 2014, our campus was and still is based in Wynwood, which is a wonderful creative space but also mixed in with tech companies.

+ +

CHAD: Is that why it's called what it's called, Wyncode?

+ +

JOHANNA: Yeah, that's right. [laughs] Wyncode and Wynwood, yep. So the landlords knew they really had all the leverage, right? But we have had, and I've always had, an amazing space here. And when we first opened, the biggest complaint we got from people who took the program was there were not enough places to eat. And for anyone who's listening who's from Miami and spent time in Wynwood, that sounds crazy because now all the hottest restaurants are here in Wynwood. And that's happened in the span of, you know, I know we've been here for eight years, but that's happened like in the last five years.

+ +

So a lot has changed. Wynwood is kind of an analogy to what's happened in the rest of Miami. It was kind of like a little bit quiet and slow, known for hospitality, awesome partying, real estate, not really known for all of this other stuff. The pandemic, again, was horrible from a business standpoint, terrible for some people, amazing for others. It was amazing for Miami. The state of Florida remained relatively open throughout the pandemic. So that attracted people here. The tax situation, no income tax, has also been very appealing, particularly for anyone who's made a lot of money in tech and crypto, in particular from Miami.

+ +

And then we have this incredible Mayor, Mayor Francis Suarez, who, long before what's happening now, has been an advocate and supporter of the tech ecosystem and startup founders here, which I've personally had experience with. He's been amazing. You know, in Silicon Valley, there was some social media going on for anyone who saw it on Twitter, and he tweeted back, and he said, "Hey, Miami would love to have you, guys. How can we help?"

+ +

And so there's this tagline in Miami which is how can we help? Trying to be an ecosystem that's here to help that's open to all. And that's been going on now for almost two years. And as a result, there's been a huge number of people in technology in particular who have moved here, both big names like Jon Oringer, Founder of Shutterstock, Keith Rabois, Founders Fund. There are so many people to name down to founders who are like; I'm starting a new startup. I don't want to do it in New York or Silicon Valley. I want to do it in Miami. So that's really exciting.

+ +

I can tell you; there's more going on here than I could...before I could keep an Easy Calendar, I knew everyone. I knew what events were going on when and now it's just...there are multiple events, meetups, multiple companies to meet. So it's really, really an exciting time. I think Mayor Francis Suarez has said this, too but definitely making a play to be the capital of crypto. So there's a lot going on in the crypto space here, a lot going on in Web3. Like Web3 being at the beginning, this is still at the beginning. This is a moment that we're hoping to turn into a movement, and I think it's really, really exciting.

+ +

I don't think everyone is going to stay here. I don't think Miami is going to be the next Silicon Valley or New York. It has its own character. It has its own vibe. It has its own way of functioning, and that's what it is. Its original kind of environment is also what's attracting people. So it's an evolution right now. It's going to change.

+ +

The people who have come here and who have been here are all in the process of evolving to what the next chapter of Miami tech is. But it's definitely an exciting time. It was a place for me where I came to professionally reinvent myself as well and really be a part of building an ecosystem. And that's very much true today for anybody who is coming here. And I think that type of opportunity is really, really exciting. There's definitely an energy, yeah.

+ +

CHAD: The state of Florida has passed laws like the Woke Act recently, which can present a challenge to employers strictly speaking. You're not allowed to ask certain questions around diversity or inclusion in interviews now. And that can be uncomfortable or difficult to do business in or to say, "Hey, we're the most welcoming company. Come here. Come to Miami." Is that something that's, you know, I'm not there. So is it a challenge on the ground, or does it not really affect people day-to-day?

+ +

JOHANNA: I mean, that's a really good question. I would say I haven't encountered it personally or even on the professional side with how we've been hiring. So it's hard to say from my perspective. I think certainly there are some things going on in Florida that Florida and California are very different. I myself I'm not an American. I'm not as involved in the politics. But it'll be interesting to see what happens in the future and how these things shape.

+ +

I will say that employers have a lot of power because they're the ones who are bringing in a lot of money into a state. They're hiring people. And so some of the responsibility is also on the companies and employers who are in their respective areas to advocate for the things that they want to see. And one of those things is diversity, inclusion, which not everybody has made that a number one priority.

+ +

And the one thing that I've said in the past is creating an inclusive and diverse ecosystem is the opportunity I think that Miami has because it is a less established tech ecosystem. The canvas isn't fully painted over, so we have an opportunity to be unique and be different and to try to avoid maybe some of the biases that have existed in other tech ecosystems.

+ +

But at this point, while there has been progress made and there are some amazing individuals doing amazing things like Leigh-Ann Buchanan leading Tech Equity Miami and JPMorgan Chase coming in to support that in a really big way and Knight Foundation, we're still at a state where the minorities are advocating for the minorities. And that's something I hope to one, personally contribute to changing but as an ecosystem as a whole hope to see that happen. Because, like I said, Miami is attracting people for a certain reason, and that's great. And I think if we could build a diverse ecosystem, that would also attract certain people and retain certain people.

+ +

And I am a firm believer, and, I mean, there are also stats to back it up, but the best products are built by the most diverse teams. So it goes without saying that the most diverse ecosystem is going to result in the best companies, best environment, et cetera. And I think that's the big opportunity for Miami, but we still have a lot of work to do to get there.

+ +

CHAD: Yeah. Well, if folks want to follow along with you or get in touch with you or learn more about BrainStation, where are all the places that they can do that?

+ +

JOHANNA: Yeah. I would love to connect with everyone. On LinkedIn, we have all of our respective social handles just at BrainStation. Even our Wyncode handles are still alive, so that's great. My parting words would be if you know someone amazing, a professional who wants to pivot careers and learn in person, now is an amazing opportunity to apply to BrainStation for incredible education and network. And I'm really looking forward to seeing amazing professionals come through the program.

+ +

CHAD: And I assume if you're in a position where you're hiring talent that you should also check out BrainStation.

+ +

JOHANNA: Yes, thank you, Chad. We 100% the thing we take the most pride in is connecting this amazing talent with awesome companies. I always like to tell everyone to keep a very wide lens on the type of talent you're hiring for your technology teams because some of the best individuals have very non-traditional tech backgrounds but bring so, so much to the table.

+ +

Our team does a lot of work in terms of once we get to know a partner, which I would love for you all to reach out and join; we do a lot of work to make sure that we are connecting curated talent to companies. And if you go to brainstation.io/hiring-partners, you'll be able to sign up there.

+ +

CHAD: Wonderful. Jo, thank you so much for joining me. I really appreciate it.

+ +

JOHANNA: Great. Thank you so much. Great to be on.

+ +

CHAD: You can subscribe to the show and find notes and a transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Johanna Mikkola.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+oZ0o6xBq + + ]]> + + Chad Pytel + Johanna Mikkola + + + 426: Marvelous with Jeni Barcelos + https://podcast.thoughtbot.com/426 + 1ae41abf-4cff-442e-82bb-dd4a9207cf2a + Thu, 09 Jun 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Jeni Barcelos is the Co-Founder and CEO of Marvelous, the world's most beautiful all-in-one teaching platform. + +Chad talks with Jeni about what makes Marvelous different from other teaching platforms out there, the importance of elevating women to leadership positions, and why applying for and getting accepted into an accelerator program was the right path for the company. + 40:53 + no + + + Jeni Barcelos is the Co-Founder and CEO of Marvelous, the world's most beautiful all-in-one teaching platform. +Chad talks with Jeni about what makes Marvelous different from other teaching platforms out there, the importance of elevating women to leadership positions, and why applying for and getting accepted into an accelerator program was the right path for the company. +Marvelous (https://www.heymarvelous.com/) +Follow Marvelous on YouTube (https://www.youtube.com/channel/UCJZ_kWoBcXJuSKP1iofXsAw), Instagram (https://www.instagram.com/heymarvelous/), or LinkedIn (https://www.linkedin.com/company/marvelous-software/). +Follow Jeni on LinkedIn (https://www.linkedin.com/in/jenibarcelos/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jeni Barcelos, the Co-Founder, and CEO of Marvelous, the world's most beautiful all-in-one teaching platform. Jeni, thank you so much for joining me. +JENI: Thank you for having me, Chad. I'm excited to be here and excited for our conversation. +CHAD: So I'm really excited to dig into more about Marvelous as well. So why don't we start there? What makes Marvelous different than other teaching platforms that are out there? +JENI: Marvelous is different in that we prioritize design, I would say more than any other competitive platform. And we also prioritize live events in a way that I think is pretty unique. So we started in the wellness space. We primarily are serving wellness creators, although all kinds of other creators use our tool as well. +So we specifically built Marvelous with the goal of serving their unique needs, which involves a lot of teaching live classes and having a really great community space where students and clients can build relationships with each other. And then, because our audience has a particular design aesthetic and is non-technical, we've created the tool in a way that makes it really easy to make something look beautiful very quickly and simply. +CHAD: So what caused you to differentiate yourself based on design? +JENI: I think just personal preference and aesthetic, to be honest. As we were building the platform, I realized very quickly that people were choosing us...one of the big reasons people were choosing us was because of the simple nature of the user interface and because of the design that it produced. And so we decided really early to prioritize that. And I would say it's also just I care deeply about design, and I don't like the idea of using tools that make that an afterthought. +And so I thought if I'm going to use it, and I do, I mean, we definitely dogfood our own platform and teach our own courses, we run our own communities there, I want it to look beautiful. [laughs] I want it to be a place that people enjoy spending time. We all spend more time, I think, than we want looking at screens. And so when you are going to engage in that practice and engage with other people on the internet, I think it's really nice to do it in a space that feels welcoming, and gentle, and beautiful. +CHAD: So you have a co-founder, Sandy. Are either of you designers or have a background in design? +JENI: Nope, not at all. Although I was one course away from minoring in art history in school. [laughter] No, I'm a lawyer. So I'm the opposite of a designer, although I think there's a part of me that thinks of myself as an artist. I wish that were my identity. +CHAD: So, given the importance of design that you discovered, how did you go about executing on that? +JENI: Hiring really great people, I would say, and having a really critical eye. And so, there's a tremendous amount of feedback that goes into our process. And now we have a head of brand in our company, and she can hold space for that design across both marketing and within product. So that hire, I think, has been critical for us to be able to maintain that as a priority. +CHAD: Where were you in the product life-cycle and business stage where you were able to hire really great people? +JENI: I would say within the last two years. So we are one of these startups that was in the right place at the right time when COVID hit. So luckily and unluckily, maybe we grew really fast in the wake of the pandemic, the beginning of the pandemic. And so that positioned us to hire pretty rapidly over the last two years. And that's when we really had the resources and the capacity to bring in that level of talent. +I'll say our creative director was working with us for many years before that but just in a part-time capacity so, you know, running her own agency. And we were hiring her out as we could because we were bootstrapped. And so it wasn't until we reached a certain level of growth where we could bring her on as a permanent fixture in the company. +CHAD: Yeah, that's often a way that I hear from founders to help get things off the grounds, particularly if you know of someone and would love to work with them and you know what they can produce, but you just can't afford to bring them on full-time as a member of the team at that point. Contracting with them, working with them part-time can be a great way to get that started. So let's rewind even further and tell me about the fateful day where you and Sandy first met each other. +JENI: Yeah, so we first met in Colorado Springs at an entrepreneurship event. And it was for an online program we had both been in that was teaching us how to start a SaaS company. And we are two of the only people that had actually done it and gotten to paying customers within six months, which was a pretty audacious goal, I would say to go from being non-technical and having no experience in the startup world to having a product or at least an MVP with paying customers within six months and no funding. +So we were 2 of maybe 5 or 6 people out of 550 in the program who did that. So we automatically kind of gravitated towards each other. And we were two of the only women also in the program. So we met at that event and got to know each other over the course of a number of days and retreated together. And then we just started really being accountability partners to one another as we were each building our own companies independently. And then that went on for another year, year and a half before Sandy joined my company. +CHAD: Okay, so you were already working on Marvelous? +JENI: Yeah. It had a different name at the time, but yes, I was six months into it when I met her. +CHAD: How did you convince her to do that? +JENI: We were actually growing...for a solo founder, we were growing to the point that I couldn't manage the company really on my own anymore. And so I applied to an accelerator just because I felt like I had other kinds of career experience but had, again, zero background in tech startups. And so, I came from teaching at a law school and building and scaling a nonprofit. And my background was in politics prior to that. So I had no idea what I was doing. Like, I didn't know what I didn't know, and so that thought scared me. And I just wanted to go immerse myself in an environment where I could ask a lot of questions and have access to resources and mentorships. +So anyway, I applied to an accelerator and got accepted contingent on having a team and having co-founders. And I was like, [laughs] well, that's why I need to come here because I don't know how to do that. Like, I don't know how I would do that. And so I reached out to Sandy because I mean, she had been more closely involved in the company than anyone else because we were constantly working together online and going on Zoom and helping each other build our companies. +She knew more than anyone else really what was involved. And she was always commenting how she wished she had started [chuckles] a company like this because it's just in the sector. Her background is in clinical wellness, and Marvelous really was serving yoga and wellness teachers. And so I said, "Well, why don't you come on board? I need to have at least one co-founder." Well, I was told I needed to have two, but I convinced them actually to accept me into the program with just one. So Sandy and I went into the accelerator together. +CHAD: I feel like that's a great sign that you were able to convince them to bend the rule. [laughs] +JENI: Yeah, I mean, I think that's actually my MO in life. So I also applied and got into graduate school at Yale without taking the GRE. So I have a history of these kinds of convincing arguments, I guess. +CHAD: [laughs] +JENI: And I'm a lawyer, right? So I was made for this. [chuckles] +CHAD: Yes. You sound like a very enjoyable person, though. So I find it hard to believe that you're... [laughs] No, I'm kidding. +JENI: I'm a human rights lawyer. So the only person I've ever represented in court was a pod of killer whales. So I'm a human rights and environmental attorney. So I'm not a corporate attorney by any means. +CHAD: So some people might describe going after things, bending the rules as ambition. And I was reading some of the things that you've written, so I'm not pulling this out of thin air. But I know that you talked before about how sometimes ambition, particularly from female-identifying people, can be seen as a problem. Why is that? +JENI: I mean, the short answer to that is the patriarchy of which we're all a part. Both men and women and non-binary people are all impacted greatly by the patriarchy. I mean, I think it's how girls are socialized. So that's a whole, I think, a whole other podcast conversation to have. But I mean, just even recently, I have a young daughter, and she was told not to raise her hand as much in school because she was so eager and raises her hand for every question that's asked. And that's unacceptable to me. But I was also told those things. +And I think just men and women are judged very differently in our culture, and that's just a fact of life. I mean, just look at, I mean, this is maybe opening up a can of worms. But if you just look at the way the Elizabeth Holmes trial played out versus so many other startup stories, and yes, there are differences, but it's really common in our culture to villainize female ambition and to look at it as problematic. +CHAD: Yeah, you're absolutely right that this is a whole podcast topic in and of itself, but I think it's an important one. But I'm curious; it can feel angering and powerless when something like that happens at school or in a system where it's very hard to control it or change it. But when it comes to your own company, you are in charge. So what have you done to try to make this different at Marvelous? +JENI: Well, I would say elevating women to leadership positions to the extent that we've been able, I mean, we're definitely a female-run company. We make decisions. Also, just even the way we provide benefits and salaries, it's in my mind done from a more holistic standpoint than I would say a lot of other small startups are doing. We prioritize people and their families and try to treat people like human beings versus just kind of pawns in our scheme to build a company, I would say. It's not perfect. +But I really think that so much of what goes on around kind of the women in tech stories so much of that and the women in fundraising stories has to do with women or non-binary people really having to prove themselves to a degree that is unrealistic in order to have the same treatment or the same opportunities as white men. So we are obviously very acutely aware of that. And so, in our own company, we're still very small but always trying to elevate the opportunities that women and people of color have in our company. +CHAD: And as you said, this permeates. It's systemic. And so, what might you do when you have a male manager with the best of intentions in a female-led company? I'm of the opinion that it's not enough to just assume that, oh, well, in that environment, this stuff won't happen because it is so ingrained. So are there other things that we can do as founders, as people, and leaders, as a company to create an environment where it's better for everybody? +JENI: I definitely don't have all the answers for this. But I would say we've put a lot of attention into coming up with core values that we really strongly affirm and reaffirm in the company and make sure that everyone is aware of those. I also just I'm constantly watching what's going on and noticing subtle cues when people start to pull back from contributing or some voices are much louder than others; just trying to notice that and not wait for something to be brought to my attention. +I think so much of it is also the culture, and it's hard in a situation like ours where we're a fully remote team with people across the world with their own different, you know, they're bringing their own cultures and their own values to the company. I mean, it's definitely hard. It's harder than I ever would have expected to get people on the same page. +And, I don't know, I don't have really good advice other than to say the founders should really agree on the core values. And then, those core values should be shared constantly. And I think it starts with the founder or the co-founder and the leadership team holding everyone to those values and standards. +CHAD: So as someone who, like you said earlier, you're not a software developer, you're not a designer, yet you are working on this idea and bringing it out into the world. How did you manage to do that? What did the very early steps look like for you? +JENI: So I started a company when I was essentially on maternity leave. I naively thought that that would be like a fun, little hobby project for me to start a tech company. Partly because I was spinning off what had really been a research project that was funded and incubated at a major university. I was spinning that off into a nonprofit with another co-founder, another lawyer. And I spent a great deal of time and energy fundraising and was constantly going and having meetings or drinks or dinner with people or even flying out to different foundations and meeting with donors. +And I was like, this is for me who...I have a body of work and have developed expertise as a climate change expert. And that word is problematic but, you know, someone who knows quite a lot about climate change in the law, edited one of the major textbooks in the area, taught some of the first curriculum on energy and the environment. I was constantly having to just go out and raise money all the time and mostly from people who had cashed out of tech companies. +So I was in Seattle at the time, you know, Microsoft and Amazon. There are a lot of people with significant wealth, and those are the people that are donating to organizations. And so I just thought I'm as smart and capable as these people. Like, why don't I have a revenue source that helps to fund the work that I want to do in the world? Which was a lot of human rights law and environmental law that's really underfunded really at that intersection of climate change and human rights. +And so I thought, well, I'm on maternity leave. I'm really interested in the wellness industry. I see it really being broken. I had gone through yoga teacher training like right at the tail end of law school just for my own mental health and wellbeing. And I just saw all of these friends and colleagues of mine struggling, and I just thought something wasn't quite right. So the first thing I did was I decided I'm going to try to build something to help them. And I set out to interview 75 yoga studio owners or managers in North America and did some research on the biggest markets at the time. +CHAD: Why 75? +JENI: Because I just thought that was a good number. If I talked to 75 people, I'd be able to have some good information. And I will say I had just come off of a couple of major projects where I had put together a big international conference in my field in climate justice. And I had also put together sort of a retreat of leaders in the field of scenario planning around that. +So I had really learned a lot and elevated my real career at the time by reaching out to people who I thought were thought leaders and experts in the field across different disciplines and having really honest, frank conversations and interviews with them. And I had been able to essentially tease out an entire field of work for myself from doing that. +So I brought my research and academic skills to bear, which was like, if I talk to enough people, I'm going to start to find some patterns. And I was curious, like, I couldn't quite understand. This wellness industry had been growing for over a decade at that point. It was this massive industry, and yet no one I knew who worked in the industry made any money. And I thought that was really weird. And I'm like, why is all the money going to apparel companies or a couple of big brands? Something is really broken in this model. I don't think the technology...tech hadn't really arrived to wellness at that point. +I came up with the idea to start doing this at the end of 2013, and so it was a long time ago. So I was just like, I'm going to talk to as many people as I can who are running businesses in the major metropolitan areas that are big yoga centers and just see what I can figure out. And so that's what really started it. And then, the idea for what was then called Namastream and is now called Marvelous came from those conversations. And it wasn't long; it was maybe six weeks into the research that I really started to...like, there were three or four ideas that I thought, well, here are product ideas that could really make a difference. +And so what I did is I sent out about 200 cold emails, and I had 74 interviews from that. And then I agreed to create a report like a white paper because, again, this is what I knew how to do as an academic is like I'm going to do a bunch of interviews, and then I'm going to write a report about it. And I'm going to share it with people. So I agreed to share the research with everyone who agreed to an interview. And so I think that's part of why they agreed to talk to me. +So yeah, so that's where the idea came from. And then again, I had no background in tech. I watched some trainings on how to do UX design, I think, like YouTube videos and stuff, and then I just did it. And I made the first prototype like a clickable prototype in Keynote because I knew how to use Keynote. +CHAD: Yeah, that's so great. Talking to people, using whatever tool you're comfortable with, Keynote, PowerPoint, that kind of thing to do clickable prototypes that's the exact kind of thing I encourage, we encourage our thoughtbot early-stage founders to do. So you were spot on. I don't know if you realized it at the time. But that's really great. What problem did those 74 or some strong subset of them have that streaming helped them with? +JENI: It was really interesting because there were a couple of studios. There were two studios at the time in Southern California that were doing this, and the bigger studios in these other major cities knew that. And so because there were so few, they were very well known way back. I mean, most of those conversations were in 2014 that I was having. Some of the studios, I mean, one of them is still a major company now. +You know, most studios had like 2,000 members. Like, a studio that I would interview had 2,000 customers on their list, like, possible customers. Some of those were people who were drop-ins or punch cards or whatever. And then the studios that were streaming had like 30,000 customers. And so that was starting to be known. And people had no idea how to do any of that themselves. +And so the problem that we are solving was when I would interview studios in the Boston area because that was one of the metropolitan areas I targeted; there were certain days out of the year that for snow closures like the studio would just lose all their revenue that day. In the south, there were studios that were impacted by hurricanes that were trying to figure out...and I'm a climate change lawyer, so I see this trend. I was looking at it from a disaster response scenario planning lens which was this is only going to get worse. I had no idea about the pandemic. +CHAD: Little did you know. [laughs] +JENI: Right? [laughs] I just thought like, wow, okay, the hurricanes are increasing in severity and duration. That's not going to change. Sea level rise is happening. Storms are becoming more unpredictable. Like, places that are cold are getting colder and have more snow on average. So all these people were complaining about lost revenue for these cataclysmic weather events. I just thought that as being a huge opportunity for a solution. So that was one reason why this idea really stood out to me. +And then also just knowing that...this actually goes back again to my own story. I used to work for Al Gore. I was one of the people that led his environmental outreach on his presidential campaign when I was a teenager. And then I ended up being one of the first people trained to give the climate presentation that he made famous in An Inconvenient Truth. +And so, I had been developing presentation materials in my legal and academic career that I was sharing with that organization. And I had to figure out how to record myself and then try to get it on a thumb drive and then send it to Nashville so they could watch it and learn how to present the slides that I was making. +And so I actually had this very different use case where I was like, it was really hard. I was on the board of another nonprofit that was bringing together environmental leaders once a year to learn new training materials and then go back out across the world to disseminate them. Again, the same thing. I was like; there is going to be such a need for some kind of streaming tool that's accessible by whoever wants to use it to be able to share knowledge and information. So both as a business tool, but it also kind of scratched this other itch that I had seen in my previous career, like, the career I thought I was taking a short break from. +And so I just was like, this is the future. And I had moved during this time across the country for my husband's job and had a new baby. And I missed my own yoga teacher. And so I thought, like, wow, I'm in North Carolina in this small town, and I really miss the Seattle community. And I miss my teachers there. I wish I could take these classes. +So for all of those reasons, I saw this as being a trend that wasn't going away, and that was only going to be more in need. And it was really early adopters at that point, like definitely not 74 studios telling me they needed this. But it was a big enough chunk of early adopters that I thought this is when you get to make something new that changes the industry. +Mid-Roll Ad: +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So you have the clickable prototype, and you feel like this is something here. What was the next step for you? +JENI: So I went back to everyone that had validated that idea, and I tried to sell it to them. [laughs] I had people PayPal.Me money in order to build it. I said, "You can become a founding customer, and you'll get access for a year included and with a payment." I think I was charging people; I don't know, a couple of thousand dollars. I don't even remember. It was a long time ago. It was under $2,000. "So you can get in now. You'll have a 20% discount on anything we make forever. +If you want to participate, you can be in this founding member circle with me. And as it's getting developed, you can provide feedback and help to shape exactly what it becomes." So I had enough people throw some money into the pot PayPal.Me money. I also had no idea how to take money from anyone. It was sort of like pre-Stripe being a normal thing. So I just had random people PayPal.Me money. And I took the money, and I hired a developer to build a prototype. +CHAD: How did you find that developer? +JENI: That was hard. So through this entrepreneurship course that I ended up meeting Sandy in, there was somebody who was a classmate, sort of like a mentor-level classmate who had done the course before who was an engineer at Microsoft. So I asked him to help me. I reached out and asked him to. And if I hadn't reached out to him, I would have reached out to other developers that I knew, just people in my extended circle of friends and stuff. +CHAD: So how long did it take from that point to get a product that people could actually use for their classes? +JENI: Early use, I would say like four months. So it was very, very, very beta. It's humiliating what it was. +CHAD: It should be. It should be humiliating. +JENI: Yeah, it should be. So it was like kind of a WordPress plugin. It was basically a glorified WordPress plugin, and that took about four months. And so I onboarded our early adopters who had given me the money, the checks, the PayPal money. That was the beginning of the summer that year. And I said, "You're the only people that are going to have access to it for the first three months," and that was part of the deal. +So I really worked around the clock helping them, working with my developer to solve any problems that were coming up, making changes. And then, in September, about three months later, I just figured out how to run Facebook ads. [laughs] So I just made up Facebook ads that ran to a one-on-one demo and let people book one-on-one demos with me through Facebook ads. +CHAD: So in those early days, if you had to do it over again, is there a lesson you learned that you might do it differently? +JENI: I don't think so, honestly. I feel like that first year; I feel pretty good about everything that I did. I mean, obviously, it would have been great to have someone like Sandy come in early on. But, I mean, I needed to figure some stuff out that I didn't need another person around to figure out, I guess. And I guess now, in like 2022, we're having this conversation. I wish I had dumped money into Facebook ads to have more demos because they were so cheap. [laughter] +CHAD: Right. Right. +JENI: It was so cheap for me to run ads. It was the golden days of online advertising, I guess. So I was probably paying like 40 cents a lead or something. [laughs] So yeah, maybe that. Because I was very much not wanting to put my own money into it. Like, once I raised the money to fund the prototype, I think I maybe in that first year put in like seven grand or something, but by the end of the year, I paid myself back. +CHAD: That's great. +JENI: I could have maybe put in a little more money. But I didn't know if it was going to work. Like, I wasn't really willing for...again, I wanted something that was very validated. And I expected fully to be going back to my career as soon as I got this thing launched. I was like, oh, this is just like a side hustle. This is going to be passive income. I did not understand that building a software company was not at all passive. I think I really bought into this idea that, like, oh, it's the internet. It will be passive income. +CHAD: When did it become clear to you that it wasn't? +JENI: Oh, I mean, I would say, you know, so I had a moment to go back to work, not my exact same job but to do work in my field between one month and two months after I launched and started running ads. I turned down a really incredible job offer, and I think that's when I knew it. +I was like, if I take a job, if I go back to work full-time...and I have the kind of career that's all-encompassing, and I sort of, whatever, I'm going to give 150% to whatever I'm doing. And so I knew that this thing would kind of die, but it was taking off. And so, I think I knew at that point I had to make a choice. +CHAD: And is that when you decided to apply to the accelerator? +JENI: No, it was like another nine months of growing it on my own before I applied to the accelerator. And I just kept doing what I was doing, and it was working. But I was doing things that didn't scale, so that was the problem. And so I didn't know, I mean, there's only so many one-on-one demos that the founder can do before you start to realize [laughs] you need to make some changes because I was doing them around the clock. +And then, at some point, I switched to webinars. I taught myself how to do webinars. And so then I was trying to do demos to multiple people at a time, but also, I didn't understand email marketing. I didn't understand copywriting. I was figuring everything out myself as I went, and I was burning out. So that's when I decided, like, oh, not everyone does this. I can't grow Microsoft or Amazon by doing this. I can't become that company. So obviously, I need to figure out how to scale. So that was when I decided to apply to the accelerator. +CHAD: Why apply to an accelerator as opposed to start fundraising, for example? +JENI: Oh my God. Well, so the whole reason I did this was so that I didn't have to go out for drinks with people and ask them for money. [laughter] I mean, I was not interested in that at all. And then I soon realized that that's what happens when you join an accelerator [laughs] is you basically just start learning to fundraise. But I didn't know that. I knew nothing. And so, I knew nothing about startups. I knew nothing about anything like this. I literally had no idea. +So the idea of going and sending emails to wealthy people to go have a drink with them was actually the last thing I was willing to do. And I don't think any VC fund would have met with me. I didn't even really know what that was. Like, I had no idea. So it didn't strike me as something that there was a lot of money that somebody would pour into it. That, honestly, wasn't even an option to me in my mind at that time. +CHAD: How did the accelerator help you? +JENI: It helped me bring on a co-founder, which I would say was invaluable. [chuckles] And I learned a lot. I mean, I'm a person who's super curious and asks lots of questions. And so there was always somebody I could ask questions to, which was great, saved me a lot of time. And I also got to be in a cohort with other founders and see how they were growing their companies. So if you've never been around that stuff before, it's super helpful, I think, to just learn what other people are doing, like what other models there are, what other teams look like. +And I also realized, like, we were one of the only companies that had any revenue. I had no idea how we compared to anything else. And so I realized, oh, we're growing, and we're making money, and we're profitable. And it's really different than what a lot of other people are doing. So I knew that there was something to it also. I knew that we were really onto something. And then I will also say that fast forward a number of years, and our leader, one of the directors of our accelerator, I ended up hiring him to be our Chief Product Officer. So that was also very fortuitous [chuckles] and really an amazing story and outcome as well. +CHAD: Did you end up raising money coming out of the accelerator? +JENI: Nope. We soft circled around and had an opportunity to take an additional tranche from the accelerator, and we walked away from that at the time. And it was a really hard decision. Mostly because Sandy is Canadian, I don't know if that was made obvious, and I'm American. And we never envisioned wanting...like, building a remote company still in 2016 was not normal. And there was no way we were going to be in the same place. And the potential investors we were talking to, one of them in particular, was pretty adamant that we needed to be in person and have an actual office set up. And that was not negotiable for us. +And so we had been doing this fine. I mean, we were fine building a company together. And our first developer was in Asia, and then our designer at the time was in another part of the United States. So I was like, why would we do that? Why would we spend money and have to buy things like a fax machine and chairs? Why would we do that? +CHAD: [laughs] +JENI: That doesn't make any sense. And so that was one kind of red flag for me. And then also in the accelerator, I pitched to tons of people because you're sort of pitching, but also it's kind of practice. And I don't know how much of that was actual pitching. And I don't know how many of those investors were actually considering making investments, or they were just being nice and giving you their time and feedback. +But I pitched a ton, and the only people that we had soft circled were women. And I just had some negative experiences with some of the investors that we had pitched to, which that's also another podcast episode. And I was really bothered by, in particular, one conversation that I had. It was like a situation where someone said something really inappropriate to me, and I just absolutely did not want to do that. So that all factored in. +CHAD: Have you ever taken any investment? +JENI: Yeah. So this year, we have...because we have a situation where it makes sense to pour fuel on our...it made sense from a marketing standpoint to pour some money in. So we've just taken a small investment from angels, and we may take a little more as well. We're open-minded, I would say, right now about fundraising. +I have, in the last two years, taken a lot of meetings. So I've talked to lots of firms and lots of angels and get emails every day and so take a number of those meetings. So I've just tried to be really open-minded about it. So yeah, I would say I don't have such a negative association as what I had before. But I also would say my company is in a really different position now, and fundraising means something else to us. +CHAD: It sounds like you're in a little bit more control over the situation. And by working with individual angels probably, you're able to maintain that, I would guess. +JENI: Yeah. And it's definitely something where I think that there are...you know, I don't think it's helpful to be closed off to fundraising because I see that there are absolutely opportunities especially to go into new markets where being bootstrapped isn't practical because of the cost to go into those markets. And so, if it's something that's heavily regulated, for example, it's not a feasible option. So allowing us to have options and actually to be able to think through those options is important to me. +CHAD: So now that you've done that, what's next for Marvelous? What's the next challenge you're ready to tackle? +JENI: I would say we had this tremendous growth early in the pandemic, which really kind of unearthed, not really unearthed, I mean, I knew it was there [laughs] but really publicly unearthed a lot of technical debt. And that's, I think, normal for bootstrapped companies as well who are growing slowly and up to a point that they're not anymore. And so we spent a solid 18 months, I would say. Up until the end of 2021, there was a solid 18 months of really rebuilding the platform from the ground up. And so we've done that, and now we're in growth mode. +We're focusing on letting people know that we exist because I think we're quite well known in the wellness industry and in the yoga space in particular, but we're not as well known outside of that in other creator niches. And so it's about brand awareness. It's about really showing up as thought leaders in the space as well. We do a lot of writing and a lot of blogging and podcasting. And in particular, we serve women and non-binary creators in a way that I think no one else does. And so it's about disseminating the information that we have and the teachings that we have and letting people know we exist, and we're a resource for them. +CHAD: Yeah. Well, like you said, you have a strong reputation, and you have those roots in the wellness space, but you've expanded beyond that. If someone's out there listening, what would make them a potential customer or an ideal customer for Marvelous? +JENI: So anyone who's teaching, training, or coaching online, the software is really industry agnostic. And so we're just, again, not as well known yet in those other spaces. But especially someone who's integrating any cohort-based learning, or really heavily integrating coaching and live streaming, or group programs, or one-on-ones into an online course or a membership, for example, Marvelous is really second to none with all of that. Because again, live streaming and the integration of live teaching with on-demand content was what we started with and what we are known for. +And so it's not an afterthought the way that I think a lot of online teaching platforms and edtech companies have slapped on live streaming as like, oh, now you can integrate with Zoom or whatever. And for us, we have an integration with Zoom that's not like anything else. And then we have other WebRTC-based live streaming options, and everything is very well thought out and makes it really easy for the end-user so for the students and clients to be able to use the tool, which I think our audience really cares about that it's easy for their clients. +CHAD: I'd be remiss, and since this is a podcast, if I didn't mention that you and Sandy have a podcast. +JENI: We sure do, yeah. Thank you so much. laughs] +CHAD: It's called the And She Spoke Podcast, and where can folks find it? +JENI: So obviously anywhere that they listen to podcasts, but our website for the podcast is andshe.co. So I would love it if you're interested in conversations about women in tech, female founders, women, money and power, online business resources, and training. And that's mostly what we talk about. We're doing a crypto series right now, sort of like exploring crypto and the intersection of women and crypto, so that's going to be coming out shortly as well. +CHAD: Cool. If folks want to try out Marvelous or find out more or get in touch with you, where are all the places that they can do that? +JENI: So our website is heymarvelous.com. And we are @heymarvelous on Instagram. That's where we hang out the most. But we're also on TikTok, and Pinterest, and Facebook, and pretty much everywhere else as well. But Instagram, I would say, is the best place. +CHAD: That's great. Jeni, thanks so much for joining me and sharing your story and your advice. I'm sure people will really appreciate it. +JENI: Yeah, thank you so much for your time, Chad. I appreciate you having me. +CHAD: And you can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Jeni Barcelos. + + + Jeni Barcelos is the Co-Founder and CEO of Marvelous, the world's most beautiful all-in-one teaching platform.

+ +

Chad talks with Jeni about what makes Marvelous different from other teaching platforms out there, the importance of elevating women to leadership positions, and why applying for and getting accepted into an accelerator program was the right path for the company.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jeni Barcelos, the Co-Founder, and CEO of Marvelous, the world's most beautiful all-in-one teaching platform. Jeni, thank you so much for joining me.

+ +

JENI: Thank you for having me, Chad. I'm excited to be here and excited for our conversation.

+ +

CHAD: So I'm really excited to dig into more about Marvelous as well. So why don't we start there? What makes Marvelous different than other teaching platforms that are out there?

+ +

JENI: Marvelous is different in that we prioritize design, I would say more than any other competitive platform. And we also prioritize live events in a way that I think is pretty unique. So we started in the wellness space. We primarily are serving wellness creators, although all kinds of other creators use our tool as well.

+ +

So we specifically built Marvelous with the goal of serving their unique needs, which involves a lot of teaching live classes and having a really great community space where students and clients can build relationships with each other. And then, because our audience has a particular design aesthetic and is non-technical, we've created the tool in a way that makes it really easy to make something look beautiful very quickly and simply.

+ +

CHAD: So what caused you to differentiate yourself based on design?

+ +

JENI: I think just personal preference and aesthetic, to be honest. As we were building the platform, I realized very quickly that people were choosing us...one of the big reasons people were choosing us was because of the simple nature of the user interface and because of the design that it produced. And so we decided really early to prioritize that. And I would say it's also just I care deeply about design, and I don't like the idea of using tools that make that an afterthought.

+ +

And so I thought if I'm going to use it, and I do, I mean, we definitely dogfood our own platform and teach our own courses, we run our own communities there, I want it to look beautiful. [laughs] I want it to be a place that people enjoy spending time. We all spend more time, I think, than we want looking at screens. And so when you are going to engage in that practice and engage with other people on the internet, I think it's really nice to do it in a space that feels welcoming, and gentle, and beautiful.

+ +

CHAD: So you have a co-founder, Sandy. Are either of you designers or have a background in design?

+ +

JENI: Nope, not at all. Although I was one course away from minoring in art history in school. [laughter] No, I'm a lawyer. So I'm the opposite of a designer, although I think there's a part of me that thinks of myself as an artist. I wish that were my identity.

+ +

CHAD: So, given the importance of design that you discovered, how did you go about executing on that?

+ +

JENI: Hiring really great people, I would say, and having a really critical eye. And so, there's a tremendous amount of feedback that goes into our process. And now we have a head of brand in our company, and she can hold space for that design across both marketing and within product. So that hire, I think, has been critical for us to be able to maintain that as a priority.

+ +

CHAD: Where were you in the product life-cycle and business stage where you were able to hire really great people?

+ +

JENI: I would say within the last two years. So we are one of these startups that was in the right place at the right time when COVID hit. So luckily and unluckily, maybe we grew really fast in the wake of the pandemic, the beginning of the pandemic. And so that positioned us to hire pretty rapidly over the last two years. And that's when we really had the resources and the capacity to bring in that level of talent.

+ +

I'll say our creative director was working with us for many years before that but just in a part-time capacity so, you know, running her own agency. And we were hiring her out as we could because we were bootstrapped. And so it wasn't until we reached a certain level of growth where we could bring her on as a permanent fixture in the company.

+ +

CHAD: Yeah, that's often a way that I hear from founders to help get things off the grounds, particularly if you know of someone and would love to work with them and you know what they can produce, but you just can't afford to bring them on full-time as a member of the team at that point. Contracting with them, working with them part-time can be a great way to get that started. So let's rewind even further and tell me about the fateful day where you and Sandy first met each other.

+ +

JENI: Yeah, so we first met in Colorado Springs at an entrepreneurship event. And it was for an online program we had both been in that was teaching us how to start a SaaS company. And we are two of the only people that had actually done it and gotten to paying customers within six months, which was a pretty audacious goal, I would say to go from being non-technical and having no experience in the startup world to having a product or at least an MVP with paying customers within six months and no funding.

+ +

So we were 2 of maybe 5 or 6 people out of 550 in the program who did that. So we automatically kind of gravitated towards each other. And we were two of the only women also in the program. So we met at that event and got to know each other over the course of a number of days and retreated together. And then we just started really being accountability partners to one another as we were each building our own companies independently. And then that went on for another year, year and a half before Sandy joined my company.

+ +

CHAD: Okay, so you were already working on Marvelous?

+ +

JENI: Yeah. It had a different name at the time, but yes, I was six months into it when I met her.

+ +

CHAD: How did you convince her to do that?

+ +

JENI: We were actually growing...for a solo founder, we were growing to the point that I couldn't manage the company really on my own anymore. And so I applied to an accelerator just because I felt like I had other kinds of career experience but had, again, zero background in tech startups. And so, I came from teaching at a law school and building and scaling a nonprofit. And my background was in politics prior to that. So I had no idea what I was doing. Like, I didn't know what I didn't know, and so that thought scared me. And I just wanted to go immerse myself in an environment where I could ask a lot of questions and have access to resources and mentorships.

+ +

So anyway, I applied to an accelerator and got accepted contingent on having a team and having co-founders. And I was like, [laughs] well, that's why I need to come here because I don't know how to do that. Like, I don't know how I would do that. And so I reached out to Sandy because I mean, she had been more closely involved in the company than anyone else because we were constantly working together online and going on Zoom and helping each other build our companies.

+ +

She knew more than anyone else really what was involved. And she was always commenting how she wished she had started [chuckles] a company like this because it's just in the sector. Her background is in clinical wellness, and Marvelous really was serving yoga and wellness teachers. And so I said, "Well, why don't you come on board? I need to have at least one co-founder." Well, I was told I needed to have two, but I convinced them actually to accept me into the program with just one. So Sandy and I went into the accelerator together.

+ +

CHAD: I feel like that's a great sign that you were able to convince them to bend the rule. [laughs]

+ +

JENI: Yeah, I mean, I think that's actually my MO in life. So I also applied and got into graduate school at Yale without taking the GRE. So I have a history of these kinds of convincing arguments, I guess.

+ +

CHAD: [laughs]

+ +

JENI: And I'm a lawyer, right? So I was made for this. [chuckles]

+ +

CHAD: Yes. You sound like a very enjoyable person, though. So I find it hard to believe that you're... [laughs] No, I'm kidding.

+ +

JENI: I'm a human rights lawyer. So the only person I've ever represented in court was a pod of killer whales. So I'm a human rights and environmental attorney. So I'm not a corporate attorney by any means.

+ +

CHAD: So some people might describe going after things, bending the rules as ambition. And I was reading some of the things that you've written, so I'm not pulling this out of thin air. But I know that you talked before about how sometimes ambition, particularly from female-identifying people, can be seen as a problem. Why is that?

+ +

JENI: I mean, the short answer to that is the patriarchy of which we're all a part. Both men and women and non-binary people are all impacted greatly by the patriarchy. I mean, I think it's how girls are socialized. So that's a whole, I think, a whole other podcast conversation to have. But I mean, just even recently, I have a young daughter, and she was told not to raise her hand as much in school because she was so eager and raises her hand for every question that's asked. And that's unacceptable to me. But I was also told those things.

+ +

And I think just men and women are judged very differently in our culture, and that's just a fact of life. I mean, just look at, I mean, this is maybe opening up a can of worms. But if you just look at the way the Elizabeth Holmes trial played out versus so many other startup stories, and yes, there are differences, but it's really common in our culture to villainize female ambition and to look at it as problematic.

+ +

CHAD: Yeah, you're absolutely right that this is a whole podcast topic in and of itself, but I think it's an important one. But I'm curious; it can feel angering and powerless when something like that happens at school or in a system where it's very hard to control it or change it. But when it comes to your own company, you are in charge. So what have you done to try to make this different at Marvelous?

+ +

JENI: Well, I would say elevating women to leadership positions to the extent that we've been able, I mean, we're definitely a female-run company. We make decisions. Also, just even the way we provide benefits and salaries, it's in my mind done from a more holistic standpoint than I would say a lot of other small startups are doing. We prioritize people and their families and try to treat people like human beings versus just kind of pawns in our scheme to build a company, I would say. It's not perfect.

+ +

But I really think that so much of what goes on around kind of the women in tech stories so much of that and the women in fundraising stories has to do with women or non-binary people really having to prove themselves to a degree that is unrealistic in order to have the same treatment or the same opportunities as white men. So we are obviously very acutely aware of that. And so, in our own company, we're still very small but always trying to elevate the opportunities that women and people of color have in our company.

+ +

CHAD: And as you said, this permeates. It's systemic. And so, what might you do when you have a male manager with the best of intentions in a female-led company? I'm of the opinion that it's not enough to just assume that, oh, well, in that environment, this stuff won't happen because it is so ingrained. So are there other things that we can do as founders, as people, and leaders, as a company to create an environment where it's better for everybody?

+ +

JENI: I definitely don't have all the answers for this. But I would say we've put a lot of attention into coming up with core values that we really strongly affirm and reaffirm in the company and make sure that everyone is aware of those. I also just I'm constantly watching what's going on and noticing subtle cues when people start to pull back from contributing or some voices are much louder than others; just trying to notice that and not wait for something to be brought to my attention.

+ +

I think so much of it is also the culture, and it's hard in a situation like ours where we're a fully remote team with people across the world with their own different, you know, they're bringing their own cultures and their own values to the company. I mean, it's definitely hard. It's harder than I ever would have expected to get people on the same page.

+ +

And, I don't know, I don't have really good advice other than to say the founders should really agree on the core values. And then, those core values should be shared constantly. And I think it starts with the founder or the co-founder and the leadership team holding everyone to those values and standards.

+ +

CHAD: So as someone who, like you said earlier, you're not a software developer, you're not a designer, yet you are working on this idea and bringing it out into the world. How did you manage to do that? What did the very early steps look like for you?

+ +

JENI: So I started a company when I was essentially on maternity leave. I naively thought that that would be like a fun, little hobby project for me to start a tech company. Partly because I was spinning off what had really been a research project that was funded and incubated at a major university. I was spinning that off into a nonprofit with another co-founder, another lawyer. And I spent a great deal of time and energy fundraising and was constantly going and having meetings or drinks or dinner with people or even flying out to different foundations and meeting with donors.

+ +

And I was like, this is for me who...I have a body of work and have developed expertise as a climate change expert. And that word is problematic but, you know, someone who knows quite a lot about climate change in the law, edited one of the major textbooks in the area, taught some of the first curriculum on energy and the environment. I was constantly having to just go out and raise money all the time and mostly from people who had cashed out of tech companies.

+ +

So I was in Seattle at the time, you know, Microsoft and Amazon. There are a lot of people with significant wealth, and those are the people that are donating to organizations. And so I just thought I'm as smart and capable as these people. Like, why don't I have a revenue source that helps to fund the work that I want to do in the world? Which was a lot of human rights law and environmental law that's really underfunded really at that intersection of climate change and human rights.

+ +

And so I thought, well, I'm on maternity leave. I'm really interested in the wellness industry. I see it really being broken. I had gone through yoga teacher training like right at the tail end of law school just for my own mental health and wellbeing. And I just saw all of these friends and colleagues of mine struggling, and I just thought something wasn't quite right. So the first thing I did was I decided I'm going to try to build something to help them. And I set out to interview 75 yoga studio owners or managers in North America and did some research on the biggest markets at the time.

+ +

CHAD: Why 75?

+ +

JENI: Because I just thought that was a good number. If I talked to 75 people, I'd be able to have some good information. And I will say I had just come off of a couple of major projects where I had put together a big international conference in my field in climate justice. And I had also put together sort of a retreat of leaders in the field of scenario planning around that.

+ +

So I had really learned a lot and elevated my real career at the time by reaching out to people who I thought were thought leaders and experts in the field across different disciplines and having really honest, frank conversations and interviews with them. And I had been able to essentially tease out an entire field of work for myself from doing that.

+ +

So I brought my research and academic skills to bear, which was like, if I talk to enough people, I'm going to start to find some patterns. And I was curious, like, I couldn't quite understand. This wellness industry had been growing for over a decade at that point. It was this massive industry, and yet no one I knew who worked in the industry made any money. And I thought that was really weird. And I'm like, why is all the money going to apparel companies or a couple of big brands? Something is really broken in this model. I don't think the technology...tech hadn't really arrived to wellness at that point.

+ +

I came up with the idea to start doing this at the end of 2013, and so it was a long time ago. So I was just like, I'm going to talk to as many people as I can who are running businesses in the major metropolitan areas that are big yoga centers and just see what I can figure out. And so that's what really started it. And then, the idea for what was then called Namastream and is now called Marvelous came from those conversations. And it wasn't long; it was maybe six weeks into the research that I really started to...like, there were three or four ideas that I thought, well, here are product ideas that could really make a difference.

+ +

And so what I did is I sent out about 200 cold emails, and I had 74 interviews from that. And then I agreed to create a report like a white paper because, again, this is what I knew how to do as an academic is like I'm going to do a bunch of interviews, and then I'm going to write a report about it. And I'm going to share it with people. So I agreed to share the research with everyone who agreed to an interview. And so I think that's part of why they agreed to talk to me.

+ +

So yeah, so that's where the idea came from. And then again, I had no background in tech. I watched some trainings on how to do UX design, I think, like YouTube videos and stuff, and then I just did it. And I made the first prototype like a clickable prototype in Keynote because I knew how to use Keynote.

+ +

CHAD: Yeah, that's so great. Talking to people, using whatever tool you're comfortable with, Keynote, PowerPoint, that kind of thing to do clickable prototypes that's the exact kind of thing I encourage, we encourage our thoughtbot early-stage founders to do. So you were spot on. I don't know if you realized it at the time. But that's really great. What problem did those 74 or some strong subset of them have that streaming helped them with?

+ +

JENI: It was really interesting because there were a couple of studios. There were two studios at the time in Southern California that were doing this, and the bigger studios in these other major cities knew that. And so because there were so few, they were very well known way back. I mean, most of those conversations were in 2014 that I was having. Some of the studios, I mean, one of them is still a major company now.

+ +

You know, most studios had like 2,000 members. Like, a studio that I would interview had 2,000 customers on their list, like, possible customers. Some of those were people who were drop-ins or punch cards or whatever. And then the studios that were streaming had like 30,000 customers. And so that was starting to be known. And people had no idea how to do any of that themselves.

+ +

And so the problem that we are solving was when I would interview studios in the Boston area because that was one of the metropolitan areas I targeted; there were certain days out of the year that for snow closures like the studio would just lose all their revenue that day. In the south, there were studios that were impacted by hurricanes that were trying to figure out...and I'm a climate change lawyer, so I see this trend. I was looking at it from a disaster response scenario planning lens which was this is only going to get worse. I had no idea about the pandemic.

+ +

CHAD: Little did you know. [laughs]

+ +

JENI: Right? [laughs] I just thought like, wow, okay, the hurricanes are increasing in severity and duration. That's not going to change. Sea level rise is happening. Storms are becoming more unpredictable. Like, places that are cold are getting colder and have more snow on average. So all these people were complaining about lost revenue for these cataclysmic weather events. I just thought that as being a huge opportunity for a solution. So that was one reason why this idea really stood out to me.

+ +

And then also just knowing that...this actually goes back again to my own story. I used to work for Al Gore. I was one of the people that led his environmental outreach on his presidential campaign when I was a teenager. And then I ended up being one of the first people trained to give the climate presentation that he made famous in An Inconvenient Truth.

+ +

And so, I had been developing presentation materials in my legal and academic career that I was sharing with that organization. And I had to figure out how to record myself and then try to get it on a thumb drive and then send it to Nashville so they could watch it and learn how to present the slides that I was making.

+ +

And so I actually had this very different use case where I was like, it was really hard. I was on the board of another nonprofit that was bringing together environmental leaders once a year to learn new training materials and then go back out across the world to disseminate them. Again, the same thing. I was like; there is going to be such a need for some kind of streaming tool that's accessible by whoever wants to use it to be able to share knowledge and information. So both as a business tool, but it also kind of scratched this other itch that I had seen in my previous career, like, the career I thought I was taking a short break from.

+ +

And so I just was like, this is the future. And I had moved during this time across the country for my husband's job and had a new baby. And I missed my own yoga teacher. And so I thought, like, wow, I'm in North Carolina in this small town, and I really miss the Seattle community. And I miss my teachers there. I wish I could take these classes.

+ +

So for all of those reasons, I saw this as being a trend that wasn't going away, and that was only going to be more in need. And it was really early adopters at that point, like definitely not 74 studios telling me they needed this. But it was a big enough chunk of early adopters that I thought this is when you get to make something new that changes the industry.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you have the clickable prototype, and you feel like this is something here. What was the next step for you?

+ +

JENI: So I went back to everyone that had validated that idea, and I tried to sell it to them. [laughs] I had people PayPal.Me money in order to build it. I said, "You can become a founding customer, and you'll get access for a year included and with a payment." I think I was charging people; I don't know, a couple of thousand dollars. I don't even remember. It was a long time ago. It was under $2,000. "So you can get in now. You'll have a 20% discount on anything we make forever.

+ +

If you want to participate, you can be in this founding member circle with me. And as it's getting developed, you can provide feedback and help to shape exactly what it becomes." So I had enough people throw some money into the pot PayPal.Me money. I also had no idea how to take money from anyone. It was sort of like pre-Stripe being a normal thing. So I just had random people PayPal.Me money. And I took the money, and I hired a developer to build a prototype.

+ +

CHAD: How did you find that developer?

+ +

JENI: That was hard. So through this entrepreneurship course that I ended up meeting Sandy in, there was somebody who was a classmate, sort of like a mentor-level classmate who had done the course before who was an engineer at Microsoft. So I asked him to help me. I reached out and asked him to. And if I hadn't reached out to him, I would have reached out to other developers that I knew, just people in my extended circle of friends and stuff.

+ +

CHAD: So how long did it take from that point to get a product that people could actually use for their classes?

+ +

JENI: Early use, I would say like four months. So it was very, very, very beta. It's humiliating what it was.

+ +

CHAD: It should be. It should be humiliating.

+ +

JENI: Yeah, it should be. So it was like kind of a WordPress plugin. It was basically a glorified WordPress plugin, and that took about four months. And so I onboarded our early adopters who had given me the money, the checks, the PayPal money. That was the beginning of the summer that year. And I said, "You're the only people that are going to have access to it for the first three months," and that was part of the deal.

+ +

So I really worked around the clock helping them, working with my developer to solve any problems that were coming up, making changes. And then, in September, about three months later, I just figured out how to run Facebook ads. [laughs] So I just made up Facebook ads that ran to a one-on-one demo and let people book one-on-one demos with me through Facebook ads.

+ +

CHAD: So in those early days, if you had to do it over again, is there a lesson you learned that you might do it differently?

+ +

JENI: I don't think so, honestly. I feel like that first year; I feel pretty good about everything that I did. I mean, obviously, it would have been great to have someone like Sandy come in early on. But, I mean, I needed to figure some stuff out that I didn't need another person around to figure out, I guess. And I guess now, in like 2022, we're having this conversation. I wish I had dumped money into Facebook ads to have more demos because they were so cheap. [laughter]

+ +

CHAD: Right. Right.

+ +

JENI: It was so cheap for me to run ads. It was the golden days of online advertising, I guess. So I was probably paying like 40 cents a lead or something. [laughs] So yeah, maybe that. Because I was very much not wanting to put my own money into it. Like, once I raised the money to fund the prototype, I think I maybe in that first year put in like seven grand or something, but by the end of the year, I paid myself back.

+ +

CHAD: That's great.

+ +

JENI: I could have maybe put in a little more money. But I didn't know if it was going to work. Like, I wasn't really willing for...again, I wanted something that was very validated. And I expected fully to be going back to my career as soon as I got this thing launched. I was like, oh, this is just like a side hustle. This is going to be passive income. I did not understand that building a software company was not at all passive. I think I really bought into this idea that, like, oh, it's the internet. It will be passive income.

+ +

CHAD: When did it become clear to you that it wasn't?

+ +

JENI: Oh, I mean, I would say, you know, so I had a moment to go back to work, not my exact same job but to do work in my field between one month and two months after I launched and started running ads. I turned down a really incredible job offer, and I think that's when I knew it.

+ +

I was like, if I take a job, if I go back to work full-time...and I have the kind of career that's all-encompassing, and I sort of, whatever, I'm going to give 150% to whatever I'm doing. And so I knew that this thing would kind of die, but it was taking off. And so, I think I knew at that point I had to make a choice.

+ +

CHAD: And is that when you decided to apply to the accelerator?

+ +

JENI: No, it was like another nine months of growing it on my own before I applied to the accelerator. And I just kept doing what I was doing, and it was working. But I was doing things that didn't scale, so that was the problem. And so I didn't know, I mean, there's only so many one-on-one demos that the founder can do before you start to realize [laughs] you need to make some changes because I was doing them around the clock.

+ +

And then, at some point, I switched to webinars. I taught myself how to do webinars. And so then I was trying to do demos to multiple people at a time, but also, I didn't understand email marketing. I didn't understand copywriting. I was figuring everything out myself as I went, and I was burning out. So that's when I decided, like, oh, not everyone does this. I can't grow Microsoft or Amazon by doing this. I can't become that company. So obviously, I need to figure out how to scale. So that was when I decided to apply to the accelerator.

+ +

CHAD: Why apply to an accelerator as opposed to start fundraising, for example?

+ +

JENI: Oh my God. Well, so the whole reason I did this was so that I didn't have to go out for drinks with people and ask them for money. [laughter] I mean, I was not interested in that at all. And then I soon realized that that's what happens when you join an accelerator [laughs] is you basically just start learning to fundraise. But I didn't know that. I knew nothing. And so, I knew nothing about startups. I knew nothing about anything like this. I literally had no idea.

+ +

So the idea of going and sending emails to wealthy people to go have a drink with them was actually the last thing I was willing to do. And I don't think any VC fund would have met with me. I didn't even really know what that was. Like, I had no idea. So it didn't strike me as something that there was a lot of money that somebody would pour into it. That, honestly, wasn't even an option to me in my mind at that time.

+ +

CHAD: How did the accelerator help you?

+ +

JENI: It helped me bring on a co-founder, which I would say was invaluable. [chuckles] And I learned a lot. I mean, I'm a person who's super curious and asks lots of questions. And so there was always somebody I could ask questions to, which was great, saved me a lot of time. And I also got to be in a cohort with other founders and see how they were growing their companies. So if you've never been around that stuff before, it's super helpful, I think, to just learn what other people are doing, like what other models there are, what other teams look like.

+ +

And I also realized, like, we were one of the only companies that had any revenue. I had no idea how we compared to anything else. And so I realized, oh, we're growing, and we're making money, and we're profitable. And it's really different than what a lot of other people are doing. So I knew that there was something to it also. I knew that we were really onto something. And then I will also say that fast forward a number of years, and our leader, one of the directors of our accelerator, I ended up hiring him to be our Chief Product Officer. So that was also very fortuitous [chuckles] and really an amazing story and outcome as well.

+ +

CHAD: Did you end up raising money coming out of the accelerator?

+ +

JENI: Nope. We soft circled around and had an opportunity to take an additional tranche from the accelerator, and we walked away from that at the time. And it was a really hard decision. Mostly because Sandy is Canadian, I don't know if that was made obvious, and I'm American. And we never envisioned wanting...like, building a remote company still in 2016 was not normal. And there was no way we were going to be in the same place. And the potential investors we were talking to, one of them in particular, was pretty adamant that we needed to be in person and have an actual office set up. And that was not negotiable for us.

+ +

And so we had been doing this fine. I mean, we were fine building a company together. And our first developer was in Asia, and then our designer at the time was in another part of the United States. So I was like, why would we do that? Why would we spend money and have to buy things like a fax machine and chairs? Why would we do that?

+ +

CHAD: [laughs]

+ +

JENI: That doesn't make any sense. And so that was one kind of red flag for me. And then also in the accelerator, I pitched to tons of people because you're sort of pitching, but also it's kind of practice. And I don't know how much of that was actual pitching. And I don't know how many of those investors were actually considering making investments, or they were just being nice and giving you their time and feedback.

+ +

But I pitched a ton, and the only people that we had soft circled were women. And I just had some negative experiences with some of the investors that we had pitched to, which that's also another podcast episode. And I was really bothered by, in particular, one conversation that I had. It was like a situation where someone said something really inappropriate to me, and I just absolutely did not want to do that. So that all factored in.

+ +

CHAD: Have you ever taken any investment?

+ +

JENI: Yeah. So this year, we have...because we have a situation where it makes sense to pour fuel on our...it made sense from a marketing standpoint to pour some money in. So we've just taken a small investment from angels, and we may take a little more as well. We're open-minded, I would say, right now about fundraising.

+ +

I have, in the last two years, taken a lot of meetings. So I've talked to lots of firms and lots of angels and get emails every day and so take a number of those meetings. So I've just tried to be really open-minded about it. So yeah, I would say I don't have such a negative association as what I had before. But I also would say my company is in a really different position now, and fundraising means something else to us.

+ +

CHAD: It sounds like you're in a little bit more control over the situation. And by working with individual angels probably, you're able to maintain that, I would guess.

+ +

JENI: Yeah. And it's definitely something where I think that there are...you know, I don't think it's helpful to be closed off to fundraising because I see that there are absolutely opportunities especially to go into new markets where being bootstrapped isn't practical because of the cost to go into those markets. And so, if it's something that's heavily regulated, for example, it's not a feasible option. So allowing us to have options and actually to be able to think through those options is important to me.

+ +

CHAD: So now that you've done that, what's next for Marvelous? What's the next challenge you're ready to tackle?

+ +

JENI: I would say we had this tremendous growth early in the pandemic, which really kind of unearthed, not really unearthed, I mean, I knew it was there [laughs] but really publicly unearthed a lot of technical debt. And that's, I think, normal for bootstrapped companies as well who are growing slowly and up to a point that they're not anymore. And so we spent a solid 18 months, I would say. Up until the end of 2021, there was a solid 18 months of really rebuilding the platform from the ground up. And so we've done that, and now we're in growth mode.

+ +

We're focusing on letting people know that we exist because I think we're quite well known in the wellness industry and in the yoga space in particular, but we're not as well known outside of that in other creator niches. And so it's about brand awareness. It's about really showing up as thought leaders in the space as well. We do a lot of writing and a lot of blogging and podcasting. And in particular, we serve women and non-binary creators in a way that I think no one else does. And so it's about disseminating the information that we have and the teachings that we have and letting people know we exist, and we're a resource for them.

+ +

CHAD: Yeah. Well, like you said, you have a strong reputation, and you have those roots in the wellness space, but you've expanded beyond that. If someone's out there listening, what would make them a potential customer or an ideal customer for Marvelous?

+ +

JENI: So anyone who's teaching, training, or coaching online, the software is really industry agnostic. And so we're just, again, not as well known yet in those other spaces. But especially someone who's integrating any cohort-based learning, or really heavily integrating coaching and live streaming, or group programs, or one-on-ones into an online course or a membership, for example, Marvelous is really second to none with all of that. Because again, live streaming and the integration of live teaching with on-demand content was what we started with and what we are known for.

+ +

And so it's not an afterthought the way that I think a lot of online teaching platforms and edtech companies have slapped on live streaming as like, oh, now you can integrate with Zoom or whatever. And for us, we have an integration with Zoom that's not like anything else. And then we have other WebRTC-based live streaming options, and everything is very well thought out and makes it really easy for the end-user so for the students and clients to be able to use the tool, which I think our audience really cares about that it's easy for their clients.

+ +

CHAD: I'd be remiss, and since this is a podcast, if I didn't mention that you and Sandy have a podcast.

+ +

JENI: We sure do, yeah. Thank you so much. laughs]

+ +

CHAD: It's called the And She Spoke Podcast, and where can folks find it?

+ +

JENI: So obviously anywhere that they listen to podcasts, but our website for the podcast is andshe.co. So I would love it if you're interested in conversations about women in tech, female founders, women, money and power, online business resources, and training. And that's mostly what we talk about. We're doing a crypto series right now, sort of like exploring crypto and the intersection of women and crypto, so that's going to be coming out shortly as well.

+ +

CHAD: Cool. If folks want to try out Marvelous or find out more or get in touch with you, where are all the places that they can do that?

+ +

JENI: So our website is heymarvelous.com. And we are @heymarvelous on Instagram. That's where we hang out the most. But we're also on TikTok, and Pinterest, and Facebook, and pretty much everywhere else as well. But Instagram, I would say, is the best place.

+ +

CHAD: That's great. Jeni, thanks so much for joining me and sharing your story and your advice. I'm sure people will really appreciate it.

+ +

JENI: Yeah, thank you so much for your time, Chad. I appreciate you having me.

+ +

CHAD: And you can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jeni Barcelos.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jeni Barcelos is the Co-Founder and CEO of Marvelous, the world's most beautiful all-in-one teaching platform.

+ +

Chad talks with Jeni about what makes Marvelous different from other teaching platforms out there, the importance of elevating women to leadership positions, and why applying for and getting accepted into an accelerator program was the right path for the company.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jeni Barcelos, the Co-Founder, and CEO of Marvelous, the world's most beautiful all-in-one teaching platform. Jeni, thank you so much for joining me.

+ +

JENI: Thank you for having me, Chad. I'm excited to be here and excited for our conversation.

+ +

CHAD: So I'm really excited to dig into more about Marvelous as well. So why don't we start there? What makes Marvelous different than other teaching platforms that are out there?

+ +

JENI: Marvelous is different in that we prioritize design, I would say more than any other competitive platform. And we also prioritize live events in a way that I think is pretty unique. So we started in the wellness space. We primarily are serving wellness creators, although all kinds of other creators use our tool as well.

+ +

So we specifically built Marvelous with the goal of serving their unique needs, which involves a lot of teaching live classes and having a really great community space where students and clients can build relationships with each other. And then, because our audience has a particular design aesthetic and is non-technical, we've created the tool in a way that makes it really easy to make something look beautiful very quickly and simply.

+ +

CHAD: So what caused you to differentiate yourself based on design?

+ +

JENI: I think just personal preference and aesthetic, to be honest. As we were building the platform, I realized very quickly that people were choosing us...one of the big reasons people were choosing us was because of the simple nature of the user interface and because of the design that it produced. And so we decided really early to prioritize that. And I would say it's also just I care deeply about design, and I don't like the idea of using tools that make that an afterthought.

+ +

And so I thought if I'm going to use it, and I do, I mean, we definitely dogfood our own platform and teach our own courses, we run our own communities there, I want it to look beautiful. [laughs] I want it to be a place that people enjoy spending time. We all spend more time, I think, than we want looking at screens. And so when you are going to engage in that practice and engage with other people on the internet, I think it's really nice to do it in a space that feels welcoming, and gentle, and beautiful.

+ +

CHAD: So you have a co-founder, Sandy. Are either of you designers or have a background in design?

+ +

JENI: Nope, not at all. Although I was one course away from minoring in art history in school. [laughter] No, I'm a lawyer. So I'm the opposite of a designer, although I think there's a part of me that thinks of myself as an artist. I wish that were my identity.

+ +

CHAD: So, given the importance of design that you discovered, how did you go about executing on that?

+ +

JENI: Hiring really great people, I would say, and having a really critical eye. And so, there's a tremendous amount of feedback that goes into our process. And now we have a head of brand in our company, and she can hold space for that design across both marketing and within product. So that hire, I think, has been critical for us to be able to maintain that as a priority.

+ +

CHAD: Where were you in the product life-cycle and business stage where you were able to hire really great people?

+ +

JENI: I would say within the last two years. So we are one of these startups that was in the right place at the right time when COVID hit. So luckily and unluckily, maybe we grew really fast in the wake of the pandemic, the beginning of the pandemic. And so that positioned us to hire pretty rapidly over the last two years. And that's when we really had the resources and the capacity to bring in that level of talent.

+ +

I'll say our creative director was working with us for many years before that but just in a part-time capacity so, you know, running her own agency. And we were hiring her out as we could because we were bootstrapped. And so it wasn't until we reached a certain level of growth where we could bring her on as a permanent fixture in the company.

+ +

CHAD: Yeah, that's often a way that I hear from founders to help get things off the grounds, particularly if you know of someone and would love to work with them and you know what they can produce, but you just can't afford to bring them on full-time as a member of the team at that point. Contracting with them, working with them part-time can be a great way to get that started. So let's rewind even further and tell me about the fateful day where you and Sandy first met each other.

+ +

JENI: Yeah, so we first met in Colorado Springs at an entrepreneurship event. And it was for an online program we had both been in that was teaching us how to start a SaaS company. And we are two of the only people that had actually done it and gotten to paying customers within six months, which was a pretty audacious goal, I would say to go from being non-technical and having no experience in the startup world to having a product or at least an MVP with paying customers within six months and no funding.

+ +

So we were 2 of maybe 5 or 6 people out of 550 in the program who did that. So we automatically kind of gravitated towards each other. And we were two of the only women also in the program. So we met at that event and got to know each other over the course of a number of days and retreated together. And then we just started really being accountability partners to one another as we were each building our own companies independently. And then that went on for another year, year and a half before Sandy joined my company.

+ +

CHAD: Okay, so you were already working on Marvelous?

+ +

JENI: Yeah. It had a different name at the time, but yes, I was six months into it when I met her.

+ +

CHAD: How did you convince her to do that?

+ +

JENI: We were actually growing...for a solo founder, we were growing to the point that I couldn't manage the company really on my own anymore. And so I applied to an accelerator just because I felt like I had other kinds of career experience but had, again, zero background in tech startups. And so, I came from teaching at a law school and building and scaling a nonprofit. And my background was in politics prior to that. So I had no idea what I was doing. Like, I didn't know what I didn't know, and so that thought scared me. And I just wanted to go immerse myself in an environment where I could ask a lot of questions and have access to resources and mentorships.

+ +

So anyway, I applied to an accelerator and got accepted contingent on having a team and having co-founders. And I was like, [laughs] well, that's why I need to come here because I don't know how to do that. Like, I don't know how I would do that. And so I reached out to Sandy because I mean, she had been more closely involved in the company than anyone else because we were constantly working together online and going on Zoom and helping each other build our companies.

+ +

She knew more than anyone else really what was involved. And she was always commenting how she wished she had started [chuckles] a company like this because it's just in the sector. Her background is in clinical wellness, and Marvelous really was serving yoga and wellness teachers. And so I said, "Well, why don't you come on board? I need to have at least one co-founder." Well, I was told I needed to have two, but I convinced them actually to accept me into the program with just one. So Sandy and I went into the accelerator together.

+ +

CHAD: I feel like that's a great sign that you were able to convince them to bend the rule. [laughs]

+ +

JENI: Yeah, I mean, I think that's actually my MO in life. So I also applied and got into graduate school at Yale without taking the GRE. So I have a history of these kinds of convincing arguments, I guess.

+ +

CHAD: [laughs]

+ +

JENI: And I'm a lawyer, right? So I was made for this. [chuckles]

+ +

CHAD: Yes. You sound like a very enjoyable person, though. So I find it hard to believe that you're... [laughs] No, I'm kidding.

+ +

JENI: I'm a human rights lawyer. So the only person I've ever represented in court was a pod of killer whales. So I'm a human rights and environmental attorney. So I'm not a corporate attorney by any means.

+ +

CHAD: So some people might describe going after things, bending the rules as ambition. And I was reading some of the things that you've written, so I'm not pulling this out of thin air. But I know that you talked before about how sometimes ambition, particularly from female-identifying people, can be seen as a problem. Why is that?

+ +

JENI: I mean, the short answer to that is the patriarchy of which we're all a part. Both men and women and non-binary people are all impacted greatly by the patriarchy. I mean, I think it's how girls are socialized. So that's a whole, I think, a whole other podcast conversation to have. But I mean, just even recently, I have a young daughter, and she was told not to raise her hand as much in school because she was so eager and raises her hand for every question that's asked. And that's unacceptable to me. But I was also told those things.

+ +

And I think just men and women are judged very differently in our culture, and that's just a fact of life. I mean, just look at, I mean, this is maybe opening up a can of worms. But if you just look at the way the Elizabeth Holmes trial played out versus so many other startup stories, and yes, there are differences, but it's really common in our culture to villainize female ambition and to look at it as problematic.

+ +

CHAD: Yeah, you're absolutely right that this is a whole podcast topic in and of itself, but I think it's an important one. But I'm curious; it can feel angering and powerless when something like that happens at school or in a system where it's very hard to control it or change it. But when it comes to your own company, you are in charge. So what have you done to try to make this different at Marvelous?

+ +

JENI: Well, I would say elevating women to leadership positions to the extent that we've been able, I mean, we're definitely a female-run company. We make decisions. Also, just even the way we provide benefits and salaries, it's in my mind done from a more holistic standpoint than I would say a lot of other small startups are doing. We prioritize people and their families and try to treat people like human beings versus just kind of pawns in our scheme to build a company, I would say. It's not perfect.

+ +

But I really think that so much of what goes on around kind of the women in tech stories so much of that and the women in fundraising stories has to do with women or non-binary people really having to prove themselves to a degree that is unrealistic in order to have the same treatment or the same opportunities as white men. So we are obviously very acutely aware of that. And so, in our own company, we're still very small but always trying to elevate the opportunities that women and people of color have in our company.

+ +

CHAD: And as you said, this permeates. It's systemic. And so, what might you do when you have a male manager with the best of intentions in a female-led company? I'm of the opinion that it's not enough to just assume that, oh, well, in that environment, this stuff won't happen because it is so ingrained. So are there other things that we can do as founders, as people, and leaders, as a company to create an environment where it's better for everybody?

+ +

JENI: I definitely don't have all the answers for this. But I would say we've put a lot of attention into coming up with core values that we really strongly affirm and reaffirm in the company and make sure that everyone is aware of those. I also just I'm constantly watching what's going on and noticing subtle cues when people start to pull back from contributing or some voices are much louder than others; just trying to notice that and not wait for something to be brought to my attention.

+ +

I think so much of it is also the culture, and it's hard in a situation like ours where we're a fully remote team with people across the world with their own different, you know, they're bringing their own cultures and their own values to the company. I mean, it's definitely hard. It's harder than I ever would have expected to get people on the same page.

+ +

And, I don't know, I don't have really good advice other than to say the founders should really agree on the core values. And then, those core values should be shared constantly. And I think it starts with the founder or the co-founder and the leadership team holding everyone to those values and standards.

+ +

CHAD: So as someone who, like you said earlier, you're not a software developer, you're not a designer, yet you are working on this idea and bringing it out into the world. How did you manage to do that? What did the very early steps look like for you?

+ +

JENI: So I started a company when I was essentially on maternity leave. I naively thought that that would be like a fun, little hobby project for me to start a tech company. Partly because I was spinning off what had really been a research project that was funded and incubated at a major university. I was spinning that off into a nonprofit with another co-founder, another lawyer. And I spent a great deal of time and energy fundraising and was constantly going and having meetings or drinks or dinner with people or even flying out to different foundations and meeting with donors.

+ +

And I was like, this is for me who...I have a body of work and have developed expertise as a climate change expert. And that word is problematic but, you know, someone who knows quite a lot about climate change in the law, edited one of the major textbooks in the area, taught some of the first curriculum on energy and the environment. I was constantly having to just go out and raise money all the time and mostly from people who had cashed out of tech companies.

+ +

So I was in Seattle at the time, you know, Microsoft and Amazon. There are a lot of people with significant wealth, and those are the people that are donating to organizations. And so I just thought I'm as smart and capable as these people. Like, why don't I have a revenue source that helps to fund the work that I want to do in the world? Which was a lot of human rights law and environmental law that's really underfunded really at that intersection of climate change and human rights.

+ +

And so I thought, well, I'm on maternity leave. I'm really interested in the wellness industry. I see it really being broken. I had gone through yoga teacher training like right at the tail end of law school just for my own mental health and wellbeing. And I just saw all of these friends and colleagues of mine struggling, and I just thought something wasn't quite right. So the first thing I did was I decided I'm going to try to build something to help them. And I set out to interview 75 yoga studio owners or managers in North America and did some research on the biggest markets at the time.

+ +

CHAD: Why 75?

+ +

JENI: Because I just thought that was a good number. If I talked to 75 people, I'd be able to have some good information. And I will say I had just come off of a couple of major projects where I had put together a big international conference in my field in climate justice. And I had also put together sort of a retreat of leaders in the field of scenario planning around that.

+ +

So I had really learned a lot and elevated my real career at the time by reaching out to people who I thought were thought leaders and experts in the field across different disciplines and having really honest, frank conversations and interviews with them. And I had been able to essentially tease out an entire field of work for myself from doing that.

+ +

So I brought my research and academic skills to bear, which was like, if I talk to enough people, I'm going to start to find some patterns. And I was curious, like, I couldn't quite understand. This wellness industry had been growing for over a decade at that point. It was this massive industry, and yet no one I knew who worked in the industry made any money. And I thought that was really weird. And I'm like, why is all the money going to apparel companies or a couple of big brands? Something is really broken in this model. I don't think the technology...tech hadn't really arrived to wellness at that point.

+ +

I came up with the idea to start doing this at the end of 2013, and so it was a long time ago. So I was just like, I'm going to talk to as many people as I can who are running businesses in the major metropolitan areas that are big yoga centers and just see what I can figure out. And so that's what really started it. And then, the idea for what was then called Namastream and is now called Marvelous came from those conversations. And it wasn't long; it was maybe six weeks into the research that I really started to...like, there were three or four ideas that I thought, well, here are product ideas that could really make a difference.

+ +

And so what I did is I sent out about 200 cold emails, and I had 74 interviews from that. And then I agreed to create a report like a white paper because, again, this is what I knew how to do as an academic is like I'm going to do a bunch of interviews, and then I'm going to write a report about it. And I'm going to share it with people. So I agreed to share the research with everyone who agreed to an interview. And so I think that's part of why they agreed to talk to me.

+ +

So yeah, so that's where the idea came from. And then again, I had no background in tech. I watched some trainings on how to do UX design, I think, like YouTube videos and stuff, and then I just did it. And I made the first prototype like a clickable prototype in Keynote because I knew how to use Keynote.

+ +

CHAD: Yeah, that's so great. Talking to people, using whatever tool you're comfortable with, Keynote, PowerPoint, that kind of thing to do clickable prototypes that's the exact kind of thing I encourage, we encourage our thoughtbot early-stage founders to do. So you were spot on. I don't know if you realized it at the time. But that's really great. What problem did those 74 or some strong subset of them have that streaming helped them with?

+ +

JENI: It was really interesting because there were a couple of studios. There were two studios at the time in Southern California that were doing this, and the bigger studios in these other major cities knew that. And so because there were so few, they were very well known way back. I mean, most of those conversations were in 2014 that I was having. Some of the studios, I mean, one of them is still a major company now.

+ +

You know, most studios had like 2,000 members. Like, a studio that I would interview had 2,000 customers on their list, like, possible customers. Some of those were people who were drop-ins or punch cards or whatever. And then the studios that were streaming had like 30,000 customers. And so that was starting to be known. And people had no idea how to do any of that themselves.

+ +

And so the problem that we are solving was when I would interview studios in the Boston area because that was one of the metropolitan areas I targeted; there were certain days out of the year that for snow closures like the studio would just lose all their revenue that day. In the south, there were studios that were impacted by hurricanes that were trying to figure out...and I'm a climate change lawyer, so I see this trend. I was looking at it from a disaster response scenario planning lens which was this is only going to get worse. I had no idea about the pandemic.

+ +

CHAD: Little did you know. [laughs]

+ +

JENI: Right? [laughs] I just thought like, wow, okay, the hurricanes are increasing in severity and duration. That's not going to change. Sea level rise is happening. Storms are becoming more unpredictable. Like, places that are cold are getting colder and have more snow on average. So all these people were complaining about lost revenue for these cataclysmic weather events. I just thought that as being a huge opportunity for a solution. So that was one reason why this idea really stood out to me.

+ +

And then also just knowing that...this actually goes back again to my own story. I used to work for Al Gore. I was one of the people that led his environmental outreach on his presidential campaign when I was a teenager. And then I ended up being one of the first people trained to give the climate presentation that he made famous in An Inconvenient Truth.

+ +

And so, I had been developing presentation materials in my legal and academic career that I was sharing with that organization. And I had to figure out how to record myself and then try to get it on a thumb drive and then send it to Nashville so they could watch it and learn how to present the slides that I was making.

+ +

And so I actually had this very different use case where I was like, it was really hard. I was on the board of another nonprofit that was bringing together environmental leaders once a year to learn new training materials and then go back out across the world to disseminate them. Again, the same thing. I was like; there is going to be such a need for some kind of streaming tool that's accessible by whoever wants to use it to be able to share knowledge and information. So both as a business tool, but it also kind of scratched this other itch that I had seen in my previous career, like, the career I thought I was taking a short break from.

+ +

And so I just was like, this is the future. And I had moved during this time across the country for my husband's job and had a new baby. And I missed my own yoga teacher. And so I thought, like, wow, I'm in North Carolina in this small town, and I really miss the Seattle community. And I miss my teachers there. I wish I could take these classes.

+ +

So for all of those reasons, I saw this as being a trend that wasn't going away, and that was only going to be more in need. And it was really early adopters at that point, like definitely not 74 studios telling me they needed this. But it was a big enough chunk of early adopters that I thought this is when you get to make something new that changes the industry.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you have the clickable prototype, and you feel like this is something here. What was the next step for you?

+ +

JENI: So I went back to everyone that had validated that idea, and I tried to sell it to them. [laughs] I had people PayPal.Me money in order to build it. I said, "You can become a founding customer, and you'll get access for a year included and with a payment." I think I was charging people; I don't know, a couple of thousand dollars. I don't even remember. It was a long time ago. It was under $2,000. "So you can get in now. You'll have a 20% discount on anything we make forever.

+ +

If you want to participate, you can be in this founding member circle with me. And as it's getting developed, you can provide feedback and help to shape exactly what it becomes." So I had enough people throw some money into the pot PayPal.Me money. I also had no idea how to take money from anyone. It was sort of like pre-Stripe being a normal thing. So I just had random people PayPal.Me money. And I took the money, and I hired a developer to build a prototype.

+ +

CHAD: How did you find that developer?

+ +

JENI: That was hard. So through this entrepreneurship course that I ended up meeting Sandy in, there was somebody who was a classmate, sort of like a mentor-level classmate who had done the course before who was an engineer at Microsoft. So I asked him to help me. I reached out and asked him to. And if I hadn't reached out to him, I would have reached out to other developers that I knew, just people in my extended circle of friends and stuff.

+ +

CHAD: So how long did it take from that point to get a product that people could actually use for their classes?

+ +

JENI: Early use, I would say like four months. So it was very, very, very beta. It's humiliating what it was.

+ +

CHAD: It should be. It should be humiliating.

+ +

JENI: Yeah, it should be. So it was like kind of a WordPress plugin. It was basically a glorified WordPress plugin, and that took about four months. And so I onboarded our early adopters who had given me the money, the checks, the PayPal money. That was the beginning of the summer that year. And I said, "You're the only people that are going to have access to it for the first three months," and that was part of the deal.

+ +

So I really worked around the clock helping them, working with my developer to solve any problems that were coming up, making changes. And then, in September, about three months later, I just figured out how to run Facebook ads. [laughs] So I just made up Facebook ads that ran to a one-on-one demo and let people book one-on-one demos with me through Facebook ads.

+ +

CHAD: So in those early days, if you had to do it over again, is there a lesson you learned that you might do it differently?

+ +

JENI: I don't think so, honestly. I feel like that first year; I feel pretty good about everything that I did. I mean, obviously, it would have been great to have someone like Sandy come in early on. But, I mean, I needed to figure some stuff out that I didn't need another person around to figure out, I guess. And I guess now, in like 2022, we're having this conversation. I wish I had dumped money into Facebook ads to have more demos because they were so cheap. [laughter]

+ +

CHAD: Right. Right.

+ +

JENI: It was so cheap for me to run ads. It was the golden days of online advertising, I guess. So I was probably paying like 40 cents a lead or something. [laughs] So yeah, maybe that. Because I was very much not wanting to put my own money into it. Like, once I raised the money to fund the prototype, I think I maybe in that first year put in like seven grand or something, but by the end of the year, I paid myself back.

+ +

CHAD: That's great.

+ +

JENI: I could have maybe put in a little more money. But I didn't know if it was going to work. Like, I wasn't really willing for...again, I wanted something that was very validated. And I expected fully to be going back to my career as soon as I got this thing launched. I was like, oh, this is just like a side hustle. This is going to be passive income. I did not understand that building a software company was not at all passive. I think I really bought into this idea that, like, oh, it's the internet. It will be passive income.

+ +

CHAD: When did it become clear to you that it wasn't?

+ +

JENI: Oh, I mean, I would say, you know, so I had a moment to go back to work, not my exact same job but to do work in my field between one month and two months after I launched and started running ads. I turned down a really incredible job offer, and I think that's when I knew it.

+ +

I was like, if I take a job, if I go back to work full-time...and I have the kind of career that's all-encompassing, and I sort of, whatever, I'm going to give 150% to whatever I'm doing. And so I knew that this thing would kind of die, but it was taking off. And so, I think I knew at that point I had to make a choice.

+ +

CHAD: And is that when you decided to apply to the accelerator?

+ +

JENI: No, it was like another nine months of growing it on my own before I applied to the accelerator. And I just kept doing what I was doing, and it was working. But I was doing things that didn't scale, so that was the problem. And so I didn't know, I mean, there's only so many one-on-one demos that the founder can do before you start to realize [laughs] you need to make some changes because I was doing them around the clock.

+ +

And then, at some point, I switched to webinars. I taught myself how to do webinars. And so then I was trying to do demos to multiple people at a time, but also, I didn't understand email marketing. I didn't understand copywriting. I was figuring everything out myself as I went, and I was burning out. So that's when I decided, like, oh, not everyone does this. I can't grow Microsoft or Amazon by doing this. I can't become that company. So obviously, I need to figure out how to scale. So that was when I decided to apply to the accelerator.

+ +

CHAD: Why apply to an accelerator as opposed to start fundraising, for example?

+ +

JENI: Oh my God. Well, so the whole reason I did this was so that I didn't have to go out for drinks with people and ask them for money. [laughter] I mean, I was not interested in that at all. And then I soon realized that that's what happens when you join an accelerator [laughs] is you basically just start learning to fundraise. But I didn't know that. I knew nothing. And so, I knew nothing about startups. I knew nothing about anything like this. I literally had no idea.

+ +

So the idea of going and sending emails to wealthy people to go have a drink with them was actually the last thing I was willing to do. And I don't think any VC fund would have met with me. I didn't even really know what that was. Like, I had no idea. So it didn't strike me as something that there was a lot of money that somebody would pour into it. That, honestly, wasn't even an option to me in my mind at that time.

+ +

CHAD: How did the accelerator help you?

+ +

JENI: It helped me bring on a co-founder, which I would say was invaluable. [chuckles] And I learned a lot. I mean, I'm a person who's super curious and asks lots of questions. And so there was always somebody I could ask questions to, which was great, saved me a lot of time. And I also got to be in a cohort with other founders and see how they were growing their companies. So if you've never been around that stuff before, it's super helpful, I think, to just learn what other people are doing, like what other models there are, what other teams look like.

+ +

And I also realized, like, we were one of the only companies that had any revenue. I had no idea how we compared to anything else. And so I realized, oh, we're growing, and we're making money, and we're profitable. And it's really different than what a lot of other people are doing. So I knew that there was something to it also. I knew that we were really onto something. And then I will also say that fast forward a number of years, and our leader, one of the directors of our accelerator, I ended up hiring him to be our Chief Product Officer. So that was also very fortuitous [chuckles] and really an amazing story and outcome as well.

+ +

CHAD: Did you end up raising money coming out of the accelerator?

+ +

JENI: Nope. We soft circled around and had an opportunity to take an additional tranche from the accelerator, and we walked away from that at the time. And it was a really hard decision. Mostly because Sandy is Canadian, I don't know if that was made obvious, and I'm American. And we never envisioned wanting...like, building a remote company still in 2016 was not normal. And there was no way we were going to be in the same place. And the potential investors we were talking to, one of them in particular, was pretty adamant that we needed to be in person and have an actual office set up. And that was not negotiable for us.

+ +

And so we had been doing this fine. I mean, we were fine building a company together. And our first developer was in Asia, and then our designer at the time was in another part of the United States. So I was like, why would we do that? Why would we spend money and have to buy things like a fax machine and chairs? Why would we do that?

+ +

CHAD: [laughs]

+ +

JENI: That doesn't make any sense. And so that was one kind of red flag for me. And then also in the accelerator, I pitched to tons of people because you're sort of pitching, but also it's kind of practice. And I don't know how much of that was actual pitching. And I don't know how many of those investors were actually considering making investments, or they were just being nice and giving you their time and feedback.

+ +

But I pitched a ton, and the only people that we had soft circled were women. And I just had some negative experiences with some of the investors that we had pitched to, which that's also another podcast episode. And I was really bothered by, in particular, one conversation that I had. It was like a situation where someone said something really inappropriate to me, and I just absolutely did not want to do that. So that all factored in.

+ +

CHAD: Have you ever taken any investment?

+ +

JENI: Yeah. So this year, we have...because we have a situation where it makes sense to pour fuel on our...it made sense from a marketing standpoint to pour some money in. So we've just taken a small investment from angels, and we may take a little more as well. We're open-minded, I would say, right now about fundraising.

+ +

I have, in the last two years, taken a lot of meetings. So I've talked to lots of firms and lots of angels and get emails every day and so take a number of those meetings. So I've just tried to be really open-minded about it. So yeah, I would say I don't have such a negative association as what I had before. But I also would say my company is in a really different position now, and fundraising means something else to us.

+ +

CHAD: It sounds like you're in a little bit more control over the situation. And by working with individual angels probably, you're able to maintain that, I would guess.

+ +

JENI: Yeah. And it's definitely something where I think that there are...you know, I don't think it's helpful to be closed off to fundraising because I see that there are absolutely opportunities especially to go into new markets where being bootstrapped isn't practical because of the cost to go into those markets. And so, if it's something that's heavily regulated, for example, it's not a feasible option. So allowing us to have options and actually to be able to think through those options is important to me.

+ +

CHAD: So now that you've done that, what's next for Marvelous? What's the next challenge you're ready to tackle?

+ +

JENI: I would say we had this tremendous growth early in the pandemic, which really kind of unearthed, not really unearthed, I mean, I knew it was there [laughs] but really publicly unearthed a lot of technical debt. And that's, I think, normal for bootstrapped companies as well who are growing slowly and up to a point that they're not anymore. And so we spent a solid 18 months, I would say. Up until the end of 2021, there was a solid 18 months of really rebuilding the platform from the ground up. And so we've done that, and now we're in growth mode.

+ +

We're focusing on letting people know that we exist because I think we're quite well known in the wellness industry and in the yoga space in particular, but we're not as well known outside of that in other creator niches. And so it's about brand awareness. It's about really showing up as thought leaders in the space as well. We do a lot of writing and a lot of blogging and podcasting. And in particular, we serve women and non-binary creators in a way that I think no one else does. And so it's about disseminating the information that we have and the teachings that we have and letting people know we exist, and we're a resource for them.

+ +

CHAD: Yeah. Well, like you said, you have a strong reputation, and you have those roots in the wellness space, but you've expanded beyond that. If someone's out there listening, what would make them a potential customer or an ideal customer for Marvelous?

+ +

JENI: So anyone who's teaching, training, or coaching online, the software is really industry agnostic. And so we're just, again, not as well known yet in those other spaces. But especially someone who's integrating any cohort-based learning, or really heavily integrating coaching and live streaming, or group programs, or one-on-ones into an online course or a membership, for example, Marvelous is really second to none with all of that. Because again, live streaming and the integration of live teaching with on-demand content was what we started with and what we are known for.

+ +

And so it's not an afterthought the way that I think a lot of online teaching platforms and edtech companies have slapped on live streaming as like, oh, now you can integrate with Zoom or whatever. And for us, we have an integration with Zoom that's not like anything else. And then we have other WebRTC-based live streaming options, and everything is very well thought out and makes it really easy for the end-user so for the students and clients to be able to use the tool, which I think our audience really cares about that it's easy for their clients.

+ +

CHAD: I'd be remiss, and since this is a podcast, if I didn't mention that you and Sandy have a podcast.

+ +

JENI: We sure do, yeah. Thank you so much. laughs]

+ +

CHAD: It's called the And She Spoke Podcast, and where can folks find it?

+ +

JENI: So obviously anywhere that they listen to podcasts, but our website for the podcast is andshe.co. So I would love it if you're interested in conversations about women in tech, female founders, women, money and power, online business resources, and training. And that's mostly what we talk about. We're doing a crypto series right now, sort of like exploring crypto and the intersection of women and crypto, so that's going to be coming out shortly as well.

+ +

CHAD: Cool. If folks want to try out Marvelous or find out more or get in touch with you, where are all the places that they can do that?

+ +

JENI: So our website is heymarvelous.com. And we are @heymarvelous on Instagram. That's where we hang out the most. But we're also on TikTok, and Pinterest, and Facebook, and pretty much everywhere else as well. But Instagram, I would say, is the best place.

+ +

CHAD: That's great. Jeni, thanks so much for joining me and sharing your story and your advice. I'm sure people will really appreciate it.

+ +

JENI: Yeah, thank you so much for your time, Chad. I appreciate you having me.

+ +

CHAD: And you can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jeni Barcelos.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kNRA6-XK + + ]]> + + Chad Pytel + Jeni Barcelos + + + 425: SweetProcess with Owen McGab Enaohwo + https://podcast.thoughtbot.com/425 + 0e4b3580-17bd-407f-bc79-a5f29ddcaf94 + Thu, 02 Jun 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Owen McGab Enaohwo is the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams and employees easily document procedures, implement processes, and manage tasks. + +Chad talks with Owen about taking specific root issues and building software around them, overcoming resistance to the core idea of documenting processes, and the importance of having the freedom and ability to be empowered to make changes to organizational documents that outline how you do your work. + 32:42 + no + + + Owen McGab Enaohwo is the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams and employees easily document procedures, implement processes, and manage tasks. +Chad talks with Owen about taking specific root issues and building software around them, overcoming resistance to the core idea of documenting processes, and the importance of having the freedom and ability to be empowered to make changes to organizational documents that outline how you do your work. +SweetProcess (https://www.sweetprocess.com/) +Follow SweetProcess on Twitter (https://twitter.com/SweetProcess), Facebook (https://www.facebook.com/SweetProcess), or LinkedIn (https://www.linkedin.com/company/sweetprocess/). +52 Sample Standard Operating Procedure Templates (https://sweetprocess.ac-page.com/52sopstemplates) +Follow Owen on Twitter (https://twitter.com/HYVAssistant) or LinkedIn (https://www.linkedin.com/in/owenmcgabenaohwo/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is Owen McGab Enaohwo, the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams as well as employees easily document procedures, implement processes, and manage tasks. Owen, thank you so much for joining me. +OWEN: Thanks for having me. I really appreciate you inviting me as a guest on here. +CHAD: I could only return the favor as I recently went on one of the podcasts that you run over at the SweetProcess. I'm happy to have you on the show. +OWEN: Great, great. +CHAD: Let's dive in a little bit to SweetProcess. You know, it's a tool for documenting process. And I'm curious what led you to founding SweetProcess and creating this product? +OWEN: That's a great question. So what happened was SweetProcess was actually founded in, I think, the fourth quarter of 2013. And before then, I had an agency where I would provide entrepreneurs in the U.S., so small to medium-sized business owners, with back-office support, basically, people in the Philippines doing back-office support for them here in the U.S. +And so people had read these books that were very popular at that time, The 4-Hour Workweek, or the World Is Flat. And then suddenly they realize that being able to hire people abroad and outsource work was not limited to only the larger companies like the telecoms and all that that would go and hire like 150 or more people in these countries working at their phone support 24/7 and all that. So these books exposed small business owners to the idea that even they themselves can do it on a smaller scale and outsource a lot of their work. And so that's what I was doing. +But the issues that I ran into was that first of all; they were coming to me with this idea that the moment they hire that immediately the person will hit the ground running and start doing the work magically, not realizing that for that to happen, there needs to have been documentation in place. Because first of all, the person you're hiring is in a different country, different culture and all that. There's that that you have going against you. +But then also, they're not even with you physically where you can say you can teach them by talking to them while they're next to you. So they're in a whole different location. So the more clear your instructions are in terms of having standard operating procedures in front of them, the more easier and quickly they're going to deliver the results you want, and so that was the first thing. +The second thing was they were very busy wearing so many hats. They didn't have time to document these procedures that we needed to do the work for them. So we came up with this strategy where we would meet with our clients at the time online on Zoom, not Zoom; Zoom wasn't the thing at the time. It was...what was it called? Skype. +CHAD: Skype. +OWEN: Yeah. So we would meet with them online, and we'd have recorded sessions with them where they would walk us through what they were doing then record those conversations. And then, someone else on my team would take this conversation and document standard operating procedure step by step from what they told us. +Now, on the backend, the issue we had was to do this documentation and have tools in place so that people can actually have one place where they could go and find all these documents for our clients. It was either we were using enterprise-level tools that were first of all hard to use for my team talk less of the clients. So these tools were not even built for small to medium-sized businesses. Or we were basically hacking to get a bunch of free tools to achieve that purpose of documentation and having one place where people can go find stuff. +So in the back of my mind, I was like, man, there has to be a better tool that does this. And so fast forward, I was invited as a guest on to Mixergy. It's another very popular podcast for tech startups. I don't know if you know of him. His name is Andrew Warner. And so, he has two versions of the podcast. The first version is the one where people go in there and talk about the biography of their business or themselves and how they were able to build a tech startup that sold for millions or whatever. +And then the other version of the podcast was one that was behind a paid subscription where people come on; they're experts, come on there and talk about specific topics like very concrete-sized topics that people are paying him to learn from. So people could come on here to learn about sales, marketing. In my case, I was brought on there to teach the listeners how they can basically document procedures and processes so that you can hand over work and no longer be the bottleneck in their business. +Lo and behold, my co-founder, Jervis, who is a programmer and now my co-founder and CTO for SweetProcess, listened to that course that I did for Mixergy. He reached out to me and said he has an idea he is working on similar to what I was talking about, the whole way of simplifying documentation. And he just had some questions about this idea he had in his head. And being the kind of person I am, open to conversation, I said, "Okay. Let's go ahead. Let's meet." +So we had a conversation. And after our conversation, I was like, "Dude; I'm running into the same issue that you're talking about right now because we do this for our customers. We do the documentation for them. But the tools are not the way they should be. Instead of me just giving you ideas on how to do that, and then you go from here, would you be interested if we go ahead and work together and build this software together and build this as a company together?" And he was excited. He was like, "Okay, let's do it." +And then I said, "Okay, instead of jumping ahead to build the software, one of the things I want to do is avoid a situation where the software ends up being hard to use and feature-bloated like the other software that we are running into right now. Why don't we spend some time having conversations with potential customers to totally understand this problem of documenting procedures and having one place where employees can go to find stuff and how employees can collaborate together to improve stuff?" +So I wanted to really understand the problem by talking to people. So we spent like about a month or so. I spoke to more than 30 different people running different companies just to get the ideas of the problems they were having with this very specific topic. And we came back, we analyzed all the conversations, and we were able to put down a list of root-specific problems that people were having. +Because people will suggest features of what they want, but if you drill down and ask them deeper and deeper like, "Why this?" You know, just going into the problem they have and try to get to the root why behind it, then you will end up having a situation where you find a bunch of specific things that are similar between all the different people you spoke to, but they are not saying the same features. +So we took those specific root issues that we were coming across, and we were able to now go ahead and build our software based on that as opposed to launching a software where at the time with a lot of competitors has not as much features as they had. But we focused on simplicity. We focused on solving the root issues and getting rid of a lot of the complex stuff. +Like, for instance, some of the software were focused on having some kind of feature and technology sets where it was focused on the business consultant or the expert person on the company who's going to come and document stuff. But we said, "No, the owners of the business don't care about that. It's really more about how does this help them. They don't care about the terminologies and all that." So we got rid of all the bloat and all the stuff and just focused on simplicity based on having these conversations that we had with the people that I spoke of earlier and also based on my own experience using these harder-to-use software. +CHAD: Well, I really appreciate and commend that because it's a common pitfall. I'm a big believer in building software for yourself that you really understand and a product that you yourself are going to use. But some founders, when faced with that, they'll be like, "Well, I don't need to talk to anybody. I'm the customer. I know everything that is needed. And let's just do what I know we need to do." So to be in a position where you were able to take a step back from that and talk to some other people and make sure you were on the right track, that's really great. +OWEN: And besides the fact of talking to people to help us streamline and simplify the software, another thing we did was open my eyes to the idea that this problem we're solving basically run across multiple different verticals or industries besides the industry I was in. The industry I was in was basically the outsourcing industry, trying to help people outsource their back-office support. +But I realized that the problem was even people that actually want to use the software for documenting didn't really care so much about outsourcing work. It was more about employees they have internally being able to do work predictably and at the scale they wanted it, delivering results that they wanted, and hence they needed that documentation. So without having these conversations, you don't get to see these things that you didn't know going in. +CHAD: Actually, that touches on one of the things I was wondering about, which is the market for your product is essentially every company in the entire world. [laughter] So, with such a huge potential market, are there things you've identified as who your ideal customers are or what kinds of customers come to SweetProcess on their own, what stage they're at, those kinds of things? +OWEN: Great question. So what we've realized is from the customers who stay 24 months or more with us typically are the much larger companies that have over 20 employees based on the data we have. So what we found is the smaller companies, we encourage them to use SweetProcess because we always want people to start early in the process of documenting procedures. +But what you realize is that these smaller companies...let me backtrack. So the software solves that problem of having documentation in place and collaborating together to improve these documents over time. And that's really because they are trying to make sure that from a production standpoint of delivering the results to their customers, they have all these instructions. And so their employees can carry out those tasks that they cannot automate. Those tasks that need to be done by human beings, employees can carry it out predictably. Now, that's them trying to deliver output to their customers. +When a company is less than five employees or even less than ten employees, they don't have so much issues or worries with production. Their main biggest issue is how to get customers, how to get sales in the first place. So their focus initially is more on okay; let me figure out a system for sales. Let me figure out a system for marketing and all that. +But on the other hand, when you already have 20 or more employees, to a large extent, you have figured out your sales pipeline, your marketing pipeline, and all that. And now you really want to make sure that the people you've hired can hit the ground running and do work predictably and deliver the results you want. So that's why it makes sense that these companies that have more employees tend to be the ones that have the need for the software, for what we do. +CHAD: Who ends up often finding and championing SweetProcess within an organization? Is it typically someone in a leadership position like a CEO? +OWEN: Great question. So it breaks down based on the size of the company. And now I'm giving you all the juice because my competitors are listening to this now. +CHAD: [laughs] +OWEN: But anyway, it is based on the size of the company. It's like if it's between 20 or let's say between 10 to 20-30 employees, most likely it's the CEO who has this pressure that, hey, I need to make sure that employees can go to one single place and find step by step instructions on how to do their work. I need to make sure the onboarding can be done faster. I need to make sure that if anybody leaves this company, we're not scrambling to figure out how work is done. So they start looking for a tool like SweetProcess. +Now, beyond that, let's say 30 to maybe 100 employees, it's now like the CEO, not the CEO but the Chief Operating Officer, someone who the CEO has hired onboard as the person in charge of operations at the company. Now, once we get beyond that 100 to, let's say, 1,000 employee kind of thing, we're now looking at someone that is a level below the COO, the Chief Operating Officer, and those usually are the operations manager. +So that's how it works; it's based on the size of the companies. It's either the CEO that's reaching out to us or the Chief Operating Officer or someone who's an operations manager at the larger companies looking to...and especially with the operations manager thing, it's usually they're trying to bring in SweetProcess to start in their department or whatever and then usually to scale-out besides their department to other parts of the company. +CHAD: How do you reach those people? +OWEN: So you mentioned something that the fact that the problem we solve cuts across the board, different verticals. It's not industry-specific. So that's a good and bad problem to have. Because if you're only selling to a specific industry, all you got to do is basically be everywhere anyone who is in that industry is at, all the podcasts, all the trades, and everything, just basically be there, and that's it. +But because the software we sell cuts across different industries, it's kind of harder to do that. So what we decided to do is focus more on creating content around the problem itself so that when people are looking for how to solve their problem, they're able to find us regardless of the industry they are in. +Mid-Roll Ad: +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: Do you find that there's resistance to the core idea of documenting process? +OWEN: Oh yes. There's resistance in different levels. Sometimes people think it has to be, you know, robotic, and sometimes they think it has to be complicated. Then it's also "I don't have time to handle the documentation." I hope that I also get to share some cheat codes on how to actually do that on this podcast. I don't want to leave the listeners just hearing about the history of the company but also giving them in case they're in that stage in their company how to go about it. +CHAD: Well, that's exactly what I was going to ask you about, so yes. +OWEN: Good, good. So, first of all, if you think about it, you only need to document procedures only at a time when you're trying to document how a task that you do on a repetitive basis, recurring basis. Because if a task is a one-time thing that you're never going to do ever again, well, there's really no need to document it. So we're now left with only recurring tasks. Now, people might just want to get excited and start documenting just because it's based on a recurring task. But I say, no, hold your brakes. +First of all, let's have this conversation with the employees and managers or whatever and say, "I know we've been doing this over and over again. But is this task necessary?" Because it might just be tribal knowledge thing where we've always done this, so let's keep doing it. No. But if you have that critical conversation and say, "Okay, is this very thing that we've always done, is it necessary or not?" If the answer is not necessary, okay, simply and quickly eliminate it. There's no need to start documenting how that task is done. If it's not necessarily, eliminate it. +If it's a situation where you already have procedures or processes in place, and they are already existing, and you're trying to come into a software like SweetProcess, even before you start importing those documents, I want you to take a look at those documents and say, "Are these things documenting tasks that are even necessary in the first place?" And if they are not, eliminate them. +So now, let's say we are at the point where you've eliminated stuff that is not necessary. The recurring task left you have no choice, but you need to do them. Now let's break those two tasks into two categories. The first category is revenue-generating tasks, basically, tasks that bring in money to the company. And the other one is, you know, they're not necessarily revenue-generating, but they're necessary and more of the operation side of things. You need to do them. They don't bring in revenues, per se, but you need to do them to produce whatever stuff that you've promised the customer. +So people might be excited to want to jump in and start documenting the tasks that bring in revenue. But I say don't do that because if you start that and you document those tasks that bring in revenue, you're also going to be tempted to say, "Okay, let me go find employees or new employees or sales whatever to come and start doing those activities that bring in revenue that I just documented." Now you're going to get more people or more customers coming into the chaos that is already in there because there are a lot of bottlenecks. +So I say focus on these bottleneck tasks first. Find the biggest bottleneck that takes the most of your time. Start from there first. And then, once you've documented how that task is done, you find the next biggest bottleneck, you document that, and you move to the next one. Before you know, you've eventually documented all the big bottlenecks in your day and the time of your manager and all that stuff. And you guys are now freeing up time to focus on these nice income-generating activities. +So the next question is okay; I've figured out a big bottleneck task to focus on. How do I document it? Does it have to be an encyclopedia? The answer is no. I want you to do one thing, install that mindset of continuous improvement in your mind, install that mindset of continuous improvement in the mindset of your managers as well as your ground-level employees. Once you have that mindset in place, it basically gives you the permission to say, "Okay, we're going to start from version 1.0 today, which is going to be rudimentary and not have that much in there." But we're telling ourselves since this is continuous improvement, it's going to keep improving as we go. +So the first thing you do is document what I call a minimum viable procedure, which is just a fancy way of saying a procedure that has the title of the procedure and the title of each of the steps. That's the first thing. And the best time to even do such a thing is while you're doing the task itself because at that point, it's highest and best in your memory so it's easy to just, you know, whether you're using a tool like SweetProcess or using whatever tool, that's the best time to actually document that minimum viable procedure. So title of the procedure, title of each of the steps. And that's it. +What do you do next? How do you get more details filled in? First of all, I don't want you to think it's only you that will be responsible for filling in the details. It needs to be a collaborative thing. So get your employees involved, anybody who you've trained verbally on the task before on how to do it. It could be a manager or some ground-level employee who you've trained verbally on how to do the task. Say, "Okay, I just documented this procedure. Here are the steps for the procedure. You've already done the task before. Come and collaborate with me to fill out the details." +So now the employee goes in there and starts step number one, starts entering the details in there. And also, let them know that the details they're going to each step doesn't have to be 100% perfect. It just needs to be enough instructions in there, be it text, be it screenshots, or whatever, that at least someone else can take these details that they've put in there and at least get started. Again, the goal is not to be 100% perfect with the end results of each procedure. At least if someone can take a procedure and get 60% of the way towards the output, that's a good place to be so because, again, we've installed that mindset of continuous improvement. +Besides collaborating together to fill out the details of the document, how do you then continuously improve the document? This is the cheat code there for this one now is anytime an employee is carrying out a task, you need to make sure that they are also looking at that procedure that you guys have built together because a lot of the insight that comes around improving a document comes when they are actually doing the work; it's not from when they are documenting how the work is done. But when they are doing the work is where the aha and all these things comes to them. +So let's say a document or a procedure has ten steps. Now the employee is doing the work, and the procedure is right in front of them. They are now able to say, "Okay, why do we need ten steps for this? I just found a better way. We probably just only need four steps." Now they can now take that input; hopefully, it's a proactive employee that we all want; they can take that input and pass it back to you. And that document can be improved based on that feedback. +Or they might come across some new way that was not even encountered for or discussed in the document, and now that feedback can as well be passed to you so that you can improve that document based on the feedback. But you see how all these things I've talked about, if you don't have the right software in place, it might be a little bit tricky. And that's why when we built SweetProcess, we made sure that it has everything in one place where the documentation side of things and how to collaborate together with the team to document is in one place, as well as the actual aspect of getting work done, which is assigning tasks. +So, for instance, in SweetProcess, you cannot assign a task to someone that is not based...every task you assign to someone must be based on an underlying procedure you've already documented. So when the employee is actually getting the work done, the instruction is right there in front of them as they are getting the work done in real-time. And if they come across any changes or anything, they can pass that back to you, the manager, who you can make changes on their behalf. +Or, if they are the proactive employee, they can literally click a button to edit the underlying procedure and make the changes while giving you the management oversight. So all these insights that I've shared about how to do it regardless of whether you use SweetProcess was based on our initial finding when we had all these conversations, and we put it in together and packaged it into our software. +CHAD: I'm glad that you touch on this idea of continuous improvement, one, because it's one of our core values at thoughtbot is continuous improvement. And I think it's one of the challenges that we have despite it being one of our values. We've been around for 19 years now. We have a very robust internal documentation handbook, procedures, and the way a lot of things are done. And I think it's very easy for someone to show up in that environment and even have all of the best intentions about practicing continuous improvement. +But when so much is already laid out for you, it can become easy to fall into the trap of saying, "Well, the answer to everything is here, and I don't need to worry about improving it because clearly..." I don't know; it just builds up this culture of like, we've got things figured out. And it's easy to just fall into the mindset I think of just blindly following the things there and not actually looking at them critically while you do it. +OWEN: Well, I think that is the wrong way to think about stuff because maybe people are thinking, oh, documenting might make the employees robotic, and maybe they don't have a say in what's going on because maybe the instruction has been passed on to them, and that's it. But the way we want people to think about this and the way we built the software is that it needs to be a collaborative thing where it's not just one person that does it. +So that's why in this software and in our software, we allow even the ground-level employee who has been assigned tasks based on the underlying document they are empowered to literally go in there and click the edit button and make the changes to it, knowing that yes, the manager or the owner of the company still has management oversight to approve the changes. +But then, even deeper than that, from a cultural standpoint, what other way can you have your voice heard in a company than when you have a tangible role in the actual improvement of how the work is done? Because that's what the procedures are, right? Your document procedures for how work is done. Guess who is doing the work? You. And if you have the ability to, and you are empowered to make changes to the documents that outline how you do your work, that is you literally having your voice heard. +On top of that, I think documenting procedures allows you to be more creative. So imagine if you're a manager and there's a specific task you do maybe every three months, and you don't have a document for it. Now, at the time it comes when you need to do this task three months from now, you're going to have to start context switching, remembering okay, how do I do this? +Spending all this time trying to figure out how to do something and then when you figure it out, now you're going to spend time doing it. But imagine if, on the other hand, you had the instructions right there in front of you. You don't have to spend one single minute remembering anything. The instructions are right there in front of you. +You get started on doing the task; what does that allow you to do? First of all, it allows you to get the task done faster, but then it also frees up your mind to start asking yourself the question like, how can I make this be done better? How can I improve this stuff? How can I get rid of some of these steps? That's where the creativity comes in. And you start thinking of new and better ways to get things done. +Because remember, documenting procedures is all about, okay, creating steps and instructions for how those tasks that you cannot automate that will be done by human beings are done the right way. But eventually, they get to certain points wherein parts of the task, you can figure out certain things to automate, and you get rid of the manual aspect of human beings doing it. So this is where this whole creativity comes into the whole thing of documenting. That's the way to think about it. +CHAD: Yeah, that's great. One of the tools, additionally, or techniques that we use a thoughtbot too is there are times where you might have a sense that something isn't quite working right or be improved, or maybe a non-technical person is the one doing the task. And they have a sense that it could be better, but they don't necessarily have the skills to know how to automate it or something like that. +To have people come together in what we call a retrospective format where you're identifying things that might be better or could be improved. You're talking about them and coming up with action items for improving them. It's is a nice forum that we have for talking about maybe the more vague feeling that someone has that something could be better and then coming up with a way to improve it as a team. Is that something that you do at SweetProcess? +OWEN: Well, yeah. So we have a bunch of different tasks that we do. And every now and then, we get to a point where we asked ourselves, is there a way we can automate this so that we don't have to do…? I'll give you an example. Every time...before we automated this when someone signs up for SweetProcess, a lot of our customers come through us creating content that addresses these questions all around documenting and how do you scale the operations of your company and so on and so forth. So a lot of people come through our content. +And as a result of coming through our content, they get into our email automation. We use ActiveCampaign, and they get into our email automation. And before, in the past, before we automated this when someone came in, they get into our email list, and then eventually, they sign up for a trial of our software. And then, we will get this email about it, and we will have to manually go into the tool that we use for our email automation and change their status so that they don't keep getting emails from us as if they were not trial. That became a thing where we were doing too much. +And we said, you know, "Hey, let's get some engineering on this," and basically got API integration built directly with our software so that when someone signs up for trial, it looks to see is this person already in the email list as someone who's not a trial user? Yes. So let's move them in a different...tag them the right tags and put them in a different category so that now they receive a whole bunch of different emails. +But the signal for us to decide that we needed to automate that stuff was doing it manually. Although we had step-by-step instructions on how to do it, it was still taking time. And so we said, "Okay, can we automate this?" And so we got to the level where we automated the stuff, and now it's not a thing that we have to even worry about or have someone do. It's just automated. +CHAD: You have a degree in computer science, right? +OWEN: Yes. +CHAD: Do you wonder or…because I sort of have this theory about myself too because I have a degree in computer science as well. But I'm now still doing some development but in operations as well. And sort of this systemized thinking or systems thinking, do you think it comes from our technical backgrounds, your technical background? +OWEN: I think you can say part of it was enhanced by this, but I've always had this mindset of when I see things like maybe if I go to a company and I see how customer service is happening or how they produce things, I've always been fascinated with how things move around within the different parts of a company to end up with the outcome that I'm trying to achieve. +Like, people might be having fun watching music videos, but I don't mind sitting down and watching a manufacturing plant like a video showing how they...because I've always been fascinated with how things come together to make the output. And so then you throw in the computer science degree there, and that also enhances that thinking. So I think from my own standpoint, it was just me personally always wanting to know the ingredients that you put together to make something happen. I'm always fascinated by stuff like that. So I'm always thinking systems-wise. +CHAD: That's great. If folks want to get in touch with you or try out SweetProcess, where are the different places that they can do that? +OWEN: So obviously, they can go to sweetprocess.com. And you'll be welcome to try out a free 14-day trial of the software. But one of the things I want to leave with you as a gift is I've shared with you how to go about documenting procedures. But you might also want to have templates in front of you so that you're not starting from a blank screen. You have a bunch of… +What I'm offering is about 52 standard operating procedure templates that you can download right after this interview. You can go to sweetprocess.com/giantrobots, and you'll be able to download it. And that's sweet like candy, process like process, forward slash giant robots just like the name of this podcast or sweetprocess.com/giantrobots. And you'll be able to get a PDF that contains 52 standard operating procedures, and from there, you can tweak it and build upon the templates. +CHAD: That's awesome. I'll make sure that we link that in the notes, which will be right in people's podcast player too. +OWEN: Thanks for having me on the call. I really appreciate it. +CHAD: Yeah, if folks want to get in touch with you, where are the places where they might do that? +OWEN: owen@sweetprocess.com, very easy. +CHAD: Awesome. Thank you so much for joining me. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Owen McGab Enaohwo is the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams and employees easily document procedures, implement processes, and manage tasks.

+ +

Chad talks with Owen about taking specific root issues and building software around them, overcoming resistance to the core idea of documenting processes, and the importance of having the freedom and ability to be empowered to make changes to organizational documents that outline how you do your work.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is Owen McGab Enaohwo, the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams as well as employees easily document procedures, implement processes, and manage tasks. Owen, thank you so much for joining me.

+ +

OWEN: Thanks for having me. I really appreciate you inviting me as a guest on here.

+ +

CHAD: I could only return the favor as I recently went on one of the podcasts that you run over at the SweetProcess. I'm happy to have you on the show.

+ +

OWEN: Great, great.

+ +

CHAD: Let's dive in a little bit to SweetProcess. You know, it's a tool for documenting process. And I'm curious what led you to founding SweetProcess and creating this product?

+ +

OWEN: That's a great question. So what happened was SweetProcess was actually founded in, I think, the fourth quarter of 2013. And before then, I had an agency where I would provide entrepreneurs in the U.S., so small to medium-sized business owners, with back-office support, basically, people in the Philippines doing back-office support for them here in the U.S.

+ +

And so people had read these books that were very popular at that time, The 4-Hour Workweek, or the World Is Flat. And then suddenly they realize that being able to hire people abroad and outsource work was not limited to only the larger companies like the telecoms and all that that would go and hire like 150 or more people in these countries working at their phone support 24/7 and all that. So these books exposed small business owners to the idea that even they themselves can do it on a smaller scale and outsource a lot of their work. And so that's what I was doing.

+ +

But the issues that I ran into was that first of all; they were coming to me with this idea that the moment they hire that immediately the person will hit the ground running and start doing the work magically, not realizing that for that to happen, there needs to have been documentation in place. Because first of all, the person you're hiring is in a different country, different culture and all that. There's that that you have going against you.

+ +

But then also, they're not even with you physically where you can say you can teach them by talking to them while they're next to you. So they're in a whole different location. So the more clear your instructions are in terms of having standard operating procedures in front of them, the more easier and quickly they're going to deliver the results you want, and so that was the first thing.

+ +

The second thing was they were very busy wearing so many hats. They didn't have time to document these procedures that we needed to do the work for them. So we came up with this strategy where we would meet with our clients at the time online on Zoom, not Zoom; Zoom wasn't the thing at the time. It was...what was it called? Skype.

+ +

CHAD: Skype.

+ +

OWEN: Yeah. So we would meet with them online, and we'd have recorded sessions with them where they would walk us through what they were doing then record those conversations. And then, someone else on my team would take this conversation and document standard operating procedure step by step from what they told us.

+ +

Now, on the backend, the issue we had was to do this documentation and have tools in place so that people can actually have one place where they could go and find all these documents for our clients. It was either we were using enterprise-level tools that were first of all hard to use for my team talk less of the clients. So these tools were not even built for small to medium-sized businesses. Or we were basically hacking to get a bunch of free tools to achieve that purpose of documentation and having one place where people can go find stuff.

+ +

So in the back of my mind, I was like, man, there has to be a better tool that does this. And so fast forward, I was invited as a guest on to Mixergy. It's another very popular podcast for tech startups. I don't know if you know of him. His name is Andrew Warner. And so, he has two versions of the podcast. The first version is the one where people go in there and talk about the biography of their business or themselves and how they were able to build a tech startup that sold for millions or whatever.

+ +

And then the other version of the podcast was one that was behind a paid subscription where people come on; they're experts, come on there and talk about specific topics like very concrete-sized topics that people are paying him to learn from. So people could come on here to learn about sales, marketing. In my case, I was brought on there to teach the listeners how they can basically document procedures and processes so that you can hand over work and no longer be the bottleneck in their business.

+ +

Lo and behold, my co-founder, Jervis, who is a programmer and now my co-founder and CTO for SweetProcess, listened to that course that I did for Mixergy. He reached out to me and said he has an idea he is working on similar to what I was talking about, the whole way of simplifying documentation. And he just had some questions about this idea he had in his head. And being the kind of person I am, open to conversation, I said, "Okay. Let's go ahead. Let's meet."

+ +

So we had a conversation. And after our conversation, I was like, "Dude; I'm running into the same issue that you're talking about right now because we do this for our customers. We do the documentation for them. But the tools are not the way they should be. Instead of me just giving you ideas on how to do that, and then you go from here, would you be interested if we go ahead and work together and build this software together and build this as a company together?" And he was excited. He was like, "Okay, let's do it."

+ +

And then I said, "Okay, instead of jumping ahead to build the software, one of the things I want to do is avoid a situation where the software ends up being hard to use and feature-bloated like the other software that we are running into right now. Why don't we spend some time having conversations with potential customers to totally understand this problem of documenting procedures and having one place where employees can go to find stuff and how employees can collaborate together to improve stuff?"

+ +

So I wanted to really understand the problem by talking to people. So we spent like about a month or so. I spoke to more than 30 different people running different companies just to get the ideas of the problems they were having with this very specific topic. And we came back, we analyzed all the conversations, and we were able to put down a list of root-specific problems that people were having.

+ +

Because people will suggest features of what they want, but if you drill down and ask them deeper and deeper like, "Why this?" You know, just going into the problem they have and try to get to the root why behind it, then you will end up having a situation where you find a bunch of specific things that are similar between all the different people you spoke to, but they are not saying the same features.

+ +

So we took those specific root issues that we were coming across, and we were able to now go ahead and build our software based on that as opposed to launching a software where at the time with a lot of competitors has not as much features as they had. But we focused on simplicity. We focused on solving the root issues and getting rid of a lot of the complex stuff.

+ +

Like, for instance, some of the software were focused on having some kind of feature and technology sets where it was focused on the business consultant or the expert person on the company who's going to come and document stuff. But we said, "No, the owners of the business don't care about that. It's really more about how does this help them. They don't care about the terminologies and all that." So we got rid of all the bloat and all the stuff and just focused on simplicity based on having these conversations that we had with the people that I spoke of earlier and also based on my own experience using these harder-to-use software.

+ +

CHAD: Well, I really appreciate and commend that because it's a common pitfall. I'm a big believer in building software for yourself that you really understand and a product that you yourself are going to use. But some founders, when faced with that, they'll be like, "Well, I don't need to talk to anybody. I'm the customer. I know everything that is needed. And let's just do what I know we need to do." So to be in a position where you were able to take a step back from that and talk to some other people and make sure you were on the right track, that's really great.

+ +

OWEN: And besides the fact of talking to people to help us streamline and simplify the software, another thing we did was open my eyes to the idea that this problem we're solving basically run across multiple different verticals or industries besides the industry I was in. The industry I was in was basically the outsourcing industry, trying to help people outsource their back-office support.

+ +

But I realized that the problem was even people that actually want to use the software for documenting didn't really care so much about outsourcing work. It was more about employees they have internally being able to do work predictably and at the scale they wanted it, delivering results that they wanted, and hence they needed that documentation. So without having these conversations, you don't get to see these things that you didn't know going in.

+ +

CHAD: Actually, that touches on one of the things I was wondering about, which is the market for your product is essentially every company in the entire world. [laughter] So, with such a huge potential market, are there things you've identified as who your ideal customers are or what kinds of customers come to SweetProcess on their own, what stage they're at, those kinds of things?

+ +

OWEN: Great question. So what we've realized is from the customers who stay 24 months or more with us typically are the much larger companies that have over 20 employees based on the data we have. So what we found is the smaller companies, we encourage them to use SweetProcess because we always want people to start early in the process of documenting procedures.

+ +

But what you realize is that these smaller companies...let me backtrack. So the software solves that problem of having documentation in place and collaborating together to improve these documents over time. And that's really because they are trying to make sure that from a production standpoint of delivering the results to their customers, they have all these instructions. And so their employees can carry out those tasks that they cannot automate. Those tasks that need to be done by human beings, employees can carry it out predictably. Now, that's them trying to deliver output to their customers.

+ +

When a company is less than five employees or even less than ten employees, they don't have so much issues or worries with production. Their main biggest issue is how to get customers, how to get sales in the first place. So their focus initially is more on okay; let me figure out a system for sales. Let me figure out a system for marketing and all that.

+ +

But on the other hand, when you already have 20 or more employees, to a large extent, you have figured out your sales pipeline, your marketing pipeline, and all that. And now you really want to make sure that the people you've hired can hit the ground running and do work predictably and deliver the results you want. So that's why it makes sense that these companies that have more employees tend to be the ones that have the need for the software, for what we do.

+ +

CHAD: Who ends up often finding and championing SweetProcess within an organization? Is it typically someone in a leadership position like a CEO?

+ +

OWEN: Great question. So it breaks down based on the size of the company. And now I'm giving you all the juice because my competitors are listening to this now.

+ +

CHAD: [laughs]

+ +

OWEN: But anyway, it is based on the size of the company. It's like if it's between 20 or let's say between 10 to 20-30 employees, most likely it's the CEO who has this pressure that, hey, I need to make sure that employees can go to one single place and find step by step instructions on how to do their work. I need to make sure the onboarding can be done faster. I need to make sure that if anybody leaves this company, we're not scrambling to figure out how work is done. So they start looking for a tool like SweetProcess.

+ +

Now, beyond that, let's say 30 to maybe 100 employees, it's now like the CEO, not the CEO but the Chief Operating Officer, someone who the CEO has hired onboard as the person in charge of operations at the company. Now, once we get beyond that 100 to, let's say, 1,000 employee kind of thing, we're now looking at someone that is a level below the COO, the Chief Operating Officer, and those usually are the operations manager.

+ +

So that's how it works; it's based on the size of the companies. It's either the CEO that's reaching out to us or the Chief Operating Officer or someone who's an operations manager at the larger companies looking to...and especially with the operations manager thing, it's usually they're trying to bring in SweetProcess to start in their department or whatever and then usually to scale-out besides their department to other parts of the company.

+ +

CHAD: How do you reach those people?

+ +

OWEN: So you mentioned something that the fact that the problem we solve cuts across the board, different verticals. It's not industry-specific. So that's a good and bad problem to have. Because if you're only selling to a specific industry, all you got to do is basically be everywhere anyone who is in that industry is at, all the podcasts, all the trades, and everything, just basically be there, and that's it.

+ +

But because the software we sell cuts across different industries, it's kind of harder to do that. So what we decided to do is focus more on creating content around the problem itself so that when people are looking for how to solve their problem, they're able to find us regardless of the industry they are in.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Do you find that there's resistance to the core idea of documenting process?

+ +

OWEN: Oh yes. There's resistance in different levels. Sometimes people think it has to be, you know, robotic, and sometimes they think it has to be complicated. Then it's also "I don't have time to handle the documentation." I hope that I also get to share some cheat codes on how to actually do that on this podcast. I don't want to leave the listeners just hearing about the history of the company but also giving them in case they're in that stage in their company how to go about it.

+ +

CHAD: Well, that's exactly what I was going to ask you about, so yes.

+ +

OWEN: Good, good. So, first of all, if you think about it, you only need to document procedures only at a time when you're trying to document how a task that you do on a repetitive basis, recurring basis. Because if a task is a one-time thing that you're never going to do ever again, well, there's really no need to document it. So we're now left with only recurring tasks. Now, people might just want to get excited and start documenting just because it's based on a recurring task. But I say, no, hold your brakes.

+ +

First of all, let's have this conversation with the employees and managers or whatever and say, "I know we've been doing this over and over again. But is this task necessary?" Because it might just be tribal knowledge thing where we've always done this, so let's keep doing it. No. But if you have that critical conversation and say, "Okay, is this very thing that we've always done, is it necessary or not?" If the answer is not necessary, okay, simply and quickly eliminate it. There's no need to start documenting how that task is done. If it's not necessarily, eliminate it.

+ +

If it's a situation where you already have procedures or processes in place, and they are already existing, and you're trying to come into a software like SweetProcess, even before you start importing those documents, I want you to take a look at those documents and say, "Are these things documenting tasks that are even necessary in the first place?" And if they are not, eliminate them.

+ +

So now, let's say we are at the point where you've eliminated stuff that is not necessary. The recurring task left you have no choice, but you need to do them. Now let's break those two tasks into two categories. The first category is revenue-generating tasks, basically, tasks that bring in money to the company. And the other one is, you know, they're not necessarily revenue-generating, but they're necessary and more of the operation side of things. You need to do them. They don't bring in revenues, per se, but you need to do them to produce whatever stuff that you've promised the customer.

+ +

So people might be excited to want to jump in and start documenting the tasks that bring in revenue. But I say don't do that because if you start that and you document those tasks that bring in revenue, you're also going to be tempted to say, "Okay, let me go find employees or new employees or sales whatever to come and start doing those activities that bring in revenue that I just documented." Now you're going to get more people or more customers coming into the chaos that is already in there because there are a lot of bottlenecks.

+ +

So I say focus on these bottleneck tasks first. Find the biggest bottleneck that takes the most of your time. Start from there first. And then, once you've documented how that task is done, you find the next biggest bottleneck, you document that, and you move to the next one. Before you know, you've eventually documented all the big bottlenecks in your day and the time of your manager and all that stuff. And you guys are now freeing up time to focus on these nice income-generating activities.

+ +

So the next question is okay; I've figured out a big bottleneck task to focus on. How do I document it? Does it have to be an encyclopedia? The answer is no. I want you to do one thing, install that mindset of continuous improvement in your mind, install that mindset of continuous improvement in the mindset of your managers as well as your ground-level employees. Once you have that mindset in place, it basically gives you the permission to say, "Okay, we're going to start from version 1.0 today, which is going to be rudimentary and not have that much in there." But we're telling ourselves since this is continuous improvement, it's going to keep improving as we go.

+ +

So the first thing you do is document what I call a minimum viable procedure, which is just a fancy way of saying a procedure that has the title of the procedure and the title of each of the steps. That's the first thing. And the best time to even do such a thing is while you're doing the task itself because at that point, it's highest and best in your memory so it's easy to just, you know, whether you're using a tool like SweetProcess or using whatever tool, that's the best time to actually document that minimum viable procedure. So title of the procedure, title of each of the steps. And that's it.

+ +

What do you do next? How do you get more details filled in? First of all, I don't want you to think it's only you that will be responsible for filling in the details. It needs to be a collaborative thing. So get your employees involved, anybody who you've trained verbally on the task before on how to do it. It could be a manager or some ground-level employee who you've trained verbally on how to do the task. Say, "Okay, I just documented this procedure. Here are the steps for the procedure. You've already done the task before. Come and collaborate with me to fill out the details."

+ +

So now the employee goes in there and starts step number one, starts entering the details in there. And also, let them know that the details they're going to each step doesn't have to be 100% perfect. It just needs to be enough instructions in there, be it text, be it screenshots, or whatever, that at least someone else can take these details that they've put in there and at least get started. Again, the goal is not to be 100% perfect with the end results of each procedure. At least if someone can take a procedure and get 60% of the way towards the output, that's a good place to be so because, again, we've installed that mindset of continuous improvement.

+ +

Besides collaborating together to fill out the details of the document, how do you then continuously improve the document? This is the cheat code there for this one now is anytime an employee is carrying out a task, you need to make sure that they are also looking at that procedure that you guys have built together because a lot of the insight that comes around improving a document comes when they are actually doing the work; it's not from when they are documenting how the work is done. But when they are doing the work is where the aha and all these things comes to them.

+ +

So let's say a document or a procedure has ten steps. Now the employee is doing the work, and the procedure is right in front of them. They are now able to say, "Okay, why do we need ten steps for this? I just found a better way. We probably just only need four steps." Now they can now take that input; hopefully, it's a proactive employee that we all want; they can take that input and pass it back to you. And that document can be improved based on that feedback.

+ +

Or they might come across some new way that was not even encountered for or discussed in the document, and now that feedback can as well be passed to you so that you can improve that document based on the feedback. But you see how all these things I've talked about, if you don't have the right software in place, it might be a little bit tricky. And that's why when we built SweetProcess, we made sure that it has everything in one place where the documentation side of things and how to collaborate together with the team to document is in one place, as well as the actual aspect of getting work done, which is assigning tasks.

+ +

So, for instance, in SweetProcess, you cannot assign a task to someone that is not based...every task you assign to someone must be based on an underlying procedure you've already documented. So when the employee is actually getting the work done, the instruction is right there in front of them as they are getting the work done in real-time. And if they come across any changes or anything, they can pass that back to you, the manager, who you can make changes on their behalf.

+ +

Or, if they are the proactive employee, they can literally click a button to edit the underlying procedure and make the changes while giving you the management oversight. So all these insights that I've shared about how to do it regardless of whether you use SweetProcess was based on our initial finding when we had all these conversations, and we put it in together and packaged it into our software.

+ +

CHAD: I'm glad that you touch on this idea of continuous improvement, one, because it's one of our core values at thoughtbot is continuous improvement. And I think it's one of the challenges that we have despite it being one of our values. We've been around for 19 years now. We have a very robust internal documentation handbook, procedures, and the way a lot of things are done. And I think it's very easy for someone to show up in that environment and even have all of the best intentions about practicing continuous improvement.

+ +

But when so much is already laid out for you, it can become easy to fall into the trap of saying, "Well, the answer to everything is here, and I don't need to worry about improving it because clearly..." I don't know; it just builds up this culture of like, we've got things figured out. And it's easy to just fall into the mindset I think of just blindly following the things there and not actually looking at them critically while you do it.

+ +

OWEN: Well, I think that is the wrong way to think about stuff because maybe people are thinking, oh, documenting might make the employees robotic, and maybe they don't have a say in what's going on because maybe the instruction has been passed on to them, and that's it. But the way we want people to think about this and the way we built the software is that it needs to be a collaborative thing where it's not just one person that does it.

+ +

So that's why in this software and in our software, we allow even the ground-level employee who has been assigned tasks based on the underlying document they are empowered to literally go in there and click the edit button and make the changes to it, knowing that yes, the manager or the owner of the company still has management oversight to approve the changes.

+ +

But then, even deeper than that, from a cultural standpoint, what other way can you have your voice heard in a company than when you have a tangible role in the actual improvement of how the work is done? Because that's what the procedures are, right? Your document procedures for how work is done. Guess who is doing the work? You. And if you have the ability to, and you are empowered to make changes to the documents that outline how you do your work, that is you literally having your voice heard.

+ +

On top of that, I think documenting procedures allows you to be more creative. So imagine if you're a manager and there's a specific task you do maybe every three months, and you don't have a document for it. Now, at the time it comes when you need to do this task three months from now, you're going to have to start context switching, remembering okay, how do I do this?

+ +

Spending all this time trying to figure out how to do something and then when you figure it out, now you're going to spend time doing it. But imagine if, on the other hand, you had the instructions right there in front of you. You don't have to spend one single minute remembering anything. The instructions are right there in front of you.

+ +

You get started on doing the task; what does that allow you to do? First of all, it allows you to get the task done faster, but then it also frees up your mind to start asking yourself the question like, how can I make this be done better? How can I improve this stuff? How can I get rid of some of these steps? That's where the creativity comes in. And you start thinking of new and better ways to get things done.

+ +

Because remember, documenting procedures is all about, okay, creating steps and instructions for how those tasks that you cannot automate that will be done by human beings are done the right way. But eventually, they get to certain points wherein parts of the task, you can figure out certain things to automate, and you get rid of the manual aspect of human beings doing it. So this is where this whole creativity comes into the whole thing of documenting. That's the way to think about it.

+ +

CHAD: Yeah, that's great. One of the tools, additionally, or techniques that we use a thoughtbot too is there are times where you might have a sense that something isn't quite working right or be improved, or maybe a non-technical person is the one doing the task. And they have a sense that it could be better, but they don't necessarily have the skills to know how to automate it or something like that.

+ +

To have people come together in what we call a retrospective format where you're identifying things that might be better or could be improved. You're talking about them and coming up with action items for improving them. It's is a nice forum that we have for talking about maybe the more vague feeling that someone has that something could be better and then coming up with a way to improve it as a team. Is that something that you do at SweetProcess?

+ +

OWEN: Well, yeah. So we have a bunch of different tasks that we do. And every now and then, we get to a point where we asked ourselves, is there a way we can automate this so that we don't have to do…? I'll give you an example. Every time...before we automated this when someone signs up for SweetProcess, a lot of our customers come through us creating content that addresses these questions all around documenting and how do you scale the operations of your company and so on and so forth. So a lot of people come through our content.

+ +

And as a result of coming through our content, they get into our email automation. We use ActiveCampaign, and they get into our email automation. And before, in the past, before we automated this when someone came in, they get into our email list, and then eventually, they sign up for a trial of our software. And then, we will get this email about it, and we will have to manually go into the tool that we use for our email automation and change their status so that they don't keep getting emails from us as if they were not trial. That became a thing where we were doing too much.

+ +

And we said, you know, "Hey, let's get some engineering on this," and basically got API integration built directly with our software so that when someone signs up for trial, it looks to see is this person already in the email list as someone who's not a trial user? Yes. So let's move them in a different...tag them the right tags and put them in a different category so that now they receive a whole bunch of different emails.

+ +

But the signal for us to decide that we needed to automate that stuff was doing it manually. Although we had step-by-step instructions on how to do it, it was still taking time. And so we said, "Okay, can we automate this?" And so we got to the level where we automated the stuff, and now it's not a thing that we have to even worry about or have someone do. It's just automated.

+ +

CHAD: You have a degree in computer science, right?

+ +

OWEN: Yes.

+ +

CHAD: Do you wonder or…because I sort of have this theory about myself too because I have a degree in computer science as well. But I'm now still doing some development but in operations as well. And sort of this systemized thinking or systems thinking, do you think it comes from our technical backgrounds, your technical background?

+ +

OWEN: I think you can say part of it was enhanced by this, but I've always had this mindset of when I see things like maybe if I go to a company and I see how customer service is happening or how they produce things, I've always been fascinated with how things move around within the different parts of a company to end up with the outcome that I'm trying to achieve.

+ +

Like, people might be having fun watching music videos, but I don't mind sitting down and watching a manufacturing plant like a video showing how they...because I've always been fascinated with how things come together to make the output. And so then you throw in the computer science degree there, and that also enhances that thinking. So I think from my own standpoint, it was just me personally always wanting to know the ingredients that you put together to make something happen. I'm always fascinated by stuff like that. So I'm always thinking systems-wise.

+ +

CHAD: That's great. If folks want to get in touch with you or try out SweetProcess, where are the different places that they can do that?

+ +

OWEN: So obviously, they can go to sweetprocess.com. And you'll be welcome to try out a free 14-day trial of the software. But one of the things I want to leave with you as a gift is I've shared with you how to go about documenting procedures. But you might also want to have templates in front of you so that you're not starting from a blank screen. You have a bunch of…

+ +

What I'm offering is about 52 standard operating procedure templates that you can download right after this interview. You can go to sweetprocess.com/giantrobots, and you'll be able to download it. And that's sweet like candy, process like process, forward slash giant robots just like the name of this podcast or sweetprocess.com/giantrobots. And you'll be able to get a PDF that contains 52 standard operating procedures, and from there, you can tweak it and build upon the templates.

+ +

CHAD: That's awesome. I'll make sure that we link that in the notes, which will be right in people's podcast player too.

+ +

OWEN: Thanks for having me on the call. I really appreciate it.

+ +

CHAD: Yeah, if folks want to get in touch with you, where are the places where they might do that?

+ +

OWEN: owen@sweetprocess.com, very easy.

+ +

CHAD: Awesome. Thank you so much for joining me. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Owen McGab Enaohwo is the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams and employees easily document procedures, implement processes, and manage tasks.

+ +

Chad talks with Owen about taking specific root issues and building software around them, overcoming resistance to the core idea of documenting processes, and the importance of having the freedom and ability to be empowered to make changes to organizational documents that outline how you do your work.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is Owen McGab Enaohwo, the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams as well as employees easily document procedures, implement processes, and manage tasks. Owen, thank you so much for joining me.

+ +

OWEN: Thanks for having me. I really appreciate you inviting me as a guest on here.

+ +

CHAD: I could only return the favor as I recently went on one of the podcasts that you run over at the SweetProcess. I'm happy to have you on the show.

+ +

OWEN: Great, great.

+ +

CHAD: Let's dive in a little bit to SweetProcess. You know, it's a tool for documenting process. And I'm curious what led you to founding SweetProcess and creating this product?

+ +

OWEN: That's a great question. So what happened was SweetProcess was actually founded in, I think, the fourth quarter of 2013. And before then, I had an agency where I would provide entrepreneurs in the U.S., so small to medium-sized business owners, with back-office support, basically, people in the Philippines doing back-office support for them here in the U.S.

+ +

And so people had read these books that were very popular at that time, The 4-Hour Workweek, or the World Is Flat. And then suddenly they realize that being able to hire people abroad and outsource work was not limited to only the larger companies like the telecoms and all that that would go and hire like 150 or more people in these countries working at their phone support 24/7 and all that. So these books exposed small business owners to the idea that even they themselves can do it on a smaller scale and outsource a lot of their work. And so that's what I was doing.

+ +

But the issues that I ran into was that first of all; they were coming to me with this idea that the moment they hire that immediately the person will hit the ground running and start doing the work magically, not realizing that for that to happen, there needs to have been documentation in place. Because first of all, the person you're hiring is in a different country, different culture and all that. There's that that you have going against you.

+ +

But then also, they're not even with you physically where you can say you can teach them by talking to them while they're next to you. So they're in a whole different location. So the more clear your instructions are in terms of having standard operating procedures in front of them, the more easier and quickly they're going to deliver the results you want, and so that was the first thing.

+ +

The second thing was they were very busy wearing so many hats. They didn't have time to document these procedures that we needed to do the work for them. So we came up with this strategy where we would meet with our clients at the time online on Zoom, not Zoom; Zoom wasn't the thing at the time. It was...what was it called? Skype.

+ +

CHAD: Skype.

+ +

OWEN: Yeah. So we would meet with them online, and we'd have recorded sessions with them where they would walk us through what they were doing then record those conversations. And then, someone else on my team would take this conversation and document standard operating procedure step by step from what they told us.

+ +

Now, on the backend, the issue we had was to do this documentation and have tools in place so that people can actually have one place where they could go and find all these documents for our clients. It was either we were using enterprise-level tools that were first of all hard to use for my team talk less of the clients. So these tools were not even built for small to medium-sized businesses. Or we were basically hacking to get a bunch of free tools to achieve that purpose of documentation and having one place where people can go find stuff.

+ +

So in the back of my mind, I was like, man, there has to be a better tool that does this. And so fast forward, I was invited as a guest on to Mixergy. It's another very popular podcast for tech startups. I don't know if you know of him. His name is Andrew Warner. And so, he has two versions of the podcast. The first version is the one where people go in there and talk about the biography of their business or themselves and how they were able to build a tech startup that sold for millions or whatever.

+ +

And then the other version of the podcast was one that was behind a paid subscription where people come on; they're experts, come on there and talk about specific topics like very concrete-sized topics that people are paying him to learn from. So people could come on here to learn about sales, marketing. In my case, I was brought on there to teach the listeners how they can basically document procedures and processes so that you can hand over work and no longer be the bottleneck in their business.

+ +

Lo and behold, my co-founder, Jervis, who is a programmer and now my co-founder and CTO for SweetProcess, listened to that course that I did for Mixergy. He reached out to me and said he has an idea he is working on similar to what I was talking about, the whole way of simplifying documentation. And he just had some questions about this idea he had in his head. And being the kind of person I am, open to conversation, I said, "Okay. Let's go ahead. Let's meet."

+ +

So we had a conversation. And after our conversation, I was like, "Dude; I'm running into the same issue that you're talking about right now because we do this for our customers. We do the documentation for them. But the tools are not the way they should be. Instead of me just giving you ideas on how to do that, and then you go from here, would you be interested if we go ahead and work together and build this software together and build this as a company together?" And he was excited. He was like, "Okay, let's do it."

+ +

And then I said, "Okay, instead of jumping ahead to build the software, one of the things I want to do is avoid a situation where the software ends up being hard to use and feature-bloated like the other software that we are running into right now. Why don't we spend some time having conversations with potential customers to totally understand this problem of documenting procedures and having one place where employees can go to find stuff and how employees can collaborate together to improve stuff?"

+ +

So I wanted to really understand the problem by talking to people. So we spent like about a month or so. I spoke to more than 30 different people running different companies just to get the ideas of the problems they were having with this very specific topic. And we came back, we analyzed all the conversations, and we were able to put down a list of root-specific problems that people were having.

+ +

Because people will suggest features of what they want, but if you drill down and ask them deeper and deeper like, "Why this?" You know, just going into the problem they have and try to get to the root why behind it, then you will end up having a situation where you find a bunch of specific things that are similar between all the different people you spoke to, but they are not saying the same features.

+ +

So we took those specific root issues that we were coming across, and we were able to now go ahead and build our software based on that as opposed to launching a software where at the time with a lot of competitors has not as much features as they had. But we focused on simplicity. We focused on solving the root issues and getting rid of a lot of the complex stuff.

+ +

Like, for instance, some of the software were focused on having some kind of feature and technology sets where it was focused on the business consultant or the expert person on the company who's going to come and document stuff. But we said, "No, the owners of the business don't care about that. It's really more about how does this help them. They don't care about the terminologies and all that." So we got rid of all the bloat and all the stuff and just focused on simplicity based on having these conversations that we had with the people that I spoke of earlier and also based on my own experience using these harder-to-use software.

+ +

CHAD: Well, I really appreciate and commend that because it's a common pitfall. I'm a big believer in building software for yourself that you really understand and a product that you yourself are going to use. But some founders, when faced with that, they'll be like, "Well, I don't need to talk to anybody. I'm the customer. I know everything that is needed. And let's just do what I know we need to do." So to be in a position where you were able to take a step back from that and talk to some other people and make sure you were on the right track, that's really great.

+ +

OWEN: And besides the fact of talking to people to help us streamline and simplify the software, another thing we did was open my eyes to the idea that this problem we're solving basically run across multiple different verticals or industries besides the industry I was in. The industry I was in was basically the outsourcing industry, trying to help people outsource their back-office support.

+ +

But I realized that the problem was even people that actually want to use the software for documenting didn't really care so much about outsourcing work. It was more about employees they have internally being able to do work predictably and at the scale they wanted it, delivering results that they wanted, and hence they needed that documentation. So without having these conversations, you don't get to see these things that you didn't know going in.

+ +

CHAD: Actually, that touches on one of the things I was wondering about, which is the market for your product is essentially every company in the entire world. [laughter] So, with such a huge potential market, are there things you've identified as who your ideal customers are or what kinds of customers come to SweetProcess on their own, what stage they're at, those kinds of things?

+ +

OWEN: Great question. So what we've realized is from the customers who stay 24 months or more with us typically are the much larger companies that have over 20 employees based on the data we have. So what we found is the smaller companies, we encourage them to use SweetProcess because we always want people to start early in the process of documenting procedures.

+ +

But what you realize is that these smaller companies...let me backtrack. So the software solves that problem of having documentation in place and collaborating together to improve these documents over time. And that's really because they are trying to make sure that from a production standpoint of delivering the results to their customers, they have all these instructions. And so their employees can carry out those tasks that they cannot automate. Those tasks that need to be done by human beings, employees can carry it out predictably. Now, that's them trying to deliver output to their customers.

+ +

When a company is less than five employees or even less than ten employees, they don't have so much issues or worries with production. Their main biggest issue is how to get customers, how to get sales in the first place. So their focus initially is more on okay; let me figure out a system for sales. Let me figure out a system for marketing and all that.

+ +

But on the other hand, when you already have 20 or more employees, to a large extent, you have figured out your sales pipeline, your marketing pipeline, and all that. And now you really want to make sure that the people you've hired can hit the ground running and do work predictably and deliver the results you want. So that's why it makes sense that these companies that have more employees tend to be the ones that have the need for the software, for what we do.

+ +

CHAD: Who ends up often finding and championing SweetProcess within an organization? Is it typically someone in a leadership position like a CEO?

+ +

OWEN: Great question. So it breaks down based on the size of the company. And now I'm giving you all the juice because my competitors are listening to this now.

+ +

CHAD: [laughs]

+ +

OWEN: But anyway, it is based on the size of the company. It's like if it's between 20 or let's say between 10 to 20-30 employees, most likely it's the CEO who has this pressure that, hey, I need to make sure that employees can go to one single place and find step by step instructions on how to do their work. I need to make sure the onboarding can be done faster. I need to make sure that if anybody leaves this company, we're not scrambling to figure out how work is done. So they start looking for a tool like SweetProcess.

+ +

Now, beyond that, let's say 30 to maybe 100 employees, it's now like the CEO, not the CEO but the Chief Operating Officer, someone who the CEO has hired onboard as the person in charge of operations at the company. Now, once we get beyond that 100 to, let's say, 1,000 employee kind of thing, we're now looking at someone that is a level below the COO, the Chief Operating Officer, and those usually are the operations manager.

+ +

So that's how it works; it's based on the size of the companies. It's either the CEO that's reaching out to us or the Chief Operating Officer or someone who's an operations manager at the larger companies looking to...and especially with the operations manager thing, it's usually they're trying to bring in SweetProcess to start in their department or whatever and then usually to scale-out besides their department to other parts of the company.

+ +

CHAD: How do you reach those people?

+ +

OWEN: So you mentioned something that the fact that the problem we solve cuts across the board, different verticals. It's not industry-specific. So that's a good and bad problem to have. Because if you're only selling to a specific industry, all you got to do is basically be everywhere anyone who is in that industry is at, all the podcasts, all the trades, and everything, just basically be there, and that's it.

+ +

But because the software we sell cuts across different industries, it's kind of harder to do that. So what we decided to do is focus more on creating content around the problem itself so that when people are looking for how to solve their problem, they're able to find us regardless of the industry they are in.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Do you find that there's resistance to the core idea of documenting process?

+ +

OWEN: Oh yes. There's resistance in different levels. Sometimes people think it has to be, you know, robotic, and sometimes they think it has to be complicated. Then it's also "I don't have time to handle the documentation." I hope that I also get to share some cheat codes on how to actually do that on this podcast. I don't want to leave the listeners just hearing about the history of the company but also giving them in case they're in that stage in their company how to go about it.

+ +

CHAD: Well, that's exactly what I was going to ask you about, so yes.

+ +

OWEN: Good, good. So, first of all, if you think about it, you only need to document procedures only at a time when you're trying to document how a task that you do on a repetitive basis, recurring basis. Because if a task is a one-time thing that you're never going to do ever again, well, there's really no need to document it. So we're now left with only recurring tasks. Now, people might just want to get excited and start documenting just because it's based on a recurring task. But I say, no, hold your brakes.

+ +

First of all, let's have this conversation with the employees and managers or whatever and say, "I know we've been doing this over and over again. But is this task necessary?" Because it might just be tribal knowledge thing where we've always done this, so let's keep doing it. No. But if you have that critical conversation and say, "Okay, is this very thing that we've always done, is it necessary or not?" If the answer is not necessary, okay, simply and quickly eliminate it. There's no need to start documenting how that task is done. If it's not necessarily, eliminate it.

+ +

If it's a situation where you already have procedures or processes in place, and they are already existing, and you're trying to come into a software like SweetProcess, even before you start importing those documents, I want you to take a look at those documents and say, "Are these things documenting tasks that are even necessary in the first place?" And if they are not, eliminate them.

+ +

So now, let's say we are at the point where you've eliminated stuff that is not necessary. The recurring task left you have no choice, but you need to do them. Now let's break those two tasks into two categories. The first category is revenue-generating tasks, basically, tasks that bring in money to the company. And the other one is, you know, they're not necessarily revenue-generating, but they're necessary and more of the operation side of things. You need to do them. They don't bring in revenues, per se, but you need to do them to produce whatever stuff that you've promised the customer.

+ +

So people might be excited to want to jump in and start documenting the tasks that bring in revenue. But I say don't do that because if you start that and you document those tasks that bring in revenue, you're also going to be tempted to say, "Okay, let me go find employees or new employees or sales whatever to come and start doing those activities that bring in revenue that I just documented." Now you're going to get more people or more customers coming into the chaos that is already in there because there are a lot of bottlenecks.

+ +

So I say focus on these bottleneck tasks first. Find the biggest bottleneck that takes the most of your time. Start from there first. And then, once you've documented how that task is done, you find the next biggest bottleneck, you document that, and you move to the next one. Before you know, you've eventually documented all the big bottlenecks in your day and the time of your manager and all that stuff. And you guys are now freeing up time to focus on these nice income-generating activities.

+ +

So the next question is okay; I've figured out a big bottleneck task to focus on. How do I document it? Does it have to be an encyclopedia? The answer is no. I want you to do one thing, install that mindset of continuous improvement in your mind, install that mindset of continuous improvement in the mindset of your managers as well as your ground-level employees. Once you have that mindset in place, it basically gives you the permission to say, "Okay, we're going to start from version 1.0 today, which is going to be rudimentary and not have that much in there." But we're telling ourselves since this is continuous improvement, it's going to keep improving as we go.

+ +

So the first thing you do is document what I call a minimum viable procedure, which is just a fancy way of saying a procedure that has the title of the procedure and the title of each of the steps. That's the first thing. And the best time to even do such a thing is while you're doing the task itself because at that point, it's highest and best in your memory so it's easy to just, you know, whether you're using a tool like SweetProcess or using whatever tool, that's the best time to actually document that minimum viable procedure. So title of the procedure, title of each of the steps. And that's it.

+ +

What do you do next? How do you get more details filled in? First of all, I don't want you to think it's only you that will be responsible for filling in the details. It needs to be a collaborative thing. So get your employees involved, anybody who you've trained verbally on the task before on how to do it. It could be a manager or some ground-level employee who you've trained verbally on how to do the task. Say, "Okay, I just documented this procedure. Here are the steps for the procedure. You've already done the task before. Come and collaborate with me to fill out the details."

+ +

So now the employee goes in there and starts step number one, starts entering the details in there. And also, let them know that the details they're going to each step doesn't have to be 100% perfect. It just needs to be enough instructions in there, be it text, be it screenshots, or whatever, that at least someone else can take these details that they've put in there and at least get started. Again, the goal is not to be 100% perfect with the end results of each procedure. At least if someone can take a procedure and get 60% of the way towards the output, that's a good place to be so because, again, we've installed that mindset of continuous improvement.

+ +

Besides collaborating together to fill out the details of the document, how do you then continuously improve the document? This is the cheat code there for this one now is anytime an employee is carrying out a task, you need to make sure that they are also looking at that procedure that you guys have built together because a lot of the insight that comes around improving a document comes when they are actually doing the work; it's not from when they are documenting how the work is done. But when they are doing the work is where the aha and all these things comes to them.

+ +

So let's say a document or a procedure has ten steps. Now the employee is doing the work, and the procedure is right in front of them. They are now able to say, "Okay, why do we need ten steps for this? I just found a better way. We probably just only need four steps." Now they can now take that input; hopefully, it's a proactive employee that we all want; they can take that input and pass it back to you. And that document can be improved based on that feedback.

+ +

Or they might come across some new way that was not even encountered for or discussed in the document, and now that feedback can as well be passed to you so that you can improve that document based on the feedback. But you see how all these things I've talked about, if you don't have the right software in place, it might be a little bit tricky. And that's why when we built SweetProcess, we made sure that it has everything in one place where the documentation side of things and how to collaborate together with the team to document is in one place, as well as the actual aspect of getting work done, which is assigning tasks.

+ +

So, for instance, in SweetProcess, you cannot assign a task to someone that is not based...every task you assign to someone must be based on an underlying procedure you've already documented. So when the employee is actually getting the work done, the instruction is right there in front of them as they are getting the work done in real-time. And if they come across any changes or anything, they can pass that back to you, the manager, who you can make changes on their behalf.

+ +

Or, if they are the proactive employee, they can literally click a button to edit the underlying procedure and make the changes while giving you the management oversight. So all these insights that I've shared about how to do it regardless of whether you use SweetProcess was based on our initial finding when we had all these conversations, and we put it in together and packaged it into our software.

+ +

CHAD: I'm glad that you touch on this idea of continuous improvement, one, because it's one of our core values at thoughtbot is continuous improvement. And I think it's one of the challenges that we have despite it being one of our values. We've been around for 19 years now. We have a very robust internal documentation handbook, procedures, and the way a lot of things are done. And I think it's very easy for someone to show up in that environment and even have all of the best intentions about practicing continuous improvement.

+ +

But when so much is already laid out for you, it can become easy to fall into the trap of saying, "Well, the answer to everything is here, and I don't need to worry about improving it because clearly..." I don't know; it just builds up this culture of like, we've got things figured out. And it's easy to just fall into the mindset I think of just blindly following the things there and not actually looking at them critically while you do it.

+ +

OWEN: Well, I think that is the wrong way to think about stuff because maybe people are thinking, oh, documenting might make the employees robotic, and maybe they don't have a say in what's going on because maybe the instruction has been passed on to them, and that's it. But the way we want people to think about this and the way we built the software is that it needs to be a collaborative thing where it's not just one person that does it.

+ +

So that's why in this software and in our software, we allow even the ground-level employee who has been assigned tasks based on the underlying document they are empowered to literally go in there and click the edit button and make the changes to it, knowing that yes, the manager or the owner of the company still has management oversight to approve the changes.

+ +

But then, even deeper than that, from a cultural standpoint, what other way can you have your voice heard in a company than when you have a tangible role in the actual improvement of how the work is done? Because that's what the procedures are, right? Your document procedures for how work is done. Guess who is doing the work? You. And if you have the ability to, and you are empowered to make changes to the documents that outline how you do your work, that is you literally having your voice heard.

+ +

On top of that, I think documenting procedures allows you to be more creative. So imagine if you're a manager and there's a specific task you do maybe every three months, and you don't have a document for it. Now, at the time it comes when you need to do this task three months from now, you're going to have to start context switching, remembering okay, how do I do this?

+ +

Spending all this time trying to figure out how to do something and then when you figure it out, now you're going to spend time doing it. But imagine if, on the other hand, you had the instructions right there in front of you. You don't have to spend one single minute remembering anything. The instructions are right there in front of you.

+ +

You get started on doing the task; what does that allow you to do? First of all, it allows you to get the task done faster, but then it also frees up your mind to start asking yourself the question like, how can I make this be done better? How can I improve this stuff? How can I get rid of some of these steps? That's where the creativity comes in. And you start thinking of new and better ways to get things done.

+ +

Because remember, documenting procedures is all about, okay, creating steps and instructions for how those tasks that you cannot automate that will be done by human beings are done the right way. But eventually, they get to certain points wherein parts of the task, you can figure out certain things to automate, and you get rid of the manual aspect of human beings doing it. So this is where this whole creativity comes into the whole thing of documenting. That's the way to think about it.

+ +

CHAD: Yeah, that's great. One of the tools, additionally, or techniques that we use a thoughtbot too is there are times where you might have a sense that something isn't quite working right or be improved, or maybe a non-technical person is the one doing the task. And they have a sense that it could be better, but they don't necessarily have the skills to know how to automate it or something like that.

+ +

To have people come together in what we call a retrospective format where you're identifying things that might be better or could be improved. You're talking about them and coming up with action items for improving them. It's is a nice forum that we have for talking about maybe the more vague feeling that someone has that something could be better and then coming up with a way to improve it as a team. Is that something that you do at SweetProcess?

+ +

OWEN: Well, yeah. So we have a bunch of different tasks that we do. And every now and then, we get to a point where we asked ourselves, is there a way we can automate this so that we don't have to do…? I'll give you an example. Every time...before we automated this when someone signs up for SweetProcess, a lot of our customers come through us creating content that addresses these questions all around documenting and how do you scale the operations of your company and so on and so forth. So a lot of people come through our content.

+ +

And as a result of coming through our content, they get into our email automation. We use ActiveCampaign, and they get into our email automation. And before, in the past, before we automated this when someone came in, they get into our email list, and then eventually, they sign up for a trial of our software. And then, we will get this email about it, and we will have to manually go into the tool that we use for our email automation and change their status so that they don't keep getting emails from us as if they were not trial. That became a thing where we were doing too much.

+ +

And we said, you know, "Hey, let's get some engineering on this," and basically got API integration built directly with our software so that when someone signs up for trial, it looks to see is this person already in the email list as someone who's not a trial user? Yes. So let's move them in a different...tag them the right tags and put them in a different category so that now they receive a whole bunch of different emails.

+ +

But the signal for us to decide that we needed to automate that stuff was doing it manually. Although we had step-by-step instructions on how to do it, it was still taking time. And so we said, "Okay, can we automate this?" And so we got to the level where we automated the stuff, and now it's not a thing that we have to even worry about or have someone do. It's just automated.

+ +

CHAD: You have a degree in computer science, right?

+ +

OWEN: Yes.

+ +

CHAD: Do you wonder or…because I sort of have this theory about myself too because I have a degree in computer science as well. But I'm now still doing some development but in operations as well. And sort of this systemized thinking or systems thinking, do you think it comes from our technical backgrounds, your technical background?

+ +

OWEN: I think you can say part of it was enhanced by this, but I've always had this mindset of when I see things like maybe if I go to a company and I see how customer service is happening or how they produce things, I've always been fascinated with how things move around within the different parts of a company to end up with the outcome that I'm trying to achieve.

+ +

Like, people might be having fun watching music videos, but I don't mind sitting down and watching a manufacturing plant like a video showing how they...because I've always been fascinated with how things come together to make the output. And so then you throw in the computer science degree there, and that also enhances that thinking. So I think from my own standpoint, it was just me personally always wanting to know the ingredients that you put together to make something happen. I'm always fascinated by stuff like that. So I'm always thinking systems-wise.

+ +

CHAD: That's great. If folks want to get in touch with you or try out SweetProcess, where are the different places that they can do that?

+ +

OWEN: So obviously, they can go to sweetprocess.com. And you'll be welcome to try out a free 14-day trial of the software. But one of the things I want to leave with you as a gift is I've shared with you how to go about documenting procedures. But you might also want to have templates in front of you so that you're not starting from a blank screen. You have a bunch of…

+ +

What I'm offering is about 52 standard operating procedure templates that you can download right after this interview. You can go to sweetprocess.com/giantrobots, and you'll be able to download it. And that's sweet like candy, process like process, forward slash giant robots just like the name of this podcast or sweetprocess.com/giantrobots. And you'll be able to get a PDF that contains 52 standard operating procedures, and from there, you can tweak it and build upon the templates.

+ +

CHAD: That's awesome. I'll make sure that we link that in the notes, which will be right in people's podcast player too.

+ +

OWEN: Thanks for having me on the call. I really appreciate it.

+ +

CHAD: Yeah, if folks want to get in touch with you, where are the places where they might do that?

+ +

OWEN: owen@sweetprocess.com, very easy.

+ +

CHAD: Awesome. Thank you so much for joining me. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9KqxyGxu + + ]]> + + Chad Pytel + + + 424: Boulevard with Matt Danna + https://podcast.thoughtbot.com/424 + 71a82b9a-836d-454a-b8a0-4833ff6f83bf + Thu, 26 May 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Matt Danna is the Co-Founder and CEO of Boulevard, which powers next-gen salons and spas. Its mission is to modernize the technology while improving the daily lives of professionals and the clients they serve. + +Chad talks with Matt about discovering a problem and then making the jump to working on it, overcoming hurdles in terms of continued growth, and deciding to invest in building their own hardware by creating Boulevard Duo: a point of sale credit card reader. + 34:25 + no + + + Matt Danna is the Co-Founder and CEO of Boulevard, which powers next-gen salons and spas. Its mission is to modernize the technology while improving the daily lives of professionals and the clients they serve. +Chad talks with Matt about discovering a problem and then making the jump to working on it, overcoming hurdles in terms of continued growth, and deciding to invest in building their own hardware by creating Boulevard Duo: a point of sale credit card reader. +Boulevard (https://www.joinblvd.com/) +Boulevard Duo (https://shop.joinblvd.com/products/duo) +Follow Boulevard on Twitter (https://twitter.com/joinblvd), Facebook (https://www.facebook.com/joinblvd/), Instagram (https://www.instagram.com/joinblvd/), LinkedIn (https://www.linkedin.com/company/boulevard/), or YouTube (https://www.youtube.com/channel/UCo9FyMtvqrDGHFl797iOhww). +Follow Matt on Twitter (https://twitter.com/mattdanna) or LinkedIn (https://www.linkedin.com/in/mattdanna/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Matt Danna, the Co-Founder and CEO of Boulevard, which powers next-gen salons and spas. Matt, thank you so much for joining me. +MATT: Thanks so much for having me, Chad. Great to be here. +CHAD: One of the things that I was interested in learning about Boulevard is it's a large product that does a lot for salons and spas. And so, I'm interested in talking with you about the process of getting to where you are today. But why don't we get started by giving folks an overview of everything that Boulevard does for salons and spas? +MATT: Yeah, absolutely. So Boulevard offers what we think is the first and really only business management platform that's really focused around the client experience. We work with businesses that help all of us look and feel our best. And it's a really special industry to be powering where there's a really close sense of that human touch and that human element. We try to use technology to help automate and relieve the day-to-day operations as much as we can for these businesses so that they can focus on providing that world-class client experience and deepening relationships with their clients. +CHAD: And tactically, that's online booking, scheduling, payments, schedule management, all that kind of stuff that goes into running. +MATT: Yeah, absolutely. So it goes all the way from, like you said, scheduling to we are a fully integrated payments solution to even have time clock kind of commission reporting. And so it really goes from managing everything front of house all the way through back of house. And happy to share more about how we ended up building such a wide and deep product because it's definitely an interesting story. +CHAD: So you were not in the salon industry prior to Boulevard, is that right? +MATT: That's correct. +CHAD: So, how did you end up getting brought into this industry? +MATT: So the founding story...so my background is in software engineering, but I ended up turning much more into a designer over time. So I've been naturally drawn to building technology for creative individuals. And so, at my last startup, which was called Fullscreen, it was a startup here in LA. We were helping YouTube creators make better content online, helping them monetize on YouTube, understand their audience. +And this was in the days where YouTubers couldn't monetize directly. They needed to go through a network. And so, we created this proprietary technology offering that really helped them understand how to build their audience and further monetize. +So the original founding story was that I met my co-founder of Boulevard at Fullscreen. His name is Sean Stavropoulos. And I was the VP of Product. He was the VP of Engineering. And the kind of inception moment was that there was this week where Sean's hair was a complete disaster. +CHAD: [chuckles] +MATT: And as a great colleague, I was making fun of him [laughs] and telling him like, "Dude, you need to go get a haircut." And he said to me that he kept forgetting to call his salon during the day to make an appointment, and at night when he remembered to do those types of things, the salon is obviously closed. +And we were just thinking how much friction there was as a client of these businesses in the booking process and that we didn't understand why you had to do basically so much work in order to be a client. It just was incongruent with what was going on in other industries and kind of restaurants and everything going through this digital transformation. +Our hypothesis was that they must still be on pen and paper; they haven't adopted technology yet, and that's why you need to call to make an appointment. And we started thinking a lot about this problem and started obsessing over it. [laughs] And there was a weekend that we were hanging out, and we ended up walking into a few different salons and spas in a neighborhood that we were hanging out. And we did a bunch of research and asked them a lot of questions. We said we were UCLA students working on a research project. +CHAD: [laughs] +MATT: Which was a pretty smart move because everyone loves talking to students, and we weren't trying to sell them anything. We were trying to learn more. And so, a good research tip is just to state you're always a student. And we ended up learning. And we were super surprised that they were all using technology. All the technology that these businesses were using were also capable of online booking. And so we were like, "Okay, none of this makes sense. Like, you're making your customers call you, but you have these capabilities." +We were like, "Do you need help embedding it into your website? Like, why don't you use online booking" And their answer would be, "We absolutely cannot use online booking, no way," which made us even more curious. And so what we ended up learning was that self-care businesses, you know, salons, spas, nail salons, you name it, they're generally running on pretty thin profit margins like in the 5% to 10% neighborhood because their labor costs are so high relative to their sales. +And the other important piece that we learned was that the front desk has outsized control over the revenue that the business makes simply by how they place appointments on the calendar. And so when you call to make an appointment, they're looking up to see if you have a client file, to see if you've been there before, what services did you get? Who were they with? How long exactly did they take? +They're also looking to see when they could fit you in. And they're doing double booking, triple booking whenever possible so that staff can be with multiple clients at once and double up. And then they're also making sure there are no gaps between appointments. And so they're doing basically this yield optimization, schedule optimization on the fly. And none of that was taken into account if customers self-booked using any of the solutions available on the market. +And so we thought that seems like a straight-up technology problem to solve that these businesses needed an online booking solution so customers can have that convenience and self-booking whenever they want. But it also needs to take into account some of that business logic that the front desk follows so that they don't get gaps in the day and have a really sub-optimal and inefficient calendar. And so that's where we thought we could provide some particular value that would be unique in the industry. And that was what we focused our MVP on, was that very thing, having an intelligent scheduling solution. +CHAD: It seems like it's a pretty big leap for the director of product and director of engineering at a startup to discover a problem like this and then actually make the jump to working on it [laughs] and making it real. Was there something in particular that happened? Why did you do that? [laughs] +MATT: Yeah, I mean, we had a, you know, being executives at the startup and really loving the team, loving what we were doing, our mission. But I think one of the motivators and catalysts was when we were doing this field research. And we ended up going out to a couple of hundred businesses over the course of several weekends to learn even more about this problem area. But one of the things that was so evident and clear was that all of the technology in the market that these customers, these businesses were using, they were negative NPS scores. +They were like, "Oh, we use, you know, X, Y, or Z solution, and we really don't like it. It's so hard to use." You would see the red in their eyes when they would talk about this technology." And we're like, "There's something very powerful here." And we weren't exactly sure at the time was it legacy technology not keeping up with modern needs of these businesses and the growing expectations from end consumers, or was it user error problems? +And we had come to the conclusion that it was really a lack of innovation in the market from existing vendors. And that got us particularly excited, and we formed a lot of conviction, so much conviction that we made the leap to start working on this. So we transitioned out of our full-time executive day jobs, and we ended up doing a little bit of consulting work while we were doing a lot of product discovery. +So for about six months, we were doing three days a week on Boulevard and a couple of days a week on consulting. So it was a nice little part-time way to keep paying the bills but also then be able to spend a significant amount of our brain space thinking about this opportunity and what problems we wanted to solve. +CHAD: So maybe I'm just off base here. And I'm not trying to get you to say that something was wrong at Fullscreen. But it strikes me there needed to be something going on, in my mind, maybe I'm off base, for you to even before deciding to make that leap, though, to spend your weekends going to salons and doing interviews. +MATT: Yeah, I think this is how most companies are started is by founders who are trying to solve a problem that they're exposed to. So everyone is always trying to build companies that are solutions for problems that they have. And we just, I think, got excited by this problem. And my background being in building technology for the creative individuals, like, I got really, really excited. And Sean took some convincing that this was worth it and that this could be a thing. +CHAD: Was it an aspiration for you to find something that you could use to found your own company? +MATT: No, no. +CHAD: And then why were you doing it? [laughs] +MATT: I think it felt like the right thing to do. I never considered myself an entrepreneur, and I really still don't. I think of myself as a builder, and I love building things. And this was in a way for us to think about, like, oh, let's build a company and turn this into a massive business. We saw that there was a particular pain point that was experienced from both consumers and businesses and that we could provide something special. It felt like it was something that only we saw, which I think made it feel even more compelling to work on. +And so we didn't know if we were crazy at first. We always had this question of like, why hasn't anyone figured this out? This seems so obvious. I still don't know why we're the only ones that have any type of kind of logic on top of the schedule in that sense. But we saw it as a unique opportunity to build something really special and provide a lot of value to consumers and businesses. +CHAD: Well, that's super interesting. So once you decided and you started working on Boulevard, how did you decide what to focus on first? And how did you set your market for what the first version was going to be or a target for what the first version was going to be? +MATT: So, we focused on the businesses that had a front desk. So those are generally the ones that really struggled with getting the most out of every minute possible in the day. And so we focused on what were typically mid to upper market single locations to start, and we got introduced to a salon owner through a mutual friend. They were based in New York, and it was just a two-person salon. And so, we built our MVP to be able to support their day-to-day functions. +And they were using some other system, so we kind of had to get to a place where there was general feature parity to support them. So we built up the features that we needed, and then we launched them, transitioned them off their previous solution. And then we did all this in person and then hung out with them for about a week or two after to babysit the system, make sure there weren't problems. We were iterating in real-time. Sean and I were releasing code. And from there, we got an intro to our second customer through another mutual friend. +CHAD: How long did it take you from when you started to when it was live in that first salon? +MATT: It took about nine months. +CHAD: And were you self-funding that based on the consulting that you mentioned? +MATT: Yeah, self-funding. And then, after we launched with the first business, Sean and I actually both liquidated our 401Ks. And we didn't have the time to continue to consult. So we bootstrapped the company and put our life savings into it once we had traction from our first couple of customers. And that's when we started to hire our first employees to help us continue to accelerate development and that kind of thing. +CHAD: So again, liquidating your 401k is a pretty big step. +MATT: Yep. +CHAD: Did you try to do external fundraising before doing that? +MATT: No. At that point, not yet. We wanted to really validate the concept on our own dime. And then, when we had paying customers and a decent customer base, we did a friends and family round. And then, once we achieved a certain milestone, we joined an accelerator, which is based in Los Angeles called Luma Launch. And we were part of that accelerator for about six months. +And then we raised our series seed following that. We went from liquidating our savings, living like college students, ramen noodle budget-type to once we felt good about the value we were providing, had the case studies and the customer feedback, and had a pretty awesome MVP to show to investors; that's when we decided to fundraise. +CHAD: How nervous were the two of you? +MATT: Very nervous. [laughter] I mean, it's one of those both of us come from really, really humble families, and there was no safety net. And so we were all in. And I think often from when there's a lot of constraints; you have to find creativity. We were all in. We were working all the time on this, really gave it everything we had. And in hindsight, it was a good decision. But it could have easily been a terrible decision. [laughs] +CHAD: I mean, this is one of the things with founding stories is we talk to the people who are successful. [laughs] So, would you recommend this path to other people? +MATT: I think if it's something where you could see providing unique value to the world and that you have lots of validation from real people, not just your friends but from prospective customers...it was when we were talking to real businesses where they would say, "This is something we would use and pay for." And so, after hearing that dozens and dozens of times, that matched with the negative NPS scores with their current solutions. +That's where we were like, "This can be something pretty special." So I wouldn't recommend building in isolation and making that leap of faith without really doing your diligence on the opportunity. But yeah, I think everyone, at some point, if they have an idea or a problem they want to solve, should give it a go. +Mid-Roll Ad: +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: That first customer that you were building the replacement for, were you charging them? +MATT: No, we were not. +CHAD: Are they paying now? +MATT: They are, they are, very little. +CHAD: Okay. [chuckles] +MATT: They're a small business and have been staying super successful. And so, in the earliest days, the learnings and feedback matter a lot more than revenue, and so you optimize for that as opposed to the economics. And so for us going and working on location at these businesses and they're paying us essentially in the learnings and teachings of helping us understand and absorb ourselves in this industry, and working as front desk and doing the jobs that all these professionals have to do. And so that's where we were able to build and get to a place where our product is really, really authentic. And it was from that first direct observation. +CHAD: I've worked on products before where they're currently being done by people. They might have technology solutions in place, and they feel like there's no technology that will do this; we need to have a person being the one to do it. Because like you said, there's something special about a person doing it. And so sometimes those businesses, when they have a solution, even if they've properly solved it, there's a lot of resistance from customers who are very skeptical that the technology is going to be able to do it the right way. Have you encountered that? +MATT: Absolutely. +CHAD: How do you combat that? +MATT: We iterated on, essentially, the objections. So the first objection was that "People can't book online because it's going to mess up my day." And so we created this what we call precision scheduling, where it does the optimization on the calendar. +And then the next issue was that we started seeing some no-shows coming because I think there's this mental analog of if you miss an OpenTable reservation not as big of a deal. But in our industry that we're serving, if you miss a two-hour appointment, that professional is out a significant amount of their income for the week. And so that's where we actually started dipping our toes in payments, and we started requiring a credit card at the time of booking just to authorize the card and to hold the appointment. And so that objection of no shows we solved there. +There was a lot of concern of like, "Hey, our customers are not going to know the right thing to book." And we have learned that customers actually are very savvy and that the clients deserve more credit than the professionals are giving them that if a woman gets a balayage, she knows it's a balayage. And so, usually, the way that we overcame that objection was we'd work with them and have best practices on menu design. But that they also then, when they're giving a service that they discuss what they actually did in that service so that the customer knows what to book next time if they want the same thing. +And so that was kind of the pattern is like, build something, learn, iterate, and do it on location with these businesses so that we could see it firsthand in an unbiased way. And so that's really how we were able to build such a product with this amount of scale and overcome some of those initial objections. +CHAD: Is it easier now that you have 2000-plus customers, some social capital out there? They can ask other people, "Is this working for you?" Is that easier now? +MATT: Absolutely. Absolutely. One of the ways...we didn't have a sales team for a long time in our company, and we were actually under the radar. We were stealth, didn't announce anything about ourselves for the first three or four years. And so we were just very much focused on product development and building something that was incredible. And then we were really fed off of referrals and that word of mouth. So it's I think when you get a product that people love, they're going to tell their friends about it. And for us, that really helped accelerate our growth. +CHAD: So yeah, so this was all taking place in what year? +MATT: So we transitioned out of our last company and started doing part-time work in summer of 2015. And then, we officially launched our first customer in spring of 2016. +CHAD: Cool. And I think that that is, you know, you didn't get to 2,000 customers overnight, right? You've been at this for a while. +MATT: Yeah, the barrier to entry is very high in the market, and VCs called our type of opportunity a brownfield opportunity where there are a lot of legacy solutions in the market. And we compete with some companies that were actually started before I was born. +CHAD: [chuckles] +MATT: And so they've had many decades to build functionality into their platform that we need to get to some level of feature parity with in order to seamlessly transition them off of their previous solution to our platform. And it did take a significant upfront investment with product in order to get to be able to pay the price of admission and to be able to actually compete in the market. +CHAD: So one of the things I'm curious about is, do you have a sense of what does the overall market looks like? I feel like there are probably lots of salons, spas, haircutting places. There are a lot of them all over the world. +MATT: There are, yeah. So we believe that there are about 500,000 self-care businesses in the United States. +CHAD: Just in the United States. +MATT: Yeah, just in the United States. And the employee base in the labor market is about two to two and a half million professionals across all those businesses. +CHAD: So, where do you think the hurdles in terms of continued growth are for you? +MATT: So one of the areas that we focus on is...so all of these self-care businesses are about 90% similar in how they operate. And so we started in the hair salon vertical and then have expanded into many adjacent verticals over the course of the past few years. We really tried to make sure that we had really, really strong product-market fit in the hair salons, which is the biggest self-care market, and before we expanded into, say, nail salons. +When expanding into adjacent verticals, there's some functionality that is unique to those verticals. And so, for example, one of our recent verticals that we expanded into is med spas. And the way that med spas charge for their services is generally based on the products that are used, and so if you buy 100 units of Botox, they charge a per-unit fee. And so that was something that was pretty unique to the medspa market that doesn't exist in other self-care markets. +And so vertical expansion is a vector of growth for us and then segment expansion. So we started with the single location, very small businesses. And then we have worked our way up to enterprise where we're powering chains and franchises of hundreds of locations. And then the other aspects kind of the third vector of growth is the different product sets and functionality that we are releasing to our customers. So continuing to develop the platform but also look at different opportunities where we can provide outsized value by developing it ourselves. +CHAD: So we could literally talk all day, and I could talk to you about scaling and product and everything. But one thing I'm interested in before we wrap up is I think it's really special to found a company with a designer, a product person, and an engineer. And I can tell even just by looking at the site and the product that you very highly value design and creating a product that people love to use. +MATT: Absolutely. +CHAD: How does that lead you to creating Duo, which is a point of sale card reader? +MATT: One of the things that we saw in the market was this real importance in service design so what information is showing when to the users of our technology. So there's that aspect of what's the overall experience? Then there's the product design; how easy is it to use? And how quickly can new employees, new front desk staff, how quickly can they get ramped up and start using the system? Do they need two weeks of training? And for us, we try to make it as intuitive and as familiar as possible. +And then we look to see how else can we extend design? And one of the complaints that we always received from customers was that hardware options were always pretty ugly, that all of them look dated like the kind of hardware that you use at a supermarket. And they wanted something that was more sleek and that they weren't ashamed to have on their countertop for checkout. +And so that's where we decided to invest in building our own hardware. And that was particularly exciting for us. So it's been really, really well-received from our customers. And it was a really fun project to work on. Getting into the hardware space is always challenging. But as a designer, it was super cool to build something that became physical for the first time in my life. +CHAD: Does the logic that led to you creating Duo eventually lead you to creating an entire hardware point of sale system? +MATT: We're assessing all opportunities. There's this interesting moment happening in the payments space where like Apple, you know, announced that I think they're piloting now that you won't need hardware in order to accept credit card payments on the iPhone. +CHAD: You'll just be able to do it right against an iPad. +MATT: Exactly. So I think there's a real question as to what is the...and I'm sure this is something that folks like Square are thinking about, that have really best in class hardware is like what does the future of hardware look for fintech companies? And is it just going to fold into the actual devices, or will you continue to need standalone readers? That's something that we're constantly thinking about and keeping smart on the latest developments in that. +But our expertise and what we love is building incredible software. Hardware was that area that we saw that we could provide unique value, but our goal is to always be a software company. You generally don't make much money off of the hardware piece in this business. +CHAD: Now, how personally involved were you in the hardware project? +MATT: I was very involved, potentially too involved. [laughs] +CHAD: As a founder, when new projects come up like this that maybe you're interested in, how do you either hold yourself back or not hold yourself back from being involved in them? +MATT: I think when the company is venturing into new territory, entirely new like uncharted waters, that's when it's valuable for me or any founder to get really, really smart on what's the opportunity, what's the risks, all that kind of stuff. In this case, my experience working at our initial customers for the first couple of years of our business was really, really impactful. +And so our Duo captures...and the reason why it's called Duo is because it's a countertop, but also you can take the top off, and you can do an in chair checkout. So you could bring it over to the customer, and they can check out right while they're in the chair as an express checkout. And so those types of things I learned while being on location working at these businesses. And so I was providing a lot of the guidance and conceptualizing how we could think about what the hardware offering would be that would be unique to us, and collaborated with our head of design and then an industrial designer to get the proof of concept there. +CHAD: And you said, "Potentially too involved," so why did you say that? [laughs] +MATT: I think as a founder, you are always trying to figure out what altitude are you flying at. And there are some things that you will need to dive in and be very hands-on. And then there are other times just to guide and support and coach. And I think for this because it was a new project, I was particularly excited to be able to get into hardware because that was a first for me that I was involved in all aspects of it. But it was a lot of fun. +CHAD: Awesome. Well, Matt, thank you so much for stopping by and sharing with us. I really appreciate it. I'm sure the listeners do too. If folks want to find out more about Boulevard, about joining the team, about becoming a customer, or just to get in touch with you, where are all the different places that they can do that? +MATT: Yeah, absolutely. I think the best place is just on our website. We are hiring across all levels and all functions, especially on the product design and engineering side. And so our website is joinblvd.com, J-O-I-N-B-L-V-D.com. There's the about page, and it links out to my LinkedIn. So if anyone wants to connect and get acquainted, that's probably the easiest way to do it. +CHAD: Awesome. Well, thanks again for joining me. I really appreciate it. +MATT: Yeah, thanks so much. This was a pleasure. +CHAD: You can subscribe to the show and find notes along with links for everything that Matt just mentioned and including a complete transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and I'll see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Matt Danna. + + + Matt Danna is the Co-Founder and CEO of Boulevard, which powers next-gen salons and spas. Its mission is to modernize the technology while improving the daily lives of professionals and the clients they serve.

+ +

Chad talks with Matt about discovering a problem and then making the jump to working on it, overcoming hurdles in terms of continued growth, and deciding to invest in building their own hardware by creating Boulevard Duo: a point of sale credit card reader.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Matt Danna, the Co-Founder and CEO of Boulevard, which powers next-gen salons and spas. Matt, thank you so much for joining me.

+ +

MATT: Thanks so much for having me, Chad. Great to be here.

+ +

CHAD: One of the things that I was interested in learning about Boulevard is it's a large product that does a lot for salons and spas. And so, I'm interested in talking with you about the process of getting to where you are today. But why don't we get started by giving folks an overview of everything that Boulevard does for salons and spas?

+ +

MATT: Yeah, absolutely. So Boulevard offers what we think is the first and really only business management platform that's really focused around the client experience. We work with businesses that help all of us look and feel our best. And it's a really special industry to be powering where there's a really close sense of that human touch and that human element. We try to use technology to help automate and relieve the day-to-day operations as much as we can for these businesses so that they can focus on providing that world-class client experience and deepening relationships with their clients.

+ +

CHAD: And tactically, that's online booking, scheduling, payments, schedule management, all that kind of stuff that goes into running.

+ +

MATT: Yeah, absolutely. So it goes all the way from, like you said, scheduling to we are a fully integrated payments solution to even have time clock kind of commission reporting. And so it really goes from managing everything front of house all the way through back of house. And happy to share more about how we ended up building such a wide and deep product because it's definitely an interesting story.

+ +

CHAD: So you were not in the salon industry prior to Boulevard, is that right?

+ +

MATT: That's correct.

+ +

CHAD: So, how did you end up getting brought into this industry?

+ +

MATT: So the founding story...so my background is in software engineering, but I ended up turning much more into a designer over time. So I've been naturally drawn to building technology for creative individuals. And so, at my last startup, which was called Fullscreen, it was a startup here in LA. We were helping YouTube creators make better content online, helping them monetize on YouTube, understand their audience.

+ +

And this was in the days where YouTubers couldn't monetize directly. They needed to go through a network. And so, we created this proprietary technology offering that really helped them understand how to build their audience and further monetize.

+ +

So the original founding story was that I met my co-founder of Boulevard at Fullscreen. His name is Sean Stavropoulos. And I was the VP of Product. He was the VP of Engineering. And the kind of inception moment was that there was this week where Sean's hair was a complete disaster.

+ +

CHAD: [chuckles]

+ +

MATT: And as a great colleague, I was making fun of him [laughs] and telling him like, "Dude, you need to go get a haircut." And he said to me that he kept forgetting to call his salon during the day to make an appointment, and at night when he remembered to do those types of things, the salon is obviously closed.

+ +

And we were just thinking how much friction there was as a client of these businesses in the booking process and that we didn't understand why you had to do basically so much work in order to be a client. It just was incongruent with what was going on in other industries and kind of restaurants and everything going through this digital transformation.

+ +

Our hypothesis was that they must still be on pen and paper; they haven't adopted technology yet, and that's why you need to call to make an appointment. And we started thinking a lot about this problem and started obsessing over it. [laughs] And there was a weekend that we were hanging out, and we ended up walking into a few different salons and spas in a neighborhood that we were hanging out. And we did a bunch of research and asked them a lot of questions. We said we were UCLA students working on a research project.

+ +

CHAD: [laughs]

+ +

MATT: Which was a pretty smart move because everyone loves talking to students, and we weren't trying to sell them anything. We were trying to learn more. And so, a good research tip is just to state you're always a student. And we ended up learning. And we were super surprised that they were all using technology. All the technology that these businesses were using were also capable of online booking. And so we were like, "Okay, none of this makes sense. Like, you're making your customers call you, but you have these capabilities."

+ +

We were like, "Do you need help embedding it into your website? Like, why don't you use online booking" And their answer would be, "We absolutely cannot use online booking, no way," which made us even more curious. And so what we ended up learning was that self-care businesses, you know, salons, spas, nail salons, you name it, they're generally running on pretty thin profit margins like in the 5% to 10% neighborhood because their labor costs are so high relative to their sales.

+ +

And the other important piece that we learned was that the front desk has outsized control over the revenue that the business makes simply by how they place appointments on the calendar. And so when you call to make an appointment, they're looking up to see if you have a client file, to see if you've been there before, what services did you get? Who were they with? How long exactly did they take?

+ +

They're also looking to see when they could fit you in. And they're doing double booking, triple booking whenever possible so that staff can be with multiple clients at once and double up. And then they're also making sure there are no gaps between appointments. And so they're doing basically this yield optimization, schedule optimization on the fly. And none of that was taken into account if customers self-booked using any of the solutions available on the market.

+ +

And so we thought that seems like a straight-up technology problem to solve that these businesses needed an online booking solution so customers can have that convenience and self-booking whenever they want. But it also needs to take into account some of that business logic that the front desk follows so that they don't get gaps in the day and have a really sub-optimal and inefficient calendar. And so that's where we thought we could provide some particular value that would be unique in the industry. And that was what we focused our MVP on, was that very thing, having an intelligent scheduling solution.

+ +

CHAD: It seems like it's a pretty big leap for the director of product and director of engineering at a startup to discover a problem like this and then actually make the jump to working on it [laughs] and making it real. Was there something in particular that happened? Why did you do that? [laughs]

+ +

MATT: Yeah, I mean, we had a, you know, being executives at the startup and really loving the team, loving what we were doing, our mission. But I think one of the motivators and catalysts was when we were doing this field research. And we ended up going out to a couple of hundred businesses over the course of several weekends to learn even more about this problem area. But one of the things that was so evident and clear was that all of the technology in the market that these customers, these businesses were using, they were negative NPS scores.

+ +

They were like, "Oh, we use, you know, X, Y, or Z solution, and we really don't like it. It's so hard to use." You would see the red in their eyes when they would talk about this technology." And we're like, "There's something very powerful here." And we weren't exactly sure at the time was it legacy technology not keeping up with modern needs of these businesses and the growing expectations from end consumers, or was it user error problems?

+ +

And we had come to the conclusion that it was really a lack of innovation in the market from existing vendors. And that got us particularly excited, and we formed a lot of conviction, so much conviction that we made the leap to start working on this. So we transitioned out of our full-time executive day jobs, and we ended up doing a little bit of consulting work while we were doing a lot of product discovery.

+ +

So for about six months, we were doing three days a week on Boulevard and a couple of days a week on consulting. So it was a nice little part-time way to keep paying the bills but also then be able to spend a significant amount of our brain space thinking about this opportunity and what problems we wanted to solve.

+ +

CHAD: So maybe I'm just off base here. And I'm not trying to get you to say that something was wrong at Fullscreen. But it strikes me there needed to be something going on, in my mind, maybe I'm off base, for you to even before deciding to make that leap, though, to spend your weekends going to salons and doing interviews.

+ +

MATT: Yeah, I think this is how most companies are started is by founders who are trying to solve a problem that they're exposed to. So everyone is always trying to build companies that are solutions for problems that they have. And we just, I think, got excited by this problem. And my background being in building technology for the creative individuals, like, I got really, really excited. And Sean took some convincing that this was worth it and that this could be a thing.

+ +

CHAD: Was it an aspiration for you to find something that you could use to found your own company?

+ +

MATT: No, no.

+ +

CHAD: And then why were you doing it? [laughs]

+ +

MATT: I think it felt like the right thing to do. I never considered myself an entrepreneur, and I really still don't. I think of myself as a builder, and I love building things. And this was in a way for us to think about, like, oh, let's build a company and turn this into a massive business. We saw that there was a particular pain point that was experienced from both consumers and businesses and that we could provide something special. It felt like it was something that only we saw, which I think made it feel even more compelling to work on.

+ +

And so we didn't know if we were crazy at first. We always had this question of like, why hasn't anyone figured this out? This seems so obvious. I still don't know why we're the only ones that have any type of kind of logic on top of the schedule in that sense. But we saw it as a unique opportunity to build something really special and provide a lot of value to consumers and businesses.

+ +

CHAD: Well, that's super interesting. So once you decided and you started working on Boulevard, how did you decide what to focus on first? And how did you set your market for what the first version was going to be or a target for what the first version was going to be?

+ +

MATT: So, we focused on the businesses that had a front desk. So those are generally the ones that really struggled with getting the most out of every minute possible in the day. And so we focused on what were typically mid to upper market single locations to start, and we got introduced to a salon owner through a mutual friend. They were based in New York, and it was just a two-person salon. And so, we built our MVP to be able to support their day-to-day functions.

+ +

And they were using some other system, so we kind of had to get to a place where there was general feature parity to support them. So we built up the features that we needed, and then we launched them, transitioned them off their previous solution. And then we did all this in person and then hung out with them for about a week or two after to babysit the system, make sure there weren't problems. We were iterating in real-time. Sean and I were releasing code. And from there, we got an intro to our second customer through another mutual friend.

+ +

CHAD: How long did it take you from when you started to when it was live in that first salon?

+ +

MATT: It took about nine months.

+ +

CHAD: And were you self-funding that based on the consulting that you mentioned?

+ +

MATT: Yeah, self-funding. And then, after we launched with the first business, Sean and I actually both liquidated our 401Ks. And we didn't have the time to continue to consult. So we bootstrapped the company and put our life savings into it once we had traction from our first couple of customers. And that's when we started to hire our first employees to help us continue to accelerate development and that kind of thing.

+ +

CHAD: So again, liquidating your 401k is a pretty big step.

+ +

MATT: Yep.

+ +

CHAD: Did you try to do external fundraising before doing that?

+ +

MATT: No. At that point, not yet. We wanted to really validate the concept on our own dime. And then, when we had paying customers and a decent customer base, we did a friends and family round. And then, once we achieved a certain milestone, we joined an accelerator, which is based in Los Angeles called Luma Launch. And we were part of that accelerator for about six months.

+ +

And then we raised our series seed following that. We went from liquidating our savings, living like college students, ramen noodle budget-type to once we felt good about the value we were providing, had the case studies and the customer feedback, and had a pretty awesome MVP to show to investors; that's when we decided to fundraise.

+ +

CHAD: How nervous were the two of you?

+ +

MATT: Very nervous. [laughter] I mean, it's one of those both of us come from really, really humble families, and there was no safety net. And so we were all in. And I think often from when there's a lot of constraints; you have to find creativity. We were all in. We were working all the time on this, really gave it everything we had. And in hindsight, it was a good decision. But it could have easily been a terrible decision. [laughs]

+ +

CHAD: I mean, this is one of the things with founding stories is we talk to the people who are successful. [laughs] So, would you recommend this path to other people?

+ +

MATT: I think if it's something where you could see providing unique value to the world and that you have lots of validation from real people, not just your friends but from prospective customers...it was when we were talking to real businesses where they would say, "This is something we would use and pay for." And so, after hearing that dozens and dozens of times, that matched with the negative NPS scores with their current solutions.

+ +

That's where we were like, "This can be something pretty special." So I wouldn't recommend building in isolation and making that leap of faith without really doing your diligence on the opportunity. But yeah, I think everyone, at some point, if they have an idea or a problem they want to solve, should give it a go.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: That first customer that you were building the replacement for, were you charging them?

+ +

MATT: No, we were not.

+ +

CHAD: Are they paying now?

+ +

MATT: They are, they are, very little.

+ +

CHAD: Okay. [chuckles]

+ +

MATT: They're a small business and have been staying super successful. And so, in the earliest days, the learnings and feedback matter a lot more than revenue, and so you optimize for that as opposed to the economics. And so for us going and working on location at these businesses and they're paying us essentially in the learnings and teachings of helping us understand and absorb ourselves in this industry, and working as front desk and doing the jobs that all these professionals have to do. And so that's where we were able to build and get to a place where our product is really, really authentic. And it was from that first direct observation.

+ +

CHAD: I've worked on products before where they're currently being done by people. They might have technology solutions in place, and they feel like there's no technology that will do this; we need to have a person being the one to do it. Because like you said, there's something special about a person doing it. And so sometimes those businesses, when they have a solution, even if they've properly solved it, there's a lot of resistance from customers who are very skeptical that the technology is going to be able to do it the right way. Have you encountered that?

+ +

MATT: Absolutely.

+ +

CHAD: How do you combat that?

+ +

MATT: We iterated on, essentially, the objections. So the first objection was that "People can't book online because it's going to mess up my day." And so we created this what we call precision scheduling, where it does the optimization on the calendar.

+ +

And then the next issue was that we started seeing some no-shows coming because I think there's this mental analog of if you miss an OpenTable reservation not as big of a deal. But in our industry that we're serving, if you miss a two-hour appointment, that professional is out a significant amount of their income for the week. And so that's where we actually started dipping our toes in payments, and we started requiring a credit card at the time of booking just to authorize the card and to hold the appointment. And so that objection of no shows we solved there.

+ +

There was a lot of concern of like, "Hey, our customers are not going to know the right thing to book." And we have learned that customers actually are very savvy and that the clients deserve more credit than the professionals are giving them that if a woman gets a balayage, she knows it's a balayage. And so, usually, the way that we overcame that objection was we'd work with them and have best practices on menu design. But that they also then, when they're giving a service that they discuss what they actually did in that service so that the customer knows what to book next time if they want the same thing.

+ +

And so that was kind of the pattern is like, build something, learn, iterate, and do it on location with these businesses so that we could see it firsthand in an unbiased way. And so that's really how we were able to build such a product with this amount of scale and overcome some of those initial objections.

+ +

CHAD: Is it easier now that you have 2000-plus customers, some social capital out there? They can ask other people, "Is this working for you?" Is that easier now?

+ +

MATT: Absolutely. Absolutely. One of the ways...we didn't have a sales team for a long time in our company, and we were actually under the radar. We were stealth, didn't announce anything about ourselves for the first three or four years. And so we were just very much focused on product development and building something that was incredible. And then we were really fed off of referrals and that word of mouth. So it's I think when you get a product that people love, they're going to tell their friends about it. And for us, that really helped accelerate our growth.

+ +

CHAD: So yeah, so this was all taking place in what year?

+ +

MATT: So we transitioned out of our last company and started doing part-time work in summer of 2015. And then, we officially launched our first customer in spring of 2016.

+ +

CHAD: Cool. And I think that that is, you know, you didn't get to 2,000 customers overnight, right? You've been at this for a while.

+ +

MATT: Yeah, the barrier to entry is very high in the market, and VCs called our type of opportunity a brownfield opportunity where there are a lot of legacy solutions in the market. And we compete with some companies that were actually started before I was born.

+ +

CHAD: [chuckles]

+ +

MATT: And so they've had many decades to build functionality into their platform that we need to get to some level of feature parity with in order to seamlessly transition them off of their previous solution to our platform. And it did take a significant upfront investment with product in order to get to be able to pay the price of admission and to be able to actually compete in the market.

+ +

CHAD: So one of the things I'm curious about is, do you have a sense of what does the overall market looks like? I feel like there are probably lots of salons, spas, haircutting places. There are a lot of them all over the world.

+ +

MATT: There are, yeah. So we believe that there are about 500,000 self-care businesses in the United States.

+ +

CHAD: Just in the United States.

+ +

MATT: Yeah, just in the United States. And the employee base in the labor market is about two to two and a half million professionals across all those businesses.

+ +

CHAD: So, where do you think the hurdles in terms of continued growth are for you?

+ +

MATT: So one of the areas that we focus on is...so all of these self-care businesses are about 90% similar in how they operate. And so we started in the hair salon vertical and then have expanded into many adjacent verticals over the course of the past few years. We really tried to make sure that we had really, really strong product-market fit in the hair salons, which is the biggest self-care market, and before we expanded into, say, nail salons.

+ +

When expanding into adjacent verticals, there's some functionality that is unique to those verticals. And so, for example, one of our recent verticals that we expanded into is med spas. And the way that med spas charge for their services is generally based on the products that are used, and so if you buy 100 units of Botox, they charge a per-unit fee. And so that was something that was pretty unique to the medspa market that doesn't exist in other self-care markets.

+ +

And so vertical expansion is a vector of growth for us and then segment expansion. So we started with the single location, very small businesses. And then we have worked our way up to enterprise where we're powering chains and franchises of hundreds of locations. And then the other aspects kind of the third vector of growth is the different product sets and functionality that we are releasing to our customers. So continuing to develop the platform but also look at different opportunities where we can provide outsized value by developing it ourselves.

+ +

CHAD: So we could literally talk all day, and I could talk to you about scaling and product and everything. But one thing I'm interested in before we wrap up is I think it's really special to found a company with a designer, a product person, and an engineer. And I can tell even just by looking at the site and the product that you very highly value design and creating a product that people love to use.

+ +

MATT: Absolutely.

+ +

CHAD: How does that lead you to creating Duo, which is a point of sale card reader?

+ +

MATT: One of the things that we saw in the market was this real importance in service design so what information is showing when to the users of our technology. So there's that aspect of what's the overall experience? Then there's the product design; how easy is it to use? And how quickly can new employees, new front desk staff, how quickly can they get ramped up and start using the system? Do they need two weeks of training? And for us, we try to make it as intuitive and as familiar as possible.

+ +

And then we look to see how else can we extend design? And one of the complaints that we always received from customers was that hardware options were always pretty ugly, that all of them look dated like the kind of hardware that you use at a supermarket. And they wanted something that was more sleek and that they weren't ashamed to have on their countertop for checkout.

+ +

And so that's where we decided to invest in building our own hardware. And that was particularly exciting for us. So it's been really, really well-received from our customers. And it was a really fun project to work on. Getting into the hardware space is always challenging. But as a designer, it was super cool to build something that became physical for the first time in my life.

+ +

CHAD: Does the logic that led to you creating Duo eventually lead you to creating an entire hardware point of sale system?

+ +

MATT: We're assessing all opportunities. There's this interesting moment happening in the payments space where like Apple, you know, announced that I think they're piloting now that you won't need hardware in order to accept credit card payments on the iPhone.

+ +

CHAD: You'll just be able to do it right against an iPad.

+ +

MATT: Exactly. So I think there's a real question as to what is the...and I'm sure this is something that folks like Square are thinking about, that have really best in class hardware is like what does the future of hardware look for fintech companies? And is it just going to fold into the actual devices, or will you continue to need standalone readers? That's something that we're constantly thinking about and keeping smart on the latest developments in that.

+ +

But our expertise and what we love is building incredible software. Hardware was that area that we saw that we could provide unique value, but our goal is to always be a software company. You generally don't make much money off of the hardware piece in this business.

+ +

CHAD: Now, how personally involved were you in the hardware project?

+ +

MATT: I was very involved, potentially too involved. [laughs]

+ +

CHAD: As a founder, when new projects come up like this that maybe you're interested in, how do you either hold yourself back or not hold yourself back from being involved in them?

+ +

MATT: I think when the company is venturing into new territory, entirely new like uncharted waters, that's when it's valuable for me or any founder to get really, really smart on what's the opportunity, what's the risks, all that kind of stuff. In this case, my experience working at our initial customers for the first couple of years of our business was really, really impactful.

+ +

And so our Duo captures...and the reason why it's called Duo is because it's a countertop, but also you can take the top off, and you can do an in chair checkout. So you could bring it over to the customer, and they can check out right while they're in the chair as an express checkout. And so those types of things I learned while being on location working at these businesses. And so I was providing a lot of the guidance and conceptualizing how we could think about what the hardware offering would be that would be unique to us, and collaborated with our head of design and then an industrial designer to get the proof of concept there.

+ +

CHAD: And you said, "Potentially too involved," so why did you say that? [laughs]

+ +

MATT: I think as a founder, you are always trying to figure out what altitude are you flying at. And there are some things that you will need to dive in and be very hands-on. And then there are other times just to guide and support and coach. And I think for this because it was a new project, I was particularly excited to be able to get into hardware because that was a first for me that I was involved in all aspects of it. But it was a lot of fun.

+ +

CHAD: Awesome. Well, Matt, thank you so much for stopping by and sharing with us. I really appreciate it. I'm sure the listeners do too. If folks want to find out more about Boulevard, about joining the team, about becoming a customer, or just to get in touch with you, where are all the different places that they can do that?

+ +

MATT: Yeah, absolutely. I think the best place is just on our website. We are hiring across all levels and all functions, especially on the product design and engineering side. And so our website is joinblvd.com, J-O-I-N-B-L-V-D.com. There's the about page, and it links out to my LinkedIn. So if anyone wants to connect and get acquainted, that's probably the easiest way to do it.

+ +

CHAD: Awesome. Well, thanks again for joining me. I really appreciate it.

+ +

MATT: Yeah, thanks so much. This was a pleasure.

+ +

CHAD: You can subscribe to the show and find notes along with links for everything that Matt just mentioned and including a complete transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and I'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Matt Danna.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Matt Danna is the Co-Founder and CEO of Boulevard, which powers next-gen salons and spas. Its mission is to modernize the technology while improving the daily lives of professionals and the clients they serve.

+ +

Chad talks with Matt about discovering a problem and then making the jump to working on it, overcoming hurdles in terms of continued growth, and deciding to invest in building their own hardware by creating Boulevard Duo: a point of sale credit card reader.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Matt Danna, the Co-Founder and CEO of Boulevard, which powers next-gen salons and spas. Matt, thank you so much for joining me.

+ +

MATT: Thanks so much for having me, Chad. Great to be here.

+ +

CHAD: One of the things that I was interested in learning about Boulevard is it's a large product that does a lot for salons and spas. And so, I'm interested in talking with you about the process of getting to where you are today. But why don't we get started by giving folks an overview of everything that Boulevard does for salons and spas?

+ +

MATT: Yeah, absolutely. So Boulevard offers what we think is the first and really only business management platform that's really focused around the client experience. We work with businesses that help all of us look and feel our best. And it's a really special industry to be powering where there's a really close sense of that human touch and that human element. We try to use technology to help automate and relieve the day-to-day operations as much as we can for these businesses so that they can focus on providing that world-class client experience and deepening relationships with their clients.

+ +

CHAD: And tactically, that's online booking, scheduling, payments, schedule management, all that kind of stuff that goes into running.

+ +

MATT: Yeah, absolutely. So it goes all the way from, like you said, scheduling to we are a fully integrated payments solution to even have time clock kind of commission reporting. And so it really goes from managing everything front of house all the way through back of house. And happy to share more about how we ended up building such a wide and deep product because it's definitely an interesting story.

+ +

CHAD: So you were not in the salon industry prior to Boulevard, is that right?

+ +

MATT: That's correct.

+ +

CHAD: So, how did you end up getting brought into this industry?

+ +

MATT: So the founding story...so my background is in software engineering, but I ended up turning much more into a designer over time. So I've been naturally drawn to building technology for creative individuals. And so, at my last startup, which was called Fullscreen, it was a startup here in LA. We were helping YouTube creators make better content online, helping them monetize on YouTube, understand their audience.

+ +

And this was in the days where YouTubers couldn't monetize directly. They needed to go through a network. And so, we created this proprietary technology offering that really helped them understand how to build their audience and further monetize.

+ +

So the original founding story was that I met my co-founder of Boulevard at Fullscreen. His name is Sean Stavropoulos. And I was the VP of Product. He was the VP of Engineering. And the kind of inception moment was that there was this week where Sean's hair was a complete disaster.

+ +

CHAD: [chuckles]

+ +

MATT: And as a great colleague, I was making fun of him [laughs] and telling him like, "Dude, you need to go get a haircut." And he said to me that he kept forgetting to call his salon during the day to make an appointment, and at night when he remembered to do those types of things, the salon is obviously closed.

+ +

And we were just thinking how much friction there was as a client of these businesses in the booking process and that we didn't understand why you had to do basically so much work in order to be a client. It just was incongruent with what was going on in other industries and kind of restaurants and everything going through this digital transformation.

+ +

Our hypothesis was that they must still be on pen and paper; they haven't adopted technology yet, and that's why you need to call to make an appointment. And we started thinking a lot about this problem and started obsessing over it. [laughs] And there was a weekend that we were hanging out, and we ended up walking into a few different salons and spas in a neighborhood that we were hanging out. And we did a bunch of research and asked them a lot of questions. We said we were UCLA students working on a research project.

+ +

CHAD: [laughs]

+ +

MATT: Which was a pretty smart move because everyone loves talking to students, and we weren't trying to sell them anything. We were trying to learn more. And so, a good research tip is just to state you're always a student. And we ended up learning. And we were super surprised that they were all using technology. All the technology that these businesses were using were also capable of online booking. And so we were like, "Okay, none of this makes sense. Like, you're making your customers call you, but you have these capabilities."

+ +

We were like, "Do you need help embedding it into your website? Like, why don't you use online booking" And their answer would be, "We absolutely cannot use online booking, no way," which made us even more curious. And so what we ended up learning was that self-care businesses, you know, salons, spas, nail salons, you name it, they're generally running on pretty thin profit margins like in the 5% to 10% neighborhood because their labor costs are so high relative to their sales.

+ +

And the other important piece that we learned was that the front desk has outsized control over the revenue that the business makes simply by how they place appointments on the calendar. And so when you call to make an appointment, they're looking up to see if you have a client file, to see if you've been there before, what services did you get? Who were they with? How long exactly did they take?

+ +

They're also looking to see when they could fit you in. And they're doing double booking, triple booking whenever possible so that staff can be with multiple clients at once and double up. And then they're also making sure there are no gaps between appointments. And so they're doing basically this yield optimization, schedule optimization on the fly. And none of that was taken into account if customers self-booked using any of the solutions available on the market.

+ +

And so we thought that seems like a straight-up technology problem to solve that these businesses needed an online booking solution so customers can have that convenience and self-booking whenever they want. But it also needs to take into account some of that business logic that the front desk follows so that they don't get gaps in the day and have a really sub-optimal and inefficient calendar. And so that's where we thought we could provide some particular value that would be unique in the industry. And that was what we focused our MVP on, was that very thing, having an intelligent scheduling solution.

+ +

CHAD: It seems like it's a pretty big leap for the director of product and director of engineering at a startup to discover a problem like this and then actually make the jump to working on it [laughs] and making it real. Was there something in particular that happened? Why did you do that? [laughs]

+ +

MATT: Yeah, I mean, we had a, you know, being executives at the startup and really loving the team, loving what we were doing, our mission. But I think one of the motivators and catalysts was when we were doing this field research. And we ended up going out to a couple of hundred businesses over the course of several weekends to learn even more about this problem area. But one of the things that was so evident and clear was that all of the technology in the market that these customers, these businesses were using, they were negative NPS scores.

+ +

They were like, "Oh, we use, you know, X, Y, or Z solution, and we really don't like it. It's so hard to use." You would see the red in their eyes when they would talk about this technology." And we're like, "There's something very powerful here." And we weren't exactly sure at the time was it legacy technology not keeping up with modern needs of these businesses and the growing expectations from end consumers, or was it user error problems?

+ +

And we had come to the conclusion that it was really a lack of innovation in the market from existing vendors. And that got us particularly excited, and we formed a lot of conviction, so much conviction that we made the leap to start working on this. So we transitioned out of our full-time executive day jobs, and we ended up doing a little bit of consulting work while we were doing a lot of product discovery.

+ +

So for about six months, we were doing three days a week on Boulevard and a couple of days a week on consulting. So it was a nice little part-time way to keep paying the bills but also then be able to spend a significant amount of our brain space thinking about this opportunity and what problems we wanted to solve.

+ +

CHAD: So maybe I'm just off base here. And I'm not trying to get you to say that something was wrong at Fullscreen. But it strikes me there needed to be something going on, in my mind, maybe I'm off base, for you to even before deciding to make that leap, though, to spend your weekends going to salons and doing interviews.

+ +

MATT: Yeah, I think this is how most companies are started is by founders who are trying to solve a problem that they're exposed to. So everyone is always trying to build companies that are solutions for problems that they have. And we just, I think, got excited by this problem. And my background being in building technology for the creative individuals, like, I got really, really excited. And Sean took some convincing that this was worth it and that this could be a thing.

+ +

CHAD: Was it an aspiration for you to find something that you could use to found your own company?

+ +

MATT: No, no.

+ +

CHAD: And then why were you doing it? [laughs]

+ +

MATT: I think it felt like the right thing to do. I never considered myself an entrepreneur, and I really still don't. I think of myself as a builder, and I love building things. And this was in a way for us to think about, like, oh, let's build a company and turn this into a massive business. We saw that there was a particular pain point that was experienced from both consumers and businesses and that we could provide something special. It felt like it was something that only we saw, which I think made it feel even more compelling to work on.

+ +

And so we didn't know if we were crazy at first. We always had this question of like, why hasn't anyone figured this out? This seems so obvious. I still don't know why we're the only ones that have any type of kind of logic on top of the schedule in that sense. But we saw it as a unique opportunity to build something really special and provide a lot of value to consumers and businesses.

+ +

CHAD: Well, that's super interesting. So once you decided and you started working on Boulevard, how did you decide what to focus on first? And how did you set your market for what the first version was going to be or a target for what the first version was going to be?

+ +

MATT: So, we focused on the businesses that had a front desk. So those are generally the ones that really struggled with getting the most out of every minute possible in the day. And so we focused on what were typically mid to upper market single locations to start, and we got introduced to a salon owner through a mutual friend. They were based in New York, and it was just a two-person salon. And so, we built our MVP to be able to support their day-to-day functions.

+ +

And they were using some other system, so we kind of had to get to a place where there was general feature parity to support them. So we built up the features that we needed, and then we launched them, transitioned them off their previous solution. And then we did all this in person and then hung out with them for about a week or two after to babysit the system, make sure there weren't problems. We were iterating in real-time. Sean and I were releasing code. And from there, we got an intro to our second customer through another mutual friend.

+ +

CHAD: How long did it take you from when you started to when it was live in that first salon?

+ +

MATT: It took about nine months.

+ +

CHAD: And were you self-funding that based on the consulting that you mentioned?

+ +

MATT: Yeah, self-funding. And then, after we launched with the first business, Sean and I actually both liquidated our 401Ks. And we didn't have the time to continue to consult. So we bootstrapped the company and put our life savings into it once we had traction from our first couple of customers. And that's when we started to hire our first employees to help us continue to accelerate development and that kind of thing.

+ +

CHAD: So again, liquidating your 401k is a pretty big step.

+ +

MATT: Yep.

+ +

CHAD: Did you try to do external fundraising before doing that?

+ +

MATT: No. At that point, not yet. We wanted to really validate the concept on our own dime. And then, when we had paying customers and a decent customer base, we did a friends and family round. And then, once we achieved a certain milestone, we joined an accelerator, which is based in Los Angeles called Luma Launch. And we were part of that accelerator for about six months.

+ +

And then we raised our series seed following that. We went from liquidating our savings, living like college students, ramen noodle budget-type to once we felt good about the value we were providing, had the case studies and the customer feedback, and had a pretty awesome MVP to show to investors; that's when we decided to fundraise.

+ +

CHAD: How nervous were the two of you?

+ +

MATT: Very nervous. [laughter] I mean, it's one of those both of us come from really, really humble families, and there was no safety net. And so we were all in. And I think often from when there's a lot of constraints; you have to find creativity. We were all in. We were working all the time on this, really gave it everything we had. And in hindsight, it was a good decision. But it could have easily been a terrible decision. [laughs]

+ +

CHAD: I mean, this is one of the things with founding stories is we talk to the people who are successful. [laughs] So, would you recommend this path to other people?

+ +

MATT: I think if it's something where you could see providing unique value to the world and that you have lots of validation from real people, not just your friends but from prospective customers...it was when we were talking to real businesses where they would say, "This is something we would use and pay for." And so, after hearing that dozens and dozens of times, that matched with the negative NPS scores with their current solutions.

+ +

That's where we were like, "This can be something pretty special." So I wouldn't recommend building in isolation and making that leap of faith without really doing your diligence on the opportunity. But yeah, I think everyone, at some point, if they have an idea or a problem they want to solve, should give it a go.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: That first customer that you were building the replacement for, were you charging them?

+ +

MATT: No, we were not.

+ +

CHAD: Are they paying now?

+ +

MATT: They are, they are, very little.

+ +

CHAD: Okay. [chuckles]

+ +

MATT: They're a small business and have been staying super successful. And so, in the earliest days, the learnings and feedback matter a lot more than revenue, and so you optimize for that as opposed to the economics. And so for us going and working on location at these businesses and they're paying us essentially in the learnings and teachings of helping us understand and absorb ourselves in this industry, and working as front desk and doing the jobs that all these professionals have to do. And so that's where we were able to build and get to a place where our product is really, really authentic. And it was from that first direct observation.

+ +

CHAD: I've worked on products before where they're currently being done by people. They might have technology solutions in place, and they feel like there's no technology that will do this; we need to have a person being the one to do it. Because like you said, there's something special about a person doing it. And so sometimes those businesses, when they have a solution, even if they've properly solved it, there's a lot of resistance from customers who are very skeptical that the technology is going to be able to do it the right way. Have you encountered that?

+ +

MATT: Absolutely.

+ +

CHAD: How do you combat that?

+ +

MATT: We iterated on, essentially, the objections. So the first objection was that "People can't book online because it's going to mess up my day." And so we created this what we call precision scheduling, where it does the optimization on the calendar.

+ +

And then the next issue was that we started seeing some no-shows coming because I think there's this mental analog of if you miss an OpenTable reservation not as big of a deal. But in our industry that we're serving, if you miss a two-hour appointment, that professional is out a significant amount of their income for the week. And so that's where we actually started dipping our toes in payments, and we started requiring a credit card at the time of booking just to authorize the card and to hold the appointment. And so that objection of no shows we solved there.

+ +

There was a lot of concern of like, "Hey, our customers are not going to know the right thing to book." And we have learned that customers actually are very savvy and that the clients deserve more credit than the professionals are giving them that if a woman gets a balayage, she knows it's a balayage. And so, usually, the way that we overcame that objection was we'd work with them and have best practices on menu design. But that they also then, when they're giving a service that they discuss what they actually did in that service so that the customer knows what to book next time if they want the same thing.

+ +

And so that was kind of the pattern is like, build something, learn, iterate, and do it on location with these businesses so that we could see it firsthand in an unbiased way. And so that's really how we were able to build such a product with this amount of scale and overcome some of those initial objections.

+ +

CHAD: Is it easier now that you have 2000-plus customers, some social capital out there? They can ask other people, "Is this working for you?" Is that easier now?

+ +

MATT: Absolutely. Absolutely. One of the ways...we didn't have a sales team for a long time in our company, and we were actually under the radar. We were stealth, didn't announce anything about ourselves for the first three or four years. And so we were just very much focused on product development and building something that was incredible. And then we were really fed off of referrals and that word of mouth. So it's I think when you get a product that people love, they're going to tell their friends about it. And for us, that really helped accelerate our growth.

+ +

CHAD: So yeah, so this was all taking place in what year?

+ +

MATT: So we transitioned out of our last company and started doing part-time work in summer of 2015. And then, we officially launched our first customer in spring of 2016.

+ +

CHAD: Cool. And I think that that is, you know, you didn't get to 2,000 customers overnight, right? You've been at this for a while.

+ +

MATT: Yeah, the barrier to entry is very high in the market, and VCs called our type of opportunity a brownfield opportunity where there are a lot of legacy solutions in the market. And we compete with some companies that were actually started before I was born.

+ +

CHAD: [chuckles]

+ +

MATT: And so they've had many decades to build functionality into their platform that we need to get to some level of feature parity with in order to seamlessly transition them off of their previous solution to our platform. And it did take a significant upfront investment with product in order to get to be able to pay the price of admission and to be able to actually compete in the market.

+ +

CHAD: So one of the things I'm curious about is, do you have a sense of what does the overall market looks like? I feel like there are probably lots of salons, spas, haircutting places. There are a lot of them all over the world.

+ +

MATT: There are, yeah. So we believe that there are about 500,000 self-care businesses in the United States.

+ +

CHAD: Just in the United States.

+ +

MATT: Yeah, just in the United States. And the employee base in the labor market is about two to two and a half million professionals across all those businesses.

+ +

CHAD: So, where do you think the hurdles in terms of continued growth are for you?

+ +

MATT: So one of the areas that we focus on is...so all of these self-care businesses are about 90% similar in how they operate. And so we started in the hair salon vertical and then have expanded into many adjacent verticals over the course of the past few years. We really tried to make sure that we had really, really strong product-market fit in the hair salons, which is the biggest self-care market, and before we expanded into, say, nail salons.

+ +

When expanding into adjacent verticals, there's some functionality that is unique to those verticals. And so, for example, one of our recent verticals that we expanded into is med spas. And the way that med spas charge for their services is generally based on the products that are used, and so if you buy 100 units of Botox, they charge a per-unit fee. And so that was something that was pretty unique to the medspa market that doesn't exist in other self-care markets.

+ +

And so vertical expansion is a vector of growth for us and then segment expansion. So we started with the single location, very small businesses. And then we have worked our way up to enterprise where we're powering chains and franchises of hundreds of locations. And then the other aspects kind of the third vector of growth is the different product sets and functionality that we are releasing to our customers. So continuing to develop the platform but also look at different opportunities where we can provide outsized value by developing it ourselves.

+ +

CHAD: So we could literally talk all day, and I could talk to you about scaling and product and everything. But one thing I'm interested in before we wrap up is I think it's really special to found a company with a designer, a product person, and an engineer. And I can tell even just by looking at the site and the product that you very highly value design and creating a product that people love to use.

+ +

MATT: Absolutely.

+ +

CHAD: How does that lead you to creating Duo, which is a point of sale card reader?

+ +

MATT: One of the things that we saw in the market was this real importance in service design so what information is showing when to the users of our technology. So there's that aspect of what's the overall experience? Then there's the product design; how easy is it to use? And how quickly can new employees, new front desk staff, how quickly can they get ramped up and start using the system? Do they need two weeks of training? And for us, we try to make it as intuitive and as familiar as possible.

+ +

And then we look to see how else can we extend design? And one of the complaints that we always received from customers was that hardware options were always pretty ugly, that all of them look dated like the kind of hardware that you use at a supermarket. And they wanted something that was more sleek and that they weren't ashamed to have on their countertop for checkout.

+ +

And so that's where we decided to invest in building our own hardware. And that was particularly exciting for us. So it's been really, really well-received from our customers. And it was a really fun project to work on. Getting into the hardware space is always challenging. But as a designer, it was super cool to build something that became physical for the first time in my life.

+ +

CHAD: Does the logic that led to you creating Duo eventually lead you to creating an entire hardware point of sale system?

+ +

MATT: We're assessing all opportunities. There's this interesting moment happening in the payments space where like Apple, you know, announced that I think they're piloting now that you won't need hardware in order to accept credit card payments on the iPhone.

+ +

CHAD: You'll just be able to do it right against an iPad.

+ +

MATT: Exactly. So I think there's a real question as to what is the...and I'm sure this is something that folks like Square are thinking about, that have really best in class hardware is like what does the future of hardware look for fintech companies? And is it just going to fold into the actual devices, or will you continue to need standalone readers? That's something that we're constantly thinking about and keeping smart on the latest developments in that.

+ +

But our expertise and what we love is building incredible software. Hardware was that area that we saw that we could provide unique value, but our goal is to always be a software company. You generally don't make much money off of the hardware piece in this business.

+ +

CHAD: Now, how personally involved were you in the hardware project?

+ +

MATT: I was very involved, potentially too involved. [laughs]

+ +

CHAD: As a founder, when new projects come up like this that maybe you're interested in, how do you either hold yourself back or not hold yourself back from being involved in them?

+ +

MATT: I think when the company is venturing into new territory, entirely new like uncharted waters, that's when it's valuable for me or any founder to get really, really smart on what's the opportunity, what's the risks, all that kind of stuff. In this case, my experience working at our initial customers for the first couple of years of our business was really, really impactful.

+ +

And so our Duo captures...and the reason why it's called Duo is because it's a countertop, but also you can take the top off, and you can do an in chair checkout. So you could bring it over to the customer, and they can check out right while they're in the chair as an express checkout. And so those types of things I learned while being on location working at these businesses. And so I was providing a lot of the guidance and conceptualizing how we could think about what the hardware offering would be that would be unique to us, and collaborated with our head of design and then an industrial designer to get the proof of concept there.

+ +

CHAD: And you said, "Potentially too involved," so why did you say that? [laughs]

+ +

MATT: I think as a founder, you are always trying to figure out what altitude are you flying at. And there are some things that you will need to dive in and be very hands-on. And then there are other times just to guide and support and coach. And I think for this because it was a new project, I was particularly excited to be able to get into hardware because that was a first for me that I was involved in all aspects of it. But it was a lot of fun.

+ +

CHAD: Awesome. Well, Matt, thank you so much for stopping by and sharing with us. I really appreciate it. I'm sure the listeners do too. If folks want to find out more about Boulevard, about joining the team, about becoming a customer, or just to get in touch with you, where are all the different places that they can do that?

+ +

MATT: Yeah, absolutely. I think the best place is just on our website. We are hiring across all levels and all functions, especially on the product design and engineering side. And so our website is joinblvd.com, J-O-I-N-B-L-V-D.com. There's the about page, and it links out to my LinkedIn. So if anyone wants to connect and get acquainted, that's probably the easiest way to do it.

+ +

CHAD: Awesome. Well, thanks again for joining me. I really appreciate it.

+ +

MATT: Yeah, thanks so much. This was a pleasure.

+ +

CHAD: You can subscribe to the show and find notes along with links for everything that Matt just mentioned and including a complete transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and I'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Matt Danna.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+VdK4cUah + + ]]> + + Chad Pytel + Matt Danna + + + 423: Reign Ventures with Monique Idlett + https://podcast.thoughtbot.com/423 + 93e4b2e0-ff6c-466a-be5e-68d75a05c6d6 + Thu, 19 May 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Monique Idlett is the Founder of Reign Ventures, a seed-stage investment firm, and previously the Co-Founder and CEO of Mosley Brands and Mosley Music Group, home to a multiplatinum roster of artists. + +Chad talks with Monique about how the music industry is like the startup venture capital industry, understanding that representation matters, having a data-forward approach, and appearing on the TV show Undercover Billionaire, where entrepreneurs are given 90-days and nothing but 100 dollars to go undercover and build a thriving million-dollar business for a small town in the US. + 41:54 + no + + + Monique Idlett is the Founder of Reign Ventures, a seed-stage investment firm, and previously the Co-Founder and CEO of Mosley Brands and Mosley Music Group, home to a multiplatinum roster of artists. +Chad talks with Monique about how the music industry is like the startup venture capital industry, understanding that representation matters, having a data-forward approach, and appearing on the TV show Undercover Billionaire, where entrepreneurs are given 90-days and nothing but 100 dollars to go undercover and build a thriving million-dollar business for a small town in the US. +Reign Ventures (https://www.reignvc.com/) +Follow Reign Ventures on Twitter (https://twitter.com/ReignVc), Instagram (https://www.instagram.com/reign_ventures/), or LinkedIn (https://www.linkedin.com/company/reign-ventures/). +Follow Monique on Twitter (https://twitter.com/Monique_Mosley_) or LinkedIn (https://www.linkedin.com/in/monique-idlett-mosley-41353b15/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Monique Idlett, the Founder of Reign Ventures, a seed-stage investment firm, and previously the Co-Founder and CEO of Mosley Brands and Mosley Music Group, home to a multiplatinum roster of artists. +Monique, thank you so much for joining me. Now, you left Mosley Music Group about three years ago to focus exclusively on Reign Ventures. How is the music industry like the startup venture capital industry? +MONIQUE: There is no difference in the way I see a pipeline of amazing talented founders. We're truly looking for those exceptional founders that we can help develop, put up that bumper system. The end product in the music industry was the music we were consuming, the experiences through the live art form. And in the startup world, that end product is the success and the ability to scale a real solution that this company has solved with amazing, talented people. So to me, it was a nice, easy transition, and it made sense. +CHAD: Are there ways in which it's different? +MONIQUE: Oh my goodness, yes, lots of ways that it's different. The difference is that music is an art form. For me, music is the universal language. I believe that I've traveled the world. And I've been to places where there were language barriers, but when a song, a popular song, came on, the language barrier was gone. In the startup world, there may be several people trying to create and penetrate a problem area in a vertical or a category. And we may not have the ability in the startup world to have several of the same sounding things from a business model. They may not all work. +And so you're dealing with the emotional capacity on the music side. And on the tech side of things you're truly dealing with, can you really solve this problem? We're solving problems, not just emotional connections from the music industry perspective. And also, it's a lot slower moving. We have a project in the music industry, and it may have a cycle. And now it's an even shorter cycle with technology. You may be able to create an entire project in just a couple of weeks. +In the startup world, in the business side of things, you may not see the development for two to three years. So the patience is definitely...I've had to apply a lot more patience and understanding of being able to scale a business versus just a project-driven entity. So it's a little different, but the end result is all the same. Creating real great solutions for real problems, whether it's through an art form or whether it's through a business model, is all similar to me. +CHAD: So, do you have a particular investment strategy or focus at Reign? +MONIQUE: We do. Erica and I currently we are the largest two female Black-owned VC fund. So one of the things that we felt ten and a half years ago when we started investing together is investing has just been done...venture has been done wrong. There's a reason why less than 3% of funding collectively was...still to this day; it's about 3.2. But over ten years ago, when we started, only less than 3% of funding from VC was going to women, all women, and Black and Brown founders. +And so literally, we were like, the problem is that we're not having enough investment or a lens on women and people of color. And we want to do it the way it should have always been done: investing inclusively. We are proud to say that we invest in all founders, all exceptional founders. And yes, we have a lens on women and people of color because they've been under-capitalized and under-resourced and under-everything. And so the reality is that we want to set the tone of how it should always look and the world is inclusive. Diversity is not an issue; the equity and inclusion side is an issue. And we want to keep being that example. +CHAD: That's great. Do you feel like, or in your experience, have you found that these founders were already out there and they just were being passed over? Or were the problems so systemic that they weren't even getting the opportunity to even be out there? +MONIQUE: I think there are always exceptional people out there; that's number one. And I think it's a two-prong problem: yes, the pipeline, the access. So there's the lack of access for these types of founders that has absolutely been an issue, the lack of resources, the lack of access. But the other side of it is that they have just been overlooked and not allowed into the rooms. There are exceptional people in this world that don't only look like one type of person. And the reality is that we have access to them. And so yes, both of those are an issue, okay. +But the reality is that we have exceptional founders of all types of people. There are amazing people in this world. When you sit behind a computer, and you run an algorithm, and you only go to only your network of what looks like you and comfortable, then you are what we call missing out on a ton of opportunity. So Erica and I are founder-friendly. We go where the founders are. +CHAD: I've come to learn and understand representation really matters. Being able to see yourself is really important. And it's something that because I look like what I look like, I had the privilege to not realize how important that is because there are so many people in power that look like me. I can imagine it's super refreshing to a lot of the founders that you work with to be talking with you and sitting across the table from you and seeing that and talking to someone that understands them. +MONIQUE: Yes. I think that having someone to relate to on all levels, personal, professional is a very important concept. And I remember starting my career at USA Today; not only was I different in age because most of my colleagues were 40-plus, and I was in my young 20s, they were mostly male and definitely particularly only Caucasian. I was the first African American executive on the marketing and sales side. And I remember feeling very isolated and very lost and not knowing who I could turn to that would understand some of the things I was actually going through. +And so yes, founders, it eases the founder's mind when they can talk to me and know that hey, I didn't always look like this from this perspective. I grew up in income-based housing in New Jersey. I understand where you come from. Yes, I understand what it's like to be a Black woman; I am one. +But also the other side of it is that when we have founders who are Caucasian male. We like to have conversations of inclusion from the ground up with them. "Did you think about this consumer base? Do you know that you might have to message different?" These are things and conversations that people are not having if you're only talking to one type of person. And so, I think that what Reign Ventures is doing is allowing for comfortable conversation and then execution. +CHAD: That's great. You started with a $25 million fund in Reign, and you're well beyond that now, right? +MONIQUE: Yes, yes. So our current fund is a $50 million fund, and then our next fund will be...we're going for the stars and trying to raise $100 million. +CHAD: Wow. I've talked to a few people who are either interested in starting VC or who have done it before. And what do you use to judge how much or how large of a fund you'll be building? +MONIQUE: So we like to think of what we want the outcome to be. And so, the long-term goal of Reign Ventures is to have a billion-dollar under asset management. That has not been done by two Black females before. And so we understand if we do that, if we look at the long-term goal, if we do that and count backwards, here's what it will take to get to that billion dollars under asset management. So yes, the size of the fund will have to increase. +But we also know that that means we're creating amazing companies and supporting amazing founders with Reign Ventures. And so we look at the size as our ability to have a larger stake and the ability to have follow-on capital for all of the companies that are doing amazing. I would tell anyone who is looking to start a venture fund that Erica and I (Erica is my business partner.) she and I started and wrote our thesis over ten years ago. +And we actually deployed our personal capital for the first nine years so that we could create a data room and so that we could understand what it meant and felt like to have skin in the game so that we can learn truly where we sat well with a thesis. And it ended up being we do really well with consumer tech and SaaS, you know, B2B SaaS software. +And so, I would say that it's not an easy journey to start a venture fund. Truly understand what you want your thesis to be. Truly understand that you're going to hear the word No way more than you will hear the word Yes. This is someone else's investment. This is accountability. And try it and understand it before you just start raising money. +CHAD: You sort of alluded to this earlier; you said increasing the size of the fund is going to allow you to make bigger investments and follow-on investments. So do you also see you investing in more companies? +MONIQUE: So we like to have a 20 to 25 cap strategy per fund. And what we do is we take 25% of the capital for the earliest investment, and then we save 75% of it for the follow-on round so that we maintain our equity stake. Because we're founder-friendly, so we always want to be in that board room. We always want to roll up our sleeves with the founders and so maintaining whichever early equity we have, which is usually the way the fund is structured, between around 10%. It allows us to not just do more companies; it actually allows us to really double down on the portfolio itself and make sure that we're staying and growing with the founders. +CHAD: How involved are you? Are you personally involved? Do you split the portfolio up, and each person takes a few? Or how do you typically do it? +MONIQUE: We truly, truly do take my 25-plus years in the music industry. We take that very bumper system approach of we're here to help develop the raw talent and, on the tech side of things, the actual founding team and the evolution of the company. And so I usually take the board seats. +Erica, she comes from finance, and she's been doing finance banking for over 25 years. She's been doing early-stage investing for 16 of those years. And so, she helps with the finance cap strategies. How do we get you from your seed stage to your A in 12 months? How do we get you from your A to your B? So she's very, very involved with the financial models and running several of those and working with the founders on who's on your cap table? Okay, so intentionally and strategically, who's missing from your cap table? Let's work on that. +And then I'm always the one working on taking the board seat. I'm the one working with the vision, the strategy. I'm an operator, so I have a most extensive network. And so I'm the one aligning them with our resources, our network. And you know, yeah, we're very, very involved. +And I think that when you're dealing with seed-stage because that's the stage we're in, it's the riskiest. We try to de-risk the company, the founder, the founding team as much as possible. So we are as involved as the founder wants us to be. We do not make founders feel guilty for not having the largest team. We're like, "Okay, what do you need? Let's get you that." And that's where we like to play. We don't see ourselves going into anything past the seed stage. +CHAD: Is there a limit to how many companies that you're able to personally work with? And how do you scale, Monique? +MONIQUE: So the cool thing about our fund is that all of the companies are intentional. Half of our companies are consumer tech. So they mostly need pretty much the same type of things, even if they're in different verticals. The other half is SaaS. And so the reality is that they're in different stages. They're growing at different stages. And we, first and foremost, create a founder community that supports each other. That's number one. +Then we have an LP community that supports not just Erica and I but our founder community. So we look at investing as from a holistic community. We drive community, and that is the way that we're able to actually still have a sustainable business model with Erica and I. And we have a team. We don't do anything by ourselves. We have an entire team dedicated to the growth of our portfolio companies. +CHAD: Speaking of that team, what does that team look like now in terms of the different roles on it? And how big is it? +MONIQUE: So currently, right now, we have about four full-time. And then, we have a couple of interns who work on the data science side. And then we also have in-house from just Monique from my particular business model side; we have an HR. We have financial operators, and then we have contractors and partners. And so, at the end of the day, there isn't anything that our founders need that we can't source for them internally or externally. +CHAD: Who was the first person you brought onto the Reign team, and why? +MONIQUE: Her name is Naya, and she actually has worked for me on my foundation side for a few years. She's was an engineering student at University of Miami. And once she graduated, she was now getting her Master's in Data Science. And we felt like being able to report properly on our founders, the companies that were applying that we actually could not invest in but were investable, we'd like to keep track of that. And so, we felt like having someone who could really handle the data side of Reign Ventures was one of the more important hires. +And then, we also hired a full-time social media person who handles the content. We have a monthly podcast called The Series A. They oversee that so all communications on our portfolio companies and Reign Ventures as a whole. So those were the first two hires. And we're currently prepping to hire for the summer a full-time associate that will be out of the New York office. We have offices here in Miami, across from the University of Miami, and then we have offices in New York. +CHAD: That's cool. The data aspect of that is super interesting to me because I think that I talk to a lot of people, and a modern VC firm is certainly doing that. But there are still ones out there that don't have that data-forward approach that it sounds like you do. +MONIQUE: Well, we need to make sense of all of this. So we need to make sense of the idea of how many founders are applying? What is the demographic makeup of them? Who is this founder? Where are they coming from? What markets are they coming from? Because we do invest just only in the United States. And we pretty much invest in all markets here. We'd like to keep that data. +And most importantly, we are over-communicators with our LPs. So we're sending them monthly updates. Carta is updated every, you know, they have access to that. So we'd like for them to understand what our day is looking like. How are we spending our time? What type of founders are coming to us? Hey, you all don't necessarily have access to these founders, here's why we do. And so all of this information is important. You have to make sense of who your audience is. And for us, our audience are the founders. +Mid-Roll Ad: +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: You mentioned that you invest in people in some ways as much or more than you do the idea that they have and really work with them. How far along will people typically be with their product when you start working with them and investing in them? +MONIQUE: The way that the investment cycle is, you know, your family and friends, then your angels, and then sometimes even your super angels will come in after that. Then you have your pre-seed, which is usually where you're testing product-market fit, et cetera. And then we step in at the seed stage, which is founder market fit, you know, product-market fit, a billion-dollar addressable market. +You understand your operational strategy, where you're going to raise less than 50 million, and if you're not, you have that strategy of why? And definitely more than just an idea at that point. Now you just need to raise this round, to hire on more team, and then scale. So for us, that's how our due diligence works. +And if you make it through that due diligence, then it becomes about who is this founding team? Will they be able to deal with adversity? Because you're going to have it. Are they coachable? What is their leadership style? Is it an inclusive environment? You can't be creating an equity company, and then all the team looks the same. So these are the things that we're looking at. +What is your personality type? We like to spend time with our founders. How will you deal with the stress because the stress will come. Is your mindset the glass is half full or is it half empty? All of these things are important at the seed stage because it's not the growth stage where it's automatic it's happening. The seed stage boils down to can you deal with adversity? +CHAD: I imagine you reject a lot of people. +MONIQUE: Ooh, I would say that we use a different term. We are not dream killers. +CHAD: Okay. [chuckles] +MONIQUE: Here's what we say: we have an open-door policy with founders. We allow founders, even the ones that are not ready for investment or that we've actually had to pass on investment. And the thing is that we can only do 20 companies. That is where we'd like to sit, 20 companies per fund. And if for some reason, it's not a company that we invest in, we still give them access to our resources. We still give them access to our network. We still will spend…I mean, every Friday is our Founder Friday, and it fills up very quickly. +Erica and I get on with founders who are not in our portfolio because just because they weren't a good fit for Reign Ventures or it was something that we could not do, maybe it did not fit the fund's structure; we also try to align them with investors that might fit them more properly. And so I don't feel like we reject; we just redirect. +CHAD: So given that then, I imagine that you are often pretty open with the companies that you're not able to invest in the reasons why and hopefully, it helps them. +MONIQUE: Oh, absolutely. We get founders all the time that say, "Listen, this was the best thing. Prior to coming to you all, we weren't able to raise $1. You didn't invest in us, but you taught us how to be investable, and now we've raised money." That's what we want to hear. None of us win if there's really a great company with a great solution that can really have some traction if they never get up and running. +CHAD: That's great. And maybe you get the opportunity to invest in them later, right? +MONIQUE: Yep. Absolutely. Absolutely. There are a couple of companies that that has happened. And one of them is now back in our due diligence and probably will make it through. +CHAD: Yeah. Are there any companies in your portfolio that you particularly want to give a shout-out to? +MONIQUE: Oh, we love all of our portfolio companies. +CHAD: [laughs] +MONIQUE: You know, Sharebite, Dormify, SoLo Funds. SoLo Funds is one of my favorite companies from the perspective of dealing and disrupting predatory lending. As a person who grew up in a neighborhood that liquor stores and cash checking were like every other block, if not on the same block, we truly do know the long-term effect it has on those communities, right? The underserved communities get so taken advantage of. If you don't have $200 and then you go to a predatory lender, and you're paying them $2,000, how do you ever advance? And so SoLo Funds really, really the only Black-owned B Corp in the United States. +CHAD: That's awesome. +MONIQUE: This narrative is so important, Chad. +CHAD: Yeah. And, you know, not only is it important from a social perspective, but that is a huge business. It's a huge market opportunity for the right company with the right values to come in and be able to have a significant business, too, right? +MONIQUE: Listen, they're making the whole ecosystem better. For the lenders, listen; they feel good. They're having a positive social impact. And oh, by the way, I'm getting a return. For the borrowers, they are getting financial literacy. They are getting higher social credit scores, which is then impacting their personal credit score. I mean, listen, by the way, when this company was created, over 76% of Americans, if they were hit with a $200 bill, they were not going to be able to pay it. So this is not just about one type of community. This is about the American concept. +CHAD: So when you work with a company like that, were they a B Corp when you started working with them? +MONIQUE: No. True story, I was literally personally the second investor in and then the third before there was ever even...So Rodney Williams is the Co-Founder of SoLo Funds. And I'm on his board for LISNR. We were one of the first investors in LISNR, which is the data over audio company. And he shared this idea with me, and I loved it because we all come from a neighborhood where we know and we were the ones who quote, unquote, "were doing better" in our families. So we were always getting the daily calls like, "Oh, my car broke down. Oh, this." And when he said this to me, I'm like, "Oh my goodness, this makes so much sense. I'm in." +And see, this is where investing in people comes to play. Rodney had proved his ability as a founder with LISNR. So the trust was there, the relationship was there. Travis comes from banking, super, super intellectual, really quality guy, and not only is he the co-founder, but he's the CEO. And he's doing an amazing job. So no, it was not a B Corp; it is now one. And they will be the largest neobank for this community. And so growing and seeing the cycle of it is what, for me, personally, is what makes me happy. All of our companies in our fund have a social impact perspective. +CHAD: Had you been involved in a B Corp before? It's something that I'm really interested in, but I have not been directly involved in one before. And I'm actually really interested in it for thoughtbot too. +MONIQUE: No, I had not. No. +CHAD: Is it difficult? [laughs] +MONIQUE: So was it difficult for them? Absolutely. But they made it through. They made it through. And I think that we now have two men who are great human beings who happen to be Black men, but they are just great human beings who went through the process and can now help educate and share that experience with other people that look like them and are trying to do the same thing as them, create great companies with a great social impact to just have a better world. +CHAD: From an investor perspective, when your portfolio companies want to embark on something like becoming a B Corp, which, you know, some investors might look at and say, "That might be a distraction from what you need to do now," how do you look at those things? +MONIQUE: I mean, listen, if you want to become a B Corp, you actually are trying to have more of an impact, and I wish more companies were. When we actually are only focusing on the dollar side, the stakeholders of the dollar side, how are we truly making sure that we're impacting the world in a positive way? There's a lot of conflict usually. +So we encourage that type of behavior; we encourage founders to think beyond their dollar sign and their stakeholders' dollar sign. The good thing is that they had an amazing team supporting them. They had an amazing A series lead investor, ACME, that really drove it with them. And so they did this. We didn't do this. They did it. This was their mission, and they did it. +CHAD: That's great. And it's definitely something that's on my list to dig into more, like I said, for thoughtbot as well. So was it 2021 that you were on Undercover Billionaire? Was it last year? +MONIQUE: Oh my goodness. +CHAD: Or was it the end of 2020? +MONIQUE: So it was the end of 2020, yes. [laughs] Tacoma, Washington. +CHAD: Yeah. So for folks who don't know, Undercover Billionaire is a TV show where you give up all of your resources, and you're planted in a city, and you start a business from scratch. And you have what? Ninety days to bring it to a million-dollar business? +MONIQUE: Yes. So technically, the premise of the show is you literally get a new identity. And you do not know where you're being dropped literally until you're dropped there. And so, I had no idea I would be dropped into Tacoma, Washington. And one, they give you $100, literally, a phone with no contacts in it, and a used vehicle, and you have 90 days to turn that into a million-dollar valuation. +CHAD: It must have been a wild experience. +MONIQUE: I have to tell you, the emotional connection that has to happen and then also by the way you're lying to everyone, it was a very intense thing. And most of the time, 99% of time, you're running on adrenaline. And to be completely honest, when I first got there, you're focused on the goal. The goal is can you make this valuation? The goal is I can't be the example that didn't make it right. Then when you get there, it becomes less and less about the goal. +You actually get to a point where you don't even care if you make the goal. You care about the community that you've been dropped into. And you just want to see them win, and you want to see them become better. And Tacoma, Washington, everything from the mayor, down to now to one T'wina Nobles, who is now the Senator, the youngest senator in the state of Washington, these amazing people were a part of my journey. +So it became all about, wow, at the end of that experience, that last show, and I look at the room of all those people, it was the most inclusive experience naturally. That's what the win was for me personally. And I also got to learn about myself. But I will tell you that it was one of the hardest things I've ever done in life outside of having children and raising them to be healthy adults. +[laughter] +CHAD: Not only to build the business, you mean, but that experience of -- +MONIQUE: Just the entire experience. +CHAD: I watched the episode where you told everybody who you really were. +MONIQUE: Yes. +CHAD: And I could see that it had really affected you. +MONIQUE: I was lying to people every single day. And these people were so amazing. They donated their time, their resources, their ability to me because that company could not happen without them and without the community. And so, what we all walked away with was a shared experience of how powerful community actually is. And that even when you don't know how to figure something out, if you use your voice, someone will actually help you and you end up all helping each other. For me, that's what was so beautiful about the experience. +CHAD: I imagine it's pretty intense. How quickly did you force yourself to settle on the business you were actually going to build? +MONIQUE: It's so interesting because I have been asked like, "Did you create the concept before you went?" And I said, "Actually, no," literally, I went into it with a blank mind of wherever I end up, I want to see what they need, and we'll create a business model around that. +So I think it was like day four of being in Tacoma. And I was in an area that was a food desert for the most part. And I'm like, listen, I'm talking to people, and they're like, "Oh yeah, we have to order juice shots. They have to get shipped. Or we get the ones that are, you know, sitting in the grocery store, and that's not a lot of options." +And I'm like, wow, this is a problem. And I'm like, let's reimagine the ice cream truck. Everyone would like to think that the wealth gap...that if you make money, you care about your health, if you don't make money, you don't care about your health, actually, no. [laughs] I grew up in a natural home, and we lived in income-based housing growing up. And so the reality is that everyone wants to be healthy. +People need more access to healthier options at an affordable rate, and people will buy it. So the question was, oh, Monique, you can't sell juice shots for $5. Yes, we can. You think a community just because they're underserved won't pay for their health? They absolutely will if you give them the option to. We always sold out in the communities that they said would never sell. +CHAD: So up against a ticking clock, what did you do to sort of validate the idea and really run with it, or did you just know? +MONIQUE: No, you don't just know, right? +CHAD: Yeah. [chuckles] +MONIQUE: You're literally working on adrenaline. Listen, there was nothing normal. We all know this as business owners; there's nothing normal about this concept. You can't create a successful business in 90 days. So you're literally in overdrive: no sleep, multitasking, doing all types of things. Here was the thing; first of all, I talked to the community. I asked them what did they need? What were they missing? If they had access to something, would they utilize it? That was number one. +Number two was testing it. So I started making samples. And I went out to the community again and started testing it. Three was of the test that did good; let's run with that and package that up. And you have to understand, Chad, it was the height of the pandemic. Everything was shut down. You know, I live in Florida, so we weren't like that. But going to Tacoma, Washington, nothing was open. So I had to think, how do I get to people because they're not coming and cannot come to a brick and mortar? +So the only thing that was pretty much open was the farmers' market. So that's what I did. I'm like, let's get to the farmers market. And also, let's see how we become mobile, oh, the ice cream truck treats. Let's teach people that healthy treats are actually what they crave. +CHAD: I think even though it was accelerated, intense, the things you're talking about doing in terms of validating the idea, actually talking to customers, testing things out, those are things I think people want to do in any situation. +MONIQUE: It is absolutely true. We talk to founders all the time, and it's the I, I, I. And we tell them, "Well, have you talked to your customer?" Sometimes we're so close to our ideas because we hold them, and we're trying to solve a problem maybe that we experience. That's step one. But step two is, is it something that other people want and need? So you definitely have to go out there and do market research. +CHAD: Are there other things that you counsel founders on doing? Particularly with the seed stage, you know, on the verge of significant growth and scaling, what are some things that are maybe common plays or common pitfalls of companies at that stage? +MONIQUE: So some of the things that we see, especially with solo founders, is them having this idea that only they can do everything and not understanding that you actually have to have a founding team. And that does require you to give some equity. We see founders wanting to hold on to everything. And then it becomes do you want 100% of something that's very restricted, or do you want to share it and make it something really special and a part of a billion-dollar concept? So that's one. +Two would be founders in need happen to take money without understanding that it is a debt that even if it's fundraising and you're raising institutional capital, these are your investors. These are your partners. And is it a good partnership? We have seen a lot of founders in contractual and legal documents because they went and took money from the wrong type of investor. We see that -- +CHAD: And they did that because they were desperate at the time? +MONIQUE: They were desperate. They were desperate. They were desperate and for just really crazy, contractual things. They don't have attorneys look at the paperwork. We see a lot of these mistakes. And so we tell founders you have to have a step back from your business. You have to look at all types of options. Have you applied for grants and particular grants in areas of the problem that you're solving? Have you tried for Small Business Association grants? Have you tried to get a credit line versus an investor who's now going to have equity? These are all the things. +And if you do need investors, don't take all the same types of investors. If every investor in your cap table is a bean counter and the numbers aren't playing out well for them, what type of board meeting is that going to be? So make sure you have an operator who's on your board. Make sure you have a financial person, investor on your board. You have to be very strategic and intentional. And if you're in a desperate moment, I can guarantee that is not when you want to take the money that you actually need to do a deeper dive and step back from the company to really see what the company needs. +CHAD: Monique, I feel like that's great advice. The level of experience and passion that you have for the work is obvious in listening to you. It makes me want to work with you. [laughs] +MONIQUE: Oh, thank you, Chad. Yes, I'm very impressed with what you have built. And I'm very impressed with you understanding the ability to give access to information to your audience. Here's the thing, we are products of an environment of capitalism. And there's nothing wrong with capitalism, but it just needs to be a lot more conscious. And it needs to have a much better impact for all. The problem with from our childhood age of education is we've been taught that there's only one, there can only be one winner. There's only one first place. +We have to take that mindset back and really step into the power and the power that we truly have, which is abundance. There's enough for us all. We just have to give that power back to it. And the reality is that we all need each other, and we all need to build together. And people just need access to information. +Most founders tell us, "I was embarrassed to ask that. I was made to feel like I was supposed to know this, so I just went ahead and pretended like I knew it." It's okay that we don't know everything. In fact, I like to sit in that space of student and say, "You know what? I like to be in the room that I actually don't know anything because then that means I'm learning, and it's okay. We better keep learning." +One of my favorite quotes is, "We delight in the beauty of the butterfly but rarely admit the changes it has gone through to achieve that beauty." And Maya Angelou wrote that, and she understood the human spirit needs to understand that no matter what career path we're on, Founder, CEO, employee, employer, no matter what that is, it is a constant evolution of self. And sometimes we'll feel like a butterfly, and sometimes we will have to be in that learning and growth and uncomfortable stage. But the beauty of uncomfort means you're growing, and we have to make more people feel comfortable with that. +CHAD: That's beautiful. Monique, thank you so much for coming on the show and sharing with all of us. +MONIQUE: No, thank you, Chad, for having me. +CHAD: If folks want to get in touch with you or find out more about Reign, where are all the different places that they can do that? +MONIQUE: So if they want to contact me, they can email me at monique@reignvc.com, which is R-E-I-G-N-V-C.com. We're on LinkedIn; we're on Twitter; we're on Instagram. And if they want to learn more about Reign VC, they could just go to reignvc.com. And if they have any questions, they can submit it, and we'll get back to them. +CHAD: Wonderful. And you can subscribe to the show and find notes and a full transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm, and you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Monique Idlett. + + + Monique Idlett is the Founder of Reign Ventures, a seed-stage investment firm, and previously the Co-Founder and CEO of Mosley Brands and Mosley Music Group, home to a multiplatinum roster of artists.

+ +

Chad talks with Monique about how the music industry is like the startup venture capital industry, understanding that representation matters, having a data-forward approach, and appearing on the TV show Undercover Billionaire, where entrepreneurs are given 90-days and nothing but 100 dollars to go undercover and build a thriving million-dollar business for a small town in the US.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Monique Idlett, the Founder of Reign Ventures, a seed-stage investment firm, and previously the Co-Founder and CEO of Mosley Brands and Mosley Music Group, home to a multiplatinum roster of artists.

+ +

Monique, thank you so much for joining me. Now, you left Mosley Music Group about three years ago to focus exclusively on Reign Ventures. How is the music industry like the startup venture capital industry?

+ +

MONIQUE: There is no difference in the way I see a pipeline of amazing talented founders. We're truly looking for those exceptional founders that we can help develop, put up that bumper system. The end product in the music industry was the music we were consuming, the experiences through the live art form. And in the startup world, that end product is the success and the ability to scale a real solution that this company has solved with amazing, talented people. So to me, it was a nice, easy transition, and it made sense.

+ +

CHAD: Are there ways in which it's different?

+ +

MONIQUE: Oh my goodness, yes, lots of ways that it's different. The difference is that music is an art form. For me, music is the universal language. I believe that I've traveled the world. And I've been to places where there were language barriers, but when a song, a popular song, came on, the language barrier was gone. In the startup world, there may be several people trying to create and penetrate a problem area in a vertical or a category. And we may not have the ability in the startup world to have several of the same sounding things from a business model. They may not all work.

+ +

And so you're dealing with the emotional capacity on the music side. And on the tech side of things you're truly dealing with, can you really solve this problem? We're solving problems, not just emotional connections from the music industry perspective. And also, it's a lot slower moving. We have a project in the music industry, and it may have a cycle. And now it's an even shorter cycle with technology. You may be able to create an entire project in just a couple of weeks.

+ +

In the startup world, in the business side of things, you may not see the development for two to three years. So the patience is definitely...I've had to apply a lot more patience and understanding of being able to scale a business versus just a project-driven entity. So it's a little different, but the end result is all the same. Creating real great solutions for real problems, whether it's through an art form or whether it's through a business model, is all similar to me.

+ +

CHAD: So, do you have a particular investment strategy or focus at Reign?

+ +

MONIQUE: We do. Erica and I currently we are the largest two female Black-owned VC fund. So one of the things that we felt ten and a half years ago when we started investing together is investing has just been done...venture has been done wrong. There's a reason why less than 3% of funding collectively was...still to this day; it's about 3.2. But over ten years ago, when we started, only less than 3% of funding from VC was going to women, all women, and Black and Brown founders.

+ +

And so literally, we were like, the problem is that we're not having enough investment or a lens on women and people of color. And we want to do it the way it should have always been done: investing inclusively. We are proud to say that we invest in all founders, all exceptional founders. And yes, we have a lens on women and people of color because they've been under-capitalized and under-resourced and under-everything. And so the reality is that we want to set the tone of how it should always look and the world is inclusive. Diversity is not an issue; the equity and inclusion side is an issue. And we want to keep being that example.

+ +

CHAD: That's great. Do you feel like, or in your experience, have you found that these founders were already out there and they just were being passed over? Or were the problems so systemic that they weren't even getting the opportunity to even be out there?

+ +

MONIQUE: I think there are always exceptional people out there; that's number one. And I think it's a two-prong problem: yes, the pipeline, the access. So there's the lack of access for these types of founders that has absolutely been an issue, the lack of resources, the lack of access. But the other side of it is that they have just been overlooked and not allowed into the rooms. There are exceptional people in this world that don't only look like one type of person. And the reality is that we have access to them. And so yes, both of those are an issue, okay.

+ +

But the reality is that we have exceptional founders of all types of people. There are amazing people in this world. When you sit behind a computer, and you run an algorithm, and you only go to only your network of what looks like you and comfortable, then you are what we call missing out on a ton of opportunity. So Erica and I are founder-friendly. We go where the founders are.

+ +

CHAD: I've come to learn and understand representation really matters. Being able to see yourself is really important. And it's something that because I look like what I look like, I had the privilege to not realize how important that is because there are so many people in power that look like me. I can imagine it's super refreshing to a lot of the founders that you work with to be talking with you and sitting across the table from you and seeing that and talking to someone that understands them.

+ +

MONIQUE: Yes. I think that having someone to relate to on all levels, personal, professional is a very important concept. And I remember starting my career at USA Today; not only was I different in age because most of my colleagues were 40-plus, and I was in my young 20s, they were mostly male and definitely particularly only Caucasian. I was the first African American executive on the marketing and sales side. And I remember feeling very isolated and very lost and not knowing who I could turn to that would understand some of the things I was actually going through.

+ +

And so yes, founders, it eases the founder's mind when they can talk to me and know that hey, I didn't always look like this from this perspective. I grew up in income-based housing in New Jersey. I understand where you come from. Yes, I understand what it's like to be a Black woman; I am one.

+ +

But also the other side of it is that when we have founders who are Caucasian male. We like to have conversations of inclusion from the ground up with them. "Did you think about this consumer base? Do you know that you might have to message different?" These are things and conversations that people are not having if you're only talking to one type of person. And so, I think that what Reign Ventures is doing is allowing for comfortable conversation and then execution.

+ +

CHAD: That's great. You started with a $25 million fund in Reign, and you're well beyond that now, right?

+ +

MONIQUE: Yes, yes. So our current fund is a $50 million fund, and then our next fund will be...we're going for the stars and trying to raise $100 million.

+ +

CHAD: Wow. I've talked to a few people who are either interested in starting VC or who have done it before. And what do you use to judge how much or how large of a fund you'll be building?

+ +

MONIQUE: So we like to think of what we want the outcome to be. And so, the long-term goal of Reign Ventures is to have a billion-dollar under asset management. That has not been done by two Black females before. And so we understand if we do that, if we look at the long-term goal, if we do that and count backwards, here's what it will take to get to that billion dollars under asset management. So yes, the size of the fund will have to increase.

+ +

But we also know that that means we're creating amazing companies and supporting amazing founders with Reign Ventures. And so we look at the size as our ability to have a larger stake and the ability to have follow-on capital for all of the companies that are doing amazing. I would tell anyone who is looking to start a venture fund that Erica and I (Erica is my business partner.) she and I started and wrote our thesis over ten years ago.

+ +

And we actually deployed our personal capital for the first nine years so that we could create a data room and so that we could understand what it meant and felt like to have skin in the game so that we can learn truly where we sat well with a thesis. And it ended up being we do really well with consumer tech and SaaS, you know, B2B SaaS software.

+ +

And so, I would say that it's not an easy journey to start a venture fund. Truly understand what you want your thesis to be. Truly understand that you're going to hear the word No way more than you will hear the word Yes. This is someone else's investment. This is accountability. And try it and understand it before you just start raising money.

+ +

CHAD: You sort of alluded to this earlier; you said increasing the size of the fund is going to allow you to make bigger investments and follow-on investments. So do you also see you investing in more companies?

+ +

MONIQUE: So we like to have a 20 to 25 cap strategy per fund. And what we do is we take 25% of the capital for the earliest investment, and then we save 75% of it for the follow-on round so that we maintain our equity stake. Because we're founder-friendly, so we always want to be in that board room. We always want to roll up our sleeves with the founders and so maintaining whichever early equity we have, which is usually the way the fund is structured, between around 10%. It allows us to not just do more companies; it actually allows us to really double down on the portfolio itself and make sure that we're staying and growing with the founders.

+ +

CHAD: How involved are you? Are you personally involved? Do you split the portfolio up, and each person takes a few? Or how do you typically do it?

+ +

MONIQUE: We truly, truly do take my 25-plus years in the music industry. We take that very bumper system approach of we're here to help develop the raw talent and, on the tech side of things, the actual founding team and the evolution of the company. And so I usually take the board seats.

+ +

Erica, she comes from finance, and she's been doing finance banking for over 25 years. She's been doing early-stage investing for 16 of those years. And so, she helps with the finance cap strategies. How do we get you from your seed stage to your A in 12 months? How do we get you from your A to your B? So she's very, very involved with the financial models and running several of those and working with the founders on who's on your cap table? Okay, so intentionally and strategically, who's missing from your cap table? Let's work on that.

+ +

And then I'm always the one working on taking the board seat. I'm the one working with the vision, the strategy. I'm an operator, so I have a most extensive network. And so I'm the one aligning them with our resources, our network. And you know, yeah, we're very, very involved.

+ +

And I think that when you're dealing with seed-stage because that's the stage we're in, it's the riskiest. We try to de-risk the company, the founder, the founding team as much as possible. So we are as involved as the founder wants us to be. We do not make founders feel guilty for not having the largest team. We're like, "Okay, what do you need? Let's get you that." And that's where we like to play. We don't see ourselves going into anything past the seed stage.

+ +

CHAD: Is there a limit to how many companies that you're able to personally work with? And how do you scale, Monique?

+ +

MONIQUE: So the cool thing about our fund is that all of the companies are intentional. Half of our companies are consumer tech. So they mostly need pretty much the same type of things, even if they're in different verticals. The other half is SaaS. And so the reality is that they're in different stages. They're growing at different stages. And we, first and foremost, create a founder community that supports each other. That's number one.

+ +

Then we have an LP community that supports not just Erica and I but our founder community. So we look at investing as from a holistic community. We drive community, and that is the way that we're able to actually still have a sustainable business model with Erica and I. And we have a team. We don't do anything by ourselves. We have an entire team dedicated to the growth of our portfolio companies.

+ +

CHAD: Speaking of that team, what does that team look like now in terms of the different roles on it? And how big is it?

+ +

MONIQUE: So currently, right now, we have about four full-time. And then, we have a couple of interns who work on the data science side. And then we also have in-house from just Monique from my particular business model side; we have an HR. We have financial operators, and then we have contractors and partners. And so, at the end of the day, there isn't anything that our founders need that we can't source for them internally or externally.

+ +

CHAD: Who was the first person you brought onto the Reign team, and why?

+ +

MONIQUE: Her name is Naya, and she actually has worked for me on my foundation side for a few years. She's was an engineering student at University of Miami. And once she graduated, she was now getting her Master's in Data Science. And we felt like being able to report properly on our founders, the companies that were applying that we actually could not invest in but were investable, we'd like to keep track of that. And so, we felt like having someone who could really handle the data side of Reign Ventures was one of the more important hires.

+ +

And then, we also hired a full-time social media person who handles the content. We have a monthly podcast called The Series A. They oversee that so all communications on our portfolio companies and Reign Ventures as a whole. So those were the first two hires. And we're currently prepping to hire for the summer a full-time associate that will be out of the New York office. We have offices here in Miami, across from the University of Miami, and then we have offices in New York.

+ +

CHAD: That's cool. The data aspect of that is super interesting to me because I think that I talk to a lot of people, and a modern VC firm is certainly doing that. But there are still ones out there that don't have that data-forward approach that it sounds like you do.

+ +

MONIQUE: Well, we need to make sense of all of this. So we need to make sense of the idea of how many founders are applying? What is the demographic makeup of them? Who is this founder? Where are they coming from? What markets are they coming from? Because we do invest just only in the United States. And we pretty much invest in all markets here. We'd like to keep that data.

+ +

And most importantly, we are over-communicators with our LPs. So we're sending them monthly updates. Carta is updated every, you know, they have access to that. So we'd like for them to understand what our day is looking like. How are we spending our time? What type of founders are coming to us? Hey, you all don't necessarily have access to these founders, here's why we do. And so all of this information is important. You have to make sense of who your audience is. And for us, our audience are the founders.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: You mentioned that you invest in people in some ways as much or more than you do the idea that they have and really work with them. How far along will people typically be with their product when you start working with them and investing in them?

+ +

MONIQUE: The way that the investment cycle is, you know, your family and friends, then your angels, and then sometimes even your super angels will come in after that. Then you have your pre-seed, which is usually where you're testing product-market fit, et cetera. And then we step in at the seed stage, which is founder market fit, you know, product-market fit, a billion-dollar addressable market.

+ +

You understand your operational strategy, where you're going to raise less than 50 million, and if you're not, you have that strategy of why? And definitely more than just an idea at that point. Now you just need to raise this round, to hire on more team, and then scale. So for us, that's how our due diligence works.

+ +

And if you make it through that due diligence, then it becomes about who is this founding team? Will they be able to deal with adversity? Because you're going to have it. Are they coachable? What is their leadership style? Is it an inclusive environment? You can't be creating an equity company, and then all the team looks the same. So these are the things that we're looking at.

+ +

What is your personality type? We like to spend time with our founders. How will you deal with the stress because the stress will come. Is your mindset the glass is half full or is it half empty? All of these things are important at the seed stage because it's not the growth stage where it's automatic it's happening. The seed stage boils down to can you deal with adversity?

+ +

CHAD: I imagine you reject a lot of people.

+ +

MONIQUE: Ooh, I would say that we use a different term. We are not dream killers.

+ +

CHAD: Okay. [chuckles]

+ +

MONIQUE: Here's what we say: we have an open-door policy with founders. We allow founders, even the ones that are not ready for investment or that we've actually had to pass on investment. And the thing is that we can only do 20 companies. That is where we'd like to sit, 20 companies per fund. And if for some reason, it's not a company that we invest in, we still give them access to our resources. We still give them access to our network. We still will spend…I mean, every Friday is our Founder Friday, and it fills up very quickly.

+ +

Erica and I get on with founders who are not in our portfolio because just because they weren't a good fit for Reign Ventures or it was something that we could not do, maybe it did not fit the fund's structure; we also try to align them with investors that might fit them more properly. And so I don't feel like we reject; we just redirect.

+ +

CHAD: So given that then, I imagine that you are often pretty open with the companies that you're not able to invest in the reasons why and hopefully, it helps them.

+ +

MONIQUE: Oh, absolutely. We get founders all the time that say, "Listen, this was the best thing. Prior to coming to you all, we weren't able to raise $1. You didn't invest in us, but you taught us how to be investable, and now we've raised money." That's what we want to hear. None of us win if there's really a great company with a great solution that can really have some traction if they never get up and running.

+ +

CHAD: That's great. And maybe you get the opportunity to invest in them later, right?

+ +

MONIQUE: Yep. Absolutely. Absolutely. There are a couple of companies that that has happened. And one of them is now back in our due diligence and probably will make it through.

+ +

CHAD: Yeah. Are there any companies in your portfolio that you particularly want to give a shout-out to?

+ +

MONIQUE: Oh, we love all of our portfolio companies.

+ +

CHAD: [laughs]

+ +

MONIQUE: You know, Sharebite, Dormify, SoLo Funds. SoLo Funds is one of my favorite companies from the perspective of dealing and disrupting predatory lending. As a person who grew up in a neighborhood that liquor stores and cash checking were like every other block, if not on the same block, we truly do know the long-term effect it has on those communities, right? The underserved communities get so taken advantage of. If you don't have $200 and then you go to a predatory lender, and you're paying them $2,000, how do you ever advance? And so SoLo Funds really, really the only Black-owned B Corp in the United States.

+ +

CHAD: That's awesome.

+ +

MONIQUE: This narrative is so important, Chad.

+ +

CHAD: Yeah. And, you know, not only is it important from a social perspective, but that is a huge business. It's a huge market opportunity for the right company with the right values to come in and be able to have a significant business, too, right?

+ +

MONIQUE: Listen, they're making the whole ecosystem better. For the lenders, listen; they feel good. They're having a positive social impact. And oh, by the way, I'm getting a return. For the borrowers, they are getting financial literacy. They are getting higher social credit scores, which is then impacting their personal credit score. I mean, listen, by the way, when this company was created, over 76% of Americans, if they were hit with a $200 bill, they were not going to be able to pay it. So this is not just about one type of community. This is about the American concept.

+ +

CHAD: So when you work with a company like that, were they a B Corp when you started working with them?

+ +

MONIQUE: No. True story, I was literally personally the second investor in and then the third before there was ever even...So Rodney Williams is the Co-Founder of SoLo Funds. And I'm on his board for LISNR. We were one of the first investors in LISNR, which is the data over audio company. And he shared this idea with me, and I loved it because we all come from a neighborhood where we know and we were the ones who quote, unquote, "were doing better" in our families. So we were always getting the daily calls like, "Oh, my car broke down. Oh, this." And when he said this to me, I'm like, "Oh my goodness, this makes so much sense. I'm in."

+ +

And see, this is where investing in people comes to play. Rodney had proved his ability as a founder with LISNR. So the trust was there, the relationship was there. Travis comes from banking, super, super intellectual, really quality guy, and not only is he the co-founder, but he's the CEO. And he's doing an amazing job. So no, it was not a B Corp; it is now one. And they will be the largest neobank for this community. And so growing and seeing the cycle of it is what, for me, personally, is what makes me happy. All of our companies in our fund have a social impact perspective.

+ +

CHAD: Had you been involved in a B Corp before? It's something that I'm really interested in, but I have not been directly involved in one before. And I'm actually really interested in it for thoughtbot too.

+ +

MONIQUE: No, I had not. No.

+ +

CHAD: Is it difficult? [laughs]

+ +

MONIQUE: So was it difficult for them? Absolutely. But they made it through. They made it through. And I think that we now have two men who are great human beings who happen to be Black men, but they are just great human beings who went through the process and can now help educate and share that experience with other people that look like them and are trying to do the same thing as them, create great companies with a great social impact to just have a better world.

+ +

CHAD: From an investor perspective, when your portfolio companies want to embark on something like becoming a B Corp, which, you know, some investors might look at and say, "That might be a distraction from what you need to do now," how do you look at those things?

+ +

MONIQUE: I mean, listen, if you want to become a B Corp, you actually are trying to have more of an impact, and I wish more companies were. When we actually are only focusing on the dollar side, the stakeholders of the dollar side, how are we truly making sure that we're impacting the world in a positive way? There's a lot of conflict usually.

+ +

So we encourage that type of behavior; we encourage founders to think beyond their dollar sign and their stakeholders' dollar sign. The good thing is that they had an amazing team supporting them. They had an amazing A series lead investor, ACME, that really drove it with them. And so they did this. We didn't do this. They did it. This was their mission, and they did it.

+ +

CHAD: That's great. And it's definitely something that's on my list to dig into more, like I said, for thoughtbot as well. So was it 2021 that you were on Undercover Billionaire? Was it last year?

+ +

MONIQUE: Oh my goodness.

+ +

CHAD: Or was it the end of 2020?

+ +

MONIQUE: So it was the end of 2020, yes. [laughs] Tacoma, Washington.

+ +

CHAD: Yeah. So for folks who don't know, Undercover Billionaire is a TV show where you give up all of your resources, and you're planted in a city, and you start a business from scratch. And you have what? Ninety days to bring it to a million-dollar business?

+ +

MONIQUE: Yes. So technically, the premise of the show is you literally get a new identity. And you do not know where you're being dropped literally until you're dropped there. And so, I had no idea I would be dropped into Tacoma, Washington. And one, they give you $100, literally, a phone with no contacts in it, and a used vehicle, and you have 90 days to turn that into a million-dollar valuation.

+ +

CHAD: It must have been a wild experience.

+ +

MONIQUE: I have to tell you, the emotional connection that has to happen and then also by the way you're lying to everyone, it was a very intense thing. And most of the time, 99% of time, you're running on adrenaline. And to be completely honest, when I first got there, you're focused on the goal. The goal is can you make this valuation? The goal is I can't be the example that didn't make it right. Then when you get there, it becomes less and less about the goal.

+ +

You actually get to a point where you don't even care if you make the goal. You care about the community that you've been dropped into. And you just want to see them win, and you want to see them become better. And Tacoma, Washington, everything from the mayor, down to now to one T'wina Nobles, who is now the Senator, the youngest senator in the state of Washington, these amazing people were a part of my journey.

+ +

So it became all about, wow, at the end of that experience, that last show, and I look at the room of all those people, it was the most inclusive experience naturally. That's what the win was for me personally. And I also got to learn about myself. But I will tell you that it was one of the hardest things I've ever done in life outside of having children and raising them to be healthy adults.

+ +

[laughter]

+ +

CHAD: Not only to build the business, you mean, but that experience of --

+ +

MONIQUE: Just the entire experience.

+ +

CHAD: I watched the episode where you told everybody who you really were.

+ +

MONIQUE: Yes.

+ +

CHAD: And I could see that it had really affected you.

+ +

MONIQUE: I was lying to people every single day. And these people were so amazing. They donated their time, their resources, their ability to me because that company could not happen without them and without the community. And so, what we all walked away with was a shared experience of how powerful community actually is. And that even when you don't know how to figure something out, if you use your voice, someone will actually help you and you end up all helping each other. For me, that's what was so beautiful about the experience.

+ +

CHAD: I imagine it's pretty intense. How quickly did you force yourself to settle on the business you were actually going to build?

+ +

MONIQUE: It's so interesting because I have been asked like, "Did you create the concept before you went?" And I said, "Actually, no," literally, I went into it with a blank mind of wherever I end up, I want to see what they need, and we'll create a business model around that.

+ +

So I think it was like day four of being in Tacoma. And I was in an area that was a food desert for the most part. And I'm like, listen, I'm talking to people, and they're like, "Oh yeah, we have to order juice shots. They have to get shipped. Or we get the ones that are, you know, sitting in the grocery store, and that's not a lot of options."

+ +

And I'm like, wow, this is a problem. And I'm like, let's reimagine the ice cream truck. Everyone would like to think that the wealth gap...that if you make money, you care about your health, if you don't make money, you don't care about your health, actually, no. [laughs] I grew up in a natural home, and we lived in income-based housing growing up. And so the reality is that everyone wants to be healthy.

+ +

People need more access to healthier options at an affordable rate, and people will buy it. So the question was, oh, Monique, you can't sell juice shots for $5. Yes, we can. You think a community just because they're underserved won't pay for their health? They absolutely will if you give them the option to. We always sold out in the communities that they said would never sell.

+ +

CHAD: So up against a ticking clock, what did you do to sort of validate the idea and really run with it, or did you just know?

+ +

MONIQUE: No, you don't just know, right?

+ +

CHAD: Yeah. [chuckles]

+ +

MONIQUE: You're literally working on adrenaline. Listen, there was nothing normal. We all know this as business owners; there's nothing normal about this concept. You can't create a successful business in 90 days. So you're literally in overdrive: no sleep, multitasking, doing all types of things. Here was the thing; first of all, I talked to the community. I asked them what did they need? What were they missing? If they had access to something, would they utilize it? That was number one.

+ +

Number two was testing it. So I started making samples. And I went out to the community again and started testing it. Three was of the test that did good; let's run with that and package that up. And you have to understand, Chad, it was the height of the pandemic. Everything was shut down. You know, I live in Florida, so we weren't like that. But going to Tacoma, Washington, nothing was open. So I had to think, how do I get to people because they're not coming and cannot come to a brick and mortar?

+ +

So the only thing that was pretty much open was the farmers' market. So that's what I did. I'm like, let's get to the farmers market. And also, let's see how we become mobile, oh, the ice cream truck treats. Let's teach people that healthy treats are actually what they crave.

+ +

CHAD: I think even though it was accelerated, intense, the things you're talking about doing in terms of validating the idea, actually talking to customers, testing things out, those are things I think people want to do in any situation.

+ +

MONIQUE: It is absolutely true. We talk to founders all the time, and it's the I, I, I. And we tell them, "Well, have you talked to your customer?" Sometimes we're so close to our ideas because we hold them, and we're trying to solve a problem maybe that we experience. That's step one. But step two is, is it something that other people want and need? So you definitely have to go out there and do market research.

+ +

CHAD: Are there other things that you counsel founders on doing? Particularly with the seed stage, you know, on the verge of significant growth and scaling, what are some things that are maybe common plays or common pitfalls of companies at that stage?

+ +

MONIQUE: So some of the things that we see, especially with solo founders, is them having this idea that only they can do everything and not understanding that you actually have to have a founding team. And that does require you to give some equity. We see founders wanting to hold on to everything. And then it becomes do you want 100% of something that's very restricted, or do you want to share it and make it something really special and a part of a billion-dollar concept? So that's one.

+ +

Two would be founders in need happen to take money without understanding that it is a debt that even if it's fundraising and you're raising institutional capital, these are your investors. These are your partners. And is it a good partnership? We have seen a lot of founders in contractual and legal documents because they went and took money from the wrong type of investor. We see that --

+ +

CHAD: And they did that because they were desperate at the time?

+ +

MONIQUE: They were desperate. They were desperate. They were desperate and for just really crazy, contractual things. They don't have attorneys look at the paperwork. We see a lot of these mistakes. And so we tell founders you have to have a step back from your business. You have to look at all types of options. Have you applied for grants and particular grants in areas of the problem that you're solving? Have you tried for Small Business Association grants? Have you tried to get a credit line versus an investor who's now going to have equity? These are all the things.

+ +

And if you do need investors, don't take all the same types of investors. If every investor in your cap table is a bean counter and the numbers aren't playing out well for them, what type of board meeting is that going to be? So make sure you have an operator who's on your board. Make sure you have a financial person, investor on your board. You have to be very strategic and intentional. And if you're in a desperate moment, I can guarantee that is not when you want to take the money that you actually need to do a deeper dive and step back from the company to really see what the company needs.

+ +

CHAD: Monique, I feel like that's great advice. The level of experience and passion that you have for the work is obvious in listening to you. It makes me want to work with you. [laughs]

+ +

MONIQUE: Oh, thank you, Chad. Yes, I'm very impressed with what you have built. And I'm very impressed with you understanding the ability to give access to information to your audience. Here's the thing, we are products of an environment of capitalism. And there's nothing wrong with capitalism, but it just needs to be a lot more conscious. And it needs to have a much better impact for all. The problem with from our childhood age of education is we've been taught that there's only one, there can only be one winner. There's only one first place.

+ +

We have to take that mindset back and really step into the power and the power that we truly have, which is abundance. There's enough for us all. We just have to give that power back to it. And the reality is that we all need each other, and we all need to build together. And people just need access to information.

+ +

Most founders tell us, "I was embarrassed to ask that. I was made to feel like I was supposed to know this, so I just went ahead and pretended like I knew it." It's okay that we don't know everything. In fact, I like to sit in that space of student and say, "You know what? I like to be in the room that I actually don't know anything because then that means I'm learning, and it's okay. We better keep learning."

+ +

One of my favorite quotes is, "We delight in the beauty of the butterfly but rarely admit the changes it has gone through to achieve that beauty." And Maya Angelou wrote that, and she understood the human spirit needs to understand that no matter what career path we're on, Founder, CEO, employee, employer, no matter what that is, it is a constant evolution of self. And sometimes we'll feel like a butterfly, and sometimes we will have to be in that learning and growth and uncomfortable stage. But the beauty of uncomfort means you're growing, and we have to make more people feel comfortable with that.

+ +

CHAD: That's beautiful. Monique, thank you so much for coming on the show and sharing with all of us.

+ +

MONIQUE: No, thank you, Chad, for having me.

+ +

CHAD: If folks want to get in touch with you or find out more about Reign, where are all the different places that they can do that?

+ +

MONIQUE: So if they want to contact me, they can email me at monique@reignvc.com, which is R-E-I-G-N-V-C.com. We're on LinkedIn; we're on Twitter; we're on Instagram. And if they want to learn more about Reign VC, they could just go to reignvc.com. And if they have any questions, they can submit it, and we'll get back to them.

+ +

CHAD: Wonderful. And you can subscribe to the show and find notes and a full transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm, and you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Monique Idlett.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Monique Idlett is the Founder of Reign Ventures, a seed-stage investment firm, and previously the Co-Founder and CEO of Mosley Brands and Mosley Music Group, home to a multiplatinum roster of artists.

+ +

Chad talks with Monique about how the music industry is like the startup venture capital industry, understanding that representation matters, having a data-forward approach, and appearing on the TV show Undercover Billionaire, where entrepreneurs are given 90-days and nothing but 100 dollars to go undercover and build a thriving million-dollar business for a small town in the US.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Monique Idlett, the Founder of Reign Ventures, a seed-stage investment firm, and previously the Co-Founder and CEO of Mosley Brands and Mosley Music Group, home to a multiplatinum roster of artists.

+ +

Monique, thank you so much for joining me. Now, you left Mosley Music Group about three years ago to focus exclusively on Reign Ventures. How is the music industry like the startup venture capital industry?

+ +

MONIQUE: There is no difference in the way I see a pipeline of amazing talented founders. We're truly looking for those exceptional founders that we can help develop, put up that bumper system. The end product in the music industry was the music we were consuming, the experiences through the live art form. And in the startup world, that end product is the success and the ability to scale a real solution that this company has solved with amazing, talented people. So to me, it was a nice, easy transition, and it made sense.

+ +

CHAD: Are there ways in which it's different?

+ +

MONIQUE: Oh my goodness, yes, lots of ways that it's different. The difference is that music is an art form. For me, music is the universal language. I believe that I've traveled the world. And I've been to places where there were language barriers, but when a song, a popular song, came on, the language barrier was gone. In the startup world, there may be several people trying to create and penetrate a problem area in a vertical or a category. And we may not have the ability in the startup world to have several of the same sounding things from a business model. They may not all work.

+ +

And so you're dealing with the emotional capacity on the music side. And on the tech side of things you're truly dealing with, can you really solve this problem? We're solving problems, not just emotional connections from the music industry perspective. And also, it's a lot slower moving. We have a project in the music industry, and it may have a cycle. And now it's an even shorter cycle with technology. You may be able to create an entire project in just a couple of weeks.

+ +

In the startup world, in the business side of things, you may not see the development for two to three years. So the patience is definitely...I've had to apply a lot more patience and understanding of being able to scale a business versus just a project-driven entity. So it's a little different, but the end result is all the same. Creating real great solutions for real problems, whether it's through an art form or whether it's through a business model, is all similar to me.

+ +

CHAD: So, do you have a particular investment strategy or focus at Reign?

+ +

MONIQUE: We do. Erica and I currently we are the largest two female Black-owned VC fund. So one of the things that we felt ten and a half years ago when we started investing together is investing has just been done...venture has been done wrong. There's a reason why less than 3% of funding collectively was...still to this day; it's about 3.2. But over ten years ago, when we started, only less than 3% of funding from VC was going to women, all women, and Black and Brown founders.

+ +

And so literally, we were like, the problem is that we're not having enough investment or a lens on women and people of color. And we want to do it the way it should have always been done: investing inclusively. We are proud to say that we invest in all founders, all exceptional founders. And yes, we have a lens on women and people of color because they've been under-capitalized and under-resourced and under-everything. And so the reality is that we want to set the tone of how it should always look and the world is inclusive. Diversity is not an issue; the equity and inclusion side is an issue. And we want to keep being that example.

+ +

CHAD: That's great. Do you feel like, or in your experience, have you found that these founders were already out there and they just were being passed over? Or were the problems so systemic that they weren't even getting the opportunity to even be out there?

+ +

MONIQUE: I think there are always exceptional people out there; that's number one. And I think it's a two-prong problem: yes, the pipeline, the access. So there's the lack of access for these types of founders that has absolutely been an issue, the lack of resources, the lack of access. But the other side of it is that they have just been overlooked and not allowed into the rooms. There are exceptional people in this world that don't only look like one type of person. And the reality is that we have access to them. And so yes, both of those are an issue, okay.

+ +

But the reality is that we have exceptional founders of all types of people. There are amazing people in this world. When you sit behind a computer, and you run an algorithm, and you only go to only your network of what looks like you and comfortable, then you are what we call missing out on a ton of opportunity. So Erica and I are founder-friendly. We go where the founders are.

+ +

CHAD: I've come to learn and understand representation really matters. Being able to see yourself is really important. And it's something that because I look like what I look like, I had the privilege to not realize how important that is because there are so many people in power that look like me. I can imagine it's super refreshing to a lot of the founders that you work with to be talking with you and sitting across the table from you and seeing that and talking to someone that understands them.

+ +

MONIQUE: Yes. I think that having someone to relate to on all levels, personal, professional is a very important concept. And I remember starting my career at USA Today; not only was I different in age because most of my colleagues were 40-plus, and I was in my young 20s, they were mostly male and definitely particularly only Caucasian. I was the first African American executive on the marketing and sales side. And I remember feeling very isolated and very lost and not knowing who I could turn to that would understand some of the things I was actually going through.

+ +

And so yes, founders, it eases the founder's mind when they can talk to me and know that hey, I didn't always look like this from this perspective. I grew up in income-based housing in New Jersey. I understand where you come from. Yes, I understand what it's like to be a Black woman; I am one.

+ +

But also the other side of it is that when we have founders who are Caucasian male. We like to have conversations of inclusion from the ground up with them. "Did you think about this consumer base? Do you know that you might have to message different?" These are things and conversations that people are not having if you're only talking to one type of person. And so, I think that what Reign Ventures is doing is allowing for comfortable conversation and then execution.

+ +

CHAD: That's great. You started with a $25 million fund in Reign, and you're well beyond that now, right?

+ +

MONIQUE: Yes, yes. So our current fund is a $50 million fund, and then our next fund will be...we're going for the stars and trying to raise $100 million.

+ +

CHAD: Wow. I've talked to a few people who are either interested in starting VC or who have done it before. And what do you use to judge how much or how large of a fund you'll be building?

+ +

MONIQUE: So we like to think of what we want the outcome to be. And so, the long-term goal of Reign Ventures is to have a billion-dollar under asset management. That has not been done by two Black females before. And so we understand if we do that, if we look at the long-term goal, if we do that and count backwards, here's what it will take to get to that billion dollars under asset management. So yes, the size of the fund will have to increase.

+ +

But we also know that that means we're creating amazing companies and supporting amazing founders with Reign Ventures. And so we look at the size as our ability to have a larger stake and the ability to have follow-on capital for all of the companies that are doing amazing. I would tell anyone who is looking to start a venture fund that Erica and I (Erica is my business partner.) she and I started and wrote our thesis over ten years ago.

+ +

And we actually deployed our personal capital for the first nine years so that we could create a data room and so that we could understand what it meant and felt like to have skin in the game so that we can learn truly where we sat well with a thesis. And it ended up being we do really well with consumer tech and SaaS, you know, B2B SaaS software.

+ +

And so, I would say that it's not an easy journey to start a venture fund. Truly understand what you want your thesis to be. Truly understand that you're going to hear the word No way more than you will hear the word Yes. This is someone else's investment. This is accountability. And try it and understand it before you just start raising money.

+ +

CHAD: You sort of alluded to this earlier; you said increasing the size of the fund is going to allow you to make bigger investments and follow-on investments. So do you also see you investing in more companies?

+ +

MONIQUE: So we like to have a 20 to 25 cap strategy per fund. And what we do is we take 25% of the capital for the earliest investment, and then we save 75% of it for the follow-on round so that we maintain our equity stake. Because we're founder-friendly, so we always want to be in that board room. We always want to roll up our sleeves with the founders and so maintaining whichever early equity we have, which is usually the way the fund is structured, between around 10%. It allows us to not just do more companies; it actually allows us to really double down on the portfolio itself and make sure that we're staying and growing with the founders.

+ +

CHAD: How involved are you? Are you personally involved? Do you split the portfolio up, and each person takes a few? Or how do you typically do it?

+ +

MONIQUE: We truly, truly do take my 25-plus years in the music industry. We take that very bumper system approach of we're here to help develop the raw talent and, on the tech side of things, the actual founding team and the evolution of the company. And so I usually take the board seats.

+ +

Erica, she comes from finance, and she's been doing finance banking for over 25 years. She's been doing early-stage investing for 16 of those years. And so, she helps with the finance cap strategies. How do we get you from your seed stage to your A in 12 months? How do we get you from your A to your B? So she's very, very involved with the financial models and running several of those and working with the founders on who's on your cap table? Okay, so intentionally and strategically, who's missing from your cap table? Let's work on that.

+ +

And then I'm always the one working on taking the board seat. I'm the one working with the vision, the strategy. I'm an operator, so I have a most extensive network. And so I'm the one aligning them with our resources, our network. And you know, yeah, we're very, very involved.

+ +

And I think that when you're dealing with seed-stage because that's the stage we're in, it's the riskiest. We try to de-risk the company, the founder, the founding team as much as possible. So we are as involved as the founder wants us to be. We do not make founders feel guilty for not having the largest team. We're like, "Okay, what do you need? Let's get you that." And that's where we like to play. We don't see ourselves going into anything past the seed stage.

+ +

CHAD: Is there a limit to how many companies that you're able to personally work with? And how do you scale, Monique?

+ +

MONIQUE: So the cool thing about our fund is that all of the companies are intentional. Half of our companies are consumer tech. So they mostly need pretty much the same type of things, even if they're in different verticals. The other half is SaaS. And so the reality is that they're in different stages. They're growing at different stages. And we, first and foremost, create a founder community that supports each other. That's number one.

+ +

Then we have an LP community that supports not just Erica and I but our founder community. So we look at investing as from a holistic community. We drive community, and that is the way that we're able to actually still have a sustainable business model with Erica and I. And we have a team. We don't do anything by ourselves. We have an entire team dedicated to the growth of our portfolio companies.

+ +

CHAD: Speaking of that team, what does that team look like now in terms of the different roles on it? And how big is it?

+ +

MONIQUE: So currently, right now, we have about four full-time. And then, we have a couple of interns who work on the data science side. And then we also have in-house from just Monique from my particular business model side; we have an HR. We have financial operators, and then we have contractors and partners. And so, at the end of the day, there isn't anything that our founders need that we can't source for them internally or externally.

+ +

CHAD: Who was the first person you brought onto the Reign team, and why?

+ +

MONIQUE: Her name is Naya, and she actually has worked for me on my foundation side for a few years. She's was an engineering student at University of Miami. And once she graduated, she was now getting her Master's in Data Science. And we felt like being able to report properly on our founders, the companies that were applying that we actually could not invest in but were investable, we'd like to keep track of that. And so, we felt like having someone who could really handle the data side of Reign Ventures was one of the more important hires.

+ +

And then, we also hired a full-time social media person who handles the content. We have a monthly podcast called The Series A. They oversee that so all communications on our portfolio companies and Reign Ventures as a whole. So those were the first two hires. And we're currently prepping to hire for the summer a full-time associate that will be out of the New York office. We have offices here in Miami, across from the University of Miami, and then we have offices in New York.

+ +

CHAD: That's cool. The data aspect of that is super interesting to me because I think that I talk to a lot of people, and a modern VC firm is certainly doing that. But there are still ones out there that don't have that data-forward approach that it sounds like you do.

+ +

MONIQUE: Well, we need to make sense of all of this. So we need to make sense of the idea of how many founders are applying? What is the demographic makeup of them? Who is this founder? Where are they coming from? What markets are they coming from? Because we do invest just only in the United States. And we pretty much invest in all markets here. We'd like to keep that data.

+ +

And most importantly, we are over-communicators with our LPs. So we're sending them monthly updates. Carta is updated every, you know, they have access to that. So we'd like for them to understand what our day is looking like. How are we spending our time? What type of founders are coming to us? Hey, you all don't necessarily have access to these founders, here's why we do. And so all of this information is important. You have to make sense of who your audience is. And for us, our audience are the founders.

+ +

Mid-Roll Ad:

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: You mentioned that you invest in people in some ways as much or more than you do the idea that they have and really work with them. How far along will people typically be with their product when you start working with them and investing in them?

+ +

MONIQUE: The way that the investment cycle is, you know, your family and friends, then your angels, and then sometimes even your super angels will come in after that. Then you have your pre-seed, which is usually where you're testing product-market fit, et cetera. And then we step in at the seed stage, which is founder market fit, you know, product-market fit, a billion-dollar addressable market.

+ +

You understand your operational strategy, where you're going to raise less than 50 million, and if you're not, you have that strategy of why? And definitely more than just an idea at that point. Now you just need to raise this round, to hire on more team, and then scale. So for us, that's how our due diligence works.

+ +

And if you make it through that due diligence, then it becomes about who is this founding team? Will they be able to deal with adversity? Because you're going to have it. Are they coachable? What is their leadership style? Is it an inclusive environment? You can't be creating an equity company, and then all the team looks the same. So these are the things that we're looking at.

+ +

What is your personality type? We like to spend time with our founders. How will you deal with the stress because the stress will come. Is your mindset the glass is half full or is it half empty? All of these things are important at the seed stage because it's not the growth stage where it's automatic it's happening. The seed stage boils down to can you deal with adversity?

+ +

CHAD: I imagine you reject a lot of people.

+ +

MONIQUE: Ooh, I would say that we use a different term. We are not dream killers.

+ +

CHAD: Okay. [chuckles]

+ +

MONIQUE: Here's what we say: we have an open-door policy with founders. We allow founders, even the ones that are not ready for investment or that we've actually had to pass on investment. And the thing is that we can only do 20 companies. That is where we'd like to sit, 20 companies per fund. And if for some reason, it's not a company that we invest in, we still give them access to our resources. We still give them access to our network. We still will spend…I mean, every Friday is our Founder Friday, and it fills up very quickly.

+ +

Erica and I get on with founders who are not in our portfolio because just because they weren't a good fit for Reign Ventures or it was something that we could not do, maybe it did not fit the fund's structure; we also try to align them with investors that might fit them more properly. And so I don't feel like we reject; we just redirect.

+ +

CHAD: So given that then, I imagine that you are often pretty open with the companies that you're not able to invest in the reasons why and hopefully, it helps them.

+ +

MONIQUE: Oh, absolutely. We get founders all the time that say, "Listen, this was the best thing. Prior to coming to you all, we weren't able to raise $1. You didn't invest in us, but you taught us how to be investable, and now we've raised money." That's what we want to hear. None of us win if there's really a great company with a great solution that can really have some traction if they never get up and running.

+ +

CHAD: That's great. And maybe you get the opportunity to invest in them later, right?

+ +

MONIQUE: Yep. Absolutely. Absolutely. There are a couple of companies that that has happened. And one of them is now back in our due diligence and probably will make it through.

+ +

CHAD: Yeah. Are there any companies in your portfolio that you particularly want to give a shout-out to?

+ +

MONIQUE: Oh, we love all of our portfolio companies.

+ +

CHAD: [laughs]

+ +

MONIQUE: You know, Sharebite, Dormify, SoLo Funds. SoLo Funds is one of my favorite companies from the perspective of dealing and disrupting predatory lending. As a person who grew up in a neighborhood that liquor stores and cash checking were like every other block, if not on the same block, we truly do know the long-term effect it has on those communities, right? The underserved communities get so taken advantage of. If you don't have $200 and then you go to a predatory lender, and you're paying them $2,000, how do you ever advance? And so SoLo Funds really, really the only Black-owned B Corp in the United States.

+ +

CHAD: That's awesome.

+ +

MONIQUE: This narrative is so important, Chad.

+ +

CHAD: Yeah. And, you know, not only is it important from a social perspective, but that is a huge business. It's a huge market opportunity for the right company with the right values to come in and be able to have a significant business, too, right?

+ +

MONIQUE: Listen, they're making the whole ecosystem better. For the lenders, listen; they feel good. They're having a positive social impact. And oh, by the way, I'm getting a return. For the borrowers, they are getting financial literacy. They are getting higher social credit scores, which is then impacting their personal credit score. I mean, listen, by the way, when this company was created, over 76% of Americans, if they were hit with a $200 bill, they were not going to be able to pay it. So this is not just about one type of community. This is about the American concept.

+ +

CHAD: So when you work with a company like that, were they a B Corp when you started working with them?

+ +

MONIQUE: No. True story, I was literally personally the second investor in and then the third before there was ever even...So Rodney Williams is the Co-Founder of SoLo Funds. And I'm on his board for LISNR. We were one of the first investors in LISNR, which is the data over audio company. And he shared this idea with me, and I loved it because we all come from a neighborhood where we know and we were the ones who quote, unquote, "were doing better" in our families. So we were always getting the daily calls like, "Oh, my car broke down. Oh, this." And when he said this to me, I'm like, "Oh my goodness, this makes so much sense. I'm in."

+ +

And see, this is where investing in people comes to play. Rodney had proved his ability as a founder with LISNR. So the trust was there, the relationship was there. Travis comes from banking, super, super intellectual, really quality guy, and not only is he the co-founder, but he's the CEO. And he's doing an amazing job. So no, it was not a B Corp; it is now one. And they will be the largest neobank for this community. And so growing and seeing the cycle of it is what, for me, personally, is what makes me happy. All of our companies in our fund have a social impact perspective.

+ +

CHAD: Had you been involved in a B Corp before? It's something that I'm really interested in, but I have not been directly involved in one before. And I'm actually really interested in it for thoughtbot too.

+ +

MONIQUE: No, I had not. No.

+ +

CHAD: Is it difficult? [laughs]

+ +

MONIQUE: So was it difficult for them? Absolutely. But they made it through. They made it through. And I think that we now have two men who are great human beings who happen to be Black men, but they are just great human beings who went through the process and can now help educate and share that experience with other people that look like them and are trying to do the same thing as them, create great companies with a great social impact to just have a better world.

+ +

CHAD: From an investor perspective, when your portfolio companies want to embark on something like becoming a B Corp, which, you know, some investors might look at and say, "That might be a distraction from what you need to do now," how do you look at those things?

+ +

MONIQUE: I mean, listen, if you want to become a B Corp, you actually are trying to have more of an impact, and I wish more companies were. When we actually are only focusing on the dollar side, the stakeholders of the dollar side, how are we truly making sure that we're impacting the world in a positive way? There's a lot of conflict usually.

+ +

So we encourage that type of behavior; we encourage founders to think beyond their dollar sign and their stakeholders' dollar sign. The good thing is that they had an amazing team supporting them. They had an amazing A series lead investor, ACME, that really drove it with them. And so they did this. We didn't do this. They did it. This was their mission, and they did it.

+ +

CHAD: That's great. And it's definitely something that's on my list to dig into more, like I said, for thoughtbot as well. So was it 2021 that you were on Undercover Billionaire? Was it last year?

+ +

MONIQUE: Oh my goodness.

+ +

CHAD: Or was it the end of 2020?

+ +

MONIQUE: So it was the end of 2020, yes. [laughs] Tacoma, Washington.

+ +

CHAD: Yeah. So for folks who don't know, Undercover Billionaire is a TV show where you give up all of your resources, and you're planted in a city, and you start a business from scratch. And you have what? Ninety days to bring it to a million-dollar business?

+ +

MONIQUE: Yes. So technically, the premise of the show is you literally get a new identity. And you do not know where you're being dropped literally until you're dropped there. And so, I had no idea I would be dropped into Tacoma, Washington. And one, they give you $100, literally, a phone with no contacts in it, and a used vehicle, and you have 90 days to turn that into a million-dollar valuation.

+ +

CHAD: It must have been a wild experience.

+ +

MONIQUE: I have to tell you, the emotional connection that has to happen and then also by the way you're lying to everyone, it was a very intense thing. And most of the time, 99% of time, you're running on adrenaline. And to be completely honest, when I first got there, you're focused on the goal. The goal is can you make this valuation? The goal is I can't be the example that didn't make it right. Then when you get there, it becomes less and less about the goal.

+ +

You actually get to a point where you don't even care if you make the goal. You care about the community that you've been dropped into. And you just want to see them win, and you want to see them become better. And Tacoma, Washington, everything from the mayor, down to now to one T'wina Nobles, who is now the Senator, the youngest senator in the state of Washington, these amazing people were a part of my journey.

+ +

So it became all about, wow, at the end of that experience, that last show, and I look at the room of all those people, it was the most inclusive experience naturally. That's what the win was for me personally. And I also got to learn about myself. But I will tell you that it was one of the hardest things I've ever done in life outside of having children and raising them to be healthy adults.

+ +

[laughter]

+ +

CHAD: Not only to build the business, you mean, but that experience of --

+ +

MONIQUE: Just the entire experience.

+ +

CHAD: I watched the episode where you told everybody who you really were.

+ +

MONIQUE: Yes.

+ +

CHAD: And I could see that it had really affected you.

+ +

MONIQUE: I was lying to people every single day. And these people were so amazing. They donated their time, their resources, their ability to me because that company could not happen without them and without the community. And so, what we all walked away with was a shared experience of how powerful community actually is. And that even when you don't know how to figure something out, if you use your voice, someone will actually help you and you end up all helping each other. For me, that's what was so beautiful about the experience.

+ +

CHAD: I imagine it's pretty intense. How quickly did you force yourself to settle on the business you were actually going to build?

+ +

MONIQUE: It's so interesting because I have been asked like, "Did you create the concept before you went?" And I said, "Actually, no," literally, I went into it with a blank mind of wherever I end up, I want to see what they need, and we'll create a business model around that.

+ +

So I think it was like day four of being in Tacoma. And I was in an area that was a food desert for the most part. And I'm like, listen, I'm talking to people, and they're like, "Oh yeah, we have to order juice shots. They have to get shipped. Or we get the ones that are, you know, sitting in the grocery store, and that's not a lot of options."

+ +

And I'm like, wow, this is a problem. And I'm like, let's reimagine the ice cream truck. Everyone would like to think that the wealth gap...that if you make money, you care about your health, if you don't make money, you don't care about your health, actually, no. [laughs] I grew up in a natural home, and we lived in income-based housing growing up. And so the reality is that everyone wants to be healthy.

+ +

People need more access to healthier options at an affordable rate, and people will buy it. So the question was, oh, Monique, you can't sell juice shots for $5. Yes, we can. You think a community just because they're underserved won't pay for their health? They absolutely will if you give them the option to. We always sold out in the communities that they said would never sell.

+ +

CHAD: So up against a ticking clock, what did you do to sort of validate the idea and really run with it, or did you just know?

+ +

MONIQUE: No, you don't just know, right?

+ +

CHAD: Yeah. [chuckles]

+ +

MONIQUE: You're literally working on adrenaline. Listen, there was nothing normal. We all know this as business owners; there's nothing normal about this concept. You can't create a successful business in 90 days. So you're literally in overdrive: no sleep, multitasking, doing all types of things. Here was the thing; first of all, I talked to the community. I asked them what did they need? What were they missing? If they had access to something, would they utilize it? That was number one.

+ +

Number two was testing it. So I started making samples. And I went out to the community again and started testing it. Three was of the test that did good; let's run with that and package that up. And you have to understand, Chad, it was the height of the pandemic. Everything was shut down. You know, I live in Florida, so we weren't like that. But going to Tacoma, Washington, nothing was open. So I had to think, how do I get to people because they're not coming and cannot come to a brick and mortar?

+ +

So the only thing that was pretty much open was the farmers' market. So that's what I did. I'm like, let's get to the farmers market. And also, let's see how we become mobile, oh, the ice cream truck treats. Let's teach people that healthy treats are actually what they crave.

+ +

CHAD: I think even though it was accelerated, intense, the things you're talking about doing in terms of validating the idea, actually talking to customers, testing things out, those are things I think people want to do in any situation.

+ +

MONIQUE: It is absolutely true. We talk to founders all the time, and it's the I, I, I. And we tell them, "Well, have you talked to your customer?" Sometimes we're so close to our ideas because we hold them, and we're trying to solve a problem maybe that we experience. That's step one. But step two is, is it something that other people want and need? So you definitely have to go out there and do market research.

+ +

CHAD: Are there other things that you counsel founders on doing? Particularly with the seed stage, you know, on the verge of significant growth and scaling, what are some things that are maybe common plays or common pitfalls of companies at that stage?

+ +

MONIQUE: So some of the things that we see, especially with solo founders, is them having this idea that only they can do everything and not understanding that you actually have to have a founding team. And that does require you to give some equity. We see founders wanting to hold on to everything. And then it becomes do you want 100% of something that's very restricted, or do you want to share it and make it something really special and a part of a billion-dollar concept? So that's one.

+ +

Two would be founders in need happen to take money without understanding that it is a debt that even if it's fundraising and you're raising institutional capital, these are your investors. These are your partners. And is it a good partnership? We have seen a lot of founders in contractual and legal documents because they went and took money from the wrong type of investor. We see that --

+ +

CHAD: And they did that because they were desperate at the time?

+ +

MONIQUE: They were desperate. They were desperate. They were desperate and for just really crazy, contractual things. They don't have attorneys look at the paperwork. We see a lot of these mistakes. And so we tell founders you have to have a step back from your business. You have to look at all types of options. Have you applied for grants and particular grants in areas of the problem that you're solving? Have you tried for Small Business Association grants? Have you tried to get a credit line versus an investor who's now going to have equity? These are all the things.

+ +

And if you do need investors, don't take all the same types of investors. If every investor in your cap table is a bean counter and the numbers aren't playing out well for them, what type of board meeting is that going to be? So make sure you have an operator who's on your board. Make sure you have a financial person, investor on your board. You have to be very strategic and intentional. And if you're in a desperate moment, I can guarantee that is not when you want to take the money that you actually need to do a deeper dive and step back from the company to really see what the company needs.

+ +

CHAD: Monique, I feel like that's great advice. The level of experience and passion that you have for the work is obvious in listening to you. It makes me want to work with you. [laughs]

+ +

MONIQUE: Oh, thank you, Chad. Yes, I'm very impressed with what you have built. And I'm very impressed with you understanding the ability to give access to information to your audience. Here's the thing, we are products of an environment of capitalism. And there's nothing wrong with capitalism, but it just needs to be a lot more conscious. And it needs to have a much better impact for all. The problem with from our childhood age of education is we've been taught that there's only one, there can only be one winner. There's only one first place.

+ +

We have to take that mindset back and really step into the power and the power that we truly have, which is abundance. There's enough for us all. We just have to give that power back to it. And the reality is that we all need each other, and we all need to build together. And people just need access to information.

+ +

Most founders tell us, "I was embarrassed to ask that. I was made to feel like I was supposed to know this, so I just went ahead and pretended like I knew it." It's okay that we don't know everything. In fact, I like to sit in that space of student and say, "You know what? I like to be in the room that I actually don't know anything because then that means I'm learning, and it's okay. We better keep learning."

+ +

One of my favorite quotes is, "We delight in the beauty of the butterfly but rarely admit the changes it has gone through to achieve that beauty." And Maya Angelou wrote that, and she understood the human spirit needs to understand that no matter what career path we're on, Founder, CEO, employee, employer, no matter what that is, it is a constant evolution of self. And sometimes we'll feel like a butterfly, and sometimes we will have to be in that learning and growth and uncomfortable stage. But the beauty of uncomfort means you're growing, and we have to make more people feel comfortable with that.

+ +

CHAD: That's beautiful. Monique, thank you so much for coming on the show and sharing with all of us.

+ +

MONIQUE: No, thank you, Chad, for having me.

+ +

CHAD: If folks want to get in touch with you or find out more about Reign, where are all the different places that they can do that?

+ +

MONIQUE: So if they want to contact me, they can email me at monique@reignvc.com, which is R-E-I-G-N-V-C.com. We're on LinkedIn; we're on Twitter; we're on Instagram. And if they want to learn more about Reign VC, they could just go to reignvc.com. And if they have any questions, they can submit it, and we'll get back to them.

+ +

CHAD: Wonderful. And you can subscribe to the show and find notes and a full transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm, and you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Monique Idlett.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8ca9woIb + + ]]> + + Chad Pytel + Monique Idlett + + + 422: Verge HealthTech Fund with Joseph Mocanu + https://podcast.thoughtbot.com/422 + fe98ba80-d4d6-4816-8db3-3f6a5c1264ec + Thu, 12 May 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Joseph Mocanu is Co-founder and Managing Director of Verge HealthTech Fund, which invests globally in seed-stage healthcare technology startups relevant to emerging Asia that focus on disease prevention and management, digital therapies, and health system efficiency. + +Chad talks with Joseph about the healthcare landscape in different places of the world, funding criteria for companies, and how the pandemic has changed prospects for the fund and the market in general. + 36:52 + no + + + Joseph Mocanu is Co-founder and Managing Director of Verge HealthTech Fund, which invests globally in seed-stage healthcare technology startups relevant to emerging Asia that focus on disease prevention and management, digital therapies, and health system efficiency. +Chad talks with Joseph about the healthcare landscape in different places of the world, funding criteria for companies, and how the pandemic has changed prospects for the fund and the market in general. +Verge HealthTech Fund (https://www.vergehc.com/) +Follow Verge HealthTech Fund on LinkedIn (https://www.linkedin.com/company/verge-healthtech-fund-i/). +Follow Joseph on Twitter (https://twitter.com/jmocanu) or LinkedIn (https://www.linkedin.com/in/jmocanu/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Joseph Mocanu, Co-founder and Managing Director of Verge HealthTech Fund, which invests globally in seed-stage healthcare technology startups relevant to emerging Asia that focus on disease prevention and management, digital therapies, and health system efficiency. Joseph, thank you for joining me. +JOSEPH: Thanks so much, Chad, for having me. +CHAD: So you have been focused on emerging Asia healthtech for a little while both at Verge HealthTech Fund, and prior to that, how did you get involved in this space? +JOSEPH: I wish I had a really cool, deliberate story that made it sound like it was a smooth transition from point A to point B. But I simply have to owe it to an opportunity to transfer to the region through my old employer which is Oliver Wyman, a global management consultancy. So I joined this consultancy in 2011 after doing my Ph.D. and MBA really to understand how to be a better investor, which, again, sounds a little bit backwards. +But I had worked at a hedge fund in China just after my MBA, and I learned that they use management consulting techniques to add value to their portfolio companies. And I thought that's a great skill to learn. And it'd be great to even learn it in English and doing it in healthcare 100% of the time. +So I had joined Oliver Wyman in 2011 in Toronto office back home, where I spent a lot of my life. And they asked me one day if I wanted to transfer to the Singapore office to help start healthcare over there. And when I went to Singapore, of course, it's this futuristic city, really well planned. It's got a lot of fine names and a reputation globally of being a modern cosmopolitan place to do business. Some people refer to it as Asia-lite. But the surrounding areas have a lot of issues when it comes to their health systems. I knew this from an academic perspective, having studied about the region before moving to Singapore but seeing it firsthand was a completely different experience. +At the time, I was working for primarily pharmaceutical clients, helping them with market access and other commercially relevant activities. And they were faced with a fundamental challenge of trying to sell their product, which was usually placed in the premium category to markets that had difficulty affording this. And not only did it have difficulty affording this, it had difficulty in delivering it as well as in using the product appropriately, making sure it gets to the patients when it's needed at the right time, at the right dose. And so they were looking for partners. They were looking for partners on the ground that could assist with this delivery education, the technology, and the financing around it as well. +Now, there was a real shortage of said partners on the ground. At the same time, there were also insurance companies that wanted to expand their business. They also realized that the policies tended to be a bit simple, and they tended to resemble one another across competitors. And also, to manage increasing claims, they had a tendency to increase the premium that they charged. This was not possible to do indefinitely. And at some point, they needed to actually manage the medical conditions, which you're probably seeing more and more of in the U.S. and in Western markets, less so of in this part of the world. +And then lastly, you had conglomerates and investors who said, "Hey, we hear healthcare is going to be a pretty hot field. How do we get started? How do we invest?" And all of this basically set me on a mission of target hunting. And during the course of this, well, I met a lot of interesting companies, a lot of them really, really early in their journey and really too small for any of my clients to find a meaningful way to engage with them. And unfortunately, they couldn't get to the point where they are relevant and large enough to engage with without a lot of capital. +This is where, you know, you'd have a nice investment ecosystem coming in to fill in the gaps. This, unfortunately, did not really exist at the time. And I had the hubris of thinking that I could do something about it by being an angel investor and starting to support these founders directly, which, thankfully, seemed to work to a certain degree. It worked to the point where one day, I woke up, and I realized I had 13 angel investments, 9 of which were in healthcare technology, and not a lot of money left in my bank account to do other things with. +CHAD: Uh-oh. [laughs] +JOSEPH: Yeah. And at the same time, I also realized that the work that those founders are doing is a whole lot more impactful than me sitting up until 3:00 o'clock in the morning every night writing PowerPoint slides or begging analysts to write the PowerPoint slides that would more or less sit and collect dust on my clients' shelves for various reasons. So I came to the realization that I need to do this full time. +I didn't have, you know, $10 million in my pocket as reference to spending all my money on angel investments. So I realized that I have to use other people's money, and the way to do that is to join a fund. Now, the problem with that idea is that there weren't any funds that were doing this, like really, really early investing in healthtech companies in the region that was really geared to helping solve some of these really big access challenges. So then I realized I had to start a VC fund that did this and only this. So that's really kind of a long-winded introduction as to how I got started with this. +CHAD: Yeah, I want to come back to the process of actually starting a VC fund in a bit. But I'm curious, were the companies that you were doing angel investment in and now doing seed-stage investment in do they tend to be local companies, or do they tend to be international companies that are planning to solve a problem locally? +JOSEPH: It's funny you ask that. At the beginning, they were local. Well, actually, if I really were to take a step back, the very first angel investment I made was for a mentee, and she was based in Toronto. But I'd say that the first true angel investment I made, you know, it was in Singapore, first and foremost, because I was there. And then I started branching out. I started making investments in the Philippines. I started looking at companies in Taiwan and other parts. +And actually, that opened my eyes to the fact that there may be other companies around the world that are trying to solve a problem that may not necessarily be in my own backyard. So I started to, you know, cheekily, I sent my wife to tech conferences around the world. And she herself is an entrepreneur from the tech industry; hardware was her specialty. And we started identifying companies from all over the world. And the second angel investment where I was the very first investor was actually from a company in South Africa with similar challenges. +So the things that we saw as major health system deficiencies or maybe shortages in infrastructure and human capital were very much true not just in Southeast Asia but in a lot of parts of the world. And we noticed that while there were different reasons for why they ended up in that position, the outcome was similar. +CHAD: I'm not sure that everyone listening has a good sense of what the healthcare landscape actually looks like in these different places of the world. So let's take insurance, for example; what is the insurance landscape, generally speaking, in Southeast Asian countries? +JOSEPH: So, in Southeast Asia, we do have insurers. I mean, private insurance is certainly there. But it's just not -- +CHAD: Do most companies have public insurance, too, like universal healthcare? +JOSEPH: That depends on which country you're in. Now, the one interesting thing about our entire region is that they've all committed to universal healthcare coverage. I would say that the implementation thereof has been heterogeneous; let's put it that way. Out of Southeast Asian countries that are not Singapore, I'd say that Thailand probably has the strongest public healthcare system. And in fact, they even do health technology assessments, which is really looking at the true cost-effectiveness of a new intervention versus what's currently done in practice to make decisions as to whether they're going to pay for it. And they cover a pretty high percentage of their population with this. +And then there are other places where the financing mechanisms are in place, but you don't necessarily have the doctors or the hospitals where they need to be to address the needs of the population. Still, we are dealing with places that are not fully urbanized. And in fact, a good deal of the population is still working on the pharm, basically. +One of the other complexities of our region is that just between the Philippines and Indonesia, which together has a combined population of 380 million at least, maybe it's 390 now, you've got 25,000 islands, and not all of those islands tend to hold major tier-one cities, even though they can hold a lot of people. And if there is one thing about healthcare that seems to be a universal truth is that highly skilled workers like to live in the rich cities. +CHAD: And so what I'm hearing is that on an individual island, if there's not a major city there, the access to the actual healthcare might be really limited. +JOSEPH: That is exactly it. +CHAD: In these economies in these countries, it's typical to have private insurance layered on top. But the pharmas probably aren't doing that, right? +JOSEPH: Oh, no, no, unfortunately not. There are some pilots of trying to do co-ops or collective insurance or micro-insurance policies. But again, when you look at the amount of premium that they could pay in, the kind of coverage they get is pretty basic. +CHAD: So, how does that landscape influence the solutions that startups are creating? +JOSEPH: Well, first and foremost, you've got to try to get some sort of mechanism by which you can seek care without having to travel too much. And I think that concept is extremely familiar to all of us thanks to the global pandemic that I hope we're coming out of right now, although there's always a new strain surprising us. +The idea of basic telemedicine is one that can have a great deal of impact in these populations. But even before that, just understanding the importance of healthcare, like, what the concept of healthcare is, what the concept of the modern medical system is, is something that a fair number of people never really had awareness of. +And I'll call out an example country, and I try not to call out too many examples. But Indonesia did a really good job of educating people about the concept of healthcare when they promoted their universal healthcare coverage. Even if they didn't have the ability to deliver it as well as they wanted to or as widespread as they wanted to, at least they got people paying attention to this concept called health. So awareness is really the first step. +The second challenge is all right, so you know health exists. When do you know when you need it? Where are you going to find a doctor? How do you know if a doctor is even good? And how do you know that the products that you're going to get are appropriate? So there are so many challenges that you have to face when you are in a lack of access situation. +CHAD: I assume you're getting pitched on a lot of ideas coming to your fund, a lot of startups. Correct me if that's wrong. [laughs] +JOSEPH: No, no, that's absolutely true. So one of the blessings and curses of being one of the very few super early-stage healthtech venture funds out there is that there aren't many of us out there. And when we started...let's just put it this way, if I could find a fund that was doing what I wanted to do, I would have sent my CV in, and I couldn't. +And starting a fund was basically the last thing I wanted to do, having never worked at a VC before or ever raised money in my life before. So I still think that we are the only truly global impact-oriented seed - I hate the term pre-seed, but I'll use it because of the audience's familiarity with it- investment fund out there right now for healthtech. So by virtue of that, we do see a lot of companies. +CHAD: So what are some of the criteria? +JOSEPH: So I'd say some of the criteria that we look for is number one, are you solving a real problem? And we define a real problem by the breadth of the problem, like, how many people are suffering from it or how systemic is this problem if it's an infrastructural one? And depth being how severe is this problem: is it life or death, or is it a minor inconvenience? So first and foremost, it's got to be solving a real problem. +Second, it's really around the team. You need a lot of clinical, technical, and commercial experience in order to pull off a healthtech startup successfully. And even before that, we want to understand why are you doing this? Because this is not easy. I'd say on a scale of 1 to 10, doing a startup is like an eight, and then doing a healthtech startup is like an 11. It's slow; it's technical, it's regulated, it's super risky. +And health systems are very pathway-dependent in the intent to not have many things in common with one another. So it is really, really hard. So we want to know the motivation. Are you going to stick through the thick and thin, or are you doing this healthtech startup because you think healthtech is cool or hot this particular period in the market cycle? So that's another criterion. +Another criterion is, well, what's your edge? I mean, okay, you can have a great team, and I think that is definitely a prerequisite. You can solve a problem. But do you have something that could make sure that you are going to be competitive and remain competitive? +CHAD: Given the barriers to market entry that you just outlined, do most of the companies that you're investing in have any sort of traction already in the market, or where are they in the product development or business development cycle? +JOSEPH: I'm going to give the ultimate cop-out answer of it depends. +CHAD: [laughs] Yeah. +JOSEPH: But I will qualify that by saying it depends on whether it's hardware or software, and it depends whether it's regulated or non-regulated. So if you are a software company that's unregulated so, what does this mean? It could be like a marketplace. It could be health education. It could be some telemedicine in a loosely regulated market. We'd really like to see user traction. We'd really like to see revenue even. +However, if you're a device company and you need to get FDA before you can earn a single dollar, we're okay with it being a science experiment or a prototype on the table as long as the science part of it has been de-risked. So if we know that the fundamental scientific principles are sound, then we're willing to take the productization and regulatory risk because we've been through this journey ourselves. +CHAD: And also, you said a team is really important, so if it's a team that has never gone through that before, that's less attractive than a team that has done it before, I assume. +JOSEPH: Yeah, absolutely. However, one of the challenges is that outside of the U.S., certain European markets in Israel, it's really difficult to find a team that's gone through the entire medical device development process before. So you are going to rely heavily on your professional service providers, consultants, advisors, other investors who've done this before. And as long as you have at least a path to getting to a point where you can unlock and utilize that expertise, that's okay. But if you don't, then that's a really, really big risk. +Mid-Roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: Earlier, you said FDA. FDA is a United States thing. Do most countries in Southeast Asia have a local regulatory agency like the FDA that things need to be approved through? +JOSEPH: Yep, every single one. The question is, what's the process to go through that? Generally speaking, the FDA, as well as the European equivalent, which is the CE Mark, are used as predicates in order to kind of shortcut the process, make it go a little bit faster. Because then you don't have to create a bunch of new work or get the local regulator to really try to do things that they're unfamiliar with. +CHAD: You said it's fairly rare for teams to have concrete experience doing that in the local market. Does that mean that most of these markets have been served by, I don't know, large companies previously? +JOSEPH: Yeah, and still are. A fair number of emerging markets don't even have the manufacturing capability to even do local production, so they require a lot of importation. I'd say that this is a different case when it comes to generic pharmaceuticals and maybe vaccines and some consumables. But complex devices and biologics are generally manufactured in more developed markets or larger economies. +CHAD: Yeah. Well, you mentioned the pandemic, and I'm curious how the pandemic has changed either your prospects for the fund but also the market in general. +JOSEPH: I would say, again, it's both a blessing and a curse. So during the start of the pandemic, there was a great deal of societal and economic uncertainty around where are we going to be as a species in six months? And I remember early 2020; it was kind of these Hollywood movies that would paint this kind of semi-apocalyptic picture of where we're going to end up. And as a consequence, people really puckered up and stopped investing in things. +I would say that the other side of it is now much of the world understands what it's like to not have access to quality healthcare or even access to healthcare. You see people not going to the hospital for things that they ought to and then suffering the consequences at home, like, let's say, not going for that heart checkup, and then you having a heart attack at home and passing when you otherwise wouldn't have. Or even cancer patients having to delay their therapy because the hospital is just too full. +So this concept of telemedicine which has always been resisted by both the payers and providers for being infeasible, or inaccurate, or impossible to fund properly, suddenly had to be done. And the concept of telemedicine is fairly old. I mean, how else would you treat your astronauts in space in the '60s if they got sick? So this is something that NASA thought of and invented and implemented, you know, decades and decades ago. And finally, this came forward. +And I was pleasantly surprised to see...and again, I'll quote the U.S. here where The Center for Medicare & Medicaid Services or CMS actually reimbursed a bunch of remote procedure codes, which is pretty amazing. And I think that was opening Pandora's Box. There's no going back from that. +So I think telemedicine is absolutely here to stay. And the real challenge now is really how to make it more user-friendly, how to improve it, how to improve the decisions that come from it. I really don't think it's going back. And as a consequence of this, it's really benefited a lot of our startups that were trying to build this remote-connected future anyway. +CHAD: Has there also been an influx of those kinds of startups? +JOSEPH: Absolutely. I would say that there has been a veritable Cambrian explosion of startups where everyone and their uncle is starting a healthtech startup as well as a healthtech fund. I see a lot of new funds coming up promising to invest in this space. So I think it's good in that there's going to be a lot of really new ideas, and hopefully, it's going to improve the standard of care for everyone around the world. But at the same time, it is creating a lot of noise, and it's becoming increasingly difficult to filter through that. +CHAD: Do the solutions tend to be local? I guess the nature of my question was, you know, like messaging apps. [laughs] Different countries have different popular messaging apps. What do you see as the penetration of different telemedicine solutions in the different countries? Do you think it's going to be, oh, you know, this is popular in this country? Or do you think it's possible for one company to come in and really have a significant impact in the market across multiple markets? +JOSEPH: Yeah, I think it's eventually going to be the latter. So at the start, you do see that you have your national champions. And like instant messaging apps, it's kind of like a 90-10 rule where the number 1 player takes 90% of the market, number 2 takes most of what's left, and then number 3 player caters to some niche or another. And I see two competing forces here; one is, yes, there may be a big player like Babylon or Crew who comes in and rolls up everything backed by heaps of capital. +But the other thing could also be that all the health systems start saying, "You know what? Why are we working with an external company? Why don't we just develop all these capabilities ourselves and then keep the patient captive?" And you are starting to see middleware providers who are basically providing that telemedicine layer, white-labeling it, or giving API access to the providers themselves, the legacy providers themselves, and then allowing them to do that. +And I actually saw this statistic...I don't know how accurate it was, but I saw a chart in the U.S. that white-labeled or internal telemedicine consults exceeded the number of Teladoc consultations, which is the largest platform in the U.S., at some point last year. +CHAD: I'm wondering, do you know if Teladoc uses Twilio? +JOSEPH: I really should know the answer to that question, but unfortunately, I do not. +CHAD: Because my sense is the real winner in this game might be companies like Twilio because I think everyone is using them. [laughs] +JOSEPH: That makes a ton of sense. So when we do look at some investments, we actually want to invest in middleware because why duke it out to be the platform when you're the utility provider? +CHAD: So let's turn our attention to the actual creation of the fund. And I know you just opened your second fund last month, right? +JOSEPH: Actually, this month. I mean, last month was the paperwork, but it takes time for stuff to get approved. +CHAD: Yeah, fair enough. So you already said actually starting a fund was, I think you said, the last thing on earth that you wanted to do. Why was that the last thing you wanted to do? +JOSEPH: Frankly, it was a whole lot more uncertainty than I was prepared to handle at the time. And I was either blessed or cursed with this momentary clarity of purpose where I knew with all my being that this is what I wanted to do with myself for, if not the rest of my life, a very long time. And the only alternative, or rather the only choice to pursue this at the time, was really starting a fund. So that's what I had to do, right? +CHAD: And how large was the first fund? +JOSEPH: It was pretty small; it was $7.6 million, which in local currency equates to a nice number of just above 10 million sings. +CHAD: And where did you...I'm going to ask where that ended up coming from. But in terms of the mechanics of actually starting a fund, what did that look like? +JOSEPH: Well, it depends on each market. But typically, what happens is you need to first have permission from the regulator in order to actually start and run a fund. So in Singapore, you need to apply for a venture capital fund management license from the Monetary Authority of Singapore. That's what had to be done first, and we got that approved in a pretty good time, actually. I think we might have captured a lull period because now, with all the funds coming out, I've heard the queue is months long in some cases. +And then came the business of incorporating the fund itself and then starting to draft all the legal paperwork, the conditions, the private memorandum or prospectus, depending on which geography and how regulated you are, that you show around to investors once they've expressed interest in learning substantially more details about your fund beyond what a simple PowerPoint deck or a casual coffee conversation can yield. +And then you start collecting commitments, and then you start collecting the money. And at some point, you have enough money to say, all right, we'll do a close or first close, and that then gives you permission to start deploying that money into investments. And some funds they'll only do one close, some funds will do a first close, and then a final close when they get the rest of the money in or some money committed and then calling the rest of it to come in. Or some will do multiple closes just so that they have the ability to keep deploying continuously while they're doing this fundraising process. +And in our case, we were doing rolling closes. So we would close every few months, and we'd continue to deploy. And by the time we finished fundraising, we actually already had nine companies out of the 15 that we have in our portfolio done. So it really depends on all sorts of different factors, which we probably don't have that much time to get into. And I risk perhaps putting my foot in my mouth and misspeaking if I give too many examples. +CHAD: [laughs] When it comes to starting a fund, how cookie-cutter is it? Or do you find yourself having to create everything from scratch, all the legal documents, whatever platform you might be...or access you might be giving to the people who are contributing to the fund? +JOSEPH: I'd say, again, it depends where you are. I think in the U.S. and especially with the advent of great service providers platforms like AngelList and Assure, it is super cookie-cutter. In our part of the world, I still think it's somewhat cookie-cutter, but we got a little too cute. +CHAD: [chuckles] +JOSEPH: We thought, okay, it's our first time doing a fund. I've been an LP in other funds. What did I wish I had as an LP? And as a consequence, we introduced some hurdle rates of tiered carry, and even zero carry if we don't hit a certain return. And all that really did was just create more questions from the investors. So we should have probably done it as cookie-cutter as possible in hindsight. +CHAD: So I often hear from founders who talk about how it's important to have a VC fund behind you that you agree with, and want to work with, and are excited about, and that can be value additive. Do you need, as someone raising a fund, do you need to consider things like that or other things when it comes to the people you're taking money from the fund? +JOSEPH: Absolutely. Maybe knock on wood here, but our relative inexperience when starting a fund probably selected out all the folks who might not have gotten along with us anyway. And the fact that we're pretty straightforward and direct with what we want to do in our objectives probably helped with that selection process as well on the positive side. But I absolutely, absolutely can recommend having that alignment of values and mission with those who are on the journey with you for a good decade. It's like getting married, right? +CHAD: Yeah. Well, so when you're planning a fund and thinking about time horizons, is a decade what you're thinking about? +JOSEPH: Yeah, all things considered. So our fund lifetime was eight years from final close. But still, it takes time to raise the fund and plan the fund, and you have people that are on board even before the fund begins. So it is a decade-long relationship, at least. And then some of the larger funds because they want to have a longer investment period, will push that out even further where they're going to be a 10-year fund from final close. +And if you have enough of your portfolio that hasn't exited yet but still has some value to be uncovered, you may ask your investors to extend the fund life even further. So this is a supremely long relationship that you have. And aside from evergreen funds that don't have a fund lifetime, I think this is about as long as it gets, although I have seen some people float the idea of a 20-year fund or a 50-year fund, but that's really not widely practiced. I think five years is the fastest I've seen, and ten seems to be the average. +CHAD: Where did that first fund come from? How did you drum up the interest and decide who would be a part of it? +JOSEPH: It's really the folks who have known me the longest or worked with me. So you know how they say when you're raising money for a startup, you get it from the three F's, Friends, Family, and Fools? For funds and for first-time fund managers, I think it's a pretty analogous group of people, although I don't think we have any fools. +CHAD: [laughs] +JOSEPH: And, unfortunately, don't have family either. So it's really all friends, old co-workers, old clients, and then the people that they introduced us to. There were some serendipitous moments where people liked what I said at a conference, or we asked a tough question. And people asked, "Well, how can you ask such a tough question?" Then they got to know us and then decide to invest from there. But majority of it was just introductions, warm introductions. We never did any cold emails. +CHAD: Have there been any exits in the first fund? +JOSEPH: Not just yet. We do come in as either the first or second investor in these companies. So there is quite a long journey that we expect before we, you know, see some exits. There may be some this year. But if I look back at my angel investments, there was only real serious talk of an exit at the six-year mark for one of the companies that's doing really well. And even that exit turned out to be just another, you know, the investor changed their mind, and instead of buying the company, they decided to just invest more money into it. So this is a long journey. +CHAD: Yeah, definitely. Did that make putting together the second fund any harder, or is that what everyone expects? +JOSEPH: I am cautiously optimistic because we're still so early in our journey that the only folks we've really spoken with are the ones who invested in our first fund or passed on our first fund because they don't back first-time fund managers. They come to expect that your second fund is built on the momentum of the first fund. And it's really your third fund that's built on the exit and actual realized track record of your first fund. +CHAD: That makes sense. What do you think is next for Verge HealthTech? +JOSEPH: Well, first things first, we got to get started with the second fund and see if we can build something to scale. I mean, the first fund was an experiment. It was a small fund, you know. Could we build the world's seed-stage global impact healthtech fund on basically a shoestring? And the second fund is now let's take everything that we wish we had for the first fund and scale it up so bigger initial ticket sizes because we want to own more, the ability to follow on properly, the ability to do more deals, which requires a much bigger team which we now have. +As well as to go back and support the winners of our first fund as well as some of the companies that maybe we made a mistake on and passed but still have a strong enough relationship to revisit and get them on the next round or the round after that, or just new companies that the market has moved. You know, the area that we might have been really interested in at the seed stage is now a pre-A stage or an A stage. +So that's really what we want to do with the second one. And it would be amazing to see where this goes. I'm thrilled that we actually have, well, I think, one of the best healthtech investment teams in the world; maybe I'm slightly biased with this. +CHAD: [laughs] +JOSEPH: And I'm excited to see what we can do together. +CHAD: That's great. Well, I wish you the best. And I really appreciate you for stopping by and sharing with us. If folks want to follow along with you or get in touch with you, where are the best places for them to do that? +JOSEPH: Probably LinkedIn is the best way to do it. Also, I have a blog on Medium, which I'm sure can be linked in the show notes. I've been really bad...I've been traveling intensely in the past half-year. But I promise my next blog post will be interesting. +CHAD: [laughs] +JOSEPH: Because I just got back from Rwanda and Saudi Arabia, which are two very, very different countries, however, with a great emphasis on improving healthcare, especially on the digital side. +CHAD: Well, that's exciting. So folks definitely can find the links for that in the notes, which you can find the notes; you can subscribe to the show and a full transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Joseph Mocanu. + + + Joseph Mocanu is Co-founder and Managing Director of Verge HealthTech Fund, which invests globally in seed-stage healthcare technology startups relevant to emerging Asia that focus on disease prevention and management, digital therapies, and health system efficiency.

+ +

Chad talks with Joseph about the healthcare landscape in different places of the world, funding criteria for companies, and how the pandemic has changed prospects for the fund and the market in general.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Joseph Mocanu, Co-founder and Managing Director of Verge HealthTech Fund, which invests globally in seed-stage healthcare technology startups relevant to emerging Asia that focus on disease prevention and management, digital therapies, and health system efficiency. Joseph, thank you for joining me.

+ +

JOSEPH: Thanks so much, Chad, for having me.

+ +

CHAD: So you have been focused on emerging Asia healthtech for a little while both at Verge HealthTech Fund, and prior to that, how did you get involved in this space?

+ +

JOSEPH: I wish I had a really cool, deliberate story that made it sound like it was a smooth transition from point A to point B. But I simply have to owe it to an opportunity to transfer to the region through my old employer which is Oliver Wyman, a global management consultancy. So I joined this consultancy in 2011 after doing my Ph.D. and MBA really to understand how to be a better investor, which, again, sounds a little bit backwards.

+ +

But I had worked at a hedge fund in China just after my MBA, and I learned that they use management consulting techniques to add value to their portfolio companies. And I thought that's a great skill to learn. And it'd be great to even learn it in English and doing it in healthcare 100% of the time.

+ +

So I had joined Oliver Wyman in 2011 in Toronto office back home, where I spent a lot of my life. And they asked me one day if I wanted to transfer to the Singapore office to help start healthcare over there. And when I went to Singapore, of course, it's this futuristic city, really well planned. It's got a lot of fine names and a reputation globally of being a modern cosmopolitan place to do business. Some people refer to it as Asia-lite. But the surrounding areas have a lot of issues when it comes to their health systems. I knew this from an academic perspective, having studied about the region before moving to Singapore but seeing it firsthand was a completely different experience.

+ +

At the time, I was working for primarily pharmaceutical clients, helping them with market access and other commercially relevant activities. And they were faced with a fundamental challenge of trying to sell their product, which was usually placed in the premium category to markets that had difficulty affording this. And not only did it have difficulty affording this, it had difficulty in delivering it as well as in using the product appropriately, making sure it gets to the patients when it's needed at the right time, at the right dose. And so they were looking for partners. They were looking for partners on the ground that could assist with this delivery education, the technology, and the financing around it as well.

+ +

Now, there was a real shortage of said partners on the ground. At the same time, there were also insurance companies that wanted to expand their business. They also realized that the policies tended to be a bit simple, and they tended to resemble one another across competitors. And also, to manage increasing claims, they had a tendency to increase the premium that they charged. This was not possible to do indefinitely. And at some point, they needed to actually manage the medical conditions, which you're probably seeing more and more of in the U.S. and in Western markets, less so of in this part of the world.

+ +

And then lastly, you had conglomerates and investors who said, "Hey, we hear healthcare is going to be a pretty hot field. How do we get started? How do we invest?" And all of this basically set me on a mission of target hunting. And during the course of this, well, I met a lot of interesting companies, a lot of them really, really early in their journey and really too small for any of my clients to find a meaningful way to engage with them. And unfortunately, they couldn't get to the point where they are relevant and large enough to engage with without a lot of capital.

+ +

This is where, you know, you'd have a nice investment ecosystem coming in to fill in the gaps. This, unfortunately, did not really exist at the time. And I had the hubris of thinking that I could do something about it by being an angel investor and starting to support these founders directly, which, thankfully, seemed to work to a certain degree. It worked to the point where one day, I woke up, and I realized I had 13 angel investments, 9 of which were in healthcare technology, and not a lot of money left in my bank account to do other things with.

+ +

CHAD: Uh-oh. [laughs]

+ +

JOSEPH: Yeah. And at the same time, I also realized that the work that those founders are doing is a whole lot more impactful than me sitting up until 3:00 o'clock in the morning every night writing PowerPoint slides or begging analysts to write the PowerPoint slides that would more or less sit and collect dust on my clients' shelves for various reasons. So I came to the realization that I need to do this full time.

+ +

I didn't have, you know, $10 million in my pocket as reference to spending all my money on angel investments. So I realized that I have to use other people's money, and the way to do that is to join a fund. Now, the problem with that idea is that there weren't any funds that were doing this, like really, really early investing in healthtech companies in the region that was really geared to helping solve some of these really big access challenges. So then I realized I had to start a VC fund that did this and only this. So that's really kind of a long-winded introduction as to how I got started with this.

+ +

CHAD: Yeah, I want to come back to the process of actually starting a VC fund in a bit. But I'm curious, were the companies that you were doing angel investment in and now doing seed-stage investment in do they tend to be local companies, or do they tend to be international companies that are planning to solve a problem locally?

+ +

JOSEPH: It's funny you ask that. At the beginning, they were local. Well, actually, if I really were to take a step back, the very first angel investment I made was for a mentee, and she was based in Toronto. But I'd say that the first true angel investment I made, you know, it was in Singapore, first and foremost, because I was there. And then I started branching out. I started making investments in the Philippines. I started looking at companies in Taiwan and other parts.

+ +

And actually, that opened my eyes to the fact that there may be other companies around the world that are trying to solve a problem that may not necessarily be in my own backyard. So I started to, you know, cheekily, I sent my wife to tech conferences around the world. And she herself is an entrepreneur from the tech industry; hardware was her specialty. And we started identifying companies from all over the world. And the second angel investment where I was the very first investor was actually from a company in South Africa with similar challenges.

+ +

So the things that we saw as major health system deficiencies or maybe shortages in infrastructure and human capital were very much true not just in Southeast Asia but in a lot of parts of the world. And we noticed that while there were different reasons for why they ended up in that position, the outcome was similar.

+ +

CHAD: I'm not sure that everyone listening has a good sense of what the healthcare landscape actually looks like in these different places of the world. So let's take insurance, for example; what is the insurance landscape, generally speaking, in Southeast Asian countries?

+ +

JOSEPH: So, in Southeast Asia, we do have insurers. I mean, private insurance is certainly there. But it's just not --

+ +

CHAD: Do most companies have public insurance, too, like universal healthcare?

+ +

JOSEPH: That depends on which country you're in. Now, the one interesting thing about our entire region is that they've all committed to universal healthcare coverage. I would say that the implementation thereof has been heterogeneous; let's put it that way. Out of Southeast Asian countries that are not Singapore, I'd say that Thailand probably has the strongest public healthcare system. And in fact, they even do health technology assessments, which is really looking at the true cost-effectiveness of a new intervention versus what's currently done in practice to make decisions as to whether they're going to pay for it. And they cover a pretty high percentage of their population with this.

+ +

And then there are other places where the financing mechanisms are in place, but you don't necessarily have the doctors or the hospitals where they need to be to address the needs of the population. Still, we are dealing with places that are not fully urbanized. And in fact, a good deal of the population is still working on the pharm, basically.

+ +

One of the other complexities of our region is that just between the Philippines and Indonesia, which together has a combined population of 380 million at least, maybe it's 390 now, you've got 25,000 islands, and not all of those islands tend to hold major tier-one cities, even though they can hold a lot of people. And if there is one thing about healthcare that seems to be a universal truth is that highly skilled workers like to live in the rich cities.

+ +

CHAD: And so what I'm hearing is that on an individual island, if there's not a major city there, the access to the actual healthcare might be really limited.

+ +

JOSEPH: That is exactly it.

+ +

CHAD: In these economies in these countries, it's typical to have private insurance layered on top. But the pharmas probably aren't doing that, right?

+ +

JOSEPH: Oh, no, no, unfortunately not. There are some pilots of trying to do co-ops or collective insurance or micro-insurance policies. But again, when you look at the amount of premium that they could pay in, the kind of coverage they get is pretty basic.

+ +

CHAD: So, how does that landscape influence the solutions that startups are creating?

+ +

JOSEPH: Well, first and foremost, you've got to try to get some sort of mechanism by which you can seek care without having to travel too much. And I think that concept is extremely familiar to all of us thanks to the global pandemic that I hope we're coming out of right now, although there's always a new strain surprising us.

+ +

The idea of basic telemedicine is one that can have a great deal of impact in these populations. But even before that, just understanding the importance of healthcare, like, what the concept of healthcare is, what the concept of the modern medical system is, is something that a fair number of people never really had awareness of.

+ +

And I'll call out an example country, and I try not to call out too many examples. But Indonesia did a really good job of educating people about the concept of healthcare when they promoted their universal healthcare coverage. Even if they didn't have the ability to deliver it as well as they wanted to or as widespread as they wanted to, at least they got people paying attention to this concept called health. So awareness is really the first step.

+ +

The second challenge is all right, so you know health exists. When do you know when you need it? Where are you going to find a doctor? How do you know if a doctor is even good? And how do you know that the products that you're going to get are appropriate? So there are so many challenges that you have to face when you are in a lack of access situation.

+ +

CHAD: I assume you're getting pitched on a lot of ideas coming to your fund, a lot of startups. Correct me if that's wrong. [laughs]

+ +

JOSEPH: No, no, that's absolutely true. So one of the blessings and curses of being one of the very few super early-stage healthtech venture funds out there is that there aren't many of us out there. And when we started...let's just put it this way, if I could find a fund that was doing what I wanted to do, I would have sent my CV in, and I couldn't.

+ +

And starting a fund was basically the last thing I wanted to do, having never worked at a VC before or ever raised money in my life before. So I still think that we are the only truly global impact-oriented seed - I hate the term pre-seed, but I'll use it because of the audience's familiarity with it- investment fund out there right now for healthtech. So by virtue of that, we do see a lot of companies.

+ +

CHAD: So what are some of the criteria?

+ +

JOSEPH: So I'd say some of the criteria that we look for is number one, are you solving a real problem? And we define a real problem by the breadth of the problem, like, how many people are suffering from it or how systemic is this problem if it's an infrastructural one? And depth being how severe is this problem: is it life or death, or is it a minor inconvenience? So first and foremost, it's got to be solving a real problem.

+ +

Second, it's really around the team. You need a lot of clinical, technical, and commercial experience in order to pull off a healthtech startup successfully. And even before that, we want to understand why are you doing this? Because this is not easy. I'd say on a scale of 1 to 10, doing a startup is like an eight, and then doing a healthtech startup is like an 11. It's slow; it's technical, it's regulated, it's super risky.

+ +

And health systems are very pathway-dependent in the intent to not have many things in common with one another. So it is really, really hard. So we want to know the motivation. Are you going to stick through the thick and thin, or are you doing this healthtech startup because you think healthtech is cool or hot this particular period in the market cycle? So that's another criterion.

+ +

Another criterion is, well, what's your edge? I mean, okay, you can have a great team, and I think that is definitely a prerequisite. You can solve a problem. But do you have something that could make sure that you are going to be competitive and remain competitive?

+ +

CHAD: Given the barriers to market entry that you just outlined, do most of the companies that you're investing in have any sort of traction already in the market, or where are they in the product development or business development cycle?

+ +

JOSEPH: I'm going to give the ultimate cop-out answer of it depends.

+ +

CHAD: [laughs] Yeah.

+ +

JOSEPH: But I will qualify that by saying it depends on whether it's hardware or software, and it depends whether it's regulated or non-regulated. So if you are a software company that's unregulated so, what does this mean? It could be like a marketplace. It could be health education. It could be some telemedicine in a loosely regulated market. We'd really like to see user traction. We'd really like to see revenue even.

+ +

However, if you're a device company and you need to get FDA before you can earn a single dollar, we're okay with it being a science experiment or a prototype on the table as long as the science part of it has been de-risked. So if we know that the fundamental scientific principles are sound, then we're willing to take the productization and regulatory risk because we've been through this journey ourselves.

+ +

CHAD: And also, you said a team is really important, so if it's a team that has never gone through that before, that's less attractive than a team that has done it before, I assume.

+ +

JOSEPH: Yeah, absolutely. However, one of the challenges is that outside of the U.S., certain European markets in Israel, it's really difficult to find a team that's gone through the entire medical device development process before. So you are going to rely heavily on your professional service providers, consultants, advisors, other investors who've done this before. And as long as you have at least a path to getting to a point where you can unlock and utilize that expertise, that's okay. But if you don't, then that's a really, really big risk.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Earlier, you said FDA. FDA is a United States thing. Do most countries in Southeast Asia have a local regulatory agency like the FDA that things need to be approved through?

+ +

JOSEPH: Yep, every single one. The question is, what's the process to go through that? Generally speaking, the FDA, as well as the European equivalent, which is the CE Mark, are used as predicates in order to kind of shortcut the process, make it go a little bit faster. Because then you don't have to create a bunch of new work or get the local regulator to really try to do things that they're unfamiliar with.

+ +

CHAD: You said it's fairly rare for teams to have concrete experience doing that in the local market. Does that mean that most of these markets have been served by, I don't know, large companies previously?

+ +

JOSEPH: Yeah, and still are. A fair number of emerging markets don't even have the manufacturing capability to even do local production, so they require a lot of importation. I'd say that this is a different case when it comes to generic pharmaceuticals and maybe vaccines and some consumables. But complex devices and biologics are generally manufactured in more developed markets or larger economies.

+ +

CHAD: Yeah. Well, you mentioned the pandemic, and I'm curious how the pandemic has changed either your prospects for the fund but also the market in general.

+ +

JOSEPH: I would say, again, it's both a blessing and a curse. So during the start of the pandemic, there was a great deal of societal and economic uncertainty around where are we going to be as a species in six months? And I remember early 2020; it was kind of these Hollywood movies that would paint this kind of semi-apocalyptic picture of where we're going to end up. And as a consequence, people really puckered up and stopped investing in things.

+ +

I would say that the other side of it is now much of the world understands what it's like to not have access to quality healthcare or even access to healthcare. You see people not going to the hospital for things that they ought to and then suffering the consequences at home, like, let's say, not going for that heart checkup, and then you having a heart attack at home and passing when you otherwise wouldn't have. Or even cancer patients having to delay their therapy because the hospital is just too full.

+ +

So this concept of telemedicine which has always been resisted by both the payers and providers for being infeasible, or inaccurate, or impossible to fund properly, suddenly had to be done. And the concept of telemedicine is fairly old. I mean, how else would you treat your astronauts in space in the '60s if they got sick? So this is something that NASA thought of and invented and implemented, you know, decades and decades ago. And finally, this came forward.

+ +

And I was pleasantly surprised to see...and again, I'll quote the U.S. here where The Center for Medicare & Medicaid Services or CMS actually reimbursed a bunch of remote procedure codes, which is pretty amazing. And I think that was opening Pandora's Box. There's no going back from that.

+ +

So I think telemedicine is absolutely here to stay. And the real challenge now is really how to make it more user-friendly, how to improve it, how to improve the decisions that come from it. I really don't think it's going back. And as a consequence of this, it's really benefited a lot of our startups that were trying to build this remote-connected future anyway.

+ +

CHAD: Has there also been an influx of those kinds of startups?

+ +

JOSEPH: Absolutely. I would say that there has been a veritable Cambrian explosion of startups where everyone and their uncle is starting a healthtech startup as well as a healthtech fund. I see a lot of new funds coming up promising to invest in this space. So I think it's good in that there's going to be a lot of really new ideas, and hopefully, it's going to improve the standard of care for everyone around the world. But at the same time, it is creating a lot of noise, and it's becoming increasingly difficult to filter through that.

+ +

CHAD: Do the solutions tend to be local? I guess the nature of my question was, you know, like messaging apps. [laughs] Different countries have different popular messaging apps. What do you see as the penetration of different telemedicine solutions in the different countries? Do you think it's going to be, oh, you know, this is popular in this country? Or do you think it's possible for one company to come in and really have a significant impact in the market across multiple markets?

+ +

JOSEPH: Yeah, I think it's eventually going to be the latter. So at the start, you do see that you have your national champions. And like instant messaging apps, it's kind of like a 90-10 rule where the number 1 player takes 90% of the market, number 2 takes most of what's left, and then number 3 player caters to some niche or another. And I see two competing forces here; one is, yes, there may be a big player like Babylon or Crew who comes in and rolls up everything backed by heaps of capital.

+ +

But the other thing could also be that all the health systems start saying, "You know what? Why are we working with an external company? Why don't we just develop all these capabilities ourselves and then keep the patient captive?" And you are starting to see middleware providers who are basically providing that telemedicine layer, white-labeling it, or giving API access to the providers themselves, the legacy providers themselves, and then allowing them to do that.

+ +

And I actually saw this statistic...I don't know how accurate it was, but I saw a chart in the U.S. that white-labeled or internal telemedicine consults exceeded the number of Teladoc consultations, which is the largest platform in the U.S., at some point last year.

+ +

CHAD: I'm wondering, do you know if Teladoc uses Twilio?

+ +

JOSEPH: I really should know the answer to that question, but unfortunately, I do not.

+ +

CHAD: Because my sense is the real winner in this game might be companies like Twilio because I think everyone is using them. [laughs]

+ +

JOSEPH: That makes a ton of sense. So when we do look at some investments, we actually want to invest in middleware because why duke it out to be the platform when you're the utility provider?

+ +

CHAD: So let's turn our attention to the actual creation of the fund. And I know you just opened your second fund last month, right?

+ +

JOSEPH: Actually, this month. I mean, last month was the paperwork, but it takes time for stuff to get approved.

+ +

CHAD: Yeah, fair enough. So you already said actually starting a fund was, I think you said, the last thing on earth that you wanted to do. Why was that the last thing you wanted to do?

+ +

JOSEPH: Frankly, it was a whole lot more uncertainty than I was prepared to handle at the time. And I was either blessed or cursed with this momentary clarity of purpose where I knew with all my being that this is what I wanted to do with myself for, if not the rest of my life, a very long time. And the only alternative, or rather the only choice to pursue this at the time, was really starting a fund. So that's what I had to do, right?

+ +

CHAD: And how large was the first fund?

+ +

JOSEPH: It was pretty small; it was $7.6 million, which in local currency equates to a nice number of just above 10 million sings.

+ +

CHAD: And where did you...I'm going to ask where that ended up coming from. But in terms of the mechanics of actually starting a fund, what did that look like?

+ +

JOSEPH: Well, it depends on each market. But typically, what happens is you need to first have permission from the regulator in order to actually start and run a fund. So in Singapore, you need to apply for a venture capital fund management license from the Monetary Authority of Singapore. That's what had to be done first, and we got that approved in a pretty good time, actually. I think we might have captured a lull period because now, with all the funds coming out, I've heard the queue is months long in some cases.

+ +

And then came the business of incorporating the fund itself and then starting to draft all the legal paperwork, the conditions, the private memorandum or prospectus, depending on which geography and how regulated you are, that you show around to investors once they've expressed interest in learning substantially more details about your fund beyond what a simple PowerPoint deck or a casual coffee conversation can yield.

+ +

And then you start collecting commitments, and then you start collecting the money. And at some point, you have enough money to say, all right, we'll do a close or first close, and that then gives you permission to start deploying that money into investments. And some funds they'll only do one close, some funds will do a first close, and then a final close when they get the rest of the money in or some money committed and then calling the rest of it to come in. Or some will do multiple closes just so that they have the ability to keep deploying continuously while they're doing this fundraising process.

+ +

And in our case, we were doing rolling closes. So we would close every few months, and we'd continue to deploy. And by the time we finished fundraising, we actually already had nine companies out of the 15 that we have in our portfolio done. So it really depends on all sorts of different factors, which we probably don't have that much time to get into. And I risk perhaps putting my foot in my mouth and misspeaking if I give too many examples.

+ +

CHAD: [laughs] When it comes to starting a fund, how cookie-cutter is it? Or do you find yourself having to create everything from scratch, all the legal documents, whatever platform you might be...or access you might be giving to the people who are contributing to the fund?

+ +

JOSEPH: I'd say, again, it depends where you are. I think in the U.S. and especially with the advent of great service providers platforms like AngelList and Assure, it is super cookie-cutter. In our part of the world, I still think it's somewhat cookie-cutter, but we got a little too cute.

+ +

CHAD: [chuckles]

+ +

JOSEPH: We thought, okay, it's our first time doing a fund. I've been an LP in other funds. What did I wish I had as an LP? And as a consequence, we introduced some hurdle rates of tiered carry, and even zero carry if we don't hit a certain return. And all that really did was just create more questions from the investors. So we should have probably done it as cookie-cutter as possible in hindsight.

+ +

CHAD: So I often hear from founders who talk about how it's important to have a VC fund behind you that you agree with, and want to work with, and are excited about, and that can be value additive. Do you need, as someone raising a fund, do you need to consider things like that or other things when it comes to the people you're taking money from the fund?

+ +

JOSEPH: Absolutely. Maybe knock on wood here, but our relative inexperience when starting a fund probably selected out all the folks who might not have gotten along with us anyway. And the fact that we're pretty straightforward and direct with what we want to do in our objectives probably helped with that selection process as well on the positive side. But I absolutely, absolutely can recommend having that alignment of values and mission with those who are on the journey with you for a good decade. It's like getting married, right?

+ +

CHAD: Yeah. Well, so when you're planning a fund and thinking about time horizons, is a decade what you're thinking about?

+ +

JOSEPH: Yeah, all things considered. So our fund lifetime was eight years from final close. But still, it takes time to raise the fund and plan the fund, and you have people that are on board even before the fund begins. So it is a decade-long relationship, at least. And then some of the larger funds because they want to have a longer investment period, will push that out even further where they're going to be a 10-year fund from final close.

+ +

And if you have enough of your portfolio that hasn't exited yet but still has some value to be uncovered, you may ask your investors to extend the fund life even further. So this is a supremely long relationship that you have. And aside from evergreen funds that don't have a fund lifetime, I think this is about as long as it gets, although I have seen some people float the idea of a 20-year fund or a 50-year fund, but that's really not widely practiced. I think five years is the fastest I've seen, and ten seems to be the average.

+ +

CHAD: Where did that first fund come from? How did you drum up the interest and decide who would be a part of it?

+ +

JOSEPH: It's really the folks who have known me the longest or worked with me. So you know how they say when you're raising money for a startup, you get it from the three F's, Friends, Family, and Fools? For funds and for first-time fund managers, I think it's a pretty analogous group of people, although I don't think we have any fools.

+ +

CHAD: [laughs]

+ +

JOSEPH: And, unfortunately, don't have family either. So it's really all friends, old co-workers, old clients, and then the people that they introduced us to. There were some serendipitous moments where people liked what I said at a conference, or we asked a tough question. And people asked, "Well, how can you ask such a tough question?" Then they got to know us and then decide to invest from there. But majority of it was just introductions, warm introductions. We never did any cold emails.

+ +

CHAD: Have there been any exits in the first fund?

+ +

JOSEPH: Not just yet. We do come in as either the first or second investor in these companies. So there is quite a long journey that we expect before we, you know, see some exits. There may be some this year. But if I look back at my angel investments, there was only real serious talk of an exit at the six-year mark for one of the companies that's doing really well. And even that exit turned out to be just another, you know, the investor changed their mind, and instead of buying the company, they decided to just invest more money into it. So this is a long journey.

+ +

CHAD: Yeah, definitely. Did that make putting together the second fund any harder, or is that what everyone expects?

+ +

JOSEPH: I am cautiously optimistic because we're still so early in our journey that the only folks we've really spoken with are the ones who invested in our first fund or passed on our first fund because they don't back first-time fund managers. They come to expect that your second fund is built on the momentum of the first fund. And it's really your third fund that's built on the exit and actual realized track record of your first fund.

+ +

CHAD: That makes sense. What do you think is next for Verge HealthTech?

+ +

JOSEPH: Well, first things first, we got to get started with the second fund and see if we can build something to scale. I mean, the first fund was an experiment. It was a small fund, you know. Could we build the world's seed-stage global impact healthtech fund on basically a shoestring? And the second fund is now let's take everything that we wish we had for the first fund and scale it up so bigger initial ticket sizes because we want to own more, the ability to follow on properly, the ability to do more deals, which requires a much bigger team which we now have.

+ +

As well as to go back and support the winners of our first fund as well as some of the companies that maybe we made a mistake on and passed but still have a strong enough relationship to revisit and get them on the next round or the round after that, or just new companies that the market has moved. You know, the area that we might have been really interested in at the seed stage is now a pre-A stage or an A stage.

+ +

So that's really what we want to do with the second one. And it would be amazing to see where this goes. I'm thrilled that we actually have, well, I think, one of the best healthtech investment teams in the world; maybe I'm slightly biased with this.

+ +

CHAD: [laughs]

+ +

JOSEPH: And I'm excited to see what we can do together.

+ +

CHAD: That's great. Well, I wish you the best. And I really appreciate you for stopping by and sharing with us. If folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

JOSEPH: Probably LinkedIn is the best way to do it. Also, I have a blog on Medium, which I'm sure can be linked in the show notes. I've been really bad...I've been traveling intensely in the past half-year. But I promise my next blog post will be interesting.

+ +

CHAD: [laughs]

+ +

JOSEPH: Because I just got back from Rwanda and Saudi Arabia, which are two very, very different countries, however, with a great emphasis on improving healthcare, especially on the digital side.

+ +

CHAD: Well, that's exciting. So folks definitely can find the links for that in the notes, which you can find the notes; you can subscribe to the show and a full transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Joseph Mocanu.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Joseph Mocanu is Co-founder and Managing Director of Verge HealthTech Fund, which invests globally in seed-stage healthcare technology startups relevant to emerging Asia that focus on disease prevention and management, digital therapies, and health system efficiency.

+ +

Chad talks with Joseph about the healthcare landscape in different places of the world, funding criteria for companies, and how the pandemic has changed prospects for the fund and the market in general.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Joseph Mocanu, Co-founder and Managing Director of Verge HealthTech Fund, which invests globally in seed-stage healthcare technology startups relevant to emerging Asia that focus on disease prevention and management, digital therapies, and health system efficiency. Joseph, thank you for joining me.

+ +

JOSEPH: Thanks so much, Chad, for having me.

+ +

CHAD: So you have been focused on emerging Asia healthtech for a little while both at Verge HealthTech Fund, and prior to that, how did you get involved in this space?

+ +

JOSEPH: I wish I had a really cool, deliberate story that made it sound like it was a smooth transition from point A to point B. But I simply have to owe it to an opportunity to transfer to the region through my old employer which is Oliver Wyman, a global management consultancy. So I joined this consultancy in 2011 after doing my Ph.D. and MBA really to understand how to be a better investor, which, again, sounds a little bit backwards.

+ +

But I had worked at a hedge fund in China just after my MBA, and I learned that they use management consulting techniques to add value to their portfolio companies. And I thought that's a great skill to learn. And it'd be great to even learn it in English and doing it in healthcare 100% of the time.

+ +

So I had joined Oliver Wyman in 2011 in Toronto office back home, where I spent a lot of my life. And they asked me one day if I wanted to transfer to the Singapore office to help start healthcare over there. And when I went to Singapore, of course, it's this futuristic city, really well planned. It's got a lot of fine names and a reputation globally of being a modern cosmopolitan place to do business. Some people refer to it as Asia-lite. But the surrounding areas have a lot of issues when it comes to their health systems. I knew this from an academic perspective, having studied about the region before moving to Singapore but seeing it firsthand was a completely different experience.

+ +

At the time, I was working for primarily pharmaceutical clients, helping them with market access and other commercially relevant activities. And they were faced with a fundamental challenge of trying to sell their product, which was usually placed in the premium category to markets that had difficulty affording this. And not only did it have difficulty affording this, it had difficulty in delivering it as well as in using the product appropriately, making sure it gets to the patients when it's needed at the right time, at the right dose. And so they were looking for partners. They were looking for partners on the ground that could assist with this delivery education, the technology, and the financing around it as well.

+ +

Now, there was a real shortage of said partners on the ground. At the same time, there were also insurance companies that wanted to expand their business. They also realized that the policies tended to be a bit simple, and they tended to resemble one another across competitors. And also, to manage increasing claims, they had a tendency to increase the premium that they charged. This was not possible to do indefinitely. And at some point, they needed to actually manage the medical conditions, which you're probably seeing more and more of in the U.S. and in Western markets, less so of in this part of the world.

+ +

And then lastly, you had conglomerates and investors who said, "Hey, we hear healthcare is going to be a pretty hot field. How do we get started? How do we invest?" And all of this basically set me on a mission of target hunting. And during the course of this, well, I met a lot of interesting companies, a lot of them really, really early in their journey and really too small for any of my clients to find a meaningful way to engage with them. And unfortunately, they couldn't get to the point where they are relevant and large enough to engage with without a lot of capital.

+ +

This is where, you know, you'd have a nice investment ecosystem coming in to fill in the gaps. This, unfortunately, did not really exist at the time. And I had the hubris of thinking that I could do something about it by being an angel investor and starting to support these founders directly, which, thankfully, seemed to work to a certain degree. It worked to the point where one day, I woke up, and I realized I had 13 angel investments, 9 of which were in healthcare technology, and not a lot of money left in my bank account to do other things with.

+ +

CHAD: Uh-oh. [laughs]

+ +

JOSEPH: Yeah. And at the same time, I also realized that the work that those founders are doing is a whole lot more impactful than me sitting up until 3:00 o'clock in the morning every night writing PowerPoint slides or begging analysts to write the PowerPoint slides that would more or less sit and collect dust on my clients' shelves for various reasons. So I came to the realization that I need to do this full time.

+ +

I didn't have, you know, $10 million in my pocket as reference to spending all my money on angel investments. So I realized that I have to use other people's money, and the way to do that is to join a fund. Now, the problem with that idea is that there weren't any funds that were doing this, like really, really early investing in healthtech companies in the region that was really geared to helping solve some of these really big access challenges. So then I realized I had to start a VC fund that did this and only this. So that's really kind of a long-winded introduction as to how I got started with this.

+ +

CHAD: Yeah, I want to come back to the process of actually starting a VC fund in a bit. But I'm curious, were the companies that you were doing angel investment in and now doing seed-stage investment in do they tend to be local companies, or do they tend to be international companies that are planning to solve a problem locally?

+ +

JOSEPH: It's funny you ask that. At the beginning, they were local. Well, actually, if I really were to take a step back, the very first angel investment I made was for a mentee, and she was based in Toronto. But I'd say that the first true angel investment I made, you know, it was in Singapore, first and foremost, because I was there. And then I started branching out. I started making investments in the Philippines. I started looking at companies in Taiwan and other parts.

+ +

And actually, that opened my eyes to the fact that there may be other companies around the world that are trying to solve a problem that may not necessarily be in my own backyard. So I started to, you know, cheekily, I sent my wife to tech conferences around the world. And she herself is an entrepreneur from the tech industry; hardware was her specialty. And we started identifying companies from all over the world. And the second angel investment where I was the very first investor was actually from a company in South Africa with similar challenges.

+ +

So the things that we saw as major health system deficiencies or maybe shortages in infrastructure and human capital were very much true not just in Southeast Asia but in a lot of parts of the world. And we noticed that while there were different reasons for why they ended up in that position, the outcome was similar.

+ +

CHAD: I'm not sure that everyone listening has a good sense of what the healthcare landscape actually looks like in these different places of the world. So let's take insurance, for example; what is the insurance landscape, generally speaking, in Southeast Asian countries?

+ +

JOSEPH: So, in Southeast Asia, we do have insurers. I mean, private insurance is certainly there. But it's just not --

+ +

CHAD: Do most companies have public insurance, too, like universal healthcare?

+ +

JOSEPH: That depends on which country you're in. Now, the one interesting thing about our entire region is that they've all committed to universal healthcare coverage. I would say that the implementation thereof has been heterogeneous; let's put it that way. Out of Southeast Asian countries that are not Singapore, I'd say that Thailand probably has the strongest public healthcare system. And in fact, they even do health technology assessments, which is really looking at the true cost-effectiveness of a new intervention versus what's currently done in practice to make decisions as to whether they're going to pay for it. And they cover a pretty high percentage of their population with this.

+ +

And then there are other places where the financing mechanisms are in place, but you don't necessarily have the doctors or the hospitals where they need to be to address the needs of the population. Still, we are dealing with places that are not fully urbanized. And in fact, a good deal of the population is still working on the pharm, basically.

+ +

One of the other complexities of our region is that just between the Philippines and Indonesia, which together has a combined population of 380 million at least, maybe it's 390 now, you've got 25,000 islands, and not all of those islands tend to hold major tier-one cities, even though they can hold a lot of people. And if there is one thing about healthcare that seems to be a universal truth is that highly skilled workers like to live in the rich cities.

+ +

CHAD: And so what I'm hearing is that on an individual island, if there's not a major city there, the access to the actual healthcare might be really limited.

+ +

JOSEPH: That is exactly it.

+ +

CHAD: In these economies in these countries, it's typical to have private insurance layered on top. But the pharmas probably aren't doing that, right?

+ +

JOSEPH: Oh, no, no, unfortunately not. There are some pilots of trying to do co-ops or collective insurance or micro-insurance policies. But again, when you look at the amount of premium that they could pay in, the kind of coverage they get is pretty basic.

+ +

CHAD: So, how does that landscape influence the solutions that startups are creating?

+ +

JOSEPH: Well, first and foremost, you've got to try to get some sort of mechanism by which you can seek care without having to travel too much. And I think that concept is extremely familiar to all of us thanks to the global pandemic that I hope we're coming out of right now, although there's always a new strain surprising us.

+ +

The idea of basic telemedicine is one that can have a great deal of impact in these populations. But even before that, just understanding the importance of healthcare, like, what the concept of healthcare is, what the concept of the modern medical system is, is something that a fair number of people never really had awareness of.

+ +

And I'll call out an example country, and I try not to call out too many examples. But Indonesia did a really good job of educating people about the concept of healthcare when they promoted their universal healthcare coverage. Even if they didn't have the ability to deliver it as well as they wanted to or as widespread as they wanted to, at least they got people paying attention to this concept called health. So awareness is really the first step.

+ +

The second challenge is all right, so you know health exists. When do you know when you need it? Where are you going to find a doctor? How do you know if a doctor is even good? And how do you know that the products that you're going to get are appropriate? So there are so many challenges that you have to face when you are in a lack of access situation.

+ +

CHAD: I assume you're getting pitched on a lot of ideas coming to your fund, a lot of startups. Correct me if that's wrong. [laughs]

+ +

JOSEPH: No, no, that's absolutely true. So one of the blessings and curses of being one of the very few super early-stage healthtech venture funds out there is that there aren't many of us out there. And when we started...let's just put it this way, if I could find a fund that was doing what I wanted to do, I would have sent my CV in, and I couldn't.

+ +

And starting a fund was basically the last thing I wanted to do, having never worked at a VC before or ever raised money in my life before. So I still think that we are the only truly global impact-oriented seed - I hate the term pre-seed, but I'll use it because of the audience's familiarity with it- investment fund out there right now for healthtech. So by virtue of that, we do see a lot of companies.

+ +

CHAD: So what are some of the criteria?

+ +

JOSEPH: So I'd say some of the criteria that we look for is number one, are you solving a real problem? And we define a real problem by the breadth of the problem, like, how many people are suffering from it or how systemic is this problem if it's an infrastructural one? And depth being how severe is this problem: is it life or death, or is it a minor inconvenience? So first and foremost, it's got to be solving a real problem.

+ +

Second, it's really around the team. You need a lot of clinical, technical, and commercial experience in order to pull off a healthtech startup successfully. And even before that, we want to understand why are you doing this? Because this is not easy. I'd say on a scale of 1 to 10, doing a startup is like an eight, and then doing a healthtech startup is like an 11. It's slow; it's technical, it's regulated, it's super risky.

+ +

And health systems are very pathway-dependent in the intent to not have many things in common with one another. So it is really, really hard. So we want to know the motivation. Are you going to stick through the thick and thin, or are you doing this healthtech startup because you think healthtech is cool or hot this particular period in the market cycle? So that's another criterion.

+ +

Another criterion is, well, what's your edge? I mean, okay, you can have a great team, and I think that is definitely a prerequisite. You can solve a problem. But do you have something that could make sure that you are going to be competitive and remain competitive?

+ +

CHAD: Given the barriers to market entry that you just outlined, do most of the companies that you're investing in have any sort of traction already in the market, or where are they in the product development or business development cycle?

+ +

JOSEPH: I'm going to give the ultimate cop-out answer of it depends.

+ +

CHAD: [laughs] Yeah.

+ +

JOSEPH: But I will qualify that by saying it depends on whether it's hardware or software, and it depends whether it's regulated or non-regulated. So if you are a software company that's unregulated so, what does this mean? It could be like a marketplace. It could be health education. It could be some telemedicine in a loosely regulated market. We'd really like to see user traction. We'd really like to see revenue even.

+ +

However, if you're a device company and you need to get FDA before you can earn a single dollar, we're okay with it being a science experiment or a prototype on the table as long as the science part of it has been de-risked. So if we know that the fundamental scientific principles are sound, then we're willing to take the productization and regulatory risk because we've been through this journey ourselves.

+ +

CHAD: And also, you said a team is really important, so if it's a team that has never gone through that before, that's less attractive than a team that has done it before, I assume.

+ +

JOSEPH: Yeah, absolutely. However, one of the challenges is that outside of the U.S., certain European markets in Israel, it's really difficult to find a team that's gone through the entire medical device development process before. So you are going to rely heavily on your professional service providers, consultants, advisors, other investors who've done this before. And as long as you have at least a path to getting to a point where you can unlock and utilize that expertise, that's okay. But if you don't, then that's a really, really big risk.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Earlier, you said FDA. FDA is a United States thing. Do most countries in Southeast Asia have a local regulatory agency like the FDA that things need to be approved through?

+ +

JOSEPH: Yep, every single one. The question is, what's the process to go through that? Generally speaking, the FDA, as well as the European equivalent, which is the CE Mark, are used as predicates in order to kind of shortcut the process, make it go a little bit faster. Because then you don't have to create a bunch of new work or get the local regulator to really try to do things that they're unfamiliar with.

+ +

CHAD: You said it's fairly rare for teams to have concrete experience doing that in the local market. Does that mean that most of these markets have been served by, I don't know, large companies previously?

+ +

JOSEPH: Yeah, and still are. A fair number of emerging markets don't even have the manufacturing capability to even do local production, so they require a lot of importation. I'd say that this is a different case when it comes to generic pharmaceuticals and maybe vaccines and some consumables. But complex devices and biologics are generally manufactured in more developed markets or larger economies.

+ +

CHAD: Yeah. Well, you mentioned the pandemic, and I'm curious how the pandemic has changed either your prospects for the fund but also the market in general.

+ +

JOSEPH: I would say, again, it's both a blessing and a curse. So during the start of the pandemic, there was a great deal of societal and economic uncertainty around where are we going to be as a species in six months? And I remember early 2020; it was kind of these Hollywood movies that would paint this kind of semi-apocalyptic picture of where we're going to end up. And as a consequence, people really puckered up and stopped investing in things.

+ +

I would say that the other side of it is now much of the world understands what it's like to not have access to quality healthcare or even access to healthcare. You see people not going to the hospital for things that they ought to and then suffering the consequences at home, like, let's say, not going for that heart checkup, and then you having a heart attack at home and passing when you otherwise wouldn't have. Or even cancer patients having to delay their therapy because the hospital is just too full.

+ +

So this concept of telemedicine which has always been resisted by both the payers and providers for being infeasible, or inaccurate, or impossible to fund properly, suddenly had to be done. And the concept of telemedicine is fairly old. I mean, how else would you treat your astronauts in space in the '60s if they got sick? So this is something that NASA thought of and invented and implemented, you know, decades and decades ago. And finally, this came forward.

+ +

And I was pleasantly surprised to see...and again, I'll quote the U.S. here where The Center for Medicare & Medicaid Services or CMS actually reimbursed a bunch of remote procedure codes, which is pretty amazing. And I think that was opening Pandora's Box. There's no going back from that.

+ +

So I think telemedicine is absolutely here to stay. And the real challenge now is really how to make it more user-friendly, how to improve it, how to improve the decisions that come from it. I really don't think it's going back. And as a consequence of this, it's really benefited a lot of our startups that were trying to build this remote-connected future anyway.

+ +

CHAD: Has there also been an influx of those kinds of startups?

+ +

JOSEPH: Absolutely. I would say that there has been a veritable Cambrian explosion of startups where everyone and their uncle is starting a healthtech startup as well as a healthtech fund. I see a lot of new funds coming up promising to invest in this space. So I think it's good in that there's going to be a lot of really new ideas, and hopefully, it's going to improve the standard of care for everyone around the world. But at the same time, it is creating a lot of noise, and it's becoming increasingly difficult to filter through that.

+ +

CHAD: Do the solutions tend to be local? I guess the nature of my question was, you know, like messaging apps. [laughs] Different countries have different popular messaging apps. What do you see as the penetration of different telemedicine solutions in the different countries? Do you think it's going to be, oh, you know, this is popular in this country? Or do you think it's possible for one company to come in and really have a significant impact in the market across multiple markets?

+ +

JOSEPH: Yeah, I think it's eventually going to be the latter. So at the start, you do see that you have your national champions. And like instant messaging apps, it's kind of like a 90-10 rule where the number 1 player takes 90% of the market, number 2 takes most of what's left, and then number 3 player caters to some niche or another. And I see two competing forces here; one is, yes, there may be a big player like Babylon or Crew who comes in and rolls up everything backed by heaps of capital.

+ +

But the other thing could also be that all the health systems start saying, "You know what? Why are we working with an external company? Why don't we just develop all these capabilities ourselves and then keep the patient captive?" And you are starting to see middleware providers who are basically providing that telemedicine layer, white-labeling it, or giving API access to the providers themselves, the legacy providers themselves, and then allowing them to do that.

+ +

And I actually saw this statistic...I don't know how accurate it was, but I saw a chart in the U.S. that white-labeled or internal telemedicine consults exceeded the number of Teladoc consultations, which is the largest platform in the U.S., at some point last year.

+ +

CHAD: I'm wondering, do you know if Teladoc uses Twilio?

+ +

JOSEPH: I really should know the answer to that question, but unfortunately, I do not.

+ +

CHAD: Because my sense is the real winner in this game might be companies like Twilio because I think everyone is using them. [laughs]

+ +

JOSEPH: That makes a ton of sense. So when we do look at some investments, we actually want to invest in middleware because why duke it out to be the platform when you're the utility provider?

+ +

CHAD: So let's turn our attention to the actual creation of the fund. And I know you just opened your second fund last month, right?

+ +

JOSEPH: Actually, this month. I mean, last month was the paperwork, but it takes time for stuff to get approved.

+ +

CHAD: Yeah, fair enough. So you already said actually starting a fund was, I think you said, the last thing on earth that you wanted to do. Why was that the last thing you wanted to do?

+ +

JOSEPH: Frankly, it was a whole lot more uncertainty than I was prepared to handle at the time. And I was either blessed or cursed with this momentary clarity of purpose where I knew with all my being that this is what I wanted to do with myself for, if not the rest of my life, a very long time. And the only alternative, or rather the only choice to pursue this at the time, was really starting a fund. So that's what I had to do, right?

+ +

CHAD: And how large was the first fund?

+ +

JOSEPH: It was pretty small; it was $7.6 million, which in local currency equates to a nice number of just above 10 million sings.

+ +

CHAD: And where did you...I'm going to ask where that ended up coming from. But in terms of the mechanics of actually starting a fund, what did that look like?

+ +

JOSEPH: Well, it depends on each market. But typically, what happens is you need to first have permission from the regulator in order to actually start and run a fund. So in Singapore, you need to apply for a venture capital fund management license from the Monetary Authority of Singapore. That's what had to be done first, and we got that approved in a pretty good time, actually. I think we might have captured a lull period because now, with all the funds coming out, I've heard the queue is months long in some cases.

+ +

And then came the business of incorporating the fund itself and then starting to draft all the legal paperwork, the conditions, the private memorandum or prospectus, depending on which geography and how regulated you are, that you show around to investors once they've expressed interest in learning substantially more details about your fund beyond what a simple PowerPoint deck or a casual coffee conversation can yield.

+ +

And then you start collecting commitments, and then you start collecting the money. And at some point, you have enough money to say, all right, we'll do a close or first close, and that then gives you permission to start deploying that money into investments. And some funds they'll only do one close, some funds will do a first close, and then a final close when they get the rest of the money in or some money committed and then calling the rest of it to come in. Or some will do multiple closes just so that they have the ability to keep deploying continuously while they're doing this fundraising process.

+ +

And in our case, we were doing rolling closes. So we would close every few months, and we'd continue to deploy. And by the time we finished fundraising, we actually already had nine companies out of the 15 that we have in our portfolio done. So it really depends on all sorts of different factors, which we probably don't have that much time to get into. And I risk perhaps putting my foot in my mouth and misspeaking if I give too many examples.

+ +

CHAD: [laughs] When it comes to starting a fund, how cookie-cutter is it? Or do you find yourself having to create everything from scratch, all the legal documents, whatever platform you might be...or access you might be giving to the people who are contributing to the fund?

+ +

JOSEPH: I'd say, again, it depends where you are. I think in the U.S. and especially with the advent of great service providers platforms like AngelList and Assure, it is super cookie-cutter. In our part of the world, I still think it's somewhat cookie-cutter, but we got a little too cute.

+ +

CHAD: [chuckles]

+ +

JOSEPH: We thought, okay, it's our first time doing a fund. I've been an LP in other funds. What did I wish I had as an LP? And as a consequence, we introduced some hurdle rates of tiered carry, and even zero carry if we don't hit a certain return. And all that really did was just create more questions from the investors. So we should have probably done it as cookie-cutter as possible in hindsight.

+ +

CHAD: So I often hear from founders who talk about how it's important to have a VC fund behind you that you agree with, and want to work with, and are excited about, and that can be value additive. Do you need, as someone raising a fund, do you need to consider things like that or other things when it comes to the people you're taking money from the fund?

+ +

JOSEPH: Absolutely. Maybe knock on wood here, but our relative inexperience when starting a fund probably selected out all the folks who might not have gotten along with us anyway. And the fact that we're pretty straightforward and direct with what we want to do in our objectives probably helped with that selection process as well on the positive side. But I absolutely, absolutely can recommend having that alignment of values and mission with those who are on the journey with you for a good decade. It's like getting married, right?

+ +

CHAD: Yeah. Well, so when you're planning a fund and thinking about time horizons, is a decade what you're thinking about?

+ +

JOSEPH: Yeah, all things considered. So our fund lifetime was eight years from final close. But still, it takes time to raise the fund and plan the fund, and you have people that are on board even before the fund begins. So it is a decade-long relationship, at least. And then some of the larger funds because they want to have a longer investment period, will push that out even further where they're going to be a 10-year fund from final close.

+ +

And if you have enough of your portfolio that hasn't exited yet but still has some value to be uncovered, you may ask your investors to extend the fund life even further. So this is a supremely long relationship that you have. And aside from evergreen funds that don't have a fund lifetime, I think this is about as long as it gets, although I have seen some people float the idea of a 20-year fund or a 50-year fund, but that's really not widely practiced. I think five years is the fastest I've seen, and ten seems to be the average.

+ +

CHAD: Where did that first fund come from? How did you drum up the interest and decide who would be a part of it?

+ +

JOSEPH: It's really the folks who have known me the longest or worked with me. So you know how they say when you're raising money for a startup, you get it from the three F's, Friends, Family, and Fools? For funds and for first-time fund managers, I think it's a pretty analogous group of people, although I don't think we have any fools.

+ +

CHAD: [laughs]

+ +

JOSEPH: And, unfortunately, don't have family either. So it's really all friends, old co-workers, old clients, and then the people that they introduced us to. There were some serendipitous moments where people liked what I said at a conference, or we asked a tough question. And people asked, "Well, how can you ask such a tough question?" Then they got to know us and then decide to invest from there. But majority of it was just introductions, warm introductions. We never did any cold emails.

+ +

CHAD: Have there been any exits in the first fund?

+ +

JOSEPH: Not just yet. We do come in as either the first or second investor in these companies. So there is quite a long journey that we expect before we, you know, see some exits. There may be some this year. But if I look back at my angel investments, there was only real serious talk of an exit at the six-year mark for one of the companies that's doing really well. And even that exit turned out to be just another, you know, the investor changed their mind, and instead of buying the company, they decided to just invest more money into it. So this is a long journey.

+ +

CHAD: Yeah, definitely. Did that make putting together the second fund any harder, or is that what everyone expects?

+ +

JOSEPH: I am cautiously optimistic because we're still so early in our journey that the only folks we've really spoken with are the ones who invested in our first fund or passed on our first fund because they don't back first-time fund managers. They come to expect that your second fund is built on the momentum of the first fund. And it's really your third fund that's built on the exit and actual realized track record of your first fund.

+ +

CHAD: That makes sense. What do you think is next for Verge HealthTech?

+ +

JOSEPH: Well, first things first, we got to get started with the second fund and see if we can build something to scale. I mean, the first fund was an experiment. It was a small fund, you know. Could we build the world's seed-stage global impact healthtech fund on basically a shoestring? And the second fund is now let's take everything that we wish we had for the first fund and scale it up so bigger initial ticket sizes because we want to own more, the ability to follow on properly, the ability to do more deals, which requires a much bigger team which we now have.

+ +

As well as to go back and support the winners of our first fund as well as some of the companies that maybe we made a mistake on and passed but still have a strong enough relationship to revisit and get them on the next round or the round after that, or just new companies that the market has moved. You know, the area that we might have been really interested in at the seed stage is now a pre-A stage or an A stage.

+ +

So that's really what we want to do with the second one. And it would be amazing to see where this goes. I'm thrilled that we actually have, well, I think, one of the best healthtech investment teams in the world; maybe I'm slightly biased with this.

+ +

CHAD: [laughs]

+ +

JOSEPH: And I'm excited to see what we can do together.

+ +

CHAD: That's great. Well, I wish you the best. And I really appreciate you for stopping by and sharing with us. If folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

JOSEPH: Probably LinkedIn is the best way to do it. Also, I have a blog on Medium, which I'm sure can be linked in the show notes. I've been really bad...I've been traveling intensely in the past half-year. But I promise my next blog post will be interesting.

+ +

CHAD: [laughs]

+ +

JOSEPH: Because I just got back from Rwanda and Saudi Arabia, which are two very, very different countries, however, with a great emphasis on improving healthcare, especially on the digital side.

+ +

CHAD: Well, that's exciting. So folks definitely can find the links for that in the notes, which you can find the notes; you can subscribe to the show and a full transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Joseph Mocanu.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bk4VcpfN + + ]]> + + Chad Pytel + Joseph Mocanu + + + 421: Benchmark Labs with Carlos F. Gaitan Ospina + https://podcast.thoughtbot.com/421 + 7db8b9c6-0972-4439-a5a4-fdd45290cf14 + Thu, 05 May 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Carlos F. Gaitan Ospina is the Founder and CEO of Benchmark Labs, which provides IoT-based weather forecasting solutions for the agriculture, energy, and insurance sectors worldwide using proprietary machine-learning software. + +Chad talks with Carlos about creating the company, the hardware they're producing and what it is doing, and where the machine learning comes into play. + 34:41 + no + + + Carlos F. Gaitan Ospina is the Founder and CEO of Benchmark Labs, which provides IoT-based weather forecasting solutions for the agriculture, energy, and insurance sectors worldwide using proprietary machine-learning software. +Chad talks with Carlos about creating the company, the hardware they're producing and what it is doing, and where the machine learning comes into play. +Benchmark Labs (https://www.benchmarklabs.com/) +Follow Benchmark Labs on Twitter (https://twitter.com/labsbenchmark), Instagram (https://www.instagram.com/benchmarklabs/), or LinkedIn (https://www.linkedin.com/company/benchmark-labs-inc/). +Follow Carlos on Twitter (https://twitter.com/cfgaitan) or LinkedIn (https://www.linkedin.com/in/carlos-felipe-gaitan-ospina-3765808/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Carlos Gaitan, the Founder and CEO of Benchmark Labs, which provides IoT-based weather forecasting solutions for the agriculture, energy, and insurance sectors worldwide using proprietary machine-learning software. Carlos, thank you very much for joining me. +CARLOS: Thank you for the invitation, Chad. It's a pleasure to join you here. +CHAD: You work in a variety of different industries with weather forecasting solutions using machine learning. I'm really curious, at a high level, how did you get to where you created Benchmark Labs today? +CARLOS: Oh, thank you, Chad. That's a great question. I think that in many ways, it's a combination of life experiences and lots of user feedback. As a background, my mum worked for 28 years in the National Federation of Coffee Growers in my native Columbia. And we experience basically the effects of weather, La Niña, El Niño, local conditions, pests on the coffee growers. I remember growing up looking at the price in The New York Stock Exchange if the pound of coffee was going to be more than $1 or not [laughs] and so on. +So, you know, we had a very severe drought in Colombia, and Colombia was heavily dependent in hydropower at that time. And I remember that we even had to study with candlelight and move to a spring savings time for the first time in the country. The country is in the equator, so you can imagine moving the clock was unheard of. So since then, I was always passionate about hydrology, the water cycle, why this happened, how weather can affect the economy at that level that people have to change their working habits. +I did civil engineering hydrology, then studied these new applications of machine learning technologies, hydroinformatics, did my studies there in Columbia, my bachelor's, my master's. Then I was fortunate to go to The University of British Columbia to study my Ph.D. in Atmospheric Sciences. And then, after I finished, I moved to The United States to work at the Geophysical Fluid Dynamics Laboratory in Princeton with close collaboration with the NOAA, the USGS. +And that gave that perspective also of understanding how weather climate models were done at the Department of Commerce level but also to understand the users on how they interact with weather data or climate data and what were the needs that they were expecting from the National Weather Service and the Department of Commerce and NOAA that not necessarily were fulfilled with the current information. +So then I moved to the private sector, joined a hardware company, and met my co-founder of Benchmark Labs there then moved to California to work on consultancy of climate change assessments. But since the time at the Department of Commerce, it became very clear that what farmers and what users wanted was weather information that was more actionable, that was tailored to their specific location, especially for specialty crops. +Think about wineries, or coffee growers, orchids, stone fruits; they depend heavily on weather, and the information from the National Weather Services was just too coarse for them. And sometimes, there are huge errors in terms of temperatures that were recorded from their farm versus what the National Weather Service was doing. And that's why we decided to create Benchmark Labs to basically solve that problem, correct those errors, and give the information that the users needed when they needed it. +CHAD: Did you ever just consider becoming a TV weather person? +CARLOS: [laughs] +CHAD: It seems it may be easier. +CARLOS: [laughs] Nah. That's a very good point. +CHAD: [laughs] +CARLOS: And I have great respect with my colleagues that went into forecast meteorology and TV persons. I remember some of my lab mates practicing in front of a green screen when we were doing the Ph.D. +CHAD: [laughs] +CARLOS: That was an interesting scenario. [laughs] However, growing up in Colombia, the weather forecasts were not very, let's say, accurate to a certain extent, and we did the opposite than the weatherman suggested. +CHAD: [laughs] +CARLOS: So I guess that steered me towards following that path. [laughs] +CHAD: So it totally resonates with me this idea that, you know, especially for...I've been on the West Coast before where you go over a hill and the weather it's like 20 degrees hotter and sunny and on one side of the hill, it was cold and foggy. We went on a great company trip many years ago to visit some Napa vineyards, and I was surprised by that. So I can imagine how that local information just doesn't match the global information that farmers might be getting. So what is the hardware that you're actually producing, and what is it doing? What does it look like? +CARLOS: [laughs] Great question. So I will go back to your story about Napa and Sonoma, and the reality is that's exactly a problem that growers face; national weather agencies give averages over a big region. They divide the world in boxes, and everybody inside of a box receives exactly the same forecast. +And if you are especially in the coast or you're in specialty agriculture, you understand that weather changes with elevation. Depending on which side of the mountain you are, you could receive all the rain or no rain at all. If you are near the shores, you could also get more wind, different types of clouds, all of those situations affect the conditions at the farm. +And going back to the situation of Napa and Sonoma, Burgundy or the Mediterranean Basin, they all believe in the value of what they call the terroir, that is what makes also unique their products. They're indigenous, and they understand at a very fundamental point how the local conditions from the soil, from the vegetation, makes their farm unique. +So what we do is we use IoT sensors, basically hardware sensors that monitor environmental variables. We refer to them in the atmospheric science world as weather stations. I had a talk with some users when I said the term weather station. They imagined a big construction or a building with a TV station on a radar or something. But in this case, there are IoT devices that are totally portable, the size of a Wi-Fi modem in some cases. And we use those sensors as ground truth that will basically tell us the local conditions. We use the information from the National Weather Services and the information from those IoT sensors and correct the forecast as they come. +CHAD: And is that where the machine learning comes in because it's actually correcting the forecast being received? +CARLOS: Exactly, our machine learning aspect of it is fully operational, non-linear correction of weather data as it comes in from the National Weather Services to correct it to the conditions that are experienced at the farm level, at the sensor level. +And a farm could be also an agricultural farm, or it could be a solar farm, a wind farm. Or, as we talk with some users in ski resorts that actually they consider as snow farmers, it's also affected by microclimates. So at the end, it is about providing value to all these areas affected by microclimates that are not being resolved correctly by the current generation of forecast from the National Weather Services. +CHAD: Are most customers able to get the coverage that they need with one weather station, or are they deploying multiple ones? +CARLOS: So that's a great question, and the answer probably is it depends. Our customers, original customers, have thousands of stations over multiple fields under management. For specialty crops, it's common to have multiple IoT sensors in one acre. For other scenarios, they might have only one station or one sensor every 10 acres or so on, so it depends on the condition. It depends on how technologically inclined are the users if they already invested in these IoT sensors or if they are looking into buying IoT sensors and then scaling up the number of sensors in their farms. +CHAD: How do all the sensors report their data back? +CARLOS: That is a very interesting question because they are, let's say, tens of hardware manufacturers globally. We also created kind of a Rosetta Stone that puts all the sensors to communicate to our back-end systems. We integrate different languages of each hardware manufacturer. It has its own ways of naming the variables. So we do the translation in our end. We receive the data via an API. These IoT devices are Internet of Things in many ways because they transmit data via Wi-Fi, satellite internet, you know, cellular. +CHAD: Cell, yeah. So different manufacturers might have different ways of actual communication, not just the protocol, but one box might be using Wi-Fi, and another one might be using a satellite. +CARLOS: Exactly. And sometimes, many manufacturers give you the options of connecting even using Wi-Fi or Bluetooth for IoT sensors that are near, let's say, a farm that has internet connectivity. If they are on the field farther away, they might need to get access to a data plan from a cellular carrier, 3G usually or 5G. In some areas, there is limited coverage so far. And if it's a very remote area, there are options to get satellite coverage. +CHAD: Now, I'm asking somewhat naive questions based on my understanding. And so if I start butting up against proprietary information, just tell me, "No." That's totally fine. +CARLOS: [laughs] +CHAD: So when we're thinking about the amount of data coming in from all of these different weather stations that your customers have, is it a lot of data? Is it a lot of data points? +CARLOS: [laughs] It's a great question. So in many ways, yeah, each weather station communicates at different frequency. Sometimes what we are offering now is hourly transmission rates, but we also have access to government stations that sometimes only refresh once per day. So yes, it's a lot of data coming in, most of the data from the weather stations. Fortunately, it can be transmitted as a txt file, or it's only for one location. So the files are not big, but they are many per day. And so, we have probably done millions of operations already to assimilate data and provide the forecast. +While on the other hand, The National Weather Service provides one forecast for the globe, let's say every...some models are every hour, other models are every six hours, and so on. So that is more, let's say, a bigger data set because it's a global data set that then you have to query to extract the information locally that is relevant for your servers, for your users. +CHAD: Yeah. And I think it's neat how this is all happening centrally from all the data coming in, right? +CARLOS: Yeah, exactly. We get data coming in for each specific location. We do the corrections, and we provide the forecasts. So there are lots of operations involved in the data handling activities, pre-processing, post-processing, but it's very rewarding at the end to provide the forecasts that are tailored to specific locations. +And we had seen users that they basically told us, "Okay, we are using provider B or C; can you beat them? Show us that you can beat them, and the contract will be yours." So we showed them, and then they are like, "Yeah, that's fantastic. This is exactly what we have been looking for, information that is more accurate for our farms," so yeah. +CHAD: Now, does your system correct itself based on what actually happened in an area after the modified forecast goes out? +CARLOS: That's not a very relevant question because some of the models are static. I used my experience when I did an internship in Environment Canada, and I found that they were adjusting their models, let's say four times per, at least the operational models they had, four times per year. They kind of tweaked them to the local, let's say, spring, summer, fall, winter conditions. In our case, we make our models to correct themselves as more data comes in so they can adjust to weather events and have short-term memory, let's say, of what they will wait heavily on and forget the distant past. +CHAD: I mean, it seems obvious, not necessarily easy but obvious, that you've made a prediction about what the weather is going to be, and you have all the data coming in from the stations to confirm whether your prediction was correct or not. So I'm sure it's not easy to adjust the model based on that. +CARLOS: [laughs] +CHAD: That seems obvious to me. +CARLOS: Yeah, it's just a different approach in many ways. As you said, it's obvious because the users usually care about a specific location, at least our users. We understand that for national security or aviation, they require a model that provides coverage over a wider area, like sometimes continents. But for agricultural users, they care about their farms, and the farms will not move in space. So -- +CHAD: Well, technically, they are moving in space; it's just the weather goes along with it. +CARLOS: [laughs] So yeah, I guess that it's just a different way of tackling the problem. We focus on doing these forecasts to each specific location instead of having a forecast done for the whole globe that could be used in many different locations or for many different industries, but it's not necessarily tailored to any industry-specific or location-specific. +CHAD: Yeah, that's great. +Mid-Roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So have you managed to bring it full circle now, and are there coffee growers in Colombia that are using your solution? +CARLOS: [laughs] I hope so. We have talked with coffee growers for sure. They care about temperature gradients. And I really think that going to Colombia as we scale will make the whole platform easier to use. I think that we can go full circle soon, sooner rather than later, into Colombia. +We got support from the World Trade Center here in San Diego to do commercialization assistance to translate our solution from English to other languages. So we will be tackling Spanish, French, Italian in the very near future because it's important to offer the forecast also in a way that they could interact natively without having to have the limitation of using an English language platform into their day-to-day life. But yeah, full circle probably we’ll be going full circle soon. +CHAD: So language is one barrier to scaling and to adoption. Are there other ones that are typical barriers of adoption for your customers? +CARLOS: We are very competitive here in the North American market, the European markets. Our prices are in dollars. But that by itself is a problem for emerging economies; for example, you know, $100 here is not the same thing as $100 in other countries. We have to take into consideration exchange rates or the amount of disposable income that they will have for their operations. +CHAD: And I'm not super educated about it, but I know that there are certain industries in agriculture where the growers are particularly pressed for margins, and coffee is one of them, right? +CARLOS: Exactly. So, fortunately, in many ways, for the bigger crops, specialty crops they are traded, and the prices are linked to U.S. dollars so that can be translated, our services can be absorbed, let's say. For the smaller crops that are not traded or that just stay locally, the price is not linked to the U.S. exchange; then it's definitely a bigger barrier for them. But hopefully, we will get to a point if we have a sufficiently large adoption in North America and the developed world; these technologies could be subsidized or made more accessible in other economies. +CHAD: What are some of the concerns that growers have? Take the specialty crops, for example, is it a matter of are they doing this because they want to make the best product possible, or is it because they want to prevent crop loss? +CARLOS: It is both, actually. The uses of weather information in agriculture varies, as you said. There are many different applications; one is to get more actionable alerts. For example, we saw what happened in Burgundy last year where a substantial part of their region lost their crops, close to 80% maybe. I don't remember the number, but it was definitely substantial. And so, having more accurate forecasts and alerts gives them an opportunity to adapt better, to get cover, protect their fields to a certain extent. Weather information affects also pests and disease models, so application of fertilizer with spraying is also affected by local conditions. +In many ways, for the operations that are very, let's say, sophisticated, some of them even link the sugar content on the fruit to weather conditions. And understanding how these weather conditions affect sugars could tell them when is the optimal time for them to, let's say, harvest? And the difference in the sugar content might determine the difference between higher margins or so-so margins [laughs] for their yield. +So yeah, it's a combination of quality of the product. It's a combination of preventing loss of the product. And it's also labor scheduling and activities, for example, that are regulated by OSHA that prevent farm operations to maybe don't, let's say if they are like temperatures above 95 Fahrenheit or 100 Fahrenheit. So having that extra information in alerts will also help them with farm management operations. +CHAD: So can you give me a sense of the stage you're at or the scale you're at now with the business and where you see your next stages of growth being? +CARLOS: Thank you. Yeah, great. So we are fortunate to have scaled this solution beyond California. We are now a global platform. We are providing forecast to Spain. Recently, we got contacted by some growers in South America, so we are testing for avocado growers in Brazil and Colombia, for example. So I'm not serving yet coffee growers in Colombia, but the avocado growers in Colombia, it seems that they got a hold on what we do, [laughs] so it is getting there. And now we have the resources, the ability to go global and offer this anywhere in the world that is connected with an IoT device. So it's fully operational. +And we are now in the midst of fundraising to scale the team, provide the customer success operations, and to support growers in different geographies, to support growers of different crops. And I think that if we are going to be successful globally, it starts with customer support, customer success, and understanding your users' needs, so they don't feel that, again, they will receive a one size fits all vanilla-like solution and that we really care about why specialty crops are special. +CHAD: So when you were just starting out, who was the first team member that you added to the team? +CARLOS: Oh, it was great. So in many ways, I thank the Economic Development Council of San Diego for funding a set of interns in data science, weather analytics, and business development. So our first hires, in many ways, were supported thanks to the Economic Development Council. +We were the two founders, and then we got support in business development to understand which, for example, specialty crops really care about weather. Then some data science interns, data scientists that helped us with grants that we did for the National Science Foundation, and NASA that we got...we supported one of the grants. During COVID times, we participated in a very interesting opportunity to know the effect of COVID on forest fires, for example, and that was in collaboration with NASA. +So first hires were interns, entry-level positions in data science, in back-end engineering, and then front-end business development. Now we are very excited to be expanding the team. We recently hired a Chief Product Officer with ten years of experience in Bloomberg, experience with visualizations, and talking to customers and users. So I think that for us, it's very important to, again, I reiterate, to have the ability to provide a great user experience, to provide meaningful information for specialty crops so they feel that they are special. +CHAD: You mentioned that you got some business development help using those grants. But right now, is the actual sales work being done by the founding team? +CARLOS: Yeah, at the beginning, as a founding team in a small startup, you have to wear multiple hats. So yeah, it's very common, and in many ways, I appreciate that we didn't rush to hire in terms of sales too early because it's important that the founding team understands the user perspectives, their needs, what they call the pain points to understand how to steer product into that direction. +And then sales will follow once you have a solution that is highly needed, that users really like and that it can be shown that it can be scaled globally. So we are working on scaling, on accuracy of the forecasts. And yeah, next hires will be to get somebody that will help us in sales and can bring us to the next level. +CHAD: What does the sales cycle look like for the kinds of customers you have now? Do they tend to be smaller, or do they tend to be larger enterprise customers? +CARLOS: So, in the beginning, we worked with smaller enterprises to understand how to use the data, for example, connect the data from one or five sensors transmitted online. So dealing with smaller enterprises, farmers was optimal at that point as a company. And now, we are focusing more on businesses, farm managers, or management companies that have hundreds, sometimes thousands of sensors on their management. +So we deal with more like business to business instead of going direct to grower at this stage because, as we were mentioning earlier, we're a small company, and going direct to grower requires lots of support and dedication in terms of dedicated agents and sales teams. +CHAD: Do those companies tend to have long sales cycles? +CARLOS: The bigger ones, yes. If you are talking about publicly traded companies, they will want to start with pilots then validate them. And you can move at different timescales with them that are not necessarily aligned with the startups at this stage. But there are some farm managers that have a way higher frequency of decision making. So their sale cycle could be one month, two months instead of having to build a relationship for years. +CHAD: You mentioned the pilots, and you mentioned earlier telling the story about a customer that said, you know, "If you can provide us with better data," but I think companies as they scale or as they talk to potential customers, you also don't want to take on too much work that you should be charging for to be able to do that pilot. How do you strike that balance? +CARLOS: It's a fascinating question. And I think that from a founding member perspective, let's say, it goes as a function of the stage of the company and what other, not necessarily monetary, benefits you can get from these pilots. We have been even recommended to not have unpaid pilots anymore, for example. I think that it's important at the beginning to get access to the information that you need to validate the technology with users that really care about what you're building. +And sometimes, there are different ways that these pilots can be structured in a way that the final user might give you a reference or might spend time with you doing the quality control, quality check, saying what kind of features they like, so that's also very important as a young startup. +As you grow, probably once you have that validation, there is no need necessarily to take into endeavors that will lead to unpaid pilots that you don’t know if there's a clear end to that. And you can move to a more structured pilot program that has clear deliverables, and at the end of window, a decision will be made depending on the set of topics that were agreed between the companies. +CHAD: You might even be able to get away without pilots if you can make a strong case by showing other case studies that are relevant to that potential customer or where you explain, oh, you know, these people had a similar situation to you and here's how it's solved, and here's the success that they had. +CARLOS: Totally. You nailed it. It's in many ways to sometimes build credibility, find analogues in the sector, or a use case that can be comparable to the pain point that another user might have. And it could be, let's start with the avocado growers in Brazil, and they have probably the same pain points that they have with avocado growers in Colombia. Once we have that sorted out, then we probably can go and talk with avocado growers here in California or Mexico, Central America and tell them, "Hey, this is the value that we've unlocked in Brazil. Do you have a similar problem?" +CHAD: What I have found is that this is one of the important reasons why you have to have a good product which is part of what you've been saying all along, you know, you really wanted to focus on making sure the product was working and that it was good. Because when you do, then you can also use referrals, you know, not referrals, but like, hey, you want to talk to this avocado grower, and they'll be happy to talk with another potential customer because they're excited about what you've done for them and been able to do with them. +CARLOS: Totally, totally. And agriculture is always open to new technologies, but they are traditional in many ways. And it's a small circle, and I think that it is very important to build products right and really care about what you're doing and your end-users. Build together. Don't come necessarily with assumptions saying, "Hey, here agricultural grower A, I have a solution that will change your life," without knowing necessarily where are they coming from and their life experiences, and how they interact with products before. +So yeah, I totally see the benefit of referrals. Word of mouth is very big, going to conferences with agricultural growers. There are big networking events that could help us more than just going and doing a Google ad campaign, for example, at this stage. +CHAD: I think that's probably an important lesson that not only applies in agriculture but in a lot of industries. And I really appreciate you stopping by to share with us. And I really wish you the best of luck as you progress in your journey at Benchmark. +CARLOS: Oh, thank you very much. I really appreciate it, and I hope that we can continue the conversation here. Just count with us anytime that you need to talk about weather, agriculture, IoT sensors. Happy to help the audience too, and always discuss what's out there to help the Giant Robots community. [laughs] +CHAD: Carlos, if people want to get in touch with you or find out more about the company, where are the best places for them to do that? +CARLOS: Go to benchmarklabs.com and then fill out a form there. And we will definitely be in touch with all of you. I will personally answer all the queries. I'm very, very happy to share our technology, share what we are building. And we are so excited because by having this technology, you can help save water, energy, and even pesticide use, and that's a huge contribution to the environment as we move forward. So yeah, thank you very much again for the invitation, and I'm here; count with me as a future resource. +CHAD: Wonderful. And you can subscribe to the show and find notes and links along with an entire transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Carlos F. Gaitan Ospina. + + + Carlos F. Gaitan Ospina is the Founder and CEO of Benchmark Labs, which provides IoT-based weather forecasting solutions for the agriculture, energy, and insurance sectors worldwide using proprietary machine-learning software.

+ +

Chad talks with Carlos about creating the company, the hardware they're producing and what it is doing, and where the machine learning comes into play.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Carlos Gaitan, the Founder and CEO of Benchmark Labs, which provides IoT-based weather forecasting solutions for the agriculture, energy, and insurance sectors worldwide using proprietary machine-learning software. Carlos, thank you very much for joining me.

+ +

CARLOS: Thank you for the invitation, Chad. It's a pleasure to join you here.

+ +

CHAD: You work in a variety of different industries with weather forecasting solutions using machine learning. I'm really curious, at a high level, how did you get to where you created Benchmark Labs today?

+ +

CARLOS: Oh, thank you, Chad. That's a great question. I think that in many ways, it's a combination of life experiences and lots of user feedback. As a background, my mum worked for 28 years in the National Federation of Coffee Growers in my native Columbia. And we experience basically the effects of weather, La Niña, El Niño, local conditions, pests on the coffee growers. I remember growing up looking at the price in The New York Stock Exchange if the pound of coffee was going to be more than $1 or not [laughs] and so on.

+ +

So, you know, we had a very severe drought in Colombia, and Colombia was heavily dependent in hydropower at that time. And I remember that we even had to study with candlelight and move to a spring savings time for the first time in the country. The country is in the equator, so you can imagine moving the clock was unheard of. So since then, I was always passionate about hydrology, the water cycle, why this happened, how weather can affect the economy at that level that people have to change their working habits.

+ +

I did civil engineering hydrology, then studied these new applications of machine learning technologies, hydroinformatics, did my studies there in Columbia, my bachelor's, my master's. Then I was fortunate to go to The University of British Columbia to study my Ph.D. in Atmospheric Sciences. And then, after I finished, I moved to The United States to work at the Geophysical Fluid Dynamics Laboratory in Princeton with close collaboration with the NOAA, the USGS.

+ +

And that gave that perspective also of understanding how weather climate models were done at the Department of Commerce level but also to understand the users on how they interact with weather data or climate data and what were the needs that they were expecting from the National Weather Service and the Department of Commerce and NOAA that not necessarily were fulfilled with the current information.

+ +

So then I moved to the private sector, joined a hardware company, and met my co-founder of Benchmark Labs there then moved to California to work on consultancy of climate change assessments. But since the time at the Department of Commerce, it became very clear that what farmers and what users wanted was weather information that was more actionable, that was tailored to their specific location, especially for specialty crops.

+ +

Think about wineries, or coffee growers, orchids, stone fruits; they depend heavily on weather, and the information from the National Weather Services was just too coarse for them. And sometimes, there are huge errors in terms of temperatures that were recorded from their farm versus what the National Weather Service was doing. And that's why we decided to create Benchmark Labs to basically solve that problem, correct those errors, and give the information that the users needed when they needed it.

+ +

CHAD: Did you ever just consider becoming a TV weather person?

+ +

CARLOS: [laughs]

+ +

CHAD: It seems it may be easier.

+ +

CARLOS: [laughs] Nah. That's a very good point.

+ +

CHAD: [laughs]

+ +

CARLOS: And I have great respect with my colleagues that went into forecast meteorology and TV persons. I remember some of my lab mates practicing in front of a green screen when we were doing the Ph.D.

+ +

CHAD: [laughs]

+ +

CARLOS: That was an interesting scenario. [laughs] However, growing up in Colombia, the weather forecasts were not very, let's say, accurate to a certain extent, and we did the opposite than the weatherman suggested.

+ +

CHAD: [laughs]

+ +

CARLOS: So I guess that steered me towards following that path. [laughs]

+ +

CHAD: So it totally resonates with me this idea that, you know, especially for...I've been on the West Coast before where you go over a hill and the weather it's like 20 degrees hotter and sunny and on one side of the hill, it was cold and foggy. We went on a great company trip many years ago to visit some Napa vineyards, and I was surprised by that. So I can imagine how that local information just doesn't match the global information that farmers might be getting. So what is the hardware that you're actually producing, and what is it doing? What does it look like?

+ +

CARLOS: [laughs] Great question. So I will go back to your story about Napa and Sonoma, and the reality is that's exactly a problem that growers face; national weather agencies give averages over a big region. They divide the world in boxes, and everybody inside of a box receives exactly the same forecast.

+ +

And if you are especially in the coast or you're in specialty agriculture, you understand that weather changes with elevation. Depending on which side of the mountain you are, you could receive all the rain or no rain at all. If you are near the shores, you could also get more wind, different types of clouds, all of those situations affect the conditions at the farm.

+ +

And going back to the situation of Napa and Sonoma, Burgundy or the Mediterranean Basin, they all believe in the value of what they call the terroir, that is what makes also unique their products. They're indigenous, and they understand at a very fundamental point how the local conditions from the soil, from the vegetation, makes their farm unique.

+ +

So what we do is we use IoT sensors, basically hardware sensors that monitor environmental variables. We refer to them in the atmospheric science world as weather stations. I had a talk with some users when I said the term weather station. They imagined a big construction or a building with a TV station on a radar or something. But in this case, there are IoT devices that are totally portable, the size of a Wi-Fi modem in some cases. And we use those sensors as ground truth that will basically tell us the local conditions. We use the information from the National Weather Services and the information from those IoT sensors and correct the forecast as they come.

+ +

CHAD: And is that where the machine learning comes in because it's actually correcting the forecast being received?

+ +

CARLOS: Exactly, our machine learning aspect of it is fully operational, non-linear correction of weather data as it comes in from the National Weather Services to correct it to the conditions that are experienced at the farm level, at the sensor level.

+ +

And a farm could be also an agricultural farm, or it could be a solar farm, a wind farm. Or, as we talk with some users in ski resorts that actually they consider as snow farmers, it's also affected by microclimates. So at the end, it is about providing value to all these areas affected by microclimates that are not being resolved correctly by the current generation of forecast from the National Weather Services.

+ +

CHAD: Are most customers able to get the coverage that they need with one weather station, or are they deploying multiple ones?

+ +

CARLOS: So that's a great question, and the answer probably is it depends. Our customers, original customers, have thousands of stations over multiple fields under management. For specialty crops, it's common to have multiple IoT sensors in one acre. For other scenarios, they might have only one station or one sensor every 10 acres or so on, so it depends on the condition. It depends on how technologically inclined are the users if they already invested in these IoT sensors or if they are looking into buying IoT sensors and then scaling up the number of sensors in their farms.

+ +

CHAD: How do all the sensors report their data back?

+ +

CARLOS: That is a very interesting question because they are, let's say, tens of hardware manufacturers globally. We also created kind of a Rosetta Stone that puts all the sensors to communicate to our back-end systems. We integrate different languages of each hardware manufacturer. It has its own ways of naming the variables. So we do the translation in our end. We receive the data via an API. These IoT devices are Internet of Things in many ways because they transmit data via Wi-Fi, satellite internet, you know, cellular.

+ +

CHAD: Cell, yeah. So different manufacturers might have different ways of actual communication, not just the protocol, but one box might be using Wi-Fi, and another one might be using a satellite.

+ +

CARLOS: Exactly. And sometimes, many manufacturers give you the options of connecting even using Wi-Fi or Bluetooth for IoT sensors that are near, let's say, a farm that has internet connectivity. If they are on the field farther away, they might need to get access to a data plan from a cellular carrier, 3G usually or 5G. In some areas, there is limited coverage so far. And if it's a very remote area, there are options to get satellite coverage.

+ +

CHAD: Now, I'm asking somewhat naive questions based on my understanding. And so if I start butting up against proprietary information, just tell me, "No." That's totally fine.

+ +

CARLOS: [laughs]

+ +

CHAD: So when we're thinking about the amount of data coming in from all of these different weather stations that your customers have, is it a lot of data? Is it a lot of data points?

+ +

CARLOS: [laughs] It's a great question. So in many ways, yeah, each weather station communicates at different frequency. Sometimes what we are offering now is hourly transmission rates, but we also have access to government stations that sometimes only refresh once per day. So yes, it's a lot of data coming in, most of the data from the weather stations. Fortunately, it can be transmitted as a txt file, or it's only for one location. So the files are not big, but they are many per day. And so, we have probably done millions of operations already to assimilate data and provide the forecast.

+ +

While on the other hand, The National Weather Service provides one forecast for the globe, let's say every...some models are every hour, other models are every six hours, and so on. So that is more, let's say, a bigger data set because it's a global data set that then you have to query to extract the information locally that is relevant for your servers, for your users.

+ +

CHAD: Yeah. And I think it's neat how this is all happening centrally from all the data coming in, right?

+ +

CARLOS: Yeah, exactly. We get data coming in for each specific location. We do the corrections, and we provide the forecasts. So there are lots of operations involved in the data handling activities, pre-processing, post-processing, but it's very rewarding at the end to provide the forecasts that are tailored to specific locations.

+ +

And we had seen users that they basically told us, "Okay, we are using provider B or C; can you beat them? Show us that you can beat them, and the contract will be yours." So we showed them, and then they are like, "Yeah, that's fantastic. This is exactly what we have been looking for, information that is more accurate for our farms," so yeah.

+ +

CHAD: Now, does your system correct itself based on what actually happened in an area after the modified forecast goes out?

+ +

CARLOS: That's not a very relevant question because some of the models are static. I used my experience when I did an internship in Environment Canada, and I found that they were adjusting their models, let's say four times per, at least the operational models they had, four times per year. They kind of tweaked them to the local, let's say, spring, summer, fall, winter conditions. In our case, we make our models to correct themselves as more data comes in so they can adjust to weather events and have short-term memory, let's say, of what they will wait heavily on and forget the distant past.

+ +

CHAD: I mean, it seems obvious, not necessarily easy but obvious, that you've made a prediction about what the weather is going to be, and you have all the data coming in from the stations to confirm whether your prediction was correct or not. So I'm sure it's not easy to adjust the model based on that.

+ +

CARLOS: [laughs]

+ +

CHAD: That seems obvious to me.

+ +

CARLOS: Yeah, it's just a different approach in many ways. As you said, it's obvious because the users usually care about a specific location, at least our users. We understand that for national security or aviation, they require a model that provides coverage over a wider area, like sometimes continents. But for agricultural users, they care about their farms, and the farms will not move in space. So --

+ +

CHAD: Well, technically, they are moving in space; it's just the weather goes along with it.

+ +

CARLOS: [laughs] So yeah, I guess that it's just a different way of tackling the problem. We focus on doing these forecasts to each specific location instead of having a forecast done for the whole globe that could be used in many different locations or for many different industries, but it's not necessarily tailored to any industry-specific or location-specific.

+ +

CHAD: Yeah, that's great.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So have you managed to bring it full circle now, and are there coffee growers in Colombia that are using your solution?

+ +

CARLOS: [laughs] I hope so. We have talked with coffee growers for sure. They care about temperature gradients. And I really think that going to Colombia as we scale will make the whole platform easier to use. I think that we can go full circle soon, sooner rather than later, into Colombia.

+ +

We got support from the World Trade Center here in San Diego to do commercialization assistance to translate our solution from English to other languages. So we will be tackling Spanish, French, Italian in the very near future because it's important to offer the forecast also in a way that they could interact natively without having to have the limitation of using an English language platform into their day-to-day life. But yeah, full circle probably we’ll be going full circle soon.

+ +

CHAD: So language is one barrier to scaling and to adoption. Are there other ones that are typical barriers of adoption for your customers?

+ +

CARLOS: We are very competitive here in the North American market, the European markets. Our prices are in dollars. But that by itself is a problem for emerging economies; for example, you know, $100 here is not the same thing as $100 in other countries. We have to take into consideration exchange rates or the amount of disposable income that they will have for their operations.

+ +

CHAD: And I'm not super educated about it, but I know that there are certain industries in agriculture where the growers are particularly pressed for margins, and coffee is one of them, right?

+ +

CARLOS: Exactly. So, fortunately, in many ways, for the bigger crops, specialty crops they are traded, and the prices are linked to U.S. dollars so that can be translated, our services can be absorbed, let's say. For the smaller crops that are not traded or that just stay locally, the price is not linked to the U.S. exchange; then it's definitely a bigger barrier for them. But hopefully, we will get to a point if we have a sufficiently large adoption in North America and the developed world; these technologies could be subsidized or made more accessible in other economies.

+ +

CHAD: What are some of the concerns that growers have? Take the specialty crops, for example, is it a matter of are they doing this because they want to make the best product possible, or is it because they want to prevent crop loss?

+ +

CARLOS: It is both, actually. The uses of weather information in agriculture varies, as you said. There are many different applications; one is to get more actionable alerts. For example, we saw what happened in Burgundy last year where a substantial part of their region lost their crops, close to 80% maybe. I don't remember the number, but it was definitely substantial. And so, having more accurate forecasts and alerts gives them an opportunity to adapt better, to get cover, protect their fields to a certain extent. Weather information affects also pests and disease models, so application of fertilizer with spraying is also affected by local conditions.

+ +

In many ways, for the operations that are very, let's say, sophisticated, some of them even link the sugar content on the fruit to weather conditions. And understanding how these weather conditions affect sugars could tell them when is the optimal time for them to, let's say, harvest? And the difference in the sugar content might determine the difference between higher margins or so-so margins [laughs] for their yield.

+ +

So yeah, it's a combination of quality of the product. It's a combination of preventing loss of the product. And it's also labor scheduling and activities, for example, that are regulated by OSHA that prevent farm operations to maybe don't, let's say if they are like temperatures above 95 Fahrenheit or 100 Fahrenheit. So having that extra information in alerts will also help them with farm management operations.

+ +

CHAD: So can you give me a sense of the stage you're at or the scale you're at now with the business and where you see your next stages of growth being?

+ +

CARLOS: Thank you. Yeah, great. So we are fortunate to have scaled this solution beyond California. We are now a global platform. We are providing forecast to Spain. Recently, we got contacted by some growers in South America, so we are testing for avocado growers in Brazil and Colombia, for example. So I'm not serving yet coffee growers in Colombia, but the avocado growers in Colombia, it seems that they got a hold on what we do, [laughs] so it is getting there. And now we have the resources, the ability to go global and offer this anywhere in the world that is connected with an IoT device. So it's fully operational.

+ +

And we are now in the midst of fundraising to scale the team, provide the customer success operations, and to support growers in different geographies, to support growers of different crops. And I think that if we are going to be successful globally, it starts with customer support, customer success, and understanding your users' needs, so they don't feel that, again, they will receive a one size fits all vanilla-like solution and that we really care about why specialty crops are special.

+ +

CHAD: So when you were just starting out, who was the first team member that you added to the team?

+ +

CARLOS: Oh, it was great. So in many ways, I thank the Economic Development Council of San Diego for funding a set of interns in data science, weather analytics, and business development. So our first hires, in many ways, were supported thanks to the Economic Development Council.

+ +

We were the two founders, and then we got support in business development to understand which, for example, specialty crops really care about weather. Then some data science interns, data scientists that helped us with grants that we did for the National Science Foundation, and NASA that we got...we supported one of the grants. During COVID times, we participated in a very interesting opportunity to know the effect of COVID on forest fires, for example, and that was in collaboration with NASA.

+ +

So first hires were interns, entry-level positions in data science, in back-end engineering, and then front-end business development. Now we are very excited to be expanding the team. We recently hired a Chief Product Officer with ten years of experience in Bloomberg, experience with visualizations, and talking to customers and users. So I think that for us, it's very important to, again, I reiterate, to have the ability to provide a great user experience, to provide meaningful information for specialty crops so they feel that they are special.

+ +

CHAD: You mentioned that you got some business development help using those grants. But right now, is the actual sales work being done by the founding team?

+ +

CARLOS: Yeah, at the beginning, as a founding team in a small startup, you have to wear multiple hats. So yeah, it's very common, and in many ways, I appreciate that we didn't rush to hire in terms of sales too early because it's important that the founding team understands the user perspectives, their needs, what they call the pain points to understand how to steer product into that direction.

+ +

And then sales will follow once you have a solution that is highly needed, that users really like and that it can be shown that it can be scaled globally. So we are working on scaling, on accuracy of the forecasts. And yeah, next hires will be to get somebody that will help us in sales and can bring us to the next level.

+ +

CHAD: What does the sales cycle look like for the kinds of customers you have now? Do they tend to be smaller, or do they tend to be larger enterprise customers?

+ +

CARLOS: So, in the beginning, we worked with smaller enterprises to understand how to use the data, for example, connect the data from one or five sensors transmitted online. So dealing with smaller enterprises, farmers was optimal at that point as a company. And now, we are focusing more on businesses, farm managers, or management companies that have hundreds, sometimes thousands of sensors on their management.

+ +

So we deal with more like business to business instead of going direct to grower at this stage because, as we were mentioning earlier, we're a small company, and going direct to grower requires lots of support and dedication in terms of dedicated agents and sales teams.

+ +

CHAD: Do those companies tend to have long sales cycles?

+ +

CARLOS: The bigger ones, yes. If you are talking about publicly traded companies, they will want to start with pilots then validate them. And you can move at different timescales with them that are not necessarily aligned with the startups at this stage. But there are some farm managers that have a way higher frequency of decision making. So their sale cycle could be one month, two months instead of having to build a relationship for years.

+ +

CHAD: You mentioned the pilots, and you mentioned earlier telling the story about a customer that said, you know, "If you can provide us with better data," but I think companies as they scale or as they talk to potential customers, you also don't want to take on too much work that you should be charging for to be able to do that pilot. How do you strike that balance?

+ +

CARLOS: It's a fascinating question. And I think that from a founding member perspective, let's say, it goes as a function of the stage of the company and what other, not necessarily monetary, benefits you can get from these pilots. We have been even recommended to not have unpaid pilots anymore, for example. I think that it's important at the beginning to get access to the information that you need to validate the technology with users that really care about what you're building.

+ +

And sometimes, there are different ways that these pilots can be structured in a way that the final user might give you a reference or might spend time with you doing the quality control, quality check, saying what kind of features they like, so that's also very important as a young startup.

+ +

As you grow, probably once you have that validation, there is no need necessarily to take into endeavors that will lead to unpaid pilots that you don’t know if there's a clear end to that. And you can move to a more structured pilot program that has clear deliverables, and at the end of window, a decision will be made depending on the set of topics that were agreed between the companies.

+ +

CHAD: You might even be able to get away without pilots if you can make a strong case by showing other case studies that are relevant to that potential customer or where you explain, oh, you know, these people had a similar situation to you and here's how it's solved, and here's the success that they had.

+ +

CARLOS: Totally. You nailed it. It's in many ways to sometimes build credibility, find analogues in the sector, or a use case that can be comparable to the pain point that another user might have. And it could be, let's start with the avocado growers in Brazil, and they have probably the same pain points that they have with avocado growers in Colombia. Once we have that sorted out, then we probably can go and talk with avocado growers here in California or Mexico, Central America and tell them, "Hey, this is the value that we've unlocked in Brazil. Do you have a similar problem?"

+ +

CHAD: What I have found is that this is one of the important reasons why you have to have a good product which is part of what you've been saying all along, you know, you really wanted to focus on making sure the product was working and that it was good. Because when you do, then you can also use referrals, you know, not referrals, but like, hey, you want to talk to this avocado grower, and they'll be happy to talk with another potential customer because they're excited about what you've done for them and been able to do with them.

+ +

CARLOS: Totally, totally. And agriculture is always open to new technologies, but they are traditional in many ways. And it's a small circle, and I think that it is very important to build products right and really care about what you're doing and your end-users. Build together. Don't come necessarily with assumptions saying, "Hey, here agricultural grower A, I have a solution that will change your life," without knowing necessarily where are they coming from and their life experiences, and how they interact with products before.

+ +

So yeah, I totally see the benefit of referrals. Word of mouth is very big, going to conferences with agricultural growers. There are big networking events that could help us more than just going and doing a Google ad campaign, for example, at this stage.

+ +

CHAD: I think that's probably an important lesson that not only applies in agriculture but in a lot of industries. And I really appreciate you stopping by to share with us. And I really wish you the best of luck as you progress in your journey at Benchmark.

+ +

CARLOS: Oh, thank you very much. I really appreciate it, and I hope that we can continue the conversation here. Just count with us anytime that you need to talk about weather, agriculture, IoT sensors. Happy to help the audience too, and always discuss what's out there to help the Giant Robots community. [laughs]

+ +

CHAD: Carlos, if people want to get in touch with you or find out more about the company, where are the best places for them to do that?

+ +

CARLOS: Go to benchmarklabs.com and then fill out a form there. And we will definitely be in touch with all of you. I will personally answer all the queries. I'm very, very happy to share our technology, share what we are building. And we are so excited because by having this technology, you can help save water, energy, and even pesticide use, and that's a huge contribution to the environment as we move forward. So yeah, thank you very much again for the invitation, and I'm here; count with me as a future resource.

+ +

CHAD: Wonderful. And you can subscribe to the show and find notes and links along with an entire transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Carlos F. Gaitan Ospina.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Carlos F. Gaitan Ospina is the Founder and CEO of Benchmark Labs, which provides IoT-based weather forecasting solutions for the agriculture, energy, and insurance sectors worldwide using proprietary machine-learning software.

+ +

Chad talks with Carlos about creating the company, the hardware they're producing and what it is doing, and where the machine learning comes into play.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Carlos Gaitan, the Founder and CEO of Benchmark Labs, which provides IoT-based weather forecasting solutions for the agriculture, energy, and insurance sectors worldwide using proprietary machine-learning software. Carlos, thank you very much for joining me.

+ +

CARLOS: Thank you for the invitation, Chad. It's a pleasure to join you here.

+ +

CHAD: You work in a variety of different industries with weather forecasting solutions using machine learning. I'm really curious, at a high level, how did you get to where you created Benchmark Labs today?

+ +

CARLOS: Oh, thank you, Chad. That's a great question. I think that in many ways, it's a combination of life experiences and lots of user feedback. As a background, my mum worked for 28 years in the National Federation of Coffee Growers in my native Columbia. And we experience basically the effects of weather, La Niña, El Niño, local conditions, pests on the coffee growers. I remember growing up looking at the price in The New York Stock Exchange if the pound of coffee was going to be more than $1 or not [laughs] and so on.

+ +

So, you know, we had a very severe drought in Colombia, and Colombia was heavily dependent in hydropower at that time. And I remember that we even had to study with candlelight and move to a spring savings time for the first time in the country. The country is in the equator, so you can imagine moving the clock was unheard of. So since then, I was always passionate about hydrology, the water cycle, why this happened, how weather can affect the economy at that level that people have to change their working habits.

+ +

I did civil engineering hydrology, then studied these new applications of machine learning technologies, hydroinformatics, did my studies there in Columbia, my bachelor's, my master's. Then I was fortunate to go to The University of British Columbia to study my Ph.D. in Atmospheric Sciences. And then, after I finished, I moved to The United States to work at the Geophysical Fluid Dynamics Laboratory in Princeton with close collaboration with the NOAA, the USGS.

+ +

And that gave that perspective also of understanding how weather climate models were done at the Department of Commerce level but also to understand the users on how they interact with weather data or climate data and what were the needs that they were expecting from the National Weather Service and the Department of Commerce and NOAA that not necessarily were fulfilled with the current information.

+ +

So then I moved to the private sector, joined a hardware company, and met my co-founder of Benchmark Labs there then moved to California to work on consultancy of climate change assessments. But since the time at the Department of Commerce, it became very clear that what farmers and what users wanted was weather information that was more actionable, that was tailored to their specific location, especially for specialty crops.

+ +

Think about wineries, or coffee growers, orchids, stone fruits; they depend heavily on weather, and the information from the National Weather Services was just too coarse for them. And sometimes, there are huge errors in terms of temperatures that were recorded from their farm versus what the National Weather Service was doing. And that's why we decided to create Benchmark Labs to basically solve that problem, correct those errors, and give the information that the users needed when they needed it.

+ +

CHAD: Did you ever just consider becoming a TV weather person?

+ +

CARLOS: [laughs]

+ +

CHAD: It seems it may be easier.

+ +

CARLOS: [laughs] Nah. That's a very good point.

+ +

CHAD: [laughs]

+ +

CARLOS: And I have great respect with my colleagues that went into forecast meteorology and TV persons. I remember some of my lab mates practicing in front of a green screen when we were doing the Ph.D.

+ +

CHAD: [laughs]

+ +

CARLOS: That was an interesting scenario. [laughs] However, growing up in Colombia, the weather forecasts were not very, let's say, accurate to a certain extent, and we did the opposite than the weatherman suggested.

+ +

CHAD: [laughs]

+ +

CARLOS: So I guess that steered me towards following that path. [laughs]

+ +

CHAD: So it totally resonates with me this idea that, you know, especially for...I've been on the West Coast before where you go over a hill and the weather it's like 20 degrees hotter and sunny and on one side of the hill, it was cold and foggy. We went on a great company trip many years ago to visit some Napa vineyards, and I was surprised by that. So I can imagine how that local information just doesn't match the global information that farmers might be getting. So what is the hardware that you're actually producing, and what is it doing? What does it look like?

+ +

CARLOS: [laughs] Great question. So I will go back to your story about Napa and Sonoma, and the reality is that's exactly a problem that growers face; national weather agencies give averages over a big region. They divide the world in boxes, and everybody inside of a box receives exactly the same forecast.

+ +

And if you are especially in the coast or you're in specialty agriculture, you understand that weather changes with elevation. Depending on which side of the mountain you are, you could receive all the rain or no rain at all. If you are near the shores, you could also get more wind, different types of clouds, all of those situations affect the conditions at the farm.

+ +

And going back to the situation of Napa and Sonoma, Burgundy or the Mediterranean Basin, they all believe in the value of what they call the terroir, that is what makes also unique their products. They're indigenous, and they understand at a very fundamental point how the local conditions from the soil, from the vegetation, makes their farm unique.

+ +

So what we do is we use IoT sensors, basically hardware sensors that monitor environmental variables. We refer to them in the atmospheric science world as weather stations. I had a talk with some users when I said the term weather station. They imagined a big construction or a building with a TV station on a radar or something. But in this case, there are IoT devices that are totally portable, the size of a Wi-Fi modem in some cases. And we use those sensors as ground truth that will basically tell us the local conditions. We use the information from the National Weather Services and the information from those IoT sensors and correct the forecast as they come.

+ +

CHAD: And is that where the machine learning comes in because it's actually correcting the forecast being received?

+ +

CARLOS: Exactly, our machine learning aspect of it is fully operational, non-linear correction of weather data as it comes in from the National Weather Services to correct it to the conditions that are experienced at the farm level, at the sensor level.

+ +

And a farm could be also an agricultural farm, or it could be a solar farm, a wind farm. Or, as we talk with some users in ski resorts that actually they consider as snow farmers, it's also affected by microclimates. So at the end, it is about providing value to all these areas affected by microclimates that are not being resolved correctly by the current generation of forecast from the National Weather Services.

+ +

CHAD: Are most customers able to get the coverage that they need with one weather station, or are they deploying multiple ones?

+ +

CARLOS: So that's a great question, and the answer probably is it depends. Our customers, original customers, have thousands of stations over multiple fields under management. For specialty crops, it's common to have multiple IoT sensors in one acre. For other scenarios, they might have only one station or one sensor every 10 acres or so on, so it depends on the condition. It depends on how technologically inclined are the users if they already invested in these IoT sensors or if they are looking into buying IoT sensors and then scaling up the number of sensors in their farms.

+ +

CHAD: How do all the sensors report their data back?

+ +

CARLOS: That is a very interesting question because they are, let's say, tens of hardware manufacturers globally. We also created kind of a Rosetta Stone that puts all the sensors to communicate to our back-end systems. We integrate different languages of each hardware manufacturer. It has its own ways of naming the variables. So we do the translation in our end. We receive the data via an API. These IoT devices are Internet of Things in many ways because they transmit data via Wi-Fi, satellite internet, you know, cellular.

+ +

CHAD: Cell, yeah. So different manufacturers might have different ways of actual communication, not just the protocol, but one box might be using Wi-Fi, and another one might be using a satellite.

+ +

CARLOS: Exactly. And sometimes, many manufacturers give you the options of connecting even using Wi-Fi or Bluetooth for IoT sensors that are near, let's say, a farm that has internet connectivity. If they are on the field farther away, they might need to get access to a data plan from a cellular carrier, 3G usually or 5G. In some areas, there is limited coverage so far. And if it's a very remote area, there are options to get satellite coverage.

+ +

CHAD: Now, I'm asking somewhat naive questions based on my understanding. And so if I start butting up against proprietary information, just tell me, "No." That's totally fine.

+ +

CARLOS: [laughs]

+ +

CHAD: So when we're thinking about the amount of data coming in from all of these different weather stations that your customers have, is it a lot of data? Is it a lot of data points?

+ +

CARLOS: [laughs] It's a great question. So in many ways, yeah, each weather station communicates at different frequency. Sometimes what we are offering now is hourly transmission rates, but we also have access to government stations that sometimes only refresh once per day. So yes, it's a lot of data coming in, most of the data from the weather stations. Fortunately, it can be transmitted as a txt file, or it's only for one location. So the files are not big, but they are many per day. And so, we have probably done millions of operations already to assimilate data and provide the forecast.

+ +

While on the other hand, The National Weather Service provides one forecast for the globe, let's say every...some models are every hour, other models are every six hours, and so on. So that is more, let's say, a bigger data set because it's a global data set that then you have to query to extract the information locally that is relevant for your servers, for your users.

+ +

CHAD: Yeah. And I think it's neat how this is all happening centrally from all the data coming in, right?

+ +

CARLOS: Yeah, exactly. We get data coming in for each specific location. We do the corrections, and we provide the forecasts. So there are lots of operations involved in the data handling activities, pre-processing, post-processing, but it's very rewarding at the end to provide the forecasts that are tailored to specific locations.

+ +

And we had seen users that they basically told us, "Okay, we are using provider B or C; can you beat them? Show us that you can beat them, and the contract will be yours." So we showed them, and then they are like, "Yeah, that's fantastic. This is exactly what we have been looking for, information that is more accurate for our farms," so yeah.

+ +

CHAD: Now, does your system correct itself based on what actually happened in an area after the modified forecast goes out?

+ +

CARLOS: That's not a very relevant question because some of the models are static. I used my experience when I did an internship in Environment Canada, and I found that they were adjusting their models, let's say four times per, at least the operational models they had, four times per year. They kind of tweaked them to the local, let's say, spring, summer, fall, winter conditions. In our case, we make our models to correct themselves as more data comes in so they can adjust to weather events and have short-term memory, let's say, of what they will wait heavily on and forget the distant past.

+ +

CHAD: I mean, it seems obvious, not necessarily easy but obvious, that you've made a prediction about what the weather is going to be, and you have all the data coming in from the stations to confirm whether your prediction was correct or not. So I'm sure it's not easy to adjust the model based on that.

+ +

CARLOS: [laughs]

+ +

CHAD: That seems obvious to me.

+ +

CARLOS: Yeah, it's just a different approach in many ways. As you said, it's obvious because the users usually care about a specific location, at least our users. We understand that for national security or aviation, they require a model that provides coverage over a wider area, like sometimes continents. But for agricultural users, they care about their farms, and the farms will not move in space. So --

+ +

CHAD: Well, technically, they are moving in space; it's just the weather goes along with it.

+ +

CARLOS: [laughs] So yeah, I guess that it's just a different way of tackling the problem. We focus on doing these forecasts to each specific location instead of having a forecast done for the whole globe that could be used in many different locations or for many different industries, but it's not necessarily tailored to any industry-specific or location-specific.

+ +

CHAD: Yeah, that's great.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So have you managed to bring it full circle now, and are there coffee growers in Colombia that are using your solution?

+ +

CARLOS: [laughs] I hope so. We have talked with coffee growers for sure. They care about temperature gradients. And I really think that going to Colombia as we scale will make the whole platform easier to use. I think that we can go full circle soon, sooner rather than later, into Colombia.

+ +

We got support from the World Trade Center here in San Diego to do commercialization assistance to translate our solution from English to other languages. So we will be tackling Spanish, French, Italian in the very near future because it's important to offer the forecast also in a way that they could interact natively without having to have the limitation of using an English language platform into their day-to-day life. But yeah, full circle probably we’ll be going full circle soon.

+ +

CHAD: So language is one barrier to scaling and to adoption. Are there other ones that are typical barriers of adoption for your customers?

+ +

CARLOS: We are very competitive here in the North American market, the European markets. Our prices are in dollars. But that by itself is a problem for emerging economies; for example, you know, $100 here is not the same thing as $100 in other countries. We have to take into consideration exchange rates or the amount of disposable income that they will have for their operations.

+ +

CHAD: And I'm not super educated about it, but I know that there are certain industries in agriculture where the growers are particularly pressed for margins, and coffee is one of them, right?

+ +

CARLOS: Exactly. So, fortunately, in many ways, for the bigger crops, specialty crops they are traded, and the prices are linked to U.S. dollars so that can be translated, our services can be absorbed, let's say. For the smaller crops that are not traded or that just stay locally, the price is not linked to the U.S. exchange; then it's definitely a bigger barrier for them. But hopefully, we will get to a point if we have a sufficiently large adoption in North America and the developed world; these technologies could be subsidized or made more accessible in other economies.

+ +

CHAD: What are some of the concerns that growers have? Take the specialty crops, for example, is it a matter of are they doing this because they want to make the best product possible, or is it because they want to prevent crop loss?

+ +

CARLOS: It is both, actually. The uses of weather information in agriculture varies, as you said. There are many different applications; one is to get more actionable alerts. For example, we saw what happened in Burgundy last year where a substantial part of their region lost their crops, close to 80% maybe. I don't remember the number, but it was definitely substantial. And so, having more accurate forecasts and alerts gives them an opportunity to adapt better, to get cover, protect their fields to a certain extent. Weather information affects also pests and disease models, so application of fertilizer with spraying is also affected by local conditions.

+ +

In many ways, for the operations that are very, let's say, sophisticated, some of them even link the sugar content on the fruit to weather conditions. And understanding how these weather conditions affect sugars could tell them when is the optimal time for them to, let's say, harvest? And the difference in the sugar content might determine the difference between higher margins or so-so margins [laughs] for their yield.

+ +

So yeah, it's a combination of quality of the product. It's a combination of preventing loss of the product. And it's also labor scheduling and activities, for example, that are regulated by OSHA that prevent farm operations to maybe don't, let's say if they are like temperatures above 95 Fahrenheit or 100 Fahrenheit. So having that extra information in alerts will also help them with farm management operations.

+ +

CHAD: So can you give me a sense of the stage you're at or the scale you're at now with the business and where you see your next stages of growth being?

+ +

CARLOS: Thank you. Yeah, great. So we are fortunate to have scaled this solution beyond California. We are now a global platform. We are providing forecast to Spain. Recently, we got contacted by some growers in South America, so we are testing for avocado growers in Brazil and Colombia, for example. So I'm not serving yet coffee growers in Colombia, but the avocado growers in Colombia, it seems that they got a hold on what we do, [laughs] so it is getting there. And now we have the resources, the ability to go global and offer this anywhere in the world that is connected with an IoT device. So it's fully operational.

+ +

And we are now in the midst of fundraising to scale the team, provide the customer success operations, and to support growers in different geographies, to support growers of different crops. And I think that if we are going to be successful globally, it starts with customer support, customer success, and understanding your users' needs, so they don't feel that, again, they will receive a one size fits all vanilla-like solution and that we really care about why specialty crops are special.

+ +

CHAD: So when you were just starting out, who was the first team member that you added to the team?

+ +

CARLOS: Oh, it was great. So in many ways, I thank the Economic Development Council of San Diego for funding a set of interns in data science, weather analytics, and business development. So our first hires, in many ways, were supported thanks to the Economic Development Council.

+ +

We were the two founders, and then we got support in business development to understand which, for example, specialty crops really care about weather. Then some data science interns, data scientists that helped us with grants that we did for the National Science Foundation, and NASA that we got...we supported one of the grants. During COVID times, we participated in a very interesting opportunity to know the effect of COVID on forest fires, for example, and that was in collaboration with NASA.

+ +

So first hires were interns, entry-level positions in data science, in back-end engineering, and then front-end business development. Now we are very excited to be expanding the team. We recently hired a Chief Product Officer with ten years of experience in Bloomberg, experience with visualizations, and talking to customers and users. So I think that for us, it's very important to, again, I reiterate, to have the ability to provide a great user experience, to provide meaningful information for specialty crops so they feel that they are special.

+ +

CHAD: You mentioned that you got some business development help using those grants. But right now, is the actual sales work being done by the founding team?

+ +

CARLOS: Yeah, at the beginning, as a founding team in a small startup, you have to wear multiple hats. So yeah, it's very common, and in many ways, I appreciate that we didn't rush to hire in terms of sales too early because it's important that the founding team understands the user perspectives, their needs, what they call the pain points to understand how to steer product into that direction.

+ +

And then sales will follow once you have a solution that is highly needed, that users really like and that it can be shown that it can be scaled globally. So we are working on scaling, on accuracy of the forecasts. And yeah, next hires will be to get somebody that will help us in sales and can bring us to the next level.

+ +

CHAD: What does the sales cycle look like for the kinds of customers you have now? Do they tend to be smaller, or do they tend to be larger enterprise customers?

+ +

CARLOS: So, in the beginning, we worked with smaller enterprises to understand how to use the data, for example, connect the data from one or five sensors transmitted online. So dealing with smaller enterprises, farmers was optimal at that point as a company. And now, we are focusing more on businesses, farm managers, or management companies that have hundreds, sometimes thousands of sensors on their management.

+ +

So we deal with more like business to business instead of going direct to grower at this stage because, as we were mentioning earlier, we're a small company, and going direct to grower requires lots of support and dedication in terms of dedicated agents and sales teams.

+ +

CHAD: Do those companies tend to have long sales cycles?

+ +

CARLOS: The bigger ones, yes. If you are talking about publicly traded companies, they will want to start with pilots then validate them. And you can move at different timescales with them that are not necessarily aligned with the startups at this stage. But there are some farm managers that have a way higher frequency of decision making. So their sale cycle could be one month, two months instead of having to build a relationship for years.

+ +

CHAD: You mentioned the pilots, and you mentioned earlier telling the story about a customer that said, you know, "If you can provide us with better data," but I think companies as they scale or as they talk to potential customers, you also don't want to take on too much work that you should be charging for to be able to do that pilot. How do you strike that balance?

+ +

CARLOS: It's a fascinating question. And I think that from a founding member perspective, let's say, it goes as a function of the stage of the company and what other, not necessarily monetary, benefits you can get from these pilots. We have been even recommended to not have unpaid pilots anymore, for example. I think that it's important at the beginning to get access to the information that you need to validate the technology with users that really care about what you're building.

+ +

And sometimes, there are different ways that these pilots can be structured in a way that the final user might give you a reference or might spend time with you doing the quality control, quality check, saying what kind of features they like, so that's also very important as a young startup.

+ +

As you grow, probably once you have that validation, there is no need necessarily to take into endeavors that will lead to unpaid pilots that you don’t know if there's a clear end to that. And you can move to a more structured pilot program that has clear deliverables, and at the end of window, a decision will be made depending on the set of topics that were agreed between the companies.

+ +

CHAD: You might even be able to get away without pilots if you can make a strong case by showing other case studies that are relevant to that potential customer or where you explain, oh, you know, these people had a similar situation to you and here's how it's solved, and here's the success that they had.

+ +

CARLOS: Totally. You nailed it. It's in many ways to sometimes build credibility, find analogues in the sector, or a use case that can be comparable to the pain point that another user might have. And it could be, let's start with the avocado growers in Brazil, and they have probably the same pain points that they have with avocado growers in Colombia. Once we have that sorted out, then we probably can go and talk with avocado growers here in California or Mexico, Central America and tell them, "Hey, this is the value that we've unlocked in Brazil. Do you have a similar problem?"

+ +

CHAD: What I have found is that this is one of the important reasons why you have to have a good product which is part of what you've been saying all along, you know, you really wanted to focus on making sure the product was working and that it was good. Because when you do, then you can also use referrals, you know, not referrals, but like, hey, you want to talk to this avocado grower, and they'll be happy to talk with another potential customer because they're excited about what you've done for them and been able to do with them.

+ +

CARLOS: Totally, totally. And agriculture is always open to new technologies, but they are traditional in many ways. And it's a small circle, and I think that it is very important to build products right and really care about what you're doing and your end-users. Build together. Don't come necessarily with assumptions saying, "Hey, here agricultural grower A, I have a solution that will change your life," without knowing necessarily where are they coming from and their life experiences, and how they interact with products before.

+ +

So yeah, I totally see the benefit of referrals. Word of mouth is very big, going to conferences with agricultural growers. There are big networking events that could help us more than just going and doing a Google ad campaign, for example, at this stage.

+ +

CHAD: I think that's probably an important lesson that not only applies in agriculture but in a lot of industries. And I really appreciate you stopping by to share with us. And I really wish you the best of luck as you progress in your journey at Benchmark.

+ +

CARLOS: Oh, thank you very much. I really appreciate it, and I hope that we can continue the conversation here. Just count with us anytime that you need to talk about weather, agriculture, IoT sensors. Happy to help the audience too, and always discuss what's out there to help the Giant Robots community. [laughs]

+ +

CHAD: Carlos, if people want to get in touch with you or find out more about the company, where are the best places for them to do that?

+ +

CARLOS: Go to benchmarklabs.com and then fill out a form there. And we will definitely be in touch with all of you. I will personally answer all the queries. I'm very, very happy to share our technology, share what we are building. And we are so excited because by having this technology, you can help save water, energy, and even pesticide use, and that's a huge contribution to the environment as we move forward. So yeah, thank you very much again for the invitation, and I'm here; count with me as a future resource.

+ +

CHAD: Wonderful. And you can subscribe to the show and find notes and links along with an entire transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Carlos F. Gaitan Ospina.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Fx5ihu27 + + ]]> + + Chad Pytel + Carlos F. Gaitan Ospina + + + 420: mRelief with Dize Hacioglu + https://podcast.thoughtbot.com/420 + 4975c872-a9a5-4f60-b29b-bbf90569842b + Thu, 28 Apr 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Dize Hacioglu is the CTO of Chicago’s mRelief, which offers an easy-to-use platform that helps families connect to SNAP food benefits. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits. + +Chad talks with Dize about how the platform helps people navigate the often complicated food stamp benefits system, what her role as CTO looks like as a CTO who codes, and how she hopes to help facilitate the growth of the mRelief program and team. + 44:18 + no + + + Dize Hacioglu is the CTO of Chicago’s mRelief, which offers an easy-to-use platform that helps families connect to SNAP food benefits. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits. +Chad talks with Dize about how the platform helps people navigate the often complicated food stamp benefits system, what her role as CTO looks like as a CTO who codes, and how she hopes to help facilitate the growth of the mRelief program and team. +mRelief (https://www.mrelief.com/) +Follow mRelief on Twitter (https://twitter.com/mRelief_form), Facebook (https://www.facebook.com/mRelief/), Instagram (https://www.instagram.com/m_relief/), or LinkedIn (https://www.linkedin.com/company/mrelief.com/). +Follow Dize on LinkedIn (https://www.linkedin.com/in/dizehacioglu/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dize Hacioglu, the CTO of mRelief, an easy-to-use platform that helps families connect to the Supplemental Nutrition Assistance Program. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits. Dize, thanks for joining me. +DIZE: Yeah, thank you so much for having me. +CHAD: And thank you for all of your work at mRelief. It's a big help to everybody. +DIZE: It's my pleasure, and it's really an honor to be able to do the work that we do. +CHAD: Speaking of that work, tell me a little bit more about what the platform actually does for people. +DIZE: So mRelief is an easy to use platform that's accessible over text messaging or web that helps folks find out if they qualify for SNAP, formerly known as food stamps, and helps them apply in certain states or connect with community-based organizations who can help them apply if they'd like further assistance. +CHAD: So it's a pretty focused product, right? [laughs] +DIZE: Mm-hmm. +CHAD: But I'm sure that there's a lot going behind the scenes in order to make that pretty focused product happen. Is that right? +DIZE: Yeah, that's right. That's right. Yes, there are a lot of moving parts. +CHAD: [laughs] So what's involved in figuring out whether someone is eligible or not? +DIZE: So there are actually a few patterns that we've discovered as we've been expanding our work from just one state where we were just in California for a while and then expanding it nationwide. We found that eligibility typically falls into a couple of different buckets. So we've been able to turn that into code that helps guide people through the typical questions of eligibility and takes them through the flow based on their state's eligibility of requirements. +CHAD: I guess my next question was going to be without mRelief; how difficult is this for folks? +DIZE: So I think most folks typically apply hoping that they're eligible, and they'll only really find out after the application process has been complete. They may have wasted time at the office, time filling out the application, time waiting for a phone call from the office only to find out that they are not eligible. +CHAD: So you mentioned you started just in California, and you've been expanding from there. You mentioned there are patterns that you found. How different are things state to state? And what does your growth trajectory look like throughout the United States? +DIZE: The biggest differences between states are income limits, the threshold that a family has to fall under in terms of monthly gross income to be able to qualify. So that has been a big data collection research project that we've done to be able to expand to all 50 states. And from their past eligibility, applications also differ from state to state. There's no one platform where you can fill out the same questions that are asked. +CHAD: I was just doing an onboarding call with some folks who are joining the thoughtbot team. And on the call, there was one person in the United States, three people who live in different countries in Africa; I think one other person in Europe. And sometimes, when I'm doing the onboarding calls with them, I have to explain how disjointed things are in the United States and which things are state by state because it surprises people. +Well, one, it surprises people who aren't in the United States that we don't have certain standard benefits like sick time in the United States. And then it also surprises people how much is actually determined by the state that you live in, even with...because SNAP is a national program, right? +DIZE: Correct. Yeah, it's federally funded. +CHAD: Right. So even with a federally-funded program, it still comes down to certain things being different in certain states, which is often really daunting and surprising to people. +DIZE: Yes, totally, totally. And it also gets even more complicated in some states like California and maybe even Texas, where it's county-administered, so each county has a different process. Sometimes they have different applications even between counties in the same state. +CHAD: So is there a reason for this other than making it hard for people to get the benefit? [laughter] That might be a political question. I just totally exposed my -- [laughter] +DIZE: I think that's a very valid question because I think we've seen instead of cutting benefits completely, administratives put up to dissuade people or make it more burdensome for people to access benefits as a way of keeping them from benefits nationwide, not just like any specific state. So I think that's a very valid question. +CHAD: But it's possible that there are other reasons, right? So, for example, like, oh, it's administered locally, or income levels are different in different places, and so it needs to be...I was just curious whether there were other reasons. +DIZE: Yeah, I'm actually not sure about the reasoning. +CHAD: Yeah, fair enough. Fair enough. +DIZE: [chuckles] +CHAD: So you joined in 2017. +DIZE: Yes, I did. +CHAD: And Emily started in 2014. +DIZE: That's right. +CHAD: So what were things like when you joined? +DIZE: Well, I joined a team of two, and the two folks that were already on the team were the co-founders, Rose Afriyie and Genevieve Nielsen, and I was also joined by another co-worker who was hired at the same time as me. And we were only doing work in California, helping folks find out if they're eligible, helping them apply for CalFresh, which is the name for SNAP in California, and helping them through the post-application process like interviewing, collecting documents, getting a Lift ride to the office to get their card. So we were really focused on the end-to-end process in one specific, again, county because it's county-administered in California. +CHAD: So in just one county. +DIZE: Yeah, in San Francisco. +CHAD: And was there a tech platform at the time? +DIZE: Yes, we had our screener, and we had our simplified application. +CHAD: Had the founders created that? +DIZE: Yes. +CHAD: Okay. And how did they focus on...they're not in California, they're in Chicago, right? +DIZE: Yeah, we're based in Chicago. +CHAD: So why California and why that particular county? Do you know? +DIZE: I think it was an amalgamation of things (I don't know if I used that word right.), but they attended Y Combinator early on in the development of mRelief. So through that, they were able to get connections to the San Francisco Human Services Agency, who was our first big contract and allowed us to really develop the end-to-end process. +CHAD: So you joined as the third/fourth person on the team? +DIZE: Yes. +CHAD: And it may be obvious, but I'm going to ask the question anyway. What drew you to joining? +DIZE: I've always loved coding. For a long time, I felt at a loss how to combine my love of coding and wanting to pursue coding as a career with my desire to try to make a positive social impact in the world. And I don't think back in 2017; I was really aware of the civic tech space. In perusing job descriptions nationwide, I stumbled across mRelief on Idealist, and it sounded like the perfect match. And I remember feeling like this is my dream job. I can't believe I get to do this work and code at the same time. +CHAD: [laughs] So you joined as a software developer at the time. Did you have aspirations to be CTO when you joined? +DIZE: No. [laughs] No, I remember looking at Genevieve, our former CTO and co-founder, and thinking I have no idea how she does her job and never thinking that I would find myself in this position. And it's been a massive learning experience and also a growth opportunity for me. +CHAD: What are some of the things that you needed to grow into or to learn in order to get to that point? +DIZE: I feel like most of the learning happened after. The biggest thing that I learned to prepare me to go into the CTO role was basically a very comprehensive understanding of our codebase. I think most of the skills or what I need to succeed in this role came after. +CHAD: Well, actually, let me ask a related but different question. CTO actually differs in different organizations. So, what does your role as CTO actually look like? +DIZE: It definitely does. And I think my role has even changed a bit in the year and a half or a year and three months that I've been in this role based on the growing team that we have at mRelief. But my day-to-day basically looks like working with our product team to plan for new features. I like to code, so I try to do some coding at least every day and also general oversight and, I guess, strategic thinking. +CHAD: One way in that description that stands out to me, you know, some other CTO might describe their role as very much not working on the code, very much not even really working with the team or product, and more focused on the executive level of the company or the needs of fundraising or something like that. So it sounds like you're very much still product-focused and oriented towards working on the product. +DIZE: Yeah, I think that's driven by a selfish desire to keep coding. +[laughter] +CHAD: You're talking to someone who is in the exact same spot. There are times where I feel guilty about that. +DIZE: Yeah. [laughs] +CHAD: Here's my justification, [laughter], and I'll be curious in terms of your justification. I've done this for 19 years now. And I'm pretty confident that I would have burned out a long time ago if I didn't spend time coding. It's part of what I find rejuvenating and what I love to do. It doesn't mean that I can always afford to work on something for four hours straight, but it's part of what has made me be able to enjoy this work for so long. +DIZE: Yeah, I completely relate to that. If I wasn't coding, I don't know how long I could sustain myself [laughs] with so much responsibility. How do you find that balance? +CHAD: Well, I think part of it is freeing yourself up to not feel guilty so being really clear with others. Like, if someone asks for something from me, being like, yep, totally, I can do that. I can get it done by this day and pretty aggressively planning out my work or time, blocking my calendar and making it clear when I'm going to be able to have that thing for them. +And if that timeline doesn't work, then they can tell me that, and I can adjust. But that goes a long way towards when I am having a coding session that lasts half a day or something like that; I cannot worry or feel guilty that someone's waiting on me for something or that it's not what I should be spending time on. +DIZE: Yeah, that makes a lot of sense. +CHAD: What about you? Have you found things that work for you? +DIZE: I have been trying different things. I've been doing a lot of YouTube deep dives on productivity blogs, just different ways of thinking about prioritizing work and making sure that things get done. But I really like your point about allowing yourself not to feel guilty. And I do like to remind myself that I don't want to take the fun out of my job. I want that for other folks on the team, and I also want that for myself. +CHAD: The other thing that is on my mind when I'm doing something is there's this stereotype of the CTO who codes and makes a mess of things that the other people have to clean up. +DIZE: [laughs] Oh no. I didn't know about that. +CHAD: You know what I'm talking about? +DIZE: No. [laughs] +CHAD: Oh, no, no? It's like, oh, the CTO made commits at 9:00 p.m. last night. I guess I have to...and the build is broken. +DIZE: Oh no. +CHAD: I guess I have to...[laughs] so, does that describe you or no? [laughs] +DIZE: Oh my gosh. I'm definitely seeing myself in that description a little bit. [laughs] +CHAD: Oh no. [laughs] +DIZE: Literally, I was up last night pushing code to production, but I think it's okay. [laughter] I mean, I hope that that's not me. [laughs] +CHAD: I try to avoid that because, you know, I want to feel like my work is useful and valued and not creating more work for other people. +DIZE: Yeah, definitely. I agree. +[laughter] +CHAD: Tell me more about the tech stack for mRelief. +DIZE: So we use React and Rails. We're hosted on Heroku. Yeah, very basic. +CHAD: I heard that you use some thoughtbot stuff, so I assumed that it was Rails. +DIZE: [laughs] Yes. Yeah. +CHAD: That's great to hear. +DIZE: Yeah, I was messing with Paperclip this morning, actually. [laughs] +CHAD: Oh, well, Paperclip is deprecated. I'm sorry to tell you. [laughs] +DIZE: I know. [laughter] I had to fork it this morning to make a change. +CHAD: I still stand by that decision. I think it's important as sort of a community contributor that we signal overall direction and coalesce behind what's built into Rails once it was there. +DIZE: Okay, that makes a lot of sense. +CHAD: But yeah, was Rails in use when you joined? +DIZE: Yeah, we're using the same stack. +CHAD: How much has it grown over time, the codebase? +DIZE: I don't really know. +CHAD: That's interesting that you don't know. [laughs] +DIZE: When you say grown, like, I guess how is that measured? +CHAD: Oh yeah. I mean, is it more complex now than it was when you joined? +DIZE: Yes, definitely. Yeah, we've added new products that had never existed, and the fact that we've expanded to more states and our screener is nationwide that's added a lot of complexity. +CHAD: So, do you have ways that you manage that complexity, either in the code or in the business? +DIZE: What would that look like? [laughter] How would you manage that complexity? +CHAD: Well, I think it's a little dependent on where the complexity is coming from. So, for example, the screener is nationwide, you said, and so does the screener change based on where you're located once you start to fill it out? +DIZE: Yes, yes. The first question we ask is zip code. +CHAD: And then how does all of that branching work in the state-specific logic work? Is it all one big jumble of if statements and code, or is it factored out in some way to help keep that as clean as possible? And if the answer is it's all one big jumble of if statements, that's totally fine. [laughs] +DIZE: I was actually going to say both. [laughs] Because I think because of the patterns that we were able to establish, and the eligibility logic between all states, there's definitely some if branching, but there are enough shared concepts that we can keep it all in one to two files that are not too long. +Mid-Roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So you mentioned the team has grown quite a bit. It seems like the development and design team is quite a bit bigger than two people now. How big is it? +DIZE: Well, the product team itself is eight people now, I think. And the team, the whole mRelief team, we just had two new folks start today, so I think we're at 20. +CHAD: What does your onboarding process for bringing new team members on look like from a technical perspective? +DIZE: So the first two weeks, folks are typically in a bunch of onboarding meetings just getting acquainted with the history of mRelief, our current processes, and stuff like that. But for our tech team, we like to jump in with them as soon as possible, get them set up obviously locally and have them contributing with some kind of low-hanging fruit tickets at first so that they have some code pushed up in the first week or two. +CHAD: Are you facilitating that through pairing with someone existing on the team, or are folks doing that independently? +DIZE: Depending on the complexity of the ticket, sometimes we pair. Mostly it's independent work. +CHAD: Some companies and some teams have the goal of like, oh, you know, first commit to production on your first day. Do you have anything like that either with the code or with the processes like benchmarks that you use of, like we really want this to happen but on the first day or in the first week? +DIZE: No, we don't have anything like that. +CHAD: At the size, you're at now, some companies start to break into sub-teams or squads or focus areas. Are you starting to do anything like that? +DIZE: I've thought about it here and there. But I think we all like sharing responsibility for all of the different products and getting our hands into all the different ways that we connect with users. So we haven't formalized anything like that. +CHAD: So that means you have one backlog of everything that's slated to be worked on. +DIZE: Yeah, that's right. +CHAD: Is that overwhelming sometimes? +DIZE: Yes. [laughter] Yeah. I don't know about your experience with backlogs, but I assume that they're always overwhelming. +CHAD: Yeah, that's a really good way of putting it. I think that not having it requires very aggressive management that a lot of teams are not willing to do. And then when you have a team of 10 or 12 people all working across multiple apps or all on the same app doing a lot of different stuff, that's overwhelming on the other side of just the amount of stuff that's happening every day can sometimes be overwhelming. +And people start to sort of step on each other. Oh, you know, we've got these two pull requests, and every time I go to make a change, something has merged into main that now my branch is behind. And if you're waiting for CI to pass and your CI is too long, something new has been merged in by the time your CI run finishes. Those are some of the challenges that I hear people facing. +DIZE: Interesting. What are those aggressive management things that you were speaking of to avoid backlogs? +CHAD: I think it basically means saying no to things. So I think when we talk about a backlog being overwhelming, one of the worst things that comes to mind mostly, and let me know if this is part of the problem you're feeling or not, but it's really long. And somewhere in there, there's like the bug that was created two years ago by someone that has never been addressed, or maybe it has been, and the ticket was never moved forward. And so you end up with 500-600 things and a long list that becomes then very difficult to ever really prioritize because it's not possible to prioritize that many issues. Does that resonate with you at all? +DIZE: That does resonate. I was scrolling through our backlog today, and I was like, when is this going to end? [laughter] I guess I hope that was normal. [laughs] +CHAD: It is normal, or I should say I think it's common. +DIZE: Common, okay. [laughs] +CHAD: I think it is a problem a lot of companies face. And like I was saying, I think one of the only solutions to that is basically, well, so either someone or a team that is very comfortable saying, "We don't need a ticket for that because we're just not going to get to it," or being able to delete something that you've not...or move it out that this was created two years ago. It's just not doing us any value to have it hanging around anymore. +DIZE: Yeah, that makes a lot of sense. That's helpful. +CHAD: And some companies do it by policy basically. They have a philosophy or a policy that says, "This needs to be a thing that comes up." They have a product manager who's paying attention to what's going on and is like, okay, this is the third time that this has come up. Now we'll create a ticket for it because we're actually going to do it. And you only create tickets for things that are for the next four weeks, for the next six weeks, and that you use something else other than tickets. +So one thing that I've found really works well for me, and I like this idea of the difference between a discussion or an idea and the work to be done is; for example, we often use Trello for project management and a Kanban board of the work that's actually happening in the backlog. But anything that's not a concrete item that we're going to actually prioritize and do is better off in a messaging system like Basecamp or another tool where it's more of like a discussion about what we might do, and we post designs and those kinds of things. +And it's not until it's actually okay; we plan to do this three weeks from now that it gets a ticket created. And if you're really aggressive about that, that works pretty well. But you really need to stay on top of it. And if someone creates a ticket for something, and then it turns out that you're not going to do it in a reasonable timeframe, it moves out and becomes a discussion. +DIZE: Oh, I really like that. That's a really great process. I feel like I'm using this as a [laughter] mentorship session. So thank you for that guidance. +CHAD: My pleasure. It's funny that we've hit upon this because I think it is a common problem. And then the other thing is like, okay, great, Chad, that's wonderful. I have 600 things in the backlog; how can you...I don't have a great answer for that [laughs] other than basically one of the things that I've done and seen other teams do is...so what project management tool are you using now? +DIZE: We're using Asana. +CHAD: Asana. It's basically creating another project and taking everything that's not going to be done in the next two or three weeks and moving it to another project and then saying, okay, what our process from now is going to be is we have a biweekly planning meeting, or we have a weekly planning session. And what we're doing as part of that is taking things from the project where we moved everything to, and we're only moving the things over that we're actually prioritizing and going to do in the next X number of weeks. +DIZE: Cool. That makes a lot of sense. Thank you. +CHAD: I hope that's helpful. [laughs] +DIZE: That is helpful. No, yeah, thank you so much. I'm still new, and I have so much to learn. [laughs] So this has been really, really informative. +CHAD: So actually, this leads me to something I was wondering about based on this conversation and just in general, is as CTO, who are you actually leading? And is there a separate product manager or a team that actually doesn't report to you? +DIZE: No. I basically lead the product team. We do have a product designer who takes on more of the management of the design part of the product team, but I don't think we've grown big enough to silo like that yet. +CHAD: And I don't recommend it. I think it's great when you have an integrated design and development team working together. At a certain size, yeah, you need to create divisions, and you need to, you know, that kind of thing. But it's better when design and development work really closely together to create something great, in my opinion. +DIZE: Yeah. I've also found that to be effective. +CHAD: You have people on your team with different levels of experience. How, as a leader, do you attempt to...I think you're a great example of someone who joined at the level of software developer and grew in their career to be CTO. Like, how do you help others do that? +DIZE: I think the biggest part of that is assessing how they see their career growing. I don't know if everybody wants to be a CTO, wants to be a manager, or just wants to continue to be an individual contributor at a higher level. So just trying to work with them to figure that out for themselves and then providing opportunities to gain that experience like leading a project, or taking on management responsibilities, providing more ownership, and leaving them to their own devices as much as they are comfortable. +CHAD: The fact that mRelief is a non-profit, how much does that factor into your day-to-day or your ability to build a team and hire or anything like that? Is that something that you feel on a regular basis? +DIZE: The biggest way that I feel it is hiring. I don't know if you're also experiencing this, but it's like, it's been a very competitive market, especially recently. And I know it's always been, but recently, I feel like it's turned up a lot. Trying to align compensation to the market has been a particular challenge. +CHAD: Where does the funding for mRelief come from? +DIZE: So we're funded in a couple of different ways, a couple of different streams. We are funded through grants, individual donations, and government contracts. +CHAD: Hiring, especially in a world where you're competing to hire against companies that don't need to be sustainable or profitable, like, they've gotten millions of dollars, and they can just spend it, that is tough. And thoughtbot has existed in that environment forever basically because we're a consulting company which started from scratch without any investors or anything like that. +And so we focused on being the kind of place that people want to work, having good benefits. We're not going to be able to compete against companies on compensation directly. And so we focus more on paying people fairly and what we can afford but being the kind of place that people actually want to work. +DIZE: What have you found to be the most, I guess, successful exploration of that? +CHAD: Well, it's evolved over time. There were a lot of things that we could put out there in terms of what it was like to work at thoughtbot versus what it was like to work at the typical startup company that made us special, and it wasn't anything radical. It was just like, you're going to work sustainably, and we're not going to approach deadlines in the same way. You're going to have agency over your work. +You're going to work with a really great, smart team of people who are all sort of like...the analogy I use is like a professional sports team. They make it look easy. And it's not super stressful all the time because you don't need stress in order to do great things; you need people who are given the space to do great work. +And I'll be honest; actually, we're one of the best places you can work if you want to do Rails work. Now, a lot of that stuff has evolved. I think startup culture is different than it was 15 years ago. And there are more companies where you can work in Rails that aren't as bad as they quite honestly used to be. We used to be able to point to companies and be like, you don't want to work there. And there are less companies that we can do that to now. +DIZE: Oh wow. Okay, so folks have started to kind of simmer down on expectations and just the hassle of startup culture? +CHAD: I think so. And then you have examples if you want to stay working in Ruby, then you have companies like GitHub and that sort of thing where they hire remotely. They've addressed a lot of the problems that they had in their culture. No company is perfect, but I think they've made it seemingly from the outside. +And from the number of thoughtbot people that we've had join GitHub, they seem to have addressed some of those issues. We've needed to, in some ways, double down on some of them, like in terms of really recognizing we can have a culture where you can actually have an impact on who we are and what we do in a way that you can't in a big company. +DIZE: Oh, yeah, yeah. That resonates for sure. +CHAD: Is that part of what you've done? Obviously, you have a mission-driven impact-oriented thing which I think probably draws people who want to do that, right? +DIZE: Yeah. And I think what we can offer that feels more unique is shared leadership. So like you said, having a lot of sway and impact on the way that the organization is run day-to-day because we really believe in distributing those responsibilities. +CHAD: What's next for you and the mRelief team? +DIZE: Well, we have some goals this year that mean expanding to a couple of more states. So we have our simplified application and also our assistance platform and about 12 partners, ten states, or something like that. And we want to expand to eight more states by June of 2023. So that's going to be a lot of our focus this next year. +CHAD: So you talked about how hiring has been a challenge. So I presume that means you're trying to hire some new people to be able to accomplish these goals. +DIZE: [laughs] Yes. Right now, we're looking for a full-stack dev experienced in React and Rails at least a year or two to help us with that expansion. +CHAD: Oh, that's another thing that has helped us hire is having an apprentice program where the majority...we don't take people who are brand new and teach them. But it's sort of like one level up, taking intermediate people who wouldn't be able to bill at the level us and our clients need them to and getting them to that level in a three to a six-month timeframe where we don't bill their time. They're paired with mentors. They work one on one with a mentor, and it's a rotation program. So they rotate the mentors. That has been really helpful for us. +DIZE: That's amazing. I would love to do something like that, and I would love to also even train folks from the ground up. I feel like that's like a pipe dream just based on capacity. But I think there are so many folks whose voices don't get to be in product development, and I'd love to foster that. +CHAD: Do you think you have the space to be able to do that, or do you think that what you're saying about it's hard for your team to have the bandwidth to train those folks? +DIZE: I think it's a problem of bandwidth, at least right now. Hopefully, it'll change. +CHAD: That's one of the reasons why we don't work with people in the beginning stages but rather someone who can be an effective pair for a Rails developer. That's a good point because they can learn a lot, but they're an effective pair. They're not slowing anybody down, and we can teach them primarily through pairing. Whereas if someone doesn't even know HTML, that is an issue that we haven't been able to...we can train, but it's hard to balance that and have enough bandwidth to teach people that. +DIZE: Yeah, that's brilliant. That makes a lot of sense. What kind of credentials do those folks usually have? Are they out of a bootcamp or self-taught? +CHAD: Some of them are out of bootcamp, and we could take more out of bootcamp. Out of bootcamp is actually a very fine stage. The problem is that there just aren't a lot of opportunities like this. And so, for example, for our last quarter's apprenticeship, we had four apprentice positions, two designers and two developers. We got 1,033 applications. +DIZE: Oh my God. Oh my God. Wow. +CHAD: And we screen all of them, and we respond to everybody but as a result of that, what it means is the more experienced people are likely to take up and get the spot over someone with no experience at all, which I don't love, but it's difficult to not have that happen. +DIZE: Got it. Very, very competitive. Wow. +CHAD: Right. Right. Our people operations person likes to point out that it's more competitive than Harvard. +DIZE: Oh my God. [laughs] What does that make the acceptance rate? +CHAD: I don't know. [laughs] Four out of 1033; I don't know. +DIZE: Dang. [laughs] +CHAD: It's low. In order to balance that a little bit and to strike a balance and find the people who I like to call the top candidates, like, they're not the most qualified, but they're the top. And I'm still working on this term but basically focusing on things that aren't just what they can do for code or their coding experience. +Like, the things that are important for consulting are like, do you have experience talking with people? Have you been a teacher? Have you been in retail? Even being in retail is a little bit of a plus over someone else necessarily who's just been a coder forever. +DIZE: Yeah, yeah, some kind of diverse working background. +CHAD: And at least I think it's really important that someone with a really strong background that lends themselves to being a good consultant is able to get an interview even if they don't have a lot of actual work experience. I think that that's really important, at least giving them the shot even if, after interviewing them, we think that we need to move forward this other candidate. +I think it's really important that the initial screening not completely screen out people just based on, for example, years of experience. We don't look at degrees at all. That's not even a factor in normal thoughtbot hiring. It's not something that we look at. +DIZE: Oh, good. That is such a cool program. I wish more places did that. [laughs] +CHAD: Oh, me too. It would make our job easier because we wouldn't need to reject so many people. We could refer them to these other places. +DIZE: [laughs] Oh my gosh. Yeah. +CHAD: We're actually changing the program for 2022 because we know that there are tons of people, not a lot of opportunity. It used to be that we would do interviews, and then we'd be forced to say, "We're not taking you now, but we are moving forward in the process with these ten people and whittling it down to the 2." +What we're doing now is we actually continue the interview process with everyone who passes the things that we're looking for. So we can get to the end of the process, and even if we only have two slots, we've identified the five people who would have been able to do it. And then what we do is we say, "We think you're a great fit. There are just not enough slots right now. So can we reconsider you or schedule you for a future slot?" That's what we're trying to do. +DIZE: Interesting. Has it been helpful? +CHAD: We're only in the second quarter of doing that. So we're still a little early with that change. But I can already anticipate the problem, which is there are too many people we would take. +DIZE: Ooh, yeah. [laughs] +CHAD: And so I carried forward 15 People from the last session, from the last quarter. And that 15 is more than...[laughs] and unless we're willing to then turn off applications so new people can't apply, we still get, you know, so the last quarter was 970 applications about. +DIZE: Oh wow. +CHAD: This quarter was 1,033. So one of the factors that has really helped with our hiring is we decided to go fully remote at the beginning of 2021, and that has really helped us expand to being able to hire a little bit more competitively by not competing against everyone in the places where we had offices previously. +DIZE: That makes sense. +CHAD: But I noticed that you're still a Chicago-based team, right? +DIZE: We're still Chicago-based, but we're remote now, fully remote. Our headquarters are here. We do have a lot of team members here. We also have folks throughout the States. +CHAD: On the development team too? +DIZE: Yes, on the development team. +CHAD: Oh, okay, great. So when did that...did that change with the pandemic, or did you have it before? +DIZE: It changed with the pandemic. So before, we weren't remote at all; we were always in person. +CHAD: Has that been a big change, or an easy change, or a hard change for your team? +DIZE: I think a pretty easy change. I think we're all...well, I don't want to speak for everybody, but it seems like it went quite smoothly. We do offer a monthly stipend for Deskpass in case anyone wants a physical workspace and may sometimes meet up to co-work for a sense of community and camaraderie. But other than that, folks seem to really enjoy it. +CHAD: Yeah, I think for us, it was also not a difficult transition when it came down to a lot of the work and that kind of thing. I think the biggest challenge for us has been we're bigger, and so there were people...and we very much we are local teams working with local clients. And so, there was a segment of the thoughtbot team that never opted in to a fully remote company. +And so they've understood the transition, but they didn't necessarily choose it for themselves. And so they have their choice of...like you said, it's a competitive market. It is important for teams to be clear about who they are and how they work. And if someone at the end of that says, "You know what? I understand, and that's not for me," I think that's okay. +DIZE: Yeah, definitely, like self-selection. [laughs] +CHAD: Yeah. Well, thank you so much for stopping by and talking with me. I really appreciate it. +DIZE: Yeah, thank you for having me. It was so lovely to chat. And thank you for all the great advice. +CHAD: I wish you and the mRelief team all the best and keep in touch. +DIZE: Thank you, you too. +CHAD: Oh, wait, if people want to find out more, we got to say the website. [laughs] And if they want to get in touch with you, where are the best places for them to do that? +DIZE: So our website is mRelief, so M as in mom, relief as in sigh of relief, mrelief.com. We're on some socials. Our name differs [laughs] based on the social, but we're on Twitter and, Instagram, TikTok soon. [laughs] +CHAD: Oh, wow. +DIZE: [laughs] Yeah, that's it. +CHAD: And that's where people can find the job posting as well? +DIZE: Yeah, on our website. +CHAD: Awesome. Well, thank you again. +DIZE: Yeah, thank you. +CHAD: You can subscribe to the show and find notes for this episode along with an entire transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Dize Hacioglu. + + + Dize Hacioglu is the CTO of Chicago’s mRelief, which offers an easy-to-use platform that helps families connect to SNAP food benefits. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits.

+ +

Chad talks with Dize about how the platform helps people navigate the often complicated food stamp benefits system, what her role as CTO looks like as a CTO who codes, and how she hopes to help facilitate the growth of the mRelief program and team.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dize Hacioglu, the CTO of mRelief, an easy-to-use platform that helps families connect to the Supplemental Nutrition Assistance Program. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits. Dize, thanks for joining me.

+ +

DIZE: Yeah, thank you so much for having me.

+ +

CHAD: And thank you for all of your work at mRelief. It's a big help to everybody.

+ +

DIZE: It's my pleasure, and it's really an honor to be able to do the work that we do.

+ +

CHAD: Speaking of that work, tell me a little bit more about what the platform actually does for people.

+ +

DIZE: So mRelief is an easy to use platform that's accessible over text messaging or web that helps folks find out if they qualify for SNAP, formerly known as food stamps, and helps them apply in certain states or connect with community-based organizations who can help them apply if they'd like further assistance.

+ +

CHAD: So it's a pretty focused product, right? [laughs]

+ +

DIZE: Mm-hmm.

+ +

CHAD: But I'm sure that there's a lot going behind the scenes in order to make that pretty focused product happen. Is that right?

+ +

DIZE: Yeah, that's right. That's right. Yes, there are a lot of moving parts.

+ +

CHAD: [laughs] So what's involved in figuring out whether someone is eligible or not?

+ +

DIZE: So there are actually a few patterns that we've discovered as we've been expanding our work from just one state where we were just in California for a while and then expanding it nationwide. We found that eligibility typically falls into a couple of different buckets. So we've been able to turn that into code that helps guide people through the typical questions of eligibility and takes them through the flow based on their state's eligibility of requirements.

+ +

CHAD: I guess my next question was going to be without mRelief; how difficult is this for folks?

+ +

DIZE: So I think most folks typically apply hoping that they're eligible, and they'll only really find out after the application process has been complete. They may have wasted time at the office, time filling out the application, time waiting for a phone call from the office only to find out that they are not eligible.

+ +

CHAD: So you mentioned you started just in California, and you've been expanding from there. You mentioned there are patterns that you found. How different are things state to state? And what does your growth trajectory look like throughout the United States?

+ +

DIZE: The biggest differences between states are income limits, the threshold that a family has to fall under in terms of monthly gross income to be able to qualify. So that has been a big data collection research project that we've done to be able to expand to all 50 states. And from their past eligibility, applications also differ from state to state. There's no one platform where you can fill out the same questions that are asked.

+ +

CHAD: I was just doing an onboarding call with some folks who are joining the thoughtbot team. And on the call, there was one person in the United States, three people who live in different countries in Africa; I think one other person in Europe. And sometimes, when I'm doing the onboarding calls with them, I have to explain how disjointed things are in the United States and which things are state by state because it surprises people.

+ +

Well, one, it surprises people who aren't in the United States that we don't have certain standard benefits like sick time in the United States. And then it also surprises people how much is actually determined by the state that you live in, even with...because SNAP is a national program, right?

+ +

DIZE: Correct. Yeah, it's federally funded.

+ +

CHAD: Right. So even with a federally-funded program, it still comes down to certain things being different in certain states, which is often really daunting and surprising to people.

+ +

DIZE: Yes, totally, totally. And it also gets even more complicated in some states like California and maybe even Texas, where it's county-administered, so each county has a different process. Sometimes they have different applications even between counties in the same state.

+ +

CHAD: So is there a reason for this other than making it hard for people to get the benefit? [laughter] That might be a political question. I just totally exposed my -- [laughter]

+ +

DIZE: I think that's a very valid question because I think we've seen instead of cutting benefits completely, administratives put up to dissuade people or make it more burdensome for people to access benefits as a way of keeping them from benefits nationwide, not just like any specific state. So I think that's a very valid question.

+ +

CHAD: But it's possible that there are other reasons, right? So, for example, like, oh, it's administered locally, or income levels are different in different places, and so it needs to be...I was just curious whether there were other reasons.

+ +

DIZE: Yeah, I'm actually not sure about the reasoning.

+ +

CHAD: Yeah, fair enough. Fair enough.

+ +

DIZE: [chuckles]

+ +

CHAD: So you joined in 2017.

+ +

DIZE: Yes, I did.

+ +

CHAD: And Emily started in 2014.

+ +

DIZE: That's right.

+ +

CHAD: So what were things like when you joined?

+ +

DIZE: Well, I joined a team of two, and the two folks that were already on the team were the co-founders, Rose Afriyie and Genevieve Nielsen, and I was also joined by another co-worker who was hired at the same time as me. And we were only doing work in California, helping folks find out if they're eligible, helping them apply for CalFresh, which is the name for SNAP in California, and helping them through the post-application process like interviewing, collecting documents, getting a Lift ride to the office to get their card. So we were really focused on the end-to-end process in one specific, again, county because it's county-administered in California.

+ +

CHAD: So in just one county.

+ +

DIZE: Yeah, in San Francisco.

+ +

CHAD: And was there a tech platform at the time?

+ +

DIZE: Yes, we had our screener, and we had our simplified application.

+ +

CHAD: Had the founders created that?

+ +

DIZE: Yes.

+ +

CHAD: Okay. And how did they focus on...they're not in California, they're in Chicago, right?

+ +

DIZE: Yeah, we're based in Chicago.

+ +

CHAD: So why California and why that particular county? Do you know?

+ +

DIZE: I think it was an amalgamation of things (I don't know if I used that word right.), but they attended Y Combinator early on in the development of mRelief. So through that, they were able to get connections to the San Francisco Human Services Agency, who was our first big contract and allowed us to really develop the end-to-end process.

+ +

CHAD: So you joined as the third/fourth person on the team?

+ +

DIZE: Yes.

+ +

CHAD: And it may be obvious, but I'm going to ask the question anyway. What drew you to joining?

+ +

DIZE: I've always loved coding. For a long time, I felt at a loss how to combine my love of coding and wanting to pursue coding as a career with my desire to try to make a positive social impact in the world. And I don't think back in 2017; I was really aware of the civic tech space. In perusing job descriptions nationwide, I stumbled across mRelief on Idealist, and it sounded like the perfect match. And I remember feeling like this is my dream job. I can't believe I get to do this work and code at the same time.

+ +

CHAD: [laughs] So you joined as a software developer at the time. Did you have aspirations to be CTO when you joined?

+ +

DIZE: No. [laughs] No, I remember looking at Genevieve, our former CTO and co-founder, and thinking I have no idea how she does her job and never thinking that I would find myself in this position. And it's been a massive learning experience and also a growth opportunity for me.

+ +

CHAD: What are some of the things that you needed to grow into or to learn in order to get to that point?

+ +

DIZE: I feel like most of the learning happened after. The biggest thing that I learned to prepare me to go into the CTO role was basically a very comprehensive understanding of our codebase. I think most of the skills or what I need to succeed in this role came after.

+ +

CHAD: Well, actually, let me ask a related but different question. CTO actually differs in different organizations. So, what does your role as CTO actually look like?

+ +

DIZE: It definitely does. And I think my role has even changed a bit in the year and a half or a year and three months that I've been in this role based on the growing team that we have at mRelief. But my day-to-day basically looks like working with our product team to plan for new features. I like to code, so I try to do some coding at least every day and also general oversight and, I guess, strategic thinking.

+ +

CHAD: One way in that description that stands out to me, you know, some other CTO might describe their role as very much not working on the code, very much not even really working with the team or product, and more focused on the executive level of the company or the needs of fundraising or something like that. So it sounds like you're very much still product-focused and oriented towards working on the product.

+ +

DIZE: Yeah, I think that's driven by a selfish desire to keep coding.

+ +

[laughter]

+ +

CHAD: You're talking to someone who is in the exact same spot. There are times where I feel guilty about that.

+ +

DIZE: Yeah. [laughs]

+ +

CHAD: Here's my justification, [laughter], and I'll be curious in terms of your justification. I've done this for 19 years now. And I'm pretty confident that I would have burned out a long time ago if I didn't spend time coding. It's part of what I find rejuvenating and what I love to do. It doesn't mean that I can always afford to work on something for four hours straight, but it's part of what has made me be able to enjoy this work for so long.

+ +

DIZE: Yeah, I completely relate to that. If I wasn't coding, I don't know how long I could sustain myself [laughs] with so much responsibility. How do you find that balance?

+ +

CHAD: Well, I think part of it is freeing yourself up to not feel guilty so being really clear with others. Like, if someone asks for something from me, being like, yep, totally, I can do that. I can get it done by this day and pretty aggressively planning out my work or time, blocking my calendar and making it clear when I'm going to be able to have that thing for them.

+ +

And if that timeline doesn't work, then they can tell me that, and I can adjust. But that goes a long way towards when I am having a coding session that lasts half a day or something like that; I cannot worry or feel guilty that someone's waiting on me for something or that it's not what I should be spending time on.

+ +

DIZE: Yeah, that makes a lot of sense.

+ +

CHAD: What about you? Have you found things that work for you?

+ +

DIZE: I have been trying different things. I've been doing a lot of YouTube deep dives on productivity blogs, just different ways of thinking about prioritizing work and making sure that things get done. But I really like your point about allowing yourself not to feel guilty. And I do like to remind myself that I don't want to take the fun out of my job. I want that for other folks on the team, and I also want that for myself.

+ +

CHAD: The other thing that is on my mind when I'm doing something is there's this stereotype of the CTO who codes and makes a mess of things that the other people have to clean up.

+ +

DIZE: [laughs] Oh no. I didn't know about that.

+ +

CHAD: You know what I'm talking about?

+ +

DIZE: No. [laughs]

+ +

CHAD: Oh, no, no? It's like, oh, the CTO made commits at 9:00 p.m. last night. I guess I have to...and the build is broken.

+ +

DIZE: Oh no.

+ +

CHAD: I guess I have to...[laughs] so, does that describe you or no? [laughs]

+ +

DIZE: Oh my gosh. I'm definitely seeing myself in that description a little bit. [laughs]

+ +

CHAD: Oh no. [laughs]

+ +

DIZE: Literally, I was up last night pushing code to production, but I think it's okay. [laughter] I mean, I hope that that's not me. [laughs]

+ +

CHAD: I try to avoid that because, you know, I want to feel like my work is useful and valued and not creating more work for other people.

+ +

DIZE: Yeah, definitely. I agree.

+ +

[laughter]

+ +

CHAD: Tell me more about the tech stack for mRelief.

+ +

DIZE: So we use React and Rails. We're hosted on Heroku. Yeah, very basic.

+ +

CHAD: I heard that you use some thoughtbot stuff, so I assumed that it was Rails.

+ +

DIZE: [laughs] Yes. Yeah.

+ +

CHAD: That's great to hear.

+ +

DIZE: Yeah, I was messing with Paperclip this morning, actually. [laughs]

+ +

CHAD: Oh, well, Paperclip is deprecated. I'm sorry to tell you. [laughs]

+ +

DIZE: I know. [laughter] I had to fork it this morning to make a change.

+ +

CHAD: I still stand by that decision. I think it's important as sort of a community contributor that we signal overall direction and coalesce behind what's built into Rails once it was there.

+ +

DIZE: Okay, that makes a lot of sense.

+ +

CHAD: But yeah, was Rails in use when you joined?

+ +

DIZE: Yeah, we're using the same stack.

+ +

CHAD: How much has it grown over time, the codebase?

+ +

DIZE: I don't really know.

+ +

CHAD: That's interesting that you don't know. [laughs]

+ +

DIZE: When you say grown, like, I guess how is that measured?

+ +

CHAD: Oh yeah. I mean, is it more complex now than it was when you joined?

+ +

DIZE: Yes, definitely. Yeah, we've added new products that had never existed, and the fact that we've expanded to more states and our screener is nationwide that's added a lot of complexity.

+ +

CHAD: So, do you have ways that you manage that complexity, either in the code or in the business?

+ +

DIZE: What would that look like? [laughter] How would you manage that complexity?

+ +

CHAD: Well, I think it's a little dependent on where the complexity is coming from. So, for example, the screener is nationwide, you said, and so does the screener change based on where you're located once you start to fill it out?

+ +

DIZE: Yes, yes. The first question we ask is zip code.

+ +

CHAD: And then how does all of that branching work in the state-specific logic work? Is it all one big jumble of if statements and code, or is it factored out in some way to help keep that as clean as possible? And if the answer is it's all one big jumble of if statements, that's totally fine. [laughs]

+ +

DIZE: I was actually going to say both. [laughs] Because I think because of the patterns that we were able to establish, and the eligibility logic between all states, there's definitely some if branching, but there are enough shared concepts that we can keep it all in one to two files that are not too long.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you mentioned the team has grown quite a bit. It seems like the development and design team is quite a bit bigger than two people now. How big is it?

+ +

DIZE: Well, the product team itself is eight people now, I think. And the team, the whole mRelief team, we just had two new folks start today, so I think we're at 20.

+ +

CHAD: What does your onboarding process for bringing new team members on look like from a technical perspective?

+ +

DIZE: So the first two weeks, folks are typically in a bunch of onboarding meetings just getting acquainted with the history of mRelief, our current processes, and stuff like that. But for our tech team, we like to jump in with them as soon as possible, get them set up obviously locally and have them contributing with some kind of low-hanging fruit tickets at first so that they have some code pushed up in the first week or two.

+ +

CHAD: Are you facilitating that through pairing with someone existing on the team, or are folks doing that independently?

+ +

DIZE: Depending on the complexity of the ticket, sometimes we pair. Mostly it's independent work.

+ +

CHAD: Some companies and some teams have the goal of like, oh, you know, first commit to production on your first day. Do you have anything like that either with the code or with the processes like benchmarks that you use of, like we really want this to happen but on the first day or in the first week?

+ +

DIZE: No, we don't have anything like that.

+ +

CHAD: At the size, you're at now, some companies start to break into sub-teams or squads or focus areas. Are you starting to do anything like that?

+ +

DIZE: I've thought about it here and there. But I think we all like sharing responsibility for all of the different products and getting our hands into all the different ways that we connect with users. So we haven't formalized anything like that.

+ +

CHAD: So that means you have one backlog of everything that's slated to be worked on.

+ +

DIZE: Yeah, that's right.

+ +

CHAD: Is that overwhelming sometimes?

+ +

DIZE: Yes. [laughter] Yeah. I don't know about your experience with backlogs, but I assume that they're always overwhelming.

+ +

CHAD: Yeah, that's a really good way of putting it. I think that not having it requires very aggressive management that a lot of teams are not willing to do. And then when you have a team of 10 or 12 people all working across multiple apps or all on the same app doing a lot of different stuff, that's overwhelming on the other side of just the amount of stuff that's happening every day can sometimes be overwhelming.

+ +

And people start to sort of step on each other. Oh, you know, we've got these two pull requests, and every time I go to make a change, something has merged into main that now my branch is behind. And if you're waiting for CI to pass and your CI is too long, something new has been merged in by the time your CI run finishes. Those are some of the challenges that I hear people facing.

+ +

DIZE: Interesting. What are those aggressive management things that you were speaking of to avoid backlogs?

+ +

CHAD: I think it basically means saying no to things. So I think when we talk about a backlog being overwhelming, one of the worst things that comes to mind mostly, and let me know if this is part of the problem you're feeling or not, but it's really long. And somewhere in there, there's like the bug that was created two years ago by someone that has never been addressed, or maybe it has been, and the ticket was never moved forward. And so you end up with 500-600 things and a long list that becomes then very difficult to ever really prioritize because it's not possible to prioritize that many issues. Does that resonate with you at all?

+ +

DIZE: That does resonate. I was scrolling through our backlog today, and I was like, when is this going to end? [laughter] I guess I hope that was normal. [laughs]

+ +

CHAD: It is normal, or I should say I think it's common.

+ +

DIZE: Common, okay. [laughs]

+ +

CHAD: I think it is a problem a lot of companies face. And like I was saying, I think one of the only solutions to that is basically, well, so either someone or a team that is very comfortable saying, "We don't need a ticket for that because we're just not going to get to it," or being able to delete something that you've not...or move it out that this was created two years ago. It's just not doing us any value to have it hanging around anymore.

+ +

DIZE: Yeah, that makes a lot of sense. That's helpful.

+ +

CHAD: And some companies do it by policy basically. They have a philosophy or a policy that says, "This needs to be a thing that comes up." They have a product manager who's paying attention to what's going on and is like, okay, this is the third time that this has come up. Now we'll create a ticket for it because we're actually going to do it. And you only create tickets for things that are for the next four weeks, for the next six weeks, and that you use something else other than tickets.

+ +

So one thing that I've found really works well for me, and I like this idea of the difference between a discussion or an idea and the work to be done is; for example, we often use Trello for project management and a Kanban board of the work that's actually happening in the backlog. But anything that's not a concrete item that we're going to actually prioritize and do is better off in a messaging system like Basecamp or another tool where it's more of like a discussion about what we might do, and we post designs and those kinds of things.

+ +

And it's not until it's actually okay; we plan to do this three weeks from now that it gets a ticket created. And if you're really aggressive about that, that works pretty well. But you really need to stay on top of it. And if someone creates a ticket for something, and then it turns out that you're not going to do it in a reasonable timeframe, it moves out and becomes a discussion.

+ +

DIZE: Oh, I really like that. That's a really great process. I feel like I'm using this as a [laughter] mentorship session. So thank you for that guidance.

+ +

CHAD: My pleasure. It's funny that we've hit upon this because I think it is a common problem. And then the other thing is like, okay, great, Chad, that's wonderful. I have 600 things in the backlog; how can you...I don't have a great answer for that [laughs] other than basically one of the things that I've done and seen other teams do is...so what project management tool are you using now?

+ +

DIZE: We're using Asana.

+ +

CHAD: Asana. It's basically creating another project and taking everything that's not going to be done in the next two or three weeks and moving it to another project and then saying, okay, what our process from now is going to be is we have a biweekly planning meeting, or we have a weekly planning session. And what we're doing as part of that is taking things from the project where we moved everything to, and we're only moving the things over that we're actually prioritizing and going to do in the next X number of weeks.

+ +

DIZE: Cool. That makes a lot of sense. Thank you.

+ +

CHAD: I hope that's helpful. [laughs]

+ +

DIZE: That is helpful. No, yeah, thank you so much. I'm still new, and I have so much to learn. [laughs] So this has been really, really informative.

+ +

CHAD: So actually, this leads me to something I was wondering about based on this conversation and just in general, is as CTO, who are you actually leading? And is there a separate product manager or a team that actually doesn't report to you?

+ +

DIZE: No. I basically lead the product team. We do have a product designer who takes on more of the management of the design part of the product team, but I don't think we've grown big enough to silo like that yet.

+ +

CHAD: And I don't recommend it. I think it's great when you have an integrated design and development team working together. At a certain size, yeah, you need to create divisions, and you need to, you know, that kind of thing. But it's better when design and development work really closely together to create something great, in my opinion.

+ +

DIZE: Yeah. I've also found that to be effective.

+ +

CHAD: You have people on your team with different levels of experience. How, as a leader, do you attempt to...I think you're a great example of someone who joined at the level of software developer and grew in their career to be CTO. Like, how do you help others do that?

+ +

DIZE: I think the biggest part of that is assessing how they see their career growing. I don't know if everybody wants to be a CTO, wants to be a manager, or just wants to continue to be an individual contributor at a higher level. So just trying to work with them to figure that out for themselves and then providing opportunities to gain that experience like leading a project, or taking on management responsibilities, providing more ownership, and leaving them to their own devices as much as they are comfortable.

+ +

CHAD: The fact that mRelief is a non-profit, how much does that factor into your day-to-day or your ability to build a team and hire or anything like that? Is that something that you feel on a regular basis?

+ +

DIZE: The biggest way that I feel it is hiring. I don't know if you're also experiencing this, but it's like, it's been a very competitive market, especially recently. And I know it's always been, but recently, I feel like it's turned up a lot. Trying to align compensation to the market has been a particular challenge.

+ +

CHAD: Where does the funding for mRelief come from?

+ +

DIZE: So we're funded in a couple of different ways, a couple of different streams. We are funded through grants, individual donations, and government contracts.

+ +

CHAD: Hiring, especially in a world where you're competing to hire against companies that don't need to be sustainable or profitable, like, they've gotten millions of dollars, and they can just spend it, that is tough. And thoughtbot has existed in that environment forever basically because we're a consulting company which started from scratch without any investors or anything like that.

+ +

And so we focused on being the kind of place that people want to work, having good benefits. We're not going to be able to compete against companies on compensation directly. And so we focus more on paying people fairly and what we can afford but being the kind of place that people actually want to work.

+ +

DIZE: What have you found to be the most, I guess, successful exploration of that?

+ +

CHAD: Well, it's evolved over time. There were a lot of things that we could put out there in terms of what it was like to work at thoughtbot versus what it was like to work at the typical startup company that made us special, and it wasn't anything radical. It was just like, you're going to work sustainably, and we're not going to approach deadlines in the same way. You're going to have agency over your work.

+ +

You're going to work with a really great, smart team of people who are all sort of like...the analogy I use is like a professional sports team. They make it look easy. And it's not super stressful all the time because you don't need stress in order to do great things; you need people who are given the space to do great work.

+ +

And I'll be honest; actually, we're one of the best places you can work if you want to do Rails work. Now, a lot of that stuff has evolved. I think startup culture is different than it was 15 years ago. And there are more companies where you can work in Rails that aren't as bad as they quite honestly used to be. We used to be able to point to companies and be like, you don't want to work there. And there are less companies that we can do that to now.

+ +

DIZE: Oh wow. Okay, so folks have started to kind of simmer down on expectations and just the hassle of startup culture?

+ +

CHAD: I think so. And then you have examples if you want to stay working in Ruby, then you have companies like GitHub and that sort of thing where they hire remotely. They've addressed a lot of the problems that they had in their culture. No company is perfect, but I think they've made it seemingly from the outside.

+ +

And from the number of thoughtbot people that we've had join GitHub, they seem to have addressed some of those issues. We've needed to, in some ways, double down on some of them, like in terms of really recognizing we can have a culture where you can actually have an impact on who we are and what we do in a way that you can't in a big company.

+ +

DIZE: Oh, yeah, yeah. That resonates for sure.

+ +

CHAD: Is that part of what you've done? Obviously, you have a mission-driven impact-oriented thing which I think probably draws people who want to do that, right?

+ +

DIZE: Yeah. And I think what we can offer that feels more unique is shared leadership. So like you said, having a lot of sway and impact on the way that the organization is run day-to-day because we really believe in distributing those responsibilities.

+ +

CHAD: What's next for you and the mRelief team?

+ +

DIZE: Well, we have some goals this year that mean expanding to a couple of more states. So we have our simplified application and also our assistance platform and about 12 partners, ten states, or something like that. And we want to expand to eight more states by June of 2023. So that's going to be a lot of our focus this next year.

+ +

CHAD: So you talked about how hiring has been a challenge. So I presume that means you're trying to hire some new people to be able to accomplish these goals.

+ +

DIZE: [laughs] Yes. Right now, we're looking for a full-stack dev experienced in React and Rails at least a year or two to help us with that expansion.

+ +

CHAD: Oh, that's another thing that has helped us hire is having an apprentice program where the majority...we don't take people who are brand new and teach them. But it's sort of like one level up, taking intermediate people who wouldn't be able to bill at the level us and our clients need them to and getting them to that level in a three to a six-month timeframe where we don't bill their time. They're paired with mentors. They work one on one with a mentor, and it's a rotation program. So they rotate the mentors. That has been really helpful for us.

+ +

DIZE: That's amazing. I would love to do something like that, and I would love to also even train folks from the ground up. I feel like that's like a pipe dream just based on capacity. But I think there are so many folks whose voices don't get to be in product development, and I'd love to foster that.

+ +

CHAD: Do you think you have the space to be able to do that, or do you think that what you're saying about it's hard for your team to have the bandwidth to train those folks?

+ +

DIZE: I think it's a problem of bandwidth, at least right now. Hopefully, it'll change.

+ +

CHAD: That's one of the reasons why we don't work with people in the beginning stages but rather someone who can be an effective pair for a Rails developer. That's a good point because they can learn a lot, but they're an effective pair. They're not slowing anybody down, and we can teach them primarily through pairing. Whereas if someone doesn't even know HTML, that is an issue that we haven't been able to...we can train, but it's hard to balance that and have enough bandwidth to teach people that.

+ +

DIZE: Yeah, that's brilliant. That makes a lot of sense. What kind of credentials do those folks usually have? Are they out of a bootcamp or self-taught?

+ +

CHAD: Some of them are out of bootcamp, and we could take more out of bootcamp. Out of bootcamp is actually a very fine stage. The problem is that there just aren't a lot of opportunities like this. And so, for example, for our last quarter's apprenticeship, we had four apprentice positions, two designers and two developers. We got 1,033 applications.

+ +

DIZE: Oh my God. Oh my God. Wow.

+ +

CHAD: And we screen all of them, and we respond to everybody but as a result of that, what it means is the more experienced people are likely to take up and get the spot over someone with no experience at all, which I don't love, but it's difficult to not have that happen.

+ +

DIZE: Got it. Very, very competitive. Wow.

+ +

CHAD: Right. Right. Our people operations person likes to point out that it's more competitive than Harvard.

+ +

DIZE: Oh my God. [laughs] What does that make the acceptance rate?

+ +

CHAD: I don't know. [laughs] Four out of 1033; I don't know.

+ +

DIZE: Dang. [laughs]

+ +

CHAD: It's low. In order to balance that a little bit and to strike a balance and find the people who I like to call the top candidates, like, they're not the most qualified, but they're the top. And I'm still working on this term but basically focusing on things that aren't just what they can do for code or their coding experience.

+ +

Like, the things that are important for consulting are like, do you have experience talking with people? Have you been a teacher? Have you been in retail? Even being in retail is a little bit of a plus over someone else necessarily who's just been a coder forever.

+ +

DIZE: Yeah, yeah, some kind of diverse working background.

+ +

CHAD: And at least I think it's really important that someone with a really strong background that lends themselves to being a good consultant is able to get an interview even if they don't have a lot of actual work experience. I think that that's really important, at least giving them the shot even if, after interviewing them, we think that we need to move forward this other candidate.

+ +

I think it's really important that the initial screening not completely screen out people just based on, for example, years of experience. We don't look at degrees at all. That's not even a factor in normal thoughtbot hiring. It's not something that we look at.

+ +

DIZE: Oh, good. That is such a cool program. I wish more places did that. [laughs]

+ +

CHAD: Oh, me too. It would make our job easier because we wouldn't need to reject so many people. We could refer them to these other places.

+ +

DIZE: [laughs] Oh my gosh. Yeah.

+ +

CHAD: We're actually changing the program for 2022 because we know that there are tons of people, not a lot of opportunity. It used to be that we would do interviews, and then we'd be forced to say, "We're not taking you now, but we are moving forward in the process with these ten people and whittling it down to the 2."

+ +

What we're doing now is we actually continue the interview process with everyone who passes the things that we're looking for. So we can get to the end of the process, and even if we only have two slots, we've identified the five people who would have been able to do it. And then what we do is we say, "We think you're a great fit. There are just not enough slots right now. So can we reconsider you or schedule you for a future slot?" That's what we're trying to do.

+ +

DIZE: Interesting. Has it been helpful?

+ +

CHAD: We're only in the second quarter of doing that. So we're still a little early with that change. But I can already anticipate the problem, which is there are too many people we would take.

+ +

DIZE: Ooh, yeah. [laughs]

+ +

CHAD: And so I carried forward 15 People from the last session, from the last quarter. And that 15 is more than...[laughs] and unless we're willing to then turn off applications so new people can't apply, we still get, you know, so the last quarter was 970 applications about.

+ +

DIZE: Oh wow.

+ +

CHAD: This quarter was 1,033. So one of the factors that has really helped with our hiring is we decided to go fully remote at the beginning of 2021, and that has really helped us expand to being able to hire a little bit more competitively by not competing against everyone in the places where we had offices previously.

+ +

DIZE: That makes sense.

+ +

CHAD: But I noticed that you're still a Chicago-based team, right?

+ +

DIZE: We're still Chicago-based, but we're remote now, fully remote. Our headquarters are here. We do have a lot of team members here. We also have folks throughout the States.

+ +

CHAD: On the development team too?

+ +

DIZE: Yes, on the development team.

+ +

CHAD: Oh, okay, great. So when did that...did that change with the pandemic, or did you have it before?

+ +

DIZE: It changed with the pandemic. So before, we weren't remote at all; we were always in person.

+ +

CHAD: Has that been a big change, or an easy change, or a hard change for your team?

+ +

DIZE: I think a pretty easy change. I think we're all...well, I don't want to speak for everybody, but it seems like it went quite smoothly. We do offer a monthly stipend for Deskpass in case anyone wants a physical workspace and may sometimes meet up to co-work for a sense of community and camaraderie. But other than that, folks seem to really enjoy it.

+ +

CHAD: Yeah, I think for us, it was also not a difficult transition when it came down to a lot of the work and that kind of thing. I think the biggest challenge for us has been we're bigger, and so there were people...and we very much we are local teams working with local clients. And so, there was a segment of the thoughtbot team that never opted in to a fully remote company.

+ +

And so they've understood the transition, but they didn't necessarily choose it for themselves. And so they have their choice of...like you said, it's a competitive market. It is important for teams to be clear about who they are and how they work. And if someone at the end of that says, "You know what? I understand, and that's not for me," I think that's okay.

+ +

DIZE: Yeah, definitely, like self-selection. [laughs]

+ +

CHAD: Yeah. Well, thank you so much for stopping by and talking with me. I really appreciate it.

+ +

DIZE: Yeah, thank you for having me. It was so lovely to chat. And thank you for all the great advice.

+ +

CHAD: I wish you and the mRelief team all the best and keep in touch.

+ +

DIZE: Thank you, you too.

+ +

CHAD: Oh, wait, if people want to find out more, we got to say the website. [laughs] And if they want to get in touch with you, where are the best places for them to do that?

+ +

DIZE: So our website is mRelief, so M as in mom, relief as in sigh of relief, mrelief.com. We're on some socials. Our name differs [laughs] based on the social, but we're on Twitter and, Instagram, TikTok soon. [laughs]

+ +

CHAD: Oh, wow.

+ +

DIZE: [laughs] Yeah, that's it.

+ +

CHAD: And that's where people can find the job posting as well?

+ +

DIZE: Yeah, on our website.

+ +

CHAD: Awesome. Well, thank you again.

+ +

DIZE: Yeah, thank you.

+ +

CHAD: You can subscribe to the show and find notes for this episode along with an entire transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Dize Hacioglu.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dize Hacioglu is the CTO of Chicago’s mRelief, which offers an easy-to-use platform that helps families connect to SNAP food benefits. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits.

+ +

Chad talks with Dize about how the platform helps people navigate the often complicated food stamp benefits system, what her role as CTO looks like as a CTO who codes, and how she hopes to help facilitate the growth of the mRelief program and team.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dize Hacioglu, the CTO of mRelief, an easy-to-use platform that helps families connect to the Supplemental Nutrition Assistance Program. Since it was founded in 2014, the non-profit mRelief has helped 2.8 million Americans unlock $1 billion in food stamp benefits. Dize, thanks for joining me.

+ +

DIZE: Yeah, thank you so much for having me.

+ +

CHAD: And thank you for all of your work at mRelief. It's a big help to everybody.

+ +

DIZE: It's my pleasure, and it's really an honor to be able to do the work that we do.

+ +

CHAD: Speaking of that work, tell me a little bit more about what the platform actually does for people.

+ +

DIZE: So mRelief is an easy to use platform that's accessible over text messaging or web that helps folks find out if they qualify for SNAP, formerly known as food stamps, and helps them apply in certain states or connect with community-based organizations who can help them apply if they'd like further assistance.

+ +

CHAD: So it's a pretty focused product, right? [laughs]

+ +

DIZE: Mm-hmm.

+ +

CHAD: But I'm sure that there's a lot going behind the scenes in order to make that pretty focused product happen. Is that right?

+ +

DIZE: Yeah, that's right. That's right. Yes, there are a lot of moving parts.

+ +

CHAD: [laughs] So what's involved in figuring out whether someone is eligible or not?

+ +

DIZE: So there are actually a few patterns that we've discovered as we've been expanding our work from just one state where we were just in California for a while and then expanding it nationwide. We found that eligibility typically falls into a couple of different buckets. So we've been able to turn that into code that helps guide people through the typical questions of eligibility and takes them through the flow based on their state's eligibility of requirements.

+ +

CHAD: I guess my next question was going to be without mRelief; how difficult is this for folks?

+ +

DIZE: So I think most folks typically apply hoping that they're eligible, and they'll only really find out after the application process has been complete. They may have wasted time at the office, time filling out the application, time waiting for a phone call from the office only to find out that they are not eligible.

+ +

CHAD: So you mentioned you started just in California, and you've been expanding from there. You mentioned there are patterns that you found. How different are things state to state? And what does your growth trajectory look like throughout the United States?

+ +

DIZE: The biggest differences between states are income limits, the threshold that a family has to fall under in terms of monthly gross income to be able to qualify. So that has been a big data collection research project that we've done to be able to expand to all 50 states. And from their past eligibility, applications also differ from state to state. There's no one platform where you can fill out the same questions that are asked.

+ +

CHAD: I was just doing an onboarding call with some folks who are joining the thoughtbot team. And on the call, there was one person in the United States, three people who live in different countries in Africa; I think one other person in Europe. And sometimes, when I'm doing the onboarding calls with them, I have to explain how disjointed things are in the United States and which things are state by state because it surprises people.

+ +

Well, one, it surprises people who aren't in the United States that we don't have certain standard benefits like sick time in the United States. And then it also surprises people how much is actually determined by the state that you live in, even with...because SNAP is a national program, right?

+ +

DIZE: Correct. Yeah, it's federally funded.

+ +

CHAD: Right. So even with a federally-funded program, it still comes down to certain things being different in certain states, which is often really daunting and surprising to people.

+ +

DIZE: Yes, totally, totally. And it also gets even more complicated in some states like California and maybe even Texas, where it's county-administered, so each county has a different process. Sometimes they have different applications even between counties in the same state.

+ +

CHAD: So is there a reason for this other than making it hard for people to get the benefit? [laughter] That might be a political question. I just totally exposed my -- [laughter]

+ +

DIZE: I think that's a very valid question because I think we've seen instead of cutting benefits completely, administratives put up to dissuade people or make it more burdensome for people to access benefits as a way of keeping them from benefits nationwide, not just like any specific state. So I think that's a very valid question.

+ +

CHAD: But it's possible that there are other reasons, right? So, for example, like, oh, it's administered locally, or income levels are different in different places, and so it needs to be...I was just curious whether there were other reasons.

+ +

DIZE: Yeah, I'm actually not sure about the reasoning.

+ +

CHAD: Yeah, fair enough. Fair enough.

+ +

DIZE: [chuckles]

+ +

CHAD: So you joined in 2017.

+ +

DIZE: Yes, I did.

+ +

CHAD: And Emily started in 2014.

+ +

DIZE: That's right.

+ +

CHAD: So what were things like when you joined?

+ +

DIZE: Well, I joined a team of two, and the two folks that were already on the team were the co-founders, Rose Afriyie and Genevieve Nielsen, and I was also joined by another co-worker who was hired at the same time as me. And we were only doing work in California, helping folks find out if they're eligible, helping them apply for CalFresh, which is the name for SNAP in California, and helping them through the post-application process like interviewing, collecting documents, getting a Lift ride to the office to get their card. So we were really focused on the end-to-end process in one specific, again, county because it's county-administered in California.

+ +

CHAD: So in just one county.

+ +

DIZE: Yeah, in San Francisco.

+ +

CHAD: And was there a tech platform at the time?

+ +

DIZE: Yes, we had our screener, and we had our simplified application.

+ +

CHAD: Had the founders created that?

+ +

DIZE: Yes.

+ +

CHAD: Okay. And how did they focus on...they're not in California, they're in Chicago, right?

+ +

DIZE: Yeah, we're based in Chicago.

+ +

CHAD: So why California and why that particular county? Do you know?

+ +

DIZE: I think it was an amalgamation of things (I don't know if I used that word right.), but they attended Y Combinator early on in the development of mRelief. So through that, they were able to get connections to the San Francisco Human Services Agency, who was our first big contract and allowed us to really develop the end-to-end process.

+ +

CHAD: So you joined as the third/fourth person on the team?

+ +

DIZE: Yes.

+ +

CHAD: And it may be obvious, but I'm going to ask the question anyway. What drew you to joining?

+ +

DIZE: I've always loved coding. For a long time, I felt at a loss how to combine my love of coding and wanting to pursue coding as a career with my desire to try to make a positive social impact in the world. And I don't think back in 2017; I was really aware of the civic tech space. In perusing job descriptions nationwide, I stumbled across mRelief on Idealist, and it sounded like the perfect match. And I remember feeling like this is my dream job. I can't believe I get to do this work and code at the same time.

+ +

CHAD: [laughs] So you joined as a software developer at the time. Did you have aspirations to be CTO when you joined?

+ +

DIZE: No. [laughs] No, I remember looking at Genevieve, our former CTO and co-founder, and thinking I have no idea how she does her job and never thinking that I would find myself in this position. And it's been a massive learning experience and also a growth opportunity for me.

+ +

CHAD: What are some of the things that you needed to grow into or to learn in order to get to that point?

+ +

DIZE: I feel like most of the learning happened after. The biggest thing that I learned to prepare me to go into the CTO role was basically a very comprehensive understanding of our codebase. I think most of the skills or what I need to succeed in this role came after.

+ +

CHAD: Well, actually, let me ask a related but different question. CTO actually differs in different organizations. So, what does your role as CTO actually look like?

+ +

DIZE: It definitely does. And I think my role has even changed a bit in the year and a half or a year and three months that I've been in this role based on the growing team that we have at mRelief. But my day-to-day basically looks like working with our product team to plan for new features. I like to code, so I try to do some coding at least every day and also general oversight and, I guess, strategic thinking.

+ +

CHAD: One way in that description that stands out to me, you know, some other CTO might describe their role as very much not working on the code, very much not even really working with the team or product, and more focused on the executive level of the company or the needs of fundraising or something like that. So it sounds like you're very much still product-focused and oriented towards working on the product.

+ +

DIZE: Yeah, I think that's driven by a selfish desire to keep coding.

+ +

[laughter]

+ +

CHAD: You're talking to someone who is in the exact same spot. There are times where I feel guilty about that.

+ +

DIZE: Yeah. [laughs]

+ +

CHAD: Here's my justification, [laughter], and I'll be curious in terms of your justification. I've done this for 19 years now. And I'm pretty confident that I would have burned out a long time ago if I didn't spend time coding. It's part of what I find rejuvenating and what I love to do. It doesn't mean that I can always afford to work on something for four hours straight, but it's part of what has made me be able to enjoy this work for so long.

+ +

DIZE: Yeah, I completely relate to that. If I wasn't coding, I don't know how long I could sustain myself [laughs] with so much responsibility. How do you find that balance?

+ +

CHAD: Well, I think part of it is freeing yourself up to not feel guilty so being really clear with others. Like, if someone asks for something from me, being like, yep, totally, I can do that. I can get it done by this day and pretty aggressively planning out my work or time, blocking my calendar and making it clear when I'm going to be able to have that thing for them.

+ +

And if that timeline doesn't work, then they can tell me that, and I can adjust. But that goes a long way towards when I am having a coding session that lasts half a day or something like that; I cannot worry or feel guilty that someone's waiting on me for something or that it's not what I should be spending time on.

+ +

DIZE: Yeah, that makes a lot of sense.

+ +

CHAD: What about you? Have you found things that work for you?

+ +

DIZE: I have been trying different things. I've been doing a lot of YouTube deep dives on productivity blogs, just different ways of thinking about prioritizing work and making sure that things get done. But I really like your point about allowing yourself not to feel guilty. And I do like to remind myself that I don't want to take the fun out of my job. I want that for other folks on the team, and I also want that for myself.

+ +

CHAD: The other thing that is on my mind when I'm doing something is there's this stereotype of the CTO who codes and makes a mess of things that the other people have to clean up.

+ +

DIZE: [laughs] Oh no. I didn't know about that.

+ +

CHAD: You know what I'm talking about?

+ +

DIZE: No. [laughs]

+ +

CHAD: Oh, no, no? It's like, oh, the CTO made commits at 9:00 p.m. last night. I guess I have to...and the build is broken.

+ +

DIZE: Oh no.

+ +

CHAD: I guess I have to...[laughs] so, does that describe you or no? [laughs]

+ +

DIZE: Oh my gosh. I'm definitely seeing myself in that description a little bit. [laughs]

+ +

CHAD: Oh no. [laughs]

+ +

DIZE: Literally, I was up last night pushing code to production, but I think it's okay. [laughter] I mean, I hope that that's not me. [laughs]

+ +

CHAD: I try to avoid that because, you know, I want to feel like my work is useful and valued and not creating more work for other people.

+ +

DIZE: Yeah, definitely. I agree.

+ +

[laughter]

+ +

CHAD: Tell me more about the tech stack for mRelief.

+ +

DIZE: So we use React and Rails. We're hosted on Heroku. Yeah, very basic.

+ +

CHAD: I heard that you use some thoughtbot stuff, so I assumed that it was Rails.

+ +

DIZE: [laughs] Yes. Yeah.

+ +

CHAD: That's great to hear.

+ +

DIZE: Yeah, I was messing with Paperclip this morning, actually. [laughs]

+ +

CHAD: Oh, well, Paperclip is deprecated. I'm sorry to tell you. [laughs]

+ +

DIZE: I know. [laughter] I had to fork it this morning to make a change.

+ +

CHAD: I still stand by that decision. I think it's important as sort of a community contributor that we signal overall direction and coalesce behind what's built into Rails once it was there.

+ +

DIZE: Okay, that makes a lot of sense.

+ +

CHAD: But yeah, was Rails in use when you joined?

+ +

DIZE: Yeah, we're using the same stack.

+ +

CHAD: How much has it grown over time, the codebase?

+ +

DIZE: I don't really know.

+ +

CHAD: That's interesting that you don't know. [laughs]

+ +

DIZE: When you say grown, like, I guess how is that measured?

+ +

CHAD: Oh yeah. I mean, is it more complex now than it was when you joined?

+ +

DIZE: Yes, definitely. Yeah, we've added new products that had never existed, and the fact that we've expanded to more states and our screener is nationwide that's added a lot of complexity.

+ +

CHAD: So, do you have ways that you manage that complexity, either in the code or in the business?

+ +

DIZE: What would that look like? [laughter] How would you manage that complexity?

+ +

CHAD: Well, I think it's a little dependent on where the complexity is coming from. So, for example, the screener is nationwide, you said, and so does the screener change based on where you're located once you start to fill it out?

+ +

DIZE: Yes, yes. The first question we ask is zip code.

+ +

CHAD: And then how does all of that branching work in the state-specific logic work? Is it all one big jumble of if statements and code, or is it factored out in some way to help keep that as clean as possible? And if the answer is it's all one big jumble of if statements, that's totally fine. [laughs]

+ +

DIZE: I was actually going to say both. [laughs] Because I think because of the patterns that we were able to establish, and the eligibility logic between all states, there's definitely some if branching, but there are enough shared concepts that we can keep it all in one to two files that are not too long.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you mentioned the team has grown quite a bit. It seems like the development and design team is quite a bit bigger than two people now. How big is it?

+ +

DIZE: Well, the product team itself is eight people now, I think. And the team, the whole mRelief team, we just had two new folks start today, so I think we're at 20.

+ +

CHAD: What does your onboarding process for bringing new team members on look like from a technical perspective?

+ +

DIZE: So the first two weeks, folks are typically in a bunch of onboarding meetings just getting acquainted with the history of mRelief, our current processes, and stuff like that. But for our tech team, we like to jump in with them as soon as possible, get them set up obviously locally and have them contributing with some kind of low-hanging fruit tickets at first so that they have some code pushed up in the first week or two.

+ +

CHAD: Are you facilitating that through pairing with someone existing on the team, or are folks doing that independently?

+ +

DIZE: Depending on the complexity of the ticket, sometimes we pair. Mostly it's independent work.

+ +

CHAD: Some companies and some teams have the goal of like, oh, you know, first commit to production on your first day. Do you have anything like that either with the code or with the processes like benchmarks that you use of, like we really want this to happen but on the first day or in the first week?

+ +

DIZE: No, we don't have anything like that.

+ +

CHAD: At the size, you're at now, some companies start to break into sub-teams or squads or focus areas. Are you starting to do anything like that?

+ +

DIZE: I've thought about it here and there. But I think we all like sharing responsibility for all of the different products and getting our hands into all the different ways that we connect with users. So we haven't formalized anything like that.

+ +

CHAD: So that means you have one backlog of everything that's slated to be worked on.

+ +

DIZE: Yeah, that's right.

+ +

CHAD: Is that overwhelming sometimes?

+ +

DIZE: Yes. [laughter] Yeah. I don't know about your experience with backlogs, but I assume that they're always overwhelming.

+ +

CHAD: Yeah, that's a really good way of putting it. I think that not having it requires very aggressive management that a lot of teams are not willing to do. And then when you have a team of 10 or 12 people all working across multiple apps or all on the same app doing a lot of different stuff, that's overwhelming on the other side of just the amount of stuff that's happening every day can sometimes be overwhelming.

+ +

And people start to sort of step on each other. Oh, you know, we've got these two pull requests, and every time I go to make a change, something has merged into main that now my branch is behind. And if you're waiting for CI to pass and your CI is too long, something new has been merged in by the time your CI run finishes. Those are some of the challenges that I hear people facing.

+ +

DIZE: Interesting. What are those aggressive management things that you were speaking of to avoid backlogs?

+ +

CHAD: I think it basically means saying no to things. So I think when we talk about a backlog being overwhelming, one of the worst things that comes to mind mostly, and let me know if this is part of the problem you're feeling or not, but it's really long. And somewhere in there, there's like the bug that was created two years ago by someone that has never been addressed, or maybe it has been, and the ticket was never moved forward. And so you end up with 500-600 things and a long list that becomes then very difficult to ever really prioritize because it's not possible to prioritize that many issues. Does that resonate with you at all?

+ +

DIZE: That does resonate. I was scrolling through our backlog today, and I was like, when is this going to end? [laughter] I guess I hope that was normal. [laughs]

+ +

CHAD: It is normal, or I should say I think it's common.

+ +

DIZE: Common, okay. [laughs]

+ +

CHAD: I think it is a problem a lot of companies face. And like I was saying, I think one of the only solutions to that is basically, well, so either someone or a team that is very comfortable saying, "We don't need a ticket for that because we're just not going to get to it," or being able to delete something that you've not...or move it out that this was created two years ago. It's just not doing us any value to have it hanging around anymore.

+ +

DIZE: Yeah, that makes a lot of sense. That's helpful.

+ +

CHAD: And some companies do it by policy basically. They have a philosophy or a policy that says, "This needs to be a thing that comes up." They have a product manager who's paying attention to what's going on and is like, okay, this is the third time that this has come up. Now we'll create a ticket for it because we're actually going to do it. And you only create tickets for things that are for the next four weeks, for the next six weeks, and that you use something else other than tickets.

+ +

So one thing that I've found really works well for me, and I like this idea of the difference between a discussion or an idea and the work to be done is; for example, we often use Trello for project management and a Kanban board of the work that's actually happening in the backlog. But anything that's not a concrete item that we're going to actually prioritize and do is better off in a messaging system like Basecamp or another tool where it's more of like a discussion about what we might do, and we post designs and those kinds of things.

+ +

And it's not until it's actually okay; we plan to do this three weeks from now that it gets a ticket created. And if you're really aggressive about that, that works pretty well. But you really need to stay on top of it. And if someone creates a ticket for something, and then it turns out that you're not going to do it in a reasonable timeframe, it moves out and becomes a discussion.

+ +

DIZE: Oh, I really like that. That's a really great process. I feel like I'm using this as a [laughter] mentorship session. So thank you for that guidance.

+ +

CHAD: My pleasure. It's funny that we've hit upon this because I think it is a common problem. And then the other thing is like, okay, great, Chad, that's wonderful. I have 600 things in the backlog; how can you...I don't have a great answer for that [laughs] other than basically one of the things that I've done and seen other teams do is...so what project management tool are you using now?

+ +

DIZE: We're using Asana.

+ +

CHAD: Asana. It's basically creating another project and taking everything that's not going to be done in the next two or three weeks and moving it to another project and then saying, okay, what our process from now is going to be is we have a biweekly planning meeting, or we have a weekly planning session. And what we're doing as part of that is taking things from the project where we moved everything to, and we're only moving the things over that we're actually prioritizing and going to do in the next X number of weeks.

+ +

DIZE: Cool. That makes a lot of sense. Thank you.

+ +

CHAD: I hope that's helpful. [laughs]

+ +

DIZE: That is helpful. No, yeah, thank you so much. I'm still new, and I have so much to learn. [laughs] So this has been really, really informative.

+ +

CHAD: So actually, this leads me to something I was wondering about based on this conversation and just in general, is as CTO, who are you actually leading? And is there a separate product manager or a team that actually doesn't report to you?

+ +

DIZE: No. I basically lead the product team. We do have a product designer who takes on more of the management of the design part of the product team, but I don't think we've grown big enough to silo like that yet.

+ +

CHAD: And I don't recommend it. I think it's great when you have an integrated design and development team working together. At a certain size, yeah, you need to create divisions, and you need to, you know, that kind of thing. But it's better when design and development work really closely together to create something great, in my opinion.

+ +

DIZE: Yeah. I've also found that to be effective.

+ +

CHAD: You have people on your team with different levels of experience. How, as a leader, do you attempt to...I think you're a great example of someone who joined at the level of software developer and grew in their career to be CTO. Like, how do you help others do that?

+ +

DIZE: I think the biggest part of that is assessing how they see their career growing. I don't know if everybody wants to be a CTO, wants to be a manager, or just wants to continue to be an individual contributor at a higher level. So just trying to work with them to figure that out for themselves and then providing opportunities to gain that experience like leading a project, or taking on management responsibilities, providing more ownership, and leaving them to their own devices as much as they are comfortable.

+ +

CHAD: The fact that mRelief is a non-profit, how much does that factor into your day-to-day or your ability to build a team and hire or anything like that? Is that something that you feel on a regular basis?

+ +

DIZE: The biggest way that I feel it is hiring. I don't know if you're also experiencing this, but it's like, it's been a very competitive market, especially recently. And I know it's always been, but recently, I feel like it's turned up a lot. Trying to align compensation to the market has been a particular challenge.

+ +

CHAD: Where does the funding for mRelief come from?

+ +

DIZE: So we're funded in a couple of different ways, a couple of different streams. We are funded through grants, individual donations, and government contracts.

+ +

CHAD: Hiring, especially in a world where you're competing to hire against companies that don't need to be sustainable or profitable, like, they've gotten millions of dollars, and they can just spend it, that is tough. And thoughtbot has existed in that environment forever basically because we're a consulting company which started from scratch without any investors or anything like that.

+ +

And so we focused on being the kind of place that people want to work, having good benefits. We're not going to be able to compete against companies on compensation directly. And so we focus more on paying people fairly and what we can afford but being the kind of place that people actually want to work.

+ +

DIZE: What have you found to be the most, I guess, successful exploration of that?

+ +

CHAD: Well, it's evolved over time. There were a lot of things that we could put out there in terms of what it was like to work at thoughtbot versus what it was like to work at the typical startup company that made us special, and it wasn't anything radical. It was just like, you're going to work sustainably, and we're not going to approach deadlines in the same way. You're going to have agency over your work.

+ +

You're going to work with a really great, smart team of people who are all sort of like...the analogy I use is like a professional sports team. They make it look easy. And it's not super stressful all the time because you don't need stress in order to do great things; you need people who are given the space to do great work.

+ +

And I'll be honest; actually, we're one of the best places you can work if you want to do Rails work. Now, a lot of that stuff has evolved. I think startup culture is different than it was 15 years ago. And there are more companies where you can work in Rails that aren't as bad as they quite honestly used to be. We used to be able to point to companies and be like, you don't want to work there. And there are less companies that we can do that to now.

+ +

DIZE: Oh wow. Okay, so folks have started to kind of simmer down on expectations and just the hassle of startup culture?

+ +

CHAD: I think so. And then you have examples if you want to stay working in Ruby, then you have companies like GitHub and that sort of thing where they hire remotely. They've addressed a lot of the problems that they had in their culture. No company is perfect, but I think they've made it seemingly from the outside.

+ +

And from the number of thoughtbot people that we've had join GitHub, they seem to have addressed some of those issues. We've needed to, in some ways, double down on some of them, like in terms of really recognizing we can have a culture where you can actually have an impact on who we are and what we do in a way that you can't in a big company.

+ +

DIZE: Oh, yeah, yeah. That resonates for sure.

+ +

CHAD: Is that part of what you've done? Obviously, you have a mission-driven impact-oriented thing which I think probably draws people who want to do that, right?

+ +

DIZE: Yeah. And I think what we can offer that feels more unique is shared leadership. So like you said, having a lot of sway and impact on the way that the organization is run day-to-day because we really believe in distributing those responsibilities.

+ +

CHAD: What's next for you and the mRelief team?

+ +

DIZE: Well, we have some goals this year that mean expanding to a couple of more states. So we have our simplified application and also our assistance platform and about 12 partners, ten states, or something like that. And we want to expand to eight more states by June of 2023. So that's going to be a lot of our focus this next year.

+ +

CHAD: So you talked about how hiring has been a challenge. So I presume that means you're trying to hire some new people to be able to accomplish these goals.

+ +

DIZE: [laughs] Yes. Right now, we're looking for a full-stack dev experienced in React and Rails at least a year or two to help us with that expansion.

+ +

CHAD: Oh, that's another thing that has helped us hire is having an apprentice program where the majority...we don't take people who are brand new and teach them. But it's sort of like one level up, taking intermediate people who wouldn't be able to bill at the level us and our clients need them to and getting them to that level in a three to a six-month timeframe where we don't bill their time. They're paired with mentors. They work one on one with a mentor, and it's a rotation program. So they rotate the mentors. That has been really helpful for us.

+ +

DIZE: That's amazing. I would love to do something like that, and I would love to also even train folks from the ground up. I feel like that's like a pipe dream just based on capacity. But I think there are so many folks whose voices don't get to be in product development, and I'd love to foster that.

+ +

CHAD: Do you think you have the space to be able to do that, or do you think that what you're saying about it's hard for your team to have the bandwidth to train those folks?

+ +

DIZE: I think it's a problem of bandwidth, at least right now. Hopefully, it'll change.

+ +

CHAD: That's one of the reasons why we don't work with people in the beginning stages but rather someone who can be an effective pair for a Rails developer. That's a good point because they can learn a lot, but they're an effective pair. They're not slowing anybody down, and we can teach them primarily through pairing. Whereas if someone doesn't even know HTML, that is an issue that we haven't been able to...we can train, but it's hard to balance that and have enough bandwidth to teach people that.

+ +

DIZE: Yeah, that's brilliant. That makes a lot of sense. What kind of credentials do those folks usually have? Are they out of a bootcamp or self-taught?

+ +

CHAD: Some of them are out of bootcamp, and we could take more out of bootcamp. Out of bootcamp is actually a very fine stage. The problem is that there just aren't a lot of opportunities like this. And so, for example, for our last quarter's apprenticeship, we had four apprentice positions, two designers and two developers. We got 1,033 applications.

+ +

DIZE: Oh my God. Oh my God. Wow.

+ +

CHAD: And we screen all of them, and we respond to everybody but as a result of that, what it means is the more experienced people are likely to take up and get the spot over someone with no experience at all, which I don't love, but it's difficult to not have that happen.

+ +

DIZE: Got it. Very, very competitive. Wow.

+ +

CHAD: Right. Right. Our people operations person likes to point out that it's more competitive than Harvard.

+ +

DIZE: Oh my God. [laughs] What does that make the acceptance rate?

+ +

CHAD: I don't know. [laughs] Four out of 1033; I don't know.

+ +

DIZE: Dang. [laughs]

+ +

CHAD: It's low. In order to balance that a little bit and to strike a balance and find the people who I like to call the top candidates, like, they're not the most qualified, but they're the top. And I'm still working on this term but basically focusing on things that aren't just what they can do for code or their coding experience.

+ +

Like, the things that are important for consulting are like, do you have experience talking with people? Have you been a teacher? Have you been in retail? Even being in retail is a little bit of a plus over someone else necessarily who's just been a coder forever.

+ +

DIZE: Yeah, yeah, some kind of diverse working background.

+ +

CHAD: And at least I think it's really important that someone with a really strong background that lends themselves to being a good consultant is able to get an interview even if they don't have a lot of actual work experience. I think that that's really important, at least giving them the shot even if, after interviewing them, we think that we need to move forward this other candidate.

+ +

I think it's really important that the initial screening not completely screen out people just based on, for example, years of experience. We don't look at degrees at all. That's not even a factor in normal thoughtbot hiring. It's not something that we look at.

+ +

DIZE: Oh, good. That is such a cool program. I wish more places did that. [laughs]

+ +

CHAD: Oh, me too. It would make our job easier because we wouldn't need to reject so many people. We could refer them to these other places.

+ +

DIZE: [laughs] Oh my gosh. Yeah.

+ +

CHAD: We're actually changing the program for 2022 because we know that there are tons of people, not a lot of opportunity. It used to be that we would do interviews, and then we'd be forced to say, "We're not taking you now, but we are moving forward in the process with these ten people and whittling it down to the 2."

+ +

What we're doing now is we actually continue the interview process with everyone who passes the things that we're looking for. So we can get to the end of the process, and even if we only have two slots, we've identified the five people who would have been able to do it. And then what we do is we say, "We think you're a great fit. There are just not enough slots right now. So can we reconsider you or schedule you for a future slot?" That's what we're trying to do.

+ +

DIZE: Interesting. Has it been helpful?

+ +

CHAD: We're only in the second quarter of doing that. So we're still a little early with that change. But I can already anticipate the problem, which is there are too many people we would take.

+ +

DIZE: Ooh, yeah. [laughs]

+ +

CHAD: And so I carried forward 15 People from the last session, from the last quarter. And that 15 is more than...[laughs] and unless we're willing to then turn off applications so new people can't apply, we still get, you know, so the last quarter was 970 applications about.

+ +

DIZE: Oh wow.

+ +

CHAD: This quarter was 1,033. So one of the factors that has really helped with our hiring is we decided to go fully remote at the beginning of 2021, and that has really helped us expand to being able to hire a little bit more competitively by not competing against everyone in the places where we had offices previously.

+ +

DIZE: That makes sense.

+ +

CHAD: But I noticed that you're still a Chicago-based team, right?

+ +

DIZE: We're still Chicago-based, but we're remote now, fully remote. Our headquarters are here. We do have a lot of team members here. We also have folks throughout the States.

+ +

CHAD: On the development team too?

+ +

DIZE: Yes, on the development team.

+ +

CHAD: Oh, okay, great. So when did that...did that change with the pandemic, or did you have it before?

+ +

DIZE: It changed with the pandemic. So before, we weren't remote at all; we were always in person.

+ +

CHAD: Has that been a big change, or an easy change, or a hard change for your team?

+ +

DIZE: I think a pretty easy change. I think we're all...well, I don't want to speak for everybody, but it seems like it went quite smoothly. We do offer a monthly stipend for Deskpass in case anyone wants a physical workspace and may sometimes meet up to co-work for a sense of community and camaraderie. But other than that, folks seem to really enjoy it.

+ +

CHAD: Yeah, I think for us, it was also not a difficult transition when it came down to a lot of the work and that kind of thing. I think the biggest challenge for us has been we're bigger, and so there were people...and we very much we are local teams working with local clients. And so, there was a segment of the thoughtbot team that never opted in to a fully remote company.

+ +

And so they've understood the transition, but they didn't necessarily choose it for themselves. And so they have their choice of...like you said, it's a competitive market. It is important for teams to be clear about who they are and how they work. And if someone at the end of that says, "You know what? I understand, and that's not for me," I think that's okay.

+ +

DIZE: Yeah, definitely, like self-selection. [laughs]

+ +

CHAD: Yeah. Well, thank you so much for stopping by and talking with me. I really appreciate it.

+ +

DIZE: Yeah, thank you for having me. It was so lovely to chat. And thank you for all the great advice.

+ +

CHAD: I wish you and the mRelief team all the best and keep in touch.

+ +

DIZE: Thank you, you too.

+ +

CHAD: Oh, wait, if people want to find out more, we got to say the website. [laughs] And if they want to get in touch with you, where are the best places for them to do that?

+ +

DIZE: So our website is mRelief, so M as in mom, relief as in sigh of relief, mrelief.com. We're on some socials. Our name differs [laughs] based on the social, but we're on Twitter and, Instagram, TikTok soon. [laughs]

+ +

CHAD: Oh, wow.

+ +

DIZE: [laughs] Yeah, that's it.

+ +

CHAD: And that's where people can find the job posting as well?

+ +

DIZE: Yeah, on our website.

+ +

CHAD: Awesome. Well, thank you again.

+ +

DIZE: Yeah, thank you.

+ +

CHAD: You can subscribe to the show and find notes for this episode along with an entire transcript of the episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Dize Hacioglu.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9s3g4-OE + + ]]> + + Chad Pytel + Dize Hacioglu + + + 419: The GK Fund with Michael Benezra + https://podcast.thoughtbot.com/419 + a4a8e079-8de9-4624-8228-7112a074a469 + Thu, 21 Apr 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Michael Benezra is the Executive Director and Co-Founder of the GK Fund: a nonprofit social impact fund to support BIPOC-owned companies in Greater Boston. Michael also serves as the COO of Colette Phillips Communications, helping to lead the [All Inclusive Boston](https://www.bostonusa.com/allinclusivebos/) tourism campaign, among other projects. + +Chad talks with Michael about being a BIPOC ally, disparities amongst the VC world, and how the GK Fund looks for the same things in BIPOC-owned companies that they look for in other companies because the innovation is there; it's just that the opportunity isn't. + 26:22 + no + + + Michael Benezra is the Executive Director and Co-Founder of the GK Fund: a nonprofit social impact fund to support BIPOC-owned companies in Greater Boston. Michael also serves as the COO of Colette Phillips Communications, helping to lead the All Inclusive Boston (https://www.bostonusa.com/allinclusivebos/) tourism campaign, among other projects. +Chad talks with Michael about being a BIPOC ally, disparities amongst the VC world, and how the GK Fund looks for the same things in BIPOC-owned companies that they look for in other companies because the innovation is there; it's just that the opportunity isn't. +The GK Fund (https://www.thegkfund.org/) +Follow The GK Fund on Twitter (https://twitter.com/GK_Fund) or LinkedIn (https://www.linkedin.com/company/thegkfund/). +Colette Phillips Communications (https://www.cpcglobal.com/) +All Inclusive Boston (https://www.bostonusa.com/allinclusivebos/) +Black Owned Bos. (https://www.blackownedbos.com/) +Follow Michael on Twitter (https://twitter.com/MichaelBenezra) or LinkedIn (https://www.linkedin.com/in/michaelbenezra/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Michael Benezra, Executive Director and Co-founder of the GK Fund, a non-profit social impact fund to support BIPOC-owned companies in Greater Boston. Michael is also the COO of Colette Phillips Communications, helping to lead the All Inclusive Boston Tourism Campaign, among other projects. Michael, thank you for joining me. +MICHAEL: Thanks for having me. +CHAD: I'm curious about the GK Fund. When did you start the Fund? +MICHAEL: So, at the time, I was working for the Israeli Foreign Ministry, and I was working with venture capital firms, private equity firms. And I was representing over 200 Israeli companies in New England, most of them startups. And my wife is Black; my family is Black. I've been close to that community for a long time. And especially in the venture capital world, I started to see some real disparities amongst other disparities in general everyday life, but it was particularly bad in the VC world. +And so Colette being a mentor and a friend of mine, Colette Phillips, I approached her, and I said, "Hey, what do you think about starting this fund, this non-profit fund?" And her and Andre Porter, who is our other co-founder who used to be the head of the state's business development agency in Massachusetts, we all decided to band together and start this non-profit. Now, we started the non-profit in December of 2019, so the pandemic hit right as we were creating this organization. And we had a decision to make, do we put this on hold, or do we move forward and accelerate? And we decided to just move forward. +CHAD: Well, I'm glad you did. I'm glad you made that decision. Hopefully, you feel the same way. [laughs] +MICHAEL: Yeah, I do. +CHAD: You're absolutely right. There's a big need here. And I actually have had over the last two months or so a few different guests that are creating VC funds or funds of certain kind that address underrepresented communities, Black, another one was veterans. And there's such a big need. How did you decide what you were going to focus on or focus down into so, for example, focusing on Boston? +MICHAEL: For Boston specifically, it had to do mostly with proximity. So I went to Harvard here for grad school. I worked for Governor Patrick. And so, for me, it was natural to stay local, especially during COVID. In my experience, there were a lot of BIPOC, particularly Black-owned startups, that were on paper akin to a lot of other startups in the Israeli world, which were very developed or also in the United States. +I'll give you an example; there was a company that I worked with that had a $100 million valuation but had no products, no physical products. They had no revenue, but they had innovation. Now, you and I being very honest, do you think a Black-owned company could get away with that? +CHAD: Yeah, no. +MICHAEL: There is no way. I knew that; the other entrepreneurs that I've talked to know that. That is a terrible double standard that needs to be fixed. So we look for the same things in BIPOC companies that we look for in other companies because, for the most part, the innovation is there; it's just that the opportunity isn't. +CHAD: Yeah. To dig into that a little bit more, I think one might say, well, if they had a founding team that had a proven track record, then maybe. And that's where you get to the fact that it's systemic, too, because if the headwinds are there where they can never get that experience, to begin with, they never get that opportunity, to begin with, then they're not going to have a founding team that has a track record that will be invested in based on just the team. +MICHAEL: That is 100% accurate, but it's actually even worse. So we do not ask our founders in the application process for their educational background. But all six of the companies that got grants from us last November they all have their bachelor's, four out of six have masters or higher. And so the cream definitely rose to the top. We had a store owner she owns an online boutique who got an engineering degree from Purdue. And we also have an entrepreneur who was an attorney at State Street, a corporate attorney, and now he's created this startup. And so, in some cases, like in most other areas, these individuals are overqualified. +CHAD: So, what is the funding model for GK on both sides of the equation? Where is the money coming from, and then how are you funding the companies? +MICHAEL: So we raise money organically like any other non-profit does. So we apply for grants. We take corporate donations. We take individual contributions online. Most of our money so far has come in through corporate contributions. So PNC Bank has been with us since the beginning. They made a very large commitment to supporting racial equity, and they've really stuck to it. The Bar Foundation has been exceptional. +And then we've also had a group of individual donors who were actually White women who have started their own non-profit now, and they've also banded together to give us money that we need to re-grant to the companies. We have over 100,000 from the State of Massachusetts to operate a grant program. So money is coming through a number of different avenues. +We've issued six micro-grants so far at $10,000 each. We did that in November. We plan to do ten more in the next month. I said in the Boston Business Journal article you can give us money, but you can't park it with us like you could with a donor-advised fund and watch it accumulate interest for 15 years. We're going to take it, and we're going to give it to the people that need it the most. +CHAD: And are they grants then? You're using the word grants, so I assume that they are. So you're not doing this in exchange for equity in the companies? +MICHAEL: No, no equity in the companies, no convertible notes, just a straight capital grant directly to the company. So I send a message over to our fiscal sponsors at Philanthropy Massachusetts. They send the check directly over to the company. After that, we have the company fill out a survey letting us know what they plan to use it for, but we're not overly prescriptive. And that's actually the way that philanthropy is heading right now is, putting fewer restrictions and barriers in the way. And that's another thing I'll talk about as well is making it easier for companies to gain access. +CHAD: So, did you ever consider more of a traditional VC fund model with this? +MICHAEL: Yeah, originally, I did. Before the pandemic, actually, I did. So the original purpose or impetus of the fund was to take companies that were coming out of accelerator programs that were underfunded. You have some great accelerators, but you have companies leaving with a business plan and $2,000. In some cases, there are companies that have been through three accelerator programs. They're not getting as much out of it as they should. I wanted us to intervene, find the companies that have the most potential, and make investments. But after COVID hit, it was a crisis. And so, we needed to shift our focus to philanthropy. +CHAD: The nice thing about that is then you can do those grants with basically no strings attached for the companies. Whereas if you were taking money from people who expect to get a return on that investment, you wouldn't be able to do that. +MICHAEL: That's exactly right. There are organizations out there that say that they're making an impact when in reality they're just making, you know, loans which is not a not a bad thing. But they're issuing loans, or they're taking equity in the companies, that's fine, but it's not what we're doing. +CHAD: What are your plans for, like, upcoming? Are you going to be continuing with micro-grants, or do you have bigger plans? +MICHAEL: We have bigger plans. So I can't say too much right now because we have an announcement coming up. But I will say issues like legal services have come up. There's a constant need for attorneys for any company, whether it's contracts, or locking down real estate, or copyright and trademark, or IP. We are working with a very large prestigious law firm that's really making a generous commitment to our companies. And this would involve us even adding free legal services for an entire year to our grantees. So that's one thing that we're planning to do. +And then the other is, and this another function of the fund, is we speak with organizations like Lyft who's donated like $5,000 in ride credits that we're giving to our grantees or Wix, which has given us like 75% off of websites. We work with partners who can also give us other services that we can provide to these companies to try to get them closer to where there's a gap. +Giving them capital is not enough. The disparities are too significant. We also partnered with Berkshire Bank, so I can make direct referrals for loans if they need them. But the idea is to really narrow that gap and give these companies the same opportunities that their White counterparts have. +CHAD: That's great. So you, as someone who's White doing this work, how do you find yourself in the community? How do you be an effective ally and advocate? +MICHAEL: For me personally, my connection personally through my wife and also through my family and my boss. Colette is a pioneer. She's a Black woman in Boston who moved here not knowing anybody. And 30 years later, she's on The Power of 50 and 100 influential lists, but she did that through hard work. And she's worked much harder, I think, than she would have had to if she weren't a woman from Antigua who came here on her own. +But ultimately, as an ally, it's my role; it's our role to step in between situations where there's inequity. So if there is a company, one of our companies, for instance, who's having a problem locking down real estate, (I think I use this in the article.), and they're saying, "Well, the real estate agent is telling us they can eliminate our lease at any time they prefer which I know is basically legal." I'll call them up and say, "Look, I'm with the fund. We're backing this company; we support them. What's the situation?" And unfortunately, most of the time, the outcome actually changes. +So it's a matter of almost you got to be proactive, and you got to be intentional. You have to use your privilege in the best way that you can. So I think that's how you do it. And then, when it's time to shed a light on these companies, you take a step back, so it's not my role to go out there and promote myself. If anyone asks me, I'm always promoting the companies. So the best thing we can do is be advocates. You can be out front, but at the end of the day, it's about uplifting them, these companies in this case. +CHAD: Yeah, that's great. Speaking of that, I was going to ask you, what are some of the companies that you have given the micro-grants to, and do you know how they use them? +MICHAEL: Yeah, so we gave our grants to six companies. One is called MustWatch, and MustWatch is founded by Che, and Che, his family, is from Haiti. They are an app. You can actually find them on the App Store. But what they do is they allow you to log in, select which movies and television shows that you watch, and share them with your friends. And it sounds like a very simple concept, but there is actually nothing on the market that allows you to do this. +And the idea is that you're collecting data while you're doing this as MustWatch. So at the end of the day, if you have a sample of like 20,000 users on the platform, you gain a lot of valuable insight and data. And that data can be useful for Nielsen or the television networks or movie production studios. I encourage people to sign up for MustWatch because if you spend as much time as I do looking for good movies, you're probably miserable. +CHAD: [laughs] +MICHAEL: [laughs] I spend so much time doing that. We also have a few online retailers. So we have B. Royal Boutique and So Zen Spa, both of them have doubled their revenue during COVID. They originally had stores. They pivoted during COVID, went online, and really were excellent when it comes to branding and marketing on social media and on other digital platforms. So they've been very successful. +We have a company called Black Owned Bos., which is pretty well known here in Boston. They basically focus on organizing and running pop-up shops. And Jae'da, who's the head of the company, is just, I mean, she's a business mastermind. She's brilliant, always finding new ways to innovate. And then we have Our Village, which is focused on community development and housing. And finally, sySTEMic flow, which is a company that helps school districts, educators support Black women in STEM and STEAM fields. So we looked for companies that could pivot, basically. +CHAD: And you mean in the face of the pandemic. +MICHAEL: In the face of the pandemic, we looked for companies that had success and had a plan and also knew their audience. The main things that we look for…and I should say this too; our application process takes an average of seven minutes. And the way that I did that was I evaluated over 20 accelerator applications. I did a comparative analysis and identified the questions that were either irrelevant or unhelpful for us. And that gave us a very short application for our companies but one that's really efficient. +And basically, what we're looking for is companies that have a good business model, have a very specific customer base and target market, and have a strong founder, and also has been undersupported. There are companies that we've identified for our next cohort that by this point in their development would have been venture funded in my experience, at least, had they not been people of color. +Mid-Roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: What has been the most surprising use of one of the grants? +MICHAEL: So B. Royal used the grant money to lock down a store in Assembly Square in Somerville. We kind of anticipated they might do that. So Zen Spa they improved their website. MustWatch actually really surprised us. So they went out and got a valuation of their company and then basically worked with a crowdfunding platform called Netcapital to raise more capital. They had a very specific plan, and they had disclosed that plan to us. I just didn't anticipate they would act so quickly on it. And based on the fact that we had given them a grant and all this mentoring and support, their valuation actually went up. +CHAD: That's a really smart use of the funds to propel that into a larger fundraise. That's really smart. +MICHAEL: I agree. +CHAD: So you do this in addition to a day job. [laughs] +MICHAEL: I mean, they're both day jobs; it's just, yeah. +CHAD: So you mentioned Colette Phillips, the person, [laughs] how about Colette Phillips Communications? +So The All Inclusive Campaign it really is historic. The genesis of the campaign is that back in 2020, Colette and I applied for an RFP from the City of Boston; it was for a tourism recovery campaign. All of the major cities in the country got this grant money through regional tourism agencies, you know, like they're a special interest niche. And they went to the Feds, and they're like, "Look, we're suffering, travel is suffering, we need a grant," so all these grants went out. +The City of Boston actually said, "Look, we want to focus on diverse tourism." So that was perfect for us. We applied, we got the grant. And we brought on Proverb, which is an incredible digital marketing agency and creative design agency, and the Greater Boston Convention & Visitors Bureau. It was the largest contract ever to go to a minority-owned company by the City of Boston, ever, and it was about 1.5 million. +CHAD: Which in and of itself for what the City of Boston probably spends on things [laughs] is a little ridiculous that that's the biggest one, but … get beyond that, I guess. +MICHAEL: It's insane. It's very upsetting. And it was a long time overdue. In this case, that contract or that RFP was really only supposed to last like one quarter. So all these regional tourism agencies they get their influx of money, a million dollars or a few 100,000. And then from there, they do the campaign, they move on. We are now three mayor's into this. We are four million dollars into this. +We submitted the campaign to the city 60 days after they contracted with us; 84% of the contractors on the project are minority-owned companies. And in that 60 days before delivering the campaign, we actually never met in person. So we did this whole campaign virtually from the start. We came in under budget. We came in ahead of time. This is what happens sometimes when you let minority-owned companies take the lead. +CHAD: Yeah, that's great. How do you do a campaign like this? I mean, this is why they came to you, the experts, but I think it's important that this message seem authentic and not pandering. +MICHAEL: Yeah, Colette is a visionary. She's been talking about diversity and inclusion for like 20 years. There's an article that came out, I think, in 1992 where she was talking about the importance of diversity in the business community. And now it's like microfilm; you can't even find it digitally online. +CHAD: [laughs] +MICHAEL: She's years ahead of her time. And she's constantly innovating, and All Inclusive was her idea, and she branded it. I think it was a long time coming, basically. This is a culmination of a message and campaign that she's been running her whole life. +CHAD: Yeah, I think that that's very powerful. And I think it comes across in the campaign. It seems authentic. I think it would be easy for it to not seem that way. And so yeah, it comes from that place of this was already a thing. It was already brewing. It wasn't just -- +MICHAEL: Do you want to hear a story? +CHAD: Yeah, I'd love it. +MICHAEL: So, most of the media coverage for this campaign was exceptionally positive. There are a few reasons for that. We included all small, locally-owned businesses in the campaign. So you won't find celebrities, no athletes, or anything like that; we may do that later. We also invested...we took 200,000 of the contract, which this was not even supposed to be in there. We actually did ad buys with 19 different local newspapers. In some cases, these newspapers would have actually closed down if we had not done that, and that was just a byproduct of something we felt was important. +But amidst all of that, she got invited to do an interview on Bloomberg on the local Bloomberg station. She's on the phone, and some guy who was on the other line, and I won't go into it too much, said, "You know, as a White man, I'm really offended. I don't feel represented in this campaign." [laughs] And she's like, "I've had enough of this," hangs up the phone. [laughs] +And this is another part of allyship I think is...naturally, you know, I said, "Look, I'm taking care of this." I wrote a letter to Bloomberg. I said, "This is unacceptable. You need to take him to task." I don't know if he still works there anymore. But that's kind of the role. You have a Black woman who's a pioneer. She just released a campaign. The first thing you should be saying to her is "Congratulations," instead of saying that, all you can tell her is about how being a White man is like, I don't know, a disadvantage? Which is crazy. There are tons of White people in the campaign. I'm White; I'm in the campaign. +CHAD: It's so foolish. I don't even want to have to explain it, but the campaign is literally called All Inclusive. +MICHAEL: [laughs] Exactly, exactly. It covers everybody, I mean, literally. And it's like, I don't know what you want from us. +CHAD: Yeah. And it's not even...like you go to the site it talks about here's what you can do with families. Here's what you can do with kids, kid-friendly activities. +MICHAEL: This campaign was also research-based. So we spent 100,000 on research with this incredible company called Heart + Mind. They did a lot of research, and they did a lot of surveying. And the words that came back when describing Boston were unwelcoming, masculine; I think Tom Brady, Ben Affleck, crime, you know, just this kind of machismo unwelcoming environment. And it kind of confirmed some of the assumptions we had, but it was really surprising to see it in the data. +So we said, "All right, this is what we're working with. We have to come up with a narrative that counters that because Boston is a majority-minority city, 23 neighborhoods, 60% of the population speaks two languages or more. That ethos is really not accurate. So hopefully, we're doing a good job. +CHAD: So if folks want to help, we already said GK Fund is a non-profit. It's coming up to tax season [laughs], so at the very least, even if you don't...hopefully, you care about the cause, but if you just want that tax write-off, I suppose that's another reason to donate. +MICHAEL: Absolutely. +CHAD: So where can folks do that if they want to learn more and donate? +MICHAEL: Visit www.thegkfund.org. +CHAD: And are you looking for help in other ways beyond monetary? How can people get involved? +MICHAEL: Absolutely. So we're looking for mentors so individuals who feel like they have experience or skills to lend to these companies, and we'll try to deploy these individuals in the best way possible. Obviously, we're looking for partnerships. So if you have a company that you feel has something to contribute or is willing to make a contribution, not monetarily but either with your products or with a discount, we also want to give that benefit to the companies as well. And there are a number of different ways. +CHAD: That's great. And if folks want to follow along with you or get in touch directly with you, how can they do that? +MICHAEL: You can feel free to follow me on Twitter. It's just @MichaelBenezra, all one word on Twitter. I got a lot of positive messages after the Boston Business Journal article came out and in LinkedIn as well. +CHAD: Great. And you can subscribe to the show and find notes and a full transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Michael, thanks so much for joining me. I really appreciate it. +MICHAEL: Yeah, thank you for having me. +CHAD: And thank you for listening. See you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Michael Benezra. + + + Michael Benezra is the Executive Director and Co-Founder of the GK Fund: a nonprofit social impact fund to support BIPOC-owned companies in Greater Boston. Michael also serves as the COO of Colette Phillips Communications, helping to lead the All Inclusive Boston tourism campaign, among other projects.

+ +

Chad talks with Michael about being a BIPOC ally, disparities amongst the VC world, and how the GK Fund looks for the same things in BIPOC-owned companies that they look for in other companies because the innovation is there; it's just that the opportunity isn't.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Michael Benezra, Executive Director and Co-founder of the GK Fund, a non-profit social impact fund to support BIPOC-owned companies in Greater Boston. Michael is also the COO of Colette Phillips Communications, helping to lead the All Inclusive Boston Tourism Campaign, among other projects. Michael, thank you for joining me.

+ +

MICHAEL: Thanks for having me.

+ +

CHAD: I'm curious about the GK Fund. When did you start the Fund?

+ +

MICHAEL: So, at the time, I was working for the Israeli Foreign Ministry, and I was working with venture capital firms, private equity firms. And I was representing over 200 Israeli companies in New England, most of them startups. And my wife is Black; my family is Black. I've been close to that community for a long time. And especially in the venture capital world, I started to see some real disparities amongst other disparities in general everyday life, but it was particularly bad in the VC world.

+ +

And so Colette being a mentor and a friend of mine, Colette Phillips, I approached her, and I said, "Hey, what do you think about starting this fund, this non-profit fund?" And her and Andre Porter, who is our other co-founder who used to be the head of the state's business development agency in Massachusetts, we all decided to band together and start this non-profit. Now, we started the non-profit in December of 2019, so the pandemic hit right as we were creating this organization. And we had a decision to make, do we put this on hold, or do we move forward and accelerate? And we decided to just move forward.

+ +

CHAD: Well, I'm glad you did. I'm glad you made that decision. Hopefully, you feel the same way. [laughs]

+ +

MICHAEL: Yeah, I do.

+ +

CHAD: You're absolutely right. There's a big need here. And I actually have had over the last two months or so a few different guests that are creating VC funds or funds of certain kind that address underrepresented communities, Black, another one was veterans. And there's such a big need. How did you decide what you were going to focus on or focus down into so, for example, focusing on Boston?

+ +

MICHAEL: For Boston specifically, it had to do mostly with proximity. So I went to Harvard here for grad school. I worked for Governor Patrick. And so, for me, it was natural to stay local, especially during COVID. In my experience, there were a lot of BIPOC, particularly Black-owned startups, that were on paper akin to a lot of other startups in the Israeli world, which were very developed or also in the United States.

+ +

I'll give you an example; there was a company that I worked with that had a $100 million valuation but had no products, no physical products. They had no revenue, but they had innovation. Now, you and I being very honest, do you think a Black-owned company could get away with that?

+ +

CHAD: Yeah, no.

+ +

MICHAEL: There is no way. I knew that; the other entrepreneurs that I've talked to know that. That is a terrible double standard that needs to be fixed. So we look for the same things in BIPOC companies that we look for in other companies because, for the most part, the innovation is there; it's just that the opportunity isn't.

+ +

CHAD: Yeah. To dig into that a little bit more, I think one might say, well, if they had a founding team that had a proven track record, then maybe. And that's where you get to the fact that it's systemic, too, because if the headwinds are there where they can never get that experience, to begin with, they never get that opportunity, to begin with, then they're not going to have a founding team that has a track record that will be invested in based on just the team.

+ +

MICHAEL: That is 100% accurate, but it's actually even worse. So we do not ask our founders in the application process for their educational background. But all six of the companies that got grants from us last November they all have their bachelor's, four out of six have masters or higher. And so the cream definitely rose to the top. We had a store owner she owns an online boutique who got an engineering degree from Purdue. And we also have an entrepreneur who was an attorney at State Street, a corporate attorney, and now he's created this startup. And so, in some cases, like in most other areas, these individuals are overqualified.

+ +

CHAD: So, what is the funding model for GK on both sides of the equation? Where is the money coming from, and then how are you funding the companies?

+ +

MICHAEL: So we raise money organically like any other non-profit does. So we apply for grants. We take corporate donations. We take individual contributions online. Most of our money so far has come in through corporate contributions. So PNC Bank has been with us since the beginning. They made a very large commitment to supporting racial equity, and they've really stuck to it. The Bar Foundation has been exceptional.

+ +

And then we've also had a group of individual donors who were actually White women who have started their own non-profit now, and they've also banded together to give us money that we need to re-grant to the companies. We have over 100,000 from the State of Massachusetts to operate a grant program. So money is coming through a number of different avenues.

+ +

We've issued six micro-grants so far at $10,000 each. We did that in November. We plan to do ten more in the next month. I said in the Boston Business Journal article you can give us money, but you can't park it with us like you could with a donor-advised fund and watch it accumulate interest for 15 years. We're going to take it, and we're going to give it to the people that need it the most.

+ +

CHAD: And are they grants then? You're using the word grants, so I assume that they are. So you're not doing this in exchange for equity in the companies?

+ +

MICHAEL: No, no equity in the companies, no convertible notes, just a straight capital grant directly to the company. So I send a message over to our fiscal sponsors at Philanthropy Massachusetts. They send the check directly over to the company. After that, we have the company fill out a survey letting us know what they plan to use it for, but we're not overly prescriptive. And that's actually the way that philanthropy is heading right now is, putting fewer restrictions and barriers in the way. And that's another thing I'll talk about as well is making it easier for companies to gain access.

+ +

CHAD: So, did you ever consider more of a traditional VC fund model with this?

+ +

MICHAEL: Yeah, originally, I did. Before the pandemic, actually, I did. So the original purpose or impetus of the fund was to take companies that were coming out of accelerator programs that were underfunded. You have some great accelerators, but you have companies leaving with a business plan and $2,000. In some cases, there are companies that have been through three accelerator programs. They're not getting as much out of it as they should. I wanted us to intervene, find the companies that have the most potential, and make investments. But after COVID hit, it was a crisis. And so, we needed to shift our focus to philanthropy.

+ +

CHAD: The nice thing about that is then you can do those grants with basically no strings attached for the companies. Whereas if you were taking money from people who expect to get a return on that investment, you wouldn't be able to do that.

+ +

MICHAEL: That's exactly right. There are organizations out there that say that they're making an impact when in reality they're just making, you know, loans which is not a not a bad thing. But they're issuing loans, or they're taking equity in the companies, that's fine, but it's not what we're doing.

+ +

CHAD: What are your plans for, like, upcoming? Are you going to be continuing with micro-grants, or do you have bigger plans?

+ +

MICHAEL: We have bigger plans. So I can't say too much right now because we have an announcement coming up. But I will say issues like legal services have come up. There's a constant need for attorneys for any company, whether it's contracts, or locking down real estate, or copyright and trademark, or IP. We are working with a very large prestigious law firm that's really making a generous commitment to our companies. And this would involve us even adding free legal services for an entire year to our grantees. So that's one thing that we're planning to do.

+ +

And then the other is, and this another function of the fund, is we speak with organizations like Lyft who's donated like $5,000 in ride credits that we're giving to our grantees or Wix, which has given us like 75% off of websites. We work with partners who can also give us other services that we can provide to these companies to try to get them closer to where there's a gap.

+ +

Giving them capital is not enough. The disparities are too significant. We also partnered with Berkshire Bank, so I can make direct referrals for loans if they need them. But the idea is to really narrow that gap and give these companies the same opportunities that their White counterparts have.

+ +

CHAD: That's great. So you, as someone who's White doing this work, how do you find yourself in the community? How do you be an effective ally and advocate?

+ +

MICHAEL: For me personally, my connection personally through my wife and also through my family and my boss. Colette is a pioneer. She's a Black woman in Boston who moved here not knowing anybody. And 30 years later, she's on The Power of 50 and 100 influential lists, but she did that through hard work. And she's worked much harder, I think, than she would have had to if she weren't a woman from Antigua who came here on her own.

+ +

But ultimately, as an ally, it's my role; it's our role to step in between situations where there's inequity. So if there is a company, one of our companies, for instance, who's having a problem locking down real estate, (I think I use this in the article.), and they're saying, "Well, the real estate agent is telling us they can eliminate our lease at any time they prefer which I know is basically legal." I'll call them up and say, "Look, I'm with the fund. We're backing this company; we support them. What's the situation?" And unfortunately, most of the time, the outcome actually changes.

+ +

So it's a matter of almost you got to be proactive, and you got to be intentional. You have to use your privilege in the best way that you can. So I think that's how you do it. And then, when it's time to shed a light on these companies, you take a step back, so it's not my role to go out there and promote myself. If anyone asks me, I'm always promoting the companies. So the best thing we can do is be advocates. You can be out front, but at the end of the day, it's about uplifting them, these companies in this case.

+ +

CHAD: Yeah, that's great. Speaking of that, I was going to ask you, what are some of the companies that you have given the micro-grants to, and do you know how they use them?

+ +

MICHAEL: Yeah, so we gave our grants to six companies. One is called MustWatch, and MustWatch is founded by Che, and Che, his family, is from Haiti. They are an app. You can actually find them on the App Store. But what they do is they allow you to log in, select which movies and television shows that you watch, and share them with your friends. And it sounds like a very simple concept, but there is actually nothing on the market that allows you to do this.

+ +

And the idea is that you're collecting data while you're doing this as MustWatch. So at the end of the day, if you have a sample of like 20,000 users on the platform, you gain a lot of valuable insight and data. And that data can be useful for Nielsen or the television networks or movie production studios. I encourage people to sign up for MustWatch because if you spend as much time as I do looking for good movies, you're probably miserable.

+ +

CHAD: [laughs]

+ +

MICHAEL: [laughs] I spend so much time doing that. We also have a few online retailers. So we have B. Royal Boutique and So Zen Spa, both of them have doubled their revenue during COVID. They originally had stores. They pivoted during COVID, went online, and really were excellent when it comes to branding and marketing on social media and on other digital platforms. So they've been very successful.

+ +

We have a company called Black Owned Bos., which is pretty well known here in Boston. They basically focus on organizing and running pop-up shops. And Jae'da, who's the head of the company, is just, I mean, she's a business mastermind. She's brilliant, always finding new ways to innovate. And then we have Our Village, which is focused on community development and housing. And finally, sySTEMic flow, which is a company that helps school districts, educators support Black women in STEM and STEAM fields. So we looked for companies that could pivot, basically.

+ +

CHAD: And you mean in the face of the pandemic.

+ +

MICHAEL: In the face of the pandemic, we looked for companies that had success and had a plan and also knew their audience. The main things that we look for…and I should say this too; our application process takes an average of seven minutes. And the way that I did that was I evaluated over 20 accelerator applications. I did a comparative analysis and identified the questions that were either irrelevant or unhelpful for us. And that gave us a very short application for our companies but one that's really efficient.

+ +

And basically, what we're looking for is companies that have a good business model, have a very specific customer base and target market, and have a strong founder, and also has been undersupported. There are companies that we've identified for our next cohort that by this point in their development would have been venture funded in my experience, at least, had they not been people of color.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: What has been the most surprising use of one of the grants?

+ +

MICHAEL: So B. Royal used the grant money to lock down a store in Assembly Square in Somerville. We kind of anticipated they might do that. So Zen Spa they improved their website. MustWatch actually really surprised us. So they went out and got a valuation of their company and then basically worked with a crowdfunding platform called Netcapital to raise more capital. They had a very specific plan, and they had disclosed that plan to us. I just didn't anticipate they would act so quickly on it. And based on the fact that we had given them a grant and all this mentoring and support, their valuation actually went up.

+ +

CHAD: That's a really smart use of the funds to propel that into a larger fundraise. That's really smart.

+ +

MICHAEL: I agree.

+ +

CHAD: So you do this in addition to a day job. [laughs]

+ +

MICHAEL: I mean, they're both day jobs; it's just, yeah.

+ +

CHAD: So you mentioned Colette Phillips, the person, [laughs] how about Colette Phillips Communications?

+ +

So The All Inclusive Campaign it really is historic. The genesis of the campaign is that back in 2020, Colette and I applied for an RFP from the City of Boston; it was for a tourism recovery campaign. All of the major cities in the country got this grant money through regional tourism agencies, you know, like they're a special interest niche. And they went to the Feds, and they're like, "Look, we're suffering, travel is suffering, we need a grant," so all these grants went out.

+ +

The City of Boston actually said, "Look, we want to focus on diverse tourism." So that was perfect for us. We applied, we got the grant. And we brought on Proverb, which is an incredible digital marketing agency and creative design agency, and the Greater Boston Convention & Visitors Bureau. It was the largest contract ever to go to a minority-owned company by the City of Boston, ever, and it was about 1.5 million.

+ +

CHAD: Which in and of itself for what the City of Boston probably spends on things [laughs] is a little ridiculous that that's the biggest one, but … get beyond that, I guess.

+ +

MICHAEL: It's insane. It's very upsetting. And it was a long time overdue. In this case, that contract or that RFP was really only supposed to last like one quarter. So all these regional tourism agencies they get their influx of money, a million dollars or a few 100,000. And then from there, they do the campaign, they move on. We are now three mayor's into this. We are four million dollars into this.

+ +

We submitted the campaign to the city 60 days after they contracted with us; 84% of the contractors on the project are minority-owned companies. And in that 60 days before delivering the campaign, we actually never met in person. So we did this whole campaign virtually from the start. We came in under budget. We came in ahead of time. This is what happens sometimes when you let minority-owned companies take the lead.

+ +

CHAD: Yeah, that's great. How do you do a campaign like this? I mean, this is why they came to you, the experts, but I think it's important that this message seem authentic and not pandering.

+ +

MICHAEL: Yeah, Colette is a visionary. She's been talking about diversity and inclusion for like 20 years. There's an article that came out, I think, in 1992 where she was talking about the importance of diversity in the business community. And now it's like microfilm; you can't even find it digitally online.

+ +

CHAD: [laughs]

+ +

MICHAEL: She's years ahead of her time. And she's constantly innovating, and All Inclusive was her idea, and she branded it. I think it was a long time coming, basically. This is a culmination of a message and campaign that she's been running her whole life.

+ +

CHAD: Yeah, I think that that's very powerful. And I think it comes across in the campaign. It seems authentic. I think it would be easy for it to not seem that way. And so yeah, it comes from that place of this was already a thing. It was already brewing. It wasn't just --

+ +

MICHAEL: Do you want to hear a story?

+ +

CHAD: Yeah, I'd love it.

+ +

MICHAEL: So, most of the media coverage for this campaign was exceptionally positive. There are a few reasons for that. We included all small, locally-owned businesses in the campaign. So you won't find celebrities, no athletes, or anything like that; we may do that later. We also invested...we took 200,000 of the contract, which this was not even supposed to be in there. We actually did ad buys with 19 different local newspapers. In some cases, these newspapers would have actually closed down if we had not done that, and that was just a byproduct of something we felt was important.

+ +

But amidst all of that, she got invited to do an interview on Bloomberg on the local Bloomberg station. She's on the phone, and some guy who was on the other line, and I won't go into it too much, said, "You know, as a White man, I'm really offended. I don't feel represented in this campaign." [laughs] And she's like, "I've had enough of this," hangs up the phone. [laughs]

+ +

And this is another part of allyship I think is...naturally, you know, I said, "Look, I'm taking care of this." I wrote a letter to Bloomberg. I said, "This is unacceptable. You need to take him to task." I don't know if he still works there anymore. But that's kind of the role. You have a Black woman who's a pioneer. She just released a campaign. The first thing you should be saying to her is "Congratulations," instead of saying that, all you can tell her is about how being a White man is like, I don't know, a disadvantage? Which is crazy. There are tons of White people in the campaign. I'm White; I'm in the campaign.

+ +

CHAD: It's so foolish. I don't even want to have to explain it, but the campaign is literally called All Inclusive.

+ +

MICHAEL: [laughs] Exactly, exactly. It covers everybody, I mean, literally. And it's like, I don't know what you want from us.

+ +

CHAD: Yeah. And it's not even...like you go to the site it talks about here's what you can do with families. Here's what you can do with kids, kid-friendly activities.

+ +

MICHAEL: This campaign was also research-based. So we spent 100,000 on research with this incredible company called Heart + Mind. They did a lot of research, and they did a lot of surveying. And the words that came back when describing Boston were unwelcoming, masculine; I think Tom Brady, Ben Affleck, crime, you know, just this kind of machismo unwelcoming environment. And it kind of confirmed some of the assumptions we had, but it was really surprising to see it in the data.

+ +

So we said, "All right, this is what we're working with. We have to come up with a narrative that counters that because Boston is a majority-minority city, 23 neighborhoods, 60% of the population speaks two languages or more. That ethos is really not accurate. So hopefully, we're doing a good job.

+ +

CHAD: So if folks want to help, we already said GK Fund is a non-profit. It's coming up to tax season [laughs], so at the very least, even if you don't...hopefully, you care about the cause, but if you just want that tax write-off, I suppose that's another reason to donate.

+ +

MICHAEL: Absolutely.

+ +

CHAD: So where can folks do that if they want to learn more and donate?

+ +

MICHAEL: Visit www.thegkfund.org.

+ +

CHAD: And are you looking for help in other ways beyond monetary? How can people get involved?

+ +

MICHAEL: Absolutely. So we're looking for mentors so individuals who feel like they have experience or skills to lend to these companies, and we'll try to deploy these individuals in the best way possible. Obviously, we're looking for partnerships. So if you have a company that you feel has something to contribute or is willing to make a contribution, not monetarily but either with your products or with a discount, we also want to give that benefit to the companies as well. And there are a number of different ways.

+ +

CHAD: That's great. And if folks want to follow along with you or get in touch directly with you, how can they do that?

+ +

MICHAEL: You can feel free to follow me on Twitter. It's just @MichaelBenezra, all one word on Twitter. I got a lot of positive messages after the Boston Business Journal article came out and in LinkedIn as well.

+ +

CHAD: Great. And you can subscribe to the show and find notes and a full transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Michael, thanks so much for joining me. I really appreciate it.

+ +

MICHAEL: Yeah, thank you for having me.

+ +

CHAD: And thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Michael Benezra.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Michael Benezra is the Executive Director and Co-Founder of the GK Fund: a nonprofit social impact fund to support BIPOC-owned companies in Greater Boston. Michael also serves as the COO of Colette Phillips Communications, helping to lead the All Inclusive Boston tourism campaign, among other projects.

+ +

Chad talks with Michael about being a BIPOC ally, disparities amongst the VC world, and how the GK Fund looks for the same things in BIPOC-owned companies that they look for in other companies because the innovation is there; it's just that the opportunity isn't.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Michael Benezra, Executive Director and Co-founder of the GK Fund, a non-profit social impact fund to support BIPOC-owned companies in Greater Boston. Michael is also the COO of Colette Phillips Communications, helping to lead the All Inclusive Boston Tourism Campaign, among other projects. Michael, thank you for joining me.

+ +

MICHAEL: Thanks for having me.

+ +

CHAD: I'm curious about the GK Fund. When did you start the Fund?

+ +

MICHAEL: So, at the time, I was working for the Israeli Foreign Ministry, and I was working with venture capital firms, private equity firms. And I was representing over 200 Israeli companies in New England, most of them startups. And my wife is Black; my family is Black. I've been close to that community for a long time. And especially in the venture capital world, I started to see some real disparities amongst other disparities in general everyday life, but it was particularly bad in the VC world.

+ +

And so Colette being a mentor and a friend of mine, Colette Phillips, I approached her, and I said, "Hey, what do you think about starting this fund, this non-profit fund?" And her and Andre Porter, who is our other co-founder who used to be the head of the state's business development agency in Massachusetts, we all decided to band together and start this non-profit. Now, we started the non-profit in December of 2019, so the pandemic hit right as we were creating this organization. And we had a decision to make, do we put this on hold, or do we move forward and accelerate? And we decided to just move forward.

+ +

CHAD: Well, I'm glad you did. I'm glad you made that decision. Hopefully, you feel the same way. [laughs]

+ +

MICHAEL: Yeah, I do.

+ +

CHAD: You're absolutely right. There's a big need here. And I actually have had over the last two months or so a few different guests that are creating VC funds or funds of certain kind that address underrepresented communities, Black, another one was veterans. And there's such a big need. How did you decide what you were going to focus on or focus down into so, for example, focusing on Boston?

+ +

MICHAEL: For Boston specifically, it had to do mostly with proximity. So I went to Harvard here for grad school. I worked for Governor Patrick. And so, for me, it was natural to stay local, especially during COVID. In my experience, there were a lot of BIPOC, particularly Black-owned startups, that were on paper akin to a lot of other startups in the Israeli world, which were very developed or also in the United States.

+ +

I'll give you an example; there was a company that I worked with that had a $100 million valuation but had no products, no physical products. They had no revenue, but they had innovation. Now, you and I being very honest, do you think a Black-owned company could get away with that?

+ +

CHAD: Yeah, no.

+ +

MICHAEL: There is no way. I knew that; the other entrepreneurs that I've talked to know that. That is a terrible double standard that needs to be fixed. So we look for the same things in BIPOC companies that we look for in other companies because, for the most part, the innovation is there; it's just that the opportunity isn't.

+ +

CHAD: Yeah. To dig into that a little bit more, I think one might say, well, if they had a founding team that had a proven track record, then maybe. And that's where you get to the fact that it's systemic, too, because if the headwinds are there where they can never get that experience, to begin with, they never get that opportunity, to begin with, then they're not going to have a founding team that has a track record that will be invested in based on just the team.

+ +

MICHAEL: That is 100% accurate, but it's actually even worse. So we do not ask our founders in the application process for their educational background. But all six of the companies that got grants from us last November they all have their bachelor's, four out of six have masters or higher. And so the cream definitely rose to the top. We had a store owner she owns an online boutique who got an engineering degree from Purdue. And we also have an entrepreneur who was an attorney at State Street, a corporate attorney, and now he's created this startup. And so, in some cases, like in most other areas, these individuals are overqualified.

+ +

CHAD: So, what is the funding model for GK on both sides of the equation? Where is the money coming from, and then how are you funding the companies?

+ +

MICHAEL: So we raise money organically like any other non-profit does. So we apply for grants. We take corporate donations. We take individual contributions online. Most of our money so far has come in through corporate contributions. So PNC Bank has been with us since the beginning. They made a very large commitment to supporting racial equity, and they've really stuck to it. The Bar Foundation has been exceptional.

+ +

And then we've also had a group of individual donors who were actually White women who have started their own non-profit now, and they've also banded together to give us money that we need to re-grant to the companies. We have over 100,000 from the State of Massachusetts to operate a grant program. So money is coming through a number of different avenues.

+ +

We've issued six micro-grants so far at $10,000 each. We did that in November. We plan to do ten more in the next month. I said in the Boston Business Journal article you can give us money, but you can't park it with us like you could with a donor-advised fund and watch it accumulate interest for 15 years. We're going to take it, and we're going to give it to the people that need it the most.

+ +

CHAD: And are they grants then? You're using the word grants, so I assume that they are. So you're not doing this in exchange for equity in the companies?

+ +

MICHAEL: No, no equity in the companies, no convertible notes, just a straight capital grant directly to the company. So I send a message over to our fiscal sponsors at Philanthropy Massachusetts. They send the check directly over to the company. After that, we have the company fill out a survey letting us know what they plan to use it for, but we're not overly prescriptive. And that's actually the way that philanthropy is heading right now is, putting fewer restrictions and barriers in the way. And that's another thing I'll talk about as well is making it easier for companies to gain access.

+ +

CHAD: So, did you ever consider more of a traditional VC fund model with this?

+ +

MICHAEL: Yeah, originally, I did. Before the pandemic, actually, I did. So the original purpose or impetus of the fund was to take companies that were coming out of accelerator programs that were underfunded. You have some great accelerators, but you have companies leaving with a business plan and $2,000. In some cases, there are companies that have been through three accelerator programs. They're not getting as much out of it as they should. I wanted us to intervene, find the companies that have the most potential, and make investments. But after COVID hit, it was a crisis. And so, we needed to shift our focus to philanthropy.

+ +

CHAD: The nice thing about that is then you can do those grants with basically no strings attached for the companies. Whereas if you were taking money from people who expect to get a return on that investment, you wouldn't be able to do that.

+ +

MICHAEL: That's exactly right. There are organizations out there that say that they're making an impact when in reality they're just making, you know, loans which is not a not a bad thing. But they're issuing loans, or they're taking equity in the companies, that's fine, but it's not what we're doing.

+ +

CHAD: What are your plans for, like, upcoming? Are you going to be continuing with micro-grants, or do you have bigger plans?

+ +

MICHAEL: We have bigger plans. So I can't say too much right now because we have an announcement coming up. But I will say issues like legal services have come up. There's a constant need for attorneys for any company, whether it's contracts, or locking down real estate, or copyright and trademark, or IP. We are working with a very large prestigious law firm that's really making a generous commitment to our companies. And this would involve us even adding free legal services for an entire year to our grantees. So that's one thing that we're planning to do.

+ +

And then the other is, and this another function of the fund, is we speak with organizations like Lyft who's donated like $5,000 in ride credits that we're giving to our grantees or Wix, which has given us like 75% off of websites. We work with partners who can also give us other services that we can provide to these companies to try to get them closer to where there's a gap.

+ +

Giving them capital is not enough. The disparities are too significant. We also partnered with Berkshire Bank, so I can make direct referrals for loans if they need them. But the idea is to really narrow that gap and give these companies the same opportunities that their White counterparts have.

+ +

CHAD: That's great. So you, as someone who's White doing this work, how do you find yourself in the community? How do you be an effective ally and advocate?

+ +

MICHAEL: For me personally, my connection personally through my wife and also through my family and my boss. Colette is a pioneer. She's a Black woman in Boston who moved here not knowing anybody. And 30 years later, she's on The Power of 50 and 100 influential lists, but she did that through hard work. And she's worked much harder, I think, than she would have had to if she weren't a woman from Antigua who came here on her own.

+ +

But ultimately, as an ally, it's my role; it's our role to step in between situations where there's inequity. So if there is a company, one of our companies, for instance, who's having a problem locking down real estate, (I think I use this in the article.), and they're saying, "Well, the real estate agent is telling us they can eliminate our lease at any time they prefer which I know is basically legal." I'll call them up and say, "Look, I'm with the fund. We're backing this company; we support them. What's the situation?" And unfortunately, most of the time, the outcome actually changes.

+ +

So it's a matter of almost you got to be proactive, and you got to be intentional. You have to use your privilege in the best way that you can. So I think that's how you do it. And then, when it's time to shed a light on these companies, you take a step back, so it's not my role to go out there and promote myself. If anyone asks me, I'm always promoting the companies. So the best thing we can do is be advocates. You can be out front, but at the end of the day, it's about uplifting them, these companies in this case.

+ +

CHAD: Yeah, that's great. Speaking of that, I was going to ask you, what are some of the companies that you have given the micro-grants to, and do you know how they use them?

+ +

MICHAEL: Yeah, so we gave our grants to six companies. One is called MustWatch, and MustWatch is founded by Che, and Che, his family, is from Haiti. They are an app. You can actually find them on the App Store. But what they do is they allow you to log in, select which movies and television shows that you watch, and share them with your friends. And it sounds like a very simple concept, but there is actually nothing on the market that allows you to do this.

+ +

And the idea is that you're collecting data while you're doing this as MustWatch. So at the end of the day, if you have a sample of like 20,000 users on the platform, you gain a lot of valuable insight and data. And that data can be useful for Nielsen or the television networks or movie production studios. I encourage people to sign up for MustWatch because if you spend as much time as I do looking for good movies, you're probably miserable.

+ +

CHAD: [laughs]

+ +

MICHAEL: [laughs] I spend so much time doing that. We also have a few online retailers. So we have B. Royal Boutique and So Zen Spa, both of them have doubled their revenue during COVID. They originally had stores. They pivoted during COVID, went online, and really were excellent when it comes to branding and marketing on social media and on other digital platforms. So they've been very successful.

+ +

We have a company called Black Owned Bos., which is pretty well known here in Boston. They basically focus on organizing and running pop-up shops. And Jae'da, who's the head of the company, is just, I mean, she's a business mastermind. She's brilliant, always finding new ways to innovate. And then we have Our Village, which is focused on community development and housing. And finally, sySTEMic flow, which is a company that helps school districts, educators support Black women in STEM and STEAM fields. So we looked for companies that could pivot, basically.

+ +

CHAD: And you mean in the face of the pandemic.

+ +

MICHAEL: In the face of the pandemic, we looked for companies that had success and had a plan and also knew their audience. The main things that we look for…and I should say this too; our application process takes an average of seven minutes. And the way that I did that was I evaluated over 20 accelerator applications. I did a comparative analysis and identified the questions that were either irrelevant or unhelpful for us. And that gave us a very short application for our companies but one that's really efficient.

+ +

And basically, what we're looking for is companies that have a good business model, have a very specific customer base and target market, and have a strong founder, and also has been undersupported. There are companies that we've identified for our next cohort that by this point in their development would have been venture funded in my experience, at least, had they not been people of color.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: What has been the most surprising use of one of the grants?

+ +

MICHAEL: So B. Royal used the grant money to lock down a store in Assembly Square in Somerville. We kind of anticipated they might do that. So Zen Spa they improved their website. MustWatch actually really surprised us. So they went out and got a valuation of their company and then basically worked with a crowdfunding platform called Netcapital to raise more capital. They had a very specific plan, and they had disclosed that plan to us. I just didn't anticipate they would act so quickly on it. And based on the fact that we had given them a grant and all this mentoring and support, their valuation actually went up.

+ +

CHAD: That's a really smart use of the funds to propel that into a larger fundraise. That's really smart.

+ +

MICHAEL: I agree.

+ +

CHAD: So you do this in addition to a day job. [laughs]

+ +

MICHAEL: I mean, they're both day jobs; it's just, yeah.

+ +

CHAD: So you mentioned Colette Phillips, the person, [laughs] how about Colette Phillips Communications?

+ +

So The All Inclusive Campaign it really is historic. The genesis of the campaign is that back in 2020, Colette and I applied for an RFP from the City of Boston; it was for a tourism recovery campaign. All of the major cities in the country got this grant money through regional tourism agencies, you know, like they're a special interest niche. And they went to the Feds, and they're like, "Look, we're suffering, travel is suffering, we need a grant," so all these grants went out.

+ +

The City of Boston actually said, "Look, we want to focus on diverse tourism." So that was perfect for us. We applied, we got the grant. And we brought on Proverb, which is an incredible digital marketing agency and creative design agency, and the Greater Boston Convention & Visitors Bureau. It was the largest contract ever to go to a minority-owned company by the City of Boston, ever, and it was about 1.5 million.

+ +

CHAD: Which in and of itself for what the City of Boston probably spends on things [laughs] is a little ridiculous that that's the biggest one, but … get beyond that, I guess.

+ +

MICHAEL: It's insane. It's very upsetting. And it was a long time overdue. In this case, that contract or that RFP was really only supposed to last like one quarter. So all these regional tourism agencies they get their influx of money, a million dollars or a few 100,000. And then from there, they do the campaign, they move on. We are now three mayor's into this. We are four million dollars into this.

+ +

We submitted the campaign to the city 60 days after they contracted with us; 84% of the contractors on the project are minority-owned companies. And in that 60 days before delivering the campaign, we actually never met in person. So we did this whole campaign virtually from the start. We came in under budget. We came in ahead of time. This is what happens sometimes when you let minority-owned companies take the lead.

+ +

CHAD: Yeah, that's great. How do you do a campaign like this? I mean, this is why they came to you, the experts, but I think it's important that this message seem authentic and not pandering.

+ +

MICHAEL: Yeah, Colette is a visionary. She's been talking about diversity and inclusion for like 20 years. There's an article that came out, I think, in 1992 where she was talking about the importance of diversity in the business community. And now it's like microfilm; you can't even find it digitally online.

+ +

CHAD: [laughs]

+ +

MICHAEL: She's years ahead of her time. And she's constantly innovating, and All Inclusive was her idea, and she branded it. I think it was a long time coming, basically. This is a culmination of a message and campaign that she's been running her whole life.

+ +

CHAD: Yeah, I think that that's very powerful. And I think it comes across in the campaign. It seems authentic. I think it would be easy for it to not seem that way. And so yeah, it comes from that place of this was already a thing. It was already brewing. It wasn't just --

+ +

MICHAEL: Do you want to hear a story?

+ +

CHAD: Yeah, I'd love it.

+ +

MICHAEL: So, most of the media coverage for this campaign was exceptionally positive. There are a few reasons for that. We included all small, locally-owned businesses in the campaign. So you won't find celebrities, no athletes, or anything like that; we may do that later. We also invested...we took 200,000 of the contract, which this was not even supposed to be in there. We actually did ad buys with 19 different local newspapers. In some cases, these newspapers would have actually closed down if we had not done that, and that was just a byproduct of something we felt was important.

+ +

But amidst all of that, she got invited to do an interview on Bloomberg on the local Bloomberg station. She's on the phone, and some guy who was on the other line, and I won't go into it too much, said, "You know, as a White man, I'm really offended. I don't feel represented in this campaign." [laughs] And she's like, "I've had enough of this," hangs up the phone. [laughs]

+ +

And this is another part of allyship I think is...naturally, you know, I said, "Look, I'm taking care of this." I wrote a letter to Bloomberg. I said, "This is unacceptable. You need to take him to task." I don't know if he still works there anymore. But that's kind of the role. You have a Black woman who's a pioneer. She just released a campaign. The first thing you should be saying to her is "Congratulations," instead of saying that, all you can tell her is about how being a White man is like, I don't know, a disadvantage? Which is crazy. There are tons of White people in the campaign. I'm White; I'm in the campaign.

+ +

CHAD: It's so foolish. I don't even want to have to explain it, but the campaign is literally called All Inclusive.

+ +

MICHAEL: [laughs] Exactly, exactly. It covers everybody, I mean, literally. And it's like, I don't know what you want from us.

+ +

CHAD: Yeah. And it's not even...like you go to the site it talks about here's what you can do with families. Here's what you can do with kids, kid-friendly activities.

+ +

MICHAEL: This campaign was also research-based. So we spent 100,000 on research with this incredible company called Heart + Mind. They did a lot of research, and they did a lot of surveying. And the words that came back when describing Boston were unwelcoming, masculine; I think Tom Brady, Ben Affleck, crime, you know, just this kind of machismo unwelcoming environment. And it kind of confirmed some of the assumptions we had, but it was really surprising to see it in the data.

+ +

So we said, "All right, this is what we're working with. We have to come up with a narrative that counters that because Boston is a majority-minority city, 23 neighborhoods, 60% of the population speaks two languages or more. That ethos is really not accurate. So hopefully, we're doing a good job.

+ +

CHAD: So if folks want to help, we already said GK Fund is a non-profit. It's coming up to tax season [laughs], so at the very least, even if you don't...hopefully, you care about the cause, but if you just want that tax write-off, I suppose that's another reason to donate.

+ +

MICHAEL: Absolutely.

+ +

CHAD: So where can folks do that if they want to learn more and donate?

+ +

MICHAEL: Visit www.thegkfund.org.

+ +

CHAD: And are you looking for help in other ways beyond monetary? How can people get involved?

+ +

MICHAEL: Absolutely. So we're looking for mentors so individuals who feel like they have experience or skills to lend to these companies, and we'll try to deploy these individuals in the best way possible. Obviously, we're looking for partnerships. So if you have a company that you feel has something to contribute or is willing to make a contribution, not monetarily but either with your products or with a discount, we also want to give that benefit to the companies as well. And there are a number of different ways.

+ +

CHAD: That's great. And if folks want to follow along with you or get in touch directly with you, how can they do that?

+ +

MICHAEL: You can feel free to follow me on Twitter. It's just @MichaelBenezra, all one word on Twitter. I got a lot of positive messages after the Boston Business Journal article came out and in LinkedIn as well.

+ +

CHAD: Great. And you can subscribe to the show and find notes and a full transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Michael, thanks so much for joining me. I really appreciate it.

+ +

MICHAEL: Yeah, thank you for having me.

+ +

CHAD: And thank you for listening. See you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Michael Benezra.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MheLUOvt + + ]]> + + Chad Pytel + Michael Benezra + + + 418: Aitomatic with Christopher Nguyen + https://podcast.thoughtbot.com/418 + 9df8ea6e-6117-4fc3-b94d-62e532fe7129 + Thu, 14 Apr 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Christopher Nguyen is the CEO of Aitomatic, which provides knowledge-first AI for industrial automation. + +Chad talks with Christopher about why having a physical sciences background matters for this work, if we have artificial intelligence, why we still need people, and working in knowledge-first AI instead of knowledge-second, knowledge-third, or no knowledge at all. Data reflects the world. + 39:04 + no + + + Christopher Nguyen is the CEO of Aitomatic, which provides knowledge-first AI for industrial automation. +Chad talks with Christopher about why having a physical sciences background matters for this work, if we have artificial intelligence, why we still need people, and working in knowledge-first AI instead of knowledge-second, knowledge-third, or no knowledge at all. Data reflects the world. +Aitomatic (https://www.aitomatic.com/) +Follow Aitomatic on Twitter (https://twitter.com/aitomatic) or LinkedIn (https://www.linkedin.com/company/aitomatic/). +Follow Christopher on Twitter (https://twitter.com/pentagoniac) or LinkedIn (https://www.linkedin.com/in/ctnguyen/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Christopher Nguyen, CEO of Aitomatic, which provides knowledge-first AI for industrial automation. Christopher, thanks for joining me. +CHRISTOPHER: Thank you. +CHAD: So I was prepping for this interview, and I noticed something that jumped out at me that we have in common, and that is your first computer was the TI-99C/4A. +CHRISTOPHER: No kidding. +CHAD: And that was also my first computer. +CHRISTOPHER: Oh, okay. +CHAD: [laughs] +CHRISTOPHER: You got no storage, correct? +CHAD: No storage; everything was off of the solid-state disks. And I remember I was a little late to it. My parents actually got it for me. I think I was 9 or 10. And my parents got it for me at a garage sale. And so all I had was the manual and the basic manual that came with it. And because it had no storage, I needed to type in the programs that were in the back of that book from scratch, and there was no way to save them. So you would type them in -- [laughs] +CHRISTOPHER: Oh my God. Every single day the same code over and over again. And hopefully, you don't turn it off. +CHAD: [laughs] Exactly. There definitely were times where it would just be on in my room because I didn't want to lose what I had spent all day typing in. +CHRISTOPHER: Yeah, yeah, I remember my proudest moment was my sister walked into the living room...and there was no monitor, and you connected it directly to the TV. +CHAD: To the TV, yeah. +CHRISTOPHER: And younger people may not even know the term character graphics, which is you pick in your book the character space, and then you put them together into a graphic image. And I painstakingly, on graph paper, created a car and converted it to hex and then poked it into these characters and put them together. And my sister walked in like, "Oh my God, you made a car." +[laughter] +CHAD: That was a good time. It was difficult back then. I feel like I learned a lot in an environment where I see people learning. Today it's a lot more of a complicated environment. They're much higher up the stack than we were back then. And, I don't know, I feel like I actually sort of had it easy. +CHRISTOPHER: Well, in many ways, that very abstraction to...you see jobs like to talk about higher software abstraction to make you more productive. I think it's absolutely that powerful. And Marc Andreessen, my friend, likes to talk about how software is eating the world. But it turns out there's one perspective where people have gone up the stack a little too far, too fast, and too much. We're still physical in the industry that I work in. +You know, our previous company was acquired by Panasonic. And I've been working on industrial AI for the last four and a half years. And it's very hard for us to find people with the right physics or electro engineering background and the right science understanding to help automate and build some of these systems because everybody's in software now. +CHAD: Why does physical sciences background matter for this work? +CHRISTOPHER: Let me give you a couple of examples. One example is one of our customers is a very large global conglomerate doing marine navigation and marine sensors. And one of the products they do is fish finding so that amateurs like you and me would go hold one of these systems and shoot it down straight to the ocean. A sonar beam goes down, kind of like submarines. But hopefully, an image would come back. And so to build a system to convert all of that into something other than jumbled what they call echograms, maybe convert to a fish image, you have to build a lot of machine intelligence, AI, machine learning, and so on. +But just to understand the data and make the right decisions about how to do that, you need to understand the physics of sound wave echoes in the ocean. If you can't do that and you got to work with another engineer to tell you how to do that, it really slows things down a lot. So knowing the equation but also having a physical intuition for how it all works can make or break the success of an engineer working on something like that. +Another example is we worked on avionics. Don't blame me for this, but if you have had poor experience with Wi-Fi on a plane, we may be involved in one way or another, Panasonic Avionics. +CHAD: [laughs] +CHRISTOPHER: But the antenna array that sits on top of the plane to receive satellite signal and sends out a signal, so you can expect there's some kind of optimization involved. It's not just line of sight. If there's a cloud coming nearby, then there's some distortion, and there's some optimization needed to take place. Again, an understanding of...at least if you remember, if not an expert in college physics, about antenna radiation pattern and so on, which help tremendously a data scientist or an engineer working on that problem whereas somebody who's a pure computer scientist would struggle a lot and probably give up with that problem. +CHAD: Yeah, this may be a little bit of a facetious question or leading question; I'm not sure which, but if we have artificial intelligence, why do we need people to do this stuff? +CHRISTOPHER: [laughs] Well, I have a broader, you know, I've thought about that a lot. And I'll answer it in the broad sense, but I think you can specialize it. The problem with machine learning, at least today and I really think for a very long time for the rest of the century at least, is that it is trained on data. And data is past examples. And when I say past, I include the present. In other words, whatever it is that our algorithms learn, they learn the world as it is. +Now, we're always trying to change the world in some way. We're always trying to change the world to what we wish it to be, not what it is. And so it's the humans that express that aspiration. I want my machine to behave better in some way. Or I want my algorithms not to have this built-in bias when it makes a decision that affects someone's life. +If it's pure machine learning and data, it will indeed reflect all the decisions that have ever been made, and it'll have all those built-in biases. So there's a big topic there to unpack and who's responsible for doing what. But I think coming back to your question, we'll always need humans to express what it is that is the world that you want in the next minute, the next day, the next week, or the next 50 years. +CHAD: So let's talk more about the ethics or the biases that can be baked into AI. How do you prevent that at Aitomatic? +CHRISTOPHER: As I said, this is a big topic. But let me begin by saying that actually, most of us don't know what we mean when we say bias, or to put it more broadly, we don't agree on the meaning. The word bias in colloquial conversation always comes with a negative connotation on the one hand. On the other hand, in machine learning, bias is inherent. You cannot have machine work without bias. So clearly, those two words must mean something slightly different even though they reflect the same thing, the same underlying physics, if you will. +So first, before people get into what they think is a very well-informed debate, they must first agree on a framework for terms that they're using. Now, of course, I can accommodate and say, okay, I think I know what you mean by that term. And so, let's take the colloquial meaning of bias. And when we say bias, we usually mean some built-in prejudice, it may be implicit, or it may be explicit that causes a human or machine to make a decision that discriminates against someone. +And here's the thing, we've got to think about intent versus impact. Is it okay for the effect to be quote, unquote, "biased" if I didn't intend it, or it doesn't matter what my intent was, and it's only the impact that matters? That's another dimension that people have to agree or even agree to disagree on before they start going into these circular arguments. But let's focus on, for now, let's say it's the impact that matters. It doesn't matter what the intent is, particularly because machines, as of present, there is no intent. +So, for example, when the Uber vehicle a number of years ago hit and killed a bicyclist, there was no traceable intent, certainly not in the system design to cause that to happen. But yet it happened, and the person did die. So coming back to your question, I know that I've neglected the question because I'm unpacking a lot of things that otherwise an answer would make no sense, or it would not have the sense meant. +So coming back, how do we prevent bias as an effect from happening in our system? And an answer that I would propose is to stop thinking about it in terms of point answers; in other words, it's not that...people say...well, myself I even said earlier it's in the data. Well, if it's in the data, does that absolve the people who build the algorithms? And if it's in the algorithms, does that absolve the people who use it? I had a conversation with some friends from Europe, and they said, "In America, you guys are so obsessed with blaming the user." Guns don't kill people; people kill people. +But I think to answer your question in a very thoughtful manner; we must first accept the responsibility throughout the entire chain and agree on what it is the outcome that we want to have, at least effect. And then the responsibility falls on all chains, all parts of the chain. And one day, it may be, hey, you got to tune the algorithm a certain way. Another day may be, hey, collect this kind of data. +And another day, it might be make sure that when you finally help with the decision, that you tweak it a certain way to affect the outcome that you want. I think what I've described is the most intellectually honest statement. And somebody listening to this is going to have a perspective that disagrees vehemently with one of the things I just said because they don't want that responsibility. +CHAD: I like it, though, because it recognizes that we're creating it. It may be a tool, and tools can be used for anything. But as the creators of that tool, we do have responsibility for...well, I think we have responsibility for what that is going to do, and if not us, then who? +CHRISTOPHER: That's right. Yeah. But if you follow the debate, you will find that there are absolutists who say, "That's not my problem. That's the user, or the decision-maker, or the data provider. But my algorithms I have to optimize in this way, and it's going to output exactly what the data told it to. The rest is your problem." +CHAD: So it strikes me in hearing you describe what's involved, especially at the state that machine learning is at now; it probably varies or what you are going to do specifically varies based on what you're trying to achieve. And maybe even the industry that it's in like avionics and what you need to do there may be different than energy. +CHRISTOPHER: Yep, or more broadly, physical industries versus the plane falls out of the air, or a car hits somebody, somebody actually dies. If you get a particular algorithm wrong at Google, maybe you click on the wrong ad. So I really advocate thinking about the impact and not just the basic algorithms. +CHAD: Yeah, so tell me more about the actual product or services that Aitomatic provides and also who the customers are. +CHRISTOPHER: I think what we discussed is quite relevant to that. I think it does lead in a very real perspective directly into that. We do what's called knowledge-first AI. And that knowledge-first as opposed to knowledge-second and knowledge-third or no knowledge at all, there are very strong schools of thought that say, "With sufficient data, we can create AI to do everything." Data is reflecting the world. As I mentioned, it's in the past as it is, not as what we want it to be. +When you apply it to some of the concrete things that we do, let's take a use case like predictive maintenance of equipment, you want to be able to save cost and even to save lives. You want to replace things, service things before they actually fail. Failure is very costly. It's far more costly than the equipment itself. Today, the state of the art is preventive maintenance, not predictive. Preventive means, let’s just every six months, every one year replace all the lights because it's too costly to replace them one by one when they fail. +Lots of industries today still do what's called reactive maintenance, you know, fix it when it fails. So predictive maintenance is the state of the art. The challenge is how do you get data and train enough machine intelligence to essentially predict? And the prediction precisely means the following: can you tell me with some probability that this compressor for this HVAC system, this air conditioning system may fail within the next month? And it turns out machine learning cannot do that. +CHAD: Oh, that's the twist. +CHRISTOPHER: Exactly. [laughter] And I know a lot of people listening are going to sit up and say, "Christopher doesn't know what the hell he's talking about." +CHAD: [laughs] +CHRISTOPHER: But I really know. I really know what the hell I'm talking about because we've been part of an industrial giant. I'll tell you what machine learning can do and what it cannot do. What it can do is with the data that's available...the main punch line, the main reason here is that there are not enough past examples of actual failures of certain types. +There's a lot of data. We're swimming in data, but we're not actually swimming in cleanly recorded failures that are well classified. And machine learning is about learning from past examples, except today, algorithms need a lot of past examples, tens of thousands, hundreds of thousands, or even millions of past examples, in order for it to discover those repeating patterns. +So we have a lot of data at places like Panasonic, Samsung, Intel, GE, all the physical industries, but these are just sensor data that's recording mostly normal operation. When a failure happens, that tends to be rare. Hopefully, failures are rare, and then they're very specific. So it turns out that what's called the labeled data is insufficient for machine learning. +So what machine learning can do is do what's called anomaly detection. And that is look at all the normal patterns, and then when something abnormal appears on the horizon to say, "Hey, something is weird. I haven't seen this before." But it cannot identify what it is, which is only half of predictive maintenance because you have to identify what the problem is so you can replace that compressor or that filter. And it turns out humans are very good. Human experts are very good at that second part. +The first improvement might be to say let's get machine learning to detect anomalies and then let's get human experts to actually do fault prediction. And after you do this for a while, which is what we did at Panasonic in the last three, four years across the global AI units, we said, "Well, wait a minute. Why are we making these very expensive?" Human experts do this if we can somehow codify their domain expertise. And so that's what Aitomatic is. We have developed a bunch of techniques, algorithms, and systems that run as SaaS software to help people codify their domain expertise, combine it with machine learning, and then deploy the whole thing as a system. +CHAD: The codified expertise, there's a word for that, right? +CHRISTOPHER: Probably you're referring to expert systems. +CHAD: Yes. Yes. +CHRISTOPHER: Yeah. Expert systems is one way to codify domain expertise. At the very basic level, you and I wrote actual BASIC programs before. You can think of that as codifying your human knowledge. You're telling the computer exactly what to do. So expert systems of the past is one way to do so. But what I'm referring to is a more evolved and more advanced perspective on that, which is how do you codify it in such a way that you can seamlessly combine with machine learning? +Expert systems and machine learning act like two islands that don't meet. But how do you do it in such a way that you can codify human knowledge and then benefit as more data comes in, absolutely move into this idea of asymptotically this world where data tells you everything? Which it never will. And so the way we do that, the naive way, as I mentioned, is simply to just write it down as a bunch of rules. And the problem is rules conflict with each other. +We, humans, work on heuristics. Whatever it is you tell me to do, you could be an expert, and you start teaching me, and you say, "Okay, so here are the rules." And then once I learn the rules, you say, "Well, and there are some exceptions." [laughs] And then, can you tell me all the exceptions? No, you can't. You have to use judgment. Okay, well, what is that? So the way we codify it is you can think of that evolution. I'll give you one concrete example from the machine learning perspective so people that are machine learning experts can see how we do things that are different. There's something in the machine learning process called the loss function. Have you heard of that term? +CHAD: No. Yeah. +CHRISTOPHER: So it's very simple. Training, which I'm sure everybody has heard, is really about how do I tweak the parameters inside the algorithm so that eventually, it gives the correct answer? So this process is repeated millions of times or hundreds of thousands of times. But let's say the first time, it gives you a random answer, but you know what the right answer should be. These are training examples. +So you compute an error. If you output a five and the answer is actually six, so I say, "Oh, you're off by one, positive one," and so on. So there's a loss function, and in this case, it's simply the subtraction of one. And then that signal, that number one, is somehow fed back into the training system that says, "Well, you were close, but you're off by one." And the next time, maybe you're off by 0.5, next time maybe you're off by -2, and so on and so forth. That value is computable, what's called a loss function. That's machine learning because you have all these examples. +Well, human knowledge can be applied as a loss function too. A simple example is that you don't have all the data examples, but you have a physical equation. If you throw a ball in the air, it follows a parabolic pattern, and we can model that exactly, an elliptic equation. That is a way to produce the correct answer, but there's no resistance there. And so, we can apply that function back as a loss function to encode that human knowledge. +Of course, things are not always as simple as a parabolic equation. But a human expert can say, "The temperature on this can never exceed 23. If it exceeds 23, life is going to end as we know it because you're going to have a disaster." You can put into the loss function an equation that says if your predictor is greater than 23, give it a very high loss. Give it a very strong signal that this cannot be. And so your machine learning function being trained can get that signal coming back and adjust the parameters appropriately. So that's just one example of how we codify human knowledge in a way that is more than just expert systems. +CHAD: That's really cool. Now, is there a way, once you have the system up and running and it is making decisions, to then feedback into that cycle and improve the model itself? +CHRISTOPHER: Oh, absolutely, yeah. I think there's a parallel to what I say during training to also while it's in production, both in real-time, meaning one example at a time, as well as in batch after you've done a bunch of these. In fact, the first successful predictive maintenance system we deployed when we were part of Panasonic employs a human being that they feedback at. +So our system would try to learn as much as it can and then try to predict the probability of failure of some piece of equipment. And the human being at the other end would say, "Okay, yeah, that looks reasonable." But a lot of times, they would say, "Clearly wrong. Look at this sensor over here. The pressure is high, and you didn't take that into account." So that's a process that we use both to certainly improve the output itself but also the feedback to improve our predictive AI. +Mid-Roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So on the customer side, whether you can share specific customers or not, what kinds of companies are your customers? +CHRISTOPHER: So I've mentioned in passing a number, so Panasonic is one of our customers. When I say Panasonic, Panasonic is a global giant, so it's run as individual companies. So, for example, avionics automotive coaching, how a fish gets from the ocean to your table, Panasonic has a big market share in making sure that everywhere in the chain that fish is refrigerated. So it's called the cold supply chain or cold chain. Supermarkets their refrigeration systems keep our food fresh, and if that goes down in an unplanned manner, then they lose entire days or weeks of sales. +I mentioned the example of Furuno, F-U-R-U-N-O. If you go to some marina, say Half Moon Bay, California, you would see on the masts most of the navigation equipment is a Furuno, the white and blue logo. So we help them with those systems and fish finding systems. As well as off the coast of Japan, there's a practice called fixed-net fishing. What that is is miles and miles of netting. And large schools of fish would swim from different gates, A into B. And once they get to B, it's set in such a way that they cannot go back to A. But it's very large that they feel like they're swimming in the ocean still and eventually to trap C. +And so Furuno is working on techniques to both detect what kind of fish is flowing through as well as actually count or estimate the number so the fishermen can determine exactly when to go and collect their catch. So I can go on. There are lots of these really interesting physics-related and physical use cases. +CHAD: So is Aitomatic actually spun off from Panasonic? +CHRISTOPHER: Spin-off, I think legally speaking, that is not the correct term because we're independent. Panasonic does not own shares. But in terms of our working relationship as customer and vendor, it's as good as it ever was. +CHAD: What went into that decision-making process to do that? +CHRISTOPHER: To do the so-called spin-off? +CHAD: Yeah. +CHRISTOPHER: Lots of things. +CHAD: I'm sure it was a complicated decision. [laughs] +CHRISTOPHER: Like we used to say at Google, to decide where to put a data center, lots of things have to intersect just the right way, including the alignment of the stars. In our case, it's a number of things. Number one, the business model just, as I said, at a very high level, it makes a lot of sense for us to be an independent company otherwise inside a...if we're a small unit inside a parent company, the business incentives are very different from if you're a startup, that's one. And the change is positive for both sides. +Number two, in terms of venture capital, as you know, today, once you're an independent company, you can access a very large amount of scale in such a way that even a global giant doesn't have the same model to fund. Number three, certainly, the scope of the business we want to be able to apply...everything that I talk to you here is actually an open-source project. +We have something called human-first AI rather than just knowledge-first, and so being able to put it out into the open-source and being able to have other people contribute to it is much easier as an independent startup than if it's a business unit. And then finally, of course, aspirations, myself and the rest of the team, we can move a lot faster. People are more passionate about the ownership of what they do. It's a much better setup as an independent company. +CHAD: Were there things from Panasonic, either in culture or the way that the business works, that even though you had the opportunity to be independent, you said, "Hey, that was pretty good. Let's keep that going"? +CHRISTOPHER: Well, I can comment on the culture of Panasonic itself. It's something that I was surprised by. This is 100 years old. The anniversary was in 2018. I gave a talk in Tokyo. So a 100-year old conglomerate. Japan might seem very stodgy, and, sorry to say, in many ways, it is. But I was very impressed. And I say this as a headline in cocktail conversation. I say the culture of engineering at Panasonic is far more like the Google that I knew than it is different; in other words, very little empire-building. People are very engineering-driven. There are a lot of cordial discussions and so on when people go into a meeting. I was very impressed by this. +The Japanese engineers in Panasonic were always really well prepared. By the time they got to the meeting, even though they are in this context our customers, they will come with a slide deck like 30 slides talking through the entire use case. And they thought about this, they thought about that. And so I'm sitting there just absorbing it, just learning the whole thing. I really enjoyed that part of being part of Panasonic. And many of those folks are now lifelong friends of mine. +CHAD: And so that's something that you've tried to maintain, that engineering-focused culture and great place. +CHRISTOPHER: Well, when we were acquired by Panasonic, both Tsuga-san, the CEO, and Miyabe-san, the CTO, said the following, he said, "We want you to infect Panasonic, not the other way around." [laughs] From their perspective, we had this Silicon Valley setup. And they want this innovation, a fresh startup, not just the algorithms but also the culture. And they were true to their word. We kept an office, our own unit, kept their office in Downtown Mountain View. And folks were sent in to pick up our ways and means. What I enjoyed, the part that I just shared with you, is what I didn't expect to learn but what I did learn in retrospect. +CHAD: As you set out on everything you want to achieve, what are you worried about? What do you think the biggest hurdles are going to be that you need to overcome to make a successful business, successful product? +CHRISTOPHER: Well, I've done this multiple times. So people like to say, "You've seen this movie before," but of course, every movie is told differently, and the scenes are different, the actors are different, and so on. Of course, the times are different. So concretely, our immediate next hurdle you have to have proof points along the way. So we've got good revenues already. As a startup less than one-year-old, we have unusually good revenues but mainly because of our deep relationships in this particular industry. +The next concrete proof point is a series of things, metrics that says we have a good product-market fit. And, of course, product-market fit means more than just a great product idea. It's a great product idea that is executed in a way that the market wants it in the next quarter, not ten years from now. So product-market fit is that iteration, and we're quite fortunate to have already customers what we call design partners that we work with. So hearing from that diverse set is pretty good confidence that if they want it, then other people will want it as well. +And then after that, certainly after in timing but in the doing now, is scaling our sales efforts, our sales volume beyond just the founder-led volume that we currently have, so building the sales team and so on. But these are things that I will say are generally understood. But it does have to still be; you just got to sweat it. You got to do it. It doesn't happen automatically. I think the much bigger challenge that I see, and maybe it's an opportunity depending on how you think about it, is I'll call it a cultural barrier. Silicon Valley, in particular, the academic side of us...and you may know I used to be a professor, so when I say academic, I'm talking about myself as well. So any criticism is self-directed. +CHAD: [laughs] +CHRISTOPHER: We tend to be purists. The purism of today, if I can use that term, is data. And so, whenever I talk about knowledge-first AI, it offends the sensibilities of some people. They say, "You mean you're going back to expert systems. You mean you are not going to be extolling the virtues of machine learning and so on." And I have to explain data is nice if you have it, but 90% of the world doesn't have the data. And you do need to come up with these new techniques to combine human knowledge with machine learning. +We look forward to being the Vanguard of that revolution, if you will, that say maybe it's a step backward. I think of it as a step forward of really harmoniously combining human knowledge and machine data to build what we call AI systems, these powerful systems that we're purporting to build. And that's almost directly at odds with the school of thought where people say, "Eventually, we'll have all the data." [laughs] And maybe, as you stated at the beginning, we don't need humans anymore. I will fight that battle. +CHAD: The customers that you talked about, a lot of them seem to be pretty big enterprises. So as you talk about scaling sales beyond the founder-led sales that you're doing now, are you continuing to sell to enterprises? Or do you ultimately envision the product being accessible to any company? +CHRISTOPHER: Well, I would say both. But I say that in a very careful sense because it's very important building businesses with a focus. And so let me break down what I mean by both, not just from some ambitious thing, you know, A and B. We will focus on enterprise as a matter of business. And the reason for that is A, that's where the money is but B, but more importantly, it's also where the readiness is. We've gone through...it's amazing. It's been a decade since that first New York Times, what I call the cats’ paper about the Google Brain Project. +We've gone through a decade of the hype and everything, but this vast physical industry, the industrial of the world, is ready. When I say ready, it means that people are now sophisticated. They don't look at it with wide eyes and say, "Please sprinkle a little bit of AI on my system." So they have teams, and they can benefit from what we do at the scale of what I've just described. But the reason I say both is because, quite happily, it is an open-source project. +Our roadmap is designed with our design partners, but once it's out there, the system can be contributed to by others. The nature of open source is such that people tend to use it more than contribute. That's fine. So I think a lot of the smaller companies and smaller teams, once they overcome this cultural barrier of applying knowledge as opposed to pure data, I think they can really take advantage of our technology. +CHAD: I'm glad you segued there because I was going to bring us there, too, which is that that open source that you've made available was it ever a question whether you could build a business where you were also open-sourcing the software behind it? +CHRISTOPHER: It was absolutely a question 10 years ago. The industry has evolved. And now you and I talked about the TI-99/4A. I was already writing what's called public domain software before the term open source. Ten years ago, CIOs would say, "Why would I do away with the relationship with a big company like a Microsoft or an Oracle in favor of this unreliable, unknown open source?" It turns out, as we now look back, it was nothing to do with the business model; it was the immaturity of open source. +Today, it is the opposite. Today, people don't worry about the lock-in with a vendor whose source code that they don't have. But I think equally important, source code is no longer a competitive advantage. Let me say that again. Source code is no longer that intellectual property. CIOs today want to be able to have the peace of mind that if some company locks them out or the company becomes defunct, that the engineers still have access to that source code so that they can build it. But that is not the real value. +Amazon, Microsoft Azure, and GCP, Google have proven that people are very willing to pay for some experts to run operationally these systems so that they can concentrate on what they do best. So every day today, you know, every month, we're sending checks to AWS. They're running something that my team can easily run but probably at a much higher cost. But even at cost parity, I would like my team members to be focused on knowledge-first AI rather than the running of an email system or the running of some compute. +So likewise, the value that our customers get from us is not the source code. But they're very willing for us to run this big industrial AI system so that they can focus on the actual work of codifying their expert knowledge. And by the way, I probably gave too long an answer to that. Another way is simply to look at the public market; there are very well rewarded companies that are entirely open source. +CHAD: Yeah. Well, thank you. That was great. Thank you for stopping by and sharing with me. I really appreciate it. If folks want to find out more about Aitomatic or get in touch with you or follow along, where are all the places that they can do that? +CHRISTOPHER: I think the website, aitomatic.com And it's just like automatic, except that it starts with A-I-. So I think the website is a great place to start to contact us. +CHAD: Wonderful. Thank you again. +CHRISTOPHER: Awesome. Thank you. +CHAD: You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Christopher Nguyen . + + + Christopher Nguyen is the CEO of Aitomatic, which provides knowledge-first AI for industrial automation.

+ +

Chad talks with Christopher about why having a physical sciences background matters for this work, if we have artificial intelligence, why we still need people, and working in knowledge-first AI instead of knowledge-second, knowledge-third, or no knowledge at all. Data reflects the world.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Christopher Nguyen, CEO of Aitomatic, which provides knowledge-first AI for industrial automation. Christopher, thanks for joining me.

+ +

CHRISTOPHER: Thank you.

+ +

CHAD: So I was prepping for this interview, and I noticed something that jumped out at me that we have in common, and that is your first computer was the TI-99C/4A.

+ +

CHRISTOPHER: No kidding.

+ +

CHAD: And that was also my first computer.

+ +

CHRISTOPHER: Oh, okay.

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: You got no storage, correct?

+ +

CHAD: No storage; everything was off of the solid-state disks. And I remember I was a little late to it. My parents actually got it for me. I think I was 9 or 10. And my parents got it for me at a garage sale. And so all I had was the manual and the basic manual that came with it. And because it had no storage, I needed to type in the programs that were in the back of that book from scratch, and there was no way to save them. So you would type them in -- [laughs]

+ +

CHRISTOPHER: Oh my God. Every single day the same code over and over again. And hopefully, you don't turn it off.

+ +

CHAD: [laughs] Exactly. There definitely were times where it would just be on in my room because I didn't want to lose what I had spent all day typing in.

+ +

CHRISTOPHER: Yeah, yeah, I remember my proudest moment was my sister walked into the living room...and there was no monitor, and you connected it directly to the TV.

+ +

CHAD: To the TV, yeah.

+ +

CHRISTOPHER: And younger people may not even know the term character graphics, which is you pick in your book the character space, and then you put them together into a graphic image. And I painstakingly, on graph paper, created a car and converted it to hex and then poked it into these characters and put them together. And my sister walked in like, "Oh my God, you made a car."

+ +

[laughter]

+ +

CHAD: That was a good time. It was difficult back then. I feel like I learned a lot in an environment where I see people learning. Today it's a lot more of a complicated environment. They're much higher up the stack than we were back then. And, I don't know, I feel like I actually sort of had it easy.

+ +

CHRISTOPHER: Well, in many ways, that very abstraction to...you see jobs like to talk about higher software abstraction to make you more productive. I think it's absolutely that powerful. And Marc Andreessen, my friend, likes to talk about how software is eating the world. But it turns out there's one perspective where people have gone up the stack a little too far, too fast, and too much. We're still physical in the industry that I work in.

+ +

You know, our previous company was acquired by Panasonic. And I've been working on industrial AI for the last four and a half years. And it's very hard for us to find people with the right physics or electro engineering background and the right science understanding to help automate and build some of these systems because everybody's in software now.

+ +

CHAD: Why does physical sciences background matter for this work?

+ +

CHRISTOPHER: Let me give you a couple of examples. One example is one of our customers is a very large global conglomerate doing marine navigation and marine sensors. And one of the products they do is fish finding so that amateurs like you and me would go hold one of these systems and shoot it down straight to the ocean. A sonar beam goes down, kind of like submarines. But hopefully, an image would come back. And so to build a system to convert all of that into something other than jumbled what they call echograms, maybe convert to a fish image, you have to build a lot of machine intelligence, AI, machine learning, and so on.

+ +

But just to understand the data and make the right decisions about how to do that, you need to understand the physics of sound wave echoes in the ocean. If you can't do that and you got to work with another engineer to tell you how to do that, it really slows things down a lot. So knowing the equation but also having a physical intuition for how it all works can make or break the success of an engineer working on something like that.

+ +

Another example is we worked on avionics. Don't blame me for this, but if you have had poor experience with Wi-Fi on a plane, we may be involved in one way or another, Panasonic Avionics.

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: But the antenna array that sits on top of the plane to receive satellite signal and sends out a signal, so you can expect there's some kind of optimization involved. It's not just line of sight. If there's a cloud coming nearby, then there's some distortion, and there's some optimization needed to take place. Again, an understanding of...at least if you remember, if not an expert in college physics, about antenna radiation pattern and so on, which help tremendously a data scientist or an engineer working on that problem whereas somebody who's a pure computer scientist would struggle a lot and probably give up with that problem.

+ +

CHAD: Yeah, this may be a little bit of a facetious question or leading question; I'm not sure which, but if we have artificial intelligence, why do we need people to do this stuff?

+ +

CHRISTOPHER: [laughs] Well, I have a broader, you know, I've thought about that a lot. And I'll answer it in the broad sense, but I think you can specialize it. The problem with machine learning, at least today and I really think for a very long time for the rest of the century at least, is that it is trained on data. And data is past examples. And when I say past, I include the present. In other words, whatever it is that our algorithms learn, they learn the world as it is.

+ +

Now, we're always trying to change the world in some way. We're always trying to change the world to what we wish it to be, not what it is. And so it's the humans that express that aspiration. I want my machine to behave better in some way. Or I want my algorithms not to have this built-in bias when it makes a decision that affects someone's life.

+ +

If it's pure machine learning and data, it will indeed reflect all the decisions that have ever been made, and it'll have all those built-in biases. So there's a big topic there to unpack and who's responsible for doing what. But I think coming back to your question, we'll always need humans to express what it is that is the world that you want in the next minute, the next day, the next week, or the next 50 years.

+ +

CHAD: So let's talk more about the ethics or the biases that can be baked into AI. How do you prevent that at Aitomatic?

+ +

CHRISTOPHER: As I said, this is a big topic. But let me begin by saying that actually, most of us don't know what we mean when we say bias, or to put it more broadly, we don't agree on the meaning. The word bias in colloquial conversation always comes with a negative connotation on the one hand. On the other hand, in machine learning, bias is inherent. You cannot have machine work without bias. So clearly, those two words must mean something slightly different even though they reflect the same thing, the same underlying physics, if you will.

+ +

So first, before people get into what they think is a very well-informed debate, they must first agree on a framework for terms that they're using. Now, of course, I can accommodate and say, okay, I think I know what you mean by that term. And so, let's take the colloquial meaning of bias. And when we say bias, we usually mean some built-in prejudice, it may be implicit, or it may be explicit that causes a human or machine to make a decision that discriminates against someone.

+ +

And here's the thing, we've got to think about intent versus impact. Is it okay for the effect to be quote, unquote, "biased" if I didn't intend it, or it doesn't matter what my intent was, and it's only the impact that matters? That's another dimension that people have to agree or even agree to disagree on before they start going into these circular arguments. But let's focus on, for now, let's say it's the impact that matters. It doesn't matter what the intent is, particularly because machines, as of present, there is no intent.

+ +

So, for example, when the Uber vehicle a number of years ago hit and killed a bicyclist, there was no traceable intent, certainly not in the system design to cause that to happen. But yet it happened, and the person did die. So coming back to your question, I know that I've neglected the question because I'm unpacking a lot of things that otherwise an answer would make no sense, or it would not have the sense meant.

+ +

So coming back, how do we prevent bias as an effect from happening in our system? And an answer that I would propose is to stop thinking about it in terms of point answers; in other words, it's not that...people say...well, myself I even said earlier it's in the data. Well, if it's in the data, does that absolve the people who build the algorithms? And if it's in the algorithms, does that absolve the people who use it? I had a conversation with some friends from Europe, and they said, "In America, you guys are so obsessed with blaming the user." Guns don't kill people; people kill people.

+ +

But I think to answer your question in a very thoughtful manner; we must first accept the responsibility throughout the entire chain and agree on what it is the outcome that we want to have, at least effect. And then the responsibility falls on all chains, all parts of the chain. And one day, it may be, hey, you got to tune the algorithm a certain way. Another day may be, hey, collect this kind of data.

+ +

And another day, it might be make sure that when you finally help with the decision, that you tweak it a certain way to affect the outcome that you want. I think what I've described is the most intellectually honest statement. And somebody listening to this is going to have a perspective that disagrees vehemently with one of the things I just said because they don't want that responsibility.

+ +

CHAD: I like it, though, because it recognizes that we're creating it. It may be a tool, and tools can be used for anything. But as the creators of that tool, we do have responsibility for...well, I think we have responsibility for what that is going to do, and if not us, then who?

+ +

CHRISTOPHER: That's right. Yeah. But if you follow the debate, you will find that there are absolutists who say, "That's not my problem. That's the user, or the decision-maker, or the data provider. But my algorithms I have to optimize in this way, and it's going to output exactly what the data told it to. The rest is your problem."

+ +

CHAD: So it strikes me in hearing you describe what's involved, especially at the state that machine learning is at now; it probably varies or what you are going to do specifically varies based on what you're trying to achieve. And maybe even the industry that it's in like avionics and what you need to do there may be different than energy.

+ +

CHRISTOPHER: Yep, or more broadly, physical industries versus the plane falls out of the air, or a car hits somebody, somebody actually dies. If you get a particular algorithm wrong at Google, maybe you click on the wrong ad. So I really advocate thinking about the impact and not just the basic algorithms.

+ +

CHAD: Yeah, so tell me more about the actual product or services that Aitomatic provides and also who the customers are.

+ +

CHRISTOPHER: I think what we discussed is quite relevant to that. I think it does lead in a very real perspective directly into that. We do what's called knowledge-first AI. And that knowledge-first as opposed to knowledge-second and knowledge-third or no knowledge at all, there are very strong schools of thought that say, "With sufficient data, we can create AI to do everything." Data is reflecting the world. As I mentioned, it's in the past as it is, not as what we want it to be.

+ +

When you apply it to some of the concrete things that we do, let's take a use case like predictive maintenance of equipment, you want to be able to save cost and even to save lives. You want to replace things, service things before they actually fail. Failure is very costly. It's far more costly than the equipment itself. Today, the state of the art is preventive maintenance, not predictive. Preventive means, let’s just every six months, every one year replace all the lights because it's too costly to replace them one by one when they fail.

+ +

Lots of industries today still do what's called reactive maintenance, you know, fix it when it fails. So predictive maintenance is the state of the art. The challenge is how do you get data and train enough machine intelligence to essentially predict? And the prediction precisely means the following: can you tell me with some probability that this compressor for this HVAC system, this air conditioning system may fail within the next month? And it turns out machine learning cannot do that.

+ +

CHAD: Oh, that's the twist.

+ +

CHRISTOPHER: Exactly. [laughter] And I know a lot of people listening are going to sit up and say, "Christopher doesn't know what the hell he's talking about."

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: But I really know. I really know what the hell I'm talking about because we've been part of an industrial giant. I'll tell you what machine learning can do and what it cannot do. What it can do is with the data that's available...the main punch line, the main reason here is that there are not enough past examples of actual failures of certain types.

+ +

There's a lot of data. We're swimming in data, but we're not actually swimming in cleanly recorded failures that are well classified. And machine learning is about learning from past examples, except today, algorithms need a lot of past examples, tens of thousands, hundreds of thousands, or even millions of past examples, in order for it to discover those repeating patterns.

+ +

So we have a lot of data at places like Panasonic, Samsung, Intel, GE, all the physical industries, but these are just sensor data that's recording mostly normal operation. When a failure happens, that tends to be rare. Hopefully, failures are rare, and then they're very specific. So it turns out that what's called the labeled data is insufficient for machine learning.

+ +

So what machine learning can do is do what's called anomaly detection. And that is look at all the normal patterns, and then when something abnormal appears on the horizon to say, "Hey, something is weird. I haven't seen this before." But it cannot identify what it is, which is only half of predictive maintenance because you have to identify what the problem is so you can replace that compressor or that filter. And it turns out humans are very good. Human experts are very good at that second part.

+ +

The first improvement might be to say let's get machine learning to detect anomalies and then let's get human experts to actually do fault prediction. And after you do this for a while, which is what we did at Panasonic in the last three, four years across the global AI units, we said, "Well, wait a minute. Why are we making these very expensive?" Human experts do this if we can somehow codify their domain expertise. And so that's what Aitomatic is. We have developed a bunch of techniques, algorithms, and systems that run as SaaS software to help people codify their domain expertise, combine it with machine learning, and then deploy the whole thing as a system.

+ +

CHAD: The codified expertise, there's a word for that, right?

+ +

CHRISTOPHER: Probably you're referring to expert systems.

+ +

CHAD: Yes. Yes.

+ +

CHRISTOPHER: Yeah. Expert systems is one way to codify domain expertise. At the very basic level, you and I wrote actual BASIC programs before. You can think of that as codifying your human knowledge. You're telling the computer exactly what to do. So expert systems of the past is one way to do so. But what I'm referring to is a more evolved and more advanced perspective on that, which is how do you codify it in such a way that you can seamlessly combine with machine learning?

+ +

Expert systems and machine learning act like two islands that don't meet. But how do you do it in such a way that you can codify human knowledge and then benefit as more data comes in, absolutely move into this idea of asymptotically this world where data tells you everything? Which it never will. And so the way we do that, the naive way, as I mentioned, is simply to just write it down as a bunch of rules. And the problem is rules conflict with each other.

+ +

We, humans, work on heuristics. Whatever it is you tell me to do, you could be an expert, and you start teaching me, and you say, "Okay, so here are the rules." And then once I learn the rules, you say, "Well, and there are some exceptions." [laughs] And then, can you tell me all the exceptions? No, you can't. You have to use judgment. Okay, well, what is that? So the way we codify it is you can think of that evolution. I'll give you one concrete example from the machine learning perspective so people that are machine learning experts can see how we do things that are different. There's something in the machine learning process called the loss function. Have you heard of that term?

+ +

CHAD: No. Yeah.

+ +

CHRISTOPHER: So it's very simple. Training, which I'm sure everybody has heard, is really about how do I tweak the parameters inside the algorithm so that eventually, it gives the correct answer? So this process is repeated millions of times or hundreds of thousands of times. But let's say the first time, it gives you a random answer, but you know what the right answer should be. These are training examples.

+ +

So you compute an error. If you output a five and the answer is actually six, so I say, "Oh, you're off by one, positive one," and so on. So there's a loss function, and in this case, it's simply the subtraction of one. And then that signal, that number one, is somehow fed back into the training system that says, "Well, you were close, but you're off by one." And the next time, maybe you're off by 0.5, next time maybe you're off by -2, and so on and so forth. That value is computable, what's called a loss function. That's machine learning because you have all these examples.

+ +

Well, human knowledge can be applied as a loss function too. A simple example is that you don't have all the data examples, but you have a physical equation. If you throw a ball in the air, it follows a parabolic pattern, and we can model that exactly, an elliptic equation. That is a way to produce the correct answer, but there's no resistance there. And so, we can apply that function back as a loss function to encode that human knowledge.

+ +

Of course, things are not always as simple as a parabolic equation. But a human expert can say, "The temperature on this can never exceed 23. If it exceeds 23, life is going to end as we know it because you're going to have a disaster." You can put into the loss function an equation that says if your predictor is greater than 23, give it a very high loss. Give it a very strong signal that this cannot be. And so your machine learning function being trained can get that signal coming back and adjust the parameters appropriately. So that's just one example of how we codify human knowledge in a way that is more than just expert systems.

+ +

CHAD: That's really cool. Now, is there a way, once you have the system up and running and it is making decisions, to then feedback into that cycle and improve the model itself?

+ +

CHRISTOPHER: Oh, absolutely, yeah. I think there's a parallel to what I say during training to also while it's in production, both in real-time, meaning one example at a time, as well as in batch after you've done a bunch of these. In fact, the first successful predictive maintenance system we deployed when we were part of Panasonic employs a human being that they feedback at.

+ +

So our system would try to learn as much as it can and then try to predict the probability of failure of some piece of equipment. And the human being at the other end would say, "Okay, yeah, that looks reasonable." But a lot of times, they would say, "Clearly wrong. Look at this sensor over here. The pressure is high, and you didn't take that into account." So that's a process that we use both to certainly improve the output itself but also the feedback to improve our predictive AI.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So on the customer side, whether you can share specific customers or not, what kinds of companies are your customers?

+ +

CHRISTOPHER: So I've mentioned in passing a number, so Panasonic is one of our customers. When I say Panasonic, Panasonic is a global giant, so it's run as individual companies. So, for example, avionics automotive coaching, how a fish gets from the ocean to your table, Panasonic has a big market share in making sure that everywhere in the chain that fish is refrigerated. So it's called the cold supply chain or cold chain. Supermarkets their refrigeration systems keep our food fresh, and if that goes down in an unplanned manner, then they lose entire days or weeks of sales.

+ +

I mentioned the example of Furuno, F-U-R-U-N-O. If you go to some marina, say Half Moon Bay, California, you would see on the masts most of the navigation equipment is a Furuno, the white and blue logo. So we help them with those systems and fish finding systems. As well as off the coast of Japan, there's a practice called fixed-net fishing. What that is is miles and miles of netting. And large schools of fish would swim from different gates, A into B. And once they get to B, it's set in such a way that they cannot go back to A. But it's very large that they feel like they're swimming in the ocean still and eventually to trap C.

+ +

And so Furuno is working on techniques to both detect what kind of fish is flowing through as well as actually count or estimate the number so the fishermen can determine exactly when to go and collect their catch. So I can go on. There are lots of these really interesting physics-related and physical use cases.

+ +

CHAD: So is Aitomatic actually spun off from Panasonic?

+ +

CHRISTOPHER: Spin-off, I think legally speaking, that is not the correct term because we're independent. Panasonic does not own shares. But in terms of our working relationship as customer and vendor, it's as good as it ever was.

+ +

CHAD: What went into that decision-making process to do that?

+ +

CHRISTOPHER: To do the so-called spin-off?

+ +

CHAD: Yeah.

+ +

CHRISTOPHER: Lots of things.

+ +

CHAD: I'm sure it was a complicated decision. [laughs]

+ +

CHRISTOPHER: Like we used to say at Google, to decide where to put a data center, lots of things have to intersect just the right way, including the alignment of the stars. In our case, it's a number of things. Number one, the business model just, as I said, at a very high level, it makes a lot of sense for us to be an independent company otherwise inside a...if we're a small unit inside a parent company, the business incentives are very different from if you're a startup, that's one. And the change is positive for both sides.

+ +

Number two, in terms of venture capital, as you know, today, once you're an independent company, you can access a very large amount of scale in such a way that even a global giant doesn't have the same model to fund. Number three, certainly, the scope of the business we want to be able to apply...everything that I talk to you here is actually an open-source project.

+ +

We have something called human-first AI rather than just knowledge-first, and so being able to put it out into the open-source and being able to have other people contribute to it is much easier as an independent startup than if it's a business unit. And then finally, of course, aspirations, myself and the rest of the team, we can move a lot faster. People are more passionate about the ownership of what they do. It's a much better setup as an independent company.

+ +

CHAD: Were there things from Panasonic, either in culture or the way that the business works, that even though you had the opportunity to be independent, you said, "Hey, that was pretty good. Let's keep that going"?

+ +

CHRISTOPHER: Well, I can comment on the culture of Panasonic itself. It's something that I was surprised by. This is 100 years old. The anniversary was in 2018. I gave a talk in Tokyo. So a 100-year old conglomerate. Japan might seem very stodgy, and, sorry to say, in many ways, it is. But I was very impressed. And I say this as a headline in cocktail conversation. I say the culture of engineering at Panasonic is far more like the Google that I knew than it is different; in other words, very little empire-building. People are very engineering-driven. There are a lot of cordial discussions and so on when people go into a meeting. I was very impressed by this.

+ +

The Japanese engineers in Panasonic were always really well prepared. By the time they got to the meeting, even though they are in this context our customers, they will come with a slide deck like 30 slides talking through the entire use case. And they thought about this, they thought about that. And so I'm sitting there just absorbing it, just learning the whole thing. I really enjoyed that part of being part of Panasonic. And many of those folks are now lifelong friends of mine.

+ +

CHAD: And so that's something that you've tried to maintain, that engineering-focused culture and great place.

+ +

CHRISTOPHER: Well, when we were acquired by Panasonic, both Tsuga-san, the CEO, and Miyabe-san, the CTO, said the following, he said, "We want you to infect Panasonic, not the other way around." [laughs] From their perspective, we had this Silicon Valley setup. And they want this innovation, a fresh startup, not just the algorithms but also the culture. And they were true to their word. We kept an office, our own unit, kept their office in Downtown Mountain View. And folks were sent in to pick up our ways and means. What I enjoyed, the part that I just shared with you, is what I didn't expect to learn but what I did learn in retrospect.

+ +

CHAD: As you set out on everything you want to achieve, what are you worried about? What do you think the biggest hurdles are going to be that you need to overcome to make a successful business, successful product?

+ +

CHRISTOPHER: Well, I've done this multiple times. So people like to say, "You've seen this movie before," but of course, every movie is told differently, and the scenes are different, the actors are different, and so on. Of course, the times are different. So concretely, our immediate next hurdle you have to have proof points along the way. So we've got good revenues already. As a startup less than one-year-old, we have unusually good revenues but mainly because of our deep relationships in this particular industry.

+ +

The next concrete proof point is a series of things, metrics that says we have a good product-market fit. And, of course, product-market fit means more than just a great product idea. It's a great product idea that is executed in a way that the market wants it in the next quarter, not ten years from now. So product-market fit is that iteration, and we're quite fortunate to have already customers what we call design partners that we work with. So hearing from that diverse set is pretty good confidence that if they want it, then other people will want it as well.

+ +

And then after that, certainly after in timing but in the doing now, is scaling our sales efforts, our sales volume beyond just the founder-led volume that we currently have, so building the sales team and so on. But these are things that I will say are generally understood. But it does have to still be; you just got to sweat it. You got to do it. It doesn't happen automatically. I think the much bigger challenge that I see, and maybe it's an opportunity depending on how you think about it, is I'll call it a cultural barrier. Silicon Valley, in particular, the academic side of us...and you may know I used to be a professor, so when I say academic, I'm talking about myself as well. So any criticism is self-directed.

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: We tend to be purists. The purism of today, if I can use that term, is data. And so, whenever I talk about knowledge-first AI, it offends the sensibilities of some people. They say, "You mean you're going back to expert systems. You mean you are not going to be extolling the virtues of machine learning and so on." And I have to explain data is nice if you have it, but 90% of the world doesn't have the data. And you do need to come up with these new techniques to combine human knowledge with machine learning.

+ +

We look forward to being the Vanguard of that revolution, if you will, that say maybe it's a step backward. I think of it as a step forward of really harmoniously combining human knowledge and machine data to build what we call AI systems, these powerful systems that we're purporting to build. And that's almost directly at odds with the school of thought where people say, "Eventually, we'll have all the data." [laughs] And maybe, as you stated at the beginning, we don't need humans anymore. I will fight that battle.

+ +

CHAD: The customers that you talked about, a lot of them seem to be pretty big enterprises. So as you talk about scaling sales beyond the founder-led sales that you're doing now, are you continuing to sell to enterprises? Or do you ultimately envision the product being accessible to any company?

+ +

CHRISTOPHER: Well, I would say both. But I say that in a very careful sense because it's very important building businesses with a focus. And so let me break down what I mean by both, not just from some ambitious thing, you know, A and B. We will focus on enterprise as a matter of business. And the reason for that is A, that's where the money is but B, but more importantly, it's also where the readiness is. We've gone through...it's amazing. It's been a decade since that first New York Times, what I call the cats’ paper about the Google Brain Project.

+ +

We've gone through a decade of the hype and everything, but this vast physical industry, the industrial of the world, is ready. When I say ready, it means that people are now sophisticated. They don't look at it with wide eyes and say, "Please sprinkle a little bit of AI on my system." So they have teams, and they can benefit from what we do at the scale of what I've just described. But the reason I say both is because, quite happily, it is an open-source project.

+ +

Our roadmap is designed with our design partners, but once it's out there, the system can be contributed to by others. The nature of open source is such that people tend to use it more than contribute. That's fine. So I think a lot of the smaller companies and smaller teams, once they overcome this cultural barrier of applying knowledge as opposed to pure data, I think they can really take advantage of our technology.

+ +

CHAD: I'm glad you segued there because I was going to bring us there, too, which is that that open source that you've made available was it ever a question whether you could build a business where you were also open-sourcing the software behind it?

+ +

CHRISTOPHER: It was absolutely a question 10 years ago. The industry has evolved. And now you and I talked about the TI-99/4A. I was already writing what's called public domain software before the term open source. Ten years ago, CIOs would say, "Why would I do away with the relationship with a big company like a Microsoft or an Oracle in favor of this unreliable, unknown open source?" It turns out, as we now look back, it was nothing to do with the business model; it was the immaturity of open source.

+ +

Today, it is the opposite. Today, people don't worry about the lock-in with a vendor whose source code that they don't have. But I think equally important, source code is no longer a competitive advantage. Let me say that again. Source code is no longer that intellectual property. CIOs today want to be able to have the peace of mind that if some company locks them out or the company becomes defunct, that the engineers still have access to that source code so that they can build it. But that is not the real value.

+ +

Amazon, Microsoft Azure, and GCP, Google have proven that people are very willing to pay for some experts to run operationally these systems so that they can concentrate on what they do best. So every day today, you know, every month, we're sending checks to AWS. They're running something that my team can easily run but probably at a much higher cost. But even at cost parity, I would like my team members to be focused on knowledge-first AI rather than the running of an email system or the running of some compute.

+ +

So likewise, the value that our customers get from us is not the source code. But they're very willing for us to run this big industrial AI system so that they can focus on the actual work of codifying their expert knowledge. And by the way, I probably gave too long an answer to that. Another way is simply to look at the public market; there are very well rewarded companies that are entirely open source.

+ +

CHAD: Yeah. Well, thank you. That was great. Thank you for stopping by and sharing with me. I really appreciate it. If folks want to find out more about Aitomatic or get in touch with you or follow along, where are all the places that they can do that?

+ +

CHRISTOPHER: I think the website, aitomatic.com And it's just like automatic, except that it starts with A-I-. So I think the website is a great place to start to contact us.

+ +

CHAD: Wonderful. Thank you again.

+ +

CHRISTOPHER: Awesome. Thank you.

+ +

CHAD: You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Christopher Nguyen .

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Christopher Nguyen is the CEO of Aitomatic, which provides knowledge-first AI for industrial automation.

+ +

Chad talks with Christopher about why having a physical sciences background matters for this work, if we have artificial intelligence, why we still need people, and working in knowledge-first AI instead of knowledge-second, knowledge-third, or no knowledge at all. Data reflects the world.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Christopher Nguyen, CEO of Aitomatic, which provides knowledge-first AI for industrial automation. Christopher, thanks for joining me.

+ +

CHRISTOPHER: Thank you.

+ +

CHAD: So I was prepping for this interview, and I noticed something that jumped out at me that we have in common, and that is your first computer was the TI-99C/4A.

+ +

CHRISTOPHER: No kidding.

+ +

CHAD: And that was also my first computer.

+ +

CHRISTOPHER: Oh, okay.

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: You got no storage, correct?

+ +

CHAD: No storage; everything was off of the solid-state disks. And I remember I was a little late to it. My parents actually got it for me. I think I was 9 or 10. And my parents got it for me at a garage sale. And so all I had was the manual and the basic manual that came with it. And because it had no storage, I needed to type in the programs that were in the back of that book from scratch, and there was no way to save them. So you would type them in -- [laughs]

+ +

CHRISTOPHER: Oh my God. Every single day the same code over and over again. And hopefully, you don't turn it off.

+ +

CHAD: [laughs] Exactly. There definitely were times where it would just be on in my room because I didn't want to lose what I had spent all day typing in.

+ +

CHRISTOPHER: Yeah, yeah, I remember my proudest moment was my sister walked into the living room...and there was no monitor, and you connected it directly to the TV.

+ +

CHAD: To the TV, yeah.

+ +

CHRISTOPHER: And younger people may not even know the term character graphics, which is you pick in your book the character space, and then you put them together into a graphic image. And I painstakingly, on graph paper, created a car and converted it to hex and then poked it into these characters and put them together. And my sister walked in like, "Oh my God, you made a car."

+ +

[laughter]

+ +

CHAD: That was a good time. It was difficult back then. I feel like I learned a lot in an environment where I see people learning. Today it's a lot more of a complicated environment. They're much higher up the stack than we were back then. And, I don't know, I feel like I actually sort of had it easy.

+ +

CHRISTOPHER: Well, in many ways, that very abstraction to...you see jobs like to talk about higher software abstraction to make you more productive. I think it's absolutely that powerful. And Marc Andreessen, my friend, likes to talk about how software is eating the world. But it turns out there's one perspective where people have gone up the stack a little too far, too fast, and too much. We're still physical in the industry that I work in.

+ +

You know, our previous company was acquired by Panasonic. And I've been working on industrial AI for the last four and a half years. And it's very hard for us to find people with the right physics or electro engineering background and the right science understanding to help automate and build some of these systems because everybody's in software now.

+ +

CHAD: Why does physical sciences background matter for this work?

+ +

CHRISTOPHER: Let me give you a couple of examples. One example is one of our customers is a very large global conglomerate doing marine navigation and marine sensors. And one of the products they do is fish finding so that amateurs like you and me would go hold one of these systems and shoot it down straight to the ocean. A sonar beam goes down, kind of like submarines. But hopefully, an image would come back. And so to build a system to convert all of that into something other than jumbled what they call echograms, maybe convert to a fish image, you have to build a lot of machine intelligence, AI, machine learning, and so on.

+ +

But just to understand the data and make the right decisions about how to do that, you need to understand the physics of sound wave echoes in the ocean. If you can't do that and you got to work with another engineer to tell you how to do that, it really slows things down a lot. So knowing the equation but also having a physical intuition for how it all works can make or break the success of an engineer working on something like that.

+ +

Another example is we worked on avionics. Don't blame me for this, but if you have had poor experience with Wi-Fi on a plane, we may be involved in one way or another, Panasonic Avionics.

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: But the antenna array that sits on top of the plane to receive satellite signal and sends out a signal, so you can expect there's some kind of optimization involved. It's not just line of sight. If there's a cloud coming nearby, then there's some distortion, and there's some optimization needed to take place. Again, an understanding of...at least if you remember, if not an expert in college physics, about antenna radiation pattern and so on, which help tremendously a data scientist or an engineer working on that problem whereas somebody who's a pure computer scientist would struggle a lot and probably give up with that problem.

+ +

CHAD: Yeah, this may be a little bit of a facetious question or leading question; I'm not sure which, but if we have artificial intelligence, why do we need people to do this stuff?

+ +

CHRISTOPHER: [laughs] Well, I have a broader, you know, I've thought about that a lot. And I'll answer it in the broad sense, but I think you can specialize it. The problem with machine learning, at least today and I really think for a very long time for the rest of the century at least, is that it is trained on data. And data is past examples. And when I say past, I include the present. In other words, whatever it is that our algorithms learn, they learn the world as it is.

+ +

Now, we're always trying to change the world in some way. We're always trying to change the world to what we wish it to be, not what it is. And so it's the humans that express that aspiration. I want my machine to behave better in some way. Or I want my algorithms not to have this built-in bias when it makes a decision that affects someone's life.

+ +

If it's pure machine learning and data, it will indeed reflect all the decisions that have ever been made, and it'll have all those built-in biases. So there's a big topic there to unpack and who's responsible for doing what. But I think coming back to your question, we'll always need humans to express what it is that is the world that you want in the next minute, the next day, the next week, or the next 50 years.

+ +

CHAD: So let's talk more about the ethics or the biases that can be baked into AI. How do you prevent that at Aitomatic?

+ +

CHRISTOPHER: As I said, this is a big topic. But let me begin by saying that actually, most of us don't know what we mean when we say bias, or to put it more broadly, we don't agree on the meaning. The word bias in colloquial conversation always comes with a negative connotation on the one hand. On the other hand, in machine learning, bias is inherent. You cannot have machine work without bias. So clearly, those two words must mean something slightly different even though they reflect the same thing, the same underlying physics, if you will.

+ +

So first, before people get into what they think is a very well-informed debate, they must first agree on a framework for terms that they're using. Now, of course, I can accommodate and say, okay, I think I know what you mean by that term. And so, let's take the colloquial meaning of bias. And when we say bias, we usually mean some built-in prejudice, it may be implicit, or it may be explicit that causes a human or machine to make a decision that discriminates against someone.

+ +

And here's the thing, we've got to think about intent versus impact. Is it okay for the effect to be quote, unquote, "biased" if I didn't intend it, or it doesn't matter what my intent was, and it's only the impact that matters? That's another dimension that people have to agree or even agree to disagree on before they start going into these circular arguments. But let's focus on, for now, let's say it's the impact that matters. It doesn't matter what the intent is, particularly because machines, as of present, there is no intent.

+ +

So, for example, when the Uber vehicle a number of years ago hit and killed a bicyclist, there was no traceable intent, certainly not in the system design to cause that to happen. But yet it happened, and the person did die. So coming back to your question, I know that I've neglected the question because I'm unpacking a lot of things that otherwise an answer would make no sense, or it would not have the sense meant.

+ +

So coming back, how do we prevent bias as an effect from happening in our system? And an answer that I would propose is to stop thinking about it in terms of point answers; in other words, it's not that...people say...well, myself I even said earlier it's in the data. Well, if it's in the data, does that absolve the people who build the algorithms? And if it's in the algorithms, does that absolve the people who use it? I had a conversation with some friends from Europe, and they said, "In America, you guys are so obsessed with blaming the user." Guns don't kill people; people kill people.

+ +

But I think to answer your question in a very thoughtful manner; we must first accept the responsibility throughout the entire chain and agree on what it is the outcome that we want to have, at least effect. And then the responsibility falls on all chains, all parts of the chain. And one day, it may be, hey, you got to tune the algorithm a certain way. Another day may be, hey, collect this kind of data.

+ +

And another day, it might be make sure that when you finally help with the decision, that you tweak it a certain way to affect the outcome that you want. I think what I've described is the most intellectually honest statement. And somebody listening to this is going to have a perspective that disagrees vehemently with one of the things I just said because they don't want that responsibility.

+ +

CHAD: I like it, though, because it recognizes that we're creating it. It may be a tool, and tools can be used for anything. But as the creators of that tool, we do have responsibility for...well, I think we have responsibility for what that is going to do, and if not us, then who?

+ +

CHRISTOPHER: That's right. Yeah. But if you follow the debate, you will find that there are absolutists who say, "That's not my problem. That's the user, or the decision-maker, or the data provider. But my algorithms I have to optimize in this way, and it's going to output exactly what the data told it to. The rest is your problem."

+ +

CHAD: So it strikes me in hearing you describe what's involved, especially at the state that machine learning is at now; it probably varies or what you are going to do specifically varies based on what you're trying to achieve. And maybe even the industry that it's in like avionics and what you need to do there may be different than energy.

+ +

CHRISTOPHER: Yep, or more broadly, physical industries versus the plane falls out of the air, or a car hits somebody, somebody actually dies. If you get a particular algorithm wrong at Google, maybe you click on the wrong ad. So I really advocate thinking about the impact and not just the basic algorithms.

+ +

CHAD: Yeah, so tell me more about the actual product or services that Aitomatic provides and also who the customers are.

+ +

CHRISTOPHER: I think what we discussed is quite relevant to that. I think it does lead in a very real perspective directly into that. We do what's called knowledge-first AI. And that knowledge-first as opposed to knowledge-second and knowledge-third or no knowledge at all, there are very strong schools of thought that say, "With sufficient data, we can create AI to do everything." Data is reflecting the world. As I mentioned, it's in the past as it is, not as what we want it to be.

+ +

When you apply it to some of the concrete things that we do, let's take a use case like predictive maintenance of equipment, you want to be able to save cost and even to save lives. You want to replace things, service things before they actually fail. Failure is very costly. It's far more costly than the equipment itself. Today, the state of the art is preventive maintenance, not predictive. Preventive means, let’s just every six months, every one year replace all the lights because it's too costly to replace them one by one when they fail.

+ +

Lots of industries today still do what's called reactive maintenance, you know, fix it when it fails. So predictive maintenance is the state of the art. The challenge is how do you get data and train enough machine intelligence to essentially predict? And the prediction precisely means the following: can you tell me with some probability that this compressor for this HVAC system, this air conditioning system may fail within the next month? And it turns out machine learning cannot do that.

+ +

CHAD: Oh, that's the twist.

+ +

CHRISTOPHER: Exactly. [laughter] And I know a lot of people listening are going to sit up and say, "Christopher doesn't know what the hell he's talking about."

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: But I really know. I really know what the hell I'm talking about because we've been part of an industrial giant. I'll tell you what machine learning can do and what it cannot do. What it can do is with the data that's available...the main punch line, the main reason here is that there are not enough past examples of actual failures of certain types.

+ +

There's a lot of data. We're swimming in data, but we're not actually swimming in cleanly recorded failures that are well classified. And machine learning is about learning from past examples, except today, algorithms need a lot of past examples, tens of thousands, hundreds of thousands, or even millions of past examples, in order for it to discover those repeating patterns.

+ +

So we have a lot of data at places like Panasonic, Samsung, Intel, GE, all the physical industries, but these are just sensor data that's recording mostly normal operation. When a failure happens, that tends to be rare. Hopefully, failures are rare, and then they're very specific. So it turns out that what's called the labeled data is insufficient for machine learning.

+ +

So what machine learning can do is do what's called anomaly detection. And that is look at all the normal patterns, and then when something abnormal appears on the horizon to say, "Hey, something is weird. I haven't seen this before." But it cannot identify what it is, which is only half of predictive maintenance because you have to identify what the problem is so you can replace that compressor or that filter. And it turns out humans are very good. Human experts are very good at that second part.

+ +

The first improvement might be to say let's get machine learning to detect anomalies and then let's get human experts to actually do fault prediction. And after you do this for a while, which is what we did at Panasonic in the last three, four years across the global AI units, we said, "Well, wait a minute. Why are we making these very expensive?" Human experts do this if we can somehow codify their domain expertise. And so that's what Aitomatic is. We have developed a bunch of techniques, algorithms, and systems that run as SaaS software to help people codify their domain expertise, combine it with machine learning, and then deploy the whole thing as a system.

+ +

CHAD: The codified expertise, there's a word for that, right?

+ +

CHRISTOPHER: Probably you're referring to expert systems.

+ +

CHAD: Yes. Yes.

+ +

CHRISTOPHER: Yeah. Expert systems is one way to codify domain expertise. At the very basic level, you and I wrote actual BASIC programs before. You can think of that as codifying your human knowledge. You're telling the computer exactly what to do. So expert systems of the past is one way to do so. But what I'm referring to is a more evolved and more advanced perspective on that, which is how do you codify it in such a way that you can seamlessly combine with machine learning?

+ +

Expert systems and machine learning act like two islands that don't meet. But how do you do it in such a way that you can codify human knowledge and then benefit as more data comes in, absolutely move into this idea of asymptotically this world where data tells you everything? Which it never will. And so the way we do that, the naive way, as I mentioned, is simply to just write it down as a bunch of rules. And the problem is rules conflict with each other.

+ +

We, humans, work on heuristics. Whatever it is you tell me to do, you could be an expert, and you start teaching me, and you say, "Okay, so here are the rules." And then once I learn the rules, you say, "Well, and there are some exceptions." [laughs] And then, can you tell me all the exceptions? No, you can't. You have to use judgment. Okay, well, what is that? So the way we codify it is you can think of that evolution. I'll give you one concrete example from the machine learning perspective so people that are machine learning experts can see how we do things that are different. There's something in the machine learning process called the loss function. Have you heard of that term?

+ +

CHAD: No. Yeah.

+ +

CHRISTOPHER: So it's very simple. Training, which I'm sure everybody has heard, is really about how do I tweak the parameters inside the algorithm so that eventually, it gives the correct answer? So this process is repeated millions of times or hundreds of thousands of times. But let's say the first time, it gives you a random answer, but you know what the right answer should be. These are training examples.

+ +

So you compute an error. If you output a five and the answer is actually six, so I say, "Oh, you're off by one, positive one," and so on. So there's a loss function, and in this case, it's simply the subtraction of one. And then that signal, that number one, is somehow fed back into the training system that says, "Well, you were close, but you're off by one." And the next time, maybe you're off by 0.5, next time maybe you're off by -2, and so on and so forth. That value is computable, what's called a loss function. That's machine learning because you have all these examples.

+ +

Well, human knowledge can be applied as a loss function too. A simple example is that you don't have all the data examples, but you have a physical equation. If you throw a ball in the air, it follows a parabolic pattern, and we can model that exactly, an elliptic equation. That is a way to produce the correct answer, but there's no resistance there. And so, we can apply that function back as a loss function to encode that human knowledge.

+ +

Of course, things are not always as simple as a parabolic equation. But a human expert can say, "The temperature on this can never exceed 23. If it exceeds 23, life is going to end as we know it because you're going to have a disaster." You can put into the loss function an equation that says if your predictor is greater than 23, give it a very high loss. Give it a very strong signal that this cannot be. And so your machine learning function being trained can get that signal coming back and adjust the parameters appropriately. So that's just one example of how we codify human knowledge in a way that is more than just expert systems.

+ +

CHAD: That's really cool. Now, is there a way, once you have the system up and running and it is making decisions, to then feedback into that cycle and improve the model itself?

+ +

CHRISTOPHER: Oh, absolutely, yeah. I think there's a parallel to what I say during training to also while it's in production, both in real-time, meaning one example at a time, as well as in batch after you've done a bunch of these. In fact, the first successful predictive maintenance system we deployed when we were part of Panasonic employs a human being that they feedback at.

+ +

So our system would try to learn as much as it can and then try to predict the probability of failure of some piece of equipment. And the human being at the other end would say, "Okay, yeah, that looks reasonable." But a lot of times, they would say, "Clearly wrong. Look at this sensor over here. The pressure is high, and you didn't take that into account." So that's a process that we use both to certainly improve the output itself but also the feedback to improve our predictive AI.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So on the customer side, whether you can share specific customers or not, what kinds of companies are your customers?

+ +

CHRISTOPHER: So I've mentioned in passing a number, so Panasonic is one of our customers. When I say Panasonic, Panasonic is a global giant, so it's run as individual companies. So, for example, avionics automotive coaching, how a fish gets from the ocean to your table, Panasonic has a big market share in making sure that everywhere in the chain that fish is refrigerated. So it's called the cold supply chain or cold chain. Supermarkets their refrigeration systems keep our food fresh, and if that goes down in an unplanned manner, then they lose entire days or weeks of sales.

+ +

I mentioned the example of Furuno, F-U-R-U-N-O. If you go to some marina, say Half Moon Bay, California, you would see on the masts most of the navigation equipment is a Furuno, the white and blue logo. So we help them with those systems and fish finding systems. As well as off the coast of Japan, there's a practice called fixed-net fishing. What that is is miles and miles of netting. And large schools of fish would swim from different gates, A into B. And once they get to B, it's set in such a way that they cannot go back to A. But it's very large that they feel like they're swimming in the ocean still and eventually to trap C.

+ +

And so Furuno is working on techniques to both detect what kind of fish is flowing through as well as actually count or estimate the number so the fishermen can determine exactly when to go and collect their catch. So I can go on. There are lots of these really interesting physics-related and physical use cases.

+ +

CHAD: So is Aitomatic actually spun off from Panasonic?

+ +

CHRISTOPHER: Spin-off, I think legally speaking, that is not the correct term because we're independent. Panasonic does not own shares. But in terms of our working relationship as customer and vendor, it's as good as it ever was.

+ +

CHAD: What went into that decision-making process to do that?

+ +

CHRISTOPHER: To do the so-called spin-off?

+ +

CHAD: Yeah.

+ +

CHRISTOPHER: Lots of things.

+ +

CHAD: I'm sure it was a complicated decision. [laughs]

+ +

CHRISTOPHER: Like we used to say at Google, to decide where to put a data center, lots of things have to intersect just the right way, including the alignment of the stars. In our case, it's a number of things. Number one, the business model just, as I said, at a very high level, it makes a lot of sense for us to be an independent company otherwise inside a...if we're a small unit inside a parent company, the business incentives are very different from if you're a startup, that's one. And the change is positive for both sides.

+ +

Number two, in terms of venture capital, as you know, today, once you're an independent company, you can access a very large amount of scale in such a way that even a global giant doesn't have the same model to fund. Number three, certainly, the scope of the business we want to be able to apply...everything that I talk to you here is actually an open-source project.

+ +

We have something called human-first AI rather than just knowledge-first, and so being able to put it out into the open-source and being able to have other people contribute to it is much easier as an independent startup than if it's a business unit. And then finally, of course, aspirations, myself and the rest of the team, we can move a lot faster. People are more passionate about the ownership of what they do. It's a much better setup as an independent company.

+ +

CHAD: Were there things from Panasonic, either in culture or the way that the business works, that even though you had the opportunity to be independent, you said, "Hey, that was pretty good. Let's keep that going"?

+ +

CHRISTOPHER: Well, I can comment on the culture of Panasonic itself. It's something that I was surprised by. This is 100 years old. The anniversary was in 2018. I gave a talk in Tokyo. So a 100-year old conglomerate. Japan might seem very stodgy, and, sorry to say, in many ways, it is. But I was very impressed. And I say this as a headline in cocktail conversation. I say the culture of engineering at Panasonic is far more like the Google that I knew than it is different; in other words, very little empire-building. People are very engineering-driven. There are a lot of cordial discussions and so on when people go into a meeting. I was very impressed by this.

+ +

The Japanese engineers in Panasonic were always really well prepared. By the time they got to the meeting, even though they are in this context our customers, they will come with a slide deck like 30 slides talking through the entire use case. And they thought about this, they thought about that. And so I'm sitting there just absorbing it, just learning the whole thing. I really enjoyed that part of being part of Panasonic. And many of those folks are now lifelong friends of mine.

+ +

CHAD: And so that's something that you've tried to maintain, that engineering-focused culture and great place.

+ +

CHRISTOPHER: Well, when we were acquired by Panasonic, both Tsuga-san, the CEO, and Miyabe-san, the CTO, said the following, he said, "We want you to infect Panasonic, not the other way around." [laughs] From their perspective, we had this Silicon Valley setup. And they want this innovation, a fresh startup, not just the algorithms but also the culture. And they were true to their word. We kept an office, our own unit, kept their office in Downtown Mountain View. And folks were sent in to pick up our ways and means. What I enjoyed, the part that I just shared with you, is what I didn't expect to learn but what I did learn in retrospect.

+ +

CHAD: As you set out on everything you want to achieve, what are you worried about? What do you think the biggest hurdles are going to be that you need to overcome to make a successful business, successful product?

+ +

CHRISTOPHER: Well, I've done this multiple times. So people like to say, "You've seen this movie before," but of course, every movie is told differently, and the scenes are different, the actors are different, and so on. Of course, the times are different. So concretely, our immediate next hurdle you have to have proof points along the way. So we've got good revenues already. As a startup less than one-year-old, we have unusually good revenues but mainly because of our deep relationships in this particular industry.

+ +

The next concrete proof point is a series of things, metrics that says we have a good product-market fit. And, of course, product-market fit means more than just a great product idea. It's a great product idea that is executed in a way that the market wants it in the next quarter, not ten years from now. So product-market fit is that iteration, and we're quite fortunate to have already customers what we call design partners that we work with. So hearing from that diverse set is pretty good confidence that if they want it, then other people will want it as well.

+ +

And then after that, certainly after in timing but in the doing now, is scaling our sales efforts, our sales volume beyond just the founder-led volume that we currently have, so building the sales team and so on. But these are things that I will say are generally understood. But it does have to still be; you just got to sweat it. You got to do it. It doesn't happen automatically. I think the much bigger challenge that I see, and maybe it's an opportunity depending on how you think about it, is I'll call it a cultural barrier. Silicon Valley, in particular, the academic side of us...and you may know I used to be a professor, so when I say academic, I'm talking about myself as well. So any criticism is self-directed.

+ +

CHAD: [laughs]

+ +

CHRISTOPHER: We tend to be purists. The purism of today, if I can use that term, is data. And so, whenever I talk about knowledge-first AI, it offends the sensibilities of some people. They say, "You mean you're going back to expert systems. You mean you are not going to be extolling the virtues of machine learning and so on." And I have to explain data is nice if you have it, but 90% of the world doesn't have the data. And you do need to come up with these new techniques to combine human knowledge with machine learning.

+ +

We look forward to being the Vanguard of that revolution, if you will, that say maybe it's a step backward. I think of it as a step forward of really harmoniously combining human knowledge and machine data to build what we call AI systems, these powerful systems that we're purporting to build. And that's almost directly at odds with the school of thought where people say, "Eventually, we'll have all the data." [laughs] And maybe, as you stated at the beginning, we don't need humans anymore. I will fight that battle.

+ +

CHAD: The customers that you talked about, a lot of them seem to be pretty big enterprises. So as you talk about scaling sales beyond the founder-led sales that you're doing now, are you continuing to sell to enterprises? Or do you ultimately envision the product being accessible to any company?

+ +

CHRISTOPHER: Well, I would say both. But I say that in a very careful sense because it's very important building businesses with a focus. And so let me break down what I mean by both, not just from some ambitious thing, you know, A and B. We will focus on enterprise as a matter of business. And the reason for that is A, that's where the money is but B, but more importantly, it's also where the readiness is. We've gone through...it's amazing. It's been a decade since that first New York Times, what I call the cats’ paper about the Google Brain Project.

+ +

We've gone through a decade of the hype and everything, but this vast physical industry, the industrial of the world, is ready. When I say ready, it means that people are now sophisticated. They don't look at it with wide eyes and say, "Please sprinkle a little bit of AI on my system." So they have teams, and they can benefit from what we do at the scale of what I've just described. But the reason I say both is because, quite happily, it is an open-source project.

+ +

Our roadmap is designed with our design partners, but once it's out there, the system can be contributed to by others. The nature of open source is such that people tend to use it more than contribute. That's fine. So I think a lot of the smaller companies and smaller teams, once they overcome this cultural barrier of applying knowledge as opposed to pure data, I think they can really take advantage of our technology.

+ +

CHAD: I'm glad you segued there because I was going to bring us there, too, which is that that open source that you've made available was it ever a question whether you could build a business where you were also open-sourcing the software behind it?

+ +

CHRISTOPHER: It was absolutely a question 10 years ago. The industry has evolved. And now you and I talked about the TI-99/4A. I was already writing what's called public domain software before the term open source. Ten years ago, CIOs would say, "Why would I do away with the relationship with a big company like a Microsoft or an Oracle in favor of this unreliable, unknown open source?" It turns out, as we now look back, it was nothing to do with the business model; it was the immaturity of open source.

+ +

Today, it is the opposite. Today, people don't worry about the lock-in with a vendor whose source code that they don't have. But I think equally important, source code is no longer a competitive advantage. Let me say that again. Source code is no longer that intellectual property. CIOs today want to be able to have the peace of mind that if some company locks them out or the company becomes defunct, that the engineers still have access to that source code so that they can build it. But that is not the real value.

+ +

Amazon, Microsoft Azure, and GCP, Google have proven that people are very willing to pay for some experts to run operationally these systems so that they can concentrate on what they do best. So every day today, you know, every month, we're sending checks to AWS. They're running something that my team can easily run but probably at a much higher cost. But even at cost parity, I would like my team members to be focused on knowledge-first AI rather than the running of an email system or the running of some compute.

+ +

So likewise, the value that our customers get from us is not the source code. But they're very willing for us to run this big industrial AI system so that they can focus on the actual work of codifying their expert knowledge. And by the way, I probably gave too long an answer to that. Another way is simply to look at the public market; there are very well rewarded companies that are entirely open source.

+ +

CHAD: Yeah. Well, thank you. That was great. Thank you for stopping by and sharing with me. I really appreciate it. If folks want to find out more about Aitomatic or get in touch with you or follow along, where are all the places that they can do that?

+ +

CHRISTOPHER: I think the website, aitomatic.com And it's just like automatic, except that it starts with A-I-. So I think the website is a great place to start to contact us.

+ +

CHAD: Wonderful. Thank you again.

+ +

CHRISTOPHER: Awesome. Thank you.

+ +

CHAD: You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Christopher Nguyen .

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ZnvRYbse + + ]]> + + Chad Pytel + Christopher Nguyen + + + 417: Hume AI with Alan Cowen + https://podcast.thoughtbot.com/417 + 58b35029-db44-41f8-8368-c348cfaf06de + Thu, 07 Apr 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Dr. Alan Cowen is the Executive Director of The Hume Initiative, a non-profit dedicated to the responsible advancement of AI with empathy, and CEO of Hume AI, an AI research lab and empathetic AI company that is hoping to pave the way for AI that improves our emotional well-being. + +Chad talks with Alan about forming clear ethical guidelines around how this technology should be used because there is a problem in that the public is skeptical about whether technology is used for good or bad. The Hume Initiative is intended to lay out what concrete use cases will be and what use cases shouldn't be supported. Hume AI is built for developers to construct empathic abilities into their applications. + 40:22 + no + + + Dr. Alan Cowen is the Executive Director of The Hume Initiative (https://thehumeinitiative.org/), a non-profit dedicated to the responsible advancement of AI with empathy, and CEO of Hume AI (https://hume.ai/), an AI research lab and empathetic AI company that is hoping to pave the way for AI that improves our emotional well-being. +Chad talks with Alan about forming clear ethical guidelines around how this technology should be used because there is a problem in that the public is skeptical about whether technology is used for good or bad. The Hume Initiative is intended to lay out what concrete use cases will be and what use cases shouldn't be supported. Hume AI is built for developers to construct empathic abilities into their applications. +The Hume Initiative (https://thehumeinitiative.org/) +Hume AI (https://hume.ai/) +Follow Hume AI on Twitter (https://twitter.com/hume__ai) or LinkedIn (https://www.linkedin.com/company/hume-ai/). +Follow Alan on Twitter (https://twitter.com/AlanCowen) or LinkedIn (https://www.linkedin.com/in/alan-cowen/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dr. Alan Cowen, the Executive Director of The Hume Initiative, a non-profit dedicated to the responsible advancement of AI with empathy, and CEO of Hume AI, an AI research lab and empathetic AI company. Alan, thank you for joining me. +DR. COWEN: Thanks for having me on. +CHAD: That's a lot of words in that introduction. I'm glad I got through it in one take. Let's take a step back a little bit and talk about the two different things, The Hume Initiative and Hume AI. And what came first? +DR. COWEN: So they were conceptualized at the same time. Practically speaking, Hume AI was started first only because it currently is the sole supporter of The Hume Initiative. But they were both conceptualized as this way to adjust two of the main problems that people have faced bringing empathic abilities to technology. Technology needs to have empathic abilities. If AI is going to get smart enough to make decisions on our behalf, it should understand whether those decisions are good or bad for our well-being. And a big part of that is understanding people's emotions because emotions are really what determine our well-being. +The Hume Initiative addresses one of the challenges, which is the formation of clear ethical guidelines around how this technology should be used. And it's not because the companies pursuing this have bad intents; that's not the point at all. The problem is that the public is probably justifiably skeptical of whether this technology will be used for them or against them. And The Hume Initiative is intended as a way of laying out what the concrete use cases will be and what use cases shouldn't be supported. +Hume AI is introducing solutions to the problem of how we build empathic AI algorithms. And the challenge there has been the data. So there have been a lot of attempts at building empathic AI or emotion AI, whatever you call it, basically ways of reading facial expression, emotion in the voice, and language. And there's been a few challenges, but most of them come down to the fact that the data tends to be based on outdated theories of emotion and/or it tends to be based on people's perceptual ratings of images largely from the internet or videos that are collected in more of an observational way without experimental control. +And within those perceptual judgments, you see gender biases, sometimes racial biases, biases by what people are wearing, whether they're wearing sunglasses, for example, because people with sunglasses for some reason are perceived as being proud. [laughter] And the algorithms will always label people with sunglasses as being proud if you're training the algorithm that way. +What you need basically is some way to control for people's identity, what they're wearing, get people's own self-reports as to what they're feeling or what they're expressing, and do it in a way that's somewhat randomized so that different people express a wide range of emotional behaviors in a wide range of contexts. And the contexts are somewhat randomized. So that's what we're doing with Hume AI is we're gathering that data, and it requires large-scale experiments to be run around the world. +CHAD: In terms of the actual product that Hume AI is going to do, is it a standalone product? Or is it something that people building products will use? +DR. COWEN: It's a developer product. It's built for developers to build empathic abilities into their applications. And so we are about to launch a developer portal, and we have a waitlist on our website on hume.ai for that. In the meantime, we've been licensing out the models that we're training and the data that we're using to train those models, which I actually kind of view as somewhat interchangeable. Models are basically descriptions of data. Some people have the resources to train those models on-premise; some people don't. +But we're providing the solution to any developer who wants to build the ability to understand, for example, vocal expression into, say, a digital assistant. So can the digital assistant understand when you're frustrated and be able to change its response based on that information? And even potentially update the actual network, the neural network that's being used to generate that response, actually, backpropagate the fact that this was an unsatisfactory response and make the algorithm better. Is this something that you could use for health tech? +So people are building out telehealth solutions that incorporate AI in various ways, one of which is can we get an objective classification of emotional behavior that can be used to help triage patients, send them to the right place, put them in touch with the right help? Can it be used to sub-diagnose disorders, diagnose disorders with more statistical power? Because you can incorporate more data and develop better treatments for those disorders, and that can be done in a wide range of contexts. +CHAD: So you mentioned training AI models. I don't want to make the assumption that everyone knows what that means or looks like. Maybe if we could take a step back, if you don't mind, talk about what that maybe traditionally looks like and how Hume is actually different. +DR. COWEN: Yeah, totally. When it comes to empathic AI, so this is an area where you're trying to train an algorithm to measure facial movements insofar as they have distinct meanings or measure inflections of the voice while people are speaking to understand the non-verbal indications of emotion in the voice. When you are training an algorithm to do that, you're taking in images, video, audio, and you're predicting people as attributions of emotion to themselves or to others and what people are feeling or what people say they're expressing or what other people say they hear in an expression. You need a lot of data for that. +Traditionally, people have used smaller datasets and assumed that emotion can be reduced to a few categories. That's been one solution to this problem. And so basically, you'll have people pose facial expressions of anger, fear, happiness, sadness, disgust, and surprise, which are called the basic six emotions. And that was introduced by Paul Ekman in the 1970s. And there are whole datasets of people posing those six expressions or perhaps combinations of them. And usually, those facial expressions are front-lit and front-facing and meet certain constraints. +And when you train a model on that data, it doesn't tend to generalize very well to naturalistic expressions that you encounter from day-to-day for a lot of different reasons; one is that the six basic emotions only capture about 30% of what people perceive in an expression. Another is that people in everyday situations have a wide range of lighting conditions, viewpoints, et cetera. And there's more diversity in age, gender than you see in these datasets and in ethnicity and so forth. And so, these algorithms don't generalize. +Another approach is to get ratings of data from the internet. So there, you're not creating the dataset for this specific purpose. You're just scraping as many facial expressions or recordings of voices as you possibly can, maybe from YouTube. That's one way to scale up. That's one way to capture a much greater variety of naturalistic expressions. But then you're gathering ratings of these images. And those ratings are influenced not just by what somebody is expressing but also by somebody's gender, ethnicity, age, and what they're wearing, and so forth. +CHAD: Well, in those scenarios, a person has also classified the image, to begin with, right? +DR. COWEN: Yeah. +CHAD: So someone is labeling that image as angry, for example. +DR. COWEN: So typically, you're scraping a bunch of videos. You're giving them to raters typically from one country. And those raters are categorizing those images based on what they perceive to be the expression, and there are a lot of influences on that. If somebody is wearing a sporting outfit, and this is a hard bit of context to cut out, you can generally infer this person is likely to be expressing triumph or disappointments or all the different things people express when they're playing sports. And it's very different if somebody's wearing a suit. And so, these different biases seep into the algorithm. +We did train probably the best version of this kind of algorithm when I was at Google. And we used it to study people's expressions in other videos from around the world, mostly home videos. And we found that people form expressions in characteristic contexts around the world. And the relationship between context and expression was largely preserved. We were looking at 16 facial expressions we were able to label accurately. And this was probably with the best version of an algorithm trained in this way. But we still only captured about half of the information people take away from expressions because we had to throw away a lot of the predictions due to these biases. So that's how algorithms are traditionally trained. +Another way that you could go about it is by training a large model, like a large language model, if you're looking at an emotional language and query it in a special way. So let's say you take a GPT-3 kind of model, and you say, "Hey, what are the emotions associated with this sentence?" And there, you see exactly the same kind of biases as you'd see in perceptual ratings because typically, it's saying what is likely to be in that data. So it might say, "Well, pigeons are disgusting, and doves are beautiful," or something like that. And that's the kind of bias we don't care about. But you can imagine there are a lot of biases that we do care about in that data too. [laughs] +And so, what's needed is experimental control. And I think this is actually when it comes to the things we really care about, something that people should consider more often in machine learning. What are the confounds that exist in the data that you're training an algorithm on? And if you really care about those confounds and you want to be scientific about it, about removing them, what's the solution? Well, the solution is to somehow randomize what somebody is expressing, for example. And that's what we do at Hume. +We actually gather data with people reacting, for example, to very strongly evocative stimuli, which could be images, videos, paintings, et cetera, music. And we have balanced the set of stimuli in a way that makes it richly evocative of as many emotions as possible. And then what somebody is likely to be experiencing in a given setting is randomized relative to who they are since they see a random set of these stimuli or they undergo a random set of tasks. +And so, to the extent possible, we've removed some of the relationships between ethnicity, gender, age, and what somebody is experiencing, or what they're expressing. And so we do this in a lot of different ways. And one thing you do is you can train on basically what is the stimulus that somebody was looking at instead of training on somebody's perception of an expression. +CHAD: Hopefully, talking through this a little bit has helped people, one, I guess, understand why this is difficult. And that's where the need for a product by a company that specializes in it is important because it would be pretty difficult for a company just getting started to be able to do this in a scientifically controlled way. And in a sense, it's sort of like pooling the resources behind one product to do it well, and that can really do it well. You recently raised money pre-seed from investors. How obvious was the need to them, and how easy or hard was it for you to raise money? +DR. COWEN: I had been basically in this world for a long time before I started Hume AI and The Hume Initiative. So during grad school, while I was publishing a lot of this science that was showing people's expressions were much more nuanced than a lot of these datasets and algorithms had considered before, I was getting inbounds from tech companies. And so, I worked a little bit with some startups. I worked with Facebook. I worked with Google. And I had seen this problem from a lot of different perspectives and viewpoints already. +The need for data was very clear. The need for algorithms was clear because people literally had reached out to me and asked, "What are the best algorithms?" And I had to say, "Look, there are a few things, but all of them have problems. And they're mostly focused on the face, and you won't see much for the voice. And you won't see much for language." And what I had trained at Google was not something that was publicly available for facial expression. What is available for language probably the best one is another dataset that I helped put together at Google and algorithms trained on that called the GoEmotions dataset, which is used by Hugging Faces emotional language algorithm. +And so I knew that there was this need, and a lot of people were looking for this kind of data, and so that's where it started. So talking to investors, it wasn't too hard to show them all the evidence that there was a need for this, a big market. And we raised a $5 million pre-seed. What we have spent a lot of that so far is in data collection. And that's made a huge difference in training algorithms for facial expression, voice, language, and so forth. And then what turns out to be more of a challenge is delivering those algorithms to people. And we're actually building a platform, an API platform, for that that will be really helpful in getting people started. +CHAD: As you took on investors who, you know, they're trying to build a business. They want to create a business that gives them a return. And as you move towards a product in the marketplace, what are the things that you've encountered that are the biggest concerns in terms of the success? +DR. COWEN: There's a scientific and sort of almost educational challenge. I think people have been fixated on a few ideas about emotion for a long time; these really sticky ideas like you can reduce emotion to six categories or two dimensions. So even when people take these really nuanced and accurate models that we've trained to distinguish 28 different kinds of facial expression, much broader array of facial expressions or 24 different kinds of vocal expression in vocal utterances like laughs, and cries, and screams, and sighs, and 16 different kinds of speech prosody, typically, people will take these, and they'll take out a few emotions, and they say, "Okay, well, this prediction is for the anger prediction, and that's the one I'm interested in." +The challenge is in conceptualizing the phenomenon people are interested in classifying with these models and how they can relate that to what the model is predicting because typically, what constitutes anger is very different from one situation to another. Someone who's angry, who is maybe playing a sport, is going to be much more vocal about it than if you're on a customer service call. +And that context is really important in going from an embedding that's general for different expressions, that can recognize 16 different emotional intonations in speech and fine-tuning it for that specific context. And I think that process can be difficult to understand if you're not fluent in the language of emotion science and particularly where it's gone over the last few years. +And so part of what we're doing now is actually setting up ways to visualize the outputs of our models really smoothly and with any data so that people can navigate their data and actually see, okay, well, what this model is saying is an embedding of anger for what I'm interested in. Maybe it's customer service calls. Actually, it's a combination of a little bit of contempt and a little bit of disappointment in what people have labeled these expressions with. And now I can take this embedding, and I understand how to use it better. +CHAD: Do you anticipate or hope for, and maybe those are the same, and maybe they're different, that you're going to have a few big customers or lots of small customers or something in between? +DR. COWEN: We hope lots of small customers. [laughs] I want to get this into as many people's hands as possible. A lot of people are doing really innovative things in the startup world. There's also a huge need in big applications like digital assistants that are mostly in the hands of a few companies basically. We want to have an impact there as well. +The difference, of course, will be the manner in which these solutions are delivered. The ease of providing people with APIs, subscribing to a pay-as-you-go model I think is really attractive for startups. And so that's how we're accessing that market. On the other hand, we do already have some big customers who are licensing the data or the models themselves. And I anticipate there will be a lot of that going forward as well. +Mid-Roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: You said you've built up to this point. But how long have you been working at it so far in terms of creating the actual product that will go to market soon? +DR. COWEN: The company is only a year old. And we actually just had our first year anniversary. +CHAD: Congratulations. +DR. COWEN: [laughs] Thank you. Thank you. We are just now about to launch our platform, which I think is going to be our main product going forward. We're also running machine learning competitions in the research community, which there will be involvement from lots of tech companies and researchers around the world. So in many ways, we're still just getting started. +But we have already what I think are the best models for understanding facial expression, the best models for understanding vocal utterances or what we call vocal bursts, which is actually different than understanding speech prosody or emotional intonation and language more generally. And we need separate models for that. We have both of probably the best models for those two modalities and are building what we think will be the best model for emotional language as well. And so we have solutions. Part of the product is delivering them, and that's what we're launching now. So we're at the beginning of that. +CHAD: So has to get to this point taken longer than you were anticipating, the time you were anticipating or shorter? Did it go faster? +DR. COWEN: I think my estimates for actually training these models and beating the state of the art were about on point. [chuckles] I mean, when we got started, I was ready to start running these experiments pretty quickly. So I designed all the experiments myself and started running them around the world, recruiting participants through labs, through consulting agencies, through crowdsourcing websites, a lot of different ways. +There were a few challenges along the way, like figuring out how you could adjust the consent form in ways that weren't really relevant to ethics. And we had IRB approval. We had a very robust consent process for people to understand how their data was going to be used but were relevant to figuring out how you come up with language that is consistent with data privacy laws and each individual jurisdiction where you're running data collection. That took a little longer than I thought. [laughs] +But suffice to say, we had the data. We had the models pretty quickly. I was able to recruit some of the top AI researchers in this space pretty quickly. We hit the ground running. We were able to take the data and train state-of-the-art models pretty fast. What's taking longer is getting the models into people's hands in two ways. I mean, negotiating enterprise contracts is always a struggle that many people are aware of. And then figuring out we needed to have a really user-friendly platform basically to deliver the models through APIs, and that's taking a little bit longer than anticipated. +CHAD: So The Hume Initiative is a group of people that have come together and established some guidelines that companies sign on to in terms of what their solutions are going to take into account and do and not do. Do I have that right? +DR. COWEN: Yeah. So we put together a separate non-profit. And we brought together some of the leading AI researchers, ethicists, with emotion scientists, and cyber law experts to this very unique composition of domain knowledge to develop what are really the first concrete ethical guidelines for empathic AI. Let's say for this use case; we support it if you meet these requirements. These are our recommendations. And for this use case, we don't support it. And we actually get really concrete. +I think generally, with AI principles efforts or AI ethics efforts, people focus on the broad principles and left it to, I don't know, it's unclear often who is going to decide whether a use case is admissible or not under these principles. Because let's say they're codified into law, then it'll end up being a judge who doesn't necessarily have any knowledge of AI or emotion science or any of these things to say this is a use case that's consistent with these principles or not. We wanted to avoid that. +And I think particularly; I think that the public is skeptical too of broader principles where they don't really know whether a given use of their data is compliant with those principles or not. I mean, sometimes it's easier. There are really good policies regarding surveillance that I think most of the big tech companies ascribe to where they say they won't be using your data in ways that you expect to have privacy and you actually don't. So I think there are pretty good principles there. +There haven't really been good principles or concrete guidelines for what people might consider manipulative. And I think some technology that incorporates cues of emotion can be deemed manipulative in a sense. In the sense that you might not want to be sucked into a comment thread because something really provocative was shown to you after clicking on a notification that was unrelated to that. But the algorithm may have figured out this is a way to keep you in the app. [laughs] So that can be considered manipulative in some kind of way. +I mean, it's bad if the person is vulnerable at that time. If the algorithm is able to read cues of your emotions and maybe through interoperability across different applications or because it knows it or has this information, this data already, it can say this is a person who is vulnerable right now to being provoked because they're in a bad mood. Maybe I can see that they just ordered food, and it's late, and it was canceled, whatever is. It can be any number of things. Or the way that this person queried a digital assistant or a search engine revealed this kind of emotional state. We don't want the algorithm to use that to get us to do something we otherwise wouldn't want to do +So the principles we've set up around that are really important. Whenever somebody's emotional behaviors are involved or cues to their emotional state, they should be used to make sure that the algorithm is not using these cues against somebody or using them as a means to an end. What they should be used to do is make sure the algorithm is improving our emotions or improving our emotional state over time on average across many different people so that we're less frustrated on average over time, and we have more instances where we're satisfied, or content, or happy, or all inspired or whatever your measures or indicators of well-being you have present through these behaviors might be. +The algorithm should be using these behaviors to enhance your well-being fundamentally. And wherever they're entering into an algorithm, we should be privy to how the algorithm is using them. And so that's essentially what the principles codify and make very concrete, and they say, "In this use case, this is how you can make sure this is the case, you know, health and wellness, digital assistants, photo-taking, arts and culture applications, film, animation." There are all these different applications of empathic AI. +So it's a very broadly applicable thing because it applies to any text, any video with people in it, any audio where you hear people's voices. This is just a part of the data that's untapped relatively, or to the extent that it's tapped by algorithms today; it's done in a way that we don't really see, or maybe the developers don't even realize. If we make explicit that these are cues to people's emotions, there's a huge number of applications where we can then have algorithms learn from people's emotional cues and decide whether to enhance certain emotions or use them in certain ways. +So I think it's going to be really, really key to get this right. And it requires expertise in how these emotions operate in daily life, in emotion science, in what is the definition of privacy here? What's the definition of a biometric measure which involves cyber law? And how does this intersect with existing laws and so forth? It's something that requires AI research expertise. You have to know how these algorithms work. +It's something that requires specific kinds of AI ethics expertise. What is the alignment problem? How do we consider the value alignment in this situation? Which I think really comes down to optimizing for people's well-being. And we have brought together exactly that composition of expertise in The Hume Initiative. +CHAD: Hume AI has sort of signed off and said, "We're going to follow these guidelines of The Hume Initiative." Does that apply to every customer who is a customer of Hume AI? +DR. COWEN: Exactly, yeah. So we actually require people on our terms of use to adhere to the guidelines. And so, for a lot of people, that won't be that difficult because they'll look through the guidelines. They'll see that their use case is supported, that they're already following the recommendations that are in the guidelines. And so they're good. They're good to go. Some people might [laughs] see that they're not compliant with the recommendations. And then they'll be able to make adjustments to their product so that they're compliant. +And then others who are pursuing use cases that are not supported by the ethics guidelines can't use the platform, which is exactly what we want. We don't want people using this for mass surveillance, for example, and that's stated pretty clearly in the guidelines. So yeah, we do require all of our customers to adhere to these guidelines that we've now launched at thehumeinitiative.org. +CHAD: How important to you was it to have The Hume Initiative and these guidelines? Was it a precondition of doing all of this? +DR. COWEN: Yeah, it was important for two reasons; one is that I felt that this shouldn't be used to exacerbate a lot of the problems that we're going to run into with AI eventually, if not already, where AI could be using our emotional behaviors to optimize for an objective that could be misaligned potentially with our desires, what emotions we want to feel, or with our well-being. Even though when you're privy to these emotional behaviors, you have the opportunity to do what a human does and say, "I have empathy. Therefore, I can say this is probably not a good way to get people to spend more time on this app or to buy this thing because I know that it's exploitative in some way." And I don't think that's the norm. +I think, by and large, these strategies that have been used to optimize AI algorithms today have been good proxies for our well-being. Like, engagement is not necessarily a bad proxy for whether we want to spend time on doing something, but it's not good in all cases. And I think there's a huge amount of room for improvement because we don't know in all cases how the AI is getting us to be more engaged. And many of the strategies it uses may not be consistent with our well-being. +But particularly going forward, once AI is smart enough, and once it has more control points in the environment, whether there are robots or digital assistants that have control over Internet of Things devices, AI will have an increasing influence on the environment around us, and it'll be smarter and smarter. And before long, it will be very important to make sure that it's aligned with our values. This is the concept of the alignment problem. +Eventually, if you have a really, really smart, all-powerful, not all-powerful, but similar [laughter] powerful robot in your house and it's written by AI, and you tell it, "Hey, robot. I'm hungry. Make me the most delicious meal that you can that's healthy for me and satisfies all of these parameters using ingredients that are available in my kitchen." And if your cat happens to be in your kitchen and it realizes that, hey, this is lean meat. I have a great sense of what this person likes, so this is going to be really tasty. And it cooks your cat. [laughs] That's a way of satisfying this objective that you don't like. +And so if it understood something about what is it that makes people happy by learning from our emotional behaviors in everyday life, we're not often saying to this robot, "This is something that I don't want you to cook." But if the robot understood this is something that makes you happy in everyday life, that would be one proxy for it to be able to figure out this would be a negative on your well-being if it did this. And so that is ultimately the solution. +So we're going from; first, we at least want to optimize our algorithms existing today for people to feel better or indications of their well-being. And then, later on, we just want to make sure that, increasingly, that is the objective of these algorithms. I think that's been really important to me. +CHAD: Obviously, it's not like the other companies out there doing this want to create a robot that cooks your cat. +DR. COWEN: No. [laughs] +CHAD: But it is possible that other companies don't prioritize it in the same way that Hume might. How do you stay motivated in the face of maybe not everyone caring about creating this in the same way that you are? +DR. COWEN: That brings me to the other main reason for doing things this way, which is that I think there's enough of an economic incentive that you can create a company that is more successful for having made ethical commitments than otherwise. And I think that's particularly true if your company wasn't going to do anything unethical anyway, [laughs] which we didn't plan on doing and most companies don't plan on doing. Because if your company is not going to do anything unethical anyway, then you might as well be able to explain to people how you made the decision about what's ethical and what isn't and be able to make guarantees to them that actually attract more customers. +Because the customers are able to say, "Look, they've made a legal commitment to not doing this." I don't have to suspect that these things are being used against me or in a manipulative way or in a way that doesn't preserve the privacy that I thought I had. I don't have to be skeptical of any of these things because I can see clearly that the company has made this potentially legal commitment, at least that's something that they're committed to publicly." So in that sense, it's purely an advantage. And that's true for AI generally but specifically for empathic AI. +I think there's been a hunger for those kinds of ethical guidelines, and you can see it in how people react to news of this technology. There is generally a skepticism in the air. I think it goes back also to maybe sometimes people's concerns about privacy are legitimate if the question is whether what the output is picking up on is going to wind up in the hands of people you don't want it to end up in. And those people are privy to things about your lifestyle, or they're able to use that against you in some way. That is a real privacy issue. It's not necessarily, to me, a privacy issue. +If an algorithm is processing these things on device and the data never goes anywhere, and it's only used in a way in which you actually want it to be used, which is maybe to surface better music to you or to have you be taking better pictures on your phone, these are all great things for you. +And that data doesn't necessarily go anywhere in the same way that any of the photo data you take doesn't necessarily go anywhere even though it's already processed by lots and lots of algorithms, or your search queries aren't necessarily not private. Just because they're processed by algorithms, maybe even algorithms that are good for the business, they're not necessarily being seen by humans. And so, it's not necessarily a privacy issue. +But people have this skepticism about emotion AI, in particular, empathic AI, in particular, because I think there are certain instincts that it plays on, like the idea that you're being watched. Early in our species history and even before our species, it was very important to be very wary of predators watching you from the bushes or from the crevices and all that. And I think that instinct is involved whenever we're being recorded, whenever there's a camera. +And that's not just an issue for empathic AI but also for things like facial identification, which brings up legitimate privacy concerns but also, sometimes there are uses that we don't care about at all, or they're clearly good. Like, I think facial identification for unlocking your phone that's a really good use. And that is basically what it's used for by some companies. Some big tech companies are just using it for that and not much else. +And so, when you unpack what you're doing with this stuff, it makes it a lot easier for people to be comfortable with it. And that is what the ethics initiative is doing essentially. It's giving people all of these use cases and recipes and unpacking what this is being used for so that people can be more comfortable with it. And I think that's actually something that is in the business' interest. +CHAD: That's great. Well, I really appreciate, you know, there are a lot of pushes and pulls when founders are creating new companies. So to put a stake in the ground in terms of what's important to you and the right way to build this product and to go through the effort of creating these guidelines and a whole initiative around it and everything is...well, I can see that not everyone does that because of the concern around oh, is this going to hurt my business? Is it going to make it harder for me to succeed? And so when principals and business case align, great, but even when they don't, I think it's important, and I commend you for making sure that you're leading with your principals. +DR. COWEN: Thanks. I mean, there have certainly been challenges to it. But I think that even so, the pros have outweighed the cons both ethically and for our business for us so far. +CHAD: Great. So if folks have enjoyed today's conversation and either want to dig in more, you have a podcast, right? +DR. COWEN: That's right. We have a podcast called The Feelings Lab, where we explore different emotions that are of concern in everyday life, that guide our everyday lives, and that are changing as a consequence of changes in society and technology. In Season One, we focused mostly on one emotion per episode. We had guests like Fred Armisen talking about horror, which is a really funny perspective to have [laughs] because fear is not always bad, and sometimes we like to watch horror movies. [laughs] +And in Season Two, we're focusing particularly on the technology. And so we had the CEO of Embodied Paolo Pirjanian, who has a robot called Moxie that's used to help kids in their emotional development, and it's a great toy. We had the CEO, one of the co-founders of Soul Machines, which was an avatar company. We had VP at Omniverse Platform Developments in NVIDIA talking about how AI is changing the abilities of artists and changing basically the way that film is made. And it's very interesting. So I'd encourage people to check that out. +CHAD: Where can people find that? I assume by searching for Feelings Lab in the podcast player. But do you have a domain name too? +DR. COWEN: Yeah, you can go to hume.ai, and then you can go to our content hub. That's one way to find it. And you can find the podcast on Apple, SoundCloud, pretty much wherever you get podcasts. And we also have a YouTube channel, The Feelings Lab. Actually, I think the YouTube channel is Hume AI, and then we post content on The Feelings Lab there as well. +CHAD: And you mentioned people can sign up now to be on the list for the Hume AI. +DR. COWEN: So yes, if you are interested in building an empathic AI technology of any kind and you would like access to our voice models or face models, emotional language models, easy access, one-line API call for streaming or for files, pretty much any use case you might have, you can sign up for the waitlist at hume.ai. And we will be releasing a beta version of the platform over the next few months. +CHAD: Cool. Well, if folks want to get in touch with you or follow along with you, where are the places where they can do that? +DR. COWEN: Folks who want to get in touch, you can email hello@hume.ai for information about our solutions, offerings, the company, or you can reach out to me personally alan@hume.ai +CHAD: Awesome. Alan, thank you so much for joining me. I really appreciate it. +DR. COWEN: Thanks for having me. +CHAD: You can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Alan Cowen. + + + Dr. Alan Cowen is the Executive Director of The Hume Initiative, a non-profit dedicated to the responsible advancement of AI with empathy, and CEO of Hume AI, an AI research lab and empathetic AI company that is hoping to pave the way for AI that improves our emotional well-being.

+ +

Chad talks with Alan about forming clear ethical guidelines around how this technology should be used because there is a problem in that the public is skeptical about whether technology is used for good or bad. The Hume Initiative is intended to lay out what concrete use cases will be and what use cases shouldn't be supported. Hume AI is built for developers to construct empathic abilities into their applications.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dr. Alan Cowen, the Executive Director of The Hume Initiative, a non-profit dedicated to the responsible advancement of AI with empathy, and CEO of Hume AI, an AI research lab and empathetic AI company. Alan, thank you for joining me.

+ +

DR. COWEN: Thanks for having me on.

+ +

CHAD: That's a lot of words in that introduction. I'm glad I got through it in one take. Let's take a step back a little bit and talk about the two different things, The Hume Initiative and Hume AI. And what came first?

+ +

DR. COWEN: So they were conceptualized at the same time. Practically speaking, Hume AI was started first only because it currently is the sole supporter of The Hume Initiative. But they were both conceptualized as this way to adjust two of the main problems that people have faced bringing empathic abilities to technology. Technology needs to have empathic abilities. If AI is going to get smart enough to make decisions on our behalf, it should understand whether those decisions are good or bad for our well-being. And a big part of that is understanding people's emotions because emotions are really what determine our well-being.

+ +

The Hume Initiative addresses one of the challenges, which is the formation of clear ethical guidelines around how this technology should be used. And it's not because the companies pursuing this have bad intents; that's not the point at all. The problem is that the public is probably justifiably skeptical of whether this technology will be used for them or against them. And The Hume Initiative is intended as a way of laying out what the concrete use cases will be and what use cases shouldn't be supported.

+ +

Hume AI is introducing solutions to the problem of how we build empathic AI algorithms. And the challenge there has been the data. So there have been a lot of attempts at building empathic AI or emotion AI, whatever you call it, basically ways of reading facial expression, emotion in the voice, and language. And there's been a few challenges, but most of them come down to the fact that the data tends to be based on outdated theories of emotion and/or it tends to be based on people's perceptual ratings of images largely from the internet or videos that are collected in more of an observational way without experimental control.

+ +

And within those perceptual judgments, you see gender biases, sometimes racial biases, biases by what people are wearing, whether they're wearing sunglasses, for example, because people with sunglasses for some reason are perceived as being proud. [laughter] And the algorithms will always label people with sunglasses as being proud if you're training the algorithm that way.

+ +

What you need basically is some way to control for people's identity, what they're wearing, get people's own self-reports as to what they're feeling or what they're expressing, and do it in a way that's somewhat randomized so that different people express a wide range of emotional behaviors in a wide range of contexts. And the contexts are somewhat randomized. So that's what we're doing with Hume AI is we're gathering that data, and it requires large-scale experiments to be run around the world.

+ +

CHAD: In terms of the actual product that Hume AI is going to do, is it a standalone product? Or is it something that people building products will use?

+ +

DR. COWEN: It's a developer product. It's built for developers to build empathic abilities into their applications. And so we are about to launch a developer portal, and we have a waitlist on our website on hume.ai for that. In the meantime, we've been licensing out the models that we're training and the data that we're using to train those models, which I actually kind of view as somewhat interchangeable. Models are basically descriptions of data. Some people have the resources to train those models on-premise; some people don't.

+ +

But we're providing the solution to any developer who wants to build the ability to understand, for example, vocal expression into, say, a digital assistant. So can the digital assistant understand when you're frustrated and be able to change its response based on that information? And even potentially update the actual network, the neural network that's being used to generate that response, actually, backpropagate the fact that this was an unsatisfactory response and make the algorithm better. Is this something that you could use for health tech?

+ +

So people are building out telehealth solutions that incorporate AI in various ways, one of which is can we get an objective classification of emotional behavior that can be used to help triage patients, send them to the right place, put them in touch with the right help? Can it be used to sub-diagnose disorders, diagnose disorders with more statistical power? Because you can incorporate more data and develop better treatments for those disorders, and that can be done in a wide range of contexts.

+ +

CHAD: So you mentioned training AI models. I don't want to make the assumption that everyone knows what that means or looks like. Maybe if we could take a step back, if you don't mind, talk about what that maybe traditionally looks like and how Hume is actually different.

+ +

DR. COWEN: Yeah, totally. When it comes to empathic AI, so this is an area where you're trying to train an algorithm to measure facial movements insofar as they have distinct meanings or measure inflections of the voice while people are speaking to understand the non-verbal indications of emotion in the voice. When you are training an algorithm to do that, you're taking in images, video, audio, and you're predicting people as attributions of emotion to themselves or to others and what people are feeling or what people say they're expressing or what other people say they hear in an expression. You need a lot of data for that.

+ +

Traditionally, people have used smaller datasets and assumed that emotion can be reduced to a few categories. That's been one solution to this problem. And so basically, you'll have people pose facial expressions of anger, fear, happiness, sadness, disgust, and surprise, which are called the basic six emotions. And that was introduced by Paul Ekman in the 1970s. And there are whole datasets of people posing those six expressions or perhaps combinations of them. And usually, those facial expressions are front-lit and front-facing and meet certain constraints.

+ +

And when you train a model on that data, it doesn't tend to generalize very well to naturalistic expressions that you encounter from day-to-day for a lot of different reasons; one is that the six basic emotions only capture about 30% of what people perceive in an expression. Another is that people in everyday situations have a wide range of lighting conditions, viewpoints, et cetera. And there's more diversity in age, gender than you see in these datasets and in ethnicity and so forth. And so, these algorithms don't generalize.

+ +

Another approach is to get ratings of data from the internet. So there, you're not creating the dataset for this specific purpose. You're just scraping as many facial expressions or recordings of voices as you possibly can, maybe from YouTube. That's one way to scale up. That's one way to capture a much greater variety of naturalistic expressions. But then you're gathering ratings of these images. And those ratings are influenced not just by what somebody is expressing but also by somebody's gender, ethnicity, age, and what they're wearing, and so forth.

+ +

CHAD: Well, in those scenarios, a person has also classified the image, to begin with, right?

+ +

DR. COWEN: Yeah.

+ +

CHAD: So someone is labeling that image as angry, for example.

+ +

DR. COWEN: So typically, you're scraping a bunch of videos. You're giving them to raters typically from one country. And those raters are categorizing those images based on what they perceive to be the expression, and there are a lot of influences on that. If somebody is wearing a sporting outfit, and this is a hard bit of context to cut out, you can generally infer this person is likely to be expressing triumph or disappointments or all the different things people express when they're playing sports. And it's very different if somebody's wearing a suit. And so, these different biases seep into the algorithm.

+ +

We did train probably the best version of this kind of algorithm when I was at Google. And we used it to study people's expressions in other videos from around the world, mostly home videos. And we found that people form expressions in characteristic contexts around the world. And the relationship between context and expression was largely preserved. We were looking at 16 facial expressions we were able to label accurately. And this was probably with the best version of an algorithm trained in this way. But we still only captured about half of the information people take away from expressions because we had to throw away a lot of the predictions due to these biases. So that's how algorithms are traditionally trained.

+ +

Another way that you could go about it is by training a large model, like a large language model, if you're looking at an emotional language and query it in a special way. So let's say you take a GPT-3 kind of model, and you say, "Hey, what are the emotions associated with this sentence?" And there, you see exactly the same kind of biases as you'd see in perceptual ratings because typically, it's saying what is likely to be in that data. So it might say, "Well, pigeons are disgusting, and doves are beautiful," or something like that. And that's the kind of bias we don't care about. But you can imagine there are a lot of biases that we do care about in that data too. [laughs]

+ +

And so, what's needed is experimental control. And I think this is actually when it comes to the things we really care about, something that people should consider more often in machine learning. What are the confounds that exist in the data that you're training an algorithm on? And if you really care about those confounds and you want to be scientific about it, about removing them, what's the solution? Well, the solution is to somehow randomize what somebody is expressing, for example. And that's what we do at Hume.

+ +

We actually gather data with people reacting, for example, to very strongly evocative stimuli, which could be images, videos, paintings, et cetera, music. And we have balanced the set of stimuli in a way that makes it richly evocative of as many emotions as possible. And then what somebody is likely to be experiencing in a given setting is randomized relative to who they are since they see a random set of these stimuli or they undergo a random set of tasks.

+ +

And so, to the extent possible, we've removed some of the relationships between ethnicity, gender, age, and what somebody is experiencing, or what they're expressing. And so we do this in a lot of different ways. And one thing you do is you can train on basically what is the stimulus that somebody was looking at instead of training on somebody's perception of an expression.

+ +

CHAD: Hopefully, talking through this a little bit has helped people, one, I guess, understand why this is difficult. And that's where the need for a product by a company that specializes in it is important because it would be pretty difficult for a company just getting started to be able to do this in a scientifically controlled way. And in a sense, it's sort of like pooling the resources behind one product to do it well, and that can really do it well. You recently raised money pre-seed from investors. How obvious was the need to them, and how easy or hard was it for you to raise money?

+ +

DR. COWEN: I had been basically in this world for a long time before I started Hume AI and The Hume Initiative. So during grad school, while I was publishing a lot of this science that was showing people's expressions were much more nuanced than a lot of these datasets and algorithms had considered before, I was getting inbounds from tech companies. And so, I worked a little bit with some startups. I worked with Facebook. I worked with Google. And I had seen this problem from a lot of different perspectives and viewpoints already.

+ +

The need for data was very clear. The need for algorithms was clear because people literally had reached out to me and asked, "What are the best algorithms?" And I had to say, "Look, there are a few things, but all of them have problems. And they're mostly focused on the face, and you won't see much for the voice. And you won't see much for language." And what I had trained at Google was not something that was publicly available for facial expression. What is available for language probably the best one is another dataset that I helped put together at Google and algorithms trained on that called the GoEmotions dataset, which is used by Hugging Faces emotional language algorithm.

+ +

And so I knew that there was this need, and a lot of people were looking for this kind of data, and so that's where it started. So talking to investors, it wasn't too hard to show them all the evidence that there was a need for this, a big market. And we raised a $5 million pre-seed. What we have spent a lot of that so far is in data collection. And that's made a huge difference in training algorithms for facial expression, voice, language, and so forth. And then what turns out to be more of a challenge is delivering those algorithms to people. And we're actually building a platform, an API platform, for that that will be really helpful in getting people started.

+ +

CHAD: As you took on investors who, you know, they're trying to build a business. They want to create a business that gives them a return. And as you move towards a product in the marketplace, what are the things that you've encountered that are the biggest concerns in terms of the success?

+ +

DR. COWEN: There's a scientific and sort of almost educational challenge. I think people have been fixated on a few ideas about emotion for a long time; these really sticky ideas like you can reduce emotion to six categories or two dimensions. So even when people take these really nuanced and accurate models that we've trained to distinguish 28 different kinds of facial expression, much broader array of facial expressions or 24 different kinds of vocal expression in vocal utterances like laughs, and cries, and screams, and sighs, and 16 different kinds of speech prosody, typically, people will take these, and they'll take out a few emotions, and they say, "Okay, well, this prediction is for the anger prediction, and that's the one I'm interested in."

+ +

The challenge is in conceptualizing the phenomenon people are interested in classifying with these models and how they can relate that to what the model is predicting because typically, what constitutes anger is very different from one situation to another. Someone who's angry, who is maybe playing a sport, is going to be much more vocal about it than if you're on a customer service call.

+ +

And that context is really important in going from an embedding that's general for different expressions, that can recognize 16 different emotional intonations in speech and fine-tuning it for that specific context. And I think that process can be difficult to understand if you're not fluent in the language of emotion science and particularly where it's gone over the last few years.

+ +

And so part of what we're doing now is actually setting up ways to visualize the outputs of our models really smoothly and with any data so that people can navigate their data and actually see, okay, well, what this model is saying is an embedding of anger for what I'm interested in. Maybe it's customer service calls. Actually, it's a combination of a little bit of contempt and a little bit of disappointment in what people have labeled these expressions with. And now I can take this embedding, and I understand how to use it better.

+ +

CHAD: Do you anticipate or hope for, and maybe those are the same, and maybe they're different, that you're going to have a few big customers or lots of small customers or something in between?

+ +

DR. COWEN: We hope lots of small customers. [laughs] I want to get this into as many people's hands as possible. A lot of people are doing really innovative things in the startup world. There's also a huge need in big applications like digital assistants that are mostly in the hands of a few companies basically. We want to have an impact there as well.

+ +

The difference, of course, will be the manner in which these solutions are delivered. The ease of providing people with APIs, subscribing to a pay-as-you-go model I think is really attractive for startups. And so that's how we're accessing that market. On the other hand, we do already have some big customers who are licensing the data or the models themselves. And I anticipate there will be a lot of that going forward as well.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: You said you've built up to this point. But how long have you been working at it so far in terms of creating the actual product that will go to market soon?

+ +

DR. COWEN: The company is only a year old. And we actually just had our first year anniversary.

+ +

CHAD: Congratulations.

+ +

DR. COWEN: [laughs] Thank you. Thank you. We are just now about to launch our platform, which I think is going to be our main product going forward. We're also running machine learning competitions in the research community, which there will be involvement from lots of tech companies and researchers around the world. So in many ways, we're still just getting started.

+ +

But we have already what I think are the best models for understanding facial expression, the best models for understanding vocal utterances or what we call vocal bursts, which is actually different than understanding speech prosody or emotional intonation and language more generally. And we need separate models for that. We have both of probably the best models for those two modalities and are building what we think will be the best model for emotional language as well. And so we have solutions. Part of the product is delivering them, and that's what we're launching now. So we're at the beginning of that.

+ +

CHAD: So has to get to this point taken longer than you were anticipating, the time you were anticipating or shorter? Did it go faster?

+ +

DR. COWEN: I think my estimates for actually training these models and beating the state of the art were about on point. [chuckles] I mean, when we got started, I was ready to start running these experiments pretty quickly. So I designed all the experiments myself and started running them around the world, recruiting participants through labs, through consulting agencies, through crowdsourcing websites, a lot of different ways.

+ +

There were a few challenges along the way, like figuring out how you could adjust the consent form in ways that weren't really relevant to ethics. And we had IRB approval. We had a very robust consent process for people to understand how their data was going to be used but were relevant to figuring out how you come up with language that is consistent with data privacy laws and each individual jurisdiction where you're running data collection. That took a little longer than I thought. [laughs]

+ +

But suffice to say, we had the data. We had the models pretty quickly. I was able to recruit some of the top AI researchers in this space pretty quickly. We hit the ground running. We were able to take the data and train state-of-the-art models pretty fast. What's taking longer is getting the models into people's hands in two ways. I mean, negotiating enterprise contracts is always a struggle that many people are aware of. And then figuring out we needed to have a really user-friendly platform basically to deliver the models through APIs, and that's taking a little bit longer than anticipated.

+ +

CHAD: So The Hume Initiative is a group of people that have come together and established some guidelines that companies sign on to in terms of what their solutions are going to take into account and do and not do. Do I have that right?

+ +

DR. COWEN: Yeah. So we put together a separate non-profit. And we brought together some of the leading AI researchers, ethicists, with emotion scientists, and cyber law experts to this very unique composition of domain knowledge to develop what are really the first concrete ethical guidelines for empathic AI. Let's say for this use case; we support it if you meet these requirements. These are our recommendations. And for this use case, we don't support it. And we actually get really concrete.

+ +

I think generally, with AI principles efforts or AI ethics efforts, people focus on the broad principles and left it to, I don't know, it's unclear often who is going to decide whether a use case is admissible or not under these principles. Because let's say they're codified into law, then it'll end up being a judge who doesn't necessarily have any knowledge of AI or emotion science or any of these things to say this is a use case that's consistent with these principles or not. We wanted to avoid that.

+ +

And I think particularly; I think that the public is skeptical too of broader principles where they don't really know whether a given use of their data is compliant with those principles or not. I mean, sometimes it's easier. There are really good policies regarding surveillance that I think most of the big tech companies ascribe to where they say they won't be using your data in ways that you expect to have privacy and you actually don't. So I think there are pretty good principles there.

+ +

There haven't really been good principles or concrete guidelines for what people might consider manipulative. And I think some technology that incorporates cues of emotion can be deemed manipulative in a sense. In the sense that you might not want to be sucked into a comment thread because something really provocative was shown to you after clicking on a notification that was unrelated to that. But the algorithm may have figured out this is a way to keep you in the app. [laughs] So that can be considered manipulative in some kind of way.

+ +

I mean, it's bad if the person is vulnerable at that time. If the algorithm is able to read cues of your emotions and maybe through interoperability across different applications or because it knows it or has this information, this data already, it can say this is a person who is vulnerable right now to being provoked because they're in a bad mood. Maybe I can see that they just ordered food, and it's late, and it was canceled, whatever is. It can be any number of things. Or the way that this person queried a digital assistant or a search engine revealed this kind of emotional state. We don't want the algorithm to use that to get us to do something we otherwise wouldn't want to do

+ +

So the principles we've set up around that are really important. Whenever somebody's emotional behaviors are involved or cues to their emotional state, they should be used to make sure that the algorithm is not using these cues against somebody or using them as a means to an end. What they should be used to do is make sure the algorithm is improving our emotions or improving our emotional state over time on average across many different people so that we're less frustrated on average over time, and we have more instances where we're satisfied, or content, or happy, or all inspired or whatever your measures or indicators of well-being you have present through these behaviors might be.

+ +

The algorithm should be using these behaviors to enhance your well-being fundamentally. And wherever they're entering into an algorithm, we should be privy to how the algorithm is using them. And so that's essentially what the principles codify and make very concrete, and they say, "In this use case, this is how you can make sure this is the case, you know, health and wellness, digital assistants, photo-taking, arts and culture applications, film, animation." There are all these different applications of empathic AI.

+ +

So it's a very broadly applicable thing because it applies to any text, any video with people in it, any audio where you hear people's voices. This is just a part of the data that's untapped relatively, or to the extent that it's tapped by algorithms today; it's done in a way that we don't really see, or maybe the developers don't even realize. If we make explicit that these are cues to people's emotions, there's a huge number of applications where we can then have algorithms learn from people's emotional cues and decide whether to enhance certain emotions or use them in certain ways.

+ +

So I think it's going to be really, really key to get this right. And it requires expertise in how these emotions operate in daily life, in emotion science, in what is the definition of privacy here? What's the definition of a biometric measure which involves cyber law? And how does this intersect with existing laws and so forth? It's something that requires AI research expertise. You have to know how these algorithms work.

+ +

It's something that requires specific kinds of AI ethics expertise. What is the alignment problem? How do we consider the value alignment in this situation? Which I think really comes down to optimizing for people's well-being. And we have brought together exactly that composition of expertise in The Hume Initiative.

+ +

CHAD: Hume AI has sort of signed off and said, "We're going to follow these guidelines of The Hume Initiative." Does that apply to every customer who is a customer of Hume AI?

+ +

DR. COWEN: Exactly, yeah. So we actually require people on our terms of use to adhere to the guidelines. And so, for a lot of people, that won't be that difficult because they'll look through the guidelines. They'll see that their use case is supported, that they're already following the recommendations that are in the guidelines. And so they're good. They're good to go. Some people might [laughs] see that they're not compliant with the recommendations. And then they'll be able to make adjustments to their product so that they're compliant.

+ +

And then others who are pursuing use cases that are not supported by the ethics guidelines can't use the platform, which is exactly what we want. We don't want people using this for mass surveillance, for example, and that's stated pretty clearly in the guidelines. So yeah, we do require all of our customers to adhere to these guidelines that we've now launched at thehumeinitiative.org.

+ +

CHAD: How important to you was it to have The Hume Initiative and these guidelines? Was it a precondition of doing all of this?

+ +

DR. COWEN: Yeah, it was important for two reasons; one is that I felt that this shouldn't be used to exacerbate a lot of the problems that we're going to run into with AI eventually, if not already, where AI could be using our emotional behaviors to optimize for an objective that could be misaligned potentially with our desires, what emotions we want to feel, or with our well-being. Even though when you're privy to these emotional behaviors, you have the opportunity to do what a human does and say, "I have empathy. Therefore, I can say this is probably not a good way to get people to spend more time on this app or to buy this thing because I know that it's exploitative in some way." And I don't think that's the norm.

+ +

I think, by and large, these strategies that have been used to optimize AI algorithms today have been good proxies for our well-being. Like, engagement is not necessarily a bad proxy for whether we want to spend time on doing something, but it's not good in all cases. And I think there's a huge amount of room for improvement because we don't know in all cases how the AI is getting us to be more engaged. And many of the strategies it uses may not be consistent with our well-being.

+ +

But particularly going forward, once AI is smart enough, and once it has more control points in the environment, whether there are robots or digital assistants that have control over Internet of Things devices, AI will have an increasing influence on the environment around us, and it'll be smarter and smarter. And before long, it will be very important to make sure that it's aligned with our values. This is the concept of the alignment problem.

+ +

Eventually, if you have a really, really smart, all-powerful, not all-powerful, but similar [laughter] powerful robot in your house and it's written by AI, and you tell it, "Hey, robot. I'm hungry. Make me the most delicious meal that you can that's healthy for me and satisfies all of these parameters using ingredients that are available in my kitchen." And if your cat happens to be in your kitchen and it realizes that, hey, this is lean meat. I have a great sense of what this person likes, so this is going to be really tasty. And it cooks your cat. [laughs] That's a way of satisfying this objective that you don't like.

+ +

And so if it understood something about what is it that makes people happy by learning from our emotional behaviors in everyday life, we're not often saying to this robot, "This is something that I don't want you to cook." But if the robot understood this is something that makes you happy in everyday life, that would be one proxy for it to be able to figure out this would be a negative on your well-being if it did this. And so that is ultimately the solution.

+ +

So we're going from; first, we at least want to optimize our algorithms existing today for people to feel better or indications of their well-being. And then, later on, we just want to make sure that, increasingly, that is the objective of these algorithms. I think that's been really important to me.

+ +

CHAD: Obviously, it's not like the other companies out there doing this want to create a robot that cooks your cat.

+ +

DR. COWEN: No. [laughs]

+ +

CHAD: But it is possible that other companies don't prioritize it in the same way that Hume might. How do you stay motivated in the face of maybe not everyone caring about creating this in the same way that you are?

+ +

DR. COWEN: That brings me to the other main reason for doing things this way, which is that I think there's enough of an economic incentive that you can create a company that is more successful for having made ethical commitments than otherwise. And I think that's particularly true if your company wasn't going to do anything unethical anyway, [laughs] which we didn't plan on doing and most companies don't plan on doing. Because if your company is not going to do anything unethical anyway, then you might as well be able to explain to people how you made the decision about what's ethical and what isn't and be able to make guarantees to them that actually attract more customers.

+ +

Because the customers are able to say, "Look, they've made a legal commitment to not doing this." I don't have to suspect that these things are being used against me or in a manipulative way or in a way that doesn't preserve the privacy that I thought I had. I don't have to be skeptical of any of these things because I can see clearly that the company has made this potentially legal commitment, at least that's something that they're committed to publicly." So in that sense, it's purely an advantage. And that's true for AI generally but specifically for empathic AI.

+ +

I think there's been a hunger for those kinds of ethical guidelines, and you can see it in how people react to news of this technology. There is generally a skepticism in the air. I think it goes back also to maybe sometimes people's concerns about privacy are legitimate if the question is whether what the output is picking up on is going to wind up in the hands of people you don't want it to end up in. And those people are privy to things about your lifestyle, or they're able to use that against you in some way. That is a real privacy issue. It's not necessarily, to me, a privacy issue.

+ +

If an algorithm is processing these things on device and the data never goes anywhere, and it's only used in a way in which you actually want it to be used, which is maybe to surface better music to you or to have you be taking better pictures on your phone, these are all great things for you.

+ +

And that data doesn't necessarily go anywhere in the same way that any of the photo data you take doesn't necessarily go anywhere even though it's already processed by lots and lots of algorithms, or your search queries aren't necessarily not private. Just because they're processed by algorithms, maybe even algorithms that are good for the business, they're not necessarily being seen by humans. And so, it's not necessarily a privacy issue.

+ +

But people have this skepticism about emotion AI, in particular, empathic AI, in particular, because I think there are certain instincts that it plays on, like the idea that you're being watched. Early in our species history and even before our species, it was very important to be very wary of predators watching you from the bushes or from the crevices and all that. And I think that instinct is involved whenever we're being recorded, whenever there's a camera.

+ +

And that's not just an issue for empathic AI but also for things like facial identification, which brings up legitimate privacy concerns but also, sometimes there are uses that we don't care about at all, or they're clearly good. Like, I think facial identification for unlocking your phone that's a really good use. And that is basically what it's used for by some companies. Some big tech companies are just using it for that and not much else.

+ +

And so, when you unpack what you're doing with this stuff, it makes it a lot easier for people to be comfortable with it. And that is what the ethics initiative is doing essentially. It's giving people all of these use cases and recipes and unpacking what this is being used for so that people can be more comfortable with it. And I think that's actually something that is in the business' interest.

+ +

CHAD: That's great. Well, I really appreciate, you know, there are a lot of pushes and pulls when founders are creating new companies. So to put a stake in the ground in terms of what's important to you and the right way to build this product and to go through the effort of creating these guidelines and a whole initiative around it and everything is...well, I can see that not everyone does that because of the concern around oh, is this going to hurt my business? Is it going to make it harder for me to succeed? And so when principals and business case align, great, but even when they don't, I think it's important, and I commend you for making sure that you're leading with your principals.

+ +

DR. COWEN: Thanks. I mean, there have certainly been challenges to it. But I think that even so, the pros have outweighed the cons both ethically and for our business for us so far.

+ +

CHAD: Great. So if folks have enjoyed today's conversation and either want to dig in more, you have a podcast, right?

+ +

DR. COWEN: That's right. We have a podcast called The Feelings Lab, where we explore different emotions that are of concern in everyday life, that guide our everyday lives, and that are changing as a consequence of changes in society and technology. In Season One, we focused mostly on one emotion per episode. We had guests like Fred Armisen talking about horror, which is a really funny perspective to have [laughs] because fear is not always bad, and sometimes we like to watch horror movies. [laughs]

+ +

And in Season Two, we're focusing particularly on the technology. And so we had the CEO of Embodied Paolo Pirjanian, who has a robot called Moxie that's used to help kids in their emotional development, and it's a great toy. We had the CEO, one of the co-founders of Soul Machines, which was an avatar company. We had VP at Omniverse Platform Developments in NVIDIA talking about how AI is changing the abilities of artists and changing basically the way that film is made. And it's very interesting. So I'd encourage people to check that out.

+ +

CHAD: Where can people find that? I assume by searching for Feelings Lab in the podcast player. But do you have a domain name too?

+ +

DR. COWEN: Yeah, you can go to hume.ai, and then you can go to our content hub. That's one way to find it. And you can find the podcast on Apple, SoundCloud, pretty much wherever you get podcasts. And we also have a YouTube channel, The Feelings Lab. Actually, I think the YouTube channel is Hume AI, and then we post content on The Feelings Lab there as well.

+ +

CHAD: And you mentioned people can sign up now to be on the list for the Hume AI.

+ +

DR. COWEN: So yes, if you are interested in building an empathic AI technology of any kind and you would like access to our voice models or face models, emotional language models, easy access, one-line API call for streaming or for files, pretty much any use case you might have, you can sign up for the waitlist at hume.ai. And we will be releasing a beta version of the platform over the next few months.

+ +

CHAD: Cool. Well, if folks want to get in touch with you or follow along with you, where are the places where they can do that?

+ +

DR. COWEN: Folks who want to get in touch, you can email hello@hume.ai for information about our solutions, offerings, the company, or you can reach out to me personally alan@hume.ai

+ +

CHAD: Awesome. Alan, thank you so much for joining me. I really appreciate it.

+ +

DR. COWEN: Thanks for having me.

+ +

CHAD: You can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Alan Cowen.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dr. Alan Cowen is the Executive Director of The Hume Initiative, a non-profit dedicated to the responsible advancement of AI with empathy, and CEO of Hume AI, an AI research lab and empathetic AI company that is hoping to pave the way for AI that improves our emotional well-being.

+ +

Chad talks with Alan about forming clear ethical guidelines around how this technology should be used because there is a problem in that the public is skeptical about whether technology is used for good or bad. The Hume Initiative is intended to lay out what concrete use cases will be and what use cases shouldn't be supported. Hume AI is built for developers to construct empathic abilities into their applications.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dr. Alan Cowen, the Executive Director of The Hume Initiative, a non-profit dedicated to the responsible advancement of AI with empathy, and CEO of Hume AI, an AI research lab and empathetic AI company. Alan, thank you for joining me.

+ +

DR. COWEN: Thanks for having me on.

+ +

CHAD: That's a lot of words in that introduction. I'm glad I got through it in one take. Let's take a step back a little bit and talk about the two different things, The Hume Initiative and Hume AI. And what came first?

+ +

DR. COWEN: So they were conceptualized at the same time. Practically speaking, Hume AI was started first only because it currently is the sole supporter of The Hume Initiative. But they were both conceptualized as this way to adjust two of the main problems that people have faced bringing empathic abilities to technology. Technology needs to have empathic abilities. If AI is going to get smart enough to make decisions on our behalf, it should understand whether those decisions are good or bad for our well-being. And a big part of that is understanding people's emotions because emotions are really what determine our well-being.

+ +

The Hume Initiative addresses one of the challenges, which is the formation of clear ethical guidelines around how this technology should be used. And it's not because the companies pursuing this have bad intents; that's not the point at all. The problem is that the public is probably justifiably skeptical of whether this technology will be used for them or against them. And The Hume Initiative is intended as a way of laying out what the concrete use cases will be and what use cases shouldn't be supported.

+ +

Hume AI is introducing solutions to the problem of how we build empathic AI algorithms. And the challenge there has been the data. So there have been a lot of attempts at building empathic AI or emotion AI, whatever you call it, basically ways of reading facial expression, emotion in the voice, and language. And there's been a few challenges, but most of them come down to the fact that the data tends to be based on outdated theories of emotion and/or it tends to be based on people's perceptual ratings of images largely from the internet or videos that are collected in more of an observational way without experimental control.

+ +

And within those perceptual judgments, you see gender biases, sometimes racial biases, biases by what people are wearing, whether they're wearing sunglasses, for example, because people with sunglasses for some reason are perceived as being proud. [laughter] And the algorithms will always label people with sunglasses as being proud if you're training the algorithm that way.

+ +

What you need basically is some way to control for people's identity, what they're wearing, get people's own self-reports as to what they're feeling or what they're expressing, and do it in a way that's somewhat randomized so that different people express a wide range of emotional behaviors in a wide range of contexts. And the contexts are somewhat randomized. So that's what we're doing with Hume AI is we're gathering that data, and it requires large-scale experiments to be run around the world.

+ +

CHAD: In terms of the actual product that Hume AI is going to do, is it a standalone product? Or is it something that people building products will use?

+ +

DR. COWEN: It's a developer product. It's built for developers to build empathic abilities into their applications. And so we are about to launch a developer portal, and we have a waitlist on our website on hume.ai for that. In the meantime, we've been licensing out the models that we're training and the data that we're using to train those models, which I actually kind of view as somewhat interchangeable. Models are basically descriptions of data. Some people have the resources to train those models on-premise; some people don't.

+ +

But we're providing the solution to any developer who wants to build the ability to understand, for example, vocal expression into, say, a digital assistant. So can the digital assistant understand when you're frustrated and be able to change its response based on that information? And even potentially update the actual network, the neural network that's being used to generate that response, actually, backpropagate the fact that this was an unsatisfactory response and make the algorithm better. Is this something that you could use for health tech?

+ +

So people are building out telehealth solutions that incorporate AI in various ways, one of which is can we get an objective classification of emotional behavior that can be used to help triage patients, send them to the right place, put them in touch with the right help? Can it be used to sub-diagnose disorders, diagnose disorders with more statistical power? Because you can incorporate more data and develop better treatments for those disorders, and that can be done in a wide range of contexts.

+ +

CHAD: So you mentioned training AI models. I don't want to make the assumption that everyone knows what that means or looks like. Maybe if we could take a step back, if you don't mind, talk about what that maybe traditionally looks like and how Hume is actually different.

+ +

DR. COWEN: Yeah, totally. When it comes to empathic AI, so this is an area where you're trying to train an algorithm to measure facial movements insofar as they have distinct meanings or measure inflections of the voice while people are speaking to understand the non-verbal indications of emotion in the voice. When you are training an algorithm to do that, you're taking in images, video, audio, and you're predicting people as attributions of emotion to themselves or to others and what people are feeling or what people say they're expressing or what other people say they hear in an expression. You need a lot of data for that.

+ +

Traditionally, people have used smaller datasets and assumed that emotion can be reduced to a few categories. That's been one solution to this problem. And so basically, you'll have people pose facial expressions of anger, fear, happiness, sadness, disgust, and surprise, which are called the basic six emotions. And that was introduced by Paul Ekman in the 1970s. And there are whole datasets of people posing those six expressions or perhaps combinations of them. And usually, those facial expressions are front-lit and front-facing and meet certain constraints.

+ +

And when you train a model on that data, it doesn't tend to generalize very well to naturalistic expressions that you encounter from day-to-day for a lot of different reasons; one is that the six basic emotions only capture about 30% of what people perceive in an expression. Another is that people in everyday situations have a wide range of lighting conditions, viewpoints, et cetera. And there's more diversity in age, gender than you see in these datasets and in ethnicity and so forth. And so, these algorithms don't generalize.

+ +

Another approach is to get ratings of data from the internet. So there, you're not creating the dataset for this specific purpose. You're just scraping as many facial expressions or recordings of voices as you possibly can, maybe from YouTube. That's one way to scale up. That's one way to capture a much greater variety of naturalistic expressions. But then you're gathering ratings of these images. And those ratings are influenced not just by what somebody is expressing but also by somebody's gender, ethnicity, age, and what they're wearing, and so forth.

+ +

CHAD: Well, in those scenarios, a person has also classified the image, to begin with, right?

+ +

DR. COWEN: Yeah.

+ +

CHAD: So someone is labeling that image as angry, for example.

+ +

DR. COWEN: So typically, you're scraping a bunch of videos. You're giving them to raters typically from one country. And those raters are categorizing those images based on what they perceive to be the expression, and there are a lot of influences on that. If somebody is wearing a sporting outfit, and this is a hard bit of context to cut out, you can generally infer this person is likely to be expressing triumph or disappointments or all the different things people express when they're playing sports. And it's very different if somebody's wearing a suit. And so, these different biases seep into the algorithm.

+ +

We did train probably the best version of this kind of algorithm when I was at Google. And we used it to study people's expressions in other videos from around the world, mostly home videos. And we found that people form expressions in characteristic contexts around the world. And the relationship between context and expression was largely preserved. We were looking at 16 facial expressions we were able to label accurately. And this was probably with the best version of an algorithm trained in this way. But we still only captured about half of the information people take away from expressions because we had to throw away a lot of the predictions due to these biases. So that's how algorithms are traditionally trained.

+ +

Another way that you could go about it is by training a large model, like a large language model, if you're looking at an emotional language and query it in a special way. So let's say you take a GPT-3 kind of model, and you say, "Hey, what are the emotions associated with this sentence?" And there, you see exactly the same kind of biases as you'd see in perceptual ratings because typically, it's saying what is likely to be in that data. So it might say, "Well, pigeons are disgusting, and doves are beautiful," or something like that. And that's the kind of bias we don't care about. But you can imagine there are a lot of biases that we do care about in that data too. [laughs]

+ +

And so, what's needed is experimental control. And I think this is actually when it comes to the things we really care about, something that people should consider more often in machine learning. What are the confounds that exist in the data that you're training an algorithm on? And if you really care about those confounds and you want to be scientific about it, about removing them, what's the solution? Well, the solution is to somehow randomize what somebody is expressing, for example. And that's what we do at Hume.

+ +

We actually gather data with people reacting, for example, to very strongly evocative stimuli, which could be images, videos, paintings, et cetera, music. And we have balanced the set of stimuli in a way that makes it richly evocative of as many emotions as possible. And then what somebody is likely to be experiencing in a given setting is randomized relative to who they are since they see a random set of these stimuli or they undergo a random set of tasks.

+ +

And so, to the extent possible, we've removed some of the relationships between ethnicity, gender, age, and what somebody is experiencing, or what they're expressing. And so we do this in a lot of different ways. And one thing you do is you can train on basically what is the stimulus that somebody was looking at instead of training on somebody's perception of an expression.

+ +

CHAD: Hopefully, talking through this a little bit has helped people, one, I guess, understand why this is difficult. And that's where the need for a product by a company that specializes in it is important because it would be pretty difficult for a company just getting started to be able to do this in a scientifically controlled way. And in a sense, it's sort of like pooling the resources behind one product to do it well, and that can really do it well. You recently raised money pre-seed from investors. How obvious was the need to them, and how easy or hard was it for you to raise money?

+ +

DR. COWEN: I had been basically in this world for a long time before I started Hume AI and The Hume Initiative. So during grad school, while I was publishing a lot of this science that was showing people's expressions were much more nuanced than a lot of these datasets and algorithms had considered before, I was getting inbounds from tech companies. And so, I worked a little bit with some startups. I worked with Facebook. I worked with Google. And I had seen this problem from a lot of different perspectives and viewpoints already.

+ +

The need for data was very clear. The need for algorithms was clear because people literally had reached out to me and asked, "What are the best algorithms?" And I had to say, "Look, there are a few things, but all of them have problems. And they're mostly focused on the face, and you won't see much for the voice. And you won't see much for language." And what I had trained at Google was not something that was publicly available for facial expression. What is available for language probably the best one is another dataset that I helped put together at Google and algorithms trained on that called the GoEmotions dataset, which is used by Hugging Faces emotional language algorithm.

+ +

And so I knew that there was this need, and a lot of people were looking for this kind of data, and so that's where it started. So talking to investors, it wasn't too hard to show them all the evidence that there was a need for this, a big market. And we raised a $5 million pre-seed. What we have spent a lot of that so far is in data collection. And that's made a huge difference in training algorithms for facial expression, voice, language, and so forth. And then what turns out to be more of a challenge is delivering those algorithms to people. And we're actually building a platform, an API platform, for that that will be really helpful in getting people started.

+ +

CHAD: As you took on investors who, you know, they're trying to build a business. They want to create a business that gives them a return. And as you move towards a product in the marketplace, what are the things that you've encountered that are the biggest concerns in terms of the success?

+ +

DR. COWEN: There's a scientific and sort of almost educational challenge. I think people have been fixated on a few ideas about emotion for a long time; these really sticky ideas like you can reduce emotion to six categories or two dimensions. So even when people take these really nuanced and accurate models that we've trained to distinguish 28 different kinds of facial expression, much broader array of facial expressions or 24 different kinds of vocal expression in vocal utterances like laughs, and cries, and screams, and sighs, and 16 different kinds of speech prosody, typically, people will take these, and they'll take out a few emotions, and they say, "Okay, well, this prediction is for the anger prediction, and that's the one I'm interested in."

+ +

The challenge is in conceptualizing the phenomenon people are interested in classifying with these models and how they can relate that to what the model is predicting because typically, what constitutes anger is very different from one situation to another. Someone who's angry, who is maybe playing a sport, is going to be much more vocal about it than if you're on a customer service call.

+ +

And that context is really important in going from an embedding that's general for different expressions, that can recognize 16 different emotional intonations in speech and fine-tuning it for that specific context. And I think that process can be difficult to understand if you're not fluent in the language of emotion science and particularly where it's gone over the last few years.

+ +

And so part of what we're doing now is actually setting up ways to visualize the outputs of our models really smoothly and with any data so that people can navigate their data and actually see, okay, well, what this model is saying is an embedding of anger for what I'm interested in. Maybe it's customer service calls. Actually, it's a combination of a little bit of contempt and a little bit of disappointment in what people have labeled these expressions with. And now I can take this embedding, and I understand how to use it better.

+ +

CHAD: Do you anticipate or hope for, and maybe those are the same, and maybe they're different, that you're going to have a few big customers or lots of small customers or something in between?

+ +

DR. COWEN: We hope lots of small customers. [laughs] I want to get this into as many people's hands as possible. A lot of people are doing really innovative things in the startup world. There's also a huge need in big applications like digital assistants that are mostly in the hands of a few companies basically. We want to have an impact there as well.

+ +

The difference, of course, will be the manner in which these solutions are delivered. The ease of providing people with APIs, subscribing to a pay-as-you-go model I think is really attractive for startups. And so that's how we're accessing that market. On the other hand, we do already have some big customers who are licensing the data or the models themselves. And I anticipate there will be a lot of that going forward as well.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: You said you've built up to this point. But how long have you been working at it so far in terms of creating the actual product that will go to market soon?

+ +

DR. COWEN: The company is only a year old. And we actually just had our first year anniversary.

+ +

CHAD: Congratulations.

+ +

DR. COWEN: [laughs] Thank you. Thank you. We are just now about to launch our platform, which I think is going to be our main product going forward. We're also running machine learning competitions in the research community, which there will be involvement from lots of tech companies and researchers around the world. So in many ways, we're still just getting started.

+ +

But we have already what I think are the best models for understanding facial expression, the best models for understanding vocal utterances or what we call vocal bursts, which is actually different than understanding speech prosody or emotional intonation and language more generally. And we need separate models for that. We have both of probably the best models for those two modalities and are building what we think will be the best model for emotional language as well. And so we have solutions. Part of the product is delivering them, and that's what we're launching now. So we're at the beginning of that.

+ +

CHAD: So has to get to this point taken longer than you were anticipating, the time you were anticipating or shorter? Did it go faster?

+ +

DR. COWEN: I think my estimates for actually training these models and beating the state of the art were about on point. [chuckles] I mean, when we got started, I was ready to start running these experiments pretty quickly. So I designed all the experiments myself and started running them around the world, recruiting participants through labs, through consulting agencies, through crowdsourcing websites, a lot of different ways.

+ +

There were a few challenges along the way, like figuring out how you could adjust the consent form in ways that weren't really relevant to ethics. And we had IRB approval. We had a very robust consent process for people to understand how their data was going to be used but were relevant to figuring out how you come up with language that is consistent with data privacy laws and each individual jurisdiction where you're running data collection. That took a little longer than I thought. [laughs]

+ +

But suffice to say, we had the data. We had the models pretty quickly. I was able to recruit some of the top AI researchers in this space pretty quickly. We hit the ground running. We were able to take the data and train state-of-the-art models pretty fast. What's taking longer is getting the models into people's hands in two ways. I mean, negotiating enterprise contracts is always a struggle that many people are aware of. And then figuring out we needed to have a really user-friendly platform basically to deliver the models through APIs, and that's taking a little bit longer than anticipated.

+ +

CHAD: So The Hume Initiative is a group of people that have come together and established some guidelines that companies sign on to in terms of what their solutions are going to take into account and do and not do. Do I have that right?

+ +

DR. COWEN: Yeah. So we put together a separate non-profit. And we brought together some of the leading AI researchers, ethicists, with emotion scientists, and cyber law experts to this very unique composition of domain knowledge to develop what are really the first concrete ethical guidelines for empathic AI. Let's say for this use case; we support it if you meet these requirements. These are our recommendations. And for this use case, we don't support it. And we actually get really concrete.

+ +

I think generally, with AI principles efforts or AI ethics efforts, people focus on the broad principles and left it to, I don't know, it's unclear often who is going to decide whether a use case is admissible or not under these principles. Because let's say they're codified into law, then it'll end up being a judge who doesn't necessarily have any knowledge of AI or emotion science or any of these things to say this is a use case that's consistent with these principles or not. We wanted to avoid that.

+ +

And I think particularly; I think that the public is skeptical too of broader principles where they don't really know whether a given use of their data is compliant with those principles or not. I mean, sometimes it's easier. There are really good policies regarding surveillance that I think most of the big tech companies ascribe to where they say they won't be using your data in ways that you expect to have privacy and you actually don't. So I think there are pretty good principles there.

+ +

There haven't really been good principles or concrete guidelines for what people might consider manipulative. And I think some technology that incorporates cues of emotion can be deemed manipulative in a sense. In the sense that you might not want to be sucked into a comment thread because something really provocative was shown to you after clicking on a notification that was unrelated to that. But the algorithm may have figured out this is a way to keep you in the app. [laughs] So that can be considered manipulative in some kind of way.

+ +

I mean, it's bad if the person is vulnerable at that time. If the algorithm is able to read cues of your emotions and maybe through interoperability across different applications or because it knows it or has this information, this data already, it can say this is a person who is vulnerable right now to being provoked because they're in a bad mood. Maybe I can see that they just ordered food, and it's late, and it was canceled, whatever is. It can be any number of things. Or the way that this person queried a digital assistant or a search engine revealed this kind of emotional state. We don't want the algorithm to use that to get us to do something we otherwise wouldn't want to do

+ +

So the principles we've set up around that are really important. Whenever somebody's emotional behaviors are involved or cues to their emotional state, they should be used to make sure that the algorithm is not using these cues against somebody or using them as a means to an end. What they should be used to do is make sure the algorithm is improving our emotions or improving our emotional state over time on average across many different people so that we're less frustrated on average over time, and we have more instances where we're satisfied, or content, or happy, or all inspired or whatever your measures or indicators of well-being you have present through these behaviors might be.

+ +

The algorithm should be using these behaviors to enhance your well-being fundamentally. And wherever they're entering into an algorithm, we should be privy to how the algorithm is using them. And so that's essentially what the principles codify and make very concrete, and they say, "In this use case, this is how you can make sure this is the case, you know, health and wellness, digital assistants, photo-taking, arts and culture applications, film, animation." There are all these different applications of empathic AI.

+ +

So it's a very broadly applicable thing because it applies to any text, any video with people in it, any audio where you hear people's voices. This is just a part of the data that's untapped relatively, or to the extent that it's tapped by algorithms today; it's done in a way that we don't really see, or maybe the developers don't even realize. If we make explicit that these are cues to people's emotions, there's a huge number of applications where we can then have algorithms learn from people's emotional cues and decide whether to enhance certain emotions or use them in certain ways.

+ +

So I think it's going to be really, really key to get this right. And it requires expertise in how these emotions operate in daily life, in emotion science, in what is the definition of privacy here? What's the definition of a biometric measure which involves cyber law? And how does this intersect with existing laws and so forth? It's something that requires AI research expertise. You have to know how these algorithms work.

+ +

It's something that requires specific kinds of AI ethics expertise. What is the alignment problem? How do we consider the value alignment in this situation? Which I think really comes down to optimizing for people's well-being. And we have brought together exactly that composition of expertise in The Hume Initiative.

+ +

CHAD: Hume AI has sort of signed off and said, "We're going to follow these guidelines of The Hume Initiative." Does that apply to every customer who is a customer of Hume AI?

+ +

DR. COWEN: Exactly, yeah. So we actually require people on our terms of use to adhere to the guidelines. And so, for a lot of people, that won't be that difficult because they'll look through the guidelines. They'll see that their use case is supported, that they're already following the recommendations that are in the guidelines. And so they're good. They're good to go. Some people might [laughs] see that they're not compliant with the recommendations. And then they'll be able to make adjustments to their product so that they're compliant.

+ +

And then others who are pursuing use cases that are not supported by the ethics guidelines can't use the platform, which is exactly what we want. We don't want people using this for mass surveillance, for example, and that's stated pretty clearly in the guidelines. So yeah, we do require all of our customers to adhere to these guidelines that we've now launched at thehumeinitiative.org.

+ +

CHAD: How important to you was it to have The Hume Initiative and these guidelines? Was it a precondition of doing all of this?

+ +

DR. COWEN: Yeah, it was important for two reasons; one is that I felt that this shouldn't be used to exacerbate a lot of the problems that we're going to run into with AI eventually, if not already, where AI could be using our emotional behaviors to optimize for an objective that could be misaligned potentially with our desires, what emotions we want to feel, or with our well-being. Even though when you're privy to these emotional behaviors, you have the opportunity to do what a human does and say, "I have empathy. Therefore, I can say this is probably not a good way to get people to spend more time on this app or to buy this thing because I know that it's exploitative in some way." And I don't think that's the norm.

+ +

I think, by and large, these strategies that have been used to optimize AI algorithms today have been good proxies for our well-being. Like, engagement is not necessarily a bad proxy for whether we want to spend time on doing something, but it's not good in all cases. And I think there's a huge amount of room for improvement because we don't know in all cases how the AI is getting us to be more engaged. And many of the strategies it uses may not be consistent with our well-being.

+ +

But particularly going forward, once AI is smart enough, and once it has more control points in the environment, whether there are robots or digital assistants that have control over Internet of Things devices, AI will have an increasing influence on the environment around us, and it'll be smarter and smarter. And before long, it will be very important to make sure that it's aligned with our values. This is the concept of the alignment problem.

+ +

Eventually, if you have a really, really smart, all-powerful, not all-powerful, but similar [laughter] powerful robot in your house and it's written by AI, and you tell it, "Hey, robot. I'm hungry. Make me the most delicious meal that you can that's healthy for me and satisfies all of these parameters using ingredients that are available in my kitchen." And if your cat happens to be in your kitchen and it realizes that, hey, this is lean meat. I have a great sense of what this person likes, so this is going to be really tasty. And it cooks your cat. [laughs] That's a way of satisfying this objective that you don't like.

+ +

And so if it understood something about what is it that makes people happy by learning from our emotional behaviors in everyday life, we're not often saying to this robot, "This is something that I don't want you to cook." But if the robot understood this is something that makes you happy in everyday life, that would be one proxy for it to be able to figure out this would be a negative on your well-being if it did this. And so that is ultimately the solution.

+ +

So we're going from; first, we at least want to optimize our algorithms existing today for people to feel better or indications of their well-being. And then, later on, we just want to make sure that, increasingly, that is the objective of these algorithms. I think that's been really important to me.

+ +

CHAD: Obviously, it's not like the other companies out there doing this want to create a robot that cooks your cat.

+ +

DR. COWEN: No. [laughs]

+ +

CHAD: But it is possible that other companies don't prioritize it in the same way that Hume might. How do you stay motivated in the face of maybe not everyone caring about creating this in the same way that you are?

+ +

DR. COWEN: That brings me to the other main reason for doing things this way, which is that I think there's enough of an economic incentive that you can create a company that is more successful for having made ethical commitments than otherwise. And I think that's particularly true if your company wasn't going to do anything unethical anyway, [laughs] which we didn't plan on doing and most companies don't plan on doing. Because if your company is not going to do anything unethical anyway, then you might as well be able to explain to people how you made the decision about what's ethical and what isn't and be able to make guarantees to them that actually attract more customers.

+ +

Because the customers are able to say, "Look, they've made a legal commitment to not doing this." I don't have to suspect that these things are being used against me or in a manipulative way or in a way that doesn't preserve the privacy that I thought I had. I don't have to be skeptical of any of these things because I can see clearly that the company has made this potentially legal commitment, at least that's something that they're committed to publicly." So in that sense, it's purely an advantage. And that's true for AI generally but specifically for empathic AI.

+ +

I think there's been a hunger for those kinds of ethical guidelines, and you can see it in how people react to news of this technology. There is generally a skepticism in the air. I think it goes back also to maybe sometimes people's concerns about privacy are legitimate if the question is whether what the output is picking up on is going to wind up in the hands of people you don't want it to end up in. And those people are privy to things about your lifestyle, or they're able to use that against you in some way. That is a real privacy issue. It's not necessarily, to me, a privacy issue.

+ +

If an algorithm is processing these things on device and the data never goes anywhere, and it's only used in a way in which you actually want it to be used, which is maybe to surface better music to you or to have you be taking better pictures on your phone, these are all great things for you.

+ +

And that data doesn't necessarily go anywhere in the same way that any of the photo data you take doesn't necessarily go anywhere even though it's already processed by lots and lots of algorithms, or your search queries aren't necessarily not private. Just because they're processed by algorithms, maybe even algorithms that are good for the business, they're not necessarily being seen by humans. And so, it's not necessarily a privacy issue.

+ +

But people have this skepticism about emotion AI, in particular, empathic AI, in particular, because I think there are certain instincts that it plays on, like the idea that you're being watched. Early in our species history and even before our species, it was very important to be very wary of predators watching you from the bushes or from the crevices and all that. And I think that instinct is involved whenever we're being recorded, whenever there's a camera.

+ +

And that's not just an issue for empathic AI but also for things like facial identification, which brings up legitimate privacy concerns but also, sometimes there are uses that we don't care about at all, or they're clearly good. Like, I think facial identification for unlocking your phone that's a really good use. And that is basically what it's used for by some companies. Some big tech companies are just using it for that and not much else.

+ +

And so, when you unpack what you're doing with this stuff, it makes it a lot easier for people to be comfortable with it. And that is what the ethics initiative is doing essentially. It's giving people all of these use cases and recipes and unpacking what this is being used for so that people can be more comfortable with it. And I think that's actually something that is in the business' interest.

+ +

CHAD: That's great. Well, I really appreciate, you know, there are a lot of pushes and pulls when founders are creating new companies. So to put a stake in the ground in terms of what's important to you and the right way to build this product and to go through the effort of creating these guidelines and a whole initiative around it and everything is...well, I can see that not everyone does that because of the concern around oh, is this going to hurt my business? Is it going to make it harder for me to succeed? And so when principals and business case align, great, but even when they don't, I think it's important, and I commend you for making sure that you're leading with your principals.

+ +

DR. COWEN: Thanks. I mean, there have certainly been challenges to it. But I think that even so, the pros have outweighed the cons both ethically and for our business for us so far.

+ +

CHAD: Great. So if folks have enjoyed today's conversation and either want to dig in more, you have a podcast, right?

+ +

DR. COWEN: That's right. We have a podcast called The Feelings Lab, where we explore different emotions that are of concern in everyday life, that guide our everyday lives, and that are changing as a consequence of changes in society and technology. In Season One, we focused mostly on one emotion per episode. We had guests like Fred Armisen talking about horror, which is a really funny perspective to have [laughs] because fear is not always bad, and sometimes we like to watch horror movies. [laughs]

+ +

And in Season Two, we're focusing particularly on the technology. And so we had the CEO of Embodied Paolo Pirjanian, who has a robot called Moxie that's used to help kids in their emotional development, and it's a great toy. We had the CEO, one of the co-founders of Soul Machines, which was an avatar company. We had VP at Omniverse Platform Developments in NVIDIA talking about how AI is changing the abilities of artists and changing basically the way that film is made. And it's very interesting. So I'd encourage people to check that out.

+ +

CHAD: Where can people find that? I assume by searching for Feelings Lab in the podcast player. But do you have a domain name too?

+ +

DR. COWEN: Yeah, you can go to hume.ai, and then you can go to our content hub. That's one way to find it. And you can find the podcast on Apple, SoundCloud, pretty much wherever you get podcasts. And we also have a YouTube channel, The Feelings Lab. Actually, I think the YouTube channel is Hume AI, and then we post content on The Feelings Lab there as well.

+ +

CHAD: And you mentioned people can sign up now to be on the list for the Hume AI.

+ +

DR. COWEN: So yes, if you are interested in building an empathic AI technology of any kind and you would like access to our voice models or face models, emotional language models, easy access, one-line API call for streaming or for files, pretty much any use case you might have, you can sign up for the waitlist at hume.ai. And we will be releasing a beta version of the platform over the next few months.

+ +

CHAD: Cool. Well, if folks want to get in touch with you or follow along with you, where are the places where they can do that?

+ +

DR. COWEN: Folks who want to get in touch, you can email hello@hume.ai for information about our solutions, offerings, the company, or you can reach out to me personally alan@hume.ai

+ +

CHAD: Awesome. Alan, thank you so much for joining me. I really appreciate it.

+ +

DR. COWEN: Thanks for having me.

+ +

CHAD: You can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter at @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Alan Cowen.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7yOk2iZF + + ]]> + + Chad Pytel + Alan Cowen + + + 416: The ParentPreneur Foundation with James Oliver Jr. + https://podcast.thoughtbot.com/416 + 325b8304-b6ec-457e-839f-de32197b4382 + Thu, 31 Mar 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + James Oliver Jr. is the Founder and CEO of The ParentPreneur Foundation, which empowers Black ParentPreneurs so they can leave a legacy for their beautiful Black children. + +Chad talks with James about inspiring, encouraging, and supporting ParentPreneurs to lobby to try to close wealth inequality gaps, shoot their shot and send cold emails, and engage in a community that supports one another. + 37:41 + no + + + James Oliver Jr. is the Founder and CEO of The ParentPreneur Foundation, which empowers Black ParentPreneurs so they can leave a legacy for their beautiful Black children. +Chad talks with James about inspiring, encouraging, and supporting ParentPreneurs to lobby to try to close wealth inequality gaps, shoot their shot and send cold emails, and engage in a community that supports one another. +Parents Making Profits (https://www.parentsmakingprofits.com/) +The ParentPreneur Foundation (https://www.parentpreneurfoundation.org/) +Follow The ParentPreneur Foundation on Twitter (https://twitter.com/ParentPreneurF), LinkedIn (https://www.linkedin.com/company/parentpreneur-foundation/), or Instagram (https://www.instagram.com/parentpreneurfoundation/). +Follow James on Twitter (https://twitter.com/jamesoliverjr) or LinkedIn (https://www.linkedin.com/in/james-oliver-jr/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is James Oliver Jr., Founder, and CEO of the ParentPreneur Foundation, which empowers Black ParentPreneurs so they can leave a legacy for their beautiful Black children. James, thanks for joining me. +JAMES: I'm super excited to be here. Thanks so much for having me. +CHAD: So I just said, in a nutshell, the tagline for ParentPreneur Foundation. I know it's a community that brings people together, Black ParentPreneurs together. How did you get started and see the need for this, and how did you actually then make it happen? +JAMES: Oh boy, that's a great question with a semi-long answer, so just hang in with me, but I think it's a really compelling story. So back in 2013, (I'm from Brooklyn, New York) at the time, I was living in Northeast Wisconsin. It started in 2011. I was trying to build a startup called WeMontage, which was the world's only website to let you turn your digital images into removable photo wallpaper. +CHAD: If you haven't seen it, by the way, you should look at it. That description that you gave, even though it describes it perfectly, I didn't realize until I went to the website and looked at the pictures exactly what it is and how remarkable of a product it is. +JAMES: Well, I'm delighted that you say that. Thank you so much. And that's part of the reason why [laughter] it failed. I mean, it's still around. And I know we have a bunch of designers in the community. So look, the website still works. The underlying collage editing software is still brilliant, but the UI UX needs a lot of love. It's a bit of a zombie with about $10,000-$15,000 of technical debt floating around over there. [laughs] But the product still works. And we still print, ship them sometimes. And we have tons of repeat customers. It's just one of those things. You build a great product, and they will always come. But the product is still brilliant still today. +So back then, I was a non-technical founder. I was out of money. I cleaned out my savings and living in the middle of nowhere. There wasn't exactly a bastion of technology startups or diversity, even for that matter. And I was fortunate to get into Gener8tor's...I think we were the second cohort. Back then, it was super early. We went to Madison. And right now, Gener8tor is killing it. +But I was out of money. I was thankful to get into their Madison cohort, which was a two-hour drive away. My ex-wife now was pregnant with our twins. The kids were supposed to be born end of March. Gener8tor ended early April. So I was like, okay, this timing works out brilliantly. But a day or two before the program started, I had to deliver, and we had to deliver the twins prematurely. Otherwise, my son would have died. +CHAD: Wow. +JAMES: His blood just started to circulate backwards. It was crazy. So we had to take them out. They weighed two pounds apiece. Every time I tell this story, it gives me agita, man. The accelerator was a two-hour drive each way back and forth to the NICU, waking up at 2:00 a.m. every morning because I couldn't sleep. I cried every day. I had a really talented developer on my team, but he had his personal demons. So he was really unreliable. But he was a brilliant guy. He was so smart, really talented. +But anyway, I got through the accelerator. Right before I was going on stage for demo day, I got a call from this angel that we pitched. We were raising $250,000 at the time, which really, in retrospect, was not nearly enough money. But I got a call. He said, "Hey, we're going to fill your round." I don't know. What does that mean? I don't take anything for granted. [laughs] What do you mean? "We're going to give you $250,000." +And then I just dropped to my knees. I thanked God. And I cried because I had sacrificed so much to get to that point. Thankfully, my daughter came home after six weeks, and my son came home after ten weeks. The kids are doing fine. They drive me crazy, but they're beautiful. +CHAD: [laughs] How old are they now? +JAMES: They just turned 9 in January. So after I launched WeMontage, I hired just a really remarkable technical co-founder and just a great guy. We still have a wonderful relationship. We got in there, and when I started out, I was like, well, I'm going to start a blog. I started a blog, and I was like, one of these days, I'm going to use the content from this blog to write a book. +CHAD: Before you move on, so in those early days, you had just gotten into the accelerator. You had this thing you needed to deal with with your family and delivering the twins. And did you ever consider dropping out of the accelerator at that point? +JAMES: I wasn't going to go, but I knew with that decision, WeMontage never would have come to light because I just didn't have the resources to make it happen. But as a family, we decided that I need to go do that and crush that, and so I made that choice. We raised money. In retrospect, we raised just enough money to fail because, look, the software was cute. We were running around pitching angels. It was cute to show look at what we can do, look at what we could do. When we turned the thing on, it was so unsustainable. It was a black box. +And I was on the phone literally with customers holding their hand to get them to place an order, and that was clearly unsustainable. So we made the decision that we need to fix this thing. We need to pull it apart, make it modular, stabilize the code, build on it. And by the time we got done with that, we only had a couple of months' cash left. +And I remember...man, if anybody has never told you this to your face, I promise you it's a hard thing to hear. They were like, "We're not going to throw good money after bad." I'm like, well, damn. Like, thanks. We have our first Today Show appearance coming up here next month. So thank you for that. Thanks. [laughs] Man. +CHAD: So you actually did go on the Today Show. +JAMES: Yeah, we got featured three times on the Today Show. I mean, on my own without a publicist, I got Today Show three times, Good Morning America, Money Magazine, DIY, Martha Stewart, on and on. +CHAD: I'm curious, after making an appearance like that, do your sales go up? +JAMES: They do. They did with the Today Show. So it was funny, like that first appearance, they didn't even put the graphic on the bottom with the name of the business. When Mario mentioned it, he said, "wemontage.com." Man, our freaking website went crazy. It crashed the website. [laughs] But we were kind of already prepared for it to crash. We had a little splash screen up and information. We got it back up in; I don't know, it was less than an hour. +But I spent literally all day getting back to those people. We gave them a coupon code. And we did about $15,000 that month from that one segment, which was great. That was our best month to date. I mean, all total, I've probably done $75,000 to $80,000 in sales from the three times we appeared on The Today Show. +CHAD: That's great. We've had clients, or I've known people who have done appearances like that, and it seems a little bit hit or miss. Sometimes it won't even result in a blip, and other times it's huge. And I'm not sure what the trend is when it matters and when it doesn't. +JAMES: This is the point: we all love these vanity things. We want to get exposure, exposure. So I have a really great relationship with Seth Godin, and he's a big supporter of the work I'm doing at ParentPreneur Foundation. He gives us scholarships to his marketing seminar, and he comes to visit with us sometime. The last time he talked about...he said, "Stop trying to do things to get attention. Spend your time getting your customers to tell their friends about your business." And that's a whole fact. +We love the vanity, but at the end of the day, PR does not necessarily equal cash flow. I had some hits. I got on Good Morning America, and that was not nearly as good as the Today Show. But that was by virtue of the last-minute change that they made in terms of how they were producing the segment. When they introduced my product, they had the camera on somebody else's product. They had people calling me about somebody else's stuff which is like, are you serious? But what are you going to do? You can't control that. +So yeah, those things are good. I will say that having that stuff on the landing page is good for credibility. People feel more comfortable, especially if they can see it. So that stuff matters to a point, but I wouldn't be spending a lot of time. I certainly would not be wasting a penny on a PR professional if I was a founder. I just wouldn't do it. All that stuff I rattled off I did on my own. +CHAD: Awesome. So you started to build a blog. [laughs] +JAMES: Yes. So the intention of that was to use that content to write a book to inspire ParentPreneurs around the world because it's hard being a parent and entrepreneur, especially if you're like early-stage scraping to get some revenue. You can't even talk about product-market fit yet. Can we make some money? [laughs] Can we make a buck? +CHAD: So I've done a few things in my life. Writing books is one of them, and I can't say that it's easy. I don't know how you found it. I was doing it with a traditional publisher the first few times around, and it was pretty difficult. How did you find it? +JAMES: So I self-published that book. And because of the way I approached it, I already had a bunch of content on my blog. It's funny; I was actually out of town. I was in Midland, Texas, because I got flown out there. I was on CNBC's version of Shark Tank, West Texas Investors Club, horrible experience, by the way. I swear if I ever go on another one of those shows, I'm going to bring the drama. +CHAD: [laughs] +JAMES: Piece of advice, for any of you guys listening, if you go on Shark Tank or any of those shows, do not leave it up to the creative people to tell a story about you. This is just me; I'm a little crazy, crazy like a fox. But you give them the story. So this is me and you talking, just the two of us. [laughs] If I go on Shark Tank or something like that, I'm not taking those people's money. They're going to be like, "Oh, well, you're just here clearly for the exposure." I'm like, well, so are you. You're doing it too. +Why should I give you 20% equity in my company for $200,000 or whatever it is? How much time are you actually going to spend helping me build my company? And by the way, the people who came before you from an investment standpoint already took a ton of risk off the table. So why should you get that money? And how many companies are in your portfolio? 50? So, okay, so are you really going to be helping me or nah? Nah? Right. No, I'm good. +CHAD: That'll definitely air. The producers will love that drama. +JAMES: That will air, right? See what I'm saying? And the people watching will be like, "Hell yeah, you tell them. Let me Google that real quick." [laughter] +CHAD: That's funny. +JAMES: But that's just me. But I have no intention of going back on any of those shows again because, at the end of the day, it was a bad experience for me. I only got about $6,000 in sales, but that's because nobody was watching that show. It was canceled. But at the end of the day, if you have a customer acquisition problem which is what we had at WeMontage, those things don't solve your problems. They just don't. Not necessarily. They could; you could get lucky. But it's probably not going to solve your problem. +CHAD: So I'm curious. So you wrote the book, and you focused on the concept of ParentPreneurs, Black ParentPreneurs specifically. +JAMES: No, actually, so the book was just for everybody who's a ParentPreneur. So the book's called The More You Hustle, The Luckier You Get: You CAN Be a Successful ParentPreneur. So Mario Armstrong, who's my guy from the Today Show, wrote the foreword to my book. We're really good friends. And it's on Amazon. +Some people have regarded it as the realest book of entrepreneurship they've ever read. It's unlike anything you ever read. It's the story of my journey, some of those things I just told you, and the up and down the back and forth. It will make you laugh, make you cry, make you wonder. You put it down, come back to it. There are some hard questions that I ask myself, and people read the book. It's a superfast read too. +CHAD: Awesome. At what point did you decide to focus on empowering Black ParentPreneurs? +JAMES: So that's a great question. So after I wrote the book, I had this idea. I said one day I'm going to sell WeMontage. And maybe it will happen. I don't know; if God can intervene, something could happen. Who knows? [laughter] It's just not likely at this point, and that's okay. But I was like, I'm going to sell this business. I'm going to take a million dollars of my own money and start a foundation for parents who are entrepreneurs because it's really freaking hard. It's so hard. Unless you've been there, you have no idea how hard that is. It's really hard. +So then, in early 2020, the whole world falls apart with George Floyd, Ahmaud Arbery, Breonna Taylor. I had my own Karen experience here in my backyard. I live in a really nice neighborhood in the suburbs of Atlanta. And I had to call the police on her. After the second experience, I filed a trespass warrant. Then I started looking at all the Federal Reserve wealth inequality data. +And I was like, I'm starting this foundation for Black ParentPreneurs because we need the help the most. We have got to try to close this wealth inequality gap. It's a big problem. I'm doing that. So now to answer your question, prior to that decision, so when I was going to Gener8tor, I met David Cohen and Brad Feld. They just popped up on a Google Meet to meet us. And these guys are co-founders of Techstars, which is one of the preeminent global startup accelerators. +And I just stayed in touch with them through their blogs. I didn't want anything from them. I remember I got an email from Brad a couple years back. And he's a voracious reader. He's a prolific writer. He sent me an email out of the blue. He said, "I just read your book. I effing loved it." [chuckles] He said, "I got to feature it on my blog." I was like, wow, okay, dope. So he did that. And we sold some books, which was great. +But so I reached out to Brad and David. I was like, "Hey, guys, I'm thinking about starting this foundation for ParentPreneurs in general." And they were like, "Yeah, I'm game. We can go back and forth with you about it," and which is amazing at that level those guys would be willing to do that. I appreciated that. And they were both like, "Eh, foundations are hard. It's a constant fundraising grind, blah, blah, blah." +And, look, they're not wrong. [laughs] They're not wrong. But here's the thing, though. For me, telling me something is hard doesn't land with me because I've had to scrap and scrape for every single blade of grass on the field of life. And quite frankly, it's hard being Black sometimes. If I had $1 every time somebody told me that WeMontage would have been successful if I had a white face out there instead of me type thing, it is very frustrating. +So then I got an email from Brad Feld out the blue after George Floyd, which was just a subject that said, "Hey, you're game for a 30-minute Zoom?" There was nothing in the body of the email. And I'm just like, yeah, I could as well want to talk to Brad. He's top of the food chain. He's not just a VC and co-founder of Techstars with a portfolio valuation north of $200 billion. He's also a Limited Partner. LPs are the people who write the checks to the VCs who write the checks to people like me and you guys listening who are entrepreneurs. +So I'm like, hell yeah, I want to talk to you for 30 minutes, Brad Feld. Who doesn't? I just didn't know what it was about. So he said, "I just want to know what two things you're working on addressing racial injustice, inequality I can put my time on or attention on." I'm like, Oh, hell yeah. Chad, I'm like, he has no idea what I just decided. +So we get on to Zoom. And I say, "You know, Brad, you remember that foundation thing I was telling you about?" He was like, "Yeah." I said, "Well, now that's just what Black ParentPreneurs is." He goes, "I'm so glad you did that." And this is the part that knocks me out of my chair every time I say it. He goes, "What would a 12-month operating plan look like? I can throw it up in a Google Doc, and I'll co-create it with you." [laughs] +CHAD: That's great. I mean, it is unfortunate that George Floyd being murdered and these other things have instigated people to want to make change and to get involved in ways that they haven't been able to before. That's super unfortunate, but something's got to wake people up. +JAMES: Well, that will come up because he was like, "Look, I'm this rich, middle-aged white dude. I've been doing things to support Black entrepreneurs in the past," but he's like, "I got to do more. So I'm reaching out to my friends, and I consider you a friend." I was like, wow, like, I knew you liked me a little bit, but I didn't know you liked me like that. +CHAD: [laughs] +JAMES: But he is a friend. I have his phone number. I can call him. He's a friend. Him and David these guys are friends. So I got the 12-month operating plan right back to him. He said, "This is great. What would a six-month plan look like?" I got to write back. And he's like, "Assume three things, one of which is a $50 000 seed grant from my foundation to start the ParentPreneur Foundation." So Brad has given now, I don't know, north of $125,000. He got us into the Techstars Foundation, which has been phenomenal. +My relationship with David has blossomed. I went on the Techstars Give First Podcast with David, and David's a friend as well. I just love those guys and how they move, and they've been super helpful. And so our foundation, at the heart of what we do, you mentioned this at the top, is we have a community of now almost 1,800 Black ParentPreneurs hosted on Mighty Networks, which is phenomenal because it's not on Facebook. That's the thing I love the most about it. +[laughter] +CHAD: I actually have some questions about Mighty Networks on my list. So we don't need to take a tangent in there right now. We can come back to it. I want to ask you about Mighty Networks. +JAMES: Love it. Love it. Love Gina Bianchini. She's the CEO. I actually had her on my LinkedIn live show a couple of months ago. +CHAD: Well, let's do it now then, actually. So as someone who has built software before to put together a company, did you ever consider that for this? And why not? And why use Mighty Networks? +JAMES: To build a community platform? +CHAD: [laughs] It's a very loaded question, James. +JAMES: Yeah, why would I do that? Listen, by the time I got done with my prototype with that; these guys would be like two versions past where they are today, which would be infinitely better than my little stinky MVP, right? +CHAD: Yeah. +JAMES: And these people live, eat, and breathe community. Is Mighty Networks perfect? No, of course not. But they're constantly making improvements. I think I told you at the top I'm actually about to launch a new podcast. I just signed a national podcast distribution deal. So we're launching a podcast on the HubSpot Podcast Network. You guys have heard of HubSpot, right? +CHAD: I have, yes. +JAMES: So it's for ParentPreneurs in general, kind of like my book, to empower ParentPreneurs to be the best parent entrepreneur they can possibly be because being a ParentPreneur is hard. And we came upon this opportunity. I saw an article; maybe LinkedIn, I don't remember, talking about HubSpot launched a new podcast network last year. And I told you I got all these PR opportunities. And I got that because I'm not shy about shooting my shot. +A lot of people are too scared to shoot their shot, or they don't know what to do, how to do it. But cold emails I'm really good at sending cold emails. So I sent a cold email to the CMO of HubSpot. He was mentioned in the article. I went on LinkedIn. I scraped his email address using my favorite email scraping tool, GetEmail.io. It works on LinkedIn. You get their email address. I sent him an awesome email. Of course, he didn't follow up right away; well, not, of course, sometimes they do. He didn't follow up right away. I sent a follow-up email. And when I send follow-up emails, I like to give some kind of update. +So in my follow-up email, I wasn't just like, "Hey, did you get my email? Please respond." It wasn't that. It was like some other update. I can't remember what it was, but it was an update following up about my email. He got back, copied somebody on the team. They got back, copied somebody else. They were like, "Do you have a clip or an excerpt of an interview?" And it just so happened we did because we knew we needed to get ready. So we did an interview with Neil Sales-Griffin, who's the Techstar Chicago Managing Director, and so we sent them an excerpt. +They were like, "This is great. Do you have a whole episode?" So we edited that thing down right here that day. It was a Friday, sent it to them. They were like, "Thanks for sending. We'll get back to you by Monday with the decision because, by the way, we have this new program, this emerging podcast voices program. There'll be six to eight podcasts in this program. And we'll listen to this and consider it." So they got back to us Sunday night at 11:00 o'clock. "This is amazing. You guys are pros." I'm like, that's not me. That's really Mario. I have no idea what I'm doing at all. +CHAD: [laughs] +JAMES: But thanks, Mario. "And you guys are stars. You can't teach stars." But I'm like, hey, all right. I've never done a podcast. But hey, glad somebody other than my mama likes me. This is awesome. And they were like, "We want to invite you to be one of the companies in this new cohort with a new podcast," and just a swoop in at the last minute like that all because I shot my shot. So if anybody's out there listening, don't be afraid to shoot your shot, man. It's a mindset. You got to know what to do, how to move. But you've got to first have the mindset like, yo, I am going to shoot my shot. +CHAD: I think as long as you...and you already said this, but you're making it real. Like, when you're following up, you're not just saying, "Hey, did you get my email?" You're finding ways to make it real and authentic. You got to show that you're real and not some bot. +JAMES: Yeah. So I will say in terms of the cold emails, I send them all the time. Cold emails is how I ended up collaborating with Nasdaq Entrepreneurial Center. We're big partners with them. We're part of this grant project with them with this major Wall Street Bank Foundation they're about to be announcing this year any day now. We got a grant tackling the problem of Black or Brown founders, underestimated founders not getting access to early-stage venture and angel funding. +So we're part of that with my foundation all because I sent a cold email to some guy at Nasdaq. I don't even remember who it was, Western president. Sent him an email, he copied the executive director from Nasdaq Entrepreneurial Center. The rest is history. My last round of grants, they co-sponsored the last round of grants. They put in some money. Great relationship with Nasdaq. They got 30 of my people from our community featured in the Nasdaq Tower in Times Square, let that sink in, all because of a cold email. +So if you're going to send a cold email, just a couple of tips off the top of my head. You need to have a compelling subject line. Keep the emojis to a minimum. [laughter] If you can use the person's name in the subject, I think that increases your open rate by like 20%. The email's got to be right to the point. Hey, my name is James Oliver, CEO of ParentPreneur Foundation. Put a link to the ParentPreneur Foundation in that instance. We got funded by Brad Feld, co-founder of Techstars, and put a link to Brad Feld's article. Establish credibility right away and get to the freaking point. Like, what do you want? Make an ask. What do you want? Get right to it. That's it. +CHAD: And then when you don't hear back, and you should follow up? +JAMES: Oh yeah. You absolutely got to follow up. I'll follow up a couple of times. I know Mario is like, "I just keep following up till they tell me to stop." [laughter] He's gangsta like that. I'll follow up three or four times. But after that, I know when people are pestering me. At that point, you're pestering. I'm not interested. If I was interested, I would have responded, so knock it off. +But I also respect the hustle when people are coming to me with something that's legit. And I will respond because I am them sometimes too. I'm like, "Hey, thanks for reaching out. I really appreciate it. I'm just not interested," or "I'm not interested now. Ping me back in six months." +CHAD: As someone who gets cold emails, I do the same thing when it's a legitimate...and you can tell. You can tell the ones where they're just blanket sending the same thing to a bunch of people. And you can tell when it's someone legitimately sending you a cold email. +JAMES: Because if you mention something about what they do specifically and how that's relevant to your email or your ask, that increases your chances of getting a response. Hell, I sent a cold email to Mark Cuban, bro. +CHAD: Awesome. +JAMES: He said yes. I interviewed him on my blog. I don't write on my blog anymore. But he got right back to me, and I interviewed him on my blog. He was great. +CHAD: So I don't know if everyone does this. Like you said, even if it's not a fit for me or I can't do it right now or whatever, if it's a legitimate thing, I will almost always actually respond to it eventually. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +JAMES: So, if I may, I just want to talk a little bit about the impact in the ParentPreneur Foundation. +CHAD: Yes. +JAMES: Because we have 1,800 people now. This current round of grants makes $95,000 in the last 19 months since we launched. We do micro-grants of $1,000 apiece. I think I just tweeted this morning that it just seems like people look down their nose at a $1,000 grant. And I'm like; clearly, these people are not or never have been a super hustling, early-stage entrepreneur and definitely not one of those with kids. So $95,000, again, keep in mind, I don't know anything about a foundation, a non-profit. I've never done it before. I've never started a community, but I don't care; it doesn't matter. [laughs] You know what I'm saying? +In this instance, there's a tremendous founder-market fit because I am them. And that shines through brilliantly in all the things that we do. And the thing that I'm most thankful for that we've done in the community is we've paid for 320 mental therapy sessions for our community members. And that's important because historically, mental health is stigmatized in the Black community. And there's this belief of epigenetics, which is basically you can pass trauma down through your DNA to your descendants. And if that's true, Black folks got a lot of trauma, and we need to get it worked out. And when we do it in our community, people jump right on it. +So I'm so proud of those guys that they take it very seriously. And that's really legacy, and that's impact because we're creating a legacy of mental wealth for the people in our community that influences how they show up for themselves, for their businesses, for their partners and spouse, for their children, all of which impacts how their children show up in the world. So it matters a lot. +CHAD: I think the therapy sessions are a great example of when you have an authentic, unique community, something is going to come out of that which is so specific to that community. The impact of that is huge but also, where did that idea come from? Was that you? You said, "Hey, this is a need we have to do this"? +JAMES: Yes. +CHAD: Did it come from the community itself? +JAMES: No. And see, this is why I'm talking about the founder-market fit. I don't know all the things that my people need, which is why a lot of times I ask them, "What do you want? What do you need?" But a lot of things I already know they need before they even need them because I've been where a lot of those guys are, and some of them ain't been there yet. I already know what you're going to be looking at in six months, bro. You need to pay attention a little bit. So right from the beginning, we use betterhelp.com. We created a BetterHelp account. And it's so easy. +We use Typeform. Typeform is another partner of ours. They've given us lots of free codes, and VideoAsk is a new Typeform company. We use that for our application process, which is just brilliant. I keep getting compliments about how amazingly seamless and elegant our application process is for the grants using VideoAsk. But we use Typeform and first come, first serve. It fills up, and then I just get the email addresses, and I just drop them right into Betterhelp's account. And they reach out to people in the community, and they get them set up. It's so easy. +CHAD: That's great. What happens in the community? Is part of the value of the community just support from each other? +JAMES: Well, that's a big part of it. So that's a great question. So one of the things in the Seth Godin marketing seminar is he talks about tension and why it's important in marketing and how it drives change and drives people to action. And the assignment around tension I couldn't think of like what the tension was for the ParentPreneur Foundation. +But when he came to meet with us, and we were talking about it, he said, "If I'm on an airplane and we're sky jumping, and they're like, 'Well let's jump out,' and it's a perfectly good airplane," the tension for him is what if the parachute doesn't open? And the answer is like, "Well, don't worry. We have a backup chute for you." Okay, banzai, let's go. [laughs] +But for the ParentPreneur Foundation, the tension is what if we fail on this rocky road? What if we fail in our journey to leave a legacy for our beautiful, Black children? He said, "It doesn't matter because we have each other's backs on this rocky road." So I'm like, yes, that's exactly right. We have each other's backs. And I'm telling you, man, I see it. A lot of stuff is taking place; I have no idea. But I hear about it from time to time, just organically. People are collaborating. It's just amazing, man. It's just great. +So yeah, I know it's lonely being an entrepreneur, a lot of different challenges, unique challenges of being a Black entrepreneur. And it's just great to have a safe space for that. We do a lot of different things. We paid for virtual assistants. We paid for when kids were being virtual schooled. We paid for some virtual tutors for some of the children. +Social capital is another thing that I talk about a lot. We pay for people to improve their LinkedIn profiles and understand how to move properly on LinkedIn and build and increase their social capital, which to me is as problematic as a dearth of financial capital because, without social capital, you can't even imagine what's possible. And it was Albert Einstein who said that imagination is more important than knowledge. And it's just so true. So we're doing all the things. +CHAD: So, do you have a sense of what the split is between moms and dads in the community? +JAMES: Yeah, just off the top of my head, I think it's around 75-25 moms and dads, and that's interesting. Women like to build community, men we don't. We're like the king of the jungle. We're all okay by ourselves. [laughs] We don't want to build community. But, man, women love to build community, and they hold down our community in a big way, and I'm just so thankful for them. +CHAD: So you started in 2020. One thing that I've seen, and I think it makes your timing good, is that a lot of people either had change forced on them because of the pandemic, and they lost their jobs. Or they felt like they needed to make a change. And a lot of people faced with that decided to do something on their own and make something happen. So there has been a surge in entrepreneurship from my... +And another thing there's been a surge in is people going to coding bootcamps feeling like yeah, I lost my job, or I no longer want to do this job that I can no longer do remotely. I want to make a change in my life and learn to code. Does that resonate with you as something you've seen in terms of people who have never been entrepreneurs before who had it forced on them or making a conscious choice to do it, joining the community? +JAMES: Yeah, absolutely. To a certain extent, at the beginning of COVID, when everybody was freaking out, because I understand that within every crisis exists an opportunity, I was looking for that opportunity. I was like, all right, where's the opportunity here? I was asking the questions. And then, I had a chance coffee meeting with some acquaintances and told them my intention of starting the foundation one of these days. And they were like, well, what are you waiting for? Why don't you do it now? And I thought that was like the answer to my question. And I was like, oh damn, like, yeah, what am I waiting for? Let's do it now. +So yeah, a lot of people are moving towards entrepreneurship. I think a quick Google search will bear that out. I don't know to what extent, but I know it's a lot. The application for new businesses are increasing over the last few years. So yeah, I get it. People kind of hate their corporate jobs. They hate going to the office. I get it. My goal in life is to never have to wear a suit and tie again. [laughs] +CHAD: Even when you go on Good Morning America. +JAMES: I might wear a suit, but I'm not wearing a tie. Knock it off. [laughs] +CHAD: Well, I'm sure everything you mentioned that you've been fundraising all this stuff costs money. Does the majority of your funding come from bigger donors? I know that you have a link to donate, and I encourage people to do that. But how much time do you have to spend fundraising? What is the donor mix? And how can people help? +JAMES: It's just weird. We get in our own heads. I used to say, man, I kind of suck at fundraising, but I don't. We raised almost $300,000 since I started this thing with no experience. That's not somebody who sucks at fundraising, right? +CHAD: Yeah. +JAMES: But in my mind, we should have a million dollars in the bank so I can hire an executive director, and we can ramp up the programs that we know, or I can scale this thing up and do some other things. I have some other things I want to do. I want to do a startup studio. I'm trying to partner with Techstars right now. With Techstars, I'm already talking to the right people. I want to do a pre-accelerator program with them for Black ParentPreneurs and putting like $20,000 in people's pockets. That's going to cost money. We need a sponsor for that. +But to answer your question, you can visit parentpreneurfoundation.org click donate. And $25 a month it all helps. It all adds up. We have things that we have to do to keep the platforms going and tools and resources that we use to keep it all going. The big chunks have come from people like Brad Feld and David Cohen. And Fred Wilson even donated $10,000 one-time but yeah, we need more. I'm just biding my time. And the work we're doing matters so much. It's making a big impact. We are literally helping people raise money and get their businesses off the ground. +And one woman who just went through the Techstars Founder Catalyst Program with JPMorgan Chase here in Atlanta she went because I introduced them on my show. And she got in, and she just raised $250,000. And then she just told me she got a commitment for another half a million dollars. And this other woman she got a $250,000 grant from Wells Fargo because of our relationship with Nasdaq. And another guy got a term sheet for half a million dollars because of the introductions we're making. +So we're literally out here building capacity for the members of our community in so many ways. I'm thankful. I'm honored. I'm humbled to be in this position to do this work. But this is purpose work for me. This is my purpose, and I'm thankful to have found it. It's like Mark Twain says, "The two most important days in your life are the day you are born and the day you figure out why." I encourage people to go figure out why. +CHAD: And if you are Black ParentPreneur hearing what we're talking about and saying, "Yeah, now I know about this. This is for me." You also go to parentpreneurfoundation.org and sign up there. +JAMES: Yes, sir. Click the join community button. Absolutely. +CHAD: Well, James, thanks for stopping by and sharing with me and all the listeners. I really appreciate it, and I wish you and everything that you're doing all the best. +JAMES: Yes. And, Chad, thanks for reaching out, man. Look at you; you're on your hustle. It wasn't you that reached out to me. There was somebody else. +CHAD: It was, yeah. Another member of my team. +JAMES: How'd you find me, man? +CHAD: I think she's very good at LinkedIn, and you're good at LinkedIn and so -- +JAMES: [laughter] Well, I got a big [inaudible 36:11] show them the receipts, man. Show them the impact because that's what you got to do. +CHAD: Are there other places where if folks want to get in touch with you or follow along with you? Where are the other places they can do that? +JAMES: Yeah, they can do that on IG. We're parentpreneurfoundation on IG. I'm not super active there, but we're there. You can follow me on Twitter. I talk a lot on Twitter. I don't think anybody's listening, but I talk a lot on Twitter. +CHAD: [laughs] +JAMES: That thing doesn't come on until you actually earn those blue checkmark thingies, I swear. Because I will say something I think is really profound, and it's crickets. And I see somebody with a blue checkmark say the exact same thing, and I'm like, okay, I see how it is, but whatevs. [laughs] So I'm on Twitter @jamesoliverjr, jamesoliver-J-R. Follow me on Twitter. That'd be awesome. Shoot me a tweet. Tell me you heard about us, heard about me on The Giant Robots Show here. I would love to connect, engage, and build and learn with your audience. So thanks. +CHAD: Awesome. And for all of you listeners, you can subscribe to the show and find notes for this episode along with an entire transcript of the episode at giantrobots.fm. If you have questions or comments for me, email me at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: James Oliver Jr.. + + + James Oliver Jr. is the Founder and CEO of The ParentPreneur Foundation, which empowers Black ParentPreneurs so they can leave a legacy for their beautiful Black children.

+ +

Chad talks with James about inspiring, encouraging, and supporting ParentPreneurs to lobby to try to close wealth inequality gaps, shoot their shot and send cold emails, and engage in a community that supports one another.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is James Oliver Jr., Founder, and CEO of the ParentPreneur Foundation, which empowers Black ParentPreneurs so they can leave a legacy for their beautiful Black children. James, thanks for joining me.

+ +

JAMES: I'm super excited to be here. Thanks so much for having me.

+ +

CHAD: So I just said, in a nutshell, the tagline for ParentPreneur Foundation. I know it's a community that brings people together, Black ParentPreneurs together. How did you get started and see the need for this, and how did you actually then make it happen?

+ +

JAMES: Oh boy, that's a great question with a semi-long answer, so just hang in with me, but I think it's a really compelling story. So back in 2013, (I'm from Brooklyn, New York) at the time, I was living in Northeast Wisconsin. It started in 2011. I was trying to build a startup called WeMontage, which was the world's only website to let you turn your digital images into removable photo wallpaper.

+ +

CHAD: If you haven't seen it, by the way, you should look at it. That description that you gave, even though it describes it perfectly, I didn't realize until I went to the website and looked at the pictures exactly what it is and how remarkable of a product it is.

+ +

JAMES: Well, I'm delighted that you say that. Thank you so much. And that's part of the reason why [laughter] it failed. I mean, it's still around. And I know we have a bunch of designers in the community. So look, the website still works. The underlying collage editing software is still brilliant, but the UI UX needs a lot of love. It's a bit of a zombie with about $10,000-$15,000 of technical debt floating around over there. [laughs] But the product still works. And we still print, ship them sometimes. And we have tons of repeat customers. It's just one of those things. You build a great product, and they will always come. But the product is still brilliant still today.

+ +

So back then, I was a non-technical founder. I was out of money. I cleaned out my savings and living in the middle of nowhere. There wasn't exactly a bastion of technology startups or diversity, even for that matter. And I was fortunate to get into Gener8tor's...I think we were the second cohort. Back then, it was super early. We went to Madison. And right now, Gener8tor is killing it.

+ +

But I was out of money. I was thankful to get into their Madison cohort, which was a two-hour drive away. My ex-wife now was pregnant with our twins. The kids were supposed to be born end of March. Gener8tor ended early April. So I was like, okay, this timing works out brilliantly. But a day or two before the program started, I had to deliver, and we had to deliver the twins prematurely. Otherwise, my son would have died.

+ +

CHAD: Wow.

+ +

JAMES: His blood just started to circulate backwards. It was crazy. So we had to take them out. They weighed two pounds apiece. Every time I tell this story, it gives me agita, man. The accelerator was a two-hour drive each way back and forth to the NICU, waking up at 2:00 a.m. every morning because I couldn't sleep. I cried every day. I had a really talented developer on my team, but he had his personal demons. So he was really unreliable. But he was a brilliant guy. He was so smart, really talented.

+ +

But anyway, I got through the accelerator. Right before I was going on stage for demo day, I got a call from this angel that we pitched. We were raising $250,000 at the time, which really, in retrospect, was not nearly enough money. But I got a call. He said, "Hey, we're going to fill your round." I don't know. What does that mean? I don't take anything for granted. [laughs] What do you mean? "We're going to give you $250,000."

+ +

And then I just dropped to my knees. I thanked God. And I cried because I had sacrificed so much to get to that point. Thankfully, my daughter came home after six weeks, and my son came home after ten weeks. The kids are doing fine. They drive me crazy, but they're beautiful.

+ +

CHAD: [laughs] How old are they now?

+ +

JAMES: They just turned 9 in January. So after I launched WeMontage, I hired just a really remarkable technical co-founder and just a great guy. We still have a wonderful relationship. We got in there, and when I started out, I was like, well, I'm going to start a blog. I started a blog, and I was like, one of these days, I'm going to use the content from this blog to write a book.

+ +

CHAD: Before you move on, so in those early days, you had just gotten into the accelerator. You had this thing you needed to deal with with your family and delivering the twins. And did you ever consider dropping out of the accelerator at that point?

+ +

JAMES: I wasn't going to go, but I knew with that decision, WeMontage never would have come to light because I just didn't have the resources to make it happen. But as a family, we decided that I need to go do that and crush that, and so I made that choice. We raised money. In retrospect, we raised just enough money to fail because, look, the software was cute. We were running around pitching angels. It was cute to show look at what we can do, look at what we could do. When we turned the thing on, it was so unsustainable. It was a black box.

+ +

And I was on the phone literally with customers holding their hand to get them to place an order, and that was clearly unsustainable. So we made the decision that we need to fix this thing. We need to pull it apart, make it modular, stabilize the code, build on it. And by the time we got done with that, we only had a couple of months' cash left.

+ +

And I remember...man, if anybody has never told you this to your face, I promise you it's a hard thing to hear. They were like, "We're not going to throw good money after bad." I'm like, well, damn. Like, thanks. We have our first Today Show appearance coming up here next month. So thank you for that. Thanks. [laughs] Man.

+ +

CHAD: So you actually did go on the Today Show.

+ +

JAMES: Yeah, we got featured three times on the Today Show. I mean, on my own without a publicist, I got Today Show three times, Good Morning America, Money Magazine, DIY, Martha Stewart, on and on.

+ +

CHAD: I'm curious, after making an appearance like that, do your sales go up?

+ +

JAMES: They do. They did with the Today Show. So it was funny, like that first appearance, they didn't even put the graphic on the bottom with the name of the business. When Mario mentioned it, he said, "wemontage.com." Man, our freaking website went crazy. It crashed the website. [laughs] But we were kind of already prepared for it to crash. We had a little splash screen up and information. We got it back up in; I don't know, it was less than an hour.

+ +

But I spent literally all day getting back to those people. We gave them a coupon code. And we did about $15,000 that month from that one segment, which was great. That was our best month to date. I mean, all total, I've probably done $75,000 to $80,000 in sales from the three times we appeared on The Today Show.

+ +

CHAD: That's great. We've had clients, or I've known people who have done appearances like that, and it seems a little bit hit or miss. Sometimes it won't even result in a blip, and other times it's huge. And I'm not sure what the trend is when it matters and when it doesn't.

+ +

JAMES: This is the point: we all love these vanity things. We want to get exposure, exposure. So I have a really great relationship with Seth Godin, and he's a big supporter of the work I'm doing at ParentPreneur Foundation. He gives us scholarships to his marketing seminar, and he comes to visit with us sometime. The last time he talked about...he said, "Stop trying to do things to get attention. Spend your time getting your customers to tell their friends about your business." And that's a whole fact.

+ +

We love the vanity, but at the end of the day, PR does not necessarily equal cash flow. I had some hits. I got on Good Morning America, and that was not nearly as good as the Today Show. But that was by virtue of the last-minute change that they made in terms of how they were producing the segment. When they introduced my product, they had the camera on somebody else's product. They had people calling me about somebody else's stuff which is like, are you serious? But what are you going to do? You can't control that.

+ +

So yeah, those things are good. I will say that having that stuff on the landing page is good for credibility. People feel more comfortable, especially if they can see it. So that stuff matters to a point, but I wouldn't be spending a lot of time. I certainly would not be wasting a penny on a PR professional if I was a founder. I just wouldn't do it. All that stuff I rattled off I did on my own.

+ +

CHAD: Awesome. So you started to build a blog. [laughs]

+ +

JAMES: Yes. So the intention of that was to use that content to write a book to inspire ParentPreneurs around the world because it's hard being a parent and entrepreneur, especially if you're like early-stage scraping to get some revenue. You can't even talk about product-market fit yet. Can we make some money? [laughs] Can we make a buck?

+ +

CHAD: So I've done a few things in my life. Writing books is one of them, and I can't say that it's easy. I don't know how you found it. I was doing it with a traditional publisher the first few times around, and it was pretty difficult. How did you find it?

+ +

JAMES: So I self-published that book. And because of the way I approached it, I already had a bunch of content on my blog. It's funny; I was actually out of town. I was in Midland, Texas, because I got flown out there. I was on CNBC's version of Shark Tank, West Texas Investors Club, horrible experience, by the way. I swear if I ever go on another one of those shows, I'm going to bring the drama.

+ +

CHAD: [laughs]

+ +

JAMES: Piece of advice, for any of you guys listening, if you go on Shark Tank or any of those shows, do not leave it up to the creative people to tell a story about you. This is just me; I'm a little crazy, crazy like a fox. But you give them the story. So this is me and you talking, just the two of us. [laughs] If I go on Shark Tank or something like that, I'm not taking those people's money. They're going to be like, "Oh, well, you're just here clearly for the exposure." I'm like, well, so are you. You're doing it too.

+ +

Why should I give you 20% equity in my company for $200,000 or whatever it is? How much time are you actually going to spend helping me build my company? And by the way, the people who came before you from an investment standpoint already took a ton of risk off the table. So why should you get that money? And how many companies are in your portfolio? 50? So, okay, so are you really going to be helping me or nah? Nah? Right. No, I'm good.

+ +

CHAD: That'll definitely air. The producers will love that drama.

+ +

JAMES: That will air, right? See what I'm saying? And the people watching will be like, "Hell yeah, you tell them. Let me Google that real quick." [laughter]

+ +

CHAD: That's funny.

+ +

JAMES: But that's just me. But I have no intention of going back on any of those shows again because, at the end of the day, it was a bad experience for me. I only got about $6,000 in sales, but that's because nobody was watching that show. It was canceled. But at the end of the day, if you have a customer acquisition problem which is what we had at WeMontage, those things don't solve your problems. They just don't. Not necessarily. They could; you could get lucky. But it's probably not going to solve your problem.

+ +

CHAD: So I'm curious. So you wrote the book, and you focused on the concept of ParentPreneurs, Black ParentPreneurs specifically.

+ +

JAMES: No, actually, so the book was just for everybody who's a ParentPreneur. So the book's called The More You Hustle, The Luckier You Get: You CAN Be a Successful ParentPreneur. So Mario Armstrong, who's my guy from the Today Show, wrote the foreword to my book. We're really good friends. And it's on Amazon.

+ +

Some people have regarded it as the realest book of entrepreneurship they've ever read. It's unlike anything you ever read. It's the story of my journey, some of those things I just told you, and the up and down the back and forth. It will make you laugh, make you cry, make you wonder. You put it down, come back to it. There are some hard questions that I ask myself, and people read the book. It's a superfast read too.

+ +

CHAD: Awesome. At what point did you decide to focus on empowering Black ParentPreneurs?

+ +

JAMES: So that's a great question. So after I wrote the book, I had this idea. I said one day I'm going to sell WeMontage. And maybe it will happen. I don't know; if God can intervene, something could happen. Who knows? [laughter] It's just not likely at this point, and that's okay. But I was like, I'm going to sell this business. I'm going to take a million dollars of my own money and start a foundation for parents who are entrepreneurs because it's really freaking hard. It's so hard. Unless you've been there, you have no idea how hard that is. It's really hard.

+ +

So then, in early 2020, the whole world falls apart with George Floyd, Ahmaud Arbery, Breonna Taylor. I had my own Karen experience here in my backyard. I live in a really nice neighborhood in the suburbs of Atlanta. And I had to call the police on her. After the second experience, I filed a trespass warrant. Then I started looking at all the Federal Reserve wealth inequality data.

+ +

And I was like, I'm starting this foundation for Black ParentPreneurs because we need the help the most. We have got to try to close this wealth inequality gap. It's a big problem. I'm doing that. So now to answer your question, prior to that decision, so when I was going to Gener8tor, I met David Cohen and Brad Feld. They just popped up on a Google Meet to meet us. And these guys are co-founders of Techstars, which is one of the preeminent global startup accelerators.

+ +

And I just stayed in touch with them through their blogs. I didn't want anything from them. I remember I got an email from Brad a couple years back. And he's a voracious reader. He's a prolific writer. He sent me an email out of the blue. He said, "I just read your book. I effing loved it." [chuckles] He said, "I got to feature it on my blog." I was like, wow, okay, dope. So he did that. And we sold some books, which was great.

+ +

But so I reached out to Brad and David. I was like, "Hey, guys, I'm thinking about starting this foundation for ParentPreneurs in general." And they were like, "Yeah, I'm game. We can go back and forth with you about it," and which is amazing at that level those guys would be willing to do that. I appreciated that. And they were both like, "Eh, foundations are hard. It's a constant fundraising grind, blah, blah, blah."

+ +

And, look, they're not wrong. [laughs] They're not wrong. But here's the thing, though. For me, telling me something is hard doesn't land with me because I've had to scrap and scrape for every single blade of grass on the field of life. And quite frankly, it's hard being Black sometimes. If I had $1 every time somebody told me that WeMontage would have been successful if I had a white face out there instead of me type thing, it is very frustrating.

+ +

So then I got an email from Brad Feld out the blue after George Floyd, which was just a subject that said, "Hey, you're game for a 30-minute Zoom?" There was nothing in the body of the email. And I'm just like, yeah, I could as well want to talk to Brad. He's top of the food chain. He's not just a VC and co-founder of Techstars with a portfolio valuation north of $200 billion. He's also a Limited Partner. LPs are the people who write the checks to the VCs who write the checks to people like me and you guys listening who are entrepreneurs.

+ +

So I'm like, hell yeah, I want to talk to you for 30 minutes, Brad Feld. Who doesn't? I just didn't know what it was about. So he said, "I just want to know what two things you're working on addressing racial injustice, inequality I can put my time on or attention on." I'm like, Oh, hell yeah. Chad, I'm like, he has no idea what I just decided.

+ +

So we get on to Zoom. And I say, "You know, Brad, you remember that foundation thing I was telling you about?" He was like, "Yeah." I said, "Well, now that's just what Black ParentPreneurs is." He goes, "I'm so glad you did that." And this is the part that knocks me out of my chair every time I say it. He goes, "What would a 12-month operating plan look like? I can throw it up in a Google Doc, and I'll co-create it with you." [laughs]

+ +

CHAD: That's great. I mean, it is unfortunate that George Floyd being murdered and these other things have instigated people to want to make change and to get involved in ways that they haven't been able to before. That's super unfortunate, but something's got to wake people up.

+ +

JAMES: Well, that will come up because he was like, "Look, I'm this rich, middle-aged white dude. I've been doing things to support Black entrepreneurs in the past," but he's like, "I got to do more. So I'm reaching out to my friends, and I consider you a friend." I was like, wow, like, I knew you liked me a little bit, but I didn't know you liked me like that.

+ +

CHAD: [laughs]

+ +

JAMES: But he is a friend. I have his phone number. I can call him. He's a friend. Him and David these guys are friends. So I got the 12-month operating plan right back to him. He said, "This is great. What would a six-month plan look like?" I got to write back. And he's like, "Assume three things, one of which is a $50 000 seed grant from my foundation to start the ParentPreneur Foundation." So Brad has given now, I don't know, north of $125,000. He got us into the Techstars Foundation, which has been phenomenal.

+ +

My relationship with David has blossomed. I went on the Techstars Give First Podcast with David, and David's a friend as well. I just love those guys and how they move, and they've been super helpful. And so our foundation, at the heart of what we do, you mentioned this at the top, is we have a community of now almost 1,800 Black ParentPreneurs hosted on Mighty Networks, which is phenomenal because it's not on Facebook. That's the thing I love the most about it.

+ +

[laughter]

+ +

CHAD: I actually have some questions about Mighty Networks on my list. So we don't need to take a tangent in there right now. We can come back to it. I want to ask you about Mighty Networks.

+ +

JAMES: Love it. Love it. Love Gina Bianchini. She's the CEO. I actually had her on my LinkedIn live show a couple of months ago.

+ +

CHAD: Well, let's do it now then, actually. So as someone who has built software before to put together a company, did you ever consider that for this? And why not? And why use Mighty Networks?

+ +

JAMES: To build a community platform?

+ +

CHAD: [laughs] It's a very loaded question, James.

+ +

JAMES: Yeah, why would I do that? Listen, by the time I got done with my prototype with that; these guys would be like two versions past where they are today, which would be infinitely better than my little stinky MVP, right?

+ +

CHAD: Yeah.

+ +

JAMES: And these people live, eat, and breathe community. Is Mighty Networks perfect? No, of course not. But they're constantly making improvements. I think I told you at the top I'm actually about to launch a new podcast. I just signed a national podcast distribution deal. So we're launching a podcast on the HubSpot Podcast Network. You guys have heard of HubSpot, right?

+ +

CHAD: I have, yes.

+ +

JAMES: So it's for ParentPreneurs in general, kind of like my book, to empower ParentPreneurs to be the best parent entrepreneur they can possibly be because being a ParentPreneur is hard. And we came upon this opportunity. I saw an article; maybe LinkedIn, I don't remember, talking about HubSpot launched a new podcast network last year. And I told you I got all these PR opportunities. And I got that because I'm not shy about shooting my shot.

+ +

A lot of people are too scared to shoot their shot, or they don't know what to do, how to do it. But cold emails I'm really good at sending cold emails. So I sent a cold email to the CMO of HubSpot. He was mentioned in the article. I went on LinkedIn. I scraped his email address using my favorite email scraping tool, GetEmail.io. It works on LinkedIn. You get their email address. I sent him an awesome email. Of course, he didn't follow up right away; well, not, of course, sometimes they do. He didn't follow up right away. I sent a follow-up email. And when I send follow-up emails, I like to give some kind of update.

+ +

So in my follow-up email, I wasn't just like, "Hey, did you get my email? Please respond." It wasn't that. It was like some other update. I can't remember what it was, but it was an update following up about my email. He got back, copied somebody on the team. They got back, copied somebody else. They were like, "Do you have a clip or an excerpt of an interview?" And it just so happened we did because we knew we needed to get ready. So we did an interview with Neil Sales-Griffin, who's the Techstar Chicago Managing Director, and so we sent them an excerpt.

+ +

They were like, "This is great. Do you have a whole episode?" So we edited that thing down right here that day. It was a Friday, sent it to them. They were like, "Thanks for sending. We'll get back to you by Monday with the decision because, by the way, we have this new program, this emerging podcast voices program. There'll be six to eight podcasts in this program. And we'll listen to this and consider it." So they got back to us Sunday night at 11:00 o'clock. "This is amazing. You guys are pros." I'm like, that's not me. That's really Mario. I have no idea what I'm doing at all.

+ +

CHAD: [laughs]

+ +

JAMES: But thanks, Mario. "And you guys are stars. You can't teach stars." But I'm like, hey, all right. I've never done a podcast. But hey, glad somebody other than my mama likes me. This is awesome. And they were like, "We want to invite you to be one of the companies in this new cohort with a new podcast," and just a swoop in at the last minute like that all because I shot my shot. So if anybody's out there listening, don't be afraid to shoot your shot, man. It's a mindset. You got to know what to do, how to move. But you've got to first have the mindset like, yo, I am going to shoot my shot.

+ +

CHAD: I think as long as you...and you already said this, but you're making it real. Like, when you're following up, you're not just saying, "Hey, did you get my email?" You're finding ways to make it real and authentic. You got to show that you're real and not some bot.

+ +

JAMES: Yeah. So I will say in terms of the cold emails, I send them all the time. Cold emails is how I ended up collaborating with Nasdaq Entrepreneurial Center. We're big partners with them. We're part of this grant project with them with this major Wall Street Bank Foundation they're about to be announcing this year any day now. We got a grant tackling the problem of Black or Brown founders, underestimated founders not getting access to early-stage venture and angel funding.

+ +

So we're part of that with my foundation all because I sent a cold email to some guy at Nasdaq. I don't even remember who it was, Western president. Sent him an email, he copied the executive director from Nasdaq Entrepreneurial Center. The rest is history. My last round of grants, they co-sponsored the last round of grants. They put in some money. Great relationship with Nasdaq. They got 30 of my people from our community featured in the Nasdaq Tower in Times Square, let that sink in, all because of a cold email.

+ +

So if you're going to send a cold email, just a couple of tips off the top of my head. You need to have a compelling subject line. Keep the emojis to a minimum. [laughter] If you can use the person's name in the subject, I think that increases your open rate by like 20%. The email's got to be right to the point. Hey, my name is James Oliver, CEO of ParentPreneur Foundation. Put a link to the ParentPreneur Foundation in that instance. We got funded by Brad Feld, co-founder of Techstars, and put a link to Brad Feld's article. Establish credibility right away and get to the freaking point. Like, what do you want? Make an ask. What do you want? Get right to it. That's it.

+ +

CHAD: And then when you don't hear back, and you should follow up?

+ +

JAMES: Oh yeah. You absolutely got to follow up. I'll follow up a couple of times. I know Mario is like, "I just keep following up till they tell me to stop." [laughter] He's gangsta like that. I'll follow up three or four times. But after that, I know when people are pestering me. At that point, you're pestering. I'm not interested. If I was interested, I would have responded, so knock it off.

+ +

But I also respect the hustle when people are coming to me with something that's legit. And I will respond because I am them sometimes too. I'm like, "Hey, thanks for reaching out. I really appreciate it. I'm just not interested," or "I'm not interested now. Ping me back in six months."

+ +

CHAD: As someone who gets cold emails, I do the same thing when it's a legitimate...and you can tell. You can tell the ones where they're just blanket sending the same thing to a bunch of people. And you can tell when it's someone legitimately sending you a cold email.

+ +

JAMES: Because if you mention something about what they do specifically and how that's relevant to your email or your ask, that increases your chances of getting a response. Hell, I sent a cold email to Mark Cuban, bro.

+ +

CHAD: Awesome.

+ +

JAMES: He said yes. I interviewed him on my blog. I don't write on my blog anymore. But he got right back to me, and I interviewed him on my blog. He was great.

+ +

CHAD: So I don't know if everyone does this. Like you said, even if it's not a fit for me or I can't do it right now or whatever, if it's a legitimate thing, I will almost always actually respond to it eventually.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

JAMES: So, if I may, I just want to talk a little bit about the impact in the ParentPreneur Foundation.

+ +

CHAD: Yes.

+ +

JAMES: Because we have 1,800 people now. This current round of grants makes $95,000 in the last 19 months since we launched. We do micro-grants of $1,000 apiece. I think I just tweeted this morning that it just seems like people look down their nose at a $1,000 grant. And I'm like; clearly, these people are not or never have been a super hustling, early-stage entrepreneur and definitely not one of those with kids. So $95,000, again, keep in mind, I don't know anything about a foundation, a non-profit. I've never done it before. I've never started a community, but I don't care; it doesn't matter. [laughs] You know what I'm saying?

+ +

In this instance, there's a tremendous founder-market fit because I am them. And that shines through brilliantly in all the things that we do. And the thing that I'm most thankful for that we've done in the community is we've paid for 320 mental therapy sessions for our community members. And that's important because historically, mental health is stigmatized in the Black community. And there's this belief of epigenetics, which is basically you can pass trauma down through your DNA to your descendants. And if that's true, Black folks got a lot of trauma, and we need to get it worked out. And when we do it in our community, people jump right on it.

+ +

So I'm so proud of those guys that they take it very seriously. And that's really legacy, and that's impact because we're creating a legacy of mental wealth for the people in our community that influences how they show up for themselves, for their businesses, for their partners and spouse, for their children, all of which impacts how their children show up in the world. So it matters a lot.

+ +

CHAD: I think the therapy sessions are a great example of when you have an authentic, unique community, something is going to come out of that which is so specific to that community. The impact of that is huge but also, where did that idea come from? Was that you? You said, "Hey, this is a need we have to do this"?

+ +

JAMES: Yes.

+ +

CHAD: Did it come from the community itself?

+ +

JAMES: No. And see, this is why I'm talking about the founder-market fit. I don't know all the things that my people need, which is why a lot of times I ask them, "What do you want? What do you need?" But a lot of things I already know they need before they even need them because I've been where a lot of those guys are, and some of them ain't been there yet. I already know what you're going to be looking at in six months, bro. You need to pay attention a little bit. So right from the beginning, we use betterhelp.com. We created a BetterHelp account. And it's so easy.

+ +

We use Typeform. Typeform is another partner of ours. They've given us lots of free codes, and VideoAsk is a new Typeform company. We use that for our application process, which is just brilliant. I keep getting compliments about how amazingly seamless and elegant our application process is for the grants using VideoAsk. But we use Typeform and first come, first serve. It fills up, and then I just get the email addresses, and I just drop them right into Betterhelp's account. And they reach out to people in the community, and they get them set up. It's so easy.

+ +

CHAD: That's great. What happens in the community? Is part of the value of the community just support from each other?

+ +

JAMES: Well, that's a big part of it. So that's a great question. So one of the things in the Seth Godin marketing seminar is he talks about tension and why it's important in marketing and how it drives change and drives people to action. And the assignment around tension I couldn't think of like what the tension was for the ParentPreneur Foundation.

+ +

But when he came to meet with us, and we were talking about it, he said, "If I'm on an airplane and we're sky jumping, and they're like, 'Well let's jump out,' and it's a perfectly good airplane," the tension for him is what if the parachute doesn't open? And the answer is like, "Well, don't worry. We have a backup chute for you." Okay, banzai, let's go. [laughs]

+ +

But for the ParentPreneur Foundation, the tension is what if we fail on this rocky road? What if we fail in our journey to leave a legacy for our beautiful, Black children? He said, "It doesn't matter because we have each other's backs on this rocky road." So I'm like, yes, that's exactly right. We have each other's backs. And I'm telling you, man, I see it. A lot of stuff is taking place; I have no idea. But I hear about it from time to time, just organically. People are collaborating. It's just amazing, man. It's just great.

+ +

So yeah, I know it's lonely being an entrepreneur, a lot of different challenges, unique challenges of being a Black entrepreneur. And it's just great to have a safe space for that. We do a lot of different things. We paid for virtual assistants. We paid for when kids were being virtual schooled. We paid for some virtual tutors for some of the children.

+ +

Social capital is another thing that I talk about a lot. We pay for people to improve their LinkedIn profiles and understand how to move properly on LinkedIn and build and increase their social capital, which to me is as problematic as a dearth of financial capital because, without social capital, you can't even imagine what's possible. And it was Albert Einstein who said that imagination is more important than knowledge. And it's just so true. So we're doing all the things.

+ +

CHAD: So, do you have a sense of what the split is between moms and dads in the community?

+ +

JAMES: Yeah, just off the top of my head, I think it's around 75-25 moms and dads, and that's interesting. Women like to build community, men we don't. We're like the king of the jungle. We're all okay by ourselves. [laughs] We don't want to build community. But, man, women love to build community, and they hold down our community in a big way, and I'm just so thankful for them.

+ +

CHAD: So you started in 2020. One thing that I've seen, and I think it makes your timing good, is that a lot of people either had change forced on them because of the pandemic, and they lost their jobs. Or they felt like they needed to make a change. And a lot of people faced with that decided to do something on their own and make something happen. So there has been a surge in entrepreneurship from my...

+ +

And another thing there's been a surge in is people going to coding bootcamps feeling like yeah, I lost my job, or I no longer want to do this job that I can no longer do remotely. I want to make a change in my life and learn to code. Does that resonate with you as something you've seen in terms of people who have never been entrepreneurs before who had it forced on them or making a conscious choice to do it, joining the community?

+ +

JAMES: Yeah, absolutely. To a certain extent, at the beginning of COVID, when everybody was freaking out, because I understand that within every crisis exists an opportunity, I was looking for that opportunity. I was like, all right, where's the opportunity here? I was asking the questions. And then, I had a chance coffee meeting with some acquaintances and told them my intention of starting the foundation one of these days. And they were like, well, what are you waiting for? Why don't you do it now? And I thought that was like the answer to my question. And I was like, oh damn, like, yeah, what am I waiting for? Let's do it now.

+ +

So yeah, a lot of people are moving towards entrepreneurship. I think a quick Google search will bear that out. I don't know to what extent, but I know it's a lot. The application for new businesses are increasing over the last few years. So yeah, I get it. People kind of hate their corporate jobs. They hate going to the office. I get it. My goal in life is to never have to wear a suit and tie again. [laughs]

+ +

CHAD: Even when you go on Good Morning America.

+ +

JAMES: I might wear a suit, but I'm not wearing a tie. Knock it off. [laughs]

+ +

CHAD: Well, I'm sure everything you mentioned that you've been fundraising all this stuff costs money. Does the majority of your funding come from bigger donors? I know that you have a link to donate, and I encourage people to do that. But how much time do you have to spend fundraising? What is the donor mix? And how can people help?

+ +

JAMES: It's just weird. We get in our own heads. I used to say, man, I kind of suck at fundraising, but I don't. We raised almost $300,000 since I started this thing with no experience. That's not somebody who sucks at fundraising, right?

+ +

CHAD: Yeah.

+ +

JAMES: But in my mind, we should have a million dollars in the bank so I can hire an executive director, and we can ramp up the programs that we know, or I can scale this thing up and do some other things. I have some other things I want to do. I want to do a startup studio. I'm trying to partner with Techstars right now. With Techstars, I'm already talking to the right people. I want to do a pre-accelerator program with them for Black ParentPreneurs and putting like $20,000 in people's pockets. That's going to cost money. We need a sponsor for that.

+ +

But to answer your question, you can visit parentpreneurfoundation.org click donate. And $25 a month it all helps. It all adds up. We have things that we have to do to keep the platforms going and tools and resources that we use to keep it all going. The big chunks have come from people like Brad Feld and David Cohen. And Fred Wilson even donated $10,000 one-time but yeah, we need more. I'm just biding my time. And the work we're doing matters so much. It's making a big impact. We are literally helping people raise money and get their businesses off the ground.

+ +

And one woman who just went through the Techstars Founder Catalyst Program with JPMorgan Chase here in Atlanta she went because I introduced them on my show. And she got in, and she just raised $250,000. And then she just told me she got a commitment for another half a million dollars. And this other woman she got a $250,000 grant from Wells Fargo because of our relationship with Nasdaq. And another guy got a term sheet for half a million dollars because of the introductions we're making.

+ +

So we're literally out here building capacity for the members of our community in so many ways. I'm thankful. I'm honored. I'm humbled to be in this position to do this work. But this is purpose work for me. This is my purpose, and I'm thankful to have found it. It's like Mark Twain says, "The two most important days in your life are the day you are born and the day you figure out why." I encourage people to go figure out why.

+ +

CHAD: And if you are Black ParentPreneur hearing what we're talking about and saying, "Yeah, now I know about this. This is for me." You also go to parentpreneurfoundation.org and sign up there.

+ +

JAMES: Yes, sir. Click the join community button. Absolutely.

+ +

CHAD: Well, James, thanks for stopping by and sharing with me and all the listeners. I really appreciate it, and I wish you and everything that you're doing all the best.

+ +

JAMES: Yes. And, Chad, thanks for reaching out, man. Look at you; you're on your hustle. It wasn't you that reached out to me. There was somebody else.

+ +

CHAD: It was, yeah. Another member of my team.

+ +

JAMES: How'd you find me, man?

+ +

CHAD: I think she's very good at LinkedIn, and you're good at LinkedIn and so --

+ +

JAMES: [laughter] Well, I got a big [inaudible 36:11] show them the receipts, man. Show them the impact because that's what you got to do.

+ +

CHAD: Are there other places where if folks want to get in touch with you or follow along with you? Where are the other places they can do that?

+ +

JAMES: Yeah, they can do that on IG. We're parentpreneurfoundation on IG. I'm not super active there, but we're there. You can follow me on Twitter. I talk a lot on Twitter. I don't think anybody's listening, but I talk a lot on Twitter.

+ +

CHAD: [laughs]

+ +

JAMES: That thing doesn't come on until you actually earn those blue checkmark thingies, I swear. Because I will say something I think is really profound, and it's crickets. And I see somebody with a blue checkmark say the exact same thing, and I'm like, okay, I see how it is, but whatevs. [laughs] So I'm on Twitter @jamesoliverjr, jamesoliver-J-R. Follow me on Twitter. That'd be awesome. Shoot me a tweet. Tell me you heard about us, heard about me on The Giant Robots Show here. I would love to connect, engage, and build and learn with your audience. So thanks.

+ +

CHAD: Awesome. And for all of you listeners, you can subscribe to the show and find notes for this episode along with an entire transcript of the episode at giantrobots.fm. If you have questions or comments for me, email me at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: James Oliver Jr..

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + James Oliver Jr. is the Founder and CEO of The ParentPreneur Foundation, which empowers Black ParentPreneurs so they can leave a legacy for their beautiful Black children.

+ +

Chad talks with James about inspiring, encouraging, and supporting ParentPreneurs to lobby to try to close wealth inequality gaps, shoot their shot and send cold emails, and engage in a community that supports one another.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is James Oliver Jr., Founder, and CEO of the ParentPreneur Foundation, which empowers Black ParentPreneurs so they can leave a legacy for their beautiful Black children. James, thanks for joining me.

+ +

JAMES: I'm super excited to be here. Thanks so much for having me.

+ +

CHAD: So I just said, in a nutshell, the tagline for ParentPreneur Foundation. I know it's a community that brings people together, Black ParentPreneurs together. How did you get started and see the need for this, and how did you actually then make it happen?

+ +

JAMES: Oh boy, that's a great question with a semi-long answer, so just hang in with me, but I think it's a really compelling story. So back in 2013, (I'm from Brooklyn, New York) at the time, I was living in Northeast Wisconsin. It started in 2011. I was trying to build a startup called WeMontage, which was the world's only website to let you turn your digital images into removable photo wallpaper.

+ +

CHAD: If you haven't seen it, by the way, you should look at it. That description that you gave, even though it describes it perfectly, I didn't realize until I went to the website and looked at the pictures exactly what it is and how remarkable of a product it is.

+ +

JAMES: Well, I'm delighted that you say that. Thank you so much. And that's part of the reason why [laughter] it failed. I mean, it's still around. And I know we have a bunch of designers in the community. So look, the website still works. The underlying collage editing software is still brilliant, but the UI UX needs a lot of love. It's a bit of a zombie with about $10,000-$15,000 of technical debt floating around over there. [laughs] But the product still works. And we still print, ship them sometimes. And we have tons of repeat customers. It's just one of those things. You build a great product, and they will always come. But the product is still brilliant still today.

+ +

So back then, I was a non-technical founder. I was out of money. I cleaned out my savings and living in the middle of nowhere. There wasn't exactly a bastion of technology startups or diversity, even for that matter. And I was fortunate to get into Gener8tor's...I think we were the second cohort. Back then, it was super early. We went to Madison. And right now, Gener8tor is killing it.

+ +

But I was out of money. I was thankful to get into their Madison cohort, which was a two-hour drive away. My ex-wife now was pregnant with our twins. The kids were supposed to be born end of March. Gener8tor ended early April. So I was like, okay, this timing works out brilliantly. But a day or two before the program started, I had to deliver, and we had to deliver the twins prematurely. Otherwise, my son would have died.

+ +

CHAD: Wow.

+ +

JAMES: His blood just started to circulate backwards. It was crazy. So we had to take them out. They weighed two pounds apiece. Every time I tell this story, it gives me agita, man. The accelerator was a two-hour drive each way back and forth to the NICU, waking up at 2:00 a.m. every morning because I couldn't sleep. I cried every day. I had a really talented developer on my team, but he had his personal demons. So he was really unreliable. But he was a brilliant guy. He was so smart, really talented.

+ +

But anyway, I got through the accelerator. Right before I was going on stage for demo day, I got a call from this angel that we pitched. We were raising $250,000 at the time, which really, in retrospect, was not nearly enough money. But I got a call. He said, "Hey, we're going to fill your round." I don't know. What does that mean? I don't take anything for granted. [laughs] What do you mean? "We're going to give you $250,000."

+ +

And then I just dropped to my knees. I thanked God. And I cried because I had sacrificed so much to get to that point. Thankfully, my daughter came home after six weeks, and my son came home after ten weeks. The kids are doing fine. They drive me crazy, but they're beautiful.

+ +

CHAD: [laughs] How old are they now?

+ +

JAMES: They just turned 9 in January. So after I launched WeMontage, I hired just a really remarkable technical co-founder and just a great guy. We still have a wonderful relationship. We got in there, and when I started out, I was like, well, I'm going to start a blog. I started a blog, and I was like, one of these days, I'm going to use the content from this blog to write a book.

+ +

CHAD: Before you move on, so in those early days, you had just gotten into the accelerator. You had this thing you needed to deal with with your family and delivering the twins. And did you ever consider dropping out of the accelerator at that point?

+ +

JAMES: I wasn't going to go, but I knew with that decision, WeMontage never would have come to light because I just didn't have the resources to make it happen. But as a family, we decided that I need to go do that and crush that, and so I made that choice. We raised money. In retrospect, we raised just enough money to fail because, look, the software was cute. We were running around pitching angels. It was cute to show look at what we can do, look at what we could do. When we turned the thing on, it was so unsustainable. It was a black box.

+ +

And I was on the phone literally with customers holding their hand to get them to place an order, and that was clearly unsustainable. So we made the decision that we need to fix this thing. We need to pull it apart, make it modular, stabilize the code, build on it. And by the time we got done with that, we only had a couple of months' cash left.

+ +

And I remember...man, if anybody has never told you this to your face, I promise you it's a hard thing to hear. They were like, "We're not going to throw good money after bad." I'm like, well, damn. Like, thanks. We have our first Today Show appearance coming up here next month. So thank you for that. Thanks. [laughs] Man.

+ +

CHAD: So you actually did go on the Today Show.

+ +

JAMES: Yeah, we got featured three times on the Today Show. I mean, on my own without a publicist, I got Today Show three times, Good Morning America, Money Magazine, DIY, Martha Stewart, on and on.

+ +

CHAD: I'm curious, after making an appearance like that, do your sales go up?

+ +

JAMES: They do. They did with the Today Show. So it was funny, like that first appearance, they didn't even put the graphic on the bottom with the name of the business. When Mario mentioned it, he said, "wemontage.com." Man, our freaking website went crazy. It crashed the website. [laughs] But we were kind of already prepared for it to crash. We had a little splash screen up and information. We got it back up in; I don't know, it was less than an hour.

+ +

But I spent literally all day getting back to those people. We gave them a coupon code. And we did about $15,000 that month from that one segment, which was great. That was our best month to date. I mean, all total, I've probably done $75,000 to $80,000 in sales from the three times we appeared on The Today Show.

+ +

CHAD: That's great. We've had clients, or I've known people who have done appearances like that, and it seems a little bit hit or miss. Sometimes it won't even result in a blip, and other times it's huge. And I'm not sure what the trend is when it matters and when it doesn't.

+ +

JAMES: This is the point: we all love these vanity things. We want to get exposure, exposure. So I have a really great relationship with Seth Godin, and he's a big supporter of the work I'm doing at ParentPreneur Foundation. He gives us scholarships to his marketing seminar, and he comes to visit with us sometime. The last time he talked about...he said, "Stop trying to do things to get attention. Spend your time getting your customers to tell their friends about your business." And that's a whole fact.

+ +

We love the vanity, but at the end of the day, PR does not necessarily equal cash flow. I had some hits. I got on Good Morning America, and that was not nearly as good as the Today Show. But that was by virtue of the last-minute change that they made in terms of how they were producing the segment. When they introduced my product, they had the camera on somebody else's product. They had people calling me about somebody else's stuff which is like, are you serious? But what are you going to do? You can't control that.

+ +

So yeah, those things are good. I will say that having that stuff on the landing page is good for credibility. People feel more comfortable, especially if they can see it. So that stuff matters to a point, but I wouldn't be spending a lot of time. I certainly would not be wasting a penny on a PR professional if I was a founder. I just wouldn't do it. All that stuff I rattled off I did on my own.

+ +

CHAD: Awesome. So you started to build a blog. [laughs]

+ +

JAMES: Yes. So the intention of that was to use that content to write a book to inspire ParentPreneurs around the world because it's hard being a parent and entrepreneur, especially if you're like early-stage scraping to get some revenue. You can't even talk about product-market fit yet. Can we make some money? [laughs] Can we make a buck?

+ +

CHAD: So I've done a few things in my life. Writing books is one of them, and I can't say that it's easy. I don't know how you found it. I was doing it with a traditional publisher the first few times around, and it was pretty difficult. How did you find it?

+ +

JAMES: So I self-published that book. And because of the way I approached it, I already had a bunch of content on my blog. It's funny; I was actually out of town. I was in Midland, Texas, because I got flown out there. I was on CNBC's version of Shark Tank, West Texas Investors Club, horrible experience, by the way. I swear if I ever go on another one of those shows, I'm going to bring the drama.

+ +

CHAD: [laughs]

+ +

JAMES: Piece of advice, for any of you guys listening, if you go on Shark Tank or any of those shows, do not leave it up to the creative people to tell a story about you. This is just me; I'm a little crazy, crazy like a fox. But you give them the story. So this is me and you talking, just the two of us. [laughs] If I go on Shark Tank or something like that, I'm not taking those people's money. They're going to be like, "Oh, well, you're just here clearly for the exposure." I'm like, well, so are you. You're doing it too.

+ +

Why should I give you 20% equity in my company for $200,000 or whatever it is? How much time are you actually going to spend helping me build my company? And by the way, the people who came before you from an investment standpoint already took a ton of risk off the table. So why should you get that money? And how many companies are in your portfolio? 50? So, okay, so are you really going to be helping me or nah? Nah? Right. No, I'm good.

+ +

CHAD: That'll definitely air. The producers will love that drama.

+ +

JAMES: That will air, right? See what I'm saying? And the people watching will be like, "Hell yeah, you tell them. Let me Google that real quick." [laughter]

+ +

CHAD: That's funny.

+ +

JAMES: But that's just me. But I have no intention of going back on any of those shows again because, at the end of the day, it was a bad experience for me. I only got about $6,000 in sales, but that's because nobody was watching that show. It was canceled. But at the end of the day, if you have a customer acquisition problem which is what we had at WeMontage, those things don't solve your problems. They just don't. Not necessarily. They could; you could get lucky. But it's probably not going to solve your problem.

+ +

CHAD: So I'm curious. So you wrote the book, and you focused on the concept of ParentPreneurs, Black ParentPreneurs specifically.

+ +

JAMES: No, actually, so the book was just for everybody who's a ParentPreneur. So the book's called The More You Hustle, The Luckier You Get: You CAN Be a Successful ParentPreneur. So Mario Armstrong, who's my guy from the Today Show, wrote the foreword to my book. We're really good friends. And it's on Amazon.

+ +

Some people have regarded it as the realest book of entrepreneurship they've ever read. It's unlike anything you ever read. It's the story of my journey, some of those things I just told you, and the up and down the back and forth. It will make you laugh, make you cry, make you wonder. You put it down, come back to it. There are some hard questions that I ask myself, and people read the book. It's a superfast read too.

+ +

CHAD: Awesome. At what point did you decide to focus on empowering Black ParentPreneurs?

+ +

JAMES: So that's a great question. So after I wrote the book, I had this idea. I said one day I'm going to sell WeMontage. And maybe it will happen. I don't know; if God can intervene, something could happen. Who knows? [laughter] It's just not likely at this point, and that's okay. But I was like, I'm going to sell this business. I'm going to take a million dollars of my own money and start a foundation for parents who are entrepreneurs because it's really freaking hard. It's so hard. Unless you've been there, you have no idea how hard that is. It's really hard.

+ +

So then, in early 2020, the whole world falls apart with George Floyd, Ahmaud Arbery, Breonna Taylor. I had my own Karen experience here in my backyard. I live in a really nice neighborhood in the suburbs of Atlanta. And I had to call the police on her. After the second experience, I filed a trespass warrant. Then I started looking at all the Federal Reserve wealth inequality data.

+ +

And I was like, I'm starting this foundation for Black ParentPreneurs because we need the help the most. We have got to try to close this wealth inequality gap. It's a big problem. I'm doing that. So now to answer your question, prior to that decision, so when I was going to Gener8tor, I met David Cohen and Brad Feld. They just popped up on a Google Meet to meet us. And these guys are co-founders of Techstars, which is one of the preeminent global startup accelerators.

+ +

And I just stayed in touch with them through their blogs. I didn't want anything from them. I remember I got an email from Brad a couple years back. And he's a voracious reader. He's a prolific writer. He sent me an email out of the blue. He said, "I just read your book. I effing loved it." [chuckles] He said, "I got to feature it on my blog." I was like, wow, okay, dope. So he did that. And we sold some books, which was great.

+ +

But so I reached out to Brad and David. I was like, "Hey, guys, I'm thinking about starting this foundation for ParentPreneurs in general." And they were like, "Yeah, I'm game. We can go back and forth with you about it," and which is amazing at that level those guys would be willing to do that. I appreciated that. And they were both like, "Eh, foundations are hard. It's a constant fundraising grind, blah, blah, blah."

+ +

And, look, they're not wrong. [laughs] They're not wrong. But here's the thing, though. For me, telling me something is hard doesn't land with me because I've had to scrap and scrape for every single blade of grass on the field of life. And quite frankly, it's hard being Black sometimes. If I had $1 every time somebody told me that WeMontage would have been successful if I had a white face out there instead of me type thing, it is very frustrating.

+ +

So then I got an email from Brad Feld out the blue after George Floyd, which was just a subject that said, "Hey, you're game for a 30-minute Zoom?" There was nothing in the body of the email. And I'm just like, yeah, I could as well want to talk to Brad. He's top of the food chain. He's not just a VC and co-founder of Techstars with a portfolio valuation north of $200 billion. He's also a Limited Partner. LPs are the people who write the checks to the VCs who write the checks to people like me and you guys listening who are entrepreneurs.

+ +

So I'm like, hell yeah, I want to talk to you for 30 minutes, Brad Feld. Who doesn't? I just didn't know what it was about. So he said, "I just want to know what two things you're working on addressing racial injustice, inequality I can put my time on or attention on." I'm like, Oh, hell yeah. Chad, I'm like, he has no idea what I just decided.

+ +

So we get on to Zoom. And I say, "You know, Brad, you remember that foundation thing I was telling you about?" He was like, "Yeah." I said, "Well, now that's just what Black ParentPreneurs is." He goes, "I'm so glad you did that." And this is the part that knocks me out of my chair every time I say it. He goes, "What would a 12-month operating plan look like? I can throw it up in a Google Doc, and I'll co-create it with you." [laughs]

+ +

CHAD: That's great. I mean, it is unfortunate that George Floyd being murdered and these other things have instigated people to want to make change and to get involved in ways that they haven't been able to before. That's super unfortunate, but something's got to wake people up.

+ +

JAMES: Well, that will come up because he was like, "Look, I'm this rich, middle-aged white dude. I've been doing things to support Black entrepreneurs in the past," but he's like, "I got to do more. So I'm reaching out to my friends, and I consider you a friend." I was like, wow, like, I knew you liked me a little bit, but I didn't know you liked me like that.

+ +

CHAD: [laughs]

+ +

JAMES: But he is a friend. I have his phone number. I can call him. He's a friend. Him and David these guys are friends. So I got the 12-month operating plan right back to him. He said, "This is great. What would a six-month plan look like?" I got to write back. And he's like, "Assume three things, one of which is a $50 000 seed grant from my foundation to start the ParentPreneur Foundation." So Brad has given now, I don't know, north of $125,000. He got us into the Techstars Foundation, which has been phenomenal.

+ +

My relationship with David has blossomed. I went on the Techstars Give First Podcast with David, and David's a friend as well. I just love those guys and how they move, and they've been super helpful. And so our foundation, at the heart of what we do, you mentioned this at the top, is we have a community of now almost 1,800 Black ParentPreneurs hosted on Mighty Networks, which is phenomenal because it's not on Facebook. That's the thing I love the most about it.

+ +

[laughter]

+ +

CHAD: I actually have some questions about Mighty Networks on my list. So we don't need to take a tangent in there right now. We can come back to it. I want to ask you about Mighty Networks.

+ +

JAMES: Love it. Love it. Love Gina Bianchini. She's the CEO. I actually had her on my LinkedIn live show a couple of months ago.

+ +

CHAD: Well, let's do it now then, actually. So as someone who has built software before to put together a company, did you ever consider that for this? And why not? And why use Mighty Networks?

+ +

JAMES: To build a community platform?

+ +

CHAD: [laughs] It's a very loaded question, James.

+ +

JAMES: Yeah, why would I do that? Listen, by the time I got done with my prototype with that; these guys would be like two versions past where they are today, which would be infinitely better than my little stinky MVP, right?

+ +

CHAD: Yeah.

+ +

JAMES: And these people live, eat, and breathe community. Is Mighty Networks perfect? No, of course not. But they're constantly making improvements. I think I told you at the top I'm actually about to launch a new podcast. I just signed a national podcast distribution deal. So we're launching a podcast on the HubSpot Podcast Network. You guys have heard of HubSpot, right?

+ +

CHAD: I have, yes.

+ +

JAMES: So it's for ParentPreneurs in general, kind of like my book, to empower ParentPreneurs to be the best parent entrepreneur they can possibly be because being a ParentPreneur is hard. And we came upon this opportunity. I saw an article; maybe LinkedIn, I don't remember, talking about HubSpot launched a new podcast network last year. And I told you I got all these PR opportunities. And I got that because I'm not shy about shooting my shot.

+ +

A lot of people are too scared to shoot their shot, or they don't know what to do, how to do it. But cold emails I'm really good at sending cold emails. So I sent a cold email to the CMO of HubSpot. He was mentioned in the article. I went on LinkedIn. I scraped his email address using my favorite email scraping tool, GetEmail.io. It works on LinkedIn. You get their email address. I sent him an awesome email. Of course, he didn't follow up right away; well, not, of course, sometimes they do. He didn't follow up right away. I sent a follow-up email. And when I send follow-up emails, I like to give some kind of update.

+ +

So in my follow-up email, I wasn't just like, "Hey, did you get my email? Please respond." It wasn't that. It was like some other update. I can't remember what it was, but it was an update following up about my email. He got back, copied somebody on the team. They got back, copied somebody else. They were like, "Do you have a clip or an excerpt of an interview?" And it just so happened we did because we knew we needed to get ready. So we did an interview with Neil Sales-Griffin, who's the Techstar Chicago Managing Director, and so we sent them an excerpt.

+ +

They were like, "This is great. Do you have a whole episode?" So we edited that thing down right here that day. It was a Friday, sent it to them. They were like, "Thanks for sending. We'll get back to you by Monday with the decision because, by the way, we have this new program, this emerging podcast voices program. There'll be six to eight podcasts in this program. And we'll listen to this and consider it." So they got back to us Sunday night at 11:00 o'clock. "This is amazing. You guys are pros." I'm like, that's not me. That's really Mario. I have no idea what I'm doing at all.

+ +

CHAD: [laughs]

+ +

JAMES: But thanks, Mario. "And you guys are stars. You can't teach stars." But I'm like, hey, all right. I've never done a podcast. But hey, glad somebody other than my mama likes me. This is awesome. And they were like, "We want to invite you to be one of the companies in this new cohort with a new podcast," and just a swoop in at the last minute like that all because I shot my shot. So if anybody's out there listening, don't be afraid to shoot your shot, man. It's a mindset. You got to know what to do, how to move. But you've got to first have the mindset like, yo, I am going to shoot my shot.

+ +

CHAD: I think as long as you...and you already said this, but you're making it real. Like, when you're following up, you're not just saying, "Hey, did you get my email?" You're finding ways to make it real and authentic. You got to show that you're real and not some bot.

+ +

JAMES: Yeah. So I will say in terms of the cold emails, I send them all the time. Cold emails is how I ended up collaborating with Nasdaq Entrepreneurial Center. We're big partners with them. We're part of this grant project with them with this major Wall Street Bank Foundation they're about to be announcing this year any day now. We got a grant tackling the problem of Black or Brown founders, underestimated founders not getting access to early-stage venture and angel funding.

+ +

So we're part of that with my foundation all because I sent a cold email to some guy at Nasdaq. I don't even remember who it was, Western president. Sent him an email, he copied the executive director from Nasdaq Entrepreneurial Center. The rest is history. My last round of grants, they co-sponsored the last round of grants. They put in some money. Great relationship with Nasdaq. They got 30 of my people from our community featured in the Nasdaq Tower in Times Square, let that sink in, all because of a cold email.

+ +

So if you're going to send a cold email, just a couple of tips off the top of my head. You need to have a compelling subject line. Keep the emojis to a minimum. [laughter] If you can use the person's name in the subject, I think that increases your open rate by like 20%. The email's got to be right to the point. Hey, my name is James Oliver, CEO of ParentPreneur Foundation. Put a link to the ParentPreneur Foundation in that instance. We got funded by Brad Feld, co-founder of Techstars, and put a link to Brad Feld's article. Establish credibility right away and get to the freaking point. Like, what do you want? Make an ask. What do you want? Get right to it. That's it.

+ +

CHAD: And then when you don't hear back, and you should follow up?

+ +

JAMES: Oh yeah. You absolutely got to follow up. I'll follow up a couple of times. I know Mario is like, "I just keep following up till they tell me to stop." [laughter] He's gangsta like that. I'll follow up three or four times. But after that, I know when people are pestering me. At that point, you're pestering. I'm not interested. If I was interested, I would have responded, so knock it off.

+ +

But I also respect the hustle when people are coming to me with something that's legit. And I will respond because I am them sometimes too. I'm like, "Hey, thanks for reaching out. I really appreciate it. I'm just not interested," or "I'm not interested now. Ping me back in six months."

+ +

CHAD: As someone who gets cold emails, I do the same thing when it's a legitimate...and you can tell. You can tell the ones where they're just blanket sending the same thing to a bunch of people. And you can tell when it's someone legitimately sending you a cold email.

+ +

JAMES: Because if you mention something about what they do specifically and how that's relevant to your email or your ask, that increases your chances of getting a response. Hell, I sent a cold email to Mark Cuban, bro.

+ +

CHAD: Awesome.

+ +

JAMES: He said yes. I interviewed him on my blog. I don't write on my blog anymore. But he got right back to me, and I interviewed him on my blog. He was great.

+ +

CHAD: So I don't know if everyone does this. Like you said, even if it's not a fit for me or I can't do it right now or whatever, if it's a legitimate thing, I will almost always actually respond to it eventually.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

JAMES: So, if I may, I just want to talk a little bit about the impact in the ParentPreneur Foundation.

+ +

CHAD: Yes.

+ +

JAMES: Because we have 1,800 people now. This current round of grants makes $95,000 in the last 19 months since we launched. We do micro-grants of $1,000 apiece. I think I just tweeted this morning that it just seems like people look down their nose at a $1,000 grant. And I'm like; clearly, these people are not or never have been a super hustling, early-stage entrepreneur and definitely not one of those with kids. So $95,000, again, keep in mind, I don't know anything about a foundation, a non-profit. I've never done it before. I've never started a community, but I don't care; it doesn't matter. [laughs] You know what I'm saying?

+ +

In this instance, there's a tremendous founder-market fit because I am them. And that shines through brilliantly in all the things that we do. And the thing that I'm most thankful for that we've done in the community is we've paid for 320 mental therapy sessions for our community members. And that's important because historically, mental health is stigmatized in the Black community. And there's this belief of epigenetics, which is basically you can pass trauma down through your DNA to your descendants. And if that's true, Black folks got a lot of trauma, and we need to get it worked out. And when we do it in our community, people jump right on it.

+ +

So I'm so proud of those guys that they take it very seriously. And that's really legacy, and that's impact because we're creating a legacy of mental wealth for the people in our community that influences how they show up for themselves, for their businesses, for their partners and spouse, for their children, all of which impacts how their children show up in the world. So it matters a lot.

+ +

CHAD: I think the therapy sessions are a great example of when you have an authentic, unique community, something is going to come out of that which is so specific to that community. The impact of that is huge but also, where did that idea come from? Was that you? You said, "Hey, this is a need we have to do this"?

+ +

JAMES: Yes.

+ +

CHAD: Did it come from the community itself?

+ +

JAMES: No. And see, this is why I'm talking about the founder-market fit. I don't know all the things that my people need, which is why a lot of times I ask them, "What do you want? What do you need?" But a lot of things I already know they need before they even need them because I've been where a lot of those guys are, and some of them ain't been there yet. I already know what you're going to be looking at in six months, bro. You need to pay attention a little bit. So right from the beginning, we use betterhelp.com. We created a BetterHelp account. And it's so easy.

+ +

We use Typeform. Typeform is another partner of ours. They've given us lots of free codes, and VideoAsk is a new Typeform company. We use that for our application process, which is just brilliant. I keep getting compliments about how amazingly seamless and elegant our application process is for the grants using VideoAsk. But we use Typeform and first come, first serve. It fills up, and then I just get the email addresses, and I just drop them right into Betterhelp's account. And they reach out to people in the community, and they get them set up. It's so easy.

+ +

CHAD: That's great. What happens in the community? Is part of the value of the community just support from each other?

+ +

JAMES: Well, that's a big part of it. So that's a great question. So one of the things in the Seth Godin marketing seminar is he talks about tension and why it's important in marketing and how it drives change and drives people to action. And the assignment around tension I couldn't think of like what the tension was for the ParentPreneur Foundation.

+ +

But when he came to meet with us, and we were talking about it, he said, "If I'm on an airplane and we're sky jumping, and they're like, 'Well let's jump out,' and it's a perfectly good airplane," the tension for him is what if the parachute doesn't open? And the answer is like, "Well, don't worry. We have a backup chute for you." Okay, banzai, let's go. [laughs]

+ +

But for the ParentPreneur Foundation, the tension is what if we fail on this rocky road? What if we fail in our journey to leave a legacy for our beautiful, Black children? He said, "It doesn't matter because we have each other's backs on this rocky road." So I'm like, yes, that's exactly right. We have each other's backs. And I'm telling you, man, I see it. A lot of stuff is taking place; I have no idea. But I hear about it from time to time, just organically. People are collaborating. It's just amazing, man. It's just great.

+ +

So yeah, I know it's lonely being an entrepreneur, a lot of different challenges, unique challenges of being a Black entrepreneur. And it's just great to have a safe space for that. We do a lot of different things. We paid for virtual assistants. We paid for when kids were being virtual schooled. We paid for some virtual tutors for some of the children.

+ +

Social capital is another thing that I talk about a lot. We pay for people to improve their LinkedIn profiles and understand how to move properly on LinkedIn and build and increase their social capital, which to me is as problematic as a dearth of financial capital because, without social capital, you can't even imagine what's possible. And it was Albert Einstein who said that imagination is more important than knowledge. And it's just so true. So we're doing all the things.

+ +

CHAD: So, do you have a sense of what the split is between moms and dads in the community?

+ +

JAMES: Yeah, just off the top of my head, I think it's around 75-25 moms and dads, and that's interesting. Women like to build community, men we don't. We're like the king of the jungle. We're all okay by ourselves. [laughs] We don't want to build community. But, man, women love to build community, and they hold down our community in a big way, and I'm just so thankful for them.

+ +

CHAD: So you started in 2020. One thing that I've seen, and I think it makes your timing good, is that a lot of people either had change forced on them because of the pandemic, and they lost their jobs. Or they felt like they needed to make a change. And a lot of people faced with that decided to do something on their own and make something happen. So there has been a surge in entrepreneurship from my...

+ +

And another thing there's been a surge in is people going to coding bootcamps feeling like yeah, I lost my job, or I no longer want to do this job that I can no longer do remotely. I want to make a change in my life and learn to code. Does that resonate with you as something you've seen in terms of people who have never been entrepreneurs before who had it forced on them or making a conscious choice to do it, joining the community?

+ +

JAMES: Yeah, absolutely. To a certain extent, at the beginning of COVID, when everybody was freaking out, because I understand that within every crisis exists an opportunity, I was looking for that opportunity. I was like, all right, where's the opportunity here? I was asking the questions. And then, I had a chance coffee meeting with some acquaintances and told them my intention of starting the foundation one of these days. And they were like, well, what are you waiting for? Why don't you do it now? And I thought that was like the answer to my question. And I was like, oh damn, like, yeah, what am I waiting for? Let's do it now.

+ +

So yeah, a lot of people are moving towards entrepreneurship. I think a quick Google search will bear that out. I don't know to what extent, but I know it's a lot. The application for new businesses are increasing over the last few years. So yeah, I get it. People kind of hate their corporate jobs. They hate going to the office. I get it. My goal in life is to never have to wear a suit and tie again. [laughs]

+ +

CHAD: Even when you go on Good Morning America.

+ +

JAMES: I might wear a suit, but I'm not wearing a tie. Knock it off. [laughs]

+ +

CHAD: Well, I'm sure everything you mentioned that you've been fundraising all this stuff costs money. Does the majority of your funding come from bigger donors? I know that you have a link to donate, and I encourage people to do that. But how much time do you have to spend fundraising? What is the donor mix? And how can people help?

+ +

JAMES: It's just weird. We get in our own heads. I used to say, man, I kind of suck at fundraising, but I don't. We raised almost $300,000 since I started this thing with no experience. That's not somebody who sucks at fundraising, right?

+ +

CHAD: Yeah.

+ +

JAMES: But in my mind, we should have a million dollars in the bank so I can hire an executive director, and we can ramp up the programs that we know, or I can scale this thing up and do some other things. I have some other things I want to do. I want to do a startup studio. I'm trying to partner with Techstars right now. With Techstars, I'm already talking to the right people. I want to do a pre-accelerator program with them for Black ParentPreneurs and putting like $20,000 in people's pockets. That's going to cost money. We need a sponsor for that.

+ +

But to answer your question, you can visit parentpreneurfoundation.org click donate. And $25 a month it all helps. It all adds up. We have things that we have to do to keep the platforms going and tools and resources that we use to keep it all going. The big chunks have come from people like Brad Feld and David Cohen. And Fred Wilson even donated $10,000 one-time but yeah, we need more. I'm just biding my time. And the work we're doing matters so much. It's making a big impact. We are literally helping people raise money and get their businesses off the ground.

+ +

And one woman who just went through the Techstars Founder Catalyst Program with JPMorgan Chase here in Atlanta she went because I introduced them on my show. And she got in, and she just raised $250,000. And then she just told me she got a commitment for another half a million dollars. And this other woman she got a $250,000 grant from Wells Fargo because of our relationship with Nasdaq. And another guy got a term sheet for half a million dollars because of the introductions we're making.

+ +

So we're literally out here building capacity for the members of our community in so many ways. I'm thankful. I'm honored. I'm humbled to be in this position to do this work. But this is purpose work for me. This is my purpose, and I'm thankful to have found it. It's like Mark Twain says, "The two most important days in your life are the day you are born and the day you figure out why." I encourage people to go figure out why.

+ +

CHAD: And if you are Black ParentPreneur hearing what we're talking about and saying, "Yeah, now I know about this. This is for me." You also go to parentpreneurfoundation.org and sign up there.

+ +

JAMES: Yes, sir. Click the join community button. Absolutely.

+ +

CHAD: Well, James, thanks for stopping by and sharing with me and all the listeners. I really appreciate it, and I wish you and everything that you're doing all the best.

+ +

JAMES: Yes. And, Chad, thanks for reaching out, man. Look at you; you're on your hustle. It wasn't you that reached out to me. There was somebody else.

+ +

CHAD: It was, yeah. Another member of my team.

+ +

JAMES: How'd you find me, man?

+ +

CHAD: I think she's very good at LinkedIn, and you're good at LinkedIn and so --

+ +

JAMES: [laughter] Well, I got a big [inaudible 36:11] show them the receipts, man. Show them the impact because that's what you got to do.

+ +

CHAD: Are there other places where if folks want to get in touch with you or follow along with you? Where are the other places they can do that?

+ +

JAMES: Yeah, they can do that on IG. We're parentpreneurfoundation on IG. I'm not super active there, but we're there. You can follow me on Twitter. I talk a lot on Twitter. I don't think anybody's listening, but I talk a lot on Twitter.

+ +

CHAD: [laughs]

+ +

JAMES: That thing doesn't come on until you actually earn those blue checkmark thingies, I swear. Because I will say something I think is really profound, and it's crickets. And I see somebody with a blue checkmark say the exact same thing, and I'm like, okay, I see how it is, but whatevs. [laughs] So I'm on Twitter @jamesoliverjr, jamesoliver-J-R. Follow me on Twitter. That'd be awesome. Shoot me a tweet. Tell me you heard about us, heard about me on The Giant Robots Show here. I would love to connect, engage, and build and learn with your audience. So thanks.

+ +

CHAD: Awesome. And for all of you listeners, you can subscribe to the show and find notes for this episode along with an entire transcript of the episode at giantrobots.fm. If you have questions or comments for me, email me at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: James Oliver Jr..

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+CclGUUT- + + ]]> + + Chad Pytel + James Oliver Jr. + + + 415: Promenade with JT Liddell + https://podcast.thoughtbot.com/415 + 35daed26-00c9-4e81-8389-688f370b08b0 + Thu, 24 Mar 2022 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + JT Lidell is the Founder of Promenade, which seamlessly matches and connects military veterans to the resources, people, and organizations that matter to them. + +Chad talks with JT about being a mission-driven, bootstrapped organization, the problems that he's encountered and hopes that Promenade solves, and aggregating people, tools, resources, and funding to make it happen. + 38:34 + no + + + JT Lidell is the Founder of Promenade, which seamlessly matches and connects military veterans to the resources, people, and organizations that matter to them. +Chad talks with JT about being a mission-driven, bootstrapped organization, the problems that he's encountered and hopes that Promenade solves, and aggregating people, tools, resources, and funding to make it happen. +Promenade (https://www.promenade.ai/) +Follow JT on Twitter (https://twitter.com/promenadeactual) or LinkedIn (https://www.linkedin.com/in/sam-zimmerman-35152a22/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is JT Liddell, the Founder of Promenade, which seamlessly matches and connects military veterans to the resources, people, and organizations that matter to them. JT, thank you so much for joining me. +JT: No, thank you for having me. Excited to talk to you about what we're building over here and having this conversation. So thank you so much for having me on today. +CHAD: I love mission-driven organizations, and Promenade falls right into that. How did it come about for you? +JT: Yeah, this has been...the inception of it really truly began many, many years ago when I first joined the military straight out of high school. So I went to The Naval Academy, actually, started there then went to the army. Fast forward 7, 8, 9, 10 years, and as I was getting out of the military and trying to join the civilian workforce, the civilian world, that's where a lot of the problems and challenges that I'm trying to solve through Promenade started. +And then, working in the technology space in corporate America really allowed me to identify some of the solutions and tools that I'm working with now. But to answer your original question, the beginning of Promenade or the inception of Promenade really began with my entry into the military. +CHAD: What were some of the problems that you encountered and that you hope that Promenade solves? +JT: Back in 2000...I left the military officially in 2010 but went straight into defense contracting work from there and worked there for a few years. And it was, as I was leaving, I went literally from Afghanistan, and 30 days later, I was sitting in an MBA classroom. And leaving Afghanistan, I thought there was literally no problem, no challenge...after going through three deployments to Afghanistan and being deployed to other parts of the world, I was like, there's nothing that I'm going to come against that I won't be able to tackle. That was the furthest from the truth. +So there are a number of issues when it came to relationships, when it came to navigating the workforce, when it came to just understanding how drastically different the civilian world was from being in the military and the defense industry. So those problems are umbrellas, and there are many, many things underneath those that I came up against. +CHAD: What are some of the ways that, you know, I speak as someone not having served in the military. What are some of the big ways in which civilian employment is different? +JT: It wasn't even necessarily...well, obviously, there are huge differences obviously from the military and civilian employment. But it was really even like, how do you get entry into the civilian workforce just from the very beginning? So, how do you craft a resume? It seems like a minor thing at this point in my life, but it's a huge one. When you leave the military, you have these 9, 10, 11-page resumes. And that's what you're supposed to do. You're supposed to put literally every single piece of experience that you have on this resume. +But when you come to the civilian world, you have to somehow condense all of that down to one page, and there's a science to doing that, and that was one of the first huge hurdles. Because a resume is just your ticket into the door, it's a ticket to that interview. That's just literally the first step. And that was something that I didn't realize was something I was going to have to hone my skill at. +CHAD: Do you think that a lot of companies overlook the value of military service? +JT: Yeah, that's a tough one to answer. So it's hard to say overlook when as a military veteran just taking myself, for instance, you know, in a lot of ways, I was not communicating effectively what my experience was in relation to the value I could provide to that organization. So as a recruiter or a headhunter, whoever is doing that initial review, they're simply looking...for a large part, they don't have experience in the military. So they don't understand the jargon and what some of these different jobs really mean with the impact they had on their organization. So there's still a lot of meat in the middle here. +So that individual needs to do a better job of communicating the exact value through a corporate sense how that value could contribute to corporate America or whatever type of organization they're trying to join. And organizations need to do a much better job of understanding that there's this untapped value in the military community and teaching and training their organizations or whoever is doing the intake process to look for the value that the military community can bring. So I don't think it's a one-sided thing. I think both sides need to come together and do a better job. +CHAD: So I said in the intro that Promenade matches and connects veterans to the resources, people, and organizations that matter to them. What exactly does that look like in terms of the product today and what you're doing? +JT: Yeah, absolutely. So this really began as a grassroots operation through my own ecosystem. Many, many years ago, when I was first getting in the military, and I was starting to get traction and understanding how to navigate the civilian world, I started to reach back. People would reach out to me, and I would reach back. And they would ask me, "How did you get here? How did you do that?" And I would just help people, review their resumes for them, get them connected to different jobs and career pathways. And then I started to do that a little bit more officially, if you will. +And then, I realized this is not just a problem within my own ecosystem; this is a problem across the military community. So as I was working in technology, as I mentioned before, I started to identify tools, one of them being artificial intelligence, that could help me scale the work that I was doing. So the pathway that I started to set out on was how do I take this grassroots work that I'm doing, and then how do I scale that work to millions of people rather than just dozens of people? So that's the journey that I'm on right now. I don't know if that answered your question or not. +CHAD: So if someone is listening and they're a veteran, what is the product going to offer them now? +JT: So they'll come on, and they'll onboard to the platform. So essentially, we're just taking the process that we've been doing offline, and we're bringing it online. So they'll come on. They'll fill out some demographic information. They'll answer a few questions about where they are in their current post-military journey. They could even be thinking about getting out. The product will still help them as they're on their way out, thinking about getting out. They could have been out for a month, a year, an entire decade doesn't really matter. We'll help assess where they are in their post-military journey. +After they go through that intake process, we'll give them the option to talk to one of our coaches, which can make this experience a little bit more personalized. And that's one of the huge things that I learned as I've been building Promenade is when I first started tackling this, thinking about tackling this issue through technology, I was like, okay, this technology these tools that I've identified and I've researched these are going to be the things that solve this problem. That's what's going to do this. No, that's what's going to fix this. +[chuckles] And what I quickly realized is you can't remove that human component from this process. There are just things that technology doesn't understand about the military experience. So having a coach, having an individual or human to talk to at the very beginning of this process, or whatever that individual needs is extremely crucial and hugely beneficial to this process. So we put that coach in front of them. That's completely optional because we do want to allow this to be self-service and self-guided. +So if they choose to get in front of that coach, they'll be able to talk one on one and augment this process. If they don't, they'll go straight to our dashboard. And what the dashboard will do is it's going to help that individual identify different areas within their post-military journey where they can improve and get better. +And, Chad, we haven't talked about this, but we've got this social impact-driven product that we're building. But the lens that we're really thinking about this is through a healthcare lens. So what that means is there's this term called social determinants of health. And what that means is...the very simple version is a super simple concept. Every part of your life impacts your overall health. The health care system, like when you go to the hospital, only impacts 20%-30% of your overall health. +The things that truly impact your health are things like, do you have a job? Have you talked to a therapist in the last six months? Do you have food, you know, the right type of food? Do you have access to the right type of food? Not just food. Are you ordering Burger King every day, McDonald's every day? But are you eating healthy food? And do you have consistent access? Those are the things that affect your overall health. +So we look at all of these different factors about the veteran and how they're going through their post-military journey. And we give them a score on all these different verticals. So essentially, through that score, we're helping them identify what those gaps are, and then we're pushing them resources to help fill those gaps. +So they'll get a couple of things through our platform. They'll get that dashboard and that score and personally recommended or personalized recommended resources to them, and that's where the artificial intelligence component comes into it. And then they'll have sort of a search field where they can just go and keyword for things just like they would go into Google and search for something. +And then the third component to this is the community that we're building, and that won't be rolled out initially. But once we've got critical mass, we've got a community that we're building where they'll get connected to people within our community, maybe people with the same skills and interest, people that they were deployed with, people that they were stationed with, or people that they just came across. And we've got a method to do that. But that's really what it's about is bringing this community together, helping them assess where they are in their post-military journey, and then putting the right resources in front of them at the right time based on who they are. So that's the experience they'll get, to answer your question. +CHAD: Awesome. Who pays for Promenade? +JT: So it's going to be twofold. So there'll be a freemium model for the military veteran, so all those things that I just mentioned, minus one or two. They'll get free access to the platform. So they'll be able to log on. They'll be able to see where they're at in their journey. And they'll be able to navigate the platform and get those personalized recommendations. +On the organizational side, they will also pay to access the platform. And then there's some other work...back when I mentioned a couple of minutes ago that organizations need to do a better job of understanding the military community, we help organizations better understand the military community, attract and retain military veteran talent if that's something that they're in the business of doing. So there are multiple ways to do it. +CHAD: And organizations would pay for that. +JT: That's right. Absolutely. Yeah. +CHAD: Is that a significant or a fundamental part of the business model? +JT: Which part? +CHAD: The organizations paying. +JT: Yeah, it is. So it depends on which part of interacting with the organization that we're talking about. So there are two ways we can do that. There's A, giving them access to the platform so just, for example, on the jobs portion, careers portion, recruiters. We'd give them access to the platform to get access to the talent. But on the let's help this organization think about how they're even reaching out to the veteran community, how they're recruiting them, the process that veterans are going through in order to apply to these organizations, once veterans are in these organizations, how are they supporting the veteran community? +And maybe even after they've left, depending on which organization you're talking about, how are you supporting that veteran community once they've left so they can be...you want them to be ambassadors for your organization. How are you supporting the veteran community even after they've left? So that's two completely different ways that we can interact with the organization. The fundamental one would be those organizations getting access to our platform and interacting with the veteran community. That for sure would be fundamental to what we're building. +CHAD: So who's funding Promenade right now? +JT: [laughs] Yeah, that's a great question. So this is definitely up until maybe a year or so ago; it's definitely been bootstrap built for sure completely out of my pocket. But thanks to some of the visibility we were able to get, in the work we were able to do, organizations were able to get in touch. We've gotten a couple of grants, one huge one from Google for Startups last year. That was $100,000 from Google for Startups. That's been obviously huge for the work and the momentum. +And what I always tell people is, you know, Chad, you've been doing this a while. [laughs] You know that $100,000 can get run through pretty quickly in the tech startup space. That was huge, and I don't want to downplay that by any means. But that wasn't even the biggest impact to what we're doing. It's just the visibility that it created for our organization. +We've had just the veterans that we work with; we've had so many reach out just because they heard about us but organizations as well that have reached out to us. They want to work with us. They want to support us. That was huge. But to answer your question, it's a combination of grant money, cash awards from different organizations, and bootstrapping it from me JT here. +CHAD: Well, thanks for doing that [laughs] and bringing this really important service to life. What are some of the barriers to achieving the success that you want to achieve with Promenade? +JT: What we're doing is essentially we're aggregating information. We're aggregating people. We're aggregating tools and resources. We're bringing all this together. I didn't think it would be easy by any means. But it's definitely much harder than I imagined it would be when I set out in this journey a couple of years ago. One of the hardest things about this is you've got all of these different areas that you're trying to assess veterans and getting these tools and resources and organizations in front of them. How do you consistently and with quality put those organizations and tools and resources in front of the veteran? +I want all of them to have the same experience. I want them to have an amazing experience. I want them to get connected quickly and with quality to the people and organizations and tools that they need to get connected to. So how do you make that experience consistent and standard across the board? And how do you control as much as possible the quality of that interaction? +Building these partnerships has been challenging. It's been difficult. But every time, I get frustrated...just like, every startup goes through those barriers. You get frustrated. I just think back to those moments where I was down on my post-military journey. And I'm like, I never want another veteran to have to go through that. That's what keeps me pushing when those barriers do hit. +And I'm like, this is going to be hard. How do I keep that organization, or how do I ensure that organization is doing A, B, and C? How do I ensure I'm keeping this veteran pushing forward and motivated when they get frustrated? Those are some of the barriers. But as I said before, I just look back on when I was going through my journey. And I don't want any veteran to have to go through that experience. So that's what keeps me going. +Mid-Roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So you officially started Promenade in May of 2020. Is that right? +JT: I came up with the idea actually in 2017 sort of the framework for what I'm doing now. And I'm in Atlanta, Georgia, and I don't know how much you know about the tech startup space in Atlanta, Georgia, but it's booming right now for sure. That'd be an understatement. And I have a few different people around me, a number of people around me in my ecosystem that are in the tech startup space. And I watched them going through their own personal journeys and finding success. +And I was like, number one, I have all these people around me that are doing it, non-technical founders, technical founders, first-time founders. There's no reason I can't also do this. And then number two, I was like, if I looked on my phone seven years from now and I saw a Promenade built by somebody else, I'd be super pissed. [laughter] I'm going to be so pissed. +I remember this quite clearly December 2019; I was like, you have to do something; if you don't, you're going to regret it. So December 2019, I went, and I signed up for this organization here in Atlanta called ATDC. I signed up for my first intro to customer discovery class. And from there, I've been pushing ever since. I think I incorporated the organization around May or March or something like that officially. But the idea, inception in its current form probably 2017 and then really began building in January 2020. +CHAD: So, how do you think the pandemic has impacted the ability to start Promenade? +JT: Yeah, a number of different ways. But I would say net-net actually in a positive way in not like the actual of what the pandemic means but the environment. It showed me clear as day that there's a huge net need for digital services when it comes to the military veteran community. Because a large resource for the veteran community is Department of Veteran Affairs, you know, doing amazing work doing great work. But just like many other government organizations, many aspects of it were shut down during the pandemic. +So let's just talk about mental wellness because that's something that is highly visible in the veteran community as being an issue. The suicide rate increased exponentially during the pandemic within the veteran community. That's because people are isolated. They're already going through issues; maybe people are getting out of the military during the pandemic. +It just showed me that there's a huge increased need for digitally online for this veteran community, resources for the veteran community, and just giving them an ecosystem to interact in. And it just pushed me even harder to build what I was building. So the pandemic was obviously a very terrible thing, but in terms of Promenade and the work that I was doing, it just made me go even harder for sure. +CHAD: So right now, is it just you? +JT: Yeah, so it's me. I've got one personal assistant, and I've got several designers and developers that I work with. +CHAD: On a contract basis? +JT: Yes, all contractors. But in terms of people who are hands-on building this thing, I probably couldn't even count the number, as I'm sure you know when it comes to developers and designers trying to build these solutions. But in terms of being officially a part of Promenade, it's still just me going at this thing right now. +CHAD: And while you're doing this, you have another full-time job, right? +JT: I do. I do. +CHAD: I think that's a scenario that a lot of people find themselves in is wanting to do something new but not necessarily being able to, you know, you're bootstrapping something on the side. How do you make it work? And what would need to happen for you to take the leap to be able to just work on Promenade? +JT: How do I make it work? A lot of Red Bull, a lot of energy drinks, [chuckles] and a lot of late nights. But again, as I mentioned before, that's something I would put in as time as a barrier when it comes to building this thing. I just take it back to the many conversations I have with veterans as they've been going through their own personal journeys. That just keeps me going. +As far as what would it take for me to move away to work on Promenade full time, the only true thing I think it would take would really be line of sight and visibility on being able to drive this thing forward in a sustainable manner, just having a line of sight on that, on this thing. Okay, I've got the traction. I can see it. It's tangible. I just need to do A, B, and C to keep pushing this thing forward. I know that's sort of vague, but that's really what it would take. +CHAD: Do you think you're going to have to take funding from somewhere, or do you think you can continue to bootstrap and operate on the grants and awards? +JT: It depends. That's a good question. That's something I've gone back and forth with. Working in the tech startup space, that's something that's discussed a lot is angel investors and VCs, and you need to do this to attract funders and things like that. That's something that's discussed a lot in this space. But it's something that I've gone back and forth with. It really comes down to what I want this thing to be at the end of the day. This thing could be huge. There's a huge gap in the military veteran space in a multitude of ways. +This thing could be a unicorn if that's the direction I really wanted to take it. And I think if I go down that pathway, it's for sure going to take funding from outside sources. But if I want to keep this thing more small scale or maybe even local to that Atlanta, Georgia region where I live and only focus on that one region, that's something I could probably bootstrap until I've got the revenue necessary to work on it full time and just keep it at more of a local level. +But I think based on the impact that I'm trying to have throughout the entire veteran community and not just on veterans themselves but the organizations which could help...we've got this concept called train the trainer in the military, which is the experience I had as well. But essentially, it's I can do all the work and have all the impact. But it would be 10X more impactful if I'm working with Fortune 500 companies that are doing the same thing that I'm doing, impact in the veteran community in the same way that I am. +So I think that's the direction I'll probably end up going, and that's why I'll have to go look for funding from other sources to build this thing the way I want to build it. So we'll see. We'll see. +CHAD: The problem with funding, obviously, is that if it comes from traditional investment sources, then they expect a return, and you have to be able to show that. It might be made up, but you have to have a story that demonstrates that there's a return. And you alluded to one angle at the beginning when you talked about healthcare. Do you see that as a potential angle in terms of what the business model might be and what industry you might actually be part of? +JT: That's a great question. So I know that if I go full-fledged down the healthcare route, social determinants of health, tracking health outcomes for the veteran community, then most definitely, this would be something where I would need outside funding, traditional funding to build this thing. And I think that's where when it comes to like, okay, I set out on this journey to impact the veteran community, and I want to have the most impact possible. That's going to be the route I'm going to have to go down. +But quite candidly, I do not have at this point enough expertise around the healthcare space to say, okay, let's go down that pathway. Right now, part of the journey that I'm on outside of just trying to build this thing and get this thing launched over the next month, or two is how do I get myself more integrated into the healthcare world to better understand how what I'm building overlaps or integrates into what's going on around social determinants of health in the healthcare space? And how do I insert myself into that? That's something I'm currently assessing. +CHAD: Well, and the interesting thing, too, for me is the thought that I wonder if that actually is something that is top of mind for the users, the veterans, or whether they're just thinking I need a job, [chuckles] and they're not necessarily thinking about their health top of mind. I mean, what do you think? +JT: They're not today. Absolutely not. Today when they reach out to me, they're like...and it's funny because that just opens another can of worms. But it just opens up this whole nother aspect of what I'm doing. So when they come to me, they're like, "I need a job." They're like, "I'm about to lose my car. I need help with my car payment," or "I'm going to be homeless soon." That's how people reach out to me. But, Chad, that's not truly the issue. +As you can imagine, if you're at the point to where you're about to be homeless, there's all this other stuff going on within your life. That's truly the work that we do. It's like people come to me...I have people reach out to me literally every single day. "I need help with this. I need help with that." And I'm like, okay, I have a conversation with them. And then we realize there's like 9, 10, 11 other things going on. So to answer your question, they're not thinking about this healthcare issue. +And from a user standpoint, that's not even how I want to approach this, like telling them, "Oh, I'm going to be here to improve your health outcomes." I wouldn't have that conversation with them. My conversation with them would still be around these different pillars. But on the organizational side, that's where I would communicate to them and say, "I've got these group of individuals who are coming to me and saying, 'I need this assistance.'" And what we're doing at the end of the day is improving their health outcomes. And what that means is, healthcare payer, they're not touching your healthcare system, which means you're saving tons of money. +And that's the part that I'm currently unpacking to say, okay, not to the user that we're doing this work and healthcare but to these organizations. And there are examples of this already out there. So, how do I do that but stay true to the work that I'm doing with the military veteran? Because one of the things that I know that's not going to change for what I'm building is the focus on the user. There are 40,000 veteran service organizations alone. There's $250 billion that gets poured into the veteran community through the Department of Veteran Affairs. +So there's no shortage of organizations working on the veteran community, with the veteran community, and there's no shortage of money out there when it comes to helping bolster the veteran community or improve outcomes within the veteran community. The true challenge that I see or the true issue that I see is there's a lack of focus on the actual veteran themselves and what they're going through. There are no tools out there for them to tap into and go on this journey. That's what I'm laser-focused on is how do I create an amazing experience for the military veteran themselves, not the organizations that are out there doing some of this work, if that makes sense. +CHAD: It totally does. And I think it really makes sense for you. I think it's a problem that a lot of startups face is that there's this draw, maybe because of your business model or because of the environment that you have this other piece, but what you really need to do is focus on creating value for your users. And in an ideal world, those two things become aligned over time. +You mentioned...a little while ago, you said something over the next few months, we got to get this launched. So there's a sign-up on the website now to become part of the community. But are you not fully launched yet? +JT: No. So what we've got right now is a landing page which essentially is building a list for individuals. Once I launch, I reach out and say, "Hey, we're live." What's not publicly facing right now is that user experience that I described. That's what's being built. But let me take a step back because we're still doing that grassroots work to where we're working with veterans one on one. So that's still something that we're heavily doing. But again, the idea here is to how do I replicate this work that we're doing to millions of people? That's what we're going to roll out here. +CHAD: I know timelines can be tricky. [laughs] What is your working timeline for doing that? +JT: As far as launching it? +CHAD: Mm-hmm. +JT: [laughs] When people ask me, you know, one or two months. It's funny; when I first started this back when I was doing the customer discovery, I was getting all this great information and learning more intimately about what the veterans community is going through. I've got my own experience. I've got the experience of people within my ecosystem. But I was just astounded by all the myriad of issues that were going on. +And I was like, oh man, I'm going to have something built and ready to go in like three months. And this is like January 2020, February 2020. I was like, I'm going to have something by Veterans Day this year. It's going to be like everyone's going to know about it. Obviously, that didn't happen because the realities [laughs] of building a tech startup set in really quickly. But we're fairly close. I'm aiming for no later than two or three months, but I hate to put the actual time on it just yet. +CHAD: And I think as a founder, you need to give yourself...pressure is good. But you also need to give yourself permission to not ship until you're ready and proud of what you've done. Now the trick is most people wait too long. [laughs] So the trick is actually forcing yourself to launch something that you're probably not unhappy with but actually is sufficient. +JT: Yeah, that's right. That's right. I don't want to wait until it's, quote, unquote, "perfect." But I do want to ensure that the individuals that do come to the front door in the very beginning they're going to get a great experience. And if they don't, then there's that feedback loop that helps us get better because that's what it's about. Whether you're a young tech startup or you're Facebook or whoever, there needs to be that feedback loop built-in in the right way. So that's what we're doing. +We're trying to ensure that, okay, we've got the foundation of this thing built correctly. And then we've got these feedback loops at all the right points to make this thing even better going forward. And then separately, as every founder is going through, how do you continue to build this thing or fund this thing, rather, to keep it going forward? And that's through bootstrapping. That's through the revenue model that we've got going. And that's through some of these partnerships that we're trying to put wet ink on right now as well. So a lot of things going on. +CHAD: So if someone's listening to this and they're in a position where they say, "I care a lot about this. I want to help. I'm a founder or a leader at a company. And I want to work with Promenade." How do they get in touch with you? Where are the best places for them to do that? +JT: Yeah, they can reach out to me at jt@promenade.ai. That's the quickest and easiest way. We've got our Instagram page up and our LinkedIn page up. You can reach out on there. But the quickest way if you're like, I want to contribute, our organization we've been thinking about how do we work with the veteran community more closely? How do we recruit them? I've got veterans in my family that are going through some of the same challenges. I want to get them in touch with you. The quickest way is just email jt@promenade.ai. +CHAD: Awesome. And good luck in this final stretch towards launch. And I wish you all the best. +JT: I appreciate it. +CHAD: And maybe you can come back on the show a few months post-launch and debrief. [laughs] +JT: Yeah. I would love to. I would love to. I'm sure I'll have plenty of lessons learned. [laughs] +CHAD: Yeah, exactly. Again, that was promenade.ai for the website. And you can subscribe to this show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Thank you, JT, for stopping by. If other folks want to follow along with you, where can they do that? +JT: Instagram, we're at promenade.ai, and LinkedIn, you can find us the same way. +CHAD: Awesome. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: JT Liddell. + + + JT Lidell is the Founder of Promenade, which seamlessly matches and connects military veterans to the resources, people, and organizations that matter to them.

+ +

Chad talks with JT about being a mission-driven, bootstrapped organization, the problems that he's encountered and hopes that Promenade solves, and aggregating people, tools, resources, and funding to make it happen.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is JT Liddell, the Founder of Promenade, which seamlessly matches and connects military veterans to the resources, people, and organizations that matter to them. JT, thank you so much for joining me.

+ +

JT: No, thank you for having me. Excited to talk to you about what we're building over here and having this conversation. So thank you so much for having me on today.

+ +

CHAD: I love mission-driven organizations, and Promenade falls right into that. How did it come about for you?

+ +

JT: Yeah, this has been...the inception of it really truly began many, many years ago when I first joined the military straight out of high school. So I went to The Naval Academy, actually, started there then went to the army. Fast forward 7, 8, 9, 10 years, and as I was getting out of the military and trying to join the civilian workforce, the civilian world, that's where a lot of the problems and challenges that I'm trying to solve through Promenade started.

+ +

And then, working in the technology space in corporate America really allowed me to identify some of the solutions and tools that I'm working with now. But to answer your original question, the beginning of Promenade or the inception of Promenade really began with my entry into the military.

+ +

CHAD: What were some of the problems that you encountered and that you hope that Promenade solves?

+ +

JT: Back in 2000...I left the military officially in 2010 but went straight into defense contracting work from there and worked there for a few years. And it was, as I was leaving, I went literally from Afghanistan, and 30 days later, I was sitting in an MBA classroom. And leaving Afghanistan, I thought there was literally no problem, no challenge...after going through three deployments to Afghanistan and being deployed to other parts of the world, I was like, there's nothing that I'm going to come against that I won't be able to tackle. That was the furthest from the truth.

+ +

So there are a number of issues when it came to relationships, when it came to navigating the workforce, when it came to just understanding how drastically different the civilian world was from being in the military and the defense industry. So those problems are umbrellas, and there are many, many things underneath those that I came up against.

+ +

CHAD: What are some of the ways that, you know, I speak as someone not having served in the military. What are some of the big ways in which civilian employment is different?

+ +

JT: It wasn't even necessarily...well, obviously, there are huge differences obviously from the military and civilian employment. But it was really even like, how do you get entry into the civilian workforce just from the very beginning? So, how do you craft a resume? It seems like a minor thing at this point in my life, but it's a huge one. When you leave the military, you have these 9, 10, 11-page resumes. And that's what you're supposed to do. You're supposed to put literally every single piece of experience that you have on this resume.

+ +

But when you come to the civilian world, you have to somehow condense all of that down to one page, and there's a science to doing that, and that was one of the first huge hurdles. Because a resume is just your ticket into the door, it's a ticket to that interview. That's just literally the first step. And that was something that I didn't realize was something I was going to have to hone my skill at.

+ +

CHAD: Do you think that a lot of companies overlook the value of military service?

+ +

JT: Yeah, that's a tough one to answer. So it's hard to say overlook when as a military veteran just taking myself, for instance, you know, in a lot of ways, I was not communicating effectively what my experience was in relation to the value I could provide to that organization. So as a recruiter or a headhunter, whoever is doing that initial review, they're simply looking...for a large part, they don't have experience in the military. So they don't understand the jargon and what some of these different jobs really mean with the impact they had on their organization. So there's still a lot of meat in the middle here.

+ +

So that individual needs to do a better job of communicating the exact value through a corporate sense how that value could contribute to corporate America or whatever type of organization they're trying to join. And organizations need to do a much better job of understanding that there's this untapped value in the military community and teaching and training their organizations or whoever is doing the intake process to look for the value that the military community can bring. So I don't think it's a one-sided thing. I think both sides need to come together and do a better job.

+ +

CHAD: So I said in the intro that Promenade matches and connects veterans to the resources, people, and organizations that matter to them. What exactly does that look like in terms of the product today and what you're doing?

+ +

JT: Yeah, absolutely. So this really began as a grassroots operation through my own ecosystem. Many, many years ago, when I was first getting in the military, and I was starting to get traction and understanding how to navigate the civilian world, I started to reach back. People would reach out to me, and I would reach back. And they would ask me, "How did you get here? How did you do that?" And I would just help people, review their resumes for them, get them connected to different jobs and career pathways. And then I started to do that a little bit more officially, if you will.

+ +

And then, I realized this is not just a problem within my own ecosystem; this is a problem across the military community. So as I was working in technology, as I mentioned before, I started to identify tools, one of them being artificial intelligence, that could help me scale the work that I was doing. So the pathway that I started to set out on was how do I take this grassroots work that I'm doing, and then how do I scale that work to millions of people rather than just dozens of people? So that's the journey that I'm on right now. I don't know if that answered your question or not.

+ +

CHAD: So if someone is listening and they're a veteran, what is the product going to offer them now?

+ +

JT: So they'll come on, and they'll onboard to the platform. So essentially, we're just taking the process that we've been doing offline, and we're bringing it online. So they'll come on. They'll fill out some demographic information. They'll answer a few questions about where they are in their current post-military journey. They could even be thinking about getting out. The product will still help them as they're on their way out, thinking about getting out. They could have been out for a month, a year, an entire decade doesn't really matter. We'll help assess where they are in their post-military journey.

+ +

After they go through that intake process, we'll give them the option to talk to one of our coaches, which can make this experience a little bit more personalized. And that's one of the huge things that I learned as I've been building Promenade is when I first started tackling this, thinking about tackling this issue through technology, I was like, okay, this technology these tools that I've identified and I've researched these are going to be the things that solve this problem. That's what's going to do this. No, that's what's going to fix this.

+ +

[chuckles] And what I quickly realized is you can't remove that human component from this process. There are just things that technology doesn't understand about the military experience. So having a coach, having an individual or human to talk to at the very beginning of this process, or whatever that individual needs is extremely crucial and hugely beneficial to this process. So we put that coach in front of them. That's completely optional because we do want to allow this to be self-service and self-guided.

+ +

So if they choose to get in front of that coach, they'll be able to talk one on one and augment this process. If they don't, they'll go straight to our dashboard. And what the dashboard will do is it's going to help that individual identify different areas within their post-military journey where they can improve and get better.

+ +

And, Chad, we haven't talked about this, but we've got this social impact-driven product that we're building. But the lens that we're really thinking about this is through a healthcare lens. So what that means is there's this term called social determinants of health. And what that means is...the very simple version is a super simple concept. Every part of your life impacts your overall health. The health care system, like when you go to the hospital, only impacts 20%-30% of your overall health.

+ +

The things that truly impact your health are things like, do you have a job? Have you talked to a therapist in the last six months? Do you have food, you know, the right type of food? Do you have access to the right type of food? Not just food. Are you ordering Burger King every day, McDonald's every day? But are you eating healthy food? And do you have consistent access? Those are the things that affect your overall health.

+ +

So we look at all of these different factors about the veteran and how they're going through their post-military journey. And we give them a score on all these different verticals. So essentially, through that score, we're helping them identify what those gaps are, and then we're pushing them resources to help fill those gaps.

+ +

So they'll get a couple of things through our platform. They'll get that dashboard and that score and personally recommended or personalized recommended resources to them, and that's where the artificial intelligence component comes into it. And then they'll have sort of a search field where they can just go and keyword for things just like they would go into Google and search for something.

+ +

And then the third component to this is the community that we're building, and that won't be rolled out initially. But once we've got critical mass, we've got a community that we're building where they'll get connected to people within our community, maybe people with the same skills and interest, people that they were deployed with, people that they were stationed with, or people that they just came across. And we've got a method to do that. But that's really what it's about is bringing this community together, helping them assess where they are in their post-military journey, and then putting the right resources in front of them at the right time based on who they are. So that's the experience they'll get, to answer your question.

+ +

CHAD: Awesome. Who pays for Promenade?

+ +

JT: So it's going to be twofold. So there'll be a freemium model for the military veteran, so all those things that I just mentioned, minus one or two. They'll get free access to the platform. So they'll be able to log on. They'll be able to see where they're at in their journey. And they'll be able to navigate the platform and get those personalized recommendations.

+ +

On the organizational side, they will also pay to access the platform. And then there's some other work...back when I mentioned a couple of minutes ago that organizations need to do a better job of understanding the military community, we help organizations better understand the military community, attract and retain military veteran talent if that's something that they're in the business of doing. So there are multiple ways to do it.

+ +

CHAD: And organizations would pay for that.

+ +

JT: That's right. Absolutely. Yeah.

+ +

CHAD: Is that a significant or a fundamental part of the business model?

+ +

JT: Which part?

+ +

CHAD: The organizations paying.

+ +

JT: Yeah, it is. So it depends on which part of interacting with the organization that we're talking about. So there are two ways we can do that. There's A, giving them access to the platform so just, for example, on the jobs portion, careers portion, recruiters. We'd give them access to the platform to get access to the talent. But on the let's help this organization think about how they're even reaching out to the veteran community, how they're recruiting them, the process that veterans are going through in order to apply to these organizations, once veterans are in these organizations, how are they supporting the veteran community?

+ +

And maybe even after they've left, depending on which organization you're talking about, how are you supporting that veteran community once they've left so they can be...you want them to be ambassadors for your organization. How are you supporting the veteran community even after they've left? So that's two completely different ways that we can interact with the organization. The fundamental one would be those organizations getting access to our platform and interacting with the veteran community. That for sure would be fundamental to what we're building.

+ +

CHAD: So who's funding Promenade right now?

+ +

JT: [laughs] Yeah, that's a great question. So this is definitely up until maybe a year or so ago; it's definitely been bootstrap built for sure completely out of my pocket. But thanks to some of the visibility we were able to get, in the work we were able to do, organizations were able to get in touch. We've gotten a couple of grants, one huge one from Google for Startups last year. That was $100,000 from Google for Startups. That's been obviously huge for the work and the momentum.

+ +

And what I always tell people is, you know, Chad, you've been doing this a while. [laughs] You know that $100,000 can get run through pretty quickly in the tech startup space. That was huge, and I don't want to downplay that by any means. But that wasn't even the biggest impact to what we're doing. It's just the visibility that it created for our organization.

+ +

We've had just the veterans that we work with; we've had so many reach out just because they heard about us but organizations as well that have reached out to us. They want to work with us. They want to support us. That was huge. But to answer your question, it's a combination of grant money, cash awards from different organizations, and bootstrapping it from me JT here.

+ +

CHAD: Well, thanks for doing that [laughs] and bringing this really important service to life. What are some of the barriers to achieving the success that you want to achieve with Promenade?

+ +

JT: What we're doing is essentially we're aggregating information. We're aggregating people. We're aggregating tools and resources. We're bringing all this together. I didn't think it would be easy by any means. But it's definitely much harder than I imagined it would be when I set out in this journey a couple of years ago. One of the hardest things about this is you've got all of these different areas that you're trying to assess veterans and getting these tools and resources and organizations in front of them. How do you consistently and with quality put those organizations and tools and resources in front of the veteran?

+ +

I want all of them to have the same experience. I want them to have an amazing experience. I want them to get connected quickly and with quality to the people and organizations and tools that they need to get connected to. So how do you make that experience consistent and standard across the board? And how do you control as much as possible the quality of that interaction?

+ +

Building these partnerships has been challenging. It's been difficult. But every time, I get frustrated...just like, every startup goes through those barriers. You get frustrated. I just think back to those moments where I was down on my post-military journey. And I'm like, I never want another veteran to have to go through that. That's what keeps me pushing when those barriers do hit.

+ +

And I'm like, this is going to be hard. How do I keep that organization, or how do I ensure that organization is doing A, B, and C? How do I ensure I'm keeping this veteran pushing forward and motivated when they get frustrated? Those are some of the barriers. But as I said before, I just look back on when I was going through my journey. And I don't want any veteran to have to go through that experience. So that's what keeps me going.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you officially started Promenade in May of 2020. Is that right?

+ +

JT: I came up with the idea actually in 2017 sort of the framework for what I'm doing now. And I'm in Atlanta, Georgia, and I don't know how much you know about the tech startup space in Atlanta, Georgia, but it's booming right now for sure. That'd be an understatement. And I have a few different people around me, a number of people around me in my ecosystem that are in the tech startup space. And I watched them going through their own personal journeys and finding success.

+ +

And I was like, number one, I have all these people around me that are doing it, non-technical founders, technical founders, first-time founders. There's no reason I can't also do this. And then number two, I was like, if I looked on my phone seven years from now and I saw a Promenade built by somebody else, I'd be super pissed. [laughter] I'm going to be so pissed.

+ +

I remember this quite clearly December 2019; I was like, you have to do something; if you don't, you're going to regret it. So December 2019, I went, and I signed up for this organization here in Atlanta called ATDC. I signed up for my first intro to customer discovery class. And from there, I've been pushing ever since. I think I incorporated the organization around May or March or something like that officially. But the idea, inception in its current form probably 2017 and then really began building in January 2020.

+ +

CHAD: So, how do you think the pandemic has impacted the ability to start Promenade?

+ +

JT: Yeah, a number of different ways. But I would say net-net actually in a positive way in not like the actual of what the pandemic means but the environment. It showed me clear as day that there's a huge net need for digital services when it comes to the military veteran community. Because a large resource for the veteran community is Department of Veteran Affairs, you know, doing amazing work doing great work. But just like many other government organizations, many aspects of it were shut down during the pandemic.

+ +

So let's just talk about mental wellness because that's something that is highly visible in the veteran community as being an issue. The suicide rate increased exponentially during the pandemic within the veteran community. That's because people are isolated. They're already going through issues; maybe people are getting out of the military during the pandemic.

+ +

It just showed me that there's a huge increased need for digitally online for this veteran community, resources for the veteran community, and just giving them an ecosystem to interact in. And it just pushed me even harder to build what I was building. So the pandemic was obviously a very terrible thing, but in terms of Promenade and the work that I was doing, it just made me go even harder for sure.

+ +

CHAD: So right now, is it just you?

+ +

JT: Yeah, so it's me. I've got one personal assistant, and I've got several designers and developers that I work with.

+ +

CHAD: On a contract basis?

+ +

JT: Yes, all contractors. But in terms of people who are hands-on building this thing, I probably couldn't even count the number, as I'm sure you know when it comes to developers and designers trying to build these solutions. But in terms of being officially a part of Promenade, it's still just me going at this thing right now.

+ +

CHAD: And while you're doing this, you have another full-time job, right?

+ +

JT: I do. I do.

+ +

CHAD: I think that's a scenario that a lot of people find themselves in is wanting to do something new but not necessarily being able to, you know, you're bootstrapping something on the side. How do you make it work? And what would need to happen for you to take the leap to be able to just work on Promenade?

+ +

JT: How do I make it work? A lot of Red Bull, a lot of energy drinks, [chuckles] and a lot of late nights. But again, as I mentioned before, that's something I would put in as time as a barrier when it comes to building this thing. I just take it back to the many conversations I have with veterans as they've been going through their own personal journeys. That just keeps me going.

+ +

As far as what would it take for me to move away to work on Promenade full time, the only true thing I think it would take would really be line of sight and visibility on being able to drive this thing forward in a sustainable manner, just having a line of sight on that, on this thing. Okay, I've got the traction. I can see it. It's tangible. I just need to do A, B, and C to keep pushing this thing forward. I know that's sort of vague, but that's really what it would take.

+ +

CHAD: Do you think you're going to have to take funding from somewhere, or do you think you can continue to bootstrap and operate on the grants and awards?

+ +

JT: It depends. That's a good question. That's something I've gone back and forth with. Working in the tech startup space, that's something that's discussed a lot is angel investors and VCs, and you need to do this to attract funders and things like that. That's something that's discussed a lot in this space. But it's something that I've gone back and forth with. It really comes down to what I want this thing to be at the end of the day. This thing could be huge. There's a huge gap in the military veteran space in a multitude of ways.

+ +

This thing could be a unicorn if that's the direction I really wanted to take it. And I think if I go down that pathway, it's for sure going to take funding from outside sources. But if I want to keep this thing more small scale or maybe even local to that Atlanta, Georgia region where I live and only focus on that one region, that's something I could probably bootstrap until I've got the revenue necessary to work on it full time and just keep it at more of a local level.

+ +

But I think based on the impact that I'm trying to have throughout the entire veteran community and not just on veterans themselves but the organizations which could help...we've got this concept called train the trainer in the military, which is the experience I had as well. But essentially, it's I can do all the work and have all the impact. But it would be 10X more impactful if I'm working with Fortune 500 companies that are doing the same thing that I'm doing, impact in the veteran community in the same way that I am.

+ +

So I think that's the direction I'll probably end up going, and that's why I'll have to go look for funding from other sources to build this thing the way I want to build it. So we'll see. We'll see.

+ +

CHAD: The problem with funding, obviously, is that if it comes from traditional investment sources, then they expect a return, and you have to be able to show that. It might be made up, but you have to have a story that demonstrates that there's a return. And you alluded to one angle at the beginning when you talked about healthcare. Do you see that as a potential angle in terms of what the business model might be and what industry you might actually be part of?

+ +

JT: That's a great question. So I know that if I go full-fledged down the healthcare route, social determinants of health, tracking health outcomes for the veteran community, then most definitely, this would be something where I would need outside funding, traditional funding to build this thing. And I think that's where when it comes to like, okay, I set out on this journey to impact the veteran community, and I want to have the most impact possible. That's going to be the route I'm going to have to go down.

+ +

But quite candidly, I do not have at this point enough expertise around the healthcare space to say, okay, let's go down that pathway. Right now, part of the journey that I'm on outside of just trying to build this thing and get this thing launched over the next month, or two is how do I get myself more integrated into the healthcare world to better understand how what I'm building overlaps or integrates into what's going on around social determinants of health in the healthcare space? And how do I insert myself into that? That's something I'm currently assessing.

+ +

CHAD: Well, and the interesting thing, too, for me is the thought that I wonder if that actually is something that is top of mind for the users, the veterans, or whether they're just thinking I need a job, [chuckles] and they're not necessarily thinking about their health top of mind. I mean, what do you think?

+ +

JT: They're not today. Absolutely not. Today when they reach out to me, they're like...and it's funny because that just opens another can of worms. But it just opens up this whole nother aspect of what I'm doing. So when they come to me, they're like, "I need a job." They're like, "I'm about to lose my car. I need help with my car payment," or "I'm going to be homeless soon." That's how people reach out to me. But, Chad, that's not truly the issue.

+ +

As you can imagine, if you're at the point to where you're about to be homeless, there's all this other stuff going on within your life. That's truly the work that we do. It's like people come to me...I have people reach out to me literally every single day. "I need help with this. I need help with that." And I'm like, okay, I have a conversation with them. And then we realize there's like 9, 10, 11 other things going on. So to answer your question, they're not thinking about this healthcare issue.

+ +

And from a user standpoint, that's not even how I want to approach this, like telling them, "Oh, I'm going to be here to improve your health outcomes." I wouldn't have that conversation with them. My conversation with them would still be around these different pillars. But on the organizational side, that's where I would communicate to them and say, "I've got these group of individuals who are coming to me and saying, 'I need this assistance.'" And what we're doing at the end of the day is improving their health outcomes. And what that means is, healthcare payer, they're not touching your healthcare system, which means you're saving tons of money.

+ +

And that's the part that I'm currently unpacking to say, okay, not to the user that we're doing this work and healthcare but to these organizations. And there are examples of this already out there. So, how do I do that but stay true to the work that I'm doing with the military veteran? Because one of the things that I know that's not going to change for what I'm building is the focus on the user. There are 40,000 veteran service organizations alone. There's $250 billion that gets poured into the veteran community through the Department of Veteran Affairs.

+ +

So there's no shortage of organizations working on the veteran community, with the veteran community, and there's no shortage of money out there when it comes to helping bolster the veteran community or improve outcomes within the veteran community. The true challenge that I see or the true issue that I see is there's a lack of focus on the actual veteran themselves and what they're going through. There are no tools out there for them to tap into and go on this journey. That's what I'm laser-focused on is how do I create an amazing experience for the military veteran themselves, not the organizations that are out there doing some of this work, if that makes sense.

+ +

CHAD: It totally does. And I think it really makes sense for you. I think it's a problem that a lot of startups face is that there's this draw, maybe because of your business model or because of the environment that you have this other piece, but what you really need to do is focus on creating value for your users. And in an ideal world, those two things become aligned over time.

+ +

You mentioned...a little while ago, you said something over the next few months, we got to get this launched. So there's a sign-up on the website now to become part of the community. But are you not fully launched yet?

+ +

JT: No. So what we've got right now is a landing page which essentially is building a list for individuals. Once I launch, I reach out and say, "Hey, we're live." What's not publicly facing right now is that user experience that I described. That's what's being built. But let me take a step back because we're still doing that grassroots work to where we're working with veterans one on one. So that's still something that we're heavily doing. But again, the idea here is to how do I replicate this work that we're doing to millions of people? That's what we're going to roll out here.

+ +

CHAD: I know timelines can be tricky. [laughs] What is your working timeline for doing that?

+ +

JT: As far as launching it?

+ +

CHAD: Mm-hmm.

+ +

JT: [laughs] When people ask me, you know, one or two months. It's funny; when I first started this back when I was doing the customer discovery, I was getting all this great information and learning more intimately about what the veterans community is going through. I've got my own experience. I've got the experience of people within my ecosystem. But I was just astounded by all the myriad of issues that were going on.

+ +

And I was like, oh man, I'm going to have something built and ready to go in like three months. And this is like January 2020, February 2020. I was like, I'm going to have something by Veterans Day this year. It's going to be like everyone's going to know about it. Obviously, that didn't happen because the realities [laughs] of building a tech startup set in really quickly. But we're fairly close. I'm aiming for no later than two or three months, but I hate to put the actual time on it just yet.

+ +

CHAD: And I think as a founder, you need to give yourself...pressure is good. But you also need to give yourself permission to not ship until you're ready and proud of what you've done. Now the trick is most people wait too long. [laughs] So the trick is actually forcing yourself to launch something that you're probably not unhappy with but actually is sufficient.

+ +

JT: Yeah, that's right. That's right. I don't want to wait until it's, quote, unquote, "perfect." But I do want to ensure that the individuals that do come to the front door in the very beginning they're going to get a great experience. And if they don't, then there's that feedback loop that helps us get better because that's what it's about. Whether you're a young tech startup or you're Facebook or whoever, there needs to be that feedback loop built-in in the right way. So that's what we're doing.

+ +

We're trying to ensure that, okay, we've got the foundation of this thing built correctly. And then we've got these feedback loops at all the right points to make this thing even better going forward. And then separately, as every founder is going through, how do you continue to build this thing or fund this thing, rather, to keep it going forward? And that's through bootstrapping. That's through the revenue model that we've got going. And that's through some of these partnerships that we're trying to put wet ink on right now as well. So a lot of things going on.

+ +

CHAD: So if someone's listening to this and they're in a position where they say, "I care a lot about this. I want to help. I'm a founder or a leader at a company. And I want to work with Promenade." How do they get in touch with you? Where are the best places for them to do that?

+ +

JT: Yeah, they can reach out to me at jt@promenade.ai. That's the quickest and easiest way. We've got our Instagram page up and our LinkedIn page up. You can reach out on there. But the quickest way if you're like, I want to contribute, our organization we've been thinking about how do we work with the veteran community more closely? How do we recruit them? I've got veterans in my family that are going through some of the same challenges. I want to get them in touch with you. The quickest way is just email jt@promenade.ai.

+ +

CHAD: Awesome. And good luck in this final stretch towards launch. And I wish you all the best.

+ +

JT: I appreciate it.

+ +

CHAD: And maybe you can come back on the show a few months post-launch and debrief. [laughs]

+ +

JT: Yeah. I would love to. I would love to. I'm sure I'll have plenty of lessons learned. [laughs]

+ +

CHAD: Yeah, exactly. Again, that was promenade.ai for the website. And you can subscribe to this show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Thank you, JT, for stopping by. If other folks want to follow along with you, where can they do that?

+ +

JT: Instagram, we're at promenade.ai, and LinkedIn, you can find us the same way.

+ +

CHAD: Awesome. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: JT Liddell.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + JT Lidell is the Founder of Promenade, which seamlessly matches and connects military veterans to the resources, people, and organizations that matter to them.

+ +

Chad talks with JT about being a mission-driven, bootstrapped organization, the problems that he's encountered and hopes that Promenade solves, and aggregating people, tools, resources, and funding to make it happen.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is JT Liddell, the Founder of Promenade, which seamlessly matches and connects military veterans to the resources, people, and organizations that matter to them. JT, thank you so much for joining me.

+ +

JT: No, thank you for having me. Excited to talk to you about what we're building over here and having this conversation. So thank you so much for having me on today.

+ +

CHAD: I love mission-driven organizations, and Promenade falls right into that. How did it come about for you?

+ +

JT: Yeah, this has been...the inception of it really truly began many, many years ago when I first joined the military straight out of high school. So I went to The Naval Academy, actually, started there then went to the army. Fast forward 7, 8, 9, 10 years, and as I was getting out of the military and trying to join the civilian workforce, the civilian world, that's where a lot of the problems and challenges that I'm trying to solve through Promenade started.

+ +

And then, working in the technology space in corporate America really allowed me to identify some of the solutions and tools that I'm working with now. But to answer your original question, the beginning of Promenade or the inception of Promenade really began with my entry into the military.

+ +

CHAD: What were some of the problems that you encountered and that you hope that Promenade solves?

+ +

JT: Back in 2000...I left the military officially in 2010 but went straight into defense contracting work from there and worked there for a few years. And it was, as I was leaving, I went literally from Afghanistan, and 30 days later, I was sitting in an MBA classroom. And leaving Afghanistan, I thought there was literally no problem, no challenge...after going through three deployments to Afghanistan and being deployed to other parts of the world, I was like, there's nothing that I'm going to come against that I won't be able to tackle. That was the furthest from the truth.

+ +

So there are a number of issues when it came to relationships, when it came to navigating the workforce, when it came to just understanding how drastically different the civilian world was from being in the military and the defense industry. So those problems are umbrellas, and there are many, many things underneath those that I came up against.

+ +

CHAD: What are some of the ways that, you know, I speak as someone not having served in the military. What are some of the big ways in which civilian employment is different?

+ +

JT: It wasn't even necessarily...well, obviously, there are huge differences obviously from the military and civilian employment. But it was really even like, how do you get entry into the civilian workforce just from the very beginning? So, how do you craft a resume? It seems like a minor thing at this point in my life, but it's a huge one. When you leave the military, you have these 9, 10, 11-page resumes. And that's what you're supposed to do. You're supposed to put literally every single piece of experience that you have on this resume.

+ +

But when you come to the civilian world, you have to somehow condense all of that down to one page, and there's a science to doing that, and that was one of the first huge hurdles. Because a resume is just your ticket into the door, it's a ticket to that interview. That's just literally the first step. And that was something that I didn't realize was something I was going to have to hone my skill at.

+ +

CHAD: Do you think that a lot of companies overlook the value of military service?

+ +

JT: Yeah, that's a tough one to answer. So it's hard to say overlook when as a military veteran just taking myself, for instance, you know, in a lot of ways, I was not communicating effectively what my experience was in relation to the value I could provide to that organization. So as a recruiter or a headhunter, whoever is doing that initial review, they're simply looking...for a large part, they don't have experience in the military. So they don't understand the jargon and what some of these different jobs really mean with the impact they had on their organization. So there's still a lot of meat in the middle here.

+ +

So that individual needs to do a better job of communicating the exact value through a corporate sense how that value could contribute to corporate America or whatever type of organization they're trying to join. And organizations need to do a much better job of understanding that there's this untapped value in the military community and teaching and training their organizations or whoever is doing the intake process to look for the value that the military community can bring. So I don't think it's a one-sided thing. I think both sides need to come together and do a better job.

+ +

CHAD: So I said in the intro that Promenade matches and connects veterans to the resources, people, and organizations that matter to them. What exactly does that look like in terms of the product today and what you're doing?

+ +

JT: Yeah, absolutely. So this really began as a grassroots operation through my own ecosystem. Many, many years ago, when I was first getting in the military, and I was starting to get traction and understanding how to navigate the civilian world, I started to reach back. People would reach out to me, and I would reach back. And they would ask me, "How did you get here? How did you do that?" And I would just help people, review their resumes for them, get them connected to different jobs and career pathways. And then I started to do that a little bit more officially, if you will.

+ +

And then, I realized this is not just a problem within my own ecosystem; this is a problem across the military community. So as I was working in technology, as I mentioned before, I started to identify tools, one of them being artificial intelligence, that could help me scale the work that I was doing. So the pathway that I started to set out on was how do I take this grassroots work that I'm doing, and then how do I scale that work to millions of people rather than just dozens of people? So that's the journey that I'm on right now. I don't know if that answered your question or not.

+ +

CHAD: So if someone is listening and they're a veteran, what is the product going to offer them now?

+ +

JT: So they'll come on, and they'll onboard to the platform. So essentially, we're just taking the process that we've been doing offline, and we're bringing it online. So they'll come on. They'll fill out some demographic information. They'll answer a few questions about where they are in their current post-military journey. They could even be thinking about getting out. The product will still help them as they're on their way out, thinking about getting out. They could have been out for a month, a year, an entire decade doesn't really matter. We'll help assess where they are in their post-military journey.

+ +

After they go through that intake process, we'll give them the option to talk to one of our coaches, which can make this experience a little bit more personalized. And that's one of the huge things that I learned as I've been building Promenade is when I first started tackling this, thinking about tackling this issue through technology, I was like, okay, this technology these tools that I've identified and I've researched these are going to be the things that solve this problem. That's what's going to do this. No, that's what's going to fix this.

+ +

[chuckles] And what I quickly realized is you can't remove that human component from this process. There are just things that technology doesn't understand about the military experience. So having a coach, having an individual or human to talk to at the very beginning of this process, or whatever that individual needs is extremely crucial and hugely beneficial to this process. So we put that coach in front of them. That's completely optional because we do want to allow this to be self-service and self-guided.

+ +

So if they choose to get in front of that coach, they'll be able to talk one on one and augment this process. If they don't, they'll go straight to our dashboard. And what the dashboard will do is it's going to help that individual identify different areas within their post-military journey where they can improve and get better.

+ +

And, Chad, we haven't talked about this, but we've got this social impact-driven product that we're building. But the lens that we're really thinking about this is through a healthcare lens. So what that means is there's this term called social determinants of health. And what that means is...the very simple version is a super simple concept. Every part of your life impacts your overall health. The health care system, like when you go to the hospital, only impacts 20%-30% of your overall health.

+ +

The things that truly impact your health are things like, do you have a job? Have you talked to a therapist in the last six months? Do you have food, you know, the right type of food? Do you have access to the right type of food? Not just food. Are you ordering Burger King every day, McDonald's every day? But are you eating healthy food? And do you have consistent access? Those are the things that affect your overall health.

+ +

So we look at all of these different factors about the veteran and how they're going through their post-military journey. And we give them a score on all these different verticals. So essentially, through that score, we're helping them identify what those gaps are, and then we're pushing them resources to help fill those gaps.

+ +

So they'll get a couple of things through our platform. They'll get that dashboard and that score and personally recommended or personalized recommended resources to them, and that's where the artificial intelligence component comes into it. And then they'll have sort of a search field where they can just go and keyword for things just like they would go into Google and search for something.

+ +

And then the third component to this is the community that we're building, and that won't be rolled out initially. But once we've got critical mass, we've got a community that we're building where they'll get connected to people within our community, maybe people with the same skills and interest, people that they were deployed with, people that they were stationed with, or people that they just came across. And we've got a method to do that. But that's really what it's about is bringing this community together, helping them assess where they are in their post-military journey, and then putting the right resources in front of them at the right time based on who they are. So that's the experience they'll get, to answer your question.

+ +

CHAD: Awesome. Who pays for Promenade?

+ +

JT: So it's going to be twofold. So there'll be a freemium model for the military veteran, so all those things that I just mentioned, minus one or two. They'll get free access to the platform. So they'll be able to log on. They'll be able to see where they're at in their journey. And they'll be able to navigate the platform and get those personalized recommendations.

+ +

On the organizational side, they will also pay to access the platform. And then there's some other work...back when I mentioned a couple of minutes ago that organizations need to do a better job of understanding the military community, we help organizations better understand the military community, attract and retain military veteran talent if that's something that they're in the business of doing. So there are multiple ways to do it.

+ +

CHAD: And organizations would pay for that.

+ +

JT: That's right. Absolutely. Yeah.

+ +

CHAD: Is that a significant or a fundamental part of the business model?

+ +

JT: Which part?

+ +

CHAD: The organizations paying.

+ +

JT: Yeah, it is. So it depends on which part of interacting with the organization that we're talking about. So there are two ways we can do that. There's A, giving them access to the platform so just, for example, on the jobs portion, careers portion, recruiters. We'd give them access to the platform to get access to the talent. But on the let's help this organization think about how they're even reaching out to the veteran community, how they're recruiting them, the process that veterans are going through in order to apply to these organizations, once veterans are in these organizations, how are they supporting the veteran community?

+ +

And maybe even after they've left, depending on which organization you're talking about, how are you supporting that veteran community once they've left so they can be...you want them to be ambassadors for your organization. How are you supporting the veteran community even after they've left? So that's two completely different ways that we can interact with the organization. The fundamental one would be those organizations getting access to our platform and interacting with the veteran community. That for sure would be fundamental to what we're building.

+ +

CHAD: So who's funding Promenade right now?

+ +

JT: [laughs] Yeah, that's a great question. So this is definitely up until maybe a year or so ago; it's definitely been bootstrap built for sure completely out of my pocket. But thanks to some of the visibility we were able to get, in the work we were able to do, organizations were able to get in touch. We've gotten a couple of grants, one huge one from Google for Startups last year. That was $100,000 from Google for Startups. That's been obviously huge for the work and the momentum.

+ +

And what I always tell people is, you know, Chad, you've been doing this a while. [laughs] You know that $100,000 can get run through pretty quickly in the tech startup space. That was huge, and I don't want to downplay that by any means. But that wasn't even the biggest impact to what we're doing. It's just the visibility that it created for our organization.

+ +

We've had just the veterans that we work with; we've had so many reach out just because they heard about us but organizations as well that have reached out to us. They want to work with us. They want to support us. That was huge. But to answer your question, it's a combination of grant money, cash awards from different organizations, and bootstrapping it from me JT here.

+ +

CHAD: Well, thanks for doing that [laughs] and bringing this really important service to life. What are some of the barriers to achieving the success that you want to achieve with Promenade?

+ +

JT: What we're doing is essentially we're aggregating information. We're aggregating people. We're aggregating tools and resources. We're bringing all this together. I didn't think it would be easy by any means. But it's definitely much harder than I imagined it would be when I set out in this journey a couple of years ago. One of the hardest things about this is you've got all of these different areas that you're trying to assess veterans and getting these tools and resources and organizations in front of them. How do you consistently and with quality put those organizations and tools and resources in front of the veteran?

+ +

I want all of them to have the same experience. I want them to have an amazing experience. I want them to get connected quickly and with quality to the people and organizations and tools that they need to get connected to. So how do you make that experience consistent and standard across the board? And how do you control as much as possible the quality of that interaction?

+ +

Building these partnerships has been challenging. It's been difficult. But every time, I get frustrated...just like, every startup goes through those barriers. You get frustrated. I just think back to those moments where I was down on my post-military journey. And I'm like, I never want another veteran to have to go through that. That's what keeps me pushing when those barriers do hit.

+ +

And I'm like, this is going to be hard. How do I keep that organization, or how do I ensure that organization is doing A, B, and C? How do I ensure I'm keeping this veteran pushing forward and motivated when they get frustrated? Those are some of the barriers. But as I said before, I just look back on when I was going through my journey. And I don't want any veteran to have to go through that experience. So that's what keeps me going.

+ +

Mid-Roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you officially started Promenade in May of 2020. Is that right?

+ +

JT: I came up with the idea actually in 2017 sort of the framework for what I'm doing now. And I'm in Atlanta, Georgia, and I don't know how much you know about the tech startup space in Atlanta, Georgia, but it's booming right now for sure. That'd be an understatement. And I have a few different people around me, a number of people around me in my ecosystem that are in the tech startup space. And I watched them going through their own personal journeys and finding success.

+ +

And I was like, number one, I have all these people around me that are doing it, non-technical founders, technical founders, first-time founders. There's no reason I can't also do this. And then number two, I was like, if I looked on my phone seven years from now and I saw a Promenade built by somebody else, I'd be super pissed. [laughter] I'm going to be so pissed.

+ +

I remember this quite clearly December 2019; I was like, you have to do something; if you don't, you're going to regret it. So December 2019, I went, and I signed up for this organization here in Atlanta called ATDC. I signed up for my first intro to customer discovery class. And from there, I've been pushing ever since. I think I incorporated the organization around May or March or something like that officially. But the idea, inception in its current form probably 2017 and then really began building in January 2020.

+ +

CHAD: So, how do you think the pandemic has impacted the ability to start Promenade?

+ +

JT: Yeah, a number of different ways. But I would say net-net actually in a positive way in not like the actual of what the pandemic means but the environment. It showed me clear as day that there's a huge net need for digital services when it comes to the military veteran community. Because a large resource for the veteran community is Department of Veteran Affairs, you know, doing amazing work doing great work. But just like many other government organizations, many aspects of it were shut down during the pandemic.

+ +

So let's just talk about mental wellness because that's something that is highly visible in the veteran community as being an issue. The suicide rate increased exponentially during the pandemic within the veteran community. That's because people are isolated. They're already going through issues; maybe people are getting out of the military during the pandemic.

+ +

It just showed me that there's a huge increased need for digitally online for this veteran community, resources for the veteran community, and just giving them an ecosystem to interact in. And it just pushed me even harder to build what I was building. So the pandemic was obviously a very terrible thing, but in terms of Promenade and the work that I was doing, it just made me go even harder for sure.

+ +

CHAD: So right now, is it just you?

+ +

JT: Yeah, so it's me. I've got one personal assistant, and I've got several designers and developers that I work with.

+ +

CHAD: On a contract basis?

+ +

JT: Yes, all contractors. But in terms of people who are hands-on building this thing, I probably couldn't even count the number, as I'm sure you know when it comes to developers and designers trying to build these solutions. But in terms of being officially a part of Promenade, it's still just me going at this thing right now.

+ +

CHAD: And while you're doing this, you have another full-time job, right?

+ +

JT: I do. I do.

+ +

CHAD: I think that's a scenario that a lot of people find themselves in is wanting to do something new but not necessarily being able to, you know, you're bootstrapping something on the side. How do you make it work? And what would need to happen for you to take the leap to be able to just work on Promenade?

+ +

JT: How do I make it work? A lot of Red Bull, a lot of energy drinks, [chuckles] and a lot of late nights. But again, as I mentioned before, that's something I would put in as time as a barrier when it comes to building this thing. I just take it back to the many conversations I have with veterans as they've been going through their own personal journeys. That just keeps me going.

+ +

As far as what would it take for me to move away to work on Promenade full time, the only true thing I think it would take would really be line of sight and visibility on being able to drive this thing forward in a sustainable manner, just having a line of sight on that, on this thing. Okay, I've got the traction. I can see it. It's tangible. I just need to do A, B, and C to keep pushing this thing forward. I know that's sort of vague, but that's really what it would take.

+ +

CHAD: Do you think you're going to have to take funding from somewhere, or do you think you can continue to bootstrap and operate on the grants and awards?

+ +

JT: It depends. That's a good question. That's something I've gone back and forth with. Working in the tech startup space, that's something that's discussed a lot is angel investors and VCs, and you need to do this to attract funders and things like that. That's something that's discussed a lot in this space. But it's something that I've gone back and forth with. It really comes down to what I want this thing to be at the end of the day. This thing could be huge. There's a huge gap in the military veteran space in a multitude of ways.

+ +

This thing could be a unicorn if that's the direction I really wanted to take it. And I think if I go down that pathway, it's for sure going to take funding from outside sources. But if I want to keep this thing more small scale or maybe even local to that Atlanta, Georgia region where I live and only focus on that one region, that's something I could probably bootstrap until I've got the revenue necessary to work on it full time and just keep it at more of a local level.

+ +

But I think based on the impact that I'm trying to have throughout the entire veteran community and not just on veterans themselves but the organizations which could help...we've got this concept called train the trainer in the military, which is the experience I had as well. But essentially, it's I can do all the work and have all the impact. But it would be 10X more impactful if I'm working with Fortune 500 companies that are doing the same thing that I'm doing, impact in the veteran community in the same way that I am.

+ +

So I think that's the direction I'll probably end up going, and that's why I'll have to go look for funding from other sources to build this thing the way I want to build it. So we'll see. We'll see.

+ +

CHAD: The problem with funding, obviously, is that if it comes from traditional investment sources, then they expect a return, and you have to be able to show that. It might be made up, but you have to have a story that demonstrates that there's a return. And you alluded to one angle at the beginning when you talked about healthcare. Do you see that as a potential angle in terms of what the business model might be and what industry you might actually be part of?

+ +

JT: That's a great question. So I know that if I go full-fledged down the healthcare route, social determinants of health, tracking health outcomes for the veteran community, then most definitely, this would be something where I would need outside funding, traditional funding to build this thing. And I think that's where when it comes to like, okay, I set out on this journey to impact the veteran community, and I want to have the most impact possible. That's going to be the route I'm going to have to go down.

+ +

But quite candidly, I do not have at this point enough expertise around the healthcare space to say, okay, let's go down that pathway. Right now, part of the journey that I'm on outside of just trying to build this thing and get this thing launched over the next month, or two is how do I get myself more integrated into the healthcare world to better understand how what I'm building overlaps or integrates into what's going on around social determinants of health in the healthcare space? And how do I insert myself into that? That's something I'm currently assessing.

+ +

CHAD: Well, and the interesting thing, too, for me is the thought that I wonder if that actually is something that is top of mind for the users, the veterans, or whether they're just thinking I need a job, [chuckles] and they're not necessarily thinking about their health top of mind. I mean, what do you think?

+ +

JT: They're not today. Absolutely not. Today when they reach out to me, they're like...and it's funny because that just opens another can of worms. But it just opens up this whole nother aspect of what I'm doing. So when they come to me, they're like, "I need a job." They're like, "I'm about to lose my car. I need help with my car payment," or "I'm going to be homeless soon." That's how people reach out to me. But, Chad, that's not truly the issue.

+ +

As you can imagine, if you're at the point to where you're about to be homeless, there's all this other stuff going on within your life. That's truly the work that we do. It's like people come to me...I have people reach out to me literally every single day. "I need help with this. I need help with that." And I'm like, okay, I have a conversation with them. And then we realize there's like 9, 10, 11 other things going on. So to answer your question, they're not thinking about this healthcare issue.

+ +

And from a user standpoint, that's not even how I want to approach this, like telling them, "Oh, I'm going to be here to improve your health outcomes." I wouldn't have that conversation with them. My conversation with them would still be around these different pillars. But on the organizational side, that's where I would communicate to them and say, "I've got these group of individuals who are coming to me and saying, 'I need this assistance.'" And what we're doing at the end of the day is improving their health outcomes. And what that means is, healthcare payer, they're not touching your healthcare system, which means you're saving tons of money.

+ +

And that's the part that I'm currently unpacking to say, okay, not to the user that we're doing this work and healthcare but to these organizations. And there are examples of this already out there. So, how do I do that but stay true to the work that I'm doing with the military veteran? Because one of the things that I know that's not going to change for what I'm building is the focus on the user. There are 40,000 veteran service organizations alone. There's $250 billion that gets poured into the veteran community through the Department of Veteran Affairs.

+ +

So there's no shortage of organizations working on the veteran community, with the veteran community, and there's no shortage of money out there when it comes to helping bolster the veteran community or improve outcomes within the veteran community. The true challenge that I see or the true issue that I see is there's a lack of focus on the actual veteran themselves and what they're going through. There are no tools out there for them to tap into and go on this journey. That's what I'm laser-focused on is how do I create an amazing experience for the military veteran themselves, not the organizations that are out there doing some of this work, if that makes sense.

+ +

CHAD: It totally does. And I think it really makes sense for you. I think it's a problem that a lot of startups face is that there's this draw, maybe because of your business model or because of the environment that you have this other piece, but what you really need to do is focus on creating value for your users. And in an ideal world, those two things become aligned over time.

+ +

You mentioned...a little while ago, you said something over the next few months, we got to get this launched. So there's a sign-up on the website now to become part of the community. But are you not fully launched yet?

+ +

JT: No. So what we've got right now is a landing page which essentially is building a list for individuals. Once I launch, I reach out and say, "Hey, we're live." What's not publicly facing right now is that user experience that I described. That's what's being built. But let me take a step back because we're still doing that grassroots work to where we're working with veterans one on one. So that's still something that we're heavily doing. But again, the idea here is to how do I replicate this work that we're doing to millions of people? That's what we're going to roll out here.

+ +

CHAD: I know timelines can be tricky. [laughs] What is your working timeline for doing that?

+ +

JT: As far as launching it?

+ +

CHAD: Mm-hmm.

+ +

JT: [laughs] When people ask me, you know, one or two months. It's funny; when I first started this back when I was doing the customer discovery, I was getting all this great information and learning more intimately about what the veterans community is going through. I've got my own experience. I've got the experience of people within my ecosystem. But I was just astounded by all the myriad of issues that were going on.

+ +

And I was like, oh man, I'm going to have something built and ready to go in like three months. And this is like January 2020, February 2020. I was like, I'm going to have something by Veterans Day this year. It's going to be like everyone's going to know about it. Obviously, that didn't happen because the realities [laughs] of building a tech startup set in really quickly. But we're fairly close. I'm aiming for no later than two or three months, but I hate to put the actual time on it just yet.

+ +

CHAD: And I think as a founder, you need to give yourself...pressure is good. But you also need to give yourself permission to not ship until you're ready and proud of what you've done. Now the trick is most people wait too long. [laughs] So the trick is actually forcing yourself to launch something that you're probably not unhappy with but actually is sufficient.

+ +

JT: Yeah, that's right. That's right. I don't want to wait until it's, quote, unquote, "perfect." But I do want to ensure that the individuals that do come to the front door in the very beginning they're going to get a great experience. And if they don't, then there's that feedback loop that helps us get better because that's what it's about. Whether you're a young tech startup or you're Facebook or whoever, there needs to be that feedback loop built-in in the right way. So that's what we're doing.

+ +

We're trying to ensure that, okay, we've got the foundation of this thing built correctly. And then we've got these feedback loops at all the right points to make this thing even better going forward. And then separately, as every founder is going through, how do you continue to build this thing or fund this thing, rather, to keep it going forward? And that's through bootstrapping. That's through the revenue model that we've got going. And that's through some of these partnerships that we're trying to put wet ink on right now as well. So a lot of things going on.

+ +

CHAD: So if someone's listening to this and they're in a position where they say, "I care a lot about this. I want to help. I'm a founder or a leader at a company. And I want to work with Promenade." How do they get in touch with you? Where are the best places for them to do that?

+ +

JT: Yeah, they can reach out to me at jt@promenade.ai. That's the quickest and easiest way. We've got our Instagram page up and our LinkedIn page up. You can reach out on there. But the quickest way if you're like, I want to contribute, our organization we've been thinking about how do we work with the veteran community more closely? How do we recruit them? I've got veterans in my family that are going through some of the same challenges. I want to get them in touch with you. The quickest way is just email jt@promenade.ai.

+ +

CHAD: Awesome. And good luck in this final stretch towards launch. And I wish you all the best.

+ +

JT: I appreciate it.

+ +

CHAD: And maybe you can come back on the show a few months post-launch and debrief. [laughs]

+ +

JT: Yeah. I would love to. I would love to. I'm sure I'll have plenty of lessons learned. [laughs]

+ +

CHAD: Yeah, exactly. Again, that was promenade.ai for the website. And you can subscribe to this show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Thank you, JT, for stopping by. If other folks want to follow along with you, where can they do that?

+ +

JT: Instagram, we're at promenade.ai, and LinkedIn, you can find us the same way.

+ +

CHAD: Awesome. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: JT Liddell.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Rt9pBGm7 + + ]]> + + Chad Pytel + JT Liddell + + + 414: Sagewell Financial with Sam Zimmerman + https://podcast.thoughtbot.com/414 + 9f743d2b-1565-441b-800a-ebf418e0adfe + Thu, 10 Mar 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Sam Zimmerman is CEO and Co-founder of Sagewell Financial. Sagewell is building a banking platform for the needs of folks who are trying to retire and live off their savings and income as intelligently and as well as possible. + +Chad talks with Sam about deciding what their first product should be and what they would be bringing to market, finding the right partners, and minimizing risk to make a business and a product that works. + 39:22 + no + + + Sam Zimmerman is CEO and Co-founder of Sagewell Financial. Sagewell is building a banking platform for the needs of folks who are trying to retire and live off their savings and income as intelligently and as well as possible. +Chad talks with Sam about deciding what their first product should be and what they would be bringing to market, finding the right partners, and minimizing risk to make a business and a product that works. +Sagewell Financial (https://www.sagewellfinancial.com/) +Follow Sam on Twitter (https://twitter.com/Ferrum_of_omega) or LinkedIn (https://www.linkedin.com/in/sam-zimmerman-35152a22/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Sam Zimmerman, CEO and Co-founder of Sagewell Financial. Sam, thanks for joining me. +SAM: Thanks so much for having me, Chad. +CHAD: I've been following along with Sagewell Financial for a little while now, given our cross-histories and the fact that we worked with a few companies that you've worked at in the past. So I'm aware of what Sagewell Financial is, but I'm not sure that all of our audience is. So I think a good place to start would be by giving folks a little bit of an intro into what Sagewell Financial is, and then we'll touch on the founding story and go from there. +SAM: Awesome. So, in a sentence, Sagewell is building the digital banking that our parents deserve. To expand on that even more, America's retirees are a really interesting and important and powerful demo in American culture at large. There are 56 million Americans on a fixed income. And last year in venture capital, nearly $100 billion went to fund financial technology companies rewriting all of finance. And of that 100 billion or a little under, less than a fraction of a percent went to America's seniors. +And so we are trying to build banking from the ground up for the needs of folks who are living on a fixed income who are in their golden years and aren't thinking about that new job or making new money. We're building a bank for folks who are trying to retire and live off their savings and their income as intelligently and as well as possible. And that looks really different than the bank that a millennial or a Gen Z user might have. +CHAD: So that's really interesting. Right or wrong, what are the reasons that this historically hasn't been a target demographic for investment? +SAM: So the prevailing assumption among venture capitalists was (We're changing that and hopefully changing that quite quickly.) was that retirees aren't open to changing. Beyond that, they're also not technically sophisticated. These folks don't know how to use a phone or aren't open to a bank that might not have any physical branch. They are set in their ways. They're not going to move branch, or they're barely going to watch a new TV show. +A lot of folks who are trying to talk...imagining a grandma or a grandpa was really what the venture capitalists are drawing on often when they're thinking about why a senior wouldn't expect to have a bank with all the new features that the millennial might. +CHAD: Well, that one is certainly changing, especially as the venture capitalists get older themselves. They probably realize that that's an outdated notion in terms of the technical aptitude or familiarity of that audience, right? +SAM: Exactly. And it's a fascinating moment. There are 10,000 boomers who turn 65 each day in America, about 4 million folks each year. And those folks were about 40 whenever the.com boom passed. They've been using email. They have XE and PayPal. And importantly, why we're building this company now is that COVID changed seniors' digital lives more than anyone else. ARP reports how 70% of all American retirees know how to use Zoom and video conferencing software nowadays. +Across the stack of digital goods and services, seniors were actually the group that was most moved online. And so, from where we sit as entrepreneurs, we saw a massive market, an exogenous effect creating a disproportionate opportunity. And so we began designing and iterating on and understanding our user to build a product that met those needs with this massive and growing market. +CHAD: Banking is a highly regulated complex space. And I imagine from day one you're looking at that and saying, "Well, we might want to do everything eventually, but doing everything is going to be difficult." So what was the process you and your co-founder and the team around you used to decide what the first product should be and what you were going to bring to market? +SAM: Our founding team spent almost nine months in user interviews and user research across what one director of finance at Capital One called geriatric finance. We talked to hundreds of folks, and a lot of our assumptions about what the simplest or most low-trust or quickest to use service might be were actually totally turned on their head in a really interesting way. +Another reason why venture capitalists aren't so confident you can reach this demo is a couple of companies have come before us, and a lot of them followed, in financial technology, a Mint-like model where you log in, and you share your various bank credentials. They pull your credit card transactions and bank transactions. And one of the really surprising things in our hours of user interviews was that that model was really unpalatable to this demo. They actually thought it was a lot higher trust to share bank credentials than it was to actually open an account. +And so we began thinking, what's the highest engagement, most common accessible feature that our demo is familiar with? And that's already broadly online. And let's start there. And the original insight came with a woman she was from Pennsylvania, and we were talking. We built this kind of mint.com-type prototype to try to help imagine banking for her needs without this high trust checking account. And she was like, "Oh." She was aghast that we were even considering asking for her bank credentials. +We heard that, and then we said, "All right, no worries, no need to do this product demo." And then she was like, "But I really love Chime, and I really love Chime's checking account." And we were like, "Wait, you have a digital bank account?" And she's like, "Yeah, I love Chime." And it was this moment where thinking about our user, what trust meant to them, what was familiar to them, and what being online meant to them opened the floodgates and helped us really understand this user and what that first product needed to be. +And so our initial product is a checking account. It's got a variety of senior-specific features around and enabling it. And it's built incredibly excessively to be available to folks who use technology in all sorts of ways. But we started with the basics because that's what our members are most familiar to and most expect. +CHAD: So you say in the fine print on the website that Sagewell is a financial technology company and not a bank, and your banking services are provided by a partner. What was involved in actually bringing that online, finding the right partner, implementing the features? What did that look like? +SAM: Yeah, it is an incredible time to be building any sort of banking in America around the world. So to that point earlier, $100 billion was pumped into financial technology companies. And so as a result, there are so many companies and so much innovation happening in banking and fintech broadly. And so starting and figuring out what vendor to work with was actually what our strategy from a banking and regulatory perspective was. And in turn, what vendors and in-house technology we needed to build was one of the hardest initial challenges that I've ever had to face in building a company. +It is still, despite what many...you'll see a lot of ads, you know, "Have a card online in minutes." It is still in today's day and age quite an achievement to build banking and get it online, and servicing your customers in a scalable and sustainable way. And so we spent a lot of time early on in the architecture and vendor selection process and product strategy process thinking about what vendors to go with; what we were going to build in-house. And before ultimately breaking ground about three months after we began, we set the product itself, which was going to be a checking account for retirees. +CHAD: What were the factors that went into choosing the partner that you ultimately chose? +SAM: Beyond your standard enterprise vendor selection, we wanted to make sure that it was secure, and we wanted a specific set of features. In our space, there are about six different companies that provide what's called Banking as a Service technology. And so that was one of our key vendors is the technology company that works with the bank to allow us to open checking accounts, fund accounts. And most of those companies have been around for only a few years. And so their products themselves are hardening and being built. +And about $200 million I would say has been invested in those companies last year. And so we wanted one that was well-capitalized. We wanted one that had not had any IT security issues. We wanted the underlying bank to be aligned in our mission. Retirees have a variety of specific financial needs. A lot of our product development involves working very closely with the bank. And so, we needed to make sure that the bank itself that they worked with was on board. +And lastly, we talked to other customers, and that was ultimately the most valuable thing in our experience and not just the customers that they refer you to but the customers who have left for one reason or another. Those were the major factors that we chose in our Banking as a Service provider. And then, beyond that, that's one piece of the puzzle. In our bank tech stack, we're looking at around 15 different partners across all parts of banking. And that's the largest and most important one. And those were the criteria we used to select. +CHAD: I often say when I'm looking at building a product or service, and we look at those integration points with external vendors, it is one of the riskiest parts of building a product because you're not in control of it. So from a business perspective, it's risky. But also, from a technology perspective, that's where estimates can get out of whack. +And things can work not like you're expecting or like the documentation said or just surprises crop up along the way. Or when something goes down, your product is broken. And your entire product [laughs] basically is built on those vendor relationships. So, how do you minimize that risk and work in that environment to make a business that works and a product that works? +SAM: [chuckles] I suppose the answer is with a lot of prudence, thoughtfulness, and care at a high level. +CHAD: [laughs] +SAM: I was actually just talking with a CTO friend of mine just talking about how in a lot of startups, one of the skills that I most ask of engineers and engineering leaders early on is vendor selection and how I hadn't seen an interview process that really helped get at that. It's a core part of a lot of technologists' jobs and particularly a lot of engineering folks' jobs. The API docs looked good but did he test it or evaluate it? Was there a third-party tool you could have used instead of building in-house? +Those are the sort of questions that a lot of times early-stage startups are answering all the time. And I had yet to see an interview that got at that. So it's a really shrewd point and one that I hope that as technologists and particularly early-stage startups become more about really going deep in one area and then leveraging third parties elsewhere, I hope that we start actually hiring and developing criteria to do that with the people that we assemble. +I think the first part what I would say is we described a little bit about the risks. We went through a risk mitigation exercise, which smells very enterprise-y. It's kind of the sort of thing that you would expect exists in some massive waterfall with a Jira board mainframe computer but just listing like, here's this integration. If this were to happen, what would we do? If the API went down, what control do we have, or how could we minimize the impact on our customers? +That exercise across some of our biggest integrations helped us select and take on the risks we wanted and avoid the ones we couldn't. So there was a lot of conversation about the sorts of failures we could put up with and how we could put up with them, and the sorts of failures we couldn't. And then really testing for the ones we couldn't to make sure that we were making as good a choice as possible. +Despite that thoughtful answer, it was the best we could do. I would say that, particularly in a space that's as fast-moving as Banking as a Service, I would say that a lot of it is still that soft skill, that relational conversations with other teams and folks and whether you trust the team that you're trusting to execute and build what they said they're going to build and that hiring skill but also a good bit of luck as well. +CHAD: So correct me if I'm wrong, but up until Sagewell, where you're CEO, you had been CTO of the other companies that you founded and worked at. Is that right? +SAM: Yeah, that's correct. +CHAD: So, what has the change to being CEO instead of CTO been like for you personally? And was that choice clear from the beginning with Sagewell? +SAM: So far, it's been incredibly rewarding. I would say in between startups; I actually volunteered at an organization called PathCheck. And while my title was CTO, the scope of that included partnerships, vendor negotiations, CISO exercises, product. It was a pretty expansive CTO role. And I found myself really energized by the breadth and the ability to work with even more really talented, thoughtful experts in their own domain and empower them to do more. And so I knew in my next role, I wanted more of that breadth. +There's an essay that classifies folks as foxes who can do a little bit of everything or hedgehogs who can do one thing really well. And I'm a super fox. [laughter] I love doing lots of things. And so CEO to me is just like an opportunity to...it's maximizing breadth and maximizing difference of experience. And I transitioned, I'd say, from a normal CTO role to a beefy CTO role to making CEO a pretty natural step from there. +CHAD: And your co-founder is named Jeff Wright, and he's the COO. How did you meet him and get started with Sagewell? +SAM: Jeff and I, it's been wonderful. I was trying to figure out how I was going to get engaged in pandemic work in April of 2020 after leaving my last startup while it was being sold to Capital One. And I was talking with a founder friend of mine, a guy named Ty Harris, who is the CEO of an Insurtech company called Openly. And he was previously the CTO at Liberty Mutual. And Ty and I had a couple of lunches and conversations, and I was talking to him about how it is getting involved in COVID stuff and how I was ultimately my species as an entrepreneur, and I was going to be building something again. +And he connected me with Jeff, and Jeff and I touched base quickly in April. And it was a little bit like a frog in the pot sort of situation where it started like, yeah, maybe we could build a company. Let's riff on some ideas and see what's out there. And it was a really, really natural progression from August to a couple of evenings, maybe a Saturday call or two, to most evenings and definitely a Saturday to oh, man, when should we transition? +CHAD: You were both working full time on other things at the time. You were working with PathCheck. +SAM: Yep, exactly. And so he was the CPO at a company called Plymouth Rock, and I was working at PathCheck. And not to go into PathCheck's story too much, but PathCheck was largely deploying a research technology, the Google and Apple Exposure Notification protocol. And it became clear that most of the states that were going to do anything were already going to do it. And so, it was natural to start thinking about what was next in August and September. And so, as my species does, that then became the night and weekend project to figure out what's next. +CHAD: So you mentioned that this is a space that is typically not strongly funded. So was that a challenge for you as you were getting started? How did you get that initial, you know, where did your initial funding come from? And I know you recently raised, at least it was announced, 5.3 million in January. So what was the transition from those early days? Where did the funding come from to ultimately getting the investment in this last round? +SAM: Jeff and I worked in the fall of 2020, met our CTO, Chris Toomey, in November actually from connection through a friend. Early on, we were a team with a demo. We really knew that we cared about seniors, and our background is in financial services. We were trying to think of a new product for seniors and so a financial product for seniors. And so, around January, we sharpened our pencils on the user research side of things and the product side of things. And once we had a clearer sense of the product direction we wanted to take, ultimately building banking for retirees, we began the fundraising process. +CHAD: So were you essentially self-funding at that point? +SAM: Yep. So we were self-funding from January-ish till May. I find that skin in the game to be… I wish I was the sort of founder who could think about flawless ideas without a little pressure. But in my experience, it's actually been where unless I jump in, unless I can have a little bit of pressure, my ideas aren't often as refined as I'd like. And so Jeff joined it full-time in February. And then we fundraised through April, closing a 1 million pre-seed, which is pretty common in fintech. +Most financial technology companies the banks won't talk to you until you have at least a million dollars in funding. And so we raised the money we needed from...and who did the money come from? It came from Point Judith Capital, who actually had invested in Ty, the guy who connected us, with his company Openly. So we had our initial conversation with David, who's been absolutely wonderful at Point Judith Capital. +And also, Jeff and I knew that innovating for a vulnerable population, ultimately retirees, meant that we wanted to have folks from the beginning who represented the seniority and seriousness with which we are taking our work. And so the second investor who in between the two of them took most of that million was Crossbeam and Raj Date at Crossbeam, who's the former Deputy Director of the U.S. Consumer Protection Bureau. We really wanted folks around the table who knew what innovation looked like and fintech innovation like David, as well as folks who understood the world of government and finance like someone like Raj to innovate thoughtfully with this demo. +CHAD: Was it difficult to get those funding rounds? +SAM: The first one? Yeah, the first one was about two months. I thought it would have taken about a month. The second one the market is pretty crazy right now. And I would say between my first company and my second, it used to be that you'd set aside six months to fundraise, and so I'd prepared for a six-month fundraise. Started kind of in early October two weeks in, and they were like, "Wow, you've already been in the market for two weeks?" [laughter] +And I was like, what? I was totally off base in terms of what was the new normal. Ultimately, that round came together in about a month and a half as well. And so we had a lot of interest. The second round that 5.3 million went from not a ton of interest to tons of interest and lots of folks around the table and having to push folks out or turn folks down pretty quickly. The first round, I would say for a pre-seed, one to two months given that the idea was hardening, sounds about right. +The second one was about one to two months but was a little...a lot of people would get excited by the market; they'd get excited by the team. And then they'd say, "You can't get a senior to open up a bank account," and then they'd come back. And then we found one believer alongside David and Raj, who had been with us. And once we got the folks at 25Madison and Merrill, especially, the rest of the round came together really quickly. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: Given that you were able to put together a round quickly, how do you decide ultimately not to take even more money? What are the factors that go into deciding how much you're trying to fundraise and how big the round is going to be? And is there pressure as you're doing that to maybe go even bigger? +SAM: Yeah, we had, I would say maybe seven and a half million dollars interested. And ever since we've closed, we've had multiple firms who are interested in a new round of capital. The market is really, really quite founder-friendly right now. I think ultimately, for any founder, what you're trying to do is create as much value with as little capital as possible. That's ultimately the game that you're trying to play now. +For a little baby company, it's often really hard to figure out how much money or how much value you'll be able to create over what amount of time. There's so much to figure out. There are so many bets and learnings and risks that it's often very hard for a company to say, with $5 million, I'll create $20 million in value. So ultimately, if you're a founder, you're incented to give away as little of the company as possible and create as much value from that. +And so when we were doing our modeling, we actually thought that it was somewhere closer to four of what we needed to create the amount of value needed to raise our A. And we ultimately bumped it up to 5.3. And there's a good bit of advice you hear a lot among founders that raising a bit more than you think is prudent, and anyone who has managed a budget knows how that can go. So we ultimately did go up to 5.3. +But taking more would have meant that we were paying a premium where we could get that million dollars maybe in a year's time, and we'd be giving away a quarter-point or a half a point of the company for that million where we might be giving away 1% or 1.5% of the company now. So it's all about creating as much value with as little money as possible. And it's easy to get lost in the big rounds and the big numbers. But ultimately, it's pretty simple math. +CHAD: And correct me if I'm wrong, and this is a question as much as a statement. So to reiterate, the rounds you're talking about are seed rounds. And so traditionally, what that means is that the majority of work that you have to do is just making the product. But in the space you're in, there is a point in time where you've made the product, and you've shown the traction, so what you have becomes more valuable. +And so it might be that the next round, which is maybe a Series A, a significant portion of that capital would be spent on something else like marketing or sales teams and that kind of thing. And you're growing beyond just the product development at that point. Is that how you're thinking about this, or am I wrong? +SAM: So it's funny that it's really changed the names. The round size what they mean has changed more in the last two years than ever before, and I would say that, particularly in fintech, because fintech has a number of unique challenges. So I would say that that $1 million round that we raised in May that was really about building a very basic product, a very truly minimally viable acceptable product. +And then the seed round in fintechs is often about getting to product-market fit or just demonstrating you can reach your end consumer or target user. In fintech, it's often not quite as much tied to a certain amount of revenue at that stage. It's often about just demonstrating that you can get to that user, and that's because, in financial technology, the cost to acquire is often quite high. +And so for a company that only has raised, say, a $5 million pre-seed because of the gravity, because it often costs hundreds sometimes thousands of dollars depending upon the market to acquire a specific user, the math is such that you're just not going to have that many users, and you're not going to be able to get to a certain amount revenue. And so often in fintechs, 1 million gets you...that pre-seed gets you that initial product. The seed is about demonstrating that you can scalably get to that end user. +And then the series A is really about blowing that out and starting to exploit that marketing and acquisition machine that you've been building to start creating revenue. That's a little bit industry-specific. Other industries will have similar or different terms. And depending upon what sort of branding a firm might want for the round, you also might hear $100 million pre-seed. You hear those things as well. It's a crazy time to be building a company. +CHAD: So you mentioned Chris Toomey, who's the CTO of Sagewell, and he was previously at thoughtbot. As a prior CTO, what were some of the things you looked at in terms of finding Chris and deciding he was the right one to join your team as CTO? I imagine your standards were pretty high. +SAM: Yeah, and Chris met them quite happily. As a CTO transitioning to CEO, I think you have to understand your strengths and weaknesses as a CTO as well as the learning curve that you might have stepping into your new role as a CEO. And I would say that one of the fortunate things is that Jeff, my co-founder and COO, we actually have a pretty unique set of skills that can span a lot of different domains. +And so I would say that looking at Jeff, Chris, and myself, we really had to make sure we had our bases covered to build the financial and technology product we needed. I would encourage folks building a company early on to really think about your strengths and weaknesses, your founding team's strengths and weaknesses. +And as I was getting to know Chris, kind of the initial handshake agreement starting to build and prototype various solutions, I think that I was particularly impressed and looking for someone who was willing to have a deeply experimental and MVP mindset while managing the risks of working with a vulnerable population. And so over the course of December through March or April, in dealing with and spinning up a couple of different prototypes with radically different product strategies and end products, I was able to see how Chris was able to be mature and shrewd about where he could cut corners, where he couldn't cut corners and then execute accordingly. +It's funny, Chris and I were talking at our one on one a week or two ago. As a CTO, I know a little more of what's possible. I know if I come in and say, "I want the Taj Mahal," I know you'll get walked back down. Chris and I over the past year...I often come to Chris, having already teared down my Taj Mahal. And I'm like, "Well, Chris, what I really need is one little specific problem." And Chris and I actually set a goal between us that I actually kind of come to him asking for the Taj Mahal next time [laughter] or not next time but sometime in the next year. +Because I think one of the things I've had to check or do in CEO is let Chris do CTO's job and not internalize all the time his voice and concerns but actually put forth a vision and not be afraid about the fact that it isn't something that we can get to market in a week or that we can't ship in three or four weeks’ time, which is an interesting contract that I think we've developed and an interesting growth area. And it's my job to throw out bigger ideas, not to be the one who tears them down all the time, which is fun, and I enjoy doing that with Chris. +CHAD: Yeah, that's an interesting perspective. And I often even working with clients and consulting want that because if you're only getting the small pieces all the time, you cannot be privy to the big picture of what we're aiming for. And that will often lead you to maybe not taking everything into account, either that's on the roadmap or down the road. Or realizing, oh, you're disappointed now, but that's because I didn't know that you wanted to do this. If I had known, then we could have done this in a different way or something like that. And so, getting a sense of that big picture is often important. +SAM: Yeah. And it's a fun, I'd say...yeah, and growing with Chris and figuring out that he's the right person for the role as a CTO turned CEO means kicking off the ladder and actually just stepping into my role and letting him do his, which has been a fun contract to establish. +CHAD: So, did you work with Chris as a contractor before committing to him as CTO? +SAM: Yeah, we were in a consulting relationship. I think Chris was politely under billing. And the pretext is always that this was something that we were really aiming to build a company together, assuming everything worked out across Chris, Jeff, and I. And so, he did start in that capacity. And then I'm trying to remember the exact timelines. Sometimes the paperwork is well after the actual agreement whenever you're creating these companies. But in a few months’ time, definitely by July and probably by May, we were building the company and off to the races. +CHAD: Now, is that a path that you would recommend to other founding teams looking for a CTO is to not commit early to really make sure that you work well with someone, maybe through a contracting relationship first? +SAM: Yeah, I think ultimately, if you're going to be going on a journey, a decade long journey, a lifetime-long journey, through highs and lows, I think the best way for everyone to know what they're getting themselves into, the excitement, and the reward, and the aches, and the pains and the sleepy [inaudible 33:31] in the morning is by working together, and I don't think there's a shortcut. In this case, it depends a lot on the situation. It depends if folks are in a position where they cannot take pay. It depends on whether nights and weekends are free or they have flexibility in their other roles. +But generally speaking, I think that ultimately, you're trusting, and your founding team is going to be taking so many risks together that you want to go in as eyes wide open as possible and have removed as much founding team risk, disagreements, misaligned working styles, misaligned visions, or preferences as possible. My coach used to say that that's the number one reason why companies at the seed stage fail is management teams and founding teams. +And so as you're thinking about building your company, and I can't emphasize this enough, mitigating and removing founding team risk, however possible, with consulting being one of them and navigating a tough conversation or two being another, is absolutely core to removing as much risk as possible for your startup. +CHAD: That's great advice. And just like you and Jeff had a time of working together before you actually started a company together, I think it's great advice to try to find ways to do that with other early members of the team too because it's a big commitment, and you want to make sure that you get it right. +SAM: Exactly. +CHAD: Well, you've reached sort of the pinnacle of having now someone on your team that used to work at thoughtbot. I think I'd be remiss if I didn't point out that we have another podcast at thoughtbot; it's called The Bike Shed. And Chris started as a host on that show while he was on thoughtbot, and he continues that to this day along with Steph Viccari, who's a team lead at thoughtbot. +And so if people are interested in hearing about Chris' work now at Sagewell and following along with the team and the work that he's doing there as well as the work we do at thoughtbot, people can check that out at bikeshed.fm. Sagewell is not a client of thoughtbot. But you've worked with thoughtbot before as a client twice, right? +SAM: Yeah, exactly, both at my first company Freebird, which was sold to Capital One, and at PathCheck, the non-profit I worked at. +CHAD: So you specifically, I assume, then made an effort to recruit from thoughtbot when you started Sagewell. [laughs] +SAM: I would say I know and love the way that thoughtbot approaches building software. And I know and love the people that I've worked with from thoughtbot. And I would say that it was as much a feature of being in the same communities as it was specifying a specific group. But you guys have created a great culture. [laughs] +CHAD: I'm just kidding. I didn't actually think that that was the case, but I can guess a lot of the benefits of working with someone who's worked at thoughtbot before because of the level of experience and the level of skill and communication and everything that people at thoughtbot have. But I'm curious, what if I turn that around? Is there a downside to hiring someone who worked at thoughtbot previously to your team? +SAM: So one of the things that I love about, particularly early on, we have a hire that we just made recently. She worked at a senior living facility for four or five years and then worked at Wells Fargo for four or five years. And before, we had a bunch of fears, and this new employee listed five or six totally different fears than we ever would have thought of. And so now we have way more fears. And part of that can be unnerving, and part of that can be challenging. +And I would say that one of the challenges of working with a team that builds software in such a clear culture is that you might not get all the fears. You might not get certain sorts of diverse perspectives or headaches because of a particular way that product and engineering are conceived. And so one risk...it’s kind of the unknown-unknown sort of situation, but it's real in startups which is I think that making sure you have diverse perspectives across the domains where you need to be deeply an expert for folks who are very similar to you is a major risk. +CHAD: That's great. Well, Sam, thanks for stopping by and sharing with us. I really wish you and Sagewell and the entire team all the best. +SAM: Awesome. It was wonderful talking. +CHAD: And if folks want to find out more about Sagewell Financial or follow along with you or get in touch with you, where are all the best places for them to do that? +SAM: sagewellfinancial.com is our email. And if you or your parents are interested in what we're building as a customer or a member, you can sign up there. If you'd like to reach me, I'm mostly on Twitter following cute animals and occasionally a good tech post @Ferrumofomega. And if you'd like to contact our company, you can just go to /press and fill out the form there. +CHAD: Awesome. And you can subscribe to the show and find notes for this episode along with a transcript of this episode and all past episodes of this season at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Sam Zimmerman is CEO and Co-founder of Sagewell Financial. Sagewell is building a banking platform for the needs of folks who are trying to retire and live off their savings and income as intelligently and as well as possible.

+ +

Chad talks with Sam about deciding what their first product should be and what they would be bringing to market, finding the right partners, and minimizing risk to make a business and a product that works.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Sam Zimmerman, CEO and Co-founder of Sagewell Financial. Sam, thanks for joining me.

+ +

SAM: Thanks so much for having me, Chad.

+ +

CHAD: I've been following along with Sagewell Financial for a little while now, given our cross-histories and the fact that we worked with a few companies that you've worked at in the past. So I'm aware of what Sagewell Financial is, but I'm not sure that all of our audience is. So I think a good place to start would be by giving folks a little bit of an intro into what Sagewell Financial is, and then we'll touch on the founding story and go from there.

+ +

SAM: Awesome. So, in a sentence, Sagewell is building the digital banking that our parents deserve. To expand on that even more, America's retirees are a really interesting and important and powerful demo in American culture at large. There are 56 million Americans on a fixed income. And last year in venture capital, nearly $100 billion went to fund financial technology companies rewriting all of finance. And of that 100 billion or a little under, less than a fraction of a percent went to America's seniors.

+ +

And so we are trying to build banking from the ground up for the needs of folks who are living on a fixed income who are in their golden years and aren't thinking about that new job or making new money. We're building a bank for folks who are trying to retire and live off their savings and their income as intelligently and as well as possible. And that looks really different than the bank that a millennial or a Gen Z user might have.

+ +

CHAD: So that's really interesting. Right or wrong, what are the reasons that this historically hasn't been a target demographic for investment?

+ +

SAM: So the prevailing assumption among venture capitalists was (We're changing that and hopefully changing that quite quickly.) was that retirees aren't open to changing. Beyond that, they're also not technically sophisticated. These folks don't know how to use a phone or aren't open to a bank that might not have any physical branch. They are set in their ways. They're not going to move branch, or they're barely going to watch a new TV show.

+ +

A lot of folks who are trying to talk...imagining a grandma or a grandpa was really what the venture capitalists are drawing on often when they're thinking about why a senior wouldn't expect to have a bank with all the new features that the millennial might.

+ +

CHAD: Well, that one is certainly changing, especially as the venture capitalists get older themselves. They probably realize that that's an outdated notion in terms of the technical aptitude or familiarity of that audience, right?

+ +

SAM: Exactly. And it's a fascinating moment. There are 10,000 boomers who turn 65 each day in America, about 4 million folks each year. And those folks were about 40 whenever the.com boom passed. They've been using email. They have XE and PayPal. And importantly, why we're building this company now is that COVID changed seniors' digital lives more than anyone else. ARP reports how 70% of all American retirees know how to use Zoom and video conferencing software nowadays.

+ +

Across the stack of digital goods and services, seniors were actually the group that was most moved online. And so, from where we sit as entrepreneurs, we saw a massive market, an exogenous effect creating a disproportionate opportunity. And so we began designing and iterating on and understanding our user to build a product that met those needs with this massive and growing market.

+ +

CHAD: Banking is a highly regulated complex space. And I imagine from day one you're looking at that and saying, "Well, we might want to do everything eventually, but doing everything is going to be difficult." So what was the process you and your co-founder and the team around you used to decide what the first product should be and what you were going to bring to market?

+ +

SAM: Our founding team spent almost nine months in user interviews and user research across what one director of finance at Capital One called geriatric finance. We talked to hundreds of folks, and a lot of our assumptions about what the simplest or most low-trust or quickest to use service might be were actually totally turned on their head in a really interesting way.

+ +

Another reason why venture capitalists aren't so confident you can reach this demo is a couple of companies have come before us, and a lot of them followed, in financial technology, a Mint-like model where you log in, and you share your various bank credentials. They pull your credit card transactions and bank transactions. And one of the really surprising things in our hours of user interviews was that that model was really unpalatable to this demo. They actually thought it was a lot higher trust to share bank credentials than it was to actually open an account.

+ +

And so we began thinking, what's the highest engagement, most common accessible feature that our demo is familiar with? And that's already broadly online. And let's start there. And the original insight came with a woman she was from Pennsylvania, and we were talking. We built this kind of mint.com-type prototype to try to help imagine banking for her needs without this high trust checking account. And she was like, "Oh." She was aghast that we were even considering asking for her bank credentials.

+ +

We heard that, and then we said, "All right, no worries, no need to do this product demo." And then she was like, "But I really love Chime, and I really love Chime's checking account." And we were like, "Wait, you have a digital bank account?" And she's like, "Yeah, I love Chime." And it was this moment where thinking about our user, what trust meant to them, what was familiar to them, and what being online meant to them opened the floodgates and helped us really understand this user and what that first product needed to be.

+ +

And so our initial product is a checking account. It's got a variety of senior-specific features around and enabling it. And it's built incredibly excessively to be available to folks who use technology in all sorts of ways. But we started with the basics because that's what our members are most familiar to and most expect.

+ +

CHAD: So you say in the fine print on the website that Sagewell is a financial technology company and not a bank, and your banking services are provided by a partner. What was involved in actually bringing that online, finding the right partner, implementing the features? What did that look like?

+ +

SAM: Yeah, it is an incredible time to be building any sort of banking in America around the world. So to that point earlier, $100 billion was pumped into financial technology companies. And so as a result, there are so many companies and so much innovation happening in banking and fintech broadly. And so starting and figuring out what vendor to work with was actually what our strategy from a banking and regulatory perspective was. And in turn, what vendors and in-house technology we needed to build was one of the hardest initial challenges that I've ever had to face in building a company.

+ +

It is still, despite what many...you'll see a lot of ads, you know, "Have a card online in minutes." It is still in today's day and age quite an achievement to build banking and get it online, and servicing your customers in a scalable and sustainable way. And so we spent a lot of time early on in the architecture and vendor selection process and product strategy process thinking about what vendors to go with; what we were going to build in-house. And before ultimately breaking ground about three months after we began, we set the product itself, which was going to be a checking account for retirees.

+ +

CHAD: What were the factors that went into choosing the partner that you ultimately chose?

+ +

SAM: Beyond your standard enterprise vendor selection, we wanted to make sure that it was secure, and we wanted a specific set of features. In our space, there are about six different companies that provide what's called Banking as a Service technology. And so that was one of our key vendors is the technology company that works with the bank to allow us to open checking accounts, fund accounts. And most of those companies have been around for only a few years. And so their products themselves are hardening and being built.

+ +

And about $200 million I would say has been invested in those companies last year. And so we wanted one that was well-capitalized. We wanted one that had not had any IT security issues. We wanted the underlying bank to be aligned in our mission. Retirees have a variety of specific financial needs. A lot of our product development involves working very closely with the bank. And so, we needed to make sure that the bank itself that they worked with was on board.

+ +

And lastly, we talked to other customers, and that was ultimately the most valuable thing in our experience and not just the customers that they refer you to but the customers who have left for one reason or another. Those were the major factors that we chose in our Banking as a Service provider. And then, beyond that, that's one piece of the puzzle. In our bank tech stack, we're looking at around 15 different partners across all parts of banking. And that's the largest and most important one. And those were the criteria we used to select.

+ +

CHAD: I often say when I'm looking at building a product or service, and we look at those integration points with external vendors, it is one of the riskiest parts of building a product because you're not in control of it. So from a business perspective, it's risky. But also, from a technology perspective, that's where estimates can get out of whack.

+ +

And things can work not like you're expecting or like the documentation said or just surprises crop up along the way. Or when something goes down, your product is broken. And your entire product [laughs] basically is built on those vendor relationships. So, how do you minimize that risk and work in that environment to make a business that works and a product that works?

+ +

SAM: [chuckles] I suppose the answer is with a lot of prudence, thoughtfulness, and care at a high level.

+ +

CHAD: [laughs]

+ +

SAM: I was actually just talking with a CTO friend of mine just talking about how in a lot of startups, one of the skills that I most ask of engineers and engineering leaders early on is vendor selection and how I hadn't seen an interview process that really helped get at that. It's a core part of a lot of technologists' jobs and particularly a lot of engineering folks' jobs. The API docs looked good but did he test it or evaluate it? Was there a third-party tool you could have used instead of building in-house?

+ +

Those are the sort of questions that a lot of times early-stage startups are answering all the time. And I had yet to see an interview that got at that. So it's a really shrewd point and one that I hope that as technologists and particularly early-stage startups become more about really going deep in one area and then leveraging third parties elsewhere, I hope that we start actually hiring and developing criteria to do that with the people that we assemble.

+ +

I think the first part what I would say is we described a little bit about the risks. We went through a risk mitigation exercise, which smells very enterprise-y. It's kind of the sort of thing that you would expect exists in some massive waterfall with a Jira board mainframe computer but just listing like, here's this integration. If this were to happen, what would we do? If the API went down, what control do we have, or how could we minimize the impact on our customers?

+ +

That exercise across some of our biggest integrations helped us select and take on the risks we wanted and avoid the ones we couldn't. So there was a lot of conversation about the sorts of failures we could put up with and how we could put up with them, and the sorts of failures we couldn't. And then really testing for the ones we couldn't to make sure that we were making as good a choice as possible.

+ +

Despite that thoughtful answer, it was the best we could do. I would say that, particularly in a space that's as fast-moving as Banking as a Service, I would say that a lot of it is still that soft skill, that relational conversations with other teams and folks and whether you trust the team that you're trusting to execute and build what they said they're going to build and that hiring skill but also a good bit of luck as well.

+ +

CHAD: So correct me if I'm wrong, but up until Sagewell, where you're CEO, you had been CTO of the other companies that you founded and worked at. Is that right?

+ +

SAM: Yeah, that's correct.

+ +

CHAD: So, what has the change to being CEO instead of CTO been like for you personally? And was that choice clear from the beginning with Sagewell?

+ +

SAM: So far, it's been incredibly rewarding. I would say in between startups; I actually volunteered at an organization called PathCheck. And while my title was CTO, the scope of that included partnerships, vendor negotiations, CISO exercises, product. It was a pretty expansive CTO role. And I found myself really energized by the breadth and the ability to work with even more really talented, thoughtful experts in their own domain and empower them to do more. And so I knew in my next role, I wanted more of that breadth.

+ +

There's an essay that classifies folks as foxes who can do a little bit of everything or hedgehogs who can do one thing really well. And I'm a super fox. [laughter] I love doing lots of things. And so CEO to me is just like an opportunity to...it's maximizing breadth and maximizing difference of experience. And I transitioned, I'd say, from a normal CTO role to a beefy CTO role to making CEO a pretty natural step from there.

+ +

CHAD: And your co-founder is named Jeff Wright, and he's the COO. How did you meet him and get started with Sagewell?

+ +

SAM: Jeff and I, it's been wonderful. I was trying to figure out how I was going to get engaged in pandemic work in April of 2020 after leaving my last startup while it was being sold to Capital One. And I was talking with a founder friend of mine, a guy named Ty Harris, who is the CEO of an Insurtech company called Openly. And he was previously the CTO at Liberty Mutual. And Ty and I had a couple of lunches and conversations, and I was talking to him about how it is getting involved in COVID stuff and how I was ultimately my species as an entrepreneur, and I was going to be building something again.

+ +

And he connected me with Jeff, and Jeff and I touched base quickly in April. And it was a little bit like a frog in the pot sort of situation where it started like, yeah, maybe we could build a company. Let's riff on some ideas and see what's out there. And it was a really, really natural progression from August to a couple of evenings, maybe a Saturday call or two, to most evenings and definitely a Saturday to oh, man, when should we transition?

+ +

CHAD: You were both working full time on other things at the time. You were working with PathCheck.

+ +

SAM: Yep, exactly. And so he was the CPO at a company called Plymouth Rock, and I was working at PathCheck. And not to go into PathCheck's story too much, but PathCheck was largely deploying a research technology, the Google and Apple Exposure Notification protocol. And it became clear that most of the states that were going to do anything were already going to do it. And so, it was natural to start thinking about what was next in August and September. And so, as my species does, that then became the night and weekend project to figure out what's next.

+ +

CHAD: So you mentioned that this is a space that is typically not strongly funded. So was that a challenge for you as you were getting started? How did you get that initial, you know, where did your initial funding come from? And I know you recently raised, at least it was announced, 5.3 million in January. So what was the transition from those early days? Where did the funding come from to ultimately getting the investment in this last round?

+ +

SAM: Jeff and I worked in the fall of 2020, met our CTO, Chris Toomey, in November actually from connection through a friend. Early on, we were a team with a demo. We really knew that we cared about seniors, and our background is in financial services. We were trying to think of a new product for seniors and so a financial product for seniors. And so, around January, we sharpened our pencils on the user research side of things and the product side of things. And once we had a clearer sense of the product direction we wanted to take, ultimately building banking for retirees, we began the fundraising process.

+ +

CHAD: So were you essentially self-funding at that point?

+ +

SAM: Yep. So we were self-funding from January-ish till May. I find that skin in the game to be… I wish I was the sort of founder who could think about flawless ideas without a little pressure. But in my experience, it's actually been where unless I jump in, unless I can have a little bit of pressure, my ideas aren't often as refined as I'd like. And so Jeff joined it full-time in February. And then we fundraised through April, closing a 1 million pre-seed, which is pretty common in fintech.

+ +

Most financial technology companies the banks won't talk to you until you have at least a million dollars in funding. And so we raised the money we needed from...and who did the money come from? It came from Point Judith Capital, who actually had invested in Ty, the guy who connected us, with his company Openly. So we had our initial conversation with David, who's been absolutely wonderful at Point Judith Capital.

+ +

And also, Jeff and I knew that innovating for a vulnerable population, ultimately retirees, meant that we wanted to have folks from the beginning who represented the seniority and seriousness with which we are taking our work. And so the second investor who in between the two of them took most of that million was Crossbeam and Raj Date at Crossbeam, who's the former Deputy Director of the U.S. Consumer Protection Bureau. We really wanted folks around the table who knew what innovation looked like and fintech innovation like David, as well as folks who understood the world of government and finance like someone like Raj to innovate thoughtfully with this demo.

+ +

CHAD: Was it difficult to get those funding rounds?

+ +

SAM: The first one? Yeah, the first one was about two months. I thought it would have taken about a month. The second one the market is pretty crazy right now. And I would say between my first company and my second, it used to be that you'd set aside six months to fundraise, and so I'd prepared for a six-month fundraise. Started kind of in early October two weeks in, and they were like, "Wow, you've already been in the market for two weeks?" [laughter]

+ +

And I was like, what? I was totally off base in terms of what was the new normal. Ultimately, that round came together in about a month and a half as well. And so we had a lot of interest. The second round that 5.3 million went from not a ton of interest to tons of interest and lots of folks around the table and having to push folks out or turn folks down pretty quickly. The first round, I would say for a pre-seed, one to two months given that the idea was hardening, sounds about right.

+ +

The second one was about one to two months but was a little...a lot of people would get excited by the market; they'd get excited by the team. And then they'd say, "You can't get a senior to open up a bank account," and then they'd come back. And then we found one believer alongside David and Raj, who had been with us. And once we got the folks at 25Madison and Merrill, especially, the rest of the round came together really quickly.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Given that you were able to put together a round quickly, how do you decide ultimately not to take even more money? What are the factors that go into deciding how much you're trying to fundraise and how big the round is going to be? And is there pressure as you're doing that to maybe go even bigger?

+ +

SAM: Yeah, we had, I would say maybe seven and a half million dollars interested. And ever since we've closed, we've had multiple firms who are interested in a new round of capital. The market is really, really quite founder-friendly right now. I think ultimately, for any founder, what you're trying to do is create as much value with as little capital as possible. That's ultimately the game that you're trying to play now.

+ +

For a little baby company, it's often really hard to figure out how much money or how much value you'll be able to create over what amount of time. There's so much to figure out. There are so many bets and learnings and risks that it's often very hard for a company to say, with $5 million, I'll create $20 million in value. So ultimately, if you're a founder, you're incented to give away as little of the company as possible and create as much value from that.

+ +

And so when we were doing our modeling, we actually thought that it was somewhere closer to four of what we needed to create the amount of value needed to raise our A. And we ultimately bumped it up to 5.3. And there's a good bit of advice you hear a lot among founders that raising a bit more than you think is prudent, and anyone who has managed a budget knows how that can go. So we ultimately did go up to 5.3.

+ +

But taking more would have meant that we were paying a premium where we could get that million dollars maybe in a year's time, and we'd be giving away a quarter-point or a half a point of the company for that million where we might be giving away 1% or 1.5% of the company now. So it's all about creating as much value with as little money as possible. And it's easy to get lost in the big rounds and the big numbers. But ultimately, it's pretty simple math.

+ +

CHAD: And correct me if I'm wrong, and this is a question as much as a statement. So to reiterate, the rounds you're talking about are seed rounds. And so traditionally, what that means is that the majority of work that you have to do is just making the product. But in the space you're in, there is a point in time where you've made the product, and you've shown the traction, so what you have becomes more valuable.

+ +

And so it might be that the next round, which is maybe a Series A, a significant portion of that capital would be spent on something else like marketing or sales teams and that kind of thing. And you're growing beyond just the product development at that point. Is that how you're thinking about this, or am I wrong?

+ +

SAM: So it's funny that it's really changed the names. The round size what they mean has changed more in the last two years than ever before, and I would say that, particularly in fintech, because fintech has a number of unique challenges. So I would say that that $1 million round that we raised in May that was really about building a very basic product, a very truly minimally viable acceptable product.

+ +

And then the seed round in fintechs is often about getting to product-market fit or just demonstrating you can reach your end consumer or target user. In fintech, it's often not quite as much tied to a certain amount of revenue at that stage. It's often about just demonstrating that you can get to that user, and that's because, in financial technology, the cost to acquire is often quite high.

+ +

And so for a company that only has raised, say, a $5 million pre-seed because of the gravity, because it often costs hundreds sometimes thousands of dollars depending upon the market to acquire a specific user, the math is such that you're just not going to have that many users, and you're not going to be able to get to a certain amount revenue. And so often in fintechs, 1 million gets you...that pre-seed gets you that initial product. The seed is about demonstrating that you can scalably get to that end user.

+ +

And then the series A is really about blowing that out and starting to exploit that marketing and acquisition machine that you've been building to start creating revenue. That's a little bit industry-specific. Other industries will have similar or different terms. And depending upon what sort of branding a firm might want for the round, you also might hear $100 million pre-seed. You hear those things as well. It's a crazy time to be building a company.

+ +

CHAD: So you mentioned Chris Toomey, who's the CTO of Sagewell, and he was previously at thoughtbot. As a prior CTO, what were some of the things you looked at in terms of finding Chris and deciding he was the right one to join your team as CTO? I imagine your standards were pretty high.

+ +

SAM: Yeah, and Chris met them quite happily. As a CTO transitioning to CEO, I think you have to understand your strengths and weaknesses as a CTO as well as the learning curve that you might have stepping into your new role as a CEO. And I would say that one of the fortunate things is that Jeff, my co-founder and COO, we actually have a pretty unique set of skills that can span a lot of different domains.

+ +

And so I would say that looking at Jeff, Chris, and myself, we really had to make sure we had our bases covered to build the financial and technology product we needed. I would encourage folks building a company early on to really think about your strengths and weaknesses, your founding team's strengths and weaknesses.

+ +

And as I was getting to know Chris, kind of the initial handshake agreement starting to build and prototype various solutions, I think that I was particularly impressed and looking for someone who was willing to have a deeply experimental and MVP mindset while managing the risks of working with a vulnerable population. And so over the course of December through March or April, in dealing with and spinning up a couple of different prototypes with radically different product strategies and end products, I was able to see how Chris was able to be mature and shrewd about where he could cut corners, where he couldn't cut corners and then execute accordingly.

+ +

It's funny, Chris and I were talking at our one on one a week or two ago. As a CTO, I know a little more of what's possible. I know if I come in and say, "I want the Taj Mahal," I know you'll get walked back down. Chris and I over the past year...I often come to Chris, having already teared down my Taj Mahal. And I'm like, "Well, Chris, what I really need is one little specific problem." And Chris and I actually set a goal between us that I actually kind of come to him asking for the Taj Mahal next time [laughter] or not next time but sometime in the next year.

+ +

Because I think one of the things I've had to check or do in CEO is let Chris do CTO's job and not internalize all the time his voice and concerns but actually put forth a vision and not be afraid about the fact that it isn't something that we can get to market in a week or that we can't ship in three or four weeks’ time, which is an interesting contract that I think we've developed and an interesting growth area. And it's my job to throw out bigger ideas, not to be the one who tears them down all the time, which is fun, and I enjoy doing that with Chris.

+ +

CHAD: Yeah, that's an interesting perspective. And I often even working with clients and consulting want that because if you're only getting the small pieces all the time, you cannot be privy to the big picture of what we're aiming for. And that will often lead you to maybe not taking everything into account, either that's on the roadmap or down the road. Or realizing, oh, you're disappointed now, but that's because I didn't know that you wanted to do this. If I had known, then we could have done this in a different way or something like that. And so, getting a sense of that big picture is often important.

+ +

SAM: Yeah. And it's a fun, I'd say...yeah, and growing with Chris and figuring out that he's the right person for the role as a CTO turned CEO means kicking off the ladder and actually just stepping into my role and letting him do his, which has been a fun contract to establish.

+ +

CHAD: So, did you work with Chris as a contractor before committing to him as CTO?

+ +

SAM: Yeah, we were in a consulting relationship. I think Chris was politely under billing. And the pretext is always that this was something that we were really aiming to build a company together, assuming everything worked out across Chris, Jeff, and I. And so, he did start in that capacity. And then I'm trying to remember the exact timelines. Sometimes the paperwork is well after the actual agreement whenever you're creating these companies. But in a few months’ time, definitely by July and probably by May, we were building the company and off to the races.

+ +

CHAD: Now, is that a path that you would recommend to other founding teams looking for a CTO is to not commit early to really make sure that you work well with someone, maybe through a contracting relationship first?

+ +

SAM: Yeah, I think ultimately, if you're going to be going on a journey, a decade long journey, a lifetime-long journey, through highs and lows, I think the best way for everyone to know what they're getting themselves into, the excitement, and the reward, and the aches, and the pains and the sleepy [inaudible 33:31] in the morning is by working together, and I don't think there's a shortcut. In this case, it depends a lot on the situation. It depends if folks are in a position where they cannot take pay. It depends on whether nights and weekends are free or they have flexibility in their other roles.

+ +

But generally speaking, I think that ultimately, you're trusting, and your founding team is going to be taking so many risks together that you want to go in as eyes wide open as possible and have removed as much founding team risk, disagreements, misaligned working styles, misaligned visions, or preferences as possible. My coach used to say that that's the number one reason why companies at the seed stage fail is management teams and founding teams.

+ +

And so as you're thinking about building your company, and I can't emphasize this enough, mitigating and removing founding team risk, however possible, with consulting being one of them and navigating a tough conversation or two being another, is absolutely core to removing as much risk as possible for your startup.

+ +

CHAD: That's great advice. And just like you and Jeff had a time of working together before you actually started a company together, I think it's great advice to try to find ways to do that with other early members of the team too because it's a big commitment, and you want to make sure that you get it right.

+ +

SAM: Exactly.

+ +

CHAD: Well, you've reached sort of the pinnacle of having now someone on your team that used to work at thoughtbot. I think I'd be remiss if I didn't point out that we have another podcast at thoughtbot; it's called The Bike Shed. And Chris started as a host on that show while he was on thoughtbot, and he continues that to this day along with Steph Viccari, who's a team lead at thoughtbot.

+ +

And so if people are interested in hearing about Chris' work now at Sagewell and following along with the team and the work that he's doing there as well as the work we do at thoughtbot, people can check that out at bikeshed.fm. Sagewell is not a client of thoughtbot. But you've worked with thoughtbot before as a client twice, right?

+ +

SAM: Yeah, exactly, both at my first company Freebird, which was sold to Capital One, and at PathCheck, the non-profit I worked at.

+ +

CHAD: So you specifically, I assume, then made an effort to recruit from thoughtbot when you started Sagewell. [laughs]

+ +

SAM: I would say I know and love the way that thoughtbot approaches building software. And I know and love the people that I've worked with from thoughtbot. And I would say that it was as much a feature of being in the same communities as it was specifying a specific group. But you guys have created a great culture. [laughs]

+ +

CHAD: I'm just kidding. I didn't actually think that that was the case, but I can guess a lot of the benefits of working with someone who's worked at thoughtbot before because of the level of experience and the level of skill and communication and everything that people at thoughtbot have. But I'm curious, what if I turn that around? Is there a downside to hiring someone who worked at thoughtbot previously to your team?

+ +

SAM: So one of the things that I love about, particularly early on, we have a hire that we just made recently. She worked at a senior living facility for four or five years and then worked at Wells Fargo for four or five years. And before, we had a bunch of fears, and this new employee listed five or six totally different fears than we ever would have thought of. And so now we have way more fears. And part of that can be unnerving, and part of that can be challenging.

+ +

And I would say that one of the challenges of working with a team that builds software in such a clear culture is that you might not get all the fears. You might not get certain sorts of diverse perspectives or headaches because of a particular way that product and engineering are conceived. And so one risk...it’s kind of the unknown-unknown sort of situation, but it's real in startups which is I think that making sure you have diverse perspectives across the domains where you need to be deeply an expert for folks who are very similar to you is a major risk.

+ +

CHAD: That's great. Well, Sam, thanks for stopping by and sharing with us. I really wish you and Sagewell and the entire team all the best.

+ +

SAM: Awesome. It was wonderful talking.

+ +

CHAD: And if folks want to find out more about Sagewell Financial or follow along with you or get in touch with you, where are all the best places for them to do that?

+ +

SAM: sagewellfinancial.com is our email. And if you or your parents are interested in what we're building as a customer or a member, you can sign up there. If you'd like to reach me, I'm mostly on Twitter following cute animals and occasionally a good tech post @Ferrum_of_omega. And if you'd like to contact our company, you can just go to /press and fill out the form there.

+ +

CHAD: Awesome. And you can subscribe to the show and find notes for this episode along with a transcript of this episode and all past episodes of this season at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sam Zimmerman is CEO and Co-founder of Sagewell Financial. Sagewell is building a banking platform for the needs of folks who are trying to retire and live off their savings and income as intelligently and as well as possible.

+ +

Chad talks with Sam about deciding what their first product should be and what they would be bringing to market, finding the right partners, and minimizing risk to make a business and a product that works.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Sam Zimmerman, CEO and Co-founder of Sagewell Financial. Sam, thanks for joining me.

+ +

SAM: Thanks so much for having me, Chad.

+ +

CHAD: I've been following along with Sagewell Financial for a little while now, given our cross-histories and the fact that we worked with a few companies that you've worked at in the past. So I'm aware of what Sagewell Financial is, but I'm not sure that all of our audience is. So I think a good place to start would be by giving folks a little bit of an intro into what Sagewell Financial is, and then we'll touch on the founding story and go from there.

+ +

SAM: Awesome. So, in a sentence, Sagewell is building the digital banking that our parents deserve. To expand on that even more, America's retirees are a really interesting and important and powerful demo in American culture at large. There are 56 million Americans on a fixed income. And last year in venture capital, nearly $100 billion went to fund financial technology companies rewriting all of finance. And of that 100 billion or a little under, less than a fraction of a percent went to America's seniors.

+ +

And so we are trying to build banking from the ground up for the needs of folks who are living on a fixed income who are in their golden years and aren't thinking about that new job or making new money. We're building a bank for folks who are trying to retire and live off their savings and their income as intelligently and as well as possible. And that looks really different than the bank that a millennial or a Gen Z user might have.

+ +

CHAD: So that's really interesting. Right or wrong, what are the reasons that this historically hasn't been a target demographic for investment?

+ +

SAM: So the prevailing assumption among venture capitalists was (We're changing that and hopefully changing that quite quickly.) was that retirees aren't open to changing. Beyond that, they're also not technically sophisticated. These folks don't know how to use a phone or aren't open to a bank that might not have any physical branch. They are set in their ways. They're not going to move branch, or they're barely going to watch a new TV show.

+ +

A lot of folks who are trying to talk...imagining a grandma or a grandpa was really what the venture capitalists are drawing on often when they're thinking about why a senior wouldn't expect to have a bank with all the new features that the millennial might.

+ +

CHAD: Well, that one is certainly changing, especially as the venture capitalists get older themselves. They probably realize that that's an outdated notion in terms of the technical aptitude or familiarity of that audience, right?

+ +

SAM: Exactly. And it's a fascinating moment. There are 10,000 boomers who turn 65 each day in America, about 4 million folks each year. And those folks were about 40 whenever the.com boom passed. They've been using email. They have XE and PayPal. And importantly, why we're building this company now is that COVID changed seniors' digital lives more than anyone else. ARP reports how 70% of all American retirees know how to use Zoom and video conferencing software nowadays.

+ +

Across the stack of digital goods and services, seniors were actually the group that was most moved online. And so, from where we sit as entrepreneurs, we saw a massive market, an exogenous effect creating a disproportionate opportunity. And so we began designing and iterating on and understanding our user to build a product that met those needs with this massive and growing market.

+ +

CHAD: Banking is a highly regulated complex space. And I imagine from day one you're looking at that and saying, "Well, we might want to do everything eventually, but doing everything is going to be difficult." So what was the process you and your co-founder and the team around you used to decide what the first product should be and what you were going to bring to market?

+ +

SAM: Our founding team spent almost nine months in user interviews and user research across what one director of finance at Capital One called geriatric finance. We talked to hundreds of folks, and a lot of our assumptions about what the simplest or most low-trust or quickest to use service might be were actually totally turned on their head in a really interesting way.

+ +

Another reason why venture capitalists aren't so confident you can reach this demo is a couple of companies have come before us, and a lot of them followed, in financial technology, a Mint-like model where you log in, and you share your various bank credentials. They pull your credit card transactions and bank transactions. And one of the really surprising things in our hours of user interviews was that that model was really unpalatable to this demo. They actually thought it was a lot higher trust to share bank credentials than it was to actually open an account.

+ +

And so we began thinking, what's the highest engagement, most common accessible feature that our demo is familiar with? And that's already broadly online. And let's start there. And the original insight came with a woman she was from Pennsylvania, and we were talking. We built this kind of mint.com-type prototype to try to help imagine banking for her needs without this high trust checking account. And she was like, "Oh." She was aghast that we were even considering asking for her bank credentials.

+ +

We heard that, and then we said, "All right, no worries, no need to do this product demo." And then she was like, "But I really love Chime, and I really love Chime's checking account." And we were like, "Wait, you have a digital bank account?" And she's like, "Yeah, I love Chime." And it was this moment where thinking about our user, what trust meant to them, what was familiar to them, and what being online meant to them opened the floodgates and helped us really understand this user and what that first product needed to be.

+ +

And so our initial product is a checking account. It's got a variety of senior-specific features around and enabling it. And it's built incredibly excessively to be available to folks who use technology in all sorts of ways. But we started with the basics because that's what our members are most familiar to and most expect.

+ +

CHAD: So you say in the fine print on the website that Sagewell is a financial technology company and not a bank, and your banking services are provided by a partner. What was involved in actually bringing that online, finding the right partner, implementing the features? What did that look like?

+ +

SAM: Yeah, it is an incredible time to be building any sort of banking in America around the world. So to that point earlier, $100 billion was pumped into financial technology companies. And so as a result, there are so many companies and so much innovation happening in banking and fintech broadly. And so starting and figuring out what vendor to work with was actually what our strategy from a banking and regulatory perspective was. And in turn, what vendors and in-house technology we needed to build was one of the hardest initial challenges that I've ever had to face in building a company.

+ +

It is still, despite what many...you'll see a lot of ads, you know, "Have a card online in minutes." It is still in today's day and age quite an achievement to build banking and get it online, and servicing your customers in a scalable and sustainable way. And so we spent a lot of time early on in the architecture and vendor selection process and product strategy process thinking about what vendors to go with; what we were going to build in-house. And before ultimately breaking ground about three months after we began, we set the product itself, which was going to be a checking account for retirees.

+ +

CHAD: What were the factors that went into choosing the partner that you ultimately chose?

+ +

SAM: Beyond your standard enterprise vendor selection, we wanted to make sure that it was secure, and we wanted a specific set of features. In our space, there are about six different companies that provide what's called Banking as a Service technology. And so that was one of our key vendors is the technology company that works with the bank to allow us to open checking accounts, fund accounts. And most of those companies have been around for only a few years. And so their products themselves are hardening and being built.

+ +

And about $200 million I would say has been invested in those companies last year. And so we wanted one that was well-capitalized. We wanted one that had not had any IT security issues. We wanted the underlying bank to be aligned in our mission. Retirees have a variety of specific financial needs. A lot of our product development involves working very closely with the bank. And so, we needed to make sure that the bank itself that they worked with was on board.

+ +

And lastly, we talked to other customers, and that was ultimately the most valuable thing in our experience and not just the customers that they refer you to but the customers who have left for one reason or another. Those were the major factors that we chose in our Banking as a Service provider. And then, beyond that, that's one piece of the puzzle. In our bank tech stack, we're looking at around 15 different partners across all parts of banking. And that's the largest and most important one. And those were the criteria we used to select.

+ +

CHAD: I often say when I'm looking at building a product or service, and we look at those integration points with external vendors, it is one of the riskiest parts of building a product because you're not in control of it. So from a business perspective, it's risky. But also, from a technology perspective, that's where estimates can get out of whack.

+ +

And things can work not like you're expecting or like the documentation said or just surprises crop up along the way. Or when something goes down, your product is broken. And your entire product [laughs] basically is built on those vendor relationships. So, how do you minimize that risk and work in that environment to make a business that works and a product that works?

+ +

SAM: [chuckles] I suppose the answer is with a lot of prudence, thoughtfulness, and care at a high level.

+ +

CHAD: [laughs]

+ +

SAM: I was actually just talking with a CTO friend of mine just talking about how in a lot of startups, one of the skills that I most ask of engineers and engineering leaders early on is vendor selection and how I hadn't seen an interview process that really helped get at that. It's a core part of a lot of technologists' jobs and particularly a lot of engineering folks' jobs. The API docs looked good but did he test it or evaluate it? Was there a third-party tool you could have used instead of building in-house?

+ +

Those are the sort of questions that a lot of times early-stage startups are answering all the time. And I had yet to see an interview that got at that. So it's a really shrewd point and one that I hope that as technologists and particularly early-stage startups become more about really going deep in one area and then leveraging third parties elsewhere, I hope that we start actually hiring and developing criteria to do that with the people that we assemble.

+ +

I think the first part what I would say is we described a little bit about the risks. We went through a risk mitigation exercise, which smells very enterprise-y. It's kind of the sort of thing that you would expect exists in some massive waterfall with a Jira board mainframe computer but just listing like, here's this integration. If this were to happen, what would we do? If the API went down, what control do we have, or how could we minimize the impact on our customers?

+ +

That exercise across some of our biggest integrations helped us select and take on the risks we wanted and avoid the ones we couldn't. So there was a lot of conversation about the sorts of failures we could put up with and how we could put up with them, and the sorts of failures we couldn't. And then really testing for the ones we couldn't to make sure that we were making as good a choice as possible.

+ +

Despite that thoughtful answer, it was the best we could do. I would say that, particularly in a space that's as fast-moving as Banking as a Service, I would say that a lot of it is still that soft skill, that relational conversations with other teams and folks and whether you trust the team that you're trusting to execute and build what they said they're going to build and that hiring skill but also a good bit of luck as well.

+ +

CHAD: So correct me if I'm wrong, but up until Sagewell, where you're CEO, you had been CTO of the other companies that you founded and worked at. Is that right?

+ +

SAM: Yeah, that's correct.

+ +

CHAD: So, what has the change to being CEO instead of CTO been like for you personally? And was that choice clear from the beginning with Sagewell?

+ +

SAM: So far, it's been incredibly rewarding. I would say in between startups; I actually volunteered at an organization called PathCheck. And while my title was CTO, the scope of that included partnerships, vendor negotiations, CISO exercises, product. It was a pretty expansive CTO role. And I found myself really energized by the breadth and the ability to work with even more really talented, thoughtful experts in their own domain and empower them to do more. And so I knew in my next role, I wanted more of that breadth.

+ +

There's an essay that classifies folks as foxes who can do a little bit of everything or hedgehogs who can do one thing really well. And I'm a super fox. [laughter] I love doing lots of things. And so CEO to me is just like an opportunity to...it's maximizing breadth and maximizing difference of experience. And I transitioned, I'd say, from a normal CTO role to a beefy CTO role to making CEO a pretty natural step from there.

+ +

CHAD: And your co-founder is named Jeff Wright, and he's the COO. How did you meet him and get started with Sagewell?

+ +

SAM: Jeff and I, it's been wonderful. I was trying to figure out how I was going to get engaged in pandemic work in April of 2020 after leaving my last startup while it was being sold to Capital One. And I was talking with a founder friend of mine, a guy named Ty Harris, who is the CEO of an Insurtech company called Openly. And he was previously the CTO at Liberty Mutual. And Ty and I had a couple of lunches and conversations, and I was talking to him about how it is getting involved in COVID stuff and how I was ultimately my species as an entrepreneur, and I was going to be building something again.

+ +

And he connected me with Jeff, and Jeff and I touched base quickly in April. And it was a little bit like a frog in the pot sort of situation where it started like, yeah, maybe we could build a company. Let's riff on some ideas and see what's out there. And it was a really, really natural progression from August to a couple of evenings, maybe a Saturday call or two, to most evenings and definitely a Saturday to oh, man, when should we transition?

+ +

CHAD: You were both working full time on other things at the time. You were working with PathCheck.

+ +

SAM: Yep, exactly. And so he was the CPO at a company called Plymouth Rock, and I was working at PathCheck. And not to go into PathCheck's story too much, but PathCheck was largely deploying a research technology, the Google and Apple Exposure Notification protocol. And it became clear that most of the states that were going to do anything were already going to do it. And so, it was natural to start thinking about what was next in August and September. And so, as my species does, that then became the night and weekend project to figure out what's next.

+ +

CHAD: So you mentioned that this is a space that is typically not strongly funded. So was that a challenge for you as you were getting started? How did you get that initial, you know, where did your initial funding come from? And I know you recently raised, at least it was announced, 5.3 million in January. So what was the transition from those early days? Where did the funding come from to ultimately getting the investment in this last round?

+ +

SAM: Jeff and I worked in the fall of 2020, met our CTO, Chris Toomey, in November actually from connection through a friend. Early on, we were a team with a demo. We really knew that we cared about seniors, and our background is in financial services. We were trying to think of a new product for seniors and so a financial product for seniors. And so, around January, we sharpened our pencils on the user research side of things and the product side of things. And once we had a clearer sense of the product direction we wanted to take, ultimately building banking for retirees, we began the fundraising process.

+ +

CHAD: So were you essentially self-funding at that point?

+ +

SAM: Yep. So we were self-funding from January-ish till May. I find that skin in the game to be… I wish I was the sort of founder who could think about flawless ideas without a little pressure. But in my experience, it's actually been where unless I jump in, unless I can have a little bit of pressure, my ideas aren't often as refined as I'd like. And so Jeff joined it full-time in February. And then we fundraised through April, closing a 1 million pre-seed, which is pretty common in fintech.

+ +

Most financial technology companies the banks won't talk to you until you have at least a million dollars in funding. And so we raised the money we needed from...and who did the money come from? It came from Point Judith Capital, who actually had invested in Ty, the guy who connected us, with his company Openly. So we had our initial conversation with David, who's been absolutely wonderful at Point Judith Capital.

+ +

And also, Jeff and I knew that innovating for a vulnerable population, ultimately retirees, meant that we wanted to have folks from the beginning who represented the seniority and seriousness with which we are taking our work. And so the second investor who in between the two of them took most of that million was Crossbeam and Raj Date at Crossbeam, who's the former Deputy Director of the U.S. Consumer Protection Bureau. We really wanted folks around the table who knew what innovation looked like and fintech innovation like David, as well as folks who understood the world of government and finance like someone like Raj to innovate thoughtfully with this demo.

+ +

CHAD: Was it difficult to get those funding rounds?

+ +

SAM: The first one? Yeah, the first one was about two months. I thought it would have taken about a month. The second one the market is pretty crazy right now. And I would say between my first company and my second, it used to be that you'd set aside six months to fundraise, and so I'd prepared for a six-month fundraise. Started kind of in early October two weeks in, and they were like, "Wow, you've already been in the market for two weeks?" [laughter]

+ +

And I was like, what? I was totally off base in terms of what was the new normal. Ultimately, that round came together in about a month and a half as well. And so we had a lot of interest. The second round that 5.3 million went from not a ton of interest to tons of interest and lots of folks around the table and having to push folks out or turn folks down pretty quickly. The first round, I would say for a pre-seed, one to two months given that the idea was hardening, sounds about right.

+ +

The second one was about one to two months but was a little...a lot of people would get excited by the market; they'd get excited by the team. And then they'd say, "You can't get a senior to open up a bank account," and then they'd come back. And then we found one believer alongside David and Raj, who had been with us. And once we got the folks at 25Madison and Merrill, especially, the rest of the round came together really quickly.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Given that you were able to put together a round quickly, how do you decide ultimately not to take even more money? What are the factors that go into deciding how much you're trying to fundraise and how big the round is going to be? And is there pressure as you're doing that to maybe go even bigger?

+ +

SAM: Yeah, we had, I would say maybe seven and a half million dollars interested. And ever since we've closed, we've had multiple firms who are interested in a new round of capital. The market is really, really quite founder-friendly right now. I think ultimately, for any founder, what you're trying to do is create as much value with as little capital as possible. That's ultimately the game that you're trying to play now.

+ +

For a little baby company, it's often really hard to figure out how much money or how much value you'll be able to create over what amount of time. There's so much to figure out. There are so many bets and learnings and risks that it's often very hard for a company to say, with $5 million, I'll create $20 million in value. So ultimately, if you're a founder, you're incented to give away as little of the company as possible and create as much value from that.

+ +

And so when we were doing our modeling, we actually thought that it was somewhere closer to four of what we needed to create the amount of value needed to raise our A. And we ultimately bumped it up to 5.3. And there's a good bit of advice you hear a lot among founders that raising a bit more than you think is prudent, and anyone who has managed a budget knows how that can go. So we ultimately did go up to 5.3.

+ +

But taking more would have meant that we were paying a premium where we could get that million dollars maybe in a year's time, and we'd be giving away a quarter-point or a half a point of the company for that million where we might be giving away 1% or 1.5% of the company now. So it's all about creating as much value with as little money as possible. And it's easy to get lost in the big rounds and the big numbers. But ultimately, it's pretty simple math.

+ +

CHAD: And correct me if I'm wrong, and this is a question as much as a statement. So to reiterate, the rounds you're talking about are seed rounds. And so traditionally, what that means is that the majority of work that you have to do is just making the product. But in the space you're in, there is a point in time where you've made the product, and you've shown the traction, so what you have becomes more valuable.

+ +

And so it might be that the next round, which is maybe a Series A, a significant portion of that capital would be spent on something else like marketing or sales teams and that kind of thing. And you're growing beyond just the product development at that point. Is that how you're thinking about this, or am I wrong?

+ +

SAM: So it's funny that it's really changed the names. The round size what they mean has changed more in the last two years than ever before, and I would say that, particularly in fintech, because fintech has a number of unique challenges. So I would say that that $1 million round that we raised in May that was really about building a very basic product, a very truly minimally viable acceptable product.

+ +

And then the seed round in fintechs is often about getting to product-market fit or just demonstrating you can reach your end consumer or target user. In fintech, it's often not quite as much tied to a certain amount of revenue at that stage. It's often about just demonstrating that you can get to that user, and that's because, in financial technology, the cost to acquire is often quite high.

+ +

And so for a company that only has raised, say, a $5 million pre-seed because of the gravity, because it often costs hundreds sometimes thousands of dollars depending upon the market to acquire a specific user, the math is such that you're just not going to have that many users, and you're not going to be able to get to a certain amount revenue. And so often in fintechs, 1 million gets you...that pre-seed gets you that initial product. The seed is about demonstrating that you can scalably get to that end user.

+ +

And then the series A is really about blowing that out and starting to exploit that marketing and acquisition machine that you've been building to start creating revenue. That's a little bit industry-specific. Other industries will have similar or different terms. And depending upon what sort of branding a firm might want for the round, you also might hear $100 million pre-seed. You hear those things as well. It's a crazy time to be building a company.

+ +

CHAD: So you mentioned Chris Toomey, who's the CTO of Sagewell, and he was previously at thoughtbot. As a prior CTO, what were some of the things you looked at in terms of finding Chris and deciding he was the right one to join your team as CTO? I imagine your standards were pretty high.

+ +

SAM: Yeah, and Chris met them quite happily. As a CTO transitioning to CEO, I think you have to understand your strengths and weaknesses as a CTO as well as the learning curve that you might have stepping into your new role as a CEO. And I would say that one of the fortunate things is that Jeff, my co-founder and COO, we actually have a pretty unique set of skills that can span a lot of different domains.

+ +

And so I would say that looking at Jeff, Chris, and myself, we really had to make sure we had our bases covered to build the financial and technology product we needed. I would encourage folks building a company early on to really think about your strengths and weaknesses, your founding team's strengths and weaknesses.

+ +

And as I was getting to know Chris, kind of the initial handshake agreement starting to build and prototype various solutions, I think that I was particularly impressed and looking for someone who was willing to have a deeply experimental and MVP mindset while managing the risks of working with a vulnerable population. And so over the course of December through March or April, in dealing with and spinning up a couple of different prototypes with radically different product strategies and end products, I was able to see how Chris was able to be mature and shrewd about where he could cut corners, where he couldn't cut corners and then execute accordingly.

+ +

It's funny, Chris and I were talking at our one on one a week or two ago. As a CTO, I know a little more of what's possible. I know if I come in and say, "I want the Taj Mahal," I know you'll get walked back down. Chris and I over the past year...I often come to Chris, having already teared down my Taj Mahal. And I'm like, "Well, Chris, what I really need is one little specific problem." And Chris and I actually set a goal between us that I actually kind of come to him asking for the Taj Mahal next time [laughter] or not next time but sometime in the next year.

+ +

Because I think one of the things I've had to check or do in CEO is let Chris do CTO's job and not internalize all the time his voice and concerns but actually put forth a vision and not be afraid about the fact that it isn't something that we can get to market in a week or that we can't ship in three or four weeks’ time, which is an interesting contract that I think we've developed and an interesting growth area. And it's my job to throw out bigger ideas, not to be the one who tears them down all the time, which is fun, and I enjoy doing that with Chris.

+ +

CHAD: Yeah, that's an interesting perspective. And I often even working with clients and consulting want that because if you're only getting the small pieces all the time, you cannot be privy to the big picture of what we're aiming for. And that will often lead you to maybe not taking everything into account, either that's on the roadmap or down the road. Or realizing, oh, you're disappointed now, but that's because I didn't know that you wanted to do this. If I had known, then we could have done this in a different way or something like that. And so, getting a sense of that big picture is often important.

+ +

SAM: Yeah. And it's a fun, I'd say...yeah, and growing with Chris and figuring out that he's the right person for the role as a CTO turned CEO means kicking off the ladder and actually just stepping into my role and letting him do his, which has been a fun contract to establish.

+ +

CHAD: So, did you work with Chris as a contractor before committing to him as CTO?

+ +

SAM: Yeah, we were in a consulting relationship. I think Chris was politely under billing. And the pretext is always that this was something that we were really aiming to build a company together, assuming everything worked out across Chris, Jeff, and I. And so, he did start in that capacity. And then I'm trying to remember the exact timelines. Sometimes the paperwork is well after the actual agreement whenever you're creating these companies. But in a few months’ time, definitely by July and probably by May, we were building the company and off to the races.

+ +

CHAD: Now, is that a path that you would recommend to other founding teams looking for a CTO is to not commit early to really make sure that you work well with someone, maybe through a contracting relationship first?

+ +

SAM: Yeah, I think ultimately, if you're going to be going on a journey, a decade long journey, a lifetime-long journey, through highs and lows, I think the best way for everyone to know what they're getting themselves into, the excitement, and the reward, and the aches, and the pains and the sleepy [inaudible 33:31] in the morning is by working together, and I don't think there's a shortcut. In this case, it depends a lot on the situation. It depends if folks are in a position where they cannot take pay. It depends on whether nights and weekends are free or they have flexibility in their other roles.

+ +

But generally speaking, I think that ultimately, you're trusting, and your founding team is going to be taking so many risks together that you want to go in as eyes wide open as possible and have removed as much founding team risk, disagreements, misaligned working styles, misaligned visions, or preferences as possible. My coach used to say that that's the number one reason why companies at the seed stage fail is management teams and founding teams.

+ +

And so as you're thinking about building your company, and I can't emphasize this enough, mitigating and removing founding team risk, however possible, with consulting being one of them and navigating a tough conversation or two being another, is absolutely core to removing as much risk as possible for your startup.

+ +

CHAD: That's great advice. And just like you and Jeff had a time of working together before you actually started a company together, I think it's great advice to try to find ways to do that with other early members of the team too because it's a big commitment, and you want to make sure that you get it right.

+ +

SAM: Exactly.

+ +

CHAD: Well, you've reached sort of the pinnacle of having now someone on your team that used to work at thoughtbot. I think I'd be remiss if I didn't point out that we have another podcast at thoughtbot; it's called The Bike Shed. And Chris started as a host on that show while he was on thoughtbot, and he continues that to this day along with Steph Viccari, who's a team lead at thoughtbot.

+ +

And so if people are interested in hearing about Chris' work now at Sagewell and following along with the team and the work that he's doing there as well as the work we do at thoughtbot, people can check that out at bikeshed.fm. Sagewell is not a client of thoughtbot. But you've worked with thoughtbot before as a client twice, right?

+ +

SAM: Yeah, exactly, both at my first company Freebird, which was sold to Capital One, and at PathCheck, the non-profit I worked at.

+ +

CHAD: So you specifically, I assume, then made an effort to recruit from thoughtbot when you started Sagewell. [laughs]

+ +

SAM: I would say I know and love the way that thoughtbot approaches building software. And I know and love the people that I've worked with from thoughtbot. And I would say that it was as much a feature of being in the same communities as it was specifying a specific group. But you guys have created a great culture. [laughs]

+ +

CHAD: I'm just kidding. I didn't actually think that that was the case, but I can guess a lot of the benefits of working with someone who's worked at thoughtbot before because of the level of experience and the level of skill and communication and everything that people at thoughtbot have. But I'm curious, what if I turn that around? Is there a downside to hiring someone who worked at thoughtbot previously to your team?

+ +

SAM: So one of the things that I love about, particularly early on, we have a hire that we just made recently. She worked at a senior living facility for four or five years and then worked at Wells Fargo for four or five years. And before, we had a bunch of fears, and this new employee listed five or six totally different fears than we ever would have thought of. And so now we have way more fears. And part of that can be unnerving, and part of that can be challenging.

+ +

And I would say that one of the challenges of working with a team that builds software in such a clear culture is that you might not get all the fears. You might not get certain sorts of diverse perspectives or headaches because of a particular way that product and engineering are conceived. And so one risk...it’s kind of the unknown-unknown sort of situation, but it's real in startups which is I think that making sure you have diverse perspectives across the domains where you need to be deeply an expert for folks who are very similar to you is a major risk.

+ +

CHAD: That's great. Well, Sam, thanks for stopping by and sharing with us. I really wish you and Sagewell and the entire team all the best.

+ +

SAM: Awesome. It was wonderful talking.

+ +

CHAD: And if folks want to find out more about Sagewell Financial or follow along with you or get in touch with you, where are all the best places for them to do that?

+ +

SAM: sagewellfinancial.com is our email. And if you or your parents are interested in what we're building as a customer or a member, you can sign up there. If you'd like to reach me, I'm mostly on Twitter following cute animals and occasionally a good tech post @Ferrum_of_omega. And if you'd like to contact our company, you can just go to /press and fill out the form there.

+ +

CHAD: Awesome. And you can subscribe to the show and find notes for this episode along with a transcript of this episode and all past episodes of this season at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+G4vyxb57 + + ]]> + + Chad Pytel + + + 413: The Takeoff Institute with Brian Hollins + https://podcast.thoughtbot.com/413 + 37de0bf6-781d-4578-8261-64e1db00d29b + Thu, 03 Mar 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Brian Hollins is the Founder of the Takeoff Institute and Founding Managing Partner of Collide Capital. The Takeoff Institute is focused on equipping Black undergrads with the resources and mentorship they need to build a young professional career. + +Chad talks with Brian about providing students with necessary skills like etiquette and polish to break into Tesla and McKinsey-level companies and facilitating facetime, communication, and mentorship with other Black people within those companies who are at executive levels. + 38:14 + no + + + Brian Hollins is the Founder of the Takeoff Institute and Founding Managing Partner of Collide Capital. The Takeoff Institute is focused on equipping Black undergrads with the resources and mentorship they need to build a young professional career. +Chad talks with Brian about providing students with necessary skills like etiquette and polish to break into Tesla and McKinsey-level companies and facilitating facetime, communication, and mentorship with other Black people within those companies who are at executive levels. +The Takeoff Institute (https://takeoffinstitute.com/) +Follow Brian on Twitter (https://twitter.com/BHolls1) or LinkedIn (https://www.linkedin.com/in/brian-hollins/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Brian Hollins, Founder of the Takeoff Institute and Founding Managing Partner of Collide Capital. Brian, thanks for joining me. +BRIAN: Chad, I'm pumped to do this. Thanks for having me. +CHAD: So you are obviously the Founder of the Takeoff Institute. So let's start there. Why don't we give folks a brief overview of what the Takeoff Institute is, and then we'll dive right in? +BRIAN: Absolutely. Happy Black History Month. Let's start there. I'm a Black undergraduate student in the past, and I'm building something for Black undergraduate students today. So Takeoff Institute is focused on equipping Black undergrads with the resources and mentorship they need to build a young professional career. I was lucky enough to go to Stanford for undergrad and almost get thrown over the wall, if you will, by mentors and people that could advise me as I broke into my young professional career. And I, unfortunately, noticed that that wasn't the same for a lot of other folks. +I ran diversity recruiting at Goldman Sachs for a few years and just saw some of the mistakes and little things that people who don't have advisors, people who don't have mentors, people who don't have an older brother in private equity. I saw the mistakes they were making and knew I wanted to build something to help bridge that gap. +So we focus on providing the types of things that I think you need to break into a Goldman Sachs or a Tesla or a Facebook or a McKinsey today that might not have been true five years ago. And unfortunately, I think a lot of career development offices and programs out there are helping students break into a job that doesn't exist anymore, and that's more focused on some of the skills that we've tried to tap into. +CHAD: And what are those skills? +BRIAN: I'll point to a few off the top of my head. One is just polish. If you've never had an internship, you don't know cadencing on scheduling or sending an email to a direct report or really focusing on your LinkedIn, and your resume, and your social media being clean and disciplined. And so we bring to light a lot of the things that I think employers are looking for today. I'll use a good example with our students. If you don't have 500 connections on LinkedIn, the number of connections you have shows. But if you have more than 500 connections, it just shows 500+. +And as a recruiter, when you really think about it, at the top of the funnel, they use these little things to guide a lot of their decision-making. For better or worse, I'm not sure it's a great way to decide who should be a good candidate for your company. But when you get 5,000 applications, and you need to get it down to 100 in a couple of days, there are little things like sending your resume in a Word Doc instead of a PDF or having spelling errors in your application, or not filling out some of the boxes that matter. And so we really train them on that etiquette and polish. +Another bucket that I think is super important we built a speaker series at the Takeoff Institute called You Can't Be What You Can't See. And I think for a lot of Black undergraduate students, you go through a Superday at some of these places. You might meet 10, 15 people. Most of the time, you're not going to meet anyone Black. And you're definitely not going to meet Black people that are at the executive level. +And so we really pride ourselves on bringing in managing directors from banks, and founders and CEOs from growing companies, and leading venture capitalist investors and just help our students see that there are people out there doing what they did. There are people that come from their backgrounds that also weren't sure who they were going to be when they were a sophomore or a junior in college. And so, building confidence is another key pillar of the program that we really pride ourselves on. +And we're very lucky we have students at Tesla, at Apple, at Facebook, at Goldman, at NBC Universal. These students have broken into really exciting roles. And as we think about building the full flywheel around Takeoff, now those students become advocates. Now those students become mentors and advisors. And we build proximity for our students to help them realize there are people that very recently went through a very similar program and are now doing the things that they aspire to do. +CHAD: That's great. It sounds to me like it really is a combination of things that they might not have the opportunity to have done before or gain the experience and because they're marginalized, historically. And also just things that are good to have that, in general, aren't taught in school regardless of your opportunity. +BRIAN: That's right. +CHAD: And sometimes people who have more opportunity are getting that exposure in the jobs that they have along the way and that kind of thing. That makes it certainly easier for them to succeed later on, let alone what they look like when they show up to the interview. +BRIAN: Yeah, I completely agree. And I think the anecdotal use there is most of the things that I'm teaching these kids you can find on Google. The problem is they don't know what to look for. And when we think about fast-tracking these students or getting them into these rooms quicker, getting them through those interviews more effectively, it's almost like bringing all of these resources right in front of their face and allowing them to soak and absorb them in a very efficient manner. +So there's a guide somewhere on the internet of how to break into consulting, and there's a guide on how to crush a product interview. And there's a guide on how to build a perfect resume or a perfect LinkedIn. But we find that most of our students, one, don't know that they should be looking for that stuff, and two, don't know how to go get it all when it matters. And that's really what we focus on, bringing all that stuff in front of them at a more efficient clip and help them build that confidence so that when they do get in front of that interview, they're armed with all the things they need to succeed. +CHAD: Well, I know you're already solving a big problem. But is there anything in particular that you do to then make sure that once these people are in the workforce, in the workplace, they're going to companies that are going to treat them right where they're not going to face bias as much as possible and those kinds of things? Or are you mostly focused on getting them ready right now? +BRIAN: No, it's a great question. I'd put that in a 2.0 Takeoff University, Takeoff Institute, but it's absolutely critical. It's super important. And we have a long way to go. Chad, I don't want to pretend like the world is ten times better than it was five years ago. But the transparency through which some of this data is being recorded, the accountability that's being held in rooms that matter, so C-suite, executive suite, board meetings, it is changing. And I'm very excited about that because I think for the students that can, and this is in every student, and I don't want to pretend like it is, but for the students that can choose where they go, they're going to choose to go to those companies. +They're going to choose to go to the companies where there is active, positive feedback from underrepresented people, so Black, Latin, female, people that don't look like the rich, white guy that runs the company. They're going to look for that feedback. And they're going to look for companies that very, very clearly advocate for supporting those types of communities. +And, again, I think we're in the early innings of that. But I think that we're definitely on a path towards that being more and more important and that tailors who we partner with and who we spend time with. And if you look at a lot of our partners, they are people that care about that stuff, and they are people that are actively working on doing something about it, which we certainly appreciate. +CHAD: So the core of the Takeoff Institute is the fellowship. Is that right? +BRIAN: Yeah, that's right. +CHAD: What exactly is that? +BRIAN: The Takeoff Institute Summer Fellowship is an eight-week program, again, designed to advance and equip Black undergraduates with the resources and mentorship they need to launch a young professional career. So the first thing that I think about is what we had talked about earlier, just aggregation of resources. +So we have a partnership with Wall Street Prep, and so our students have to do an Excel and PowerPoint tutorial within the first two weeks of the program. And that's in after hours, and they have to do it on their own. And we track their progress, and they have to submit it. Because I cannot think of a single role in a post-undergraduate career where it is not important to be literate in both of those platforms and also, maybe more importantly, where top performers are not very good in both of those platforms. So the first piece is resource aggregation. +CHAD: And this is happening remotely? +BRIAN: This is all remote. This is all remote. I started the Takeoff Institute in 2020. Chad, I hope there's a day where I say that none of it is remote, but it's the world we live in. +CHAD: [laughs] +BRIAN: And it's what allowed us to scale it the way we did. We had over 500 kids apply for our first fellowship two years ago. We took 50 and had a little over 600 apply for the second year and took 50 again last summer and have some really exciting things coming up for this summer. So we can talk about the goal and where we're headed later. But the second piece is the speaker series that I told you about. And so, bringing in folks during our weekly meetings and allowing them to ask questions and be vulnerable and share that experience. +The third piece is mentorship. And so, I wanted to recreate the feeling of having a direct report. I think too many Black undergrads get to their first job without any real internship experience. And I think in an internship, one of the things you do is you make a bunch of dumb mistakes where your direct report tells you they were dumb because you're an intern. And you check that box, like, whoops, I did that I'm never going to do it again. +And unfortunately, when you get to your first job, and that's some of the stuff you're doing early on, it just doesn't go well. It doesn't lead to you being ranked highly. It doesn't lead to you getting an offer a year later. It doesn't lead to you getting the advocacy and support of people internally to say that you're a top performer. So we almost try to recreate that direct report internship experience and allow them to make some of those mistakes. +And so every student is paired up with a one on one advisor. And so, for folks that are listening, if you want to be an advisor, I'd call it anywhere from 25 to 50-year-olds with a desire to help undergraduate students succeed. We have a variety of different types of advisors. And again, it's really about challenging our students to make sure they send the email to check-in. +They send the email to let them know that they need to meet. They send a calendar invite. And if it's in ET, they remember, oh wow, I need to send that in PT. So just giving them that experience. So resources, access to people that look like them in seats that matter, and mentorship and guidance are the three main pillars of the Takeoff Institute. +CHAD: I love that idea of learning from experiencing failure. One of the things as someone speaking for myself coming from a place of opportunity and privilege and being a white male, I might approach certain circumstances where I'm just not as afraid of failure. I'm a big believer in learning through failure, and so because of that, I'm less afraid of that. Someone who hasn't had that opportunity and is underrepresented might be much more scared of what might happen if they fail, and that's just missing the opportunity to do that. +BRIAN: I think you're absolutely right. And I want to, if you're open to it, have a little fun here. I'd love to flip that question on you and just think about what are some of the things that you would be sharing or guiding to underrepresented ecosystems to help them bridge that gap, to help them kind of get that confidence to know that they do have the right, they do have the skills; they do have the knowledge to break into those places? And it's about quieting that imposter syndrome and going after some of those opportunities. +CHAD: Yeah, I've always believed it's really difficult to tell people not to feel something that they're feeling. [laughs] It's really hard to change someone's feelings. And so I would put it on the mentors that they need to work to create the environment where people understand that it's okay to make mistakes. That's certainly the experience that I had in my internship when I was just getting started out. I saw my manager making mistakes, and they owned up to them. And we talked about them. And we were doing a lot of the same work. We were working alongside of each other. And so that close working relationship is one thing. +I don't know if you're aware, but at thoughtbot, we have an apprentice program where new people are paired with an experienced mentor, and it's almost entirely working together on work. So creating that opportunity. So assuming you have a mentor that's supportive and wants to work with you, great. And if not, I would say try to circumvent that as much as possible and get yourself working with them as much as possible so that you can get close to them and see them working, and see them failing, and really gain that first-hand experience, which in and of itself can be uncomfortable to force that. I totally recognize that. +BRIAN: Totally. Part of the program is they do a research report with their mentor. And so it's sort of this guided I'm here to answer questions, but I am not here to do this for you. And I'm very intentional with our mentors about that. I think a lot of these students, especially the ones who have never had a direct report, they wait until they're told what to do. And they don't know how to turn on that proactive brain. And I think it's a super important muscle to flex, especially at that age. How do you teach a kid to do the thing that he thinks his boss is going to ask for as opposed to the thing that his boss asked for? +CHAD: Well, this is sort of a pet peeve of mine because I think that, in some ways, there is a flaw in our educational system. It's centered around people telling people what to do. +BRIAN: Do what you're told, yeah, absolutely. +CHAD: Right. And so, I was very fortunate that I had some teachers that did more project-based learning and then chose to go to a college that was project-based. And the difference when you're in charge of something, and you're responsible, and people aren't telling you what to do, that really creates the environment where you can do that great work. +BRIAN: Totally. What's pretty cool is we keep a repository of all their presentations. And so, a lot of them, after the program is over they'll actually share their presentation on their LinkedIn or through their socials. And just having a body of work that early in your career, mapping the Esports competitive landscape, or how to build a D2C skincare business for people of color. I mean, really cool projects that they're very proud of, that they worked hard on, and now that they can share. +And, again, part of what we do is build that LinkedIn, build that thought leadership, help them become experts in their own craft because I think it builds that confidence that we just talked about missing for so many of them. And it's doing all these little things that really just unlock their inner self. I'm not giving them anything that they don't already have. I'm just unlocking it. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: Let's take a step back. And I'm curious what it takes to start something like Takeoff Institute. How difficult is it to set up a non-profit? From when you decided to do this, what steps did you take as a founder getting off the ground? +BRIAN: I'll give you context of how I started it at first. I was a student at Harvard Business School. Nine months into my MBA program, the world blew up. And so what was a trip to Shenzhen or Tokyo turned into hanging out in my apartment. And I think similar to what you described around that participatory learning environment and how that helped you, HBS is known for what's called the case method. And the case method is a very, very powerful way to learn. It's, by far, in a way, my favorite way to learn. And I knew nothing about it before I got to HBS. +And the repeat experience of being presented a problem and having to choose a side and then gathering information after the fact around whether that was not necessarily right or wrong but whether that was educated or insightful and then repeating that process over and over again. You just learn a ton about your biases and the types of things that you can and can't accomplish on your own without thinking of other parts of your brain or using other kinds of tools in your toolbox. +And so I found myself really challenged after my first year of school, saying, I've never built anything, and I've never put my mind towards some of the problems that I think exist in the world. And I mentioned while I was at Goldman running diversity recruiting at Stanford for a couple of years, and I saw so many problems and flaws in that model. And then my youngest brother was a Marine. So he served in the military for four years and then took the GI Bill, and he's now a junior at Columbia University in New York. And I saw his journey very recently and a lot of the flaws in the system. +And so I just knew that this problem wasn't going anywhere. And I knew that I really, really wanted to be a part of the solution. And I think unfortunately, our generation is taught that you're supposed to turn 50 and be rich before you start giving back and before you, whatever, consider building a non-profit, and I sort of call bullshit on that, to be honest. +I think I will never be more proximate to the problems I'm trying to solve than I am right now. And I'm 30 years old. I'm seven, eight years out of school, but I still very, very intentionally stay close to the undergraduate ecosystem and understand what it takes and what the problems are with breaking into the industry right now. +So I think it was a combination of being a student of the problem, knowing the problem, knowing it exists, building confidence and desire to become a leader while I was at HBS. And third, COVID, just realizing that a lot of these problems were actually being exacerbated, and they were getting worse, not better. I'm sitting at HBS watching some of the smartest kids I know lose internships. And all I could think was, what does that mean for the Black community? What does that mean for Black undergrads who already don't have the internship that's high paying and kind of seasons through these types of things? +And so I wanted to do something about it. And I knew it was going to be bootstrapped. I knew I didn't have a million bucks to put towards it, but I knew I could put something together. And like I said, when I saw the demand for 500+ kids applying, I knew we had something. And in the last two years, we've done a lot and have a long way to go but are really excited about some of the things around the corner. +CHAD: That's great context. And so, how did you go from zero to something? +BRIAN: The first part was just surrounding myself with people that I thought wanted to be contributors and collaborators and building it, so that's both students and mentors, so building an operating board and people around us to help us do it. I can tell you the process of launching a 501(c)(3) is not fun, and it's not for the faint of heart dealing with the government. +And I caveat that by saying towards the end of the process, I almost appreciated how difficult it was because it forced me to get a lot of things in place that were not fun to put in place. And as a result, if I wasn't that serious about building this, I think I would have been paused multiple times throughout the journey. While it's a frustrating manual, kind of nasty process, I do think it's a filtering mechanism for the government. Because the last thing you want to do is allow corporations to give people money that they think is going somewhere good and then it not go somewhere good, so I definitely appreciate that. But yeah, the journey is not fun. +I think anything that's bootstrapped...I'm sure you've had plenty of guests on here that have experience at bootstrap companies. If you can't go out and raise $10 million like some of these seed companies on day one, well, then you can't hire five people, and you can't set up all of the right systems online that you want to someday. So I think that's another component that I just learned a ton from was how do we put the things in place to allow us to do this thoughtfully but not necessarily the things in place that we want to have in year three when now we have a 500k P&L and can flex into some different things and bring people on full time? +So it almost forced us to build a bare-bones mechanism that just went out and really focused on the product, really focused on is this something that Black undergraduate students need and want? And only very myopically focused on that in the early days. Because all of the other stuff, the infrastructure of a non-profit, the operating board, who we bring around, and what money we raise, none of that really matters if Black undergrads don't see it as valuable. +And so I very intentionally spent a lot of our time with the students and was very hands-on, still very hands-on. But really spent time getting feedback and gathering feedback from our first cohort around what are the things you love? What are the things we should change? Who are some of the speakers you wish you heard from? What are some of the ways we can engage you guys now that you have graduated? +It's been a fun journey. I'm learning a lot still. As you know, I run a venture capital fund alongside this. And so just finding ways for those two things to talk to each other and to support one another. We back predominantly underrepresented founders. And these founders come from the same ecosystems where our students come from. So it's a really unique opportunity to see synergies exist across the two things I'm building. +CHAD: As you were getting started with Takeoff, like you said, the most important thing was the students. So was there anything in particular that you did that you thought worked really well to let people know about this and spread the word? +BRIAN: Yeah, I'd say less so in season one, chapter one, whatever you want to call it. Less so in that season than last season. And so what I did is I really turned on our brand ambassador program SO taking the students who graduated from the first cohort and using them to push us into career development offices, help them share on their campuses. +We had 50 students, but it wasn't 20 from Harvard and 20 from Stanford. We probably had 35, maybe 40 schools represented where we had a few kids from a few different schools. But the network effects of allowing the students to go out, and there are 100 things on a job board at a school that people are trying to get access to these students. But there's not that many students actually advocating for the programs and saying, "Hey, I went through this, and it was valuable, and here's why it was valuable. And here's why you should go through it." +We have a ton of our students who are very proud of the program and share what we're building with other students. And I think that that was a really cool unlock because I think that's the most authentic way to get to know your customers is go through people who really have experienced what you're building and allow them to tell the story for you. +CHAD: You said you get 500 applications, 600 applications for the latest cohort, and you're choosing 50. How do you do that? +BRIAN: We use a couple of different filtering mechanisms, so the first is the application. So there are questions in there around why they would join the program, things like do you have another internship lined up? We tend to focus on kids who either couldn't get an internship or don't have a Goldman Sachs banking internship already lined up. We tend to find that they're just more absorbed by the program. They're more focused. +The second thing is there are a couple of questions around just what their aspiration is. I try to look for students who at least have spent some time thinking about who they want to be when they grow up. That doesn't mean you need to know. But oftentimes, if you're not curious or aspirational on your own, regardless of whether you have confidence, if you're not curious or aspirational on your own, it's very hard for me to elicit that in an eight-week program. +And so we really try to filter out the students that we think are excited about getting to the other side or are excited about breaking in or excited about challenging ceilings. That's a little harder to search for than did they fill out their LinkedIn? Did they submit their PDF the right way? So that's the second component. +The third component is honestly being very intentional about matching with our mentors. So I try to find mentors that are at least somewhat lined up with the ecosystems these students want to go to. So if I have someone that wants to break into product, I actually think it's super-valuable to get some of our friends that work at Facebook or some of our friends that work at Pinterest who are in product as their mentors, regardless of whether they work on a product-related research project. And so, using our mentors to guide that journey from 100 to 50 students to make sure that they all feel like they are getting someone that can really help advance them. +And it's funny; it's pretty incredible. At the end of the program, a lot of them will come and say, "I can't believe how similar I am to Tyler, or Stacey, or Rebecca." It's really incredible how connected they become. And I just like to say, "Oh yeah, I can't believe it too." +We are very intentional in the background on making that happen. But our mentors stick around with our advisors, and I hear two years later they are helping each other find a job. Or I'll get a picture of them out to brunch because they check in once a quarter. That's the stuff that just gets me super jacked up to keep doing it is recognizing that these people continue these relationships long after the fellowship program is over. +CHAD: And that's great and really shows one of the great things about programs like this, and you already alluded to it earlier, is that they compound. As more people go through it, the value of the overall program hopefully goes up. +BRIAN: That's right. +CHAD: So are there any interviews or anything as part of the process of getting? +BRIAN: There's not. That's new this year, which we're super excited about. The first two years were, again, really just us in the background making that happen. And I wouldn't have known what to interview for, to be completely honest. I think now I have just a better understanding of the type of student that succeeds in our program. I didn't entirely understand that before. And I think regardless of whether you're diverse yourself, I think there's implicit bias that comes with jumping on a Zoom with someone and seeing how they interact. And I don't know that those biases always lead you to the best candidate. +And so, I think we tried to take a thoughtful approach but didn't want to over-engineer the early days of building our cohorts. And we beta-tested a bunch of different stuff. So we had freshman, sophomore, junior, senior, and first-year out, as well as Harvard, Stanford, Arkansas State, two-year community college, really just the full gamut. There are 1.1 million Black undergrads in the country in every given year. +So finding students from all these different places and then kind of honing that in and figuring out, you know what? I think if you do this program right after your freshman or right after your sophomore year, it's super valuable. And it really sets you up to have that strong junior year internship because that's the one that matters. That's the one that changes your trajectory if you go get a good one. +And so just learning those types of things over the first two years, I think, really helped us hone in who we focus on, and why we focus on them, and what resources we provide for them. Because it just, again, it just helps us build that treadmill to really accelerate their trajectory into their young professional career. +CHAD: You mentioned undergrad, so the program is specifically focused on people in college going to a university of some kind. +BRIAN: It's specifically focused on Black undergraduate students. I struggled with this a little bit because there are a lot of people that need help. I grew up in some underprivileged ecosystems as well. And there were plenty of poor white kids that also should get this or underrepresented Latinos that I knew. And while I wanted to build that, I also knew there's just a lot of noise. There's a lot of resources and advice and people out there trying to help. And I kind of said to myself, "This is the demographic that I understand best." +And instead of pretending like I know how to build a platform to help someone from an ecosystem I don't truly understand break-in, I'm just going to focus all my effort on getting more people that look like me because I know that there's a need for that and know that there's a gap for that. And I know that historically, companies have not been good at doing that on their own. So that's been our focus. And I hope there's a day where we have the privilege to expand that horizon and spend time because we have the resources to do it. But for now, I still have a long way to go within the Black community. And I'm going to keep focusing our time there. +CHAD: Yeah, I was thinking more about the kids who aren't even getting the opportunity to go to college. So they're 1.1 million Black undergrads. There are probably even more people who don't even get the opportunity to go to college. There are so many people you could help with this. What are your goals for growth? And how do you serve more people? +BRIAN: Yeah, I'll tell you the one that's top of mine because we're super excited about it. And this hasn't been released to many places, and so for our lovely thoughtbot community, I'm super excited to share this early, but we're building something called Takeoff University. Takeoff University will be the largest resource repository in the world for Black undergraduate students. Again, I think that the positioning is Black undergraduate students. I don't think that there's a paywall set up where if you don't have a .edu you can't use it. And so, I'm still thinking about how we provide access for some of the people you're describing. +But regardless, the idea being our fellowship is very hands-on and very intentional, and specifically focused on accelerating 50 people a summer. But how can we build something that more effectively brings in anyone in their undergraduate ecosystem development? Whether you're a freshman, sophomore, junior, senior, how can we deliver resources to you and get you some of the things that we know you need at the time that you need them and allow you to more effectively become part of the Takeoff ecosystem? Because what we believe is we can build a pretty unique flywheel around the broader TakeOff University ecosystem and some of the content and curriculum and thought leadership and just sharing that can occur there. +I think a lot about our older students. When we talk to them about how they engage with younger students, it's oftentimes younger students are sent to them. So they have a classmate who says, "Hey, you should talk to this guy. He broke in, or he had an internship somewhere." And those students come, and one of the first things they ask is, "How do I do it? How do I become you? How do I do the thing you did?" +And I think for a lot of students, they don't have a good answer for that. It's hey, let me send you these 2009 PDFs that someone sent me on banking recruiting. Or "Hey, have you checked this out at the career development office?" But they don't send them to anywhere, at least in a concentrated manner. And that's really what got me excited about building Takeoff University was there is not a centralized resource repository where any and every Black undergraduate student should go to prepare themselves for their young professional journey. +And so some of the things that'll be a part of that are the first thing is you come in as a career exploratory quiz. You answer a bunch of questions on what you're interested in, what stage you are in your internship development, what stage you are in your academic tenure. And it just helps guide us towards some of the resources that we know you should look at. And it doesn't mean you can't spend time in the whole library but help us guide you in the early days. +And then from there, dynamic ways for students to engage, so building community and allowing them to share resources, ways for companies to engage. So allowing companies to come in and identify students that might be top candidates for their program. So really just building an inclusive ecosystem for Black undergrads where they can come and know that they'll give valuable resources. And so we're really excited. We have some really cool things in the oven around this and excited to launch it to the world later this year. +CHAD: That's great. What would it take for you to grow from 50 fellows to 100? And is that something that you want to do? +BRIAN: Definitely. If you had used the number 500, I might have paused. [laughter] Again, 50 was like, get it right, do it right. I have 100 kids. I don't want to speak for all of them, but I have a lot of students that love what we did over their summer and really shout it from the rooftops to their community. And that means a lot to us. +And I'm not entirely sure that if it had been 100 and then 100 that I'd have 200 students who shout that. I think we were able to build a very intimate and hands-on experience for our first two cohorts. And as we grow, and as we introduce technology, and platform, and resources, I think there are ways for us to expand the number without getting out over our skis. +And so 100 is in a very near-term goal for us. I'm not sure that it goes much past that. I think instead, like I described with Takeoff University, we start introducing other opportunities. We start putting more things under the Takeoff Institute umbrella. I think a lot like the Aspen Institute. There are so many different ecosystems and community-building efforts going on underneath the larger umbrella. And so long as Takeoff Institute is known as just advancing opportunities, I think we can build a ton of cool ways to have touchpoints with students across the country. +CHAD: Are there specific blockers you would identify? Or you have an attentive audience here, are there things you would ask for to get to that 100 fellows? +BRIAN: It's a great question. I think folks that have had any experience building, you know, call it Twitter University, Pinterest University, Plaid University, folks who have been on the internal teams that help stand up curriculum and training for employees, again, that's a large part of what we're standing up with TakeOff University. And I'm very, very fortunate to have the funding now and not be in a place where we're looking for money to do that. +And so we have the resources to make this really special, and just getting some of the design and product folks that might be listening who might be interested in helping build a community like the one that we're building, we'd appreciate it. We'd love to chat. You can email me at brian@takeoffinstitute.com. I'd love to chat and learn. And even if you don't have time to chat, if there are platforms that you know that look really cool and look like the type of thing that we should be mocking or mimicking, I think it's always helpful to see comparisons and benchmarks. So I think that that'd be a great one. +And the other thing I'd add is if you want to be a mentor, please apply, takeoffinstitute.com. It's an incredible experience. I wish I could say I had 100 advisors, but I probably only have 60 because most of the ones who did the first cohort did the second cohort. And they loved it, and they're doing the third cohort. It's an hour a week. It's a very light touch, eight weeks of the summer. It's a very light touch, but I think it's impactful. So we'd love to have some of the folks. +CHAD: Do you specifically look for Black mentors? +BRIAN: We don't. We don't. I think that that's a really important part of this experience. Like I mentioned, you don't get to choose who your direct report is. And so your direct report might be White, Asian, Black. I don't care what they are. You need to get used to having that direct report experience and building rapport, and building that relationship regardless of what they look like. And so we appreciate having mentors that are male, female, and come from all different walks of life. +CHAD: Great. And that website again was? +BRIAN: www.takeoffinstitute.com +CHAD: Awesome. Well, I think that's a very natural and great place to leave it. I hope folks will contact you and get involved. And there's so much work to be done in this area. And it's a great opportunity to have an impact. +BRIAN: Yeah. Thanks for having me, Chad. +CHAD: Thank you. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +Brian, if folks want to get in touch with you, you want to say your email again and any other channels they should do that? +BRIAN: Yeah, perfect. brian@takeoffinstitute.com. And you can find me on Twitter @BHolls1, B-H-O-L-L-S-1. +CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Brian Hollins. + + + Brian Hollins is the Founder of the Takeoff Institute and Founding Managing Partner of Collide Capital. The Takeoff Institute is focused on equipping Black undergrads with the resources and mentorship they need to build a young professional career.

+ +

Chad talks with Brian about providing students with necessary skills like etiquette and polish to break into Tesla and McKinsey-level companies and facilitating facetime, communication, and mentorship with other Black people within those companies who are at executive levels.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Brian Hollins, Founder of the Takeoff Institute and Founding Managing Partner of Collide Capital. Brian, thanks for joining me.

+ +

BRIAN: Chad, I'm pumped to do this. Thanks for having me.

+ +

CHAD: So you are obviously the Founder of the Takeoff Institute. So let's start there. Why don't we give folks a brief overview of what the Takeoff Institute is, and then we'll dive right in?

+ +

BRIAN: Absolutely. Happy Black History Month. Let's start there. I'm a Black undergraduate student in the past, and I'm building something for Black undergraduate students today. So Takeoff Institute is focused on equipping Black undergrads with the resources and mentorship they need to build a young professional career. I was lucky enough to go to Stanford for undergrad and almost get thrown over the wall, if you will, by mentors and people that could advise me as I broke into my young professional career. And I, unfortunately, noticed that that wasn't the same for a lot of other folks.

+ +

I ran diversity recruiting at Goldman Sachs for a few years and just saw some of the mistakes and little things that people who don't have advisors, people who don't have mentors, people who don't have an older brother in private equity. I saw the mistakes they were making and knew I wanted to build something to help bridge that gap.

+ +

So we focus on providing the types of things that I think you need to break into a Goldman Sachs or a Tesla or a Facebook or a McKinsey today that might not have been true five years ago. And unfortunately, I think a lot of career development offices and programs out there are helping students break into a job that doesn't exist anymore, and that's more focused on some of the skills that we've tried to tap into.

+ +

CHAD: And what are those skills?

+ +

BRIAN: I'll point to a few off the top of my head. One is just polish. If you've never had an internship, you don't know cadencing on scheduling or sending an email to a direct report or really focusing on your LinkedIn, and your resume, and your social media being clean and disciplined. And so we bring to light a lot of the things that I think employers are looking for today. I'll use a good example with our students. If you don't have 500 connections on LinkedIn, the number of connections you have shows. But if you have more than 500 connections, it just shows 500+.

+ +

And as a recruiter, when you really think about it, at the top of the funnel, they use these little things to guide a lot of their decision-making. For better or worse, I'm not sure it's a great way to decide who should be a good candidate for your company. But when you get 5,000 applications, and you need to get it down to 100 in a couple of days, there are little things like sending your resume in a Word Doc instead of a PDF or having spelling errors in your application, or not filling out some of the boxes that matter. And so we really train them on that etiquette and polish.

+ +

Another bucket that I think is super important we built a speaker series at the Takeoff Institute called You Can't Be What You Can't See. And I think for a lot of Black undergraduate students, you go through a Superday at some of these places. You might meet 10, 15 people. Most of the time, you're not going to meet anyone Black. And you're definitely not going to meet Black people that are at the executive level.

+ +

And so we really pride ourselves on bringing in managing directors from banks, and founders and CEOs from growing companies, and leading venture capitalist investors and just help our students see that there are people out there doing what they did. There are people that come from their backgrounds that also weren't sure who they were going to be when they were a sophomore or a junior in college. And so, building confidence is another key pillar of the program that we really pride ourselves on.

+ +

And we're very lucky we have students at Tesla, at Apple, at Facebook, at Goldman, at NBC Universal. These students have broken into really exciting roles. And as we think about building the full flywheel around Takeoff, now those students become advocates. Now those students become mentors and advisors. And we build proximity for our students to help them realize there are people that very recently went through a very similar program and are now doing the things that they aspire to do.

+ +

CHAD: That's great. It sounds to me like it really is a combination of things that they might not have the opportunity to have done before or gain the experience and because they're marginalized, historically. And also just things that are good to have that, in general, aren't taught in school regardless of your opportunity.

+ +

BRIAN: That's right.

+ +

CHAD: And sometimes people who have more opportunity are getting that exposure in the jobs that they have along the way and that kind of thing. That makes it certainly easier for them to succeed later on, let alone what they look like when they show up to the interview.

+ +

BRIAN: Yeah, I completely agree. And I think the anecdotal use there is most of the things that I'm teaching these kids you can find on Google. The problem is they don't know what to look for. And when we think about fast-tracking these students or getting them into these rooms quicker, getting them through those interviews more effectively, it's almost like bringing all of these resources right in front of their face and allowing them to soak and absorb them in a very efficient manner.

+ +

So there's a guide somewhere on the internet of how to break into consulting, and there's a guide on how to crush a product interview. And there's a guide on how to build a perfect resume or a perfect LinkedIn. But we find that most of our students, one, don't know that they should be looking for that stuff, and two, don't know how to go get it all when it matters. And that's really what we focus on, bringing all that stuff in front of them at a more efficient clip and help them build that confidence so that when they do get in front of that interview, they're armed with all the things they need to succeed.

+ +

CHAD: Well, I know you're already solving a big problem. But is there anything in particular that you do to then make sure that once these people are in the workforce, in the workplace, they're going to companies that are going to treat them right where they're not going to face bias as much as possible and those kinds of things? Or are you mostly focused on getting them ready right now?

+ +

BRIAN: No, it's a great question. I'd put that in a 2.0 Takeoff University, Takeoff Institute, but it's absolutely critical. It's super important. And we have a long way to go. Chad, I don't want to pretend like the world is ten times better than it was five years ago. But the transparency through which some of this data is being recorded, the accountability that's being held in rooms that matter, so C-suite, executive suite, board meetings, it is changing. And I'm very excited about that because I think for the students that can, and this is in every student, and I don't want to pretend like it is, but for the students that can choose where they go, they're going to choose to go to those companies.

+ +

They're going to choose to go to the companies where there is active, positive feedback from underrepresented people, so Black, Latin, female, people that don't look like the rich, white guy that runs the company. They're going to look for that feedback. And they're going to look for companies that very, very clearly advocate for supporting those types of communities.

+ +

And, again, I think we're in the early innings of that. But I think that we're definitely on a path towards that being more and more important and that tailors who we partner with and who we spend time with. And if you look at a lot of our partners, they are people that care about that stuff, and they are people that are actively working on doing something about it, which we certainly appreciate.

+ +

CHAD: So the core of the Takeoff Institute is the fellowship. Is that right?

+ +

BRIAN: Yeah, that's right.

+ +

CHAD: What exactly is that?

+ +

BRIAN: The Takeoff Institute Summer Fellowship is an eight-week program, again, designed to advance and equip Black undergraduates with the resources and mentorship they need to launch a young professional career. So the first thing that I think about is what we had talked about earlier, just aggregation of resources.

+ +

So we have a partnership with Wall Street Prep, and so our students have to do an Excel and PowerPoint tutorial within the first two weeks of the program. And that's in after hours, and they have to do it on their own. And we track their progress, and they have to submit it. Because I cannot think of a single role in a post-undergraduate career where it is not important to be literate in both of those platforms and also, maybe more importantly, where top performers are not very good in both of those platforms. So the first piece is resource aggregation.

+ +

CHAD: And this is happening remotely?

+ +

BRIAN: This is all remote. This is all remote. I started the Takeoff Institute in 2020. Chad, I hope there's a day where I say that none of it is remote, but it's the world we live in.

+ +

CHAD: [laughs]

+ +

BRIAN: And it's what allowed us to scale it the way we did. We had over 500 kids apply for our first fellowship two years ago. We took 50 and had a little over 600 apply for the second year and took 50 again last summer and have some really exciting things coming up for this summer. So we can talk about the goal and where we're headed later. But the second piece is the speaker series that I told you about. And so, bringing in folks during our weekly meetings and allowing them to ask questions and be vulnerable and share that experience.

+ +

The third piece is mentorship. And so, I wanted to recreate the feeling of having a direct report. I think too many Black undergrads get to their first job without any real internship experience. And I think in an internship, one of the things you do is you make a bunch of dumb mistakes where your direct report tells you they were dumb because you're an intern. And you check that box, like, whoops, I did that I'm never going to do it again.

+ +

And unfortunately, when you get to your first job, and that's some of the stuff you're doing early on, it just doesn't go well. It doesn't lead to you being ranked highly. It doesn't lead to you getting an offer a year later. It doesn't lead to you getting the advocacy and support of people internally to say that you're a top performer. So we almost try to recreate that direct report internship experience and allow them to make some of those mistakes.

+ +

And so every student is paired up with a one on one advisor. And so, for folks that are listening, if you want to be an advisor, I'd call it anywhere from 25 to 50-year-olds with a desire to help undergraduate students succeed. We have a variety of different types of advisors. And again, it's really about challenging our students to make sure they send the email to check-in.

+ +

They send the email to let them know that they need to meet. They send a calendar invite. And if it's in ET, they remember, oh wow, I need to send that in PT. So just giving them that experience. So resources, access to people that look like them in seats that matter, and mentorship and guidance are the three main pillars of the Takeoff Institute.

+ +

CHAD: I love that idea of learning from experiencing failure. One of the things as someone speaking for myself coming from a place of opportunity and privilege and being a white male, I might approach certain circumstances where I'm just not as afraid of failure. I'm a big believer in learning through failure, and so because of that, I'm less afraid of that. Someone who hasn't had that opportunity and is underrepresented might be much more scared of what might happen if they fail, and that's just missing the opportunity to do that.

+ +

BRIAN: I think you're absolutely right. And I want to, if you're open to it, have a little fun here. I'd love to flip that question on you and just think about what are some of the things that you would be sharing or guiding to underrepresented ecosystems to help them bridge that gap, to help them kind of get that confidence to know that they do have the right, they do have the skills; they do have the knowledge to break into those places? And it's about quieting that imposter syndrome and going after some of those opportunities.

+ +

CHAD: Yeah, I've always believed it's really difficult to tell people not to feel something that they're feeling. [laughs] It's really hard to change someone's feelings. And so I would put it on the mentors that they need to work to create the environment where people understand that it's okay to make mistakes. That's certainly the experience that I had in my internship when I was just getting started out. I saw my manager making mistakes, and they owned up to them. And we talked about them. And we were doing a lot of the same work. We were working alongside of each other. And so that close working relationship is one thing.

+ +

I don't know if you're aware, but at thoughtbot, we have an apprentice program where new people are paired with an experienced mentor, and it's almost entirely working together on work. So creating that opportunity. So assuming you have a mentor that's supportive and wants to work with you, great. And if not, I would say try to circumvent that as much as possible and get yourself working with them as much as possible so that you can get close to them and see them working, and see them failing, and really gain that first-hand experience, which in and of itself can be uncomfortable to force that. I totally recognize that.

+ +

BRIAN: Totally. Part of the program is they do a research report with their mentor. And so it's sort of this guided I'm here to answer questions, but I am not here to do this for you. And I'm very intentional with our mentors about that. I think a lot of these students, especially the ones who have never had a direct report, they wait until they're told what to do. And they don't know how to turn on that proactive brain. And I think it's a super important muscle to flex, especially at that age. How do you teach a kid to do the thing that he thinks his boss is going to ask for as opposed to the thing that his boss asked for?

+ +

CHAD: Well, this is sort of a pet peeve of mine because I think that, in some ways, there is a flaw in our educational system. It's centered around people telling people what to do.

+ +

BRIAN: Do what you're told, yeah, absolutely.

+ +

CHAD: Right. And so, I was very fortunate that I had some teachers that did more project-based learning and then chose to go to a college that was project-based. And the difference when you're in charge of something, and you're responsible, and people aren't telling you what to do, that really creates the environment where you can do that great work.

+ +

BRIAN: Totally. What's pretty cool is we keep a repository of all their presentations. And so, a lot of them, after the program is over they'll actually share their presentation on their LinkedIn or through their socials. And just having a body of work that early in your career, mapping the Esports competitive landscape, or how to build a D2C skincare business for people of color. I mean, really cool projects that they're very proud of, that they worked hard on, and now that they can share.

+ +

And, again, part of what we do is build that LinkedIn, build that thought leadership, help them become experts in their own craft because I think it builds that confidence that we just talked about missing for so many of them. And it's doing all these little things that really just unlock their inner self. I'm not giving them anything that they don't already have. I'm just unlocking it.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Let's take a step back. And I'm curious what it takes to start something like Takeoff Institute. How difficult is it to set up a non-profit? From when you decided to do this, what steps did you take as a founder getting off the ground?

+ +

BRIAN: I'll give you context of how I started it at first. I was a student at Harvard Business School. Nine months into my MBA program, the world blew up. And so what was a trip to Shenzhen or Tokyo turned into hanging out in my apartment. And I think similar to what you described around that participatory learning environment and how that helped you, HBS is known for what's called the case method. And the case method is a very, very powerful way to learn. It's, by far, in a way, my favorite way to learn. And I knew nothing about it before I got to HBS.

+ +

And the repeat experience of being presented a problem and having to choose a side and then gathering information after the fact around whether that was not necessarily right or wrong but whether that was educated or insightful and then repeating that process over and over again. You just learn a ton about your biases and the types of things that you can and can't accomplish on your own without thinking of other parts of your brain or using other kinds of tools in your toolbox.

+ +

And so I found myself really challenged after my first year of school, saying, I've never built anything, and I've never put my mind towards some of the problems that I think exist in the world. And I mentioned while I was at Goldman running diversity recruiting at Stanford for a couple of years, and I saw so many problems and flaws in that model. And then my youngest brother was a Marine. So he served in the military for four years and then took the GI Bill, and he's now a junior at Columbia University in New York. And I saw his journey very recently and a lot of the flaws in the system.

+ +

And so I just knew that this problem wasn't going anywhere. And I knew that I really, really wanted to be a part of the solution. And I think unfortunately, our generation is taught that you're supposed to turn 50 and be rich before you start giving back and before you, whatever, consider building a non-profit, and I sort of call bullshit on that, to be honest.

+ +

I think I will never be more proximate to the problems I'm trying to solve than I am right now. And I'm 30 years old. I'm seven, eight years out of school, but I still very, very intentionally stay close to the undergraduate ecosystem and understand what it takes and what the problems are with breaking into the industry right now.

+ +

So I think it was a combination of being a student of the problem, knowing the problem, knowing it exists, building confidence and desire to become a leader while I was at HBS. And third, COVID, just realizing that a lot of these problems were actually being exacerbated, and they were getting worse, not better. I'm sitting at HBS watching some of the smartest kids I know lose internships. And all I could think was, what does that mean for the Black community? What does that mean for Black undergrads who already don't have the internship that's high paying and kind of seasons through these types of things?

+ +

And so I wanted to do something about it. And I knew it was going to be bootstrapped. I knew I didn't have a million bucks to put towards it, but I knew I could put something together. And like I said, when I saw the demand for 500+ kids applying, I knew we had something. And in the last two years, we've done a lot and have a long way to go but are really excited about some of the things around the corner.

+ +

CHAD: That's great context. And so, how did you go from zero to something?

+ +

BRIAN: The first part was just surrounding myself with people that I thought wanted to be contributors and collaborators and building it, so that's both students and mentors, so building an operating board and people around us to help us do it. I can tell you the process of launching a 501(c)(3) is not fun, and it's not for the faint of heart dealing with the government.

+ +

And I caveat that by saying towards the end of the process, I almost appreciated how difficult it was because it forced me to get a lot of things in place that were not fun to put in place. And as a result, if I wasn't that serious about building this, I think I would have been paused multiple times throughout the journey. While it's a frustrating manual, kind of nasty process, I do think it's a filtering mechanism for the government. Because the last thing you want to do is allow corporations to give people money that they think is going somewhere good and then it not go somewhere good, so I definitely appreciate that. But yeah, the journey is not fun.

+ +

I think anything that's bootstrapped...I'm sure you've had plenty of guests on here that have experience at bootstrap companies. If you can't go out and raise $10 million like some of these seed companies on day one, well, then you can't hire five people, and you can't set up all of the right systems online that you want to someday. So I think that's another component that I just learned a ton from was how do we put the things in place to allow us to do this thoughtfully but not necessarily the things in place that we want to have in year three when now we have a 500k P&L and can flex into some different things and bring people on full time?

+ +

So it almost forced us to build a bare-bones mechanism that just went out and really focused on the product, really focused on is this something that Black undergraduate students need and want? And only very myopically focused on that in the early days. Because all of the other stuff, the infrastructure of a non-profit, the operating board, who we bring around, and what money we raise, none of that really matters if Black undergrads don't see it as valuable.

+ +

And so I very intentionally spent a lot of our time with the students and was very hands-on, still very hands-on. But really spent time getting feedback and gathering feedback from our first cohort around what are the things you love? What are the things we should change? Who are some of the speakers you wish you heard from? What are some of the ways we can engage you guys now that you have graduated?

+ +

It's been a fun journey. I'm learning a lot still. As you know, I run a venture capital fund alongside this. And so just finding ways for those two things to talk to each other and to support one another. We back predominantly underrepresented founders. And these founders come from the same ecosystems where our students come from. So it's a really unique opportunity to see synergies exist across the two things I'm building.

+ +

CHAD: As you were getting started with Takeoff, like you said, the most important thing was the students. So was there anything in particular that you did that you thought worked really well to let people know about this and spread the word?

+ +

BRIAN: Yeah, I'd say less so in season one, chapter one, whatever you want to call it. Less so in that season than last season. And so what I did is I really turned on our brand ambassador program SO taking the students who graduated from the first cohort and using them to push us into career development offices, help them share on their campuses.

+ +

We had 50 students, but it wasn't 20 from Harvard and 20 from Stanford. We probably had 35, maybe 40 schools represented where we had a few kids from a few different schools. But the network effects of allowing the students to go out, and there are 100 things on a job board at a school that people are trying to get access to these students. But there's not that many students actually advocating for the programs and saying, "Hey, I went through this, and it was valuable, and here's why it was valuable. And here's why you should go through it."

+ +

We have a ton of our students who are very proud of the program and share what we're building with other students. And I think that that was a really cool unlock because I think that's the most authentic way to get to know your customers is go through people who really have experienced what you're building and allow them to tell the story for you.

+ +

CHAD: You said you get 500 applications, 600 applications for the latest cohort, and you're choosing 50. How do you do that?

+ +

BRIAN: We use a couple of different filtering mechanisms, so the first is the application. So there are questions in there around why they would join the program, things like do you have another internship lined up? We tend to focus on kids who either couldn't get an internship or don't have a Goldman Sachs banking internship already lined up. We tend to find that they're just more absorbed by the program. They're more focused.

+ +

The second thing is there are a couple of questions around just what their aspiration is. I try to look for students who at least have spent some time thinking about who they want to be when they grow up. That doesn't mean you need to know. But oftentimes, if you're not curious or aspirational on your own, regardless of whether you have confidence, if you're not curious or aspirational on your own, it's very hard for me to elicit that in an eight-week program.

+ +

And so we really try to filter out the students that we think are excited about getting to the other side or are excited about breaking in or excited about challenging ceilings. That's a little harder to search for than did they fill out their LinkedIn? Did they submit their PDF the right way? So that's the second component.

+ +

The third component is honestly being very intentional about matching with our mentors. So I try to find mentors that are at least somewhat lined up with the ecosystems these students want to go to. So if I have someone that wants to break into product, I actually think it's super-valuable to get some of our friends that work at Facebook or some of our friends that work at Pinterest who are in product as their mentors, regardless of whether they work on a product-related research project. And so, using our mentors to guide that journey from 100 to 50 students to make sure that they all feel like they are getting someone that can really help advance them.

+ +

And it's funny; it's pretty incredible. At the end of the program, a lot of them will come and say, "I can't believe how similar I am to Tyler, or Stacey, or Rebecca." It's really incredible how connected they become. And I just like to say, "Oh yeah, I can't believe it too."

+ +

We are very intentional in the background on making that happen. But our mentors stick around with our advisors, and I hear two years later they are helping each other find a job. Or I'll get a picture of them out to brunch because they check in once a quarter. That's the stuff that just gets me super jacked up to keep doing it is recognizing that these people continue these relationships long after the fellowship program is over.

+ +

CHAD: And that's great and really shows one of the great things about programs like this, and you already alluded to it earlier, is that they compound. As more people go through it, the value of the overall program hopefully goes up.

+ +

BRIAN: That's right.

+ +

CHAD: So are there any interviews or anything as part of the process of getting?

+ +

BRIAN: There's not. That's new this year, which we're super excited about. The first two years were, again, really just us in the background making that happen. And I wouldn't have known what to interview for, to be completely honest. I think now I have just a better understanding of the type of student that succeeds in our program. I didn't entirely understand that before. And I think regardless of whether you're diverse yourself, I think there's implicit bias that comes with jumping on a Zoom with someone and seeing how they interact. And I don't know that those biases always lead you to the best candidate.

+ +

And so, I think we tried to take a thoughtful approach but didn't want to over-engineer the early days of building our cohorts. And we beta-tested a bunch of different stuff. So we had freshman, sophomore, junior, senior, and first-year out, as well as Harvard, Stanford, Arkansas State, two-year community college, really just the full gamut. There are 1.1 million Black undergrads in the country in every given year.

+ +

So finding students from all these different places and then kind of honing that in and figuring out, you know what? I think if you do this program right after your freshman or right after your sophomore year, it's super valuable. And it really sets you up to have that strong junior year internship because that's the one that matters. That's the one that changes your trajectory if you go get a good one.

+ +

And so just learning those types of things over the first two years, I think, really helped us hone in who we focus on, and why we focus on them, and what resources we provide for them. Because it just, again, it just helps us build that treadmill to really accelerate their trajectory into their young professional career.

+ +

CHAD: You mentioned undergrad, so the program is specifically focused on people in college going to a university of some kind.

+ +

BRIAN: It's specifically focused on Black undergraduate students. I struggled with this a little bit because there are a lot of people that need help. I grew up in some underprivileged ecosystems as well. And there were plenty of poor white kids that also should get this or underrepresented Latinos that I knew. And while I wanted to build that, I also knew there's just a lot of noise. There's a lot of resources and advice and people out there trying to help. And I kind of said to myself, "This is the demographic that I understand best."

+ +

And instead of pretending like I know how to build a platform to help someone from an ecosystem I don't truly understand break-in, I'm just going to focus all my effort on getting more people that look like me because I know that there's a need for that and know that there's a gap for that. And I know that historically, companies have not been good at doing that on their own. So that's been our focus. And I hope there's a day where we have the privilege to expand that horizon and spend time because we have the resources to do it. But for now, I still have a long way to go within the Black community. And I'm going to keep focusing our time there.

+ +

CHAD: Yeah, I was thinking more about the kids who aren't even getting the opportunity to go to college. So they're 1.1 million Black undergrads. There are probably even more people who don't even get the opportunity to go to college. There are so many people you could help with this. What are your goals for growth? And how do you serve more people?

+ +

BRIAN: Yeah, I'll tell you the one that's top of mine because we're super excited about it. And this hasn't been released to many places, and so for our lovely thoughtbot community, I'm super excited to share this early, but we're building something called Takeoff University. Takeoff University will be the largest resource repository in the world for Black undergraduate students. Again, I think that the positioning is Black undergraduate students. I don't think that there's a paywall set up where if you don't have a .edu you can't use it. And so, I'm still thinking about how we provide access for some of the people you're describing.

+ +

But regardless, the idea being our fellowship is very hands-on and very intentional, and specifically focused on accelerating 50 people a summer. But how can we build something that more effectively brings in anyone in their undergraduate ecosystem development? Whether you're a freshman, sophomore, junior, senior, how can we deliver resources to you and get you some of the things that we know you need at the time that you need them and allow you to more effectively become part of the Takeoff ecosystem? Because what we believe is we can build a pretty unique flywheel around the broader TakeOff University ecosystem and some of the content and curriculum and thought leadership and just sharing that can occur there.

+ +

I think a lot about our older students. When we talk to them about how they engage with younger students, it's oftentimes younger students are sent to them. So they have a classmate who says, "Hey, you should talk to this guy. He broke in, or he had an internship somewhere." And those students come, and one of the first things they ask is, "How do I do it? How do I become you? How do I do the thing you did?"

+ +

And I think for a lot of students, they don't have a good answer for that. It's hey, let me send you these 2009 PDFs that someone sent me on banking recruiting. Or "Hey, have you checked this out at the career development office?" But they don't send them to anywhere, at least in a concentrated manner. And that's really what got me excited about building Takeoff University was there is not a centralized resource repository where any and every Black undergraduate student should go to prepare themselves for their young professional journey.

+ +

And so some of the things that'll be a part of that are the first thing is you come in as a career exploratory quiz. You answer a bunch of questions on what you're interested in, what stage you are in your internship development, what stage you are in your academic tenure. And it just helps guide us towards some of the resources that we know you should look at. And it doesn't mean you can't spend time in the whole library but help us guide you in the early days.

+ +

And then from there, dynamic ways for students to engage, so building community and allowing them to share resources, ways for companies to engage. So allowing companies to come in and identify students that might be top candidates for their program. So really just building an inclusive ecosystem for Black undergrads where they can come and know that they'll give valuable resources. And so we're really excited. We have some really cool things in the oven around this and excited to launch it to the world later this year.

+ +

CHAD: That's great. What would it take for you to grow from 50 fellows to 100? And is that something that you want to do?

+ +

BRIAN: Definitely. If you had used the number 500, I might have paused. [laughter] Again, 50 was like, get it right, do it right. I have 100 kids. I don't want to speak for all of them, but I have a lot of students that love what we did over their summer and really shout it from the rooftops to their community. And that means a lot to us.

+ +

And I'm not entirely sure that if it had been 100 and then 100 that I'd have 200 students who shout that. I think we were able to build a very intimate and hands-on experience for our first two cohorts. And as we grow, and as we introduce technology, and platform, and resources, I think there are ways for us to expand the number without getting out over our skis.

+ +

And so 100 is in a very near-term goal for us. I'm not sure that it goes much past that. I think instead, like I described with Takeoff University, we start introducing other opportunities. We start putting more things under the Takeoff Institute umbrella. I think a lot like the Aspen Institute. There are so many different ecosystems and community-building efforts going on underneath the larger umbrella. And so long as Takeoff Institute is known as just advancing opportunities, I think we can build a ton of cool ways to have touchpoints with students across the country.

+ +

CHAD: Are there specific blockers you would identify? Or you have an attentive audience here, are there things you would ask for to get to that 100 fellows?

+ +

BRIAN: It's a great question. I think folks that have had any experience building, you know, call it Twitter University, Pinterest University, Plaid University, folks who have been on the internal teams that help stand up curriculum and training for employees, again, that's a large part of what we're standing up with TakeOff University. And I'm very, very fortunate to have the funding now and not be in a place where we're looking for money to do that.

+ +

And so we have the resources to make this really special, and just getting some of the design and product folks that might be listening who might be interested in helping build a community like the one that we're building, we'd appreciate it. We'd love to chat. You can email me at brian@takeoffinstitute.com. I'd love to chat and learn. And even if you don't have time to chat, if there are platforms that you know that look really cool and look like the type of thing that we should be mocking or mimicking, I think it's always helpful to see comparisons and benchmarks. So I think that that'd be a great one.

+ +

And the other thing I'd add is if you want to be a mentor, please apply, takeoffinstitute.com. It's an incredible experience. I wish I could say I had 100 advisors, but I probably only have 60 because most of the ones who did the first cohort did the second cohort. And they loved it, and they're doing the third cohort. It's an hour a week. It's a very light touch, eight weeks of the summer. It's a very light touch, but I think it's impactful. So we'd love to have some of the folks.

+ +

CHAD: Do you specifically look for Black mentors?

+ +

BRIAN: We don't. We don't. I think that that's a really important part of this experience. Like I mentioned, you don't get to choose who your direct report is. And so your direct report might be White, Asian, Black. I don't care what they are. You need to get used to having that direct report experience and building rapport, and building that relationship regardless of what they look like. And so we appreciate having mentors that are male, female, and come from all different walks of life.

+ +

CHAD: Great. And that website again was?

+ +

BRIAN: www.takeoffinstitute.com

+ +

CHAD: Awesome. Well, I think that's a very natural and great place to leave it. I hope folks will contact you and get involved. And there's so much work to be done in this area. And it's a great opportunity to have an impact.

+ +

BRIAN: Yeah. Thanks for having me, Chad.

+ +

CHAD: Thank you. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

Brian, if folks want to get in touch with you, you want to say your email again and any other channels they should do that?

+ +

BRIAN: Yeah, perfect. brian@takeoffinstitute.com. And you can find me on Twitter @BHolls1, B-H-O-L-L-S-1.

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Brian Hollins.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Brian Hollins is the Founder of the Takeoff Institute and Founding Managing Partner of Collide Capital. The Takeoff Institute is focused on equipping Black undergrads with the resources and mentorship they need to build a young professional career.

+ +

Chad talks with Brian about providing students with necessary skills like etiquette and polish to break into Tesla and McKinsey-level companies and facilitating facetime, communication, and mentorship with other Black people within those companies who are at executive levels.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Brian Hollins, Founder of the Takeoff Institute and Founding Managing Partner of Collide Capital. Brian, thanks for joining me.

+ +

BRIAN: Chad, I'm pumped to do this. Thanks for having me.

+ +

CHAD: So you are obviously the Founder of the Takeoff Institute. So let's start there. Why don't we give folks a brief overview of what the Takeoff Institute is, and then we'll dive right in?

+ +

BRIAN: Absolutely. Happy Black History Month. Let's start there. I'm a Black undergraduate student in the past, and I'm building something for Black undergraduate students today. So Takeoff Institute is focused on equipping Black undergrads with the resources and mentorship they need to build a young professional career. I was lucky enough to go to Stanford for undergrad and almost get thrown over the wall, if you will, by mentors and people that could advise me as I broke into my young professional career. And I, unfortunately, noticed that that wasn't the same for a lot of other folks.

+ +

I ran diversity recruiting at Goldman Sachs for a few years and just saw some of the mistakes and little things that people who don't have advisors, people who don't have mentors, people who don't have an older brother in private equity. I saw the mistakes they were making and knew I wanted to build something to help bridge that gap.

+ +

So we focus on providing the types of things that I think you need to break into a Goldman Sachs or a Tesla or a Facebook or a McKinsey today that might not have been true five years ago. And unfortunately, I think a lot of career development offices and programs out there are helping students break into a job that doesn't exist anymore, and that's more focused on some of the skills that we've tried to tap into.

+ +

CHAD: And what are those skills?

+ +

BRIAN: I'll point to a few off the top of my head. One is just polish. If you've never had an internship, you don't know cadencing on scheduling or sending an email to a direct report or really focusing on your LinkedIn, and your resume, and your social media being clean and disciplined. And so we bring to light a lot of the things that I think employers are looking for today. I'll use a good example with our students. If you don't have 500 connections on LinkedIn, the number of connections you have shows. But if you have more than 500 connections, it just shows 500+.

+ +

And as a recruiter, when you really think about it, at the top of the funnel, they use these little things to guide a lot of their decision-making. For better or worse, I'm not sure it's a great way to decide who should be a good candidate for your company. But when you get 5,000 applications, and you need to get it down to 100 in a couple of days, there are little things like sending your resume in a Word Doc instead of a PDF or having spelling errors in your application, or not filling out some of the boxes that matter. And so we really train them on that etiquette and polish.

+ +

Another bucket that I think is super important we built a speaker series at the Takeoff Institute called You Can't Be What You Can't See. And I think for a lot of Black undergraduate students, you go through a Superday at some of these places. You might meet 10, 15 people. Most of the time, you're not going to meet anyone Black. And you're definitely not going to meet Black people that are at the executive level.

+ +

And so we really pride ourselves on bringing in managing directors from banks, and founders and CEOs from growing companies, and leading venture capitalist investors and just help our students see that there are people out there doing what they did. There are people that come from their backgrounds that also weren't sure who they were going to be when they were a sophomore or a junior in college. And so, building confidence is another key pillar of the program that we really pride ourselves on.

+ +

And we're very lucky we have students at Tesla, at Apple, at Facebook, at Goldman, at NBC Universal. These students have broken into really exciting roles. And as we think about building the full flywheel around Takeoff, now those students become advocates. Now those students become mentors and advisors. And we build proximity for our students to help them realize there are people that very recently went through a very similar program and are now doing the things that they aspire to do.

+ +

CHAD: That's great. It sounds to me like it really is a combination of things that they might not have the opportunity to have done before or gain the experience and because they're marginalized, historically. And also just things that are good to have that, in general, aren't taught in school regardless of your opportunity.

+ +

BRIAN: That's right.

+ +

CHAD: And sometimes people who have more opportunity are getting that exposure in the jobs that they have along the way and that kind of thing. That makes it certainly easier for them to succeed later on, let alone what they look like when they show up to the interview.

+ +

BRIAN: Yeah, I completely agree. And I think the anecdotal use there is most of the things that I'm teaching these kids you can find on Google. The problem is they don't know what to look for. And when we think about fast-tracking these students or getting them into these rooms quicker, getting them through those interviews more effectively, it's almost like bringing all of these resources right in front of their face and allowing them to soak and absorb them in a very efficient manner.

+ +

So there's a guide somewhere on the internet of how to break into consulting, and there's a guide on how to crush a product interview. And there's a guide on how to build a perfect resume or a perfect LinkedIn. But we find that most of our students, one, don't know that they should be looking for that stuff, and two, don't know how to go get it all when it matters. And that's really what we focus on, bringing all that stuff in front of them at a more efficient clip and help them build that confidence so that when they do get in front of that interview, they're armed with all the things they need to succeed.

+ +

CHAD: Well, I know you're already solving a big problem. But is there anything in particular that you do to then make sure that once these people are in the workforce, in the workplace, they're going to companies that are going to treat them right where they're not going to face bias as much as possible and those kinds of things? Or are you mostly focused on getting them ready right now?

+ +

BRIAN: No, it's a great question. I'd put that in a 2.0 Takeoff University, Takeoff Institute, but it's absolutely critical. It's super important. And we have a long way to go. Chad, I don't want to pretend like the world is ten times better than it was five years ago. But the transparency through which some of this data is being recorded, the accountability that's being held in rooms that matter, so C-suite, executive suite, board meetings, it is changing. And I'm very excited about that because I think for the students that can, and this is in every student, and I don't want to pretend like it is, but for the students that can choose where they go, they're going to choose to go to those companies.

+ +

They're going to choose to go to the companies where there is active, positive feedback from underrepresented people, so Black, Latin, female, people that don't look like the rich, white guy that runs the company. They're going to look for that feedback. And they're going to look for companies that very, very clearly advocate for supporting those types of communities.

+ +

And, again, I think we're in the early innings of that. But I think that we're definitely on a path towards that being more and more important and that tailors who we partner with and who we spend time with. And if you look at a lot of our partners, they are people that care about that stuff, and they are people that are actively working on doing something about it, which we certainly appreciate.

+ +

CHAD: So the core of the Takeoff Institute is the fellowship. Is that right?

+ +

BRIAN: Yeah, that's right.

+ +

CHAD: What exactly is that?

+ +

BRIAN: The Takeoff Institute Summer Fellowship is an eight-week program, again, designed to advance and equip Black undergraduates with the resources and mentorship they need to launch a young professional career. So the first thing that I think about is what we had talked about earlier, just aggregation of resources.

+ +

So we have a partnership with Wall Street Prep, and so our students have to do an Excel and PowerPoint tutorial within the first two weeks of the program. And that's in after hours, and they have to do it on their own. And we track their progress, and they have to submit it. Because I cannot think of a single role in a post-undergraduate career where it is not important to be literate in both of those platforms and also, maybe more importantly, where top performers are not very good in both of those platforms. So the first piece is resource aggregation.

+ +

CHAD: And this is happening remotely?

+ +

BRIAN: This is all remote. This is all remote. I started the Takeoff Institute in 2020. Chad, I hope there's a day where I say that none of it is remote, but it's the world we live in.

+ +

CHAD: [laughs]

+ +

BRIAN: And it's what allowed us to scale it the way we did. We had over 500 kids apply for our first fellowship two years ago. We took 50 and had a little over 600 apply for the second year and took 50 again last summer and have some really exciting things coming up for this summer. So we can talk about the goal and where we're headed later. But the second piece is the speaker series that I told you about. And so, bringing in folks during our weekly meetings and allowing them to ask questions and be vulnerable and share that experience.

+ +

The third piece is mentorship. And so, I wanted to recreate the feeling of having a direct report. I think too many Black undergrads get to their first job without any real internship experience. And I think in an internship, one of the things you do is you make a bunch of dumb mistakes where your direct report tells you they were dumb because you're an intern. And you check that box, like, whoops, I did that I'm never going to do it again.

+ +

And unfortunately, when you get to your first job, and that's some of the stuff you're doing early on, it just doesn't go well. It doesn't lead to you being ranked highly. It doesn't lead to you getting an offer a year later. It doesn't lead to you getting the advocacy and support of people internally to say that you're a top performer. So we almost try to recreate that direct report internship experience and allow them to make some of those mistakes.

+ +

And so every student is paired up with a one on one advisor. And so, for folks that are listening, if you want to be an advisor, I'd call it anywhere from 25 to 50-year-olds with a desire to help undergraduate students succeed. We have a variety of different types of advisors. And again, it's really about challenging our students to make sure they send the email to check-in.

+ +

They send the email to let them know that they need to meet. They send a calendar invite. And if it's in ET, they remember, oh wow, I need to send that in PT. So just giving them that experience. So resources, access to people that look like them in seats that matter, and mentorship and guidance are the three main pillars of the Takeoff Institute.

+ +

CHAD: I love that idea of learning from experiencing failure. One of the things as someone speaking for myself coming from a place of opportunity and privilege and being a white male, I might approach certain circumstances where I'm just not as afraid of failure. I'm a big believer in learning through failure, and so because of that, I'm less afraid of that. Someone who hasn't had that opportunity and is underrepresented might be much more scared of what might happen if they fail, and that's just missing the opportunity to do that.

+ +

BRIAN: I think you're absolutely right. And I want to, if you're open to it, have a little fun here. I'd love to flip that question on you and just think about what are some of the things that you would be sharing or guiding to underrepresented ecosystems to help them bridge that gap, to help them kind of get that confidence to know that they do have the right, they do have the skills; they do have the knowledge to break into those places? And it's about quieting that imposter syndrome and going after some of those opportunities.

+ +

CHAD: Yeah, I've always believed it's really difficult to tell people not to feel something that they're feeling. [laughs] It's really hard to change someone's feelings. And so I would put it on the mentors that they need to work to create the environment where people understand that it's okay to make mistakes. That's certainly the experience that I had in my internship when I was just getting started out. I saw my manager making mistakes, and they owned up to them. And we talked about them. And we were doing a lot of the same work. We were working alongside of each other. And so that close working relationship is one thing.

+ +

I don't know if you're aware, but at thoughtbot, we have an apprentice program where new people are paired with an experienced mentor, and it's almost entirely working together on work. So creating that opportunity. So assuming you have a mentor that's supportive and wants to work with you, great. And if not, I would say try to circumvent that as much as possible and get yourself working with them as much as possible so that you can get close to them and see them working, and see them failing, and really gain that first-hand experience, which in and of itself can be uncomfortable to force that. I totally recognize that.

+ +

BRIAN: Totally. Part of the program is they do a research report with their mentor. And so it's sort of this guided I'm here to answer questions, but I am not here to do this for you. And I'm very intentional with our mentors about that. I think a lot of these students, especially the ones who have never had a direct report, they wait until they're told what to do. And they don't know how to turn on that proactive brain. And I think it's a super important muscle to flex, especially at that age. How do you teach a kid to do the thing that he thinks his boss is going to ask for as opposed to the thing that his boss asked for?

+ +

CHAD: Well, this is sort of a pet peeve of mine because I think that, in some ways, there is a flaw in our educational system. It's centered around people telling people what to do.

+ +

BRIAN: Do what you're told, yeah, absolutely.

+ +

CHAD: Right. And so, I was very fortunate that I had some teachers that did more project-based learning and then chose to go to a college that was project-based. And the difference when you're in charge of something, and you're responsible, and people aren't telling you what to do, that really creates the environment where you can do that great work.

+ +

BRIAN: Totally. What's pretty cool is we keep a repository of all their presentations. And so, a lot of them, after the program is over they'll actually share their presentation on their LinkedIn or through their socials. And just having a body of work that early in your career, mapping the Esports competitive landscape, or how to build a D2C skincare business for people of color. I mean, really cool projects that they're very proud of, that they worked hard on, and now that they can share.

+ +

And, again, part of what we do is build that LinkedIn, build that thought leadership, help them become experts in their own craft because I think it builds that confidence that we just talked about missing for so many of them. And it's doing all these little things that really just unlock their inner self. I'm not giving them anything that they don't already have. I'm just unlocking it.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Let's take a step back. And I'm curious what it takes to start something like Takeoff Institute. How difficult is it to set up a non-profit? From when you decided to do this, what steps did you take as a founder getting off the ground?

+ +

BRIAN: I'll give you context of how I started it at first. I was a student at Harvard Business School. Nine months into my MBA program, the world blew up. And so what was a trip to Shenzhen or Tokyo turned into hanging out in my apartment. And I think similar to what you described around that participatory learning environment and how that helped you, HBS is known for what's called the case method. And the case method is a very, very powerful way to learn. It's, by far, in a way, my favorite way to learn. And I knew nothing about it before I got to HBS.

+ +

And the repeat experience of being presented a problem and having to choose a side and then gathering information after the fact around whether that was not necessarily right or wrong but whether that was educated or insightful and then repeating that process over and over again. You just learn a ton about your biases and the types of things that you can and can't accomplish on your own without thinking of other parts of your brain or using other kinds of tools in your toolbox.

+ +

And so I found myself really challenged after my first year of school, saying, I've never built anything, and I've never put my mind towards some of the problems that I think exist in the world. And I mentioned while I was at Goldman running diversity recruiting at Stanford for a couple of years, and I saw so many problems and flaws in that model. And then my youngest brother was a Marine. So he served in the military for four years and then took the GI Bill, and he's now a junior at Columbia University in New York. And I saw his journey very recently and a lot of the flaws in the system.

+ +

And so I just knew that this problem wasn't going anywhere. And I knew that I really, really wanted to be a part of the solution. And I think unfortunately, our generation is taught that you're supposed to turn 50 and be rich before you start giving back and before you, whatever, consider building a non-profit, and I sort of call bullshit on that, to be honest.

+ +

I think I will never be more proximate to the problems I'm trying to solve than I am right now. And I'm 30 years old. I'm seven, eight years out of school, but I still very, very intentionally stay close to the undergraduate ecosystem and understand what it takes and what the problems are with breaking into the industry right now.

+ +

So I think it was a combination of being a student of the problem, knowing the problem, knowing it exists, building confidence and desire to become a leader while I was at HBS. And third, COVID, just realizing that a lot of these problems were actually being exacerbated, and they were getting worse, not better. I'm sitting at HBS watching some of the smartest kids I know lose internships. And all I could think was, what does that mean for the Black community? What does that mean for Black undergrads who already don't have the internship that's high paying and kind of seasons through these types of things?

+ +

And so I wanted to do something about it. And I knew it was going to be bootstrapped. I knew I didn't have a million bucks to put towards it, but I knew I could put something together. And like I said, when I saw the demand for 500+ kids applying, I knew we had something. And in the last two years, we've done a lot and have a long way to go but are really excited about some of the things around the corner.

+ +

CHAD: That's great context. And so, how did you go from zero to something?

+ +

BRIAN: The first part was just surrounding myself with people that I thought wanted to be contributors and collaborators and building it, so that's both students and mentors, so building an operating board and people around us to help us do it. I can tell you the process of launching a 501(c)(3) is not fun, and it's not for the faint of heart dealing with the government.

+ +

And I caveat that by saying towards the end of the process, I almost appreciated how difficult it was because it forced me to get a lot of things in place that were not fun to put in place. And as a result, if I wasn't that serious about building this, I think I would have been paused multiple times throughout the journey. While it's a frustrating manual, kind of nasty process, I do think it's a filtering mechanism for the government. Because the last thing you want to do is allow corporations to give people money that they think is going somewhere good and then it not go somewhere good, so I definitely appreciate that. But yeah, the journey is not fun.

+ +

I think anything that's bootstrapped...I'm sure you've had plenty of guests on here that have experience at bootstrap companies. If you can't go out and raise $10 million like some of these seed companies on day one, well, then you can't hire five people, and you can't set up all of the right systems online that you want to someday. So I think that's another component that I just learned a ton from was how do we put the things in place to allow us to do this thoughtfully but not necessarily the things in place that we want to have in year three when now we have a 500k P&L and can flex into some different things and bring people on full time?

+ +

So it almost forced us to build a bare-bones mechanism that just went out and really focused on the product, really focused on is this something that Black undergraduate students need and want? And only very myopically focused on that in the early days. Because all of the other stuff, the infrastructure of a non-profit, the operating board, who we bring around, and what money we raise, none of that really matters if Black undergrads don't see it as valuable.

+ +

And so I very intentionally spent a lot of our time with the students and was very hands-on, still very hands-on. But really spent time getting feedback and gathering feedback from our first cohort around what are the things you love? What are the things we should change? Who are some of the speakers you wish you heard from? What are some of the ways we can engage you guys now that you have graduated?

+ +

It's been a fun journey. I'm learning a lot still. As you know, I run a venture capital fund alongside this. And so just finding ways for those two things to talk to each other and to support one another. We back predominantly underrepresented founders. And these founders come from the same ecosystems where our students come from. So it's a really unique opportunity to see synergies exist across the two things I'm building.

+ +

CHAD: As you were getting started with Takeoff, like you said, the most important thing was the students. So was there anything in particular that you did that you thought worked really well to let people know about this and spread the word?

+ +

BRIAN: Yeah, I'd say less so in season one, chapter one, whatever you want to call it. Less so in that season than last season. And so what I did is I really turned on our brand ambassador program SO taking the students who graduated from the first cohort and using them to push us into career development offices, help them share on their campuses.

+ +

We had 50 students, but it wasn't 20 from Harvard and 20 from Stanford. We probably had 35, maybe 40 schools represented where we had a few kids from a few different schools. But the network effects of allowing the students to go out, and there are 100 things on a job board at a school that people are trying to get access to these students. But there's not that many students actually advocating for the programs and saying, "Hey, I went through this, and it was valuable, and here's why it was valuable. And here's why you should go through it."

+ +

We have a ton of our students who are very proud of the program and share what we're building with other students. And I think that that was a really cool unlock because I think that's the most authentic way to get to know your customers is go through people who really have experienced what you're building and allow them to tell the story for you.

+ +

CHAD: You said you get 500 applications, 600 applications for the latest cohort, and you're choosing 50. How do you do that?

+ +

BRIAN: We use a couple of different filtering mechanisms, so the first is the application. So there are questions in there around why they would join the program, things like do you have another internship lined up? We tend to focus on kids who either couldn't get an internship or don't have a Goldman Sachs banking internship already lined up. We tend to find that they're just more absorbed by the program. They're more focused.

+ +

The second thing is there are a couple of questions around just what their aspiration is. I try to look for students who at least have spent some time thinking about who they want to be when they grow up. That doesn't mean you need to know. But oftentimes, if you're not curious or aspirational on your own, regardless of whether you have confidence, if you're not curious or aspirational on your own, it's very hard for me to elicit that in an eight-week program.

+ +

And so we really try to filter out the students that we think are excited about getting to the other side or are excited about breaking in or excited about challenging ceilings. That's a little harder to search for than did they fill out their LinkedIn? Did they submit their PDF the right way? So that's the second component.

+ +

The third component is honestly being very intentional about matching with our mentors. So I try to find mentors that are at least somewhat lined up with the ecosystems these students want to go to. So if I have someone that wants to break into product, I actually think it's super-valuable to get some of our friends that work at Facebook or some of our friends that work at Pinterest who are in product as their mentors, regardless of whether they work on a product-related research project. And so, using our mentors to guide that journey from 100 to 50 students to make sure that they all feel like they are getting someone that can really help advance them.

+ +

And it's funny; it's pretty incredible. At the end of the program, a lot of them will come and say, "I can't believe how similar I am to Tyler, or Stacey, or Rebecca." It's really incredible how connected they become. And I just like to say, "Oh yeah, I can't believe it too."

+ +

We are very intentional in the background on making that happen. But our mentors stick around with our advisors, and I hear two years later they are helping each other find a job. Or I'll get a picture of them out to brunch because they check in once a quarter. That's the stuff that just gets me super jacked up to keep doing it is recognizing that these people continue these relationships long after the fellowship program is over.

+ +

CHAD: And that's great and really shows one of the great things about programs like this, and you already alluded to it earlier, is that they compound. As more people go through it, the value of the overall program hopefully goes up.

+ +

BRIAN: That's right.

+ +

CHAD: So are there any interviews or anything as part of the process of getting?

+ +

BRIAN: There's not. That's new this year, which we're super excited about. The first two years were, again, really just us in the background making that happen. And I wouldn't have known what to interview for, to be completely honest. I think now I have just a better understanding of the type of student that succeeds in our program. I didn't entirely understand that before. And I think regardless of whether you're diverse yourself, I think there's implicit bias that comes with jumping on a Zoom with someone and seeing how they interact. And I don't know that those biases always lead you to the best candidate.

+ +

And so, I think we tried to take a thoughtful approach but didn't want to over-engineer the early days of building our cohorts. And we beta-tested a bunch of different stuff. So we had freshman, sophomore, junior, senior, and first-year out, as well as Harvard, Stanford, Arkansas State, two-year community college, really just the full gamut. There are 1.1 million Black undergrads in the country in every given year.

+ +

So finding students from all these different places and then kind of honing that in and figuring out, you know what? I think if you do this program right after your freshman or right after your sophomore year, it's super valuable. And it really sets you up to have that strong junior year internship because that's the one that matters. That's the one that changes your trajectory if you go get a good one.

+ +

And so just learning those types of things over the first two years, I think, really helped us hone in who we focus on, and why we focus on them, and what resources we provide for them. Because it just, again, it just helps us build that treadmill to really accelerate their trajectory into their young professional career.

+ +

CHAD: You mentioned undergrad, so the program is specifically focused on people in college going to a university of some kind.

+ +

BRIAN: It's specifically focused on Black undergraduate students. I struggled with this a little bit because there are a lot of people that need help. I grew up in some underprivileged ecosystems as well. And there were plenty of poor white kids that also should get this or underrepresented Latinos that I knew. And while I wanted to build that, I also knew there's just a lot of noise. There's a lot of resources and advice and people out there trying to help. And I kind of said to myself, "This is the demographic that I understand best."

+ +

And instead of pretending like I know how to build a platform to help someone from an ecosystem I don't truly understand break-in, I'm just going to focus all my effort on getting more people that look like me because I know that there's a need for that and know that there's a gap for that. And I know that historically, companies have not been good at doing that on their own. So that's been our focus. And I hope there's a day where we have the privilege to expand that horizon and spend time because we have the resources to do it. But for now, I still have a long way to go within the Black community. And I'm going to keep focusing our time there.

+ +

CHAD: Yeah, I was thinking more about the kids who aren't even getting the opportunity to go to college. So they're 1.1 million Black undergrads. There are probably even more people who don't even get the opportunity to go to college. There are so many people you could help with this. What are your goals for growth? And how do you serve more people?

+ +

BRIAN: Yeah, I'll tell you the one that's top of mine because we're super excited about it. And this hasn't been released to many places, and so for our lovely thoughtbot community, I'm super excited to share this early, but we're building something called Takeoff University. Takeoff University will be the largest resource repository in the world for Black undergraduate students. Again, I think that the positioning is Black undergraduate students. I don't think that there's a paywall set up where if you don't have a .edu you can't use it. And so, I'm still thinking about how we provide access for some of the people you're describing.

+ +

But regardless, the idea being our fellowship is very hands-on and very intentional, and specifically focused on accelerating 50 people a summer. But how can we build something that more effectively brings in anyone in their undergraduate ecosystem development? Whether you're a freshman, sophomore, junior, senior, how can we deliver resources to you and get you some of the things that we know you need at the time that you need them and allow you to more effectively become part of the Takeoff ecosystem? Because what we believe is we can build a pretty unique flywheel around the broader TakeOff University ecosystem and some of the content and curriculum and thought leadership and just sharing that can occur there.

+ +

I think a lot about our older students. When we talk to them about how they engage with younger students, it's oftentimes younger students are sent to them. So they have a classmate who says, "Hey, you should talk to this guy. He broke in, or he had an internship somewhere." And those students come, and one of the first things they ask is, "How do I do it? How do I become you? How do I do the thing you did?"

+ +

And I think for a lot of students, they don't have a good answer for that. It's hey, let me send you these 2009 PDFs that someone sent me on banking recruiting. Or "Hey, have you checked this out at the career development office?" But they don't send them to anywhere, at least in a concentrated manner. And that's really what got me excited about building Takeoff University was there is not a centralized resource repository where any and every Black undergraduate student should go to prepare themselves for their young professional journey.

+ +

And so some of the things that'll be a part of that are the first thing is you come in as a career exploratory quiz. You answer a bunch of questions on what you're interested in, what stage you are in your internship development, what stage you are in your academic tenure. And it just helps guide us towards some of the resources that we know you should look at. And it doesn't mean you can't spend time in the whole library but help us guide you in the early days.

+ +

And then from there, dynamic ways for students to engage, so building community and allowing them to share resources, ways for companies to engage. So allowing companies to come in and identify students that might be top candidates for their program. So really just building an inclusive ecosystem for Black undergrads where they can come and know that they'll give valuable resources. And so we're really excited. We have some really cool things in the oven around this and excited to launch it to the world later this year.

+ +

CHAD: That's great. What would it take for you to grow from 50 fellows to 100? And is that something that you want to do?

+ +

BRIAN: Definitely. If you had used the number 500, I might have paused. [laughter] Again, 50 was like, get it right, do it right. I have 100 kids. I don't want to speak for all of them, but I have a lot of students that love what we did over their summer and really shout it from the rooftops to their community. And that means a lot to us.

+ +

And I'm not entirely sure that if it had been 100 and then 100 that I'd have 200 students who shout that. I think we were able to build a very intimate and hands-on experience for our first two cohorts. And as we grow, and as we introduce technology, and platform, and resources, I think there are ways for us to expand the number without getting out over our skis.

+ +

And so 100 is in a very near-term goal for us. I'm not sure that it goes much past that. I think instead, like I described with Takeoff University, we start introducing other opportunities. We start putting more things under the Takeoff Institute umbrella. I think a lot like the Aspen Institute. There are so many different ecosystems and community-building efforts going on underneath the larger umbrella. And so long as Takeoff Institute is known as just advancing opportunities, I think we can build a ton of cool ways to have touchpoints with students across the country.

+ +

CHAD: Are there specific blockers you would identify? Or you have an attentive audience here, are there things you would ask for to get to that 100 fellows?

+ +

BRIAN: It's a great question. I think folks that have had any experience building, you know, call it Twitter University, Pinterest University, Plaid University, folks who have been on the internal teams that help stand up curriculum and training for employees, again, that's a large part of what we're standing up with TakeOff University. And I'm very, very fortunate to have the funding now and not be in a place where we're looking for money to do that.

+ +

And so we have the resources to make this really special, and just getting some of the design and product folks that might be listening who might be interested in helping build a community like the one that we're building, we'd appreciate it. We'd love to chat. You can email me at brian@takeoffinstitute.com. I'd love to chat and learn. And even if you don't have time to chat, if there are platforms that you know that look really cool and look like the type of thing that we should be mocking or mimicking, I think it's always helpful to see comparisons and benchmarks. So I think that that'd be a great one.

+ +

And the other thing I'd add is if you want to be a mentor, please apply, takeoffinstitute.com. It's an incredible experience. I wish I could say I had 100 advisors, but I probably only have 60 because most of the ones who did the first cohort did the second cohort. And they loved it, and they're doing the third cohort. It's an hour a week. It's a very light touch, eight weeks of the summer. It's a very light touch, but I think it's impactful. So we'd love to have some of the folks.

+ +

CHAD: Do you specifically look for Black mentors?

+ +

BRIAN: We don't. We don't. I think that that's a really important part of this experience. Like I mentioned, you don't get to choose who your direct report is. And so your direct report might be White, Asian, Black. I don't care what they are. You need to get used to having that direct report experience and building rapport, and building that relationship regardless of what they look like. And so we appreciate having mentors that are male, female, and come from all different walks of life.

+ +

CHAD: Great. And that website again was?

+ +

BRIAN: www.takeoffinstitute.com

+ +

CHAD: Awesome. Well, I think that's a very natural and great place to leave it. I hope folks will contact you and get involved. And there's so much work to be done in this area. And it's a great opportunity to have an impact.

+ +

BRIAN: Yeah. Thanks for having me, Chad.

+ +

CHAD: Thank you. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

Brian, if folks want to get in touch with you, you want to say your email again and any other channels they should do that?

+ +

BRIAN: Yeah, perfect. brian@takeoffinstitute.com. And you can find me on Twitter @BHolls1, B-H-O-L-L-S-1.

+ +

CHAD: This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Brian Hollins.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+UvmyRaFN + + ]]> + + Chad Pytel + Brian Hollins + + + 412: Diversity-X with Kevin Withane + https://podcast.thoughtbot.com/412 + 5c743a88-edc5-4cb2-aebe-8ccc1051c633 + Thu, 24 Feb 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Kevin Withane is the founder of Diversity-X: a community to help underrepresented founders who are trying to make a positive impact in the world thrive, scale, and grow. + +Chad talks with Kevin about giving underestimated founders connections and access, creating a venture fund, and creating a platform via DiversityX. + 32:26 + no + + + Kevin Withane is the founder of Diversity-X: a community to help underrepresented founders who are trying to make a positive impact in the world thrive, scale, and grow. +Chad talks with Kevin about giving underestimated founders connections and access, creating a venture fund, and creating a platform via DiversityX. +Follow City DiversityX on Twitter (https://twitter.com/diversityx_vc). +Follow Kevin on Twitter (https://twitter.com/KevinWithane) or LinkedIn (https://www.linkedin.com/in/kevinwithane/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Kevin Withane, founder of Diversity-X. Kevin, thanks for joining me. +KEVIN: Chad, thank you so much for having me on this show. +CHAD: Kevin, I know you have deep expertise and background in law and ethics and compliance, particularly when it comes to diversity, equity, and inclusion issues. And that has led you to create Diversity-X. And so what is Diversity-X? +KEVIN: Diversity-X is a community for underestimated founders trying to make a positive impact in the world. We're working on creating a VC fund for it. And also, it's an ecosystem to support those underestimated founders and help them thrive and scale, and grow. +CHAD: That's great. What kind of support and community are underestimated founders lacking, and how does Diversity-X fill in that gap? +KEVIN: I think it's a mix of connections and access. I use the term underestimated rather than what many people term as underrepresented because there are plenty of people of color founders, plenty of LGBTQ+ founders, plenty of female founders, disabled founders, veteran founders. There are lots of them in the world, so they are represented. +They're just underrepresented in the equitable allocation of capital and particularly venture capital at early stage, which sees many of these founders not necessarily succeed or have to work that little bit harder just to get a starting place where many others get funding a lot earlier and a lot easier in their journey. And I'm not saying raising capital is easy at all for anybody, but it's easier for certain groups of people than it is for others. +CHAD: What makes it easier? +KEVIN: I'm going to be candid in my views. I think it makes it easier if you're a white male; nothing against white males, but it's easier. There's that privilege. But also, you look, sound, probably have a lot of similar backgrounds to the people who are allocating the money who have control over whether they invest or don't invest in the startups. And I think; also, they tend to have better connections or better ins. It is a generalized statement, but data shows that 93% of VC money typically goes to white male founders. So it's backed up by data to an extent. +CHAD: Right. And it doesn't even need to be ill intent. In some cases, there might be, but it doesn't need to be. So much of the VC world is about connections, and what you've done previously, and who you know, and the intro you're able to get. And then, when you finally get the meeting, if you're out pitching something that just isn't even on the radar of the typical VC, they're not going to connect with your idea in the same way that you do. +When we're building products, having a diverse team of people allows us to see all the different aspects of that product and have people saying, "Well, what about this? From my background or my perspective, I understand that this is a particular concern for women around the safety of this," or something. And people say, "Oh yeah, I didn't even realize that." +KEVIN: Yeah, that's a great point. Within the Diversity-X community, very early on, I realized one of the probable flaws for VC is, let's be honest, it's a very male-dominated industry. I think they are making real strides to change it, make it more open, more accessible to females and people of color. But essentially, for the most part, it is people who look and sound the same and typically are a white male. +And there's no disrespect, but sometimes you can get a pitch about femtech. And while she may go, "Yeah, I can see that this could be a problem," you don't know because the fact is you're not a woman. You just don't know. And I experienced that very early on speaking to a female founder who's part of the community, and she's really trying to do some amazing stuff. But at first, I was like, "I can empathize with the issues you're trying to address here and the problem, but that's as far as my knowledge goes." +And it made me wonder if VCs who are getting this sort of pitch will probably turn them down. They can't understand the problem. So, therefore, they can't understand what the solution that the founder is trying to come up with is really trying to address. And so pushes it by because they don't have that expertise, and that's not their fault; it's just there's a lack of diversity in the VCs themselves to be able to address that. +But then you hear these stories about male founders coming with a femtech solution almost on the back of a cigarette packet. And they're getting X amount of dollars to go and do some research and try and start building a product around what their idea is. And yet many of the female founders are scratching their head; well, we didn't have an in to that VC, so we never got in. And yep, so we don't get funding for what is a problem that we actually experience ourselves, and we're trying to address. +CHAD: This conversation reminds me of a conversation that I had in 2018 in Episode 279 with Alex Friedman, the co-founder of LOLA, which is a feminine products company. And she talked about how it was clearly uncomfortable for the people that they were talking to to talk about these kinds of things. +So even that can have an aspect to it where like...and then men may be more comfortable talking with men about feminine products than they are to women about them. And it just permeates the whole conversation when you're trying to launch a product that you need money for if it's uncomfortable, or it's foreign, or all of those things. +KEVIN: Absolutely. The industry needs to change in a couple of ways, I see. There needs to be greater emphasis on VCs building networks and connections into the communities and to the founders that are underestimated people of color, female from different socioeconomic backgrounds that may not have been able to afford to go to MIT or Harvard but super-smart people solving real-life and real-world problems. +And VCs themselves need to look at their own diversity, like, it is not diversity just for the sake of well, we need X number of women now with investing power, or we need more people of color to invest. It's because those people bring their lived experiences, which is the same for any business. +It's no different if you're a big corporate. The reason for diversity is the same. It's to get that cognitive diversity, that cognitive difference of lived experience, which in the end, bring into your field. It's something as human beings we can't detach ourselves from. We can't detach ourselves from our lived experience. We take that everywhere we go. +CHAD: So what's involved in creating a venture fund? +KEVIN: A lot more work than I thought. +CHAD: [laughs] +KEVIN: I don't have a venture background, so I'm already 700 steps behind everybody else that is doing it. Even the good guys who are trying to actually address this problem, many of them actually come from a venture background. But I'm looking out there, and I'm seeing people like Matt the VC, Arlan Hamilton, and they inspire me that I can do this. Because, ultimately, I had a soft conversation with a family office just to try and explain what I'm doing and see if there'd be interest. And they actually liked the idea. +But they said to me, "Who are your competitors out there?" And I said, "Look, you can think of me as naive, but the reality is I don't think I have any competitors." And the reason is because we have a mission. Our vision is a world where you don't have underestimated founders. +Our mission is to grow the world's biggest community of underestimated founders and support those that are VC-ready and the right fit for funding that are going to be successful with capital. And whilst there are other companies and funds doing this, they have niches where they focus on certain areas. We're much broader. +But ultimately, no matter how much I raised in the fund, it's never going to be enough. It's never going to be enough to meet the gap that there is right now and the opportunity. So when you say competitor, every time an underestimated founder gets funded and gets given the opportunity to really address the problem that they're trying to tackle, that's a win for me because it's helping my mission and the vision. So that's the way I look at it. +And yes, that is a little bit naive, maybe. But you look at Elon Musk, and you look at founders who are trying to do amazing things. And you don't really knock them down for their grand visions. You have to aim high, and that's what we're trying to do at Diversity-X. +CHAD: So I noticed that you are particularly focused on the UK and Europe. And in my experience, the investment community tends to be different between the United States and Europe. How have you found that, and has that been adding a challenge on top of a challenge? +KEVIN: Yeah, it is adding a challenge on top of a challenge. It is different. I think the U.S., in some senses, is much more progressive, much more open. It's funny, I was talking to a friend, and I was saying...I can't really talk numbers because I don't want to get in trouble with the FCA. But I said to him, "This is the sort of size of the fund I'm looking to raise." And he is an American. And he just looked at me and said, "Why?" And I said, "Well, you need sort of skin in the game. You need this, this, and this." +He looked at me and said, "You are the skin in the game. Your passion comes through." Guys in America, people will be looking at you, saying, "You're way too small. You need to go much bigger than this." And I said, "But skin in the game, skin in the game, skin in the game." He said, "Don't tell me about that. Go big and see if people will buy into it." And that's I think much more of the view across the pond. There's much more appetite. +And I think for European VCs and particularly those probably starting out trying to address some of the issues that Diversity-X hopes to address, we've got to move probably and work hopefully in tandem with the more progressive, more open, more solution-oriented VC funds that are coming from the U.S. Because quite frankly, they are coming here now. They're coming to UK and Europe. But the reason I wanted to start in the UK and focus on the UK and Europe is that's where I'm based. That's where the best part of my knowledge is. Although interestingly, I guess my network is probably from the LP side, probably stronger in the U.S. So we'll see how that pans out. +CHAD: I assume that there are some legal requirements to starting a venture fund. Or can anybody do it, I guess is the...[laughs] +KEVIN: Maybe this is part of the problem as well as, the bar for entry just to start a fund is high, and it's expensive. So I guess I'm blessed that I've had the opportunities I've had in the past to be able to build something to be able to start this. But yeah, it's a myriad. And as a lawyer and someone who's even done transactional work on private equity and even helping some startups on fundraising and seeing how it works, it is very difficult. And you could be dealing with multiple jurisdictions depending on where your limited partners are. So there's a lot to factor in. +And then it's not just the legal fees; it's the fund administration and the fund management. For instance, in the UK, are you going to be regulated if your fund doesn't need to be regulated? Or are you going to be authorized on your own, or are you going to use an umbrella? What does that mean? So it's a real steep learning curve. +And I've got to admit, in my personal journey, there have been too few who have responded to my request just for help and advice, including what I would consider...I use this as the good guys, but the people trying to address the same problems that I am either focused on female. You reach out, but there's no return call. But there is one person who's a traditional fund; he is a white male VC. But honestly, he came back. We had a call. We talked about stuff. He said, "Keep in contact. Let me know how it's going," and he's tried to help me. +A couple of weeks later, I didn't hear from him, and then all of a sudden, an email popped up, or a message popped up saying, "Oh yeah, sorry it's taken me a couple of weeks to get back to you. But I just wanted to make sure that here's an introduction. This could be the partner you're looking for blah, blah, blah." I was blown away by that, that kind gesture. Somebody who just literally could have had a call with me said, "Yeah, not interested in this, never going to go anywhere. Why exert any effort?" +CHAD: That's great. You mentioned it is difficult. It's always difficult to start something new. But you're doing it alone. You don't have a partner. +KEVIN: No. I'm on the hunt for a partner. It's like dating, I guess. You keep trying to kiss a lot of frogs to find that person. Ultimately, knowing that I'm going to get challenged, rightly so, on track record, I would like to find a partner who has VC experience, who buys in deeply to the concept, and the mission, and the vision that we have and is looking to build a VC firm, not a fund, i.e., this is not a one and done exercise. This is about creating over multiple funds and, hopefully, generationally growing this to something really special. +CHAD: Well, if you're listening, and that describes you, get in touch with Kevin. [laughs] +KEVIN: Absolutely. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: In the meantime, while you're working on building this venture fund, you said, okay, I'm going to start building a community right away, right? +KEVIN: Yep. +CHAD: And when it comes to platform, how are you doing that? Are you using something off the shelf? Are you piecing it together? How's it going? +KEVIN: It's such hard work. Who would have thought? My wife laughs at me because since she's known me, every time we go into a town, or a village, or a shop that has a community board, I'll stop and read it. And she would laugh. She's like, "It's such a geeky thing to do." And I was like, "I love community. I like to know what's going on, what's happening." +I presumed that it's, therefore, relatively easy to build one. Then I was very nervous, and I was like, I don't know how to get started. And somebody who's in the community but also just an amazing person, Amy, she said to me, "Dude, just get started. Stop procrastinating. Just start a WhatsApp group," so I did. +And then I invited a couple of friendly faces, i.e., friends, and said, "Please, can you join this group?" And then I invited a couple of founders that I had just connected with and just started having conversations with. And from that moment...and this was early October, and then my son went into hospital. But from that moment, it started growing. So beginning of October 2021 to date, we have about 60 founders, which I think is not bad. And we use a WhatsApp group. +Then I had some conversations and got some feedback from the founders. And they said, "Look, we need some more organization because our feed is blowing up with the amount of traffic going through it. So we need some sort of structure. We need some resources and different things." So I was looking around, and I was like, by the end of day, what can I get for free? Because I'm not making any money on this. And what can I get for free? So we moved it...we didn't move it. We set up on Slack. +But I've got to say despite having more organization, the bulk of the activity still works around WhatsApp. But I will say this; I'm not a tech person, so I do need support on this. So if there's anybody who wants to volunteer to give me some advice, or help, or just come onboard maybe in some capacity, I am trying to build a platform that's web-based, maybe even app-based, that can help facilitate conversations, learning, investor matching. +Because part of what I'm doing, whilst I haven't raised a fund yet, is that there are members in this community who need support right now, financially. I can't give that to them, but there are good people out there, good angels, or even some of them, probably VCs that would. And so it's trying to create a platform where we can connect those founders, those underestimated founders, and I think predominantly angels. +But if any VCs want to join, that'd be great too, just to help these guys get started. They need to start moving forward, and they can't wait for me to get a fund up and running. So whatever I can do. So I am looking at building a platform. It's just in the question of how do I do this? And is there anybody to help me? +CHAD: If you're a founder who wants to get involved in this community and think it would be beneficial to them, where do they go to do that? +KEVIN: I'll say reach out to me either email me kevin.withane@gmail.com or connect with me on LinkedIn, two best Places. We'll chat. But generally, the community is open. If you're an underestimated founder, if you just tick that box, you're in. Come and learn, grow, support, be supported. You'll see that. +We've had some new members in the last week who have just said, "This is a really interesting community." And I spoke with one today that said, "I'm generally very wary, particularly about being around people who have similar businesses to what I have, you know, competitors." And I said, "Why? Why are you scared of competitors?" And she's in a field which relates to sustainability. +I said to really deliver the sustainability you want to deliver, it's about collaboration, and that's what this group has. It has that in spades, people working together, people supporting each other, e-platform. They are going gangbusters on sharing information. This is what we use. This is a great book. This is a great resource. These are great people to go and speak to. And so it takes the pain and reduces the stresses of being a founder, which you've got to do so many different things. And generally, you've got to do all of those things on your own with a very few number of people supporting you. +CHAD: And I imagine that a lot of the people in the community so far are people who invite each other in. +KEVIN: Yeah, and there are other people that I've met who have contacted me and said, "Look, we've got this startup. We're looking for an advisor, or we're just looking for a bit of support," or even someone saying, "We're looking for investment." So I'm very upfront where we are at the stage we are. But I'll introduce him to the community, and they start embedding themselves in it. And it's growing. As I said, the mission I don't know if it's bold enough, but I think it is bold. +CHAD: [laughs] +KEVIN: It is to be the world's largest community of underestimated founders. And I actually asked a question with the group yesterday was, "How do I go from, say, 50 to 500 in a few months but real genuine people that want to be community members like actually contribute and be active?" I'm still waiting for the answer to that question. I'm hoping it's going to come next week. [laughs] +CHAD: [laughs] So I'm curious, given your work in, and correct me if this is wrong, but I would say a more corporate space, in your work in international law firms and global public companies and that kind of thing. How has that experience either been different or the same as what you're trying to do now? And how do traditional companies approach issues like this? +KEVIN: So I get to work with...I have a day job, as I call it, but Diversity-X and supporting diversity is my passion. To address some of the passions that I have, the reality is not every workplace can or chooses to allow that to happen for employees. In certain companies, your role is your role. And if you want more, then go outside. +So for me, there are things I wanted to do that I don't get the opportunity to do in my workplace or in the way I want to do it in my workplace. So I started looking outside; well, who can I help that needs someone like me to help them with this sort of thing? And that's how I fell into helping startup founders. And that's where I found this absolute passion. +I think everybody who works with founders and startups is always energized in a way that incorporates the energies that sits in pockets in my experience. And you don't tend to see huge organizations. And this is not to say they don't exist; there are some that do but who are energized and focused on a purpose. +I think those that have purpose that's really, really clearly defined and embedded do have this energy of drive and innovation and disruption and even go as far as trying to have radical change. Others are trying to learn. And to be fair, to many organizations, some of this stuff is new to them. And they're learning, and it takes time, and you have to give them time, and you have to give them the opportunity to fail and make mistakes. +So there are a lot of companies that are trying to do the right thing, trying to be better, trying to embrace their people and the issues, and the things that their people care about but as well as balancing with the wider stakeholders because they have multiple stakeholders; it's not easy. +It's a tough balancing act for anybody in a leadership position in the corporate to say, "Well, look, we've got to deliver financial results. But also, we've got to think long term, but we're measured on short term." How do you do that? It takes a lot of work and effort, which is why I see the opportunity for startups, in particular, to operationalize this stuff early on. So that becomes embedded because retrofitting is very expensive and very time-consuming, and resource-heavy. +CHAD: Having lived and worked in the UK, China, Hong Kong, Russia, The United States, how are things different in all those places when it comes to work and issues like this? +KEVIN: Let me just quickly ask you a question see what you think. Where do you think was the hardest place of those locations to live and work? +CHAD: Hmm. Russia? +KEVIN: It's interesting. +CHAD: I don't know. +KEVIN: No, no, no. People would usually say, and people do say to me, "Oh, China must be really hard, or Russia must be really hard." +CHAD: Well, I went to visit China about two and a half years ago. And it completely changed my perspective on what China is like, and so that's why I didn't answer China. But I don't want to invalidate your perspective if China was the most difficult place for you. [laughs] +KEVIN: Actually, no. The United States was the hardest place, which is why in 2020, we made that decision, for multiple reasons, to return home back to the UK. It's the land of opportunity, but it's slipping by. They've got so much resource. They've got so much of everything. But there's such disunity in my perspective and in my lived experience. +But if you're an American, you might see it differently. If you're someone, an immigrant who got naturalized there, you may see it differently. But in my personal experience, and that's all I can talk to, was that this is a deeply divided country that's frittering away the opportunity to truly be the greatest country in the world. +And they talk about being the land of the free. I used to joke with my Canadian colleagues because I was in Detroit, so you look north. You look south, sorry, you look south to Detroit, which is the only place...and I use this as my pop quiz question of it's the only place in America, I believe, that if you look south, you're looking at Canada. But I used to say that's the land of the freer because truly, I actually felt more strict in the United States than living in Russia or in China. +You get told what to do. It's just done in a different way in the United States, and that's just my experience. But look, I lived there for three and a half years. It's not a lifetime by any stretch of the imagination. And it was a time when I guess many of the people I love and care about in America probably said, "Kevin, you are here at the worst time to be here. +CHAD: [laughs] Right. +KEVIN: And this is not the real America." But unfortunately, that was the America I experienced. So it was the hardest place for me. +CHAD: I think that that's actually where America gets into trouble is by continually saying, "This isn't the real America." And you can only say that for so long when we've been saying it for a long time. And so I think it's important to ask ourselves, isn't that actually the real America then? Sort of to your point of the VCs and not changing the demographics despite saying something is a problem and working at it over time. And, oh, we've made a percentage point of progress means that you're not really working on the problem or willing to change because you're probably not focused on the right things. +KEVIN: Yeah. And you think about the United States of America it's funny, the house I'm living in is 172 years old. It is older than so many places in the States, and yet I remember someone saying, "Oh, you're living in a 1950s house. That's a really old house." [laughs] It's like, it's almost a new build in the UK. America has this rich history to still create. +CHAD: And I think that's what lends us to being more aggressive when it comes to investment and more willing to take risks. So like you said, there are tons of opportunity and some tons of potential at the same time as there are probably real big problems. +KEVIN: You know that saying about the rising tide benefits all? +CHAD: Yeah. +KEVIN: I think in VC, it has had a negative connotation because from the industrial gaslighting is yeah, there has been an increase in funding, but everybody got it. So the percentages of allocation didn't change. But also, America has that opportunity, in my view, to really rise everybody. Just take the education system; it should be the greatest education system in the world, bar none. The resources are there, the talent is there, the people are there, and they're hungry for that education. Heck, people from other countries scramble to get America to have a piece of that. But why is it not? +And I think it's because there's too much protection of certain groups and an unwillingness to be more open. But the more open you are to the different ideas, to the different viewpoints, to then finding the best place for us, I think it presents America with a huge, huge opportunity. So, you know, I'm probably [inaudible 29:14] [laughter] because really you should be the best. You say you're the biggest and the best, but people don't care about the size of your army, really. The everyday Joe in the UK, we don't think about that. I grew up thinking America was paved with gold, and I got there, and it's like, this is not quite the way I grew up. [laughs] +CHAD: Well, inside of America, there's a lack of that perspective, though, because when you can self believe that that's the case. And because you don't have a perspective on what it's actually like elsewhere, it's very easy to say, "Oh, we are the best." +KEVIN: Yeah, that's true. And look, who cares what country is the best in reality? [laughter] Sometimes I like to think I've got these three children. Right now, as children, they don't care. They just want to get on with people and have more friends and more relationships, and that's what they care about. But at some stage, I don't know where it starts or how it starts; we lose that. We lose that. +But you see that in founders, this ability to get past that, and they're trying to address it. At least the founders I'm trying to support they're really trying to break past these barriers of we're different, and we need to remain different to we are different. Let's embrace that. And how can we use that to our advantage? +CHAD: Yeah. And I think that to take a step back, I'm a big believer in continuous improvement and always trying to be better. And I think that when you find yourself in a position where you've stopped doing that, it's no good for anybody. And it's very clear to me that there's the next frontier for improving ourselves, and the companies that we work at, and the world in which we live is all of these things that we've talked about today. And so I really wish you the best with Diversity-Xand with what you're trying to do. And please keep in touch, and we should talk further, maybe offline after this recording, about how we might be able to help more. +KEVIN: Brilliant. And thank you so much for having me on this podcast. I'm so, so grateful. Thank you. +CHAD: Kevin, if folks...you said your email address before, but do you want to say it again or other places where people can reach out to you? +KEVIN: Yeah, so it's kevin.withane that's W-I-T-H-A-N-E @gmail.com. Or you can find me on LinkedIn. I'm very visible there. +CHAD: And you can subscribe to the show and find notes along with a transcript of this entire episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and we'll see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Kevin Withane is the founder of Diversity-X: a community to help underrepresented founders who are trying to make a positive impact in the world thrive, scale, and grow.

+ +

Chad talks with Kevin about giving underestimated founders connections and access, creating a venture fund, and creating a platform via DiversityX.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Kevin Withane, founder of Diversity-X. Kevin, thanks for joining me.

+ +

KEVIN: Chad, thank you so much for having me on this show.

+ +

CHAD: Kevin, I know you have deep expertise and background in law and ethics and compliance, particularly when it comes to diversity, equity, and inclusion issues. And that has led you to create Diversity-X. And so what is Diversity-X?

+ +

KEVIN: Diversity-X is a community for underestimated founders trying to make a positive impact in the world. We're working on creating a VC fund for it. And also, it's an ecosystem to support those underestimated founders and help them thrive and scale, and grow.

+ +

CHAD: That's great. What kind of support and community are underestimated founders lacking, and how does Diversity-X fill in that gap?

+ +

KEVIN: I think it's a mix of connections and access. I use the term underestimated rather than what many people term as underrepresented because there are plenty of people of color founders, plenty of LGBTQ+ founders, plenty of female founders, disabled founders, veteran founders. There are lots of them in the world, so they are represented.

+ +

They're just underrepresented in the equitable allocation of capital and particularly venture capital at early stage, which sees many of these founders not necessarily succeed or have to work that little bit harder just to get a starting place where many others get funding a lot earlier and a lot easier in their journey. And I'm not saying raising capital is easy at all for anybody, but it's easier for certain groups of people than it is for others.

+ +

CHAD: What makes it easier?

+ +

KEVIN: I'm going to be candid in my views. I think it makes it easier if you're a white male; nothing against white males, but it's easier. There's that privilege. But also, you look, sound, probably have a lot of similar backgrounds to the people who are allocating the money who have control over whether they invest or don't invest in the startups. And I think; also, they tend to have better connections or better ins. It is a generalized statement, but data shows that 93% of VC money typically goes to white male founders. So it's backed up by data to an extent.

+ +

CHAD: Right. And it doesn't even need to be ill intent. In some cases, there might be, but it doesn't need to be. So much of the VC world is about connections, and what you've done previously, and who you know, and the intro you're able to get. And then, when you finally get the meeting, if you're out pitching something that just isn't even on the radar of the typical VC, they're not going to connect with your idea in the same way that you do.

+ +

When we're building products, having a diverse team of people allows us to see all the different aspects of that product and have people saying, "Well, what about this? From my background or my perspective, I understand that this is a particular concern for women around the safety of this," or something. And people say, "Oh yeah, I didn't even realize that."

+ +

KEVIN: Yeah, that's a great point. Within the Diversity-X community, very early on, I realized one of the probable flaws for VC is, let's be honest, it's a very male-dominated industry. I think they are making real strides to change it, make it more open, more accessible to females and people of color. But essentially, for the most part, it is people who look and sound the same and typically are a white male.

+ +

And there's no disrespect, but sometimes you can get a pitch about femtech. And while she may go, "Yeah, I can see that this could be a problem," you don't know because the fact is you're not a woman. You just don't know. And I experienced that very early on speaking to a female founder who's part of the community, and she's really trying to do some amazing stuff. But at first, I was like, "I can empathize with the issues you're trying to address here and the problem, but that's as far as my knowledge goes."

+ +

And it made me wonder if VCs who are getting this sort of pitch will probably turn them down. They can't understand the problem. So, therefore, they can't understand what the solution that the founder is trying to come up with is really trying to address. And so pushes it by because they don't have that expertise, and that's not their fault; it's just there's a lack of diversity in the VCs themselves to be able to address that.

+ +

But then you hear these stories about male founders coming with a femtech solution almost on the back of a cigarette packet. And they're getting X amount of dollars to go and do some research and try and start building a product around what their idea is. And yet many of the female founders are scratching their head; well, we didn't have an in to that VC, so we never got in. And yep, so we don't get funding for what is a problem that we actually experience ourselves, and we're trying to address.

+ +

CHAD: This conversation reminds me of a conversation that I had in 2018 in Episode 279 with Alex Friedman, the co-founder of LOLA, which is a feminine products company. And she talked about how it was clearly uncomfortable for the people that they were talking to to talk about these kinds of things.

+ +

So even that can have an aspect to it where like...and then men may be more comfortable talking with men about feminine products than they are to women about them. And it just permeates the whole conversation when you're trying to launch a product that you need money for if it's uncomfortable, or it's foreign, or all of those things.

+ +

KEVIN: Absolutely. The industry needs to change in a couple of ways, I see. There needs to be greater emphasis on VCs building networks and connections into the communities and to the founders that are underestimated people of color, female from different socioeconomic backgrounds that may not have been able to afford to go to MIT or Harvard but super-smart people solving real-life and real-world problems.

+ +

And VCs themselves need to look at their own diversity, like, it is not diversity just for the sake of well, we need X number of women now with investing power, or we need more people of color to invest. It's because those people bring their lived experiences, which is the same for any business.

+ +

It's no different if you're a big corporate. The reason for diversity is the same. It's to get that cognitive diversity, that cognitive difference of lived experience, which in the end, bring into your field. It's something as human beings we can't detach ourselves from. We can't detach ourselves from our lived experience. We take that everywhere we go.

+ +

CHAD: So what's involved in creating a venture fund?

+ +

KEVIN: A lot more work than I thought.

+ +

CHAD: [laughs]

+ +

KEVIN: I don't have a venture background, so I'm already 700 steps behind everybody else that is doing it. Even the good guys who are trying to actually address this problem, many of them actually come from a venture background. But I'm looking out there, and I'm seeing people like Matt the VC, Arlan Hamilton, and they inspire me that I can do this. Because, ultimately, I had a soft conversation with a family office just to try and explain what I'm doing and see if there'd be interest. And they actually liked the idea.

+ +

But they said to me, "Who are your competitors out there?" And I said, "Look, you can think of me as naive, but the reality is I don't think I have any competitors." And the reason is because we have a mission. Our vision is a world where you don't have underestimated founders.

+ +

Our mission is to grow the world's biggest community of underestimated founders and support those that are VC-ready and the right fit for funding that are going to be successful with capital. And whilst there are other companies and funds doing this, they have niches where they focus on certain areas. We're much broader.

+ +

But ultimately, no matter how much I raised in the fund, it's never going to be enough. It's never going to be enough to meet the gap that there is right now and the opportunity. So when you say competitor, every time an underestimated founder gets funded and gets given the opportunity to really address the problem that they're trying to tackle, that's a win for me because it's helping my mission and the vision. So that's the way I look at it.

+ +

And yes, that is a little bit naive, maybe. But you look at Elon Musk, and you look at founders who are trying to do amazing things. And you don't really knock them down for their grand visions. You have to aim high, and that's what we're trying to do at Diversity-X.

+ +

CHAD: So I noticed that you are particularly focused on the UK and Europe. And in my experience, the investment community tends to be different between the United States and Europe. How have you found that, and has that been adding a challenge on top of a challenge?

+ +

KEVIN: Yeah, it is adding a challenge on top of a challenge. It is different. I think the U.S., in some senses, is much more progressive, much more open. It's funny, I was talking to a friend, and I was saying...I can't really talk numbers because I don't want to get in trouble with the FCA. But I said to him, "This is the sort of size of the fund I'm looking to raise." And he is an American. And he just looked at me and said, "Why?" And I said, "Well, you need sort of skin in the game. You need this, this, and this."

+ +

He looked at me and said, "You are the skin in the game. Your passion comes through." Guys in America, people will be looking at you, saying, "You're way too small. You need to go much bigger than this." And I said, "But skin in the game, skin in the game, skin in the game." He said, "Don't tell me about that. Go big and see if people will buy into it." And that's I think much more of the view across the pond. There's much more appetite.

+ +

And I think for European VCs and particularly those probably starting out trying to address some of the issues that Diversity-X hopes to address, we've got to move probably and work hopefully in tandem with the more progressive, more open, more solution-oriented VC funds that are coming from the U.S. Because quite frankly, they are coming here now. They're coming to UK and Europe. But the reason I wanted to start in the UK and focus on the UK and Europe is that's where I'm based. That's where the best part of my knowledge is. Although interestingly, I guess my network is probably from the LP side, probably stronger in the U.S. So we'll see how that pans out.

+ +

CHAD: I assume that there are some legal requirements to starting a venture fund. Or can anybody do it, I guess is the...[laughs]

+ +

KEVIN: Maybe this is part of the problem as well as, the bar for entry just to start a fund is high, and it's expensive. So I guess I'm blessed that I've had the opportunities I've had in the past to be able to build something to be able to start this. But yeah, it's a myriad. And as a lawyer and someone who's even done transactional work on private equity and even helping some startups on fundraising and seeing how it works, it is very difficult. And you could be dealing with multiple jurisdictions depending on where your limited partners are. So there's a lot to factor in.

+ +

And then it's not just the legal fees; it's the fund administration and the fund management. For instance, in the UK, are you going to be regulated if your fund doesn't need to be regulated? Or are you going to be authorized on your own, or are you going to use an umbrella? What does that mean? So it's a real steep learning curve.

+ +

And I've got to admit, in my personal journey, there have been too few who have responded to my request just for help and advice, including what I would consider...I use this as the good guys, but the people trying to address the same problems that I am either focused on female. You reach out, but there's no return call. But there is one person who's a traditional fund; he is a white male VC. But honestly, he came back. We had a call. We talked about stuff. He said, "Keep in contact. Let me know how it's going," and he's tried to help me.

+ +

A couple of weeks later, I didn't hear from him, and then all of a sudden, an email popped up, or a message popped up saying, "Oh yeah, sorry it's taken me a couple of weeks to get back to you. But I just wanted to make sure that here's an introduction. This could be the partner you're looking for blah, blah, blah." I was blown away by that, that kind gesture. Somebody who just literally could have had a call with me said, "Yeah, not interested in this, never going to go anywhere. Why exert any effort?"

+ +

CHAD: That's great. You mentioned it is difficult. It's always difficult to start something new. But you're doing it alone. You don't have a partner.

+ +

KEVIN: No. I'm on the hunt for a partner. It's like dating, I guess. You keep trying to kiss a lot of frogs to find that person. Ultimately, knowing that I'm going to get challenged, rightly so, on track record, I would like to find a partner who has VC experience, who buys in deeply to the concept, and the mission, and the vision that we have and is looking to build a VC firm, not a fund, i.e., this is not a one and done exercise. This is about creating over multiple funds and, hopefully, generationally growing this to something really special.

+ +

CHAD: Well, if you're listening, and that describes you, get in touch with Kevin. [laughs]

+ +

KEVIN: Absolutely.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: In the meantime, while you're working on building this venture fund, you said, okay, I'm going to start building a community right away, right?

+ +

KEVIN: Yep.

+ +

CHAD: And when it comes to platform, how are you doing that? Are you using something off the shelf? Are you piecing it together? How's it going?

+ +

KEVIN: It's such hard work. Who would have thought? My wife laughs at me because since she's known me, every time we go into a town, or a village, or a shop that has a community board, I'll stop and read it. And she would laugh. She's like, "It's such a geeky thing to do." And I was like, "I love community. I like to know what's going on, what's happening."

+ +

I presumed that it's, therefore, relatively easy to build one. Then I was very nervous, and I was like, I don't know how to get started. And somebody who's in the community but also just an amazing person, Amy, she said to me, "Dude, just get started. Stop procrastinating. Just start a WhatsApp group," so I did.

+ +

And then I invited a couple of friendly faces, i.e., friends, and said, "Please, can you join this group?" And then I invited a couple of founders that I had just connected with and just started having conversations with. And from that moment...and this was early October, and then my son went into hospital. But from that moment, it started growing. So beginning of October 2021 to date, we have about 60 founders, which I think is not bad. And we use a WhatsApp group.

+ +

Then I had some conversations and got some feedback from the founders. And they said, "Look, we need some more organization because our feed is blowing up with the amount of traffic going through it. So we need some sort of structure. We need some resources and different things." So I was looking around, and I was like, by the end of day, what can I get for free? Because I'm not making any money on this. And what can I get for free? So we moved it...we didn't move it. We set up on Slack.

+ +

But I've got to say despite having more organization, the bulk of the activity still works around WhatsApp. But I will say this; I'm not a tech person, so I do need support on this. So if there's anybody who wants to volunteer to give me some advice, or help, or just come onboard maybe in some capacity, I am trying to build a platform that's web-based, maybe even app-based, that can help facilitate conversations, learning, investor matching.

+ +

Because part of what I'm doing, whilst I haven't raised a fund yet, is that there are members in this community who need support right now, financially. I can't give that to them, but there are good people out there, good angels, or even some of them, probably VCs that would. And so it's trying to create a platform where we can connect those founders, those underestimated founders, and I think predominantly angels.

+ +

But if any VCs want to join, that'd be great too, just to help these guys get started. They need to start moving forward, and they can't wait for me to get a fund up and running. So whatever I can do. So I am looking at building a platform. It's just in the question of how do I do this? And is there anybody to help me?

+ +

CHAD: If you're a founder who wants to get involved in this community and think it would be beneficial to them, where do they go to do that?

+ +

KEVIN: I'll say reach out to me either email me kevin.withane@gmail.com or connect with me on LinkedIn, two best Places. We'll chat. But generally, the community is open. If you're an underestimated founder, if you just tick that box, you're in. Come and learn, grow, support, be supported. You'll see that.

+ +

We've had some new members in the last week who have just said, "This is a really interesting community." And I spoke with one today that said, "I'm generally very wary, particularly about being around people who have similar businesses to what I have, you know, competitors." And I said, "Why? Why are you scared of competitors?" And she's in a field which relates to sustainability.

+ +

I said to really deliver the sustainability you want to deliver, it's about collaboration, and that's what this group has. It has that in spades, people working together, people supporting each other, e-platform. They are going gangbusters on sharing information. This is what we use. This is a great book. This is a great resource. These are great people to go and speak to. And so it takes the pain and reduces the stresses of being a founder, which you've got to do so many different things. And generally, you've got to do all of those things on your own with a very few number of people supporting you.

+ +

CHAD: And I imagine that a lot of the people in the community so far are people who invite each other in.

+ +

KEVIN: Yeah, and there are other people that I've met who have contacted me and said, "Look, we've got this startup. We're looking for an advisor, or we're just looking for a bit of support," or even someone saying, "We're looking for investment." So I'm very upfront where we are at the stage we are. But I'll introduce him to the community, and they start embedding themselves in it. And it's growing. As I said, the mission I don't know if it's bold enough, but I think it is bold.

+ +

CHAD: [laughs]

+ +

KEVIN: It is to be the world's largest community of underestimated founders. And I actually asked a question with the group yesterday was, "How do I go from, say, 50 to 500 in a few months but real genuine people that want to be community members like actually contribute and be active?" I'm still waiting for the answer to that question. I'm hoping it's going to come next week. [laughs]

+ +

CHAD: [laughs] So I'm curious, given your work in, and correct me if this is wrong, but I would say a more corporate space, in your work in international law firms and global public companies and that kind of thing. How has that experience either been different or the same as what you're trying to do now? And how do traditional companies approach issues like this?

+ +

KEVIN: So I get to work with...I have a day job, as I call it, but Diversity-X and supporting diversity is my passion. To address some of the passions that I have, the reality is not every workplace can or chooses to allow that to happen for employees. In certain companies, your role is your role. And if you want more, then go outside.

+ +

So for me, there are things I wanted to do that I don't get the opportunity to do in my workplace or in the way I want to do it in my workplace. So I started looking outside; well, who can I help that needs someone like me to help them with this sort of thing? And that's how I fell into helping startup founders. And that's where I found this absolute passion.

+ +

I think everybody who works with founders and startups is always energized in a way that incorporates the energies that sits in pockets in my experience. And you don't tend to see huge organizations. And this is not to say they don't exist; there are some that do but who are energized and focused on a purpose.

+ +

I think those that have purpose that's really, really clearly defined and embedded do have this energy of drive and innovation and disruption and even go as far as trying to have radical change. Others are trying to learn. And to be fair, to many organizations, some of this stuff is new to them. And they're learning, and it takes time, and you have to give them time, and you have to give them the opportunity to fail and make mistakes.

+ +

So there are a lot of companies that are trying to do the right thing, trying to be better, trying to embrace their people and the issues, and the things that their people care about but as well as balancing with the wider stakeholders because they have multiple stakeholders; it's not easy.

+ +

It's a tough balancing act for anybody in a leadership position in the corporate to say, "Well, look, we've got to deliver financial results. But also, we've got to think long term, but we're measured on short term." How do you do that? It takes a lot of work and effort, which is why I see the opportunity for startups, in particular, to operationalize this stuff early on. So that becomes embedded because retrofitting is very expensive and very time-consuming, and resource-heavy.

+ +

CHAD: Having lived and worked in the UK, China, Hong Kong, Russia, The United States, how are things different in all those places when it comes to work and issues like this?

+ +

KEVIN: Let me just quickly ask you a question see what you think. Where do you think was the hardest place of those locations to live and work?

+ +

CHAD: Hmm. Russia?

+ +

KEVIN: It's interesting.

+ +

CHAD: I don't know.

+ +

KEVIN: No, no, no. People would usually say, and people do say to me, "Oh, China must be really hard, or Russia must be really hard."

+ +

CHAD: Well, I went to visit China about two and a half years ago. And it completely changed my perspective on what China is like, and so that's why I didn't answer China. But I don't want to invalidate your perspective if China was the most difficult place for you. [laughs]

+ +

KEVIN: Actually, no. The United States was the hardest place, which is why in 2020, we made that decision, for multiple reasons, to return home back to the UK. It's the land of opportunity, but it's slipping by. They've got so much resource. They've got so much of everything. But there's such disunity in my perspective and in my lived experience.

+ +

But if you're an American, you might see it differently. If you're someone, an immigrant who got naturalized there, you may see it differently. But in my personal experience, and that's all I can talk to, was that this is a deeply divided country that's frittering away the opportunity to truly be the greatest country in the world.

+ +

And they talk about being the land of the free. I used to joke with my Canadian colleagues because I was in Detroit, so you look north. You look south, sorry, you look south to Detroit, which is the only place...and I use this as my pop quiz question of it's the only place in America, I believe, that if you look south, you're looking at Canada. But I used to say that's the land of the freer because truly, I actually felt more strict in the United States than living in Russia or in China.

+ +

You get told what to do. It's just done in a different way in the United States, and that's just my experience. But look, I lived there for three and a half years. It's not a lifetime by any stretch of the imagination. And it was a time when I guess many of the people I love and care about in America probably said, "Kevin, you are here at the worst time to be here.

+ +

CHAD: [laughs] Right.

+ +

KEVIN: And this is not the real America." But unfortunately, that was the America I experienced. So it was the hardest place for me.

+ +

CHAD: I think that that's actually where America gets into trouble is by continually saying, "This isn't the real America." And you can only say that for so long when we've been saying it for a long time. And so I think it's important to ask ourselves, isn't that actually the real America then? Sort of to your point of the VCs and not changing the demographics despite saying something is a problem and working at it over time. And, oh, we've made a percentage point of progress means that you're not really working on the problem or willing to change because you're probably not focused on the right things.

+ +

KEVIN: Yeah. And you think about the United States of America it's funny, the house I'm living in is 172 years old. It is older than so many places in the States, and yet I remember someone saying, "Oh, you're living in a 1950s house. That's a really old house." [laughs] It's like, it's almost a new build in the UK. America has this rich history to still create.

+ +

CHAD: And I think that's what lends us to being more aggressive when it comes to investment and more willing to take risks. So like you said, there are tons of opportunity and some tons of potential at the same time as there are probably real big problems.

+KEVIN: You know that saying about the rising tide benefits all?

+ +

CHAD: Yeah.

+ +

KEVIN: I think in VC, it has had a negative connotation because from the industrial gaslighting is yeah, there has been an increase in funding, but everybody got it. So the percentages of allocation didn't change. But also, America has that opportunity, in my view, to really rise everybody. Just take the education system; it should be the greatest education system in the world, bar none. The resources are there, the talent is there, the people are there, and they're hungry for that education. Heck, people from other countries scramble to get America to have a piece of that. But why is it not?

+ +

And I think it's because there's too much protection of certain groups and an unwillingness to be more open. But the more open you are to the different ideas, to the different viewpoints, to then finding the best place for us, I think it presents America with a huge, huge opportunity. So, you know, I'm probably [inaudible 29:14] [laughter] because really you should be the best. You say you're the biggest and the best, but people don't care about the size of your army, really. The everyday Joe in the UK, we don't think about that. I grew up thinking America was paved with gold, and I got there, and it's like, this is not quite the way I grew up. [laughs]

+ +

CHAD: Well, inside of America, there's a lack of that perspective, though, because when you can self believe that that's the case. And because you don't have a perspective on what it's actually like elsewhere, it's very easy to say, "Oh, we are the best."

+ +

KEVIN: Yeah, that's true. And look, who cares what country is the best in reality? [laughter] Sometimes I like to think I've got these three children. Right now, as children, they don't care. They just want to get on with people and have more friends and more relationships, and that's what they care about. But at some stage, I don't know where it starts or how it starts; we lose that. We lose that.

+ +

But you see that in founders, this ability to get past that, and they're trying to address it. At least the founders I'm trying to support they're really trying to break past these barriers of we're different, and we need to remain different to we are different. Let's embrace that. And how can we use that to our advantage?

+ +

CHAD: Yeah. And I think that to take a step back, I'm a big believer in continuous improvement and always trying to be better. And I think that when you find yourself in a position where you've stopped doing that, it's no good for anybody. And it's very clear to me that there's the next frontier for improving ourselves, and the companies that we work at, and the world in which we live is all of these things that we've talked about today. And so I really wish you the best with Diversity-Xand with what you're trying to do. And please keep in touch, and we should talk further, maybe offline after this recording, about how we might be able to help more.

+ +

KEVIN: Brilliant. And thank you so much for having me on this podcast. I'm so, so grateful. Thank you.

+ +

CHAD: Kevin, if folks...you said your email address before, but do you want to say it again or other places where people can reach out to you?

+ +

KEVIN: Yeah, so it's kevin.withane that's W-I-T-H-A-N-E @gmail.com. Or you can find me on LinkedIn. I'm very visible there.

+ +

CHAD: And you can subscribe to the show and find notes along with a transcript of this entire episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and we'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Kevin Withane is the founder of Diversity-X: a community to help underrepresented founders who are trying to make a positive impact in the world thrive, scale, and grow.

+ +

Chad talks with Kevin about giving underestimated founders connections and access, creating a venture fund, and creating a platform via DiversityX.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Kevin Withane, founder of Diversity-X. Kevin, thanks for joining me.

+ +

KEVIN: Chad, thank you so much for having me on this show.

+ +

CHAD: Kevin, I know you have deep expertise and background in law and ethics and compliance, particularly when it comes to diversity, equity, and inclusion issues. And that has led you to create Diversity-X. And so what is Diversity-X?

+ +

KEVIN: Diversity-X is a community for underestimated founders trying to make a positive impact in the world. We're working on creating a VC fund for it. And also, it's an ecosystem to support those underestimated founders and help them thrive and scale, and grow.

+ +

CHAD: That's great. What kind of support and community are underestimated founders lacking, and how does Diversity-X fill in that gap?

+ +

KEVIN: I think it's a mix of connections and access. I use the term underestimated rather than what many people term as underrepresented because there are plenty of people of color founders, plenty of LGBTQ+ founders, plenty of female founders, disabled founders, veteran founders. There are lots of them in the world, so they are represented.

+ +

They're just underrepresented in the equitable allocation of capital and particularly venture capital at early stage, which sees many of these founders not necessarily succeed or have to work that little bit harder just to get a starting place where many others get funding a lot earlier and a lot easier in their journey. And I'm not saying raising capital is easy at all for anybody, but it's easier for certain groups of people than it is for others.

+ +

CHAD: What makes it easier?

+ +

KEVIN: I'm going to be candid in my views. I think it makes it easier if you're a white male; nothing against white males, but it's easier. There's that privilege. But also, you look, sound, probably have a lot of similar backgrounds to the people who are allocating the money who have control over whether they invest or don't invest in the startups. And I think; also, they tend to have better connections or better ins. It is a generalized statement, but data shows that 93% of VC money typically goes to white male founders. So it's backed up by data to an extent.

+ +

CHAD: Right. And it doesn't even need to be ill intent. In some cases, there might be, but it doesn't need to be. So much of the VC world is about connections, and what you've done previously, and who you know, and the intro you're able to get. And then, when you finally get the meeting, if you're out pitching something that just isn't even on the radar of the typical VC, they're not going to connect with your idea in the same way that you do.

+ +

When we're building products, having a diverse team of people allows us to see all the different aspects of that product and have people saying, "Well, what about this? From my background or my perspective, I understand that this is a particular concern for women around the safety of this," or something. And people say, "Oh yeah, I didn't even realize that."

+ +

KEVIN: Yeah, that's a great point. Within the Diversity-X community, very early on, I realized one of the probable flaws for VC is, let's be honest, it's a very male-dominated industry. I think they are making real strides to change it, make it more open, more accessible to females and people of color. But essentially, for the most part, it is people who look and sound the same and typically are a white male.

+ +

And there's no disrespect, but sometimes you can get a pitch about femtech. And while she may go, "Yeah, I can see that this could be a problem," you don't know because the fact is you're not a woman. You just don't know. And I experienced that very early on speaking to a female founder who's part of the community, and she's really trying to do some amazing stuff. But at first, I was like, "I can empathize with the issues you're trying to address here and the problem, but that's as far as my knowledge goes."

+ +

And it made me wonder if VCs who are getting this sort of pitch will probably turn them down. They can't understand the problem. So, therefore, they can't understand what the solution that the founder is trying to come up with is really trying to address. And so pushes it by because they don't have that expertise, and that's not their fault; it's just there's a lack of diversity in the VCs themselves to be able to address that.

+ +

But then you hear these stories about male founders coming with a femtech solution almost on the back of a cigarette packet. And they're getting X amount of dollars to go and do some research and try and start building a product around what their idea is. And yet many of the female founders are scratching their head; well, we didn't have an in to that VC, so we never got in. And yep, so we don't get funding for what is a problem that we actually experience ourselves, and we're trying to address.

+ +

CHAD: This conversation reminds me of a conversation that I had in 2018 in Episode 279 with Alex Friedman, the co-founder of LOLA, which is a feminine products company. And she talked about how it was clearly uncomfortable for the people that they were talking to to talk about these kinds of things.

+ +

So even that can have an aspect to it where like...and then men may be more comfortable talking with men about feminine products than they are to women about them. And it just permeates the whole conversation when you're trying to launch a product that you need money for if it's uncomfortable, or it's foreign, or all of those things.

+ +

KEVIN: Absolutely. The industry needs to change in a couple of ways, I see. There needs to be greater emphasis on VCs building networks and connections into the communities and to the founders that are underestimated people of color, female from different socioeconomic backgrounds that may not have been able to afford to go to MIT or Harvard but super-smart people solving real-life and real-world problems.

+ +

And VCs themselves need to look at their own diversity, like, it is not diversity just for the sake of well, we need X number of women now with investing power, or we need more people of color to invest. It's because those people bring their lived experiences, which is the same for any business.

+ +

It's no different if you're a big corporate. The reason for diversity is the same. It's to get that cognitive diversity, that cognitive difference of lived experience, which in the end, bring into your field. It's something as human beings we can't detach ourselves from. We can't detach ourselves from our lived experience. We take that everywhere we go.

+ +

CHAD: So what's involved in creating a venture fund?

+ +

KEVIN: A lot more work than I thought.

+ +

CHAD: [laughs]

+ +

KEVIN: I don't have a venture background, so I'm already 700 steps behind everybody else that is doing it. Even the good guys who are trying to actually address this problem, many of them actually come from a venture background. But I'm looking out there, and I'm seeing people like Matt the VC, Arlan Hamilton, and they inspire me that I can do this. Because, ultimately, I had a soft conversation with a family office just to try and explain what I'm doing and see if there'd be interest. And they actually liked the idea.

+ +

But they said to me, "Who are your competitors out there?" And I said, "Look, you can think of me as naive, but the reality is I don't think I have any competitors." And the reason is because we have a mission. Our vision is a world where you don't have underestimated founders.

+ +

Our mission is to grow the world's biggest community of underestimated founders and support those that are VC-ready and the right fit for funding that are going to be successful with capital. And whilst there are other companies and funds doing this, they have niches where they focus on certain areas. We're much broader.

+ +

But ultimately, no matter how much I raised in the fund, it's never going to be enough. It's never going to be enough to meet the gap that there is right now and the opportunity. So when you say competitor, every time an underestimated founder gets funded and gets given the opportunity to really address the problem that they're trying to tackle, that's a win for me because it's helping my mission and the vision. So that's the way I look at it.

+ +

And yes, that is a little bit naive, maybe. But you look at Elon Musk, and you look at founders who are trying to do amazing things. And you don't really knock them down for their grand visions. You have to aim high, and that's what we're trying to do at Diversity-X.

+ +

CHAD: So I noticed that you are particularly focused on the UK and Europe. And in my experience, the investment community tends to be different between the United States and Europe. How have you found that, and has that been adding a challenge on top of a challenge?

+ +

KEVIN: Yeah, it is adding a challenge on top of a challenge. It is different. I think the U.S., in some senses, is much more progressive, much more open. It's funny, I was talking to a friend, and I was saying...I can't really talk numbers because I don't want to get in trouble with the FCA. But I said to him, "This is the sort of size of the fund I'm looking to raise." And he is an American. And he just looked at me and said, "Why?" And I said, "Well, you need sort of skin in the game. You need this, this, and this."

+ +

He looked at me and said, "You are the skin in the game. Your passion comes through." Guys in America, people will be looking at you, saying, "You're way too small. You need to go much bigger than this." And I said, "But skin in the game, skin in the game, skin in the game." He said, "Don't tell me about that. Go big and see if people will buy into it." And that's I think much more of the view across the pond. There's much more appetite.

+ +

And I think for European VCs and particularly those probably starting out trying to address some of the issues that Diversity-X hopes to address, we've got to move probably and work hopefully in tandem with the more progressive, more open, more solution-oriented VC funds that are coming from the U.S. Because quite frankly, they are coming here now. They're coming to UK and Europe. But the reason I wanted to start in the UK and focus on the UK and Europe is that's where I'm based. That's where the best part of my knowledge is. Although interestingly, I guess my network is probably from the LP side, probably stronger in the U.S. So we'll see how that pans out.

+ +

CHAD: I assume that there are some legal requirements to starting a venture fund. Or can anybody do it, I guess is the...[laughs]

+ +

KEVIN: Maybe this is part of the problem as well as, the bar for entry just to start a fund is high, and it's expensive. So I guess I'm blessed that I've had the opportunities I've had in the past to be able to build something to be able to start this. But yeah, it's a myriad. And as a lawyer and someone who's even done transactional work on private equity and even helping some startups on fundraising and seeing how it works, it is very difficult. And you could be dealing with multiple jurisdictions depending on where your limited partners are. So there's a lot to factor in.

+ +

And then it's not just the legal fees; it's the fund administration and the fund management. For instance, in the UK, are you going to be regulated if your fund doesn't need to be regulated? Or are you going to be authorized on your own, or are you going to use an umbrella? What does that mean? So it's a real steep learning curve.

+ +

And I've got to admit, in my personal journey, there have been too few who have responded to my request just for help and advice, including what I would consider...I use this as the good guys, but the people trying to address the same problems that I am either focused on female. You reach out, but there's no return call. But there is one person who's a traditional fund; he is a white male VC. But honestly, he came back. We had a call. We talked about stuff. He said, "Keep in contact. Let me know how it's going," and he's tried to help me.

+ +

A couple of weeks later, I didn't hear from him, and then all of a sudden, an email popped up, or a message popped up saying, "Oh yeah, sorry it's taken me a couple of weeks to get back to you. But I just wanted to make sure that here's an introduction. This could be the partner you're looking for blah, blah, blah." I was blown away by that, that kind gesture. Somebody who just literally could have had a call with me said, "Yeah, not interested in this, never going to go anywhere. Why exert any effort?"

+ +

CHAD: That's great. You mentioned it is difficult. It's always difficult to start something new. But you're doing it alone. You don't have a partner.

+ +

KEVIN: No. I'm on the hunt for a partner. It's like dating, I guess. You keep trying to kiss a lot of frogs to find that person. Ultimately, knowing that I'm going to get challenged, rightly so, on track record, I would like to find a partner who has VC experience, who buys in deeply to the concept, and the mission, and the vision that we have and is looking to build a VC firm, not a fund, i.e., this is not a one and done exercise. This is about creating over multiple funds and, hopefully, generationally growing this to something really special.

+ +

CHAD: Well, if you're listening, and that describes you, get in touch with Kevin. [laughs]

+ +

KEVIN: Absolutely.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: In the meantime, while you're working on building this venture fund, you said, okay, I'm going to start building a community right away, right?

+ +

KEVIN: Yep.

+ +

CHAD: And when it comes to platform, how are you doing that? Are you using something off the shelf? Are you piecing it together? How's it going?

+ +

KEVIN: It's such hard work. Who would have thought? My wife laughs at me because since she's known me, every time we go into a town, or a village, or a shop that has a community board, I'll stop and read it. And she would laugh. She's like, "It's such a geeky thing to do." And I was like, "I love community. I like to know what's going on, what's happening."

+ +

I presumed that it's, therefore, relatively easy to build one. Then I was very nervous, and I was like, I don't know how to get started. And somebody who's in the community but also just an amazing person, Amy, she said to me, "Dude, just get started. Stop procrastinating. Just start a WhatsApp group," so I did.

+ +

And then I invited a couple of friendly faces, i.e., friends, and said, "Please, can you join this group?" And then I invited a couple of founders that I had just connected with and just started having conversations with. And from that moment...and this was early October, and then my son went into hospital. But from that moment, it started growing. So beginning of October 2021 to date, we have about 60 founders, which I think is not bad. And we use a WhatsApp group.

+ +

Then I had some conversations and got some feedback from the founders. And they said, "Look, we need some more organization because our feed is blowing up with the amount of traffic going through it. So we need some sort of structure. We need some resources and different things." So I was looking around, and I was like, by the end of day, what can I get for free? Because I'm not making any money on this. And what can I get for free? So we moved it...we didn't move it. We set up on Slack.

+ +

But I've got to say despite having more organization, the bulk of the activity still works around WhatsApp. But I will say this; I'm not a tech person, so I do need support on this. So if there's anybody who wants to volunteer to give me some advice, or help, or just come onboard maybe in some capacity, I am trying to build a platform that's web-based, maybe even app-based, that can help facilitate conversations, learning, investor matching.

+ +

Because part of what I'm doing, whilst I haven't raised a fund yet, is that there are members in this community who need support right now, financially. I can't give that to them, but there are good people out there, good angels, or even some of them, probably VCs that would. And so it's trying to create a platform where we can connect those founders, those underestimated founders, and I think predominantly angels.

+ +

But if any VCs want to join, that'd be great too, just to help these guys get started. They need to start moving forward, and they can't wait for me to get a fund up and running. So whatever I can do. So I am looking at building a platform. It's just in the question of how do I do this? And is there anybody to help me?

+ +

CHAD: If you're a founder who wants to get involved in this community and think it would be beneficial to them, where do they go to do that?

+ +

KEVIN: I'll say reach out to me either email me kevin.withane@gmail.com or connect with me on LinkedIn, two best Places. We'll chat. But generally, the community is open. If you're an underestimated founder, if you just tick that box, you're in. Come and learn, grow, support, be supported. You'll see that.

+ +

We've had some new members in the last week who have just said, "This is a really interesting community." And I spoke with one today that said, "I'm generally very wary, particularly about being around people who have similar businesses to what I have, you know, competitors." And I said, "Why? Why are you scared of competitors?" And she's in a field which relates to sustainability.

+ +

I said to really deliver the sustainability you want to deliver, it's about collaboration, and that's what this group has. It has that in spades, people working together, people supporting each other, e-platform. They are going gangbusters on sharing information. This is what we use. This is a great book. This is a great resource. These are great people to go and speak to. And so it takes the pain and reduces the stresses of being a founder, which you've got to do so many different things. And generally, you've got to do all of those things on your own with a very few number of people supporting you.

+ +

CHAD: And I imagine that a lot of the people in the community so far are people who invite each other in.

+ +

KEVIN: Yeah, and there are other people that I've met who have contacted me and said, "Look, we've got this startup. We're looking for an advisor, or we're just looking for a bit of support," or even someone saying, "We're looking for investment." So I'm very upfront where we are at the stage we are. But I'll introduce him to the community, and they start embedding themselves in it. And it's growing. As I said, the mission I don't know if it's bold enough, but I think it is bold.

+ +

CHAD: [laughs]

+ +

KEVIN: It is to be the world's largest community of underestimated founders. And I actually asked a question with the group yesterday was, "How do I go from, say, 50 to 500 in a few months but real genuine people that want to be community members like actually contribute and be active?" I'm still waiting for the answer to that question. I'm hoping it's going to come next week. [laughs]

+ +

CHAD: [laughs] So I'm curious, given your work in, and correct me if this is wrong, but I would say a more corporate space, in your work in international law firms and global public companies and that kind of thing. How has that experience either been different or the same as what you're trying to do now? And how do traditional companies approach issues like this?

+ +

KEVIN: So I get to work with...I have a day job, as I call it, but Diversity-X and supporting diversity is my passion. To address some of the passions that I have, the reality is not every workplace can or chooses to allow that to happen for employees. In certain companies, your role is your role. And if you want more, then go outside.

+ +

So for me, there are things I wanted to do that I don't get the opportunity to do in my workplace or in the way I want to do it in my workplace. So I started looking outside; well, who can I help that needs someone like me to help them with this sort of thing? And that's how I fell into helping startup founders. And that's where I found this absolute passion.

+ +

I think everybody who works with founders and startups is always energized in a way that incorporates the energies that sits in pockets in my experience. And you don't tend to see huge organizations. And this is not to say they don't exist; there are some that do but who are energized and focused on a purpose.

+ +

I think those that have purpose that's really, really clearly defined and embedded do have this energy of drive and innovation and disruption and even go as far as trying to have radical change. Others are trying to learn. And to be fair, to many organizations, some of this stuff is new to them. And they're learning, and it takes time, and you have to give them time, and you have to give them the opportunity to fail and make mistakes.

+ +

So there are a lot of companies that are trying to do the right thing, trying to be better, trying to embrace their people and the issues, and the things that their people care about but as well as balancing with the wider stakeholders because they have multiple stakeholders; it's not easy.

+ +

It's a tough balancing act for anybody in a leadership position in the corporate to say, "Well, look, we've got to deliver financial results. But also, we've got to think long term, but we're measured on short term." How do you do that? It takes a lot of work and effort, which is why I see the opportunity for startups, in particular, to operationalize this stuff early on. So that becomes embedded because retrofitting is very expensive and very time-consuming, and resource-heavy.

+ +

CHAD: Having lived and worked in the UK, China, Hong Kong, Russia, The United States, how are things different in all those places when it comes to work and issues like this?

+ +

KEVIN: Let me just quickly ask you a question see what you think. Where do you think was the hardest place of those locations to live and work?

+ +

CHAD: Hmm. Russia?

+ +

KEVIN: It's interesting.

+ +

CHAD: I don't know.

+ +

KEVIN: No, no, no. People would usually say, and people do say to me, "Oh, China must be really hard, or Russia must be really hard."

+ +

CHAD: Well, I went to visit China about two and a half years ago. And it completely changed my perspective on what China is like, and so that's why I didn't answer China. But I don't want to invalidate your perspective if China was the most difficult place for you. [laughs]

+ +

KEVIN: Actually, no. The United States was the hardest place, which is why in 2020, we made that decision, for multiple reasons, to return home back to the UK. It's the land of opportunity, but it's slipping by. They've got so much resource. They've got so much of everything. But there's such disunity in my perspective and in my lived experience.

+ +

But if you're an American, you might see it differently. If you're someone, an immigrant who got naturalized there, you may see it differently. But in my personal experience, and that's all I can talk to, was that this is a deeply divided country that's frittering away the opportunity to truly be the greatest country in the world.

+ +

And they talk about being the land of the free. I used to joke with my Canadian colleagues because I was in Detroit, so you look north. You look south, sorry, you look south to Detroit, which is the only place...and I use this as my pop quiz question of it's the only place in America, I believe, that if you look south, you're looking at Canada. But I used to say that's the land of the freer because truly, I actually felt more strict in the United States than living in Russia or in China.

+ +

You get told what to do. It's just done in a different way in the United States, and that's just my experience. But look, I lived there for three and a half years. It's not a lifetime by any stretch of the imagination. And it was a time when I guess many of the people I love and care about in America probably said, "Kevin, you are here at the worst time to be here.

+ +

CHAD: [laughs] Right.

+ +

KEVIN: And this is not the real America." But unfortunately, that was the America I experienced. So it was the hardest place for me.

+ +

CHAD: I think that that's actually where America gets into trouble is by continually saying, "This isn't the real America." And you can only say that for so long when we've been saying it for a long time. And so I think it's important to ask ourselves, isn't that actually the real America then? Sort of to your point of the VCs and not changing the demographics despite saying something is a problem and working at it over time. And, oh, we've made a percentage point of progress means that you're not really working on the problem or willing to change because you're probably not focused on the right things.

+ +

KEVIN: Yeah. And you think about the United States of America it's funny, the house I'm living in is 172 years old. It is older than so many places in the States, and yet I remember someone saying, "Oh, you're living in a 1950s house. That's a really old house." [laughs] It's like, it's almost a new build in the UK. America has this rich history to still create.

+ +

CHAD: And I think that's what lends us to being more aggressive when it comes to investment and more willing to take risks. So like you said, there are tons of opportunity and some tons of potential at the same time as there are probably real big problems.

+KEVIN: You know that saying about the rising tide benefits all?

+ +

CHAD: Yeah.

+ +

KEVIN: I think in VC, it has had a negative connotation because from the industrial gaslighting is yeah, there has been an increase in funding, but everybody got it. So the percentages of allocation didn't change. But also, America has that opportunity, in my view, to really rise everybody. Just take the education system; it should be the greatest education system in the world, bar none. The resources are there, the talent is there, the people are there, and they're hungry for that education. Heck, people from other countries scramble to get America to have a piece of that. But why is it not?

+ +

And I think it's because there's too much protection of certain groups and an unwillingness to be more open. But the more open you are to the different ideas, to the different viewpoints, to then finding the best place for us, I think it presents America with a huge, huge opportunity. So, you know, I'm probably [inaudible 29:14] [laughter] because really you should be the best. You say you're the biggest and the best, but people don't care about the size of your army, really. The everyday Joe in the UK, we don't think about that. I grew up thinking America was paved with gold, and I got there, and it's like, this is not quite the way I grew up. [laughs]

+ +

CHAD: Well, inside of America, there's a lack of that perspective, though, because when you can self believe that that's the case. And because you don't have a perspective on what it's actually like elsewhere, it's very easy to say, "Oh, we are the best."

+ +

KEVIN: Yeah, that's true. And look, who cares what country is the best in reality? [laughter] Sometimes I like to think I've got these three children. Right now, as children, they don't care. They just want to get on with people and have more friends and more relationships, and that's what they care about. But at some stage, I don't know where it starts or how it starts; we lose that. We lose that.

+ +

But you see that in founders, this ability to get past that, and they're trying to address it. At least the founders I'm trying to support they're really trying to break past these barriers of we're different, and we need to remain different to we are different. Let's embrace that. And how can we use that to our advantage?

+ +

CHAD: Yeah. And I think that to take a step back, I'm a big believer in continuous improvement and always trying to be better. And I think that when you find yourself in a position where you've stopped doing that, it's no good for anybody. And it's very clear to me that there's the next frontier for improving ourselves, and the companies that we work at, and the world in which we live is all of these things that we've talked about today. And so I really wish you the best with Diversity-Xand with what you're trying to do. And please keep in touch, and we should talk further, maybe offline after this recording, about how we might be able to help more.

+ +

KEVIN: Brilliant. And thank you so much for having me on this podcast. I'm so, so grateful. Thank you.

+ +

CHAD: Kevin, if folks...you said your email address before, but do you want to say it again or other places where people can reach out to you?

+ +

KEVIN: Yeah, so it's kevin.withane that's W-I-T-H-A-N-E @gmail.com. Or you can find me on LinkedIn. I'm very visible there.

+ +

CHAD: And you can subscribe to the show and find notes along with a transcript of this entire episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and we'll see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+M1tM-dvX + + ]]> + + Chad Pytel + + + 411: Civic Innovation with Jay Nath + https://podcast.thoughtbot.com/411 + 8335369d-271e-4482-890c-a29c98d2f8a5 + Thu, 17 Feb 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Jay Nath is the Co-CEO of City Innovate, a govtech company streamlining procurement through enterprise software and innovative frameworks. + +He talks with Chad about how he focuses on helping governments be more effective, responsive, and zeroed in on helping their constituents whether on a small city or a big state scale. + 34:56 + no + + + Jay Nath is the Co-CEO of City Innovate, a govtech company streamlining procurement through enterprise software and innovative frameworks. +He talks with Chad about how he focuses on helping governments be more effective, responsive, and zeroed in on helping their constituents whether on a small city or a big state scale. +City Innovate (https://www.cityinnovate.com/) +Follow City Innovate on Twitter (https://twitter.com/CityInnovate) or LinkedIn (https://www.linkedin.com/company/city-innovate/) +Follow Jay on Twitter (https://twitter.com/jay_nath) or LinkedIn (https://www.linkedin.com/in/jaynath/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Jay Nath, Co-CEO of City Innovate and former Chief Innovation Officer of San Francisco. Jay, thanks for joining me. +JAY: Yeah, Chad, thank you for having me. +CHAD: I assume based on the name and the fact that I've done my research...but I assume based on the name of City Innovate and the fact that you're a former Chief Innovation Officer of San Francisco that what City Innovate might be. But why don't you give everybody an overview of what it is? +JAY: Thank you, Chad. So City Innovate is focused on helping governments be more effective, responsive, and focused on helping their constituents, whether it's a small city government or a big state. And the way that we've been doing this is really sort of an interesting; I'd say wonky place. We found that there's a pressure point in government around documents and specifically on procurement. +And why is that interesting? Because what I've seen is if you want to work with government and collaborate, whether it's even volunteering or you're a startup, and you want to work, procurement is often that channel. And it's not really a channel; it's more of a barrier, a byzantine process. You can think of this from a technical frame, creating an API, a read/write API to make that process much more streamlined on both sides, helping governments be able to find the best partners to solve their big challenges. +And on the other side, folks from all walks of life, whether you're a massive company or you're a founder in a garage, how do you actually connect those two? So we're really working at that intersection, and it's something that I find a lot of value in and importance in. And surprisingly and maybe not surprisingly, there's a lot of need for technology to help connect those dots. And ultimately, I think what I can do is make that process more inclusive and lower the barriers of entry so that people from different communities can participate and help make their communities better. +CHAD: So your clients at City Innovate are cities and governmental organizations. Are you just delivering a product to them, or are you often helping them work better too? +JAY: It's a bit of both. From a product standpoint, we're really in the B2B space and very much enterprise, if you will. And part of that standard enterprise SaaS offering is also support services, and that can be training, that can be professional services to help them in thought leadership in different ways. And that's exactly what we do. So we not only have our product, but we help them through something called agile procurement. So it's really borrowing from the software development methodology and applying the same principles and approaches to developing and finding the right partner and being more agile and iterative through that process. +And historically, it's been very waterfall and very stilted and overly structured. So really being more focused on outcomes, really being focused on getting data into the process so that you can actually do, let's say, a bake-off and get more information before we make that decision. And it's surprising, Chad, folks in government are often buying multimillion dollars, tens of millions of dollars technology systems without actually trying it out. And think about your personal life. You test drive a car. You look through a home. You make these big decisions with a lot of data and evidence. +And in government historically, they've been using paper documents to make that decision, RFPs responses, and marketing material. And it's hard to sift through and say, "Hey, what's real and what's not?" So we've been really helping them think through a more agile evidence-based approach, and our software supports that. And so yeah, it's really leading a movement about changing how they think about partnering with the vendor community or contractors. +CHAD: So one of the things that is probably interesting about this and maybe a little bit meta is that this is what you help them do. And so you have to go through that process with them of being procured. [laughs] +JAY: It is meta. You're absolutely right. [laughs] +CHAD: In order to become the vendor that they use. +JAY: That's right. +CHAD: What are the challenges inherent in that, and does it ever get in the way? And how do people, either your clients, come to you, or how do you find them? And how do you work through that challenging process of government procurement? +JAY: Well, the thing is, since we know this space really well, we know how to navigate those different channels, the byzantine processes I mentioned before. I think one of the things I worked on when I was in the City of San Francisco was a program that brought startups and governments together, and we had an educational component. We'd help founders better understand that exact question. +How do you actually get contracts with government? And there are no books that are out there. There's no real knowledge out there. And so, we help them talk about the ten different pathways to doing that. So it's a bit of a hidden art, if you will. And I think there needs to be more conversation and more resources for founders if they're looking to go into the public sector to be able to navigate that. So we know that really well. And we're trying to really help broaden access to that knowledge. +CHAD: I assume that the clients you end up getting are people who are...or are governments who want to be better. Otherwise, they wouldn't choose your solution. [laughs] +JAY: That's right. Well, I think their motivations are multifold. Some of the governments want a process that's more efficient. They know that they can be more productive. They have maybe staffing constraints, and they have a lot of work, so we can help them on the productivity side. There are other governments that are really focused on hey; we need to get better partners out there. We've been working with the same folks over and over again. How do we work with those innovators in our community? So there's that crowd. +And then there's, I think, another group of folks who are saying, "Hey, we wanted to make sure that this process is more inclusive. We want to work with folks who are from different backgrounds who may be underrepresented. How do we make this process more streamlined, more efficient so that they're able to participate more effectively?" So I think the motivations can be different, but it's really at the end of the day centered around this idea of digital transformation and service design that allows these two different worlds to be able to communicate and work together more effectively. +CHAD: How long is the typical sales cycle for a client? +JAY: Man, yeah, [laughs] it can range from weeks, I would say to months and going over 12 months. It can be 12 to 18 months, trying to get in, doing a trial maybe, giving them that certainty, and then securing budget and that annual process of waiting for that budget approval to happen. So it is not for the faint of heart, especially enterprise software within government is really something that requires a lot of different approaches. +So partnerships with bigger companies that have the distribution channel, that might have those relationships, that might have those contracts, how do you actually work with them to shortcut the long procurement process? How do you leverage folks like AWS and other cloud providers that may already have a relationship so that you can, again, piggyback off of that? So I think there are a number of different ways to try to compress that timeframe. But it's not a walk in the park, Chad. +CHAD: So, in that environment, how did you get started with City Innovate? How long was it until you were able to get your first real customer? And how did you bridge the gap between founding and being in the market? +JAY: That's a great question. So being in the public sector, I knew that procurement is a huge challenge and also a pressure point and a leverage point to unlocking a lot of value. And so the work that we had done with startups and government the first experience that we had was amazing. We had a startup that came in and helped blind people navigate through the airport here in San Francisco SFO in four months and truly a collaboration with the startup and the airport staff. And unfortunately, when it came to procurement, it took two years for them to actually get into contract. +CHAD: Wow. +JAY: For a startup, that's like dog years. That's like an eternity. And so we really knew that we had to tackle that. So we introduced a methodology called challenge-based procurement that, as I spoke to earlier, is more agile, evidence-based, and outcomes-based. And that really leveled the playing field for these young companies to show that hey, we can actually go in here and help you solve that problem. You don't have to work with a big publicly-traded company to do this work and spend a lot of money. We can be more nimble and agile. And so that's really where I started to dig in deeper into procurement. +And that work got federally funded because it created a lot of jobs. And we've had hundreds of startups all across the U.S. It's an international program called STIR, Startup In Residence, and really proud of that work. Our mayor, unfortunately, died unexpectedly. So we looked at hey, where do we move this program? And it did make sense for a city to manage a multi-city program, and so City Innovate came to mind. +At the time, they were a non-profit. I'd been working with my co-CEO co-executive director at the time. It was a nice, beautiful transition into that. And at that time, I said for myself personally, where do I see impact, and what can I do? And for me, the idea of entrepreneurship, the idea of products making impact in government, I saw how much impact was being made. And so City Innovate has really become that vehicle for myself and the organization to really scale that idea out. +CHAD: You mentioned you have a co-CEO. How did that come about? And how do you split the responsibilities between the two of you? +JAY: Well, the good thing is we're really great complements. So his focus is really on go-to-market and focusing on how do we get this in the hands of our customers or prospective customers? And I've always been very interested on the product side. I was formerly a VP of product at a startup before my time in government, and so that scenario I find keen interest. And I deeply understand the personas and the use cases of government, having spent a lot of time there. +And so that empathy and understanding and building a product around that and having somebody who can help get that product in the hands of government navigating through those difficult processes. It really does take that. You can have a great product, but without that ability to get it in the hands of your customers, especially with governments, it's really challenging. +CHAD: Is there any in particular...like, why Co-CEO and not two other C-level roles, one of you CEO, one of you CIO? +JAY: I don't think we've spent too much time debating that. And that might change, I think to your point to better describe our focus areas. Maybe my role changes to chief product officer and his to a different role title. I think if you're starting a company, you've got a lot of things to worry about. And it just seemed like a...yeah, I don't think there was much thought in it. +CHAD: Yeah. That's interesting, though. You alluded to what you were doing before the City of San Francisco. Well, let's dive into that a little bit more. And specifically, what were you doing, and then why did you join the public sector? +JAY: So I was VP of Product at a company called SquareTrade. It was a wonderful journey. We were working with, again, something kind of wonky and a space that was anti-consumer. It was around warranties, specifically electronic warranties. And we were in the eBay marketplace and expanded way beyond that in later years. But when I was there, we really took a contrarian perspective and being inspired by Zappos and many companies that are really focused on the consumer. +We changed that value proposition to say, hey, can we build a product that people love, a warranty that actually works? And so we did crazy things like we would actually give you the money before you returned the product. We would have the shipping label. And we wouldn't ask any questions. We did amazing things. But that wasn't just because we were focused on the user experience. We also had data to back it up. +We knew that, hey, there are a certain percentage of people who are going to return rocks. And there's a certain percentage of people who are going to do certain things. So we had a lot of information going in. The other thing we knew is that we could own the whole stack, the underwriting, the retailing. And we also knew the business. So that was a great experience. +But I really was missing this connection to the public good and doing something that was having impact in a really tangible way. That's when I saw why don't I work for a city I love deeply and care about? And that really drove me into thinking about public service. I had some friends who were in it, and they convinced me that I should take a look at that. +And I definitely have found the work that I had been doing in public service to be extremely rewarding and just a unique opportunity. Especially if you're a technologist or a product mindset or an engineering mindset, that is such a rare perspective in government, and being able to bring that in, you can do amazing things. +We all know the healthcare.gov and how that was imploding and exploding. It almost brought down a presidency and administration, and it was saved. I think many people know the story, especially in your audience. That was really folks in Silicon Valley saying, "Hey, I'm going to raise my hand and volunteer my time. I might be working at a big company and making a lot of money, but I will take my time out and try to help." And they did. They turned it around. +And I think that ethos and that mindset of giving back is something that's animated my interests in public sector and the fact that there's so much need, especially from the tech community, in helping the government out. +CHAD: Now, you didn't get started as the City Innovation Officer. [chuckles] So you got started as the Manager of Enterprise CRM for the City of San Francisco. +JAY: That's right. Yeah, it was interesting. Yeah, definitely. +CHAD: I think that public sector work is maybe a little bit of a black box for people. I know it is for me. You mentioned you knew some people, but I assume that was not a political appointment job. +JAY: It was not. +CHAD: So, how does one get into that, find it, and get that job and that kind of thing? +JAY: I think I took a very rare and uncommon path. So as you noted, I came in helping stand up a call center. So a 311 one call center which is, for the folks who don't know, 311 is for non-emergencies, potholes, et cetera, starting a business, how do I do that? So yeah, set up a CRM system 24/7. It was a great experience and actually much harder than I thought. I was working harder there than I had at the startup, so breaking some stereotypes or at least some ideas that I had in my mind. +But I quickly found myself saturating that opportunity and saying, hey, what do I want to do? And this was at the time that Obama had just come into office, and he had a call to action. His first memo in office was around openness and collaboration and that I felt was really compelling to me. I had the opportunity to say, "Hey, let me reach out to folks in White House. I don't have any relationships there, but I have this badge of San Francisco." And that started me on a journey of innovation, civic innovation. +And I did some really interesting things with great startups like Twitter at the time. We created a read/write API, the first of its kind in local government. Almost got fired by the [inaudible 16:45] [laughter] and trying to explain just like, why are you opening a channel into government to let people do horrible things? And so it was an interesting conversation. But Gavin Newsom was the mayor at the time then, so you can see it's going back in time. +CHAD: [laughs] +JAY: But my journey then sort of said, hey, let's continue building data standards and doing good work. And I was recognized by the mayoral campaigns that were running. And so they wanted to sort of say, "Hey, we need somebody in innovation in the mayor's office." So I got recruited into that role, the first of its kind in San Francisco and in the U.S. +So it was just a great opportunity to really help define and set a foundation for what does civic innovation mean? What does that look like? And we had a small office, and we did some really interesting work at the nexus of collaboration. That's really what I think is what we tried to do is make government more permeable, more accessible for people who are driving innovation in their communities to be able to participate in government. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: If someone's interested, how might they get involved in contributing to the public sector? +JAY: I think there's a couple of different ways. So one way, Chad, is that governments are often putting a lot of data out there. There has been an open data movement that we had led, and it's now a national global movement. So you can find data, and you can create a data product around that and giving more insight into visibility and into issues. You can volunteer with a specific department. They're looking for those skill sets, so you can do that. +You can also look for digital services offices. So those are becoming much more commonplace in governments if that's your thing. There are definitely ways to raise your hand and try to contribute. Folks are always looking for it. And if you don't see that opportunity, make that opportunity happen. Reach out to your council member. Reach out to a department head and say, "Hey, I've got this great superpower. I want to help you do better." And I guarantee they will listen because they're often strapped for resources. +CHAD: How do you know when you should pursue a more general product that might be useful to governments versus like, oh, if I could get in there and contribute? How do you make that distinction in your mind? +JAY: Well, I don't think there needs to be. So you can come in and have maybe a frame of hey, let me help my local government. And you might find opportunities while you're working there. They're using Microsoft Word and Excel to do something that really should be productized so you can think about it from that frame. Or you might have built a product for an adjacent market or for another need and say, "Hey, is there an opportunity to actually reframe this product that I have in the government context?" It might be a content management system. It might be a lot of different products can be reframed in that context. +So the way that we actually became a product company from a non-profit was just doing that. We got invited to bring our methodology of agile procurement. And so we had in the back of our mind this idea that I bet if we go there, it's going to be kind of dusty. There's going to be a lot of broken tools, and that was the case. They were using 40-year old technology to manage sometimes billions of dollars of purchasing. And so we saw something that you normally wouldn't have that vantage point by really collaborating and working with them. And that led to product ideas, and that we were able to co-design and co-develop that with our partner governments. +And then something that I think is also unique is that they're often eager to work with you because they don't get that opportunity often to work with vendors and folks who can conjure magic in their minds, that they have a vision or idea. And you can come back in a week or a month, and you might have a working product, not just wireframes. And for them, that ability to move so quickly they haven't seen that before. +And I saw that firsthand in bringing startups and governments together, the velocity and speed that startups can work with is so different. We all know that. But when they see that, they get excited. They want to work with them. They want to lean into it and figure out, hey, can I give you data? Can I give you other ways to better understand the space? Because no one's cared about this space before. So there's often a willingness to grab a hold of anyone who can actually help them solve their problems. But you have to listen, and you have to come in humble. +And I'll share a story here. I created a program called Civic Bridge that brought in pro bono services from big companies like Google and McKinsey, and many others. And some folks from Google came in, and they were sharing how they have to serve everybody. Their product is really ubiquitous and has to serve everybody. They quickly got reminded that government has to serve everybody, people who don't have technology, people who aren't online, people who don't have English as their first language, and people with different disabilities. All of them are constituents. +And so technology is one way to reach people. But you have to think broadly about how do you make that service or what you're offering accessible to everybody? And I think that was a humbling experience for the folks there at the table. But what I loved about that program is really this cross-pollination and also breaking down stereotypes in both directions that people sometimes have in the public sector of private sector folks because they often don't hop back and forth. If you're a public sector person, you're often in the public sector. +And so being able to actually see that they're not just a bunch of capitalists, [laughs] that they're your neighbor, that these are people who do care about the community, and they're making an impact in a different way. And vice versa, that there are so many talented people in government. And the problems seem simple or seem simple to solve on the outside, but they're often wicked problems or just have a lot of complexity to try to solve. So it's great to be able to have that empathy on both sides. +CHAD: Yeah, that's maybe one thing. Are there other things that you would point out that are different when creating and shaping products for the public sector versus the private products? +JAY: Yeah, I think that idea of being inclusive is really important. The other one is around...and this is, I think, true even in the private sector but more so in the public sector because of the demographics that you're working with. The demographics are folks who are closer to retirement. They are not digital natives. So when you're building products, you really need to leverage mental models and use that as a way to bring them into a new experience or a new tool. And as an example, there are obviously a lot of government forms that you see, right? +CHAD: Mm-hmm. +JAY: And I think as a technologist or a product person, you might say, hey, let's move away from Microsoft Word or Adobe PDF or whatever you're using. We have this thing called HTML, and we can bring this online and have all these beautiful affordances. Well, that's really hard for those folks to wrap their heads around and move from something they may have been using for 20, 30 years. +And so maybe that first step is not that; maybe it's online fillable PDFs that you can actually store the data in a database and shift that back. And maybe that allows them to actually move more quickly because there's less resistance both internally and for the public as well. And so we've seen that time and time again, is that hey, is there a way to make that shift into a new paradigm but do it in such a way that there's a clear connection point? +And then maybe the next step after that is, yeah, we need to make sure this is mobile-ready. Let's actually make that into a responsive design and move away from that PDF. And that's something that we've learned in our own product that, hey, we need to understand deeply the products and tools that they're using today. And how do we draw those parallels and bring them into the current modern set of technologies that we're offering? So it's not always easy, but it's something that we found a lot of success leveraging those mental models. +CHAD: Are there other things that you might call out as things you got to keep in mind? +JAY: Well, security is often, you know, we see that everywhere with SolarWinds, et cetera. I think there's just a deeper concern of supply chain attacks, ransomware, et cetera. So you're seeing, I think across the board in enterprise as well but in government even more so really focusing on that. And I think the challenge for folks who are building products is how do you find that balance when you have to make sure that you're NIST-certified and all of the SOC 2, et cetera? How do you build a great product that is accessible that doesn't make you go through a bunch of hoops to try to get access to it? And it's not easy. +So that adds a layer of complexity trying to build that out. And, Chad, I'm sure you've worked with a lot of folks who have thought about government or may have had some success with it. So it might be interesting to hear from you if there are certain patterns or product sensibilities that you've seen that have been successfully applied in the public sector realm. +CHAD: Well, I think you're right about that inherent complexity or that the bar is pretty high in order to have a product which is accessible and secure. If you're building a product for consumers, you can do some of that stuff iteratively. It can be difficult to work in an agile, iterative way in a highly regulated space. And so there's maybe not even one set way that you do that. It might be different for the space that you operate in. +But it is important to take a step back and say, what can we do iteratively, or what can we leave off right now because we have to do this other thing? And those will be different for every product. And I see the real mistake being not taking that step back and not really being thoughtful about how you're going to do that in the complex, highly regulated space. +And this is true for healthcare and finance as well. There are certain things you've got to do. And really, you have to approach it pretty thoughtfully in order to make sure you can still work and not just default to doing everything agile. We have this concept of like the 80-20 rule, and that is sometimes really difficult to do in the public space, right? +JAY: I think you're absolutely right. And I think people recognize that highly regulated markets or industries are tough to crack. And I think you're absolutely right, Chad, that you have to find that entry point where maybe you can come in and the regulations are lower for that problem that you're solving initially. And use that as a place to land and then better understand where you fit into the overall workflow. And you're able to go upstream and downstream from there. +And that's a lot of what we've seen success with these young startups, and the work we're doing will come in where there's maybe not so much regulations and provide value there, build trust, and then look at the broader ecosystem or processes to say, "Hey, where can we add more value?" Yes, it might be highly regulated. But we now have a better understanding, more resources, and customers to help us educate climbing that mountain together. +But yeah, I want to make sure that...the flip side of all this...so if I were listening, I'd say, "Well, it sounds like the public sector is really tough," [laughter] and it is, but it's also truly rewarding. I think being able to know that you're able to help at the scale that the government does its work is really, really rewarding. +One of the founders that we helped get her first product was to help foster kids, and that foster process that we've probably all heard is really, really tough. And they brought that online, and they went from one city...they're in so many different states now serving so many people across the U.S., and they're doing really well. They're, I think, Series B or C. And it's amazing. But it took that one government to take a chance and to be able to bring all this value. So that's something that excites me is the level of impact is so significant. +CHAD: On that note, you started the conversation saying that procurement was the area where you felt like you could have an impact. Do you see expanding beyond that in the future, or is that not on your roadmap? +JAY: I think we have a lot to chew on. But like a lot of product folks, we've got ideas that are further out. What I'm seeing in the government space when we talk about digital transformation...in the government context, you're often talking about PDFs and Microsoft Word documents, et cetera. +So I think for us, we're really excited about is there a new way to think about documents in a way that works for governments? They're used to Microsoft Word. But is there more that can be done there to create more affordances, to create more powers that they just don't have today? And they're using Post-it Notes or whatever it might be to try to address those shortcomings. +CHAD: Everything is going to be marked down in GitHub eventually. [laughter] +JAY: Yes, we do need to introduce Markdown or just plain text, maybe. Why are these contracts locked up in Microsoft Word? Yeah, that's something that's a pet peeve of mine as well. I spend a lot of time in open data. And let's not use proprietary formats. Let's use something that folks understand. But the world is changing, which is great. We're seeing more governments using JSON. +And one of the things that I'll share is that when you're building a product for government, you do have to think about the data component because that data doesn't belong to you; you're really stewards. That data belongs to the government and its constituents. So that's a different way of thinking because often, private companies are trying to monetize the data that they're having. So you have to have a much more sort of a frame that you're a custodian. +CHAD: I think that's one of the things that can get a little lost, whether it be bureaucracy or politics or whatever but this idea that there is a community here. It is the community in which you live. You said that what inspired you to get involved was wanting to contribute back to a city that you love. It's easy for that to get lost in everything. +JAY: Yeah. And that's my call to action to your audiences. Sort of touching upon our earlier points in our conversation, find a way if you have that means, and ability, and interest to make your community better. It might be something just for your city, or it might be something bigger. And I've seen so many people have good ideas. But to your point, how do you actually convert that good idea into something that's valuable and used by the community? +And hopefully, this conversation is helping people and inspiring them to raise their hands and knock on the door. I think you'll see folks on the other side giving you a warm reception. They're very hungry and eager for people who have the capabilities of product and engineering and that type of talent to come to the table and help them. +CHAD: That's great. If folks want to get in touch with you or find out more about City Innovate or STIR, too, where are the places where they can do that? +JAY: They can go to our website cityinnovate.com. They can also go...I've got my own personal website, jaynath.com. And I'm very open. I have been since my days in public service. I'm still very accessible, maybe not as responsive as I used to be, just with all that work of being a founder. But if you're interested in this space, I always want to give back because we need great people with great talent working in the public sector, whether it's for government or within government or building a product for government. +CHAD: Awesome. Jay, thanks very much for stopping by and sharing with us. +JAY: Thank you so much, Chad, for the opportunity to share the work that we're doing. +CHAD: You can subscribe to the show and find notes and a transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Jay Nath. + + + Jay Nath is the Co-CEO of City Innovate, a govtech company streamlining procurement through enterprise software and innovative frameworks.

+ +

He talks with Chad about how he focuses on helping governments be more effective, responsive, and zeroed in on helping their constituents whether on a small city or a big state scale.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Jay Nath, Co-CEO of City Innovate and former Chief Innovation Officer of San Francisco. Jay, thanks for joining me.

+ +

JAY: Yeah, Chad, thank you for having me.

+ +

CHAD: I assume based on the name and the fact that I've done my research...but I assume based on the name of City Innovate and the fact that you're a former Chief Innovation Officer of San Francisco that what City Innovate might be. But why don't you give everybody an overview of what it is?

+ +

JAY: Thank you, Chad. So City Innovate is focused on helping governments be more effective, responsive, and focused on helping their constituents, whether it's a small city government or a big state. And the way that we've been doing this is really sort of an interesting; I'd say wonky place. We found that there's a pressure point in government around documents and specifically on procurement.

+ +

And why is that interesting? Because what I've seen is if you want to work with government and collaborate, whether it's even volunteering or you're a startup, and you want to work, procurement is often that channel. And it's not really a channel; it's more of a barrier, a byzantine process. You can think of this from a technical frame, creating an API, a read/write API to make that process much more streamlined on both sides, helping governments be able to find the best partners to solve their big challenges.

+ +

And on the other side, folks from all walks of life, whether you're a massive company or you're a founder in a garage, how do you actually connect those two? So we're really working at that intersection, and it's something that I find a lot of value in and importance in. And surprisingly and maybe not surprisingly, there's a lot of need for technology to help connect those dots. And ultimately, I think what I can do is make that process more inclusive and lower the barriers of entry so that people from different communities can participate and help make their communities better.

+ +

CHAD: So your clients at City Innovate are cities and governmental organizations. Are you just delivering a product to them, or are you often helping them work better too?

+ +

JAY: It's a bit of both. From a product standpoint, we're really in the B2B space and very much enterprise, if you will. And part of that standard enterprise SaaS offering is also support services, and that can be training, that can be professional services to help them in thought leadership in different ways. And that's exactly what we do. So we not only have our product, but we help them through something called agile procurement. So it's really borrowing from the software development methodology and applying the same principles and approaches to developing and finding the right partner and being more agile and iterative through that process.

+ +

And historically, it's been very waterfall and very stilted and overly structured. So really being more focused on outcomes, really being focused on getting data into the process so that you can actually do, let's say, a bake-off and get more information before we make that decision. And it's surprising, Chad, folks in government are often buying multimillion dollars, tens of millions of dollars technology systems without actually trying it out. And think about your personal life. You test drive a car. You look through a home. You make these big decisions with a lot of data and evidence.

+ +

And in government historically, they've been using paper documents to make that decision, RFPs responses, and marketing material. And it's hard to sift through and say, "Hey, what's real and what's not?" So we've been really helping them think through a more agile evidence-based approach, and our software supports that. And so yeah, it's really leading a movement about changing how they think about partnering with the vendor community or contractors.

+ +

CHAD: So one of the things that is probably interesting about this and maybe a little bit meta is that this is what you help them do. And so you have to go through that process with them of being procured. [laughs]

+ +

JAY: It is meta. You're absolutely right. [laughs]

+ +

CHAD: In order to become the vendor that they use.

+ +

JAY: That's right.

+ +

CHAD: What are the challenges inherent in that, and does it ever get in the way? And how do people, either your clients, come to you, or how do you find them? And how do you work through that challenging process of government procurement?

+ +

JAY: Well, the thing is, since we know this space really well, we know how to navigate those different channels, the byzantine processes I mentioned before. I think one of the things I worked on when I was in the City of San Francisco was a program that brought startups and governments together, and we had an educational component. We'd help founders better understand that exact question.

+ +

How do you actually get contracts with government? And there are no books that are out there. There's no real knowledge out there. And so, we help them talk about the ten different pathways to doing that. So it's a bit of a hidden art, if you will. And I think there needs to be more conversation and more resources for founders if they're looking to go into the public sector to be able to navigate that. So we know that really well. And we're trying to really help broaden access to that knowledge.

+ +

CHAD: I assume that the clients you end up getting are people who are...or are governments who want to be better. Otherwise, they wouldn't choose your solution. [laughs]

+ +

JAY: That's right. Well, I think their motivations are multifold. Some of the governments want a process that's more efficient. They know that they can be more productive. They have maybe staffing constraints, and they have a lot of work, so we can help them on the productivity side. There are other governments that are really focused on hey; we need to get better partners out there. We've been working with the same folks over and over again. How do we work with those innovators in our community? So there's that crowd.

+ +

And then there's, I think, another group of folks who are saying, "Hey, we wanted to make sure that this process is more inclusive. We want to work with folks who are from different backgrounds who may be underrepresented. How do we make this process more streamlined, more efficient so that they're able to participate more effectively?" So I think the motivations can be different, but it's really at the end of the day centered around this idea of digital transformation and service design that allows these two different worlds to be able to communicate and work together more effectively.

+ +

CHAD: How long is the typical sales cycle for a client?

+ +

JAY: Man, yeah, [laughs] it can range from weeks, I would say to months and going over 12 months. It can be 12 to 18 months, trying to get in, doing a trial maybe, giving them that certainty, and then securing budget and that annual process of waiting for that budget approval to happen. So it is not for the faint of heart, especially enterprise software within government is really something that requires a lot of different approaches.

+ +

So partnerships with bigger companies that have the distribution channel, that might have those relationships, that might have those contracts, how do you actually work with them to shortcut the long procurement process? How do you leverage folks like AWS and other cloud providers that may already have a relationship so that you can, again, piggyback off of that? So I think there are a number of different ways to try to compress that timeframe. But it's not a walk in the park, Chad.

+ +

CHAD: So, in that environment, how did you get started with City Innovate? How long was it until you were able to get your first real customer? And how did you bridge the gap between founding and being in the market?

+ +

JAY: That's a great question. So being in the public sector, I knew that procurement is a huge challenge and also a pressure point and a leverage point to unlocking a lot of value. And so the work that we had done with startups and government the first experience that we had was amazing. We had a startup that came in and helped blind people navigate through the airport here in San Francisco SFO in four months and truly a collaboration with the startup and the airport staff. And unfortunately, when it came to procurement, it took two years for them to actually get into contract.

+ +

CHAD: Wow.

+ +

JAY: For a startup, that's like dog years. That's like an eternity. And so we really knew that we had to tackle that. So we introduced a methodology called challenge-based procurement that, as I spoke to earlier, is more agile, evidence-based, and outcomes-based. And that really leveled the playing field for these young companies to show that hey, we can actually go in here and help you solve that problem. You don't have to work with a big publicly-traded company to do this work and spend a lot of money. We can be more nimble and agile. And so that's really where I started to dig in deeper into procurement.

+ +

And that work got federally funded because it created a lot of jobs. And we've had hundreds of startups all across the U.S. It's an international program called STIR, Startup In Residence, and really proud of that work. Our mayor, unfortunately, died unexpectedly. So we looked at hey, where do we move this program? And it did make sense for a city to manage a multi-city program, and so City Innovate came to mind.

+ +

At the time, they were a non-profit. I'd been working with my co-CEO co-executive director at the time. It was a nice, beautiful transition into that. And at that time, I said for myself personally, where do I see impact, and what can I do? And for me, the idea of entrepreneurship, the idea of products making impact in government, I saw how much impact was being made. And so City Innovate has really become that vehicle for myself and the organization to really scale that idea out.

+ +

CHAD: You mentioned you have a co-CEO. How did that come about? And how do you split the responsibilities between the two of you?

+ +

JAY: Well, the good thing is we're really great complements. So his focus is really on go-to-market and focusing on how do we get this in the hands of our customers or prospective customers? And I've always been very interested on the product side. I was formerly a VP of product at a startup before my time in government, and so that scenario I find keen interest. And I deeply understand the personas and the use cases of government, having spent a lot of time there.

+ +

And so that empathy and understanding and building a product around that and having somebody who can help get that product in the hands of government navigating through those difficult processes. It really does take that. You can have a great product, but without that ability to get it in the hands of your customers, especially with governments, it's really challenging.

+ +

CHAD: Is there any in particular...like, why Co-CEO and not two other C-level roles, one of you CEO, one of you CIO?

+ +

JAY: I don't think we've spent too much time debating that. And that might change, I think to your point to better describe our focus areas. Maybe my role changes to chief product officer and his to a different role title. I think if you're starting a company, you've got a lot of things to worry about. And it just seemed like a...yeah, I don't think there was much thought in it.

+ +

CHAD: Yeah. That's interesting, though. You alluded to what you were doing before the City of San Francisco. Well, let's dive into that a little bit more. And specifically, what were you doing, and then why did you join the public sector?

+ +

JAY: So I was VP of Product at a company called SquareTrade. It was a wonderful journey. We were working with, again, something kind of wonky and a space that was anti-consumer. It was around warranties, specifically electronic warranties. And we were in the eBay marketplace and expanded way beyond that in later years. But when I was there, we really took a contrarian perspective and being inspired by Zappos and many companies that are really focused on the consumer.

+ +

We changed that value proposition to say, hey, can we build a product that people love, a warranty that actually works? And so we did crazy things like we would actually give you the money before you returned the product. We would have the shipping label. And we wouldn't ask any questions. We did amazing things. But that wasn't just because we were focused on the user experience. We also had data to back it up.

+ +

We knew that, hey, there are a certain percentage of people who are going to return rocks. And there's a certain percentage of people who are going to do certain things. So we had a lot of information going in. The other thing we knew is that we could own the whole stack, the underwriting, the retailing. And we also knew the business. So that was a great experience.

+ +

But I really was missing this connection to the public good and doing something that was having impact in a really tangible way. That's when I saw why don't I work for a city I love deeply and care about? And that really drove me into thinking about public service. I had some friends who were in it, and they convinced me that I should take a look at that.

+ +

And I definitely have found the work that I had been doing in public service to be extremely rewarding and just a unique opportunity. Especially if you're a technologist or a product mindset or an engineering mindset, that is such a rare perspective in government, and being able to bring that in, you can do amazing things.

+ +

We all know the healthcare.gov and how that was imploding and exploding. It almost brought down a presidency and administration, and it was saved. I think many people know the story, especially in your audience. That was really folks in Silicon Valley saying, "Hey, I'm going to raise my hand and volunteer my time. I might be working at a big company and making a lot of money, but I will take my time out and try to help." And they did. They turned it around.

+ +

And I think that ethos and that mindset of giving back is something that's animated my interests in public sector and the fact that there's so much need, especially from the tech community, in helping the government out.

+ +

CHAD: Now, you didn't get started as the City Innovation Officer. [chuckles] So you got started as the Manager of Enterprise CRM for the City of San Francisco.

+ +

JAY: That's right. Yeah, it was interesting. Yeah, definitely.

+ +

CHAD: I think that public sector work is maybe a little bit of a black box for people. I know it is for me. You mentioned you knew some people, but I assume that was not a political appointment job.

+ +

JAY: It was not.

+ +

CHAD: So, how does one get into that, find it, and get that job and that kind of thing?

+ +

JAY: I think I took a very rare and uncommon path. So as you noted, I came in helping stand up a call center. So a 311 one call center which is, for the folks who don't know, 311 is for non-emergencies, potholes, et cetera, starting a business, how do I do that? So yeah, set up a CRM system 24/7. It was a great experience and actually much harder than I thought. I was working harder there than I had at the startup, so breaking some stereotypes or at least some ideas that I had in my mind.

+ +

But I quickly found myself saturating that opportunity and saying, hey, what do I want to do? And this was at the time that Obama had just come into office, and he had a call to action. His first memo in office was around openness and collaboration and that I felt was really compelling to me. I had the opportunity to say, "Hey, let me reach out to folks in White House. I don't have any relationships there, but I have this badge of San Francisco." And that started me on a journey of innovation, civic innovation.

+ +

And I did some really interesting things with great startups like Twitter at the time. We created a read/write API, the first of its kind in local government. Almost got fired by the [inaudible 16:45] [laughter] and trying to explain just like, why are you opening a channel into government to let people do horrible things? And so it was an interesting conversation. But Gavin Newsom was the mayor at the time then, so you can see it's going back in time.

+ +

CHAD: [laughs]

+ +

JAY: But my journey then sort of said, hey, let's continue building data standards and doing good work. And I was recognized by the mayoral campaigns that were running. And so they wanted to sort of say, "Hey, we need somebody in innovation in the mayor's office." So I got recruited into that role, the first of its kind in San Francisco and in the U.S.

+ +

So it was just a great opportunity to really help define and set a foundation for what does civic innovation mean? What does that look like? And we had a small office, and we did some really interesting work at the nexus of collaboration. That's really what I think is what we tried to do is make government more permeable, more accessible for people who are driving innovation in their communities to be able to participate in government.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: If someone's interested, how might they get involved in contributing to the public sector?

+ +

JAY: I think there's a couple of different ways. So one way, Chad, is that governments are often putting a lot of data out there. There has been an open data movement that we had led, and it's now a national global movement. So you can find data, and you can create a data product around that and giving more insight into visibility and into issues. You can volunteer with a specific department. They're looking for those skill sets, so you can do that.

+ +

You can also look for digital services offices. So those are becoming much more commonplace in governments if that's your thing. There are definitely ways to raise your hand and try to contribute. Folks are always looking for it. And if you don't see that opportunity, make that opportunity happen. Reach out to your council member. Reach out to a department head and say, "Hey, I've got this great superpower. I want to help you do better." And I guarantee they will listen because they're often strapped for resources.

+ +

CHAD: How do you know when you should pursue a more general product that might be useful to governments versus like, oh, if I could get in there and contribute? How do you make that distinction in your mind?

+ +

JAY: Well, I don't think there needs to be. So you can come in and have maybe a frame of hey, let me help my local government. And you might find opportunities while you're working there. They're using Microsoft Word and Excel to do something that really should be productized so you can think about it from that frame. Or you might have built a product for an adjacent market or for another need and say, "Hey, is there an opportunity to actually reframe this product that I have in the government context?" It might be a content management system. It might be a lot of different products can be reframed in that context.

+ +

So the way that we actually became a product company from a non-profit was just doing that. We got invited to bring our methodology of agile procurement. And so we had in the back of our mind this idea that I bet if we go there, it's going to be kind of dusty. There's going to be a lot of broken tools, and that was the case. They were using 40-year old technology to manage sometimes billions of dollars of purchasing. And so we saw something that you normally wouldn't have that vantage point by really collaborating and working with them. And that led to product ideas, and that we were able to co-design and co-develop that with our partner governments.

+ +

And then something that I think is also unique is that they're often eager to work with you because they don't get that opportunity often to work with vendors and folks who can conjure magic in their minds, that they have a vision or idea. And you can come back in a week or a month, and you might have a working product, not just wireframes. And for them, that ability to move so quickly they haven't seen that before.

+ +

And I saw that firsthand in bringing startups and governments together, the velocity and speed that startups can work with is so different. We all know that. But when they see that, they get excited. They want to work with them. They want to lean into it and figure out, hey, can I give you data? Can I give you other ways to better understand the space? Because no one's cared about this space before. So there's often a willingness to grab a hold of anyone who can actually help them solve their problems. But you have to listen, and you have to come in humble.

+ +

And I'll share a story here. I created a program called Civic Bridge that brought in pro bono services from big companies like Google and McKinsey, and many others. And some folks from Google came in, and they were sharing how they have to serve everybody. Their product is really ubiquitous and has to serve everybody. They quickly got reminded that government has to serve everybody, people who don't have technology, people who aren't online, people who don't have English as their first language, and people with different disabilities. All of them are constituents.

+ +

And so technology is one way to reach people. But you have to think broadly about how do you make that service or what you're offering accessible to everybody? And I think that was a humbling experience for the folks there at the table. But what I loved about that program is really this cross-pollination and also breaking down stereotypes in both directions that people sometimes have in the public sector of private sector folks because they often don't hop back and forth. If you're a public sector person, you're often in the public sector.

+ +

And so being able to actually see that they're not just a bunch of capitalists, [laughs] that they're your neighbor, that these are people who do care about the community, and they're making an impact in a different way. And vice versa, that there are so many talented people in government. And the problems seem simple or seem simple to solve on the outside, but they're often wicked problems or just have a lot of complexity to try to solve. So it's great to be able to have that empathy on both sides.

+ +

CHAD: Yeah, that's maybe one thing. Are there other things that you would point out that are different when creating and shaping products for the public sector versus the private products?

+ +

JAY: Yeah, I think that idea of being inclusive is really important. The other one is around...and this is, I think, true even in the private sector but more so in the public sector because of the demographics that you're working with. The demographics are folks who are closer to retirement. They are not digital natives. So when you're building products, you really need to leverage mental models and use that as a way to bring them into a new experience or a new tool. And as an example, there are obviously a lot of government forms that you see, right?

+ +

CHAD: Mm-hmm.

+ +

JAY: And I think as a technologist or a product person, you might say, hey, let's move away from Microsoft Word or Adobe PDF or whatever you're using. We have this thing called HTML, and we can bring this online and have all these beautiful affordances. Well, that's really hard for those folks to wrap their heads around and move from something they may have been using for 20, 30 years.

+ +

And so maybe that first step is not that; maybe it's online fillable PDFs that you can actually store the data in a database and shift that back. And maybe that allows them to actually move more quickly because there's less resistance both internally and for the public as well. And so we've seen that time and time again, is that hey, is there a way to make that shift into a new paradigm but do it in such a way that there's a clear connection point?

+ +

And then maybe the next step after that is, yeah, we need to make sure this is mobile-ready. Let's actually make that into a responsive design and move away from that PDF. And that's something that we've learned in our own product that, hey, we need to understand deeply the products and tools that they're using today. And how do we draw those parallels and bring them into the current modern set of technologies that we're offering? So it's not always easy, but it's something that we found a lot of success leveraging those mental models.

+ +

CHAD: Are there other things that you might call out as things you got to keep in mind?

+ +

JAY: Well, security is often, you know, we see that everywhere with SolarWinds, et cetera. I think there's just a deeper concern of supply chain attacks, ransomware, et cetera. So you're seeing, I think across the board in enterprise as well but in government even more so really focusing on that. And I think the challenge for folks who are building products is how do you find that balance when you have to make sure that you're NIST-certified and all of the SOC 2, et cetera? How do you build a great product that is accessible that doesn't make you go through a bunch of hoops to try to get access to it? And it's not easy.

+ +

So that adds a layer of complexity trying to build that out. And, Chad, I'm sure you've worked with a lot of folks who have thought about government or may have had some success with it. So it might be interesting to hear from you if there are certain patterns or product sensibilities that you've seen that have been successfully applied in the public sector realm.

+ +

CHAD: Well, I think you're right about that inherent complexity or that the bar is pretty high in order to have a product which is accessible and secure. If you're building a product for consumers, you can do some of that stuff iteratively. It can be difficult to work in an agile, iterative way in a highly regulated space. And so there's maybe not even one set way that you do that. It might be different for the space that you operate in.

+ +

But it is important to take a step back and say, what can we do iteratively, or what can we leave off right now because we have to do this other thing? And those will be different for every product. And I see the real mistake being not taking that step back and not really being thoughtful about how you're going to do that in the complex, highly regulated space.

+ +

And this is true for healthcare and finance as well. There are certain things you've got to do. And really, you have to approach it pretty thoughtfully in order to make sure you can still work and not just default to doing everything agile. We have this concept of like the 80-20 rule, and that is sometimes really difficult to do in the public space, right?

+ +

JAY: I think you're absolutely right. And I think people recognize that highly regulated markets or industries are tough to crack. And I think you're absolutely right, Chad, that you have to find that entry point where maybe you can come in and the regulations are lower for that problem that you're solving initially. And use that as a place to land and then better understand where you fit into the overall workflow. And you're able to go upstream and downstream from there.

+ +

And that's a lot of what we've seen success with these young startups, and the work we're doing will come in where there's maybe not so much regulations and provide value there, build trust, and then look at the broader ecosystem or processes to say, "Hey, where can we add more value?" Yes, it might be highly regulated. But we now have a better understanding, more resources, and customers to help us educate climbing that mountain together.

+ +

But yeah, I want to make sure that...the flip side of all this...so if I were listening, I'd say, "Well, it sounds like the public sector is really tough," [laughter] and it is, but it's also truly rewarding. I think being able to know that you're able to help at the scale that the government does its work is really, really rewarding.

+ +

One of the founders that we helped get her first product was to help foster kids, and that foster process that we've probably all heard is really, really tough. And they brought that online, and they went from one city...they're in so many different states now serving so many people across the U.S., and they're doing really well. They're, I think, Series B or C. And it's amazing. But it took that one government to take a chance and to be able to bring all this value. So that's something that excites me is the level of impact is so significant.

+ +

CHAD: On that note, you started the conversation saying that procurement was the area where you felt like you could have an impact. Do you see expanding beyond that in the future, or is that not on your roadmap?

+ +

JAY: I think we have a lot to chew on. But like a lot of product folks, we've got ideas that are further out. What I'm seeing in the government space when we talk about digital transformation...in the government context, you're often talking about PDFs and Microsoft Word documents, et cetera.

+ +

So I think for us, we're really excited about is there a new way to think about documents in a way that works for governments? They're used to Microsoft Word. But is there more that can be done there to create more affordances, to create more powers that they just don't have today? And they're using Post-it Notes or whatever it might be to try to address those shortcomings.

+ +

CHAD: Everything is going to be marked down in GitHub eventually. [laughter]

+ +

JAY: Yes, we do need to introduce Markdown or just plain text, maybe. Why are these contracts locked up in Microsoft Word? Yeah, that's something that's a pet peeve of mine as well. I spend a lot of time in open data. And let's not use proprietary formats. Let's use something that folks understand. But the world is changing, which is great. We're seeing more governments using JSON.

+ +

And one of the things that I'll share is that when you're building a product for government, you do have to think about the data component because that data doesn't belong to you; you're really stewards. That data belongs to the government and its constituents. So that's a different way of thinking because often, private companies are trying to monetize the data that they're having. So you have to have a much more sort of a frame that you're a custodian.

+ +

CHAD: I think that's one of the things that can get a little lost, whether it be bureaucracy or politics or whatever but this idea that there is a community here. It is the community in which you live. You said that what inspired you to get involved was wanting to contribute back to a city that you love. It's easy for that to get lost in everything.

+ +

JAY: Yeah. And that's my call to action to your audiences. Sort of touching upon our earlier points in our conversation, find a way if you have that means, and ability, and interest to make your community better. It might be something just for your city, or it might be something bigger. And I've seen so many people have good ideas. But to your point, how do you actually convert that good idea into something that's valuable and used by the community?

+ +

And hopefully, this conversation is helping people and inspiring them to raise their hands and knock on the door. I think you'll see folks on the other side giving you a warm reception. They're very hungry and eager for people who have the capabilities of product and engineering and that type of talent to come to the table and help them.

+ +

CHAD: That's great. If folks want to get in touch with you or find out more about City Innovate or STIR, too, where are the places where they can do that?

+ +

JAY: They can go to our website cityinnovate.com. They can also go...I've got my own personal website, jaynath.com. And I'm very open. I have been since my days in public service. I'm still very accessible, maybe not as responsive as I used to be, just with all that work of being a founder. But if you're interested in this space, I always want to give back because we need great people with great talent working in the public sector, whether it's for government or within government or building a product for government.

+ +

CHAD: Awesome. Jay, thanks very much for stopping by and sharing with us.

+ +

JAY: Thank you so much, Chad, for the opportunity to share the work that we're doing.

+ +

CHAD: You can subscribe to the show and find notes and a transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jay Nath.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jay Nath is the Co-CEO of City Innovate, a govtech company streamlining procurement through enterprise software and innovative frameworks.

+ +

He talks with Chad about how he focuses on helping governments be more effective, responsive, and zeroed in on helping their constituents whether on a small city or a big state scale.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Jay Nath, Co-CEO of City Innovate and former Chief Innovation Officer of San Francisco. Jay, thanks for joining me.

+ +

JAY: Yeah, Chad, thank you for having me.

+ +

CHAD: I assume based on the name and the fact that I've done my research...but I assume based on the name of City Innovate and the fact that you're a former Chief Innovation Officer of San Francisco that what City Innovate might be. But why don't you give everybody an overview of what it is?

+ +

JAY: Thank you, Chad. So City Innovate is focused on helping governments be more effective, responsive, and focused on helping their constituents, whether it's a small city government or a big state. And the way that we've been doing this is really sort of an interesting; I'd say wonky place. We found that there's a pressure point in government around documents and specifically on procurement.

+ +

And why is that interesting? Because what I've seen is if you want to work with government and collaborate, whether it's even volunteering or you're a startup, and you want to work, procurement is often that channel. And it's not really a channel; it's more of a barrier, a byzantine process. You can think of this from a technical frame, creating an API, a read/write API to make that process much more streamlined on both sides, helping governments be able to find the best partners to solve their big challenges.

+ +

And on the other side, folks from all walks of life, whether you're a massive company or you're a founder in a garage, how do you actually connect those two? So we're really working at that intersection, and it's something that I find a lot of value in and importance in. And surprisingly and maybe not surprisingly, there's a lot of need for technology to help connect those dots. And ultimately, I think what I can do is make that process more inclusive and lower the barriers of entry so that people from different communities can participate and help make their communities better.

+ +

CHAD: So your clients at City Innovate are cities and governmental organizations. Are you just delivering a product to them, or are you often helping them work better too?

+ +

JAY: It's a bit of both. From a product standpoint, we're really in the B2B space and very much enterprise, if you will. And part of that standard enterprise SaaS offering is also support services, and that can be training, that can be professional services to help them in thought leadership in different ways. And that's exactly what we do. So we not only have our product, but we help them through something called agile procurement. So it's really borrowing from the software development methodology and applying the same principles and approaches to developing and finding the right partner and being more agile and iterative through that process.

+ +

And historically, it's been very waterfall and very stilted and overly structured. So really being more focused on outcomes, really being focused on getting data into the process so that you can actually do, let's say, a bake-off and get more information before we make that decision. And it's surprising, Chad, folks in government are often buying multimillion dollars, tens of millions of dollars technology systems without actually trying it out. And think about your personal life. You test drive a car. You look through a home. You make these big decisions with a lot of data and evidence.

+ +

And in government historically, they've been using paper documents to make that decision, RFPs responses, and marketing material. And it's hard to sift through and say, "Hey, what's real and what's not?" So we've been really helping them think through a more agile evidence-based approach, and our software supports that. And so yeah, it's really leading a movement about changing how they think about partnering with the vendor community or contractors.

+ +

CHAD: So one of the things that is probably interesting about this and maybe a little bit meta is that this is what you help them do. And so you have to go through that process with them of being procured. [laughs]

+ +

JAY: It is meta. You're absolutely right. [laughs]

+ +

CHAD: In order to become the vendor that they use.

+ +

JAY: That's right.

+ +

CHAD: What are the challenges inherent in that, and does it ever get in the way? And how do people, either your clients, come to you, or how do you find them? And how do you work through that challenging process of government procurement?

+ +

JAY: Well, the thing is, since we know this space really well, we know how to navigate those different channels, the byzantine processes I mentioned before. I think one of the things I worked on when I was in the City of San Francisco was a program that brought startups and governments together, and we had an educational component. We'd help founders better understand that exact question.

+ +

How do you actually get contracts with government? And there are no books that are out there. There's no real knowledge out there. And so, we help them talk about the ten different pathways to doing that. So it's a bit of a hidden art, if you will. And I think there needs to be more conversation and more resources for founders if they're looking to go into the public sector to be able to navigate that. So we know that really well. And we're trying to really help broaden access to that knowledge.

+ +

CHAD: I assume that the clients you end up getting are people who are...or are governments who want to be better. Otherwise, they wouldn't choose your solution. [laughs]

+ +

JAY: That's right. Well, I think their motivations are multifold. Some of the governments want a process that's more efficient. They know that they can be more productive. They have maybe staffing constraints, and they have a lot of work, so we can help them on the productivity side. There are other governments that are really focused on hey; we need to get better partners out there. We've been working with the same folks over and over again. How do we work with those innovators in our community? So there's that crowd.

+ +

And then there's, I think, another group of folks who are saying, "Hey, we wanted to make sure that this process is more inclusive. We want to work with folks who are from different backgrounds who may be underrepresented. How do we make this process more streamlined, more efficient so that they're able to participate more effectively?" So I think the motivations can be different, but it's really at the end of the day centered around this idea of digital transformation and service design that allows these two different worlds to be able to communicate and work together more effectively.

+ +

CHAD: How long is the typical sales cycle for a client?

+ +

JAY: Man, yeah, [laughs] it can range from weeks, I would say to months and going over 12 months. It can be 12 to 18 months, trying to get in, doing a trial maybe, giving them that certainty, and then securing budget and that annual process of waiting for that budget approval to happen. So it is not for the faint of heart, especially enterprise software within government is really something that requires a lot of different approaches.

+ +

So partnerships with bigger companies that have the distribution channel, that might have those relationships, that might have those contracts, how do you actually work with them to shortcut the long procurement process? How do you leverage folks like AWS and other cloud providers that may already have a relationship so that you can, again, piggyback off of that? So I think there are a number of different ways to try to compress that timeframe. But it's not a walk in the park, Chad.

+ +

CHAD: So, in that environment, how did you get started with City Innovate? How long was it until you were able to get your first real customer? And how did you bridge the gap between founding and being in the market?

+ +

JAY: That's a great question. So being in the public sector, I knew that procurement is a huge challenge and also a pressure point and a leverage point to unlocking a lot of value. And so the work that we had done with startups and government the first experience that we had was amazing. We had a startup that came in and helped blind people navigate through the airport here in San Francisco SFO in four months and truly a collaboration with the startup and the airport staff. And unfortunately, when it came to procurement, it took two years for them to actually get into contract.

+ +

CHAD: Wow.

+ +

JAY: For a startup, that's like dog years. That's like an eternity. And so we really knew that we had to tackle that. So we introduced a methodology called challenge-based procurement that, as I spoke to earlier, is more agile, evidence-based, and outcomes-based. And that really leveled the playing field for these young companies to show that hey, we can actually go in here and help you solve that problem. You don't have to work with a big publicly-traded company to do this work and spend a lot of money. We can be more nimble and agile. And so that's really where I started to dig in deeper into procurement.

+ +

And that work got federally funded because it created a lot of jobs. And we've had hundreds of startups all across the U.S. It's an international program called STIR, Startup In Residence, and really proud of that work. Our mayor, unfortunately, died unexpectedly. So we looked at hey, where do we move this program? And it did make sense for a city to manage a multi-city program, and so City Innovate came to mind.

+ +

At the time, they were a non-profit. I'd been working with my co-CEO co-executive director at the time. It was a nice, beautiful transition into that. And at that time, I said for myself personally, where do I see impact, and what can I do? And for me, the idea of entrepreneurship, the idea of products making impact in government, I saw how much impact was being made. And so City Innovate has really become that vehicle for myself and the organization to really scale that idea out.

+ +

CHAD: You mentioned you have a co-CEO. How did that come about? And how do you split the responsibilities between the two of you?

+ +

JAY: Well, the good thing is we're really great complements. So his focus is really on go-to-market and focusing on how do we get this in the hands of our customers or prospective customers? And I've always been very interested on the product side. I was formerly a VP of product at a startup before my time in government, and so that scenario I find keen interest. And I deeply understand the personas and the use cases of government, having spent a lot of time there.

+ +

And so that empathy and understanding and building a product around that and having somebody who can help get that product in the hands of government navigating through those difficult processes. It really does take that. You can have a great product, but without that ability to get it in the hands of your customers, especially with governments, it's really challenging.

+ +

CHAD: Is there any in particular...like, why Co-CEO and not two other C-level roles, one of you CEO, one of you CIO?

+ +

JAY: I don't think we've spent too much time debating that. And that might change, I think to your point to better describe our focus areas. Maybe my role changes to chief product officer and his to a different role title. I think if you're starting a company, you've got a lot of things to worry about. And it just seemed like a...yeah, I don't think there was much thought in it.

+ +

CHAD: Yeah. That's interesting, though. You alluded to what you were doing before the City of San Francisco. Well, let's dive into that a little bit more. And specifically, what were you doing, and then why did you join the public sector?

+ +

JAY: So I was VP of Product at a company called SquareTrade. It was a wonderful journey. We were working with, again, something kind of wonky and a space that was anti-consumer. It was around warranties, specifically electronic warranties. And we were in the eBay marketplace and expanded way beyond that in later years. But when I was there, we really took a contrarian perspective and being inspired by Zappos and many companies that are really focused on the consumer.

+ +

We changed that value proposition to say, hey, can we build a product that people love, a warranty that actually works? And so we did crazy things like we would actually give you the money before you returned the product. We would have the shipping label. And we wouldn't ask any questions. We did amazing things. But that wasn't just because we were focused on the user experience. We also had data to back it up.

+ +

We knew that, hey, there are a certain percentage of people who are going to return rocks. And there's a certain percentage of people who are going to do certain things. So we had a lot of information going in. The other thing we knew is that we could own the whole stack, the underwriting, the retailing. And we also knew the business. So that was a great experience.

+ +

But I really was missing this connection to the public good and doing something that was having impact in a really tangible way. That's when I saw why don't I work for a city I love deeply and care about? And that really drove me into thinking about public service. I had some friends who were in it, and they convinced me that I should take a look at that.

+ +

And I definitely have found the work that I had been doing in public service to be extremely rewarding and just a unique opportunity. Especially if you're a technologist or a product mindset or an engineering mindset, that is such a rare perspective in government, and being able to bring that in, you can do amazing things.

+ +

We all know the healthcare.gov and how that was imploding and exploding. It almost brought down a presidency and administration, and it was saved. I think many people know the story, especially in your audience. That was really folks in Silicon Valley saying, "Hey, I'm going to raise my hand and volunteer my time. I might be working at a big company and making a lot of money, but I will take my time out and try to help." And they did. They turned it around.

+ +

And I think that ethos and that mindset of giving back is something that's animated my interests in public sector and the fact that there's so much need, especially from the tech community, in helping the government out.

+ +

CHAD: Now, you didn't get started as the City Innovation Officer. [chuckles] So you got started as the Manager of Enterprise CRM for the City of San Francisco.

+ +

JAY: That's right. Yeah, it was interesting. Yeah, definitely.

+ +

CHAD: I think that public sector work is maybe a little bit of a black box for people. I know it is for me. You mentioned you knew some people, but I assume that was not a political appointment job.

+ +

JAY: It was not.

+ +

CHAD: So, how does one get into that, find it, and get that job and that kind of thing?

+ +

JAY: I think I took a very rare and uncommon path. So as you noted, I came in helping stand up a call center. So a 311 one call center which is, for the folks who don't know, 311 is for non-emergencies, potholes, et cetera, starting a business, how do I do that? So yeah, set up a CRM system 24/7. It was a great experience and actually much harder than I thought. I was working harder there than I had at the startup, so breaking some stereotypes or at least some ideas that I had in my mind.

+ +

But I quickly found myself saturating that opportunity and saying, hey, what do I want to do? And this was at the time that Obama had just come into office, and he had a call to action. His first memo in office was around openness and collaboration and that I felt was really compelling to me. I had the opportunity to say, "Hey, let me reach out to folks in White House. I don't have any relationships there, but I have this badge of San Francisco." And that started me on a journey of innovation, civic innovation.

+ +

And I did some really interesting things with great startups like Twitter at the time. We created a read/write API, the first of its kind in local government. Almost got fired by the [inaudible 16:45] [laughter] and trying to explain just like, why are you opening a channel into government to let people do horrible things? And so it was an interesting conversation. But Gavin Newsom was the mayor at the time then, so you can see it's going back in time.

+ +

CHAD: [laughs]

+ +

JAY: But my journey then sort of said, hey, let's continue building data standards and doing good work. And I was recognized by the mayoral campaigns that were running. And so they wanted to sort of say, "Hey, we need somebody in innovation in the mayor's office." So I got recruited into that role, the first of its kind in San Francisco and in the U.S.

+ +

So it was just a great opportunity to really help define and set a foundation for what does civic innovation mean? What does that look like? And we had a small office, and we did some really interesting work at the nexus of collaboration. That's really what I think is what we tried to do is make government more permeable, more accessible for people who are driving innovation in their communities to be able to participate in government.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: If someone's interested, how might they get involved in contributing to the public sector?

+ +

JAY: I think there's a couple of different ways. So one way, Chad, is that governments are often putting a lot of data out there. There has been an open data movement that we had led, and it's now a national global movement. So you can find data, and you can create a data product around that and giving more insight into visibility and into issues. You can volunteer with a specific department. They're looking for those skill sets, so you can do that.

+ +

You can also look for digital services offices. So those are becoming much more commonplace in governments if that's your thing. There are definitely ways to raise your hand and try to contribute. Folks are always looking for it. And if you don't see that opportunity, make that opportunity happen. Reach out to your council member. Reach out to a department head and say, "Hey, I've got this great superpower. I want to help you do better." And I guarantee they will listen because they're often strapped for resources.

+ +

CHAD: How do you know when you should pursue a more general product that might be useful to governments versus like, oh, if I could get in there and contribute? How do you make that distinction in your mind?

+ +

JAY: Well, I don't think there needs to be. So you can come in and have maybe a frame of hey, let me help my local government. And you might find opportunities while you're working there. They're using Microsoft Word and Excel to do something that really should be productized so you can think about it from that frame. Or you might have built a product for an adjacent market or for another need and say, "Hey, is there an opportunity to actually reframe this product that I have in the government context?" It might be a content management system. It might be a lot of different products can be reframed in that context.

+ +

So the way that we actually became a product company from a non-profit was just doing that. We got invited to bring our methodology of agile procurement. And so we had in the back of our mind this idea that I bet if we go there, it's going to be kind of dusty. There's going to be a lot of broken tools, and that was the case. They were using 40-year old technology to manage sometimes billions of dollars of purchasing. And so we saw something that you normally wouldn't have that vantage point by really collaborating and working with them. And that led to product ideas, and that we were able to co-design and co-develop that with our partner governments.

+ +

And then something that I think is also unique is that they're often eager to work with you because they don't get that opportunity often to work with vendors and folks who can conjure magic in their minds, that they have a vision or idea. And you can come back in a week or a month, and you might have a working product, not just wireframes. And for them, that ability to move so quickly they haven't seen that before.

+ +

And I saw that firsthand in bringing startups and governments together, the velocity and speed that startups can work with is so different. We all know that. But when they see that, they get excited. They want to work with them. They want to lean into it and figure out, hey, can I give you data? Can I give you other ways to better understand the space? Because no one's cared about this space before. So there's often a willingness to grab a hold of anyone who can actually help them solve their problems. But you have to listen, and you have to come in humble.

+ +

And I'll share a story here. I created a program called Civic Bridge that brought in pro bono services from big companies like Google and McKinsey, and many others. And some folks from Google came in, and they were sharing how they have to serve everybody. Their product is really ubiquitous and has to serve everybody. They quickly got reminded that government has to serve everybody, people who don't have technology, people who aren't online, people who don't have English as their first language, and people with different disabilities. All of them are constituents.

+ +

And so technology is one way to reach people. But you have to think broadly about how do you make that service or what you're offering accessible to everybody? And I think that was a humbling experience for the folks there at the table. But what I loved about that program is really this cross-pollination and also breaking down stereotypes in both directions that people sometimes have in the public sector of private sector folks because they often don't hop back and forth. If you're a public sector person, you're often in the public sector.

+ +

And so being able to actually see that they're not just a bunch of capitalists, [laughs] that they're your neighbor, that these are people who do care about the community, and they're making an impact in a different way. And vice versa, that there are so many talented people in government. And the problems seem simple or seem simple to solve on the outside, but they're often wicked problems or just have a lot of complexity to try to solve. So it's great to be able to have that empathy on both sides.

+ +

CHAD: Yeah, that's maybe one thing. Are there other things that you would point out that are different when creating and shaping products for the public sector versus the private products?

+ +

JAY: Yeah, I think that idea of being inclusive is really important. The other one is around...and this is, I think, true even in the private sector but more so in the public sector because of the demographics that you're working with. The demographics are folks who are closer to retirement. They are not digital natives. So when you're building products, you really need to leverage mental models and use that as a way to bring them into a new experience or a new tool. And as an example, there are obviously a lot of government forms that you see, right?

+ +

CHAD: Mm-hmm.

+ +

JAY: And I think as a technologist or a product person, you might say, hey, let's move away from Microsoft Word or Adobe PDF or whatever you're using. We have this thing called HTML, and we can bring this online and have all these beautiful affordances. Well, that's really hard for those folks to wrap their heads around and move from something they may have been using for 20, 30 years.

+ +

And so maybe that first step is not that; maybe it's online fillable PDFs that you can actually store the data in a database and shift that back. And maybe that allows them to actually move more quickly because there's less resistance both internally and for the public as well. And so we've seen that time and time again, is that hey, is there a way to make that shift into a new paradigm but do it in such a way that there's a clear connection point?

+ +

And then maybe the next step after that is, yeah, we need to make sure this is mobile-ready. Let's actually make that into a responsive design and move away from that PDF. And that's something that we've learned in our own product that, hey, we need to understand deeply the products and tools that they're using today. And how do we draw those parallels and bring them into the current modern set of technologies that we're offering? So it's not always easy, but it's something that we found a lot of success leveraging those mental models.

+ +

CHAD: Are there other things that you might call out as things you got to keep in mind?

+ +

JAY: Well, security is often, you know, we see that everywhere with SolarWinds, et cetera. I think there's just a deeper concern of supply chain attacks, ransomware, et cetera. So you're seeing, I think across the board in enterprise as well but in government even more so really focusing on that. And I think the challenge for folks who are building products is how do you find that balance when you have to make sure that you're NIST-certified and all of the SOC 2, et cetera? How do you build a great product that is accessible that doesn't make you go through a bunch of hoops to try to get access to it? And it's not easy.

+ +

So that adds a layer of complexity trying to build that out. And, Chad, I'm sure you've worked with a lot of folks who have thought about government or may have had some success with it. So it might be interesting to hear from you if there are certain patterns or product sensibilities that you've seen that have been successfully applied in the public sector realm.

+ +

CHAD: Well, I think you're right about that inherent complexity or that the bar is pretty high in order to have a product which is accessible and secure. If you're building a product for consumers, you can do some of that stuff iteratively. It can be difficult to work in an agile, iterative way in a highly regulated space. And so there's maybe not even one set way that you do that. It might be different for the space that you operate in.

+ +

But it is important to take a step back and say, what can we do iteratively, or what can we leave off right now because we have to do this other thing? And those will be different for every product. And I see the real mistake being not taking that step back and not really being thoughtful about how you're going to do that in the complex, highly regulated space.

+ +

And this is true for healthcare and finance as well. There are certain things you've got to do. And really, you have to approach it pretty thoughtfully in order to make sure you can still work and not just default to doing everything agile. We have this concept of like the 80-20 rule, and that is sometimes really difficult to do in the public space, right?

+ +

JAY: I think you're absolutely right. And I think people recognize that highly regulated markets or industries are tough to crack. And I think you're absolutely right, Chad, that you have to find that entry point where maybe you can come in and the regulations are lower for that problem that you're solving initially. And use that as a place to land and then better understand where you fit into the overall workflow. And you're able to go upstream and downstream from there.

+ +

And that's a lot of what we've seen success with these young startups, and the work we're doing will come in where there's maybe not so much regulations and provide value there, build trust, and then look at the broader ecosystem or processes to say, "Hey, where can we add more value?" Yes, it might be highly regulated. But we now have a better understanding, more resources, and customers to help us educate climbing that mountain together.

+ +

But yeah, I want to make sure that...the flip side of all this...so if I were listening, I'd say, "Well, it sounds like the public sector is really tough," [laughter] and it is, but it's also truly rewarding. I think being able to know that you're able to help at the scale that the government does its work is really, really rewarding.

+ +

One of the founders that we helped get her first product was to help foster kids, and that foster process that we've probably all heard is really, really tough. And they brought that online, and they went from one city...they're in so many different states now serving so many people across the U.S., and they're doing really well. They're, I think, Series B or C. And it's amazing. But it took that one government to take a chance and to be able to bring all this value. So that's something that excites me is the level of impact is so significant.

+ +

CHAD: On that note, you started the conversation saying that procurement was the area where you felt like you could have an impact. Do you see expanding beyond that in the future, or is that not on your roadmap?

+ +

JAY: I think we have a lot to chew on. But like a lot of product folks, we've got ideas that are further out. What I'm seeing in the government space when we talk about digital transformation...in the government context, you're often talking about PDFs and Microsoft Word documents, et cetera.

+ +

So I think for us, we're really excited about is there a new way to think about documents in a way that works for governments? They're used to Microsoft Word. But is there more that can be done there to create more affordances, to create more powers that they just don't have today? And they're using Post-it Notes or whatever it might be to try to address those shortcomings.

+ +

CHAD: Everything is going to be marked down in GitHub eventually. [laughter]

+ +

JAY: Yes, we do need to introduce Markdown or just plain text, maybe. Why are these contracts locked up in Microsoft Word? Yeah, that's something that's a pet peeve of mine as well. I spend a lot of time in open data. And let's not use proprietary formats. Let's use something that folks understand. But the world is changing, which is great. We're seeing more governments using JSON.

+ +

And one of the things that I'll share is that when you're building a product for government, you do have to think about the data component because that data doesn't belong to you; you're really stewards. That data belongs to the government and its constituents. So that's a different way of thinking because often, private companies are trying to monetize the data that they're having. So you have to have a much more sort of a frame that you're a custodian.

+ +

CHAD: I think that's one of the things that can get a little lost, whether it be bureaucracy or politics or whatever but this idea that there is a community here. It is the community in which you live. You said that what inspired you to get involved was wanting to contribute back to a city that you love. It's easy for that to get lost in everything.

+ +

JAY: Yeah. And that's my call to action to your audiences. Sort of touching upon our earlier points in our conversation, find a way if you have that means, and ability, and interest to make your community better. It might be something just for your city, or it might be something bigger. And I've seen so many people have good ideas. But to your point, how do you actually convert that good idea into something that's valuable and used by the community?

+ +

And hopefully, this conversation is helping people and inspiring them to raise their hands and knock on the door. I think you'll see folks on the other side giving you a warm reception. They're very hungry and eager for people who have the capabilities of product and engineering and that type of talent to come to the table and help them.

+ +

CHAD: That's great. If folks want to get in touch with you or find out more about City Innovate or STIR, too, where are the places where they can do that?

+ +

JAY: They can go to our website cityinnovate.com. They can also go...I've got my own personal website, jaynath.com. And I'm very open. I have been since my days in public service. I'm still very accessible, maybe not as responsive as I used to be, just with all that work of being a founder. But if you're interested in this space, I always want to give back because we need great people with great talent working in the public sector, whether it's for government or within government or building a product for government.

+ +

CHAD: Awesome. Jay, thanks very much for stopping by and sharing with us.

+ +

JAY: Thank you so much, Chad, for the opportunity to share the work that we're doing.

+ +

CHAD: You can subscribe to the show and find notes and a transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jay Nath.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+uyq0bpeJ + + ]]> + + Chad Pytel + Jay Nath + + + 410: Ada Developers Academy with Alexandra Holien + https://podcast.thoughtbot.com/410 + 46fa5de8-00a7-41df-9ef6-1f3ffc3850a6 + Thu, 10 Feb 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Alexandra Holien is the Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. She talks with Chad about working for a nonprofit that prioritizes teaching Black, Brown, Latinx, Indigenous, Hawaiian, Pacific Islander, and low-income folks software development for free. + 34:31 + no + + + Alexandra Holien is the Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. She talks with Chad about working for a nonprofit that prioritizes teaching Black, Brown, Latinx, Indigenous, Hawaiian, Pacific Islander, and low-income folks software development for free. +Ada Developers Academy (https://adadevelopersacademy.org/) +Follow Alexandra on Twitter (https://twitter.com/AlexandraHolien) or LinkedIn (https://www.linkedin.com/in/alexandraholien/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Alexandra Holien, Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. Alexandra, thank you for joining me. +ALEXANDRA: Thank you for having me. I'm excited. +CHAD: Let's start right off the bat with giving folks a brief overview of what Ada actually is. +ALEXANDRA: Yeah, I'd love to. Ada Developers Academy we are a super unique non-profit, and I think, well-functioning business. We're a tuition-free 11-month software developing bootcamp academy for women and gender-expansive people. That may sound like some of the other bootcamps you've seen out there, but we're completely different. We have this really cool intersection of education, social justice, equity, bringing money to the people that need money sort of drive about us. +We prioritize serving Black, Latine, Indigenous, Hawaiian, and Pacific Islander folks, and low-income folks. And we prioritize them because they've been left out of this capitalistic system the most. And we think if we can really put money in the hands of these gorgeous, resilient communities through the career of software development and one of the hugest wealth engines of our time, then we're going to change the world. We're crazy because it's like we're free for our students. +CHAD: [chuckles] +ALEXANDRA: There are wraparound services, ridiculous, not even ridiculous, just like, natural. And it seems unique, and it seems crazy. But these things that we're doing to support our students are actually just human and basic needs, providing comprehensive support for our students financially, childcare, mental health care, free laptops, just making sure that they're set up for success, unlike I think other more traditional education systems. So they can go and be really amazing software developers. +And it's proven time and time again if you just set people up, open the door, give them the opportunity, make sure that you're creating equity, then 92% of those folks what we're seeing is our numbers are going to go out there and get full-time software development jobs. So that's Ada in the smallest nutshell and believe me, I'm going to tell you way more. +CHAD: Well, we're going to dig into each of those things and more. I interview a lot of people who graduate from bootcamps. We have a pretty wide-reaching apprentice program. And I'm pretty familiar with what it looks like when people are graduating from those programs. And you can graduate from a three-month program and be successful, and I don't mean to imply that you can't be. +But I do see folks who go to slightly longer programs, up to 11 months, a year like at Ada, and those people are often much more well-rounded developers not only with the technical skills but with all of the other skills that are important to development. How intentional was the length of the curriculum? And was there pressure early on to get people into the market faster? +ALEXANDRA: Yeah, great question. I think that so many...let me answer your first question, which is how intentional was it? It had to be at the forefront of what we wanted to do. And the reason why it had to be is that we were taking a group of people that had already been left out of the system. +And we already knew that there were going to be steps that they had to take to get into...like, once they got into the tech industry, getting in and staying in was going to be harder than their counterparts, harder than the white dude who took apart a computer or a Nintendo when they were in the 80s and growing up because their dads were software engineers. And then went on to college and knew they were going to be software engineers. +So our founders, Scott Case and Elise Worthy, were so intentional in making sure that the technical bar and the technical merit of our students going into the industry was not what they were going to have to worry about. That was not going to be the thing that kept them up at night thinking like, oh, man, I don't know if I can do this because I don't understand it. That was not going to be it because we knew there were going to be other things. +We knew there were going to be people mistaking you for the secretary. And these are examples that are all true. It's mistaking you for the secretary or the person that's the assistant or the executive assistant when they walk into the room or that person that constantly misgenders you. We knew there were going to be other really big obstacles that they're going to have to overcome when walking into a very homogenous industry like the software development industry of the United States. We knew that that was going to be the big thing. +So being intentional about the programming that we were going to offer our students that five and a half months of nine-to-five intense programming that also concentrates on what I don't think a lot of bootcamps really concentrate on, that CS fundamentals part of it, showing people that that is a part of the world. It's not the part of the world of the most entry-level software engineers, but it is there, so showing them that that's there. +And then giving them that internship, giving them that on-the-job training that Ada does that no other bootcamp does like we do. That sort of on-the-job training where you go in, and you see what does that practice of what you learned in code look like in real-time when you put it next to one of our sponsoring companies' tech stack? +So it had to be really intentional. I don't know if it was like, yes, this has to be perfectly like this. I think we definitely iterated and made it better over the years. But making sure that the technical bar of our students was at the technical bar of everyone else was something that we really wanted to make sure that we hit on. So they didn't have to worry about...so retention was not that they couldn't quote, "hack it" like everyone else like the people say, or they didn't have the aptitude. The retention was all about is the company creating a good enough environment for these folks to want to stay at that point? +CHAD: What is the tech stack that you're teaching now? +ALEXANDRA: Yeah, we just switched. We talked about this for a little bit. We just switched from our beloved Ruby on Rails. We were Ruby on Rails for a very long time. But we just switched to Python, React, JavaScript. HTML and CSS is part of our curriculum. And yeah, that's it, Python, React, JavaScript. +CHAD: I don't take the switch away from Rails personally. [laughs] +ALEXANDRA: People did. We had companies being like, "What are you doing? We love Ruby." And we were like, "Yes, we do too, but we had to move forward and on." [laughs] Ada started at the same time Ruby was in the spotlight, too, eight years ago. +CHAD: So is that what you're seeing in the industry now, is Python, React are in more development, in more demand? +ALEXANDRA: Yeah, we're seeing that definitely come up. We put together a steering committee for our curriculum when we made this switch. We basically just brought in our partners to help us like, okay, what is the thing because, you know, our partners range...every cohort, we have a company that sponsors the education of one of our students, and then they take that student on as an intern. So we can't please everyone. We knew we couldn't please everyone here. But we wanted to find a good middle, and Python seemed like a really good middle. Python, React was a good middle for us to go towards for just the future. +Eight years from now, again, we'll probably be in the same place we are right now. But we say it's like teaching Spanish. We're not teaching you building out a bunch of Python engineers. We're building out people that know how to be agile, know how to learn different curriculums, know how to be flexible and all that, and know that the industry is changing, and you have to be a lifelong learner, right? +CHAD: Yeah. +ALEXANDRA: You know this to be a part of this industry. +CHAD: Well, beyond the tech, what are some of the other things that students in Ada learn or focus on over the course of the program? +ALEXANDRA: I would say our curriculum is broken out into three distinctive pieces that are all a part of our everyday classroom. So that first part being that technical part that our students really are just getting the chops of what it means to be a software engineer, understanding a full tech stack, understanding the frontend, backend, the APIs that all connect the stuff, just making someone that sort of bare bones of what I think is a good software engineer. +The next step is that social justice piece, which is held up by our equity and policy team. They're really teaching students once you get in the door, it's not just about getting in the door; it's about staying in the room. And it's about not just diversity; it's about inclusion. And we're seeing that we cannot just expect just because someone's decided to sponsor an Ada student, we can't expect someone knowing how to support someone that is outside of what they've supported in the past, and we know what that looks like. +So we have to really create students who know what allyship looks like, know what advocacy for themselves looks like. So they can really manage up in this process, bring people in. We do not want to say someone did something or said something to me, so we're just going to push these people away because we found that when you push those people away, especially in the tech software engineering space, you're really just left out of it. You're just out of the system. So we have to figure out how to change the system from within. +So really teaching students how they can talk about gender expression, how they can talk about racial expression, how they can advocate for themselves while they're on the job. And the goal of all of this is actually to keep people on tech. We don't want our students having to talk about these things all the time. We want them to be talking about the tech that they're doing just like they want. And so we want to just keep things as much on tech as possible. +The third part is our professional development part. How do you manager up, take yourself in that first block to that SE2 SE3? And that's just helping folks with career development. +CHAD: When it comes to the inclusion piece, I imagine it's a little bit of a fine line to walk because you don't necessarily want to put all of the work of creating an inclusive environment on the people who have been historically marginalized. But at the same time, you want to set those people up for success coming out of your program. How directly do you provide training to the companies that are sponsoring? +ALEXANDRA: Completely directly. [laughter] We know that if we can get a whole...I would say I sign people at the CTO level and the senior manager level. They have the budget. They're the ones pulling the purse strings. But once we figure out, once you sign on as a company, your manager and mentor are going through our corporate accountability training. While our students are learning the technical part of it, our managers and mentors are going through a monthly training with our team to make sure they are ready to receive these interns. So when that intern comes on-site, they're speaking the same language. +We're not only teaching the students how to be allies and advocates. We're teaching the managers how to be. So many times, they're like, "Someone on my team keeps misgendering someone, and I don't know what to do." We had enough of those calls, so we decided to teach them what to do. And not only do we teach them, but we also put them in peer learning groups together so they can teach each other what to do because that's where they really start listening to each other. When two folks coming from the same background are having a conversation on how to be a better manager, we love that. +CHAD: Yeah, that's great. And I think that's really likely a very important component to overall success. Well, let's talk economics a little bit because I've gotten up on my soapbox before around how companies have traditionally been way too comfortable saying, "Well, we have this position open, and we're using recruiters." And the position has been vacant for months. And in the meantime, they're willing to pay recruiters tens of thousands of dollars trying to fill the position. +And I've always made the case like, tech and the way the economics work it would be better to invest that money that you're willing to give a recruiter into training people. When I learned about Ada, it really resonated with me. So what is the complete picture of how students afford to attend Ada, where the funding comes from, and how that all works out for them? +ALEXANDRA: Oh, you're speaking to the choir. [laughs] When I talk about this with companies, I am oftentimes like, "How much did you spend on recruiting last year?" And then they tell me the number, and I'm like, wow, okay. We work with companies we call them our company partners because they are partnering with us to complete this mission of Ada that we have, which is to educate more women and gender-expansive people to be software engineers. +Our business model is simple, but it works. We wanted to remove all barriers for entry for people that wanted to become software engineers within that group. So we wanted the program to be free. We knew that was always the case. We knew that there was this hole with bootcamps that was out there. This was seven, eight years ago where it was like people were going through these bootcamps and then not getting full-time jobs. And so we knew we didn't want to fall victim to that. +So what we did was put an internship on the backend and really got companies to not just put their money where their mouth is but put their time and resources where their mouth is. That's more money. So they pay $55,000, and that $55,000 educates the student while they're in class with us, keeps the program completely free for our students. And then the other part of their buy into this whole shebang is you have to now make this person a hireable junior engineer because they're going to do an internship with you. And then everyone's always like, okay, the return on investment. To me, the return on investment is you did good, company. +CHAD: [laughs] +ALEXANDRA: But also, the return on investment for a lot of our company partners, I call it the icing on the cake because it is not a part of our model. It is 70% of them convert their students to full-time jobs, full-time FTE offers from these internships. We had a company give...they sponsored six interns, gave six offers, and then went on to do a hiring loop with our graduating cohort and gave another 23 offers. +CHAD: Wow. +ALEXANDRA: And this happens every six months. So these companies that are out there saying it's a pipeline problem or I'm just going to spend money on this recruiter to go find talent, I'm like, are you kidding me? We're either in your backyard, or we're a phone call, phone call, excuse me, an email away. +CHAD: [laughs] A fax away. +ALEXANDRA: I age myself. I said Rolodex to our students, and people didn't know what it was, and I was so embarrassed. I was like, wow, I guess a LinkedIn I'm sorry. +CHAD: [laughs] +ALEXANDRA: But we're like, you know, the resource is there, the talent is there. We have 120 students in our cohorts, and that's only growing. We're expanding to Atlanta. We're expanding to the DC area. It's there. So when companies are like, "I don't know." I've seen us move the needle at mid-sized companies. There are companies like Amazon, and there are over 100 graduated Adies there. We've moved the needle. +So it's like, you just got to call or email at this point. There are other ways to do it. And if you keep going to the same well, you keep going to the colleges; you keep going to that recruit, yeah, you're going to fill up the same thing over and over again. +And we know 70% of jobs are received by...you’re networking with your friends, and you’re networking with your peers. And if something like 75% of the industry is white dudes or just dudes in general, then we're just going to keep bringing in the same person. And it's not just diversity is the right thing to do. It is the right thing to do, but it’s also like you build a better product, period. That's just a better product. +CHAD: Yeah, the different perspectives that people have, the different blind spots that people have. When you get rid of those, you build a better product. +ALEXANDRA: And we're talking about building the future here. We have to include the other 50% of the population. So it's imperative. It's not necessary; it is imperative we get up to that. You're at 40% in your company. We got to get up to 50%. We got to get a little bit more. And we got to make sure that 50% is diverse on all intersections of what diversity can mean. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So you mentioned the companies pay to sponsor individual students. You also have mentioned earlier in the conversation that you provide things like child care. So are the pooled resources of all of those sponsorships also going to pay for those additional benefits while in the program, or do you have another source of funds? +ALEXANDRA: We are still very much so a non-profit. [laughs] We have a good amount of philanthropic dollars coming our way, and it's individual donors. I would say one of our biggest clumps of donors, our biggest group of people that donate to Ada, are our alumni. They come out with 160% salary change, and they are the first people to see the value in giving back to Ada. We also have some major donors out there. +We just got a pretty large expansion grant from the Pivotal folks, which is Melinda French Gates, MacKenzie Bezos, and the Schusterman Foundation. They invested $10 million in helping us expand. That expansion has served more students. Wraparound services mostly come from philanthropic dollars. So donating to what we do, donating to keep our program equitable, is always very much needed because about 10% of our budget is all philanthropic dollars, and that's covering those wraparound services barriers to entry. +CHAD: Is healthcare one of the wraparound services that you provide? +ALEXANDRA: No. I wish. I mean, geez. +CHAD: I know. +ALEXANDRA: If the U.S. government gets it right, after they get it right, we'll follow soon. [laughter] But we're trying. We are trying to do it differently. We're trying to meet people where they are and see the reality of people's situations. And the reality is that if you're a woman or gender-expansive person and you want to take this chance, we offer a zero-interest either loan or a zero-interest grant that comes directly from Ada, or from our partner, Community Credit lab. And that's a zero-interest loan. We don't even check your credit. If you're in it with us, then we're going to get it in it with you. +And that zero-interest loan just gets recycled back to serve more people. So that zero-interest loan is while you're in class for that five and a half months, you're going to need still some money coming in. So we make sure you still have money coming in. The stipend hits when you get to internships, so from that 55,000, about 17 goes directly to the student for their stipend while they're interning. +Also, we give a childcare stipend. We're looking for a childcare partner out there because we really want to be able to make this more of a national program. But we're looking for that out there. But we give that stipend out to folks so they can pay for daycare or whatever they may need so they can actually come to the program. +We have a laptop program. You need a Mac to come to Ada. Everyone can't afford a Mac. We take donated Macs from companies that...companies sometimes give them a two-year life cycle for their Macs. So we can use it for another couple of years. So we take donations for Macs. And we also have a fund that we fund every year so people can buy a Mac. +And my favorite and I think one of the most needed things is we partner with BetterHelp and offer our students free therapy while they're in the classroom and while they're in their internship and a little bit after that as well. The free therapy was just...we're in a pandemic, and it's hit women hard. It's hit gender-expansive folks, parents, Brown folks, it's hit people hard. And so we're like, hey, why don't we, while you're in a pandemic, send you through the most rigorous part of your life? [laughs] +And so, making sure we were supporting people all around was really important to us. And it did nothing but create success for us. This did not make a deficit in our bottom line. This actually created more success for us. We saw when we did this; we got more people graduating. We get more people donating back. We get more people paying back their loans faster. So it just does nothing for the community but make it better and stronger. So we're going to continue to do it. It's going to continue to always be a part of who we are at Ada. But the wraparound services are key to the success. +CHAD: That's fantastic. So you mentioned you're expanding. Where is the original location? +ALEXANDRA: Seattle. We are a Seattle-based school. +CHAD: And you're expanding to Atlanta and DC you mentioned. +ALEXANDRA: Yeah. We first went digital because you know -- +CHAD: That is what I was going to ask. +ALEXANDRA: [laughs] +CHAD: How have you dealt with the pandemic with a primarily in-person model previously? And then how has that affected your expansion plans? +ALEXANDRA: The pandemic was shitty and just horrible in so many ways. And out of a lot of shitty and horrible times, it creates a lot of innovation, and that's what it did. Our leadership team is a group of Brown parents. And they went to work immediately. We switched from being an in-person classroom where there's a lunch club, and a push-up club, and there are hugs everywhere and to being 100% online program in three days with systems. And companies were coming to us saying, "How are you creating community in this time?" So we did it very quickly. It taught us that we can educate people digitally. +So the first thing we decided to do is like we've got our digital cohort up and running. So still, I would say in quotes, "our Seattle cohort and digital cohort," but digital cohort basically means you're partnering with a company that is fully digital, and they are not attached to anything geographically. And that helped us expand to Atlanta because it helped us jump over the hurdle of like, oh, we have to go get a brick and mortar. We have to set up this brick and mortar. Instead, we just decided to educate people still digitally. +If you're in the Atlanta cohort, you're still having your education 100% online, and your internship is going to be in person with an Atlanta-based tech company. So you might be but and see [inaudible 24:11] in Atlanta later on, but we can educate you digitally. So we didn't have to slow this down. +We saw the need just like the amount of women that lost their jobs in the pandemic. We were completely energized by the fact that we can do this. We have people that believe in us. They're giving us money. They're funding this. We can do it. So we went for it. And Atlanta is the first campus. We already have staff there. We already have a campus director on point there. +And then, the next expansion will be to the DC area. And we're excited to do the same thing. It's educate them digitally because that's what we've been doing for the last few years, and we're good at it. And find but and see partnerships in DC because that's how we can really make sure we have good programming that we know they can do and then give them to the sponsoring companies to complete their programming with the internship. +CHAD: So where are the current limits of growth for you then? +ALEXANDRA: Current limits for growth, I mean, we've been such a Seattle-based place, and COVID pushed us into that national arena, so not a lot of people outside of our geography know who we are. Pacific Northwest was our sweet spot because people used to have to move to Seattle to be a part of Ada. So we got a lot of Californians. We got a lot of Oregons, Montana, Idaho, some Floridians because Florida knows about...we have a very huge population of Floridians. I don't know how they know, but they know. +CHAD: [laughs] +ALEXANDRA: Our thing is, how do we get the Ada Developers Academy name and model out to the rest of the country? So they know that we are here, and we're an option for them if they want to become a software engineer. +CHAD: And right now, it sounds like you have your sights just set on the United States, not internationally. +ALEXANDRA: Not Internationally. I always joke about Ada at sea, but we'll see. +CHAD: [laughs] +ALEXANDRA: Give me 10, 20 years to get that spun up. But I would just love to...[laughs] but yeah, over the next five years, there'll be five markets in Ada. By 2025, we're hoping to educate 10,000 women and gender-expansive people. We just graduated a class of 72 last Thursday. And we just admitted another class of 120 that starts in March. So we're chugging. But right now, it's Seattle, digital, Atlanta, DC. I imagine there'll be a Southern region, and then probably a Midwest region coming after that. +CHAD: So, and then you have the purely digital cohort too? +ALEXANDRA: Yep. And that's that sort of the sixth market, purely digital, which means there are so many companies that went fully remote and have no plan on coming back. And so that's just a market that we want to make sure that we're...we want people to opt into that. That's for some people who want to be fully remote forever. Some people are seeing that they need some sort of community while doing this work. And so they want to have a but and see internship. And there's every which way in between. So we'll figure it out as we move through this pandemic like the rest of the folks. +CHAD: You've shared some numbers there. And I think sometimes it's good to put that in context because people don't realize that 10,000, on one hand, sounds like a small number in the grand scheme of the United States. But actually, it's a very large number. +ALEXANDRA: It's huge. +CHAD: The U.S. only graduates around 65,000 CS graduates a year in the whole United States, so just to put that in context for people. +ALEXANDRA: Yeah, it's huge. I looked at the numbers for...I'm in Seattle, and I'll just say there's a college here, a large college here in Seattle, and they graduated 300 CS folks last year, and 20% of them were women. And we graduated in six months, 72 women and gender-expansive, and our focus is Brown folks, low socioeconomic folks. So you could just imagine underneath that umbrella of women, even under that, the diversity that you see. We're getting up there with some of our colleges, and we're doing this every six months. +And so it's a powerful model. It's the reason why I've been here for six years. It's the reason why I get really excited talking about this program. [laughs] I don't know if you can tell, but I get really excited talking about it. Because once people get in, they love being a part of our program, and they love being a partner with us. And it's a cool place to be. It just feels like a transformative place right now. And I think that we can really make a difference. +CHAD: Yeah, your excitement, and I'm a big believer in the opportunity. Your excitement is clear [laughs] when you're talking about it. How did you get into this work? +ALEXANDRA: I was in recruiting before. I did technical recruiting, contractor for a few different places. And I just saw the amount...and I came from a working-class. My family is from the Deep South in Louisiana. And the average income from the town I'm from is $26,000, and that was my reality. +And then, when I started technical recruiting, it was insane. The amount of wealth that was a part of this churn, the going to these colleges, early recruiting, paying people $6,000 a month, paying them a living stipend, making sure they had a plane ticket home, hot air balloons, tours of people's, you know, these millionaires houses. I was like, holy crap, this has to be more readily available. +And again, having two working-class black parents, they didn't even know what software development was. We didn't even know that was a possibility. My dad was like, "We're getting a computer," because he wanted to be on the forefront. And we got to that clear Mac that was like a purple color. We had that purple one. +CHAD: [laughs] +ALEXANDRA: And my dad was like, "We've one." But still, there were kids in my school and in my college that had been around computers their whole lives; their schools had programming and things. So they just had that extra step. My opportunity to see in was recruiting. And after that, I was like, okay, where do I find the intersection of this and what I want to do, which is making sure that black folks have money? To be crude about it. [laughs] If we’re going to work and live in a capitalist society, then I want us to have some coins to play, and that is where I found Ada. And I love having this place. +I just get to be a part of this place where I just get to open doors or show people a door. They can open it themselves and go through, and just that's the amazing part of me, a part of this is watching people change their lives, buy their grandparents' homes, pay off their student debt, get a divorce, anything they want to do. [laughs] But to have the agency to do it in this world we live in, in the society we live in, and that's all I care about is that agency. +CHAD: Yeah, I was very privileged to be exposed to computers really early on and get to experience that spark of I love this. This is what I want to do. And I talk to so many people who just never had that opportunity to discover that that was even a thing that they could do, let alone love. It's just incredible when I meet someone who's like a plumber, and then they somehow get that exposure to computers or technology, and you see that spark go off for them. And it's amazing. +ALEXANDRA: It's so cool. It's one of my favorite...like; our admissions process is pretty rigorous. I think the average is like 15% or 20%, depending on the cohort admissions process. And to hear how obsessed these airline stewardesses or hairdressers or mothers are obsessed with coding, I'm like, yes, yes. Or these folks who are like...Oh, we had this woman who she was an immigrant from...she fled Israel, and she came to the U.S. And she's like, the only thing she knew about coding before she started was she had one time saw someone with two screens in a movie. +CHAD: [laughs] +ALEXANDRA: And she saw them on the computer, and she saw two screens. And then she started going through finding free stuff online. She found Ada. And this person's sitting in front of me talking about how geek they are about arrays and loops, and I'm like, yes, this is amazing. And to watch that person graduate less than a year later with just the salary that she got from Microsoft, and just the feeling that she felt when she got to call home and say, "Hey, I'm a software engineer now," I was like, all day, all day. That's like the gravy for this. +CHAD: It has nothing to do with aptitude. It has everything to do with opportunity. +ALEXANDRA: Oh my gosh. Yeah, opportunities. Yeah, it's everything here. +CHAD: Well, that's great. And Ada is providing folks with that opportunity. And I am so excited to hear about it and share it with our audience. Hopefully, students are listening and want to sign up but also those sponsoring companies too, right? +ALEXANDRA: Yeah, for sure. Sponsoring companies too. We love you too. You keep the wheels on this bus. So definitely give us a call. +CHAD: So if folks want to get in touch, where's the best place for them to do that? +ALEXANDRA: Our website that's the best place to start, adadevelopersacademy.org. And there there is stuff on corporate partnership. If you sign up on the partners' email list, it leads you right to my email. And then, for students, we have full admissions. Our admissions opens in March for the next Atlanta cohort. There are going to be 48 seats in Atlanta, 60 seats digitally, and 60 seats in Seattle. I would say get ready for that via our website. +CHAD: Awesome. You can subscribe to the show and find notes for this episode at giantrobots.fm along with all those links that Alexandra just mentioned and a transcript of the entire episode. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Alexandra Holien. + + + Alexandra Holien is the Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. She talks with Chad about working for a nonprofit that prioritizes teaching Black, Brown, Latinx, Indigenous, Hawaiian, Pacific Islander, and low-income folks software development for free.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Alexandra Holien, Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. Alexandra, thank you for joining me.

+ +

ALEXANDRA: Thank you for having me. I'm excited.

+ +

CHAD: Let's start right off the bat with giving folks a brief overview of what Ada actually is.

+ +

ALEXANDRA: Yeah, I'd love to. Ada Developers Academy we are a super unique non-profit, and I think, well-functioning business. We're a tuition-free 11-month software developing bootcamp academy for women and gender-expansive people. That may sound like some of the other bootcamps you've seen out there, but we're completely different. We have this really cool intersection of education, social justice, equity, bringing money to the people that need money sort of drive about us.

+ +

We prioritize serving Black, Latine, Indigenous, Hawaiian, and Pacific Islander folks, and low-income folks. And we prioritize them because they've been left out of this capitalistic system the most. And we think if we can really put money in the hands of these gorgeous, resilient communities through the career of software development and one of the hugest wealth engines of our time, then we're going to change the world. We're crazy because it's like we're free for our students.

+ +

CHAD: [chuckles]

+ +

ALEXANDRA: There are wraparound services, ridiculous, not even ridiculous, just like, natural. And it seems unique, and it seems crazy. But these things that we're doing to support our students are actually just human and basic needs, providing comprehensive support for our students financially, childcare, mental health care, free laptops, just making sure that they're set up for success, unlike I think other more traditional education systems. So they can go and be really amazing software developers.

+ +

And it's proven time and time again if you just set people up, open the door, give them the opportunity, make sure that you're creating equity, then 92% of those folks what we're seeing is our numbers are going to go out there and get full-time software development jobs. So that's Ada in the smallest nutshell and believe me, I'm going to tell you way more.

+ +

CHAD: Well, we're going to dig into each of those things and more. I interview a lot of people who graduate from bootcamps. We have a pretty wide-reaching apprentice program. And I'm pretty familiar with what it looks like when people are graduating from those programs. And you can graduate from a three-month program and be successful, and I don't mean to imply that you can't be.

+ +

But I do see folks who go to slightly longer programs, up to 11 months, a year like at Ada, and those people are often much more well-rounded developers not only with the technical skills but with all of the other skills that are important to development. How intentional was the length of the curriculum? And was there pressure early on to get people into the market faster?

+ +

ALEXANDRA: Yeah, great question. I think that so many...let me answer your first question, which is how intentional was it? It had to be at the forefront of what we wanted to do. And the reason why it had to be is that we were taking a group of people that had already been left out of the system.

+ +

And we already knew that there were going to be steps that they had to take to get into...like, once they got into the tech industry, getting in and staying in was going to be harder than their counterparts, harder than the white dude who took apart a computer or a Nintendo when they were in the 80s and growing up because their dads were software engineers. And then went on to college and knew they were going to be software engineers.

+ +

So our founders, Scott Case and Elise Worthy, were so intentional in making sure that the technical bar and the technical merit of our students going into the industry was not what they were going to have to worry about. That was not going to be the thing that kept them up at night thinking like, oh, man, I don't know if I can do this because I don't understand it. That was not going to be it because we knew there were going to be other things.

+ +

We knew there were going to be people mistaking you for the secretary. And these are examples that are all true. It's mistaking you for the secretary or the person that's the assistant or the executive assistant when they walk into the room or that person that constantly misgenders you. We knew there were going to be other really big obstacles that they're going to have to overcome when walking into a very homogenous industry like the software development industry of the United States. We knew that that was going to be the big thing.

+ +

So being intentional about the programming that we were going to offer our students that five and a half months of nine-to-five intense programming that also concentrates on what I don't think a lot of bootcamps really concentrate on, that CS fundamentals part of it, showing people that that is a part of the world. It's not the part of the world of the most entry-level software engineers, but it is there, so showing them that that's there.

+ +

And then giving them that internship, giving them that on-the-job training that Ada does that no other bootcamp does like we do. That sort of on-the-job training where you go in, and you see what does that practice of what you learned in code look like in real-time when you put it next to one of our sponsoring companies' tech stack?

+ +

So it had to be really intentional. I don't know if it was like, yes, this has to be perfectly like this. I think we definitely iterated and made it better over the years. But making sure that the technical bar of our students was at the technical bar of everyone else was something that we really wanted to make sure that we hit on. So they didn't have to worry about...so retention was not that they couldn't quote, "hack it" like everyone else like the people say, or they didn't have the aptitude. The retention was all about is the company creating a good enough environment for these folks to want to stay at that point?

+ +

CHAD: What is the tech stack that you're teaching now?

+ +

ALEXANDRA: Yeah, we just switched. We talked about this for a little bit. We just switched from our beloved Ruby on Rails. We were Ruby on Rails for a very long time. But we just switched to Python, React, JavaScript. HTML and CSS is part of our curriculum. And yeah, that's it, Python, React, JavaScript.

+ +

CHAD: I don't take the switch away from Rails personally. [laughs]

+ +

ALEXANDRA: People did. We had companies being like, "What are you doing? We love Ruby." And we were like, "Yes, we do too, but we had to move forward and on." [laughs] Ada started at the same time Ruby was in the spotlight, too, eight years ago.

+ +

CHAD: So is that what you're seeing in the industry now, is Python, React are in more development, in more demand?

+ +

ALEXANDRA: Yeah, we're seeing that definitely come up. We put together a steering committee for our curriculum when we made this switch. We basically just brought in our partners to help us like, okay, what is the thing because, you know, our partners range...every cohort, we have a company that sponsors the education of one of our students, and then they take that student on as an intern. So we can't please everyone. We knew we couldn't please everyone here. But we wanted to find a good middle, and Python seemed like a really good middle. Python, React was a good middle for us to go towards for just the future.

+ +

Eight years from now, again, we'll probably be in the same place we are right now. But we say it's like teaching Spanish. We're not teaching you building out a bunch of Python engineers. We're building out people that know how to be agile, know how to learn different curriculums, know how to be flexible and all that, and know that the industry is changing, and you have to be a lifelong learner, right?

+ +

CHAD: Yeah.

+ +

ALEXANDRA: You know this to be a part of this industry.

+ +

CHAD: Well, beyond the tech, what are some of the other things that students in Ada learn or focus on over the course of the program?

+ +

ALEXANDRA: I would say our curriculum is broken out into three distinctive pieces that are all a part of our everyday classroom. So that first part being that technical part that our students really are just getting the chops of what it means to be a software engineer, understanding a full tech stack, understanding the frontend, backend, the APIs that all connect the stuff, just making someone that sort of bare bones of what I think is a good software engineer.

+ +

The next step is that social justice piece, which is held up by our equity and policy team. They're really teaching students once you get in the door, it's not just about getting in the door; it's about staying in the room. And it's about not just diversity; it's about inclusion. And we're seeing that we cannot just expect just because someone's decided to sponsor an Ada student, we can't expect someone knowing how to support someone that is outside of what they've supported in the past, and we know what that looks like.

+ +

So we have to really create students who know what allyship looks like, know what advocacy for themselves looks like. So they can really manage up in this process, bring people in. We do not want to say someone did something or said something to me, so we're just going to push these people away because we found that when you push those people away, especially in the tech software engineering space, you're really just left out of it. You're just out of the system. So we have to figure out how to change the system from within.

+ +

So really teaching students how they can talk about gender expression, how they can talk about racial expression, how they can advocate for themselves while they're on the job. And the goal of all of this is actually to keep people on tech. We don't want our students having to talk about these things all the time. We want them to be talking about the tech that they're doing just like they want. And so we want to just keep things as much on tech as possible.

+ +

The third part is our professional development part. How do you manager up, take yourself in that first block to that SE2 SE3? And that's just helping folks with career development.

+ +

CHAD: When it comes to the inclusion piece, I imagine it's a little bit of a fine line to walk because you don't necessarily want to put all of the work of creating an inclusive environment on the people who have been historically marginalized. But at the same time, you want to set those people up for success coming out of your program. How directly do you provide training to the companies that are sponsoring?

+ +

ALEXANDRA: Completely directly. [laughter] We know that if we can get a whole...I would say I sign people at the CTO level and the senior manager level. They have the budget. They're the ones pulling the purse strings. But once we figure out, once you sign on as a company, your manager and mentor are going through our corporate accountability training. While our students are learning the technical part of it, our managers and mentors are going through a monthly training with our team to make sure they are ready to receive these interns. So when that intern comes on-site, they're speaking the same language.

+ +

We're not only teaching the students how to be allies and advocates. We're teaching the managers how to be. So many times, they're like, "Someone on my team keeps misgendering someone, and I don't know what to do." We had enough of those calls, so we decided to teach them what to do. And not only do we teach them, but we also put them in peer learning groups together so they can teach each other what to do because that's where they really start listening to each other. When two folks coming from the same background are having a conversation on how to be a better manager, we love that.

+ +

CHAD: Yeah, that's great. And I think that's really likely a very important component to overall success. Well, let's talk economics a little bit because I've gotten up on my soapbox before around how companies have traditionally been way too comfortable saying, "Well, we have this position open, and we're using recruiters." And the position has been vacant for months. And in the meantime, they're willing to pay recruiters tens of thousands of dollars trying to fill the position.

+ +

And I've always made the case like, tech and the way the economics work it would be better to invest that money that you're willing to give a recruiter into training people. When I learned about Ada, it really resonated with me. So what is the complete picture of how students afford to attend Ada, where the funding comes from, and how that all works out for them?

+ +

ALEXANDRA: Oh, you're speaking to the choir. [laughs] When I talk about this with companies, I am oftentimes like, "How much did you spend on recruiting last year?" And then they tell me the number, and I'm like, wow, okay. We work with companies we call them our company partners because they are partnering with us to complete this mission of Ada that we have, which is to educate more women and gender-expansive people to be software engineers.

+ +

Our business model is simple, but it works. We wanted to remove all barriers for entry for people that wanted to become software engineers within that group. So we wanted the program to be free. We knew that was always the case. We knew that there was this hole with bootcamps that was out there. This was seven, eight years ago where it was like people were going through these bootcamps and then not getting full-time jobs. And so we knew we didn't want to fall victim to that.

+ +

So what we did was put an internship on the backend and really got companies to not just put their money where their mouth is but put their time and resources where their mouth is. That's more money. So they pay $55,000, and that $55,000 educates the student while they're in class with us, keeps the program completely free for our students. And then the other part of their buy into this whole shebang is you have to now make this person a hireable junior engineer because they're going to do an internship with you. And then everyone's always like, okay, the return on investment. To me, the return on investment is you did good, company.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: But also, the return on investment for a lot of our company partners, I call it the icing on the cake because it is not a part of our model. It is 70% of them convert their students to full-time jobs, full-time FTE offers from these internships. We had a company give...they sponsored six interns, gave six offers, and then went on to do a hiring loop with our graduating cohort and gave another 23 offers.

+ +

CHAD: Wow.

+ +

ALEXANDRA: And this happens every six months. So these companies that are out there saying it's a pipeline problem or I'm just going to spend money on this recruiter to go find talent, I'm like, are you kidding me? We're either in your backyard, or we're a phone call, phone call, excuse me, an email away.

+ +

CHAD: [laughs] A fax away.

+ +

ALEXANDRA: I age myself. I said Rolodex to our students, and people didn't know what it was, and I was so embarrassed. I was like, wow, I guess a LinkedIn I'm sorry.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: But we're like, you know, the resource is there, the talent is there. We have 120 students in our cohorts, and that's only growing. We're expanding to Atlanta. We're expanding to the DC area. It's there. So when companies are like, "I don't know." I've seen us move the needle at mid-sized companies. There are companies like Amazon, and there are over 100 graduated Adies there. We've moved the needle.

+ +

So it's like, you just got to call or email at this point. There are other ways to do it. And if you keep going to the same well, you keep going to the colleges; you keep going to that recruit, yeah, you're going to fill up the same thing over and over again.

+ +

And we know 70% of jobs are received by...you’re networking with your friends, and you’re networking with your peers. And if something like 75% of the industry is white dudes or just dudes in general, then we're just going to keep bringing in the same person. And it's not just diversity is the right thing to do. It is the right thing to do, but it’s also like you build a better product, period. That's just a better product.

+ +

CHAD: Yeah, the different perspectives that people have, the different blind spots that people have. When you get rid of those, you build a better product.

+ +

ALEXANDRA: And we're talking about building the future here. We have to include the other 50% of the population. So it's imperative. It's not necessary; it is imperative we get up to that. You're at 40% in your company. We got to get up to 50%. We got to get a little bit more. And we got to make sure that 50% is diverse on all intersections of what diversity can mean.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you mentioned the companies pay to sponsor individual students. You also have mentioned earlier in the conversation that you provide things like child care. So are the pooled resources of all of those sponsorships also going to pay for those additional benefits while in the program, or do you have another source of funds?

+ +

ALEXANDRA: We are still very much so a non-profit. [laughs] We have a good amount of philanthropic dollars coming our way, and it's individual donors. I would say one of our biggest clumps of donors, our biggest group of people that donate to Ada, are our alumni. They come out with 160% salary change, and they are the first people to see the value in giving back to Ada. We also have some major donors out there.

+ +

We just got a pretty large expansion grant from the Pivotal folks, which is Melinda French Gates, MacKenzie Bezos, and the Schusterman Foundation. They invested $10 million in helping us expand. That expansion has served more students. Wraparound services mostly come from philanthropic dollars. So donating to what we do, donating to keep our program equitable, is always very much needed because about 10% of our budget is all philanthropic dollars, and that's covering those wraparound services barriers to entry.

+ +

CHAD: Is healthcare one of the wraparound services that you provide?

+ +

ALEXANDRA: No. I wish. I mean, geez.

+ +

CHAD: I know.

+ +

ALEXANDRA: If the U.S. government gets it right, after they get it right, we'll follow soon. [laughter] But we're trying. We are trying to do it differently. We're trying to meet people where they are and see the reality of people's situations. And the reality is that if you're a woman or gender-expansive person and you want to take this chance, we offer a zero-interest either loan or a zero-interest grant that comes directly from Ada, or from our partner, Community Credit lab. And that's a zero-interest loan. We don't even check your credit. If you're in it with us, then we're going to get it in it with you.

+ +

And that zero-interest loan just gets recycled back to serve more people. So that zero-interest loan is while you're in class for that five and a half months, you're going to need still some money coming in. So we make sure you still have money coming in. The stipend hits when you get to internships, so from that 55,000, about 17 goes directly to the student for their stipend while they're interning.

+ +

Also, we give a childcare stipend. We're looking for a childcare partner out there because we really want to be able to make this more of a national program. But we're looking for that out there. But we give that stipend out to folks so they can pay for daycare or whatever they may need so they can actually come to the program.

+ +

We have a laptop program. You need a Mac to come to Ada. Everyone can't afford a Mac. We take donated Macs from companies that...companies sometimes give them a two-year life cycle for their Macs. So we can use it for another couple of years. So we take donations for Macs. And we also have a fund that we fund every year so people can buy a Mac.

+ +

And my favorite and I think one of the most needed things is we partner with BetterHelp and offer our students free therapy while they're in the classroom and while they're in their internship and a little bit after that as well. The free therapy was just...we're in a pandemic, and it's hit women hard. It's hit gender-expansive folks, parents, Brown folks, it's hit people hard. And so we're like, hey, why don't we, while you're in a pandemic, send you through the most rigorous part of your life? [laughs]

+ +

And so, making sure we were supporting people all around was really important to us. And it did nothing but create success for us. This did not make a deficit in our bottom line. This actually created more success for us. We saw when we did this; we got more people graduating. We get more people donating back. We get more people paying back their loans faster. So it just does nothing for the community but make it better and stronger. So we're going to continue to do it. It's going to continue to always be a part of who we are at Ada. But the wraparound services are key to the success.

+ +

CHAD: That's fantastic. So you mentioned you're expanding. Where is the original location?

+ +

ALEXANDRA: Seattle. We are a Seattle-based school.

+ +

CHAD: And you're expanding to Atlanta and DC you mentioned.

+ +

ALEXANDRA: Yeah. We first went digital because you know --

+ +

CHAD: That is what I was going to ask.

+ +

ALEXANDRA: [laughs]

+ +

CHAD: How have you dealt with the pandemic with a primarily in-person model previously? And then how has that affected your expansion plans?

+ +

ALEXANDRA: The pandemic was shitty and just horrible in so many ways. And out of a lot of shitty and horrible times, it creates a lot of innovation, and that's what it did. Our leadership team is a group of Brown parents. And they went to work immediately. We switched from being an in-person classroom where there's a lunch club, and a push-up club, and there are hugs everywhere and to being 100% online program in three days with systems. And companies were coming to us saying, "How are you creating community in this time?" So we did it very quickly. It taught us that we can educate people digitally.

+ +

So the first thing we decided to do is like we've got our digital cohort up and running. So still, I would say in quotes, "our Seattle cohort and digital cohort," but digital cohort basically means you're partnering with a company that is fully digital, and they are not attached to anything geographically. And that helped us expand to Atlanta because it helped us jump over the hurdle of like, oh, we have to go get a brick and mortar. We have to set up this brick and mortar. Instead, we just decided to educate people still digitally.

+ +

If you're in the Atlanta cohort, you're still having your education 100% online, and your internship is going to be in person with an Atlanta-based tech company. So you might be but and see [inaudible 24:11] in Atlanta later on, but we can educate you digitally. So we didn't have to slow this down.

+ +

We saw the need just like the amount of women that lost their jobs in the pandemic. We were completely energized by the fact that we can do this. We have people that believe in us. They're giving us money. They're funding this. We can do it. So we went for it. And Atlanta is the first campus. We already have staff there. We already have a campus director on point there.

+ +

And then, the next expansion will be to the DC area. And we're excited to do the same thing. It's educate them digitally because that's what we've been doing for the last few years, and we're good at it. And find but and see partnerships in DC because that's how we can really make sure we have good programming that we know they can do and then give them to the sponsoring companies to complete their programming with the internship.

+ +

CHAD: So where are the current limits of growth for you then?

+ +

ALEXANDRA: Current limits for growth, I mean, we've been such a Seattle-based place, and COVID pushed us into that national arena, so not a lot of people outside of our geography know who we are. Pacific Northwest was our sweet spot because people used to have to move to Seattle to be a part of Ada. So we got a lot of Californians. We got a lot of Oregons, Montana, Idaho, some Floridians because Florida knows about...we have a very huge population of Floridians. I don't know how they know, but they know.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: Our thing is, how do we get the Ada Developers Academy name and model out to the rest of the country? So they know that we are here, and we're an option for them if they want to become a software engineer.

+ +

CHAD: And right now, it sounds like you have your sights just set on the United States, not internationally.

+ +

ALEXANDRA: Not Internationally. I always joke about Ada at sea, but we'll see.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: Give me 10, 20 years to get that spun up. But I would just love to...[laughs] but yeah, over the next five years, there'll be five markets in Ada. By 2025, we're hoping to educate 10,000 women and gender-expansive people. We just graduated a class of 72 last Thursday. And we just admitted another class of 120 that starts in March. So we're chugging. But right now, it's Seattle, digital, Atlanta, DC. I imagine there'll be a Southern region, and then probably a Midwest region coming after that.

+ +

CHAD: So, and then you have the purely digital cohort too?

+ +

ALEXANDRA: Yep. And that's that sort of the sixth market, purely digital, which means there are so many companies that went fully remote and have no plan on coming back. And so that's just a market that we want to make sure that we're...we want people to opt into that. That's for some people who want to be fully remote forever. Some people are seeing that they need some sort of community while doing this work. And so they want to have a but and see internship. And there's every which way in between. So we'll figure it out as we move through this pandemic like the rest of the folks.

+ +

CHAD: You've shared some numbers there. And I think sometimes it's good to put that in context because people don't realize that 10,000, on one hand, sounds like a small number in the grand scheme of the United States. But actually, it's a very large number.

+ +

ALEXANDRA: It's huge.

+ +

CHAD: The U.S. only graduates around 65,000 CS graduates a year in the whole United States, so just to put that in context for people.

+ +

ALEXANDRA: Yeah, it's huge. I looked at the numbers for...I'm in Seattle, and I'll just say there's a college here, a large college here in Seattle, and they graduated 300 CS folks last year, and 20% of them were women. And we graduated in six months, 72 women and gender-expansive, and our focus is Brown folks, low socioeconomic folks. So you could just imagine underneath that umbrella of women, even under that, the diversity that you see. We're getting up there with some of our colleges, and we're doing this every six months.

+ +

And so it's a powerful model. It's the reason why I've been here for six years. It's the reason why I get really excited talking about this program. [laughs] I don't know if you can tell, but I get really excited talking about it. Because once people get in, they love being a part of our program, and they love being a partner with us. And it's a cool place to be. It just feels like a transformative place right now. And I think that we can really make a difference.

+ +

CHAD: Yeah, your excitement, and I'm a big believer in the opportunity. Your excitement is clear [laughs] when you're talking about it. How did you get into this work?

+ +

ALEXANDRA: I was in recruiting before. I did technical recruiting, contractor for a few different places. And I just saw the amount...and I came from a working-class. My family is from the Deep South in Louisiana. And the average income from the town I'm from is $26,000, and that was my reality.

+ +

And then, when I started technical recruiting, it was insane. The amount of wealth that was a part of this churn, the going to these colleges, early recruiting, paying people $6,000 a month, paying them a living stipend, making sure they had a plane ticket home, hot air balloons, tours of people's, you know, these millionaires houses. I was like, holy crap, this has to be more readily available.

+ +

And again, having two working-class black parents, they didn't even know what software development was. We didn't even know that was a possibility. My dad was like, "We're getting a computer," because he wanted to be on the forefront. And we got to that clear Mac that was like a purple color. We had that purple one.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: And my dad was like, "We've one." But still, there were kids in my school and in my college that had been around computers their whole lives; their schools had programming and things. So they just had that extra step. My opportunity to see in was recruiting. And after that, I was like, okay, where do I find the intersection of this and what I want to do, which is making sure that black folks have money? To be crude about it. [laughs] If we’re going to work and live in a capitalist society, then I want us to have some coins to play, and that is where I found Ada. And I love having this place.

+ +

I just get to be a part of this place where I just get to open doors or show people a door. They can open it themselves and go through, and just that's the amazing part of me, a part of this is watching people change their lives, buy their grandparents' homes, pay off their student debt, get a divorce, anything they want to do. [laughs] But to have the agency to do it in this world we live in, in the society we live in, and that's all I care about is that agency.

+ +

CHAD: Yeah, I was very privileged to be exposed to computers really early on and get to experience that spark of I love this. This is what I want to do. And I talk to so many people who just never had that opportunity to discover that that was even a thing that they could do, let alone love. It's just incredible when I meet someone who's like a plumber, and then they somehow get that exposure to computers or technology, and you see that spark go off for them. And it's amazing.

+ +

ALEXANDRA: It's so cool. It's one of my favorite...like; our admissions process is pretty rigorous. I think the average is like 15% or 20%, depending on the cohort admissions process. And to hear how obsessed these airline stewardesses or hairdressers or mothers are obsessed with coding, I'm like, yes, yes. Or these folks who are like...Oh, we had this woman who she was an immigrant from...she fled Israel, and she came to the U.S. And she's like, the only thing she knew about coding before she started was she had one time saw someone with two screens in a movie.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: And she saw them on the computer, and she saw two screens. And then she started going through finding free stuff online. She found Ada. And this person's sitting in front of me talking about how geek they are about arrays and loops, and I'm like, yes, this is amazing. And to watch that person graduate less than a year later with just the salary that she got from Microsoft, and just the feeling that she felt when she got to call home and say, "Hey, I'm a software engineer now," I was like, all day, all day. That's like the gravy for this.

+ +

CHAD: It has nothing to do with aptitude. It has everything to do with opportunity.

+ +

ALEXANDRA: Oh my gosh. Yeah, opportunities. Yeah, it's everything here.

+ +

CHAD: Well, that's great. And Ada is providing folks with that opportunity. And I am so excited to hear about it and share it with our audience. Hopefully, students are listening and want to sign up but also those sponsoring companies too, right?

+ +

ALEXANDRA: Yeah, for sure. Sponsoring companies too. We love you too. You keep the wheels on this bus. So definitely give us a call.

+ +

CHAD: So if folks want to get in touch, where's the best place for them to do that?

+ +

ALEXANDRA: Our website that's the best place to start, adadevelopersacademy.org. And there there is stuff on corporate partnership. If you sign up on the partners' email list, it leads you right to my email. And then, for students, we have full admissions. Our admissions opens in March for the next Atlanta cohort. There are going to be 48 seats in Atlanta, 60 seats digitally, and 60 seats in Seattle. I would say get ready for that via our website.

+ +

CHAD: Awesome. You can subscribe to the show and find notes for this episode at giantrobots.fm along with all those links that Alexandra just mentioned and a transcript of the entire episode. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Alexandra Holien.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Alexandra Holien is the Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. She talks with Chad about working for a nonprofit that prioritizes teaching Black, Brown, Latinx, Indigenous, Hawaiian, Pacific Islander, and low-income folks software development for free.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Alexandra Holien, Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. Alexandra, thank you for joining me.

+ +

ALEXANDRA: Thank you for having me. I'm excited.

+ +

CHAD: Let's start right off the bat with giving folks a brief overview of what Ada actually is.

+ +

ALEXANDRA: Yeah, I'd love to. Ada Developers Academy we are a super unique non-profit, and I think, well-functioning business. We're a tuition-free 11-month software developing bootcamp academy for women and gender-expansive people. That may sound like some of the other bootcamps you've seen out there, but we're completely different. We have this really cool intersection of education, social justice, equity, bringing money to the people that need money sort of drive about us.

+ +

We prioritize serving Black, Latine, Indigenous, Hawaiian, and Pacific Islander folks, and low-income folks. And we prioritize them because they've been left out of this capitalistic system the most. And we think if we can really put money in the hands of these gorgeous, resilient communities through the career of software development and one of the hugest wealth engines of our time, then we're going to change the world. We're crazy because it's like we're free for our students.

+ +

CHAD: [chuckles]

+ +

ALEXANDRA: There are wraparound services, ridiculous, not even ridiculous, just like, natural. And it seems unique, and it seems crazy. But these things that we're doing to support our students are actually just human and basic needs, providing comprehensive support for our students financially, childcare, mental health care, free laptops, just making sure that they're set up for success, unlike I think other more traditional education systems. So they can go and be really amazing software developers.

+ +

And it's proven time and time again if you just set people up, open the door, give them the opportunity, make sure that you're creating equity, then 92% of those folks what we're seeing is our numbers are going to go out there and get full-time software development jobs. So that's Ada in the smallest nutshell and believe me, I'm going to tell you way more.

+ +

CHAD: Well, we're going to dig into each of those things and more. I interview a lot of people who graduate from bootcamps. We have a pretty wide-reaching apprentice program. And I'm pretty familiar with what it looks like when people are graduating from those programs. And you can graduate from a three-month program and be successful, and I don't mean to imply that you can't be.

+ +

But I do see folks who go to slightly longer programs, up to 11 months, a year like at Ada, and those people are often much more well-rounded developers not only with the technical skills but with all of the other skills that are important to development. How intentional was the length of the curriculum? And was there pressure early on to get people into the market faster?

+ +

ALEXANDRA: Yeah, great question. I think that so many...let me answer your first question, which is how intentional was it? It had to be at the forefront of what we wanted to do. And the reason why it had to be is that we were taking a group of people that had already been left out of the system.

+ +

And we already knew that there were going to be steps that they had to take to get into...like, once they got into the tech industry, getting in and staying in was going to be harder than their counterparts, harder than the white dude who took apart a computer or a Nintendo when they were in the 80s and growing up because their dads were software engineers. And then went on to college and knew they were going to be software engineers.

+ +

So our founders, Scott Case and Elise Worthy, were so intentional in making sure that the technical bar and the technical merit of our students going into the industry was not what they were going to have to worry about. That was not going to be the thing that kept them up at night thinking like, oh, man, I don't know if I can do this because I don't understand it. That was not going to be it because we knew there were going to be other things.

+ +

We knew there were going to be people mistaking you for the secretary. And these are examples that are all true. It's mistaking you for the secretary or the person that's the assistant or the executive assistant when they walk into the room or that person that constantly misgenders you. We knew there were going to be other really big obstacles that they're going to have to overcome when walking into a very homogenous industry like the software development industry of the United States. We knew that that was going to be the big thing.

+ +

So being intentional about the programming that we were going to offer our students that five and a half months of nine-to-five intense programming that also concentrates on what I don't think a lot of bootcamps really concentrate on, that CS fundamentals part of it, showing people that that is a part of the world. It's not the part of the world of the most entry-level software engineers, but it is there, so showing them that that's there.

+ +

And then giving them that internship, giving them that on-the-job training that Ada does that no other bootcamp does like we do. That sort of on-the-job training where you go in, and you see what does that practice of what you learned in code look like in real-time when you put it next to one of our sponsoring companies' tech stack?

+ +

So it had to be really intentional. I don't know if it was like, yes, this has to be perfectly like this. I think we definitely iterated and made it better over the years. But making sure that the technical bar of our students was at the technical bar of everyone else was something that we really wanted to make sure that we hit on. So they didn't have to worry about...so retention was not that they couldn't quote, "hack it" like everyone else like the people say, or they didn't have the aptitude. The retention was all about is the company creating a good enough environment for these folks to want to stay at that point?

+ +

CHAD: What is the tech stack that you're teaching now?

+ +

ALEXANDRA: Yeah, we just switched. We talked about this for a little bit. We just switched from our beloved Ruby on Rails. We were Ruby on Rails for a very long time. But we just switched to Python, React, JavaScript. HTML and CSS is part of our curriculum. And yeah, that's it, Python, React, JavaScript.

+ +

CHAD: I don't take the switch away from Rails personally. [laughs]

+ +

ALEXANDRA: People did. We had companies being like, "What are you doing? We love Ruby." And we were like, "Yes, we do too, but we had to move forward and on." [laughs] Ada started at the same time Ruby was in the spotlight, too, eight years ago.

+ +

CHAD: So is that what you're seeing in the industry now, is Python, React are in more development, in more demand?

+ +

ALEXANDRA: Yeah, we're seeing that definitely come up. We put together a steering committee for our curriculum when we made this switch. We basically just brought in our partners to help us like, okay, what is the thing because, you know, our partners range...every cohort, we have a company that sponsors the education of one of our students, and then they take that student on as an intern. So we can't please everyone. We knew we couldn't please everyone here. But we wanted to find a good middle, and Python seemed like a really good middle. Python, React was a good middle for us to go towards for just the future.

+ +

Eight years from now, again, we'll probably be in the same place we are right now. But we say it's like teaching Spanish. We're not teaching you building out a bunch of Python engineers. We're building out people that know how to be agile, know how to learn different curriculums, know how to be flexible and all that, and know that the industry is changing, and you have to be a lifelong learner, right?

+ +

CHAD: Yeah.

+ +

ALEXANDRA: You know this to be a part of this industry.

+ +

CHAD: Well, beyond the tech, what are some of the other things that students in Ada learn or focus on over the course of the program?

+ +

ALEXANDRA: I would say our curriculum is broken out into three distinctive pieces that are all a part of our everyday classroom. So that first part being that technical part that our students really are just getting the chops of what it means to be a software engineer, understanding a full tech stack, understanding the frontend, backend, the APIs that all connect the stuff, just making someone that sort of bare bones of what I think is a good software engineer.

+ +

The next step is that social justice piece, which is held up by our equity and policy team. They're really teaching students once you get in the door, it's not just about getting in the door; it's about staying in the room. And it's about not just diversity; it's about inclusion. And we're seeing that we cannot just expect just because someone's decided to sponsor an Ada student, we can't expect someone knowing how to support someone that is outside of what they've supported in the past, and we know what that looks like.

+ +

So we have to really create students who know what allyship looks like, know what advocacy for themselves looks like. So they can really manage up in this process, bring people in. We do not want to say someone did something or said something to me, so we're just going to push these people away because we found that when you push those people away, especially in the tech software engineering space, you're really just left out of it. You're just out of the system. So we have to figure out how to change the system from within.

+ +

So really teaching students how they can talk about gender expression, how they can talk about racial expression, how they can advocate for themselves while they're on the job. And the goal of all of this is actually to keep people on tech. We don't want our students having to talk about these things all the time. We want them to be talking about the tech that they're doing just like they want. And so we want to just keep things as much on tech as possible.

+ +

The third part is our professional development part. How do you manager up, take yourself in that first block to that SE2 SE3? And that's just helping folks with career development.

+ +

CHAD: When it comes to the inclusion piece, I imagine it's a little bit of a fine line to walk because you don't necessarily want to put all of the work of creating an inclusive environment on the people who have been historically marginalized. But at the same time, you want to set those people up for success coming out of your program. How directly do you provide training to the companies that are sponsoring?

+ +

ALEXANDRA: Completely directly. [laughter] We know that if we can get a whole...I would say I sign people at the CTO level and the senior manager level. They have the budget. They're the ones pulling the purse strings. But once we figure out, once you sign on as a company, your manager and mentor are going through our corporate accountability training. While our students are learning the technical part of it, our managers and mentors are going through a monthly training with our team to make sure they are ready to receive these interns. So when that intern comes on-site, they're speaking the same language.

+ +

We're not only teaching the students how to be allies and advocates. We're teaching the managers how to be. So many times, they're like, "Someone on my team keeps misgendering someone, and I don't know what to do." We had enough of those calls, so we decided to teach them what to do. And not only do we teach them, but we also put them in peer learning groups together so they can teach each other what to do because that's where they really start listening to each other. When two folks coming from the same background are having a conversation on how to be a better manager, we love that.

+ +

CHAD: Yeah, that's great. And I think that's really likely a very important component to overall success. Well, let's talk economics a little bit because I've gotten up on my soapbox before around how companies have traditionally been way too comfortable saying, "Well, we have this position open, and we're using recruiters." And the position has been vacant for months. And in the meantime, they're willing to pay recruiters tens of thousands of dollars trying to fill the position.

+ +

And I've always made the case like, tech and the way the economics work it would be better to invest that money that you're willing to give a recruiter into training people. When I learned about Ada, it really resonated with me. So what is the complete picture of how students afford to attend Ada, where the funding comes from, and how that all works out for them?

+ +

ALEXANDRA: Oh, you're speaking to the choir. [laughs] When I talk about this with companies, I am oftentimes like, "How much did you spend on recruiting last year?" And then they tell me the number, and I'm like, wow, okay. We work with companies we call them our company partners because they are partnering with us to complete this mission of Ada that we have, which is to educate more women and gender-expansive people to be software engineers.

+ +

Our business model is simple, but it works. We wanted to remove all barriers for entry for people that wanted to become software engineers within that group. So we wanted the program to be free. We knew that was always the case. We knew that there was this hole with bootcamps that was out there. This was seven, eight years ago where it was like people were going through these bootcamps and then not getting full-time jobs. And so we knew we didn't want to fall victim to that.

+ +

So what we did was put an internship on the backend and really got companies to not just put their money where their mouth is but put their time and resources where their mouth is. That's more money. So they pay $55,000, and that $55,000 educates the student while they're in class with us, keeps the program completely free for our students. And then the other part of their buy into this whole shebang is you have to now make this person a hireable junior engineer because they're going to do an internship with you. And then everyone's always like, okay, the return on investment. To me, the return on investment is you did good, company.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: But also, the return on investment for a lot of our company partners, I call it the icing on the cake because it is not a part of our model. It is 70% of them convert their students to full-time jobs, full-time FTE offers from these internships. We had a company give...they sponsored six interns, gave six offers, and then went on to do a hiring loop with our graduating cohort and gave another 23 offers.

+ +

CHAD: Wow.

+ +

ALEXANDRA: And this happens every six months. So these companies that are out there saying it's a pipeline problem or I'm just going to spend money on this recruiter to go find talent, I'm like, are you kidding me? We're either in your backyard, or we're a phone call, phone call, excuse me, an email away.

+ +

CHAD: [laughs] A fax away.

+ +

ALEXANDRA: I age myself. I said Rolodex to our students, and people didn't know what it was, and I was so embarrassed. I was like, wow, I guess a LinkedIn I'm sorry.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: But we're like, you know, the resource is there, the talent is there. We have 120 students in our cohorts, and that's only growing. We're expanding to Atlanta. We're expanding to the DC area. It's there. So when companies are like, "I don't know." I've seen us move the needle at mid-sized companies. There are companies like Amazon, and there are over 100 graduated Adies there. We've moved the needle.

+ +

So it's like, you just got to call or email at this point. There are other ways to do it. And if you keep going to the same well, you keep going to the colleges; you keep going to that recruit, yeah, you're going to fill up the same thing over and over again.

+ +

And we know 70% of jobs are received by...you’re networking with your friends, and you’re networking with your peers. And if something like 75% of the industry is white dudes or just dudes in general, then we're just going to keep bringing in the same person. And it's not just diversity is the right thing to do. It is the right thing to do, but it’s also like you build a better product, period. That's just a better product.

+ +

CHAD: Yeah, the different perspectives that people have, the different blind spots that people have. When you get rid of those, you build a better product.

+ +

ALEXANDRA: And we're talking about building the future here. We have to include the other 50% of the population. So it's imperative. It's not necessary; it is imperative we get up to that. You're at 40% in your company. We got to get up to 50%. We got to get a little bit more. And we got to make sure that 50% is diverse on all intersections of what diversity can mean.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you mentioned the companies pay to sponsor individual students. You also have mentioned earlier in the conversation that you provide things like child care. So are the pooled resources of all of those sponsorships also going to pay for those additional benefits while in the program, or do you have another source of funds?

+ +

ALEXANDRA: We are still very much so a non-profit. [laughs] We have a good amount of philanthropic dollars coming our way, and it's individual donors. I would say one of our biggest clumps of donors, our biggest group of people that donate to Ada, are our alumni. They come out with 160% salary change, and they are the first people to see the value in giving back to Ada. We also have some major donors out there.

+ +

We just got a pretty large expansion grant from the Pivotal folks, which is Melinda French Gates, MacKenzie Bezos, and the Schusterman Foundation. They invested $10 million in helping us expand. That expansion has served more students. Wraparound services mostly come from philanthropic dollars. So donating to what we do, donating to keep our program equitable, is always very much needed because about 10% of our budget is all philanthropic dollars, and that's covering those wraparound services barriers to entry.

+ +

CHAD: Is healthcare one of the wraparound services that you provide?

+ +

ALEXANDRA: No. I wish. I mean, geez.

+ +

CHAD: I know.

+ +

ALEXANDRA: If the U.S. government gets it right, after they get it right, we'll follow soon. [laughter] But we're trying. We are trying to do it differently. We're trying to meet people where they are and see the reality of people's situations. And the reality is that if you're a woman or gender-expansive person and you want to take this chance, we offer a zero-interest either loan or a zero-interest grant that comes directly from Ada, or from our partner, Community Credit lab. And that's a zero-interest loan. We don't even check your credit. If you're in it with us, then we're going to get it in it with you.

+ +

And that zero-interest loan just gets recycled back to serve more people. So that zero-interest loan is while you're in class for that five and a half months, you're going to need still some money coming in. So we make sure you still have money coming in. The stipend hits when you get to internships, so from that 55,000, about 17 goes directly to the student for their stipend while they're interning.

+ +

Also, we give a childcare stipend. We're looking for a childcare partner out there because we really want to be able to make this more of a national program. But we're looking for that out there. But we give that stipend out to folks so they can pay for daycare or whatever they may need so they can actually come to the program.

+ +

We have a laptop program. You need a Mac to come to Ada. Everyone can't afford a Mac. We take donated Macs from companies that...companies sometimes give them a two-year life cycle for their Macs. So we can use it for another couple of years. So we take donations for Macs. And we also have a fund that we fund every year so people can buy a Mac.

+ +

And my favorite and I think one of the most needed things is we partner with BetterHelp and offer our students free therapy while they're in the classroom and while they're in their internship and a little bit after that as well. The free therapy was just...we're in a pandemic, and it's hit women hard. It's hit gender-expansive folks, parents, Brown folks, it's hit people hard. And so we're like, hey, why don't we, while you're in a pandemic, send you through the most rigorous part of your life? [laughs]

+ +

And so, making sure we were supporting people all around was really important to us. And it did nothing but create success for us. This did not make a deficit in our bottom line. This actually created more success for us. We saw when we did this; we got more people graduating. We get more people donating back. We get more people paying back their loans faster. So it just does nothing for the community but make it better and stronger. So we're going to continue to do it. It's going to continue to always be a part of who we are at Ada. But the wraparound services are key to the success.

+ +

CHAD: That's fantastic. So you mentioned you're expanding. Where is the original location?

+ +

ALEXANDRA: Seattle. We are a Seattle-based school.

+ +

CHAD: And you're expanding to Atlanta and DC you mentioned.

+ +

ALEXANDRA: Yeah. We first went digital because you know --

+ +

CHAD: That is what I was going to ask.

+ +

ALEXANDRA: [laughs]

+ +

CHAD: How have you dealt with the pandemic with a primarily in-person model previously? And then how has that affected your expansion plans?

+ +

ALEXANDRA: The pandemic was shitty and just horrible in so many ways. And out of a lot of shitty and horrible times, it creates a lot of innovation, and that's what it did. Our leadership team is a group of Brown parents. And they went to work immediately. We switched from being an in-person classroom where there's a lunch club, and a push-up club, and there are hugs everywhere and to being 100% online program in three days with systems. And companies were coming to us saying, "How are you creating community in this time?" So we did it very quickly. It taught us that we can educate people digitally.

+ +

So the first thing we decided to do is like we've got our digital cohort up and running. So still, I would say in quotes, "our Seattle cohort and digital cohort," but digital cohort basically means you're partnering with a company that is fully digital, and they are not attached to anything geographically. And that helped us expand to Atlanta because it helped us jump over the hurdle of like, oh, we have to go get a brick and mortar. We have to set up this brick and mortar. Instead, we just decided to educate people still digitally.

+ +

If you're in the Atlanta cohort, you're still having your education 100% online, and your internship is going to be in person with an Atlanta-based tech company. So you might be but and see [inaudible 24:11] in Atlanta later on, but we can educate you digitally. So we didn't have to slow this down.

+ +

We saw the need just like the amount of women that lost their jobs in the pandemic. We were completely energized by the fact that we can do this. We have people that believe in us. They're giving us money. They're funding this. We can do it. So we went for it. And Atlanta is the first campus. We already have staff there. We already have a campus director on point there.

+ +

And then, the next expansion will be to the DC area. And we're excited to do the same thing. It's educate them digitally because that's what we've been doing for the last few years, and we're good at it. And find but and see partnerships in DC because that's how we can really make sure we have good programming that we know they can do and then give them to the sponsoring companies to complete their programming with the internship.

+ +

CHAD: So where are the current limits of growth for you then?

+ +

ALEXANDRA: Current limits for growth, I mean, we've been such a Seattle-based place, and COVID pushed us into that national arena, so not a lot of people outside of our geography know who we are. Pacific Northwest was our sweet spot because people used to have to move to Seattle to be a part of Ada. So we got a lot of Californians. We got a lot of Oregons, Montana, Idaho, some Floridians because Florida knows about...we have a very huge population of Floridians. I don't know how they know, but they know.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: Our thing is, how do we get the Ada Developers Academy name and model out to the rest of the country? So they know that we are here, and we're an option for them if they want to become a software engineer.

+ +

CHAD: And right now, it sounds like you have your sights just set on the United States, not internationally.

+ +

ALEXANDRA: Not Internationally. I always joke about Ada at sea, but we'll see.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: Give me 10, 20 years to get that spun up. But I would just love to...[laughs] but yeah, over the next five years, there'll be five markets in Ada. By 2025, we're hoping to educate 10,000 women and gender-expansive people. We just graduated a class of 72 last Thursday. And we just admitted another class of 120 that starts in March. So we're chugging. But right now, it's Seattle, digital, Atlanta, DC. I imagine there'll be a Southern region, and then probably a Midwest region coming after that.

+ +

CHAD: So, and then you have the purely digital cohort too?

+ +

ALEXANDRA: Yep. And that's that sort of the sixth market, purely digital, which means there are so many companies that went fully remote and have no plan on coming back. And so that's just a market that we want to make sure that we're...we want people to opt into that. That's for some people who want to be fully remote forever. Some people are seeing that they need some sort of community while doing this work. And so they want to have a but and see internship. And there's every which way in between. So we'll figure it out as we move through this pandemic like the rest of the folks.

+ +

CHAD: You've shared some numbers there. And I think sometimes it's good to put that in context because people don't realize that 10,000, on one hand, sounds like a small number in the grand scheme of the United States. But actually, it's a very large number.

+ +

ALEXANDRA: It's huge.

+ +

CHAD: The U.S. only graduates around 65,000 CS graduates a year in the whole United States, so just to put that in context for people.

+ +

ALEXANDRA: Yeah, it's huge. I looked at the numbers for...I'm in Seattle, and I'll just say there's a college here, a large college here in Seattle, and they graduated 300 CS folks last year, and 20% of them were women. And we graduated in six months, 72 women and gender-expansive, and our focus is Brown folks, low socioeconomic folks. So you could just imagine underneath that umbrella of women, even under that, the diversity that you see. We're getting up there with some of our colleges, and we're doing this every six months.

+ +

And so it's a powerful model. It's the reason why I've been here for six years. It's the reason why I get really excited talking about this program. [laughs] I don't know if you can tell, but I get really excited talking about it. Because once people get in, they love being a part of our program, and they love being a partner with us. And it's a cool place to be. It just feels like a transformative place right now. And I think that we can really make a difference.

+ +

CHAD: Yeah, your excitement, and I'm a big believer in the opportunity. Your excitement is clear [laughs] when you're talking about it. How did you get into this work?

+ +

ALEXANDRA: I was in recruiting before. I did technical recruiting, contractor for a few different places. And I just saw the amount...and I came from a working-class. My family is from the Deep South in Louisiana. And the average income from the town I'm from is $26,000, and that was my reality.

+ +

And then, when I started technical recruiting, it was insane. The amount of wealth that was a part of this churn, the going to these colleges, early recruiting, paying people $6,000 a month, paying them a living stipend, making sure they had a plane ticket home, hot air balloons, tours of people's, you know, these millionaires houses. I was like, holy crap, this has to be more readily available.

+ +

And again, having two working-class black parents, they didn't even know what software development was. We didn't even know that was a possibility. My dad was like, "We're getting a computer," because he wanted to be on the forefront. And we got to that clear Mac that was like a purple color. We had that purple one.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: And my dad was like, "We've one." But still, there were kids in my school and in my college that had been around computers their whole lives; their schools had programming and things. So they just had that extra step. My opportunity to see in was recruiting. And after that, I was like, okay, where do I find the intersection of this and what I want to do, which is making sure that black folks have money? To be crude about it. [laughs] If we’re going to work and live in a capitalist society, then I want us to have some coins to play, and that is where I found Ada. And I love having this place.

+ +

I just get to be a part of this place where I just get to open doors or show people a door. They can open it themselves and go through, and just that's the amazing part of me, a part of this is watching people change their lives, buy their grandparents' homes, pay off their student debt, get a divorce, anything they want to do. [laughs] But to have the agency to do it in this world we live in, in the society we live in, and that's all I care about is that agency.

+ +

CHAD: Yeah, I was very privileged to be exposed to computers really early on and get to experience that spark of I love this. This is what I want to do. And I talk to so many people who just never had that opportunity to discover that that was even a thing that they could do, let alone love. It's just incredible when I meet someone who's like a plumber, and then they somehow get that exposure to computers or technology, and you see that spark go off for them. And it's amazing.

+ +

ALEXANDRA: It's so cool. It's one of my favorite...like; our admissions process is pretty rigorous. I think the average is like 15% or 20%, depending on the cohort admissions process. And to hear how obsessed these airline stewardesses or hairdressers or mothers are obsessed with coding, I'm like, yes, yes. Or these folks who are like...Oh, we had this woman who she was an immigrant from...she fled Israel, and she came to the U.S. And she's like, the only thing she knew about coding before she started was she had one time saw someone with two screens in a movie.

+ +

CHAD: [laughs]

+ +

ALEXANDRA: And she saw them on the computer, and she saw two screens. And then she started going through finding free stuff online. She found Ada. And this person's sitting in front of me talking about how geek they are about arrays and loops, and I'm like, yes, this is amazing. And to watch that person graduate less than a year later with just the salary that she got from Microsoft, and just the feeling that she felt when she got to call home and say, "Hey, I'm a software engineer now," I was like, all day, all day. That's like the gravy for this.

+ +

CHAD: It has nothing to do with aptitude. It has everything to do with opportunity.

+ +

ALEXANDRA: Oh my gosh. Yeah, opportunities. Yeah, it's everything here.

+ +

CHAD: Well, that's great. And Ada is providing folks with that opportunity. And I am so excited to hear about it and share it with our audience. Hopefully, students are listening and want to sign up but also those sponsoring companies too, right?

+ +

ALEXANDRA: Yeah, for sure. Sponsoring companies too. We love you too. You keep the wheels on this bus. So definitely give us a call.

+ +

CHAD: So if folks want to get in touch, where's the best place for them to do that?

+ +

ALEXANDRA: Our website that's the best place to start, adadevelopersacademy.org. And there there is stuff on corporate partnership. If you sign up on the partners' email list, it leads you right to my email. And then, for students, we have full admissions. Our admissions opens in March for the next Atlanta cohort. There are going to be 48 seats in Atlanta, 60 seats digitally, and 60 seats in Seattle. I would say get ready for that via our website.

+ +

CHAD: Awesome. You can subscribe to the show and find notes for this episode at giantrobots.fm along with all those links that Alexandra just mentioned and a transcript of the entire episode. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Alexandra Holien.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tC4a7Q6T + + ]]> + + Chad Pytel + Alexandra Holien + + + 409: Career Growth and Being a Mindful Dev with Dagna Bieda + https://podcast.thoughtbot.com/409 + 5cb659f3-849a-43fa-a480-da3568647a82 + Thu, 03 Feb 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Dagna Bieda is an engineer, career coach, and founder of theMindfulDev.com. She talks with Chad about being a software engineer first and then becoming a career coach who has helped a big range of clients with communication and marketing themselves successfully. + 34:10 + no + + + Dagna Bieda is an engineer, career coach, and founder of theMindfulDev.com. She talks with Chad about being a software engineer first and then becoming a career coach who has helped a big range of clients with communication and marketing themselves successfully. +theMindfulDev (https://www.themindfuldev.com/) +Follow Dagna on Twitter (https://twitter.com/dagnabieda) or LinkedIn (https://www.linkedin.com/in/dagnabieda/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dagna Bieda, engineer, career coach, and founder of theMindfulDev.com. Dagna, thanks for joining me. +DAGNA: Absolutely. It's a blast being here. So thanks for having me over, Chad. +CHAD: So what you do is a little bit unique in that you provide career coaching to engineers. But you yourself are an engineer and have a background in engineering. So how did you arrive at what you're doing today? +DAGNA: Yeah, you're exactly on point there. I was a software engineer and then turned into career coaching. So essentially, I've been coding for over ten years and coaching for the past 3. And I'm the tough love, “I've been in your shoes” kind of coach because I have that engineering experience. +And a little bit about what it is that I did as a software engineer is I essentially moved from programming in microcontrollers in C through cell phone towers, providing LTE networks in C++. I also did behaviors of social robots in C++. I wrote a distributed web app in Ruby on Rails. And I also wrote some mobile apps for parking and transit in Swift and Java. +Having that range of experience, I really get to help a big range of clients. My former clients have worked for LinkedIn, Amazon, Google, Disney, as well as much smaller businesses. And their own experience was ranging anywhere from 2 to 20 years of experience. And I had clients who are self-taught, who are career-changing bootcamp grads, who are college grads. And my goal as a coach is to really help them reach for their potential. +CHAD: Now, did you arrive at this because you yourself struggled with some of these things? Or did you have it easy and you said, "Oh, I don't understand why these other people..." [laughs] +DAGNA: So both of these questions are exactly on point. I feel like I had it very easy at the very beginning of my career. I essentially got promoted to a senior engineer very quickly. It took about two years or something, so like superfast. But then, as a senior engineer, there was a moment where I felt that I've just plateaued in my career, and I was stuck, and I was frustrated. And I wanted to learn all the technologies out there. And what was missing was some people skills. +So once I finally was able to figure out okay, this is what I'm missing...and in hindsight, it was so obvious. I decided to move into career coaching because I realized that we're kind of brainwashed, so to speak, to put the technology on a pedestal and ignore everything else, right? +CHAD: Yeah. +DAGNA: But if you don't work on your soft skills and don't realize that at the end, it's all humans because you're working with humans...you're creating products for humans. So it's not something you can really escape from. That was like a huge aha moment. I was like, people don't even know this is important. Like, I got to change that. [laughs] That was a mission for me to change that, to help discover what are those roadblocks? What are those limiting beliefs that software engineers often have that keep them stuck in their career and frustrated and stopping them from really fulfilling their potential? +CHAD: I often say that almost all problems are actually communication problems at their heart. +DAGNA: Ooh, yes. +CHAD: And in consulting, we have clients who come to us with what they think is a technical problem. And we have to sometimes tell them like, "We can fix this problem. But if you don't address the underlying communication problem that caused it in the first place, it's just going to happen again." +DAGNA: Absolutely, yeah. +CHAD: So I think that's a problem engineers have is that they try to apply technical problems or think code is the solution to every problem. +DAGNA: Well, it's not just that. Let's think about how software engineers are trained into their careers. If you have a class and you need to deliver a piece of code that compiles and does whatever it was meant to do for your assignment, even if you had incredible communications with your teammate and partner, even if you negotiated changes in the scope of features, it's all not going to matter for you passing your class if the code doesn't compile and if it doesn't do what it's supposed to do. +So early on, whenever we're creating software, we're taught how to create software. We're being taught to put technology on a pedestal. And I've worked with multiple senior engineers that feel really frustrated because they're so knowledgeable but aren't able to communicate all this knowledge that they have in their own mind. +They might be having brilliant ideas that might be helping their businesses grow and get past helping the businesses they work for grow. And they're not able to pitch those ideas and not able to really be heard and seen for the value that they bring to the table. And this is where I come in, and this is what I help with, getting past that frustration and that feeling of being stuck. +CHAD: And just to clarify if I'm following right, and what I'm advocating is this isn't just if you're a developer and want to move into management. This is for just moving up in your career as a developer, right? +DAGNA: Absolutely. Here's the thing, even if you're going to become the principal architect in the company, what are the skills that you need to have? It's not just technical expertise. If you have technical expertise and you're not able to talk about it with the business stakeholders that don't have the same amount of knowledge that you do, then you're not going to get to that point. Principal engineers create direction in the company, make decisions, have to be mindful about the business value that they're creating, not just the underlying tech stack. +So as we grow in our careers as software engineers, it is really critical to, once you have, I'd say, five years of experience as a software engineer, to start working on the soft skills. And to be honest, someone who has gone through a coding bootcamp because they had less of that brainwashing about putting the technology on the pedestal often tend to advance in their careers much faster because they bring that previous experience with them to the table, so they can communicate better. They have different types of ideas, different perceptions. They don't have those limiting beliefs that a lot of developers have. +The number one limiting belief that I see my clients have is believing that the work they do speaks for itself, and it doesn't unless someone literally dives into the code that you wrote. So for you to be able to advocate for your career, you need to be able to say, "Hey, I wrote this feature," and not expect people to dive into the code and look through the feature and all the lines of code you wrote. It’s to be able to emphasize the business impact that the feature you wrote had on the business, and how it helped, how you contributed to the business side. And that's something that I work with developers on. +Now, you did mention, Chad, that you work with a lot of developers, right? +CHAD: Mm-hmm. Yeah. +DAGNA: Would you say that marketing what developers do is a huge thing holding people back in their career? +CHAD: Yes, not only because of what I said earlier about a lot of the root causes of problems are around actual communication. But you're right; when it comes to who you can rely on in your company, who you can communicate with, who gets their ideas across more, it comes down to being able to communicate those ideas and that value. Even little things like when the code you've been working on is ready on staging, don't just say, "It's on staging. Check it out," and moving the ticket forward. +DAGNA: [laughs] +CHAD: But actually being able to communicate what you've done either through words or screenshots. I think we've all been in scenarios where you're working on a complicated ticket, and you are making decisions along the way about how to do that. And you make all those decisions, and they're the best decisions in the world. But if you just put that ticket up for a review and say, "It's on staging," it's either not going to be accepted, or you're going to get tons of questions around why you did this. What did you consider when you were doing this? It's like a lack of trust and understanding there. +But if instead, you say, "Here are all the things I'm considering along the way." And you say, "I've balanced all of these priorities, and here's the decision I've made, and it's on staging, and it works like this. And here's where you go to view it. And click on this. And here's a movie that shows how it works". People are going to be like, "Oh, sounds great. Accepted." +DAGNA: Yeah, absolutely. But here's the thing. As developers, we're not taught to do all these things that you just described. We're taught to write code that compiles, boom, done. [laughs] +CHAD: So when working with people who have this sort of mindset o the skill gap, what are some things that you have people do to level up? +DAGNA: Yeah, there are certain things that we specifically work on, and that is negotiation, setting expectations and boundaries, being able to respectfully either decline a change in scope of work or try to negotiate the change of a deadline whenever there's an impossible feature request. Or things like being able to set expectations that if you're working on your focus time, that you shouldn't be disrupted. +And it's something that's very hard because developers usually really want to be helpful. So when a product manager comes to them and says, "Hey, I really need this. It's for a critical client," what happens is most often than not, they're going to drop everything they were doing just to finish that one thing and be helpful. And so being able to create a boundary saying, "Hey, I'll get back to you after I'm done working on what it is that I'm working," is a skill. +Being able to market what you did and being able to show the business value, how your work contributed to the business side is also a skill. And even having communication with your manager telling them, "Hey, I realize that I need to work on XYZ. Would you be willing to give me feedback? Because we go to the meetings together, you see how I communicate; you see how I think, you see how I act. Give me more feedback. What can I do to grow in my career?" So asking for that feedback is a skill. So there are a lot of moving elements, and these are the skills that I work with on my clients. +But there's a big thing that I want to address here too is that with technology changing and being at such a fast pace, it is very important to give yourself grace, especially when you're starting out. Be patient with yourself to give yourself that time to actually master the tech part. And it's really important to see and understand how you think about your career growth. Do you beat yourself up in your mind, or do you actually see the opportunities for growth? +With developers, since we're not being taught how to communicate effectively with other people, oftentimes, when someone wants to give us feedback that might help us in our career, we get defensive because it feels like an attack on our character. And I see it with juniors all the time. "Why did you say I was messy?" "No, no, I said your code was messy." Taking that kind of feedback on the code very personal and getting agitated instead of seeing opportunity for growth in the career. +CHAD: Would you say that most of the people that work with you are doing it while they're going through a transition or in between looking for their next thing? Or are they doing it while they're in a position hoping to improve within that existing company? +DAGNA: So all three paths that you mentioned are very valid. It depends on what people are doing, what their goals are. When I work with my clients, we work one on one. So it's very tailored to their specific and unique situation and their needs. But I can tell you that from last year, my absolute best example was one client who came to me because he felt that he was being an undervalued senior engineer. +And he wanted to promote himself and maybe move on from the job that he was in at the time that he didn't see much opportunity for growth. And he was just stagnant. "Help me market myself. I need to get out of this current situation. I know I have the potential. And I want to find something more exciting to work on." As we worked together, within three and a half months, he became a startup CTO, which was a dream come true for him. But he didn't believe at the time before we worked together that he could actually make that happen for himself. +Then I had another client who, within two months of us working together, was preparing to land a team lead position. But he actually was able to jump two levels up, and he became a VP of innovation at his own company. +CHAD: Cool. +DAGNA: It so happened that as we worked together, his company was going through a massive spurt of growth. And because he was the right person working on the right skills at the right time, he became the VP which is incredible. +And I had another client just recently who felt that he was overworking himself. He was coming also from a military background. So he had certain beliefs that they served him in the military, but they were not really helpful for progressing in the tech industry. And as we worked together, he was able to not only stop overworking himself and have a better relationship with his wife; he also landed a new job where he doubled his salary. He went from 109,000 a year to 220,000. That actually made even my jaw drop a little. [laughter] +But it shows you how powerful the process is that I follow with my clients. It's really about the engineering mindset. It's about how to think about career growth and how to prioritize certain things depending on which stage of your career you're in. +CHAD: Are there other common pitfalls or mistakes that developers make that hold them back? +DAGNA: So absolutely the limiting belief that I mentioned earlier, believing that your work speaks for itself. I feel like 80% of people that I work with have that limiting belief, and we work to get past that. +Another thing that is pretty common is not understanding how you come across. That's a problem that I had in my career. When I mentioned that I was a senior engineer for a few years and I felt stuck, I wanted to advance, but it wasn't happening for me. It wasn't clear why it wasn't happening until I started working with someone who was open enough to provide me some tough love type of feedback. One time he told me, "Dagna, why are you calling these people idiots?" And I'm like, "I never said that." +CHAD: [chuckles] +DAGNA: My intention was really pure, good, coming from my heart and my soul, from really good intentions. But my intentions were completely different from the message that got across, right? +CHAD: Was it your tone, what you were saying? What was it that made that come across? +DAGNA: Part of it is not being assertive enough. And I should probably mention here that I am an immigrant to the United States. I originally grew up and got educated back in Poland, my home country. And the way we communicate in Poland is completely different than how we communicate here in the United States. And at the very beginning, I didn't really understand how my communication impacts my career. +So essentially, as a senior engineer, I was way too direct. And I was using words that were triggering for some people. So I had to learn how to be more assertive, how to communicate to people that I get where they're coming from, what is their perspective, what it is that they're trying to accomplish in the conversation. Once I started doing that, I actually got the offer to get promoted to the engineering manager that I was working towards. +But the funny thing is that was the day that I actually came into the office and put my notice in because I was so sad of being a coach by then. I was like; I figured this communication thing out. I need to spread the word. +CHAD: [laughs] +DAGNA: It's way too important for me to now be a manager, nah, nah, nah. I have more lives to impact here than just the team that I might be working with. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: That's great. And it segues really nicely into the next question I was going to ask you, which is your experience with the cultural differences. There's a general trend in the market that we're seeing now in more companies hiring remotely, opening up the candidate pool to people who live all over the place. And not only does that expose more people to be hired by different companies, but it broadens the candidate pool. So you're competing against even more people. So is that something that you're seeing as well? And how do people position themselves within the global market now, particularly if they're not in the U.S.? +DAGNA: Well, if we're talking about global market, we got to be mindful that for a company that's located in the United States or any other country for that matter, there are tax implications. So it really depends on the company and how they are set up to be able to pay out salaries offshore or hire contractors offshore. Because the reality is that a lot of clients of mine that are from the European Union, for example, a lot of clients of mine that are in the EU, if they wanted to apply for companies in the United States, they wouldn't really be considered because of those tax implications. +So even though a lot of companies open up and want to hire people from abroad, not every company does that. And even if companies say that they are open for remote workers, it really depends on how they're paying their taxes and how all that is set up. So the way I see it is there is a movement towards opening up for remote work. But it's definitely not about competing across the globe, not yet at least. +CHAD: I think maybe my perspective is a little bit skewed on it just because of where we're at. So are you saying that developers should do their due diligence about what companies they actually want to work for? +DAGNA: Absolutely, yeah. I mean, applying for a company that is not set up in a way that can support paying salaries outside or even having those international agreements in place, you're just wasting your time applying there and setting yourself up for frustration because they're not going to reach back to you. +CHAD: Yeah, that's good advice. +DAGNA: Now, in terms of your work with remote positions, who do you usually work with, Chad? +CHAD: Are you asking from developers that we typically work with or who do we -- +DAGNA: Yes. I was curious, like, what's the amount of people that you work with that are actually remote and worldwide? What is your experience there? +CHAD: So last year at thoughtbot, we got rid of all of our offices, and we went fully remote. And when we did that, it took us a little while to get everything organized. But when we did, our goal was to open it up based on time zone, not based on country that you live in. And so we organized into two teams, all of the Americas and Europe, Middle East and Africa is the second team. +DAGNA: So I'm curious, what are the tax implications of you guys paying out those salaries? +CHAD: So we use a company called remote.com along with a few other partners that provide employer record in the country that you live in. So there's an actual entity. You're fully paid according to local rules with actual salary benefits, paid time off, all that stuff. And you are a real employee of that entity in that country. And then what they do is they invoice us for that total amount. +DAGNA: Ah, that's awesome. +CHAD: And they handle all the local employment, which is great because up until that point, we previously had to have entities of our own in every country in order to do it right because we really want to do it right. We're not that big, and so it's a lot of overhead for us to be able to do that. So working with partner companies, companies that provide that local entity is the direction we've gone in, and it's worked really well overall. +DAGNA: Awesome. Glad to hear that. +CHAD: And I think in general, I'm trying to spread the word about that because I do think it is important. There are a lot of companies out there. This is building on what you said before. There are a lot of companies out there that are, on one hand, doing things incorrectly or, on the other, they might not have good intentions; they're sort of purposely taking advantage by having people work as contractors when they probably really shouldn't be. +DAGNA: Oh yeah, I hear you. +CHAD: I'm curious, in your role now, do you still code at all? +DAGNA: So I gave up coding for now. I essentially left my last engineering job in March of last year, and I've been fully focused on coaching. Coaching as it is is a skill as well. And I realized that if I really want to make an impact, I have to have my attention fully devoted to that business. And part of it too is business growth. +A skill that I'm learning right now is writing, writing a newsletter, writing posts on social media, and just sharing what I think is very important and what is not really being talked about enough like the communication, like the human side of software, like career growth, and the fact that we are set up to overvalue the technical skillset in terms of career growth. And all this really takes up my time and my effort. +CHAD: One of the things that resonated with me when I looked at your website was this idea of being clear on your personal definition of fulfillment. Fulfillment is one of the things we talk a lot about at thoughtbot. It's one of our core values. And so, how has it been for you to transition away from coding? And do you think you're going to be fulfilled by that over the long term? +DAGNA: Oh, absolutely, yeah. It's been a blast. Here's the thing, as I help my clients achieve spectacular results, that's what really puts me on fire. And I wake up every day thinking, damn, I can help people in very critical moments in their life. +I had a client who, as we were coaching together, unfortunately, his father passed away. And he told me that thanks to the coaching that we did together and the mindset training that we did, he was able to cope with this difficult situation in his life so much better, not to mention how that impacted his career. +So I get to really help, really have a huge impact on people's lives, and that's something that really is incredible for me. That is my personal definition of fulfillment. And I like to say that I used to be programming, and now I'm re-programming human minds. +CHAD: So this idea of personal definition of fulfillment, first, why is it important to be clear on that? +DAGNA: It affects your energy levels, your motivation. If you're working in a place that might be giving you an incredible benefits package, but every day you wake up, and you just don't want to go to work, that is something that I like to call golden handcuffs because you're essentially in hell, in prison. And it feels horrible to be in a situation like that. And I have experienced it myself where I felt like I have so much potential within me. Why am I wasting my time here? Even though the money was great, the benefits were good, but I knew I had so much more within me. +And figuring out the personal definition of fulfillment is really what helped me open my eyes that; hey, my job was great, but it wasn't something that I really wanted to do. It's kind of like being in a relationship that just doesn't work, but you're in it just because. [laughs] Isn't it so much better to work in a place that is meaningful to you, that supports your values, that fits your desired lifestyle, someplace that every day that you wake up, you're really excited about going to work? Isn't that a much better way to live? +CHAD: Yeah. What if someone finds themselves understanding that these are the skills that they should have to be a really great developer and advance in their career and maybe even making progress on that? Are there other things...you used the term earlier about marketing yourself. Does that mean having a great personal website? What does it mean when you say that? +DAGNA: Well, I really mean being able to talk about your accomplishments, depending on which stakeholders you're talking to. So if you're trying to pitch an idea to your product manager, then talking at the product manager level, being able to show how what you do or the idea that you have contributes to the business. If you're in an interview setting, how to discuss what you have accomplished with the people that might want to potentially hire you. +It also is related to having your LinkedIn in a way that attracts attention and brings people in that you actually wanted to work with. I've had some people come to me and say, "You know what? I get seven; eight offers every single day on LinkedIn." And I'm like, that's great. But are these the offers that you actually want to work on? Is it something that you actually want to pursue, or you just want to keep getting those notifications?" +And oftentimes, whenever we have our LinkedIn profiles set up, what happens is we put the keywords there. I know this tech stack; I know this framework. I've worked with this language, blah, blah, blah. And what's missing is who you are as a person, what you value. What do you expect from a workplace? What kind of change do you want to make in the world? What is really important to you? What are your expectations? +And I think that the pandemic, in a way, showed that, that as we got to work from home, we got to re-evaluate what is really important in our lives. Back when you used to go to the office, you would have that disconnect between the work and the life. And you could strive for some work-life balance but keep them kind of separate. +Now, with everything being super entangled, it kind of forces you to reevaluate okay, what is really important for me? Is it important for me to eat breakfast with my kids and drop them off at school, and pushing that meeting to a little bit later during the day? Or is it important to me to clock out after 6:00 so I can be with my kids after they get back from school? Or do I really care about maybe doing all my work after 6:00 p.m. because that's when my brain lights on fire? Have you found yourself going back to re-thinking what is important in life after the remote work started? +CHAD: [laughs] Well, yes, and no. Yes, but I also have made a habit of doing that. +DAGNA: Oh, perfect. +CHAD: As a result, I often dramatically either change my schedule or my focus or something about every two years. And that has been critical to me to be able to do this for so long. I haven't really worked...I've been doing this for more than 18 years now, but I haven't really worked in the same job more than two or three years. Even though it might be the same title, the job has dramatically changed. And that's through my own personal initiative of realizing what I need to do to be fulfilled now. And I'm fortunately in a position where I can make those changes happen. +DAGNA: That's great. But I kind of want to share that I believe everybody's in a position to actually do that. +CHAD: Yeah, I agree. +DAGNA: Especially in engineering. There are so many opportunities for growth. It's kind of ridiculous. You can be an embedded engineer and become a front-end engineer. You can go into the backend, and then you can do DevOps, and then you can become an engineering manager. And then you can go back to being an individual contributor if you wanted to. +I mean, you could just move up, down, left, right, check things out, see what's fun, what's not, change industries. So there's just so much opportunity for growth. And I think it's also very human wanting to grow, wanting to learn more, trying to kind of push the boundaries and check what's out there outside of your comfort zone. I think that's very human. +CHAD: Yeah. Well, if people want to get in touch with you or find out more, where are the best places for them to do that? +DAGNA: The absolute best place is going to my website, theMindfulDev.com/podcast. And that link will actually redirect you to a case study of a client of mine that explains how I work with clients. So if you're interested for us to get to work together, you can just go there and watch the case study video, and let's go from there. +CHAD: Awesome. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Dagna Bieda. + + + Dagna Bieda is an engineer, career coach, and founder of theMindfulDev.com. She talks with Chad about being a software engineer first and then becoming a career coach who has helped a big range of clients with communication and marketing themselves successfully.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dagna Bieda, engineer, career coach, and founder of theMindfulDev.com. Dagna, thanks for joining me.

+ +

DAGNA: Absolutely. It's a blast being here. So thanks for having me over, Chad.

+ +

CHAD: So what you do is a little bit unique in that you provide career coaching to engineers. But you yourself are an engineer and have a background in engineering. So how did you arrive at what you're doing today?

+ +

DAGNA: Yeah, you're exactly on point there. I was a software engineer and then turned into career coaching. So essentially, I've been coding for over ten years and coaching for the past 3. And I'm the tough love, “I've been in your shoes” kind of coach because I have that engineering experience.

+ +

And a little bit about what it is that I did as a software engineer is I essentially moved from programming in microcontrollers in C through cell phone towers, providing LTE networks in C++. I also did behaviors of social robots in C++. I wrote a distributed web app in Ruby on Rails. And I also wrote some mobile apps for parking and transit in Swift and Java.

+ +

Having that range of experience, I really get to help a big range of clients. My former clients have worked for LinkedIn, Amazon, Google, Disney, as well as much smaller businesses. And their own experience was ranging anywhere from 2 to 20 years of experience. And I had clients who are self-taught, who are career-changing bootcamp grads, who are college grads. And my goal as a coach is to really help them reach for their potential.

+ +

CHAD: Now, did you arrive at this because you yourself struggled with some of these things? Or did you have it easy and you said, "Oh, I don't understand why these other people..." [laughs]

+ +

DAGNA: So both of these questions are exactly on point. I feel like I had it very easy at the very beginning of my career. I essentially got promoted to a senior engineer very quickly. It took about two years or something, so like superfast. But then, as a senior engineer, there was a moment where I felt that I've just plateaued in my career, and I was stuck, and I was frustrated. And I wanted to learn all the technologies out there. And what was missing was some people skills.

+ +

So once I finally was able to figure out okay, this is what I'm missing...and in hindsight, it was so obvious. I decided to move into career coaching because I realized that we're kind of brainwashed, so to speak, to put the technology on a pedestal and ignore everything else, right?

+ +

CHAD: Yeah.

+ +

DAGNA: But if you don't work on your soft skills and don't realize that at the end, it's all humans because you're working with humans...you're creating products for humans. So it's not something you can really escape from. That was like a huge aha moment. I was like, people don't even know this is important. Like, I got to change that. [laughs] That was a mission for me to change that, to help discover what are those roadblocks? What are those limiting beliefs that software engineers often have that keep them stuck in their career and frustrated and stopping them from really fulfilling their potential?

+ +

CHAD: I often say that almost all problems are actually communication problems at their heart.

+ +

DAGNA: Ooh, yes.

+ +

CHAD: And in consulting, we have clients who come to us with what they think is a technical problem. And we have to sometimes tell them like, "We can fix this problem. But if you don't address the underlying communication problem that caused it in the first place, it's just going to happen again."

+ +

DAGNA: Absolutely, yeah.

+ +

CHAD: So I think that's a problem engineers have is that they try to apply technical problems or think code is the solution to every problem.

+ +

DAGNA: Well, it's not just that. Let's think about how software engineers are trained into their careers. If you have a class and you need to deliver a piece of code that compiles and does whatever it was meant to do for your assignment, even if you had incredible communications with your teammate and partner, even if you negotiated changes in the scope of features, it's all not going to matter for you passing your class if the code doesn't compile and if it doesn't do what it's supposed to do.

+ +

So early on, whenever we're creating software, we're taught how to create software. We're being taught to put technology on a pedestal. And I've worked with multiple senior engineers that feel really frustrated because they're so knowledgeable but aren't able to communicate all this knowledge that they have in their own mind.

+ +

They might be having brilliant ideas that might be helping their businesses grow and get past helping the businesses they work for grow. And they're not able to pitch those ideas and not able to really be heard and seen for the value that they bring to the table. And this is where I come in, and this is what I help with, getting past that frustration and that feeling of being stuck.

+ +

CHAD: And just to clarify if I'm following right, and what I'm advocating is this isn't just if you're a developer and want to move into management. This is for just moving up in your career as a developer, right?

+ +

DAGNA: Absolutely. Here's the thing, even if you're going to become the principal architect in the company, what are the skills that you need to have? It's not just technical expertise. If you have technical expertise and you're not able to talk about it with the business stakeholders that don't have the same amount of knowledge that you do, then you're not going to get to that point. Principal engineers create direction in the company, make decisions, have to be mindful about the business value that they're creating, not just the underlying tech stack.

+ +

So as we grow in our careers as software engineers, it is really critical to, once you have, I'd say, five years of experience as a software engineer, to start working on the soft skills. And to be honest, someone who has gone through a coding bootcamp because they had less of that brainwashing about putting the technology on the pedestal often tend to advance in their careers much faster because they bring that previous experience with them to the table, so they can communicate better. They have different types of ideas, different perceptions. They don't have those limiting beliefs that a lot of developers have.

+ +

The number one limiting belief that I see my clients have is believing that the work they do speaks for itself, and it doesn't unless someone literally dives into the code that you wrote. So for you to be able to advocate for your career, you need to be able to say, "Hey, I wrote this feature," and not expect people to dive into the code and look through the feature and all the lines of code you wrote. It’s to be able to emphasize the business impact that the feature you wrote had on the business, and how it helped, how you contributed to the business side. And that's something that I work with developers on.

+ +

Now, you did mention, Chad, that you work with a lot of developers, right?

+ +

CHAD: Mm-hmm. Yeah.

+ +

DAGNA: Would you say that marketing what developers do is a huge thing holding people back in their career?

+ +

CHAD: Yes, not only because of what I said earlier about a lot of the root causes of problems are around actual communication. But you're right; when it comes to who you can rely on in your company, who you can communicate with, who gets their ideas across more, it comes down to being able to communicate those ideas and that value. Even little things like when the code you've been working on is ready on staging, don't just say, "It's on staging. Check it out," and moving the ticket forward.

+ +

DAGNA: [laughs]

+ +

CHAD: But actually being able to communicate what you've done either through words or screenshots. I think we've all been in scenarios where you're working on a complicated ticket, and you are making decisions along the way about how to do that. And you make all those decisions, and they're the best decisions in the world. But if you just put that ticket up for a review and say, "It's on staging," it's either not going to be accepted, or you're going to get tons of questions around why you did this. What did you consider when you were doing this? It's like a lack of trust and understanding there.

+ +

But if instead, you say, "Here are all the things I'm considering along the way." And you say, "I've balanced all of these priorities, and here's the decision I've made, and it's on staging, and it works like this. And here's where you go to view it. And click on this. And here's a movie that shows how it works". People are going to be like, "Oh, sounds great. Accepted."

+ +

DAGNA: Yeah, absolutely. But here's the thing. As developers, we're not taught to do all these things that you just described. We're taught to write code that compiles, boom, done. [laughs]

+ +

CHAD: So when working with people who have this sort of mindset o the skill gap, what are some things that you have people do to level up?

+ +

DAGNA: Yeah, there are certain things that we specifically work on, and that is negotiation, setting expectations and boundaries, being able to respectfully either decline a change in scope of work or try to negotiate the change of a deadline whenever there's an impossible feature request. Or things like being able to set expectations that if you're working on your focus time, that you shouldn't be disrupted.

+ +

And it's something that's very hard because developers usually really want to be helpful. So when a product manager comes to them and says, "Hey, I really need this. It's for a critical client," what happens is most often than not, they're going to drop everything they were doing just to finish that one thing and be helpful. And so being able to create a boundary saying, "Hey, I'll get back to you after I'm done working on what it is that I'm working," is a skill.

+ +

Being able to market what you did and being able to show the business value, how your work contributed to the business side is also a skill. And even having communication with your manager telling them, "Hey, I realize that I need to work on XYZ. Would you be willing to give me feedback? Because we go to the meetings together, you see how I communicate; you see how I think, you see how I act. Give me more feedback. What can I do to grow in my career?" So asking for that feedback is a skill. So there are a lot of moving elements, and these are the skills that I work with on my clients.

+ +

But there's a big thing that I want to address here too is that with technology changing and being at such a fast pace, it is very important to give yourself grace, especially when you're starting out. Be patient with yourself to give yourself that time to actually master the tech part. And it's really important to see and understand how you think about your career growth. Do you beat yourself up in your mind, or do you actually see the opportunities for growth?

+ +

With developers, since we're not being taught how to communicate effectively with other people, oftentimes, when someone wants to give us feedback that might help us in our career, we get defensive because it feels like an attack on our character. And I see it with juniors all the time. "Why did you say I was messy?" "No, no, I said your code was messy." Taking that kind of feedback on the code very personal and getting agitated instead of seeing opportunity for growth in the career.

+ +

CHAD: Would you say that most of the people that work with you are doing it while they're going through a transition or in between looking for their next thing? Or are they doing it while they're in a position hoping to improve within that existing company?

+ +

DAGNA: So all three paths that you mentioned are very valid. It depends on what people are doing, what their goals are. When I work with my clients, we work one on one. So it's very tailored to their specific and unique situation and their needs. But I can tell you that from last year, my absolute best example was one client who came to me because he felt that he was being an undervalued senior engineer.

+ +

And he wanted to promote himself and maybe move on from the job that he was in at the time that he didn't see much opportunity for growth. And he was just stagnant. "Help me market myself. I need to get out of this current situation. I know I have the potential. And I want to find something more exciting to work on." As we worked together, within three and a half months, he became a startup CTO, which was a dream come true for him. But he didn't believe at the time before we worked together that he could actually make that happen for himself.

+ +

Then I had another client who, within two months of us working together, was preparing to land a team lead position. But he actually was able to jump two levels up, and he became a VP of innovation at his own company.

+ +

CHAD: Cool.

+ +

DAGNA: It so happened that as we worked together, his company was going through a massive spurt of growth. And because he was the right person working on the right skills at the right time, he became the VP which is incredible.

+ +

And I had another client just recently who felt that he was overworking himself. He was coming also from a military background. So he had certain beliefs that they served him in the military, but they were not really helpful for progressing in the tech industry. And as we worked together, he was able to not only stop overworking himself and have a better relationship with his wife; he also landed a new job where he doubled his salary. He went from 109,000 a year to 220,000. That actually made even my jaw drop a little. [laughter]

+ +

But it shows you how powerful the process is that I follow with my clients. It's really about the engineering mindset. It's about how to think about career growth and how to prioritize certain things depending on which stage of your career you're in.

+ +

CHAD: Are there other common pitfalls or mistakes that developers make that hold them back?

+ +

DAGNA: So absolutely the limiting belief that I mentioned earlier, believing that your work speaks for itself. I feel like 80% of people that I work with have that limiting belief, and we work to get past that.

+ +

Another thing that is pretty common is not understanding how you come across. That's a problem that I had in my career. When I mentioned that I was a senior engineer for a few years and I felt stuck, I wanted to advance, but it wasn't happening for me. It wasn't clear why it wasn't happening until I started working with someone who was open enough to provide me some tough love type of feedback. One time he told me, "Dagna, why are you calling these people idiots?" And I'm like, "I never said that."

+ +

CHAD: [chuckles]

+ +

DAGNA: My intention was really pure, good, coming from my heart and my soul, from really good intentions. But my intentions were completely different from the message that got across, right?

+ +

CHAD: Was it your tone, what you were saying? What was it that made that come across?

+ +

DAGNA: Part of it is not being assertive enough. And I should probably mention here that I am an immigrant to the United States. I originally grew up and got educated back in Poland, my home country. And the way we communicate in Poland is completely different than how we communicate here in the United States. And at the very beginning, I didn't really understand how my communication impacts my career.

+ +

So essentially, as a senior engineer, I was way too direct. And I was using words that were triggering for some people. So I had to learn how to be more assertive, how to communicate to people that I get where they're coming from, what is their perspective, what it is that they're trying to accomplish in the conversation. Once I started doing that, I actually got the offer to get promoted to the engineering manager that I was working towards.

+ +

But the funny thing is that was the day that I actually came into the office and put my notice in because I was so sad of being a coach by then. I was like; I figured this communication thing out. I need to spread the word.

+ +

CHAD: [laughs]

+ +

DAGNA: It's way too important for me to now be a manager, nah, nah, nah. I have more lives to impact here than just the team that I might be working with.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: That's great. And it segues really nicely into the next question I was going to ask you, which is your experience with the cultural differences. There's a general trend in the market that we're seeing now in more companies hiring remotely, opening up the candidate pool to people who live all over the place. And not only does that expose more people to be hired by different companies, but it broadens the candidate pool. So you're competing against even more people. So is that something that you're seeing as well? And how do people position themselves within the global market now, particularly if they're not in the U.S.?

+ +

DAGNA: Well, if we're talking about global market, we got to be mindful that for a company that's located in the United States or any other country for that matter, there are tax implications. So it really depends on the company and how they are set up to be able to pay out salaries offshore or hire contractors offshore. Because the reality is that a lot of clients of mine that are from the European Union, for example, a lot of clients of mine that are in the EU, if they wanted to apply for companies in the United States, they wouldn't really be considered because of those tax implications.

+ +

So even though a lot of companies open up and want to hire people from abroad, not every company does that. And even if companies say that they are open for remote workers, it really depends on how they're paying their taxes and how all that is set up. So the way I see it is there is a movement towards opening up for remote work. But it's definitely not about competing across the globe, not yet at least.

+ +

CHAD: I think maybe my perspective is a little bit skewed on it just because of where we're at. So are you saying that developers should do their due diligence about what companies they actually want to work for?

+ +

DAGNA: Absolutely, yeah. I mean, applying for a company that is not set up in a way that can support paying salaries outside or even having those international agreements in place, you're just wasting your time applying there and setting yourself up for frustration because they're not going to reach back to you.

+ +

CHAD: Yeah, that's good advice.

+ +

DAGNA: Now, in terms of your work with remote positions, who do you usually work with, Chad?

+ +

CHAD: Are you asking from developers that we typically work with or who do we --

+ +

DAGNA: Yes. I was curious, like, what's the amount of people that you work with that are actually remote and worldwide? What is your experience there?

+ +

CHAD: So last year at thoughtbot, we got rid of all of our offices, and we went fully remote. And when we did that, it took us a little while to get everything organized. But when we did, our goal was to open it up based on time zone, not based on country that you live in. And so we organized into two teams, all of the Americas and Europe, Middle East and Africa is the second team.

+ +

DAGNA: So I'm curious, what are the tax implications of you guys paying out those salaries?

+ +

CHAD: So we use a company called remote.com along with a few other partners that provide employer record in the country that you live in. So there's an actual entity. You're fully paid according to local rules with actual salary benefits, paid time off, all that stuff. And you are a real employee of that entity in that country. And then what they do is they invoice us for that total amount.

+ +

DAGNA: Ah, that's awesome.

+ +

CHAD: And they handle all the local employment, which is great because up until that point, we previously had to have entities of our own in every country in order to do it right because we really want to do it right. We're not that big, and so it's a lot of overhead for us to be able to do that. So working with partner companies, companies that provide that local entity is the direction we've gone in, and it's worked really well overall.

+ +

DAGNA: Awesome. Glad to hear that.

+ +

CHAD: And I think in general, I'm trying to spread the word about that because I do think it is important. There are a lot of companies out there. This is building on what you said before. There are a lot of companies out there that are, on one hand, doing things incorrectly or, on the other, they might not have good intentions; they're sort of purposely taking advantage by having people work as contractors when they probably really shouldn't be.

+ +

DAGNA: Oh yeah, I hear you.

+ +

CHAD: I'm curious, in your role now, do you still code at all?

+ +

DAGNA: So I gave up coding for now. I essentially left my last engineering job in March of last year, and I've been fully focused on coaching. Coaching as it is is a skill as well. And I realized that if I really want to make an impact, I have to have my attention fully devoted to that business. And part of it too is business growth.

+ +

A skill that I'm learning right now is writing, writing a newsletter, writing posts on social media, and just sharing what I think is very important and what is not really being talked about enough like the communication, like the human side of software, like career growth, and the fact that we are set up to overvalue the technical skillset in terms of career growth. And all this really takes up my time and my effort.

+ +

CHAD: One of the things that resonated with me when I looked at your website was this idea of being clear on your personal definition of fulfillment. Fulfillment is one of the things we talk a lot about at thoughtbot. It's one of our core values. And so, how has it been for you to transition away from coding? And do you think you're going to be fulfilled by that over the long term?

+ +

DAGNA: Oh, absolutely, yeah. It's been a blast. Here's the thing, as I help my clients achieve spectacular results, that's what really puts me on fire. And I wake up every day thinking, damn, I can help people in very critical moments in their life.

+ +

I had a client who, as we were coaching together, unfortunately, his father passed away. And he told me that thanks to the coaching that we did together and the mindset training that we did, he was able to cope with this difficult situation in his life so much better, not to mention how that impacted his career.

+ +

So I get to really help, really have a huge impact on people's lives, and that's something that really is incredible for me. That is my personal definition of fulfillment. And I like to say that I used to be programming, and now I'm re-programming human minds.

+ +

CHAD: So this idea of personal definition of fulfillment, first, why is it important to be clear on that?

+ +

DAGNA: It affects your energy levels, your motivation. If you're working in a place that might be giving you an incredible benefits package, but every day you wake up, and you just don't want to go to work, that is something that I like to call golden handcuffs because you're essentially in hell, in prison. And it feels horrible to be in a situation like that. And I have experienced it myself where I felt like I have so much potential within me. Why am I wasting my time here? Even though the money was great, the benefits were good, but I knew I had so much more within me.

+ +

And figuring out the personal definition of fulfillment is really what helped me open my eyes that; hey, my job was great, but it wasn't something that I really wanted to do. It's kind of like being in a relationship that just doesn't work, but you're in it just because. [laughs] Isn't it so much better to work in a place that is meaningful to you, that supports your values, that fits your desired lifestyle, someplace that every day that you wake up, you're really excited about going to work? Isn't that a much better way to live?

+ +

CHAD: Yeah. What if someone finds themselves understanding that these are the skills that they should have to be a really great developer and advance in their career and maybe even making progress on that? Are there other things...you used the term earlier about marketing yourself. Does that mean having a great personal website? What does it mean when you say that?

+ +

DAGNA: Well, I really mean being able to talk about your accomplishments, depending on which stakeholders you're talking to. So if you're trying to pitch an idea to your product manager, then talking at the product manager level, being able to show how what you do or the idea that you have contributes to the business. If you're in an interview setting, how to discuss what you have accomplished with the people that might want to potentially hire you.

+ +

It also is related to having your LinkedIn in a way that attracts attention and brings people in that you actually wanted to work with. I've had some people come to me and say, "You know what? I get seven; eight offers every single day on LinkedIn." And I'm like, that's great. But are these the offers that you actually want to work on? Is it something that you actually want to pursue, or you just want to keep getting those notifications?"

+ +

And oftentimes, whenever we have our LinkedIn profiles set up, what happens is we put the keywords there. I know this tech stack; I know this framework. I've worked with this language, blah, blah, blah. And what's missing is who you are as a person, what you value. What do you expect from a workplace? What kind of change do you want to make in the world? What is really important to you? What are your expectations?

+ +

And I think that the pandemic, in a way, showed that, that as we got to work from home, we got to re-evaluate what is really important in our lives. Back when you used to go to the office, you would have that disconnect between the work and the life. And you could strive for some work-life balance but keep them kind of separate.

+ +

Now, with everything being super entangled, it kind of forces you to reevaluate okay, what is really important for me? Is it important for me to eat breakfast with my kids and drop them off at school, and pushing that meeting to a little bit later during the day? Or is it important to me to clock out after 6:00 so I can be with my kids after they get back from school? Or do I really care about maybe doing all my work after 6:00 p.m. because that's when my brain lights on fire? Have you found yourself going back to re-thinking what is important in life after the remote work started?

+ +

CHAD: [laughs] Well, yes, and no. Yes, but I also have made a habit of doing that.

+ +

DAGNA: Oh, perfect.

+ +

CHAD: As a result, I often dramatically either change my schedule or my focus or something about every two years. And that has been critical to me to be able to do this for so long. I haven't really worked...I've been doing this for more than 18 years now, but I haven't really worked in the same job more than two or three years. Even though it might be the same title, the job has dramatically changed. And that's through my own personal initiative of realizing what I need to do to be fulfilled now. And I'm fortunately in a position where I can make those changes happen.

+ +

DAGNA: That's great. But I kind of want to share that I believe everybody's in a position to actually do that.

+ +

CHAD: Yeah, I agree.

+ +

DAGNA: Especially in engineering. There are so many opportunities for growth. It's kind of ridiculous. You can be an embedded engineer and become a front-end engineer. You can go into the backend, and then you can do DevOps, and then you can become an engineering manager. And then you can go back to being an individual contributor if you wanted to.

+ +

I mean, you could just move up, down, left, right, check things out, see what's fun, what's not, change industries. So there's just so much opportunity for growth. And I think it's also very human wanting to grow, wanting to learn more, trying to kind of push the boundaries and check what's out there outside of your comfort zone. I think that's very human.

+ +

CHAD: Yeah. Well, if people want to get in touch with you or find out more, where are the best places for them to do that?

+ +

DAGNA: The absolute best place is going to my website, theMindfulDev.com/podcast. And that link will actually redirect you to a case study of a client of mine that explains how I work with clients. So if you're interested for us to get to work together, you can just go there and watch the case study video, and let's go from there.

+ +

CHAD: Awesome. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Dagna Bieda.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dagna Bieda is an engineer, career coach, and founder of theMindfulDev.com. She talks with Chad about being a software engineer first and then becoming a career coach who has helped a big range of clients with communication and marketing themselves successfully.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dagna Bieda, engineer, career coach, and founder of theMindfulDev.com. Dagna, thanks for joining me.

+ +

DAGNA: Absolutely. It's a blast being here. So thanks for having me over, Chad.

+ +

CHAD: So what you do is a little bit unique in that you provide career coaching to engineers. But you yourself are an engineer and have a background in engineering. So how did you arrive at what you're doing today?

+ +

DAGNA: Yeah, you're exactly on point there. I was a software engineer and then turned into career coaching. So essentially, I've been coding for over ten years and coaching for the past 3. And I'm the tough love, “I've been in your shoes” kind of coach because I have that engineering experience.

+ +

And a little bit about what it is that I did as a software engineer is I essentially moved from programming in microcontrollers in C through cell phone towers, providing LTE networks in C++. I also did behaviors of social robots in C++. I wrote a distributed web app in Ruby on Rails. And I also wrote some mobile apps for parking and transit in Swift and Java.

+ +

Having that range of experience, I really get to help a big range of clients. My former clients have worked for LinkedIn, Amazon, Google, Disney, as well as much smaller businesses. And their own experience was ranging anywhere from 2 to 20 years of experience. And I had clients who are self-taught, who are career-changing bootcamp grads, who are college grads. And my goal as a coach is to really help them reach for their potential.

+ +

CHAD: Now, did you arrive at this because you yourself struggled with some of these things? Or did you have it easy and you said, "Oh, I don't understand why these other people..." [laughs]

+ +

DAGNA: So both of these questions are exactly on point. I feel like I had it very easy at the very beginning of my career. I essentially got promoted to a senior engineer very quickly. It took about two years or something, so like superfast. But then, as a senior engineer, there was a moment where I felt that I've just plateaued in my career, and I was stuck, and I was frustrated. And I wanted to learn all the technologies out there. And what was missing was some people skills.

+ +

So once I finally was able to figure out okay, this is what I'm missing...and in hindsight, it was so obvious. I decided to move into career coaching because I realized that we're kind of brainwashed, so to speak, to put the technology on a pedestal and ignore everything else, right?

+ +

CHAD: Yeah.

+ +

DAGNA: But if you don't work on your soft skills and don't realize that at the end, it's all humans because you're working with humans...you're creating products for humans. So it's not something you can really escape from. That was like a huge aha moment. I was like, people don't even know this is important. Like, I got to change that. [laughs] That was a mission for me to change that, to help discover what are those roadblocks? What are those limiting beliefs that software engineers often have that keep them stuck in their career and frustrated and stopping them from really fulfilling their potential?

+ +

CHAD: I often say that almost all problems are actually communication problems at their heart.

+ +

DAGNA: Ooh, yes.

+ +

CHAD: And in consulting, we have clients who come to us with what they think is a technical problem. And we have to sometimes tell them like, "We can fix this problem. But if you don't address the underlying communication problem that caused it in the first place, it's just going to happen again."

+ +

DAGNA: Absolutely, yeah.

+ +

CHAD: So I think that's a problem engineers have is that they try to apply technical problems or think code is the solution to every problem.

+ +

DAGNA: Well, it's not just that. Let's think about how software engineers are trained into their careers. If you have a class and you need to deliver a piece of code that compiles and does whatever it was meant to do for your assignment, even if you had incredible communications with your teammate and partner, even if you negotiated changes in the scope of features, it's all not going to matter for you passing your class if the code doesn't compile and if it doesn't do what it's supposed to do.

+ +

So early on, whenever we're creating software, we're taught how to create software. We're being taught to put technology on a pedestal. And I've worked with multiple senior engineers that feel really frustrated because they're so knowledgeable but aren't able to communicate all this knowledge that they have in their own mind.

+ +

They might be having brilliant ideas that might be helping their businesses grow and get past helping the businesses they work for grow. And they're not able to pitch those ideas and not able to really be heard and seen for the value that they bring to the table. And this is where I come in, and this is what I help with, getting past that frustration and that feeling of being stuck.

+ +

CHAD: And just to clarify if I'm following right, and what I'm advocating is this isn't just if you're a developer and want to move into management. This is for just moving up in your career as a developer, right?

+ +

DAGNA: Absolutely. Here's the thing, even if you're going to become the principal architect in the company, what are the skills that you need to have? It's not just technical expertise. If you have technical expertise and you're not able to talk about it with the business stakeholders that don't have the same amount of knowledge that you do, then you're not going to get to that point. Principal engineers create direction in the company, make decisions, have to be mindful about the business value that they're creating, not just the underlying tech stack.

+ +

So as we grow in our careers as software engineers, it is really critical to, once you have, I'd say, five years of experience as a software engineer, to start working on the soft skills. And to be honest, someone who has gone through a coding bootcamp because they had less of that brainwashing about putting the technology on the pedestal often tend to advance in their careers much faster because they bring that previous experience with them to the table, so they can communicate better. They have different types of ideas, different perceptions. They don't have those limiting beliefs that a lot of developers have.

+ +

The number one limiting belief that I see my clients have is believing that the work they do speaks for itself, and it doesn't unless someone literally dives into the code that you wrote. So for you to be able to advocate for your career, you need to be able to say, "Hey, I wrote this feature," and not expect people to dive into the code and look through the feature and all the lines of code you wrote. It’s to be able to emphasize the business impact that the feature you wrote had on the business, and how it helped, how you contributed to the business side. And that's something that I work with developers on.

+ +

Now, you did mention, Chad, that you work with a lot of developers, right?

+ +

CHAD: Mm-hmm. Yeah.

+ +

DAGNA: Would you say that marketing what developers do is a huge thing holding people back in their career?

+ +

CHAD: Yes, not only because of what I said earlier about a lot of the root causes of problems are around actual communication. But you're right; when it comes to who you can rely on in your company, who you can communicate with, who gets their ideas across more, it comes down to being able to communicate those ideas and that value. Even little things like when the code you've been working on is ready on staging, don't just say, "It's on staging. Check it out," and moving the ticket forward.

+ +

DAGNA: [laughs]

+ +

CHAD: But actually being able to communicate what you've done either through words or screenshots. I think we've all been in scenarios where you're working on a complicated ticket, and you are making decisions along the way about how to do that. And you make all those decisions, and they're the best decisions in the world. But if you just put that ticket up for a review and say, "It's on staging," it's either not going to be accepted, or you're going to get tons of questions around why you did this. What did you consider when you were doing this? It's like a lack of trust and understanding there.

+ +

But if instead, you say, "Here are all the things I'm considering along the way." And you say, "I've balanced all of these priorities, and here's the decision I've made, and it's on staging, and it works like this. And here's where you go to view it. And click on this. And here's a movie that shows how it works". People are going to be like, "Oh, sounds great. Accepted."

+ +

DAGNA: Yeah, absolutely. But here's the thing. As developers, we're not taught to do all these things that you just described. We're taught to write code that compiles, boom, done. [laughs]

+ +

CHAD: So when working with people who have this sort of mindset o the skill gap, what are some things that you have people do to level up?

+ +

DAGNA: Yeah, there are certain things that we specifically work on, and that is negotiation, setting expectations and boundaries, being able to respectfully either decline a change in scope of work or try to negotiate the change of a deadline whenever there's an impossible feature request. Or things like being able to set expectations that if you're working on your focus time, that you shouldn't be disrupted.

+ +

And it's something that's very hard because developers usually really want to be helpful. So when a product manager comes to them and says, "Hey, I really need this. It's for a critical client," what happens is most often than not, they're going to drop everything they were doing just to finish that one thing and be helpful. And so being able to create a boundary saying, "Hey, I'll get back to you after I'm done working on what it is that I'm working," is a skill.

+ +

Being able to market what you did and being able to show the business value, how your work contributed to the business side is also a skill. And even having communication with your manager telling them, "Hey, I realize that I need to work on XYZ. Would you be willing to give me feedback? Because we go to the meetings together, you see how I communicate; you see how I think, you see how I act. Give me more feedback. What can I do to grow in my career?" So asking for that feedback is a skill. So there are a lot of moving elements, and these are the skills that I work with on my clients.

+ +

But there's a big thing that I want to address here too is that with technology changing and being at such a fast pace, it is very important to give yourself grace, especially when you're starting out. Be patient with yourself to give yourself that time to actually master the tech part. And it's really important to see and understand how you think about your career growth. Do you beat yourself up in your mind, or do you actually see the opportunities for growth?

+ +

With developers, since we're not being taught how to communicate effectively with other people, oftentimes, when someone wants to give us feedback that might help us in our career, we get defensive because it feels like an attack on our character. And I see it with juniors all the time. "Why did you say I was messy?" "No, no, I said your code was messy." Taking that kind of feedback on the code very personal and getting agitated instead of seeing opportunity for growth in the career.

+ +

CHAD: Would you say that most of the people that work with you are doing it while they're going through a transition or in between looking for their next thing? Or are they doing it while they're in a position hoping to improve within that existing company?

+ +

DAGNA: So all three paths that you mentioned are very valid. It depends on what people are doing, what their goals are. When I work with my clients, we work one on one. So it's very tailored to their specific and unique situation and their needs. But I can tell you that from last year, my absolute best example was one client who came to me because he felt that he was being an undervalued senior engineer.

+ +

And he wanted to promote himself and maybe move on from the job that he was in at the time that he didn't see much opportunity for growth. And he was just stagnant. "Help me market myself. I need to get out of this current situation. I know I have the potential. And I want to find something more exciting to work on." As we worked together, within three and a half months, he became a startup CTO, which was a dream come true for him. But he didn't believe at the time before we worked together that he could actually make that happen for himself.

+ +

Then I had another client who, within two months of us working together, was preparing to land a team lead position. But he actually was able to jump two levels up, and he became a VP of innovation at his own company.

+ +

CHAD: Cool.

+ +

DAGNA: It so happened that as we worked together, his company was going through a massive spurt of growth. And because he was the right person working on the right skills at the right time, he became the VP which is incredible.

+ +

And I had another client just recently who felt that he was overworking himself. He was coming also from a military background. So he had certain beliefs that they served him in the military, but they were not really helpful for progressing in the tech industry. And as we worked together, he was able to not only stop overworking himself and have a better relationship with his wife; he also landed a new job where he doubled his salary. He went from 109,000 a year to 220,000. That actually made even my jaw drop a little. [laughter]

+ +

But it shows you how powerful the process is that I follow with my clients. It's really about the engineering mindset. It's about how to think about career growth and how to prioritize certain things depending on which stage of your career you're in.

+ +

CHAD: Are there other common pitfalls or mistakes that developers make that hold them back?

+ +

DAGNA: So absolutely the limiting belief that I mentioned earlier, believing that your work speaks for itself. I feel like 80% of people that I work with have that limiting belief, and we work to get past that.

+ +

Another thing that is pretty common is not understanding how you come across. That's a problem that I had in my career. When I mentioned that I was a senior engineer for a few years and I felt stuck, I wanted to advance, but it wasn't happening for me. It wasn't clear why it wasn't happening until I started working with someone who was open enough to provide me some tough love type of feedback. One time he told me, "Dagna, why are you calling these people idiots?" And I'm like, "I never said that."

+ +

CHAD: [chuckles]

+ +

DAGNA: My intention was really pure, good, coming from my heart and my soul, from really good intentions. But my intentions were completely different from the message that got across, right?

+ +

CHAD: Was it your tone, what you were saying? What was it that made that come across?

+ +

DAGNA: Part of it is not being assertive enough. And I should probably mention here that I am an immigrant to the United States. I originally grew up and got educated back in Poland, my home country. And the way we communicate in Poland is completely different than how we communicate here in the United States. And at the very beginning, I didn't really understand how my communication impacts my career.

+ +

So essentially, as a senior engineer, I was way too direct. And I was using words that were triggering for some people. So I had to learn how to be more assertive, how to communicate to people that I get where they're coming from, what is their perspective, what it is that they're trying to accomplish in the conversation. Once I started doing that, I actually got the offer to get promoted to the engineering manager that I was working towards.

+ +

But the funny thing is that was the day that I actually came into the office and put my notice in because I was so sad of being a coach by then. I was like; I figured this communication thing out. I need to spread the word.

+ +

CHAD: [laughs]

+ +

DAGNA: It's way too important for me to now be a manager, nah, nah, nah. I have more lives to impact here than just the team that I might be working with.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: That's great. And it segues really nicely into the next question I was going to ask you, which is your experience with the cultural differences. There's a general trend in the market that we're seeing now in more companies hiring remotely, opening up the candidate pool to people who live all over the place. And not only does that expose more people to be hired by different companies, but it broadens the candidate pool. So you're competing against even more people. So is that something that you're seeing as well? And how do people position themselves within the global market now, particularly if they're not in the U.S.?

+ +

DAGNA: Well, if we're talking about global market, we got to be mindful that for a company that's located in the United States or any other country for that matter, there are tax implications. So it really depends on the company and how they are set up to be able to pay out salaries offshore or hire contractors offshore. Because the reality is that a lot of clients of mine that are from the European Union, for example, a lot of clients of mine that are in the EU, if they wanted to apply for companies in the United States, they wouldn't really be considered because of those tax implications.

+ +

So even though a lot of companies open up and want to hire people from abroad, not every company does that. And even if companies say that they are open for remote workers, it really depends on how they're paying their taxes and how all that is set up. So the way I see it is there is a movement towards opening up for remote work. But it's definitely not about competing across the globe, not yet at least.

+ +

CHAD: I think maybe my perspective is a little bit skewed on it just because of where we're at. So are you saying that developers should do their due diligence about what companies they actually want to work for?

+ +

DAGNA: Absolutely, yeah. I mean, applying for a company that is not set up in a way that can support paying salaries outside or even having those international agreements in place, you're just wasting your time applying there and setting yourself up for frustration because they're not going to reach back to you.

+ +

CHAD: Yeah, that's good advice.

+ +

DAGNA: Now, in terms of your work with remote positions, who do you usually work with, Chad?

+ +

CHAD: Are you asking from developers that we typically work with or who do we --

+ +

DAGNA: Yes. I was curious, like, what's the amount of people that you work with that are actually remote and worldwide? What is your experience there?

+ +

CHAD: So last year at thoughtbot, we got rid of all of our offices, and we went fully remote. And when we did that, it took us a little while to get everything organized. But when we did, our goal was to open it up based on time zone, not based on country that you live in. And so we organized into two teams, all of the Americas and Europe, Middle East and Africa is the second team.

+ +

DAGNA: So I'm curious, what are the tax implications of you guys paying out those salaries?

+ +

CHAD: So we use a company called remote.com along with a few other partners that provide employer record in the country that you live in. So there's an actual entity. You're fully paid according to local rules with actual salary benefits, paid time off, all that stuff. And you are a real employee of that entity in that country. And then what they do is they invoice us for that total amount.

+ +

DAGNA: Ah, that's awesome.

+ +

CHAD: And they handle all the local employment, which is great because up until that point, we previously had to have entities of our own in every country in order to do it right because we really want to do it right. We're not that big, and so it's a lot of overhead for us to be able to do that. So working with partner companies, companies that provide that local entity is the direction we've gone in, and it's worked really well overall.

+ +

DAGNA: Awesome. Glad to hear that.

+ +

CHAD: And I think in general, I'm trying to spread the word about that because I do think it is important. There are a lot of companies out there. This is building on what you said before. There are a lot of companies out there that are, on one hand, doing things incorrectly or, on the other, they might not have good intentions; they're sort of purposely taking advantage by having people work as contractors when they probably really shouldn't be.

+ +

DAGNA: Oh yeah, I hear you.

+ +

CHAD: I'm curious, in your role now, do you still code at all?

+ +

DAGNA: So I gave up coding for now. I essentially left my last engineering job in March of last year, and I've been fully focused on coaching. Coaching as it is is a skill as well. And I realized that if I really want to make an impact, I have to have my attention fully devoted to that business. And part of it too is business growth.

+ +

A skill that I'm learning right now is writing, writing a newsletter, writing posts on social media, and just sharing what I think is very important and what is not really being talked about enough like the communication, like the human side of software, like career growth, and the fact that we are set up to overvalue the technical skillset in terms of career growth. And all this really takes up my time and my effort.

+ +

CHAD: One of the things that resonated with me when I looked at your website was this idea of being clear on your personal definition of fulfillment. Fulfillment is one of the things we talk a lot about at thoughtbot. It's one of our core values. And so, how has it been for you to transition away from coding? And do you think you're going to be fulfilled by that over the long term?

+ +

DAGNA: Oh, absolutely, yeah. It's been a blast. Here's the thing, as I help my clients achieve spectacular results, that's what really puts me on fire. And I wake up every day thinking, damn, I can help people in very critical moments in their life.

+ +

I had a client who, as we were coaching together, unfortunately, his father passed away. And he told me that thanks to the coaching that we did together and the mindset training that we did, he was able to cope with this difficult situation in his life so much better, not to mention how that impacted his career.

+ +

So I get to really help, really have a huge impact on people's lives, and that's something that really is incredible for me. That is my personal definition of fulfillment. And I like to say that I used to be programming, and now I'm re-programming human minds.

+ +

CHAD: So this idea of personal definition of fulfillment, first, why is it important to be clear on that?

+ +

DAGNA: It affects your energy levels, your motivation. If you're working in a place that might be giving you an incredible benefits package, but every day you wake up, and you just don't want to go to work, that is something that I like to call golden handcuffs because you're essentially in hell, in prison. And it feels horrible to be in a situation like that. And I have experienced it myself where I felt like I have so much potential within me. Why am I wasting my time here? Even though the money was great, the benefits were good, but I knew I had so much more within me.

+ +

And figuring out the personal definition of fulfillment is really what helped me open my eyes that; hey, my job was great, but it wasn't something that I really wanted to do. It's kind of like being in a relationship that just doesn't work, but you're in it just because. [laughs] Isn't it so much better to work in a place that is meaningful to you, that supports your values, that fits your desired lifestyle, someplace that every day that you wake up, you're really excited about going to work? Isn't that a much better way to live?

+ +

CHAD: Yeah. What if someone finds themselves understanding that these are the skills that they should have to be a really great developer and advance in their career and maybe even making progress on that? Are there other things...you used the term earlier about marketing yourself. Does that mean having a great personal website? What does it mean when you say that?

+ +

DAGNA: Well, I really mean being able to talk about your accomplishments, depending on which stakeholders you're talking to. So if you're trying to pitch an idea to your product manager, then talking at the product manager level, being able to show how what you do or the idea that you have contributes to the business. If you're in an interview setting, how to discuss what you have accomplished with the people that might want to potentially hire you.

+ +

It also is related to having your LinkedIn in a way that attracts attention and brings people in that you actually wanted to work with. I've had some people come to me and say, "You know what? I get seven; eight offers every single day on LinkedIn." And I'm like, that's great. But are these the offers that you actually want to work on? Is it something that you actually want to pursue, or you just want to keep getting those notifications?"

+ +

And oftentimes, whenever we have our LinkedIn profiles set up, what happens is we put the keywords there. I know this tech stack; I know this framework. I've worked with this language, blah, blah, blah. And what's missing is who you are as a person, what you value. What do you expect from a workplace? What kind of change do you want to make in the world? What is really important to you? What are your expectations?

+ +

And I think that the pandemic, in a way, showed that, that as we got to work from home, we got to re-evaluate what is really important in our lives. Back when you used to go to the office, you would have that disconnect between the work and the life. And you could strive for some work-life balance but keep them kind of separate.

+ +

Now, with everything being super entangled, it kind of forces you to reevaluate okay, what is really important for me? Is it important for me to eat breakfast with my kids and drop them off at school, and pushing that meeting to a little bit later during the day? Or is it important to me to clock out after 6:00 so I can be with my kids after they get back from school? Or do I really care about maybe doing all my work after 6:00 p.m. because that's when my brain lights on fire? Have you found yourself going back to re-thinking what is important in life after the remote work started?

+ +

CHAD: [laughs] Well, yes, and no. Yes, but I also have made a habit of doing that.

+ +

DAGNA: Oh, perfect.

+ +

CHAD: As a result, I often dramatically either change my schedule or my focus or something about every two years. And that has been critical to me to be able to do this for so long. I haven't really worked...I've been doing this for more than 18 years now, but I haven't really worked in the same job more than two or three years. Even though it might be the same title, the job has dramatically changed. And that's through my own personal initiative of realizing what I need to do to be fulfilled now. And I'm fortunately in a position where I can make those changes happen.

+ +

DAGNA: That's great. But I kind of want to share that I believe everybody's in a position to actually do that.

+ +

CHAD: Yeah, I agree.

+ +

DAGNA: Especially in engineering. There are so many opportunities for growth. It's kind of ridiculous. You can be an embedded engineer and become a front-end engineer. You can go into the backend, and then you can do DevOps, and then you can become an engineering manager. And then you can go back to being an individual contributor if you wanted to.

+ +

I mean, you could just move up, down, left, right, check things out, see what's fun, what's not, change industries. So there's just so much opportunity for growth. And I think it's also very human wanting to grow, wanting to learn more, trying to kind of push the boundaries and check what's out there outside of your comfort zone. I think that's very human.

+ +

CHAD: Yeah. Well, if people want to get in touch with you or find out more, where are the best places for them to do that?

+ +

DAGNA: The absolute best place is going to my website, theMindfulDev.com/podcast. And that link will actually redirect you to a case study of a client of mine that explains how I work with clients. So if you're interested for us to get to work together, you can just go there and watch the case study video, and let's go from there.

+ +

CHAD: Awesome. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Dagna Bieda.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+B-dqwl3z + + ]]> + + Chad Pytel + Dagna Bieda + + + 408: Shipyard with Benjie De Groot + https://podcast.thoughtbot.com/408 + d9c6eca4-af9d-4e89-903e-716b515f6267 + Thu, 27 Jan 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Chad talks to Benjie De Groot, co-founder, and CEO of Shipyard. Shipyard manages, creates, builds, and deploys ephemeral environments. + +Benjie talks about how Shipyard became a funded company, discovering who their ideal customers are, and building out the core team so Shipyard can accelerate and figure out their next steps in how to bring it to the masses. + 38:56 + no + + + Chad talks to Benjie De Groot, co-founder, and CEO of Shipyard. Shipyard manages, creates, builds, and deploys ephemeral environments. +Benjie talks about how Shipyard became a funded company, discovering who their ideal customers are, and building out the core team so Shipyard can accelerate and figure out their next steps in how to bring it to the masses. +Ephemeral Environments (https://ephemeralenvironments.io/) +Shipyard (https://shipyard.build/) +Follow Benjie on LinkedIn (https://www.linkedin.com/in/bueller/). +Follow Shipyard on Twitter (https://twitter.com/shipyardbuild), LinkedIn (https://www.linkedin.com/company/shipyardbuild/), or GitHub (https://github.com/shipyard). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Benjie De Groot, co-founder, and CEO of Shipyard. Benjie, thanks for joining me. +BENJIE: Thanks for having me. +CHAD: Why don't we start by if you don't mind sharing a little bit about what Shipyard is and does? +BENJIE: Sure. At the core of what Shipyard is working on is ephemeral environments; not everybody knows what that means. That is changing a bit. But essentially, what we're focused on is on every pull request or commit for a feature; Shipyard manages, and creates, and builds, and deploys ephemeral environments. So that's a disposable one-off on-demand environment that any stakeholder in your internal company can use. And we focus on the tooling around that, on build pipeline, and then security around that. And then all kinds of other cool features that are necessary that pop up. +CHAD: Cool. So as a developer, I'm familiar with the concept of developing locally, putting up my pull requests. And also, we deploy a lot of stuff to Heroku. So I'm familiar with some of the infrastructure that Heroku might give. How did you arrive at saying like, this is a thing that I want to work on and believe should exist? +BENJIE: That's a great question. I actually am also a developer; that’s my background. And throughout the course of my career, I've always been on the technical side of the company. And what that's translated to, because of passion, to be honest, is always taking on a DevOps type role, so throughout the course of my career, a lot of responsibility. +I mean, I started off writing Bash scripts, went to Puppet, did Chef for a while, did Ansible. Somehow I went back to Bash scripts for a lot of this stuff. Then this company called DoCloud popped up, which obviously became Docker, and I kind of got obsessed with that. And then I had a bunch of friends at Google, and they were telling me about this creepy thing called Borg, and that became Kubernetes. And so, my career has kind of happened throughout that entire process. And throughout, DevOps has kind of been my passion. +Along with my co-founder, Peter, I was a high-priced Kubernetes consultant in the New York ecosystem just a few years ago. And a lot of companies were trying to make the transition to Kubernetes. And Peter and myself came in and helped people that were struggling to find DevOps resources. And what that always kind of looked like was there was some bespoke version of a deployment system that was perfect for the person that wrote it. But obviously, it wasn't good enough for me and Peter, for Peter and myself. +CHAD: [laughs] +BENJIE: And so we would rewrite it, and it would be great. But then, eventually, we'd move on, and someone else would rewrite it. And there were a few instances where we ended up going back to companies and just reimplementing what we had already done. And throughout that process of being this consultant, we kept running into this ephemeral environment thing and building the same tooling over and over and over again. +So Peter and I, on a weekend, kind of got, "Oh, let's make a tool for ourselves." So we did that. And we made this exoskeleton to help our consulting business. And as things progressed, we kept just adding features, and it was really fun, and it was great. And then some of our customers or clients saw that. And they were like, "Hey, can we click that button?" And we were like, "I guess." +And so slowly, it turned into a product that was very duct tape-y and glued together, but it worked great. And to be frank, I had been through the VC process on the technical side in the past and didn't want to go through that again, the hamster wheel of need to raise more and more money and so very, very averse. And was very set on a really nice lifestyle consulting business, and hell was going to have to freeze over for us to take any VC dollars. +And then I don't know if you heard, but in March of 2020, hell froze over, and [laughter] there was a little pandemic. And at the same time, we got some pre-emptive term sheets, yadda, yadda, yadda. Next thing you know, we're a funded company building out a really cool product. So that's the origin story of where Shipyard came from. +CHAD: Really cool. I definitely want to come back to what building the product for you has been like, and the funding, and where you go from here. But let's come back to the product itself. As a developer, my normal workflow is I'm working locally. I'm able to run the application that I'm working on locally here on my computer. I put up a pull request on GitHub. I ask my team to review it. +Once it gets reviewed from a code perspective or a design perspective and gets a thumbs up, I merge it back into the main branch. And I deploy it to a staging server, at which point I would ask my stakeholder, my client, whatever, "Hey, this thing you're expecting it's on the staging server for you to check out." And everyone else on the team is doing the same thing. So where does Shipyard come in, and why is it better than that? +BENJIE: So where Shipyard comes in, it's after the local development but before you get to staging or really before you get to production because, in practicality, a lot of people turn Shipyard into their staging servers. But what happens is through webhooks, we hook into your GitHub. And we see that there's a new commit that comes in. And we automatically build and deploy a fully ephemeral environment for that feature. And what that gets you is a few things. +One paradigm that we're seeing a lot of is when you make that PR, a lot of end-to-end test suites are being run automatically using Shipyard ephemeral environments. And what that gives you is, in some instances, before you even have a code review, you're passing the suite of tests. And what that gives you is you save a lot of time. If there's just a dumb migration error or some typo or something like that, you're not wasting human capital or human energy on those environments. +And the other instance there that gets really interesting is by bringing up these environments earlier on, product stakeholders and QA stakeholders can do their jobs earlier on in the process. And so you can avoid a lot of merge conflicts. So like, you merge something, and maybe there's an edge case that you hadn't tested for, and the code review didn't pick up. Well, all of a sudden, staging is broken. And some other team member that's using the same process you were now they're blocked. Or the client can't see that environment, and there's some other type of problem. +But really, we didn't invent this paradigm. This is what FAANG does. There's a reason why I can't remember the last time that Gmail itself a button broke, or there was bad CSS, or bad HTML, same thing with Facebook, same thing with Netflix. Obviously, we all know about –- +CHAD: There's the obvious DNS outages. +BENJIE: [laughs] Right. I was going to say we all know about AWS, especially in December of 2021. That was a tough month. But yeah, from a UI/UX and controllable release perspective, this greatly increases your internal stakeholders’ ability to get their hands on features earlier, find problems, and then get those back to developers. +And the other thing, and maybe this is a question for you. But have you ever been in a situation where you built something, and it doesn't actually get reviewed for a few weeks? And then there is a bug, and you have to go back, and context switch off of what you're working on and go back and put a whole other mental model in place to go back and remember why did I use a switch statement here? That's a bad example but something to that effect. +CHAD: [laughs] Yeah. Well, I really try to avoid that scenario by having tight feedback loops, but sometimes it's unavoidable. It might be you finish something right before a holiday or going away or something like that; that can happen. So it's happened to me before, yeah. +BENJIE: Right. And how do you get your product people or your UAT teams...when do they get to touch the feature that you're working on? +CHAD: It's usually not until after a code review when it's been merged into main and deployed to staging. +BENJIE: So that's kind of how we make that feedback loop tighter. And what we've seen in practice actually is a lot faster, more reliable releases. And there's a significant increase in the cadence of releases that can happen and a higher quality of those releases. +CHAD: You mentioned that some customers end up even getting rid of staging. And so that's really exciting and interesting to me. When they do that, what does the overall picture look like? Is the code merge manual? Or do you have customers that are doing continuous deployment off of a thumbs up from the person reviewing it in the ephemeral environment and getting that automatically merged, and then maybe canary deploy or something to production? +BENJIE: Yeah, that's a great question. The thing to keep in mind here is that the majority of our customers are larger, and they have bigger teams because obviously, this is a collaboration platform ultimately. And so there's more value for the more complex teams and more stakeholders. So we don't have anybody at this moment that I know of; there could be, doing LGTM is good enough. So there's always a manual component. +But what it looks like from a staging perspective is that your main branch is actually ostensibly your staging environment, and so all the ephemeral environments are sort of dev environments that are shareable. And then when you merge because a code review passes, and QA checks, and UAT, then it gets automatically built into the main branch and the main environment. And then some people do QA. They'll final pass a QA or a final end-to-end test there. And then there's also a manual promotion to production as well. That's the typical pattern we've seen. +CHAD: Cool. One of the things that when I've used...sometimes a problem even with staging. But when I've used or been on projects with some ephemeral environments, getting good data in those environments can sometimes be a challenge. Is that something that Shipyard helps with? Or what's your recommended approach to that problem? +BENJIE: So that was one of the biggest problems we had early on. We put a lot of work into that. We apply the same git branch model to data. So the way that we do that is basically if you...oh, by the way, I forgot to mention something. We use Docker Compose as our application definition. So we extrapolate from Docker Compose and transpile into best practice Kubernetes YAMLs. So there is a little bit of inferring and magic we do in certain places. And one of the places we do that is if you have a named volume...sorry, am I getting too technical, or is this --? +CHAD: Not for me. And in fact, I have follow-up questions about [laughs] why you have that approach of converting. +BENJIE: We will dive into that in a second. And I have a whole bunch of redhead friends that make fun of me about Compose all the time, but I stick to my guns on that one. But I'm happy to talk about that. At high level, if you indicate to Shipyard this is a persistent volume that we want to make sure that child environments get, then we will do an instant snapshot. And we will actually provide that to the generated child ephemeral environment. And ostensibly, what that does is it allows you to test data migrations as well on these ephemeral environments. +Now, to go back to your initial question, we encourage...and we're working on some partnerships actually with some interesting companies. But we encourage people to specifically have their main data set on main be ostensibly a copy of whatever the good data set is. But obviously, you're responsible for pulling out your own PII and all the confidential stuff there. But the key thing here is you're maintaining one environment with the right data on it. And then all of the subsequent generated ephemeral environments inherit that and can then change that. +CHAD: Yeah, that's cool. That solves a real pain point that I've had in the past when trying to work this way. +BENJIE: One company that I think is really interesting around this space is Tonic.ai. And we're actually working on some stuff with them, I think. But we share an investor, so that's why I know them, for disclaimer purposes. But they're great. And they have some really cool tooling around mapping your database to PII and automatic detection of certain types of information that you don't want pushed into your staging servers and to your developers' hands. So that's one to check out, too, if you're looking for data help. +CHAD: Cool. So do you want to get back to this Docker question? Why that approach of converting the Docker Compose into YAML for Kubernetes? +BENJIE: So this is quite a controversial topic. +CHAD: [laughs] +BENJIE: But I will tell you where it came from. Hearkening back to our origin story, what we saw was we saw a pattern of a lot of companies going a little bit too all-in in Kubernetes; let’s just put it that way, where every single one of the developers is running minikube or even K3s or K3d or whatever. And all of a sudden, the DevOps people and the SRE people in the organization are spending most of their time supporting developers in local development environments. +So early on in that consulting game, we realized we don't want to do that. So if you want to work with us, we think you can use Docker Compose for most things. Now, that's obviously not always the case. There are some companies and applications that have hundreds of microservices. So obviously, Docker Compose is not a very realistic fit for those people. But the majority of people can pretty much encapsulate their application in Docker Compose. So that's one thing. +The other thing is I mentioned to you that I'm a DevOps engineer for years. I'm sick of new YAML formats or specifications. So I have a saying, "Not another YAML, I say nay." My co-founder, Peter, hates when I say that, but whatever, I like it. +CHAD: [laughs] +BENJIE: So that's another piece of this. And then the biggest thing here is that we look at Docker Compose as rabbit ears on a television set. So you know, like a 98-year-old grandmother can somehow stand on one foot and hold the antenna the right way, and it's static. The picture is perfect, and they can watch...I don't know why I'm saying Jay Leno. I don't think it's on the air anymore. +CHAD: [laughs] +BENJIE: Sticking with the grandma reference, humans are really good at figuring out stuff like that. [laughs] And that's kind of what Docker compose is. It's kind of like if you can make it work locally, Shipyard is going to take care of the rest and clean up a bunch of stuff for you. So that's how we look at it. +Admittedly, we do have some Helm stuff we're working on and some Kustomize (with a K) stuff. And there are a whole lot of other interesting things out there. But frankly, we haven't run into problems with our current approach. And when we have tried to ingest raw manifests and stuff like that, other issues tend to arise. So we use Compose as a funnel to be very opinionated about our Kubernetes deployments. +CHAD: Well, I'm a big believer in, especially in early days having opinions about things. And it sounds like, with this particular opinion, you not only can help people at different stages and say that "This is good enough," but you're also casting a wide net for what people can do. You're not cutting people off because they already use Kustomize or something like that. +BENJIE: Yeah. And a lot of it is about accessibility. And so it's proven to be a pretty interesting thing. We didn't think that we were going to go this far with it. [laughs] We really thought that we were going to get in trouble soon. But it's pretty cool how it's going. +And also, I will do a shout-out to the Docker Compose community. They're picking up some steam here. I think a lot of people are realizing that it's a pretty good spec for most use cases. So I know that Docker released somewhat recently you don't have to do Docker-Compose anymore. It's just Docker Compose. And there are all kinds of Compose specifications stuff that I think is worth checking out. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So to get a little bit meta for a minute, how do you use Shipyard on Shipyard? +BENJIE: The ultimate dog food. That is one of the biggest selling points to our own engineering team when recruiting. We've got a pretty spectacular team that comes from some pretty awesome companies. And people sometimes ask me, "Hey, how did you get these engineers?" And honestly, I think the answer is dogfooding. Because what we're building is what every DevOps engineer sets out to build every time they start their job, in my opinion. +You always want this ephemeral type of elastic environments are only on when you need them to be on. I didn't discuss this, but we also have functionality that we call SLV or Since Last Visit. So we know the last time someone went to one of these environments, and we'll turn it off for you. And then, obviously, it's very quick to turn it back on when needed. So there are cost savings. There are all kinds of stuff there. +But ultimately, we're building the ultimate DevOps tool. And so we use Shipyard to run Shipyard. We use it in our QA process. We use it in our end-to-end testing process. And we also use it in our production process as well. We have some of our...we do have a production offering, and we use that ourselves for our stuff. So it's a very recursive conversation around that. +And sometimes, when I'm actually doing a demo for various people, the only way to show or the only good demo I have of certain functionality is to actually show the Shipyard organization itself in Shipyard. And I get very recursively tied up, and people get confused. And it's always a bad idea. +CHAD: [laughs] Yeah, you have to queue the Inception music. +BENJIE: Yeah, exactly. We're at the third level. We're at the ice palace or whatever, ice hideout at this point. That's from the movie Inception for those that don't know what we're talking about. +CHAD: [laughs] Yeah, that's really cool. I imagine that...sometimes when I'm working on a project, and you get down to the instrumentation level, to those levels, it can be difficult to run the system on the system. Have there been particular challenges? It's not just a normal web app; I guess is the way of saying that. What Shipyard is isn't just a normal web app. +BENJIE: Yeah, one of the things that we do is that we have a pretty robust security posture, so every single one of our customers gets their own cluster. And so our security model is using the hypervisor basically, which, by the way, for anyone looking at Kubernetes, forget Shipyard for a second. Please understand that if you're in a shared namespace anything, our back is great, but don't do it. There's a CVE around on the corner, I promise you. Don't do it. Anyway. +CHAD: [laughs] That's a good PSA for people. +BENJIE: Yeah, right? [laughs] Yeah. So some of the cool challenges we've had is we early on, we definitely had some stuff where if we did a bad release, we would break our own ability to fix our own releases. So that was that way early on. We figured that one out very early. I think that was even before we were a product even. That was just a few sleepless nights of Peter and myself being like, oh God; we got to fix this so that we don't screw up this client's website. So that's been interesting. I mean, that was really it. +And my co-founder, Peter, is listening to this, and he's like, there are 4,000 different things I've fixed over the last few years that were a problem around this, and I can't bring them up. But there's a lot, and I don't know what they are. And Peter is very good at fixing them. So that speaks to my co-founder and the rest of the team. +CHAD: So you mentioned that March of 2020 happened, hell froze over. And you found yourself thinking you're going to take a different path and fundraise and become a funded company. How difficult did you find fundraising in that environment, or was it easy? +BENJIE: It was real tough at the beginning there. For one, I have no idea what I'm doing. [laughter] That's just the truth. Maybe I should say that in the past tense. I had no idea what I was doing. I still feel like I have no idea what I'm doing. +But like I said, I come from a technical side, and I'm a bit of an engineer. So if a VC asked me a question and the answer is yes, but I have to qualify it with some weird edge case that I came up with. That's not a great look for these types of pitch meetings. So I would suggest people not overengineer answers to questions, yes or no works very often. So it was challenging. +But also, at the time, I'll say that there was definitely some predatory term sheets going around because this was really early, and we had no idea. And I was a fool...I wasn't a fool, but I had no idea. We're running this consulting company, and I'm like, oh my God, all my customers are funded. They're all going to go away. We had some pretty large customers. It was very irrational looking back. But it was a crazy time. Also, I should mention that we're in New York. So things were heightened a lot more also in March of 2020. It was very intense, and so I had to learn a lot. +And basically, the realization like, oh, if the world becomes remote, software is just going to go crazy had not seeped into my brain quite yet in March or April. So did a lot of learning that way. We were very fortunate to have some really helpful people along that path and eventually figured it out. +I will say, funny story, I literally didn't have a pitch for three months. I would just do a demo and talk about stuff. And then a friend of mine was like, "Oh, what's your pitch?" And I was like, "I do a demo, and I talk about it." So he's like, "Dude, you got to have a pitch." So that helped a lot once I figured out [laughs] that I needed a pitch. +CHAD: It did help. So you recommend people have a pitch. +BENJIE: I would say that that is a positive, yes. Having a pitch is helpful. I know that that's a ridiculous statement here, but I literally didn't have...I just didn't think about what's my pitch? +CHAD: Well, I think it's simultaneously a ridiculous thing but also there exist in the world things that people do just because that's the way that they're done. And so it's valid, I think to say, "Do we really need that? Can we get by without it?" And if the lesson learned there is actually there's a reason why people do it and it is valuable, that's a valuable lesson. It's too bad you had to go through it to discover it. +BENJIE: Well, yeah. I look back fondly at that. And I wouldn't say I was being contrarian. I was just kind of being a jackass, frankly. But I learned a lot. And honestly, in the end, I couldn't be happier. I'm pretty anti-VC. Everyone knows that about me. I like to make fun of them and all these things. But I couldn't be happier with our investors, and they've been unbelievably supportive. And so that's been a super positive. +The one thing I would say to anyone listening to this podcast that has to go out and raise money is you got to get really good at letting things roll off your shoulder. As an engineer, it's really hard for me to deal with any level of rejection because I'm like, oh, it works, or it doesn't work. Oh, you found this edge case that I didn't think about? Oh, you got me, but I'll fix it now, and now it's fine. That's not the way that fundraising works. +You have certain conversations, and you feel super positive. And then, all of a sudden, you don't hear back from this person for weeks at a time. You have other conversations where you think that it was the worst thing that you've ever done. And the next day, you get a term sheet. +I had one pitch...this is when I knew how to do a pitch. This was a few months in. I had this one pitch, and it was all virtual, and it was very early days in our remote world. And there were four partners on this call and a few associates or whatever. And I do the pitch, but everyone is muted on Zoom for 45 minutes. Now, it's pretty clear from our conversation that I talk a lot. So it's not the end of the world. But I had no idea what was going on. And I just thought that I had bombed it. It was horrible, all these things. +And the next day, I got an email, and it was three introductions to amazing opportunities. And two of them actually panned out. We didn't end up going with that fund. But I just thought it was hilarious that I was convinced that I shouldn't be doing this, and it was the opposite. So you never know. That's the other thing I learned is you literally can never know what's going to come of any particular meeting in the VC fundraising world. +CHAD: So how long did it take you from the point that you decided you were going to do this and you were going to start trying to fundraise to actually getting the investment in the bank? +BENJIE: Probably four to six months. We obviously had some opportunities, but as we went through this process, realizing that having the right partner for the next 7 to 10 years was really important. And we ended up with our lead. I can't believe I'm talking positively about a VC on a podcast but whatever. +CHAD: [laughs] +BENJIE: Our lead, Owen Davis from Contour Venture...Contour is like this New York fund that they do everything, but no one knows their name. Oh, he's going to love that I said that but whatever. +CHAD: [laughs] +BENJIE: They're great. He's great. And he's the dream investor for us to lead. And then we have other...and I'll mention Shruti over at Array and the folks at Heavybit and Work-Bench as well. They're all in this round, and it all came together. And I was a little picky. So we kind of took our time. And I suggest that if you have that luxury, which we did because we already had a successful consulting business, make sure you know who you're getting into business with for sure. And we got very lucky with that. +CHAD: So how much time while you were fundraising did you personally work on that as opposed to other things for the product or the business? +BENJIE: I should have probably put a little bit more time to the fundraising. To be honest with you, I would say I probably put 50% to 60% of my energy into the fundraise, and then the 40% was all building product. As an engineer, you have a really frustrating call, or you think you're doing well, and then you're not, or vice versa. So for me, I would retreat into building. And so I probably retreated into building a little more than I should have to be frank, [laughs] but it worked out in the end. +CHAD: While you were doing that, you supported yourselves from the consulting revenue. +BENJIE: Yeah, for the most part. We still had active clients. So we converted most of those...actually all of those into Shipyard customers. And they were very supportive in that process, by the way, doing due diligence calls for us. They were all very helpful. +CHAD: And how did you decide how much money you should be seeking to raise? +BENJIE: Ultimately, that was something I struggle with just because I really want to know what I'm going to do and what the plan is. And one of the lessons that I've learned as a CEO now is your job is basically to make unbelievably important, critical decisions with little to no data and just hope you're making the right one and then adjust quickly if you're not. So understanding when you've made the wrong decision. +But ultimately, to answer your question, I built out a spreadsheet. I had a wish list of engineers that I knew or positions that we needed to fill, probably underestimated some of the product marketing needs that we would need to do. But built out a model and then figured, hey, how can we get there in 18 to 24 months to get to the next round? +Because you really do have to be making sure that you can...I mentioned the hamster wheel early on; maybe that's too negative of an analogy there. But you have to be thinking about your next round. And so you have to get to what metrics you want to hit. And you just work backwards from there. +CHAD: At what point along the way...you mentioned earlier that your customers tend to be larger companies. At what point along the way did you discover who your ideal customers were? +BENJIE: I think we're still discovering that. We're still figuring that out. But for me, this tool Shipyard, and I've seen it, if you start using a tool like Shipyard from day one, the gains and the benefits are just insane. We had one company that started off from scratch with us. And within two months, they had extremely robust software development lifecycle, production deploys, all kinds of stuff. And they've been going now for years...not years but a year a half or so with us and super successful. +So I always wanted to be like, oh, startup X with two engineers you should use us. And the more we talk to them, the more conversations we had. We're just like, this is not a DevOps priority. DevOps is not the priority. +CHAD: Especially in those early days, I feel like there's such a tendency, especially from engineers, to say, "Oh, that's not that complicated. I can do that," or "We don't really need that. Let's piece together this." +BENJIE: Yeah, that's exactly right. So then, as we started to talk more and more and understand what people were doing, we just fell into this ICP or Initial Customer Profile of more complex teams that are really facing these problems. I mean, specifically, when you get to a certain size, a bad release costs you a lot of money, customer success, customers that are leaving you, frustrated sales execs, frustrated product people, frustrated QA people. So it's when you get to these more complex levels is when you need this type of tooling. +Now, one thing Shipyard released actually very, very quietly, but you know, it's released. We released a 30-day free trial. It's kind of like our light tier, so people can start doing it. And we're starting to see some people at the earlier stage companies starting to do this, which is exciting to us. But our goal as a company is absolutely to figure out how to get this to the masses because ephemeral environments is the paradigm of the future. I mean, it's the paradigm of the present with the big tech companies. And it's now coming down to the rest of us. +And so instead of having to hire five DevOps people to build the system out for you for six months, you hire one DevOps person, and that DevOps person shifts into an SRE role, not entirely, but their concerns are more about reliability of the actual site rather than reliability for developer environments or QA environments or staging environments. So we think that's really powerful. +One thing that I probably should have mentioned way sooner is we have a community site that we've donated, and we're more than happy to have some pull requests come in. We've had a few. ephemeralenvironments.io, yeah, I don't know how to spell ephemeral either, but you can Google it. It will come up. +CHAD: [laughs] +BENJIE: ephemeralenvironments.io, and it goes through the different use cases of ephemeral environments and where there's value there. So that's kind of the goal with all this. +CHAD: So what are you working on now? And what is the next stage for the company, I guess also from a product perspective? But also, you mentioned that hamster wheel. [laughter] You're coming up on 18 months of being on that wheel, right? +BENJIE: We are. One thing is we've had some success, so our revenue is pretty solid, but no rest for the weary. But we're probably going to go out and bring in some more capital pretty soon. And the reason for that, because that's always the important thing to me, is that we have some pretty spectacular design partners, some pretty big logos, all these things. +The product is there. The product is killing it. I couldn't be more proud of the product and the team. We've also started to build out the core team and couldn't be more proud of that. And so now we need to accelerate and figure out our next steps and how to bring this to the masses. +And ultimately, the vision of Shipyard is to make all this stuff move a lot faster, bring velocity to teams, and all that stuff. And we believe that ephemeral environments are a huge component of that. So we're probably in the next few months going to probably go out and look at our financing options. I will say that the market has been a little insane. So I feel like all the education that I got in 2022 is probably out the window because some of these valuations and other stuff seems like it's a frothy market, as they say, but we'll be doing that. +And we're really going to probably double down on figuring out what the community needs and where the value is for the community, so both with ephemeralenvironments.io. But also, there are some really cool internal tools that we've built that solve some of the issues within the Kubernetes ecosystem. Okay, that's a strong word. They help a lot. I'm never going to say I've solved anything in Kubernetes. +CHAD: [laughs] +BENJIE: But they help a lot with understanding why the state of your application is maybe not where you want it to be. And so, we'd like to probably contribute a bit more back to CNCF, in particular, but open source in general. So continue to build the team to work on that. And then, obviously, pushing forward with product and some pretty cool stuff we have on the roadmap that we're really excited about. +CHAD: Awesome. Well, I wish you all the best with that. If folks want to find out more about Shipyard, follow along with you, get in touch; where are the best places for them to do that? +BENJIE: Really, shipyard.build is our website. And that is probably the best place to try it and also to contact us. Our Twitter is @shipyardbuild twitter.com/shipyardbuild. Personally, I'm not a fan of Twitter. So I personally don't use Twitter, but we do as a company. And I think that our Twitter and our website are probably the best things to reach out to, and obviously, sales@shipyard.build you can send an email there. But I think you'll probably find the information you're looking for on the website. And if not, please let us know what's missing. +CHAD: And you mentioned the free trial. So I feel like that's a great thing for people who want to get more into the product; they can give it a try, right? +BENJIE: Yeah. And one thing to note about the free trial the reason that it's kind of cool is it's your own cluster. You get your own cluster. It's completely single tenant. It's pretty dope. It's pretty cool. And you can really take it for a spin. I would suggest, I mean, we've had a lot of success with companies that are using Docker Compose already to just dive in there and get their application running. +But I would say that we have some pretty cool starter apps as well. They're linked in our docs and our GitHub. Just seeing the power of this through our starter applications has also been a great experience for a lot of people. So I'd suggest taking a look at that. +Oh, and I should plug a podcast that I'm a co-host of, Kubelist. I do that with Marc Campbell from Replicated, where we interview CNCF open-source projects all the time. That's why I got to be careful pretending like I'm solving anything. There are a lot of options in the Kubernetes landscape. +CHAD: Wonderful. You can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Benjie De Groot. + + + Chad talks to Benjie De Groot, co-founder, and CEO of Shipyard. Shipyard manages, creates, builds, and deploys ephemeral environments.

+ +

Benjie talks about how Shipyard became a funded company, discovering who their ideal customers are, and building out the core team so Shipyard can accelerate and figure out their next steps in how to bring it to the masses.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Benjie De Groot, co-founder, and CEO of Shipyard. Benjie, thanks for joining me.

+ +

BENJIE: Thanks for having me.

+ +

CHAD: Why don't we start by if you don't mind sharing a little bit about what Shipyard is and does?

+ +

BENJIE: Sure. At the core of what Shipyard is working on is ephemeral environments; not everybody knows what that means. That is changing a bit. But essentially, what we're focused on is on every pull request or commit for a feature; Shipyard manages, and creates, and builds, and deploys ephemeral environments. So that's a disposable one-off on-demand environment that any stakeholder in your internal company can use. And we focus on the tooling around that, on build pipeline, and then security around that. And then all kinds of other cool features that are necessary that pop up.

+ +

CHAD: Cool. So as a developer, I'm familiar with the concept of developing locally, putting up my pull requests. And also, we deploy a lot of stuff to Heroku. So I'm familiar with some of the infrastructure that Heroku might give. How did you arrive at saying like, this is a thing that I want to work on and believe should exist?

+ +

BENJIE: That's a great question. I actually am also a developer; that’s my background. And throughout the course of my career, I've always been on the technical side of the company. And what that's translated to, because of passion, to be honest, is always taking on a DevOps type role, so throughout the course of my career, a lot of responsibility.

+ +

I mean, I started off writing Bash scripts, went to Puppet, did Chef for a while, did Ansible. Somehow I went back to Bash scripts for a lot of this stuff. Then this company called DoCloud popped up, which obviously became Docker, and I kind of got obsessed with that. And then I had a bunch of friends at Google, and they were telling me about this creepy thing called Borg, and that became Kubernetes. And so, my career has kind of happened throughout that entire process. And throughout, DevOps has kind of been my passion.

+ +

Along with my co-founder, Peter, I was a high-priced Kubernetes consultant in the New York ecosystem just a few years ago. And a lot of companies were trying to make the transition to Kubernetes. And Peter and myself came in and helped people that were struggling to find DevOps resources. And what that always kind of looked like was there was some bespoke version of a deployment system that was perfect for the person that wrote it. But obviously, it wasn't good enough for me and Peter, for Peter and myself.

+ +

CHAD: [laughs]

+ +

BENJIE: And so we would rewrite it, and it would be great. But then, eventually, we'd move on, and someone else would rewrite it. And there were a few instances where we ended up going back to companies and just reimplementing what we had already done. And throughout that process of being this consultant, we kept running into this ephemeral environment thing and building the same tooling over and over and over again.

+ +

So Peter and I, on a weekend, kind of got, "Oh, let's make a tool for ourselves." So we did that. And we made this exoskeleton to help our consulting business. And as things progressed, we kept just adding features, and it was really fun, and it was great. And then some of our customers or clients saw that. And they were like, "Hey, can we click that button?" And we were like, "I guess."

+ +

And so slowly, it turned into a product that was very duct tape-y and glued together, but it worked great. And to be frank, I had been through the VC process on the technical side in the past and didn't want to go through that again, the hamster wheel of need to raise more and more money and so very, very averse. And was very set on a really nice lifestyle consulting business, and hell was going to have to freeze over for us to take any VC dollars.

+ +

And then I don't know if you heard, but in March of 2020, hell froze over, and [laughter] there was a little pandemic. And at the same time, we got some pre-emptive term sheets, yadda, yadda, yadda. Next thing you know, we're a funded company building out a really cool product. So that's the origin story of where Shipyard came from.

+ +

CHAD: Really cool. I definitely want to come back to what building the product for you has been like, and the funding, and where you go from here. But let's come back to the product itself. As a developer, my normal workflow is I'm working locally. I'm able to run the application that I'm working on locally here on my computer. I put up a pull request on GitHub. I ask my team to review it.

+ +

Once it gets reviewed from a code perspective or a design perspective and gets a thumbs up, I merge it back into the main branch. And I deploy it to a staging server, at which point I would ask my stakeholder, my client, whatever, "Hey, this thing you're expecting it's on the staging server for you to check out." And everyone else on the team is doing the same thing. So where does Shipyard come in, and why is it better than that?

+ +

BENJIE: So where Shipyard comes in, it's after the local development but before you get to staging or really before you get to production because, in practicality, a lot of people turn Shipyard into their staging servers. But what happens is through webhooks, we hook into your GitHub. And we see that there's a new commit that comes in. And we automatically build and deploy a fully ephemeral environment for that feature. And what that gets you is a few things.

+ +

One paradigm that we're seeing a lot of is when you make that PR, a lot of end-to-end test suites are being run automatically using Shipyard ephemeral environments. And what that gives you is, in some instances, before you even have a code review, you're passing the suite of tests. And what that gives you is you save a lot of time. If there's just a dumb migration error or some typo or something like that, you're not wasting human capital or human energy on those environments.

+ +

And the other instance there that gets really interesting is by bringing up these environments earlier on, product stakeholders and QA stakeholders can do their jobs earlier on in the process. And so you can avoid a lot of merge conflicts. So like, you merge something, and maybe there's an edge case that you hadn't tested for, and the code review didn't pick up. Well, all of a sudden, staging is broken. And some other team member that's using the same process you were now they're blocked. Or the client can't see that environment, and there's some other type of problem.

+ +

But really, we didn't invent this paradigm. This is what FAANG does. There's a reason why I can't remember the last time that Gmail itself a button broke, or there was bad CSS, or bad HTML, same thing with Facebook, same thing with Netflix. Obviously, we all know about –-

+ +

CHAD: There's the obvious DNS outages.

+ +

BENJIE: [laughs] Right. I was going to say we all know about AWS, especially in December of 2021. That was a tough month. But yeah, from a UI/UX and controllable release perspective, this greatly increases your internal stakeholders’ ability to get their hands on features earlier, find problems, and then get those back to developers.

+ +

And the other thing, and maybe this is a question for you. But have you ever been in a situation where you built something, and it doesn't actually get reviewed for a few weeks? And then there is a bug, and you have to go back, and context switch off of what you're working on and go back and put a whole other mental model in place to go back and remember why did I use a switch statement here? That's a bad example but something to that effect.

+ +

CHAD: [laughs] Yeah. Well, I really try to avoid that scenario by having tight feedback loops, but sometimes it's unavoidable. It might be you finish something right before a holiday or going away or something like that; that can happen. So it's happened to me before, yeah.

+ +

BENJIE: Right. And how do you get your product people or your UAT teams...when do they get to touch the feature that you're working on?

+ +

CHAD: It's usually not until after a code review when it's been merged into main and deployed to staging.

+ +

BENJIE: So that's kind of how we make that feedback loop tighter. And what we've seen in practice actually is a lot faster, more reliable releases. And there's a significant increase in the cadence of releases that can happen and a higher quality of those releases.

+ +

CHAD: You mentioned that some customers end up even getting rid of staging. And so that's really exciting and interesting to me. When they do that, what does the overall picture look like? Is the code merge manual? Or do you have customers that are doing continuous deployment off of a thumbs up from the person reviewing it in the ephemeral environment and getting that automatically merged, and then maybe canary deploy or something to production?

+ +

BENJIE: Yeah, that's a great question. The thing to keep in mind here is that the majority of our customers are larger, and they have bigger teams because obviously, this is a collaboration platform ultimately. And so there's more value for the more complex teams and more stakeholders. So we don't have anybody at this moment that I know of; there could be, doing LGTM is good enough. So there's always a manual component.

+ +

But what it looks like from a staging perspective is that your main branch is actually ostensibly your staging environment, and so all the ephemeral environments are sort of dev environments that are shareable. And then when you merge because a code review passes, and QA checks, and UAT, then it gets automatically built into the main branch and the main environment. And then some people do QA. They'll final pass a QA or a final end-to-end test there. And then there's also a manual promotion to production as well. That's the typical pattern we've seen.

+ +

CHAD: Cool. One of the things that when I've used...sometimes a problem even with staging. But when I've used or been on projects with some ephemeral environments, getting good data in those environments can sometimes be a challenge. Is that something that Shipyard helps with? Or what's your recommended approach to that problem?

+ +

BENJIE: So that was one of the biggest problems we had early on. We put a lot of work into that. We apply the same git branch model to data. So the way that we do that is basically if you...oh, by the way, I forgot to mention something. We use Docker Compose as our application definition. So we extrapolate from Docker Compose and transpile into best practice Kubernetes YAMLs. So there is a little bit of inferring and magic we do in certain places. And one of the places we do that is if you have a named volume...sorry, am I getting too technical, or is this --?

+ +

CHAD: Not for me. And in fact, I have follow-up questions about [laughs] why you have that approach of converting.

+ +

BENJIE: We will dive into that in a second. And I have a whole bunch of redhead friends that make fun of me about Compose all the time, but I stick to my guns on that one. But I'm happy to talk about that. At high level, if you indicate to Shipyard this is a persistent volume that we want to make sure that child environments get, then we will do an instant snapshot. And we will actually provide that to the generated child ephemeral environment. And ostensibly, what that does is it allows you to test data migrations as well on these ephemeral environments.

+ +

Now, to go back to your initial question, we encourage...and we're working on some partnerships actually with some interesting companies. But we encourage people to specifically have their main data set on main be ostensibly a copy of whatever the good data set is. But obviously, you're responsible for pulling out your own PII and all the confidential stuff there. But the key thing here is you're maintaining one environment with the right data on it. And then all of the subsequent generated ephemeral environments inherit that and can then change that.

+ +

CHAD: Yeah, that's cool. That solves a real pain point that I've had in the past when trying to work this way.

+ +

BENJIE: One company that I think is really interesting around this space is Tonic.ai. And we're actually working on some stuff with them, I think. But we share an investor, so that's why I know them, for disclaimer purposes. But they're great. And they have some really cool tooling around mapping your database to PII and automatic detection of certain types of information that you don't want pushed into your staging servers and to your developers' hands. So that's one to check out, too, if you're looking for data help.

+ +

CHAD: Cool. So do you want to get back to this Docker question? Why that approach of converting the Docker Compose into YAML for Kubernetes?

+ +

BENJIE: So this is quite a controversial topic.

+ +

CHAD: [laughs]

+ +

BENJIE: But I will tell you where it came from. Hearkening back to our origin story, what we saw was we saw a pattern of a lot of companies going a little bit too all-in in Kubernetes; let’s just put it that way, where every single one of the developers is running minikube or even K3s or K3d or whatever. And all of a sudden, the DevOps people and the SRE people in the organization are spending most of their time supporting developers in local development environments.

+ +

So early on in that consulting game, we realized we don't want to do that. So if you want to work with us, we think you can use Docker Compose for most things. Now, that's obviously not always the case. There are some companies and applications that have hundreds of microservices. So obviously, Docker Compose is not a very realistic fit for those people. But the majority of people can pretty much encapsulate their application in Docker Compose. So that's one thing.

+ +

The other thing is I mentioned to you that I'm a DevOps engineer for years. I'm sick of new YAML formats or specifications. So I have a saying, "Not another YAML, I say nay." My co-founder, Peter, hates when I say that, but whatever, I like it.

+ +

CHAD: [laughs]

+ +

BENJIE: So that's another piece of this. And then the biggest thing here is that we look at Docker Compose as rabbit ears on a television set. So you know, like a 98-year-old grandmother can somehow stand on one foot and hold the antenna the right way, and it's static. The picture is perfect, and they can watch...I don't know why I'm saying Jay Leno. I don't think it's on the air anymore.

+ +

CHAD: [laughs]

+ +

BENJIE: Sticking with the grandma reference, humans are really good at figuring out stuff like that. [laughs] And that's kind of what Docker compose is. It's kind of like if you can make it work locally, Shipyard is going to take care of the rest and clean up a bunch of stuff for you. So that's how we look at it.

+ +

Admittedly, we do have some Helm stuff we're working on and some Kustomize (with a K) stuff. And there are a whole lot of other interesting things out there. But frankly, we haven't run into problems with our current approach. And when we have tried to ingest raw manifests and stuff like that, other issues tend to arise. So we use Compose as a funnel to be very opinionated about our Kubernetes deployments.

+ +

CHAD: Well, I'm a big believer in, especially in early days having opinions about things. And it sounds like, with this particular opinion, you not only can help people at different stages and say that "This is good enough," but you're also casting a wide net for what people can do. You're not cutting people off because they already use Kustomize or something like that.

+ +

BENJIE: Yeah. And a lot of it is about accessibility. And so it's proven to be a pretty interesting thing. We didn't think that we were going to go this far with it. [laughs] We really thought that we were going to get in trouble soon. But it's pretty cool how it's going.

+ +

And also, I will do a shout-out to the Docker Compose community. They're picking up some steam here. I think a lot of people are realizing that it's a pretty good spec for most use cases. So I know that Docker released somewhat recently you don't have to do Docker-Compose anymore. It's just Docker Compose. And there are all kinds of Compose specifications stuff that I think is worth checking out.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So to get a little bit meta for a minute, how do you use Shipyard on Shipyard?

+ +

BENJIE: The ultimate dog food. That is one of the biggest selling points to our own engineering team when recruiting. We've got a pretty spectacular team that comes from some pretty awesome companies. And people sometimes ask me, "Hey, how did you get these engineers?" And honestly, I think the answer is dogfooding. Because what we're building is what every DevOps engineer sets out to build every time they start their job, in my opinion.

+ +

You always want this ephemeral type of elastic environments are only on when you need them to be on. I didn't discuss this, but we also have functionality that we call SLV or Since Last Visit. So we know the last time someone went to one of these environments, and we'll turn it off for you. And then, obviously, it's very quick to turn it back on when needed. So there are cost savings. There are all kinds of stuff there.

+ +

But ultimately, we're building the ultimate DevOps tool. And so we use Shipyard to run Shipyard. We use it in our QA process. We use it in our end-to-end testing process. And we also use it in our production process as well. We have some of our...we do have a production offering, and we use that ourselves for our stuff. So it's a very recursive conversation around that.

+ +

And sometimes, when I'm actually doing a demo for various people, the only way to show or the only good demo I have of certain functionality is to actually show the Shipyard organization itself in Shipyard. And I get very recursively tied up, and people get confused. And it's always a bad idea.

+ +

CHAD: [laughs] Yeah, you have to queue the Inception music.

+ +

BENJIE: Yeah, exactly. We're at the third level. We're at the ice palace or whatever, ice hideout at this point. That's from the movie Inception for those that don't know what we're talking about.

+ +

CHAD: [laughs] Yeah, that's really cool. I imagine that...sometimes when I'm working on a project, and you get down to the instrumentation level, to those levels, it can be difficult to run the system on the system. Have there been particular challenges? It's not just a normal web app; I guess is the way of saying that. What Shipyard is isn't just a normal web app.

+ +

BENJIE: Yeah, one of the things that we do is that we have a pretty robust security posture, so every single one of our customers gets their own cluster. And so our security model is using the hypervisor basically, which, by the way, for anyone looking at Kubernetes, forget Shipyard for a second. Please understand that if you're in a shared namespace anything, our back is great, but don't do it. There's a CVE around on the corner, I promise you. Don't do it. Anyway.

+ +

CHAD: [laughs] That's a good PSA for people.

+ +

BENJIE: Yeah, right? [laughs] Yeah. So some of the cool challenges we've had is we early on, we definitely had some stuff where if we did a bad release, we would break our own ability to fix our own releases. So that was that way early on. We figured that one out very early. I think that was even before we were a product even. That was just a few sleepless nights of Peter and myself being like, oh God; we got to fix this so that we don't screw up this client's website. So that's been interesting. I mean, that was really it.

+ +

And my co-founder, Peter, is listening to this, and he's like, there are 4,000 different things I've fixed over the last few years that were a problem around this, and I can't bring them up. But there's a lot, and I don't know what they are. And Peter is very good at fixing them. So that speaks to my co-founder and the rest of the team.

+ +

CHAD: So you mentioned that March of 2020 happened, hell froze over. And you found yourself thinking you're going to take a different path and fundraise and become a funded company. How difficult did you find fundraising in that environment, or was it easy?

+ +

BENJIE: It was real tough at the beginning there. For one, I have no idea what I'm doing. [laughter] That's just the truth. Maybe I should say that in the past tense. I had no idea what I was doing. I still feel like I have no idea what I'm doing.

+ +

But like I said, I come from a technical side, and I'm a bit of an engineer. So if a VC asked me a question and the answer is yes, but I have to qualify it with some weird edge case that I came up with. That's not a great look for these types of pitch meetings. So I would suggest people not overengineer answers to questions, yes or no works very often. So it was challenging.

+ +

But also, at the time, I'll say that there was definitely some predatory term sheets going around because this was really early, and we had no idea. And I was a fool...I wasn't a fool, but I had no idea. We're running this consulting company, and I'm like, oh my God, all my customers are funded. They're all going to go away. We had some pretty large customers. It was very irrational looking back. But it was a crazy time. Also, I should mention that we're in New York. So things were heightened a lot more also in March of 2020. It was very intense, and so I had to learn a lot.

+ +

And basically, the realization like, oh, if the world becomes remote, software is just going to go crazy had not seeped into my brain quite yet in March or April. So did a lot of learning that way. We were very fortunate to have some really helpful people along that path and eventually figured it out.

+ +

I will say, funny story, I literally didn't have a pitch for three months. I would just do a demo and talk about stuff. And then a friend of mine was like, "Oh, what's your pitch?" And I was like, "I do a demo, and I talk about it." So he's like, "Dude, you got to have a pitch." So that helped a lot once I figured out [laughs] that I needed a pitch.

+ +

CHAD: It did help. So you recommend people have a pitch.

+ +

BENJIE: I would say that that is a positive, yes. Having a pitch is helpful. I know that that's a ridiculous statement here, but I literally didn't have...I just didn't think about what's my pitch?

+ +

CHAD: Well, I think it's simultaneously a ridiculous thing but also there exist in the world things that people do just because that's the way that they're done. And so it's valid, I think to say, "Do we really need that? Can we get by without it?" And if the lesson learned there is actually there's a reason why people do it and it is valuable, that's a valuable lesson. It's too bad you had to go through it to discover it.

+ +

BENJIE: Well, yeah. I look back fondly at that. And I wouldn't say I was being contrarian. I was just kind of being a jackass, frankly. But I learned a lot. And honestly, in the end, I couldn't be happier. I'm pretty anti-VC. Everyone knows that about me. I like to make fun of them and all these things. But I couldn't be happier with our investors, and they've been unbelievably supportive. And so that's been a super positive.

+ +

The one thing I would say to anyone listening to this podcast that has to go out and raise money is you got to get really good at letting things roll off your shoulder. As an engineer, it's really hard for me to deal with any level of rejection because I'm like, oh, it works, or it doesn't work. Oh, you found this edge case that I didn't think about? Oh, you got me, but I'll fix it now, and now it's fine. That's not the way that fundraising works.

+ +

You have certain conversations, and you feel super positive. And then, all of a sudden, you don't hear back from this person for weeks at a time. You have other conversations where you think that it was the worst thing that you've ever done. And the next day, you get a term sheet.

+ +

I had one pitch...this is when I knew how to do a pitch. This was a few months in. I had this one pitch, and it was all virtual, and it was very early days in our remote world. And there were four partners on this call and a few associates or whatever. And I do the pitch, but everyone is muted on Zoom for 45 minutes. Now, it's pretty clear from our conversation that I talk a lot. So it's not the end of the world. But I had no idea what was going on. And I just thought that I had bombed it. It was horrible, all these things.

+ +

And the next day, I got an email, and it was three introductions to amazing opportunities. And two of them actually panned out. We didn't end up going with that fund. But I just thought it was hilarious that I was convinced that I shouldn't be doing this, and it was the opposite. So you never know. That's the other thing I learned is you literally can never know what's going to come of any particular meeting in the VC fundraising world.

+ +

CHAD: So how long did it take you from the point that you decided you were going to do this and you were going to start trying to fundraise to actually getting the investment in the bank?

+ +

BENJIE: Probably four to six months. We obviously had some opportunities, but as we went through this process, realizing that having the right partner for the next 7 to 10 years was really important. And we ended up with our lead. I can't believe I'm talking positively about a VC on a podcast but whatever.

+ +

CHAD: [laughs]

+ +

BENJIE: Our lead, Owen Davis from Contour Venture...Contour is like this New York fund that they do everything, but no one knows their name. Oh, he's going to love that I said that but whatever.

+ +

CHAD: [laughs]

+ +

BENJIE: They're great. He's great. And he's the dream investor for us to lead. And then we have other...and I'll mention Shruti over at Array and the folks at Heavybit and Work-Bench as well. They're all in this round, and it all came together. And I was a little picky. So we kind of took our time. And I suggest that if you have that luxury, which we did because we already had a successful consulting business, make sure you know who you're getting into business with for sure. And we got very lucky with that.

+ +

CHAD: So how much time while you were fundraising did you personally work on that as opposed to other things for the product or the business?

+ +

BENJIE: I should have probably put a little bit more time to the fundraising. To be honest with you, I would say I probably put 50% to 60% of my energy into the fundraise, and then the 40% was all building product. As an engineer, you have a really frustrating call, or you think you're doing well, and then you're not, or vice versa. So for me, I would retreat into building. And so I probably retreated into building a little more than I should have to be frank, [laughs] but it worked out in the end.

+ +

CHAD: While you were doing that, you supported yourselves from the consulting revenue.

+ +

BENJIE: Yeah, for the most part. We still had active clients. So we converted most of those...actually all of those into Shipyard customers. And they were very supportive in that process, by the way, doing due diligence calls for us. They were all very helpful.

+ +

CHAD: And how did you decide how much money you should be seeking to raise?

+ +

BENJIE: Ultimately, that was something I struggle with just because I really want to know what I'm going to do and what the plan is. And one of the lessons that I've learned as a CEO now is your job is basically to make unbelievably important, critical decisions with little to no data and just hope you're making the right one and then adjust quickly if you're not. So understanding when you've made the wrong decision.

+ +

But ultimately, to answer your question, I built out a spreadsheet. I had a wish list of engineers that I knew or positions that we needed to fill, probably underestimated some of the product marketing needs that we would need to do. But built out a model and then figured, hey, how can we get there in 18 to 24 months to get to the next round?

+ +

Because you really do have to be making sure that you can...I mentioned the hamster wheel early on; maybe that's too negative of an analogy there. But you have to be thinking about your next round. And so you have to get to what metrics you want to hit. And you just work backwards from there.

+ +

CHAD: At what point along the way...you mentioned earlier that your customers tend to be larger companies. At what point along the way did you discover who your ideal customers were?

+ +

BENJIE: I think we're still discovering that. We're still figuring that out. But for me, this tool Shipyard, and I've seen it, if you start using a tool like Shipyard from day one, the gains and the benefits are just insane. We had one company that started off from scratch with us. And within two months, they had extremely robust software development lifecycle, production deploys, all kinds of stuff. And they've been going now for years...not years but a year a half or so with us and super successful.

+ +

So I always wanted to be like, oh, startup X with two engineers you should use us. And the more we talk to them, the more conversations we had. We're just like, this is not a DevOps priority. DevOps is not the priority.

+ +

CHAD: Especially in those early days, I feel like there's such a tendency, especially from engineers, to say, "Oh, that's not that complicated. I can do that," or "We don't really need that. Let's piece together this."

+ +

BENJIE: Yeah, that's exactly right. So then, as we started to talk more and more and understand what people were doing, we just fell into this ICP or Initial Customer Profile of more complex teams that are really facing these problems. I mean, specifically, when you get to a certain size, a bad release costs you a lot of money, customer success, customers that are leaving you, frustrated sales execs, frustrated product people, frustrated QA people. So it's when you get to these more complex levels is when you need this type of tooling.

+ +

Now, one thing Shipyard released actually very, very quietly, but you know, it's released. We released a 30-day free trial. It's kind of like our light tier, so people can start doing it. And we're starting to see some people at the earlier stage companies starting to do this, which is exciting to us. But our goal as a company is absolutely to figure out how to get this to the masses because ephemeral environments is the paradigm of the future. I mean, it's the paradigm of the present with the big tech companies. And it's now coming down to the rest of us.

+ +

And so instead of having to hire five DevOps people to build the system out for you for six months, you hire one DevOps person, and that DevOps person shifts into an SRE role, not entirely, but their concerns are more about reliability of the actual site rather than reliability for developer environments or QA environments or staging environments. So we think that's really powerful.

+ +

One thing that I probably should have mentioned way sooner is we have a community site that we've donated, and we're more than happy to have some pull requests come in. We've had a few. ephemeralenvironments.io, yeah, I don't know how to spell ephemeral either, but you can Google it. It will come up.

+ +

CHAD: [laughs]

+ +

BENJIE: ephemeralenvironments.io, and it goes through the different use cases of ephemeral environments and where there's value there. So that's kind of the goal with all this.

+ +

CHAD: So what are you working on now? And what is the next stage for the company, I guess also from a product perspective? But also, you mentioned that hamster wheel. [laughter] You're coming up on 18 months of being on that wheel, right?

+ +

BENJIE: We are. One thing is we've had some success, so our revenue is pretty solid, but no rest for the weary. But we're probably going to go out and bring in some more capital pretty soon. And the reason for that, because that's always the important thing to me, is that we have some pretty spectacular design partners, some pretty big logos, all these things.

+ +

The product is there. The product is killing it. I couldn't be more proud of the product and the team. We've also started to build out the core team and couldn't be more proud of that. And so now we need to accelerate and figure out our next steps and how to bring this to the masses.

+ +

And ultimately, the vision of Shipyard is to make all this stuff move a lot faster, bring velocity to teams, and all that stuff. And we believe that ephemeral environments are a huge component of that. So we're probably in the next few months going to probably go out and look at our financing options. I will say that the market has been a little insane. So I feel like all the education that I got in 2022 is probably out the window because some of these valuations and other stuff seems like it's a frothy market, as they say, but we'll be doing that.

+ +

And we're really going to probably double down on figuring out what the community needs and where the value is for the community, so both with ephemeralenvironments.io. But also, there are some really cool internal tools that we've built that solve some of the issues within the Kubernetes ecosystem. Okay, that's a strong word. They help a lot. I'm never going to say I've solved anything in Kubernetes.

+ +

CHAD: [laughs]

+ +

BENJIE: But they help a lot with understanding why the state of your application is maybe not where you want it to be. And so, we'd like to probably contribute a bit more back to CNCF, in particular, but open source in general. So continue to build the team to work on that. And then, obviously, pushing forward with product and some pretty cool stuff we have on the roadmap that we're really excited about.

+ +

CHAD: Awesome. Well, I wish you all the best with that. If folks want to find out more about Shipyard, follow along with you, get in touch; where are the best places for them to do that?

+ +

BENJIE: Really, shipyard.build is our website. And that is probably the best place to try it and also to contact us. Our Twitter is @shipyardbuild twitter.com/shipyardbuild. Personally, I'm not a fan of Twitter. So I personally don't use Twitter, but we do as a company. And I think that our Twitter and our website are probably the best things to reach out to, and obviously, sales@shipyard.build you can send an email there. But I think you'll probably find the information you're looking for on the website. And if not, please let us know what's missing.

+ +

CHAD: And you mentioned the free trial. So I feel like that's a great thing for people who want to get more into the product; they can give it a try, right?

+ +

BENJIE: Yeah. And one thing to note about the free trial the reason that it's kind of cool is it's your own cluster. You get your own cluster. It's completely single tenant. It's pretty dope. It's pretty cool. And you can really take it for a spin. I would suggest, I mean, we've had a lot of success with companies that are using Docker Compose already to just dive in there and get their application running.

+ +

But I would say that we have some pretty cool starter apps as well. They're linked in our docs and our GitHub. Just seeing the power of this through our starter applications has also been a great experience for a lot of people. So I'd suggest taking a look at that.

+ +

Oh, and I should plug a podcast that I'm a co-host of, Kubelist. I do that with Marc Campbell from Replicated, where we interview CNCF open-source projects all the time. That's why I got to be careful pretending like I'm solving anything. There are a lot of options in the Kubernetes landscape.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Benjie De Groot.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to Benjie De Groot, co-founder, and CEO of Shipyard. Shipyard manages, creates, builds, and deploys ephemeral environments.

+ +

Benjie talks about how Shipyard became a funded company, discovering who their ideal customers are, and building out the core team so Shipyard can accelerate and figure out their next steps in how to bring it to the masses.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel, and with me today is Benjie De Groot, co-founder, and CEO of Shipyard. Benjie, thanks for joining me.

+ +

BENJIE: Thanks for having me.

+ +

CHAD: Why don't we start by if you don't mind sharing a little bit about what Shipyard is and does?

+ +

BENJIE: Sure. At the core of what Shipyard is working on is ephemeral environments; not everybody knows what that means. That is changing a bit. But essentially, what we're focused on is on every pull request or commit for a feature; Shipyard manages, and creates, and builds, and deploys ephemeral environments. So that's a disposable one-off on-demand environment that any stakeholder in your internal company can use. And we focus on the tooling around that, on build pipeline, and then security around that. And then all kinds of other cool features that are necessary that pop up.

+ +

CHAD: Cool. So as a developer, I'm familiar with the concept of developing locally, putting up my pull requests. And also, we deploy a lot of stuff to Heroku. So I'm familiar with some of the infrastructure that Heroku might give. How did you arrive at saying like, this is a thing that I want to work on and believe should exist?

+ +

BENJIE: That's a great question. I actually am also a developer; that’s my background. And throughout the course of my career, I've always been on the technical side of the company. And what that's translated to, because of passion, to be honest, is always taking on a DevOps type role, so throughout the course of my career, a lot of responsibility.

+ +

I mean, I started off writing Bash scripts, went to Puppet, did Chef for a while, did Ansible. Somehow I went back to Bash scripts for a lot of this stuff. Then this company called DoCloud popped up, which obviously became Docker, and I kind of got obsessed with that. And then I had a bunch of friends at Google, and they were telling me about this creepy thing called Borg, and that became Kubernetes. And so, my career has kind of happened throughout that entire process. And throughout, DevOps has kind of been my passion.

+ +

Along with my co-founder, Peter, I was a high-priced Kubernetes consultant in the New York ecosystem just a few years ago. And a lot of companies were trying to make the transition to Kubernetes. And Peter and myself came in and helped people that were struggling to find DevOps resources. And what that always kind of looked like was there was some bespoke version of a deployment system that was perfect for the person that wrote it. But obviously, it wasn't good enough for me and Peter, for Peter and myself.

+ +

CHAD: [laughs]

+ +

BENJIE: And so we would rewrite it, and it would be great. But then, eventually, we'd move on, and someone else would rewrite it. And there were a few instances where we ended up going back to companies and just reimplementing what we had already done. And throughout that process of being this consultant, we kept running into this ephemeral environment thing and building the same tooling over and over and over again.

+ +

So Peter and I, on a weekend, kind of got, "Oh, let's make a tool for ourselves." So we did that. And we made this exoskeleton to help our consulting business. And as things progressed, we kept just adding features, and it was really fun, and it was great. And then some of our customers or clients saw that. And they were like, "Hey, can we click that button?" And we were like, "I guess."

+ +

And so slowly, it turned into a product that was very duct tape-y and glued together, but it worked great. And to be frank, I had been through the VC process on the technical side in the past and didn't want to go through that again, the hamster wheel of need to raise more and more money and so very, very averse. And was very set on a really nice lifestyle consulting business, and hell was going to have to freeze over for us to take any VC dollars.

+ +

And then I don't know if you heard, but in March of 2020, hell froze over, and [laughter] there was a little pandemic. And at the same time, we got some pre-emptive term sheets, yadda, yadda, yadda. Next thing you know, we're a funded company building out a really cool product. So that's the origin story of where Shipyard came from.

+ +

CHAD: Really cool. I definitely want to come back to what building the product for you has been like, and the funding, and where you go from here. But let's come back to the product itself. As a developer, my normal workflow is I'm working locally. I'm able to run the application that I'm working on locally here on my computer. I put up a pull request on GitHub. I ask my team to review it.

+ +

Once it gets reviewed from a code perspective or a design perspective and gets a thumbs up, I merge it back into the main branch. And I deploy it to a staging server, at which point I would ask my stakeholder, my client, whatever, "Hey, this thing you're expecting it's on the staging server for you to check out." And everyone else on the team is doing the same thing. So where does Shipyard come in, and why is it better than that?

+ +

BENJIE: So where Shipyard comes in, it's after the local development but before you get to staging or really before you get to production because, in practicality, a lot of people turn Shipyard into their staging servers. But what happens is through webhooks, we hook into your GitHub. And we see that there's a new commit that comes in. And we automatically build and deploy a fully ephemeral environment for that feature. And what that gets you is a few things.

+ +

One paradigm that we're seeing a lot of is when you make that PR, a lot of end-to-end test suites are being run automatically using Shipyard ephemeral environments. And what that gives you is, in some instances, before you even have a code review, you're passing the suite of tests. And what that gives you is you save a lot of time. If there's just a dumb migration error or some typo or something like that, you're not wasting human capital or human energy on those environments.

+ +

And the other instance there that gets really interesting is by bringing up these environments earlier on, product stakeholders and QA stakeholders can do their jobs earlier on in the process. And so you can avoid a lot of merge conflicts. So like, you merge something, and maybe there's an edge case that you hadn't tested for, and the code review didn't pick up. Well, all of a sudden, staging is broken. And some other team member that's using the same process you were now they're blocked. Or the client can't see that environment, and there's some other type of problem.

+ +

But really, we didn't invent this paradigm. This is what FAANG does. There's a reason why I can't remember the last time that Gmail itself a button broke, or there was bad CSS, or bad HTML, same thing with Facebook, same thing with Netflix. Obviously, we all know about –-

+ +

CHAD: There's the obvious DNS outages.

+ +

BENJIE: [laughs] Right. I was going to say we all know about AWS, especially in December of 2021. That was a tough month. But yeah, from a UI/UX and controllable release perspective, this greatly increases your internal stakeholders’ ability to get their hands on features earlier, find problems, and then get those back to developers.

+ +

And the other thing, and maybe this is a question for you. But have you ever been in a situation where you built something, and it doesn't actually get reviewed for a few weeks? And then there is a bug, and you have to go back, and context switch off of what you're working on and go back and put a whole other mental model in place to go back and remember why did I use a switch statement here? That's a bad example but something to that effect.

+ +

CHAD: [laughs] Yeah. Well, I really try to avoid that scenario by having tight feedback loops, but sometimes it's unavoidable. It might be you finish something right before a holiday or going away or something like that; that can happen. So it's happened to me before, yeah.

+ +

BENJIE: Right. And how do you get your product people or your UAT teams...when do they get to touch the feature that you're working on?

+ +

CHAD: It's usually not until after a code review when it's been merged into main and deployed to staging.

+ +

BENJIE: So that's kind of how we make that feedback loop tighter. And what we've seen in practice actually is a lot faster, more reliable releases. And there's a significant increase in the cadence of releases that can happen and a higher quality of those releases.

+ +

CHAD: You mentioned that some customers end up even getting rid of staging. And so that's really exciting and interesting to me. When they do that, what does the overall picture look like? Is the code merge manual? Or do you have customers that are doing continuous deployment off of a thumbs up from the person reviewing it in the ephemeral environment and getting that automatically merged, and then maybe canary deploy or something to production?

+ +

BENJIE: Yeah, that's a great question. The thing to keep in mind here is that the majority of our customers are larger, and they have bigger teams because obviously, this is a collaboration platform ultimately. And so there's more value for the more complex teams and more stakeholders. So we don't have anybody at this moment that I know of; there could be, doing LGTM is good enough. So there's always a manual component.

+ +

But what it looks like from a staging perspective is that your main branch is actually ostensibly your staging environment, and so all the ephemeral environments are sort of dev environments that are shareable. And then when you merge because a code review passes, and QA checks, and UAT, then it gets automatically built into the main branch and the main environment. And then some people do QA. They'll final pass a QA or a final end-to-end test there. And then there's also a manual promotion to production as well. That's the typical pattern we've seen.

+ +

CHAD: Cool. One of the things that when I've used...sometimes a problem even with staging. But when I've used or been on projects with some ephemeral environments, getting good data in those environments can sometimes be a challenge. Is that something that Shipyard helps with? Or what's your recommended approach to that problem?

+ +

BENJIE: So that was one of the biggest problems we had early on. We put a lot of work into that. We apply the same git branch model to data. So the way that we do that is basically if you...oh, by the way, I forgot to mention something. We use Docker Compose as our application definition. So we extrapolate from Docker Compose and transpile into best practice Kubernetes YAMLs. So there is a little bit of inferring and magic we do in certain places. And one of the places we do that is if you have a named volume...sorry, am I getting too technical, or is this --?

+ +

CHAD: Not for me. And in fact, I have follow-up questions about [laughs] why you have that approach of converting.

+ +

BENJIE: We will dive into that in a second. And I have a whole bunch of redhead friends that make fun of me about Compose all the time, but I stick to my guns on that one. But I'm happy to talk about that. At high level, if you indicate to Shipyard this is a persistent volume that we want to make sure that child environments get, then we will do an instant snapshot. And we will actually provide that to the generated child ephemeral environment. And ostensibly, what that does is it allows you to test data migrations as well on these ephemeral environments.

+ +

Now, to go back to your initial question, we encourage...and we're working on some partnerships actually with some interesting companies. But we encourage people to specifically have their main data set on main be ostensibly a copy of whatever the good data set is. But obviously, you're responsible for pulling out your own PII and all the confidential stuff there. But the key thing here is you're maintaining one environment with the right data on it. And then all of the subsequent generated ephemeral environments inherit that and can then change that.

+ +

CHAD: Yeah, that's cool. That solves a real pain point that I've had in the past when trying to work this way.

+ +

BENJIE: One company that I think is really interesting around this space is Tonic.ai. And we're actually working on some stuff with them, I think. But we share an investor, so that's why I know them, for disclaimer purposes. But they're great. And they have some really cool tooling around mapping your database to PII and automatic detection of certain types of information that you don't want pushed into your staging servers and to your developers' hands. So that's one to check out, too, if you're looking for data help.

+ +

CHAD: Cool. So do you want to get back to this Docker question? Why that approach of converting the Docker Compose into YAML for Kubernetes?

+ +

BENJIE: So this is quite a controversial topic.

+ +

CHAD: [laughs]

+ +

BENJIE: But I will tell you where it came from. Hearkening back to our origin story, what we saw was we saw a pattern of a lot of companies going a little bit too all-in in Kubernetes; let’s just put it that way, where every single one of the developers is running minikube or even K3s or K3d or whatever. And all of a sudden, the DevOps people and the SRE people in the organization are spending most of their time supporting developers in local development environments.

+ +

So early on in that consulting game, we realized we don't want to do that. So if you want to work with us, we think you can use Docker Compose for most things. Now, that's obviously not always the case. There are some companies and applications that have hundreds of microservices. So obviously, Docker Compose is not a very realistic fit for those people. But the majority of people can pretty much encapsulate their application in Docker Compose. So that's one thing.

+ +

The other thing is I mentioned to you that I'm a DevOps engineer for years. I'm sick of new YAML formats or specifications. So I have a saying, "Not another YAML, I say nay." My co-founder, Peter, hates when I say that, but whatever, I like it.

+ +

CHAD: [laughs]

+ +

BENJIE: So that's another piece of this. And then the biggest thing here is that we look at Docker Compose as rabbit ears on a television set. So you know, like a 98-year-old grandmother can somehow stand on one foot and hold the antenna the right way, and it's static. The picture is perfect, and they can watch...I don't know why I'm saying Jay Leno. I don't think it's on the air anymore.

+ +

CHAD: [laughs]

+ +

BENJIE: Sticking with the grandma reference, humans are really good at figuring out stuff like that. [laughs] And that's kind of what Docker compose is. It's kind of like if you can make it work locally, Shipyard is going to take care of the rest and clean up a bunch of stuff for you. So that's how we look at it.

+ +

Admittedly, we do have some Helm stuff we're working on and some Kustomize (with a K) stuff. And there are a whole lot of other interesting things out there. But frankly, we haven't run into problems with our current approach. And when we have tried to ingest raw manifests and stuff like that, other issues tend to arise. So we use Compose as a funnel to be very opinionated about our Kubernetes deployments.

+ +

CHAD: Well, I'm a big believer in, especially in early days having opinions about things. And it sounds like, with this particular opinion, you not only can help people at different stages and say that "This is good enough," but you're also casting a wide net for what people can do. You're not cutting people off because they already use Kustomize or something like that.

+ +

BENJIE: Yeah. And a lot of it is about accessibility. And so it's proven to be a pretty interesting thing. We didn't think that we were going to go this far with it. [laughs] We really thought that we were going to get in trouble soon. But it's pretty cool how it's going.

+ +

And also, I will do a shout-out to the Docker Compose community. They're picking up some steam here. I think a lot of people are realizing that it's a pretty good spec for most use cases. So I know that Docker released somewhat recently you don't have to do Docker-Compose anymore. It's just Docker Compose. And there are all kinds of Compose specifications stuff that I think is worth checking out.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So to get a little bit meta for a minute, how do you use Shipyard on Shipyard?

+ +

BENJIE: The ultimate dog food. That is one of the biggest selling points to our own engineering team when recruiting. We've got a pretty spectacular team that comes from some pretty awesome companies. And people sometimes ask me, "Hey, how did you get these engineers?" And honestly, I think the answer is dogfooding. Because what we're building is what every DevOps engineer sets out to build every time they start their job, in my opinion.

+ +

You always want this ephemeral type of elastic environments are only on when you need them to be on. I didn't discuss this, but we also have functionality that we call SLV or Since Last Visit. So we know the last time someone went to one of these environments, and we'll turn it off for you. And then, obviously, it's very quick to turn it back on when needed. So there are cost savings. There are all kinds of stuff there.

+ +

But ultimately, we're building the ultimate DevOps tool. And so we use Shipyard to run Shipyard. We use it in our QA process. We use it in our end-to-end testing process. And we also use it in our production process as well. We have some of our...we do have a production offering, and we use that ourselves for our stuff. So it's a very recursive conversation around that.

+ +

And sometimes, when I'm actually doing a demo for various people, the only way to show or the only good demo I have of certain functionality is to actually show the Shipyard organization itself in Shipyard. And I get very recursively tied up, and people get confused. And it's always a bad idea.

+ +

CHAD: [laughs] Yeah, you have to queue the Inception music.

+ +

BENJIE: Yeah, exactly. We're at the third level. We're at the ice palace or whatever, ice hideout at this point. That's from the movie Inception for those that don't know what we're talking about.

+ +

CHAD: [laughs] Yeah, that's really cool. I imagine that...sometimes when I'm working on a project, and you get down to the instrumentation level, to those levels, it can be difficult to run the system on the system. Have there been particular challenges? It's not just a normal web app; I guess is the way of saying that. What Shipyard is isn't just a normal web app.

+ +

BENJIE: Yeah, one of the things that we do is that we have a pretty robust security posture, so every single one of our customers gets their own cluster. And so our security model is using the hypervisor basically, which, by the way, for anyone looking at Kubernetes, forget Shipyard for a second. Please understand that if you're in a shared namespace anything, our back is great, but don't do it. There's a CVE around on the corner, I promise you. Don't do it. Anyway.

+ +

CHAD: [laughs] That's a good PSA for people.

+ +

BENJIE: Yeah, right? [laughs] Yeah. So some of the cool challenges we've had is we early on, we definitely had some stuff where if we did a bad release, we would break our own ability to fix our own releases. So that was that way early on. We figured that one out very early. I think that was even before we were a product even. That was just a few sleepless nights of Peter and myself being like, oh God; we got to fix this so that we don't screw up this client's website. So that's been interesting. I mean, that was really it.

+ +

And my co-founder, Peter, is listening to this, and he's like, there are 4,000 different things I've fixed over the last few years that were a problem around this, and I can't bring them up. But there's a lot, and I don't know what they are. And Peter is very good at fixing them. So that speaks to my co-founder and the rest of the team.

+ +

CHAD: So you mentioned that March of 2020 happened, hell froze over. And you found yourself thinking you're going to take a different path and fundraise and become a funded company. How difficult did you find fundraising in that environment, or was it easy?

+ +

BENJIE: It was real tough at the beginning there. For one, I have no idea what I'm doing. [laughter] That's just the truth. Maybe I should say that in the past tense. I had no idea what I was doing. I still feel like I have no idea what I'm doing.

+ +

But like I said, I come from a technical side, and I'm a bit of an engineer. So if a VC asked me a question and the answer is yes, but I have to qualify it with some weird edge case that I came up with. That's not a great look for these types of pitch meetings. So I would suggest people not overengineer answers to questions, yes or no works very often. So it was challenging.

+ +

But also, at the time, I'll say that there was definitely some predatory term sheets going around because this was really early, and we had no idea. And I was a fool...I wasn't a fool, but I had no idea. We're running this consulting company, and I'm like, oh my God, all my customers are funded. They're all going to go away. We had some pretty large customers. It was very irrational looking back. But it was a crazy time. Also, I should mention that we're in New York. So things were heightened a lot more also in March of 2020. It was very intense, and so I had to learn a lot.

+ +

And basically, the realization like, oh, if the world becomes remote, software is just going to go crazy had not seeped into my brain quite yet in March or April. So did a lot of learning that way. We were very fortunate to have some really helpful people along that path and eventually figured it out.

+ +

I will say, funny story, I literally didn't have a pitch for three months. I would just do a demo and talk about stuff. And then a friend of mine was like, "Oh, what's your pitch?" And I was like, "I do a demo, and I talk about it." So he's like, "Dude, you got to have a pitch." So that helped a lot once I figured out [laughs] that I needed a pitch.

+ +

CHAD: It did help. So you recommend people have a pitch.

+ +

BENJIE: I would say that that is a positive, yes. Having a pitch is helpful. I know that that's a ridiculous statement here, but I literally didn't have...I just didn't think about what's my pitch?

+ +

CHAD: Well, I think it's simultaneously a ridiculous thing but also there exist in the world things that people do just because that's the way that they're done. And so it's valid, I think to say, "Do we really need that? Can we get by without it?" And if the lesson learned there is actually there's a reason why people do it and it is valuable, that's a valuable lesson. It's too bad you had to go through it to discover it.

+ +

BENJIE: Well, yeah. I look back fondly at that. And I wouldn't say I was being contrarian. I was just kind of being a jackass, frankly. But I learned a lot. And honestly, in the end, I couldn't be happier. I'm pretty anti-VC. Everyone knows that about me. I like to make fun of them and all these things. But I couldn't be happier with our investors, and they've been unbelievably supportive. And so that's been a super positive.

+ +

The one thing I would say to anyone listening to this podcast that has to go out and raise money is you got to get really good at letting things roll off your shoulder. As an engineer, it's really hard for me to deal with any level of rejection because I'm like, oh, it works, or it doesn't work. Oh, you found this edge case that I didn't think about? Oh, you got me, but I'll fix it now, and now it's fine. That's not the way that fundraising works.

+ +

You have certain conversations, and you feel super positive. And then, all of a sudden, you don't hear back from this person for weeks at a time. You have other conversations where you think that it was the worst thing that you've ever done. And the next day, you get a term sheet.

+ +

I had one pitch...this is when I knew how to do a pitch. This was a few months in. I had this one pitch, and it was all virtual, and it was very early days in our remote world. And there were four partners on this call and a few associates or whatever. And I do the pitch, but everyone is muted on Zoom for 45 minutes. Now, it's pretty clear from our conversation that I talk a lot. So it's not the end of the world. But I had no idea what was going on. And I just thought that I had bombed it. It was horrible, all these things.

+ +

And the next day, I got an email, and it was three introductions to amazing opportunities. And two of them actually panned out. We didn't end up going with that fund. But I just thought it was hilarious that I was convinced that I shouldn't be doing this, and it was the opposite. So you never know. That's the other thing I learned is you literally can never know what's going to come of any particular meeting in the VC fundraising world.

+ +

CHAD: So how long did it take you from the point that you decided you were going to do this and you were going to start trying to fundraise to actually getting the investment in the bank?

+ +

BENJIE: Probably four to six months. We obviously had some opportunities, but as we went through this process, realizing that having the right partner for the next 7 to 10 years was really important. And we ended up with our lead. I can't believe I'm talking positively about a VC on a podcast but whatever.

+ +

CHAD: [laughs]

+ +

BENJIE: Our lead, Owen Davis from Contour Venture...Contour is like this New York fund that they do everything, but no one knows their name. Oh, he's going to love that I said that but whatever.

+ +

CHAD: [laughs]

+ +

BENJIE: They're great. He's great. And he's the dream investor for us to lead. And then we have other...and I'll mention Shruti over at Array and the folks at Heavybit and Work-Bench as well. They're all in this round, and it all came together. And I was a little picky. So we kind of took our time. And I suggest that if you have that luxury, which we did because we already had a successful consulting business, make sure you know who you're getting into business with for sure. And we got very lucky with that.

+ +

CHAD: So how much time while you were fundraising did you personally work on that as opposed to other things for the product or the business?

+ +

BENJIE: I should have probably put a little bit more time to the fundraising. To be honest with you, I would say I probably put 50% to 60% of my energy into the fundraise, and then the 40% was all building product. As an engineer, you have a really frustrating call, or you think you're doing well, and then you're not, or vice versa. So for me, I would retreat into building. And so I probably retreated into building a little more than I should have to be frank, [laughs] but it worked out in the end.

+ +

CHAD: While you were doing that, you supported yourselves from the consulting revenue.

+ +

BENJIE: Yeah, for the most part. We still had active clients. So we converted most of those...actually all of those into Shipyard customers. And they were very supportive in that process, by the way, doing due diligence calls for us. They were all very helpful.

+ +

CHAD: And how did you decide how much money you should be seeking to raise?

+ +

BENJIE: Ultimately, that was something I struggle with just because I really want to know what I'm going to do and what the plan is. And one of the lessons that I've learned as a CEO now is your job is basically to make unbelievably important, critical decisions with little to no data and just hope you're making the right one and then adjust quickly if you're not. So understanding when you've made the wrong decision.

+ +

But ultimately, to answer your question, I built out a spreadsheet. I had a wish list of engineers that I knew or positions that we needed to fill, probably underestimated some of the product marketing needs that we would need to do. But built out a model and then figured, hey, how can we get there in 18 to 24 months to get to the next round?

+ +

Because you really do have to be making sure that you can...I mentioned the hamster wheel early on; maybe that's too negative of an analogy there. But you have to be thinking about your next round. And so you have to get to what metrics you want to hit. And you just work backwards from there.

+ +

CHAD: At what point along the way...you mentioned earlier that your customers tend to be larger companies. At what point along the way did you discover who your ideal customers were?

+ +

BENJIE: I think we're still discovering that. We're still figuring that out. But for me, this tool Shipyard, and I've seen it, if you start using a tool like Shipyard from day one, the gains and the benefits are just insane. We had one company that started off from scratch with us. And within two months, they had extremely robust software development lifecycle, production deploys, all kinds of stuff. And they've been going now for years...not years but a year a half or so with us and super successful.

+ +

So I always wanted to be like, oh, startup X with two engineers you should use us. And the more we talk to them, the more conversations we had. We're just like, this is not a DevOps priority. DevOps is not the priority.

+ +

CHAD: Especially in those early days, I feel like there's such a tendency, especially from engineers, to say, "Oh, that's not that complicated. I can do that," or "We don't really need that. Let's piece together this."

+ +

BENJIE: Yeah, that's exactly right. So then, as we started to talk more and more and understand what people were doing, we just fell into this ICP or Initial Customer Profile of more complex teams that are really facing these problems. I mean, specifically, when you get to a certain size, a bad release costs you a lot of money, customer success, customers that are leaving you, frustrated sales execs, frustrated product people, frustrated QA people. So it's when you get to these more complex levels is when you need this type of tooling.

+ +

Now, one thing Shipyard released actually very, very quietly, but you know, it's released. We released a 30-day free trial. It's kind of like our light tier, so people can start doing it. And we're starting to see some people at the earlier stage companies starting to do this, which is exciting to us. But our goal as a company is absolutely to figure out how to get this to the masses because ephemeral environments is the paradigm of the future. I mean, it's the paradigm of the present with the big tech companies. And it's now coming down to the rest of us.

+ +

And so instead of having to hire five DevOps people to build the system out for you for six months, you hire one DevOps person, and that DevOps person shifts into an SRE role, not entirely, but their concerns are more about reliability of the actual site rather than reliability for developer environments or QA environments or staging environments. So we think that's really powerful.

+ +

One thing that I probably should have mentioned way sooner is we have a community site that we've donated, and we're more than happy to have some pull requests come in. We've had a few. ephemeralenvironments.io, yeah, I don't know how to spell ephemeral either, but you can Google it. It will come up.

+ +

CHAD: [laughs]

+ +

BENJIE: ephemeralenvironments.io, and it goes through the different use cases of ephemeral environments and where there's value there. So that's kind of the goal with all this.

+ +

CHAD: So what are you working on now? And what is the next stage for the company, I guess also from a product perspective? But also, you mentioned that hamster wheel. [laughter] You're coming up on 18 months of being on that wheel, right?

+ +

BENJIE: We are. One thing is we've had some success, so our revenue is pretty solid, but no rest for the weary. But we're probably going to go out and bring in some more capital pretty soon. And the reason for that, because that's always the important thing to me, is that we have some pretty spectacular design partners, some pretty big logos, all these things.

+ +

The product is there. The product is killing it. I couldn't be more proud of the product and the team. We've also started to build out the core team and couldn't be more proud of that. And so now we need to accelerate and figure out our next steps and how to bring this to the masses.

+ +

And ultimately, the vision of Shipyard is to make all this stuff move a lot faster, bring velocity to teams, and all that stuff. And we believe that ephemeral environments are a huge component of that. So we're probably in the next few months going to probably go out and look at our financing options. I will say that the market has been a little insane. So I feel like all the education that I got in 2022 is probably out the window because some of these valuations and other stuff seems like it's a frothy market, as they say, but we'll be doing that.

+ +

And we're really going to probably double down on figuring out what the community needs and where the value is for the community, so both with ephemeralenvironments.io. But also, there are some really cool internal tools that we've built that solve some of the issues within the Kubernetes ecosystem. Okay, that's a strong word. They help a lot. I'm never going to say I've solved anything in Kubernetes.

+ +

CHAD: [laughs]

+ +

BENJIE: But they help a lot with understanding why the state of your application is maybe not where you want it to be. And so, we'd like to probably contribute a bit more back to CNCF, in particular, but open source in general. So continue to build the team to work on that. And then, obviously, pushing forward with product and some pretty cool stuff we have on the roadmap that we're really excited about.

+ +

CHAD: Awesome. Well, I wish you all the best with that. If folks want to find out more about Shipyard, follow along with you, get in touch; where are the best places for them to do that?

+ +

BENJIE: Really, shipyard.build is our website. And that is probably the best place to try it and also to contact us. Our Twitter is @shipyardbuild twitter.com/shipyardbuild. Personally, I'm not a fan of Twitter. So I personally don't use Twitter, but we do as a company. And I think that our Twitter and our website are probably the best things to reach out to, and obviously, sales@shipyard.build you can send an email there. But I think you'll probably find the information you're looking for on the website. And if not, please let us know what's missing.

+ +

CHAD: And you mentioned the free trial. So I feel like that's a great thing for people who want to get more into the product; they can give it a try, right?

+ +

BENJIE: Yeah. And one thing to note about the free trial the reason that it's kind of cool is it's your own cluster. You get your own cluster. It's completely single tenant. It's pretty dope. It's pretty cool. And you can really take it for a spin. I would suggest, I mean, we've had a lot of success with companies that are using Docker Compose already to just dive in there and get their application running.

+ +

But I would say that we have some pretty cool starter apps as well. They're linked in our docs and our GitHub. Just seeing the power of this through our starter applications has also been a great experience for a lot of people. So I'd suggest taking a look at that.

+ +

Oh, and I should plug a podcast that I'm a co-host of, Kubelist. I do that with Marc Campbell from Replicated, where we interview CNCF open-source projects all the time. That's why I got to be careful pretending like I'm solving anything. There are a lot of options in the Kubernetes landscape.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Benjie De Groot.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+gqfU-QgD + + ]]> + + Chad Pytel + Benjie De Groot + + + Assessment and Performance Metrics with Tiffany Shubert of Relias Healthcare + https://podcast.thoughtbot.com/407 + 2d905d11-039a-4bb4-82d7-4eb78156754f + Thu, 20 Jan 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Chad talks to Tiffany Shubert, Senior Product Manager at Relias Healthcare. Relias is an online healthcare education company. They develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides in multiple healthcare settings. They span the entire range from acute care hospital settings to in-home care to hospice. + +Tiffany talks about how her clinical skills apply really well to product management, defining who you're solving the problem for, being all about your end-user, and making sure they have an amazing experience with your product. + 43:23 + no + + + Chad talks to Tiffany Shubert, Senior Product Manager at Relias Healthcare. Relias is an online healthcare education company. They develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides in multiple healthcare settings. They span the entire range from acute care hospital settings to in-home care to hospice. +Tiffany talks about how her clinical skills apply really well to product management, defining who you're solving the problem for, being all about your end-user, and making sure they have an amazing experience with your product. +Relias Healthcare (https://reliashealthcare.com/) +Follow Tiffany on LinkedIn (https://www.linkedin.com/in/shubertconsulting/). +Follow Relias on Twitter (https://twitter.com/relias) or LinkedIn (https://www.linkedin.com/company/relias/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Tiffany Shubert, Senior Product Manager at Relias. Tiffany, thanks for joining me. +TIFFANY: Hey. Thanks so much, Chad. I'm really excited to be here. +CHAD: So, Tiffany, folks may not be familiar with what Relias is, although if you're in certain spaces, it's certainly a big name that you may have heard of. So why don't you start off by telling people a little bit about Relias? +TIFFANY: Sure. So Relias is an online healthcare education company. Relias is in many, many different settings. But the majority of what we do is we develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides. And we are in multiple healthcare settings. So we span the entire range from acute care hospital settings to in-home care to hospice. +CHAD: We do a lot of work with different clients in the healthcare space. And so many of them, without even me prompting, mention, "Oh, we use Relias." [chuckles] And it's remarkable to see. Is Relias the biggest provider of learning management software for the space? +TIFFANY: So, we are the biggest provider of compliance training in the skilled nursing space. And we are a big provider in all of the other spaces. And really, where Relias started was in this notion of compliance training which, for those who are not familiar, really could benefit from a lot of design. That is the kind of training that every single healthcare provider has to take in order to see a patient. So that's where you take your patient privacy training, your bloodborne pathogen training, all of those types of trainings. And that's where Relias really started and has grown from there. +CHAD: So, how long have you been at Relias? +TIFFANY: So I started, interesting, in the end of March 2020. [chuckles] So yeah, it has been my pandemic experience, so almost two years now. +CHAD: What brought you to Relias? +TIFFANY: So I was at an interesting juncture in my career. I'm a physical therapist by training, and I was in clinical practice for about 15 years. And I transitioned over actually through a very interesting pathway but working for some different startups that were creating different technologies around healthcare. And one of the startups I had been with had run the course. And I was looking for something more around education, which is my original passion. And when Relias actually found me, I didn't realize it was actually in my backyard. +CHAD: [laughs] +TIFFANY: What drew me to it was this ability at this space where we could be looking at education, especially for clinicians, not as what I would call a penance which is how it's looked at. Like, ugh, I have to take my online education, or I have to take my training. But more of a hey, how can we make education interesting and dynamic? And how can we really apply many of the concepts we know about design and about really developing excellent products to clinical education? Which was incredibly exciting to me. +CHAD: As you moved from someone practicing to product management in this space, did you do any formal learning or training in that, or did you just learn along the way? +TIFFANY: A combination. Really my original experience in product was working for a startup company that was developing a really innovative concept around creating a soft, light exoskeleton, and they needed a clinician on staff to really understand how bodies move and what kind of problems could be solved. +That position really evolved into being a director of user experience. And so that really entailed bringing our end users, who happened to be older adults, into the lab and having them really work side by side with the engineers who are creating the product. So I developed that whole program, validated it, expanded it. +And from there, I really realized, oh, my clinical skills actually apply really well to product management. But now I do need to get some more formal training. So I went through some of the different...I actually went through the CSPO certification program, and then I have also just continued doing some more formal training at Relias. +CHAD: I imagine that the industry itself experience being almost on the user side helps. But is it ever a hurdle that you need to overcome? +TIFFANY: I think when clinicians first get into industry, they make a lot of mistakes because they want to solve every single problem. Or they want to give their users every single opportunity or every single feature. +So, for example, if you sit down with a group of physical therapists, and if you say, "I'm going to build you an app for helping your patients with their home exercise program," every single physical therapist is going to give you a laundry list of 30 things that they want. And typically, where clinicians go in my role is they're like, "Okay, we're going to fix all 30 things." And really, it's that ability to narrow it down, narrow it down. +And to be honest, if you're a good clinician, it's the same thing. Patients usually come with multiple complaints, and you've got to figure out what that number one complaint is and what you can do to address it. So that's where I think it becomes a barrier is wanting to fix every single problem as opposed to being able to really winnow it down. But when you can winnow it down, it's very powerful. +CHAD: An extension of that that I've seen, which I think is one of the challenges in healthcare, is that there are a lot of edge cases. And in normal SaaS products like an e-commerce product or whatever, it's easier to say, "We're not going to solve that right now." +But in healthcare, every edge case is an actual person that you could be helping. And so it's a little bit harder to really get in the mindset of not solving every problem. Because especially if the space of healthcare that you're in is literally life and death, it can be difficult from a product perspective to say, "We're not going to solve that case." +TIFFANY: I completely agree. Those are just conversations that you have to have because you also have to look at if we spend all of this time solving all of these use cases or all of these edge cases, we're never going to have a product. +So then you got to pull back, and you got to go, what is going to have the biggest impact? Or what are the components across every single patient that we can address? Because there's always going to be some commonalities, not necessarily disease space, but in how we actually address that patient and manage that disease or manage that impairment. +It is a big trap that we fall into because you're right; healthcare provider training is you have to address everything. But the fact of the matter is that's not realistic. +CHAD: What are some other challenges that you encounter while creating products in the healthcare space? +TIFFANY: I think the biggest challenge is really defining who you're solving the problem for, and we run into this all the time. And this has become very clear to me lately that if you're working for a Facebook or a Google, you are all about your end-user. And it's all about making sure that that end-user has an amazing experience. +But in healthcare, you've got patients, you've got clinicians, you've got hospitals, you've got healthcare systems. You've got private insurance payers, and you've got Medicare. And all of those groups may be interacting with your product. And all of those groups have totally different use cases and totally different problems to solve. +So first of all, figuring out, like, who am I building this for? Who is going to pay for it? And where do those two things intersect? And that has been the biggest problem I have seen in innovation in this space over the last ten years has been, well, we're going to build this for the patient, and it's going to be amazing, and the insurance companies will just pay for it. That hasn't really panned out because nobody sat down and actually talked to the insurance companies and asked them what problems do they see happening that a product could solve? +And then the flip has happened too where they've gone to the insurance companies, and insurance companies have said, "Well, here are the problems," but then they've never talked to the patients. So it's getting that multifaceted perspective and then boiling it down to what truly is the problem we're going to solve? +CHAD: And the way I see it is that this problem is amped up in the healthcare space because there are so many stakeholders or people you're potentially building the product for. But it's a general problem too in enterprise software where basically the people making the buying decision are not the users necessarily or the people you're trying to help. +And any time where that's the case, you also run the risk of very difficult to build a good product because the people making the buying decisions aren't actually the ones who are going to be using it or don't have the same needs as the people that you're trying to help with the software. +TIFFANY: Exactly, exactly. So it takes a lot of time to sort all that out, and we rarely have that amount of time. I'd say one of the things that was so fascinating on the product that Relias and thoughtbot worked on was we had the time to go a little deeper and to really figure out...so the problem we were trying to solve is okay, we need a better tool. Physical therapists need a better tool to engage patients, specifically older adult patients. +And again, so we had the conversation with the clinicians, and they're like, "Oh, well, we want all of these exercises." But then we paused, and we said, "But really, what is your biggest clinical challenge?" And they all said, "Time. We don't have enough time." +So then we were able to pull back and not go, oh, this is not about making the best exercise program ever. This is about creating a product that actually solves the problem of time. If we can enhance efficiency, then clinicians will use it. They'll be happy with it, and we can take it from there. +Solving the problem of time is a totally different problem than we have to create a product that offers you 30,000 different exercises. It was just a really important lesson because then once we said time, then all of a sudden, we had clinician buy-in. +And then we also had an organization buy-in because the organization is going, "Absolutely. If you can save my clinicians 10 minutes, that's going to increase their productivity. That's going to give them more time with the patient. Or maybe we could even get so efficient that there are more opportunities to see more patients." So it's tricky to figure all that out. +CHAD: So how did we figure that out? What tools did we use to have those conversations with people? +TIFFANY: Yeah, there was a lot of really excellent discovery and meeting with a good variety of clinicians but all practicing in the same space. And that's one of the things I want to call out. When you look at healthcare, healthcare spans so many different settings. And there are not a lot of consistency or universal truths between settings. +And what I mean is someone who is seeing a patient in a home health setting is going to have a very different skill set than someone who is working with a professional sports team, same training, same title, totally different set of problems. So we were really, really clear that we had to really refine this problem and get a very specific type of therapist. +And we also wanted to get a specific...I'm going to just use home health just for an example. But okay, so let's make sure we get therapists who are working in rural settings, in-home health, and therapists who are working in urban settings in-home health because we wanted to make sure that we had a better understanding of the problems they were facing in these multiple settings. +From there, from that discovery, got really, really, really very strict on what consistencies we were seeing around the problems that the therapists were running into. And from there, we just really focused on what was going to give us the most bang for our buck. And the problem of time was super consistent. The questions really were not like, well, would an app save you time? The questions were really what are your biggest challenges right now? +CHAD: And did you do that in one on one interviews with them? +TIFFANY: Yeah, those were one on one interviews. Yes. Yeah. +CHAD: How do you, when you're doing it, collect the data from those interviews in a way that is conducive to analysis later on? +TIFFANY: So I've used a whole variety of tools. And we were very analog in this particular one. We were interviewing one person, but there were about four of us on the call, and everyone was taking notes. And then everybody was highlighting common themes. And I've used focus group analysis software as well, which is always really, really helpful. But in this particular, we were really just going analog, and it worked pretty well. +CHAD: And you were doing this without a prototype or anything like that yet, right? +TIFFANY: Correct, for the initial without a prototype. Yep. +CHAD: And so once you had that potential job to be done or value proposition, how did you go from that job to be done to a potential product? +TIFFANY: So from there, we did go ahead, and we prototyped, and we prototyped a workflow that seemed to make sense given what we had heard from our users and then also just with my clinical background. And then that prototype really was the trick because a lot of times in healthcare, when you are working with clinicians, some are tech-savvy, but there's a significant amount (And this isn't age-dependent, but this is younger and older.) that are not. +And so they really need a little bit of context to ground what their thoughts are and how they think you can solve them. So by getting that prototype in place and by letting the therapist really bounce around in there and see what was intuitive and what wasn't, that was the game-changer. And we could really see okay, here's our understanding of this. And whoops! Missed that one. [laughter] Oh, this all makes sense. +But you could see as therapists went through what they appreciated was that the user interface was super simple, super clean. They could easily find things. And even those who didn't have a lot of self-efficacy around technology really felt at the end of a 20-minute session I know how to use this, and I could see how this will save me time. All of that data really helped us understand we were going down the right path. +It was a little unsettling because when we looked at other products in the market, they would basically say, "We literally have 6,000 exercises that therapists can use." Well, we were really saying, "We're going to give you about 400. But the reason why is because it's a lot quicker to review 400 exercises and identify what you want as opposed to 6,000." And by and large, what we were hearing was that "Oh, well, when I use those apps that have 6,000 exercises, I just get overwhelmed, and it takes too long." +CHAD: But that can be a little scary, too, because if you're in that situation where you know that the person making the buying decision is just going to look and say, "Oh, this one has more exercises." [laughs] +TIFFANY: Yep, yep, yep. Yeah. +CHAD: Actually, at this point, let's take a little bit of a tangent because you're doing this within an existing company, Relias. Relias isn't necessarily a small company. So what kind of reporting out or management of other stakeholders or the business did you need to do along the way? +TIFFANY: That's a great question. And Relias is a big company, but also, this was a very new space for Relias. So they had never looked outward at a patient engagement tool. The focus had always been education for clinicians. So this was a very new space for them. +And actually, the most important and early conversations really were with our legal team and our cybersecurity team. And that was because we were going to be creating a database for patients. Again, new space, and we really needed to de-risk as early as possible, make sure that we could actually build this thing, keep it safe, that the budget was going to align. Also, that information really restricted the kind of information that we can actually keep about patients. So having that on the front end saved us so much time later on. That was number one. +And I would say anybody who's looking in the healthcare space absolutely has to start there because, again, the rules are changing constantly. And as clinicians, we are trained on how to take care of patients. We are trained to maintain patient privacy. We typically don't have a whole bunch of experience on cybersecurity and how you actually keep an online system secure. So you need to make sure you're talking to the right stakeholders to get the right information. So that was critical. +CHAD: Some organizations have an executive sponsor on the team or embedded in the team so that there are direct status updates and awareness of new product development. Is that the track that Relias took, or was it something else? +TIFFANY: That was absolutely the track that we took, so we did have an executive sponsor who we reported out to each week gave updates to. And he was able to communicate out to leadership as well. And we also had lots of opportunities internally to give updates and to do demos. So people could understand what we were doing; why we were making the decisions we were making to make sure everything aligned appropriately. +CHAD: I'm a big believer in demos and that kind of thing to communicate. I think we all have been in situations where when you're working on a complex problem, even if you do all your research and answer every question in the most perfect way and all that stuff, if at the end of that process it’s the first time anyone's hearing about all the results of that, there's going to be so many questions about did you consider this? Did you consider that? +And I think we all know that if instead we communicate things along the way and keep people up to speed, there's much more understanding but also trust in the process. +TIFFANY: Yeah, absolutely. And I have also experienced what you're describing. And what I have found is it's really like the weekly demo can be really quick, super helpful, and then documentation, documentation, documentation. We've created FAQ pages because of exactly what you're saying. +Because a lot of times, something isn't intuitive to a stakeholder, and maybe you've answered that question three or four times. So you've got to have it written down somewhere so that everybody's on the same page and understands. And even if they've missed seven meetings, if they come and have that question, hey, just so you know, we made that decision three weeks ago. This is why. This is the justification. This is why we're moving forward. +CHAD: Yeah. Is there any other sort of techniques that you employ to try to keep people up to date or strike that balance there? +TIFFANY: The main one, I think, is the weekly report out. And it is a challenge, and especially with things being virtual, of course, it's even more of a challenge because I think it's really easy to get insular but being consistent and being timely. +So if everybody knows okay, I'm going to go to this meeting on Monday morning at 10:00 o'clock, it's going to be 15 minutes, and I'm going to know exactly what's happening, all of a sudden, that organization piece is so key. Keeping it short is really key, and then everybody's on the same page. And you don't end up with that; hey, wait a minute, I didn't hear about that. Or why is that happening? Because that takes so much time to manage. +CHAD: We worked with one team several years ago, actually, but I realize that it might even be more relevant now. And I don't necessarily recommend this for every team. I think each team needs to find their own techniques that work well for their culture. +But this team, rather than having meetings actually had...they had occasional meetings, but they actually had a team blog, internal, completely internal. And they essentially wrote a blog together that everyone who wanted to follow along was able to follow along with. +TIFFANY: I think that's a great idea. I think in bigger companies, sometimes that gets lost. [laughs] +CHAD: Yeah, it definitely worked for this organization's culture and who was following along, but it wouldn't work for everybody. +TIFFANY: Absolutely. One other thing that I need to call out that I didn't was with some of the formative user interviews, we had to push on this, but we did try to get at least one member of engineering coming to some of those or at least getting some highlights. And this may seem like, of course, you would do that. But when you're working in a fairly large company that's entering into new space, there are new ways to be engaging your engineering team that are different and may not seem valuable at the time. +So we rallied pretty hard to get some folks in there so that they could really understand the problem that they were going to be contributing to solving. And that was critical because the assumptions about if you're building an app for an older adult versus the realities are so radically different that you can only really understand it if you visually see it or hearing from your user. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: Okay, so let's pop the stack now and go back to where we were before we took that tangent into that side of internal communication and management. So you had the prototype and were starting to show it to potential users and were getting positive feedback. What were the next steps after that? +TIFFANY: So the next steps for us were running through...and to be clear, we actually were creating two apps, which I never actually said, one for the clinician, [laughter] which the problem was to solve time, and one was for the older adult. +And I've had a ton of experience actually designing for older adults. So some people may think that that might have been the harder app. But there are some really straightforward design tenets that work when you're designing for somebody who's 60,70, 80, 90, 100-plus. +So starting out on the clinician side, got our prototype, went through, validated it with about seven clinicians, identified some areas of confusion, identified some areas that we thought were totally intuitive and were completely not. +So my favorite was we wanted a way for clinicians to identify the patients that they were going to see that day, and so we just thought that if they favorited the patients, if they just clicked a star, and they'll show up. And we had seven out of seven clinicians say, "Does that mean that they're actually my favorite patient? [laughter] Like, no. Okay, missed the boat on that one; regroup. +We went through about three prototype revisions before we got to the point where we were really happy with the workflow and felt like it was intuitive. So that was the first thing. +And then the second thing was on the patient-facing side. And for that one, it's a totally different workflow because it's just one human who's being given exercises. So it really was, okay, how do they access the exercises? How did they experience the exercises? And what makes sense? +And so we had a lot of questions because we were trying to figure out, do we want written text? Do we want animations? Do we want animations with audio? So we had a really robust user group that we were able...we had about ten that we were able to actually demo, and they could give us direct feedback on. +And then we had a user group of about 30 people that we actually just started sending prototypes and surveys to get some better feedback. And what we found is when we did more of the email, we would send them an audio clip of an animation. And we did some really lovely A/B testing that way. And we got much better results. +Because generally speaking, when you interview an older adult about something you are creating for them, they're super positive, even about the stuff they don't like. So it was a lot easier to get more robust, more real feedback by removing the human element and saying, "Hey, tell us how you really feel." We got some amazing feedback that way. +CHAD: That's interesting. And just in terms of timeline, was this happening pre-pandemic or post-pandemic? +TIFFANY: This was post-pandemic. Well, we really started doing this design work in the summer of 2020, so right in the middle of the pandemic, yes. +CHAD: Right. And so when you talk about these interviews and all that kind of stuff, everything was remote. +TIFFANY: Yeah, everything was remote, worked fantastic. That has been one of the cool things about being in this space, especially in design space, technology design, and aging, is that the acceleration of the technology adoption that happened in 2020 was mind-blowing. +I started working with design with older adults in 2014, building them different types of applications. And it just was incredible the level of comfort that I saw in 2020 amongst a much broader audience compared to 2014, 2015. +CHAD: Yeah, we've definitely seen that as well across different products. And the underlying reason is bad, but it certainly makes what we're doing a lot easier to have more people comfortable, even with little things like being on a Zoom call and knowing how to share their screen. Little things like that would sometimes be a big hang-up for getting good interviews and good feedback with people. +TIFFANY: Absolutely, absolutely, and doing some relatively complex things. Like, we were trying to validate doing a two-factor authentication, and we were able to do it virtually. So it's really giving us some really neat tools to reach a broad audience. +CHAD: A little while ago, you called out that there are patterns for building applications for certain ages. Can you tell me more about that? +TIFFANY: Sure. There's actually been a lot of research done in this area. I've contributed a little bit to it. [laughter] So what we really found especially early on...and I was involved with a project to take the connect technology and the Microsoft Connect technology and modify it to deliver a fall prevention program to older adults. +So in my previous life as a physical therapist, I have a Ph.D. in human movement and did a lot of research in healthy aging and injury prevention. And older adult falls is a fairly significant public health issue. And there are a lot of cool things you can do to address it around exercise. But the problem is scale. So how do you actually bring some of these exercises to older adults at scale as opposed to one on one? So that's the context behind this. +And so we started working with Microsoft SDK, building this out. And what we quickly realized is that the things that tend to make, let's say, a video game really cool and engaging are actually the worst things you can put into design if you're introducing an older adult or someone who's not comfortable with technology into a game. So you need a very simple interface, to begin with. And you need very straightforward commands. +And so it's funny because, in 2013, 2014 the people that were in this space all came from the gaming world. So they'd make these really beautiful backgrounds and things jumping and popping out. And you would lose your user within two minutes because it was just so visually overwhelming. +And one of the things that's interesting is as we get older, our brains are just not as flexible. They're super smart, but they get easily distracted. So what we learned is if you keep your user interface super simple, and then you make your early experiences very positive, so you keep the tasks very straightforward, you show success, what happens is your user gets a ton of self-efficacy. And they start to really realize that they know exactly what they're doing because they do. And then you can start doing some more interesting things. +So what we found is with our technology, as we got our users, okay, they're using it three times, they're using it four times. They're being super consistent doing this exercise program. Let's make it more visually engaging then they could actually handle it because they weren't so worried about what do I do next to go forward in the exercise program? +So yeah, so when you think about design, that was a really long-winded answer, sorry. +CHAD: [laughs] It's okay. +TIFFANY: But you want to keep things super simple and straightforward. You do need to infuse it with compassion and empathy, and if you can do small successes, really, really helpful. The other thing that is incredibly helpful, and this is going to sound a little hokey, is that any kind of avatar or chatbot who's super positive really, really can have a big impact. +Because a lot of times, older adults are by themselves trying to navigate this thing, and they have no idea what's going on. And if a chatbot pops up and says, "Hey, you're at this stage, do you need any help?" Or "Hey, you pushed the red button, good job." There's this very interesting relationship that gets built with older adults and chatbots and avatars. They engage with them much more. +And I think ultimately what I saw because we were using an avatar to lead through exercises is that self-efficacy increased because even though the avatar was leading them through the exercises, they ultimately knew it was them. Compared to if I was leading them through the exercises, there's always that yeah, I did it, but Tiffany taught me how. Whereas this is well, I did it, and the avatar taught me how, which really means that I actually did it. So I can actually do it. It's a really cool space. +CHAD: In validating the exercise format through those surveys and that kind of thing, what did you learn in terms of the format? Was animated ones winning out? +TIFFANY: Absolutely. What we learned was animation, hands down 100%. We also learned that animation plus narration really was the winning ticket. What we had tested we did some A/B testing where we did animation plus narration, and we had the exercise instructions written with the assumption that, well, some people are visual, and some people are auditory, and some people want to read the exercises. And we compared that to just animation plus narration and no written instructions. And the feedback we got was that it was too much. +Like, you're reading the instructions, you're watching, and you're listening, and it just was confusing and overwhelming. And sometimes it wasn't an exact match because when you're narrating an exercise versus reading about it, the words aren't always exactly the same because sometimes it just doesn't make sense to make them the same. But when you just had the narration with the exercise, people were really happy. They could see it, they could hear it, they could replay it. +And the other thing that was really nice about that particular format is it also gave a little bit of space. And this is on a mobile device, so when I say little space, I do mean little space where if the therapist had any specific cues, they could input it in there. So then now the patient's got...they can see the exercises, they can hear how to do it. "Oh yeah, and my therapist said, 'Make sure I put all my weight on my left leg.”’ So that just seemed to be the right package as opposed to dumping all of this information on the user. +CHAD: One of the things, when I've worked with people or organizations before that can become a bit of a blocker, is identifying something like this. Oh, animations with narration that's what this should be and then needing to produce all of that in order to bring the product to market to create it all from scratch. Was this material that you already had at your disposal? Or was it going to need to be created? +TIFFANY: It was going to need to be created. And the way we addressed that issue is we looked at, for lack of a better word, what are those key bread and butter exercises that just about every therapist prescribes to just about every person? I mean, it still was a sizable lift, but again, it wasn't an overwhelmingly huge production. +So we went ahead and said, okay, table stakes. We've got to have these in because if you don't, then it's not really usable. And of all of these, which are the ones which are generic enough that if we built it once, a therapist could put in additional instructions to do any kind of modifications? So that was really how we addressed that. +I would say if somebody is starting completely from scratch, pick a total of 10 exercises or a total of 10 things and just pilot that and just try to do low-fidelity prototypes and just validate it before going down the path. +CHAD: So in the story here, we're moving towards actually building something. Was there a go/no go point in the product's life cycle where you needed to get sign-off on something in order to decide to actually bring this product to market? +TIFFANY: Yes. And interestingly, we are in that point at this exact moment in time. [laughter] So we're at the point where it's released in alpha. We're getting some really great feedback. And on the clinician side, we're back to the original challenge around building something for patients. +We are still actually putting finishing touches on making sure that we can really secure this database the way it needs to be secured in 2022 because things, again, are moving pretty rapidly. So we are waiting for our go decision as we speak. +CHAD: But we did build something. +TIFFANY: Yes. +CHAD: So you didn't need to get full sign-off and go/no go before going from prototype to starting to build something. +TIFFANY: Correct. Yes, yeah. Yes, sorry. +CHAD: No, it's okay. +TIFFANY: We had, like I said, we were really good communicating out. We had all the data to support the decisions that we made. We felt like we had a couple of very minor outstanding things that we knew that needed to still be addressed. But we also felt we were at that point where we could go ahead and build. And once we got in people's hands, we probably have much better data on how to address the outstanding items. +CHAD: So given that you're at the point of you've gotten some things in people's hands, you're now making sure that this can be a product that you fully bring to market. What are some of the factors that are being looked at? And you mentioned security is one. What are some of the others? +TIFFANY: Some of the others...I will say one of the things that is not a factor but was a factor early on is, hey, wait a minute, can older adults really use this? Are they really going to want to use this? That's a slam dunk. Yes, they can use it, and yes, they really want to use it. Plenty of data there. +So one of the factors that's...believe it or not, the pandemic is actually throwing us a little bit of a curveball in the sense of there is so much transition happening in healthcare right now that we're having a couple of little challenges around...some of our clients are actually changing their settings. +So our first target market is people who are in home health. Well, if all of a sudden you are going from skilled nursing and opening up home health, there are a lot of factors you've got to balance. So that's been a little bit of a curveball. And it's also been a curveball in finding our early adopters to really go ahead and test it out. +And then the final thing that is a big challenge, and I think it's a challenge for everybody, is integration with pre-existing systems because there's so much variability and variety of EMR systems. I'll give you a great example. You could have a skilled nursing facility that has one EMR system, and that skilled nursing facility could contract with a rehab therapy company who uses a different system, but they're both seeing the same patient. +We want to be super strategic about...because, again, that's a huge resource suck of looking at those API integrations. That's one of the things that we're really doing a deeper dive into now to really figure out where do we actually put these resources? What's going to give us the most bang for our buck? And knowing that the target is moving constantly. +CHAD: What do you do while your...one of the challenges can be like, oh, we've got a team ready to build the product. Are you in a holding pattern now? Or what do you do? How do you manage that? +TIFFANY: There are two ways to manage, and one is going back to your product right now and doing more testing, which is always a good thing because you're just refining, refining, refining. It’s tricky, though, because when you've got a lot of limits on resources, especially human resources, lots of projects going on, the tricky part is can I keep my team, or do they need to get repurposed? +And I think it's all about having really honest conversations and if they are going to be pulled into another project, making sure everybody's on the same page about what that looks like so that if you are in a holding pattern, when you get off that holding pattern, that there's not a huge delay. Lots of conversations, lots of discussions, yeah +CHAD: Well, I wish you the best in working through all of that and bringing this product to market. I know you've been a tremendous partner in working on this together. I know the team has enjoyed working with you. And we work with a lot of people at different companies, and your experience in navigating this has been notable. +TIFFANY: Thank you. The team was amazing. I mean, it is a really great group of people, really open, at the same time, really able to crystallize some of the challenges in a way that was incredibly effective. So yeah, it was really a fantastic experience, and I'm very grateful for it. +CHAD: So if folks want to follow along with you or get in touch with you, where are the best places for them to do that? +TIFFANY: Either on LinkedIn. I, of course, have a space on LinkedIn but also at Relias. And my email is tshubert@relias.com. +CHAD: Wonderful. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Tiffany Shubert. + + + Chad talks to Tiffany Shubert, Senior Product Manager at Relias Healthcare. Relias is an online healthcare education company. They develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides in multiple healthcare settings. They span the entire range from acute care hospital settings to in-home care to hospice.

+ +

Tiffany talks about how her clinical skills apply really well to product management, defining who you're solving the problem for, being all about your end-user, and making sure they have an amazing experience with your product.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Tiffany Shubert, Senior Product Manager at Relias. Tiffany, thanks for joining me.

+ +

TIFFANY: Hey. Thanks so much, Chad. I'm really excited to be here.

+ +

CHAD: So, Tiffany, folks may not be familiar with what Relias is, although if you're in certain spaces, it's certainly a big name that you may have heard of. So why don't you start off by telling people a little bit about Relias?

+ +

TIFFANY: Sure. So Relias is an online healthcare education company. Relias is in many, many different settings. But the majority of what we do is we develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides. And we are in multiple healthcare settings. So we span the entire range from acute care hospital settings to in-home care to hospice.

+ +

CHAD: We do a lot of work with different clients in the healthcare space. And so many of them, without even me prompting, mention, "Oh, we use Relias." [chuckles] And it's remarkable to see. Is Relias the biggest provider of learning management software for the space?

+ +

TIFFANY: So, we are the biggest provider of compliance training in the skilled nursing space. And we are a big provider in all of the other spaces. And really, where Relias started was in this notion of compliance training which, for those who are not familiar, really could benefit from a lot of design. That is the kind of training that every single healthcare provider has to take in order to see a patient. So that's where you take your patient privacy training, your bloodborne pathogen training, all of those types of trainings. And that's where Relias really started and has grown from there.

+ +

CHAD: So, how long have you been at Relias?

+ +

TIFFANY: So I started, interesting, in the end of March 2020. [chuckles] So yeah, it has been my pandemic experience, so almost two years now.

+ +

CHAD: What brought you to Relias?

+ +

TIFFANY: So I was at an interesting juncture in my career. I'm a physical therapist by training, and I was in clinical practice for about 15 years. And I transitioned over actually through a very interesting pathway but working for some different startups that were creating different technologies around healthcare. And one of the startups I had been with had run the course. And I was looking for something more around education, which is my original passion. And when Relias actually found me, I didn't realize it was actually in my backyard.

+ +

CHAD: [laughs]

+ +

TIFFANY: What drew me to it was this ability at this space where we could be looking at education, especially for clinicians, not as what I would call a penance which is how it's looked at. Like, ugh, I have to take my online education, or I have to take my training. But more of a hey, how can we make education interesting and dynamic? And how can we really apply many of the concepts we know about design and about really developing excellent products to clinical education? Which was incredibly exciting to me.

+ +

CHAD: As you moved from someone practicing to product management in this space, did you do any formal learning or training in that, or did you just learn along the way?

+ +

TIFFANY: A combination. Really my original experience in product was working for a startup company that was developing a really innovative concept around creating a soft, light exoskeleton, and they needed a clinician on staff to really understand how bodies move and what kind of problems could be solved.

+ +

That position really evolved into being a director of user experience. And so that really entailed bringing our end users, who happened to be older adults, into the lab and having them really work side by side with the engineers who are creating the product. So I developed that whole program, validated it, expanded it.

+ +

And from there, I really realized, oh, my clinical skills actually apply really well to product management. But now I do need to get some more formal training. So I went through some of the different...I actually went through the CSPO certification program, and then I have also just continued doing some more formal training at Relias.

+ +

CHAD: I imagine that the industry itself experience being almost on the user side helps. But is it ever a hurdle that you need to overcome?

+ +

TIFFANY: I think when clinicians first get into industry, they make a lot of mistakes because they want to solve every single problem. Or they want to give their users every single opportunity or every single feature.

+ +

So, for example, if you sit down with a group of physical therapists, and if you say, "I'm going to build you an app for helping your patients with their home exercise program," every single physical therapist is going to give you a laundry list of 30 things that they want. And typically, where clinicians go in my role is they're like, "Okay, we're going to fix all 30 things." And really, it's that ability to narrow it down, narrow it down.

+ +

And to be honest, if you're a good clinician, it's the same thing. Patients usually come with multiple complaints, and you've got to figure out what that number one complaint is and what you can do to address it. So that's where I think it becomes a barrier is wanting to fix every single problem as opposed to being able to really winnow it down. But when you can winnow it down, it's very powerful.

+ +

CHAD: An extension of that that I've seen, which I think is one of the challenges in healthcare, is that there are a lot of edge cases. And in normal SaaS products like an e-commerce product or whatever, it's easier to say, "We're not going to solve that right now."

+ +

But in healthcare, every edge case is an actual person that you could be helping. And so it's a little bit harder to really get in the mindset of not solving every problem. Because especially if the space of healthcare that you're in is literally life and death, it can be difficult from a product perspective to say, "We're not going to solve that case."

+ +

TIFFANY: I completely agree. Those are just conversations that you have to have because you also have to look at if we spend all of this time solving all of these use cases or all of these edge cases, we're never going to have a product.

+ +

So then you got to pull back, and you got to go, what is going to have the biggest impact? Or what are the components across every single patient that we can address? Because there's always going to be some commonalities, not necessarily disease space, but in how we actually address that patient and manage that disease or manage that impairment.

+ +

It is a big trap that we fall into because you're right; healthcare provider training is you have to address everything. But the fact of the matter is that's not realistic.

+ +

CHAD: What are some other challenges that you encounter while creating products in the healthcare space?

+ +

TIFFANY: I think the biggest challenge is really defining who you're solving the problem for, and we run into this all the time. And this has become very clear to me lately that if you're working for a Facebook or a Google, you are all about your end-user. And it's all about making sure that that end-user has an amazing experience.

+ +

But in healthcare, you've got patients, you've got clinicians, you've got hospitals, you've got healthcare systems. You've got private insurance payers, and you've got Medicare. And all of those groups may be interacting with your product. And all of those groups have totally different use cases and totally different problems to solve.

+ +

So first of all, figuring out, like, who am I building this for? Who is going to pay for it? And where do those two things intersect? And that has been the biggest problem I have seen in innovation in this space over the last ten years has been, well, we're going to build this for the patient, and it's going to be amazing, and the insurance companies will just pay for it. That hasn't really panned out because nobody sat down and actually talked to the insurance companies and asked them what problems do they see happening that a product could solve?

+ +

And then the flip has happened too where they've gone to the insurance companies, and insurance companies have said, "Well, here are the problems," but then they've never talked to the patients. So it's getting that multifaceted perspective and then boiling it down to what truly is the problem we're going to solve?

+ +

CHAD: And the way I see it is that this problem is amped up in the healthcare space because there are so many stakeholders or people you're potentially building the product for. But it's a general problem too in enterprise software where basically the people making the buying decision are not the users necessarily or the people you're trying to help.

+ +

And any time where that's the case, you also run the risk of very difficult to build a good product because the people making the buying decisions aren't actually the ones who are going to be using it or don't have the same needs as the people that you're trying to help with the software.

+ +

TIFFANY: Exactly, exactly. So it takes a lot of time to sort all that out, and we rarely have that amount of time. I'd say one of the things that was so fascinating on the product that Relias and thoughtbot worked on was we had the time to go a little deeper and to really figure out...so the problem we were trying to solve is okay, we need a better tool. Physical therapists need a better tool to engage patients, specifically older adult patients.

+ +

And again, so we had the conversation with the clinicians, and they're like, "Oh, well, we want all of these exercises." But then we paused, and we said, "But really, what is your biggest clinical challenge?" And they all said, "Time. We don't have enough time."

+ +

So then we were able to pull back and not go, oh, this is not about making the best exercise program ever. This is about creating a product that actually solves the problem of time. If we can enhance efficiency, then clinicians will use it. They'll be happy with it, and we can take it from there.

+ +

Solving the problem of time is a totally different problem than we have to create a product that offers you 30,000 different exercises. It was just a really important lesson because then once we said time, then all of a sudden, we had clinician buy-in.

+ +

And then we also had an organization buy-in because the organization is going, "Absolutely. If you can save my clinicians 10 minutes, that's going to increase their productivity. That's going to give them more time with the patient. Or maybe we could even get so efficient that there are more opportunities to see more patients." So it's tricky to figure all that out.

+ +

CHAD: So how did we figure that out? What tools did we use to have those conversations with people?

+ +

TIFFANY: Yeah, there was a lot of really excellent discovery and meeting with a good variety of clinicians but all practicing in the same space. And that's one of the things I want to call out. When you look at healthcare, healthcare spans so many different settings. And there are not a lot of consistency or universal truths between settings.

+ +

And what I mean is someone who is seeing a patient in a home health setting is going to have a very different skill set than someone who is working with a professional sports team, same training, same title, totally different set of problems. So we were really, really clear that we had to really refine this problem and get a very specific type of therapist.

+ +

And we also wanted to get a specific...I'm going to just use home health just for an example. But okay, so let's make sure we get therapists who are working in rural settings, in-home health, and therapists who are working in urban settings in-home health because we wanted to make sure that we had a better understanding of the problems they were facing in these multiple settings.

+ +

From there, from that discovery, got really, really, really very strict on what consistencies we were seeing around the problems that the therapists were running into. And from there, we just really focused on what was going to give us the most bang for our buck. And the problem of time was super consistent. The questions really were not like, well, would an app save you time? The questions were really what are your biggest challenges right now?

+ +

CHAD: And did you do that in one on one interviews with them?

+ +

TIFFANY: Yeah, those were one on one interviews. Yes. Yeah.

+ +

CHAD: How do you, when you're doing it, collect the data from those interviews in a way that is conducive to analysis later on?

+ +

TIFFANY: So I've used a whole variety of tools. And we were very analog in this particular one. We were interviewing one person, but there were about four of us on the call, and everyone was taking notes. And then everybody was highlighting common themes. And I've used focus group analysis software as well, which is always really, really helpful. But in this particular, we were really just going analog, and it worked pretty well.

+ +

CHAD: And you were doing this without a prototype or anything like that yet, right?

+ +

TIFFANY: Correct, for the initial without a prototype. Yep.

+ +

CHAD: And so once you had that potential job to be done or value proposition, how did you go from that job to be done to a potential product?

+ +

TIFFANY: So from there, we did go ahead, and we prototyped, and we prototyped a workflow that seemed to make sense given what we had heard from our users and then also just with my clinical background. And then that prototype really was the trick because a lot of times in healthcare, when you are working with clinicians, some are tech-savvy, but there's a significant amount (And this isn't age-dependent, but this is younger and older.) that are not.

+ +

And so they really need a little bit of context to ground what their thoughts are and how they think you can solve them. So by getting that prototype in place and by letting the therapist really bounce around in there and see what was intuitive and what wasn't, that was the game-changer. And we could really see okay, here's our understanding of this. And whoops! Missed that one. [laughter] Oh, this all makes sense.

+ +

But you could see as therapists went through what they appreciated was that the user interface was super simple, super clean. They could easily find things. And even those who didn't have a lot of self-efficacy around technology really felt at the end of a 20-minute session I know how to use this, and I could see how this will save me time. All of that data really helped us understand we were going down the right path.

+ +

It was a little unsettling because when we looked at other products in the market, they would basically say, "We literally have 6,000 exercises that therapists can use." Well, we were really saying, "We're going to give you about 400. But the reason why is because it's a lot quicker to review 400 exercises and identify what you want as opposed to 6,000." And by and large, what we were hearing was that "Oh, well, when I use those apps that have 6,000 exercises, I just get overwhelmed, and it takes too long."

+ +

CHAD: But that can be a little scary, too, because if you're in that situation where you know that the person making the buying decision is just going to look and say, "Oh, this one has more exercises." [laughs]

+ +

TIFFANY: Yep, yep, yep. Yeah.

+ +

CHAD: Actually, at this point, let's take a little bit of a tangent because you're doing this within an existing company, Relias. Relias isn't necessarily a small company. So what kind of reporting out or management of other stakeholders or the business did you need to do along the way?

+ +

TIFFANY: That's a great question. And Relias is a big company, but also, this was a very new space for Relias. So they had never looked outward at a patient engagement tool. The focus had always been education for clinicians. So this was a very new space for them.

+ +

And actually, the most important and early conversations really were with our legal team and our cybersecurity team. And that was because we were going to be creating a database for patients. Again, new space, and we really needed to de-risk as early as possible, make sure that we could actually build this thing, keep it safe, that the budget was going to align. Also, that information really restricted the kind of information that we can actually keep about patients. So having that on the front end saved us so much time later on. That was number one.

+ +

And I would say anybody who's looking in the healthcare space absolutely has to start there because, again, the rules are changing constantly. And as clinicians, we are trained on how to take care of patients. We are trained to maintain patient privacy. We typically don't have a whole bunch of experience on cybersecurity and how you actually keep an online system secure. So you need to make sure you're talking to the right stakeholders to get the right information. So that was critical.

+ +

CHAD: Some organizations have an executive sponsor on the team or embedded in the team so that there are direct status updates and awareness of new product development. Is that the track that Relias took, or was it something else?

+ +

TIFFANY: That was absolutely the track that we took, so we did have an executive sponsor who we reported out to each week gave updates to. And he was able to communicate out to leadership as well. And we also had lots of opportunities internally to give updates and to do demos. So people could understand what we were doing; why we were making the decisions we were making to make sure everything aligned appropriately.

+ +

CHAD: I'm a big believer in demos and that kind of thing to communicate. I think we all have been in situations where when you're working on a complex problem, even if you do all your research and answer every question in the most perfect way and all that stuff, if at the end of that process it’s the first time anyone's hearing about all the results of that, there's going to be so many questions about did you consider this? Did you consider that?

+ +

And I think we all know that if instead we communicate things along the way and keep people up to speed, there's much more understanding but also trust in the process.

+ +

TIFFANY: Yeah, absolutely. And I have also experienced what you're describing. And what I have found is it's really like the weekly demo can be really quick, super helpful, and then documentation, documentation, documentation. We've created FAQ pages because of exactly what you're saying.

+ +

Because a lot of times, something isn't intuitive to a stakeholder, and maybe you've answered that question three or four times. So you've got to have it written down somewhere so that everybody's on the same page and understands. And even if they've missed seven meetings, if they come and have that question, hey, just so you know, we made that decision three weeks ago. This is why. This is the justification. This is why we're moving forward.

+ +

CHAD: Yeah. Is there any other sort of techniques that you employ to try to keep people up to date or strike that balance there?

+ +

TIFFANY: The main one, I think, is the weekly report out. And it is a challenge, and especially with things being virtual, of course, it's even more of a challenge because I think it's really easy to get insular but being consistent and being timely.

+ +

So if everybody knows okay, I'm going to go to this meeting on Monday morning at 10:00 o'clock, it's going to be 15 minutes, and I'm going to know exactly what's happening, all of a sudden, that organization piece is so key. Keeping it short is really key, and then everybody's on the same page. And you don't end up with that; hey, wait a minute, I didn't hear about that. Or why is that happening? Because that takes so much time to manage.

+ +

CHAD: We worked with one team several years ago, actually, but I realize that it might even be more relevant now. And I don't necessarily recommend this for every team. I think each team needs to find their own techniques that work well for their culture.

+ +

But this team, rather than having meetings actually had...they had occasional meetings, but they actually had a team blog, internal, completely internal. And they essentially wrote a blog together that everyone who wanted to follow along was able to follow along with.

+ +

TIFFANY: I think that's a great idea. I think in bigger companies, sometimes that gets lost. [laughs]

+ +

CHAD: Yeah, it definitely worked for this organization's culture and who was following along, but it wouldn't work for everybody.

+ +

TIFFANY: Absolutely. One other thing that I need to call out that I didn't was with some of the formative user interviews, we had to push on this, but we did try to get at least one member of engineering coming to some of those or at least getting some highlights. And this may seem like, of course, you would do that. But when you're working in a fairly large company that's entering into new space, there are new ways to be engaging your engineering team that are different and may not seem valuable at the time.

+ +

So we rallied pretty hard to get some folks in there so that they could really understand the problem that they were going to be contributing to solving. And that was critical because the assumptions about if you're building an app for an older adult versus the realities are so radically different that you can only really understand it if you visually see it or hearing from your user.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Okay, so let's pop the stack now and go back to where we were before we took that tangent into that side of internal communication and management. So you had the prototype and were starting to show it to potential users and were getting positive feedback. What were the next steps after that?

+ +

TIFFANY: So the next steps for us were running through...and to be clear, we actually were creating two apps, which I never actually said, one for the clinician, [laughter] which the problem was to solve time, and one was for the older adult.

+ +

And I've had a ton of experience actually designing for older adults. So some people may think that that might have been the harder app. But there are some really straightforward design tenets that work when you're designing for somebody who's 60,70, 80, 90, 100-plus.

+ +

So starting out on the clinician side, got our prototype, went through, validated it with about seven clinicians, identified some areas of confusion, identified some areas that we thought were totally intuitive and were completely not.

+ +

So my favorite was we wanted a way for clinicians to identify the patients that they were going to see that day, and so we just thought that if they favorited the patients, if they just clicked a star, and they'll show up. And we had seven out of seven clinicians say, "Does that mean that they're actually my favorite patient? [laughter] Like, no. Okay, missed the boat on that one; regroup.

+ +

We went through about three prototype revisions before we got to the point where we were really happy with the workflow and felt like it was intuitive. So that was the first thing.

+ +

And then the second thing was on the patient-facing side. And for that one, it's a totally different workflow because it's just one human who's being given exercises. So it really was, okay, how do they access the exercises? How did they experience the exercises? And what makes sense?

+ +

And so we had a lot of questions because we were trying to figure out, do we want written text? Do we want animations? Do we want animations with audio? So we had a really robust user group that we were able...we had about ten that we were able to actually demo, and they could give us direct feedback on.

+ +

And then we had a user group of about 30 people that we actually just started sending prototypes and surveys to get some better feedback. And what we found is when we did more of the email, we would send them an audio clip of an animation. And we did some really lovely A/B testing that way. And we got much better results.

+ +

Because generally speaking, when you interview an older adult about something you are creating for them, they're super positive, even about the stuff they don't like. So it was a lot easier to get more robust, more real feedback by removing the human element and saying, "Hey, tell us how you really feel." We got some amazing feedback that way.

+ +

CHAD: That's interesting. And just in terms of timeline, was this happening pre-pandemic or post-pandemic?

+ +

TIFFANY: This was post-pandemic. Well, we really started doing this design work in the summer of 2020, so right in the middle of the pandemic, yes.

+ +

CHAD: Right. And so when you talk about these interviews and all that kind of stuff, everything was remote.

+ +

TIFFANY: Yeah, everything was remote, worked fantastic. That has been one of the cool things about being in this space, especially in design space, technology design, and aging, is that the acceleration of the technology adoption that happened in 2020 was mind-blowing.

+ +

I started working with design with older adults in 2014, building them different types of applications. And it just was incredible the level of comfort that I saw in 2020 amongst a much broader audience compared to 2014, 2015.

+ +

CHAD: Yeah, we've definitely seen that as well across different products. And the underlying reason is bad, but it certainly makes what we're doing a lot easier to have more people comfortable, even with little things like being on a Zoom call and knowing how to share their screen. Little things like that would sometimes be a big hang-up for getting good interviews and good feedback with people.

+ +

TIFFANY: Absolutely, absolutely, and doing some relatively complex things. Like, we were trying to validate doing a two-factor authentication, and we were able to do it virtually. So it's really giving us some really neat tools to reach a broad audience.

+ +

CHAD: A little while ago, you called out that there are patterns for building applications for certain ages. Can you tell me more about that?

+ +

TIFFANY: Sure. There's actually been a lot of research done in this area. I've contributed a little bit to it. [laughter] So what we really found especially early on...and I was involved with a project to take the connect technology and the Microsoft Connect technology and modify it to deliver a fall prevention program to older adults.

+ +

So in my previous life as a physical therapist, I have a Ph.D. in human movement and did a lot of research in healthy aging and injury prevention. And older adult falls is a fairly significant public health issue. And there are a lot of cool things you can do to address it around exercise. But the problem is scale. So how do you actually bring some of these exercises to older adults at scale as opposed to one on one? So that's the context behind this.

+ +

And so we started working with Microsoft SDK, building this out. And what we quickly realized is that the things that tend to make, let's say, a video game really cool and engaging are actually the worst things you can put into design if you're introducing an older adult or someone who's not comfortable with technology into a game. So you need a very simple interface, to begin with. And you need very straightforward commands.

+ +

And so it's funny because, in 2013, 2014 the people that were in this space all came from the gaming world. So they'd make these really beautiful backgrounds and things jumping and popping out. And you would lose your user within two minutes because it was just so visually overwhelming.

+ +

And one of the things that's interesting is as we get older, our brains are just not as flexible. They're super smart, but they get easily distracted. So what we learned is if you keep your user interface super simple, and then you make your early experiences very positive, so you keep the tasks very straightforward, you show success, what happens is your user gets a ton of self-efficacy. And they start to really realize that they know exactly what they're doing because they do. And then you can start doing some more interesting things.

+ +

So what we found is with our technology, as we got our users, okay, they're using it three times, they're using it four times. They're being super consistent doing this exercise program. Let's make it more visually engaging then they could actually handle it because they weren't so worried about what do I do next to go forward in the exercise program?

+ +

So yeah, so when you think about design, that was a really long-winded answer, sorry.

+ +

CHAD: [laughs] It's okay.

+ +

TIFFANY: But you want to keep things super simple and straightforward. You do need to infuse it with compassion and empathy, and if you can do small successes, really, really helpful. The other thing that is incredibly helpful, and this is going to sound a little hokey, is that any kind of avatar or chatbot who's super positive really, really can have a big impact.

+ +

Because a lot of times, older adults are by themselves trying to navigate this thing, and they have no idea what's going on. And if a chatbot pops up and says, "Hey, you're at this stage, do you need any help?" Or "Hey, you pushed the red button, good job." There's this very interesting relationship that gets built with older adults and chatbots and avatars. They engage with them much more.

+ +

And I think ultimately what I saw because we were using an avatar to lead through exercises is that self-efficacy increased because even though the avatar was leading them through the exercises, they ultimately knew it was them. Compared to if I was leading them through the exercises, there's always that yeah, I did it, but Tiffany taught me how. Whereas this is well, I did it, and the avatar taught me how, which really means that I actually did it. So I can actually do it. It's a really cool space.

+ +

CHAD: In validating the exercise format through those surveys and that kind of thing, what did you learn in terms of the format? Was animated ones winning out?

+ +

TIFFANY: Absolutely. What we learned was animation, hands down 100%. We also learned that animation plus narration really was the winning ticket. What we had tested we did some A/B testing where we did animation plus narration, and we had the exercise instructions written with the assumption that, well, some people are visual, and some people are auditory, and some people want to read the exercises. And we compared that to just animation plus narration and no written instructions. And the feedback we got was that it was too much.

+ +

Like, you're reading the instructions, you're watching, and you're listening, and it just was confusing and overwhelming. And sometimes it wasn't an exact match because when you're narrating an exercise versus reading about it, the words aren't always exactly the same because sometimes it just doesn't make sense to make them the same. But when you just had the narration with the exercise, people were really happy. They could see it, they could hear it, they could replay it.

+ +

And the other thing that was really nice about that particular format is it also gave a little bit of space. And this is on a mobile device, so when I say little space, I do mean little space where if the therapist had any specific cues, they could input it in there. So then now the patient's got...they can see the exercises, they can hear how to do it. "Oh yeah, and my therapist said, 'Make sure I put all my weight on my left leg.”’ So that just seemed to be the right package as opposed to dumping all of this information on the user.

+ +

CHAD: One of the things, when I've worked with people or organizations before that can become a bit of a blocker, is identifying something like this. Oh, animations with narration that's what this should be and then needing to produce all of that in order to bring the product to market to create it all from scratch. Was this material that you already had at your disposal? Or was it going to need to be created?

+ +

TIFFANY: It was going to need to be created. And the way we addressed that issue is we looked at, for lack of a better word, what are those key bread and butter exercises that just about every therapist prescribes to just about every person? I mean, it still was a sizable lift, but again, it wasn't an overwhelmingly huge production.

+ +

So we went ahead and said, okay, table stakes. We've got to have these in because if you don't, then it's not really usable. And of all of these, which are the ones which are generic enough that if we built it once, a therapist could put in additional instructions to do any kind of modifications? So that was really how we addressed that.

+ +

I would say if somebody is starting completely from scratch, pick a total of 10 exercises or a total of 10 things and just pilot that and just try to do low-fidelity prototypes and just validate it before going down the path.

+ +

CHAD: So in the story here, we're moving towards actually building something. Was there a go/no go point in the product's life cycle where you needed to get sign-off on something in order to decide to actually bring this product to market?

+ +

TIFFANY: Yes. And interestingly, we are in that point at this exact moment in time. [laughter] So we're at the point where it's released in alpha. We're getting some really great feedback. And on the clinician side, we're back to the original challenge around building something for patients.

+ +

We are still actually putting finishing touches on making sure that we can really secure this database the way it needs to be secured in 2022 because things, again, are moving pretty rapidly. So we are waiting for our go decision as we speak.

+ +

CHAD: But we did build something.

+ +

TIFFANY: Yes.

+ +

CHAD: So you didn't need to get full sign-off and go/no go before going from prototype to starting to build something.

+ +

TIFFANY: Correct. Yes, yeah. Yes, sorry.

+ +

CHAD: No, it's okay.

+ +

TIFFANY: We had, like I said, we were really good communicating out. We had all the data to support the decisions that we made. We felt like we had a couple of very minor outstanding things that we knew that needed to still be addressed. But we also felt we were at that point where we could go ahead and build. And once we got in people's hands, we probably have much better data on how to address the outstanding items.

+ +

CHAD: So given that you're at the point of you've gotten some things in people's hands, you're now making sure that this can be a product that you fully bring to market. What are some of the factors that are being looked at? And you mentioned security is one. What are some of the others?

+ +

TIFFANY: Some of the others...I will say one of the things that is not a factor but was a factor early on is, hey, wait a minute, can older adults really use this? Are they really going to want to use this? That's a slam dunk. Yes, they can use it, and yes, they really want to use it. Plenty of data there.

+ +

So one of the factors that's...believe it or not, the pandemic is actually throwing us a little bit of a curveball in the sense of there is so much transition happening in healthcare right now that we're having a couple of little challenges around...some of our clients are actually changing their settings.

+ +

So our first target market is people who are in home health. Well, if all of a sudden you are going from skilled nursing and opening up home health, there are a lot of factors you've got to balance. So that's been a little bit of a curveball. And it's also been a curveball in finding our early adopters to really go ahead and test it out.

+ +

And then the final thing that is a big challenge, and I think it's a challenge for everybody, is integration with pre-existing systems because there's so much variability and variety of EMR systems. I'll give you a great example. You could have a skilled nursing facility that has one EMR system, and that skilled nursing facility could contract with a rehab therapy company who uses a different system, but they're both seeing the same patient.

+ +

We want to be super strategic about...because, again, that's a huge resource suck of looking at those API integrations. That's one of the things that we're really doing a deeper dive into now to really figure out where do we actually put these resources? What's going to give us the most bang for our buck? And knowing that the target is moving constantly.

+ +

CHAD: What do you do while your...one of the challenges can be like, oh, we've got a team ready to build the product. Are you in a holding pattern now? Or what do you do? How do you manage that?

+ +

TIFFANY: There are two ways to manage, and one is going back to your product right now and doing more testing, which is always a good thing because you're just refining, refining, refining. It’s tricky, though, because when you've got a lot of limits on resources, especially human resources, lots of projects going on, the tricky part is can I keep my team, or do they need to get repurposed?

+ +

And I think it's all about having really honest conversations and if they are going to be pulled into another project, making sure everybody's on the same page about what that looks like so that if you are in a holding pattern, when you get off that holding pattern, that there's not a huge delay. Lots of conversations, lots of discussions, yeah

+ +

CHAD: Well, I wish you the best in working through all of that and bringing this product to market. I know you've been a tremendous partner in working on this together. I know the team has enjoyed working with you. And we work with a lot of people at different companies, and your experience in navigating this has been notable.

+ +

TIFFANY: Thank you. The team was amazing. I mean, it is a really great group of people, really open, at the same time, really able to crystallize some of the challenges in a way that was incredibly effective. So yeah, it was really a fantastic experience, and I'm very grateful for it.

+ +

CHAD: So if folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

TIFFANY: Either on LinkedIn. I, of course, have a space on LinkedIn but also at Relias. And my email is tshubert@relias.com.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Tiffany Shubert.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to Tiffany Shubert, Senior Product Manager at Relias Healthcare. Relias is an online healthcare education company. They develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides in multiple healthcare settings. They span the entire range from acute care hospital settings to in-home care to hospice.

+ +

Tiffany talks about how her clinical skills apply really well to product management, defining who you're solving the problem for, being all about your end-user, and making sure they have an amazing experience with your product.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Tiffany Shubert, Senior Product Manager at Relias. Tiffany, thanks for joining me.

+ +

TIFFANY: Hey. Thanks so much, Chad. I'm really excited to be here.

+ +

CHAD: So, Tiffany, folks may not be familiar with what Relias is, although if you're in certain spaces, it's certainly a big name that you may have heard of. So why don't you start off by telling people a little bit about Relias?

+ +

TIFFANY: Sure. So Relias is an online healthcare education company. Relias is in many, many different settings. But the majority of what we do is we develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides. And we are in multiple healthcare settings. So we span the entire range from acute care hospital settings to in-home care to hospice.

+ +

CHAD: We do a lot of work with different clients in the healthcare space. And so many of them, without even me prompting, mention, "Oh, we use Relias." [chuckles] And it's remarkable to see. Is Relias the biggest provider of learning management software for the space?

+ +

TIFFANY: So, we are the biggest provider of compliance training in the skilled nursing space. And we are a big provider in all of the other spaces. And really, where Relias started was in this notion of compliance training which, for those who are not familiar, really could benefit from a lot of design. That is the kind of training that every single healthcare provider has to take in order to see a patient. So that's where you take your patient privacy training, your bloodborne pathogen training, all of those types of trainings. And that's where Relias really started and has grown from there.

+ +

CHAD: So, how long have you been at Relias?

+ +

TIFFANY: So I started, interesting, in the end of March 2020. [chuckles] So yeah, it has been my pandemic experience, so almost two years now.

+ +

CHAD: What brought you to Relias?

+ +

TIFFANY: So I was at an interesting juncture in my career. I'm a physical therapist by training, and I was in clinical practice for about 15 years. And I transitioned over actually through a very interesting pathway but working for some different startups that were creating different technologies around healthcare. And one of the startups I had been with had run the course. And I was looking for something more around education, which is my original passion. And when Relias actually found me, I didn't realize it was actually in my backyard.

+ +

CHAD: [laughs]

+ +

TIFFANY: What drew me to it was this ability at this space where we could be looking at education, especially for clinicians, not as what I would call a penance which is how it's looked at. Like, ugh, I have to take my online education, or I have to take my training. But more of a hey, how can we make education interesting and dynamic? And how can we really apply many of the concepts we know about design and about really developing excellent products to clinical education? Which was incredibly exciting to me.

+ +

CHAD: As you moved from someone practicing to product management in this space, did you do any formal learning or training in that, or did you just learn along the way?

+ +

TIFFANY: A combination. Really my original experience in product was working for a startup company that was developing a really innovative concept around creating a soft, light exoskeleton, and they needed a clinician on staff to really understand how bodies move and what kind of problems could be solved.

+ +

That position really evolved into being a director of user experience. And so that really entailed bringing our end users, who happened to be older adults, into the lab and having them really work side by side with the engineers who are creating the product. So I developed that whole program, validated it, expanded it.

+ +

And from there, I really realized, oh, my clinical skills actually apply really well to product management. But now I do need to get some more formal training. So I went through some of the different...I actually went through the CSPO certification program, and then I have also just continued doing some more formal training at Relias.

+ +

CHAD: I imagine that the industry itself experience being almost on the user side helps. But is it ever a hurdle that you need to overcome?

+ +

TIFFANY: I think when clinicians first get into industry, they make a lot of mistakes because they want to solve every single problem. Or they want to give their users every single opportunity or every single feature.

+ +

So, for example, if you sit down with a group of physical therapists, and if you say, "I'm going to build you an app for helping your patients with their home exercise program," every single physical therapist is going to give you a laundry list of 30 things that they want. And typically, where clinicians go in my role is they're like, "Okay, we're going to fix all 30 things." And really, it's that ability to narrow it down, narrow it down.

+ +

And to be honest, if you're a good clinician, it's the same thing. Patients usually come with multiple complaints, and you've got to figure out what that number one complaint is and what you can do to address it. So that's where I think it becomes a barrier is wanting to fix every single problem as opposed to being able to really winnow it down. But when you can winnow it down, it's very powerful.

+ +

CHAD: An extension of that that I've seen, which I think is one of the challenges in healthcare, is that there are a lot of edge cases. And in normal SaaS products like an e-commerce product or whatever, it's easier to say, "We're not going to solve that right now."

+ +

But in healthcare, every edge case is an actual person that you could be helping. And so it's a little bit harder to really get in the mindset of not solving every problem. Because especially if the space of healthcare that you're in is literally life and death, it can be difficult from a product perspective to say, "We're not going to solve that case."

+ +

TIFFANY: I completely agree. Those are just conversations that you have to have because you also have to look at if we spend all of this time solving all of these use cases or all of these edge cases, we're never going to have a product.

+ +

So then you got to pull back, and you got to go, what is going to have the biggest impact? Or what are the components across every single patient that we can address? Because there's always going to be some commonalities, not necessarily disease space, but in how we actually address that patient and manage that disease or manage that impairment.

+ +

It is a big trap that we fall into because you're right; healthcare provider training is you have to address everything. But the fact of the matter is that's not realistic.

+ +

CHAD: What are some other challenges that you encounter while creating products in the healthcare space?

+ +

TIFFANY: I think the biggest challenge is really defining who you're solving the problem for, and we run into this all the time. And this has become very clear to me lately that if you're working for a Facebook or a Google, you are all about your end-user. And it's all about making sure that that end-user has an amazing experience.

+ +

But in healthcare, you've got patients, you've got clinicians, you've got hospitals, you've got healthcare systems. You've got private insurance payers, and you've got Medicare. And all of those groups may be interacting with your product. And all of those groups have totally different use cases and totally different problems to solve.

+ +

So first of all, figuring out, like, who am I building this for? Who is going to pay for it? And where do those two things intersect? And that has been the biggest problem I have seen in innovation in this space over the last ten years has been, well, we're going to build this for the patient, and it's going to be amazing, and the insurance companies will just pay for it. That hasn't really panned out because nobody sat down and actually talked to the insurance companies and asked them what problems do they see happening that a product could solve?

+ +

And then the flip has happened too where they've gone to the insurance companies, and insurance companies have said, "Well, here are the problems," but then they've never talked to the patients. So it's getting that multifaceted perspective and then boiling it down to what truly is the problem we're going to solve?

+ +

CHAD: And the way I see it is that this problem is amped up in the healthcare space because there are so many stakeholders or people you're potentially building the product for. But it's a general problem too in enterprise software where basically the people making the buying decision are not the users necessarily or the people you're trying to help.

+ +

And any time where that's the case, you also run the risk of very difficult to build a good product because the people making the buying decisions aren't actually the ones who are going to be using it or don't have the same needs as the people that you're trying to help with the software.

+ +

TIFFANY: Exactly, exactly. So it takes a lot of time to sort all that out, and we rarely have that amount of time. I'd say one of the things that was so fascinating on the product that Relias and thoughtbot worked on was we had the time to go a little deeper and to really figure out...so the problem we were trying to solve is okay, we need a better tool. Physical therapists need a better tool to engage patients, specifically older adult patients.

+ +

And again, so we had the conversation with the clinicians, and they're like, "Oh, well, we want all of these exercises." But then we paused, and we said, "But really, what is your biggest clinical challenge?" And they all said, "Time. We don't have enough time."

+ +

So then we were able to pull back and not go, oh, this is not about making the best exercise program ever. This is about creating a product that actually solves the problem of time. If we can enhance efficiency, then clinicians will use it. They'll be happy with it, and we can take it from there.

+ +

Solving the problem of time is a totally different problem than we have to create a product that offers you 30,000 different exercises. It was just a really important lesson because then once we said time, then all of a sudden, we had clinician buy-in.

+ +

And then we also had an organization buy-in because the organization is going, "Absolutely. If you can save my clinicians 10 minutes, that's going to increase their productivity. That's going to give them more time with the patient. Or maybe we could even get so efficient that there are more opportunities to see more patients." So it's tricky to figure all that out.

+ +

CHAD: So how did we figure that out? What tools did we use to have those conversations with people?

+ +

TIFFANY: Yeah, there was a lot of really excellent discovery and meeting with a good variety of clinicians but all practicing in the same space. And that's one of the things I want to call out. When you look at healthcare, healthcare spans so many different settings. And there are not a lot of consistency or universal truths between settings.

+ +

And what I mean is someone who is seeing a patient in a home health setting is going to have a very different skill set than someone who is working with a professional sports team, same training, same title, totally different set of problems. So we were really, really clear that we had to really refine this problem and get a very specific type of therapist.

+ +

And we also wanted to get a specific...I'm going to just use home health just for an example. But okay, so let's make sure we get therapists who are working in rural settings, in-home health, and therapists who are working in urban settings in-home health because we wanted to make sure that we had a better understanding of the problems they were facing in these multiple settings.

+ +

From there, from that discovery, got really, really, really very strict on what consistencies we were seeing around the problems that the therapists were running into. And from there, we just really focused on what was going to give us the most bang for our buck. And the problem of time was super consistent. The questions really were not like, well, would an app save you time? The questions were really what are your biggest challenges right now?

+ +

CHAD: And did you do that in one on one interviews with them?

+ +

TIFFANY: Yeah, those were one on one interviews. Yes. Yeah.

+ +

CHAD: How do you, when you're doing it, collect the data from those interviews in a way that is conducive to analysis later on?

+ +

TIFFANY: So I've used a whole variety of tools. And we were very analog in this particular one. We were interviewing one person, but there were about four of us on the call, and everyone was taking notes. And then everybody was highlighting common themes. And I've used focus group analysis software as well, which is always really, really helpful. But in this particular, we were really just going analog, and it worked pretty well.

+ +

CHAD: And you were doing this without a prototype or anything like that yet, right?

+ +

TIFFANY: Correct, for the initial without a prototype. Yep.

+ +

CHAD: And so once you had that potential job to be done or value proposition, how did you go from that job to be done to a potential product?

+ +

TIFFANY: So from there, we did go ahead, and we prototyped, and we prototyped a workflow that seemed to make sense given what we had heard from our users and then also just with my clinical background. And then that prototype really was the trick because a lot of times in healthcare, when you are working with clinicians, some are tech-savvy, but there's a significant amount (And this isn't age-dependent, but this is younger and older.) that are not.

+ +

And so they really need a little bit of context to ground what their thoughts are and how they think you can solve them. So by getting that prototype in place and by letting the therapist really bounce around in there and see what was intuitive and what wasn't, that was the game-changer. And we could really see okay, here's our understanding of this. And whoops! Missed that one. [laughter] Oh, this all makes sense.

+ +

But you could see as therapists went through what they appreciated was that the user interface was super simple, super clean. They could easily find things. And even those who didn't have a lot of self-efficacy around technology really felt at the end of a 20-minute session I know how to use this, and I could see how this will save me time. All of that data really helped us understand we were going down the right path.

+ +

It was a little unsettling because when we looked at other products in the market, they would basically say, "We literally have 6,000 exercises that therapists can use." Well, we were really saying, "We're going to give you about 400. But the reason why is because it's a lot quicker to review 400 exercises and identify what you want as opposed to 6,000." And by and large, what we were hearing was that "Oh, well, when I use those apps that have 6,000 exercises, I just get overwhelmed, and it takes too long."

+ +

CHAD: But that can be a little scary, too, because if you're in that situation where you know that the person making the buying decision is just going to look and say, "Oh, this one has more exercises." [laughs]

+ +

TIFFANY: Yep, yep, yep. Yeah.

+ +

CHAD: Actually, at this point, let's take a little bit of a tangent because you're doing this within an existing company, Relias. Relias isn't necessarily a small company. So what kind of reporting out or management of other stakeholders or the business did you need to do along the way?

+ +

TIFFANY: That's a great question. And Relias is a big company, but also, this was a very new space for Relias. So they had never looked outward at a patient engagement tool. The focus had always been education for clinicians. So this was a very new space for them.

+ +

And actually, the most important and early conversations really were with our legal team and our cybersecurity team. And that was because we were going to be creating a database for patients. Again, new space, and we really needed to de-risk as early as possible, make sure that we could actually build this thing, keep it safe, that the budget was going to align. Also, that information really restricted the kind of information that we can actually keep about patients. So having that on the front end saved us so much time later on. That was number one.

+ +

And I would say anybody who's looking in the healthcare space absolutely has to start there because, again, the rules are changing constantly. And as clinicians, we are trained on how to take care of patients. We are trained to maintain patient privacy. We typically don't have a whole bunch of experience on cybersecurity and how you actually keep an online system secure. So you need to make sure you're talking to the right stakeholders to get the right information. So that was critical.

+ +

CHAD: Some organizations have an executive sponsor on the team or embedded in the team so that there are direct status updates and awareness of new product development. Is that the track that Relias took, or was it something else?

+ +

TIFFANY: That was absolutely the track that we took, so we did have an executive sponsor who we reported out to each week gave updates to. And he was able to communicate out to leadership as well. And we also had lots of opportunities internally to give updates and to do demos. So people could understand what we were doing; why we were making the decisions we were making to make sure everything aligned appropriately.

+ +

CHAD: I'm a big believer in demos and that kind of thing to communicate. I think we all have been in situations where when you're working on a complex problem, even if you do all your research and answer every question in the most perfect way and all that stuff, if at the end of that process it’s the first time anyone's hearing about all the results of that, there's going to be so many questions about did you consider this? Did you consider that?

+ +

And I think we all know that if instead we communicate things along the way and keep people up to speed, there's much more understanding but also trust in the process.

+ +

TIFFANY: Yeah, absolutely. And I have also experienced what you're describing. And what I have found is it's really like the weekly demo can be really quick, super helpful, and then documentation, documentation, documentation. We've created FAQ pages because of exactly what you're saying.

+ +

Because a lot of times, something isn't intuitive to a stakeholder, and maybe you've answered that question three or four times. So you've got to have it written down somewhere so that everybody's on the same page and understands. And even if they've missed seven meetings, if they come and have that question, hey, just so you know, we made that decision three weeks ago. This is why. This is the justification. This is why we're moving forward.

+ +

CHAD: Yeah. Is there any other sort of techniques that you employ to try to keep people up to date or strike that balance there?

+ +

TIFFANY: The main one, I think, is the weekly report out. And it is a challenge, and especially with things being virtual, of course, it's even more of a challenge because I think it's really easy to get insular but being consistent and being timely.

+ +

So if everybody knows okay, I'm going to go to this meeting on Monday morning at 10:00 o'clock, it's going to be 15 minutes, and I'm going to know exactly what's happening, all of a sudden, that organization piece is so key. Keeping it short is really key, and then everybody's on the same page. And you don't end up with that; hey, wait a minute, I didn't hear about that. Or why is that happening? Because that takes so much time to manage.

+ +

CHAD: We worked with one team several years ago, actually, but I realize that it might even be more relevant now. And I don't necessarily recommend this for every team. I think each team needs to find their own techniques that work well for their culture.

+ +

But this team, rather than having meetings actually had...they had occasional meetings, but they actually had a team blog, internal, completely internal. And they essentially wrote a blog together that everyone who wanted to follow along was able to follow along with.

+ +

TIFFANY: I think that's a great idea. I think in bigger companies, sometimes that gets lost. [laughs]

+ +

CHAD: Yeah, it definitely worked for this organization's culture and who was following along, but it wouldn't work for everybody.

+ +

TIFFANY: Absolutely. One other thing that I need to call out that I didn't was with some of the formative user interviews, we had to push on this, but we did try to get at least one member of engineering coming to some of those or at least getting some highlights. And this may seem like, of course, you would do that. But when you're working in a fairly large company that's entering into new space, there are new ways to be engaging your engineering team that are different and may not seem valuable at the time.

+ +

So we rallied pretty hard to get some folks in there so that they could really understand the problem that they were going to be contributing to solving. And that was critical because the assumptions about if you're building an app for an older adult versus the realities are so radically different that you can only really understand it if you visually see it or hearing from your user.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: Okay, so let's pop the stack now and go back to where we were before we took that tangent into that side of internal communication and management. So you had the prototype and were starting to show it to potential users and were getting positive feedback. What were the next steps after that?

+ +

TIFFANY: So the next steps for us were running through...and to be clear, we actually were creating two apps, which I never actually said, one for the clinician, [laughter] which the problem was to solve time, and one was for the older adult.

+ +

And I've had a ton of experience actually designing for older adults. So some people may think that that might have been the harder app. But there are some really straightforward design tenets that work when you're designing for somebody who's 60,70, 80, 90, 100-plus.

+ +

So starting out on the clinician side, got our prototype, went through, validated it with about seven clinicians, identified some areas of confusion, identified some areas that we thought were totally intuitive and were completely not.

+ +

So my favorite was we wanted a way for clinicians to identify the patients that they were going to see that day, and so we just thought that if they favorited the patients, if they just clicked a star, and they'll show up. And we had seven out of seven clinicians say, "Does that mean that they're actually my favorite patient? [laughter] Like, no. Okay, missed the boat on that one; regroup.

+ +

We went through about three prototype revisions before we got to the point where we were really happy with the workflow and felt like it was intuitive. So that was the first thing.

+ +

And then the second thing was on the patient-facing side. And for that one, it's a totally different workflow because it's just one human who's being given exercises. So it really was, okay, how do they access the exercises? How did they experience the exercises? And what makes sense?

+ +

And so we had a lot of questions because we were trying to figure out, do we want written text? Do we want animations? Do we want animations with audio? So we had a really robust user group that we were able...we had about ten that we were able to actually demo, and they could give us direct feedback on.

+ +

And then we had a user group of about 30 people that we actually just started sending prototypes and surveys to get some better feedback. And what we found is when we did more of the email, we would send them an audio clip of an animation. And we did some really lovely A/B testing that way. And we got much better results.

+ +

Because generally speaking, when you interview an older adult about something you are creating for them, they're super positive, even about the stuff they don't like. So it was a lot easier to get more robust, more real feedback by removing the human element and saying, "Hey, tell us how you really feel." We got some amazing feedback that way.

+ +

CHAD: That's interesting. And just in terms of timeline, was this happening pre-pandemic or post-pandemic?

+ +

TIFFANY: This was post-pandemic. Well, we really started doing this design work in the summer of 2020, so right in the middle of the pandemic, yes.

+ +

CHAD: Right. And so when you talk about these interviews and all that kind of stuff, everything was remote.

+ +

TIFFANY: Yeah, everything was remote, worked fantastic. That has been one of the cool things about being in this space, especially in design space, technology design, and aging, is that the acceleration of the technology adoption that happened in 2020 was mind-blowing.

+ +

I started working with design with older adults in 2014, building them different types of applications. And it just was incredible the level of comfort that I saw in 2020 amongst a much broader audience compared to 2014, 2015.

+ +

CHAD: Yeah, we've definitely seen that as well across different products. And the underlying reason is bad, but it certainly makes what we're doing a lot easier to have more people comfortable, even with little things like being on a Zoom call and knowing how to share their screen. Little things like that would sometimes be a big hang-up for getting good interviews and good feedback with people.

+ +

TIFFANY: Absolutely, absolutely, and doing some relatively complex things. Like, we were trying to validate doing a two-factor authentication, and we were able to do it virtually. So it's really giving us some really neat tools to reach a broad audience.

+ +

CHAD: A little while ago, you called out that there are patterns for building applications for certain ages. Can you tell me more about that?

+ +

TIFFANY: Sure. There's actually been a lot of research done in this area. I've contributed a little bit to it. [laughter] So what we really found especially early on...and I was involved with a project to take the connect technology and the Microsoft Connect technology and modify it to deliver a fall prevention program to older adults.

+ +

So in my previous life as a physical therapist, I have a Ph.D. in human movement and did a lot of research in healthy aging and injury prevention. And older adult falls is a fairly significant public health issue. And there are a lot of cool things you can do to address it around exercise. But the problem is scale. So how do you actually bring some of these exercises to older adults at scale as opposed to one on one? So that's the context behind this.

+ +

And so we started working with Microsoft SDK, building this out. And what we quickly realized is that the things that tend to make, let's say, a video game really cool and engaging are actually the worst things you can put into design if you're introducing an older adult or someone who's not comfortable with technology into a game. So you need a very simple interface, to begin with. And you need very straightforward commands.

+ +

And so it's funny because, in 2013, 2014 the people that were in this space all came from the gaming world. So they'd make these really beautiful backgrounds and things jumping and popping out. And you would lose your user within two minutes because it was just so visually overwhelming.

+ +

And one of the things that's interesting is as we get older, our brains are just not as flexible. They're super smart, but they get easily distracted. So what we learned is if you keep your user interface super simple, and then you make your early experiences very positive, so you keep the tasks very straightforward, you show success, what happens is your user gets a ton of self-efficacy. And they start to really realize that they know exactly what they're doing because they do. And then you can start doing some more interesting things.

+ +

So what we found is with our technology, as we got our users, okay, they're using it three times, they're using it four times. They're being super consistent doing this exercise program. Let's make it more visually engaging then they could actually handle it because they weren't so worried about what do I do next to go forward in the exercise program?

+ +

So yeah, so when you think about design, that was a really long-winded answer, sorry.

+ +

CHAD: [laughs] It's okay.

+ +

TIFFANY: But you want to keep things super simple and straightforward. You do need to infuse it with compassion and empathy, and if you can do small successes, really, really helpful. The other thing that is incredibly helpful, and this is going to sound a little hokey, is that any kind of avatar or chatbot who's super positive really, really can have a big impact.

+ +

Because a lot of times, older adults are by themselves trying to navigate this thing, and they have no idea what's going on. And if a chatbot pops up and says, "Hey, you're at this stage, do you need any help?" Or "Hey, you pushed the red button, good job." There's this very interesting relationship that gets built with older adults and chatbots and avatars. They engage with them much more.

+ +

And I think ultimately what I saw because we were using an avatar to lead through exercises is that self-efficacy increased because even though the avatar was leading them through the exercises, they ultimately knew it was them. Compared to if I was leading them through the exercises, there's always that yeah, I did it, but Tiffany taught me how. Whereas this is well, I did it, and the avatar taught me how, which really means that I actually did it. So I can actually do it. It's a really cool space.

+ +

CHAD: In validating the exercise format through those surveys and that kind of thing, what did you learn in terms of the format? Was animated ones winning out?

+ +

TIFFANY: Absolutely. What we learned was animation, hands down 100%. We also learned that animation plus narration really was the winning ticket. What we had tested we did some A/B testing where we did animation plus narration, and we had the exercise instructions written with the assumption that, well, some people are visual, and some people are auditory, and some people want to read the exercises. And we compared that to just animation plus narration and no written instructions. And the feedback we got was that it was too much.

+ +

Like, you're reading the instructions, you're watching, and you're listening, and it just was confusing and overwhelming. And sometimes it wasn't an exact match because when you're narrating an exercise versus reading about it, the words aren't always exactly the same because sometimes it just doesn't make sense to make them the same. But when you just had the narration with the exercise, people were really happy. They could see it, they could hear it, they could replay it.

+ +

And the other thing that was really nice about that particular format is it also gave a little bit of space. And this is on a mobile device, so when I say little space, I do mean little space where if the therapist had any specific cues, they could input it in there. So then now the patient's got...they can see the exercises, they can hear how to do it. "Oh yeah, and my therapist said, 'Make sure I put all my weight on my left leg.”’ So that just seemed to be the right package as opposed to dumping all of this information on the user.

+ +

CHAD: One of the things, when I've worked with people or organizations before that can become a bit of a blocker, is identifying something like this. Oh, animations with narration that's what this should be and then needing to produce all of that in order to bring the product to market to create it all from scratch. Was this material that you already had at your disposal? Or was it going to need to be created?

+ +

TIFFANY: It was going to need to be created. And the way we addressed that issue is we looked at, for lack of a better word, what are those key bread and butter exercises that just about every therapist prescribes to just about every person? I mean, it still was a sizable lift, but again, it wasn't an overwhelmingly huge production.

+ +

So we went ahead and said, okay, table stakes. We've got to have these in because if you don't, then it's not really usable. And of all of these, which are the ones which are generic enough that if we built it once, a therapist could put in additional instructions to do any kind of modifications? So that was really how we addressed that.

+ +

I would say if somebody is starting completely from scratch, pick a total of 10 exercises or a total of 10 things and just pilot that and just try to do low-fidelity prototypes and just validate it before going down the path.

+ +

CHAD: So in the story here, we're moving towards actually building something. Was there a go/no go point in the product's life cycle where you needed to get sign-off on something in order to decide to actually bring this product to market?

+ +

TIFFANY: Yes. And interestingly, we are in that point at this exact moment in time. [laughter] So we're at the point where it's released in alpha. We're getting some really great feedback. And on the clinician side, we're back to the original challenge around building something for patients.

+ +

We are still actually putting finishing touches on making sure that we can really secure this database the way it needs to be secured in 2022 because things, again, are moving pretty rapidly. So we are waiting for our go decision as we speak.

+ +

CHAD: But we did build something.

+ +

TIFFANY: Yes.

+ +

CHAD: So you didn't need to get full sign-off and go/no go before going from prototype to starting to build something.

+ +

TIFFANY: Correct. Yes, yeah. Yes, sorry.

+ +

CHAD: No, it's okay.

+ +

TIFFANY: We had, like I said, we were really good communicating out. We had all the data to support the decisions that we made. We felt like we had a couple of very minor outstanding things that we knew that needed to still be addressed. But we also felt we were at that point where we could go ahead and build. And once we got in people's hands, we probably have much better data on how to address the outstanding items.

+ +

CHAD: So given that you're at the point of you've gotten some things in people's hands, you're now making sure that this can be a product that you fully bring to market. What are some of the factors that are being looked at? And you mentioned security is one. What are some of the others?

+ +

TIFFANY: Some of the others...I will say one of the things that is not a factor but was a factor early on is, hey, wait a minute, can older adults really use this? Are they really going to want to use this? That's a slam dunk. Yes, they can use it, and yes, they really want to use it. Plenty of data there.

+ +

So one of the factors that's...believe it or not, the pandemic is actually throwing us a little bit of a curveball in the sense of there is so much transition happening in healthcare right now that we're having a couple of little challenges around...some of our clients are actually changing their settings.

+ +

So our first target market is people who are in home health. Well, if all of a sudden you are going from skilled nursing and opening up home health, there are a lot of factors you've got to balance. So that's been a little bit of a curveball. And it's also been a curveball in finding our early adopters to really go ahead and test it out.

+ +

And then the final thing that is a big challenge, and I think it's a challenge for everybody, is integration with pre-existing systems because there's so much variability and variety of EMR systems. I'll give you a great example. You could have a skilled nursing facility that has one EMR system, and that skilled nursing facility could contract with a rehab therapy company who uses a different system, but they're both seeing the same patient.

+ +

We want to be super strategic about...because, again, that's a huge resource suck of looking at those API integrations. That's one of the things that we're really doing a deeper dive into now to really figure out where do we actually put these resources? What's going to give us the most bang for our buck? And knowing that the target is moving constantly.

+ +

CHAD: What do you do while your...one of the challenges can be like, oh, we've got a team ready to build the product. Are you in a holding pattern now? Or what do you do? How do you manage that?

+ +

TIFFANY: There are two ways to manage, and one is going back to your product right now and doing more testing, which is always a good thing because you're just refining, refining, refining. It’s tricky, though, because when you've got a lot of limits on resources, especially human resources, lots of projects going on, the tricky part is can I keep my team, or do they need to get repurposed?

+ +

And I think it's all about having really honest conversations and if they are going to be pulled into another project, making sure everybody's on the same page about what that looks like so that if you are in a holding pattern, when you get off that holding pattern, that there's not a huge delay. Lots of conversations, lots of discussions, yeah

+ +

CHAD: Well, I wish you the best in working through all of that and bringing this product to market. I know you've been a tremendous partner in working on this together. I know the team has enjoyed working with you. And we work with a lot of people at different companies, and your experience in navigating this has been notable.

+ +

TIFFANY: Thank you. The team was amazing. I mean, it is a really great group of people, really open, at the same time, really able to crystallize some of the challenges in a way that was incredibly effective. So yeah, it was really a fantastic experience, and I'm very grateful for it.

+ +

CHAD: So if folks want to follow along with you or get in touch with you, where are the best places for them to do that?

+ +

TIFFANY: Either on LinkedIn. I, of course, have a space on LinkedIn but also at Relias. And my email is tshubert@relias.com.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Tiffany Shubert.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+2-tAWe7z + + ]]> + + Chad Pytel + Tiffany Shubert + + + 406: thoughtbot 2021 Year-in-Review with CEO Diana Bald + https://podcast.thoughtbot.com/406 + fdddc918-ee19-4f2f-92d9-6e413305a545 + Thu, 13 Jan 2022 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Chad talks to the CEO of thoughtbot, Diana Bald, about 2021 in retrospect. thoughtbot, as a company, has settled into a new structure that contains different teams and committed to becoming a fully remote organization. + +Last year, Diana successfully transitioned into taking over the company's CEO role. She and Chad talk about the improvements the company made in 2021, including DEI (diversity, equity, inclusion) efforts and training sessions, and look ahead to some improvements coming in 2022, such as an expansion of the apprenticeship program. + 48:24 + no + + + Chad talks to the CEO of thoughtbot, Diana Bald, about 2021 in retrospect. thoughtbot, as a company, has settled into a new structure that contains different teams and committed to becoming a fully remote organization. +Last year, Diana successfully transitioned into taking over the company's CEO role. She and Chad talk about the improvements the company made in 2021, including DEI (diversity, equity, inclusion) efforts and training sessions, and look ahead to some improvements coming in 2022, such as an expansion of the apprenticeship program. +P.S.: thoughtbot is hiring! To see open roles, visit thoughtbot.com/jobs (https://thoughtbot.com/jobs). +Follow Diana on Twitter (https://twitter.com/dianabald) or LinkedIn (https://www.linkedin.com/in/dianabald/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). +Email Diana at dianabald@thoughtbot.com. +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today back again is Diana Bald, the CEO of thoughtbot. Diana, welcome back to the show. +DIANA: Thanks for having me back, Chad. Hello everybody out there. +CHAD: You joined us in the spring; I guess is the best way to put it where we talked about the transition from me to you of CEO. And it feels like it was actually simultaneously both just yesterday that we did that recording and a long, long time ago. How has this year been for you? +DIANA: Yeah, I completely agree. It feels the same way for me. [chuckles] This year has been interesting and eventful. Well, 2021 has been. +CHAD: So we're recording this just in the dawn of 2022. Looking ahead, we're bright-eyed and ready to go to the New Year, right? +DIANA: That's right. +CHAD: So I thought that it'd be good to do a little bit of a retrospective or a review of 2021. A lot changed for thoughtbot. And the last time we talked about it was way back at the beginning of all those changes. +And I've had all the managing directors of the different teams on now to talk about the different teams, and what they're focused on, and how they're working, and what their goals are. And I thought it'd be fun to do that for thoughtbot overall with you. +DIANA: Yeah, I think it's a great idea. +CHAD: Cool. So since we last talked, we really settled into the different teams and the new structure. And even little things like we've sublet most of our office spaces and those kinds of things. I'm really reaffirming how things have gone. But I'm curious, just at a high level, what's been the most surprising thing for you about 2021? +DIANA: [chuckles] That was not a question I was expecting. +CHAD: [laughs] +DIANA: The most surprising thing for me was (There were a lot.) I think how quickly we put everything together actually. That was probably the most surprising thing. I think that we were able to reorganize and pretty much just get to work in the new team structure right away. +There wasn't a lot of reinventing. We reinvented when we redefined. But as we started doing the work, it was very logical, like, oh, this makes a lot of sense. These teams break out very nicely. So that speed in which that happened, I think, was the biggest surprise to me. +CHAD: I know that some people said we moved maybe too quickly on some of those changes. How do you respond to those people? +DIANA: [laughs] It's different personalities. Well, can I take a philosophical perspective? +CHAD: Yeah, totally. +DIANA: Okay. So I have a frame of mind as life doesn't happen to us. It happens for us in the sense that there is never a perfect time to do anything. One can be preparing, preparing, preparing, and it's good. Preparation is great. Analysis is great. All that stuff is good. But there's never going to be perfect anything. In fact, it's better to get started to get the feedback because the feedback is real. +And it's kind of like the way that we actually work, in fact. You respond, and you iterate based on what the circumstances are telling you. And I think that's the difference in point of view. So, for me, I thought the pace was nice. But I could see why other people might have thought we moved too quickly. +CHAD: So I forgot to mention the episode number if folks want to go back and listen to more of the details. It was Episode 392 (https://www.giantrobots.fm/392) where we talked, and then Episode 393 at giantrobots.fm/393 (https://www.giantrobots.fm/393) is where we talked about the details of the different teams and going fully remote, so if folks want to go back and listen to that. And then obviously, I've been talking to the different managing directors recently. +So now that we're almost a full...actually, I think we're a full year from when we actually made the changes. +DIANA: January eighth was the day. +CHAD: So we're a few days shy of a full year. I think there are really two aspects of this whole thing. There was the concept of going remote and committing to being fully remote. And there's the concept of then reorganizing the company in a way that was supportive of that. +And a lot of that was driven by the fact that we were really organized previously around the geographic studios and how we didn't feel like continuing that way was going to be something that would be sustainable for us over the long-term, both from a sales and business perspective but from a people perspective too. +And so we talked about the teams and how quick and how I think overall well that has gone. How about the fully remote aspect? How has it been for you personally? That's one way to put it. +DIANA: Well, I think that remote should be taken into context. We went remote in a time when the entire world was going remote. And I think that if we had gone remote at a different time, our experiences would be a little different because, with the start of the pandemic, we had a lot of limitations to our freedom because we were on lockdown. +And so when you go remote in a time of lockdown, and a time of limitations to freedom, it's very different than being remote at a time when you have the flexibility to go work out during the middle of the day, go pick up kids from school or whatever one does when you have flexibility. [chuckles] +So I think that the time that we started remote helped us clarify that yes, this is something we want to do. But I think our experience was tainted because we were in lockdown at the time, and our freedoms were very limited. +If our freedoms weren't so limited, we had planned, as you know, because we talked about it, having pop-up offices or having the ability to bring people together, and we weren't able to do any of those ideas. The pandemic took much longer than we thought it would for us to get to that. And right now, we're back in that place where Omicron is going on. And we're still kind of semi...not really locked down, but a lot of us are being extra cautious. +And then, for me personally, I'm enjoying the freedom. I like the freedom. But I'm also very cautious because I have to protect my family. And I just need to be very careful when I meet with people and things like that. +CHAD: Well, I agree that the social-emotional impact of how things have been for the last two years basically has made this transition difficult for a lot of people, myself included. And we've needed to be mindful of that, I think, as we try to move forward as aggressively as possible towards the way things we want to be. +I think it's been challenging for myself, for team members to realize that the way things are now isn't necessarily the way things are always going to be. We will be able to be in person. We will be able to visit each other. We'll be able to have those pop-up offices and that kind of thing that we've been limited to do. I'm really looking forward to that sometime in the future. +DIANA: Yeah, for sure I am as well. +CHAD: The other side from the business has been we're not getting pressure from clients. I feel like I'm revisiting this topic. [chuckles] I know last time we talked, it was like, I wonder what it's going to be like when we start getting clients back in person. And is there going to be pressure to be with them? And that kind of thing. +And unfortunately, because of the pandemic going on, we haven't been getting that pressure. Now, that works for our business because it just relieves the pressure or the need to travel or schedule things and that kind of thing. +But that being said, I'm more optimistic than I was before even though we haven't truly lived it that not only will clients...and that we have a really good way of doing things like design sprints and everything remotely but that there will be a benefit to getting together at the start of projects once we can safely do that and everything. +And I think people will better understand the concept of we're getting together to kick off the project or to do the design sprint. We could do it remotely, but we're choosing to do it in person with the understanding that it's totally fine to go back remote after we've had that in-person kickoff. +DIANA: Yeah, and I think that there's going to be some situations where it will be better to be remote to have the sprint and other situations where let's say you want to test something with a live audience or you want to get feedback from live people interacting with a physical object or something like that where it would make sense to have the physical in-person component. And other things are better with a brainstorm to have it be digital. +I think it just depends on the circumstances and the client and what they're looking to achieve. And having that flexibility that we don't currently have right now because of the variant is something I'm looking forward to. +CHAD: So when we talk about the transition and you taking over the CEO role, I said that one of the reasons why I thought that was the right thing to do and was excited to do that was because I thought that you were going to be better for what the company, and particularly the managing directors and the other leaders at the company, needed to get to the next stage. +And I forget exactly how much...a lot of that is baked into getting to the next stage of thoughtbot. One is resiliency of team and leadership and not having it be based solely around me. That's certainly one aspect of it. The other is your deep experience with sales and marketing; business development better match what we need to do going forward in terms of building, getting to the next levels of revenue, and sustainability. +And at the time, you were still learning, or maybe learning is the wrong word. How would you describe it? Basically, like getting a handle on things before making decisions or changes to move forward with certain aspects of how we do business development and that kind of thing. +DIANA: Yeah, I think I understand what you're saying. +CHAD: And so now that we're significantly past that point, what are some of the things that you've done or focused on with thoughtbot business development with thoughtbot overall that you would consider positive changes? +DIANA: I think the introduction of Rocket Fuel is one that I would consider a positive change in that direction. We had...I don't know if we want to re-familiarize the audience with the theme of rocket. +CHAD: Yeah, I totally think you should because I think it might come out of nowhere for people. +DIANA: [laughs] So we organized around a theme to make it easier for us to convey what we're doing. And you could think of the stages of a rocket from ignition to blast off in orbit. And basically, it's a fun way of saying that we have an end-to-end product development process. +And so everything from ideation and validation that's our Ignite team, to building and going to market is our Lift Off team. Scaling and transforming is our Boost team. And supporting and maintaining is our Mission Control team. +So when you have a rocket, you need fuel. [chuckles] And so that's where we introduce Rocket Fuel, which is basically business development and marketing. And what we did is we changed it from being two different ways of approaching, driving the business into business development being the driver and marketing being the support. +And what I mean by that is it's more strategic, in line with the different stages of where we are. So for the Ignite team, their needs are very different than for the Boost team. So when we're in the ideation validation stage with a client, it's very, very different than a client who's in the transformation or in the scaling stage of their product. +So having that mindset of driving that phase of product development has been very helpful to us because then we can apply the marketing tactics, strategies, plans around the stage of that product lifecycle. So that's been something that I think has worked really well this past year. +CHAD: So what does the Rocket Fuel team look like? What are the different roles on it? +DIANA: Well, it's small right now, but we're growing it. We have Kelly, who is our Associate Director of Business Development, and she's focused on supporting more of the implementation of some of the ideas that are coming out of each of the marketing tactics that I mentioned earlier. So whether it's partnerships with different organizations or whether it is campaigns that we're running so overseeing those, and she's also stepping in when the managing director has to step away for a few months, maybe somebody is taking paternity leave or something like that. Kelly stepped in there. +And then we have in sales enablement Liz who's serving as a Sales Enablement and Business Development Manager. And she's really helping us get exactly what her title says, enable the sales process. So she's putting together the marketing collateral. She's got our CRM system, getting that organized and up to date with information. And she's starting to work on updating our handbook with business development information and marketing information that's changed since we were in our old structure. So she's getting that in line. +So she's more behind the scenes and more enabling us to move quickly. And Kelly is more on the strategic end of it, helping us build out the plans that'll drive the growth of each of our teams. +CHAD: And Liz is also helping respond to RFPs and making sure things move forward or are pulled together for making proposals and contracts with clients, right? +DIANA: Yeah, she's doing a great job on that. +CHAD: I think all of those things are something that we had talked about doing for a while, having someone be able to help with those kinds of things, especially when we have a world where managing directors at thoughtbot are responsible not just for sales but for the whole business that they run. +And so they have a lot on a day-to-day or a weekly basis of what they need to spend time on. So having someone who can help them have time to spend on things that are not sales and to make sure that sales move along quickly, I think, has worked really well. And it was something we had talked about for a while, and I'm really happy to see it come to fruition. +DIANA: Yeah, I am too. I agree; it is helping the managing directors take a breath. They need sustainable lives as well. And it's good that we're able to help them in this regard. I think we can help them even more. Liz has only been with us for a few months. And as she gets more and more comfortable, she gets more and more ideas and starts to run a little faster, which is great to see her do that. +And the same with Kelly, as she's wrapping her arms around her new role, she is also coming up with a lot of ideas. And it's exciting to see them work because they energize each other. [laughs] It's really cool. +And we're also recruiting for an Associate Director of Business Development for Mission Control to help us grow that team. If anybody out there is listening, and you know of anyone, [laughs] encourage them to apply. +CHAD: Yeah, that's a really good point. So that Mission Control does DevOps, maintenance, SRE work, so we're really looking for someone who has experience growing and building that kind of business. And it's quite honestly a big growth opportunity because there's a real opportunity to start as the Associate Director of Business Development in that business and grow into more of a Managing Director role, right? +DIANA: Absolutely. We see it as an opportunity to come in on the ground floor; essentially as the very fast-moving, high potential team gets going. So it's a super exciting opportunity for people that are interested in DevOps or Site Reliability Engineering or anything else that we're doing in that space of support and developing. +CHAD: Great. Well, hopefully, someone hears this and says, "That's for me. I want to apply." If that's you, you can go to thoughtbot.com/jobs and check it out there. I'm making my hard pitch here. We also have some outside consultants helping with running different campaigns and digital marketing activities, right? +DIANA: That's right. We are working with outside consultants to help us run some targeted campaigns based on some of the strategies that Liz and Kelly are developing. And they're doing the actual implementation of the marketing. So they'll buy the ads; they'll run them. And we also have somebody helping us with social media. Mandy is doing that. She's doing a great job of that. +And we have Tori, who's still helping us out with some of the digital marketing campaign, conceptualizing them, and transitioning some of that work that she was doing on the CRM, transitioning some of that over to Liz to take over our sales enablement. So a lot of activity happening over here at Rocket Fuel. +CHAD: So to put it as plainly as I can, thoughtbot has been successful. We've been particularly successful from a culture and team, and thought leadership standpoint. But we haven't been incredibly successful in making a company that operates at the level that we do and generates enough profit to be really comfortable that when a pandemic hits...that's an extreme circumstance, but there are ups and downs in every business. +And our margins haven't been historically as large as other consulting companies and that kind of thing because of the kinds of team we have and the way that we run the business. And so a big goal of when we talk about taking thoughtbot to the next level has been sustainability and making sure that we operate with enough cushion that we can more than weather downturns or ups and downs in the business without having to let people go or make significant changes. +And if people listened to the prior episode, they know that we had actually made significant progress towards that goal in 2019. And we were feeling really great going into 2020 about what we were going to accomplish. And then, in April of 2020, we had a significant decrease in revenue all at once, which really threw the business into turmoil because we hadn't been operating with that significant margin, a sustainable margin. +So we spent 2020 recovering from that, making sure that we had corrected some of those fatal flaws. And we saw, I think, a lot of that come to fruition in 2021 and had a really sustainable year where we met and exceeded our goals. I'm really happy about that. I assume you're happy to. [laughs] +DIANA: Yes, I'm really happy about that too. [laughs] I think that it's something that we haven't celebrated, and we need to celebrate it. It was actually a really great year for us financially. And I talked about speed earlier. And I said I was pleasantly surprised with the speed. +And one of the factors is that in the first quarter of last year, things started to come together for us in that vein of financial sustainability. And we were able to maintain it every quarter of the full year. That's pretty great. And we should pat ourselves on the back for that. Congratulations, Chad. [chuckles] +CHAD: Congratulations, Diana. You and I have talked about this before. So overall, the market recovered in a really good way for services, businesses, for software development. So that boosted our ability to really go above and beyond. But even putting that aside, it took a lot of work. It wasn't easy. And it was through the fundamental changes we had made that we were able to take advantage of that good market, I think. +DIANA: Yeah, I agree. And the intentionality of what we were doing, I think the reorganization helped us see clearly the benefits of each team. Obviously, today, I have a much clearer insight into each team's strengths and each team's capabilities than I did a year ago when we last talked. +I think we are still trying to get our...is it going to work? What is it going to look like? And now it's like, oh, this is so obvious. This makes a lot of sense. The teams are working on very different aspects of the product development lifecycle. And I think that intentionality also helped us with our goals. +CHAD: And I think that one of the goals of doing that too was to free people up to better understand and focus on the kind of work that they wanted to do rather than trying to do everything everywhere. And for the individual person at thoughtbot, never knowing what your next client project was going to look like because it could have been any of our types of clients that we have. +And I think overall, what I've heard from the team is that it has been a good opportunity to reduce those surprises, get better at the kind of thing that you're working on now, even if ultimately that means okay, you've done your stint in Lift Off and now you want to move over to Boost, or you've been in Boost, and now you want to give Lift Off a try. At least you can do that with intentionality as opposed to never being quite sure what your next project is going to look like. +DIANA: Yeah, exactly. There are some people that like that variety of moving back and forth, and that's good that we can make that happen. And then there are others like you said, that really want to hone in on an area of specialty and get better at that particular thing. +CHAD: I think there's a benefit to us even just having words to use to describe the different kinds of projects now because we never had those words to use before. So when now internally people say, "Oh, this is a boost-style project," that means something to people. And I think it helps us talk about the work that we're doing or we might do for customers. +DIANA: Yeah. +CHAD: Cool. So what else happened in 2021? [chuckles] +DIANA: What else happened in 2021? Well, we did a lot of DEI training, and that was great. I learned a lot in that training. I thought actually that I was pretty hip with everything. I thought I've been involved in DEI activities all my life, so I get it, of course. But then, once I took the training, I was like, wait, there's a lot to learn here. I thought I knew a lot. But I'm learning a lot. +There were several courses and several sessions. And with each session, I came away learning a lot more than I thought I would and having a greater appreciation. I think one of the greatest appreciations I learned last year was an appreciation for words, how important it is to think about what you're saying. A lot of times, we just talk, and it's important to really think through what one says. I took that to heart from the training that we got. +CHAD: And I think people might hear that and say, "Oh, you're talking about being politically correct," and perhaps maybe having a negative reaction to that. But I think one way to think about it is it's not just being politically correct for the sake of being politically correct. But words can have an impact on people, or the way that you talk about something can have an impact on people, either by making them feel bad or excluding them. +When you have a group of people working on something, people come at work with so many different backgrounds and experiences, and perspectives. And so, having an inclusive environment where everyone can contribute fully is super important to not only being fulfilled in our work but ultimately creating great products too. +DIANA: Yeah, absolutely. And that diversity is something that will make us have better products. But it also makes us; I think in many ways, better people by understanding where others are coming from, what they might have experienced in the past, and knowing that what is available to one person may not be available to others. +So it's not just political correctness but also a better understanding of humans and what we go through and that it's not necessarily equal for everyone. And it's not necessarily fair for folks. And that's sometimes easy to forget. And I think that training that we went through really reminded me. And it gave me an appreciation for the privileges that I do have and just a greater awareness that I'm so grateful for. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So we've had a DEI Council at thoughtbot for a couple of years now. And I think that we created it because of the studio model. We were very distributed as a company. And so we wanted a group of people that could come together, work on things, but also collectively, educate themselves and take action items and everything, and then take them back to their physical studios. +And I think that now with the reorganization, with the progress we've made, it's not that the Council doesn't work. But it's in a different spot in terms of what we're hoping to achieve as a company and the way that it's working. +So we actually have right before the end of the year, we opened a DEI program manager position, which is a full-time position at thoughtbot for someone to not do all of the work that the council is going to do but a centralized thing to make the distributed nature of the...to sort of empower the council, and free up time. +We're all on client work a significant portion of our time. And so striking the balance between having DEI ingrained in the company, having everyone have enough time to work on what needs to be worked on, and to have it all be managed, we looked at that whole picture and said, we think that the Council could be even more effective if we have someone on board who can work with them full time basically. +And people might be saying DEI Council full time? It's not just the council. So it's diversity, equity, and inclusion. So it really permeates everything about our culture, and how the company works, and how it functions. And there's a lot there. +So that person is going to be part of the operations team, which is my team. And they'll be ingrained, you know, part of everything that we do to make thoughtbot operate but through the lens of is this equitable? Are we inclusive of the people that we have on our team in Africa and South America, as well as the United States now? +That's a huge thing for us, making sure that we're setting things up in a way that works for everyone at the company. And we're more internationally diverse than we've ever been before. And so that has been something that takes up a lot of our time. And we want to make sure we do a great job with it. So that's one of the things that this new person is going to do. +DIANA: Yeah, and one of the things I'm really excited about for this person is putting some metrics together for us. It's been hard for us to quantify our progress in DEI. And I know that this individual will be doing that, which is to me exciting because we're going to be able to see how are we really progressing with these initiatives? I think that's going to be great. +And also, being able to partner with other organizations just outside of thoughtbot is going to be interesting as well because our DEI Council does it, but none of us have a lot of time to actually do too much of it. Everybody's got like you said, client work and other things they have to work on. So that's another thing I'm really excited about this individual taking on is that outside partnership perspective. +CHAD: I feel like we have a lot of positions open right now. +DIANA: [laughs] We sure do. +CHAD: Not only in the operations or the non-designers and developers. We've got a lot of design and development roles open as well. +DIANA: Yep. Plug for the thoughtbot.com/jobs page. [laughter] +CHAD: Yeah. Well, one of the things that I'm really excited about going into 2022 we've had the Apprenticeship Program for 11 years now. We say on the website we've done over 50 apprentices. I think it's more like over 75. I just stopped doing the count a while ago. +But we haven't been able to do it consistently previously because when we were distributed among the different studios, and everything was based on who you worked with in person, we needed to make sure, you know, not every studio was even large enough to have enough mentors to be able to have apprentices. But we also needed good projects for mentorship and having apprentices on them. +And we also needed to make sure, like, oh, if we take on an apprentice in Austin, we need to make sure that the Austin studio needs another Rails developer. And so it was pretty limiting. But even though it was limiting, we did lots of apprentices. And it's been super successful. So many leaders at the company started as apprentices. +DIANA: Christina comes to mind. She's like a development director now. +CHAD: Yeah, exactly. A lot of the development directors at thoughtbot started as apprentices over the years. So I'm super excited because this is another thing that no longer being in-person studios unlocks for us is to say basically thoughtbot as long as we're hiring across all of thoughtbot, we will always have the need for designers and developers. +And so we can make the Apprenticeship Program more of a rotational program. No matter where you live now, you can join. We can do remote apprenticeship like all of our positions. And you can rotate among the thoughtbot teams with a great mentor from each team and then be promoted as a designer or a developer onto one of those teams that has a position for a Rails developer or a designer. +And that is going to enable us to have consistent apprenticeship positions across the company open all the time with a consistent application process with timelines laid out for when deadlines are going to be for applications and when we're accepting people, and when people start. And I'm really excited about that. +I think it's going to be not only great for apprentices, which is actually one of the primary reasons why we do it but also great for thoughtbot to get this consistency to what has been a really valuable hiring channel for us in the past. +DIANA: Absolutely. I think that's one of the things I'm most excited about, to be honest with you, is that Apprenticeship Program because of everything that you mentioned. And it's not like we just need to limit it to one person. It could be a group of people going through the program together, which gives them a sense of camaraderie as well and a second incoming class. We have an incoming class. [laughs] +CHAD: Right, right. My only regret is that even just in this first batch, we can see...or I've just had the potential of the Apprentice Program for us reinforced. In this batch, we have almost 1,000 applications across the two Launchpads with the design and development positions. It's incredible. [laughs] +DIANA: That's so amazing. +CHAD: Even though we're having more apprentice positions than we've had in many years going for 2022, it's still not enough. There are so many people that could be great fits for thoughtbot that we might not be able to have enough bandwidth to take on. So I'm looking ahead to the next thing as like, how can we grow enough to have even more apprentices? +DIANA: Well, let's get Rocket Fuel to help with that. +[laughter] +CHAD: Yeah. I've often said that hiring great team members really isn't our problem. Our problem is consistently having more than enough work to be fulfilled, to be picky and choosy, while also having enough work for our team very reliably, weathering those ups and downs. And when we turn off hiring, it hurts our ability to hire overall because it takes longer to ramp it back up and that kind of thing. And I think you saw that throughout the course of 2021. +We had to turn off hiring for a while in 2020. And when we resumed it, it took quite a while for those wheels to spin back up and for enough people to get through the pipeline. Because even though we get a significant number of people applying, we really only hire less than 1% of the people who come across because our standards of what we want when we add people to the team are high. +DIANA: Yeah, it's true. It's challenging. We really did feel that impact pretty hard for a while there; the repercussions of not having the hiring open in 2020 were felt for sure. +CHAD: We also made the decision that we were going to focus on making sure that when we started hiring back up, we didn't just necessarily go right back to the way that we were doing things before in terms of all of our process. +So we used to have a lot of automation in place because of the number of applications. And we didn't immediately put all that in place because sometimes that automation got away from us. We care a lot about the hiring process. And we wanted to make sure that we just didn't blindly turn it back on because we had a sense that it wasn't 100% working for us. +And the other was that we made the decision from a DEI perspective to make sure that we didn't move forward on starting interviewing for a position without having the candidate pool we were choosing from reflect a representative sample of the United States. +And that's in the tech industry; if you put a role online and just let people come into it organically from a normal job pool, the tech industry isn't representative of the United States demographics. And so, if you just let that status quo come in, you're going to see what's reflected in the tech industry. So that was another important but real limitation that we put on ourselves when we started hiring again. +DIANA: Yeah, it was painful, [laughs] but it was necessary. +CHAD: And I think we've seen as people move through the pipeline and as our hiring goes up that it was worth it, even if it wasn't easy and was difficult. +DIANA: That's how things usually are, right? +CHAD: Right. [laughs] +DIANA: Things are usually not easy. And usually, things that are worth it, there's work involved. +CHAD: And we're not done with DEI work and trying to build the kind of organization we want to have. You're never really done. So there's always something that we can do better. We still need to really speed up our hiring process, which has been pretty much stuck at a certain timeline for a long time. And figuring out a way to speed that up while still staying true to the kind of process and the qualifications that we want to put on the process continues to be a challenge for us. +DIANA: I think that's industry-wide, though. I don't think that's unique to us. There are a lot of companies challenged with hiring at the moment. There are a lot of reasons for that. But we definitely have to keep on top of it and try to figure out ways to make ourselves better. +CHAD: Yeah. I think the biggest problem is to the extent that if you lose people along the way that you would totally otherwise hire because they go to other companies first just because you didn't finish the process fast enough. That's the fundamental thing that we want to avoid. +DIANA: That's the real risk that we...I think we actually lost some people for that. +CHAD: Yeah, definitely. And over the years, despite trying, we haven't been able to significantly speed up our hiring process. For folks who aren't familiar, a big part of our process is having a few different stages. And the final stage being pairing, working with actual members of the team for the day. We pay for that day. And meeting the rest of the team and having a process which involves the rest of the team it's not just a siloed hiring team that's making all the hiring decisions. +But doing a full day visit as the last stage means effectively that we can never have two people interviewing for the same position. And then everyone being on client work and only really being able to do those visits on Fridays means that the fastest, unless we're willing to make a change to that, the fastest we can go to hire into any one position is one final stage interview a week. That's a bottleneck. +DIANA: That's a bottleneck for sure unless we have dedicated people doing the recruiting. Then that would be a challenge as well because that's all these folks would do. +CHAD: Right. And then the team would feel, you know, we gain a lot from everyone being part of the team. So that when people show up on day one, we can say, "Hey, everyone that you worked with, everyone that you met was a unanimous yes to you being here." +It builds a tremendous amount of trust and confidence on both sides, I think. And to not have that, I think we would need to then do a lot more work in building up that confidence of those new team members and of the team in that process and on day one when they show up. So it's an area of future work for us, definitely. I don't know what the solution will be eventually. But I do know that it's an area that we have to improve on. +DIANA: Yeah, agreed. +CHAD: Cool. Well, anything else on your mind before we wrap up? +DIANA: No. I'm looking forward to 2022. There's a lot that we want to do. And it's going to be an exciting year. It's already starting off exciting. [laughter] Though, I do want to talk a little bit about community now or? +CHAD: How about we give a little sneak peek in terms of what we're thinking for 2022? And then, in a little while, we'll have you back on to talk more about it. How's that sound? +DIANA: Yeah, it sounds great. +CHAD: Okay, community has always been a big part of thoughtbot. It's what has driven a lot of the open-source that we've done, our blogging. But what do you mean by community in 2022? +DIANA: Well, we started off this conversation by talking about remote and some of the pros and cons associated with it. And I think that one of the things that remote does there’s a lot of benefits to it. But I think that we need to help overcome the challenges, and I want us to do more of that in 2022. +So, for example, creating a culture where people feel the recognition that you might be able to do more in person than you do remotely or lessen feelings of isolation that some folks feel, bringing out the quiet voices among us, giving them space to talk and give their voice. How can we make that happen? +Finding ways for people to build relationships with each other and maybe people that have never met, that are on different teams. How do we make that happen? Just overall experiencing a positive, respectful and inclusive work environment. That at a remote level is something that I think we need to dive in deeper this year. And like you said, we can dive into that more at another time. +CHAD: Yeah, I'm excited. I feel it too. And it comes from I think maybe it was Stephanie or Louis that was talking about it, both members of our team who were generally like, when you were in person, there was an ease to either talking to someone off-hand or even just when you have a daily sync every day in person, it's easy to recognize a success and to have everyone applaud. +And when you aren't in person with each other, you need to work at it more to really foster that sense of team and community. And that's clearly part of what getting through 2021 and settling in and getting to the next level is about for us. +DIANA: Yeah, absolutely. +CHAD: Cool. Well, if folks want to get in touch with you or follow along with you, where are the best places for them to do that, Diana? +DIANA: I started off last year actually doing some tweets, and I'm not very good at it. I totally stopped doing it. But I'm going to try to do more of it. I can be found on Twitter @dianabald, first name, last name. I'm on LinkedIn, first name, last name. The good news about my name is that there’s not a lot of me out there, [laughter] people with my last name. So I'm easy to find. And by email, it's dianabald@thoughtbot.com. +CHAD: Great. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. I'd love to get some comments and questions in 2022 and bring them to the episode. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. +Diana, thanks again for joining me. +DIANA: Thank you, Chad. Thank you, everybody. +CHAD: And thank you for listening. See you next time. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Diana Bald. + + + Chad talks to the CEO of thoughtbot, Diana Bald, about 2021 in retrospect. thoughtbot, as a company, has settled into a new structure that contains different teams and committed to becoming a fully remote organization.

+ +

Last year, Diana successfully transitioned into taking over the company's CEO role. She and Chad talk about the improvements the company made in 2021, including DEI (diversity, equity, inclusion) efforts and training sessions, and look ahead to some improvements coming in 2022, such as an expansion of the apprenticeship program.

+ +

P.S.: thoughtbot is hiring! To see open roles, visit thoughtbot.com/jobs.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today back again is Diana Bald, the CEO of thoughtbot. Diana, welcome back to the show.

+ +

DIANA: Thanks for having me back, Chad. Hello everybody out there.

+ +

CHAD: You joined us in the spring; I guess is the best way to put it where we talked about the transition from me to you of CEO. And it feels like it was actually simultaneously both just yesterday that we did that recording and a long, long time ago. How has this year been for you?

+ +

DIANA: Yeah, I completely agree. It feels the same way for me. [chuckles] This year has been interesting and eventful. Well, 2021 has been.

+ +

CHAD: So we're recording this just in the dawn of 2022. Looking ahead, we're bright-eyed and ready to go to the New Year, right?

+ +

DIANA: That's right.

+ +

CHAD: So I thought that it'd be good to do a little bit of a retrospective or a review of 2021. A lot changed for thoughtbot. And the last time we talked about it was way back at the beginning of all those changes.

+ +

And I've had all the managing directors of the different teams on now to talk about the different teams, and what they're focused on, and how they're working, and what their goals are. And I thought it'd be fun to do that for thoughtbot overall with you.

+ +

DIANA: Yeah, I think it's a great idea.

+ +

CHAD: Cool. So since we last talked, we really settled into the different teams and the new structure. And even little things like we've sublet most of our office spaces and those kinds of things. I'm really reaffirming how things have gone. But I'm curious, just at a high level, what's been the most surprising thing for you about 2021?

+ +

DIANA: [chuckles] That was not a question I was expecting.

+ +

CHAD: [laughs]

+ +

DIANA: The most surprising thing for me was (There were a lot.) I think how quickly we put everything together actually. That was probably the most surprising thing. I think that we were able to reorganize and pretty much just get to work in the new team structure right away.

+ +

There wasn't a lot of reinventing. We reinvented when we redefined. But as we started doing the work, it was very logical, like, oh, this makes a lot of sense. These teams break out very nicely. So that speed in which that happened, I think, was the biggest surprise to me.

+ +

CHAD: I know that some people said we moved maybe too quickly on some of those changes. How do you respond to those people?

+ +

DIANA: [laughs] It's different personalities. Well, can I take a philosophical perspective?

+ +

CHAD: Yeah, totally.

+ +

DIANA: Okay. So I have a frame of mind as life doesn't happen to us. It happens for us in the sense that there is never a perfect time to do anything. One can be preparing, preparing, preparing, and it's good. Preparation is great. Analysis is great. All that stuff is good. But there's never going to be perfect anything. In fact, it's better to get started to get the feedback because the feedback is real.

+ +

And it's kind of like the way that we actually work, in fact. You respond, and you iterate based on what the circumstances are telling you. And I think that's the difference in point of view. So, for me, I thought the pace was nice. But I could see why other people might have thought we moved too quickly.

+ +

CHAD: So I forgot to mention the episode number if folks want to go back and listen to more of the details. It was Episode 392 where we talked, and then Episode 393 at giantrobots.fm/393 is where we talked about the details of the different teams and going fully remote, so if folks want to go back and listen to that. And then obviously, I've been talking to the different managing directors recently.

+ +

So now that we're almost a full...actually, I think we're a full year from when we actually made the changes.

+ +

DIANA: January eighth was the day.

+ +

CHAD: So we're a few days shy of a full year. I think there are really two aspects of this whole thing. There was the concept of going remote and committing to being fully remote. And there's the concept of then reorganizing the company in a way that was supportive of that.

+ +

And a lot of that was driven by the fact that we were really organized previously around the geographic studios and how we didn't feel like continuing that way was going to be something that would be sustainable for us over the long-term, both from a sales and business perspective but from a people perspective too.

+ +

And so we talked about the teams and how quick and how I think overall well that has gone. How about the fully remote aspect? How has it been for you personally? That's one way to put it.

+ +

DIANA: Well, I think that remote should be taken into context. We went remote in a time when the entire world was going remote. And I think that if we had gone remote at a different time, our experiences would be a little different because, with the start of the pandemic, we had a lot of limitations to our freedom because we were on lockdown.

+ +

And so when you go remote in a time of lockdown, and a time of limitations to freedom, it's very different than being remote at a time when you have the flexibility to go work out during the middle of the day, go pick up kids from school or whatever one does when you have flexibility. [chuckles]

+ +

So I think that the time that we started remote helped us clarify that yes, this is something we want to do. But I think our experience was tainted because we were in lockdown at the time, and our freedoms were very limited.

+ +

If our freedoms weren't so limited, we had planned, as you know, because we talked about it, having pop-up offices or having the ability to bring people together, and we weren't able to do any of those ideas. The pandemic took much longer than we thought it would for us to get to that. And right now, we're back in that place where Omicron is going on. And we're still kind of semi...not really locked down, but a lot of us are being extra cautious.

+ +

And then, for me personally, I'm enjoying the freedom. I like the freedom. But I'm also very cautious because I have to protect my family. And I just need to be very careful when I meet with people and things like that.

+ +

CHAD: Well, I agree that the social-emotional impact of how things have been for the last two years basically has made this transition difficult for a lot of people, myself included. And we've needed to be mindful of that, I think, as we try to move forward as aggressively as possible towards the way things we want to be.

+ +

I think it's been challenging for myself, for team members to realize that the way things are now isn't necessarily the way things are always going to be. We will be able to be in person. We will be able to visit each other. We'll be able to have those pop-up offices and that kind of thing that we've been limited to do. I'm really looking forward to that sometime in the future.

+ +

DIANA: Yeah, for sure I am as well.

+ +

CHAD: The other side from the business has been we're not getting pressure from clients. I feel like I'm revisiting this topic. [chuckles] I know last time we talked, it was like, I wonder what it's going to be like when we start getting clients back in person. And is there going to be pressure to be with them? And that kind of thing.

+ +

And unfortunately, because of the pandemic going on, we haven't been getting that pressure. Now, that works for our business because it just relieves the pressure or the need to travel or schedule things and that kind of thing.

+ +

But that being said, I'm more optimistic than I was before even though we haven't truly lived it that not only will clients...and that we have a really good way of doing things like design sprints and everything remotely but that there will be a benefit to getting together at the start of projects once we can safely do that and everything.

+ +

And I think people will better understand the concept of we're getting together to kick off the project or to do the design sprint. We could do it remotely, but we're choosing to do it in person with the understanding that it's totally fine to go back remote after we've had that in-person kickoff.

+ +

DIANA: Yeah, and I think that there's going to be some situations where it will be better to be remote to have the sprint and other situations where let's say you want to test something with a live audience or you want to get feedback from live people interacting with a physical object or something like that where it would make sense to have the physical in-person component. And other things are better with a brainstorm to have it be digital.

+ +

I think it just depends on the circumstances and the client and what they're looking to achieve. And having that flexibility that we don't currently have right now because of the variant is something I'm looking forward to.

+ +

CHAD: So when we talk about the transition and you taking over the CEO role, I said that one of the reasons why I thought that was the right thing to do and was excited to do that was because I thought that you were going to be better for what the company, and particularly the managing directors and the other leaders at the company, needed to get to the next stage.

+ +

And I forget exactly how much...a lot of that is baked into getting to the next stage of thoughtbot. One is resiliency of team and leadership and not having it be based solely around me. That's certainly one aspect of it. The other is your deep experience with sales and marketing; business development better match what we need to do going forward in terms of building, getting to the next levels of revenue, and sustainability.

+ +

And at the time, you were still learning, or maybe learning is the wrong word. How would you describe it? Basically, like getting a handle on things before making decisions or changes to move forward with certain aspects of how we do business development and that kind of thing.

+ +

DIANA: Yeah, I think I understand what you're saying.

+ +

CHAD: And so now that we're significantly past that point, what are some of the things that you've done or focused on with thoughtbot business development with thoughtbot overall that you would consider positive changes?

+ +

DIANA: I think the introduction of Rocket Fuel is one that I would consider a positive change in that direction. We had...I don't know if we want to re-familiarize the audience with the theme of rocket.

+ +

CHAD: Yeah, I totally think you should because I think it might come out of nowhere for people.

+ +

DIANA: [laughs] So we organized around a theme to make it easier for us to convey what we're doing. And you could think of the stages of a rocket from ignition to blast off in orbit. And basically, it's a fun way of saying that we have an end-to-end product development process.

+ +

And so everything from ideation and validation that's our Ignite team, to building and going to market is our Lift Off team. Scaling and transforming is our Boost team. And supporting and maintaining is our Mission Control team.

+ +

So when you have a rocket, you need fuel. [chuckles] And so that's where we introduce Rocket Fuel, which is basically business development and marketing. And what we did is we changed it from being two different ways of approaching, driving the business into business development being the driver and marketing being the support.

+ +

And what I mean by that is it's more strategic, in line with the different stages of where we are. So for the Ignite team, their needs are very different than for the Boost team. So when we're in the ideation validation stage with a client, it's very, very different than a client who's in the transformation or in the scaling stage of their product.

+ +

So having that mindset of driving that phase of product development has been very helpful to us because then we can apply the marketing tactics, strategies, plans around the stage of that product lifecycle. So that's been something that I think has worked really well this past year.

+ +

CHAD: So what does the Rocket Fuel team look like? What are the different roles on it?

+ +

DIANA: Well, it's small right now, but we're growing it. We have Kelly, who is our Associate Director of Business Development, and she's focused on supporting more of the implementation of some of the ideas that are coming out of each of the marketing tactics that I mentioned earlier. So whether it's partnerships with different organizations or whether it is campaigns that we're running so overseeing those, and she's also stepping in when the managing director has to step away for a few months, maybe somebody is taking paternity leave or something like that. Kelly stepped in there.

+ +

And then we have in sales enablement Liz who's serving as a Sales Enablement and Business Development Manager. And she's really helping us get exactly what her title says, enable the sales process. So she's putting together the marketing collateral. She's got our CRM system, getting that organized and up to date with information. And she's starting to work on updating our handbook with business development information and marketing information that's changed since we were in our old structure. So she's getting that in line.

+ +

So she's more behind the scenes and more enabling us to move quickly. And Kelly is more on the strategic end of it, helping us build out the plans that'll drive the growth of each of our teams.

+ +

CHAD: And Liz is also helping respond to RFPs and making sure things move forward or are pulled together for making proposals and contracts with clients, right?

+ +

DIANA: Yeah, she's doing a great job on that.

+ +

CHAD: I think all of those things are something that we had talked about doing for a while, having someone be able to help with those kinds of things, especially when we have a world where managing directors at thoughtbot are responsible not just for sales but for the whole business that they run.

+ +

And so they have a lot on a day-to-day or a weekly basis of what they need to spend time on. So having someone who can help them have time to spend on things that are not sales and to make sure that sales move along quickly, I think, has worked really well. And it was something we had talked about for a while, and I'm really happy to see it come to fruition.

+ +

DIANA: Yeah, I am too. I agree; it is helping the managing directors take a breath. They need sustainable lives as well. And it's good that we're able to help them in this regard. I think we can help them even more. Liz has only been with us for a few months. And as she gets more and more comfortable, she gets more and more ideas and starts to run a little faster, which is great to see her do that.

+ +

And the same with Kelly, as she's wrapping her arms around her new role, she is also coming up with a lot of ideas. And it's exciting to see them work because they energize each other. [laughs] It's really cool.

+ +

And we're also recruiting for an Associate Director of Business Development for Mission Control to help us grow that team. If anybody out there is listening, and you know of anyone, [laughs] encourage them to apply.

+ +

CHAD: Yeah, that's a really good point. So that Mission Control does DevOps, maintenance, SRE work, so we're really looking for someone who has experience growing and building that kind of business. And it's quite honestly a big growth opportunity because there's a real opportunity to start as the Associate Director of Business Development in that business and grow into more of a Managing Director role, right?

+ +

DIANA: Absolutely. We see it as an opportunity to come in on the ground floor; essentially as the very fast-moving, high potential team gets going. So it's a super exciting opportunity for people that are interested in DevOps or Site Reliability Engineering or anything else that we're doing in that space of support and developing.

+ +

CHAD: Great. Well, hopefully, someone hears this and says, "That's for me. I want to apply." If that's you, you can go to thoughtbot.com/jobs and check it out there. I'm making my hard pitch here. We also have some outside consultants helping with running different campaigns and digital marketing activities, right?

+ +

DIANA: That's right. We are working with outside consultants to help us run some targeted campaigns based on some of the strategies that Liz and Kelly are developing. And they're doing the actual implementation of the marketing. So they'll buy the ads; they'll run them. And we also have somebody helping us with social media. Mandy is doing that. She's doing a great job of that.

+ +

And we have Tori, who's still helping us out with some of the digital marketing campaign, conceptualizing them, and transitioning some of that work that she was doing on the CRM, transitioning some of that over to Liz to take over our sales enablement. So a lot of activity happening over here at Rocket Fuel.

+ +

CHAD: So to put it as plainly as I can, thoughtbot has been successful. We've been particularly successful from a culture and team, and thought leadership standpoint. But we haven't been incredibly successful in making a company that operates at the level that we do and generates enough profit to be really comfortable that when a pandemic hits...that's an extreme circumstance, but there are ups and downs in every business.

+ +

And our margins haven't been historically as large as other consulting companies and that kind of thing because of the kinds of team we have and the way that we run the business. And so a big goal of when we talk about taking thoughtbot to the next level has been sustainability and making sure that we operate with enough cushion that we can more than weather downturns or ups and downs in the business without having to let people go or make significant changes.

+ +

And if people listened to the prior episode, they know that we had actually made significant progress towards that goal in 2019. And we were feeling really great going into 2020 about what we were going to accomplish. And then, in April of 2020, we had a significant decrease in revenue all at once, which really threw the business into turmoil because we hadn't been operating with that significant margin, a sustainable margin.

+ +

So we spent 2020 recovering from that, making sure that we had corrected some of those fatal flaws. And we saw, I think, a lot of that come to fruition in 2021 and had a really sustainable year where we met and exceeded our goals. I'm really happy about that. I assume you're happy to. [laughs]

+ +

DIANA: Yes, I'm really happy about that too. [laughs] I think that it's something that we haven't celebrated, and we need to celebrate it. It was actually a really great year for us financially. And I talked about speed earlier. And I said I was pleasantly surprised with the speed.

+ +

And one of the factors is that in the first quarter of last year, things started to come together for us in that vein of financial sustainability. And we were able to maintain it every quarter of the full year. That's pretty great. And we should pat ourselves on the back for that. Congratulations, Chad. [chuckles]

+ +

CHAD: Congratulations, Diana. You and I have talked about this before. So overall, the market recovered in a really good way for services, businesses, for software development. So that boosted our ability to really go above and beyond. But even putting that aside, it took a lot of work. It wasn't easy. And it was through the fundamental changes we had made that we were able to take advantage of that good market, I think.

+ +

DIANA: Yeah, I agree. And the intentionality of what we were doing, I think the reorganization helped us see clearly the benefits of each team. Obviously, today, I have a much clearer insight into each team's strengths and each team's capabilities than I did a year ago when we last talked.

+ +

I think we are still trying to get our...is it going to work? What is it going to look like? And now it's like, oh, this is so obvious. This makes a lot of sense. The teams are working on very different aspects of the product development lifecycle. And I think that intentionality also helped us with our goals.

+ +

CHAD: And I think that one of the goals of doing that too was to free people up to better understand and focus on the kind of work that they wanted to do rather than trying to do everything everywhere. And for the individual person at thoughtbot, never knowing what your next client project was going to look like because it could have been any of our types of clients that we have.

+ +

And I think overall, what I've heard from the team is that it has been a good opportunity to reduce those surprises, get better at the kind of thing that you're working on now, even if ultimately that means okay, you've done your stint in Lift Off and now you want to move over to Boost, or you've been in Boost, and now you want to give Lift Off a try. At least you can do that with intentionality as opposed to never being quite sure what your next project is going to look like.

+ +

DIANA: Yeah, exactly. There are some people that like that variety of moving back and forth, and that's good that we can make that happen. And then there are others like you said, that really want to hone in on an area of specialty and get better at that particular thing.

+ +

CHAD: I think there's a benefit to us even just having words to use to describe the different kinds of projects now because we never had those words to use before. So when now internally people say, "Oh, this is a boost-style project," that means something to people. And I think it helps us talk about the work that we're doing or we might do for customers.

+ +

DIANA: Yeah.

+ +

CHAD: Cool. So what else happened in 2021? [chuckles]

+ +

DIANA: What else happened in 2021? Well, we did a lot of DEI training, and that was great. I learned a lot in that training. I thought actually that I was pretty hip with everything. I thought I've been involved in DEI activities all my life, so I get it, of course. But then, once I took the training, I was like, wait, there's a lot to learn here. I thought I knew a lot. But I'm learning a lot.

+ +

There were several courses and several sessions. And with each session, I came away learning a lot more than I thought I would and having a greater appreciation. I think one of the greatest appreciations I learned last year was an appreciation for words, how important it is to think about what you're saying. A lot of times, we just talk, and it's important to really think through what one says. I took that to heart from the training that we got.

+ +

CHAD: And I think people might hear that and say, "Oh, you're talking about being politically correct," and perhaps maybe having a negative reaction to that. But I think one way to think about it is it's not just being politically correct for the sake of being politically correct. But words can have an impact on people, or the way that you talk about something can have an impact on people, either by making them feel bad or excluding them.

+ +

When you have a group of people working on something, people come at work with so many different backgrounds and experiences, and perspectives. And so, having an inclusive environment where everyone can contribute fully is super important to not only being fulfilled in our work but ultimately creating great products too.

+ +

DIANA: Yeah, absolutely. And that diversity is something that will make us have better products. But it also makes us; I think in many ways, better people by understanding where others are coming from, what they might have experienced in the past, and knowing that what is available to one person may not be available to others.

+ +

So it's not just political correctness but also a better understanding of humans and what we go through and that it's not necessarily equal for everyone. And it's not necessarily fair for folks. And that's sometimes easy to forget. And I think that training that we went through really reminded me. And it gave me an appreciation for the privileges that I do have and just a greater awareness that I'm so grateful for.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So we've had a DEI Council at thoughtbot for a couple of years now. And I think that we created it because of the studio model. We were very distributed as a company. And so we wanted a group of people that could come together, work on things, but also collectively, educate themselves and take action items and everything, and then take them back to their physical studios.

+ +

And I think that now with the reorganization, with the progress we've made, it's not that the Council doesn't work. But it's in a different spot in terms of what we're hoping to achieve as a company and the way that it's working.

+ +

So we actually have right before the end of the year, we opened a DEI program manager position, which is a full-time position at thoughtbot for someone to not do all of the work that the council is going to do but a centralized thing to make the distributed nature of the...to sort of empower the council, and free up time.

+ +

We're all on client work a significant portion of our time. And so striking the balance between having DEI ingrained in the company, having everyone have enough time to work on what needs to be worked on, and to have it all be managed, we looked at that whole picture and said, we think that the Council could be even more effective if we have someone on board who can work with them full time basically.

+ +

And people might be saying DEI Council full time? It's not just the council. So it's diversity, equity, and inclusion. So it really permeates everything about our culture, and how the company works, and how it functions. And there's a lot there.

+ +

So that person is going to be part of the operations team, which is my team. And they'll be ingrained, you know, part of everything that we do to make thoughtbot operate but through the lens of is this equitable? Are we inclusive of the people that we have on our team in Africa and South America, as well as the United States now?

+ +

That's a huge thing for us, making sure that we're setting things up in a way that works for everyone at the company. And we're more internationally diverse than we've ever been before. And so that has been something that takes up a lot of our time. And we want to make sure we do a great job with it. So that's one of the things that this new person is going to do.

+ +

DIANA: Yeah, and one of the things I'm really excited about for this person is putting some metrics together for us. It's been hard for us to quantify our progress in DEI. And I know that this individual will be doing that, which is to me exciting because we're going to be able to see how are we really progressing with these initiatives? I think that's going to be great.

+ +

And also, being able to partner with other organizations just outside of thoughtbot is going to be interesting as well because our DEI Council does it, but none of us have a lot of time to actually do too much of it. Everybody's got like you said, client work and other things they have to work on. So that's another thing I'm really excited about this individual taking on is that outside partnership perspective.

+ +

CHAD: I feel like we have a lot of positions open right now.

+ +

DIANA: [laughs] We sure do.

+ +

CHAD: Not only in the operations or the non-designers and developers. We've got a lot of design and development roles open as well.

+ +

DIANA: Yep. Plug for the thoughtbot.com/jobs page. [laughter]

+ +

CHAD: Yeah. Well, one of the things that I'm really excited about going into 2022 we've had the Apprenticeship Program for 11 years now. We say on the website we've done over 50 apprentices. I think it's more like over 75. I just stopped doing the count a while ago.

+ +

But we haven't been able to do it consistently previously because when we were distributed among the different studios, and everything was based on who you worked with in person, we needed to make sure, you know, not every studio was even large enough to have enough mentors to be able to have apprentices. But we also needed good projects for mentorship and having apprentices on them.

+ +

And we also needed to make sure, like, oh, if we take on an apprentice in Austin, we need to make sure that the Austin studio needs another Rails developer. And so it was pretty limiting. But even though it was limiting, we did lots of apprentices. And it's been super successful. So many leaders at the company started as apprentices.

+ +

DIANA: Christina comes to mind. She's like a development director now.

+ +

CHAD: Yeah, exactly. A lot of the development directors at thoughtbot started as apprentices over the years. So I'm super excited because this is another thing that no longer being in-person studios unlocks for us is to say basically thoughtbot as long as we're hiring across all of thoughtbot, we will always have the need for designers and developers.

+ +

And so we can make the Apprenticeship Program more of a rotational program. No matter where you live now, you can join. We can do remote apprenticeship like all of our positions. And you can rotate among the thoughtbot teams with a great mentor from each team and then be promoted as a designer or a developer onto one of those teams that has a position for a Rails developer or a designer.

+ +

And that is going to enable us to have consistent apprenticeship positions across the company open all the time with a consistent application process with timelines laid out for when deadlines are going to be for applications and when we're accepting people, and when people start. And I'm really excited about that.

+ +

I think it's going to be not only great for apprentices, which is actually one of the primary reasons why we do it but also great for thoughtbot to get this consistency to what has been a really valuable hiring channel for us in the past.

+ +

DIANA: Absolutely. I think that's one of the things I'm most excited about, to be honest with you, is that Apprenticeship Program because of everything that you mentioned. And it's not like we just need to limit it to one person. It could be a group of people going through the program together, which gives them a sense of camaraderie as well and a second incoming class. We have an incoming class. [laughs]

+ +

CHAD: Right, right. My only regret is that even just in this first batch, we can see...or I've just had the potential of the Apprentice Program for us reinforced. In this batch, we have almost 1,000 applications across the two Launchpads with the design and development positions. It's incredible. [laughs]

+ +

DIANA: That's so amazing.

+ +

CHAD: Even though we're having more apprentice positions than we've had in many years going for 2022, it's still not enough. There are so many people that could be great fits for thoughtbot that we might not be able to have enough bandwidth to take on. So I'm looking ahead to the next thing as like, how can we grow enough to have even more apprentices?

+ +

DIANA: Well, let's get Rocket Fuel to help with that.

+ +

[laughter]

+ +

CHAD: Yeah. I've often said that hiring great team members really isn't our problem. Our problem is consistently having more than enough work to be fulfilled, to be picky and choosy, while also having enough work for our team very reliably, weathering those ups and downs. And when we turn off hiring, it hurts our ability to hire overall because it takes longer to ramp it back up and that kind of thing. And I think you saw that throughout the course of 2021.

+ +

We had to turn off hiring for a while in 2020. And when we resumed it, it took quite a while for those wheels to spin back up and for enough people to get through the pipeline. Because even though we get a significant number of people applying, we really only hire less than 1% of the people who come across because our standards of what we want when we add people to the team are high.

+ +

DIANA: Yeah, it's true. It's challenging. We really did feel that impact pretty hard for a while there; the repercussions of not having the hiring open in 2020 were felt for sure.

+ +

CHAD: We also made the decision that we were going to focus on making sure that when we started hiring back up, we didn't just necessarily go right back to the way that we were doing things before in terms of all of our process.

+ +

So we used to have a lot of automation in place because of the number of applications. And we didn't immediately put all that in place because sometimes that automation got away from us. We care a lot about the hiring process. And we wanted to make sure that we just didn't blindly turn it back on because we had a sense that it wasn't 100% working for us.

+ +

And the other was that we made the decision from a DEI perspective to make sure that we didn't move forward on starting interviewing for a position without having the candidate pool we were choosing from reflect a representative sample of the United States.

+ +

And that's in the tech industry; if you put a role online and just let people come into it organically from a normal job pool, the tech industry isn't representative of the United States demographics. And so, if you just let that status quo come in, you're going to see what's reflected in the tech industry. So that was another important but real limitation that we put on ourselves when we started hiring again.

+ +

DIANA: Yeah, it was painful, [laughs] but it was necessary.

+ +

CHAD: And I think we've seen as people move through the pipeline and as our hiring goes up that it was worth it, even if it wasn't easy and was difficult.

+ +

DIANA: That's how things usually are, right?

+ +

CHAD: Right. [laughs]

+ +

DIANA: Things are usually not easy. And usually, things that are worth it, there's work involved.

+ +

CHAD: And we're not done with DEI work and trying to build the kind of organization we want to have. You're never really done. So there's always something that we can do better. We still need to really speed up our hiring process, which has been pretty much stuck at a certain timeline for a long time. And figuring out a way to speed that up while still staying true to the kind of process and the qualifications that we want to put on the process continues to be a challenge for us.

+ +

DIANA: I think that's industry-wide, though. I don't think that's unique to us. There are a lot of companies challenged with hiring at the moment. There are a lot of reasons for that. But we definitely have to keep on top of it and try to figure out ways to make ourselves better.

+ +

CHAD: Yeah. I think the biggest problem is to the extent that if you lose people along the way that you would totally otherwise hire because they go to other companies first just because you didn't finish the process fast enough. That's the fundamental thing that we want to avoid.

+ +

DIANA: That's the real risk that we...I think we actually lost some people for that.

+ +

CHAD: Yeah, definitely. And over the years, despite trying, we haven't been able to significantly speed up our hiring process. For folks who aren't familiar, a big part of our process is having a few different stages. And the final stage being pairing, working with actual members of the team for the day. We pay for that day. And meeting the rest of the team and having a process which involves the rest of the team it's not just a siloed hiring team that's making all the hiring decisions.

+ +

But doing a full day visit as the last stage means effectively that we can never have two people interviewing for the same position. And then everyone being on client work and only really being able to do those visits on Fridays means that the fastest, unless we're willing to make a change to that, the fastest we can go to hire into any one position is one final stage interview a week. That's a bottleneck.

+ +

DIANA: That's a bottleneck for sure unless we have dedicated people doing the recruiting. Then that would be a challenge as well because that's all these folks would do.

+ +

CHAD: Right. And then the team would feel, you know, we gain a lot from everyone being part of the team. So that when people show up on day one, we can say, "Hey, everyone that you worked with, everyone that you met was a unanimous yes to you being here."

+ +

It builds a tremendous amount of trust and confidence on both sides, I think. And to not have that, I think we would need to then do a lot more work in building up that confidence of those new team members and of the team in that process and on day one when they show up. So it's an area of future work for us, definitely. I don't know what the solution will be eventually. But I do know that it's an area that we have to improve on.

+ +

DIANA: Yeah, agreed.

+ +

CHAD: Cool. Well, anything else on your mind before we wrap up?

+ +

DIANA: No. I'm looking forward to 2022. There's a lot that we want to do. And it's going to be an exciting year. It's already starting off exciting. [laughter] Though, I do want to talk a little bit about community now or?

+ +

CHAD: How about we give a little sneak peek in terms of what we're thinking for 2022? And then, in a little while, we'll have you back on to talk more about it. How's that sound?

+ +

DIANA: Yeah, it sounds great.

+ +

CHAD: Okay, community has always been a big part of thoughtbot. It's what has driven a lot of the open-source that we've done, our blogging. But what do you mean by community in 2022?

+ +

DIANA: Well, we started off this conversation by talking about remote and some of the pros and cons associated with it. And I think that one of the things that remote does there’s a lot of benefits to it. But I think that we need to help overcome the challenges, and I want us to do more of that in 2022.

+ +

So, for example, creating a culture where people feel the recognition that you might be able to do more in person than you do remotely or lessen feelings of isolation that some folks feel, bringing out the quiet voices among us, giving them space to talk and give their voice. How can we make that happen?

+ +

Finding ways for people to build relationships with each other and maybe people that have never met, that are on different teams. How do we make that happen? Just overall experiencing a positive, respectful and inclusive work environment. That at a remote level is something that I think we need to dive in deeper this year. And like you said, we can dive into that more at another time.

+ +

CHAD: Yeah, I'm excited. I feel it too. And it comes from I think maybe it was Stephanie or Louis that was talking about it, both members of our team who were generally like, when you were in person, there was an ease to either talking to someone off-hand or even just when you have a daily sync every day in person, it's easy to recognize a success and to have everyone applaud.

+ +

And when you aren't in person with each other, you need to work at it more to really foster that sense of team and community. And that's clearly part of what getting through 2021 and settling in and getting to the next level is about for us.

+ +

DIANA: Yeah, absolutely.

+ +

CHAD: Cool. Well, if folks want to get in touch with you or follow along with you, where are the best places for them to do that, Diana?

+ +

DIANA: I started off last year actually doing some tweets, and I'm not very good at it. I totally stopped doing it. But I'm going to try to do more of it. I can be found on Twitter @dianabald, first name, last name. I'm on LinkedIn, first name, last name. The good news about my name is that there’s not a lot of me out there, [laughter] people with my last name. So I'm easy to find. And by email, it's dianabald@thoughtbot.com.

+ +

CHAD: Great. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. I'd love to get some comments and questions in 2022 and bring them to the episode. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Diana, thanks again for joining me.

+ +

DIANA: Thank you, Chad. Thank you, everybody.

+ +

CHAD: And thank you for listening. See you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Diana Bald.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to the CEO of thoughtbot, Diana Bald, about 2021 in retrospect. thoughtbot, as a company, has settled into a new structure that contains different teams and committed to becoming a fully remote organization.

+ +

Last year, Diana successfully transitioned into taking over the company's CEO role. She and Chad talk about the improvements the company made in 2021, including DEI (diversity, equity, inclusion) efforts and training sessions, and look ahead to some improvements coming in 2022, such as an expansion of the apprenticeship program.

+ +

P.S.: thoughtbot is hiring! To see open roles, visit thoughtbot.com/jobs.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today back again is Diana Bald, the CEO of thoughtbot. Diana, welcome back to the show.

+ +

DIANA: Thanks for having me back, Chad. Hello everybody out there.

+ +

CHAD: You joined us in the spring; I guess is the best way to put it where we talked about the transition from me to you of CEO. And it feels like it was actually simultaneously both just yesterday that we did that recording and a long, long time ago. How has this year been for you?

+ +

DIANA: Yeah, I completely agree. It feels the same way for me. [chuckles] This year has been interesting and eventful. Well, 2021 has been.

+ +

CHAD: So we're recording this just in the dawn of 2022. Looking ahead, we're bright-eyed and ready to go to the New Year, right?

+ +

DIANA: That's right.

+ +

CHAD: So I thought that it'd be good to do a little bit of a retrospective or a review of 2021. A lot changed for thoughtbot. And the last time we talked about it was way back at the beginning of all those changes.

+ +

And I've had all the managing directors of the different teams on now to talk about the different teams, and what they're focused on, and how they're working, and what their goals are. And I thought it'd be fun to do that for thoughtbot overall with you.

+ +

DIANA: Yeah, I think it's a great idea.

+ +

CHAD: Cool. So since we last talked, we really settled into the different teams and the new structure. And even little things like we've sublet most of our office spaces and those kinds of things. I'm really reaffirming how things have gone. But I'm curious, just at a high level, what's been the most surprising thing for you about 2021?

+ +

DIANA: [chuckles] That was not a question I was expecting.

+ +

CHAD: [laughs]

+ +

DIANA: The most surprising thing for me was (There were a lot.) I think how quickly we put everything together actually. That was probably the most surprising thing. I think that we were able to reorganize and pretty much just get to work in the new team structure right away.

+ +

There wasn't a lot of reinventing. We reinvented when we redefined. But as we started doing the work, it was very logical, like, oh, this makes a lot of sense. These teams break out very nicely. So that speed in which that happened, I think, was the biggest surprise to me.

+ +

CHAD: I know that some people said we moved maybe too quickly on some of those changes. How do you respond to those people?

+ +

DIANA: [laughs] It's different personalities. Well, can I take a philosophical perspective?

+ +

CHAD: Yeah, totally.

+ +

DIANA: Okay. So I have a frame of mind as life doesn't happen to us. It happens for us in the sense that there is never a perfect time to do anything. One can be preparing, preparing, preparing, and it's good. Preparation is great. Analysis is great. All that stuff is good. But there's never going to be perfect anything. In fact, it's better to get started to get the feedback because the feedback is real.

+ +

And it's kind of like the way that we actually work, in fact. You respond, and you iterate based on what the circumstances are telling you. And I think that's the difference in point of view. So, for me, I thought the pace was nice. But I could see why other people might have thought we moved too quickly.

+ +

CHAD: So I forgot to mention the episode number if folks want to go back and listen to more of the details. It was Episode 392 where we talked, and then Episode 393 at giantrobots.fm/393 is where we talked about the details of the different teams and going fully remote, so if folks want to go back and listen to that. And then obviously, I've been talking to the different managing directors recently.

+ +

So now that we're almost a full...actually, I think we're a full year from when we actually made the changes.

+ +

DIANA: January eighth was the day.

+ +

CHAD: So we're a few days shy of a full year. I think there are really two aspects of this whole thing. There was the concept of going remote and committing to being fully remote. And there's the concept of then reorganizing the company in a way that was supportive of that.

+ +

And a lot of that was driven by the fact that we were really organized previously around the geographic studios and how we didn't feel like continuing that way was going to be something that would be sustainable for us over the long-term, both from a sales and business perspective but from a people perspective too.

+ +

And so we talked about the teams and how quick and how I think overall well that has gone. How about the fully remote aspect? How has it been for you personally? That's one way to put it.

+ +

DIANA: Well, I think that remote should be taken into context. We went remote in a time when the entire world was going remote. And I think that if we had gone remote at a different time, our experiences would be a little different because, with the start of the pandemic, we had a lot of limitations to our freedom because we were on lockdown.

+ +

And so when you go remote in a time of lockdown, and a time of limitations to freedom, it's very different than being remote at a time when you have the flexibility to go work out during the middle of the day, go pick up kids from school or whatever one does when you have flexibility. [chuckles]

+ +

So I think that the time that we started remote helped us clarify that yes, this is something we want to do. But I think our experience was tainted because we were in lockdown at the time, and our freedoms were very limited.

+ +

If our freedoms weren't so limited, we had planned, as you know, because we talked about it, having pop-up offices or having the ability to bring people together, and we weren't able to do any of those ideas. The pandemic took much longer than we thought it would for us to get to that. And right now, we're back in that place where Omicron is going on. And we're still kind of semi...not really locked down, but a lot of us are being extra cautious.

+ +

And then, for me personally, I'm enjoying the freedom. I like the freedom. But I'm also very cautious because I have to protect my family. And I just need to be very careful when I meet with people and things like that.

+ +

CHAD: Well, I agree that the social-emotional impact of how things have been for the last two years basically has made this transition difficult for a lot of people, myself included. And we've needed to be mindful of that, I think, as we try to move forward as aggressively as possible towards the way things we want to be.

+ +

I think it's been challenging for myself, for team members to realize that the way things are now isn't necessarily the way things are always going to be. We will be able to be in person. We will be able to visit each other. We'll be able to have those pop-up offices and that kind of thing that we've been limited to do. I'm really looking forward to that sometime in the future.

+ +

DIANA: Yeah, for sure I am as well.

+ +

CHAD: The other side from the business has been we're not getting pressure from clients. I feel like I'm revisiting this topic. [chuckles] I know last time we talked, it was like, I wonder what it's going to be like when we start getting clients back in person. And is there going to be pressure to be with them? And that kind of thing.

+ +

And unfortunately, because of the pandemic going on, we haven't been getting that pressure. Now, that works for our business because it just relieves the pressure or the need to travel or schedule things and that kind of thing.

+ +

But that being said, I'm more optimistic than I was before even though we haven't truly lived it that not only will clients...and that we have a really good way of doing things like design sprints and everything remotely but that there will be a benefit to getting together at the start of projects once we can safely do that and everything.

+ +

And I think people will better understand the concept of we're getting together to kick off the project or to do the design sprint. We could do it remotely, but we're choosing to do it in person with the understanding that it's totally fine to go back remote after we've had that in-person kickoff.

+ +

DIANA: Yeah, and I think that there's going to be some situations where it will be better to be remote to have the sprint and other situations where let's say you want to test something with a live audience or you want to get feedback from live people interacting with a physical object or something like that where it would make sense to have the physical in-person component. And other things are better with a brainstorm to have it be digital.

+ +

I think it just depends on the circumstances and the client and what they're looking to achieve. And having that flexibility that we don't currently have right now because of the variant is something I'm looking forward to.

+ +

CHAD: So when we talk about the transition and you taking over the CEO role, I said that one of the reasons why I thought that was the right thing to do and was excited to do that was because I thought that you were going to be better for what the company, and particularly the managing directors and the other leaders at the company, needed to get to the next stage.

+ +

And I forget exactly how much...a lot of that is baked into getting to the next stage of thoughtbot. One is resiliency of team and leadership and not having it be based solely around me. That's certainly one aspect of it. The other is your deep experience with sales and marketing; business development better match what we need to do going forward in terms of building, getting to the next levels of revenue, and sustainability.

+ +

And at the time, you were still learning, or maybe learning is the wrong word. How would you describe it? Basically, like getting a handle on things before making decisions or changes to move forward with certain aspects of how we do business development and that kind of thing.

+ +

DIANA: Yeah, I think I understand what you're saying.

+ +

CHAD: And so now that we're significantly past that point, what are some of the things that you've done or focused on with thoughtbot business development with thoughtbot overall that you would consider positive changes?

+ +

DIANA: I think the introduction of Rocket Fuel is one that I would consider a positive change in that direction. We had...I don't know if we want to re-familiarize the audience with the theme of rocket.

+ +

CHAD: Yeah, I totally think you should because I think it might come out of nowhere for people.

+ +

DIANA: [laughs] So we organized around a theme to make it easier for us to convey what we're doing. And you could think of the stages of a rocket from ignition to blast off in orbit. And basically, it's a fun way of saying that we have an end-to-end product development process.

+ +

And so everything from ideation and validation that's our Ignite team, to building and going to market is our Lift Off team. Scaling and transforming is our Boost team. And supporting and maintaining is our Mission Control team.

+ +

So when you have a rocket, you need fuel. [chuckles] And so that's where we introduce Rocket Fuel, which is basically business development and marketing. And what we did is we changed it from being two different ways of approaching, driving the business into business development being the driver and marketing being the support.

+ +

And what I mean by that is it's more strategic, in line with the different stages of where we are. So for the Ignite team, their needs are very different than for the Boost team. So when we're in the ideation validation stage with a client, it's very, very different than a client who's in the transformation or in the scaling stage of their product.

+ +

So having that mindset of driving that phase of product development has been very helpful to us because then we can apply the marketing tactics, strategies, plans around the stage of that product lifecycle. So that's been something that I think has worked really well this past year.

+ +

CHAD: So what does the Rocket Fuel team look like? What are the different roles on it?

+ +

DIANA: Well, it's small right now, but we're growing it. We have Kelly, who is our Associate Director of Business Development, and she's focused on supporting more of the implementation of some of the ideas that are coming out of each of the marketing tactics that I mentioned earlier. So whether it's partnerships with different organizations or whether it is campaigns that we're running so overseeing those, and she's also stepping in when the managing director has to step away for a few months, maybe somebody is taking paternity leave or something like that. Kelly stepped in there.

+ +

And then we have in sales enablement Liz who's serving as a Sales Enablement and Business Development Manager. And she's really helping us get exactly what her title says, enable the sales process. So she's putting together the marketing collateral. She's got our CRM system, getting that organized and up to date with information. And she's starting to work on updating our handbook with business development information and marketing information that's changed since we were in our old structure. So she's getting that in line.

+ +

So she's more behind the scenes and more enabling us to move quickly. And Kelly is more on the strategic end of it, helping us build out the plans that'll drive the growth of each of our teams.

+ +

CHAD: And Liz is also helping respond to RFPs and making sure things move forward or are pulled together for making proposals and contracts with clients, right?

+ +

DIANA: Yeah, she's doing a great job on that.

+ +

CHAD: I think all of those things are something that we had talked about doing for a while, having someone be able to help with those kinds of things, especially when we have a world where managing directors at thoughtbot are responsible not just for sales but for the whole business that they run.

+ +

And so they have a lot on a day-to-day or a weekly basis of what they need to spend time on. So having someone who can help them have time to spend on things that are not sales and to make sure that sales move along quickly, I think, has worked really well. And it was something we had talked about for a while, and I'm really happy to see it come to fruition.

+ +

DIANA: Yeah, I am too. I agree; it is helping the managing directors take a breath. They need sustainable lives as well. And it's good that we're able to help them in this regard. I think we can help them even more. Liz has only been with us for a few months. And as she gets more and more comfortable, she gets more and more ideas and starts to run a little faster, which is great to see her do that.

+ +

And the same with Kelly, as she's wrapping her arms around her new role, she is also coming up with a lot of ideas. And it's exciting to see them work because they energize each other. [laughs] It's really cool.

+ +

And we're also recruiting for an Associate Director of Business Development for Mission Control to help us grow that team. If anybody out there is listening, and you know of anyone, [laughs] encourage them to apply.

+ +

CHAD: Yeah, that's a really good point. So that Mission Control does DevOps, maintenance, SRE work, so we're really looking for someone who has experience growing and building that kind of business. And it's quite honestly a big growth opportunity because there's a real opportunity to start as the Associate Director of Business Development in that business and grow into more of a Managing Director role, right?

+ +

DIANA: Absolutely. We see it as an opportunity to come in on the ground floor; essentially as the very fast-moving, high potential team gets going. So it's a super exciting opportunity for people that are interested in DevOps or Site Reliability Engineering or anything else that we're doing in that space of support and developing.

+ +

CHAD: Great. Well, hopefully, someone hears this and says, "That's for me. I want to apply." If that's you, you can go to thoughtbot.com/jobs and check it out there. I'm making my hard pitch here. We also have some outside consultants helping with running different campaigns and digital marketing activities, right?

+ +

DIANA: That's right. We are working with outside consultants to help us run some targeted campaigns based on some of the strategies that Liz and Kelly are developing. And they're doing the actual implementation of the marketing. So they'll buy the ads; they'll run them. And we also have somebody helping us with social media. Mandy is doing that. She's doing a great job of that.

+ +

And we have Tori, who's still helping us out with some of the digital marketing campaign, conceptualizing them, and transitioning some of that work that she was doing on the CRM, transitioning some of that over to Liz to take over our sales enablement. So a lot of activity happening over here at Rocket Fuel.

+ +

CHAD: So to put it as plainly as I can, thoughtbot has been successful. We've been particularly successful from a culture and team, and thought leadership standpoint. But we haven't been incredibly successful in making a company that operates at the level that we do and generates enough profit to be really comfortable that when a pandemic hits...that's an extreme circumstance, but there are ups and downs in every business.

+ +

And our margins haven't been historically as large as other consulting companies and that kind of thing because of the kinds of team we have and the way that we run the business. And so a big goal of when we talk about taking thoughtbot to the next level has been sustainability and making sure that we operate with enough cushion that we can more than weather downturns or ups and downs in the business without having to let people go or make significant changes.

+ +

And if people listened to the prior episode, they know that we had actually made significant progress towards that goal in 2019. And we were feeling really great going into 2020 about what we were going to accomplish. And then, in April of 2020, we had a significant decrease in revenue all at once, which really threw the business into turmoil because we hadn't been operating with that significant margin, a sustainable margin.

+ +

So we spent 2020 recovering from that, making sure that we had corrected some of those fatal flaws. And we saw, I think, a lot of that come to fruition in 2021 and had a really sustainable year where we met and exceeded our goals. I'm really happy about that. I assume you're happy to. [laughs]

+ +

DIANA: Yes, I'm really happy about that too. [laughs] I think that it's something that we haven't celebrated, and we need to celebrate it. It was actually a really great year for us financially. And I talked about speed earlier. And I said I was pleasantly surprised with the speed.

+ +

And one of the factors is that in the first quarter of last year, things started to come together for us in that vein of financial sustainability. And we were able to maintain it every quarter of the full year. That's pretty great. And we should pat ourselves on the back for that. Congratulations, Chad. [chuckles]

+ +

CHAD: Congratulations, Diana. You and I have talked about this before. So overall, the market recovered in a really good way for services, businesses, for software development. So that boosted our ability to really go above and beyond. But even putting that aside, it took a lot of work. It wasn't easy. And it was through the fundamental changes we had made that we were able to take advantage of that good market, I think.

+ +

DIANA: Yeah, I agree. And the intentionality of what we were doing, I think the reorganization helped us see clearly the benefits of each team. Obviously, today, I have a much clearer insight into each team's strengths and each team's capabilities than I did a year ago when we last talked.

+ +

I think we are still trying to get our...is it going to work? What is it going to look like? And now it's like, oh, this is so obvious. This makes a lot of sense. The teams are working on very different aspects of the product development lifecycle. And I think that intentionality also helped us with our goals.

+ +

CHAD: And I think that one of the goals of doing that too was to free people up to better understand and focus on the kind of work that they wanted to do rather than trying to do everything everywhere. And for the individual person at thoughtbot, never knowing what your next client project was going to look like because it could have been any of our types of clients that we have.

+ +

And I think overall, what I've heard from the team is that it has been a good opportunity to reduce those surprises, get better at the kind of thing that you're working on now, even if ultimately that means okay, you've done your stint in Lift Off and now you want to move over to Boost, or you've been in Boost, and now you want to give Lift Off a try. At least you can do that with intentionality as opposed to never being quite sure what your next project is going to look like.

+ +

DIANA: Yeah, exactly. There are some people that like that variety of moving back and forth, and that's good that we can make that happen. And then there are others like you said, that really want to hone in on an area of specialty and get better at that particular thing.

+ +

CHAD: I think there's a benefit to us even just having words to use to describe the different kinds of projects now because we never had those words to use before. So when now internally people say, "Oh, this is a boost-style project," that means something to people. And I think it helps us talk about the work that we're doing or we might do for customers.

+ +

DIANA: Yeah.

+ +

CHAD: Cool. So what else happened in 2021? [chuckles]

+ +

DIANA: What else happened in 2021? Well, we did a lot of DEI training, and that was great. I learned a lot in that training. I thought actually that I was pretty hip with everything. I thought I've been involved in DEI activities all my life, so I get it, of course. But then, once I took the training, I was like, wait, there's a lot to learn here. I thought I knew a lot. But I'm learning a lot.

+ +

There were several courses and several sessions. And with each session, I came away learning a lot more than I thought I would and having a greater appreciation. I think one of the greatest appreciations I learned last year was an appreciation for words, how important it is to think about what you're saying. A lot of times, we just talk, and it's important to really think through what one says. I took that to heart from the training that we got.

+ +

CHAD: And I think people might hear that and say, "Oh, you're talking about being politically correct," and perhaps maybe having a negative reaction to that. But I think one way to think about it is it's not just being politically correct for the sake of being politically correct. But words can have an impact on people, or the way that you talk about something can have an impact on people, either by making them feel bad or excluding them.

+ +

When you have a group of people working on something, people come at work with so many different backgrounds and experiences, and perspectives. And so, having an inclusive environment where everyone can contribute fully is super important to not only being fulfilled in our work but ultimately creating great products too.

+ +

DIANA: Yeah, absolutely. And that diversity is something that will make us have better products. But it also makes us; I think in many ways, better people by understanding where others are coming from, what they might have experienced in the past, and knowing that what is available to one person may not be available to others.

+ +

So it's not just political correctness but also a better understanding of humans and what we go through and that it's not necessarily equal for everyone. And it's not necessarily fair for folks. And that's sometimes easy to forget. And I think that training that we went through really reminded me. And it gave me an appreciation for the privileges that I do have and just a greater awareness that I'm so grateful for.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So we've had a DEI Council at thoughtbot for a couple of years now. And I think that we created it because of the studio model. We were very distributed as a company. And so we wanted a group of people that could come together, work on things, but also collectively, educate themselves and take action items and everything, and then take them back to their physical studios.

+ +

And I think that now with the reorganization, with the progress we've made, it's not that the Council doesn't work. But it's in a different spot in terms of what we're hoping to achieve as a company and the way that it's working.

+ +

So we actually have right before the end of the year, we opened a DEI program manager position, which is a full-time position at thoughtbot for someone to not do all of the work that the council is going to do but a centralized thing to make the distributed nature of the...to sort of empower the council, and free up time.

+ +

We're all on client work a significant portion of our time. And so striking the balance between having DEI ingrained in the company, having everyone have enough time to work on what needs to be worked on, and to have it all be managed, we looked at that whole picture and said, we think that the Council could be even more effective if we have someone on board who can work with them full time basically.

+ +

And people might be saying DEI Council full time? It's not just the council. So it's diversity, equity, and inclusion. So it really permeates everything about our culture, and how the company works, and how it functions. And there's a lot there.

+ +

So that person is going to be part of the operations team, which is my team. And they'll be ingrained, you know, part of everything that we do to make thoughtbot operate but through the lens of is this equitable? Are we inclusive of the people that we have on our team in Africa and South America, as well as the United States now?

+ +

That's a huge thing for us, making sure that we're setting things up in a way that works for everyone at the company. And we're more internationally diverse than we've ever been before. And so that has been something that takes up a lot of our time. And we want to make sure we do a great job with it. So that's one of the things that this new person is going to do.

+ +

DIANA: Yeah, and one of the things I'm really excited about for this person is putting some metrics together for us. It's been hard for us to quantify our progress in DEI. And I know that this individual will be doing that, which is to me exciting because we're going to be able to see how are we really progressing with these initiatives? I think that's going to be great.

+ +

And also, being able to partner with other organizations just outside of thoughtbot is going to be interesting as well because our DEI Council does it, but none of us have a lot of time to actually do too much of it. Everybody's got like you said, client work and other things they have to work on. So that's another thing I'm really excited about this individual taking on is that outside partnership perspective.

+ +

CHAD: I feel like we have a lot of positions open right now.

+ +

DIANA: [laughs] We sure do.

+ +

CHAD: Not only in the operations or the non-designers and developers. We've got a lot of design and development roles open as well.

+ +

DIANA: Yep. Plug for the thoughtbot.com/jobs page. [laughter]

+ +

CHAD: Yeah. Well, one of the things that I'm really excited about going into 2022 we've had the Apprenticeship Program for 11 years now. We say on the website we've done over 50 apprentices. I think it's more like over 75. I just stopped doing the count a while ago.

+ +

But we haven't been able to do it consistently previously because when we were distributed among the different studios, and everything was based on who you worked with in person, we needed to make sure, you know, not every studio was even large enough to have enough mentors to be able to have apprentices. But we also needed good projects for mentorship and having apprentices on them.

+ +

And we also needed to make sure, like, oh, if we take on an apprentice in Austin, we need to make sure that the Austin studio needs another Rails developer. And so it was pretty limiting. But even though it was limiting, we did lots of apprentices. And it's been super successful. So many leaders at the company started as apprentices.

+ +

DIANA: Christina comes to mind. She's like a development director now.

+ +

CHAD: Yeah, exactly. A lot of the development directors at thoughtbot started as apprentices over the years. So I'm super excited because this is another thing that no longer being in-person studios unlocks for us is to say basically thoughtbot as long as we're hiring across all of thoughtbot, we will always have the need for designers and developers.

+ +

And so we can make the Apprenticeship Program more of a rotational program. No matter where you live now, you can join. We can do remote apprenticeship like all of our positions. And you can rotate among the thoughtbot teams with a great mentor from each team and then be promoted as a designer or a developer onto one of those teams that has a position for a Rails developer or a designer.

+ +

And that is going to enable us to have consistent apprenticeship positions across the company open all the time with a consistent application process with timelines laid out for when deadlines are going to be for applications and when we're accepting people, and when people start. And I'm really excited about that.

+ +

I think it's going to be not only great for apprentices, which is actually one of the primary reasons why we do it but also great for thoughtbot to get this consistency to what has been a really valuable hiring channel for us in the past.

+ +

DIANA: Absolutely. I think that's one of the things I'm most excited about, to be honest with you, is that Apprenticeship Program because of everything that you mentioned. And it's not like we just need to limit it to one person. It could be a group of people going through the program together, which gives them a sense of camaraderie as well and a second incoming class. We have an incoming class. [laughs]

+ +

CHAD: Right, right. My only regret is that even just in this first batch, we can see...or I've just had the potential of the Apprentice Program for us reinforced. In this batch, we have almost 1,000 applications across the two Launchpads with the design and development positions. It's incredible. [laughs]

+ +

DIANA: That's so amazing.

+ +

CHAD: Even though we're having more apprentice positions than we've had in many years going for 2022, it's still not enough. There are so many people that could be great fits for thoughtbot that we might not be able to have enough bandwidth to take on. So I'm looking ahead to the next thing as like, how can we grow enough to have even more apprentices?

+ +

DIANA: Well, let's get Rocket Fuel to help with that.

+ +

[laughter]

+ +

CHAD: Yeah. I've often said that hiring great team members really isn't our problem. Our problem is consistently having more than enough work to be fulfilled, to be picky and choosy, while also having enough work for our team very reliably, weathering those ups and downs. And when we turn off hiring, it hurts our ability to hire overall because it takes longer to ramp it back up and that kind of thing. And I think you saw that throughout the course of 2021.

+ +

We had to turn off hiring for a while in 2020. And when we resumed it, it took quite a while for those wheels to spin back up and for enough people to get through the pipeline. Because even though we get a significant number of people applying, we really only hire less than 1% of the people who come across because our standards of what we want when we add people to the team are high.

+ +

DIANA: Yeah, it's true. It's challenging. We really did feel that impact pretty hard for a while there; the repercussions of not having the hiring open in 2020 were felt for sure.

+ +

CHAD: We also made the decision that we were going to focus on making sure that when we started hiring back up, we didn't just necessarily go right back to the way that we were doing things before in terms of all of our process.

+ +

So we used to have a lot of automation in place because of the number of applications. And we didn't immediately put all that in place because sometimes that automation got away from us. We care a lot about the hiring process. And we wanted to make sure that we just didn't blindly turn it back on because we had a sense that it wasn't 100% working for us.

+ +

And the other was that we made the decision from a DEI perspective to make sure that we didn't move forward on starting interviewing for a position without having the candidate pool we were choosing from reflect a representative sample of the United States.

+ +

And that's in the tech industry; if you put a role online and just let people come into it organically from a normal job pool, the tech industry isn't representative of the United States demographics. And so, if you just let that status quo come in, you're going to see what's reflected in the tech industry. So that was another important but real limitation that we put on ourselves when we started hiring again.

+ +

DIANA: Yeah, it was painful, [laughs] but it was necessary.

+ +

CHAD: And I think we've seen as people move through the pipeline and as our hiring goes up that it was worth it, even if it wasn't easy and was difficult.

+ +

DIANA: That's how things usually are, right?

+ +

CHAD: Right. [laughs]

+ +

DIANA: Things are usually not easy. And usually, things that are worth it, there's work involved.

+ +

CHAD: And we're not done with DEI work and trying to build the kind of organization we want to have. You're never really done. So there's always something that we can do better. We still need to really speed up our hiring process, which has been pretty much stuck at a certain timeline for a long time. And figuring out a way to speed that up while still staying true to the kind of process and the qualifications that we want to put on the process continues to be a challenge for us.

+ +

DIANA: I think that's industry-wide, though. I don't think that's unique to us. There are a lot of companies challenged with hiring at the moment. There are a lot of reasons for that. But we definitely have to keep on top of it and try to figure out ways to make ourselves better.

+ +

CHAD: Yeah. I think the biggest problem is to the extent that if you lose people along the way that you would totally otherwise hire because they go to other companies first just because you didn't finish the process fast enough. That's the fundamental thing that we want to avoid.

+ +

DIANA: That's the real risk that we...I think we actually lost some people for that.

+ +

CHAD: Yeah, definitely. And over the years, despite trying, we haven't been able to significantly speed up our hiring process. For folks who aren't familiar, a big part of our process is having a few different stages. And the final stage being pairing, working with actual members of the team for the day. We pay for that day. And meeting the rest of the team and having a process which involves the rest of the team it's not just a siloed hiring team that's making all the hiring decisions.

+ +

But doing a full day visit as the last stage means effectively that we can never have two people interviewing for the same position. And then everyone being on client work and only really being able to do those visits on Fridays means that the fastest, unless we're willing to make a change to that, the fastest we can go to hire into any one position is one final stage interview a week. That's a bottleneck.

+ +

DIANA: That's a bottleneck for sure unless we have dedicated people doing the recruiting. Then that would be a challenge as well because that's all these folks would do.

+ +

CHAD: Right. And then the team would feel, you know, we gain a lot from everyone being part of the team. So that when people show up on day one, we can say, "Hey, everyone that you worked with, everyone that you met was a unanimous yes to you being here."

+ +

It builds a tremendous amount of trust and confidence on both sides, I think. And to not have that, I think we would need to then do a lot more work in building up that confidence of those new team members and of the team in that process and on day one when they show up. So it's an area of future work for us, definitely. I don't know what the solution will be eventually. But I do know that it's an area that we have to improve on.

+ +

DIANA: Yeah, agreed.

+ +

CHAD: Cool. Well, anything else on your mind before we wrap up?

+ +

DIANA: No. I'm looking forward to 2022. There's a lot that we want to do. And it's going to be an exciting year. It's already starting off exciting. [laughter] Though, I do want to talk a little bit about community now or?

+ +

CHAD: How about we give a little sneak peek in terms of what we're thinking for 2022? And then, in a little while, we'll have you back on to talk more about it. How's that sound?

+ +

DIANA: Yeah, it sounds great.

+ +

CHAD: Okay, community has always been a big part of thoughtbot. It's what has driven a lot of the open-source that we've done, our blogging. But what do you mean by community in 2022?

+ +

DIANA: Well, we started off this conversation by talking about remote and some of the pros and cons associated with it. And I think that one of the things that remote does there’s a lot of benefits to it. But I think that we need to help overcome the challenges, and I want us to do more of that in 2022.

+ +

So, for example, creating a culture where people feel the recognition that you might be able to do more in person than you do remotely or lessen feelings of isolation that some folks feel, bringing out the quiet voices among us, giving them space to talk and give their voice. How can we make that happen?

+ +

Finding ways for people to build relationships with each other and maybe people that have never met, that are on different teams. How do we make that happen? Just overall experiencing a positive, respectful and inclusive work environment. That at a remote level is something that I think we need to dive in deeper this year. And like you said, we can dive into that more at another time.

+ +

CHAD: Yeah, I'm excited. I feel it too. And it comes from I think maybe it was Stephanie or Louis that was talking about it, both members of our team who were generally like, when you were in person, there was an ease to either talking to someone off-hand or even just when you have a daily sync every day in person, it's easy to recognize a success and to have everyone applaud.

+ +

And when you aren't in person with each other, you need to work at it more to really foster that sense of team and community. And that's clearly part of what getting through 2021 and settling in and getting to the next level is about for us.

+ +

DIANA: Yeah, absolutely.

+ +

CHAD: Cool. Well, if folks want to get in touch with you or follow along with you, where are the best places for them to do that, Diana?

+ +

DIANA: I started off last year actually doing some tweets, and I'm not very good at it. I totally stopped doing it. But I'm going to try to do more of it. I can be found on Twitter @dianabald, first name, last name. I'm on LinkedIn, first name, last name. The good news about my name is that there’s not a lot of me out there, [laughter] people with my last name. So I'm easy to find. And by email, it's dianabald@thoughtbot.com.

+ +

CHAD: Great. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. I'd love to get some comments and questions in 2022 and bring them to the episode. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

+ +

Diana, thanks again for joining me.

+ +

DIANA: Thank you, Chad. Thank you, everybody.

+ +

CHAD: And thank you for listening. See you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Diana Bald.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+k5F4hWNe + + ]]> + + Chad Pytel + Diana Bald + + + 405: RackN Digital Rebar with Rob Hirschfeld + https://podcast.thoughtbot.com/405 + 810d7cf3-75cc-455c-b3df-00624d9690c6 + Thu, 23 Dec 2021 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Chad talks to Rob Hirschfeld, the Founder and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. RackN is focused on helping customers automate infrastructure. They focus on customer autonomy and self-management, and that's why they're a software company, not a services or as-a-service platform company. + +Digital Rebar is a platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. + 47:24 + no + + + Chad talks to Rob Hirschfeld, the Founder and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. RackN is focused on helping customers automate infrastructure. They focus on customer autonomy and self-management, and that's why they're a software company, not a services or as-a-service platform company. +Digital Rebar is a platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. +RackN's Website (https://rackn.com/); Digial Rebar (https://rackn.com/rebar/) +Follow Rob on Twitter (https://twitter.com/zehicle) or LinkedIn (https://www.linkedin.com/in/rhirschfeld/). Visit his website at robhirschfeld.com (https://robhirschfeld.com/). +Follow RackN on Twitter (https://twitter.com/rackngo), LinkedIn (https://www.linkedin.com/company/rackn/), or YouTube (https://www.youtube.com/channel/UCr3bBtP-pMsDQ5c0IDjt_LQ). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Rob Hirschfeld, Founder, and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. Rob, welcome to the show +ROB: Chad, it is a pleasure to be here. Looking forward to the conversation. +CHAD: Why don't we start with a little bit more information about what RackN and the Digital Rebar platform actually is. +ROB: I would be happy to. RackN is focused on helping customers automate infrastructure. And for us, it's really important that the customers are doing the automation. We're very focused on customer autonomy and self-management. It's why we're a software company, not a services or as a service platform company. +But fundamentally, what Digital Rebar does is it is the platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. And we were talking data centers do a lot of on-premises all the way from the bare metal up. But multi-cloud, you name it, we're doing infrastructure at that level. +CHAD: So, how agnostic to the actual bare metal are you? +ROB: We're very agnostic to the bare metal. The way we look at it is data centers are heterogeneous, diverse places. And that the thing that sometimes blocks companies from being innovative is when they decide, oh, we're going to use this one vendor for this one platform. And that keeps them actually from moving forward. So when we look at data centers, the heterogeneity and sometimes the complexity of that environment is a feature. It's not a bug from that perspective. +And so it's always been important to us to be multi-vendor, to do things in a vendor-neutral way to accommodate the quirks and the differences between...and it's not just vendors; it's actually user choice. A lot of companies have a multi-vendor problem (I'm air quoting) that is actually a multi-team problem where teams have chosen to make different choices. +TerraForm has no conformance standard built into it. [laughs] And so you might have everybody in your company using TerraForm and Ansible happily but all differently. And that's the problem that we walk into when we walk into a data center challenge. And you can't sweep that under the rug. So we embraced it. +CHAD: What kind of companies are your primary customers? +ROB: We're very wide-ranging, from the top banks use us and deploy us, telcos, service providers, very large scale service providers use us under the covers, media companies. It really runs the gamut because it's fundamentally for us just about infrastructure. And our largest customers are racing to be the first to deploy. And it's multi-site, but 20,000 machines that they're managing under our Digital Rebar management system. +CHAD: It's easy, I think, depending on where you sit and your experiences. The cloud providers today can overshadow the idea that there are even people who still have their own data centers or rent a portion of a data center. In today's ecosystem, what are some of the factors that cause someone to do that who isn't an infrastructure provider themselves? +ROB: You know the funny thing about these cloud stories (And we're talking just the day after Amazon had a day-long outage.) is that even the cloud providers don't have you give up operation. You're still responsible for the ops. And for our customers, it's not like they can all just use Lambdas and API gateways. At the end of the day, they're actually doing multi-site distributed operations. And they have these estates that are actually it's more about how do I control distributed infrastructure as much as it is about repatriating. +Now, we do a lot to help people repatriate. And they do that because they want more control. Cost savings is a significant component with this. You get into the 1000s of machines, and that's a big deal. Even at hundreds of machines, you can save a lot of money compared to what you get in cloud. +And I think people get confused with it being an or choice. It really is an and choice. Our best customers are incredibly savvy cloud users. They want that dynamic, resilient very API-driven environment. And they're looking to bring that throughout the organization. And so those are the ones that get excited when they see what we've done because we spend a lot of time doing infrastructure as code and API-driven infrastructure. That's really what they want. +CHAD: Cool. So, how long have you been working on RackN? When did you found it? +ROB: [laughs] Oh my goodness. So RackN is seven years old. Digital Rebar, we consider it to be at its fourth generation, but those numbers actually count back before that. They go back to 2009. The founding team was actually at Dell together in the OpenStack heyday and even before the OpenStack heyday. And we were trying to ship clouds from the Dell Factory. +And what we found was that every customer had this bespoke data center we've already talked about. And we couldn't write automation that would work customer to customer to customer. And it was driving us nuts. We're a software team, not a hardware team inside of Dell. And the idea that if I fixed something in the delivery or in their data center, and couldn't go back to their data center because it was different than what the next customer needed and the next customer needed, we knew that we would never have a community. It's very much about this community and reuse pattern. +There's an interesting story that I picked up from SREcon actually where they were talking about the early days of boilers. This is going back a few centuries ago. But when they first started putting boilers into homes and buildings, there was no pattern, there was no standard. And everybody would basically hire a plumber or a heating architect. Heating architect was a thing. +But you'd build a boiler and every one was custom, and every one was different. And no surprise, they blew up a lot, and they caused fires. And buildings were incredibly unsafe because they were working on high-pressure systems with no pattern. And it took regulation and laws and standards. And now nobody even thinks about it. You just take standard parts, and you connect them together in standard ways. And that creates actually a much more innovative system. You wouldn't want every house to be wired uniquely either. +And so when we look at the state of automation today, we see it as this pre-industrial pre-standardization process and that companies are actually harmed and harming themselves because they don't have standards, and patterns, and practices that they can just roll and know they work. +And so that philosophy started way back in 2009 with the first generation which was called Crowbar. Some of your audience might even remember this from the OpenStack days. It was the first OpenStack installer built around Chef. And it had all sorts of challenges in it, but it showed us the way. And then we iterated up to where Digital Rebar is today. Really fully infrastructure as code, building infrastructure pipelines, and a lot of philosophical pieces we've learned along the way. +CHAD: So you were at Dell working on this thing. How did you decide to leave Dell and start something new? +ROB: Dell helped me with that decision. [laughs] So the challenge of being a software person inside of Dell especially at the time, Crowbar was open-source which did make it easier for us to say, "Hey, we want to part ways but keep the IP." And the funny thing is there's not a scrap of Crowbar in Digital Rebar except one or two naming conventions that we pulled forward and the nod of the name, that Rebar is a nod to Crowbar. +But what happened was Dell when it went private, really did actually double down on the hardware and the more enterprise packaged things. They didn't want to invest in DevOps and that conversation that you need to have with your customers on how they operate, the infrastructure you sold them. And that made Dell not a very good place for me and the team. And so we left Dell, looked at the opportunity to take what we'd been building with Crowbar and then make it into a product. That's been a long journey. +CHAD: Now, did you bootstrap, or did you take investment? +ROB: We took [laughs] a little bit of investment. We raised some seed funding. Certainly not what was in hindsight was going to be sufficient for us to do it. But we thought at the time that we had something that was much more product-ready for customers than it was. +CHAD: And what was the challenge that you found? What was the surprise there that it wasn't as ready as you thought? +ROB: So what we've learned in our space specifically...and there are some things that I think apply to everybody, and there are some things that you might be able to throw on the floor and ignore. I was a big fan of Minimum Viable Product. And it turned out that the MVP strategy was not at all workable with customers in data centers. +Our product is for people running production data centers. And nobody's going to put in software to run a data center that is MVP. It has to be resilient. It has to be robust. It has to be simple enough that they can understand it and solve some core problems, which is still sort of an MVP idea. But it can't be oops. [laughs] You can't have a lot of oops moments when you're dealing with enterprise infrastructure automation software. It has to work. +And importantly, and as a design note, this has been a lesson for us. If it does break, it has to break in very transparent, obvious ways. And I can't emphasize that enough. There's so much that when we build it, we come back and like, was it obvious that it broke? Is it obvious that it broke in a way that you can fix? +CHAD: And it's part of the culture too to do detailed post mortems with explanations and be as transparent as possible or at least find the root cause so that you can address it. That's part of the culture of the space too, right? +ROB: You'd like to hope so. [laughs] +CHAD: Okay. [laughs] In my experience, that's the culture of the space. +ROB: You're looking more at a developer experience. But even with a developer, you've got to be in a post mortem or something. And it's like everybody's pointing to the person to the left and the right sort of by human nature. You don't walk into that room assuming that it was your fault, and you should, but that's not how it usually is approached. +And what we find in the ops space, and I would tell people to work around this pattern if they can, is that if you're the thing doing the automation, you're always the first cause of the problem. So we run into situations where we're doing a configuration, and we find a vendor bug or a glitch or there's something, and we found it. It's our problem whether we were the cause or not. And that's super hard. +I think that people on every side of any type of issue need to look through and figure out what the...the blameless post mortem is a really important piece in all this. At the end of the day, it's always a human system that made a mistake or has something like that. But it's not as simple as the thing that told you the bad news that the messenger was at fault. +And there's a system design element to that. That's what we're talking about here is that when you're exposing errors or when something's not behaving the way you expect, our philosophy is to stop. And we've had some very contentious arguments with customers who were like, "Just retry until it fixes itself," or vendors who were like, "Yeah, if you retry that thing three times, [laughs] then it'll magically go away." And we're like, that's not good behavior. Fix the problem. It actually took us years to put a retry element into the tasks so that you can say, yeah, this does need three retries. Just go do it. We've resisted for a long time for this reason. +CHAD: So you head out into the market. And did you get initial customers, or was there so much resistance to the product that you had that you struggled to get even first customers? +ROB: We had first customers. We had a nice body of code. The problem is actually pretty well understood even by our customers. And so it wasn't hard for them to get a trial going. So we actually had a very profitable customer doing...it was in object storage, public object storage space. And they were installing us. They wanted to move us into all their data centers. +But for it to work, we ended up having an engineer who basically did consulting and worked with them for the better part of six months and built a whole bunch of stuff, got it working. They could plug in servers, and everything would set itself up. And they could hit a button and reset all the servers, and they would talk to the switches. It was an amazing amount of automation. +But, and this happens a lot, the person we'd been working with was an SRE. And when they went to turn it over to the admins in the ops team, they said, [laughs] "We can't operate. There's too much going on, too complex." And we'd actually recognized...and this is a really serious challenge. It's a challenge now that we're almost five years into the generation that came after that experience. +And we recognized there was a problem. And that this wasn't going to create that repeatable experience that we were looking for if it took that much. At the same time, we had been building what is now Digital Rebar in this generation that was a single Golang binary. All the services were bundled into the system. So it listened on different ports but provide all the services, very easy to install, really, really simple. We literally stripped everything back to the basics and restarted. +And we had this experience where we sat down with a customer who had...I'm going to take a second and tell the story because this is such a compelling story from a product experience. So we took our first product. We were in a bake-off with another bare metal focus provisioning at the time. And they were in a lab, and they set our stuff up. And they turned it on, and they provisioned. And they set up the competitor, and they turned it on and provisioned. And both products worked. +Our product took 20 minutes to go through the cycle and the competitor took 3. And the customer came back and said, "I can't use this. I like your product better. It has more controls with all this stuff." But it took 20 minutes instead of 3. We actually logged into the system, looked at it and we were like, "Well, that's because it recognized that your BIOS was out of date, patched your BIOS, updated the system, checked that it was right, and then rebooted the systems and then continued on its way because it recognized your systems were outdated automatically. +And he said, "I didn't want it to do that. I needed it to boot as quickly as possible." And literally, [laughs] we were in the middle of a team retreat. So it's like, the CTO is literally excusing himself on the table to talk to the guy to make this stuff, try and make it right. And he's like, "Well, we've got this new thing. Why don't you install this, what's now Digital Rebar, on the system and repeat the experiment?" And he did and Digital Rebar was even faster than the competitor. And it did exactly just install, booted, and was done. +And he came back to the table, and it took 15 minutes to have the whole conversation to make everything work. It was that much of a simpler design. And he sat down and told the story. And I was in the middle of it. I'm just like, "We're going to have to pivot and put everything into the new version," which is what we did. And we just ripped out the complexity. And then over the last couple of years now, we've built the complexity back into the system to do all those additional but much more customer-driven from that perspective. +CHAD: How did you make sure that as you were changing your focus, putting all of your energy into the new version that you [laughs] didn't introduce too much risk in that process or didn't take too long? +ROB: [laughs] We did take too long and introduced too much risk, and we did run out of money. [laughs] All those things happened. This was a very difficult decision. We thought we could get it done much faster. The challenge of the simpler product was that it was too simple to be enough in customers’ data centers. And so yeah, we almost went out of business in the middle of all this cycle. We had a time where RackN went back down to just the two founders. +And at this point, we'd gotten far enough with the product that we knew it was the right thing. And we'd also embedded a degree...with the way we do the UX, we have this split. The UX runs on a hosted system. It doesn't have to but by default, it does. And then we have the back end. So we were very careful about how we collected metrics because you really need to know who's downloading and using your products. +And we had enough data from that to realize that we had some very committed early users and early customers, just huge brand names that were playing around. So we knew that we'd gotten this mix right, that we were solving a problem in a unique way. But it was going to take time because big companies don't make decisions quickly. We have a joke. We call it the reorg half-life problem. So the half-life of a reorg in any of our customers is about nine months. And either you're successful inside of that reorg half-life, or you have to be resilient across this reorg half. +And so initially, it was taking more than nine months. We had to be able to get the product in play. And once we did, we had some customers who came in with very big checks and let us come back and basically build back up. And we've been adding some really nice names into our customer roster. Unfortunately, it's all private. I can tell you their industries and their scale, but I can't name them. +But that engagement helped drive us towards the feature set and the capabilities and building things up along that process. But it was frustrating. And some of them, especially at the time we were open-source, were very happy to say, "No, we are a super big brand name. We don't pay for software." I'm like, "Most profitable, highest valued companies in the world you don't want to pay for this operational software?" And they're like, "No, we don't have to." And that didn't sit very well with us. Very hard, as a starting startup, it was hard. +CHAD: At the time, everything you were doing was open source. +ROB: So in the Digital Rebar era, we were trying to do Open Core. Digital Rebar itself was open. And then we were trying to hold back the BIOS patches, integrate enterprise single sign-on. So there was a degree of integration pieces that we held back as RackN and then left the core open. So you could use Digital Rebar and run it, which we had actually had a lot of success with people downloading, installing, and running Digital Rebar, not as much success in getting them to pay us for that privilege. +CHAD: So, how did you adjust to that reality? +ROB: We inverted the license. After we landed a couple of big banks and we had several others and some hyperscalers too who were like, "This is really good software. We love it. We're embedding it in our service, but we're not going to pay you." And then they would show up with bugs and complaints and issues and all sorts of stuff still. +And what happened is we started seeing them replicating the closed pieces. The APIs were open. We actually looked at it and listening to our communities, they wanted to see what was in the closed pieces. That was actually operationally important for them to understand how that stuff worked. They never contributed or asked to see anything in the core. And, there's an important and here, and they needed performance improvements in the core that were radically different. +So the original open-source stuff went to maybe 500 machines, and then it started to cap out. And we were like, all right, we're going to have to really rewrite the data store mechanisms that go with this. And the team looked at each other and were like, "We're not going to open source that. That's really complex and challenging IP." And so we said the right model for us is going to be to make the core closed and then allow our community and users to see all the things that they are actually using to interact with their environment. And it ends up being a little bit of a filter. +There are people who only use open-source software. But those companies also don't necessarily want to pay. When I was an open-source evangelist, this was always a problem. You're pounding on the table saying, "If you're using open-source software, you need to understand who to pay for that service, that software that you're getting. If you're not paying for it, that software is going to go away." In a lot of cases, we're a walking example of that. +And it's funny, more of the codebase is open today than it was then. [chuckles] But the challenge is that it's really an open ecosystem now because none of that software is particularly useful without the core to run it and glue everything together. +CHAD: Was that a difficult decision to make? Was it controversial? +ROB: Incredibly difficult. It was something I spent a lot of time agonizing about. My CTO is much clear-eyed on this. From his perspective, he and the other engineers are blood, sweat, and tears putting this in. And it was very frustrating for them to see it running people's production data centers who told us, and this is I think the key, who just said to us, "You know, we're not going to pay money for that." And so for them, it was very clear-eyed it's their work, their sweat equity, very gut feeling for that. +For me, I watched communities with open-source routes, you know, the Kubernetes community. I was in OpenStack. I was on the board for that. And there is definitely a lift that you get from having free software and not having the strings. And I also like the idea that from a support perspective, if you're using open-source software, you could conceivably not care for the vendor that went away. You could find another life for it. +But years have gone by and that's not actually a truism that when you are using open-source software if you're getting it from a vendor, you're not necessarily protected from that vendor making decisions for you. CentOS is a great...the whole we're about to hit the CentOS deadlines, which is the Streams, and you can't get other versions. And we now have three versions of CentOS, at least three versions of CentOS with Rocky, and Alma, and CentOs Streams. Those are very challenging decisions for people running enterprise data centers, not that simple. +And nobody in our communities is running charity data centers. There's no goodwill charity. I'm running a data center out of the goodness of my heart. [laughs] They are all production systems, enterprise. They're doing real production work. And that's a commercial engagement. It's not a feel-good thing. +CHAD: So what did you do in your decision-making process? What pushed you, or what did you come to terms with in order to make that change? +ROB: I had to admit I was wrong. [laughter] I had to think back on statements I'd made and the enthusiasm that I'd had and give up some really hard beliefs. Being a CEO or a founder is the same process. So I wish I could say this was the only time [laughs] I had to question, you know, hard-made assumptions, or some core beliefs in what I thought. +I've had to get really good at questioning when am I projecting this is the way I want the world to be therefore it will be? That's a CEO skill set and a founder skill set...and when that projection is having you on thin ice. And so you constantly have to make that balance. +And this was one of those ones where I'm like, all right, let's do it. And I still wake up some mornings and look at people who are open source only and see how much press they get or how easy it is for them to get mentions and things like that. And I'm like, ah, God, that'd be great. It feels like it's much harder for us because we're commercial to get the amplification. +There are conferences that will amplify open-source TerraForm, great example. It gets tons of amplification for being a single vendor project that's really tightly controlled by HashiCorp. But nobody is afraid to go talk about TerraForm and mention TerraForm and do all this stuff, the amazing use of open source by that company. But they could turn it and twist it, and they could change it. It's not a guarantee by any stretch of the imagination. +CHAD: Well, one of the things that I've come to terms with, and maybe this is a very positive way of looking at it, instead of that you were wrong, [laughter] is to realize that well, you weren't necessarily wrong. It got you to where you were at that point. But maybe in order to go to the next level, you need to do something different. And that's how I come to terms with some things where I need to change my thinking. +ROB: [laughs] I like that. It's good. Sometimes you can look back and be like, yeah, that wasn't the right thing and just own it. But yeah, it does help you to know the path. Part of the reason why I love talking about it with you like this is it's not just Rob was wrong; we're actually walking the path through that decision. And it's easy to imagine us sitting in...we're in a tiny, little shared office listening to calls where...I'll tell you this as a story to make it incredibly concrete because it's exactly how this happened. +We were on a call. Everybody was in the room. And we were talking to a major bank saying, "We love your software." We're like, "Great, we're looking forward to working with you," all this stuff. And they're like, "Yeah, we need you to show us how you built this plugin because we want to write our own version of it." +CHAD: [chuckles] +ROB: We're like, "If you did that, you wouldn't need to buy our software." And they're like, "That's right. We're not going to buy your software." +CHAD: Exactly. [laughs] +ROB: And we're like, "Well, we won't show you how to use it. Then we won't show you how to do that." And they're like, "Well, okay. We'll figure it out ourselves." And so I'm the cheerful, sunny, positive, sort of managing the call, and I'm not just yelling at them. My CTO is sitting next to me literally tearing his hair. This was literally a tearing his hair out moment. And we hung up the call, and we went on a walk around the neighborhood. And he was just like, "What more do you need to hear for you to understand?" +And so it's moments like that. But instead of being like, no, you're wrong, we got to do it this way, I was ready to say, "Okay, what do you think we can do? How do we think we can do it?" And then he left me with a big pile of PR messaging to explain what we're doing, conversations like this. Two years ago when we made this change, almost three, I felt like I was being handed a really hard challenge. +As it turns out, it hasn't been as big a deal. The market has changed about how they perceive open source. And for enterprise customers, they're like, "All right, how do we deal with the licensing for this stuff?" And we're like, "You just buy it from us." And they're like, "That's it?" And I'm like, "Yes." And you guarantee every..." "Yes." They're like, "Oh. Well, that's pretty straightforward. I don't have to worry about..." +We could go way down an open-source rabbit hole and the consulting pieces and who owns the IP, and I used to deal with all that stuff. Now it's very straightforward. [laughs] Like, "You want to buy and use the software to run your data center?" "Yes, I do." "Great." +CHAD: Well, I think this is generally applicable even beyond your specific product but to products in general. It's like, when you're not talking to people who are good customers or who are even going to be your customers who are going to pay for what you want, you can spend a lot of time and energy trying to please them. But you're not going to be successful because they're not going to be your customers no matter what you do. +ROB: And that ends up being a bit of a filter with the open-source pieces is that there are customers who were dyed in the wool open source. And this used to be more true actually as the markets moved a lot. We ended up just not talking to many. But they do, they want a lot. They definitely would ask for features or things and additions and help, things like that. And it's hard to say no. Especially as a startup founder, you want to say yes a lot. +We try to not say yes to things that we don't...and this puts us at a disadvantage I feel like from a marketing perspective. If we don't do something, we tend to say we don't do it, or we could do it, but it would take whatever. I wish more people in the tech space were as disciplined about this does work, this doesn't work, this is a feature. This is something we're working on. It's not how tech marketing typically works sadly. That's why we focus on self-trials so people can use the product. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So you have the core and then you have the ecosystem. And you also mentioned earlier that it is an actual software package that people are buying and installing in their data center. But then you have the UI which is in the cloud and what's in the data center is reporting up to that. +ROB: Well, this is where I'm going to get very technical [laughs] so hang on for a second. We actually use a cross-domain approach. So the way this works...and our UX is written in React. And everything's...boy, there's like three or four things I have to say all at once. So forgive me as I circle. +Everything we do at Digital Rebar is API-first, really API only, so the Golang service with an API, which is amazing. It's the right way to do software. So for our UX, it is a React application that can talk to that what we call an endpoint, that Digital Rebar endpoint. And so the UX is designed to talk directly to the Digital Rebar endpoint, and all of the information that it gets comes from that Digital Rebar endpoint. We do not have to relay it. Like, you have to be inside that network to get access to that endpoint. And the UX just talks to it. +CHAD: Okay. And so the UX is just being served from your centralized servers, but you're just delivering the React for the JavaScript app. And that is talking to the local APIs. +ROB: Right. And so we do use that browser as a bridge. And so when you want to download new content packs...so Digital Rebar is a platform. So you have to download content and automation and pieces into it. The browser is actually your bridge to do that. So the browser can connect to our catalog, pull down our catalog, and then send things into that browser. So it's super handy for that. +But yeah, it's fundamentally...it's all behind your firewall software except...and this is where people get confused because you're downloading it from rackn.io. That download or the URL on the browser looks like it's a RackN URL even though all the traffic is network local. +CHAD: Do your customers tend to stay up to date? Are they updating to the latest version right away all the time? +ROB: [laughs] No, of course not. +CHAD: I figured that was the answer. +ROB: And we maintain patches on old versions and things like that. I wish they were a little faster. I'm not always sad that they're...I'm actually very glad when we do a release like we did yesterday...And in that release, I don't expect any of our production customers to go patch everything. +So in a SaaS, you might actually have to deal with the fact that you've got...and we're back to our heterogeneity story. And this is why it's important that we don't do this. If we were to push that, if we didn't handle every situation for every customer exactly right, there would be chaos. And it would all come back to our team. The way we do it means that we don't have to deal with that. Customers are in control of when they upgrade and when they migrate, except in the UX case. +CHAD: So how do you manage that if someone goes to the UI and their local thing is an old version? Are you detecting that and doing things differently? +ROB: Yes, one of the decisions we made that I'm really happy with is we embedded feature flags into the API. When you log in, it will pull back. We know what the versions are. But versions are really problematic as a way to determine what's in software, not what's not in software. So instead, we get an array back that has feature flags as we add features into the core. And we've been doing this for years. And it's an amazingly productive process. +And so what the UX does is as we add new things into the UX, it will look for those feature flags. And if the feature flag isn't there, it will show you a message that says, "This feature is not available for your endpoint," or show you the thing appropriate without that. And so the UX has gone through years of this process. And so there are literally just places where the UX changes behavior based on what you've installed on your system. +And remember, our customers it's multi-site. So our customers do have multiple versions of Digital Rebar installed across there. So this behavior is really important also for them to be able to do it. And it goes back to LaunchDarkly. I was talking to Edith back in the early days of LaunchDarkly and feature flags, and I got really excited about that. And that's why we embedded it into the product. Everybody should do it. It's amazing. +CHAD: One of the previous episodes a few ago was with actually the thoughtbot CTO, Joe Ferris. And we're on a project together where it's a different way of working but especially when you need it... so much of what I had done previously was versioned APIs. Maybe that works at a certain scale. But you get to a certain scale of software and way of working and wanting to do continuous deployment and continually update features and all that stuff. And it's a really good way of working when instead you are communicating on the level of feature availability. +ROB: And from an ops person's perspective, and this was true with OpenStack, they were adding feature flags down at the metadata for the...it was incredible. They went deep into the versioned API hellscape. It's the only way I can describe it [laughs] because we don't do that. But the thing that that does not help you with is a lot of times the changes that you're looking at from an API perspective are behavior changes, not API changes. Our API over years now has been additive. +And as long as you're okay with new objects showing up, new fields showing up in an object, you could go back to four-year-old software, talk to our API, and it would still work just fine. So all your integrations are going to be good, but the behavior might change. And that's what people don't...they're like, oh, I can make my API version, and everything's good. But the behavior that you're putting behind the scenes might be different. You need a way to express that even more than the APIs in my opinion. +CHAD: I do think you really see that when you...if you're just building a monolithic web app, it's harder to see. But once you separate your UI from your back end...and where I first hit this was with mobile applications. The problem becomes more obvious to you as a developer I think. +ROB: Yes. +CHAD: Because you have some people out there who are actually running different versions of your UI too. So your back end is the same for everybody but your UI is different. +ROB: [laughs] +CHAD: And so you need a back end that can respond to different clients. And a better way to do that rather than versioning your API is to have the clients tell you what they're capable of while they're making the requests and to respond differently. It's much more of a flexible way. +ROB: We do track what UX. We have customers who don't want to use that. They don't even want us changing the UX...or actually normal enterprise. And so they will run...the nice thing about a React app is you can just run it. The Digital Rebar can host its UX, and that's perfectly reasonable. We have customers who do that. +But every core adds more operational complexity. And then if they don't patch the UX, they can fall behind or not get features. So we see that it's...you're describing a real, you know, the more information you're exchanging between the clients and the servers, the better for you to track what's really going on. +CHAD: And I think overall once you can get a little...in my experience, especially people who haven't worked that way, joining the team, it can take a little bit for them to get comfortable with that approach and the flexibility you need to be building into your system. But once people are comfortable with it and the team is comfortable, it really starts to hum. +In my experience, a lot of what we've advocated for in terms of the way software should be built and deployed and that kind of thing is it actually makes it so that you can leave that even easier. And you can really be agile because you can roll things out in a very agile way. +ROB: So are you thinking like an actual rolling deployment where the deployed software has multiple versions coming through? +CHAD: Yep. And you can also have different users seeing different things at different times as well. You can say, "We're going to be doing continual deployment and have code continually deployed." But that doesn't mean that it's part of the release yet, that it's available to users to use. +ROB: Yeah, that ability to split and feature flag is a huge deal. +CHAD: Yeah. What I'm trying to figure out is does this apply to every project even the small like, this just changes the way you should build software? Or is there a time in a product to start introducing that thing? +ROB: I am a big fan of doing it first and fast. There are decisions that we made early that have proven out really well. Feature flags is one of them. We started right away knowing that this would be an important thing for us to do. And same thing with tracking dependencies and being able to say, "I need..." actually, it's helpful because you can write automation that says, "I need this feature in the product." This flag and the product it's not just a version thing. That makes the automation a little bit more portable, easier to maintain. +The other thing we did that I really like is all of our objects have documentation embedded in them. So as I write a parameter or an ask or really anything in the system, everything has a documentation field. And so I can write the documentation for that component right there. And then we modified our build scripts so that they will pull in all of that documentation and create an aggregated view. And so the ability to do just-in-time documentation is very, very high. And so I'm a huge fan of that. +Because then you have the burden of like, oh, I need to go back and write up a whole bunch of documentation really lessened when you can be like, okay, for this parameter, I can explain its behavior, or I can tell you what it does and know that it's going to show up as part of a documentation set that explains it. That's been something I've been a big fan of in what we build. +And not everybody [laughs] is as much a fan. And you can see people writing stuff without particularly crisp documentation behind it. But at least we can go back and add that documentation or lessons learned or things like that. And it's been hugely helpful to have a place to do that. +From a design perspective, one other thing I would say that we did that...and you can imagine the conversation. I have a UX usability focus. I'm out selling the product. So for me, it's how does it demo? How does it show? What's that first experience like? And so for me having icons and colors in the UX, in the experience is really important. Because there's a lot of semantic meaning that people get just looking down a list of icons and seeing that they are different colors and different shapes. +But from the CTO's perspective, that's window dressing. Who cares? It doesn't have functional purpose. And we're both right. There's a lot of times when to me, both people can be right. So we added that as a metafield into all of our objects. And so we have the functional part of the definition of the API. And then we have these metaobjects that you can add in or meta definitions that you can add in behind the scenes to drive icons and colors. +But sometimes UX rendering hints and things like that that from an API perspective, you're like, I don't care, not really an API thing. But from a do I show...this is sensitive information. Do I turn it into a password field? Or should this have a clipboard so I can clipboard icon it, or should I render it in this type of viewer or a plain text viewer? And all that stuff we have a place for. +CHAD: And so it's actually being delivered by the API that's saying that. +ROB: Correct. +CHAD: That's cool. +ROB: It's been very helpful. You can imagine the type of stuff we have, and it's easy to influence UX behaviors without asking for UI change. +CHAD: Now, are these GraphQL APIs? +ROB: No. We looked at doing that. That's probably a whole nother...I might get our CTO on the line for that. +CHAD: [laughs] It's a whole nother episode for that. +ROB: But we could do that. But we made some decisions that it wasn't going to provide a lot of lift for us in navigation at the moment. It's funny, there's stuff that we think is a really cool idea, but we've learned not to jump on them without having really specific customer use cases or validations. +CHAD: Well, like you said, you've got to say no. You've got to make decisions about what is important, and what isn't important now, and what you'll get to later, and that requires discipline. +ROB: This may be a way to bring it full circle. If you go back to the stories of every customer having a unique data center, there’s this heterogeneity and multi-vendor pieces that are really important. The unicycle we have to ride for this is we want our customers to have standard operating processes, standard infrastructure pipelines for this and use those and follow that process. +Because we know if they do, then they'll keep improving as we improve the pipelines. And they're all unique. So there has to be a way in those infrastructure pipelines to do extensions that allow somebody to say, "I need to make this call here in the middle of this pipeline." And we have ways to do that address those needs. +The challenge becomes providing enough opinionated like, this is how you should do things. And it's okay if you have to extend it or change it a little bit or tweak it without it just becoming an open-ended tool where people show up and they're like, "Oh, yeah, I get how to build something." And we have people do this, but they run out of gas in the long journey. +They end up writing bespoke workflows. They write their own pipelines; they do their own integrations. And for them, it's very hard to support them. It's very hard to upgrade them. It's very hard for them to survive the reorg, your nine-month reorg windows. +And so yeah, there's a balance between go do whatever you want, which you have to enable and do it our way because these processes are going to let your teams collaborate, let you reuse software. And we've actually over time been erring more and more on the side of you really need to do it the way we want you to do; reinforce the infrastructure as code processes. +And this is the key, right? I mean, you're coming from a development mindset. You want your tooling to reinforce good behavior, CICD, infrastructure as code, all these things. You need those to be easier to do [laughs] than writing it yourself. And over time, we've been progressing more and more towards the let's make it easier to do it within the opinionated way that we have and less easy to do it within the Wild West pattern. +CHAD: Cool. Well, I think with that, we'll start to wrap up. So if people want to find out more, where are some places that they could do that or get in touch with you? +ROB: The simplest thing is of course rackn.com is the website. We encourage people to just, if this is interesting, download and try the software. If they have a cloud account, it's super easy to play with it, all things RackN through that. +I am very active on Twitter under the handle @zehicle Z-E-H-I-C-L-E. And I'm happy to have conversations around these topics and data center and operations and even the future of cloud and edge computing. So please look me up. I'm excited to have conversations like that. +CHAD: Awesome. And you can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chad talks to Rob Hirschfeld, the Founder and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. RackN is focused on helping customers automate infrastructure. They focus on customer autonomy and self-management, and that's why they're a software company, not a services or as-a-service platform company.

+ +

Digital Rebar is a platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Rob Hirschfeld, Founder, and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. Rob, welcome to the show

+ +

ROB: Chad, it is a pleasure to be here. Looking forward to the conversation.

+ +

CHAD: Why don't we start with a little bit more information about what RackN and the Digital Rebar platform actually is.

+ +

ROB: I would be happy to. RackN is focused on helping customers automate infrastructure. And for us, it's really important that the customers are doing the automation. We're very focused on customer autonomy and self-management. It's why we're a software company, not a services or as a service platform company.

+ +

But fundamentally, what Digital Rebar does is it is the platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. And we were talking data centers do a lot of on-premises all the way from the bare metal up. But multi-cloud, you name it, we're doing infrastructure at that level.

+ +

CHAD: So, how agnostic to the actual bare metal are you?

+ +

ROB: We're very agnostic to the bare metal. The way we look at it is data centers are heterogeneous, diverse places. And that the thing that sometimes blocks companies from being innovative is when they decide, oh, we're going to use this one vendor for this one platform. And that keeps them actually from moving forward. So when we look at data centers, the heterogeneity and sometimes the complexity of that environment is a feature. It's not a bug from that perspective.

+ +

And so it's always been important to us to be multi-vendor, to do things in a vendor-neutral way to accommodate the quirks and the differences between...and it's not just vendors; it's actually user choice. A lot of companies have a multi-vendor problem (I'm air quoting) that is actually a multi-team problem where teams have chosen to make different choices.

+ +

TerraForm has no conformance standard built into it. [laughs] And so you might have everybody in your company using TerraForm and Ansible happily but all differently. And that's the problem that we walk into when we walk into a data center challenge. And you can't sweep that under the rug. So we embraced it.

+ +

CHAD: What kind of companies are your primary customers?

+ +

ROB: We're very wide-ranging, from the top banks use us and deploy us, telcos, service providers, very large scale service providers use us under the covers, media companies. It really runs the gamut because it's fundamentally for us just about infrastructure. And our largest customers are racing to be the first to deploy. And it's multi-site, but 20,000 machines that they're managing under our Digital Rebar management system.

+ +

CHAD: It's easy, I think, depending on where you sit and your experiences. The cloud providers today can overshadow the idea that there are even people who still have their own data centers or rent a portion of a data center. In today's ecosystem, what are some of the factors that cause someone to do that who isn't an infrastructure provider themselves?

+ +

ROB: You know the funny thing about these cloud stories (And we're talking just the day after Amazon had a day-long outage.) is that even the cloud providers don't have you give up operation. You're still responsible for the ops. And for our customers, it's not like they can all just use Lambdas and API gateways. At the end of the day, they're actually doing multi-site distributed operations. And they have these estates that are actually it's more about how do I control distributed infrastructure as much as it is about repatriating.

+ +

Now, we do a lot to help people repatriate. And they do that because they want more control. Cost savings is a significant component with this. You get into the 1000s of machines, and that's a big deal. Even at hundreds of machines, you can save a lot of money compared to what you get in cloud.

+ +

And I think people get confused with it being an or choice. It really is an and choice. Our best customers are incredibly savvy cloud users. They want that dynamic, resilient very API-driven environment. And they're looking to bring that throughout the organization. And so those are the ones that get excited when they see what we've done because we spend a lot of time doing infrastructure as code and API-driven infrastructure. That's really what they want.

+ +

CHAD: Cool. So, how long have you been working on RackN? When did you found it?

+ +

ROB: [laughs] Oh my goodness. So RackN is seven years old. Digital Rebar, we consider it to be at its fourth generation, but those numbers actually count back before that. They go back to 2009. The founding team was actually at Dell together in the OpenStack heyday and even before the OpenStack heyday. And we were trying to ship clouds from the Dell Factory.

+ +

And what we found was that every customer had this bespoke data center we've already talked about. And we couldn't write automation that would work customer to customer to customer. And it was driving us nuts. We're a software team, not a hardware team inside of Dell. And the idea that if I fixed something in the delivery or in their data center, and couldn't go back to their data center because it was different than what the next customer needed and the next customer needed, we knew that we would never have a community. It's very much about this community and reuse pattern.

+ +

There's an interesting story that I picked up from SREcon actually where they were talking about the early days of boilers. This is going back a few centuries ago. But when they first started putting boilers into homes and buildings, there was no pattern, there was no standard. And everybody would basically hire a plumber or a heating architect. Heating architect was a thing.

+ +

But you'd build a boiler and every one was custom, and every one was different. And no surprise, they blew up a lot, and they caused fires. And buildings were incredibly unsafe because they were working on high-pressure systems with no pattern. And it took regulation and laws and standards. And now nobody even thinks about it. You just take standard parts, and you connect them together in standard ways. And that creates actually a much more innovative system. You wouldn't want every house to be wired uniquely either.

+ +

And so when we look at the state of automation today, we see it as this pre-industrial pre-standardization process and that companies are actually harmed and harming themselves because they don't have standards, and patterns, and practices that they can just roll and know they work.

+ +

And so that philosophy started way back in 2009 with the first generation which was called Crowbar. Some of your audience might even remember this from the OpenStack days. It was the first OpenStack installer built around Chef. And it had all sorts of challenges in it, but it showed us the way. And then we iterated up to where Digital Rebar is today. Really fully infrastructure as code, building infrastructure pipelines, and a lot of philosophical pieces we've learned along the way.

+ +

CHAD: So you were at Dell working on this thing. How did you decide to leave Dell and start something new?

+ +

ROB: Dell helped me with that decision. [laughs] So the challenge of being a software person inside of Dell especially at the time, Crowbar was open-source which did make it easier for us to say, "Hey, we want to part ways but keep the IP." And the funny thing is there's not a scrap of Crowbar in Digital Rebar except one or two naming conventions that we pulled forward and the nod of the name, that Rebar is a nod to Crowbar.

+ +

But what happened was Dell when it went private, really did actually double down on the hardware and the more enterprise packaged things. They didn't want to invest in DevOps and that conversation that you need to have with your customers on how they operate, the infrastructure you sold them. And that made Dell not a very good place for me and the team. And so we left Dell, looked at the opportunity to take what we'd been building with Crowbar and then make it into a product. That's been a long journey.

+ +

CHAD: Now, did you bootstrap, or did you take investment?

+ +

ROB: We took [laughs] a little bit of investment. We raised some seed funding. Certainly not what was in hindsight was going to be sufficient for us to do it. But we thought at the time that we had something that was much more product-ready for customers than it was.

+ +

CHAD: And what was the challenge that you found? What was the surprise there that it wasn't as ready as you thought?

+ +

ROB: So what we've learned in our space specifically...and there are some things that I think apply to everybody, and there are some things that you might be able to throw on the floor and ignore. I was a big fan of Minimum Viable Product. And it turned out that the MVP strategy was not at all workable with customers in data centers.

+ +

Our product is for people running production data centers. And nobody's going to put in software to run a data center that is MVP. It has to be resilient. It has to be robust. It has to be simple enough that they can understand it and solve some core problems, which is still sort of an MVP idea. But it can't be oops. [laughs] You can't have a lot of oops moments when you're dealing with enterprise infrastructure automation software. It has to work.

+ +

And importantly, and as a design note, this has been a lesson for us. If it does break, it has to break in very transparent, obvious ways. And I can't emphasize that enough. There's so much that when we build it, we come back and like, was it obvious that it broke? Is it obvious that it broke in a way that you can fix?

+ +

CHAD: And it's part of the culture too to do detailed post mortems with explanations and be as transparent as possible or at least find the root cause so that you can address it. That's part of the culture of the space too, right?

+ +

ROB: You'd like to hope so. [laughs]

+ +

CHAD: Okay. [laughs] In my experience, that's the culture of the space.

+ +

ROB: You're looking more at a developer experience. But even with a developer, you've got to be in a post mortem or something. And it's like everybody's pointing to the person to the left and the right sort of by human nature. You don't walk into that room assuming that it was your fault, and you should, but that's not how it usually is approached.

+ +

And what we find in the ops space, and I would tell people to work around this pattern if they can, is that if you're the thing doing the automation, you're always the first cause of the problem. So we run into situations where we're doing a configuration, and we find a vendor bug or a glitch or there's something, and we found it. It's our problem whether we were the cause or not. And that's super hard.

+ +

I think that people on every side of any type of issue need to look through and figure out what the...the blameless post mortem is a really important piece in all this. At the end of the day, it's always a human system that made a mistake or has something like that. But it's not as simple as the thing that told you the bad news that the messenger was at fault.

+ +

And there's a system design element to that. That's what we're talking about here is that when you're exposing errors or when something's not behaving the way you expect, our philosophy is to stop. And we've had some very contentious arguments with customers who were like, "Just retry until it fixes itself," or vendors who were like, "Yeah, if you retry that thing three times, [laughs] then it'll magically go away." And we're like, that's not good behavior. Fix the problem. It actually took us years to put a retry element into the tasks so that you can say, yeah, this does need three retries. Just go do it. We've resisted for a long time for this reason.

+ +

CHAD: So you head out into the market. And did you get initial customers, or was there so much resistance to the product that you had that you struggled to get even first customers?

+ +

ROB: We had first customers. We had a nice body of code. The problem is actually pretty well understood even by our customers. And so it wasn't hard for them to get a trial going. So we actually had a very profitable customer doing...it was in object storage, public object storage space. And they were installing us. They wanted to move us into all their data centers.

+ +

But for it to work, we ended up having an engineer who basically did consulting and worked with them for the better part of six months and built a whole bunch of stuff, got it working. They could plug in servers, and everything would set itself up. And they could hit a button and reset all the servers, and they would talk to the switches. It was an amazing amount of automation.

+ +

But, and this happens a lot, the person we'd been working with was an SRE. And when they went to turn it over to the admins in the ops team, they said, [laughs] "We can't operate. There's too much going on, too complex." And we'd actually recognized...and this is a really serious challenge. It's a challenge now that we're almost five years into the generation that came after that experience.

+ +

And we recognized there was a problem. And that this wasn't going to create that repeatable experience that we were looking for if it took that much. At the same time, we had been building what is now Digital Rebar in this generation that was a single Golang binary. All the services were bundled into the system. So it listened on different ports but provide all the services, very easy to install, really, really simple. We literally stripped everything back to the basics and restarted.

+ +

And we had this experience where we sat down with a customer who had...I'm going to take a second and tell the story because this is such a compelling story from a product experience. So we took our first product. We were in a bake-off with another bare metal focus provisioning at the time. And they were in a lab, and they set our stuff up. And they turned it on, and they provisioned. And they set up the competitor, and they turned it on and provisioned. And both products worked.

+ +

Our product took 20 minutes to go through the cycle and the competitor took 3. And the customer came back and said, "I can't use this. I like your product better. It has more controls with all this stuff." But it took 20 minutes instead of 3. We actually logged into the system, looked at it and we were like, "Well, that's because it recognized that your BIOS was out of date, patched your BIOS, updated the system, checked that it was right, and then rebooted the systems and then continued on its way because it recognized your systems were outdated automatically.

+ +

And he said, "I didn't want it to do that. I needed it to boot as quickly as possible." And literally, [laughs] we were in the middle of a team retreat. So it's like, the CTO is literally excusing himself on the table to talk to the guy to make this stuff, try and make it right. And he's like, "Well, we've got this new thing. Why don't you install this, what's now Digital Rebar, on the system and repeat the experiment?" And he did and Digital Rebar was even faster than the competitor. And it did exactly just install, booted, and was done.

+ +

And he came back to the table, and it took 15 minutes to have the whole conversation to make everything work. It was that much of a simpler design. And he sat down and told the story. And I was in the middle of it. I'm just like, "We're going to have to pivot and put everything into the new version," which is what we did. And we just ripped out the complexity. And then over the last couple of years now, we've built the complexity back into the system to do all those additional but much more customer-driven from that perspective.

+ +

CHAD: How did you make sure that as you were changing your focus, putting all of your energy into the new version that you [laughs] didn't introduce too much risk in that process or didn't take too long?

+ +

ROB: [laughs] We did take too long and introduced too much risk, and we did run out of money. [laughs] All those things happened. This was a very difficult decision. We thought we could get it done much faster. The challenge of the simpler product was that it was too simple to be enough in customers’ data centers. And so yeah, we almost went out of business in the middle of all this cycle. We had a time where RackN went back down to just the two founders.

+ +

And at this point, we'd gotten far enough with the product that we knew it was the right thing. And we'd also embedded a degree...with the way we do the UX, we have this split. The UX runs on a hosted system. It doesn't have to but by default, it does. And then we have the back end. So we were very careful about how we collected metrics because you really need to know who's downloading and using your products.

+ +

And we had enough data from that to realize that we had some very committed early users and early customers, just huge brand names that were playing around. So we knew that we'd gotten this mix right, that we were solving a problem in a unique way. But it was going to take time because big companies don't make decisions quickly. We have a joke. We call it the reorg half-life problem. So the half-life of a reorg in any of our customers is about nine months. And either you're successful inside of that reorg half-life, or you have to be resilient across this reorg half.

+ +

And so initially, it was taking more than nine months. We had to be able to get the product in play. And once we did, we had some customers who came in with very big checks and let us come back and basically build back up. And we've been adding some really nice names into our customer roster. Unfortunately, it's all private. I can tell you their industries and their scale, but I can't name them.

+ +

But that engagement helped drive us towards the feature set and the capabilities and building things up along that process. But it was frustrating. And some of them, especially at the time we were open-source, were very happy to say, "No, we are a super big brand name. We don't pay for software." I'm like, "Most profitable, highest valued companies in the world you don't want to pay for this operational software?" And they're like, "No, we don't have to." And that didn't sit very well with us. Very hard, as a starting startup, it was hard.

+ +

CHAD: At the time, everything you were doing was open source.

+ +

ROB: So in the Digital Rebar era, we were trying to do Open Core. Digital Rebar itself was open. And then we were trying to hold back the BIOS patches, integrate enterprise single sign-on. So there was a degree of integration pieces that we held back as RackN and then left the core open. So you could use Digital Rebar and run it, which we had actually had a lot of success with people downloading, installing, and running Digital Rebar, not as much success in getting them to pay us for that privilege.

+ +

CHAD: So, how did you adjust to that reality?

+ +

ROB: We inverted the license. After we landed a couple of big banks and we had several others and some hyperscalers too who were like, "This is really good software. We love it. We're embedding it in our service, but we're not going to pay you." And then they would show up with bugs and complaints and issues and all sorts of stuff still.

+ +

And what happened is we started seeing them replicating the closed pieces. The APIs were open. We actually looked at it and listening to our communities, they wanted to see what was in the closed pieces. That was actually operationally important for them to understand how that stuff worked. They never contributed or asked to see anything in the core. And, there's an important and here, and they needed performance improvements in the core that were radically different.

+ +

So the original open-source stuff went to maybe 500 machines, and then it started to cap out. And we were like, all right, we're going to have to really rewrite the data store mechanisms that go with this. And the team looked at each other and were like, "We're not going to open source that. That's really complex and challenging IP." And so we said the right model for us is going to be to make the core closed and then allow our community and users to see all the things that they are actually using to interact with their environment. And it ends up being a little bit of a filter.

+ +

There are people who only use open-source software. But those companies also don't necessarily want to pay. When I was an open-source evangelist, this was always a problem. You're pounding on the table saying, "If you're using open-source software, you need to understand who to pay for that service, that software that you're getting. If you're not paying for it, that software is going to go away." In a lot of cases, we're a walking example of that.

+ +

And it's funny, more of the codebase is open today than it was then. [chuckles] But the challenge is that it's really an open ecosystem now because none of that software is particularly useful without the core to run it and glue everything together.

+ +

CHAD: Was that a difficult decision to make? Was it controversial?

+ +

ROB: Incredibly difficult. It was something I spent a lot of time agonizing about. My CTO is much clear-eyed on this. From his perspective, he and the other engineers are blood, sweat, and tears putting this in. And it was very frustrating for them to see it running people's production data centers who told us, and this is I think the key, who just said to us, "You know, we're not going to pay money for that." And so for them, it was very clear-eyed it's their work, their sweat equity, very gut feeling for that.

+ +

For me, I watched communities with open-source routes, you know, the Kubernetes community. I was in OpenStack. I was on the board for that. And there is definitely a lift that you get from having free software and not having the strings. And I also like the idea that from a support perspective, if you're using open-source software, you could conceivably not care for the vendor that went away. You could find another life for it.

+ +

But years have gone by and that's not actually a truism that when you are using open-source software if you're getting it from a vendor, you're not necessarily protected from that vendor making decisions for you. CentOS is a great...the whole we're about to hit the CentOS deadlines, which is the Streams, and you can't get other versions. And we now have three versions of CentOS, at least three versions of CentOS with Rocky, and Alma, and CentOs Streams. Those are very challenging decisions for people running enterprise data centers, not that simple.

+ +

And nobody in our communities is running charity data centers. There's no goodwill charity. I'm running a data center out of the goodness of my heart. [laughs] They are all production systems, enterprise. They're doing real production work. And that's a commercial engagement. It's not a feel-good thing.

+ +

CHAD: So what did you do in your decision-making process? What pushed you, or what did you come to terms with in order to make that change?

+ +

ROB: I had to admit I was wrong. [laughter] I had to think back on statements I'd made and the enthusiasm that I'd had and give up some really hard beliefs. Being a CEO or a founder is the same process. So I wish I could say this was the only time [laughs] I had to question, you know, hard-made assumptions, or some core beliefs in what I thought.

+ +

I've had to get really good at questioning when am I projecting this is the way I want the world to be therefore it will be? That's a CEO skill set and a founder skill set...and when that projection is having you on thin ice. And so you constantly have to make that balance.

+ +

And this was one of those ones where I'm like, all right, let's do it. And I still wake up some mornings and look at people who are open source only and see how much press they get or how easy it is for them to get mentions and things like that. And I'm like, ah, God, that'd be great. It feels like it's much harder for us because we're commercial to get the amplification.

+ +

There are conferences that will amplify open-source TerraForm, great example. It gets tons of amplification for being a single vendor project that's really tightly controlled by HashiCorp. But nobody is afraid to go talk about TerraForm and mention TerraForm and do all this stuff, the amazing use of open source by that company. But they could turn it and twist it, and they could change it. It's not a guarantee by any stretch of the imagination.

+ +

CHAD: Well, one of the things that I've come to terms with, and maybe this is a very positive way of looking at it, instead of that you were wrong, [laughter] is to realize that well, you weren't necessarily wrong. It got you to where you were at that point. But maybe in order to go to the next level, you need to do something different. And that's how I come to terms with some things where I need to change my thinking.

+ +

ROB: [laughs] I like that. It's good. Sometimes you can look back and be like, yeah, that wasn't the right thing and just own it. But yeah, it does help you to know the path. Part of the reason why I love talking about it with you like this is it's not just Rob was wrong; we're actually walking the path through that decision. And it's easy to imagine us sitting in...we're in a tiny, little shared office listening to calls where...I'll tell you this as a story to make it incredibly concrete because it's exactly how this happened.

+ +

We were on a call. Everybody was in the room. And we were talking to a major bank saying, "We love your software." We're like, "Great, we're looking forward to working with you," all this stuff. And they're like, "Yeah, we need you to show us how you built this plugin because we want to write our own version of it."

+ +

CHAD: [chuckles]

+ +

ROB: We're like, "If you did that, you wouldn't need to buy our software." And they're like, "That's right. We're not going to buy your software."

+ +

CHAD: Exactly. [laughs]

+ +

ROB: And we're like, "Well, we won't show you how to use it. Then we won't show you how to do that." And they're like, "Well, okay. We'll figure it out ourselves." And so I'm the cheerful, sunny, positive, sort of managing the call, and I'm not just yelling at them. My CTO is sitting next to me literally tearing his hair. This was literally a tearing his hair out moment. And we hung up the call, and we went on a walk around the neighborhood. And he was just like, "What more do you need to hear for you to understand?"

+ +

And so it's moments like that. But instead of being like, no, you're wrong, we got to do it this way, I was ready to say, "Okay, what do you think we can do? How do we think we can do it?" And then he left me with a big pile of PR messaging to explain what we're doing, conversations like this. Two years ago when we made this change, almost three, I felt like I was being handed a really hard challenge.

+ +

As it turns out, it hasn't been as big a deal. The market has changed about how they perceive open source. And for enterprise customers, they're like, "All right, how do we deal with the licensing for this stuff?" And we're like, "You just buy it from us." And they're like, "That's it?" And I'm like, "Yes." And you guarantee every..." "Yes." They're like, "Oh. Well, that's pretty straightforward. I don't have to worry about..."

+ +

We could go way down an open-source rabbit hole and the consulting pieces and who owns the IP, and I used to deal with all that stuff. Now it's very straightforward. [laughs] Like, "You want to buy and use the software to run your data center?" "Yes, I do." "Great."

+ +

CHAD: Well, I think this is generally applicable even beyond your specific product but to products in general. It's like, when you're not talking to people who are good customers or who are even going to be your customers who are going to pay for what you want, you can spend a lot of time and energy trying to please them. But you're not going to be successful because they're not going to be your customers no matter what you do.

+ +

ROB: And that ends up being a bit of a filter with the open-source pieces is that there are customers who were dyed in the wool open source. And this used to be more true actually as the markets moved a lot. We ended up just not talking to many. But they do, they want a lot. They definitely would ask for features or things and additions and help, things like that. And it's hard to say no. Especially as a startup founder, you want to say yes a lot.

+ +

We try to not say yes to things that we don't...and this puts us at a disadvantage I feel like from a marketing perspective. If we don't do something, we tend to say we don't do it, or we could do it, but it would take whatever. I wish more people in the tech space were as disciplined about this does work, this doesn't work, this is a feature. This is something we're working on. It's not how tech marketing typically works sadly. That's why we focus on self-trials so people can use the product.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you have the core and then you have the ecosystem. And you also mentioned earlier that it is an actual software package that people are buying and installing in their data center. But then you have the UI which is in the cloud and what's in the data center is reporting up to that.

+ +

ROB: Well, this is where I'm going to get very technical [laughs] so hang on for a second. We actually use a cross-domain approach. So the way this works...and our UX is written in React. And everything's...boy, there's like three or four things I have to say all at once. So forgive me as I circle.

+ +

Everything we do at Digital Rebar is API-first, really API only, so the Golang service with an API, which is amazing. It's the right way to do software. So for our UX, it is a React application that can talk to that what we call an endpoint, that Digital Rebar endpoint. And so the UX is designed to talk directly to the Digital Rebar endpoint, and all of the information that it gets comes from that Digital Rebar endpoint. We do not have to relay it. Like, you have to be inside that network to get access to that endpoint. And the UX just talks to it.

+ +

CHAD: Okay. And so the UX is just being served from your centralized servers, but you're just delivering the React for the JavaScript app. And that is talking to the local APIs.

+ +

ROB: Right. And so we do use that browser as a bridge. And so when you want to download new content packs...so Digital Rebar is a platform. So you have to download content and automation and pieces into it. The browser is actually your bridge to do that. So the browser can connect to our catalog, pull down our catalog, and then send things into that browser. So it's super handy for that.

+ +

But yeah, it's fundamentally...it's all behind your firewall software except...and this is where people get confused because you're downloading it from rackn.io. That download or the URL on the browser looks like it's a RackN URL even though all the traffic is network local.

+ +

CHAD: Do your customers tend to stay up to date? Are they updating to the latest version right away all the time?

+ +

ROB: [laughs] No, of course not.

+ +

CHAD: I figured that was the answer.

+ +

ROB: And we maintain patches on old versions and things like that. I wish they were a little faster. I'm not always sad that they're...I'm actually very glad when we do a release like we did yesterday...And in that release, I don't expect any of our production customers to go patch everything.

+ +

So in a SaaS, you might actually have to deal with the fact that you've got...and we're back to our heterogeneity story. And this is why it's important that we don't do this. If we were to push that, if we didn't handle every situation for every customer exactly right, there would be chaos. And it would all come back to our team. The way we do it means that we don't have to deal with that. Customers are in control of when they upgrade and when they migrate, except in the UX case.

+ +

CHAD: So how do you manage that if someone goes to the UI and their local thing is an old version? Are you detecting that and doing things differently?

+ +

ROB: Yes, one of the decisions we made that I'm really happy with is we embedded feature flags into the API. When you log in, it will pull back. We know what the versions are. But versions are really problematic as a way to determine what's in software, not what's not in software. So instead, we get an array back that has feature flags as we add features into the core. And we've been doing this for years. And it's an amazingly productive process.

+ +

And so what the UX does is as we add new things into the UX, it will look for those feature flags. And if the feature flag isn't there, it will show you a message that says, "This feature is not available for your endpoint," or show you the thing appropriate without that. And so the UX has gone through years of this process. And so there are literally just places where the UX changes behavior based on what you've installed on your system.

+ +

And remember, our customers it's multi-site. So our customers do have multiple versions of Digital Rebar installed across there. So this behavior is really important also for them to be able to do it. And it goes back to LaunchDarkly. I was talking to Edith back in the early days of LaunchDarkly and feature flags, and I got really excited about that. And that's why we embedded it into the product. Everybody should do it. It's amazing.

+ +

CHAD: One of the previous episodes a few ago was with actually the thoughtbot CTO, Joe Ferris. And we're on a project together where it's a different way of working but especially when you need it... so much of what I had done previously was versioned APIs. Maybe that works at a certain scale. But you get to a certain scale of software and way of working and wanting to do continuous deployment and continually update features and all that stuff. And it's a really good way of working when instead you are communicating on the level of feature availability.

+ +

ROB: And from an ops person's perspective, and this was true with OpenStack, they were adding feature flags down at the metadata for the...it was incredible. They went deep into the versioned API hellscape. It's the only way I can describe it [laughs] because we don't do that. But the thing that that does not help you with is a lot of times the changes that you're looking at from an API perspective are behavior changes, not API changes. Our API over years now has been additive.

+ +

And as long as you're okay with new objects showing up, new fields showing up in an object, you could go back to four-year-old software, talk to our API, and it would still work just fine. So all your integrations are going to be good, but the behavior might change. And that's what people don't...they're like, oh, I can make my API version, and everything's good. But the behavior that you're putting behind the scenes might be different. You need a way to express that even more than the APIs in my opinion.

+ +

CHAD: I do think you really see that when you...if you're just building a monolithic web app, it's harder to see. But once you separate your UI from your back end...and where I first hit this was with mobile applications. The problem becomes more obvious to you as a developer I think.

+ +

ROB: Yes.

+ +

CHAD: Because you have some people out there who are actually running different versions of your UI too. So your back end is the same for everybody but your UI is different.

+ +

ROB: [laughs]

+ +

CHAD: And so you need a back end that can respond to different clients. And a better way to do that rather than versioning your API is to have the clients tell you what they're capable of while they're making the requests and to respond differently. It's much more of a flexible way.

+ +

ROB: We do track what UX. We have customers who don't want to use that. They don't even want us changing the UX...or actually normal enterprise. And so they will run...the nice thing about a React app is you can just run it. The Digital Rebar can host its UX, and that's perfectly reasonable. We have customers who do that.

+ +

But every core adds more operational complexity. And then if they don't patch the UX, they can fall behind or not get features. So we see that it's...you're describing a real, you know, the more information you're exchanging between the clients and the servers, the better for you to track what's really going on.

+ +

CHAD: And I think overall once you can get a little...in my experience, especially people who haven't worked that way, joining the team, it can take a little bit for them to get comfortable with that approach and the flexibility you need to be building into your system. But once people are comfortable with it and the team is comfortable, it really starts to hum.

+ +

In my experience, a lot of what we've advocated for in terms of the way software should be built and deployed and that kind of thing is it actually makes it so that you can leave that even easier. And you can really be agile because you can roll things out in a very agile way.

+ +

ROB: So are you thinking like an actual rolling deployment where the deployed software has multiple versions coming through?

+ +

CHAD: Yep. And you can also have different users seeing different things at different times as well. You can say, "We're going to be doing continual deployment and have code continually deployed." But that doesn't mean that it's part of the release yet, that it's available to users to use.

+ +

ROB: Yeah, that ability to split and feature flag is a huge deal.

+ +

CHAD: Yeah. What I'm trying to figure out is does this apply to every project even the small like, this just changes the way you should build software? Or is there a time in a product to start introducing that thing?

+ +

ROB: I am a big fan of doing it first and fast. There are decisions that we made early that have proven out really well. Feature flags is one of them. We started right away knowing that this would be an important thing for us to do. And same thing with tracking dependencies and being able to say, "I need..." actually, it's helpful because you can write automation that says, "I need this feature in the product." This flag and the product it's not just a version thing. That makes the automation a little bit more portable, easier to maintain.

+ +

The other thing we did that I really like is all of our objects have documentation embedded in them. So as I write a parameter or an ask or really anything in the system, everything has a documentation field. And so I can write the documentation for that component right there. And then we modified our build scripts so that they will pull in all of that documentation and create an aggregated view. And so the ability to do just-in-time documentation is very, very high. And so I'm a huge fan of that.

+ +

Because then you have the burden of like, oh, I need to go back and write up a whole bunch of documentation really lessened when you can be like, okay, for this parameter, I can explain its behavior, or I can tell you what it does and know that it's going to show up as part of a documentation set that explains it. That's been something I've been a big fan of in what we build.

+ +

And not everybody [laughs] is as much a fan. And you can see people writing stuff without particularly crisp documentation behind it. But at least we can go back and add that documentation or lessons learned or things like that. And it's been hugely helpful to have a place to do that.

+ +

From a design perspective, one other thing I would say that we did that...and you can imagine the conversation. I have a UX usability focus. I'm out selling the product. So for me, it's how does it demo? How does it show? What's that first experience like? And so for me having icons and colors in the UX, in the experience is really important. Because there's a lot of semantic meaning that people get just looking down a list of icons and seeing that they are different colors and different shapes.

+ +

But from the CTO's perspective, that's window dressing. Who cares? It doesn't have functional purpose. And we're both right. There's a lot of times when to me, both people can be right. So we added that as a metafield into all of our objects. And so we have the functional part of the definition of the API. And then we have these metaobjects that you can add in or meta definitions that you can add in behind the scenes to drive icons and colors.

+ +

But sometimes UX rendering hints and things like that that from an API perspective, you're like, I don't care, not really an API thing. But from a do I show...this is sensitive information. Do I turn it into a password field? Or should this have a clipboard so I can clipboard icon it, or should I render it in this type of viewer or a plain text viewer? And all that stuff we have a place for.

+ +

CHAD: And so it's actually being delivered by the API that's saying that.

+ +

ROB: Correct.

+ +

CHAD: That's cool.

+ +

ROB: It's been very helpful. You can imagine the type of stuff we have, and it's easy to influence UX behaviors without asking for UI change.

+ +

CHAD: Now, are these GraphQL APIs?

+ +

ROB: No. We looked at doing that. That's probably a whole nother...I might get our CTO on the line for that.

+ +

CHAD: [laughs] It's a whole nother episode for that.

+ +

ROB: But we could do that. But we made some decisions that it wasn't going to provide a lot of lift for us in navigation at the moment. It's funny, there's stuff that we think is a really cool idea, but we've learned not to jump on them without having really specific customer use cases or validations.

+ +

CHAD: Well, like you said, you've got to say no. You've got to make decisions about what is important, and what isn't important now, and what you'll get to later, and that requires discipline.

+ +

ROB: This may be a way to bring it full circle. If you go back to the stories of every customer having a unique data center, there’s this heterogeneity and multi-vendor pieces that are really important. The unicycle we have to ride for this is we want our customers to have standard operating processes, standard infrastructure pipelines for this and use those and follow that process.

+ +

Because we know if they do, then they'll keep improving as we improve the pipelines. And they're all unique. So there has to be a way in those infrastructure pipelines to do extensions that allow somebody to say, "I need to make this call here in the middle of this pipeline." And we have ways to do that address those needs.

+ +

The challenge becomes providing enough opinionated like, this is how you should do things. And it's okay if you have to extend it or change it a little bit or tweak it without it just becoming an open-ended tool where people show up and they're like, "Oh, yeah, I get how to build something." And we have people do this, but they run out of gas in the long journey.

+ +

They end up writing bespoke workflows. They write their own pipelines; they do their own integrations. And for them, it's very hard to support them. It's very hard to upgrade them. It's very hard for them to survive the reorg, your nine-month reorg windows.

+ +

And so yeah, there's a balance between go do whatever you want, which you have to enable and do it our way because these processes are going to let your teams collaborate, let you reuse software. And we've actually over time been erring more and more on the side of you really need to do it the way we want you to do; reinforce the infrastructure as code processes.

+ +

And this is the key, right? I mean, you're coming from a development mindset. You want your tooling to reinforce good behavior, CICD, infrastructure as code, all these things. You need those to be easier to do [laughs] than writing it yourself. And over time, we've been progressing more and more towards the let's make it easier to do it within the opinionated way that we have and less easy to do it within the Wild West pattern.

+ +

CHAD: Cool. Well, I think with that, we'll start to wrap up. So if people want to find out more, where are some places that they could do that or get in touch with you?

+ +

ROB: The simplest thing is of course rackn.com is the website. We encourage people to just, if this is interesting, download and try the software. If they have a cloud account, it's super easy to play with it, all things RackN through that.

+ +

I am very active on Twitter under the handle @zehicle Z-E-H-I-C-L-E. And I'm happy to have conversations around these topics and data center and operations and even the future of cloud and edge computing. So please look me up. I'm excited to have conversations like that.

+ +

CHAD: Awesome. And you can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to Rob Hirschfeld, the Founder and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. RackN is focused on helping customers automate infrastructure. They focus on customer autonomy and self-management, and that's why they're a software company, not a services or as-a-service platform company.

+ +

Digital Rebar is a platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Rob Hirschfeld, Founder, and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. Rob, welcome to the show

+ +

ROB: Chad, it is a pleasure to be here. Looking forward to the conversation.

+ +

CHAD: Why don't we start with a little bit more information about what RackN and the Digital Rebar platform actually is.

+ +

ROB: I would be happy to. RackN is focused on helping customers automate infrastructure. And for us, it's really important that the customers are doing the automation. We're very focused on customer autonomy and self-management. It's why we're a software company, not a services or as a service platform company.

+ +

But fundamentally, what Digital Rebar does is it is the platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. And we were talking data centers do a lot of on-premises all the way from the bare metal up. But multi-cloud, you name it, we're doing infrastructure at that level.

+ +

CHAD: So, how agnostic to the actual bare metal are you?

+ +

ROB: We're very agnostic to the bare metal. The way we look at it is data centers are heterogeneous, diverse places. And that the thing that sometimes blocks companies from being innovative is when they decide, oh, we're going to use this one vendor for this one platform. And that keeps them actually from moving forward. So when we look at data centers, the heterogeneity and sometimes the complexity of that environment is a feature. It's not a bug from that perspective.

+ +

And so it's always been important to us to be multi-vendor, to do things in a vendor-neutral way to accommodate the quirks and the differences between...and it's not just vendors; it's actually user choice. A lot of companies have a multi-vendor problem (I'm air quoting) that is actually a multi-team problem where teams have chosen to make different choices.

+ +

TerraForm has no conformance standard built into it. [laughs] And so you might have everybody in your company using TerraForm and Ansible happily but all differently. And that's the problem that we walk into when we walk into a data center challenge. And you can't sweep that under the rug. So we embraced it.

+ +

CHAD: What kind of companies are your primary customers?

+ +

ROB: We're very wide-ranging, from the top banks use us and deploy us, telcos, service providers, very large scale service providers use us under the covers, media companies. It really runs the gamut because it's fundamentally for us just about infrastructure. And our largest customers are racing to be the first to deploy. And it's multi-site, but 20,000 machines that they're managing under our Digital Rebar management system.

+ +

CHAD: It's easy, I think, depending on where you sit and your experiences. The cloud providers today can overshadow the idea that there are even people who still have their own data centers or rent a portion of a data center. In today's ecosystem, what are some of the factors that cause someone to do that who isn't an infrastructure provider themselves?

+ +

ROB: You know the funny thing about these cloud stories (And we're talking just the day after Amazon had a day-long outage.) is that even the cloud providers don't have you give up operation. You're still responsible for the ops. And for our customers, it's not like they can all just use Lambdas and API gateways. At the end of the day, they're actually doing multi-site distributed operations. And they have these estates that are actually it's more about how do I control distributed infrastructure as much as it is about repatriating.

+ +

Now, we do a lot to help people repatriate. And they do that because they want more control. Cost savings is a significant component with this. You get into the 1000s of machines, and that's a big deal. Even at hundreds of machines, you can save a lot of money compared to what you get in cloud.

+ +

And I think people get confused with it being an or choice. It really is an and choice. Our best customers are incredibly savvy cloud users. They want that dynamic, resilient very API-driven environment. And they're looking to bring that throughout the organization. And so those are the ones that get excited when they see what we've done because we spend a lot of time doing infrastructure as code and API-driven infrastructure. That's really what they want.

+ +

CHAD: Cool. So, how long have you been working on RackN? When did you found it?

+ +

ROB: [laughs] Oh my goodness. So RackN is seven years old. Digital Rebar, we consider it to be at its fourth generation, but those numbers actually count back before that. They go back to 2009. The founding team was actually at Dell together in the OpenStack heyday and even before the OpenStack heyday. And we were trying to ship clouds from the Dell Factory.

+ +

And what we found was that every customer had this bespoke data center we've already talked about. And we couldn't write automation that would work customer to customer to customer. And it was driving us nuts. We're a software team, not a hardware team inside of Dell. And the idea that if I fixed something in the delivery or in their data center, and couldn't go back to their data center because it was different than what the next customer needed and the next customer needed, we knew that we would never have a community. It's very much about this community and reuse pattern.

+ +

There's an interesting story that I picked up from SREcon actually where they were talking about the early days of boilers. This is going back a few centuries ago. But when they first started putting boilers into homes and buildings, there was no pattern, there was no standard. And everybody would basically hire a plumber or a heating architect. Heating architect was a thing.

+ +

But you'd build a boiler and every one was custom, and every one was different. And no surprise, they blew up a lot, and they caused fires. And buildings were incredibly unsafe because they were working on high-pressure systems with no pattern. And it took regulation and laws and standards. And now nobody even thinks about it. You just take standard parts, and you connect them together in standard ways. And that creates actually a much more innovative system. You wouldn't want every house to be wired uniquely either.

+ +

And so when we look at the state of automation today, we see it as this pre-industrial pre-standardization process and that companies are actually harmed and harming themselves because they don't have standards, and patterns, and practices that they can just roll and know they work.

+ +

And so that philosophy started way back in 2009 with the first generation which was called Crowbar. Some of your audience might even remember this from the OpenStack days. It was the first OpenStack installer built around Chef. And it had all sorts of challenges in it, but it showed us the way. And then we iterated up to where Digital Rebar is today. Really fully infrastructure as code, building infrastructure pipelines, and a lot of philosophical pieces we've learned along the way.

+ +

CHAD: So you were at Dell working on this thing. How did you decide to leave Dell and start something new?

+ +

ROB: Dell helped me with that decision. [laughs] So the challenge of being a software person inside of Dell especially at the time, Crowbar was open-source which did make it easier for us to say, "Hey, we want to part ways but keep the IP." And the funny thing is there's not a scrap of Crowbar in Digital Rebar except one or two naming conventions that we pulled forward and the nod of the name, that Rebar is a nod to Crowbar.

+ +

But what happened was Dell when it went private, really did actually double down on the hardware and the more enterprise packaged things. They didn't want to invest in DevOps and that conversation that you need to have with your customers on how they operate, the infrastructure you sold them. And that made Dell not a very good place for me and the team. And so we left Dell, looked at the opportunity to take what we'd been building with Crowbar and then make it into a product. That's been a long journey.

+ +

CHAD: Now, did you bootstrap, or did you take investment?

+ +

ROB: We took [laughs] a little bit of investment. We raised some seed funding. Certainly not what was in hindsight was going to be sufficient for us to do it. But we thought at the time that we had something that was much more product-ready for customers than it was.

+ +

CHAD: And what was the challenge that you found? What was the surprise there that it wasn't as ready as you thought?

+ +

ROB: So what we've learned in our space specifically...and there are some things that I think apply to everybody, and there are some things that you might be able to throw on the floor and ignore. I was a big fan of Minimum Viable Product. And it turned out that the MVP strategy was not at all workable with customers in data centers.

+ +

Our product is for people running production data centers. And nobody's going to put in software to run a data center that is MVP. It has to be resilient. It has to be robust. It has to be simple enough that they can understand it and solve some core problems, which is still sort of an MVP idea. But it can't be oops. [laughs] You can't have a lot of oops moments when you're dealing with enterprise infrastructure automation software. It has to work.

+ +

And importantly, and as a design note, this has been a lesson for us. If it does break, it has to break in very transparent, obvious ways. And I can't emphasize that enough. There's so much that when we build it, we come back and like, was it obvious that it broke? Is it obvious that it broke in a way that you can fix?

+ +

CHAD: And it's part of the culture too to do detailed post mortems with explanations and be as transparent as possible or at least find the root cause so that you can address it. That's part of the culture of the space too, right?

+ +

ROB: You'd like to hope so. [laughs]

+ +

CHAD: Okay. [laughs] In my experience, that's the culture of the space.

+ +

ROB: You're looking more at a developer experience. But even with a developer, you've got to be in a post mortem or something. And it's like everybody's pointing to the person to the left and the right sort of by human nature. You don't walk into that room assuming that it was your fault, and you should, but that's not how it usually is approached.

+ +

And what we find in the ops space, and I would tell people to work around this pattern if they can, is that if you're the thing doing the automation, you're always the first cause of the problem. So we run into situations where we're doing a configuration, and we find a vendor bug or a glitch or there's something, and we found it. It's our problem whether we were the cause or not. And that's super hard.

+ +

I think that people on every side of any type of issue need to look through and figure out what the...the blameless post mortem is a really important piece in all this. At the end of the day, it's always a human system that made a mistake or has something like that. But it's not as simple as the thing that told you the bad news that the messenger was at fault.

+ +

And there's a system design element to that. That's what we're talking about here is that when you're exposing errors or when something's not behaving the way you expect, our philosophy is to stop. And we've had some very contentious arguments with customers who were like, "Just retry until it fixes itself," or vendors who were like, "Yeah, if you retry that thing three times, [laughs] then it'll magically go away." And we're like, that's not good behavior. Fix the problem. It actually took us years to put a retry element into the tasks so that you can say, yeah, this does need three retries. Just go do it. We've resisted for a long time for this reason.

+ +

CHAD: So you head out into the market. And did you get initial customers, or was there so much resistance to the product that you had that you struggled to get even first customers?

+ +

ROB: We had first customers. We had a nice body of code. The problem is actually pretty well understood even by our customers. And so it wasn't hard for them to get a trial going. So we actually had a very profitable customer doing...it was in object storage, public object storage space. And they were installing us. They wanted to move us into all their data centers.

+ +

But for it to work, we ended up having an engineer who basically did consulting and worked with them for the better part of six months and built a whole bunch of stuff, got it working. They could plug in servers, and everything would set itself up. And they could hit a button and reset all the servers, and they would talk to the switches. It was an amazing amount of automation.

+ +

But, and this happens a lot, the person we'd been working with was an SRE. And when they went to turn it over to the admins in the ops team, they said, [laughs] "We can't operate. There's too much going on, too complex." And we'd actually recognized...and this is a really serious challenge. It's a challenge now that we're almost five years into the generation that came after that experience.

+ +

And we recognized there was a problem. And that this wasn't going to create that repeatable experience that we were looking for if it took that much. At the same time, we had been building what is now Digital Rebar in this generation that was a single Golang binary. All the services were bundled into the system. So it listened on different ports but provide all the services, very easy to install, really, really simple. We literally stripped everything back to the basics and restarted.

+ +

And we had this experience where we sat down with a customer who had...I'm going to take a second and tell the story because this is such a compelling story from a product experience. So we took our first product. We were in a bake-off with another bare metal focus provisioning at the time. And they were in a lab, and they set our stuff up. And they turned it on, and they provisioned. And they set up the competitor, and they turned it on and provisioned. And both products worked.

+ +

Our product took 20 minutes to go through the cycle and the competitor took 3. And the customer came back and said, "I can't use this. I like your product better. It has more controls with all this stuff." But it took 20 minutes instead of 3. We actually logged into the system, looked at it and we were like, "Well, that's because it recognized that your BIOS was out of date, patched your BIOS, updated the system, checked that it was right, and then rebooted the systems and then continued on its way because it recognized your systems were outdated automatically.

+ +

And he said, "I didn't want it to do that. I needed it to boot as quickly as possible." And literally, [laughs] we were in the middle of a team retreat. So it's like, the CTO is literally excusing himself on the table to talk to the guy to make this stuff, try and make it right. And he's like, "Well, we've got this new thing. Why don't you install this, what's now Digital Rebar, on the system and repeat the experiment?" And he did and Digital Rebar was even faster than the competitor. And it did exactly just install, booted, and was done.

+ +

And he came back to the table, and it took 15 minutes to have the whole conversation to make everything work. It was that much of a simpler design. And he sat down and told the story. And I was in the middle of it. I'm just like, "We're going to have to pivot and put everything into the new version," which is what we did. And we just ripped out the complexity. And then over the last couple of years now, we've built the complexity back into the system to do all those additional but much more customer-driven from that perspective.

+ +

CHAD: How did you make sure that as you were changing your focus, putting all of your energy into the new version that you [laughs] didn't introduce too much risk in that process or didn't take too long?

+ +

ROB: [laughs] We did take too long and introduced too much risk, and we did run out of money. [laughs] All those things happened. This was a very difficult decision. We thought we could get it done much faster. The challenge of the simpler product was that it was too simple to be enough in customers’ data centers. And so yeah, we almost went out of business in the middle of all this cycle. We had a time where RackN went back down to just the two founders.

+ +

And at this point, we'd gotten far enough with the product that we knew it was the right thing. And we'd also embedded a degree...with the way we do the UX, we have this split. The UX runs on a hosted system. It doesn't have to but by default, it does. And then we have the back end. So we were very careful about how we collected metrics because you really need to know who's downloading and using your products.

+ +

And we had enough data from that to realize that we had some very committed early users and early customers, just huge brand names that were playing around. So we knew that we'd gotten this mix right, that we were solving a problem in a unique way. But it was going to take time because big companies don't make decisions quickly. We have a joke. We call it the reorg half-life problem. So the half-life of a reorg in any of our customers is about nine months. And either you're successful inside of that reorg half-life, or you have to be resilient across this reorg half.

+ +

And so initially, it was taking more than nine months. We had to be able to get the product in play. And once we did, we had some customers who came in with very big checks and let us come back and basically build back up. And we've been adding some really nice names into our customer roster. Unfortunately, it's all private. I can tell you their industries and their scale, but I can't name them.

+ +

But that engagement helped drive us towards the feature set and the capabilities and building things up along that process. But it was frustrating. And some of them, especially at the time we were open-source, were very happy to say, "No, we are a super big brand name. We don't pay for software." I'm like, "Most profitable, highest valued companies in the world you don't want to pay for this operational software?" And they're like, "No, we don't have to." And that didn't sit very well with us. Very hard, as a starting startup, it was hard.

+ +

CHAD: At the time, everything you were doing was open source.

+ +

ROB: So in the Digital Rebar era, we were trying to do Open Core. Digital Rebar itself was open. And then we were trying to hold back the BIOS patches, integrate enterprise single sign-on. So there was a degree of integration pieces that we held back as RackN and then left the core open. So you could use Digital Rebar and run it, which we had actually had a lot of success with people downloading, installing, and running Digital Rebar, not as much success in getting them to pay us for that privilege.

+ +

CHAD: So, how did you adjust to that reality?

+ +

ROB: We inverted the license. After we landed a couple of big banks and we had several others and some hyperscalers too who were like, "This is really good software. We love it. We're embedding it in our service, but we're not going to pay you." And then they would show up with bugs and complaints and issues and all sorts of stuff still.

+ +

And what happened is we started seeing them replicating the closed pieces. The APIs were open. We actually looked at it and listening to our communities, they wanted to see what was in the closed pieces. That was actually operationally important for them to understand how that stuff worked. They never contributed or asked to see anything in the core. And, there's an important and here, and they needed performance improvements in the core that were radically different.

+ +

So the original open-source stuff went to maybe 500 machines, and then it started to cap out. And we were like, all right, we're going to have to really rewrite the data store mechanisms that go with this. And the team looked at each other and were like, "We're not going to open source that. That's really complex and challenging IP." And so we said the right model for us is going to be to make the core closed and then allow our community and users to see all the things that they are actually using to interact with their environment. And it ends up being a little bit of a filter.

+ +

There are people who only use open-source software. But those companies also don't necessarily want to pay. When I was an open-source evangelist, this was always a problem. You're pounding on the table saying, "If you're using open-source software, you need to understand who to pay for that service, that software that you're getting. If you're not paying for it, that software is going to go away." In a lot of cases, we're a walking example of that.

+ +

And it's funny, more of the codebase is open today than it was then. [chuckles] But the challenge is that it's really an open ecosystem now because none of that software is particularly useful without the core to run it and glue everything together.

+ +

CHAD: Was that a difficult decision to make? Was it controversial?

+ +

ROB: Incredibly difficult. It was something I spent a lot of time agonizing about. My CTO is much clear-eyed on this. From his perspective, he and the other engineers are blood, sweat, and tears putting this in. And it was very frustrating for them to see it running people's production data centers who told us, and this is I think the key, who just said to us, "You know, we're not going to pay money for that." And so for them, it was very clear-eyed it's their work, their sweat equity, very gut feeling for that.

+ +

For me, I watched communities with open-source routes, you know, the Kubernetes community. I was in OpenStack. I was on the board for that. And there is definitely a lift that you get from having free software and not having the strings. And I also like the idea that from a support perspective, if you're using open-source software, you could conceivably not care for the vendor that went away. You could find another life for it.

+ +

But years have gone by and that's not actually a truism that when you are using open-source software if you're getting it from a vendor, you're not necessarily protected from that vendor making decisions for you. CentOS is a great...the whole we're about to hit the CentOS deadlines, which is the Streams, and you can't get other versions. And we now have three versions of CentOS, at least three versions of CentOS with Rocky, and Alma, and CentOs Streams. Those are very challenging decisions for people running enterprise data centers, not that simple.

+ +

And nobody in our communities is running charity data centers. There's no goodwill charity. I'm running a data center out of the goodness of my heart. [laughs] They are all production systems, enterprise. They're doing real production work. And that's a commercial engagement. It's not a feel-good thing.

+ +

CHAD: So what did you do in your decision-making process? What pushed you, or what did you come to terms with in order to make that change?

+ +

ROB: I had to admit I was wrong. [laughter] I had to think back on statements I'd made and the enthusiasm that I'd had and give up some really hard beliefs. Being a CEO or a founder is the same process. So I wish I could say this was the only time [laughs] I had to question, you know, hard-made assumptions, or some core beliefs in what I thought.

+ +

I've had to get really good at questioning when am I projecting this is the way I want the world to be therefore it will be? That's a CEO skill set and a founder skill set...and when that projection is having you on thin ice. And so you constantly have to make that balance.

+ +

And this was one of those ones where I'm like, all right, let's do it. And I still wake up some mornings and look at people who are open source only and see how much press they get or how easy it is for them to get mentions and things like that. And I'm like, ah, God, that'd be great. It feels like it's much harder for us because we're commercial to get the amplification.

+ +

There are conferences that will amplify open-source TerraForm, great example. It gets tons of amplification for being a single vendor project that's really tightly controlled by HashiCorp. But nobody is afraid to go talk about TerraForm and mention TerraForm and do all this stuff, the amazing use of open source by that company. But they could turn it and twist it, and they could change it. It's not a guarantee by any stretch of the imagination.

+ +

CHAD: Well, one of the things that I've come to terms with, and maybe this is a very positive way of looking at it, instead of that you were wrong, [laughter] is to realize that well, you weren't necessarily wrong. It got you to where you were at that point. But maybe in order to go to the next level, you need to do something different. And that's how I come to terms with some things where I need to change my thinking.

+ +

ROB: [laughs] I like that. It's good. Sometimes you can look back and be like, yeah, that wasn't the right thing and just own it. But yeah, it does help you to know the path. Part of the reason why I love talking about it with you like this is it's not just Rob was wrong; we're actually walking the path through that decision. And it's easy to imagine us sitting in...we're in a tiny, little shared office listening to calls where...I'll tell you this as a story to make it incredibly concrete because it's exactly how this happened.

+ +

We were on a call. Everybody was in the room. And we were talking to a major bank saying, "We love your software." We're like, "Great, we're looking forward to working with you," all this stuff. And they're like, "Yeah, we need you to show us how you built this plugin because we want to write our own version of it."

+ +

CHAD: [chuckles]

+ +

ROB: We're like, "If you did that, you wouldn't need to buy our software." And they're like, "That's right. We're not going to buy your software."

+ +

CHAD: Exactly. [laughs]

+ +

ROB: And we're like, "Well, we won't show you how to use it. Then we won't show you how to do that." And they're like, "Well, okay. We'll figure it out ourselves." And so I'm the cheerful, sunny, positive, sort of managing the call, and I'm not just yelling at them. My CTO is sitting next to me literally tearing his hair. This was literally a tearing his hair out moment. And we hung up the call, and we went on a walk around the neighborhood. And he was just like, "What more do you need to hear for you to understand?"

+ +

And so it's moments like that. But instead of being like, no, you're wrong, we got to do it this way, I was ready to say, "Okay, what do you think we can do? How do we think we can do it?" And then he left me with a big pile of PR messaging to explain what we're doing, conversations like this. Two years ago when we made this change, almost three, I felt like I was being handed a really hard challenge.

+ +

As it turns out, it hasn't been as big a deal. The market has changed about how they perceive open source. And for enterprise customers, they're like, "All right, how do we deal with the licensing for this stuff?" And we're like, "You just buy it from us." And they're like, "That's it?" And I'm like, "Yes." And you guarantee every..." "Yes." They're like, "Oh. Well, that's pretty straightforward. I don't have to worry about..."

+ +

We could go way down an open-source rabbit hole and the consulting pieces and who owns the IP, and I used to deal with all that stuff. Now it's very straightforward. [laughs] Like, "You want to buy and use the software to run your data center?" "Yes, I do." "Great."

+ +

CHAD: Well, I think this is generally applicable even beyond your specific product but to products in general. It's like, when you're not talking to people who are good customers or who are even going to be your customers who are going to pay for what you want, you can spend a lot of time and energy trying to please them. But you're not going to be successful because they're not going to be your customers no matter what you do.

+ +

ROB: And that ends up being a bit of a filter with the open-source pieces is that there are customers who were dyed in the wool open source. And this used to be more true actually as the markets moved a lot. We ended up just not talking to many. But they do, they want a lot. They definitely would ask for features or things and additions and help, things like that. And it's hard to say no. Especially as a startup founder, you want to say yes a lot.

+ +

We try to not say yes to things that we don't...and this puts us at a disadvantage I feel like from a marketing perspective. If we don't do something, we tend to say we don't do it, or we could do it, but it would take whatever. I wish more people in the tech space were as disciplined about this does work, this doesn't work, this is a feature. This is something we're working on. It's not how tech marketing typically works sadly. That's why we focus on self-trials so people can use the product.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So you have the core and then you have the ecosystem. And you also mentioned earlier that it is an actual software package that people are buying and installing in their data center. But then you have the UI which is in the cloud and what's in the data center is reporting up to that.

+ +

ROB: Well, this is where I'm going to get very technical [laughs] so hang on for a second. We actually use a cross-domain approach. So the way this works...and our UX is written in React. And everything's...boy, there's like three or four things I have to say all at once. So forgive me as I circle.

+ +

Everything we do at Digital Rebar is API-first, really API only, so the Golang service with an API, which is amazing. It's the right way to do software. So for our UX, it is a React application that can talk to that what we call an endpoint, that Digital Rebar endpoint. And so the UX is designed to talk directly to the Digital Rebar endpoint, and all of the information that it gets comes from that Digital Rebar endpoint. We do not have to relay it. Like, you have to be inside that network to get access to that endpoint. And the UX just talks to it.

+ +

CHAD: Okay. And so the UX is just being served from your centralized servers, but you're just delivering the React for the JavaScript app. And that is talking to the local APIs.

+ +

ROB: Right. And so we do use that browser as a bridge. And so when you want to download new content packs...so Digital Rebar is a platform. So you have to download content and automation and pieces into it. The browser is actually your bridge to do that. So the browser can connect to our catalog, pull down our catalog, and then send things into that browser. So it's super handy for that.

+ +

But yeah, it's fundamentally...it's all behind your firewall software except...and this is where people get confused because you're downloading it from rackn.io. That download or the URL on the browser looks like it's a RackN URL even though all the traffic is network local.

+ +

CHAD: Do your customers tend to stay up to date? Are they updating to the latest version right away all the time?

+ +

ROB: [laughs] No, of course not.

+ +

CHAD: I figured that was the answer.

+ +

ROB: And we maintain patches on old versions and things like that. I wish they were a little faster. I'm not always sad that they're...I'm actually very glad when we do a release like we did yesterday...And in that release, I don't expect any of our production customers to go patch everything.

+ +

So in a SaaS, you might actually have to deal with the fact that you've got...and we're back to our heterogeneity story. And this is why it's important that we don't do this. If we were to push that, if we didn't handle every situation for every customer exactly right, there would be chaos. And it would all come back to our team. The way we do it means that we don't have to deal with that. Customers are in control of when they upgrade and when they migrate, except in the UX case.

+ +

CHAD: So how do you manage that if someone goes to the UI and their local thing is an old version? Are you detecting that and doing things differently?

+ +

ROB: Yes, one of the decisions we made that I'm really happy with is we embedded feature flags into the API. When you log in, it will pull back. We know what the versions are. But versions are really problematic as a way to determine what's in software, not what's not in software. So instead, we get an array back that has feature flags as we add features into the core. And we've been doing this for years. And it's an amazingly productive process.

+ +

And so what the UX does is as we add new things into the UX, it will look for those feature flags. And if the feature flag isn't there, it will show you a message that says, "This feature is not available for your endpoint," or show you the thing appropriate without that. And so the UX has gone through years of this process. And so there are literally just places where the UX changes behavior based on what you've installed on your system.

+ +

And remember, our customers it's multi-site. So our customers do have multiple versions of Digital Rebar installed across there. So this behavior is really important also for them to be able to do it. And it goes back to LaunchDarkly. I was talking to Edith back in the early days of LaunchDarkly and feature flags, and I got really excited about that. And that's why we embedded it into the product. Everybody should do it. It's amazing.

+ +

CHAD: One of the previous episodes a few ago was with actually the thoughtbot CTO, Joe Ferris. And we're on a project together where it's a different way of working but especially when you need it... so much of what I had done previously was versioned APIs. Maybe that works at a certain scale. But you get to a certain scale of software and way of working and wanting to do continuous deployment and continually update features and all that stuff. And it's a really good way of working when instead you are communicating on the level of feature availability.

+ +

ROB: And from an ops person's perspective, and this was true with OpenStack, they were adding feature flags down at the metadata for the...it was incredible. They went deep into the versioned API hellscape. It's the only way I can describe it [laughs] because we don't do that. But the thing that that does not help you with is a lot of times the changes that you're looking at from an API perspective are behavior changes, not API changes. Our API over years now has been additive.

+ +

And as long as you're okay with new objects showing up, new fields showing up in an object, you could go back to four-year-old software, talk to our API, and it would still work just fine. So all your integrations are going to be good, but the behavior might change. And that's what people don't...they're like, oh, I can make my API version, and everything's good. But the behavior that you're putting behind the scenes might be different. You need a way to express that even more than the APIs in my opinion.

+ +

CHAD: I do think you really see that when you...if you're just building a monolithic web app, it's harder to see. But once you separate your UI from your back end...and where I first hit this was with mobile applications. The problem becomes more obvious to you as a developer I think.

+ +

ROB: Yes.

+ +

CHAD: Because you have some people out there who are actually running different versions of your UI too. So your back end is the same for everybody but your UI is different.

+ +

ROB: [laughs]

+ +

CHAD: And so you need a back end that can respond to different clients. And a better way to do that rather than versioning your API is to have the clients tell you what they're capable of while they're making the requests and to respond differently. It's much more of a flexible way.

+ +

ROB: We do track what UX. We have customers who don't want to use that. They don't even want us changing the UX...or actually normal enterprise. And so they will run...the nice thing about a React app is you can just run it. The Digital Rebar can host its UX, and that's perfectly reasonable. We have customers who do that.

+ +

But every core adds more operational complexity. And then if they don't patch the UX, they can fall behind or not get features. So we see that it's...you're describing a real, you know, the more information you're exchanging between the clients and the servers, the better for you to track what's really going on.

+ +

CHAD: And I think overall once you can get a little...in my experience, especially people who haven't worked that way, joining the team, it can take a little bit for them to get comfortable with that approach and the flexibility you need to be building into your system. But once people are comfortable with it and the team is comfortable, it really starts to hum.

+ +

In my experience, a lot of what we've advocated for in terms of the way software should be built and deployed and that kind of thing is it actually makes it so that you can leave that even easier. And you can really be agile because you can roll things out in a very agile way.

+ +

ROB: So are you thinking like an actual rolling deployment where the deployed software has multiple versions coming through?

+ +

CHAD: Yep. And you can also have different users seeing different things at different times as well. You can say, "We're going to be doing continual deployment and have code continually deployed." But that doesn't mean that it's part of the release yet, that it's available to users to use.

+ +

ROB: Yeah, that ability to split and feature flag is a huge deal.

+ +

CHAD: Yeah. What I'm trying to figure out is does this apply to every project even the small like, this just changes the way you should build software? Or is there a time in a product to start introducing that thing?

+ +

ROB: I am a big fan of doing it first and fast. There are decisions that we made early that have proven out really well. Feature flags is one of them. We started right away knowing that this would be an important thing for us to do. And same thing with tracking dependencies and being able to say, "I need..." actually, it's helpful because you can write automation that says, "I need this feature in the product." This flag and the product it's not just a version thing. That makes the automation a little bit more portable, easier to maintain.

+ +

The other thing we did that I really like is all of our objects have documentation embedded in them. So as I write a parameter or an ask or really anything in the system, everything has a documentation field. And so I can write the documentation for that component right there. And then we modified our build scripts so that they will pull in all of that documentation and create an aggregated view. And so the ability to do just-in-time documentation is very, very high. And so I'm a huge fan of that.

+ +

Because then you have the burden of like, oh, I need to go back and write up a whole bunch of documentation really lessened when you can be like, okay, for this parameter, I can explain its behavior, or I can tell you what it does and know that it's going to show up as part of a documentation set that explains it. That's been something I've been a big fan of in what we build.

+ +

And not everybody [laughs] is as much a fan. And you can see people writing stuff without particularly crisp documentation behind it. But at least we can go back and add that documentation or lessons learned or things like that. And it's been hugely helpful to have a place to do that.

+ +

From a design perspective, one other thing I would say that we did that...and you can imagine the conversation. I have a UX usability focus. I'm out selling the product. So for me, it's how does it demo? How does it show? What's that first experience like? And so for me having icons and colors in the UX, in the experience is really important. Because there's a lot of semantic meaning that people get just looking down a list of icons and seeing that they are different colors and different shapes.

+ +

But from the CTO's perspective, that's window dressing. Who cares? It doesn't have functional purpose. And we're both right. There's a lot of times when to me, both people can be right. So we added that as a metafield into all of our objects. And so we have the functional part of the definition of the API. And then we have these metaobjects that you can add in or meta definitions that you can add in behind the scenes to drive icons and colors.

+ +

But sometimes UX rendering hints and things like that that from an API perspective, you're like, I don't care, not really an API thing. But from a do I show...this is sensitive information. Do I turn it into a password field? Or should this have a clipboard so I can clipboard icon it, or should I render it in this type of viewer or a plain text viewer? And all that stuff we have a place for.

+ +

CHAD: And so it's actually being delivered by the API that's saying that.

+ +

ROB: Correct.

+ +

CHAD: That's cool.

+ +

ROB: It's been very helpful. You can imagine the type of stuff we have, and it's easy to influence UX behaviors without asking for UI change.

+ +

CHAD: Now, are these GraphQL APIs?

+ +

ROB: No. We looked at doing that. That's probably a whole nother...I might get our CTO on the line for that.

+ +

CHAD: [laughs] It's a whole nother episode for that.

+ +

ROB: But we could do that. But we made some decisions that it wasn't going to provide a lot of lift for us in navigation at the moment. It's funny, there's stuff that we think is a really cool idea, but we've learned not to jump on them without having really specific customer use cases or validations.

+ +

CHAD: Well, like you said, you've got to say no. You've got to make decisions about what is important, and what isn't important now, and what you'll get to later, and that requires discipline.

+ +

ROB: This may be a way to bring it full circle. If you go back to the stories of every customer having a unique data center, there’s this heterogeneity and multi-vendor pieces that are really important. The unicycle we have to ride for this is we want our customers to have standard operating processes, standard infrastructure pipelines for this and use those and follow that process.

+ +

Because we know if they do, then they'll keep improving as we improve the pipelines. And they're all unique. So there has to be a way in those infrastructure pipelines to do extensions that allow somebody to say, "I need to make this call here in the middle of this pipeline." And we have ways to do that address those needs.

+ +

The challenge becomes providing enough opinionated like, this is how you should do things. And it's okay if you have to extend it or change it a little bit or tweak it without it just becoming an open-ended tool where people show up and they're like, "Oh, yeah, I get how to build something." And we have people do this, but they run out of gas in the long journey.

+ +

They end up writing bespoke workflows. They write their own pipelines; they do their own integrations. And for them, it's very hard to support them. It's very hard to upgrade them. It's very hard for them to survive the reorg, your nine-month reorg windows.

+ +

And so yeah, there's a balance between go do whatever you want, which you have to enable and do it our way because these processes are going to let your teams collaborate, let you reuse software. And we've actually over time been erring more and more on the side of you really need to do it the way we want you to do; reinforce the infrastructure as code processes.

+ +

And this is the key, right? I mean, you're coming from a development mindset. You want your tooling to reinforce good behavior, CICD, infrastructure as code, all these things. You need those to be easier to do [laughs] than writing it yourself. And over time, we've been progressing more and more towards the let's make it easier to do it within the opinionated way that we have and less easy to do it within the Wild West pattern.

+ +

CHAD: Cool. Well, I think with that, we'll start to wrap up. So if people want to find out more, where are some places that they could do that or get in touch with you?

+ +

ROB: The simplest thing is of course rackn.com is the website. We encourage people to just, if this is interesting, download and try the software. If they have a cloud account, it's super easy to play with it, all things RackN through that.

+ +

I am very active on Twitter under the handle @zehicle Z-E-H-I-C-L-E. And I'm happy to have conversations around these topics and data center and operations and even the future of cloud and edge computing. So please look me up. I'm excited to have conversations like that.

+ +

CHAD: Awesome. And you can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+VWuAymHs + + ]]> + + Chad Pytel + + + 404: My Goat with Neil Amrhein and Matt Erickson + https://podcast.thoughtbot.com/404 + 090a2e3b-6fb6-4c6e-9ec8-c8289eaa9293 + Thu, 16 Dec 2021 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Neal Amrhein is the founder and CEO and Matt Erickson is the CTO of My Goat. My Goat is a subscription mowing service for commercial properties. They use robotic mowers and elegant software tools to make turf care easy, convenient, and affordable. + 42:17 + no + + + Neal Amrhein is the founder and CEO and Matt Erickson is the CTO of My Goat. My Goat is a subscription mowing service for commercial properties. They use robotic mowers and elegant software tools to make turf care easy, convenient, and affordable. +Follow Neal on LinkedIn (https://www.linkedin.com/in/neil-amrhein-9398969/). +Follow Erik on LinkedIn (https://www.linkedin.com/in/matt-erickson-153fish/). +My Goat (https://mygoat.co/) +Follow MyGoat on Twitter (https://twitter.com/MyGoatCo), Facebook (https://www.facebook.com/MyGoatCo), LinkedIn (https://www.linkedin.com/company/my-goat-inc), YouTube (https://www.youtube.com/channel/UCjV3ITbDvfqhQGIImFL5T7g/featured), or Instagram (https://www.instagram.com/mygoatco/). +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is a couple of people from a company with actual robots. It's Neal Amrhein, the founder and CEO, and Matt Erickson, the CTO of My Goat. Gentlemen, thanks for joining me. +So tell me more about this idea that you are robot-agnostic? Are you helping people choose the solution that's right for them? Or do you have go-to vendors? +NEIL: We do. So my philosophy, having spent a number of years in technology selling hardware and even software solutions, is that one thing that my experience has held is that hardware gets better, faster, and cheaper. +And for us to invest in a hardware platform or have customers invest in a hardware platform, I liken it to my early adoption of high-definition televisions where in 2003, I was one of those guys that spent $2,400 on a 42-inch Sony Wega TV. And now you can get a 70-inch with a lot more technology and so forth for about $300 at Costco. +So my feeling about hardware is it gets better, faster, cheaper. It's really the software that makes the difference in terms of how you leverage it. So we engage about 6 to 12 different hardware manufacturers that make autonomous robots from robots that are 27 to 35 pounds up to 1,200 pounds and all different variations in between. +And then, we extract the communication tools so that we can help our users who are formerly the groundskeepers become technology groundskeepers. And they are now interfacing with the concept of autonomous robots that are mowing commercial properties 24/7, which we would actually call maintaining versus mowing. +So we use nighttime, you know, day, night, rain or shine. So that's why we're robot-agnostic and welcome the latest and greatest designers and developers of hardware. We've got some folks that are just totally focused on designing, and developing, and building awesome autonomous robotic mowers with solar panels or great things that are going out there. And we're the software platform that brings it all together. +CHAD: I totally get what you're saying about the progress of hardware and wanting to be in the business of creating value on top of that. How do you make sure that you don't take on the business risk of one of the manufacturers just providing the solution that you're providing? +NEIL: Chad, we don't look at a business risk if there's a manufacturer that's going and selling autonomous robotic mowers. We welcome that, in fact, because that helps us with the adoption process. +The idea of having, you know, Roomba is the de facto vacuum cleaner that goes randomly in your house. But there are half a dozen other hardware devices and opportunities, and they're all selling it. It's really how are you managing that Roomba? Which is also the subscription component of the Netflix part of our business, which is that Roomba may be a shark next year. It may be something else the following year. +For our customers, we select the best hardware for their particular property, whether it's a golf course. They may have an autonomous robot that's manufactured by XYZ for the tee box and another one for the fairway, and another one for the greens. They just pay a monthly subscription for access to the software to manage those particular hardware pieces and optimize that hardware. And that's something that Matt will talk a little bit about. +But we really have taken the approach that robots are just like cars. They'll sit in your garage 20 hours out of the week, but they're actually effectively useful 168 hours a week. So how do we maximize that and utilize the hardware itself? And that's what our software does. And of course, with that, we share that information with our customers and our users to continue to make it more efficient. +CHAD: Thanks, Neil. Matt, what does the software stack actually look like that you're all putting together? +MATT: So we got to talk about the technology so Laravel, PHP, MySQL. We host in DigitalOcean. And we have a WordPress front end, but the back end is all Laravel PHP. +CHAD: And so it's in the cloud for all the customers? +MATT: Yes. +CHAD: And then how do you communicate with the fleet? +MATT: So we connect through APIs. The hardware generally has an API that can give us status updates at various intervals. So we aggregate that information back. And then, we present a web-based solution dashboard that includes different views. +We can get into the different users and how we've tried to meet their needs and drive workflow for them. But at a high level, we've got some graphical dashboards. And we also have some very tactical workflows for the guys. We call them shepherds taking care of our goats on the ground. +CHAD: I know that you said it's autonomous, but how do you communicate with the robots when you need to? Is it radio frequency locally, or is it cell phones? +MATT: So the robots actually come with…they have both GPS and cellular connectivity. So we have pretty good real-time connectivity with the robots. So we can remotely control them. We can park them, or we can send them back to their charging stations, different features like that. You can adjust cutting height, things like that, remotely. We also use just text messaging, SMS for communicating with shepherds. It's kind of real-time feedback. +So yeah, let me dig in a little bit, the autonomous idea of the robot. Yeah, we want them to be autonomous. And we work with our shepherds, groundskeepers so that each of the goats works in a pen, an area defined by that in the ground kind of like an invisible fence dog wire type thing. +But basically, we work with the shepherds, and we have this training certification process. But basically, they can get that pen to an area where really what we shoot for about 72 hours of the robot should be able to operate autonomously within that pen for about three and a half days. +And then shepherds will be instructed to move that robot to another pen for about three and a half days. Usually, one robot is taking care of…it ends up being about two and a half days. And that's kind of the way the software solution is driving that efficiency of people time as well as robot time. +The robots can mow 24/7. They take care of the grass. They maintain it, as Neil mentioned earlier. So it's not throw the robot out once a week kind of thing. You have to change your thinking. A lot of what we deal with when we go to a robot solution over that traditional status quo mowing we really have to help people through that thought process of this is not how it used to be. It works differently. But yep, that's kind of the solution. +CHAD: I feel like I need to ask, even though it's going to be a little bit of a tangent. +MATT: [laughs] +CHAD: How did you arrive at the name of My Goat and take the leap on a quirky name like that? +NEIL: Yeah, it's a great question. [laughs] First of all, I think that I first saw one of these robots through a YouTube video about three and a half or four years ago. And you may or may not know this, Chad, but there are about 3 million of these things that have been sold since 1995. So this is not bleeding edge technology in any way, shape, or form. +When I saw it on a YouTube video, it just kind of hit me that wow, these things are out there doing their thing day or night, rain or shine. And interestingly enough, the market, I guess the landscape market, the residential side, was somewhere in the neighborhood of $65 to $80 billion that we were targeting and looking at. +And as far as the goats, I had talked to some early folks who were marketing folks, and we just settled on Goat. And then we put my on the front end of it. And before we knew it, we had My Goat. And as we've evolved from just a cool robot-centric organization that's using software, we've evolved into an organization that's really teaching shepherds how to become interactive with the goats. And it's taken a life of its own. The blades are called teeth. +CHAD: [laughs] +NEIL: And those are some of our…of course, the goats need to be brushed. They don't get washed, or they don't get sprayed down with water, but they get brushed. And there's the whole the operating system is the heart and all kinds of stuff that's been going on. +CHAD: Well, I feel like with a name like My Goat, if you're not going to commit and carry that branding through to everything, what's the point? +[laughter] +NEIL: Right. Yes, it has taken a life of its own. And it's interesting. I don't know that it's the most catchy name for a software technology company. But it's certainly gotten some folks' attention, and it's helped. Let's put it this way: our marketing team really enjoys everything about what they can do with it. +CHAD: Well, and there's something to having a brand and carrying that through in the naming that causes ideas to resonate with people and makes them special. At the end of the day, you're mowing lawns. And so making it special and communicating that you have something special, I think, is something that people can do regardless of what their product is thinking of ways of doing that. +NEIL: Yeah. And I would add that I think the only pushback we've received on the name is probably from some of our high-end golf course users and prospects who don't want to turn their golf course into a goat track, so to speak. +CHAD: [laughs] +NEIL: But that's probably the extent of it. But overall, it's been well received without a doubt. And as we're focused on the software component of interacting with autonomous robots, our software development mentality and our vision is that it may be the same thing applied to 500 Roombas inside of a million square feet at a fulfillment center for Under Armour. +And instead of having 50 people cleaning the floors, you may have five people managing 500. And how do they do that effectively and efficiently? So there's really a business-focused component of the vision that I've had for the business. And that's helped me, along with many others, to get us to where we are. +MATT: I'm just going to jump in. You're right; the name sticks and people really adopt to the shepherd mentality. We get a lot of requests for shepherd crooks. [laughs] They all want a shepherd staff. +CHAD: So along those lines, when people are considering working with you, what are some of the questions or concerns that they have about a solution? +NEIL: Sure. So it's disruptive, Chad. I think I could probably start by saying the traditional way of maintaining or mowing commercial properties is that you have a big guy and a big machine, and how fast does it go? How much noise does it make? How many grass clippings get blown all over the place? You get in, and you get out. And then you start over. +So in the state of Tennessee, where we are here, it's about 34 to 36 weeks of mowing a year. In Michigan, it's 17 to 22 weeks, depending on where you are. In South Florida, believe it or not, I know there are only 52 weeks, but they're mowing 56 to 58 times a year. So it's the frequency of going and mowing and blowing, right? +CHAD: Mm-hmm. +NEIL: We're changing that by saying, why be worried about the weather? Why would you be worried about darkness? Why would you be worried about noise regulations when you can have the grass maintained all the time? +So that mentality of maintaining essentially two football fields a week up to three football fields a week with less than 35 minutes of labor. There is nothing in comparison. There's nothing you can compare with the traditional what we call the status quo to make that happen. +So the labor efficiency and improvement in labor productivity is just the tip of the iceberg in terms of the cost savings and the financial payback. So because we are so disruptive, a lot of what we do, and a lot of the time we spend, and one of our core values is being educators. +So back to your question about manufacturers selling their own proprietary hardware; absolutely, the more the merrier. We welcome. To me, the sign of success and progress is not the small city block that has one gas station but has four gas stations on the corner. It just now means there are cars that are driving around. And so, I embrace that level of competition. I believe iron sharpens iron. +And folks who are traditionally in the landscape space who have made trimmers and blowers and chainsaws are now finding a little bit of competition with folks who are now solely focused on making unbelievably efficient autonomous robotic mowers, or cleaners, or robots in general, which is, again, we're not crashing giant robots although that's the name of your podcast. [laughter] We're not trying to crash them or break them. But it is certainly the foundation for where we are. +MATT: Hey, Neil, you've got a good analogy. I think analogies help explain concepts. So you want to run through your airport analogy with the runways and the different airlines? +NEIL: Yeah, I could share that with you. Thanks for reminding me. So my philosophy about…we sell subscriptions that are based upon a geography, Chad. +CHAD: Size of geography, you mean? +NEIL: Yeah, the size of the geography. So it's about a football field, give or take. Based upon some limitations with technology, we put invisible dog fences in the ground, and we charge our users, our subscribers by the particular pen or the number of pens, and then there's a ratio. +So much like in an airport, we're not selling flights; we're selling runways. And those runways are accessible by all kinds of…you may have 30 terminals at the gates, and you may have five different airlines. And each of those airlines has a different brand and name, but they're using multiple hardware components. Those jets are maybe McDonnell Douglas, or maybe they're a Boeing or whatever it may be. All of that is fine by us. +What we do is we have the software that runs the gates, the terminals. So you have Southwest in terminal two and Delta in terminal 32. And they're using our software to figure out how to get the baggage on the planes and get those planes off the ground so they can make money for their businesses. So we look at it that way. +And that's kind of where our IP rests is in that spot in that place. And, again, there'll be other airlines, whether it's Allegiant or whomever buying more Boeing planes. But ultimately, they'll all need a runway, and the software that manages the process and the workflow is what we're focused on. +CHAD: So, is the total cost of ownership of autonomous solution typically lower than what they are doing today? +NEIL: It is, specifically, the labor improvement is generally about 3x in terms of improving the efficiency of the labor. So if you talk about an average groundskeeper who may be responsible for mowing, if it's a perfect day outside mowing nine acres a day and they are out there five days a week, they may have efficiencies of maybe up to 40 or 45 acres a week. With our solution, that is increased to about 135 to 145 acres a week where they can maintain about 70 mowers, 70 autonomous robotic mowers, or 70 goats as we call them. They'll herd 70 goats with the same full-time employee. So that's one aspect. +With that, the immediate reaction is, well, you're eliminating jobs. We're actually redeploying jobs. I'm a builder. I'm a job creator. I've had 4,800 folks work for me in my home care business over the last 12 years. And so, I'm a big believer in improving and deploying folks in areas that we don't have robots. +So, for example, there's no robot right now that's pruning trees or making up a sand trap, robots that are planting flowers or putting mulch in a flower bed. So those kinds of jobs are still out there. We're just making the traditional idea of throwing somebody on a mower in the middle of a cemetery or golf course or open space and having them manage that through our software platform sitting in their F150 pushing start and stop or pause and doing other things. +CHAD: Instead of riding on the mower. +NEIL: You got it. +MATT: A lot of our potential customers come to us because (we kind of touched on that) there's a labor shortage. It's hard for folks to find people that want to ride zero-turns. So to Neil's point, we're not about deploying robots, kind of one for one replacing jobs. It's basically we're taking the labor force that we can get, that we have, and we're retraining them to be more efficient through these robots. Pretty age-old story when you're talking about industrialization. +But the idea is we haven't displaced workers. They're not hiring fewer people. They're taking everybody they can get. And they're doing all of that value add. The groundskeepers now have time to go out and do the mulching and the landscaping, trimming, improving the property. +A lot of these groundskeepers have a lot of pride in their property. And they would rather be doing the items that to them are a value add and beautification projects rather than just riding a Back 40 or a zero-turn. We had one shepherd say, hey, it's really helped his back. Riding a lawnmower is kind of rough. And walking around every now and then helping out a robot is a whole lot easier of a physical life for you. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So I saw on the website because of the kind of solution and the scale that it's at, it seems like you have a few different key customer bases. You want to talk about that and whether you knew that going in, or did you find them along the way? +NEIL: Yeah, that's a great question. So we came out of the gate initially with early investors. We were focused on what we considered was the low-hanging fruit in the residential space. So we had designed and developed the operational and financial template to actually have shepherds who were employees of My Goat. And we would have the Goats sold in a subscription model to residential customers. And then we'd have the goat stay on a property and then get moved, et cetera. +But we learned very quickly that business to consumer and residential customers it's not that impossible; it just was not as low-hanging fruit as we had thought initially because folks leave rakes in the yard. And anytime a goat comes upon a rake, it's going to get trapped, and therefore it needs to be rescued. And you have to send a shepherd out, et cetera. Or somebody decides to put a new vegetable garden, and they break the wire that's in the ground. They're just a bunch of…, or there's a dog chasing the robot or a little kid out there, or somebody stops it. So those required a lot of…it didn't make the robot autonomous. +So we pivoted in late 2019, early 2020 into the commercial space. We expired all of our subscriptions to residential customers and went completely into the commercial space. And we had had some success with some golf courses and some cemeteries. And we've gained a lot more momentum now with cities and counties, regional airports. But large open areas that are a minimum of five acres, typically we would run a pilot or a preview with at least 12 to 14 acres. +But the biggest restriction, of course, when you get into those large open areas is electricity because they've been traditionally maintained or mowed by gas-powered machines. So back to your other question about where the savings is and the payback period, and how we have an immediate impact. There's an operational savings that is pretty quick in terms of the return because we flatten out a lot of the ups and downs that a traditional landscaper has. +So let's take a golf course, for example. The average golf course spends about $80,000 per hole per year and depending on the course, 45% to 60% of that is spent on mowing, mowing machines, and people involved. And we're able to take that, and they're hiring temporary people in March here in the south, and they have them here until October. So they're having to go through that cycle every single year. +So if they can flatten that operational expense out by redesigning the golf course and having…and maybe it's not 100%. Much like a Roomba, you still have to get the corners and the edges, maybe with a broom if it doesn't get into every nook and cranny. So it's not a 100% solution. It's not for every application. +But as we moved into the commercial space, we found a greater payback period not only on the cost of the gasoline is...you know, take a zero-turn mower. And again, I say that's probably our greatest competitor is institutionalized thinking to say, this year we're going to buy a big green, big red, or big orange machine for $16,000 or $18,000, Kubota, Toro, or John Deere. And we're going to do the same thing we did last year. We're going to find a guy who can operate it. We're going to put gas in it, and we're going to run it around. +Well, you put hours in those things, and they're very costly to maintain if you hit a root. So you've got to make sure that you can't run a 1,800-pound mower when it's been raining for three days. So what do you do with a fairway when it's soggy or any other commercial area that could be…or a hill that could be dangerous. So we've found a lot of application and then, of course, the environmental part of it, Chad. +So the average zero-turn emits the equivalent of a carbon footprint every hour it's running about 300 miles of a Toyota Camry running. So they haven't become more efficient. And then you've got noise regulations and so forth in a lot of communities. +And even in California, they're moving in the direction of I think it's 2024 where gas-powered and oil-powered landscaping blowers and tremors, et cetera, are not going to be allowed, or you'll be fined for using them. So that's the third component of where My Goat has seen some opportunities in the commercial space. +CHAD: You mentioned that they can run at night. So they must be quiet. They must be. +NEIL: Yes, they are. And it's not the traditional…you're not making as much of a mess. Some of our cemetery customers have mentioned that the fact that their trimming has been reduced by up to 50% because they're going up and over markers because they only weigh 27 pounds. They're mostly plastic and rubber. They're not doing any damage to vases. So they're having a cost reduction in that regard but also with the uprights. +Folks have their family members in a particular private estate area where they may have an upright, and if you have a zero-turn mower out there throwing and splashing grass clippings, you're likely having to go out there again with more labor and take a blower and clean up the mess that the mower made. So these little small operational components along with the experience. +Again, back to the cemetery, you're asking about why we're there. We know that industry very well. And we know that the experience that loved ones want to have when they're out there celebrating life and grieving across a 40 or 50-acre property. They don't want to hear a zero-turn. +So you're turning those things off three or four times a day for those services, and you're having that individual parked a quarter-mile away. No longer is that an operational challenge or a concern because all of these robots are being controlled, start, stopped, and programmed through our software. +CHAD: That's really cool. So you mentioned investors and the early pivot away from residential to commercial. What does your funding story look like? And what phase did you get to when you took on investment? And let's start there. How did you find your initial investors? And what phase were you at when you did that? +NEIL: Yeah, that's a great question. So we went through the traditional friends and family and moved into an angel round, but really I started my first company…bootstrapped it. And so, I wasn't really proficient in raising money in the traditional sense. I had an idea, put a business plan together. +And I talked to a couple of folks and just told the story. To be honest with you, Chad, I wasn't really asking for money. I was more or less asking for advice. And then a number of folks were like, "Are you taking money? I'd like to take an equity position." And so, we structured the business and the shares on a pre-revenue valuation. And then, within 14 months, we were able to double that valuation. +And we're now opening a new round here and a Series A with a valuation that's nearly five times our initial valuation. So we're making a lot of progress because we have, again, it's an annual recurring revenue stream. It's a subscription model. +And what we did with our investors in the early rounds is many of them came on, and they just wanted to be silent. They were not interested in having an opinion. They wanted me and my team to run it. So that's been very helpful. So that's where we are in 2022. We'll be opening and closing a Series A. And I certainly can get more specific with others about that if your listeners or audience are interested. +CHAD: So when you think about a Series A, what will you be using that for? What are your next scaling goals? +NEIL: My commitment to my investors in the previous two rounds has been to sales and technology, so sales, business development, and technology enhancement to the software, so hiring more developers, scaling that team. Matt's leading the vision, and we've got a number of other folks who are involved in the user experience. But again, because we're a software company, it starts with a demonstration that's usually 15 or 20 minutes that can be scheduled through our website at mygoat.co. And it goes from there. +On the sales side and business development is telling the story. In those verticals, we're interested in building out potentially even reseller markets with other industries that are aligned with us. We've had some very high-level conversations with folks that sell electricity for a living. The Tennessee Valley Authority we became an early preferred partner with them and because they have carbon credit that they can offer and sell to their customers, their local power companies. And they're in the business of selling power. And we're in the business of providing subscriptions that require power. +CHAD: What are some barriers to continuing to scale? Do you have geographic barriers? +NEIL: I have self-imposed geographic barriers, [laughter] +So it's a Neil Amrhein barrier. But overall, our barriers, our challenges really are; I’ve never heard of these things before. Do they actually mow? So we get through those conversations fairly quickly. But depending on who we're talking to, it also becomes a fear. People fear change and especially things that are disruptive. +So our barriers, once we get through the fear, is we don't have any electricity here on this golf course, or this city park, or this regional airport that there is unlimited electricity. So we can pull whatever electricity is necessary there. So it is really the barriers of education, just like anything that's truly disruptive in an industry that's been doing the same thing for 45 or 50 years. +CHAD: So you already talked about how you view potential competition from manufacturers, but how do you view competition in general? Is there other competition out there? +NEIL: The biggest competition we have is institutionalized thinking, which is doing the same thing we did last year. So that's a battle that we have every day. I like competition because I think it makes the end product, and the customer is the one who benefits the most from having lots of people in the market no matter what their angle is. +We like our position because, again, we're not the hardware manufacturer. We're able to work with others. We're the financial advisor that gets to work with the insurance guy and everybody else, where all your money is with your college buddy who's managing it, et cetera. We're agnostic. We're putting it all together. So it benefits everybody. +And those who make and manufacture these robots get the benefit as well because it's part of the subscription process as far as that's concerned. But the more, the merrier. A lot of people come to me and say, "Well, I saw an autonomous robotic mower out on this lawn or in the neighborhood here." And that's good for us. +CHAD: Matt, I assume that being robot-agnostic means that you need to integrate with the different systems. Does that have challenges? +MATT: You know, not really. Robots are, as far as the autonomous robotic lawn mowers, they're pretty much telling us the same thing. There are status updates; there are battery updates; there are GPS coordinates. It does tend to be a pretty common data set that we're seeing. So it's been a lot easier than I thought. When you think about…data integrations are always the top challenge you have. It's worked out a lot better than we thought initially. +CHAD: Well, that's great. Has there been anything surprising the other way which was something you thought was going to be easy turned out to be a lot harder? +MATT: Yeah. We've had a manufacturer that actually had a tiered concept in their data availability. They weren't giving us all of the data that they had. They were saving it because they were running their own kind of hey, you can use home automation techniques to integrate with your residential autonomous robotic lawnmower. Hey, if it's raining at your house, we could park your robot. So they were kind of hiding some of the API from us. We were able to work through that. +But I think that goes to one of your questions about concern around competition from the manufacturers. They're really not looking at this from that niche that we're hitting, that commercial perspective. +Maintaining one Roomba in your house is the analogy I use. You kind of know where he gets stuck, and you go find him. And that's okay. You don't need a lot of software for that. But that analogy Neil mentioned, if you have 500 of these guys running around a warehouse, or for us, we have property with 50 robots on. How do you know which one right now -- +CHAD: And the space that that takes up. +MATT: Right. Right. +CHAD: You can't see them all necessarily even. +MATT: [laughs] Exactly. You can't. You can't just walk around and see everyone and visually check. You need that software to be efficient to know; oh, there are three things I need to do today with the robots. Let me plan that out, and let me take care of it. +So I think, like Neil said, the manufacturers out there they're making lawn equipment. They're making lots of different hardware. And to them, fleet management is really where is my hardware right now? [laughs] That's the extent of it. And they can't think about a property that needs maybe two or three different manufacturers of hardware because properties are not one homogeneous set of type of grass. There are always different needs, different features on that property. So there's always that idea that we're going to need a couple of different manufacturers, maybe. +So, yeah, it's really interesting. For me, I think it's we're really hitting a home run in an area that there really aren't any other competitors exactly in our niche. And if there are, I think the industry for us what we do is at a place where we need more adoption out there in the world. [crosstalk 34:03] +CHAD: Do you ever hear from early adopters? People who say they've either already bought autonomous mowers and they're struggling to manage them, or they really want to, and they're coming to you to do it? +NEIL: That's a great point. I have a couple of thoughts here because you guys are going in a lot of different directions here. +MATT: [laughs] +NEIL: Chad, the short answer is when people buy anything early on, they're going to have the proverbial challenges of who supports it when it breaks? Who do I call? What happens next? It just goes on and on and on, whether it's a hardware platform, and that's mostly the case, or it's something else. It's what does that support look like? +So the early adopters when we talk about their experiences, and this is one of the things I would say is probably our biggest challenge is that we have created a learning management software platform, a video library of how do you work with robots? We know that they're going to get trapped. +There is no doubt that a 27-pound autonomous goat if there is a lightning strike like there was here in Nashville last night, they're going to be tree limbs that are down. And there'll be goats that are trapped. And it's going to take a human being, a shepherd, to be notified via SMS alert to proactively go to that spot on that property across 50 or 100 acres and rescue that goat. And it's just a matter of these kinds of things happen environmentally. +So we talk about, when we talk to customers, about their utilization of the goat. And we talk about optimizing their property. It's not really that the goat doesn't graze or the robot doesn't work. It's what are the restrictions and the environmental challenges that are in front of it? If there are erosion issues around a marker or in a large open field, and if it's a really well-groomed practice field or intramural field, it's likely going to be aerated. It's going to be very flat, et cetera. But most commercial properties are not that way. +So the goats actually have a tendency to go out, and they're going to find all those environmental challenges. And it requires a human being to go out there and fix them. Because if the environmental challenge is that there's a hole and on a horse farm, it's going to be there until somebody throws some dirt in it. It's just the reality. And that goat is going to find that environmental challenge every single time. So there is a learning curve that goes with it. There's a level of patience. +And I think you mentioned what's our challenge? Our challenge is letting folks know that it's an evolution, not a revolution, as far as what your property is going to look like. I spent a number of years at the Ritz Carlton Hotel Company, and we talk about property health as is it a two-star property, a three-star property, four-star property, five-star property? +We recognize that a lot of commercial properties are going to just be a two-star. But potentially, they could be a three-star property. Or if it's a cemetery and you've got a goat that's maybe found environmental challenges on a cemetery, it also becomes a liability or risk for family members who go visit their loved ones. +So now we're using the robot proactively to improve the status of the property as opposed to saying, well, it just gets trapped every time it finds a hole or every time there's a situation that goes on. So it does require an active level of engagement and maintenance. And the philosophy has to be changed so that groundskeepers are now checking their phones or being alerted at 7:15 in the morning. And they may go rescue Billy, the goat, because a lot of folks name their robots. [laughter] +They're going out there, and they're in pen 34,27, 31. And then at lunchtime, they may have another two or three of the same goats that were trapped, need to be rescued, and then again at 4:00 o'clock in the afternoon. So it's a maintenance mentality as opposed to a mow and go mentality. So that is philosophically a big change in terms of their mindset. +CHAD: So what's next for My Goat then? You mentioned the Series A. Is there anything in particular on your radar that you're either worried about or are looking forward to? +NEIL: Looking forward to more folks like your audience and listeners hearing our story. I'm in the business of telling our story. And I welcome, again, the competition because that means there's validation for what's going on. I don't think we're going to stuff this genie back in the bottle, so to speak. +It's going to be hard for me to believe that five, six years from now, folks are going to be out there firing up a push mower that they just bought at Lowe's when they can buy something at Lowe's that's $250 for a residential robot that they get to use. +Same thing on the commercial space. I don't know what it ultimately looks like from a vision perspective. But I think our challenge is continuing the messaging, the adoption, enhancing the payback period. It is really just like any good technology, artificial intelligence, robotics, et cetera. I mean, that combination. +I hold the position, Chad, that I don't really think any technology is being developed or new per se since the invention of the internet. It's the application of the technology. It's what are people doing that they weren't doing before? +We have the communication tools with 5G or what have you that we didn't have five or six years ago that we can now ping our goats every 15 minutes and find out what their status is. And then we can report that back to the user and say, "Hey, your optimization or utilization on your hardware and your subscription is X, Y, and Z. And your return on investment is six months to 16 months." That's where I think it elevates the conversation of efficiency and changes the game. +So our next steps are continuing to get the message out, embrace not only users but industries we haven't thought about. I mentioned horse farms that just came on my radar screen not too long ago. We've had some success with cities and counties. You can imagine…everything one of our core values is green is good, and time is a number. +So you just drive down the interstate, and you can see so much green everywhere as far as opportunities ahead. And there's plenty of room for lots of people to play in this space. We welcome more and more of probably the designers and developers that you got on this podcast to come up with the latest and greatest hardware and make those APIs available for Matt and his team to integrate and continue to grow. +CHAD: That's great. If folks want to reach out to you to either learn more or see if you can work together, where are the best places for them to do that? +NEIL: Sure. Let me first direct them to www.mygoat.co. And there are a series of areas there where it's either click on a demo now or information. Our phone number is listed there as well. +I'll also give you my email address, which is Neil, N-E-I-L neil@mygoat.co, so neil@mygoat.co. And Matt's is just matt@mygoat.co as well. And those are probably the fastest way to connect with us. And if they put in a quick subject line your name and your podcast, it'll bubble everybody to the top a little faster. +CHAD: Wonderful. Thank you both for joining me. I really appreciate it. +MATT: Absolutely. Thank you, Chad. +NEIL: Thank you for having us. +CHAD: And I wish you all the best. +You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guests: Matthew Erickson and Neal Amrhein. + + + Neal Amrhein is the founder and CEO and Matt Erickson is the CTO of My Goat. My Goat is a subscription mowing service for commercial properties. They use robotic mowers and elegant software tools to make turf care easy, convenient, and affordable.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is a couple of people from a company with actual robots. It's Neal Amrhein, the founder and CEO, and Matt Erickson, the CTO of My Goat. Gentlemen, thanks for joining me.

+ +

So tell me more about this idea that you are robot-agnostic? Are you helping people choose the solution that's right for them? Or do you have go-to vendors?

+ +

NEIL: We do. So my philosophy, having spent a number of years in technology selling hardware and even software solutions, is that one thing that my experience has held is that hardware gets better, faster, and cheaper.

+ +

And for us to invest in a hardware platform or have customers invest in a hardware platform, I liken it to my early adoption of high-definition televisions where in 2003, I was one of those guys that spent $2,400 on a 42-inch Sony Wega TV. And now you can get a 70-inch with a lot more technology and so forth for about $300 at Costco.

+ +

So my feeling about hardware is it gets better, faster, cheaper. It's really the software that makes the difference in terms of how you leverage it. So we engage about 6 to 12 different hardware manufacturers that make autonomous robots from robots that are 27 to 35 pounds up to 1,200 pounds and all different variations in between.

+ +

And then, we extract the communication tools so that we can help our users who are formerly the groundskeepers become technology groundskeepers. And they are now interfacing with the concept of autonomous robots that are mowing commercial properties 24/7, which we would actually call maintaining versus mowing.

+ +

So we use nighttime, you know, day, night, rain or shine. So that's why we're robot-agnostic and welcome the latest and greatest designers and developers of hardware. We've got some folks that are just totally focused on designing, and developing, and building awesome autonomous robotic mowers with solar panels or great things that are going out there. And we're the software platform that brings it all together.

+ +

CHAD: I totally get what you're saying about the progress of hardware and wanting to be in the business of creating value on top of that. How do you make sure that you don't take on the business risk of one of the manufacturers just providing the solution that you're providing?

+ +

NEIL: Chad, we don't look at a business risk if there's a manufacturer that's going and selling autonomous robotic mowers. We welcome that, in fact, because that helps us with the adoption process.

+ +

The idea of having, you know, Roomba is the de facto vacuum cleaner that goes randomly in your house. But there are half a dozen other hardware devices and opportunities, and they're all selling it. It's really how are you managing that Roomba? Which is also the subscription component of the Netflix part of our business, which is that Roomba may be a shark next year. It may be something else the following year.

+ +

For our customers, we select the best hardware for their particular property, whether it's a golf course. They may have an autonomous robot that's manufactured by XYZ for the tee box and another one for the fairway, and another one for the greens. They just pay a monthly subscription for access to the software to manage those particular hardware pieces and optimize that hardware. And that's something that Matt will talk a little bit about.

+ +

But we really have taken the approach that robots are just like cars. They'll sit in your garage 20 hours out of the week, but they're actually effectively useful 168 hours a week. So how do we maximize that and utilize the hardware itself? And that's what our software does. And of course, with that, we share that information with our customers and our users to continue to make it more efficient.

+ +

CHAD: Thanks, Neil. Matt, what does the software stack actually look like that you're all putting together?

+ +

MATT: So we got to talk about the technology so Laravel, PHP, MySQL. We host in DigitalOcean. And we have a WordPress front end, but the back end is all Laravel PHP.

+ +

CHAD: And so it's in the cloud for all the customers?

+ +

MATT: Yes.

+ +

CHAD: And then how do you communicate with the fleet?

+ +

MATT: So we connect through APIs. The hardware generally has an API that can give us status updates at various intervals. So we aggregate that information back. And then, we present a web-based solution dashboard that includes different views.

+ +

We can get into the different users and how we've tried to meet their needs and drive workflow for them. But at a high level, we've got some graphical dashboards. And we also have some very tactical workflows for the guys. We call them shepherds taking care of our goats on the ground.

+ +

CHAD: I know that you said it's autonomous, but how do you communicate with the robots when you need to? Is it radio frequency locally, or is it cell phones?

+ +

MATT: So the robots actually come with…they have both GPS and cellular connectivity. So we have pretty good real-time connectivity with the robots. So we can remotely control them. We can park them, or we can send them back to their charging stations, different features like that. You can adjust cutting height, things like that, remotely. We also use just text messaging, SMS for communicating with shepherds. It's kind of real-time feedback.

+ +

So yeah, let me dig in a little bit, the autonomous idea of the robot. Yeah, we want them to be autonomous. And we work with our shepherds, groundskeepers so that each of the goats works in a pen, an area defined by that in the ground kind of like an invisible fence dog wire type thing.

+ +

But basically, we work with the shepherds, and we have this training certification process. But basically, they can get that pen to an area where really what we shoot for about 72 hours of the robot should be able to operate autonomously within that pen for about three and a half days.

+ +

And then shepherds will be instructed to move that robot to another pen for about three and a half days. Usually, one robot is taking care of…it ends up being about two and a half days. And that's kind of the way the software solution is driving that efficiency of people time as well as robot time.

+ +

The robots can mow 24/7. They take care of the grass. They maintain it, as Neil mentioned earlier. So it's not throw the robot out once a week kind of thing. You have to change your thinking. A lot of what we deal with when we go to a robot solution over that traditional status quo mowing we really have to help people through that thought process of this is not how it used to be. It works differently. But yep, that's kind of the solution.

+ +

CHAD: I feel like I need to ask, even though it's going to be a little bit of a tangent.

+ +

MATT: [laughs]

+ +

CHAD: How did you arrive at the name of My Goat and take the leap on a quirky name like that?

+ +

NEIL: Yeah, it's a great question. [laughs] First of all, I think that I first saw one of these robots through a YouTube video about three and a half or four years ago. And you may or may not know this, Chad, but there are about 3 million of these things that have been sold since 1995. So this is not bleeding edge technology in any way, shape, or form.

+ +

When I saw it on a YouTube video, it just kind of hit me that wow, these things are out there doing their thing day or night, rain or shine. And interestingly enough, the market, I guess the landscape market, the residential side, was somewhere in the neighborhood of $65 to $80 billion that we were targeting and looking at.

+ +

And as far as the goats, I had talked to some early folks who were marketing folks, and we just settled on Goat. And then we put my on the front end of it. And before we knew it, we had My Goat. And as we've evolved from just a cool robot-centric organization that's using software, we've evolved into an organization that's really teaching shepherds how to become interactive with the goats. And it's taken a life of its own. The blades are called teeth.

+ +

CHAD: [laughs]

+ +

NEIL: And those are some of our…of course, the goats need to be brushed. They don't get washed, or they don't get sprayed down with water, but they get brushed. And there's the whole the operating system is the heart and all kinds of stuff that's been going on.

+ +

CHAD: Well, I feel like with a name like My Goat, if you're not going to commit and carry that branding through to everything, what's the point?

+ +

[laughter]

+ +

NEIL: Right. Yes, it has taken a life of its own. And it's interesting. I don't know that it's the most catchy name for a software technology company. But it's certainly gotten some folks' attention, and it's helped. Let's put it this way: our marketing team really enjoys everything about what they can do with it.

+ +

CHAD: Well, and there's something to having a brand and carrying that through in the naming that causes ideas to resonate with people and makes them special. At the end of the day, you're mowing lawns. And so making it special and communicating that you have something special, I think, is something that people can do regardless of what their product is thinking of ways of doing that.

+ +

NEIL: Yeah. And I would add that I think the only pushback we've received on the name is probably from some of our high-end golf course users and prospects who don't want to turn their golf course into a goat track, so to speak.

+ +

CHAD: [laughs]

+ +

NEIL: But that's probably the extent of it. But overall, it's been well received without a doubt. And as we're focused on the software component of interacting with autonomous robots, our software development mentality and our vision is that it may be the same thing applied to 500 Roombas inside of a million square feet at a fulfillment center for Under Armour.

+ +

And instead of having 50 people cleaning the floors, you may have five people managing 500. And how do they do that effectively and efficiently? So there's really a business-focused component of the vision that I've had for the business. And that's helped me, along with many others, to get us to where we are.

+ +

MATT: I'm just going to jump in. You're right; the name sticks and people really adopt to the shepherd mentality. We get a lot of requests for shepherd crooks. [laughs] They all want a shepherd staff.

+ +

CHAD: So along those lines, when people are considering working with you, what are some of the questions or concerns that they have about a solution?

+ +

NEIL: Sure. So it's disruptive, Chad. I think I could probably start by saying the traditional way of maintaining or mowing commercial properties is that you have a big guy and a big machine, and how fast does it go? How much noise does it make? How many grass clippings get blown all over the place? You get in, and you get out. And then you start over.

+ +

So in the state of Tennessee, where we are here, it's about 34 to 36 weeks of mowing a year. In Michigan, it's 17 to 22 weeks, depending on where you are. In South Florida, believe it or not, I know there are only 52 weeks, but they're mowing 56 to 58 times a year. So it's the frequency of going and mowing and blowing, right?

+ +

CHAD: Mm-hmm.

+ +

NEIL: We're changing that by saying, why be worried about the weather? Why would you be worried about darkness? Why would you be worried about noise regulations when you can have the grass maintained all the time?

+ +

So that mentality of maintaining essentially two football fields a week up to three football fields a week with less than 35 minutes of labor. There is nothing in comparison. There's nothing you can compare with the traditional what we call the status quo to make that happen.

+ +

So the labor efficiency and improvement in labor productivity is just the tip of the iceberg in terms of the cost savings and the financial payback. So because we are so disruptive, a lot of what we do, and a lot of the time we spend, and one of our core values is being educators.

+ +

So back to your question about manufacturers selling their own proprietary hardware; absolutely, the more the merrier. We welcome. To me, the sign of success and progress is not the small city block that has one gas station but has four gas stations on the corner. It just now means there are cars that are driving around. And so, I embrace that level of competition. I believe iron sharpens iron.

+ +

And folks who are traditionally in the landscape space who have made trimmers and blowers and chainsaws are now finding a little bit of competition with folks who are now solely focused on making unbelievably efficient autonomous robotic mowers, or cleaners, or robots in general, which is, again, we're not crashing giant robots although that's the name of your podcast. [laughter] We're not trying to crash them or break them. But it is certainly the foundation for where we are.

+ +

MATT: Hey, Neil, you've got a good analogy. I think analogies help explain concepts. So you want to run through your airport analogy with the runways and the different airlines?

+ +

NEIL: Yeah, I could share that with you. Thanks for reminding me. So my philosophy about…we sell subscriptions that are based upon a geography, Chad.

+ +

CHAD: Size of geography, you mean?

+ +

NEIL: Yeah, the size of the geography. So it's about a football field, give or take. Based upon some limitations with technology, we put invisible dog fences in the ground, and we charge our users, our subscribers by the particular pen or the number of pens, and then there's a ratio.

+ +

So much like in an airport, we're not selling flights; we're selling runways. And those runways are accessible by all kinds of…you may have 30 terminals at the gates, and you may have five different airlines. And each of those airlines has a different brand and name, but they're using multiple hardware components. Those jets are maybe McDonnell Douglas, or maybe they're a Boeing or whatever it may be. All of that is fine by us.

+ +

What we do is we have the software that runs the gates, the terminals. So you have Southwest in terminal two and Delta in terminal 32. And they're using our software to figure out how to get the baggage on the planes and get those planes off the ground so they can make money for their businesses. So we look at it that way.

+ +

And that's kind of where our IP rests is in that spot in that place. And, again, there'll be other airlines, whether it's Allegiant or whomever buying more Boeing planes. But ultimately, they'll all need a runway, and the software that manages the process and the workflow is what we're focused on.

+ +

CHAD: So, is the total cost of ownership of autonomous solution typically lower than what they are doing today?

+ +

NEIL: It is, specifically, the labor improvement is generally about 3x in terms of improving the efficiency of the labor. So if you talk about an average groundskeeper who may be responsible for mowing, if it's a perfect day outside mowing nine acres a day and they are out there five days a week, they may have efficiencies of maybe up to 40 or 45 acres a week. With our solution, that is increased to about 135 to 145 acres a week where they can maintain about 70 mowers, 70 autonomous robotic mowers, or 70 goats as we call them. They'll herd 70 goats with the same full-time employee. So that's one aspect.

+ +

With that, the immediate reaction is, well, you're eliminating jobs. We're actually redeploying jobs. I'm a builder. I'm a job creator. I've had 4,800 folks work for me in my home care business over the last 12 years. And so, I'm a big believer in improving and deploying folks in areas that we don't have robots.

+ +

So, for example, there's no robot right now that's pruning trees or making up a sand trap, robots that are planting flowers or putting mulch in a flower bed. So those kinds of jobs are still out there. We're just making the traditional idea of throwing somebody on a mower in the middle of a cemetery or golf course or open space and having them manage that through our software platform sitting in their F150 pushing start and stop or pause and doing other things.

+ +

CHAD: Instead of riding on the mower.

+ +

NEIL: You got it.

+ +

MATT: A lot of our potential customers come to us because (we kind of touched on that) there's a labor shortage. It's hard for folks to find people that want to ride zero-turns. So to Neil's point, we're not about deploying robots, kind of one for one replacing jobs. It's basically we're taking the labor force that we can get, that we have, and we're retraining them to be more efficient through these robots. Pretty age-old story when you're talking about industrialization.

+ +

But the idea is we haven't displaced workers. They're not hiring fewer people. They're taking everybody they can get. And they're doing all of that value add. The groundskeepers now have time to go out and do the mulching and the landscaping, trimming, improving the property.

+ +

A lot of these groundskeepers have a lot of pride in their property. And they would rather be doing the items that to them are a value add and beautification projects rather than just riding a Back 40 or a zero-turn. We had one shepherd say, hey, it's really helped his back. Riding a lawnmower is kind of rough. And walking around every now and then helping out a robot is a whole lot easier of a physical life for you.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So I saw on the website because of the kind of solution and the scale that it's at, it seems like you have a few different key customer bases. You want to talk about that and whether you knew that going in, or did you find them along the way?

+ +

NEIL: Yeah, that's a great question. So we came out of the gate initially with early investors. We were focused on what we considered was the low-hanging fruit in the residential space. So we had designed and developed the operational and financial template to actually have shepherds who were employees of My Goat. And we would have the Goats sold in a subscription model to residential customers. And then we'd have the goat stay on a property and then get moved, et cetera.

+ +

But we learned very quickly that business to consumer and residential customers it's not that impossible; it just was not as low-hanging fruit as we had thought initially because folks leave rakes in the yard. And anytime a goat comes upon a rake, it's going to get trapped, and therefore it needs to be rescued. And you have to send a shepherd out, et cetera. Or somebody decides to put a new vegetable garden, and they break the wire that's in the ground. They're just a bunch of…, or there's a dog chasing the robot or a little kid out there, or somebody stops it. So those required a lot of…it didn't make the robot autonomous.

+ +

So we pivoted in late 2019, early 2020 into the commercial space. We expired all of our subscriptions to residential customers and went completely into the commercial space. And we had had some success with some golf courses and some cemeteries. And we've gained a lot more momentum now with cities and counties, regional airports. But large open areas that are a minimum of five acres, typically we would run a pilot or a preview with at least 12 to 14 acres.

+ +

But the biggest restriction, of course, when you get into those large open areas is electricity because they've been traditionally maintained or mowed by gas-powered machines. So back to your other question about where the savings is and the payback period, and how we have an immediate impact. There's an operational savings that is pretty quick in terms of the return because we flatten out a lot of the ups and downs that a traditional landscaper has.

+ +

So let's take a golf course, for example. The average golf course spends about $80,000 per hole per year and depending on the course, 45% to 60% of that is spent on mowing, mowing machines, and people involved. And we're able to take that, and they're hiring temporary people in March here in the south, and they have them here until October. So they're having to go through that cycle every single year.

+ +

So if they can flatten that operational expense out by redesigning the golf course and having…and maybe it's not 100%. Much like a Roomba, you still have to get the corners and the edges, maybe with a broom if it doesn't get into every nook and cranny. So it's not a 100% solution. It's not for every application.

+ +

But as we moved into the commercial space, we found a greater payback period not only on the cost of the gasoline is...you know, take a zero-turn mower. And again, I say that's probably our greatest competitor is institutionalized thinking to say, this year we're going to buy a big green, big red, or big orange machine for $16,000 or $18,000, Kubota, Toro, or John Deere. And we're going to do the same thing we did last year. We're going to find a guy who can operate it. We're going to put gas in it, and we're going to run it around.

+ +

Well, you put hours in those things, and they're very costly to maintain if you hit a root. So you've got to make sure that you can't run a 1,800-pound mower when it's been raining for three days. So what do you do with a fairway when it's soggy or any other commercial area that could be…or a hill that could be dangerous. So we've found a lot of application and then, of course, the environmental part of it, Chad.

+ +

So the average zero-turn emits the equivalent of a carbon footprint every hour it's running about 300 miles of a Toyota Camry running. So they haven't become more efficient. And then you've got noise regulations and so forth in a lot of communities.

+ +

And even in California, they're moving in the direction of I think it's 2024 where gas-powered and oil-powered landscaping blowers and tremors, et cetera, are not going to be allowed, or you'll be fined for using them. So that's the third component of where My Goat has seen some opportunities in the commercial space.

+ +

CHAD: You mentioned that they can run at night. So they must be quiet. They must be.

+ +

NEIL: Yes, they are. And it's not the traditional…you're not making as much of a mess. Some of our cemetery customers have mentioned that the fact that their trimming has been reduced by up to 50% because they're going up and over markers because they only weigh 27 pounds. They're mostly plastic and rubber. They're not doing any damage to vases. So they're having a cost reduction in that regard but also with the uprights.

+ +

Folks have their family members in a particular private estate area where they may have an upright, and if you have a zero-turn mower out there throwing and splashing grass clippings, you're likely having to go out there again with more labor and take a blower and clean up the mess that the mower made. So these little small operational components along with the experience.

+ +

Again, back to the cemetery, you're asking about why we're there. We know that industry very well. And we know that the experience that loved ones want to have when they're out there celebrating life and grieving across a 40 or 50-acre property. They don't want to hear a zero-turn.

+ +

So you're turning those things off three or four times a day for those services, and you're having that individual parked a quarter-mile away. No longer is that an operational challenge or a concern because all of these robots are being controlled, start, stopped, and programmed through our software.

+ +

CHAD: That's really cool. So you mentioned investors and the early pivot away from residential to commercial. What does your funding story look like? And what phase did you get to when you took on investment? And let's start there. How did you find your initial investors? And what phase were you at when you did that?

+ +

NEIL: Yeah, that's a great question. So we went through the traditional friends and family and moved into an angel round, but really I started my first company…bootstrapped it. And so, I wasn't really proficient in raising money in the traditional sense. I had an idea, put a business plan together.

+ +

And I talked to a couple of folks and just told the story. To be honest with you, Chad, I wasn't really asking for money. I was more or less asking for advice. And then a number of folks were like, "Are you taking money? I'd like to take an equity position." And so, we structured the business and the shares on a pre-revenue valuation. And then, within 14 months, we were able to double that valuation.

+ +

And we're now opening a new round here and a Series A with a valuation that's nearly five times our initial valuation. So we're making a lot of progress because we have, again, it's an annual recurring revenue stream. It's a subscription model.

+ +

And what we did with our investors in the early rounds is many of them came on, and they just wanted to be silent. They were not interested in having an opinion. They wanted me and my team to run it. So that's been very helpful. So that's where we are in 2022. We'll be opening and closing a Series A. And I certainly can get more specific with others about that if your listeners or audience are interested.

+ +

CHAD: So when you think about a Series A, what will you be using that for? What are your next scaling goals?

+ +

NEIL: My commitment to my investors in the previous two rounds has been to sales and technology, so sales, business development, and technology enhancement to the software, so hiring more developers, scaling that team. Matt's leading the vision, and we've got a number of other folks who are involved in the user experience. But again, because we're a software company, it starts with a demonstration that's usually 15 or 20 minutes that can be scheduled through our website at mygoat.co. And it goes from there.

+ +

On the sales side and business development is telling the story. In those verticals, we're interested in building out potentially even reseller markets with other industries that are aligned with us. We've had some very high-level conversations with folks that sell electricity for a living. The Tennessee Valley Authority we became an early preferred partner with them and because they have carbon credit that they can offer and sell to their customers, their local power companies. And they're in the business of selling power. And we're in the business of providing subscriptions that require power.

+ +

CHAD: What are some barriers to continuing to scale? Do you have geographic barriers?

+ +

NEIL: I have self-imposed geographic barriers, [laughter]

+ +

So it's a Neil Amrhein barrier. But overall, our barriers, our challenges really are; I’ve never heard of these things before. Do they actually mow? So we get through those conversations fairly quickly. But depending on who we're talking to, it also becomes a fear. People fear change and especially things that are disruptive.

+ +

So our barriers, once we get through the fear, is we don't have any electricity here on this golf course, or this city park, or this regional airport that there is unlimited electricity. So we can pull whatever electricity is necessary there. So it is really the barriers of education, just like anything that's truly disruptive in an industry that's been doing the same thing for 45 or 50 years.

+ +

CHAD: So you already talked about how you view potential competition from manufacturers, but how do you view competition in general? Is there other competition out there?

+ +

NEIL: The biggest competition we have is institutionalized thinking, which is doing the same thing we did last year. So that's a battle that we have every day. I like competition because I think it makes the end product, and the customer is the one who benefits the most from having lots of people in the market no matter what their angle is.

+ +

We like our position because, again, we're not the hardware manufacturer. We're able to work with others. We're the financial advisor that gets to work with the insurance guy and everybody else, where all your money is with your college buddy who's managing it, et cetera. We're agnostic. We're putting it all together. So it benefits everybody.

+ +

And those who make and manufacture these robots get the benefit as well because it's part of the subscription process as far as that's concerned. But the more, the merrier. A lot of people come to me and say, "Well, I saw an autonomous robotic mower out on this lawn or in the neighborhood here." And that's good for us.

+ +

CHAD: Matt, I assume that being robot-agnostic means that you need to integrate with the different systems. Does that have challenges?

+ +

MATT: You know, not really. Robots are, as far as the autonomous robotic lawn mowers, they're pretty much telling us the same thing. There are status updates; there are battery updates; there are GPS coordinates. It does tend to be a pretty common data set that we're seeing. So it's been a lot easier than I thought. When you think about…data integrations are always the top challenge you have. It's worked out a lot better than we thought initially.

+ +

CHAD: Well, that's great. Has there been anything surprising the other way which was something you thought was going to be easy turned out to be a lot harder?

+ +

MATT: Yeah. We've had a manufacturer that actually had a tiered concept in their data availability. They weren't giving us all of the data that they had. They were saving it because they were running their own kind of hey, you can use home automation techniques to integrate with your residential autonomous robotic lawnmower. Hey, if it's raining at your house, we could park your robot. So they were kind of hiding some of the API from us. We were able to work through that.

+ +

But I think that goes to one of your questions about concern around competition from the manufacturers. They're really not looking at this from that niche that we're hitting, that commercial perspective.

+ +

Maintaining one Roomba in your house is the analogy I use. You kind of know where he gets stuck, and you go find him. And that's okay. You don't need a lot of software for that. But that analogy Neil mentioned, if you have 500 of these guys running around a warehouse, or for us, we have property with 50 robots on. How do you know which one right now --

+ +

CHAD: And the space that that takes up.

+ +

MATT: Right. Right.

+ +

CHAD: You can't see them all necessarily even.

+ +

MATT: [laughs] Exactly. You can't. You can't just walk around and see everyone and visually check. You need that software to be efficient to know; oh, there are three things I need to do today with the robots. Let me plan that out, and let me take care of it.

+ +

So I think, like Neil said, the manufacturers out there they're making lawn equipment. They're making lots of different hardware. And to them, fleet management is really where is my hardware right now? [laughs] That's the extent of it. And they can't think about a property that needs maybe two or three different manufacturers of hardware because properties are not one homogeneous set of type of grass. There are always different needs, different features on that property. So there's always that idea that we're going to need a couple of different manufacturers, maybe.

+ +

So, yeah, it's really interesting. For me, I think it's we're really hitting a home run in an area that there really aren't any other competitors exactly in our niche. And if there are, I think the industry for us what we do is at a place where we need more adoption out there in the world. [crosstalk 34:03]

+ +

CHAD: Do you ever hear from early adopters? People who say they've either already bought autonomous mowers and they're struggling to manage them, or they really want to, and they're coming to you to do it?

+ +

NEIL: That's a great point. I have a couple of thoughts here because you guys are going in a lot of different directions here.

+ +

MATT: [laughs]

+ +

NEIL: Chad, the short answer is when people buy anything early on, they're going to have the proverbial challenges of who supports it when it breaks? Who do I call? What happens next? It just goes on and on and on, whether it's a hardware platform, and that's mostly the case, or it's something else. It's what does that support look like?

+ +

So the early adopters when we talk about their experiences, and this is one of the things I would say is probably our biggest challenge is that we have created a learning management software platform, a video library of how do you work with robots? We know that they're going to get trapped.

+ +

There is no doubt that a 27-pound autonomous goat if there is a lightning strike like there was here in Nashville last night, they're going to be tree limbs that are down. And there'll be goats that are trapped. And it's going to take a human being, a shepherd, to be notified via SMS alert to proactively go to that spot on that property across 50 or 100 acres and rescue that goat. And it's just a matter of these kinds of things happen environmentally.

+ +

So we talk about, when we talk to customers, about their utilization of the goat. And we talk about optimizing their property. It's not really that the goat doesn't graze or the robot doesn't work. It's what are the restrictions and the environmental challenges that are in front of it? If there are erosion issues around a marker or in a large open field, and if it's a really well-groomed practice field or intramural field, it's likely going to be aerated. It's going to be very flat, et cetera. But most commercial properties are not that way.

+ +

So the goats actually have a tendency to go out, and they're going to find all those environmental challenges. And it requires a human being to go out there and fix them. Because if the environmental challenge is that there's a hole and on a horse farm, it's going to be there until somebody throws some dirt in it. It's just the reality. And that goat is going to find that environmental challenge every single time. So there is a learning curve that goes with it. There's a level of patience.

+ +

And I think you mentioned what's our challenge? Our challenge is letting folks know that it's an evolution, not a revolution, as far as what your property is going to look like. I spent a number of years at the Ritz Carlton Hotel Company, and we talk about property health as is it a two-star property, a three-star property, four-star property, five-star property?

+ +

We recognize that a lot of commercial properties are going to just be a two-star. But potentially, they could be a three-star property. Or if it's a cemetery and you've got a goat that's maybe found environmental challenges on a cemetery, it also becomes a liability or risk for family members who go visit their loved ones.

+ +

So now we're using the robot proactively to improve the status of the property as opposed to saying, well, it just gets trapped every time it finds a hole or every time there's a situation that goes on. So it does require an active level of engagement and maintenance. And the philosophy has to be changed so that groundskeepers are now checking their phones or being alerted at 7:15 in the morning. And they may go rescue Billy, the goat, because a lot of folks name their robots. [laughter]

+ +

They're going out there, and they're in pen 34,27, 31. And then at lunchtime, they may have another two or three of the same goats that were trapped, need to be rescued, and then again at 4:00 o'clock in the afternoon. So it's a maintenance mentality as opposed to a mow and go mentality. So that is philosophically a big change in terms of their mindset.

+ +

CHAD: So what's next for My Goat then? You mentioned the Series A. Is there anything in particular on your radar that you're either worried about or are looking forward to?

+ +

NEIL: Looking forward to more folks like your audience and listeners hearing our story. I'm in the business of telling our story. And I welcome, again, the competition because that means there's validation for what's going on. I don't think we're going to stuff this genie back in the bottle, so to speak.

+ +

It's going to be hard for me to believe that five, six years from now, folks are going to be out there firing up a push mower that they just bought at Lowe's when they can buy something at Lowe's that's $250 for a residential robot that they get to use.

+ +

Same thing on the commercial space. I don't know what it ultimately looks like from a vision perspective. But I think our challenge is continuing the messaging, the adoption, enhancing the payback period. It is really just like any good technology, artificial intelligence, robotics, et cetera. I mean, that combination.

+ +

I hold the position, Chad, that I don't really think any technology is being developed or new per se since the invention of the internet. It's the application of the technology. It's what are people doing that they weren't doing before?

+ +

We have the communication tools with 5G or what have you that we didn't have five or six years ago that we can now ping our goats every 15 minutes and find out what their status is. And then we can report that back to the user and say, "Hey, your optimization or utilization on your hardware and your subscription is X, Y, and Z. And your return on investment is six months to 16 months." That's where I think it elevates the conversation of efficiency and changes the game.

+ +

So our next steps are continuing to get the message out, embrace not only users but industries we haven't thought about. I mentioned horse farms that just came on my radar screen not too long ago. We've had some success with cities and counties. You can imagine…everything one of our core values is green is good, and time is a number.

+ +

So you just drive down the interstate, and you can see so much green everywhere as far as opportunities ahead. And there's plenty of room for lots of people to play in this space. We welcome more and more of probably the designers and developers that you got on this podcast to come up with the latest and greatest hardware and make those APIs available for Matt and his team to integrate and continue to grow.

+ +

CHAD: That's great. If folks want to reach out to you to either learn more or see if you can work together, where are the best places for them to do that?

+ +

NEIL: Sure. Let me first direct them to www.mygoat.co. And there are a series of areas there where it's either click on a demo now or information. Our phone number is listed there as well.

+ +

I'll also give you my email address, which is Neil, N-E-I-L neil@mygoat.co, so neil@mygoat.co. And Matt's is just matt@mygoat.co as well. And those are probably the fastest way to connect with us. And if they put in a quick subject line your name and your podcast, it'll bubble everybody to the top a little faster.

+ +

CHAD: Wonderful. Thank you both for joining me. I really appreciate it.

+ +

MATT: Absolutely. Thank you, Chad.

+ +

NEIL: Thank you for having us.

+ +

CHAD: And I wish you all the best.

+ +

You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guests: Matthew Erickson and Neal Amrhein.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Neal Amrhein is the founder and CEO and Matt Erickson is the CTO of My Goat. My Goat is a subscription mowing service for commercial properties. They use robotic mowers and elegant software tools to make turf care easy, convenient, and affordable.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is a couple of people from a company with actual robots. It's Neal Amrhein, the founder and CEO, and Matt Erickson, the CTO of My Goat. Gentlemen, thanks for joining me.

+ +

So tell me more about this idea that you are robot-agnostic? Are you helping people choose the solution that's right for them? Or do you have go-to vendors?

+ +

NEIL: We do. So my philosophy, having spent a number of years in technology selling hardware and even software solutions, is that one thing that my experience has held is that hardware gets better, faster, and cheaper.

+ +

And for us to invest in a hardware platform or have customers invest in a hardware platform, I liken it to my early adoption of high-definition televisions where in 2003, I was one of those guys that spent $2,400 on a 42-inch Sony Wega TV. And now you can get a 70-inch with a lot more technology and so forth for about $300 at Costco.

+ +

So my feeling about hardware is it gets better, faster, cheaper. It's really the software that makes the difference in terms of how you leverage it. So we engage about 6 to 12 different hardware manufacturers that make autonomous robots from robots that are 27 to 35 pounds up to 1,200 pounds and all different variations in between.

+ +

And then, we extract the communication tools so that we can help our users who are formerly the groundskeepers become technology groundskeepers. And they are now interfacing with the concept of autonomous robots that are mowing commercial properties 24/7, which we would actually call maintaining versus mowing.

+ +

So we use nighttime, you know, day, night, rain or shine. So that's why we're robot-agnostic and welcome the latest and greatest designers and developers of hardware. We've got some folks that are just totally focused on designing, and developing, and building awesome autonomous robotic mowers with solar panels or great things that are going out there. And we're the software platform that brings it all together.

+ +

CHAD: I totally get what you're saying about the progress of hardware and wanting to be in the business of creating value on top of that. How do you make sure that you don't take on the business risk of one of the manufacturers just providing the solution that you're providing?

+ +

NEIL: Chad, we don't look at a business risk if there's a manufacturer that's going and selling autonomous robotic mowers. We welcome that, in fact, because that helps us with the adoption process.

+ +

The idea of having, you know, Roomba is the de facto vacuum cleaner that goes randomly in your house. But there are half a dozen other hardware devices and opportunities, and they're all selling it. It's really how are you managing that Roomba? Which is also the subscription component of the Netflix part of our business, which is that Roomba may be a shark next year. It may be something else the following year.

+ +

For our customers, we select the best hardware for their particular property, whether it's a golf course. They may have an autonomous robot that's manufactured by XYZ for the tee box and another one for the fairway, and another one for the greens. They just pay a monthly subscription for access to the software to manage those particular hardware pieces and optimize that hardware. And that's something that Matt will talk a little bit about.

+ +

But we really have taken the approach that robots are just like cars. They'll sit in your garage 20 hours out of the week, but they're actually effectively useful 168 hours a week. So how do we maximize that and utilize the hardware itself? And that's what our software does. And of course, with that, we share that information with our customers and our users to continue to make it more efficient.

+ +

CHAD: Thanks, Neil. Matt, what does the software stack actually look like that you're all putting together?

+ +

MATT: So we got to talk about the technology so Laravel, PHP, MySQL. We host in DigitalOcean. And we have a WordPress front end, but the back end is all Laravel PHP.

+ +

CHAD: And so it's in the cloud for all the customers?

+ +

MATT: Yes.

+ +

CHAD: And then how do you communicate with the fleet?

+ +

MATT: So we connect through APIs. The hardware generally has an API that can give us status updates at various intervals. So we aggregate that information back. And then, we present a web-based solution dashboard that includes different views.

+ +

We can get into the different users and how we've tried to meet their needs and drive workflow for them. But at a high level, we've got some graphical dashboards. And we also have some very tactical workflows for the guys. We call them shepherds taking care of our goats on the ground.

+ +

CHAD: I know that you said it's autonomous, but how do you communicate with the robots when you need to? Is it radio frequency locally, or is it cell phones?

+ +

MATT: So the robots actually come with…they have both GPS and cellular connectivity. So we have pretty good real-time connectivity with the robots. So we can remotely control them. We can park them, or we can send them back to their charging stations, different features like that. You can adjust cutting height, things like that, remotely. We also use just text messaging, SMS for communicating with shepherds. It's kind of real-time feedback.

+ +

So yeah, let me dig in a little bit, the autonomous idea of the robot. Yeah, we want them to be autonomous. And we work with our shepherds, groundskeepers so that each of the goats works in a pen, an area defined by that in the ground kind of like an invisible fence dog wire type thing.

+ +

But basically, we work with the shepherds, and we have this training certification process. But basically, they can get that pen to an area where really what we shoot for about 72 hours of the robot should be able to operate autonomously within that pen for about three and a half days.

+ +

And then shepherds will be instructed to move that robot to another pen for about three and a half days. Usually, one robot is taking care of…it ends up being about two and a half days. And that's kind of the way the software solution is driving that efficiency of people time as well as robot time.

+ +

The robots can mow 24/7. They take care of the grass. They maintain it, as Neil mentioned earlier. So it's not throw the robot out once a week kind of thing. You have to change your thinking. A lot of what we deal with when we go to a robot solution over that traditional status quo mowing we really have to help people through that thought process of this is not how it used to be. It works differently. But yep, that's kind of the solution.

+ +

CHAD: I feel like I need to ask, even though it's going to be a little bit of a tangent.

+ +

MATT: [laughs]

+ +

CHAD: How did you arrive at the name of My Goat and take the leap on a quirky name like that?

+ +

NEIL: Yeah, it's a great question. [laughs] First of all, I think that I first saw one of these robots through a YouTube video about three and a half or four years ago. And you may or may not know this, Chad, but there are about 3 million of these things that have been sold since 1995. So this is not bleeding edge technology in any way, shape, or form.

+ +

When I saw it on a YouTube video, it just kind of hit me that wow, these things are out there doing their thing day or night, rain or shine. And interestingly enough, the market, I guess the landscape market, the residential side, was somewhere in the neighborhood of $65 to $80 billion that we were targeting and looking at.

+ +

And as far as the goats, I had talked to some early folks who were marketing folks, and we just settled on Goat. And then we put my on the front end of it. And before we knew it, we had My Goat. And as we've evolved from just a cool robot-centric organization that's using software, we've evolved into an organization that's really teaching shepherds how to become interactive with the goats. And it's taken a life of its own. The blades are called teeth.

+ +

CHAD: [laughs]

+ +

NEIL: And those are some of our…of course, the goats need to be brushed. They don't get washed, or they don't get sprayed down with water, but they get brushed. And there's the whole the operating system is the heart and all kinds of stuff that's been going on.

+ +

CHAD: Well, I feel like with a name like My Goat, if you're not going to commit and carry that branding through to everything, what's the point?

+ +

[laughter]

+ +

NEIL: Right. Yes, it has taken a life of its own. And it's interesting. I don't know that it's the most catchy name for a software technology company. But it's certainly gotten some folks' attention, and it's helped. Let's put it this way: our marketing team really enjoys everything about what they can do with it.

+ +

CHAD: Well, and there's something to having a brand and carrying that through in the naming that causes ideas to resonate with people and makes them special. At the end of the day, you're mowing lawns. And so making it special and communicating that you have something special, I think, is something that people can do regardless of what their product is thinking of ways of doing that.

+ +

NEIL: Yeah. And I would add that I think the only pushback we've received on the name is probably from some of our high-end golf course users and prospects who don't want to turn their golf course into a goat track, so to speak.

+ +

CHAD: [laughs]

+ +

NEIL: But that's probably the extent of it. But overall, it's been well received without a doubt. And as we're focused on the software component of interacting with autonomous robots, our software development mentality and our vision is that it may be the same thing applied to 500 Roombas inside of a million square feet at a fulfillment center for Under Armour.

+ +

And instead of having 50 people cleaning the floors, you may have five people managing 500. And how do they do that effectively and efficiently? So there's really a business-focused component of the vision that I've had for the business. And that's helped me, along with many others, to get us to where we are.

+ +

MATT: I'm just going to jump in. You're right; the name sticks and people really adopt to the shepherd mentality. We get a lot of requests for shepherd crooks. [laughs] They all want a shepherd staff.

+ +

CHAD: So along those lines, when people are considering working with you, what are some of the questions or concerns that they have about a solution?

+ +

NEIL: Sure. So it's disruptive, Chad. I think I could probably start by saying the traditional way of maintaining or mowing commercial properties is that you have a big guy and a big machine, and how fast does it go? How much noise does it make? How many grass clippings get blown all over the place? You get in, and you get out. And then you start over.

+ +

So in the state of Tennessee, where we are here, it's about 34 to 36 weeks of mowing a year. In Michigan, it's 17 to 22 weeks, depending on where you are. In South Florida, believe it or not, I know there are only 52 weeks, but they're mowing 56 to 58 times a year. So it's the frequency of going and mowing and blowing, right?

+ +

CHAD: Mm-hmm.

+ +

NEIL: We're changing that by saying, why be worried about the weather? Why would you be worried about darkness? Why would you be worried about noise regulations when you can have the grass maintained all the time?

+ +

So that mentality of maintaining essentially two football fields a week up to three football fields a week with less than 35 minutes of labor. There is nothing in comparison. There's nothing you can compare with the traditional what we call the status quo to make that happen.

+ +

So the labor efficiency and improvement in labor productivity is just the tip of the iceberg in terms of the cost savings and the financial payback. So because we are so disruptive, a lot of what we do, and a lot of the time we spend, and one of our core values is being educators.

+ +

So back to your question about manufacturers selling their own proprietary hardware; absolutely, the more the merrier. We welcome. To me, the sign of success and progress is not the small city block that has one gas station but has four gas stations on the corner. It just now means there are cars that are driving around. And so, I embrace that level of competition. I believe iron sharpens iron.

+ +

And folks who are traditionally in the landscape space who have made trimmers and blowers and chainsaws are now finding a little bit of competition with folks who are now solely focused on making unbelievably efficient autonomous robotic mowers, or cleaners, or robots in general, which is, again, we're not crashing giant robots although that's the name of your podcast. [laughter] We're not trying to crash them or break them. But it is certainly the foundation for where we are.

+ +

MATT: Hey, Neil, you've got a good analogy. I think analogies help explain concepts. So you want to run through your airport analogy with the runways and the different airlines?

+ +

NEIL: Yeah, I could share that with you. Thanks for reminding me. So my philosophy about…we sell subscriptions that are based upon a geography, Chad.

+ +

CHAD: Size of geography, you mean?

+ +

NEIL: Yeah, the size of the geography. So it's about a football field, give or take. Based upon some limitations with technology, we put invisible dog fences in the ground, and we charge our users, our subscribers by the particular pen or the number of pens, and then there's a ratio.

+ +

So much like in an airport, we're not selling flights; we're selling runways. And those runways are accessible by all kinds of…you may have 30 terminals at the gates, and you may have five different airlines. And each of those airlines has a different brand and name, but they're using multiple hardware components. Those jets are maybe McDonnell Douglas, or maybe they're a Boeing or whatever it may be. All of that is fine by us.

+ +

What we do is we have the software that runs the gates, the terminals. So you have Southwest in terminal two and Delta in terminal 32. And they're using our software to figure out how to get the baggage on the planes and get those planes off the ground so they can make money for their businesses. So we look at it that way.

+ +

And that's kind of where our IP rests is in that spot in that place. And, again, there'll be other airlines, whether it's Allegiant or whomever buying more Boeing planes. But ultimately, they'll all need a runway, and the software that manages the process and the workflow is what we're focused on.

+ +

CHAD: So, is the total cost of ownership of autonomous solution typically lower than what they are doing today?

+ +

NEIL: It is, specifically, the labor improvement is generally about 3x in terms of improving the efficiency of the labor. So if you talk about an average groundskeeper who may be responsible for mowing, if it's a perfect day outside mowing nine acres a day and they are out there five days a week, they may have efficiencies of maybe up to 40 or 45 acres a week. With our solution, that is increased to about 135 to 145 acres a week where they can maintain about 70 mowers, 70 autonomous robotic mowers, or 70 goats as we call them. They'll herd 70 goats with the same full-time employee. So that's one aspect.

+ +

With that, the immediate reaction is, well, you're eliminating jobs. We're actually redeploying jobs. I'm a builder. I'm a job creator. I've had 4,800 folks work for me in my home care business over the last 12 years. And so, I'm a big believer in improving and deploying folks in areas that we don't have robots.

+ +

So, for example, there's no robot right now that's pruning trees or making up a sand trap, robots that are planting flowers or putting mulch in a flower bed. So those kinds of jobs are still out there. We're just making the traditional idea of throwing somebody on a mower in the middle of a cemetery or golf course or open space and having them manage that through our software platform sitting in their F150 pushing start and stop or pause and doing other things.

+ +

CHAD: Instead of riding on the mower.

+ +

NEIL: You got it.

+ +

MATT: A lot of our potential customers come to us because (we kind of touched on that) there's a labor shortage. It's hard for folks to find people that want to ride zero-turns. So to Neil's point, we're not about deploying robots, kind of one for one replacing jobs. It's basically we're taking the labor force that we can get, that we have, and we're retraining them to be more efficient through these robots. Pretty age-old story when you're talking about industrialization.

+ +

But the idea is we haven't displaced workers. They're not hiring fewer people. They're taking everybody they can get. And they're doing all of that value add. The groundskeepers now have time to go out and do the mulching and the landscaping, trimming, improving the property.

+ +

A lot of these groundskeepers have a lot of pride in their property. And they would rather be doing the items that to them are a value add and beautification projects rather than just riding a Back 40 or a zero-turn. We had one shepherd say, hey, it's really helped his back. Riding a lawnmower is kind of rough. And walking around every now and then helping out a robot is a whole lot easier of a physical life for you.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So I saw on the website because of the kind of solution and the scale that it's at, it seems like you have a few different key customer bases. You want to talk about that and whether you knew that going in, or did you find them along the way?

+ +

NEIL: Yeah, that's a great question. So we came out of the gate initially with early investors. We were focused on what we considered was the low-hanging fruit in the residential space. So we had designed and developed the operational and financial template to actually have shepherds who were employees of My Goat. And we would have the Goats sold in a subscription model to residential customers. And then we'd have the goat stay on a property and then get moved, et cetera.

+ +

But we learned very quickly that business to consumer and residential customers it's not that impossible; it just was not as low-hanging fruit as we had thought initially because folks leave rakes in the yard. And anytime a goat comes upon a rake, it's going to get trapped, and therefore it needs to be rescued. And you have to send a shepherd out, et cetera. Or somebody decides to put a new vegetable garden, and they break the wire that's in the ground. They're just a bunch of…, or there's a dog chasing the robot or a little kid out there, or somebody stops it. So those required a lot of…it didn't make the robot autonomous.

+ +

So we pivoted in late 2019, early 2020 into the commercial space. We expired all of our subscriptions to residential customers and went completely into the commercial space. And we had had some success with some golf courses and some cemeteries. And we've gained a lot more momentum now with cities and counties, regional airports. But large open areas that are a minimum of five acres, typically we would run a pilot or a preview with at least 12 to 14 acres.

+ +

But the biggest restriction, of course, when you get into those large open areas is electricity because they've been traditionally maintained or mowed by gas-powered machines. So back to your other question about where the savings is and the payback period, and how we have an immediate impact. There's an operational savings that is pretty quick in terms of the return because we flatten out a lot of the ups and downs that a traditional landscaper has.

+ +

So let's take a golf course, for example. The average golf course spends about $80,000 per hole per year and depending on the course, 45% to 60% of that is spent on mowing, mowing machines, and people involved. And we're able to take that, and they're hiring temporary people in March here in the south, and they have them here until October. So they're having to go through that cycle every single year.

+ +

So if they can flatten that operational expense out by redesigning the golf course and having…and maybe it's not 100%. Much like a Roomba, you still have to get the corners and the edges, maybe with a broom if it doesn't get into every nook and cranny. So it's not a 100% solution. It's not for every application.

+ +

But as we moved into the commercial space, we found a greater payback period not only on the cost of the gasoline is...you know, take a zero-turn mower. And again, I say that's probably our greatest competitor is institutionalized thinking to say, this year we're going to buy a big green, big red, or big orange machine for $16,000 or $18,000, Kubota, Toro, or John Deere. And we're going to do the same thing we did last year. We're going to find a guy who can operate it. We're going to put gas in it, and we're going to run it around.

+ +

Well, you put hours in those things, and they're very costly to maintain if you hit a root. So you've got to make sure that you can't run a 1,800-pound mower when it's been raining for three days. So what do you do with a fairway when it's soggy or any other commercial area that could be…or a hill that could be dangerous. So we've found a lot of application and then, of course, the environmental part of it, Chad.

+ +

So the average zero-turn emits the equivalent of a carbon footprint every hour it's running about 300 miles of a Toyota Camry running. So they haven't become more efficient. And then you've got noise regulations and so forth in a lot of communities.

+ +

And even in California, they're moving in the direction of I think it's 2024 where gas-powered and oil-powered landscaping blowers and tremors, et cetera, are not going to be allowed, or you'll be fined for using them. So that's the third component of where My Goat has seen some opportunities in the commercial space.

+ +

CHAD: You mentioned that they can run at night. So they must be quiet. They must be.

+ +

NEIL: Yes, they are. And it's not the traditional…you're not making as much of a mess. Some of our cemetery customers have mentioned that the fact that their trimming has been reduced by up to 50% because they're going up and over markers because they only weigh 27 pounds. They're mostly plastic and rubber. They're not doing any damage to vases. So they're having a cost reduction in that regard but also with the uprights.

+ +

Folks have their family members in a particular private estate area where they may have an upright, and if you have a zero-turn mower out there throwing and splashing grass clippings, you're likely having to go out there again with more labor and take a blower and clean up the mess that the mower made. So these little small operational components along with the experience.

+ +

Again, back to the cemetery, you're asking about why we're there. We know that industry very well. And we know that the experience that loved ones want to have when they're out there celebrating life and grieving across a 40 or 50-acre property. They don't want to hear a zero-turn.

+ +

So you're turning those things off three or four times a day for those services, and you're having that individual parked a quarter-mile away. No longer is that an operational challenge or a concern because all of these robots are being controlled, start, stopped, and programmed through our software.

+ +

CHAD: That's really cool. So you mentioned investors and the early pivot away from residential to commercial. What does your funding story look like? And what phase did you get to when you took on investment? And let's start there. How did you find your initial investors? And what phase were you at when you did that?

+ +

NEIL: Yeah, that's a great question. So we went through the traditional friends and family and moved into an angel round, but really I started my first company…bootstrapped it. And so, I wasn't really proficient in raising money in the traditional sense. I had an idea, put a business plan together.

+ +

And I talked to a couple of folks and just told the story. To be honest with you, Chad, I wasn't really asking for money. I was more or less asking for advice. And then a number of folks were like, "Are you taking money? I'd like to take an equity position." And so, we structured the business and the shares on a pre-revenue valuation. And then, within 14 months, we were able to double that valuation.

+ +

And we're now opening a new round here and a Series A with a valuation that's nearly five times our initial valuation. So we're making a lot of progress because we have, again, it's an annual recurring revenue stream. It's a subscription model.

+ +

And what we did with our investors in the early rounds is many of them came on, and they just wanted to be silent. They were not interested in having an opinion. They wanted me and my team to run it. So that's been very helpful. So that's where we are in 2022. We'll be opening and closing a Series A. And I certainly can get more specific with others about that if your listeners or audience are interested.

+ +

CHAD: So when you think about a Series A, what will you be using that for? What are your next scaling goals?

+ +

NEIL: My commitment to my investors in the previous two rounds has been to sales and technology, so sales, business development, and technology enhancement to the software, so hiring more developers, scaling that team. Matt's leading the vision, and we've got a number of other folks who are involved in the user experience. But again, because we're a software company, it starts with a demonstration that's usually 15 or 20 minutes that can be scheduled through our website at mygoat.co. And it goes from there.

+ +

On the sales side and business development is telling the story. In those verticals, we're interested in building out potentially even reseller markets with other industries that are aligned with us. We've had some very high-level conversations with folks that sell electricity for a living. The Tennessee Valley Authority we became an early preferred partner with them and because they have carbon credit that they can offer and sell to their customers, their local power companies. And they're in the business of selling power. And we're in the business of providing subscriptions that require power.

+ +

CHAD: What are some barriers to continuing to scale? Do you have geographic barriers?

+ +

NEIL: I have self-imposed geographic barriers, [laughter]

+ +

So it's a Neil Amrhein barrier. But overall, our barriers, our challenges really are; I’ve never heard of these things before. Do they actually mow? So we get through those conversations fairly quickly. But depending on who we're talking to, it also becomes a fear. People fear change and especially things that are disruptive.

+ +

So our barriers, once we get through the fear, is we don't have any electricity here on this golf course, or this city park, or this regional airport that there is unlimited electricity. So we can pull whatever electricity is necessary there. So it is really the barriers of education, just like anything that's truly disruptive in an industry that's been doing the same thing for 45 or 50 years.

+ +

CHAD: So you already talked about how you view potential competition from manufacturers, but how do you view competition in general? Is there other competition out there?

+ +

NEIL: The biggest competition we have is institutionalized thinking, which is doing the same thing we did last year. So that's a battle that we have every day. I like competition because I think it makes the end product, and the customer is the one who benefits the most from having lots of people in the market no matter what their angle is.

+ +

We like our position because, again, we're not the hardware manufacturer. We're able to work with others. We're the financial advisor that gets to work with the insurance guy and everybody else, where all your money is with your college buddy who's managing it, et cetera. We're agnostic. We're putting it all together. So it benefits everybody.

+ +

And those who make and manufacture these robots get the benefit as well because it's part of the subscription process as far as that's concerned. But the more, the merrier. A lot of people come to me and say, "Well, I saw an autonomous robotic mower out on this lawn or in the neighborhood here." And that's good for us.

+ +

CHAD: Matt, I assume that being robot-agnostic means that you need to integrate with the different systems. Does that have challenges?

+ +

MATT: You know, not really. Robots are, as far as the autonomous robotic lawn mowers, they're pretty much telling us the same thing. There are status updates; there are battery updates; there are GPS coordinates. It does tend to be a pretty common data set that we're seeing. So it's been a lot easier than I thought. When you think about…data integrations are always the top challenge you have. It's worked out a lot better than we thought initially.

+ +

CHAD: Well, that's great. Has there been anything surprising the other way which was something you thought was going to be easy turned out to be a lot harder?

+ +

MATT: Yeah. We've had a manufacturer that actually had a tiered concept in their data availability. They weren't giving us all of the data that they had. They were saving it because they were running their own kind of hey, you can use home automation techniques to integrate with your residential autonomous robotic lawnmower. Hey, if it's raining at your house, we could park your robot. So they were kind of hiding some of the API from us. We were able to work through that.

+ +

But I think that goes to one of your questions about concern around competition from the manufacturers. They're really not looking at this from that niche that we're hitting, that commercial perspective.

+ +

Maintaining one Roomba in your house is the analogy I use. You kind of know where he gets stuck, and you go find him. And that's okay. You don't need a lot of software for that. But that analogy Neil mentioned, if you have 500 of these guys running around a warehouse, or for us, we have property with 50 robots on. How do you know which one right now --

+ +

CHAD: And the space that that takes up.

+ +

MATT: Right. Right.

+ +

CHAD: You can't see them all necessarily even.

+ +

MATT: [laughs] Exactly. You can't. You can't just walk around and see everyone and visually check. You need that software to be efficient to know; oh, there are three things I need to do today with the robots. Let me plan that out, and let me take care of it.

+ +

So I think, like Neil said, the manufacturers out there they're making lawn equipment. They're making lots of different hardware. And to them, fleet management is really where is my hardware right now? [laughs] That's the extent of it. And they can't think about a property that needs maybe two or three different manufacturers of hardware because properties are not one homogeneous set of type of grass. There are always different needs, different features on that property. So there's always that idea that we're going to need a couple of different manufacturers, maybe.

+ +

So, yeah, it's really interesting. For me, I think it's we're really hitting a home run in an area that there really aren't any other competitors exactly in our niche. And if there are, I think the industry for us what we do is at a place where we need more adoption out there in the world. [crosstalk 34:03]

+ +

CHAD: Do you ever hear from early adopters? People who say they've either already bought autonomous mowers and they're struggling to manage them, or they really want to, and they're coming to you to do it?

+ +

NEIL: That's a great point. I have a couple of thoughts here because you guys are going in a lot of different directions here.

+ +

MATT: [laughs]

+ +

NEIL: Chad, the short answer is when people buy anything early on, they're going to have the proverbial challenges of who supports it when it breaks? Who do I call? What happens next? It just goes on and on and on, whether it's a hardware platform, and that's mostly the case, or it's something else. It's what does that support look like?

+ +

So the early adopters when we talk about their experiences, and this is one of the things I would say is probably our biggest challenge is that we have created a learning management software platform, a video library of how do you work with robots? We know that they're going to get trapped.

+ +

There is no doubt that a 27-pound autonomous goat if there is a lightning strike like there was here in Nashville last night, they're going to be tree limbs that are down. And there'll be goats that are trapped. And it's going to take a human being, a shepherd, to be notified via SMS alert to proactively go to that spot on that property across 50 or 100 acres and rescue that goat. And it's just a matter of these kinds of things happen environmentally.

+ +

So we talk about, when we talk to customers, about their utilization of the goat. And we talk about optimizing their property. It's not really that the goat doesn't graze or the robot doesn't work. It's what are the restrictions and the environmental challenges that are in front of it? If there are erosion issues around a marker or in a large open field, and if it's a really well-groomed practice field or intramural field, it's likely going to be aerated. It's going to be very flat, et cetera. But most commercial properties are not that way.

+ +

So the goats actually have a tendency to go out, and they're going to find all those environmental challenges. And it requires a human being to go out there and fix them. Because if the environmental challenge is that there's a hole and on a horse farm, it's going to be there until somebody throws some dirt in it. It's just the reality. And that goat is going to find that environmental challenge every single time. So there is a learning curve that goes with it. There's a level of patience.

+ +

And I think you mentioned what's our challenge? Our challenge is letting folks know that it's an evolution, not a revolution, as far as what your property is going to look like. I spent a number of years at the Ritz Carlton Hotel Company, and we talk about property health as is it a two-star property, a three-star property, four-star property, five-star property?

+ +

We recognize that a lot of commercial properties are going to just be a two-star. But potentially, they could be a three-star property. Or if it's a cemetery and you've got a goat that's maybe found environmental challenges on a cemetery, it also becomes a liability or risk for family members who go visit their loved ones.

+ +

So now we're using the robot proactively to improve the status of the property as opposed to saying, well, it just gets trapped every time it finds a hole or every time there's a situation that goes on. So it does require an active level of engagement and maintenance. And the philosophy has to be changed so that groundskeepers are now checking their phones or being alerted at 7:15 in the morning. And they may go rescue Billy, the goat, because a lot of folks name their robots. [laughter]

+ +

They're going out there, and they're in pen 34,27, 31. And then at lunchtime, they may have another two or three of the same goats that were trapped, need to be rescued, and then again at 4:00 o'clock in the afternoon. So it's a maintenance mentality as opposed to a mow and go mentality. So that is philosophically a big change in terms of their mindset.

+ +

CHAD: So what's next for My Goat then? You mentioned the Series A. Is there anything in particular on your radar that you're either worried about or are looking forward to?

+ +

NEIL: Looking forward to more folks like your audience and listeners hearing our story. I'm in the business of telling our story. And I welcome, again, the competition because that means there's validation for what's going on. I don't think we're going to stuff this genie back in the bottle, so to speak.

+ +

It's going to be hard for me to believe that five, six years from now, folks are going to be out there firing up a push mower that they just bought at Lowe's when they can buy something at Lowe's that's $250 for a residential robot that they get to use.

+ +

Same thing on the commercial space. I don't know what it ultimately looks like from a vision perspective. But I think our challenge is continuing the messaging, the adoption, enhancing the payback period. It is really just like any good technology, artificial intelligence, robotics, et cetera. I mean, that combination.

+ +

I hold the position, Chad, that I don't really think any technology is being developed or new per se since the invention of the internet. It's the application of the technology. It's what are people doing that they weren't doing before?

+ +

We have the communication tools with 5G or what have you that we didn't have five or six years ago that we can now ping our goats every 15 minutes and find out what their status is. And then we can report that back to the user and say, "Hey, your optimization or utilization on your hardware and your subscription is X, Y, and Z. And your return on investment is six months to 16 months." That's where I think it elevates the conversation of efficiency and changes the game.

+ +

So our next steps are continuing to get the message out, embrace not only users but industries we haven't thought about. I mentioned horse farms that just came on my radar screen not too long ago. We've had some success with cities and counties. You can imagine…everything one of our core values is green is good, and time is a number.

+ +

So you just drive down the interstate, and you can see so much green everywhere as far as opportunities ahead. And there's plenty of room for lots of people to play in this space. We welcome more and more of probably the designers and developers that you got on this podcast to come up with the latest and greatest hardware and make those APIs available for Matt and his team to integrate and continue to grow.

+ +

CHAD: That's great. If folks want to reach out to you to either learn more or see if you can work together, where are the best places for them to do that?

+ +

NEIL: Sure. Let me first direct them to www.mygoat.co. And there are a series of areas there where it's either click on a demo now or information. Our phone number is listed there as well.

+ +

I'll also give you my email address, which is Neil, N-E-I-L neil@mygoat.co, so neil@mygoat.co. And Matt's is just matt@mygoat.co as well. And those are probably the fastest way to connect with us. And if they put in a quick subject line your name and your podcast, it'll bubble everybody to the top a little faster.

+ +

CHAD: Wonderful. Thank you both for joining me. I really appreciate it.

+ +

MATT: Absolutely. Thank you, Chad.

+ +

NEIL: Thank you for having us.

+ +

CHAD: And I wish you all the best.

+ +

You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guests: Matthew Erickson and Neal Amrhein.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pk-sU8B8 + + ]]> + + Chad Pytel + Matthew Erickson + Neal Amrhein + + + 403: Mission Control with Joe Ferris + https://podcast.thoughtbot.com/403 + 1957a0ca-fc15-4376-a3e1-4ebab71bf6bb + Thu, 09 Dec 2021 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Joe Ferris is thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Mission Control is our newest team doing DevOps Support, Maintenance, and SRE (Site Reliability Engineering). The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, is to support those teams and support other client teams in deploying and scaling applications. They have an on-call team and do more complex cloud build-outs with the goal being to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own. + 34:04 + no + + + Joe Ferris is thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Mission Control is our newest team doing DevOps Support, Maintenance, and SRE (Site Reliability Engineering). The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, is to support those teams and support other client teams in deploying and scaling applications. They have an on-call team and do more complex cloud build-outs with the goal being to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own. +Follow Joe on Twitter (https://twitter.com/joeferris) or LinkedIn (https://www.linkedin.com/in/joe-ferris-81421a167/). +thoughtbot's Mission Control team (https://thoughtbot.com/mission-control) +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Joe Ferris, thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Joe, welcome back to the show. +JOE: Thanks, Chad. It's been a while. +CHAD: It has been a while. I think you were the first-ever guest, if I'm not mistaken. +JOE: I believe that's right. We talked about null, I think. +[laughter] +CHAD: Yeah. And it would have been with Ben back when I was just a listener and maybe producer. So welcome back to the show. It's been a long time, and a lot has changed at thoughtbot over the years. I've been talking to each of the managing directors of the new teams, and I wanted to be sure to have you on. Why don't we take a little bit of a step back and talk about Mission Control? When we say DevOps and maintenance, what do we mean? And what does Mission Control do? +JOE: Sure. Mission Control is our newest team doing DevOps support, and maintenance, and SRE. It came out of our experiments with DevOps a while ago now, almost two years coming up. Historically, thoughtbot has shied away from getting too much into DevOps. I think a lot of us had some unpleasant experiences earlier in our career around sysadmin tasks and expectations there. Not a lot of people have wanted to be on call historically. +So we've heavily leveraged services like Heroku that take a lot of that burden away from you and avoided doing things like direct to AWS deployments or getting too involved with CI/CD pipelines that were particularly complex. But we've had clients over the years that have requested more interesting or more difficult deployments. +And finally, we had one a couple of years ago, where we said, "All alright, let's just handle this instead of saying no or trying to outsource it." We thought it made sense for them. And after going through it, we came to the conclusion that it was actually pretty good that the ecosystem had evolved a lot and that it was a service worth offering. That began our journey into DevOps, so to speak. So we did some smart DevOps work for a variety of clients over the next year or so before we decided to form an official team doing this new kind of work, which is how we ended up with Mission control. +The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, the goal of Mission Control is to support those teams and support other client teams in deploying and scaling their applications. And we have an on-call team. We will do more complex cloud build-outs. And our goal is to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own. +CHAD: You used the acronym SRE earlier in that little spiel. I'm not sure that everyone knows what that is. [laughs] So it stands for Site Reliability Engineer, right? +JOE: That's right. And that's been newer for us. So DevOps is supposed to be the fusion of development and operations. But the operations world is really big. So similar to how everybody has problems getting people to be full-stack enough given the complexity of front end and back end, we have similar problems in design. +We also have that problem in DevOps where both development and operations are huge, rich ecosystems. And so, having developers that are fully experienced at both is hard. So the path of least resistance, when you say are doing DevOps, is definitely just to do operations. And it's been a struggle for us to actually break down those silos and have teams work more on the operation side on their own. +So one of the things that caught our eye with SRE was some of the built-in mechanisms for engaging with the team. The one-sentence pitch for SRE is that it is operations if you approach it like a software problem. It has these concepts of SLOs, Service Level Objectives, and error budgets, which is the amount of time you spent violating your SLO. And part of the process is getting buy-in from the entire team, from the stakeholders down to the developers and the operations team. And so, it provides a natural interaction point between the operations folks and the rest of the team because nobody wants to break the error budget. Once the error budget is exhausted, everybody has to stop building new features and focus on stability until the error budget is cut up again. +So rather than having this unpleasant give or take where we're more coming from the operations side, and we're always pushing for more stability, and everybody else is coming from the product side, and they're always pushing for more features, SRE gives you this useful metric to have that conversation around where we're not always just pushing for more. We're trying to hit a specific goal that we've agreed on. And when we hit the goal, we know that we can keep full throttle moving out new features. +CHAD: Now, is the SRE a developer who is also working on resolving errors before the budget is hit? +JOE: Yeah, a Site Reliability Engineer is a developer. But that's actually not too different from other forms of DevOps. DevOps is supposed to be developers in general. When I say we built an operations team, even if you look at the work that we're doing, a lot of it is development work. We build scripts, and automations, and so on. We don't manually set up EC2 instances, and not everything is toil, even outside of SRE. +But the idea in SRE is that somebody will be more integrated with the development team and make changes to not just the operational stack but also the development stack in service of reliability. I've heard it said that SRE is a particular implementation of DevOps. That makes sense to me. +CHAD: Let's start back in the beginning because you made reference to the fact that historically, a lot of what we deploy was deployed to Heroku. And we did that because, for a lot of the applications that we're building, it made sense. It minimized the operational overhead of deployments. There is a point in some systems that you cross a line. Where do we see that line typically being where you need to start looking at something else? +JOE: I think there can be a few different instigating factors. One of the fastest ways for somebody to want to move to AWS is if they have significant security concerns, particularly for healthcare applications. The security model is more straightforward in AWS to have better isolation. There are options on Heroku, but it requires going to a different Heroku platform using Shield. And you just don't get the same power you get in terms of network isolation models you get on AWS with your own VPC. +So if you're already at the point where you want to start out with a VPC out of the gate and do that kind of isolation, my opinion is you may as well own it and go to AWS. So that's one reason. Another is if you start hitting scaling issues, Heroku is easier for the developers because it's simple and it's very streamlined. But doing complex deployments is difficult, which eliminates some of the options available to somebody doing something like SRE. +So to give one example, one mechanism people can use to make it safer to deploy without potentially introducing bugs or performance degradations is a canary release where when you release, you put the new version out as the canary build. And you route maybe 5% of traffic to that, and you actually collect metrics on performance and error rates on the canary traffic versus the regular traffic. +And then you have some period where you're in experiment mode, which varies depending on the level of stability you're looking to achieve. Once you're confident that the canary release didn't introduce a regression, then it gets promoted to the stable build, and you do that every time you deploy. I have no idea how you would do that on Heroku. +CHAD: I think you'd have to do it at the application level. You'd have to do it with a feature flag system. And it would only be possible to do some of the things that you would be able to do if you're able to do the whole system. +JOE: Right. And I guess you could do weighted random numbers to try and decide whether to canary or not. But one of the benefits of doing it outside the application is there's no way to make a mistake. So, for example, if you introduced a bug in your canary mechanism in the application or you forget to put it behind a feature flag, then you've now deployed to production, and you have an error. Whereas if it's managed by the CI/CD pipeline, you're just deploying a new version of the application. In Heroku land, that would mean you deploy the new slug as a canary build. In most other areas, it means you're deploying a container image. +That's one example of why if you get to the point that you have a lot of traffic in production and you need to manage that traffic while continuing to release features, it can be helpful to work on a platform like AWS where you have a lot more deployment options. +Another one is that SRE is heavily built on observability and metrics, which can be difficult to collect on Heroku. Some of that is just a matter of lineage. Like, the SRE community was built up around tools like Prometheus that are scrape-based. That means you need to have a special metrics endpoint exposed on all of your containers. +In Heroku, there isn't a way to access any of your dynos directly except through the web router, and you can't control which one you get. So using Prometheus on Heroku is not really practical, which means you need to re-implement what everybody else has built for SRE using a different observability tool. +And observability out of the box on Heroku it's easy to get set up, but it's more limited. So doing something like complex SLOs and setting up error budget dashboards and alerting is going to be a significant task. Versus on a platform like Kubernetes where it doesn't sound like it'll be easier, but it is because there are open-source tools that you can just deploy. +CHAD: You mentioned Kubernetes. It's probably worth calling out that that's pretty much what we are using across the board, right? +JOE: For our AWS and other cloud deployments, we have standardized largely on Kubernetes. We started out using simpler containerization platforms like ECS on AWS. But what we found is that the developer tooling is generally not particularly good because there's not enough community momentum behind any of those. And the open-source is limited versus something like Kubernetes there's a massive open-source community. +There is a ton of different tooling that people build that's available for developers and for DevOps. And for these things like SRE, you can use almost entirely open-source software to build out all of the interesting parts of that and deploy that. So what we've been building is basically an SRE Platform as a Service where we collect these open-source components. We deploy them to a managed Kubernetes cluster. And then, applications can immediately start exposing metrics to Prometheus and defining SLOs. +CHAD: So much in the same way where we talked about some of the boundaries where it starts to make sense to not be on Heroku, what are some of the boundaries that teams hit where it makes sense to start thinking about SRE or even just having someone on the team that's focused on that kind of work? +JOE: I think as soon as people start hitting their first scaling challenges. So for an MVP where you're validating a product where you don't actually have production traffic yet, I don't think it makes sense. And I also think I would avoid deploying to something like Kubernetes if you can help it for an MVP. +But for anybody who has scaling concerns, SRE is a very useful mindset. And the sooner you start adopting it, the sooner you'll start to build an application that's made to scale. It can be very difficult to put out those fires while something is not on a platform where you have many options, and nobody has been thinking about observability. It means that you need to be guessing at how to put out the fire as well as simultaneously introducing metrics and potentially planning a cloud migration. +So I think as soon as you start feeling nervous about deploying to production or as soon as you notice that you're spending a lot of time working on performance, it makes sense to bring in SRE. I also think anybody that needs to provide an SLA should for sure implement SRE. It can be used to measure whether or not you're on track to hit an SLA because you basically set SLOs that are stricter than your SLA, and you make sure that you meet it. +CHAD: Is there a way that existing teams can layer on some of the SRE activities without having full-time SRE people? +JOE: I think you can have a team member who does development that also acts as the SRE. If you have a small team, I could see the commitment to it being daunting. I think that could be one good reason to bring in outside specialists if you're not at the point where you can afford to have a full-time SRE in-house. Working with a team that can provide an SRE on-demand like Mission Control could be valuable. +CHAD: I didn't realize that that was going to be a perfect segue into part of the value proposition of Mission Control [laughter] when I asked the question. But I guess that's a really good point. That is part of what we're helping people do is monthly contracts that provide this to them, even if their team can't do it 100% of the time. +JOE: Right, except for pretty large teams. I don't think it makes sense for them to hire a full-time SRE. It's much easier to work with a team like ours that has the experience and has more than one person. Even if you do hire a full-time SRE, you will only have one. So if they go on vacation, or if they get sick, or if it's in the middle of the night, then do you still have an SRE? I think that's one of the benefits of working with a team. +CHAD: And that's been interesting with Mission Control because we introduced Mission Control and made it a formal thing at the same time as going entirely remote. And it's interesting how doing that freed us up in terms of being able to commit to building a different kind of team. +It doesn't necessarily need to be on call after hours if we're going to have an entirely remote team. We can have people on that team that span different time zones. And so, from a thoughtbot perspective, it's interesting how those things went hand in hand for us. +JOE: Yes, it's been immensely helpful for Mission Control, in particular, to be fully remote. There are a lot of options that wouldn't have been available to us if we were a U.S.-centric team. It's been really interesting. I've built out development teams before that were focused on a location. And it's been really interesting to build out this team with a focus on availability and distribution. +For example, one thing that has helped us is having somebody in South America because they don't celebrate U.S. holidays. So even discounting time zones, which are a challenge when you're trying to provide around-the-clock availability, just having that kind of diversity in holiday schedules really helps. So we've been able to build it totally differently than we would have if we were trying to put a bunch of people in an office. And I think it's made it possible for us to have much better coverage with a much smaller team. +Mid-roll Ad +I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. +We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. +Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +CHAD: So Mission Control I introduced it as maintenance and DevOps. So we're also helping people with different kinds of things beyond operations, right? +JOE: Yeah, particularly with SRE, there's a focus on stability and scaling. And we're also helping people with CI/CD. One of the focuses for us this quarter has been helping people develop CI/CD pipelines that provide safer deploys and providing guidance and a system for developers to implement things like feature flags and beta flags. +Because one of the challenges of making performance improvements is that you don't actually know if you've solved the problem until it's deployed, and deploying something that changes performance is inherently risky. And so, in addition to helping people actually make the performance improvements, we have to demonstrate the process for deploying and testing those improvements. +CHAD: I've worked on fairly big systems in the past. But there have been a couple of different instances over the last maybe year where we've approached the problem in a different way than we have in the past, which has been really interesting to me from a development standpoint. It's the idea of…if you remember, for the food delivery application, we had that conversation about the different ways to build APIs rather than versioning APIs explicitly. And that has been a different approach than the way I would have done things in the past. And it's been a really powerful approach. So, can we talk a little bit more about that approach? +JOE: Sure. +CHAD: Well, specifically, so we have mobile applications that use a back-end API, and not everyone updates their mobile application at the same time instantly. You have bugs basically in the wild that you are fixing or that you're changing in your API, or if you're just introducing API changes. +And so the idea of instead of explicitly versioning API on the server-side and having clients write to a specific API, instead building much more flexible APIs, in particular, having the client tell you what version of the API that they're expecting but through consolidated API endpoints so that the server is much more in control of the behavior than the client being in control of the behavior. +JOE: Yeah, I think the two big changes that were helpful on that project were using GraphQL for some of the APIs, which provides more flexibility generally than a typical REST API and the minimum version requirement. So the application sends the version of the application. And the API will tell the client they have to upgrade if it's a version that isn't compatible with the newer APIs. So when we do have to break backwards compatibility, we force an app upgrade. +CHAD: But in general, you're taking the approach not to break backward compatibility. And you're meeting the client where it's at whenever possible and maintaining backward compatibility in the APIs. +JOE: That's something that we have been teaching developers about generally is backwards and forwards compatibility. We do that with deployments as well. For some of the larger deployments we have where there might be dozens of containers running for a service, it certainly doesn't make sense to stop them all and start new ones because the app would be down for a long time. And it would take too long to catch up to the backlog of requests. +But even a typical blue-green deployment is problematic. So if we have 30 containers running and we spin up 30 new containers, and they all need 15 database connections, then during the deploy, you potentially overload your database or exhaust your connection limit. Plus, you will need to allocate the compute resources for double the normal workload. +So what we've been doing instead is rolling deploys almost everywhere where we spin up a few new containers using the new version and wait until they're fully online, spin down a few old ones, and then repeat that process until everything is up to date. But to do a rolling deploy like that requires backwards compatibility with the services it uses, in particular, at the database. And so, writing Rails migrations that are backwards compatible for one version has been a challenge. +CHAD: And there's not really good tooling in Rails to do multiple stages of things. So if you really want to do that, you have to manage that in your source control basically and say, "Here's a new migration. We're going to merge in and deploy after this one," and that's not so great. +JOE: Right. The other way to do that in the CI/CD pipeline would be to release commits one at a time and wait for them to be rolled out. But depending on how you structure your commit log, that could be pretty tedious. [laughs] +CHAD: Yeah. I've seen as I've worked on this other project we're really striving to do continuous deployment. It's a high traffic, very complex deployment with lots of individual configured tenants. Separating out the concept of a deploy from a release has been very valuable for the application and for the clients. It changes the way that you need to think about how development progresses. +I never before really worked in a system where you're literally sometimes duplicating and preserving old code, putting new code in place, having them both deployed, and then being able to switch between them as part of the release, and then cleaning up the old code later. At the scale that this is at, at the complexity that this is at, it makes sense for that application. It obviously doesn't make sense for everybody to be working that way. +JOE: Right. Breaking up applications to be a little smaller, having components that could be experimented with individually would make some of that easier. The experimentation there separating the release from the deploy some of that is necessary because it's monolithic in so many ways. Like, it's a very big Rails application with one database with ACID compliance, which is a very powerful model. And it provides simplicity in some ways. But then it requires you to take on the complexity of making sure that you release things correctly. +I do think that it would be difficult in this particular situation but for applications that reach that level of traffic and where you need to manage the risk of deploying, having smaller components, having some services broken would make that easier because you could do, for example, a canary deploy with one release rather than duplicating the code and having the old and new version. +CHAD: Right. The services create boundaries with contracts about behavior and reduces things that are tightly coupled together, and their behavior is tightly coupled together. So, for example, on this application, we do have that one service that is completely managed independently from the main monolith and has its own deploy schedule. And we can, for the most part, change them independently without needing to go through all of that process that we go through to manage change. I think you're absolutely right. +JOE: Another experiment we've been trying for another client is it's another Rails monolith. There are different audiences for it. So this is the food delivery application again. And there are customers who are placing orders. There are drivers who are delivering orders. There are restaurants that are fulfilling orders. And then there are admins who are managing everything in the back end. And there's some overlap in the data they use. But the actual requests, and controllers, and pieces of the Rails application they use are almost entirely isolated. +So one challenge we had was being able to provide different reliability contracts for those different audiences and also scaling them and configuring them differently. So, for example, if you've done tuning for a Rails application before, you've probably tweaked things like how many threads will I have for each of my Puma workers? How many Puma workers will I have per container? How many database connections do I need in the pool? +And what we were able to do for this application using Kubernetes and Isto was running the same application, the same container, so like one monolithic Rails container but running it more than once in different configurations and routing traffic to different pools of containers based on the audience. +And so, for example, if the customer is making requests, those all go to the customer pool of containers, which are scaled independently and have their own configuration tweaks for the kinds of requests that customers tend to make, which are generally small, high throughput requests with lots of little rights. +And then, compared to the admin panel, they typically view dashboards and big lists of records. And so, the requests tend to be larger, but the number of users is much smaller. There are way more customers than there are admins. And so, for those, we have fewer connections. We have more memory allocated for the kind of bloat that results in those types of requests. +And we also have a different performance objective for admins. It's more acceptable for those pages to respond a little bit slower. And admins understand it's their job. They have to use the software. So they'll reload the page if they have to versus a customer where if they're having trouble placing an order, they might just buy somewhere else. So that's been a pretty powerful mechanism we were able to leverage +CHAD: Is that switching on URL-like endpoints? +JOE: Yeah, it's based on the path. But the mechanisms available to us are actually pretty powerful. At that point, we have access to the full request. So we could really route based on anything we wanted right down to the user. +CHAD: I guess that's a really good example. You don't have access to that routing on Heroku. +JOE: No, I think any Platform as a Service where they manage the routing if they don't provide that feature, you don't get that feature. +CHAD: This is the first we're talking about this. That is a really interesting example of how to scale a monolith solves some of the problems that services often get you without having to break everything up right off the bat in order to do that. +JOE: Yeah. I also think it provides kind of an inside-out approach to doing that. One of the problems with breaking out services is you have to plan what the services are going to be to a certain degree. And so, I think the best way to do it is to extract services from a monolith the same way you extract classes to break them up. +And this audience-based approach is almost like a dry run. You can see if the boundaries you're drawing make sense in terms of traffic. And if those make sense, it probably makes sense to break up the front end at those boundaries eventually into different applications. And then figure out what services you need to extract to provide the common infrastructure for those front-end services. +The same way test-driven development makes it much easier to find the correct tests to write, I think this approach of audience boundary discovery is an interesting approach to finding service boundaries versus trying to guess at what the services are, which very frequently leads people to wrapping services around database tables which doesn't help at all. +CHAD: Yeah, that's the wrong thing to be looking at when you're looking at how to do services. +JOE: Right. It's almost like deciding what your database tables would be upfront before you've seen the UI for the application. +CHAD: Cool. So heading into 2022, we're looking ahead at the upcoming year. And so what's on the docket for Mission Control? +JOE: We didn't start experimenting fully with SRE until the third quarter of this year. And so far, we've loved it. So I think we'll make a pretty heavy investment into our SRE offering. The goal is for us to have an open-source set of Terraform modules that effectively deploy a platform ready to go for SRE. What we want to do is maintain and curate that platform and then deploy it and maintain it for our clients. +I think another big thing we'll be doing is (This might be incredibly boring.) but restructuring the way our agreements work a little bit. One of the things we wanted to test out when we built Mission Control was how much we could have built into a monthly recurring contract versus billing for time and materials like we usually do. So we tried putting a lot into that contract and really pushing the boundaries of what would be reasonable. +And there was definitely a lot of pain there for us and a lot of difficult conversations with clients. So I think for 2022, we will be shifting a lot of our work back towards time and materials. So I guess that's a lesson out there for anybody else that's providing [laughs] support contracts is to make sure that the responsibilities contained in the linear amount scale linearly. +CHAD: I think when we originally conceived of Mission Control, we also saw it handling a lot more things that it turns out just were not doing as part of Mission Control like regular Rails upgrades. +JOE: Yeah, a lot of the things that we included in contracts originally were not particularly important to clients or at least were not outside of what they were capable of doing already. So it wasn't that much of a value-add. There are a lot of people out there that will upgrade your Rails version. And having somebody who just does it in the background but isn't aware of some of the impacts that might have in the application turned out to be not much of a value prop. Whereas stability turns out to be a big pain point for a lot of people, people don't know how to do it. +And then our maintenance offering, I think what ended up providing the most value is not the keeping the code fresh parts, but it was more for the teams that don't have a large continuous development team having access to somebody who can fix quick bugs and things like that without needing to first negotiate a contract with a provider. I think that provides a lot of value. Those are pretty separate and different offerings. But those are the pieces that we found have really been valuable to clients. +CHAD: Well, great. If people want to find out more about Mission Control or get in touch with you, where are the best places for them to do that? +JOE: Well, we have a website thoughtbot.com/mission-control with a dash between mission and control. There are a few ways to reach out there. You can also find us on Twitter. We are @thoughtbot, and I am @joeferris. +CHAD: Cool. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Joe Ferris. + + + Joe Ferris is thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Mission Control is our newest team doing DevOps Support, Maintenance, and SRE (Site Reliability Engineering). The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, is to support those teams and support other client teams in deploying and scaling applications. They have an on-call team and do more complex cloud build-outs with the goal being to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Joe Ferris, thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Joe, welcome back to the show.

+ +

JOE: Thanks, Chad. It's been a while.

+ +

CHAD: It has been a while. I think you were the first-ever guest, if I'm not mistaken.

+ +

JOE: I believe that's right. We talked about null, I think.

+ +

[laughter]

+ +

CHAD: Yeah. And it would have been with Ben back when I was just a listener and maybe producer. So welcome back to the show. It's been a long time, and a lot has changed at thoughtbot over the years. I've been talking to each of the managing directors of the new teams, and I wanted to be sure to have you on. Why don't we take a little bit of a step back and talk about Mission Control? When we say DevOps and maintenance, what do we mean? And what does Mission Control do?

+ +

JOE: Sure. Mission Control is our newest team doing DevOps support, and maintenance, and SRE. It came out of our experiments with DevOps a while ago now, almost two years coming up. Historically, thoughtbot has shied away from getting too much into DevOps. I think a lot of us had some unpleasant experiences earlier in our career around sysadmin tasks and expectations there. Not a lot of people have wanted to be on call historically.

+ +

So we've heavily leveraged services like Heroku that take a lot of that burden away from you and avoided doing things like direct to AWS deployments or getting too involved with CI/CD pipelines that were particularly complex. But we've had clients over the years that have requested more interesting or more difficult deployments.

+ +

And finally, we had one a couple of years ago, where we said, "All alright, let's just handle this instead of saying no or trying to outsource it." We thought it made sense for them. And after going through it, we came to the conclusion that it was actually pretty good that the ecosystem had evolved a lot and that it was a service worth offering. That began our journey into DevOps, so to speak. So we did some smart DevOps work for a variety of clients over the next year or so before we decided to form an official team doing this new kind of work, which is how we ended up with Mission control.

+ +

The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, the goal of Mission Control is to support those teams and support other client teams in deploying and scaling their applications. And we have an on-call team. We will do more complex cloud build-outs. And our goal is to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own.

+ +

CHAD: You used the acronym SRE earlier in that little spiel. I'm not sure that everyone knows what that is. [laughs] So it stands for Site Reliability Engineer, right?

+ +

JOE: That's right. And that's been newer for us. So DevOps is supposed to be the fusion of development and operations. But the operations world is really big. So similar to how everybody has problems getting people to be full-stack enough given the complexity of front end and back end, we have similar problems in design.

+ +

We also have that problem in DevOps where both development and operations are huge, rich ecosystems. And so, having developers that are fully experienced at both is hard. So the path of least resistance, when you say are doing DevOps, is definitely just to do operations. And it's been a struggle for us to actually break down those silos and have teams work more on the operation side on their own.

+ +

So one of the things that caught our eye with SRE was some of the built-in mechanisms for engaging with the team. The one-sentence pitch for SRE is that it is operations if you approach it like a software problem. It has these concepts of SLOs, Service Level Objectives, and error budgets, which is the amount of time you spent violating your SLO. And part of the process is getting buy-in from the entire team, from the stakeholders down to the developers and the operations team. And so, it provides a natural interaction point between the operations folks and the rest of the team because nobody wants to break the error budget. Once the error budget is exhausted, everybody has to stop building new features and focus on stability until the error budget is cut up again.

+ +

So rather than having this unpleasant give or take where we're more coming from the operations side, and we're always pushing for more stability, and everybody else is coming from the product side, and they're always pushing for more features, SRE gives you this useful metric to have that conversation around where we're not always just pushing for more. We're trying to hit a specific goal that we've agreed on. And when we hit the goal, we know that we can keep full throttle moving out new features.

+ +

CHAD: Now, is the SRE a developer who is also working on resolving errors before the budget is hit?

+ +

JOE: Yeah, a Site Reliability Engineer is a developer. But that's actually not too different from other forms of DevOps. DevOps is supposed to be developers in general. When I say we built an operations team, even if you look at the work that we're doing, a lot of it is development work. We build scripts, and automations, and so on. We don't manually set up EC2 instances, and not everything is toil, even outside of SRE.

+ +

But the idea in SRE is that somebody will be more integrated with the development team and make changes to not just the operational stack but also the development stack in service of reliability. I've heard it said that SRE is a particular implementation of DevOps. That makes sense to me.

+ +

CHAD: Let's start back in the beginning because you made reference to the fact that historically, a lot of what we deploy was deployed to Heroku. And we did that because, for a lot of the applications that we're building, it made sense. It minimized the operational overhead of deployments. There is a point in some systems that you cross a line. Where do we see that line typically being where you need to start looking at something else?

+ +

JOE: I think there can be a few different instigating factors. One of the fastest ways for somebody to want to move to AWS is if they have significant security concerns, particularly for healthcare applications. The security model is more straightforward in AWS to have better isolation. There are options on Heroku, but it requires going to a different Heroku platform using Shield. And you just don't get the same power you get in terms of network isolation models you get on AWS with your own VPC.

+ +

So if you're already at the point where you want to start out with a VPC out of the gate and do that kind of isolation, my opinion is you may as well own it and go to AWS. So that's one reason. Another is if you start hitting scaling issues, Heroku is easier for the developers because it's simple and it's very streamlined. But doing complex deployments is difficult, which eliminates some of the options available to somebody doing something like SRE.

+ +

So to give one example, one mechanism people can use to make it safer to deploy without potentially introducing bugs or performance degradations is a canary release where when you release, you put the new version out as the canary build. And you route maybe 5% of traffic to that, and you actually collect metrics on performance and error rates on the canary traffic versus the regular traffic.

+ +

And then you have some period where you're in experiment mode, which varies depending on the level of stability you're looking to achieve. Once you're confident that the canary release didn't introduce a regression, then it gets promoted to the stable build, and you do that every time you deploy. I have no idea how you would do that on Heroku.

+ +

CHAD: I think you'd have to do it at the application level. You'd have to do it with a feature flag system. And it would only be possible to do some of the things that you would be able to do if you're able to do the whole system.

+ +

JOE: Right. And I guess you could do weighted random numbers to try and decide whether to canary or not. But one of the benefits of doing it outside the application is there's no way to make a mistake. So, for example, if you introduced a bug in your canary mechanism in the application or you forget to put it behind a feature flag, then you've now deployed to production, and you have an error. Whereas if it's managed by the CI/CD pipeline, you're just deploying a new version of the application. In Heroku land, that would mean you deploy the new slug as a canary build. In most other areas, it means you're deploying a container image.

+ +

That's one example of why if you get to the point that you have a lot of traffic in production and you need to manage that traffic while continuing to release features, it can be helpful to work on a platform like AWS where you have a lot more deployment options.

+ +

Another one is that SRE is heavily built on observability and metrics, which can be difficult to collect on Heroku. Some of that is just a matter of lineage. Like, the SRE community was built up around tools like Prometheus that are scrape-based. That means you need to have a special metrics endpoint exposed on all of your containers.

+ +

In Heroku, there isn't a way to access any of your dynos directly except through the web router, and you can't control which one you get. So using Prometheus on Heroku is not really practical, which means you need to re-implement what everybody else has built for SRE using a different observability tool.

+ +

And observability out of the box on Heroku it's easy to get set up, but it's more limited. So doing something like complex SLOs and setting up error budget dashboards and alerting is going to be a significant task. Versus on a platform like Kubernetes where it doesn't sound like it'll be easier, but it is because there are open-source tools that you can just deploy.

+ +

CHAD: You mentioned Kubernetes. It's probably worth calling out that that's pretty much what we are using across the board, right?

+ +

JOE: For our AWS and other cloud deployments, we have standardized largely on Kubernetes. We started out using simpler containerization platforms like ECS on AWS. But what we found is that the developer tooling is generally not particularly good because there's not enough community momentum behind any of those. And the open-source is limited versus something like Kubernetes there's a massive open-source community.

+ +

There is a ton of different tooling that people build that's available for developers and for DevOps. And for these things like SRE, you can use almost entirely open-source software to build out all of the interesting parts of that and deploy that. So what we've been building is basically an SRE Platform as a Service where we collect these open-source components. We deploy them to a managed Kubernetes cluster. And then, applications can immediately start exposing metrics to Prometheus and defining SLOs.

+ +

CHAD: So much in the same way where we talked about some of the boundaries where it starts to make sense to not be on Heroku, what are some of the boundaries that teams hit where it makes sense to start thinking about SRE or even just having someone on the team that's focused on that kind of work?

+ +

JOE: I think as soon as people start hitting their first scaling challenges. So for an MVP where you're validating a product where you don't actually have production traffic yet, I don't think it makes sense. And I also think I would avoid deploying to something like Kubernetes if you can help it for an MVP.

+ +

But for anybody who has scaling concerns, SRE is a very useful mindset. And the sooner you start adopting it, the sooner you'll start to build an application that's made to scale. It can be very difficult to put out those fires while something is not on a platform where you have many options, and nobody has been thinking about observability. It means that you need to be guessing at how to put out the fire as well as simultaneously introducing metrics and potentially planning a cloud migration.

+ +

So I think as soon as you start feeling nervous about deploying to production or as soon as you notice that you're spending a lot of time working on performance, it makes sense to bring in SRE. I also think anybody that needs to provide an SLA should for sure implement SRE. It can be used to measure whether or not you're on track to hit an SLA because you basically set SLOs that are stricter than your SLA, and you make sure that you meet it.

+ +

CHAD: Is there a way that existing teams can layer on some of the SRE activities without having full-time SRE people?

+ +

JOE: I think you can have a team member who does development that also acts as the SRE. If you have a small team, I could see the commitment to it being daunting. I think that could be one good reason to bring in outside specialists if you're not at the point where you can afford to have a full-time SRE in-house. Working with a team that can provide an SRE on-demand like Mission Control could be valuable.

+ +

CHAD: I didn't realize that that was going to be a perfect segue into part of the value proposition of Mission Control [laughter] when I asked the question. But I guess that's a really good point. That is part of what we're helping people do is monthly contracts that provide this to them, even if their team can't do it 100% of the time.

+ +

JOE: Right, except for pretty large teams. I don't think it makes sense for them to hire a full-time SRE. It's much easier to work with a team like ours that has the experience and has more than one person. Even if you do hire a full-time SRE, you will only have one. So if they go on vacation, or if they get sick, or if it's in the middle of the night, then do you still have an SRE? I think that's one of the benefits of working with a team.

+ +

CHAD: And that's been interesting with Mission Control because we introduced Mission Control and made it a formal thing at the same time as going entirely remote. And it's interesting how doing that freed us up in terms of being able to commit to building a different kind of team.

+ +

It doesn't necessarily need to be on call after hours if we're going to have an entirely remote team. We can have people on that team that span different time zones. And so, from a thoughtbot perspective, it's interesting how those things went hand in hand for us.

+ +

JOE: Yes, it's been immensely helpful for Mission Control, in particular, to be fully remote. There are a lot of options that wouldn't have been available to us if we were a U.S.-centric team. It's been really interesting. I've built out development teams before that were focused on a location. And it's been really interesting to build out this team with a focus on availability and distribution.

+ +

For example, one thing that has helped us is having somebody in South America because they don't celebrate U.S. holidays. So even discounting time zones, which are a challenge when you're trying to provide around-the-clock availability, just having that kind of diversity in holiday schedules really helps. So we've been able to build it totally differently than we would have if we were trying to put a bunch of people in an office. And I think it's made it possible for us to have much better coverage with a much smaller team.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So Mission Control I introduced it as maintenance and DevOps. So we're also helping people with different kinds of things beyond operations, right?

+ +

JOE: Yeah, particularly with SRE, there's a focus on stability and scaling. And we're also helping people with CI/CD. One of the focuses for us this quarter has been helping people develop CI/CD pipelines that provide safer deploys and providing guidance and a system for developers to implement things like feature flags and beta flags.

+ +

Because one of the challenges of making performance improvements is that you don't actually know if you've solved the problem until it's deployed, and deploying something that changes performance is inherently risky. And so, in addition to helping people actually make the performance improvements, we have to demonstrate the process for deploying and testing those improvements.

+ +

CHAD: I've worked on fairly big systems in the past. But there have been a couple of different instances over the last maybe year where we've approached the problem in a different way than we have in the past, which has been really interesting to me from a development standpoint. It's the idea of…if you remember, for the food delivery application, we had that conversation about the different ways to build APIs rather than versioning APIs explicitly. And that has been a different approach than the way I would have done things in the past. And it's been a really powerful approach. So, can we talk a little bit more about that approach?

+ +

JOE: Sure.

+ +

CHAD: Well, specifically, so we have mobile applications that use a back-end API, and not everyone updates their mobile application at the same time instantly. You have bugs basically in the wild that you are fixing or that you're changing in your API, or if you're just introducing API changes.

+ +

And so the idea of instead of explicitly versioning API on the server-side and having clients write to a specific API, instead building much more flexible APIs, in particular, having the client tell you what version of the API that they're expecting but through consolidated API endpoints so that the server is much more in control of the behavior than the client being in control of the behavior.

+ +

JOE: Yeah, I think the two big changes that were helpful on that project were using GraphQL for some of the APIs, which provides more flexibility generally than a typical REST API and the minimum version requirement. So the application sends the version of the application. And the API will tell the client they have to upgrade if it's a version that isn't compatible with the newer APIs. So when we do have to break backwards compatibility, we force an app upgrade.

+ +

CHAD: But in general, you're taking the approach not to break backward compatibility. And you're meeting the client where it's at whenever possible and maintaining backward compatibility in the APIs.

+ +

JOE: That's something that we have been teaching developers about generally is backwards and forwards compatibility. We do that with deployments as well. For some of the larger deployments we have where there might be dozens of containers running for a service, it certainly doesn't make sense to stop them all and start new ones because the app would be down for a long time. And it would take too long to catch up to the backlog of requests.

+ +

But even a typical blue-green deployment is problematic. So if we have 30 containers running and we spin up 30 new containers, and they all need 15 database connections, then during the deploy, you potentially overload your database or exhaust your connection limit. Plus, you will need to allocate the compute resources for double the normal workload.

+ +

So what we've been doing instead is rolling deploys almost everywhere where we spin up a few new containers using the new version and wait until they're fully online, spin down a few old ones, and then repeat that process until everything is up to date. But to do a rolling deploy like that requires backwards compatibility with the services it uses, in particular, at the database. And so, writing Rails migrations that are backwards compatible for one version has been a challenge.

+ +

CHAD: And there's not really good tooling in Rails to do multiple stages of things. So if you really want to do that, you have to manage that in your source control basically and say, "Here's a new migration. We're going to merge in and deploy after this one," and that's not so great.

+ +

JOE: Right. The other way to do that in the CI/CD pipeline would be to release commits one at a time and wait for them to be rolled out. But depending on how you structure your commit log, that could be pretty tedious. [laughs]

+ +

CHAD: Yeah. I've seen as I've worked on this other project we're really striving to do continuous deployment. It's a high traffic, very complex deployment with lots of individual configured tenants. Separating out the concept of a deploy from a release has been very valuable for the application and for the clients. It changes the way that you need to think about how development progresses.

+ +

I never before really worked in a system where you're literally sometimes duplicating and preserving old code, putting new code in place, having them both deployed, and then being able to switch between them as part of the release, and then cleaning up the old code later. At the scale that this is at, at the complexity that this is at, it makes sense for that application. It obviously doesn't make sense for everybody to be working that way.

+ +

JOE: Right. Breaking up applications to be a little smaller, having components that could be experimented with individually would make some of that easier. The experimentation there separating the release from the deploy some of that is necessary because it's monolithic in so many ways. Like, it's a very big Rails application with one database with ACID compliance, which is a very powerful model. And it provides simplicity in some ways. But then it requires you to take on the complexity of making sure that you release things correctly.

+ +

I do think that it would be difficult in this particular situation but for applications that reach that level of traffic and where you need to manage the risk of deploying, having smaller components, having some services broken would make that easier because you could do, for example, a canary deploy with one release rather than duplicating the code and having the old and new version.

+ +

CHAD: Right. The services create boundaries with contracts about behavior and reduces things that are tightly coupled together, and their behavior is tightly coupled together. So, for example, on this application, we do have that one service that is completely managed independently from the main monolith and has its own deploy schedule. And we can, for the most part, change them independently without needing to go through all of that process that we go through to manage change. I think you're absolutely right.

+ +

JOE: Another experiment we've been trying for another client is it's another Rails monolith. There are different audiences for it. So this is the food delivery application again. And there are customers who are placing orders. There are drivers who are delivering orders. There are restaurants that are fulfilling orders. And then there are admins who are managing everything in the back end. And there's some overlap in the data they use. But the actual requests, and controllers, and pieces of the Rails application they use are almost entirely isolated.

+ +

So one challenge we had was being able to provide different reliability contracts for those different audiences and also scaling them and configuring them differently. So, for example, if you've done tuning for a Rails application before, you've probably tweaked things like how many threads will I have for each of my Puma workers? How many Puma workers will I have per container? How many database connections do I need in the pool?

+ +

And what we were able to do for this application using Kubernetes and Isto was running the same application, the same container, so like one monolithic Rails container but running it more than once in different configurations and routing traffic to different pools of containers based on the audience.

+ +

And so, for example, if the customer is making requests, those all go to the customer pool of containers, which are scaled independently and have their own configuration tweaks for the kinds of requests that customers tend to make, which are generally small, high throughput requests with lots of little rights.

+ +

And then, compared to the admin panel, they typically view dashboards and big lists of records. And so, the requests tend to be larger, but the number of users is much smaller. There are way more customers than there are admins. And so, for those, we have fewer connections. We have more memory allocated for the kind of bloat that results in those types of requests.

+ +

And we also have a different performance objective for admins. It's more acceptable for those pages to respond a little bit slower. And admins understand it's their job. They have to use the software. So they'll reload the page if they have to versus a customer where if they're having trouble placing an order, they might just buy somewhere else. So that's been a pretty powerful mechanism we were able to leverage

+ +

CHAD: Is that switching on URL-like endpoints?

+ +

JOE: Yeah, it's based on the path. But the mechanisms available to us are actually pretty powerful. At that point, we have access to the full request. So we could really route based on anything we wanted right down to the user.

+ +

CHAD: I guess that's a really good example. You don't have access to that routing on Heroku.

+ +

JOE: No, I think any Platform as a Service where they manage the routing if they don't provide that feature, you don't get that feature.

+ +

CHAD: This is the first we're talking about this. That is a really interesting example of how to scale a monolith solves some of the problems that services often get you without having to break everything up right off the bat in order to do that.

+ +

JOE: Yeah. I also think it provides kind of an inside-out approach to doing that. One of the problems with breaking out services is you have to plan what the services are going to be to a certain degree. And so, I think the best way to do it is to extract services from a monolith the same way you extract classes to break them up.

+ +

And this audience-based approach is almost like a dry run. You can see if the boundaries you're drawing make sense in terms of traffic. And if those make sense, it probably makes sense to break up the front end at those boundaries eventually into different applications. And then figure out what services you need to extract to provide the common infrastructure for those front-end services.

+ +

The same way test-driven development makes it much easier to find the correct tests to write, I think this approach of audience boundary discovery is an interesting approach to finding service boundaries versus trying to guess at what the services are, which very frequently leads people to wrapping services around database tables which doesn't help at all.

+ +

CHAD: Yeah, that's the wrong thing to be looking at when you're looking at how to do services.

+ +

JOE: Right. It's almost like deciding what your database tables would be upfront before you've seen the UI for the application.

+ +

CHAD: Cool. So heading into 2022, we're looking ahead at the upcoming year. And so what's on the docket for Mission Control?

+ +

JOE: We didn't start experimenting fully with SRE until the third quarter of this year. And so far, we've loved it. So I think we'll make a pretty heavy investment into our SRE offering. The goal is for us to have an open-source set of Terraform modules that effectively deploy a platform ready to go for SRE. What we want to do is maintain and curate that platform and then deploy it and maintain it for our clients.

+ +

I think another big thing we'll be doing is (This might be incredibly boring.) but restructuring the way our agreements work a little bit. One of the things we wanted to test out when we built Mission Control was how much we could have built into a monthly recurring contract versus billing for time and materials like we usually do. So we tried putting a lot into that contract and really pushing the boundaries of what would be reasonable.

+ +

And there was definitely a lot of pain there for us and a lot of difficult conversations with clients. So I think for 2022, we will be shifting a lot of our work back towards time and materials. So I guess that's a lesson out there for anybody else that's providing [laughs] support contracts is to make sure that the responsibilities contained in the linear amount scale linearly.

+ +

CHAD: I think when we originally conceived of Mission Control, we also saw it handling a lot more things that it turns out just were not doing as part of Mission Control like regular Rails upgrades.

+ +

JOE: Yeah, a lot of the things that we included in contracts originally were not particularly important to clients or at least were not outside of what they were capable of doing already. So it wasn't that much of a value-add. There are a lot of people out there that will upgrade your Rails version. And having somebody who just does it in the background but isn't aware of some of the impacts that might have in the application turned out to be not much of a value prop. Whereas stability turns out to be a big pain point for a lot of people, people don't know how to do it.

+ +

And then our maintenance offering, I think what ended up providing the most value is not the keeping the code fresh parts, but it was more for the teams that don't have a large continuous development team having access to somebody who can fix quick bugs and things like that without needing to first negotiate a contract with a provider. I think that provides a lot of value. Those are pretty separate and different offerings. But those are the pieces that we found have really been valuable to clients.

+ +

CHAD: Well, great. If people want to find out more about Mission Control or get in touch with you, where are the best places for them to do that?

+ +

JOE: Well, we have a website thoughtbot.com/mission-control with a dash between mission and control. There are a few ways to reach out there. You can also find us on Twitter. We are @thoughtbot, and I am @joeferris.

+ +

CHAD: Cool. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Joe Ferris.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Joe Ferris is thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Mission Control is our newest team doing DevOps Support, Maintenance, and SRE (Site Reliability Engineering). The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, is to support those teams and support other client teams in deploying and scaling applications. They have an on-call team and do more complex cloud build-outs with the goal being to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Joe Ferris, thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Joe, welcome back to the show.

+ +

JOE: Thanks, Chad. It's been a while.

+ +

CHAD: It has been a while. I think you were the first-ever guest, if I'm not mistaken.

+ +

JOE: I believe that's right. We talked about null, I think.

+ +

[laughter]

+ +

CHAD: Yeah. And it would have been with Ben back when I was just a listener and maybe producer. So welcome back to the show. It's been a long time, and a lot has changed at thoughtbot over the years. I've been talking to each of the managing directors of the new teams, and I wanted to be sure to have you on. Why don't we take a little bit of a step back and talk about Mission Control? When we say DevOps and maintenance, what do we mean? And what does Mission Control do?

+ +

JOE: Sure. Mission Control is our newest team doing DevOps support, and maintenance, and SRE. It came out of our experiments with DevOps a while ago now, almost two years coming up. Historically, thoughtbot has shied away from getting too much into DevOps. I think a lot of us had some unpleasant experiences earlier in our career around sysadmin tasks and expectations there. Not a lot of people have wanted to be on call historically.

+ +

So we've heavily leveraged services like Heroku that take a lot of that burden away from you and avoided doing things like direct to AWS deployments or getting too involved with CI/CD pipelines that were particularly complex. But we've had clients over the years that have requested more interesting or more difficult deployments.

+ +

And finally, we had one a couple of years ago, where we said, "All alright, let's just handle this instead of saying no or trying to outsource it." We thought it made sense for them. And after going through it, we came to the conclusion that it was actually pretty good that the ecosystem had evolved a lot and that it was a service worth offering. That began our journey into DevOps, so to speak. So we did some smart DevOps work for a variety of clients over the next year or so before we decided to form an official team doing this new kind of work, which is how we ended up with Mission control.

+ +

The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, the goal of Mission Control is to support those teams and support other client teams in deploying and scaling their applications. And we have an on-call team. We will do more complex cloud build-outs. And our goal is to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own.

+ +

CHAD: You used the acronym SRE earlier in that little spiel. I'm not sure that everyone knows what that is. [laughs] So it stands for Site Reliability Engineer, right?

+ +

JOE: That's right. And that's been newer for us. So DevOps is supposed to be the fusion of development and operations. But the operations world is really big. So similar to how everybody has problems getting people to be full-stack enough given the complexity of front end and back end, we have similar problems in design.

+ +

We also have that problem in DevOps where both development and operations are huge, rich ecosystems. And so, having developers that are fully experienced at both is hard. So the path of least resistance, when you say are doing DevOps, is definitely just to do operations. And it's been a struggle for us to actually break down those silos and have teams work more on the operation side on their own.

+ +

So one of the things that caught our eye with SRE was some of the built-in mechanisms for engaging with the team. The one-sentence pitch for SRE is that it is operations if you approach it like a software problem. It has these concepts of SLOs, Service Level Objectives, and error budgets, which is the amount of time you spent violating your SLO. And part of the process is getting buy-in from the entire team, from the stakeholders down to the developers and the operations team. And so, it provides a natural interaction point between the operations folks and the rest of the team because nobody wants to break the error budget. Once the error budget is exhausted, everybody has to stop building new features and focus on stability until the error budget is cut up again.

+ +

So rather than having this unpleasant give or take where we're more coming from the operations side, and we're always pushing for more stability, and everybody else is coming from the product side, and they're always pushing for more features, SRE gives you this useful metric to have that conversation around where we're not always just pushing for more. We're trying to hit a specific goal that we've agreed on. And when we hit the goal, we know that we can keep full throttle moving out new features.

+ +

CHAD: Now, is the SRE a developer who is also working on resolving errors before the budget is hit?

+ +

JOE: Yeah, a Site Reliability Engineer is a developer. But that's actually not too different from other forms of DevOps. DevOps is supposed to be developers in general. When I say we built an operations team, even if you look at the work that we're doing, a lot of it is development work. We build scripts, and automations, and so on. We don't manually set up EC2 instances, and not everything is toil, even outside of SRE.

+ +

But the idea in SRE is that somebody will be more integrated with the development team and make changes to not just the operational stack but also the development stack in service of reliability. I've heard it said that SRE is a particular implementation of DevOps. That makes sense to me.

+ +

CHAD: Let's start back in the beginning because you made reference to the fact that historically, a lot of what we deploy was deployed to Heroku. And we did that because, for a lot of the applications that we're building, it made sense. It minimized the operational overhead of deployments. There is a point in some systems that you cross a line. Where do we see that line typically being where you need to start looking at something else?

+ +

JOE: I think there can be a few different instigating factors. One of the fastest ways for somebody to want to move to AWS is if they have significant security concerns, particularly for healthcare applications. The security model is more straightforward in AWS to have better isolation. There are options on Heroku, but it requires going to a different Heroku platform using Shield. And you just don't get the same power you get in terms of network isolation models you get on AWS with your own VPC.

+ +

So if you're already at the point where you want to start out with a VPC out of the gate and do that kind of isolation, my opinion is you may as well own it and go to AWS. So that's one reason. Another is if you start hitting scaling issues, Heroku is easier for the developers because it's simple and it's very streamlined. But doing complex deployments is difficult, which eliminates some of the options available to somebody doing something like SRE.

+ +

So to give one example, one mechanism people can use to make it safer to deploy without potentially introducing bugs or performance degradations is a canary release where when you release, you put the new version out as the canary build. And you route maybe 5% of traffic to that, and you actually collect metrics on performance and error rates on the canary traffic versus the regular traffic.

+ +

And then you have some period where you're in experiment mode, which varies depending on the level of stability you're looking to achieve. Once you're confident that the canary release didn't introduce a regression, then it gets promoted to the stable build, and you do that every time you deploy. I have no idea how you would do that on Heroku.

+ +

CHAD: I think you'd have to do it at the application level. You'd have to do it with a feature flag system. And it would only be possible to do some of the things that you would be able to do if you're able to do the whole system.

+ +

JOE: Right. And I guess you could do weighted random numbers to try and decide whether to canary or not. But one of the benefits of doing it outside the application is there's no way to make a mistake. So, for example, if you introduced a bug in your canary mechanism in the application or you forget to put it behind a feature flag, then you've now deployed to production, and you have an error. Whereas if it's managed by the CI/CD pipeline, you're just deploying a new version of the application. In Heroku land, that would mean you deploy the new slug as a canary build. In most other areas, it means you're deploying a container image.

+ +

That's one example of why if you get to the point that you have a lot of traffic in production and you need to manage that traffic while continuing to release features, it can be helpful to work on a platform like AWS where you have a lot more deployment options.

+ +

Another one is that SRE is heavily built on observability and metrics, which can be difficult to collect on Heroku. Some of that is just a matter of lineage. Like, the SRE community was built up around tools like Prometheus that are scrape-based. That means you need to have a special metrics endpoint exposed on all of your containers.

+ +

In Heroku, there isn't a way to access any of your dynos directly except through the web router, and you can't control which one you get. So using Prometheus on Heroku is not really practical, which means you need to re-implement what everybody else has built for SRE using a different observability tool.

+ +

And observability out of the box on Heroku it's easy to get set up, but it's more limited. So doing something like complex SLOs and setting up error budget dashboards and alerting is going to be a significant task. Versus on a platform like Kubernetes where it doesn't sound like it'll be easier, but it is because there are open-source tools that you can just deploy.

+ +

CHAD: You mentioned Kubernetes. It's probably worth calling out that that's pretty much what we are using across the board, right?

+ +

JOE: For our AWS and other cloud deployments, we have standardized largely on Kubernetes. We started out using simpler containerization platforms like ECS on AWS. But what we found is that the developer tooling is generally not particularly good because there's not enough community momentum behind any of those. And the open-source is limited versus something like Kubernetes there's a massive open-source community.

+ +

There is a ton of different tooling that people build that's available for developers and for DevOps. And for these things like SRE, you can use almost entirely open-source software to build out all of the interesting parts of that and deploy that. So what we've been building is basically an SRE Platform as a Service where we collect these open-source components. We deploy them to a managed Kubernetes cluster. And then, applications can immediately start exposing metrics to Prometheus and defining SLOs.

+ +

CHAD: So much in the same way where we talked about some of the boundaries where it starts to make sense to not be on Heroku, what are some of the boundaries that teams hit where it makes sense to start thinking about SRE or even just having someone on the team that's focused on that kind of work?

+ +

JOE: I think as soon as people start hitting their first scaling challenges. So for an MVP where you're validating a product where you don't actually have production traffic yet, I don't think it makes sense. And I also think I would avoid deploying to something like Kubernetes if you can help it for an MVP.

+ +

But for anybody who has scaling concerns, SRE is a very useful mindset. And the sooner you start adopting it, the sooner you'll start to build an application that's made to scale. It can be very difficult to put out those fires while something is not on a platform where you have many options, and nobody has been thinking about observability. It means that you need to be guessing at how to put out the fire as well as simultaneously introducing metrics and potentially planning a cloud migration.

+ +

So I think as soon as you start feeling nervous about deploying to production or as soon as you notice that you're spending a lot of time working on performance, it makes sense to bring in SRE. I also think anybody that needs to provide an SLA should for sure implement SRE. It can be used to measure whether or not you're on track to hit an SLA because you basically set SLOs that are stricter than your SLA, and you make sure that you meet it.

+ +

CHAD: Is there a way that existing teams can layer on some of the SRE activities without having full-time SRE people?

+ +

JOE: I think you can have a team member who does development that also acts as the SRE. If you have a small team, I could see the commitment to it being daunting. I think that could be one good reason to bring in outside specialists if you're not at the point where you can afford to have a full-time SRE in-house. Working with a team that can provide an SRE on-demand like Mission Control could be valuable.

+ +

CHAD: I didn't realize that that was going to be a perfect segue into part of the value proposition of Mission Control [laughter] when I asked the question. But I guess that's a really good point. That is part of what we're helping people do is monthly contracts that provide this to them, even if their team can't do it 100% of the time.

+ +

JOE: Right, except for pretty large teams. I don't think it makes sense for them to hire a full-time SRE. It's much easier to work with a team like ours that has the experience and has more than one person. Even if you do hire a full-time SRE, you will only have one. So if they go on vacation, or if they get sick, or if it's in the middle of the night, then do you still have an SRE? I think that's one of the benefits of working with a team.

+ +

CHAD: And that's been interesting with Mission Control because we introduced Mission Control and made it a formal thing at the same time as going entirely remote. And it's interesting how doing that freed us up in terms of being able to commit to building a different kind of team.

+ +

It doesn't necessarily need to be on call after hours if we're going to have an entirely remote team. We can have people on that team that span different time zones. And so, from a thoughtbot perspective, it's interesting how those things went hand in hand for us.

+ +

JOE: Yes, it's been immensely helpful for Mission Control, in particular, to be fully remote. There are a lot of options that wouldn't have been available to us if we were a U.S.-centric team. It's been really interesting. I've built out development teams before that were focused on a location. And it's been really interesting to build out this team with a focus on availability and distribution.

+ +

For example, one thing that has helped us is having somebody in South America because they don't celebrate U.S. holidays. So even discounting time zones, which are a challenge when you're trying to provide around-the-clock availability, just having that kind of diversity in holiday schedules really helps. So we've been able to build it totally differently than we would have if we were trying to put a bunch of people in an office. And I think it's made it possible for us to have much better coverage with a much smaller team.

+ +

Mid-roll Ad

+ +

I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.

+ +

We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.

+ +

Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

CHAD: So Mission Control I introduced it as maintenance and DevOps. So we're also helping people with different kinds of things beyond operations, right?

+ +

JOE: Yeah, particularly with SRE, there's a focus on stability and scaling. And we're also helping people with CI/CD. One of the focuses for us this quarter has been helping people develop CI/CD pipelines that provide safer deploys and providing guidance and a system for developers to implement things like feature flags and beta flags.

+ +

Because one of the challenges of making performance improvements is that you don't actually know if you've solved the problem until it's deployed, and deploying something that changes performance is inherently risky. And so, in addition to helping people actually make the performance improvements, we have to demonstrate the process for deploying and testing those improvements.

+ +

CHAD: I've worked on fairly big systems in the past. But there have been a couple of different instances over the last maybe year where we've approached the problem in a different way than we have in the past, which has been really interesting to me from a development standpoint. It's the idea of…if you remember, for the food delivery application, we had that conversation about the different ways to build APIs rather than versioning APIs explicitly. And that has been a different approach than the way I would have done things in the past. And it's been a really powerful approach. So, can we talk a little bit more about that approach?

+ +

JOE: Sure.

+ +

CHAD: Well, specifically, so we have mobile applications that use a back-end API, and not everyone updates their mobile application at the same time instantly. You have bugs basically in the wild that you are fixing or that you're changing in your API, or if you're just introducing API changes.

+ +

And so the idea of instead of explicitly versioning API on the server-side and having clients write to a specific API, instead building much more flexible APIs, in particular, having the client tell you what version of the API that they're expecting but through consolidated API endpoints so that the server is much more in control of the behavior than the client being in control of the behavior.

+ +

JOE: Yeah, I think the two big changes that were helpful on that project were using GraphQL for some of the APIs, which provides more flexibility generally than a typical REST API and the minimum version requirement. So the application sends the version of the application. And the API will tell the client they have to upgrade if it's a version that isn't compatible with the newer APIs. So when we do have to break backwards compatibility, we force an app upgrade.

+ +

CHAD: But in general, you're taking the approach not to break backward compatibility. And you're meeting the client where it's at whenever possible and maintaining backward compatibility in the APIs.

+ +

JOE: That's something that we have been teaching developers about generally is backwards and forwards compatibility. We do that with deployments as well. For some of the larger deployments we have where there might be dozens of containers running for a service, it certainly doesn't make sense to stop them all and start new ones because the app would be down for a long time. And it would take too long to catch up to the backlog of requests.

+ +

But even a typical blue-green deployment is problematic. So if we have 30 containers running and we spin up 30 new containers, and they all need 15 database connections, then during the deploy, you potentially overload your database or exhaust your connection limit. Plus, you will need to allocate the compute resources for double the normal workload.

+ +

So what we've been doing instead is rolling deploys almost everywhere where we spin up a few new containers using the new version and wait until they're fully online, spin down a few old ones, and then repeat that process until everything is up to date. But to do a rolling deploy like that requires backwards compatibility with the services it uses, in particular, at the database. And so, writing Rails migrations that are backwards compatible for one version has been a challenge.

+ +

CHAD: And there's not really good tooling in Rails to do multiple stages of things. So if you really want to do that, you have to manage that in your source control basically and say, "Here's a new migration. We're going to merge in and deploy after this one," and that's not so great.

+ +

JOE: Right. The other way to do that in the CI/CD pipeline would be to release commits one at a time and wait for them to be rolled out. But depending on how you structure your commit log, that could be pretty tedious. [laughs]

+ +

CHAD: Yeah. I've seen as I've worked on this other project we're really striving to do continuous deployment. It's a high traffic, very complex deployment with lots of individual configured tenants. Separating out the concept of a deploy from a release has been very valuable for the application and for the clients. It changes the way that you need to think about how development progresses.

+ +

I never before really worked in a system where you're literally sometimes duplicating and preserving old code, putting new code in place, having them both deployed, and then being able to switch between them as part of the release, and then cleaning up the old code later. At the scale that this is at, at the complexity that this is at, it makes sense for that application. It obviously doesn't make sense for everybody to be working that way.

+ +

JOE: Right. Breaking up applications to be a little smaller, having components that could be experimented with individually would make some of that easier. The experimentation there separating the release from the deploy some of that is necessary because it's monolithic in so many ways. Like, it's a very big Rails application with one database with ACID compliance, which is a very powerful model. And it provides simplicity in some ways. But then it requires you to take on the complexity of making sure that you release things correctly.

+ +

I do think that it would be difficult in this particular situation but for applications that reach that level of traffic and where you need to manage the risk of deploying, having smaller components, having some services broken would make that easier because you could do, for example, a canary deploy with one release rather than duplicating the code and having the old and new version.

+ +

CHAD: Right. The services create boundaries with contracts about behavior and reduces things that are tightly coupled together, and their behavior is tightly coupled together. So, for example, on this application, we do have that one service that is completely managed independently from the main monolith and has its own deploy schedule. And we can, for the most part, change them independently without needing to go through all of that process that we go through to manage change. I think you're absolutely right.

+ +

JOE: Another experiment we've been trying for another client is it's another Rails monolith. There are different audiences for it. So this is the food delivery application again. And there are customers who are placing orders. There are drivers who are delivering orders. There are restaurants that are fulfilling orders. And then there are admins who are managing everything in the back end. And there's some overlap in the data they use. But the actual requests, and controllers, and pieces of the Rails application they use are almost entirely isolated.

+ +

So one challenge we had was being able to provide different reliability contracts for those different audiences and also scaling them and configuring them differently. So, for example, if you've done tuning for a Rails application before, you've probably tweaked things like how many threads will I have for each of my Puma workers? How many Puma workers will I have per container? How many database connections do I need in the pool?

+ +

And what we were able to do for this application using Kubernetes and Isto was running the same application, the same container, so like one monolithic Rails container but running it more than once in different configurations and routing traffic to different pools of containers based on the audience.

+ +

And so, for example, if the customer is making requests, those all go to the customer pool of containers, which are scaled independently and have their own configuration tweaks for the kinds of requests that customers tend to make, which are generally small, high throughput requests with lots of little rights.

+ +

And then, compared to the admin panel, they typically view dashboards and big lists of records. And so, the requests tend to be larger, but the number of users is much smaller. There are way more customers than there are admins. And so, for those, we have fewer connections. We have more memory allocated for the kind of bloat that results in those types of requests.

+ +

And we also have a different performance objective for admins. It's more acceptable for those pages to respond a little bit slower. And admins understand it's their job. They have to use the software. So they'll reload the page if they have to versus a customer where if they're having trouble placing an order, they might just buy somewhere else. So that's been a pretty powerful mechanism we were able to leverage

+ +

CHAD: Is that switching on URL-like endpoints?

+ +

JOE: Yeah, it's based on the path. But the mechanisms available to us are actually pretty powerful. At that point, we have access to the full request. So we could really route based on anything we wanted right down to the user.

+ +

CHAD: I guess that's a really good example. You don't have access to that routing on Heroku.

+ +

JOE: No, I think any Platform as a Service where they manage the routing if they don't provide that feature, you don't get that feature.

+ +

CHAD: This is the first we're talking about this. That is a really interesting example of how to scale a monolith solves some of the problems that services often get you without having to break everything up right off the bat in order to do that.

+ +

JOE: Yeah. I also think it provides kind of an inside-out approach to doing that. One of the problems with breaking out services is you have to plan what the services are going to be to a certain degree. And so, I think the best way to do it is to extract services from a monolith the same way you extract classes to break them up.

+ +

And this audience-based approach is almost like a dry run. You can see if the boundaries you're drawing make sense in terms of traffic. And if those make sense, it probably makes sense to break up the front end at those boundaries eventually into different applications. And then figure out what services you need to extract to provide the common infrastructure for those front-end services.

+ +

The same way test-driven development makes it much easier to find the correct tests to write, I think this approach of audience boundary discovery is an interesting approach to finding service boundaries versus trying to guess at what the services are, which very frequently leads people to wrapping services around database tables which doesn't help at all.

+ +

CHAD: Yeah, that's the wrong thing to be looking at when you're looking at how to do services.

+ +

JOE: Right. It's almost like deciding what your database tables would be upfront before you've seen the UI for the application.

+ +

CHAD: Cool. So heading into 2022, we're looking ahead at the upcoming year. And so what's on the docket for Mission Control?

+ +

JOE: We didn't start experimenting fully with SRE until the third quarter of this year. And so far, we've loved it. So I think we'll make a pretty heavy investment into our SRE offering. The goal is for us to have an open-source set of Terraform modules that effectively deploy a platform ready to go for SRE. What we want to do is maintain and curate that platform and then deploy it and maintain it for our clients.

+ +

I think another big thing we'll be doing is (This might be incredibly boring.) but restructuring the way our agreements work a little bit. One of the things we wanted to test out when we built Mission Control was how much we could have built into a monthly recurring contract versus billing for time and materials like we usually do. So we tried putting a lot into that contract and really pushing the boundaries of what would be reasonable.

+ +

And there was definitely a lot of pain there for us and a lot of difficult conversations with clients. So I think for 2022, we will be shifting a lot of our work back towards time and materials. So I guess that's a lesson out there for anybody else that's providing [laughs] support contracts is to make sure that the responsibilities contained in the linear amount scale linearly.

+ +

CHAD: I think when we originally conceived of Mission Control, we also saw it handling a lot more things that it turns out just were not doing as part of Mission Control like regular Rails upgrades.

+ +

JOE: Yeah, a lot of the things that we included in contracts originally were not particularly important to clients or at least were not outside of what they were capable of doing already. So it wasn't that much of a value-add. There are a lot of people out there that will upgrade your Rails version. And having somebody who just does it in the background but isn't aware of some of the impacts that might have in the application turned out to be not much of a value prop. Whereas stability turns out to be a big pain point for a lot of people, people don't know how to do it.

+ +

And then our maintenance offering, I think what ended up providing the most value is not the keeping the code fresh parts, but it was more for the teams that don't have a large continuous development team having access to somebody who can fix quick bugs and things like that without needing to first negotiate a contract with a provider. I think that provides a lot of value. Those are pretty separate and different offerings. But those are the pieces that we found have really been valuable to clients.

+ +

CHAD: Well, great. If people want to find out more about Mission Control or get in touch with you, where are the best places for them to do that?

+ +

JOE: Well, we have a website thoughtbot.com/mission-control with a dash between mission and control. There are a few ways to reach out there. You can also find us on Twitter. We are @thoughtbot, and I am @joeferris.

+ +

CHAD: Cool. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Joe Ferris.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pjDMf3W3 + + ]]> + + Chad Pytel + Joe Ferris + + + 402: Lift Off with Emily Bahna + https://podcast.thoughtbot.com/402 + ba2ade66-f2cb-4924-b97c-2398997a0e48 + Thu, 02 Dec 2021 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Emily Bahna is a Managing Director at thoughtbot who leads the Lift Off team, where they focus on really leaning into the core of the company. The team works with new founders to launch new products or they work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But, the thing that ties Lift Off together, is that they start at ground zero to build upon an idea and actually build the first version product to get it out live into the marketplace. + 29:09 + no + + + Emily Bahna a Managing Director at thoughtbot who leads the Lift Off team, where they focus on really leaning into the core of the company. The team works with new founders to launch new products or they work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But, the thing that ties Lift Off together, is that they start at ground zero to build upon an idea and actually build the first version product to get it out live into the marketplace. +Follow Emily on Twitter (https://twitter.com/emilybahna) or LinkedIn (https://www.linkedin.com/in/ebahna/). +thoughtbot's Lift Off team (https://thoughtbot.com/lift-off) +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Emily Bahna, Managing Director of thoughtbot's Lift Off team. Emily, thanks for joining me. +EMILY: Thank you. +CHAD: So at this point, we've talked with a few of the different managing directors at thoughtbot about their teams. And Lift Off is one of the largest teams that we have. And so what is it that Lift Off actually does? +EMILY: Lift Off is focused in on really leaning into the core of thoughtbot. We work with new founders launching new products or work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But I think the thing that ties Lift Off together is that we are starting at ground zero building upon an idea and actually building the first version product and getting it out into the marketplace. +CHAD: And oftentimes, those are pretty significant endeavors. The last episode that came out was with Dawn at Ignite who is more on the validation, early stage, getting things that are fairly straightforward into market as quickly as possible usually in a matter of months. But Lift Off the endeavors are usually quite a bit more significant than that, right? +EMILY: Yeah. I would say that the difference between validation...we're beyond the stage of validation. We're working with clients who are ready to build a foundation. They really need to put in the infrastructure that's going to take their product and get it ready to scale into the future. So they really need to make that investment into the longer-term strategy. They need to know what's realistic to build first. But they also have to keep an eye on the long road ahead of building something that can be something that can set out to grow down the road as well. +CHAD: I guess another way of putting it is that Ignite often works with brand new teams, brand new companies creating something for the first time. And Lift Off typically works with existing companies who have existing significant revenue who want to do something new, either a new business or a new product, or maybe they have an existing web product and they're going into mobile for the first time. That's another way of putting it, right? +EMILY: It could be. I think that when people are ready to move into the Lift Off space, it's about having the investment, the right kind of funding to move in that direction. Sometimes we do work with new founders that have a significant amount of funding, but a lot of times it is folks that are at the enterprise level that are building a new service line. They've got validation and market research already done. And they're building out a completely new line of business that they need to explore and set a new foundation in place. +CHAD: Do you have some examples of clients that have been projects of Lift Off? +EMILY: Yeah. We've been doing a lot of really interesting work in the health tech space, a lot of interest in improving patient experience. So we worked with a company called Relias in terms of moving them into a new service line that they'd never been in before, really focusing on improving patient care for therapists, physical therapy therapists. We've also worked with an organization called Groups Recover Together, building out a mobile application for an organization that helps people recover from substance abuse. And we also are working with an organization called Airrosti. That is also an organization that helps in the physical therapy space, so improving patient exercises or rehabilitation through an improved mobile experience, virtual experience to improve overall patient outcomes. +CHAD: I think it's not a coincidence that a lot of the projects that we work on in Lift Off are in the health tech space because that combination of...like you were saying, a lot of what Lift Off does is really build products that are complex and that are going to scale and have a certain scale fairly quickly and need to really think about more of a platform that's going to be iterated upon into the future. And once you get into a highly regulated industry like health or finance or something, there are so many factors at play, especially if you're an existing business going into that. There's lots to consider. The projects are more complex. And so having a team of people that are focused on working in that kind of environment and know the challenges of doing that and an integrated design and development team who's comfortable operating in that space, I think that that's why it's not a coincidence. +EMILY: Yeah. I think there's also a lot of great energy in that space right now to move it to the next level. And to be honest, the pandemic really accelerated the need for improvements in patient engagement and allowing therapists or physicians to be able to care for patients in a virtual setting. It also is true not just in health tech, but as you mentioned, we've been actively working with a lot of FinTech companies as well, building out mobile experiences for companies that are helping people get out of debt or working in even some of these new areas like cryptocurrency and things that are changing pretty rapidly in the marketplace and being able to respond to that. But kind of working in a really complex environment some particular industries that have specific compliance security needs in order to be able to serve their customers in a safe way. So working through a lot of those challenges is what's really important and having a team that can navigate through those levels of complexity. +CHAD: I've talked with the other managing directors about the benefits of our new focus teams and how working on a similar project allows the team members to focus. The other aspect of it is there are parts of what we did under the studio model. And it may have been like there'd be one Lift Off project within...I think we should mention that you used to be the Managing Director of the Durham Studio. And it was a relatively small team working with local clients. And so you may only have one of these kinds of clients a year or maybe even less. +And so building up an expertise but also meeting the needs of those particular clients there wasn't enough work there, for example, to hire someone with a specific skill set or knowledge if it's only going to be few and far between. And that's been true in Lift Off because we used to, at thoughtbot, not really have product managers. Everyone was designers and developers. And that was because only a subset of our projects really needed a product manager at the table. For the most part, a lot of those smaller projects or the boost-style projects are just developers or designers working directly with a stakeholder. And so, within Lift Off, we've built a product management practice because of that specialized need within these kinds of projects, right? +EMILY: Yeah, I think just like you said, the ability to really focus in on the first version product is looking at ways that we could improve our process there and provide more support that's really needed for these kinds of engagements. So what we have seen with the more complex MVPs is a lot of these clients need reliability. They need to know that what they're building is the...They need to have more support in terms of the management of that, having someone who's dedicated to being able to straddle between the business objectives and working with the team navigating some of these more complex compliance issues, security issues, and keeping that on track. +Also, we've been leaning into improving our practices around defining what first version product is. We've been using design sprints to really help align both business owners and the team to determine what are the biggest risk factors? How do we define what we're actually going to build and start building that roadmap? And we've been leaning into those best practices and actually improving upon it. +And so we've looked at that and built out a discovery sprint that is not just a week-long but really extends that out to about three weeks to give us more time to do more user research, dive a little deeper through the design sprint exercises, but then bring in engineering, bringing an interdisciplinary team to look at the problem from both a product management point of view, a design point of view, and a development point of view to really determine the first version product roadmap and give more clarity to our clients and a clearer sense of what we can accomplish in the first. +CHAD: I can speak to this firsthand because I was advising and working on a project that started before we reorganized into teams and effectively playing that role. But as the project went on, not that we did a terrible job, but it became overwhelming for me with my other responsibilities and spending a couple of days a week. A couple of days a week is sufficient on a smaller project, but on a much larger project, it's essentially a full-time job to do all of that work. [chuckles] And I just didn't have enough time to be able to do that, let alone then provide a real active management of the roadmap six-plus months out. +So a very lightweight process with not a lot of definition works when that period is then over in 6 to 12 weeks, and you have something [chuckles] in the market. When you're trying to plan and trying to coordinate work and trying to give clarity around a product and everything that's six-plus months out, it's a whole nother ball game. And it requires a whole nother level of effort, and the clients want that. And so being able to give it to them not only makes them more successful and more confident and feeling like they have that reliability, but it also then puts our team in a better supported set up for success and that kind of thing because they have what they need, and the client has what they need. And everyone's able to really come together and collaborate on building and launching a great product. +EMILY: Yeah. I think we're always looking at ways that we can improve our process, and as we are taking on more of the complex projects recognizing the need for this role. What's really exciting is the interest in the product management role. It’s been an opportunity for our team members. We've had two senior developers who've wanted to move into that role. And it's been an amazing transformation of with them, similar to you, having that background, the hands-on background of understanding what it means to be a developer on a project but then being able to transition to a different role on the project and get more involved on the business side of things. But that's been extraordinarily successful in making that transition and providing the support that the team needs in order to be successful. So in some ways, it's like we were trying to do that job without really defining it. But now that it's been defined, just recognizing the value that that role plays on these types of projects and seeing the opportunity to even improve it. +CHAD: I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one on one with a small group of agency founders and leaders toward their business goals. We do one on one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. +So we have a bunch of positions open in Lift Off. But product management is one of those positions that we're looking for people, right? +EMILY: Yeah. We are actually opening up a position for Director of Product Management because the role is so critical to the work that we're doing, just like...I feel like we're extending our design and development model but then adding this third tier of product management, which is just as important in terms of the team that works best for these types of projects. It's having that interdisciplinary core of product management, design, and development working together for new products. A lot of it is really having that high-level oversight, the business strategy integrated in with the folks that can specialize in the development and the design piece. Having to look at the problem from those three different points of view just provides a level of reliability for clients that they just can't get with a single point of view. +CHAD: What is the size of the product management team now? +EMILY: Right now? Let's see. I think we've got about five. We have four or five active product managers right now. +CHAD: So tell us more about the ideal Director of Product Management. What do you think that they would be? Able to lead a team that size while also evolving our product management process and doing product management themselves? +EMILY: Yeah. I think I'm bringing in somebody who can help us improve our product management process specifically for first version products and really looking at it, and really shaping it, and pulling in the best practices, and really shaping it for the clients that we have I think is one thing I'm looking for the director to do. I'm also looking at the director to upskill our team. Like I said, there are a lot of folks like developers and designers that are actually interested in moving into that role and building up a potential career pathway for folks that may want to move into that area and to ensure that they are successful with that. +And then growing the team, we are hoping to be able to...I think we've got five active projects right now, so being able to grow our projects and to grow the team so that we can support those kinds of projects on an ongoing basis. So really extending that out and then working collaboratively with our design and development directors to look at how we can collectively put together best practices around first version products. +CHAD: Awesome. Well, what's on your radar now? What's next for Lift Off besides hiring a Director of Product Management? +EMILY: [laughs] That's definitely number one. I think what is up next is really focusing in on teamwork. How do we work collectively as a team? Are there ways to improve our process to better serve our clients? We've done a lot of things in the past year. Like I'd mentioned before, we've improved our design sprints and extended them to become discovery sprints. Those are just names, but it's really the beginning stages of kicking off a project more successfully. Looking at ways that we can improve our customer experience and being able to serve clients in a better way, improving our product management across the board for all our projects, looking at ways that throughout the first version product for our clients what other ways can we better support our clients? Either through go-to-market strategies or helping them recruit permanent team members onto their team. But I think what's next for Lift Off is really examining how we service clients and looking at ways that we can actually make it even better. +CHAD: Cool. Well, I want to change gears a little bit and ask you about you. +EMILY: [laughs] +CHAD: So your background, I think it's important to say is as a designer, right? +EMILY: Yeah, that's one of my backgrounds. +[laughter] +CHAD: Okay, you have a varied background. But what were you doing when you joined thoughtbot and moved into the Managing Director role? And how has that evolved over time? +EMILY: I think it's really interesting. You're always leaning into something. And as you look back at your past, even if it doesn't seem to make sense, you're always gravitating to something that is your North Star. Before I joined thoughtbot, I actually ran my own agency, which was called UX-Shop. And it was a team of one; it was me. As I was building up that agency, I recognized that I couldn't do it all. The types of projects that I wanted to work on were more complex. And so, when I started UX-Shop, I would be pulling in talent to create the type of team that would make that project more successful. It was hard to continually do that in a way where I had to recruit talent [laughs] and secure projects as well without having them as permanent employees. +When I joined thoughtbot, it was an opportunity where I had access to amazing talent. And I could really focus in on building that, first off doing it in the Raleigh, Durham office where we went from a team of four to I think we grew the team to about nine. And starting to really grow that office to transitioning to this new model where we went from a team of nine to...I don't know the exact number, but I think it's like 25, 28. We're heading toward the 30 mark. So it's a significantly larger team with the ability to really focus in on the kind of projects that I actually really love, which is new product design and development but going after those more complex projects. +And I think when I start looking back at my own career, I'm just starting to see patterns of the same focus but the opportunity to dive into it in a bigger way, in a more challenging way, and starting to tackle that. So thoughtbot's really given me the opportunity to take that ambition and actually apply it with the opportunity to have the talented team to be able to execute on those types of projects. +CHAD: How has going from a team of one to a team of four to a team of nine to a team of pushing 30...are there things that you've needed to evolve in your own skillset or experiences? +EMILY: Yeah. I think certainly building leadership skills, understanding how to work through a lot of challenges on what makes a team work really well together, making sure that we've got the guidelines and structures in place. There are a lot of things that I've grown just having the opportunity to work through some of those challenges. But also, in some ways, growing into a larger team has made some things a little easier. But it was nice having that progression from a smaller team to a larger team. +I don't know if I would have been as successful with growing to a team of 30 right off the bat without being able to work in that smaller space, kind of learn my lessons, and then build upon those and grow that unit, get better at what I was doing. The reason why Lift Off is really starting to thrive is understanding that that foundation is built upon a lot of trial and error and just learning how to navigate and improve my own personal leadership skills. +CHAD: Are there any particular resources that you called upon in order to do that? +EMILY: So certainly reaching out to folks who are in similar positions. There's a strong community here where I live in Durham, talking to a lot of founders or folks in the leadership space who are growing teams. I've had some coaching with executive coaching that's helped quite a bit, especially when I've been in situations that I just wanted to make sure that I was handling them in the right way. And then, of course, having access to the folks at thoughtbot like you, Chad, and people that I can talk to and get advice on how to navigate tricky situations have all been contributing to my education and making me a better leader in this space. +CHAD: Would you recommend coaching to other people? +EMILY: I would. I think it's a real opportunity for you to...there's a lot of things that you don't really know that you don't know. And there's a lot of ways of approaching things in a different way on how you communicate. That is the difference between really getting through and solving a problem versus having a situation arise and escalate and become problematic. And it's a little bit of understanding how to frame things in a thoughtful way. +It's also an opportunity to understand that sometimes you just need to have some space to think before responding and understanding how to navigate complexity, especially in today's world where leadership there's so much going on, transitioning to remote. There are different things that are pulling at us in different aspects and just really understanding the human element of your teams. So having someone who you can talk to in a way that you can share those ideas and get a different perspective, I think, is really helpful. +CHAD: Yeah. Well, if folks want to get in touch with you or Lift Off, what's the best places for them to do that? +EMILY: Well, there's always my email, emily@thoughtbot.com. I think just reaching out to me directly is the best place. I'm always happy to talk about Lift Off or have an intro coffee call with folks that are interested in what we do. So that's the best way to get in touch with me. +CHAD: Excellent. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Special Guest: Emily Bahna. + + + Emily Bahna a Managing Director at thoughtbot who leads the Lift Off team, where they focus on really leaning into the core of the company. The team works with new founders to launch new products or they work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But, the thing that ties Lift Off together, is that they start at ground zero to build upon an idea and actually build the first version product to get it out live into the marketplace.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Emily Bahna, Managing Director of thoughtbot's Lift Off team. Emily, thanks for joining me.

+ +

EMILY: Thank you.

+ +

CHAD: So at this point, we've talked with a few of the different managing directors at thoughtbot about their teams. And Lift Off is one of the largest teams that we have. And so what is it that Lift Off actually does?

+ +

EMILY: Lift Off is focused in on really leaning into the core of thoughtbot. We work with new founders launching new products or work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But I think the thing that ties Lift Off together is that we are starting at ground zero building upon an idea and actually building the first version product and getting it out into the marketplace.

+ +

CHAD: And oftentimes, those are pretty significant endeavors. The last episode that came out was with Dawn at Ignite who is more on the validation, early stage, getting things that are fairly straightforward into market as quickly as possible usually in a matter of months. But Lift Off the endeavors are usually quite a bit more significant than that, right?

+ +

EMILY: Yeah. I would say that the difference between validation...we're beyond the stage of validation. We're working with clients who are ready to build a foundation. They really need to put in the infrastructure that's going to take their product and get it ready to scale into the future. So they really need to make that investment into the longer-term strategy. They need to know what's realistic to build first. But they also have to keep an eye on the long road ahead of building something that can be something that can set out to grow down the road as well.

+ +

CHAD: I guess another way of putting it is that Ignite often works with brand new teams, brand new companies creating something for the first time. And Lift Off typically works with existing companies who have existing significant revenue who want to do something new, either a new business or a new product, or maybe they have an existing web product and they're going into mobile for the first time. That's another way of putting it, right?

+ +

EMILY: It could be. I think that when people are ready to move into the Lift Off space, it's about having the investment, the right kind of funding to move in that direction. Sometimes we do work with new founders that have a significant amount of funding, but a lot of times it is folks that are at the enterprise level that are building a new service line. They've got validation and market research already done. And they're building out a completely new line of business that they need to explore and set a new foundation in place.

+ +

CHAD: Do you have some examples of clients that have been projects of Lift Off?

+ +

EMILY: Yeah. We've been doing a lot of really interesting work in the health tech space, a lot of interest in improving patient experience. So we worked with a company called Relias in terms of moving them into a new service line that they'd never been in before, really focusing on improving patient care for therapists, physical therapy therapists. We've also worked with an organization called Groups Recover Together, building out a mobile application for an organization that helps people recover from substance abuse. And we also are working with an organization called Airrosti. That is also an organization that helps in the physical therapy space, so improving patient exercises or rehabilitation through an improved mobile experience, virtual experience to improve overall patient outcomes.

+ +

CHAD: I think it's not a coincidence that a lot of the projects that we work on in Lift Off are in the health tech space because that combination of...like you were saying, a lot of what Lift Off does is really build products that are complex and that are going to scale and have a certain scale fairly quickly and need to really think about more of a platform that's going to be iterated upon into the future. And once you get into a highly regulated industry like health or finance or something, there are so many factors at play, especially if you're an existing business going into that. There's lots to consider. The projects are more complex. And so having a team of people that are focused on working in that kind of environment and know the challenges of doing that and an integrated design and development team who's comfortable operating in that space, I think that that's why it's not a coincidence.

+ +

EMILY: Yeah. I think there's also a lot of great energy in that space right now to move it to the next level. And to be honest, the pandemic really accelerated the need for improvements in patient engagement and allowing therapists or physicians to be able to care for patients in a virtual setting. It also is true not just in health tech, but as you mentioned, we've been actively working with a lot of FinTech companies as well, building out mobile experiences for companies that are helping people get out of debt or working in even some of these new areas like cryptocurrency and things that are changing pretty rapidly in the marketplace and being able to respond to that. But kind of working in a really complex environment some particular industries that have specific compliance security needs in order to be able to serve their customers in a safe way. So working through a lot of those challenges is what's really important and having a team that can navigate through those levels of complexity.

+ +

CHAD: I've talked with the other managing directors about the benefits of our new focus teams and how working on a similar project allows the team members to focus. The other aspect of it is there are parts of what we did under the studio model. And it may have been like there'd be one Lift Off project within...I think we should mention that you used to be the Managing Director of the Durham Studio. And it was a relatively small team working with local clients. And so you may only have one of these kinds of clients a year or maybe even less.

+ +

And so building up an expertise but also meeting the needs of those particular clients there wasn't enough work there, for example, to hire someone with a specific skill set or knowledge if it's only going to be few and far between. And that's been true in Lift Off because we used to, at thoughtbot, not really have product managers. Everyone was designers and developers. And that was because only a subset of our projects really needed a product manager at the table. For the most part, a lot of those smaller projects or the boost-style projects are just developers or designers working directly with a stakeholder. And so, within Lift Off, we've built a product management practice because of that specialized need within these kinds of projects, right?

+ +

EMILY: Yeah, I think just like you said, the ability to really focus in on the first version product is looking at ways that we could improve our process there and provide more support that's really needed for these kinds of engagements. So what we have seen with the more complex MVPs is a lot of these clients need reliability. They need to know that what they're building is the...They need to have more support in terms of the management of that, having someone who's dedicated to being able to straddle between the business objectives and working with the team navigating some of these more complex compliance issues, security issues, and keeping that on track.

+ +

Also, we've been leaning into improving our practices around defining what first version product is. We've been using design sprints to really help align both business owners and the team to determine what are the biggest risk factors? How do we define what we're actually going to build and start building that roadmap? And we've been leaning into those best practices and actually improving upon it.

+ +

And so we've looked at that and built out a discovery sprint that is not just a week-long but really extends that out to about three weeks to give us more time to do more user research, dive a little deeper through the design sprint exercises, but then bring in engineering, bringing an interdisciplinary team to look at the problem from both a product management point of view, a design point of view, and a development point of view to really determine the first version product roadmap and give more clarity to our clients and a clearer sense of what we can accomplish in the first.

+ +

CHAD: I can speak to this firsthand because I was advising and working on a project that started before we reorganized into teams and effectively playing that role. But as the project went on, not that we did a terrible job, but it became overwhelming for me with my other responsibilities and spending a couple of days a week. A couple of days a week is sufficient on a smaller project, but on a much larger project, it's essentially a full-time job to do all of that work. [chuckles] And I just didn't have enough time to be able to do that, let alone then provide a real active management of the roadmap six-plus months out.

+ +

So a very lightweight process with not a lot of definition works when that period is then over in 6 to 12 weeks, and you have something [chuckles] in the market. When you're trying to plan and trying to coordinate work and trying to give clarity around a product and everything that's six-plus months out, it's a whole nother ball game. And it requires a whole nother level of effort, and the clients want that. And so being able to give it to them not only makes them more successful and more confident and feeling like they have that reliability, but it also then puts our team in a better supported set up for success and that kind of thing because they have what they need, and the client has what they need. And everyone's able to really come together and collaborate on building and launching a great product.

+ +

EMILY: Yeah. I think we're always looking at ways that we can improve our process, and as we are taking on more of the complex projects recognizing the need for this role. What's really exciting is the interest in the product management role. It’s been an opportunity for our team members. We've had two senior developers who've wanted to move into that role. And it's been an amazing transformation of with them, similar to you, having that background, the hands-on background of understanding what it means to be a developer on a project but then being able to transition to a different role on the project and get more involved on the business side of things. But that's been extraordinarily successful in making that transition and providing the support that the team needs in order to be successful. So in some ways, it's like we were trying to do that job without really defining it. But now that it's been defined, just recognizing the value that that role plays on these types of projects and seeing the opportunity to even improve it.

+ +

CHAD: I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one on one with a small group of agency founders and leaders toward their business goals. We do one on one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

So we have a bunch of positions open in Lift Off. But product management is one of those positions that we're looking for people, right?

+ +

EMILY: Yeah. We are actually opening up a position for Director of Product Management because the role is so critical to the work that we're doing, just like...I feel like we're extending our design and development model but then adding this third tier of product management, which is just as important in terms of the team that works best for these types of projects. It's having that interdisciplinary core of product management, design, and development working together for new products. A lot of it is really having that high-level oversight, the business strategy integrated in with the folks that can specialize in the development and the design piece. Having to look at the problem from those three different points of view just provides a level of reliability for clients that they just can't get with a single point of view.

+ +

CHAD: What is the size of the product management team now?

+ +

EMILY: Right now? Let's see. I think we've got about five. We have four or five active product managers right now.

+ +

CHAD: So tell us more about the ideal Director of Product Management. What do you think that they would be? Able to lead a team that size while also evolving our product management process and doing product management themselves?

+ +

EMILY: Yeah. I think I'm bringing in somebody who can help us improve our product management process specifically for first version products and really looking at it, and really shaping it, and pulling in the best practices, and really shaping it for the clients that we have I think is one thing I'm looking for the director to do. I'm also looking at the director to upskill our team. Like I said, there are a lot of folks like developers and designers that are actually interested in moving into that role and building up a potential career pathway for folks that may want to move into that area and to ensure that they are successful with that.

+ +

And then growing the team, we are hoping to be able to...I think we've got five active projects right now, so being able to grow our projects and to grow the team so that we can support those kinds of projects on an ongoing basis. So really extending that out and then working collaboratively with our design and development directors to look at how we can collectively put together best practices around first version products.

+ +

CHAD: Awesome. Well, what's on your radar now? What's next for Lift Off besides hiring a Director of Product Management?

+ +

EMILY: [laughs] That's definitely number one. I think what is up next is really focusing in on teamwork. How do we work collectively as a team? Are there ways to improve our process to better serve our clients? We've done a lot of things in the past year. Like I'd mentioned before, we've improved our design sprints and extended them to become discovery sprints. Those are just names, but it's really the beginning stages of kicking off a project more successfully. Looking at ways that we can improve our customer experience and being able to serve clients in a better way, improving our product management across the board for all our projects, looking at ways that throughout the first version product for our clients what other ways can we better support our clients? Either through go-to-market strategies or helping them recruit permanent team members onto their team. But I think what's next for Lift Off is really examining how we service clients and looking at ways that we can actually make it even better.

+ +

CHAD: Cool. Well, I want to change gears a little bit and ask you about you.

+ +

EMILY: [laughs]

+ +

CHAD: So your background, I think it's important to say is as a designer, right?

+ +

EMILY: Yeah, that's one of my backgrounds.

+ +

[laughter]

+ +

CHAD: Okay, you have a varied background. But what were you doing when you joined thoughtbot and moved into the Managing Director role? And how has that evolved over time?

+ +

EMILY: I think it's really interesting. You're always leaning into something. And as you look back at your past, even if it doesn't seem to make sense, you're always gravitating to something that is your North Star. Before I joined thoughtbot, I actually ran my own agency, which was called UX-Shop. And it was a team of one; it was me. As I was building up that agency, I recognized that I couldn't do it all. The types of projects that I wanted to work on were more complex. And so, when I started UX-Shop, I would be pulling in talent to create the type of team that would make that project more successful. It was hard to continually do that in a way where I had to recruit talent [laughs] and secure projects as well without having them as permanent employees.

+ +

When I joined thoughtbot, it was an opportunity where I had access to amazing talent. And I could really focus in on building that, first off doing it in the Raleigh, Durham office where we went from a team of four to I think we grew the team to about nine. And starting to really grow that office to transitioning to this new model where we went from a team of nine to...I don't know the exact number, but I think it's like 25, 28. We're heading toward the 30 mark. So it's a significantly larger team with the ability to really focus in on the kind of projects that I actually really love, which is new product design and development but going after those more complex projects.

+ +

And I think when I start looking back at my own career, I'm just starting to see patterns of the same focus but the opportunity to dive into it in a bigger way, in a more challenging way, and starting to tackle that. So thoughtbot's really given me the opportunity to take that ambition and actually apply it with the opportunity to have the talented team to be able to execute on those types of projects.

+ +

CHAD: How has going from a team of one to a team of four to a team of nine to a team of pushing 30...are there things that you've needed to evolve in your own skillset or experiences?

+ +

EMILY: Yeah. I think certainly building leadership skills, understanding how to work through a lot of challenges on what makes a team work really well together, making sure that we've got the guidelines and structures in place. There are a lot of things that I've grown just having the opportunity to work through some of those challenges. But also, in some ways, growing into a larger team has made some things a little easier. But it was nice having that progression from a smaller team to a larger team.

+ +

I don't know if I would have been as successful with growing to a team of 30 right off the bat without being able to work in that smaller space, kind of learn my lessons, and then build upon those and grow that unit, get better at what I was doing. The reason why Lift Off is really starting to thrive is understanding that that foundation is built upon a lot of trial and error and just learning how to navigate and improve my own personal leadership skills.

+ +

CHAD: Are there any particular resources that you called upon in order to do that?

+ +

EMILY: So certainly reaching out to folks who are in similar positions. There's a strong community here where I live in Durham, talking to a lot of founders or folks in the leadership space who are growing teams. I've had some coaching with executive coaching that's helped quite a bit, especially when I've been in situations that I just wanted to make sure that I was handling them in the right way. And then, of course, having access to the folks at thoughtbot like you, Chad, and people that I can talk to and get advice on how to navigate tricky situations have all been contributing to my education and making me a better leader in this space.

+ +

CHAD: Would you recommend coaching to other people?

+ +

EMILY: I would. I think it's a real opportunity for you to...there's a lot of things that you don't really know that you don't know. And there's a lot of ways of approaching things in a different way on how you communicate. That is the difference between really getting through and solving a problem versus having a situation arise and escalate and become problematic. And it's a little bit of understanding how to frame things in a thoughtful way.

+ +

It's also an opportunity to understand that sometimes you just need to have some space to think before responding and understanding how to navigate complexity, especially in today's world where leadership there's so much going on, transitioning to remote. There are different things that are pulling at us in different aspects and just really understanding the human element of your teams. So having someone who you can talk to in a way that you can share those ideas and get a different perspective, I think, is really helpful.

+ +

CHAD: Yeah. Well, if folks want to get in touch with you or Lift Off, what's the best places for them to do that?

+ +

EMILY: Well, there's always my email, emily@thoughtbot.com. I think just reaching out to me directly is the best place. I'm always happy to talk about Lift Off or have an intro coffee call with folks that are interested in what we do. So that's the best way to get in touch with me.

+ +

CHAD: Excellent. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

Special Guest: Emily Bahna.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Emily Bahna a Managing Director at thoughtbot who leads the Lift Off team, where they focus on really leaning into the core of the company. The team works with new founders to launch new products or they work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But, the thing that ties Lift Off together, is that they start at ground zero to build upon an idea and actually build the first version product to get it out live into the marketplace.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Emily Bahna, Managing Director of thoughtbot's Lift Off team. Emily, thanks for joining me.

+ +

EMILY: Thank you.

+ +

CHAD: So at this point, we've talked with a few of the different managing directors at thoughtbot about their teams. And Lift Off is one of the largest teams that we have. And so what is it that Lift Off actually does?

+ +

EMILY: Lift Off is focused in on really leaning into the core of thoughtbot. We work with new founders launching new products or work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But I think the thing that ties Lift Off together is that we are starting at ground zero building upon an idea and actually building the first version product and getting it out into the marketplace.

+ +

CHAD: And oftentimes, those are pretty significant endeavors. The last episode that came out was with Dawn at Ignite who is more on the validation, early stage, getting things that are fairly straightforward into market as quickly as possible usually in a matter of months. But Lift Off the endeavors are usually quite a bit more significant than that, right?

+ +

EMILY: Yeah. I would say that the difference between validation...we're beyond the stage of validation. We're working with clients who are ready to build a foundation. They really need to put in the infrastructure that's going to take their product and get it ready to scale into the future. So they really need to make that investment into the longer-term strategy. They need to know what's realistic to build first. But they also have to keep an eye on the long road ahead of building something that can be something that can set out to grow down the road as well.

+ +

CHAD: I guess another way of putting it is that Ignite often works with brand new teams, brand new companies creating something for the first time. And Lift Off typically works with existing companies who have existing significant revenue who want to do something new, either a new business or a new product, or maybe they have an existing web product and they're going into mobile for the first time. That's another way of putting it, right?

+ +

EMILY: It could be. I think that when people are ready to move into the Lift Off space, it's about having the investment, the right kind of funding to move in that direction. Sometimes we do work with new founders that have a significant amount of funding, but a lot of times it is folks that are at the enterprise level that are building a new service line. They've got validation and market research already done. And they're building out a completely new line of business that they need to explore and set a new foundation in place.

+ +

CHAD: Do you have some examples of clients that have been projects of Lift Off?

+ +

EMILY: Yeah. We've been doing a lot of really interesting work in the health tech space, a lot of interest in improving patient experience. So we worked with a company called Relias in terms of moving them into a new service line that they'd never been in before, really focusing on improving patient care for therapists, physical therapy therapists. We've also worked with an organization called Groups Recover Together, building out a mobile application for an organization that helps people recover from substance abuse. And we also are working with an organization called Airrosti. That is also an organization that helps in the physical therapy space, so improving patient exercises or rehabilitation through an improved mobile experience, virtual experience to improve overall patient outcomes.

+ +

CHAD: I think it's not a coincidence that a lot of the projects that we work on in Lift Off are in the health tech space because that combination of...like you were saying, a lot of what Lift Off does is really build products that are complex and that are going to scale and have a certain scale fairly quickly and need to really think about more of a platform that's going to be iterated upon into the future. And once you get into a highly regulated industry like health or finance or something, there are so many factors at play, especially if you're an existing business going into that. There's lots to consider. The projects are more complex. And so having a team of people that are focused on working in that kind of environment and know the challenges of doing that and an integrated design and development team who's comfortable operating in that space, I think that that's why it's not a coincidence.

+ +

EMILY: Yeah. I think there's also a lot of great energy in that space right now to move it to the next level. And to be honest, the pandemic really accelerated the need for improvements in patient engagement and allowing therapists or physicians to be able to care for patients in a virtual setting. It also is true not just in health tech, but as you mentioned, we've been actively working with a lot of FinTech companies as well, building out mobile experiences for companies that are helping people get out of debt or working in even some of these new areas like cryptocurrency and things that are changing pretty rapidly in the marketplace and being able to respond to that. But kind of working in a really complex environment some particular industries that have specific compliance security needs in order to be able to serve their customers in a safe way. So working through a lot of those challenges is what's really important and having a team that can navigate through those levels of complexity.

+ +

CHAD: I've talked with the other managing directors about the benefits of our new focus teams and how working on a similar project allows the team members to focus. The other aspect of it is there are parts of what we did under the studio model. And it may have been like there'd be one Lift Off project within...I think we should mention that you used to be the Managing Director of the Durham Studio. And it was a relatively small team working with local clients. And so you may only have one of these kinds of clients a year or maybe even less.

+ +

And so building up an expertise but also meeting the needs of those particular clients there wasn't enough work there, for example, to hire someone with a specific skill set or knowledge if it's only going to be few and far between. And that's been true in Lift Off because we used to, at thoughtbot, not really have product managers. Everyone was designers and developers. And that was because only a subset of our projects really needed a product manager at the table. For the most part, a lot of those smaller projects or the boost-style projects are just developers or designers working directly with a stakeholder. And so, within Lift Off, we've built a product management practice because of that specialized need within these kinds of projects, right?

+ +

EMILY: Yeah, I think just like you said, the ability to really focus in on the first version product is looking at ways that we could improve our process there and provide more support that's really needed for these kinds of engagements. So what we have seen with the more complex MVPs is a lot of these clients need reliability. They need to know that what they're building is the...They need to have more support in terms of the management of that, having someone who's dedicated to being able to straddle between the business objectives and working with the team navigating some of these more complex compliance issues, security issues, and keeping that on track.

+ +

Also, we've been leaning into improving our practices around defining what first version product is. We've been using design sprints to really help align both business owners and the team to determine what are the biggest risk factors? How do we define what we're actually going to build and start building that roadmap? And we've been leaning into those best practices and actually improving upon it.

+ +

And so we've looked at that and built out a discovery sprint that is not just a week-long but really extends that out to about three weeks to give us more time to do more user research, dive a little deeper through the design sprint exercises, but then bring in engineering, bringing an interdisciplinary team to look at the problem from both a product management point of view, a design point of view, and a development point of view to really determine the first version product roadmap and give more clarity to our clients and a clearer sense of what we can accomplish in the first.

+ +

CHAD: I can speak to this firsthand because I was advising and working on a project that started before we reorganized into teams and effectively playing that role. But as the project went on, not that we did a terrible job, but it became overwhelming for me with my other responsibilities and spending a couple of days a week. A couple of days a week is sufficient on a smaller project, but on a much larger project, it's essentially a full-time job to do all of that work. [chuckles] And I just didn't have enough time to be able to do that, let alone then provide a real active management of the roadmap six-plus months out.

+ +

So a very lightweight process with not a lot of definition works when that period is then over in 6 to 12 weeks, and you have something [chuckles] in the market. When you're trying to plan and trying to coordinate work and trying to give clarity around a product and everything that's six-plus months out, it's a whole nother ball game. And it requires a whole nother level of effort, and the clients want that. And so being able to give it to them not only makes them more successful and more confident and feeling like they have that reliability, but it also then puts our team in a better supported set up for success and that kind of thing because they have what they need, and the client has what they need. And everyone's able to really come together and collaborate on building and launching a great product.

+ +

EMILY: Yeah. I think we're always looking at ways that we can improve our process, and as we are taking on more of the complex projects recognizing the need for this role. What's really exciting is the interest in the product management role. It’s been an opportunity for our team members. We've had two senior developers who've wanted to move into that role. And it's been an amazing transformation of with them, similar to you, having that background, the hands-on background of understanding what it means to be a developer on a project but then being able to transition to a different role on the project and get more involved on the business side of things. But that's been extraordinarily successful in making that transition and providing the support that the team needs in order to be successful. So in some ways, it's like we were trying to do that job without really defining it. But now that it's been defined, just recognizing the value that that role plays on these types of projects and seeing the opportunity to even improve it.

+ +

CHAD: I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one on one with a small group of agency founders and leaders toward their business goals. We do one on one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.

+ +

So we have a bunch of positions open in Lift Off. But product management is one of those positions that we're looking for people, right?

+ +

EMILY: Yeah. We are actually opening up a position for Director of Product Management because the role is so critical to the work that we're doing, just like...I feel like we're extending our design and development model but then adding this third tier of product management, which is just as important in terms of the team that works best for these types of projects. It's having that interdisciplinary core of product management, design, and development working together for new products. A lot of it is really having that high-level oversight, the business strategy integrated in with the folks that can specialize in the development and the design piece. Having to look at the problem from those three different points of view just provides a level of reliability for clients that they just can't get with a single point of view.

+ +

CHAD: What is the size of the product management team now?

+ +

EMILY: Right now? Let's see. I think we've got about five. We have four or five active product managers right now.

+ +

CHAD: So tell us more about the ideal Director of Product Management. What do you think that they would be? Able to lead a team that size while also evolving our product management process and doing product management themselves?

+ +

EMILY: Yeah. I think I'm bringing in somebody who can help us improve our product management process specifically for first version products and really looking at it, and really shaping it, and pulling in the best practices, and really shaping it for the clients that we have I think is one thing I'm looking for the director to do. I'm also looking at the director to upskill our team. Like I said, there are a lot of folks like developers and designers that are actually interested in moving into that role and building up a potential career pathway for folks that may want to move into that area and to ensure that they are successful with that.

+ +

And then growing the team, we are hoping to be able to...I think we've got five active projects right now, so being able to grow our projects and to grow the team so that we can support those kinds of projects on an ongoing basis. So really extending that out and then working collaboratively with our design and development directors to look at how we can collectively put together best practices around first version products.

+ +

CHAD: Awesome. Well, what's on your radar now? What's next for Lift Off besides hiring a Director of Product Management?

+ +

EMILY: [laughs] That's definitely number one. I think what is up next is really focusing in on teamwork. How do we work collectively as a team? Are there ways to improve our process to better serve our clients? We've done a lot of things in the past year. Like I'd mentioned before, we've improved our design sprints and extended them to become discovery sprints. Those are just names, but it's really the beginning stages of kicking off a project more successfully. Looking at ways that we can improve our customer experience and being able to serve clients in a better way, improving our product management across the board for all our projects, looking at ways that throughout the first version product for our clients what other ways can we better support our clients? Either through go-to-market strategies or helping them recruit permanent team members onto their team. But I think what's next for Lift Off is really examining how we service clients and looking at ways that we can actually make it even better.

+ +

CHAD: Cool. Well, I want to change gears a little bit and ask you about you.

+ +

EMILY: [laughs]

+ +

CHAD: So your background, I think it's important to say is as a designer, right?

+ +

EMILY: Yeah, that's one of my backgrounds.

+ +

[laughter]

+ +

CHAD: Okay, you have a varied background. But what were you doing when you joined thoughtbot and moved into the Managing Director role? And how has that evolved over time?

+ +

EMILY: I think it's really interesting. You're always leaning into something. And as you look back at your past, even if it doesn't seem to make sense, you're always gravitating to something that is your North Star. Before I joined thoughtbot, I actually ran my own agency, which was called UX-Shop. And it was a team of one; it was me. As I was building up that agency, I recognized that I couldn't do it all. The types of projects that I wanted to work on were more complex. And so, when I started UX-Shop, I would be pulling in talent to create the type of team that would make that project more successful. It was hard to continually do that in a way where I had to recruit talent [laughs] and secure projects as well without having them as permanent employees.

+ +

When I joined thoughtbot, it was an opportunity where I had access to amazing talent. And I could really focus in on building that, first off doing it in the Raleigh, Durham office where we went from a team of four to I think we grew the team to about nine. And starting to really grow that office to transitioning to this new model where we went from a team of nine to...I don't know the exact number, but I think it's like 25, 28. We're heading toward the 30 mark. So it's a significantly larger team with the ability to really focus in on the kind of projects that I actually really love, which is new product design and development but going after those more complex projects.

+ +

And I think when I start looking back at my own career, I'm just starting to see patterns of the same focus but the opportunity to dive into it in a bigger way, in a more challenging way, and starting to tackle that. So thoughtbot's really given me the opportunity to take that ambition and actually apply it with the opportunity to have the talented team to be able to execute on those types of projects.

+ +

CHAD: How has going from a team of one to a team of four to a team of nine to a team of pushing 30...are there things that you've needed to evolve in your own skillset or experiences?

+ +

EMILY: Yeah. I think certainly building leadership skills, understanding how to work through a lot of challenges on what makes a team work really well together, making sure that we've got the guidelines and structures in place. There are a lot of things that I've grown just having the opportunity to work through some of those challenges. But also, in some ways, growing into a larger team has made some things a little easier. But it was nice having that progression from a smaller team to a larger team.

+ +

I don't know if I would have been as successful with growing to a team of 30 right off the bat without being able to work in that smaller space, kind of learn my lessons, and then build upon those and grow that unit, get better at what I was doing. The reason why Lift Off is really starting to thrive is understanding that that foundation is built upon a lot of trial and error and just learning how to navigate and improve my own personal leadership skills.

+ +

CHAD: Are there any particular resources that you called upon in order to do that?

+ +

EMILY: So certainly reaching out to folks who are in similar positions. There's a strong community here where I live in Durham, talking to a lot of founders or folks in the leadership space who are growing teams. I've had some coaching with executive coaching that's helped quite a bit, especially when I've been in situations that I just wanted to make sure that I was handling them in the right way. And then, of course, having access to the folks at thoughtbot like you, Chad, and people that I can talk to and get advice on how to navigate tricky situations have all been contributing to my education and making me a better leader in this space.

+ +

CHAD: Would you recommend coaching to other people?

+ +

EMILY: I would. I think it's a real opportunity for you to...there's a lot of things that you don't really know that you don't know. And there's a lot of ways of approaching things in a different way on how you communicate. That is the difference between really getting through and solving a problem versus having a situation arise and escalate and become problematic. And it's a little bit of understanding how to frame things in a thoughtful way.

+ +

It's also an opportunity to understand that sometimes you just need to have some space to think before responding and understanding how to navigate complexity, especially in today's world where leadership there's so much going on, transitioning to remote. There are different things that are pulling at us in different aspects and just really understanding the human element of your teams. So having someone who you can talk to in a way that you can share those ideas and get a different perspective, I think, is really helpful.

+ +

CHAD: Yeah. Well, if folks want to get in touch with you or Lift Off, what's the best places for them to do that?

+ +

EMILY: Well, there's always my email, emily@thoughtbot.com. I think just reaching out to me directly is the best place. I'm always happy to talk about Lift Off or have an intro coffee call with folks that are interested in what we do. So that's the best way to get in touch with me.

+ +

CHAD: Excellent. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

Special Guest: Emily Bahna.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+sP02R1pQ + + ]]> + + Chad Pytel + Emily Bahna + + + 401: thoughtbot Ignite with Dawn Delatte + https://podcast.thoughtbot.com/401 + 68ae9765-1355-4418-977d-939828e2f6ce + Thu, 18 Nov 2021 00:15:00 -0500 + thoughtbot + + full + 11 + thoughtbot + Dawn Delatte a Designer and Managing Director at thoughtbot who leads the Ignite team, where they focus primarily on validating and launching early-stage products through design-thinking, business and product strategy, and iterative design and development. Dawn works collaboratively with designers and developers to ensure they add value to the people and products thoughtbot works with every day. + 35:36 + no + + + Dawn Delatte a Designer and Managing Director at thoughtbot who leads the Ignite team, where they focus primarily on validating and launching early-stage products through design-thinking, business and product strategy, and iterative design and development. Dawn works collaboratively with designers and developers to ensure they add value to the people and products thoughtbot works with every day. +Follow Dawn on Twitter (https://twitter.com/dawndig) or LinkedIn (https://www.linkedin.com/in/dawndelatte/). +Visit her website at dawndelatte.com (http://dawndelatte.com/). +thoughtbot's Ignite team (https://thoughtbot.com/ignite) +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dawn Delatte, Managing Director of the thoughtbot Ignite team. Dawn, thanks for joining me. +DAWN: Hi, thanks for having me. +CHAD: Ignite is one of the examples I always use when I talk about why we split up into teams the way that we did and what the benefits are, Dawn. So why don't you tell people what Ignite actually does? +DAWN: Cool. So the Ignite team we work with entrepreneurs, and non-technical startup founders, in some cases, experienced startup founders, as well as innovation teams within existing organizations. And we work with them to validate their product ideas and deliver very initial versions of their products to continue that validation process. We provide all kinds of services around that from a validation perspective. We use product sprint methodology to understand the opportunity, understand the market, the problem, come up with solutions, all those things to arrive at some ideas and some solutions that we can then quickly prototype and then test with target users depending on who we've decided their customer is or who they've decided their customer is. And that's very high level. I'm happy to get into more detail about what our discovery sprints are like. +But after that, then we would go into, like I said, continued validation but through actual product launches. So sometimes that looks like proof of concepts, sometimes that's first MVPs. But either way, we focus on a set of goals, and that could be a certain number of users onboarded to the platform. It could be getting that next round of investment funding. But it's pretty straightforward, not a whole lot of complexity, and focused on getting a product and company to that next best stage. +CHAD: One of the reasons why I use Ignite is that it's on one end of the spectrum. It's at the extreme end of the spectrum. Last week, I talked to Josh, who's on the other end of Boost, where we're working on existing products with existing teams. And Ignite is all the way on the other side, which is sometimes we are not even writing any code at all; we're just validating an idea. +The work that Ignite does has always been a very important part of what thoughtbot does. But it's a big challenge to go from a product where maybe you have hundreds of thousands or millions of users and a large team, and you're doing development as a developer or designer, maybe it's healthcare or something super complex, and then to the next week where you're working on something that is going to get into market very quickly, maybe is totally unproven. The things you need to do in that environment and the way that you need to work can be a little bit different. +And so allowing the thoughtbot designers and developers to focus on the particular needs of the Ignite-type clients I think we have seen, and I think we'll continue to see it as people even get more used to it, it has a direct benefit to our clients as well The best thing might not always be to write a Rails app. But if you take a developer who was on a Rails app on Friday or Thursday, and then they start on a new project on Monday, chances are they're expecting to write a Rails app. +DAWN: That's a really important observation and distinction about what our developers do compared to other developers at thoughtbot. I've always said that selling any kind of project or working with new clients with any type of project, whether it's very early stage or that enterprise client that we all wear our product consulting hats, or we're product consultants first, and then we have our toolkit. But I think that is the most true, at least from my experience, in the Ignite team. +And we've even talked about and, in some cases, have been able to blur the lines even more between designers and developers because first and foremost, you're coming to the problems thinking about it exactly how you're talking about. Like, what is it going to take to make this product launch successful? It might not involve writing very much code. And we might not discover that until after we've been working together for a couple of weeks and started to validate some of the ideas we have. And so, being able to have that adaptability and really focus on the consulting and strategy aspect of things is super important. +CHAD: So if there is a typical or Ignite client that we're working with, what does it look like? +DAWN: I would say a typical...so who we've engaged the most with are non-technical founders and entrepreneurs. And I say non-technical but what I really mean is they haven't had the experience of launching a product and going through that process. +CHAD: A digital product. +DAWN: Yeah, a digital product. So for lack of a better way to describe them, non-technical because there's a lot of work involved in helping them understand product strategy and technical architecting and everything that happens in between. So that's who we've been able to work with primarily while we've also worked with other types of clients. +CHAD: What is typically the first step with clients? At what stage are they at, and what is the first step that we're taking them through? +DAWN: The sales process is a little bit different. We're not talking about requirements. And we're not exactly talking about what the end product looks like. If the conversation is going that way, we're usually trying to bring it back a little bit and keep things more high level just to make sure that we have a really good sense of what it is that we should try to do. +So the sales process is we're already starting to dig into validation processes and making sure that our clients are able to define their customers and define the problem, and have started to think about their value proposition from a business perspective, and have made other considerations that through all of our experience, all the years that we have experience with shipping products, make sure that the client understands at least at a very high level what the big components for success are going to be. And if they haven't started to make decisions about those things, that they know that we can help them do that. +So that conversation is already starting in the sales process, which is great because we can get the team involved, and everybody starts wrapping their head around the problem. And by the time that we actually kick off the project, we're really excited because we all are ready, and we have ideas for what we can do together. +But the first stage is usually always what we call a discovery sprint. So we've been doing Product Design Sprints for a long time at thoughtbot. And we've always been iterative with everything we do. But with Product Design Sprints, especially because every single one of them is unique, you have to figure out either what exercises you're going to do that make the most sense for this client in this project. +We had, I guess a bigger iteration of the Product Design Sprint as a whole. And we've moved into this concept of a discovery sprint or a discovery phase. And it allows us to do a couple of things. So the Product Design Sprint was largely modeled after the Google Ventures Sprint, which is this intensive five-day process where you quickly understand the problem, come up with some solutions together, prototype, and test within five days. We've elongated that process a little bit. So we definitely do two weeks, sometimes four if there's a lot to uncover and make sure we understand about the market before we start writing code or before we start doing the next phase of work together. +And we kick off with a lot of the same processes. So like I keep saying, making sure you understand the problem, making sure you've defined the customer, the opportunities. In some cases, at least with our clients, we're actually doing lean model canvas work because our clients haven't always thought through how they're going to make money off of this product and what their competitive landscape looks like and things like that. We incorporate a lot of that business strategy into the product strategy work that we're doing during this phase. +But yeah, the first week of a discovery sprint is usually those kinds of exercises, working together through all this institutional knowledge that the client might have. Because usually, they're experiencing this problem or they've been in this industry,and they know what the problems of their customers have, and so they can talk a lot about it. And then, we move into some of the more traditional Product Design Sprint phases, so diverge exercises, converge exercises that help us to come up with a bunch of ideas for what the product should be or should do. And then decide as a group which ones are the strongest so that we can move into prototyping. +We prototype. We test with either existing customers in this space, or we get anonymous users based on certain demographics that are important to validate the concept with, and then we test. And then, we do that iteratively throughout the process to make sure that we're capturing as much data as we can to feel confident about how validation is going. Or, in some cases, it might make sense for us to think about the next phase of validation actually being more like a proof of concept. And so we can jump into that really quickly depending on how validation is going. +A lot of times, at the end of discovery spreads, we've incorporated some technical planning and architecting into the process. Sometimes we have to validate that the launch approach is going to work from a technical perspective. And so that's the kind of research that our developer would be doing in this process. And by the end of this phase, we have a presentation of our findings, an architectural diagram if that's where we're leaning or where we would recommend the next stage go. We would present all that information and make a decision. Sometimes we invalidate. We largely invalidate some of the ideas that we came up with, and we have to go back to the drawing board. +CHAD: Have we worked with any clients recently that had a major invalidation where they really needed to go back to the drawing board based on what we learned with the whole concept? +DAWN: We did have a client that we worked with this year that we didn't invalidate things during the sprint but not far into the product build, we realized that we were going to need some other infrastructure in place in order for that product to be successful. So we actually did a more traditional Product Design Sprint with this client. Part of the reasoning was…, and this product idea was in the real estate space. [chuckles] The idea was to open up the market a little bit by...I don't want to say eliminating, but I guess, in a way eliminating certain aspects of what a realtor might do in the process of buying and selling real estate. +It is possible to knock on somebody's door and ask them if you can buy their house, and then the transaction is facilitated through a realtor. But this would open up the possibility of this happening digitally through a product. So there’s certain data that you can pull from real estate sites out there that let you know certain things about a property. And this is public information; anybody can find it. +And the concept was to have homeowners who might potentially be interested in selling their properties be on the platform and have their homes be available to anybody that might be looking or vice versa. Like, someone who's buying could get on the platform and see what kind of homes are in their area; maybe they have a particular area that they want to buy in and essentially cut out the realtor in that they could go directly to the property owner and inquire about their home or see if they might be interested in selling it. So that was, at a high level, the product idea. +We did a more traditional sprint with them because the client was obviously very familiar with this space and really understood the opportunity well. And there are not a lot of competitors in this space in the U.S., at least. Our goal was ultimately to get to a plan for MVP. And so we spent time validating the user experience and at a high level, making sure that we were confident and moving forward with everything. And we felt like we got validation for that. +And we got started on the project, and we realized there's actually a lot to this space. It's very heavily...if not regulated, there are all sorts of processes in place that require very specific people and roles to accomplish different things and facilitate the process. It's also because of the role that a realtor has played for so long. People aren't very educated on what this process could be like, buying and selling homes, especially with a direct transaction. And so there was way more to uncover and to understand and to work through on the business side than we had initially anticipated. And so we decided to quickly bring in somebody to focus on product strategy while we were also iteratively working through an MVP launch. +So we decided to test as often as we can and constantly be working through on a weekly basis what it was that we were building, making sure that that aligned with what we were learning in real-time, essentially. The product strategist came on and started to continue some of the competitor research that we had started in the Product Design Sprints really try to understand the market and try to work very directly with the clients who were both in real estate to quickly make decisions about the direction that we were going in while we were also iterating on this product idea. +About halfway through, which is standard to Ignite a 12 to 16-week MVP launch, so about halfway through at about six weeks in, we decided that we needed to continue validating with a working prototype as opposed to continuing to chug along until we got to MVP launch and just see what happened. That was feeling too risky as we were learning more and more about the market. So I wouldn't say we invalidated anything, but as we continued to validate and as we started to build iteratively realized that we needed to spend a lot more time on validating the product idea and that it made sense to do that with a working product. And so, we pivoted in that way once we had started building. +CHAD: Yeah, that's cool. I often say that it's fairly rare that we completely invalidate the core of someone's idea. But it's not at all rare that it changes based on what everyone is learning along the way, whether that be in a Product Design Sprint or discovery sprint. And I think that's one of the things that not only does it make products more successful because you're reducing risk and you're changing them based on the things that you'll learn, but I also think it leads to the working environment that I want to be a part of where it's very collaborative; everyone's building off of each other's ideas. We're changing based on what we learn rapidly. I really love doing that. +DAWN: Yeah. +AD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU. +AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more, and many of the AgencyU members are now working on client projects together and referring work to each other. +Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I’ve seen and learned from a lot of different situations, and I’d be happy to work with you. +Learn more and sign up at thoughtbot.com/agencyu +DAWN: And it's funny what you just said about learning versus invalidating. I literally just got off of a call with somebody right before I joined this, and we touched on that exact same thing. They've been building a prototype and going through their own validation phases. And this person pointed out that they didn't want to call the work that they had been doing validation that they wanted to call it learning. And I just thought that was very poignant. I feel like I call it continued validation when I'm talking about delivering a proof of concept or initial MVP because, really, that's what it is. But I think a better way to say it is just learning. You're learning from the process and from your market, and it's all at the same time. It's very agile in that way. +CHAD: One of the meta reasons why I like that from a thoughtbot perspective is that oftentimes, founders, in particular, can be very precious about their ideas or not want to give up. And so this idea of oh, it could potentially be invalidated is almost like a confrontational tension or something that even when they are shown something they might not be willing to adjust because it's not their original idea. And the word learning subtly de-escalates that a little bit. It's like, what have we learned? [laughs] Have we learned something that we can take into play? It's not invalidating the idea. +DAWN: Yeah, I find that using the term like de-risking does a similar thing. Because whether or not you're an investor, that's a term that I think everybody can understand. Like, let's try to learn from and lower the risk of us not being successful with each step we take. The ultimate goal is product success and business success, and we want to get people there. But we want to make sure we do it the right way. And we want to make sure that all the decisions that we're making early on have positive, long-term effects. So yeah, de-risking and learning. I think I'm going to change the way I talk about validation now. [laughter] +CHAD: So what else is Ignite working towards now? I know that you have...everywhere at thoughtbot, we've got a bunch of open positions open. So you're actively hiring, right? +DAWN: Yeah. So going back to what you were saying and what we were talking about earlier, a lot of what we've been thinking through on the development side is what skills are really necessary and important for our developers to have for the types of projects and the type of work that we're doing. We made an assumption and have been working through learning [laughter] whether or not that assumption is true that we don't necessarily need a ton of back-end Rails expertise to be able to deliver products in the way that we're thinking. Rails has always been really good with MVPs, really good for MVPs and speed to market and things like that. But I think that we are thinking through how we can be even more agile and iterative with product delivery. +So we're leaning towards skill sets that focus on the front end, so delivering that really great consumer or user experience on the front end because MVP and startup space is incredibly competitive nowadays. We have to be thinking through, I think, more than what we did maybe ten years ago when we were delivering MVPs for startups. So we're focusing more on the front end. We're focusing more on the user experience. And we're thinking through how we can utilize existing tooling on the back end to support the products that we're building, which we assume is going to require a lot less particular expertise and a back-end language like Rails and a lot more openness to making decisions that make the most sense for that product idea in particular so whether that's pulling together existing tools on the back end. +CHAD: Well, I find it useful to think about...or one way to articulate this is mobile apps in particular because some people might not get the distinction with a web app the difference between the front end and the back end. I think it's maybe a little bit more obvious with things like React and that kind of thing. But if you take a mobile app, for example, in order to actually build and launch a mobile app, we typically need to build the mobile app, and then that mobile app needs to talk to servers on the backside. +And put quite plainly, if we have a Rails developer on the project and a mobile developer on the project, that's two people. And if instead, we can have a mobile developer who is putting together some back-end services from companies like Google or Twilio or those kinds of things, to get to the next stage of the company, it's going to be a lot cheaper and potentially faster for the stage that that company is at if it makes sense then. That doesn't mean that they won't ever need a back end of their own, right? +DAWN: Yeah. Well, and I'm learning more and more too that making those kinds of decisions now doesn't necessarily mean that I can't scale, even with the services that we pull together for the back end at that time when we do the initial launch. AWS, for instance, has a ton of capability for initial launches and for scaling. So there are a lot of options. That's what's become more important to us when we think through the development expertise on our team is not only experience with delivering early-stage products, because you're in that mindset, but openness to working with different technologies that would allow you to, like you're saying, plug into these different tools and servers and systems that already working for a particular industry, for instance. +I mean, e-commerce is one that you think of where we definitely don't want to be reinventing any wheels there. [laughs] From a conceptual perspective, yes, and from a competitive perspective, yes. But from a back-end development and architectural perspective, there's so much that we can utilize that already exists. So yeah, we are hiring. [laughter] I think that was your original question. And we have open developer positions, which is why I was focused on that. +Our development focuses less around what you've historically seen at thoughtbot, which is we need Rails developers. We need full-stack developers who can for sure stand up a custom back end. And we've shifted to...we definitely need to focus on the front end. We need that expertise. And we need some adaptability around back-end tooling and being able to pull stuff together that way. +CHAD: So you were the Managing Director of the Austin studio. And now you're the Managing Director of the Ignite team. Before that, you were a designer. How has this transition compared to prior transitions that you've been a part of? +DAWN: I think the biggest difference, and this has been just as challenging as it has been rewarding, and I think positive for our business, is the fact that I can focus on expanding our services and expanding our expertise in this one area. Before, we had the local studios, and we could work across the entire product lifecycle. And from a sales and business development perspective, that both gave me varied experience. And it gave me a lot of levers to pull, especially with the teams and making sure that we were all working on different things and able to cycle through different types of projects. But that's hard to do, and it's a lot of work. [laughs] And being able to focus on one stage of the product lifecycle and a set of clients, and expand our expertise in that area has been really challenging and really rewarding. +We've been able to sink our teeth in and imagine what possibilities are here and explore markets that we haven't before and actually think through how we can build partnerships with people and really become experts in this space in a way that we haven't been able to in the past because there hasn't been dedicated time and dedicated effort in particular. So the transition has been really great in that way. I'm really excited about it. +CHAD: Well, that's good. [laughter] You were out on parental leave for a fair amount of time. How long was it in total? +DAWN: About four months. +CHAD: Welcome back, by the way. +DAWN: Thank you. +CHAD: I'm curious on your perspective either with Ignite or maybe even more so thoughtbot overall. How was it being away, and what surprised you when you came back? +DAWN: So a couple of things, we were a smaller team in the beginning of this year. We knew that we were going to have to be iterative with our approach to refining our positioning as a team and understanding all these things that we're talking about, like our clients and our customers, and who we're going to work with, how we're going to work with them, how we're going to deliver value. We knew that we were going to have to be iterative. So we went through some phases this year. We were experimental and applied our validation processes to Ignite as a business. And we learned a ton of stuff. And we're going in a great direction. And then I was out for four months [laughter], and so there was a gap. And I tried very hard not to check my email. I mostly did a good job of it. +And so I was telling Diana, our CEO, earlier that I feel a little bit like we're going into 2022 with a fresh start even though we have this whole year behind us that we learned from. We got to a point where we're going in a particular direction now. And we validated enough and felt strongly enough about the direction that we're going in that we're hitting the ground running now going into next year. And I don't know what I assumed; maybe I assumed that we would have established a little bit more this year in the direction that we initially intended. And it's not like a far departure. It's just that it's certainly evolved beyond what I was imagining initially from the technical perspective, for instance. +CHAD: Well, even in Ignite, which is pretty short client cycles, we're not so huge. [chuckles] Ignite might do 12 projects in a year, and that might be a lot. So we get a lot of opportunities to try new things. And the cycle time isn't that long, but it's not super-fast pace, and it's not super high volume. So it does take some time to refine things based on what we learn, even in Ignite, which is typically faster cycles. +DAWN: Yeah, that's true. If you think of it that way, a lot of our projects if we're doing an MVP launch, for instance, it's about a quarter along. And if we only do a couple of those every quarter, it takes those whole cycles to be able to look at things in retrospect. I agree; it takes a little bit longer to learn overall. +I like the way that you put it, too, like when you really look back and think of it, even though we do a lot of what you would consider rapid projects, it's still going to take some time to learn. And I think overall, and I think this is true for all of our teams and our whole company, the year has been so positive. And we've learned so much. And everyone is feeling really strong, I think, in their positioning in going forward into the next year. Again, it's been good. It's been certainly challenging [laughs] but good. +CHAD: I think there have been certain things about this year that have been challenging, and we've talked about it on previous episodes, some of them. But just in general, I think I got the sense that we transitioned from being tired of the current pandemic situation and working situation to actually being upset and angry about it, which was a really weird transition. And I think it just made work in general challenging sometimes. +We also had the challenges of fairly high turnover this year at the company like a lot of companies have had. The reasons why it happens at thoughtbot might be different than other companies, but it's something that people in general have. And sometimes that can make it hard to get ahead, but because we were having such a positive year overall, it was this weird dichotomy of general success and positive change and all that stuff. But at the same time, people were still leaving the company, and that can make it challenging. +The silver lining is for a team like Ignite, even though that can be super challenging, you're in your early days, and now you're getting the opportunity to...the new people being added to the team are doing it with different expectations, and you're able to shape the team into what it needs to be today. +DAWN: Yeah. There has been an interesting...it seems like there was an influx this year and excitement and readiness to get back into building products and working on their ideas from a client perspective, but our teams were just coming off of a very hard year. People were coming off of a very hard year. So a lot of exhausted people trying to show up and be positive and work through all this excitement and movement in the industry. So it's kind of like parental leave. [laughter] Totally exhausted, but you're showing up, so it's good. +CHAD: Well, Dawn, thanks for stopping by the show, and joining me, and talking to me about Ignite and beyond. I really appreciate it. +DAWN: Yeah, this has been really fun. +CHAD: If folks want to get in touch with you or follow along with you, where are the different places that they can do that? +DAWN: Let's see. Well, I have an email address that is dawn@thoughtbot.com. I have a Twitter. I'm pretty sure that my handle is @dawndig. [laughter] Why I don't know this off the top of my head. I haven't looked at my handle in a very long time. Yeah, @dawndig, so D-A-W-N-D-I-G. LinkedIn is just my name, and it's pronounced Delatte. +CHAD: And you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Special Guest: Dawn Delatte. + + + Dawn Delatte a Designer and Managing Director at thoughtbot who leads the Ignite team, where they focus primarily on validating and launching early-stage products through design-thinking, business and product strategy, and iterative design and development. Dawn works collaboratively with designers and developers to ensure they add value to the people and products thoughtbot works with every day.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dawn Delatte, Managing Director of the thoughtbot Ignite team. Dawn, thanks for joining me.

+ +

DAWN: Hi, thanks for having me.

+ +

CHAD: Ignite is one of the examples I always use when I talk about why we split up into teams the way that we did and what the benefits are, Dawn. So why don't you tell people what Ignite actually does?

+ +

DAWN: Cool. So the Ignite team we work with entrepreneurs, and non-technical startup founders, in some cases, experienced startup founders, as well as innovation teams within existing organizations. And we work with them to validate their product ideas and deliver very initial versions of their products to continue that validation process. We provide all kinds of services around that from a validation perspective. We use product sprint methodology to understand the opportunity, understand the market, the problem, come up with solutions, all those things to arrive at some ideas and some solutions that we can then quickly prototype and then test with target users depending on who we've decided their customer is or who they've decided their customer is. And that's very high level. I'm happy to get into more detail about what our discovery sprints are like.

+ +

But after that, then we would go into, like I said, continued validation but through actual product launches. So sometimes that looks like proof of concepts, sometimes that's first MVPs. But either way, we focus on a set of goals, and that could be a certain number of users onboarded to the platform. It could be getting that next round of investment funding. But it's pretty straightforward, not a whole lot of complexity, and focused on getting a product and company to that next best stage.

+ +

CHAD: One of the reasons why I use Ignite is that it's on one end of the spectrum. It's at the extreme end of the spectrum. Last week, I talked to Josh, who's on the other end of Boost, where we're working on existing products with existing teams. And Ignite is all the way on the other side, which is sometimes we are not even writing any code at all; we're just validating an idea.

+ +

The work that Ignite does has always been a very important part of what thoughtbot does. But it's a big challenge to go from a product where maybe you have hundreds of thousands or millions of users and a large team, and you're doing development as a developer or designer, maybe it's healthcare or something super complex, and then to the next week where you're working on something that is going to get into market very quickly, maybe is totally unproven. The things you need to do in that environment and the way that you need to work can be a little bit different.

+ +

And so allowing the thoughtbot designers and developers to focus on the particular needs of the Ignite-type clients I think we have seen, and I think we'll continue to see it as people even get more used to it, it has a direct benefit to our clients as well The best thing might not always be to write a Rails app. But if you take a developer who was on a Rails app on Friday or Thursday, and then they start on a new project on Monday, chances are they're expecting to write a Rails app.

+ +

DAWN: That's a really important observation and distinction about what our developers do compared to other developers at thoughtbot. I've always said that selling any kind of project or working with new clients with any type of project, whether it's very early stage or that enterprise client that we all wear our product consulting hats, or we're product consultants first, and then we have our toolkit. But I think that is the most true, at least from my experience, in the Ignite team.

+ +

And we've even talked about and, in some cases, have been able to blur the lines even more between designers and developers because first and foremost, you're coming to the problems thinking about it exactly how you're talking about. Like, what is it going to take to make this product launch successful? It might not involve writing very much code. And we might not discover that until after we've been working together for a couple of weeks and started to validate some of the ideas we have. And so, being able to have that adaptability and really focus on the consulting and strategy aspect of things is super important.

+ +

CHAD: So if there is a typical or Ignite client that we're working with, what does it look like?

+ +

DAWN: I would say a typical...so who we've engaged the most with are non-technical founders and entrepreneurs. And I say non-technical but what I really mean is they haven't had the experience of launching a product and going through that process.

+ +

CHAD: A digital product.

+ +

DAWN: Yeah, a digital product. So for lack of a better way to describe them, non-technical because there's a lot of work involved in helping them understand product strategy and technical architecting and everything that happens in between. So that's who we've been able to work with primarily while we've also worked with other types of clients.

+ +

CHAD: What is typically the first step with clients? At what stage are they at, and what is the first step that we're taking them through?

+ +

DAWN: The sales process is a little bit different. We're not talking about requirements. And we're not exactly talking about what the end product looks like. If the conversation is going that way, we're usually trying to bring it back a little bit and keep things more high level just to make sure that we have a really good sense of what it is that we should try to do.

+ +

So the sales process is we're already starting to dig into validation processes and making sure that our clients are able to define their customers and define the problem, and have started to think about their value proposition from a business perspective, and have made other considerations that through all of our experience, all the years that we have experience with shipping products, make sure that the client understands at least at a very high level what the big components for success are going to be. And if they haven't started to make decisions about those things, that they know that we can help them do that.

+ +

So that conversation is already starting in the sales process, which is great because we can get the team involved, and everybody starts wrapping their head around the problem. And by the time that we actually kick off the project, we're really excited because we all are ready, and we have ideas for what we can do together.

+ +

But the first stage is usually always what we call a discovery sprint. So we've been doing Product Design Sprints for a long time at thoughtbot. And we've always been iterative with everything we do. But with Product Design Sprints, especially because every single one of them is unique, you have to figure out either what exercises you're going to do that make the most sense for this client in this project.

+ +

We had, I guess a bigger iteration of the Product Design Sprint as a whole. And we've moved into this concept of a discovery sprint or a discovery phase. And it allows us to do a couple of things. So the Product Design Sprint was largely modeled after the Google Ventures Sprint, which is this intensive five-day process where you quickly understand the problem, come up with some solutions together, prototype, and test within five days. We've elongated that process a little bit. So we definitely do two weeks, sometimes four if there's a lot to uncover and make sure we understand about the market before we start writing code or before we start doing the next phase of work together.

+ +

And we kick off with a lot of the same processes. So like I keep saying, making sure you understand the problem, making sure you've defined the customer, the opportunities. In some cases, at least with our clients, we're actually doing lean model canvas work because our clients haven't always thought through how they're going to make money off of this product and what their competitive landscape looks like and things like that. We incorporate a lot of that business strategy into the product strategy work that we're doing during this phase.

+ +

But yeah, the first week of a discovery sprint is usually those kinds of exercises, working together through all this institutional knowledge that the client might have. Because usually, they're experiencing this problem or they've been in this industry,and they know what the problems of their customers have, and so they can talk a lot about it. And then, we move into some of the more traditional Product Design Sprint phases, so diverge exercises, converge exercises that help us to come up with a bunch of ideas for what the product should be or should do. And then decide as a group which ones are the strongest so that we can move into prototyping.

+ +

We prototype. We test with either existing customers in this space, or we get anonymous users based on certain demographics that are important to validate the concept with, and then we test. And then, we do that iteratively throughout the process to make sure that we're capturing as much data as we can to feel confident about how validation is going. Or, in some cases, it might make sense for us to think about the next phase of validation actually being more like a proof of concept. And so we can jump into that really quickly depending on how validation is going.

+ +

A lot of times, at the end of discovery spreads, we've incorporated some technical planning and architecting into the process. Sometimes we have to validate that the launch approach is going to work from a technical perspective. And so that's the kind of research that our developer would be doing in this process. And by the end of this phase, we have a presentation of our findings, an architectural diagram if that's where we're leaning or where we would recommend the next stage go. We would present all that information and make a decision. Sometimes we invalidate. We largely invalidate some of the ideas that we came up with, and we have to go back to the drawing board.

+ +

CHAD: Have we worked with any clients recently that had a major invalidation where they really needed to go back to the drawing board based on what we learned with the whole concept?

+ +

DAWN: We did have a client that we worked with this year that we didn't invalidate things during the sprint but not far into the product build, we realized that we were going to need some other infrastructure in place in order for that product to be successful. So we actually did a more traditional Product Design Sprint with this client. Part of the reasoning was…, and this product idea was in the real estate space. [chuckles] The idea was to open up the market a little bit by...I don't want to say eliminating, but I guess, in a way eliminating certain aspects of what a realtor might do in the process of buying and selling real estate.

+ +

It is possible to knock on somebody's door and ask them if you can buy their house, and then the transaction is facilitated through a realtor. But this would open up the possibility of this happening digitally through a product. So there’s certain data that you can pull from real estate sites out there that let you know certain things about a property. And this is public information; anybody can find it.

+ +

And the concept was to have homeowners who might potentially be interested in selling their properties be on the platform and have their homes be available to anybody that might be looking or vice versa. Like, someone who's buying could get on the platform and see what kind of homes are in their area; maybe they have a particular area that they want to buy in and essentially cut out the realtor in that they could go directly to the property owner and inquire about their home or see if they might be interested in selling it. So that was, at a high level, the product idea.

+ +

We did a more traditional sprint with them because the client was obviously very familiar with this space and really understood the opportunity well. And there are not a lot of competitors in this space in the U.S., at least. Our goal was ultimately to get to a plan for MVP. And so we spent time validating the user experience and at a high level, making sure that we were confident and moving forward with everything. And we felt like we got validation for that.

+ +

And we got started on the project, and we realized there's actually a lot to this space. It's very heavily...if not regulated, there are all sorts of processes in place that require very specific people and roles to accomplish different things and facilitate the process. It's also because of the role that a realtor has played for so long. People aren't very educated on what this process could be like, buying and selling homes, especially with a direct transaction. And so there was way more to uncover and to understand and to work through on the business side than we had initially anticipated. And so we decided to quickly bring in somebody to focus on product strategy while we were also iteratively working through an MVP launch.

+ +

So we decided to test as often as we can and constantly be working through on a weekly basis what it was that we were building, making sure that that aligned with what we were learning in real-time, essentially. The product strategist came on and started to continue some of the competitor research that we had started in the Product Design Sprints really try to understand the market and try to work very directly with the clients who were both in real estate to quickly make decisions about the direction that we were going in while we were also iterating on this product idea.

+ +

About halfway through, which is standard to Ignite a 12 to 16-week MVP launch, so about halfway through at about six weeks in, we decided that we needed to continue validating with a working prototype as opposed to continuing to chug along until we got to MVP launch and just see what happened. That was feeling too risky as we were learning more and more about the market. So I wouldn't say we invalidated anything, but as we continued to validate and as we started to build iteratively realized that we needed to spend a lot more time on validating the product idea and that it made sense to do that with a working product. And so, we pivoted in that way once we had started building.

+ +

CHAD: Yeah, that's cool. I often say that it's fairly rare that we completely invalidate the core of someone's idea. But it's not at all rare that it changes based on what everyone is learning along the way, whether that be in a Product Design Sprint or discovery sprint. And I think that's one of the things that not only does it make products more successful because you're reducing risk and you're changing them based on the things that you'll learn, but I also think it leads to the working environment that I want to be a part of where it's very collaborative; everyone's building off of each other's ideas. We're changing based on what we learn rapidly. I really love doing that.

+ +

DAWN: Yeah.

+ +

AD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU.

+ +

AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more, and many of the AgencyU members are now working on client projects together and referring work to each other.

+ +

Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I’ve seen and learned from a lot of different situations, and I’d be happy to work with you.

+ +

Learn more and sign up at thoughtbot.com/agencyu

+ +

DAWN: And it's funny what you just said about learning versus invalidating. I literally just got off of a call with somebody right before I joined this, and we touched on that exact same thing. They've been building a prototype and going through their own validation phases. And this person pointed out that they didn't want to call the work that they had been doing validation that they wanted to call it learning. And I just thought that was very poignant. I feel like I call it continued validation when I'm talking about delivering a proof of concept or initial MVP because, really, that's what it is. But I think a better way to say it is just learning. You're learning from the process and from your market, and it's all at the same time. It's very agile in that way.

+ +

CHAD: One of the meta reasons why I like that from a thoughtbot perspective is that oftentimes, founders, in particular, can be very precious about their ideas or not want to give up. And so this idea of oh, it could potentially be invalidated is almost like a confrontational tension or something that even when they are shown something they might not be willing to adjust because it's not their original idea. And the word learning subtly de-escalates that a little bit. It's like, what have we learned? [laughs] Have we learned something that we can take into play? It's not invalidating the idea.

+ +

DAWN: Yeah, I find that using the term like de-risking does a similar thing. Because whether or not you're an investor, that's a term that I think everybody can understand. Like, let's try to learn from and lower the risk of us not being successful with each step we take. The ultimate goal is product success and business success, and we want to get people there. But we want to make sure we do it the right way. And we want to make sure that all the decisions that we're making early on have positive, long-term effects. So yeah, de-risking and learning. I think I'm going to change the way I talk about validation now. [laughter]

+ +

CHAD: So what else is Ignite working towards now? I know that you have...everywhere at thoughtbot, we've got a bunch of open positions open. So you're actively hiring, right?

+ +

DAWN: Yeah. So going back to what you were saying and what we were talking about earlier, a lot of what we've been thinking through on the development side is what skills are really necessary and important for our developers to have for the types of projects and the type of work that we're doing. We made an assumption and have been working through learning [laughter] whether or not that assumption is true that we don't necessarily need a ton of back-end Rails expertise to be able to deliver products in the way that we're thinking. Rails has always been really good with MVPs, really good for MVPs and speed to market and things like that. But I think that we are thinking through how we can be even more agile and iterative with product delivery.

+ +

So we're leaning towards skill sets that focus on the front end, so delivering that really great consumer or user experience on the front end because MVP and startup space is incredibly competitive nowadays. We have to be thinking through, I think, more than what we did maybe ten years ago when we were delivering MVPs for startups. So we're focusing more on the front end. We're focusing more on the user experience. And we're thinking through how we can utilize existing tooling on the back end to support the products that we're building, which we assume is going to require a lot less particular expertise and a back-end language like Rails and a lot more openness to making decisions that make the most sense for that product idea in particular so whether that's pulling together existing tools on the back end.

+ +

CHAD: Well, I find it useful to think about...or one way to articulate this is mobile apps in particular because some people might not get the distinction with a web app the difference between the front end and the back end. I think it's maybe a little bit more obvious with things like React and that kind of thing. But if you take a mobile app, for example, in order to actually build and launch a mobile app, we typically need to build the mobile app, and then that mobile app needs to talk to servers on the backside.

+ +

And put quite plainly, if we have a Rails developer on the project and a mobile developer on the project, that's two people. And if instead, we can have a mobile developer who is putting together some back-end services from companies like Google or Twilio or those kinds of things, to get to the next stage of the company, it's going to be a lot cheaper and potentially faster for the stage that that company is at if it makes sense then. That doesn't mean that they won't ever need a back end of their own, right?

+ +

DAWN: Yeah. Well, and I'm learning more and more too that making those kinds of decisions now doesn't necessarily mean that I can't scale, even with the services that we pull together for the back end at that time when we do the initial launch. AWS, for instance, has a ton of capability for initial launches and for scaling. So there are a lot of options. That's what's become more important to us when we think through the development expertise on our team is not only experience with delivering early-stage products, because you're in that mindset, but openness to working with different technologies that would allow you to, like you're saying, plug into these different tools and servers and systems that already working for a particular industry, for instance.

+ +

I mean, e-commerce is one that you think of where we definitely don't want to be reinventing any wheels there. [laughs] From a conceptual perspective, yes, and from a competitive perspective, yes. But from a back-end development and architectural perspective, there's so much that we can utilize that already exists. So yeah, we are hiring. [laughter] I think that was your original question. And we have open developer positions, which is why I was focused on that.

+ +

Our development focuses less around what you've historically seen at thoughtbot, which is we need Rails developers. We need full-stack developers who can for sure stand up a custom back end. And we've shifted to...we definitely need to focus on the front end. We need that expertise. And we need some adaptability around back-end tooling and being able to pull stuff together that way.

+ +

CHAD: So you were the Managing Director of the Austin studio. And now you're the Managing Director of the Ignite team. Before that, you were a designer. How has this transition compared to prior transitions that you've been a part of?

+ +

DAWN: I think the biggest difference, and this has been just as challenging as it has been rewarding, and I think positive for our business, is the fact that I can focus on expanding our services and expanding our expertise in this one area. Before, we had the local studios, and we could work across the entire product lifecycle. And from a sales and business development perspective, that both gave me varied experience. And it gave me a lot of levers to pull, especially with the teams and making sure that we were all working on different things and able to cycle through different types of projects. But that's hard to do, and it's a lot of work. [laughs] And being able to focus on one stage of the product lifecycle and a set of clients, and expand our expertise in that area has been really challenging and really rewarding.

+ +

We've been able to sink our teeth in and imagine what possibilities are here and explore markets that we haven't before and actually think through how we can build partnerships with people and really become experts in this space in a way that we haven't been able to in the past because there hasn't been dedicated time and dedicated effort in particular. So the transition has been really great in that way. I'm really excited about it.

+ +

CHAD: Well, that's good. [laughter] You were out on parental leave for a fair amount of time. How long was it in total?

+ +

DAWN: About four months.

+ +

CHAD: Welcome back, by the way.

+ +

DAWN: Thank you.

+ +

CHAD: I'm curious on your perspective either with Ignite or maybe even more so thoughtbot overall. How was it being away, and what surprised you when you came back?

+ +

DAWN: So a couple of things, we were a smaller team in the beginning of this year. We knew that we were going to have to be iterative with our approach to refining our positioning as a team and understanding all these things that we're talking about, like our clients and our customers, and who we're going to work with, how we're going to work with them, how we're going to deliver value. We knew that we were going to have to be iterative. So we went through some phases this year. We were experimental and applied our validation processes to Ignite as a business. And we learned a ton of stuff. And we're going in a great direction. And then I was out for four months [laughter], and so there was a gap. And I tried very hard not to check my email. I mostly did a good job of it.

+ +

And so I was telling Diana, our CEO, earlier that I feel a little bit like we're going into 2022 with a fresh start even though we have this whole year behind us that we learned from. We got to a point where we're going in a particular direction now. And we validated enough and felt strongly enough about the direction that we're going in that we're hitting the ground running now going into next year. And I don't know what I assumed; maybe I assumed that we would have established a little bit more this year in the direction that we initially intended. And it's not like a far departure. It's just that it's certainly evolved beyond what I was imagining initially from the technical perspective, for instance.

+ +

CHAD: Well, even in Ignite, which is pretty short client cycles, we're not so huge. [chuckles] Ignite might do 12 projects in a year, and that might be a lot. So we get a lot of opportunities to try new things. And the cycle time isn't that long, but it's not super-fast pace, and it's not super high volume. So it does take some time to refine things based on what we learn, even in Ignite, which is typically faster cycles.

+ +

DAWN: Yeah, that's true. If you think of it that way, a lot of our projects if we're doing an MVP launch, for instance, it's about a quarter along. And if we only do a couple of those every quarter, it takes those whole cycles to be able to look at things in retrospect. I agree; it takes a little bit longer to learn overall.

+ +

I like the way that you put it, too, like when you really look back and think of it, even though we do a lot of what you would consider rapid projects, it's still going to take some time to learn. And I think overall, and I think this is true for all of our teams and our whole company, the year has been so positive. And we've learned so much. And everyone is feeling really strong, I think, in their positioning in going forward into the next year. Again, it's been good. It's been certainly challenging [laughs] but good.

+ +

CHAD: I think there have been certain things about this year that have been challenging, and we've talked about it on previous episodes, some of them. But just in general, I think I got the sense that we transitioned from being tired of the current pandemic situation and working situation to actually being upset and angry about it, which was a really weird transition. And I think it just made work in general challenging sometimes.

+ +

We also had the challenges of fairly high turnover this year at the company like a lot of companies have had. The reasons why it happens at thoughtbot might be different than other companies, but it's something that people in general have. And sometimes that can make it hard to get ahead, but because we were having such a positive year overall, it was this weird dichotomy of general success and positive change and all that stuff. But at the same time, people were still leaving the company, and that can make it challenging.

+ +

The silver lining is for a team like Ignite, even though that can be super challenging, you're in your early days, and now you're getting the opportunity to...the new people being added to the team are doing it with different expectations, and you're able to shape the team into what it needs to be today.

+ +

DAWN: Yeah. There has been an interesting...it seems like there was an influx this year and excitement and readiness to get back into building products and working on their ideas from a client perspective, but our teams were just coming off of a very hard year. People were coming off of a very hard year. So a lot of exhausted people trying to show up and be positive and work through all this excitement and movement in the industry. So it's kind of like parental leave. [laughter] Totally exhausted, but you're showing up, so it's good.

+ +

CHAD: Well, Dawn, thanks for stopping by the show, and joining me, and talking to me about Ignite and beyond. I really appreciate it.

+ +

DAWN: Yeah, this has been really fun.

+ +

CHAD: If folks want to get in touch with you or follow along with you, where are the different places that they can do that?

+ +

DAWN: Let's see. Well, I have an email address that is dawn@thoughtbot.com. I have a Twitter. I'm pretty sure that my handle is @dawndig. [laughter] Why I don't know this off the top of my head. I haven't looked at my handle in a very long time. Yeah, @dawndig, so D-A-W-N-D-I-G. LinkedIn is just my name, and it's pronounced Delatte.

+ +

CHAD: And you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

Special Guest: Dawn Delatte.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dawn Delatte a Designer and Managing Director at thoughtbot who leads the Ignite team, where they focus primarily on validating and launching early-stage products through design-thinking, business and product strategy, and iterative design and development. Dawn works collaboratively with designers and developers to ensure they add value to the people and products thoughtbot works with every day.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dawn Delatte, Managing Director of the thoughtbot Ignite team. Dawn, thanks for joining me.

+ +

DAWN: Hi, thanks for having me.

+ +

CHAD: Ignite is one of the examples I always use when I talk about why we split up into teams the way that we did and what the benefits are, Dawn. So why don't you tell people what Ignite actually does?

+ +

DAWN: Cool. So the Ignite team we work with entrepreneurs, and non-technical startup founders, in some cases, experienced startup founders, as well as innovation teams within existing organizations. And we work with them to validate their product ideas and deliver very initial versions of their products to continue that validation process. We provide all kinds of services around that from a validation perspective. We use product sprint methodology to understand the opportunity, understand the market, the problem, come up with solutions, all those things to arrive at some ideas and some solutions that we can then quickly prototype and then test with target users depending on who we've decided their customer is or who they've decided their customer is. And that's very high level. I'm happy to get into more detail about what our discovery sprints are like.

+ +

But after that, then we would go into, like I said, continued validation but through actual product launches. So sometimes that looks like proof of concepts, sometimes that's first MVPs. But either way, we focus on a set of goals, and that could be a certain number of users onboarded to the platform. It could be getting that next round of investment funding. But it's pretty straightforward, not a whole lot of complexity, and focused on getting a product and company to that next best stage.

+ +

CHAD: One of the reasons why I use Ignite is that it's on one end of the spectrum. It's at the extreme end of the spectrum. Last week, I talked to Josh, who's on the other end of Boost, where we're working on existing products with existing teams. And Ignite is all the way on the other side, which is sometimes we are not even writing any code at all; we're just validating an idea.

+ +

The work that Ignite does has always been a very important part of what thoughtbot does. But it's a big challenge to go from a product where maybe you have hundreds of thousands or millions of users and a large team, and you're doing development as a developer or designer, maybe it's healthcare or something super complex, and then to the next week where you're working on something that is going to get into market very quickly, maybe is totally unproven. The things you need to do in that environment and the way that you need to work can be a little bit different.

+ +

And so allowing the thoughtbot designers and developers to focus on the particular needs of the Ignite-type clients I think we have seen, and I think we'll continue to see it as people even get more used to it, it has a direct benefit to our clients as well The best thing might not always be to write a Rails app. But if you take a developer who was on a Rails app on Friday or Thursday, and then they start on a new project on Monday, chances are they're expecting to write a Rails app.

+ +

DAWN: That's a really important observation and distinction about what our developers do compared to other developers at thoughtbot. I've always said that selling any kind of project or working with new clients with any type of project, whether it's very early stage or that enterprise client that we all wear our product consulting hats, or we're product consultants first, and then we have our toolkit. But I think that is the most true, at least from my experience, in the Ignite team.

+ +

And we've even talked about and, in some cases, have been able to blur the lines even more between designers and developers because first and foremost, you're coming to the problems thinking about it exactly how you're talking about. Like, what is it going to take to make this product launch successful? It might not involve writing very much code. And we might not discover that until after we've been working together for a couple of weeks and started to validate some of the ideas we have. And so, being able to have that adaptability and really focus on the consulting and strategy aspect of things is super important.

+ +

CHAD: So if there is a typical or Ignite client that we're working with, what does it look like?

+ +

DAWN: I would say a typical...so who we've engaged the most with are non-technical founders and entrepreneurs. And I say non-technical but what I really mean is they haven't had the experience of launching a product and going through that process.

+ +

CHAD: A digital product.

+ +

DAWN: Yeah, a digital product. So for lack of a better way to describe them, non-technical because there's a lot of work involved in helping them understand product strategy and technical architecting and everything that happens in between. So that's who we've been able to work with primarily while we've also worked with other types of clients.

+ +

CHAD: What is typically the first step with clients? At what stage are they at, and what is the first step that we're taking them through?

+ +

DAWN: The sales process is a little bit different. We're not talking about requirements. And we're not exactly talking about what the end product looks like. If the conversation is going that way, we're usually trying to bring it back a little bit and keep things more high level just to make sure that we have a really good sense of what it is that we should try to do.

+ +

So the sales process is we're already starting to dig into validation processes and making sure that our clients are able to define their customers and define the problem, and have started to think about their value proposition from a business perspective, and have made other considerations that through all of our experience, all the years that we have experience with shipping products, make sure that the client understands at least at a very high level what the big components for success are going to be. And if they haven't started to make decisions about those things, that they know that we can help them do that.

+ +

So that conversation is already starting in the sales process, which is great because we can get the team involved, and everybody starts wrapping their head around the problem. And by the time that we actually kick off the project, we're really excited because we all are ready, and we have ideas for what we can do together.

+ +

But the first stage is usually always what we call a discovery sprint. So we've been doing Product Design Sprints for a long time at thoughtbot. And we've always been iterative with everything we do. But with Product Design Sprints, especially because every single one of them is unique, you have to figure out either what exercises you're going to do that make the most sense for this client in this project.

+ +

We had, I guess a bigger iteration of the Product Design Sprint as a whole. And we've moved into this concept of a discovery sprint or a discovery phase. And it allows us to do a couple of things. So the Product Design Sprint was largely modeled after the Google Ventures Sprint, which is this intensive five-day process where you quickly understand the problem, come up with some solutions together, prototype, and test within five days. We've elongated that process a little bit. So we definitely do two weeks, sometimes four if there's a lot to uncover and make sure we understand about the market before we start writing code or before we start doing the next phase of work together.

+ +

And we kick off with a lot of the same processes. So like I keep saying, making sure you understand the problem, making sure you've defined the customer, the opportunities. In some cases, at least with our clients, we're actually doing lean model canvas work because our clients haven't always thought through how they're going to make money off of this product and what their competitive landscape looks like and things like that. We incorporate a lot of that business strategy into the product strategy work that we're doing during this phase.

+ +

But yeah, the first week of a discovery sprint is usually those kinds of exercises, working together through all this institutional knowledge that the client might have. Because usually, they're experiencing this problem or they've been in this industry,and they know what the problems of their customers have, and so they can talk a lot about it. And then, we move into some of the more traditional Product Design Sprint phases, so diverge exercises, converge exercises that help us to come up with a bunch of ideas for what the product should be or should do. And then decide as a group which ones are the strongest so that we can move into prototyping.

+ +

We prototype. We test with either existing customers in this space, or we get anonymous users based on certain demographics that are important to validate the concept with, and then we test. And then, we do that iteratively throughout the process to make sure that we're capturing as much data as we can to feel confident about how validation is going. Or, in some cases, it might make sense for us to think about the next phase of validation actually being more like a proof of concept. And so we can jump into that really quickly depending on how validation is going.

+ +

A lot of times, at the end of discovery spreads, we've incorporated some technical planning and architecting into the process. Sometimes we have to validate that the launch approach is going to work from a technical perspective. And so that's the kind of research that our developer would be doing in this process. And by the end of this phase, we have a presentation of our findings, an architectural diagram if that's where we're leaning or where we would recommend the next stage go. We would present all that information and make a decision. Sometimes we invalidate. We largely invalidate some of the ideas that we came up with, and we have to go back to the drawing board.

+ +

CHAD: Have we worked with any clients recently that had a major invalidation where they really needed to go back to the drawing board based on what we learned with the whole concept?

+ +

DAWN: We did have a client that we worked with this year that we didn't invalidate things during the sprint but not far into the product build, we realized that we were going to need some other infrastructure in place in order for that product to be successful. So we actually did a more traditional Product Design Sprint with this client. Part of the reasoning was…, and this product idea was in the real estate space. [chuckles] The idea was to open up the market a little bit by...I don't want to say eliminating, but I guess, in a way eliminating certain aspects of what a realtor might do in the process of buying and selling real estate.

+ +

It is possible to knock on somebody's door and ask them if you can buy their house, and then the transaction is facilitated through a realtor. But this would open up the possibility of this happening digitally through a product. So there’s certain data that you can pull from real estate sites out there that let you know certain things about a property. And this is public information; anybody can find it.

+ +

And the concept was to have homeowners who might potentially be interested in selling their properties be on the platform and have their homes be available to anybody that might be looking or vice versa. Like, someone who's buying could get on the platform and see what kind of homes are in their area; maybe they have a particular area that they want to buy in and essentially cut out the realtor in that they could go directly to the property owner and inquire about their home or see if they might be interested in selling it. So that was, at a high level, the product idea.

+ +

We did a more traditional sprint with them because the client was obviously very familiar with this space and really understood the opportunity well. And there are not a lot of competitors in this space in the U.S., at least. Our goal was ultimately to get to a plan for MVP. And so we spent time validating the user experience and at a high level, making sure that we were confident and moving forward with everything. And we felt like we got validation for that.

+ +

And we got started on the project, and we realized there's actually a lot to this space. It's very heavily...if not regulated, there are all sorts of processes in place that require very specific people and roles to accomplish different things and facilitate the process. It's also because of the role that a realtor has played for so long. People aren't very educated on what this process could be like, buying and selling homes, especially with a direct transaction. And so there was way more to uncover and to understand and to work through on the business side than we had initially anticipated. And so we decided to quickly bring in somebody to focus on product strategy while we were also iteratively working through an MVP launch.

+ +

So we decided to test as often as we can and constantly be working through on a weekly basis what it was that we were building, making sure that that aligned with what we were learning in real-time, essentially. The product strategist came on and started to continue some of the competitor research that we had started in the Product Design Sprints really try to understand the market and try to work very directly with the clients who were both in real estate to quickly make decisions about the direction that we were going in while we were also iterating on this product idea.

+ +

About halfway through, which is standard to Ignite a 12 to 16-week MVP launch, so about halfway through at about six weeks in, we decided that we needed to continue validating with a working prototype as opposed to continuing to chug along until we got to MVP launch and just see what happened. That was feeling too risky as we were learning more and more about the market. So I wouldn't say we invalidated anything, but as we continued to validate and as we started to build iteratively realized that we needed to spend a lot more time on validating the product idea and that it made sense to do that with a working product. And so, we pivoted in that way once we had started building.

+ +

CHAD: Yeah, that's cool. I often say that it's fairly rare that we completely invalidate the core of someone's idea. But it's not at all rare that it changes based on what everyone is learning along the way, whether that be in a Product Design Sprint or discovery sprint. And I think that's one of the things that not only does it make products more successful because you're reducing risk and you're changing them based on the things that you'll learn, but I also think it leads to the working environment that I want to be a part of where it's very collaborative; everyone's building off of each other's ideas. We're changing based on what we learn rapidly. I really love doing that.

+ +

DAWN: Yeah.

+ +

AD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU.

+ +

AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more, and many of the AgencyU members are now working on client projects together and referring work to each other.

+ +

Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I’ve seen and learned from a lot of different situations, and I’d be happy to work with you.

+ +

Learn more and sign up at thoughtbot.com/agencyu

+ +

DAWN: And it's funny what you just said about learning versus invalidating. I literally just got off of a call with somebody right before I joined this, and we touched on that exact same thing. They've been building a prototype and going through their own validation phases. And this person pointed out that they didn't want to call the work that they had been doing validation that they wanted to call it learning. And I just thought that was very poignant. I feel like I call it continued validation when I'm talking about delivering a proof of concept or initial MVP because, really, that's what it is. But I think a better way to say it is just learning. You're learning from the process and from your market, and it's all at the same time. It's very agile in that way.

+ +

CHAD: One of the meta reasons why I like that from a thoughtbot perspective is that oftentimes, founders, in particular, can be very precious about their ideas or not want to give up. And so this idea of oh, it could potentially be invalidated is almost like a confrontational tension or something that even when they are shown something they might not be willing to adjust because it's not their original idea. And the word learning subtly de-escalates that a little bit. It's like, what have we learned? [laughs] Have we learned something that we can take into play? It's not invalidating the idea.

+ +

DAWN: Yeah, I find that using the term like de-risking does a similar thing. Because whether or not you're an investor, that's a term that I think everybody can understand. Like, let's try to learn from and lower the risk of us not being successful with each step we take. The ultimate goal is product success and business success, and we want to get people there. But we want to make sure we do it the right way. And we want to make sure that all the decisions that we're making early on have positive, long-term effects. So yeah, de-risking and learning. I think I'm going to change the way I talk about validation now. [laughter]

+ +

CHAD: So what else is Ignite working towards now? I know that you have...everywhere at thoughtbot, we've got a bunch of open positions open. So you're actively hiring, right?

+ +

DAWN: Yeah. So going back to what you were saying and what we were talking about earlier, a lot of what we've been thinking through on the development side is what skills are really necessary and important for our developers to have for the types of projects and the type of work that we're doing. We made an assumption and have been working through learning [laughter] whether or not that assumption is true that we don't necessarily need a ton of back-end Rails expertise to be able to deliver products in the way that we're thinking. Rails has always been really good with MVPs, really good for MVPs and speed to market and things like that. But I think that we are thinking through how we can be even more agile and iterative with product delivery.

+ +

So we're leaning towards skill sets that focus on the front end, so delivering that really great consumer or user experience on the front end because MVP and startup space is incredibly competitive nowadays. We have to be thinking through, I think, more than what we did maybe ten years ago when we were delivering MVPs for startups. So we're focusing more on the front end. We're focusing more on the user experience. And we're thinking through how we can utilize existing tooling on the back end to support the products that we're building, which we assume is going to require a lot less particular expertise and a back-end language like Rails and a lot more openness to making decisions that make the most sense for that product idea in particular so whether that's pulling together existing tools on the back end.

+ +

CHAD: Well, I find it useful to think about...or one way to articulate this is mobile apps in particular because some people might not get the distinction with a web app the difference between the front end and the back end. I think it's maybe a little bit more obvious with things like React and that kind of thing. But if you take a mobile app, for example, in order to actually build and launch a mobile app, we typically need to build the mobile app, and then that mobile app needs to talk to servers on the backside.

+ +

And put quite plainly, if we have a Rails developer on the project and a mobile developer on the project, that's two people. And if instead, we can have a mobile developer who is putting together some back-end services from companies like Google or Twilio or those kinds of things, to get to the next stage of the company, it's going to be a lot cheaper and potentially faster for the stage that that company is at if it makes sense then. That doesn't mean that they won't ever need a back end of their own, right?

+ +

DAWN: Yeah. Well, and I'm learning more and more too that making those kinds of decisions now doesn't necessarily mean that I can't scale, even with the services that we pull together for the back end at that time when we do the initial launch. AWS, for instance, has a ton of capability for initial launches and for scaling. So there are a lot of options. That's what's become more important to us when we think through the development expertise on our team is not only experience with delivering early-stage products, because you're in that mindset, but openness to working with different technologies that would allow you to, like you're saying, plug into these different tools and servers and systems that already working for a particular industry, for instance.

+ +

I mean, e-commerce is one that you think of where we definitely don't want to be reinventing any wheels there. [laughs] From a conceptual perspective, yes, and from a competitive perspective, yes. But from a back-end development and architectural perspective, there's so much that we can utilize that already exists. So yeah, we are hiring. [laughter] I think that was your original question. And we have open developer positions, which is why I was focused on that.

+ +

Our development focuses less around what you've historically seen at thoughtbot, which is we need Rails developers. We need full-stack developers who can for sure stand up a custom back end. And we've shifted to...we definitely need to focus on the front end. We need that expertise. And we need some adaptability around back-end tooling and being able to pull stuff together that way.

+ +

CHAD: So you were the Managing Director of the Austin studio. And now you're the Managing Director of the Ignite team. Before that, you were a designer. How has this transition compared to prior transitions that you've been a part of?

+ +

DAWN: I think the biggest difference, and this has been just as challenging as it has been rewarding, and I think positive for our business, is the fact that I can focus on expanding our services and expanding our expertise in this one area. Before, we had the local studios, and we could work across the entire product lifecycle. And from a sales and business development perspective, that both gave me varied experience. And it gave me a lot of levers to pull, especially with the teams and making sure that we were all working on different things and able to cycle through different types of projects. But that's hard to do, and it's a lot of work. [laughs] And being able to focus on one stage of the product lifecycle and a set of clients, and expand our expertise in that area has been really challenging and really rewarding.

+ +

We've been able to sink our teeth in and imagine what possibilities are here and explore markets that we haven't before and actually think through how we can build partnerships with people and really become experts in this space in a way that we haven't been able to in the past because there hasn't been dedicated time and dedicated effort in particular. So the transition has been really great in that way. I'm really excited about it.

+ +

CHAD: Well, that's good. [laughter] You were out on parental leave for a fair amount of time. How long was it in total?

+ +

DAWN: About four months.

+ +

CHAD: Welcome back, by the way.

+ +

DAWN: Thank you.

+ +

CHAD: I'm curious on your perspective either with Ignite or maybe even more so thoughtbot overall. How was it being away, and what surprised you when you came back?

+ +

DAWN: So a couple of things, we were a smaller team in the beginning of this year. We knew that we were going to have to be iterative with our approach to refining our positioning as a team and understanding all these things that we're talking about, like our clients and our customers, and who we're going to work with, how we're going to work with them, how we're going to deliver value. We knew that we were going to have to be iterative. So we went through some phases this year. We were experimental and applied our validation processes to Ignite as a business. And we learned a ton of stuff. And we're going in a great direction. And then I was out for four months [laughter], and so there was a gap. And I tried very hard not to check my email. I mostly did a good job of it.

+ +

And so I was telling Diana, our CEO, earlier that I feel a little bit like we're going into 2022 with a fresh start even though we have this whole year behind us that we learned from. We got to a point where we're going in a particular direction now. And we validated enough and felt strongly enough about the direction that we're going in that we're hitting the ground running now going into next year. And I don't know what I assumed; maybe I assumed that we would have established a little bit more this year in the direction that we initially intended. And it's not like a far departure. It's just that it's certainly evolved beyond what I was imagining initially from the technical perspective, for instance.

+ +

CHAD: Well, even in Ignite, which is pretty short client cycles, we're not so huge. [chuckles] Ignite might do 12 projects in a year, and that might be a lot. So we get a lot of opportunities to try new things. And the cycle time isn't that long, but it's not super-fast pace, and it's not super high volume. So it does take some time to refine things based on what we learn, even in Ignite, which is typically faster cycles.

+ +

DAWN: Yeah, that's true. If you think of it that way, a lot of our projects if we're doing an MVP launch, for instance, it's about a quarter along. And if we only do a couple of those every quarter, it takes those whole cycles to be able to look at things in retrospect. I agree; it takes a little bit longer to learn overall.

+ +

I like the way that you put it, too, like when you really look back and think of it, even though we do a lot of what you would consider rapid projects, it's still going to take some time to learn. And I think overall, and I think this is true for all of our teams and our whole company, the year has been so positive. And we've learned so much. And everyone is feeling really strong, I think, in their positioning in going forward into the next year. Again, it's been good. It's been certainly challenging [laughs] but good.

+ +

CHAD: I think there have been certain things about this year that have been challenging, and we've talked about it on previous episodes, some of them. But just in general, I think I got the sense that we transitioned from being tired of the current pandemic situation and working situation to actually being upset and angry about it, which was a really weird transition. And I think it just made work in general challenging sometimes.

+ +

We also had the challenges of fairly high turnover this year at the company like a lot of companies have had. The reasons why it happens at thoughtbot might be different than other companies, but it's something that people in general have. And sometimes that can make it hard to get ahead, but because we were having such a positive year overall, it was this weird dichotomy of general success and positive change and all that stuff. But at the same time, people were still leaving the company, and that can make it challenging.

+ +

The silver lining is for a team like Ignite, even though that can be super challenging, you're in your early days, and now you're getting the opportunity to...the new people being added to the team are doing it with different expectations, and you're able to shape the team into what it needs to be today.

+ +

DAWN: Yeah. There has been an interesting...it seems like there was an influx this year and excitement and readiness to get back into building products and working on their ideas from a client perspective, but our teams were just coming off of a very hard year. People were coming off of a very hard year. So a lot of exhausted people trying to show up and be positive and work through all this excitement and movement in the industry. So it's kind of like parental leave. [laughter] Totally exhausted, but you're showing up, so it's good.

+ +

CHAD: Well, Dawn, thanks for stopping by the show, and joining me, and talking to me about Ignite and beyond. I really appreciate it.

+ +

DAWN: Yeah, this has been really fun.

+ +

CHAD: If folks want to get in touch with you or follow along with you, where are the different places that they can do that?

+ +

DAWN: Let's see. Well, I have an email address that is dawn@thoughtbot.com. I have a Twitter. I'm pretty sure that my handle is @dawndig. [laughter] Why I don't know this off the top of my head. I haven't looked at my handle in a very long time. Yeah, @dawndig, so D-A-W-N-D-I-G. LinkedIn is just my name, and it's pronounced Delatte.

+ +

CHAD: And you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

Special Guest: Dawn Delatte.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Qgnvf1zl + + ]]> + + Chad Pytel + Dawn Delatte + + + 400: Launchpad II with Kirsten Hurley + https://podcast.thoughtbot.com/400 + 27e2c950-3142-43d8-aa2e-0c0ef82ec458 + Thu, 04 Nov 2021 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Chad interviews Kirsten Hurley, Managing Director of thoughtbot's Launchpad II team. The Launchpad II team covers the EMEA area: that's Europe, the Middle East, and Africa. She talks about working remotely for almost the entire time she's worked with the company, her approach to talking with potential customers when she knows she's never going to meet them in person, and what she sees happening to the different geographies that thoughtbot is selling and expanding into. + 35:27 + no + + + Chad interviews Kirsten Hurley, Managing Director of thoughtbot's Launchpad II team. The Launchpad II team covers the EMEA area: that's Europe, the Middle East, and Africa. She talks about working remotely for almost the entire time she's worked with the company, her approach to talking with potential customers when she knows she's never going to meet them in person, and what she sees happening to the different geographies that thoughtbot is selling and expanding into. +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/) +Follow Kirsten on LinkedIn (https://www.linkedin.com/in/hurleykirsten/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Kirsten Hurley, Managing Director of thoughtbot's Launchpad II team. Kirsten, thanks for joining me. +KIRSTEN: Thanks for having me on, Chad. +CHAD: So I've now talked with a few managing directors at thoughtbot about the new team that they're leading. So I think listeners are probably expecting what's coming next which is, you know, why don't you give people a little bit of an overview of what the Launchpad II team, which has a slightly different name than the other teams we've talked to so far, do? +KIRSTEN: Sure. So I guess maybe to remind some folks, so Launchpad I refers to the Americas. So you've already spoken to a few of the managing directors who head up different teams across the Americas. You have different propositions. Over in Launchpad II, which historically was the London studio when we were working in a physical office environment, we are a smaller team than everyone else who was based over in the Americas. +So we didn't quite scale out to be able to have individual teams working on particular propositions. But I think what the team had been successfully doing anyway was working across everything. And we still do work on Ignite-style projects, Lift Off, and Boost engagements as well. So yeah, that's where we've got to. And I think maybe the changes for us is that since we've gone to fully remote working and officially called ourselves the EMEA Launchpad II team, we've started hiring folks from further afield, which is really exciting for me. +CHAD: So not everyone may be familiar with the acronym, although it's fairly common, EMEA. So what regions does that actually cover? +KIRSTEN: [laughs] Sorry. So that's Europe, the Middle East, and Africa. And I should say we were already working with clients pretty much fully across the region anyway. It was just never really official. But I think the more global terminology is Europe, the Middle East, and Africa or EMEA. But because we're thoughtbot and we like to do things a little bit...well, we like to own our things. So we've called it Launchpad II to go with the rocket theme that we had in our rebranding. What was that? The end of last year I think we came up with it all. +CHAD: Yeah. So what has it been like to go from a team of people that were...[laughs] actually, as I ask this question I realized that you joined a week before the pandemic started, and we had to go remote. So I was going to ask you what it was like to go from a team of people that were going to a studio every day all based in London to a remote team. [laughs] But you never really experienced the alternative. +KIRSTEN: [laughs] No. I think the most time I spent with the team as a whole was actually in my interview process [laughs] before I even started in person I should say. That was a pretty interesting week. You had flown over from Boston [chuckles] to spend some time getting me all set up and running. And I think it was the Wednesday where you and I had a bit of a chat, and we were concerned about this virus that was going around and the duty of care that we actually had to our teams across the world from a point of view of them commuting to work, and it didn't feel right. And so I think we made the decision that day that from the following week, everyone would start working from home. And I think we thought it would just be for a few weeks, and we'd see how it went. So yeah, it was interesting for sure. [laughs] +CHAD: Right. And I remember what happened is I went to...I usually leave on a Friday when I visit, but a few of us, I think, went to a pub or something on...we were planning on doing that on Friday. So I was going to leave on Saturday morning, and I did. But I woke up on Saturday morning ready to catch my flight to the news that the U.S. had shut down all flights from the UK or from Europe, was what the headline said. And I was like, oh no, [laughter] I might be stuck here. And then when you actually read the article, it said actually the UK is exempt and also U.S. citizens were exempt, so they can get back. I remember waking up that morning and having a fright that I was going to be stuck there and made it back safely, thankfully. So the U.S. then went remote that following week if I remember the timeline right. +It was an interesting time. And like you said, we thought it was going to be temporary, relatively short, but it wasn't. And then, at the end of last year, we decided that we would be going completely fully remote, and that was pretty exciting. I think for folks, it was obviously...unexpected is probably the wrong word because we couldn't be in person anyway. But it wasn't what people were necessarily expecting when they joined thoughtbot. People join because we often, or at least they have the expectation that we're in an office together. But it's been exciting for Launchpad II because it means that you can now and are hiring people much differently and further afield than you were in the past, right? +KIRSTEN: Yeah, and even actually working with partners further afield as well. So we have some great partnerships still in the UK but actually working with some of your cohorts from AgencyU, your coaching program, Subvisual over in Portugal, and a couple of others as well. That's been really great to work with those teams as well. +CHAD: Having come into a new team as in a leadership position and being, basically as we've said, entirely remote almost from day one, how has that been for you? +KIRSTEN: Certainly, it wasn't the plan. [laughs] So I think my last few roles were very much working based in an office. And so my background is commercial and sales, account management. And I was very used to building rapport with teams and clients in person. So I had joined thoughtbot and joined the London studio as it was then but Launchpad II with a remit to grow the business. So I think you had been looking after the team for about a year, giving us a great foundation to then really grow. +And coming in, this black swan event had happened in the world, so the priorities changed overnight. And it was okay; how do I keep this team safe? Is everyone set up to be successful in their role? And also our existing clients and our existing projects, are they supported in the right way? This is a shock to them as well. I think, at thoughtbot, we're very lucky that from a point of view of asynchronous communication and remote working practices, being a global company, it wasn't such a shock to the system, but for some of our clients, it was. So we had to make sure that they were supported. And in some cases, we showed them what good looks like. +But rather than focusing on new business and growing straight away, it was really a period of stabilization, I would say, for about three to six months while everyone got used to what was an evolving situation, but we came through it. And I have to say a huge thank you to the team actually for their kindness and patience with me and learning remotely everything about thoughtbot that I was so excited to become a part of. But also, learning a leadership style over Zoom wasn't really what I thought I was going to be doing. +CHAD: Well, you mentioned selling a lot of what you had done previously was relationship building with clients in person or potential clients in person. Is there anything that stands out to you in terms of how you've needed to adjust either your style or your approach when talking with potential customers when you know you're never going to meet them in person? +KIRSTEN: I'm not sure you can really change your personality per se because I am always interested in building rapport through understanding an individual's motives and what they're passionate about. And quite often, those conversations can be things outside of work, so talking with clients about maybe going up for runs and things like that and personal bests and things just because that's a natural thing to talk to someone about. I still very much make room for those kinds of things in calls. +Because I think in a consultancy relationship, people buy people, and people want to work with people who understand them. And while the majority of that is obviously people understanding your job and the product that you want to be building as well, I think you need to have that personal element. So while it felt a bit stilted over Zoom to make that time, I think that it's worth it in the long run. +CHAD: That's a really good point. I think if you're not careful about it, it's very easy to just get right to business in a call as opposed to when you're meeting someone in person you need to walk to a conference room or something, and it naturally lends itself to some small talk. +KIRSTEN: Exactly, that bit where you're riding in the lift together. +CHAD: And I think that that probably applies to sales as much as it does our team members too. +KIRSTEN: Absolutely. Funnily enough, I was talking with our Development Director here, Rob Whittaker, the other day about one-to-ones should not be really that much talking about your client project. It's obviously important to make sure that someone is happy and they're being successful in their work. But actually, what's going on behind the scenes and understanding that within your team is probably just as important, if not more so, like you say. +CHAD: So tell us a little bit about some of the interesting work that's happening in Launchpad II. +KIRSTEN: Well, we've got a couple of flagship clients that keep on growing for us, which is really great, actually. They're effectively partnerships, really at this point. And so, one of those clients is a large financial service institution where we were building APIs for all of the COVID loan schemes. And I think the last I checked, the amount of money that had flowed through that system and the loans approved was something over £75 billion. So for a pretty small development team, it's really impressive what they've achieved over that time. So that's a team of three developers in a Boost-style engagement, so like Josh's team over in the U.S. working on a Rails project and working alongside business analysts from the team and other stakeholders there as well. +And so over in the Middle East, we have a food delivery client, so they're actually a huge brand over there. And we had started working with them nearly two years ago now on creating a mobile app for their customers. So we've been adding to features, getting that released. And obviously, with what's happened in the last 18 months, food delivery is a sector where you've seen huge growth. And that's even led to us recently looking at re-engineering the platform and making sure that we're still managing to delight their customers as well with their user experience. +And we've even been working on some Ignite-style projects too. So there's a lot of startups, a lot of folks have been at home thinking about what is this new business? What's the impact I'm going to have on the world? And most recently, we've been running some product design sprints with a wellness brand who are looking at bringing a different type of wellness to the market. And again, that's a mobile app which we're really excited to be working on. +CHAD: Have you seen the different geographies both from the U.S. and UK...what do you see happening to the different geographies that you're selling into and expanding into? Are there any notable differences you would call out? +KIRSTEN: I think the biggest difference that I see between clients in the Americas and over here in Europe, the Middle East, Africa would be the funding levels for startups and the expectations around that. It seems like a more mature market from a point of view of being able to get a decent budget to really build a meaningful platform for first release over in the Americas, whereas over here, it's a bit leaner definitely [laughs] on the startup side of things. So I think that's probably the biggest challenge we have when talking with clients and making sure we can give them the bang for the buck, as it were. So making sure that the research that we did, that the designers do, for example, is focused on the right thing and really gives them the insight that they need to have the confidence to progress and invest in that build. Or whether they actually need to go back and do more before they actually start spending on the development side of things. +CHAD: I would definitely second that. And one thing that I noticed not only were the amounts different in the U.S. and the UK, but it seems like in the U.S., when you're talking with a founder, there's more often than not other people they need to check in with in order to make a decision. And when I was talking to founders in the UK and beyond and in Europe, what I often felt was that there was actually someone that they needed to check in with and get permission from or that was holding the purse strings or something. And that might be a cultural thing as well, far less likely to just make a decision with you in the meeting saying, "Yeah, we're going to work together." There was always, for me, a lot more back and forth, and checking and permission getting around decisions that are being made. +KIRSTEN: Yeah, I would agree with that. +CHAD: Is that something that you've seen too? +KIRSTEN: I think so. It's interesting because what we've started doing recently actually...sometimes through the product design sprints but even in the sales process, if a founder does know or does realize in those conversations that they're going to need to find an additional source of money to be able to fund it, conversations have gone more into how can we help them with their pitch deck as well? And I think I've seen this with the Ignite team over in the Americas as well, to be fair. The prototypes that we build, very early-stage prototypes, where we're testing and doing the user research those go into the pitch decks now to give potential investors greater confidence as well if that's the route that they go down. +MIDROLL AD +CHAD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU. +AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions, and also monthly group meetings. We start with goal setting, advice, and problem solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. +Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot I’ve seen and learned from a lot of different situations, and I’d be happy to work with you. +Learn more and sign up at thoughtbot.com/agencyu +CHAD: What do you think is next for Launchpad II? As you look ahead, what do you see, and what do you want to accomplish? +KIRSTEN: Well, so it's budget season [chuckles] at thoughtbot at the moment. So we've just gone through our first iteration of what that might look like. And we are super keen to make the most of what we've built over, certainly in my time, the last 18 months. We've had great commercial success, and we've grown existing clients. We've brought on a couple of new ones. And we've really matured our team as well from the point of view of what we think works for our clients and what we get the greatest fulfillment in as well. +So I think in that first card, we would like to grow the team by an additional ten folks, and that's working across design, development, and product management as well. So that's something new that we brought in this year. We had our first product manager join the team, and that's been a huge success as well. It's something that everyone at thoughtbot working on projects had assumed responsibility collectively for, but actually, some projects really need that nominated person. So I'm excited to grow that team as well as the other ones. +And I think looking ahead for our hiring as well building a more geographically diverse team as well that better reflects our client base. So we currently have clients in the Middle East; as I mentioned, we've got France, Germany, and a few more UK-centric ones as well. So it would be great to build a more diverse team from a point of view of life experience. Because as we well know, the more diverse a team, the greater the empathy for a broader range of human experience, and that leads to great products as well. +CHAD: Well, speaking of hiring, you do have a bunch of open positions in Launchpad II now. And we probably can't stress enough that those positions are open to anybody, anywhere in Europe, the Middle East, Africa. And we'd love for people to apply from across all of those places and including an apprenticeship opening, right? +KIRSTEN: Oh, absolutely. I would also encourage people to reach out to me as well if they're not sure whether they would maybe qualify for the role. I think we do a lot of work on our job descriptions to make sure that they are as approachable as possible. But nonetheless, if someone isn't sure, then please do just reach out to me. And we can have an informal chat before the more formal process starts. I'm more than happy to have a 15-minute call with someone and just answer any questions too. +CHAD: Well, on that note, I'm interested in your perspective, especially as someone relatively new to the team. Coming in externally, you have a perspective that maybe someone who's been here a long time doesn't have quite as fresh a perspective. But what do you think makes people a good fit for thoughtbot? +KIRSTEN: From what I've learned from the team over the last 18 months or so, there's obviously a passion for creating great software. But I think what really seems to resonate with folks is feeling like they're a part of something bigger, so open source contributions, contributing to potentially clients who've got some social good agenda. Those kinds of things are pretty important to people. And working with even people who have empathy for each other and who envisage those values we have around earning, imparting, and summoning trust. +I think we've all been through a pretty tough time over the last 18 months. And the level of compassion that everyone has shown each other has been incredible. And the patience, as I've mentioned before, is great. And I think everyone just wants to pull together for positive outcomes, whether it's within the team, whether it's for clients. What would be your old school view then, Chad, as a founder of what, 18 years ago? [laughs] +CHAD: Yeah. I think the other thing that I would call out that maybe isn't explicitly in the values, which people can read about at thoughtbot.com/purpose, is designers, and especially developers at thoughtbot, are not what you might typically envision a developer to be in that developers at thoughtbot are expected to be able to talk directly to clients and work directly with clients. And that's not an expectation everywhere. +So, people who like talking with people about problems and collaborating to solve problems, not everyone is a fit for that. And one of the things we look for in the hiring process is those communication skills, and the ability to have those conversations, and to weigh trade-offs, and be a consultant, and all of those things. So someone who enjoys doing that in the process of building a great product is something that I would call out. +KIRSTEN: Yeah, I think that's a really good point. Collaboration is huge for us, always has been. And obviously, the way that that works has changed slightly with the move to remote working. But I think thoughtbot is the least hierarchical consultancy that I've ever worked for in that everyone is encouraged to give their opinions and discuss challenges with clients very openly. +Everyone is encouraged to contribute. It's not just the senior developers or the team leads who are making decisions. Everyone makes a decision together. And I think that's incredibly empowering for people maybe who haven't had that opportunity before. Sometimes it takes folks a little while to grow in their confidence and believe that it's true. But it's really nice to see when people who join us start coming out of their shells and really get a sense of satisfaction from genuinely being a part of a really constructive team. +CHAD: And the other thing that I often say is really important, not necessarily to being hired at thoughtbot but being really successful here, is being able to lift your head up from the particular client project that you are on right now and to see and get excited by the bigger picture of what's going on. So that might be noticing patterns in the way that we're implementing something that will lead to the creation of an open-source project or a product to solve that need. It could be if you really love thinking about engineering or design best practices and getting the chance to experiment with them in your work, that's going to make you really successful at thoughtbot over the long term. +Because we do great work on clients’ projects, but our actual product that we're selling goes far beyond the lines of code or the design that we produce. You said it yourself earlier, people buy our people, and our process, and our culture. That's what people are making decisions about whether to work with us or someone else over. And so we have an opportunity to be working on improving the company, and our processes, and our engineering practices, and all that stuff, and it makes us a better company. So the people who are able to do that tend to be very successful and grow into leadership positions and those kinds of things. +KIRSTEN: Yeah, I would agree with that. So I was actually going to ask you, Chad, what are your hopes and dreams for the Launchpad II team? We obviously have a few conversations here and there. But it's good to know from your experience, having worked with the team before I came along, maybe it's interesting for people listening what you think the potential is. +CHAD: I think that there is a lot of potential, and I think that it's probably no surprise that I think that, to be honest. [chuckles] I'm very excited by the ability to expand throughout a larger region and to bring new team members on as well as new clients on, and the way that that's working now is really great. It's not that the way that we were working before wasn't good. There are pros and cons to every way of working. And the pros now are being able to hire people no matter where they live and to have the expectation that we're able to work with these clients remotely everywhere. +And we're getting the chance to be involved in a lot of really cool exciting things and with cool, exciting people because we're doing that. And I do this and have done it for so long because of the cool, exciting things that we do with the cool, exciting people that we do them with. So that is what I'm really excited by. And the thing from a business perspective and a team perspective that I keep on reminding people of and pushing people towards is the team structure that we have in the Americas was created at a certain point because the number of people in the Americas made sense to have a breakdown and have some focus. And that focus is proving very positive. +It's not that in Launchpad II, we're not doing a good job on our client work. It's not that people aren't fulfilled in their work. But what we see is when people never know what kind of project they're going to be on next, or are tasked with going from a project where they're doing huge scaling and architecture, and the timelines on things are months, not days, and then you rotate on a project where it's the complete opposite. You're bringing your product to market super quickly. The timelines you're operating on...a ticket you're going to work on now is going to go to production a few minutes later. It's a different skill set. +And not that the people at thoughtbot can't do all of those things, but there is a benefit to being able to excel in the moment of that kind of project that you're on and to be able to raise your hand and say, "You know, I really like this kind of work," and to be able to focus on that. So that's down the road for Launchpad II. That's something that we have to look forward to is the team will eventually get big enough where we're able to say, "Hey, what kind of work do you want to focus on?" It's a transition we've been through in the Americas. Hopefully, we've learned from that. +And the other thing that will be the case for Launchpad II is that it won't necessarily all happen at once. In the Americas, we did it as a reorganization, and it all happened at once. But in Launchpad II, it can happen more organically where we say, "There is enough work in this area and enough people now," that we start to focus a little bit and we create a team of people that focuses on Boost-style projects or a team of people that focus on Lift Off-style projects and without worrying about also needing to create those other teams at the same time. So we should do it more organically. I'm excited. I'm looking forward to that process. I'm not exactly sure when it will happen. But I think it will be an indicator of the growth and success that we've had in Launchpad II. +KIRSTEN: We're certainly watching all of the great experiments that are happening over in Launchpad I in the different teams, looking at the learnings that are coming out of all of the different things. And yeah, I think it's giving us a lot of food for thought right now as to how will that work for us and how will it work for the clients that we work with as well? Because that's the other thing we mentioned before about the maturity of the startup market, et cetera. So we may need to organize ourselves a little bit differently to be able to serve them. So it will be interesting, as you say when we get to the scale, that that's appropriate, which I hope is going to be sooner rather than later. [laughs] So yeah, it's going to be an interesting challenge. +And I agree with you on the organic thing as well. I think it might be a case where some folks want to actually try out some different types of things. Maybe the newer folks who join us next year may not know what gives them the most fulfillment. But that's also another great thing about thoughtbot generally is that nothing is permanent. [laughs] And if we find a better way to do something, then we'll always twist rather than stick. +CHAD: I like that saying. That's cool. You're right to call out that a lot of the improvements that I've talked about are from a team perspective and an individual perspective. But a big driver of that was from the client-side, and we see lots of benefits there too. And you called out that we have project managers now. And that's been successful in a way that project management at thoughtbot has never been successful before. +And part of it is when everything was the same in all of the individual studios, not every project would benefit from a project manager. And if we only have one project and that happens to not be a full-time project for a project manager, it wasn't enough work. But when we can coalesce a team together and a client base together that needs a certain kind of thing consistently, then we're better able to support that which makes our work for the clients better as well. And so that's also been a really good area of improvement for us. +KIRSTEN: Yeah, I think it's interesting to consider product management in the industry as well. I think it's matured quite significantly whether thoughtbot was doing that or not. I think product management generally is a far more important role than it ever used to be because clients themselves invest in those roles a lot more than they used to. +CHAD: Yeah, and I think that I realized...I just caught myself in a mistake. Was I saying project management before? +KIRSTEN: [laughs] I should have corrected you. I wasn't entirely sure if I'd misheard you across the pond here. +CHAD: [laughs] Okay. That was a mistake. +KIRSTEN: I think a few of us still make that mistake. +CHAD: Yes. Actually, that's a really good thing. I caught myself doing it just because they're similar words. But I totally meant product management and not project management. And there are two different things, two distinct things that I think it's important to make that distinction clear. So what is the distinction between those two things, Kirsten? +KIRSTEN: [laughs] And now it's my turn to tie myself in knots a little bit. It's because product management; I think the first thing you go to is thinking about someone who's responsible for maintaining a product roadmap. And I know that that's a spicy conversation to get into sometimes because you don't want them to be so resolutely set at the outset of a project. But you need someone who's got one eye on the end goal. +And sometimes, when you've got a team of developers and designers working to some pretty aggressive timelines, and deep in technical problems and solving challenges, that person who helicopters out and looks across everything and retains the broader context of the overall program or the overall client objectives, and can hold the team true to that is really important strategically for the success of a project. +But I think; actually, you also need to be flexible and listen to the designers and developers when something that was on the roadmap is disproved somehow or is not viable for whatever reason, whether that's because of end-user research or just technically [chuckles] it's too challenging for the budget available to the clients. So then being able to talk with the client as a whole team but lead that discussion and help them understand the recommendations that are being made. I think we've seen that work really well in our team here this year. +CHAD: And I think an important distinction as well is that some of our clients look to us to make those decisions on their behalf, not all of them but some of them. And that's one of the things that distinguishes a product manager and someone who's making decisions about what the product even is versus a project manager who it's much more about the day-to-day tasks, making sure the backlog is organized, tickets are clear, things are moving along, meetings are scheduled, that kind of thing. And it's much less about the product actually being built. +KIRSTEN: Absolutely. +CHAD: Well, I think that brings us at about time. If folks want to get in touch with you, apply to those positions, where are the best places for them to do that? +KIRSTEN: Well, my email is kirsten@thoughtbot.com. And I am on LinkedIn, Kirsten Hurley, pretty searchable,I think going Kirsten Hurley in thoughtbot. Those are the best ways to get ahold of me. +CHAD: And I think people can check out all those jobs and apply at thoughtbot.com/jobs. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks, Mandy. And thank you for listening, listener. See you next time. Special Guest: Kirsten Hurley. + + + Chad interviews Kirsten Hurley, Managing Director of thoughtbot's Launchpad II team. The Launchpad II team covers the EMEA area: that's Europe, the Middle East, and Africa. She talks about working remotely for almost the entire time she's worked with the company, her approach to talking with potential customers when she knows she's never going to meet them in person, and what she sees happening to the different geographies that thoughtbot is selling and expanding into.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Kirsten Hurley, Managing Director of thoughtbot's Launchpad II team. Kirsten, thanks for joining me.

+ +

KIRSTEN: Thanks for having me on, Chad.

+ +

CHAD: So I've now talked with a few managing directors at thoughtbot about the new team that they're leading. So I think listeners are probably expecting what's coming next which is, you know, why don't you give people a little bit of an overview of what the Launchpad II team, which has a slightly different name than the other teams we've talked to so far, do?

+ +

KIRSTEN: Sure. So I guess maybe to remind some folks, so Launchpad I refers to the Americas. So you've already spoken to a few of the managing directors who head up different teams across the Americas. You have different propositions. Over in Launchpad II, which historically was the London studio when we were working in a physical office environment, we are a smaller team than everyone else who was based over in the Americas.

+ +

So we didn't quite scale out to be able to have individual teams working on particular propositions. But I think what the team had been successfully doing anyway was working across everything. And we still do work on Ignite-style projects, Lift Off, and Boost engagements as well. So yeah, that's where we've got to. And I think maybe the changes for us is that since we've gone to fully remote working and officially called ourselves the EMEA Launchpad II team, we've started hiring folks from further afield, which is really exciting for me.

+ +

CHAD: So not everyone may be familiar with the acronym, although it's fairly common, EMEA. So what regions does that actually cover?

+ +

KIRSTEN: [laughs] Sorry. So that's Europe, the Middle East, and Africa. And I should say we were already working with clients pretty much fully across the region anyway. It was just never really official. But I think the more global terminology is Europe, the Middle East, and Africa or EMEA. But because we're thoughtbot and we like to do things a little bit...well, we like to own our things. So we've called it Launchpad II to go with the rocket theme that we had in our rebranding. What was that? The end of last year I think we came up with it all.

+ +

CHAD: Yeah. So what has it been like to go from a team of people that were...[laughs] actually, as I ask this question I realized that you joined a week before the pandemic started, and we had to go remote. So I was going to ask you what it was like to go from a team of people that were going to a studio every day all based in London to a remote team. [laughs] But you never really experienced the alternative.

+ +

KIRSTEN: [laughs] No. I think the most time I spent with the team as a whole was actually in my interview process [laughs] before I even started in person I should say. That was a pretty interesting week. You had flown over from Boston [chuckles] to spend some time getting me all set up and running. And I think it was the Wednesday where you and I had a bit of a chat, and we were concerned about this virus that was going around and the duty of care that we actually had to our teams across the world from a point of view of them commuting to work, and it didn't feel right. And so I think we made the decision that day that from the following week, everyone would start working from home. And I think we thought it would just be for a few weeks, and we'd see how it went. So yeah, it was interesting for sure. [laughs]

+ +

CHAD: Right. And I remember what happened is I went to...I usually leave on a Friday when I visit, but a few of us, I think, went to a pub or something on...we were planning on doing that on Friday. So I was going to leave on Saturday morning, and I did. But I woke up on Saturday morning ready to catch my flight to the news that the U.S. had shut down all flights from the UK or from Europe, was what the headline said. And I was like, oh no, [laughter] I might be stuck here. And then when you actually read the article, it said actually the UK is exempt and also U.S. citizens were exempt, so they can get back. I remember waking up that morning and having a fright that I was going to be stuck there and made it back safely, thankfully. So the U.S. then went remote that following week if I remember the timeline right.

+ +

It was an interesting time. And like you said, we thought it was going to be temporary, relatively short, but it wasn't. And then, at the end of last year, we decided that we would be going completely fully remote, and that was pretty exciting. I think for folks, it was obviously...unexpected is probably the wrong word because we couldn't be in person anyway. But it wasn't what people were necessarily expecting when they joined thoughtbot. People join because we often, or at least they have the expectation that we're in an office together. But it's been exciting for Launchpad II because it means that you can now and are hiring people much differently and further afield than you were in the past, right?

+ +

KIRSTEN: Yeah, and even actually working with partners further afield as well. So we have some great partnerships still in the UK but actually working with some of your cohorts from AgencyU, your coaching program, Subvisual over in Portugal, and a couple of others as well. That's been really great to work with those teams as well.

+ +

CHAD: Having come into a new team as in a leadership position and being, basically as we've said, entirely remote almost from day one, how has that been for you?

+ +

KIRSTEN: Certainly, it wasn't the plan. [laughs] So I think my last few roles were very much working based in an office. And so my background is commercial and sales, account management. And I was very used to building rapport with teams and clients in person. So I had joined thoughtbot and joined the London studio as it was then but Launchpad II with a remit to grow the business. So I think you had been looking after the team for about a year, giving us a great foundation to then really grow.

+ +

And coming in, this black swan event had happened in the world, so the priorities changed overnight. And it was okay; how do I keep this team safe? Is everyone set up to be successful in their role? And also our existing clients and our existing projects, are they supported in the right way? This is a shock to them as well. I think, at thoughtbot, we're very lucky that from a point of view of asynchronous communication and remote working practices, being a global company, it wasn't such a shock to the system, but for some of our clients, it was. So we had to make sure that they were supported. And in some cases, we showed them what good looks like.

+ +

But rather than focusing on new business and growing straight away, it was really a period of stabilization, I would say, for about three to six months while everyone got used to what was an evolving situation, but we came through it. And I have to say a huge thank you to the team actually for their kindness and patience with me and learning remotely everything about thoughtbot that I was so excited to become a part of. But also, learning a leadership style over Zoom wasn't really what I thought I was going to be doing.

+ +

CHAD: Well, you mentioned selling a lot of what you had done previously was relationship building with clients in person or potential clients in person. Is there anything that stands out to you in terms of how you've needed to adjust either your style or your approach when talking with potential customers when you know you're never going to meet them in person?

+ +

KIRSTEN: I'm not sure you can really change your personality per se because I am always interested in building rapport through understanding an individual's motives and what they're passionate about. And quite often, those conversations can be things outside of work, so talking with clients about maybe going up for runs and things like that and personal bests and things just because that's a natural thing to talk to someone about. I still very much make room for those kinds of things in calls.

+ +

Because I think in a consultancy relationship, people buy people, and people want to work with people who understand them. And while the majority of that is obviously people understanding your job and the product that you want to be building as well, I think you need to have that personal element. So while it felt a bit stilted over Zoom to make that time, I think that it's worth it in the long run.

+ +

CHAD: That's a really good point. I think if you're not careful about it, it's very easy to just get right to business in a call as opposed to when you're meeting someone in person you need to walk to a conference room or something, and it naturally lends itself to some small talk.

+ +

KIRSTEN: Exactly, that bit where you're riding in the lift together.

+ +

CHAD: And I think that that probably applies to sales as much as it does our team members too.

+ +

KIRSTEN: Absolutely. Funnily enough, I was talking with our Development Director here, Rob Whittaker, the other day about one-to-ones should not be really that much talking about your client project. It's obviously important to make sure that someone is happy and they're being successful in their work. But actually, what's going on behind the scenes and understanding that within your team is probably just as important, if not more so, like you say.

+ +

CHAD: So tell us a little bit about some of the interesting work that's happening in Launchpad II.

+ +

KIRSTEN: Well, we've got a couple of flagship clients that keep on growing for us, which is really great, actually. They're effectively partnerships, really at this point. And so, one of those clients is a large financial service institution where we were building APIs for all of the COVID loan schemes. And I think the last I checked, the amount of money that had flowed through that system and the loans approved was something over £75 billion. So for a pretty small development team, it's really impressive what they've achieved over that time. So that's a team of three developers in a Boost-style engagement, so like Josh's team over in the U.S. working on a Rails project and working alongside business analysts from the team and other stakeholders there as well.

+ +

And so over in the Middle East, we have a food delivery client, so they're actually a huge brand over there. And we had started working with them nearly two years ago now on creating a mobile app for their customers. So we've been adding to features, getting that released. And obviously, with what's happened in the last 18 months, food delivery is a sector where you've seen huge growth. And that's even led to us recently looking at re-engineering the platform and making sure that we're still managing to delight their customers as well with their user experience.

+ +

And we've even been working on some Ignite-style projects too. So there's a lot of startups, a lot of folks have been at home thinking about what is this new business? What's the impact I'm going to have on the world? And most recently, we've been running some product design sprints with a wellness brand who are looking at bringing a different type of wellness to the market. And again, that's a mobile app which we're really excited to be working on.

+ +

CHAD: Have you seen the different geographies both from the U.S. and UK...what do you see happening to the different geographies that you're selling into and expanding into? Are there any notable differences you would call out?

+ +

KIRSTEN: I think the biggest difference that I see between clients in the Americas and over here in Europe, the Middle East, Africa would be the funding levels for startups and the expectations around that. It seems like a more mature market from a point of view of being able to get a decent budget to really build a meaningful platform for first release over in the Americas, whereas over here, it's a bit leaner definitely [laughs] on the startup side of things. So I think that's probably the biggest challenge we have when talking with clients and making sure we can give them the bang for the buck, as it were. So making sure that the research that we did, that the designers do, for example, is focused on the right thing and really gives them the insight that they need to have the confidence to progress and invest in that build. Or whether they actually need to go back and do more before they actually start spending on the development side of things.

+ +

CHAD: I would definitely second that. And one thing that I noticed not only were the amounts different in the U.S. and the UK, but it seems like in the U.S., when you're talking with a founder, there's more often than not other people they need to check in with in order to make a decision. And when I was talking to founders in the UK and beyond and in Europe, what I often felt was that there was actually someone that they needed to check in with and get permission from or that was holding the purse strings or something. And that might be a cultural thing as well, far less likely to just make a decision with you in the meeting saying, "Yeah, we're going to work together." There was always, for me, a lot more back and forth, and checking and permission getting around decisions that are being made.

+ +

KIRSTEN: Yeah, I would agree with that.

+ +

CHAD: Is that something that you've seen too?

+ +

KIRSTEN: I think so. It's interesting because what we've started doing recently actually...sometimes through the product design sprints but even in the sales process, if a founder does know or does realize in those conversations that they're going to need to find an additional source of money to be able to fund it, conversations have gone more into how can we help them with their pitch deck as well? And I think I've seen this with the Ignite team over in the Americas as well, to be fair. The prototypes that we build, very early-stage prototypes, where we're testing and doing the user research those go into the pitch decks now to give potential investors greater confidence as well if that's the route that they go down.

+ +

MIDROLL AD

+ +

CHAD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU.

+ +

AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions, and also monthly group meetings. We start with goal setting, advice, and problem solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other.

+ +

Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot I’ve seen and learned from a lot of different situations, and I’d be happy to work with you.

+ +

Learn more and sign up at thoughtbot.com/agencyu

+ +

CHAD: What do you think is next for Launchpad II? As you look ahead, what do you see, and what do you want to accomplish?

+ +

KIRSTEN: Well, so it's budget season [chuckles] at thoughtbot at the moment. So we've just gone through our first iteration of what that might look like. And we are super keen to make the most of what we've built over, certainly in my time, the last 18 months. We've had great commercial success, and we've grown existing clients. We've brought on a couple of new ones. And we've really matured our team as well from the point of view of what we think works for our clients and what we get the greatest fulfillment in as well.

+ +

So I think in that first card, we would like to grow the team by an additional ten folks, and that's working across design, development, and product management as well. So that's something new that we brought in this year. We had our first product manager join the team, and that's been a huge success as well. It's something that everyone at thoughtbot working on projects had assumed responsibility collectively for, but actually, some projects really need that nominated person. So I'm excited to grow that team as well as the other ones.

+ +

And I think looking ahead for our hiring as well building a more geographically diverse team as well that better reflects our client base. So we currently have clients in the Middle East; as I mentioned, we've got France, Germany, and a few more UK-centric ones as well. So it would be great to build a more diverse team from a point of view of life experience. Because as we well know, the more diverse a team, the greater the empathy for a broader range of human experience, and that leads to great products as well.

+ +

CHAD: Well, speaking of hiring, you do have a bunch of open positions in Launchpad II now. And we probably can't stress enough that those positions are open to anybody, anywhere in Europe, the Middle East, Africa. And we'd love for people to apply from across all of those places and including an apprenticeship opening, right?

+ +

KIRSTEN: Oh, absolutely. I would also encourage people to reach out to me as well if they're not sure whether they would maybe qualify for the role. I think we do a lot of work on our job descriptions to make sure that they are as approachable as possible. But nonetheless, if someone isn't sure, then please do just reach out to me. And we can have an informal chat before the more formal process starts. I'm more than happy to have a 15-minute call with someone and just answer any questions too.

+ +

CHAD: Well, on that note, I'm interested in your perspective, especially as someone relatively new to the team. Coming in externally, you have a perspective that maybe someone who's been here a long time doesn't have quite as fresh a perspective. But what do you think makes people a good fit for thoughtbot?

+ +

KIRSTEN: From what I've learned from the team over the last 18 months or so, there's obviously a passion for creating great software. But I think what really seems to resonate with folks is feeling like they're a part of something bigger, so open source contributions, contributing to potentially clients who've got some social good agenda. Those kinds of things are pretty important to people. And working with even people who have empathy for each other and who envisage those values we have around earning, imparting, and summoning trust.

+ +

I think we've all been through a pretty tough time over the last 18 months. And the level of compassion that everyone has shown each other has been incredible. And the patience, as I've mentioned before, is great. And I think everyone just wants to pull together for positive outcomes, whether it's within the team, whether it's for clients. What would be your old school view then, Chad, as a founder of what, 18 years ago? [laughs]

+ +

CHAD: Yeah. I think the other thing that I would call out that maybe isn't explicitly in the values, which people can read about at thoughtbot.com/purpose, is designers, and especially developers at thoughtbot, are not what you might typically envision a developer to be in that developers at thoughtbot are expected to be able to talk directly to clients and work directly with clients. And that's not an expectation everywhere.

+ +

So, people who like talking with people about problems and collaborating to solve problems, not everyone is a fit for that. And one of the things we look for in the hiring process is those communication skills, and the ability to have those conversations, and to weigh trade-offs, and be a consultant, and all of those things. So someone who enjoys doing that in the process of building a great product is something that I would call out.

+ +

KIRSTEN: Yeah, I think that's a really good point. Collaboration is huge for us, always has been. And obviously, the way that that works has changed slightly with the move to remote working. But I think thoughtbot is the least hierarchical consultancy that I've ever worked for in that everyone is encouraged to give their opinions and discuss challenges with clients very openly.

+ +

Everyone is encouraged to contribute. It's not just the senior developers or the team leads who are making decisions. Everyone makes a decision together. And I think that's incredibly empowering for people maybe who haven't had that opportunity before. Sometimes it takes folks a little while to grow in their confidence and believe that it's true. But it's really nice to see when people who join us start coming out of their shells and really get a sense of satisfaction from genuinely being a part of a really constructive team.

+ +

CHAD: And the other thing that I often say is really important, not necessarily to being hired at thoughtbot but being really successful here, is being able to lift your head up from the particular client project that you are on right now and to see and get excited by the bigger picture of what's going on. So that might be noticing patterns in the way that we're implementing something that will lead to the creation of an open-source project or a product to solve that need. It could be if you really love thinking about engineering or design best practices and getting the chance to experiment with them in your work, that's going to make you really successful at thoughtbot over the long term.

+ +

Because we do great work on clients’ projects, but our actual product that we're selling goes far beyond the lines of code or the design that we produce. You said it yourself earlier, people buy our people, and our process, and our culture. That's what people are making decisions about whether to work with us or someone else over. And so we have an opportunity to be working on improving the company, and our processes, and our engineering practices, and all that stuff, and it makes us a better company. So the people who are able to do that tend to be very successful and grow into leadership positions and those kinds of things.

+ +

KIRSTEN: Yeah, I would agree with that. So I was actually going to ask you, Chad, what are your hopes and dreams for the Launchpad II team? We obviously have a few conversations here and there. But it's good to know from your experience, having worked with the team before I came along, maybe it's interesting for people listening what you think the potential is.

+ +

CHAD: I think that there is a lot of potential, and I think that it's probably no surprise that I think that, to be honest. [chuckles] I'm very excited by the ability to expand throughout a larger region and to bring new team members on as well as new clients on, and the way that that's working now is really great. It's not that the way that we were working before wasn't good. There are pros and cons to every way of working. And the pros now are being able to hire people no matter where they live and to have the expectation that we're able to work with these clients remotely everywhere.

+ +

And we're getting the chance to be involved in a lot of really cool exciting things and with cool, exciting people because we're doing that. And I do this and have done it for so long because of the cool, exciting things that we do with the cool, exciting people that we do them with. So that is what I'm really excited by. And the thing from a business perspective and a team perspective that I keep on reminding people of and pushing people towards is the team structure that we have in the Americas was created at a certain point because the number of people in the Americas made sense to have a breakdown and have some focus. And that focus is proving very positive.

+ +

It's not that in Launchpad II, we're not doing a good job on our client work. It's not that people aren't fulfilled in their work. But what we see is when people never know what kind of project they're going to be on next, or are tasked with going from a project where they're doing huge scaling and architecture, and the timelines on things are months, not days, and then you rotate on a project where it's the complete opposite. You're bringing your product to market super quickly. The timelines you're operating on...a ticket you're going to work on now is going to go to production a few minutes later. It's a different skill set.

+ +

And not that the people at thoughtbot can't do all of those things, but there is a benefit to being able to excel in the moment of that kind of project that you're on and to be able to raise your hand and say, "You know, I really like this kind of work," and to be able to focus on that. So that's down the road for Launchpad II. That's something that we have to look forward to is the team will eventually get big enough where we're able to say, "Hey, what kind of work do you want to focus on?" It's a transition we've been through in the Americas. Hopefully, we've learned from that.

+ +

And the other thing that will be the case for Launchpad II is that it won't necessarily all happen at once. In the Americas, we did it as a reorganization, and it all happened at once. But in Launchpad II, it can happen more organically where we say, "There is enough work in this area and enough people now," that we start to focus a little bit and we create a team of people that focuses on Boost-style projects or a team of people that focus on Lift Off-style projects and without worrying about also needing to create those other teams at the same time. So we should do it more organically. I'm excited. I'm looking forward to that process. I'm not exactly sure when it will happen. But I think it will be an indicator of the growth and success that we've had in Launchpad II.

+ +

KIRSTEN: We're certainly watching all of the great experiments that are happening over in Launchpad I in the different teams, looking at the learnings that are coming out of all of the different things. And yeah, I think it's giving us a lot of food for thought right now as to how will that work for us and how will it work for the clients that we work with as well? Because that's the other thing we mentioned before about the maturity of the startup market, et cetera. So we may need to organize ourselves a little bit differently to be able to serve them. So it will be interesting, as you say when we get to the scale, that that's appropriate, which I hope is going to be sooner rather than later. [laughs] So yeah, it's going to be an interesting challenge.

+ +

And I agree with you on the organic thing as well. I think it might be a case where some folks want to actually try out some different types of things. Maybe the newer folks who join us next year may not know what gives them the most fulfillment. But that's also another great thing about thoughtbot generally is that nothing is permanent. [laughs] And if we find a better way to do something, then we'll always twist rather than stick.

+ +

CHAD: I like that saying. That's cool. You're right to call out that a lot of the improvements that I've talked about are from a team perspective and an individual perspective. But a big driver of that was from the client-side, and we see lots of benefits there too. And you called out that we have project managers now. And that's been successful in a way that project management at thoughtbot has never been successful before.

+ +

And part of it is when everything was the same in all of the individual studios, not every project would benefit from a project manager. And if we only have one project and that happens to not be a full-time project for a project manager, it wasn't enough work. But when we can coalesce a team together and a client base together that needs a certain kind of thing consistently, then we're better able to support that which makes our work for the clients better as well. And so that's also been a really good area of improvement for us.

+ +

KIRSTEN: Yeah, I think it's interesting to consider product management in the industry as well. I think it's matured quite significantly whether thoughtbot was doing that or not. I think product management generally is a far more important role than it ever used to be because clients themselves invest in those roles a lot more than they used to.

+ +

CHAD: Yeah, and I think that I realized...I just caught myself in a mistake. Was I saying project management before?

+ +

KIRSTEN: [laughs] I should have corrected you. I wasn't entirely sure if I'd misheard you across the pond here.

+ +

CHAD: [laughs] Okay. That was a mistake.

+ +

KIRSTEN: I think a few of us still make that mistake.

+ +

CHAD: Yes. Actually, that's a really good thing. I caught myself doing it just because they're similar words. But I totally meant product management and not project management. And there are two different things, two distinct things that I think it's important to make that distinction clear. So what is the distinction between those two things, Kirsten?

+ +

KIRSTEN: [laughs] And now it's my turn to tie myself in knots a little bit. It's because product management; I think the first thing you go to is thinking about someone who's responsible for maintaining a product roadmap. And I know that that's a spicy conversation to get into sometimes because you don't want them to be so resolutely set at the outset of a project. But you need someone who's got one eye on the end goal.

+ +

And sometimes, when you've got a team of developers and designers working to some pretty aggressive timelines, and deep in technical problems and solving challenges, that person who helicopters out and looks across everything and retains the broader context of the overall program or the overall client objectives, and can hold the team true to that is really important strategically for the success of a project.

+ +

But I think; actually, you also need to be flexible and listen to the designers and developers when something that was on the roadmap is disproved somehow or is not viable for whatever reason, whether that's because of end-user research or just technically [chuckles] it's too challenging for the budget available to the clients. So then being able to talk with the client as a whole team but lead that discussion and help them understand the recommendations that are being made. I think we've seen that work really well in our team here this year.

+ +

CHAD: And I think an important distinction as well is that some of our clients look to us to make those decisions on their behalf, not all of them but some of them. And that's one of the things that distinguishes a product manager and someone who's making decisions about what the product even is versus a project manager who it's much more about the day-to-day tasks, making sure the backlog is organized, tickets are clear, things are moving along, meetings are scheduled, that kind of thing. And it's much less about the product actually being built.

+ +

KIRSTEN: Absolutely.

+ +

CHAD: Well, I think that brings us at about time. If folks want to get in touch with you, apply to those positions, where are the best places for them to do that?

+ +

KIRSTEN: Well, my email is kirsten@thoughtbot.com. And I am on LinkedIn, Kirsten Hurley, pretty searchable,I think going Kirsten Hurley in thoughtbot. Those are the best ways to get ahold of me.

+ +

CHAD: And I think people can check out all those jobs and apply at thoughtbot.com/jobs. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks, Mandy. And thank you for listening, listener. See you next time.

Special Guest: Kirsten Hurley.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad interviews Kirsten Hurley, Managing Director of thoughtbot's Launchpad II team. The Launchpad II team covers the EMEA area: that's Europe, the Middle East, and Africa. She talks about working remotely for almost the entire time she's worked with the company, her approach to talking with potential customers when she knows she's never going to meet them in person, and what she sees happening to the different geographies that thoughtbot is selling and expanding into.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Kirsten Hurley, Managing Director of thoughtbot's Launchpad II team. Kirsten, thanks for joining me.

+ +

KIRSTEN: Thanks for having me on, Chad.

+ +

CHAD: So I've now talked with a few managing directors at thoughtbot about the new team that they're leading. So I think listeners are probably expecting what's coming next which is, you know, why don't you give people a little bit of an overview of what the Launchpad II team, which has a slightly different name than the other teams we've talked to so far, do?

+ +

KIRSTEN: Sure. So I guess maybe to remind some folks, so Launchpad I refers to the Americas. So you've already spoken to a few of the managing directors who head up different teams across the Americas. You have different propositions. Over in Launchpad II, which historically was the London studio when we were working in a physical office environment, we are a smaller team than everyone else who was based over in the Americas.

+ +

So we didn't quite scale out to be able to have individual teams working on particular propositions. But I think what the team had been successfully doing anyway was working across everything. And we still do work on Ignite-style projects, Lift Off, and Boost engagements as well. So yeah, that's where we've got to. And I think maybe the changes for us is that since we've gone to fully remote working and officially called ourselves the EMEA Launchpad II team, we've started hiring folks from further afield, which is really exciting for me.

+ +

CHAD: So not everyone may be familiar with the acronym, although it's fairly common, EMEA. So what regions does that actually cover?

+ +

KIRSTEN: [laughs] Sorry. So that's Europe, the Middle East, and Africa. And I should say we were already working with clients pretty much fully across the region anyway. It was just never really official. But I think the more global terminology is Europe, the Middle East, and Africa or EMEA. But because we're thoughtbot and we like to do things a little bit...well, we like to own our things. So we've called it Launchpad II to go with the rocket theme that we had in our rebranding. What was that? The end of last year I think we came up with it all.

+ +

CHAD: Yeah. So what has it been like to go from a team of people that were...[laughs] actually, as I ask this question I realized that you joined a week before the pandemic started, and we had to go remote. So I was going to ask you what it was like to go from a team of people that were going to a studio every day all based in London to a remote team. [laughs] But you never really experienced the alternative.

+ +

KIRSTEN: [laughs] No. I think the most time I spent with the team as a whole was actually in my interview process [laughs] before I even started in person I should say. That was a pretty interesting week. You had flown over from Boston [chuckles] to spend some time getting me all set up and running. And I think it was the Wednesday where you and I had a bit of a chat, and we were concerned about this virus that was going around and the duty of care that we actually had to our teams across the world from a point of view of them commuting to work, and it didn't feel right. And so I think we made the decision that day that from the following week, everyone would start working from home. And I think we thought it would just be for a few weeks, and we'd see how it went. So yeah, it was interesting for sure. [laughs]

+ +

CHAD: Right. And I remember what happened is I went to...I usually leave on a Friday when I visit, but a few of us, I think, went to a pub or something on...we were planning on doing that on Friday. So I was going to leave on Saturday morning, and I did. But I woke up on Saturday morning ready to catch my flight to the news that the U.S. had shut down all flights from the UK or from Europe, was what the headline said. And I was like, oh no, [laughter] I might be stuck here. And then when you actually read the article, it said actually the UK is exempt and also U.S. citizens were exempt, so they can get back. I remember waking up that morning and having a fright that I was going to be stuck there and made it back safely, thankfully. So the U.S. then went remote that following week if I remember the timeline right.

+ +

It was an interesting time. And like you said, we thought it was going to be temporary, relatively short, but it wasn't. And then, at the end of last year, we decided that we would be going completely fully remote, and that was pretty exciting. I think for folks, it was obviously...unexpected is probably the wrong word because we couldn't be in person anyway. But it wasn't what people were necessarily expecting when they joined thoughtbot. People join because we often, or at least they have the expectation that we're in an office together. But it's been exciting for Launchpad II because it means that you can now and are hiring people much differently and further afield than you were in the past, right?

+ +

KIRSTEN: Yeah, and even actually working with partners further afield as well. So we have some great partnerships still in the UK but actually working with some of your cohorts from AgencyU, your coaching program, Subvisual over in Portugal, and a couple of others as well. That's been really great to work with those teams as well.

+ +

CHAD: Having come into a new team as in a leadership position and being, basically as we've said, entirely remote almost from day one, how has that been for you?

+ +

KIRSTEN: Certainly, it wasn't the plan. [laughs] So I think my last few roles were very much working based in an office. And so my background is commercial and sales, account management. And I was very used to building rapport with teams and clients in person. So I had joined thoughtbot and joined the London studio as it was then but Launchpad II with a remit to grow the business. So I think you had been looking after the team for about a year, giving us a great foundation to then really grow.

+ +

And coming in, this black swan event had happened in the world, so the priorities changed overnight. And it was okay; how do I keep this team safe? Is everyone set up to be successful in their role? And also our existing clients and our existing projects, are they supported in the right way? This is a shock to them as well. I think, at thoughtbot, we're very lucky that from a point of view of asynchronous communication and remote working practices, being a global company, it wasn't such a shock to the system, but for some of our clients, it was. So we had to make sure that they were supported. And in some cases, we showed them what good looks like.

+ +

But rather than focusing on new business and growing straight away, it was really a period of stabilization, I would say, for about three to six months while everyone got used to what was an evolving situation, but we came through it. And I have to say a huge thank you to the team actually for their kindness and patience with me and learning remotely everything about thoughtbot that I was so excited to become a part of. But also, learning a leadership style over Zoom wasn't really what I thought I was going to be doing.

+ +

CHAD: Well, you mentioned selling a lot of what you had done previously was relationship building with clients in person or potential clients in person. Is there anything that stands out to you in terms of how you've needed to adjust either your style or your approach when talking with potential customers when you know you're never going to meet them in person?

+ +

KIRSTEN: I'm not sure you can really change your personality per se because I am always interested in building rapport through understanding an individual's motives and what they're passionate about. And quite often, those conversations can be things outside of work, so talking with clients about maybe going up for runs and things like that and personal bests and things just because that's a natural thing to talk to someone about. I still very much make room for those kinds of things in calls.

+ +

Because I think in a consultancy relationship, people buy people, and people want to work with people who understand them. And while the majority of that is obviously people understanding your job and the product that you want to be building as well, I think you need to have that personal element. So while it felt a bit stilted over Zoom to make that time, I think that it's worth it in the long run.

+ +

CHAD: That's a really good point. I think if you're not careful about it, it's very easy to just get right to business in a call as opposed to when you're meeting someone in person you need to walk to a conference room or something, and it naturally lends itself to some small talk.

+ +

KIRSTEN: Exactly, that bit where you're riding in the lift together.

+ +

CHAD: And I think that that probably applies to sales as much as it does our team members too.

+ +

KIRSTEN: Absolutely. Funnily enough, I was talking with our Development Director here, Rob Whittaker, the other day about one-to-ones should not be really that much talking about your client project. It's obviously important to make sure that someone is happy and they're being successful in their work. But actually, what's going on behind the scenes and understanding that within your team is probably just as important, if not more so, like you say.

+ +

CHAD: So tell us a little bit about some of the interesting work that's happening in Launchpad II.

+ +

KIRSTEN: Well, we've got a couple of flagship clients that keep on growing for us, which is really great, actually. They're effectively partnerships, really at this point. And so, one of those clients is a large financial service institution where we were building APIs for all of the COVID loan schemes. And I think the last I checked, the amount of money that had flowed through that system and the loans approved was something over £75 billion. So for a pretty small development team, it's really impressive what they've achieved over that time. So that's a team of three developers in a Boost-style engagement, so like Josh's team over in the U.S. working on a Rails project and working alongside business analysts from the team and other stakeholders there as well.

+ +

And so over in the Middle East, we have a food delivery client, so they're actually a huge brand over there. And we had started working with them nearly two years ago now on creating a mobile app for their customers. So we've been adding to features, getting that released. And obviously, with what's happened in the last 18 months, food delivery is a sector where you've seen huge growth. And that's even led to us recently looking at re-engineering the platform and making sure that we're still managing to delight their customers as well with their user experience.

+ +

And we've even been working on some Ignite-style projects too. So there's a lot of startups, a lot of folks have been at home thinking about what is this new business? What's the impact I'm going to have on the world? And most recently, we've been running some product design sprints with a wellness brand who are looking at bringing a different type of wellness to the market. And again, that's a mobile app which we're really excited to be working on.

+ +

CHAD: Have you seen the different geographies both from the U.S. and UK...what do you see happening to the different geographies that you're selling into and expanding into? Are there any notable differences you would call out?

+ +

KIRSTEN: I think the biggest difference that I see between clients in the Americas and over here in Europe, the Middle East, Africa would be the funding levels for startups and the expectations around that. It seems like a more mature market from a point of view of being able to get a decent budget to really build a meaningful platform for first release over in the Americas, whereas over here, it's a bit leaner definitely [laughs] on the startup side of things. So I think that's probably the biggest challenge we have when talking with clients and making sure we can give them the bang for the buck, as it were. So making sure that the research that we did, that the designers do, for example, is focused on the right thing and really gives them the insight that they need to have the confidence to progress and invest in that build. Or whether they actually need to go back and do more before they actually start spending on the development side of things.

+ +

CHAD: I would definitely second that. And one thing that I noticed not only were the amounts different in the U.S. and the UK, but it seems like in the U.S., when you're talking with a founder, there's more often than not other people they need to check in with in order to make a decision. And when I was talking to founders in the UK and beyond and in Europe, what I often felt was that there was actually someone that they needed to check in with and get permission from or that was holding the purse strings or something. And that might be a cultural thing as well, far less likely to just make a decision with you in the meeting saying, "Yeah, we're going to work together." There was always, for me, a lot more back and forth, and checking and permission getting around decisions that are being made.

+ +

KIRSTEN: Yeah, I would agree with that.

+ +

CHAD: Is that something that you've seen too?

+ +

KIRSTEN: I think so. It's interesting because what we've started doing recently actually...sometimes through the product design sprints but even in the sales process, if a founder does know or does realize in those conversations that they're going to need to find an additional source of money to be able to fund it, conversations have gone more into how can we help them with their pitch deck as well? And I think I've seen this with the Ignite team over in the Americas as well, to be fair. The prototypes that we build, very early-stage prototypes, where we're testing and doing the user research those go into the pitch decks now to give potential investors greater confidence as well if that's the route that they go down.

+ +

MIDROLL AD

+ +

CHAD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU.

+ +

AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions, and also monthly group meetings. We start with goal setting, advice, and problem solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other.

+ +

Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot I’ve seen and learned from a lot of different situations, and I’d be happy to work with you.

+ +

Learn more and sign up at thoughtbot.com/agencyu

+ +

CHAD: What do you think is next for Launchpad II? As you look ahead, what do you see, and what do you want to accomplish?

+ +

KIRSTEN: Well, so it's budget season [chuckles] at thoughtbot at the moment. So we've just gone through our first iteration of what that might look like. And we are super keen to make the most of what we've built over, certainly in my time, the last 18 months. We've had great commercial success, and we've grown existing clients. We've brought on a couple of new ones. And we've really matured our team as well from the point of view of what we think works for our clients and what we get the greatest fulfillment in as well.

+ +

So I think in that first card, we would like to grow the team by an additional ten folks, and that's working across design, development, and product management as well. So that's something new that we brought in this year. We had our first product manager join the team, and that's been a huge success as well. It's something that everyone at thoughtbot working on projects had assumed responsibility collectively for, but actually, some projects really need that nominated person. So I'm excited to grow that team as well as the other ones.

+ +

And I think looking ahead for our hiring as well building a more geographically diverse team as well that better reflects our client base. So we currently have clients in the Middle East; as I mentioned, we've got France, Germany, and a few more UK-centric ones as well. So it would be great to build a more diverse team from a point of view of life experience. Because as we well know, the more diverse a team, the greater the empathy for a broader range of human experience, and that leads to great products as well.

+ +

CHAD: Well, speaking of hiring, you do have a bunch of open positions in Launchpad II now. And we probably can't stress enough that those positions are open to anybody, anywhere in Europe, the Middle East, Africa. And we'd love for people to apply from across all of those places and including an apprenticeship opening, right?

+ +

KIRSTEN: Oh, absolutely. I would also encourage people to reach out to me as well if they're not sure whether they would maybe qualify for the role. I think we do a lot of work on our job descriptions to make sure that they are as approachable as possible. But nonetheless, if someone isn't sure, then please do just reach out to me. And we can have an informal chat before the more formal process starts. I'm more than happy to have a 15-minute call with someone and just answer any questions too.

+ +

CHAD: Well, on that note, I'm interested in your perspective, especially as someone relatively new to the team. Coming in externally, you have a perspective that maybe someone who's been here a long time doesn't have quite as fresh a perspective. But what do you think makes people a good fit for thoughtbot?

+ +

KIRSTEN: From what I've learned from the team over the last 18 months or so, there's obviously a passion for creating great software. But I think what really seems to resonate with folks is feeling like they're a part of something bigger, so open source contributions, contributing to potentially clients who've got some social good agenda. Those kinds of things are pretty important to people. And working with even people who have empathy for each other and who envisage those values we have around earning, imparting, and summoning trust.

+ +

I think we've all been through a pretty tough time over the last 18 months. And the level of compassion that everyone has shown each other has been incredible. And the patience, as I've mentioned before, is great. And I think everyone just wants to pull together for positive outcomes, whether it's within the team, whether it's for clients. What would be your old school view then, Chad, as a founder of what, 18 years ago? [laughs]

+ +

CHAD: Yeah. I think the other thing that I would call out that maybe isn't explicitly in the values, which people can read about at thoughtbot.com/purpose, is designers, and especially developers at thoughtbot, are not what you might typically envision a developer to be in that developers at thoughtbot are expected to be able to talk directly to clients and work directly with clients. And that's not an expectation everywhere.

+ +

So, people who like talking with people about problems and collaborating to solve problems, not everyone is a fit for that. And one of the things we look for in the hiring process is those communication skills, and the ability to have those conversations, and to weigh trade-offs, and be a consultant, and all of those things. So someone who enjoys doing that in the process of building a great product is something that I would call out.

+ +

KIRSTEN: Yeah, I think that's a really good point. Collaboration is huge for us, always has been. And obviously, the way that that works has changed slightly with the move to remote working. But I think thoughtbot is the least hierarchical consultancy that I've ever worked for in that everyone is encouraged to give their opinions and discuss challenges with clients very openly.

+ +

Everyone is encouraged to contribute. It's not just the senior developers or the team leads who are making decisions. Everyone makes a decision together. And I think that's incredibly empowering for people maybe who haven't had that opportunity before. Sometimes it takes folks a little while to grow in their confidence and believe that it's true. But it's really nice to see when people who join us start coming out of their shells and really get a sense of satisfaction from genuinely being a part of a really constructive team.

+ +

CHAD: And the other thing that I often say is really important, not necessarily to being hired at thoughtbot but being really successful here, is being able to lift your head up from the particular client project that you are on right now and to see and get excited by the bigger picture of what's going on. So that might be noticing patterns in the way that we're implementing something that will lead to the creation of an open-source project or a product to solve that need. It could be if you really love thinking about engineering or design best practices and getting the chance to experiment with them in your work, that's going to make you really successful at thoughtbot over the long term.

+ +

Because we do great work on clients’ projects, but our actual product that we're selling goes far beyond the lines of code or the design that we produce. You said it yourself earlier, people buy our people, and our process, and our culture. That's what people are making decisions about whether to work with us or someone else over. And so we have an opportunity to be working on improving the company, and our processes, and our engineering practices, and all that stuff, and it makes us a better company. So the people who are able to do that tend to be very successful and grow into leadership positions and those kinds of things.

+ +

KIRSTEN: Yeah, I would agree with that. So I was actually going to ask you, Chad, what are your hopes and dreams for the Launchpad II team? We obviously have a few conversations here and there. But it's good to know from your experience, having worked with the team before I came along, maybe it's interesting for people listening what you think the potential is.

+ +

CHAD: I think that there is a lot of potential, and I think that it's probably no surprise that I think that, to be honest. [chuckles] I'm very excited by the ability to expand throughout a larger region and to bring new team members on as well as new clients on, and the way that that's working now is really great. It's not that the way that we were working before wasn't good. There are pros and cons to every way of working. And the pros now are being able to hire people no matter where they live and to have the expectation that we're able to work with these clients remotely everywhere.

+ +

And we're getting the chance to be involved in a lot of really cool exciting things and with cool, exciting people because we're doing that. And I do this and have done it for so long because of the cool, exciting things that we do with the cool, exciting people that we do them with. So that is what I'm really excited by. And the thing from a business perspective and a team perspective that I keep on reminding people of and pushing people towards is the team structure that we have in the Americas was created at a certain point because the number of people in the Americas made sense to have a breakdown and have some focus. And that focus is proving very positive.

+ +

It's not that in Launchpad II, we're not doing a good job on our client work. It's not that people aren't fulfilled in their work. But what we see is when people never know what kind of project they're going to be on next, or are tasked with going from a project where they're doing huge scaling and architecture, and the timelines on things are months, not days, and then you rotate on a project where it's the complete opposite. You're bringing your product to market super quickly. The timelines you're operating on...a ticket you're going to work on now is going to go to production a few minutes later. It's a different skill set.

+ +

And not that the people at thoughtbot can't do all of those things, but there is a benefit to being able to excel in the moment of that kind of project that you're on and to be able to raise your hand and say, "You know, I really like this kind of work," and to be able to focus on that. So that's down the road for Launchpad II. That's something that we have to look forward to is the team will eventually get big enough where we're able to say, "Hey, what kind of work do you want to focus on?" It's a transition we've been through in the Americas. Hopefully, we've learned from that.

+ +

And the other thing that will be the case for Launchpad II is that it won't necessarily all happen at once. In the Americas, we did it as a reorganization, and it all happened at once. But in Launchpad II, it can happen more organically where we say, "There is enough work in this area and enough people now," that we start to focus a little bit and we create a team of people that focuses on Boost-style projects or a team of people that focus on Lift Off-style projects and without worrying about also needing to create those other teams at the same time. So we should do it more organically. I'm excited. I'm looking forward to that process. I'm not exactly sure when it will happen. But I think it will be an indicator of the growth and success that we've had in Launchpad II.

+ +

KIRSTEN: We're certainly watching all of the great experiments that are happening over in Launchpad I in the different teams, looking at the learnings that are coming out of all of the different things. And yeah, I think it's giving us a lot of food for thought right now as to how will that work for us and how will it work for the clients that we work with as well? Because that's the other thing we mentioned before about the maturity of the startup market, et cetera. So we may need to organize ourselves a little bit differently to be able to serve them. So it will be interesting, as you say when we get to the scale, that that's appropriate, which I hope is going to be sooner rather than later. [laughs] So yeah, it's going to be an interesting challenge.

+ +

And I agree with you on the organic thing as well. I think it might be a case where some folks want to actually try out some different types of things. Maybe the newer folks who join us next year may not know what gives them the most fulfillment. But that's also another great thing about thoughtbot generally is that nothing is permanent. [laughs] And if we find a better way to do something, then we'll always twist rather than stick.

+ +

CHAD: I like that saying. That's cool. You're right to call out that a lot of the improvements that I've talked about are from a team perspective and an individual perspective. But a big driver of that was from the client-side, and we see lots of benefits there too. And you called out that we have project managers now. And that's been successful in a way that project management at thoughtbot has never been successful before.

+ +

And part of it is when everything was the same in all of the individual studios, not every project would benefit from a project manager. And if we only have one project and that happens to not be a full-time project for a project manager, it wasn't enough work. But when we can coalesce a team together and a client base together that needs a certain kind of thing consistently, then we're better able to support that which makes our work for the clients better as well. And so that's also been a really good area of improvement for us.

+ +

KIRSTEN: Yeah, I think it's interesting to consider product management in the industry as well. I think it's matured quite significantly whether thoughtbot was doing that or not. I think product management generally is a far more important role than it ever used to be because clients themselves invest in those roles a lot more than they used to.

+ +

CHAD: Yeah, and I think that I realized...I just caught myself in a mistake. Was I saying project management before?

+ +

KIRSTEN: [laughs] I should have corrected you. I wasn't entirely sure if I'd misheard you across the pond here.

+ +

CHAD: [laughs] Okay. That was a mistake.

+ +

KIRSTEN: I think a few of us still make that mistake.

+ +

CHAD: Yes. Actually, that's a really good thing. I caught myself doing it just because they're similar words. But I totally meant product management and not project management. And there are two different things, two distinct things that I think it's important to make that distinction clear. So what is the distinction between those two things, Kirsten?

+ +

KIRSTEN: [laughs] And now it's my turn to tie myself in knots a little bit. It's because product management; I think the first thing you go to is thinking about someone who's responsible for maintaining a product roadmap. And I know that that's a spicy conversation to get into sometimes because you don't want them to be so resolutely set at the outset of a project. But you need someone who's got one eye on the end goal.

+ +

And sometimes, when you've got a team of developers and designers working to some pretty aggressive timelines, and deep in technical problems and solving challenges, that person who helicopters out and looks across everything and retains the broader context of the overall program or the overall client objectives, and can hold the team true to that is really important strategically for the success of a project.

+ +

But I think; actually, you also need to be flexible and listen to the designers and developers when something that was on the roadmap is disproved somehow or is not viable for whatever reason, whether that's because of end-user research or just technically [chuckles] it's too challenging for the budget available to the clients. So then being able to talk with the client as a whole team but lead that discussion and help them understand the recommendations that are being made. I think we've seen that work really well in our team here this year.

+ +

CHAD: And I think an important distinction as well is that some of our clients look to us to make those decisions on their behalf, not all of them but some of them. And that's one of the things that distinguishes a product manager and someone who's making decisions about what the product even is versus a project manager who it's much more about the day-to-day tasks, making sure the backlog is organized, tickets are clear, things are moving along, meetings are scheduled, that kind of thing. And it's much less about the product actually being built.

+ +

KIRSTEN: Absolutely.

+ +

CHAD: Well, I think that brings us at about time. If folks want to get in touch with you, apply to those positions, where are the best places for them to do that?

+ +

KIRSTEN: Well, my email is kirsten@thoughtbot.com. And I am on LinkedIn, Kirsten Hurley, pretty searchable,I think going Kirsten Hurley in thoughtbot. Those are the best ways to get ahold of me.

+ +

CHAD: And I think people can check out all those jobs and apply at thoughtbot.com/jobs. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks, Mandy. And thank you for listening, listener. See you next time.

Special Guest: Kirsten Hurley.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+wkOYPEET + + ]]> + + Chad Pytel + Kirsten Hurley + + + 399: thoughtbot Boost with Joshua Clayton + https://podcast.thoughtbot.com/399 + f24b1c30-40fa-42ea-8b87-ef666406ed15 + Thu, 28 Oct 2021 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Chad interviews Managing Director at thoughtbot, Joshua Clayton, about what a Managing Director at thoughtbot does, what makes Boost at thoughtbot different than other teams, and the belief in integrated teams of designers and developers company-wide. + 39:57 + no + + + Chad interviews Managing Director at thoughtbot, Joshua Clayton, about what a Managing Director at thoughtbot does, what makes Boost at thoughtbot different than other teams, and the belief in integrated teams of designers and developers company-wide. +Empathize with Your Customer by Josh Clayton (https://thoughtbot.com/blog/empathize-with-your-customer) +thoughtbot Boost (https://thoughtbot.com/boost) +Follow thoughtbot on Twitter (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/) +Follow Josh on LinkedIn (https://www.linkedin.com/in/joshuadclayton/) or Twitter (https://twitter.com/joshuaclayton) +Check out Josh's website (https://joshuaclayton.me/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Josh Clayton, Managing Director of the thoughtbot Boost team. Hey, I know that company. Welcome, Josh. +JOSH: Hey, Chad. How are you? +CHAD: All right. I'm back to the show I think. I didn't get a chance to look up the last episode you're in, but it was probably hundreds of episodes ago now. +JOSH: Yeah, it's got to have been a while. +CHAD: [laughs] Speaking of a while, you recently…now time is all messed up for me, but I know that you have been at thoughtbot for a long time. How long has it been? +JOSH: It was 12 years in August. +CHAD: It's been a wonderful 12 years, Josh. +JOSH: I agree. I agree. +CHAD: [laughs] +JOSH: It's been fun. +CHAD: So in that time, you have had a few different roles. But you've been a Managing Director for a while now. +JOSH: Yeah, I think that's...let's see. It was seven and a half years for the Boston team. And then it's 10 and a half months with Boost. +CHAD: So your background is as a developer. And you, like a lot of people who have a background as developers at thoughtbot, myself included, still do development on a fairly regular basis. What does the Managing Director job at thoughtbot actually do? +JOSH: What don't we do [laughter] is maybe a better question. Effectively, we're running that team's business. So it involves some amount of software consulting. It involves software sales. It involves managing the profitability of the team. There are marketing functions, and, I don't know, anything and everything, hiring-related things. We opened up and recently filled our Development Director position, which was open for a couple of months over the summer. We've just opened up a Design Director position. So it's everything. [laughs] It's everything it feels like. +CHAD: At the beginning of this year, we did an episode about the changes that we had made at thoughtbot to reorganize the teams around rather than geographic studios around the types of work that we would do on that team. And that's how the Boost team was created. So in that episode, we gave people an overview. But I'd love to hear in your own words, what makes Boost at thoughtbot different than the other teams, and what do you focus on? +JOSH: So what makes Boost different? I think one of the drivers, one of the motivators, is to embed alongside existing product teams, engineering, and design teams, and help them get better, help them grow as well as ship features and fix bugs. So I think that the way that I position it is if there's an existing product that's deployed, people are using it day in and day out. Hopefully, it's been battle-tested. There are probably some funky areas of the code. Those are the codebases that we're operating in. It might be a team of two people; it might be a team of 200 people. But there is an existing product and an existing team. They're looking for our support to help make it better. +CHAD: One of the things I love about Boost and the changes that we've made, especially relative to Boost, is that at thoughtbot, we really believe in integrated teams of designers and developers. And a big part of what we've always done has been to be a complete product design and development team that brings new products to market, big and small. And because we were one of the first consulting companies in the world to switch to Ruby on Rails and because of that deep experience with Rails, and scaling, and working on existing products, we had a significant number of customers who engaged us for development for that expertise, and to help them scale, and grow, and hire, and implement best practices or solve problems that they were having in their existing codebase or on their existing team. +And even though that was a significant part of our business, it was always something that seemed that we maybe even didn't really want to be doing it, or it was on the periphery of our marketing and positioning. And I was super excited when we officially created this team because it allowed us to acknowledge that this was a significant part of what we do, a significant part of our revenue, and to have a team of people that opted into doing this kind of work who would not only love the kind of work but want to even grow it and do more of it. And we haven't really had that for this kind of work. We've had individuals wanting to do it but not at an organizational level in an organization that supports it. That was more of a statement than a question, but reaction? +JOSH: [laughs] I think you're spot on. It's always been interesting to me to hear that it's...obviously, at thoughtbot, we have been building MVPs and working with a lot of different types of companies over the years and helping them launch products. But I think that the type of work that I and, ideally, obviously, other people on the Boost team enjoy working on is existing platforms and working alongside existing teams. We talk about legacy systems, and I think they get a bad rap. And it's like, no, it's battle-tested. +CHAD: [chuckles] +JOSH: The business has proven its viability. It is still around years later. Conway's law applies in all of the stuff. Again, there are gnarly aspects of the code. But I think that's what the folks on the Boost team enjoy being challenged by is problems where these things are larger systems. They've been around for a while, and they do get pretty gnarly. +CHAD: I think one of the things that held us back in the past is that it is a skill set, and it's an experience. And you are going to be on an MVP project where you're doing design and development, going from concept to launching of a new idea, usually in a matter of weeks, working directly with a founder or a team of co-founders. And then you rotate on to this significantly larger project with maybe an engineering team of tens or dozens or hundreds of other developers on it. It's a very different skill set, and you have very different challenges in that environment. And when you're constantly switching between those different kinds of projects, you can't necessarily get better at it. And that's one of the other things that I think is helping us be more successful. +JOSH: I remember one of the teammates had joined the kick-off call with me at the Boost inception that very first meeting. And it was Joël. And Joël had asked pretty straightforwardly, "What is the expectation in terms of project rotations?" Because I think historically across the company, we'd aimed to do two to four-month engagements before we'd rotate folks. And I told him point-blank it's going to be six months to a year probably. And I don't think it necessarily shocked him or other folks on the team. +But I think when you're going into existing codebases and working alongside existing teams, there is inherently politics at play and complexities at play where it might take you being a new developer on a team six weeks, maybe longer before you actually feel comfortable and confident navigating the codebase and knowing where you can have and make an impact. And so, I think some of the shifts there have been particularly interesting to watch the types of consulting conversations that we have within the team just because it is a different beast, I think than building and launching products. +CHAD: So let's get into a little bit of detail about the kinds of projects we're doing in Boost to the extent that we can give specific examples and maybe more importantly and relevant to the audience, what are the things that we see? What are the common challenges that we see as products grow and evolve, as teams grow and evolve? What do you think one of the most common challenges that people have is? +JOSH: As teams grow and evolve, I think a lot of teams run into onboarding issues and general knowledge sharing. I think when you start a small team, and you're two, three, maybe five engineers, it's pretty easy for everyone to keep probably the entirety or the majority of that domain in their head at any one time. As you work to scale a team...there's a client of ours right now where they're effectively doubling every...I don't know what the time period is, but they're growing very, very rapidly. +And the feedback that some of our team have provided to them is it's really hard, and there are very much knowledge silos. And they're working through, okay? How do we tease this out? How do we share this context so that you don't have a couple of folks that are effectively blocking every single other member of the team? And so that's one of the core areas that hangs up our team and other teams. [chuckles] Our clients bring us on, and a lot of times, it's like we're rip-roaring and ready to go. And it's like, I need information from a bunch of people, and the processes aren't in place such that we can be as effective as we would want to be given the nature of work that we're doing. +CHAD: I think that's a straightforward problem, and it's a good example...I don't want to make this an hour-long thoughtbot commercial. But I'll just point blank say one of the reasons why sometimes working with us is positive for clients is it's really easy to have a certain pain around your onboarding process or company, even just simple things like how long it takes to get a new person a computer or to ramp them up on their existing team. If you're just hiring an employee, it's easy to ignore the cost of that. +JOSH: Yes. +CHAD: But when you're bringing on thoughtbot and we have a specific start date, and it's a certain cost, and those kinds of things, it can really expose the pain that is already happening but was just being ignored and provide the impetus to actually fix the problem. +JOSH: One of the things that we try to set out to do on the first day for any project is to open up a pull request to the codebase, whether it's an improvement to the onboarding like the README for the repository or whatever it might be. Ideally, we are finding ways to contribute on day one. And sometimes, that's frankly not realistic for individual contributors doing it from their own machines. But oftentimes, we'll know that going in. And as we onboard new folks and things like that, we'll say, okay, well, day one is going to be your pair programming over Tuple or some other tool so that you are able to engage and interact with a team and work on the code, even if there's still a bit of a lag between GitHub access and everything else that's the base of onboarding steps. +CHAD: So another common one that people bring us on to help with is scaling challenges in terms of the actual product itself, maybe that's performance or other scaling challenges. I'm working on a project now where that was how we first got involved. The service was failing, and it was only getting worse under the increasing scale. So, what are some tips that you have for how to effectively solve some of those problems while not bringing everything else that you need to accomplish to a screeching halt? +JOSH: At the end of the day, you can't fix something that you don't know is broken. Or you might have a hunch in terms of, oh, I know this page or this set of pages are slow. I think so much of what we see is teams come in, and they're like, "We don't have New Relic setup." We don't have an instrumentation setup. So they can't measure anything. And so it's like, I know this page takes three or four seconds to paint, but I don't know why. And I don't know how to fix it. It's like, okay, well, the first thing that we need to do is set up some amount of performance monitoring and application tracking just to get a sense of what that's like. +There is a potential customer who had reached out back in January of this year. So this was weeks into Boost's inception. And they said, "Listen, we've got some performance-related issues. We don't really know what to do, but we know the application is really, really slow on these couple of pages." It's like, "Are you using New Relic, or Scout, or anything like that?" They're like, "No." It's like, okay, that's the first thing that you need to do. +And they came back about a month ago and were like, okay, "Here's the access to all of this data. Now we're ready to go," and it's like, "Yes!" They probably didn't need to wait for that long. But it really speaks to that in order to address some of the performance-related stuff; we need to have some sense of what is going on and where. +I know Steph over on The Bike Shed Podcast had talked to Nate Berkopec. And she had floated one of the questions I had had. And he basically schooled me on that podcast and reiterated it really is ultimately about measuring so much of what we're doing. +CHAD: Yeah. One of the things, especially for teams that are having a problem but feel like they don't know what to do it's tough when it's actually the case. But the reality is a lot of times; there’s actually very low-hanging fruit that it's just no one has the time or experience to actually identify that. And putting some monitoring in place combined with actually taking the time to look through it, especially if it's the first time you ever hit scaling problems...There's either a missing database in that index or some N+1 queries, and fortunately, once you identify that kind of problem, it's usually fairly quick to fix as well. +It's a different thing when there's maybe fundamental architecture things that are causing your app to have scaling problems. But it's very unlikely that those are the first problems you're ever experiencing. The first problems you're ever going to experience if your app is running slow are going to be things happening at the database level or missing an index or something like that. And it's very unlikely that significant architecture changes need to be put in place in order to fix the first scaling problems that any product usually has. +JOSH: That wasn't the type, or at least I think when we got brought on, and you were working on your most recent clients, we were well beyond...maybe we weren't, maybe I'm misrepresenting or misremembering, but it feels like we were well beyond some of the low hanging fruit. +CHAD: Yeah, there was a batch of low-hanging fruit. One of the things if you're working on a product that is scaling super rapidly, what can happen is that the low-hanging fruit masks the other problems that are happening there because it all happened too quickly, all at the same time. And that was the case on this project. So it went from having hundreds of people using it to millions of people using it in the span of a month. And so there was low-hanging fruit. +But removing the low-hanging fruit didn't make the app suddenly work again; it just made it so that we could look at the metrics and say, "Okay, those things are no longer the problem." The real problems are not being masked now. We now can identify the architectural changes that need to be put into place in order to operate at the scale. +JOSH: Yeah, it's the low-hanging fruit when the orchard is on fire. [laughter] That is true. +CHAD: Right. So you got to peel back like an onion. And this is the case with I think a lot of...whether it be a technical challenge or a team challenge. You can't always come in and very quickly solve the root problem. You might not even know what the root problem is. You just have to start solving the problem that is obvious in front of you and learning more. And then you solve that one, and then you expose the next one, and you expose the next one. +And even when you can identify the root problem, you'll be like, this is the problem, and everyone agrees it's the problem. It still might be too hard to actually fix that problem. It might be an organizational or a systemic problem. And instead, you say, "Okay, we have to iteratively solve that problem." And you start peeling back those layers to get to the point where you've positioned yourself to solve that core problem. And I think we face that a lot, particularly as external consultants. We're coming in, and we can't just be the bull in the china shop. Because we haven't built the trust with everyone necessary to make the changes, or we don't know enough to know what the changes need to be. +JOSH: Right. And I think the people aspect of all of these things in my opinion...and I should caveat this with I've been writing software professionally for almost 20 years. The people, in my opinion, are always the harder aspects to any engagement. It's very rare that we go into a technical project where it's like we literally cannot figure out a technical solution to this thing. We can usually figure it out. And it might take weeks or months to implement, especially as it spans multiple systems. But more often than not, it's really navigating the people and the relationships and building that trust like you had mentioned that is really what will help dictate success within that project. +CHAD: I have a line that I use fairly often, and it's that I really believe very few, if any, developers sit down and are like, I'm going to write a bad solution today, or I'm going to write bad code today. That's not what people are doing. I think the majority of people genuinely try within their entire capacity to do a good job. And so that means that when I'm coming into a situation where there are problems, or things are messy, or there were bad decisions or bad code written, it can't be chalked up to like, oh, that was a bad developer, or that was a bad choice that was made. There was usually some people or organizational problem that caused that to happen in the first place. And merely fixing the bad code is not going to be what we should focus our time on. We probably need to do that. But if we don't fix the reason for that problem in the first place, it's just going to happen again. +A really popular example of this is when we get approached to do a Rails upgrade on a very significant product that is very behind with Rails. First of all, it's very expensive to do that on a very significant project if there's no test coverage. People could hire us to spend and spend a lot of money just getting to the next Rails version. But if they do that and don't solve the reason why they were so behind with Rails and have no test coverage and all that stuff, along the way, it will have been wasted effort because in a year or in two years, it will be back to the way that it was before. And that's one example that's very technical. But that kind of stuff happens all the time, even with squishy things [laughs] like the structure of a team or something like that. +So if you could give advice to people that are struggling with a particular problem, what would you tell them? And let's maybe make it a little bit more concrete. Like, one thing that can happen is as teams grow, like you said, not everyone can know everything. And so it starts breaking down into pods; maybe is one way to organize the team. And then you've gone into a bunch of individual teams working on discrete features. And that's happening fairly quickly. What are some ways to manage that change and manage that growth while maintaining continuity and making it go well? +JOSH: I think a lot of it depends on the goals from the technical leadership in terms of areas of ownership. That'd be the first part that I would dive into, I think. We work with clients where they segregate front-end from back-end development. And that allows the teams to focus on React and TypeScript versus Ruby or Go or whatever their back end is written in. +But if the goal is to share that knowledge, I think you've got options in terms of lunch and learn and shared code review and team demos and things like that. There are other ways to spread that information across the team so that everybody still has maybe not intimate knowledge of the code that's being written on a day to day basis, but they're at least aware of those patterns and practices and what each of the individual pods is may be responsible for and is delivering. So you have that team cohesion across more of the functional space, on the engineering side or on the product design side. +CHAD: One thing that I think I would also add is that a lot of times, people take for granted how better developers will do their job if they understand the reason or the business drivers behind what they're working on. And it's really easy for people to take that for granted because it's like, there's a ticket to the ticket. It says what to do on the ticket. [laughs] +JOSH: I have a blog post about this, actually. +CHAD: [laughs] Okay, great. We'll put that in the show notes. But if someone doesn't understand the reason behind that, it's not going to go the way that you're expecting frequently. It's not as straightforward. +JOSH: Yeah. You're left guessing what the underlying customer need is. And if you're guessing about the motivations, I don't want to say not in absolutes, but you're likely not going to address all of those core needs and implement an effective solution. +I think in the blog post that I had written, ultimately, it was advocating for getting engineers to participate in customer interviews and really understand, like, how are people using the product that I am implementing features for? Because without that exposure, without seeing those pain points, oftentimes, it's okay, you've got a product designer or a product manager who's putting together this list of things to do. And if it's treated as a checklist or oh, I need to go implement XYZ without understanding why that needs to be done in the first place, what is the pain point? What is the customer-facing? How are they feeling as they're going through the product? Without that context and without that empathy, the solution is going to be...it might functionally work. But will it be a good user experience? Will it be a good customer experience? It's a little bit more shaky, I think. +CHAD: Yeah. And in a fast-moving, fast-growing startup where everyone has a lot to do, if you're experiencing this kind of problem, it might manifest to you as stories get caught up at the beginning stages of when a developer is supposed to be working on them. And you find yourself having calls about what something is even supposed to be or supposed to do. And as the person who originated that ticket or originated that idea, you might have the feeling like, I can't believe we're having this conversation. Like, we don't have time to educate you about all the reasons why this is important and just please just do what we've said on the ticket. That is a natural reaction to that thing. +And so my advice would be if you're feeling that, if your team is feeling that or something similar, there's probably something small you can do. It might not even be having developers participate in discovery or interviews or anything. It might be as simple as just making sure that on the ticket you say why it's important. If your ticket is a checklist of things to change or do, making sure that the reason why is communicated there will go a long way to having the person pick up that ticket, get the context necessary to understand, and make good decisions as they work on it. +JOSH: Yeah, I remember the switch to the jobs to be done format. And I remember just being like, oh, [laughs] this makes a lot more sense because we can understand the context and the why. What is driving it? What is the problem there rather than what is the solution? And I think that shift in mindset does go a long way, like you said. +CHAD: I think one of the ideas behind a well-functioning team is we talk about this idea of collaboration which is you feel like you're doing your best work, that things are moving quickly, and you're enjoying the people you're working with, and you're building upon each other's ideas, and you're making things better as a team. +And I was recently talking to someone else, a candidate for VP of Engineering at one of our clients, and they were talking about flow, the idea of flow. And it wasn't a way that I had articulated it previously, but it's certainly another way of thinking about and a good way of thinking about it, especially when it comes to what is the role of a VP of engineering? Or what is the role of a CTO at a small company? Or what is the role of a development team or a product team in general? And one way to think about that is to work to maintain a flow state. +And when we think about the processes that we have in terms of retrospectives where every week we gather, and we identify things that could be better, and we come up with action items, a lot of the things that drive what could be better or what we want to try to do differently are all identifying the things that take us out of the flow state and trying to fix that problem so that items flow from beginning to end smoothly, that they go from concept to production smoothly as quickly as possible, and that individual people know where the next item to take is that it's ready so they're not blocked as they begin it. And they're able to get that to staging, and get a pull request out, and get that reviewed quickly, get it to staging, get that reviewed quickly, and then deploy it to production. And in theory, even do a continuous deployment so that that whole flow is automated as much as possible. So this idea of flow resonated with me. Has it resonated with you? +JOSH: Yeah, I agree. I remember seeing the comparisons people saying, okay, you're not actually looking for an engineer's passion necessarily. What you're looking for...and I come back to the hiring side of things because I'm doing that right now. But rather than looking to assess passion, it's assessing capacity and ability to get into a flow state more quickly. And obviously, so much of that is dependent on the team, and the communication style, the management style, and things like that. +But flow is very much...I think once you get into that and you know how to get into that like you said, every waking moment is spent trying to optimize how do I get into this space? Because when you're in that space, when you're flowing, be it from an IC level or above, there's nothing quite like it. It's just this calm state of just everything feels like it's firing all the time perfectly, and it's good. And I think trying to make those spaces available for the rest of the team to get into that state and maintain that state makes a lot of sense. +I remember years and years and years ago, there was the focus on maker versus manager time. And we talk about anchoring manager time either at the start of the end day or around lunchtime or whatever is a logical time for a break. The idea is to maintain that flow state for as long as possible so that nothing else eats into that. Because you do an hour of writing software, and then you've got a 30-minute one-on-one with a teammate. And then you go, and you run for another hour, hour and a half, and then it's another half an hour meeting. It's like you're being sucked away. It is really hard to get into that zone and then stay there. So I think there's been a focus on it for a while. And I'm really glad that there's now a name and a thing that we can point to. +CHAD: I don't want to lead people astray about what Boost is. There's a big important part of Boost, which may not be immediately obvious to people, and that is design. I may have insinuated that design wasn't part of Boost before when we were talking about it, but it is. And it's designed on existing products and existing teams which is a different need than going from concept to launch of a new idea. +JOSH: So we had done some work with The New England Journal of Medicine. And their team, a very small team, internal team, had basically designed an application. And they ran into a number of accessibility and usability issues. They continued to hear feedback from a lot of folks saying, "This is not effective for what we're looking to do." And they'd engaged us in a couple of different times basically to rip apart and re-architect some of the application hierarchy and the usability side of things. +It's been really interesting to see okay, well, within the design side of operating within existing products, it's often lended or leaned more towards doing some amount of a design audit and usability audit, talking to customers. And less around we're going to start from scratch and more what are some of these iterative improvements that we can make to make the product more accessible, easier to understand, easier to navigate, easier to use within what is, again, these very large platforms sometimes? +CHAD: I know one common request we get is we're thinking about implementing a design system or introducing a design system with the first version of the product. And we're having this growing pain around introducing new features. Is a design system the right thing to do there? That's a request we sometimes get. +JOSH: Yeah. And I think a lot of it at the end of the day, what we're looking to assess is what are the knowns? How much do we know about the application, about the interface? We talk about on the software development side of things avoiding premature abstraction, and I think the same thing is true about design systems. Like, if we're going through a product, maybe it's a wizard, and apart from forms, the pages are individualized, and there's not really any common patterns. It's like, okay, well, maybe now it doesn't make sense. But when you've got an application that spans hundreds of pages, there are going to be patterns across the different pages in terms of application hierarchy and componentization and things like that. +And the work that we're oftentimes brought in to do is let's assess what's there, figure out what are the common patterns here. And it's almost like refactoring and teasing things apart to where we get slight...it's a reduction in code use or rather an increase in code reuse because we're removing some of the idiosyncrasies that maybe were not teased apart into some component-based system. And that's fun work. [chuckles] It's really interesting. +You get things like React when you're doing client-side rendering. And within the Rails side of things, there's a big push for the GitHub ViewComponent. RubyGem is another example. It's both ways to introduce these layers of abstraction that allow more of the engineering team to take on more of the application development, not because design isn't necessary, but they're then empowered to reuse these logical set of components. And so it amplifies the dev work, but it also amplifies the design work because the entire team is now leaning on that pre-baked work. It enables designers to shift focus and priorities to okay; what are new components? What are different ways to position this or present this information? And also, for our designers, it frees up their time to talk even more to customers, to people using the system. +CHAD: Well, I guess we'd be remiss if we didn't do a more blatant plug. You mentioned it earlier, but we do have an opening for Design Director on the Boost team. +JOSH: We do. +CHAD: So who would be a good fit for that role? +JOSH: That's a great question. I think a couple of the things that we're really focusing on for this role is someone who has done the work, so to speak, at an IC level for a lot of the work that we're doing right now with customers. And so we ask point-blank on the application sheet, have you worked in HTML and CSS? Have you facilitated design exercises like design sprints? Have you facilitated user interviews? Because so much of what we're seeing from a vision and a strategy perspective is we need to take and leverage these tools in the skill sets that our teams are looking to hone in on, and we want to take it a lot further. I think there's a big opportunity there. +So I think it's less around years of experience. I wouldn't say you need to have 15 years of management experience or having been a director in order to apply for the role. But it's someone that can empathize with the team and has some opinions and some thoughts in terms of okay, what is design? What is not only visual design but product design accessibility? What does that look like in the next 5 to 10 years? Those are the people that I would love to see apply. +CHAD: If someone's interested, where's the best place for them to do that? +JOSH: thoughtbot.com/jobs. And the listing is there. +CHAD: So what's next for Boost, Josh? What do you have your sights set on as we wrap up 2021 and head into the next year? +JOSH: Oh boy. A lot of where the focus has been on this year is continuing to double down on Rails as the technology stack and get our feet wet, not that our feet aren't wet, [chuckles] continue to invest on the front end with React. I think for 2022, I think the big focus...we've run in the past some pretty successful custom trainings workshops for engineering teams. I think one that we had done earlier was late last year into early this year. We ran about 120 or so of their engineers through a custom RSpec course. +So we worked with their engineering managers and some of their teams and got a sense of okay; given this codebase and given the skill sets of this 100-plus person engineering team, where should we focus? And we put together a two-day RSpec workshop. We administered over; I think, five or six weeks. We did it virtually. And the reception from that was incredible. They ended up bringing us back on. We're getting ready to start another round of consulting work where we're embedding alongside their teams. So I see that as a huge opportunity for Boost coming into next year. +And then I think one of the things that we've been pushing for is reducing some of the billing time from folks in leadership positions so that they're in a better position to support their designers and developers. And I'm really excited about the progress that we've made thus far. And I'm excited to continue carrying that into next year. +CHAD: Awesome. Well, thanks for taking the time to talk to me. +JOSH: Thank you. +CHAD: Part of this new season, Season 11 of the podcast, for the next few episodes, I'm going to be talking to each of the managing directors at thoughtbot about their teams, about the different kinds of work we do on those teams, and the challenges, and what phases are clients in those different stages of the product lifecycle. +So you can subscribe to the show and find notes for this episode and all the other episodes at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Josh, if folks want to get in touch with you or follow along with you, what are the best places for them to do that? +JOSH: Definitely Twitter. My handle is @joshuaclayton, all one word. +CHAD: Awesome. Thanks again. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Special Guest: Joshua Clayton. + + + Chad interviews Managing Director at thoughtbot, Joshua Clayton, about what a Managing Director at thoughtbot does, what makes Boost at thoughtbot different than other teams, and the belief in integrated teams of designers and developers company-wide.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Josh Clayton, Managing Director of the thoughtbot Boost team. Hey, I know that company. Welcome, Josh.

+ +

JOSH: Hey, Chad. How are you?

+ +

CHAD: All right. I'm back to the show I think. I didn't get a chance to look up the last episode you're in, but it was probably hundreds of episodes ago now.

+ +

JOSH: Yeah, it's got to have been a while.

+ +

CHAD: [laughs] Speaking of a while, you recently…now time is all messed up for me, but I know that you have been at thoughtbot for a long time. How long has it been?

+ +

JOSH: It was 12 years in August.

+ +

CHAD: It's been a wonderful 12 years, Josh.

+ +

JOSH: I agree. I agree.

+ +

CHAD: [laughs]

+ +

JOSH: It's been fun.

+ +

CHAD: So in that time, you have had a few different roles. But you've been a Managing Director for a while now.

+ +

JOSH: Yeah, I think that's...let's see. It was seven and a half years for the Boston team. And then it's 10 and a half months with Boost.

+ +

CHAD: So your background is as a developer. And you, like a lot of people who have a background as developers at thoughtbot, myself included, still do development on a fairly regular basis. What does the Managing Director job at thoughtbot actually do?

+ +

JOSH: What don't we do [laughter] is maybe a better question. Effectively, we're running that team's business. So it involves some amount of software consulting. It involves software sales. It involves managing the profitability of the team. There are marketing functions, and, I don't know, anything and everything, hiring-related things. We opened up and recently filled our Development Director position, which was open for a couple of months over the summer. We've just opened up a Design Director position. So it's everything. [laughs] It's everything it feels like.

+ +

CHAD: At the beginning of this year, we did an episode about the changes that we had made at thoughtbot to reorganize the teams around rather than geographic studios around the types of work that we would do on that team. And that's how the Boost team was created. So in that episode, we gave people an overview. But I'd love to hear in your own words, what makes Boost at thoughtbot different than the other teams, and what do you focus on?

+ +

JOSH: So what makes Boost different? I think one of the drivers, one of the motivators, is to embed alongside existing product teams, engineering, and design teams, and help them get better, help them grow as well as ship features and fix bugs. So I think that the way that I position it is if there's an existing product that's deployed, people are using it day in and day out. Hopefully, it's been battle-tested. There are probably some funky areas of the code. Those are the codebases that we're operating in. It might be a team of two people; it might be a team of 200 people. But there is an existing product and an existing team. They're looking for our support to help make it better.

+ +

CHAD: One of the things I love about Boost and the changes that we've made, especially relative to Boost, is that at thoughtbot, we really believe in integrated teams of designers and developers. And a big part of what we've always done has been to be a complete product design and development team that brings new products to market, big and small. And because we were one of the first consulting companies in the world to switch to Ruby on Rails and because of that deep experience with Rails, and scaling, and working on existing products, we had a significant number of customers who engaged us for development for that expertise, and to help them scale, and grow, and hire, and implement best practices or solve problems that they were having in their existing codebase or on their existing team.

+ +

And even though that was a significant part of our business, it was always something that seemed that we maybe even didn't really want to be doing it, or it was on the periphery of our marketing and positioning. And I was super excited when we officially created this team because it allowed us to acknowledge that this was a significant part of what we do, a significant part of our revenue, and to have a team of people that opted into doing this kind of work who would not only love the kind of work but want to even grow it and do more of it. And we haven't really had that for this kind of work. We've had individuals wanting to do it but not at an organizational level in an organization that supports it. That was more of a statement than a question, but reaction?

+ +

JOSH: [laughs] I think you're spot on. It's always been interesting to me to hear that it's...obviously, at thoughtbot, we have been building MVPs and working with a lot of different types of companies over the years and helping them launch products. But I think that the type of work that I and, ideally, obviously, other people on the Boost team enjoy working on is existing platforms and working alongside existing teams. We talk about legacy systems, and I think they get a bad rap. And it's like, no, it's battle-tested.

+ +

CHAD: [chuckles]

+ +

JOSH: The business has proven its viability. It is still around years later. Conway's law applies in all of the stuff. Again, there are gnarly aspects of the code. But I think that's what the folks on the Boost team enjoy being challenged by is problems where these things are larger systems. They've been around for a while, and they do get pretty gnarly.

+ +

CHAD: I think one of the things that held us back in the past is that it is a skill set, and it's an experience. And you are going to be on an MVP project where you're doing design and development, going from concept to launching of a new idea, usually in a matter of weeks, working directly with a founder or a team of co-founders. And then you rotate on to this significantly larger project with maybe an engineering team of tens or dozens or hundreds of other developers on it. It's a very different skill set, and you have very different challenges in that environment. And when you're constantly switching between those different kinds of projects, you can't necessarily get better at it. And that's one of the other things that I think is helping us be more successful.

+ +

JOSH: I remember one of the teammates had joined the kick-off call with me at the Boost inception that very first meeting. And it was Joël. And Joël had asked pretty straightforwardly, "What is the expectation in terms of project rotations?" Because I think historically across the company, we'd aimed to do two to four-month engagements before we'd rotate folks. And I told him point-blank it's going to be six months to a year probably. And I don't think it necessarily shocked him or other folks on the team.

+ +

But I think when you're going into existing codebases and working alongside existing teams, there is inherently politics at play and complexities at play where it might take you being a new developer on a team six weeks, maybe longer before you actually feel comfortable and confident navigating the codebase and knowing where you can have and make an impact. And so, I think some of the shifts there have been particularly interesting to watch the types of consulting conversations that we have within the team just because it is a different beast, I think than building and launching products.

+ +

CHAD: So let's get into a little bit of detail about the kinds of projects we're doing in Boost to the extent that we can give specific examples and maybe more importantly and relevant to the audience, what are the things that we see? What are the common challenges that we see as products grow and evolve, as teams grow and evolve? What do you think one of the most common challenges that people have is?

+ +

JOSH: As teams grow and evolve, I think a lot of teams run into onboarding issues and general knowledge sharing. I think when you start a small team, and you're two, three, maybe five engineers, it's pretty easy for everyone to keep probably the entirety or the majority of that domain in their head at any one time. As you work to scale a team...there's a client of ours right now where they're effectively doubling every...I don't know what the time period is, but they're growing very, very rapidly.

+ +

And the feedback that some of our team have provided to them is it's really hard, and there are very much knowledge silos. And they're working through, okay? How do we tease this out? How do we share this context so that you don't have a couple of folks that are effectively blocking every single other member of the team? And so that's one of the core areas that hangs up our team and other teams. [chuckles] Our clients bring us on, and a lot of times, it's like we're rip-roaring and ready to go. And it's like, I need information from a bunch of people, and the processes aren't in place such that we can be as effective as we would want to be given the nature of work that we're doing.

+ +

CHAD: I think that's a straightforward problem, and it's a good example...I don't want to make this an hour-long thoughtbot commercial. But I'll just point blank say one of the reasons why sometimes working with us is positive for clients is it's really easy to have a certain pain around your onboarding process or company, even just simple things like how long it takes to get a new person a computer or to ramp them up on their existing team. If you're just hiring an employee, it's easy to ignore the cost of that.

+ +

JOSH: Yes.

+ +

CHAD: But when you're bringing on thoughtbot and we have a specific start date, and it's a certain cost, and those kinds of things, it can really expose the pain that is already happening but was just being ignored and provide the impetus to actually fix the problem.

+ +

JOSH: One of the things that we try to set out to do on the first day for any project is to open up a pull request to the codebase, whether it's an improvement to the onboarding like the README for the repository or whatever it might be. Ideally, we are finding ways to contribute on day one. And sometimes, that's frankly not realistic for individual contributors doing it from their own machines. But oftentimes, we'll know that going in. And as we onboard new folks and things like that, we'll say, okay, well, day one is going to be your pair programming over Tuple or some other tool so that you are able to engage and interact with a team and work on the code, even if there's still a bit of a lag between GitHub access and everything else that's the base of onboarding steps.

+ +

CHAD: So another common one that people bring us on to help with is scaling challenges in terms of the actual product itself, maybe that's performance or other scaling challenges. I'm working on a project now where that was how we first got involved. The service was failing, and it was only getting worse under the increasing scale. So, what are some tips that you have for how to effectively solve some of those problems while not bringing everything else that you need to accomplish to a screeching halt?

+ +

JOSH: At the end of the day, you can't fix something that you don't know is broken. Or you might have a hunch in terms of, oh, I know this page or this set of pages are slow. I think so much of what we see is teams come in, and they're like, "We don't have New Relic setup." We don't have an instrumentation setup. So they can't measure anything. And so it's like, I know this page takes three or four seconds to paint, but I don't know why. And I don't know how to fix it. It's like, okay, well, the first thing that we need to do is set up some amount of performance monitoring and application tracking just to get a sense of what that's like.

+ +

There is a potential customer who had reached out back in January of this year. So this was weeks into Boost's inception. And they said, "Listen, we've got some performance-related issues. We don't really know what to do, but we know the application is really, really slow on these couple of pages." It's like, "Are you using New Relic, or Scout, or anything like that?" They're like, "No." It's like, okay, that's the first thing that you need to do.

+ +

And they came back about a month ago and were like, okay, "Here's the access to all of this data. Now we're ready to go," and it's like, "Yes!" They probably didn't need to wait for that long. But it really speaks to that in order to address some of the performance-related stuff; we need to have some sense of what is going on and where.

+ +

I know Steph over on The Bike Shed Podcast had talked to Nate Berkopec. And she had floated one of the questions I had had. And he basically schooled me on that podcast and reiterated it really is ultimately about measuring so much of what we're doing.

+ +

CHAD: Yeah. One of the things, especially for teams that are having a problem but feel like they don't know what to do it's tough when it's actually the case. But the reality is a lot of times; there’s actually very low-hanging fruit that it's just no one has the time or experience to actually identify that. And putting some monitoring in place combined with actually taking the time to look through it, especially if it's the first time you ever hit scaling problems...There's either a missing database in that index or some N+1 queries, and fortunately, once you identify that kind of problem, it's usually fairly quick to fix as well.

+ +

It's a different thing when there's maybe fundamental architecture things that are causing your app to have scaling problems. But it's very unlikely that those are the first problems you're ever experiencing. The first problems you're ever going to experience if your app is running slow are going to be things happening at the database level or missing an index or something like that. And it's very unlikely that significant architecture changes need to be put in place in order to fix the first scaling problems that any product usually has.

+ +

JOSH: That wasn't the type, or at least I think when we got brought on, and you were working on your most recent clients, we were well beyond...maybe we weren't, maybe I'm misrepresenting or misremembering, but it feels like we were well beyond some of the low hanging fruit.

+ +

CHAD: Yeah, there was a batch of low-hanging fruit. One of the things if you're working on a product that is scaling super rapidly, what can happen is that the low-hanging fruit masks the other problems that are happening there because it all happened too quickly, all at the same time. And that was the case on this project. So it went from having hundreds of people using it to millions of people using it in the span of a month. And so there was low-hanging fruit.

+ +

But removing the low-hanging fruit didn't make the app suddenly work again; it just made it so that we could look at the metrics and say, "Okay, those things are no longer the problem." The real problems are not being masked now. We now can identify the architectural changes that need to be put into place in order to operate at the scale.

+ +

JOSH: Yeah, it's the low-hanging fruit when the orchard is on fire. [laughter] That is true.

+ +

CHAD: Right. So you got to peel back like an onion. And this is the case with I think a lot of...whether it be a technical challenge or a team challenge. You can't always come in and very quickly solve the root problem. You might not even know what the root problem is. You just have to start solving the problem that is obvious in front of you and learning more. And then you solve that one, and then you expose the next one, and you expose the next one.

+ +

And even when you can identify the root problem, you'll be like, this is the problem, and everyone agrees it's the problem. It still might be too hard to actually fix that problem. It might be an organizational or a systemic problem. And instead, you say, "Okay, we have to iteratively solve that problem." And you start peeling back those layers to get to the point where you've positioned yourself to solve that core problem. And I think we face that a lot, particularly as external consultants. We're coming in, and we can't just be the bull in the china shop. Because we haven't built the trust with everyone necessary to make the changes, or we don't know enough to know what the changes need to be.

+ +

JOSH: Right. And I think the people aspect of all of these things in my opinion...and I should caveat this with I've been writing software professionally for almost 20 years. The people, in my opinion, are always the harder aspects to any engagement. It's very rare that we go into a technical project where it's like we literally cannot figure out a technical solution to this thing. We can usually figure it out. And it might take weeks or months to implement, especially as it spans multiple systems. But more often than not, it's really navigating the people and the relationships and building that trust like you had mentioned that is really what will help dictate success within that project.

+ +

CHAD: I have a line that I use fairly often, and it's that I really believe very few, if any, developers sit down and are like, I'm going to write a bad solution today, or I'm going to write bad code today. That's not what people are doing. I think the majority of people genuinely try within their entire capacity to do a good job. And so that means that when I'm coming into a situation where there are problems, or things are messy, or there were bad decisions or bad code written, it can't be chalked up to like, oh, that was a bad developer, or that was a bad choice that was made. There was usually some people or organizational problem that caused that to happen in the first place. And merely fixing the bad code is not going to be what we should focus our time on. We probably need to do that. But if we don't fix the reason for that problem in the first place, it's just going to happen again.

+ +

A really popular example of this is when we get approached to do a Rails upgrade on a very significant product that is very behind with Rails. First of all, it's very expensive to do that on a very significant project if there's no test coverage. People could hire us to spend and spend a lot of money just getting to the next Rails version. But if they do that and don't solve the reason why they were so behind with Rails and have no test coverage and all that stuff, along the way, it will have been wasted effort because in a year or in two years, it will be back to the way that it was before. And that's one example that's very technical. But that kind of stuff happens all the time, even with squishy things [laughs] like the structure of a team or something like that.

+ +

So if you could give advice to people that are struggling with a particular problem, what would you tell them? And let's maybe make it a little bit more concrete. Like, one thing that can happen is as teams grow, like you said, not everyone can know everything. And so it starts breaking down into pods; maybe is one way to organize the team. And then you've gone into a bunch of individual teams working on discrete features. And that's happening fairly quickly. What are some ways to manage that change and manage that growth while maintaining continuity and making it go well?

+ +

JOSH: I think a lot of it depends on the goals from the technical leadership in terms of areas of ownership. That'd be the first part that I would dive into, I think. We work with clients where they segregate front-end from back-end development. And that allows the teams to focus on React and TypeScript versus Ruby or Go or whatever their back end is written in.

+ +

But if the goal is to share that knowledge, I think you've got options in terms of lunch and learn and shared code review and team demos and things like that. There are other ways to spread that information across the team so that everybody still has maybe not intimate knowledge of the code that's being written on a day to day basis, but they're at least aware of those patterns and practices and what each of the individual pods is may be responsible for and is delivering. So you have that team cohesion across more of the functional space, on the engineering side or on the product design side.

+ +

CHAD: One thing that I think I would also add is that a lot of times, people take for granted how better developers will do their job if they understand the reason or the business drivers behind what they're working on. And it's really easy for people to take that for granted because it's like, there's a ticket to the ticket. It says what to do on the ticket. [laughs]

+ +

JOSH: I have a blog post about this, actually.

+ +

CHAD: [laughs] Okay, great. We'll put that in the show notes. But if someone doesn't understand the reason behind that, it's not going to go the way that you're expecting frequently. It's not as straightforward.

+ +

JOSH: Yeah. You're left guessing what the underlying customer need is. And if you're guessing about the motivations, I don't want to say not in absolutes, but you're likely not going to address all of those core needs and implement an effective solution.

+ +

I think in the blog post that I had written, ultimately, it was advocating for getting engineers to participate in customer interviews and really understand, like, how are people using the product that I am implementing features for? Because without that exposure, without seeing those pain points, oftentimes, it's okay, you've got a product designer or a product manager who's putting together this list of things to do. And if it's treated as a checklist or oh, I need to go implement XYZ without understanding why that needs to be done in the first place, what is the pain point? What is the customer-facing? How are they feeling as they're going through the product? Without that context and without that empathy, the solution is going to be...it might functionally work. But will it be a good user experience? Will it be a good customer experience? It's a little bit more shaky, I think.

+ +

CHAD: Yeah. And in a fast-moving, fast-growing startup where everyone has a lot to do, if you're experiencing this kind of problem, it might manifest to you as stories get caught up at the beginning stages of when a developer is supposed to be working on them. And you find yourself having calls about what something is even supposed to be or supposed to do. And as the person who originated that ticket or originated that idea, you might have the feeling like, I can't believe we're having this conversation. Like, we don't have time to educate you about all the reasons why this is important and just please just do what we've said on the ticket. That is a natural reaction to that thing.

+ +

And so my advice would be if you're feeling that, if your team is feeling that or something similar, there's probably something small you can do. It might not even be having developers participate in discovery or interviews or anything. It might be as simple as just making sure that on the ticket you say why it's important. If your ticket is a checklist of things to change or do, making sure that the reason why is communicated there will go a long way to having the person pick up that ticket, get the context necessary to understand, and make good decisions as they work on it.

+ +

JOSH: Yeah, I remember the switch to the jobs to be done format. And I remember just being like, oh, [laughs] this makes a lot more sense because we can understand the context and the why. What is driving it? What is the problem there rather than what is the solution? And I think that shift in mindset does go a long way, like you said.

+ +

CHAD: I think one of the ideas behind a well-functioning team is we talk about this idea of collaboration which is you feel like you're doing your best work, that things are moving quickly, and you're enjoying the people you're working with, and you're building upon each other's ideas, and you're making things better as a team.

+ +

And I was recently talking to someone else, a candidate for VP of Engineering at one of our clients, and they were talking about flow, the idea of flow. And it wasn't a way that I had articulated it previously, but it's certainly another way of thinking about and a good way of thinking about it, especially when it comes to what is the role of a VP of engineering? Or what is the role of a CTO at a small company? Or what is the role of a development team or a product team in general? And one way to think about that is to work to maintain a flow state.

+ +

And when we think about the processes that we have in terms of retrospectives where every week we gather, and we identify things that could be better, and we come up with action items, a lot of the things that drive what could be better or what we want to try to do differently are all identifying the things that take us out of the flow state and trying to fix that problem so that items flow from beginning to end smoothly, that they go from concept to production smoothly as quickly as possible, and that individual people know where the next item to take is that it's ready so they're not blocked as they begin it. And they're able to get that to staging, and get a pull request out, and get that reviewed quickly, get it to staging, get that reviewed quickly, and then deploy it to production. And in theory, even do a continuous deployment so that that whole flow is automated as much as possible. So this idea of flow resonated with me. Has it resonated with you?

+ +

JOSH: Yeah, I agree. I remember seeing the comparisons people saying, okay, you're not actually looking for an engineer's passion necessarily. What you're looking for...and I come back to the hiring side of things because I'm doing that right now. But rather than looking to assess passion, it's assessing capacity and ability to get into a flow state more quickly. And obviously, so much of that is dependent on the team, and the communication style, the management style, and things like that.

+ +

But flow is very much...I think once you get into that and you know how to get into that like you said, every waking moment is spent trying to optimize how do I get into this space? Because when you're in that space, when you're flowing, be it from an IC level or above, there's nothing quite like it. It's just this calm state of just everything feels like it's firing all the time perfectly, and it's good. And I think trying to make those spaces available for the rest of the team to get into that state and maintain that state makes a lot of sense.

+ +

I remember years and years and years ago, there was the focus on maker versus manager time. And we talk about anchoring manager time either at the start of the end day or around lunchtime or whatever is a logical time for a break. The idea is to maintain that flow state for as long as possible so that nothing else eats into that. Because you do an hour of writing software, and then you've got a 30-minute one-on-one with a teammate. And then you go, and you run for another hour, hour and a half, and then it's another half an hour meeting. It's like you're being sucked away. It is really hard to get into that zone and then stay there. So I think there's been a focus on it for a while. And I'm really glad that there's now a name and a thing that we can point to.

+ +

CHAD: I don't want to lead people astray about what Boost is. There's a big important part of Boost, which may not be immediately obvious to people, and that is design. I may have insinuated that design wasn't part of Boost before when we were talking about it, but it is. And it's designed on existing products and existing teams which is a different need than going from concept to launch of a new idea.

+ +

JOSH: So we had done some work with The New England Journal of Medicine. And their team, a very small team, internal team, had basically designed an application. And they ran into a number of accessibility and usability issues. They continued to hear feedback from a lot of folks saying, "This is not effective for what we're looking to do." And they'd engaged us in a couple of different times basically to rip apart and re-architect some of the application hierarchy and the usability side of things.

+ +

It's been really interesting to see okay, well, within the design side of operating within existing products, it's often lended or leaned more towards doing some amount of a design audit and usability audit, talking to customers. And less around we're going to start from scratch and more what are some of these iterative improvements that we can make to make the product more accessible, easier to understand, easier to navigate, easier to use within what is, again, these very large platforms sometimes?

+ +

CHAD: I know one common request we get is we're thinking about implementing a design system or introducing a design system with the first version of the product. And we're having this growing pain around introducing new features. Is a design system the right thing to do there? That's a request we sometimes get.

+ +

JOSH: Yeah. And I think a lot of it at the end of the day, what we're looking to assess is what are the knowns? How much do we know about the application, about the interface? We talk about on the software development side of things avoiding premature abstraction, and I think the same thing is true about design systems. Like, if we're going through a product, maybe it's a wizard, and apart from forms, the pages are individualized, and there's not really any common patterns. It's like, okay, well, maybe now it doesn't make sense. But when you've got an application that spans hundreds of pages, there are going to be patterns across the different pages in terms of application hierarchy and componentization and things like that.

+ +

And the work that we're oftentimes brought in to do is let's assess what's there, figure out what are the common patterns here. And it's almost like refactoring and teasing things apart to where we get slight...it's a reduction in code use or rather an increase in code reuse because we're removing some of the idiosyncrasies that maybe were not teased apart into some component-based system. And that's fun work. [chuckles] It's really interesting.

+ +

You get things like React when you're doing client-side rendering. And within the Rails side of things, there's a big push for the GitHub ViewComponent. RubyGem is another example. It's both ways to introduce these layers of abstraction that allow more of the engineering team to take on more of the application development, not because design isn't necessary, but they're then empowered to reuse these logical set of components. And so it amplifies the dev work, but it also amplifies the design work because the entire team is now leaning on that pre-baked work. It enables designers to shift focus and priorities to okay; what are new components? What are different ways to position this or present this information? And also, for our designers, it frees up their time to talk even more to customers, to people using the system.

+ +

CHAD: Well, I guess we'd be remiss if we didn't do a more blatant plug. You mentioned it earlier, but we do have an opening for Design Director on the Boost team.

+ +

JOSH: We do.

+ +

CHAD: So who would be a good fit for that role?

+ +

JOSH: That's a great question. I think a couple of the things that we're really focusing on for this role is someone who has done the work, so to speak, at an IC level for a lot of the work that we're doing right now with customers. And so we ask point-blank on the application sheet, have you worked in HTML and CSS? Have you facilitated design exercises like design sprints? Have you facilitated user interviews? Because so much of what we're seeing from a vision and a strategy perspective is we need to take and leverage these tools in the skill sets that our teams are looking to hone in on, and we want to take it a lot further. I think there's a big opportunity there.

+ +

So I think it's less around years of experience. I wouldn't say you need to have 15 years of management experience or having been a director in order to apply for the role. But it's someone that can empathize with the team and has some opinions and some thoughts in terms of okay, what is design? What is not only visual design but product design accessibility? What does that look like in the next 5 to 10 years? Those are the people that I would love to see apply.

+ +

CHAD: If someone's interested, where's the best place for them to do that?

+ +

JOSH: thoughtbot.com/jobs. And the listing is there.

+ +

CHAD: So what's next for Boost, Josh? What do you have your sights set on as we wrap up 2021 and head into the next year?

+ +

JOSH: Oh boy. A lot of where the focus has been on this year is continuing to double down on Rails as the technology stack and get our feet wet, not that our feet aren't wet, [chuckles] continue to invest on the front end with React. I think for 2022, I think the big focus...we've run in the past some pretty successful custom trainings workshops for engineering teams. I think one that we had done earlier was late last year into early this year. We ran about 120 or so of their engineers through a custom RSpec course.

+ +

So we worked with their engineering managers and some of their teams and got a sense of okay; given this codebase and given the skill sets of this 100-plus person engineering team, where should we focus? And we put together a two-day RSpec workshop. We administered over; I think, five or six weeks. We did it virtually. And the reception from that was incredible. They ended up bringing us back on. We're getting ready to start another round of consulting work where we're embedding alongside their teams. So I see that as a huge opportunity for Boost coming into next year.

+ +

And then I think one of the things that we've been pushing for is reducing some of the billing time from folks in leadership positions so that they're in a better position to support their designers and developers. And I'm really excited about the progress that we've made thus far. And I'm excited to continue carrying that into next year.

+ +

CHAD: Awesome. Well, thanks for taking the time to talk to me.

+ +

JOSH: Thank you.

+ +

CHAD: Part of this new season, Season 11 of the podcast, for the next few episodes, I'm going to be talking to each of the managing directors at thoughtbot about their teams, about the different kinds of work we do on those teams, and the challenges, and what phases are clients in those different stages of the product lifecycle.

+ +

So you can subscribe to the show and find notes for this episode and all the other episodes at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Josh, if folks want to get in touch with you or follow along with you, what are the best places for them to do that?

+ +

JOSH: Definitely Twitter. My handle is @joshuaclayton, all one word.

+ +

CHAD: Awesome. Thanks again. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

Special Guest: Joshua Clayton.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad interviews Managing Director at thoughtbot, Joshua Clayton, about what a Managing Director at thoughtbot does, what makes Boost at thoughtbot different than other teams, and the belief in integrated teams of designers and developers company-wide.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is The Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Josh Clayton, Managing Director of the thoughtbot Boost team. Hey, I know that company. Welcome, Josh.

+ +

JOSH: Hey, Chad. How are you?

+ +

CHAD: All right. I'm back to the show I think. I didn't get a chance to look up the last episode you're in, but it was probably hundreds of episodes ago now.

+ +

JOSH: Yeah, it's got to have been a while.

+ +

CHAD: [laughs] Speaking of a while, you recently…now time is all messed up for me, but I know that you have been at thoughtbot for a long time. How long has it been?

+ +

JOSH: It was 12 years in August.

+ +

CHAD: It's been a wonderful 12 years, Josh.

+ +

JOSH: I agree. I agree.

+ +

CHAD: [laughs]

+ +

JOSH: It's been fun.

+ +

CHAD: So in that time, you have had a few different roles. But you've been a Managing Director for a while now.

+ +

JOSH: Yeah, I think that's...let's see. It was seven and a half years for the Boston team. And then it's 10 and a half months with Boost.

+ +

CHAD: So your background is as a developer. And you, like a lot of people who have a background as developers at thoughtbot, myself included, still do development on a fairly regular basis. What does the Managing Director job at thoughtbot actually do?

+ +

JOSH: What don't we do [laughter] is maybe a better question. Effectively, we're running that team's business. So it involves some amount of software consulting. It involves software sales. It involves managing the profitability of the team. There are marketing functions, and, I don't know, anything and everything, hiring-related things. We opened up and recently filled our Development Director position, which was open for a couple of months over the summer. We've just opened up a Design Director position. So it's everything. [laughs] It's everything it feels like.

+ +

CHAD: At the beginning of this year, we did an episode about the changes that we had made at thoughtbot to reorganize the teams around rather than geographic studios around the types of work that we would do on that team. And that's how the Boost team was created. So in that episode, we gave people an overview. But I'd love to hear in your own words, what makes Boost at thoughtbot different than the other teams, and what do you focus on?

+ +

JOSH: So what makes Boost different? I think one of the drivers, one of the motivators, is to embed alongside existing product teams, engineering, and design teams, and help them get better, help them grow as well as ship features and fix bugs. So I think that the way that I position it is if there's an existing product that's deployed, people are using it day in and day out. Hopefully, it's been battle-tested. There are probably some funky areas of the code. Those are the codebases that we're operating in. It might be a team of two people; it might be a team of 200 people. But there is an existing product and an existing team. They're looking for our support to help make it better.

+ +

CHAD: One of the things I love about Boost and the changes that we've made, especially relative to Boost, is that at thoughtbot, we really believe in integrated teams of designers and developers. And a big part of what we've always done has been to be a complete product design and development team that brings new products to market, big and small. And because we were one of the first consulting companies in the world to switch to Ruby on Rails and because of that deep experience with Rails, and scaling, and working on existing products, we had a significant number of customers who engaged us for development for that expertise, and to help them scale, and grow, and hire, and implement best practices or solve problems that they were having in their existing codebase or on their existing team.

+ +

And even though that was a significant part of our business, it was always something that seemed that we maybe even didn't really want to be doing it, or it was on the periphery of our marketing and positioning. And I was super excited when we officially created this team because it allowed us to acknowledge that this was a significant part of what we do, a significant part of our revenue, and to have a team of people that opted into doing this kind of work who would not only love the kind of work but want to even grow it and do more of it. And we haven't really had that for this kind of work. We've had individuals wanting to do it but not at an organizational level in an organization that supports it. That was more of a statement than a question, but reaction?

+ +

JOSH: [laughs] I think you're spot on. It's always been interesting to me to hear that it's...obviously, at thoughtbot, we have been building MVPs and working with a lot of different types of companies over the years and helping them launch products. But I think that the type of work that I and, ideally, obviously, other people on the Boost team enjoy working on is existing platforms and working alongside existing teams. We talk about legacy systems, and I think they get a bad rap. And it's like, no, it's battle-tested.

+ +

CHAD: [chuckles]

+ +

JOSH: The business has proven its viability. It is still around years later. Conway's law applies in all of the stuff. Again, there are gnarly aspects of the code. But I think that's what the folks on the Boost team enjoy being challenged by is problems where these things are larger systems. They've been around for a while, and they do get pretty gnarly.

+ +

CHAD: I think one of the things that held us back in the past is that it is a skill set, and it's an experience. And you are going to be on an MVP project where you're doing design and development, going from concept to launching of a new idea, usually in a matter of weeks, working directly with a founder or a team of co-founders. And then you rotate on to this significantly larger project with maybe an engineering team of tens or dozens or hundreds of other developers on it. It's a very different skill set, and you have very different challenges in that environment. And when you're constantly switching between those different kinds of projects, you can't necessarily get better at it. And that's one of the other things that I think is helping us be more successful.

+ +

JOSH: I remember one of the teammates had joined the kick-off call with me at the Boost inception that very first meeting. And it was Joël. And Joël had asked pretty straightforwardly, "What is the expectation in terms of project rotations?" Because I think historically across the company, we'd aimed to do two to four-month engagements before we'd rotate folks. And I told him point-blank it's going to be six months to a year probably. And I don't think it necessarily shocked him or other folks on the team.

+ +

But I think when you're going into existing codebases and working alongside existing teams, there is inherently politics at play and complexities at play where it might take you being a new developer on a team six weeks, maybe longer before you actually feel comfortable and confident navigating the codebase and knowing where you can have and make an impact. And so, I think some of the shifts there have been particularly interesting to watch the types of consulting conversations that we have within the team just because it is a different beast, I think than building and launching products.

+ +

CHAD: So let's get into a little bit of detail about the kinds of projects we're doing in Boost to the extent that we can give specific examples and maybe more importantly and relevant to the audience, what are the things that we see? What are the common challenges that we see as products grow and evolve, as teams grow and evolve? What do you think one of the most common challenges that people have is?

+ +

JOSH: As teams grow and evolve, I think a lot of teams run into onboarding issues and general knowledge sharing. I think when you start a small team, and you're two, three, maybe five engineers, it's pretty easy for everyone to keep probably the entirety or the majority of that domain in their head at any one time. As you work to scale a team...there's a client of ours right now where they're effectively doubling every...I don't know what the time period is, but they're growing very, very rapidly.

+ +

And the feedback that some of our team have provided to them is it's really hard, and there are very much knowledge silos. And they're working through, okay? How do we tease this out? How do we share this context so that you don't have a couple of folks that are effectively blocking every single other member of the team? And so that's one of the core areas that hangs up our team and other teams. [chuckles] Our clients bring us on, and a lot of times, it's like we're rip-roaring and ready to go. And it's like, I need information from a bunch of people, and the processes aren't in place such that we can be as effective as we would want to be given the nature of work that we're doing.

+ +

CHAD: I think that's a straightforward problem, and it's a good example...I don't want to make this an hour-long thoughtbot commercial. But I'll just point blank say one of the reasons why sometimes working with us is positive for clients is it's really easy to have a certain pain around your onboarding process or company, even just simple things like how long it takes to get a new person a computer or to ramp them up on their existing team. If you're just hiring an employee, it's easy to ignore the cost of that.

+ +

JOSH: Yes.

+ +

CHAD: But when you're bringing on thoughtbot and we have a specific start date, and it's a certain cost, and those kinds of things, it can really expose the pain that is already happening but was just being ignored and provide the impetus to actually fix the problem.

+ +

JOSH: One of the things that we try to set out to do on the first day for any project is to open up a pull request to the codebase, whether it's an improvement to the onboarding like the README for the repository or whatever it might be. Ideally, we are finding ways to contribute on day one. And sometimes, that's frankly not realistic for individual contributors doing it from their own machines. But oftentimes, we'll know that going in. And as we onboard new folks and things like that, we'll say, okay, well, day one is going to be your pair programming over Tuple or some other tool so that you are able to engage and interact with a team and work on the code, even if there's still a bit of a lag between GitHub access and everything else that's the base of onboarding steps.

+ +

CHAD: So another common one that people bring us on to help with is scaling challenges in terms of the actual product itself, maybe that's performance or other scaling challenges. I'm working on a project now where that was how we first got involved. The service was failing, and it was only getting worse under the increasing scale. So, what are some tips that you have for how to effectively solve some of those problems while not bringing everything else that you need to accomplish to a screeching halt?

+ +

JOSH: At the end of the day, you can't fix something that you don't know is broken. Or you might have a hunch in terms of, oh, I know this page or this set of pages are slow. I think so much of what we see is teams come in, and they're like, "We don't have New Relic setup." We don't have an instrumentation setup. So they can't measure anything. And so it's like, I know this page takes three or four seconds to paint, but I don't know why. And I don't know how to fix it. It's like, okay, well, the first thing that we need to do is set up some amount of performance monitoring and application tracking just to get a sense of what that's like.

+ +

There is a potential customer who had reached out back in January of this year. So this was weeks into Boost's inception. And they said, "Listen, we've got some performance-related issues. We don't really know what to do, but we know the application is really, really slow on these couple of pages." It's like, "Are you using New Relic, or Scout, or anything like that?" They're like, "No." It's like, okay, that's the first thing that you need to do.

+ +

And they came back about a month ago and were like, okay, "Here's the access to all of this data. Now we're ready to go," and it's like, "Yes!" They probably didn't need to wait for that long. But it really speaks to that in order to address some of the performance-related stuff; we need to have some sense of what is going on and where.

+ +

I know Steph over on The Bike Shed Podcast had talked to Nate Berkopec. And she had floated one of the questions I had had. And he basically schooled me on that podcast and reiterated it really is ultimately about measuring so much of what we're doing.

+ +

CHAD: Yeah. One of the things, especially for teams that are having a problem but feel like they don't know what to do it's tough when it's actually the case. But the reality is a lot of times; there’s actually very low-hanging fruit that it's just no one has the time or experience to actually identify that. And putting some monitoring in place combined with actually taking the time to look through it, especially if it's the first time you ever hit scaling problems...There's either a missing database in that index or some N+1 queries, and fortunately, once you identify that kind of problem, it's usually fairly quick to fix as well.

+ +

It's a different thing when there's maybe fundamental architecture things that are causing your app to have scaling problems. But it's very unlikely that those are the first problems you're ever experiencing. The first problems you're ever going to experience if your app is running slow are going to be things happening at the database level or missing an index or something like that. And it's very unlikely that significant architecture changes need to be put in place in order to fix the first scaling problems that any product usually has.

+ +

JOSH: That wasn't the type, or at least I think when we got brought on, and you were working on your most recent clients, we were well beyond...maybe we weren't, maybe I'm misrepresenting or misremembering, but it feels like we were well beyond some of the low hanging fruit.

+ +

CHAD: Yeah, there was a batch of low-hanging fruit. One of the things if you're working on a product that is scaling super rapidly, what can happen is that the low-hanging fruit masks the other problems that are happening there because it all happened too quickly, all at the same time. And that was the case on this project. So it went from having hundreds of people using it to millions of people using it in the span of a month. And so there was low-hanging fruit.

+ +

But removing the low-hanging fruit didn't make the app suddenly work again; it just made it so that we could look at the metrics and say, "Okay, those things are no longer the problem." The real problems are not being masked now. We now can identify the architectural changes that need to be put into place in order to operate at the scale.

+ +

JOSH: Yeah, it's the low-hanging fruit when the orchard is on fire. [laughter] That is true.

+ +

CHAD: Right. So you got to peel back like an onion. And this is the case with I think a lot of...whether it be a technical challenge or a team challenge. You can't always come in and very quickly solve the root problem. You might not even know what the root problem is. You just have to start solving the problem that is obvious in front of you and learning more. And then you solve that one, and then you expose the next one, and you expose the next one.

+ +

And even when you can identify the root problem, you'll be like, this is the problem, and everyone agrees it's the problem. It still might be too hard to actually fix that problem. It might be an organizational or a systemic problem. And instead, you say, "Okay, we have to iteratively solve that problem." And you start peeling back those layers to get to the point where you've positioned yourself to solve that core problem. And I think we face that a lot, particularly as external consultants. We're coming in, and we can't just be the bull in the china shop. Because we haven't built the trust with everyone necessary to make the changes, or we don't know enough to know what the changes need to be.

+ +

JOSH: Right. And I think the people aspect of all of these things in my opinion...and I should caveat this with I've been writing software professionally for almost 20 years. The people, in my opinion, are always the harder aspects to any engagement. It's very rare that we go into a technical project where it's like we literally cannot figure out a technical solution to this thing. We can usually figure it out. And it might take weeks or months to implement, especially as it spans multiple systems. But more often than not, it's really navigating the people and the relationships and building that trust like you had mentioned that is really what will help dictate success within that project.

+ +

CHAD: I have a line that I use fairly often, and it's that I really believe very few, if any, developers sit down and are like, I'm going to write a bad solution today, or I'm going to write bad code today. That's not what people are doing. I think the majority of people genuinely try within their entire capacity to do a good job. And so that means that when I'm coming into a situation where there are problems, or things are messy, or there were bad decisions or bad code written, it can't be chalked up to like, oh, that was a bad developer, or that was a bad choice that was made. There was usually some people or organizational problem that caused that to happen in the first place. And merely fixing the bad code is not going to be what we should focus our time on. We probably need to do that. But if we don't fix the reason for that problem in the first place, it's just going to happen again.

+ +

A really popular example of this is when we get approached to do a Rails upgrade on a very significant product that is very behind with Rails. First of all, it's very expensive to do that on a very significant project if there's no test coverage. People could hire us to spend and spend a lot of money just getting to the next Rails version. But if they do that and don't solve the reason why they were so behind with Rails and have no test coverage and all that stuff, along the way, it will have been wasted effort because in a year or in two years, it will be back to the way that it was before. And that's one example that's very technical. But that kind of stuff happens all the time, even with squishy things [laughs] like the structure of a team or something like that.

+ +

So if you could give advice to people that are struggling with a particular problem, what would you tell them? And let's maybe make it a little bit more concrete. Like, one thing that can happen is as teams grow, like you said, not everyone can know everything. And so it starts breaking down into pods; maybe is one way to organize the team. And then you've gone into a bunch of individual teams working on discrete features. And that's happening fairly quickly. What are some ways to manage that change and manage that growth while maintaining continuity and making it go well?

+ +

JOSH: I think a lot of it depends on the goals from the technical leadership in terms of areas of ownership. That'd be the first part that I would dive into, I think. We work with clients where they segregate front-end from back-end development. And that allows the teams to focus on React and TypeScript versus Ruby or Go or whatever their back end is written in.

+ +

But if the goal is to share that knowledge, I think you've got options in terms of lunch and learn and shared code review and team demos and things like that. There are other ways to spread that information across the team so that everybody still has maybe not intimate knowledge of the code that's being written on a day to day basis, but they're at least aware of those patterns and practices and what each of the individual pods is may be responsible for and is delivering. So you have that team cohesion across more of the functional space, on the engineering side or on the product design side.

+ +

CHAD: One thing that I think I would also add is that a lot of times, people take for granted how better developers will do their job if they understand the reason or the business drivers behind what they're working on. And it's really easy for people to take that for granted because it's like, there's a ticket to the ticket. It says what to do on the ticket. [laughs]

+ +

JOSH: I have a blog post about this, actually.

+ +

CHAD: [laughs] Okay, great. We'll put that in the show notes. But if someone doesn't understand the reason behind that, it's not going to go the way that you're expecting frequently. It's not as straightforward.

+ +

JOSH: Yeah. You're left guessing what the underlying customer need is. And if you're guessing about the motivations, I don't want to say not in absolutes, but you're likely not going to address all of those core needs and implement an effective solution.

+ +

I think in the blog post that I had written, ultimately, it was advocating for getting engineers to participate in customer interviews and really understand, like, how are people using the product that I am implementing features for? Because without that exposure, without seeing those pain points, oftentimes, it's okay, you've got a product designer or a product manager who's putting together this list of things to do. And if it's treated as a checklist or oh, I need to go implement XYZ without understanding why that needs to be done in the first place, what is the pain point? What is the customer-facing? How are they feeling as they're going through the product? Without that context and without that empathy, the solution is going to be...it might functionally work. But will it be a good user experience? Will it be a good customer experience? It's a little bit more shaky, I think.

+ +

CHAD: Yeah. And in a fast-moving, fast-growing startup where everyone has a lot to do, if you're experiencing this kind of problem, it might manifest to you as stories get caught up at the beginning stages of when a developer is supposed to be working on them. And you find yourself having calls about what something is even supposed to be or supposed to do. And as the person who originated that ticket or originated that idea, you might have the feeling like, I can't believe we're having this conversation. Like, we don't have time to educate you about all the reasons why this is important and just please just do what we've said on the ticket. That is a natural reaction to that thing.

+ +

And so my advice would be if you're feeling that, if your team is feeling that or something similar, there's probably something small you can do. It might not even be having developers participate in discovery or interviews or anything. It might be as simple as just making sure that on the ticket you say why it's important. If your ticket is a checklist of things to change or do, making sure that the reason why is communicated there will go a long way to having the person pick up that ticket, get the context necessary to understand, and make good decisions as they work on it.

+ +

JOSH: Yeah, I remember the switch to the jobs to be done format. And I remember just being like, oh, [laughs] this makes a lot more sense because we can understand the context and the why. What is driving it? What is the problem there rather than what is the solution? And I think that shift in mindset does go a long way, like you said.

+ +

CHAD: I think one of the ideas behind a well-functioning team is we talk about this idea of collaboration which is you feel like you're doing your best work, that things are moving quickly, and you're enjoying the people you're working with, and you're building upon each other's ideas, and you're making things better as a team.

+ +

And I was recently talking to someone else, a candidate for VP of Engineering at one of our clients, and they were talking about flow, the idea of flow. And it wasn't a way that I had articulated it previously, but it's certainly another way of thinking about and a good way of thinking about it, especially when it comes to what is the role of a VP of engineering? Or what is the role of a CTO at a small company? Or what is the role of a development team or a product team in general? And one way to think about that is to work to maintain a flow state.

+ +

And when we think about the processes that we have in terms of retrospectives where every week we gather, and we identify things that could be better, and we come up with action items, a lot of the things that drive what could be better or what we want to try to do differently are all identifying the things that take us out of the flow state and trying to fix that problem so that items flow from beginning to end smoothly, that they go from concept to production smoothly as quickly as possible, and that individual people know where the next item to take is that it's ready so they're not blocked as they begin it. And they're able to get that to staging, and get a pull request out, and get that reviewed quickly, get it to staging, get that reviewed quickly, and then deploy it to production. And in theory, even do a continuous deployment so that that whole flow is automated as much as possible. So this idea of flow resonated with me. Has it resonated with you?

+ +

JOSH: Yeah, I agree. I remember seeing the comparisons people saying, okay, you're not actually looking for an engineer's passion necessarily. What you're looking for...and I come back to the hiring side of things because I'm doing that right now. But rather than looking to assess passion, it's assessing capacity and ability to get into a flow state more quickly. And obviously, so much of that is dependent on the team, and the communication style, the management style, and things like that.

+ +

But flow is very much...I think once you get into that and you know how to get into that like you said, every waking moment is spent trying to optimize how do I get into this space? Because when you're in that space, when you're flowing, be it from an IC level or above, there's nothing quite like it. It's just this calm state of just everything feels like it's firing all the time perfectly, and it's good. And I think trying to make those spaces available for the rest of the team to get into that state and maintain that state makes a lot of sense.

+ +

I remember years and years and years ago, there was the focus on maker versus manager time. And we talk about anchoring manager time either at the start of the end day or around lunchtime or whatever is a logical time for a break. The idea is to maintain that flow state for as long as possible so that nothing else eats into that. Because you do an hour of writing software, and then you've got a 30-minute one-on-one with a teammate. And then you go, and you run for another hour, hour and a half, and then it's another half an hour meeting. It's like you're being sucked away. It is really hard to get into that zone and then stay there. So I think there's been a focus on it for a while. And I'm really glad that there's now a name and a thing that we can point to.

+ +

CHAD: I don't want to lead people astray about what Boost is. There's a big important part of Boost, which may not be immediately obvious to people, and that is design. I may have insinuated that design wasn't part of Boost before when we were talking about it, but it is. And it's designed on existing products and existing teams which is a different need than going from concept to launch of a new idea.

+ +

JOSH: So we had done some work with The New England Journal of Medicine. And their team, a very small team, internal team, had basically designed an application. And they ran into a number of accessibility and usability issues. They continued to hear feedback from a lot of folks saying, "This is not effective for what we're looking to do." And they'd engaged us in a couple of different times basically to rip apart and re-architect some of the application hierarchy and the usability side of things.

+ +

It's been really interesting to see okay, well, within the design side of operating within existing products, it's often lended or leaned more towards doing some amount of a design audit and usability audit, talking to customers. And less around we're going to start from scratch and more what are some of these iterative improvements that we can make to make the product more accessible, easier to understand, easier to navigate, easier to use within what is, again, these very large platforms sometimes?

+ +

CHAD: I know one common request we get is we're thinking about implementing a design system or introducing a design system with the first version of the product. And we're having this growing pain around introducing new features. Is a design system the right thing to do there? That's a request we sometimes get.

+ +

JOSH: Yeah. And I think a lot of it at the end of the day, what we're looking to assess is what are the knowns? How much do we know about the application, about the interface? We talk about on the software development side of things avoiding premature abstraction, and I think the same thing is true about design systems. Like, if we're going through a product, maybe it's a wizard, and apart from forms, the pages are individualized, and there's not really any common patterns. It's like, okay, well, maybe now it doesn't make sense. But when you've got an application that spans hundreds of pages, there are going to be patterns across the different pages in terms of application hierarchy and componentization and things like that.

+ +

And the work that we're oftentimes brought in to do is let's assess what's there, figure out what are the common patterns here. And it's almost like refactoring and teasing things apart to where we get slight...it's a reduction in code use or rather an increase in code reuse because we're removing some of the idiosyncrasies that maybe were not teased apart into some component-based system. And that's fun work. [chuckles] It's really interesting.

+ +

You get things like React when you're doing client-side rendering. And within the Rails side of things, there's a big push for the GitHub ViewComponent. RubyGem is another example. It's both ways to introduce these layers of abstraction that allow more of the engineering team to take on more of the application development, not because design isn't necessary, but they're then empowered to reuse these logical set of components. And so it amplifies the dev work, but it also amplifies the design work because the entire team is now leaning on that pre-baked work. It enables designers to shift focus and priorities to okay; what are new components? What are different ways to position this or present this information? And also, for our designers, it frees up their time to talk even more to customers, to people using the system.

+ +

CHAD: Well, I guess we'd be remiss if we didn't do a more blatant plug. You mentioned it earlier, but we do have an opening for Design Director on the Boost team.

+ +

JOSH: We do.

+ +

CHAD: So who would be a good fit for that role?

+ +

JOSH: That's a great question. I think a couple of the things that we're really focusing on for this role is someone who has done the work, so to speak, at an IC level for a lot of the work that we're doing right now with customers. And so we ask point-blank on the application sheet, have you worked in HTML and CSS? Have you facilitated design exercises like design sprints? Have you facilitated user interviews? Because so much of what we're seeing from a vision and a strategy perspective is we need to take and leverage these tools in the skill sets that our teams are looking to hone in on, and we want to take it a lot further. I think there's a big opportunity there.

+ +

So I think it's less around years of experience. I wouldn't say you need to have 15 years of management experience or having been a director in order to apply for the role. But it's someone that can empathize with the team and has some opinions and some thoughts in terms of okay, what is design? What is not only visual design but product design accessibility? What does that look like in the next 5 to 10 years? Those are the people that I would love to see apply.

+ +

CHAD: If someone's interested, where's the best place for them to do that?

+ +

JOSH: thoughtbot.com/jobs. And the listing is there.

+ +

CHAD: So what's next for Boost, Josh? What do you have your sights set on as we wrap up 2021 and head into the next year?

+ +

JOSH: Oh boy. A lot of where the focus has been on this year is continuing to double down on Rails as the technology stack and get our feet wet, not that our feet aren't wet, [chuckles] continue to invest on the front end with React. I think for 2022, I think the big focus...we've run in the past some pretty successful custom trainings workshops for engineering teams. I think one that we had done earlier was late last year into early this year. We ran about 120 or so of their engineers through a custom RSpec course.

+ +

So we worked with their engineering managers and some of their teams and got a sense of okay; given this codebase and given the skill sets of this 100-plus person engineering team, where should we focus? And we put together a two-day RSpec workshop. We administered over; I think, five or six weeks. We did it virtually. And the reception from that was incredible. They ended up bringing us back on. We're getting ready to start another round of consulting work where we're embedding alongside their teams. So I see that as a huge opportunity for Boost coming into next year.

+ +

And then I think one of the things that we've been pushing for is reducing some of the billing time from folks in leadership positions so that they're in a better position to support their designers and developers. And I'm really excited about the progress that we've made thus far. And I'm excited to continue carrying that into next year.

+ +

CHAD: Awesome. Well, thanks for taking the time to talk to me.

+ +

JOSH: Thank you.

+ +

CHAD: Part of this new season, Season 11 of the podcast, for the next few episodes, I'm going to be talking to each of the managing directors at thoughtbot about their teams, about the different kinds of work we do on those teams, and the challenges, and what phases are clients in those different stages of the product lifecycle.

+ +

So you can subscribe to the show and find notes for this episode and all the other episodes at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Josh, if folks want to get in touch with you or follow along with you, what are the best places for them to do that?

+ +

JOSH: Definitely Twitter. My handle is @joshuaclayton, all one word.

+ +

CHAD: Awesome. Thanks again. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.

Special Guest: Joshua Clayton.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+xAzHpBi0 + + ]]> + + Chad Pytel + Joshua Clayton + + + 398: Education 2.0 with Victoria Ransom of Prisma + https://podcast.thoughtbot.com/398 + 1e8fe895-4f85-4adb-8155-1528f72f2fb2 + Thu, 21 Oct 2021 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Chad interviews Co-Founder and CEO, Victoria Ranson of Prisma. Prisma is a stealth-mode education startup on a mission to reimagine the way children are educated. Their mission is to create a generation capable of solving the world's biggest problems by creating and running a comprehensive virtual learning program for kids in grades 4-8 that is very unlike any other traditional homeschooling program you've ever heard of. + 41:42 + no + + + Chad interviews Co-Founder and CEO, Victoria Ranson of Prisma. Prisma is a stealth-mode education startup on a mission to reimagine the way children are educated. Their mission is to create a generation capable of solving the world's biggest problems by creating and running a comprehensive virtual learning program for kids in grades 4-8 that is very unlike any other traditional homeschooling program you've ever heard of. +Prisma's Website (https://joinprisma.com) +Follow Prisma on Twitter (https://twitter.com/JoinPrisma) or Facebook (https://www.facebook.com/joinprisma) +Follow Victoria on LinkedIn (https://www.linkedin.com/in/victoriaransom/) +Follow Co-Founder, President, and Victoria's husband Alan Chuard on Twitter (https://twitter.com/AlainChuard) +For more info, email info@joinprisma.com +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Victoria Ransom, founder, and CEO of Prisma. Victoria, thanks for joining me on the show. +VICTORIA: Hi, thanks for having me. +CHAD: So, Victoria, before we jump into this great product that you have, why don't you tell people what Prisma really is. +VICTORIA: Sure. Prisma is a very comprehensive educational program for kids who are learning from home or from anywhere in the world. It is not at all like traditional homeschooling because we provide kids with a very social experience. Kids are part of a cohort where they're meeting live with other kids every single day and collaborating with them on projects, and learning from each other, and discussing. And we provide coaches who are there every step of the way with the kids, providing them with rich feedback, helping to bring out the best in them, providing really engaging, live learning experiences. +So it’s not traditional homeschooling, although it has a lot of the really great benefits of that with the flexibility and the ability to learn from wherever you are. But we're equally not like typical online schooling, which I would say has tended to be more of an approach of taking traditional school and bringing it online. So there's still a concept of lectures, and grades, and textbooks. They may be electronic in nature, but they still resemble textbooks. +The Prisma curriculum is very different. It's rooted in learning through doing and project-based learning, and applying learning to the real world, and allowing kids a lot of choice. So they're ideally always learning through the lens of something that interests them and allowing them to go at their own pace. So a lot of the best practices from some of the most innovative bricks and mortar schools we're bringing to an online environment. And then, of course, we're very different from bricks and mortar schools because it is a virtual program where kids can learn from anywhere. +So we think it's a new approach to education that is really uniquely flexible, really prepares kids. We're very focused on preparing kids for the kind of world they're going to live in. The world is always changing rapidly. But I think this generation of kids is going to experience a future that's unlike anything we've ever seen in terms of the level of shift and change, AI being one of the reasons. +If you look at studies that look at the future of work, I think some studies we've read say 65% of today's elementary school kids will work in jobs that are yet to be invented. So, how do you prepare kids for that kind of future? And so, we're very focused on giving kids the holistic skills and the mindset that they will need to thrive in that kind of world. So yeah, that is Prisma in a very long nutshell. +CHAD: [chuckles] Obviously, I think we'd be remiss if we didn't talk about the context of where we're in, which is kids just went through a year or more where a lot of kids were remote for school. And did Prisma exist before the pandemic? +VICTORIA: It did in our minds very much so [chuckles] but not in reality. So Prisma arose out of our own personal needs. So my husband and I are the founders of Prisma. We've actually been entrepreneurs for most of our careers. After successfully selling a company to Google a few years ago, we said whatever we do next in our lives; we want it to be something that has the potential to have a large positive impact on society and on the world. And then struggled to figure out what that should look like because there are a lot of things that need solving in the world. +But we have three children, and as they approached school age, it really caused us to do a deep dive into how do we want to educate our kids? What do we think is the best approach to education? And from that, we started to formulate a vision by looking at all kinds of different schooling models, from homeschooling to micro-schooling to innovative bricks and mortar schooling. We developed a picture for how we wanted to educate our kids. But that really inspired us to create something that could be accessible to many more kids than just our own kids. +And so we had a good 18 months to 2 years of researching, ideating, thinking about the pros and cons of a virtual model. And then along came COVID, and at that point, we said, you know what? There's never been a better time to test out an innovative new approach to schooling, especially one that was always going to be home-based from the get-go. And so let's start ideating and dreaming about this, and let's just put it into action see how it goes. So it was born during COVID, but the roots of Prisma very much predate COVID. +CHAD: So, what was the actual timing there from when you decided to do something? When was that to you had the first students? +VICTORIA: Yeah, that was a whirlwind. [laughs] +CHAD: I can imagine. +VICTORIA: Yeah. So really, it was late March, I think of 2020, when we said, "We've just got to do this. The world is telling us to do this." To when we had our first kids in the door was early September. So between basically the beginning of April to the beginning of September, we incorporated, we refined our vision. The good news is we had a vision, and it was mapped out. We hired a curriculum team, hired coaches, created a website, found our first families, all of that. +And we launched Prisma very clearly with the families saying, "This is a pilot. We're trying something new here. Let's see how this goes." And we actually told the families, "Look, we're going to definitely run this until the end of December, the end of the year. And if it's not going really, really well, then we will suggest you go and do something better." But it went great. It's not to say our model is perfect. And we believe very much in constant improvement and constant iteration. +But in terms of kids loving school at a time, the national narrative was that kids were hating school, and they were falling behind, and parents were finding distance learning a disaster; we had kids that were loving school more than they ever had. And we surveyed kids, and that's why we know that. Parents were extremely happy. Everything was pointing to the fact that we really had found something unique that was really working. And so it turned from a pilot into something that we're now putting all the building blocks in place to be able to scale more broadly. +CHAD: School is a big thing, a big concept, and a very important one. Working so quickly in the midst of a pandemic, you know, launching any product is as much an art and finding what those first features need to be. How did you identify what that is and make sure you had something that was viable but that you could get done on time? +VICTORIA: I think that came down to...because obviously, our product is our curriculum and our model. We have a software development team and a product development team. And they are building the tools that we'll need to run our model. But when we first launched, we were piecing together different tools that already existed. So the initial product really was the curriculum and our model of education and the tools that we pieced together to make it work. +And I think the reason we were able to be successful is that we did a lot of groundwork in saying, what really matters? What is our perspective on what is the goal of this educational model? We got clear on that. What do we think are the values or approaches that really are critical to achieving that goal? And then using that as our Northstar. +So to be more concrete, we were really clear about two things in terms of why we were developing this model. One was we really wanted kids to love learning. We think they should love learning because learning is amazing, and it's exciting. And every kid is born with an innate desire to learn. And that if you want to bring the best out in kids, you want them to be excited about what they're learning. So kids loving learning was a very strong Northstar for us. And the second was what I already talked about before is developing an educational model that will really give kids the skills and mindsets they will need to really thrive in what is an exciting but uncertain future. And so that was the Northstar of why are we doing this. +From that, we developed a clear perspective on okay; if we want kids to love learning, how do we do that? And so it was things like making sure that kids have choice so they can apply their learning to things that really excite them, making sure learning is applied to the real world, so kids are never saying, "Why the heck do I need this?" Making sure that learning is hands-on as possible because we think kids just get more out of it, and learn more, and enjoy it more if they can really be hands-on and project-based. Making sure...I won't go through them all, but we have our sort of core curriculum values, making sure learning is happening in a community-supportive community. +And then the other thing we're really clear on is okay, what are these overarching skills or mindsets that we think are critical to succeeding in adulthood? And it was things like systems thinking and problem-solving, having a designer's mindset, which is this concept of being comfortable with iterating, and getting feedback, and putting yourself in someone else's shoes, being an excellent communicator and collaborator. Again, I won't go through them all. But we were just really clear. +I think we had a really strong foundation of why do we exist and what is our approach here? And that enabled us to then be really clear about things like, okay, we're not going to throw the kitchen sink in terms of everything that kids need to learn, no. We're more focused on overarching skills than checking the box on 1,000 different science standards that kids might need to go through. +So yeah, as you said, I think whenever you launch a product or a company, being able to narrow down because you can't offer everything you want to offer, being able to narrow down to what really matters is important. And I feel like we did a pretty good job with that. +CHAD: Awesome. What was the makeup of the initial team? You mentioned you and your husband. How did you split the responsibilities between you two, and then who else was involved? +VICTORIA: So my husband and I have been co-founders of several companies. And it's worked really well because we have very different skill sets. My husband has much more of a product mind. He's much more detail-oriented. And he has a real eye for design and user experiences and also a creative marketing mind. So that gives you a sense of where he tends to focus. And I've tended to focus more on people management and operationalizing businesses, being more that external spokesperson. And so that's how we have split. He's doing more of the software development and product marketing and marketing side of Prisma. And I'm more involved in the day-to-day running of the program. +Our first two very, very critical hires were curriculum developers, and Prisma would not be what it is today if we hadn't hired the two people that we hired. And they really balanced each other well because we hired Kristen, who had really deep experience in education. She had at a pretty young age founded her own charter school very successfully and just had such super deep experience in education, teaching, teaching teachers, training teachers, managing her own school. +And then we had Emily, who came from a really non-traditional background. She'd actually come up through the theater world, had done a degree at Harvard School of Education. And they actually had some good experience with working with professors at Harvard in innovative ways to assess, also, computer science education. And she's got a very out-of-the-box way of thinking. And between the two of those, it was a really great combination for us to turn what was a vision of a curriculum that Alain and I had created into something actually concrete. +And then the other critical hires were our first coaches. Again, we got super lucky in hiring just really fantastic coaches. And we've now realized hiring great coaches is a very fundamental part of what we do. And in fact, it will be one of our scaling challenges, I think. But again, we got really lucky with our coaches. And then, over time, we've hired operations people and product people. But I think that initial magic of the curriculum team and the coaching team was really important. We wouldn't be where we are today if we hadn't have hired those people, I think. +CHAD: Did you bring on the two curriculum team members full-time right away? +VICTORIA: We intended to, I think, when we were still incorporating the business. And all of this was happening in such a rush that I think we technically had to bring them on as contractors. But it was intended as a full-time role. Having said that, our hiring process asked them to sketch out in a fairly in-depth way or at least to sketch out in-depth pieces of what the ultimate Prisma curriculum would look like. So we did have a chance, I think, to test them out fairly well before we committed. +CHAD: So did you take investment to start Prisma, or did you self-fund it? +VICTORIA: We have self-funded. We're super lucky to be in the position to be able to do that, and we are continuing to self-fund. We had a ton of interest from venture capitalists; I think partly because we're somewhat proven entrepreneurs with other successes. And then also, because there was just suddenly a big spotlight on education and the belief that education might really shift. +But we have not taken funding because...it doesn't mean we won't ever. But we're very focused on being mission-first. And we're also very focused on growing carefully and thoughtfully. We think in the long run, we'll be far more successful if we really grow conservatively, at least initially, until we really feel like we've refined this and we know how to keep a really high level of quality and customer satisfaction while scaling. And I think our concern is that sometimes when you take outside capital that that capital might not be as patient. It might really push to grow faster than what we think might be the best approach. So thus far, we're just in the lucky position where we haven't had to take outside capital. +CHAD: I assume that you're on a traditional school schedule based on what you said about starting in September. +VICTORIA: We kind of are actually, which is funny because our initial vision for Prisma was to have it be year-round. And I think our families have been super open to so many innovative things. But the idea of having a summer break seems to be something that families don't want to give up on. +CHAD: [laughs] +VICTORIA: So I think our ultimate goal is that we'll be able to offer a summer program for those families that want to either go year-round or maybe they want to do the summer program and not do a winter program. And we do have kids already that are in the southern hemisphere, where that is desirable. But so far, we haven't tackled a summer program just because we're already tackling a lot. But we surveyed families, and they actually really wanted to mostly stick with the idea of having a summer, a more traditional summer break. +CHAD: But does that mean that you can't add students outside of that cycle, so you really truly have cohorts? Or are you adding people along the way? +VICTORIA: We're adding people along the way. We operate in five weeks cycles, actually. And each cycle has an overarching theme. And that's part of our goal of making things feel really-real world. And also, because kids have a lot of choice, we do want there to be some unifying factor to what they're doing. +And so examples of themes that we've done are cities of the future, hidden histories, which looked at U.S. history but really from the perspective of lessons we can learn, inventor studio where kids learned all about design thinking through being real inventors. We have a super cool theme right now called uncharted territories, which has got some really strong STEM learning but through the lens of space exploration and deep-sea exploration. And kids are working on an interdisciplinary project during that time. We have live workshops that are aligned around the theme. +And then they're also working on what we call missions. So math missions and writing missions, which again, are really honoring that idea of giving kids choice and allowing them to go at their own pace but just to make sure they're really getting the foundations they need in math and writing. But really, a kid could join at the beginning of any cycle. +CHAD: Okay, that's great. Is that a happy accident of the model, or was it intentional in terms of from a product perspective making sure that you could continue to add people and weren't locked in to a small set of initial users? +VICTORIA: No, that was intentional, although our original model that we launched with did not have five weeks cycles. It actually didn't have themes either. It was more trimester-based. We call them sessions, not trimesters. And so that was more of a model where we could have kids come in every trimester. And that's evolved to do these five-week cycles and themes. +And from the feedback we got in that first trimester, we evolved the model. And so, I guess we've now evolved in a way we could have even more frequent intakes. But yeah, I think it was very...for us not coming from the education world, the idea that you could only bring customers on board once a year that felt very foreign. So we've always had the idea of let's make sure we can onboard kids throughout the year. +CHAD: So what did the first families, I guess, the early adopters, what did they look like? +VICTORIA: They were a real mix, so some long-time public school families and private school families, some long-time homeschool families. It was a real mix. I think it was a mix. Now, the Prisma families, I would say, are very much bought into precisely what our model and our vision is. But that first set of pilot families, I think some of them, if you ask them honestly, would say, "School was a disaster because of COVID. We're willing to give anything a shot. We'll give this a shot." And I think what's been really surprising to some of those families is, wow, we actually really only thought we would do this for a year, and now we're continuing because it worked. +But it was a mix of families I'd say who had always really believed in a more alternative innovative approach to education but, for one reason or another, hadn't had the ability to test it perhaps because there were no schools like that in their neighborhood or because they just hadn't perhaps had the courage to try it out. So there was that set of families. There were families that had kids that would be probably said to be gifted and were just not being challenged in school and were a bit bored and not really living up to their potential that I think were attracted to give Prisma a shot. +There were homeschool families who really loved the idea of home-based learning but were looking for more community, a bit more support by having some structure and some coaches. And in some families where kids had not thrived in school because they had special learning needs. We even have kids at Prisma that have physical disabilities where physically showing up in school each day is really tough. And online learning just makes their life so much easier. So I guess the ultimate theme here is it was families for whom the more traditional bricks and mortar approach was maybe okay, but it wasn't wildly successful for their kids. +CHAD: You focus on particular grade levels or age range, right? +VICTORIA: Yes, four through eight right now, yeah. +CHAD: And you said, "Right now." [laughs] So why did you choose that age to focus on, and do you plan on expanding? +VICTORIA: Yes, we do plan on expanding. I think the first expansion will be to go up into high school grades. The reason we focused on fourth through eighth was twofold. One was that we just think parents are more open to experimenting with a new model at the elementary-middle school level than they are at the high school level, so there was that. Just because once you get to high school, parents and kids alike start to get more anxious about things like college admissions and perhaps become more risk-averse. But the other really big reason came from all the conversations we had with teachers. I didn't mention that when we hired for our first coaching roles, we got 1,400 applicants applying. [chuckles] +CHAD: Wow. +VICTORIA: And so we narrowed it down. I did not talk to 1,400 people, but I talked to a lot of teachers. And actually, we first started those conversations saying we were going to focus on high school. And we shifted our thinking in part because so many of those teachers said that they felt like fourth, fifth, sixth grade is a real turning point for kids in terms of their enjoyment of school and their confidence in their own abilities and part of the reason for that, not the only reason, is that testing starts to ramp up at that stage in schooling. But we just really felt like if we could catch kids at that point, before they'd sort of lost their enjoyment for learning and before they had started to internalize ideas like I'm not good at school, or I'm not good at math, or whatever it may be, that we could have the greatest impact. +The other thing is there is quite an unlearning process that kids have to go through when they join Prisma because we give them a lot of autonomy, and independence, and ability to make choices and have control over their schedule. And we ask them to write self-reviews. And when it's time for a Parent Coach Learner Conference, the learner leads that conference. And the earlier you can get kids, I think the easier it is to get them to adapt to that approach than when you get them later in their schooling where it's been drummed into them that you paint within the lines. You do what you're told. You do this in order to get good grades. And so that was another piece that attracted us to that age range. +CHAD: How old are your kids? +VICTORIA: Good question. So they are seven, four, and two. So they're not quite old enough for Prisma yet, so we're doing our own version of Prisma right now until our oldest is old enough for Prisma. And the reason we didn't go below fourth grade, at least for now, is we do think there is a limit to how young you can go and be successful with a largely virtual model, and so that's why we haven't gone below fourth. And so, our seven-year-old is being homeschooled. But we've also put together a community of other homeschool kids that she learns with several times a week and gets that socialization piece, so that's the cohort piece that we offer through Prisma. But yeah, she's definitely...she's in training to be a Prisma kid. +CHAD: How do you balance with both you and your husband working on Prisma, homeschooling a seven-year-old, the other kids? How are you balancing all of that? +VICTORIA: And just parenthood in general because this is our first time starting a company while having kids. +CHAD: Yes. +VICTORIA: We had a pretty long gap in between our last company and this. So the honest answer is we have hired a teacher for the homeschooling piece, so that helps a lot. And she's super capable, and she's really the frontline person for managing the community that we've developed. So the harder piece is not that so much; it's managing parenthood with entrepreneurship. [chuckles] I would say it's a work in progress. And ask me some days, and I'll say, "That's going great." And ask me other days, I would say, "It's not going so great." +We are really, really lucky that we can hire good childcare, so that helps a lot. But even if you have great childcare, I want to be involved with my kids. I love my time with my kids. There's also just so many decisions and things you need to be involved in with kids that you truly don't want to and should not outsource, whether it's as simple as like on my to-do list right now, is that the two-year-old's birthday is coming up, and I'm not going to outsource buying birthday presents or organizing a party. So that's on my to-do list. +So I would say relative to when we had our previous company which was really successful, and stressful, and busy but that was the only thing we had to worry about. Trying to manage a company and kids it's a lot of context shifting. But for me, at least, I'm very, very rigid about my time. So I will organize my schedule so that I finish at least at the latest by 4:00 p.m. each day, and that is my time with the kids. And I'm with them until they're in bed, and then I'll jump back online. But there's almost nothing that will interfere with it. And that's just how I've prioritized, and it's just really important to me. So it's setting priorities, I guess. +CHAD: Yeah, when we were setting up for the show, you said that you were in the office. So you separate home and work, and school places, I guess. +VICTORIA: Kind of. The office is a little built-out area of our garage, [chuckles] so I walk from the front door three paces into the garage. But it is separated to the extent that the kids are not running in at any moment. They don't really come here. But it's really nice. And I think a lot of parents have discovered that during this whole COVID work from home experience and with kids home too, it's really nice. Because not every day, but some days I can go in and have lunch with the kids because they're all around. And some days, I can pop over to Elle's classroom and see what she's doing and be involved and do a bit of reading with her and that sort of thing. +So I personally really love the efficiency of working from home, wasting no time with commutes, and also just the ability to be really flexible with my time. Maybe I will take an hour out in the middle of the day to do something with the kids, and then I'll make it up later in the evening because that's fine. I don't have that much going on in the evening anyway once the kids are in bed. So I personally really like that flexibility. +CHAD: So, turning our attention back to the product, you said that you got started piecing together existing tools on the tech side. And so, what were the first things that you started to replace in that stack? And when did you start hiring a tech team to do that? +VICTORIA: Yeah. So Alain, my husband, his background is product management. So we had product expertise already. We spun up a team of engineers, I think already by October or late October of 2020. So shortly after, we had officially begun the school year. And fortunately, these were engineers we'd worked with before in previous companies. +And the first thing we started to tackle actually was the live learning experience, so basically a replacement for Zoom. And that was partly because we felt like there was nothing available that really designed a live learning experience through the eyes of fourth through eighth graders, through that sort of demographic. And also, because the other product needs that we have that we're now tackling is everything we need to just manage the whole curriculum like a learning management system. +But our whole model was still too much in flux for us to want to focus on that right away. We needed some clarity about what the model would look like. Whereas the idea that we would always have a live learning component where kids would be online, there'd be a coach, but it would be very collaborative and interactive was very clear. We knew that wouldn't shift, and so that was the first piece we tackled. +And we've really tried to tackle a few different areas there. One is to make coaches really efficient so that they're not trying to focus on creating this really engaging learning experience while also having 15 different tabs open and trying to play this YouTube video. So we've basically created what we call Prisma LIVE, where our curriculum team can create these semi-scripted because we certainly let coaches deviate, of course, but experiences with chapters. +And there's a lot of shifting of the way the room looks, and the way the kids are organized, and the visuals. Because a lot of the research we looked at is that fatigue, Zoom fatigue, actually comes from staring for a long time at the same scene of this person you're talking to or these people you're talking to. So to make it visually stimulating and appealing for kids and seamless for coaches so they don't need to worry about managing all these different aspects of the workshop. They're just clicking through and focusing on making sure kids are participating. +And participation was another thing we really focused on. We do a lot of breakout rooms because we want kids to be collaborating in small groups. So we wanted coaches to be able to instead of having to jump into breakout rooms and interrupt the flow and not know who needs help, the ability for them to stay in the main room and be able to listen in and get an oversight for how things are going in the various breakout rooms and jump into those rooms where it's clear that they're needed perhaps because there's not much going on in there. There's not much discussion, or maybe there's a lot of very animated discussion. So that was an area we focused on and then just making it more kid-friendly and more fun. +And every cycle at Prisma ends with Expo Day, where kids present the project they've been working on to the whole Prisma community, parents, and grandparents. And one of the real downsides of virtual in that experience is that these kids are presenting these amazing things, but there's limited ability for people to express how amazing they think it is. And so just visual ways of people being able to express their emotions and their reactions during live workshops is another thing. We've focused on fun avatars that would appeal to kids and that sort of thing. So that has been our first focus. +Now we're heads down on the learning management piece. Like, what are the building blocks we need to put in place in order to be able to keep the customer experience really high whilst making our coaches more and more effective and more and more scalable? +CHAD: So as you got started or when you were thinking about getting started, what were you most afraid of? +VICTORIA: Well, aside from the fact that we're trying to pull this off really quickly and being afraid that this would be a complete failure, aside from that, honestly -- +CHAD: Just that small thing. [chuckles] +VICTORIA: Yeah. I think the thing that we were most nervous about, and I think it's the thing we probably get the biggest question about, and yet it has proven to be the thing we really didn't need to worry about, is socialization. And to what extent can kids build friendships virtually? To what extent can they build community virtually? To what extent can they meaningfully collaborate and learn together virtually? And I think we went in hoping that all of that was fully achievable but not being quite sure about it. +And honestly, the signs were so quick that that wasn't going to be an issue for us. Already in orientation...we organized this really fun orientation mostly oriented around making sure kids were excited and got to know each other. And so quickly, we started hearing from parents, like, "Oh, my kid can't stop talking about Prisma. They're jumping out of bed every morning. They've never done that before. They've never jumped out of bed to go to school. And my kid has already made their first friend." +And what I think we've discovered is absolutely kids can make friends virtually, and probably kids would have never questioned that actually. That probably felt natural to them. I think it's maybe adults that might question that. Now, does that mean that kids shouldn't have in-person friends? Of course, they should. And we would strongly encourage Prisma families to make sure their kids are enrolled in extracurriculars in their community and that sort of thing. We've surveyed the kids. Every single Prisma learner has said that they've made strong friendships at Prisma. For some of them, it's many friendships. For some of them, it's a smaller number of friendships. +And the other thing that's just going really well, I think, better than in-person school or bricks and mortar school is the community we've created. It's a really, really supportive community of kids. There hasn't been this sorting that I think happens in schools, particularly at the middle school and high school level of like, you're part of that clique, and you're part of that clique. And we're a little cooler than you are. Maybe just the nature of virtual makes it harder to sort kids like that. And there's not the natural time of in the cafeteria where you have to decide where you're going to sit and that kind of awkwardness. +Plus, we did a lot of legwork upfront of working with the kids to say: What kind of community do we want to build here? What are the values of our cohort? What are the expectations of our cohort? And I think that really helped to create a community that's just really kind and supportive, pretty uniquely kind and supportive, I think. +CHAD: Cool. That's great. And now that you're up and running and continuing to grow, looking ahead, what are you most worried about now as your next challenge? +VICTORIA: I think the biggest, hardest thing for us to figure out is how to keep the level of quality, great results. I haven't even mentioned it yet, but we are making sure that kids are progressing both academically in terms of these holistic skills. And on the academic front, we've seen really amazing growth. So the kids did a nationally recognized assessment at the end of last year and at the beginning when they joined. And they grew in math at 153% of expected growth and 174% of expected growth in reading. +So we've set a really high bar for ourselves. Kids are loving Prisma; 100% of kids said they're happier at Prisma than at their previous school. We have a really great Net Promoter Score, which means parents are really willing to recommend Prisma. We're seeing great growth in the kids. So how do we keep that super high bar whilst opening Prisma up to more and more and more kids? Because part of the attraction for us to offer a virtual model was the desire to be able to reach large numbers of kids if we came up with a model that really worked. +And I think through all of our research, one of the things we noticed is there are amazingly innovative schools out there. There are a lot of really innovative brick-and-mortar schools, actually, but they really haven't scaled. They tend to be...a few have scaled a bit, but they're still very limited in the number of kids that they can reach. And part of our thesis was that if you could do this online, just online is inherently more scalable. You're not dealing with buildings and everything that goes along with that. +But nevertheless, we still are a model where coaches are really important. So our ability to continue to find, train, and develop coaches that are really awesome I think will be a challenge, something we're going to have to get really, really good at. And then just making sure that we can strike the right balance because we also want to be a model that's as affordable as possible and that requires us to make sure that our costs are reasonable. So striking that balance and trying to use technology to be as efficient as possible, I think that is the next set of challenges that we need to deal with. +CHAD: Are you comfortable sharing how many students you have now? +VICTORIA: Yeah, I'm comfortable with that because the number we have was very much set by our own desire to grow carefully. So we have almost 90 kids. And we have a very long waitlist, basically. +CHAD: Well, that's bigger than my high school graduating class. [laughs] +VICTORIA: Oh, there you go. [laughs] It's funny because people react differently to that. Some people are like, "Wow, that's pretty big." It's not nearly as big as we intend to get. But we decided to cap. We wanted to be disciplined. We had way more demand than that. But further to what I said of quality first and delighting customers first, we said, "No, we'll cut it off at that point." And families have gone on to a waitlist, which is growing by the day. And then we'll be able to let more families in throughout the year. +We're small, but we're a lot bigger than we were in our first pilot year. And I think what's been really exciting is we're still somewhat early into the school year. But that level of delight, and excitement, and families just writing to us and saying, "I've never seen my kids so excited." And that's happening again. So it's really exciting to see that we're getting that again even though we have actually grown quite a bit relative to where we were. +CHAD: Well, congratulations on everything that you've achieved so far and in tackling these upcoming challenges. +VICTORIA: Thank you. +CHAD: If people want to find out more about Prisma and join or if they're interested in becoming a great coach, where can they do that? +VICTORIA: So the best place to go is our website which is joinprisma.com, so not prisma.com, joinprisma.com. We have a super detailed website, which I think is really informative. So that's a great place to start. You can also sign up for an info session there if you want to talk to someone live about Prisma. And then yes, we have job postings on there as well. And we're always super excited to hear from talented candidates. So that's the best place to go. +CHAD: And if people want to follow along with you personally or get in touch, where are the best places for them to do that? +VICTORIA: So we do have Prisma social media accounts, so Twitter is @joinprisma. And I'm not the most active person on social media. My husband is much more active, so they may want to follow him. He's Alain Chuard. I presume his Twitter handle is @AlainChuard, C-H-U-A-R-D. [laughs] And you can reach me if you email info@joinprisma.com, but you address it to Victoria. It will reach me, and I will reply. +CHAD: Awesome. And people can find all these links and everything in the show notes, which are at giantrobots.fm. You can also subscribe to the show there as well. And if you have questions or comments for us, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Everybody, thanks for listening and see you next time. Thanks, Victoria. +VICTORIA: Thank you. Thanks so much. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Victoria Ransom. + + + Chad interviews Co-Founder and CEO, Victoria Ranson of Prisma. Prisma is a stealth-mode education startup on a mission to reimagine the way children are educated. Their mission is to create a generation capable of solving the world's biggest problems by creating and running a comprehensive virtual learning program for kids in grades 4-8 that is very unlike any other traditional homeschooling program you've ever heard of.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Victoria Ransom, founder, and CEO of Prisma. Victoria, thanks for joining me on the show.

+ +

VICTORIA: Hi, thanks for having me.

+ +

CHAD: So, Victoria, before we jump into this great product that you have, why don't you tell people what Prisma really is.

+ +

VICTORIA: Sure. Prisma is a very comprehensive educational program for kids who are learning from home or from anywhere in the world. It is not at all like traditional homeschooling because we provide kids with a very social experience. Kids are part of a cohort where they're meeting live with other kids every single day and collaborating with them on projects, and learning from each other, and discussing. And we provide coaches who are there every step of the way with the kids, providing them with rich feedback, helping to bring out the best in them, providing really engaging, live learning experiences.

+ +

So it’s not traditional homeschooling, although it has a lot of the really great benefits of that with the flexibility and the ability to learn from wherever you are. But we're equally not like typical online schooling, which I would say has tended to be more of an approach of taking traditional school and bringing it online. So there's still a concept of lectures, and grades, and textbooks. They may be electronic in nature, but they still resemble textbooks.

+ +

The Prisma curriculum is very different. It's rooted in learning through doing and project-based learning, and applying learning to the real world, and allowing kids a lot of choice. So they're ideally always learning through the lens of something that interests them and allowing them to go at their own pace. So a lot of the best practices from some of the most innovative bricks and mortar schools we're bringing to an online environment. And then, of course, we're very different from bricks and mortar schools because it is a virtual program where kids can learn from anywhere.

+ +

So we think it's a new approach to education that is really uniquely flexible, really prepares kids. We're very focused on preparing kids for the kind of world they're going to live in. The world is always changing rapidly. But I think this generation of kids is going to experience a future that's unlike anything we've ever seen in terms of the level of shift and change, AI being one of the reasons.

+ +

If you look at studies that look at the future of work, I think some studies we've read say 65% of today's elementary school kids will work in jobs that are yet to be invented. So, how do you prepare kids for that kind of future? And so, we're very focused on giving kids the holistic skills and the mindset that they will need to thrive in that kind of world. So yeah, that is Prisma in a very long nutshell.

+ +

CHAD: [chuckles] Obviously, I think we'd be remiss if we didn't talk about the context of where we're in, which is kids just went through a year or more where a lot of kids were remote for school. And did Prisma exist before the pandemic?

+ +

VICTORIA: It did in our minds very much so [chuckles] but not in reality. So Prisma arose out of our own personal needs. So my husband and I are the founders of Prisma. We've actually been entrepreneurs for most of our careers. After successfully selling a company to Google a few years ago, we said whatever we do next in our lives; we want it to be something that has the potential to have a large positive impact on society and on the world. And then struggled to figure out what that should look like because there are a lot of things that need solving in the world.

+ +

But we have three children, and as they approached school age, it really caused us to do a deep dive into how do we want to educate our kids? What do we think is the best approach to education? And from that, we started to formulate a vision by looking at all kinds of different schooling models, from homeschooling to micro-schooling to innovative bricks and mortar schooling. We developed a picture for how we wanted to educate our kids. But that really inspired us to create something that could be accessible to many more kids than just our own kids.

+ +

And so we had a good 18 months to 2 years of researching, ideating, thinking about the pros and cons of a virtual model. And then along came COVID, and at that point, we said, you know what? There's never been a better time to test out an innovative new approach to schooling, especially one that was always going to be home-based from the get-go. And so let's start ideating and dreaming about this, and let's just put it into action see how it goes. So it was born during COVID, but the roots of Prisma very much predate COVID.

+ +

CHAD: So, what was the actual timing there from when you decided to do something? When was that to you had the first students?

+ +

VICTORIA: Yeah, that was a whirlwind. [laughs]

+ +

CHAD: I can imagine.

+ +

VICTORIA: Yeah. So really, it was late March, I think of 2020, when we said, "We've just got to do this. The world is telling us to do this." To when we had our first kids in the door was early September. So between basically the beginning of April to the beginning of September, we incorporated, we refined our vision. The good news is we had a vision, and it was mapped out. We hired a curriculum team, hired coaches, created a website, found our first families, all of that.

+ +

And we launched Prisma very clearly with the families saying, "This is a pilot. We're trying something new here. Let's see how this goes." And we actually told the families, "Look, we're going to definitely run this until the end of December, the end of the year. And if it's not going really, really well, then we will suggest you go and do something better." But it went great. It's not to say our model is perfect. And we believe very much in constant improvement and constant iteration.

+ +

But in terms of kids loving school at a time, the national narrative was that kids were hating school, and they were falling behind, and parents were finding distance learning a disaster; we had kids that were loving school more than they ever had. And we surveyed kids, and that's why we know that. Parents were extremely happy. Everything was pointing to the fact that we really had found something unique that was really working. And so it turned from a pilot into something that we're now putting all the building blocks in place to be able to scale more broadly.

+ +

CHAD: School is a big thing, a big concept, and a very important one. Working so quickly in the midst of a pandemic, you know, launching any product is as much an art and finding what those first features need to be. How did you identify what that is and make sure you had something that was viable but that you could get done on time?

+ +

VICTORIA: I think that came down to...because obviously, our product is our curriculum and our model. We have a software development team and a product development team. And they are building the tools that we'll need to run our model. But when we first launched, we were piecing together different tools that already existed. So the initial product really was the curriculum and our model of education and the tools that we pieced together to make it work.

+ +

And I think the reason we were able to be successful is that we did a lot of groundwork in saying, what really matters? What is our perspective on what is the goal of this educational model? We got clear on that. What do we think are the values or approaches that really are critical to achieving that goal? And then using that as our Northstar.

+ +

So to be more concrete, we were really clear about two things in terms of why we were developing this model. One was we really wanted kids to love learning. We think they should love learning because learning is amazing, and it's exciting. And every kid is born with an innate desire to learn. And that if you want to bring the best out in kids, you want them to be excited about what they're learning. So kids loving learning was a very strong Northstar for us. And the second was what I already talked about before is developing an educational model that will really give kids the skills and mindsets they will need to really thrive in what is an exciting but uncertain future. And so that was the Northstar of why are we doing this.

+ +

From that, we developed a clear perspective on okay; if we want kids to love learning, how do we do that? And so it was things like making sure that kids have choice so they can apply their learning to things that really excite them, making sure learning is applied to the real world, so kids are never saying, "Why the heck do I need this?" Making sure that learning is hands-on as possible because we think kids just get more out of it, and learn more, and enjoy it more if they can really be hands-on and project-based. Making sure...I won't go through them all, but we have our sort of core curriculum values, making sure learning is happening in a community-supportive community.

+ +

And then the other thing we're really clear on is okay, what are these overarching skills or mindsets that we think are critical to succeeding in adulthood? And it was things like systems thinking and problem-solving, having a designer's mindset, which is this concept of being comfortable with iterating, and getting feedback, and putting yourself in someone else's shoes, being an excellent communicator and collaborator. Again, I won't go through them all. But we were just really clear.

+ +

I think we had a really strong foundation of why do we exist and what is our approach here? And that enabled us to then be really clear about things like, okay, we're not going to throw the kitchen sink in terms of everything that kids need to learn, no. We're more focused on overarching skills than checking the box on 1,000 different science standards that kids might need to go through.

+ +

So yeah, as you said, I think whenever you launch a product or a company, being able to narrow down because you can't offer everything you want to offer, being able to narrow down to what really matters is important. And I feel like we did a pretty good job with that.

+ +

CHAD: Awesome. What was the makeup of the initial team? You mentioned you and your husband. How did you split the responsibilities between you two, and then who else was involved?

+ +

VICTORIA: So my husband and I have been co-founders of several companies. And it's worked really well because we have very different skill sets. My husband has much more of a product mind. He's much more detail-oriented. And he has a real eye for design and user experiences and also a creative marketing mind. So that gives you a sense of where he tends to focus. And I've tended to focus more on people management and operationalizing businesses, being more that external spokesperson. And so that's how we have split. He's doing more of the software development and product marketing and marketing side of Prisma. And I'm more involved in the day-to-day running of the program.

+ +

Our first two very, very critical hires were curriculum developers, and Prisma would not be what it is today if we hadn't hired the two people that we hired. And they really balanced each other well because we hired Kristen, who had really deep experience in education. She had at a pretty young age founded her own charter school very successfully and just had such super deep experience in education, teaching, teaching teachers, training teachers, managing her own school.

+ +

And then we had Emily, who came from a really non-traditional background. She'd actually come up through the theater world, had done a degree at Harvard School of Education. And they actually had some good experience with working with professors at Harvard in innovative ways to assess, also, computer science education. And she's got a very out-of-the-box way of thinking. And between the two of those, it was a really great combination for us to turn what was a vision of a curriculum that Alain and I had created into something actually concrete.

+ +

And then the other critical hires were our first coaches. Again, we got super lucky in hiring just really fantastic coaches. And we've now realized hiring great coaches is a very fundamental part of what we do. And in fact, it will be one of our scaling challenges, I think. But again, we got really lucky with our coaches. And then, over time, we've hired operations people and product people. But I think that initial magic of the curriculum team and the coaching team was really important. We wouldn't be where we are today if we hadn't have hired those people, I think.

+ +

CHAD: Did you bring on the two curriculum team members full-time right away?

+ +

VICTORIA: We intended to, I think, when we were still incorporating the business. And all of this was happening in such a rush that I think we technically had to bring them on as contractors. But it was intended as a full-time role. Having said that, our hiring process asked them to sketch out in a fairly in-depth way or at least to sketch out in-depth pieces of what the ultimate Prisma curriculum would look like. So we did have a chance, I think, to test them out fairly well before we committed.

+ +

CHAD: So did you take investment to start Prisma, or did you self-fund it?

+ +

VICTORIA: We have self-funded. We're super lucky to be in the position to be able to do that, and we are continuing to self-fund. We had a ton of interest from venture capitalists; I think partly because we're somewhat proven entrepreneurs with other successes. And then also, because there was just suddenly a big spotlight on education and the belief that education might really shift.

+ +

But we have not taken funding because...it doesn't mean we won't ever. But we're very focused on being mission-first. And we're also very focused on growing carefully and thoughtfully. We think in the long run, we'll be far more successful if we really grow conservatively, at least initially, until we really feel like we've refined this and we know how to keep a really high level of quality and customer satisfaction while scaling. And I think our concern is that sometimes when you take outside capital that that capital might not be as patient. It might really push to grow faster than what we think might be the best approach. So thus far, we're just in the lucky position where we haven't had to take outside capital.

+ +

CHAD: I assume that you're on a traditional school schedule based on what you said about starting in September.

+ +

VICTORIA: We kind of are actually, which is funny because our initial vision for Prisma was to have it be year-round. And I think our families have been super open to so many innovative things. But the idea of having a summer break seems to be something that families don't want to give up on.

+ +

CHAD: [laughs]

+ +

VICTORIA: So I think our ultimate goal is that we'll be able to offer a summer program for those families that want to either go year-round or maybe they want to do the summer program and not do a winter program. And we do have kids already that are in the southern hemisphere, where that is desirable. But so far, we haven't tackled a summer program just because we're already tackling a lot. But we surveyed families, and they actually really wanted to mostly stick with the idea of having a summer, a more traditional summer break.

+ +

CHAD: But does that mean that you can't add students outside of that cycle, so you really truly have cohorts? Or are you adding people along the way?

+ +

VICTORIA: We're adding people along the way. We operate in five weeks cycles, actually. And each cycle has an overarching theme. And that's part of our goal of making things feel really-real world. And also, because kids have a lot of choice, we do want there to be some unifying factor to what they're doing.

+ +

And so examples of themes that we've done are cities of the future, hidden histories, which looked at U.S. history but really from the perspective of lessons we can learn, inventor studio where kids learned all about design thinking through being real inventors. We have a super cool theme right now called uncharted territories, which has got some really strong STEM learning but through the lens of space exploration and deep-sea exploration. And kids are working on an interdisciplinary project during that time. We have live workshops that are aligned around the theme.

+ +

And then they're also working on what we call missions. So math missions and writing missions, which again, are really honoring that idea of giving kids choice and allowing them to go at their own pace but just to make sure they're really getting the foundations they need in math and writing. But really, a kid could join at the beginning of any cycle.

+ +

CHAD: Okay, that's great. Is that a happy accident of the model, or was it intentional in terms of from a product perspective making sure that you could continue to add people and weren't locked in to a small set of initial users?

+ +

VICTORIA: No, that was intentional, although our original model that we launched with did not have five weeks cycles. It actually didn't have themes either. It was more trimester-based. We call them sessions, not trimesters. And so that was more of a model where we could have kids come in every trimester. And that's evolved to do these five-week cycles and themes.

+ +

And from the feedback we got in that first trimester, we evolved the model. And so, I guess we've now evolved in a way we could have even more frequent intakes. But yeah, I think it was very...for us not coming from the education world, the idea that you could only bring customers on board once a year that felt very foreign. So we've always had the idea of let's make sure we can onboard kids throughout the year.

+ +

CHAD: So what did the first families, I guess, the early adopters, what did they look like?

+ +

VICTORIA: They were a real mix, so some long-time public school families and private school families, some long-time homeschool families. It was a real mix. I think it was a mix. Now, the Prisma families, I would say, are very much bought into precisely what our model and our vision is. But that first set of pilot families, I think some of them, if you ask them honestly, would say, "School was a disaster because of COVID. We're willing to give anything a shot. We'll give this a shot." And I think what's been really surprising to some of those families is, wow, we actually really only thought we would do this for a year, and now we're continuing because it worked.

+ +

But it was a mix of families I'd say who had always really believed in a more alternative innovative approach to education but, for one reason or another, hadn't had the ability to test it perhaps because there were no schools like that in their neighborhood or because they just hadn't perhaps had the courage to try it out. So there was that set of families. There were families that had kids that would be probably said to be gifted and were just not being challenged in school and were a bit bored and not really living up to their potential that I think were attracted to give Prisma a shot.

+ +

There were homeschool families who really loved the idea of home-based learning but were looking for more community, a bit more support by having some structure and some coaches. And in some families where kids had not thrived in school because they had special learning needs. We even have kids at Prisma that have physical disabilities where physically showing up in school each day is really tough. And online learning just makes their life so much easier. So I guess the ultimate theme here is it was families for whom the more traditional bricks and mortar approach was maybe okay, but it wasn't wildly successful for their kids.

+ +

CHAD: You focus on particular grade levels or age range, right?

+ +

VICTORIA: Yes, four through eight right now, yeah.

+ +

CHAD: And you said, "Right now." [laughs] So why did you choose that age to focus on, and do you plan on expanding?

+ +

VICTORIA: Yes, we do plan on expanding. I think the first expansion will be to go up into high school grades. The reason we focused on fourth through eighth was twofold. One was that we just think parents are more open to experimenting with a new model at the elementary-middle school level than they are at the high school level, so there was that. Just because once you get to high school, parents and kids alike start to get more anxious about things like college admissions and perhaps become more risk-averse. But the other really big reason came from all the conversations we had with teachers. I didn't mention that when we hired for our first coaching roles, we got 1,400 applicants applying. [chuckles]

+ +

CHAD: Wow.

+ +

VICTORIA: And so we narrowed it down. I did not talk to 1,400 people, but I talked to a lot of teachers. And actually, we first started those conversations saying we were going to focus on high school. And we shifted our thinking in part because so many of those teachers said that they felt like fourth, fifth, sixth grade is a real turning point for kids in terms of their enjoyment of school and their confidence in their own abilities and part of the reason for that, not the only reason, is that testing starts to ramp up at that stage in schooling. But we just really felt like if we could catch kids at that point, before they'd sort of lost their enjoyment for learning and before they had started to internalize ideas like I'm not good at school, or I'm not good at math, or whatever it may be, that we could have the greatest impact.

+ +

The other thing is there is quite an unlearning process that kids have to go through when they join Prisma because we give them a lot of autonomy, and independence, and ability to make choices and have control over their schedule. And we ask them to write self-reviews. And when it's time for a Parent Coach Learner Conference, the learner leads that conference. And the earlier you can get kids, I think the easier it is to get them to adapt to that approach than when you get them later in their schooling where it's been drummed into them that you paint within the lines. You do what you're told. You do this in order to get good grades. And so that was another piece that attracted us to that age range.

+ +

CHAD: How old are your kids?

+ +

VICTORIA: Good question. So they are seven, four, and two. So they're not quite old enough for Prisma yet, so we're doing our own version of Prisma right now until our oldest is old enough for Prisma. And the reason we didn't go below fourth grade, at least for now, is we do think there is a limit to how young you can go and be successful with a largely virtual model, and so that's why we haven't gone below fourth. And so, our seven-year-old is being homeschooled. But we've also put together a community of other homeschool kids that she learns with several times a week and gets that socialization piece, so that's the cohort piece that we offer through Prisma. But yeah, she's definitely...she's in training to be a Prisma kid.

+ +

CHAD: How do you balance with both you and your husband working on Prisma, homeschooling a seven-year-old, the other kids? How are you balancing all of that?

+ +

VICTORIA: And just parenthood in general because this is our first time starting a company while having kids.

+ +

CHAD: Yes.

+ +

VICTORIA: We had a pretty long gap in between our last company and this. So the honest answer is we have hired a teacher for the homeschooling piece, so that helps a lot. And she's super capable, and she's really the frontline person for managing the community that we've developed. So the harder piece is not that so much; it's managing parenthood with entrepreneurship. [chuckles] I would say it's a work in progress. And ask me some days, and I'll say, "That's going great." And ask me other days, I would say, "It's not going so great."

+ +

We are really, really lucky that we can hire good childcare, so that helps a lot. But even if you have great childcare, I want to be involved with my kids. I love my time with my kids. There's also just so many decisions and things you need to be involved in with kids that you truly don't want to and should not outsource, whether it's as simple as like on my to-do list right now, is that the two-year-old's birthday is coming up, and I'm not going to outsource buying birthday presents or organizing a party. So that's on my to-do list.

+ +

So I would say relative to when we had our previous company which was really successful, and stressful, and busy but that was the only thing we had to worry about. Trying to manage a company and kids it's a lot of context shifting. But for me, at least, I'm very, very rigid about my time. So I will organize my schedule so that I finish at least at the latest by 4:00 p.m. each day, and that is my time with the kids. And I'm with them until they're in bed, and then I'll jump back online. But there's almost nothing that will interfere with it. And that's just how I've prioritized, and it's just really important to me. So it's setting priorities, I guess.

+ +

CHAD: Yeah, when we were setting up for the show, you said that you were in the office. So you separate home and work, and school places, I guess.

+ +

VICTORIA: Kind of. The office is a little built-out area of our garage, [chuckles] so I walk from the front door three paces into the garage. But it is separated to the extent that the kids are not running in at any moment. They don't really come here. But it's really nice. And I think a lot of parents have discovered that during this whole COVID work from home experience and with kids home too, it's really nice. Because not every day, but some days I can go in and have lunch with the kids because they're all around. And some days, I can pop over to Elle's classroom and see what she's doing and be involved and do a bit of reading with her and that sort of thing.

+ +

So I personally really love the efficiency of working from home, wasting no time with commutes, and also just the ability to be really flexible with my time. Maybe I will take an hour out in the middle of the day to do something with the kids, and then I'll make it up later in the evening because that's fine. I don't have that much going on in the evening anyway once the kids are in bed. So I personally really like that flexibility.

+ +

CHAD: So, turning our attention back to the product, you said that you got started piecing together existing tools on the tech side. And so, what were the first things that you started to replace in that stack? And when did you start hiring a tech team to do that?

+ +

VICTORIA: Yeah. So Alain, my husband, his background is product management. So we had product expertise already. We spun up a team of engineers, I think already by October or late October of 2020. So shortly after, we had officially begun the school year. And fortunately, these were engineers we'd worked with before in previous companies.

+ +

And the first thing we started to tackle actually was the live learning experience, so basically a replacement for Zoom. And that was partly because we felt like there was nothing available that really designed a live learning experience through the eyes of fourth through eighth graders, through that sort of demographic. And also, because the other product needs that we have that we're now tackling is everything we need to just manage the whole curriculum like a learning management system.

+ +

But our whole model was still too much in flux for us to want to focus on that right away. We needed some clarity about what the model would look like. Whereas the idea that we would always have a live learning component where kids would be online, there'd be a coach, but it would be very collaborative and interactive was very clear. We knew that wouldn't shift, and so that was the first piece we tackled.

+ +

And we've really tried to tackle a few different areas there. One is to make coaches really efficient so that they're not trying to focus on creating this really engaging learning experience while also having 15 different tabs open and trying to play this YouTube video. So we've basically created what we call Prisma LIVE, where our curriculum team can create these semi-scripted because we certainly let coaches deviate, of course, but experiences with chapters.

+ +

And there's a lot of shifting of the way the room looks, and the way the kids are organized, and the visuals. Because a lot of the research we looked at is that fatigue, Zoom fatigue, actually comes from staring for a long time at the same scene of this person you're talking to or these people you're talking to. So to make it visually stimulating and appealing for kids and seamless for coaches so they don't need to worry about managing all these different aspects of the workshop. They're just clicking through and focusing on making sure kids are participating.

+ +

And participation was another thing we really focused on. We do a lot of breakout rooms because we want kids to be collaborating in small groups. So we wanted coaches to be able to instead of having to jump into breakout rooms and interrupt the flow and not know who needs help, the ability for them to stay in the main room and be able to listen in and get an oversight for how things are going in the various breakout rooms and jump into those rooms where it's clear that they're needed perhaps because there's not much going on in there. There's not much discussion, or maybe there's a lot of very animated discussion. So that was an area we focused on and then just making it more kid-friendly and more fun.

+ +

And every cycle at Prisma ends with Expo Day, where kids present the project they've been working on to the whole Prisma community, parents, and grandparents. And one of the real downsides of virtual in that experience is that these kids are presenting these amazing things, but there's limited ability for people to express how amazing they think it is. And so just visual ways of people being able to express their emotions and their reactions during live workshops is another thing. We've focused on fun avatars that would appeal to kids and that sort of thing. So that has been our first focus.

+ +

Now we're heads down on the learning management piece. Like, what are the building blocks we need to put in place in order to be able to keep the customer experience really high whilst making our coaches more and more effective and more and more scalable?
+CHAD: So as you got started or when you were thinking about getting started, what were you most afraid of?

+ +

VICTORIA: Well, aside from the fact that we're trying to pull this off really quickly and being afraid that this would be a complete failure, aside from that, honestly --

+ +

CHAD: Just that small thing. [chuckles]

+ +

VICTORIA: Yeah. I think the thing that we were most nervous about, and I think it's the thing we probably get the biggest question about, and yet it has proven to be the thing we really didn't need to worry about, is socialization. And to what extent can kids build friendships virtually? To what extent can they build community virtually? To what extent can they meaningfully collaborate and learn together virtually? And I think we went in hoping that all of that was fully achievable but not being quite sure about it.

+ +

And honestly, the signs were so quick that that wasn't going to be an issue for us. Already in orientation...we organized this really fun orientation mostly oriented around making sure kids were excited and got to know each other. And so quickly, we started hearing from parents, like, "Oh, my kid can't stop talking about Prisma. They're jumping out of bed every morning. They've never done that before. They've never jumped out of bed to go to school. And my kid has already made their first friend."

+ +

And what I think we've discovered is absolutely kids can make friends virtually, and probably kids would have never questioned that actually. That probably felt natural to them. I think it's maybe adults that might question that. Now, does that mean that kids shouldn't have in-person friends? Of course, they should. And we would strongly encourage Prisma families to make sure their kids are enrolled in extracurriculars in their community and that sort of thing. We've surveyed the kids. Every single Prisma learner has said that they've made strong friendships at Prisma. For some of them, it's many friendships. For some of them, it's a smaller number of friendships.

+ +

And the other thing that's just going really well, I think, better than in-person school or bricks and mortar school is the community we've created. It's a really, really supportive community of kids. There hasn't been this sorting that I think happens in schools, particularly at the middle school and high school level of like, you're part of that clique, and you're part of that clique. And we're a little cooler than you are. Maybe just the nature of virtual makes it harder to sort kids like that. And there's not the natural time of in the cafeteria where you have to decide where you're going to sit and that kind of awkwardness.

+ +

Plus, we did a lot of legwork upfront of working with the kids to say: What kind of community do we want to build here? What are the values of our cohort? What are the expectations of our cohort? And I think that really helped to create a community that's just really kind and supportive, pretty uniquely kind and supportive, I think.

+ +

CHAD: Cool. That's great. And now that you're up and running and continuing to grow, looking ahead, what are you most worried about now as your next challenge?

+ +

VICTORIA: I think the biggest, hardest thing for us to figure out is how to keep the level of quality, great results. I haven't even mentioned it yet, but we are making sure that kids are progressing both academically in terms of these holistic skills. And on the academic front, we've seen really amazing growth. So the kids did a nationally recognized assessment at the end of last year and at the beginning when they joined. And they grew in math at 153% of expected growth and 174% of expected growth in reading.

+ +

So we've set a really high bar for ourselves. Kids are loving Prisma; 100% of kids said they're happier at Prisma than at their previous school. We have a really great Net Promoter Score, which means parents are really willing to recommend Prisma. We're seeing great growth in the kids. So how do we keep that super high bar whilst opening Prisma up to more and more and more kids? Because part of the attraction for us to offer a virtual model was the desire to be able to reach large numbers of kids if we came up with a model that really worked.

+ +

And I think through all of our research, one of the things we noticed is there are amazingly innovative schools out there. There are a lot of really innovative brick-and-mortar schools, actually, but they really haven't scaled. They tend to be...a few have scaled a bit, but they're still very limited in the number of kids that they can reach. And part of our thesis was that if you could do this online, just online is inherently more scalable. You're not dealing with buildings and everything that goes along with that.

+ +

But nevertheless, we still are a model where coaches are really important. So our ability to continue to find, train, and develop coaches that are really awesome I think will be a challenge, something we're going to have to get really, really good at. And then just making sure that we can strike the right balance because we also want to be a model that's as affordable as possible and that requires us to make sure that our costs are reasonable. So striking that balance and trying to use technology to be as efficient as possible, I think that is the next set of challenges that we need to deal with.

+ +

CHAD: Are you comfortable sharing how many students you have now?

+ +

VICTORIA: Yeah, I'm comfortable with that because the number we have was very much set by our own desire to grow carefully. So we have almost 90 kids. And we have a very long waitlist, basically.

+ +

CHAD: Well, that's bigger than my high school graduating class. [laughs]

+ +

VICTORIA: Oh, there you go. [laughs] It's funny because people react differently to that. Some people are like, "Wow, that's pretty big." It's not nearly as big as we intend to get. But we decided to cap. We wanted to be disciplined. We had way more demand than that. But further to what I said of quality first and delighting customers first, we said, "No, we'll cut it off at that point." And families have gone on to a waitlist, which is growing by the day. And then we'll be able to let more families in throughout the year.

+ +

We're small, but we're a lot bigger than we were in our first pilot year. And I think what's been really exciting is we're still somewhat early into the school year. But that level of delight, and excitement, and families just writing to us and saying, "I've never seen my kids so excited." And that's happening again. So it's really exciting to see that we're getting that again even though we have actually grown quite a bit relative to where we were.

+ +

CHAD: Well, congratulations on everything that you've achieved so far and in tackling these upcoming challenges.

+ +

VICTORIA: Thank you.

+ +

CHAD: If people want to find out more about Prisma and join or if they're interested in becoming a great coach, where can they do that?

+ +

VICTORIA: So the best place to go is our website which is joinprisma.com, so not prisma.com, joinprisma.com. We have a super detailed website, which I think is really informative. So that's a great place to start. You can also sign up for an info session there if you want to talk to someone live about Prisma. And then yes, we have job postings on there as well. And we're always super excited to hear from talented candidates. So that's the best place to go.

+ +

CHAD: And if people want to follow along with you personally or get in touch, where are the best places for them to do that?

+ +

VICTORIA: So we do have Prisma social media accounts, so Twitter is @joinprisma. And I'm not the most active person on social media. My husband is much more active, so they may want to follow him. He's Alain Chuard. I presume his Twitter handle is @AlainChuard, C-H-U-A-R-D. [laughs] And you can reach me if you email info@joinprisma.com, but you address it to Victoria. It will reach me, and I will reply.

+ +

CHAD: Awesome. And people can find all these links and everything in the show notes, which are at giantrobots.fm. You can also subscribe to the show there as well. And if you have questions or comments for us, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Everybody, thanks for listening and see you next time. Thanks, Victoria.

+ +

VICTORIA: Thank you. Thanks so much.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Victoria Ransom.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad interviews Co-Founder and CEO, Victoria Ranson of Prisma. Prisma is a stealth-mode education startup on a mission to reimagine the way children are educated. Their mission is to create a generation capable of solving the world's biggest problems by creating and running a comprehensive virtual learning program for kids in grades 4-8 that is very unlike any other traditional homeschooling program you've ever heard of.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Victoria Ransom, founder, and CEO of Prisma. Victoria, thanks for joining me on the show.

+ +

VICTORIA: Hi, thanks for having me.

+ +

CHAD: So, Victoria, before we jump into this great product that you have, why don't you tell people what Prisma really is.

+ +

VICTORIA: Sure. Prisma is a very comprehensive educational program for kids who are learning from home or from anywhere in the world. It is not at all like traditional homeschooling because we provide kids with a very social experience. Kids are part of a cohort where they're meeting live with other kids every single day and collaborating with them on projects, and learning from each other, and discussing. And we provide coaches who are there every step of the way with the kids, providing them with rich feedback, helping to bring out the best in them, providing really engaging, live learning experiences.

+ +

So it’s not traditional homeschooling, although it has a lot of the really great benefits of that with the flexibility and the ability to learn from wherever you are. But we're equally not like typical online schooling, which I would say has tended to be more of an approach of taking traditional school and bringing it online. So there's still a concept of lectures, and grades, and textbooks. They may be electronic in nature, but they still resemble textbooks.

+ +

The Prisma curriculum is very different. It's rooted in learning through doing and project-based learning, and applying learning to the real world, and allowing kids a lot of choice. So they're ideally always learning through the lens of something that interests them and allowing them to go at their own pace. So a lot of the best practices from some of the most innovative bricks and mortar schools we're bringing to an online environment. And then, of course, we're very different from bricks and mortar schools because it is a virtual program where kids can learn from anywhere.

+ +

So we think it's a new approach to education that is really uniquely flexible, really prepares kids. We're very focused on preparing kids for the kind of world they're going to live in. The world is always changing rapidly. But I think this generation of kids is going to experience a future that's unlike anything we've ever seen in terms of the level of shift and change, AI being one of the reasons.

+ +

If you look at studies that look at the future of work, I think some studies we've read say 65% of today's elementary school kids will work in jobs that are yet to be invented. So, how do you prepare kids for that kind of future? And so, we're very focused on giving kids the holistic skills and the mindset that they will need to thrive in that kind of world. So yeah, that is Prisma in a very long nutshell.

+ +

CHAD: [chuckles] Obviously, I think we'd be remiss if we didn't talk about the context of where we're in, which is kids just went through a year or more where a lot of kids were remote for school. And did Prisma exist before the pandemic?

+ +

VICTORIA: It did in our minds very much so [chuckles] but not in reality. So Prisma arose out of our own personal needs. So my husband and I are the founders of Prisma. We've actually been entrepreneurs for most of our careers. After successfully selling a company to Google a few years ago, we said whatever we do next in our lives; we want it to be something that has the potential to have a large positive impact on society and on the world. And then struggled to figure out what that should look like because there are a lot of things that need solving in the world.

+ +

But we have three children, and as they approached school age, it really caused us to do a deep dive into how do we want to educate our kids? What do we think is the best approach to education? And from that, we started to formulate a vision by looking at all kinds of different schooling models, from homeschooling to micro-schooling to innovative bricks and mortar schooling. We developed a picture for how we wanted to educate our kids. But that really inspired us to create something that could be accessible to many more kids than just our own kids.

+ +

And so we had a good 18 months to 2 years of researching, ideating, thinking about the pros and cons of a virtual model. And then along came COVID, and at that point, we said, you know what? There's never been a better time to test out an innovative new approach to schooling, especially one that was always going to be home-based from the get-go. And so let's start ideating and dreaming about this, and let's just put it into action see how it goes. So it was born during COVID, but the roots of Prisma very much predate COVID.

+ +

CHAD: So, what was the actual timing there from when you decided to do something? When was that to you had the first students?

+ +

VICTORIA: Yeah, that was a whirlwind. [laughs]

+ +

CHAD: I can imagine.

+ +

VICTORIA: Yeah. So really, it was late March, I think of 2020, when we said, "We've just got to do this. The world is telling us to do this." To when we had our first kids in the door was early September. So between basically the beginning of April to the beginning of September, we incorporated, we refined our vision. The good news is we had a vision, and it was mapped out. We hired a curriculum team, hired coaches, created a website, found our first families, all of that.

+ +

And we launched Prisma very clearly with the families saying, "This is a pilot. We're trying something new here. Let's see how this goes." And we actually told the families, "Look, we're going to definitely run this until the end of December, the end of the year. And if it's not going really, really well, then we will suggest you go and do something better." But it went great. It's not to say our model is perfect. And we believe very much in constant improvement and constant iteration.

+ +

But in terms of kids loving school at a time, the national narrative was that kids were hating school, and they were falling behind, and parents were finding distance learning a disaster; we had kids that were loving school more than they ever had. And we surveyed kids, and that's why we know that. Parents were extremely happy. Everything was pointing to the fact that we really had found something unique that was really working. And so it turned from a pilot into something that we're now putting all the building blocks in place to be able to scale more broadly.

+ +

CHAD: School is a big thing, a big concept, and a very important one. Working so quickly in the midst of a pandemic, you know, launching any product is as much an art and finding what those first features need to be. How did you identify what that is and make sure you had something that was viable but that you could get done on time?

+ +

VICTORIA: I think that came down to...because obviously, our product is our curriculum and our model. We have a software development team and a product development team. And they are building the tools that we'll need to run our model. But when we first launched, we were piecing together different tools that already existed. So the initial product really was the curriculum and our model of education and the tools that we pieced together to make it work.

+ +

And I think the reason we were able to be successful is that we did a lot of groundwork in saying, what really matters? What is our perspective on what is the goal of this educational model? We got clear on that. What do we think are the values or approaches that really are critical to achieving that goal? And then using that as our Northstar.

+ +

So to be more concrete, we were really clear about two things in terms of why we were developing this model. One was we really wanted kids to love learning. We think they should love learning because learning is amazing, and it's exciting. And every kid is born with an innate desire to learn. And that if you want to bring the best out in kids, you want them to be excited about what they're learning. So kids loving learning was a very strong Northstar for us. And the second was what I already talked about before is developing an educational model that will really give kids the skills and mindsets they will need to really thrive in what is an exciting but uncertain future. And so that was the Northstar of why are we doing this.

+ +

From that, we developed a clear perspective on okay; if we want kids to love learning, how do we do that? And so it was things like making sure that kids have choice so they can apply their learning to things that really excite them, making sure learning is applied to the real world, so kids are never saying, "Why the heck do I need this?" Making sure that learning is hands-on as possible because we think kids just get more out of it, and learn more, and enjoy it more if they can really be hands-on and project-based. Making sure...I won't go through them all, but we have our sort of core curriculum values, making sure learning is happening in a community-supportive community.

+ +

And then the other thing we're really clear on is okay, what are these overarching skills or mindsets that we think are critical to succeeding in adulthood? And it was things like systems thinking and problem-solving, having a designer's mindset, which is this concept of being comfortable with iterating, and getting feedback, and putting yourself in someone else's shoes, being an excellent communicator and collaborator. Again, I won't go through them all. But we were just really clear.

+ +

I think we had a really strong foundation of why do we exist and what is our approach here? And that enabled us to then be really clear about things like, okay, we're not going to throw the kitchen sink in terms of everything that kids need to learn, no. We're more focused on overarching skills than checking the box on 1,000 different science standards that kids might need to go through.

+ +

So yeah, as you said, I think whenever you launch a product or a company, being able to narrow down because you can't offer everything you want to offer, being able to narrow down to what really matters is important. And I feel like we did a pretty good job with that.

+ +

CHAD: Awesome. What was the makeup of the initial team? You mentioned you and your husband. How did you split the responsibilities between you two, and then who else was involved?

+ +

VICTORIA: So my husband and I have been co-founders of several companies. And it's worked really well because we have very different skill sets. My husband has much more of a product mind. He's much more detail-oriented. And he has a real eye for design and user experiences and also a creative marketing mind. So that gives you a sense of where he tends to focus. And I've tended to focus more on people management and operationalizing businesses, being more that external spokesperson. And so that's how we have split. He's doing more of the software development and product marketing and marketing side of Prisma. And I'm more involved in the day-to-day running of the program.

+ +

Our first two very, very critical hires were curriculum developers, and Prisma would not be what it is today if we hadn't hired the two people that we hired. And they really balanced each other well because we hired Kristen, who had really deep experience in education. She had at a pretty young age founded her own charter school very successfully and just had such super deep experience in education, teaching, teaching teachers, training teachers, managing her own school.

+ +

And then we had Emily, who came from a really non-traditional background. She'd actually come up through the theater world, had done a degree at Harvard School of Education. And they actually had some good experience with working with professors at Harvard in innovative ways to assess, also, computer science education. And she's got a very out-of-the-box way of thinking. And between the two of those, it was a really great combination for us to turn what was a vision of a curriculum that Alain and I had created into something actually concrete.

+ +

And then the other critical hires were our first coaches. Again, we got super lucky in hiring just really fantastic coaches. And we've now realized hiring great coaches is a very fundamental part of what we do. And in fact, it will be one of our scaling challenges, I think. But again, we got really lucky with our coaches. And then, over time, we've hired operations people and product people. But I think that initial magic of the curriculum team and the coaching team was really important. We wouldn't be where we are today if we hadn't have hired those people, I think.

+ +

CHAD: Did you bring on the two curriculum team members full-time right away?

+ +

VICTORIA: We intended to, I think, when we were still incorporating the business. And all of this was happening in such a rush that I think we technically had to bring them on as contractors. But it was intended as a full-time role. Having said that, our hiring process asked them to sketch out in a fairly in-depth way or at least to sketch out in-depth pieces of what the ultimate Prisma curriculum would look like. So we did have a chance, I think, to test them out fairly well before we committed.

+ +

CHAD: So did you take investment to start Prisma, or did you self-fund it?

+ +

VICTORIA: We have self-funded. We're super lucky to be in the position to be able to do that, and we are continuing to self-fund. We had a ton of interest from venture capitalists; I think partly because we're somewhat proven entrepreneurs with other successes. And then also, because there was just suddenly a big spotlight on education and the belief that education might really shift.

+ +

But we have not taken funding because...it doesn't mean we won't ever. But we're very focused on being mission-first. And we're also very focused on growing carefully and thoughtfully. We think in the long run, we'll be far more successful if we really grow conservatively, at least initially, until we really feel like we've refined this and we know how to keep a really high level of quality and customer satisfaction while scaling. And I think our concern is that sometimes when you take outside capital that that capital might not be as patient. It might really push to grow faster than what we think might be the best approach. So thus far, we're just in the lucky position where we haven't had to take outside capital.

+ +

CHAD: I assume that you're on a traditional school schedule based on what you said about starting in September.

+ +

VICTORIA: We kind of are actually, which is funny because our initial vision for Prisma was to have it be year-round. And I think our families have been super open to so many innovative things. But the idea of having a summer break seems to be something that families don't want to give up on.

+ +

CHAD: [laughs]

+ +

VICTORIA: So I think our ultimate goal is that we'll be able to offer a summer program for those families that want to either go year-round or maybe they want to do the summer program and not do a winter program. And we do have kids already that are in the southern hemisphere, where that is desirable. But so far, we haven't tackled a summer program just because we're already tackling a lot. But we surveyed families, and they actually really wanted to mostly stick with the idea of having a summer, a more traditional summer break.

+ +

CHAD: But does that mean that you can't add students outside of that cycle, so you really truly have cohorts? Or are you adding people along the way?

+ +

VICTORIA: We're adding people along the way. We operate in five weeks cycles, actually. And each cycle has an overarching theme. And that's part of our goal of making things feel really-real world. And also, because kids have a lot of choice, we do want there to be some unifying factor to what they're doing.

+ +

And so examples of themes that we've done are cities of the future, hidden histories, which looked at U.S. history but really from the perspective of lessons we can learn, inventor studio where kids learned all about design thinking through being real inventors. We have a super cool theme right now called uncharted territories, which has got some really strong STEM learning but through the lens of space exploration and deep-sea exploration. And kids are working on an interdisciplinary project during that time. We have live workshops that are aligned around the theme.

+ +

And then they're also working on what we call missions. So math missions and writing missions, which again, are really honoring that idea of giving kids choice and allowing them to go at their own pace but just to make sure they're really getting the foundations they need in math and writing. But really, a kid could join at the beginning of any cycle.

+ +

CHAD: Okay, that's great. Is that a happy accident of the model, or was it intentional in terms of from a product perspective making sure that you could continue to add people and weren't locked in to a small set of initial users?

+ +

VICTORIA: No, that was intentional, although our original model that we launched with did not have five weeks cycles. It actually didn't have themes either. It was more trimester-based. We call them sessions, not trimesters. And so that was more of a model where we could have kids come in every trimester. And that's evolved to do these five-week cycles and themes.

+ +

And from the feedback we got in that first trimester, we evolved the model. And so, I guess we've now evolved in a way we could have even more frequent intakes. But yeah, I think it was very...for us not coming from the education world, the idea that you could only bring customers on board once a year that felt very foreign. So we've always had the idea of let's make sure we can onboard kids throughout the year.

+ +

CHAD: So what did the first families, I guess, the early adopters, what did they look like?

+ +

VICTORIA: They were a real mix, so some long-time public school families and private school families, some long-time homeschool families. It was a real mix. I think it was a mix. Now, the Prisma families, I would say, are very much bought into precisely what our model and our vision is. But that first set of pilot families, I think some of them, if you ask them honestly, would say, "School was a disaster because of COVID. We're willing to give anything a shot. We'll give this a shot." And I think what's been really surprising to some of those families is, wow, we actually really only thought we would do this for a year, and now we're continuing because it worked.

+ +

But it was a mix of families I'd say who had always really believed in a more alternative innovative approach to education but, for one reason or another, hadn't had the ability to test it perhaps because there were no schools like that in their neighborhood or because they just hadn't perhaps had the courage to try it out. So there was that set of families. There were families that had kids that would be probably said to be gifted and were just not being challenged in school and were a bit bored and not really living up to their potential that I think were attracted to give Prisma a shot.

+ +

There were homeschool families who really loved the idea of home-based learning but were looking for more community, a bit more support by having some structure and some coaches. And in some families where kids had not thrived in school because they had special learning needs. We even have kids at Prisma that have physical disabilities where physically showing up in school each day is really tough. And online learning just makes their life so much easier. So I guess the ultimate theme here is it was families for whom the more traditional bricks and mortar approach was maybe okay, but it wasn't wildly successful for their kids.

+ +

CHAD: You focus on particular grade levels or age range, right?

+ +

VICTORIA: Yes, four through eight right now, yeah.

+ +

CHAD: And you said, "Right now." [laughs] So why did you choose that age to focus on, and do you plan on expanding?

+ +

VICTORIA: Yes, we do plan on expanding. I think the first expansion will be to go up into high school grades. The reason we focused on fourth through eighth was twofold. One was that we just think parents are more open to experimenting with a new model at the elementary-middle school level than they are at the high school level, so there was that. Just because once you get to high school, parents and kids alike start to get more anxious about things like college admissions and perhaps become more risk-averse. But the other really big reason came from all the conversations we had with teachers. I didn't mention that when we hired for our first coaching roles, we got 1,400 applicants applying. [chuckles]

+ +

CHAD: Wow.

+ +

VICTORIA: And so we narrowed it down. I did not talk to 1,400 people, but I talked to a lot of teachers. And actually, we first started those conversations saying we were going to focus on high school. And we shifted our thinking in part because so many of those teachers said that they felt like fourth, fifth, sixth grade is a real turning point for kids in terms of their enjoyment of school and their confidence in their own abilities and part of the reason for that, not the only reason, is that testing starts to ramp up at that stage in schooling. But we just really felt like if we could catch kids at that point, before they'd sort of lost their enjoyment for learning and before they had started to internalize ideas like I'm not good at school, or I'm not good at math, or whatever it may be, that we could have the greatest impact.

+ +

The other thing is there is quite an unlearning process that kids have to go through when they join Prisma because we give them a lot of autonomy, and independence, and ability to make choices and have control over their schedule. And we ask them to write self-reviews. And when it's time for a Parent Coach Learner Conference, the learner leads that conference. And the earlier you can get kids, I think the easier it is to get them to adapt to that approach than when you get them later in their schooling where it's been drummed into them that you paint within the lines. You do what you're told. You do this in order to get good grades. And so that was another piece that attracted us to that age range.

+ +

CHAD: How old are your kids?

+ +

VICTORIA: Good question. So they are seven, four, and two. So they're not quite old enough for Prisma yet, so we're doing our own version of Prisma right now until our oldest is old enough for Prisma. And the reason we didn't go below fourth grade, at least for now, is we do think there is a limit to how young you can go and be successful with a largely virtual model, and so that's why we haven't gone below fourth. And so, our seven-year-old is being homeschooled. But we've also put together a community of other homeschool kids that she learns with several times a week and gets that socialization piece, so that's the cohort piece that we offer through Prisma. But yeah, she's definitely...she's in training to be a Prisma kid.

+ +

CHAD: How do you balance with both you and your husband working on Prisma, homeschooling a seven-year-old, the other kids? How are you balancing all of that?

+ +

VICTORIA: And just parenthood in general because this is our first time starting a company while having kids.

+ +

CHAD: Yes.

+ +

VICTORIA: We had a pretty long gap in between our last company and this. So the honest answer is we have hired a teacher for the homeschooling piece, so that helps a lot. And she's super capable, and she's really the frontline person for managing the community that we've developed. So the harder piece is not that so much; it's managing parenthood with entrepreneurship. [chuckles] I would say it's a work in progress. And ask me some days, and I'll say, "That's going great." And ask me other days, I would say, "It's not going so great."

+ +

We are really, really lucky that we can hire good childcare, so that helps a lot. But even if you have great childcare, I want to be involved with my kids. I love my time with my kids. There's also just so many decisions and things you need to be involved in with kids that you truly don't want to and should not outsource, whether it's as simple as like on my to-do list right now, is that the two-year-old's birthday is coming up, and I'm not going to outsource buying birthday presents or organizing a party. So that's on my to-do list.

+ +

So I would say relative to when we had our previous company which was really successful, and stressful, and busy but that was the only thing we had to worry about. Trying to manage a company and kids it's a lot of context shifting. But for me, at least, I'm very, very rigid about my time. So I will organize my schedule so that I finish at least at the latest by 4:00 p.m. each day, and that is my time with the kids. And I'm with them until they're in bed, and then I'll jump back online. But there's almost nothing that will interfere with it. And that's just how I've prioritized, and it's just really important to me. So it's setting priorities, I guess.

+ +

CHAD: Yeah, when we were setting up for the show, you said that you were in the office. So you separate home and work, and school places, I guess.

+ +

VICTORIA: Kind of. The office is a little built-out area of our garage, [chuckles] so I walk from the front door three paces into the garage. But it is separated to the extent that the kids are not running in at any moment. They don't really come here. But it's really nice. And I think a lot of parents have discovered that during this whole COVID work from home experience and with kids home too, it's really nice. Because not every day, but some days I can go in and have lunch with the kids because they're all around. And some days, I can pop over to Elle's classroom and see what she's doing and be involved and do a bit of reading with her and that sort of thing.

+ +

So I personally really love the efficiency of working from home, wasting no time with commutes, and also just the ability to be really flexible with my time. Maybe I will take an hour out in the middle of the day to do something with the kids, and then I'll make it up later in the evening because that's fine. I don't have that much going on in the evening anyway once the kids are in bed. So I personally really like that flexibility.

+ +

CHAD: So, turning our attention back to the product, you said that you got started piecing together existing tools on the tech side. And so, what were the first things that you started to replace in that stack? And when did you start hiring a tech team to do that?

+ +

VICTORIA: Yeah. So Alain, my husband, his background is product management. So we had product expertise already. We spun up a team of engineers, I think already by October or late October of 2020. So shortly after, we had officially begun the school year. And fortunately, these were engineers we'd worked with before in previous companies.

+ +

And the first thing we started to tackle actually was the live learning experience, so basically a replacement for Zoom. And that was partly because we felt like there was nothing available that really designed a live learning experience through the eyes of fourth through eighth graders, through that sort of demographic. And also, because the other product needs that we have that we're now tackling is everything we need to just manage the whole curriculum like a learning management system.

+ +

But our whole model was still too much in flux for us to want to focus on that right away. We needed some clarity about what the model would look like. Whereas the idea that we would always have a live learning component where kids would be online, there'd be a coach, but it would be very collaborative and interactive was very clear. We knew that wouldn't shift, and so that was the first piece we tackled.

+ +

And we've really tried to tackle a few different areas there. One is to make coaches really efficient so that they're not trying to focus on creating this really engaging learning experience while also having 15 different tabs open and trying to play this YouTube video. So we've basically created what we call Prisma LIVE, where our curriculum team can create these semi-scripted because we certainly let coaches deviate, of course, but experiences with chapters.

+ +

And there's a lot of shifting of the way the room looks, and the way the kids are organized, and the visuals. Because a lot of the research we looked at is that fatigue, Zoom fatigue, actually comes from staring for a long time at the same scene of this person you're talking to or these people you're talking to. So to make it visually stimulating and appealing for kids and seamless for coaches so they don't need to worry about managing all these different aspects of the workshop. They're just clicking through and focusing on making sure kids are participating.

+ +

And participation was another thing we really focused on. We do a lot of breakout rooms because we want kids to be collaborating in small groups. So we wanted coaches to be able to instead of having to jump into breakout rooms and interrupt the flow and not know who needs help, the ability for them to stay in the main room and be able to listen in and get an oversight for how things are going in the various breakout rooms and jump into those rooms where it's clear that they're needed perhaps because there's not much going on in there. There's not much discussion, or maybe there's a lot of very animated discussion. So that was an area we focused on and then just making it more kid-friendly and more fun.

+ +

And every cycle at Prisma ends with Expo Day, where kids present the project they've been working on to the whole Prisma community, parents, and grandparents. And one of the real downsides of virtual in that experience is that these kids are presenting these amazing things, but there's limited ability for people to express how amazing they think it is. And so just visual ways of people being able to express their emotions and their reactions during live workshops is another thing. We've focused on fun avatars that would appeal to kids and that sort of thing. So that has been our first focus.

+ +

Now we're heads down on the learning management piece. Like, what are the building blocks we need to put in place in order to be able to keep the customer experience really high whilst making our coaches more and more effective and more and more scalable?
+CHAD: So as you got started or when you were thinking about getting started, what were you most afraid of?

+ +

VICTORIA: Well, aside from the fact that we're trying to pull this off really quickly and being afraid that this would be a complete failure, aside from that, honestly --

+ +

CHAD: Just that small thing. [chuckles]

+ +

VICTORIA: Yeah. I think the thing that we were most nervous about, and I think it's the thing we probably get the biggest question about, and yet it has proven to be the thing we really didn't need to worry about, is socialization. And to what extent can kids build friendships virtually? To what extent can they build community virtually? To what extent can they meaningfully collaborate and learn together virtually? And I think we went in hoping that all of that was fully achievable but not being quite sure about it.

+ +

And honestly, the signs were so quick that that wasn't going to be an issue for us. Already in orientation...we organized this really fun orientation mostly oriented around making sure kids were excited and got to know each other. And so quickly, we started hearing from parents, like, "Oh, my kid can't stop talking about Prisma. They're jumping out of bed every morning. They've never done that before. They've never jumped out of bed to go to school. And my kid has already made their first friend."

+ +

And what I think we've discovered is absolutely kids can make friends virtually, and probably kids would have never questioned that actually. That probably felt natural to them. I think it's maybe adults that might question that. Now, does that mean that kids shouldn't have in-person friends? Of course, they should. And we would strongly encourage Prisma families to make sure their kids are enrolled in extracurriculars in their community and that sort of thing. We've surveyed the kids. Every single Prisma learner has said that they've made strong friendships at Prisma. For some of them, it's many friendships. For some of them, it's a smaller number of friendships.

+ +

And the other thing that's just going really well, I think, better than in-person school or bricks and mortar school is the community we've created. It's a really, really supportive community of kids. There hasn't been this sorting that I think happens in schools, particularly at the middle school and high school level of like, you're part of that clique, and you're part of that clique. And we're a little cooler than you are. Maybe just the nature of virtual makes it harder to sort kids like that. And there's not the natural time of in the cafeteria where you have to decide where you're going to sit and that kind of awkwardness.

+ +

Plus, we did a lot of legwork upfront of working with the kids to say: What kind of community do we want to build here? What are the values of our cohort? What are the expectations of our cohort? And I think that really helped to create a community that's just really kind and supportive, pretty uniquely kind and supportive, I think.

+ +

CHAD: Cool. That's great. And now that you're up and running and continuing to grow, looking ahead, what are you most worried about now as your next challenge?

+ +

VICTORIA: I think the biggest, hardest thing for us to figure out is how to keep the level of quality, great results. I haven't even mentioned it yet, but we are making sure that kids are progressing both academically in terms of these holistic skills. And on the academic front, we've seen really amazing growth. So the kids did a nationally recognized assessment at the end of last year and at the beginning when they joined. And they grew in math at 153% of expected growth and 174% of expected growth in reading.

+ +

So we've set a really high bar for ourselves. Kids are loving Prisma; 100% of kids said they're happier at Prisma than at their previous school. We have a really great Net Promoter Score, which means parents are really willing to recommend Prisma. We're seeing great growth in the kids. So how do we keep that super high bar whilst opening Prisma up to more and more and more kids? Because part of the attraction for us to offer a virtual model was the desire to be able to reach large numbers of kids if we came up with a model that really worked.

+ +

And I think through all of our research, one of the things we noticed is there are amazingly innovative schools out there. There are a lot of really innovative brick-and-mortar schools, actually, but they really haven't scaled. They tend to be...a few have scaled a bit, but they're still very limited in the number of kids that they can reach. And part of our thesis was that if you could do this online, just online is inherently more scalable. You're not dealing with buildings and everything that goes along with that.

+ +

But nevertheless, we still are a model where coaches are really important. So our ability to continue to find, train, and develop coaches that are really awesome I think will be a challenge, something we're going to have to get really, really good at. And then just making sure that we can strike the right balance because we also want to be a model that's as affordable as possible and that requires us to make sure that our costs are reasonable. So striking that balance and trying to use technology to be as efficient as possible, I think that is the next set of challenges that we need to deal with.

+ +

CHAD: Are you comfortable sharing how many students you have now?

+ +

VICTORIA: Yeah, I'm comfortable with that because the number we have was very much set by our own desire to grow carefully. So we have almost 90 kids. And we have a very long waitlist, basically.

+ +

CHAD: Well, that's bigger than my high school graduating class. [laughs]

+ +

VICTORIA: Oh, there you go. [laughs] It's funny because people react differently to that. Some people are like, "Wow, that's pretty big." It's not nearly as big as we intend to get. But we decided to cap. We wanted to be disciplined. We had way more demand than that. But further to what I said of quality first and delighting customers first, we said, "No, we'll cut it off at that point." And families have gone on to a waitlist, which is growing by the day. And then we'll be able to let more families in throughout the year.

+ +

We're small, but we're a lot bigger than we were in our first pilot year. And I think what's been really exciting is we're still somewhat early into the school year. But that level of delight, and excitement, and families just writing to us and saying, "I've never seen my kids so excited." And that's happening again. So it's really exciting to see that we're getting that again even though we have actually grown quite a bit relative to where we were.

+ +

CHAD: Well, congratulations on everything that you've achieved so far and in tackling these upcoming challenges.

+ +

VICTORIA: Thank you.

+ +

CHAD: If people want to find out more about Prisma and join or if they're interested in becoming a great coach, where can they do that?

+ +

VICTORIA: So the best place to go is our website which is joinprisma.com, so not prisma.com, joinprisma.com. We have a super detailed website, which I think is really informative. So that's a great place to start. You can also sign up for an info session there if you want to talk to someone live about Prisma. And then yes, we have job postings on there as well. And we're always super excited to hear from talented candidates. So that's the best place to go.

+ +

CHAD: And if people want to follow along with you personally or get in touch, where are the best places for them to do that?

+ +

VICTORIA: So we do have Prisma social media accounts, so Twitter is @joinprisma. And I'm not the most active person on social media. My husband is much more active, so they may want to follow him. He's Alain Chuard. I presume his Twitter handle is @AlainChuard, C-H-U-A-R-D. [laughs] And you can reach me if you email info@joinprisma.com, but you address it to Victoria. It will reach me, and I will reply.

+ +

CHAD: Awesome. And people can find all these links and everything in the show notes, which are at giantrobots.fm. You can also subscribe to the show there as well. And if you have questions or comments for us, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Everybody, thanks for listening and see you next time. Thanks, Victoria.

+ +

VICTORIA: Thank you. Thanks so much.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Victoria Ransom.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Z6vA0kku + + ]]> + + Chad Pytel + Victoria Ransom + + + 397: Driven By Fulfillment with Natalie Nzeyimana of Harbour + https://podcast.thoughtbot.com/397 + fd6cef63-e6e5-4d81-b139-50e9af5369be + Thu, 14 Oct 2021 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + At harbour.today, Natalie Nzeyimana and her team are helping people build holistic resilience. On this episode, she and Chad talk about building the app at the beginning of the pandemic when she witnessed herself and others feeling like they were close to drowning and feeling really unmoored. + +Harbour is a space for people to anchor themselves, find clarity, and set sail. The community offers one-to-one coaching, workshops, a course, and a daily check-in tool. + 39:37 + no + + + At harbour.today, Natalie Nzeyimana and her team are helping people build holistic resilience. On this episode, she and Chad talk about building the app at the beginning of the pandemic when she witnessed herself and others feeling like they were close to drowning and feeling really unmoored. +Harbour is a space for people to anchor themselves, find clarity, and set sail. The community offers one-to-one coaching, workshops, a course, and a daily check-in tool. +harbour.today (https://www.harbour.today/) +Instagram (https://www.instagram.com/harbour.today/) +Twitter (https://twitter.com/natalieisonline) +Lunchclub (https://lunchclub.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And today, I'm joined by the founder of Harbour, Natalie Nzeyimana. So, Natalie, thanks for joining me. +NATALIE: Thanks for having me on. +CHAD: So tell me a little bit about what Harbour is. +NATALIE: Sure. Harbour is a space for people to anchor self, find clarity, and set sail. We offer one-to-one coaching, workshops, a course, and a daily check-in tool. Harbour was built at the beginning of the pandemic when I witnessed within myself, and the people I knew who I'd worked with, friends, family, just a lot of us felt like we were close to drowning and feeling really unmoored. And so, it began as a course to think about the ways we could use holistic strategies to anchor ourselves and set sail. And from then, from November 2020 to now, it's become a product. +CHAD: You started in November. And I know we first met in London a while ago. You were teaching yourself to code working on an education product if I remember right. And we got together at Google Space there and paired for a little bit. Did you code Harbour yourself? +NATALIE: It feels like another lifetime. +CHAD: [laughs] +NATALIE: I think life before the pandemic and life after the pandemic; there’s a real line there. I've done quite a bit of the coding myself. However, I've also used a lot of no-code solutions to create MVPs. They've been amazing at helping me scale, helping me test out ideas incredibly quickly. +And so one of the interesting things about juggling doing client work, and then also building the back end, and building the module, and then building the design work, and thinking about content juggling all of these different pieces, is that equation of do I invest time in HTML, or do I invest time in machine learning that's going to help me scale? And making all of those intricate decisions has been really, really interesting because, of course, I want to make everything myself. But these no-code solutions have enabled me to test hypotheses so much faster so that I can save time in the long run. +CHAD: Well, tell us a little bit more about what the product is today and what you went through to get to this point. +NATALIE: Sure. So initially, I just posted on LinkedIn to see who would want to join the course. I had a really simple Squarespace page, and then that evolved into a Typeform which I would use with clients to help them track progress and checking in with their chakras every day. And so, the way that Harbour works is that we do an energy review based on the seven in-body chakras. +And so, for anyone who might be unfamiliar with this terminology, the chakras are...well, there are different schools of thought on this. They are a system for either focusing during meditation depending on where you sit in terms of your feelings towards energy bodies. They are a subtle body energy system of themselves. And what I find incredibly helpful for those chakras is that they help people map their energy in a way that I haven't found anything else does effectively. +So starting from the root chakra, which is the base of your spine, you can ask yourself, am I feeling safe? Am I feeling grounded? Am I feeling as though my material needs are met? +Traveling up towards your reproductive area, you've got the sacral chakra which governs your sense of feeling as though you can desire the things that you desire in the world, feeling as though you are sensual. You're able to experience pleasure. You're able to be creative and playful. +And then up to the solar plexus, which is around your navel area, governs the sense of personal power, empowerment, will, feeling as though you're able to go after your goals with chutzpah and energy. +And then moving into the heart chakra, which governs this idea of do I feel as though I'm open to receiving and giving love freely? +And the throat, do I feel as though I'm an open conduit for the truth of who I am? Do I feel as though I'm able to express myself fully in the world? +And then into the third eye, which governs your intuition. Do I feel as though I'm able to trust my intuitive leads and to move with grace and ease, trusting and able to go with the flow? +And then finally, we have the crown chakra, which governs do I feel open to receiving divine wisdom? Do I feel as though I'm in this world on my own and there's nothing but pure materiality? Or do I feel open to receiving what some people might call God or Allah or the Tao? Whatever your orientation is, do I feel open towards receiving that kind of wisdom? +What's really beautiful about the chakras is that they've been used by ancient Chinese, ancient Egyptians, Tibetans, Sikhs, multiple traditions, and indigenous systems. And so there's kind of this lovely thread of people around the world thinking about how energy moves through our minds, bodies, and spirits. But that's quite a lot. So we just ask seven questions every day. +CHAD: So I have to admit I was not...and my first exposure to this is this conversation. So is this something that you have been aware of and practicing prior to working on Harbour, or is it something that you found which then led you to the creation? +NATALIE: Definitely the latter, the latter. So I went through a pretty gnarly, dark night of the soul and just had this huge existential crisis of wondering what am I here to do? Why am I here? What's my purpose in life? I don't know if other people might resonate with this, but kind of feeling that you make these huge or not so huge career goals, and then you reach them, and you still feel like something's missing. And in my quest to understand what that missing piece might be, I came across chakras, and I found it incredibly helpful. +I think people who do yoga might be aware of this because they often come up to yoga. Physical movement is often a way of realigning and balancing the chakras. So there are specific movements or specific asanas that you can do to balance out your root chakra or balance out your Sacral Chakra, which is great because it's kind of like all of these different hacks you can do to bring your mind, body, and spirit back in line. And that's why I think I loved it because when I encountered a lot of other systems or other approaches, it just all felt a bit ephemeral and like I couldn't grasp it. But there was something about chakras that really spoke to the budding engineer within me because I was like, wait, you can just hack yourself into alignment? This is great. +[chuckles] +CHAD: So this is something you do daily. +NATALIE: Well, something I try to do daily. [chuckles] +CHAD: Okay. I meant, is this something one does daily? [chuckles] +NATALIE: Yeah. Ideally, yes. Because it's like anything else that we do, if you want to maintain a certain level of well-being or perhaps a certain level of fluency, let's say, for example, in a language whether that's a programming language or the spoken language, you need to practice it every day. +And so, with chakras and aligning one's mind, body, and spirit, it feels as though the stakes are slightly higher when we're in the middle of a pandemic, and there's so much uncertainty, and all of our lives have kind of been exposed to so much change. But yes, daily is optimal. Daily is, at least at Harbour, the bare minimum. +What are some things that you do every day to balance your mind, body, and spirit? You may be aligning your chakras without quite realizing that you are. +CHAD: Yeah. So I run every day. And I've often described that as that's my meditation. So I find that that really does wonders for reducing my overall stress. I do it in the morning before starting my day. And so, I think it really sets the foundation on which the rest of the day is built for me. And it wasn't until I made the commitment to do it every day. And now I run long distance enough where I need to take a rest day once a week. But when I made the commitment to do it every day, it really did change my relationship with running. +NATALIE: That's so interesting. I was thinking about Kazuo Ishiguro's what I think about when I'm running or something along those lines. He's written this great book. And I know several people who run and have spoken of its incredible meditative qualities. And I think that's a wonderful way of connecting with yourself or creating space to connect with yourself. +I also wanted to touch upon something that I know that we tend to move towards or perhaps even a dichotomy: do we meditate to relieve stress, or do we meditate to get closer to our divinity? And so one of the things at Harbour that we try to do is we try to help folks shift from meditating to relieve stress to meditating to connect with one's divinity, and that way, the stress doesn't become as prominent a factor for which meditation is there to alleviate. +CHAD: What do you mean by divinity in this case? +NATALIE: Yeah, great question. Very controversial. [laughs] I mean, it's 2021, and the least cool thing you could possibly do in an engineering environment is talk about God and the divine. I think there is a really interesting choice point we're at as a collective where there is an increased awareness of consciousness. So there's a lot of language in at least the tech community, from my experience, whether you've got things like Burning Man or just a lot of products and offerings out there, which are there to raise your consciousness. +One of the really tricky things about raising your consciousness...and in the chakra system, we do that through something that's called a kundalini awakening, which is where your consciousness does raise from the root chakra all the way to the crown. As your consciousness raises through the chakras, coming from the Indian tradition, what happens is your life force, your consciousness moves through your chakras, and each chakra it touches upon triggers a mini awakening. +So, for example, as your life force is moving through your root chakra, anything that may have happened in your childhood, anytime that you may have experienced any aspect of material instability, let's say you lost your job or you had a partnership fall apart, or any time where you felt like your world completely crumbled, that will likely be triggered when you're going through that mini awakening in that root chakra. +I mentioned divinity because it feels as though there are two paths we can go down. We can either go down the path of I am raising my consciousness. I am the master of my own destiny. I know what I am here to do in life, and I'm in control of my own awakening. Or we can go down another path which is far trickier, which is sort of saying, "At every point in every day, I choose to surrender to the wisdom that is far beyond me. And I'm going to trust the signals and the science that I receive that they are aligned with my highest good." +One of these paths is more egoic, and the other one is more surrendered. That's not to say that we don't need an ego. But the ego can get into really tricky territory when you're doing this kind of alignment and awakening work, and it can really do a lot of harm. And I don't say that through judgment. I say that because I've been through the wringer with a lot of ego deaths. +And so, one of the safest ways to mitigate that risk of the ego taking over is to surrender to something that is far more wise than you. Perhaps you don't resonate with the idea that there is only one creator, and that's fine. But perhaps just from a logical point of view, it does seem to make more sense to surrender to the fact that there's something that knows more than I do at any moment. +CHAD: So this is some really big stuff. +NATALIE: Oh yeah. +CHAD: Before we get much further into it, I think for listeners who want to learn more or are interested in what they're hearing and want to give it a try, where do they do that? Where do they find Harbour? And what is it going to look like? +NATALIE: Sure. So you can follow us at harbour.today online on our website also on Instagram. And I'd love to invite your listeners to try out our 30-day trial, where if you complete 30 days of your chakra daily check-in, you'll receive access to our platform with activities, reading prompts, and also different course materials for free for a whole year. And I know I'm probably giving this away to a lot of people because all the engineers I know are very disciplined, [laughs] and they'll do this 30-day streak like it's a GitHub streak. +CHAD: [laughs] +NATALIE: So I'm shooting myself in the foot a little bit. But I'm really keen to offer folks who are asking these questions who are thinking about what am I here to do? Is there more? How do I engage with literature that could help me ask these questions more deeply within myself? And the daily check-in and the learning platform is a really simple way to do that. +CHAD: Great. That's great. I hope folks check it out. So, in addition to the daily check-in, you just gave some hints on what is actually on the platform. There are reading prompts and those sorts of things. Is there more than that as well available? +NATALIE: Definitely. So we are launching a monthly course on October 6th, and then the next one will be in January when we come back from the break called Organic Cycles. And the purpose of this course is to help people who are thinking about launching something. So you may have a side project that you're thinking about launching or perhaps a hobby that you feel like you want to take up, or maybe you even want to become an entrepreneur full time. But you're a little bit overwhelmed by what might be involved by that. +And so at Harbour, we're real big believers in cyclic, iterative, sustainable growth. And so, we use the moon cycle for our sprints. We use it for measuring our tasks. And in Organic Cycles, you will learn about the moon. You'll follow the Moon Phases. And let's say, for example, you want to start a new business selling socks. [laughs] On the new moon on October the sixth, you will join us, and you will tell us all about your sock business. And we'll listen, and we'll make a plan as other people in the cosmic plan. +In the first quarter, we'll start thinking a little bit about why do you love socks so much? Where does that come from? And what are the small steps we can make together to help you grow your sock business within this moon cycle? Which is, of course, 28 days. On the full moon, we'll celebrate all the progress that you've made with your sock business. And together, we'll figure out the next steps. In the last quarter, we'll think about hmm, what were the experiments making the sock business so far that worked really well? What are the ones that didn't? Which ones would you like to take into the next cycle? And on the next new moon, we'll start all over again. +And so it's very similar to an agile workflow, except you're learning about the moon. And the reason why I believe that's important is because a lot of our day-to-day lives are just so focused on abstract entities and not necessarily the natural world. And so a lot of the prompts in the daily review for Harbour are getting outside, all sorts of different things that reconnect you to nature as a way of rewilding you. +So yeah, I'd really love for folks to come on board. If you have any experience with agile, even if you don't and you're just curious about the moon, and want to find out a little bit more about the stars and anything natural, and meet other people who are curious about energy and ideation and how to create cycles which feel more organic, we'd love to have you along. +CHAD: I really like the sound of this in that it's a structure to anything. A group environment where you're helping each other is great. Layering on the information about the moon and everything adds an additional element of interest to it. I'm just a big believer in being intentional about what we do in our businesses and in our lives. So any structure that can help people be intentional about what they do, I think is going to help people and help them be more successful than if they just don't have a plan and aren't intentional, aren't consciously thinking about what they want to achieve, and what they want for themselves. And helping people do that, I think, is great. +NATALIE: Definitely. And I definitely have been on both sides of that coin, either having too much structure or no structure at all. And I think there's something really beautiful about naming things in ways that feel soft and ways that feel different to people so that they can access that idea and be playful with it and be creative. Because I know that for a lot of people who we work with, post-burnout, folks who are incredibly structured. The Harbour client is a recovering Type A like me who has probably been an overachiever at school and has probably been incredibly structured in their lives but didn't really know how to let go and didn't really know how to create fluidity and flow in their life. +And so one of our tag lines is between discipline and surrender and a devotion to flow. And flow is made possible through that playfulness, and through that structure, and through those rituals, and through that surrender, which is really fun. And it's always really, really fun to see people connect the dots and see, oh, it's quite interesting. Like on full moons, I do have a lot more energy. Or on the new moons, I do feel a little bit more restful, and giving people prompts to add self-care and add meditation to their existing structures. +CHAD: So this might be an overly practical question, but I'm curious how you manage time zones. +NATALIE: [laughs] With naps. +[laughter] +CHAD: Okay. Fair enough. +NATALIE: No, really, I do. I have naps. And I really love work...as you know, I've been working with folks in the U.S. for the last ten years. And I really enjoy it because I think it feels like transporting to a different environment. So, yeah, just a nap, and then I wake up, and I'm in a different country. It's great. +CHAD: [laughs] So it's almost like you've actually traveled then. +NATALIE: Exactly. Exactly. +CHAD: Hopefully, a little less jetlag. +NATALIE: Yeah, it's really great. What about in your work? I know that you're one of the most organized and structured people I've ever met. But sometimes, when I'm in Notion, I'm like, what would Chad do? [chuckles] But how do you find the balance between order and structure and allowing yourself the space to find flow and surrender even as a leader, even when you're building a product? +CHAD: Well, thank you for the compliment. I appreciate it. Let me preface by saying I think that nothing ever stays the same. And so what I do today and what's working for me today is probably pretty different than three years ago because our teams are in different places, and the people I work with are different, and I'm in a different place. +So the thing that's working for me now is putting times blocked off on my calendar where I want to either...it's a regularly scheduled time. And I have one on Thursday; it's from 2:00 to 5:00 p.m. It's just blocked off, and it just says, "Focus time." And each week, then I decide in advance what I'm going to be doing during that focus time. And it might be exploring something new. It might be working on something specific. And then, when I need to accomplish something else, making sure that I block off the time on the calendar. And so that's working for me now. And it's not what I used to do. I used to be much more freeform. Nowadays, if I don't block off the time, I lose it. +Previously, I could maintain a lot of free time on my calendar and use that as the time I was doing things. And as we grew and as I was working with people more across all of thoughtbot, across many different time zones, I needed to be much more conscious about what my scheduled time actually looked like and make sure that I'm scheduling time to work on things more freeform. +NATALIE: Yeah, definitely. That's so helpful. And I like the idea of time blocking. I've been trying to do a little bit more of that. What's interesting, too, is as Harbour grows and the product grows, and thinking about scaling and trying to anticipate things before they happen, even though you can't anticipate everything, one of the exercises I've been thinking about is what would it feel like to have a team of this many people and meditate on that idea and see if it feels right? And do I necessarily need to have a team that looks like X or a team that looks like Y? And trying to meditate into what that experience would be before making the decision. And I'm wondering if, through your experience having run this global company and having scaled it over more than a decade, what are some of the things that you've done to pre-pave and to support the sustainable scaling of the business? +CHAD: I think thinking things through in advance is very important. And I don't say the next thing I'm about to say because it's not important because I think that it is very important, and I certainly do it. But I've also come to grips over the years with the idea that no matter how much we plan, it's not going to go like we plan. And so there's this interesting balance between planning too much and reacting to what's happening. +And I'll come back to intentionality. And the way that I talked about it at thoughtbot is letting fulfillment be our North Star. So we shouldn't be doing things just because we think they'll be good business decisions or because we think they're the right thing to do for some arbitrary reason. We should be driven by what we want to be doing in our work and what kind of company we want to be, and being fulfilled in our work. +And when we're faced with a decision to make about who we are, or what we do, or how we're going to approach this, letting it be driven by fulfillment is very powerful. Because it means that likely what everyone wants from their work is not so different from one another, especially when we curate a team of people that want to work together for our working lives what might be. It's probably not so different from each other. +So that's also very powerful because it means that I don't need to be the one to make all of the decisions. Other people can make those decisions around who we are and what we'll do, and which direction will head in. And they'll very likely be what will be fulfilling to the rest of the team as well. And so it sort of democratizes that decision-making in a way which is more resilient and then can be more flexible. As our best-laid plans start to go awry, we're making decisions based on fulfillment. And I think that allows us to be resilient. +NATALIE: Yeah, that's so helpful. +CHAD: Because so much of what we've tried, particularly when we intentionally try to grow, so many of the decisions that have made thoughtbot successful we weren't making them for business reasons, we were making them because -- +NATALIE: They felt right. +CHAD: They felt right. We were the first consulting company in the world to switch to Ruby on Rails. We didn't make that decision because we thought Rails was going to be popular. We made it because, as developers and designers, we were more fulfilled using this new thing, Rails, than using PHP or Java. And, in fact, if we had been focused on what we thought would be the successful business thing, we might never have chosen that because it can feel very risky because you're choosing something entirely unknown. +So the opposite example is we've tried very hard to grow over the years non-organically geographically. So someone is moving to this area, or we are going to hire someone in this area. And we're going to grow into this area. And it's not driven necessarily by fulfillment. And in a lot of those cases, it's been very difficult, or it's outright not been successful. And so, being able to react to those situations and adjust has been critical for our long-term success. +Another word I use often is grit. And grit, for me, means we fail a bunch but we stay at it because we are driven by...what's driving that is fulfillment. So even if we really believe in it, even if we've failed in execution for business reasons or something like that, we tend to stick with it over the long term and just try a different way. +NATALIE: Yeah, I hear that. There is so much grit that's required to sustain something over a long period of time. And it feels like quite an incremental grit as opposed to huge pushes of energy that we might witness in different business models, for example, venture capital. And having been in the whirlwind of the VC world a little bit and now building what I hope is a more sustainable model, the grit is very moment to moment. It's continuous. Each task, each decision, it's a soft resilience that kind of grows over time as opposed to having to wield huge amounts of chutzpah to get through this investment cycle. Do you know what I mean? +CHAD: I do, and I think that has a flip side as well, which I try to be conscious of but don't always do a good job with. I tend not to project too far; that’s one side. And then the reverse is also true, which I tend not to celebrate successes enough. I tend not to reflect on the past too much because I'm on to the next incremental improvement pretty quickly. That has benefits because when you have a down day, tomorrow is a new day. It's a brand new day. But that has downsides too, which is when you have a great day, [laughs] you're on to the next thing the next day as well, at least for me. I move on very quickly. And like I said, I think that has its benefits, and it has its downsides. +NATALIE: What are your rituals for celebrating both personally and professionally? How do you celebrate yourself and the ways that you've grown? And how do you celebrate the business that you've grown with others? +CHAD: Just being honest, I probably have not...I do not have rituals. And I think this is where having good partners, or other members of my team has been helpful because knowing that this will be my tendency, having other people backing me up to recognize the successes or to call me on when I’m moving on too quickly or something like that has been helpful. +NATALIE: Yeah, definitely. +CHAD: Are you working on Harbour solo right now, or are you working with others? +NATALIE: Sure. Sometimes I work with a really wonderful ayurvedic practitioner called Sriram, who was an engineer for 15 years before he became an ayurvedic practitioner. So completely similar to you in that thought about going about and finding a co-founder or partnering with someone. And then I just had this really lovely chat with someone on Lunchclub. And we ended up talking about chakras for an hour and also coding. And I was like, this is my dream. [laughs] I get to talk about chakras, and I get to talk about product. This is great. And so, I work with Sriram sometimes on client work. Normally, the split is that he takes approximately a third of the client sessions, but we work on the one-to-one coaching. +And so, I'm your accountability coach. And we're hiring more now, which is really exciting. And I'll do the weekly reviews with clients, and then Sriram will put together the ayurvedic program for the client. So that's always really great fun. And I'm also working with a wonderful designer based in San Francisco called Christina. And yeah, so the three of us...Sriram has his own practice, and Christina has her own agency. But there's a lot of collaborative work that's happening there. +And I'm currently onboarding more coaches, which is exciting and very necessary because I came to a choice point, and I said, do I want to study chakras and become qualified? And I realized I didn't. I wanted to talk to all the people who knew about chakras and who were qualified, and so that's been a lovely experience onboarding them, and onboarding therapists, and onboarding other personal development coaches who are going to be able to serve clients as we scale. +CHAD: Nice. You mentioned Lunchclub many times in the story of Harbour on the website. I have never used Lunchclub. But I heard of it before. And if folks haven't heard of it, what's the pitch for Lunchclub? +[chuckles] +NATALIE: It's LinkedIn as you'd want it to be. +[laughter] +CHAD: Oh, that's great. That's great. +NATALIE: I think Lunchclub gets rid of all of the bravado and all of the stuff on LinkedIn because I think a lot of us do really struggle with self-promotion online. But at the same time, we want to connect with people. And we want to have real conversations that hopefully lead to more conversations or more opportunities for both parties. +And when I started on Lunchclub about a year and a half ago, it was just an incredible way to connect with people around the world. I'd just moved into a flat. I was living on my own in the middle of the pandemic and in the middle of the lockdown building product. And I thought, I really need to chat to people because I really enjoy doing that. +And through 45-minute conversations, you get matched by their little magical AI, and you connect with people who might be related to the interests that you have. And you can build streaks. And the more streaks you build, the more points you get. And the more points you get, the more you can choose who you connect with based on geography and business development goals, et cetera. Well, even if you do choose I want to meet an investor or I want to meet a Biz Dev specialist, this isn't really a sales call or an investment pitch. It's just I want to increase the likelihood that the person I meet will be aligned with where I'm trying to get on my journey. +CHAD: Well, the pandemic has been a really difficult time for everybody, parents, and of which I count myself in that. In particular, seeing it across thoughtbot, obviously, a trend is the people who live alone had an especially challenging time during the strictest of the lockdowns that were happening. And it was challenging. We saw a lot of people struggling. And because we were all remote, you're remote all day working. You don't necessarily want to be reaching out to people remotely, just that energy there. And I think that's maybe where Harbour comes in is solving that energy problem that I think many of us are feeling now. +NATALIE: Definitely. I think what happened over the last year and a half, two years, has created a tectonic shift, but I think also a portal because it's forced us to reckon with ourselves in ways that perhaps we had been ignoring, in ways that we didn't know we needed to, in ways that we've been forced to. And it can be really scary. And even as an adult, that's weird. It's weird to feel that scared as an adult. It's weird to feel that displaced as an adult. It's weird to feel so unmoored. It's weird to feel like you're starting from scratch again, not necessarily in terms of your career or what you post on LinkedIn about who you are, but inside that, you really are starting from scratch: Who am I without access to my friends? Who am I without access to family members? Who am I without X? Who am I without Y? +And so, the pandemic kind of energetically takes everything away, and so we can see ourselves more clearly. And that can be really strange because we haven't had the opportunity to do that in the past. And for many folks, often, we don't engage with mental health or well-being until something goes wrong. And we don't really engage with these ideas until we feel we're at a breaking point. And so the pandemic being the biggest breaking point we've had as a collective, at least in the Western world, we are forced to do that reckoning. +And so, of course, it's not just a loneliness pandemic; it's not just a burnout pandemic. I really do think it's an existential pandemic because people are wondering, or at least I am, and I know others who are, and I think others who are listening might be: Who am I? What am I here to do? What's my destiny? Why am I here? What's next? How do I make sense of all of the things that have happened in my life so far? And because there's no noise and no distraction or no busyness much as there was before the pandemic, you really are just there with yourself reckoning with those questions. +CHAD: Well, Natalie, I'm happy to see that someone emerged on the other side of this with a new product. +NATALIE: [laughs] +CHAD: And I wish you the best. +NATALIE: Thank you. Thank you very much. +CHAD: Again, if folks want to sign up or check it out more or just follow along with you, where are all the places that they can do that? +NATALIE: Sure. I would love for folks to connect on Instagram, harbour.today. You can also sign up to our newsletter. We have a daily email that comes out with questions from our community. So folks might ask things along the lines of what I've been describing, and we'll respond with some chakra guidance, some ancient philosophy that might be helpful, and also some practical tools, things that you can do like walking barefoot in your local park. Or some breathing exercises that might help you find balance within, or some yoga can really help you hack your chakras back into alignment, or some scripture that may help you reconnect with your divinity. +CHAD: Wonderful. You can subscribe to the show and find notes for this episode at giantrobots.fm. And we are emerging into this new season with full transcripts of every show as well. So you can find those on the website. And it will be included in the show notes, so they appear in your podcast player as well. I'm excited. It's something that we have been talking about doing for a while, but the time and expense of it traditionally was prohibitive. But we've made it happen for this new season in no small thanks to our new editor and producer, Mandy Moore. +So if you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and edited by Mandy Moore. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Natalie Nzeyimana. + + + At harbour.today, Natalie Nzeyimana and her team are helping people build holistic resilience. On this episode, she and Chad talk about building the app at the beginning of the pandemic when she witnessed herself and others feeling like they were close to drowning and feeling really unmoored.

+ +

Harbour is a space for people to anchor themselves, find clarity, and set sail. The community offers one-to-one coaching, workshops, a course, and a daily check-in tool.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And today, I'm joined by the founder of Harbour, Natalie Nzeyimana. So, Natalie, thanks for joining me.

+ +

NATALIE: Thanks for having me on.

+ +

CHAD: So tell me a little bit about what Harbour is.

+ +

NATALIE: Sure. Harbour is a space for people to anchor self, find clarity, and set sail. We offer one-to-one coaching, workshops, a course, and a daily check-in tool. Harbour was built at the beginning of the pandemic when I witnessed within myself, and the people I knew who I'd worked with, friends, family, just a lot of us felt like we were close to drowning and feeling really unmoored. And so, it began as a course to think about the ways we could use holistic strategies to anchor ourselves and set sail. And from then, from November 2020 to now, it's become a product.

+ +

CHAD: You started in November. And I know we first met in London a while ago. You were teaching yourself to code working on an education product if I remember right. And we got together at Google Space there and paired for a little bit. Did you code Harbour yourself?

+ +

NATALIE: It feels like another lifetime.

+ +

CHAD: [laughs]

+ +

NATALIE: I think life before the pandemic and life after the pandemic; there’s a real line there. I've done quite a bit of the coding myself. However, I've also used a lot of no-code solutions to create MVPs. They've been amazing at helping me scale, helping me test out ideas incredibly quickly.

+ +

And so one of the interesting things about juggling doing client work, and then also building the back end, and building the module, and then building the design work, and thinking about content juggling all of these different pieces, is that equation of do I invest time in HTML, or do I invest time in machine learning that's going to help me scale? And making all of those intricate decisions has been really, really interesting because, of course, I want to make everything myself. But these no-code solutions have enabled me to test hypotheses so much faster so that I can save time in the long run.

+ +

CHAD: Well, tell us a little bit more about what the product is today and what you went through to get to this point.

+ +

NATALIE: Sure. So initially, I just posted on LinkedIn to see who would want to join the course. I had a really simple Squarespace page, and then that evolved into a Typeform which I would use with clients to help them track progress and checking in with their chakras every day. And so, the way that Harbour works is that we do an energy review based on the seven in-body chakras.

+ +

And so, for anyone who might be unfamiliar with this terminology, the chakras are...well, there are different schools of thought on this. They are a system for either focusing during meditation depending on where you sit in terms of your feelings towards energy bodies. They are a subtle body energy system of themselves. And what I find incredibly helpful for those chakras is that they help people map their energy in a way that I haven't found anything else does effectively.

+ +

So starting from the root chakra, which is the base of your spine, you can ask yourself, am I feeling safe? Am I feeling grounded? Am I feeling as though my material needs are met?

+ +

Traveling up towards your reproductive area, you've got the sacral chakra which governs your sense of feeling as though you can desire the things that you desire in the world, feeling as though you are sensual. You're able to experience pleasure. You're able to be creative and playful.

+ +

And then up to the solar plexus, which is around your navel area, governs the sense of personal power, empowerment, will, feeling as though you're able to go after your goals with chutzpah and energy.

+ +

And then moving into the heart chakra, which governs this idea of do I feel as though I'm open to receiving and giving love freely?

+ +

And the throat, do I feel as though I'm an open conduit for the truth of who I am? Do I feel as though I'm able to express myself fully in the world?

+ +

And then into the third eye, which governs your intuition. Do I feel as though I'm able to trust my intuitive leads and to move with grace and ease, trusting and able to go with the flow?

+ +

And then finally, we have the crown chakra, which governs do I feel open to receiving divine wisdom? Do I feel as though I'm in this world on my own and there's nothing but pure materiality? Or do I feel open to receiving what some people might call God or Allah or the Tao? Whatever your orientation is, do I feel open towards receiving that kind of wisdom?

+ +

What's really beautiful about the chakras is that they've been used by ancient Chinese, ancient Egyptians, Tibetans, Sikhs, multiple traditions, and indigenous systems. And so there's kind of this lovely thread of people around the world thinking about how energy moves through our minds, bodies, and spirits. But that's quite a lot. So we just ask seven questions every day.

+ +

CHAD: So I have to admit I was not...and my first exposure to this is this conversation. So is this something that you have been aware of and practicing prior to working on Harbour, or is it something that you found which then led you to the creation?

+ +

NATALIE: Definitely the latter, the latter. So I went through a pretty gnarly, dark night of the soul and just had this huge existential crisis of wondering what am I here to do? Why am I here? What's my purpose in life? I don't know if other people might resonate with this, but kind of feeling that you make these huge or not so huge career goals, and then you reach them, and you still feel like something's missing. And in my quest to understand what that missing piece might be, I came across chakras, and I found it incredibly helpful.

+ +

I think people who do yoga might be aware of this because they often come up to yoga. Physical movement is often a way of realigning and balancing the chakras. So there are specific movements or specific asanas that you can do to balance out your root chakra or balance out your Sacral Chakra, which is great because it's kind of like all of these different hacks you can do to bring your mind, body, and spirit back in line. And that's why I think I loved it because when I encountered a lot of other systems or other approaches, it just all felt a bit ephemeral and like I couldn't grasp it. But there was something about chakras that really spoke to the budding engineer within me because I was like, wait, you can just hack yourself into alignment? This is great.

+ +

[chuckles]

+ +

CHAD: So this is something you do daily.

+ +

NATALIE: Well, something I try to do daily. [chuckles]

+ +

CHAD: Okay. I meant, is this something one does daily? [chuckles]

+ +

NATALIE: Yeah. Ideally, yes. Because it's like anything else that we do, if you want to maintain a certain level of well-being or perhaps a certain level of fluency, let's say, for example, in a language whether that's a programming language or the spoken language, you need to practice it every day.

+ +

And so, with chakras and aligning one's mind, body, and spirit, it feels as though the stakes are slightly higher when we're in the middle of a pandemic, and there's so much uncertainty, and all of our lives have kind of been exposed to so much change. But yes, daily is optimal. Daily is, at least at Harbour, the bare minimum.

+ +

What are some things that you do every day to balance your mind, body, and spirit? You may be aligning your chakras without quite realizing that you are.

+ +

CHAD: Yeah. So I run every day. And I've often described that as that's my meditation. So I find that that really does wonders for reducing my overall stress. I do it in the morning before starting my day. And so, I think it really sets the foundation on which the rest of the day is built for me. And it wasn't until I made the commitment to do it every day. And now I run long distance enough where I need to take a rest day once a week. But when I made the commitment to do it every day, it really did change my relationship with running.

+ +

NATALIE: That's so interesting. I was thinking about Kazuo Ishiguro's what I think about when I'm running or something along those lines. He's written this great book. And I know several people who run and have spoken of its incredible meditative qualities. And I think that's a wonderful way of connecting with yourself or creating space to connect with yourself.

+ +

I also wanted to touch upon something that I know that we tend to move towards or perhaps even a dichotomy: do we meditate to relieve stress, or do we meditate to get closer to our divinity? And so one of the things at Harbour that we try to do is we try to help folks shift from meditating to relieve stress to meditating to connect with one's divinity, and that way, the stress doesn't become as prominent a factor for which meditation is there to alleviate.

+ +

CHAD: What do you mean by divinity in this case?

+ +

NATALIE: Yeah, great question. Very controversial. [laughs] I mean, it's 2021, and the least cool thing you could possibly do in an engineering environment is talk about God and the divine. I think there is a really interesting choice point we're at as a collective where there is an increased awareness of consciousness. So there's a lot of language in at least the tech community, from my experience, whether you've got things like Burning Man or just a lot of products and offerings out there, which are there to raise your consciousness.

+ +

One of the really tricky things about raising your consciousness...and in the chakra system, we do that through something that's called a kundalini awakening, which is where your consciousness does raise from the root chakra all the way to the crown. As your consciousness raises through the chakras, coming from the Indian tradition, what happens is your life force, your consciousness moves through your chakras, and each chakra it touches upon triggers a mini awakening.

+ +

So, for example, as your life force is moving through your root chakra, anything that may have happened in your childhood, anytime that you may have experienced any aspect of material instability, let's say you lost your job or you had a partnership fall apart, or any time where you felt like your world completely crumbled, that will likely be triggered when you're going through that mini awakening in that root chakra.

+ +

I mentioned divinity because it feels as though there are two paths we can go down. We can either go down the path of I am raising my consciousness. I am the master of my own destiny. I know what I am here to do in life, and I'm in control of my own awakening. Or we can go down another path which is far trickier, which is sort of saying, "At every point in every day, I choose to surrender to the wisdom that is far beyond me. And I'm going to trust the signals and the science that I receive that they are aligned with my highest good."

+ +

One of these paths is more egoic, and the other one is more surrendered. That's not to say that we don't need an ego. But the ego can get into really tricky territory when you're doing this kind of alignment and awakening work, and it can really do a lot of harm. And I don't say that through judgment. I say that because I've been through the wringer with a lot of ego deaths.

+ +

And so, one of the safest ways to mitigate that risk of the ego taking over is to surrender to something that is far more wise than you. Perhaps you don't resonate with the idea that there is only one creator, and that's fine. But perhaps just from a logical point of view, it does seem to make more sense to surrender to the fact that there's something that knows more than I do at any moment.

+ +

CHAD: So this is some really big stuff.

+ +

NATALIE: Oh yeah.

+ +

CHAD: Before we get much further into it, I think for listeners who want to learn more or are interested in what they're hearing and want to give it a try, where do they do that? Where do they find Harbour? And what is it going to look like?

+ +

NATALIE: Sure. So you can follow us at harbour.today online on our website also on Instagram. And I'd love to invite your listeners to try out our 30-day trial, where if you complete 30 days of your chakra daily check-in, you'll receive access to our platform with activities, reading prompts, and also different course materials for free for a whole year. And I know I'm probably giving this away to a lot of people because all the engineers I know are very disciplined, [laughs] and they'll do this 30-day streak like it's a GitHub streak.

+ +

CHAD: [laughs]

+ +

NATALIE: So I'm shooting myself in the foot a little bit. But I'm really keen to offer folks who are asking these questions who are thinking about what am I here to do? Is there more? How do I engage with literature that could help me ask these questions more deeply within myself? And the daily check-in and the learning platform is a really simple way to do that.

+ +

CHAD: Great. That's great. I hope folks check it out. So, in addition to the daily check-in, you just gave some hints on what is actually on the platform. There are reading prompts and those sorts of things. Is there more than that as well available?

+ +

NATALIE: Definitely. So we are launching a monthly course on October 6th, and then the next one will be in January when we come back from the break called Organic Cycles. And the purpose of this course is to help people who are thinking about launching something. So you may have a side project that you're thinking about launching or perhaps a hobby that you feel like you want to take up, or maybe you even want to become an entrepreneur full time. But you're a little bit overwhelmed by what might be involved by that.

+ +

And so at Harbour, we're real big believers in cyclic, iterative, sustainable growth. And so, we use the moon cycle for our sprints. We use it for measuring our tasks. And in Organic Cycles, you will learn about the moon. You'll follow the Moon Phases. And let's say, for example, you want to start a new business selling socks. [laughs] On the new moon on October the sixth, you will join us, and you will tell us all about your sock business. And we'll listen, and we'll make a plan as other people in the cosmic plan.

+ +

In the first quarter, we'll start thinking a little bit about why do you love socks so much? Where does that come from? And what are the small steps we can make together to help you grow your sock business within this moon cycle? Which is, of course, 28 days. On the full moon, we'll celebrate all the progress that you've made with your sock business. And together, we'll figure out the next steps. In the last quarter, we'll think about hmm, what were the experiments making the sock business so far that worked really well? What are the ones that didn't? Which ones would you like to take into the next cycle? And on the next new moon, we'll start all over again.

+ +

And so it's very similar to an agile workflow, except you're learning about the moon. And the reason why I believe that's important is because a lot of our day-to-day lives are just so focused on abstract entities and not necessarily the natural world. And so a lot of the prompts in the daily review for Harbour are getting outside, all sorts of different things that reconnect you to nature as a way of rewilding you.

+ +

So yeah, I'd really love for folks to come on board. If you have any experience with agile, even if you don't and you're just curious about the moon, and want to find out a little bit more about the stars and anything natural, and meet other people who are curious about energy and ideation and how to create cycles which feel more organic, we'd love to have you along.

+ +

CHAD: I really like the sound of this in that it's a structure to anything. A group environment where you're helping each other is great. Layering on the information about the moon and everything adds an additional element of interest to it. I'm just a big believer in being intentional about what we do in our businesses and in our lives. So any structure that can help people be intentional about what they do, I think is going to help people and help them be more successful than if they just don't have a plan and aren't intentional, aren't consciously thinking about what they want to achieve, and what they want for themselves. And helping people do that, I think, is great.

+ +

NATALIE: Definitely. And I definitely have been on both sides of that coin, either having too much structure or no structure at all. And I think there's something really beautiful about naming things in ways that feel soft and ways that feel different to people so that they can access that idea and be playful with it and be creative. Because I know that for a lot of people who we work with, post-burnout, folks who are incredibly structured. The Harbour client is a recovering Type A like me who has probably been an overachiever at school and has probably been incredibly structured in their lives but didn't really know how to let go and didn't really know how to create fluidity and flow in their life.

+ +

And so one of our tag lines is between discipline and surrender and a devotion to flow. And flow is made possible through that playfulness, and through that structure, and through those rituals, and through that surrender, which is really fun. And it's always really, really fun to see people connect the dots and see, oh, it's quite interesting. Like on full moons, I do have a lot more energy. Or on the new moons, I do feel a little bit more restful, and giving people prompts to add self-care and add meditation to their existing structures.

+ +

CHAD: So this might be an overly practical question, but I'm curious how you manage time zones.

+ +

NATALIE: [laughs] With naps.

+ +

[laughter]

+ +

CHAD: Okay. Fair enough.

+ +

NATALIE: No, really, I do. I have naps. And I really love work...as you know, I've been working with folks in the U.S. for the last ten years. And I really enjoy it because I think it feels like transporting to a different environment. So, yeah, just a nap, and then I wake up, and I'm in a different country. It's great.

+ +

CHAD: [laughs] So it's almost like you've actually traveled then.

+ +

NATALIE: Exactly. Exactly.

+ +

CHAD: Hopefully, a little less jetlag.

+ +

NATALIE: Yeah, it's really great. What about in your work? I know that you're one of the most organized and structured people I've ever met. But sometimes, when I'm in Notion, I'm like, what would Chad do? [chuckles] But how do you find the balance between order and structure and allowing yourself the space to find flow and surrender even as a leader, even when you're building a product?

+ +

CHAD: Well, thank you for the compliment. I appreciate it. Let me preface by saying I think that nothing ever stays the same. And so what I do today and what's working for me today is probably pretty different than three years ago because our teams are in different places, and the people I work with are different, and I'm in a different place.

+ +

So the thing that's working for me now is putting times blocked off on my calendar where I want to either...it's a regularly scheduled time. And I have one on Thursday; it's from 2:00 to 5:00 p.m. It's just blocked off, and it just says, "Focus time." And each week, then I decide in advance what I'm going to be doing during that focus time. And it might be exploring something new. It might be working on something specific. And then, when I need to accomplish something else, making sure that I block off the time on the calendar. And so that's working for me now. And it's not what I used to do. I used to be much more freeform. Nowadays, if I don't block off the time, I lose it.

+ +

Previously, I could maintain a lot of free time on my calendar and use that as the time I was doing things. And as we grew and as I was working with people more across all of thoughtbot, across many different time zones, I needed to be much more conscious about what my scheduled time actually looked like and make sure that I'm scheduling time to work on things more freeform.

+ +

NATALIE: Yeah, definitely. That's so helpful. And I like the idea of time blocking. I've been trying to do a little bit more of that. What's interesting, too, is as Harbour grows and the product grows, and thinking about scaling and trying to anticipate things before they happen, even though you can't anticipate everything, one of the exercises I've been thinking about is what would it feel like to have a team of this many people and meditate on that idea and see if it feels right? And do I necessarily need to have a team that looks like X or a team that looks like Y? And trying to meditate into what that experience would be before making the decision. And I'm wondering if, through your experience having run this global company and having scaled it over more than a decade, what are some of the things that you've done to pre-pave and to support the sustainable scaling of the business?

+ +

CHAD: I think thinking things through in advance is very important. And I don't say the next thing I'm about to say because it's not important because I think that it is very important, and I certainly do it. But I've also come to grips over the years with the idea that no matter how much we plan, it's not going to go like we plan. And so there's this interesting balance between planning too much and reacting to what's happening.

+ +

And I'll come back to intentionality. And the way that I talked about it at thoughtbot is letting fulfillment be our North Star. So we shouldn't be doing things just because we think they'll be good business decisions or because we think they're the right thing to do for some arbitrary reason. We should be driven by what we want to be doing in our work and what kind of company we want to be, and being fulfilled in our work.

+ +

And when we're faced with a decision to make about who we are, or what we do, or how we're going to approach this, letting it be driven by fulfillment is very powerful. Because it means that likely what everyone wants from their work is not so different from one another, especially when we curate a team of people that want to work together for our working lives what might be. It's probably not so different from each other.

+ +

So that's also very powerful because it means that I don't need to be the one to make all of the decisions. Other people can make those decisions around who we are and what we'll do, and which direction will head in. And they'll very likely be what will be fulfilling to the rest of the team as well. And so it sort of democratizes that decision-making in a way which is more resilient and then can be more flexible. As our best-laid plans start to go awry, we're making decisions based on fulfillment. And I think that allows us to be resilient.

+ +

NATALIE: Yeah, that's so helpful.

+ +

CHAD: Because so much of what we've tried, particularly when we intentionally try to grow, so many of the decisions that have made thoughtbot successful we weren't making them for business reasons, we were making them because --

+ +

NATALIE: They felt right.

+ +

CHAD: They felt right. We were the first consulting company in the world to switch to Ruby on Rails. We didn't make that decision because we thought Rails was going to be popular. We made it because, as developers and designers, we were more fulfilled using this new thing, Rails, than using PHP or Java. And, in fact, if we had been focused on what we thought would be the successful business thing, we might never have chosen that because it can feel very risky because you're choosing something entirely unknown.

+ +

So the opposite example is we've tried very hard to grow over the years non-organically geographically. So someone is moving to this area, or we are going to hire someone in this area. And we're going to grow into this area. And it's not driven necessarily by fulfillment. And in a lot of those cases, it's been very difficult, or it's outright not been successful. And so, being able to react to those situations and adjust has been critical for our long-term success.

+ +

Another word I use often is grit. And grit, for me, means we fail a bunch but we stay at it because we are driven by...what's driving that is fulfillment. So even if we really believe in it, even if we've failed in execution for business reasons or something like that, we tend to stick with it over the long term and just try a different way.

+ +

NATALIE: Yeah, I hear that. There is so much grit that's required to sustain something over a long period of time. And it feels like quite an incremental grit as opposed to huge pushes of energy that we might witness in different business models, for example, venture capital. And having been in the whirlwind of the VC world a little bit and now building what I hope is a more sustainable model, the grit is very moment to moment. It's continuous. Each task, each decision, it's a soft resilience that kind of grows over time as opposed to having to wield huge amounts of chutzpah to get through this investment cycle. Do you know what I mean?

+ +

CHAD: I do, and I think that has a flip side as well, which I try to be conscious of but don't always do a good job with. I tend not to project too far; that’s one side. And then the reverse is also true, which I tend not to celebrate successes enough. I tend not to reflect on the past too much because I'm on to the next incremental improvement pretty quickly. That has benefits because when you have a down day, tomorrow is a new day. It's a brand new day. But that has downsides too, which is when you have a great day, [laughs] you're on to the next thing the next day as well, at least for me. I move on very quickly. And like I said, I think that has its benefits, and it has its downsides.

+ +

NATALIE: What are your rituals for celebrating both personally and professionally? How do you celebrate yourself and the ways that you've grown? And how do you celebrate the business that you've grown with others?

+ +

CHAD: Just being honest, I probably have not...I do not have rituals. And I think this is where having good partners, or other members of my team has been helpful because knowing that this will be my tendency, having other people backing me up to recognize the successes or to call me on when I’m moving on too quickly or something like that has been helpful.

+ +

NATALIE: Yeah, definitely.

+ +

CHAD: Are you working on Harbour solo right now, or are you working with others?

+ +

NATALIE: Sure. Sometimes I work with a really wonderful ayurvedic practitioner called Sriram, who was an engineer for 15 years before he became an ayurvedic practitioner. So completely similar to you in that thought about going about and finding a co-founder or partnering with someone. And then I just had this really lovely chat with someone on Lunchclub. And we ended up talking about chakras for an hour and also coding. And I was like, this is my dream. [laughs] I get to talk about chakras, and I get to talk about product. This is great. And so, I work with Sriram sometimes on client work. Normally, the split is that he takes approximately a third of the client sessions, but we work on the one-to-one coaching.

+ +

And so, I'm your accountability coach. And we're hiring more now, which is really exciting. And I'll do the weekly reviews with clients, and then Sriram will put together the ayurvedic program for the client. So that's always really great fun. And I'm also working with a wonderful designer based in San Francisco called Christina. And yeah, so the three of us...Sriram has his own practice, and Christina has her own agency. But there's a lot of collaborative work that's happening there.

+ +

And I'm currently onboarding more coaches, which is exciting and very necessary because I came to a choice point, and I said, do I want to study chakras and become qualified? And I realized I didn't. I wanted to talk to all the people who knew about chakras and who were qualified, and so that's been a lovely experience onboarding them, and onboarding therapists, and onboarding other personal development coaches who are going to be able to serve clients as we scale.

+ +

CHAD: Nice. You mentioned Lunchclub many times in the story of Harbour on the website. I have never used Lunchclub. But I heard of it before. And if folks haven't heard of it, what's the pitch for Lunchclub?

+ +

[chuckles]

+ +

NATALIE: It's LinkedIn as you'd want it to be.

+ +

[laughter]

+ +

CHAD: Oh, that's great. That's great.

+ +

NATALIE: I think Lunchclub gets rid of all of the bravado and all of the stuff on LinkedIn because I think a lot of us do really struggle with self-promotion online. But at the same time, we want to connect with people. And we want to have real conversations that hopefully lead to more conversations or more opportunities for both parties.

+ +

And when I started on Lunchclub about a year and a half ago, it was just an incredible way to connect with people around the world. I'd just moved into a flat. I was living on my own in the middle of the pandemic and in the middle of the lockdown building product. And I thought, I really need to chat to people because I really enjoy doing that.

+ +

And through 45-minute conversations, you get matched by their little magical AI, and you connect with people who might be related to the interests that you have. And you can build streaks. And the more streaks you build, the more points you get. And the more points you get, the more you can choose who you connect with based on geography and business development goals, et cetera. Well, even if you do choose I want to meet an investor or I want to meet a Biz Dev specialist, this isn't really a sales call or an investment pitch. It's just I want to increase the likelihood that the person I meet will be aligned with where I'm trying to get on my journey.

+ +

CHAD: Well, the pandemic has been a really difficult time for everybody, parents, and of which I count myself in that. In particular, seeing it across thoughtbot, obviously, a trend is the people who live alone had an especially challenging time during the strictest of the lockdowns that were happening. And it was challenging. We saw a lot of people struggling. And because we were all remote, you're remote all day working. You don't necessarily want to be reaching out to people remotely, just that energy there. And I think that's maybe where Harbour comes in is solving that energy problem that I think many of us are feeling now.

+ +

NATALIE: Definitely. I think what happened over the last year and a half, two years, has created a tectonic shift, but I think also a portal because it's forced us to reckon with ourselves in ways that perhaps we had been ignoring, in ways that we didn't know we needed to, in ways that we've been forced to. And it can be really scary. And even as an adult, that's weird. It's weird to feel that scared as an adult. It's weird to feel that displaced as an adult. It's weird to feel so unmoored. It's weird to feel like you're starting from scratch again, not necessarily in terms of your career or what you post on LinkedIn about who you are, but inside that, you really are starting from scratch: Who am I without access to my friends? Who am I without access to family members? Who am I without X? Who am I without Y?

+ +

And so, the pandemic kind of energetically takes everything away, and so we can see ourselves more clearly. And that can be really strange because we haven't had the opportunity to do that in the past. And for many folks, often, we don't engage with mental health or well-being until something goes wrong. And we don't really engage with these ideas until we feel we're at a breaking point. And so the pandemic being the biggest breaking point we've had as a collective, at least in the Western world, we are forced to do that reckoning.

+ +

And so, of course, it's not just a loneliness pandemic; it's not just a burnout pandemic. I really do think it's an existential pandemic because people are wondering, or at least I am, and I know others who are, and I think others who are listening might be: Who am I? What am I here to do? What's my destiny? Why am I here? What's next? How do I make sense of all of the things that have happened in my life so far? And because there's no noise and no distraction or no busyness much as there was before the pandemic, you really are just there with yourself reckoning with those questions.

+ +

CHAD: Well, Natalie, I'm happy to see that someone emerged on the other side of this with a new product.

+ +

NATALIE: [laughs]

+ +

CHAD: And I wish you the best.

+ +

NATALIE: Thank you. Thank you very much.

+ +

CHAD: Again, if folks want to sign up or check it out more or just follow along with you, where are all the places that they can do that?

+ +

NATALIE: Sure. I would love for folks to connect on Instagram, harbour.today. You can also sign up to our newsletter. We have a daily email that comes out with questions from our community. So folks might ask things along the lines of what I've been describing, and we'll respond with some chakra guidance, some ancient philosophy that might be helpful, and also some practical tools, things that you can do like walking barefoot in your local park. Or some breathing exercises that might help you find balance within, or some yoga can really help you hack your chakras back into alignment, or some scripture that may help you reconnect with your divinity.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes for this episode at giantrobots.fm. And we are emerging into this new season with full transcripts of every show as well. So you can find those on the website. And it will be included in the show notes, so they appear in your podcast player as well. I'm excited. It's something that we have been talking about doing for a while, but the time and expense of it traditionally was prohibitive. But we've made it happen for this new season in no small thanks to our new editor and producer, Mandy Moore.

+ +

So if you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and edited by Mandy Moore.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Natalie Nzeyimana.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + At harbour.today, Natalie Nzeyimana and her team are helping people build holistic resilience. On this episode, she and Chad talk about building the app at the beginning of the pandemic when she witnessed herself and others feeling like they were close to drowning and feeling really unmoored.

+ +

Harbour is a space for people to anchor themselves, find clarity, and set sail. The community offers one-to-one coaching, workshops, a course, and a daily check-in tool.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And today, I'm joined by the founder of Harbour, Natalie Nzeyimana. So, Natalie, thanks for joining me.

+ +

NATALIE: Thanks for having me on.

+ +

CHAD: So tell me a little bit about what Harbour is.

+ +

NATALIE: Sure. Harbour is a space for people to anchor self, find clarity, and set sail. We offer one-to-one coaching, workshops, a course, and a daily check-in tool. Harbour was built at the beginning of the pandemic when I witnessed within myself, and the people I knew who I'd worked with, friends, family, just a lot of us felt like we were close to drowning and feeling really unmoored. And so, it began as a course to think about the ways we could use holistic strategies to anchor ourselves and set sail. And from then, from November 2020 to now, it's become a product.

+ +

CHAD: You started in November. And I know we first met in London a while ago. You were teaching yourself to code working on an education product if I remember right. And we got together at Google Space there and paired for a little bit. Did you code Harbour yourself?

+ +

NATALIE: It feels like another lifetime.

+ +

CHAD: [laughs]

+ +

NATALIE: I think life before the pandemic and life after the pandemic; there’s a real line there. I've done quite a bit of the coding myself. However, I've also used a lot of no-code solutions to create MVPs. They've been amazing at helping me scale, helping me test out ideas incredibly quickly.

+ +

And so one of the interesting things about juggling doing client work, and then also building the back end, and building the module, and then building the design work, and thinking about content juggling all of these different pieces, is that equation of do I invest time in HTML, or do I invest time in machine learning that's going to help me scale? And making all of those intricate decisions has been really, really interesting because, of course, I want to make everything myself. But these no-code solutions have enabled me to test hypotheses so much faster so that I can save time in the long run.

+ +

CHAD: Well, tell us a little bit more about what the product is today and what you went through to get to this point.

+ +

NATALIE: Sure. So initially, I just posted on LinkedIn to see who would want to join the course. I had a really simple Squarespace page, and then that evolved into a Typeform which I would use with clients to help them track progress and checking in with their chakras every day. And so, the way that Harbour works is that we do an energy review based on the seven in-body chakras.

+ +

And so, for anyone who might be unfamiliar with this terminology, the chakras are...well, there are different schools of thought on this. They are a system for either focusing during meditation depending on where you sit in terms of your feelings towards energy bodies. They are a subtle body energy system of themselves. And what I find incredibly helpful for those chakras is that they help people map their energy in a way that I haven't found anything else does effectively.

+ +

So starting from the root chakra, which is the base of your spine, you can ask yourself, am I feeling safe? Am I feeling grounded? Am I feeling as though my material needs are met?

+ +

Traveling up towards your reproductive area, you've got the sacral chakra which governs your sense of feeling as though you can desire the things that you desire in the world, feeling as though you are sensual. You're able to experience pleasure. You're able to be creative and playful.

+ +

And then up to the solar plexus, which is around your navel area, governs the sense of personal power, empowerment, will, feeling as though you're able to go after your goals with chutzpah and energy.

+ +

And then moving into the heart chakra, which governs this idea of do I feel as though I'm open to receiving and giving love freely?

+ +

And the throat, do I feel as though I'm an open conduit for the truth of who I am? Do I feel as though I'm able to express myself fully in the world?

+ +

And then into the third eye, which governs your intuition. Do I feel as though I'm able to trust my intuitive leads and to move with grace and ease, trusting and able to go with the flow?

+ +

And then finally, we have the crown chakra, which governs do I feel open to receiving divine wisdom? Do I feel as though I'm in this world on my own and there's nothing but pure materiality? Or do I feel open to receiving what some people might call God or Allah or the Tao? Whatever your orientation is, do I feel open towards receiving that kind of wisdom?

+ +

What's really beautiful about the chakras is that they've been used by ancient Chinese, ancient Egyptians, Tibetans, Sikhs, multiple traditions, and indigenous systems. And so there's kind of this lovely thread of people around the world thinking about how energy moves through our minds, bodies, and spirits. But that's quite a lot. So we just ask seven questions every day.

+ +

CHAD: So I have to admit I was not...and my first exposure to this is this conversation. So is this something that you have been aware of and practicing prior to working on Harbour, or is it something that you found which then led you to the creation?

+ +

NATALIE: Definitely the latter, the latter. So I went through a pretty gnarly, dark night of the soul and just had this huge existential crisis of wondering what am I here to do? Why am I here? What's my purpose in life? I don't know if other people might resonate with this, but kind of feeling that you make these huge or not so huge career goals, and then you reach them, and you still feel like something's missing. And in my quest to understand what that missing piece might be, I came across chakras, and I found it incredibly helpful.

+ +

I think people who do yoga might be aware of this because they often come up to yoga. Physical movement is often a way of realigning and balancing the chakras. So there are specific movements or specific asanas that you can do to balance out your root chakra or balance out your Sacral Chakra, which is great because it's kind of like all of these different hacks you can do to bring your mind, body, and spirit back in line. And that's why I think I loved it because when I encountered a lot of other systems or other approaches, it just all felt a bit ephemeral and like I couldn't grasp it. But there was something about chakras that really spoke to the budding engineer within me because I was like, wait, you can just hack yourself into alignment? This is great.

+ +

[chuckles]

+ +

CHAD: So this is something you do daily.

+ +

NATALIE: Well, something I try to do daily. [chuckles]

+ +

CHAD: Okay. I meant, is this something one does daily? [chuckles]

+ +

NATALIE: Yeah. Ideally, yes. Because it's like anything else that we do, if you want to maintain a certain level of well-being or perhaps a certain level of fluency, let's say, for example, in a language whether that's a programming language or the spoken language, you need to practice it every day.

+ +

And so, with chakras and aligning one's mind, body, and spirit, it feels as though the stakes are slightly higher when we're in the middle of a pandemic, and there's so much uncertainty, and all of our lives have kind of been exposed to so much change. But yes, daily is optimal. Daily is, at least at Harbour, the bare minimum.

+ +

What are some things that you do every day to balance your mind, body, and spirit? You may be aligning your chakras without quite realizing that you are.

+ +

CHAD: Yeah. So I run every day. And I've often described that as that's my meditation. So I find that that really does wonders for reducing my overall stress. I do it in the morning before starting my day. And so, I think it really sets the foundation on which the rest of the day is built for me. And it wasn't until I made the commitment to do it every day. And now I run long distance enough where I need to take a rest day once a week. But when I made the commitment to do it every day, it really did change my relationship with running.

+ +

NATALIE: That's so interesting. I was thinking about Kazuo Ishiguro's what I think about when I'm running or something along those lines. He's written this great book. And I know several people who run and have spoken of its incredible meditative qualities. And I think that's a wonderful way of connecting with yourself or creating space to connect with yourself.

+ +

I also wanted to touch upon something that I know that we tend to move towards or perhaps even a dichotomy: do we meditate to relieve stress, or do we meditate to get closer to our divinity? And so one of the things at Harbour that we try to do is we try to help folks shift from meditating to relieve stress to meditating to connect with one's divinity, and that way, the stress doesn't become as prominent a factor for which meditation is there to alleviate.

+ +

CHAD: What do you mean by divinity in this case?

+ +

NATALIE: Yeah, great question. Very controversial. [laughs] I mean, it's 2021, and the least cool thing you could possibly do in an engineering environment is talk about God and the divine. I think there is a really interesting choice point we're at as a collective where there is an increased awareness of consciousness. So there's a lot of language in at least the tech community, from my experience, whether you've got things like Burning Man or just a lot of products and offerings out there, which are there to raise your consciousness.

+ +

One of the really tricky things about raising your consciousness...and in the chakra system, we do that through something that's called a kundalini awakening, which is where your consciousness does raise from the root chakra all the way to the crown. As your consciousness raises through the chakras, coming from the Indian tradition, what happens is your life force, your consciousness moves through your chakras, and each chakra it touches upon triggers a mini awakening.

+ +

So, for example, as your life force is moving through your root chakra, anything that may have happened in your childhood, anytime that you may have experienced any aspect of material instability, let's say you lost your job or you had a partnership fall apart, or any time where you felt like your world completely crumbled, that will likely be triggered when you're going through that mini awakening in that root chakra.

+ +

I mentioned divinity because it feels as though there are two paths we can go down. We can either go down the path of I am raising my consciousness. I am the master of my own destiny. I know what I am here to do in life, and I'm in control of my own awakening. Or we can go down another path which is far trickier, which is sort of saying, "At every point in every day, I choose to surrender to the wisdom that is far beyond me. And I'm going to trust the signals and the science that I receive that they are aligned with my highest good."

+ +

One of these paths is more egoic, and the other one is more surrendered. That's not to say that we don't need an ego. But the ego can get into really tricky territory when you're doing this kind of alignment and awakening work, and it can really do a lot of harm. And I don't say that through judgment. I say that because I've been through the wringer with a lot of ego deaths.

+ +

And so, one of the safest ways to mitigate that risk of the ego taking over is to surrender to something that is far more wise than you. Perhaps you don't resonate with the idea that there is only one creator, and that's fine. But perhaps just from a logical point of view, it does seem to make more sense to surrender to the fact that there's something that knows more than I do at any moment.

+ +

CHAD: So this is some really big stuff.

+ +

NATALIE: Oh yeah.

+ +

CHAD: Before we get much further into it, I think for listeners who want to learn more or are interested in what they're hearing and want to give it a try, where do they do that? Where do they find Harbour? And what is it going to look like?

+ +

NATALIE: Sure. So you can follow us at harbour.today online on our website also on Instagram. And I'd love to invite your listeners to try out our 30-day trial, where if you complete 30 days of your chakra daily check-in, you'll receive access to our platform with activities, reading prompts, and also different course materials for free for a whole year. And I know I'm probably giving this away to a lot of people because all the engineers I know are very disciplined, [laughs] and they'll do this 30-day streak like it's a GitHub streak.

+ +

CHAD: [laughs]

+ +

NATALIE: So I'm shooting myself in the foot a little bit. But I'm really keen to offer folks who are asking these questions who are thinking about what am I here to do? Is there more? How do I engage with literature that could help me ask these questions more deeply within myself? And the daily check-in and the learning platform is a really simple way to do that.

+ +

CHAD: Great. That's great. I hope folks check it out. So, in addition to the daily check-in, you just gave some hints on what is actually on the platform. There are reading prompts and those sorts of things. Is there more than that as well available?

+ +

NATALIE: Definitely. So we are launching a monthly course on October 6th, and then the next one will be in January when we come back from the break called Organic Cycles. And the purpose of this course is to help people who are thinking about launching something. So you may have a side project that you're thinking about launching or perhaps a hobby that you feel like you want to take up, or maybe you even want to become an entrepreneur full time. But you're a little bit overwhelmed by what might be involved by that.

+ +

And so at Harbour, we're real big believers in cyclic, iterative, sustainable growth. And so, we use the moon cycle for our sprints. We use it for measuring our tasks. And in Organic Cycles, you will learn about the moon. You'll follow the Moon Phases. And let's say, for example, you want to start a new business selling socks. [laughs] On the new moon on October the sixth, you will join us, and you will tell us all about your sock business. And we'll listen, and we'll make a plan as other people in the cosmic plan.

+ +

In the first quarter, we'll start thinking a little bit about why do you love socks so much? Where does that come from? And what are the small steps we can make together to help you grow your sock business within this moon cycle? Which is, of course, 28 days. On the full moon, we'll celebrate all the progress that you've made with your sock business. And together, we'll figure out the next steps. In the last quarter, we'll think about hmm, what were the experiments making the sock business so far that worked really well? What are the ones that didn't? Which ones would you like to take into the next cycle? And on the next new moon, we'll start all over again.

+ +

And so it's very similar to an agile workflow, except you're learning about the moon. And the reason why I believe that's important is because a lot of our day-to-day lives are just so focused on abstract entities and not necessarily the natural world. And so a lot of the prompts in the daily review for Harbour are getting outside, all sorts of different things that reconnect you to nature as a way of rewilding you.

+ +

So yeah, I'd really love for folks to come on board. If you have any experience with agile, even if you don't and you're just curious about the moon, and want to find out a little bit more about the stars and anything natural, and meet other people who are curious about energy and ideation and how to create cycles which feel more organic, we'd love to have you along.

+ +

CHAD: I really like the sound of this in that it's a structure to anything. A group environment where you're helping each other is great. Layering on the information about the moon and everything adds an additional element of interest to it. I'm just a big believer in being intentional about what we do in our businesses and in our lives. So any structure that can help people be intentional about what they do, I think is going to help people and help them be more successful than if they just don't have a plan and aren't intentional, aren't consciously thinking about what they want to achieve, and what they want for themselves. And helping people do that, I think, is great.

+ +

NATALIE: Definitely. And I definitely have been on both sides of that coin, either having too much structure or no structure at all. And I think there's something really beautiful about naming things in ways that feel soft and ways that feel different to people so that they can access that idea and be playful with it and be creative. Because I know that for a lot of people who we work with, post-burnout, folks who are incredibly structured. The Harbour client is a recovering Type A like me who has probably been an overachiever at school and has probably been incredibly structured in their lives but didn't really know how to let go and didn't really know how to create fluidity and flow in their life.

+ +

And so one of our tag lines is between discipline and surrender and a devotion to flow. And flow is made possible through that playfulness, and through that structure, and through those rituals, and through that surrender, which is really fun. And it's always really, really fun to see people connect the dots and see, oh, it's quite interesting. Like on full moons, I do have a lot more energy. Or on the new moons, I do feel a little bit more restful, and giving people prompts to add self-care and add meditation to their existing structures.

+ +

CHAD: So this might be an overly practical question, but I'm curious how you manage time zones.

+ +

NATALIE: [laughs] With naps.

+ +

[laughter]

+ +

CHAD: Okay. Fair enough.

+ +

NATALIE: No, really, I do. I have naps. And I really love work...as you know, I've been working with folks in the U.S. for the last ten years. And I really enjoy it because I think it feels like transporting to a different environment. So, yeah, just a nap, and then I wake up, and I'm in a different country. It's great.

+ +

CHAD: [laughs] So it's almost like you've actually traveled then.

+ +

NATALIE: Exactly. Exactly.

+ +

CHAD: Hopefully, a little less jetlag.

+ +

NATALIE: Yeah, it's really great. What about in your work? I know that you're one of the most organized and structured people I've ever met. But sometimes, when I'm in Notion, I'm like, what would Chad do? [chuckles] But how do you find the balance between order and structure and allowing yourself the space to find flow and surrender even as a leader, even when you're building a product?

+ +

CHAD: Well, thank you for the compliment. I appreciate it. Let me preface by saying I think that nothing ever stays the same. And so what I do today and what's working for me today is probably pretty different than three years ago because our teams are in different places, and the people I work with are different, and I'm in a different place.

+ +

So the thing that's working for me now is putting times blocked off on my calendar where I want to either...it's a regularly scheduled time. And I have one on Thursday; it's from 2:00 to 5:00 p.m. It's just blocked off, and it just says, "Focus time." And each week, then I decide in advance what I'm going to be doing during that focus time. And it might be exploring something new. It might be working on something specific. And then, when I need to accomplish something else, making sure that I block off the time on the calendar. And so that's working for me now. And it's not what I used to do. I used to be much more freeform. Nowadays, if I don't block off the time, I lose it.

+ +

Previously, I could maintain a lot of free time on my calendar and use that as the time I was doing things. And as we grew and as I was working with people more across all of thoughtbot, across many different time zones, I needed to be much more conscious about what my scheduled time actually looked like and make sure that I'm scheduling time to work on things more freeform.

+ +

NATALIE: Yeah, definitely. That's so helpful. And I like the idea of time blocking. I've been trying to do a little bit more of that. What's interesting, too, is as Harbour grows and the product grows, and thinking about scaling and trying to anticipate things before they happen, even though you can't anticipate everything, one of the exercises I've been thinking about is what would it feel like to have a team of this many people and meditate on that idea and see if it feels right? And do I necessarily need to have a team that looks like X or a team that looks like Y? And trying to meditate into what that experience would be before making the decision. And I'm wondering if, through your experience having run this global company and having scaled it over more than a decade, what are some of the things that you've done to pre-pave and to support the sustainable scaling of the business?

+ +

CHAD: I think thinking things through in advance is very important. And I don't say the next thing I'm about to say because it's not important because I think that it is very important, and I certainly do it. But I've also come to grips over the years with the idea that no matter how much we plan, it's not going to go like we plan. And so there's this interesting balance between planning too much and reacting to what's happening.

+ +

And I'll come back to intentionality. And the way that I talked about it at thoughtbot is letting fulfillment be our North Star. So we shouldn't be doing things just because we think they'll be good business decisions or because we think they're the right thing to do for some arbitrary reason. We should be driven by what we want to be doing in our work and what kind of company we want to be, and being fulfilled in our work.

+ +

And when we're faced with a decision to make about who we are, or what we do, or how we're going to approach this, letting it be driven by fulfillment is very powerful. Because it means that likely what everyone wants from their work is not so different from one another, especially when we curate a team of people that want to work together for our working lives what might be. It's probably not so different from each other.

+ +

So that's also very powerful because it means that I don't need to be the one to make all of the decisions. Other people can make those decisions around who we are and what we'll do, and which direction will head in. And they'll very likely be what will be fulfilling to the rest of the team as well. And so it sort of democratizes that decision-making in a way which is more resilient and then can be more flexible. As our best-laid plans start to go awry, we're making decisions based on fulfillment. And I think that allows us to be resilient.

+ +

NATALIE: Yeah, that's so helpful.

+ +

CHAD: Because so much of what we've tried, particularly when we intentionally try to grow, so many of the decisions that have made thoughtbot successful we weren't making them for business reasons, we were making them because --

+ +

NATALIE: They felt right.

+ +

CHAD: They felt right. We were the first consulting company in the world to switch to Ruby on Rails. We didn't make that decision because we thought Rails was going to be popular. We made it because, as developers and designers, we were more fulfilled using this new thing, Rails, than using PHP or Java. And, in fact, if we had been focused on what we thought would be the successful business thing, we might never have chosen that because it can feel very risky because you're choosing something entirely unknown.

+ +

So the opposite example is we've tried very hard to grow over the years non-organically geographically. So someone is moving to this area, or we are going to hire someone in this area. And we're going to grow into this area. And it's not driven necessarily by fulfillment. And in a lot of those cases, it's been very difficult, or it's outright not been successful. And so, being able to react to those situations and adjust has been critical for our long-term success.

+ +

Another word I use often is grit. And grit, for me, means we fail a bunch but we stay at it because we are driven by...what's driving that is fulfillment. So even if we really believe in it, even if we've failed in execution for business reasons or something like that, we tend to stick with it over the long term and just try a different way.

+ +

NATALIE: Yeah, I hear that. There is so much grit that's required to sustain something over a long period of time. And it feels like quite an incremental grit as opposed to huge pushes of energy that we might witness in different business models, for example, venture capital. And having been in the whirlwind of the VC world a little bit and now building what I hope is a more sustainable model, the grit is very moment to moment. It's continuous. Each task, each decision, it's a soft resilience that kind of grows over time as opposed to having to wield huge amounts of chutzpah to get through this investment cycle. Do you know what I mean?

+ +

CHAD: I do, and I think that has a flip side as well, which I try to be conscious of but don't always do a good job with. I tend not to project too far; that’s one side. And then the reverse is also true, which I tend not to celebrate successes enough. I tend not to reflect on the past too much because I'm on to the next incremental improvement pretty quickly. That has benefits because when you have a down day, tomorrow is a new day. It's a brand new day. But that has downsides too, which is when you have a great day, [laughs] you're on to the next thing the next day as well, at least for me. I move on very quickly. And like I said, I think that has its benefits, and it has its downsides.

+ +

NATALIE: What are your rituals for celebrating both personally and professionally? How do you celebrate yourself and the ways that you've grown? And how do you celebrate the business that you've grown with others?

+ +

CHAD: Just being honest, I probably have not...I do not have rituals. And I think this is where having good partners, or other members of my team has been helpful because knowing that this will be my tendency, having other people backing me up to recognize the successes or to call me on when I’m moving on too quickly or something like that has been helpful.

+ +

NATALIE: Yeah, definitely.

+ +

CHAD: Are you working on Harbour solo right now, or are you working with others?

+ +

NATALIE: Sure. Sometimes I work with a really wonderful ayurvedic practitioner called Sriram, who was an engineer for 15 years before he became an ayurvedic practitioner. So completely similar to you in that thought about going about and finding a co-founder or partnering with someone. And then I just had this really lovely chat with someone on Lunchclub. And we ended up talking about chakras for an hour and also coding. And I was like, this is my dream. [laughs] I get to talk about chakras, and I get to talk about product. This is great. And so, I work with Sriram sometimes on client work. Normally, the split is that he takes approximately a third of the client sessions, but we work on the one-to-one coaching.

+ +

And so, I'm your accountability coach. And we're hiring more now, which is really exciting. And I'll do the weekly reviews with clients, and then Sriram will put together the ayurvedic program for the client. So that's always really great fun. And I'm also working with a wonderful designer based in San Francisco called Christina. And yeah, so the three of us...Sriram has his own practice, and Christina has her own agency. But there's a lot of collaborative work that's happening there.

+ +

And I'm currently onboarding more coaches, which is exciting and very necessary because I came to a choice point, and I said, do I want to study chakras and become qualified? And I realized I didn't. I wanted to talk to all the people who knew about chakras and who were qualified, and so that's been a lovely experience onboarding them, and onboarding therapists, and onboarding other personal development coaches who are going to be able to serve clients as we scale.

+ +

CHAD: Nice. You mentioned Lunchclub many times in the story of Harbour on the website. I have never used Lunchclub. But I heard of it before. And if folks haven't heard of it, what's the pitch for Lunchclub?

+ +

[chuckles]

+ +

NATALIE: It's LinkedIn as you'd want it to be.

+ +

[laughter]

+ +

CHAD: Oh, that's great. That's great.

+ +

NATALIE: I think Lunchclub gets rid of all of the bravado and all of the stuff on LinkedIn because I think a lot of us do really struggle with self-promotion online. But at the same time, we want to connect with people. And we want to have real conversations that hopefully lead to more conversations or more opportunities for both parties.

+ +

And when I started on Lunchclub about a year and a half ago, it was just an incredible way to connect with people around the world. I'd just moved into a flat. I was living on my own in the middle of the pandemic and in the middle of the lockdown building product. And I thought, I really need to chat to people because I really enjoy doing that.

+ +

And through 45-minute conversations, you get matched by their little magical AI, and you connect with people who might be related to the interests that you have. And you can build streaks. And the more streaks you build, the more points you get. And the more points you get, the more you can choose who you connect with based on geography and business development goals, et cetera. Well, even if you do choose I want to meet an investor or I want to meet a Biz Dev specialist, this isn't really a sales call or an investment pitch. It's just I want to increase the likelihood that the person I meet will be aligned with where I'm trying to get on my journey.

+ +

CHAD: Well, the pandemic has been a really difficult time for everybody, parents, and of which I count myself in that. In particular, seeing it across thoughtbot, obviously, a trend is the people who live alone had an especially challenging time during the strictest of the lockdowns that were happening. And it was challenging. We saw a lot of people struggling. And because we were all remote, you're remote all day working. You don't necessarily want to be reaching out to people remotely, just that energy there. And I think that's maybe where Harbour comes in is solving that energy problem that I think many of us are feeling now.

+ +

NATALIE: Definitely. I think what happened over the last year and a half, two years, has created a tectonic shift, but I think also a portal because it's forced us to reckon with ourselves in ways that perhaps we had been ignoring, in ways that we didn't know we needed to, in ways that we've been forced to. And it can be really scary. And even as an adult, that's weird. It's weird to feel that scared as an adult. It's weird to feel that displaced as an adult. It's weird to feel so unmoored. It's weird to feel like you're starting from scratch again, not necessarily in terms of your career or what you post on LinkedIn about who you are, but inside that, you really are starting from scratch: Who am I without access to my friends? Who am I without access to family members? Who am I without X? Who am I without Y?

+ +

And so, the pandemic kind of energetically takes everything away, and so we can see ourselves more clearly. And that can be really strange because we haven't had the opportunity to do that in the past. And for many folks, often, we don't engage with mental health or well-being until something goes wrong. And we don't really engage with these ideas until we feel we're at a breaking point. And so the pandemic being the biggest breaking point we've had as a collective, at least in the Western world, we are forced to do that reckoning.

+ +

And so, of course, it's not just a loneliness pandemic; it's not just a burnout pandemic. I really do think it's an existential pandemic because people are wondering, or at least I am, and I know others who are, and I think others who are listening might be: Who am I? What am I here to do? What's my destiny? Why am I here? What's next? How do I make sense of all of the things that have happened in my life so far? And because there's no noise and no distraction or no busyness much as there was before the pandemic, you really are just there with yourself reckoning with those questions.

+ +

CHAD: Well, Natalie, I'm happy to see that someone emerged on the other side of this with a new product.

+ +

NATALIE: [laughs]

+ +

CHAD: And I wish you the best.

+ +

NATALIE: Thank you. Thank you very much.

+ +

CHAD: Again, if folks want to sign up or check it out more or just follow along with you, where are all the places that they can do that?

+ +

NATALIE: Sure. I would love for folks to connect on Instagram, harbour.today. You can also sign up to our newsletter. We have a daily email that comes out with questions from our community. So folks might ask things along the lines of what I've been describing, and we'll respond with some chakra guidance, some ancient philosophy that might be helpful, and also some practical tools, things that you can do like walking barefoot in your local park. Or some breathing exercises that might help you find balance within, or some yoga can really help you hack your chakras back into alignment, or some scripture that may help you reconnect with your divinity.

+ +

CHAD: Wonderful. You can subscribe to the show and find notes for this episode at giantrobots.fm. And we are emerging into this new season with full transcripts of every show as well. So you can find those on the website. And it will be included in the show notes, so they appear in your podcast player as well. I'm excited. It's something that we have been talking about doing for a while, but the time and expense of it traditionally was prohibitive. But we've made it happen for this new season in no small thanks to our new editor and producer, Mandy Moore.

+ +

So if you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and edited by Mandy Moore.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Natalie Nzeyimana.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9ox7KlM2 + + ]]> + + Chad Pytel + Natalie Nzeyimana + + + 396: Product Roadmaps Aren’t Dead; They Smell + https://podcast.thoughtbot.com/396 + 1c1025e2-aa1e-4615-a158-2c56bec7733b + Thu, 07 Oct 2021 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Lindsey and Chad talk about product roadmaps. Are they dead? Lindsey and Chad think they just smell. + +We also say an emotional goodbye to Lindsey as she moves on to new adventures. We miss you! + 45:38 + no + + + Lindsey and Chad talk about product roadmaps. Are they dead? Lindsey and Chad think they just smell. +We also say an emotional goodbye to Lindsey as she moves on to new adventures. We miss you! +Buffer Transparent Product Roadmap (https://trello.com/b/PDIV7XW3/buffer-transparent-product-roadmap) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +LINDSEY: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Lindsey Christensen. +CHAD: And I'm your other host, Chad Pytel. +LINDSEY: And today we're going to talk about product roadmaps. +CHAD: Product roadmaps. [laughs] +LINDSEY: Whoa. This is the topic. I feel like recently I've seen some thought pieces that product roadmaps are dead. So I'm curious if you think product roadmaps are dead. +CHAD: No, I don't think that they're dead, but I want to make the distinction too. I've never believed in a public product roadmap because I think that sets you up for just disappointing everyone involved, your customer, yourselves. And I think that there's a balance to be struck there. Saying that product roadmaps don't have a place, to me, in my mind, is like saying planning, having plans doesn't have a place and that just doesn't ring true to me. I think you should plan out what you're going to be working on. But I'm sure we'll get more into it. I also believe things about not having big backlogs and not doing too much planning and that kind of thing. So it depends on what you mean by a product roadmap. +LINDSEY: Well, yeah. I think that therein lies the issue. You can do it well, and you can also [laughs] run it into the ground. But you mentioned having it public and that being a bad idea. And I think at the core of product roadmaps is communication and alignment and getting all of your stakeholders on the same page about what you're building and why. So to me, I would think those stakeholders are the leadership team of the company, if this is a product company and product is the main business driver, the leadership of the company, the product team, of course, and engineering, sales, and marketing as well. Am I missing others? Clients, customers. +CHAD: Right. Customers. +LINDSEY: How do you feel about it? Does that count as the externally facing do not reveal? +CHAD: Oh yeah, it does for me. So we've all seen the companies that say that they're going to do something and then in a best-case scenario, that becomes a deadline which was arbitrarily made in the first place that everyone is stressing out over, that sales is potentially making promises that are either going to need to be broken or are going to need to be super stressed over. And then in a worst-case scenario, you end up not delivering on that roadmap as you essentially promised. And you actually end up with disappointed customers. +LINDSEY: So you would recommend not telling the customers about future features. +CHAD: Yeah. I think there's a balance to be struck there. So certainly, if you know that you're working on something now like actively working on something and a customer were to ask you about that thing directly, I might say, "Yeah, we're working on that now, and we're excited about getting it out to you." But I have only [chuckles] ever been a part of when a team is saying, "Q3 of next year, six months, nine months down the road, this specific feature is going to make it to customers." That's a real recipe, in my experience, a real recipe for lots of people being either really disappointed in that not happening or really working unsustainably in order to hit that in the first place. It's really hard to plan software that far in advance. +We just had the CEO of Dragon Innovation on the podcast. And I think that even then, you have to be careful with hardware, but at least with hardware or other kinds of businesses, it's a little bit easier to say, "Our goal is to have this incorporated in the product, or whatever, in the next revision of the hardware. And we expect to do that two years from now," or something like that. That's a little bit easier to put a bow around, I think. +LINDSEY: Yeah. I was a part of a software company that got acquired by a hardware company. And all of a sudden, we were wrapped into these 5 to 10-year product roadmaps that were blowing all of our minds [laughs] and a very different fit than how we were used to working. +CHAD: Yeah. It's worth noting that there are some companies that essentially go so far as to publish a Trello board of their roadmap. I don't know which ones they are. [chuckles] I have to find them. But even then, they're not necessarily making hard promises. And if you're committed to being transparent and publishing some roadmap to the public, the ways that I've seen it done best are working in themes. So you say, "Two quarters from now, our focus is going to be on reporting," or something like that. That is a little bit...because you're not making specific promises. You're just establishing a theme of what your focus is going to be on for that time. You can imagine you can still get yourself into a position where customers are putting all their hopes and dreams on what that's going to look like, and maybe your support staff or salespeople or whatever start to make promises about what's going to be delivered in that time. And then again, a bunch of people end up disappointed. +LINDSEY: Yeah. I've also seen what I think to be the most successful roadmaps be based around themes. And I think it’s also…again, going back to that, the fact that it's, in addition, to actually delivering product and delivering good product, it's helping align your internal team around what you're doing. So to rally your whole team or your whole company around reporting is the next big thing that we're working on, and this is why. This is what we've heard from users, from our research. And this is the direction we're going in and then actually getting everyone working towards reporting in their own ways. Marketing can be working on content around reporting. Hopefully, sales is seeding the idea of maybe not promising around reporting as well. +And that also really appeals to me as a marketer and as someone who's thinking often about how do we get folks moving in the same direction, speaking the same language and creating some momentum around something that can differentiate us, get people excited about what we're doing? Then hopefully, it's also strategically valuable to the company adding a new feature or entirely a new product. You're expanding your offering and maybe even your market reach. Who do you think are the most important folks within the company to be driving the product roadmap? Who owns the product roadmap? +CHAD: Well, [laughs] so if you have a company that has a roadmap...I'm getting distracted by the premise here. Let's just come back to that a bit. Momentum is key. You used the word momentum. And if you're feeling the need to plan things out or to gain a sense of clarity on your team about what's going to be done, and what's important, and you need to do a long-term roadmap in order to do that, that to me does point to it's sort of a smell. That's what we do when there's a code problem. We say it's a code smell. It points to if you had a team that was continually delivering value to your customers, to your users, and that you had a team where when sales, or marketing, or someone learned something about what will be valuable to customers and it's validated that it's valuable, and it gets put into the design and development process, and it comes out relatively soon, there's no need for a product roadmap. +Or I should say people don't feel the need for a product roadmap as much because they have high confidence that user needs are going to be met in a tight feedback cycle and that there's not a loss of momentum. And things going into the system are coming out in a week, two weeks, three weeks. Even four weeks, you can maintain that sense of momentum of we understood that this was important. We validated that it was. It went into the system, and it came out the other side, and it's in the hands of users. It's only when that starts to break down that stakeholders start to say, "We need to plan. We need a roadmap," because they lack the confidence that putting things into the system they're going to see them come out the other side in a way that maintains momentum. +LINDSEY: Does that depend on the size of the company? +CHAD: Well, ideally, even companies of large size are able to do that, but we all know that that's difficult. It may be that most companies just can't do that. And when that's the case, you have that breakdown. You have that lack of confidence. You have a system where you aren't putting things in and quickly seeing them come out the other side. And so that's where something like a product roadmap you start to say we need that in place. And I think that that's why it often happens as teams get bigger and as companies get more complex. +LINDSEY: Interesting. So product roadmaps are not dead, but roadmap can be a smell. +CHAD: Yes. [chuckles] Yeah, that's what I would say. That's my opinion. +LINDSEY: Who owns that smell? +CHAD: So now to get back to who owns the product roadmap, if your customers aren't the ones driving what's on the roadmap, then something is fundamentally broken. At the end of the day, the real owners of the product roadmap, even though they probably shouldn't see it, are the users, the customers. But I don't think that's the question you were asking. Who decides what's on the roadmap? It's got to be the people who are closest to hearing customers and who have the vision for what the product is supposed to be. So that will often be the company leadership, the CEO, the chief product officer, something like that combined with people who are talking with customers. +LINDSEY: So on the opposite end of the spectrum, if it's a big company, maybe it's a little bit harder to operate without the roadmap. If you're a really small and young company, let's say, and you already have a roadmap, is that too much? +CHAD: Well, this is a podcast, so we can have opinions. I would say [laughs] growth opinion, high-level position, yeah, you should probably not have that roadmap. Now the devil is in the details. What is the roadmap? Is it high-level themes? Is it I'm building this idea, and I'm a visionary about what this product is going to be, and I've laid out in broad strokes...we've done an initial version, a minimum viable product, and we have a vision for where we're going over the next year or two? There's a way to do that which doesn't then convert into this rigid product roadmap. And I think that that's what people who say product roadmaps are dead and you shouldn't be doing them; that’s what they're pushing against is that really rigid expectation setting system where promises get made and then broken. +LINDSEY: Right and promising especially deadlines far out into the future. +CHAD: And they also understand or believe that if you have a product roadmap, it potentially puts you in a position where you stop listening to customers because you say, "In six months, this is the thing that we're going to be working on." And then you get there, and you just work on it, and you deliver it without having learned along the way that the next most important thing might be something completely different. And so that's another risk with product roadmaps is you start working to the roadmap instead of working to what your users are telling you. So at that company, I'm not surprised to hear that it was a 5-year, 10-year thing, and then it's based off of a thing, Was it really concrete, or was it more sort of vision stuff? +LINDSEY: It was very concrete, I would say. +CHAD: Yeah. [laughs] +LINDSEY: And it's interesting because a lot of it was around trying to be first to market with cutting edge technologies. And on the hardware side, there was also R&D and multiple scientific teams working on specific things. And actually, to get more concrete, I think I can share without giving specifics. So it was 3D printing, and there's like an arms race in 3D printing to be able to print with new materials. So there are multiple teams working on trying to figure out how to print with new materials. And then we had these really long-term product roadmaps that were like by this year; we’re going to have gone to market with it and using that as a way to stay ahead of the competition basically. +CHAD: I can imagine that from a business perspective, you're looking at that situation, and you say...and this is true both in science and in software. But from a business perspective, it's saying, "If we don't have this deadline in place, then we have a research project that's just going to go on. We need this timeline, this deadline to hold everyone accountable to what a goal is and to make sure that we're bringing new products to market in that timeframe." And then the scientists are probably saying, "We have no idea. It's completely arbitrary. We think that we could do this, but what happens when we don't? What happens when we don't have something?" +A lot of times, I make an analogy between science and even software development and art because it is a creative process. It's all in our heads, and we're just coming up with it. You can say, "I need to have the book," or "I need to have this painting finished by this time." But it's very difficult to then ensure that that is actually going to happen at the creative level of saying, "I'm proud of this work, or it's good." It's hard to do that. +LINDSEY: Yeah, and I think there was an element too of either we will figure it out, or we will acquire whoever figures it out. And then there's a separate team that's off trying to suss out who's figuring it out and what are they willing to be bought for? [laughs] +CHAD: Right. And maybe from a business perspective, a lot of that makes sense. And you have to balance all of those things in order to try to be successful from a business perspective. +LINDSEY: Yeah. It's interesting on the hardware side, too, especially as you do get closer to actually launching. It can be very waterfall-esque working towards launch because there are so many dependencies in order to get the thing built and shipped and launched on time. +CHAD: I found a Quora thread about companies that have made their roadmap public. +LINDSEY: Did any do it successfully? +CHAD: [laughs] +LINDSEY: I've only seen nightmare stories. Like, let this be a lesson. Here's a company that made their roadmap public, and within weeks they were disappointing people. [laughs] +CHAD: I think that it's tempting, you know, and I think we should just do it. Part of the benefit of not having a roadmap that people say is that it allows not only the flexibility for what you're going to do to change based on what you learn. But the other is it offers you the opportunity to surprise and delight customers. And it allows you not to say, "This thing is six months away," but to say, "Here it is now." And one of the best examples of that that I think we're all familiar with is Apple. Apple doesn't typically pre-announce products that far in advance. And they're even a hardware company. They're clearly working on things years in the making. But they don't talk about them publicly until it's like, you can order this today, or you can order this on Wednesday. And the excitement and momentum that Apple builds around that is like the Charlie and the Chocolate Factory, Willy Wonka kind of secretive thing. It's super exciting to customers, and they're super successful doing it. +And last year, we had a really public thing where...actually, it was I guess two years ago that the saga started when Apple unusually announced AirPower, which is a charging mat that could charge both of your phone and your watch and everything all at the same time. They announced that far in advance. And then it actually ended up never shipping, and they eventually canceled the product. And they had to do all of that publicly, which is very, very different from Apple. I imagine that there are tons of products that Apple thinks that they're going to eventually release, and they don't work out, and they have to kill the projects. And all of that happens behind closed doors. +LINDSEY: So we don't know of anyone who does it successfully. What does Quora say? +CHAD: Quora doesn't know. A lot of the companies are not even in business anymore. [laughter] +LINDSEY: There you go. +CHAD: Buffer has apparently...Buffer has a transparent product roadmap. And I guess if there's any company that does transparency pretty well that I could point to, it would be Buffer. So we can link to that in the show notes. How does this board work? We've made this to give you a clear view into what we're working on, what we're about to work on, and what we're thinking about working on. We hope you enjoy the peek behind the scenes. They have four lanes: potential, next up, in progress, and done. They have voting enabled on their Trello board so their customers can vote on the different things that they have going on. +LINDSEY: Are you in the actual board? +CHAD: I am on the actual board, yeah. +LINDSEY: How many votes? What kind of numbers are we talking? +CHAD: So the in-progress thing that they are currently working on is a better way to manage campaigns in Buffer, and it has four votes. +LINDSEY: Oh. +CHAD: [laughs] So it doesn't seem like there's tons of engagement. There's another one, the best time to post to maximize your reach. It has seven votes. +LINDSEY: Okay, so a pretty low number. +CHAD: Pretty low. Oh, here's one, flexible pricing for Buffer has 67 votes. So I think you can get a little sense of the engagement that's on there. But I like that there's no description on these cards. It's just a better way to manage campaigns in Buffer. So they're not saying what they're going to be doing. There are no timelines on any of these cards. It was only moved to in progress. And they're not saying anything on these cards from what I can see about when it's going to be done or what is actually going to be entailed in it. I encourage people to look at this. It's pretty good in terms of potentially ways to make a public roadmap work for you and your customers. +LINDSEY: And what about thoughtbot? We also heavily gravitate towards the Trello management. +CHAD: Yeah. This is clearly not their actual Trello board. It's a specific board created for a transparent roadmap. +LINDSEY: It’s a distraction. +CHAD: [laughs] Yeah. If we were going to do something like this… +LINDSEY: I guess I meant as far as tools; what are the things that you have seen work with…? My guess would be Trello because we use that a lot for managing projects. +CHAD: Yeah, we use it for managing pretty much every project. And longtime followers of thoughtbot will know that we used to use a tool called Pivotal Tracker. And then, we created our own tool called Trajectory, which doesn't exist anymore. But the big thing about that was it was really meant to address the flow between coming up with ideas and the design thinking that goes into evolving a product idea and then breaking it down into stories and doing the stories from there. +And we switched to Trello in part because of the flexibility of Trello. Trello is not specific to any one product or any one workflow. And so, the nature of software development is again a reason why product roadmaps can be troublesome because things change constantly. You're constantly learning. You should be meeting on a regular feedback cycle of not only how is our product working for people and what should we do differently, but how is our process of developing that product working, and what should we be doing differently? That's one of the great things about Trello is that because it's so flexible, you can say, "Yeah, we're having this problem with our process. Let's change it." And you can usually find a way to embrace that flexibility in Trello. +LINDSEY: And how do you know that your product roadmap is on the right track? Or what are some smells that you're going in the wrong direction? We talk about customers being happy. What does that actually mean, and what does that look like? +CHAD: If the things that are going into what you're doing on your product are coming from users, and then they're going back to them, and they're receiving usage, that's a really good sign. And a lot of teams look at and measure cycle time, so the total time for something that goes into the process to come out the other side and get in the hands of users. And a lot of teams really high functioning teams will be working to make that as short as possible. And one of the reasons why is because that gives a sense to your customers that your product is continually moving forward in a way that comes from their needs. And that's a really good place to be in. You know what I mean? +LINDSEY: Yeah, that makes sense. +CHAD: Do you use any products where you feel like they've got that flow working really well? +LINDSEY: As far as asking for feedback and then incorporating it into the product? +CHAD: Yeah, or even just that you use the product and you're maybe not even giving them feedback directly, but you have a vague sense of how your need might not be met. And they're releasing features and that kind of thing on a semi-regular basis where you say, "I didn't even realize I needed that, but now that I have it, it makes me happy." Or "Boy, that really solved this problem that I was facing." +LINDSEY: I think the one that comes to mind immediately is Slack, actually. I feel like their product releases often speak to something I was feeling. Like, I think especially they seem attuned to the fact that it can create a lot of noise. And so providing or increasing the different ways that you can personalize your own experience so that you can mute things or have certain kinds of notifications or be able to set hours that you're away and unavailable. Those releases, I think, feel especially personal when I see those come through. +CHAD: I think you're right. Slack is one where that would be the case. And it's worth noting that Slack does publish a roadmap, and they've been doing it for a couple of years. Particularly, it seems like, from the outside, a big part of what drove that and what's in their marketing around it is better setting expectations with their enterprise customers and that sort of thing rather than necessarily not meeting the needs of actual users. +LINDSEY: They also seem especially responsive and helpful out in the world too. I've seen multiple instances of folks I know tweeting about a bug or something in Slack, and very quickly, the Slack account is responding with how to fix it or notifying that it's been logged in, and they'll be following up, that kind of thing. +CHAD: So I'm looking at the Slack one a little bit more, and it seems like the roadmap is centered primarily around what they call the platform roadmap. So it's more like APIs and system-level things that they're going to be focusing on or adding rather than user-facing features. So it's more serving the needs of people who are building on top of the Slack platform versus saying that their product is going to have a specific feature at this time that's user-facing. +LINDSEY: That's interesting. +CHAD: Which makes sense because people building on top of the Slack platform who are really dependent for their business needs on the Slack platform are going to have high expectations for knowing what's coming and knowing that their needs are being addressed at some point in the future. +LINDSEY: Right. And on the enterprise side, as they're getting more enterprise customers, I imagine that could come into play as well where enterprise companies are going to have some dependencies or requirements that maybe the Slack team hasn't had to deal with before, which could be integrations. It could be certain kinds of security measures, which if they're definitely working on those or creating the necessary partnerships, it can also make sense to say, "We have in our sites this integration or the security measure coming by the end of the year," kind of thing. +CHAD: Yeah. So one that I have...and it's interesting because I think they've been doing a good job lately, but they went through a real period of time where I felt like they weren't doing as good a job with it, and it’s GitHub. So GitHub lately has done a much better job of, for me as a developer, as a user of GitHub every day, delivering features where it's like, yeah, this is awesome, and it fills a need or a pain that I was really having. Or I didn't even realize that I was going to need this feature, and now that it's here, I can't imagine it being any different. +And they do that, as far as I know, there's not a public roadmap for GitHub. And GitHub, I could be completely wrong on this; they do a conference. They do shows. And what they're doing at that is they're announcing things. So they're more on the sliding scale towards Apple, where they're announcing general availability or beta availability of new features at their events as opposed to saying, "Here's what the roadmap for the next year looks like." +LINDSEY: Which does create a forcing function of having things ready enough, maybe not launchable but ready enough that you can at least talk about it and talk about the timeline. +CHAD: Yeah. And we had the product manager of the payments that GitHub announced on a previous episode. Her name's Devon. And that's one of the things she talked about was working towards that deadline of that presentation and how stressful it was and making sure that they manage scope within that. +LINDSEY: So, do you think GitHub has been doing a better job since they were acquired? +CHAD: It doesn't so much match since when they've been acquired, but there was a period of time where...and maybe it could be that there's nothing GitHub-specific about this, but there's probably a period in every product's time where you go from this is a new thing, and so there are so many new features that are low hanging fruit. And you can quickly roll them out, bang, bang, bang for a long period of time. Your roadmap is just sitting there in front of you, waiting for you to do it. You don't need to worry too much about it. That's, depending on the product, probably six months, a year, two years, maybe even five years. But then you're going to work your way through that list and the things that you do next, particularly if you reach a growth stage, which means that your core customers may be different than your original core customers…where you can enter a lull. And you need to take some time to figure out what the next phase of your product looks like. It's possible that it happened with GitHub. +I tend to think that it's more that internally GitHub had real challenges. And we know it had some issues with sexual harassment and workplace issues like that. I think that really got in the way of GitHub functioning well. That's my theory. But again, I'm totally on the outside. But I do know that they went through some significant restructuring and addressing a lot of those issues and creating what is hopefully a more inclusive workplace where people can do their best work. And then good work started to come out again. +LINDSEY: As far as launching products or new features, it's always interesting and challenging I think with SaaS products where you're continuously releasing improvements and how you think about…again, from the marketing fun of it too a little bit, is like how you think about when is something like a new launch? When is something a significant enough new feature? Is this actually a separate product from what we've been offering? And sometimes, that can be really obvious. Going back to the reporting example, that's a nice kind of shiny new toy in your platform that you're going to have, like a dashboard. The difficult ones are performance improvements. But I was curious if you have any takes on that too. +CHAD: Yeah. What I've always done on the products that I've worked on...and thoughtbot has created several products that have been fairly successful not only for our clients but for ourselves as well. I've always favored not underestimating people's ability to absorb significant product changes as long as they're coming from a place of you know that they are needed. And that if you're shipping regular new things on a basis, not all of your customers know about that right away, and so you can take a marketing touchpoint for those changes. And even though you have a sense of urgency about communicating them right away, you do have some time to do that. +I think I said earlier when I was starting out, "Underestimate people." What I think I meant was overestimate. We, as people who are very close to the product, assume that the minute we deploy a new feature or a change that everyone in the world is going to know about it. And that's just not the reality of what it's going to be. So when rolling out new features, you have to communicate them to the people who are touching them and are who are hitting them. +But there are almost multiple layers of marketing and communication for any new feature that's going out, communicating with immediate customers that are touching a new feature, and then making sure that everything that's going out is flowing through marketing and is coordinated with marketing around what those touchpoints are going to be. And the general guideline that I've always used is at least once a month; there should be a major round-up or communication about a significant change that has been made. And I've always felt really good about the products that I was working on if we were in that cycle like we're continually delivering new things. But then, on a monthly basis, there's at least one new either individually significant thing that we can talk about. Or absent of that, doing a roundup of a theme of changes or just here are three major improvements we've made in the last month. +LINDSEY: Yeah, I totally agree. It's great to have those opportunities to engage with customers and keep them invested in the product, and looking forward to those regular updates as well. +CHAD: Right. So when we think back to Trello boards or roadmaps and that kind of thing, I don't think marketing should be…after that fact, marketing shouldn't be saying like, "What was just released? Can we know?" and then responding to it. Marketing should have insight into what's in the backlog, what's the next things that are going into production. What are the things we're planning now? And they should be contributing to that process because, in a lot of companies, marketing is going to be on the front lines of interacting with customers. So you're going to hear things, and you're going to see things and that should contribute to the process. +LINDSEY: Right. Ideally, the marketing team is also customer-facing and providing those insights as well and tapped into what folks are having challenges with or looking forward to as well as what else they have their eye on that others are offering or trying out that are your competition. +CHAD: So that's the cadence that when I'm in charge of a product, I've tried to achieve. It's easier to do in the early days of a product when, like I was saying, you don't even need the roadmap. There's so much low-hanging fruit, and everything is valuable, and the priorities are relatively clear. It's harder to maintain that pace far into your product's future not only because what you're doing is less clear and maybe less valuable to all of your customers but also that daily, weekly, monthly pace can be difficult to keep up indefinitely just from a sustainability standpoint. +LINDSEY: Yeah. I feel like sometimes I even see products incorporating content in those later stages as ways to keep folks engaged and updated and have that be a feature of the product, whether it's community-based or the company itself actually producing new content and incorporating that into the product. +CHAD: Yeah. So a really good example of that is (Boy, we've had a lot of good people on the podcast.) the folks at Wistia, which is a local company to Boston. And they're continually evolving what their product is offering. And they're launching new features. They're doing new things. But a big part of what you see publicly from them is also new content that helps people be better creators. So they are a good example that comes to mind of a company that does that pretty well. +LINDSEY: So, we're going to be talking to three other startups of different stages in different industries about how they approach their product roadmap. Any sense for what might be consistent versus what is different? I imagine you also have insight from seeing a ton of client projects. Are certain areas of product roadmap more consistent than others? +CHAD: I suspect what we're going to hear from the early-stage companies is that they actually have what...They're probably either going to say, "We have no idea. We're just flying by the seat of our pants." But actually, I think it wouldn't be surprising to me if there's just so much low-hanging fruit in front of us that that gives them a sense of a clear product roadmap. And they say, "Yeah, we do know. We do have a sense of what we're going to be doing next week and the week after." But they're going to not be so worried about what six months from now looks like. +And I think a common trend of later-stage companies is I wouldn't be surprised to hear that they're very focused on partnerships and external relationships in a way that early companies aren't. And that is one of the factors which we haven't really touched on is, anytime you start involving external people the same way with Slack; it’s like people who are depending on you for their own business needs outside of your users creates more pressure for you to set expectations with them and to introduce roadmaps. So companies that are really focused on that who have channels and partnerships and that kind of thing are going to have more desire or pressure to introduce some form of roadmap. +LINDSEY: Yeah. And in a way, that's the later stage companies' low-hanging fruit. When you bring in a partner, or you make an acquisition and immediately fill in a need that you've identified or an opportunity that you've identified, instead of taking your existing team to build it, or hire a team, or work with someone like thoughtbot. +CHAD: Yeah. And it could be that that is actually totally the right thing. Because if you give everybody the benefit of the doubt and you say, "This product has been well-managed and user-centric to meet the needs of the users, then you're going to get that cycle." In the early days, we know what we should be doing, and our users are telling us. And we've got a lot of things to introduce into the product to fully meet the needs of those customers. And you're going to do that, and it's going to serve you for a really long time for delivering new things to them. +But at some point, again, giving the benefit of the doubt, assuming you've done that and things have gone well, there is a point at which you say, "We've delivered all of that. And we have a product which is meeting the needs of our users. It's fulfilling the job to be done of those users." You say, "Okay, great." So we're either bringing new people in who might have different needs and different jobs to be done. Or we are exploring other business opportunities like bringing on partners and opening up new channels which have their own needs that are driving your product roadmap, or they're bringing in customers who have a different job to be done. +LINDSEY: And honestly, it's an easy way for early-stage companies too to add a partner and gain access to their audience. But it's not likely that they're going to want to partner with you [laughs] because you're not bringing anything to the table, so you got to do that building first. +CHAD: Yeah. So we'll see what they say. I'm looking forward to the conversations. So, Linsdey, you have some personal news. +LINDSEY: Yes. With mixed emotions, I'll be moving on from thoughtbot and the podcast. +CHAD: This comes as a complete surprise to me. You're just springing this to me on the podcast. +LINDSEY: I know. I know I told you I wanted you to join five minutes earlier. And it's inappropriate. +CHAD: [chuckles] +LINDSEY: No, that's not true. I used all the proper channels. I read the handbook. But yeah, end of an era, moving on. But dang, it's been a lot of fun, hasn't it? +CHAD: It has been fun. It's been great working with you. The impact that you've had on thoughtbot will be long-lasting. It was significant and long-lasting. I think that you joined at a really interesting time. Pandemic and all that stuff aside, completely separate from that, we were going through important transitions, and I think you're an important part of this. I remember commenting to you not long after you joined when you gave the first company-wide presentation that you were the first person I think who had ever done a full company-wide presentation like that, besides me. +LINDSEY: Yeah. Wow. This feels like so long ago. +CHAD: And you're just so fun to work with and collaborate with and just be a team member with that you're definitely going to be missed. So thank you for everything. +LINDSEY: Thank you. I am definitely not tearing up. So no one has to worry about that. It's hard to look back without getting choked up. It's been a really great experience. [laughter] +CHAD: I'm glad to hear that. You brought so much to the table. We learned a lot along the way, and it wasn't always easy. We had a marketing team working in a certain way, which went through a big change. I think we learned a lot about how the next phase of thoughtbot needs to work, and I think you're an important part of getting there. So thanks again. +LINDSEY: Thanks for having me. Thanks to all of you for listening. And I'm now available as a guest, which is the great news. +CHAD: [laughs] +LINDSEY: And I almost know how to set up all my recording settings, so that's half the battle. But it's been real, and thank you for the opportunity from the experience. +CHAD: So we will be back in a little while with new episodes of the show. You can subscribe to the show and find notes for this episode at giantrobots.fm. +If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. And for all you listeners out there, I'll talk to you next time. Bye. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Lindsey and Chad talk about product roadmaps. Are they dead? Lindsey and Chad think they just smell.

+ +

We also say an emotional goodbye to Lindsey as she moves on to new adventures. We miss you!

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Lindsey Christensen.

+ +

CHAD: And I'm your other host, Chad Pytel.

+ +

LINDSEY: And today we're going to talk about product roadmaps.

+ +

CHAD: Product roadmaps. [laughs]

+ +

LINDSEY: Whoa. This is the topic. I feel like recently I've seen some thought pieces that product roadmaps are dead. So I'm curious if you think product roadmaps are dead.

+ +

CHAD: No, I don't think that they're dead, but I want to make the distinction too. I've never believed in a public product roadmap because I think that sets you up for just disappointing everyone involved, your customer, yourselves. And I think that there's a balance to be struck there. Saying that product roadmaps don't have a place, to me, in my mind, is like saying planning, having plans doesn't have a place and that just doesn't ring true to me. I think you should plan out what you're going to be working on. But I'm sure we'll get more into it. I also believe things about not having big backlogs and not doing too much planning and that kind of thing. So it depends on what you mean by a product roadmap.

+ +

LINDSEY: Well, yeah. I think that therein lies the issue. You can do it well, and you can also [laughs] run it into the ground. But you mentioned having it public and that being a bad idea. And I think at the core of product roadmaps is communication and alignment and getting all of your stakeholders on the same page about what you're building and why. So to me, I would think those stakeholders are the leadership team of the company, if this is a product company and product is the main business driver, the leadership of the company, the product team, of course, and engineering, sales, and marketing as well. Am I missing others? Clients, customers.

+ +

CHAD: Right. Customers.

+ +

LINDSEY: How do you feel about it? Does that count as the externally facing do not reveal?

+ +

CHAD: Oh yeah, it does for me. So we've all seen the companies that say that they're going to do something and then in a best-case scenario, that becomes a deadline which was arbitrarily made in the first place that everyone is stressing out over, that sales is potentially making promises that are either going to need to be broken or are going to need to be super stressed over. And then in a worst-case scenario, you end up not delivering on that roadmap as you essentially promised. And you actually end up with disappointed customers.

+ +

LINDSEY: So you would recommend not telling the customers about future features.

+ +

CHAD: Yeah. I think there's a balance to be struck there. So certainly, if you know that you're working on something now like actively working on something and a customer were to ask you about that thing directly, I might say, "Yeah, we're working on that now, and we're excited about getting it out to you." But I have only [chuckles] ever been a part of when a team is saying, "Q3 of next year, six months, nine months down the road, this specific feature is going to make it to customers." That's a real recipe, in my experience, a real recipe for lots of people being either really disappointed in that not happening or really working unsustainably in order to hit that in the first place. It's really hard to plan software that far in advance.

+ +

We just had the CEO of Dragon Innovation on the podcast. And I think that even then, you have to be careful with hardware, but at least with hardware or other kinds of businesses, it's a little bit easier to say, "Our goal is to have this incorporated in the product, or whatever, in the next revision of the hardware. And we expect to do that two years from now," or something like that. That's a little bit easier to put a bow around, I think.

+ +

LINDSEY: Yeah. I was a part of a software company that got acquired by a hardware company. And all of a sudden, we were wrapped into these 5 to 10-year product roadmaps that were blowing all of our minds [laughs] and a very different fit than how we were used to working.

+ +

CHAD: Yeah. It's worth noting that there are some companies that essentially go so far as to publish a Trello board of their roadmap. I don't know which ones they are. [chuckles] I have to find them. But even then, they're not necessarily making hard promises. And if you're committed to being transparent and publishing some roadmap to the public, the ways that I've seen it done best are working in themes. So you say, "Two quarters from now, our focus is going to be on reporting," or something like that. That is a little bit...because you're not making specific promises. You're just establishing a theme of what your focus is going to be on for that time. You can imagine you can still get yourself into a position where customers are putting all their hopes and dreams on what that's going to look like, and maybe your support staff or salespeople or whatever start to make promises about what's going to be delivered in that time. And then again, a bunch of people end up disappointed.

+ +

LINDSEY: Yeah. I've also seen what I think to be the most successful roadmaps be based around themes. And I think it’s also…again, going back to that, the fact that it's, in addition, to actually delivering product and delivering good product, it's helping align your internal team around what you're doing. So to rally your whole team or your whole company around reporting is the next big thing that we're working on, and this is why. This is what we've heard from users, from our research. And this is the direction we're going in and then actually getting everyone working towards reporting in their own ways. Marketing can be working on content around reporting. Hopefully, sales is seeding the idea of maybe not promising around reporting as well.

+ +

And that also really appeals to me as a marketer and as someone who's thinking often about how do we get folks moving in the same direction, speaking the same language and creating some momentum around something that can differentiate us, get people excited about what we're doing? Then hopefully, it's also strategically valuable to the company adding a new feature or entirely a new product. You're expanding your offering and maybe even your market reach. Who do you think are the most important folks within the company to be driving the product roadmap? Who owns the product roadmap?

+ +

CHAD: Well, [laughs] so if you have a company that has a roadmap...I'm getting distracted by the premise here. Let's just come back to that a bit. Momentum is key. You used the word momentum. And if you're feeling the need to plan things out or to gain a sense of clarity on your team about what's going to be done, and what's important, and you need to do a long-term roadmap in order to do that, that to me does point to it's sort of a smell. That's what we do when there's a code problem. We say it's a code smell. It points to if you had a team that was continually delivering value to your customers, to your users, and that you had a team where when sales, or marketing, or someone learned something about what will be valuable to customers and it's validated that it's valuable, and it gets put into the design and development process, and it comes out relatively soon, there's no need for a product roadmap.

+ +

Or I should say people don't feel the need for a product roadmap as much because they have high confidence that user needs are going to be met in a tight feedback cycle and that there's not a loss of momentum. And things going into the system are coming out in a week, two weeks, three weeks. Even four weeks, you can maintain that sense of momentum of we understood that this was important. We validated that it was. It went into the system, and it came out the other side, and it's in the hands of users. It's only when that starts to break down that stakeholders start to say, "We need to plan. We need a roadmap," because they lack the confidence that putting things into the system they're going to see them come out the other side in a way that maintains momentum.

+ +

LINDSEY: Does that depend on the size of the company?

+ +

CHAD: Well, ideally, even companies of large size are able to do that, but we all know that that's difficult. It may be that most companies just can't do that. And when that's the case, you have that breakdown. You have that lack of confidence. You have a system where you aren't putting things in and quickly seeing them come out the other side. And so that's where something like a product roadmap you start to say we need that in place. And I think that that's why it often happens as teams get bigger and as companies get more complex.

+ +

LINDSEY: Interesting. So product roadmaps are not dead, but roadmap can be a smell.

+ +

CHAD: Yes. [chuckles] Yeah, that's what I would say. That's my opinion.

+ +

LINDSEY: Who owns that smell?

+ +

CHAD: So now to get back to who owns the product roadmap, if your customers aren't the ones driving what's on the roadmap, then something is fundamentally broken. At the end of the day, the real owners of the product roadmap, even though they probably shouldn't see it, are the users, the customers. But I don't think that's the question you were asking. Who decides what's on the roadmap? It's got to be the people who are closest to hearing customers and who have the vision for what the product is supposed to be. So that will often be the company leadership, the CEO, the chief product officer, something like that combined with people who are talking with customers.

+ +

LINDSEY: So on the opposite end of the spectrum, if it's a big company, maybe it's a little bit harder to operate without the roadmap. If you're a really small and young company, let's say, and you already have a roadmap, is that too much?

+ +

CHAD: Well, this is a podcast, so we can have opinions. I would say [laughs] growth opinion, high-level position, yeah, you should probably not have that roadmap. Now the devil is in the details. What is the roadmap? Is it high-level themes? Is it I'm building this idea, and I'm a visionary about what this product is going to be, and I've laid out in broad strokes...we've done an initial version, a minimum viable product, and we have a vision for where we're going over the next year or two? There's a way to do that which doesn't then convert into this rigid product roadmap. And I think that that's what people who say product roadmaps are dead and you shouldn't be doing them; that’s what they're pushing against is that really rigid expectation setting system where promises get made and then broken.

+ +

LINDSEY: Right and promising especially deadlines far out into the future.

+ +

CHAD: And they also understand or believe that if you have a product roadmap, it potentially puts you in a position where you stop listening to customers because you say, "In six months, this is the thing that we're going to be working on." And then you get there, and you just work on it, and you deliver it without having learned along the way that the next most important thing might be something completely different. And so that's another risk with product roadmaps is you start working to the roadmap instead of working to what your users are telling you. So at that company, I'm not surprised to hear that it was a 5-year, 10-year thing, and then it's based off of a thing, Was it really concrete, or was it more sort of vision stuff?

+ +

LINDSEY: It was very concrete, I would say.

+ +

CHAD: Yeah. [laughs]

+ +

LINDSEY: And it's interesting because a lot of it was around trying to be first to market with cutting edge technologies. And on the hardware side, there was also R&D and multiple scientific teams working on specific things. And actually, to get more concrete, I think I can share without giving specifics. So it was 3D printing, and there's like an arms race in 3D printing to be able to print with new materials. So there are multiple teams working on trying to figure out how to print with new materials. And then we had these really long-term product roadmaps that were like by this year; we’re going to have gone to market with it and using that as a way to stay ahead of the competition basically.

+ +

CHAD: I can imagine that from a business perspective, you're looking at that situation, and you say...and this is true both in science and in software. But from a business perspective, it's saying, "If we don't have this deadline in place, then we have a research project that's just going to go on. We need this timeline, this deadline to hold everyone accountable to what a goal is and to make sure that we're bringing new products to market in that timeframe." And then the scientists are probably saying, "We have no idea. It's completely arbitrary. We think that we could do this, but what happens when we don't? What happens when we don't have something?"

+ +

A lot of times, I make an analogy between science and even software development and art because it is a creative process. It's all in our heads, and we're just coming up with it. You can say, "I need to have the book," or "I need to have this painting finished by this time." But it's very difficult to then ensure that that is actually going to happen at the creative level of saying, "I'm proud of this work, or it's good." It's hard to do that.

+ +

LINDSEY: Yeah, and I think there was an element too of either we will figure it out, or we will acquire whoever figures it out. And then there's a separate team that's off trying to suss out who's figuring it out and what are they willing to be bought for? [laughs]

+ +

CHAD: Right. And maybe from a business perspective, a lot of that makes sense. And you have to balance all of those things in order to try to be successful from a business perspective.

+ +

LINDSEY: Yeah. It's interesting on the hardware side, too, especially as you do get closer to actually launching. It can be very waterfall-esque working towards launch because there are so many dependencies in order to get the thing built and shipped and launched on time.

+ +

CHAD: I found a Quora thread about companies that have made their roadmap public.

+ +

LINDSEY: Did any do it successfully?

+ +

CHAD: [laughs]

+ +

LINDSEY: I've only seen nightmare stories. Like, let this be a lesson. Here's a company that made their roadmap public, and within weeks they were disappointing people. [laughs]

+ +

CHAD: I think that it's tempting, you know, and I think we should just do it. Part of the benefit of not having a roadmap that people say is that it allows not only the flexibility for what you're going to do to change based on what you learn. But the other is it offers you the opportunity to surprise and delight customers. And it allows you not to say, "This thing is six months away," but to say, "Here it is now." And one of the best examples of that that I think we're all familiar with is Apple. Apple doesn't typically pre-announce products that far in advance. And they're even a hardware company. They're clearly working on things years in the making. But they don't talk about them publicly until it's like, you can order this today, or you can order this on Wednesday. And the excitement and momentum that Apple builds around that is like the Charlie and the Chocolate Factory, Willy Wonka kind of secretive thing. It's super exciting to customers, and they're super successful doing it.

+ +

And last year, we had a really public thing where...actually, it was I guess two years ago that the saga started when Apple unusually announced AirPower, which is a charging mat that could charge both of your phone and your watch and everything all at the same time. They announced that far in advance. And then it actually ended up never shipping, and they eventually canceled the product. And they had to do all of that publicly, which is very, very different from Apple. I imagine that there are tons of products that Apple thinks that they're going to eventually release, and they don't work out, and they have to kill the projects. And all of that happens behind closed doors.

+ +

LINDSEY: So we don't know of anyone who does it successfully. What does Quora say?

+ +

CHAD: Quora doesn't know. A lot of the companies are not even in business anymore. [laughter]

+ +

LINDSEY: There you go.

+ +

CHAD: Buffer has apparently...Buffer has a transparent product roadmap. And I guess if there's any company that does transparency pretty well that I could point to, it would be Buffer. So we can link to that in the show notes. How does this board work? We've made this to give you a clear view into what we're working on, what we're about to work on, and what we're thinking about working on. We hope you enjoy the peek behind the scenes. They have four lanes: potential, next up, in progress, and done. They have voting enabled on their Trello board so their customers can vote on the different things that they have going on.

+ +

LINDSEY: Are you in the actual board?

+ +

CHAD: I am on the actual board, yeah.

+ +

LINDSEY: How many votes? What kind of numbers are we talking?

+ +

CHAD: So the in-progress thing that they are currently working on is a better way to manage campaigns in Buffer, and it has four votes.

+ +

LINDSEY: Oh.

+ +

CHAD: [laughs] So it doesn't seem like there's tons of engagement. There's another one, the best time to post to maximize your reach. It has seven votes.

+ +

LINDSEY: Okay, so a pretty low number.

+ +

CHAD: Pretty low. Oh, here's one, flexible pricing for Buffer has 67 votes. So I think you can get a little sense of the engagement that's on there. But I like that there's no description on these cards. It's just a better way to manage campaigns in Buffer. So they're not saying what they're going to be doing. There are no timelines on any of these cards. It was only moved to in progress. And they're not saying anything on these cards from what I can see about when it's going to be done or what is actually going to be entailed in it. I encourage people to look at this. It's pretty good in terms of potentially ways to make a public roadmap work for you and your customers.

+ +

LINDSEY: And what about thoughtbot? We also heavily gravitate towards the Trello management.

+ +

CHAD: Yeah. This is clearly not their actual Trello board. It's a specific board created for a transparent roadmap.

+ +

LINDSEY: It’s a distraction.

+ +

CHAD: [laughs] Yeah. If we were going to do something like this…

+ +

LINDSEY: I guess I meant as far as tools; what are the things that you have seen work with…? My guess would be Trello because we use that a lot for managing projects.

+ +

CHAD: Yeah, we use it for managing pretty much every project. And longtime followers of thoughtbot will know that we used to use a tool called Pivotal Tracker. And then, we created our own tool called Trajectory, which doesn't exist anymore. But the big thing about that was it was really meant to address the flow between coming up with ideas and the design thinking that goes into evolving a product idea and then breaking it down into stories and doing the stories from there.

+ +

And we switched to Trello in part because of the flexibility of Trello. Trello is not specific to any one product or any one workflow. And so, the nature of software development is again a reason why product roadmaps can be troublesome because things change constantly. You're constantly learning. You should be meeting on a regular feedback cycle of not only how is our product working for people and what should we do differently, but how is our process of developing that product working, and what should we be doing differently? That's one of the great things about Trello is that because it's so flexible, you can say, "Yeah, we're having this problem with our process. Let's change it." And you can usually find a way to embrace that flexibility in Trello.

+ +

LINDSEY: And how do you know that your product roadmap is on the right track? Or what are some smells that you're going in the wrong direction? We talk about customers being happy. What does that actually mean, and what does that look like?

+ +

CHAD: If the things that are going into what you're doing on your product are coming from users, and then they're going back to them, and they're receiving usage, that's a really good sign. And a lot of teams look at and measure cycle time, so the total time for something that goes into the process to come out the other side and get in the hands of users. And a lot of teams really high functioning teams will be working to make that as short as possible. And one of the reasons why is because that gives a sense to your customers that your product is continually moving forward in a way that comes from their needs. And that's a really good place to be in. You know what I mean?

+ +

LINDSEY: Yeah, that makes sense.

+ +

CHAD: Do you use any products where you feel like they've got that flow working really well?

+ +

LINDSEY: As far as asking for feedback and then incorporating it into the product?

+ +

CHAD: Yeah, or even just that you use the product and you're maybe not even giving them feedback directly, but you have a vague sense of how your need might not be met. And they're releasing features and that kind of thing on a semi-regular basis where you say, "I didn't even realize I needed that, but now that I have it, it makes me happy." Or "Boy, that really solved this problem that I was facing."

+ +

LINDSEY: I think the one that comes to mind immediately is Slack, actually. I feel like their product releases often speak to something I was feeling. Like, I think especially they seem attuned to the fact that it can create a lot of noise. And so providing or increasing the different ways that you can personalize your own experience so that you can mute things or have certain kinds of notifications or be able to set hours that you're away and unavailable. Those releases, I think, feel especially personal when I see those come through.

+ +

CHAD: I think you're right. Slack is one where that would be the case. And it's worth noting that Slack does publish a roadmap, and they've been doing it for a couple of years. Particularly, it seems like, from the outside, a big part of what drove that and what's in their marketing around it is better setting expectations with their enterprise customers and that sort of thing rather than necessarily not meeting the needs of actual users.

+ +

LINDSEY: They also seem especially responsive and helpful out in the world too. I've seen multiple instances of folks I know tweeting about a bug or something in Slack, and very quickly, the Slack account is responding with how to fix it or notifying that it's been logged in, and they'll be following up, that kind of thing.

+ +

CHAD: So I'm looking at the Slack one a little bit more, and it seems like the roadmap is centered primarily around what they call the platform roadmap. So it's more like APIs and system-level things that they're going to be focusing on or adding rather than user-facing features. So it's more serving the needs of people who are building on top of the Slack platform versus saying that their product is going to have a specific feature at this time that's user-facing.

+ +

LINDSEY: That's interesting.

+ +

CHAD: Which makes sense because people building on top of the Slack platform who are really dependent for their business needs on the Slack platform are going to have high expectations for knowing what's coming and knowing that their needs are being addressed at some point in the future.

+ +

LINDSEY: Right. And on the enterprise side, as they're getting more enterprise customers, I imagine that could come into play as well where enterprise companies are going to have some dependencies or requirements that maybe the Slack team hasn't had to deal with before, which could be integrations. It could be certain kinds of security measures, which if they're definitely working on those or creating the necessary partnerships, it can also make sense to say, "We have in our sites this integration or the security measure coming by the end of the year," kind of thing.

+ +

CHAD: Yeah. So one that I have...and it's interesting because I think they've been doing a good job lately, but they went through a real period of time where I felt like they weren't doing as good a job with it, and it’s GitHub. So GitHub lately has done a much better job of, for me as a developer, as a user of GitHub every day, delivering features where it's like, yeah, this is awesome, and it fills a need or a pain that I was really having. Or I didn't even realize that I was going to need this feature, and now that it's here, I can't imagine it being any different.

+ +

And they do that, as far as I know, there's not a public roadmap for GitHub. And GitHub, I could be completely wrong on this; they do a conference. They do shows. And what they're doing at that is they're announcing things. So they're more on the sliding scale towards Apple, where they're announcing general availability or beta availability of new features at their events as opposed to saying, "Here's what the roadmap for the next year looks like."

+ +

LINDSEY: Which does create a forcing function of having things ready enough, maybe not launchable but ready enough that you can at least talk about it and talk about the timeline.

+ +

CHAD: Yeah. And we had the product manager of the payments that GitHub announced on a previous episode. Her name's Devon. And that's one of the things she talked about was working towards that deadline of that presentation and how stressful it was and making sure that they manage scope within that.

+ +

LINDSEY: So, do you think GitHub has been doing a better job since they were acquired?

+ +

CHAD: It doesn't so much match since when they've been acquired, but there was a period of time where...and maybe it could be that there's nothing GitHub-specific about this, but there's probably a period in every product's time where you go from this is a new thing, and so there are so many new features that are low hanging fruit. And you can quickly roll them out, bang, bang, bang for a long period of time. Your roadmap is just sitting there in front of you, waiting for you to do it. You don't need to worry too much about it. That's, depending on the product, probably six months, a year, two years, maybe even five years. But then you're going to work your way through that list and the things that you do next, particularly if you reach a growth stage, which means that your core customers may be different than your original core customers…where you can enter a lull. And you need to take some time to figure out what the next phase of your product looks like. It's possible that it happened with GitHub.

+ +

I tend to think that it's more that internally GitHub had real challenges. And we know it had some issues with sexual harassment and workplace issues like that. I think that really got in the way of GitHub functioning well. That's my theory. But again, I'm totally on the outside. But I do know that they went through some significant restructuring and addressing a lot of those issues and creating what is hopefully a more inclusive workplace where people can do their best work. And then good work started to come out again.

+ +

LINDSEY: As far as launching products or new features, it's always interesting and challenging I think with SaaS products where you're continuously releasing improvements and how you think about…again, from the marketing fun of it too a little bit, is like how you think about when is something like a new launch? When is something a significant enough new feature? Is this actually a separate product from what we've been offering? And sometimes, that can be really obvious. Going back to the reporting example, that's a nice kind of shiny new toy in your platform that you're going to have, like a dashboard. The difficult ones are performance improvements. But I was curious if you have any takes on that too.

+ +

CHAD: Yeah. What I've always done on the products that I've worked on...and thoughtbot has created several products that have been fairly successful not only for our clients but for ourselves as well. I've always favored not underestimating people's ability to absorb significant product changes as long as they're coming from a place of you know that they are needed. And that if you're shipping regular new things on a basis, not all of your customers know about that right away, and so you can take a marketing touchpoint for those changes. And even though you have a sense of urgency about communicating them right away, you do have some time to do that.

+ +

I think I said earlier when I was starting out, "Underestimate people." What I think I meant was overestimate. We, as people who are very close to the product, assume that the minute we deploy a new feature or a change that everyone in the world is going to know about it. And that's just not the reality of what it's going to be. So when rolling out new features, you have to communicate them to the people who are touching them and are who are hitting them.

+ +

But there are almost multiple layers of marketing and communication for any new feature that's going out, communicating with immediate customers that are touching a new feature, and then making sure that everything that's going out is flowing through marketing and is coordinated with marketing around what those touchpoints are going to be. And the general guideline that I've always used is at least once a month; there should be a major round-up or communication about a significant change that has been made. And I've always felt really good about the products that I was working on if we were in that cycle like we're continually delivering new things. But then, on a monthly basis, there's at least one new either individually significant thing that we can talk about. Or absent of that, doing a roundup of a theme of changes or just here are three major improvements we've made in the last month.

+ +

LINDSEY: Yeah, I totally agree. It's great to have those opportunities to engage with customers and keep them invested in the product, and looking forward to those regular updates as well.

+ +

CHAD: Right. So when we think back to Trello boards or roadmaps and that kind of thing, I don't think marketing should be…after that fact, marketing shouldn't be saying like, "What was just released? Can we know?" and then responding to it. Marketing should have insight into what's in the backlog, what's the next things that are going into production. What are the things we're planning now? And they should be contributing to that process because, in a lot of companies, marketing is going to be on the front lines of interacting with customers. So you're going to hear things, and you're going to see things and that should contribute to the process.

+ +

LINDSEY: Right. Ideally, the marketing team is also customer-facing and providing those insights as well and tapped into what folks are having challenges with or looking forward to as well as what else they have their eye on that others are offering or trying out that are your competition.

+ +

CHAD: So that's the cadence that when I'm in charge of a product, I've tried to achieve. It's easier to do in the early days of a product when, like I was saying, you don't even need the roadmap. There's so much low-hanging fruit, and everything is valuable, and the priorities are relatively clear. It's harder to maintain that pace far into your product's future not only because what you're doing is less clear and maybe less valuable to all of your customers but also that daily, weekly, monthly pace can be difficult to keep up indefinitely just from a sustainability standpoint.

+ +

LINDSEY: Yeah. I feel like sometimes I even see products incorporating content in those later stages as ways to keep folks engaged and updated and have that be a feature of the product, whether it's community-based or the company itself actually producing new content and incorporating that into the product.

+ +

CHAD: Yeah. So a really good example of that is (Boy, we've had a lot of good people on the podcast.) the folks at Wistia, which is a local company to Boston. And they're continually evolving what their product is offering. And they're launching new features. They're doing new things. But a big part of what you see publicly from them is also new content that helps people be better creators. So they are a good example that comes to mind of a company that does that pretty well.

+ +

LINDSEY: So, we're going to be talking to three other startups of different stages in different industries about how they approach their product roadmap. Any sense for what might be consistent versus what is different? I imagine you also have insight from seeing a ton of client projects. Are certain areas of product roadmap more consistent than others?

+ +

CHAD: I suspect what we're going to hear from the early-stage companies is that they actually have what...They're probably either going to say, "We have no idea. We're just flying by the seat of our pants." But actually, I think it wouldn't be surprising to me if there's just so much low-hanging fruit in front of us that that gives them a sense of a clear product roadmap. And they say, "Yeah, we do know. We do have a sense of what we're going to be doing next week and the week after." But they're going to not be so worried about what six months from now looks like.

+ +

And I think a common trend of later-stage companies is I wouldn't be surprised to hear that they're very focused on partnerships and external relationships in a way that early companies aren't. And that is one of the factors which we haven't really touched on is, anytime you start involving external people the same way with Slack; it’s like people who are depending on you for their own business needs outside of your users creates more pressure for you to set expectations with them and to introduce roadmaps. So companies that are really focused on that who have channels and partnerships and that kind of thing are going to have more desire or pressure to introduce some form of roadmap.

+ +

LINDSEY: Yeah. And in a way, that's the later stage companies' low-hanging fruit. When you bring in a partner, or you make an acquisition and immediately fill in a need that you've identified or an opportunity that you've identified, instead of taking your existing team to build it, or hire a team, or work with someone like thoughtbot.

+ +

CHAD: Yeah. And it could be that that is actually totally the right thing. Because if you give everybody the benefit of the doubt and you say, "This product has been well-managed and user-centric to meet the needs of the users, then you're going to get that cycle." In the early days, we know what we should be doing, and our users are telling us. And we've got a lot of things to introduce into the product to fully meet the needs of those customers. And you're going to do that, and it's going to serve you for a really long time for delivering new things to them.

+ +

But at some point, again, giving the benefit of the doubt, assuming you've done that and things have gone well, there is a point at which you say, "We've delivered all of that. And we have a product which is meeting the needs of our users. It's fulfilling the job to be done of those users." You say, "Okay, great." So we're either bringing new people in who might have different needs and different jobs to be done. Or we are exploring other business opportunities like bringing on partners and opening up new channels which have their own needs that are driving your product roadmap, or they're bringing in customers who have a different job to be done.

+ +

LINDSEY: And honestly, it's an easy way for early-stage companies too to add a partner and gain access to their audience. But it's not likely that they're going to want to partner with you [laughs] because you're not bringing anything to the table, so you got to do that building first.

+ +

CHAD: Yeah. So we'll see what they say. I'm looking forward to the conversations. So, Linsdey, you have some personal news.

+ +

LINDSEY: Yes. With mixed emotions, I'll be moving on from thoughtbot and the podcast.

+ +

CHAD: This comes as a complete surprise to me. You're just springing this to me on the podcast.

+ +

LINDSEY: I know. I know I told you I wanted you to join five minutes earlier. And it's inappropriate.

+ +

CHAD: [chuckles]

+ +

LINDSEY: No, that's not true. I used all the proper channels. I read the handbook. But yeah, end of an era, moving on. But dang, it's been a lot of fun, hasn't it?

+ +

CHAD: It has been fun. It's been great working with you. The impact that you've had on thoughtbot will be long-lasting. It was significant and long-lasting. I think that you joined at a really interesting time. Pandemic and all that stuff aside, completely separate from that, we were going through important transitions, and I think you're an important part of this. I remember commenting to you not long after you joined when you gave the first company-wide presentation that you were the first person I think who had ever done a full company-wide presentation like that, besides me.

+ +

LINDSEY: Yeah. Wow. This feels like so long ago.

+ +

CHAD: And you're just so fun to work with and collaborate with and just be a team member with that you're definitely going to be missed. So thank you for everything.

+ +

LINDSEY: Thank you. I am definitely not tearing up. So no one has to worry about that. It's hard to look back without getting choked up. It's been a really great experience. [laughter]

+ +

CHAD: I'm glad to hear that. You brought so much to the table. We learned a lot along the way, and it wasn't always easy. We had a marketing team working in a certain way, which went through a big change. I think we learned a lot about how the next phase of thoughtbot needs to work, and I think you're an important part of getting there. So thanks again.

+ +

LINDSEY: Thanks for having me. Thanks to all of you for listening. And I'm now available as a guest, which is the great news.

+ +

CHAD: [laughs]

+ +

LINDSEY: And I almost know how to set up all my recording settings, so that's half the battle. But it's been real, and thank you for the opportunity from the experience.

+ +

CHAD: So we will be back in a little while with new episodes of the show. You can subscribe to the show and find notes for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. And for all you listeners out there, I'll talk to you next time. Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lindsey and Chad talk about product roadmaps. Are they dead? Lindsey and Chad think they just smell.

+ +

We also say an emotional goodbye to Lindsey as she moves on to new adventures. We miss you!

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

LINDSEY: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Lindsey Christensen.

+ +

CHAD: And I'm your other host, Chad Pytel.

+ +

LINDSEY: And today we're going to talk about product roadmaps.

+ +

CHAD: Product roadmaps. [laughs]

+ +

LINDSEY: Whoa. This is the topic. I feel like recently I've seen some thought pieces that product roadmaps are dead. So I'm curious if you think product roadmaps are dead.

+ +

CHAD: No, I don't think that they're dead, but I want to make the distinction too. I've never believed in a public product roadmap because I think that sets you up for just disappointing everyone involved, your customer, yourselves. And I think that there's a balance to be struck there. Saying that product roadmaps don't have a place, to me, in my mind, is like saying planning, having plans doesn't have a place and that just doesn't ring true to me. I think you should plan out what you're going to be working on. But I'm sure we'll get more into it. I also believe things about not having big backlogs and not doing too much planning and that kind of thing. So it depends on what you mean by a product roadmap.

+ +

LINDSEY: Well, yeah. I think that therein lies the issue. You can do it well, and you can also [laughs] run it into the ground. But you mentioned having it public and that being a bad idea. And I think at the core of product roadmaps is communication and alignment and getting all of your stakeholders on the same page about what you're building and why. So to me, I would think those stakeholders are the leadership team of the company, if this is a product company and product is the main business driver, the leadership of the company, the product team, of course, and engineering, sales, and marketing as well. Am I missing others? Clients, customers.

+ +

CHAD: Right. Customers.

+ +

LINDSEY: How do you feel about it? Does that count as the externally facing do not reveal?

+ +

CHAD: Oh yeah, it does for me. So we've all seen the companies that say that they're going to do something and then in a best-case scenario, that becomes a deadline which was arbitrarily made in the first place that everyone is stressing out over, that sales is potentially making promises that are either going to need to be broken or are going to need to be super stressed over. And then in a worst-case scenario, you end up not delivering on that roadmap as you essentially promised. And you actually end up with disappointed customers.

+ +

LINDSEY: So you would recommend not telling the customers about future features.

+ +

CHAD: Yeah. I think there's a balance to be struck there. So certainly, if you know that you're working on something now like actively working on something and a customer were to ask you about that thing directly, I might say, "Yeah, we're working on that now, and we're excited about getting it out to you." But I have only [chuckles] ever been a part of when a team is saying, "Q3 of next year, six months, nine months down the road, this specific feature is going to make it to customers." That's a real recipe, in my experience, a real recipe for lots of people being either really disappointed in that not happening or really working unsustainably in order to hit that in the first place. It's really hard to plan software that far in advance.

+ +

We just had the CEO of Dragon Innovation on the podcast. And I think that even then, you have to be careful with hardware, but at least with hardware or other kinds of businesses, it's a little bit easier to say, "Our goal is to have this incorporated in the product, or whatever, in the next revision of the hardware. And we expect to do that two years from now," or something like that. That's a little bit easier to put a bow around, I think.

+ +

LINDSEY: Yeah. I was a part of a software company that got acquired by a hardware company. And all of a sudden, we were wrapped into these 5 to 10-year product roadmaps that were blowing all of our minds [laughs] and a very different fit than how we were used to working.

+ +

CHAD: Yeah. It's worth noting that there are some companies that essentially go so far as to publish a Trello board of their roadmap. I don't know which ones they are. [chuckles] I have to find them. But even then, they're not necessarily making hard promises. And if you're committed to being transparent and publishing some roadmap to the public, the ways that I've seen it done best are working in themes. So you say, "Two quarters from now, our focus is going to be on reporting," or something like that. That is a little bit...because you're not making specific promises. You're just establishing a theme of what your focus is going to be on for that time. You can imagine you can still get yourself into a position where customers are putting all their hopes and dreams on what that's going to look like, and maybe your support staff or salespeople or whatever start to make promises about what's going to be delivered in that time. And then again, a bunch of people end up disappointed.

+ +

LINDSEY: Yeah. I've also seen what I think to be the most successful roadmaps be based around themes. And I think it’s also…again, going back to that, the fact that it's, in addition, to actually delivering product and delivering good product, it's helping align your internal team around what you're doing. So to rally your whole team or your whole company around reporting is the next big thing that we're working on, and this is why. This is what we've heard from users, from our research. And this is the direction we're going in and then actually getting everyone working towards reporting in their own ways. Marketing can be working on content around reporting. Hopefully, sales is seeding the idea of maybe not promising around reporting as well.

+ +

And that also really appeals to me as a marketer and as someone who's thinking often about how do we get folks moving in the same direction, speaking the same language and creating some momentum around something that can differentiate us, get people excited about what we're doing? Then hopefully, it's also strategically valuable to the company adding a new feature or entirely a new product. You're expanding your offering and maybe even your market reach. Who do you think are the most important folks within the company to be driving the product roadmap? Who owns the product roadmap?

+ +

CHAD: Well, [laughs] so if you have a company that has a roadmap...I'm getting distracted by the premise here. Let's just come back to that a bit. Momentum is key. You used the word momentum. And if you're feeling the need to plan things out or to gain a sense of clarity on your team about what's going to be done, and what's important, and you need to do a long-term roadmap in order to do that, that to me does point to it's sort of a smell. That's what we do when there's a code problem. We say it's a code smell. It points to if you had a team that was continually delivering value to your customers, to your users, and that you had a team where when sales, or marketing, or someone learned something about what will be valuable to customers and it's validated that it's valuable, and it gets put into the design and development process, and it comes out relatively soon, there's no need for a product roadmap.

+ +

Or I should say people don't feel the need for a product roadmap as much because they have high confidence that user needs are going to be met in a tight feedback cycle and that there's not a loss of momentum. And things going into the system are coming out in a week, two weeks, three weeks. Even four weeks, you can maintain that sense of momentum of we understood that this was important. We validated that it was. It went into the system, and it came out the other side, and it's in the hands of users. It's only when that starts to break down that stakeholders start to say, "We need to plan. We need a roadmap," because they lack the confidence that putting things into the system they're going to see them come out the other side in a way that maintains momentum.

+ +

LINDSEY: Does that depend on the size of the company?

+ +

CHAD: Well, ideally, even companies of large size are able to do that, but we all know that that's difficult. It may be that most companies just can't do that. And when that's the case, you have that breakdown. You have that lack of confidence. You have a system where you aren't putting things in and quickly seeing them come out the other side. And so that's where something like a product roadmap you start to say we need that in place. And I think that that's why it often happens as teams get bigger and as companies get more complex.

+ +

LINDSEY: Interesting. So product roadmaps are not dead, but roadmap can be a smell.

+ +

CHAD: Yes. [chuckles] Yeah, that's what I would say. That's my opinion.

+ +

LINDSEY: Who owns that smell?

+ +

CHAD: So now to get back to who owns the product roadmap, if your customers aren't the ones driving what's on the roadmap, then something is fundamentally broken. At the end of the day, the real owners of the product roadmap, even though they probably shouldn't see it, are the users, the customers. But I don't think that's the question you were asking. Who decides what's on the roadmap? It's got to be the people who are closest to hearing customers and who have the vision for what the product is supposed to be. So that will often be the company leadership, the CEO, the chief product officer, something like that combined with people who are talking with customers.

+ +

LINDSEY: So on the opposite end of the spectrum, if it's a big company, maybe it's a little bit harder to operate without the roadmap. If you're a really small and young company, let's say, and you already have a roadmap, is that too much?

+ +

CHAD: Well, this is a podcast, so we can have opinions. I would say [laughs] growth opinion, high-level position, yeah, you should probably not have that roadmap. Now the devil is in the details. What is the roadmap? Is it high-level themes? Is it I'm building this idea, and I'm a visionary about what this product is going to be, and I've laid out in broad strokes...we've done an initial version, a minimum viable product, and we have a vision for where we're going over the next year or two? There's a way to do that which doesn't then convert into this rigid product roadmap. And I think that that's what people who say product roadmaps are dead and you shouldn't be doing them; that’s what they're pushing against is that really rigid expectation setting system where promises get made and then broken.

+ +

LINDSEY: Right and promising especially deadlines far out into the future.

+ +

CHAD: And they also understand or believe that if you have a product roadmap, it potentially puts you in a position where you stop listening to customers because you say, "In six months, this is the thing that we're going to be working on." And then you get there, and you just work on it, and you deliver it without having learned along the way that the next most important thing might be something completely different. And so that's another risk with product roadmaps is you start working to the roadmap instead of working to what your users are telling you. So at that company, I'm not surprised to hear that it was a 5-year, 10-year thing, and then it's based off of a thing, Was it really concrete, or was it more sort of vision stuff?

+ +

LINDSEY: It was very concrete, I would say.

+ +

CHAD: Yeah. [laughs]

+ +

LINDSEY: And it's interesting because a lot of it was around trying to be first to market with cutting edge technologies. And on the hardware side, there was also R&D and multiple scientific teams working on specific things. And actually, to get more concrete, I think I can share without giving specifics. So it was 3D printing, and there's like an arms race in 3D printing to be able to print with new materials. So there are multiple teams working on trying to figure out how to print with new materials. And then we had these really long-term product roadmaps that were like by this year; we’re going to have gone to market with it and using that as a way to stay ahead of the competition basically.

+ +

CHAD: I can imagine that from a business perspective, you're looking at that situation, and you say...and this is true both in science and in software. But from a business perspective, it's saying, "If we don't have this deadline in place, then we have a research project that's just going to go on. We need this timeline, this deadline to hold everyone accountable to what a goal is and to make sure that we're bringing new products to market in that timeframe." And then the scientists are probably saying, "We have no idea. It's completely arbitrary. We think that we could do this, but what happens when we don't? What happens when we don't have something?"

+ +

A lot of times, I make an analogy between science and even software development and art because it is a creative process. It's all in our heads, and we're just coming up with it. You can say, "I need to have the book," or "I need to have this painting finished by this time." But it's very difficult to then ensure that that is actually going to happen at the creative level of saying, "I'm proud of this work, or it's good." It's hard to do that.

+ +

LINDSEY: Yeah, and I think there was an element too of either we will figure it out, or we will acquire whoever figures it out. And then there's a separate team that's off trying to suss out who's figuring it out and what are they willing to be bought for? [laughs]

+ +

CHAD: Right. And maybe from a business perspective, a lot of that makes sense. And you have to balance all of those things in order to try to be successful from a business perspective.

+ +

LINDSEY: Yeah. It's interesting on the hardware side, too, especially as you do get closer to actually launching. It can be very waterfall-esque working towards launch because there are so many dependencies in order to get the thing built and shipped and launched on time.

+ +

CHAD: I found a Quora thread about companies that have made their roadmap public.

+ +

LINDSEY: Did any do it successfully?

+ +

CHAD: [laughs]

+ +

LINDSEY: I've only seen nightmare stories. Like, let this be a lesson. Here's a company that made their roadmap public, and within weeks they were disappointing people. [laughs]

+ +

CHAD: I think that it's tempting, you know, and I think we should just do it. Part of the benefit of not having a roadmap that people say is that it allows not only the flexibility for what you're going to do to change based on what you learn. But the other is it offers you the opportunity to surprise and delight customers. And it allows you not to say, "This thing is six months away," but to say, "Here it is now." And one of the best examples of that that I think we're all familiar with is Apple. Apple doesn't typically pre-announce products that far in advance. And they're even a hardware company. They're clearly working on things years in the making. But they don't talk about them publicly until it's like, you can order this today, or you can order this on Wednesday. And the excitement and momentum that Apple builds around that is like the Charlie and the Chocolate Factory, Willy Wonka kind of secretive thing. It's super exciting to customers, and they're super successful doing it.

+ +

And last year, we had a really public thing where...actually, it was I guess two years ago that the saga started when Apple unusually announced AirPower, which is a charging mat that could charge both of your phone and your watch and everything all at the same time. They announced that far in advance. And then it actually ended up never shipping, and they eventually canceled the product. And they had to do all of that publicly, which is very, very different from Apple. I imagine that there are tons of products that Apple thinks that they're going to eventually release, and they don't work out, and they have to kill the projects. And all of that happens behind closed doors.

+ +

LINDSEY: So we don't know of anyone who does it successfully. What does Quora say?

+ +

CHAD: Quora doesn't know. A lot of the companies are not even in business anymore. [laughter]

+ +

LINDSEY: There you go.

+ +

CHAD: Buffer has apparently...Buffer has a transparent product roadmap. And I guess if there's any company that does transparency pretty well that I could point to, it would be Buffer. So we can link to that in the show notes. How does this board work? We've made this to give you a clear view into what we're working on, what we're about to work on, and what we're thinking about working on. We hope you enjoy the peek behind the scenes. They have four lanes: potential, next up, in progress, and done. They have voting enabled on their Trello board so their customers can vote on the different things that they have going on.

+ +

LINDSEY: Are you in the actual board?

+ +

CHAD: I am on the actual board, yeah.

+ +

LINDSEY: How many votes? What kind of numbers are we talking?

+ +

CHAD: So the in-progress thing that they are currently working on is a better way to manage campaigns in Buffer, and it has four votes.

+ +

LINDSEY: Oh.

+ +

CHAD: [laughs] So it doesn't seem like there's tons of engagement. There's another one, the best time to post to maximize your reach. It has seven votes.

+ +

LINDSEY: Okay, so a pretty low number.

+ +

CHAD: Pretty low. Oh, here's one, flexible pricing for Buffer has 67 votes. So I think you can get a little sense of the engagement that's on there. But I like that there's no description on these cards. It's just a better way to manage campaigns in Buffer. So they're not saying what they're going to be doing. There are no timelines on any of these cards. It was only moved to in progress. And they're not saying anything on these cards from what I can see about when it's going to be done or what is actually going to be entailed in it. I encourage people to look at this. It's pretty good in terms of potentially ways to make a public roadmap work for you and your customers.

+ +

LINDSEY: And what about thoughtbot? We also heavily gravitate towards the Trello management.

+ +

CHAD: Yeah. This is clearly not their actual Trello board. It's a specific board created for a transparent roadmap.

+ +

LINDSEY: It’s a distraction.

+ +

CHAD: [laughs] Yeah. If we were going to do something like this…

+ +

LINDSEY: I guess I meant as far as tools; what are the things that you have seen work with…? My guess would be Trello because we use that a lot for managing projects.

+ +

CHAD: Yeah, we use it for managing pretty much every project. And longtime followers of thoughtbot will know that we used to use a tool called Pivotal Tracker. And then, we created our own tool called Trajectory, which doesn't exist anymore. But the big thing about that was it was really meant to address the flow between coming up with ideas and the design thinking that goes into evolving a product idea and then breaking it down into stories and doing the stories from there.

+ +

And we switched to Trello in part because of the flexibility of Trello. Trello is not specific to any one product or any one workflow. And so, the nature of software development is again a reason why product roadmaps can be troublesome because things change constantly. You're constantly learning. You should be meeting on a regular feedback cycle of not only how is our product working for people and what should we do differently, but how is our process of developing that product working, and what should we be doing differently? That's one of the great things about Trello is that because it's so flexible, you can say, "Yeah, we're having this problem with our process. Let's change it." And you can usually find a way to embrace that flexibility in Trello.

+ +

LINDSEY: And how do you know that your product roadmap is on the right track? Or what are some smells that you're going in the wrong direction? We talk about customers being happy. What does that actually mean, and what does that look like?

+ +

CHAD: If the things that are going into what you're doing on your product are coming from users, and then they're going back to them, and they're receiving usage, that's a really good sign. And a lot of teams look at and measure cycle time, so the total time for something that goes into the process to come out the other side and get in the hands of users. And a lot of teams really high functioning teams will be working to make that as short as possible. And one of the reasons why is because that gives a sense to your customers that your product is continually moving forward in a way that comes from their needs. And that's a really good place to be in. You know what I mean?

+ +

LINDSEY: Yeah, that makes sense.

+ +

CHAD: Do you use any products where you feel like they've got that flow working really well?

+ +

LINDSEY: As far as asking for feedback and then incorporating it into the product?

+ +

CHAD: Yeah, or even just that you use the product and you're maybe not even giving them feedback directly, but you have a vague sense of how your need might not be met. And they're releasing features and that kind of thing on a semi-regular basis where you say, "I didn't even realize I needed that, but now that I have it, it makes me happy." Or "Boy, that really solved this problem that I was facing."

+ +

LINDSEY: I think the one that comes to mind immediately is Slack, actually. I feel like their product releases often speak to something I was feeling. Like, I think especially they seem attuned to the fact that it can create a lot of noise. And so providing or increasing the different ways that you can personalize your own experience so that you can mute things or have certain kinds of notifications or be able to set hours that you're away and unavailable. Those releases, I think, feel especially personal when I see those come through.

+ +

CHAD: I think you're right. Slack is one where that would be the case. And it's worth noting that Slack does publish a roadmap, and they've been doing it for a couple of years. Particularly, it seems like, from the outside, a big part of what drove that and what's in their marketing around it is better setting expectations with their enterprise customers and that sort of thing rather than necessarily not meeting the needs of actual users.

+ +

LINDSEY: They also seem especially responsive and helpful out in the world too. I've seen multiple instances of folks I know tweeting about a bug or something in Slack, and very quickly, the Slack account is responding with how to fix it or notifying that it's been logged in, and they'll be following up, that kind of thing.

+ +

CHAD: So I'm looking at the Slack one a little bit more, and it seems like the roadmap is centered primarily around what they call the platform roadmap. So it's more like APIs and system-level things that they're going to be focusing on or adding rather than user-facing features. So it's more serving the needs of people who are building on top of the Slack platform versus saying that their product is going to have a specific feature at this time that's user-facing.

+ +

LINDSEY: That's interesting.

+ +

CHAD: Which makes sense because people building on top of the Slack platform who are really dependent for their business needs on the Slack platform are going to have high expectations for knowing what's coming and knowing that their needs are being addressed at some point in the future.

+ +

LINDSEY: Right. And on the enterprise side, as they're getting more enterprise customers, I imagine that could come into play as well where enterprise companies are going to have some dependencies or requirements that maybe the Slack team hasn't had to deal with before, which could be integrations. It could be certain kinds of security measures, which if they're definitely working on those or creating the necessary partnerships, it can also make sense to say, "We have in our sites this integration or the security measure coming by the end of the year," kind of thing.

+ +

CHAD: Yeah. So one that I have...and it's interesting because I think they've been doing a good job lately, but they went through a real period of time where I felt like they weren't doing as good a job with it, and it’s GitHub. So GitHub lately has done a much better job of, for me as a developer, as a user of GitHub every day, delivering features where it's like, yeah, this is awesome, and it fills a need or a pain that I was really having. Or I didn't even realize that I was going to need this feature, and now that it's here, I can't imagine it being any different.

+ +

And they do that, as far as I know, there's not a public roadmap for GitHub. And GitHub, I could be completely wrong on this; they do a conference. They do shows. And what they're doing at that is they're announcing things. So they're more on the sliding scale towards Apple, where they're announcing general availability or beta availability of new features at their events as opposed to saying, "Here's what the roadmap for the next year looks like."

+ +

LINDSEY: Which does create a forcing function of having things ready enough, maybe not launchable but ready enough that you can at least talk about it and talk about the timeline.

+ +

CHAD: Yeah. And we had the product manager of the payments that GitHub announced on a previous episode. Her name's Devon. And that's one of the things she talked about was working towards that deadline of that presentation and how stressful it was and making sure that they manage scope within that.

+ +

LINDSEY: So, do you think GitHub has been doing a better job since they were acquired?

+ +

CHAD: It doesn't so much match since when they've been acquired, but there was a period of time where...and maybe it could be that there's nothing GitHub-specific about this, but there's probably a period in every product's time where you go from this is a new thing, and so there are so many new features that are low hanging fruit. And you can quickly roll them out, bang, bang, bang for a long period of time. Your roadmap is just sitting there in front of you, waiting for you to do it. You don't need to worry too much about it. That's, depending on the product, probably six months, a year, two years, maybe even five years. But then you're going to work your way through that list and the things that you do next, particularly if you reach a growth stage, which means that your core customers may be different than your original core customers…where you can enter a lull. And you need to take some time to figure out what the next phase of your product looks like. It's possible that it happened with GitHub.

+ +

I tend to think that it's more that internally GitHub had real challenges. And we know it had some issues with sexual harassment and workplace issues like that. I think that really got in the way of GitHub functioning well. That's my theory. But again, I'm totally on the outside. But I do know that they went through some significant restructuring and addressing a lot of those issues and creating what is hopefully a more inclusive workplace where people can do their best work. And then good work started to come out again.

+ +

LINDSEY: As far as launching products or new features, it's always interesting and challenging I think with SaaS products where you're continuously releasing improvements and how you think about…again, from the marketing fun of it too a little bit, is like how you think about when is something like a new launch? When is something a significant enough new feature? Is this actually a separate product from what we've been offering? And sometimes, that can be really obvious. Going back to the reporting example, that's a nice kind of shiny new toy in your platform that you're going to have, like a dashboard. The difficult ones are performance improvements. But I was curious if you have any takes on that too.

+ +

CHAD: Yeah. What I've always done on the products that I've worked on...and thoughtbot has created several products that have been fairly successful not only for our clients but for ourselves as well. I've always favored not underestimating people's ability to absorb significant product changes as long as they're coming from a place of you know that they are needed. And that if you're shipping regular new things on a basis, not all of your customers know about that right away, and so you can take a marketing touchpoint for those changes. And even though you have a sense of urgency about communicating them right away, you do have some time to do that.

+ +

I think I said earlier when I was starting out, "Underestimate people." What I think I meant was overestimate. We, as people who are very close to the product, assume that the minute we deploy a new feature or a change that everyone in the world is going to know about it. And that's just not the reality of what it's going to be. So when rolling out new features, you have to communicate them to the people who are touching them and are who are hitting them.

+ +

But there are almost multiple layers of marketing and communication for any new feature that's going out, communicating with immediate customers that are touching a new feature, and then making sure that everything that's going out is flowing through marketing and is coordinated with marketing around what those touchpoints are going to be. And the general guideline that I've always used is at least once a month; there should be a major round-up or communication about a significant change that has been made. And I've always felt really good about the products that I was working on if we were in that cycle like we're continually delivering new things. But then, on a monthly basis, there's at least one new either individually significant thing that we can talk about. Or absent of that, doing a roundup of a theme of changes or just here are three major improvements we've made in the last month.

+ +

LINDSEY: Yeah, I totally agree. It's great to have those opportunities to engage with customers and keep them invested in the product, and looking forward to those regular updates as well.

+ +

CHAD: Right. So when we think back to Trello boards or roadmaps and that kind of thing, I don't think marketing should be…after that fact, marketing shouldn't be saying like, "What was just released? Can we know?" and then responding to it. Marketing should have insight into what's in the backlog, what's the next things that are going into production. What are the things we're planning now? And they should be contributing to that process because, in a lot of companies, marketing is going to be on the front lines of interacting with customers. So you're going to hear things, and you're going to see things and that should contribute to the process.

+ +

LINDSEY: Right. Ideally, the marketing team is also customer-facing and providing those insights as well and tapped into what folks are having challenges with or looking forward to as well as what else they have their eye on that others are offering or trying out that are your competition.

+ +

CHAD: So that's the cadence that when I'm in charge of a product, I've tried to achieve. It's easier to do in the early days of a product when, like I was saying, you don't even need the roadmap. There's so much low-hanging fruit, and everything is valuable, and the priorities are relatively clear. It's harder to maintain that pace far into your product's future not only because what you're doing is less clear and maybe less valuable to all of your customers but also that daily, weekly, monthly pace can be difficult to keep up indefinitely just from a sustainability standpoint.

+ +

LINDSEY: Yeah. I feel like sometimes I even see products incorporating content in those later stages as ways to keep folks engaged and updated and have that be a feature of the product, whether it's community-based or the company itself actually producing new content and incorporating that into the product.

+ +

CHAD: Yeah. So a really good example of that is (Boy, we've had a lot of good people on the podcast.) the folks at Wistia, which is a local company to Boston. And they're continually evolving what their product is offering. And they're launching new features. They're doing new things. But a big part of what you see publicly from them is also new content that helps people be better creators. So they are a good example that comes to mind of a company that does that pretty well.

+ +

LINDSEY: So, we're going to be talking to three other startups of different stages in different industries about how they approach their product roadmap. Any sense for what might be consistent versus what is different? I imagine you also have insight from seeing a ton of client projects. Are certain areas of product roadmap more consistent than others?

+ +

CHAD: I suspect what we're going to hear from the early-stage companies is that they actually have what...They're probably either going to say, "We have no idea. We're just flying by the seat of our pants." But actually, I think it wouldn't be surprising to me if there's just so much low-hanging fruit in front of us that that gives them a sense of a clear product roadmap. And they say, "Yeah, we do know. We do have a sense of what we're going to be doing next week and the week after." But they're going to not be so worried about what six months from now looks like.

+ +

And I think a common trend of later-stage companies is I wouldn't be surprised to hear that they're very focused on partnerships and external relationships in a way that early companies aren't. And that is one of the factors which we haven't really touched on is, anytime you start involving external people the same way with Slack; it’s like people who are depending on you for their own business needs outside of your users creates more pressure for you to set expectations with them and to introduce roadmaps. So companies that are really focused on that who have channels and partnerships and that kind of thing are going to have more desire or pressure to introduce some form of roadmap.

+ +

LINDSEY: Yeah. And in a way, that's the later stage companies' low-hanging fruit. When you bring in a partner, or you make an acquisition and immediately fill in a need that you've identified or an opportunity that you've identified, instead of taking your existing team to build it, or hire a team, or work with someone like thoughtbot.

+ +

CHAD: Yeah. And it could be that that is actually totally the right thing. Because if you give everybody the benefit of the doubt and you say, "This product has been well-managed and user-centric to meet the needs of the users, then you're going to get that cycle." In the early days, we know what we should be doing, and our users are telling us. And we've got a lot of things to introduce into the product to fully meet the needs of those customers. And you're going to do that, and it's going to serve you for a really long time for delivering new things to them.

+ +

But at some point, again, giving the benefit of the doubt, assuming you've done that and things have gone well, there is a point at which you say, "We've delivered all of that. And we have a product which is meeting the needs of our users. It's fulfilling the job to be done of those users." You say, "Okay, great." So we're either bringing new people in who might have different needs and different jobs to be done. Or we are exploring other business opportunities like bringing on partners and opening up new channels which have their own needs that are driving your product roadmap, or they're bringing in customers who have a different job to be done.

+ +

LINDSEY: And honestly, it's an easy way for early-stage companies too to add a partner and gain access to their audience. But it's not likely that they're going to want to partner with you [laughs] because you're not bringing anything to the table, so you got to do that building first.

+ +

CHAD: Yeah. So we'll see what they say. I'm looking forward to the conversations. So, Linsdey, you have some personal news.

+ +

LINDSEY: Yes. With mixed emotions, I'll be moving on from thoughtbot and the podcast.

+ +

CHAD: This comes as a complete surprise to me. You're just springing this to me on the podcast.

+ +

LINDSEY: I know. I know I told you I wanted you to join five minutes earlier. And it's inappropriate.

+ +

CHAD: [chuckles]

+ +

LINDSEY: No, that's not true. I used all the proper channels. I read the handbook. But yeah, end of an era, moving on. But dang, it's been a lot of fun, hasn't it?

+ +

CHAD: It has been fun. It's been great working with you. The impact that you've had on thoughtbot will be long-lasting. It was significant and long-lasting. I think that you joined at a really interesting time. Pandemic and all that stuff aside, completely separate from that, we were going through important transitions, and I think you're an important part of this. I remember commenting to you not long after you joined when you gave the first company-wide presentation that you were the first person I think who had ever done a full company-wide presentation like that, besides me.

+ +

LINDSEY: Yeah. Wow. This feels like so long ago.

+ +

CHAD: And you're just so fun to work with and collaborate with and just be a team member with that you're definitely going to be missed. So thank you for everything.

+ +

LINDSEY: Thank you. I am definitely not tearing up. So no one has to worry about that. It's hard to look back without getting choked up. It's been a really great experience. [laughter]

+ +

CHAD: I'm glad to hear that. You brought so much to the table. We learned a lot along the way, and it wasn't always easy. We had a marketing team working in a certain way, which went through a big change. I think we learned a lot about how the next phase of thoughtbot needs to work, and I think you're an important part of getting there. So thanks again.

+ +

LINDSEY: Thanks for having me. Thanks to all of you for listening. And I'm now available as a guest, which is the great news.

+ +

CHAD: [laughs]

+ +

LINDSEY: And I almost know how to set up all my recording settings, so that's half the battle. But it's been real, and thank you for the opportunity from the experience.

+ +

CHAD: So we will be back in a little while with new episodes of the show. You can subscribe to the show and find notes for this episode at giantrobots.fm.

+ +

If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. And for all you listeners out there, I'll talk to you next time. Bye.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+VFC8ZXcz + + ]]> + + Lindsey Christensen + Chad Pytel + + + 395: Energy, Perspective, Priorities, and Intention with Jen Dary of Plucky + https://podcast.thoughtbot.com/395 + beeb4ad4-b132-4667-b7d2-469115a330a6 + Thu, 30 Sep 2021 00:15:00 -0400 + thoughtbot + + full + 11 + thoughtbot + Chad talks to Leadership Coach and Founder of Plucky, Jen Dary, about working with individuals and companies to create healthy dynamics at work. + +In fact, Plucky just released a new product that aids in doing just that! Manager Weeklies are notebooks designed to help leaders intentionally set up their weeks and track progress. It includes tips and tricks, including useful 1:1 tools. Each notebook is designed to last one quarter. + 48:55 + no + + + Chad talks to Leadership Coach and Founder of Plucky, Jen Dary, about working with individuals and companies to create healthy dynamics at work. +In fact, Plucky just released a new product that aids in doing just that! Manager Weeklies are notebooks designed to help leaders intentionally set up their weeks and track progress. It includes tips and tricks, including useful 1:1 tools. Each notebook is designed to last one quarter. +Follow Jen Dary on Twitter (https://twitter.com/jenniferdary) or LinkedIn (https://www.linkedin.com/in/jen-dary-46b0367/) +Plucky (https://www.beplucky.com/) +Manager Weeklies info & order link (https://shop.beplucky.com/products/manager-weeklies-2-pack) +Newsletter: beplucky.com/newsletter (https://beplucky.com/newsletter) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jen Dary, founder of Plucky. Jen, welcome back to the podcast. +JEN: Thank you. My third time. Three time's a charm. I feel very lucky. +CHAD: There aren't many people who have been on the podcast as guests three or more times. So you're in an ever-increasing select group of returning guests. +JEN: Thank you. I feel like it's maybe because the Tokyo Olympics have just started, but I feel competitive and ready to take on this third session. +CHAD: [laughs] So the last time you were on was October 28th, 2019 is when the episode came out. +JEN: Millennia ago. +CHAD: Not quite two years ago, but yeah, also a millennia ago. And that was Episode 342 so if people want to go back and take a listen to that. And then before that, you were on Episode 270, which I actually don't even know the date of. It was even longer. So welcome back. You are celebrating the eighth anniversary of Plucky. +JEN: I know. I don't really think of it in these ways because I don't have an MBA, or I didn't come from a business background or anything. But definitely when I hit five years, I feel like my husband said something about that. He was like, "Honey, you should be really proud. Not a lot of businesses make it five years." And that was not really on my mind. +But now that Plucky is eight, I feel like oh man, I'm just so happy to talk about how businesses evolve and how what you thought it was going to be in year one was different than year three, was different than year five, and of course, it's different than year eight. So we're eight years in, but nothing's the same, and everything's the same. I'm sure you've experienced that too. +CHAD: It was actually the eighth year going into the ninth year mark that we at thoughtbot started to make big changes. And it was that idea of coming up on a decade. It started to feel like, wow, there's real momentum here. And instead of thinking about what the next year looks like, what does the next decade look like? And are we the kind of company that is going to last 20 years? And that put us in a different mindset. And I started to think about the impact we were having and the legacy that we would have. And was it big enough for the size of the company that we had? +JEN: How old is thoughtbot right now? +CHAD: We just celebrated our 18th anniversary. +JEN: Oh my gosh. All right. Well, maybe at the very end, you can give me your best wisdom for the ninth year. [laughter] +CHAD: Oh jeez. Okay. [chuckles] +JEN: No presh, but tuck that in the back of your brain. +CHAD: Yeah, get some sleep. That's my best advice. +JEN: [laughs] Great. +CHAD: That would be great. We can come back to that. +JEN: Cool. +CHAD: So obviously, it's been a big two years since we last talked. I'm sure a lot has progressed in Plucky. How have things changed? +JEN: Well, what's funny is that the two years spread that we're talking about or 18 months or whatever it is, for the most part, overlaps with COVID so far. So by the end of 2019, things were cooking, and everything is good. And even, personally speaking, my youngest son would be entering kindergarten in the fall of 2020. Again, as a business owner, a mom, all those things I was sort of at the end of 2019 hot, so good. +And then I was anticipating 2020 to be continued pretty much the same as is. Like, we would keep training managers. I would keep traveling. All that would get easier because the kids are getting bigger, then my kid would go to kindergarten. And I was also finishing a book about...I can't remember if we talked about this before, but I was really sick in 2016. I had a brain tumor diagnosis, and I'm okay now. It was benign. I had this memoir that was eh, I don't know, maybe two-thirds done. All that was the plan for 2020, Chad. And I'm sure this is shocking news to you, but none of it happened, including freaking kindergarten, obviously in person. +So on the business side of things, I kept everything stable as best as I could. So coaching kept going because coaching has always been remote. We have some products, and we kept shipping those out as best we could. At the very beginning of COVID, when everybody thought it was this three, four-week hiatus from real life, I recorded a story every day. Because I was like, what can I do for all the world that's working? So I recorded a storytime for Plucky with my kids. And I put it out on social media so that working parents could have another 15 minutes of distraction for their kids. That's how cute I was back then. [laughter] After one month of that, I was like, I need somebody to read stories to my kids. Yikes. +CHAD: Yeah. [laughs] +JEN: So the big thing that changed was that our manager trainings in person obviously I had to cancel those. So I transitioned from in-person to virtual events, and that has continued. And as of this recording, end of July, I was thinking that our November event this year…it's the 20th cohort of So Now You're a Manager. I was going to have it in person. And just last week, I pulled the plug on that. And I was like, no, we're going to stay virtual a little bit longer because I don't know how to predict what the hell is coming. So again, that sort of stabilizing, right? Like, okay, well, now I know how to do the virtual. That will be the stable choice this year, which is weird to say, but true. +CHAD: Yeah. So you just gave a great organic listing of the things that Plucky does, and a big part of that was that in-person So Now You're a Manager training, which, if people remember from the previous episodes, new managers at thoughtbot have attended over the years. It's a really great training for people who become managers. So what was transitioning that to remote like? Because you'd only ever done it in person before, right? +JEN: Yeah, totally. The first 11 cohorts were in person, and then we got to 12, and that was supposed to happen in March in Atlanta. We canceled that, and it wasn't until June that we had the 12th, and that was the first virtual one. And to say that I needed to go through stages of grief is probably pretty accurate. [chuckles] +My energy in person is so a thing, like a tool of mine and just pulling people together, and making safe space for conversations and all that jazz. So I was like, what the hell is that going to be like on Zoom? And meanwhile, remember I'm watching my first grader go through the shenanigans of Zoom for the end of that year. And I'm like, oh my God, how am I possibly going to get grown-ups on this and paying attention and not being distracted? +So a couple of things, I will say number one is I definitely interviewed four or five people in the industry who are good at virtual events, and I tried to get their deepest wisdom about it. The second thing is that I made the cohorts smaller. So in person, we have around 20 to 22 max, and in virtual, we do 10 to 12 max. And so that got a lot smaller. Also, instead of being two days back to back, I broke it into three half days which is just a different ask. And I wasn't sure if people would bite at that. +I tried to mimic it after how some people do an MBA on the side. So then they go to work, and they practice the stuff they're learning at the MBA. And so that has been my thought like, okay, you'll be with me basically for a month. We'll have three half days together, usually on a Friday. And then you're practicing in the meantime. So between the times I see you, you're improving your listening skills. You're coming back with anecdotes about hires or tough conversations or whatever. So I won't say that's like a silver lining, but it's just a different beast. And the first day I did it, I mean, I'm telling you, I was on the bathroom floor on my knees like, don't let the internet go out. +CHAD: [laughs] +JEN: I was so scared. I don't know why looking back. I'm in tech, but I'm not technical. It's my husband who helps me set up a monitor and whatnot. Oh God, I was so nervous. And I just thought, shit, this is the thing I can't problem-solve. If the internet goes out, I don't know what to do, but if someone's upset, I can help them. So it just brought all of my skills in a different environment. And now I feel pretty good about it. +I don't know if you found this with your distributed company overall, but I have worked very hard to make sure that it's a blend, of course, this digital experience, but also I use the mail. I use snail mail a lot. So attendees get a packet before we begin. They get a gift at the end, a graduation gift. And yeah, I feel like I've learned a lot about how to have a hand-in-hand experience of digital as well as a physical object that they can touch to make that experience more than just a screen. +CHAD: Yeah, I think that's important. How did changing the format, reducing the class size, what business ramifications were there for that? +JEN: Well, it's way less money. [chuckles] +CHAD: Right. Okay, sorry. +JEN: No. Oh my God. I want to be very real about these things, especially for people starting their businesses. It's way less money. And also if you think about it, everybody had already bought tickets to Atlanta, and then they had already started buying tickets to...I can't remember what the next one was going to be, New York, I think. So for a lot of the year, everything was, I'll say, comped, but that's not really what's going on. All of a sudden, the amount of seats that I thought I was selling for the year got reduced in about half, and much of that were already pre-bought tickets. So, as a line item, that was way lower. +I also think I got...man, I haven't really said this transparently to anybody before, but I'll say it here. I got really scared about what to charge. Do you charge the same thing virtually than you do in person? And so I lowered it, I would say for a year. I lowered it by a couple of hundred dollars for each ticket because I didn't know what the market wanted. And also, I didn't know, oh God, were businesses closing? Were people getting prof dev budgets? Everybody was frozen for a good while. So I'm lucky that now today I'm back up to the same price that it had been before, but it's not as much income per event. +And the other thing I'll say which affects money…but again, I want to be transparent for other folks who think about or currently run businesses. One great thing to come out of some of the social unrest of last year is that we now have an equity scholarship for So Now You're a Manager. So in every cohort, be that virtually or in person, I always reserve a seat for someone who's coming from an underrepresented group, so people apply. And that is something that I very happily said I will eat the cost of that ticket because it's important to me to have different voices in the room. And that has been a total awesome thing this year. That just started in January of 2021, but that's something really great that came out of last year. +CHAD: Yeah. What did you find that customers wanted, and did it change over time? Was there an appetite for it to be remote, or was there resistance to it? +JEN: I think at first people were overwhelmed and didn't want it. That's why I held it from March until June until I thought people were ready. I can tell you categorically that I've had the lowest percentage of parents attend of all time because, let's be real, who wants another kind of obligation? Or also, parents during this time, especially with young children, were not in that growth space necessarily for work because there was so much to keep afloat. So other than the three half days, I also have this optional hour that I throw in just if people can come; there’s this extra exercise that didn't fit in from the original curriculum. And I don't think I've had one parent, maybe one, come across all those cohorts that have been virtual to that. So the optional stuff I see parents opting out of. +That said, I saw more folks who maybe either live alone or maybe have a roommate but who are pre-family or some people won't have families but someone who was socially like, "It was so hard and tiring last year." And that sort of swung back around towards the summer and end of summer. I saw much more interest there because I think people were really lonely. +CHAD: Yeah. And I also think, at least for me personally and for thoughtbot, that was when the thinking definitely shifted that this wasn't going to be going away anytime soon. And so we came to terms with that and started to then make much more long-term plans and permanent changes. +JEN: I think it was also in the...I want to say like early fall when Twitter announced they'd be remote. Like, they have an office, but they wouldn't oblige anyone to ever come back again. And whenever that decision was made, there were a couple of other companies...At that point, I was still living in the Bay Area, and there were a couple of other companies that made similar suggestions. And so again, to your point, there was a revisioning of what the next phase was like or at least what to expect. And so, I think people weren't holding out to go back to normal. It was like, what's the new normal? +CHAD: Yeah. So when we first shut down offices and went remote, we were giving updates every two weeks, and then it changed to every month. And then it would be like, "There's really no change. We're going to give another update in April." And then April was, "We'll give another update in May." And when it came to June, we just said, "We're planning on being in this mode for at least the end of the year. Let's start all acting and make this sustainable." So that is when our thinking changed too. +JEN: Did you feel like with your CEOness and business responsibility over there...what kept you grounded for all that thing? Because obviously every time you make that announcement or regardless of whether that's in person or just...I don't even know– retention or whatever it is. It feels like you're just building strategy on freaking quicksand. +CHAD: It wasn't easy. You feel responsible for everybody's well-being, both financially and everything else. And so the lack of stability…you want to provide it in an unstable world. You want to say, "Well, at least you shouldn't have to worry about this. Let’s provide…" but it was impossible to do. And I'm much more comfortable with uncertainty. I think there's a spectrum of comfortableness with uncertainty, and I'm pretty far on one end of it, and even I was struggling. Same thing with like I'm very much on the spectrum of not having to worry about anxiety or anything like that, and even I was feeling it. And so I was just like...at one point I said to I think it was Diana or whatever "If I'm feeling this, if I'm getting chest palpitations, [laughs] something's really wrong, and we really need to pay attention to how everybody else is feeling." +JEN: Oh, yeah. I even saw that anxiety obviously with coaching clients. There are some clients that when budgets dried up, there was like an initial drop-off, I would say March, April. But then I feel very lucky that the pipeline was still very strong, and I had clients stay with me or join or whatever. +You remember as well as anybody not only did we have this health crisis going on, which again we still do but my last class...So third of three of the cohort in May last year was a couple of days after George Floyd's murder. And the responsibility I felt too...like, when all these things were going on last summer, it was like, who freaking cares about anything? It's like these huge things. And you start to say nothing matters. There are only three things that matter in life. And then you kept sort of recycling the drain on that. +So here I am going into teaching the third of three classes. And during the third class, I always teach concepts on how to hire, concepts on how to lay someone off and fire someone, which everyone's always very barfy and nervous about. And I try to bring us together and graduate us in what feels like a victorious moment. But that's three days after George Floyd's murder, and everyone is reeling and needing to process. And I remember thinking that morning, I don't know how this is going to go because I was fully willing to rip up the plan and do something different. But at the same time, there's also sometimes they want some structure. Folks want to just show up and take this class and be distracted from what's going on in the world. +So we sort of talked about this a few minutes before we started recording but really, what has been fascinating and challenging about continuing to train managers over the last two years is that these very large things are going on in the background: George Floyd's murder, a lot of social unrest in Minneapolis, the election, COVID, all these things. And you can't just put that away and show up to manager training. It is freaking relevant because it is relevant for them. Of course, it's very meta, but all of my students are then going to go back and be responsible for 3, 5, 7 other people in their day-to-day work. So it was really wild, but again, stretching and a challenge that I met with a lot of intention. I don't know if I was always super successful at it, but I thought a lot about it. +CHAD: Yeah, I think that was the shift that we saw on our team. And what I've heard from people is that enough is enough in several different categories of things. And like, we just can't keep on doing what we were doing before. It's not working, and it is unacceptable. People are angry too. So it's not just processing. It's anger and wanting to see action, wanting to take action. And yet, doing it in a world where we can't actually be together, I think, made it particularly challenging for some people and for managers to know how to meet their team members where they were. And people process things in different ways too, and people need different things. +And at that point, we had hired people who had only ever been remote. So I think the connections that you have with people that you might've worked with in person you can lean on a lot in the beginning. But then you're working with someone or managing someone who you've never met in person. +JEN: Yeah. It's a whole new ball game. And I think that the notion of community has gone through the wringer, not only in the worst, it's a rebirth almost. I think the notion of locally what's going on for you and then who can you see? Who can you have a barbecue with? All of those questions of like, who can I be with? Of course, the internet's great, but the internet has some major, major boundaries to it. And people see that at work, and they see that in training. +CHAD: One of the things we're struggling with in that category now is there are people who live next to each other because we were historically in offices. And as it becomes more possible to get together with each other, and this is something that, as managers, we're trying to navigate, it actually has a huge potential for exclusion now that we have hired a bunch of people who are anywhere. +If the teams that were in-person together but are now working remotely start getting in person again, even if it's just an outing at a park, who's not able to attend that, and how will they feel? And what expectations have we set with them? And then you have just sort of equity and inclusion issues around people we've hired in Brazil since we've gone remote. There's no way for them to come. +JEN: Sure. +CHAD: It's not fair. And navigating that as a team, I think we've been able to do that, but it hasn't been easy. +JEN: I think sometimes the only way to see it is none of it will work. So if none of it will work, then cool. The bar's low. [laughter] Yeah, it's not going to be perfect. And all in person had its issues too. So then, if you just sort of bottom it out and say, cool, cool, cool, there's no one silver bullet answer here. So what that means is yes, as human beings, folks who are possibly able to meet up for coffee will resonate and glow and be psyched to be around some other people. So, how do we say "No," less often to that? Because that's great. That's really something to celebrate. And I'm sure if everybody was in that situation, they would try to take advantage of that too. But then to say, if you're not in that situation, here's another option. +And then, every once in a while, we'll mix those options together and have like a rolling menu with it so that nothing gets too static and paralyzed and presumed. And it's in that flow state, which of course, is more fatiguing because you have decision fatigue, and you got to keep making decisions about it. But if you can just say, "Oh, well, we're going to decide that on a week to week basis or on a quarter to quarter." I probably have said this to you before in one of these other podcast conversations, but I just really think that life is a giant science experiment. So if that's true, then you can just say, "Hey, y'all, for Q3, we're going to try this. And at the end of Q3, we'll ask you how that went, and we'll either keep doing it, or we'll totally change it, or we'll increment it." +Software people are really good at this because they know that not everything has to go from 2.0 to 3.0. You could go 2.1, 2.2, 2.3. There are incremental builders. So if you can leverage that metaphor even culturally or socially with the makeup of the team and the way you run things, I don't know; I kind of think that's the best you got. +CHAD: Yeah. And I think we generally have the idea that we trust people and that we can provide the information. And people will generally use that information to make good decisions that are oriented towards fulfillment. So a really good example when it comes to managers is in an environment where if you're meeting in person with someone, one team member and you're their manager, and you're not meeting in person with another, that could influence negatively the other person's path to promotion or the relationship they have with you and just subtly bias you towards the person that you might be able to meet in person with. And so as a manager, making sure people know that, that that is a thing that can happen is a good way to manage that bias because I think generally, people don't want to let that happen, but they might not even realize it, so they can actively manage it. +JEN: Well, it sounds like even in that thought, you are gently nudging people back towards intention and back towards just not sleepwalking through their work, that this is important for us, not only in the distance conversation here but also obviously for race, and for gender and for all kinds of different ways that humans are. We will never get it 100% right and yet intention, and taking a beat, and taking a breath before you move into conversations about promotions or whatever will help remind you hang on a second, remember there's invisible stuff inevitably going on based on who I am and where I came from. How do I make sure things are fair today? Or whatever the reminder needs to be. It sounds like that's...I don't know. It's good that you have that front of mind. +CHAD: So that's one example of remote management. How much of before the pandemic were people who were coming and attending the workshops? Were they managing people remotely? And how much of your curriculum was specific to that, if any? +JEN: My gut says maybe about a third were remote managers. They are definitely with bigger companies that I was seeing that. The small agencies based in Pittsburgh, you know, Austin, those places were pretty localized. But so what you get with a bigger company is also a bit more infrastructure that supports some of these cultural conversations. +And we had it as part of the curriculum, but it wasn't very big, and maybe I would sort of be intentional. There are breakout groups and stuff like that. And I might think I'm going to pair these two together for their practice one-on-one because I know they're both remote managers. I am very intentional about a lot of the pairings and all that stuff, and so I would be thoughtful in that way. But now, on some level, in all these virtual workshops, everybody has an equal footing now. So everybody's kind of screwed, and everybody's also making it work. So that has been a very interesting thing to see. +And I always laugh at this example, a woman who came early on, maybe like the eighth or ninth cohort, and she's a remote manager. And she would say, "Well, I don't have a water cooler. I don't have, like, I'm walking down the hall sensing somebody’s upset or anything." But she would say, "This is going to sound weird, but I keep an eye on how fast they emoji something." So if you have a person who...You know this person in Slack. They're always on Slack, always so supportive, funny, have something to say, a little thumbs-up emoji, or whatever. But if one day they're at work for sure and they haven't said anything about something, she would learn to read the tea leaves like that and check-in. And I just thought that was so clever and very creative. +And what she's alluding to is this level three listening that I teach, which is gut or instinct or intuition. And what she was tracking was basically a change in behavior. And that's pretty much what we're tracking when we're in the office too. There could be many reasons why somebody doesn't emoji something right away. Maybe your daughter just ran into the room. Maybe there's a doorbell. There are a million things. But at the same time, not to be too precious about it but to casually track that at least instinctively. She was doing a good job of meeting the moment as best she could. +CHAD: Are there other ways in which what you've been doing has changed over the last year? What are managers concerned about or challenged by? +JEN: Yeah. First of all, I always had name tags that allowed for pronouns. But this is now certainly part of the curriculum. When we start, I give some social norms and then some tech norms. And so I make the suggestion that in Zoom, after your name, you put your pronouns. And it's not a huge chunk because I really don't feel like I am the best to teach this, but I've added in a DEI component, diversity, equity, inclusion component. And we have some folks in the alumni community who are DEI consultants, so that's great. I always give them shout-outs and refer over if people are looking for that. +I've noticed that people are...I'll say careful, but what I mean by careful is that they are aware of all of the stuff we're talking about, like race and social stuff. Depending on where your office was in the country, the election was sometimes really hard. I think about companies in Ohio or Pennsylvania or swing states where it was not obvious that everybody in the office was on the same page about that. And the way that that stuff comes up and is like this piece of baggage in the room that prevents literally like a website being made. We want to think no, that shouldn't enter. That's not relevant here. +And yet people are careful about both trying to say, "Listen, bring who you are. You're accepted here." And also like, well, sometimes what you're suggesting you believe about the world is harmful. The whole Basecamp thing is a good example of that. And so I found the managers who come to my training to just be open to not only sharing their experiences with that but looking very much for some guidance on that from their peers and then from me. +CHAD: That's sort of what I was saying about people felt like you needed to be changing the way that you were approaching things. It wasn't okay anymore for most people to say, "We shouldn't be having this conversation. It's not a work-related conversation." It affects people's work and their ability to work. It is a work issue. And you can't simply put everything aside. That's one angle of it, but we're not all equipped. We're not all educated. We're not all ready to be able to do that as managers. +JEN: Totally. But with the amount of shit that we have had to handle for the last two years, short of somebody who's a social worker/priest, I don't know who was ready. I feel like a lot of what we're talking about is so resonant for me because all of this is so hard. And if you are alone doing hard things, it's impossible. But the reason that I run the manager trainings the way I do and the reason that I hold onto them after and I put them in a Slack community, they're now alumni of the program. And it's active; it depends on the day. But people have hard questions that they're wrestling with. People have jobs that they're promoting, that they're trying to get people to apply to. It's this active community that goes on afterwards. +Because, honestly, Chad, I feel like a big input into me creating So You're Now a Manager and the community around it was my experience becoming a parent. I was one of the first ones of all my friends. I was the first one of my siblings, and my son was the first grandchild on both sides. And I was like, this is so lonely. All my friends are going out in Brooklyn for dinner. And I was 31. It's not like I was very young or anything, but that's New York. And so I had a moms’ group. And man, that moms’ group got me through those early days because we could all laugh at how hard it was. We could cry together. +And when I looked at the transition that people go through from IC, individual contributor, to manager or some level of leadership, you get responsibility. You have to play the messenger sometimes, something you're not totally down with. You have sometimes competition with peers. You have to manage up sometimes. And then you have these people who come to you with requests: I want a new career path. I want more money. I want a different title. And the slog of that is very reminiscent, on some level, of parenting to me. +So I thought, well, this is not going to be like, here's your book. Good luck being a manager, although books could be helpful. For me, it seemed like there was at least a certain template of a person in the world who could use community too. So I always say you'll be with me for two days or a month if it's virtual. But I can't possibly teach you everything you'll encounter. That said, we can get some critical skills under your belt. And then you can just continue to riff with this peer network. And that has been a very, I would say, unique thing about the manager training I run and something that is so fulfilling to me. I have a very tiny business. Those are, in weird ways, kind of my colleagues, the funny jokes they tell or those personalities. That was another thing that we had to let go of. In 2020, I was going to have the first reunion. +CHAD: Oh yeah. We actually talked about that in the previous episode as an idea. +JEN: Heartbreaking. Yeah, it was called Encore. Basically, it was a follow-up and open to anybody that has already taken SNYAM, So Now You're a Manager. I had people who pitched talks, and we had selected them. And yeah, we had to pull the plug on that. So my hope is that next year we can do that. And now we've got almost...actually; I think we just hit 300 people, so maybe 50 will come, I don't know. We'll see. But I like the idea of providing a space for these folks who were new managers when I knew them and when they came through me but have gained some skills themselves and could become thought leaders in this management space. And whenever the world is ready for it, I'm excited to put that together. +CHAD: Yeah, that's awesome. That sense of community is one thing I've struggled with, to be honest. Because having done this for 18 years, there aren't many people who worked at the company that work there now anymore. [chuckles] We've grown too. So I no longer have the close personal relationship that I had with most people at the company before or close work relationships. And combined with as we've grown, it's harder...you have to be more of a leader. You have to put yourself aside. It's harder to always be a servant to others. And then I found that especially difficult last year. And it's part of why I needed to not be CEO anymore and to transition to the COO role. Because I couldn't be in a position where everyone was always looking to me continually to make...and as distributed as we are, one of our values is self-management. But continually always looking to me to be the one who always has an answer, who is the stable one, I needed a break from that. So it's been nice, the transition. +JEN: I was going to say is it better? +CHAD: [chuckles] So it's a little bit different than I expected. So what happened was we made that change. We made other changes, and that was all going well. And then, in February, the largest vaccine scheduling provider in the United States came to us and needed help scaling the infrastructure and all that stuff. +JEN: Oh my God. That's exciting. +CHAD: And so I, along with a crack team of other experienced thoughtboters, went and spent all of our time focused on that. It has pros and cons, which is right as I was transitioning into a new role; I completely got pulled away and started working full-time with that client for a very important cause, which is the reason why we did it and decided it was worth it. The silver lining is it put everyone else in a position where we went very quickly from Chad's no longer the CEO to Chad's not here right now. [chuckles] And that was unexpected. But I think that it had downsides, but it had upsides too in terms of really being in a position where people could come into their own, into their new roles and sort of a forcing function for some of the changes that we needed to make. +JEN: You know, I'll give you major props on that, Chad. Because 18 years and especially, I think this about a lot of things, but especially business here, people get stuck. They really do. They get stuck, especially founders, CEOs. They don't know how to get out of something if they're tired. And there are not a lot of models for what that could look like. The biggest disservice someone could make to leading a company would be to not really be feeling it because that shit trickles down. And if you're tired or if it's not your thing anymore, really, the biggest gift you can give is to go get aligned somewhere else and then hand over the reins to what I keep thinking of as the next generation. +I coach a lot of people, or I work with a lot of people who are in the middle, let's say, so they're not C-suite, and they're not newest managers, but they're sort of senior there. They're totally ready to go. I can't overstate that. [chuckles] Will they mess stuff up? Sure. So did you. Will they have questions? Absolutely. But the next generation of every company it's the most strategic thing that a CEO could do is to think, what happens if I'm not here? That allows you to take a freaking vacation, like take a month off. Or that allows you to meet such a huge civic call, which you're describing here, and step away. Or again, God forbid something happened, and you get very sick; it allows the company to be bigger than yourself. +So I just commend you on even having the courage to step towards COO and then obviously also kind of redirect as needed this year. But I hope that if there are other CEOs listening or folks in the C-suite who are wiped, this is my gentle nudge to them to hand over the reins at some point. Because you'll get a paycheck, I’m sure you can figure that. +CHAD: [chuckles] Being wiped was one small part of it. And I had Diana on who's the new CEO, and we talked about this. We had grown to a certain point. Also, to toot my own horn, I had done a really good job of building a team of managing directors who were really good at what they were doing. And I was no longer the best manager for them. I was no longer what they needed in order to continue to grow. I could do it, but I wasn't the best person for it. So that was the overriding reason to make the change, and being tired and needing to not always be the one that everyone was looking to was certainly a part of it. But yeah, it's been good. +JEN: Yeah. I figured we would get there at some point, but we talked a little bit earlier about how I have this new product coming out in September. So the product is called Manager Weeklies, and it's basically...I got to figure out the exact noun for this. I guess this is the marketing moment. [chuckles] But it's basically a small notebook. The way I think of it is it helps you take a deep breath before your week starts. And so I'm not messing with your to-do lists. Everybody has different versions of that, Trello or wherever the heck you keep it. But before you start the week, it is so important to wonder where's my energy at? What's my perspective? What are the couple of priorities? What am I blocking? Just a couple of invitation questions there. +And then the idea is that you then can do this on whatever, a Sunday night or Monday morning. And then the rest of the week has, I feel like I've said intention 50 times in this conversation but has intention in it. You can decline those three meetings because they're not the highest priority. You can make some space to actually do the work that comes out of the meetings that you're in. And what I have watched over the last maybe three years are my coaching clients who get themselves together at the beginning of the week who have some sort of practice about setting things up in a good way are the most successful. They get the promotions because they look like they know what they're doing because they do. +So anyway, it's called Manager Weeklies. So it's a small notebook. Each notebook is for a quarter. And then, because I'm a coach, I also filled it with other good stuff. Like at the end, there are all kinds of prompts for ways to give praise to people on your team, ways to give feedback, ways to handle conflict, ways to say, "Yes, no, maybe." And then there's a Work Wheel tool at the very end. +And so my hope is that people who just feel like they show up on a Monday already behind that they would find some help with that intention. And I feel like what you're saying is that self-awareness component that came through for you, Chad, to say, I'm not the best at this, and also, I'm a little fatigued and so, therefore, deep breath. Here's the strategy going forward. It wasn't reactive, but there was some thought behind it. And so we'll see this fall people get a chance to try that out. +CHAD: That's awesome. I feel like it's getting back to your roots but also building on it. So for people who don't know, the Plucky Cards were actually the first way that I was introduced to you was someone showing me a pack of those cards. So, where can people find out more about that? +JEN: The best way for people to find any information is just to subscribe to the newsletter. I send it once a month. It's usually a reflection on work, life, something going on there. So if you go to beplucky.com/newsletter, then you'll be first in the know. What's very funny, Chad, is I have a former coaching client who holds the record now. He was the first one to buy the first pack of cards. He was the first one to buy the second pack of cards. [laughs] And he was also the first one to do this Small Group ticket that I recently did as a little offshoot of Plucky. So anyway, in my mind, I always laugh, and I wonder, I wonder if he's going to grab the first pack of Manager Weeklies this fall. +But you're right. They certainly plug and play with the cards very well where there's even space in the weekly template to say, what's the one-on-one topic for the week? So it could be a card that you pull, and you use, or it could just be something else going on in the world that you want to bring to all the one-on-ones. But I feel like there are a lot of things I'm not great at in the world, but the things I am good at are people. And then I listen to people over and over again through all of these experiences. And I try to hear what else do they need? What weird little thing can I invent that could help them with some of these things that they struggle with? +And I'm also just really mindful of the fact that not everybody has the budget for coaching or for manager training. And I would love for Plucky to be a brand that even if you work for a nonprofit or if you don't have the money to pay for some of those more expensive things that you would have 35 bucks for a pack of cards or 20 bucks or whatever the pricing will be for the notebooks and that you can engage with my brand, even if you're not very wealthy. And I feel like as a person who works and serves an industry like tech, that is always really a priority for me to not only coach or work with the people with the most money. +CHAD: Yeah. If I remember right, you designed the cards, right? +JEN: Oh my God, I wish. No. +CHAD: Oh, okay. +JEN: For the first pack of cards I worked with, I don't know if you know him, Greg Storey. +CHAD: Yeah. +JEN: He's great. Greg Storey did my first deck of cards, and then he moved on, and he's doing other interesting things with his career. So I have a designer who helped me with the second deck of cards called the Manager Pack. So that's questions for managers of managers to bring to one-on-ones, and then the Manager Weeklies are coming out. I've been collaborating with a woman who runs a design little shop called YupGup in Delaware. So her name is Joni. So it is so wild, Chad. I wish that I had any design sense. But it's like, I make these things which look like a terrible PowerPoint. I'm like, here, then there will be a bullet. And then I give it to a designer like Joni at YupGup, and all of a sudden, she has a logo. And then she has some emojis and colors. And I'm like, this is how I felt when I was pregnant, and someone showed me a sonogram, and I was like, (gasps) there's a baby in there. +CHAD: [laughs] +JEN: This is how I felt when she showed me them, and it was so exciting. And I will never be good enough to even be talented at all to make these things myself. But I hold the idea, and then I find someone who wants to help me make that in the world. It's just magical. That is so fun for me. And so I just ordered them. Actually, I ordered 1,000 of them about three hours ago. And so they'll come in August, and I just know it will be very surreal when I open the box and look at them and think about how many people in the world and pens in the world will be used to set intention, to set up people's weeks and hopefully, make a softer and more fair and thoughtful place to work. +CHAD: And one of the things I love about your business and products is that you know you're having an impact beyond that 1,000 notebooks that you put out in the world because each of those people manages 3, 4, 6, 7 people. And if you can make work better for those people, then you have a 7,000-person impact. +JEN: Yeah. And it's funny you say that because I think that recently...I keep saying I'm about to go away for a month or just be out of work for a month as a break after this whole COVID time. Since starting Plucky eight years ago, I didn't really have a model. I am not a traditional business. And even though many people kept saying, "When are you going to hire? When are you going to build the team? When are you going to do all of that?" That is not the shape of Plucky medium-term or long-term. I'm not going to be a coach factory. I certainly could, but then I'd end up super burned out and not liking my job. And then I'd have a sad company, and it would be bad. So I don't want to do that. +CHAD: And that's literally the opposite of Plucky. +JEN: Right. I mean, in the name, right? So, where I have landed as a model is to look at what artists do. And you would never take an artist...I really like Lisa Congdon in Portland. She's a cool, cool artist. And I've heard her speak, and I like her a lot. And what would Lisa Congdon's team look like? She sure isn't hiring other artists to do the work that she's over-signed up for. You get Lisa. And so she has a shop, and then she has partnerships where she teaches at different universities. And as I move into the ninth year here, I'm thinking a lot about what's standing between me and Plucky's shape and what an artist like Lisa Congdon has going on? +And honestly, fully transparently, I think it's that I need to own that Plucky is me. And it's so messy in marketing. Do you use the royal 'we'? We at Plucky? Who is we? And I think that there's some good growth in front of me this fall and next year to say, yeah, I'm Jen, and I run a company called Plucky. And I'm putting this stuff out in the world, and I hope to have ripple effects. And it won't be by hiring 100 people. It'll be just like you described, selling things to X people, and then those people's reports, those ripples will follow down. And I'm really grateful to have found myself in this place because I love coming to work every day. +CHAD: Awesome. Well, even though you love coming to work every day, also enjoy your vacation. +JEN: Oh my God. Thank you. +CHAD: And your time off and your time to reflect. +JEN: Yes, thank you so much. +CHAD: You already mentioned the website, but again, mention that, and then are there other places that people can follow along or get in touch with you? +JEN: Yes, sure. So the newsletter, like I said, is beplucky.com/newsletter. On Twitter, you can look at @BePlucky. I'm on LinkedIn, too, obviously for Plucky. And then I have basically a behind-the-scenes account on Instagram because it was too annoying...Like, what do you take pictures of, Chad, when you're a coach? You can't take pictures of confidential conversations. +CHAD: [laughs] +JEN: So Instagram, I was like, I don't know what to do with this anymore. So anyway, I just have a behind-the-scenes one over there, which is called bepluckster because somebody else had it. So yeah, so all those ways. +And also, I just generally say that if you're a person listening to this podcast and you just wanted to say something to me or ask a question, you should always just email me. It's just hello@beplucky.com. I love just hearing from people. And I might not be able to send you a three-page essay back, but I really love just interacting. And if something moved you or made you think about something, whether that was something I said or Chad, you can always just shoot me a note and tell me what you're thinking. I am not precious about that. +CHAD: Awesome. Likewise. So you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. Thanks for joining us, Jen. +JEN: Thank you. +Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Jen Dary. + + + Chad talks to Leadership Coach and Founder of Plucky, Jen Dary, about working with individuals and companies to create healthy dynamics at work.

+ +

In fact, Plucky just released a new product that aids in doing just that! Manager Weeklies are notebooks designed to help leaders intentionally set up their weeks and track progress. It includes tips and tricks, including useful 1:1 tools. Each notebook is designed to last one quarter.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jen Dary, founder of Plucky. Jen, welcome back to the podcast.

+ +

JEN: Thank you. My third time. Three time's a charm. I feel very lucky.

+ +

CHAD: There aren't many people who have been on the podcast as guests three or more times. So you're in an ever-increasing select group of returning guests.

+ +

JEN: Thank you. I feel like it's maybe because the Tokyo Olympics have just started, but I feel competitive and ready to take on this third session.

+ +

CHAD: [laughs] So the last time you were on was October 28th, 2019 is when the episode came out.

+ +

JEN: Millennia ago.

+ +

CHAD: Not quite two years ago, but yeah, also a millennia ago. And that was Episode 342 so if people want to go back and take a listen to that. And then before that, you were on Episode 270, which I actually don't even know the date of. It was even longer. So welcome back. You are celebrating the eighth anniversary of Plucky.

+ +

JEN: I know. I don't really think of it in these ways because I don't have an MBA, or I didn't come from a business background or anything. But definitely when I hit five years, I feel like my husband said something about that. He was like, "Honey, you should be really proud. Not a lot of businesses make it five years." And that was not really on my mind.

+ +

But now that Plucky is eight, I feel like oh man, I'm just so happy to talk about how businesses evolve and how what you thought it was going to be in year one was different than year three, was different than year five, and of course, it's different than year eight. So we're eight years in, but nothing's the same, and everything's the same. I'm sure you've experienced that too.

+ +

CHAD: It was actually the eighth year going into the ninth year mark that we at thoughtbot started to make big changes. And it was that idea of coming up on a decade. It started to feel like, wow, there's real momentum here. And instead of thinking about what the next year looks like, what does the next decade look like? And are we the kind of company that is going to last 20 years? And that put us in a different mindset. And I started to think about the impact we were having and the legacy that we would have. And was it big enough for the size of the company that we had?

+ +

JEN: How old is thoughtbot right now?

+ +

CHAD: We just celebrated our 18th anniversary.

+ +

JEN: Oh my gosh. All right. Well, maybe at the very end, you can give me your best wisdom for the ninth year. [laughter]

+ +

CHAD: Oh jeez. Okay. [chuckles]

+ +

JEN: No presh, but tuck that in the back of your brain.

+ +

CHAD: Yeah, get some sleep. That's my best advice.

+ +

JEN: [laughs] Great.

+ +

CHAD: That would be great. We can come back to that.

+ +

JEN: Cool.

+ +

CHAD: So obviously, it's been a big two years since we last talked. I'm sure a lot has progressed in Plucky. How have things changed?

+ +

JEN: Well, what's funny is that the two years spread that we're talking about or 18 months or whatever it is, for the most part, overlaps with COVID so far. So by the end of 2019, things were cooking, and everything is good. And even, personally speaking, my youngest son would be entering kindergarten in the fall of 2020. Again, as a business owner, a mom, all those things I was sort of at the end of 2019 hot, so good.

+ +

And then I was anticipating 2020 to be continued pretty much the same as is. Like, we would keep training managers. I would keep traveling. All that would get easier because the kids are getting bigger, then my kid would go to kindergarten. And I was also finishing a book about...I can't remember if we talked about this before, but I was really sick in 2016. I had a brain tumor diagnosis, and I'm okay now. It was benign. I had this memoir that was eh, I don't know, maybe two-thirds done. All that was the plan for 2020, Chad. And I'm sure this is shocking news to you, but none of it happened, including freaking kindergarten, obviously in person.

+ +

So on the business side of things, I kept everything stable as best as I could. So coaching kept going because coaching has always been remote. We have some products, and we kept shipping those out as best we could. At the very beginning of COVID, when everybody thought it was this three, four-week hiatus from real life, I recorded a story every day. Because I was like, what can I do for all the world that's working? So I recorded a storytime for Plucky with my kids. And I put it out on social media so that working parents could have another 15 minutes of distraction for their kids. That's how cute I was back then. [laughter] After one month of that, I was like, I need somebody to read stories to my kids. Yikes.

+ +

CHAD: Yeah. [laughs]

+ +

JEN: So the big thing that changed was that our manager trainings in person obviously I had to cancel those. So I transitioned from in-person to virtual events, and that has continued. And as of this recording, end of July, I was thinking that our November event this year…it's the 20th cohort of So Now You're a Manager. I was going to have it in person. And just last week, I pulled the plug on that. And I was like, no, we're going to stay virtual a little bit longer because I don't know how to predict what the hell is coming. So again, that sort of stabilizing, right? Like, okay, well, now I know how to do the virtual. That will be the stable choice this year, which is weird to say, but true.

+ +

CHAD: Yeah. So you just gave a great organic listing of the things that Plucky does, and a big part of that was that in-person So Now You're a Manager training, which, if people remember from the previous episodes, new managers at thoughtbot have attended over the years. It's a really great training for people who become managers. So what was transitioning that to remote like? Because you'd only ever done it in person before, right?

+ +

JEN: Yeah, totally. The first 11 cohorts were in person, and then we got to 12, and that was supposed to happen in March in Atlanta. We canceled that, and it wasn't until June that we had the 12th, and that was the first virtual one. And to say that I needed to go through stages of grief is probably pretty accurate. [chuckles]

+ +

My energy in person is so a thing, like a tool of mine and just pulling people together, and making safe space for conversations and all that jazz. So I was like, what the hell is that going to be like on Zoom? And meanwhile, remember I'm watching my first grader go through the shenanigans of Zoom for the end of that year. And I'm like, oh my God, how am I possibly going to get grown-ups on this and paying attention and not being distracted?

+ +

So a couple of things, I will say number one is I definitely interviewed four or five people in the industry who are good at virtual events, and I tried to get their deepest wisdom about it. The second thing is that I made the cohorts smaller. So in person, we have around 20 to 22 max, and in virtual, we do 10 to 12 max. And so that got a lot smaller. Also, instead of being two days back to back, I broke it into three half days which is just a different ask. And I wasn't sure if people would bite at that.

+ +

I tried to mimic it after how some people do an MBA on the side. So then they go to work, and they practice the stuff they're learning at the MBA. And so that has been my thought like, okay, you'll be with me basically for a month. We'll have three half days together, usually on a Friday. And then you're practicing in the meantime. So between the times I see you, you're improving your listening skills. You're coming back with anecdotes about hires or tough conversations or whatever. So I won't say that's like a silver lining, but it's just a different beast. And the first day I did it, I mean, I'm telling you, I was on the bathroom floor on my knees like, don't let the internet go out.

+ +

CHAD: [laughs]

+ +

JEN: I was so scared. I don't know why looking back. I'm in tech, but I'm not technical. It's my husband who helps me set up a monitor and whatnot. Oh God, I was so nervous. And I just thought, shit, this is the thing I can't problem-solve. If the internet goes out, I don't know what to do, but if someone's upset, I can help them. So it just brought all of my skills in a different environment. And now I feel pretty good about it.

+ +

I don't know if you found this with your distributed company overall, but I have worked very hard to make sure that it's a blend, of course, this digital experience, but also I use the mail. I use snail mail a lot. So attendees get a packet before we begin. They get a gift at the end, a graduation gift. And yeah, I feel like I've learned a lot about how to have a hand-in-hand experience of digital as well as a physical object that they can touch to make that experience more than just a screen.

+ +

CHAD: Yeah, I think that's important. How did changing the format, reducing the class size, what business ramifications were there for that?

+ +

JEN: Well, it's way less money. [chuckles]

+ +

CHAD: Right. Okay, sorry.

+ +

JEN: No. Oh my God. I want to be very real about these things, especially for people starting their businesses. It's way less money. And also if you think about it, everybody had already bought tickets to Atlanta, and then they had already started buying tickets to...I can't remember what the next one was going to be, New York, I think. So for a lot of the year, everything was, I'll say, comped, but that's not really what's going on. All of a sudden, the amount of seats that I thought I was selling for the year got reduced in about half, and much of that were already pre-bought tickets. So, as a line item, that was way lower.

+ +

I also think I got...man, I haven't really said this transparently to anybody before, but I'll say it here. I got really scared about what to charge. Do you charge the same thing virtually than you do in person? And so I lowered it, I would say for a year. I lowered it by a couple of hundred dollars for each ticket because I didn't know what the market wanted. And also, I didn't know, oh God, were businesses closing? Were people getting prof dev budgets? Everybody was frozen for a good while. So I'm lucky that now today I'm back up to the same price that it had been before, but it's not as much income per event.

+ +

And the other thing I'll say which affects money…but again, I want to be transparent for other folks who think about or currently run businesses. One great thing to come out of some of the social unrest of last year is that we now have an equity scholarship for So Now You're a Manager. So in every cohort, be that virtually or in person, I always reserve a seat for someone who's coming from an underrepresented group, so people apply. And that is something that I very happily said I will eat the cost of that ticket because it's important to me to have different voices in the room. And that has been a total awesome thing this year. That just started in January of 2021, but that's something really great that came out of last year.

+ +

CHAD: Yeah. What did you find that customers wanted, and did it change over time? Was there an appetite for it to be remote, or was there resistance to it?

+ +

JEN: I think at first people were overwhelmed and didn't want it. That's why I held it from March until June until I thought people were ready. I can tell you categorically that I've had the lowest percentage of parents attend of all time because, let's be real, who wants another kind of obligation? Or also, parents during this time, especially with young children, were not in that growth space necessarily for work because there was so much to keep afloat. So other than the three half days, I also have this optional hour that I throw in just if people can come; there’s this extra exercise that didn't fit in from the original curriculum. And I don't think I've had one parent, maybe one, come across all those cohorts that have been virtual to that. So the optional stuff I see parents opting out of.

+ +

That said, I saw more folks who maybe either live alone or maybe have a roommate but who are pre-family or some people won't have families but someone who was socially like, "It was so hard and tiring last year." And that sort of swung back around towards the summer and end of summer. I saw much more interest there because I think people were really lonely.

+ +

CHAD: Yeah. And I also think, at least for me personally and for thoughtbot, that was when the thinking definitely shifted that this wasn't going to be going away anytime soon. And so we came to terms with that and started to then make much more long-term plans and permanent changes.

+ +

JEN: I think it was also in the...I want to say like early fall when Twitter announced they'd be remote. Like, they have an office, but they wouldn't oblige anyone to ever come back again. And whenever that decision was made, there were a couple of other companies...At that point, I was still living in the Bay Area, and there were a couple of other companies that made similar suggestions. And so again, to your point, there was a revisioning of what the next phase was like or at least what to expect. And so, I think people weren't holding out to go back to normal. It was like, what's the new normal?

+ +

CHAD: Yeah. So when we first shut down offices and went remote, we were giving updates every two weeks, and then it changed to every month. And then it would be like, "There's really no change. We're going to give another update in April." And then April was, "We'll give another update in May." And when it came to June, we just said, "We're planning on being in this mode for at least the end of the year. Let's start all acting and make this sustainable." So that is when our thinking changed too.

+ +

JEN: Did you feel like with your CEOness and business responsibility over there...what kept you grounded for all that thing? Because obviously every time you make that announcement or regardless of whether that's in person or just...I don't even know– retention or whatever it is. It feels like you're just building strategy on freaking quicksand.

+ +

CHAD: It wasn't easy. You feel responsible for everybody's well-being, both financially and everything else. And so the lack of stability…you want to provide it in an unstable world. You want to say, "Well, at least you shouldn't have to worry about this. Let’s provide…" but it was impossible to do. And I'm much more comfortable with uncertainty. I think there's a spectrum of comfortableness with uncertainty, and I'm pretty far on one end of it, and even I was struggling. Same thing with like I'm very much on the spectrum of not having to worry about anxiety or anything like that, and even I was feeling it. And so I was just like...at one point I said to I think it was Diana or whatever "If I'm feeling this, if I'm getting chest palpitations, [laughs] something's really wrong, and we really need to pay attention to how everybody else is feeling."

+ +

JEN: Oh, yeah. I even saw that anxiety obviously with coaching clients. There are some clients that when budgets dried up, there was like an initial drop-off, I would say March, April. But then I feel very lucky that the pipeline was still very strong, and I had clients stay with me or join or whatever.

+ +

You remember as well as anybody not only did we have this health crisis going on, which again we still do but my last class...So third of three of the cohort in May last year was a couple of days after George Floyd's murder. And the responsibility I felt too...like, when all these things were going on last summer, it was like, who freaking cares about anything? It's like these huge things. And you start to say nothing matters. There are only three things that matter in life. And then you kept sort of recycling the drain on that.

+ +

So here I am going into teaching the third of three classes. And during the third class, I always teach concepts on how to hire, concepts on how to lay someone off and fire someone, which everyone's always very barfy and nervous about. And I try to bring us together and graduate us in what feels like a victorious moment. But that's three days after George Floyd's murder, and everyone is reeling and needing to process. And I remember thinking that morning, I don't know how this is going to go because I was fully willing to rip up the plan and do something different. But at the same time, there's also sometimes they want some structure. Folks want to just show up and take this class and be distracted from what's going on in the world.

+ +

So we sort of talked about this a few minutes before we started recording but really, what has been fascinating and challenging about continuing to train managers over the last two years is that these very large things are going on in the background: George Floyd's murder, a lot of social unrest in Minneapolis, the election, COVID, all these things. And you can't just put that away and show up to manager training. It is freaking relevant because it is relevant for them. Of course, it's very meta, but all of my students are then going to go back and be responsible for 3, 5, 7 other people in their day-to-day work. So it was really wild, but again, stretching and a challenge that I met with a lot of intention. I don't know if I was always super successful at it, but I thought a lot about it.

+ +

CHAD: Yeah, I think that was the shift that we saw on our team. And what I've heard from people is that enough is enough in several different categories of things. And like, we just can't keep on doing what we were doing before. It's not working, and it is unacceptable. People are angry too. So it's not just processing. It's anger and wanting to see action, wanting to take action. And yet, doing it in a world where we can't actually be together, I think, made it particularly challenging for some people and for managers to know how to meet their team members where they were. And people process things in different ways too, and people need different things.

+ +

And at that point, we had hired people who had only ever been remote. So I think the connections that you have with people that you might've worked with in person you can lean on a lot in the beginning. But then you're working with someone or managing someone who you've never met in person.

+ +

JEN: Yeah. It's a whole new ball game. And I think that the notion of community has gone through the wringer, not only in the worst, it's a rebirth almost. I think the notion of locally what's going on for you and then who can you see? Who can you have a barbecue with? All of those questions of like, who can I be with? Of course, the internet's great, but the internet has some major, major boundaries to it. And people see that at work, and they see that in training.

+ +

CHAD: One of the things we're struggling with in that category now is there are people who live next to each other because we were historically in offices. And as it becomes more possible to get together with each other, and this is something that, as managers, we're trying to navigate, it actually has a huge potential for exclusion now that we have hired a bunch of people who are anywhere.

+ +

If the teams that were in-person together but are now working remotely start getting in person again, even if it's just an outing at a park, who's not able to attend that, and how will they feel? And what expectations have we set with them? And then you have just sort of equity and inclusion issues around people we've hired in Brazil since we've gone remote. There's no way for them to come.

+ +

JEN: Sure.

+ +

CHAD: It's not fair. And navigating that as a team, I think we've been able to do that, but it hasn't been easy.

+ +

JEN: I think sometimes the only way to see it is none of it will work. So if none of it will work, then cool. The bar's low. [laughter] Yeah, it's not going to be perfect. And all in person had its issues too. So then, if you just sort of bottom it out and say, cool, cool, cool, there's no one silver bullet answer here. So what that means is yes, as human beings, folks who are possibly able to meet up for coffee will resonate and glow and be psyched to be around some other people. So, how do we say "No," less often to that? Because that's great. That's really something to celebrate. And I'm sure if everybody was in that situation, they would try to take advantage of that too. But then to say, if you're not in that situation, here's another option.

+ +

And then, every once in a while, we'll mix those options together and have like a rolling menu with it so that nothing gets too static and paralyzed and presumed. And it's in that flow state, which of course, is more fatiguing because you have decision fatigue, and you got to keep making decisions about it. But if you can just say, "Oh, well, we're going to decide that on a week to week basis or on a quarter to quarter." I probably have said this to you before in one of these other podcast conversations, but I just really think that life is a giant science experiment. So if that's true, then you can just say, "Hey, y'all, for Q3, we're going to try this. And at the end of Q3, we'll ask you how that went, and we'll either keep doing it, or we'll totally change it, or we'll increment it."

+ +

Software people are really good at this because they know that not everything has to go from 2.0 to 3.0. You could go 2.1, 2.2, 2.3. There are incremental builders. So if you can leverage that metaphor even culturally or socially with the makeup of the team and the way you run things, I don't know; I kind of think that's the best you got.

+ +

CHAD: Yeah. And I think we generally have the idea that we trust people and that we can provide the information. And people will generally use that information to make good decisions that are oriented towards fulfillment. So a really good example when it comes to managers is in an environment where if you're meeting in person with someone, one team member and you're their manager, and you're not meeting in person with another, that could influence negatively the other person's path to promotion or the relationship they have with you and just subtly bias you towards the person that you might be able to meet in person with. And so as a manager, making sure people know that, that that is a thing that can happen is a good way to manage that bias because I think generally, people don't want to let that happen, but they might not even realize it, so they can actively manage it.

+ +

JEN: Well, it sounds like even in that thought, you are gently nudging people back towards intention and back towards just not sleepwalking through their work, that this is important for us, not only in the distance conversation here but also obviously for race, and for gender and for all kinds of different ways that humans are. We will never get it 100% right and yet intention, and taking a beat, and taking a breath before you move into conversations about promotions or whatever will help remind you hang on a second, remember there's invisible stuff inevitably going on based on who I am and where I came from. How do I make sure things are fair today? Or whatever the reminder needs to be. It sounds like that's...I don't know. It's good that you have that front of mind.

+ +

CHAD: So that's one example of remote management. How much of before the pandemic were people who were coming and attending the workshops? Were they managing people remotely? And how much of your curriculum was specific to that, if any?

+ +

JEN: My gut says maybe about a third were remote managers. They are definitely with bigger companies that I was seeing that. The small agencies based in Pittsburgh, you know, Austin, those places were pretty localized. But so what you get with a bigger company is also a bit more infrastructure that supports some of these cultural conversations.

+ +

And we had it as part of the curriculum, but it wasn't very big, and maybe I would sort of be intentional. There are breakout groups and stuff like that. And I might think I'm going to pair these two together for their practice one-on-one because I know they're both remote managers. I am very intentional about a lot of the pairings and all that stuff, and so I would be thoughtful in that way. But now, on some level, in all these virtual workshops, everybody has an equal footing now. So everybody's kind of screwed, and everybody's also making it work. So that has been a very interesting thing to see.

+ +

And I always laugh at this example, a woman who came early on, maybe like the eighth or ninth cohort, and she's a remote manager. And she would say, "Well, I don't have a water cooler. I don't have, like, I'm walking down the hall sensing somebody’s upset or anything." But she would say, "This is going to sound weird, but I keep an eye on how fast they emoji something." So if you have a person who...You know this person in Slack. They're always on Slack, always so supportive, funny, have something to say, a little thumbs-up emoji, or whatever. But if one day they're at work for sure and they haven't said anything about something, she would learn to read the tea leaves like that and check-in. And I just thought that was so clever and very creative.

+ +

And what she's alluding to is this level three listening that I teach, which is gut or instinct or intuition. And what she was tracking was basically a change in behavior. And that's pretty much what we're tracking when we're in the office too. There could be many reasons why somebody doesn't emoji something right away. Maybe your daughter just ran into the room. Maybe there's a doorbell. There are a million things. But at the same time, not to be too precious about it but to casually track that at least instinctively. She was doing a good job of meeting the moment as best she could.

+ +

CHAD: Are there other ways in which what you've been doing has changed over the last year? What are managers concerned about or challenged by?

+ +

JEN: Yeah. First of all, I always had name tags that allowed for pronouns. But this is now certainly part of the curriculum. When we start, I give some social norms and then some tech norms. And so I make the suggestion that in Zoom, after your name, you put your pronouns. And it's not a huge chunk because I really don't feel like I am the best to teach this, but I've added in a DEI component, diversity, equity, inclusion component. And we have some folks in the alumni community who are DEI consultants, so that's great. I always give them shout-outs and refer over if people are looking for that.

+ +

I've noticed that people are...I'll say careful, but what I mean by careful is that they are aware of all of the stuff we're talking about, like race and social stuff. Depending on where your office was in the country, the election was sometimes really hard. I think about companies in Ohio or Pennsylvania or swing states where it was not obvious that everybody in the office was on the same page about that. And the way that that stuff comes up and is like this piece of baggage in the room that prevents literally like a website being made. We want to think no, that shouldn't enter. That's not relevant here.

+ +

And yet people are careful about both trying to say, "Listen, bring who you are. You're accepted here." And also like, well, sometimes what you're suggesting you believe about the world is harmful. The whole Basecamp thing is a good example of that. And so I found the managers who come to my training to just be open to not only sharing their experiences with that but looking very much for some guidance on that from their peers and then from me.

+ +

CHAD: That's sort of what I was saying about people felt like you needed to be changing the way that you were approaching things. It wasn't okay anymore for most people to say, "We shouldn't be having this conversation. It's not a work-related conversation." It affects people's work and their ability to work. It is a work issue. And you can't simply put everything aside. That's one angle of it, but we're not all equipped. We're not all educated. We're not all ready to be able to do that as managers.

+ +

JEN: Totally. But with the amount of shit that we have had to handle for the last two years, short of somebody who's a social worker/priest, I don't know who was ready. I feel like a lot of what we're talking about is so resonant for me because all of this is so hard. And if you are alone doing hard things, it's impossible. But the reason that I run the manager trainings the way I do and the reason that I hold onto them after and I put them in a Slack community, they're now alumni of the program. And it's active; it depends on the day. But people have hard questions that they're wrestling with. People have jobs that they're promoting, that they're trying to get people to apply to. It's this active community that goes on afterwards.

+ +

Because, honestly, Chad, I feel like a big input into me creating So You're Now a Manager and the community around it was my experience becoming a parent. I was one of the first ones of all my friends. I was the first one of my siblings, and my son was the first grandchild on both sides. And I was like, this is so lonely. All my friends are going out in Brooklyn for dinner. And I was 31. It's not like I was very young or anything, but that's New York. And so I had a moms’ group. And man, that moms’ group got me through those early days because we could all laugh at how hard it was. We could cry together.

+ +

And when I looked at the transition that people go through from IC, individual contributor, to manager or some level of leadership, you get responsibility. You have to play the messenger sometimes, something you're not totally down with. You have sometimes competition with peers. You have to manage up sometimes. And then you have these people who come to you with requests: I want a new career path. I want more money. I want a different title. And the slog of that is very reminiscent, on some level, of parenting to me.

+ +

So I thought, well, this is not going to be like, here's your book. Good luck being a manager, although books could be helpful. For me, it seemed like there was at least a certain template of a person in the world who could use community too. So I always say you'll be with me for two days or a month if it's virtual. But I can't possibly teach you everything you'll encounter. That said, we can get some critical skills under your belt. And then you can just continue to riff with this peer network. And that has been a very, I would say, unique thing about the manager training I run and something that is so fulfilling to me. I have a very tiny business. Those are, in weird ways, kind of my colleagues, the funny jokes they tell or those personalities. That was another thing that we had to let go of. In 2020, I was going to have the first reunion.

+ +

CHAD: Oh yeah. We actually talked about that in the previous episode as an idea.

+ +

JEN: Heartbreaking. Yeah, it was called Encore. Basically, it was a follow-up and open to anybody that has already taken SNYAM, So Now You're a Manager. I had people who pitched talks, and we had selected them. And yeah, we had to pull the plug on that. So my hope is that next year we can do that. And now we've got almost...actually; I think we just hit 300 people, so maybe 50 will come, I don't know. We'll see. But I like the idea of providing a space for these folks who were new managers when I knew them and when they came through me but have gained some skills themselves and could become thought leaders in this management space. And whenever the world is ready for it, I'm excited to put that together.

+ +

CHAD: Yeah, that's awesome. That sense of community is one thing I've struggled with, to be honest. Because having done this for 18 years, there aren't many people who worked at the company that work there now anymore. [chuckles] We've grown too. So I no longer have the close personal relationship that I had with most people at the company before or close work relationships. And combined with as we've grown, it's harder...you have to be more of a leader. You have to put yourself aside. It's harder to always be a servant to others. And then I found that especially difficult last year. And it's part of why I needed to not be CEO anymore and to transition to the COO role. Because I couldn't be in a position where everyone was always looking to me continually to make...and as distributed as we are, one of our values is self-management. But continually always looking to me to be the one who always has an answer, who is the stable one, I needed a break from that. So it's been nice, the transition.

+ +

JEN: I was going to say is it better?

+ +

CHAD: [chuckles] So it's a little bit different than I expected. So what happened was we made that change. We made other changes, and that was all going well. And then, in February, the largest vaccine scheduling provider in the United States came to us and needed help scaling the infrastructure and all that stuff.

+ +

JEN: Oh my God. That's exciting.

+ +

CHAD: And so I, along with a crack team of other experienced thoughtboters, went and spent all of our time focused on that. It has pros and cons, which is right as I was transitioning into a new role; I completely got pulled away and started working full-time with that client for a very important cause, which is the reason why we did it and decided it was worth it. The silver lining is it put everyone else in a position where we went very quickly from Chad's no longer the CEO to Chad's not here right now. [chuckles] And that was unexpected. But I think that it had downsides, but it had upsides too in terms of really being in a position where people could come into their own, into their new roles and sort of a forcing function for some of the changes that we needed to make.

+ +

JEN: You know, I'll give you major props on that, Chad. Because 18 years and especially, I think this about a lot of things, but especially business here, people get stuck. They really do. They get stuck, especially founders, CEOs. They don't know how to get out of something if they're tired. And there are not a lot of models for what that could look like. The biggest disservice someone could make to leading a company would be to not really be feeling it because that shit trickles down. And if you're tired or if it's not your thing anymore, really, the biggest gift you can give is to go get aligned somewhere else and then hand over the reins to what I keep thinking of as the next generation.

+ +

I coach a lot of people, or I work with a lot of people who are in the middle, let's say, so they're not C-suite, and they're not newest managers, but they're sort of senior there. They're totally ready to go. I can't overstate that. [chuckles] Will they mess stuff up? Sure. So did you. Will they have questions? Absolutely. But the next generation of every company it's the most strategic thing that a CEO could do is to think, what happens if I'm not here? That allows you to take a freaking vacation, like take a month off. Or that allows you to meet such a huge civic call, which you're describing here, and step away. Or again, God forbid something happened, and you get very sick; it allows the company to be bigger than yourself.

+ +

So I just commend you on even having the courage to step towards COO and then obviously also kind of redirect as needed this year. But I hope that if there are other CEOs listening or folks in the C-suite who are wiped, this is my gentle nudge to them to hand over the reins at some point. Because you'll get a paycheck, I’m sure you can figure that.

+ +

CHAD: [chuckles] Being wiped was one small part of it. And I had Diana on who's the new CEO, and we talked about this. We had grown to a certain point. Also, to toot my own horn, I had done a really good job of building a team of managing directors who were really good at what they were doing. And I was no longer the best manager for them. I was no longer what they needed in order to continue to grow. I could do it, but I wasn't the best person for it. So that was the overriding reason to make the change, and being tired and needing to not always be the one that everyone was looking to was certainly a part of it. But yeah, it's been good.

+ +

JEN: Yeah. I figured we would get there at some point, but we talked a little bit earlier about how I have this new product coming out in September. So the product is called Manager Weeklies, and it's basically...I got to figure out the exact noun for this. I guess this is the marketing moment. [chuckles] But it's basically a small notebook. The way I think of it is it helps you take a deep breath before your week starts. And so I'm not messing with your to-do lists. Everybody has different versions of that, Trello or wherever the heck you keep it. But before you start the week, it is so important to wonder where's my energy at? What's my perspective? What are the couple of priorities? What am I blocking? Just a couple of invitation questions there.

+ +

And then the idea is that you then can do this on whatever, a Sunday night or Monday morning. And then the rest of the week has, I feel like I've said intention 50 times in this conversation but has intention in it. You can decline those three meetings because they're not the highest priority. You can make some space to actually do the work that comes out of the meetings that you're in. And what I have watched over the last maybe three years are my coaching clients who get themselves together at the beginning of the week who have some sort of practice about setting things up in a good way are the most successful. They get the promotions because they look like they know what they're doing because they do.

+ +

So anyway, it's called Manager Weeklies. So it's a small notebook. Each notebook is for a quarter. And then, because I'm a coach, I also filled it with other good stuff. Like at the end, there are all kinds of prompts for ways to give praise to people on your team, ways to give feedback, ways to handle conflict, ways to say, "Yes, no, maybe." And then there's a Work Wheel tool at the very end.

+ +

And so my hope is that people who just feel like they show up on a Monday already behind that they would find some help with that intention. And I feel like what you're saying is that self-awareness component that came through for you, Chad, to say, I'm not the best at this, and also, I'm a little fatigued and so, therefore, deep breath. Here's the strategy going forward. It wasn't reactive, but there was some thought behind it. And so we'll see this fall people get a chance to try that out.

+ +

CHAD: That's awesome. I feel like it's getting back to your roots but also building on it. So for people who don't know, the Plucky Cards were actually the first way that I was introduced to you was someone showing me a pack of those cards. So, where can people find out more about that?

+ +

JEN: The best way for people to find any information is just to subscribe to the newsletter. I send it once a month. It's usually a reflection on work, life, something going on there. So if you go to beplucky.com/newsletter, then you'll be first in the know. What's very funny, Chad, is I have a former coaching client who holds the record now. He was the first one to buy the first pack of cards. He was the first one to buy the second pack of cards. [laughs] And he was also the first one to do this Small Group ticket that I recently did as a little offshoot of Plucky. So anyway, in my mind, I always laugh, and I wonder, I wonder if he's going to grab the first pack of Manager Weeklies this fall.

+ +

But you're right. They certainly plug and play with the cards very well where there's even space in the weekly template to say, what's the one-on-one topic for the week? So it could be a card that you pull, and you use, or it could just be something else going on in the world that you want to bring to all the one-on-ones. But I feel like there are a lot of things I'm not great at in the world, but the things I am good at are people. And then I listen to people over and over again through all of these experiences. And I try to hear what else do they need? What weird little thing can I invent that could help them with some of these things that they struggle with?

+ +

And I'm also just really mindful of the fact that not everybody has the budget for coaching or for manager training. And I would love for Plucky to be a brand that even if you work for a nonprofit or if you don't have the money to pay for some of those more expensive things that you would have 35 bucks for a pack of cards or 20 bucks or whatever the pricing will be for the notebooks and that you can engage with my brand, even if you're not very wealthy. And I feel like as a person who works and serves an industry like tech, that is always really a priority for me to not only coach or work with the people with the most money.

+ +

CHAD: Yeah. If I remember right, you designed the cards, right?

+ +

JEN: Oh my God, I wish. No.

+ +

CHAD: Oh, okay.

+ +

JEN: For the first pack of cards I worked with, I don't know if you know him, Greg Storey.

+ +

CHAD: Yeah.

+ +

JEN: He's great. Greg Storey did my first deck of cards, and then he moved on, and he's doing other interesting things with his career. So I have a designer who helped me with the second deck of cards called the Manager Pack. So that's questions for managers of managers to bring to one-on-ones, and then the Manager Weeklies are coming out. I've been collaborating with a woman who runs a design little shop called YupGup in Delaware. So her name is Joni. So it is so wild, Chad. I wish that I had any design sense. But it's like, I make these things which look like a terrible PowerPoint. I'm like, here, then there will be a bullet. And then I give it to a designer like Joni at YupGup, and all of a sudden, she has a logo. And then she has some emojis and colors. And I'm like, this is how I felt when I was pregnant, and someone showed me a sonogram, and I was like, (gasps) there's a baby in there.

+ +

CHAD: [laughs]

+ +

JEN: This is how I felt when she showed me them, and it was so exciting. And I will never be good enough to even be talented at all to make these things myself. But I hold the idea, and then I find someone who wants to help me make that in the world. It's just magical. That is so fun for me. And so I just ordered them. Actually, I ordered 1,000 of them about three hours ago. And so they'll come in August, and I just know it will be very surreal when I open the box and look at them and think about how many people in the world and pens in the world will be used to set intention, to set up people's weeks and hopefully, make a softer and more fair and thoughtful place to work.

+ +

CHAD: And one of the things I love about your business and products is that you know you're having an impact beyond that 1,000 notebooks that you put out in the world because each of those people manages 3, 4, 6, 7 people. And if you can make work better for those people, then you have a 7,000-person impact.

+ +

JEN: Yeah. And it's funny you say that because I think that recently...I keep saying I'm about to go away for a month or just be out of work for a month as a break after this whole COVID time. Since starting Plucky eight years ago, I didn't really have a model. I am not a traditional business. And even though many people kept saying, "When are you going to hire? When are you going to build the team? When are you going to do all of that?" That is not the shape of Plucky medium-term or long-term. I'm not going to be a coach factory. I certainly could, but then I'd end up super burned out and not liking my job. And then I'd have a sad company, and it would be bad. So I don't want to do that.

+ +

CHAD: And that's literally the opposite of Plucky.

+ +

JEN: Right. I mean, in the name, right? So, where I have landed as a model is to look at what artists do. And you would never take an artist...I really like Lisa Congdon in Portland. She's a cool, cool artist. And I've heard her speak, and I like her a lot. And what would Lisa Congdon's team look like? She sure isn't hiring other artists to do the work that she's over-signed up for. You get Lisa. And so she has a shop, and then she has partnerships where she teaches at different universities. And as I move into the ninth year here, I'm thinking a lot about what's standing between me and Plucky's shape and what an artist like Lisa Congdon has going on?

+ +

And honestly, fully transparently, I think it's that I need to own that Plucky is me. And it's so messy in marketing. Do you use the royal 'we'? We at Plucky? Who is we? And I think that there's some good growth in front of me this fall and next year to say, yeah, I'm Jen, and I run a company called Plucky. And I'm putting this stuff out in the world, and I hope to have ripple effects. And it won't be by hiring 100 people. It'll be just like you described, selling things to X people, and then those people's reports, those ripples will follow down. And I'm really grateful to have found myself in this place because I love coming to work every day.

+ +

CHAD: Awesome. Well, even though you love coming to work every day, also enjoy your vacation.

+ +

JEN: Oh my God. Thank you.

+ +

CHAD: And your time off and your time to reflect.

+ +

JEN: Yes, thank you so much.

+ +

CHAD: You already mentioned the website, but again, mention that, and then are there other places that people can follow along or get in touch with you?

+ +

JEN: Yes, sure. So the newsletter, like I said, is beplucky.com/newsletter. On Twitter, you can look at @BePlucky. I'm on LinkedIn, too, obviously for Plucky. And then I have basically a behind-the-scenes account on Instagram because it was too annoying...Like, what do you take pictures of, Chad, when you're a coach? You can't take pictures of confidential conversations.

+ +

CHAD: [laughs]

+ +

JEN: So Instagram, I was like, I don't know what to do with this anymore. So anyway, I just have a behind-the-scenes one over there, which is called bepluckster because somebody else had it. So yeah, so all those ways.

+ +

And also, I just generally say that if you're a person listening to this podcast and you just wanted to say something to me or ask a question, you should always just email me. It's just hello@beplucky.com. I love just hearing from people. And I might not be able to send you a three-page essay back, but I really love just interacting. And if something moved you or made you think about something, whether that was something I said or Chad, you can always just shoot me a note and tell me what you're thinking. I am not precious about that.

+ +

CHAD: Awesome. Likewise. So you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. Thanks for joining us, Jen.

+ +

JEN: Thank you.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jen Dary.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to Leadership Coach and Founder of Plucky, Jen Dary, about working with individuals and companies to create healthy dynamics at work.

+ +

In fact, Plucky just released a new product that aids in doing just that! Manager Weeklies are notebooks designed to help leaders intentionally set up their weeks and track progress. It includes tips and tricks, including useful 1:1 tools. Each notebook is designed to last one quarter.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Jen Dary, founder of Plucky. Jen, welcome back to the podcast.

+ +

JEN: Thank you. My third time. Three time's a charm. I feel very lucky.

+ +

CHAD: There aren't many people who have been on the podcast as guests three or more times. So you're in an ever-increasing select group of returning guests.

+ +

JEN: Thank you. I feel like it's maybe because the Tokyo Olympics have just started, but I feel competitive and ready to take on this third session.

+ +

CHAD: [laughs] So the last time you were on was October 28th, 2019 is when the episode came out.

+ +

JEN: Millennia ago.

+ +

CHAD: Not quite two years ago, but yeah, also a millennia ago. And that was Episode 342 so if people want to go back and take a listen to that. And then before that, you were on Episode 270, which I actually don't even know the date of. It was even longer. So welcome back. You are celebrating the eighth anniversary of Plucky.

+ +

JEN: I know. I don't really think of it in these ways because I don't have an MBA, or I didn't come from a business background or anything. But definitely when I hit five years, I feel like my husband said something about that. He was like, "Honey, you should be really proud. Not a lot of businesses make it five years." And that was not really on my mind.

+ +

But now that Plucky is eight, I feel like oh man, I'm just so happy to talk about how businesses evolve and how what you thought it was going to be in year one was different than year three, was different than year five, and of course, it's different than year eight. So we're eight years in, but nothing's the same, and everything's the same. I'm sure you've experienced that too.

+ +

CHAD: It was actually the eighth year going into the ninth year mark that we at thoughtbot started to make big changes. And it was that idea of coming up on a decade. It started to feel like, wow, there's real momentum here. And instead of thinking about what the next year looks like, what does the next decade look like? And are we the kind of company that is going to last 20 years? And that put us in a different mindset. And I started to think about the impact we were having and the legacy that we would have. And was it big enough for the size of the company that we had?

+ +

JEN: How old is thoughtbot right now?

+ +

CHAD: We just celebrated our 18th anniversary.

+ +

JEN: Oh my gosh. All right. Well, maybe at the very end, you can give me your best wisdom for the ninth year. [laughter]

+ +

CHAD: Oh jeez. Okay. [chuckles]

+ +

JEN: No presh, but tuck that in the back of your brain.

+ +

CHAD: Yeah, get some sleep. That's my best advice.

+ +

JEN: [laughs] Great.

+ +

CHAD: That would be great. We can come back to that.

+ +

JEN: Cool.

+ +

CHAD: So obviously, it's been a big two years since we last talked. I'm sure a lot has progressed in Plucky. How have things changed?

+ +

JEN: Well, what's funny is that the two years spread that we're talking about or 18 months or whatever it is, for the most part, overlaps with COVID so far. So by the end of 2019, things were cooking, and everything is good. And even, personally speaking, my youngest son would be entering kindergarten in the fall of 2020. Again, as a business owner, a mom, all those things I was sort of at the end of 2019 hot, so good.

+ +

And then I was anticipating 2020 to be continued pretty much the same as is. Like, we would keep training managers. I would keep traveling. All that would get easier because the kids are getting bigger, then my kid would go to kindergarten. And I was also finishing a book about...I can't remember if we talked about this before, but I was really sick in 2016. I had a brain tumor diagnosis, and I'm okay now. It was benign. I had this memoir that was eh, I don't know, maybe two-thirds done. All that was the plan for 2020, Chad. And I'm sure this is shocking news to you, but none of it happened, including freaking kindergarten, obviously in person.

+ +

So on the business side of things, I kept everything stable as best as I could. So coaching kept going because coaching has always been remote. We have some products, and we kept shipping those out as best we could. At the very beginning of COVID, when everybody thought it was this three, four-week hiatus from real life, I recorded a story every day. Because I was like, what can I do for all the world that's working? So I recorded a storytime for Plucky with my kids. And I put it out on social media so that working parents could have another 15 minutes of distraction for their kids. That's how cute I was back then. [laughter] After one month of that, I was like, I need somebody to read stories to my kids. Yikes.

+ +

CHAD: Yeah. [laughs]

+ +

JEN: So the big thing that changed was that our manager trainings in person obviously I had to cancel those. So I transitioned from in-person to virtual events, and that has continued. And as of this recording, end of July, I was thinking that our November event this year…it's the 20th cohort of So Now You're a Manager. I was going to have it in person. And just last week, I pulled the plug on that. And I was like, no, we're going to stay virtual a little bit longer because I don't know how to predict what the hell is coming. So again, that sort of stabilizing, right? Like, okay, well, now I know how to do the virtual. That will be the stable choice this year, which is weird to say, but true.

+ +

CHAD: Yeah. So you just gave a great organic listing of the things that Plucky does, and a big part of that was that in-person So Now You're a Manager training, which, if people remember from the previous episodes, new managers at thoughtbot have attended over the years. It's a really great training for people who become managers. So what was transitioning that to remote like? Because you'd only ever done it in person before, right?

+ +

JEN: Yeah, totally. The first 11 cohorts were in person, and then we got to 12, and that was supposed to happen in March in Atlanta. We canceled that, and it wasn't until June that we had the 12th, and that was the first virtual one. And to say that I needed to go through stages of grief is probably pretty accurate. [chuckles]

+ +

My energy in person is so a thing, like a tool of mine and just pulling people together, and making safe space for conversations and all that jazz. So I was like, what the hell is that going to be like on Zoom? And meanwhile, remember I'm watching my first grader go through the shenanigans of Zoom for the end of that year. And I'm like, oh my God, how am I possibly going to get grown-ups on this and paying attention and not being distracted?

+ +

So a couple of things, I will say number one is I definitely interviewed four or five people in the industry who are good at virtual events, and I tried to get their deepest wisdom about it. The second thing is that I made the cohorts smaller. So in person, we have around 20 to 22 max, and in virtual, we do 10 to 12 max. And so that got a lot smaller. Also, instead of being two days back to back, I broke it into three half days which is just a different ask. And I wasn't sure if people would bite at that.

+ +

I tried to mimic it after how some people do an MBA on the side. So then they go to work, and they practice the stuff they're learning at the MBA. And so that has been my thought like, okay, you'll be with me basically for a month. We'll have three half days together, usually on a Friday. And then you're practicing in the meantime. So between the times I see you, you're improving your listening skills. You're coming back with anecdotes about hires or tough conversations or whatever. So I won't say that's like a silver lining, but it's just a different beast. And the first day I did it, I mean, I'm telling you, I was on the bathroom floor on my knees like, don't let the internet go out.

+ +

CHAD: [laughs]

+ +

JEN: I was so scared. I don't know why looking back. I'm in tech, but I'm not technical. It's my husband who helps me set up a monitor and whatnot. Oh God, I was so nervous. And I just thought, shit, this is the thing I can't problem-solve. If the internet goes out, I don't know what to do, but if someone's upset, I can help them. So it just brought all of my skills in a different environment. And now I feel pretty good about it.

+ +

I don't know if you found this with your distributed company overall, but I have worked very hard to make sure that it's a blend, of course, this digital experience, but also I use the mail. I use snail mail a lot. So attendees get a packet before we begin. They get a gift at the end, a graduation gift. And yeah, I feel like I've learned a lot about how to have a hand-in-hand experience of digital as well as a physical object that they can touch to make that experience more than just a screen.

+ +

CHAD: Yeah, I think that's important. How did changing the format, reducing the class size, what business ramifications were there for that?

+ +

JEN: Well, it's way less money. [chuckles]

+ +

CHAD: Right. Okay, sorry.

+ +

JEN: No. Oh my God. I want to be very real about these things, especially for people starting their businesses. It's way less money. And also if you think about it, everybody had already bought tickets to Atlanta, and then they had already started buying tickets to...I can't remember what the next one was going to be, New York, I think. So for a lot of the year, everything was, I'll say, comped, but that's not really what's going on. All of a sudden, the amount of seats that I thought I was selling for the year got reduced in about half, and much of that were already pre-bought tickets. So, as a line item, that was way lower.

+ +

I also think I got...man, I haven't really said this transparently to anybody before, but I'll say it here. I got really scared about what to charge. Do you charge the same thing virtually than you do in person? And so I lowered it, I would say for a year. I lowered it by a couple of hundred dollars for each ticket because I didn't know what the market wanted. And also, I didn't know, oh God, were businesses closing? Were people getting prof dev budgets? Everybody was frozen for a good while. So I'm lucky that now today I'm back up to the same price that it had been before, but it's not as much income per event.

+ +

And the other thing I'll say which affects money…but again, I want to be transparent for other folks who think about or currently run businesses. One great thing to come out of some of the social unrest of last year is that we now have an equity scholarship for So Now You're a Manager. So in every cohort, be that virtually or in person, I always reserve a seat for someone who's coming from an underrepresented group, so people apply. And that is something that I very happily said I will eat the cost of that ticket because it's important to me to have different voices in the room. And that has been a total awesome thing this year. That just started in January of 2021, but that's something really great that came out of last year.

+ +

CHAD: Yeah. What did you find that customers wanted, and did it change over time? Was there an appetite for it to be remote, or was there resistance to it?

+ +

JEN: I think at first people were overwhelmed and didn't want it. That's why I held it from March until June until I thought people were ready. I can tell you categorically that I've had the lowest percentage of parents attend of all time because, let's be real, who wants another kind of obligation? Or also, parents during this time, especially with young children, were not in that growth space necessarily for work because there was so much to keep afloat. So other than the three half days, I also have this optional hour that I throw in just if people can come; there’s this extra exercise that didn't fit in from the original curriculum. And I don't think I've had one parent, maybe one, come across all those cohorts that have been virtual to that. So the optional stuff I see parents opting out of.

+ +

That said, I saw more folks who maybe either live alone or maybe have a roommate but who are pre-family or some people won't have families but someone who was socially like, "It was so hard and tiring last year." And that sort of swung back around towards the summer and end of summer. I saw much more interest there because I think people were really lonely.

+ +

CHAD: Yeah. And I also think, at least for me personally and for thoughtbot, that was when the thinking definitely shifted that this wasn't going to be going away anytime soon. And so we came to terms with that and started to then make much more long-term plans and permanent changes.

+ +

JEN: I think it was also in the...I want to say like early fall when Twitter announced they'd be remote. Like, they have an office, but they wouldn't oblige anyone to ever come back again. And whenever that decision was made, there were a couple of other companies...At that point, I was still living in the Bay Area, and there were a couple of other companies that made similar suggestions. And so again, to your point, there was a revisioning of what the next phase was like or at least what to expect. And so, I think people weren't holding out to go back to normal. It was like, what's the new normal?

+ +

CHAD: Yeah. So when we first shut down offices and went remote, we were giving updates every two weeks, and then it changed to every month. And then it would be like, "There's really no change. We're going to give another update in April." And then April was, "We'll give another update in May." And when it came to June, we just said, "We're planning on being in this mode for at least the end of the year. Let's start all acting and make this sustainable." So that is when our thinking changed too.

+ +

JEN: Did you feel like with your CEOness and business responsibility over there...what kept you grounded for all that thing? Because obviously every time you make that announcement or regardless of whether that's in person or just...I don't even know– retention or whatever it is. It feels like you're just building strategy on freaking quicksand.

+ +

CHAD: It wasn't easy. You feel responsible for everybody's well-being, both financially and everything else. And so the lack of stability…you want to provide it in an unstable world. You want to say, "Well, at least you shouldn't have to worry about this. Let’s provide…" but it was impossible to do. And I'm much more comfortable with uncertainty. I think there's a spectrum of comfortableness with uncertainty, and I'm pretty far on one end of it, and even I was struggling. Same thing with like I'm very much on the spectrum of not having to worry about anxiety or anything like that, and even I was feeling it. And so I was just like...at one point I said to I think it was Diana or whatever "If I'm feeling this, if I'm getting chest palpitations, [laughs] something's really wrong, and we really need to pay attention to how everybody else is feeling."

+ +

JEN: Oh, yeah. I even saw that anxiety obviously with coaching clients. There are some clients that when budgets dried up, there was like an initial drop-off, I would say March, April. But then I feel very lucky that the pipeline was still very strong, and I had clients stay with me or join or whatever.

+ +

You remember as well as anybody not only did we have this health crisis going on, which again we still do but my last class...So third of three of the cohort in May last year was a couple of days after George Floyd's murder. And the responsibility I felt too...like, when all these things were going on last summer, it was like, who freaking cares about anything? It's like these huge things. And you start to say nothing matters. There are only three things that matter in life. And then you kept sort of recycling the drain on that.

+ +

So here I am going into teaching the third of three classes. And during the third class, I always teach concepts on how to hire, concepts on how to lay someone off and fire someone, which everyone's always very barfy and nervous about. And I try to bring us together and graduate us in what feels like a victorious moment. But that's three days after George Floyd's murder, and everyone is reeling and needing to process. And I remember thinking that morning, I don't know how this is going to go because I was fully willing to rip up the plan and do something different. But at the same time, there's also sometimes they want some structure. Folks want to just show up and take this class and be distracted from what's going on in the world.

+ +

So we sort of talked about this a few minutes before we started recording but really, what has been fascinating and challenging about continuing to train managers over the last two years is that these very large things are going on in the background: George Floyd's murder, a lot of social unrest in Minneapolis, the election, COVID, all these things. And you can't just put that away and show up to manager training. It is freaking relevant because it is relevant for them. Of course, it's very meta, but all of my students are then going to go back and be responsible for 3, 5, 7 other people in their day-to-day work. So it was really wild, but again, stretching and a challenge that I met with a lot of intention. I don't know if I was always super successful at it, but I thought a lot about it.

+ +

CHAD: Yeah, I think that was the shift that we saw on our team. And what I've heard from people is that enough is enough in several different categories of things. And like, we just can't keep on doing what we were doing before. It's not working, and it is unacceptable. People are angry too. So it's not just processing. It's anger and wanting to see action, wanting to take action. And yet, doing it in a world where we can't actually be together, I think, made it particularly challenging for some people and for managers to know how to meet their team members where they were. And people process things in different ways too, and people need different things.

+ +

And at that point, we had hired people who had only ever been remote. So I think the connections that you have with people that you might've worked with in person you can lean on a lot in the beginning. But then you're working with someone or managing someone who you've never met in person.

+ +

JEN: Yeah. It's a whole new ball game. And I think that the notion of community has gone through the wringer, not only in the worst, it's a rebirth almost. I think the notion of locally what's going on for you and then who can you see? Who can you have a barbecue with? All of those questions of like, who can I be with? Of course, the internet's great, but the internet has some major, major boundaries to it. And people see that at work, and they see that in training.

+ +

CHAD: One of the things we're struggling with in that category now is there are people who live next to each other because we were historically in offices. And as it becomes more possible to get together with each other, and this is something that, as managers, we're trying to navigate, it actually has a huge potential for exclusion now that we have hired a bunch of people who are anywhere.

+ +

If the teams that were in-person together but are now working remotely start getting in person again, even if it's just an outing at a park, who's not able to attend that, and how will they feel? And what expectations have we set with them? And then you have just sort of equity and inclusion issues around people we've hired in Brazil since we've gone remote. There's no way for them to come.

+ +

JEN: Sure.

+ +

CHAD: It's not fair. And navigating that as a team, I think we've been able to do that, but it hasn't been easy.

+ +

JEN: I think sometimes the only way to see it is none of it will work. So if none of it will work, then cool. The bar's low. [laughter] Yeah, it's not going to be perfect. And all in person had its issues too. So then, if you just sort of bottom it out and say, cool, cool, cool, there's no one silver bullet answer here. So what that means is yes, as human beings, folks who are possibly able to meet up for coffee will resonate and glow and be psyched to be around some other people. So, how do we say "No," less often to that? Because that's great. That's really something to celebrate. And I'm sure if everybody was in that situation, they would try to take advantage of that too. But then to say, if you're not in that situation, here's another option.

+ +

And then, every once in a while, we'll mix those options together and have like a rolling menu with it so that nothing gets too static and paralyzed and presumed. And it's in that flow state, which of course, is more fatiguing because you have decision fatigue, and you got to keep making decisions about it. But if you can just say, "Oh, well, we're going to decide that on a week to week basis or on a quarter to quarter." I probably have said this to you before in one of these other podcast conversations, but I just really think that life is a giant science experiment. So if that's true, then you can just say, "Hey, y'all, for Q3, we're going to try this. And at the end of Q3, we'll ask you how that went, and we'll either keep doing it, or we'll totally change it, or we'll increment it."

+ +

Software people are really good at this because they know that not everything has to go from 2.0 to 3.0. You could go 2.1, 2.2, 2.3. There are incremental builders. So if you can leverage that metaphor even culturally or socially with the makeup of the team and the way you run things, I don't know; I kind of think that's the best you got.

+ +

CHAD: Yeah. And I think we generally have the idea that we trust people and that we can provide the information. And people will generally use that information to make good decisions that are oriented towards fulfillment. So a really good example when it comes to managers is in an environment where if you're meeting in person with someone, one team member and you're their manager, and you're not meeting in person with another, that could influence negatively the other person's path to promotion or the relationship they have with you and just subtly bias you towards the person that you might be able to meet in person with. And so as a manager, making sure people know that, that that is a thing that can happen is a good way to manage that bias because I think generally, people don't want to let that happen, but they might not even realize it, so they can actively manage it.

+ +

JEN: Well, it sounds like even in that thought, you are gently nudging people back towards intention and back towards just not sleepwalking through their work, that this is important for us, not only in the distance conversation here but also obviously for race, and for gender and for all kinds of different ways that humans are. We will never get it 100% right and yet intention, and taking a beat, and taking a breath before you move into conversations about promotions or whatever will help remind you hang on a second, remember there's invisible stuff inevitably going on based on who I am and where I came from. How do I make sure things are fair today? Or whatever the reminder needs to be. It sounds like that's...I don't know. It's good that you have that front of mind.

+ +

CHAD: So that's one example of remote management. How much of before the pandemic were people who were coming and attending the workshops? Were they managing people remotely? And how much of your curriculum was specific to that, if any?

+ +

JEN: My gut says maybe about a third were remote managers. They are definitely with bigger companies that I was seeing that. The small agencies based in Pittsburgh, you know, Austin, those places were pretty localized. But so what you get with a bigger company is also a bit more infrastructure that supports some of these cultural conversations.

+ +

And we had it as part of the curriculum, but it wasn't very big, and maybe I would sort of be intentional. There are breakout groups and stuff like that. And I might think I'm going to pair these two together for their practice one-on-one because I know they're both remote managers. I am very intentional about a lot of the pairings and all that stuff, and so I would be thoughtful in that way. But now, on some level, in all these virtual workshops, everybody has an equal footing now. So everybody's kind of screwed, and everybody's also making it work. So that has been a very interesting thing to see.

+ +

And I always laugh at this example, a woman who came early on, maybe like the eighth or ninth cohort, and she's a remote manager. And she would say, "Well, I don't have a water cooler. I don't have, like, I'm walking down the hall sensing somebody’s upset or anything." But she would say, "This is going to sound weird, but I keep an eye on how fast they emoji something." So if you have a person who...You know this person in Slack. They're always on Slack, always so supportive, funny, have something to say, a little thumbs-up emoji, or whatever. But if one day they're at work for sure and they haven't said anything about something, she would learn to read the tea leaves like that and check-in. And I just thought that was so clever and very creative.

+ +

And what she's alluding to is this level three listening that I teach, which is gut or instinct or intuition. And what she was tracking was basically a change in behavior. And that's pretty much what we're tracking when we're in the office too. There could be many reasons why somebody doesn't emoji something right away. Maybe your daughter just ran into the room. Maybe there's a doorbell. There are a million things. But at the same time, not to be too precious about it but to casually track that at least instinctively. She was doing a good job of meeting the moment as best she could.

+ +

CHAD: Are there other ways in which what you've been doing has changed over the last year? What are managers concerned about or challenged by?

+ +

JEN: Yeah. First of all, I always had name tags that allowed for pronouns. But this is now certainly part of the curriculum. When we start, I give some social norms and then some tech norms. And so I make the suggestion that in Zoom, after your name, you put your pronouns. And it's not a huge chunk because I really don't feel like I am the best to teach this, but I've added in a DEI component, diversity, equity, inclusion component. And we have some folks in the alumni community who are DEI consultants, so that's great. I always give them shout-outs and refer over if people are looking for that.

+ +

I've noticed that people are...I'll say careful, but what I mean by careful is that they are aware of all of the stuff we're talking about, like race and social stuff. Depending on where your office was in the country, the election was sometimes really hard. I think about companies in Ohio or Pennsylvania or swing states where it was not obvious that everybody in the office was on the same page about that. And the way that that stuff comes up and is like this piece of baggage in the room that prevents literally like a website being made. We want to think no, that shouldn't enter. That's not relevant here.

+ +

And yet people are careful about both trying to say, "Listen, bring who you are. You're accepted here." And also like, well, sometimes what you're suggesting you believe about the world is harmful. The whole Basecamp thing is a good example of that. And so I found the managers who come to my training to just be open to not only sharing their experiences with that but looking very much for some guidance on that from their peers and then from me.

+ +

CHAD: That's sort of what I was saying about people felt like you needed to be changing the way that you were approaching things. It wasn't okay anymore for most people to say, "We shouldn't be having this conversation. It's not a work-related conversation." It affects people's work and their ability to work. It is a work issue. And you can't simply put everything aside. That's one angle of it, but we're not all equipped. We're not all educated. We're not all ready to be able to do that as managers.

+ +

JEN: Totally. But with the amount of shit that we have had to handle for the last two years, short of somebody who's a social worker/priest, I don't know who was ready. I feel like a lot of what we're talking about is so resonant for me because all of this is so hard. And if you are alone doing hard things, it's impossible. But the reason that I run the manager trainings the way I do and the reason that I hold onto them after and I put them in a Slack community, they're now alumni of the program. And it's active; it depends on the day. But people have hard questions that they're wrestling with. People have jobs that they're promoting, that they're trying to get people to apply to. It's this active community that goes on afterwards.

+ +

Because, honestly, Chad, I feel like a big input into me creating So You're Now a Manager and the community around it was my experience becoming a parent. I was one of the first ones of all my friends. I was the first one of my siblings, and my son was the first grandchild on both sides. And I was like, this is so lonely. All my friends are going out in Brooklyn for dinner. And I was 31. It's not like I was very young or anything, but that's New York. And so I had a moms’ group. And man, that moms’ group got me through those early days because we could all laugh at how hard it was. We could cry together.

+ +

And when I looked at the transition that people go through from IC, individual contributor, to manager or some level of leadership, you get responsibility. You have to play the messenger sometimes, something you're not totally down with. You have sometimes competition with peers. You have to manage up sometimes. And then you have these people who come to you with requests: I want a new career path. I want more money. I want a different title. And the slog of that is very reminiscent, on some level, of parenting to me.

+ +

So I thought, well, this is not going to be like, here's your book. Good luck being a manager, although books could be helpful. For me, it seemed like there was at least a certain template of a person in the world who could use community too. So I always say you'll be with me for two days or a month if it's virtual. But I can't possibly teach you everything you'll encounter. That said, we can get some critical skills under your belt. And then you can just continue to riff with this peer network. And that has been a very, I would say, unique thing about the manager training I run and something that is so fulfilling to me. I have a very tiny business. Those are, in weird ways, kind of my colleagues, the funny jokes they tell or those personalities. That was another thing that we had to let go of. In 2020, I was going to have the first reunion.

+ +

CHAD: Oh yeah. We actually talked about that in the previous episode as an idea.

+ +

JEN: Heartbreaking. Yeah, it was called Encore. Basically, it was a follow-up and open to anybody that has already taken SNYAM, So Now You're a Manager. I had people who pitched talks, and we had selected them. And yeah, we had to pull the plug on that. So my hope is that next year we can do that. And now we've got almost...actually; I think we just hit 300 people, so maybe 50 will come, I don't know. We'll see. But I like the idea of providing a space for these folks who were new managers when I knew them and when they came through me but have gained some skills themselves and could become thought leaders in this management space. And whenever the world is ready for it, I'm excited to put that together.

+ +

CHAD: Yeah, that's awesome. That sense of community is one thing I've struggled with, to be honest. Because having done this for 18 years, there aren't many people who worked at the company that work there now anymore. [chuckles] We've grown too. So I no longer have the close personal relationship that I had with most people at the company before or close work relationships. And combined with as we've grown, it's harder...you have to be more of a leader. You have to put yourself aside. It's harder to always be a servant to others. And then I found that especially difficult last year. And it's part of why I needed to not be CEO anymore and to transition to the COO role. Because I couldn't be in a position where everyone was always looking to me continually to make...and as distributed as we are, one of our values is self-management. But continually always looking to me to be the one who always has an answer, who is the stable one, I needed a break from that. So it's been nice, the transition.

+ +

JEN: I was going to say is it better?

+ +

CHAD: [chuckles] So it's a little bit different than I expected. So what happened was we made that change. We made other changes, and that was all going well. And then, in February, the largest vaccine scheduling provider in the United States came to us and needed help scaling the infrastructure and all that stuff.

+ +

JEN: Oh my God. That's exciting.

+ +

CHAD: And so I, along with a crack team of other experienced thoughtboters, went and spent all of our time focused on that. It has pros and cons, which is right as I was transitioning into a new role; I completely got pulled away and started working full-time with that client for a very important cause, which is the reason why we did it and decided it was worth it. The silver lining is it put everyone else in a position where we went very quickly from Chad's no longer the CEO to Chad's not here right now. [chuckles] And that was unexpected. But I think that it had downsides, but it had upsides too in terms of really being in a position where people could come into their own, into their new roles and sort of a forcing function for some of the changes that we needed to make.

+ +

JEN: You know, I'll give you major props on that, Chad. Because 18 years and especially, I think this about a lot of things, but especially business here, people get stuck. They really do. They get stuck, especially founders, CEOs. They don't know how to get out of something if they're tired. And there are not a lot of models for what that could look like. The biggest disservice someone could make to leading a company would be to not really be feeling it because that shit trickles down. And if you're tired or if it's not your thing anymore, really, the biggest gift you can give is to go get aligned somewhere else and then hand over the reins to what I keep thinking of as the next generation.

+ +

I coach a lot of people, or I work with a lot of people who are in the middle, let's say, so they're not C-suite, and they're not newest managers, but they're sort of senior there. They're totally ready to go. I can't overstate that. [chuckles] Will they mess stuff up? Sure. So did you. Will they have questions? Absolutely. But the next generation of every company it's the most strategic thing that a CEO could do is to think, what happens if I'm not here? That allows you to take a freaking vacation, like take a month off. Or that allows you to meet such a huge civic call, which you're describing here, and step away. Or again, God forbid something happened, and you get very sick; it allows the company to be bigger than yourself.

+ +

So I just commend you on even having the courage to step towards COO and then obviously also kind of redirect as needed this year. But I hope that if there are other CEOs listening or folks in the C-suite who are wiped, this is my gentle nudge to them to hand over the reins at some point. Because you'll get a paycheck, I’m sure you can figure that.

+ +

CHAD: [chuckles] Being wiped was one small part of it. And I had Diana on who's the new CEO, and we talked about this. We had grown to a certain point. Also, to toot my own horn, I had done a really good job of building a team of managing directors who were really good at what they were doing. And I was no longer the best manager for them. I was no longer what they needed in order to continue to grow. I could do it, but I wasn't the best person for it. So that was the overriding reason to make the change, and being tired and needing to not always be the one that everyone was looking to was certainly a part of it. But yeah, it's been good.

+ +

JEN: Yeah. I figured we would get there at some point, but we talked a little bit earlier about how I have this new product coming out in September. So the product is called Manager Weeklies, and it's basically...I got to figure out the exact noun for this. I guess this is the marketing moment. [chuckles] But it's basically a small notebook. The way I think of it is it helps you take a deep breath before your week starts. And so I'm not messing with your to-do lists. Everybody has different versions of that, Trello or wherever the heck you keep it. But before you start the week, it is so important to wonder where's my energy at? What's my perspective? What are the couple of priorities? What am I blocking? Just a couple of invitation questions there.

+ +

And then the idea is that you then can do this on whatever, a Sunday night or Monday morning. And then the rest of the week has, I feel like I've said intention 50 times in this conversation but has intention in it. You can decline those three meetings because they're not the highest priority. You can make some space to actually do the work that comes out of the meetings that you're in. And what I have watched over the last maybe three years are my coaching clients who get themselves together at the beginning of the week who have some sort of practice about setting things up in a good way are the most successful. They get the promotions because they look like they know what they're doing because they do.

+ +

So anyway, it's called Manager Weeklies. So it's a small notebook. Each notebook is for a quarter. And then, because I'm a coach, I also filled it with other good stuff. Like at the end, there are all kinds of prompts for ways to give praise to people on your team, ways to give feedback, ways to handle conflict, ways to say, "Yes, no, maybe." And then there's a Work Wheel tool at the very end.

+ +

And so my hope is that people who just feel like they show up on a Monday already behind that they would find some help with that intention. And I feel like what you're saying is that self-awareness component that came through for you, Chad, to say, I'm not the best at this, and also, I'm a little fatigued and so, therefore, deep breath. Here's the strategy going forward. It wasn't reactive, but there was some thought behind it. And so we'll see this fall people get a chance to try that out.

+ +

CHAD: That's awesome. I feel like it's getting back to your roots but also building on it. So for people who don't know, the Plucky Cards were actually the first way that I was introduced to you was someone showing me a pack of those cards. So, where can people find out more about that?

+ +

JEN: The best way for people to find any information is just to subscribe to the newsletter. I send it once a month. It's usually a reflection on work, life, something going on there. So if you go to beplucky.com/newsletter, then you'll be first in the know. What's very funny, Chad, is I have a former coaching client who holds the record now. He was the first one to buy the first pack of cards. He was the first one to buy the second pack of cards. [laughs] And he was also the first one to do this Small Group ticket that I recently did as a little offshoot of Plucky. So anyway, in my mind, I always laugh, and I wonder, I wonder if he's going to grab the first pack of Manager Weeklies this fall.

+ +

But you're right. They certainly plug and play with the cards very well where there's even space in the weekly template to say, what's the one-on-one topic for the week? So it could be a card that you pull, and you use, or it could just be something else going on in the world that you want to bring to all the one-on-ones. But I feel like there are a lot of things I'm not great at in the world, but the things I am good at are people. And then I listen to people over and over again through all of these experiences. And I try to hear what else do they need? What weird little thing can I invent that could help them with some of these things that they struggle with?

+ +

And I'm also just really mindful of the fact that not everybody has the budget for coaching or for manager training. And I would love for Plucky to be a brand that even if you work for a nonprofit or if you don't have the money to pay for some of those more expensive things that you would have 35 bucks for a pack of cards or 20 bucks or whatever the pricing will be for the notebooks and that you can engage with my brand, even if you're not very wealthy. And I feel like as a person who works and serves an industry like tech, that is always really a priority for me to not only coach or work with the people with the most money.

+ +

CHAD: Yeah. If I remember right, you designed the cards, right?

+ +

JEN: Oh my God, I wish. No.

+ +

CHAD: Oh, okay.

+ +

JEN: For the first pack of cards I worked with, I don't know if you know him, Greg Storey.

+ +

CHAD: Yeah.

+ +

JEN: He's great. Greg Storey did my first deck of cards, and then he moved on, and he's doing other interesting things with his career. So I have a designer who helped me with the second deck of cards called the Manager Pack. So that's questions for managers of managers to bring to one-on-ones, and then the Manager Weeklies are coming out. I've been collaborating with a woman who runs a design little shop called YupGup in Delaware. So her name is Joni. So it is so wild, Chad. I wish that I had any design sense. But it's like, I make these things which look like a terrible PowerPoint. I'm like, here, then there will be a bullet. And then I give it to a designer like Joni at YupGup, and all of a sudden, she has a logo. And then she has some emojis and colors. And I'm like, this is how I felt when I was pregnant, and someone showed me a sonogram, and I was like, (gasps) there's a baby in there.

+ +

CHAD: [laughs]

+ +

JEN: This is how I felt when she showed me them, and it was so exciting. And I will never be good enough to even be talented at all to make these things myself. But I hold the idea, and then I find someone who wants to help me make that in the world. It's just magical. That is so fun for me. And so I just ordered them. Actually, I ordered 1,000 of them about three hours ago. And so they'll come in August, and I just know it will be very surreal when I open the box and look at them and think about how many people in the world and pens in the world will be used to set intention, to set up people's weeks and hopefully, make a softer and more fair and thoughtful place to work.

+ +

CHAD: And one of the things I love about your business and products is that you know you're having an impact beyond that 1,000 notebooks that you put out in the world because each of those people manages 3, 4, 6, 7 people. And if you can make work better for those people, then you have a 7,000-person impact.

+ +

JEN: Yeah. And it's funny you say that because I think that recently...I keep saying I'm about to go away for a month or just be out of work for a month as a break after this whole COVID time. Since starting Plucky eight years ago, I didn't really have a model. I am not a traditional business. And even though many people kept saying, "When are you going to hire? When are you going to build the team? When are you going to do all of that?" That is not the shape of Plucky medium-term or long-term. I'm not going to be a coach factory. I certainly could, but then I'd end up super burned out and not liking my job. And then I'd have a sad company, and it would be bad. So I don't want to do that.

+ +

CHAD: And that's literally the opposite of Plucky.

+ +

JEN: Right. I mean, in the name, right? So, where I have landed as a model is to look at what artists do. And you would never take an artist...I really like Lisa Congdon in Portland. She's a cool, cool artist. And I've heard her speak, and I like her a lot. And what would Lisa Congdon's team look like? She sure isn't hiring other artists to do the work that she's over-signed up for. You get Lisa. And so she has a shop, and then she has partnerships where she teaches at different universities. And as I move into the ninth year here, I'm thinking a lot about what's standing between me and Plucky's shape and what an artist like Lisa Congdon has going on?

+ +

And honestly, fully transparently, I think it's that I need to own that Plucky is me. And it's so messy in marketing. Do you use the royal 'we'? We at Plucky? Who is we? And I think that there's some good growth in front of me this fall and next year to say, yeah, I'm Jen, and I run a company called Plucky. And I'm putting this stuff out in the world, and I hope to have ripple effects. And it won't be by hiring 100 people. It'll be just like you described, selling things to X people, and then those people's reports, those ripples will follow down. And I'm really grateful to have found myself in this place because I love coming to work every day.

+ +

CHAD: Awesome. Well, even though you love coming to work every day, also enjoy your vacation.

+ +

JEN: Oh my God. Thank you.

+ +

CHAD: And your time off and your time to reflect.

+ +

JEN: Yes, thank you so much.

+ +

CHAD: You already mentioned the website, but again, mention that, and then are there other places that people can follow along or get in touch with you?

+ +

JEN: Yes, sure. So the newsletter, like I said, is beplucky.com/newsletter. On Twitter, you can look at @BePlucky. I'm on LinkedIn, too, obviously for Plucky. And then I have basically a behind-the-scenes account on Instagram because it was too annoying...Like, what do you take pictures of, Chad, when you're a coach? You can't take pictures of confidential conversations.

+ +

CHAD: [laughs]

+ +

JEN: So Instagram, I was like, I don't know what to do with this anymore. So anyway, I just have a behind-the-scenes one over there, which is called bepluckster because somebody else had it. So yeah, so all those ways.

+ +

And also, I just generally say that if you're a person listening to this podcast and you just wanted to say something to me or ask a question, you should always just email me. It's just hello@beplucky.com. I love just hearing from people. And I might not be able to send you a three-page essay back, but I really love just interacting. And if something moved you or made you think about something, whether that was something I said or Chad, you can always just shoot me a note and tell me what you're thinking. I am not precious about that.

+ +

CHAD: Awesome. Likewise. So you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. Thanks for joining us, Jen.

+ +

JEN: Thank you.

+ +

Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Jen Dary.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kebaT2ig + + ]]> + + Chad Pytel + Jen Dary + + + 394: Creating a Remote Culture That Thrives + https://podcast.thoughtbot.com/394 + 6c1ec31e-231d-4b8b-bbf9-9200bc35843e + Thu, 27 May 2021 05:00:00 -0400 + thoughtbot + + full + 10 + thoughtbot + Chad and Lindsey talk about how the pandemic has changed "normal" remote work and how thoughtbot has dealt with the transition from being majoritively in-person to fully remote, plus the impact it's had on both employees and clients. + 48:19 + no + + + Chad and Lindsey talk about how the pandemic has changed "normal" remote work and how thoughtbot has dealt with the transition from being majoritively in-person to fully remote, plus the impact it's had on both employees and clients. +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. +LINDSEY: And I’m your other host, Lindsey Christensen. We’re back. Chad, I've only seen you pixelated for over a year now. +CHAD: I know. +LINDSEY: Can you believe it? +CHAD: It's hard to believe. I haven't seen anybody that I work with [laughs] not pixelated for over a year now. +LINDSEY: It seems normal now. +CHAD: Yeah, it seems normal, except when you think about it, and you realize how long it's been. We're going to talk about remote work today, and I think that that's something to keep in mind, which is what we're doing now isn't normal remote work. We can make the best of it and that kind of thing, but it's obviously different than normal remote work when you can actually have a social life outside of work and meet people and get together in person to kick off new projects or to be like, “Let's have a retreat or whatever.” So right off the top, we should acknowledge that we're not in this normal period, and this isn't necessarily normal remote work. +LINDSEY: Right. Which is a good thing, I guess, or the optimist in me says remote work can be way better than it is right now because this is quarantining work. [chuckles] +CHAD: Right. So for those who don't know, thoughtbot made the decision to go remote-first work from anywhere. And we touched on it in the previous two episodes a little bit, and that's what we're going to be talking about today. And I think that that's one of the things that made us confident in the direction was that things aren't great now, but they're certainly not bad. And the majority of the team felt good about what was happening now, even given all of the downsides. It gave us the confidence to look ahead and say, “Can this be even better, and will it be okay?” And I think that's part of what gave us the confidence to move forward. +LINDSEY: I saw this interesting stat, and this was actually from a while ago, last July 2020. Gartner did a survey of company leaders, and 80% plan to allow employees to work remotely, at least part of the time after the pandemic, and 47% will allow people to work full-time from home, which is even a bigger percentage than I anticipated. But I think it speaks to the major change that everyone's seeing. We've all learned that remote work can work. I saw another stat that was, I think, no companies are reporting a reduction in productivity because of remote work, and in 27% of cases, companies feel like they're being even more productive. +CHAD: We didn't not do this before because we didn't think it would be productive on a day-to-day basis or that we didn't believe in the ability to work remotely working. There were a couple of important points that caused us to choose the direction we did; the first one being we went through a period of time where we were a hybrid remote or about half the team was remote, and the other half was working in an office in Boston. And it felt hard and mediocre and something we couldn't -- It wasn't worth the amount of effort we would need to invest in making that work well. It just didn't seem worth it. And so we made the decision to -- And I think this is the way thoughtbot works like we've got to make intentional decisions in a lot of things that we do and half measures don't really satisfy us over the long-term. And so there was this feeling back then of we either need to decide to go completely remote, or we need to all be in person. And because we work locally with clients, that pushed us in the direction of well, we really like working with local clients face-to-face. We like how that feels, and it feels like something that's going to be enjoyable and fulfilling, and sustainable over the long term. So let's commit to that. And I think that that's one of the reasons why we've been successful in this transition is because, at the same time, we no longer had the client constraints of clients asking us to be in person with them or wanting to work with them in person, that was just completely off the table. +LINDSEY: That's interesting. I think I hadn't really fully thought about that element which was need or perceived need from the client to be side-by-side with us. +CHAD: Yeah. Once that was off the table, it allowed us to be freed up to make an independent decision, probably more confident in that decision because going through a period where we could show clients that it could work, I'm more confident now that when clients can be in person again, that they will be more open to working with us remotely. And I'm sure some portion of them won't be, but we'll find other clients in that time period. [laughter] +LINDSEY: I think another thing that helped us in that transition was we weren't fully remote, but we were remote in a lot of regards. So we had six different studios around the world who collaborated together, worked on the same projects and the same teams. And we had a really good starting point for how we collaborated online, whether that's in actual video meetings or doing asynchronous work or project management all the way through to client work. Not everyone was in the city of the client that they were collaborating with. +CHAD: Yeah. And all of the corporate team, the operations, marketing, all that stuff was already really a distributed team. It was primarily the design and development that fell back on being in person the most often. +LINDSEY: And I would say we also had a pretty flexible work from home policy too. So if folks felt like they were going to be more productive from home a certain day or were having a delivery or whatever those life things are, we trust that they know what's best for them and best for the client and allow folks to make decisions about where they're working. +CHAD: The way that we worded it before was that temporary remote working was always okay. And that could be I'm going somewhere for two months; even that was okay. And the opposite of that is what we said wasn't okay, which wasn’t permanently remote. And the big difference now is that we said permanently remote is okay. And walking back through the transition, this was something that has been an ongoing conversation at thoughtbot for a while. It was pretty early on in the pandemic that we said that people needed to start to move out of the places that we had studios. And I think that that was the first important step that we took as a company to make sure that we were supporting everybody in what they needed to do for life reasons saying, “If you need to move outside of a place where you would normally be based, do it. We'll continue to support that.” And then about 20 people, [laughs] a little less than 100 moved over the course of the next six months or so. And once that happened, that's a pretty significant portion of the team no longer being based where we have offices, and that sort of sealed the deal. +LINDSEY: I didn't know that number. +CHAD: I think it's less than 20. I think it's like 17 or something like that. +LINDSEY: So it probably works out to about 20% moved to where there weren't offices. And do you have an idea how far spread out everyone is now? +CHAD: I think most people who moved significantly moved to be closer to family or back where they were originally from. I think that was the driving factor. So it's places like Texas, different parts of Texas, Arizona, that kind of thing. And then people bought houses to get out of the city and that kind of thing as well, particularly New York City was -- I think a lot of the people in New York City are the ones who moved as well. +LINDSEY: So, how would you describe our remote structure now? +CHAD: I think there are a couple of important things like, we're specifically calling it work from anywhere, not work from home. Obviously, we all need to be in our homes now, but long-term, there's no reason why if the home isn't comfortable for somebody that they will work somewhere else, and anywhere also means geography. And we're not even completely shutting the door on eventually having small co-working spaces or small offices where people can get together and work in person. It's just not what we have right now and not what we're specifically planning on in the short term. So I think that's the base level when I think about the important parts of the structure is what are we actually saying, or what are we actually doing? +And then the next important aspect we took into account was okay; one of the things that influenced the way that we were working before, which was a local team working with primarily other people in your office was it's pretty annoying, and it does affect productivity to be waiting significantly across time zones for people that you're supposed to be collaborating with. And so we ended up splitting the company by time zone into what we’re calling Launch Pad 1 and Launch Pad 2. And Launch Pad 1 is all of the Americas, and Launch Pad 2 two is Europe, Middle East, and Africa. It's interesting because that's actually only about three maybe four times zones different at the extremes. All of the Americas, when you do it out, it's a lot of time zones. It's ten timezones, but the reality is we don't have anybody in Hawaii or Alaska yet, so we're okay with that.[chuckles] But it's something that may need to be revisited in the future if we really start to hire people remotely in those extremes of the time zone. +LINDSEY: So the geographies are really time zone-based, which is an interesting note. And then I'm sure some folks are also interested in logistics, especially now that you're heading up operations. What does that mean, or what are the big hurdles when you do have people spread across countries, let alone states? +CHAD: So let's break it down in terms of employment stuff, and then we'll talk about operations like how we run things. We're not leading the charge in this. Other companies have done it before. And so we're taking a lot of cues from companies like GitLab and Buffer about how they do things. We've had international employees for a little while off, and on or international team members, I should say. And what we've historically leaned on for that is having them as independent contractors. And it's pretty common for them to create their own company that they're then using, and they're working within, and they're paying local taxes, and they're invoicing us for the time. And in a lot of countries, their laws are conducive to that. But strictly speaking, it's not okay to do that in every country. And if you were to get audited and someone were to look at the relationship you have with that person and their laws are similar to the U.S., they might declare that person an employee, and you're responsible for the taxes and everything, not them. +Operating at the size we are, to be perfectly honest, at the size, we are with a handful of people, it’s a gray area. Like, some places it's okay, some places it's not quite okay, but it's only a handful of people and everything. You can get away with that without doing a lot of research into each specific country, whether it's okay or not, particularly if you make it the responsibility of the people, and you set up contractor agreements, and you set things up that way. So that's a pretty common way of operating. But as you start to grow and formalize it more and the numbers of people that you're working with as international contractors increases, the pressure is going to mount to say, “We have to get out of this gray area; otherwise, some country or someone could get in trouble,” not even us, but potentially the team member. If they were to get audited and it's not quite up to snuff, they could be held for some employment taxes or something like that. So we want to avoid that. We don't want to create a burden on people. And so there's really two ways of going about it; one is to create local entities in each of the countries where you want to hire somebody. So you create your own local company. That company employs them and pays the local taxes and employment taxes, and all that stuff and everything is fully set up and official, and we've done that before. We did that in Sweden when we had the studio in Stockholm, and that's how we work in the UK. +The overhead of doing that is really high, especially --It’s okay when we were in Sweden and the UK and the U.S. But as we look ahead and we say, “We're going to have ten then maybe 20 in different countries,” the overhead of that is really high. So the alternative is to work with a company that does that for you. So there are companies they're called PEOs professional employment organizations or international PEOs. And what they do is they create companies in all of the countries that they want to operate in, and then they employ the people as real full employees there. And they do all the books, and they pay all the taxes and everything. And they make sure that everything is done correctly for each individual country. And then they invoice you for the employee's salary, the taxes, and then an administration fee. And it's typically on the order of $250 to $600 a month per person. And so that's the direction we're going to go in as we expand this and we do it. That's the direction we'll go in because we've been through what it's like to create that overhead of the individual entities in each country. +And it might make sense if we were saying we're going to open an office or hire significantly in this one country and build a whole team of 20 people in one country, but that's not what we were planning on doing. We may only have one or two people in each of the countries that we end up hiring someone in. So it doesn't make sense to have that overhead. And there are a few different companies out there, and not to plug them, we're not using them yet, but the interesting one that's on my radar is remote.com which was started by the person at GitLab that did this all for them and learned a ton about it and then left GitLab and started remote.com as a way to make that more accessible and modern for other companies. A lot of the other companies that do this tend to be very large, and they've been around for a long time, which typically means things aren't really done online so much; it's a lot of paper. And remote.com it's a website you sign up for. You could just enter the people in, and things happen automatically. And so that's why that's on my radar. +LINDSEY: They're probably getting a lot of business these days. +CHAD: Yes. And they have a lot of countries that they're expanding to over the next year or so. +LINDSEY: How many countries do we have people in now? +CHAD: That's a good question. I don't know [laughs] United States, UK, and Uruguay right now. I think those are the only ones. But we have two people who are moving, one to Canada, one to Austria. So those are the next two that are on the horizon. And we're actively hiring, so we just opened a bunch of positions. And I know that a lot of people applying to those positions are from places like Brazil, other places in South and Latin America, and potentially Canada as well. +LINDSEY: Cool. Oh, we also got some great audience questions for this episode, so thanks to everyone who submitted. One of the questions was, when will you start hiring Canadians? +CHAD: We're doing it now. [chuckles] All the positions on thoughtbot are at thoughtbot.com/jobs. They're all listed as remotely. They're segmented by Americas versus Launch Pad 2, which is Europe, Middle East, and Africa. +LINDSEY: So, continuing on the hiring conversation, obviously, the hiring process itself has to be modified for the remote life. I'm not personally currently hiring, but I see the activity. And I think it seems like right now we've got a good handle on it but are also in the process of figuring out what works best and how to optimize it. Because we were on a hiring freeze for a while, and now it's opening back up, and we're trying to figure out how -- Honestly, it seems like the biggest question is how do we replicate that in-office cultural experience, social experience in the online format? +CHAD: Yeah. Up until the office visit portion, the majority of our hiring process was already remote. So the non-technical interview was primarily done remotely. The technical interview was primarily done remotely. But at the final stage of that process, we would bring people into the office for the full day to pair with one person in the morning for developers, pair with another person in the afternoon, have lunch with the team. For designers, it was getting a design challenge and working with the team throughout the course of the day in a conference room. And so replicating both the working together aspects and the social aspects of that office visit day is important to us, and that's where the tricky part has been. The working together part is the easier part of it, I think we found because we're all working remotely anyway. So we just replicate that; it’s pairing remotely, and it's doing the design challenge in collaboration remotely. It's the social aspects that are harder. And part of it is is we're not necessarily getting everybody together on a regular basis every day and so creating a time for everybody to come together just because we have a candidate visiting and do something that's not artificial, together, was a little bit tricky to find. +LINDSEY: Everyone act natural and social at 2:00 p.m. [chuckles] +CHAD: Right. Go. [chuckles] And then to insert someone into that mix who doesn't know anybody on the call and is interviewing, it's a high level of awkwardness for the candidate as well. So what we've found has worked best is to find something that we are doing already and piggyback on top of that. So in the case of the UK, they were already getting together where everyone shares something that they're working on. They were already doing that on a regular basis. Or someone would say, “Let's have a discussion about this,” we were already doing that. So just making sure that that gets scheduled for when there is going to be a candidate and then prepping them and asking them to prepare something to share as well. +And then, when it came time to do a different team, I encouraged them, “Don't just do what they're doing because they were already doing this. If you try to do it, and it’s something you're not doing already, it might turn out to be even more awkward. Try to find something that you're doing already and piggyback off of that.” And some teams were brand new, and they didn't have anything that they were doing already. And so that's the one thing we talked about in the last episode. But at the same time as going remote, we also, instead of being small teams based on geography, we reorganized to be based on the kinds of projects that we work on. And so Boost, for example, was an entirely new team of people that didn't necessarily have those norms and those regular events happening. And so they needed to create something that they could use not only to bring the team together but that that hiring process could piggyback on for that final stage. +I think mostly it's gone well. I think everyone knows that it's a little awkward, so I think everybody gives it the benefit of the doubt. I couldn't imagine...well, I guess I can imagine it. But I wouldn't necessarily want to arrive at a standpoint where we start hiring people without the opportunity for the whole team that they're going to be working with to get to know them a little bit but also to provide their feedback but also for the candidate. When you join a new company, you want to know what it's like to work there. You want to know that you want to work with the people. You want to flush out any red flags. And I don't think we have any red flags. And so I'd rather that be out there and that kind of thing so that people can experience as much as possible what it's really going to be like to work at thoughtbot and who you're going to be working with. +LINDSEY: So we have another audience question, and you can let me know if you actually want to answer this or not. How will you handle compensation? Will it be the same for everyone across the globe or country-specific, et cetera? +CHAD: I can totally answer this. +LINDSEY: You want to get into it? Let's do it. +CHAD: I realize I'm answering in long-winded ways, but I think the context is important in these things. So the way things worked historically at thoughtbot was based on your geography, but that made sense because the clients were based on geography, and each of the locations was working with local clients. And so, the economy of the different studios was entirely different from one another. So the studio in Raleigh-Durham worked with clients there primarily, and that is very different than Manhattan, New York, and what people understand a local team costs and what they're willing to pay and that kind of thing. And so there was a natural one-to-one correlation between the studio you worked in and the economics of how the business of that studio worked. And so the salaries and the economics of the whole expenses of the studio were based on that local thing. And so that's the way it worked previously. And then we would always do reviews within that group of people to make sure that there was fairness in pay from an equity perspective between people with the same level of experience and not for other factors like gender or anything like that, so equity in pay is really important to us. And so every compensation thing goes through that review process. And then we do an annual salary review every year where we re-review everything for equity, and we review an increase for economics and performance, and that happens in April. So when we went remote, we didn't change anything. And historically, what would have happened if you lived in one place and you moved to another studio with different economics? Your salary might change because you needed to be sustainable within that studio. And you would find that out in advance, and it would factor into whether you want to do it or not. +So when we went remote, and people started moving, what we did was we reminded people that traditionally, that might have an impact, but you're not moving to where a new studio is. We don't know how things are going to be in the future, just that we'll do the salary review in April. So coming up to the salary review, we started looking at the way that we were going to do it. We went through a little bit of a change when we originally started the process; like I said, we're taking cues from other people, and one of those companies is GitLab. And what GitLab talks about is cost of market. And so that's what we had planned on doing so rather than paying people cost of living, cost of market is the idea of what would your competitive salary be based on where you live? And that includes both remote and local employers, what you can command, but it doesn't necessarily mean that it's the same everywhere based on where you live. And so that was the direction we started to go down. It's not where we ultimately ended up. Ultimately, we ended up creating within the United States, based on the position you have, a salary range, and that is the same salary range across the whole United States with a couple of exceptions, and I’ll mention what that is. So if you're a developer, or if you're a senior developer, or you're a team lead across the whole United States, you'll fall within this range based on your performance, and I'm happy with that. We were never philosophically opposed to doing that. And I'm pretty cool with the fact that we got there in the course of doing the review. +So the exception to that is we financially couldn't set the level of that salary at a city like San Francisco or New York. If we were bringing everybody up to that level at the company, it would be very difficult for us to be profitable. And so we set the tiers based on the next tier down of cities in the U.S., so it's cities like Boston and Austin are where we took the bands from. We have team members who live in San Francisco and New York, and that, strictly speaking, would have meant a salary reduction for the people who live there. And we didn't want to create hardship on people that didn't know that we were going to do that. When they decided where to live, it would create hardship on people. And so, we took a look at New York and San Francisco, and we created another tier that is based on those markets. +And then, between those two tiers, what we're looking at is, are these salaries based on the cost of living equitable? So does someone who was working at thoughtbot in New York effectively earn the same amount of money as someone on the other tier who's living anywhere else? And if you actually look at that, the interesting thing is there are more people at thoughtbot now who are at the main tier who live in even lower cost of living places. And so they're actually coming out sort of it's more favorable, which is I'd rather be in that position because I think over time, more and more people will become more and more distributed, and people will live in different places with different cost structures. Any follow-up questions or thoughts on all that? +LINDSEY: For me, I'm glad I didn't have to decide it. [laughter] It's really complicated because I see there's logic to different approaches. Nothing is an obviously bad decision. The reality is we do live in a world where economics of location vary greatly. But at the same time, what does the future of work and equity look like? +CHAD: Everything I just said was U.S.-centric. So we actually don't have a set thing that we're doing for countries outside of the U.S. We're going to evolve that based on what we learn over the next few months as we hire people. There are really two tracks or two options in front of us: the first one is to establish country rates, and the second one is to establish an outside of the U.S. tier like that is maybe the same or slightly below that other tier that we're already talking about, the main tier that everybody in the U.S. is on. And so we'll see what we learn over the course of that. The reason why we probably won't end up there is because Canada is very different than Uruguay, for example. And so establishing one rate that works everywhere -- There are two important things that are our guiding principles here; the first is people should be paid equitably and fairly for the work that they do. At thoughtbot, there's not really an ulterior motive. We don't have outside investors. We're just people who work at the company trying to create the company that works on our behalf as people who work here. That's the primary motivating factor is to be fair and to pay people as much as we can, and then the second thing is while being sustainable. So we also don't have outside investors. We don't have a huge bank role, and we have to operate profitably. We’re not a VC-backed company that doesn't need to operate profitably. And so that's the second guiding philosophy is we've got to make sure that we operate profitably. And if we create a tier, creating a tier that works to meet both of those things, pay people fairly and be sustainable, we've got to set those numbers right because it's pretty easy to hire a bunch of people in an expensive place and set the tier too high and then not be sustainable. So we'll learn over the next six months. +LINDSEY: So switching gears a little bit, we got a few questions from folks who are curious how we are actually doing the remote collaboration with clients because that's obviously something core to what we do that we're really passionate about and I think especially on the design side too. So someone's like, “How, are you doing things you used to do on whiteboards or on the walls?” The sprint comes to mind with the sticky notes all over the different walls. +CHAD: Well, I've been talking a lot. Do you want to start this one? [chuckles] +LINDSEY: Yeah. It's funny; I’ve said this before on the show, but I feel like going remote has also almost made our meetings more equitable. We had a lot of especially corporate folks in the Boston team who would sit in a room, and then we'd have a few folks from our different studios calling in remotely. And there is a disadvantage to that, not being in the room and not being able to hear every comment or the conversation after the call has ended. And I feel like this spills over to client work as well, where remote meetings can actually be even more productive and collaborative in a lot of ways. So that's one component. But as far as the actual tools that we're using, I would say right now we're using online whiteboarding, sprint-mimicking tools a lot. So Miro is definitely getting a lot of use. +CHAD: I think that's the one we're using the most. New things come along, and people experiment with them and everything, but the default at this point is Miro. +LINDSEY: They even have the sticky note feature, which for some reason, just works. It's the same thing as having a little box and writing in it, but it feels like a sticky note. So it evokes the feeling of the sprint. So we do use that a ton for brainstorming and collaboration internally and with clients. +CHAD: And there are actually some things that are obviously being in person in the room with people is really nice, especially in those early days of a product where it's a really critical portion of the time. But there are some things about being remote equitable inclusive is one. Another is when you're in person, you have limited space. And Miro whiteboard is an infinite canvas, and so you don't run out of space. And when you flex to fill your whole tool and take advantage of that, it makes it easier. And the other I would say is -- and Jaclyn and Kyle just talked about this on the last episode of Tentative, our design podcast, which if people don't know about, they should check out. And talking about how when we're in person and one person is at the whiteboard, they have a marker, and they're working on a sketch, bringing together the wireframe and the storyboard. They’re the one with the marker, and they're the one who's doing everything, and not only is that not necessarily -- They're the funnel of all the ideas, but it's a lot of work for them as well, and it's not as collaborative as it otherwise could be. But when everyone is remote, and everyone's on the live whiteboard, people can share the work in a way that is better and more efficient when it comes to those wireframes. And you can give people a task because everyone can have their own portion of the board. And you can say, “Can you do this for me?” And then two people can go off and do that on one portion of the board, and then you can drag it over when they're done, that kind of thing. And it makes the sprints more efficient. +LINDSEY: Yeah, like organizing the Post-it notes. I've seen that done a lot, asking for help. Grouping common themes together can make things move really quickly. +CHAD: We were already using Figma on the majority of our products. And for those who don't know, Figma is a collaborative design tool so think Photoshop or Sketch, a totally online version of that that's more like working on a Google Doc with people together. And now Figma has prototyping tools built in. So it's pretty powerful in a very online collaborative way to be able to create the designs and then turn them immediately into prototypes and to do that directly with clients and with other team members all in the same document. This is one of those things that is actually a little bit harder to do. If you're all in the same room with someone, you're inclined to -- I guess you could all open your computers and work in the same document together, but I feel like that doesn't happen as much instead one person's driving, so it actually makes things more productive to work that way. +LINDSEY: Yeah. Miro and Figma both have that kind of Google-ish feature of you see everyone who's in the doc, and you can actually see their cursor moving around in real-time as you're both working on it. And you can leave comments on all the kinds of collaboration features that you'd want with those kinds of things. And then on the development side, we also obviously put a lot of value on pairing on work. So I know even before Covid, we were experimenting a lot with different ways to do development pairing, whether it was in Hangouts or Slack video. And I believe we're currently using Tuple a lot for that. +CHAD: Yeah. Tuple was created by a previous host of this podcast, Ben Orenstein, thoughtbot alum. +LINDSEY: It’s how all the greats get started. +CHAD: Yeah. But unfortunately, it's Mac only. And so we do have some team members who are not on Macs; they're on Linux. So we can't totally rely 100% on Tuple. And so there are some other things we use like USE Together, and people who use Team Macs will share that way. +LINDSEY: And then I think one of the last things about remote work that is worth chatting about today is the team culture. We did have a very in-office culture, especially because folks are working on different client projects. And one of the things they love most about thoughtbot is the other thoughtboters and getting to see each other and maybe do investment projects together or going to the summit. So we had another question about this too, which is how do you foster that culture? How do you keep it going when no one's in-person anymore? +CHAD: I think this is one of the areas where we have the most iteration and learning to do because the work stuff we were already doing a lot of it. And the project stuff is easier to judge, too. So did the project work? Did we ship on time? Was the design great? It's a lot easier to get immediate feedback on whether what we're doing is working or not. And with the culture things, the ramifications of doing it badly might not manifest for months. +LINDSEY: We also need the client work to get money. +CHAD: Right. [chuckles] +LINDSEY: We need the money in order to work on the culture. [laughs] +CHAD: Right. And the fact that we've been doing this in the pandemic it's a double-edged sword. I think it gives us a little bit of leeway to say, “Things are not normal now. And so we can't do this or we can't do that, and that is just what it is. And so we're just going to have to make the best of it.” The other side of that, though, is that it's been a very difficult time for a lot of people, not only just because of the pandemic. This last year has been a really difficult year for a lot of people. And so, yes, we get a little bit of runway to figure things out because it's such a unique situation. At the same time, it's important more than ever to figure out how to support people and have things be good and fulfilling and sustainable for people and to have a culture that thrives, not necessarily just gets by. I think that is what has made this last year challenging is figuring that out. +So some specifics, we traditionally get together as an entire company once a year. So we brought that all online last year, and we combined it with our end-of-the-year parties that we usually do, which are also a hackathon where we take time off of client work, and we work on projects together. So we combined those two things in December and had a two-day all-remote event with murder mysteries hosted by professional companies to trivia and then underlying with the hackathon. And I think people really enjoyed it. It was one of those things where I think people were -- there was a pocket of people who were really skeptical about it. “I'm tired of being on video calls all day,” and all that stuff. “I'm not feeling up for it,” like all these sorts of things. And it was like, “Trust me, just show up, just do it.” And I think what we heard was pretty universal that people were surprised at how enjoyable it was. And so this year we're doing three of those, two one-day ones and one two-day one. And that'll be in May and then the summer, and then the winter. Implicit in that is we're not expecting to be able to get back in person together in any large group for all of this year. +LINDSEY: But you do anticipate in-person summit return. +CHAD: Yeah, definitely. I think it's more important than ever. And I think what we'll also see and encourage is team in-person get-togethers where it's not just the whole company, but you're on a project team or the marketing team or rocket fuel, as it likes to be called now, and get together. Yes, it's fine. Get together in this place. And that's one of the things that -- We spend a lot of money on very expensive offices in Boston and New York, and in the past, San Francisco, and Austin, London. It’s over $500,000 a year in office expenses between all those places that we still have the expense now. But once we're able to eliminate that expense, it's going to free up a lot of money to be put towards getting those teams together in person and do other things. +LINDSEY: That was the other thing I was going to say, and you noted this about the UK team is that there's also a lot of team-specific activities where team leadership for Boost, Ignite, Lift Off, Mission control or with the geography-based ones too are figuring out what kind of social stuff or testing out different ideas like the show and tells or doing quiz time. I know there's a pocket of folks who jump in the lounge, which came out of the remote summit, the lounge during lunchtime or after work on Friday, and just trying out different things. +CHAD: And Stephanie, who was the office manager in New York, has moved into an operations manager role, so company-wide. And a big part of what she is doing is figuring out things to try. And I think some things will succeed and some things won't, whether it's organizing games or the thing that just happened on Friday was people opting in to be paired for a 15-minute conversation with somebody else in the company, things like that. We're trying a lot of different things and seeing what works, what doesn't online. She created an online art gallery where people who are doing art can post it, that kind of thing. So we'll learn. +LINDSEY: We'll learn, and then we'll most likely share it with you, so stay tuned for that. You can subscribe to the show and find notes for this episode at giantrobots.fm. +CHAD: If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. +LINDSEY: And me on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot. +CHAD: Thanks for listening, and see you next time. +LINDSEY: This podcast was brought to you by thoughtbot. +Thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chad and Lindsey talk about how the pandemic has changed "normal" remote work and how thoughtbot has dealt with the transition from being majoritively in-person to fully remote, plus the impact it's had on both employees and clients.

+ +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

LINDSEY: And I’m your other host, Lindsey Christensen. We’re back. Chad, I've only seen you pixelated for over a year now.

+ +

CHAD: I know.

+ +

LINDSEY: Can you believe it?

+ +

CHAD: It's hard to believe. I haven't seen anybody that I work with [laughs] not pixelated for over a year now.

+ +

LINDSEY: It seems normal now.

+ +

CHAD: Yeah, it seems normal, except when you think about it, and you realize how long it's been. We're going to talk about remote work today, and I think that that's something to keep in mind, which is what we're doing now isn't normal remote work. We can make the best of it and that kind of thing, but it's obviously different than normal remote work when you can actually have a social life outside of work and meet people and get together in person to kick off new projects or to be like, “Let's have a retreat or whatever.” So right off the top, we should acknowledge that we're not in this normal period, and this isn't necessarily normal remote work.

+ +

LINDSEY: Right. Which is a good thing, I guess, or the optimist in me says remote work can be way better than it is right now because this is quarantining work. [chuckles]

+ +

CHAD: Right. So for those who don't know, thoughtbot made the decision to go remote-first work from anywhere. And we touched on it in the previous two episodes a little bit, and that's what we're going to be talking about today. And I think that that's one of the things that made us confident in the direction was that things aren't great now, but they're certainly not bad. And the majority of the team felt good about what was happening now, even given all of the downsides. It gave us the confidence to look ahead and say, “Can this be even better, and will it be okay?” And I think that's part of what gave us the confidence to move forward.

+ +

LINDSEY: I saw this interesting stat, and this was actually from a while ago, last July 2020. Gartner did a survey of company leaders, and 80% plan to allow employees to work remotely, at least part of the time after the pandemic, and 47% will allow people to work full-time from home, which is even a bigger percentage than I anticipated. But I think it speaks to the major change that everyone's seeing. We've all learned that remote work can work. I saw another stat that was, I think, no companies are reporting a reduction in productivity because of remote work, and in 27% of cases, companies feel like they're being even more productive.

+ +

CHAD: We didn't not do this before because we didn't think it would be productive on a day-to-day basis or that we didn't believe in the ability to work remotely working. There were a couple of important points that caused us to choose the direction we did; the first one being we went through a period of time where we were a hybrid remote or about half the team was remote, and the other half was working in an office in Boston. And it felt hard and mediocre and something we couldn't -- It wasn't worth the amount of effort we would need to invest in making that work well. It just didn't seem worth it. And so we made the decision to -- And I think this is the way thoughtbot works like we've got to make intentional decisions in a lot of things that we do and half measures don't really satisfy us over the long-term. And so there was this feeling back then of we either need to decide to go completely remote, or we need to all be in person. And because we work locally with clients, that pushed us in the direction of well, we really like working with local clients face-to-face. We like how that feels, and it feels like something that's going to be enjoyable and fulfilling, and sustainable over the long term. So let's commit to that. And I think that that's one of the reasons why we've been successful in this transition is because, at the same time, we no longer had the client constraints of clients asking us to be in person with them or wanting to work with them in person, that was just completely off the table.

+ +

LINDSEY: That's interesting. I think I hadn't really fully thought about that element which was need or perceived need from the client to be side-by-side with us.

+ +

CHAD: Yeah. Once that was off the table, it allowed us to be freed up to make an independent decision, probably more confident in that decision because going through a period where we could show clients that it could work, I'm more confident now that when clients can be in person again, that they will be more open to working with us remotely. And I'm sure some portion of them won't be, but we'll find other clients in that time period. [laughter]

+ +

LINDSEY: I think another thing that helped us in that transition was we weren't fully remote, but we were remote in a lot of regards. So we had six different studios around the world who collaborated together, worked on the same projects and the same teams. And we had a really good starting point for how we collaborated online, whether that's in actual video meetings or doing asynchronous work or project management all the way through to client work. Not everyone was in the city of the client that they were collaborating with.

+ +

CHAD: Yeah. And all of the corporate team, the operations, marketing, all that stuff was already really a distributed team. It was primarily the design and development that fell back on being in person the most often.

+ +

LINDSEY: And I would say we also had a pretty flexible work from home policy too. So if folks felt like they were going to be more productive from home a certain day or were having a delivery or whatever those life things are, we trust that they know what's best for them and best for the client and allow folks to make decisions about where they're working.

+ +

CHAD: The way that we worded it before was that temporary remote working was always okay. And that could be I'm going somewhere for two months; even that was okay. And the opposite of that is what we said wasn't okay, which wasn’t permanently remote. And the big difference now is that we said permanently remote is okay. And walking back through the transition, this was something that has been an ongoing conversation at thoughtbot for a while. It was pretty early on in the pandemic that we said that people needed to start to move out of the places that we had studios. And I think that that was the first important step that we took as a company to make sure that we were supporting everybody in what they needed to do for life reasons saying, “If you need to move outside of a place where you would normally be based, do it. We'll continue to support that.” And then about 20 people, [laughs] a little less than 100 moved over the course of the next six months or so. And once that happened, that's a pretty significant portion of the team no longer being based where we have offices, and that sort of sealed the deal.

+ +

LINDSEY: I didn't know that number.

+ +

CHAD: I think it's less than 20. I think it's like 17 or something like that.

+ +

LINDSEY: So it probably works out to about 20% moved to where there weren't offices. And do you have an idea how far spread out everyone is now?

+ +

CHAD: I think most people who moved significantly moved to be closer to family or back where they were originally from. I think that was the driving factor. So it's places like Texas, different parts of Texas, Arizona, that kind of thing. And then people bought houses to get out of the city and that kind of thing as well, particularly New York City was -- I think a lot of the people in New York City are the ones who moved as well.

+ +

LINDSEY: So, how would you describe our remote structure now?

+ +

CHAD: I think there are a couple of important things like, we're specifically calling it work from anywhere, not work from home. Obviously, we all need to be in our homes now, but long-term, there's no reason why if the home isn't comfortable for somebody that they will work somewhere else, and anywhere also means geography. And we're not even completely shutting the door on eventually having small co-working spaces or small offices where people can get together and work in person. It's just not what we have right now and not what we're specifically planning on in the short term. So I think that's the base level when I think about the important parts of the structure is what are we actually saying, or what are we actually doing?

+ +

And then the next important aspect we took into account was okay; one of the things that influenced the way that we were working before, which was a local team working with primarily other people in your office was it's pretty annoying, and it does affect productivity to be waiting significantly across time zones for people that you're supposed to be collaborating with. And so we ended up splitting the company by time zone into what we’re calling Launch Pad 1 and Launch Pad 2. And Launch Pad 1 is all of the Americas, and Launch Pad 2 two is Europe, Middle East, and Africa. It's interesting because that's actually only about three maybe four times zones different at the extremes. All of the Americas, when you do it out, it's a lot of time zones. It's ten timezones, but the reality is we don't have anybody in Hawaii or Alaska yet, so we're okay with that.[chuckles] But it's something that may need to be revisited in the future if we really start to hire people remotely in those extremes of the time zone.

+ +

LINDSEY: So the geographies are really time zone-based, which is an interesting note. And then I'm sure some folks are also interested in logistics, especially now that you're heading up operations. What does that mean, or what are the big hurdles when you do have people spread across countries, let alone states?

+ +

CHAD: So let's break it down in terms of employment stuff, and then we'll talk about operations like how we run things. We're not leading the charge in this. Other companies have done it before. And so we're taking a lot of cues from companies like GitLab and Buffer about how they do things. We've had international employees for a little while off, and on or international team members, I should say. And what we've historically leaned on for that is having them as independent contractors. And it's pretty common for them to create their own company that they're then using, and they're working within, and they're paying local taxes, and they're invoicing us for the time. And in a lot of countries, their laws are conducive to that. But strictly speaking, it's not okay to do that in every country. And if you were to get audited and someone were to look at the relationship you have with that person and their laws are similar to the U.S., they might declare that person an employee, and you're responsible for the taxes and everything, not them.

+ +

Operating at the size we are, to be perfectly honest, at the size, we are with a handful of people, it’s a gray area. Like, some places it's okay, some places it's not quite okay, but it's only a handful of people and everything. You can get away with that without doing a lot of research into each specific country, whether it's okay or not, particularly if you make it the responsibility of the people, and you set up contractor agreements, and you set things up that way. So that's a pretty common way of operating. But as you start to grow and formalize it more and the numbers of people that you're working with as international contractors increases, the pressure is going to mount to say, “We have to get out of this gray area; otherwise, some country or someone could get in trouble,” not even us, but potentially the team member. If they were to get audited and it's not quite up to snuff, they could be held for some employment taxes or something like that. So we want to avoid that. We don't want to create a burden on people. And so there's really two ways of going about it; one is to create local entities in each of the countries where you want to hire somebody. So you create your own local company. That company employs them and pays the local taxes and employment taxes, and all that stuff and everything is fully set up and official, and we've done that before. We did that in Sweden when we had the studio in Stockholm, and that's how we work in the UK.

+ +

The overhead of doing that is really high, especially --It’s okay when we were in Sweden and the UK and the U.S. But as we look ahead and we say, “We're going to have ten then maybe 20 in different countries,” the overhead of that is really high. So the alternative is to work with a company that does that for you. So there are companies they're called PEOs professional employment organizations or international PEOs. And what they do is they create companies in all of the countries that they want to operate in, and then they employ the people as real full employees there. And they do all the books, and they pay all the taxes and everything. And they make sure that everything is done correctly for each individual country. And then they invoice you for the employee's salary, the taxes, and then an administration fee. And it's typically on the order of $250 to $600 a month per person. And so that's the direction we're going to go in as we expand this and we do it. That's the direction we'll go in because we've been through what it's like to create that overhead of the individual entities in each country.

+ +

And it might make sense if we were saying we're going to open an office or hire significantly in this one country and build a whole team of 20 people in one country, but that's not what we were planning on doing. We may only have one or two people in each of the countries that we end up hiring someone in. So it doesn't make sense to have that overhead. And there are a few different companies out there, and not to plug them, we're not using them yet, but the interesting one that's on my radar is remote.com which was started by the person at GitLab that did this all for them and learned a ton about it and then left GitLab and started remote.com as a way to make that more accessible and modern for other companies. A lot of the other companies that do this tend to be very large, and they've been around for a long time, which typically means things aren't really done online so much; it's a lot of paper. And remote.com it's a website you sign up for. You could just enter the people in, and things happen automatically. And so that's why that's on my radar.

+ +

LINDSEY: They're probably getting a lot of business these days.

+ +

CHAD: Yes. And they have a lot of countries that they're expanding to over the next year or so.

+ +

LINDSEY: How many countries do we have people in now?

+ +

CHAD: That's a good question. I don't know [laughs] United States, UK, and Uruguay right now. I think those are the only ones. But we have two people who are moving, one to Canada, one to Austria. So those are the next two that are on the horizon. And we're actively hiring, so we just opened a bunch of positions. And I know that a lot of people applying to those positions are from places like Brazil, other places in South and Latin America, and potentially Canada as well.

+ +

LINDSEY: Cool. Oh, we also got some great audience questions for this episode, so thanks to everyone who submitted. One of the questions was, when will you start hiring Canadians?

+ +

CHAD: We're doing it now. [chuckles] All the positions on thoughtbot are at thoughtbot.com/jobs. They're all listed as remotely. They're segmented by Americas versus Launch Pad 2, which is Europe, Middle East, and Africa.

+ +

LINDSEY: So, continuing on the hiring conversation, obviously, the hiring process itself has to be modified for the remote life. I'm not personally currently hiring, but I see the activity. And I think it seems like right now we've got a good handle on it but are also in the process of figuring out what works best and how to optimize it. Because we were on a hiring freeze for a while, and now it's opening back up, and we're trying to figure out how -- Honestly, it seems like the biggest question is how do we replicate that in-office cultural experience, social experience in the online format?

+ +

CHAD: Yeah. Up until the office visit portion, the majority of our hiring process was already remote. So the non-technical interview was primarily done remotely. The technical interview was primarily done remotely. But at the final stage of that process, we would bring people into the office for the full day to pair with one person in the morning for developers, pair with another person in the afternoon, have lunch with the team. For designers, it was getting a design challenge and working with the team throughout the course of the day in a conference room. And so replicating both the working together aspects and the social aspects of that office visit day is important to us, and that's where the tricky part has been. The working together part is the easier part of it, I think we found because we're all working remotely anyway. So we just replicate that; it’s pairing remotely, and it's doing the design challenge in collaboration remotely. It's the social aspects that are harder. And part of it is is we're not necessarily getting everybody together on a regular basis every day and so creating a time for everybody to come together just because we have a candidate visiting and do something that's not artificial, together, was a little bit tricky to find.

+ +

LINDSEY: Everyone act natural and social at 2:00 p.m. [chuckles]

+ +

CHAD: Right. Go. [chuckles] And then to insert someone into that mix who doesn't know anybody on the call and is interviewing, it's a high level of awkwardness for the candidate as well. So what we've found has worked best is to find something that we are doing already and piggyback on top of that. So in the case of the UK, they were already getting together where everyone shares something that they're working on. They were already doing that on a regular basis. Or someone would say, “Let's have a discussion about this,” we were already doing that. So just making sure that that gets scheduled for when there is going to be a candidate and then prepping them and asking them to prepare something to share as well.

+ +

And then, when it came time to do a different team, I encouraged them, “Don't just do what they're doing because they were already doing this. If you try to do it, and it’s something you're not doing already, it might turn out to be even more awkward. Try to find something that you're doing already and piggyback off of that.” And some teams were brand new, and they didn't have anything that they were doing already. And so that's the one thing we talked about in the last episode. But at the same time as going remote, we also, instead of being small teams based on geography, we reorganized to be based on the kinds of projects that we work on. And so Boost, for example, was an entirely new team of people that didn't necessarily have those norms and those regular events happening. And so they needed to create something that they could use not only to bring the team together but that that hiring process could piggyback on for that final stage.

+ +

I think mostly it's gone well. I think everyone knows that it's a little awkward, so I think everybody gives it the benefit of the doubt. I couldn't imagine...well, I guess I can imagine it. But I wouldn't necessarily want to arrive at a standpoint where we start hiring people without the opportunity for the whole team that they're going to be working with to get to know them a little bit but also to provide their feedback but also for the candidate. When you join a new company, you want to know what it's like to work there. You want to know that you want to work with the people. You want to flush out any red flags. And I don't think we have any red flags. And so I'd rather that be out there and that kind of thing so that people can experience as much as possible what it's really going to be like to work at thoughtbot and who you're going to be working with.

+ +

LINDSEY: So we have another audience question, and you can let me know if you actually want to answer this or not. How will you handle compensation? Will it be the same for everyone across the globe or country-specific, et cetera?

+ +

CHAD: I can totally answer this.

+ +

LINDSEY: You want to get into it? Let's do it.

+ +

CHAD: I realize I'm answering in long-winded ways, but I think the context is important in these things. So the way things worked historically at thoughtbot was based on your geography, but that made sense because the clients were based on geography, and each of the locations was working with local clients. And so, the economy of the different studios was entirely different from one another. So the studio in Raleigh-Durham worked with clients there primarily, and that is very different than Manhattan, New York, and what people understand a local team costs and what they're willing to pay and that kind of thing. And so there was a natural one-to-one correlation between the studio you worked in and the economics of how the business of that studio worked. And so the salaries and the economics of the whole expenses of the studio were based on that local thing. And so that's the way it worked previously. And then we would always do reviews within that group of people to make sure that there was fairness in pay from an equity perspective between people with the same level of experience and not for other factors like gender or anything like that, so equity in pay is really important to us. And so every compensation thing goes through that review process. And then we do an annual salary review every year where we re-review everything for equity, and we review an increase for economics and performance, and that happens in April. So when we went remote, we didn't change anything. And historically, what would have happened if you lived in one place and you moved to another studio with different economics? Your salary might change because you needed to be sustainable within that studio. And you would find that out in advance, and it would factor into whether you want to do it or not.

+ +

So when we went remote, and people started moving, what we did was we reminded people that traditionally, that might have an impact, but you're not moving to where a new studio is. We don't know how things are going to be in the future, just that we'll do the salary review in April. So coming up to the salary review, we started looking at the way that we were going to do it. We went through a little bit of a change when we originally started the process; like I said, we're taking cues from other people, and one of those companies is GitLab. And what GitLab talks about is cost of market. And so that's what we had planned on doing so rather than paying people cost of living, cost of market is the idea of what would your competitive salary be based on where you live? And that includes both remote and local employers, what you can command, but it doesn't necessarily mean that it's the same everywhere based on where you live. And so that was the direction we started to go down. It's not where we ultimately ended up. Ultimately, we ended up creating within the United States, based on the position you have, a salary range, and that is the same salary range across the whole United States with a couple of exceptions, and I’ll mention what that is. So if you're a developer, or if you're a senior developer, or you're a team lead across the whole United States, you'll fall within this range based on your performance, and I'm happy with that. We were never philosophically opposed to doing that. And I'm pretty cool with the fact that we got there in the course of doing the review.

+ +

So the exception to that is we financially couldn't set the level of that salary at a city like San Francisco or New York. If we were bringing everybody up to that level at the company, it would be very difficult for us to be profitable. And so we set the tiers based on the next tier down of cities in the U.S., so it's cities like Boston and Austin are where we took the bands from. We have team members who live in San Francisco and New York, and that, strictly speaking, would have meant a salary reduction for the people who live there. And we didn't want to create hardship on people that didn't know that we were going to do that. When they decided where to live, it would create hardship on people. And so, we took a look at New York and San Francisco, and we created another tier that is based on those markets.

+ +

And then, between those two tiers, what we're looking at is, are these salaries based on the cost of living equitable? So does someone who was working at thoughtbot in New York effectively earn the same amount of money as someone on the other tier who's living anywhere else? And if you actually look at that, the interesting thing is there are more people at thoughtbot now who are at the main tier who live in even lower cost of living places. And so they're actually coming out sort of it's more favorable, which is I'd rather be in that position because I think over time, more and more people will become more and more distributed, and people will live in different places with different cost structures. Any follow-up questions or thoughts on all that?

+ +

LINDSEY: For me, I'm glad I didn't have to decide it. [laughter] It's really complicated because I see there's logic to different approaches. Nothing is an obviously bad decision. The reality is we do live in a world where economics of location vary greatly. But at the same time, what does the future of work and equity look like?

+ +

CHAD: Everything I just said was U.S.-centric. So we actually don't have a set thing that we're doing for countries outside of the U.S. We're going to evolve that based on what we learn over the next few months as we hire people. There are really two tracks or two options in front of us: the first one is to establish country rates, and the second one is to establish an outside of the U.S. tier like that is maybe the same or slightly below that other tier that we're already talking about, the main tier that everybody in the U.S. is on. And so we'll see what we learn over the course of that. The reason why we probably won't end up there is because Canada is very different than Uruguay, for example. And so establishing one rate that works everywhere -- There are two important things that are our guiding principles here; the first is people should be paid equitably and fairly for the work that they do. At thoughtbot, there's not really an ulterior motive. We don't have outside investors. We're just people who work at the company trying to create the company that works on our behalf as people who work here. That's the primary motivating factor is to be fair and to pay people as much as we can, and then the second thing is while being sustainable. So we also don't have outside investors. We don't have a huge bank role, and we have to operate profitably. We’re not a VC-backed company that doesn't need to operate profitably. And so that's the second guiding philosophy is we've got to make sure that we operate profitably. And if we create a tier, creating a tier that works to meet both of those things, pay people fairly and be sustainable, we've got to set those numbers right because it's pretty easy to hire a bunch of people in an expensive place and set the tier too high and then not be sustainable. So we'll learn over the next six months.

+ +

LINDSEY: So switching gears a little bit, we got a few questions from folks who are curious how we are actually doing the remote collaboration with clients because that's obviously something core to what we do that we're really passionate about and I think especially on the design side too. So someone's like, “How, are you doing things you used to do on whiteboards or on the walls?” The sprint comes to mind with the sticky notes all over the different walls.

+ +

CHAD: Well, I've been talking a lot. Do you want to start this one? [chuckles]

+ +

LINDSEY: Yeah. It's funny; I’ve said this before on the show, but I feel like going remote has also almost made our meetings more equitable. We had a lot of especially corporate folks in the Boston team who would sit in a room, and then we'd have a few folks from our different studios calling in remotely. And there is a disadvantage to that, not being in the room and not being able to hear every comment or the conversation after the call has ended. And I feel like this spills over to client work as well, where remote meetings can actually be even more productive and collaborative in a lot of ways. So that's one component. But as far as the actual tools that we're using, I would say right now we're using online whiteboarding, sprint-mimicking tools a lot. So Miro is definitely getting a lot of use.

+ +

CHAD: I think that's the one we're using the most. New things come along, and people experiment with them and everything, but the default at this point is Miro.

+ +

LINDSEY: They even have the sticky note feature, which for some reason, just works. It's the same thing as having a little box and writing in it, but it feels like a sticky note. So it evokes the feeling of the sprint. So we do use that a ton for brainstorming and collaboration internally and with clients.

+ +

CHAD: And there are actually some things that are obviously being in person in the room with people is really nice, especially in those early days of a product where it's a really critical portion of the time. But there are some things about being remote equitable inclusive is one. Another is when you're in person, you have limited space. And Miro whiteboard is an infinite canvas, and so you don't run out of space. And when you flex to fill your whole tool and take advantage of that, it makes it easier. And the other I would say is -- and Jaclyn and Kyle just talked about this on the last episode of Tentative, our design podcast, which if people don't know about, they should check out. And talking about how when we're in person and one person is at the whiteboard, they have a marker, and they're working on a sketch, bringing together the wireframe and the storyboard. They’re the one with the marker, and they're the one who's doing everything, and not only is that not necessarily -- They're the funnel of all the ideas, but it's a lot of work for them as well, and it's not as collaborative as it otherwise could be. But when everyone is remote, and everyone's on the live whiteboard, people can share the work in a way that is better and more efficient when it comes to those wireframes. And you can give people a task because everyone can have their own portion of the board. And you can say, “Can you do this for me?” And then two people can go off and do that on one portion of the board, and then you can drag it over when they're done, that kind of thing. And it makes the sprints more efficient.

+ +

LINDSEY: Yeah, like organizing the Post-it notes. I've seen that done a lot, asking for help. Grouping common themes together can make things move really quickly.

+ +

CHAD: We were already using Figma on the majority of our products. And for those who don't know, Figma is a collaborative design tool so think Photoshop or Sketch, a totally online version of that that's more like working on a Google Doc with people together. And now Figma has prototyping tools built in. So it's pretty powerful in a very online collaborative way to be able to create the designs and then turn them immediately into prototypes and to do that directly with clients and with other team members all in the same document. This is one of those things that is actually a little bit harder to do. If you're all in the same room with someone, you're inclined to -- I guess you could all open your computers and work in the same document together, but I feel like that doesn't happen as much instead one person's driving, so it actually makes things more productive to work that way.

+ +

LINDSEY: Yeah. Miro and Figma both have that kind of Google-ish feature of you see everyone who's in the doc, and you can actually see their cursor moving around in real-time as you're both working on it. And you can leave comments on all the kinds of collaboration features that you'd want with those kinds of things. And then on the development side, we also obviously put a lot of value on pairing on work. So I know even before Covid, we were experimenting a lot with different ways to do development pairing, whether it was in Hangouts or Slack video. And I believe we're currently using Tuple a lot for that.

+ +

CHAD: Yeah. Tuple was created by a previous host of this podcast, Ben Orenstein, thoughtbot alum.

+ +

LINDSEY: It’s how all the greats get started.

+ +

CHAD: Yeah. But unfortunately, it's Mac only. And so we do have some team members who are not on Macs; they're on Linux. So we can't totally rely 100% on Tuple. And so there are some other things we use like USE Together, and people who use Team Macs will share that way.

+ +

LINDSEY: And then I think one of the last things about remote work that is worth chatting about today is the team culture. We did have a very in-office culture, especially because folks are working on different client projects. And one of the things they love most about thoughtbot is the other thoughtboters and getting to see each other and maybe do investment projects together or going to the summit. So we had another question about this too, which is how do you foster that culture? How do you keep it going when no one's in-person anymore?

+ +

CHAD: I think this is one of the areas where we have the most iteration and learning to do because the work stuff we were already doing a lot of it. And the project stuff is easier to judge, too. So did the project work? Did we ship on time? Was the design great? It's a lot easier to get immediate feedback on whether what we're doing is working or not. And with the culture things, the ramifications of doing it badly might not manifest for months.

+ +

LINDSEY: We also need the client work to get money.

+ +

CHAD: Right. [chuckles]

+ +

LINDSEY: We need the money in order to work on the culture. [laughs]

+ +

CHAD: Right. And the fact that we've been doing this in the pandemic it's a double-edged sword. I think it gives us a little bit of leeway to say, “Things are not normal now. And so we can't do this or we can't do that, and that is just what it is. And so we're just going to have to make the best of it.” The other side of that, though, is that it's been a very difficult time for a lot of people, not only just because of the pandemic. This last year has been a really difficult year for a lot of people. And so, yes, we get a little bit of runway to figure things out because it's such a unique situation. At the same time, it's important more than ever to figure out how to support people and have things be good and fulfilling and sustainable for people and to have a culture that thrives, not necessarily just gets by. I think that is what has made this last year challenging is figuring that out.

+ +

So some specifics, we traditionally get together as an entire company once a year. So we brought that all online last year, and we combined it with our end-of-the-year parties that we usually do, which are also a hackathon where we take time off of client work, and we work on projects together. So we combined those two things in December and had a two-day all-remote event with murder mysteries hosted by professional companies to trivia and then underlying with the hackathon. And I think people really enjoyed it. It was one of those things where I think people were -- there was a pocket of people who were really skeptical about it. “I'm tired of being on video calls all day,” and all that stuff. “I'm not feeling up for it,” like all these sorts of things. And it was like, “Trust me, just show up, just do it.” And I think what we heard was pretty universal that people were surprised at how enjoyable it was. And so this year we're doing three of those, two one-day ones and one two-day one. And that'll be in May and then the summer, and then the winter. Implicit in that is we're not expecting to be able to get back in person together in any large group for all of this year.

+ +

LINDSEY: But you do anticipate in-person summit return.

+ +

CHAD: Yeah, definitely. I think it's more important than ever. And I think what we'll also see and encourage is team in-person get-togethers where it's not just the whole company, but you're on a project team or the marketing team or rocket fuel, as it likes to be called now, and get together. Yes, it's fine. Get together in this place. And that's one of the things that -- We spend a lot of money on very expensive offices in Boston and New York, and in the past, San Francisco, and Austin, London. It’s over $500,000 a year in office expenses between all those places that we still have the expense now. But once we're able to eliminate that expense, it's going to free up a lot of money to be put towards getting those teams together in person and do other things.

+ +

LINDSEY: That was the other thing I was going to say, and you noted this about the UK team is that there's also a lot of team-specific activities where team leadership for Boost, Ignite, Lift Off, Mission control or with the geography-based ones too are figuring out what kind of social stuff or testing out different ideas like the show and tells or doing quiz time. I know there's a pocket of folks who jump in the lounge, which came out of the remote summit, the lounge during lunchtime or after work on Friday, and just trying out different things.

+ +

CHAD: And Stephanie, who was the office manager in New York, has moved into an operations manager role, so company-wide. And a big part of what she is doing is figuring out things to try. And I think some things will succeed and some things won't, whether it's organizing games or the thing that just happened on Friday was people opting in to be paired for a 15-minute conversation with somebody else in the company, things like that. We're trying a lot of different things and seeing what works, what doesn't online. She created an online art gallery where people who are doing art can post it, that kind of thing. So we'll learn.

+ +

LINDSEY: We'll learn, and then we'll most likely share it with you, so stay tuned for that. You can subscribe to the show and find notes for this episode at giantrobots.fm.

+ +

CHAD: If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

LINDSEY: And me on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot.

+ +

CHAD: Thanks for listening, and see you next time.

+ +

LINDSEY: This podcast was brought to you by thoughtbot.

+ +

Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk about how the pandemic has changed "normal" remote work and how thoughtbot has dealt with the transition from being majoritively in-person to fully remote, plus the impact it's had on both employees and clients.

+ +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

LINDSEY: And I’m your other host, Lindsey Christensen. We’re back. Chad, I've only seen you pixelated for over a year now.

+ +

CHAD: I know.

+ +

LINDSEY: Can you believe it?

+ +

CHAD: It's hard to believe. I haven't seen anybody that I work with [laughs] not pixelated for over a year now.

+ +

LINDSEY: It seems normal now.

+ +

CHAD: Yeah, it seems normal, except when you think about it, and you realize how long it's been. We're going to talk about remote work today, and I think that that's something to keep in mind, which is what we're doing now isn't normal remote work. We can make the best of it and that kind of thing, but it's obviously different than normal remote work when you can actually have a social life outside of work and meet people and get together in person to kick off new projects or to be like, “Let's have a retreat or whatever.” So right off the top, we should acknowledge that we're not in this normal period, and this isn't necessarily normal remote work.

+ +

LINDSEY: Right. Which is a good thing, I guess, or the optimist in me says remote work can be way better than it is right now because this is quarantining work. [chuckles]

+ +

CHAD: Right. So for those who don't know, thoughtbot made the decision to go remote-first work from anywhere. And we touched on it in the previous two episodes a little bit, and that's what we're going to be talking about today. And I think that that's one of the things that made us confident in the direction was that things aren't great now, but they're certainly not bad. And the majority of the team felt good about what was happening now, even given all of the downsides. It gave us the confidence to look ahead and say, “Can this be even better, and will it be okay?” And I think that's part of what gave us the confidence to move forward.

+ +

LINDSEY: I saw this interesting stat, and this was actually from a while ago, last July 2020. Gartner did a survey of company leaders, and 80% plan to allow employees to work remotely, at least part of the time after the pandemic, and 47% will allow people to work full-time from home, which is even a bigger percentage than I anticipated. But I think it speaks to the major change that everyone's seeing. We've all learned that remote work can work. I saw another stat that was, I think, no companies are reporting a reduction in productivity because of remote work, and in 27% of cases, companies feel like they're being even more productive.

+ +

CHAD: We didn't not do this before because we didn't think it would be productive on a day-to-day basis or that we didn't believe in the ability to work remotely working. There were a couple of important points that caused us to choose the direction we did; the first one being we went through a period of time where we were a hybrid remote or about half the team was remote, and the other half was working in an office in Boston. And it felt hard and mediocre and something we couldn't -- It wasn't worth the amount of effort we would need to invest in making that work well. It just didn't seem worth it. And so we made the decision to -- And I think this is the way thoughtbot works like we've got to make intentional decisions in a lot of things that we do and half measures don't really satisfy us over the long-term. And so there was this feeling back then of we either need to decide to go completely remote, or we need to all be in person. And because we work locally with clients, that pushed us in the direction of well, we really like working with local clients face-to-face. We like how that feels, and it feels like something that's going to be enjoyable and fulfilling, and sustainable over the long term. So let's commit to that. And I think that that's one of the reasons why we've been successful in this transition is because, at the same time, we no longer had the client constraints of clients asking us to be in person with them or wanting to work with them in person, that was just completely off the table.

+ +

LINDSEY: That's interesting. I think I hadn't really fully thought about that element which was need or perceived need from the client to be side-by-side with us.

+ +

CHAD: Yeah. Once that was off the table, it allowed us to be freed up to make an independent decision, probably more confident in that decision because going through a period where we could show clients that it could work, I'm more confident now that when clients can be in person again, that they will be more open to working with us remotely. And I'm sure some portion of them won't be, but we'll find other clients in that time period. [laughter]

+ +

LINDSEY: I think another thing that helped us in that transition was we weren't fully remote, but we were remote in a lot of regards. So we had six different studios around the world who collaborated together, worked on the same projects and the same teams. And we had a really good starting point for how we collaborated online, whether that's in actual video meetings or doing asynchronous work or project management all the way through to client work. Not everyone was in the city of the client that they were collaborating with.

+ +

CHAD: Yeah. And all of the corporate team, the operations, marketing, all that stuff was already really a distributed team. It was primarily the design and development that fell back on being in person the most often.

+ +

LINDSEY: And I would say we also had a pretty flexible work from home policy too. So if folks felt like they were going to be more productive from home a certain day or were having a delivery or whatever those life things are, we trust that they know what's best for them and best for the client and allow folks to make decisions about where they're working.

+ +

CHAD: The way that we worded it before was that temporary remote working was always okay. And that could be I'm going somewhere for two months; even that was okay. And the opposite of that is what we said wasn't okay, which wasn’t permanently remote. And the big difference now is that we said permanently remote is okay. And walking back through the transition, this was something that has been an ongoing conversation at thoughtbot for a while. It was pretty early on in the pandemic that we said that people needed to start to move out of the places that we had studios. And I think that that was the first important step that we took as a company to make sure that we were supporting everybody in what they needed to do for life reasons saying, “If you need to move outside of a place where you would normally be based, do it. We'll continue to support that.” And then about 20 people, [laughs] a little less than 100 moved over the course of the next six months or so. And once that happened, that's a pretty significant portion of the team no longer being based where we have offices, and that sort of sealed the deal.

+ +

LINDSEY: I didn't know that number.

+ +

CHAD: I think it's less than 20. I think it's like 17 or something like that.

+ +

LINDSEY: So it probably works out to about 20% moved to where there weren't offices. And do you have an idea how far spread out everyone is now?

+ +

CHAD: I think most people who moved significantly moved to be closer to family or back where they were originally from. I think that was the driving factor. So it's places like Texas, different parts of Texas, Arizona, that kind of thing. And then people bought houses to get out of the city and that kind of thing as well, particularly New York City was -- I think a lot of the people in New York City are the ones who moved as well.

+ +

LINDSEY: So, how would you describe our remote structure now?

+ +

CHAD: I think there are a couple of important things like, we're specifically calling it work from anywhere, not work from home. Obviously, we all need to be in our homes now, but long-term, there's no reason why if the home isn't comfortable for somebody that they will work somewhere else, and anywhere also means geography. And we're not even completely shutting the door on eventually having small co-working spaces or small offices where people can get together and work in person. It's just not what we have right now and not what we're specifically planning on in the short term. So I think that's the base level when I think about the important parts of the structure is what are we actually saying, or what are we actually doing?

+ +

And then the next important aspect we took into account was okay; one of the things that influenced the way that we were working before, which was a local team working with primarily other people in your office was it's pretty annoying, and it does affect productivity to be waiting significantly across time zones for people that you're supposed to be collaborating with. And so we ended up splitting the company by time zone into what we’re calling Launch Pad 1 and Launch Pad 2. And Launch Pad 1 is all of the Americas, and Launch Pad 2 two is Europe, Middle East, and Africa. It's interesting because that's actually only about three maybe four times zones different at the extremes. All of the Americas, when you do it out, it's a lot of time zones. It's ten timezones, but the reality is we don't have anybody in Hawaii or Alaska yet, so we're okay with that.[chuckles] But it's something that may need to be revisited in the future if we really start to hire people remotely in those extremes of the time zone.

+ +

LINDSEY: So the geographies are really time zone-based, which is an interesting note. And then I'm sure some folks are also interested in logistics, especially now that you're heading up operations. What does that mean, or what are the big hurdles when you do have people spread across countries, let alone states?

+ +

CHAD: So let's break it down in terms of employment stuff, and then we'll talk about operations like how we run things. We're not leading the charge in this. Other companies have done it before. And so we're taking a lot of cues from companies like GitLab and Buffer about how they do things. We've had international employees for a little while off, and on or international team members, I should say. And what we've historically leaned on for that is having them as independent contractors. And it's pretty common for them to create their own company that they're then using, and they're working within, and they're paying local taxes, and they're invoicing us for the time. And in a lot of countries, their laws are conducive to that. But strictly speaking, it's not okay to do that in every country. And if you were to get audited and someone were to look at the relationship you have with that person and their laws are similar to the U.S., they might declare that person an employee, and you're responsible for the taxes and everything, not them.

+ +

Operating at the size we are, to be perfectly honest, at the size, we are with a handful of people, it’s a gray area. Like, some places it's okay, some places it's not quite okay, but it's only a handful of people and everything. You can get away with that without doing a lot of research into each specific country, whether it's okay or not, particularly if you make it the responsibility of the people, and you set up contractor agreements, and you set things up that way. So that's a pretty common way of operating. But as you start to grow and formalize it more and the numbers of people that you're working with as international contractors increases, the pressure is going to mount to say, “We have to get out of this gray area; otherwise, some country or someone could get in trouble,” not even us, but potentially the team member. If they were to get audited and it's not quite up to snuff, they could be held for some employment taxes or something like that. So we want to avoid that. We don't want to create a burden on people. And so there's really two ways of going about it; one is to create local entities in each of the countries where you want to hire somebody. So you create your own local company. That company employs them and pays the local taxes and employment taxes, and all that stuff and everything is fully set up and official, and we've done that before. We did that in Sweden when we had the studio in Stockholm, and that's how we work in the UK.

+ +

The overhead of doing that is really high, especially --It’s okay when we were in Sweden and the UK and the U.S. But as we look ahead and we say, “We're going to have ten then maybe 20 in different countries,” the overhead of that is really high. So the alternative is to work with a company that does that for you. So there are companies they're called PEOs professional employment organizations or international PEOs. And what they do is they create companies in all of the countries that they want to operate in, and then they employ the people as real full employees there. And they do all the books, and they pay all the taxes and everything. And they make sure that everything is done correctly for each individual country. And then they invoice you for the employee's salary, the taxes, and then an administration fee. And it's typically on the order of $250 to $600 a month per person. And so that's the direction we're going to go in as we expand this and we do it. That's the direction we'll go in because we've been through what it's like to create that overhead of the individual entities in each country.

+ +

And it might make sense if we were saying we're going to open an office or hire significantly in this one country and build a whole team of 20 people in one country, but that's not what we were planning on doing. We may only have one or two people in each of the countries that we end up hiring someone in. So it doesn't make sense to have that overhead. And there are a few different companies out there, and not to plug them, we're not using them yet, but the interesting one that's on my radar is remote.com which was started by the person at GitLab that did this all for them and learned a ton about it and then left GitLab and started remote.com as a way to make that more accessible and modern for other companies. A lot of the other companies that do this tend to be very large, and they've been around for a long time, which typically means things aren't really done online so much; it's a lot of paper. And remote.com it's a website you sign up for. You could just enter the people in, and things happen automatically. And so that's why that's on my radar.

+ +

LINDSEY: They're probably getting a lot of business these days.

+ +

CHAD: Yes. And they have a lot of countries that they're expanding to over the next year or so.

+ +

LINDSEY: How many countries do we have people in now?

+ +

CHAD: That's a good question. I don't know [laughs] United States, UK, and Uruguay right now. I think those are the only ones. But we have two people who are moving, one to Canada, one to Austria. So those are the next two that are on the horizon. And we're actively hiring, so we just opened a bunch of positions. And I know that a lot of people applying to those positions are from places like Brazil, other places in South and Latin America, and potentially Canada as well.

+ +

LINDSEY: Cool. Oh, we also got some great audience questions for this episode, so thanks to everyone who submitted. One of the questions was, when will you start hiring Canadians?

+ +

CHAD: We're doing it now. [chuckles] All the positions on thoughtbot are at thoughtbot.com/jobs. They're all listed as remotely. They're segmented by Americas versus Launch Pad 2, which is Europe, Middle East, and Africa.

+ +

LINDSEY: So, continuing on the hiring conversation, obviously, the hiring process itself has to be modified for the remote life. I'm not personally currently hiring, but I see the activity. And I think it seems like right now we've got a good handle on it but are also in the process of figuring out what works best and how to optimize it. Because we were on a hiring freeze for a while, and now it's opening back up, and we're trying to figure out how -- Honestly, it seems like the biggest question is how do we replicate that in-office cultural experience, social experience in the online format?

+ +

CHAD: Yeah. Up until the office visit portion, the majority of our hiring process was already remote. So the non-technical interview was primarily done remotely. The technical interview was primarily done remotely. But at the final stage of that process, we would bring people into the office for the full day to pair with one person in the morning for developers, pair with another person in the afternoon, have lunch with the team. For designers, it was getting a design challenge and working with the team throughout the course of the day in a conference room. And so replicating both the working together aspects and the social aspects of that office visit day is important to us, and that's where the tricky part has been. The working together part is the easier part of it, I think we found because we're all working remotely anyway. So we just replicate that; it’s pairing remotely, and it's doing the design challenge in collaboration remotely. It's the social aspects that are harder. And part of it is is we're not necessarily getting everybody together on a regular basis every day and so creating a time for everybody to come together just because we have a candidate visiting and do something that's not artificial, together, was a little bit tricky to find.

+ +

LINDSEY: Everyone act natural and social at 2:00 p.m. [chuckles]

+ +

CHAD: Right. Go. [chuckles] And then to insert someone into that mix who doesn't know anybody on the call and is interviewing, it's a high level of awkwardness for the candidate as well. So what we've found has worked best is to find something that we are doing already and piggyback on top of that. So in the case of the UK, they were already getting together where everyone shares something that they're working on. They were already doing that on a regular basis. Or someone would say, “Let's have a discussion about this,” we were already doing that. So just making sure that that gets scheduled for when there is going to be a candidate and then prepping them and asking them to prepare something to share as well.

+ +

And then, when it came time to do a different team, I encouraged them, “Don't just do what they're doing because they were already doing this. If you try to do it, and it’s something you're not doing already, it might turn out to be even more awkward. Try to find something that you're doing already and piggyback off of that.” And some teams were brand new, and they didn't have anything that they were doing already. And so that's the one thing we talked about in the last episode. But at the same time as going remote, we also, instead of being small teams based on geography, we reorganized to be based on the kinds of projects that we work on. And so Boost, for example, was an entirely new team of people that didn't necessarily have those norms and those regular events happening. And so they needed to create something that they could use not only to bring the team together but that that hiring process could piggyback on for that final stage.

+ +

I think mostly it's gone well. I think everyone knows that it's a little awkward, so I think everybody gives it the benefit of the doubt. I couldn't imagine...well, I guess I can imagine it. But I wouldn't necessarily want to arrive at a standpoint where we start hiring people without the opportunity for the whole team that they're going to be working with to get to know them a little bit but also to provide their feedback but also for the candidate. When you join a new company, you want to know what it's like to work there. You want to know that you want to work with the people. You want to flush out any red flags. And I don't think we have any red flags. And so I'd rather that be out there and that kind of thing so that people can experience as much as possible what it's really going to be like to work at thoughtbot and who you're going to be working with.

+ +

LINDSEY: So we have another audience question, and you can let me know if you actually want to answer this or not. How will you handle compensation? Will it be the same for everyone across the globe or country-specific, et cetera?

+ +

CHAD: I can totally answer this.

+ +

LINDSEY: You want to get into it? Let's do it.

+ +

CHAD: I realize I'm answering in long-winded ways, but I think the context is important in these things. So the way things worked historically at thoughtbot was based on your geography, but that made sense because the clients were based on geography, and each of the locations was working with local clients. And so, the economy of the different studios was entirely different from one another. So the studio in Raleigh-Durham worked with clients there primarily, and that is very different than Manhattan, New York, and what people understand a local team costs and what they're willing to pay and that kind of thing. And so there was a natural one-to-one correlation between the studio you worked in and the economics of how the business of that studio worked. And so the salaries and the economics of the whole expenses of the studio were based on that local thing. And so that's the way it worked previously. And then we would always do reviews within that group of people to make sure that there was fairness in pay from an equity perspective between people with the same level of experience and not for other factors like gender or anything like that, so equity in pay is really important to us. And so every compensation thing goes through that review process. And then we do an annual salary review every year where we re-review everything for equity, and we review an increase for economics and performance, and that happens in April. So when we went remote, we didn't change anything. And historically, what would have happened if you lived in one place and you moved to another studio with different economics? Your salary might change because you needed to be sustainable within that studio. And you would find that out in advance, and it would factor into whether you want to do it or not.

+ +

So when we went remote, and people started moving, what we did was we reminded people that traditionally, that might have an impact, but you're not moving to where a new studio is. We don't know how things are going to be in the future, just that we'll do the salary review in April. So coming up to the salary review, we started looking at the way that we were going to do it. We went through a little bit of a change when we originally started the process; like I said, we're taking cues from other people, and one of those companies is GitLab. And what GitLab talks about is cost of market. And so that's what we had planned on doing so rather than paying people cost of living, cost of market is the idea of what would your competitive salary be based on where you live? And that includes both remote and local employers, what you can command, but it doesn't necessarily mean that it's the same everywhere based on where you live. And so that was the direction we started to go down. It's not where we ultimately ended up. Ultimately, we ended up creating within the United States, based on the position you have, a salary range, and that is the same salary range across the whole United States with a couple of exceptions, and I’ll mention what that is. So if you're a developer, or if you're a senior developer, or you're a team lead across the whole United States, you'll fall within this range based on your performance, and I'm happy with that. We were never philosophically opposed to doing that. And I'm pretty cool with the fact that we got there in the course of doing the review.

+ +

So the exception to that is we financially couldn't set the level of that salary at a city like San Francisco or New York. If we were bringing everybody up to that level at the company, it would be very difficult for us to be profitable. And so we set the tiers based on the next tier down of cities in the U.S., so it's cities like Boston and Austin are where we took the bands from. We have team members who live in San Francisco and New York, and that, strictly speaking, would have meant a salary reduction for the people who live there. And we didn't want to create hardship on people that didn't know that we were going to do that. When they decided where to live, it would create hardship on people. And so, we took a look at New York and San Francisco, and we created another tier that is based on those markets.

+ +

And then, between those two tiers, what we're looking at is, are these salaries based on the cost of living equitable? So does someone who was working at thoughtbot in New York effectively earn the same amount of money as someone on the other tier who's living anywhere else? And if you actually look at that, the interesting thing is there are more people at thoughtbot now who are at the main tier who live in even lower cost of living places. And so they're actually coming out sort of it's more favorable, which is I'd rather be in that position because I think over time, more and more people will become more and more distributed, and people will live in different places with different cost structures. Any follow-up questions or thoughts on all that?

+ +

LINDSEY: For me, I'm glad I didn't have to decide it. [laughter] It's really complicated because I see there's logic to different approaches. Nothing is an obviously bad decision. The reality is we do live in a world where economics of location vary greatly. But at the same time, what does the future of work and equity look like?

+ +

CHAD: Everything I just said was U.S.-centric. So we actually don't have a set thing that we're doing for countries outside of the U.S. We're going to evolve that based on what we learn over the next few months as we hire people. There are really two tracks or two options in front of us: the first one is to establish country rates, and the second one is to establish an outside of the U.S. tier like that is maybe the same or slightly below that other tier that we're already talking about, the main tier that everybody in the U.S. is on. And so we'll see what we learn over the course of that. The reason why we probably won't end up there is because Canada is very different than Uruguay, for example. And so establishing one rate that works everywhere -- There are two important things that are our guiding principles here; the first is people should be paid equitably and fairly for the work that they do. At thoughtbot, there's not really an ulterior motive. We don't have outside investors. We're just people who work at the company trying to create the company that works on our behalf as people who work here. That's the primary motivating factor is to be fair and to pay people as much as we can, and then the second thing is while being sustainable. So we also don't have outside investors. We don't have a huge bank role, and we have to operate profitably. We’re not a VC-backed company that doesn't need to operate profitably. And so that's the second guiding philosophy is we've got to make sure that we operate profitably. And if we create a tier, creating a tier that works to meet both of those things, pay people fairly and be sustainable, we've got to set those numbers right because it's pretty easy to hire a bunch of people in an expensive place and set the tier too high and then not be sustainable. So we'll learn over the next six months.

+ +

LINDSEY: So switching gears a little bit, we got a few questions from folks who are curious how we are actually doing the remote collaboration with clients because that's obviously something core to what we do that we're really passionate about and I think especially on the design side too. So someone's like, “How, are you doing things you used to do on whiteboards or on the walls?” The sprint comes to mind with the sticky notes all over the different walls.

+ +

CHAD: Well, I've been talking a lot. Do you want to start this one? [chuckles]

+ +

LINDSEY: Yeah. It's funny; I’ve said this before on the show, but I feel like going remote has also almost made our meetings more equitable. We had a lot of especially corporate folks in the Boston team who would sit in a room, and then we'd have a few folks from our different studios calling in remotely. And there is a disadvantage to that, not being in the room and not being able to hear every comment or the conversation after the call has ended. And I feel like this spills over to client work as well, where remote meetings can actually be even more productive and collaborative in a lot of ways. So that's one component. But as far as the actual tools that we're using, I would say right now we're using online whiteboarding, sprint-mimicking tools a lot. So Miro is definitely getting a lot of use.

+ +

CHAD: I think that's the one we're using the most. New things come along, and people experiment with them and everything, but the default at this point is Miro.

+ +

LINDSEY: They even have the sticky note feature, which for some reason, just works. It's the same thing as having a little box and writing in it, but it feels like a sticky note. So it evokes the feeling of the sprint. So we do use that a ton for brainstorming and collaboration internally and with clients.

+ +

CHAD: And there are actually some things that are obviously being in person in the room with people is really nice, especially in those early days of a product where it's a really critical portion of the time. But there are some things about being remote equitable inclusive is one. Another is when you're in person, you have limited space. And Miro whiteboard is an infinite canvas, and so you don't run out of space. And when you flex to fill your whole tool and take advantage of that, it makes it easier. And the other I would say is -- and Jaclyn and Kyle just talked about this on the last episode of Tentative, our design podcast, which if people don't know about, they should check out. And talking about how when we're in person and one person is at the whiteboard, they have a marker, and they're working on a sketch, bringing together the wireframe and the storyboard. They’re the one with the marker, and they're the one who's doing everything, and not only is that not necessarily -- They're the funnel of all the ideas, but it's a lot of work for them as well, and it's not as collaborative as it otherwise could be. But when everyone is remote, and everyone's on the live whiteboard, people can share the work in a way that is better and more efficient when it comes to those wireframes. And you can give people a task because everyone can have their own portion of the board. And you can say, “Can you do this for me?” And then two people can go off and do that on one portion of the board, and then you can drag it over when they're done, that kind of thing. And it makes the sprints more efficient.

+ +

LINDSEY: Yeah, like organizing the Post-it notes. I've seen that done a lot, asking for help. Grouping common themes together can make things move really quickly.

+ +

CHAD: We were already using Figma on the majority of our products. And for those who don't know, Figma is a collaborative design tool so think Photoshop or Sketch, a totally online version of that that's more like working on a Google Doc with people together. And now Figma has prototyping tools built in. So it's pretty powerful in a very online collaborative way to be able to create the designs and then turn them immediately into prototypes and to do that directly with clients and with other team members all in the same document. This is one of those things that is actually a little bit harder to do. If you're all in the same room with someone, you're inclined to -- I guess you could all open your computers and work in the same document together, but I feel like that doesn't happen as much instead one person's driving, so it actually makes things more productive to work that way.

+ +

LINDSEY: Yeah. Miro and Figma both have that kind of Google-ish feature of you see everyone who's in the doc, and you can actually see their cursor moving around in real-time as you're both working on it. And you can leave comments on all the kinds of collaboration features that you'd want with those kinds of things. And then on the development side, we also obviously put a lot of value on pairing on work. So I know even before Covid, we were experimenting a lot with different ways to do development pairing, whether it was in Hangouts or Slack video. And I believe we're currently using Tuple a lot for that.

+ +

CHAD: Yeah. Tuple was created by a previous host of this podcast, Ben Orenstein, thoughtbot alum.

+ +

LINDSEY: It’s how all the greats get started.

+ +

CHAD: Yeah. But unfortunately, it's Mac only. And so we do have some team members who are not on Macs; they're on Linux. So we can't totally rely 100% on Tuple. And so there are some other things we use like USE Together, and people who use Team Macs will share that way.

+ +

LINDSEY: And then I think one of the last things about remote work that is worth chatting about today is the team culture. We did have a very in-office culture, especially because folks are working on different client projects. And one of the things they love most about thoughtbot is the other thoughtboters and getting to see each other and maybe do investment projects together or going to the summit. So we had another question about this too, which is how do you foster that culture? How do you keep it going when no one's in-person anymore?

+ +

CHAD: I think this is one of the areas where we have the most iteration and learning to do because the work stuff we were already doing a lot of it. And the project stuff is easier to judge, too. So did the project work? Did we ship on time? Was the design great? It's a lot easier to get immediate feedback on whether what we're doing is working or not. And with the culture things, the ramifications of doing it badly might not manifest for months.

+ +

LINDSEY: We also need the client work to get money.

+ +

CHAD: Right. [chuckles]

+ +

LINDSEY: We need the money in order to work on the culture. [laughs]

+ +

CHAD: Right. And the fact that we've been doing this in the pandemic it's a double-edged sword. I think it gives us a little bit of leeway to say, “Things are not normal now. And so we can't do this or we can't do that, and that is just what it is. And so we're just going to have to make the best of it.” The other side of that, though, is that it's been a very difficult time for a lot of people, not only just because of the pandemic. This last year has been a really difficult year for a lot of people. And so, yes, we get a little bit of runway to figure things out because it's such a unique situation. At the same time, it's important more than ever to figure out how to support people and have things be good and fulfilling and sustainable for people and to have a culture that thrives, not necessarily just gets by. I think that is what has made this last year challenging is figuring that out.

+ +

So some specifics, we traditionally get together as an entire company once a year. So we brought that all online last year, and we combined it with our end-of-the-year parties that we usually do, which are also a hackathon where we take time off of client work, and we work on projects together. So we combined those two things in December and had a two-day all-remote event with murder mysteries hosted by professional companies to trivia and then underlying with the hackathon. And I think people really enjoyed it. It was one of those things where I think people were -- there was a pocket of people who were really skeptical about it. “I'm tired of being on video calls all day,” and all that stuff. “I'm not feeling up for it,” like all these sorts of things. And it was like, “Trust me, just show up, just do it.” And I think what we heard was pretty universal that people were surprised at how enjoyable it was. And so this year we're doing three of those, two one-day ones and one two-day one. And that'll be in May and then the summer, and then the winter. Implicit in that is we're not expecting to be able to get back in person together in any large group for all of this year.

+ +

LINDSEY: But you do anticipate in-person summit return.

+ +

CHAD: Yeah, definitely. I think it's more important than ever. And I think what we'll also see and encourage is team in-person get-togethers where it's not just the whole company, but you're on a project team or the marketing team or rocket fuel, as it likes to be called now, and get together. Yes, it's fine. Get together in this place. And that's one of the things that -- We spend a lot of money on very expensive offices in Boston and New York, and in the past, San Francisco, and Austin, London. It’s over $500,000 a year in office expenses between all those places that we still have the expense now. But once we're able to eliminate that expense, it's going to free up a lot of money to be put towards getting those teams together in person and do other things.

+ +

LINDSEY: That was the other thing I was going to say, and you noted this about the UK team is that there's also a lot of team-specific activities where team leadership for Boost, Ignite, Lift Off, Mission control or with the geography-based ones too are figuring out what kind of social stuff or testing out different ideas like the show and tells or doing quiz time. I know there's a pocket of folks who jump in the lounge, which came out of the remote summit, the lounge during lunchtime or after work on Friday, and just trying out different things.

+ +

CHAD: And Stephanie, who was the office manager in New York, has moved into an operations manager role, so company-wide. And a big part of what she is doing is figuring out things to try. And I think some things will succeed and some things won't, whether it's organizing games or the thing that just happened on Friday was people opting in to be paired for a 15-minute conversation with somebody else in the company, things like that. We're trying a lot of different things and seeing what works, what doesn't online. She created an online art gallery where people who are doing art can post it, that kind of thing. So we'll learn.

+ +

LINDSEY: We'll learn, and then we'll most likely share it with you, so stay tuned for that. You can subscribe to the show and find notes for this episode at giantrobots.fm.

+ +

CHAD: If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.

+ +

LINDSEY: And me on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot.

+ +

CHAD: Thanks for listening, and see you next time.

+ +

LINDSEY: This podcast was brought to you by thoughtbot.

+ +

Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bDBS3VZH + + ]]> + + Lindsey Christensen + Chad Pytel + + + 393: Reaffirming Values and Taking thoughtbot Remote + https://podcast.thoughtbot.com/393 + 6cd5c845-ce3b-473a-97d0-edc8fa480c0d + Thu, 20 May 2021 05:00:00 -0400 + thoughtbot + + full + 10 + thoughtbot + Chad and Lindsey take listeners behind the scenes and go deep into the nitty-gritty of recent thoughtbot company changes driven by the pandemic and the organization's need (and desire!) to go fully remote – all while reaffirming and revisiting the organization's values, mission, and purpose as part of the process. + 1:05:22 + no + + + Chad and Lindsey take listeners behind the scenes and go deep into the nitty-gritty of recent thoughtbot company changes driven by the pandemic and the organization's need (and desire!) to go fully remote – all while reaffirming and revisiting the organization's values, mission, and purpose as part of the process. +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD PYTEL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. +LINDSEY CHRISTENSEN: And I'm your other host, Lindsey Christensen. And we're back. Thanks for tuning in. +CHAD: We've missed you. +LINDSEY: Yes. We’ve been kind of busy. +CHAD: We've been busy, and we knew we were going to take a break after the last season. We didn't necessarily know for quite how long, and then a whole bunch of stuff happened, which we're going to tell you about today. From the last episode, you heard about the change to the thoughtbot CEO, and we alluded to some changes that we've made to the company. And we're going to talk about those today. +LINDSEY: Yeah. And in true thoughtbot Giant Robots fashion, we’ll go behind the scenes and give you the nitty-gritty of why things happened and how it's going because it's all really interesting. +CHAD: Yeah. I think on the surface, it's really easy to think about how maybe these changes have been entirely driven by the need to go remote or the desire to go remote. And the reality was that's an important part of it, but it really was so much more than that. Some of these changes that we've made are ones we've been talking about for a long time. And it wasn't until almost a year of operating in a different way that we said, “We need to make some of these changes in order to accommodate remote and working from anywhere.” And we fell back on a lot of other problems we needed to solve along the way. +LINDSEY: So we actually decided to break out remote work into its own episode, which will be the next episode. And I'm sure it's going to come up today, but it's a whole other area of changes and focus, whereas some of the reorg changes that we just underwent solved a lot or are trying to solve a number of challenges that we've been working on over the years. So I guess to start off, before we reorganized, how did we function? And that was largely geographically based. +CHAD: Yeah. And the geographic basis means that we had a studio in a city, and in that studio, we offered the complete thoughtbot services. And that was driven by this idea back in 2012 when we started to expand. Prior to that, we really held the company to less than 30 people. And we were primarily a group of people all in one location working together, and we were all of what thoughtbot was. And we really liked that. We liked the structure. But people wanted to move and live somewhere else. And our purpose is that we believe that there's a better way to work. And we want to share it with as many people as possible, although we've revised that purpose now as part of this process. And so I really remember the day we were having a company meeting, and someone stood up and said, “If we really believe we have a better way to work, why are we not trying to bring it to more people? Why are we losing these great team members only because they want to live somewhere else?” But we also really liked the small, close-knit team of people who worked closely together on client work. We had done some client projects that were split across teams and across time zones and that kind of stuff. And it just didn't feel as good as we wanted it to feel, especially because it was hybrid. +And so we said, “We know exactly what a great thoughtbot looks like. Instead of trying to expand what that great thoughtbot looks like, let's try to replicate it instead.” And so when someone wanted to move to a new city, we said, “That’s great.” We looked at the market in the city that they were moving to and said, “Let's grow another thoughtbot around them and use that as the starting point for a new thoughtbot studio that would be a full design and development team that offers and works with all the different kinds of clients that we work with.” And that was the model which brought us to being in six cities in the UK and in the U.S. and about 100 people working with a whole bunch of clients every year across those. But for the individual person working at thoughtbot, individual designer or developer, it felt very much like thoughtbot had always felt, which was you were working with a team of three or four other people directly on that client. Oftentimes, the client would be in the same city as you. And when we could meet face-to-face with people, they'd be working in our office, and we'd be working really closely with them. +LINDSEY: Another interesting element of that structure was the marketing, and community was also very locally based, so engaging in and hosting local meetups. Actually, all of our offices -- We had offices, first of all, in amazing locations in all of these tech hub cities, and all the offices additionally had space for specifically events and community type of activities. And we thought a lot about nurturing local community, creating local partnerships. Obviously, we're thinking a lot about the hiring pool, and nurturing potential future hires in those cities as well. +CHAD: Yeah, and that's what we had done in Boston where we got started, and it's very fulfilling to be part of your local community. And we wanted to embrace that as we grew. And for a good while, it worked pretty well. We were certainly able to grow quickly once we decided to do it. A lot of people who listened to the podcast a long time will recognize that we actually at one point had ten cities, some of which were pretty established and other ones which we were expanding into. And we learned a lot along the way about how much harder it is to build a local business than we originally were anticipating it would be. One of the things that we learned, and I've talked about this on the podcast in the past, is that with our reputation in the design and development community, we could often go into a major city and have a great first year because there was a lot of pent up demand for people who wanted to work with us, work at the company and as our clients. And that really led us astray in the beginning because we would go into -- We were expanding in three or four cities in the same year, and they were all super successful. So we were hiring teams to do all the work that we had. What we weren't doing was all the legwork we needed to do to build a sustainable local business. And so after the first batch of clients or the first batch and a half of clients we were done working with, we didn't have a sustainable pipeline of new local clients coming in. And so we learned a lot about how much we actually need to do when going into a new city to not only have that great first year but to have a great fifth year. And so we had a few failures where we had to close some studios just because we couldn't afford to operate them profitably, and that was pretty painful. I forget the episode numbers where we talked about it in the past, but we have. You can go back and listen to it. We can link them in the show notes. +LINDSEY: In addition to having the designers and the developers in the local studios, at least in recent years, we also had the structure that each city studio had a managing director. And a lot of those managing directors actually came from design and development themselves, but they were in charge of everything local including, and especially the sale, so finding new clients, onboarding them, the actual profitability of their studio, hiring. And again, as you mentioned, that was across all kinds of clients, all kinds of projects, but primarily locally based. +CHAD: And once we realized what it was going to take to build local businesses and make them successful, we refined that managing director position a lot. It wasn't one that we necessarily had in every studio, and so adding it or, in some cases, making the difficult decision to swap out the person in that with someone. Now that we understood what was necessary, making sure that someone in that position actually wanted that job and could do it. And that has been the journey we've been on; I would say for the past three or four years of making those changes, figuring it out so that when it was working well, each of the studios could work really well. And we've made a lot of progress with that. +But one of the problems we had, so we have all the individual studios, and then we have the corporate-level people which are myself and you, marketing people, operations supporting all of the studios. And one of the things that we've struggled with over the years is being consistently profitable as we've grown or primarily operating break-even, which historically we were very comfortable doing because the whole leadership and shareholder of thoughtbot and ownership all worked here. We care a lot about paying people as much as we can possibly do and having the greatest benefits we possibly can while staying sustainable. And so it wasn't an issue. We're not running the company to generate lots of profits that then go to some investors or shareholders. So operating breakeven wasn't historically a problem, where it started to become a problem is as we grew and grew, the numbers became large enough that when things didn't go like we were expecting and we were managing to break even, then we would be very unprofitable very quickly if something didn't go the way that we were expecting, and it started to put the company at risk. So we started to focus more on profitability. And one of the things that was hurting profitability is that we were maintaining these small teams with offices, and just the overhead of a small team across many different geographies added overhead, which made it harder to be profitable because we needed to do everything in each individual location. +LINDSEY: Right. So now, really getting into those big challenges that were pressuring us to rethink how we operate, profitability and margin was a big one, which once you look at the breakdown in the numbers, the overhead of having the different studios was one. I think that also bleeds into the MDs have really challenging positions. They're responsible for a lot: they're responsible for the happiness and fulfillment of their teams; they're doing business development; they're doing client management; they're in charge of their entire revenue sheet. So that was another area that I think over time, we were consistently looking at; how do we improve this role? How do we make it so that folks can be successful here? +CHAD: Well, you can imagine, too, that designers and developers at thoughtbot we were seeing a similar thing, which is in a lot of ways, thoughtbot is modeled around me and other early developers. And I would often tell people I really like a lot of variety. I like to be working on one client and have huge scaling problems and challenges that we’re working at and growing their business to a whole nother level. And I like rotating off of that. And I then like working with a startup where we’re building the first version of the product. And for some people, no doubt that is exciting and challenging but worth it. And same thing on the sales side for managing directors, like being able to know how to effectively communicate and sell to the needs of each of those different kinds of projects. It's totally doable, but it adds to a lot of effort and angst being spent on just always trying to do everything, both on the development side and the managing director side, and it's hard. And that was one of the challenges that we were hearing either explicitly, or in a lot of cases, I don't think people realized it was happening. Everyone at thoughtbot is amazing and is great and very high execution level and all that stuff. And when you start getting challenges or feedback about poor performance from a great performer, you start to question why is that? What's going on? And it's an unrealistic expectation to have someone work in as part of a large enterprise for six months and then next week have them working on a brand new startup MVP that's got to go to production in six weeks and necessarily expect them to on a dime be able to change their approach to managing that product and making sure that it's successful. +And like you said, we want to put people in a position where they can be as successful as possible in everything that they do and having good people spin their wheels even if it's not a performance problem -- if there's a level of interest or excitement for one kind of client over another, we have a system of collecting feedback about what you want to work on and rating the incoming projects. But the primary determinator for what project you work on was which one was starting at the time your other project was ending; that was the primary determiner. So people effectively had no choice about the kind of project that they would work on. And that was a common complaint that we heard from people is that lack of control. +LINDSEY: And even though it wasn't supposed to happen, I think people did have reputations for a specialty, and the managing directors or whoever was staffing a project would seek out certain folks for certain projects. So even though we'd like to think of everyone as being able to handle any kind of project, and at a basic level, they could for sure, people with specialties were sought out for things. So that was already happening organically. +CHAD: And related but even going deeper on it, when we're maintaining small groups of people that are a complete replica of everything that is thoughtbot, and it's a group of 9 to 25 people, that ability to specialize or to have a career path that extends -- The company you're a part of feels like a 20-person company, and in a 20-person company, there's naturally not going to be tons of room for a big career ladder and lots of advancement or specialization. You will trend towards having a team of people that are more generalized and less hierarchical. +LINDSEY: Were there any other big challenges that come to mind for you when we were going into, like, let's revisit how we're structured? +CHAD: Well, there was one that touched on all of what we just talked about, and that was design and thoughtbot. And this is one thing that's super interesting. And I think I've talked about it on the show before. But we started from day one as a design and development company. We've always done design, and we've always had people on staff that did it. And one of the things that happened, though, is being the first consulting company in the world to switch to Ruby on Rails and being a big contributor to that community, and building a reputation through our open-source and through our blog and everything on the development side, that part of the business has grown. The development team is much larger than the design team. And a lot of people in the world view thoughtbot as oh, they're a Rails development company and really it wasn’t -- What we've always talked about is Rails is in service of the products that we want to design and build and creating great products. And so design has consistently been a challenge over the years as the reputation there isn't as big as on the development side. +And so what we saw in the individual studios were each individual studio needed to have a certain number of designers in order to feel like it had a design team and to be able to service the work that it did have locally and a management structure within that team that made sense. It had all those problems that we've just talked about. It was difficult to be profitable. It was difficult to have enough locals work for the two or three designers that were in a studio. And that specialization for what they would do and the kinds of projects that they would work on didn't always match the actual work that we had in a particular city at a time. And so because we were organizing the work that we did geographically, it wasn't uncommon for a designer to not have client work to do and that hurt the design team because we were attracting these great designers. And people are at thoughtbot because they want to build great products; they want to do great work, and then they join the team, and they're not doing it. And so design turnover has been much higher than other parts of the company for that and other related reasons. +LINDSEY: Okay. So I have a question for you because you and Diana started on this process before I was involved. So for you, when did reorganization first start? +CHAD: Well, as I alluded to at the top of the show, we had been talking about these kinds of things for a while. And I think you were part of most of those discussions as part of the management team where it'd be like, oh, should we break out design? And there wasn't really this clear -- Our strategy for the last many years has been strong local studios bound together by a common purpose and values. And we were feeling pretty good about that strategy. So these problems would crop up, and we would evaluate them in the context of that strategy and say, “No, we're reaffirming our strategy.” So it wasn't until having gone through 2020 and looking towards what 2021 was going to be like and saying, “We've got all these things that could be better. But one thing we know that needs to change is we can't go through another year of everyone planning for all of this to be temporary and to be back to the way that we were before.” We had already been breaking down the geographic barriers of studios because many projects were being staffed across offices at a much higher level than ever was before. And we had given everybody the thumbs up to move wherever they wanted, and we were going to support it. And we had about 20 people move from places where we had a studio to places where we didn't. And so it was really that that crystallized the need to -- I didn't know exactly what we were going to do going into it, but this feeling we need to do something because we can't stay in this limbo state for another year, which is what we were predicting in terms of how long we were going to be in the current operating mode. And even when it does come back, we now have 20+ people who don't live where we have offices anymore. So we can't go through this next period of time expecting things to just go back to the way that they were. So that was when we knew that we were going to do it. So I guess that was at the end of November or the beginning of December of 2020. +LINDSEY: It was exciting to have this push to do it. As you mentioned, we talked about different options before. Like Joe had come up with, I remember, a really clever squad-based team proposal. We’d thrown around, “Should we do an industry-based team structure?” But I think what was really missing was a push, a driver, you know, you have to. Because it was “Everything else is kind of working okay the way it is. What if this is a big mistake?” And so we wouldn't move forward. So we had these major drivers to decide on something and then went into what I think is a really successful and fascinating series of brainstorming and iteration sessions pretty quickly as a leadership team to hone in on what we've ended up rolling out. +CHAD: And I think one of the things that I appreciated, and it was Diana who did this, was saying, “Let's make sure we reaffirm or revisit our values and purpose as part of this process.” And when you have a company that is driven by values and purpose, it's important when you're making big decisions to revisit them so that they're helping guide what you actually do so that you don't get off track. And we anticipated that the change was going to be big enough that maybe even the value -- We need to be open to the possibility that the value or the purpose would change or should change in the process or had already changed and we hadn't reflected them. And so that was a part of it, like expecting to go into it doing that. And then we can't have a...or maybe we could, but we decided it wasn't realistic to have a 100-person meeting. So again, for a lot of the things we do at thoughtbot, we treat thoughtbot like a product in and of itself. And we use the tools and techniques as designers and developers on that product itself. And so we did survey the team to get their thoughts around purpose and values and around what it had been like to work remotely and just a few questions in general about how they felt about projects and work and that kind of thing. And then, we took that information that we had gathered from the team into the design thinking and brainstorming sessions with the leadership team, which was the managing directors across all the studios and the design and development directors, and then the corporate leadership. +LINDSEY: And I'd say at the forefront of these exercises and decisions was how do we ensure thoughtboters are fulfilled? And also, how do we provide the most value to clients, and where those things intersect, how could we potentially reorganize ourselves? And these sessions are some of my favorite things to do, even though they can be maybe stressful times that are driving these exercises. But doing these kinds of really open brainstorming and design thinking exercises, problem-solving with our team, which is full of the smartest, most thoughtful, kindest people, I find incredibly fulfilling and really drive amazing outcomes. And I’m kind of sappy, I guess here. But I start to feel like, oh my gosh, I know why our clients love working with these folks. It's a really powerful exercise, and you come up with really amazing ideas and outcomes. +CHAD: Yeah. I had a thought as you were saying that, though, that I agree, but I think you could do exactly the same thing but not be committed to actually making a change. If you were just doing it, it would drive me crazy. [chuckles] And I think that that's an important component is that we went into it saying something is going to change; we don't know what it is. We define problems, and then we come up with solutions to those problems, and we are going to make a change. And that was the difference between the previous we're all sort of venting or trying to do it in a leadership meeting. And I think off-sites and brainstorming sessions and that kind of thing get a bad rap, but when they're actually necessary and when they're done well, and when you have a group of people that are committed to improvement and actually making a change, they can be really great. +LINDSEY: Yeah. And I think you all had set out a goal. You and Diana had set a goal schedule of how this would work, which is coming up with ideas as an extended leadership team which is maybe like 18 people. And doing that, we booked a half-day, maybe a bit more; obviously, this is all virtual. And we'd have different sessions where we were breaking out into smaller groups of maybe five people randomized each time and working through a specific challenge or coming up with a specific proposal, then reconvening as the extended leadership team and running through those proposals. So that would be the first individual day. And then you and Diana went off with those proposals and ideas to make some executive decisions around what you thought made sense and then re-proposed to the extended leadership team for feedback and iteration with the goal that every week we're getting closer to the final, final thing that we're going to roll out to the team. And also, by the way, how do we roll that out? +CHAD: I'm curious from your perspective how that worked because we didn't go into the process expecting it to work that way. Well, I guess we did. When Diana and I were planning it, though, we initially started from a different place, and then we realized this is going to be too difficult for a group to converge on, and it probably does need us to go and force a convergence basically and then go back and make a proposal. But I'm curious what you think about that. +LINDSEY: Oh, I think you absolutely have to do that. +CHAD: [chuckles] Okay. +LINDSEY: And that's the way I operate, too, even from a marketing perspective, is to take input and ideas and see what folks think. But at the end of the day, you can't make a group decision; someone has to make an executive decision based on what they've heard. So I thought that worked well. Plus, I was in the group that came up with the idea for the reorg we chose. I don't want to brag about it, but it was a great decision. +CHAD: [laughs] +LINDSEY: So yeah, I guess getting into what that actually was, what we ended up deciding and have moved forward with was breaking out the teams, so keeping a team-based structure but no longer geographically-based but actually each team based on the types of clients and client projects that they're providing services for. And obviously, those services are tailored to the type of client projects. +CHAD: Shall we go through them? [chuckles] +LINDSEY: Yeah, we should go through them. +CHAD: [chuckles] Okay. +LINDSEY: So the naming came after the fact, but we also had a lot of fun with branding and naming these teams and went all-in on the rocket theme, as you'll hear. So we've got four main service teams. The first one deals with the earliest stage products kind of pre-product so validating ideas, and that is thoughtbot Ignite. The next team deals with more MVP, V1 but not really a quick project, like longer MVP types of projects, and that is thoughtbot Lift Off. The third team deals with more established companies and teams who are elevating their product and teams to the next level that's thoughtbot Boost. And then finally, we've introduced more DevOps and maintenance services under thoughtbot Mission Control, and they also manage our PR reviews as a service, reviews by thoughtbot. So that's the quick overview of the four teams you've got Ignite, Lift Off, Boost, and Mission Control. +CHAD: And the interesting thing about the team structure and what each team was going to focus on is that once we made the decision that this was -- there wasn't really a lot of question around what those teams would be. We knew these different project types existed. It was something that we have documented, and it's in our marketing. We have positioning statements already. A lot of these client types were already created. We have an internal consulting class that people take, about 20 people a quarter take it. And it goes over the different kinds of clients that we work with and the different needs that they have and how to work with them. And it was split along these lines. Now there were some small details on the edges to be worked out, but what was difficult was making the decision to do this. Once we made the decision to do it, what those teams would be was pretty clear. +LINDSEY: Obviously, I love it. From a marketing perspective, breaking out these different types of clients makes so much sense. You're talking to them about different sets of needs, goals, pain points, so there's great focus and clarity there. And then that trickles to everyone's job. The managing directors now are responsible for one of these service-based teams. The designers and developers themselves are specializing and really enjoy that type of work. And in the breakout group during these brainstorming sessions that I was in, I remember when we were starting from this place of anything goes, I was asking the directors in my group, “What do you think makes our team fulfilled? Are they more interested in a specific industry? Are they more interested in a specific technology? Are they more interested in a type of client?” And the directors in my group all said, “I really think it is the type of project that provides fulfillment in different ways for different folks.” So we took that as a starting point, and then it was, “Okay, well, what are those different types of clients if we could put them into four or five buckets?” +CHAD: And Ignite and Lift Off are really interesting to me because it's a good example of where the lines can be effectively drawn. So you alluded to it already, Ignite is for the earliest of products and teams where the idea hasn't even been validated yet, and they need our help determining whether it even makes sense to proceed at all. And then when we do validate it, the size of what we're building and the speed at which we're going to be able to get to market falls under 12 weeks. It will typically fall in the 8 to 10-week range where we've gone from that concept that we validated to a launch product in the hands of users. And they’re ruthlessly prioritized. They're usually pretty straightforward, both on the tech side but also in what we need to build. And I think one mistake we've made in the past is taking large finance and healthcare companies and these large companies that we also work with and trying to do the same thing that we do for those Ignite clients for them and ending up in a place where maybe we haven't done as good a job, or the project doesn't go as well because we're trying to squeeze it into a place where it doesn't fit. And that's what Lift Off is; it’s creating a space where it fits, realizing that a client who comes to us with this massive need it's not massive because they're doing too much. It's massive because they have a big problem that they want to solve, usually for a business that already exists, and it's a new product within that business. Maybe they've even already validated it. And the integrations that it's going to have, the systems it needs to talk to, the level of scale that it's going to have is different than is going to be possible in 8 to 12 weeks. And when we try to squeeze it in there, it's not going to be successful. So Lift-Off is giving a space for those projects to thrive in a way. +And I also think it's one of those things where it's going to have an impact on our sales too because what would happen previously is that one of those clients might come to us and we're furiously trying to squeeze it down. And how a client perceives that is potentially like, “Oh, they don't know how to do what we need them to do, or they don't want to do it. Or they think our idea is bad because they're saying we need to validate it, and we've already validated it. We have an existing business that we're building this off of,” or something like that. And it causes us to lose that work, which we would otherwise love to have. And now a client like that comes and is talking to a managing director who gets the needs of that kind of project and a team of people that are going to work on it that understand that there's a process to run through and it's going to take six months or a year. We're going to launch along the way, and then we're going to continue to grow the product from there. It's just a different feeling all around, which I think is going to have a positive impact on our ability to actually grow those parts of the business. +LINDSEY: And Lift Off by nature of working on those health, tech, and financial products is also dealing with highly regulated spaces, which is another reason why those projects are necessarily longer and more complex and lend themselves well to someone who's dealt with it before. +CHAD: Right. Another thing, and we touched on this a little bit earlier with Boost, is a big part of our business historically is that those clients that have built-in Rails along the way, they've built a super successful business. They're scaling a lot. They're growing their team. They need technical leadership, experience mentorship, and those projects tend to be very development-heavy as well. Like, we have clients where we have four or five developers working with them and no designers, and it caused the design and the development team to be very lopsided. But we really liked that work, and it's very valuable to clients. And so same thing with Boost, Boost instead of that being something which is pushed off into the back where like, oh, well, it's not the project-based integrated team of designers and developers launching a new product, and so it's not our ideal work. It gives a space where that can be our ideal work, and the kinds of people who want to work on those kinds of projects with that level of experience and need feel like they are able to do that on a team that is focused on that. And that team doesn't necessarily need to have a design team that works or looks the same as every other place at thoughtbot. And it creates a place which can focus on what it needs to do in the best way possible that is the most fulfilling to the team and success for the customers. And it looks different than thoughtbot has historically looked, and that's okay. Because actually, when you pick it apart, it's not that different; it’s just taking the 20% of all of the thoughtbot studios where the 20% felt like something that wasn't quite right and putting it all together to make 100% of something that feels right. +LINDSEY: And from the design perspective, Boost design is a lot around optimizing what already is in place or helping take care of design debt that's been neglected, making sure design and development are talking to each other and thinking about those processes to make them talk to each other better. Whereas Lift Off and Ignite are more introducing design or design processes or design frameworks like putting your design system together or thinking about your accessibility processes, those kinds of activities. And then Mission Control is probably the newest to thoughtbot in terms of services that we're offering clients. +CHAD: And within Mission Control, there are two big areas that are different, so the first is maintenance. So we historically have been project-based at thoughtbot. And what that would mean is that well, it doesn't necessarily mean -- So historically, project-based plus everyone working on one project at a time, I think the combination of those two things meant that what we mostly did was we help people set up their own team of people who are going to take over from what we had done after we launched the first version of the product and level it up from there. And most of our clients got to the point where the goal was to become self-sufficient. And we also would meet people who had already built something and were just looking for our expertise to help take care of it but not necessarily have enough work for someone full-time. And for both of those clients, we didn't really have a solution for them. And so that's where the maintenance team in Mission Control comes into play because it's a team of people who have opted into splitting their time across multiple clients. The contracts are different where they're paying a monthly recurring maintenance fee for us to take care of certain things every month: security upgrades, patches, small bug fixes, and features. Maybe they even have a team on staff where they're doing the majority of the development work, but they just want our support in helping things go well. +And also, you mentioned the pull request review service that's within Mission Control as well where we have a separate service where you can sign up, and you just request a pull request review from thoughtbot, and then one of our team members goes on and gives you feedback on that pull request. So that's one part of what's happening in Mission Control is that maintenance work. And then the other is DevOps, and infrastructure is an area where the majority of projects that we worked on across all of thoughtbot were deployed to Heroku or the teams had their own DevOps and infrastructure people and creating a specialization of that for a handful of projects for an individual studio that has that need, over the course of a year, never made sense. But once we started to do it and we took a more global view to it and said, “Across all of our clients, what is the need either met or unmet and what might we be able to do? And where is the interest of our team?” It became clear we could offer -- like, our clients need us to do this sometimes. And for the clients who need us to do it, we want to be there for them. We want to do it. And creating a team of people that is global, that can do it across time zones 24/7 is also one of the needs of the clients, and having that team span those geographies is one way we've been able to do that when historically we would have shied away from that. +LINDSEY: And speaking of the team's interest in different areas, different services for the rollout of this new organization, we, by and large, had folks opt in to what they wanted to do even as far as the managing directors picking what team that they were going to head up. +CHAD: So we said, “These are what the teams are going to be,” and we did a company-wide presentation. And then, we asked people to submit their first and second choice. And then we made the decision around which of the managing directors were going to do what and then we announced that to everybody. Am I saying this the right way? Did we announce the managing directors before we asked everybody or just before the deadline was up? +LINDSEY: I think it was trickled in. At first, it was “What team do you want to be on?” But then, as that's going on behind the scenes, you and Diana are having discussions with the managing directors around where they want to be. And then, as that information became available, you shared that with the team also to help with decisions, same with the design and development directors. I think it was announced the design and development directors chose the teams they wanted to be on and lead. And then, once that was finalized, that was also shared with the team as they're voting on where they want to head. +CHAD: And the majority of people got their first choice and the majority of people the person who was their manager also chose a similar choice. And so there was a lot of change but not too much churn, I guess is the way I would put it. We were able to do it in a way which I think people felt like they had a choice. And I think going into it; people were afraid of that like okay, am I going to make a choice here and then end up on a team of people I've never worked with before? That was not the case. Now there's certainly a big blending of the teams, particularly Boston and New York were the biggest studios. And so they make up the majority of the people in each of the Boost and Lift Off. But people are working with people that they have worked with before. +LINDSEY: And it turns out the people they didn't work with before are also awesome, also, very cool. +CHAD: [chuckles] So much effort over the years spent -- that strategy of replicating what was great about thoughtbot into other geographies is true. And so the standards that we had for hiring, and the kinds of people we hire, and the screening for values fit, and all that stuff led us to a place where everyone at thoughtbot is great. And so I wasn't really concerned about that, but other people may have been because there's always a fear of the unknown. +LINDSEY: Yeah, definitely. I'm trying to think if there were other rollout things that might be interesting. +CHAD: Well, one of the interesting things it's a little in the details. On the surface, that is the team, and those are the services we offer. But we also needed to contend with the fact that we are in the U.S. and the UK, and we didn't really feel like it makes sense to have those teams span 10+ time zones, that that would be too far of a stretch. And it would affect people's fulfillment on the team as well as the services we are able to deliver. So these services that we offer are actually fulfilled by two…do we have a word for it? [chuckles] +LINDSEY: Geographies? +CHAD: Geographies, yeah, I guess. +LINDSEY: There are two geographies that we ended up naming Launchpad 1 and Launchpad 2, because rockets. +CHAD: So Launchpad 1 is all of the Americas, and Launchpad 2 is Europe, Middle East, and Africa. And so they provide all of those services in those places. But they have teams that are formed across the whole geographic region. And then eventually, if all goes well, we'll have Launchpad 3, and that'll be [chuckles] the other side of the world. +LINDSEY: I've got the icon ready and waiting. So I guess timing-wise, this all happened...rollout was by the beginning of the year, right? January? +CHAD: Yeah. One of the things is more people took more time off between the December Holidays and New Year's and everything than they have ever done before, and we needed it. Everyone needed it. So we weren't able to finalize what team everyone was on and have a conversation about that with everybody before they saw it in a message somewhere, which we really wanted to do. So we ended up not being able to finish all of that before the end of the year. And so it rolled into the first couple of weeks of January as people came back, and we were able to talk to them. And then I think we made the internally public announcements about all the teams that everyone was going to be on, and we did a formal kickoff. What was it? January 8th or something like that. +LINDSEY: Yeah. And I think that's actually a really good point to bring up is the communication to the individuals. It was important for them to hear it one-on-one from their manager before anything was announced more broadly and then to transition to their team if their manager was changing, which in a lot of cases, it didn't, but sometimes it did. Having one-on-one-on-one transition meetings to really ease that move was also important to not make this really abrupt and unnecessarily stressful in a time that is already very stressful for reasons we know. +CHAD: And even if someone's direct manager wasn't changing, it was very likely that their director would change. And so, in those cases, we still did a one-on-one-on-one, but it was with the new director sitting in as well as a skip-level one-on-one on-one. And we did it quickly, but it was important to make it happen quickly. +LINDSEY: And it was also important to not abruptly change on the clients because obviously, we weren't doing a full stop of client work just because we're doing some reshuffling internally. So that was phased, and we didn't even really make it a big deal to the clients because that probably would have just added confusion as we were making these changes. +CHAD: Yeah, definitely. And we made the decision that we weren't going to just arbitrarily say, “This person is now on this team; therefore, they have to leave this project,” so we made that decision. And we have as natural points in the project for a rotation to happen. People will move to a project; if there's a mismatch between the project that they're on and the team that they're on, they'll move at a natural point. But the reality was that a lot of people also chose -- It's not like we have 57 different project types; we have three. And so a lot of people were already working on the project type that they chose just because the odds were good that they were. There's been very little customer-facing impact to it. So it's early days. It's March now, so it's been a couple of months. But how do you think it's going, or where do you think the growing pains are? +LINDSEY: Good question. I think there's been more of a smooth transition than there have been growing pains, first of all, which has been nice. I think folks have been pleasantly surprised by really enjoying their new teams and new team members. I think growing pains-wise, on the operations side, obviously we've had to...I think we’re still in the process of figuring out how to best pipe certain kinds of inquiries into the right team and managing director. Sometimes it's a no-brainer. They're like, “I need to validate this idea.” It's like boom, “You're off to Dawn for Ignite, and you’re going to have a conversation there.” But if they come in and they say, “I'm working on an MVP, and we don't know if that MVP is one of the really fast ones or one of the more complex ones,” then it's like, okay, is this going to Dawn or Emily? +CHAD: And we historically didn't need to have any handoffs because one person was able…one person and team; it was based on geography. So we knew exactly who was going to be having that conversation with them. So operationally, it's actually one thing we didn't touch. So no one was let go in this big reorg. There was a position for everyone, I guess, if they wanted it. But one area we haven't touched on is anyone who was local, who was in a support role moved up into the corporate level in a support or operations role. And there weren't that many of those people, but the office manager in Boston is now full-time in people operations. And the office manager in New York City is now the operations manager for the whole team, the whole company. Kelly, who was doing business development just in Boston, is now helping across all of thoughtbot, which is really good at using her skill set across the whole company. I think that that's good. +And now, like you said, figuring out how to support everyone across the teams is a little bit of whether it be the operations manager figuring out how to get people computers when we hire new people to like what you were saying around inquiries coming in and making sure that they're sent to the right person. The thing that has made it more challenging for me is that just a confluence of events at the time where we were making some of these changes. And now it has made my involvement different than I was originally expecting them to be. I expected to be a little bit more involved in certain things, but because I've been pulled into several important client projects and was working on client work at the time that then expanded very rapidly, it's been challenging for me to manage the workload. But in some ways, there's a bright side to it, which is it's giving other people the space to operate without me, which I think can be good because I'm very confident in what everyone's bringing to the table. And when you go through a big period of change like this, if everyone was deferring to what I thought as the founder or looking for me for answers or permission to do something, I think that we would suffer for it. And so being forced in a way to not be available for everything that's going on is a way for people to have more ownership over it and not be relying on me, and I know that they can do it. +LINDSEY: Cool. +CHAD: So we never said what the new purpose was. So maybe we'll just talk a little bit about that, and then we'll use that as a wrapping up point. +LINDSEY: Sounds good. +CHAD: So I mentioned earlier our purpose had been we believe that there's a better way to work. There's always a better way to work, and we want to find it and share it with as many people as possible. We had written down that purpose several years ago, like a decade ago, I think. And I believe a good purpose describes what is the underlying motivation for the company and the people at it. And when we did that survey of people, a few of the questions we asked touched on it. And it wasn't that surprising to me about -- one of the threads in that was this idea of positive contributions to the world, making sure that the things that we work on and do have positive contributions to the world and that being a motivating factor. Like, that's part of what makes the team tick and what they want to be doing and are fulfilled by and that kind of thing. And so we incorporated that into the purpose. And so we adjusted the wording a little bit to make that incorporation, but we ended up that we believe that it's always possible to continuously learn and improve the way people work while building higher quality products that make positive contributions to the world. +This resonated with me in a way that -- it's a little bit more wordy, and that's not why it resonates with me. [chuckles] Specifically, our previous purpose of we believe that there's always a better way to work and we want to find it and share it with as many people as possible lacked one thing that I think a good purpose can incorporate, which is what is a clear idea of what the alternative is like, what you're fighting against, or what you're trying to improve. It's there in the previous purpose. So, in theory, there maybe are people out there who believe that there's not always a better way to work that they've achieved it or something like that or that they have particular practices which aren't great. But it's not explicit or really even implicit in the purpose. And the new purpose we believe that it's possible to continuously learn and improve the way people work while building higher quality products and make positive contributions to the world. You can point to someone who might believe the opposite of that, that you can't build higher quality products that make positive contributions to the world while also continuously learning and improving the way that you work and everything, that to build higher quality products or make positive contributions to the world, you might need to compromise on the values of continuous improvement and learning. And our new purpose makes a statement that you don't need to compromise in order to achieve that result, and I like that about it. +LINDSEY: I really like the addition of talking about the kinds of positive products because I think once you know thoughtbot at all, you know that that's underlying the purpose but take out the guesswork, just tell the folks. All right. Well, I think that's a good place to stop. I'm glad we didn't even go into the remote because there's obviously a lot to talk about. +CHAD: Yeah. So we'll talk about that next time? +LINDSEY: Yeah. We're going to talk about what changes we've made in going completely remote and what that looks like, what we think it looks like for the future. +CHAD: Cool. +LINDSEY: So you can subscribe to the show and find notes for this episode at giantrobots.fm +CHAD: If you have questions or comments, and we'd love to hear them, email us at hosts@giantrobots.fm, or you can find me on Twitter @cpytel. +LINDSEY: And you can find me on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot. +CHAD: It's good to be back. Thanks for listening and see you next time. +LINDSEY: It's so good to be back. Stay tuned. +This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success. + + + Chad and Lindsey take listeners behind the scenes and go deep into the nitty-gritty of recent thoughtbot company changes driven by the pandemic and the organization's need (and desire!) to go fully remote – all while reaffirming and revisiting the organization's values, mission, and purpose as part of the process.

+ +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD PYTEL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

LINDSEY CHRISTENSEN: And I'm your other host, Lindsey Christensen. And we're back. Thanks for tuning in.

+ +

CHAD: We've missed you.

+ +

LINDSEY: Yes. We’ve been kind of busy.

+ +

CHAD: We've been busy, and we knew we were going to take a break after the last season. We didn't necessarily know for quite how long, and then a whole bunch of stuff happened, which we're going to tell you about today. From the last episode, you heard about the change to the thoughtbot CEO, and we alluded to some changes that we've made to the company. And we're going to talk about those today.

+ +

LINDSEY: Yeah. And in true thoughtbot Giant Robots fashion, we’ll go behind the scenes and give you the nitty-gritty of why things happened and how it's going because it's all really interesting.

+ +

CHAD: Yeah. I think on the surface, it's really easy to think about how maybe these changes have been entirely driven by the need to go remote or the desire to go remote. And the reality was that's an important part of it, but it really was so much more than that. Some of these changes that we've made are ones we've been talking about for a long time. And it wasn't until almost a year of operating in a different way that we said, “We need to make some of these changes in order to accommodate remote and working from anywhere.” And we fell back on a lot of other problems we needed to solve along the way.

+ +

LINDSEY: So we actually decided to break out remote work into its own episode, which will be the next episode. And I'm sure it's going to come up today, but it's a whole other area of changes and focus, whereas some of the reorg changes that we just underwent solved a lot or are trying to solve a number of challenges that we've been working on over the years. So I guess to start off, before we reorganized, how did we function? And that was largely geographically based.

+ +

CHAD: Yeah. And the geographic basis means that we had a studio in a city, and in that studio, we offered the complete thoughtbot services. And that was driven by this idea back in 2012 when we started to expand. Prior to that, we really held the company to less than 30 people. And we were primarily a group of people all in one location working together, and we were all of what thoughtbot was. And we really liked that. We liked the structure. But people wanted to move and live somewhere else. And our purpose is that we believe that there's a better way to work. And we want to share it with as many people as possible, although we've revised that purpose now as part of this process. And so I really remember the day we were having a company meeting, and someone stood up and said, “If we really believe we have a better way to work, why are we not trying to bring it to more people? Why are we losing these great team members only because they want to live somewhere else?” But we also really liked the small, close-knit team of people who worked closely together on client work. We had done some client projects that were split across teams and across time zones and that kind of stuff. And it just didn't feel as good as we wanted it to feel, especially because it was hybrid.

+ +

And so we said, “We know exactly what a great thoughtbot looks like. Instead of trying to expand what that great thoughtbot looks like, let's try to replicate it instead.” And so when someone wanted to move to a new city, we said, “That’s great.” We looked at the market in the city that they were moving to and said, “Let's grow another thoughtbot around them and use that as the starting point for a new thoughtbot studio that would be a full design and development team that offers and works with all the different kinds of clients that we work with.” And that was the model which brought us to being in six cities in the UK and in the U.S. and about 100 people working with a whole bunch of clients every year across those. But for the individual person working at thoughtbot, individual designer or developer, it felt very much like thoughtbot had always felt, which was you were working with a team of three or four other people directly on that client. Oftentimes, the client would be in the same city as you. And when we could meet face-to-face with people, they'd be working in our office, and we'd be working really closely with them.

+ +

LINDSEY: Another interesting element of that structure was the marketing, and community was also very locally based, so engaging in and hosting local meetups. Actually, all of our offices -- We had offices, first of all, in amazing locations in all of these tech hub cities, and all the offices additionally had space for specifically events and community type of activities. And we thought a lot about nurturing local community, creating local partnerships. Obviously, we're thinking a lot about the hiring pool, and nurturing potential future hires in those cities as well.

+ +

CHAD: Yeah, and that's what we had done in Boston where we got started, and it's very fulfilling to be part of your local community. And we wanted to embrace that as we grew. And for a good while, it worked pretty well. We were certainly able to grow quickly once we decided to do it. A lot of people who listened to the podcast a long time will recognize that we actually at one point had ten cities, some of which were pretty established and other ones which we were expanding into. And we learned a lot along the way about how much harder it is to build a local business than we originally were anticipating it would be. One of the things that we learned, and I've talked about this on the podcast in the past, is that with our reputation in the design and development community, we could often go into a major city and have a great first year because there was a lot of pent up demand for people who wanted to work with us, work at the company and as our clients. And that really led us astray in the beginning because we would go into -- We were expanding in three or four cities in the same year, and they were all super successful. So we were hiring teams to do all the work that we had. What we weren't doing was all the legwork we needed to do to build a sustainable local business. And so after the first batch of clients or the first batch and a half of clients we were done working with, we didn't have a sustainable pipeline of new local clients coming in. And so we learned a lot about how much we actually need to do when going into a new city to not only have that great first year but to have a great fifth year. And so we had a few failures where we had to close some studios just because we couldn't afford to operate them profitably, and that was pretty painful. I forget the episode numbers where we talked about it in the past, but we have. You can go back and listen to it. We can link them in the show notes.

+ +

LINDSEY: In addition to having the designers and the developers in the local studios, at least in recent years, we also had the structure that each city studio had a managing director. And a lot of those managing directors actually came from design and development themselves, but they were in charge of everything local including, and especially the sale, so finding new clients, onboarding them, the actual profitability of their studio, hiring. And again, as you mentioned, that was across all kinds of clients, all kinds of projects, but primarily locally based.

+ +

CHAD: And once we realized what it was going to take to build local businesses and make them successful, we refined that managing director position a lot. It wasn't one that we necessarily had in every studio, and so adding it or, in some cases, making the difficult decision to swap out the person in that with someone. Now that we understood what was necessary, making sure that someone in that position actually wanted that job and could do it. And that has been the journey we've been on; I would say for the past three or four years of making those changes, figuring it out so that when it was working well, each of the studios could work really well. And we've made a lot of progress with that.

+ +

But one of the problems we had, so we have all the individual studios, and then we have the corporate-level people which are myself and you, marketing people, operations supporting all of the studios. And one of the things that we've struggled with over the years is being consistently profitable as we've grown or primarily operating break-even, which historically we were very comfortable doing because the whole leadership and shareholder of thoughtbot and ownership all worked here. We care a lot about paying people as much as we can possibly do and having the greatest benefits we possibly can while staying sustainable. And so it wasn't an issue. We're not running the company to generate lots of profits that then go to some investors or shareholders. So operating breakeven wasn't historically a problem, where it started to become a problem is as we grew and grew, the numbers became large enough that when things didn't go like we were expecting and we were managing to break even, then we would be very unprofitable very quickly if something didn't go the way that we were expecting, and it started to put the company at risk. So we started to focus more on profitability. And one of the things that was hurting profitability is that we were maintaining these small teams with offices, and just the overhead of a small team across many different geographies added overhead, which made it harder to be profitable because we needed to do everything in each individual location.

+ +

LINDSEY: Right. So now, really getting into those big challenges that were pressuring us to rethink how we operate, profitability and margin was a big one, which once you look at the breakdown in the numbers, the overhead of having the different studios was one. I think that also bleeds into the MDs have really challenging positions. They're responsible for a lot: they're responsible for the happiness and fulfillment of their teams; they're doing business development; they're doing client management; they're in charge of their entire revenue sheet. So that was another area that I think over time, we were consistently looking at; how do we improve this role? How do we make it so that folks can be successful here?

+ +

CHAD: Well, you can imagine, too, that designers and developers at thoughtbot we were seeing a similar thing, which is in a lot of ways, thoughtbot is modeled around me and other early developers. And I would often tell people I really like a lot of variety. I like to be working on one client and have huge scaling problems and challenges that we’re working at and growing their business to a whole nother level. And I like rotating off of that. And I then like working with a startup where we’re building the first version of the product. And for some people, no doubt that is exciting and challenging but worth it. And same thing on the sales side for managing directors, like being able to know how to effectively communicate and sell to the needs of each of those different kinds of projects. It's totally doable, but it adds to a lot of effort and angst being spent on just always trying to do everything, both on the development side and the managing director side, and it's hard. And that was one of the challenges that we were hearing either explicitly, or in a lot of cases, I don't think people realized it was happening. Everyone at thoughtbot is amazing and is great and very high execution level and all that stuff. And when you start getting challenges or feedback about poor performance from a great performer, you start to question why is that? What's going on? And it's an unrealistic expectation to have someone work in as part of a large enterprise for six months and then next week have them working on a brand new startup MVP that's got to go to production in six weeks and necessarily expect them to on a dime be able to change their approach to managing that product and making sure that it's successful.

+ +

And like you said, we want to put people in a position where they can be as successful as possible in everything that they do and having good people spin their wheels even if it's not a performance problem -- if there's a level of interest or excitement for one kind of client over another, we have a system of collecting feedback about what you want to work on and rating the incoming projects. But the primary determinator for what project you work on was which one was starting at the time your other project was ending; that was the primary determiner. So people effectively had no choice about the kind of project that they would work on. And that was a common complaint that we heard from people is that lack of control.

+ +

LINDSEY: And even though it wasn't supposed to happen, I think people did have reputations for a specialty, and the managing directors or whoever was staffing a project would seek out certain folks for certain projects. So even though we'd like to think of everyone as being able to handle any kind of project, and at a basic level, they could for sure, people with specialties were sought out for things. So that was already happening organically.

+ +

CHAD: And related but even going deeper on it, when we're maintaining small groups of people that are a complete replica of everything that is thoughtbot, and it's a group of 9 to 25 people, that ability to specialize or to have a career path that extends -- The company you're a part of feels like a 20-person company, and in a 20-person company, there's naturally not going to be tons of room for a big career ladder and lots of advancement or specialization. You will trend towards having a team of people that are more generalized and less hierarchical.

+ +

LINDSEY: Were there any other big challenges that come to mind for you when we were going into, like, let's revisit how we're structured?

+ +

CHAD: Well, there was one that touched on all of what we just talked about, and that was design and thoughtbot. And this is one thing that's super interesting. And I think I've talked about it on the show before. But we started from day one as a design and development company. We've always done design, and we've always had people on staff that did it. And one of the things that happened, though, is being the first consulting company in the world to switch to Ruby on Rails and being a big contributor to that community, and building a reputation through our open-source and through our blog and everything on the development side, that part of the business has grown. The development team is much larger than the design team. And a lot of people in the world view thoughtbot as oh, they're a Rails development company and really it wasn’t -- What we've always talked about is Rails is in service of the products that we want to design and build and creating great products. And so design has consistently been a challenge over the years as the reputation there isn't as big as on the development side.

+ +

And so what we saw in the individual studios were each individual studio needed to have a certain number of designers in order to feel like it had a design team and to be able to service the work that it did have locally and a management structure within that team that made sense. It had all those problems that we've just talked about. It was difficult to be profitable. It was difficult to have enough locals work for the two or three designers that were in a studio. And that specialization for what they would do and the kinds of projects that they would work on didn't always match the actual work that we had in a particular city at a time. And so because we were organizing the work that we did geographically, it wasn't uncommon for a designer to not have client work to do and that hurt the design team because we were attracting these great designers. And people are at thoughtbot because they want to build great products; they want to do great work, and then they join the team, and they're not doing it. And so design turnover has been much higher than other parts of the company for that and other related reasons.

+ +

LINDSEY: Okay. So I have a question for you because you and Diana started on this process before I was involved. So for you, when did reorganization first start?

+ +

CHAD: Well, as I alluded to at the top of the show, we had been talking about these kinds of things for a while. And I think you were part of most of those discussions as part of the management team where it'd be like, oh, should we break out design? And there wasn't really this clear -- Our strategy for the last many years has been strong local studios bound together by a common purpose and values. And we were feeling pretty good about that strategy. So these problems would crop up, and we would evaluate them in the context of that strategy and say, “No, we're reaffirming our strategy.” So it wasn't until having gone through 2020 and looking towards what 2021 was going to be like and saying, “We've got all these things that could be better. But one thing we know that needs to change is we can't go through another year of everyone planning for all of this to be temporary and to be back to the way that we were before.” We had already been breaking down the geographic barriers of studios because many projects were being staffed across offices at a much higher level than ever was before. And we had given everybody the thumbs up to move wherever they wanted, and we were going to support it. And we had about 20 people move from places where we had a studio to places where we didn't. And so it was really that that crystallized the need to -- I didn't know exactly what we were going to do going into it, but this feeling we need to do something because we can't stay in this limbo state for another year, which is what we were predicting in terms of how long we were going to be in the current operating mode. And even when it does come back, we now have 20+ people who don't live where we have offices anymore. So we can't go through this next period of time expecting things to just go back to the way that they were. So that was when we knew that we were going to do it. So I guess that was at the end of November or the beginning of December of 2020.

+ +

LINDSEY: It was exciting to have this push to do it. As you mentioned, we talked about different options before. Like Joe had come up with, I remember, a really clever squad-based team proposal. We’d thrown around, “Should we do an industry-based team structure?” But I think what was really missing was a push, a driver, you know, you have to. Because it was “Everything else is kind of working okay the way it is. What if this is a big mistake?” And so we wouldn't move forward. So we had these major drivers to decide on something and then went into what I think is a really successful and fascinating series of brainstorming and iteration sessions pretty quickly as a leadership team to hone in on what we've ended up rolling out.

+ +

CHAD: And I think one of the things that I appreciated, and it was Diana who did this, was saying, “Let's make sure we reaffirm or revisit our values and purpose as part of this process.” And when you have a company that is driven by values and purpose, it's important when you're making big decisions to revisit them so that they're helping guide what you actually do so that you don't get off track. And we anticipated that the change was going to be big enough that maybe even the value -- We need to be open to the possibility that the value or the purpose would change or should change in the process or had already changed and we hadn't reflected them. And so that was a part of it, like expecting to go into it doing that. And then we can't have a...or maybe we could, but we decided it wasn't realistic to have a 100-person meeting. So again, for a lot of the things we do at thoughtbot, we treat thoughtbot like a product in and of itself. And we use the tools and techniques as designers and developers on that product itself. And so we did survey the team to get their thoughts around purpose and values and around what it had been like to work remotely and just a few questions in general about how they felt about projects and work and that kind of thing. And then, we took that information that we had gathered from the team into the design thinking and brainstorming sessions with the leadership team, which was the managing directors across all the studios and the design and development directors, and then the corporate leadership.

+ +

LINDSEY: And I'd say at the forefront of these exercises and decisions was how do we ensure thoughtboters are fulfilled? And also, how do we provide the most value to clients, and where those things intersect, how could we potentially reorganize ourselves? And these sessions are some of my favorite things to do, even though they can be maybe stressful times that are driving these exercises. But doing these kinds of really open brainstorming and design thinking exercises, problem-solving with our team, which is full of the smartest, most thoughtful, kindest people, I find incredibly fulfilling and really drive amazing outcomes. And I’m kind of sappy, I guess here. But I start to feel like, oh my gosh, I know why our clients love working with these folks. It's a really powerful exercise, and you come up with really amazing ideas and outcomes.

+ +

CHAD: Yeah. I had a thought as you were saying that, though, that I agree, but I think you could do exactly the same thing but not be committed to actually making a change. If you were just doing it, it would drive me crazy. [chuckles] And I think that that's an important component is that we went into it saying something is going to change; we don't know what it is. We define problems, and then we come up with solutions to those problems, and we are going to make a change. And that was the difference between the previous we're all sort of venting or trying to do it in a leadership meeting. And I think off-sites and brainstorming sessions and that kind of thing get a bad rap, but when they're actually necessary and when they're done well, and when you have a group of people that are committed to improvement and actually making a change, they can be really great.

+ +

LINDSEY: Yeah. And I think you all had set out a goal. You and Diana had set a goal schedule of how this would work, which is coming up with ideas as an extended leadership team which is maybe like 18 people. And doing that, we booked a half-day, maybe a bit more; obviously, this is all virtual. And we'd have different sessions where we were breaking out into smaller groups of maybe five people randomized each time and working through a specific challenge or coming up with a specific proposal, then reconvening as the extended leadership team and running through those proposals. So that would be the first individual day. And then you and Diana went off with those proposals and ideas to make some executive decisions around what you thought made sense and then re-proposed to the extended leadership team for feedback and iteration with the goal that every week we're getting closer to the final, final thing that we're going to roll out to the team. And also, by the way, how do we roll that out?

+ +

CHAD: I'm curious from your perspective how that worked because we didn't go into the process expecting it to work that way. Well, I guess we did. When Diana and I were planning it, though, we initially started from a different place, and then we realized this is going to be too difficult for a group to converge on, and it probably does need us to go and force a convergence basically and then go back and make a proposal. But I'm curious what you think about that.

+ +

LINDSEY: Oh, I think you absolutely have to do that.

+ +

CHAD: [chuckles] Okay.

+ +

LINDSEY: And that's the way I operate, too, even from a marketing perspective, is to take input and ideas and see what folks think. But at the end of the day, you can't make a group decision; someone has to make an executive decision based on what they've heard. So I thought that worked well. Plus, I was in the group that came up with the idea for the reorg we chose. I don't want to brag about it, but it was a great decision.

+ +

CHAD: [laughs]

+ +

LINDSEY: So yeah, I guess getting into what that actually was, what we ended up deciding and have moved forward with was breaking out the teams, so keeping a team-based structure but no longer geographically-based but actually each team based on the types of clients and client projects that they're providing services for. And obviously, those services are tailored to the type of client projects.

+ +

CHAD: Shall we go through them? [chuckles]

+ +

LINDSEY: Yeah, we should go through them.

+ +

CHAD: [chuckles] Okay.

+ +

LINDSEY: So the naming came after the fact, but we also had a lot of fun with branding and naming these teams and went all-in on the rocket theme, as you'll hear. So we've got four main service teams. The first one deals with the earliest stage products kind of pre-product so validating ideas, and that is thoughtbot Ignite. The next team deals with more MVP, V1 but not really a quick project, like longer MVP types of projects, and that is thoughtbot Lift Off. The third team deals with more established companies and teams who are elevating their product and teams to the next level that's thoughtbot Boost. And then finally, we've introduced more DevOps and maintenance services under thoughtbot Mission Control, and they also manage our PR reviews as a service, reviews by thoughtbot. So that's the quick overview of the four teams you've got Ignite, Lift Off, Boost, and Mission Control.

+ +

CHAD: And the interesting thing about the team structure and what each team was going to focus on is that once we made the decision that this was -- there wasn't really a lot of question around what those teams would be. We knew these different project types existed. It was something that we have documented, and it's in our marketing. We have positioning statements already. A lot of these client types were already created. We have an internal consulting class that people take, about 20 people a quarter take it. And it goes over the different kinds of clients that we work with and the different needs that they have and how to work with them. And it was split along these lines. Now there were some small details on the edges to be worked out, but what was difficult was making the decision to do this. Once we made the decision to do it, what those teams would be was pretty clear.

+ +

LINDSEY: Obviously, I love it. From a marketing perspective, breaking out these different types of clients makes so much sense. You're talking to them about different sets of needs, goals, pain points, so there's great focus and clarity there. And then that trickles to everyone's job. The managing directors now are responsible for one of these service-based teams. The designers and developers themselves are specializing and really enjoy that type of work. And in the breakout group during these brainstorming sessions that I was in, I remember when we were starting from this place of anything goes, I was asking the directors in my group, “What do you think makes our team fulfilled? Are they more interested in a specific industry? Are they more interested in a specific technology? Are they more interested in a type of client?” And the directors in my group all said, “I really think it is the type of project that provides fulfillment in different ways for different folks.” So we took that as a starting point, and then it was, “Okay, well, what are those different types of clients if we could put them into four or five buckets?”

+ +

CHAD: And Ignite and Lift Off are really interesting to me because it's a good example of where the lines can be effectively drawn. So you alluded to it already, Ignite is for the earliest of products and teams where the idea hasn't even been validated yet, and they need our help determining whether it even makes sense to proceed at all. And then when we do validate it, the size of what we're building and the speed at which we're going to be able to get to market falls under 12 weeks. It will typically fall in the 8 to 10-week range where we've gone from that concept that we validated to a launch product in the hands of users. And they’re ruthlessly prioritized. They're usually pretty straightforward, both on the tech side but also in what we need to build. And I think one mistake we've made in the past is taking large finance and healthcare companies and these large companies that we also work with and trying to do the same thing that we do for those Ignite clients for them and ending up in a place where maybe we haven't done as good a job, or the project doesn't go as well because we're trying to squeeze it into a place where it doesn't fit. And that's what Lift Off is; it’s creating a space where it fits, realizing that a client who comes to us with this massive need it's not massive because they're doing too much. It's massive because they have a big problem that they want to solve, usually for a business that already exists, and it's a new product within that business. Maybe they've even already validated it. And the integrations that it's going to have, the systems it needs to talk to, the level of scale that it's going to have is different than is going to be possible in 8 to 12 weeks. And when we try to squeeze it in there, it's not going to be successful. So Lift-Off is giving a space for those projects to thrive in a way.

+ +

And I also think it's one of those things where it's going to have an impact on our sales too because what would happen previously is that one of those clients might come to us and we're furiously trying to squeeze it down. And how a client perceives that is potentially like, “Oh, they don't know how to do what we need them to do, or they don't want to do it. Or they think our idea is bad because they're saying we need to validate it, and we've already validated it. We have an existing business that we're building this off of,” or something like that. And it causes us to lose that work, which we would otherwise love to have. And now a client like that comes and is talking to a managing director who gets the needs of that kind of project and a team of people that are going to work on it that understand that there's a process to run through and it's going to take six months or a year. We're going to launch along the way, and then we're going to continue to grow the product from there. It's just a different feeling all around, which I think is going to have a positive impact on our ability to actually grow those parts of the business.

+ +

LINDSEY: And Lift Off by nature of working on those health, tech, and financial products is also dealing with highly regulated spaces, which is another reason why those projects are necessarily longer and more complex and lend themselves well to someone who's dealt with it before.

+ +

CHAD: Right. Another thing, and we touched on this a little bit earlier with Boost, is a big part of our business historically is that those clients that have built-in Rails along the way, they've built a super successful business. They're scaling a lot. They're growing their team. They need technical leadership, experience mentorship, and those projects tend to be very development-heavy as well. Like, we have clients where we have four or five developers working with them and no designers, and it caused the design and the development team to be very lopsided. But we really liked that work, and it's very valuable to clients. And so same thing with Boost, Boost instead of that being something which is pushed off into the back where like, oh, well, it's not the project-based integrated team of designers and developers launching a new product, and so it's not our ideal work. It gives a space where that can be our ideal work, and the kinds of people who want to work on those kinds of projects with that level of experience and need feel like they are able to do that on a team that is focused on that. And that team doesn't necessarily need to have a design team that works or looks the same as every other place at thoughtbot. And it creates a place which can focus on what it needs to do in the best way possible that is the most fulfilling to the team and success for the customers. And it looks different than thoughtbot has historically looked, and that's okay. Because actually, when you pick it apart, it's not that different; it’s just taking the 20% of all of the thoughtbot studios where the 20% felt like something that wasn't quite right and putting it all together to make 100% of something that feels right.

+ +

LINDSEY: And from the design perspective, Boost design is a lot around optimizing what already is in place or helping take care of design debt that's been neglected, making sure design and development are talking to each other and thinking about those processes to make them talk to each other better. Whereas Lift Off and Ignite are more introducing design or design processes or design frameworks like putting your design system together or thinking about your accessibility processes, those kinds of activities. And then Mission Control is probably the newest to thoughtbot in terms of services that we're offering clients.

+ +

CHAD: And within Mission Control, there are two big areas that are different, so the first is maintenance. So we historically have been project-based at thoughtbot. And what that would mean is that well, it doesn't necessarily mean -- So historically, project-based plus everyone working on one project at a time, I think the combination of those two things meant that what we mostly did was we help people set up their own team of people who are going to take over from what we had done after we launched the first version of the product and level it up from there. And most of our clients got to the point where the goal was to become self-sufficient. And we also would meet people who had already built something and were just looking for our expertise to help take care of it but not necessarily have enough work for someone full-time. And for both of those clients, we didn't really have a solution for them. And so that's where the maintenance team in Mission Control comes into play because it's a team of people who have opted into splitting their time across multiple clients. The contracts are different where they're paying a monthly recurring maintenance fee for us to take care of certain things every month: security upgrades, patches, small bug fixes, and features. Maybe they even have a team on staff where they're doing the majority of the development work, but they just want our support in helping things go well.

+ +

And also, you mentioned the pull request review service that's within Mission Control as well where we have a separate service where you can sign up, and you just request a pull request review from thoughtbot, and then one of our team members goes on and gives you feedback on that pull request. So that's one part of what's happening in Mission Control is that maintenance work. And then the other is DevOps, and infrastructure is an area where the majority of projects that we worked on across all of thoughtbot were deployed to Heroku or the teams had their own DevOps and infrastructure people and creating a specialization of that for a handful of projects for an individual studio that has that need, over the course of a year, never made sense. But once we started to do it and we took a more global view to it and said, “Across all of our clients, what is the need either met or unmet and what might we be able to do? And where is the interest of our team?” It became clear we could offer -- like, our clients need us to do this sometimes. And for the clients who need us to do it, we want to be there for them. We want to do it. And creating a team of people that is global, that can do it across time zones 24/7 is also one of the needs of the clients, and having that team span those geographies is one way we've been able to do that when historically we would have shied away from that.

+ +

LINDSEY: And speaking of the team's interest in different areas, different services for the rollout of this new organization, we, by and large, had folks opt in to what they wanted to do even as far as the managing directors picking what team that they were going to head up.

+ +

CHAD: So we said, “These are what the teams are going to be,” and we did a company-wide presentation. And then, we asked people to submit their first and second choice. And then we made the decision around which of the managing directors were going to do what and then we announced that to everybody. Am I saying this the right way? Did we announce the managing directors before we asked everybody or just before the deadline was up?

+ +

LINDSEY: I think it was trickled in. At first, it was “What team do you want to be on?” But then, as that's going on behind the scenes, you and Diana are having discussions with the managing directors around where they want to be. And then, as that information became available, you shared that with the team also to help with decisions, same with the design and development directors. I think it was announced the design and development directors chose the teams they wanted to be on and lead. And then, once that was finalized, that was also shared with the team as they're voting on where they want to head.

+ +

CHAD: And the majority of people got their first choice and the majority of people the person who was their manager also chose a similar choice. And so there was a lot of change but not too much churn, I guess is the way I would put it. We were able to do it in a way which I think people felt like they had a choice. And I think going into it; people were afraid of that like okay, am I going to make a choice here and then end up on a team of people I've never worked with before? That was not the case. Now there's certainly a big blending of the teams, particularly Boston and New York were the biggest studios. And so they make up the majority of the people in each of the Boost and Lift Off. But people are working with people that they have worked with before.

+ +

LINDSEY: And it turns out the people they didn't work with before are also awesome, also, very cool.

+ +

CHAD: [chuckles] So much effort over the years spent -- that strategy of replicating what was great about thoughtbot into other geographies is true. And so the standards that we had for hiring, and the kinds of people we hire, and the screening for values fit, and all that stuff led us to a place where everyone at thoughtbot is great. And so I wasn't really concerned about that, but other people may have been because there's always a fear of the unknown.

+ +

LINDSEY: Yeah, definitely. I'm trying to think if there were other rollout things that might be interesting.

+ +

CHAD: Well, one of the interesting things it's a little in the details. On the surface, that is the team, and those are the services we offer. But we also needed to contend with the fact that we are in the U.S. and the UK, and we didn't really feel like it makes sense to have those teams span 10+ time zones, that that would be too far of a stretch. And it would affect people's fulfillment on the team as well as the services we are able to deliver. So these services that we offer are actually fulfilled by two…do we have a word for it? [chuckles]

+ +

LINDSEY: Geographies?

+ +

CHAD: Geographies, yeah, I guess.

+ +

LINDSEY: There are two geographies that we ended up naming Launchpad 1 and Launchpad 2, because rockets.

+ +

CHAD: So Launchpad 1 is all of the Americas, and Launchpad 2 is Europe, Middle East, and Africa. And so they provide all of those services in those places. But they have teams that are formed across the whole geographic region. And then eventually, if all goes well, we'll have Launchpad 3, and that'll be [chuckles] the other side of the world.

+ +

LINDSEY: I've got the icon ready and waiting. So I guess timing-wise, this all happened...rollout was by the beginning of the year, right? January?

+ +

CHAD: Yeah. One of the things is more people took more time off between the December Holidays and New Year's and everything than they have ever done before, and we needed it. Everyone needed it. So we weren't able to finalize what team everyone was on and have a conversation about that with everybody before they saw it in a message somewhere, which we really wanted to do. So we ended up not being able to finish all of that before the end of the year. And so it rolled into the first couple of weeks of January as people came back, and we were able to talk to them. And then I think we made the internally public announcements about all the teams that everyone was going to be on, and we did a formal kickoff. What was it? January 8th or something like that.

+ +

LINDSEY: Yeah. And I think that's actually a really good point to bring up is the communication to the individuals. It was important for them to hear it one-on-one from their manager before anything was announced more broadly and then to transition to their team if their manager was changing, which in a lot of cases, it didn't, but sometimes it did. Having one-on-one-on-one transition meetings to really ease that move was also important to not make this really abrupt and unnecessarily stressful in a time that is already very stressful for reasons we know.

+ +

CHAD: And even if someone's direct manager wasn't changing, it was very likely that their director would change. And so, in those cases, we still did a one-on-one-on-one, but it was with the new director sitting in as well as a skip-level one-on-one on-one. And we did it quickly, but it was important to make it happen quickly.

+ +

LINDSEY: And it was also important to not abruptly change on the clients because obviously, we weren't doing a full stop of client work just because we're doing some reshuffling internally. So that was phased, and we didn't even really make it a big deal to the clients because that probably would have just added confusion as we were making these changes.

+ +

CHAD: Yeah, definitely. And we made the decision that we weren't going to just arbitrarily say, “This person is now on this team; therefore, they have to leave this project,” so we made that decision. And we have as natural points in the project for a rotation to happen. People will move to a project; if there's a mismatch between the project that they're on and the team that they're on, they'll move at a natural point. But the reality was that a lot of people also chose -- It's not like we have 57 different project types; we have three. And so a lot of people were already working on the project type that they chose just because the odds were good that they were. There's been very little customer-facing impact to it. So it's early days. It's March now, so it's been a couple of months. But how do you think it's going, or where do you think the growing pains are?

+ +

LINDSEY: Good question. I think there's been more of a smooth transition than there have been growing pains, first of all, which has been nice. I think folks have been pleasantly surprised by really enjoying their new teams and new team members. I think growing pains-wise, on the operations side, obviously we've had to...I think we’re still in the process of figuring out how to best pipe certain kinds of inquiries into the right team and managing director. Sometimes it's a no-brainer. They're like, “I need to validate this idea.” It's like boom, “You're off to Dawn for Ignite, and you’re going to have a conversation there.” But if they come in and they say, “I'm working on an MVP, and we don't know if that MVP is one of the really fast ones or one of the more complex ones,” then it's like, okay, is this going to Dawn or Emily?

+ +

CHAD: And we historically didn't need to have any handoffs because one person was able…one person and team; it was based on geography. So we knew exactly who was going to be having that conversation with them. So operationally, it's actually one thing we didn't touch. So no one was let go in this big reorg. There was a position for everyone, I guess, if they wanted it. But one area we haven't touched on is anyone who was local, who was in a support role moved up into the corporate level in a support or operations role. And there weren't that many of those people, but the office manager in Boston is now full-time in people operations. And the office manager in New York City is now the operations manager for the whole team, the whole company. Kelly, who was doing business development just in Boston, is now helping across all of thoughtbot, which is really good at using her skill set across the whole company. I think that that's good.

+ +

And now, like you said, figuring out how to support everyone across the teams is a little bit of whether it be the operations manager figuring out how to get people computers when we hire new people to like what you were saying around inquiries coming in and making sure that they're sent to the right person. The thing that has made it more challenging for me is that just a confluence of events at the time where we were making some of these changes. And now it has made my involvement different than I was originally expecting them to be. I expected to be a little bit more involved in certain things, but because I've been pulled into several important client projects and was working on client work at the time that then expanded very rapidly, it's been challenging for me to manage the workload. But in some ways, there's a bright side to it, which is it's giving other people the space to operate without me, which I think can be good because I'm very confident in what everyone's bringing to the table. And when you go through a big period of change like this, if everyone was deferring to what I thought as the founder or looking for me for answers or permission to do something, I think that we would suffer for it. And so being forced in a way to not be available for everything that's going on is a way for people to have more ownership over it and not be relying on me, and I know that they can do it.

+ +

LINDSEY: Cool.

+ +

CHAD: So we never said what the new purpose was. So maybe we'll just talk a little bit about that, and then we'll use that as a wrapping up point.

+ +

LINDSEY: Sounds good.

+ +

CHAD: So I mentioned earlier our purpose had been we believe that there's a better way to work. There's always a better way to work, and we want to find it and share it with as many people as possible. We had written down that purpose several years ago, like a decade ago, I think. And I believe a good purpose describes what is the underlying motivation for the company and the people at it. And when we did that survey of people, a few of the questions we asked touched on it. And it wasn't that surprising to me about -- one of the threads in that was this idea of positive contributions to the world, making sure that the things that we work on and do have positive contributions to the world and that being a motivating factor. Like, that's part of what makes the team tick and what they want to be doing and are fulfilled by and that kind of thing. And so we incorporated that into the purpose. And so we adjusted the wording a little bit to make that incorporation, but we ended up that we believe that it's always possible to continuously learn and improve the way people work while building higher quality products that make positive contributions to the world.

+ +

This resonated with me in a way that -- it's a little bit more wordy, and that's not why it resonates with me. [chuckles] Specifically, our previous purpose of we believe that there's always a better way to work and we want to find it and share it with as many people as possible lacked one thing that I think a good purpose can incorporate, which is what is a clear idea of what the alternative is like, what you're fighting against, or what you're trying to improve. It's there in the previous purpose. So, in theory, there maybe are people out there who believe that there's not always a better way to work that they've achieved it or something like that or that they have particular practices which aren't great. But it's not explicit or really even implicit in the purpose. And the new purpose we believe that it's possible to continuously learn and improve the way people work while building higher quality products and make positive contributions to the world. You can point to someone who might believe the opposite of that, that you can't build higher quality products that make positive contributions to the world while also continuously learning and improving the way that you work and everything, that to build higher quality products or make positive contributions to the world, you might need to compromise on the values of continuous improvement and learning. And our new purpose makes a statement that you don't need to compromise in order to achieve that result, and I like that about it.

+ +

LINDSEY: I really like the addition of talking about the kinds of positive products because I think once you know thoughtbot at all, you know that that's underlying the purpose but take out the guesswork, just tell the folks. All right. Well, I think that's a good place to stop. I'm glad we didn't even go into the remote because there's obviously a lot to talk about.

+ +

CHAD: Yeah. So we'll talk about that next time?

+ +

LINDSEY: Yeah. We're going to talk about what changes we've made in going completely remote and what that looks like, what we think it looks like for the future.

+ +

CHAD: Cool.

+ +

LINDSEY: So you can subscribe to the show and find notes for this episode at giantrobots.fm

+ +

CHAD: If you have questions or comments, and we'd love to hear them, email us at hosts@giantrobots.fm, or you can find me on Twitter @cpytel.

+ +

LINDSEY: And you can find me on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot.

+ +

CHAD: It's good to be back. Thanks for listening and see you next time.

+ +

LINDSEY: It's so good to be back. Stay tuned.

+ +

This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey take listeners behind the scenes and go deep into the nitty-gritty of recent thoughtbot company changes driven by the pandemic and the organization's need (and desire!) to go fully remote – all while reaffirming and revisiting the organization's values, mission, and purpose as part of the process.

+ +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD PYTEL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel.

+ +

LINDSEY CHRISTENSEN: And I'm your other host, Lindsey Christensen. And we're back. Thanks for tuning in.

+ +

CHAD: We've missed you.

+ +

LINDSEY: Yes. We’ve been kind of busy.

+ +

CHAD: We've been busy, and we knew we were going to take a break after the last season. We didn't necessarily know for quite how long, and then a whole bunch of stuff happened, which we're going to tell you about today. From the last episode, you heard about the change to the thoughtbot CEO, and we alluded to some changes that we've made to the company. And we're going to talk about those today.

+ +

LINDSEY: Yeah. And in true thoughtbot Giant Robots fashion, we’ll go behind the scenes and give you the nitty-gritty of why things happened and how it's going because it's all really interesting.

+ +

CHAD: Yeah. I think on the surface, it's really easy to think about how maybe these changes have been entirely driven by the need to go remote or the desire to go remote. And the reality was that's an important part of it, but it really was so much more than that. Some of these changes that we've made are ones we've been talking about for a long time. And it wasn't until almost a year of operating in a different way that we said, “We need to make some of these changes in order to accommodate remote and working from anywhere.” And we fell back on a lot of other problems we needed to solve along the way.

+ +

LINDSEY: So we actually decided to break out remote work into its own episode, which will be the next episode. And I'm sure it's going to come up today, but it's a whole other area of changes and focus, whereas some of the reorg changes that we just underwent solved a lot or are trying to solve a number of challenges that we've been working on over the years. So I guess to start off, before we reorganized, how did we function? And that was largely geographically based.

+ +

CHAD: Yeah. And the geographic basis means that we had a studio in a city, and in that studio, we offered the complete thoughtbot services. And that was driven by this idea back in 2012 when we started to expand. Prior to that, we really held the company to less than 30 people. And we were primarily a group of people all in one location working together, and we were all of what thoughtbot was. And we really liked that. We liked the structure. But people wanted to move and live somewhere else. And our purpose is that we believe that there's a better way to work. And we want to share it with as many people as possible, although we've revised that purpose now as part of this process. And so I really remember the day we were having a company meeting, and someone stood up and said, “If we really believe we have a better way to work, why are we not trying to bring it to more people? Why are we losing these great team members only because they want to live somewhere else?” But we also really liked the small, close-knit team of people who worked closely together on client work. We had done some client projects that were split across teams and across time zones and that kind of stuff. And it just didn't feel as good as we wanted it to feel, especially because it was hybrid.

+ +

And so we said, “We know exactly what a great thoughtbot looks like. Instead of trying to expand what that great thoughtbot looks like, let's try to replicate it instead.” And so when someone wanted to move to a new city, we said, “That’s great.” We looked at the market in the city that they were moving to and said, “Let's grow another thoughtbot around them and use that as the starting point for a new thoughtbot studio that would be a full design and development team that offers and works with all the different kinds of clients that we work with.” And that was the model which brought us to being in six cities in the UK and in the U.S. and about 100 people working with a whole bunch of clients every year across those. But for the individual person working at thoughtbot, individual designer or developer, it felt very much like thoughtbot had always felt, which was you were working with a team of three or four other people directly on that client. Oftentimes, the client would be in the same city as you. And when we could meet face-to-face with people, they'd be working in our office, and we'd be working really closely with them.

+ +

LINDSEY: Another interesting element of that structure was the marketing, and community was also very locally based, so engaging in and hosting local meetups. Actually, all of our offices -- We had offices, first of all, in amazing locations in all of these tech hub cities, and all the offices additionally had space for specifically events and community type of activities. And we thought a lot about nurturing local community, creating local partnerships. Obviously, we're thinking a lot about the hiring pool, and nurturing potential future hires in those cities as well.

+ +

CHAD: Yeah, and that's what we had done in Boston where we got started, and it's very fulfilling to be part of your local community. And we wanted to embrace that as we grew. And for a good while, it worked pretty well. We were certainly able to grow quickly once we decided to do it. A lot of people who listened to the podcast a long time will recognize that we actually at one point had ten cities, some of which were pretty established and other ones which we were expanding into. And we learned a lot along the way about how much harder it is to build a local business than we originally were anticipating it would be. One of the things that we learned, and I've talked about this on the podcast in the past, is that with our reputation in the design and development community, we could often go into a major city and have a great first year because there was a lot of pent up demand for people who wanted to work with us, work at the company and as our clients. And that really led us astray in the beginning because we would go into -- We were expanding in three or four cities in the same year, and they were all super successful. So we were hiring teams to do all the work that we had. What we weren't doing was all the legwork we needed to do to build a sustainable local business. And so after the first batch of clients or the first batch and a half of clients we were done working with, we didn't have a sustainable pipeline of new local clients coming in. And so we learned a lot about how much we actually need to do when going into a new city to not only have that great first year but to have a great fifth year. And so we had a few failures where we had to close some studios just because we couldn't afford to operate them profitably, and that was pretty painful. I forget the episode numbers where we talked about it in the past, but we have. You can go back and listen to it. We can link them in the show notes.

+ +

LINDSEY: In addition to having the designers and the developers in the local studios, at least in recent years, we also had the structure that each city studio had a managing director. And a lot of those managing directors actually came from design and development themselves, but they were in charge of everything local including, and especially the sale, so finding new clients, onboarding them, the actual profitability of their studio, hiring. And again, as you mentioned, that was across all kinds of clients, all kinds of projects, but primarily locally based.

+ +

CHAD: And once we realized what it was going to take to build local businesses and make them successful, we refined that managing director position a lot. It wasn't one that we necessarily had in every studio, and so adding it or, in some cases, making the difficult decision to swap out the person in that with someone. Now that we understood what was necessary, making sure that someone in that position actually wanted that job and could do it. And that has been the journey we've been on; I would say for the past three or four years of making those changes, figuring it out so that when it was working well, each of the studios could work really well. And we've made a lot of progress with that.

+ +

But one of the problems we had, so we have all the individual studios, and then we have the corporate-level people which are myself and you, marketing people, operations supporting all of the studios. And one of the things that we've struggled with over the years is being consistently profitable as we've grown or primarily operating break-even, which historically we were very comfortable doing because the whole leadership and shareholder of thoughtbot and ownership all worked here. We care a lot about paying people as much as we can possibly do and having the greatest benefits we possibly can while staying sustainable. And so it wasn't an issue. We're not running the company to generate lots of profits that then go to some investors or shareholders. So operating breakeven wasn't historically a problem, where it started to become a problem is as we grew and grew, the numbers became large enough that when things didn't go like we were expecting and we were managing to break even, then we would be very unprofitable very quickly if something didn't go the way that we were expecting, and it started to put the company at risk. So we started to focus more on profitability. And one of the things that was hurting profitability is that we were maintaining these small teams with offices, and just the overhead of a small team across many different geographies added overhead, which made it harder to be profitable because we needed to do everything in each individual location.

+ +

LINDSEY: Right. So now, really getting into those big challenges that were pressuring us to rethink how we operate, profitability and margin was a big one, which once you look at the breakdown in the numbers, the overhead of having the different studios was one. I think that also bleeds into the MDs have really challenging positions. They're responsible for a lot: they're responsible for the happiness and fulfillment of their teams; they're doing business development; they're doing client management; they're in charge of their entire revenue sheet. So that was another area that I think over time, we were consistently looking at; how do we improve this role? How do we make it so that folks can be successful here?

+ +

CHAD: Well, you can imagine, too, that designers and developers at thoughtbot we were seeing a similar thing, which is in a lot of ways, thoughtbot is modeled around me and other early developers. And I would often tell people I really like a lot of variety. I like to be working on one client and have huge scaling problems and challenges that we’re working at and growing their business to a whole nother level. And I like rotating off of that. And I then like working with a startup where we’re building the first version of the product. And for some people, no doubt that is exciting and challenging but worth it. And same thing on the sales side for managing directors, like being able to know how to effectively communicate and sell to the needs of each of those different kinds of projects. It's totally doable, but it adds to a lot of effort and angst being spent on just always trying to do everything, both on the development side and the managing director side, and it's hard. And that was one of the challenges that we were hearing either explicitly, or in a lot of cases, I don't think people realized it was happening. Everyone at thoughtbot is amazing and is great and very high execution level and all that stuff. And when you start getting challenges or feedback about poor performance from a great performer, you start to question why is that? What's going on? And it's an unrealistic expectation to have someone work in as part of a large enterprise for six months and then next week have them working on a brand new startup MVP that's got to go to production in six weeks and necessarily expect them to on a dime be able to change their approach to managing that product and making sure that it's successful.

+ +

And like you said, we want to put people in a position where they can be as successful as possible in everything that they do and having good people spin their wheels even if it's not a performance problem -- if there's a level of interest or excitement for one kind of client over another, we have a system of collecting feedback about what you want to work on and rating the incoming projects. But the primary determinator for what project you work on was which one was starting at the time your other project was ending; that was the primary determiner. So people effectively had no choice about the kind of project that they would work on. And that was a common complaint that we heard from people is that lack of control.

+ +

LINDSEY: And even though it wasn't supposed to happen, I think people did have reputations for a specialty, and the managing directors or whoever was staffing a project would seek out certain folks for certain projects. So even though we'd like to think of everyone as being able to handle any kind of project, and at a basic level, they could for sure, people with specialties were sought out for things. So that was already happening organically.

+ +

CHAD: And related but even going deeper on it, when we're maintaining small groups of people that are a complete replica of everything that is thoughtbot, and it's a group of 9 to 25 people, that ability to specialize or to have a career path that extends -- The company you're a part of feels like a 20-person company, and in a 20-person company, there's naturally not going to be tons of room for a big career ladder and lots of advancement or specialization. You will trend towards having a team of people that are more generalized and less hierarchical.

+ +

LINDSEY: Were there any other big challenges that come to mind for you when we were going into, like, let's revisit how we're structured?

+ +

CHAD: Well, there was one that touched on all of what we just talked about, and that was design and thoughtbot. And this is one thing that's super interesting. And I think I've talked about it on the show before. But we started from day one as a design and development company. We've always done design, and we've always had people on staff that did it. And one of the things that happened, though, is being the first consulting company in the world to switch to Ruby on Rails and being a big contributor to that community, and building a reputation through our open-source and through our blog and everything on the development side, that part of the business has grown. The development team is much larger than the design team. And a lot of people in the world view thoughtbot as oh, they're a Rails development company and really it wasn’t -- What we've always talked about is Rails is in service of the products that we want to design and build and creating great products. And so design has consistently been a challenge over the years as the reputation there isn't as big as on the development side.

+ +

And so what we saw in the individual studios were each individual studio needed to have a certain number of designers in order to feel like it had a design team and to be able to service the work that it did have locally and a management structure within that team that made sense. It had all those problems that we've just talked about. It was difficult to be profitable. It was difficult to have enough locals work for the two or three designers that were in a studio. And that specialization for what they would do and the kinds of projects that they would work on didn't always match the actual work that we had in a particular city at a time. And so because we were organizing the work that we did geographically, it wasn't uncommon for a designer to not have client work to do and that hurt the design team because we were attracting these great designers. And people are at thoughtbot because they want to build great products; they want to do great work, and then they join the team, and they're not doing it. And so design turnover has been much higher than other parts of the company for that and other related reasons.

+ +

LINDSEY: Okay. So I have a question for you because you and Diana started on this process before I was involved. So for you, when did reorganization first start?

+ +

CHAD: Well, as I alluded to at the top of the show, we had been talking about these kinds of things for a while. And I think you were part of most of those discussions as part of the management team where it'd be like, oh, should we break out design? And there wasn't really this clear -- Our strategy for the last many years has been strong local studios bound together by a common purpose and values. And we were feeling pretty good about that strategy. So these problems would crop up, and we would evaluate them in the context of that strategy and say, “No, we're reaffirming our strategy.” So it wasn't until having gone through 2020 and looking towards what 2021 was going to be like and saying, “We've got all these things that could be better. But one thing we know that needs to change is we can't go through another year of everyone planning for all of this to be temporary and to be back to the way that we were before.” We had already been breaking down the geographic barriers of studios because many projects were being staffed across offices at a much higher level than ever was before. And we had given everybody the thumbs up to move wherever they wanted, and we were going to support it. And we had about 20 people move from places where we had a studio to places where we didn't. And so it was really that that crystallized the need to -- I didn't know exactly what we were going to do going into it, but this feeling we need to do something because we can't stay in this limbo state for another year, which is what we were predicting in terms of how long we were going to be in the current operating mode. And even when it does come back, we now have 20+ people who don't live where we have offices anymore. So we can't go through this next period of time expecting things to just go back to the way that they were. So that was when we knew that we were going to do it. So I guess that was at the end of November or the beginning of December of 2020.

+ +

LINDSEY: It was exciting to have this push to do it. As you mentioned, we talked about different options before. Like Joe had come up with, I remember, a really clever squad-based team proposal. We’d thrown around, “Should we do an industry-based team structure?” But I think what was really missing was a push, a driver, you know, you have to. Because it was “Everything else is kind of working okay the way it is. What if this is a big mistake?” And so we wouldn't move forward. So we had these major drivers to decide on something and then went into what I think is a really successful and fascinating series of brainstorming and iteration sessions pretty quickly as a leadership team to hone in on what we've ended up rolling out.

+ +

CHAD: And I think one of the things that I appreciated, and it was Diana who did this, was saying, “Let's make sure we reaffirm or revisit our values and purpose as part of this process.” And when you have a company that is driven by values and purpose, it's important when you're making big decisions to revisit them so that they're helping guide what you actually do so that you don't get off track. And we anticipated that the change was going to be big enough that maybe even the value -- We need to be open to the possibility that the value or the purpose would change or should change in the process or had already changed and we hadn't reflected them. And so that was a part of it, like expecting to go into it doing that. And then we can't have a...or maybe we could, but we decided it wasn't realistic to have a 100-person meeting. So again, for a lot of the things we do at thoughtbot, we treat thoughtbot like a product in and of itself. And we use the tools and techniques as designers and developers on that product itself. And so we did survey the team to get their thoughts around purpose and values and around what it had been like to work remotely and just a few questions in general about how they felt about projects and work and that kind of thing. And then, we took that information that we had gathered from the team into the design thinking and brainstorming sessions with the leadership team, which was the managing directors across all the studios and the design and development directors, and then the corporate leadership.

+ +

LINDSEY: And I'd say at the forefront of these exercises and decisions was how do we ensure thoughtboters are fulfilled? And also, how do we provide the most value to clients, and where those things intersect, how could we potentially reorganize ourselves? And these sessions are some of my favorite things to do, even though they can be maybe stressful times that are driving these exercises. But doing these kinds of really open brainstorming and design thinking exercises, problem-solving with our team, which is full of the smartest, most thoughtful, kindest people, I find incredibly fulfilling and really drive amazing outcomes. And I’m kind of sappy, I guess here. But I start to feel like, oh my gosh, I know why our clients love working with these folks. It's a really powerful exercise, and you come up with really amazing ideas and outcomes.

+ +

CHAD: Yeah. I had a thought as you were saying that, though, that I agree, but I think you could do exactly the same thing but not be committed to actually making a change. If you were just doing it, it would drive me crazy. [chuckles] And I think that that's an important component is that we went into it saying something is going to change; we don't know what it is. We define problems, and then we come up with solutions to those problems, and we are going to make a change. And that was the difference between the previous we're all sort of venting or trying to do it in a leadership meeting. And I think off-sites and brainstorming sessions and that kind of thing get a bad rap, but when they're actually necessary and when they're done well, and when you have a group of people that are committed to improvement and actually making a change, they can be really great.

+ +

LINDSEY: Yeah. And I think you all had set out a goal. You and Diana had set a goal schedule of how this would work, which is coming up with ideas as an extended leadership team which is maybe like 18 people. And doing that, we booked a half-day, maybe a bit more; obviously, this is all virtual. And we'd have different sessions where we were breaking out into smaller groups of maybe five people randomized each time and working through a specific challenge or coming up with a specific proposal, then reconvening as the extended leadership team and running through those proposals. So that would be the first individual day. And then you and Diana went off with those proposals and ideas to make some executive decisions around what you thought made sense and then re-proposed to the extended leadership team for feedback and iteration with the goal that every week we're getting closer to the final, final thing that we're going to roll out to the team. And also, by the way, how do we roll that out?

+ +

CHAD: I'm curious from your perspective how that worked because we didn't go into the process expecting it to work that way. Well, I guess we did. When Diana and I were planning it, though, we initially started from a different place, and then we realized this is going to be too difficult for a group to converge on, and it probably does need us to go and force a convergence basically and then go back and make a proposal. But I'm curious what you think about that.

+ +

LINDSEY: Oh, I think you absolutely have to do that.

+ +

CHAD: [chuckles] Okay.

+ +

LINDSEY: And that's the way I operate, too, even from a marketing perspective, is to take input and ideas and see what folks think. But at the end of the day, you can't make a group decision; someone has to make an executive decision based on what they've heard. So I thought that worked well. Plus, I was in the group that came up with the idea for the reorg we chose. I don't want to brag about it, but it was a great decision.

+ +

CHAD: [laughs]

+ +

LINDSEY: So yeah, I guess getting into what that actually was, what we ended up deciding and have moved forward with was breaking out the teams, so keeping a team-based structure but no longer geographically-based but actually each team based on the types of clients and client projects that they're providing services for. And obviously, those services are tailored to the type of client projects.

+ +

CHAD: Shall we go through them? [chuckles]

+ +

LINDSEY: Yeah, we should go through them.

+ +

CHAD: [chuckles] Okay.

+ +

LINDSEY: So the naming came after the fact, but we also had a lot of fun with branding and naming these teams and went all-in on the rocket theme, as you'll hear. So we've got four main service teams. The first one deals with the earliest stage products kind of pre-product so validating ideas, and that is thoughtbot Ignite. The next team deals with more MVP, V1 but not really a quick project, like longer MVP types of projects, and that is thoughtbot Lift Off. The third team deals with more established companies and teams who are elevating their product and teams to the next level that's thoughtbot Boost. And then finally, we've introduced more DevOps and maintenance services under thoughtbot Mission Control, and they also manage our PR reviews as a service, reviews by thoughtbot. So that's the quick overview of the four teams you've got Ignite, Lift Off, Boost, and Mission Control.

+ +

CHAD: And the interesting thing about the team structure and what each team was going to focus on is that once we made the decision that this was -- there wasn't really a lot of question around what those teams would be. We knew these different project types existed. It was something that we have documented, and it's in our marketing. We have positioning statements already. A lot of these client types were already created. We have an internal consulting class that people take, about 20 people a quarter take it. And it goes over the different kinds of clients that we work with and the different needs that they have and how to work with them. And it was split along these lines. Now there were some small details on the edges to be worked out, but what was difficult was making the decision to do this. Once we made the decision to do it, what those teams would be was pretty clear.

+ +

LINDSEY: Obviously, I love it. From a marketing perspective, breaking out these different types of clients makes so much sense. You're talking to them about different sets of needs, goals, pain points, so there's great focus and clarity there. And then that trickles to everyone's job. The managing directors now are responsible for one of these service-based teams. The designers and developers themselves are specializing and really enjoy that type of work. And in the breakout group during these brainstorming sessions that I was in, I remember when we were starting from this place of anything goes, I was asking the directors in my group, “What do you think makes our team fulfilled? Are they more interested in a specific industry? Are they more interested in a specific technology? Are they more interested in a type of client?” And the directors in my group all said, “I really think it is the type of project that provides fulfillment in different ways for different folks.” So we took that as a starting point, and then it was, “Okay, well, what are those different types of clients if we could put them into four or five buckets?”

+ +

CHAD: And Ignite and Lift Off are really interesting to me because it's a good example of where the lines can be effectively drawn. So you alluded to it already, Ignite is for the earliest of products and teams where the idea hasn't even been validated yet, and they need our help determining whether it even makes sense to proceed at all. And then when we do validate it, the size of what we're building and the speed at which we're going to be able to get to market falls under 12 weeks. It will typically fall in the 8 to 10-week range where we've gone from that concept that we validated to a launch product in the hands of users. And they’re ruthlessly prioritized. They're usually pretty straightforward, both on the tech side but also in what we need to build. And I think one mistake we've made in the past is taking large finance and healthcare companies and these large companies that we also work with and trying to do the same thing that we do for those Ignite clients for them and ending up in a place where maybe we haven't done as good a job, or the project doesn't go as well because we're trying to squeeze it into a place where it doesn't fit. And that's what Lift Off is; it’s creating a space where it fits, realizing that a client who comes to us with this massive need it's not massive because they're doing too much. It's massive because they have a big problem that they want to solve, usually for a business that already exists, and it's a new product within that business. Maybe they've even already validated it. And the integrations that it's going to have, the systems it needs to talk to, the level of scale that it's going to have is different than is going to be possible in 8 to 12 weeks. And when we try to squeeze it in there, it's not going to be successful. So Lift-Off is giving a space for those projects to thrive in a way.

+ +

And I also think it's one of those things where it's going to have an impact on our sales too because what would happen previously is that one of those clients might come to us and we're furiously trying to squeeze it down. And how a client perceives that is potentially like, “Oh, they don't know how to do what we need them to do, or they don't want to do it. Or they think our idea is bad because they're saying we need to validate it, and we've already validated it. We have an existing business that we're building this off of,” or something like that. And it causes us to lose that work, which we would otherwise love to have. And now a client like that comes and is talking to a managing director who gets the needs of that kind of project and a team of people that are going to work on it that understand that there's a process to run through and it's going to take six months or a year. We're going to launch along the way, and then we're going to continue to grow the product from there. It's just a different feeling all around, which I think is going to have a positive impact on our ability to actually grow those parts of the business.

+ +

LINDSEY: And Lift Off by nature of working on those health, tech, and financial products is also dealing with highly regulated spaces, which is another reason why those projects are necessarily longer and more complex and lend themselves well to someone who's dealt with it before.

+ +

CHAD: Right. Another thing, and we touched on this a little bit earlier with Boost, is a big part of our business historically is that those clients that have built-in Rails along the way, they've built a super successful business. They're scaling a lot. They're growing their team. They need technical leadership, experience mentorship, and those projects tend to be very development-heavy as well. Like, we have clients where we have four or five developers working with them and no designers, and it caused the design and the development team to be very lopsided. But we really liked that work, and it's very valuable to clients. And so same thing with Boost, Boost instead of that being something which is pushed off into the back where like, oh, well, it's not the project-based integrated team of designers and developers launching a new product, and so it's not our ideal work. It gives a space where that can be our ideal work, and the kinds of people who want to work on those kinds of projects with that level of experience and need feel like they are able to do that on a team that is focused on that. And that team doesn't necessarily need to have a design team that works or looks the same as every other place at thoughtbot. And it creates a place which can focus on what it needs to do in the best way possible that is the most fulfilling to the team and success for the customers. And it looks different than thoughtbot has historically looked, and that's okay. Because actually, when you pick it apart, it's not that different; it’s just taking the 20% of all of the thoughtbot studios where the 20% felt like something that wasn't quite right and putting it all together to make 100% of something that feels right.

+ +

LINDSEY: And from the design perspective, Boost design is a lot around optimizing what already is in place or helping take care of design debt that's been neglected, making sure design and development are talking to each other and thinking about those processes to make them talk to each other better. Whereas Lift Off and Ignite are more introducing design or design processes or design frameworks like putting your design system together or thinking about your accessibility processes, those kinds of activities. And then Mission Control is probably the newest to thoughtbot in terms of services that we're offering clients.

+ +

CHAD: And within Mission Control, there are two big areas that are different, so the first is maintenance. So we historically have been project-based at thoughtbot. And what that would mean is that well, it doesn't necessarily mean -- So historically, project-based plus everyone working on one project at a time, I think the combination of those two things meant that what we mostly did was we help people set up their own team of people who are going to take over from what we had done after we launched the first version of the product and level it up from there. And most of our clients got to the point where the goal was to become self-sufficient. And we also would meet people who had already built something and were just looking for our expertise to help take care of it but not necessarily have enough work for someone full-time. And for both of those clients, we didn't really have a solution for them. And so that's where the maintenance team in Mission Control comes into play because it's a team of people who have opted into splitting their time across multiple clients. The contracts are different where they're paying a monthly recurring maintenance fee for us to take care of certain things every month: security upgrades, patches, small bug fixes, and features. Maybe they even have a team on staff where they're doing the majority of the development work, but they just want our support in helping things go well.

+ +

And also, you mentioned the pull request review service that's within Mission Control as well where we have a separate service where you can sign up, and you just request a pull request review from thoughtbot, and then one of our team members goes on and gives you feedback on that pull request. So that's one part of what's happening in Mission Control is that maintenance work. And then the other is DevOps, and infrastructure is an area where the majority of projects that we worked on across all of thoughtbot were deployed to Heroku or the teams had their own DevOps and infrastructure people and creating a specialization of that for a handful of projects for an individual studio that has that need, over the course of a year, never made sense. But once we started to do it and we took a more global view to it and said, “Across all of our clients, what is the need either met or unmet and what might we be able to do? And where is the interest of our team?” It became clear we could offer -- like, our clients need us to do this sometimes. And for the clients who need us to do it, we want to be there for them. We want to do it. And creating a team of people that is global, that can do it across time zones 24/7 is also one of the needs of the clients, and having that team span those geographies is one way we've been able to do that when historically we would have shied away from that.

+ +

LINDSEY: And speaking of the team's interest in different areas, different services for the rollout of this new organization, we, by and large, had folks opt in to what they wanted to do even as far as the managing directors picking what team that they were going to head up.

+ +

CHAD: So we said, “These are what the teams are going to be,” and we did a company-wide presentation. And then, we asked people to submit their first and second choice. And then we made the decision around which of the managing directors were going to do what and then we announced that to everybody. Am I saying this the right way? Did we announce the managing directors before we asked everybody or just before the deadline was up?

+ +

LINDSEY: I think it was trickled in. At first, it was “What team do you want to be on?” But then, as that's going on behind the scenes, you and Diana are having discussions with the managing directors around where they want to be. And then, as that information became available, you shared that with the team also to help with decisions, same with the design and development directors. I think it was announced the design and development directors chose the teams they wanted to be on and lead. And then, once that was finalized, that was also shared with the team as they're voting on where they want to head.

+ +

CHAD: And the majority of people got their first choice and the majority of people the person who was their manager also chose a similar choice. And so there was a lot of change but not too much churn, I guess is the way I would put it. We were able to do it in a way which I think people felt like they had a choice. And I think going into it; people were afraid of that like okay, am I going to make a choice here and then end up on a team of people I've never worked with before? That was not the case. Now there's certainly a big blending of the teams, particularly Boston and New York were the biggest studios. And so they make up the majority of the people in each of the Boost and Lift Off. But people are working with people that they have worked with before.

+ +

LINDSEY: And it turns out the people they didn't work with before are also awesome, also, very cool.

+ +

CHAD: [chuckles] So much effort over the years spent -- that strategy of replicating what was great about thoughtbot into other geographies is true. And so the standards that we had for hiring, and the kinds of people we hire, and the screening for values fit, and all that stuff led us to a place where everyone at thoughtbot is great. And so I wasn't really concerned about that, but other people may have been because there's always a fear of the unknown.

+ +

LINDSEY: Yeah, definitely. I'm trying to think if there were other rollout things that might be interesting.

+ +

CHAD: Well, one of the interesting things it's a little in the details. On the surface, that is the team, and those are the services we offer. But we also needed to contend with the fact that we are in the U.S. and the UK, and we didn't really feel like it makes sense to have those teams span 10+ time zones, that that would be too far of a stretch. And it would affect people's fulfillment on the team as well as the services we are able to deliver. So these services that we offer are actually fulfilled by two…do we have a word for it? [chuckles]

+ +

LINDSEY: Geographies?

+ +

CHAD: Geographies, yeah, I guess.

+ +

LINDSEY: There are two geographies that we ended up naming Launchpad 1 and Launchpad 2, because rockets.

+ +

CHAD: So Launchpad 1 is all of the Americas, and Launchpad 2 is Europe, Middle East, and Africa. And so they provide all of those services in those places. But they have teams that are formed across the whole geographic region. And then eventually, if all goes well, we'll have Launchpad 3, and that'll be [chuckles] the other side of the world.

+ +

LINDSEY: I've got the icon ready and waiting. So I guess timing-wise, this all happened...rollout was by the beginning of the year, right? January?

+ +

CHAD: Yeah. One of the things is more people took more time off between the December Holidays and New Year's and everything than they have ever done before, and we needed it. Everyone needed it. So we weren't able to finalize what team everyone was on and have a conversation about that with everybody before they saw it in a message somewhere, which we really wanted to do. So we ended up not being able to finish all of that before the end of the year. And so it rolled into the first couple of weeks of January as people came back, and we were able to talk to them. And then I think we made the internally public announcements about all the teams that everyone was going to be on, and we did a formal kickoff. What was it? January 8th or something like that.

+ +

LINDSEY: Yeah. And I think that's actually a really good point to bring up is the communication to the individuals. It was important for them to hear it one-on-one from their manager before anything was announced more broadly and then to transition to their team if their manager was changing, which in a lot of cases, it didn't, but sometimes it did. Having one-on-one-on-one transition meetings to really ease that move was also important to not make this really abrupt and unnecessarily stressful in a time that is already very stressful for reasons we know.

+ +

CHAD: And even if someone's direct manager wasn't changing, it was very likely that their director would change. And so, in those cases, we still did a one-on-one-on-one, but it was with the new director sitting in as well as a skip-level one-on-one on-one. And we did it quickly, but it was important to make it happen quickly.

+ +

LINDSEY: And it was also important to not abruptly change on the clients because obviously, we weren't doing a full stop of client work just because we're doing some reshuffling internally. So that was phased, and we didn't even really make it a big deal to the clients because that probably would have just added confusion as we were making these changes.

+ +

CHAD: Yeah, definitely. And we made the decision that we weren't going to just arbitrarily say, “This person is now on this team; therefore, they have to leave this project,” so we made that decision. And we have as natural points in the project for a rotation to happen. People will move to a project; if there's a mismatch between the project that they're on and the team that they're on, they'll move at a natural point. But the reality was that a lot of people also chose -- It's not like we have 57 different project types; we have three. And so a lot of people were already working on the project type that they chose just because the odds were good that they were. There's been very little customer-facing impact to it. So it's early days. It's March now, so it's been a couple of months. But how do you think it's going, or where do you think the growing pains are?

+ +

LINDSEY: Good question. I think there's been more of a smooth transition than there have been growing pains, first of all, which has been nice. I think folks have been pleasantly surprised by really enjoying their new teams and new team members. I think growing pains-wise, on the operations side, obviously we've had to...I think we’re still in the process of figuring out how to best pipe certain kinds of inquiries into the right team and managing director. Sometimes it's a no-brainer. They're like, “I need to validate this idea.” It's like boom, “You're off to Dawn for Ignite, and you’re going to have a conversation there.” But if they come in and they say, “I'm working on an MVP, and we don't know if that MVP is one of the really fast ones or one of the more complex ones,” then it's like, okay, is this going to Dawn or Emily?

+ +

CHAD: And we historically didn't need to have any handoffs because one person was able…one person and team; it was based on geography. So we knew exactly who was going to be having that conversation with them. So operationally, it's actually one thing we didn't touch. So no one was let go in this big reorg. There was a position for everyone, I guess, if they wanted it. But one area we haven't touched on is anyone who was local, who was in a support role moved up into the corporate level in a support or operations role. And there weren't that many of those people, but the office manager in Boston is now full-time in people operations. And the office manager in New York City is now the operations manager for the whole team, the whole company. Kelly, who was doing business development just in Boston, is now helping across all of thoughtbot, which is really good at using her skill set across the whole company. I think that that's good.

+ +

And now, like you said, figuring out how to support everyone across the teams is a little bit of whether it be the operations manager figuring out how to get people computers when we hire new people to like what you were saying around inquiries coming in and making sure that they're sent to the right person. The thing that has made it more challenging for me is that just a confluence of events at the time where we were making some of these changes. And now it has made my involvement different than I was originally expecting them to be. I expected to be a little bit more involved in certain things, but because I've been pulled into several important client projects and was working on client work at the time that then expanded very rapidly, it's been challenging for me to manage the workload. But in some ways, there's a bright side to it, which is it's giving other people the space to operate without me, which I think can be good because I'm very confident in what everyone's bringing to the table. And when you go through a big period of change like this, if everyone was deferring to what I thought as the founder or looking for me for answers or permission to do something, I think that we would suffer for it. And so being forced in a way to not be available for everything that's going on is a way for people to have more ownership over it and not be relying on me, and I know that they can do it.

+ +

LINDSEY: Cool.

+ +

CHAD: So we never said what the new purpose was. So maybe we'll just talk a little bit about that, and then we'll use that as a wrapping up point.

+ +

LINDSEY: Sounds good.

+ +

CHAD: So I mentioned earlier our purpose had been we believe that there's a better way to work. There's always a better way to work, and we want to find it and share it with as many people as possible. We had written down that purpose several years ago, like a decade ago, I think. And I believe a good purpose describes what is the underlying motivation for the company and the people at it. And when we did that survey of people, a few of the questions we asked touched on it. And it wasn't that surprising to me about -- one of the threads in that was this idea of positive contributions to the world, making sure that the things that we work on and do have positive contributions to the world and that being a motivating factor. Like, that's part of what makes the team tick and what they want to be doing and are fulfilled by and that kind of thing. And so we incorporated that into the purpose. And so we adjusted the wording a little bit to make that incorporation, but we ended up that we believe that it's always possible to continuously learn and improve the way people work while building higher quality products that make positive contributions to the world.

+ +

This resonated with me in a way that -- it's a little bit more wordy, and that's not why it resonates with me. [chuckles] Specifically, our previous purpose of we believe that there's always a better way to work and we want to find it and share it with as many people as possible lacked one thing that I think a good purpose can incorporate, which is what is a clear idea of what the alternative is like, what you're fighting against, or what you're trying to improve. It's there in the previous purpose. So, in theory, there maybe are people out there who believe that there's not always a better way to work that they've achieved it or something like that or that they have particular practices which aren't great. But it's not explicit or really even implicit in the purpose. And the new purpose we believe that it's possible to continuously learn and improve the way people work while building higher quality products and make positive contributions to the world. You can point to someone who might believe the opposite of that, that you can't build higher quality products that make positive contributions to the world while also continuously learning and improving the way that you work and everything, that to build higher quality products or make positive contributions to the world, you might need to compromise on the values of continuous improvement and learning. And our new purpose makes a statement that you don't need to compromise in order to achieve that result, and I like that about it.

+ +

LINDSEY: I really like the addition of talking about the kinds of positive products because I think once you know thoughtbot at all, you know that that's underlying the purpose but take out the guesswork, just tell the folks. All right. Well, I think that's a good place to stop. I'm glad we didn't even go into the remote because there's obviously a lot to talk about.

+ +

CHAD: Yeah. So we'll talk about that next time?

+ +

LINDSEY: Yeah. We're going to talk about what changes we've made in going completely remote and what that looks like, what we think it looks like for the future.

+ +

CHAD: Cool.

+ +

LINDSEY: So you can subscribe to the show and find notes for this episode at giantrobots.fm

+ +

CHAD: If you have questions or comments, and we'd love to hear them, email us at hosts@giantrobots.fm, or you can find me on Twitter @cpytel.

+ +

LINDSEY: And you can find me on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot.

+ +

CHAD: It's good to be back. Thanks for listening and see you next time.

+ +

LINDSEY: It's so good to be back. Stay tuned.

+ +

This podcast was brought to you by thoughtbot. Thoughtbot is your expert design and development partner. Let's make your product and team a success.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+sjAADr4e + + ]]> + + Lindsey Christensen + Chad Pytel + + + 392: Better Together with New CEO of thoughtbot, Diana Bald + https://podcast.thoughtbot.com/392 + 668f385f-37ad-4365-b18b-7e2c93d723f6 + Thu, 13 May 2021 05:00:00 -0400 + thoughtbot + + full + 10 + thoughtbot + Chad is joined by Diana Bald, the new CEO of thoughtbot, to discuss her background, the organizational changes to the leadership of the company, and the reasoning behind them. + 37:29 + no + + + Chad is joined by Diana Bald, the new CEO of thoughtbot, to discuss her background, the organizational changes to the leadership of the company, and the reasoning behind them. +Diana on Twitter (https://twitter.com/dianabald) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! +Transcript: +CHAD PYTEL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And today, I'm joined by the new CEO of thoughtbot, Diana Bald. Thanks for joining me, Diana. +DIANA BALD: Hi, Chad. This is so fun. This is so exciting. I've only done one podcast before this, so I'm excited. +CHAD: Well, don't worry. You can still be CEO of thoughtbot even if you're not a podcaster. [laughter] +DIANA: Okay, that's great to know. +CHAD: So it's been several months now. So I want to go back and talk about how we arrived here. But I'm curious, how are you feeling now? What does it feel like? +DIANA: It feels great. I think I'm getting more and more comfortable every day, which is amazing. And I think the year has gotten off to a great start, so that's helping me feel more comfortable as well. So far, so good. +CHAD: So for folks who are listening, I'm sure they're wondering who are you? [chuckles] Let's give the audience a little peek into your background and how you arrived at thoughtbot, and the role you originally had. +DIANA: Great. How far back do you want me to go? +CHAD: As far as back as you're comfortable. +DIANA: Okay. I actually was really interested in technology at a younger age. I put myself through undergrad and grad school while I was doing tech roles. I trained lawyers on how to move from the analog world into the digital world. That was one of my very first jobs at a law firm. And then, shortly after that, I did webmaster work when I was putting myself through MBA school. It was a very different world than it is now. This is way back when the internet was really just kicking off; it was 1998 to 2001, around that time. When I graduated from MBA school, I was recruited into Univision into their leadership pipeline, which was very much focused on business development. But my very first project there was web integration, integrating the univision.com with their TV and radio. That was when I started to move away from technology. I was there for ten years. I had a variety of different roles, a really fun job. I got to experience a lot of different roles, lived in a lot of different cities. I spent a lot of time in Philadelphia, where I actually launched a television station in Spanish, which was really fun. And then I came to New York. +After Univision, I spent four years in the advertising and marketing world. I spent two years with IPG at ID Media, which was a direct marketing agency. And then two years at MDC Partners at an agency called TargetCast, which later became Assembly, which was more media buying and planning. And then, when I left there, I went to Liberty Mutual for three years. And at Liberty Mutual, I fell back in love with technology. I missed it. I was doing a lot of strategic partnership opportunities with really interesting companies that were doing brand new business models and disrupting insurance, and there was a lot of exposure to telematics and IoT. And it was just calling me back, and I was like, I got to get back to tech. And somehow, I don't recall exactly how, but I found you. You and I chatted, and then I fell in love with thoughtbot [chuckles], and then after that, the rest is history. +CHAD: You joined us as the Managing Director of the New York City studio. I want to say that was a position we were advertising for, and you applied to it. +DIANA: Yeah. +CHAD: And one of the things that really stood out when I first met you and as we've got to know each other and work together is the variety of experience that you had because I've only ever done what I do, which has its own strengths. So the fact that I started freelancing web design and development in high school and have continued to do that now for 25 years is a strength, but it's also, aside from the jobs I had as a dishwasher or the checkout person at the grocery store, this is literally all I've done. And the variety of experience you have not only helps thoughtbot be better, but I also think it positions you well for our business. In consulting, you need to be unflappable in a lot of circumstances, and I think you're good at that. You're good at maintaining an even keel and talking with customers and dealing with difficult situations and that kind of thing. +DIANA: In some ways, I'm envious that you have been able to stick with development the entire time; that’s really, really cool. But in other ways, I can see what you're talking about because I do feel like I have had a variety of roles and seen a lot of different situations. And every one of these situations has had their challenges. And they've all been generalist roles where I've dealt with clients, and then those clients had challenges in their respective industries. So I've really learned a lot about keeping things in perspective, if you will, more so than people who are in a role for a particular time and see that aspect of it. I'm seeing things from a bird's eye view much more often because maybe I've seen the situation in the past only it was in this industry, or I've seen this situation in the past, but it had these characters. And it's like I can carry that knowledge over to thoughtbot, which has been really helpful. +CHAD: So the managing director role, I think I've described it on the show before, and it’s sort of the CEO of the individual studio. That’s the way that it works. You oversaw the individual studio, and you were responsible for business development and the whole P&L of the studio, the whole business. Going back to first joining thoughtbot, what was a surprise to you? +DIANA: How comfortable I felt. [chuckles] I felt like, oh, I'm home. I felt like, oh, there you are. I've been looking for you all my life kind of feeling. I don't know how to explain it. It just felt really good. Like, okay, these are problems. I like these problems. Or this is really joyful. I felt like I was actually in my element for probably the first time in my career, although I've had some jobs where I felt pretty much in my comfort zone, but thoughtbot took it to a totally new level. And I don't know if it's thoughtbot, or the role, or the combination of the two, or maybe it's me where I am now in my life and just having had all these different jobs and experiences. Maybe it's all the above. +CHAD: One of the interesting things that's been a journey for thoughtbot not only just with you but with several people is up until a few years ago, we hadn't, aside from some office managers or people operations, we hadn't had people in direct client-facing roles who are not designers and developers. And it comes from a place of fear and skepticism about that, historically for us, for me personally. And I don't think I was wrong per se; I was just misguided. And I've learned over the years that when you're afraid of something, there can be some truth in what you're afraid of, but you should let that fear guide you into making good decisions and not let it hold you back from doing anything. And that's what we were doing: we were so afraid of what adding non-designers and developers to the consulting side of the business would mean for us as designers and developers that we didn't do it at all, instead of trying to find people who would be a great fit, who would be great advocates for us, a great fit for the company. And once we figured out the recipe for doing that, I feel like not only did it make thoughtbot better and stronger on the business side, but it made thoughtbot better overall. One of the things we strive for is an inclusive, diverse environment, and that doesn't just mean the obvious things. It also means having different perspectives and experiences that a group can bring to the table that makes the results better and more enjoyable, and more fulfilling to work in. And I think that you've been successful in bringing that to the company, and it felt good and not only you but the other people that we've added in the managing director roles. And that kind of thing that brings that different experience and different skill sets to the table has made thoughtbot better, I think. So, thank you. +DIANA: Thank you for letting us bring it to the table; not every place lets us do that. But you've set up a culture, to your credit, that I think brings the best out in people. And I think you've enabled that to happen, so thank you right back. [chuckles] +CHAD: There's another angle to that, which has been on my mind, which is what we were doing in the past was basically forcing designers and developers to do some of those things and potentially setting them up to fail because it wasn't a strength, or it wasn't an area that they were actually interested in. They were just doing it out of love for thoughtbot or wanting to see us succeed. When you put people in a position where they're going to struggle or where they're going to not succeed, that's doing nobody a favor as well. And so that's in part been on my mind because as we've been reorganizing the company and everything, I think that's part of the lens at which we're looking at it: what can we do to make things easier to make us more successful as a team and as individuals in our day-to-day work, too? +DIANA: I think that there's a lot there. I feel like in every designer; there is a business person because they're breaking things down. They're deconstructing constantly, and they're asking tons of questions that business people just naturally ask. And then developers are super creative, and they're problem solvers, and they do the same thing. I feel like it's a combination of art and science. Everybody's got their science part of it, the developers, designers, even people like me with a business development background. But then when you do enough of that thing, and you're meshed with the people who bring a complementary skill, then you're able to do the art side of it together that you wouldn't get solo, for instance. If you just put a bunch of business development people in a room together, it's very different than when you mix them up with a designer who brings that side of thinking and a developer who brings their thinking. I think together we're better than siloed. +CHAD: So when it came to the actual transition and having you step into the role of CEO and move into the COO role, and I want to be relatively honest that it wasn't some grand plan that I executed over a period of a long time. And if that had been the case, I think we would have gone about it a little bit differently and certainly with more transparency for the rest of the thoughtbot team. For the listeners, the path there was that Matt Jankowski, a long-time COO and member of the leadership team at thoughtbot, was getting ready to move on. And that wasn't the only thing that was changing. Obviously, 2020 was a big year; it was a difficult year. And so the combination of all of those things and me looking at what does the leadership team at thoughtbot look like going forward? Who is going to fill Matt's responsibilities? That kind of thing, and really breaking down those roles and responsibilities and coming to the conclusion that the CEO role and particularly business development are inherently coupled at the company right now and that we have a lot of things we need to do in front of us and who is the best person to be able to do that? And feeling like it might not be me. +And the things that I was going to be taking over from Matt operationally were in and of themselves a significant area. I love thoughtbot. I love helping it work better and being close to the client work. And now that we've built an incredible team of managing directors, that was another thing that was on my mind that I've built that team. I'm really proud of that team, and it's an awesome team. But who's going to be the better mentor and leader for that team going forward now that we've got a team of experienced people who are slightly different than just designers and developers and who have different needs and jobs? And again, the best person for that might not be me. And so those were all the thoughts that were going through my head. And then things came together really quickly. +DIANA: Yeah, they sure did. [laughter] They sure did turn around and come together really quickly. First, I have a lot of admiration for you, in particular, like the way that you're able to take a step back and look at things objectively and not let ego get in the way of things because that's a big deal. Not everybody is able to do that, Chad. And I've worked at a lot of places, as we talked about, and I've seen ego get in the way. And I've seen ego get in the way in a bad way. It's not always a friend. Sometimes it could be a friend, sometimes it's a very powerful friend to have, but sometimes ego can hurt. And so there's a lot of wisdom to that. +And in terms of the speed at which things came together, yes, I agree; I think that's a reflection of the times we're living in. We're in a time where things can change on a dime, and we just have to be able to pivot and be able to reassess the landscape, see what we have to do, make the necessary modifications and then go. And I'm really proud of both of us and the team of the managing directors and everyone at thoughtbot for our ability to quickly adjust and do what we had to do during the really crazy year that 2020 was. +CHAD: I spent the majority of 2020 in intense survival mode. And so it wasn't until we were through that period that I realized how much it had affected me, whether it be in burnout ways but also in terms of realizing that we were going to survive. At the end of March, early April, it was the most difficult time. We saw a good portion of our business…new projects were starting, people doing new things. At the end of March, early April, a lot of that new stuff got completely put on hold as the whole world recalibrated. And so we saw a significant decrease in revenue in those months, and we didn't know where it was going to go. So we were very proactive about redoing our numbers and making sure that we weren't going to go out of business and didn't go out of business. And once we were able to do that and to stabilize things, we still needed to spend a significant amount of effort for the rest of the year, working really hard to make sure that we made things less bad. And that was pretty difficult. +But my main point or my takeaway from the year and part of what has led to this transition is the realization that I don't really have any plans to go anywhere per se, but rather than be like, oh, I need to keep my position forever, it's more we're coming up on the 20-year mark of thoughtbot. When we came up on the 10-year mark of thoughtbot, we asked ourselves the question, “Okay, it's ten years. We're not really going anywhere. What do the next ten years look like?” And so, as we continue to move forward as a company, I think the horizon tends to expand. And it's like, okay, we're coming up on 20 years. What do the next 20 years look like? So, I don't really have any plans to go anywhere, but am I going to be doing this and the same thing in the same way for another 20 years? Probably not. [laughs] I'll be getting close to retirement age. So I always have come to work every day, just trying to create the place that I want to work, doing the kinds of things that I want to do. And I think that motivates everyone at thoughtbot. That's how we all come to work every day. And I think it's one of the things that leads to that culture that we have. And I think this transition has been part of that expanding horizon part of thinking about being a resilient company that is going to last for a long time. +DIANA: Yeah, absolutely. I think that's one of the things I love most about thoughtbot is just that we're intentional and that we do want to make this a place that people want to work at. +CHAD: So we asked for questions from the audience, and one of the gists of the episode was what was the actual way that we communicated this change to the company? +DIANA: So I think we went about it in multiple ways. You notified people in the early stages. And then, we also went about a transition period, which was like the second phase of it. I think you can speak best to the first phase. +CHAD: Yeah, one of the first things I did was once the decision was made; I met one-on-one with the rest of the C-level team and looped them in on it. And then I think the next thing was crafting a company-wide message that went out to the whole company. I'm not sure if there was much in between those two things. +DIANA: Yeah, I think that's what it was. +CHAD: Now, one of the interesting things, as I was saying earlier, is that part of the change that was happening at the same time was Matt transitioning out of the company. And so I think in some ways that made the whole thing a little bit more understandable for people. There was change already happening, and they were together. I think in retrospect, in other ways, or at least one thing I wanted to make sure people understood, is that the COO role and the CEO role going forward aren't necessarily the same as what they were in the past. And so even though Matt was leaving and I was taking on that title, that doesn't necessarily mean I was just going to be doing everything that he did in the same way that he did it. And the same is true for you in the CEO role. +DIANA: Yeah, we bring our own personalities and our own strengths to the roles. We give each other room to do that. I know that you like to be involved in the development. You like to be involved in sales as well. It's important that things change, that things don't stay the same. I think it's important to evolve and to bring in different viewpoints and change the roles a little bit if we need to, which I think we've done and we're doing. +CHAD: And so someone asked, “Were people surprised?” I think people were very surprised, don't you? +DIANA: [chuckles] Yeah, I think so. I think I was surprised, [laughter] starting with me. Yeah, everybody was. But it's understandable; you’re the founder. And I think change does bring an element of surprise in and of itself. +CHAD: Yeah, I think we got to that place very quickly. But in retrospect, knowing where we ended up, I could have envisioned more proactively saying, “This is a transition,” not even necessarily with you specifically just like “maybe next year I won't be CEO,” like giving people some clue that a transition of some kind might be coming. But I didn't know myself, and so it wasn't really practical to give people. But I think in retrospect, it would have been nice to make it more clear that that's the kind of thing that might be on the table. +DIANA: I also feel, though, that there is an element like we were speaking about earlier that sometimes things change and they change quickly, and we can see more of that happening in the future. I don't think that's going to stop. I think that actually might increase to some extent. So it's great if we have an advance notice of things, but sometimes there isn't the room or the opportunity to do so. +CHAD: So then you moved into the role. We had a transition period. What was that like for you? +DIANA: It was interesting because I thought, well, let me bring things that I always wanted my CEOs to do but never did. And let me not do things that I saw my CEOs doing that I didn't like. [chuckles] Let me start there. And one of the things that I really enjoy, and I think it's part of the culture here, is just being a little goofy and a little silly and just having that freedom. And I actually think that that makes for a better, healthier environment. And I guess I wished my prior CEOs were a little bit less uptight, maybe, if you will, a little bit more goofy, a little bit more fun. And so I think bringing that even more because you already bring that but really doing it together. [chuckles] +CHAD: Well, I have to be honest, I used to be a lot more goofy than even I am now. And I've just been worn down over the years [laughter], which is why part of this is just making sure that things stay fresh, too. But yes, I really appreciate that. +DIANA: And also another thing that I would think is really important to me is that voices be heard. It's all a collaboration, right? Because I've worked at some big companies, I would say a lot, but not all of them have been big companies, and it's been very top-down, and it shouldn't be that way, even in big companies. I think that it should be a dialogue. You put something out there, but you also have to hear the feedback. That feedback loop is really important. And you might miss something really, really big if you don't have that feedback loop. And I really enjoy that we are doing that here. We have our director sessions where we break out into teams, and people come up with ideas, and they share those ideas. And we take that in, and we synthesize it, and we say, “Yes, that's valid. Don't agree with that. Definitely agree with that.” We're able to have that dialogue that I think serves us really, really well, which is another thing that I'm really enjoying about my new role and working with you in this capacity. It’s great. +CHAD: I have a couple of things that surprised me, and I'm curious what surprised you. But the first is that I knew that things were going to have to change. There were too many pent-up questions at thoughtbot. It was too obvious that the pandemic was going to last a lot more longer, but I didn't know what any of those things were. I just had a sense that they were going to change. And so the process of navigating that change with you and not being the one who is CEO while that's happening has been really positive for me and surprising. What's been surprising for you? +DIANA: Very few things surprise me if I'm honest. [laughs] I feel like with time, with so many experiences people have, things get less and less surprising the more time we're on this planet. I don't feel that surprised about things. I actually have gotten to a point in my life where I'm seeing things as opportunities (and you and I have talked about this a lot) and leaning into those challenges and turning them into what's the silver lining here? Can we find the silver lining, and how do we pull that silver lining out and actually turn that into something really strong? I'm doing that more and more. And I feel like the pandemic has actually really called that out and made that a strength in a way which is ironic, but it's actually been really a very useful skill. +CHAD: So the other thing that's been surprising or unexpected, once the transition was over, some things happened that pulled me into client work much more than I was originally expecting. And that's been really interesting because I feel like it's both good and bad. There are things that I would historically be involved in, and even in my new role, I should be, and I just can't be. So all of you are left to do things without me, but there was never any doubt in my mind that you'd be able to handle it or that the team would be able to handle it. But I think it's actually been an interesting thing to have those two things coincide. We've got these transitions going on, and we've got the reorganization, and suddenly, I'm a lot less available than I have been in the past. So that's been something that's been unexpected that we've had to deal with. +DIANA: I think one of the things that's helped me deal with that is that you've been working on some very important projects for the world, and that really do help humanity. And I just think that that's been one thing I keep thinking about: Chad’s doing really important stuff right now. So I think that's been a good thing to keep in mind as well. And then there's another side to it, too, where it's like a parent analogy. Even though I'm not a parent, I have young people in my life. You leave them alone sometimes, and sometimes they'll surprise you, and they'll actually be able to take care of themselves. And they're able to actually do more than you thought they would because you left them alone and it’s like, let's see what they do. And then they actually do something really cool. Some of that has played into this, too, which is interesting. +CHAD: Well, from my perspective, it's almost the opposite of what one might think, which is I never had any trust issues. And I always believe in the thoughtbot team to be able to do things. But oftentimes, I feel like I'm being asked for permission or being checked in with just because I'm the founder and that kind of thing. And so I actually think it's been healthy to be not available and be pretty explicit about that because then it means that I'm not being an artificial gatekeeper for people and things. +DIANA: And it also strengthens the decision-making, I think, because people get to practice that without you and not become dependent on you solving the problem for them, for instance. That's another healthy side to that. +CHAD: So in upcoming episodes, we're going to talk about the reorg, and a big part of that is going remote. We don't need to dig too much into it now, but through the lens of becoming CEO through that transition, that has been entirely remote. For me, as CEO, I was traveling to each of the studios meeting people in person once a month. How has it been going through this transition, becoming more embedded into the rest of the company at different levels and that kind of thing and having it be entirely remote? +DIANA: It's got its pros and cons. In some ways, we've been able to move really quickly on some things. We've also been able to bring perspectives that maybe we wouldn't have thought about before. On the other hand, I really enjoy getting out and seeing people in person, and I feel like there's a chemistry that's developed when you're able to go to lunch together or just have coffee together. And I’m missing that side of it and looking forward to the day when we can do that safely, especially the folks in London; getting a chance to do that with them would be terrific. But I think as with anything, it's got its pros and cons associated with it. We’re trying to lean into the pros as much as possible because this won't always be the case. There will be a time when we all come together. And we might as well just make the most of this time that we're apart to move as quickly as we can, learn as much as we can, and take those learnings so that when we are in person, and we do connect that we can then explore other advantages that that brings us. +CHAD: So when it comes to working from anywhere, which we're specifically not saying that we're an entirely remote company; it’s just that we are now working from anywhere going forward. And that was an intentional choice. But that's been an interesting transition; I think because previously, our whole strategy as a company was local studios working with local clients with a local team. Our culture was built up around our physical places of work. So my question for you as the CEO of thoughtbot is how do you maintain that culture, or how do you change it to not lose what people think makes thoughtbot great along the way? +DIANA: I think we're in the process of discovering that right now. And we are learning things that work and things that don't work. And I don't have an answer. I can only speak to things that we're trying to do. I have noticed there have been a lot of people who have left and gone to different parts of the country, or some have even left the country. And I think that was really surprising. I wasn't expecting people to move to some of the places that they've moved. But knowing that they have an increased comfort level in their lives because they're closer to their families or they're doing things that they need to do right now in certain locations that are not where they started gives me a sense of reassurance that this was the right decision because we're giving people that space, that ability to do that. And some people really did need to move to different locations and deal with certain things. And then just giving that extra flexibility that’s honestly practical, it's just practicality. I feel like all we've done is introduced the element of this is just a practical application of life. Like, if you need to take your kids to school or if you need to go to the doctor, go to the doctor, it's okay. If you need to run an errand, go ahead and do that. You don't have to be tied to a desk in one location all day long. It's healthier if you do what you have to do and then get back to work when you're ready. +And then we've had a lot of issues that have impacted society in general that have affected thoughtbot overall, like the things that happened with George Floyd and some of the things we're hearing about recently in Atlanta, killings in Atlanta. Sometimes people just need to take a moment and process all that and see how do we make this world a better place and how do we bring our best selves to thoughtbot? And in our new remote structure, we're giving that, not that we didn't do it before, but it's just giving that extra space that it's okay, it's safe. It's safe to do that. Take the time you need and the place that you need, if it's closer to your families, do that. I feel like that's been a very practical thing that we've done. +There's a sense of loss because I miss all the New Yorkers. [chuckles] I’d see them often, and everybody would get together on Fridays and have lunch together, and there's a sense of that loss. Seeing our Slack channel go away was sort of sad in a way, but then happy in other ways. But that's true with everything that changes. With everything that changes, there's a beginning and an end; there’s a transition. And we're going through that. I'm looking forward to the days that we can bring people together, maybe in an in-person summit. I think that's going to be fantastic. It's going to be so much fun. But right now, the summit that we had virtually was a blast, and everybody was virtual, and folks had a really good time. So it's just we're finding that right balance. We're testing and trying things. I hope people feel they can bring ideas to us, and we can implement different tactics, tricks, cultures, all that is work in process. +CHAD: I think we're in for an interesting time over the next year because part of why we had offices before was that highly collaborative environment with not only the thoughtbot team but with the clients that we work with and whether that would have been in their office or in ours. And when that was completely off the table, there was no discussion. We didn't need to be in person with someone. The team wasn't going to be based in New York because you're in New York, those kinds of things. And so the pandemic was the kick in the pants we needed. And since clients were also entirely remote, it just wasn't an issue. It'll be interesting over the next year as we navigate being able to be in person again staffing projects remotely, having teams be distributed, that kind of thing. It will be fine. If we didn't think it would be fine, we wouldn't have done what we did, but just because it will end up okay doesn't mean that it won't be a little bit of a challenge or interesting. +DIANA: Absolutely, yes, I agree. I think we may even be more experimental and traveling to different cities where the client is, for example, together as a group, which we really didn't do much of in the past. We've talked about having things like pop-up offices, which is something we will experiment with. So there's some experimentation to happen. I know we're going to make mistakes. But I know we're also going to do some stuff that's going to be really, really great, too. We have to try it, though. We won't learn until we try it and lean into what works. Let's do more of the stuff that's working. +CHAD: Yeah. And the other thing, and I think we communicated this to the team, which is like, this is what we're doing today. It's going to be iterative. And one of the things people need to keep in mind is that we spend a lot of money on offices. And so once we remove that, that money can be put to completely different things whether it be getting together in person more often, or it be other benefits or just operating more profitably so that we're all working a little less stressed. There are all these things that are going to come out of it. And that doesn't even necessarily mean that three years from now, we won't have small offices in some places that look very different than what the previous thoughtbot offices look like. But the best way forward, we felt, was to completely wipe the slate clean and rebuild what it means to be at thoughtbot and how we're working both financially but also from making this new structure work really well perspective. +DIANA: Yes, exactly. +CHAD: So, any parting words of wisdom or thoughts? +DIANA: Yeah. You made this really comfortable for me. I was completely out of my comfort zone, but I think you made me feel comfortable in having a podcast conversation. So thank you for that. It was a lot of fun. +CHAD: If people want to get in touch with you, ask you questions, follow along with you, where is the best place for them to do that? +DIANA: Email is great. Also, I am getting more active on Twitter now. It's something I'm having to do, but you can also find me on Twitter @dianabald, first name, last name. And my email is dianabald@thoughtbot.com. +CHAD: Awesome. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel and Lindsey on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot and produced and edited by Thom Obarski. Thanks for listening as always, and see you next time +This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success. Special Guest: Diana Bald. + + + Chad is joined by Diana Bald, the new CEO of thoughtbot, to discuss her background, the organizational changes to the leadership of the company, and the reasoning behind them.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD PYTEL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And today, I'm joined by the new CEO of thoughtbot, Diana Bald. Thanks for joining me, Diana.

+ +

DIANA BALD: Hi, Chad. This is so fun. This is so exciting. I've only done one podcast before this, so I'm excited.

+ +

CHAD: Well, don't worry. You can still be CEO of thoughtbot even if you're not a podcaster. [laughter]

+ +

DIANA: Okay, that's great to know.

+ +

CHAD: So it's been several months now. So I want to go back and talk about how we arrived here. But I'm curious, how are you feeling now? What does it feel like?

+ +

DIANA: It feels great. I think I'm getting more and more comfortable every day, which is amazing. And I think the year has gotten off to a great start, so that's helping me feel more comfortable as well. So far, so good.

+ +

CHAD: So for folks who are listening, I'm sure they're wondering who are you? [chuckles] Let's give the audience a little peek into your background and how you arrived at thoughtbot, and the role you originally had.

+ +

DIANA: Great. How far back do you want me to go?

+ +

CHAD: As far as back as you're comfortable.

+ +

DIANA: Okay. I actually was really interested in technology at a younger age. I put myself through undergrad and grad school while I was doing tech roles. I trained lawyers on how to move from the analog world into the digital world. That was one of my very first jobs at a law firm. And then, shortly after that, I did webmaster work when I was putting myself through MBA school. It was a very different world than it is now. This is way back when the internet was really just kicking off; it was 1998 to 2001, around that time. When I graduated from MBA school, I was recruited into Univision into their leadership pipeline, which was very much focused on business development. But my very first project there was web integration, integrating the univision.com with their TV and radio. That was when I started to move away from technology. I was there for ten years. I had a variety of different roles, a really fun job. I got to experience a lot of different roles, lived in a lot of different cities. I spent a lot of time in Philadelphia, where I actually launched a television station in Spanish, which was really fun. And then I came to New York.

+ +

After Univision, I spent four years in the advertising and marketing world. I spent two years with IPG at ID Media, which was a direct marketing agency. And then two years at MDC Partners at an agency called TargetCast, which later became Assembly, which was more media buying and planning. And then, when I left there, I went to Liberty Mutual for three years. And at Liberty Mutual, I fell back in love with technology. I missed it. I was doing a lot of strategic partnership opportunities with really interesting companies that were doing brand new business models and disrupting insurance, and there was a lot of exposure to telematics and IoT. And it was just calling me back, and I was like, I got to get back to tech. And somehow, I don't recall exactly how, but I found you. You and I chatted, and then I fell in love with thoughtbot [chuckles], and then after that, the rest is history.

+ +

CHAD: You joined us as the Managing Director of the New York City studio. I want to say that was a position we were advertising for, and you applied to it.

+ +

DIANA: Yeah.

+ +

CHAD: And one of the things that really stood out when I first met you and as we've got to know each other and work together is the variety of experience that you had because I've only ever done what I do, which has its own strengths. So the fact that I started freelancing web design and development in high school and have continued to do that now for 25 years is a strength, but it's also, aside from the jobs I had as a dishwasher or the checkout person at the grocery store, this is literally all I've done. And the variety of experience you have not only helps thoughtbot be better, but I also think it positions you well for our business. In consulting, you need to be unflappable in a lot of circumstances, and I think you're good at that. You're good at maintaining an even keel and talking with customers and dealing with difficult situations and that kind of thing.

+ +

DIANA: In some ways, I'm envious that you have been able to stick with development the entire time; that’s really, really cool. But in other ways, I can see what you're talking about because I do feel like I have had a variety of roles and seen a lot of different situations. And every one of these situations has had their challenges. And they've all been generalist roles where I've dealt with clients, and then those clients had challenges in their respective industries. So I've really learned a lot about keeping things in perspective, if you will, more so than people who are in a role for a particular time and see that aspect of it. I'm seeing things from a bird's eye view much more often because maybe I've seen the situation in the past only it was in this industry, or I've seen this situation in the past, but it had these characters. And it's like I can carry that knowledge over to thoughtbot, which has been really helpful.

+ +

CHAD: So the managing director role, I think I've described it on the show before, and it’s sort of the CEO of the individual studio. That’s the way that it works. You oversaw the individual studio, and you were responsible for business development and the whole P&L of the studio, the whole business. Going back to first joining thoughtbot, what was a surprise to you?

+ +

DIANA: How comfortable I felt. [chuckles] I felt like, oh, I'm home. I felt like, oh, there you are. I've been looking for you all my life kind of feeling. I don't know how to explain it. It just felt really good. Like, okay, these are problems. I like these problems. Or this is really joyful. I felt like I was actually in my element for probably the first time in my career, although I've had some jobs where I felt pretty much in my comfort zone, but thoughtbot took it to a totally new level. And I don't know if it's thoughtbot, or the role, or the combination of the two, or maybe it's me where I am now in my life and just having had all these different jobs and experiences. Maybe it's all the above.

+ +

CHAD: One of the interesting things that's been a journey for thoughtbot not only just with you but with several people is up until a few years ago, we hadn't, aside from some office managers or people operations, we hadn't had people in direct client-facing roles who are not designers and developers. And it comes from a place of fear and skepticism about that, historically for us, for me personally. And I don't think I was wrong per se; I was just misguided. And I've learned over the years that when you're afraid of something, there can be some truth in what you're afraid of, but you should let that fear guide you into making good decisions and not let it hold you back from doing anything. And that's what we were doing: we were so afraid of what adding non-designers and developers to the consulting side of the business would mean for us as designers and developers that we didn't do it at all, instead of trying to find people who would be a great fit, who would be great advocates for us, a great fit for the company. And once we figured out the recipe for doing that, I feel like not only did it make thoughtbot better and stronger on the business side, but it made thoughtbot better overall. One of the things we strive for is an inclusive, diverse environment, and that doesn't just mean the obvious things. It also means having different perspectives and experiences that a group can bring to the table that makes the results better and more enjoyable, and more fulfilling to work in. And I think that you've been successful in bringing that to the company, and it felt good and not only you but the other people that we've added in the managing director roles. And that kind of thing that brings that different experience and different skill sets to the table has made thoughtbot better, I think. So, thank you.

+ +

DIANA: Thank you for letting us bring it to the table; not every place lets us do that. But you've set up a culture, to your credit, that I think brings the best out in people. And I think you've enabled that to happen, so thank you right back. [chuckles]

+ +

CHAD: There's another angle to that, which has been on my mind, which is what we were doing in the past was basically forcing designers and developers to do some of those things and potentially setting them up to fail because it wasn't a strength, or it wasn't an area that they were actually interested in. They were just doing it out of love for thoughtbot or wanting to see us succeed. When you put people in a position where they're going to struggle or where they're going to not succeed, that's doing nobody a favor as well. And so that's in part been on my mind because as we've been reorganizing the company and everything, I think that's part of the lens at which we're looking at it: what can we do to make things easier to make us more successful as a team and as individuals in our day-to-day work, too?

+ +

DIANA: I think that there's a lot there. I feel like in every designer; there is a business person because they're breaking things down. They're deconstructing constantly, and they're asking tons of questions that business people just naturally ask. And then developers are super creative, and they're problem solvers, and they do the same thing. I feel like it's a combination of art and science. Everybody's got their science part of it, the developers, designers, even people like me with a business development background. But then when you do enough of that thing, and you're meshed with the people who bring a complementary skill, then you're able to do the art side of it together that you wouldn't get solo, for instance. If you just put a bunch of business development people in a room together, it's very different than when you mix them up with a designer who brings that side of thinking and a developer who brings their thinking. I think together we're better than siloed.

+ +

CHAD: So when it came to the actual transition and having you step into the role of CEO and move into the COO role, and I want to be relatively honest that it wasn't some grand plan that I executed over a period of a long time. And if that had been the case, I think we would have gone about it a little bit differently and certainly with more transparency for the rest of the thoughtbot team. For the listeners, the path there was that Matt Jankowski, a long-time COO and member of the leadership team at thoughtbot, was getting ready to move on. And that wasn't the only thing that was changing. Obviously, 2020 was a big year; it was a difficult year. And so the combination of all of those things and me looking at what does the leadership team at thoughtbot look like going forward? Who is going to fill Matt's responsibilities? That kind of thing, and really breaking down those roles and responsibilities and coming to the conclusion that the CEO role and particularly business development are inherently coupled at the company right now and that we have a lot of things we need to do in front of us and who is the best person to be able to do that? And feeling like it might not be me.

+ +

And the things that I was going to be taking over from Matt operationally were in and of themselves a significant area. I love thoughtbot. I love helping it work better and being close to the client work. And now that we've built an incredible team of managing directors, that was another thing that was on my mind that I've built that team. I'm really proud of that team, and it's an awesome team. But who's going to be the better mentor and leader for that team going forward now that we've got a team of experienced people who are slightly different than just designers and developers and who have different needs and jobs? And again, the best person for that might not be me. And so those were all the thoughts that were going through my head. And then things came together really quickly.

+ +

DIANA: Yeah, they sure did. [laughter] They sure did turn around and come together really quickly. First, I have a lot of admiration for you, in particular, like the way that you're able to take a step back and look at things objectively and not let ego get in the way of things because that's a big deal. Not everybody is able to do that, Chad. And I've worked at a lot of places, as we talked about, and I've seen ego get in the way. And I've seen ego get in the way in a bad way. It's not always a friend. Sometimes it could be a friend, sometimes it's a very powerful friend to have, but sometimes ego can hurt. And so there's a lot of wisdom to that.

+ +

And in terms of the speed at which things came together, yes, I agree; I think that's a reflection of the times we're living in. We're in a time where things can change on a dime, and we just have to be able to pivot and be able to reassess the landscape, see what we have to do, make the necessary modifications and then go. And I'm really proud of both of us and the team of the managing directors and everyone at thoughtbot for our ability to quickly adjust and do what we had to do during the really crazy year that 2020 was.

+ +

CHAD: I spent the majority of 2020 in intense survival mode. And so it wasn't until we were through that period that I realized how much it had affected me, whether it be in burnout ways but also in terms of realizing that we were going to survive. At the end of March, early April, it was the most difficult time. We saw a good portion of our business…new projects were starting, people doing new things. At the end of March, early April, a lot of that new stuff got completely put on hold as the whole world recalibrated. And so we saw a significant decrease in revenue in those months, and we didn't know where it was going to go. So we were very proactive about redoing our numbers and making sure that we weren't going to go out of business and didn't go out of business. And once we were able to do that and to stabilize things, we still needed to spend a significant amount of effort for the rest of the year, working really hard to make sure that we made things less bad. And that was pretty difficult.

+ +

But my main point or my takeaway from the year and part of what has led to this transition is the realization that I don't really have any plans to go anywhere per se, but rather than be like, oh, I need to keep my position forever, it's more we're coming up on the 20-year mark of thoughtbot. When we came up on the 10-year mark of thoughtbot, we asked ourselves the question, “Okay, it's ten years. We're not really going anywhere. What do the next ten years look like?” And so, as we continue to move forward as a company, I think the horizon tends to expand. And it's like, okay, we're coming up on 20 years. What do the next 20 years look like? So, I don't really have any plans to go anywhere, but am I going to be doing this and the same thing in the same way for another 20 years? Probably not. [laughs] I'll be getting close to retirement age. So I always have come to work every day, just trying to create the place that I want to work, doing the kinds of things that I want to do. And I think that motivates everyone at thoughtbot. That's how we all come to work every day. And I think it's one of the things that leads to that culture that we have. And I think this transition has been part of that expanding horizon part of thinking about being a resilient company that is going to last for a long time.

+ +

DIANA: Yeah, absolutely. I think that's one of the things I love most about thoughtbot is just that we're intentional and that we do want to make this a place that people want to work at.

+ +

CHAD: So we asked for questions from the audience, and one of the gists of the episode was what was the actual way that we communicated this change to the company?

+ +

DIANA: So I think we went about it in multiple ways. You notified people in the early stages. And then, we also went about a transition period, which was like the second phase of it. I think you can speak best to the first phase.

+ +

CHAD: Yeah, one of the first things I did was once the decision was made; I met one-on-one with the rest of the C-level team and looped them in on it. And then I think the next thing was crafting a company-wide message that went out to the whole company. I'm not sure if there was much in between those two things.

+ +

DIANA: Yeah, I think that's what it was.

+ +

CHAD: Now, one of the interesting things, as I was saying earlier, is that part of the change that was happening at the same time was Matt transitioning out of the company. And so I think in some ways that made the whole thing a little bit more understandable for people. There was change already happening, and they were together. I think in retrospect, in other ways, or at least one thing I wanted to make sure people understood, is that the COO role and the CEO role going forward aren't necessarily the same as what they were in the past. And so even though Matt was leaving and I was taking on that title, that doesn't necessarily mean I was just going to be doing everything that he did in the same way that he did it. And the same is true for you in the CEO role.

+ +

DIANA: Yeah, we bring our own personalities and our own strengths to the roles. We give each other room to do that. I know that you like to be involved in the development. You like to be involved in sales as well. It's important that things change, that things don't stay the same. I think it's important to evolve and to bring in different viewpoints and change the roles a little bit if we need to, which I think we've done and we're doing.

+ +

CHAD: And so someone asked, “Were people surprised?” I think people were very surprised, don't you?

+ +

DIANA: [chuckles] Yeah, I think so. I think I was surprised, [laughter] starting with me. Yeah, everybody was. But it's understandable; you’re the founder. And I think change does bring an element of surprise in and of itself.

+ +

CHAD: Yeah, I think we got to that place very quickly. But in retrospect, knowing where we ended up, I could have envisioned more proactively saying, “This is a transition,” not even necessarily with you specifically just like “maybe next year I won't be CEO,” like giving people some clue that a transition of some kind might be coming. But I didn't know myself, and so it wasn't really practical to give people. But I think in retrospect, it would have been nice to make it more clear that that's the kind of thing that might be on the table.

+ +

DIANA: I also feel, though, that there is an element like we were speaking about earlier that sometimes things change and they change quickly, and we can see more of that happening in the future. I don't think that's going to stop. I think that actually might increase to some extent. So it's great if we have an advance notice of things, but sometimes there isn't the room or the opportunity to do so.

+ +

CHAD: So then you moved into the role. We had a transition period. What was that like for you?

+ +

DIANA: It was interesting because I thought, well, let me bring things that I always wanted my CEOs to do but never did. And let me not do things that I saw my CEOs doing that I didn't like. [chuckles] Let me start there. And one of the things that I really enjoy, and I think it's part of the culture here, is just being a little goofy and a little silly and just having that freedom. And I actually think that that makes for a better, healthier environment. And I guess I wished my prior CEOs were a little bit less uptight, maybe, if you will, a little bit more goofy, a little bit more fun. And so I think bringing that even more because you already bring that but really doing it together. [chuckles]

+ +

CHAD: Well, I have to be honest, I used to be a lot more goofy than even I am now. And I've just been worn down over the years [laughter], which is why part of this is just making sure that things stay fresh, too. But yes, I really appreciate that.

+ +

DIANA: And also another thing that I would think is really important to me is that voices be heard. It's all a collaboration, right? Because I've worked at some big companies, I would say a lot, but not all of them have been big companies, and it's been very top-down, and it shouldn't be that way, even in big companies. I think that it should be a dialogue. You put something out there, but you also have to hear the feedback. That feedback loop is really important. And you might miss something really, really big if you don't have that feedback loop. And I really enjoy that we are doing that here. We have our director sessions where we break out into teams, and people come up with ideas, and they share those ideas. And we take that in, and we synthesize it, and we say, “Yes, that's valid. Don't agree with that. Definitely agree with that.” We're able to have that dialogue that I think serves us really, really well, which is another thing that I'm really enjoying about my new role and working with you in this capacity. It’s great.

+ +

CHAD: I have a couple of things that surprised me, and I'm curious what surprised you. But the first is that I knew that things were going to have to change. There were too many pent-up questions at thoughtbot. It was too obvious that the pandemic was going to last a lot more longer, but I didn't know what any of those things were. I just had a sense that they were going to change. And so the process of navigating that change with you and not being the one who is CEO while that's happening has been really positive for me and surprising. What's been surprising for you?

+ +

DIANA: Very few things surprise me if I'm honest. [laughs] I feel like with time, with so many experiences people have, things get less and less surprising the more time we're on this planet. I don't feel that surprised about things. I actually have gotten to a point in my life where I'm seeing things as opportunities (and you and I have talked about this a lot) and leaning into those challenges and turning them into what's the silver lining here? Can we find the silver lining, and how do we pull that silver lining out and actually turn that into something really strong? I'm doing that more and more. And I feel like the pandemic has actually really called that out and made that a strength in a way which is ironic, but it's actually been really a very useful skill.

+ +

CHAD: So the other thing that's been surprising or unexpected, once the transition was over, some things happened that pulled me into client work much more than I was originally expecting. And that's been really interesting because I feel like it's both good and bad. There are things that I would historically be involved in, and even in my new role, I should be, and I just can't be. So all of you are left to do things without me, but there was never any doubt in my mind that you'd be able to handle it or that the team would be able to handle it. But I think it's actually been an interesting thing to have those two things coincide. We've got these transitions going on, and we've got the reorganization, and suddenly, I'm a lot less available than I have been in the past. So that's been something that's been unexpected that we've had to deal with.

+ +

DIANA: I think one of the things that's helped me deal with that is that you've been working on some very important projects for the world, and that really do help humanity. And I just think that that's been one thing I keep thinking about: Chad’s doing really important stuff right now. So I think that's been a good thing to keep in mind as well. And then there's another side to it, too, where it's like a parent analogy. Even though I'm not a parent, I have young people in my life. You leave them alone sometimes, and sometimes they'll surprise you, and they'll actually be able to take care of themselves. And they're able to actually do more than you thought they would because you left them alone and it’s like, let's see what they do. And then they actually do something really cool. Some of that has played into this, too, which is interesting.

+ +

CHAD: Well, from my perspective, it's almost the opposite of what one might think, which is I never had any trust issues. And I always believe in the thoughtbot team to be able to do things. But oftentimes, I feel like I'm being asked for permission or being checked in with just because I'm the founder and that kind of thing. And so I actually think it's been healthy to be not available and be pretty explicit about that because then it means that I'm not being an artificial gatekeeper for people and things.

+ +

DIANA: And it also strengthens the decision-making, I think, because people get to practice that without you and not become dependent on you solving the problem for them, for instance. That's another healthy side to that.

+ +

CHAD: So in upcoming episodes, we're going to talk about the reorg, and a big part of that is going remote. We don't need to dig too much into it now, but through the lens of becoming CEO through that transition, that has been entirely remote. For me, as CEO, I was traveling to each of the studios meeting people in person once a month. How has it been going through this transition, becoming more embedded into the rest of the company at different levels and that kind of thing and having it be entirely remote?

+ +

DIANA: It's got its pros and cons. In some ways, we've been able to move really quickly on some things. We've also been able to bring perspectives that maybe we wouldn't have thought about before. On the other hand, I really enjoy getting out and seeing people in person, and I feel like there's a chemistry that's developed when you're able to go to lunch together or just have coffee together. And I’m missing that side of it and looking forward to the day when we can do that safely, especially the folks in London; getting a chance to do that with them would be terrific. But I think as with anything, it's got its pros and cons associated with it. We’re trying to lean into the pros as much as possible because this won't always be the case. There will be a time when we all come together. And we might as well just make the most of this time that we're apart to move as quickly as we can, learn as much as we can, and take those learnings so that when we are in person, and we do connect that we can then explore other advantages that that brings us.

+ +

CHAD: So when it comes to working from anywhere, which we're specifically not saying that we're an entirely remote company; it’s just that we are now working from anywhere going forward. And that was an intentional choice. But that's been an interesting transition; I think because previously, our whole strategy as a company was local studios working with local clients with a local team. Our culture was built up around our physical places of work. So my question for you as the CEO of thoughtbot is how do you maintain that culture, or how do you change it to not lose what people think makes thoughtbot great along the way?

+ +

DIANA: I think we're in the process of discovering that right now. And we are learning things that work and things that don't work. And I don't have an answer. I can only speak to things that we're trying to do. I have noticed there have been a lot of people who have left and gone to different parts of the country, or some have even left the country. And I think that was really surprising. I wasn't expecting people to move to some of the places that they've moved. But knowing that they have an increased comfort level in their lives because they're closer to their families or they're doing things that they need to do right now in certain locations that are not where they started gives me a sense of reassurance that this was the right decision because we're giving people that space, that ability to do that. And some people really did need to move to different locations and deal with certain things. And then just giving that extra flexibility that’s honestly practical, it's just practicality. I feel like all we've done is introduced the element of this is just a practical application of life. Like, if you need to take your kids to school or if you need to go to the doctor, go to the doctor, it's okay. If you need to run an errand, go ahead and do that. You don't have to be tied to a desk in one location all day long. It's healthier if you do what you have to do and then get back to work when you're ready.

+ +

And then we've had a lot of issues that have impacted society in general that have affected thoughtbot overall, like the things that happened with George Floyd and some of the things we're hearing about recently in Atlanta, killings in Atlanta. Sometimes people just need to take a moment and process all that and see how do we make this world a better place and how do we bring our best selves to thoughtbot? And in our new remote structure, we're giving that, not that we didn't do it before, but it's just giving that extra space that it's okay, it's safe. It's safe to do that. Take the time you need and the place that you need, if it's closer to your families, do that. I feel like that's been a very practical thing that we've done.

+ +

There's a sense of loss because I miss all the New Yorkers. [chuckles] I’d see them often, and everybody would get together on Fridays and have lunch together, and there's a sense of that loss. Seeing our Slack channel go away was sort of sad in a way, but then happy in other ways. But that's true with everything that changes. With everything that changes, there's a beginning and an end; there’s a transition. And we're going through that. I'm looking forward to the days that we can bring people together, maybe in an in-person summit. I think that's going to be fantastic. It's going to be so much fun. But right now, the summit that we had virtually was a blast, and everybody was virtual, and folks had a really good time. So it's just we're finding that right balance. We're testing and trying things. I hope people feel they can bring ideas to us, and we can implement different tactics, tricks, cultures, all that is work in process.

+ +

CHAD: I think we're in for an interesting time over the next year because part of why we had offices before was that highly collaborative environment with not only the thoughtbot team but with the clients that we work with and whether that would have been in their office or in ours. And when that was completely off the table, there was no discussion. We didn't need to be in person with someone. The team wasn't going to be based in New York because you're in New York, those kinds of things. And so the pandemic was the kick in the pants we needed. And since clients were also entirely remote, it just wasn't an issue. It'll be interesting over the next year as we navigate being able to be in person again staffing projects remotely, having teams be distributed, that kind of thing. It will be fine. If we didn't think it would be fine, we wouldn't have done what we did, but just because it will end up okay doesn't mean that it won't be a little bit of a challenge or interesting.

+ +

DIANA: Absolutely, yes, I agree. I think we may even be more experimental and traveling to different cities where the client is, for example, together as a group, which we really didn't do much of in the past. We've talked about having things like pop-up offices, which is something we will experiment with. So there's some experimentation to happen. I know we're going to make mistakes. But I know we're also going to do some stuff that's going to be really, really great, too. We have to try it, though. We won't learn until we try it and lean into what works. Let's do more of the stuff that's working.

+ +

CHAD: Yeah. And the other thing, and I think we communicated this to the team, which is like, this is what we're doing today. It's going to be iterative. And one of the things people need to keep in mind is that we spend a lot of money on offices. And so once we remove that, that money can be put to completely different things whether it be getting together in person more often, or it be other benefits or just operating more profitably so that we're all working a little less stressed. There are all these things that are going to come out of it. And that doesn't even necessarily mean that three years from now, we won't have small offices in some places that look very different than what the previous thoughtbot offices look like. But the best way forward, we felt, was to completely wipe the slate clean and rebuild what it means to be at thoughtbot and how we're working both financially but also from making this new structure work really well perspective.

+ +

DIANA: Yes, exactly.

+ +

CHAD: So, any parting words of wisdom or thoughts?

+ +

DIANA: Yeah. You made this really comfortable for me. I was completely out of my comfort zone, but I think you made me feel comfortable in having a podcast conversation. So thank you for that. It was a lot of fun.

+ +

CHAD: If people want to get in touch with you, ask you questions, follow along with you, where is the best place for them to do that?

+ +

DIANA: Email is great. Also, I am getting more active on Twitter now. It's something I'm having to do, but you can also find me on Twitter @dianabald, first name, last name. And my email is dianabald@thoughtbot.com.

+ +

CHAD: Awesome. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel and Lindsey on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot and produced and edited by Thom Obarski. Thanks for listening as always, and see you next time

+ +

This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Diana Bald.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Diana Bald, the new CEO of thoughtbot, to discuss her background, the organizational changes to the leadership of the company, and the reasoning behind them.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Transcript:

+ +

CHAD PYTEL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And today, I'm joined by the new CEO of thoughtbot, Diana Bald. Thanks for joining me, Diana.

+ +

DIANA BALD: Hi, Chad. This is so fun. This is so exciting. I've only done one podcast before this, so I'm excited.

+ +

CHAD: Well, don't worry. You can still be CEO of thoughtbot even if you're not a podcaster. [laughter]

+ +

DIANA: Okay, that's great to know.

+ +

CHAD: So it's been several months now. So I want to go back and talk about how we arrived here. But I'm curious, how are you feeling now? What does it feel like?

+ +

DIANA: It feels great. I think I'm getting more and more comfortable every day, which is amazing. And I think the year has gotten off to a great start, so that's helping me feel more comfortable as well. So far, so good.

+ +

CHAD: So for folks who are listening, I'm sure they're wondering who are you? [chuckles] Let's give the audience a little peek into your background and how you arrived at thoughtbot, and the role you originally had.

+ +

DIANA: Great. How far back do you want me to go?

+ +

CHAD: As far as back as you're comfortable.

+ +

DIANA: Okay. I actually was really interested in technology at a younger age. I put myself through undergrad and grad school while I was doing tech roles. I trained lawyers on how to move from the analog world into the digital world. That was one of my very first jobs at a law firm. And then, shortly after that, I did webmaster work when I was putting myself through MBA school. It was a very different world than it is now. This is way back when the internet was really just kicking off; it was 1998 to 2001, around that time. When I graduated from MBA school, I was recruited into Univision into their leadership pipeline, which was very much focused on business development. But my very first project there was web integration, integrating the univision.com with their TV and radio. That was when I started to move away from technology. I was there for ten years. I had a variety of different roles, a really fun job. I got to experience a lot of different roles, lived in a lot of different cities. I spent a lot of time in Philadelphia, where I actually launched a television station in Spanish, which was really fun. And then I came to New York.

+ +

After Univision, I spent four years in the advertising and marketing world. I spent two years with IPG at ID Media, which was a direct marketing agency. And then two years at MDC Partners at an agency called TargetCast, which later became Assembly, which was more media buying and planning. And then, when I left there, I went to Liberty Mutual for three years. And at Liberty Mutual, I fell back in love with technology. I missed it. I was doing a lot of strategic partnership opportunities with really interesting companies that were doing brand new business models and disrupting insurance, and there was a lot of exposure to telematics and IoT. And it was just calling me back, and I was like, I got to get back to tech. And somehow, I don't recall exactly how, but I found you. You and I chatted, and then I fell in love with thoughtbot [chuckles], and then after that, the rest is history.

+ +

CHAD: You joined us as the Managing Director of the New York City studio. I want to say that was a position we were advertising for, and you applied to it.

+ +

DIANA: Yeah.

+ +

CHAD: And one of the things that really stood out when I first met you and as we've got to know each other and work together is the variety of experience that you had because I've only ever done what I do, which has its own strengths. So the fact that I started freelancing web design and development in high school and have continued to do that now for 25 years is a strength, but it's also, aside from the jobs I had as a dishwasher or the checkout person at the grocery store, this is literally all I've done. And the variety of experience you have not only helps thoughtbot be better, but I also think it positions you well for our business. In consulting, you need to be unflappable in a lot of circumstances, and I think you're good at that. You're good at maintaining an even keel and talking with customers and dealing with difficult situations and that kind of thing.

+ +

DIANA: In some ways, I'm envious that you have been able to stick with development the entire time; that’s really, really cool. But in other ways, I can see what you're talking about because I do feel like I have had a variety of roles and seen a lot of different situations. And every one of these situations has had their challenges. And they've all been generalist roles where I've dealt with clients, and then those clients had challenges in their respective industries. So I've really learned a lot about keeping things in perspective, if you will, more so than people who are in a role for a particular time and see that aspect of it. I'm seeing things from a bird's eye view much more often because maybe I've seen the situation in the past only it was in this industry, or I've seen this situation in the past, but it had these characters. And it's like I can carry that knowledge over to thoughtbot, which has been really helpful.

+ +

CHAD: So the managing director role, I think I've described it on the show before, and it’s sort of the CEO of the individual studio. That’s the way that it works. You oversaw the individual studio, and you were responsible for business development and the whole P&L of the studio, the whole business. Going back to first joining thoughtbot, what was a surprise to you?

+ +

DIANA: How comfortable I felt. [chuckles] I felt like, oh, I'm home. I felt like, oh, there you are. I've been looking for you all my life kind of feeling. I don't know how to explain it. It just felt really good. Like, okay, these are problems. I like these problems. Or this is really joyful. I felt like I was actually in my element for probably the first time in my career, although I've had some jobs where I felt pretty much in my comfort zone, but thoughtbot took it to a totally new level. And I don't know if it's thoughtbot, or the role, or the combination of the two, or maybe it's me where I am now in my life and just having had all these different jobs and experiences. Maybe it's all the above.

+ +

CHAD: One of the interesting things that's been a journey for thoughtbot not only just with you but with several people is up until a few years ago, we hadn't, aside from some office managers or people operations, we hadn't had people in direct client-facing roles who are not designers and developers. And it comes from a place of fear and skepticism about that, historically for us, for me personally. And I don't think I was wrong per se; I was just misguided. And I've learned over the years that when you're afraid of something, there can be some truth in what you're afraid of, but you should let that fear guide you into making good decisions and not let it hold you back from doing anything. And that's what we were doing: we were so afraid of what adding non-designers and developers to the consulting side of the business would mean for us as designers and developers that we didn't do it at all, instead of trying to find people who would be a great fit, who would be great advocates for us, a great fit for the company. And once we figured out the recipe for doing that, I feel like not only did it make thoughtbot better and stronger on the business side, but it made thoughtbot better overall. One of the things we strive for is an inclusive, diverse environment, and that doesn't just mean the obvious things. It also means having different perspectives and experiences that a group can bring to the table that makes the results better and more enjoyable, and more fulfilling to work in. And I think that you've been successful in bringing that to the company, and it felt good and not only you but the other people that we've added in the managing director roles. And that kind of thing that brings that different experience and different skill sets to the table has made thoughtbot better, I think. So, thank you.

+ +

DIANA: Thank you for letting us bring it to the table; not every place lets us do that. But you've set up a culture, to your credit, that I think brings the best out in people. And I think you've enabled that to happen, so thank you right back. [chuckles]

+ +

CHAD: There's another angle to that, which has been on my mind, which is what we were doing in the past was basically forcing designers and developers to do some of those things and potentially setting them up to fail because it wasn't a strength, or it wasn't an area that they were actually interested in. They were just doing it out of love for thoughtbot or wanting to see us succeed. When you put people in a position where they're going to struggle or where they're going to not succeed, that's doing nobody a favor as well. And so that's in part been on my mind because as we've been reorganizing the company and everything, I think that's part of the lens at which we're looking at it: what can we do to make things easier to make us more successful as a team and as individuals in our day-to-day work, too?

+ +

DIANA: I think that there's a lot there. I feel like in every designer; there is a business person because they're breaking things down. They're deconstructing constantly, and they're asking tons of questions that business people just naturally ask. And then developers are super creative, and they're problem solvers, and they do the same thing. I feel like it's a combination of art and science. Everybody's got their science part of it, the developers, designers, even people like me with a business development background. But then when you do enough of that thing, and you're meshed with the people who bring a complementary skill, then you're able to do the art side of it together that you wouldn't get solo, for instance. If you just put a bunch of business development people in a room together, it's very different than when you mix them up with a designer who brings that side of thinking and a developer who brings their thinking. I think together we're better than siloed.

+ +

CHAD: So when it came to the actual transition and having you step into the role of CEO and move into the COO role, and I want to be relatively honest that it wasn't some grand plan that I executed over a period of a long time. And if that had been the case, I think we would have gone about it a little bit differently and certainly with more transparency for the rest of the thoughtbot team. For the listeners, the path there was that Matt Jankowski, a long-time COO and member of the leadership team at thoughtbot, was getting ready to move on. And that wasn't the only thing that was changing. Obviously, 2020 was a big year; it was a difficult year. And so the combination of all of those things and me looking at what does the leadership team at thoughtbot look like going forward? Who is going to fill Matt's responsibilities? That kind of thing, and really breaking down those roles and responsibilities and coming to the conclusion that the CEO role and particularly business development are inherently coupled at the company right now and that we have a lot of things we need to do in front of us and who is the best person to be able to do that? And feeling like it might not be me.

+ +

And the things that I was going to be taking over from Matt operationally were in and of themselves a significant area. I love thoughtbot. I love helping it work better and being close to the client work. And now that we've built an incredible team of managing directors, that was another thing that was on my mind that I've built that team. I'm really proud of that team, and it's an awesome team. But who's going to be the better mentor and leader for that team going forward now that we've got a team of experienced people who are slightly different than just designers and developers and who have different needs and jobs? And again, the best person for that might not be me. And so those were all the thoughts that were going through my head. And then things came together really quickly.

+ +

DIANA: Yeah, they sure did. [laughter] They sure did turn around and come together really quickly. First, I have a lot of admiration for you, in particular, like the way that you're able to take a step back and look at things objectively and not let ego get in the way of things because that's a big deal. Not everybody is able to do that, Chad. And I've worked at a lot of places, as we talked about, and I've seen ego get in the way. And I've seen ego get in the way in a bad way. It's not always a friend. Sometimes it could be a friend, sometimes it's a very powerful friend to have, but sometimes ego can hurt. And so there's a lot of wisdom to that.

+ +

And in terms of the speed at which things came together, yes, I agree; I think that's a reflection of the times we're living in. We're in a time where things can change on a dime, and we just have to be able to pivot and be able to reassess the landscape, see what we have to do, make the necessary modifications and then go. And I'm really proud of both of us and the team of the managing directors and everyone at thoughtbot for our ability to quickly adjust and do what we had to do during the really crazy year that 2020 was.

+ +

CHAD: I spent the majority of 2020 in intense survival mode. And so it wasn't until we were through that period that I realized how much it had affected me, whether it be in burnout ways but also in terms of realizing that we were going to survive. At the end of March, early April, it was the most difficult time. We saw a good portion of our business…new projects were starting, people doing new things. At the end of March, early April, a lot of that new stuff got completely put on hold as the whole world recalibrated. And so we saw a significant decrease in revenue in those months, and we didn't know where it was going to go. So we were very proactive about redoing our numbers and making sure that we weren't going to go out of business and didn't go out of business. And once we were able to do that and to stabilize things, we still needed to spend a significant amount of effort for the rest of the year, working really hard to make sure that we made things less bad. And that was pretty difficult.

+ +

But my main point or my takeaway from the year and part of what has led to this transition is the realization that I don't really have any plans to go anywhere per se, but rather than be like, oh, I need to keep my position forever, it's more we're coming up on the 20-year mark of thoughtbot. When we came up on the 10-year mark of thoughtbot, we asked ourselves the question, “Okay, it's ten years. We're not really going anywhere. What do the next ten years look like?” And so, as we continue to move forward as a company, I think the horizon tends to expand. And it's like, okay, we're coming up on 20 years. What do the next 20 years look like? So, I don't really have any plans to go anywhere, but am I going to be doing this and the same thing in the same way for another 20 years? Probably not. [laughs] I'll be getting close to retirement age. So I always have come to work every day, just trying to create the place that I want to work, doing the kinds of things that I want to do. And I think that motivates everyone at thoughtbot. That's how we all come to work every day. And I think it's one of the things that leads to that culture that we have. And I think this transition has been part of that expanding horizon part of thinking about being a resilient company that is going to last for a long time.

+ +

DIANA: Yeah, absolutely. I think that's one of the things I love most about thoughtbot is just that we're intentional and that we do want to make this a place that people want to work at.

+ +

CHAD: So we asked for questions from the audience, and one of the gists of the episode was what was the actual way that we communicated this change to the company?

+ +

DIANA: So I think we went about it in multiple ways. You notified people in the early stages. And then, we also went about a transition period, which was like the second phase of it. I think you can speak best to the first phase.

+ +

CHAD: Yeah, one of the first things I did was once the decision was made; I met one-on-one with the rest of the C-level team and looped them in on it. And then I think the next thing was crafting a company-wide message that went out to the whole company. I'm not sure if there was much in between those two things.

+ +

DIANA: Yeah, I think that's what it was.

+ +

CHAD: Now, one of the interesting things, as I was saying earlier, is that part of the change that was happening at the same time was Matt transitioning out of the company. And so I think in some ways that made the whole thing a little bit more understandable for people. There was change already happening, and they were together. I think in retrospect, in other ways, or at least one thing I wanted to make sure people understood, is that the COO role and the CEO role going forward aren't necessarily the same as what they were in the past. And so even though Matt was leaving and I was taking on that title, that doesn't necessarily mean I was just going to be doing everything that he did in the same way that he did it. And the same is true for you in the CEO role.

+ +

DIANA: Yeah, we bring our own personalities and our own strengths to the roles. We give each other room to do that. I know that you like to be involved in the development. You like to be involved in sales as well. It's important that things change, that things don't stay the same. I think it's important to evolve and to bring in different viewpoints and change the roles a little bit if we need to, which I think we've done and we're doing.

+ +

CHAD: And so someone asked, “Were people surprised?” I think people were very surprised, don't you?

+ +

DIANA: [chuckles] Yeah, I think so. I think I was surprised, [laughter] starting with me. Yeah, everybody was. But it's understandable; you’re the founder. And I think change does bring an element of surprise in and of itself.

+ +

CHAD: Yeah, I think we got to that place very quickly. But in retrospect, knowing where we ended up, I could have envisioned more proactively saying, “This is a transition,” not even necessarily with you specifically just like “maybe next year I won't be CEO,” like giving people some clue that a transition of some kind might be coming. But I didn't know myself, and so it wasn't really practical to give people. But I think in retrospect, it would have been nice to make it more clear that that's the kind of thing that might be on the table.

+ +

DIANA: I also feel, though, that there is an element like we were speaking about earlier that sometimes things change and they change quickly, and we can see more of that happening in the future. I don't think that's going to stop. I think that actually might increase to some extent. So it's great if we have an advance notice of things, but sometimes there isn't the room or the opportunity to do so.

+ +

CHAD: So then you moved into the role. We had a transition period. What was that like for you?

+ +

DIANA: It was interesting because I thought, well, let me bring things that I always wanted my CEOs to do but never did. And let me not do things that I saw my CEOs doing that I didn't like. [chuckles] Let me start there. And one of the things that I really enjoy, and I think it's part of the culture here, is just being a little goofy and a little silly and just having that freedom. And I actually think that that makes for a better, healthier environment. And I guess I wished my prior CEOs were a little bit less uptight, maybe, if you will, a little bit more goofy, a little bit more fun. And so I think bringing that even more because you already bring that but really doing it together. [chuckles]

+ +

CHAD: Well, I have to be honest, I used to be a lot more goofy than even I am now. And I've just been worn down over the years [laughter], which is why part of this is just making sure that things stay fresh, too. But yes, I really appreciate that.

+ +

DIANA: And also another thing that I would think is really important to me is that voices be heard. It's all a collaboration, right? Because I've worked at some big companies, I would say a lot, but not all of them have been big companies, and it's been very top-down, and it shouldn't be that way, even in big companies. I think that it should be a dialogue. You put something out there, but you also have to hear the feedback. That feedback loop is really important. And you might miss something really, really big if you don't have that feedback loop. And I really enjoy that we are doing that here. We have our director sessions where we break out into teams, and people come up with ideas, and they share those ideas. And we take that in, and we synthesize it, and we say, “Yes, that's valid. Don't agree with that. Definitely agree with that.” We're able to have that dialogue that I think serves us really, really well, which is another thing that I'm really enjoying about my new role and working with you in this capacity. It’s great.

+ +

CHAD: I have a couple of things that surprised me, and I'm curious what surprised you. But the first is that I knew that things were going to have to change. There were too many pent-up questions at thoughtbot. It was too obvious that the pandemic was going to last a lot more longer, but I didn't know what any of those things were. I just had a sense that they were going to change. And so the process of navigating that change with you and not being the one who is CEO while that's happening has been really positive for me and surprising. What's been surprising for you?

+ +

DIANA: Very few things surprise me if I'm honest. [laughs] I feel like with time, with so many experiences people have, things get less and less surprising the more time we're on this planet. I don't feel that surprised about things. I actually have gotten to a point in my life where I'm seeing things as opportunities (and you and I have talked about this a lot) and leaning into those challenges and turning them into what's the silver lining here? Can we find the silver lining, and how do we pull that silver lining out and actually turn that into something really strong? I'm doing that more and more. And I feel like the pandemic has actually really called that out and made that a strength in a way which is ironic, but it's actually been really a very useful skill.

+ +

CHAD: So the other thing that's been surprising or unexpected, once the transition was over, some things happened that pulled me into client work much more than I was originally expecting. And that's been really interesting because I feel like it's both good and bad. There are things that I would historically be involved in, and even in my new role, I should be, and I just can't be. So all of you are left to do things without me, but there was never any doubt in my mind that you'd be able to handle it or that the team would be able to handle it. But I think it's actually been an interesting thing to have those two things coincide. We've got these transitions going on, and we've got the reorganization, and suddenly, I'm a lot less available than I have been in the past. So that's been something that's been unexpected that we've had to deal with.

+ +

DIANA: I think one of the things that's helped me deal with that is that you've been working on some very important projects for the world, and that really do help humanity. And I just think that that's been one thing I keep thinking about: Chad’s doing really important stuff right now. So I think that's been a good thing to keep in mind as well. And then there's another side to it, too, where it's like a parent analogy. Even though I'm not a parent, I have young people in my life. You leave them alone sometimes, and sometimes they'll surprise you, and they'll actually be able to take care of themselves. And they're able to actually do more than you thought they would because you left them alone and it’s like, let's see what they do. And then they actually do something really cool. Some of that has played into this, too, which is interesting.

+ +

CHAD: Well, from my perspective, it's almost the opposite of what one might think, which is I never had any trust issues. And I always believe in the thoughtbot team to be able to do things. But oftentimes, I feel like I'm being asked for permission or being checked in with just because I'm the founder and that kind of thing. And so I actually think it's been healthy to be not available and be pretty explicit about that because then it means that I'm not being an artificial gatekeeper for people and things.

+ +

DIANA: And it also strengthens the decision-making, I think, because people get to practice that without you and not become dependent on you solving the problem for them, for instance. That's another healthy side to that.

+ +

CHAD: So in upcoming episodes, we're going to talk about the reorg, and a big part of that is going remote. We don't need to dig too much into it now, but through the lens of becoming CEO through that transition, that has been entirely remote. For me, as CEO, I was traveling to each of the studios meeting people in person once a month. How has it been going through this transition, becoming more embedded into the rest of the company at different levels and that kind of thing and having it be entirely remote?

+ +

DIANA: It's got its pros and cons. In some ways, we've been able to move really quickly on some things. We've also been able to bring perspectives that maybe we wouldn't have thought about before. On the other hand, I really enjoy getting out and seeing people in person, and I feel like there's a chemistry that's developed when you're able to go to lunch together or just have coffee together. And I’m missing that side of it and looking forward to the day when we can do that safely, especially the folks in London; getting a chance to do that with them would be terrific. But I think as with anything, it's got its pros and cons associated with it. We’re trying to lean into the pros as much as possible because this won't always be the case. There will be a time when we all come together. And we might as well just make the most of this time that we're apart to move as quickly as we can, learn as much as we can, and take those learnings so that when we are in person, and we do connect that we can then explore other advantages that that brings us.

+ +

CHAD: So when it comes to working from anywhere, which we're specifically not saying that we're an entirely remote company; it’s just that we are now working from anywhere going forward. And that was an intentional choice. But that's been an interesting transition; I think because previously, our whole strategy as a company was local studios working with local clients with a local team. Our culture was built up around our physical places of work. So my question for you as the CEO of thoughtbot is how do you maintain that culture, or how do you change it to not lose what people think makes thoughtbot great along the way?

+ +

DIANA: I think we're in the process of discovering that right now. And we are learning things that work and things that don't work. And I don't have an answer. I can only speak to things that we're trying to do. I have noticed there have been a lot of people who have left and gone to different parts of the country, or some have even left the country. And I think that was really surprising. I wasn't expecting people to move to some of the places that they've moved. But knowing that they have an increased comfort level in their lives because they're closer to their families or they're doing things that they need to do right now in certain locations that are not where they started gives me a sense of reassurance that this was the right decision because we're giving people that space, that ability to do that. And some people really did need to move to different locations and deal with certain things. And then just giving that extra flexibility that’s honestly practical, it's just practicality. I feel like all we've done is introduced the element of this is just a practical application of life. Like, if you need to take your kids to school or if you need to go to the doctor, go to the doctor, it's okay. If you need to run an errand, go ahead and do that. You don't have to be tied to a desk in one location all day long. It's healthier if you do what you have to do and then get back to work when you're ready.

+ +

And then we've had a lot of issues that have impacted society in general that have affected thoughtbot overall, like the things that happened with George Floyd and some of the things we're hearing about recently in Atlanta, killings in Atlanta. Sometimes people just need to take a moment and process all that and see how do we make this world a better place and how do we bring our best selves to thoughtbot? And in our new remote structure, we're giving that, not that we didn't do it before, but it's just giving that extra space that it's okay, it's safe. It's safe to do that. Take the time you need and the place that you need, if it's closer to your families, do that. I feel like that's been a very practical thing that we've done.

+ +

There's a sense of loss because I miss all the New Yorkers. [chuckles] I’d see them often, and everybody would get together on Fridays and have lunch together, and there's a sense of that loss. Seeing our Slack channel go away was sort of sad in a way, but then happy in other ways. But that's true with everything that changes. With everything that changes, there's a beginning and an end; there’s a transition. And we're going through that. I'm looking forward to the days that we can bring people together, maybe in an in-person summit. I think that's going to be fantastic. It's going to be so much fun. But right now, the summit that we had virtually was a blast, and everybody was virtual, and folks had a really good time. So it's just we're finding that right balance. We're testing and trying things. I hope people feel they can bring ideas to us, and we can implement different tactics, tricks, cultures, all that is work in process.

+ +

CHAD: I think we're in for an interesting time over the next year because part of why we had offices before was that highly collaborative environment with not only the thoughtbot team but with the clients that we work with and whether that would have been in their office or in ours. And when that was completely off the table, there was no discussion. We didn't need to be in person with someone. The team wasn't going to be based in New York because you're in New York, those kinds of things. And so the pandemic was the kick in the pants we needed. And since clients were also entirely remote, it just wasn't an issue. It'll be interesting over the next year as we navigate being able to be in person again staffing projects remotely, having teams be distributed, that kind of thing. It will be fine. If we didn't think it would be fine, we wouldn't have done what we did, but just because it will end up okay doesn't mean that it won't be a little bit of a challenge or interesting.

+ +

DIANA: Absolutely, yes, I agree. I think we may even be more experimental and traveling to different cities where the client is, for example, together as a group, which we really didn't do much of in the past. We've talked about having things like pop-up offices, which is something we will experiment with. So there's some experimentation to happen. I know we're going to make mistakes. But I know we're also going to do some stuff that's going to be really, really great, too. We have to try it, though. We won't learn until we try it and lean into what works. Let's do more of the stuff that's working.

+ +

CHAD: Yeah. And the other thing, and I think we communicated this to the team, which is like, this is what we're doing today. It's going to be iterative. And one of the things people need to keep in mind is that we spend a lot of money on offices. And so once we remove that, that money can be put to completely different things whether it be getting together in person more often, or it be other benefits or just operating more profitably so that we're all working a little less stressed. There are all these things that are going to come out of it. And that doesn't even necessarily mean that three years from now, we won't have small offices in some places that look very different than what the previous thoughtbot offices look like. But the best way forward, we felt, was to completely wipe the slate clean and rebuild what it means to be at thoughtbot and how we're working both financially but also from making this new structure work really well perspective.

+ +

DIANA: Yes, exactly.

+ +

CHAD: So, any parting words of wisdom or thoughts?

+ +

DIANA: Yeah. You made this really comfortable for me. I was completely out of my comfort zone, but I think you made me feel comfortable in having a podcast conversation. So thank you for that. It was a lot of fun.

+ +

CHAD: If people want to get in touch with you, ask you questions, follow along with you, where is the best place for them to do that?

+ +

DIANA: Email is great. Also, I am getting more active on Twitter now. It's something I'm having to do, but you can also find me on Twitter @dianabald, first name, last name. And my email is dianabald@thoughtbot.com.

+ +

CHAD: Awesome. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel and Lindsey on Twitter @Lindsey3D. This podcast is brought to you by thoughtbot and produced and edited by Thom Obarski. Thanks for listening as always, and see you next time

+ +

This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Special Guest: Diana Bald.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ID_xuZwH + + ]]> + + Chad Pytel + Diana Bald + + + Values - ShearShare + https://podcast.thoughtbot.com/391 + 3eccfed6-5825-45db-8c6d-ef258c6e37c3 + Mon, 21 Dec 2020 00:15:00 -0500 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, discussing culture-fit with new hires, incorporating values into brand-thinking, fostering relationships, and planning for 2021. + 43:50 + no + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, discussing culture-fit with new hires, incorporating values into brand-thinking, fostering relationships, and planning for 2021. +Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey (https://docs.google.com/forms/d/e/1FAIpQLScc386ccM-nS_pcLClG1fIAH4Kr4L5jlSY4eidKa93L5DSztQ/viewform). +Thanks! +This episode is sponsored by HelloFresh (http://HelloFresh.com/robots80) +Enter code ROBOTS80 to get a total of $80 off, including free shipping! +ShearShare (https://shearshare.com/) +ShearShare on Instagram (https://www.instagram.com/shearshare/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: ShearShare. + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, discussing culture-fit with new hires, incorporating values into brand-thinking, fostering relationships, and planning for 2021.

+ +
+ +
    +

  • Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

    +Thanks!

    • +

  • This episode is sponsored by HelloFresh

    +Enter code ROBOTS80 to get a total of $80 off, including free shipping!

    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, discussing culture-fit with new hires, incorporating values into brand-thinking, fostering relationships, and planning for 2021.

+ +
+ +
    +

  • Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

    +Thanks!

    • +

  • This episode is sponsored by HelloFresh

    +Enter code ROBOTS80 to get a total of $80 off, including free shipping!

    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+AUhuHu-V + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Values - Teikametrics + https://podcast.thoughtbot.com/390 + fec3e2be-cb0b-487a-9205-713fda6752cd + Mon, 30 Nov 2020 00:15:00 -0500 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the intermingling importance of mission, vision, and values. + 40:24 + no + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the intermingling importance of mission, vision, and values. +Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey (https://docs.google.com/forms/d/e/1FAIpQLScc386ccM-nS_pcLClG1fIAH4Kr4L5jlSY4eidKa93L5DSztQ/viewform). +Thanks! +Teikametrics (https://www.teikametrics.com/) +Blitzscaling (https://amzn.to/3fDJxy4)- Reid Hoffman +Jeff Weiner - CS183 at Stanford (https://youtu.be/cYN3ghAam14) +Dunbar's number (https://en.wikipedia.org/wiki/Dunbar%27s_number) +Previous Netflix Culture Deck (https://www.slideshare.net/reed2001/culture-1798664) +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the intermingling importance of mission, vision, and values.

+ +
+ +

Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

+Thanks!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the intermingling importance of mission, vision, and values.

+ +
+ +

Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

+Thanks!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+zsDUDpBO + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Values - Nurse-1-1 + https://podcast.thoughtbot.com/389 + 09a89e73-1e27-4ae7-a06d-bb56f4140a77 + Mon, 16 Nov 2020 00:15:00 -0500 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss crafting values with purpose, living those values in the product's messaging & marketing, choosing not to publicly publish them, and what the landscape of healthcare looks like going into 2021. + 41:18 + no + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss crafting values with purpose, living those values in the product's messaging & marketing, choosing not to publicly publish them, and what the landscape of healthcare looks like going into 2021. +Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey (https://docs.google.com/forms/d/e/1FAIpQLScc386ccM-nS_pcLClG1fIAH4Kr4L5jlSY4eidKa93L5DSztQ/viewform). +Thanks! +This episode is sponsored by HelloFresh (http://HelloFresh.com/robots90) +Enter code ROBOTS90 to get a total of $90 off, including free shipping! +Nurse-1-1 (https://nurse-1-1.com/) +Michael on Twitter (https://twitter.com/MichaelSheeley) +Nurse-1-1 on Instagram (https://www.instagram.com/nurseoneone/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Nurse-1-1. + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss crafting values with purpose, living those values in the product's messaging & marketing, choosing not to publicly publish them, and what the landscape of healthcare looks like going into 2021.

+ +
+ +
    +

  • Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

    +Thanks!

    • +

  • This episode is sponsored by HelloFresh

    +Enter code ROBOTS90 to get a total of $90 off, including free shipping!

    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss crafting values with purpose, living those values in the product's messaging & marketing, choosing not to publicly publish them, and what the landscape of healthcare looks like going into 2021.

+ +
+ +
    +

  • Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

    +Thanks!

    • +

  • This episode is sponsored by HelloFresh

    +Enter code ROBOTS90 to get a total of $90 off, including free shipping!

    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+NJwbz-ba + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Values + https://podcast.thoughtbot.com/388 + 5cb870ac-26cf-458e-8b01-25bc8b3a9095 + Mon, 09 Nov 2020 00:15:00 -0500 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey discuss the history of values at thoughtbot and how they served as a key differentiator in the early days of the company, and navigating the tricky waters of when client values don't align. + 33:48 + no + + Chad and Lindsey discuss the history of values at thoughtbot and how they served as a key differentiator in the early days of the company, and navigating the tricky waters of when client values don't align. +Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey (https://docs.google.com/forms/d/e/1FAIpQLScc386ccM-nS_pcLClG1fIAH4Kr4L5jlSY4eidKa93L5DSztQ/viewform). +Thanks! +The thoughtbot Founders' story on Giant Robots (https://www.giantrobots.fm/262) +thoughtbot Purpose Statement (https://thoughtbot.com/purpose) +AgencyU (https://thoughtbot.com/agencyu) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Chad and Lindsey discuss the history of values at thoughtbot and how they served as a key differentiator in the early days of the company, and navigating the tricky waters of when client values don't align.

+ +
+ +

Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

+Thanks!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey discuss the history of values at thoughtbot and how they served as a key differentiator in the early days of the company, and navigating the tricky waters of when client values don't align.

+ +
+ +

Please take a minute to help guide our next season with your thoughtful feedback on our Giant Robots listener survey.

+Thanks!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tDboxf1R + + ]]> + + Chad Pytel + Lindsey Christensen + + + Marketing - ShearShare + https://podcast.thoughtbot.com/387 + e1be8d1b-c2a9-4413-a363-4eec616de8f5 + Mon, 02 Nov 2020 00:15:00 -0500 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about their early days of in-person marketing, the importance of naming, consistent messaging, and the effects of hiring a head of growth. + 44:51 + no + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about their early days of in-person marketing, the importance of naming, consistent messaging, and the effects of hiring a head of growth. +ShearShare (https://shearshare.com/) +Mentored by Failure (https://amzn.to/2GOxjCe)- Tye Caldwell +ShearShare on TikTok (https://www.tiktok.com/@shearshare) +ShearShare secures $2.3M in seed funding (https://techcrunch.com/2020/10/26/dallas-shearshare-has-a-marketplace-connecting-stylists-with-available-seats-at-salons-and-2-3-million-in-funding/) +Google's Black Founders' Fund (https://techcrunch.com/2020/10/06/google-is-providing-cash-awards-to-76-startups-through-a-racial-equity-initiative-announced-in-june/) +ShearShare on Instagram (https://www.instagram.com/shearshare/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: ShearShare. + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about their early days of in-person marketing, the importance of naming, consistent messaging, and the effects of hiring a head of growth.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about their early days of in-person marketing, the importance of naming, consistent messaging, and the effects of hiring a head of growth.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+U1QsSnFJ + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Marketing - Teikametrics + https://podcast.thoughtbot.com/386 + cf66876c-9a56-47bd-8f71-36a9d59562b4 + Mon, 26 Oct 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the day-one origins of marketing there, building your reputation through content marketing, and the efficacy of various content channels. + 46:48 + no + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the day-one origins of marketing there, building your reputation through content marketing, and the efficacy of various content channels. +This episode is brought to you by Teamistry (https://link.chtbl.com/teamistry?sid=podcast.giantrobots). +Discover stories of teams who work together in new and unexpected ways to achieve remarkable things, on the Teamistry podcast +Teikametrics (https://www.teikametrics.com/) +Stats & Trends From Prime Day 2020 Webinar (https://learn.teikametrics.com/blog/stats-trends-from-prime-day-2020/) +"How to Make Podcasting Work for You" (https://youtu.be/58j28Qv0Lsk)- Lindsey @ Startup Boston +Flywheel 2.0 (https://go.teikametrics.com/flywheel2.0?utm_source=podcast&utm_medium=giantrobots)- Early Access List +Teikametrics Acquires Adjusti.co (https://www.businesswire.com/news/home/20201014005161/en/Teikametrics-Acquires-Adjusti.co-to-Provide-Market-Intelligence-for-Amazon-and-Walmart/) +Nikola admits prototype was rolling downhill in promotional video (https://arstechnica.com/cars/2020/09/nikola-admits-prototype-was-rolling-downhill-in-promotional-video/) +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the day-one origins of marketing there, building your reputation through content marketing, and the efficacy of various content channels.

+ +
+ +

This episode is brought to you by Teamistry.

+Discover stories of teams who work together in new and unexpected ways to achieve remarkable things, on the Teamistry podcast

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing the day-one origins of marketing there, building your reputation through content marketing, and the efficacy of various content channels.

+ +
+ +

This episode is brought to you by Teamistry.

+Discover stories of teams who work together in new and unexpected ways to achieve remarkable things, on the Teamistry podcast

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+x2lVADZR + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Marketing - Nurse-1-1 + https://podcast.thoughtbot.com/385 + a3c33a68-a5e6-4577-97fa-ff70b7455881 + Mon, 19 Oct 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss the blurry line between marketing, research, & product, committing to branding, acquisition costs, SEO & content marketing, helping to power a new provider platform, and hiring a head of marketing. + 47:39 + no + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss the blurry line between marketing, research, & product, committing to branding, acquisition costs, SEO & content marketing, helping to power a new provider platform, and hiring a head of marketing. +Nurse-1-1 (https://nurse-1-1.com/) +Nurse-1-1 Healthtech Blog (https://nurse-1-1.com/health/blog/) +Utilization Management White Paper (https://nurse-1-1.com/health/wp-content/uploads/2020/06/Nurse-1-1-Utilization-Management-White-Paper-Low-Res.pdf) +Well At Home (https://www.wellathome.com/) +Michael on Twitter (https://twitter.com/MichaelSheeley) +Nurse-1-1 on Instagram (https://www.instagram.com/nurseoneone/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Nurse-1-1. + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss the blurry line between marketing, research, & product, committing to branding, acquisition costs, SEO & content marketing, helping to power a new provider platform, and hiring a head of marketing.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss the blurry line between marketing, research, & product, committing to branding, acquisition costs, SEO & content marketing, helping to power a new provider platform, and hiring a head of marketing.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8dQIM7bX + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Marketing + https://podcast.thoughtbot.com/384 + 6d36378e-1e67-4b85-adc3-0d0ee2637f2b + Mon, 12 Oct 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey discuss 'what's in a name' when it comes to branding, where (and where not) to start when you first begin your marketing efforts, and staying engaged with your customers. + 30:43 + no + + Chad and Lindsey discuss 'what's in a name' when it comes to branding, where (and where not) to start when you first begin your marketing efforts, and staying engaged with your customers. +This episode is brought to you by: +Teamistry (https://link.chtbl.com/teamistry?sid=podcast.giantrobots)- Discover stories of teams who work together in new and unexpected ways to achieve remarkable things, on the Teamistry podcast +Hover (https://www.hover.com/welcome/GiantRobots): 10% discount on all new purchases! +SWOT analysis (https://en.wikipedia.org/wiki/SWOT_analysis) +Being Human in the Absence of Humans (https://info.thoughtbot.com/remote-product-team-resources)- Remote Teams Workshop +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Chad and Lindsey discuss 'what's in a name' when it comes to branding, where (and where not) to start when you first begin your marketing efforts, and staying engaged with your customers.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • Teamistry- Discover stories of teams who work together in new and unexpected ways to achieve remarkable things, on the Teamistry podcast
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey discuss 'what's in a name' when it comes to branding, where (and where not) to start when you first begin your marketing efforts, and staying engaged with your customers.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • Teamistry- Discover stories of teams who work together in new and unexpected ways to achieve remarkable things, on the Teamistry podcast
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+FzsBUD4z + + ]]> + + Chad Pytel + Lindsey Christensen + + + Data - Teikametrics + https://podcast.thoughtbot.com/383 + c34ecf3d-81ba-412d-b364-838ec881019b + Mon, 05 Oct 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing trust within the use of data, planning the future with indexed data, a data-science related acquisition, and navigating the world of buzzwords around machine learning. + 48:06 + no + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing trust within the use of data, planning the future with indexed data, a data-science related acquisition, and navigating the world of buzzwords around machine learning. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/giantrobots): Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Hover (https://www.hover.com/welcome/GiantRobots): 10% discount on all new purchases! +Teikametrics (https://www.teikametrics.com/) +Amazon Marketplace Bribery Scheme (https://www.theverge.com/2020/9/19/21446549/six-people-indicted-amazon-bribery-marketplace-third-party-sellers) +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing trust within the use of data, planning the future with indexed data, a data-science related acquisition, and navigating the world of buzzwords around machine learning.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing trust within the use of data, planning the future with indexed data, a data-science related acquisition, and navigating the world of buzzwords around machine learning.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+yv2_ze9Q + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Data - ShearShare + https://podcast.thoughtbot.com/382 + 3a0f029a-306a-45b0-abc7-c5f3ce7a6143 + Mon, 28 Sep 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about using data to guide product design, imagining a machine learning recommendation engine, and their experience in Google for Startups Accelerator. + 45:21 + no + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about using data to guide product design, imagining a machine learning recommendation engine, and their experience in Google for Startups Accelerator. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/giantrobots): Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Hover (https://www.hover.com/welcome/GiantRobots): 10% discount on all new purchases! +ShearShare (https://shearshare.com/) +Google for Startups Accelerator: Black Founders (https://developers.google.com/community/accelerators/black-founders/meet-the-startups) +ShearShare on Instagram (https://www.instagram.com/shearshare/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: ShearShare. + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about using data to guide product design, imagining a machine learning recommendation engine, and their experience in Google for Startups Accelerator.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about using data to guide product design, imagining a machine learning recommendation engine, and their experience in Google for Startups Accelerator.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+o4tYhNZI + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Data - Nurse-1-1 + https://podcast.thoughtbot.com/381 + d558dfac-d26c-41a7-b494-b7f25a88a80e + Mon, 21 Sep 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss using data to drive a better customer experience, some of the regulations around data management in healthcare, and advice for health-tech startups. + 55:44 + no + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss using data to drive a better customer experience, some of the regulations around data management in healthcare, and advice for health-tech startups. +Join us on Sept 24th at 12pm ET for the Your path to digital health startup success (https://thoughtbot.com/events/digital-health-startup-event), a digital health-tech event! +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/giantrobots): Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Hover (https://www.hover.com/welcome/GiantRobots): 10% discount on all new purchases! +Nurse-1-1 (https://nurse-1-1.com/) +Michael on Twitter (https://twitter.com/MichaelSheeley) +Nurse-1-1 on Instagram (https://www.instagram.com/nurseoneone/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + Special Guest: Nurse-1-1. + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss using data to drive a better customer experience, some of the regulations around data management in healthcare, and advice for health-tech startups.

+ +

Join us on Sept 24th at 12pm ET for the Your path to digital health startup success, a digital health-tech event!

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss using data to drive a better customer experience, some of the regulations around data management in healthcare, and advice for health-tech startups.

+ +

Join us on Sept 24th at 12pm ET for the Your path to digital health startup success, a digital health-tech event!

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • Hover: 10% discount on all new purchases!
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tHfiz1vP + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Data + https://podcast.thoughtbot.com/380 + fe1c70c6-69e5-4b21-b9c8-7ffc0fc49377 + Tue, 08 Sep 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Data drives the world, and so this month we'll be talking about common pitfalls of building a business around data, laying out a tandem roadmap to drive forward both data and product, the importance of insight over raw data, when does it makes sense to reach for machine learning, tooling, and thoughts on the ethics & future legislation of data collection. + 41:11 + no + + Data drives the world, and so this month we'll be talking about common pitfalls of building a business around data, laying out a tandem roadmap to drive forward both data and product, the importance of insight over raw data, when does it makes sense to reach for machine learning, tooling, and thoughts on the ethics & future legislation of data collection. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots): Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +GDPR (https://gdpr-info.eu/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Data drives the world, and so this month we'll be talking about common pitfalls of building a business around data, laying out a tandem roadmap to drive forward both data and product, the importance of insight over raw data, when does it makes sense to reach for machine learning, tooling, and thoughts on the ethics & future legislation of data collection.

+ +
+ +

This episode is brought to you by ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Data drives the world, and so this month we'll be talking about common pitfalls of building a business around data, laying out a tandem roadmap to drive forward both data and product, the importance of insight over raw data, when does it makes sense to reach for machine learning, tooling, and thoughts on the ethics & future legislation of data collection.

+ +
+ +

This episode is brought to you by ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Iv5DEhCJ + + ]]> + + Chad Pytel + Lindsey Christensen + + + Fundraising - Nurse-1-1 + https://podcast.thoughtbot.com/379 + 93e68dca-5544-4395-a4d7-ef6dbe493f9b + Mon, 31 Aug 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss vetting your investors, his experience with fundraising, maintaining your reputation, his mindset while negotiation with investors, lessons learned while building and funding startups, the importance of establishing a founding team, and involving the team in the fundraising process. + 50:21 + no + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss vetting your investors, his experience with fundraising, maintaining your reputation, his mindset while negotiation with investors, lessons learned while building and funding startups, the importance of establishing a founding team, and involving the team in the fundraising process. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Nurse-1-1 (https://nurse-1-1.com/) +Michael on Twitter (https://twitter.com/MichaelSheeley) +Nurse-1-1 on Instagram (https://www.instagram.com/nurseoneone/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Nurse-1-1. + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss vetting your investors, his experience with fundraising, maintaining your reputation, his mindset while negotiation with investors, lessons learned while building and funding startups, the importance of establishing a founding team, and involving the team in the fundraising process.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss vetting your investors, his experience with fundraising, maintaining your reputation, his mindset while negotiation with investors, lessons learned while building and funding startups, the importance of establishing a founding team, and involving the team in the fundraising process.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+-eW5g_zP + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Fundraising - ShearShare + https://podcast.thoughtbot.com/378 + 642968ae-c64a-4f97-b469-dd7a108261bd + Mon, 24 Aug 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Courtney & Tye Caldwell, Co-founders of ShearShare, to discuss their acceptance into the first cohort of Google for Startups' Black Founders Accelerator, speaking the language of investors, preparing for series A, how they think about an exit, and equity for the team. + 1:11:39 + no + + Chad and Lindsey are joined by Courtney & Tye Caldwell, Co-founders of ShearShare, to discuss their acceptance into the first cohort of Google for Startups' Black Founders Accelerator, speaking the language of investors, preparing for series A, how they think about an exit, and equity for the team. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +ShearShare (https://shearshare.com/) +Google for Startups Accelerator: Black Founders (https://developers.google.com/community/accelerators/black-founders/meet-the-startups) +Backstage Capital (https://backstagecapital.com/) +Jaylon Smith Minority Entrepreneurship Institute Capital Fund (https://jaylonsmith.com/mei) +ShearShare on Instagram (https://www.instagram.com/shearshare/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: ShearShare. + + + Chad and Lindsey are joined by Courtney & Tye Caldwell, Co-founders of ShearShare, to discuss their acceptance into the first cohort of Google for Startups' Black Founders Accelerator, speaking the language of investors, preparing for series A, how they think about an exit, and equity for the team.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Courtney & Tye Caldwell, Co-founders of ShearShare, to discuss their acceptance into the first cohort of Google for Startups' Black Founders Accelerator, speaking the language of investors, preparing for series A, how they think about an exit, and equity for the team.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+K15mTthF + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Fundraising - Teikametrics + https://podcast.thoughtbot.com/377 + d4ff413f-16f6-4cf8-abf2-40f8311565c6 + Mon, 17 Aug 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing early days of community building online, geography in relation to investors, his history with VC, the importance of relationship building, when & how much money to raise, time investment of a CEO for fundraising, and sharing financials with the team. + 42:14 + no + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing early days of community building online, geography in relation to investors, his history with VC, the importance of relationship building, when & how much money to raise, time investment of a CEO for fundraising, and sharing financials with the team. +This episode is brought to you by: +ScoutAPM (https://scoutapm.com/giantrobots): Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +FusionAuth (http://fusionauth.io/podcast) - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code GIANTROBOTS +Teikametrics (https://www.teikametrics.com/) +BigCommerce files to go public (https://techcrunch.com/2020/07/13/bigcommerce-files-to-go-public/) +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing early days of community building online, geography in relation to investors, his history with VC, the importance of relationship building, when & how much money to raise, time investment of a CEO for fundraising, and sharing financials with the team.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • FusionAuth - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code GIANTROBOTS
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, discussing early days of community building online, geography in relation to investors, his history with VC, the importance of relationship building, when & how much money to raise, time investment of a CEO for fundraising, and sharing financials with the team.

+ +
+ +

This episode is brought to you by:

+ +
    +
  • ScoutAPM: Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!
    • +
  • FusionAuth - Use it for free today and get a free t-shirt, or upgrade to their paid editions and get 25% with promo code GIANTROBOTS
    • +
+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Ai8isT5H + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Fundraising + https://podcast.thoughtbot.com/376 + 76d5b73a-0387-4332-87b6-dcf34368d620 + Mon, 10 Aug 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + This month we'll be talking about all things fundraising! The discussion covers investors vs bootstrapping, crowd-funding, differences between the various levels of fundraising, accelerators, and the expectations of taking venture capital. + 33:19 + no + + This month we'll be talking about all things fundraising! The discussion covers investors vs bootstrapping, crowd-funding, differences between the various levels of fundraising, accelerators, and the expectations of taking venture capital. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Wistia on Giant Robots (https://www.giantrobots.fm/254) +Term Sheet Grader (https://www.pillar.vc/founders-guide/guides/term-sheet-grader/)- Pillar VC +Backstage Capital (https://backstagecapital.com/) +It's About Damn Time: How to Turn Being Underestimated into Your Greatest Advantage (https://amzn.to/3kjZN9r)- Arlan Hamilton +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + This month we'll be talking about all things fundraising! The discussion covers investors vs bootstrapping, crowd-funding, differences between the various levels of fundraising, accelerators, and the expectations of taking venture capital.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This month we'll be talking about all things fundraising! The discussion covers investors vs bootstrapping, crowd-funding, differences between the various levels of fundraising, accelerators, and the expectations of taking venture capital.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+EzV8HQqh + + ]]> + + Chad Pytel + Lindsey Christensen + + + Work-Life Flow - Nurse-1-1 + https://podcast.thoughtbot.com/375 + 61c78104-ea31-4c2a-840d-c113503e8083 + Mon, 03 Aug 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss figuring out the summer and working from home during Covid and beyond, his approach to feature rollout, pings, & to-dos, as well as keeping the team on a unified path, and his personal motivations to keep going. + 39:08 + no + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss figuring out the summer and working from home during Covid and beyond, his approach to feature rollout, pings, & to-dos, as well as keeping the team on a unified path, and his personal motivations to keep going. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Nurse-1-1 (https://nurse-1-1.com/) +Michael on Twitter (https://twitter.com/MichaelSheeley) +Nurse-1-1 on Instagram (https://www.instagram.com/nurseoneone/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Nurse-1-1. + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss figuring out the summer and working from home during Covid and beyond, his approach to feature rollout, pings, & to-dos, as well as keeping the team on a unified path, and his personal motivations to keep going.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss figuring out the summer and working from home during Covid and beyond, his approach to feature rollout, pings, & to-dos, as well as keeping the team on a unified path, and his personal motivations to keep going.

+ +
+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ +
+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Z5h55dNz + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Work-Life Flow - ShearShare + https://podcast.thoughtbot.com/374 + 052cee93-9e07-4c27-9e3e-3529a3aa2df4 + Mon, 27 Jul 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the offset schedule of the beauty industry, an unexpected source of inspiration, the importance of a routine, and supporting the betterment of their team & community. + 46:10 + no + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the offset schedule of the beauty industry, an unexpected source of inspiration, the importance of a routine, and supporting the betterment of their team & community. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +ShearShare (https://shearshare.com/) +Your First Million Podcast (https://yfmpodcast.com/) +Les Brown Greatness Radio (https://www.spreaker.com/show/the-les-brown-radio-show) +The ShearShare "Concoction" (https://gist.github.com/ThomObarski/f639af924a204ffbd1532d2b48c0eb74) +ShearShare on Instagram (https://www.instagram.com/shearshare/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: ShearShare. + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the offset schedule of the beauty industry, an unexpected source of inspiration, the importance of a routine, and supporting the betterment of their team & community.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the offset schedule of the beauty industry, an unexpected source of inspiration, the importance of a routine, and supporting the betterment of their team & community.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hbU7GlPZ + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Work-Life Flow - Teikametrics + https://podcast.thoughtbot.com/373 + fb64ff9c-1e01-4c5d-9df5-7eeac77ab795 + Mon, 20 Jul 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey catch up with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, as they head into the second half of the year discussing finding balance (especially when you love your work), examining 'what's our role' to make an impact in responding to national and global events, the importance of exercise in his life, and staying engaged with the product even as one's focus shifts more broadly in the company. + 38:51 + no + + Chad and Lindsey catch up with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, as they head into the second half of the year discussing finding balance (especially when you love your work), examining 'what's our role' to make an impact in responding to national and global events, the importance of exercise in his life, and staying engaged with the product even as one's focus shifts more broadly in the company. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +Teikametrics (https://www.teikametrics.com/) +The Advantage: Why Organizational Health Trumps Everything Else In Business (https://amzn.to/2OyFmqF)- Patrick M. Lencioni +Measure What Matters (https://amzn.to/3gS8JA8)- John Doerr +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + + Chad and Lindsey catch up with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, as they head into the second half of the year discussing finding balance (especially when you love your work), examining 'what's our role' to make an impact in responding to national and global events, the importance of exercise in his life, and staying engaged with the product even as one's focus shifts more broadly in the company.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey catch up with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, as they head into the second half of the year discussing finding balance (especially when you love your work), examining 'what's our role' to make an impact in responding to national and global events, the importance of exercise in his life, and staying engaged with the product even as one's focus shifts more broadly in the company.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+1phNSsIw + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Work-Life Flow + https://podcast.thoughtbot.com/372 + 79209b93-b1cd-4673-b76b-89e93ffbe957 + Mon, 13 Jul 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Lindsey and Chad discuss work-life flow, both in general and during quarantine, their schedules, hobbies, and methods to preserve personal time like time-boxing, prioritization, and calendar blocking. + 37:19 + no + + Lindsey and Chad discuss work-life flow, both in general and during quarantine, their schedules, hobbies, and methods to preserve personal time like time-boxing, prioritization, and calendar blocking. +This episode is brought to you by ScoutAPM (https://scoutapm.com/giantrobots). +Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy! +We need to stop striving for work-life balance. Here’s why (https://www.fastcompany.com/90308095/why-you-should-stop-trying-to-achieve-work-life-balance) +Calendly (https://calendly.com/) +AllTrails (https://www.alltrails.com/) +Dungeons & Dragons Online (https://www.ddo.com/) +table.party (https://table.party/) +Pivoting to Antiracism (https://thoughtbot.com/blog/pivoting-to-antiracism) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Lindsey and Chad discuss work-life flow, both in general and during quarantine, their schedules, hobbies, and methods to preserve personal time like time-boxing, prioritization, and calendar blocking.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lindsey and Chad discuss work-life flow, both in general and during quarantine, their schedules, hobbies, and methods to preserve personal time like time-boxing, prioritization, and calendar blocking.

+ +

This episode is brought to you by ScoutAPM.
+Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy!

+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7-w8RFac + + ]]> + + Chad Pytel + Lindsey Christensen + + + Sales - Nurse-1-1 + https://podcast.thoughtbot.com/371 + dbe46caa-a176-4539-8359-c88245876cbf + Mon, 06 Jul 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss prioritizing revenue, their revenue models, why sales at their stage is more like business development, and considering your first 'sales' hire. + 38:24 + no + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss prioritizing revenue, their revenue models, why sales at their stage is more like business development, and considering your first 'sales' hire. +Nurse-1-1 (https://nurse-1-1.com/) +Utilization Management White Paper (https://nurse-1-1.com/health/wp-content/uploads/2020/06/Nurse-1-1-Utilization-Management-White-Paper-Low-Res.pdf) +Michael on Twitter (https://twitter.com/MichaelSheeley) Special Guest: Nurse-1-1. + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss prioritizing revenue, their revenue models, why sales at their stage is more like business development, and considering your first 'sales' hire.

+ +

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss prioritizing revenue, their revenue models, why sales at their stage is more like business development, and considering your first 'sales' hire.

+ +

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+D6jJ3I8q + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Sales - ShearShare + https://podcast.thoughtbot.com/370 + f7ee1693-1bcb-466f-b135-c2a0cc7405c2 + Mon, 29 Jun 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about all the different forms that sales can take, their revenue model, the importance of personal outreach, and building trust through content marketing. + 51:07 + no + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about all the different forms that sales can take, their revenue model, the importance of personal outreach, and building trust through content marketing. +ShearShare (https://shearshare.com/) +ShearShare - Build My Business (https://shearshare.com/buildmybusiness/) +ShearShare on Instagram (https://www.instagram.com/shearshare/) Special Guest: ShearShare. + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about all the different forms that sales can take, their revenue model, the importance of personal outreach, and building trust through content marketing.

+ +

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about all the different forms that sales can take, their revenue model, the importance of personal outreach, and building trust through content marketing.

+ +

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jfjzbVPt + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Sales - Teikametrics + https://podcast.thoughtbot.com/369 + 07d37640-34ad-4a38-92f1-cbafa4699209 + Mon, 22 Jun 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about product-led direct-to-consumer as the future of sales, capturing multiple market segments, and sales structure within Teikametrics. + 47:43 + no + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about product-led direct-to-consumer as the future of sales, capturing multiple market segments, and sales structure within Teikametrics. +Teikametrics (https://www.teikametrics.com/) +Facebook Shops (https://www.facebook.com/business/shops) +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about product-led direct-to-consumer as the future of sales, capturing multiple market segments, and sales structure within Teikametrics.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about product-led direct-to-consumer as the future of sales, capturing multiple market segments, and sales structure within Teikametrics.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+U8XPUrGI + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Sales + https://podcast.thoughtbot.com/368 + a17fcd51-4f7b-4840-ae58-b3749bd3ad2e + Mon, 15 Jun 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey discuss thoughtbot's ideology around sales, the sales process & cycle, identifying your ideal customers, and fostering real relationships with customers. + 35:18 + no + + Chad and Lindsey discuss thoughtbot's ideology around sales, the sales process & cycle, identifying your ideal customers, and fostering real relationships with customers. +GitHub is now free for all teams (https://techcrunch.com/2020/04/14/github-is-now-free-for-all-teams/) +a16z Podcast (https://a16z.simplecast.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Chad and Lindsey discuss thoughtbot's ideology around sales, the sales process & cycle, identifying your ideal customers, and fostering real relationships with customers.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey discuss thoughtbot's ideology around sales, the sales process & cycle, identifying your ideal customers, and fostering real relationships with customers.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Dhgv19E1 + + ]]> + + Chad Pytel + Lindsey Christensen + + + 367: Securing Opportunity (Shelly Bell) + https://podcast.thoughtbot.com/367 + e52f0f92-6ea6-43e5-baf5-853fab5f0ac6 + Mon, 08 Jun 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + We’re pushing out our next episode in the Giant Robots startup series. We want to pause to acknowledge, reflect, and take action against injustices against the black community. + +thoughtbot stands with the black community. We’re outraged by the systematic racism and violence in the US. George Floyd, Tony McDade, Breonna Taylor, Ahmaud Arbery, Eric Garner, Trayvon Martin, and too many other members of the black community have lost their lives due to racial injustice. It needs to end. + +We recognize we haven’t been doing enough to fight this injustice and need to be active in anti-racism. Our D&I council and many others on the thoughtbot team are discussing how we can do more and are working on new initiatives to better support our black colleagues, friends, and beyond - far into the future. + +We're looking to do things both large and small. For example, this week we changed our conference reimbursement benefit to only be applicable to conferences that have a diverse speaker lineup and a code of conduct. We hope our efforts will be useful to others as well, and plan to make them available to other companies to work from. In the meantime, we’re going to link to a reading list that we recommend. + +Today we’re resharing a past episode that features a black voice in the tech community that we look up to and you should know - Shelly Bell. Shelly is the founder of Black Girl Ventures, an organization that creates access to social and financial capital for Black and Brown women founders. She’s been named in the Top 100 Power Women by Entrepreneur Magazine and has a fantastic story you don’t want to miss. + +Stay safe and see you soon. + 37:56 + no + + We’re pushing out our next episode in the Giant Robots startup series. We want to pause to acknowledge, reflect, and take action against injustices against the black community. +thoughtbot stands with the black community. We’re outraged by the systematic racism and violence in the US. George Floyd, Tony McDade, Breonna Taylor, Ahmaud Arbery, Eric Garner, Trayvon Martin, and too many other members of the black community have lost their lives due to racial injustice. It needs to end. +We recognize we haven’t been doing enough to fight this injustice and need to be active in anti-racism. Our D&I council and many others on the thoughtbot team are discussing how we can do more and are working on new initiatives to better support our black colleagues, friends, and beyond - far into the future. +We're looking to do things both large and small. For example, this week we changed our conference reimbursement benefit to only be applicable to conferences that have a diverse speaker lineup and a code of conduct. We hope our efforts will be useful to others as well, and plan to make them available to other companies to work from. In the meantime, we’re going to link to a reading list that we recommend. +Today we’re resharing a past episode that features a black voice in the tech community that we look up to and you should know - Shelly Bell. Shelly is the founder of Black Girl Ventures, an organization that creates access to social and financial capital for Black and Brown women founders. She’s been named in the Top 100 Power Women by Entrepreneur Magazine and has a fantastic story you don’t want to miss. +Stay safe and see you soon. +75 Things White People Can Do for Racial Justice (https://medium.com/equality-includes-you/what-white-people-can-do-for-racial-justice-f2d18b0e0234) +How To Be An Antiracist (https://www.ibramxkendi.com/how-to-be-an-antiracist-1)- Ibram X. Kendi +Behind By Design (https://medium.com/@OneBandwagonFan/behind-by-design-ad2c81f01b14) +So You Want to Talk About Race (https://www.sealpress.com/titles/ijeoma-oluo/so-you-want-to-talk-about-race/9781580056779/)- Ijeoma Oluo +Save the Tears (https://tatianamac.com/posts/save-the-tears/) +White Guyde To The Galaxy (https://tatianamac.com/posts/white-guyde/) +Black Tech for Black Lives (https://www.blacktechforblacklives.com/) +Original Notes from Giant Robots Episode 354 +Shelly Bell, CEO & Founder of Black Girl Ventures, discusses working to open up your messaging, what makes for a good pitch, and the current state of the investment landscape. +Black Girl Ventures (https://www.blackgirlventures.org/) +Ragbaby Exchange (http://ragbabyexch.org/) +BEACON (https://www.thebeacondc.com/) +"Male and Female Entrepreneurs Get Asked Different Questions by VCs — and It Affects How Much Funding They Get" (https://hbr.org/2017/06/male-and-female-entrepreneurs-get-asked-different-questions-by-vcs-and-it-affects-how-much-funding-they-get)- Harvard Business Review +SheRaise (https://www.sheraise.com/) +Shelly on Twitter (https://twitter.com/iamshellybell) + + + We’re pushing out our next episode in the Giant Robots startup series. We want to pause to acknowledge, reflect, and take action against injustices against the black community.

+ +

thoughtbot stands with the black community. We’re outraged by the systematic racism and violence in the US. George Floyd, Tony McDade, Breonna Taylor, Ahmaud Arbery, Eric Garner, Trayvon Martin, and too many other members of the black community have lost their lives due to racial injustice. It needs to end.

+ +

We recognize we haven’t been doing enough to fight this injustice and need to be active in anti-racism. Our D&I council and many others on the thoughtbot team are discussing how we can do more and are working on new initiatives to better support our black colleagues, friends, and beyond - far into the future.

+ +

We're looking to do things both large and small. For example, this week we changed our conference reimbursement benefit to only be applicable to conferences that have a diverse speaker lineup and a code of conduct. We hope our efforts will be useful to others as well, and plan to make them available to other companies to work from. In the meantime, we’re going to link to a reading list that we recommend.

+ +

Today we’re resharing a past episode that features a black voice in the tech community that we look up to and you should know - Shelly Bell. Shelly is the founder of Black Girl Ventures, an organization that creates access to social and financial capital for Black and Brown women founders. She’s been named in the Top 100 Power Women by Entrepreneur Magazine and has a fantastic story you don’t want to miss.

+ +

Stay safe and see you soon.

+ + + +
+ +

Original Notes from Giant Robots Episode 354

+ +

Shelly Bell, CEO & Founder of Black Girl Ventures, discusses working to open up your messaging, what makes for a good pitch, and the current state of the investment landscape.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + We’re pushing out our next episode in the Giant Robots startup series. We want to pause to acknowledge, reflect, and take action against injustices against the black community.

+ +

thoughtbot stands with the black community. We’re outraged by the systematic racism and violence in the US. George Floyd, Tony McDade, Breonna Taylor, Ahmaud Arbery, Eric Garner, Trayvon Martin, and too many other members of the black community have lost their lives due to racial injustice. It needs to end.

+ +

We recognize we haven’t been doing enough to fight this injustice and need to be active in anti-racism. Our D&I council and many others on the thoughtbot team are discussing how we can do more and are working on new initiatives to better support our black colleagues, friends, and beyond - far into the future.

+ +

We're looking to do things both large and small. For example, this week we changed our conference reimbursement benefit to only be applicable to conferences that have a diverse speaker lineup and a code of conduct. We hope our efforts will be useful to others as well, and plan to make them available to other companies to work from. In the meantime, we’re going to link to a reading list that we recommend.

+ +

Today we’re resharing a past episode that features a black voice in the tech community that we look up to and you should know - Shelly Bell. Shelly is the founder of Black Girl Ventures, an organization that creates access to social and financial capital for Black and Brown women founders. She’s been named in the Top 100 Power Women by Entrepreneur Magazine and has a fantastic story you don’t want to miss.

+ +

Stay safe and see you soon.

+ + + +
+ +

Original Notes from Giant Robots Episode 354

+ +

Shelly Bell, CEO & Founder of Black Girl Ventures, discusses working to open up your messaging, what makes for a good pitch, and the current state of the investment landscape.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jftTsZml + + ]]> + + + + Communication & Collaboration - Nurse-1-1 + https://podcast.thoughtbot.com/366 + 5ec772e1-6a45-4f44-aa5c-a2c18eaf05eb + Mon, 01 Jun 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss feeling disconnected from the team during quarantine, evaluating for communication skills during the interview process, how communication standards differ in the medical field, and avoiding AI & automation within patient conversations. + 41:47 + no + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss feeling disconnected from the team during quarantine, evaluating for communication skills during the interview process, how communication standards differ in the medical field, and avoiding AI & automation within patient conversations. +Nurse-1-1 (https://nurse-1-1.com/) +Michael on Twitter (https://twitter.com/MichaelSheeley) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Nurse-1-1. + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss feeling disconnected from the team during quarantine, evaluating for communication skills during the interview process, how communication standards differ in the medical field, and avoiding AI & automation within patient conversations.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey are joined by Michael Sheeley, founder & CEO of Nurse-1-1, to discuss feeling disconnected from the team during quarantine, evaluating for communication skills during the interview process, how communication standards differ in the medical field, and avoiding AI & automation within patient conversations.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+CH1ZS-7_ + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Communication & Collaboration- ShearShare + https://podcast.thoughtbot.com/365 + 2ae8a969-2574-41ae-8b8b-6a7e2e6dc498 + Mon, 25 May 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about being founded as remote company, their communication tools and methodologies, interview process, and messaging implementation. + 49:33 + no + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about being founded as remote company, their communication tools and methodologies, interview process, and messaging implementation. +ShearShare (https://shearshare.com/) +Notion (https://www.notion.so/) +ShearShare Business Learning Portal (https://shearshare.com/buildmybusiness/) +ShearShare on Instagram (https://www.instagram.com/shearshare/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: ShearShare. + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about being founded as remote company, their communication tools and methodologies, interview process, and messaging implementation.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about being founded as remote company, their communication tools and methodologies, interview process, and messaging implementation.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+5thiFSLN + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Communication & Collaboration - Teikametrics + https://podcast.thoughtbot.com/364 + d9a3cbbc-ace1-4c12-a01e-72f0864917e5 + Mon, 18 May 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about Teikametrics' guiding principles, Zoom fatigue, rethinking stances on remote work, the value of a peer group, and how retail is adapting during Covid-19. + 47:02 + no + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about Teikametrics' guiding principles, Zoom fatigue, rethinking stances on remote work, the value of a peer group, and how retail is adapting during Covid-19. +Teikametrics (https://www.teikametrics.com/) +Coinbase planning and response to COVID-2019 (https://blog.coinbase.com/coinbase-planning-and-response-to-covid-2019-d0cb3379bc3e) +Amazon '6 Pager' Methodology (https://www.cnbc.com/2018/04/23/what-jeff-bezos-learned-from-requiring-6-page-memos-at-amazon.html) +Trillion Dollar Coach: The Leadership Playbook of Silicon Valley's Bill Campbell (https://amzn.to/2X99xs2)- Eric Schmidt +Good to Great (https://amzn.to/366yqZA)- Jim Collins +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about Teikametrics' guiding principles, Zoom fatigue, rethinking stances on remote work, the value of a peer group, and how retail is adapting during Covid-19.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about Teikametrics' guiding principles, Zoom fatigue, rethinking stances on remote work, the value of a peer group, and how retail is adapting during Covid-19.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+orVoTCM5 + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Communication & Collaboration + https://podcast.thoughtbot.com/363 + cebf784d-c3f9-45de-9d27-c9aac106f5b8 + Mon, 11 May 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey discuss thoughtbot's methodology & tools for communication and collaboration, both in general and adapting them to a fully remote workplace, the pros and cons of this new environment, and approaching your work with optimism. + 39:23 + no + + Chad and Lindsey discuss thoughtbot's methodology & tools for communication and collaboration, both in general and adapting them to a fully remote workplace, the pros and cons of this new environment, and approaching your work with optimism. +This episode is brought to you by ExpressVPN (https://www.expressvpn.com/ROBOTS). +Click through to get three months for free. +37 Signals (Now Basecamp) (https://basecamp.com/) +thoughtbot Playbook (https://thoughtbot.com/playbook) +Being Human in the Absence of Humans: A Q&A for Product Teams (https://info.thoughtbot.com/remote-product-team-resources) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Chad and Lindsey discuss thoughtbot's methodology & tools for communication and collaboration, both in general and adapting them to a fully remote workplace, the pros and cons of this new environment, and approaching your work with optimism.

+ +

This episode is brought to you by ExpressVPN.

+Click through to get three months for free.

+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey discuss thoughtbot's methodology & tools for communication and collaboration, both in general and adapting them to a fully remote workplace, the pros and cons of this new environment, and approaching your work with optimism.

+ +

This episode is brought to you by ExpressVPN.

+Click through to get three months for free.

+ + + +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0SVaIFW1 + + ]]> + + Chad Pytel + Lindsey Christensen + + + Product Roadmap - Nurse-1-1 + https://podcast.thoughtbot.com/362 + 2f8e60da-14ba-430c-bfde-2f58c26d4738 + Mon, 04 May 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Michael Sheeley, founder & CEO of Nurse-1-1, on learnings from their launch, challenges of building in the health-tech space, their approach to long-term planning, and the future of medicine in a post COVID-19 world. + 50:32 + no + + Chad and Lindsey talk with Michael Sheeley, founder & CEO of Nurse-1-1, on learnings from their launch, challenges of building in the health-tech space, their approach to long-term planning, and the future of medicine in a post COVID-19 world. +Nurse-1-1 (https://nurse-1-1.com/) +Michael on Giant Robots (https://www.giantrobots.fm/277) +Harvard Innovation Labs (https://innovationlabs.harvard.edu/) +Zocdoc Partnership (https://www.zocdoc.com/about/news/free-nurse-chat/) +Net Promotor Score (NPS) (https://en.wikipedia.org/wiki/Net_Promoter) +Health-Related Google Searches Doubled in the Week Before Patients’ Emergency Department Visits (https://www.pennmedicine.org/news/news-releases/2019/february/health-related-google-searches-doubled-in-the-week-before-patients-emergency-department-visits)- Penn Medicine +Michael on Twitter (https://twitter.com/MichaelSheeley) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Nurse-1-1. + + product roadmap, transparency, public, honesty, trust, nurse, emergency room, coronavirus, + + Chad and Lindsey talk with Michael Sheeley, founder & CEO of Nurse-1-1, on learnings from their launch, challenges of building in the health-tech space, their approach to long-term planning, and the future of medicine in a post COVID-19 world.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Michael Sheeley, founder & CEO of Nurse-1-1, on learnings from their launch, challenges of building in the health-tech space, their approach to long-term planning, and the future of medicine in a post COVID-19 world.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tehDPsgB + + ]]> + + Chad Pytel + Lindsey Christensen + Nurse-1-1 + + + Product Roadmap - ShearShare + https://podcast.thoughtbot.com/361 + 2f49d996-8fe3-4c4e-9471-659efb6717e1 + Mon, 27 Apr 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the history of the platform, how the beauty industry has been impacted by COVID-19, building yourself as a brand that people can trust, and how their product roadmap has adapted to the changing landscape. + 50:44 + no + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the history of the platform, how the beauty industry has been impacted by COVID-19, building yourself as a brand that people can trust, and how their product roadmap has adapted to the changing landscape. +ShearShare (https://shearshare.com/) +ShearShare on Giant Robots (https://www.giantrobots.fm/331) +Mentored by Failure (https://amzn.to/2GOxjCe)- Tye Caldwell +ShearShare Learning Portal (https://shearshare.com/buildmybusiness/) +Courtney on Twitter (https://twitter.com/ShearShareCOO) +Tye on Twitter (https://twitter.com/drtyecaldwell) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: ShearShare. + + product roadmap, transparency, public, honesty, trust, + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the history of the platform, how the beauty industry has been impacted by COVID-19, building yourself as a brand that people can trust, and how their product roadmap has adapted to the changing landscape.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Courtney & Tye Caldwell, Co-founders of ShearShare, about the history of the platform, how the beauty industry has been impacted by COVID-19, building yourself as a brand that people can trust, and how their product roadmap has adapted to the changing landscape.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+zRz6GpjE + + ]]> + + Chad Pytel + Lindsey Christensen + ShearShare + + + Product Roadmap - Teikametrics + https://podcast.thoughtbot.com/360 + 6892044d-12d3-4274-b2e0-9c79a482f1b8 + Mon, 20 Apr 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about the history of the platform, staying focused on the needs of your customers, shifting product requirements to meet your ideal buyer-personas, and their newly-minted formal product roadmap. + 50:44 + no + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about the history of the platform, staying focused on the needs of your customers, shifting product requirements to meet your ideal buyer-personas, and their newly-minted formal product roadmap. +This episode is brought to you by ExpressVPN (https://www.expressvpn.com/ROBOTS). +Click through to get three months for free. +Teikametrics (https://www.teikametrics.com/) +Aatish Salvi on Giant Robots (https://www.giantrobots.fm/301) +The Ride of a Lifetime: Lessons Learned from 15 Years as CEO of the Walt Disney Company (https://amzn.to/2xuA0ro)- Robert Iger +The Everything Store (https://amzn.to/3ekI8v7)- Brad Stone +Retail optimization startup Teikametrics raises $15M as it expands beyond Amazon and beyond ads (https://techcrunch.com/2020/02/19/teikametrics-funding/?guccounter=1&guce_referrer=aHR0cHM6Ly9kdWNrZHVja2dvLmNvbS8&guce_referrer_sig=AQAAACwyNoVV6IyDU33Gvh4P0QxnqHGcOK97vl_S-wKVyrMnitd8Icn6v6dl2I27iEujt_dx5syczmpDQuTsVI7qF-zrJGY62dyc9KbqggLXO98WVDBCHGiF2lLqnvicUCHQQVRm6jzHH-ydYcswYsqO9ib868_E_JBb40bkzrW7LiVl) +The Advantage (https://amzn.to/2VvwlBD)- Patrick M. Lencioni +Alasdair on LinkedIn (https://www.linkedin.com/in/alasdairmcleanforeman/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Special Guest: Teikametrics. + + product roadmap, transparency, public, + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about the history of the platform, staying focused on the needs of your customers, shifting product requirements to meet your ideal buyer-personas, and their newly-minted formal product roadmap.

+ +

This episode is brought to you by ExpressVPN.

+Click through to get three months for free.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey talk with Alasdair McLean-Foreman, CEO & Founder of Teikametrics, about the history of the platform, staying focused on the needs of your customers, shifting product requirements to meet your ideal buyer-personas, and their newly-minted formal product roadmap.

+ +

This episode is brought to you by ExpressVPN.

+Click through to get three months for free.

+ + + +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ELRhxwSw + + ]]> + + Chad Pytel + Lindsey Christensen + Teikametrics + + + Product Roadmaps + https://podcast.thoughtbot.com/359 + 60566f05-9508-4a8d-af4f-8e58aa731617 + Mon, 06 Apr 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey discuss their experiences around, and the pros and cons of, product road maps. + 41:48 + no + + Chad and Lindsey discuss their experiences around, and the pros and cons of, product road maps. +Enroll in our free online-workshop on code audits How to supercharge your Rails application with a code audit (https://info.thoughtbot.com/code-audit-workshop?utm_source=GiantRobots&utm_medium=Podcast) +Scott Miller on Giant Robots (https://www.giantrobots.fm/356) +Quora Thread (https://www.quora.com/Have-you-ever-seen-companies-make-their-product-roadmap-public-Should-they-ever) on companies with public product roadmaps +AirPower is Dead. Here's What Happened (https://www.macrumors.com/guide/airpower/) +Buffer’s Transparent Product Roadmap (https://open.buffer.com/transparent-product-roadmap/) +Slack Platform Roadmap (https://api.slack.com/roadmap) +GitHub Universe Conference (https://githubuniverse.com/) +Devon Zuegel on Giant Robots (https://www.giantrobots.fm/334) +Wistia on Giant Robots (https://www.giantrobots.fm/254) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + product roadmap, transparency, public, + + Chad and Lindsey discuss their experiences around, and the pros and cons of, product road maps.

+ +

Enroll in our free online-workshop on code audits How to supercharge your Rails application with a code audit

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey discuss their experiences around, and the pros and cons of, product road maps.

+ +

Enroll in our free online-workshop on code audits How to supercharge your Rails application with a code audit

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bPMmwUUE + + ]]> + + Chad Pytel + Lindsey Christensen + + + Giant Robots v1 + https://podcast.thoughtbot.com/358 + 1655345b-a2c6-42e9-955f-615c624264e4 + Mon, 30 Mar 2020 00:15:00 -0400 + thoughtbot + + full + 9 + thoughtbot + Chad and Lindsey announce Giant Robots' latest evolution as a long-form startup series, following three startups over the course of a year. Throughout the season we will celebrate the wins, learn from the setbacks, explore how they approach high-concept issues, and truly capture the arc of a year in the life of their startup! + 18:03 + no + + Chad and Lindsey announce Giant Robots' latest evolution as a long-form startup series, following three startups over the course of a year. Throughout the season we will celebrate the wins, learn from the setbacks, explore how they approach high-concept issues, and truly capture the arc of a year in the life of their startup! +Enroll in our free online-workshop on going remote Being Human in the Absence of Humans: A Live Q&A for Product Teams (https://info.thoughtbot.com/being-human-in-the-absence-of-humans?utm_source=GiantRobots&utm_medium=Podcast) +Michael Sheeley on Giant Robots (https://www.giantrobots.fm/277) +Nurse-1-1 (https://nurse-1-1.com/) +Courtney & Tye Caldwell on Giant Robots (https://www.giantrobots.fm/331) +ShearShare (https://shearshare.com/) +Aatish Salvi on Giant Robots (https://www.giantrobots.fm/301) +Teikametrics (https://www.teikametrics.com/) +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Chad and Lindsey announce Giant Robots' latest evolution as a long-form startup series, following three startups over the course of a year. Throughout the season we will celebrate the wins, learn from the setbacks, explore how they approach high-concept issues, and truly capture the arc of a year in the life of their startup!

+ +

Enroll in our free online-workshop on going remote Being Human in the Absence of Humans: A Live Q&A for Product Teams

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad and Lindsey announce Giant Robots' latest evolution as a long-form startup series, following three startups over the course of a year. Throughout the season we will celebrate the wins, learn from the setbacks, explore how they approach high-concept issues, and truly capture the arc of a year in the life of their startup!

+ +

Enroll in our free online-workshop on going remote Being Human in the Absence of Humans: A Live Q&A for Product Teams

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mi5q6TXq + + ]]> + + Chad Pytel + Lindsey Christensen + + + 357: Sustainable Growth Hacking (Anuj Adhiya) + https://podcast.thoughtbot.com/357 + 509d1f0b-ded8-474a-a915-c51a90ea6ea0 + Mon, 23 Mar 2020 00:15:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Anuj Adhiya, VP of Growth at Jamber, discusses 'growth' vs 'growth hacking', growing value through your north-star metric, A/B testing, and sustainability. + 50:54 + no + + Anuj Adhiya, VP of Growth at Jamber, discusses 'growth' vs 'growth hacking', growing value through your north-star metric, A/B testing, and sustainability. +This episode is brought to you by ExpressVPN (https://www.expressvpn.com/ROBOTS). +Click through to get three months for free. +Jamber (https://www.jamber.com/) +Growth Hacking For Dummies (https://amzn.to/2TXBm6B) +Karen Rubin on Giant Robots (https://www.giantrobots.fm/348) +GrowthHackers AMA with Karen Rubin (https://growthhackers.com/amas/karen-rubin-vp-growth-owl-labs) +Pirate Metrics (https://www.pierrelechelle.com/aarrr-pirate-metrics) +Anuj on Twitter (https://twitter.com/AnujAdhiya) +Nerd-out about growth hacking w/ Anuj! (https://adhiya.youcanbook.me/) +See open positions (https://goo.gl/AAazrT) at thoughtbot! +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + marketing, growth, growth hacking, north star, value, metrics, tooling, A/B test, + + Anuj Adhiya, VP of Growth at Jamber, discusses 'growth' vs 'growth hacking', growing value through your north-star metric, A/B testing, and sustainability.

+ +

This episode is brought to you by ExpressVPN.

+Click through to get three months for free.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Anuj Adhiya, VP of Growth at Jamber, discusses 'growth' vs 'growth hacking', growing value through your north-star metric, A/B testing, and sustainability.

+ +

This episode is brought to you by ExpressVPN.

+Click through to get three months for free.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Sponsored By:

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+a6Y-stb5 + + ]]> + + + + 356: Start From the Beginning (Scott Miller) + https://podcast.thoughtbot.com/356 + 2aa4b8d0-c417-4ff3-a2d4-ec1031fe0fd8 + Mon, 24 Feb 2020 00:15:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Scott Miller, CEO of Dragon Innovation and co-founder of Bolt, discusses building out manufacturing from a prototype, sustainability & environmentalism, and working with thoughtbot to validate a software idea. + 46:39 + no + + Scott Miller, CEO of Dragon Innovation and co-founder of Bolt, discusses building out manufacturing from a prototype, sustainability & environmentalism, and working with thoughtbot to validate a software idea. +Dragon Innovation (https://www.dragoninnovation.com/) +Bolt (https://bolt.io/) +Dragon Standard BOM (https://gsuite.google.com/marketplace/app/dragon_standard_bom/499121254478?pann=cwsdp&hl=en) +Halloween Robot v2 (https://www.hackster.io/DragonInnovation/halloween-robot-v2-f0d322) +Adruino Bathroom Sensor Breakdown on Giant Robots (https://www.giantrobots.fm/87) +Scott on LinkedIn (https://www.linkedin.com/in/scottnmiller/) +See open positions (https://goo.gl/AAazrT) at thoughtbot! +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + + Scott Miller, CEO of Dragon Innovation and co-founder of Bolt, discusses building out manufacturing from a prototype, sustainability & environmentalism, and working with thoughtbot to validate a software idea.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Scott Miller, CEO of Dragon Innovation and co-founder of Bolt, discusses building out manufacturing from a prototype, sustainability & environmentalism, and working with thoughtbot to validate a software idea.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+nZ7w8nKY + + ]]> + + + + 355: The New Hospitality (Maria Loughlin) + https://podcast.thoughtbot.com/355 + 8454a29a-1dd7-4d8f-8b2c-e8714243c94d + Mon, 17 Feb 2020 00:15:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Maria Loughlin, VP of Engineering at Toast, discusses restaurants adaptation to new technology, her approach to building and supporting a team, and providing better business opportunities & education to their clients. + 35:24 + no + + Maria Loughlin, VP of Engineering at Toast, discusses restaurants adaptation to new technology, her approach to building and supporting a team, and providing better business opportunities & education to their clients. +Toast (https://pos.toasttab.com/) +Toast.org (https://toast.org/) +Maria on Twitter (https://twitter.com/MariaLoughlin) +See open positions (https://goo.gl/AAazrT) at thoughtbot! +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + restaurant tech, D&I, knowledge share + + Maria Loughlin, VP of Engineering at Toast, discusses restaurants adaptation to new technology, her approach to building and supporting a team, and providing better business opportunities & education to their clients.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Maria Loughlin, VP of Engineering at Toast, discusses restaurants adaptation to new technology, her approach to building and supporting a team, and providing better business opportunities & education to their clients.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dA-kGxHM + + ]]> + + + + 354: Securing Opportunity (Shelly Bell) + https://podcast.thoughtbot.com/354 + 3bf9a1ad-fbe2-4807-8e39-571b9d24ffe2 + Mon, 10 Feb 2020 00:15:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Shelly Bell, CEO & Founder of Black Girl Ventures, discusses working to open up your messaging, what makes for a good pitch, and the current state of the investment landscape. + 36:11 + no + + Shelly Bell, CEO & Founder of Black Girl Ventures, discusses working to open up your messaging, what makes for a good pitch, and the current state of the investment landscape. +Black Girl Ventures (https://www.blackgirlventures.org/) +Ragbaby Exchange (http://ragbabyexch.org/) +BEACON (https://www.thebeacondc.com/) +"Male and Female Entrepreneurs Get Asked Different Questions by VCs — and It Affects How Much Funding They Get" (https://hbr.org/2017/06/male-and-female-entrepreneurs-get-asked-different-questions-by-vcs-and-it-affects-how-much-funding-they-get)- Harvard Business Review +SheRaise (https://www.sheraise.com/) +Shelly on Twitter (https://twitter.com/iamshellybell) +See open positions (https://goo.gl/AAazrT) at thoughtbot! +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + community, bias, vc, venture funding, underrepresented, + + Shelly Bell, CEO & Founder of Black Girl Ventures, discusses working to open up your messaging, what makes for a good pitch, and the current state of the investment landscape.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Shelly Bell, CEO & Founder of Black Girl Ventures, discusses working to open up your messaging, what makes for a good pitch, and the current state of the investment landscape.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+b9gcs7b3 + + ]]> + + + + 353: Built off of Hustle (Ashlee Ammons & Kerry Schrader) + https://podcast.thoughtbot.com/353 + 8b48815b-c7b3-4380-a5d6-735990b914c8 + Mon, 03 Feb 2020 00:15:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Ashlee Ammons & Kerry Schrader, co-founders of Mixtroz, discuss the pain points in attending networking events, building an app from a non-technical / non-entrepreneurial background, and share some of their personal challenges along the way. + 45:04 + no + + Ashlee Ammons & Kerry Schrader, co-founders of Mixtroz, discuss the pain points in attending networking events, building an app from a non-technical / non-entrepreneurial background, and share some of their personal challenges along the way. +Mixtroz (https://www.mixtroz.com/) +The Third Wave (https://amzn.to/2vjDY4z)- Steve Case +Ashlee on Instagram (https://www.instagram.com/shemixalot87/) +Kerry on Instagram (https://www.instagram.com/themillennialplus/) +See open positions (https://goo.gl/AAazrT) at thoughtbot! +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + networking, saas, + + Ashlee Ammons & Kerry Schrader, co-founders of Mixtroz, discuss the pain points in attending networking events, building an app from a non-technical / non-entrepreneurial background, and share some of their personal challenges along the way.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ashlee Ammons & Kerry Schrader, co-founders of Mixtroz, discuss the pain points in attending networking events, building an app from a non-technical / non-entrepreneurial background, and share some of their personal challenges along the way.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+TMSFKxUZ + + ]]> + + + + 352: How Stories Are Told (Matt Daniels) + https://podcast.thoughtbot.com/352 + 9334cd8c-02d7-4d0b-872f-f6b19f433039 + Mon, 27 Jan 2020 00:15:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Matt Daniels, journalist at _The Pudding_, discusses journalistic editorial funding models, translating ideas through visual communication, their content-creation processes, and measuring 'success' in creative work. + 39:50 + no + + Matt Daniels, journalist at The Pudding, discusses journalistic editorial funding models, translating ideas through visual communication, their content-creation processes, and measuring 'success' in creative work. +The Pudding (https://pudding.cool/) +Polygraph (http://polygraph.cool/) +Shape Up (https://basecamp.com/shapeup)- Basecamp +Shangri-La (recording studio) (https://en.wikipedia.org/wiki/Shangri-La_(recording_studio)) +Holacracy (https://www.holacracy.org/) +Editorial Data Viz Lunch 'n Learn @ thoughtbot (https://youtu.be/wxIaKasPrPY) +Matt on Twitter (https://twitter.com/matthew_daniels) +See open positions (https://goo.gl/AAazrT) at thoughtbot! +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + journalism, editorial, visual communication, data viz, impact, success, + + Matt Daniels, journalist at The Pudding, discusses journalistic editorial funding models, translating ideas through visual communication, their content-creation processes, and measuring 'success' in creative work.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Matt Daniels, journalist at The Pudding, discusses journalistic editorial funding models, translating ideas through visual communication, their content-creation processes, and measuring 'success' in creative work.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7n-8YEQP + + ]]> + + + + 351: The Forecast Calls For Goals + https://podcast.thoughtbot.com/351 + 31f42eb5-6b45-428a-ad9b-a3e05290aaff + Tue, 21 Jan 2020 00:15:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Chad & Lindsey welcome in the new year at thoughtbot, discussing actually having a budget, setting corporate goals, and the rise and fall of 'Use Your Best Judgement' as thoughtbot's principle zero. + 37:50 + no + + Chad & Lindsey welcome in the new year at thoughtbot, discussing actually having a budget, setting corporate goals, and the rise and fall of 'Use Your Best Judgement' as thoughtbot's principle zero. +OKR Framework (https://objectives-key-results.com/) +OGSM Framework (https://en.wikipedia.org/wiki/OGSM) +Health Tech Workshop (https://info.thoughtbot.com/building-compliant-health-tech-products-recording): How to stay agile when building compliant health tech products +Traction: Get a Grip on Your Business (https://amzn.to/35QJetg)- Gino Wickman +See open positions (https://goo.gl/AAazrT) at thoughtbot! +Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! + + goals, goal framework, budget, principle zero, resolution, + + Chad & Lindsey welcome in the new year at thoughtbot, discussing actually having a budget, setting corporate goals, and the rise and fall of 'Use Your Best Judgement' as thoughtbot's principle zero.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad & Lindsey welcome in the new year at thoughtbot, discussing actually having a budget, setting corporate goals, and the rise and fall of 'Use Your Best Judgement' as thoughtbot's principle zero.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+E5KCyh3V + + ]]> + + + + 350: Beyond Transit (Tiffany Chu) + https://podcast.thoughtbot.com/350 + 064150a2-de94-4a0d-a9ea-80c4600100b4 + Mon, 13 Jan 2020 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Tiffany Chu, CEO of Remix, discusses the different entities involved in transportation initiatives, pivoting to service an unanticipated user-group, and utilizing open-source in civic tech. + 31:51 + no + + <p>Tiffany Chu, CEO of Remix, discusses the different entities involved in transportation initiatives, pivoting to service an unanticipated user-group, and utilizing open-source in civic tech.</p><ul><li><a href="https://www.remix.com/">Remix</a></li><li><a href="https://www.openstreetmap.org/about">OpenStreetMap</a></li><li><a href="https://twitter.com/tchu88">Tiffany on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Tiffany Chu, CEO of Remix, discusses the different entities involved in transportation initiatives, pivoting to service an unanticipated user-group, and utilizing open-source in civic tech.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Tiffany Chu, CEO of Remix, discusses the different entities involved in transportation initiatives, pivoting to service an unanticipated user-group, and utilizing open-source in civic tech.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9-U6mcE2 + + ]]> + + + + 349: Better Information (Lokesh Dani) + https://podcast.thoughtbot.com/349 + f57936b0-6c4b-4d95-82f7-192d224384ef + Mon, 06 Jan 2020 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Lokesh Dani, founder of Xopolis, discusses researching the future of work, democratizing opportunity in the labor market, and focusing on the user experience. + 34:11 + no + + <p>Lokesh Dani, founder of Xopolis, discusses researching the future of work, democratizing opportunity in the labor market, and focusing on the user experience.</p><ul><li><a href="https://xopol.is/">Xopolis</a></li><li><a href="https://www.nsf.gov/news/special_reports/i-corps/">NSF Innovation Corps</a></li><li><a href="https://www.linkedin.com/in/lokeshdani/">Lokesh on LinkedIn</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Lokesh Dani, founder of Xopolis, discusses researching the future of work, democratizing opportunity in the labor market, and focusing on the user experience.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lokesh Dani, founder of Xopolis, discusses researching the future of work, democratizing opportunity in the labor market, and focusing on the user experience.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+DrFrcXxa + + ]]> + + + + 348: Tailor to the Experience (Karen Rubin) + https://podcast.thoughtbot.com/348 + 1fc0f948-c850-4453-ad58-299ad6ea94b0 + Mon, 30 Dec 2019 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Karen Rubin, CRO at Owl Labs, discusses embracing playful aspects of your product, tailoring their marketing focus, managing growth in a B2B e-commerce company, the landscape of remote work, the complexities of building and selling a physical product, lessons learned from launching products at Hubspot, and building a team with strong female leadership. + 44:49 + no + + <p>Karen Rubin, CRO at Owl Labs, discusses embracing playful aspects of your product, tailoring their marketing focus, managing growth in a B2B e-commerce company, the landscape of remote work, the complexities of building and selling a physical product, lessons learned from launching products at Hubspot, and building a team with strong female leadership.</p><ul><li><a href="https://www.owllabs.com/">Owl Labs</a></li><li><a href="https://twitter.com/ZweihanderRPG/status/1192550357429297152?s=20">Owl as a Bat</a></li><li><a href="https://offers.hubspot.com/company-culture-template-ebook"><i>The Company Culture Cookbook</i></a></li><li><a href="https://twitter.com/karenrubin">Karen on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Karen Rubin, CRO at Owl Labs, discusses embracing playful aspects of your product, tailoring their marketing focus, managing growth in a B2B e-commerce company, the landscape of remote work, the complexities of building and selling a physical product, lessons learned from launching products at Hubspot, and building a team with strong female leadership.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Karen Rubin, CRO at Owl Labs, discusses embracing playful aspects of your product, tailoring their marketing focus, managing growth in a B2B e-commerce company, the landscape of remote work, the complexities of building and selling a physical product, lessons learned from launching products at Hubspot, and building a team with strong female leadership.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YRrDwq7X + + ]]> + + + + 347: Deliver Better Services (Robin Carnahan) + https://podcast.thoughtbot.com/347 + d2f09b17-6ebf-42ac-8d3f-100559a7fb72 + Mon, 09 Dec 2019 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Robin Carnahan, Director of State & Local Practice at 18F, discusses introducing tech into government as the Missouri Secretary of State, facilitating tech-education within the federal government, and the types of needs to which 18F responds. + 29:05 + no + + <p>Robin Carnahan, Director of State & Local Practice at 18F, discusses introducing tech into government as the Missouri Secretary of State, facilitating tech-education within the federal government, and the types of needs to which 18F responds.</p><ul><li><a href="https://18f.gsa.gov/">18F</a></li><li><a href="https://login.gov/">login.gov</a></li><li><a href="https://cloud.gov/">cloud.gov</a></li><li><a href="https://www.launchcode.org/">LaunchCode</a></li><li><a href="https://twitter.com/RobinCarnahan">Robin on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Robin Carnahan, Director of State & Local Practice at 18F, discusses introducing tech into government as the Missouri Secretary of State, facilitating tech-education within the federal government, and the types of needs to which 18F responds.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Robin Carnahan, Director of State & Local Practice at 18F, discusses introducing tech into government as the Missouri Secretary of State, facilitating tech-education within the federal government, and the types of needs to which 18F responds.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+v-P3rk_3 + + ]]> + + + + 346: Empower Users (Geoff DiMasi) + https://podcast.thoughtbot.com/346 + b101705d-1d2a-4d1d-99a0-5a78316211cb + Mon, 02 Dec 2019 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Geoff DiMasi, founder of Punk Ave. & Apostrophe, discusses his drive to build a CMS, balancing maintaining a service company while building a product (as well as the thought-process of spinning out a product into its own company), the Philadelphia tech-scene, and transitioning to a remote company. + 41:04 + no + + <p>Geoff DiMasi, founder of Punk Ave. & Apostrophe, discusses his drive to build a CMS, balancing maintaining a service company while building a product (as well as the thought-process of spinning out a product into its own company), the Philadelphia tech-scene, and transitioning to a remote company.</p><ul><li><a href="https://apostrophecms.com/">ApostropheCMS</a></li><li><a href="https://github.com/apostrophecms">Apostrophe Open Source</a></li><li><a href="https://github.com/thoughtbot">Open Source at thoughtbot</a></li><li><a href="https://thoughtbot.com/upcase">Upcase</a></li><li><a href="https://en.wikipedia.org/wiki/OKR">Objectives and Key Results(OKR) System</a></li><li><a href="https://www.indyhall.org/">Indy Hall Coworking Space</a></li><li><a href="https://jamstack.org/">JAMstack</a></li><li><a href="https://en.wikipedia.org/wiki/Headless_content_management_system">Headless CMS</a></li><li><a href="https://twitter.com/geoffd">Geoff on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Geoff DiMasi, founder of Punk Ave. & Apostrophe, discusses his drive to build a CMS, balancing maintaining a service company while building a product (as well as the thought-process of spinning out a product into its own company), the Philadelphia tech-scene, and transitioning to a remote company.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Geoff DiMasi, founder of Punk Ave. & Apostrophe, discusses his drive to build a CMS, balancing maintaining a service company while building a product (as well as the thought-process of spinning out a product into its own company), the Philadelphia tech-scene, and transitioning to a remote company.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+3-I1LToq + + ]]> + + + + 345: Conviction in the Problem (Alex Cornell) + https://podcast.thoughtbot.com/345 + c05d674a-4837-4c2f-a591-d2735adc2f6f + Mon, 25 Nov 2019 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Alex Cornell, co-founder of Cocoon, discusses opportunity cost, prototyping methodology, having design skills as a founder, designing for intuition, and being invested in the problem you want to solve. + 43:03 + no + + <p>Alex Cornell, co-founder of Cocoon, discusses opportunity cost, prototyping methodology, having design skills as a founder, designing for intuition, and being invested in the problem you want to solve.</p><ul><li><a href="https://ourcocoon.com/">Cocoon</a></li><li><a href="https://www.notion.so/">Notion</a></li><li><a href="https://origami.design/">Origami Prototyping</a></li><li><a href="https://www.ycombinator.com/apply/">Apply to Y Combinator</a></li><li><a href="https://twitter.com/alexcornell">Alex on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Alex Cornell, co-founder of Cocoon, discusses opportunity cost, prototyping methodology, having design skills as a founder, designing for intuition, and being invested in the problem you want to solve.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Alex Cornell, co-founder of Cocoon, discusses opportunity cost, prototyping methodology, having design skills as a founder, designing for intuition, and being invested in the problem you want to solve.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+A2r-01JS + + ]]> + + + + 344: Facilitating Innovation (Heather Ames) + https://podcast.thoughtbot.com/344 + ae961198-e652-4a6b-b784-bfeb38258546 + Mon, 18 Nov 2019 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Heather Ames, co-founder and COO of Neurala, discusses automated visual-inspection, balancing research with deployment, the challenges of productizing AI, and finding the right product/customer fit. + 32:25 + no + + <p>Heather Ames, co-founder and COO of Neurala, discusses automated visual-inspection, balancing research with deployment, the challenges of productizing AI, and finding the right product/customer fit.</p><ul><li><a href="https://www.neurala.com/">Neurala</a></li><li><a href="https://www.neurala.com/solutions/brain">Brain Builder</a></li><li><a href="https://twitter.com/AmesVersace">Heather on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Heather Ames, co-founder and COO of Neurala, discusses automated visual-inspection, balancing research with deployment, the challenges of productizing AI, and finding the right product/customer fit.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Heather Ames, co-founder and COO of Neurala, discusses automated visual-inspection, balancing research with deployment, the challenges of productizing AI, and finding the right product/customer fit.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Hwgqgn09 + + ]]> + + + + 343: A True Movement (Pariss Athena) + https://podcast.thoughtbot.com/343 + 95732487-dbe7-4b3a-8cff-9c1f55ca80f6 + Mon, 04 Nov 2019 00:00:00 -0500 + thoughtbot + + full + 8 + thoughtbot + Pariss Athena, Hiring & Product Team Member at G2i, creator of #BlackTechTwitter, and founder of Black Tech Pipeline, shares her journey from never hearing about code to viral awareness campaign creator, as well as discusses visibility, finding value on twitter, and life online with thousands of followers. + 27:45 + no + + <p>Pariss Athena, Hiring & Product Team Member at G2i, creator of #BlackTechTwitter, and founder of Black Tech Pipeline, shares her journey from never hearing about code to viral awareness campaign creator, as well as discusses visibility, finding value on twitter, and life online with thousands of followers.</p><ul><li><a href="https://www.resilientcoders.org/">Resilient Coders</a></li><li><a href="https://twitter.com/ParissAthena/status/1068873547005812737?s=20">The Tweet that started #BlackTechTwitter</a></li><li><a href="https://blockclubchicago.org/2019/08/08/hannibal-buress-is-building-an-arts-and-technology-center-for-the-future-masterminds-of-the-west-side/">"Hannibal Buress Is Building An Arts And Technology Center For The Future Masterminds Of The West Side"</a></li><li><a href="https://www.blacktechpipeline.com/">Black Tech Pipeline</a></li><li><a href="https://twitter.com/ParissAthena">Pariss on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Pariss Athena, Hiring & Product Team Member at G2i, creator of #BlackTechTwitter, and founder of Black Tech Pipeline, shares her journey from never hearing about code to viral awareness campaign creator, as well as discusses visibility, finding value on twitter, and life online with thousands of followers.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Pariss Athena, Hiring & Product Team Member at G2i, creator of #BlackTechTwitter, and founder of Black Tech Pipeline, shares her journey from never hearing about code to viral awareness campaign creator, as well as discusses visibility, finding value on twitter, and life online with thousands of followers.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jVYwt8Hw + + ]]> + + + + 342: The People Stuff (Jennifer Dary) + https://podcast.thoughtbot.com/342 + d4a69b52-8bf1-452d-8dd5-48797c0ffcd6 + Mon, 28 Oct 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Jennifer Dary, founder of Plucky, rejoins the podcast to discuss the rarity of listening, what it feels like to have a six year-old company, and conducts a 1:1 for managers with Lindsey & Chad. + 45:19 + no + + <p>Jennifer Dary, founder of Plucky, rejoins the podcast to discuss the rarity of listening, what it feels like to have a six year-old company, and conducts a 1:1 for managers with Lindsey & Chad.</p><ul><li><a href="https://www.beplucky.com/">Plucky</a></li><li><a href="https://giantrobots.fm/episodes/270">Jennifer on <i>Giant Robots</i> ep 270</a></li><li><a href="https://www.wsj.com/articles/executive-coach-or-therapist-its-getting-harder-to-tell-the-difference-11568971811">Executive Coach or Therapist?</a></li><li><a href="https://shop.beplucky.com/products/1-1-manager-pack">1:1 Manager Pack</a></li><li><a href="https://www.beplucky.com/manager/">'So Now You're a Manager' Training</a></li><li><a href="https://www.ddo.com">D&D Online</a></li><li><a href="https://www.beplucky.com/newsletter/">Plucky Newsletter</a></li><li><a href="https://twitter.com/jenniferdary">Jennifer on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jennifer Dary, founder of Plucky, rejoins the podcast to discuss the rarity of listening, what it feels like to have a six year-old company, and conducts a 1:1 for managers with Lindsey & Chad.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jennifer Dary, founder of Plucky, rejoins the podcast to discuss the rarity of listening, what it feels like to have a six year-old company, and conducts a 1:1 for managers with Lindsey & Chad.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+HahnzmON + + ]]> + + + + 341: From Survival to Growth (David Kaplan) + https://podcast.thoughtbot.com/341 + acb8248f-50b8-418a-954d-71a5d51a1373 + Mon, 21 Oct 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + David Kaplan, head of engineering at Policygenius, discusses joining an established company in a leadership role, factors for long-term success, choosing Flutter over React Native, and challenging assumptions when building out an MVP. + 36:40 + no + + <p>David Kaplan, head of engineering at Policygenius, discusses joining an established company in a leadership role, factors for long-term success, choosing Flutter over React Native, and challenging assumptions when building out an MVP.</p><ul><li><a href="https://www.policygenius.com/">Policygenius</a></li><li><a href="https://medium.com/policygenius-stories/flutter-vs-react-native-8067a49af71">Flutter vs. React Native</a></li><li><a href="https://www.linkedin.com/in/davebkaplan/">David on LinkedIn</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + David Kaplan, head of engineering at Policygenius, discusses joining an established company in a leadership role, factors for long-term success, choosing Flutter over React Native, and challenging assumptions when building out an MVP.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + David Kaplan, head of engineering at Policygenius, discusses joining an established company in a leadership role, factors for long-term success, choosing Flutter over React Native, and challenging assumptions when building out an MVP.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MsAI8Vs7 + + ]]> + + + + 340: Accessible, Ethical, Inclusive (Cat Noone) + https://podcast.thoughtbot.com/340 + 4aeb4330-4c9a-4b39-a90b-c3131f6ba670 + Mon, 14 Oct 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Cat Noone, CEO of Stark, shares an overview of accessible design, dreams for shaping a more accessible future, helming custom support with a small team, and her motivation to create. + 32:06 + no + + <p>Cat Noone, CEO of Stark, shares an overview of accessible design, dreams for shaping a more accessible future, helming custom support with a small team, and her motivation to create.</p><ul><li><a href="https://www.getstark.co/">Stark</a></li><li><a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility Guidelines (WCAG)</a></li><li><a href="https://getlyra.com/">Lyra</a></li><li><a href="https://stark.substack.com/about">A Stark Difference in Design Newletter</a></li><li><a href="https://twitter.com/imcatnoone">Cat on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Cat Noone, CEO of Stark, shares an overview of accessible design, dreams for shaping a more accessible future, helming custom support with a small team, and her motivation to create.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Cat Noone, CEO of Stark, shares an overview of accessible design, dreams for shaping a more accessible future, helming custom support with a small team, and her motivation to create.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+a_COXwe8 + + ]]> + + + + 339: Process Goals (Andrew Steele) + https://podcast.thoughtbot.com/339 + 7d531437-e65c-434a-a70b-ab7f1c1f0ccc + Mon, 07 Oct 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Andrew Steele, Olympic Medalist & Head of Product at DNAfit, discusses providing actionable wellness utility from DNA data, goal setting, "blame culture", localization, and his time at the Beijing Olympics. + 38:16 + no + + <p>Andrew Steele, Olympic Medalist & Head of Product at DNAfit, discusses providing actionable wellness utility from DNA data, goal setting, "blame culture", localization, and his time at the Beijing Olympics.</p><ul><li><a href="https://www.dnafit.com">DNAfit</a></li><li><a href="https://www.olympic.org/videos/record-time-for-american-men-in-4x400m-relay">Beijing 4x400m Relay Men's Final</a></li><li><a href="https://www.imdb.com/title/tt6333060/?ref_=fn_al_tt_1"><i>Icarus</i> (2017)</a></li><li>20% off Health Fit for <i>Giant Robots</i> Listeners<ul><li><a href="https://www.dnafit.com/cart/HEALTH-FIT/1/usd/GIANTROBOTS/">in $USD</a></li><li><a href="https://www.dnafit.com/cart/HEALTH-FIT/1/gbp/GIANTROBOTS/">In £GBP</a> </li></ul></li><li><a href="https://twitter.com/AndrewSteele">Andrew on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + +

Andrew Steele, Olympic Medalist & Head of Product at DNAfit, discusses providing actionable wellness utility from DNA data, goal setting, "blame culture", localization, and his time at the Beijing Olympics.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + +

Andrew Steele, Olympic Medalist & Head of Product at DNAfit, discusses providing actionable wellness utility from DNA data, goal setting, "blame culture", localization, and his time at the Beijing Olympics.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_WAWwRuI + + ]]> + + + + 338: Automating SaaS (Bryan Helmig) + https://podcast.thoughtbot.com/338 + c1133057-4974-49af-a749-58f4ecd9937e + Mon, 30 Sep 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Bryan Helmig, cofounder & CTO of Zapier, discusses extending tooling to small businesses through API integration, scaling, early marketing successes, and the future of automation. + 39:53 + no + + <p>Bryan Helmig, cofounder & CTO of Zapier, discusses extending tooling to small businesses through API integration, scaling, early marketing successes, and the future of automation. </p><ul><li><a href="https://zapier.com/">Zapier</a></li><li><a href="mailto:bryan@zapier.com">Contact Bryan</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Bryan Helmig, cofounder & CTO of Zapier, discusses extending tooling to small businesses through API integration, scaling, early marketing successes, and the future of automation.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Bryan Helmig, cofounder & CTO of Zapier, discusses extending tooling to small businesses through API integration, scaling, early marketing successes, and the future of automation.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+i7Z6Q4bv + + ]]> + + + + 337: Outcomes, Not Outputs (Adam Scroggin) + https://podcast.thoughtbot.com/337 + be0153d9-38da-40f8-be15-e86e3a6ff3bd + Mon, 23 Sep 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Adam Scroggin, CEO of CardBoard, discusses user story mapping, consulting vs product work, the importance of goal setting, product market fit, and his favorite tools & services for building web apps. + 42:18 + no + + <p>Adam Scroggin, CEO of CardBoard, discusses user story mapping, consulting vs product work, the importance of goal setting, product market fit, and his favorite tools & services for building web apps.</p><ul><li><a href="https://cardboardit.com/">CardBoard</a></li><li><a href="https://www.heroku.com/private-spaces">Heroku Private Spaces</a></li><li><a href="mailto:adam@cardboardit.com">Contact Adam</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Adam Scroggin, CEO of CardBoard, discusses user story mapping, consulting vs product work, the importance of goal setting, product market fit, and his favorite tools & services for building web apps.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Adam Scroggin, CEO of CardBoard, discusses user story mapping, consulting vs product work, the importance of goal setting, product market fit, and his favorite tools & services for building web apps.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+WbwXnvbm + + ]]> + + + + 336: There's No Manual (Chris Coyier) + https://podcast.thoughtbot.com/336 + c5fe4800-540e-417c-a331-2b98f1c9b8fd + Mon, 16 Sep 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Chris Coyier, cofounder of CodePen, creator of CSS-Tricks, & host of Shop Talk Show, candidly shares how a weekend project turned into a full-time business, aspirations for the future, and areas for improvement. + 40:36 + no + + <p>Chris Coyier, cofounder of CodePen, creator of CSS-Tricks, & host of <i>Shop Talk Show</i>, candidly shares how a weekend project turned into a full-time business, aspirations for the future, and areas for improvement.</p><ul><li><a href="http://codepen.io/">CodePen</a></li><li><a href="https://css-tricks.com/">CSS-Tricks</a></li><li><a href="https://shoptalkshow.com/"><i>Shop Talk Show</i> Podcast</a></li><li><a href="https://en.wikipedia.org/wiki/TechTV">TechTV</a></li><li><a href="https://chriscoyier.net">ChrisCoyier.net</a></li><li><a href="https://twitter.com/chriscoyier">Chris on Twitter</a></li></ul><p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p><p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chris Coyier, cofounder of CodePen, creator of CSS-Tricks, & host of Shop Talk Show, candidly shares how a weekend project turned into a full-time business, aspirations for the future, and areas for improvement.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris Coyier, cofounder of CodePen, creator of CSS-Tricks, & host of Shop Talk Show, candidly shares how a weekend project turned into a full-time business, aspirations for the future, and areas for improvement.

See open positions at thoughtbot!

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hW5fPYWS + + ]]> + + + + 335: Discipline & Creativity (Jonathan Cutrell) + https://podcast.thoughtbot.com/335 + 341c8f95-8306-4f9f-988a-aaafe8757999 + Mon, 09 Sep 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Jonathan Cutrell, host of Developer Tea and Senior Engineer at Clearbit, discusses the history of the podcast, motivation for creation, learning to say 'no', and what it means to truly be 'remote-friendly'. + 30:52 + no + + <p>Jonathan Cutrell, host of Developer Tea and Senior Engineer at Clearbit, discusses the history of the podcast, motivation for creation, learning to say 'no', and what it means to truly be 'remote-friendly'.</p> +<ul> +<li><a href="https://clearbit.com/">Clearbit</a></li> +<li><a href="https://developertea.simplecast.fm/"><em>Developer Tea</em> Podcast</a></li> +<li><a href="https://spec.fm/">Spec</a></li> +<li><a href="https://www.teabreakchallenge.com/">Tea Break Challenge</a></li> +<li><a href="https://twitter.com/JCutrell">Jonathan on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jonathan Cutrell, host of Developer Tea and Senior Engineer at Clearbit, discusses the history of the podcast, motivation for creation, learning to say 'no', and what it means to truly be 'remote-friendly'.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jonathan Cutrell, host of Developer Tea and Senior Engineer at Clearbit, discusses the history of the podcast, motivation for creation, learning to say 'no', and what it means to truly be 'remote-friendly'.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+arhqBzVa + + ]]> + + + + 334: Preserve and Extend (Devon Zuegel) + https://podcast.thoughtbot.com/334 + fc981a6d-9dfd-40a4-ab56-8f9b36faf688 + Mon, 02 Sep 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Devon Zuegel, Product Manager at GitHub, discusses her transition from researcher to product manager, and shepherding the funding, communication, and tooling of open source sustainability. + 41:23 + no + + <p>Devon Zuegel, Product Manager at GitHub, discusses her transition from researcher to product manager, and shepherding the funding, communication, and tooling of open source sustainability.</p> +<ul> +<li><a href="https://github.com/">GitHub</a></li> +<li><a href="https://bikeshed.fm/episodes/191">Devon on <em>The Bike Shed</em></a></li> +<li><a href="https://github.com/sponsors">GitHub Sponsors</a></li> +<li><a href="https://github.blog/2019-01-17-lets-talk-about-open-source-sustainability/">Let’s talk about open source sustainability</a></li> +<li><a href="https://www.youtube.com/playlist?list=PL0lo9MOBetEFXbNHpObS6VQJPI2sibuwn">GitHub Satellite 2019</a></li> +<li><a href="https://github.com/thoughtbot">thoughtbot open source projects</a></li> +<li><a href="https://twitter.com/devonzuegel">Devon on Twitter</a></li> +</ul> +<p>Learn more about <a href="https://youtu.be/0v3MA995s7Y">open source at thoughtbot</a>.</p> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Devon Zuegel, Product Manager at GitHub, discusses her transition from researcher to product manager, and shepherding the funding, communication, and tooling of open source sustainability.

+ + + +

Learn more about open source at thoughtbot.

+ +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Devon Zuegel, Product Manager at GitHub, discusses her transition from researcher to product manager, and shepherding the funding, communication, and tooling of open source sustainability.

+ + + +

Learn more about open source at thoughtbot.

+ +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+smnkp4PI + + ]]> + + + + 333: Do Fewer Things Better (Matt Massicotte) + https://podcast.thoughtbot.com/333 + bb8162e7-640f-46a0-ab12-83f488a7ef75 + Mon, 26 Aug 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Matt Massicotte, creator of Chime, discusses the landscape of text editors, the complexities of writing your own parsers, building a new product while building a new family, and alternative app platform & pricing models. + 38:21 + no + + <p>Matt Massicotte, creator of Chime, discusses the landscape of text editors, the complexities of writing your own parsers, building a new product while building a new family, and alternative app platform &amp; pricing models.</p> +<ul> +<li><a href="https://www.chimehq.com/">Chime</a></li> +<li><a href="https://twitter.com/mattie">Matt on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Matt Massicotte, creator of Chime, discusses the landscape of text editors, the complexities of writing your own parsers, building a new product while building a new family, and alternative app platform & pricing models.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Matt Massicotte, creator of Chime, discusses the landscape of text editors, the complexities of writing your own parsers, building a new product while building a new family, and alternative app platform & pricing models.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+DCnYJi1q + + ]]> + + + + 332: Grow to Accommodate (Jordan Berke) + https://podcast.thoughtbot.com/332 + 8c228a8d-a4eb-423a-8a75-99a6bdca0552 + Mon, 19 Aug 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Jordan Berke, CEO & founder of RepOne Strength, discusses finding your customers, working in the world of open source hardware, sourcing materials, relentless work pace, and bootstrapping. + 33:04 + no + + <p>Jordan Berke, CEO &amp; founder of RepOne Strength, discusses finding your customers, working in the world of open source hardware, sourcing materials, relentless work pace, and bootstrapping.</p> +<ul> +<li><a href="https://www.reponestrength.com/">RepOne Strength</a></li> +<li><a href="https://www.meetup.com/Open-Source-NYC/">Open Source NYC</a></li> +<li><a href="https://www.businessinsider.com/bill-gates-startup-founders-should-not-take-vacations-2019-6">&quot;Bill Gates says startup founders should not take weekends or vacations in the early days of building a company&quot;</a>- Business Insider</li> +<li><a href="https://www.linkedin.com/in/jordan-berke-7ab700ab/">Jordan on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jordan Berke, CEO & founder of RepOne Strength, discusses finding your customers, working in the world of open source hardware, sourcing materials, relentless work pace, and bootstrapping.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jordan Berke, CEO & founder of RepOne Strength, discusses finding your customers, working in the world of open source hardware, sourcing materials, relentless work pace, and bootstrapping.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rnohIbwp + + ]]> + + + + 331: Deep Industry Expertise (Courtney & Tye Caldwell) + https://podcast.thoughtbot.com/331 + f942ee5d-7966-46fa-9ffb-3791de6a8cb2 + Mon, 12 Aug 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Courtney & Tye Caldwell, Co-founders of ShearShare, discuss their journey from salon owners to startup founders, defining an MVP and maintaining a narrow focus for your product. + 50:37 + no + + <p>Courtney &amp; Tye Caldwell, Co-founders of ShearShare, discuss their journey from salon owners to startup founders, defining an MVP and maintaining a narrow focus for your product.</p> +<ul> +<li><a href="https://shearshare.com/">ShearShare</a></li> +<li><a href="https://amzn.to/2GOxjCe"><em>Mentored by Failure</em></a>- Tye Caldwell</li> +<li><a href="https://www.salontoday.com/374804/shearshare-new-partnership-simplifies-the-financials-for-solo-artists">ShearShare Simplifying Financials</a></li> +<li><a href="https://tech.co/news/shearshare-startup-of-the-year-innovate-celebrate-2016-09">Tech.Co Startup of the Year 2016</a></li> +<li><a href="https://twitter.com/ShearShareCOO">Courtney on Twitter</a></li> +<li><a href="https://twitter.com/drtyecaldwell">Tye on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + Special Guest: ShearShare. + + + Courtney & Tye Caldwell, Co-founders of ShearShare, discuss their journey from salon owners to startup founders, defining an MVP and maintaining a narrow focus for your product.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Courtney & Tye Caldwell, Co-founders of ShearShare, discuss their journey from salon owners to startup founders, defining an MVP and maintaining a narrow focus for your product.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Special Guest: ShearShare.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_Bo0ITfL + + ]]> + + ShearShare + + + 330: There's So Much Potential (Tess Posner) + https://podcast.thoughtbot.com/330 + 7f8c65ac-5f46-4236-a7fd-748f1df62379 + Mon, 05 Aug 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Tess Posner, CEO of AI4ALL, gives an overview of the field of AI and discusses representation in AI careers, the ramifications of not having diversity in tech, the role of allies, and the future of work. + 41:20 + no + + <p>Tess Posner, CEO of AI4ALL, gives an overview of the field of AI and discusses representation in AI careers, the ramifications of not having diversity in tech, the role of allies, and the future of work.</p> +<ul> +<li><a href="http://ai-4-all.org/">AI4ALL</a></li> +<li><a href="http://ai-4-all.org/summer-programs/">AI4ALL Summer Programs</a></li> +<li><a href="https://newsroom.intel.com/newsroom/wp-content/uploads/sites/11/2016/07/Diversity_report_7.7.16_web-1.pdf">&quot;Decoding Diversity&quot;</a>- Intel study on the financial and economic returns to diversity in tech</li> +<li><a href="https://www.kaporcenter.org/tech-leavers/">&quot;Tech Leavers Study&quot;</a>- from Kapor Center for Social Impact</li> +<li><a href="https://www.linkedin.com/pulse/diversity-crisis-ai-together-we-can-fix-tess-gilman-posner/">&quot;There is a diversity crisis in AI, but together we can fix it.&quot;</a>- Tess Posner</li> +<li><a href="https://amzn.to/316Ojvn"><em>Algorithms of Oppression</em></a>- Safiya Umoja Noble</li> +<li><a href="https://amzn.to/2LPNhjJ"><em>Automating Inequality</em></a>- Virginia Eubanks</li> +<li><a href="http://gendershades.org/">The Gender Shades Project</a></li> +<li><a href="https://twitter.com/RealSaavedra/status/1104815221217026049?s=20">AOC on Automation (SxSW 2019)</a></li> +<li><a href="https://www.opportunityatwork.org/">Opportunity@Work</a></li> +<li><a href="http://ai-4-all.org/open-learning/">Open Learning</a></li> +<li><a href="https://twitter.com/tessposner">Tess on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + +

Tess Posner, CEO of AI4ALL, gives an overview of the field of AI and discusses representation in AI careers, the ramifications of not having diversity in tech, the role of allies, and the future of work.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + +

Tess Posner, CEO of AI4ALL, gives an overview of the field of AI and discusses representation in AI careers, the ramifications of not having diversity in tech, the role of allies, and the future of work.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+-keUCDi8 + + ]]> + + + + 329: The Detail Stuff (Jon Werner) + https://podcast.thoughtbot.com/329 + a1233c81-20cc-43e6-b3c5-57d8f1dabace + Mon, 29 Jul 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Jon Werner, CEO & Co-Founder of KOYA Innovations, discusses running a startup with his family, protecting one's intellectual property, the importance of forethought, and developing a platform for kindness. + 52:41 + no + + <p>Jon Werner, CEO &amp; Co-Founder of KOYA Innovations, discusses running a startup with his family, protecting one's intellectual property, the importance of forethought, and developing a platform for kindness.</p> +<p>This episode of <em>Giant Robots</em> is sponsored by:</p> +<ul> +<li><a href="http://www.islonline.com/giantrobots">ISL Online</a></li> +<li><a href="http://www.indeedprime.com/thoughtbot">Indeed Prime</a></li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://getkoya.com/">Koya</a></li> +<li><a href="https://www.linkedin.com/in/jonwerner/">Jon on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jon Werner, CEO & Co-Founder of KOYA Innovations, discusses running a startup with his family, protecting one's intellectual property, the importance of forethought, and developing a platform for kindness.

+ +

This episode of Giant Robots is sponsored by:

+ + + +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jon Werner, CEO & Co-Founder of KOYA Innovations, discusses running a startup with his family, protecting one's intellectual property, the importance of forethought, and developing a platform for kindness.

+ +

This episode of Giant Robots is sponsored by:

+ + + +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+yMMyUEbY + + ]]> + + + + 328: Reliability First (Rob Zuber) + https://podcast.thoughtbot.com/328 + 410b41df-939d-4b9c-ac97-a398ee547dee + Mon, 22 Jul 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Rob Zuber, CTO of CircleCI, discusses prioritizing product direction, scaling, slow iteration to introduce major changes, and what's next for the platform. + 41:59 + no + + <p>Rob Zuber, CTO of CircleCI, discusses prioritizing product direction, scaling, slow iteration to introduce major changes, and what's next for the platform.</p> +<ul> +<li><a href="https://circleci.com/">CircleCI</a></li> +<li><a href="https://en.wikipedia.org/wiki/Chaos_engineering">Chaos Engineering</a></li> +<li><a href="https://circleci.com/orbs/">Orbs</a></li> +<li><a href="https://twitter.com/z00b">Rob on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Rob Zuber, CTO of CircleCI, discusses prioritizing product direction, scaling, slow iteration to introduce major changes, and what's next for the platform.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Rob Zuber, CTO of CircleCI, discusses prioritizing product direction, scaling, slow iteration to introduce major changes, and what's next for the platform.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+o4nOTFzS + + ]]> + + + + 327: Lead By Listening (Kate Brigham) + https://podcast.thoughtbot.com/327 + 82a780c7-4fd5-4ce6-b9da-dbed1bc0f4c1 + Mon, 08 Jul 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Kate Brigham, VP of Product, Design, & Research at ezCater, discusses organizational design, roadmaps, user-research, designing to solve the needs of several groups at once, and, as a leader, empowering others to solve problems. + 45:24 + no + + <p>Kate Brigham, VP of Product, Design, &amp; Research at ezCater, discusses organizational design, roadmaps, user-research, designing to solve the needs of several groups at once, and, as a leader, empowering others to solve problems.</p> +<p>This episode of <em>Giant Robots</em> is sponsored by:</p> +<ul> +<li><a href="http://www.islonline.com/giantrobots">ISL Online</a></li> +<li><a href="http://www.indeedprime.com/thoughtbot">Indeed Prime</a></li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://www.ezcater.com/">ezCater</a></li> +<li><a href="http://giantrobots.fm/321">Stefania Mallett on <em>Giant Robots</em></a></li> +<li><a href="https://www.patientslikeme.com/">PatientsLikeMe</a></li> +<li><a href="https://twitter.com/kbrigham">Kate on Twitter</a></li> +<li><a href="https://www.linkedin.com/in/katebrigham/">Kate on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Kate Brigham, VP of Product, Design, & Research at ezCater, discusses organizational design, roadmaps, user-research, designing to solve the needs of several groups at once, and, as a leader, empowering others to solve problems.

+ +

This episode of Giant Robots is sponsored by:

+ + + +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Kate Brigham, VP of Product, Design, & Research at ezCater, discusses organizational design, roadmaps, user-research, designing to solve the needs of several groups at once, and, as a leader, empowering others to solve problems.

+ +

This episode of Giant Robots is sponsored by:

+ + + +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0A_C4kpW + + ]]> + + + + 326: Building the Whole Landscape (Morgan Evans) + https://podcast.thoughtbot.com/326 + 25b96ca3-bca7-46b2-9d5e-1af8607a57ab + Mon, 01 Jul 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Morgan Evans, organizational designer and CEO & Founder of Business Casual, discusses developing systems to holistically design a company, building a culture that is receptive to feedback, conflict mediation, acknowledging emotions while at work, and early days at Etsy. + 43:00 + no + + <p>Morgan Evans, organizational designer and CEO &amp; Founder of Business Casual, discusses developing systems to holistically design a company, building a culture that is receptive to feedback, conflict mediation, acknowledging emotions while at work, and early days at Etsy.</p> +<ul> +<li><a href="http://thisisbusinesscasual.com/index.html">Business Casual</a></li> +<li><a href="https://twitter.com/NeonMorgan">Morgan on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Morgan Evans, organizational designer and CEO & Founder of Business Casual, discusses developing systems to holistically design a company, building a culture that is receptive to feedback, conflict mediation, acknowledging emotions while at work, and early days at Etsy.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Morgan Evans, organizational designer and CEO & Founder of Business Casual, discusses developing systems to holistically design a company, building a culture that is receptive to feedback, conflict mediation, acknowledging emotions while at work, and early days at Etsy.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+1ASn5_Lj + + ]]> + + + + 325: Wallet-Power (Vanessa Bruce) + https://podcast.thoughtbot.com/325 + b3bfdb4e-4898-4ad8-bc01-c6a4ef8015fa + Mon, 24 Jun 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Vanessa Bruce, co-founder of Dough, discusses affecting change through individual purchase-power, how she handles context-switching, choosing a platform to optimize for content creation, the challenge of visibility, and the decision to launch nationally. + 40:44 + no + + <p>Vanessa Bruce, co-founder of Dough, discusses affecting change through individual purchase-power, how she handles context-switching, choosing a platform to optimize for content creation, the challenge of visibility, and the decision to launch nationally.</p> +<p>This episode of <em>Giant Robots</em> is sponsored by:</p> +<ul> +<li><a href="http://www.islonline.com/giantrobots">ISL Online</a></li> +<li><a href="http://www.indeedprime.com/thoughtbot">Indeed Prime</a></li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://www.joindough.com/">Dough</a></li> +<li><a href="https://www.joindough.com/become-a-member">Dough Membership</a></li> +<li><a href="https://open.buffer.com/introducing-open-salaries-at-buffer-including-our-transparent-formula-and-all-individual-salaries/">Open Salaries at Buffer</a></li> +<li><a href="https://www.linkedin.com/in/vmacaulay/">Vanessa on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Vanessa Bruce, co-founder of Dough, discusses affecting change through individual purchase-power, how she handles context-switching, choosing a platform to optimize for content creation, the challenge of visibility, and the decision to launch nationally.

+ +

This episode of Giant Robots is sponsored by:

+ + + +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Vanessa Bruce, co-founder of Dough, discusses affecting change through individual purchase-power, how she handles context-switching, choosing a platform to optimize for content creation, the challenge of visibility, and the decision to launch nationally.

+ +

This episode of Giant Robots is sponsored by:

+ + + +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0mnXXXY5 + + ]]> + + + + 324: Tap the Market (Karyl Fowler) + https://podcast.thoughtbot.com/324 + ab953c63-563b-449a-9173-b87563457b63 + Mon, 17 Jun 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Karyl Fowler, CEO & Co-founder of Transmute, discusses utilizing block chain for decentralized identity-management, exploring finding the right customer profile fits, education around data-security, her time at Techstars, and the startup community in Austin. + 47:54 + no + + <p>Karyl Fowler, CEO &amp; Co-founder of Transmute, discusses utilizing block chain for decentralized identity-management, exploring finding the right customer profile fits, education around data-security, her time at Techstars, and the startup community in Austin.</p> +<ul> +<li><a href="https://www.transmute.industries/">Transmute</a></li> +<li><a href="https://www.transmute.industries/logistics">Transmute ID</a></li> +<li><a href="https://www.techstars.com/">Techstars</a></li> +<li><a href="https://medium.com/@Transmute">Transmute News Blog</a></li> +<li><a href="https://twitter.com/TheKaryl">Karyl on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Karyl Fowler, CEO & Co-founder of Transmute, discusses utilizing block chain for decentralized identity-management, exploring finding the right customer profile fits, education around data-security, her time at Techstars, and the startup community in Austin.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Karyl Fowler, CEO & Co-founder of Transmute, discusses utilizing block chain for decentralized identity-management, exploring finding the right customer profile fits, education around data-security, her time at Techstars, and the startup community in Austin.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+DE3EXiNl + + ]]> + + + + 323: Mission Focused (Kristy Wallace) + https://podcast.thoughtbot.com/323 + 5cd92436-05fd-4b3f-a3a5-03f02f0d59a1 + Mon, 10 Jun 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Kristy Wallace, CEO of Ellevate Network, discusses cross-industry community building, utilizing tech to facilitate connections, scaling without losing personal impact, and becoming a certified B Corp. + 39:02 + no + + <p>Kristy Wallace, CEO of Ellevate Network, discusses cross-industry community building, utilizing tech to facilitate connections, scaling without losing personal impact, and becoming a certified B Corp.</p> +<ul> +<li><a href="https://www.ellevatenetwork.com/">Ellevate Network</a></li> +<li><a href="https://amzn.to/2EPLx4R"><em>The Five Love Languages</em></a>: Gary Chapman</li> +<li><a href="http://pipelineangels.com/">Pipeline Angels</a></li> +<li><a href="https://en.wikipedia.org/wiki/B_Corporation_(certification)">B Corporation</a></li> +<li><a href="https://app.bimpactassessment.net/login">B Impact Assessment</a></li> +<li><a href="https://www.ellevatenetwork.com/podcasts">Ellevate Podcast:</a> Conversations With Women Changing the Face of Business</li> +<li><a href="https://twitter.com/kristyawallace">Kristy on Twitter</a></li> +<li><a href="https://www.linkedin.com/in/kristysiskowallace/">Kristy on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Kristy Wallace, CEO of Ellevate Network, discusses cross-industry community building, utilizing tech to facilitate connections, scaling without losing personal impact, and becoming a certified B Corp.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Kristy Wallace, CEO of Ellevate Network, discusses cross-industry community building, utilizing tech to facilitate connections, scaling without losing personal impact, and becoming a certified B Corp.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+BmUUABbL + + ]]> + + + + 322: Measure Equity (Paloma Medina) + https://podcast.thoughtbot.com/322 + 6f47b664-c62c-4ac7-9c83-bb1153336eed + Tue, 28 May 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Paloma Medina, performance coach, trainer, and owner of 11:11 Supply, discusses translating her brick & mortar store experience to an online shop, the themes around her coaching, design thinking, and how equity is linked to our long-term physical health. + 43:01 + no + + <p>Paloma Medina, performance coach, trainer, and owner of 11:11 Supply, discusses translating her brick &amp; mortar store experience to an online shop, the themes around her coaching, design thinking, and how equity is linked to our long-term physical health.</p> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://www.1111supply.com/">11:11 Supply</a></li> +<li><a href="https://cwpencils.com/">CW Pencil Enterprise</a></li> +<li><a href="https://youtu.be/sZu7N3LAbUM?t=2597">Paloma @ TEDx Portland</a></li> +<li><a href="https://www.linkedin.com/in/paloma-medina-241b7727/">Paloma on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Paloma Medina, performance coach, trainer, and owner of 11:11 Supply, discusses translating her brick & mortar store experience to an online shop, the themes around her coaching, design thinking, and how equity is linked to our long-term physical health.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Paloma Medina, performance coach, trainer, and owner of 11:11 Supply, discusses translating her brick & mortar store experience to an online shop, the themes around her coaching, design thinking, and how equity is linked to our long-term physical health.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+OWb0dL1T + + ]]> + + + + 321: Building a Marketplace (Stefania Mallett) + https://podcast.thoughtbot.com/321 + 2b2e0928-9566-4359-bcb6-60ca239ddcc0 + Mon, 20 May 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Stefania Mallett, CEO and co-founder of ezCater, discusses non-compete agreements, maintaining an entrepreneurial spirit, codifying values, advice on building a marketplace, and the nuances of expanding globally. + 46:17 + no + + <p>Stefania Mallett, CEO and co-founder of ezCater, discusses non-compete agreements, maintaining an entrepreneurial spirit, codifying values, advice on building a marketplace, and the nuances of expanding globally.</p> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://www.ezcater.com/">ezCater</a></li> +<li><a href="https://www.fool.com/knowledge-center/ebitda.aspx">EBITDA</a></li> +<li><a href="https://www.caterup2019.com/">CaterUp! Conference</a></li> +<li><a href="https://www.linkedin.com/in/stefania-mallett/">Stefania on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Stefania Mallett, CEO and co-founder of ezCater, discusses non-compete agreements, maintaining an entrepreneurial spirit, codifying values, advice on building a marketplace, and the nuances of expanding globally.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Stefania Mallett, CEO and co-founder of ezCater, discusses non-compete agreements, maintaining an entrepreneurial spirit, codifying values, advice on building a marketplace, and the nuances of expanding globally.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+NMYnbJPq + + ]]> + + + + 320: Lead Through Collaboration (Harold Hughes) + https://podcast.thoughtbot.com/320 + daddac05-18e8-4e10-95f5-8797d2b110c5 + Mon, 13 May 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Harold Hughes, Founder & CEO of Bandwagon, discusses utilizing blockchain for security and personalization in event ticketing, data-transparency, his key to entrepreneurship, the importance of investment firms funding underrepresented groups, and speaking to the SEC. + 43:55 + no + + <p>Harold Hughes, Founder &amp; CEO of Bandwagon, discusses utilizing blockchain for security and personalization in event ticketing, data-transparency, his key to entrepreneurship, the importance of investment firms funding underrepresented groups, and speaking to the SEC.</p> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://bandwagonfanclub.com/">Bandwagon</a></li> +<li><a href="https://www.facebook.com/business/help/742478679120153">Facebook Pixel</a></li> +<li><a href="https://fi.co/">Founder Institute Accelerator</a></li> +<li><a href="https://en.wikipedia.org/wiki/PayPal_Mafia">PayPal Mafia</a></li> +<li><a href="http://money.com/money/5454728/arlan-hamilton-backstage-capital/">Arlan Hamilton - Backstage Capital Story</a></li> +<li><a href="https://backstagecapital.com/">Backstage Capital</a></li> +<li><a href="https://en.wikipedia.org/wiki/Small_Business_Week">Small Business Week</a></li> +<li><a href="https://en.wikipedia.org/wiki/Jumpstart_Our_Business_Startups_Act">JOBS Act</a></li> +<li><a href="https://www.experienceaura.io/">Aura</a></li> +<li><a href="https://twitter.com/OneBandwagonFan">Harold on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Harold Hughes, Founder & CEO of Bandwagon, discusses utilizing blockchain for security and personalization in event ticketing, data-transparency, his key to entrepreneurship, the importance of investment firms funding underrepresented groups, and speaking to the SEC.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Harold Hughes, Founder & CEO of Bandwagon, discusses utilizing blockchain for security and personalization in event ticketing, data-transparency, his key to entrepreneurship, the importance of investment firms funding underrepresented groups, and speaking to the SEC.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+KBBpvCjk + + ]]> + + + + 319: Beyond Purpose (Bruce Daisley) + https://podcast.thoughtbot.com/319 + 1befd422-c631-4c1d-ad5e-9561cc5e3fbd + Tue, 07 May 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Bruce Daisley, VP EMEA at Twitter, discusses the international focus of Twitter, the importance of psychological-safety on workplace culture, diversity & striving for fulfillment for all workers, and fleeting happiness vs enduring purpose. + 39:33 + no + + <p>Bruce Daisley, VP EMEA at Twitter, discusses the international focus of Twitter, the importance of psychological-safety on workplace culture, diversity &amp; striving for fulfillment for all workers, and fleeting happiness vs enduring purpose.</p> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://twitter.com/">Twitter</a></li> +<li><a href="https://eatsleepworkrepeat.fm/">Eat Sleep Work Repeat Podcast</a></li> +<li><a href="https://jobs.netflix.com/culture">Netflix Culture Statement</a></li> +<li><a href="https://www.slideshare.net/reed2001/culture-1798664">Previous Netflix Culture Deck</a></li> +<li><a href="https://en.wikipedia.org/wiki/Psychological_safety">Psychological Safety</a></li> +<li><a href="https://en.wikipedia.org/wiki/Crew_resource_management">Crew Resource Management</a></li> +<li>Fraternity Experiment: <a href="https://journals.sagepub.com/doi/abs/10.1177/0146167208328062">&quot;The Advantages and Liabilities of Agreeing With Socially Distinct Newcomers&quot;</a></li> +<li><a href="https://www.newscientist.com/article/mg14519661-200-a-spoonful-of-sugar-helps-the-doctor-feel-good/">&quot;Positive Affect&quot; in Doctors Study</a></li> +<li><a href="https://en.wikipedia.org/wiki/Blue_Monday_(date)">Blue Monday</a></li> +<li><a href="https://amzn.to/2H43XQZ"><em>The Joy of Work</em></a>- Bruce Daisley</li> +<li><a href="https://www.buzzfeednews.com/article/annehelenpetersen/millennials-burnout-generation-debt-work">&quot;How Millennials Became The Burnout Generation&quot;</a></li> +<li><a href="https://twitter.com/brucedaisley">Bruce on Twitter</a></li> +<li><a href="https://www.linkedin.com/in/brucedaisley/">Bruce on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Bruce Daisley, VP EMEA at Twitter, discusses the international focus of Twitter, the importance of psychological-safety on workplace culture, diversity & striving for fulfillment for all workers, and fleeting happiness vs enduring purpose.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Bruce Daisley, VP EMEA at Twitter, discusses the international focus of Twitter, the importance of psychological-safety on workplace culture, diversity & striving for fulfillment for all workers, and fleeting happiness vs enduring purpose.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+S4fRq-38 + + ]]> + + + + 318: Scaling With People (Chris Sullens) + https://podcast.thoughtbot.com/318 + c2d16f9b-8864-4eb0-b83e-820c6d25e0ee + Mon, 29 Apr 2019 00:00:00 -0400 + thoughtbot + + full + 8 + thoughtbot + Chris Sullens, CEO of CentralReach, discusses needing to be cognizant of company culture while introducing new systems and a management team, the difficult task of hiring for culture, and how technology can help shape the future of ABA therapy. + 39:35 + no + + <p>Chris Sullens, CEO of CentralReach, discusses needing to be cognizant of company culture while introducing new systems and a management team, the difficult task of hiring for culture, and how technology can help shape the future of ABA therapy.</p> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://centralreach.com/">CentralReach</a></li> +<li><a href="https://www.calipercorp.com/">Caliper Assessment</a></li> +<li><a href="https://twitter.com/ChrisSullens">Chris on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chris Sullens, CEO of CentralReach, discusses needing to be cognizant of company culture while introducing new systems and a management team, the difficult task of hiring for culture, and how technology can help shape the future of ABA therapy.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris Sullens, CEO of CentralReach, discusses needing to be cognizant of company culture while introducing new systems and a management team, the difficult task of hiring for culture, and how technology can help shape the future of ABA therapy.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+L8MCZymN + + ]]> + + + + 317: About Fulfillment (Ben Furber) + https://podcast.thoughtbot.com/317 + a76bab84-c076-46da-98e6-ea52ac0ed4b8 + Tue, 23 Apr 2019 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Ben Furber, Developer at thoughtbot London, presents a panel discussion around striving for professional fulfillment, as individuals, managers, and organizations. + 1:11:13 + no + + <p>Ben Furber, Developer at thoughtbot London, presents a panel discussion around striving for professional fulfillment, as individuals, managers, and organizations.</p> +<p>The panelists touch on bringing your authentic self to work, finding organizations with value alignment, an environment where you're able to make mistakes, 'process' vs trust, rethinking retros, giving appreciative feedback, and honest conversations.</p> +<ul> +<li><a href="https://twitter.com/ThisIsJoFrank">Jo Franchetti</a> - Web Developer Advocate for Samsung Internet</li> +<li><a href="https://github.com/benfurber">Ben Furber</a> - Developer and consultant for thoughtbot</li> +<li><a href="https://twitter.com/mnky">Melody King</a> - Product Owner for Ieso Digital Health</li> +<li><a href="https://www.linkedin.com/in/kay-lack-71834311a/">Kay Lack</a> - Director of Academy at Makers</li> +<li><a href="https://twitter.com/_i_Singh">Itti Singh</a> - Frontend Developer for Ieso Digital Health</li> +</ul> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://www.eventbrite.co.uk/e/the-fulfilled-developer-tickets-56398030026#">The Fulfilled Developer</a>- Event Details</li> +<li><a href="https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs">Maslow's Hierarchy of Needs</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Ben Furber, Developer at thoughtbot London, presents a panel discussion around striving for professional fulfillment, as individuals, managers, and organizations.

+ +

The panelists touch on bringing your authentic self to work, finding organizations with value alignment, an environment where you're able to make mistakes, 'process' vs trust, rethinking retros, giving appreciative feedback, and honest conversations.

+ +
    +
  • Jo Franchetti - Web Developer Advocate for Samsung Internet
    • +
  • Ben Furber - Developer and consultant for thoughtbot
    • +
  • Melody King - Product Owner for Ieso Digital Health
    • +
  • Kay Lack - Director of Academy at Makers
    • +
  • Itti Singh - Frontend Developer for Ieso Digital Health
    • +
+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Furber, Developer at thoughtbot London, presents a panel discussion around striving for professional fulfillment, as individuals, managers, and organizations.

+ +

The panelists touch on bringing your authentic self to work, finding organizations with value alignment, an environment where you're able to make mistakes, 'process' vs trust, rethinking retros, giving appreciative feedback, and honest conversations.

+ +
    +
  • Jo Franchetti - Web Developer Advocate for Samsung Internet
    • +
  • Ben Furber - Developer and consultant for thoughtbot
    • +
  • Melody King - Product Owner for Ieso Digital Health
    • +
  • Kay Lack - Director of Academy at Makers
    • +
  • Itti Singh - Frontend Developer for Ieso Digital Health
    • +
+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cCeRnHfl + + ]]> + + + + 316: A Completely Orthogonal Skillset (Lara Hogan) + https://podcast.thoughtbot.com/316 + 1612e65d-9518-4539-9825-ee0cfeb2dc8a + Mon, 15 Apr 2019 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Lara Hogan, co-founder of Wherewithall, discusses finding her ideal job coaching and mentoring, evaluating for management alignment, what makes for a strong manager, the value of role-play, constructive feedback, and her upcoming book, "Resilient Management". + 40:42 + no + + <p>Lara Hogan, co-founder of Wherewithall, discusses finding her ideal job coaching and mentoring, evaluating for management alignment, what makes for a strong manager, the value of role-play, constructive feedback, and her upcoming book, <em>Resilient Management</em>.</p> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://wherewithall.com/">Wherewithall</a></li> +<li><a href="https://journals.sagepub.com/doi/10.1177/0956797612458937">Not Lack of Ability but More Choice: Individual and Gender Differences in Choice of Careers in Science, Technology, Engineering, and Mathematics</a></li> +<li><a href="https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/">&quot;On Being A Senior Engineer&quot;</a>- John Allspaw</li> +<li><a href="https://resilient-management.com/"><em>Resilient Management</em></a></li> +<li><a href="https://en.wikipedia.org/wiki/Voltron">Voltron</a></li> +<li><a href="https://twitter.com/lara_hogan">Lara on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Lara Hogan, co-founder of Wherewithall, discusses finding her ideal job coaching and mentoring, evaluating for management alignment, what makes for a strong manager, the value of role-play, constructive feedback, and her upcoming book, Resilient Management.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lara Hogan, co-founder of Wherewithall, discusses finding her ideal job coaching and mentoring, evaluating for management alignment, what makes for a strong manager, the value of role-play, constructive feedback, and her upcoming book, Resilient Management.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+CCddiD-O + + ]]> + + + + 315: I'm Not a CPA, I Just Play One On Podcasts (Scott Orn) + https://podcast.thoughtbot.com/315 + 16e32bcd-8f99-43f4-843b-322b6a7c8bc1 + Mon, 08 Apr 2019 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Scott Orn, COO of Kruze Consulting, talks about podcasting, early stage pain-points, favorite tools, the trade-offs of remote work, and last minute tax-day advice for startups. + 42:40 + no + + <p>Scott Orn, COO of Kruze Consulting, talks about podcasting, early stage pain-points, favorite tools, the trade-offs of remote work, and last minute tax-day advice for startups.</p> +<p>This episode of Giant Robots is sponsored by:<br /> +<a href="https://www.pricingwire.com/">PricingWire</a>: Monetization &amp; Pricing Strategy for Software &amp; Technology Innovators</p> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://kruzeconsulting.com/">Kruze Consulting</a></li> +<li><a href="http://giantrobots.fm/43">Scott on <em>Giant Robots</em> #43</a></li> +<li><a href="https://kruzeconsulting.com/founders_and_friends/"><em>Founders &amp; Friends</em> Podcast</a></li> +<li><a href="http://www.bensfriends.org/">Ben's Friends</a></li> +<li><a href="https://thoughtbot.com/playbook">thoughtbot Playbook</a></li> +<li><a href="https://liquidspace.com/us/ca/san-francisco/thoughtbot/dedicated-desk-1">Come work from our San Francisco Office!</a></li> +<li><a href="https://kruzeconsulting.com/startup-taxes/">Kruze Startup Tax Returns</a></li> +<li><a href="https://twitter.com/scottorn">Scott on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Scott Orn, COO of Kruze Consulting, talks about podcasting, early stage pain-points, favorite tools, the trade-offs of remote work, and last minute tax-day advice for startups.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Scott Orn, COO of Kruze Consulting, talks about podcasting, early stage pain-points, favorite tools, the trade-offs of remote work, and last minute tax-day advice for startups.

+ +

This episode of Giant Robots is sponsored by:
+PricingWire: Monetization & Pricing Strategy for Software & Technology Innovators

+ +

Links & Show Notes

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Bi7JTpov + + ]]> + + + + 314: Streamlined and Thoughtful (Chelsea Moore) + https://podcast.thoughtbot.com/314 + fe948c81-5d08-41ca-bc6e-5fc813c77f2e + Mon, 01 Apr 2019 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chelsea Moore, co-founder & CEO of BoxFox, discusses quickly going from idea to launch while doing everything from design to fulfillment in-house, their approach to growth, learning to say 'no', letting branding & social media evolve from itself, and reinforcing the human side of e-commerce. + 36:43 + no + + <p>Chelsea Moore, co-founder &amp; CEO of BoxFox, discusses quickly going from idea to launch while doing everything from design to fulfillment in-house, their approach to growth, learning to say 'no', letting branding &amp; social media evolve from itself, and reinforcing the human side of e-commerce.</p> +<ul> +<li><a href="https://shopboxfox.com/">BOXFOX</a></li> +<li><a href="https://twitter.com/_chelsmoore">Chelsea on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chelsea Moore, co-founder & CEO of BoxFox, discusses quickly going from idea to launch while doing everything from design to fulfillment in-house, their approach to growth, learning to say 'no', letting branding & social media evolve from itself, and reinforcing the human side of e-commerce.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chelsea Moore, co-founder & CEO of BoxFox, discusses quickly going from idea to launch while doing everything from design to fulfillment in-house, their approach to growth, learning to say 'no', letting branding & social media evolve from itself, and reinforcing the human side of e-commerce.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+eDgj--of + + ]]> + + + + 313: I Just Want to Get There (Art Papas) + https://podcast.thoughtbot.com/313 + 57e08f71-8ce5-411a-a232-70928f561b23 + Mon, 25 Mar 2019 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Art Papas, CEO of Bullhorn, discusses the business of temporary staffing, the danger of doing a marketing push before finding product market fit, focusing early on culture, adjusting to his role as CEO, communication techniques for company-wide messaging, and having enthusiasm for the future. + 31:02 + no + + <p>Art Papas, CEO of Bullhorn, discusses the business of temporary staffing, the danger of doing a marketing push before finding product market fit, focusing early on culture, adjusting to his role as CEO, communication techniques for company-wide messaging, and having enthusiasm for the future.</p> +<ul> +<li><a href="https://www.bullhorn.com/">Bullhorn</a></li> +<li><a href="https://amzn.to/2Okg3ay"><em>Winning</em></a>- Jack Welch</li> +<li><a href="https://amzn.to/2CvMy0S"><em>The Innovator's Dilemma</em></a>- Clayton Christensen</li> +<li><a href="https://twitter.com/artpapas">Art on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Art Papas, CEO of Bullhorn, discusses the business of temporary staffing, the danger of doing a marketing push before finding product market fit, focusing early on culture, adjusting to his role as CEO, communication techniques for company-wide messaging, and having enthusiasm for the future.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Art Papas, CEO of Bullhorn, discusses the business of temporary staffing, the danger of doing a marketing push before finding product market fit, focusing early on culture, adjusting to his role as CEO, communication techniques for company-wide messaging, and having enthusiasm for the future.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mQIJygvl + + ]]> + + + + 312: Seeking Strengths (Gareth Burrowes) + https://podcast.thoughtbot.com/312 + 2afc812b-cb65-4cf3-bfd8-77c2793811ab + Mon, 18 Mar 2019 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Gareth Burrowes, Co-Founder & Head of Product and Marketing at The Tech Connection, discusses employment screening focused on candidate strengths, removing unconscious bias from the hiring flow, and the importance of diversity at every level of a company. + 38:52 + no + + <p>Gareth Burrowes, Co-Founder &amp; Head of Product and Marketing at The Tech Connection, discusses employment screening focused on candidate strengths, removing unconscious bias from the hiring flow, and the importance of diversity at every level of a company.</p> +<ul> +<li><a href="https://thetechconnectioninc.com/">The Tech Connection</a></li> +<li><a href="https://twitter.com/GarethBurrowes">Gareth on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Gareth Burrowes, Co-Founder & Head of Product and Marketing at The Tech Connection, discusses employment screening focused on candidate strengths, removing unconscious bias from the hiring flow, and the importance of diversity at every level of a company.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Gareth Burrowes, Co-Founder & Head of Product and Marketing at The Tech Connection, discusses employment screening focused on candidate strengths, removing unconscious bias from the hiring flow, and the importance of diversity at every level of a company.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+O2ydcbo7 + + ]]> + + + + 311: Serving Serverless (Erica Windisch) + https://podcast.thoughtbot.com/311 + 2ec0d2e8-ff44-4e93-b7a8-ad0b884a6ddd + Mon, 11 Mar 2019 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Erica Windisch, CTO and co-founder of IOpipe, discusses serverless architecture and how it can provide a clearer user-interaction story, the state of automatic code generation, and her experience in Techstars. + 39:03 + no + + <p>Erica Windisch, CTO and co-founder of IOpipe, discusses serverless architecture and how it can provide a clearer user-interaction story, the state of automatic code generation, and her experience in Techstars.</p> +<ul> +<li><a href="https://www.iopipe.com/">IOpipe</a></li> +<li><a href="https://www.techstars.com/content/accelerators/nyc/meet-15-startups-techstars-nyc-summer-2016-program/">Techstars NYC 2016</a></li> +<li><a href="https://blog.gardeviance.org/2015/02/an-introduction-to-wardley-value-chain.html">An introduction to Wardley (Value Chain) Mapping</a></li> +<li><a href="https://iopipe.now.sh/">IOpipe Community on Slack</a></li> +<li><a href="https://twitter.com/ewindisch">Erica on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Erica Windisch, CTO and co-founder of IOpipe, discusses serverless architecture and how it can provide a clearer user-interaction story, the state of automatic code generation, and her experience in Techstars.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Erica Windisch, CTO and co-founder of IOpipe, discusses serverless architecture and how it can provide a clearer user-interaction story, the state of automatic code generation, and her experience in Techstars.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+IxZESUL8 + + ]]> + + + + 310: Have a Slide For That (Alec Stern) + https://podcast.thoughtbot.com/310 + b2aa39d2-75f8-48f9-b3b7-83fe8de977b2 + Mon, 04 Mar 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Alec Stern, startup founder, entrepreneur, mentor, investor, and advisor, discusses founding Constant Contact, the early days of SaaS, the importance and utilization of 'channels', and pursuing customer feedback. + 42:31 + no + + <p>Alec Stern, startup founder, entrepreneur, mentor, investor, and advisor, discusses founding Constant Contact, the early days of SaaS, the importance and utilization of 'channels', and pursuing customer feedback.</p> +<ul> +<li><a href="https://www.constantcontact.com/">Constant Contact</a></li> +<li><a href="https://point2pointglobal.com/">Point2Point Global</a></li> +<li><a href="https://twitter.com/AlecStern">Alec on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Alec Stern, startup founder, entrepreneur, mentor, investor, and advisor, discusses founding Constant Contact, the early days of SaaS, the importance and utilization of 'channels', and pursuing customer feedback.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Alec Stern, startup founder, entrepreneur, mentor, investor, and advisor, discusses founding Constant Contact, the early days of SaaS, the importance and utilization of 'channels', and pursuing customer feedback.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tLkCEzkA + + ]]> + + + + 309: Slow is Smooth, Smooth is Fast (Jamie Howard) + https://podcast.thoughtbot.com/309 + cfe3c1f4-01df-48de-8d8b-5e85b5939b3a + Mon, 25 Feb 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Jamie Howard, Director of Engineering at TransLoc, discusses hiring, solutions-driven engineering, leadership in the military vs the private sector, and Agile methodology. + 27:53 + no + + <p>Jamie Howard, Director of Engineering at TransLoc, discusses hiring, solutions-driven engineering, leadership in the military vs the private sector, and Agile methodology.</p> +<ul> +<li><a href="https://transloc.com/">TransLoc</a></li> +<li><a href="https://www.mbta.com/accessibility/the-ride">The Ride</a></li> +<li><a href="https://vimeo.com/85490944">Spotify Engineering Culture</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jamie Howard, Director of Engineering at TransLoc, discusses hiring, solutions-driven engineering, leadership in the military vs the private sector, and Agile methodology.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jamie Howard, Director of Engineering at TransLoc, discusses hiring, solutions-driven engineering, leadership in the military vs the private sector, and Agile methodology.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+eFGDIxgN + + ]]> + + + + 308: Technology is Everywhere (Siobhan Green) + https://podcast.thoughtbot.com/308 + f3512b26-135c-4371-bc54-63cd557782c1 + Mon, 18 Feb 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Siobhan Green, co-founder & CEO of Sonjara, discusses finding good tech solutions for organizations in the social-benefit space and developing countries, merging her passions for tech and international development, GDPR, and the ethics and security of various technological solutions. + 35:25 + no + + <p>Siobhan Green, co-founder &amp; CEO of Sonjara, discusses finding good tech solutions for organizations in the social-benefit space and developing countries, merging her passions for tech and international development, GDPR, and the ethics and security of various technological solutions.</p> +<ul> +<li><a href="http://www.sonjara.com/">Sonjara</a></li> +<li><a href="https://en.wikipedia.org/wiki/Information_and_communication_technologies_for_development">ICT4D</a></li> +<li><a href="http://www.sonjara.com/blog?article_id=161">The Ethics of Data Workshop</a></li> +<li><a href="https://twitter.com/siobhangreen">Siobhan on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Siobhan Green, co-founder & CEO of Sonjara, discusses finding good tech solutions for organizations in the social-benefit space and developing countries, merging her passions for tech and international development, GDPR, and the ethics and security of various technological solutions.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Siobhan Green, co-founder & CEO of Sonjara, discusses finding good tech solutions for organizations in the social-benefit space and developing countries, merging her passions for tech and international development, GDPR, and the ethics and security of various technological solutions.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+z8ITgRfu + + ]]> + + + + 307: Win in the Long Term (Mike McDerment) + https://podcast.thoughtbot.com/307 + 08407036-61c7-4647-822f-8b391c421aad + Mon, 11 Feb 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Mike McDerment, co-founder and CEO of FreshBooks, discusses reimagining the platform with a system-wide A-B test, experiences with scaling, the value of customer service, and the art/science of change. + 34:40 + no + + <p>Mike McDerment, co-founder and CEO of FreshBooks, discusses reimagining the platform with a system-wide A-B test, experiences with scaling, the value of customer service, and the art/science of change.</p> +<ul> +<li><a href="https://www.freshbooks.com/">FreshBooks</a></li> +<li><a href="https://twitter.com/MikeMcDerment">Mike on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Mike McDerment, co-founder and CEO of FreshBooks, discusses reimagining the platform with a system-wide A-B test, experiences with scaling, the value of customer service, and the art/science of change.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Mike McDerment, co-founder and CEO of FreshBooks, discusses reimagining the platform with a system-wide A-B test, experiences with scaling, the value of customer service, and the art/science of change.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GD-ZHHWQ + + ]]> + + + + 306: 306: Solving a Specific Problem (Ellen Chisa) + https://podcast.thoughtbot.com/306 + 00fe5f15-0f5a-4a3a-ae40-0a4a17572e4a + Mon, 04 Feb 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Ellen Chisa, CEO and cofounder of Dark, discusses building a complete programming platform from scratch, the benefits of a private beta, and making programming more accessible. + 26:45 + no + + <p>Ellen Chisa, CEO and cofounder of Dark, discusses building a complete programming platform from scratch, the benefits of a private beta, and making programming more accessible.</p> +<ul> +<li><a href="https://darklang.com/">Dark</a></li> +<li><a href="https://medium.com/darklang/philip2-an-elm-to-reasonml-compiler-a210aaa6cd04">Philip2</a></li> +<li><a href="https://twitter.com/ellenchisa">Ellen on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Ellen Chisa, CEO and cofounder of Dark, discusses building a complete programming platform from scratch, the benefits of a private beta, and making programming more accessible.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ellen Chisa, CEO and cofounder of Dark, discusses building a complete programming platform from scratch, the benefits of a private beta, and making programming more accessible.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tj8EUNSK + + ]]> + + + + 305: You're Never Done (Ben McRedmond) + https://podcast.thoughtbot.com/305 + 72f28ffa-321d-4d94-af4e-f40aa785d737 + Mon, 28 Jan 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Ben McRedmond, CEO of Consider, discusses his time as Senior Director of Growth at Intercom, teases his plans for fixing email, and discusses the importance & difficulty of product validation. + 28:48 + no + + <p>Ben McRedmond, CEO of Consider, discusses his time as Senior Director of Growth at Intercom, teases his plans for fixing email, and discusses the importance &amp; difficulty of product validation.</p> +<ul> +<li><a href="https://consider.co/">Consider</a></li> +<li><a href="https://twitter.com/benmcredmond">Ben on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Ben McRedmond, CEO of Consider, discusses his time as Senior Director of Growth at Intercom, teases his plans for fixing email, and discusses the importance & difficulty of product validation.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben McRedmond, CEO of Consider, discusses his time as Senior Director of Growth at Intercom, teases his plans for fixing email, and discusses the importance & difficulty of product validation.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Odjinxlm + + ]]> + + + + 304: Intentional Soul-Searching (Natalie Nagele) + https://podcast.thoughtbot.com/304 + 3c519ddf-77d1-4cde-ac8f-e8aeab117d4e + Mon, 21 Jan 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Natalie Nagele, Co-founder and CEO of Wildbit, discusses product updates, operating with more meaning and purpose, user research, bootstrap vs VC funding, and experiments in productivity (like a 4-day work week, turning off Slack, and strategies for remote work). + 46:05 + no + + <p>Natalie Nagele, Co-founder and CEO of Wildbit, discusses product updates, operating with more meaning and purpose, user research, bootstrap vs VC funding, and experiments in productivity (like a 4-day work week, turning off Slack, and strategies for remote work).</p> +<ul> +<li><a href="https://wildbit.com/">Wildbit</a></li> +<li><a href="http://giantrobots.fm/62">Natalie on <em>Giant Robots</em> Ep #66</a></li> +<li><a href="https://www.conveyor.com/">Conveyor</a></li> +<li><a href="https://amzn.to/2RFNpVx"><em>Deep Work</em></a>- Cal Newport</li> +<li><a href="https://twitter.com/natalienagele">Natalie on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Natalie Nagele, Co-founder and CEO of Wildbit, discusses product updates, operating with more meaning and purpose, user research, bootstrap vs VC funding, and experiments in productivity (like a 4-day work week, turning off Slack, and strategies for remote work).

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Natalie Nagele, Co-founder and CEO of Wildbit, discusses product updates, operating with more meaning and purpose, user research, bootstrap vs VC funding, and experiments in productivity (like a 4-day work week, turning off Slack, and strategies for remote work).

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+5m1cWtRJ + + ]]> + + + + 303: Building Something Special (Margaret McKenna) + https://podcast.thoughtbot.com/303 + bd240745-9b41-4224-9322-7135ef5be9d7 + Mon, 14 Jan 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Margaret McKenna, Software Engineer at Devoted Health, discusses joining a team based on their mission, building systems from scratch, and evolution on a new, rapidly growing team. + 28:32 + no + + <p>Margaret McKenna, Software Engineer at Devoted Health, discusses joining a team based on their mission, building systems from scratch, and evolution on a new, rapidly growing team.</p> +<ul> +<li><a href="https://www.devoted.com/">Devoted Health</a></li> +<li><a href="http://giantrobots.fm/298">DJ Patil on <em>Giant Robots</em></a></li> +<li><a href="https://twitter.com/margaretlmck">Margaret on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Margaret McKenna, Software Engineer at Devoted Health, discusses joining a team based on their mission, building systems from scratch, and evolution on a new, rapidly growing team.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Margaret McKenna, Software Engineer at Devoted Health, discusses joining a team based on their mission, building systems from scratch, and evolution on a new, rapidly growing team.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+eyABBPSD + + ]]> + + + + 302: What Stage Are We In? (Sam Clemens) + https://podcast.thoughtbot.com/302 + eb7259aa-c3a4-49f5-8ff2-7483fb4576d2 + Mon, 07 Jan 2019 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Sam Clemens, Partner at Accomplice VC, discusses utilizing his product experience to nurture new companies, advice for where businesses should focus in various stages of growth, what should really be in an MVP, and his feelings around leaving a company as it's founder. + 40:50 + no + + <p>Sam Clemens, Partner at Accomplice VC, discusses utilizing his product experience to nurture new companies, advice for where businesses should focus in various stages of growth, what should really be in an MVP, and his feelings around leaving a company as it's founder.</p> +<ul> +<li><a href="https://accomplice.co/">Accomplice VC</a></li> +<li><a href="https://www.linkedin.com/in/sclemens/">Sam on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Sam Clemens, Partner at Accomplice VC, discusses utilizing his product experience to nurture new companies, advice for where businesses should focus in various stages of growth, what should really be in an MVP, and his feelings around leaving a company as it's founder.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sam Clemens, Partner at Accomplice VC, discusses utilizing his product experience to nurture new companies, advice for where businesses should focus in various stages of growth, what should really be in an MVP, and his feelings around leaving a company as it's founder.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0hZCJxv8 + + ]]> + + + + 301: Projection & Prediction (Aatish Salvi) + https://podcast.thoughtbot.com/301 + 746f08ad-b88b-4a5d-91ed-94c192d55bcd + Mon, 10 Dec 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Aatish Salvi, CTO of Teikametrics, discusses building a service for 3rd party Amazon sellers using data science, being wary of pre-mature optimization, integrating data engineering research into the team, and working with Amazon as both a partner and a competitor. + 39:59 + no + + <p>Aatish Salvi, CTO of Teikametrics, discusses building a service for 3rd party Amazon sellers using data science, being wary of pre-mature optimization, integrating data engineering research into the team, and working with Amazon as both a partner and a competitor.</p> +<ul> +<li><a href="https://www.teikametrics.com/">Teikametrics</a></li> +<li><a href="https://www.linkedin.com/in/aatishsalvi/">Aatish on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + Special Guest: Teikametrics. + + + Aatish Salvi, CTO of Teikametrics, discusses building a service for 3rd party Amazon sellers using data science, being wary of pre-mature optimization, integrating data engineering research into the team, and working with Amazon as both a partner and a competitor.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Aatish Salvi, CTO of Teikametrics, discusses building a service for 3rd party Amazon sellers using data science, being wary of pre-mature optimization, integrating data engineering research into the team, and working with Amazon as both a partner and a competitor.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Special Guest: Teikametrics.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jQg4bN7V + + ]]> + + Teikametrics + + + 300: More Useable Information (Jennifer Lum) + https://podcast.thoughtbot.com/300 + 38b016e1-4b77-44ce-9c60-a3549cc90a48 + Mon, 03 Dec 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Jennifer Lum, COO and co-founder of Forge.ai, discusses building a company and platform that transforms unstructured information into machine-readable data in real-time, avoiding biases in data collection, and evolving & defining company values as one's team grows. + 30:56 + no + + <p>Jennifer Lum, COO and co-founder of Forge.ai, discusses building a company and platform that transforms unstructured information into machine-readable data in real-time, avoiding biases in data collection, and evolving &amp; defining company values as one's team grows.</p> +<ul> +<li><a href="https://www.forge.ai/">Forge</a></li> +<li><a href="https://twitter.com/lum">Jennifer on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jennifer Lum, COO and co-founder of Forge.ai, discusses building a company and platform that transforms unstructured information into machine-readable data in real-time, avoiding biases in data collection, and evolving & defining company values as one's team grows.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jennifer Lum, COO and co-founder of Forge.ai, discusses building a company and platform that transforms unstructured information into machine-readable data in real-time, avoiding biases in data collection, and evolving & defining company values as one's team grows.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MOuaVJ9Z + + ]]> + + + + 299: High-Touch (Millie Blackwell) + https://podcast.thoughtbot.com/299 + 45e698f4-5430-4358-96fe-e3f31f8ab58b + Mon, 26 Nov 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Millie Blackwell, President & Co-founder of Showcase Workshop, discusses differences in business culture between California and New Zealand, pursuing tablets as a business tool early in the lifespan of the iPad, experimenting with SaaS pricing, and providing value to both enterprise buyers and end-users. + 36:42 + no + + <p>Millie Blackwell, President &amp; Co-founder of Showcase Workshop, discusses differences in business culture between California and New Zealand, pursuing tablets as a business tool early in the lifespan of the iPad, experimenting with SaaS pricing, and providing value to both enterprise buyers and end-users.</p> +<ul> +<li><a href="https://showcaseworkshop.com/giant-robots-smashing-into-other-giant-robots/">Showcase Workshop</a></li> +<li><a href="https://showcaseworkshop.com/releaf-fund/">Showcase Forest Releaf Fund</a></li> +<li><a href="https://www.linkedin.com/in/millie-blackwell-ba824144/">Millie on LinkedIn</a></li> +</ul> + + + + Millie Blackwell, President & Co-founder of Showcase Workshop, discusses differences in business culture between California and New Zealand, pursuing tablets as a business tool early in the lifespan of the iPad, experimenting with SaaS pricing, and providing value to both enterprise buyers and end-users.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Millie Blackwell, President & Co-founder of Showcase Workshop, discusses differences in business culture between California and New Zealand, pursuing tablets as a business tool early in the lifespan of the iPad, experimenting with SaaS pricing, and providing value to both enterprise buyers and end-users.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+16RnysHJ + + ]]> + + + + 298: Doing Right is Scalable (DJ Patil) + https://podcast.thoughtbot.com/298 + 73467b1c-804f-42ab-b6ab-65ac42eb3ba8 + Thu, 15 Nov 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + DJ Patil, Head of Technology at Devoted Health, discusses his time as the U.S. Chief Data Scientist, scaling healthcare to meet modern data demands, and the process of architecting a health care company. + 47:10 + no + + <p>DJ Patil, Head of Technology at Devoted Health, discusses his time as the U.S. Chief Data Scientist, scaling healthcare to meet modern data demands, and the process of architecting a health care company.</p> +<ul> +<li><a href="https://www.devoted.com/">Devoted Health</a></li> +<li><a href="https://www.data.gov/">U.S. Government’s open data</a></li> +<li><a href="https://amzn.to/2qE6qsA"><em>The Fifth Risk</em></a>- Michael Lewis</li> +<li><a href="http://paulgraham.com/ds.html">&quot;Do Things That Don't Scale&quot;</a></li> +<li><a href="https://twitter.com/dpatil">DJ on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + DJ Patil, Head of Technology at Devoted Health, discusses his time as the U.S. Chief Data Scientist, scaling healthcare to meet modern data demands, and the process of architecting a health care company.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + DJ Patil, Head of Technology at Devoted Health, discusses his time as the U.S. Chief Data Scientist, scaling healthcare to meet modern data demands, and the process of architecting a health care company.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+XXyLCghG + + ]]> + + + + 297: Go Deep (David Kloba & Rob Meinhardt) + https://podcast.thoughtbot.com/297 + 540c1ef1-e8dc-45eb-870b-5211730272e3 + Tue, 06 Nov 2018 12:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + David Kloba & Rob Meinhardt, Co-Founders of Furious Collective, discuss the mindset and methodology of their venture production studio, recount their adventures over the past year of growing FormKeep after having acquired it from thoughtbot, and offer advice to founders preparing to sell their product or company. + 49:31 + no + + <p>David Kloba &amp; Rob Meinhardt, Co-Founders of Furious Collective, discuss the mindset and methodology of their venture production studio, recount their adventures over the past year of growing FormKeep after having acquired it from thoughtbot, and offer advice to founders preparing to sell their product or company.</p> +<ul> +<li><a href="https://www.furiouscollective.com/">Furious Collective</a></li> +<li><a href="https://formkeep.com/">FormKeep</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + David Kloba & Rob Meinhardt, Co-Founders of Furious Collective, discuss the mindset and methodology of their venture production studio, recount their adventures over the past year of growing FormKeep after having acquired it from thoughtbot, and offer advice to founders preparing to sell their product or company.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + David Kloba & Rob Meinhardt, Co-Founders of Furious Collective, discuss the mindset and methodology of their venture production studio, recount their adventures over the past year of growing FormKeep after having acquired it from thoughtbot, and offer advice to founders preparing to sell their product or company.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+wXqIXtEp + + ]]> + + + + 296: Stay Close to Your Users (Andrew Bialecki) + https://podcast.thoughtbot.com/296 + 41ff8190-ee8e-4ce1-9f55-73bce6748235 + Tue, 30 Oct 2018 14:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Andrew Bialecki, CEO of Klaviyo, discusses building systems to process and get insight from business' data, scaling personality and humanity to mass communication, and translating customer feedback into concrete product improvement. Plus, the debut of 'Ask thoughtbot'! + 52:36 + no + + <p>Andrew Bialecki, CEO of Klaviyo, discusses building systems to process and get insight from business' data, scaling personality and humanity to mass communication, and translating customer feedback into concrete product improvement. Plus, the debut of 'Ask thoughtbot'!</p> +<ul> +<li><a href="https://www.klaviyo.com/">Klaviyo</a></li> +<li><a href="http://giantrobots.fm/269">David Cancel on <em>Giant Robots</em></a></li> +<li><a href="https://amzn.to/2JmPYVS"><em>The Innovators</em></a>- Walter Isaacson</li> +<li><a href="https://twitter.com/abialecki">Andrew on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Andrew Bialecki, CEO of Klaviyo, discusses building systems to process and get insight from business' data, scaling personality and humanity to mass communication, and translating customer feedback into concrete product improvement. Plus, the debut of 'Ask thoughtbot'!

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Andrew Bialecki, CEO of Klaviyo, discusses building systems to process and get insight from business' data, scaling personality and humanity to mass communication, and translating customer feedback into concrete product improvement. Plus, the debut of 'Ask thoughtbot'!

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+AnoDi8lS + + ]]> + + + + 295: Follow Your Passion (Jonathan Kim) + https://podcast.thoughtbot.com/295 + 8a39677f-4390-44fd-afe7-f35b8c7d5d32 + Wed, 24 Oct 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Jonathan Kim, CEO of Appcues, discusses building better onboarding and personalization to apps, starting a company as a solo founder, lessons learned from his time in journalism, and core culture values. + 41:41 + no + + <p>Jonathan Kim, CEO of Appcues, discusses building better onboarding and personalization to apps, starting a company as a solo founder, lessons learned from his time in journalism, and core culture values.</p> +<ul> +<li><a href="https://www.appcues.com/">Appcues</a></li> +<li><a href="http://giantrobots.fm/269">David Cancel on <em>Giant Robots</em></a></li> +<li><a href="https://twitter.com/hijonathan">Jonathan on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jonathan Kim, CEO of Appcues, discusses building better onboarding and personalization to apps, starting a company as a solo founder, lessons learned from his time in journalism, and core culture values.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jonathan Kim, CEO of Appcues, discusses building better onboarding and personalization to apps, starting a company as a solo founder, lessons learned from his time in journalism, and core culture values.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+csWqqJs5 + + ]]> + + + + 294: From a Place of Sharing (Chris Toomey) + https://podcast.thoughtbot.com/294 + 9750d64c-000d-4d6c-b786-9c0b6ba93536 + Thu, 18 Oct 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + In this special crossover episode, Chad is joined by Chris Toomey, Development Director at thoughtbot and host of The Bike Shed podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE. + 30:08 + no + + <p>In this special crossover episode, Chad is joined by Chris Toomey, Development Director at thoughtbot and host of <em>The Bike Shed</em> podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE.</p> +<ul> +<li><a href="http://bikeshed.fm/"><em>The Bike Shed</em></a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://thoughtbot.com/upcase/test-driven-rails">Test Driven Rails</a></li> +<li><a href="https://thoughtbot.com/upcase/mastering-git">Mastering Git</a></li> +<li><a href="https://thoughtbot.com/upcase/fundamentals-of-tdd">Fundamentals of TDD</a></li> +<li><a href="http://bikeshed.fm/166">SOA on <em>The Bike Shed</em></a></li> +<li><a href="https://thoughtbot.com/upcase/onramp-to-vim">Onramp to Vim</a></li> +<li><a href="https://thoughtbot.com/purpose">thoughtbot Purpose Statement</a></li> +<li><a href="https://twitter.com/christoomey">Chris on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + In this special crossover episode, Chad is joined by Chris Toomey, Development Director at thoughtbot and host of The Bike Shed podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this special crossover episode, Chad is joined by Chris Toomey, Development Director at thoughtbot and host of The Bike Shed podcast, to discuss the content, history, and the process of making Upcase, thoughtbot's online learning platform, FREE.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0KBxfgwk + + ]]> + + + + 293: Advertising as a Service (Sandra Richter) + https://podcast.thoughtbot.com/293 + ed006b9f-7624-4146-bfc8-7a03af78df7c + Wed, 10 Oct 2018 12:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Sandra Richter, Co-founder and CEO of Soofa, talks about redefining the infrastructure of out of home advertising, purpose vs business motivation, and learning from setbacks. + 44:23 + no + + <p>Sandra Richter, Co-founder and CEO of Soofa, talks about redefining the infrastructure of out of home advertising, purpose vs business motivation, and learning from setbacks.</p> +<ul> +<li><a href="https://www.soofa.co/">Soofa</a></li> +<li><a href="https://www.media.mit.edu/">MIT Media Lab</a></li> +<li><a href="https://www.soofa.co/advertise">Soofa Sign</a></li> +<li><a href="https://talk.soofa.co/">Soofa Talk</a></li> +<li><a href="https://twitter.com/Cosmonautin">Sandra on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Sandra Richter, Co-founder and CEO of Soofa, talks about redefining the infrastructure of out of home advertising, purpose vs business motivation, and learning from setbacks.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sandra Richter, Co-founder and CEO of Soofa, talks about redefining the infrastructure of out of home advertising, purpose vs business motivation, and learning from setbacks.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9h5NQgMM + + ]]> + + + + 292: MVP-ing the Sales Process (Lindsey Christensen) + https://podcast.thoughtbot.com/292 + 15184842-3d75-4742-906c-940183b0adc1 + Tue, 02 Oct 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Lindsey Christensen, VP of Marketing at thoughtbot, discusses shaping thoughtbot's marketing strategy, team, and future. + 47:20 + no + + <p>Lindsey Christensen, VP of Marketing at thoughtbot, discusses shaping thoughtbot's marketing strategy, team, and future.</p> +<ul> +<li><a href="https://thoughtbot.com/resources">Purpose-built</a> Resource Center</li> +<li><a href="http://bikeshed.fm/">The Bike Shed</a> Podcast</li> +<li><a href="https://twitter.com/Lindsey3D">Lindsey on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Lindsey Christensen, VP of Marketing at thoughtbot, discusses shaping thoughtbot's marketing strategy, team, and future.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Lindsey Christensen, VP of Marketing at thoughtbot, discusses shaping thoughtbot's marketing strategy, team, and future.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dBE3-CgR + + ]]> + + + + 291: Intrapreneurial Streak (Heena Purohit) + https://podcast.thoughtbot.com/291 + e25be20c-ea6d-4b0b-a956-35165b6ae863 + Tue, 25 Sep 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Heena Purohit, Product Manager of IBM Watson IoT, discusses how they are tailoring custom solutions with IoT data, building business acumen for better product managing, and iterating at scale. + 42:05 + no + + <p>Heena Purohit, Product Manager of IBM Watson IoT, discusses how they are tailoring custom solutions with IoT data, building business acumen for better product managing, and iterating at scale.</p> +<ul> +<li><a href="https://www.ibm.com/internet-of-things/solutions/iot-platform/watson-iot-platform">IBM Watson IoT</a></li> +<li><a href="https://en.wikipedia.org/wiki/Stryker">Stryker Vehicle</a></li> +<li><a href="https://en.wikipedia.org/wiki/Intrapreneurship">Intrapreneurship</a></li> +<li><a href="https://www.research.ibm.com/artificial-intelligence/trusted-ai/">Trusted AI</a></li> +<li><a href="https://twitter.com/justheena">Heena on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Heena Purohit, Product Manager of IBM Watson IoT, discusses how they are tailoring custom solutions with IoT data, building business acumen for better product managing, and iterating at scale.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Heena Purohit, Product Manager of IBM Watson IoT, discusses how they are tailoring custom solutions with IoT data, building business acumen for better product managing, and iterating at scale.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MbMLiFCU + + ]]> + + + + 290: Usage Native (Mike Trotzke) + https://podcast.thoughtbot.com/290 + 2328057f-5b06-46b7-b463-92679b799f13 + Tue, 11 Sep 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Mike Trotzke, CEO of Cheddar, talks about the future of billing models, when is the right time to do seed investing, and finding your value pricing metric. + 36:20 + no + + <p>Mike Trotzke, CEO of Cheddar, talks about the future of billing models, when is the right time to do seed investing, and finding your value pricing metric.</p> +<ul> +<li><a href="https://www.getcheddar.com/">Cheddar</a></li> +<li><a href="https://info.getcheddar.com/pricing-bootcamp-how-to-price-your-startup-for-maximum-revenue-optimization-1">Pricing Bootcamp</a></li> +<li><a href="https://labs.openviewpartners.com/saas-pricing-strategies-frameworks-lessons-learned/#.W5bmWpMzqRc">&quot;SaaS Pricing: Strategies, Frameworks &amp; Lessons Learned&quot;</a>- Chad Pytel</li> +<li><a href="https://thoughtbot.com/work/splitfit">Building Splitfit</a></li> +<li><a href="https://twitter.com/trotzke">Mike on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Mike Trotzke, CEO of Cheddar, talks about the future of billing models, when is the right time to do seed investing, and finding your value pricing metric.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Mike Trotzke, CEO of Cheddar, talks about the future of billing models, when is the right time to do seed investing, and finding your value pricing metric.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MjK-WuFc + + ]]> + + + + 289: Capture Community Early (Jameson Toole) + https://podcast.thoughtbot.com/289 + b9b78a79-3f9c-49ab-b7f3-1556acf7de26 + Mon, 03 Sep 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Jameson Toole, founder of Fritz, discusses AI & Machine Learning on mobile, the process & ideology of launching a product from scratch, and the business of developer tools. + 35:38 + no + + <p>Jameson Toole, founder of Fritz, discusses AI &amp; Machine Learning on mobile, the process &amp; ideology of launching a product from scratch, and the business of developer tools.</p> +<ul> +<li><a href="https://fritz.ai/">Fritz</a></li> +<li><a href="https://developer.apple.com/documentation/coreml">Core ML</a></li> +<li><a href="https://www.tensorflow.org/">TensorFlow</a></li> +<li><a href="http://instasaber.com/">InstaSaber</a></li> +<li><a href="https://heartbeat.fritz.ai/?gi=94724473d4f9">Heartbeat</a></li> +<li><a href="https://twitter.com/jamesonthecrow">Jameson on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jameson Toole, founder of Fritz, discusses AI & Machine Learning on mobile, the process & ideology of launching a product from scratch, and the business of developer tools.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jameson Toole, founder of Fritz, discusses AI & Machine Learning on mobile, the process & ideology of launching a product from scratch, and the business of developer tools.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+QFq1zjEN + + ]]> + + + + 288: Pursuing Customer Delight (Yoav Shapira) + https://podcast.thoughtbot.com/288 + df94c059-21c9-4ebc-96f5-e29eba66eda2 + Mon, 27 Aug 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Yoav Shapira, an Engineering Manager at Facebook with a long history in Boston startups, discusses early technology choices for startups, balancing product needs/wants with technical limitations, the role of Capital-D 'Design', and common startup advice. + 51:25 + no + + <p>Yoav Shapira, an Engineering Manager at Facebook with a long history in Boston startups, discusses early technology choices for startups, balancing product needs/wants with technical limitations, the role of Capital-D 'Design', and common startup advice.</p> +<ul> +<li><a href="https://www.cargurus.com/">CarGurus</a></li> +<li><a href="https://www.hubspot.com/">HubSpot</a></li> +<li><a href="https://www.happier.com/">Happier</a></li> +<li><a href="http://www.jana.com/about">Jana</a></li> +<li><a href="http://giantrobots.fm/269">David Cancel on <em>Giant Robots</em></a></li> +<li><a href="https://thoughtbot.com/playbook">thoughtbot Playbook</a></li> +<li><a href="https://www.article19.org/data/files/Internet_Statement_Adopted.pdf">Internet Access a Basic Human Right</a></li> +<li><a href="https://youtu.be/HHfoAY2Y4dU">Building a Crucial Conversations Culture at Facebook</a></li> +<li><a href="https://managingbias.fb.com/">Managing Unconscious Bias</a></li> +<li><a href="https://twitter.com/YoavShapira">Yoav on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Yoav Shapira, an Engineering Manager at Facebook with a long history in Boston startups, discusses early technology choices for startups, balancing product needs/wants with technical limitations, the role of Capital-D 'Design', and common startup advice.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Yoav Shapira, an Engineering Manager at Facebook with a long history in Boston startups, discusses early technology choices for startups, balancing product needs/wants with technical limitations, the role of Capital-D 'Design', and common startup advice.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+S7Z6qUYh + + ]]> + + + + 287: Disruptive, Exponentially-Innovative, 10x Videos (Sarah Cooper) + https://podcast.thoughtbot.com/287 + dcfe892a-1229-43df-b122-baab023685df + Mon, 20 Aug 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Sarah Cooper, comedian, speaker, and author of "100 Tricks to Appear Smart in Meetings", joins Chad to discuss management burnout, the creative process, and her latest book. + 30:19 + no + + <p>Sarah Cooper, comedian, speaker, and author of <em>100 Tricks to Appear Smart in Meetings</em>, joins Chad to discuss management burnout, the creative process, and her latest book.</p> +<ul> +<li><a href="https://amzn.to/2MLegdf"><em>100 Tricks to Appear Smart in Meetings</em></a></li> +<li><a href="https://thecooperreview.com/">The Cooper Review</a></li> +<li><a href="https://thecooperreview.com/10-tricks-appear-smart-meetings/">&quot;10 Tricks to Appear Smart in Meetings&quot;</a></li> +<li><a href="http://theoatmeal.com/comics">The Oatmeal</a></li> +<li><a href="https://amzn.to/2MJz2db"><em>How to be Successful Without Hurting Men's Feelings</em></a></li> +<li><a href="https://thecooperreview.com/non-threatening-leadership-strategies-for-women/">&quot;9 Non-Threatening Leadership Strategies for Women&quot;</a></li> +<li><a href="https://youtu.be/ykTQE30pMFg">The Bubble: Crushing It</a></li> +<li><a href="http://sarahcpr.com/">Sarah Cooper</a></li> +<li><a href="https://www.mcsweeneys.net/">McSweeney's</a></li> +<li><a href="https://twitter.com/sarahcpr">Sarah on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Sarah Cooper, comedian, speaker, and author of 100 Tricks to Appear Smart in Meetings, joins Chad to discuss management burnout, the creative process, and her latest book.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sarah Cooper, comedian, speaker, and author of 100 Tricks to Appear Smart in Meetings, joins Chad to discuss management burnout, the creative process, and her latest book.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+qn41_jN4 + + ]]> + + + + 286: A Million Boxes at a Time (Stephan Ango) + https://podcast.thoughtbot.com/286 + 592b2442-eed8-4e29-8287-2e3c6844580f + Tue, 14 Aug 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Stephan Ango, Co-founder and Head of Product at Lumi, discusses merging creative and scientific mindsets in industrial design, the logistics of packaging, developing custom solutions by slowly replacing 3rd party tools, and building your ideal culture while balancing operational needs. + 47:37 + no + + <p>Stephan Ango, Co-founder and Head of Product at Lumi, discusses merging creative and scientific mindsets in industrial design, the logistics of packaging, developing custom solutions by slowly replacing 3rd party tools, and building your ideal culture while balancing operational needs.</p> +<ul> +<li><a href="https://www.lumi.com/">Lumi</a></li> +<li><a href="http://www.inkodye.com/">Inkodye</a></li> +<li><a href="https://github.com/purescript/purescript">PureScript</a></li> +<li><a href="https://medium.com/fuzzy-sharp/purescript-and-haskell-at-lumi-7e8e2b16fb13">PureScript and Haskell at Lumi</a></li> +<li><a href="https://www.lumi.com/wellmade"><em>Well Made</em> Podcast</a></li> +<li><a href="https://www.lumi.com/shippingthings"><em>Shipping Things</em></a></li> +<li><a href="https://kk.org/thetechnium/1000-true-fans/">&quot;1,000 True Fans&quot;</a>- Kevin Kelly</li> +<li><a href="https://twitter.com/kepano">Stephan on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Stephan Ango, Co-founder and Head of Product at Lumi, discusses merging creative and scientific mindsets in industrial design, the logistics of packaging, developing custom solutions by slowly replacing 3rd party tools, and building your ideal culture while balancing operational needs.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Stephan Ango, Co-founder and Head of Product at Lumi, discusses merging creative and scientific mindsets in industrial design, the logistics of packaging, developing custom solutions by slowly replacing 3rd party tools, and building your ideal culture while balancing operational needs.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+W6USsEv3 + + ]]> + + + + 285: Deep Counting (Jerry Talton) + https://podcast.thoughtbot.com/285 + 666011e1-d36b-4e6e-ad3b-0f967f8fbd1c + Mon, 06 Aug 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Jerry Talton, leader of the Machine-Learning Services team at Slack, talks about picking up after a failed startup, design-thinking for machine learning, and important lessons from managing. + 47:52 + no + + <p>Jerry Talton, leader of the Machine-Learning Services team at Slack, talks about picking up after a failed startup, design-thinking for machine learning, and important lessons from managing.</p> +<ul> +<li><a href="https://slack.com/">Slack</a></li> +<li><a href="https://en.wikipedia.org/wiki/Eating_your_own_dog_food">&quot;Doggfooding&quot;</a></li> +<li><a href="https://github.com/facebookresearch/Starspace">StarSpace</a></li> +<li><a href="https://www.harrisonmetal.com/classes/foundations-general-management">General Management Course</a></li> +<li><a href="https://amzn.to/2ACfTYY"><em>The No Asshole Rule</em></a>- Robert Sutton</li> +<li><a href="https://amzn.to/2ODdZKJ"><em>Creativity, Inc.</em></a>- Ed Catmull</li> +<li><a href="https://youtu.be/ZQJ6yqQRAQs"><em>West Wing</em></a>- Down in a Hole</li> +<li><a href="http://giantrobots.fm/256"><em>Giant Robots</em> ep 256</a>- Stay Hungry, Stay Learning</li> +<li><a href="https://homes.cs.washington.edu/%7Epedrod/papers/cacm12.pdf">'A Few Useful Things to Know About Machine Learning'</a>- Pedro Domingos</li> +<li><a href="https://icml.cc/Conferences/2005/proceedings/papers/067_NaiveBayes_LowdDomingos.pdf">'Naive Bayes Models for Probability Estimation'</a>- Lowd &amp; Domingos</li> +<li><a href="https://twitter.com/jerrytalton">Jerry on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jerry Talton, leader of the Machine-Learning Services team at Slack, talks about picking up after a failed startup, design-thinking for machine learning, and important lessons from managing.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jerry Talton, leader of the Machine-Learning Services team at Slack, talks about picking up after a failed startup, design-thinking for machine learning, and important lessons from managing.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+XtuvJiqd + + ]]> + + + + 284: Bringing Vision to Robots (Clara Vu) + https://podcast.thoughtbot.com/284 + 7dda9e54-2f6c-4280-a741-db9b29d7819b + Mon, 23 Jul 2018 14:30:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Clara Vu, co-founder & VP of Engineering of Veo Robotics, shares her story getting into the world of robotics, designing perception systems for industrial robots, and 'First-Principles Thinking' in all aspects of business. + 41:29 + no + + <p>Clara Vu, co-founder &amp; VP of Engineering of Veo Robotics, shares her story getting into the world of robotics, designing perception systems for industrial robots, and 'First-Principles Thinking' in all aspects of business.</p> +<ul> +<li><a href="https://www.veobot.com/">Veo Robotics</a></li> +<li><a href="https://en.wikipedia.org/wiki/T-shaped_skills">T-Shaped Skills</a></li> +<li><a href="https://en.wikipedia.org/wiki/Time-of-flight_camera">Time of Flight Cameras</a></li> +<li><a href="https://www.linkedin.com/in/clara-vu-244941/">Clara on LinkedIn</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Clara Vu, co-founder & VP of Engineering of Veo Robotics, shares her story getting into the world of robotics, designing perception systems for industrial robots, and 'First-Principles Thinking' in all aspects of business.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Clara Vu, co-founder & VP of Engineering of Veo Robotics, shares her story getting into the world of robotics, designing perception systems for industrial robots, and 'First-Principles Thinking' in all aspects of business.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rVgfHqWI + + ]]> + + + + 283: Overcoming Awkward Data (Joe Ferris) + https://podcast.thoughtbot.com/283 + c86c81b3-d62f-4b2a-afab-258e3ec8532f + Mon, 16 Jul 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Joe Ferris, CTO of thoughtbot, joins Chad to discuss Data Engineering, what it is, when you need it, and some of the challenges thoughtbot has faced while using it. + 41:14 + no + + <p>Joe Ferris, CTO of thoughtbot, joins Chad to discuss Data Engineering, what it is, when you need it, and some of the challenges thoughtbot has faced while using it.</p> +<ul> +<li><a href="http://giantrobots.fm/263">Machine Learning on <em>Giant Robots</em></a></li> +<li><a href="https://twitter.com/joeferris">Joe on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Joe Ferris, CTO of thoughtbot, joins Chad to discuss Data Engineering, what it is, when you need it, and some of the challenges thoughtbot has faced while using it.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Joe Ferris, CTO of thoughtbot, joins Chad to discuss Data Engineering, what it is, when you need it, and some of the challenges thoughtbot has faced while using it.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kvL3-mHb + + ]]> + + + + 282: Robot as a Platform (Tim Enwall) + https://podcast.thoughtbot.com/282 + fab9b6ed-ad65-4b81-8a9e-f3fe937987bb + Mon, 02 Jul 2018 11:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Tim Enwall, CEO of Misty Robotics, discusses designing, building, and selling a fully autonomous robot for developers. + 38:28 + no + + <p>Tim Enwall, CEO of Misty Robotics, discusses designing, building, and selling a fully autonomous robot for developers.</p> +<ul> +<li><a href="https://www.mistyrobotics.com/">Misty Robotics</a>- Use code <code>GiantRobot</code> for $200 off pre-orders</li> +<li><a href="https://www.sphero.com/">Sphero</a></li> +<li><a href="https://www.robotshop.com/">RobotShop</a></li> +<li><a href="http://amzn.to/2irbW0m"><em>Crossing the Chasm</em></a>- Geoffrey A. Moore</li> +<li><a href="https://images.thoughtbot.com/blog-vellum-image-uploads/pLSqkrMoRqGHLSRbHO1Q_MistyIphoto.jpg">Misty Series Pics</a></li> +<li><a href="https://www.liveworx.com/">LiveWorx Conference</a></li> +<li><a href="https://medium.com/@tenwall">Tim on Medium</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Tim Enwall, CEO of Misty Robotics, discusses designing, building, and selling a fully autonomous robot for developers.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Tim Enwall, CEO of Misty Robotics, discusses designing, building, and selling a fully autonomous robot for developers.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GsZQf0Ux + + ]]> + + + + 281: Reconnecting With Development (Robby Russell) + https://podcast.thoughtbot.com/281 + 7f1cf9e3-5cab-4fc3-9521-834c6f96512f + Mon, 25 Jun 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Robby Russell, VP of Engineering & Partner at Planet Argon, discusses considering remote work for an agency, strategies for leading a dev team, defining focus for an agency, and the results of the 2018 Rails Hosting Survey. + 49:33 + no + + <p>Robby Russell, VP of Engineering &amp; Partner at Planet Argon, discusses considering remote work for an agency, strategies for leading a dev team, defining focus for an agency, and the results of the 2018 Rails Hosting Survey.</p> +<ul> +<li><a href="https://www.planetargon.com/">Planet Argon</a></li> +<li><a href="https://www.eosworldwide.com/traction"><em>Traction: Get a Grip on Your Business</em></a></li> +<li><a href="http://rails-hosting.com/">Rails Hosting Survey</a></li> +<li><a href="https://twitter.com/robbyrussell">Robby on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Robby Russell, VP of Engineering & Partner at Planet Argon, discusses considering remote work for an agency, strategies for leading a dev team, defining focus for an agency, and the results of the 2018 Rails Hosting Survey.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Robby Russell, VP of Engineering & Partner at Planet Argon, discusses considering remote work for an agency, strategies for leading a dev team, defining focus for an agency, and the results of the 2018 Rails Hosting Survey.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YyaEnaE_ + + ]]> + + + + 280: Design at the Program Layer (Greg Storey) + https://podcast.thoughtbot.com/280 + a0776a7d-cf68-4634-a6d0-c6d47a806246 + Mon, 18 Jun 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Greg Storey, founder of Airbag Industries & Executive Director of Design at USAA, discusses the blurring of personal and company identity, helming a budding design group, "safe agile", what it means for design to 'have a seat at the table', and sustainable pace within an agency. + 47:19 + no + + <p>Greg Storey, founder of Airbag Industries &amp; Executive Director of Design at USAA, discusses the blurring of personal and company identity, helming a budding design group, &quot;safe agile&quot;, what it means for design to 'have a seat at the table', and sustainable pace within an agency.</p> +<ul> +<li><a href="http://airbagindustries.com/">Airbag Industries</a></li> +<li><a href="https://www.electricpulp.com/">Electric Pulp</a></li> +<li><a href="https://deardesignstudent.com/you-are-not-your-job-search-922871d815de">&quot;You Are Not Your Job Search&quot;</a>- Greg Storey</li> +<li><a href="https://robots.thoughtbot.com/how-design-is-changing-it">&quot;How Design is Changing IT&quot;</a>- Chad Pytel</li> +<li><a href="https://www.ibm.com/design/thinking/">IBM: Enterprise Design Thinking</a></li> +<li><a href="https://www.ibm.com/design/thinking/static/media/Enterprise-Design-Thinking-Report.8ab1e9e1.pdf">Forrester: IBM's Design Thinking Study</a></li> +<li><a href="https://medium.com/sprintsandmilestones">Sprints &amp; Milestones Podcast</a></li> +<li><a href="https://twitter.com/Brilliantcrank">Greg on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Greg Storey, founder of Airbag Industries & Executive Director of Design at USAA, discusses the blurring of personal and company identity, helming a budding design group, "safe agile", what it means for design to 'have a seat at the table', and sustainable pace within an agency.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Greg Storey, founder of Airbag Industries & Executive Director of Design at USAA, discusses the blurring of personal and company identity, helming a budding design group, "safe agile", what it means for design to 'have a seat at the table', and sustainable pace within an agency.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kZNRk1Ce + + ]]> + + + + 279: Building a Lifelong Brand (Alex Friedman) + https://podcast.thoughtbot.com/279 + 50a05d51-8999-4fef-911f-4c5db3abd6c4 + Mon, 11 Jun 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Alex Friedman, co-founder of LOLA, discusses overcoming stigma, launching new products, measuring success, and brand values. + 24:53 + no + + <p>Alex Friedman, co-founder of LOLA, discusses overcoming stigma, launching new products, measuring success, and brand values.</p> +<ul> +<li><a href="https://www.mylola.com/">LOLA</a></li> +<li><a href="https://www.mylola.com/collections/sex">Sex by LOLA</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Alex Friedman, co-founder of LOLA, discusses overcoming stigma, launching new products, measuring success, and brand values.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Alex Friedman, co-founder of LOLA, discusses overcoming stigma, launching new products, measuring success, and brand values.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+LItj8TF- + + ]]> + + + + 278: The 'Lights On' Moment (Sam Moorhouse) + https://podcast.thoughtbot.com/278 + baeb23aa-e563-493e-a34e-310e4ad0e238 + Mon, 04 Jun 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Sam Moorhouse, creator of Global Code, discusses the importance of mentorship and how he established a software engineering summer education program in Ghana. + 28:04 + no + + <p>Sam Moorhouse, creator of Global Code, discusses the importance of mentorship and how he established a software engineering summer education program in Ghana.</p> +<ul> +<li><a href="https://globalcode.org.uk/">Global Code</a></li> +<li><a href="http://www.elite-education.org/">ELiTE</a></li> +<li><a href="https://www.engineering.columbia.edu/news/computer-science-ghana">ELiTE in Ghana</a></li> +<li><a href="https://www.raspberrypi.org/">Raspberry Pi</a></li> +<li><a href="https://twitter.com/sammoorhouse">Sam on Twitter</a></li> +<li><a href="https://twitter.com/glblcd">Global Code on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Sam Moorhouse, creator of Global Code, discusses the importance of mentorship and how he established a software engineering summer education program in Ghana.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sam Moorhouse, creator of Global Code, discusses the importance of mentorship and how he established a software engineering summer education program in Ghana.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+O5nUlyDC + + ]]> + + + + 277: How Do We Work Together? (Michael Sheeley) + https://podcast.thoughtbot.com/277 + bee3384a-e2f5-4795-aa8e-56dd0f31b17c + Mon, 28 May 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Michael Sheeley, former co-founder of Runkeeper, talks about his struggles with scaling, experimentation with prices, finding ways to connect and work together as a larger society, and innovation in health care. + 53:26 + no + + <p>Michael Sheeley, former co-founder of Runkeeper, talks about his struggles with scaling, experimentation with prices, finding ways to connect and work together as a larger society, and innovation in health care.</p> +<ul> +<li><a href="https://runkeeper.com/">Runkeeper</a></li> +<li><a href="https://twitter.com/MichaelSheeley">Michael on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + Special Guest: Nurse-1-1. + + + Michael Sheeley, former co-founder of Runkeeper, talks about his struggles with scaling, experimentation with prices, finding ways to connect and work together as a larger society, and innovation in health care.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Michael Sheeley, former co-founder of Runkeeper, talks about his struggles with scaling, experimentation with prices, finding ways to connect and work together as a larger society, and innovation in health care.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Special Guest: Nurse-1-1.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bF-UbuEE + + ]]> + + Nurse-1-1 + + + 276: Enable and Serve (Chris Heivly) + https://podcast.thoughtbot.com/276 + 0d6b0f40-bd93-4f4f-9fd5-fbaba313036c + Tue, 22 May 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chris Heivly, author & entrepreneur in residence at Techstars, discusses the early days of MapQuest, Raleigh as a burgeoning tech city, and building up new tech communities. + 47:31 + no + + <p>Chris Heivly, author &amp; entrepreneur in residence at Techstars, discusses the early days of MapQuest, Raleigh as a burgeoning tech city, and building up new tech communities.</p> +<ul> +<li><a href="https://amzn.to/2KxbF55"><em>Build the Fort</em></a>- Chris Heivly</li> +<li><a href="https://www.techstars.com/">Techstars</a></li> +<li><a href="https://amzn.to/2k95F7C"><em>The Innovator's Dilemma</em></a>- Clayton M. Christensen</li> +<li><a href="https://www.randmcnally.com/">Rand McNally</a></li> +<li><a href="https://amzn.to/2GzZCBH"><em>Startup Communities</em></a>- Brad Feld</li> +<li><a href="http://heivly.com/">Heivly.com</a></li> +<li><a href="https://amzn.to/2wZ13Kl"><em>The Lean Startup</em></a>- Eric Ries</li> +<li><a href="https://twitter.com/chrisheivly">Chris on Twitter</a></li> +</ul> +<p>See <a href="https://goo.gl/AAazrT">open positions</a> at thoughtbot!</p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chris Heivly, author & entrepreneur in residence at Techstars, discusses the early days of MapQuest, Raleigh as a burgeoning tech city, and building up new tech communities.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris Heivly, author & entrepreneur in residence at Techstars, discusses the early days of MapQuest, Raleigh as a burgeoning tech city, and building up new tech communities.

+ + + +

See open positions at thoughtbot!

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Fhb1kx_5 + + ]]> + + + + 275: Galvanizing Focus (Paul English) + https://podcast.thoughtbot.com/275 + b1d18e73-0749-4d10-bee5-cee791bf0f39 + Mon, 14 May 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Paul English, co-founder of Lola, discusses what it means to be a good brand, transitioning from a tech foundry to a single-product focus, lessons learned from having launched multiple companies, and his approaches to competition & success. + 43:00 + no + + <p>Paul English, co-founder of Lola, discusses what it means to be a good brand, transitioning from a tech foundry to a single-product focus, lessons learned from having launched multiple companies, and his approaches to competition &amp; success.</p> +<ul> +<li><a href="http://giantrobots.fm/269">David Cancel on <em>Giant Robots</em></a></li> +<li><a href="http://paulenglish.com/">Paul English</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Paul English, co-founder of Lola, discusses what it means to be a good brand, transitioning from a tech foundry to a single-product focus, lessons learned from having launched multiple companies, and his approaches to competition & success.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Paul English, co-founder of Lola, discusses what it means to be a good brand, transitioning from a tech foundry to a single-product focus, lessons learned from having launched multiple companies, and his approaches to competition & success.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+BmkZ6P9i + + ]]> + + + + 274: Providing Value (Ram V. Iyer) + https://podcast.thoughtbot.com/274 + 080931d2-b918-4599-8af7-7f68fc9ac61d + Tue, 08 May 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Ram V. Iyer, Business Thinker & Professional Business Mentor at The Business Thinking Institute, discusses his internalization of business success/failure, having a 'business thinking' mindset, and distinguishing oneself through the value you can create. + 37:11 + no + + <p>Ram V. Iyer, Business Thinker &amp; Professional Business Mentor at The Business Thinking Institute, discusses his internalization of business success/failure, having a 'business thinking' mindset, and distinguishing oneself through the value you can create.</p> +<ul> +<li><a href="http://www.businessthinking.com/">Business Thinking Institute</a></li> +<li><a href="http://www.businessthinking.com/about/my_why">Business Thinking- My Why</a></li> +<li><a href="https://www.businessthinking.com/podcasts">Business Thinking Radio</a></li> +<li><a href="http://www.businessthinking.com/quiz/are-you-wired-for-business-success">'Silent Killers' Quiz</a></li> +<li><a href="https://www.linkedin.com/in/ramviyermit/">Ram on LinkedIn</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Ram V. Iyer, Business Thinker & Professional Business Mentor at The Business Thinking Institute, discusses his internalization of business success/failure, having a 'business thinking' mindset, and distinguishing oneself through the value you can create.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ram V. Iyer, Business Thinker & Professional Business Mentor at The Business Thinking Institute, discusses his internalization of business success/failure, having a 'business thinking' mindset, and distinguishing oneself through the value you can create.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+G0QTfgFp + + ]]> + + + + 273: Showcase Your Value (Nilan Peiris) + https://podcast.thoughtbot.com/273 + bbe980f1-409e-4a3a-86f4-3c9014856a52 + Mon, 30 Apr 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Nilan Peiris, VP of Growth at TransferWise, discusses growth sources, handling failure, studying user evangelism, launching in a new market, and scaling globally. + 31:17 + no + + <p>Nilan Peiris, VP of Growth at TransferWise, discusses growth sources, handling failure, studying user evangelism, launching in a new market, and scaling globally.</p> +<ul> +<li><a href="https://transferwise.com/">TransferWise</a></li> +<li><a href="https://twitter.com/nilanp">Nilan on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Nilan Peiris, VP of Growth at TransferWise, discusses growth sources, handling failure, studying user evangelism, launching in a new market, and scaling globally.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Nilan Peiris, VP of Growth at TransferWise, discusses growth sources, handling failure, studying user evangelism, launching in a new market, and scaling globally.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+HUFExoJW + + ]]> + + + + 272: Grown-Up App Development (Dermot Daly) + https://podcast.thoughtbot.com/272 + 7ca405f6-cbfa-4169-aff9-f128698c6bc5 + Mon, 23 Apr 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Dermot Daly, founder and CEO of Tapadoo, discusses being a developer early in the iOS ecosystem while differentiating themselves now as it's become a more crowded market-space, building your ideal company, and developing apps for med-tech devices. + 36:26 + no + + <p>Dermot Daly, founder and CEO of Tapadoo, discusses being a developer early in the iOS ecosystem while differentiating themselves now as it's become a more crowded market-space, building your ideal company, and developing apps for med-tech devices.</p> +<ul> +<li><a href="http://tapadoo.com/">Tapadoo</a></li> +<li><a href="https://www.meetup.com/Xcake-Mobile-app-development-with-an-Appley-flavour/">xCake</a></li> +<li><a href="https://amzn.to/2qOalmg"><em>Finish Big</em></a></li> +<li><a href="https://www.slendertone.com/us-en/">Slendertone</a></li> +<li><a href="https://twitter.com/dermdaly">Dermot on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Dermot Daly, founder and CEO of Tapadoo, discusses being a developer early in the iOS ecosystem while differentiating themselves now as it's become a more crowded market-space, building your ideal company, and developing apps for med-tech devices.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Dermot Daly, founder and CEO of Tapadoo, discusses being a developer early in the iOS ecosystem while differentiating themselves now as it's become a more crowded market-space, building your ideal company, and developing apps for med-tech devices.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+uZNZrwWp + + ]]> + + + + 271: Being a Good Manager (Camille Fournier) + https://podcast.thoughtbot.com/271 + e34fdd55-f1c7-435e-bc81-712074f8e3c6 + Tue, 17 Apr 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Camille Fournier, author, speaker, and Managing Director at Two Sigma, discusses her path from Director of Infrastructure Engineering to CTO, lessons learned from tech team management, and the importance of defining core-values. + 40:32 + no + + <p>Camille Fournier, author, speaker, and Managing Director at Two Sigma, discusses her path from Director of Infrastructure Engineering to CTO, lessons learned from tech team management, and the importance of defining core-values.</p> +<ul> +<li><a href="https://www.twosigma.com/">Two Sigma</a></li> +<li><a href="https://www.renttherunway.com/">Rent the Runway</a></li> +<li><a href="https://amzn.to/2vcaqp5"><em>The Manager's Path</em></a></li> +<li><a href="http://giantrobots.fm/269">David Cancel on <em>Giant Robots</em></a></li> +<li><a href="https://twitter.com/skamille">Camille on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Camille Fournier, author, speaker, and Managing Director at Two Sigma, discusses her path from Director of Infrastructure Engineering to CTO, lessons learned from tech team management, and the importance of defining core-values.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Camille Fournier, author, speaker, and Managing Director at Two Sigma, discusses her path from Director of Infrastructure Engineering to CTO, lessons learned from tech team management, and the importance of defining core-values.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+SfYTgSsf + + ]]> + + + + 270: How's Work Lately? (Jennifer Dary) + https://podcast.thoughtbot.com/270 + 5ef07624-7c8a-42de-a2db-23eeb12fd5c8 + Tue, 10 Apr 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Jennifer Dary, founder of Plucky, discusses purpose, process, longevity, relationships, and trust by turning the tables and giving Chad a corporate counseling session. + 48:54 + no + + <p>Jennifer Dary, founder of Plucky, discusses purpose, process, longevity, relationships, and trust by turning the tables and giving Chad a corporate counseling session.</p> +<ul> +<li><a href="https://www.beplucky.com/">Plucky</a></li> +<li><a href="http://hopscotchdesignfest.com/">Hopscotch Design Festival</a></li> +<li><a href="https://www.thisismetis.com/">Metis</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://amzn.to/2GJFH88"><em>Joe Torre's Ground Rules for Winners</em></a></li> +<li><a href="https://www.beplucky.com/shop/">1:1 Starter Pack</a></li> +<li><a href="https://twitter.com/jenniferdary">Jennifer on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Jennifer Dary, founder of Plucky, discusses purpose, process, longevity, relationships, and trust by turning the tables and giving Chad a corporate counseling session.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jennifer Dary, founder of Plucky, discusses purpose, process, longevity, relationships, and trust by turning the tables and giving Chad a corporate counseling session.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+NsgYWett + + ]]> + + + + 269: Human to Human Connection (David Cancel) + https://podcast.thoughtbot.com/269 + f18f3618-01d5-4ee0-934c-2bc1256c22a3 + Tue, 03 Apr 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + David Cancel, CEO & Co-founder of Drift, discusses bringing the personal touch back to sales through conversational marketing, validating an idea, competition, and differentiating yourself through communication & marketing. + 45:02 + no + + <p>David Cancel, CEO &amp; Co-founder of Drift, discusses bringing the personal touch back to sales through conversational marketing, validating an idea, competition, and differentiating yourself through communication &amp; marketing.</p> +<ul> +<li><a href="https://www.drift.com/">Drift</a></li> +<li><a href="http://davidcancel.com/true-startup-competition">True Startup Competition</a></li> +<li><a href="https://brooklynboulders.com/somerville/">Brooklyn Boulders</a></li> +<li><a href="https://www.drift.com/hypergrowth/"><em>HYPERGROWTH</em></a></li> +<li><a href="https://seekingwisdom.io/tagged/podcast">Seeking Wisdom Podcast</a></li> +<li><a href="https://twitter.com/dcancel">David on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + David Cancel, CEO & Co-founder of Drift, discusses bringing the personal touch back to sales through conversational marketing, validating an idea, competition, and differentiating yourself through communication & marketing.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + David Cancel, CEO & Co-founder of Drift, discusses bringing the personal touch back to sales through conversational marketing, validating an idea, competition, and differentiating yourself through communication & marketing.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cutMH4Wz + + ]]> + + + + 268: Present and Effective (Adam Marchick) + https://podcast.thoughtbot.com/268 + 58ed2234-25ce-4881-98cd-96947afa934e + Tue, 27 Mar 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Adam Marchick, CEO & co-founder of Alpine AI, discusses pioneering vocal analytics, making a better experience for digital commerce on vocal platforms, and operating in an early stage market. + 34:15 + no + + <p>Adam Marchick, CEO &amp; co-founder of Alpine AI, discusses pioneering vocal analytics, making a better experience for digital commerce on vocal platforms, and operating in an early stage market.</p> +<ul> +<li><a href="https://alpine.ai/">Alpine AI</a></li> +<li><a href="https://twitter.com/adammstanford">Adam on Twitter</a></li> +</ul> +<p>Thank you Alpine AI for providing a <a href="https://alpine.ai/present-effective-voice-podcast/">transcript of today's episode</a></p> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Adam Marchick, CEO & co-founder of Alpine AI, discusses pioneering vocal analytics, making a better experience for digital commerce on vocal platforms, and operating in an early stage market.

+ + + +

Thank you Alpine AI for providing a transcript of today's episode

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Adam Marchick, CEO & co-founder of Alpine AI, discusses pioneering vocal analytics, making a better experience for digital commerce on vocal platforms, and operating in an early stage market.

+ + + +

Thank you Alpine AI for providing a transcript of today's episode

+ +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rpX_AtIt + + ]]> + + + + 267: Familiar With the Market (Sara Tateno) + https://podcast.thoughtbot.com/267 + aa66212b-94a9-465a-9ba2-55854a7a69d3 + Mon, 19 Mar 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Sara Tateno, founder and CEO of Happity, shares her journey from BBC Radio, to coding bootcamp, to startup founder. + 31:01 + no + + <p>Sara Tateno, founder and CEO of Happity, shares her journey from BBC Radio, to coding bootcamp, to startup founder.</p> +<ul> +<li><a href="https://www.happity.co.uk/">Happity</a></li> +<li><a href="https://www.bbc.co.uk/programmes/b006wkfp">Radio 1's Essential Mix</a></li> +<li><a href="https://www.mumsintechnology.co.uk/">Mums in Tech</a></li> +<li><a href="http://www.makersacademy.com/">Makers Academy</a></li> +<li><a href="https://www.thinktrigg.com/pages/trigg-tracker">Trigg Life Mapper</a></li> +<li><a href="https://ignite.io/">Ignite Accelerator</a></li> +<li><a href="https://twitter.com/SaraTateno">Sara on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Sara Tateno, founder and CEO of Happity, shares her journey from BBC Radio, to coding bootcamp, to startup founder.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sara Tateno, founder and CEO of Happity, shares her journey from BBC Radio, to coding bootcamp, to startup founder.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+lZ5jgYDD + + ]]> + + + + 266: Destination Driven (Ernesto Moreno) + https://podcast.thoughtbot.com/266 + f85b627c-d342-474b-a2a9-f8bc27994ffd + Tue, 13 Mar 2018 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Ernesto Moreno, business coach, entrepreneur, & restaurateur, joins Chad to discuss transforming a restaurant using lean methodology, focusing on your strengths, and finding creativity in running a business. + 35:38 + no + + <p>Ernesto Moreno, business coach, entrepreneur, &amp; restaurateur, joins Chad to discuss transforming a restaurant using lean methodology, focusing on your strengths, and finding creativity in running a business.</p> +<ul> +<li><a href="https://en.wikipedia.org/wiki/Arepa">Arepas</a></li> +<li><a href="http://theleanstartup.com/principles">Lean Startup Methodology</a></li> +<li><a href="http://amzn.to/2tw3baB"><em>The E-Myth Revisited</em></a>- Michael E. Gerber</li> +<li><a href="http://amzn.to/2FxwkYP"><em>The ONE Thing</em></a>- Gary Keller</li> +<li><a href="http://arepaandco.com/">Arepa &amp; Co.</a></li> +<li><a href="https://twitter.com/Ernestoria">Ernesto on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Ernesto Moreno, business coach, entrepreneur, & restaurateur, joins Chad to discuss transforming a restaurant using lean methodology, focusing on your strengths, and finding creativity in running a business.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ernesto Moreno, business coach, entrepreneur, & restaurateur, joins Chad to discuss transforming a restaurant using lean methodology, focusing on your strengths, and finding creativity in running a business.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cAdO0CAE + + ]]> + + + + 265: Loosening My Hold (Tracy Osborn) + https://podcast.thoughtbot.com/265 + b2ef7abb-cb25-4f9a-86bb-522943737867 + Mon, 05 Mar 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Tracy Osborn, author and the creator of WeddingLovely, joins Chad to talk about juggling projects, redefining your core customer base, the feeling of giving up control when hiring, and publishing via Kickstarter. + 38:05 + no + + <p>Tracy Osborn, author and the creator of WeddingLovely, joins Chad to talk about juggling projects, redefining your core customer base, the feeling of giving up control when hiring, and publishing via Kickstarter.</p> +<ul> +<li><a href="https://weddinglovely.com/">WeddingLovely</a></li> +<li><a href="http://amzn.to/2oE5xPi"><em>Hello Web App</em></a></li> +<li><a href="http://www.businessinsider.com/chart-of-the-day-the-startup-curve-2012-3">The Startup Curve</a></li> +<li><a href="https://tutorial.djangogirls.org/en/">Django Girls Tutorial</a></li> +<li><a href="http://amzn.to/2GTZ9ed"><em>Hello Web App: Intermediate Concepts</em></a></li> +<li><a href="http://amzn.to/2EZq2Re"><em>Hello Web Design</em></a></li> +<li><a href="https://thoughtbot.com/learn#books">thoughtbot Books</a></li> +<li><a href="https://hellowebbooks.com/">Hello Web Books</a></li> +<li><a href="http://giantrobots.fm/72">Nathan Barry on <em>Giant Robots</em></a></li> +<li><a href="https://limedaring.com/">Limedaring.com</a></li> +<li><a href="https://twitter.com/limedaring">Tracy on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Tracy Osborn, author and the creator of WeddingLovely, joins Chad to talk about juggling projects, redefining your core customer base, the feeling of giving up control when hiring, and publishing via Kickstarter.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Tracy Osborn, author and the creator of WeddingLovely, joins Chad to talk about juggling projects, redefining your core customer base, the feeling of giving up control when hiring, and publishing via Kickstarter.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rYqYMxiA + + ]]> + + + + 264: Having a Realistic Mindset (Allen Pike) + https://podcast.thoughtbot.com/264 + 4507592b-8a31-49e6-a14f-a167f6e50528 + Tue, 27 Feb 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad discusses reflection & goal planning, the scope of internal projects, and balancing time & team structure for both client & product work with Allen Pike, CEO & co-founder of Steamclock Software. + 40:48 + no + + <p>Chad discusses reflection &amp; goal planning, the scope of internal projects, and balancing time &amp; team structure for both client &amp; product work with Allen Pike, CEO &amp; co-founder of Steamclock Software.</p> +<ul> +<li><a href="https://www.steamclock.com/">Steamclock Software</a></li> +<li><a href="https://www.steamclock.com/weddingdj/">WeddingDJ</a></li> +<li><a href="http://randsinrepose.com/archives/stables-and-volatiles/">Stables and Volatiles</a></li> +<li><a href="https://en.wikipedia.org/wiki/Dunbar%27s_number">Dunbar's Number</a></li> +<li><a href="https://twitter.com/apike">Allen on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad discusses reflection & goal planning, the scope of internal projects, and balancing time & team structure for both client & product work with Allen Pike, CEO & co-founder of Steamclock Software.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad discusses reflection & goal planning, the scope of internal projects, and balancing time & team structure for both client & product work with Allen Pike, CEO & co-founder of Steamclock Software.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+AjI-_OXU + + ]]> + + + + 263: The Stuff of Science Fiction (George Brocklehurst) + https://podcast.thoughtbot.com/263 + ca9e153a-a797-4209-8267-571a490a5fe6 + Mon, 19 Feb 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by George Brocklehurst, development director of thoughtbot NYC, to discuss the methodologies, tools, and use cases in working with machine learning. + 22:46 + no + + <p>Chad is joined by George Brocklehurst, development director of thoughtbot NYC, to discuss the methodologies, tools, and use cases in working with machine learning.</p> +<ul> +<li><a href="https://robots.thoughtbot.com/what-is-machine-learning">What is Machine Learning?</a>- George Brocklehurst</li> +<li><a href="https://en.wikipedia.org/wiki/Named-entity_recognition">Named-Entity Recognition</a></li> +<li><a href="https://nlp.stanford.edu/software/CRF-NER.shtml">Stanford Named Entity Recognizer</a></li> +<li><a href="http://pytorch.org/">PyTorch</a></li> +<li><a href="https://airbrake.io/">Hoptoad (now Airbrake)</a></li> +<li><a href="https://blog.floydhub.com/turning-design-mockups-into-code-with-deep-learning/">Turning Design Mockups Into Code With Deep Learning</a>- Emil Wallner</li> +<li><a href="https://www.coursera.org/learn/machine-learning">Machine Learning Course</a> on Coursera</li> +<li><a href="http://www.fast.ai/">fast.ai</a></li> +<li><a href="http://amzn.to/2C3wQaf"><em>Fundamentals of Machine Learning for Predictive Data Analytics</em></a>- John D. Kelleher</li> +<li><a href="https://robots.thoughtbot.com/named-entity-recognition">Named Entity Recognition: Downloading Recipes</a></li> +<li><a href="https://www.kaggle.com/competitions">Kaggle Competitions</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by George Brocklehurst, development director of thoughtbot NYC, to discuss the methodologies, tools, and use cases in working with machine learning.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by George Brocklehurst, development director of thoughtbot NYC, to discuss the methodologies, tools, and use cases in working with machine learning.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tDLfkCAe + + ]]> + + + + 262: The Thought Behind the Bot + https://podcast.thoughtbot.com/262 + 8c069e44-8fb5-41c3-b54e-db205f37aa7d + Mon, 12 Feb 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + In 2003, five friends came together to form thoughtbot. In this special episode, we take a look back on the founding of thoughtbot, and it's first years, told from the perspective of the original founders and early partners. From their first meeting in college, to the dramatic first work-experience that led them to create thoughtbot, to the eventual breakup and reformation, we explore the events that led thoughtbot to become the company it is today. + 57:06 + no + + <p>In 2003, five friends came together to form thoughtbot. In this special episode, we take a look back on the founding of thoughtbot, and it's first years, told from the perspective of the original founders and early partners. From their first meeting in college, to the dramatic first work-experience that led them to create thoughtbot, to the eventual breakup and reformation, we explore the events that led thoughtbot to become the company it is today.</p> +<ul> +<li><a href="https://www.linkedin.com/in/mattdtucker/">Matt Tucker</a></li> +<li><a href="https://www.linkedin.com/in/calvin-swaim-31337815/">Calvin Swaim</a></li> +<li><a href="https://www.linkedin.com/in/willie-conrad-1808451/">Willie Conrad</a></li> +<li><a href="https://thoughtbot.com/">thoughtbot</a></li> +<li><a href="https://www.wpi.edu/">Worcester Polytechnic Institute</a></li> +<li><a href="http://www.imdb.com/title/tt0387168/?ref_=fn_al_tt_1"><em>Disc</em></a></li> +<li><a href="http://pinospizza.com/">Pino's Pizza</a></li> +<li><a href="https://youtu.be/Gzj723LkRJY">Build a Blog Demo</a></li> +<li><a href="https://www.shotgunflat.com/">Shotgunflat</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + In 2003, five friends came together to form thoughtbot. In this special episode, we take a look back on the founding of thoughtbot, and it's first years, told from the perspective of the original founders and early partners. From their first meeting in college, to the dramatic first work-experience that led them to create thoughtbot, to the eventual breakup and reformation, we explore the events that led thoughtbot to become the company it is today.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In 2003, five friends came together to form thoughtbot. In this special episode, we take a look back on the founding of thoughtbot, and it's first years, told from the perspective of the original founders and early partners. From their first meeting in college, to the dramatic first work-experience that led them to create thoughtbot, to the eventual breakup and reformation, we explore the events that led thoughtbot to become the company it is today.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rWUTH4kg + + ]]> + + + + 261: A Human Future (Pamela Pavliscak) + https://podcast.thoughtbot.com/261 + c4bebdf5-5464-479a-aba9-443f08083738 + Mon, 05 Feb 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Pamela Pavliscak, founder of Change Sciences, about human-centered design thinking, and incorporating well-being & ethics as a measure of success. + 35:55 + no + + <p>Chad is joined by Pamela Pavliscak, founder of Change Sciences, about human-centered design thinking, and incorporating well-being &amp; ethics as a measure of success.</p> +<ul> +<li><a href="https://www.changesciences.com/">Change Sciences</a></li> +<li><a href="http://vsdesign.org/">Value Sensitive Design</a></li> +<li><a href="http://amzn.to/2DYrbY9"><em>Nudge</em></a>- Richard H. Thaler</li> +<li><a href="http://standards.ieee.org/develop/indconn/ec/autonomous_systems.html">IEEE Global Initiative on Ethics of Autonomous and Intelligent Systems</a></li> +<li><a href="https://robots.thoughtbot.com/we-build-politics">Ethics in thoughtbot's Purpose Statement</a></li> +<li><a href="http://amzn.to/2DPnAZ0"><em>Designing for Happiness</em></a>- Pamela Pavliscak</li> +<li><a href="https://www.pratt.edu/">Pratt Institute</a></li> +<li><a href="https://soundingbox.com/">SoundingBox</a></li> +<li><a href="https://twitter.com/paminthelab">Pamela on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Pamela Pavliscak, founder of Change Sciences, about human-centered design thinking, and incorporating well-being & ethics as a measure of success.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Pamela Pavliscak, founder of Change Sciences, about human-centered design thinking, and incorporating well-being & ethics as a measure of success.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+DalviORQ + + ]]> + + + + 260: Treating Yourself Like a Business (Andrew Carroll) + https://podcast.thoughtbot.com/260 + c06e7de1-2811-48a9-9900-4bfc4c4d320c + Mon, 29 Jan 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Andrew Carroll, CPA and independent CFO, to discuss how the new tax regulations will affect freelancers, small business, & solopreneurs. + 39:23 + no + + <p>Chad is joined by Andrew Carroll, CPA and independent CFO, to discuss how the new tax regulations will affect freelancers, small business, &amp; solopreneurs. Also, recommended strategies for savings, retirement, and investing for entrepreneurs.</p> +<ul> +<li><a href="https://cfoandrew.com/">CFO Andrew</a></li> +<li><a href="https://quickbooks.intuit.com/online/">Quickbooks Online</a></li> +<li><a href="https://gusto.com/">Gusto</a></li> +<li><a href="https://twitter.com/cfoandrew">Andrew on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Andrew Carroll, CPA and independent CFO, to discuss how the new tax regulations will affect freelancers, small business, & solopreneurs. Also, recommended strategies for savings, retirement, and investing for entrepreneurs.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Andrew Carroll, CPA and independent CFO, to discuss how the new tax regulations will affect freelancers, small business, & solopreneurs. Also, recommended strategies for savings, retirement, and investing for entrepreneurs.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+k1s7CXJ5 + + ]]> + + + + 259: Carve Your Own Story (Curtis Herbert) + https://podcast.thoughtbot.com/259 + 5ebff0b8-8512-427e-9455-63c006e8402b + Mon, 22 Jan 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Curtis Herbert, independent app developer and creator of Slopes, to discuss balancing client and product work, the pros & cons of a seasonal app, the importance of outreach, and experimenting with non-traditional business models. + 43:14 + no + + <p>Chad is joined by Curtis Herbert, independent app developer and creator of Slopes, to discuss balancing client and product work, the pros &amp; cons of a seasonal app, the importance of outreach, and experimenting with non-traditional business models.</p> +<ul> +<li><a href="https://getslopes.com/">Slopes</a></li> +<li><a href="https://breakpointstudio.com/">Breakpoint Studio</a></li> +<li><a href="https://twitter.com/parrots">Curtis on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Curtis Herbert, independent app developer and creator of Slopes, to discuss balancing client and product work, the pros & cons of a seasonal app, the importance of outreach, and experimenting with non-traditional business models.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Curtis Herbert, independent app developer and creator of Slopes, to discuss balancing client and product work, the pros & cons of a seasonal app, the importance of outreach, and experimenting with non-traditional business models.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+IemcxeYV + + ]]> + + + + 258: Doing it on Principle (Max Seelemann) + https://podcast.thoughtbot.com/258 + 5c518ff0-9d02-4ee5-acaf-82a21bd886a5 + Mon, 15 Jan 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Max Seelemann, co-founder and lead developer of Ulysses, to discuss app-review, the complexities of multi-platform releases, initiating a full-app rewrite, and switching to a subscription pricing-model. + 39:04 + no + + <p>Chad is joined by Max Seelemann, co-founder and lead developer of Ulysses, to discuss app-review, the complexities of multi-platform releases, initiating a full-app rewrite, and switching to a subscription pricing-model.</p> +<ul> +<li><a href="https://ulyssesapp.com/">Ulysses Writing App</a></li> +<li><a href="https://en.wikipedia.org/wiki/Sunk_cost">Sunk Cost Fallacy</a></li> +<li><a href="https://ulyssesapp.com/blog/2017/08/ulysses-switches-to-subscription/">'Ulysses Switches to Subscription' Blog Post</a></li> +<li><a href="https://twitter.com/macguru17">Max on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Max Seelemann, co-founder and lead developer of Ulysses, to discuss app-review, the complexities of multi-platform releases, initiating a full-app rewrite, and switching to a subscription pricing-model.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Max Seelemann, co-founder and lead developer of Ulysses, to discuss app-review, the complexities of multi-platform releases, initiating a full-app rewrite, and switching to a subscription pricing-model.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pmMbBf-G + + ]]> + + + + 257: Mapping the World For Parents (Anne Halsall) + https://podcast.thoughtbot.com/257 + 3d9f2e29-b742-47e6-853b-024dc6d700d9 + Mon, 08 Jan 2018 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Anne Halsall, co-founder and Chief Product Officer of Winnie, discussing intention in branding, assumptions about features, balancing local and remote work, and quantifying growth. + 42:45 + no + + <p>Chad is joined by Anne Halsall, co-founder and Chief Product Officer of Winnie, discussing intention in branding, assumptions about features, balancing local and remote work, and quantifying growth.</p> +<ul> +<li><a href="https://winnie.com/">Winnie</a></li> +<li><a href="https://twitter.com/Winnie">Winnie on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Anne Halsall, co-founder and Chief Product Officer of Winnie, discussing intention in branding, assumptions about features, balancing local and remote work, and quantifying growth.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Anne Halsall, co-founder and Chief Product Officer of Winnie, discussing intention in branding, assumptions about features, balancing local and remote work, and quantifying growth.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kwCDmFeQ + + ]]> + + + + 256: Stay Hungry, Stay Learning (Hosted by Alan Wick) + https://podcast.thoughtbot.com/256 + d1d209d2-bbdb-443d-a44b-f7aa7bb14a98 + Mon, 18 Dec 2017 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + The tables are flipped and Chad is interviewed by Alan Wick, at our Playbook Launch Party, on the lessons learned from starting thoughtbot, company methodology, and looking towards the challenges & opportunities of the future. + 47:35 + no + + <p>The tables are flipped and Chad is interviewed by Alan Wick, at our Playbook Launch Party, on the lessons learned from starting thoughtbot, company methodology, and looking towards the challenges &amp; opportunities of the future.</p> +<ul> +<li><a href="https://thoughtbot.com/playbook">thoughtbot Playbook</a></li> +<li><a href="http://amzn.to/2irbW0m"><em>Crossing the Chasm</em></a>- Geoffrey A. Moore</li> +<li><a href="http://giantrobots.fm/8debc9d2">Geoffrey Moore on <em>Giant Robots</em></a></li> +<li><a href="https://thoughtbot.com/purpose">thoughtbot /purpose</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> +<p>Thank you to <a href="http://www.storyblocks.com/robots">Storyblocks</a> for sponsoring today's episode!</p> + + + + The tables are flipped and Chad is interviewed by Alan Wick, at our Playbook Launch Party, on the lessons learned from starting thoughtbot, company methodology, and looking towards the challenges & opportunities of the future.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + The tables are flipped and Chad is interviewed by Alan Wick, at our Playbook Launch Party, on the lessons learned from starting thoughtbot, company methodology, and looking towards the challenges & opportunities of the future.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_cA3TYLl + + ]]> + + + + 255: Solving the Whole Problem (Maria Parker) + https://podcast.thoughtbot.com/255 + 5b9bd120-e1da-4c6f-b87d-9b116f1ad558 + Mon, 04 Dec 2017 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad chats with Maria Parker, CEO of Cruzbike, about running your first Kickstarter, issues with scaling production, and the challenge of shifting public perceptions. + 41:29 + no + + <p>Chad chats with Maria Parker, CEO of Cruzbike, about running your first Kickstarter, issues with scaling production, and the challenge of shifting public perceptions.</p> +<ul> +<li><a href="http://hopscotchdesignfest.com/">Hopscotch Design Festival</a></li> +<li><a href="https://cruzbike.com/">Cruzbike</a></li> +<li><a href="http://amzn.to/2nm76Ea"><em>Crossing the Chasm</em></a>- Geoffrey A. Moore</li> +<li><a href="https://www.facebook.com/3ktoacure">3000 Miles to a Cure</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> +<p>Thank you to <a href="http://www.storyblocks.com/robots">Storyblocks</a> for sponsoring today's episode!</p> + + + + Chad chats with Maria Parker, CEO of Cruzbike, about running your first Kickstarter, issues with scaling production, and the challenge of shifting public perceptions.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad chats with Maria Parker, CEO of Cruzbike, about running your first Kickstarter, issues with scaling production, and the challenge of shifting public perceptions.

+ + + +

Become a Sponsor of Giant Robots!

+ +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bN6OWBHp + + ]]> + + + + 254: Product and Vision (Chris Savage & Brendan Schwartz) + https://podcast.thoughtbot.com/254 + d524c9c3-f450-4db1-a842-4241d86b2c63 + Mon, 20 Nov 2017 00:00:00 -0500 + thoughtbot + + full + 7 + thoughtbot + Chad talks with Chris & Brendan, co-founders of Wistia, about building/launching new products, hiring, and managing company identity & vision. + 44:13 + no + + <p>Chad talks with Chris Savage &amp; Brendan Schwartz, co-founders of Wistia, about building/launching new products, hiring, and managing company identity &amp; vision.</p> +<ul> +<li><a href="https://wistia.com/">Wistia</a></li> +<li><a href="http://giantrobots.fm/65">Chris &amp; Brendan on <em>Giant Robots</em></a></li> +<li><a href="https://wistia.com/wistiafest">Wistiafest</a> video marketing conference</li> +<li><a href="https://wistia.com/soapbox">Soapbox</a></li> +</ul> +<p>Thank you to <a href="http://www.storyblocks.com/robots">Storyblocks</a> for sponsoring today's episode!</p> + + + + Chad talks with Chris Savage & Brendan Schwartz, co-founders of Wistia, about building/launching new products, hiring, and managing company identity & vision.

+ + + +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with Chris Savage & Brendan Schwartz, co-founders of Wistia, about building/launching new products, hiring, and managing company identity & vision.

+ + + +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Pgifo-cP + + ]]> + + + + 253: iPads For Camp (Aleen Simms) + https://podcast.thoughtbot.com/253 + cc96e2f3-1a51-4a27-9429-c59cd18feb88 + Fri, 03 Nov 2017 13:45:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Aleen Simms, an organizer for App Camp For Girls, to discuss the importance and logistics of their new Indiegogo Campaign. + 27:22 + no + + <p>Chad is joined by Aleen Simms, an organizer for App Camp For Girls, to discuss the importance and logistics of their new Indiegogo Campaign.</p> +<p>Head over to the <a href="http://tbot.io/appcamp">App Camp Indiegogo</a> via tbot.io/appcamp to have your donation matched today!</p> +<ul> +<li><a href="http://ac4g.org">App Camp for Girls</a></li> +<li><a href="http://appcamp4girls.com/volunteer/">Volunteer!</a></li> +<li><a href="http://appcamp4girls.com/volunteer-form">Volunteer Interest Form</a></li> +<li><a href="https://www.theincomparable.com/">The Incomparable Podcast</a></li> +<li><a href="https://www.theincomparable.com/person/aleen-simms/">Aleen on The Incomparable Network</a></li> +<li><a href="https://www.relay.fm/originality/">Originality Podcast</a></li> +<li><a href="https://twitter.com/aleen">Aleen on Twitter</a></li> +</ul> +<p>Check out our newest podcast, <a href="https://medium.com/@upcase/">Crossroads</a>.</p> +<p>Thank you to <a href="http://www.storyblocks.com/robots">Storyblocks</a> for sponsoring today's episode!</p> + + + + Chad is joined by Aleen Simms, an organizer for App Camp For Girls, to discuss the importance and logistics of their new Indiegogo Campaign.

+ +

Head over to the App Camp Indiegogo via tbot.io/appcamp to have your donation matched today!

+ + + +

Check out our newest podcast, Crossroads.

+ +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Aleen Simms, an organizer for App Camp For Girls, to discuss the importance and logistics of their new Indiegogo Campaign.

+ +

Head over to the App Camp Indiegogo via tbot.io/appcamp to have your donation matched today!

+ + + +

Check out our newest podcast, Crossroads.

+ +

Thank you to Storyblocks for sponsoring today's episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+HYWsTn2p + + ]]> + + + + 252: Strategic Foresight (Amy Webb) + https://podcast.thoughtbot.com/252 + f033fb7f-3be9-4c22-ad68-1d6f87fe02d1 + Tue, 24 Oct 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Amy Webb, Professor at the Stern School of Business NYU and Founder & Quantitative Futurist at The Future Today Institute, to discuss distilling trends, incremental decision making, and the role of organizational management on the outcome of a company's future. + 39:57 + no + + <p>Chad is joined by Amy Webb, Professor at the Stern School of Business NYU and Founder &amp; Quantitative Futurist at The Future Today Institute, to discuss distilling trends, incremental decision making, and the role of organizational management on the outcome of a company's future.</p> +<ul> +<li><a href="https://futuretodayinstitute.com/">Future Today Institute</a></li> +<li><a href="http://amzn.to/2zkxwI5"><em>The Innovator's Dilemma</em></a>- Clayton M. Christensen</li> +<li><a href="http://exponent.fm/">Exponent Podcast</a></li> +<li><a href="https://www.nytimes.com/2016/03/25/technology/microsoft-created-a-twitter-bot-to-learn-from-users-it-quickly-became-a-racist-jerk.html">Microsoft Tay Bot</a></li> +<li><a href="https://futuretodayinstitute.com/mu_uploads/2017/04/Botness-Scale-FTI-2016.pdf">Botness Scale</a></li> +<li><a href="http://amzn.to/2h1rkxe"><em>The Signals Are Talking: Why Today’s Fringe Is Tomorrow’s Mainstream</em></a>- Amy Webb</li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Amy Webb, Professor at the Stern School of Business NYU and Founder & Quantitative Futurist at The Future Today Institute, to discuss distilling trends, incremental decision making, and the role of organizational management on the outcome of a company's future.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Amy Webb, Professor at the Stern School of Business NYU and Founder & Quantitative Futurist at The Future Today Institute, to discuss distilling trends, incremental decision making, and the role of organizational management on the outcome of a company's future.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+qIq_0wVy + + ]]> + + + + 251: More Than Just Pretty Pictures (Jarrod Drysdale) + https://podcast.thoughtbot.com/251 + 697dab69-c902-4c0e-baf3-cb8ec2fa6ede + Mon, 09 Oct 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by designer and author Jarrod Drysdale to discuss lessons learned from shutting down Cascade, writing about design, cultivating content for your audience, and design's evolving role within organizations. + 40:53 + no + + <p>Chad is joined by designer and author Jarrod Drysdale to discuss lessons learned from shutting down Cascade, writing about design, cultivating content for your audience, and design's evolving role within organizations.</p> +<ul> +<li><a href="http://giantrobots.fm/33">Jarrod on <em>Giant Robots</em></a></li> +<li><a href="https://proximityschool.com/theory-sprints/">TheorySprints</a> design course</li> +<li><a href="http://www.studiofellow.com/">Studio Fellow</a></li> +<li><a href="https://proximityschool.com/">Proximity School of Design</a></li> +<li><a href="https://twitter.com/studiofellow">Jarrod on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by designer and author Jarrod Drysdale to discuss lessons learned from shutting down Cascade, writing about design, cultivating content for your audience, and design's evolving role within organizations.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by designer and author Jarrod Drysdale to discuss lessons learned from shutting down Cascade, writing about design, cultivating content for your audience, and design's evolving role within organizations.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Vzv-lzaz + + ]]> + + + + 250: The Internet of Payments (Anders Brownworth) + https://podcast.thoughtbot.com/250 + 6ef0d259-0686-4440-b364-0c8927bdc781 + Tue, 26 Sep 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Anders Brownworth, Chief Evangelist at Circle, to discuss zero-cost transaction fees, cryptocurrency, and re-envisioning modern payment systems. + 35:43 + no + + <p>Chad is joined by Anders Brownworth, Chief Evangelist at Circle, to discuss zero-cost transaction fees, cryptocurrency, and re-envisioning modern payment systems.</p> +<ul> +<li><a href="https://www.circle.com/en">Circle</a></li> +<li><a href="http://www.claytonchristensen.com/key-concepts/">Disruptive Innovation</a>- Clayton Christensen</li> +<li><a href="http://5by5.tv/criticalpath">The Critical Path Podcast</a></li> +<li><a href="https://twitter.com/anders94">Anders on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Anders Brownworth, Chief Evangelist at Circle, to discuss zero-cost transaction fees, cryptocurrency, and re-envisioning modern payment systems.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Anders Brownworth, Chief Evangelist at Circle, to discuss zero-cost transaction fees, cryptocurrency, and re-envisioning modern payment systems.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cmzDNplt + + ]]> + + + + 249: The Business of Buying (Thomas Smale) + https://podcast.thoughtbot.com/249 + c1eb787c-123b-4959-9ec6-d97f13bc241e + Tue, 12 Sep 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Thomas Smale, founder of FE International to discuss valuations, selling SaaS businesses, and tips to make your product more attractive to potential buyers. + 37:12 + no + + <p>Chad is joined by Thomas Smale, founder of FE International to discuss valuations, selling SaaS businesses, and tips to make your product more attractive to potential buyers.</p> +<ul> +<li><a href="https://youtu.be/3LiY4uhuTeQ"><em>The Developer's Path</em> Video</a></li> +<li><a href="https://feinternational.com/">FE International</a></li> +<li><a href="https://feinternational.com/blog/saas-metrics-how-to-value-saas-business/">SaaS Valuations: How to Value a SaaS Business in 2017</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Thomas Smale, founder of FE International to discuss valuations, selling SaaS businesses, and tips to make your product more attractive to potential buyers.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Thomas Smale, founder of FE International to discuss valuations, selling SaaS businesses, and tips to make your product more attractive to potential buyers.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_pwLv_Ob + + ]]> + + + + 248: Crossing the Chasm (Geoffrey A. Moore) + https://podcast.thoughtbot.com/248 + cad296cb-166a-47a7-a851-1de03efae503 + Mon, 28 Aug 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by author Geoffrey A. Moore to discuss the concepts in Crossing the Chasm and how they relate to scaling consulting. + 39:32 + no + + + <p>Chad is joined by author Geoffrey A. Moore to discuss the concepts in <em>Crossing the Chasm</em> and how they relate to scaling consulting.</p> +<ul> +<li><a href="https://thoughtbot.com/podcast-transcripts/geoffrey-moore-crossing-the-chasm">The full transcript for this episode</a></li> +<li><a href="http://amzn.to/2irbW0m"><em>Crossing the Chasm</em></a>- Geoffrey A. Moore</li> +<li><a href="https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action">&quot;How Great Leaders Inspire Action&quot;</a>- Simon Sinek TED Talk</li> +<li><a href="http://giantrobots.fm/episodes/c8edb52a/244-a-fork-in-the-road-seth-godin">Seth Godin on <em>Giant Robots</em></a></li> +<li><a href="http://amzn.to/2w0YB3o"><em>Behind the Cloud</em></a>- Marc Benioff, Carlye Adler</li> +<li><a href="http://amzn.to/2w8cj3b"><em>Zone to Win</em></a>- Geoffrey A. Moore</li> +<li><a href="https://youtu.be/EUXnJraKM3k">Microsoft Re-Designs the iPod Packaging</a></li> +<li><a href="http://www.geoffreyamoore.com/">Geoffrey's Homepage</a></li> +<li><a href="https://www.linkedin.com/in/geoffreyamoore/">Geoffrey on Linkedin</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by author Geoffrey A. Moore to discuss the concepts in Crossing the Chasm and how they relate to scaling consulting.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by author Geoffrey A. Moore to discuss the concepts in Crossing the Chasm and how they relate to scaling consulting.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+fw4ianG_ + + ]]> + + + + 247: The Developer’s Path (Laurie Young) + https://podcast.thoughtbot.com/247 + 9fe2876f-f1b2-4ef1-b74d-436047a1f787 + Tue, 15 Aug 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Laurie Young to discuss The Developer's Path, a panel discussion hosted at thoughtbot London on how companies and developers can work together to achieve reciprocal growth. + 35:31 + no + + <p>Chad is joined by Laurie Young to discuss The Developer's Path, a panel discussion hosted at thoughtbot London on how companies and developers can work together to achieve reciprocal growth.</p> +<ul> +<li><a href="https://youtu.be/3LiY4uhuTeQ">Developer's Path Panel Video</a></li> +<li><a href="https://thoughtbot.com/playbook/our-company/apprenticeship">thoughtbot Playbook- Apprenticeship</a></li> +<li><a href="http://www.makersacademy.com/">Makers Academy</a></li> +<li><a href="http://railsgirls.london/">Rails Girls London</a></li> +<li><a href="http://railsbridge.org/">RailsBridge</a></li> +<li><a href="http://overtheair.org/blog/">Over the Air</a></li> +<li><a href="https://www.apprentice.io/">Apprentice.io</a></li> +<li><a href="https://twitter.com/wildfalcon">Laurie on Twitter</a></li> +</ul> + + + + Chad is joined by Laurie Young to discuss The Developer's Path, a panel discussion hosted at thoughtbot London on how companies and developers can work together to achieve reciprocal growth.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Laurie Young to discuss The Developer's Path, a panel discussion hosted at thoughtbot London on how companies and developers can work together to achieve reciprocal growth.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0rCqCUJU + + ]]> + + + + 246: Becoming the 'Yes' Person (Sara Chipps) + https://podcast.thoughtbot.com/246 + 224da145-bb5c-4c73-b628-d910866a09e3 + Fri, 28 Jul 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Sara Chipps, cofounder of Girl Develop It & CEO of Jewelbots, to discuss integrating with custom hardware, building a community of young coders, working with retailers, and branding. + 40:22 + no + + <p>Chad is joined by Sara Chipps, cofounder of Girl Develop It &amp; CEO of Jewelbots, to discuss integrating with custom hardware, building a community of young coders, working with retailers, and branding.</p> +<ul> +<li><a href="http://giantrobots.fm/169">Sara on Giant Robots</a></li> +<li><a href="https://jewelbots.com/">Jewelbots</a></li> +<li><a href="https://medium.com/@quymbee/worldwide-jewelbotsbuild-makers-unite-1c999ab42956">#JewelbotsBuild</a></li> +<li><a href="http://www.firstlegoleague.org/about-fll">First Lego League</a></li> +<li><a href="https://www.radicalcandor.com/blog/tag/podcast/">Radical Candor Podcast</a></li> +<li><a href="http://amzn.to/2uCq7Um"><em>Zero to One</em></a>- Peter Thiel</li> +<li><a href="https://www.instagram.com/p/BN237yAlcHD/">Robot Conference Room Signage</a></li> +<li><a href="https://twitter.com/sarajchipps">Sara on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Sara Chipps, cofounder of Girl Develop It & CEO of Jewelbots, to discuss integrating with custom hardware, building a community of young coders, working with retailers, and branding.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Sara Chipps, cofounder of Girl Develop It & CEO of Jewelbots, to discuss integrating with custom hardware, building a community of young coders, working with retailers, and branding.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+nszF3xmr + + ]]> + + + + 245: F is for Feelings (Gregg Pollack) + https://podcast.thoughtbot.com/245 + b3be5743-466b-4f12-b22c-4047ed691fde + Thu, 13 Jul 2017 13:30:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Code School & Envy Labs founder Gregg Pollack to discuss optimal work environments and building a company to support Open Source Projects. + 55:45 + no + + <p>Chad is joined by Code School &amp; Envy Labs founder Gregg Pollack to discuss optimal work environments and building a company to support Open Source Projects.</p> +<ul> +<li><a href="http://giantrobots.fm/49">Gregg on Giant Robots</a></li> +<li><a href="http://starterstudio.com/">Starter Studio</a></li> +<li><a href="http://brenebrown.com/">Brené Brown</a></li> +<li><a href="https://thehumanelement.com/">The Human Element</a></li> +<li><a href="http://codepop.com/">Code Pop</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="http://www.cbsnews.com/news/the-37signals-secret-to-success-sell-your-by-products/">Sell Your By-Products</a></li> +<li><a href="https://thoughtbot.com/upcase/dive-into-neovim">Dive into Neovim</a> on Upcase</li> +<li><a href="https://www.greggpollack.com/">Gregg's Blog</a></li> +<li><a href="https://twitter.com/greggpollack">Gregg on Twitter</a></li> +<li><a href="https://tbot.io/path">Panel Discussion: The Developer’s Path</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Code School & Envy Labs founder Gregg Pollack to discuss optimal work environments and building a company to support Open Source Projects.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Code School & Envy Labs founder Gregg Pollack to discuss optimal work environments and building a company to support Open Source Projects.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Dhkohw5- + + ]]> + + + + 244: A Fork in the Road (Seth Godin) + https://podcast.thoughtbot.com/244 + c55a1e20-526c-48c0-b6f1-eac00e805ab1 + Tue, 04 Jul 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by author, blogger, entrepreneur, and marketer Seth Godin to discuss the organizational introspection required to move from the cutting edge to the mainstream. + 32:50 + no + + + <p>Chad is joined by author, blogger, entrepreneur, and marketer Seth Godin to discuss the organizational introspection required to move from the cutting edge to the mainstream.</p> +<ul> +<li><a href="https://thoughtbot.com/podcast-transcripts/seth-godin-a-fork-in-the-road">The full transcript for this episode</a></li> +<li><a href="http://giantrobots.fm/81">Seth on Giant Robots</a></li> +<li><a href="http://amzn.to/2tIW7XH"><em>Tribes: We Need You to Lead Us</em></a>: Seth Godin</li> +<li><a href="http://amzn.to/2sEXRMz"><em>The Dip</em></a>: Seth Godin</li> +<li><a href="https://thoughtbot.com/playbook">thoughtbot Playbook</a></li> +<li><a href="http://amzn.to/2tCk2aN"><em>Crossing the Chasm</em></a>: Geoffrey A. Moore</li> +<li><a href="https://www.rga.com/">R/GA</a></li> +<li><a href="https://books.google.com/ngrams/info">Google Ngram Viewer</a></li> +<li><a href="http://www.jeffkoons.com/">Jeff Koons</a></li> +<li><a href="https://altmba.com/">altMBA</a></li> +<li><a href="https://themarketingseminar.com/">The Marketing Seminar</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by author, blogger, entrepreneur, and marketer Seth Godin to discuss the organizational introspection required to move from the cutting edge to the mainstream.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by author, blogger, entrepreneur, and marketer Seth Godin to discuss the organizational introspection required to move from the cutting edge to the mainstream.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ONK8Sw_Q + + ]]> + + + + 243: Mostly Local (Mike McKenna) + https://podcast.thoughtbot.com/243 + 5508a20c-0f9e-4c85-8620-2c149cf3b381 + Tue, 27 Jun 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Mike McKenna, CEO of Shotgunflat, to discuss cultivating a business in the town in which one grew up, working with family, the effect of adding a sales team to a consultancy, and the legislation of craft-brewing. + 36:45 + no + + <p>Chad is joined by Mike McKenna, CEO of Shotgunflat, to discuss cultivating a business in the town in which one grew up, working with family, the effect of adding a sales team to a consultancy, and the legislation of craft-brewing.</p> +<ul> +<li><a href="https://www.shotgunflat.com/">Shotgunflat</a></li> +<li><a href="http://www.thirstygoat.net/home">Thirsty Goat Brewing</a></li> +<li><a href="http://www.mtnwknd.com/">Mtn Wknd</a></li> +<li><a href="https://twitter.com/shotgunmm">Mike on Twitter</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Mike McKenna, CEO of Shotgunflat, to discuss cultivating a business in the town in which one grew up, working with family, the effect of adding a sales team to a consultancy, and the legislation of craft-brewing.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Mike McKenna, CEO of Shotgunflat, to discuss cultivating a business in the town in which one grew up, working with family, the effect of adding a sales team to a consultancy, and the legislation of craft-brewing.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+KZUnG4b4 + + ]]> + + + + 242: Too Dressed Up For The Internet (Kim Goulbourne) + https://podcast.thoughtbot.com/242 + bae2b3e3-45d6-4d14-92d2-f1246dd7461e + Mon, 19 Jun 2017 00:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by thoughtbot designer Kim Goulbourne to discuss inspiration, side projects, and winning a Webby Award! + 24:22 + no + + <p>Chad is joined by thoughtbot designer Kim Goulbourne to discuss inspiration, side projects, and winning a Webby Award!</p> +<ul> +<li><a href="http://www.webbyawards.com/">The Webby Awards</a></li> +<li><a href="http://www.bitterrenter.nyc/">Bitter Renter</a></li> +<li><a href="http://www.webbyawards.com/winners/2017/websites/general-website/real-estate/bitter-renter/">&quot;Suck it Zillow. I won!&quot;</a></li> +<li><a href="http://www.noquestionsasked.nyc/">No Questions Asked</a></li> +<li><a href="http://madebybourn.com/">Made By Bourn</a></li> +<li><a href="https://twitter.com/kimgoulb">Kim on Twitter</a></li> +<li><a href="https://www.instagram.com/madebybourn/">Kim on Instagram</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by thoughtbot designer Kim Goulbourne to discuss inspiration, side projects, and winning a Webby Award!

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by thoughtbot designer Kim Goulbourne to discuss inspiration, side projects, and winning a Webby Award!

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+urdXu2P3 + + ]]> + + + + 241: I Don’t Like Talking to Computers (Nick Charlton) + https://podcast.thoughtbot.com/241 + 8b401912-a1e6-49d8-bade-d56c7a0427f4 + Wed, 07 Jun 2017 16:00:00 -0400 + thoughtbot + + full + 7 + thoughtbot + Chad is joined by Nick Charlton, thoughtbot developer and co-host of the Build Phase podcast, to give their impressions on all the news out of the WWDC17 Keynote & Platforms State of the Union. + 1:02:14 + no + + <p>Chad is joined by Nick Charlton, thoughtbot developer and co-host of the Build Phase podcast, to give their impressions on all the news out of the WWDC17 Keynote &amp; Platforms State of the Union.</p> +<ul> +<li><a href="http://buildphase.fm/">Build Phase</a></li> +<li><a href="https://www.apple.com/apple-events/june-2017/">WWDC17 Keynote</a></li> +<li><a href="https://developer.apple.com/videos/play/wwdc2017/102/">Platforms State of the Union</a></li> +<li><a href="http://bikeshed.fm/112">I/O '17 discussion on <em>The Bike Shed</em></a></li> +<li><a href="https://developer.apple.com/documentation/foundation/archives_and_serialization/encoding_and_decoding_custom_types">Encoding and Decoding Custom Types</a></li> +<li><a href="https://github.com/thoughtbot/Argo">Argo</a></li> +</ul> +<p>Become a <a href="https://thoughtbot.com/sponsorship">Sponsor</a> of Giant Robots!</p> + + + + Chad is joined by Nick Charlton, thoughtbot developer and co-host of the Build Phase podcast, to give their impressions on all the news out of the WWDC17 Keynote & Platforms State of the Union.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad is joined by Nick Charlton, thoughtbot developer and co-host of the Build Phase podcast, to give their impressions on all the news out of the WWDC17 Keynote & Platforms State of the Union.

+ + + +

Become a Sponsor of Giant Robots!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+OgBj9c6w + + ]]> + + + + 240: Handing Over the Reins + https://podcast.thoughtbot.com/240 + 2333848a-1679-4875-b020-f83cc3cee33e + Mon, 05 Jun 2017 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben outlines his next steps, reflects on his time at thoughtbot, and hands the proverbial podcast reins over to Chad. + 55:38 + no + + <p>Ben outlines his next steps, reflects on his time at thoughtbot, and hands the proverbial podcast reins over to Chad.</p> +<ul> +<li><a href="http://giantrobots.fm/197">Ballroom Dancing Onboarding on <em>Giant Robots</em></a></li> +<li><a href="http://artofproductpodcast.com/">The Art of Product Podcast</a></li> +<li><a href="https://youtu.be/tXRhtWERUDE">Art of Vim Intro</a>- Ben acting in a smoking jacket</li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://youtu.be/DC-pQPq0acs">Refactoring From Good to Great</a></li> +<li><a href="https://robots.thoughtbot.com/blurred-lines">&quot;Blurred Lines&quot;</a>- Kyle Fiedler</li> +</ul> + + + + Ben outlines his next steps, reflects on his time at thoughtbot, and hands the proverbial podcast reins over to Chad.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben outlines his next steps, reflects on his time at thoughtbot, and hands the proverbial podcast reins over to Chad.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+CDsYa4Co + + ]]> + + + + 239: Change is in the Air + https://podcast.thoughtbot.com/239 + c2eb4e91-9ae0-44af-9c07-cfad5c7fad0d + Mon, 29 May 2017 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben bids adieu to thoughtbot, and outlines his plans, hopes, and fears for the future. + 35:51 + no + + <p>Ben bids adieu to thoughtbot, and outlines his plans, hopes, and fears for the future.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-239">FormKeep</a></li> +<li><a href="http://businessofsoftware.org/2013/02/gail-goodman-constant-contact-how-to-negotiate-the-long-slow-saas-ramp-of-death/">How to negotiate the Long, Slow, SaaS Ramp of Death</a>- Gail Goodman</li> +<li><a href="http://www.softwarebyrob.com/2015/03/26/the-stairstep-approach-to-bootstrapping/">The Stairstep Approach to Bootstrapping</a>- Rob Walling</li> +<li><a href="http://giantrobots.fm/62">Natalie Nagele on <em>Giant Robots</em></a></li> +<li><a href="http://www.vimuniversity.com/">Vim University</a></li> +</ul> + + + + Ben bids adieu to thoughtbot, and outlines his plans, hopes, and fears for the future.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben bids adieu to thoughtbot, and outlines his plans, hopes, and fears for the future.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+08w10OiP + + ]]> + + + + 238: The Graph is Beautiful + https://podcast.thoughtbot.com/238 + ea90001e-408d-4373-8557-543270a59fb6 + Mon, 22 May 2017 16:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Derrick gets technical about Drip's performance optimization, and reflects on pre-conceived opinions in regards to tactical & strategic planning after receiving some constructive criticism. + 19:51 + no + + <p>Derrick gets technical about Drip's performance optimization, and reflects on pre-conceived opinions in regards to tactical &amp; strategic planning after receiving some constructive criticism.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-238">FormKeep</a></li> +<li><a href="https://twitter.com/r00k/status/855447427553402880">Studio Pics</a></li> +<li><a href="https://newrelic.com/">New Relic</a></li> +</ul> + + + + Derrick gets technical about Drip's performance optimization, and reflects on pre-conceived opinions in regards to tactical & strategic planning after receiving some constructive criticism.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick gets technical about Drip's performance optimization, and reflects on pre-conceived opinions in regards to tactical & strategic planning after receiving some constructive criticism.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0d0ia61z + + ]]> + + + + 237: Steve Jobs Used Slides + https://podcast.thoughtbot.com/237 + 09cc78e2-2d09-4510-b875-45ec76b8dd7f + Fri, 28 Apr 2017 23:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben and Derrick recount their experiences and lessons learned speaking at MicroConf. + 34:13 + no + + <p>Ben and Derrick recount their experiences and lessons learned speaking at MicroConf.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-237">FormKeep</a></li> +<li><a href="http://www.microconf.com/">MicroConf</a></li> +<li><a href="https://en.wikipedia.org/wiki/Hedonic_treadmill">Hedonic Treadmill</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + Ben and Derrick recount their experiences and lessons learned speaking at MicroConf.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Derrick recount their experiences and lessons learned speaking at MicroConf.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hAzJQQM1 + + ]]> + + + + 236: Care For Customer Support (Spencer Fry) + https://podcast.thoughtbot.com/236 + 36db1fa1-648d-4662-91ec-092eb024d816 + Fri, 21 Apr 2017 23:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben is joined this week by Spencer Fry, founder of TypeFrag, Carbonmade, Uncover, and Coach, to discuss carryover lessons of successful startups. + 37:38 + no + + <p>Ben is joined this week by Spencer Fry, founder of TypeFrag, Carbonmade, Uncover, and Coach, to discuss carryover lessons of successful startups.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-236">FormKeep</a></li> +<li><a href="http://www.typefrag.com/">TypeFrag</a></li> +<li><a href="https://carbonmade.com/">Carbonmade</a></li> +<li><a href="https://www.withcoach.com/">Coach</a></li> +<li><a href="http://www.spencerfry.com/why-i-started-coach"><em>Why I Started Coach</em></a></li> +<li><a href="http://www.spencerfry.com/being-a-solo-founder"><em>Being a Solo Founder</em></a></li> +<li><a href="http://notationcapital.com/">Notation Capital</a></li> +<li><a href="http://www.spencerfry.com/perseverance-pays-off"><em>Perseverance Pays Off</em></a></li> +<li><a href="http://amzn.to/2q7vS7o"><em>Creativity, Inc.</em></a></li> +<li><a href="https://twitter.com/spencerfry">Spencer on Twitter</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + Ben is joined this week by Spencer Fry, founder of TypeFrag, Carbonmade, Uncover, and Coach, to discuss carryover lessons of successful startups.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined this week by Spencer Fry, founder of TypeFrag, Carbonmade, Uncover, and Coach, to discuss carryover lessons of successful startups.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+sEqnP0ii + + ]]> + + + + 235: Meta Talk Process + https://podcast.thoughtbot.com/235 + 79df6b25-dee4-4b39-9122-73b7287dc8eb + Wed, 12 Apr 2017 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + As we prepare for MicroConf, Ben takes a new tact on his talk after giving an early demo, and Derrick recounts a positive pair-programming experience. + 31:01 + no + + <p>As we prepare for MicroConf, Ben takes a new tact on his talk after giving an early demo, and Derrick recounts a positive pair-programming experience.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-235">FormKeep</a></li> +<li><a href="https://screenhero.com/">Screenhero</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + As we prepare for MicroConf, Ben takes a new tact on his talk after giving an early demo, and Derrick recounts a positive pair-programming experience.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + As we prepare for MicroConf, Ben takes a new tact on his talk after giving an early demo, and Derrick recounts a positive pair-programming experience.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+QApkdh-l + + ]]> + + + + 234: Secret Features + https://podcast.thoughtbot.com/234 + 71a092e2-7aa0-4eae-908e-bb3073c9142b + Wed, 05 Apr 2017 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + On FormKeep, Ben implements custom redirects on form submissions and starts a test to remove up-front credit card collection, as well as discusses evaluation of feature requests. On Drip, Derrick walks through the app with new devs, considers on-boarding automation, and continues his refactoring project. + 29:46 + no + + <p>On FormKeep, Ben implements custom redirects on form submissions and starts a test to remove up-front credit card collection, as well as discusses evaluation of feature requests. On Drip, Derrick walks through the app with new devs, considers on-boarding automation, and continues his refactoring project.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-234">FormKeep</a></li> +<li><a href="https://github.com/thoughtbot/laptop">thoughtbot Laptop Setup Script</a></li> +<li><a href="http://www.kytrinyx.com/talks/therapeutic-refactoring/">Therapeutic Refactoring</a></li> +<li><a href="https://github.com/kickstarter/rack-attack">Rack::Attack</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + On FormKeep, Ben implements custom redirects on form submissions and starts a test to remove up-front credit card collection, as well as discusses evaluation of feature requests. On Drip, Derrick walks through the app with new devs, considers on-boarding automation, and continues his refactoring project.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On FormKeep, Ben implements custom redirects on form submissions and starts a test to remove up-front credit card collection, as well as discusses evaluation of feature requests. On Drip, Derrick walks through the app with new devs, considers on-boarding automation, and continues his refactoring project.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+lNezlnNd + + ]]> + + + + 233: Insert Mode is the Worst Mode + https://podcast.thoughtbot.com/233 + 6c39e486-6acc-4498-8904-ed208899d650 + Mon, 27 Mar 2017 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Derrick welcomes new Javascript and Rails developers to Drip. Ben prepares a content deal and interviews a Content Manager for Upcase, discusses the benefits and methodology to Vim proficiency, works on an integration with Wistia, and ponders growing / selling apps. + 27:34 + no + + <p>Derrick welcomes new Javascript and Rails developers to Drip. Ben prepares a content deal and interviews a Content Manager for Upcase, discusses the benefits and methodology to Vim proficiency, works on an integration with Wistia, and ponders growing / selling apps.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-233">FormKeep</a></li> +<li><a href="http://www.inc.com/laura-garnett/how-to-find-your-genius-zone.html">How to Find Your Genius Zone</a>- Laura Garnett</li> +<li><a href="http://www.benorenstein.com/blog/surviving-your-first-week-in-vim">Surviving Your First Week in Vim</a></li> +<li><a href="https://wistia.com/">Wistia</a></li> +<li><a href="http://www.startupsfortherestofus.com/">Startups For the Rest of Us</a></li> +<li><a href="http://blog.codetree.com/articles/what-its-like-buying-a-128k-side-project.html">What It's Like Buying a $128k Side Project</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + Derrick welcomes new Javascript and Rails developers to Drip. Ben prepares a content deal and interviews a Content Manager for Upcase, discusses the benefits and methodology to Vim proficiency, works on an integration with Wistia, and ponders growing / selling apps.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick welcomes new Javascript and Rails developers to Drip. Ben prepares a content deal and interviews a Content Manager for Upcase, discusses the benefits and methodology to Vim proficiency, works on an integration with Wistia, and ponders growing / selling apps.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JR88YRnD + + ]]> + + + + 232: Don't Be Boring + https://podcast.thoughtbot.com/232 + 6d4f215a-1941-4705-bab8-cc779a2d0905 + Wed, 22 Mar 2017 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + As Ben and Derrick prepare their talks for MicroConf, Ben shares his tips and habits for talk preparation and public speaking. + 27:24 + no + + <p>As Ben and Derrick prepare their talks for MicroConf, Ben shares his tips and habits for talk preparation and public speaking.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-232">FormKeep</a></li> +<li><a href="https://github.com/speaking-for-hackers/speaking-for-hackers-book/blob/master/before-your-talk.txt#L327">Ben's Pre-Talk Checklist</a></li> +<li><a href="https://youtu.be/l9JXH7JPjR4">How to Talk to Developers</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + As Ben and Derrick prepare their talks for MicroConf, Ben shares his tips and habits for talk preparation and public speaking.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + As Ben and Derrick prepare their talks for MicroConf, Ben shares his tips and habits for talk preparation and public speaking.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+lY_NvyuX + + ]]> + + + + 231: Who Likes Using Ugly Software? + https://podcast.thoughtbot.com/231 + f4466d5d-1f52-4081-b1b1-dd888e4d4bf7 + Tue, 14 Mar 2017 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben & Derrick reflect on the S3 outage and how it affected their services, and muse on managing user perceptions. Derrick submits a talk to MicroConf on what it means to be "customer driven", and begins a refactoring effort to rework Drip's integration system. On Upcase, Ben integrates a referral widget, and enables subscription pausing, while on FormKeep he fixes a trial plan selection bug. + 33:01 + no + + <p>Ben &amp; Derrick reflect on the S3 outage and how it affected their services, and muse on managing user perceptions. Derrick submits a talk to MicroConf on what it means to be &quot;customer driven&quot;, and begins a refactoring effort to rework Drip's integration system. On Upcase, Ben integrates a referral widget, and enables subscription pausing, while on FormKeep he fixes a trial plan selection bug.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-231">FormKeep</a></li> +<li><a href="https://aws.amazon.com/message/41926/">AWS S3 Disruption Postmortem</a></li> +<li><a href="http://techblog.netflix.com/2011/07/netflix-simian-army.html">The Netflix Simian Army</a></li> +<li><a href="https://github.com/Netflix/chaosmonkey">Chaos Monkey</a></li> +<li><a href="https://github.com/thiagopradi/octopus">Octopus Gem</a></li> +<li><a href="http://www.microconf.com/">MicroConf</a></li> +<li><a href="https://www.referralsaasquatch.com/">Referral SaaSquatch</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + Ben & Derrick reflect on the S3 outage and how it affected their services, and muse on managing user perceptions. Derrick submits a talk to MicroConf on what it means to be "customer driven", and begins a refactoring effort to rework Drip's integration system. On Upcase, Ben integrates a referral widget, and enables subscription pausing, while on FormKeep he fixes a trial plan selection bug.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben & Derrick reflect on the S3 outage and how it affected their services, and muse on managing user perceptions. Derrick submits a talk to MicroConf on what it means to be "customer driven", and begins a refactoring effort to rework Drip's integration system. On Upcase, Ben integrates a referral widget, and enables subscription pausing, while on FormKeep he fixes a trial plan selection bug.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+kYXU91FT + + ]]> + + + + 230: Sales Through Education (Anna Jacobsen) + https://podcast.thoughtbot.com/230 + 3bf2feea-075d-441b-82af-a98bcbe64f06 + Mon, 06 Mar 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben & Derrick welcome Anna Jacobsen, Education Director at Drip, to discuss customer demos / onboarding, sales and retention strategies, customer success, and best practices within Drip. + 32:55 + no + + <p>Ben &amp; Derrick welcome Anna Jacobsen, Education Director at Drip, to discuss customer demos / onboarding, sales and retention strategies, customer success, and best practices within Drip.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-230">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="https://www.convertedu.com/courses/drip-consultant-certification/">Drip Certification Course</a></li> +<li><a href="https://vimeo.com/165218551">Lessons Learned From a Year of Product Demos at Drip</a>- Anna Jacobsen @ MicroConf</li> +<li><a href="http://giantrobots.fm/113">Rob Walling on <em>Giant Robots</em></a></li> +<li><a href="https://calendly.com/">Calendly</a></li> +<li><a href="https://59daysofcode.org/who-we-are/">59 Days of Code</a></li> +<li><a href="https://hashtagfresno.com/">Hashtag Fresno</a></li> +<li><a href="https://twitter.com/annagjacobsen">Anna on Twitter</a></li> +</ul> +<p>Thank you to our sponsor this week, <a href="https://freshbooks.com/GIANTROBOTS">FreshBooks</a></p> + + + + Ben & Derrick welcome Anna Jacobsen, Education Director at Drip, to discuss customer demos / onboarding, sales and retention strategies, customer success, and best practices within Drip.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben & Derrick welcome Anna Jacobsen, Education Director at Drip, to discuss customer demos / onboarding, sales and retention strategies, customer success, and best practices within Drip.

+ + + +

Thank you to our sponsor this week, FreshBooks

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+6tvwK7P_ + + ]]> + + + + 229: We Need More Counters + https://podcast.thoughtbot.com/229 + 8bb128fc-b048-4cbb-adbd-50b8f2d4a2ed + Mon, 27 Feb 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + On FormKeep, Ben runs an A/B test on trial length and adds a short onboarding survey, meanwhile wrapping up team signups and working on a content licensing deal for Upcase. Derrick reports back from his machine learning class, and discusses an issue in quality assurance testing. + 33:33 + no + + <p>On FormKeep, Ben runs an A/B test on trial length and adds a short onboarding survey, meanwhile wrapping up team signups and working on a content licensing deal for Upcase. Derrick reports back from his machine learning class, and discusses an issue in quality assurance testing.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-229">FormKeep</a></li> +<li><a href="http://accountdetails.info/">Account Details</a></li> +<li><a href="http://www.microconf.com/starter/">MicroConf: Starter Edition</a></li> +<li><a href="https://vimeo.com/74338272">Jason Cohen - Designing the Ideal Bootstrapped Business</a>: MicroConf Talk</li> +<li><a href="https://stripe.com/radar">Stripe Radar</a></li> +</ul> + + + + On FormKeep, Ben runs an A/B test on trial length and adds a short onboarding survey, meanwhile wrapping up team signups and working on a content licensing deal for Upcase. Derrick reports back from his machine learning class, and discusses an issue in quality assurance testing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On FormKeep, Ben runs an A/B test on trial length and adds a short onboarding survey, meanwhile wrapping up team signups and working on a content licensing deal for Upcase. Derrick reports back from his machine learning class, and discusses an issue in quality assurance testing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+5mjiYvl4 + + ]]> + + + + 228: Start in Beginner Mode + https://podcast.thoughtbot.com/228 + 015047f9-d032-40ba-becd-4fc561e0765d + Mon, 20 Feb 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Derrick travels to Portland to visit fellow bootstrapper friends, Ben recounts his recent conference travel, and a discussion of their most pivotal hires as well as account rescue techniques. + 24:59 + no + + <p>Derrick travels to Portland to visit fellow bootstrapper friends, Ben recounts his recent conference travel, and a discussion of their most pivotal hires as well as account rescue techniques.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-228">FormKeep</a></li> +<li><a href="https://bigsnowtinyconf.com/">Big Snow Tiny Conf</a></li> +<li><a href="https://blog.baremetrics.com/the-startup-echo-chamber-is-making-you-deaf-771eec220181#.m1z4fv4xr">The Startup Echo Chamber is Making You Deaf</a></li> +<li><a href="https://vimeo.com/165218551">Lessons Learned From a Year of Product Demos at Drip</a>- Anna Jacobsen @ MicroConf</li> +</ul> + + + + Derrick travels to Portland to visit fellow bootstrapper friends, Ben recounts his recent conference travel, and a discussion of their most pivotal hires as well as account rescue techniques.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick travels to Portland to visit fellow bootstrapper friends, Ben recounts his recent conference travel, and a discussion of their most pivotal hires as well as account rescue techniques.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+x3vERNlo + + ]]> + + + + 227: We Don't Do Fractional Pennies + https://podcast.thoughtbot.com/227 + 19ff5df5-60cb-4b97-bd07-dcb3d132aace + Mon, 13 Feb 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Derrick celebrates a great shipping week, completing both 'live segments' and a Drip certification course. Ben recounts the rollout & results of the Upcase + Tapas promotion, and reflects on its successes and possible pitfalls. + 30:26 + no + + <p>Derrick celebrates a great shipping week, completing both 'live segments' and a Drip certification course. Ben recounts the rollout &amp; results of the Upcase + Tapas promotion, and reflects on its successes and possible pitfalls.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-227">FormKeep</a></li> +<li><a href="http://giantrobots.fm/208">Efficiency Starts With a Haircut</a></li> +<li><a href="http://images.thoughtbot.com/podcasts/giantrobots/shippinghat.jpg">Shipping Hat</a></li> +<li><a href="https://firecider.com/">Fire Cider</a></li> +<li><a href="https://www.convertedu.com/courses/drip-consultant-certification/">Drip Certification Course</a></li> +<li><a href="https://thoughtbot.com/upcase/tapas-for-one">Upcase + Ruby Tapas</a></li> +</ul> + + + + Derrick celebrates a great shipping week, completing both 'live segments' and a Drip certification course. Ben recounts the rollout & results of the Upcase + Tapas promotion, and reflects on its successes and possible pitfalls.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick celebrates a great shipping week, completing both 'live segments' and a Drip certification course. Ben recounts the rollout & results of the Upcase + Tapas promotion, and reflects on its successes and possible pitfalls.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Mbdrgm-7 + + ]]> + + + + 226: There Are So Many Edge-Cases + https://podcast.thoughtbot.com/226 + b0111506-7dfe-448c-865a-d5c8f036a369 + Mon, 06 Feb 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben presses to meet the Upcase & Tapas launch deadline, and shares some lessons learned from its preparation, promotion, and launch. On Drip, Derrick rolls out more UI updates, is looking to hire JavaScript and Rails engineers, and details his hiring & interview process. + 22:44 + no + + <p>Ben presses to meet the Upcase &amp; Tapas launch deadline, and shares some lessons learned from its preparation, promotion, and launch. On Drip, Derrick rolls out more UI updates, is looking to hire JavaScript and Rails engineers, and details his hiring &amp; interview process.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-226">FormKeep</a></li> +<li><a href="https://thoughtbot.com/upcase/tapas">Upcase &amp; Tapas</a></li> +<li><a href="https://www.leadpages.net/blog/category/conversioncast/">ConversionCast</a></li> +</ul> + + + + Ben presses to meet the Upcase & Tapas launch deadline, and shares some lessons learned from its preparation, promotion, and launch. On Drip, Derrick rolls out more UI updates, is looking to hire JavaScript and Rails engineers, and details his hiring & interview process.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben presses to meet the Upcase & Tapas launch deadline, and shares some lessons learned from its preparation, promotion, and launch. On Drip, Derrick rolls out more UI updates, is looking to hire JavaScript and Rails engineers, and details his hiring & interview process.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+-jVWniBb + + ]]> + + + + 225: Abuse the Sunk-Cost Fallacy + https://podcast.thoughtbot.com/225 + a38b135f-906c-4213-a7fe-98fef1e900ff + Mon, 30 Jan 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben halts the search for a marketer to instead hire a sales consultant and focus on growth himself, and announces a collaboration with Ruby Tapas. Derrick enrolls in a machine learning class, and contemplates Drip team & work structure. + 31:43 + no + + <p>Ben halts the search for a marketer to instead hire a sales consultant and focus on growth himself, and announces a collaboration with Ruby Tapas. Derrick enrolls in a machine learning class, and contemplates Drip team &amp; work structure.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-225">FormKeep</a></li> +<li><a href="https://m.signalvnoise.com/what-my-calendar-looks-like-11724d3a8b7e#.a8tp32f3w">What My Calendar Looks Like</a>- Jason Fried</li> +<li><a href="https://thoughtbot.com/upcase/tapas">Upcase + Tapas Promo</a></li> +<li><a href="https://www.rubytapas.com/">Ruby Tapas</a></li> +<li><a href="http://nathanbarry.com/launch/">Mastering Product Launches</a></li> +<li><a href="https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae">How We Structure Our Work and Teams at Basecamp</a></li> +<li><a href="https://wistia.com/">Wistia</a></li> +<li><a href="https://www.coursera.org/learn/machine-learning">Machine Learning Class</a></li> +</ul> +<p>Thank you to our sponsor this week <a href="https://well.tc/mdtrobots">Mobile Dev + Test Conference from Techwell</a></p> + + + + Ben halts the search for a marketer to instead hire a sales consultant and focus on growth himself, and announces a collaboration with Ruby Tapas. Derrick enrolls in a machine learning class, and contemplates Drip team & work structure.

+ + + +

Thank you to our sponsor this week Mobile Dev + Test Conference from Techwell

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben halts the search for a marketer to instead hire a sales consultant and focus on growth himself, and announces a collaboration with Ruby Tapas. Derrick enrolls in a machine learning class, and contemplates Drip team & work structure.

+ + + +

Thank you to our sponsor this week Mobile Dev + Test Conference from Techwell

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+UxcNCz-i + + ]]> + + + + 224: Sharpen Your Saw + https://podcast.thoughtbot.com/224 + 83071de9-8031-49a0-81a8-9205a310ce30 + Mon, 23 Jan 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Derrick takes a solo retreat to reflect on new goals for Drip, and draws up preliminary plans for scaling team size / structure, as well as speeding up velocity through parallelism. Ben shares his experience with GrowthHackers Projects, hides the lowest plan and implements an automated annual upgrade reminder, pitches a content partnership for Upcase, considers a thoughtbot products bundle, and realizes a need for a mentor. + 33:17 + no + + <p>Derrick takes a solo retreat to reflect on new goals for Drip, and draws up preliminary plans for scaling team size / structure, as well as speeding up velocity through parallelism. Ben shares his experience with GrowthHackers Projects, hides the lowest plan and implements an automated annual upgrade reminder, pitches a content partnership for Upcase, considers a thoughtbot products bundle, and realizes a need for a mentor.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-224">FormKeep</a></li> +<li><a href="https://gumroad.com/l/retreats">The Zen Founder Guide to Founder Retreats</a></li> +<li><a href="http://zenfounder.com/">ZenFounder Podcast</a></li> +<li><a href="http://www.appntd.com/">Appointed</a></li> +<li><a href="https://growthhackers.com/welcome">GrowthHackers</a></li> +<li><a href="https://www.omnigroup.com/omnifocus">OmniFocus</a></li> +<li><a href="https://www.rubytapas.com/">Ruby Tapas</a></li> +<li><a href="http://amzn.to/2iyUKWb"><em>Predictable Revenue</em></a>- Aaron Ross &amp; Marylou Tyler</li> +</ul> + + + + Derrick takes a solo retreat to reflect on new goals for Drip, and draws up preliminary plans for scaling team size / structure, as well as speeding up velocity through parallelism. Ben shares his experience with GrowthHackers Projects, hides the lowest plan and implements an automated annual upgrade reminder, pitches a content partnership for Upcase, considers a thoughtbot products bundle, and realizes a need for a mentor.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick takes a solo retreat to reflect on new goals for Drip, and draws up preliminary plans for scaling team size / structure, as well as speeding up velocity through parallelism. Ben shares his experience with GrowthHackers Projects, hides the lowest plan and implements an automated annual upgrade reminder, pitches a content partnership for Upcase, considers a thoughtbot products bundle, and realizes a need for a mentor.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+h5gklYgJ + + ]]> + + + + 223: Work Deterrent System + https://podcast.thoughtbot.com/223 + da537642-1468-4495-a88b-a3f369822964 + Mon, 09 Jan 2017 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben & Derrick discuss music in the workplace, optimizing Redis, reaching larger markets beyond early adopters, and standing out in job application e-mails. + 25:12 + no + + <p>Ben &amp; Derrick discuss music in the workplace, optimizing Redis, reaching larger markets beyond early adopters, and standing out in job application e-mails.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-223">FormKeep</a></li> +<li><a href="http://99percentinvisible.org/episode/unpleasant-design-hostile-urban-architecture/">Hostile Architecture on 99% Invisible</a></li> +<li><a href="https://github.com/twitter/twemproxy">twemproxy</a></li> +<li><a href="https://www.amazon.com/gp/product/0062292986?tag=thoughtbot-20"><em>Crossing the Chasm</em></a>: Geoffrey A. Moore</li> +</ul> + + + + Ben & Derrick discuss music in the workplace, optimizing Redis, reaching larger markets beyond early adopters, and standing out in job application e-mails.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben & Derrick discuss music in the workplace, optimizing Redis, reaching larger markets beyond early adopters, and standing out in job application e-mails.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+zbs3XWav + + ]]> + + + + 222: Honesty Bait + https://podcast.thoughtbot.com/222 + dd3f00c8-47c7-42ed-a93e-3937275e1730 + Mon, 19 Dec 2016 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Derrick considers learning a new language to be prepared for scaling Drip's optimization, and gives new details on the tech used to streamline queries for large accounts. Ben breaks down his post to finding the best candidate for product Head of Marketing, and pointers on developing an entrepreneur's mindset. + 30:20 + no + + <p>Derrick considers learning a new language to be prepared for scaling Drip's optimization, and gives new details on the tech used to streamline queries for large accounts. Ben breaks down his post to finding the best candidate for product Head of Marketing, and pointers on developing an entrepreneur's mindset.</p> +<ul> +<li><a href="https://thoughtbot.com/podcasts">Podcast Swag Bundles</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-222">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="https://robots.thoughtbot.com/you-should-take-a-codecation">You Should Take A Codecation</a></li> +<li><a href="http://bikeshed.fm/52">You're an Elixir Developer Now</a> on <em>The Bike Shed</em> Podcast</li> +<li><a href="http://bikeshed.fm/57">Mutability Ruins the Whole Party</a>- José Valim on <em>The Bike Shed</em> Podcast</li> +<li><a href="https://robots.thoughtbot.com/we-re-hiring-a-head-of-marketing-for-our-products">We're Hiring a Head of Marketing for our Products</a></li> +<li><a href="https://www.amazon.com/gp/product/0615373968/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0615373968&amp;linkCode=as2&amp;tag=thoughtbot-20&amp;linkId=93ce501126995ae1753f8f14012eba3e"><em>Start Small, Stay Small</em></a>- Rob Walling</li> +<li><a href="http://giantrobots.fm/113">Minimum Path to Awesome</a>- Rob Walling on <em>Giant Robots</em></li> +</ul> + + + + Derrick considers learning a new language to be prepared for scaling Drip's optimization, and gives new details on the tech used to streamline queries for large accounts. Ben breaks down his post to finding the best candidate for product Head of Marketing, and pointers on developing an entrepreneur's mindset.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick considers learning a new language to be prepared for scaling Drip's optimization, and gives new details on the tech used to streamline queries for large accounts. Ben breaks down his post to finding the best candidate for product Head of Marketing, and pointers on developing an entrepreneur's mindset.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+vLYDpZ1J + + ]]> + + + + 221: Power in Mimicry + https://podcast.thoughtbot.com/221 + cd63f0c4-7574-41d2-9dd6-3aec64459797 + Mon, 12 Dec 2016 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben discusses the lessons of mimicked learning and tempering of judgmental thinking gleaned from a sports book, and muses on how to apply them to career advice. On Drip, faced with a mountain of catch-up work after the holiday, Derek confronts scalability. + 35:02 + no + + <p>Ben discusses the lessons of mimicked learning and tempering of judgmental thinking gleaned from a sports book, and muses on how to apply them to career advice. On Drip, faced with a mountain of catch-up work after the holiday, Derek confronts scalability.</p> +<ul> +<li><a href="https://thoughtbot.com/podcasts">Podcast Swag Bundles</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-221">FormKeep</a></li> +<li><a href="https://www.amazon.com/gp/product/0679778314/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0679778314&amp;linkCode=as2&amp;tag=thoughtbot-20&amp;linkId=42a415b5c311c531331bbb40f9b23893"><em>The Inner Game of Tennis</em></a></li> +<li><a href="http://www.inc.com/magazine/20110301/making-money-small-business-advice-from-jason-fried.html">How to Get Good at Making Money</a>- Jason Fried</li> +<li><a href="https://github.com/thoughtbot/guides/tree/master/style">thoughtbot Style Guide</a></li> +<li><a href="https://robots.thoughtbot.com/we-re-hiring-a-head-of-marketing-for-our-products">We're Hiring a Head of Marketing for Our Products</a></li> +<li><a href="http://www.benorenstein.com/">Ben's Personal Site</a></li> +<li><a href="https://meetedgar.com/">Edgar</a></li> +<li><a href="http://giantrobots.fm/174">Laura Roeder on <em>Giant Robots</em></a></li> +</ul> + + + + Ben discusses the lessons of mimicked learning and tempering of judgmental thinking gleaned from a sports book, and muses on how to apply them to career advice. On Drip, faced with a mountain of catch-up work after the holiday, Derek confronts scalability.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben discusses the lessons of mimicked learning and tempering of judgmental thinking gleaned from a sports book, and muses on how to apply them to career advice. On Drip, faced with a mountain of catch-up work after the holiday, Derek confronts scalability.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+4mtEdMAh + + ]]> + + + + 220: Goin' Legit (For 2017) + https://podcast.thoughtbot.com/220 + 2178679e-1c51-4749-90c5-344f315b5863 + Tue, 06 Dec 2016 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben decides to hire a support firm, document support processes, completes the Hound pricing change, and prepares to make products their own division for next year. Meanwhile, on Drip, Derrick addresses a performance challenge. + 33:30 + no + + <p>Ben decides to hire a support firm, document support processes, completes the Hound pricing change, and prepares to make products their own division for next year. Meanwhile, on Drip, Derrick addresses a performance challenge.</p> +<ul> +<li><a href="https://thoughtbot.com/podcasts">Podcast Swag Bundles</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-220">FormKeep</a></li> +<li><a href="http://cosupport.com/">CoSupport</a></li> +<li><a href="http://bootstrappedweb.com/">Bootstrapped Web Podcast</a></li> +<li><a href="https://www.amazon.com/gp/product/0312430000/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0312430000&amp;linkCode=as2&amp;tag=thoughtbot-20&amp;linkId=54e6ab98293e7ec4baa24c3332b324db"><em>The Checklist Manifesto</em></a>: Atul Gawande</li> +<li><a href="http://www.benorenstein.com/blog/my-morning-checklist">The Checklist I Use To Start My Day</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +</ul> + + + + Ben decides to hire a support firm, document support processes, completes the Hound pricing change, and prepares to make products their own division for next year. Meanwhile, on Drip, Derrick addresses a performance challenge.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben decides to hire a support firm, document support processes, completes the Hound pricing change, and prepares to make products their own division for next year. Meanwhile, on Drip, Derrick addresses a performance challenge.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_fU5n1dp + + ]]> + + + + 219: Rails' Sidekick (Mike Perham) + https://podcast.thoughtbot.com/219 + 408c7ce9-f75d-47af-bb33-d5327ddbe2a8 + Mon, 28 Nov 2016 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben is joined by Mike Perham, author of Sidekiq, to discuss running a business solo, taking a side project from hobby to full time job, and scaling support as an app grows. + 31:20 + no + + <p>Ben is joined by Mike Perham, author of Sidekiq, to discuss running a business solo, taking a side project from hobby to full time job, and scaling support as an app grows.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-219">FormKeep</a></li> +<li><a href="https://www.indiehackers.com/businesses/sidekiq">Indie Hackers- Sidekiq</a></li> +<li><a href="http://sidekiq.org/">Sidekiq</a></li> +<li><a href="https://en.wikipedia.org/wiki/Open_core">Open Core Software Business Model</a></li> +<li><a href="http://www.mikeperham.com/">MikePerham.com</a></li> +<li><a href="http://www.mikeperham.com/2016/02/09/kill-your-dependencies/">Kill Your Dependencies</a></li> +</ul> + + + + Ben is joined by Mike Perham, author of Sidekiq, to discuss running a business solo, taking a side project from hobby to full time job, and scaling support as an app grows.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by Mike Perham, author of Sidekiq, to discuss running a business solo, taking a side project from hobby to full time job, and scaling support as an app grows.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Q7O6yf60 + + ]]> + + + + 218: A Spark of Inspiration + https://podcast.thoughtbot.com/218 + 2828edb9-296e-44ff-8b2d-c67b2d27306b + Mon, 21 Nov 2016 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + On Drip, Derrick launches a free tier, and utilizes credit card anti-fraud measures. Ben publicly launches FormLinter, pauses exploring new product ideas in favor of giving attention to existing ones, and starts to rebuild the product team. They also discuss the merits of remote vs in-person collaboration, the pros and cons of open offices, and dealing with interruptions from notifications and meetings. + 35:37 + no + + <p>On Drip, Derrick launches a free tier, and utilizes credit card anti-fraud measures. Ben publicly launches FormLinter, pauses exploring new product ideas in favor of giving attention to existing ones, and starts to rebuild the product team. They also discuss the merits of remote vs in-person collaboration, the pros and cons of open offices, and dealing with interruptions from notifications and meetings.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-218">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="https://stripe.com/radar">Stripe: Radar</a></li> +<li><a href="http://www.aasmnet.org/jcsm/ViewAbstract.aspx?pid=29198">Caffeine Effects on Sleep Study</a></li> +<li><a href="http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html">The Development Abstraction Layer</a>- Joel Spolsky</li> +<li><a href="https://robots.thoughtbot.com/announcing-formlinter">Announcing FormLinter</a></li> +</ul> + + + + On Drip, Derrick launches a free tier, and utilizes credit card anti-fraud measures. Ben publicly launches FormLinter, pauses exploring new product ideas in favor of giving attention to existing ones, and starts to rebuild the product team. They also discuss the merits of remote vs in-person collaboration, the pros and cons of open offices, and dealing with interruptions from notifications and meetings.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On Drip, Derrick launches a free tier, and utilizes credit card anti-fraud measures. Ben publicly launches FormLinter, pauses exploring new product ideas in favor of giving attention to existing ones, and starts to rebuild the product team. They also discuss the merits of remote vs in-person collaboration, the pros and cons of open offices, and dealing with interruptions from notifications and meetings.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+RfM1tu1o + + ]]> + + + + 217: The Object Object Object + https://podcast.thoughtbot.com/217 + bbe41658-9413-46d8-9e0c-784b105d51b7 + Mon, 14 Nov 2016 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Ben and Nick get super nerdy this week and chat about Meetspace's architecture using Go, Postgres, and HMAC including custom cookie signing, rendering, error handling, tooling, and more! + 50:51 + no + + <p>Ben and Nick get super nerdy this week and chat about Meetspace's architecture using Go, Postgres, and HMAC including custom cookie signing, rendering, error handling, tooling, and more!</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-217">FormKeep</a></li> +<li><a href="http://www.meetspaceapp.com/">Meetspace</a>- use code <code>GIANTROBOTS30</code> for 30% off your first month</li> +<li><a href="https://github.com/lib/pq">Go Postgres Driver</a></li> +<li><a href="https://godoc.org/golang.org/x/net/websocket">Google's Websocket Driver</a></li> +<li><a href="https://github.com/webrtc/adapter">WebRTC Uniform Interface</a></li> +<li><a href="http://www.meetspaceapp.com/2016/04/19/cookie-signing-postgresql.html">Secure Signed Cookies</a>- Nick Gauthier</li> +<li><a href="https://en.wikipedia.org/wiki/Hash-based_message_authentication_code">HMAC</a></li> +<li><a href="https://github.com/kisielk/errcheck">errcheck Go linter</a></li> +<li><a href="http://topfunky.com/2016/think-like-a-developer/">Think Like a Software Developer</a>- Geoffrey Grosenbach</li> +<li><a href="https://github.com/ngauthier/tubesock">Tubesock</a></li> +<li><a href="http://giantrobots.fm/96">Jeff Casimir on <em>Giant Robots</em></a></li> +<li><a href="https://twitter.com/ngauthier">Nick on Twitter</a></li> +</ul> + + + + Ben and Nick get super nerdy this week and chat about Meetspace's architecture using Go, Postgres, and HMAC including custom cookie signing, rendering, error handling, tooling, and more!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Nick get super nerdy this week and chat about Meetspace's architecture using Go, Postgres, and HMAC including custom cookie signing, rendering, error handling, tooling, and more!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+W13pakGY + + ]]> + + + + 216: The One With Laila & Brenda + https://podcast.thoughtbot.com/216 + ffb33399-87ad-4c42-b3a8-cbc6caf858d8 + Mon, 07 Nov 2016 00:00:00 -0500 + thoughtbot + + full + 6 + thoughtbot + Sadly, Ben is stuck in hammock somewhere, and we are without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila & Brenda Show! + +Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts! + 38:54 + no + + <p>Sadly, Ben is stuck in hammock somewhere, and we are without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila &amp; Brenda Show!</p> +<p>Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts!</p> +<ul> +<li><a href="http://lailaandbrenda.fm/">The Laila &amp; Brenda Show</a></li> +</ul> + + + + Sadly, Ben is stuck in hammock somewhere, and we are without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila & Brenda Show!

+ +

Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Sadly, Ben is stuck in hammock somewhere, and we are without a new episode this week. However, we would love you all to check out thoughtbot's newest podcast, interviewing inspirational designers, developers, and other makers in tech, The Laila & Brenda Show!

+ +

Give their latest episode a listen here, and if you like it subscribe to their feed however you listen to podcasts!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+J9IVpDLf + + ]]> + + + + 215: SaaS is a Marathon, Not a Sprint + https://podcast.thoughtbot.com/215 + 1d62b1c2-86c8-4be9-bb0d-e71ff3a986e6 + Mon, 31 Oct 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben and Nick chat about ways to pitch your product, working solo as well as sustainably, and the costs of doing business. + 37:11 + no + + <p>Ben and Nick chat about ways to pitch your product, working solo as well as sustainably, and the costs of doing business.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-215">FormKeep</a></li> +<li><a href="http://www.meetspaceapp.com/">Meetspace</a>- use code <code>GIANTROBOTS30</code> for 30% off your first month</li> +<li><a href="http://ngauthier.com/2016/04/staying-motivated-solo.html">Staying Motivated While Working Solo</a></li> +<li><a href="https://twitter.com/ngauthier">Nick on Twitter</a></li> +</ul> + + + + Ben and Nick chat about ways to pitch your product, working solo as well as sustainably, and the costs of doing business.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Nick chat about ways to pitch your product, working solo as well as sustainably, and the costs of doing business.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jZmusptx + + ]]> + + + + 214: My Cat is VP of Marketing (Nick Gauthier) + https://podcast.thoughtbot.com/214 + 9b7baa69-c783-4a1a-b033-41614c6629c4 + Mon, 24 Oct 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben talks to Nick Gauthier, founder of MeetSpace, about the importance of validating ideas, reading through API documentation, and pricing surveys. + 42:52 + no + + <p>Ben talks to Nick Gauthier, founder of MeetSpace, about the importance of validating ideas, reading through API documentation, and pricing surveys.</p> +<ul> +<li><a href="http://tbot.io/survey">Podcast Patreon Survey</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-214">FormKeep</a></li> +<li><a href="http://www.meetspaceapp.com/">MeetSpace</a>- use code <code>GIANTROBOTS30</code> for 30% off your first month</li> +<li><a href="https://en.wikipedia.org/wiki/Hash-based_message_authentication_code">HMAC</a></li> +<li><a href="https://github.com/hgmnz/rtfmroulette">Random Postgres Docs App</a></li> +<li><a href="https://en.wikipedia.org/wiki/Van_Westendorp%27s_Price_Sensitivity_Meter">Van Westendorp Price Sensitivity Meter</a></li> +<li><a href="http://www.meetspaceapp.com/2016/09/15/meetspace-pricing.html">How Our Users Picked Our Pricing</a></li> +<li><a href="http://golangweekly.com/">Go Newsletter</a></li> +<li><a href="http://www.saasfest.io/">SaaSFest</a></li> +<li><a href="https://twitter.com/ngauthier">Nick on Twitter</a></li> +</ul> + + + + Ben talks to Nick Gauthier, founder of MeetSpace, about the importance of validating ideas, reading through API documentation, and pricing surveys.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Nick Gauthier, founder of MeetSpace, about the importance of validating ideas, reading through API documentation, and pricing surveys.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+NcwD_A-P + + ]]> + + + + 213: Madness Free + https://podcast.thoughtbot.com/213 + 0d681ed8-24c2-4edb-a306-78aed4630083 + Mon, 17 Oct 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Derrick finds some new areas to improve after walking new hires through Drip's architecture, and discusses his custom billing engine. On Hound, Ben delegates the new-pricing project, and validates a new product idea. + 40:59 + no + + <p>Derrick finds some new areas to improve after walking new hires through Drip's architecture, and discusses his custom billing engine. On Hound, Ben delegates the new-pricing project, and validates a new product idea.</p> +<ul> +<li><a href="http://tbot.io/survey">Podcast Patreon Survey</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-213">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="https://www.briefs.fm/">Briefs</a></li> +<li><a href="https://www.fullstory.com/">FullStory</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="http://techzinglive.com/">techzing podcast</a></li> +<li><a href="https://www.goodreads.com/book/show/1319.The_War_of_Art"><em>The War of Art</em></a></li> +<li><a href="http://www.benorenstein.com/content-marketing-roi/">Content Marketing ROI</a></li> +</ul> + + + + Derrick finds some new areas to improve after walking new hires through Drip's architecture, and discusses his custom billing engine. On Hound, Ben delegates the new-pricing project, and validates a new product idea.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick finds some new areas to improve after walking new hires through Drip's architecture, and discusses his custom billing engine. On Hound, Ben delegates the new-pricing project, and validates a new product idea.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+CE36pBs6 + + ]]> + + + + 212: Good Enough, Namaste + https://podcast.thoughtbot.com/212 + fd3de397-3bd7-4ec5-958d-0e0c3e9c055d + Mon, 10 Oct 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Derrick brings a few more new hires onto the team, and ships a change to make clients' Javascript snippets more performant. On Hound, Ben does some direct outreach sales, considers bringing on someone to help with marketing, and muses on the balancing act between product manager, developer, and marketing. + 38:23 + no + + <p>Derrick brings a few more new hires onto the team, and ships a change to make clients' Javascript snippets more performant. On Hound, Ben does some direct outreach sales, considers bringing on someone to help with marketing, and muses on the balancing act between product manager, developer, and marketing.</p> +<ul> +<li><a href="http://tbot.io/survey">Podcast Patreon Survey</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-212">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="http://bootstrappedweb.com/">Bootstrapped Web Podcast</a></li> +<li><a href="https://www.codeschool.com/screencasts/founder-s-talk-part-3">Greg Pollack Founder's Talk</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="http://thirdpartyjs.com/"><em>Third-Party JavaScript</em></a></li> +<li><a href="http://zenfounder.com/">ZenFounder Podcast</a></li> +<li><a href="https://www.grandtrunk.com/collections/hammocks">Grand Trunk Hammocks</a></li> +</ul> + + + + Derrick brings a few more new hires onto the team, and ships a change to make clients' Javascript snippets more performant. On Hound, Ben does some direct outreach sales, considers bringing on someone to help with marketing, and muses on the balancing act between product manager, developer, and marketing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick brings a few more new hires onto the team, and ships a change to make clients' Javascript snippets more performant. On Hound, Ben does some direct outreach sales, considers bringing on someone to help with marketing, and muses on the balancing act between product manager, developer, and marketing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+m227Gla9 + + ]]> + + + + 211: Battle Hardened Over Time + https://podcast.thoughtbot.com/211 + 4d150fad-4125-4df8-aafe-b32e8e177a85 + Mon, 03 Oct 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + On Hound, Ben sends out announcements for pricing changes, questions when a decision is the "right" decision when it comes to customer feedback, and toys with per-seat pricing model feasibility. Derrick has a successful first week on-boarding the new dev-ops hire, offers Ben some advice on balancing features with price, and discusses some customer acquisition campaigns. + 39:45 + no + + <p>On Hound, Ben sends out announcements for pricing changes, questions when a decision is the &quot;right&quot; decision when it comes to customer feedback, and toys with per-seat pricing model feasibility. Derrick has a successful first week on-boarding the new dev-ops hire, offers Ben some advice on balancing features with price, and discusses some customer acquisition campaigns.</p> +<ul> +<li><a href="http://tbot.io/survey">Podcast Patreon Survey</a></li> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-211">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="http://paulgraham.com/schlep.html"><em>Schlep Blindness</em></a>- Paul Graham (Ben meant 'Schlep' rather than 'Slog')</li> +<li><a href="https://www.leadpages.net/blog/category/conversioncast/">Conversion Cast</a></li> +</ul> + + + + On Hound, Ben sends out announcements for pricing changes, questions when a decision is the "right" decision when it comes to customer feedback, and toys with per-seat pricing model feasibility. Derrick has a successful first week on-boarding the new dev-ops hire, offers Ben some advice on balancing features with price, and discusses some customer acquisition campaigns.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On Hound, Ben sends out announcements for pricing changes, questions when a decision is the "right" decision when it comes to customer feedback, and toys with per-seat pricing model feasibility. Derrick has a successful first week on-boarding the new dev-ops hire, offers Ben some advice on balancing features with price, and discusses some customer acquisition campaigns.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+XYZ44nlI + + ]]> + + + + 210: s/Walden/Andover + https://podcast.thoughtbot.com/210 + 82cfad0f-1b20-47ce-a088-b0621f552e2c + Mon, 26 Sep 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben plans a camping trip, acquires a new Twitter account, releases his notes on giving great conference talks, and begins to tell users of Hound's new pricing. Derrick reacts to the announcement of Github Projects and what that means for Codetree, ships the new form design on Drip, and muses on the ramifications to Google's announced penalizing of intrusive mobile pop-ups. + 32:19 + no + + <p>Ben plans a camping trip, acquires a new Twitter account, releases his notes on giving great conference talks, and begins to tell users of Hound's new pricing. Derrick reacts to the announcement of Github Projects and what that means for Codetree, ships the new form design on Drip, and muses on the ramifications to Google's announced penalizing of intrusive mobile pop-ups.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-210">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="http://ultralightbackpackintips.blogspot.com/">Ultralight Backpackin' Tips</a></li> +<li><a href="https://twitter.com/GiantRobots">We're on Twitter</a></li> +<li><a href="https://youtu.be/C6MGKHkNtxU">Projects on GitHub</a>- from GitHub Universe 2016</li> +<li><a href="https://codetree.com/">Codetree</a></li> +<li><a href="https://youtu.be/ByNs9TG30E8">Om Next</a>- David Nolen, Euroclojure 2015</li> +<li><a href="https://github.com/dear-github/dear-github">'Dear Github'</a></li> +<li><a href="http://adam.herokuapp.com/past/2011/4/28/scaling_a_development_team/">How to Scale a Development Team</a></li> +<li><a href="https://github.com/speaking-for-hackers/speaking-for-hackers-book">Speaking for Hackers</a></li> +<li><a href="https://webmasters.googleblog.com/2016/08/helping-users-easily-access-content-on.html">Google Pop-up Guidelines</a></li> +</ul> + + + + Ben plans a camping trip, acquires a new Twitter account, releases his notes on giving great conference talks, and begins to tell users of Hound's new pricing. Derrick reacts to the announcement of Github Projects and what that means for Codetree, ships the new form design on Drip, and muses on the ramifications to Google's announced penalizing of intrusive mobile pop-ups.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben plans a camping trip, acquires a new Twitter account, releases his notes on giving great conference talks, and begins to tell users of Hound's new pricing. Derrick reacts to the announcement of Github Projects and what that means for Codetree, ships the new form design on Drip, and muses on the ramifications to Google's announced penalizing of intrusive mobile pop-ups.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+OGHlc2CE + + ]]> + + + + 209: Playlist Driven Development + https://podcast.thoughtbot.com/209 + 06e3e9c1-43cf-481c-bf20-0244d7c493e9 + Mon, 19 Sep 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + On Drip, Derrick deals with a high-bandwidth customer and hires a new devops team member. Meanwhile, Ben brainstorms new pricing structures for Hound. + 33:54 + no + + <p>On Drip, Derrick deals with a high-bandwidth customer and hires a new devops team member. Meanwhile, Ben brainstorms new pricing structures for Hound.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-207">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="http://www.microconf.com/sessions/lessons-from-the-saas-metrics-of-1500-companies/">Lessons From the Saas Metrics of 1500 Companies</a>- Patrick Campbell MicroConf Session Overview (video not currently available)</li> +</ul> + + + + On Drip, Derrick deals with a high-bandwidth customer and hires a new devops team member. Meanwhile, Ben brainstorms new pricing structures for Hound.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On Drip, Derrick deals with a high-bandwidth customer and hires a new devops team member. Meanwhile, Ben brainstorms new pricing structures for Hound.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+B7sR1HGe + + ]]> + + + + 208: Efficiency Starts With a Haircut + https://podcast.thoughtbot.com/208 + eb3ad839-4801-48c9-8f5c-2bb6b692abcd + Mon, 12 Sep 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Derrick switches domains from getdrip.com to drip.co, begins to update the design of the Drip widget, and tries to find balance in his varying roles as CTO. Ben hands off the reins of Upcase, switches to a low-tech project management solution, and mixes work and personal todos. + 40:02 + no + + <p>Derrick switches domains from getdrip.com to drip.co, begins to update the design of the Drip widget, and tries to find balance in his varying roles as CTO. Ben hands off the reigns of Upcase, switches to a low-tech project management solution, and mixes work and personal todos.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-207">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="https://youtu.be/PJjmw9TRB7s">Implementing a Strong Code-Review Culture</a>- Derek Prior</li> +<li><a href="https://seekingwisdom.io/tagged/podcast">Seeking Wisdom Podcast</a></li> +<li><a href="https://www.16personalities.com/">16Personalities</a></li> +<li><a href="https://chrome.google.com/webstore/detail/momentum/laookkfknpbbblfpciffpaejjkokdgca?hl=en">Momentum Chrome Extension</a></li> +</ul> + + + + Derrick switches domains from getdrip.com to drip.co, begins to update the design of the Drip widget, and tries to find balance in his varying roles as CTO. Ben hands off the reigns of Upcase, switches to a low-tech project management solution, and mixes work and personal todos.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Derrick switches domains from getdrip.com to drip.co, begins to update the design of the Drip widget, and tries to find balance in his varying roles as CTO. Ben hands off the reigns of Upcase, switches to a low-tech project management solution, and mixes work and personal todos.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+e7mWR56g + + ]]> + + + + 207: Database & Queue are Dirty Words (Derrick Reimer) + https://podcast.thoughtbot.com/207 + 0d11f7cf-01f5-49fc-9ea3-ca16c6a85ce9 + Tue, 06 Sep 2016 00:00:00 -0400 + thoughtbot + + full + 6 + thoughtbot + Ben welcomes guest co-host Derrick Reimer, co-founder of Drip, getting to know his background and products for our first outside-thoughtbot view on SaaS strategy (as well as Ben's arm-twisty methods for getting him on the podcast in the first place)! + 33:21 + no + + <p>Ben welcomes guest co-host Derrick Reimer, co-founder of Drip, getting to know his background and products for our first outside-thoughtbot view on SaaS strategy (as well as Ben's arm-twisty methods for getting him on the podcast in the first place)!</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-207">FormKeep</a></li> +<li><a href="https://www.drip.co/">Drip</a></li> +<li><a href="http://www.microconf.com/">MicroConf</a></li> +<li><a href="https://github.com/mperham/sidekiq">Sidekiq</a></li> +<li><a href="https://codetree.com/">Codetree</a></li> +<li><a href="https://www.drip.co/workflows">Drip Workflows</a></li> +<li><a href="https://twitter.com/derrickreimer">Derrick on Twitter</a></li> +</ul> + + + + Ben welcomes guest co-host Derrick Reimer, co-founder of Drip, getting to know his background and products for our first outside-thoughtbot view on SaaS strategy (as well as Ben's arm-twisty methods for getting him on the podcast in the first place)!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben welcomes guest co-host Derrick Reimer, co-founder of Drip, getting to know his background and products for our first outside-thoughtbot view on SaaS strategy (as well as Ben's arm-twisty methods for getting him on the podcast in the first place)!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mWJpPYRL + + ]]> + + + + 206: I'm Glad We Talked About This (Chad Pytel) + https://podcast.thoughtbot.com/206 + 2bf6596f-c3f6-4be3-a819-f9df063dd188 + Mon, 22 Aug 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + thoughtbot CEO Chad Pytel joins Ben to discuss our recent office closings and reasons necessitating this decision, what this means for the product team, and the future of thoughtbot. Also, a teaser of what to expect next from Giant Robots Podcast. + 47:13 + no + + <p>thoughtbot CEO Chad Pytel joins Ben to discuss our recent office closings and reasons necessitating this decision, what this means for the product team, and the future of thoughtbot. Also, a teaser of what to expect next from Giant Robots Podcast.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-206">FormKeep</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="http://giantrobots.fm/153">Chad on <em>Giant Robots</em> from last year</a></li> +<li><a href="https://twitter.com/cpytel">Chad on Twitter</a></li> +</ul> + + + + thoughtbot CEO Chad Pytel joins Ben to discuss our recent office closings and reasons necessitating this decision, what this means for the product team, and the future of thoughtbot. Also, a teaser of what to expect next from Giant Robots Podcast.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + thoughtbot CEO Chad Pytel joins Ben to discuss our recent office closings and reasons necessitating this decision, what this means for the product team, and the future of thoughtbot. Also, a teaser of what to expect next from Giant Robots Podcast.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+n7tacXrF + + ]]> + + + + 205: Bottling Calm + https://podcast.thoughtbot.com/205 + f1433d7c-e32e-4597-abe4-3a854c3c8f2e + Mon, 08 Aug 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Fresh back from vacation, Ben shifts his attention to a Hound project, adding in tiered plans and pricing. Chris begins to build out a drip sequence for content recommendations, prepares to roll off to return to client work, and leaves us with some final reflections, takeaways, and lessons learned while on Upcase. + 42:59 + no + + <p>Fresh back from vacation, Ben shifts his attention to a Hound project, adding in tiered plans and pricing. Chris begins to build out a drip sequence for content recommendations, prepares to roll off to return to client work, and leaves us with some final reflections, takeaways, and lessons learned while on Upcase.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-205">FormKeep</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="https://robots.thoughtbot.com/bin-setup">./bin/setup</a></li> +<li><a href="http://www.businessinsider.com/warren-buffett-productivity-trick-2014-9">Warren Buffett's 2-List System</a></li> +</ul> + + + + Fresh back from vacation, Ben shifts his attention to a Hound project, adding in tiered plans and pricing. Chris begins to build out a drip sequence for content recommendations, prepares to roll off to return to client work, and leaves us with some final reflections, takeaways, and lessons learned while on Upcase.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Fresh back from vacation, Ben shifts his attention to a Hound project, adding in tiered plans and pricing. Chris begins to build out a drip sequence for content recommendations, prepares to roll off to return to client work, and leaves us with some final reflections, takeaways, and lessons learned while on Upcase.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hv5089C7 + + ]]> + + + + 204: Disinclined, For Simplicity's Sake + https://podcast.thoughtbot.com/204 + f8894057-372f-43ae-841f-fb32c3fd21e4 + Mon, 01 Aug 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Chris delves into marketing mode for the TDD course, removes more client-side analytics code, and starts redesigning the information architecture on Upcase. On FormKeep, Ben alerts users to site down-time, removes all pay-per-form logic from the codebase, and begins to set up trials sans credit-card. + 56:55 + no + + <p>Chris delves into marketing mode for the TDD course, removes more client-side analytics code, and starts redesigning the information architecture on Upcase. On FormKeep, Ben alerts users to site down-time, removes all pay-per-form logic from the codebase, and begins to set up trials sans credit-card.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-204">FormKeep</a></li> +<li><a href="http://www.slideshare.net/reed2001/culture-1798664">Netflix Culture Deck</a></li> +<li><a href="https://thoughtbot.com/upcase/fundamentals-of-tdd">Fundamentals of TDD on Upcase</a></li> +<li><a href="https://robots.thoughtbot.com/fundamentals-of-tdd-now-on-upcase">Fundamentals of TDD Blog Post</a></li> +<li><a href="https://www.pingdom.com/">Pingdom</a></li> +<li><a href="http://bikeshed.fm/70">Sandi Metz on <em>Bike Shed</em></a></li> +</ul> + + + + Chris delves into marketing mode for the TDD course, removes more client-side analytics code, and starts redesigning the information architecture on Upcase. On FormKeep, Ben alerts users to site down-time, removes all pay-per-form logic from the codebase, and begins to set up trials sans credit-card.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris delves into marketing mode for the TDD course, removes more client-side analytics code, and starts redesigning the information architecture on Upcase. On FormKeep, Ben alerts users to site down-time, removes all pay-per-form logic from the codebase, and begins to set up trials sans credit-card.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+KuW-cxoP + + ]]> + + + + 203: Worry Beads on Business Chains + https://podcast.thoughtbot.com/203 + 4de0a0c9-199d-44eb-95fd-2f87437efd79 + Mon, 25 Jul 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben receives some insight on customer referrals for FormKeep, applies his pricing philosophy to Hound, and realizes a personal blind-spot when it comes to customer satisfaction. On Upcase, Chris patches an automated follow-up messaging bug leading to enhanced focus on server-side analytics, welcomes Tyson to the team to begin work on trail mapping course content, and soft launches the Fundamentals of TDD trail. + 45:57 + no + + <p>Ben receives some insight on customer referrals for FormKeep, applies his pricing philosophy to Hound, and realizes a personal blind-spot when it comes to customer satisfaction. On Upcase, Chris patches an automated follow-up messaging bug leading to enhanced focus on server-side analytics, welcomes Tyson to the team to begin work on trail mapping course content, and soft launches the Fundamentals of TDD trail.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-203">FormKeep</a></li> +<li><a href="https://chrome.google.com/webstore/detail/motivation/ofdgfpchbidcgncgfpdlpclnpaemakoj">Age Motivation extension</a></li> +<li><a href="http://lailaandbrenda.fm/">The Laila &amp; Brenda Show</a></li> +<li><a href="https://en.wikipedia.org/wiki/.fm">.fm wiki</a></li> +<li><a href="https://amplitude.com/">Amplitude</a></li> +<li><a href="https://www.hittail.com/">HitTail</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="https://thoughtbot.com/upcase/fundamentals-of-tdd">Fundamentals of TDD</a></li> +</ul> + + + + Ben receives some insight on customer referrals for FormKeep, applies his pricing philosophy to Hound, and realizes a personal blind-spot when it comes to customer satisfaction. On Upcase, Chris patches an automated follow-up messaging bug leading to enhanced focus on server-side analytics, welcomes Tyson to the team to begin work on trail mapping course content, and soft launches the Fundamentals of TDD trail.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben receives some insight on customer referrals for FormKeep, applies his pricing philosophy to Hound, and realizes a personal blind-spot when it comes to customer satisfaction. On Upcase, Chris patches an automated follow-up messaging bug leading to enhanced focus on server-side analytics, welcomes Tyson to the team to begin work on trail mapping course content, and soft launches the Fundamentals of TDD trail.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+i8W0ij_b + + ]]> + + + + 202: A Full 360 + https://podcast.thoughtbot.com/202 + 3d4a873f-755d-4c13-b0ee-d4ac17306a7a + Mon, 18 Jul 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben rants about bad jokes on twitter, doesn't ship any improved activation features on FormKeep this week, irons out some bugs on FormLinter, and begins an ad campaign. Chris contemplates shifting Upcase's business model, and walks through the impetus driving this decision. + 41:17 + no + + <p>Ben rants about bad jokes on twitter, doesn't ship any improved activation features on FormKeep this week, irons out some bugs on FormLinter, and begins an ad campaign. Chris contemplates shifting Upcase's business model, and walks through the impetus driving this decision.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-202">FormKeep</a></li> +<li><a href="https://twitter.com/ID_AA_Carmack">John Carmack Twitter</a></li> +<li><a href="https://codahale.com/fan-in/">Fan-In</a></li> +<li><a href="https://formlinter.com/">FormLinter</a></li> +<li><a href="https://thoughtbot.com/upcase/the-weekly-iteration">The Weekly Iteration</a></li> +</ul> + + + + Ben rants about bad jokes on twitter, doesn't ship any improved activation features on FormKeep this week, irons out some bugs on FormLinter, and begins an ad campaign. Chris contemplates shifting Upcase's business model, and walks through the impetus driving this decision.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben rants about bad jokes on twitter, doesn't ship any improved activation features on FormKeep this week, irons out some bugs on FormLinter, and begins an ad campaign. Chris contemplates shifting Upcase's business model, and walks through the impetus driving this decision.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JfKhJidU + + ]]> + + + + 201: The Difficulty is in Focusing + https://podcast.thoughtbot.com/201 + 1acd0f61-bc0c-4305-99f0-98f914c34fab + Mon, 11 Jul 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben encounters a downed FormKeep and enables a monitoring service, completes the un-grandfathering process for accounts on old tiers, and begins work on improving activation flow. Chris sends out a survey to users and discovers a shift in the Upcase demographics. + 48:34 + no + + <p>Ben encounters a downed FormKeep and enables a monitoring service, completes the un-grandfathering process for accounts on old tiers, and begins work on improving activation flow. Chris sends out a survey to users and discovers a shift in the Upcase demographics.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-201">FormKeep</a></li> +<li><a href="https://www.pingdom.com/">pingdom</a></li> +<li><a href="https://formlinter.com/">FormLinter</a></li> +</ul> + + + + Ben encounters a downed FormKeep and enables a monitoring service, completes the un-grandfathering process for accounts on old tiers, and begins work on improving activation flow. Chris sends out a survey to users and discovers a shift in the Upcase demographics.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben encounters a downed FormKeep and enables a monitoring service, completes the un-grandfathering process for accounts on old tiers, and begins work on improving activation flow. Chris sends out a survey to users and discovers a shift in the Upcase demographics.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0JL7siRf + + ]]> + + + + 200: Summertime Sadness + https://podcast.thoughtbot.com/200 + e4b5266d-c7df-46d0-81b0-0f26489a7d74 + Mon, 04 Jul 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Chris digs into the causes for a MRR drop, discovering usage trends with seasonality; and in the process gets a clearer picture of Upcase's user base. Also, he welcome Geoff to the project, and begins a new marketing initiative driven by user testimonials. Ben welcomes Tyson onto team Formkeep to begin redesigning on boarding, and continues FormLinter improvements / marketing. + 46:29 + no + + <p>Chris digs into the causes for a MRR drop, discovering usage trends with seasonality; and in the process gets a clearer picture of Upcase's user base. Also, he welcome Geoff to the project, and begins a new marketing initiative driven by user testimonials. Ben welcomes Tyson onto team Formkeep to begin redesigning on boarding, and continues FormLinter improvements / marketing.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-200">Formkeep</a></li> +<li><a href="https://www.typeform.com/">Typeform</a></li> +<li><a href="http://giantrobots.fm/173">Hiten Shah on <em>Giant Robots</em></a></li> +<li><a href="https://www.chefsteps.com/">ChefSteps</a></li> +<li><a href="https://fullstory.com/">FullStory</a></li> +<li><a href="https://formlinter.com/">FormLinter</a></li> +</ul> + + + + Chris digs into the causes for a MRR drop, discovering usage trends with seasonality; and in the process gets a clearer picture of Upcase's user base. Also, he welcome Geoff to the project, and begins a new marketing initiative driven by user testimonials. Ben welcomes Tyson onto team Formkeep to begin redesigning on boarding, and continues FormLinter improvements / marketing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris digs into the causes for a MRR drop, discovering usage trends with seasonality; and in the process gets a clearer picture of Upcase's user base. Also, he welcome Geoff to the project, and begins a new marketing initiative driven by user testimonials. Ben welcomes Tyson onto team Formkeep to begin redesigning on boarding, and continues FormLinter improvements / marketing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+qT6a_fnj + + ]]> + + + + 199: Heartening Frustration + https://podcast.thoughtbot.com/199 + aa7c4c5c-a14a-4187-9210-39d951a11693 + Mon, 27 Jun 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + This week, we ruminate on the meta-organization of project management. Ben embraces team feedback on FormLinter.com, reaches the end of Formkeep's grandfathered pricing window, and removes sandboxing to streamline plan structures. Chris contemplates Upcase's role as a product within thoughtbot, prepares to welcome on new team members (bye Gabe!), and restructures topic relationships to improve discoverability. Also, the return of Dance Talk! + 51:22 + no + + <p>This week, we ruminate on the meta-organization of project management. Ben embraces team feedback on FormLinter.com, reaches the end of Formkeep's grandfathered pricing window, and removes sandboxing to streamline plan structures. Chris contemplates Upcase's role as a product within thoughtbot, prepares to welcome on new team members (bye Gabe!), and restructures topic relationships to improve discoverability. Also, the return of Dance Talk!</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-199">Formkeep</a></li> +<li><a href="http://gettingthingsdone.com/">Getting Things Done</a></li> +<li><a href="http://www.businessinsider.com/warren-buffett-productivity-trick-2014-9">Warren Buffett's 2-List System</a></li> +<li><a href="https://formlinter.com/">FormLinter</a></li> +<li><a href="https://youtu.be/Gzj723LkRJY">Ruby on Rails 15 Minute Blog Engine Demo</a></li> +</ul> + + + + This week, we ruminate on the meta-organization of project management. Ben embraces team feedback on FormLinter.com, reaches the end of Formkeep's grandfathered pricing window, and removes sandboxing to streamline plan structures. Chris contemplates Upcase's role as a product within thoughtbot, prepares to welcome on new team members (bye Gabe!), and restructures topic relationships to improve discoverability. Also, the return of Dance Talk!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week, we ruminate on the meta-organization of project management. Ben embraces team feedback on FormLinter.com, reaches the end of Formkeep's grandfathered pricing window, and removes sandboxing to streamline plan structures. Chris contemplates Upcase's role as a product within thoughtbot, prepares to welcome on new team members (bye Gabe!), and restructures topic relationships to improve discoverability. Also, the return of Dance Talk!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_f8tAoFx + + ]]> + + + + 198: Nailing Down the Why + https://podcast.thoughtbot.com/198 + dd7a61fc-fb09-4166-b1ca-49d865dc6a15 + Mon, 20 Jun 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + On Formkeep, Ben launches FormLinter to increase form accessibility and conversions, and looks forward to additional persons on thoughtbot product work. Chris continues marketing of the Bourbon Smash course, wrestles with metrics and analytics, and improves team logins on Upcase. + 45:28 + no + + <p>On Formkeep, Ben launches FormLinter to increase form accessibility and conversions, and looks forward to additional persons on thoughtbot product work. Chris continues marketing of the Bourbon Smash course, wrestles with metrics and analytics, and improves team logins on Upcase.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-198">Formkeep</a></li> +<li><a href="http://formlinter.com/">FormLinter</a></li> +<li><a href="https://accesslint.com/">AccessLint</a></li> +<li><a href="http://tractionbook.com/"><em>Traction</em></a>- Gabriel Weinberg &amp; Justin Mares</li> +<li><a href="https://inbound.org/">inbound.org</a></li> +<li><a href="https://robots.thoughtbot.com/failing-on-day-one">Failing on Day One</a>- Chad Pytel</li> +<li><a href="https://en.wikipedia.org/wiki/Panopticon">Panopticon</a></li> +</ul> + + + + On Formkeep, Ben launches FormLinter to increase form accessibility and conversions, and looks forward to additional persons on thoughtbot product work. Chris continues marketing of the Bourbon Smash course, wrestles with metrics and analytics, and improves team logins on Upcase.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On Formkeep, Ben launches FormLinter to increase form accessibility and conversions, and looks forward to additional persons on thoughtbot product work. Chris continues marketing of the Bourbon Smash course, wrestles with metrics and analytics, and improves team logins on Upcase.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YVAi_GqC + + ]]> + + + + 197: An Engine That Throws Off Money + https://podcast.thoughtbot.com/197 + 8b9f0c73-fb7e-4bab-a177-76eeccd31de1 + Mon, 13 Jun 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + On Upcase, Chris releases the Bourbon course, restructures how new courses are highlighted, and discusses juggling the various factors that contribute to MRR. Ben takes on-boarding notes from a century old dance school to improve activation on Formkeep. + 1:08:44 + no + + <p>On Upcase, Chris releases the Bourbon course, restructures how new courses are highlighted, and discusses juggling the various factors that contribute to MRR. Ben takes on-boarding notes from a century old dance school to improve activation on Formkeep.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-197">Formkeep</a></li> +<li><a href="http://www.dancarlin.com/hardcore-history-series/">Hardcore History</a></li> +<li><a href="https://thoughtbot.com/upcase/bourbon-smash">Bourbon Smash Course on Upcase</a></li> +<li><a href="http://www.rubytapas.com/">Ruby Tapas</a></li> +<li><a href="http://arthurmurray.com/">Arthur Murray</a> Dance Centers</li> +<li><a href="http://blog.asmartbear.com/bootstrapped-cpc.html">Bootstrapped CPC Rule of Thumb</a>- Jason Cohen</li> +<li><a href="https://en.wikipedia.org/wiki/Dark_Age_of_Camelot">Dark Age of Camelot</a></li> +</ul> + + + + On Upcase, Chris releases the Bourbon course, restructures how new courses are highlighted, and discusses juggling the various factors that contribute to MRR. Ben takes on-boarding notes from a century old dance school to improve activation on Formkeep.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On Upcase, Chris releases the Bourbon course, restructures how new courses are highlighted, and discusses juggling the various factors that contribute to MRR. Ben takes on-boarding notes from a century old dance school to improve activation on Formkeep.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hZc4AsL7 + + ]]> + + + + 196: Anecdotal Driven Development + https://podcast.thoughtbot.com/196 + 65745730-b8f6-41f8-988e-2c9ed5bcd648 + Mon, 30 May 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben changes product activation flow, possibly for the worse, launches a new UI, and muses on new customer acquisition for Formkeep. On Upcase, Chris starts to see benefits from the domain transition, and brainstorms on how to un-bottleneck course releases. + 49:52 + no + + <p>Ben changes product activation flow, possibly for the worse, launches a new UI, and muses on new customer acquisition for Formkeep. On Upcase, Chris starts to see benefits from the domain transition, and brainstorms on how to un-bottleneck course releases.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-196">Formkeep</a></li> +<li><a href="https://www.goodreads.com/book/show/11468377-thinking-fast-and-slow"><em>Thinking, Fast and Slow</em></a></li> +<li><a href="https://www.goodreads.com/book/show/1633.Getting_Things_Done"><em>Getting Things Done</em></a></li> +<li><a href="http://www.npr.org/sections/money/2016/01/15/463237871/episode-677-the-experiment-experiment">Planet Money 667: The Experiment Experiment</a></li> +</ul> + + + + Ben changes product activation flow, possibly for the worse, launches a new UI, and muses on new customer acquisition for Formkeep. On Upcase, Chris starts to see benefits from the domain transition, and brainstorms on how to un-bottleneck course releases.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben changes product activation flow, possibly for the worse, launches a new UI, and muses on new customer acquisition for Formkeep. On Upcase, Chris starts to see benefits from the domain transition, and brainstorms on how to un-bottleneck course releases.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+f72xYwYg + + ]]> + + + + 195: The Storm Before the Calm + https://podcast.thoughtbot.com/195 + 22e8c94f-c18a-4cbc-8127-fdd9074a2137 + Mon, 23 May 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben delays a new feature until an easier implementation can be reached, adds additional event tracking for better site usage feedback, takes a medium to large digression to rant about Javascript, and makes headway on Formkeep's UI refactor. On Upcase, Chris steps back from the content spotlight, takes a hit to traffic from the domain transition, and tests all things email. + 1:07:04 + no + + <p>Ben delays a new feature until an easier implementation can be reached, adds additional event tracking for better site usage feedback, takes a medium to large digression to rant about Javascript, and makes headway on Formkeep's UI refactor. On Upcase, Chris steps back from the content spotlight, takes a hit to traffic from the domain transition, and tests all things email.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-195">Formkeep</a></li> +<li><a href="https://amplitude.com/">Amplitude Analytics</a></li> +<li><a href="https://segment.com/">Segment Analytics</a></li> +<li><a href="http://bikeshed.fm/58"><em>Bike Shed</em> #58</a>- Rewrite vs refactor episode</li> +<li><a href="https://robots.thoughtbot.com/keeping-the-frontend-modular-with-bem">Keeping the Front-End Modular with BEM</a>- On <em>Giant Robots</em> Blog</li> +<li><a href="http://engineering.khanacademy.org/posts/aphrodite-inline-css.htm">Inline CSS at Khan Academy: Aphrodite</a></li> +<li><a href="https://clearbit.com/">Clearbit</a></li> +<li><a href="https://www.goodreads.com/book/show/78428.Your_Money_or_Your_Life"><em>Your Money or Your Life</em></a></li> +<li><a href="https://vimeo.com/70901901">How to 10x in 15 months</a>- Rob Walling</li> +<li><a href="http://www.totango.com/wp-content/uploads/2012/11/2012-SaaS-Conversions-Benchmark2.pdf">2012 SaaS Conversions Benchmark</a></li> +</ul> + + + + Ben delays a new feature until an easier implementation can be reached, adds additional event tracking for better site usage feedback, takes a medium to large digression to rant about Javascript, and makes headway on Formkeep's UI refactor. On Upcase, Chris steps back from the content spotlight, takes a hit to traffic from the domain transition, and tests all things email.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben delays a new feature until an easier implementation can be reached, adds additional event tracking for better site usage feedback, takes a medium to large digression to rant about Javascript, and makes headway on Formkeep's UI refactor. On Upcase, Chris steps back from the content spotlight, takes a hit to traffic from the domain transition, and tests all things email.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+TmXjz_p_ + + ]]> + + + + 194: Changing Your Internet Home + https://podcast.thoughtbot.com/194 + 8a0e2823-b069-4efb-99ed-a2b776d42d8f + Mon, 16 May 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Chris transitions Upcase to thoughtbot.com/upcase for SEO and branding purposes, and introduces reactivate & resubscribe functionality. Ben publishes a blog post on Formkeep's pricing history, optimizes the initial form setup page, and begins work to implement a no credit card up-front trial. + 49:00 + no + + <p>Chris transitions Upcase to thoughtbot.com/upcase for SEO and branding purposes, and introduces reactivate &amp; resubscribe functionality. Ben publishes a blog post on Formkeep's pricing history, optimizes the initial form setup page, and begins work to implement a no credit card up-front trial.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase/">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-194">Formkeep</a></li> +<li><a href="https://medium.com/baremetrics-founders-journey/convertkits-3-000-revenue-growth-that-nobody-saw-coming-e100338871f4#.ib2q4b7qz">ConvertKit’s 3,000% revenue growth that nobody saw coming</a>- Josh Pigford</li> +<li><a href="https://medium.com/baremetrics-founders-journey/is-your-company-really-only-doing-45-000-per-month-a2098bf29bf5#.as3h4xmtq">Is your company really only doing $45,000 per month?</a>- Josh Pigford</li> +<li><a href="https://en.wikipedia.org/wiki/Hedonic_treadmill">Hedonic Treadmill</a></li> +<li><a href="https://robots.thoughtbot.com/a-tale-of-three-pricing-models">A Tale of Three Pricing Models</a>- Ben Orenstein</li> +<li><a href="http://www.totango.com/wp-content/uploads/2012/11/2012-SaaS-Conversions-Benchmark2.pdf">2012 SaaS Conversions Benchmark</a></li> +<li><a href="http://www.wimhofmethod.com/">Wim Hof Method</a></li> +<li><a href="https://www.fastly.com/">Fastly</a></li> +</ul> + + + + Chris transitions Upcase to thoughtbot.com/upcase for SEO and branding purposes, and introduces reactivate & resubscribe functionality. Ben publishes a blog post on Formkeep's pricing history, optimizes the initial form setup page, and begins work to implement a no credit card up-front trial.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris transitions Upcase to thoughtbot.com/upcase for SEO and branding purposes, and introduces reactivate & resubscribe functionality. Ben publishes a blog post on Formkeep's pricing history, optimizes the initial form setup page, and begins work to implement a no credit card up-front trial.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jd6U2IE4 + + ]]> + + + + 193: This Episode Has Been Brought to You By the Letter 'S' + https://podcast.thoughtbot.com/193 + 49571e5d-33a0-46a8-a0b1-3fb65079a9ed + Mon, 09 May 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben switches from Mandrill to Sendgrid, turns a corner on his guarantee vs trial test, and begins the process of overhauling Formkeep's UI. Meanwhile, on Upcase, Chris utilizes an interesting method for A/B Testing, teases a secret project, and increases SEO by changing out the header. + 45:19 + no + + <p>Ben switches from Mandrill to Sendgrid, turns a corner on his guarantee vs trial test, and begins the process of overhauling Formkeep's UI. Meanwhile, on Upcase, Chris utilizes an interesting method for A/B Testing, teases a secret project, and increases SEO by changing out the header.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-193">Formkeep</a></li> +</ul> + + + + Ben switches from Mandrill to Sendgrid, turns a corner on his guarantee vs trial test, and begins the process of overhauling Formkeep's UI. Meanwhile, on Upcase, Chris utilizes an interesting method for A/B Testing, teases a secret project, and increases SEO by changing out the header.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben switches from Mandrill to Sendgrid, turns a corner on his guarantee vs trial test, and begins the process of overhauling Formkeep's UI. Meanwhile, on Upcase, Chris utilizes an interesting method for A/B Testing, teases a secret project, and increases SEO by changing out the header.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+2D9XSh7x + + ]]> + + + + 192: The High End of Reasonable + https://podcast.thoughtbot.com/192 + c01c8b18-fa2a-4083-be70-e46e5f0c7f60 + Mon, 02 May 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben and Chris muse on the nature of weather-related happiness. Also, Ben works on instrumenting Formkeep's activation funnel, utilizes a monitoring utility to optimize sign-up flow, and vows to almost certainly not toy with pricing any more. Meanwhile on Upcase, Chris confronts multiple root causes for a dip in MRR, updates content displays, and overhauls the checkout. + 50:55 + no + + <p>Ben and Chris muse on the nature of weather-related happiness. Also, Ben works on instrumenting Formkeep's activation funnel, utilizes a monitoring utility to optimize sign-up flow, and vows to almost certainly not toy with pricing any more. Meanwhile on Upcase, Chris confronts multiple root causes for a dip in MRR, updates content displays, and overhauls the checkout.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-192">Formkeep</a></li> +<li><a href="http://happierhuman.com/hedonic-treadmill/">The Hedonic Treadmill</a></li> +<li><a href="https://www.fullstory.com/">FullStory</a></li> +</ul> + + + + Ben and Chris muse on the nature of weather-related happiness. Also, Ben works on instrumenting Formkeep's activation funnel, utilizes a monitoring utility to optimize sign-up flow, and vows to almost certainly not toy with pricing any more. Meanwhile on Upcase, Chris confronts multiple root causes for a dip in MRR, updates content displays, and overhauls the checkout.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Chris muse on the nature of weather-related happiness. Also, Ben works on instrumenting Formkeep's activation funnel, utilizes a monitoring utility to optimize sign-up flow, and vows to almost certainly not toy with pricing any more. Meanwhile on Upcase, Chris confronts multiple root causes for a dip in MRR, updates content displays, and overhauls the checkout.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ANlN-1Fr + + ]]> + + + + 191: I've Done it Once, I'm an Expert + https://podcast.thoughtbot.com/191 + 563cc8f1-91b9-4e9f-9ad8-61b1e9d43047 + Mon, 25 Apr 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben and Chris discuss taxes and financial (as well as bedtime) routines. On Upcase, Chris showcases "The Weekly Iteration" on the site, reveals a long-term dream for the platform, and patches a critical security issue. Ben adds a bunch of features to cut down on support requests, does some UX cleanup, and performs other general tasks to improve usability on Formkeep. + 47:14 + no + + <p>Ben and Chris discuss taxes and financial (as well as bedtime) routines. On Upcase, Chris showcases &quot;The Weekly Iteration&quot; on the site, reveals a long-term dream for the platform, and patches a critical security issue. Ben adds a bunch of features to cut down on support requests, does some UX cleanup, and performs other general tasks to improve usability on Formkeep.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-191">Formkeep</a></li> +<li><a href="http://www2.meethue.com/">Philips Hue</a></li> +<li><a href="https://upcase.com/the-weekly-iteration">The Weekly Iteration</a></li> +<li><a href="https://www.campaignmonitor.com/dev-resources/will-it-work/">Campaign Monitor</a>- HTML Email Design Guidelines</li> +<li><a href="https://ma.ttias.be/remote-code-execution-git-versions-client-server-2-7-1-cve-2016-2324-cve-2016-2315/">Git remote code execution vulnerability</a></li> +<li><a href="https://www.w3.org/TR/css-flexbox/">Flexbox</a></li> +<li><a href="https://upcase.com/videos/flexbox">Flexbox on The Weekly Iteration</a></li> +<li><a href="https://accountdock.com/">AccountDock</a></li> +<li><a href="https://calendly.com/">calendly</a></li> +</ul> +<p>Thank you to <a href="https://hired.com/giantrobots">Hired</a> for sponsoring this episode!</p> + + + + Ben and Chris discuss taxes and financial (as well as bedtime) routines. On Upcase, Chris showcases "The Weekly Iteration" on the site, reveals a long-term dream for the platform, and patches a critical security issue. Ben adds a bunch of features to cut down on support requests, does some UX cleanup, and performs other general tasks to improve usability on Formkeep.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Chris discuss taxes and financial (as well as bedtime) routines. On Upcase, Chris showcases "The Weekly Iteration" on the site, reveals a long-term dream for the platform, and patches a critical security issue. Ben adds a bunch of features to cut down on support requests, does some UX cleanup, and performs other general tasks to improve usability on Formkeep.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+nLzLYhHd + + ]]> + + + + 190: An Unkempt Backlog + https://podcast.thoughtbot.com/190 + 1991588e-53e3-41f0-9df7-38abc9ba8e22 + Tue, 19 Apr 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Chris makes progress on Upcase's to-dos in order to shift focus to after-the-funnel improvements, and makes a renewed vow to talk to customers for direct feedback. Meanwhile, Ben attends a conference, and while he picked up some great strategies for Formkeep on-boarding, he mostly just wants to fix the airline industry. + 55:33 + no + + <p>Chris makes progress on Upcase's to-dos in order to shift focus to after-the-funnel improvements, and makes a renewed vow to talk to customers for direct feedback. Meanwhile, Ben attends a conference, and while he picked up some great strategies for Formkeep onboarding, he mostly just wants to fix the airline industry.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-190">Formkeep</a></li> +<li><a href="https://upcase.com/pages/aarq-bloopers">Advanced ActiveRecord Querying</a>- Bloopers</li> +<li><a href="https://vimeo.com/54076835">Gail Goodman: When software and people mix</a>- Business of Software 2012</li> +<li><a href="http://www.ivoox.com/episode-282-the-long-slow-saas-ramp-audios-mp3_rf_10964443_1.html">Startups For the Rest of Us Ep 212</a>- The Long, Slow Death of SaaS Ramp</li> +<li><a href="http://www.microconf.com/">MicroConf</a></li> +</ul> +<p>Thank you to <a href="https://hired.com/giantrobots">Hired</a> for sponsoring this episode!</p> + + + + Chris makes progress on Upcase's to-dos in order to shift focus to after-the-funnel improvements, and makes a renewed vow to talk to customers for direct feedback. Meanwhile, Ben attends a conference, and while he picked up some great strategies for Formkeep onboarding, he mostly just wants to fix the airline industry.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris makes progress on Upcase's to-dos in order to shift focus to after-the-funnel improvements, and makes a renewed vow to talk to customers for direct feedback. Meanwhile, Ben attends a conference, and while he picked up some great strategies for Formkeep onboarding, he mostly just wants to fix the airline industry.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JOQIcKiP + + ]]> + + + + 189: Swimming Against a Stream of Complexity + https://podcast.thoughtbot.com/189 + 5496daeb-a95e-43b2-a45d-e19d840390c1 + Mon, 11 Apr 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Chris keeps improving MRR on Upcase, patches a Javascript problem with a Javascript solution, and implements benefit focused text on course descriptions. On Formkeep, Ben discovers a flaw in an A/B test, deals with squirrely payment code, and prepares for a conference talk. + 48:35 + no + + <p>Chris keeps improving MRR on Upcase, patches a Javascript problem with a Javascript solution, and implements benefit focused text on course descriptions. On Formkeep, Ben discovers a flaw in an A/B test, deals with squirrely payment code, and prepares for a conference talk.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-189">Formkeep</a></li> +<li><a href="http://www.microconf.com/">MicroConf</a></li> +<li><a href="https://www.briefs.fm/">Briefs</a></li> +<li>Dark Patterns on <a href="http://tentative.fm/23">Tentative Podcast</a></li> +<li><a href="https://percy.io/">Percy.io</a>- Visual regression testing</li> +<li>Paul Fernell (Litmus) on <a href="http://giantrobots.fm/68">Giant Robots</a></li> +<li><a href="https://upcase.com/videos/intro-to-accessibility">Weekly Iteration</a>- Intro to Accessibility</li> +</ul> +<p>Thank you to <a href="https://hired.com/giantrobots">Hired</a> for sponsoring this episode!</p> + + + + Chris keeps improving MRR on Upcase, patches a Javascript problem with a Javascript solution, and implements benefit focused text on course descriptions. On Formkeep, Ben discovers a flaw in an A/B test, deals with squirrely payment code, and prepares for a conference talk.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris keeps improving MRR on Upcase, patches a Javascript problem with a Javascript solution, and implements benefit focused text on course descriptions. On Formkeep, Ben discovers a flaw in an A/B test, deals with squirrely payment code, and prepares for a conference talk.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Qs-GHWxt + + ]]> + + + + 188: I Have a Spreadsheet! + https://podcast.thoughtbot.com/188 + add4a26e-0954-4b46-adc3-c5f537c418fa + Mon, 04 Apr 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben decides to A/B test pricing, begins grandfathering existing customers to the new tiers, teases new features on Formkeep, and recounts some interesting customer interactions. Meanwhile, Chris drives conversions through e-mail and Twitter, identifies unique customer segments, and brings in more of the thoughtbot voice to Upcase. + 45:34 + no + + <p>Ben decides to A/B test pricing, begins grandfathering existing customers to the new tiers, teases new features on Formkeep, and recounts some interesting customer interactions. Meanwhile, Chris drives conversions through e-mail and Twitter, identifies unique customer segments, and brings in more of the thoughtbot voice to Upcase.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-187">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://vwo.com/">Visual Website Optomizer</a></li> +<li><a href="https://github.com/splitrb/split">Split Gem</a></li> +<li><a href="https://www.honeybadger.io/">Honeybadger</a></li> +<li><a href="https://www.youtube.com/user/ThoughtbotVideo">thoughtbot YouTube</a></li> +</ul> +<p>Thank you to <a href="https://hired.com/giantrobots">Hired</a> for sponsoring this episode!</p> + + + + Ben decides to A/B test pricing, begins grandfathering existing customers to the new tiers, teases new features on Formkeep, and recounts some interesting customer interactions. Meanwhile, Chris drives conversions through e-mail and Twitter, identifies unique customer segments, and brings in more of the thoughtbot voice to Upcase.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben decides to A/B test pricing, begins grandfathering existing customers to the new tiers, teases new features on Formkeep, and recounts some interesting customer interactions. Meanwhile, Chris drives conversions through e-mail and Twitter, identifies unique customer segments, and brings in more of the thoughtbot voice to Upcase.

+ + + +

Thank you to Hired for sponsoring this episode!

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ti5gIOjW + + ]]> + + + + 187: Missed You! + https://podcast.thoughtbot.com/187 + bdaed9a0-8f98-42bb-8546-39fc6a946c93 + Mon, 28 Mar 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Chris welcomes a new member to team Upcase, confronts a drop in MRR, and looks forward to increased content production. On Formkeep, Ben introduces tiered pricing and trials, considers tier differentiators, and muses on what next to implement. + 54:20 + no + + <p>Chris welcomes a new member to team Upcase, confronts a drop in MRR, and looks forward to increased content production. On Formkeep, Ben introduces tiered pricing and trials, considers tier differentiators, and muses on what next to implement.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-187">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://zapier.com/">Zapier</a></li> +<li><a href="http://blog.asmartbear.com/">a smart bear</a></li> +<li><a href="https://vimeo.com/74338272">Designing the Ideal Bootstrapped Business</a>- Jason Cohen</li> +</ul> + + + + Chris welcomes a new member to team Upcase, confronts a drop in MRR, and looks forward to increased content production. On Formkeep, Ben introduces tiered pricing and trials, considers tier differentiators, and muses on what next to implement.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris welcomes a new member to team Upcase, confronts a drop in MRR, and looks forward to increased content production. On Formkeep, Ben introduces tiered pricing and trials, considers tier differentiators, and muses on what next to implement.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Yd_ck-WA + + ]]> + + + + 186: Learning Through Experimentation (Ryan Buckley) + https://podcast.thoughtbot.com/186 + b8572d4b-ccc4-47c4-be90-5500b86730ce + Mon, 14 Mar 2016 00:00:00 -0400 + thoughtbot + + full + 5 + thoughtbot + Ben and Chris welcome on Ryan Buckley, co-founder of Scripted, for an honest discussion on the shortcomings, pain-points, and benefits that arise from restructuring a product's focus. + 37:12 + no + + <p>Ben and Chris welcome on Ryan Buckley, co-founder of Scripted, for an honest discussion on the shortcomings, pain-points, and benefits that arise from restructuring a product's focus.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-186">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="http://scripted.com/">Scripted</a></li> +<li><a href="https://twitter.com/rbucks">Ryan on Twitter</a></li> +</ul> + + + + Ben and Chris welcome on Ryan Buckley, co-founder of Scripted, for an honest discussion on the shortcomings, pain-points, and benefits that arise from restructuring a product's focus.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Chris welcome on Ryan Buckley, co-founder of Scripted, for an honest discussion on the shortcomings, pain-points, and benefits that arise from restructuring a product's focus.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+-5N9v_Jz + + ]]> + + + + 185: The Funnel is Just the Beginning (Lincoln Murphy) + https://podcast.thoughtbot.com/185 + 3a773c35-052d-472f-a0f9-2dab1936e737 + Mon, 07 Mar 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Ben welcomes SaaS growth and customer success pioneer Lincoln Murphy to discuss the true importance of providing value to existing customers and focusing on their success, as every tactic you undertake as a business is predicated on understanding their desired outcome. He also delves into how focusing on customer type is beneficial for both consumers and producers, as well as gives Ben some feedback about Formkeep. + 30:12 + no + + <p>Ben welcomes SaaS growth and customer success pioneer Lincoln Murphy to discuss the true importance of providing value to existing customers and focusing on their success, as every tactic you undertake as a business is predicated on understanding their desired outcome. He also delves into how focusing on customer type is beneficial for both consumers and producers, as well as gives Ben some feedback about Formkeep.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-185">Formkeep</a></li> +<li><a href="https://hbr.org/2014/10/the-value-of-keeping-the-right-customers/">The Value of Keeping the Right Customers</a></li> +<li><a href="https://www.entrepreneurs-journey.com/397/80-20-rule-pareto-principle/">80/20 Rule</a></li> +<li><a href="https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27#.y119xc9y6">Jobs-to-be-Done</a></li> +<li><a href="http://sixteenventures.com/ideal-customer-profile">Ideal Customer Profile Framework</a></li> +<li><a href="http://sixteenventures.com/">Sixteen Ventures</a></li> +<li><a href="https://twitter.com/lincolnmurphy">Lincoln on Twitter</a></li> +</ul> + + + + Ben welcomes SaaS growth and customer success pioneer Lincoln Murphy to discuss the true importance of providing value to existing customers and focusing on their success, as every tactic you undertake as a business is predicated on understanding their desired outcome. He also delves into how focusing on customer type is beneficial for both consumers and producers, as well as gives Ben some feedback about Formkeep.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben welcomes SaaS growth and customer success pioneer Lincoln Murphy to discuss the true importance of providing value to existing customers and focusing on their success, as every tactic you undertake as a business is predicated on understanding their desired outcome. He also delves into how focusing on customer type is beneficial for both consumers and producers, as well as gives Ben some feedback about Formkeep.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dnk5ITxl + + ]]> + + + + 184: I Love You, Businesses! + https://podcast.thoughtbot.com/184 + 049af7a1-2aa6-4d19-a742-50711a83c000 + Mon, 29 Feb 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Ben accidentally launches a Vim course, debates a B2B vs B2C focus, and feels out different Formkeep pricing tiers. Chris welcomes back a handful of former subscribers to Upcase, continues to work on content production, and integrates relevant content into broader thoughtbot docs. + 50:41 + no + + <p>Ben accidentally launches a Vim course, debates a B2B vs B2C focus, and feels out different Formkeep pricing tiers. Chris welcomes back a handful of former subscribers to Upcase, continues to work on content production, and integrates relevant content into broader thoughtbot docs.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-184">Formkeep</a></li> +<li><a href="https://gumroad.com/l/become-a-daily-vim-user/early-bird">Become a Daily Vim User</a></li> +<li><a href="https://www.briefs.fm/vim-tips-with-ben">Vim Tips With Ben Podcast</a></li> +<li><a href="https://www.sublimetext.com/">Sublime Text</a></li> +<li><a href="https://github.com/thoughtbot/factory_girl#documentation">Factory Girl docs</a> with Upcase introductory video</li> +</ul> + + + + Ben accidentally launches a Vim course, debates a B2B vs B2C focus, and feels out different Formkeep pricing tiers. Chris welcomes back a handful of former subscribers to Upcase, continues to work on content production, and integrates relevant content into broader thoughtbot docs.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben accidentally launches a Vim course, debates a B2B vs B2C focus, and feels out different Formkeep pricing tiers. Chris welcomes back a handful of former subscribers to Upcase, continues to work on content production, and integrates relevant content into broader thoughtbot docs.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tMR8AwfQ + + ]]> + + + + 183: Embarrassing Trailing White-Space + https://podcast.thoughtbot.com/183 + 80979e0d-dd67-47a9-a059-75f32c94aed6 + Mon, 22 Feb 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Chris converts with email campaigns, lays out a time-table to churn out a ton of content, and tries to analyze a dip in revenue. Meanwhile, Ben tests the definition of what constitutes a "conference", focuses on how to enrich Formkeep for specific use cases, and makes headway on tiered pricing. + 49:22 + no + + <p>Chris converts with email campaigns, lays out a time-table to churn out a ton of content, and tries to analyze a dip in revenue. Meanwhile, Ben tests the definition of what constitutes a &quot;conference&quot;, focuses on how to enrich Formkeep for specific use cases, and makes headway on tiered pricing.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-183">Formkeep</a></li> +<li><a href="http://www.moraware.com/">Moraware</a>- Countertop Fabricator Software</li> +<li><a href="https://clearbit.com/">Clearbit</a></li> +</ul> + + + + Chris converts with email campaigns, lays out a time-table to churn out a ton of content, and tries to analyze a dip in revenue. Meanwhile, Ben tests the definition of what constitutes a "conference", focuses on how to enrich Formkeep for specific use cases, and makes headway on tiered pricing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris converts with email campaigns, lays out a time-table to churn out a ton of content, and tries to analyze a dip in revenue. Meanwhile, Ben tests the definition of what constitutes a "conference", focuses on how to enrich Formkeep for specific use cases, and makes headway on tiered pricing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+OVxBpIDU + + ]]> + + + + 182: The Weight of Javascript + https://podcast.thoughtbot.com/182 + df563f9c-7bb6-4845-83e5-5d16bb4ddfcb + Mon, 15 Feb 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Ben finalizes Formkeep's Ember removal, toys with the idea of manual on boarding, and positions himself to begin experimenting with plans and pricing. Meanwhile, Chris deals with credit card fraud, too many inodes on Upcase's server, and finishes the changes required to offer free videos. + 49:15 + no + + <p>Ben finalizes Formkeep's Ember removal, toys with the idea of manual on boarding, and positions himself to begin experimenting with plans and pricing. Meanwhile, Chris deals with credit card fraud, too many inodes on Upcase's server, and finishes the changes required to offer free videos.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-182">Formkeep</a></li> +<li><a href="http://www.investopedia.com/articles/investing/013114/barbell-investment-strategy.asp">Barbell Investment Strategy</a></li> +<li><a href="http://blog.formkeep.com/designing-forms-that-convert/">Designing Forms That Convert</a></li> +<li><a href="https://thoughtbot.com/upcase/videos/gitsh">Free Gitsh Video</a> from The Weekly Iteration</li> +<li><a href="https://www.google.com/webhp?sourceid=chrome-instant&amp;ion=1&amp;espv=2&amp;ie=UTF-8#q=what%20is%202.5%20*%2026">What is 2.5 * 26?</a></li> +</ul> + + + + Ben finalizes Formkeep's Ember removal, toys with the idea of manual on boarding, and positions himself to begin experimenting with plans and pricing. Meanwhile, Chris deals with credit card fraud, too many inodes on Upcase's server, and finishes the changes required to offer free videos.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben finalizes Formkeep's Ember removal, toys with the idea of manual on boarding, and positions himself to begin experimenting with plans and pricing. Meanwhile, Chris deals with credit card fraud, too many inodes on Upcase's server, and finishes the changes required to offer free videos.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ics4YKHG + + ]]> + + + + 181: Tying Your Work to Impact (Brian Balfour) + https://podcast.thoughtbot.com/181 + 15c887d6-c43a-4196-a91c-dfd5953c1f62 + Mon, 08 Feb 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Chris talks with growth expert Brian Balfour on starting and sustaining SaaS business, and his team's approach to addressing growth issues. + 42:12 + no + + <p>Chris talks with growth expert Brian Balfour on starting and sustaining SaaS business, and his team's approach to addressing growth issues.</p> +<ul> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://www.pierrelechelle.com/aarrr-pirate-metrics">Pirate Metrics</a></li> +<li><a href="https://growthhackers.com/growth-studies/airbnb">Airbnb Growth Study</a></li> +<li><a href="http://www.coelevate.com/essays/growth-principle-one-be-the-best-at-getting-better">Be the Best at Getting Better</a></li> +<li><a href="http://www.coelevate.com/essays/traction-vs-growth">Traction vs Growth</a></li> +<li><a href="http://www.coelevate.com/essays/customer-acquisition">How to Become a Customer Acquisition Expert</a></li> +<li><a href="http://www.forbes.com/sites/ralphbenko/2014/10/13/peter-thiel-we-dont-live-in-a-normal-world-we-live-under-a-power-law">Power Law</a></li> +<li><a href="http://www.coelevate.com/">Coelevate</a>- Brian’s personal writings</li> +<li><a href="https://twitter.com/bbalfour">Brian on Twitter</a></li> +</ul> + + + + Chris talks with growth expert Brian Balfour on starting and sustaining SaaS business, and his team's approach to addressing growth issues.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris talks with growth expert Brian Balfour on starting and sustaining SaaS business, and his team's approach to addressing growth issues.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_SiOyJn0 + + ]]> + + + + 180: We Don't Deal With Paper + https://podcast.thoughtbot.com/180 + 1da0e8fa-6c6d-43fb-9340-3abc6d8979c5 + Mon, 01 Feb 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Chris gets a surprise while reviewing Upcase's Q4 profit & loss statement, gains some insight into e-mail marketing, wrestles with the added complexity of adding github auth-to-access, and brainstorms new community-driven projects. Meanwhile, Ben gets his hands dirty with Formkeep's Ember removal, is tempted by the siren's call of distraction, and gets an open review from the Bootstrapped Web podcast. Also, Chris does a live user-test of Formkeep's new user activation flow. + 48:03 + no + + <p>Chris gets a surprise while reviewing Upcase's Q4 profit &amp; loss statement, gains some insight into e-mail marketing, wrestles with the added complexity of adding github auth-to-access, and brainstorms new community-driven projects. Meanwhile, Ben gets his hands dirty with Formkeep's Ember removal, is tempted by the siren's call of distraction, and gets an open review from the Bootstrapped Web podcast. Also, Chris does a live user-test of Formkeep's new user activation flow.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-180">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="http://christoomey.yourkwagent.com/">The Chris Toomey of Real Estate</a></li> +<li><a href="http://calnewport.com/books/deep-work/"><em>Deep Work</em></a>- Cal Newport</li> +<li><a href="http://bootstrappedweb.com/98-website-teardowns-a-form-builder-invoicing-and-wordpress-products/">Bootstrapped Web Ep 98</a>- Formkeep Teardown!</li> +<li><a href="https://xkcd.com/356/">xkcd: Nerd Sniping</a></li> +<li><a href="http://designingsocialinterfaces.com/patterns/Pave_the_Cowpaths">Pave the Cowpaths</a></li> +<li><a href="https://cooperpress.com/">Cooper Press</a></li> +</ul> + + + + Chris gets a surprise while reviewing Upcase's Q4 profit & loss statement, gains some insight into e-mail marketing, wrestles with the added complexity of adding github auth-to-access, and brainstorms new community-driven projects. Meanwhile, Ben gets his hands dirty with Formkeep's Ember removal, is tempted by the siren's call of distraction, and gets an open review from the Bootstrapped Web podcast. Also, Chris does a live user-test of Formkeep's new user activation flow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris gets a surprise while reviewing Upcase's Q4 profit & loss statement, gains some insight into e-mail marketing, wrestles with the added complexity of adding github auth-to-access, and brainstorms new community-driven projects. Meanwhile, Ben gets his hands dirty with Formkeep's Ember removal, is tempted by the siren's call of distraction, and gets an open review from the Bootstrapped Web podcast. Also, Chris does a live user-test of Formkeep's new user activation flow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+DDIJXDhV + + ]]> + + + + 179: It's Tough to Iterate on Nothing + https://podcast.thoughtbot.com/179 + 4d051b16-5f47-4336-b172-9eb4711f8f80 + Mon, 25 Jan 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Ben resolves to cut back on dashboard checkins, makes progress on Formkeep's Ember extraction, and struggles with product-market fit. Meanwhile, Chris tackles some analytics issues, opens up Upcase landing pages from behind the paywall to improve marketing and SEO, and steps up his marketing and social-media game. + 58:32 + no + + <p>Ben resolves to cut back on dashboard checkins, makes progress on Formkeep's Ember extraction, and struggles with product-market fit. Meanwhile, Chris tackles some analytics issues, opens up Upcase landing pages from behind the paywall to improve marketing and SEO, and steps up his marketing and social-media game.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-179">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://baremetrics.com/">baremetrics</a></li> +<li><a href="http://blog.formkeep.com/">Formkeep Blog</a></li> +<li><a href="https://www.goodreads.com/book/show/4099.The_Pragmatic_Programmer"><em>The Pragmatic Programmer</em></a></li> +<li><a href="https://www.goodreads.com/book/show/833015.Spin_Selling"><em>SPIN Selling</em></a></li> +<li><a href="http://firstround.com/review/radical-candor-the-surprising-secret-to-being-a-good-boss/">Radical Candor</a></li> +<li><a href="http://bootstrappedweb.com/">Bootstrapped Web Podcast</a></li> +</ul> + + + + Ben resolves to cut back on dashboard checkins, makes progress on Formkeep's Ember extraction, and struggles with product-market fit. Meanwhile, Chris tackles some analytics issues, opens up Upcase landing pages from behind the paywall to improve marketing and SEO, and steps up his marketing and social-media game.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben resolves to cut back on dashboard checkins, makes progress on Formkeep's Ember extraction, and struggles with product-market fit. Meanwhile, Chris tackles some analytics issues, opens up Upcase landing pages from behind the paywall to improve marketing and SEO, and steps up his marketing and social-media game.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7NMRtIf- + + ]]> + + + + 178: No-one Wants Form End-Points for Christmas + https://podcast.thoughtbot.com/178 + ddb7ae40-9ac1-4b48-956a-63d21afbf085 + Mon, 18 Jan 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Ben and Chris both struggle with cancelations coming into the new year, Formkeep continues to strip out Ember and focus on content marketing, and Upcase resolves a major issue in the exercise system and improves the checkout flow. + 1:05:28 + no + + <p>Ben and Chris both struggle with cancelations coming into the new year, Formkeep continues to strip out Ember and focus on content marketing, and Upcase resolves a major issue in the exercise system and improves the checkout flow.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-178">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month"><em>The Mythical Man-Month</em></a></li> +<li><a href="https://en.wikipedia.org/wiki/Levenshtein_distance">Levenshtein Distance</a></li> +<li><a href="http://meetedgar.com/">Edgar</a></li> +<li><a href="http://giantrobots.fm/174">Laura Roeder on <em>Giant Robots</em></a></li> +<li><a href="https://medium.com/keep-learning-keep-growing/the-4-part-system-ive-used-for-4-years-to-achieve-10x-productivity-40ec9e3c770e#.ia0mun9ir">How to 3x your productivity in 10 minutes a week</a>- Mitchell Harper</li> +<li><a href="http://gitolite.com/gitolite/index.html">gitolite</a></li> +<li><a href="https://youtu.be/QMU6SjMZq1Q">Test All the F***in Time</a></li> +<li><a href="https://vimeo.com/47465229">Finding Your Flywheel</a>- Rob Walling</li> +<li><a href="https://www.goodreads.com/book/show/833015.Spin_Selling">SPIN Selling</a></li> +</ul> + + + + Ben and Chris both struggle with cancelations coming into the new year, Formkeep continues to strip out Ember and focus on content marketing, and Upcase resolves a major issue in the exercise system and improves the checkout flow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Chris both struggle with cancelations coming into the new year, Formkeep continues to strip out Ember and focus on content marketing, and Upcase resolves a major issue in the exercise system and improves the checkout flow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MiqkikSl + + ]]> + + + + 177: I Forgot There Would Be Follow-On Tasks + https://podcast.thoughtbot.com/177 + 7be524f3-d149-462e-b548-e80c8e5e8bf0 + Mon, 11 Jan 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + Chris tracks new members after the release of the new Mastering Git course from Upcase, launches a drip e-mail campaign to attract more members, and focuses on increased content output. Ben continues removing Ember from Formkeep, rethinks an activation sequence A/B test, conducts user tests to improve the checkout flow, and adopts a mindset of continuous improvement. + 52:47 + no + + <p>Chris tracks new members after the release of the new Mastering Git course from Upcase, launches a drip e-mail campaign to attract more members, and focuses on increased content output. Ben continues removing Ember from Formkeep, rethinks an activation sequence A/B test, conducts user tests to improve the checkout flow, and adopts a mindset of continuous improvement.</p> +<ul> +<li><a href="https://formkeep.com/?utm_source=podcast-episode&amp;utm_medium=show-notes&amp;utm_campaign=giant-robots-177">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="https://upcase.com/mastering-git">Mastering Git</a> course on Upcase</li> +<li><a href="https://zapier.com/learn/ultimate-guide-to-email-marketing-apps/drip-marketing-campaign/">Drip Marketing</a></li> +<li><a href="https://youtu.be/3haAWU0oiuw">Mastermind Alliance</a></li> +<li><a href="http://playbook.samaltman.com/">Startup Playbook</a>- Sam Altman</li> +<li><a href="http://giantrobots.fm/113">Rob Walling on <em>Giant Robots</em></a></li> +<li><a href="https://vimeo.com/70901901">How to 10x in 15 Months</a></li> +<li><a href="http://priceonomics.com/the-content-marketing-handbook/">The Content Marketing Handbook</a></li> +<li><a href="http://priceonomics.com/hotels/">Airbnb vs Hotels</a></li> +<li><a href="http://www.harpercollins.com/9780060833459/the-effective-executive"><em>The Effective Executive</em></a>- Peter F. Drucker</li> +</ul> + + + + Chris tracks new members after the release of the new Mastering Git course from Upcase, launches a drip e-mail campaign to attract more members, and focuses on increased content output. Ben continues removing Ember from Formkeep, rethinks an activation sequence A/B test, conducts user tests to improve the checkout flow, and adopts a mindset of continuous improvement.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chris tracks new members after the release of the new Mastering Git course from Upcase, launches a drip e-mail campaign to attract more members, and focuses on increased content output. Ben continues removing Ember from Formkeep, rethinks an activation sequence A/B test, conducts user tests to improve the checkout flow, and adopts a mindset of continuous improvement.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+LvddUO-l + + ]]> + + + + 176: The Pricing is Right + https://podcast.thoughtbot.com/176 + bcfcd1d2-0c3a-4af2-889f-8405f8842542 + Mon, 04 Jan 2016 00:00:00 -0500 + thoughtbot + + full + 5 + thoughtbot + As Ben transitions from Upcase to Formkeep, so too will the podcast transition to an open discussion around growing thoughtbot's internal projects and maintaining them as businesses, highlighting our hopes, experiments, tactics, failures, and success along the way! Today Ben and new co-host Chris discuss finding that magic feature or metric around which to structure pricing, selecting the right framework for your app, and customer acquisition tactics. + 54:34 + no + + <p>As Ben transitions from Upcase to Formkeep, so too will the podcast transition to an open discussion around growing thoughtbot's internal projects and maintaining them as businesses, highlighting our hopes, experiments, tactics, failures, and success along the way! Today Ben and new co-host Chris discuss finding that magic feature or metric around which to structure pricing, selecting the right framework for your app, and customer acquisition tactics.</p> +<ul> +<li><a href="https://formkeep.com/">Formkeep</a></li> +<li><a href="https://thoughtbot.com/upcase">Upcase</a></li> +<li><a href="http://www.priceintelligently.com/">Price Intelligently</a></li> +<li><a href="http://audienceops.com/">Audience Ops</a></li> +<li><a href="http://bootstrappedweb.com/">Bootstrapped Web Podcast</a></li> +<li><a href="https://middlemanapp.com/">Middleman</a></li> +<li><a href="http://tractionbook.com/"><em>Traction</em></a></li> +<li><a href="http://wistia.com/doc/turnstile">Wistia Turnstile</a></li> +<li><a href="http://giantrobots.fm/113">Rob Walling on <em>Giant Robots</em></a></li> +<li><a href="https://vwo.com/">Visual Website Optimizer</a></li> +<li><a href="https://upcase.com/mastering-git">Mastering Git</a> course on Upcase</li> +<li><a href="https://twitter.com/christoomey">Chris on Twitter</a></li> +</ul> + + + + As Ben transitions from Upcase to Formkeep, so too will the podcast transition to an open discussion around growing thoughtbot's internal projects and maintaining them as businesses, highlighting our hopes, experiments, tactics, failures, and success along the way! Today Ben and new co-host Chris discuss finding that magic feature or metric around which to structure pricing, selecting the right framework for your app, and customer acquisition tactics.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + As Ben transitions from Upcase to Formkeep, so too will the podcast transition to an open discussion around growing thoughtbot's internal projects and maintaining them as businesses, highlighting our hopes, experiments, tactics, failures, and success along the way! Today Ben and new co-host Chris discuss finding that magic feature or metric around which to structure pricing, selecting the right framework for your app, and customer acquisition tactics.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+XKXMjA_g + + ]]> + + + + 175: Broaden Your Worldview (Ashe Dryden) + https://podcast.thoughtbot.com/175 + 5482fe95-fe0b-4c17-a8cd-c84a1d69cdd3 + Mon, 21 Dec 2015 00:00:00 -0500 + thoughtbot + + full + 4 + thoughtbot + Ben talks with Ashe Dryden about ways to approach diversity in the tech community from workplace, conference, and personal perspectives. + 30:04 + no + + <p>Ben talks with Ashe Dryden about ways to approach diversity in the tech community from workplace, conference, and personal perspectives.</p> +<ul> +<li><a href="http://www.alterconf.com/">AlterConf</a></li> +<li><a href="https://leanpub.com/the-diverse-team"><em>The Diverse Team</em></a></li> +<li><a href="https://leanpub.com/diverseconfs"><em>The Inclusive Event</em></a></li> +<li><a href="https://modelviewculture.com/">Model View Culture</a></li> +<li><a href="https://vimeo.com/108143657">Brianna Wu - 9 Ways to Stop Hurting and Start Helping Women in Tech</a></li> +<li><a href="http://joinfundclub.com/">Fund Club</a></li> +<li><a href="https://twitter.com/ashedryden">Ashe on Twitter</a></li> +</ul> + + + + Ben talks with Ashe Dryden about ways to approach diversity in the tech community from workplace, conference, and personal perspectives.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Ashe Dryden about ways to approach diversity in the tech community from workplace, conference, and personal perspectives.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jhAe-kqz + + ]]> + + + + 174: Building Character (Laura Roeder) + https://podcast.thoughtbot.com/174 + f4437be0-7790-4d02-bea5-99dc740b4657 + Mon, 14 Dec 2015 12:00:00 -0500 + thoughtbot + + full + 4 + thoughtbot + Ben and Laura Roeder, founder of Edgar, chat about anthropomorphizing your brand to build better engagement, going the extra step to care about customer success, and some tips for social media marketing best practices. + 29:43 + no + + <p>Ben and Laura Roeder, founder of Edgar, chat about anthropomorphizing your brand to build better engagement, going the extra step to care about customer success, and some tips for social media marketing best practices.</p> +<p>This episode is brought to you by <a href="https://formkeep.com/?utm_source=giant-robots-podcast&amp;utm_medium=show-notes&amp;utm_campaign=ep-174">Formkeep</a>: Form endpoints for designers and developers</p> +<ul> +<li><a href="http://meetedgar.com/">Edgar</a></li> +<li><a href="http://scopcity.com/love-name-edgar/">Edgar is my boyfriend</a>- Sticker shown at the top of this glowing love-letter to Edgar</li> +<li><a href="https://playbook.thoughtbot.com/">thoughtbot Playbook</a></li> +<li><a href="https://twitter.com/lkr">Laura on Twitter</a></li> +</ul> + + + + Ben and Laura Roeder, founder of Edgar, chat about anthropomorphizing your brand to build better engagement, going the extra step to care about customer success, and some tips for social media marketing best practices.

+ +

This episode is brought to you by Formkeep: Form endpoints for designers and developers

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Laura Roeder, founder of Edgar, chat about anthropomorphizing your brand to build better engagement, going the extra step to care about customer success, and some tips for social media marketing best practices.

+ +

This episode is brought to you by Formkeep: Form endpoints for designers and developers

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+VSX_2-H5 + + ]]> + + + + 173: Obsessed With Helping (Hiten Shah) + https://podcast.thoughtbot.com/173 + 8cca3580-fd95-4a9c-87ba-0e7b28479009 + Mon, 07 Dec 2015 00:00:00 -0500 + thoughtbot + + full + 4 + thoughtbot + Ben talks with Hiten Shah, co-founder of Crazy Egg and Kissmetrics, on the value of helping others, frameworks for a better life, being an infovore, and tips for finding a successful product niche. + 30:28 + no + + <p>Ben talks with Hiten Shah, co-founder of Crazy Egg and Kissmetrics, on the value of helping others, frameworks for a better life, being an infovore, and tips for finding a successful product niche.</p> +<ul> +<li><a href="https://upcase.com/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="http://www.crazyegg.com/visual-website-analytics">Crazy Egg</a></li> +<li><a href="https://www.kissmetrics.com/">Kissmetrics</a></li> +<li><a href="https://youtu.be/jwG_qR6XmDQ">Jeff Bezos - Regret Minimization Framework</a></li> +<li><a href="https://hitenism.com/hacks-for-infovores/">Hacks for Infovores</a></li> +<li><a href="http://paulgraham.com/good.html">&quot;Be Good&quot;</a>- Paul Graham</li> +<li><a href="http://theleanstartup.com/principles">The Lean Startup</a></li> +<li><a href="http://www.businessinsider.com/jack-dorsey-on-ceo-as-editor-2011-6">Jack Dorsey on CEO as Editor</a></li> +<li><a href="http://thestartupchat.com/">The Startup Chat Podcast</a></li> +<li><a href="http://hiten.com/">Saas Weekly</a></li> +<li><a href="https://twitter.com/hnshah">Hiten on Twitter</a></li> +</ul> + + + + Ben talks with Hiten Shah, co-founder of Crazy Egg and Kissmetrics, on the value of helping others, frameworks for a better life, being an infovore, and tips for finding a successful product niche.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Hiten Shah, co-founder of Crazy Egg and Kissmetrics, on the value of helping others, frameworks for a better life, being an infovore, and tips for finding a successful product niche.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+qDFYDRfw + + ]]> + + + + 172: Go After the Hard Stuff (Eric Normand) + https://podcast.thoughtbot.com/172 + 9a14ab67-6d7e-411a-a462-60f2850715f1 + Tue, 01 Dec 2015 00:00:00 -0500 + thoughtbot + + full + 4 + thoughtbot + Ben and Eric Normand of LispCast and PurelyFunctional.tv talk about the pros and cons of Haskell and Clojure, empathize on some of the pain points of running an educational coding platform, and hypothesize on how the next great programming "killer demo" will present itself. + 41:27 + no + + <p>Ben and Eric Normand of LispCast and PurelyFunctional.tv talk about the pros and cons of Haskell and Clojure, empathize on some of the pain points of running an educational coding platform, and hypothesize on how the next great programming &quot;killer demo&quot; will present itself.</p> +<ul> +<li><a href="https://upcase.com/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="http://www.lispcast.com/giantrobots">LispCast</a>- With welcome message for <em>Giant Robots</em> listeners</li> +<li><a href="http://www.purelyfunctional.tv/">PurelyFunctional.tv</a></li> +<li><a href="http://www.lispcast.com/nil-punning">Nil Punning</a></li> +<li><a href="https://www.kickstarter.com/projects/376627045/lispcast-introduction-to-clojure-videos/description">Original LispCast Kickstarter</a></li> +<li><a href="https://youtu.be/Gzj723LkRJY">Ruby on Rails 15 Minute Blog Demo</a></li> +<li><a href="https://twitter.com/ericnormand">Eric on Twitter</a></li> +</ul> + + + + Ben and Eric Normand of LispCast and PurelyFunctional.tv talk about the pros and cons of Haskell and Clojure, empathize on some of the pain points of running an educational coding platform, and hypothesize on how the next great programming "killer demo" will present itself.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Eric Normand of LispCast and PurelyFunctional.tv talk about the pros and cons of Haskell and Clojure, empathize on some of the pain points of running an educational coding platform, and hypothesize on how the next great programming "killer demo" will present itself.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+W6gSuFNz + + ]]> + + + + 171: Always Be Hustling (Steli Efti) + https://podcast.thoughtbot.com/171 + f71b184a-f8c8-4ded-bbec-b3f129420bbd + Mon, 23 Nov 2015 00:00:00 -0500 + thoughtbot + + full + 4 + thoughtbot + Ben talks with Steli Efti, CEO and Co-founder of Close, on maintaining energy and passion in speaking, why engineers make great sales people (and how they can be even better), and managing your emotions to be more productive and happy. + 37:39 + no + + <p>Ben talks with Steli Efti, CEO and Co-founder of Close, on maintaining energy and passion in speaking, why engineers make great sales people (and how they can be even better), and managing your emotions to be more productive and happy.</p> +<ul> +<li><a href="https://upcase.com/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="https://close.com/">Close</a></li> +<li><a href="https://vimeo.com/131441010">How to Build a Solo SaaS Sales Machine</a></li> +<li><a href="https://blog.close.com/engineer-sales-lessons">Engineers Vs Sales People</a></li> +<li><a href="http://thestartupchat.com/landing/">The Startup Chat</a></li> +<li><a href="https://twitter.com/Steli">Steli on Twitter</a></li> +</ul> + + + + Ben talks with Steli Efti, CEO and Co-founder of Close, on maintaining energy and passion in speaking, why engineers make great sales people (and how they can be even better), and managing your emotions to be more productive and happy.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Steli Efti, CEO and Co-founder of Close, on maintaining energy and passion in speaking, why engineers make great sales people (and how they can be even better), and managing your emotions to be more productive and happy.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mLC4gqlY + + ]]> + + + + 170: Make Things People Want (C. Todd Lombardo & Trace Wax) + https://podcast.thoughtbot.com/170 + 4c1bb4a2-6450-4aab-a987-03e6dbbb3e9f + Mon, 09 Nov 2015 00:00:00 -0500 + thoughtbot + + full + 4 + thoughtbot + Chad talks with C. Todd Lombardo & Trace Wax about their new book, co-authored with Richard Banfield, Design Sprint: A Practical Guidebook for Building Great Digital Products, as well as the process and benefits of design sprints. + 39:38 + no + + <p>Chad talks with C. Todd Lombardo &amp; Trace Wax about their new book, co-authored with Richard Banfield, Design Sprint: A Practical Guidebook for Building Great Digital Products, as well as the process and benefits of design sprints.</p> +<ul> +<li><a href="https://upcase.com/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="http://shop.oreilly.com/product/0636920038573.do"><em>Design Sprint: A Practical Guidebook for Building Great Digital Products</em></a></li> +<li><a href="http://giantrobots.fm/106"><em>Giant Robots</em> #106</a></li> +<li>The <a href="https://characterlab.org/character-growth-card">Character Growth Card</a> at <a href="https://characterlab.org">Character Lab</a></li> +<li><a href="http://www.sciencedirect.com/science/article/pii/S1057740811000829"><em>The IKEA Effect</em></a>- Michael Norton</li> +<li><a href="http://designmuseumfoundation.org/boston/about/">Design Museum Boston</a></li> +<li><a href="http://www.christenseninstitute.org/key-concepts/jobs-to-be-done/">Jobs to be Done Framework</a> and <a href="http://alanklement.blogspot.com/2013/09/replacing-user-story-with-job-story.html">Jobs Stories</a></li> +<li><a href="http://www.gotomeeting.com/">GoToMeeting</a></li> +<li><a href="http://theleanstartup.com/principles">Lean Startup Methodology</a></li> +<li><a href="http://tentative.fm/6"><em>Tentative</em> #6</a></li> +<li><a href="https://twitter.com/iamctodd">C. Todd on Twitter</a></li> +<li><a href="https://twitter.com/tracedwax">Trace on Twitter</a></li> +</ul> + + + + Chad talks with C. Todd Lombardo & Trace Wax about their new book, co-authored with Richard Banfield, Design Sprint: A Practical Guidebook for Building Great Digital Products, as well as the process and benefits of design sprints.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with C. Todd Lombardo & Trace Wax about their new book, co-authored with Richard Banfield, Design Sprint: A Practical Guidebook for Building Great Digital Products, as well as the process and benefits of design sprints.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Ycz56pBI + + ]]> + + + + 169: Purpose Driven Development (Sara Chipps) + https://podcast.thoughtbot.com/169 + 640ed6ad-ac0d-4743-88a9-17b886b7e5e5 + Thu, 05 Nov 2015 00:00:00 -0500 + thoughtbot + + full + 4 + thoughtbot + Brenda talks with Sara Chipps on the desire to educate in code, her inspiration to work on hardware, and the troubles of manufacturing. + 36:02 + no + + <p>Brenda talks with Sara Chipps on the desire to educate in code, her inspiration to work on hardware, and the troubles of manufacturing.</p> +<ul> +<li><a href="https://upcase.com/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="http://jewelbots.com/">Jewelbots</a></li> +<li><a href="http://2015.cssdevconf.com/">CSS Dev Conf</a></li> +<li><a href="https://www.girldevelopit.com/">Girl Develop It</a></li> +<li><a href="https://en.wikipedia.org/wiki/Mesh_networking">Mesh Networking</a></li> +<li><a href="http://www.usfirst.org/roboticsprograms/">FIRST Robotics Programs</a></li> +<li><a href="https://websummit.net/">Web Summit</a></li> +<li><a href="http://www.barbie.com/en-us/promotions/youcanbeanything">Barbie, You Can Be Anything Campaign</a></li> +<li><a href="http://nodebots.io/">NodeBots</a></li> +<li><a href="http://highway1.io/">Highway1</a></li> +<li><a href="https://twitter.com/sarajchipps">Sara on Twitter</a></li> +<li><a href="https://medium.com/@SaraJChipps/">Sara on Medium</a></li> +</ul> + + + + Brenda talks with Sara Chipps on the desire to educate in code, her inspiration to work on hardware, and the troubles of manufacturing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Brenda talks with Sara Chipps on the desire to educate in code, her inspiration to work on hardware, and the troubles of manufacturing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hxbLoxa- + + ]]> + + + + 168: 'Unpronounceable' (Star Simpson) + https://podcast.thoughtbot.com/168 + 4a26437d-a62c-4343-a9b7-7d7195a50edd + Tue, 27 Oct 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Chad Pytel and Laila Winner welcome Star Simpson to discuss PLIBMTTBHGATY (Programming Languages I’ve Been Meaning To Try But Haven’t Gotten Around To Yet), fostering community through meet-ups, and the finer points of taco delivery via drone. + 31:52 + no + + <p>Chad Pytel and Laila Winner welcome Star Simpson to discuss PLIBMTTBHGATY (Programming Languages I’ve Been Meaning To Try But Haven’t Gotten Around To Yet), fostering community through meet-ups, and the finer points of taco delivery via drone.</p> +<ul> +<li><a href="https://upcase.com/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="https://www.google.com/makani/">Makani</a></li> +<li><a href="http://tacocopter.com/">TacoCopter</a></li> +<li><a href="https://www.getcloudapp.com/">CloudApp</a></li> +<li><a href="http://blog.starsimpson.com/plibmttbhgaty">PLIBMTTBHGATY</a></li> +<li><a href="http://bikeshed.fm/34">Laila on <em>Bike Shed</em></a></li> +<li><a href="https://en.wikipedia.org/wiki/Brainfuck">Brain𝑓*ⓒ#</a></li> +<li><a href="http://plibmttbhgaty.com/">plibmttbhgaty.com</a></li> +<li><a href="http://news.mit.edu/2015/support-students-business-cyber-law-0909">MIT / BU Legal Clinic</a></li> +<li><a href="http://freedom2innovate.mit.edu/">Freedom to Innovate Summit</a></li> +<li><a href="http://starsimpson.com/#projects">Star's Projects</a></li> +<li><a href="https://twitter.com/starsandrobots">Star on Twitter</a></li> +<li><a href="https://twitter.com/malandr1na">Laila on Twitter</a></li> +<li><a href="https://twitter.com/cpytel">Chad on Twitter</a></li> +</ul> + + + + Chad Pytel and Laila Winner welcome Star Simpson to discuss PLIBMTTBHGATY (Programming Languages I’ve Been Meaning To Try But Haven’t Gotten Around To Yet), fostering community through meet-ups, and the finer points of taco delivery via drone.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad Pytel and Laila Winner welcome Star Simpson to discuss PLIBMTTBHGATY (Programming Languages I’ve Been Meaning To Try But Haven’t Gotten Around To Yet), fostering community through meet-ups, and the finer points of taco delivery via drone.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+XU_rJAKn + + ]]> + + + + 167: A Place For Both (Brenda Storer) + https://podcast.thoughtbot.com/167 + c624bb89-9a1d-4bbf-8d20-b53eaf93008f + Mon, 12 Oct 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben talks with thoughtbot designer Brenda Storer on fitting both development and design in her job title, tips for public speaking, and introduces a new change to the show. + 36:46 + no + + <p>Ben talks with thoughtbot designer Brenda Storer on fitting both development and design in her job title, tips for public speaking, and introduces a new change to the show.</p> +<ul> +<li><a href="https://upcase.com/halfoff">Upcase</a>: 50% Off Your First Month For Giant Robots Listeners!</li> +<li><a href="https://www.girldevelopit.com/">Girl Develop It</a></li> +<li><a href="http://2015.cssdevconf.com/">CSS Dev Conf</a></li> +<li><a href="http://fourhourworkweek.com/podcast/">The Tim Ferriss Show</a></li> +<li><a href="http://www.startupsfortherestofus.com/">Startups for the Rest of Us</a></li> +<li><a href="http://www.earwolf.com/show/comedy-bang-bang/">Comedy Bang Bang</a></li> +<li><a href="http://bikeshed.fm/">The Bike Shed</a></li> +<li><a href="http://www.savagelovecast.com/">Savage Lovecast</a></li> +</ul> +<p>Get to know your new sometimes-host better!</p> +<ul> +<li><a href="https://twitter.com/brendamarienyc">Brenda on Twitter</a></li> +<li><a href="http://rebootshow.fm/2">Brenda on <em>Reboot</em> Podcast</a></li> +<li><a href="http://tentative.fm/10">Brenda on <em>Tentative</em> Podcast</a></li> +</ul> + + + + Ben talks with thoughtbot designer Brenda Storer on fitting both development and design in her job title, tips for public speaking, and introduces a new change to the show.

+ + + +

Get to know your new sometimes-host better!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with thoughtbot designer Brenda Storer on fitting both development and design in her job title, tips for public speaking, and introduces a new change to the show.

+ + + +

Get to know your new sometimes-host better!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Qe7JvKx3 + + ]]> + + + + 166: Refactoring Health Care (John Norman) + https://podcast.thoughtbot.com/166 + e433ff1c-7091-4013-834b-0ff9ff5b23ea + Mon, 05 Oct 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben talks with John Norman about his process and modified approach to the delivery, payment, and tech of modern managed health care. They also touch on age bias in the programming world, living a purpose-driven life, and dealing with startup growth. + 40:13 + no + + <p>Ben talks with John Norman about his process and modified approach to the delivery, payment, and tech of modern managed health care. They also touch on age bias in the programming world, living a purpose-driven life, and dealing with startup growth.</p> +<ul> +<li><a href="http://www.iorahealth.com/">Iora Health</a></li> +<li><a href="http://www.newyorker.com/magazine/2011/01/24/the-hot-spotters">&quot;The Hot Spotters&quot;</a>- Atul Gawande</li> +<li><a href="https://www.goodreads.com/book/show/6402544-the-healing-of-america"><em>The Healing of America</em></a>- T.R. Reid</li> +<li><a href="http://www.wellnessfx.com/">WellnessFX</a></li> +<li><a href="http://www.agilemanifesto.org/">Agile Manifesto</a></li> +<li><a href="https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act">HIPAA</a></li> +<li><a href="http://atulgawande.com/book/being-mortal/"><em>Being Mortal</em></a>- Atul Gawande</li> +<li><a href="http://adam.herokuapp.com/past/2011/4/28/scaling_a_development_team/">&quot;How to Scale a Development Team&quot;</a>- Adam Wiggins</li> +<li><a href="http://www.peterme.com/2013/09/26/the-double-diamond-model-of-product-definition-and-design/">&quot;The Double Diamond Model of Product Definition and Design&quot;</a>- Peter Merholz</li> +<li><a href="https://twitter.com/tuke">John on Twitter</a></li> +</ul> + + + + Ben talks with John Norman about his process and modified approach to the delivery, payment, and tech of modern managed health care. They also touch on age bias in the programming world, living a purpose-driven life, and dealing with startup growth.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with John Norman about his process and modified approach to the delivery, payment, and tech of modern managed health care. They also touch on age bias in the programming world, living a purpose-driven life, and dealing with startup growth.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+RECx6xLL + + ]]> + + + + 165: Everyone's Welcome Here (Adam Stacoviak & Jerod Santo) + https://podcast.thoughtbot.com/165 + 7a270e65-4036-404c-8825-4a0dc2ce8d9f + Mon, 28 Sep 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben talks with Adam & Jerod of The Changelog Podcast to discuss their personal interviewing modalities, doing full-time media creation, and a new video project aimed to explore the actual people behind your programming heroes. + 43:05 + no + + <p>Ben talks with Adam &amp; Jerod of The Changelog Podcast to discuss their personal interviewing modalities, doing full-time media creation, and a new video project aimed to explore the actual people behind your programming heroes.</p> +<ul> +<li><a href="https://changelog.com/">The Changelog</a></li> +<li><a href="https://changelog.com/beyond-code-season-1-teaser-trailer-1/">Beyond Code</a></li> +<li><a href="http://keeprubyweird.com/">Keep Ruby Weird</a></li> +<li><a href="http://themoth.org/">The Moth</a></li> +<li><a href="https://youtu.be/xGytDsqkQY8">Semisonic- &quot;Closing Time&quot;</a></li> +<li><a href="http://wistia.com/">Wistia</a></li> +<li><a href="http://giantrobots.fm/65">Wistia on Giant Robots</a></li> +<li><a href="https://thoughtbot.com/podcasts">thoughtbot's Podcasts</a> (just in case you didn't already know about our other great shows)</li> +<li><a href="https://github.com/thechangelog/ping">Ping The Changelog</a></li> +<li><a href="https://changelog.com/weekly/">Changelog Weekly</a></li> +<li><a href="https://twitter.com/adamstac">Adam On Twitter</a></li> +<li><a href="https://twitter.com/jerodsanto">Jerod on Twitter</a></li> +</ul> + + + + Ben talks with Adam & Jerod of The Changelog Podcast to discuss their personal interviewing modalities, doing full-time media creation, and a new video project aimed to explore the actual people behind your programming heroes.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Adam & Jerod of The Changelog Podcast to discuss their personal interviewing modalities, doing full-time media creation, and a new video project aimed to explore the actual people behind your programming heroes.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Ffpzi9zG + + ]]> + + + + 164: Transcribing at 260 wpm (Mirabai Knight) + https://podcast.thoughtbot.com/164 + e09746dd-a386-4a9f-93d1-1dba38a98013 + Mon, 21 Sep 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben talks with Mirabai Knight about the technology and uses of modern stenography; including using steno with Vim, and her work on Plover, the open source Steno engine. + 36:50 + no + + <p>Ben talks with Mirabai Knight about the technology and uses of modern stenography; including using steno with Vim, and her work on Plover, the open source Steno engine.</p> +<ul> +<li><a href="http://stenoknight.com/">StenoKnight CART Services</a></li> +<li><a href="http://podcasts.thoughtbot.s3.amazonaws.com/Giant%20Robots/GR164_Transcript.txt">Giant Robots 164 Transcript</a></li> +<li><a href="http://www.whitecoatcaptioning.com/">White Coat Captioning</a></li> +<li><a href="https://en.wikipedia.org/wiki/Stenotype">Stenotype</a></li> +<li><a href="http://stenoknight.com/plover/plover-alphabetical.jpg">Steno Alphabet Chart</a></li> +<li><a href="http://giantrobots.fm/160">Drew Neil on <em>Giant Robots</em></a></li> +<li><a href="http://openstenoproject.org/">Plover</a>: The Open Steno Project</li> +<li><a href="https://www.youtube.com/watch?v=62l64Acfidc">How Stenography Works</a></li> +<li><a href="http://stenoboard.com/">Stenoboard</a>- 3D Printed Kit</li> +<li><a href="http://stenosaurus.com/">Stenosaurus</a></li> +<li><a href="http://plover.stenoknight.com/2015/07/success-stories-from-steno-autodidacts.html">Success Stories from Steno Autodidacts</a></li> +<li><a href="https://www.youtube.com/watch?v=MuVUGKBOp9Q">Using Plover with Vim for Captioning</a></li> +<li><a href="https://www.youtube.com/watch?v=jRFKZGWrmrM">Coding in Python with Plover</a></li> +<li><a href="https://twitter.com/stenoknight">Mirabai On Twitter</a></li> +</ul> + + + + Ben talks with Mirabai Knight about the technology and uses of modern stenography; including using steno with Vim, and her work on Plover, the open source Steno engine.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Mirabai Knight about the technology and uses of modern stenography; including using steno with Vim, and her work on Plover, the open source Steno engine.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+lOyVJNLz + + ]]> + + + + 163: Play is the Best Way to Learn (Nadia Odunayo) + https://podcast.thoughtbot.com/163 + 35f67951-7cf7-4a84-b80b-1cafcdf591a5 + Mon, 14 Sep 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben talks with Nadia Odunayo about giving non-technical conference talks and full-time pairing. + 31:37 + no + + <p>Ben talks with Nadia Odunayo about giving non-technical conference talks and full-time pairing.</p> +<ul> +<li><a href="http://confreaks.tv/videos/railsconf2015-playing-games-in-the-clouds">Playing Games in the Clouds</a>- Nadia's 2015 RailsConf Talk</li> +<li><a href="https://floobits.com/help/faq">Floobits</a></li> +<li><a href="http://www.makersacademy.com/">Makers Academy</a></li> +<li><a href="http://rubyconf.org/">RubyConf</a></li> +<li><a href="https://twitter.com/nodunayo">Nadia On Twitter</a></li> +</ul> + + + + Ben talks with Nadia Odunayo about giving non-technical conference talks and full-time pairing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Nadia Odunayo about giving non-technical conference talks and full-time pairing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+yyILl8vd + + ]]> + + + + 162: Literal Giant Robots (Brinkley Warren) + https://podcast.thoughtbot.com/162 + 171c55c0-f7b2-4adc-89a7-b3789bf3b4f1 + Tue, 08 Sep 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben is joined by Brinkley Warren of MegaBots Inc. to discuss the history, build, and strategy behind the MegaBot Mk II, USA's entrant in next years giant robot duel! + 23:25 + no + + <p>Ben is joined by Brinkley Warren of MegaBots Inc. to discuss the history, build, and strategy behind the MegaBot Mk II, USA's entrant in next years giant robot duel!</p> +<ul> +<li><a href="https://www.kickstarter.com/projects/megabots/support-team-usa-in-the-giant-robot-duel">MegaBots Giant Robot Duel Kickstarter</a></li> +<li><a href="http://www.megabots.com/">MegaBots Inc.</a> (with initial challenge videos)</li> +<li><a href="http://www.theroboticschallenge.org/">Darpa Robotics Challenge</a></li> +<li><a href="http://www.ihmc.us/">IHMC</a></li> +<li><a href="https://en.wikipedia.org/wiki/Grant_Imahara">Grant Imahara</a></li> +<li><a href="https://twitter.com/MegaBotsInc">MegaBots On Twitter</a></li> +<li><a href="https://twitter.com/brinkwar">Brinkley On Twitter</a></li> +</ul> + + + + Ben is joined by Brinkley Warren of MegaBots Inc. to discuss the history, build, and strategy behind the MegaBot Mk II, USA's entrant in next years giant robot duel!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by Brinkley Warren of MegaBots Inc. to discuss the history, build, and strategy behind the MegaBot Mk II, USA's entrant in next years giant robot duel!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+LfLH4xVv + + ]]> + + + + 161: Listen to Your Users (Jules Coleman) + https://podcast.thoughtbot.com/161 + 7c8d7b07-3fef-417b-9fd5-66ea0601479a + Mon, 31 Aug 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben and Jules Coleman, founder of Hassle, discuss staying close to the codebase while in a more managerial role, the challenges of rapid growth, and the value of internalizing feedback. + 28:38 + no + + <p>Ben and Jules Coleman, founder of Hassle, discuss staying close to the codebase while in a more managerial role, the challenges of rapid growth, and the value of internalizing feedback.</p> +<ul> +<li><a href="https://hassle.com/uk">Hassle</a></li> +<li><a href="https://en.wikipedia.org/wiki/Kaizen">Kaizen</a></li> +<li><a href="http://teddle.tumblr.com/post/42016690099/the-shit-that-techcrunch-doesnt-tell-you">The Shit That TechCrunch Doesn't Tell You</a></li> +<li><a href="https://twitter.com/julescoleman">Jules On Twitter</a></li> +</ul> + + + + Ben and Jules Coleman, founder of Hassle, discuss staying close to the codebase while in a more managerial role, the challenges of rapid growth, and the value of internalizing feedback.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Jules Coleman, founder of Hassle, discuss staying close to the codebase while in a more managerial role, the challenges of rapid growth, and the value of internalizing feedback.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8hwRJ-49 + + ]]> + + + + 160: Unfollowing the Leader (Drew Neil) + https://podcast.thoughtbot.com/160 + 8c6bdeb8-0e54-4b20-b4a2-5b577bea1246 + Wed, 26 Aug 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben and Drew Neil discuss freeing up Vim's leader key, the value of visual learning, and using GitHub to crowd source closed captions. + 30:49 + no + + <p>Ben and Drew Neil discuss freeing up Vim's leader key, the value of visual learning, and using GitHub to crowd source closed captions.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +<li><a href="http://retronyms.com/pod">Retronyms</a>: Make music whenever, wherever. Tap your inspiration and remember to keep it fresh. Visit to get a free download of AudioCopy.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://vimeo.com/85343734">Follow My Leader</a></li> +<li><a href="https://github.com/tpope/vim-speeddating">speeddating.vim</a></li> +<li><a href="http://www.vim.org/scripts/script.php?script_id=1567">rails.vim</a></li> +<li><a href="https://github.com/tpope/vim-unimpaired">unimpaired.vim</a></li> +<li><a href="https://github.com/tpope/vim-surround">surround.vim</a></li> +<li><a href="http://vimcasts.org/">Vimcasts</a></li> +<li><a href="https://pragprog.com/book/dnvim/practical-vim"><em>Practical Vim</em></a></li> +<li><a href="http://peertopeer.io/">Peer to Peer</a></li> +<li><a href="http://vimcasts.org/episodes/modal-editing-undo-redo-and-repeat/">Vimcasts #12</a>: Modal editing: undo, redo and repeat</li> +<li><a href="http://neovim.io/">Neovim</a></li> +<li><a href="https://twitter.com/nelstrom">Drew On Twitter</a></li> +</ul> + + + + Ben and Drew Neil discuss freeing up Vim's leader key, the value of visual learning, and using GitHub to crowd source closed captions.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
  • Retronyms: Make music whenever, wherever. Tap your inspiration and remember to keep it fresh. Visit to get a free download of AudioCopy.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Drew Neil discuss freeing up Vim's leader key, the value of visual learning, and using GitHub to crowd source closed captions.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
  • Retronyms: Make music whenever, wherever. Tap your inspiration and remember to keep it fresh. Visit to get a free download of AudioCopy.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+yv7_5y7t + + ]]> + + + + 159: Falling Out of Love With Haskell (Mike Burns) + https://podcast.thoughtbot.com/159 + 5e519536-d31b-40d4-a07c-9428e8657e46 + Mon, 17 Aug 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben and fellow thoughtbotter Mike Burns take time out of their Summer Summit schedule to chat about launching offices, the art of classical code, and why Mike no longer loves Haskell. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account. + 23:02 + no + + <p>Ben and fellow thoughtbotter Mike Burns take time out of their Summer Summit schedule to chat about launching offices, the art of classical code, and why Mike no longer loves Haskell.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://www.meetup.com/The-Classical-Code-Reading-Group-of-Stockholm/">The Classical Code Reading Group of Stockholm</a></li> +<li><a href="http://www.rottentomatoes.com/m/hackers/"><em>Hackers</em></a></li> +<li><a href="http://www.openbsd.org/">OpenBSD</a></li> +<li><a href="https://twitter.com/mikeburns">Mike On Twitter</a></li> +</ul> + + + + Ben and fellow thoughtbotter Mike Burns take time out of their Summer Summit schedule to chat about launching offices, the art of classical code, and why Mike no longer loves Haskell.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and fellow thoughtbotter Mike Burns take time out of their Summer Summit schedule to chat about launching offices, the art of classical code, and why Mike no longer loves Haskell.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+sRvxJDQ0 + + ]]> + + + + 158: Producing...Stuff (Thom Obarski) + https://podcast.thoughtbot.com/158 + 9e9184cb-a488-40cb-904d-64368ec1991d + Mon, 10 Aug 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben is joined by trepidatious producer, Thom Obarski, to talk all things media at thoughtbot, compare working in tech to entertainment environments, and bestow some beginner advice on starting one's own podcast. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account. + 31:04 + no + + <p>Ben is joined by trepidatious producer, Thom Obarski, to talk all things media at thoughtbot, compare working in tech to entertainment environments, and bestow some beginner advice on starting one's own podcast.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://web.archive.org/web/20130729204551id_/http://www.conversationsnetwork.org/levelator/">Levelator</a></li> +<li><a href="http://genius.com/Ben-orenstein-open-your-world-for-commentary-annotated">Ben, transcribed &amp; annotated</a></li> +<li><a href="http://giantrobots.fm/81">Seth Godin Episode of <em>Giant Robots</em></a></li> +<li><a href="https://robots.thoughtbot.com/were-hiring-a-producer">Original Producer Position Posting</a></li> +<li><a href="https://thoughtbot.com/podcasts">Acitve thoughtbot Podcasts</a></li> +<li><a href="http://www.imdb.com/name/nm2020931/">Thom on IMDB</a></li> +<li><a href="https://www.youtube.com/user/ThoughtbotVideo">thoughtbot Youtube</a> <em>(Warning, a welcome video autoplays if you're not already a subscriber)</em></li> +<li><a href="https://youtu.be/9rxqgAbPDWE">Ben's first blooper reel</a></li> +<li><a href="https://www.youtube.com/playlist?list=PL8tzorAO7s0jgDqcDD0HJ2W2eN6sx0w5w">Robots at Play</a> Video Playlist</li> +<li><a href="https://gist.github.com/ThoughtbotThom/01115cd635fbd45d19c7">Thom's Investment Time</a></li> +<li><a href="http://wistia.com/">Wistia</a></li> +<li><a href="http://giantrobots.fm/65">Wista on <em>Giant Robots</em></a></li> +<li><a href="http://25.io/mou/">Mou</a></li> +<li><a href="https://gist.github.com/ThoughtbotThom/f26db5f2fb42e787310d#file-podcasting-for-0-down-md"><em>Podcasting for $0 Down</em></a>- Submitted talk proposal</li> +<li><a href="https://podclear.com/#/">Podclear</a></li> +<li><a href="https://twitter.com/thoughtbotThom">Thom on Twitter</a></li> +</ul> + + + + Ben is joined by trepidatious producer, Thom Obarski, to talk all things media at thoughtbot, compare working in tech to entertainment environments, and bestow some beginner advice on starting one's own podcast.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by trepidatious producer, Thom Obarski, to talk all things media at thoughtbot, compare working in tech to entertainment environments, and bestow some beginner advice on starting one's own podcast.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rpIS7Pso + + ]]> + + + + 157: Between Frustration and Enlightenment (Tom Stuart) + https://podcast.thoughtbot.com/157 + 1c5cd5d5-4279-47a8-96d3-bbd1565f871a + Mon, 03 Aug 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben is joined by Tom Stuart to talk about incorporating computer science topics into Ruby, his process of preparing talks, enriching your development career with a bit of computer science knowledge, and gushing about how amazing computers truly are. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account. + 46:17 + no + + <p>Ben is joined by Tom Stuart to talk about incorporating computer science topics into Ruby, his process of preparing talks, enriching your development career with a bit of computer science knowledge, and gushing about how amazing computers truly are.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://codon.com/refactoring-ruby-with-monads">Refactoring Ruby With Monads</a></li> +<li><a href="http://codon.com/a-lever-for-the-mind">A Lever for the Mind</a></li> +<li><a href="http://www.nand2tetris.org/book.php"><em>The Elements of Computing Systems</em></a> (From NAND to Tetris)</li> +<li><a href="https://www.omnigroup.com/omnioutliner">OmniOutliner</a></li> +<li><a href="http://russelldavies.typepad.com/planning/2015/06/doing-the-hard-work-to-make-it-bearable.html">&quot;Doing the hard work to make it bearable&quot;</a>- Russell Davies</li> +<li><a href="https://youtu.be/4Sso4HtvJsw">To the Moon!</a>-Russ Olsen</li> +<li><a href="http://genius.com/Ben-orenstein-open-your-world-for-commentary-annotated">Ben, transcribed &amp; annotated</a></li> +<li><a href="http://computationbook.com/"><em>Understanding Computation</em></a>- Tom Stuart</li> +<li><a href="http://rubywebapp.com/"><em>How to Write a Web Application in Ruby</em></a></li> +<li><a href="http://lrug.org/">London Ruby User Group</a></li> +<li><a href="https://twitter.com/tomstuart">Tom on Twitter</a></li> +</ul> + + + + Ben is joined by Tom Stuart to talk about incorporating computer science topics into Ruby, his process of preparing talks, enriching your development career with a bit of computer science knowledge, and gushing about how amazing computers truly are.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by Tom Stuart to talk about incorporating computer science topics into Ruby, his process of preparing talks, enriching your development career with a bit of computer science knowledge, and gushing about how amazing computers truly are.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GsDLIUEH + + ]]> + + + + 156: It Has to be Valuable (Steve Tooke) + https://podcast.thoughtbot.com/156 + be89c93a-a081-4e75-bd46-20113176027e + Mon, 27 Jul 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben is joined by Steve Tooke to discuss the importance of communication, testing, and building Cucumber 2. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 33:13 + no + + <p>Ben is joined by Steve Tooke to discuss the importance of communication, testing, and building Cucumber 2.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://tooky.co.uk/your-tests-want-you-to-change-your-design/">Your Tests Want You to Change Your Design</a></li> +<li><a href="https://youtu.be/4cVZvoFGJTU">The Deep Synergy Between Testability and Good Design</a></li> +<li><a href="http://www.urbandictionary.com/define.php?term=subtweeting"><em>subtweeting</em></a></li> +<li><a href="http://www.htdp.org/">How to Design Programs</a></li> +<li><a href="https://leanpub.com/fp-oo"><em>Functional Programming for the Object-Oriented Programmer</em></a>- Brian Marick</li> +<li><a href="https://cucumber.io/">Cucumber</a></li> +<li><a href="https://skillsmatter.com/skillscasts/6240-taking-back-bdd">Taking Back BDD</a></li> +<li><a href="http://swancon.co.uk/">SwanseaCon</a></li> +<li><a href="https://twitter.com/tooky">Steve on Twitter</a></li> +</ul> + + + + Ben is joined by Steve Tooke to discuss the importance of communication, testing, and building Cucumber 2.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by Steve Tooke to discuss the importance of communication, testing, and building Cucumber 2.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+UkVg5M5G + + ]]> + + + + 155: CTO Duties (Joe Ferris) + https://podcast.thoughtbot.com/155 + b8a57881-1369-436c-92f5-39b02a37723a + Mon, 20 Jul 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben welcomes Joe Ferris, thoughtbot's CTO, to discuss design parity within the company, inversion of control, and solving all the world's problems with monads. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 40:57 + no + + <p>Ben welcomes Joe Ferris, thoughtbot's CTO, to discuss design parity within the company, inversion of control, and solving all the world's problems with monads.</p> +<p>This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://bourbon.io/">Bourbon</a></li> +<li><a href="http://stackoverflow.com/questions/3058/what-is-inversion-of-control">Inversion of Control</a></li> +<li><a href="https://upcase.com/join">Upcase</a></li> +<li><a href="https://gumroad.com/l/ruby-science"><em>Ruby Science</em></a></li> +<li><a href="https://gumroad.com/l/maybe-haskell/giantrobots?utm_source=giantrobots&amp;utm_medium=podcast"><em>Maybe Haskell</em></a> (50% off for our listeners!)</li> +<li><a href="https://en.wikipedia.org/wiki/Agda_(programming_language)">Agda</a></li> +<li><a href="https://en.wikipedia.org/wiki/Idris_(programming_language)">Idris</a></li> +<li><a href="https://www.docker.com/">Docker</a></li> +<li><a href="http://boot2docker.io/">boot2docker</a></li> +<li><a href="https://www.getdrip.com/forms/4174771/submissions/new">Upcase Newsletter</a></li> +<li><a href="https://twitter.com/joeferris">Joe on Twitter</a></li> +</ul> + + + + Ben welcomes Joe Ferris, thoughtbot's CTO, to discuss design parity within the company, inversion of control, and solving all the world's problems with monads.

+ +

This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben welcomes Joe Ferris, thoughtbot's CTO, to discuss design parity within the company, inversion of control, and solving all the world's problems with monads.

+ +

This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+QLyEMpUz + + ]]> + + + + 154: Do it Right the First Time (Samir Talwar) + https://podcast.thoughtbot.com/154 + eb8aab4a-945c-43cd-8d34-4c5d60da682f + Mon, 13 Jul 2015 00:00:00 -0400 + thoughtbot + + full + 4 + thoughtbot + Ben and Samir Talwar of Codurance discuss the appeal of functional programming, mob programming, and a different take on conferences. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 34:26 + no + + <p>Ben and Samir Talwar of Codurance discuss the appeal of functional programming, mob programming, and a different take on conferences.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://codurance.com/">Codurance</a></li> +<li><a href="http://www.usgo.org/what-go">What is Go?</a> (the game, not the language)</li> +<li><a href="http://monospacedmonologues.com/post/91841399505/mob-programming-and-the-importance-of-fun-at-work">Mob Programming, and the Importance of Fun at Work</a></li> +<li><a href="http://www.agilealliance.org/files/6214/0509/9357/ExperienceReport.2014.Zuill.pdf">Mob Programming- A Whole Team Approach</a>- Woody Zuill</li> +<li><a href="http://socratesuk.org/">SoCraTes UK</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="http://www.mindviewinc.com/Conferences/OpenSpaces">What Is An OpenSpace Conference?</a></li> +<li><a href="https://en.wikipedia.org/wiki/Mafia_(party_game)">Werewolf / Mafia (Party Game)</a></li> +<li><a href="http://www.meetup.com/london-software-craftsmanship/">London Software Craftsmanship Community</a></li> +<li><a href="https://twitter.com/SamirTalwar">Samir on Twitter</a></li> +</ul> + + + + Ben and Samir Talwar of Codurance discuss the appeal of functional programming, mob programming, and a different take on conferences.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Samir Talwar of Codurance discuss the appeal of functional programming, mob programming, and a different take on conferences.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+QnmjkqBl + + ]]> + + + + 153: Auld Lang Syne (Chad Pytel) + https://podcast.thoughtbot.com/153 + 52e04966-05e3-4c40-bb30-cf7e8b5923ac + Mon, 06 Jul 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + As Giant Robots nears its 3 year anniversary, Ben welcomes back Chad Pytel to reflect on the highs and lows of the previous year at thoughtbot. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 54:34 + no + + <p>As Giant Robots nears its 3 year anniversary, Ben welcomes back Chad Pytel to reflect on the highs and lows of the previous year at thoughtbot.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://press.kaptest.com/press-releases/kaplan-acquires-dev-bootcamp-founder-and-leader-of-the-software-developer-bootcamp-industry">Kaplan Acquires Dev Bootcamp</a></li> +<li><a href="https://robots.thoughtbot.com/learn-is-now-upcase">Learn is Now Upcase</a></li> +<li><a href="https://robots.thoughtbot.com/ship-you-a-haskell">Ship You a Haskell</a></li> +<li><a href="https://robots.thoughtbot.com/paid-private-repos-for-hound">Paid Private Repos for Hound</a></li> +<li><a href="https://robots.thoughtbot.com/our-books-are-now-available-individually">Books Now Available Individually</a></li> +<li><a href="https://robots.thoughtbot.com/upcoming-events-for-october-2014">Events (in) October, 2014</a></li> +<li><a href="https://robots.thoughtbot.com/introducing-formkeep">Introducing Formkeep</a></li> +<li><a href="http://giantrobots.fm/122">Ruby, the Weird Way</a>- Keep Ruby Weird organizers on Giant Robots #122</li> +<li><a href="https://robots.thoughtbot.com/bike-shed">Announcing The Bike Shed</a></li> +<li><a href="https://robots.thoughtbot.com/updated-test-driven-rails-videos">Updated Test-Driven Rails Videos</a></li> +<li><a href="https://robots.thoughtbot.com/upcase-is-now-more-affordable">Upcase is Now More Affordable</a></li> +<li><a href="http://2014.thoughtbot.com/">thoughtbot 2014 Report</a></li> +<li><a href="http://giantrobots.fm/130">Counting All the F-Words</a>- full podcast breakdown of our 2014 stats on GR #130</li> +<li><a href="https://upcase.com/tmux">Upcase tmux Trail</a></li> +<li><a href="https://gumroad.com/l/maybe-haskell"><em>Maybe Haskell</em></a>- Pat Brisbin</li> +<li><a href="https://robots.thoughtbot.com/portland-office">Portland Office</a></li> +<li><a href="https://robots.thoughtbot.com/thoughtbot-in-chicago">thoughtbot in Chicago</a></li> +<li><a href="http://coaching.thoughtbot.com/">thoughtbot Coaching</a></li> +<li><a href="http://troposweather.com/">Tropos</a></li> +<li><a href="https://gumroad.com/l/write-yourself-a-roguelike"><em>Write Yourself a Roguelike</em></a>- Goose</li> +<li><a href="https://gumroad.com/l/testing-rails"><em>Testing Rails</em></a>- Josh Steiner</li> +<li><a href="https://gumroad.com/l/maintaining-open-source-projects"><em>Maintaining Open Source Projects</em></a>- Tute Costa</li> +<li><a href="http://playroto.to/">Rototo: Space Survival</a></li> +<li><a href="https://gumroad.com/l/design-for-the-web"><em>Design for the Web</em></a>- Joshua Ogle</li> +<li><a href="https://robots.thoughtbot.com/announcing-carnival-for-your-site">Carnival for your Site</a></li> +<li><a href="https://robots.thoughtbot.com/introducing-our-chief-design-officer-and-design-directors">Introducing Design Directors</a></li> +<li><a href="https://robots.thoughtbot.com/thoughtbot-in-london">thoughtbot in London</a></li> +<li><a href="https://twitter.com/cpytel">Chad on Twitter</a></li> +</ul> + + + + As Giant Robots nears its 3 year anniversary, Ben welcomes back Chad Pytel to reflect on the highs and lows of the previous year at thoughtbot.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + As Giant Robots nears its 3 year anniversary, Ben welcomes back Chad Pytel to reflect on the highs and lows of the previous year at thoughtbot.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dQiUZ3GC + + ]]> + + + + 152: Providing Positive Change (Denise Yu & Rosa Fox) + https://podcast.thoughtbot.com/152 + b792aeb1-f3f8-48e1-b440-6ae10641b2b7 + Mon, 29 Jun 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben welcomes Denise Yu and Rosa Fox of Codebar to discuss the importance of fostering community, mentoring tips, and more. + 29:45 + no + + <p>Ben welcomes Denise Yu and Rosa Fox of Codebar to discuss the importance of fostering community, mentoring tips, and more.</p> +<ul> +<li><a href="http://codebar.io/">Codebar</a></li> +<li><a href="https://twitter.com/deniseyu21">Denise on Twitter</a></li> +<li><a href="https://twitter.com/Rosaemerald">Rosa on Twitter</a></li> +</ul> + + + + Ben welcomes Denise Yu and Rosa Fox of Codebar to discuss the importance of fostering community, mentoring tips, and more.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben welcomes Denise Yu and Rosa Fox of Codebar to discuss the importance of fostering community, mentoring tips, and more.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+KuTKT6A5 + + ]]> + + + + 151: Open By Default (Aidan Feldman) + https://podcast.thoughtbot.com/151 + c0f03a48-c6d0-42e5-868d-ab3802d76cbe + Mon, 15 Jun 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben discusses consulting and open source from within the government, as well as choosing the right clients, and the value of mentorship, with Aidan Feldman of 18F. + 28:57 + no + + <p>Ben discusses consulting and open source from within the government, as well as choosing the right clients, and the value of mentorship, with Aidan Feldman of 18F.</p> +<ul> +<li><a href="https://18f.gsa.gov/">18F</a></li> +<li><a href="http://www.meetup.com/hackerhours/">Hacker Hours</a></li> +<li><a href="https://github.com/osscommunity">Open Source Community</a></li> +<li><a href="https://twitter.com/aidanfeldman">Aidan on Twitter</a></li> +</ul> + + + + Ben discusses consulting and open source from within the government, as well as choosing the right clients, and the value of mentorship, with Aidan Feldman of 18F.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben discusses consulting and open source from within the government, as well as choosing the right clients, and the value of mentorship, with Aidan Feldman of 18F.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dfbg7ECu + + ]]> + + + + 150: Don't Screw it Up (Derek Prior) + https://podcast.thoughtbot.com/150 + db081e37-bfff-453a-b0aa-69913c75f974 + Mon, 08 Jun 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with fellow thoughtbotter Derek Prior on conference speaking, code review, and podcasting. + 33:28 + no + + <p>Ben talks with fellow thoughtbotter Derek Prior on conference speaking, code review, and podcasting.</p> +<ul> +<li><a href="https://youtu.be/PJjmw9TRB7s">Implementing a Strong Code-Review Culture</a>- Derek's RailsConf 2015 Talk</li> +<li><a href="https://www.youtube.com/watch?v=l9JXH7JPjR4">How to Talk to Developers</a></li> +<li><a href="http://genius.com/Ben-orenstein-open-your-world-for-commentary-annotated">Giant Robots on Genius</a></li> +<li><a href="http://bikeshed.fm/">The Bike Shed Podcast</a></li> +<li><a href="https://twitter.com/derekprior">Derek on Twitter</a></li> +</ul> + + + + Ben talks with fellow thoughtbotter Derek Prior on conference speaking, code review, and podcasting.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with fellow thoughtbotter Derek Prior on conference speaking, code review, and podcasting.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+VJTm3y7g + + ]]> + + + + 149: Try to Stand Out (Chris Toomey) + https://podcast.thoughtbot.com/149 + f43e3e36-64b3-4f64-bbf2-32c3ac6fcc44 + Mon, 01 Jun 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with fellow thoughtbotter Chris Toomey on networking, mentorship, React.js, and sustainable pace. + 32:47 + no + + <p>Ben talks with fellow thoughtbotter Chris Toomey on networking, mentorship, React.js, and sustainable pace.</p> +<ul> +<li><a href="http://www.meetup.com/The-Boston-Vim-Meetup/">Boston Vim Meetup</a></li> +<li><a href="http://upcase.com">Upcase</a></li> +<li><a href="https://facebook.github.io/react/">React</a></li> +<li><a href="https://www.youtube.com/watch?v=x7cQ3mrcKaY">Pete Hunt- React: Rethinking Best Practices</a></li> +<li><a href="http://www.mrmoneymustache.com/2012/01/13/the-shockingly-simple-math-behind-early-retirement/"><em>The Shockingly Simple Math Behind Early Retirement</em></a>- Mr. Money Mustache</li> +<li><a href="https://twitter.com/christoomey">Chris on Twitter</a></li> +</ul> + + + + Ben talks with fellow thoughtbotter Chris Toomey on networking, mentorship, React.js, and sustainable pace.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with fellow thoughtbotter Chris Toomey on networking, mentorship, React.js, and sustainable pace.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+wq9wmtK4 + + ]]> + + + + 148: We All Want to be Heard (Rebecca Miller-Webster) + https://podcast.thoughtbot.com/148 + 74a859f1-5cf0-44dd-a817-e239681a9c76 + Mon, 25 May 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Rebecca Miller-Webster, Managing Director of thoughtbot Chicago, on beginners contributing to open-source, organizing conferences, and cultivating a more inclusive culture. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 32:10 + no + + <p>Ben talks with Rebecca Miller-Webster, Managing Director of thoughtbot Chicago, on beginners contributing to open-source, organizing conferences, and cultivating a more inclusive culture.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://www.writespeakcode.com/">Write/Speak/Code</a></li> +<li><a href="http://www.rebeccamiller-webster.com">Rebecca's Personal Site</a></li> +<li><a href="https://youtu.be/nxo40nzdICw">Increasing the Visibility &amp; Leadership of Women in Tech</a>- TEDx Talk</li> +<li><a href="http://www.thebeccacomplex.com/">The Becca Complex</a></li> +<li><a href="https://twitter.com/rmillerwebster">Rebecca on Twitter</a></li> +</ul> + + + + Ben talks with Rebecca Miller-Webster, Managing Director of thoughtbot Chicago, on beginners contributing to open-source, organizing conferences, and cultivating a more inclusive culture.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Rebecca Miller-Webster, Managing Director of thoughtbot Chicago, on beginners contributing to open-source, organizing conferences, and cultivating a more inclusive culture.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+O1VND8vD + + ]]> + + + + 147: Cry Through it, and Keep Typing (Saron Yitbarek) + https://podcast.thoughtbot.com/147 + 8a158b12-641d-45d1-b2cf-65125186e0eb + Mon, 18 May 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben welcomes on Saron Yitbarek to talk about creating communities that foster learning and niceness; as well as getting comfortable with being uncomfortable, and how confronting that discomfort can ultimately lead to success. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 33:09 + no + + <p>Ben welcomes on Saron Yitbarek to talk about creating communities that foster learning and niceness; as well as getting comfortable with being uncomfortable, and how confronting that discomfort can ultimately lead to success.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://flatironschool.com/">Flatiron School</a></li> +<li><a href="http://www.meetup.com/ny-tech/">NY Tech Meetup</a></li> +<li><a href="http://www.codenewbie.org/">CodeNewbie</a></li> +<li><a href="http://www.readingcodegood.com/">Code Club</a></li> +<li><a href="https://storify.com/codenewbies">Twitter Chats</a></li> +<li><a href="http://www.codenewbie.org/podcast">CodeNewbie Podcast</a></li> +<li><a href="https://codenewbie.typeform.com/to/uwsWlZ">CN Slack Chat</a></li> +<li><a href="http://bloggytoons.com/dear-flatiron">Saron- the Flatiron Hopeful Cartoon</a></li> +<li><a href="http://bloggytoons.com/posts/2014/2/22/demons-and-cfps"><em>Demons and CFPs</em></a></li> +<li><a href="https://twitter.com/saronyitbarek">Saron on Twitter</a></li> +</ul> + + + + Ben welcomes on Saron Yitbarek to talk about creating communities that foster learning and niceness; as well as getting comfortable with being uncomfortable, and how confronting that discomfort can ultimately lead to success.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben welcomes on Saron Yitbarek to talk about creating communities that foster learning and niceness; as well as getting comfortable with being uncomfortable, and how confronting that discomfort can ultimately lead to success.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+5kOmIPbC + + ]]> + + + + 146: Ready For the Real World (Shelby Kelly) + https://podcast.thoughtbot.com/146 + c07ceee4-947f-45b9-b529-e10135395453 + Mon, 11 May 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben and Shelby Kelly discuss teaching at a coding bootcamp and the future of junior-developer programs. Stick around till the end to catch a sample of her Rocky Mountain Ruby rap! + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 28:53 + no + + <p>Ben and Shelby Kelly discuss teaching at a coding bootcamp and the future of junior-developer programs. Stick around till the end to catch a sample of her Rocky Mountain Ruby rap!</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="http://www.galvanize.com/courses/full-stack/">Galvanize Full Stack</a></li> +<li><a href="https://youtu.be/DqoKIKWf2HM?t=31m1s">Rocky Mountain Ruby Rap</a></li> +<li><a href="https://twitter.com/ShelllKell">Shelby on Twitter</a></li> +</ul> + + + + Ben and Shelby Kelly discuss teaching at a coding bootcamp and the future of junior-developer programs. Stick around till the end to catch a sample of her Rocky Mountain Ruby rap!

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Shelby Kelly discuss teaching at a coding bootcamp and the future of junior-developer programs. Stick around till the end to catch a sample of her Rocky Mountain Ruby rap!

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MECajKQN + + ]]> + + + + 145: YOLO! _push to master_ (Sam Phippen) + https://podcast.thoughtbot.com/145 + 2042c8d6-d64c-44a5-a63a-5765f561ce9d + Mon, 04 May 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to Sam Phippen on working on the RSpec core team, new features in 3.3, tips for contributing to open-source, and his favorite parts of Rails. + +This episode of Giant Robots is sponsored by Digital Ocean. Simple and fast cloud hosting, built for developers. Use the code `GiantRobots` for a $10 credit towards your new account. + 43:40 + no + + <p>Ben talks to Sam Phippen on working on the RSpec core team, new features in 3.3, tips for contributing to open-source, and his favorite parts of Rails.</p> +<p>This episode of Giant Robots is sponsored by:</p> +<ul> +<li><a href="https://www.digitalocean.com/">Digital Ocean</a>: Simple and fast cloud hosting, built for developers. Use the code <code>GiantRobots</code> for a $10 credit towards your new account.</li> +</ul> +<p>Links &amp; Show Notes</p> +<ul> +<li><a href="https://github.com/dblock/rspec-rerun">rspec-rerun</a></li> +<li><a href="http://sidekiq.org/">Sidekiq</a></li> +<li><a href="https://aphyr.com/posts">Kyle Kingsbury's Blog</a></li> +<li><a href="https://twitter.com/samphippen">Sam on Twitter</a></li> +</ul> + + + + Ben talks to Sam Phippen on working on the RSpec core team, new features in 3.3, tips for contributing to open-source, and his favorite parts of Rails.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Sam Phippen on working on the RSpec core team, new features in 3.3, tips for contributing to open-source, and his favorite parts of Rails.

+ +

This episode of Giant Robots is sponsored by:

+ +
    +
  • Digital Ocean: Simple and fast cloud hosting, built for developers. Use the code GiantRobots for a $10 credit towards your new account.
    • +
+ +

Links & Show Notes

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+U_QSW3rO + + ]]> + + + + 144: Finding a New Way (Pam Selle) + https://podcast.thoughtbot.com/144 + b2578e97-0d66-4200-980a-8fb8c2786b09 + Mon, 27 Apr 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to Pam Selle on the importance of self-imposed structure, voice coding, and living with RSI. + + 34:19 + no + + <p>Ben talks to Pam Selle on the importance of self-impossed structure, voice coding, and living with RSI.</p> +<ul> +<li><a href="https://www.recurse.com/">Recurse Center</a></li> +<li><a href="https://mitpress.mit.edu/sicp/full-text/book/book.html"><em>Structure and Interpretation of Computer Programs</em></a></li> +<li><a href="http://thewebivore.com/introducing-macvimspeak-talking-computer-use-vim/">MacVimSpeak</a></li> +<li><a href="http://handsfreecoding.org/">Hands-Free Coding</a></li> +<li><a href="http://www.keyboard.io/">Keyboardio</a></li> +<li><a href="https://www.goodreads.com/book/show/156155.It_s_Not_Carpal_Tunnel_Syndrome_"><em>It's Not Carpal Tunnel Syndrome!</em></a></li> +<li><a href="http://shop.oreilly.com/product/9781939902085.do"><em>Choosing a JavaScript Framework</em></a></li> +<li><a href="https://twitter.com/pamasaur">Pam on Twitter</a></li> +<li><a href="http://turing.cool">Turing-Incomplete Podcast</a></li> +</ul> +<p><a href="http://bitly.com/giantrobots">Haymakers For Hope</a>: Ben's Charity Boxing Match</p> + + + + Ben talks to Pam Selle on the importance of self-impossed structure, voice coding, and living with RSI.

+ + + +

Haymakers For Hope: Ben's Charity Boxing Match

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Pam Selle on the importance of self-impossed structure, voice coding, and living with RSI.

+ + + +

Haymakers For Hope: Ben's Charity Boxing Match

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GNbl6JnZ + + ]]> + + + + 143: Keep an Open Mind (Carin Meier) + https://podcast.thoughtbot.com/143 + 9beb8585-06a9-4a52-834e-6d2d373bc068 + Mon, 20 Apr 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Carin Meier on the writer's process, how programming relates to the arts, and the importance of a graduated and immersive approach to learning. + 29:02 + no + + <p>Ben talks with Carin Meier on the writer's process, how programming relates to the arts, and the importance of a graduated and immersive approach to learning.</p> +<ul> +<li><a href="http://shop.oreilly.com/product/0636920034292.do"><em>Living Clojure</em></a></li> +<li><a href="http://www.wolfram.com/mathematica/">Mathematica</a></li> +<li><a href="http://easeinto5k.bluefinapps.com/">Ease into 5k</a></li> +<li><a href="http://www.4clojure.com/">4Clojure</a></li> +<li><a href="https://github.com/gigasquid/wonderland-clojure-katas">Wonderland Katas</a></li> +<li><a href="http://gigasquidsoftware.com/blog/2014/02/01/hitchhikers-guide-to-clojure/">Hitchhiker's Guide to Clojure</a></li> +<li><a href="http://ardrone2.parrot.com/">Parrot AR Drones</a></li> +<li><a href="http://clojurewest.org/speakers#csmall">How Clojure Saved My Chickens</a></li> +<li><a href="https://twitter.com/gigasquid">Carin on Twitter</a></li> +</ul> + + + + Ben talks with Carin Meier on the writer's process, how programming relates to the arts, and the importance of a graduated and immersive approach to learning.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Carin Meier on the writer's process, how programming relates to the arts, and the importance of a graduated and immersive approach to learning.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+3qX5mw77 + + ]]> + + + + 142: The Power of Play (Justin Gitlin) + https://podcast.thoughtbot.com/142 + 26f73a76-182a-45e3-a5fd-1e8bf3dfacd9 + Mon, 13 Apr 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Justin Gitlin on changing the experience of a social media platform, as well as shaping game dev to art (and vice versa). + 28:23 + no + + <p>Ben talks with Justin Gitlin on changing the experience of a social media platform, as well as shaping game dev to art (and vice versa).</p> +<ul> +<li><a href="http://modeset.com/">Mode Set</a></li> +<li><a href="https://ello.co/wtf/post/about">Ello</a></li> +<li><a href="http://en.wikipedia.org/wiki/Facebook_real-name_policy_controversy">Facebook real-name policy controversy</a></li> +<li><a href="http://ohheckyeah.com/">OhHeckYeah</a></li> +<li><a href="http://www.bay12games.com/dwarves/">Dwarf fortress</a></li> +<li><a href="http://playroto.to/">Rototo</a></li> +<li><a href="http://www.npr.org/2013/10/21/236207605/scott-adams-explains-how-to-fail-at-almost-everything-except-dilbert">An Interview With Scott Adams</a></li> +<li><a href="http://cmky.org/festival/">Communikey Festival</a></li> +<li><a href="https://twitter.com/cacheflowe">Justin on Twitter</a></li> +</ul> + + + + Ben talks with Justin Gitlin on changing the experience of a social media platform, as well as shaping game dev to art (and vice versa).

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Justin Gitlin on changing the experience of a social media platform, as well as shaping game dev to art (and vice versa).

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Pw-MLY-b + + ]]> + + + + 141: Don't Say No to Anything (Georgia Dow) + https://podcast.thoughtbot.com/141 + 55df29b9-e195-4cb8-8873-08c5aa16ed05 + Mon, 06 Apr 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben sits down with therapist/writer/podcaster/speaker/Brazilian Jiu-Jitsu champion Georgia Dow to discuss the value of new experiences, the advantages of private mentorship, and living life to it's fullest. + 29:35 + no + + <p>Ben sits down with therapist/writer/podcaster/speaker/Brazilian Jiu-Jitsu champion Georgia Dow to discuss the value of new experiences, the advantages of private mentorship, and living life to its fullest.</p> +<ul> +<li><a href="http://www.imore.com/">iMore</a></li> +<li><a href="http://www.imore.com/vector">Vector Podcast</a></li> +<li><a href="http://isometricshow.com/">Isometric Podcast</a></li> +<li><a href="http://en.wikipedia.org/wiki/Royal_Mews">Royal Mews</a></li> +<li><a href="https://twitter.com/thoughtbotThom/status/582912809618526208">Georgia, true to her word</a></li> +<li><a href="https://twitter.com/Georgia_Dow">Georgia on Twitter</a></li> +</ul> + + + + Ben sits down with therapist/writer/podcaster/speaker/Brazilian Jiu-Jitsu champion Georgia Dow to discuss the value of new experiences, the advantages of private mentorship, and living life to its fullest.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben sits down with therapist/writer/podcaster/speaker/Brazilian Jiu-Jitsu champion Georgia Dow to discuss the value of new experiences, the advantages of private mentorship, and living life to its fullest.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+XCv6iCbl + + ]]> + + + + 140: Don't Believe Everything That You Think (Sir John Hargrave) + https://podcast.thoughtbot.com/140 + b3d5ea53-666c-4266-9d53-abcca16da39f + Mon, 30 Mar 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to Sir John Hargrave, CEO of Media Shower, about his new book _Mind Hacking_ on the power of reprogramming one's thoughts to maintain new habits, and innovations to the traditional publishing model. + 31:01 + no + + <p>Ben talks to Sir John Hargrave, CEO of Media Shower, about his new book <em>Mind Hacking</em> on the power of reprogramming one's thoughts to maintain new habits, and innovations to the traditional publishing model.</p> +<ul> +<li><a href="https://mediashower.com/">Media Shower</a></li> +<li><a href="http://www.mindhacki.ng/"><em>Mind Hacking</em></a></li> +<li><a href="http://www2.nami.org/Content/NavigationMenu/Inform_Yourself/About_Mental_Illness/About_Treatments_and_Supports/Cognitive_Behavioral_Therapy1.htm">CBT Therapy Philsophy</a></li> +<li><a href="http://www.wsj.com/articles/SB10001424053111903480904576512250915629460"><em>Software is Eating the World</em></a>- Marc Andreessen</li> +<li><a href="https://www.gitbook.com/">GitBook</a></li> +<li><a href="https://twitter.com/sirjohnhargrave">Sir John on Twitter</a></li> +</ul> + + + + Ben talks to Sir John Hargrave, CEO of Media Shower, about his new book Mind Hacking on the power of reprogramming one's thoughts to maintain new habits, and innovations to the traditional publishing model.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Sir John Hargrave, CEO of Media Shower, about his new book Mind Hacking on the power of reprogramming one's thoughts to maintain new habits, and innovations to the traditional publishing model.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+0IGbjAy_ + + ]]> + + + + 139: Learning Oriented Culture (Mike Brittain) + https://podcast.thoughtbot.com/139 + 9cc84728-5fe9-4c88-93a5-e635b4be25ec + Mon, 23 Mar 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to Mike Brittain, VP of Engineering at Etsy, on interacting with the development community, strides in diversity practices, the pros/cons of an open office, and the difficulties in transitioning from engineering to management. + 38:27 + no + + <p>Ben talks to Mike Brittain, VP of Engineering at Etsy, on interacting with the development community, strides in diversity practices, the pros/cons of an open office, and the difficulties in transitioning from engineering to management.</p> +<ul> +<li><a href="https://codeascraft.com/2015/02/17/the-art-of-the-dojo/">The Art of the Dojo</a></li> +<li><a href="http://www.officelovin.com/2014/04/25/the-wonderfully-designed-offices-of-spotify/">Spotify's NYC Office</a></li> +<li><a href="https://youtu.be/YAjChZ3gyps">Facebook's Vending Machines</a></li> +<li><a href="http://managinghumans.com/"><em>Managing Humans</em></a>- Michael Lopp</li> +<li><a href="https://twitter.com/mikebrittain">Mike on Twitter</a></li> +</ul> + + + + Ben talks to Mike Brittain, VP of Engineering at Etsy, on interacting with the development community, strides in diversity practices, the pros/cons of an open office, and the difficulties in transitioning from engineering to management.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Mike Brittain, VP of Engineering at Etsy, on interacting with the development community, strides in diversity practices, the pros/cons of an open office, and the difficulties in transitioning from engineering to management.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+O2m9AmHZ + + ]]> + + + + 138: Overloading the Home Row (Craig Andera) + https://podcast.thoughtbot.com/138 + 5b6d7f1c-62a5-4de8-9d45-05c746fd49c7 + Mon, 16 Mar 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to Craig Andera, developer at Cognitect, on his latest 20% time project, Clojure as open source, and reimagining database structures. + 44:35 + no + + <p>Ben talks to Craig Andera, developer at Cognitect, on his latest 20% time project, how Clojure gets made, and driving immutability into a database.</p> +<ul> +<li><a href="http://blog.cognitect.com/cognicast/">Cognicast</a></li> +<li><a href="https://www.kinesis-ergo.com/products/#keyboards-section">Kinesis Keyboards</a></li> +<li><a href="https://github.com/candera/khordr">khordr</a></li> +<li><a href="http://cognitect.com/datomic">Datomic</a></li> +<li><a href="http://youtu.be/rI8tNMsozo0?t=46s">&quot;Simplicity Matters&quot;</a>- Rich Hickey</li> +<li><a href="http://themuirproject.com/mmah/videos/"><em>Mile...Mile &amp; a Half</em></a> (Documentary)</li> +<li><a href="http://youtu.be/ShEez0JkOFw?t=5s">&quot;Programming with Hand Tools&quot;</a>- Tim Ewald</li> +<li><a href="http://en.wikipedia.org/wiki/Falcon_4.0">Falcon 4.0</a></li> +<li><a href="https://twitter.com/craigandera">Craig on Twitter</a></li> +</ul> + + + + Ben talks to Craig Andera, developer at Cognitect, on his latest 20% time project, how Clojure gets made, and driving immutability into a database.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Craig Andera, developer at Cognitect, on his latest 20% time project, how Clojure gets made, and driving immutability into a database.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+HIGg3pQx + + ]]> + + + + 137: The Haskell Renaissance (Pat Brisbin) + https://podcast.thoughtbot.com/137 + 9240abdc-0286-42d5-83cf-85e469f8c5a4 + Mon, 09 Mar 2015 00:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Pat Brisbin on his new book, and the future of Haskell at thoughtbot. + 30:34 + no + + <p>Ben talks with Pat Brisbin on his new book, and the future of Haskell at thoughtbot.</p> +<ul> +<li><a href="https://robots.thoughtbot.com/maybe-haskell-our-newest-book"><em>Maybe Haskell</em> announcement</a></li> +<li><a href="https://thoughtbot.com/books">thoughtbot's books</a></li> +<li><a href="http://learnyouahaskell.com/"><em>Learn You a Haskell for Great Good</em></a></li> +<li><a href="https://upcase.com/haskell">Upcase Haskell excercises</a></li> +<li><a href="https://github.com/thoughtbot/carnival">Carnival</a></li> +<li><a href="https://github.com/mietek/haskell-on-heroku">haskell on heroku</a></li> +<li><a href="http://www.yesodweb.com/">Yesod</a></li> +<li><a href="http://maybe-haskell.com/giantrobots?utm_source=giantrobots&amp;utm_medium=podcast"><em>Maybe Haskell</em></a> (50% off for our listeners!)</li> +<li><a href="https://twitter.com/patbrisbin">Pat on Twitter</a></li> +</ul> + + + + Ben talks with Pat Brisbin on his new book, and the future of Haskell at thoughtbot.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Pat Brisbin on his new book, and the future of Haskell at thoughtbot.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Cnay3ekm + + ]]> + + + + 136: I Think it Was the Altitude (Ben Orenstein) + https://podcast.thoughtbot.com/136 + 18b70ba5-0092-4ac3-96d1-74ed2d191576 + Mon, 02 Mar 2015 00:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad officially welcomes Ben back to the podcast, discuses the employer/employee ideology that can facilitate a successful sabbatical, and reveals some exclusives on the future of thoughtbot. + 31:16 + no + + <p>Chad officially welcomes Ben back to the podcast, discuses the employer/employee ideology that can facilitate a successful sabbatical, and reveals some exclusives on the future of thoughtbot.</p> +<ul> +<li><a href="http://turing.io/">Turing School</a></li> +<li><a href="http://www.healthyhacker.com/2014/11/03/walkabout/">Ben on the Healthy Hacker podcast</a></li> +<li><a href="http://www.focaluprightfurniture.com/focal-standing-seat/">Pogo-stick Chair</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="https://upcase.com/">Upcase</a></li> +<li><a href="http://youtu.be/Q_kgpPXNv3E">Rugby explained for Chad</a></li> +<li><a href="https://robots.thoughtbot.com/portland-office">New thoughtbot Office</a></li> +<li><a href="http://2015.bathruby.org/">Bath Ruby</a></li> +</ul> + + + + Chad officially welcomes Ben back to the podcast, discuses the employer/employee ideology that can facilitate a successful sabbatical, and reveals some exclusives on the future of thoughtbot.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad officially welcomes Ben back to the podcast, discuses the employer/employee ideology that can facilitate a successful sabbatical, and reveals some exclusives on the future of thoughtbot.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+QOCF6wsg + + ]]> + + + + 135: Planning For Change (Ben Arent) + https://podcast.thoughtbot.com/135 + e47b9673-8a13-4e46-b8dd-1dd0f729aaa5 + Mon, 23 Feb 2015 00:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks with Ben Arent, product manager at Rackspace, on the trials of app acquisition, as well as their favorite Sass tools. + 33:46 + no + + <p>Chad talks with Ben Arent, product manager at Rackspace, on the pros/cons of app acquisition, as well as their favorite Sass tools.</p> +<ul> +<li><a href="http://www.rackspace.com/">Rackspace</a></li> +<li><a href="https://airbrake.io/">Airbrake</a></li> +<li><a href="http://golang.org/">Go Programing Language</a></li> +<li><a href="http://www.rackspace.com/cloud/hybrid">Hybrid Cloud</a></li> +<li><a href="http://www.rackspace.com/cloud/servers/onmetal">OnMetal Cloud Servers</a></li> +<li><a href="http://www.opencompute.org/">Open Computer Project</a></li> +<li><a href="https://segment.com/">Segment</a></li> +<li><a href="https://www.intercom.io/">Intercom</a></li> +<li><a href="https://tenderapp.com/">Tender Support</a></li> +<li><a href="https://github.com/tripit/slate">Slate</a></li> +<li><a href="https://www.temper.io/">Temper</a></li> +<li><a href="http://www.hubspot.com/">Hubspot</a></li> +<li><a href="https://twitter.com/benarent">Ben on Twitter</a></li> +</ul> + + + + Chad talks with Ben Arent, product manager at Rackspace, on the pros/cons of app acquisition, as well as their favorite Sass tools.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with Ben Arent, product manager at Rackspace, on the pros/cons of app acquisition, as well as their favorite Sass tools.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+PsAHJVGw + + ]]> + + + + 134: Growing to Meteor (Paul Dowman) + https://podcast.thoughtbot.com/134 + d56b8b1b-e5eb-4b8e-a979-7489dbaeb52a + Mon, 16 Feb 2015 00:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks with Paul Dowman, founder of OK GROW!, on replacing Rails with Meteor, and how martial arts has made him a better developer. + 41:43 + no + + <p>Chad talks with Paul Dowman, founder of OK GROW!, on replacing Rails with Meteor, and how martial arts has made him a better developer.</p> +<ul> +<li><a href="http://www.okgrow.com/">OK GROW!</a></li> +<li><a href="https://www.meteor.com/">Meteor</a></li> +<li><a href="http://velocity.meteor.com/">Velocity Test Framework</a></li> +<li><a href="http://robots.thoughtbot.com/wasting-less-time">Wasting Less Time</a></li> +<li><a href="http://robots.thoughtbot.com/replace-coffeescript-with-es6">Replace CoffeeScript with ES6</a></li> +<li><a href="http://en.wikipedia.org/wiki/Jeet_Kune_Do">Jeet Kune Do</a></li> +<li><a href="https://twitter.com/pauldowman">Paul on Twitter</a></li> +</ul> + + + + Chad talks with Paul Dowman, founder of OK GROW!, on replacing Rails with Meteor, and how martial arts has made him a better developer.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with Paul Dowman, founder of OK GROW!, on replacing Rails with Meteor, and how martial arts has made him a better developer.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rL9ehkMq + + ]]> + + + + 133: The DNA of Music (Matt Aimonetti) + https://podcast.thoughtbot.com/133 + e9e7ea3d-8ca3-4ed6-a55a-42c4208c3a3e + Mon, 09 Feb 2015 00:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks with Matt Aimonetti, co-founder of Splice, on remote worker strategies, fundraising, and his vision for the future of digital musical collaboration. + 34:40 + no + + <p>Chad talks with Matt Aimonetti, co-founder of Splice, on remote worker strategies, fundraising, and his vision for the future of digital musical collaboration.</p> +<ul> +<li><a href="https://splice.com/">Splice</a></li> +<li><a href="https://www.google.com/chrome/business/solutions/for-meetings.html">Chromebox For Meetings</a></li> +<li><a href="http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/">#NoEstimates</a></li> +<li><a href="http://exercism.io/">excercism.io</a></li> +<li><a href="https://twitter.com/mattetti">Matt on Twitter</a></li> +</ul> + + + + Chad talks with Matt Aimonetti, co-founder of Splice, on remote worker strategies, fundraising, and his vision for the future of digital musical collaboration.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with Matt Aimonetti, co-founder of Splice, on remote worker strategies, fundraising, and his vision for the future of digital musical collaboration.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YY9H0mQX + + ]]> + + + + 132: Story Tellers (Adarsh Pandit, Kyle Fiedler) + https://podcast.thoughtbot.com/132 + 9bf96ab8-0a7c-44ef-954a-573740bfc05d + Sun, 01 Feb 2015 19:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks with fellow thoughtbotters Adarsh Pandit and Kyle Fiedler on the pros and cons of stories, story points, and job stories. + 38:28 + no + + <p>Chad talks with fellow thoughtbotters Adarsh Pandit and Kyle Fiedler on the pros and cons of stories, story points, and job stories.</p> +<ul> +<li><a href="https://twitter.com/adarshp/status/558360781180256256">Adarsh’s tweets on points</a></li> +<li><a href="http://robots.thoughtbot.com/converting-to-jobs-stories"><em>Converting to Jobs Stories</em></a></li> +<li><a href="http://www.pivotaltracker.com/">Pivotal Tracker</a></li> +<li><a href="https://basecamp.com">Basecamp</a></li> +<li><a href="https://lighthouseapp.com">Lighthouse</a></li> +<li><a href="http://www.agilemanifesto.org">Agile Manifesto</a></li> +<li><a href="http://alanklement.blogspot.com/2013/09/replacing-user-story-with-job-story.html"><em>Replacing The User Story With The Job Story</em></a>- Alan Klement</li> +<li><a href="http://trello.com">Trello</a></li> +<li><a href="http://playbook.thoughtbot.com/#research">thoughtbot’s research board</a></li> +</ul> + + + + Chad talks with fellow thoughtbotters Adarsh Pandit and Kyle Fiedler on the pros and cons of stories, story points, and job stories.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with fellow thoughtbotters Adarsh Pandit and Kyle Fiedler on the pros and cons of stories, story points, and job stories.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Rxwemnob + + ]]> + + + + 131: The Human-Computer Interaction Umbrella (Irene Ros) + https://podcast.thoughtbot.com/131 + ecaf46f9-bb30-4804-91f0-18755e344ca5 + Mon, 26 Jan 2015 00:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks with Irene Ros, data visualization practice lead at Bocoup, about her pursuit of making data visualization function in a social context. + 32:24 + no + + <p>Chad talks with Irene Ros, data visualization practice lead at Bocoup, about her pursuit of making data visualization function in a social context.</p> +<ul> +<li><a href="http://www.nsftools.com/misc/WhatIsNotes.htm">What is Lotus Notes?</a></li> +<li><a href="http://www-969.ibm.com/software/analytics/manyeyes/">Many Eyes</a></li> +<li><a href="http://researcher.watson.ibm.com/researcher/view_group.php?id=1232">Mant Bills</a></li> +<li><a href="http://bocoup.com/">Bocoup</a></li> +<li><a href="http://bocoup.com/community/bob/">Roosters Stickers Around the World</a></li> +<li><a href="http://popcornjs.org/">Popcorn.js</a></li> +<li><a href="https://angel.co/">AngelList</a></li> +<li><a href="http://openvisconf.com/">OpenVis Conf</a></li> +<li><a href="http://scienceclubforgirls.org/">Science Club for Girls</a></li> +<li><a href="http://www.meetup.com/boston_JS/">BostonJS Meetup</a></li> +<li><a href="http://www.meetup.com/bostondatavis/">Boston Data Visualization Meetup</a></li> +<li><a href="http://misoproject.com/">Miso</a></li> +<li><a href="http://misoproject.com/d3-chart/">d3.Chart</a></li> +<li><a href="https://twitter.com/ireneros">Irene on Twitter</a></li> +</ul> + + + + Chad talks with Irene Ros, data visualization practice lead at Bocoup, about her pursuit of making data visualization function in a social context.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with Irene Ros, data visualization practice lead at Bocoup, about her pursuit of making data visualization function in a social context.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8ASN8f8C + + ]]> + + + + 130: Counting all the F-Words (Joanne Cheng) + https://podcast.thoughtbot.com/130 + 71416e40-9327-45ba-a308-28ad2cc50e1e + Mon, 19 Jan 2015 16:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad & developer Joanne Cheng break down thoughtbot's statistical year in review! + 27:48 + no + + <p>Chad &amp; developer Joanne Cheng break down thoughtbot's statistical year in review!</p> +<ul> +<li><a href="http://giantrobots.fm/112">Data by Design</a> <em>(Giant Robots ep 112)</em></li> +<li><a href="http://2014.thoughtbot.com/">thoughtbot 2014 Report</a></li> +<li><a href="http://feltron.com/">Feltron Reports</a></li> +<li><a href="https://vimeo.com/101957416">&quot;The Weight of Rain&quot;</a>- Jonathan Corum</li> +<li><a href="https://csvkit.readthedocs.org/en/0.9.0/">csvkit</a></li> +<li><a href="http://buildphase.fm/">Build Phase</a></li> +<li><a href="https://twitter.com/joannecheng">Joanne on Twitter</a></li> +</ul> + + + + Chad & developer Joanne Cheng break down thoughtbot's statistical year in review!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad & developer Joanne Cheng break down thoughtbot's statistical year in review!

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+gJ4Hj-YQ + + ]]> + + + + 129: The Engineering of Payments (Ian Logan) + https://podcast.thoughtbot.com/129 + 5c862624-5746-4317-b2d4-49aec43d7e6f + Tue, 13 Jan 2015 00:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks with Ian Logan, an Engineering Manager at Airbnb, on the challenges, ideology, implementation, and future of their payments system. + 35:34 + no + + <p>Chad talks with Ian Logan, an Engineering Manager at Airbnb, on the challenges, ideology, implementation, and future of their payments system.</p> +<ul> +<li><a href="https://www.airbnb.com/">Airbnb</a></li> +<li><a href="http://en.wikipedia.org/wiki/Combinatorics">Combinatorics</a></li> +<li><a href="http://nerds.airbnb.com/openair-payments-global-scale/">Open Air: Payments on a Global Scale</a></li> +<li><a href="http://www.businessinsider.com/tech-unsung-heroes-2012-12#ian-logan-for-setting-airbnb-free-5">13 Secret Rock Stars of Silicon Valley</a></li> +<li><a href="https://www.airbnb.com/disaster-response">Airbnb Disaster Response</a></li> +<li><a href="https://github.com/airbnb/trebuchet">trebuchet</a></li> +<li><a href="https://twitter.com/albertianlogan">Ian on Twitter</a></li> +</ul> + + + + Chad talks with Ian Logan, an Engineering Manager at Airbnb, on the challenges, ideology, implementation, and future of their payments system.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with Ian Logan, an Engineering Manager at Airbnb, on the challenges, ideology, implementation, and future of their payments system.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+L3oT8DJO + + ]]> + + + + 128: To Attract and Retain (Dan Croak) + https://podcast.thoughtbot.com/128 + f88c093d-f7ab-4780-908d-820d04883fdb + Sun, 04 Jan 2015 21:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks with thoughtbot CMO Dan Croak about our content marketing strategy, managing the flow of new media, and the origin of our growth team. + 47:44 + no + + <p>Chad talks with thoughtbot CMO Dan Croak about our content marketing strategy, managing the flow of new media, and the origin of our growth team.</p> +<ul> +<li><a href="http://bourbon.io/">Bourbon</a></li> +<li><a href="https://github.com/thoughtbot/paperclip">Paperclip</a></li> +<li><a href="http://playbook.thoughtbot.com/">thoughtbot Playbook</a></li> +<li><a href="http://adam.herokuapp.com/past/2011/4/28/scaling_a_development_team">How To Scale a Development Team</a>- Adam Wiggins</li> +<li><em><a href="http://rhodesmill.org/brandon/2012/one-sentence-per-line/">Semantic Linefeeds</a></em>- Brandon Rhodes</li> +<li><a href="http://www.coelevate.com/">Coelevate</a></li> +<li><a href="https://houndci.com/">Hound</a></li> +<li><a href="http://robots.thoughtbot.com/north-star-metric">North Star Metric</a></li> +<li><a href="https://github.com/nicholaides/words-to-avoid.vim">Words to Avoid</a></li> +<li><a href="https://twitter.com/Croaky">Dan on Twitter</a></li> +</ul> + + + + Chad talks with thoughtbot CMO Dan Croak about our content marketing strategy, managing the flow of new media, and the origin of our growth team.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks with thoughtbot CMO Dan Croak about our content marketing strategy, managing the flow of new media, and the origin of our growth team.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+OEowKKcr + + ]]> + + + + 127: Merging Worlds (Meng To) + https://podcast.thoughtbot.com/127 + a4a55ded-7422-4901-b7ba-68a6229c9e0d + Mon, 22 Dec 2014 07:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Jeff Smith talks to Meng To, author of Design + Code about the blurring line between developers and designers, learning tools to better communicate, and the difficulties of planing a world-wide workshop tour. + 39:40 + no + + <p>Jeff Smith talks to Meng To, author of Design + Code about the blurring line between developers and designers, learning tools to better communicate, and the difficulties of planing a world-wide workshop tour.</p> +<ul> +<li><a href="https://designcode.io/">Design + Code</a></li> +<li><a href="http://framerjs.com/">Framer</a></li> +<li><a href="http://bohemiancoding.com/sketch/">Sketch</a></li> +<li><a href="http://blog.mengto.com/">Meng's Design Blog</a></li> +<li><a href="https://designcode.io/workshop">Sketch + Swift Workshops</a></li> +<li><a href="https://twitter.com/MengTo">Meng on Twitter</a></li> +</ul> + + + + Jeff Smith talks to Meng To, author of Design + Code about the blurring line between developers and designers, learning tools to better communicate, and the difficulties of planing a world-wide workshop tour.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Jeff Smith talks to Meng To, author of Design + Code about the blurring line between developers and designers, learning tools to better communicate, and the difficulties of planing a world-wide workshop tour.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pmCsfd1i + + ]]> + + + + 126: Log In to Your Space (Zach Dunn) + https://podcast.thoughtbot.com/126 + 58e3f70b-e080-4363-a9cb-681d4d0372a5 + Mon, 15 Dec 2014 06:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks to Zach Dunn, CPO of Robin, about the future of smart spaces, working with family, and when to shift your company's scope. + 47:21 + no + + <p>Chad talks to Zach Dunn, CPO of Robin, about the future of smart spaces, working with family, and when to shift your company's scope.</p> +<ul> +<li><a href="https://robinpowered.com/">Robin</a></li> +<li><a href="http://onemightyroar.com/">One Mighty Roar</a></li> +<li><a href="http://either.io/">either</a></li> +<li><a href="http://www.boston.com/business/innovation/2013/10/04/hive-under-winners/vPoI9ifiBp7ilp9FJAlW4J/pictures.html#slide-23">2013 Boston 25 Under 25</a></li> +<li><a href="http://en.wikipedia.org/wiki/Robin_%28comics%29">Robin: The Boy Wonder</a></li> +<li><a href="http://robots.thoughtbot.com/arduino-bathroom-occupancy-detector">Bathroom Ocupancy Proof of Concept</a></li> +<li><a href="https://twitter.com/zachdunn">Zach on Twitter</a></li> +</ul> + + + + Chad talks to Zach Dunn, CPO of Robin, about the future of smart spaces, working with family, and when to shift your company's scope.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to Zach Dunn, CPO of Robin, about the future of smart spaces, working with family, and when to shift your company's scope.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+ybtIb4Nz + + ]]> + + + + 125: Rebooting (Adarsh Pandit) + https://podcast.thoughtbot.com/125 + a1c7e2c6-ba2a-459d-b89b-e2f9e26d8fcb + Sun, 07 Dec 2014 22:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks to Adarsh Pandit, thoughtbot SF Managing Director & host of the Reboot podcast, about his personal journey which inspired our newest show. + 43:51 + no + + <p>Chad talks to Adarsh Pandit, thoughtbot SF Managing Director &amp; host of the Reboot podcast, about his personal journey which inspired our newest show.</p> +<ul> +<li><a href="http://rebootshow.fm/">Reboot</a></li> +<li><a href="https://pragprog.com/book/ruby/programming-ruby">&quot;The Pickaxe&quot;</a></li> +<li><a href="https://pragprog.com/book/rails4/agile-web-development-with-rails-4"><em>Agile Development with Rails</em></a></li> +<li><a href="https://pragprog.com/book/ltp2/learn-to-program"><em>Learn to Program</em></a></li> +<li><a href="http://www.apprentice.io/">apprentice.io</a></li> +<li><a href="https://twitter.com/adarshp">Adarsh on Twitter</a></li> +</ul> + + + + Chad talks to Adarsh Pandit, thoughtbot SF Managing Director & host of the Reboot podcast, about his personal journey which inspired our newest show.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to Adarsh Pandit, thoughtbot SF Managing Director & host of the Reboot podcast, about his personal journey which inspired our newest show.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+niwaHr5Q + + ]]> + + + + 124: Maintaining Your Legacy (Scott Ford) + https://podcast.thoughtbot.com/124 + 8af63de2-f655-46b8-ae2f-b39b3626f1cf + Sun, 23 Nov 2014 20:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Chad talks to Scott Ford, founder & COO of Corgibytes, about the business of software remodeling/retrofitting, and finding value and beauty in old code. + 32:57 + no + + <p>Chad talks to Scott Ford, founder &amp; COO of Corgibytes, about the business of software remodeling/retrofitting, and finding value and beauty in old code.</p> +<ul> +<li><a href="http://corgibytes.com/">Corgibytes</a></li> +<li><a href="https://twitter.com/mscottford">Scott on Twitter</a></li> +</ul> + + + + Chad talks to Scott Ford, founder & COO of Corgibytes, about the business of software remodeling/retrofitting, and finding value and beauty in old code.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Chad talks to Scott Ford, founder & COO of Corgibytes, about the business of software remodeling/retrofitting, and finding value and beauty in old code.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+VpRCSOQq + + ]]> + + + + 123: Don't Call It a Codecation (Chris Hunt) + https://podcast.thoughtbot.com/123 + 55c8f4eb-9fad-469d-b465-67723e784e26 + Tue, 18 Nov 2014 01:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Ben & Chris Hunt catch up on their latest conference talks, podcasts, and things accomplished on their recent coding retreat. + 24:49 + no + + <p>Ben &amp; Chris Hunt catch up on their latest conference talks, podcasts, and things accomplished on their recent coding retreat.</p> +<ul> +<li><a href="http://youtu.be/6mesJxUVZyI"><em>Service Oriented Architecture at Square</em></a></li> +<li><a href="http://youtu.be/PV9Tsu6ny-0"><em>Solving the Rubik's Cube in 20 Seconds</em></a></li> +<li><a href="https://www.trailmix.life/landing">Trailmix</a></li> +<li><a href="http://turing.io/">Turing School</a></li> +<li><a href="http://spanulate.com/">Spanulate Podcast</a></li> +<li><a href="http://robots.thoughtbot.com/you-should-take-a-codecation"><em>You Should Take a Codecation</em></a></li> +<li><a href="http://www.reddit.com/r/programming/comments/2kv2d7/you_should_take_a_codecation/"><em>Codcation</em> on reddit</a></li> +<li><a href="http://www.healthyhacker.com/">Healthy Hacker Podcast</a></li> +<li><a href="https://github.com/codecation/trailmix">trailmix repo</a></li> +<li><a href="https://twitter.com/chrishunt">Chris on Twitter</a></li> +</ul> + + + + Ben & Chris Hunt catch up on their latest conference talks, podcasts, and things accomplished on their recent coding retreat.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben & Chris Hunt catch up on their latest conference talks, podcasts, and things accomplished on their recent coding retreat.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+X_pgISKk + + ]]> + + + + 122: Ruby, the Weird Way (Britt Ballard, Caleb Thompson, Richard Schneeman, Terence Lee) + https://podcast.thoughtbot.com/122 + 0f0bd139-0dde-431f-b254-51b000c58eab + Mon, 10 Nov 2014 05:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Britt Ballard leads this roundtable discussion on home-growing your own conference and their experiences, from theme and logo selection to scheduling guests and venues, turning Keep Ruby Weird from a dream into a reality. + 50:18 + no + + <p>Britt Ballard leads this roundtable discussion on home-growing your own conference and their experiences, from theme and logo selection to scheduling guests and venues, turning Keep Ruby Weird from a dream into a reality.</p> +<ul> +<li><a href="http://keeprubyweird.com/">Keep Ruby Weird</a></li> +<li><a href="http://www.yelp.com/biz/jeremiah-the-innocent-hi-how-are-you-frog-austin">Jeremiah The Innocent</a></li> +<li><a href="https://formkeep.com/">FormKeep</a></li> +<li><a href="https://twitter.com/keeprubyweird/status/489832560592056320/photo/1">Scheduling, made simple</a></li> +<li><a href="https://twitter.com/CoralineAda/status/525497374614257664">Badges</a></li> +<li><a href="http://punoff.com/">O.Henry Pun-Off</a></li> +<li><a href="https://twitter.com/keeprubyweird/status/531571173386362881/photo/1">Chauffeuring</a></li> +<li><a href="https://twitter.com/schneems/status/531848627707072512">Ruby Rody</a></li> +</ul> + + + + Britt Ballard leads this roundtable discussion on home-growing your own conference and their experiences, from theme and logo selection to scheduling guests and venues, turning Keep Ruby Weird from a dream into a reality.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Britt Ballard leads this roundtable discussion on home-growing your own conference and their experiences, from theme and logo selection to scheduling guests and venues, turning Keep Ruby Weird from a dream into a reality.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+SiNjoj12 + + ]]> + + + + 121: Prolificness (Allison House) + https://podcast.thoughtbot.com/121 + a379069b-62cc-4f94-8bb9-b02887811536 + Sun, 02 Nov 2014 23:00:00 -0500 + thoughtbot + + full + 3 + thoughtbot + Guest-Ben Chad Pytel talks with Allison House about maintaining personal growth while freelancing, and her approach to harnessing your capacity to learn. + 32:30 + no + + <p>Guest-Ben Chad Pytel talks with Allison House about maintaining personal growth while freelancing, and her approach to harnessing your capacity to learn.</p> +<ul> +<li><a href="http://allison.house/">allison.house</a></li> +<li><a href="https://www.dropbox.com/origins">Origins</a></li> +<li><a href="http://tinyhabits.com/"><em>Tiny Habits</em></a>- BJ Fogg</li> +<li><a href="http://allison.house/blog/making-tweedy-summer-noon-music-video/">&quot;Summer Noon&quot;</a>- Tweedy</li> +<li><a href="http://allison.house/blog/launching-soon/">Design Tips Signup</a></li> +<li><a href="https://twitter.com/house">House on Twitter</a></li> +</ul> + + + + Guest-Ben Chad Pytel talks with Allison House about maintaining personal growth while freelancing, and her approach to harnessing your capacity to learn.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Guest-Ben Chad Pytel talks with Allison House about maintaining personal growth while freelancing, and her approach to harnessing your capacity to learn.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+XOpDX79r + + ]]> + + + + 120: Open Your World For Commentary (Tom Lehman) + https://podcast.thoughtbot.com/120 + 5ec02c5e-4527-4ae7-98e5-6bc364410284 + Mon, 27 Oct 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Tom Lehman, creator of Genius, about the power of honesty in corporate culture, and navigating the mores of discussing salary. + 54:19 + no + + <p>Ben talks with Tom Lehman, creator of Genius, about the power of honesty in corporate culture, and navigating the mores of discussing salary.</p> +<ul> +<li><a href="http://genius.com/">Genius</a></li> +<li><a href="http://meta.genius.com/Genius-the-genius-isms-annotated">The Genius ISMs</a></li> +<li><a href="http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect">Dunning–Kruger effect</a></li> +<li><a href="http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/"><em>Don't Call Yourself a Programmer, and Other Career Advice</em></a>- Patrick McKenzie</li> +<li><a href="https://twitter.com/dumbnamenumbers">Tom on Twitter</a></li> +</ul> + + + + Ben talks with Tom Lehman, creator of Genius, about the power of honesty in corporate culture, and navigating the mores of discussing salary.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Tom Lehman, creator of Genius, about the power of honesty in corporate culture, and navigating the mores of discussing salary.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+NlwQgcmu + + ]]> + + + + 119: Create Value or Create Technology? (Pete Hunt) + https://podcast.thoughtbot.com/119 + 4b87b8b3-212a-4189-b868-b9d3d6e78c27 + Sun, 19 Oct 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Pete Hunt, formerly of Facebook & Instagram, on React and what makes this unique JavaScript library tick, as well as shifting from a technical to a business focused mindset. + 27:52 + no + + <p>Ben talks with Pete Hunt, formerly of Facebook &amp; Instagram, on React and what makes this unique JavaScript library tick, as well as shifting from a technical to a business focused mindset.</p> +<ul> +<li><a href="http://facebook.github.io/react/">React</a></li> +<li><a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm">Fielding Dissertation</a></li> +<li><a href="http://www.infoq.com/presentations/Simple-Made-Easy"><em>Simple Made Easy</em></a>- Rich Hickey</li> +<li><a href="https://twitter.com/floydophone">Pete on Twitter</a></li> +</ul> + + + + Ben talks with Pete Hunt, formerly of Facebook & Instagram, on React and what makes this unique JavaScript library tick, as well as shifting from a technical to a business focused mindset.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Pete Hunt, formerly of Facebook & Instagram, on React and what makes this unique JavaScript library tick, as well as shifting from a technical to a business focused mindset.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JYOceV4C + + ]]> + + + + 118: Scare Yourself (Dan Martell) + https://podcast.thoughtbot.com/118 + 344a193b-0133-48d0-985c-d927f00bcb00 + Sun, 12 Oct 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Dan Martell, CEO and founder of Clarity, about self-actualization in business, how life is affected by those around which one surrounds themselves and the value of staying outside one's comfort zone. + 37:46 + no + + <p>Ben talks with Dan Martell, CEO and founder of Clarity, about self-actualization in business, how life is affected by those around which one surrounds themselves and the value of staying outside one's comfort zone.</p> +<ul> +<li><a href="http://en.wikipedia.org/wiki/Maslow&#x27;s_hierarchy_of_needs">Maslow's hierarchy of needs</a></li> +<li><a href="http://blog.bleacherreport.com/2013/07/02/ira-glass-on-closing-the-gap-between-what-you-want-to-do-and-what-you-can-do/">Ira Glass on closing &quot;the gap&quot; between what you want to do and what you can do</a></li> +<li><a href="http://www.danmartell.com/hierarchy-of-entrepreneurial-needs/"><em>Maslow’s Hierarchy of Entrepreneurial Needs</em></a>- Dan Martell</li> +<li><a href="https://www.goodreads.com/book/show/81948.The_E_Myth_Revisited">The E-Myth Revisited</a></li> +<li><a href="http://fourhourchef.com/"><em>The 4-Hour Chef</em></a>- Tim Ferriss</li> +<li><a href="http://www.portage.ca/welcome">Portage Program</a></li> +<li><a href="http://www.danmartell.com/friendventory/">Friendventory</a></li> +<li><a href="https://www.headspace.com/headspace-meditation-app">Headspace App</a></li> +<li><a href="https://clarity.fm/">Clarity</a></li> +<li><a href="https://twitter.com/danmartell">Dan on Twitter</a></li> +</ul> + + + + Ben talks with Dan Martell, CEO and founder of Clarity, about self-actualization in business, how life is affected by those around which one surrounds themselves and the value of staying outside one's comfort zone.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Dan Martell, CEO and founder of Clarity, about self-actualization in business, how life is affected by those around which one surrounds themselves and the value of staying outside one's comfort zone.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+I-FUY2G4 + + ]]> + + + + 117: Designing Quality (Will Sulinski) + https://podcast.thoughtbot.com/117 + 4f37cb6b-55e6-476c-b54d-07fa2bf51fcd + Sun, 21 Sep 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Will Sulinski, founder of Pistol Lake, on translating lessons learned from the tech sector into success in the fashion industry. + + + 27:27 + no + + <p>Ben talks with Will Sulinski, founder of Pistol Lake, on translating lessons learned from the tech sector into success in the fashion industry.</p> +<ul> +<li><a href="http://www.pistollake.com/">Pistol Lake</a></li> +<li><a href="http://www.patagonia.com/us/product/let-my-people-go-surfing-paperback-book?p=BK501-0"><em>Let My People Go Surfing</em></a></li> +<li><a href="http://podcasts.thoughtbot.com/giantrobots/78">Chris Lindland Episode</a></li> +<li><a href="https://twitter.com/wsul">Will on Twitter</a></li> +</ul> + + + + Ben talks with Will Sulinski, founder of Pistol Lake, on translating lessons learned from the tech sector into success in the fashion industry.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Will Sulinski, founder of Pistol Lake, on translating lessons learned from the tech sector into success in the fashion industry.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+w6RS1mP9 + + ]]> + + + + 116: A Model Jellyfish (Carl Smith) + https://podcast.thoughtbot.com/116 + ee33ba0f-56b3-49c1-bb4f-db5988684b01 + Sun, 14 Sep 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with nGen Works founder Carl Smith about alternatives to a "flat" structure, remote management & community building. + + + 31:51 + no + + <p>Ben talks with nGen Works founder Carl Smith about alternatives to a &quot;flat&quot; structure, remote management &amp; community building.</p> +<ul> +<li><a href="http://www.ngenworks.com/">nGen Works</a></li> +<li><a href="http://unmatchedstyle.com/category/bizcraft">BizCraft Podcast</a></li> +<li><a href="http://www.ngenworks.com/blog/technically-simple-episode-1-why-do-projects-always-take-so-long">Technically Simple Podcast</a></li> +<li><a href="http://www.danpink.com/books/drive"><em>Drive</em></a> by Daniel Pink</li> +<li><a href="http://dpm2014.com/category/dpm-radio/">DPM Radio</a></li> +<li><a href="http://bureauofdigitalaffairs.com/">The Bureau of Digital Affairs</a></li> +<li><a href="http://www.qcatpro.com/">QCat</a></li> +<li><a href="https://twitter.com/carlsmith">Carl on Twitter</a></li> +</ul> + + + + Ben talks with nGen Works founder Carl Smith about alternatives to a "flat" structure, remote management & community building.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with nGen Works founder Carl Smith about alternatives to a "flat" structure, remote management & community building.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_qwe6J-g + + ]]> + + + + 115: There's a Spectrum Involved Here (Brandon Bloom) + https://podcast.thoughtbot.com/115 + fe5f845d-b297-493d-844e-24568df3be3b + Sun, 07 Sep 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Brandon Bloom about finding the right tool for the job, there being too many objects in OO Programing and the importance for a full spectrum of options, regardless of the choice. + + + 37:04 + no + + <p>Ben talks with Brandon Bloom about finding the right tool for the job, there being too many objects in OO Programing and the importance for a full spectrum of options, regardless of the choice.</p> +<ul> +<li><a href="http://code.org/educate/hoc">Hour of Code Campaign</a></li> +<li><a href="https://github.com/swannodette/om/blob/master/README.md">Om</a></li> +<li><a href="http://www.wolfram.com/mathematica/">Mathematica</a></li> +<li><a href="http://www.brandonbloom.name/blog/2014/01/08/unsound-and-incomplete/">Unsound and Incomplete</a></li> +<li><a href="http://www.brandonbloom.name/blog/2013/06/18/oop-cycles/">Trivial Cycles in Object Oriented Programming</a></li> +<li><a href="https://twitter.com/BrandonBloom">Brandon on Twitter</a></li> +</ul> + + + + Ben talks with Brandon Bloom about finding the right tool for the job, there being too many objects in OO Programing and the importance for a full spectrum of options, regardless of the choice.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Brandon Bloom about finding the right tool for the job, there being too many objects in OO Programing and the importance for a full spectrum of options, regardless of the choice.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8w3dgdn2 + + ]]> + + + + 114: Offer Value First (Ryan Delk) + https://podcast.thoughtbot.com/114 + ff278ed3-d559-4fa2-ba30-9781d9e52466 + Sun, 31 Aug 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Gumroad grower Ryan Delk about standing out from your peers by adding value before you ask for value. + + + 24:58 + no + + <p>Ben talks with Gumroad grower Ryan Delk about standing out from your peers by adding value before you ask for value.</p> +<ul> +<li><a href="https://gumroad.com/">Gumroad</a></li> +<li><a href="http://vimeo.com/26021720">Chris Sacca on Foundation:</a> &quot;Create Value Before You Ask For Value Back&quot; Section Around 14:50</li> +<li><a href="https://twitter.com/delk">Ryan on Twitter</a></li> +</ul> + + + + Ben talks with Gumroad grower Ryan Delk about standing out from your peers by adding value before you ask for value.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Gumroad grower Ryan Delk about standing out from your peers by adding value before you ask for value.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+caRS4QOz + + ]]> + + + + 113: Minimum Path to Awesome (Rob Walling) + https://podcast.thoughtbot.com/113 + 13212d19-ad31-4d0c-9e56-e9102d90c20e + Sun, 24 Aug 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben and Rob Walling, founder of Drip and HitTail, discuss engaging your audience, the path to building new habits and the need to create. + + + 32:54 + no + + <p>Ben and Rob Walling, founder of Drip and HitTail, discuss engaging your audience, the path to building new habits and the need to create.</p> +<ul> +<li><a href="https://www.getdrip.com/">Drip</a></li> +<li><a href="https://www.hittail.com/">HitTail</a></li> +<li><a href="http://www.microconf.com/">MicroConf</a></li> +<li><a href="http://www.softwarebyrob.com/2014/07/31/the-biggest-gamble-of-your-career/">The Biggest Gamble of Your Career</a></li> +<li><a href="http://tinyhabits.com/">Tiny Habits</a></li> +<li><a href="http://www.startupsfortherestofus.com/about">Startups For The Rest Of Us Podcast</a></li> +<li><a href="https://twitter.com/robwalling">Rob on Twitter</a></li> +</ul> + + + + Ben and Rob Walling, founder of Drip and HitTail, discuss engaging your audience, the path to building new habits and the need to create.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Rob Walling, founder of Drip and HitTail, discuss engaging your audience, the path to building new habits and the need to create.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+1NL3ebFV + + ]]> + + + + 112: Data By Design (Joanne Cheng) + https://podcast.thoughtbot.com/112 + 622c5f06-b367-4991-868c-1cf0714a106e + Sun, 17 Aug 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to developer Joanne Cheng about lessons learned from the conference circuit, as well as the subject of her latest conf talk, Data-Driven-Documents within JavaScript, and trends in dashboard design. + + + 26:32 + no + + <p>Ben talks to developer Joanne Cheng about lessons learned from the conference circuit, as well as the subject of her latest conf talk, Data-Driven-Documents within JavaScript, and trends in dashboard design.</p> +<ul> +<li><a href="http://d3js.org/">D3</a></li> +<li><a href="http://shop.oreilly.com/product/0636920026938.do">Interactive Data Visualization for the Web</a></li> +<li><a href="http://www.edwardtufte.com/tufte/">Edward Tufte</a></li> +<li><a href="http://www.perceptualedge.com/articles/misc/WhyMostDashboardsFail.pdf">Why Most Dashboards Fail</a>- Stephen Few</li> +<li><a href="http://flowingdata.com/">FlowingData</a></li> +<li><a href="https://github.com/overtone/overtone">Overtone</a></li> +<li><a href="http://robots.thoughtbot.com/lets-talk-about-dials">Let's Talk About Dials</a></li> +<li><a href="https://twitter.com/joannecheng">Joanne on Twitter</a></li> +<li><a href="http://www.airpair.com/airconf2014">AirConf</a></li> +</ul> + + + + Ben talks to developer Joanne Cheng about lessons learned from the conference circuit, as well as the subject of her latest conf talk, Data-Driven-Documents within JavaScript, and trends in dashboard design.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to developer Joanne Cheng about lessons learned from the conference circuit, as well as the subject of her latest conf talk, Data-Driven-Documents within JavaScript, and trends in dashboard design.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+73cPdTnt + + ]]> + + + + 111: Thinking Outside the Loop (Chris Granger) + https://podcast.thoughtbot.com/111 + c3f7c437-ee0a-412b-b946-41db2971962c + Sun, 10 Aug 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks with Chris Granger, creator of Light Table, about building a better IDE and envisioning a world where all programming happens inside a database and anyone can do it. + + + 41:45 + no + + <p>Ben talks with Chris Granger, creator of Light Table, about building a better IDE and envisioning a world where all programming happens inside a database and anyone can do it.</p> +<ul> +<li><a href="http://www.lighttable.com/">Light Table</a></li> +<li><a href="http://www.chris-granger.com/2014/03/27/toward-a-better-programming/">Toward a Better Programming</a></li> +<li><a href="https://www.youtube.com/watch?v=L6iUm_Cqx2s">Aurora StrangeLoop 2013 Demo</a></li> +<li><a href="http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf">Exploring Data-Centric, Declarative Programming for the Cloud</a></li> +<li><a href="https://twitter.com/ibdknox">Chris on Twitter</a></li> +</ul> + + + + Ben talks with Chris Granger, creator of Light Table, about building a better IDE and envisioning a world where all programming happens inside a database and anyone can do it.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Chris Granger, creator of Light Table, about building a better IDE and envisioning a world where all programming happens inside a database and anyone can do it.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Ysge3iZw + + ]]> + + + + 110: Protecting Invisible Things (Eric Mill) + https://podcast.thoughtbot.com/110 + 09c254f9-fd47-491a-b449-ae73ab208ea3 + Sun, 03 Aug 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + This week Ben talks with former thoughtbotter, and creator of Is It Christmas, Eric Mill about the power of blogging, the personal empowerment offered by the internet and the role of government in the digital age. + + + 32:10 + no + + <p>This week Ben talks with former thoughtbotter, and creator of Is It Christmas, Eric Mill about the power of blogging, the personal empowerment offered by the internet and the role of government in the digital age.</p> +<ul> +<li><a href="https://isitchristmas.com/">Is It Christmas?</a></li> +<li><a href="https://konklone.com/post/the-door-to-the-fisa-court">The Door to the FISA Court</a></li> +<li><a href="https://konklone.com/post/switch-to-https-now-for-free">Switch to HTTPS Now, For Free</a></li> +<li><a href="http://tinyletter.com/civichacking">Civic Hacking Weekly</a></li> +<li><a href="https://konklone.com/post/2000-year-problems">2,000-Year Problems</a></li> +<li><a href="http://www.bluestatedigital.com/">Blue State Digital</a></li> +<li><a href="http://sunlightfoundation.com/">The Sunlight Foundation</a></li> +<li><a href="https://scout.sunlightfoundation.com/">Scout Search Engine</a></li> +<li><a href="https://18f.gsa.gov/">18f</a></li> +<li><a href="https://github.com/unitedstates">United States Project</a></li> +<li><a href="https://twitter.com/konklone">Eric on Twitter</a></li> +</ul> + + + + This week Ben talks with former thoughtbotter, and creator of Is It Christmas, Eric Mill about the power of blogging, the personal empowerment offered by the internet and the role of government in the digital age.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben talks with former thoughtbotter, and creator of Is It Christmas, Eric Mill about the power of blogging, the personal empowerment offered by the internet and the role of government in the digital age.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+wTtGESE1 + + ]]> + + + + 109: Venturing Thru Capital (Alex Taussig) + https://podcast.thoughtbot.com/109 + 5d877180-bd87-4dde-82f0-a05ec8638d68 + Sun, 27 Jul 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben delves behind the scenes of a VC firm with Alex Taussig of Highland Capital. + + + 36:18 + no + + <p>Ben delves behind the scenes of a VC firm with Alex Taussig of Highland Capital.</p> +<ul> +<li><a href="http://www.hcp.com/">Highland Capital Partners</a></li> +<li><a href="https://twitter.com/ataussig">Alex on Twitter</a></li> +</ul> + + + + Ben delves behind the scenes of a VC firm with Alex Taussig of Highland Capital.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben delves behind the scenes of a VC firm with Alex Taussig of Highland Capital.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+xqYmjcxg + + ]]> + + + + 108: Picking Your Obsession (Brett Van Zuiden) + https://podcast.thoughtbot.com/108 + 6321f4d1-50a8-4647-b78b-be85e3ab26ca + Sun, 20 Jul 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to Brett Van Zuiden, founder of Filepicker, about the importance of finding your specialization and passion in your industry, as well as his experiences in Y Combinator. + + + 38:18 + no + + <p>Ben talks to Brett Van Zuiden, founder of Filepicker, about the importance of finding your specialization and passion in your industry, as well as his experiences in Y Combinator.</p> +<ul> +<li><a href="https://www.inkfilepicker.com/">Filepicker</a></li> +<li><a href="http://techcrunch.com/2012/04/12/how-to-scale-a-1-billion-startup-a-guide-from-instagram-co-founder-mike-krieger/">Scaling Instagram</a></li> +<li><a href="https://ifttt.com/">IFTTT</a></li> +<li><a href="http://entertainment.time.com/2005/10/16/all-time-100-novels/">All-TIME 100 Novels</a></li> +<li><a href="http://www.ycombinator.com/">Y Combinator</a></li> +<li><a href="https://twitter.com/brettcvz">Brett on Twitter</a></li> +</ul> + + + + Ben talks to Brett Van Zuiden, founder of Filepicker, about the importance of finding your specialization and passion in your industry, as well as his experiences in Y Combinator.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Brett Van Zuiden, founder of Filepicker, about the importance of finding your specialization and passion in your industry, as well as his experiences in Y Combinator.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tUxgjbPm + + ]]> + + + + 107: The Best Secrets Kept (Sara Haider) + https://podcast.thoughtbot.com/107 + 59740c1f-cde3-4b0e-b28e-5958f1c8a325 + Sun, 13 Jul 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben talks to Sarah Haider, Android lead at Secret, about anonymity in social media, her work with Girls Who Code and Android Development. + + + 32:58 + no + + <p>Ben talks to Sarah Haider, Android lead at Secret, about anonymity in social media, her work with Girls Who Code and Android Development.</p> +<ul> +<li><a href="http://girlswhocode.com/">Girls Who Code</a></li> +<li><a href="https://www.secret.ly/">Secret</a></li> +<li><a href="https://github.com/thoughtbot/hound">Hound</a></li> +<li><a href="https://twitter.com/pandemona">Sara on Twitter</a></li> +</ul> + + + + Ben talks to Sarah Haider, Android lead at Secret, about anonymity in social media, her work with Girls Who Code and Android Development.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to Sarah Haider, Android lead at Secret, about anonymity in social media, her work with Girls Who Code and Android Development.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mKYEhJoE + + ]]> + + + + 106: Sprinting Thru Design (Alex Baldwin & Galen Frechette) + https://podcast.thoughtbot.com/106 + 03eb9ef4-ed5f-4a73-9934-5a800b92ba07 + Sun, 06 Jul 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben is joined by fellow thoughtbotters Alex & Galen to break down their product design sprint workflow. + + + 28:10 + no + + <p>Ben is joined by fellow thoughtbotters Alex &amp; Galen to break down their product design sprint workflow.</p> +<ul> +<li><a href="http://www.gv.com/lib/the-product-design-sprint-a-five-day-recipe-for-startups">Google Ventures:</a> Design Sprint Recipe</li> +<li><a href="http://www.ideo.com/work/human-centered-design-toolkit/">Human Centered Design Toolkit</a></li> +<li><a href="http://www.christenseninstitute.org/key-concepts/jobs-to-be-done/">Jobs To Be Done Framework</a></li> +<li><a href="http://youtu.be/s9nbTB33hbg">Milkshake Marketing</a></li> +<li><a href="http://www.thisismetis.com/product-design">Product Design Bootcamp</a></li> +</ul> + + + + Ben is joined by fellow thoughtbotters Alex & Galen to break down their product design sprint workflow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by fellow thoughtbotters Alex & Galen to break down their product design sprint workflow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+xiDjqAcm + + ]]> + + + + 105: Use Your Info-magination (Marc-André Cournoyer) + https://podcast.thoughtbot.com/105 + f71f1d45-db77-41ca-9e87-4ff29a54ddee + Sun, 29 Jun 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben welcomes Marc-André Cournoyer of Coded Inc. to discuss self-marketing and sustaining info-product platforms. + + + 32:32 + no + + <p>Ben welcomes Marc-André Cournoyer of Coded Inc. to discuss self-marketing and sustaining info-product platforms.</p> +<ul> +<li><a href="http://code.macournoyer.com/thin/">Thin</a></li> +<li><a href="http://createyourproglang.com/">How to Create Your Own Freaking Awesome Programming Language</a></li> +<li><a href="https://www.goodreads.com/book/show/123684.Influence">Influence-</a> Robert Cialdini</li> +<li><a href="https://www.goodreads.com/book/show/2621927-scientific-advertising">Scientific Advertising-</a> Claude C. Hopkins</li> +<li><a href="http://codedinc.com/">Coded Inc.</a></li> +<li><a href="http://www.growing-object-oriented-software.com/">Growing Object-Oriented Software Guided by Tests</a></li> +<li><a href="https://learn.thoughtbot.com/workshops/18-test-driven-rails">Test-Driven Rails</a></li> +<li><a href="http://www.greatcodeclub.com/">The Great Code Club</a></li> +<li><a href="http://forum.thoughtbot.com/t/rejected-weekly-iteration-episode/1785">Rejected Weekly Iteration</a></li> +</ul> + + + + Ben welcomes Marc-André Cournoyer of Coded Inc. to discuss self-marketing and sustaining info-product platforms.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben welcomes Marc-André Cournoyer of Coded Inc. to discuss self-marketing and sustaining info-product platforms.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cXT7h9nA + + ]]> + + + + 104: Maintaining The Meat Machines (Adam Wiggins) + https://podcast.thoughtbot.com/104 + 55ae3c15-8929-4e57-b16e-47cc9a420bf8 + Sun, 22 Jun 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + On this weeks Giant Robots Ben welcomes Adam Wiggins, Heroku co-founder and former CTO, to join as more of a guest host than guest. They discuss team size/structure, project scalability, the benefits of working abroad & self-maintenance best practices. + + + 40:30 + no + + <p>On this weeks Giant Robots Ben welcomes Adam Wiggins, Heroku co-founder and former CTO, to join as more of a guest host than guest. They discuss team size/structure, project scalability, the benefits of working abroad &amp; self-maintenance best practices.</p> +<ul> +<li><a href="http://about.adamwiggins.com/">Adam Wiggins</a></li> +<li><a href="https://www.heroku.com/">Heroku</a></li> +<li><a href="http://www.hellointernet.fm/podcast/10">&quot;2 Dudes Talking&quot; podcast genre discussion</a></li> +<li><a href="http://adam.herokuapp.com/past/2011/4/28/scaling_a_development_team/">How to Scale a Development Team</a></li> +<li><a href="http://www.joelonsoftware.com/articles/fog0000000017.html">Good Software Takes Ten Years. Get Used To It.</a></li> +<li><a href="https://www.goodreads.com/book/show/81948.The_E_Myth_Revisited">The E-Myth Revisited</a></li> +<li><a href="https://www.goodreads.com/book/show/29587.Down_and_Out_in_the_Magic_Kingdom">Down and Out in the Magic Kingdom</a></li> +</ul> + + + + On this weeks Giant Robots Ben welcomes Adam Wiggins, Heroku co-founder and former CTO, to join as more of a guest host than guest. They discuss team size/structure, project scalability, the benefits of working abroad & self-maintenance best practices.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On this weeks Giant Robots Ben welcomes Adam Wiggins, Heroku co-founder and former CTO, to join as more of a guest host than guest. They discuss team size/structure, project scalability, the benefits of working abroad & self-maintenance best practices.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MgcVwrWE + + ]]> + + + + 103: Consulting the Consultants (Adam Wathan, Chris Keithlin) + https://podcast.thoughtbot.com/103 + 12b83d90-c7e7-45a9-8c91-0f2a252b3a0b + Sun, 15 Jun 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Giant Robots welcome Adam & Chris of Vehikl who inquire about project selection / scheduling, portfolio building & customer-facing. + + + 36:30 + no + + <p>Giant Robots welcome Adam &amp; Chris of Vehikl who inquire about project selection / scheduling, portfolio building &amp; customer-facing.</p> +<ul> +<li><a href="http://vehikl.com/">Vehikl</a></li> +<li><a href="http://playbook.thoughtbot.com/">thoughtbot Playbook</a></li> +<li><a href="https://twitter.com/adamwathan">Adam on Twitter</a></li> +<li><a href="https://www.linkedin.com/in/chriskeithlin">Chris on LinkedIn</a></li> +</ul> + + + + Giant Robots welcome Adam & Chris of Vehikl who inquire about project selection / scheduling, portfolio building & customer-facing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Giant Robots welcome Adam & Chris of Vehikl who inquire about project selection / scheduling, portfolio building & customer-facing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cqFV_BJF + + ]]> + + + + 102: Put It Out To The World (Peter Cooper) + https://podcast.thoughtbot.com/102 + 94cf8741-1a00-4374-bbcd-9ca57f0467f0 + Sun, 08 Jun 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben sits down with Peter Cooper, of Cooper Press, on his evolution from blogger to published author and publisher. + + + 28:21 + no + + <p>Ben sits down with Peter Cooper, of Cooper Press, on his evolution from blogger to published author and publisher.</p> +<ul> +<li><a href="https://cooperpress.com/">Cooper Press</a></li> +<li><a href="http://www.rubyinside.com/">Ruby Inside</a></li> +<li><a href="http://youtu.be/p5EIrSM8dCA">Ruby on Rails vs PHP video</a></li> +<li><a href="http://fluentconf.com/">Fluent Conf</a></li> +<li><a href="http://www.reddit.com/r/lifeprotips">/r/lifeprotips</a></li> +<li><a href="https://twitter.com/peterc">Peter on Twitter</a></li> +</ul> + + + + Ben sits down with Peter Cooper, of Cooper Press, on his evolution from blogger to published author and publisher.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben sits down with Peter Cooper, of Cooper Press, on his evolution from blogger to published author and publisher.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+AOGVA_aC + + ]]> + + + + 101: Developing Skills (Alex Fox, Jatin Bhandari) + https://podcast.thoughtbot.com/101 + d736af96-3ba3-4ed2-a2f2-83af6ef46606 + Sun, 01 Jun 2014 20:00:00 -0400 + thoughtbot + + full + 3 + thoughtbot + Ben is joined by Alex & Jatin, recent graduates of the first thoughtbot / Metis Ruby on Rails Bootcamp, to talk about the process, experience and feedback on their path to becoming junior developers. + + + 38:48 + no + + <p>Ben is joined by Alex &amp; Jatin, recent graduates of the first thoughtbot / Metis Ruby on Rails Bootcamp, to talk about the process, experience and feedback on their path to becoming junior developers.</p> +<ul> +<li><a href="http://www.thisismetis.com/">Ruby on Rails Bootcamp</a></li> +<li><a href="https://twitter.com/alexdfox">Alex on Twitter</a></li> +<li><a href="https://twitter.com/g2jatin">Jatin on Twitter</a></li> +</ul> + + + + Ben is joined by Alex & Jatin, recent graduates of the first thoughtbot / Metis Ruby on Rails Bootcamp, to talk about the process, experience and feedback on their path to becoming junior developers.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by Alex & Jatin, recent graduates of the first thoughtbot / Metis Ruby on Rails Bootcamp, to talk about the process, experience and feedback on their path to becoming junior developers.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+52BXk8Es + + ]]> + + + + 100: Adequately Industrious (Aaron Patterson) + https://podcast.thoughtbot.com/100 + a8dc2dfa-3b9c-4712-91eb-c398f76ad407 + Sun, 25 May 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + On our special 100th episode Aaron Patterson joins Ben from RailsConf to talk AdequateRecord, frustrations in software, bulk meat discounts, the finer nuances of cat-naming and the importance of scientific thinking in web development. + + + 45:31 + no + + <p>On our special 100th episode Aaron Patterson joins Ben from RailsConf to talk AdequateRecord, frustrations in software, bulk meat discounts, the finer nuances of cat-naming and the importance of scientific thinking in web development.</p> +<ul> +<li><a href="http://tenderlovemaking.com/2014/02/19/adequaterecord-pro-like-activerecord.html">AdequateRecord</a></li> +<li><a href="http://www.call-cc.org/">Chicken Scheme</a></li> +<li><a href="http://www.confreaks.com/videos/3393-railsconf-closing-keynote">Aaron's RailsConf Closing Keynote</a></li> +<li><a href="https://twitter.com/tenderlove">Aaron on Twitter</a></li> +</ul> + + + + On our special 100th episode Aaron Patterson joins Ben from RailsConf to talk AdequateRecord, frustrations in software, bulk meat discounts, the finer nuances of cat-naming and the importance of scientific thinking in web development.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On our special 100th episode Aaron Patterson joins Ben from RailsConf to talk AdequateRecord, frustrations in software, bulk meat discounts, the finer nuances of cat-naming and the importance of scientific thinking in web development.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+f8GqLKR5 + + ]]> + + + + 99: You Are Not Alone (Greg Baugues) + https://podcast.thoughtbot.com/99 + 075a376b-6261-43a7-94cb-38dd2de51938 + Sun, 18 May 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + From RailsConf, Ben & Greg Baugues of Twilio discuss how mental illness affects the development community and the importance of, as well as resources to, proper treatment. + + + 19:30 + no + + <p>From RailsConf, Ben &amp; Greg Baugues of Twilio discuss how mental illness affects the development community and the importance of, as well as resources to, proper treatment.</p> +<ul> +<li><a href="http://baugues.com/depression">Business of Software Video</a></li> +<li><a href="https://leanpub.com/developers-and-depression/">Developers and Depression book</a></li> +<li><a href="http://devpressed.com/">Devpressed Forum</a></li> +<li><a href="http://funkatron.com/osmi.html">Open Sourcing Mental Illness</a></li> +<li><a href="http://prompt.engineyard.com/">prompt Campaign</a></li> +<li><a href="https://twitter.com/greggyb">Greg on Twitter</a></li> +</ul> + + + + From RailsConf, Ben & Greg Baugues of Twilio discuss how mental illness affects the development community and the importance of, as well as resources to, proper treatment.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + From RailsConf, Ben & Greg Baugues of Twilio discuss how mental illness affects the development community and the importance of, as well as resources to, proper treatment.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+imzn7o6a + + ]]> + + + + 98: Memorization Techniques (Chris Hunt) + https://podcast.thoughtbot.com/98 + 36994abb-95fe-4576-8160-9d61f131976c + Sun, 11 May 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + From RailsConf, Ben talks to Chris Hunt of Github about techniques for enhancing spacial memory, competitive personalities, the coffee infamy of the Pacific Northwest and Clojure testing. + + + 19:51 + no + + <p>From RailsConf, Ben talks to Chris Hunt of Github about techniques for enhancing spacial memory, competitive personalities, the coffee infamy of the Pacific Northwest and Clojure testing.</p> +<ul> +<li><a href="http://en.wikipedia.org/wiki/Dominic_O&#x27;Brien">Dominic O'Brien Bibliography</a></li> +<li><a href="http://www.worldmemorychampionships.com/">World Memory Championships</a></li> +<li><a href="https://twitter.com/chrishunt">Chris on Twitter</a></li> +</ul> + + + + From RailsConf, Ben talks to Chris Hunt of Github about techniques for enhancing spacial memory, competitive personalities, the coffee infamy of the Pacific Northwest and Clojure testing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + From RailsConf, Ben talks to Chris Hunt of Github about techniques for enhancing spacial memory, competitive personalities, the coffee infamy of the Pacific Northwest and Clojure testing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jpChrO7x + + ]]> + + + + 97: Railing Against Rails (Ernie Miller) + https://podcast.thoughtbot.com/97 + 3a209e88-53cc-4f6e-9509-3310d4c83660 + Sun, 04 May 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Live from RailsConf Ben & Ernie Miller explore his "Curmudgeon" talk, modules and the importance of nuance. + + + 25:38 + no + + <p>Live from RailsConf Ben &amp; Ernie Miller explore his &quot;Curmudgeon&quot; talk, modules and the importance of nuance.</p> +<ul> +<li><a href="http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html">TDD is Dead</a></li> +<li><a href="http://www.appriss.com/VINE.html">Appriss: VINE</a></li> +<li><a href="https://twitter.com/erniemiller">Ernie on Twitter</a></li> +</ul> + + + + Live from RailsConf Ben & Ernie Miller explore his "Curmudgeon" talk, modules and the importance of nuance.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Live from RailsConf Ben & Ernie Miller explore his "Curmudgeon" talk, modules and the importance of nuance.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+wsAGqGwW + + ]]> + + + + 96: Business is Hard (Jeff Casimir) + https://podcast.thoughtbot.com/96 + b3179129-6e6c-41a4-9ef8-d53cec45d66f + Sun, 27 Apr 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Live from RailsConf, Ben talks to Executive Director of The Turing School Jeff Casimir on Conf-stress, the lack of jobs in open source and the challenges of learning to run a business. + + + 35:12 + no + + <p>Live from RailsConf, Ben talks to Executive Director of The Turing School Jeff Casimir on Conf-stress, the lack of jobs in open source and the challenges of learning to run a business.</p> +<ul> +<li><a href="http://turing.io/">Turing School of Software &amp; Design</a></li> +<li><a href="http://heartbleed.com/">Heartbleed Bug</a></li> +<li><a href="http://www.goodreads.com/book/show/81948.The_E_Myth_Revisited">The E-Myth Revisited</a></li> +</ul> + + + + Live from RailsConf, Ben talks to Executive Director of The Turing School Jeff Casimir on Conf-stress, the lack of jobs in open source and the challenges of learning to run a business.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Live from RailsConf, Ben talks to Executive Director of The Turing School Jeff Casimir on Conf-stress, the lack of jobs in open source and the challenges of learning to run a business.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+CUMA-U5X + + ]]> + + + + 95: Making Time (Chas Emerick) + https://podcast.thoughtbot.com/95 + c82a48f6-68db-4aad-86f9-fca345a82d56 + Sun, 20 Apr 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + This week Ben sits down with Chas Emerick to discuss his latest venture, The Quilt Project, start up philosophies and the importance of balanced time management. + + + 41:55 + no + + <p>This week Ben sits down with Chas Emerick to discuss his latest venture, The Quilt Project, start up philosophies and the importance of balanced time management.</p> +<ul> +<li><a href="http://cemerick.com/2013/02/15/100-time/">100% Time</a></li> +<li><a href="http://shop.oreilly.com/product/0636920013754.do">Clojure Programming: Practical Lisp for the Java World</a></li> +<li><a href="http://www.quilt.org/">The Quilt Project</a></li> +<li><a href="http://snowtide.com/">PDF TextStream</a></li> +<li><a href="https://www.youtube.com/watch?v=shm7QcJMvig">Rich Hickey's Ant Simulator</a></li> +<li><a href="http://en.wikipedia.org/wiki/Von_Neumann_architecture">Von Neumann architecture</a></li> +<li><a href="http://en.wiktionary.org/wiki/heaven_forfend">heaven forfend</a></li> +</ul> + + + + This week Ben sits down with Chas Emerick to discuss his latest venture, The Quilt Project, start up philosophies and the importance of balanced time management.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben sits down with Chas Emerick to discuss his latest venture, The Quilt Project, start up philosophies and the importance of balanced time management.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Sfb6of7h + + ]]> + + + + 94: The Nature of Writing (Diana Zmuda, Jessie Young) + https://podcast.thoughtbot.com/94 + c01956ab-77c4-4264-a46c-a3d4adccd798 + Sun, 13 Apr 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben is joined by Diana & Jessie of thoughtbot San Francisco to discuss their latest book, iOS on Rails, the concept of releasing a book in Beta and the importance of apprenticeships to emerging junior developers. + + + 36:24 + no + + <p>Ben is joined by Diana &amp; Jessie of thoughtbot San Francisco to discuss their latest book, iOS on Rails, the concept of releasing a book in Beta and the importance of apprenticeships to emerging junior developers.</p> +<ul> +<li><a href="http://iosonrails.net">iOS on Rails</a></li> +<li><a href="http://roy.gbiv.com/">Roy Fielding</a></li> +<li><a href="http://www.raywenderlich.com/tutorials">Ray Wenderlich iPhone Tutorials</a></li> +<li><a href="https://www.flinto.com/">Flinto</a></li> +<li><a href="https://twitter.com/dazmuda">Diana on Twitter</a></li> +<li><a href="https://twitter.com/jessieay">Jessie on Twitter</a></li> +</ul> + + + + Ben is joined by Diana & Jessie of thoughtbot San Francisco to discuss their latest book, iOS on Rails, the concept of releasing a book in Beta and the importance of apprenticeships to emerging junior developers.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by Diana & Jessie of thoughtbot San Francisco to discuss their latest book, iOS on Rails, the concept of releasing a book in Beta and the importance of apprenticeships to emerging junior developers.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GL-E9Ym9 + + ]]> + + + + 93: Diversity of Approach (David Nolen) + https://podcast.thoughtbot.com/93 + 1580cf4c-7775-4e82-871d-f41d622b281b + Sun, 06 Apr 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + On this weeks show Ben talks to David Nolen, Rails & JavaScript developer for the NY Times, about being a steward of ClojureScript, functional programming, the advantages of immutable values and Om. + + + 41:38 + no + + <p>On this weeks show Ben talks to David Nolen, Rails &amp; JavaScript developer for the NY Times, about being a steward of ClojureScript, functional programming, the advantages of immutable values and Om.</p> +<ul> +<li><a href="http://swannodette.github.io/">David Nolen</a></li> +<li><a href="https://github.com/clojure/clojurescript">ClojureScript</a></li> +<li><a href="http://facebook.github.io/react/">React</a></li> +<li><a href="http://kitchentablecoders.com/class/2014/04/12/the-immutable-stack/">Kitchen Table Coders: The Immutable Stack</a></li> +<li><a href="https://twitter.com/swannodette">David on Twitter</a></li> +<li><a href="http://www.iosonrails.net">iOS on Rails (Beta)</a></li> +</ul> + + + + On this weeks show Ben talks to David Nolen, Rails & JavaScript developer for the NY Times, about being a steward of ClojureScript, functional programming, the advantages of immutable values and Om.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On this weeks show Ben talks to David Nolen, Rails & JavaScript developer for the NY Times, about being a steward of ClojureScript, functional programming, the advantages of immutable values and Om.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+pHQyqLqW + + ]]> + + + + 92: Program to the Machine You Have (Ryan Hoover) + https://podcast.thoughtbot.com/92 + c0ffbafb-8417-407d-8f7f-720b3a463dca + Sun, 30 Mar 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben and Ryan Hoover, co-creator of Product Hunt, talk revenue models, the value of blogging, diversification of skills, and tiny steps towards major change. + + + 32:32 + no + + <p>Ben and Ryan Hoover, co-creator of Product Hunt, talk revenue models, the value of blogging, diversification of skills, and tiny steps towards major change.</p> +<ul> +<li><a href="http://tradecrafted.com/">Tradecraft:</a> Training people to succeed in traction roles at high-growth startups</li> +<li><a href="http://www.producthunt.co/">Product Hunt:</a> A daily leaderboard of the best new products</li> +<li><a href="http://blog.ryanhoover.me/knowing-when-its-time-to-move-on">Knowing When It's Time To Move On</a></li> +<li><a href="http://ryanhoover.me/post/67471168540/dont-learn-to-code">Don't Learn To Code</a></li> +<li><a href="http://tinyhabits.com/">BJ Fogg- Tiny Habits method</a></li> +<li><a href="https://twitter.com/rrhoover">Ryan on Twitter</a></li> +</ul> + + + + Ben and Ryan Hoover, co-creator of Product Hunt, talk revenue models, the value of blogging, diversification of skills, and tiny steps towards major change.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Ryan Hoover, co-creator of Product Hunt, talk revenue models, the value of blogging, diversification of skills, and tiny steps towards major change.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7Udk9Q9W + + ]]> + + + + 91: Not Ruining Design (Rich Thornett) + https://podcast.thoughtbot.com/91 + 8818f620-7c4d-4383-82fc-175da790c939 + Sun, 23 Mar 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + This week on Giant Robots, Ben talks to Rich Thornett, Co-Founder of Dribbble, about the formation and criticisms of the company, the role of product design and remote team management. + + + 34:18 + no + + <p>This week on Giant Robots, Ben talks to Rich Thornett, Co-Founder of Dribbble, about the formation and criticisms of the company, the role of product design and remote team management.</p> +<ul> +<li><a href="http://dribbble.com/">dribbble</a></li> +<li><a href="https://twitter.com/frogandcode">Rich on Twitter</a></li> +</ul> + + + + This week on Giant Robots, Ben talks to Rich Thornett, Co-Founder of Dribbble, about the formation and criticisms of the company, the role of product design and remote team management.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on Giant Robots, Ben talks to Rich Thornett, Co-Founder of Dribbble, about the formation and criticisms of the company, the role of product design and remote team management.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+GDDz4Q9S + + ]]> + + + + 90: Do One Thing Well (George Brocklehurst, Mike Burns) + https://podcast.thoughtbot.com/90 + 56292915-37d4-4f7c-9fd8-bbe84004ce88 + Sun, 16 Mar 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben talks to George Brocklehurst & Mike Burns of thoughtbot's Stockholm office on creating and distributing gitsh, an interactive shell for Git, and why it shouldn't be a Ruby gem. + + + 22:31 + no + + <p>Ben talks to George Brocklehurst &amp; Mike Burns of thoughtbot's Stockholm office on creating and distributing gitsh, an interactive shell for Git, and why it shouldn't be a Ruby gem.</p> +<ul> +<li><a href="http://robots.thoughtbot.com/announcing-gitsh">Get Gitsh</a></li> +<li><a href="http://www.meetup.com/Stockholm-Vim/">Stockholm Vim</a></li> +<li><a href="http://www.meetup.com/Haskell-Stockholm/">Haskell Stockholm</a></li> +<li><a href="http://robots.thoughtbot.com/announcing-the-classical-code-reading-group-of">Classical Code Reading Group</a></li> +</ul> + + + + Ben talks to George Brocklehurst & Mike Burns of thoughtbot's Stockholm office on creating and distributing gitsh, an interactive shell for Git, and why it shouldn't be a Ruby gem.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks to George Brocklehurst & Mike Burns of thoughtbot's Stockholm office on creating and distributing gitsh, an interactive shell for Git, and why it shouldn't be a Ruby gem.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+uzIPCst_ + + ]]> + + + + 89: Moving Beyond The Wheel (Mahmoud Abdelkader) + https://podcast.thoughtbot.com/89 + 77a7f08d-7cc5-4281-b4b9-1a3ec3e6d52b + Sun, 09 Mar 2014 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + This week on Giant Robots, Mahmoud Abdelkader of Balanced joins Ben to talk the priorities in ones career trajectory, the role of a successful CTO, and the benefits of radically open transparency. + + + 35:23 + no + + <p>This week on Giant Robots, Mahmoud Abdelkader of Balanced joins Ben to talk the priorities in ones career trajectory, the role of a successful CTO, and the benefits of radically open transparency.</p> +<ul> +<li><a href="https://www.balancedpayments.com/">Balanced</a></li> +<li><a href="http://blog.balancedpayments.com/state-machines/">What Does Balanced Do?</a></li> +<li><a href="https://github.com/balanced">Balanced Github</a></li> +<li><a href="https://github.com/balanced-cookbooks">Balanced Cookbooks</a></li> +<li><a href="https://twitter.com/mahmoudimus">Mahmoud on Twitter</a></li> +</ul> + + + + This week on Giant Robots, Mahmoud Abdelkader of Balanced joins Ben to talk the priorities in ones career trajectory, the role of a successful CTO, and the benefits of radically open transparency.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on Giant Robots, Mahmoud Abdelkader of Balanced joins Ben to talk the priorities in ones career trajectory, the role of a successful CTO, and the benefits of radically open transparency.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+iV_JRNW4 + + ]]> + + + + 88: Prospering Communities (Kyle Bragger) + https://podcast.thoughtbot.com/88 + eda759df-3f9a-490b-b4ea-bb3085e056f2 + Sun, 02 Mar 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week Ben Talks with Kyle Bragger of Elepath, Inc on the nature of online community building, advertising vs subscription revenue models and the importance of continued creative output (and actually releasing it to the world). + + + 28:25 + no + + <p>This week Ben Talks with Kyle Bragger of Elepath, Inc on the nature of online community building, advertising vs subscription revenue models and the importance of continued creative output (and actually releasing it to the world).</p> +<ul> +<li><a href="http://www.elepath.com/">Elepath, Inc</a></li> +<li><a href="https://exposure.so/">Exposure</a></li> +<li><a href="http://en.wikipedia.org/wiki/Mauerpark#Bearpit_Karaoke_Show">Mauerpark Karaoke</a></li> +<li><a href="http://forrst.com/">Forrst</a></li> +<li><a href="http://drewwilson.com/">Drew Wilson</a></li> +</ul> + + + + This week Ben Talks with Kyle Bragger of Elepath, Inc on the nature of online community building, advertising vs subscription revenue models and the importance of continued creative output (and actually releasing it to the world).

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben Talks with Kyle Bragger of Elepath, Inc on the nature of online community building, advertising vs subscription revenue models and the importance of continued creative output (and actually releasing it to the world).

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+fiShU9XW + + ]]> + + + + 87: Monitoring the Bathrooms (Tony DiPasquale) + https://podcast.thoughtbot.com/87 + 43662f33-2e84-4c18-881b-59b314566c39 + Sun, 23 Feb 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week on Giant Robots, Ben chats with Tony DiPasquale on utilizing Arduino engineering to solve 0th world problems. + + + 23:04 + no + + <p>This week on Giant Robots, Ben chats with Tony DiPasquale on utilizing Arduino engineering to solve 0th world problems.</p> +<ul> +<li><a href="http://www.arduino.cc/">Arduino Home Page</a></li> +<li><a href="http://robots.thoughtbot.com/arduino-bathroom-occupancy-detector">Original Bathroom Occupancy Proof of Concept Breakdown</a></li> +<li><a href="http://robots.thoughtbot.com/low-power-custom-arduino-sensor-board">Full Low Power Custom Arduino Sensor Board Instructions!</a></li> +</ul> + + + + This week on Giant Robots, Ben chats with Tony DiPasquale on utilizing Arduino engineering to solve 0th world problems.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on Giant Robots, Ben chats with Tony DiPasquale on utilizing Arduino engineering to solve 0th world problems.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+D1ddNUx5 + + ]]> + + + + 86: Humility and Patience (Peter Reinhardt) + https://podcast.thoughtbot.com/86 + c2cc9dc0-3d7c-4945-ac0c-99cad689f7fd + Sun, 16 Feb 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + In this week's episode, we're joined by Peter Reinhardt, Co-founder and CEO of Segment.io. Ben and Peter discuss the product, their tech stack, the companies big pivot to Segment.io, their growth and future plans. They also discuss leaving MIT to start a company, getting along with your co-founders, nuclear reactors, hiking, and much more. + + + 21:50 + no + + <p>In this week's episode, we're joined by Peter Reinhardt, Co-founder and CEO of Segment.io. Ben and Peter discuss the product, their tech stack, the companies big pivot to Segment.io, their growth and future plans. They also discuss leaving MIT to start a company, getting along with your co-founders, nuclear reactors, hiking, and much more.</p> +<ul> +<li><a href="http://segment.io">Segment.io</a></li> +<li><a href="http://nodejs.org">node.js</a></li> +<li><a href="http://expressjs.com">Express.js</a></li> +<li><a href="http://en.wikipedia.org/wiki/Thorium-based_nuclear_power">Thorium reactors</a></li> +<li><a href="http://en.wikipedia.org/wiki/Molten_salt_reactor">Molten salt reactor</a></li> +<li><a href="http://www.kulfoto.com/interesting/444/scary-photos-from-heights/6760/sitting-on-the-trolltunga-rock-norway">Norway diving board rock, Trolltunga</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/reinpk">@reinpk</a> on twitter.</p> + + + + In this week's episode, we're joined by Peter Reinhardt, Co-founder and CEO of Segment.io. Ben and Peter discuss the product, their tech stack, the companies big pivot to Segment.io, their growth and future plans. They also discuss leaving MIT to start a company, getting along with your co-founders, nuclear reactors, hiking, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @reinpk on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this week's episode, we're joined by Peter Reinhardt, Co-founder and CEO of Segment.io. Ben and Peter discuss the product, their tech stack, the companies big pivot to Segment.io, their growth and future plans. They also discuss leaving MIT to start a company, getting along with your co-founders, nuclear reactors, hiking, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @reinpk on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+fCxCscY8 + + ]]> + + + + 85: I Want These Ideas To Be Free (Max Temkin) + https://podcast.thoughtbot.com/85 + 996efdce-b836-490d-be91-6dc39579c0e2 + Sun, 09 Feb 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week, Ben is joined by Max Temkin, creator of Cards Against Humanity and Humans vs. Zombies. Max talks about his success with Cards Against Humanity and his feelings of impostor syndrome. He talks about some of his other projects including his first indie game, Humans vs. Zombies. Most recently Max had a multiplayer PC game published called Samurai Gunn. Max talks about the "open source" nature of his games. They discuss money, sustainability, kickstarter, and much more. + + + 40:12 + no + + <p>This week, Ben is joined by Max Temkin, creator of Cards Against Humanity and Humans vs. Zombies. Max talks about his success with Cards Against Humanity and his feelings of impostor syndrome. He talks about some of his other projects including his first indie game, Humans vs. Zombies. Most recently Max had a multiplayer PC game published called Samurai Gunn. Max talks about the &quot;open source&quot; nature of his games. They discuss money, sustainability, kickstarter, and much more.</p> +<ul> +<li><a href="http://maxistentialism.com/">Maxistentialism</a></li> +<li><a href="http://www.cardsagainsthumanity.com/">Cards Against Humanity</a></li> +<li><a href="http://humansvszombies.org/">Humans vs. Zombies</a></li> +<li><a href="http://maxistentialism.com/samuraigunn/">Samurai Gunn</a></li> +<li><a href="http://5by5.tv/b2w/153">Back to Work: Anxiety's a Goat</a></li> +<li><a href="http://blog.maxistentialism.com/">Max's Blog</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/MaxTemkin">@MaxTemkin</a> on twitter.</p> + + + + This week, Ben is joined by Max Temkin, creator of Cards Against Humanity and Humans vs. Zombies. Max talks about his success with Cards Against Humanity and his feelings of impostor syndrome. He talks about some of his other projects including his first indie game, Humans vs. Zombies. Most recently Max had a multiplayer PC game published called Samurai Gunn. Max talks about the "open source" nature of his games. They discuss money, sustainability, kickstarter, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @MaxTemkin on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week, Ben is joined by Max Temkin, creator of Cards Against Humanity and Humans vs. Zombies. Max talks about his success with Cards Against Humanity and his feelings of impostor syndrome. He talks about some of his other projects including his first indie game, Humans vs. Zombies. Most recently Max had a multiplayer PC game published called Samurai Gunn. Max talks about the "open source" nature of his games. They discuss money, sustainability, kickstarter, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @MaxTemkin on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+UJRaG2wp + + ]]> + + + + 84: The Bus Number (Harper Reed) + https://podcast.thoughtbot.com/84 + 1050744b-b2b8-405c-98a9-dd01736b019c + Sun, 02 Feb 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + On this week's episode, Ben talks with Harper Reed, former CTO of Threadless, former CTO of Obama for America, and currently CEO of Modest. Harper talks about management and his "cabal" of people that he likes to work with. He also discusses his experience on the campaign, healthcare.gov, and procurement laws. When asked about his playbook for success, Harper talks about networking strategies, the use of different languages for different problems, craziness, and much more. + + + 46:20 + no + + <p>On this week's episode, Ben talks with Harper Reed, former CTO of Threadless, former CTO of Obama for America, and currently CEO of Modest. Harper talks about management and his &quot;cabal&quot; of people that he likes to work with. He also discusses his experience on the campaign, healthcare.gov, and procurement laws. When asked about his playbook for success, Harper talks about networking strategies, the use of different languages for different problems, craziness, and much more.</p> +<ul> +<li><a href="http://harperreed.com/">Harper Reed</a></li> +<li><a href="http://hbs1963.com/">If I Knew Then</a></li> +<li><a href="http://www.nytimes.com/2013/10/25/opinion/getting-to-the-bottom-of-healthcaregovs-flop.html?_r=0">Why the Government Never Gets Tech Right</a></li> +<li><a href="https://github.com/harperreed">Harper's GitHub</a></li> +<li><a href="http://www.nata2.org/">Harper's Blog</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/harper">@harper</a> on twitter.</p> + + + + On this week's episode, Ben talks with Harper Reed, former CTO of Threadless, former CTO of Obama for America, and currently CEO of Modest. Harper talks about management and his "cabal" of people that he likes to work with. He also discusses his experience on the campaign, healthcare.gov, and procurement laws. When asked about his playbook for success, Harper talks about networking strategies, the use of different languages for different problems, craziness, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @harper on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On this week's episode, Ben talks with Harper Reed, former CTO of Threadless, former CTO of Obama for America, and currently CEO of Modest. Harper talks about management and his "cabal" of people that he likes to work with. He also discusses his experience on the campaign, healthcare.gov, and procurement laws. When asked about his playbook for success, Harper talks about networking strategies, the use of different languages for different problems, craziness, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @harper on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JUJrnare + + ]]> + + + + 83: Turning the Tables (Ben Orenstein) + https://podcast.thoughtbot.com/83 + d17156e3-4a79-4cf6-8e15-96b13f4b7eea + Sun, 26 Jan 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + On this week's special episode, Chad Pytel turns the tables and interviews host Ben Orenstein. They discuss the process of running the podcast and Ben's roots in programming and computer science. Ben talks about his Vim mastery, how he got into public speaking, and his experiences speaking at RailsConf. This year Ben is organizing the live coding track at RailConf. Ben describes his strategies for learning programming, how he's getting into Clojure, and much more! + + + 53:30 + no + + <p>On this week's special episode, Chad Pytel turns the tables and interviews host Ben Orenstein. They discuss the process of running the podcast and Ben's roots in programming and computer science. Ben talks about his Vim mastery, how he got into public speaking, and his experiences speaking at RailsConf. This year Ben is organizing the live coding track at RailConf. Ben describes his strategies for learning programming, how he's getting into Clojure, and much more!</p> +<ul> +<li><a href="http://codeulate.com/">Ben's Blog</a></li> +<li><a href="https://github.com/r00k">Ben's Github</a></li> +<li><a href="http://robots.thoughtbot.com/the-vim-learning-curve-is-a-myth">The Vim Learning Curve is a Myth</a></li> +<li><a href="http://podcasts.thoughtbot.com/giantrobots/44">Chad Fowler on the Giant Robots podcast</a></li> +<li><a href="http://chadfowler.com/blog/2013/05/25/how-to-get-your-conference-talk-accepted/">How to Get Your Conference Talk Accepted</a></li> +<li><a href="http://www.youtube.com/watch?v=l9JXH7JPjR4">How to Talk to Developers (Rails Conf 2013)</a></li> +<li><a href="http://www.4clojure.com/">4clojure.org</a></li> +<li><a href="http://www.wellnessfx.com/">WellnessFX</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/cpytel">@cpytel</a> on twitter.</p> + + + + On this week's special episode, Chad Pytel turns the tables and interviews host Ben Orenstein. They discuss the process of running the podcast and Ben's roots in programming and computer science. Ben talks about his Vim mastery, how he got into public speaking, and his experiences speaking at RailsConf. This year Ben is organizing the live coding track at RailConf. Ben describes his strategies for learning programming, how he's getting into Clojure, and much more!

+ + + +

Follow @thoughtbot, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On this week's special episode, Chad Pytel turns the tables and interviews host Ben Orenstein. They discuss the process of running the podcast and Ben's roots in programming and computer science. Ben talks about his Vim mastery, how he got into public speaking, and his experiences speaking at RailsConf. This year Ben is organizing the live coding track at RailConf. Ben describes his strategies for learning programming, how he's getting into Clojure, and much more!

+ + + +

Follow @thoughtbot, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rIv4F_ns + + ]]> + + + + 82: Teach all the things (Matt Knox) + https://podcast.thoughtbot.com/82 + 3573e6ec-2be9-4b90-a2ea-13db3ebebd95 + Sun, 19 Jan 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week's episode features Matt Knox of Twitter. Matt is a part of Twitter's university team which teaches new Twitter recruits about the company. He works as an engineer as well in order to stay current. Matt discusses his background as an engineer, and how he got into teaching. He discusses using Storm, essentially a real-time Hadoop, for Twitter. Ben and Matt talk about the importance of keeping a portfolio as a programmer and deliberate practice routines for coding, and more. + + + 38:25 + no + + <p>This week's episode features Matt Knox of Twitter. Matt is a part of Twitter's university team which teaches new Twitter recruits about the company. He works as an engineer as well in order to stay current. Matt discusses his background as an engineer, and how he got into teaching. He discusses using Storm, essentially a real-time Hadoop, for Twitter. Ben and Matt talk about the importance of keeping a portfolio as a programmer and deliberate practice routines for coding, and more.</p> +<ul> +<li><a href="https://github.com/mattknox">Matt Knox's Github</a></li> +<li><a href="http://mattknox.com/">Matt Knox's Blog</a></li> +<li><a href="http://storm-project.net/">Storm</a></li> +<li><a href="http://hadoop.apache.org/">Hadoop</a></li> +<li><a href="http://www.mattknox.com/essay-fodder/managers_coders.html">The Things They Carry</a></li> +<li><a href="http://codeulate.com/2007/12/on-the-fundamentals-of-programming/">On the Fundamentals of Programming</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/mattknox">@mattknox</a> on twitter.</p> + + + + This week's episode features Matt Knox of Twitter. Matt is a part of Twitter's university team which teaches new Twitter recruits about the company. He works as an engineer as well in order to stay current. Matt discusses his background as an engineer, and how he got into teaching. He discusses using Storm, essentially a real-time Hadoop, for Twitter. Ben and Matt talk about the importance of keeping a portfolio as a programmer and deliberate practice routines for coding, and more.

+ + + +

Follow @thoughtbot, @r00k, and @mattknox on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week's episode features Matt Knox of Twitter. Matt is a part of Twitter's university team which teaches new Twitter recruits about the company. He works as an engineer as well in order to stay current. Matt discusses his background as an engineer, and how he got into teaching. He discusses using Storm, essentially a real-time Hadoop, for Twitter. Ben and Matt talk about the importance of keeping a portfolio as a programmer and deliberate practice routines for coding, and more.

+ + + +

Follow @thoughtbot, @r00k, and @mattknox on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+LVHsJao6 + + ]]> + + + + 81: An Agent of Change (Seth Godin) + https://podcast.thoughtbot.com/81 + b833dc4f-e2d8-4ed7-b53f-039444904280 + Sun, 12 Jan 2014 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + In this week's episode, Ben Orenstein is joined by best selling author, Seth Godin. Seth describes himself as an entrepreneur, a blogger, and an agent of change. They discuss art, frustration, and the endless pursuit of perfection as an artist. In his newest book, The Icarus Deception, Seth discusses seeking art in your work and looking beyond standards and production. They talk about the importance of finding connections with other artists and people who can provide meaningful feedback. They discuss several of Seth's blog posts which are linked below, and much more. + + + 33:41 + no + + <p>In this week's episode, Ben Orenstein is joined by best selling author, Seth Godin. Seth describes himself as an entrepreneur, a blogger, and an agent of change. They discuss art, frustration, and the endless pursuit of perfection as an artist. In his newest book, The Icarus Deception, Seth discusses seeking art in your work and looking beyond standards and production. They talk about the importance of finding connections with other artists and people who can provide meaningful feedback. They discuss several of Seth's blog posts which are linked below, and much more.</p> +<ul> +<li><a href="http://www.sethgodin.com/sg/books.asp">Seth's Books</a></li> +<li><a href="http://sethgodin.typepad.com/seths_blog/2014/01/how-to-draw-an-owl.html">How to Draw an Owl</a></li> +<li><a href="http://sethgodin.typepad.com/seths_blog/2013/12/pick-three.html">Pick Three</a></li> +<li><a href="http://sethgodin.typepad.com/seths_blog/2014/01/but-what-if-i-fail.html">But What if I Fail</a></li> +<li><a href="http://kryptoncommunitycollegeslc.weebly.com/1/post/2013/10/krypton-course-001-seth-godin-on-shipping.html">Krypton Course</a></li> +<li><a href="http://www.lewishyde.com/publications/the-gift">The Gift by Lewis Hyde</a></li> +<li><a href="http://www.stevenpressfield.com/the-war-of-art/">The War of Art</a></li> +<li><a href="http://www.npr.org/2013/10/21/236207605/scott-adams-explains-how-to-fail-at-almost-everything-except-dilbert">Interview with Scott Adams</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/thisissethsblog">@thisissethsblog</a> on twitter.</p> + + + + In this week's episode, Ben Orenstein is joined by best selling author, Seth Godin. Seth describes himself as an entrepreneur, a blogger, and an agent of change. They discuss art, frustration, and the endless pursuit of perfection as an artist. In his newest book, The Icarus Deception, Seth discusses seeking art in your work and looking beyond standards and production. They talk about the importance of finding connections with other artists and people who can provide meaningful feedback. They discuss several of Seth's blog posts which are linked below, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @thisissethsblog on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this week's episode, Ben Orenstein is joined by best selling author, Seth Godin. Seth describes himself as an entrepreneur, a blogger, and an agent of change. They discuss art, frustration, and the endless pursuit of perfection as an artist. In his newest book, The Icarus Deception, Seth discusses seeking art in your work and looking beyond standards and production. They talk about the importance of finding connections with other artists and people who can provide meaningful feedback. They discuss several of Seth's blog posts which are linked below, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @thisissethsblog on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+cEa3beb5 + + ]]> + + + + 80: Growing Business (Josh Pigford) + https://podcast.thoughtbot.com/80 + 540be990-7b48-4ecd-b94f-b3eb14650ec8 + Sun, 22 Dec 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week on Giant Robots, Ben Orenstein chats with Josh Pigford about time management, entrepreneurship and farming + + + 28:11 + no + + <p>This week on Giant Robots, Ben Orenstein chats with Josh Pigford about time management, entrepreneurship and farming</p> +<ul> +<li><a href="http://joshpigford.com">Josh Pigford's Website</a></li> +<li><a href="https://twitter.com/Shpigford">Josh Pigford's Twitter</a></li> +<li><a href="http://tinyfarmstead.com">Tiny Farmstead</a></li> +<li><a href="https://www.baremetrics.io">Baremetrics</a></li> +<li><a href="http://popsurvey.com">Popsurvey</a></li> +<li><a href="https://www.temper.io">Temper</a></li> +</ul> + + + + This week on Giant Robots, Ben Orenstein chats with Josh Pigford about time management, entrepreneurship and farming

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on Giant Robots, Ben Orenstein chats with Josh Pigford about time management, entrepreneurship and farming

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+6EXg-9J3 + + ]]> + + + + 79: The Gentle Wise One (Uncle Bob Martin) + https://podcast.thoughtbot.com/79 + b5d8c26b-013f-4db9-9abc-754369cdbcd9 + Sun, 15 Dec 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week on Giant Robots, Ben Orenstein talks with Uncle Bob Martin about functional programming, ethics, and writing. + + + 37:59 + no + + <p>This week on Giant Robots, Ben Orenstein talks with Uncle Bob Martin about functional programming, ethics, and writing.</p> +<ul> +<li><a href="https://twitter.com/unclebobmartin">Bob Martin's Twitter</a></li> +<li><a href="https://sites.google.com/site/unclebobconsultingllc/">Clean Coder</a></li> +<li><a href="http://blog.8thlight.com/uncle-bob/archive.html">Bob Martin's Blog</a></li> +</ul> + + + + This week on Giant Robots, Ben Orenstein talks with Uncle Bob Martin about functional programming, ethics, and writing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on Giant Robots, Ben Orenstein talks with Uncle Bob Martin about functional programming, ethics, and writing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+oniiXUM_ + + ]]> + + + + 78: Fancy Pants (Chris Lindland) + https://podcast.thoughtbot.com/78 + ccebe5f6-f0ea-4c62-9b81-f3adc05e17c6 + Sun, 08 Dec 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week on Giant Robots, Ben Orenstein talks with Chris Lindland, CEO of Betabrand.com about online fashion, self-generating product and dress-pant-sweatpants. + + + 28:06 + no + + <p>This week on Giant Robots, Ben Orenstein talks with Chris Lindland, CEO of Betabrand.com about online fashion, self-generating product and dress-pant-sweatpants.</p> +<ul> +<li><a href="https://twitter.com/cordarounds">Chris Lindland's Twitte</a></li> +<li><a href="http://www.betabrand.com">Betabrand</a></li> +</ul> + + + + This week on Giant Robots, Ben Orenstein talks with Chris Lindland, CEO of Betabrand.com about online fashion, self-generating product and dress-pant-sweatpants.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on Giant Robots, Ben Orenstein talks with Chris Lindland, CEO of Betabrand.com about online fashion, self-generating product and dress-pant-sweatpants.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jHq6n8oG + + ]]> + + + + 77: A Beautiful Thing (Harold Giménez) + https://podcast.thoughtbot.com/77 + 50105f49-3892-42ff-850e-1869b22374e4 + Sun, 01 Dec 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week on Giant Robots, Ben Orenstein speaks with Harold Giménez, Heroku postgres leader, about postgres, data management, and beer brewing. + + + 51:16 + no + + <p>This week on Giant Robots, Ben Orenstein speaks with Harold Giménez, Heroku postgres leader, about postgres, data management, and beer brewing.</p> +<ul> +<li><a href="https://twitter.com/hgmnz">Harold's Twitter</a></li> +<li><a href="http://practiceovertheory.com">Harold's Blog</a></li> +<li><a href="https://www.heroku.com">Heroku</a></li> +</ul> + + + + This week on Giant Robots, Ben Orenstein speaks with Harold Giménez, Heroku postgres leader, about postgres, data management, and beer brewing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on Giant Robots, Ben Orenstein speaks with Harold Giménez, Heroku postgres leader, about postgres, data management, and beer brewing.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+2mICPYIj + + ]]> + + + + 76: The Boutique Agency + https://podcast.thoughtbot.com/76 + b15bf4d6-9423-41b7-9c03-81b4946c4f19 + Sun, 24 Nov 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + Ben Orenstein speaks with Alex Kesler, founder and CEO of inSegment about digital marketing, GTD and productivity. + + + 40:51 + no + + <p>Ben Orenstein speaks with Alex Kesler, founder and CEO of inSegment about digital marketing, GTD and productivity.</p> +<ul> +<li><a href="http://www.insegment.com">inSegment</a></li> +<li><a href="https://twitter.com/inSegment">inSegment's Twitter</a></li> +</ul> + + + + Ben Orenstein speaks with Alex Kesler, founder and CEO of inSegment about digital marketing, GTD and productivity.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein speaks with Alex Kesler, founder and CEO of inSegment about digital marketing, GTD and productivity.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+fuTFCPrf + + ]]> + + + + 75: Embedding Democracy (Catherine Bracy) + https://podcast.thoughtbot.com/75 + 44e04579-d665-4157-951c-8606ff251c7e + Sun, 17 Nov 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + This week Ben Orenstein interviews Catherine Bracy, Director of Community Organizing at Code for America. + + + 31:21 + no + + <p>This week Ben Orenstein interviews Catherine Bracy, Director of Community Organizing at Code for America.</p> +<ul> +<li><a href="https://twitter.com/cbracy">Catherine Bracy's Twitter</a></li> +<li><a href="http://codeforamerica.org">Code for America</a></li> +</ul> + + + + This week Ben Orenstein interviews Catherine Bracy, Director of Community Organizing at Code for America.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben Orenstein interviews Catherine Bracy, Director of Community Organizing at Code for America.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+S6vm2umz + + ]]> + + + + 74: Fancy Scala (Sean Griffin) + https://podcast.thoughtbot.com/74 + 55c37d63-cbc3-4859-98d0-e459dbb522a6 + Sun, 10 Nov 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + Ben Orenstein speaks with thoughtbot developer Sean Griffin about scala and ruby. + + + 32:05 + no + + <p>Ben Orenstein speaks with thoughtbot developer Sean Griffin about scala and ruby.</p> +<ul> +<li><a href="https://twitter.com/sgrif">Sean Griffin's Twitter</a></li> +<li><a href="http://computationbook.com">Understanding Computation Tom Stuart</a></li> +<li><a href="http://www.scala-lang.org">Scala Website</a></li> +<li><a href="https://www.coursera.org/course/progfun">Martin Odersky's Free Class</a></li> +<li><a href="http://ofps.oreilly.com/titles/9780596155957/">Programming Scala</a></li> +</ul> + + + + Ben Orenstein speaks with thoughtbot developer Sean Griffin about scala and ruby.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein speaks with thoughtbot developer Sean Griffin about scala and ruby.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bw24Lsdd + + ]]> + + + + 73: Spooky Robots Haunting other Spooky Robots (Drew Neil) + https://podcast.thoughtbot.com/73 + e29520ca-695a-419d-b9dd-314ea191d2e7 + Sun, 03 Nov 2013 19:00:00 -0500 + thoughtbot + + full + 2 + thoughtbot + Ben Orenstein speaks with Drew Neil, creator of vimcasts.org about teaching writing and workshopping vim. + + + 33:03 + no + + <p>Ben Orenstein speaks with Drew Neil, creator of vimcasts.org about teaching writing and workshopping vim.</p> +<ul> +<li><a href="http://vimcasts.org">Vimcasts</a></li> +<li><a href="http://pragprog.com/book/dnvim/practical-vim">Practical Vim: Edit at the Speed of Thought</a></li> +<li><a href="https://twitter.com/nelstrom">Drew Neil's Twitter</a></li> +</ul> + + + + Ben Orenstein speaks with Drew Neil, creator of vimcasts.org about teaching writing and workshopping vim.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein speaks with Drew Neil, creator of vimcasts.org about teaching writing and workshopping vim.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+jLbofSXw + + ]]> + + + + 72: Up in the Mountains (Nathan Barry) + https://podcast.thoughtbot.com/72 + 8f339f6f-269f-4c58-bf50-c39649a02efd + Sun, 27 Oct 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + This week on The Giant Robots Podcast, Ben Orenstein chats with Nathan Barry about book writing, teaching and self employment. + + + 32:39 + no + + <p>This week on The Giant Robots Podcast, Ben Orenstein chats with Nathan Barry about book writing, teaching and self employment.</p> +<ul> +<li><a href="https://twitter.com/nathanbarry">Nathan's Twitter</a></li> +<li><a href="http://nathanbarry.com">Nathan's Website</a></li> +<li><a href="http://nathanbarry.com/app-design-handbook/">The App Design Handbook</a></li> +</ul> + + + + This week on The Giant Robots Podcast, Ben Orenstein chats with Nathan Barry about book writing, teaching and self employment.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week on The Giant Robots Podcast, Ben Orenstein chats with Nathan Barry about book writing, teaching and self employment.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YJJ9aNcw + + ]]> + + + + 71: The Power of the Truth + https://podcast.thoughtbot.com/71 + 170bd48f-4c05-44f3-b909-c05510a8acd1 + Sun, 20 Oct 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Josh Clayton and Ben Orenstein interview each other about their managing director positions. + + + 39:53 + no + + <p>Josh Clayton and Ben Orenstein interview each other about their managing director positions.</p> +<ul> +<li><a href="https://twitter.com/r00k">Ben Orenstein's Twitter</a></li> +<li><a href="https://twitter.com/joshuaclayton">Josh Clayton's Twitter</a></li> +</ul> + + + + Josh Clayton and Ben Orenstein interview each other about their managing director positions.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Josh Clayton and Ben Orenstein interview each other about their managing director positions.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MtHqKzAi + + ]]> + + + + 70: Let Your Freak Flag Fly + https://podcast.thoughtbot.com/70 + f69a9055-8a92-445e-94b2-18bf577fc671 + Sun, 13 Oct 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben Orenstein speaks with Jeff Atwood about Discourse, forum software, and soylent. + + + 40:17 + no + + <p>Ben Orenstein speaks with Jeff Atwood about Discourse, forum software, and soylent.</p> +<ul> +<li><a href="http://www.codinghorror.com/blog/">Coding Horror</a></li> +<li><a href="http://stackexchange.com">StackExchange</a></li> +<li><a href="http://www.discourse.org">Discourse.org</a></li> +<li><a href="http://discourse.soylent.me">discourse.soylent.me</a></li> +<li><a href="https://twitter.com/codinghorror">Jeff Atwood's Twitter</a></li> +</ul> + + + + Ben Orenstein speaks with Jeff Atwood about Discourse, forum software, and soylent.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein speaks with Jeff Atwood about Discourse, forum software, and soylent.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+AhkGLb1x + + ]]> + + + + 69: Geocoding in the Now + https://podcast.thoughtbot.com/69 + 8a936a3d-f3b5-4e15-b00d-fa7e97a641e6 + Sun, 06 Oct 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben Orenstein interviews Josh Clayton and Laila Winner on their book, Geocoding on Rails. + + + 14:50 + no + + <p>Ben Orenstein interviews Josh Clayton and Laila Winner on their book, Geocoding on Rails.</p> +<ul> +<li><a href="https://learn.thoughtbot.com/products/22-geocoding-on-rails">Geocoding on Rails</a></li> +<li><a href="https://twitter.com/joshuaclayton">Josh Clayton's Twitter</a></li> +<li><a href="https://github.com/malandrina">Laila Winner's Github</a></li> +</ul> + + + + Ben Orenstein interviews Josh Clayton and Laila Winner on their book, Geocoding on Rails.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein interviews Josh Clayton and Laila Winner on their book, Geocoding on Rails.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+tJSZzHt1 + + ]]> + + + + 68: Simplicity and Elegance + https://podcast.thoughtbot.com/68 + 843a7b91-8e9d-4506-8fb7-fdc736484f29 + Sun, 29 Sep 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben Orenstein and Paul Farnell, CEO of Litmus, talk about starting up, business practices, and Litmus. + + + 34:10 + no + + <p>Ben Orenstein and Paul Farnell, CEO of Litmus, talk about starting up, business practices, and Litmus.</p> +<ul> +<li><a href="https://twitter.com/unsalted">Paul Farnell's Twitter</a></li> +<li><a href="http://litmus.com">Litmus</a></li> +</ul> + + + + Ben Orenstein and Paul Farnell, CEO of Litmus, talk about starting up, business practices, and Litmus.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein and Paul Farnell, CEO of Litmus, talk about starting up, business practices, and Litmus.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+MnAfXgXL + + ]]> + + + + 67: The Data Optimist + https://podcast.thoughtbot.com/67 + adde52f3-0695-4b97-8fbe-fb98ccca7836 + Sun, 22 Sep 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben Orenstein and Hilary Mason, Data Scientist in Residence at Accel Partners, talk about Data Science, Bitly and Cheeseburgers. + + + 29:41 + no + + <p>Ben Orenstein and Hilary Mason, Data Scientist in Residence at Accel Partners, talk about Data Science, Bitly and Cheeseburgers.</p> +<ul> +<li><a href="http://rt.ly/sign_in?next=%2F">rt.ly search engine</a></li> +<li><a href="http://blog.okcupid.com">OkCupid Blog</a></li> +<li><a href="http://hackny.org">hackNY</a></li> +<li><a href="http://www.datagotham.com">DataGotham</a></li> +<li><a href="http://www.nycresistor.com">NYC Resister</a></li> +<li><a href="http://www.hilarymason.com">Hilary Mason's Personal Website</a></li> +<li><a href="https://twitter.com/hmason">Hilary Mason on Twitter</a></li> +</ul> + + + + Ben Orenstein and Hilary Mason, Data Scientist in Residence at Accel Partners, talk about Data Science, Bitly and Cheeseburgers.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein and Hilary Mason, Data Scientist in Residence at Accel Partners, talk about Data Science, Bitly and Cheeseburgers.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+r2MvmLpj + + ]]> + + + + 66: With Great Power Comes Great Responsibility + https://podcast.thoughtbot.com/66 + 51400dab-585d-4000-a7ed-a3d050f0a00f + Sun, 15 Sep 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben talks with Anthony Eden about DNSimple, programming languages and code retreats. + + + 40:18 + no + + <p>Ben talks with Anthony Eden about DNSimple, programming languages and code retreats.</p> +<ul> +<li><a href="https://dnsimple.com">dnsimple</a></li> +<li><a href="https://twitter.com/aeden">Anthony Eden's Twitter</a></li> +</ul> + + + + Ben talks with Anthony Eden about DNSimple, programming languages and code retreats.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben talks with Anthony Eden about DNSimple, programming languages and code retreats.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_iUmQfo_ + + ]]> + + + + 65: No! Videos Private! + https://podcast.thoughtbot.com/65 + 09b6a8d8-fb4f-4ac0-a452-110c4951bc8e + Sun, 08 Sep 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + On this episode Ben talks with Chris Savage and Brendan Schwartz about Wistia + + + 38:25 + no + + <p>On this episode Ben talks with Chris Savage and Brendan Schwartz about Wistia</p> +<ul> +<li><a href="http://wistia.com">Wistia</a></li> +<li><a href="https://twitter.com/csavage">Chris Savage's Twitter</a></li> +<li><a href="https://twitter.com/brendan">Brendan Schwartz's Twitter</a></li> +</ul> + + + + On this episode Ben talks with Chris Savage and Brendan Schwartz about Wistia

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On this episode Ben talks with Chris Savage and Brendan Schwartz about Wistia

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+aWH7j_6- + + ]]> + + + + 64: Wistfully Into the Air + https://podcast.thoughtbot.com/64 + 075fe908-20c5-45d1-b315-2f1f52ef10d0 + Sun, 01 Sep 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode of Giant Robots Ben talks with Des Traynor about intercom, concise communication. blogging and customer outreach. + + + 36:18 + no + + <p>In this episode of Giant Robots Ben talks with Des Traynor about intercom, concise communication. blogging and customer outreach.</p> +<ul> +<li><a href="https://www.intercom.io">Intercom</a></li> +<li><a href="http://insideintercom.io">Inside Intercom Blog</a></li> +<li><a href="https://twitter.com/destraynor">Des Traynor's Twitter</a></li> +</ul> + + + + In this episode of Giant Robots Ben talks with Des Traynor about intercom, concise communication. blogging and customer outreach.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode of Giant Robots Ben talks with Des Traynor about intercom, concise communication. blogging and customer outreach.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+xQqqk3_b + + ]]> + + + + 63: Knowledge Bomb! + https://podcast.thoughtbot.com/63 + e973a9be-ea2d-4c24-876f-52fad7bfacc6 + Sun, 25 Aug 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + Ben and Chad discuss mentoring, job hunting tips and FAQ + + + 48:37 + no + + <p>Ben and Chad discuss mentoring, job hunting tips and FAQ</p> +<ul> +<li><a href="https://github.com/thoughtbot/guides/tree/master/code-review">thoughtbot Code Review Guide</a></li> +<li><a href="http://www.pairprogramwith.me/">Pair With Me</a></li> +<li><a href="http://robots.thoughtbot.com/post/50655960596/sandi-metz-rules-for-developers">Sandi Metz Rules</a></li> +</ul> + + + + Ben and Chad discuss mentoring, job hunting tips and FAQ

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben and Chad discuss mentoring, job hunting tips and FAQ

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+c7uDKYPF + + ]]> + + + + 62: Family Business + https://podcast.thoughtbot.com/62 + da8b09d8-4ffa-46a6-afd9-f0e1e7d4b204 + Sun, 18 Aug 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this of episode of Giant Robots, Ben speaks with Natalie Nagele and Ilya Sabanin about Wildbit, Beanstalk, and work flow. + + + 31:39 + no + + <p>In this of episode of Giant Robots, Ben speaks with Natalie Nagele and Ilya Sabanin about Wildbit, Beanstalk, and work flow.</p> +<ul> +<li><a href="http://wildbit.com/">Wildbit</a></li> +<li><a href="http://beanstalkapp.com/">Beanstalk</a></li> +<li><a href="https://twitter.com/isabanin">Ilya Sabanin's Twitter</a></li> +<li><a href="https://twitter.com/natalienagele">Natalie Nagele's Twitter</a></li> +</ul> + + + + In this of episode of Giant Robots, Ben speaks with Natalie Nagele and Ilya Sabanin about Wildbit, Beanstalk, and work flow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this of episode of Giant Robots, Ben speaks with Natalie Nagele and Ilya Sabanin about Wildbit, Beanstalk, and work flow.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+AUNc6lhH + + ]]> + + + + 61: Having the Craic with Paul + https://podcast.thoughtbot.com/61 + 54006a25-a88c-4258-b4d9-bea71bcecb5d + Sun, 11 Aug 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode Paul and Ben talk about tito, funconf, and organizing conferences. + + + 34:56 + no + + <p>In this episode Paul and Ben talk about tito, funconf, and organizing conferences.</p> +<ul> +<li><a href="https://twitter.com/paulca">Paul Campbell's Twitter</a></li> +<li><a href="http://www.pabcas.com">Pabcas</a></li> +<li><a href="http://www.hypertiny.com">Hypertiny</a></li> +<li><a href="https://tito.io">Tito</a></li> +</ul> + + + + In this episode Paul and Ben talk about tito, funconf, and organizing conferences.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode Paul and Ben talk about tito, funconf, and organizing conferences.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+S1EeuMJJ + + ]]> + + + + 60: Deep Dive + https://podcast.thoughtbot.com/60 + 3b28fdad-4f42-4af2-b7cf-ec507b61688b + Sun, 04 Aug 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this week's episode Ben discusses effective business practices and advice for optimal page design with special guest Patrick McKenzie. + + + 34:01 + no + + <p>In this week's episode Ben discusses effective business practices and advice for optimal page design with special guest Patrick McKenzie.</p> +<ul> +<li><a href="http://learn.thoughtbot.com">Learn Prime</a></li> +<li><a href="http://www.bingocardcreator.com/">Bingo Card Creator</a></li> +<li><a href="http://paulgraham.com/ds.html">Paul Gram (Do Things That Don't Scale)</a></li> +<li><a href="http://doubleyourfreelancingrate.com/">Double your Freelancing Rate</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/patio11">@patio11</a> on twitter.</p> + + + + In this week's episode Ben discusses effective business practices and advice for optimal page design with special guest Patrick McKenzie.

+ + + +

Follow @thoughtbot, @r00k, and @patio11 on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this week's episode Ben discusses effective business practices and advice for optimal page design with special guest Patrick McKenzie.

+ + + +

Follow @thoughtbot, @r00k, and @patio11 on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+49u9f0jm + + ]]> + + + + 59: Nowhere to Hide + https://podcast.thoughtbot.com/59 + b7f75cbe-e509-4529-9800-d3b372b1f6d8 + Sun, 28 Jul 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode, Ben Orenstein speaks with thoughtbot CTO Joe Ferris about the technical interview process at thoughtbot, and more. + + + 25:52 + no + + <p>In this episode, Ben Orenstein speaks with thoughtbot CTO Joe Ferris about the technical interview process at thoughtbot, and more.</p> +<ul> +<li><a href="http://on-ruby.blogspot.com/2007/12/flog-profiling-complexity.html">Flog tool complexity</a></li> +<li><a href="http://www.rubyinside.com/3-tools-for-drying-your-ruby-code-1305.html">Flay duplication tool</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/joeferris">@joeferris</a> on twitter.</p> + + + + In this episode, Ben Orenstein speaks with thoughtbot CTO Joe Ferris about the technical interview process at thoughtbot, and more.

+ + + +

Follow @thoughtbot, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, Ben Orenstein speaks with thoughtbot CTO Joe Ferris about the technical interview process at thoughtbot, and more.

+ + + +

Follow @thoughtbot, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+S5z5GTPs + + ]]> + + + + 58: A Thousand Neckbeards + https://podcast.thoughtbot.com/58 + c49aa4a2-2487-442b-a752-e98cb5d148e3 + Sun, 21 Jul 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + This week Ben Orenstein, Pat Brisbin, and Mike Burns talk about Haskell, Linux, functional and dynamic programming, Conway's Game of Life, and much more. + + + 31:12 + no + + <p>This week Ben Orenstein, Pat Brisbin, and Mike Burns talk about Haskell, Linux, functional and dynamic programming, Conway's Game of Life, and much more.</p> +<ul> +<li><a href="http://book.realworldhaskell.org/">Real World Haskell</a></li> +<li><a href="http://hackage.haskell.org/packages/hackage.html">Hackage</a></li> +<li><a href="http://www.bitstorm.org/gameoflife/">Conways Game of LIfe</a></li> +<li><a href="http://learnyouahaskell.com/">Learn You A Haskell</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/patbrisbin">@patbrisbin</a> and <a href="http://twitter.com/mikeburns">@mikeburns</a> on twitter.</p> + + + + This week Ben Orenstein, Pat Brisbin, and Mike Burns talk about Haskell, Linux, functional and dynamic programming, Conway's Game of Life, and much more.

+ + + +

Follow @thoughtbot, @r00k, @patbrisbin and @mikeburns on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben Orenstein, Pat Brisbin, and Mike Burns talk about Haskell, Linux, functional and dynamic programming, Conway's Game of Life, and much more.

+ + + +

Follow @thoughtbot, @r00k, @patbrisbin and @mikeburns on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8vh6OrEo + + ]]> + + + + 57: Delayed Gratification + https://podcast.thoughtbot.com/57 + f0cc0c63-3b79-4575-961e-2567a6351e15 + Sun, 14 Jul 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode, Ben Orenstein is joined by Michael Klett, Co-founder and tech lead of Chargify. Ben and Michael discuss the evolution of Chargify and bumps along the way, underwear subscriptions, Michael’s transition from hardware to software, negativity in the Rails community, slow tests, and much more. + + + 28:10 + no + + <p>In this episode, Ben Orenstein is joined by Michael Klett, Co-founder and tech lead of Chargify. Ben and Michael discuss the evolution of Chargify and bumps along the way, underwear subscriptions, Michael’s transition from hardware to software, negativity in the Rails community, slow tests, and much more.</p> +<ul> +<li><a href="http://chargify.com/">Chargify</a></li> +<li><a href="http://www.manpacks.com/">Manpacks</a></li> +<li><a href="http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/">Bryan Helmcamp’s blog on 7 ways to refactor</a></li> +<li><a href="http://mitpress.mit.edu/sicp/full-text/book/book.html">Structure and Interpretation of Computer Programs</a></li> +<li><a href="http://stream.rubydaily.org/post/51754385362/railsconf-2013-closing-keynote-by-tenderlove-via">@tenderlove’s keynote at railsconf</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/moklett">@moklett</a> on twitter.</p> + + + + In this episode, Ben Orenstein is joined by Michael Klett, Co-founder and tech lead of Chargify. Ben and Michael discuss the evolution of Chargify and bumps along the way, underwear subscriptions, Michael’s transition from hardware to software, negativity in the Rails community, slow tests, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @moklett on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, Ben Orenstein is joined by Michael Klett, Co-founder and tech lead of Chargify. Ben and Michael discuss the evolution of Chargify and bumps along the way, underwear subscriptions, Michael’s transition from hardware to software, negativity in the Rails community, slow tests, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @moklett on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7mADX-35 + + ]]> + + + + 56: Code in a Bubble Bath + https://podcast.thoughtbot.com/56 + bbb1dcfe-8e42-413f-9610-742903426458 + Sun, 07 Jul 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode Ben Orenstein is joined by Alex MacCaw, creator of Spine, formerly of Twitter, and now a developer at Stripe. Ben and Alex talk about travel, writing, code, and couch surfing. + + + 36:36 + no + + ]<p>In this episode Ben Orenstein is joined by Alex MacCaw, creator of Spine, formerly of Twitter, and now a developer at Stripe. Ben and Alex talk about travel, writing, code, and couch surfing.</p> +<ul> +<li><a href="http://alexmaccaw.com">Alex's Personal Website</a></li> +<li><a href="http://blog.alexmaccaw.com">Alex's Blog</a></li> +<li><a href="http://blog.alexmaccaw.com/how-to-travel-around-the-world-for-a-year">Alex's World Travel Blog Post</a></li> +<li><a href="https://github.com/maccman">Alex's Github</a></li> +<li><a href="http://spinejs.com/">Spine</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/maccaw">@maccaw</a> on twitter.</p> + + + ]

In this episode Ben Orenstein is joined by Alex MacCaw, creator of Spine, formerly of Twitter, and now a developer at Stripe. Ben and Alex talk about travel, writing, code, and couch surfing.

+ + + +

Follow @thoughtbot, @r00k, and @maccaw on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + ]

In this episode Ben Orenstein is joined by Alex MacCaw, creator of Spine, formerly of Twitter, and now a developer at Stripe. Ben and Alex talk about travel, writing, code, and couch surfing.

+ + + +

Follow @thoughtbot, @r00k, and @maccaw on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+LMWIK7Py + + ]]> + + + + 55: The Value of Flow + https://podcast.thoughtbot.com/55 + 9ac1feeb-6c09-40a3-a578-17e93201b013 + Sun, 30 Jun 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode Ben Orenstein speaks with designer and founder of Authentic Jobs, Cameron Moll, about Authentic Jobs, design, the value of flow and family, and much, much more. + + + 42:29 + no + + <p>In this episode Ben Orenstein speaks with designer and founder of Authentic Jobs, Cameron Moll, about Authentic Jobs, design, the value of flow and family, and much, much more.</p> +<ul> +<li><a href="http://www.authenticjobs.com">Authentic Jobs</a></li> +<li><a href="http://cameronmoll.com">Cameron's personal website</a></li> +<li><a href="http://hired.fm">Podcast: Hired</a></li> +<li><a href="http://www.futureinsights.com/home/cameron-moll-keynote-from-future-insights-live-2013-crafting.html">Cameron's Future Insights Live Keynote</a></li> +<li><a href="http://www.amazon.com/Hire-With-Your-Head-Performance-Based/dp/0470128356">Hire with your head – Lou Adler</a></li> +<li><a href="http://www.bloomberg.com/video/ebay-ceo-john-donahoe-on-growth-competition-M5WvDmmKTZuOvq1SJwCOLw.html">Ebay CEO Interview Charlie Rose</a></li> +<li><a href="http://alistapart.com/article/redesignrealign">Good Designers Redesign, Great Designers Realign</a></li> +<li><a href="http://youtu.be/l9JXH7JPjR4?t=40m40s">Rails Conf 2013 How to Talk to Developers by Ben Orenstein</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/cameronmoll">@cameronmoll</a> on twitter.</p> + + + + In this episode Ben Orenstein speaks with designer and founder of Authentic Jobs, Cameron Moll, about Authentic Jobs, design, the value of flow and family, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @cameronmoll on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode Ben Orenstein speaks with designer and founder of Authentic Jobs, Cameron Moll, about Authentic Jobs, design, the value of flow and family, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @cameronmoll on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rWIO8305 + + ]]> + + + + 54: Build your stuff on the side and have a good time + https://podcast.thoughtbot.com/54 + efc2c383-94f6-4f36-8901-4fe46a5a4cd2 + Sun, 23 Jun 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode, Ben Orenstein is joined by 17 year old Jack Kaufman, author of The Found a Business Book. Ben and Jack discuss Jack's inspiration for the book and how he got all his interviews, the other opportunities it's led too, the common themes he uncovered in his interviews, the differences between those who got funding and bootstrappers, working on the book while in highschool, marketing he's doing, his plans for the future, the issue with college computer science programs, his fears about the future, and much more. + + + 25:22 + no + + <p>In this episode, Ben Orenstein is joined by 17 year old Jack Kaufman, author of The Found a Business Book. Ben and Jack discuss Jack's inspiration for the book and how he got all his interviews, the other opportunities it's led too, the common themes he uncovered in his interviews, the differences between those who got funding and bootstrappers, working on the book while in highschool, marketing he's doing, his plans for the future, the issue with college computer science programs, his fears about the future, and much more.</p> +<ul> +<li><a href="http://www.foundabusiness.com/">The Found a Business Book</a></li> +<li><a href="http://mixergy.com/goto/welcome/">mixergy.com</a></li> +<li><a href="http://sideprojectbook.com/">The Side Project Book</a></li> +<li><a href="http://www.forbes.com/sites/ryanmac/2013/06/04/jack-dorseys-five-startup-tips-to-a-17-year-old-entrepreneur/">Jack's guest post for Forbes.com</a></li> +<li><a href="http://www.haverford.edu/">Haverford College</a></li> +<li><a href="http://www.pillsoftware.com/">pillsoftware.com</a></li> +<li><a href="http://ruby.railstutorial.org/">Michael Hartl's Rails Totorial</a></li> +<li><a href="http://learn.thoughtbot.com/prime">Learn Prime</a></li> +<li><a href="http://apprentice.io">apprentice.io</a></li> +<li><a href="http://devbootcamp.com/">Dev Bootcamp</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/kaufman_jack">@kaufman_jack</a> on twitter.</p> + + + + In this episode, Ben Orenstein is joined by 17 year old Jack Kaufman, author of The Found a Business Book. Ben and Jack discuss Jack's inspiration for the book and how he got all his interviews, the other opportunities it's led too, the common themes he uncovered in his interviews, the differences between those who got funding and bootstrappers, working on the book while in highschool, marketing he's doing, his plans for the future, the issue with college computer science programs, his fears about the future, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @kaufman_jack on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, Ben Orenstein is joined by 17 year old Jack Kaufman, author of The Found a Business Book. Ben and Jack discuss Jack's inspiration for the book and how he got all his interviews, the other opportunities it's led too, the common themes he uncovered in his interviews, the differences between those who got funding and bootstrappers, working on the book while in highschool, marketing he's doing, his plans for the future, the issue with college computer science programs, his fears about the future, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @kaufman_jack on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+osM9VgPH + + ]]> + + + + 53: Not everything needs to be extracted + https://podcast.thoughtbot.com/53 + 21441aa2-7383-468a-b5a5-ad31c03ac0ae + Sun, 16 Jun 2013 20:00:00 -0400 + thoughtbot + + full + 2 + thoughtbot + In this episode Ben Orenstein is joined by Yehuda Katz and Tom Dale from Tilde. They discuss bootstrapping a business and the model behind Tilde, their breakdown of product development and consulting, and how they all met. They also talk about designing APIs and frameworks that people actually want to use, how teaching helps them be better framework developers, how they can beat the competition, how supporting multiple languages and frameworks can ruin your app's experience, the big surprises as they've launched, Ember.js' push to 1.0 and beyond, the difference between Ember.js and Backbone.js and why JavaScript matters, and much more. + + + 38:29 + no + + <p>In this episode Ben Orenstein is joined by Yehuda Katz and Tom Dale from Tilde. They discuss bootstrapping a business and the model behind Tilde, their breakdown of product development and consulting, and how they all met. They also talk about designing APIs and frameworks that people actually want to use, how teaching helps them be better framework developers, how they can beat the competition, how supporting multiple languages and frameworks can ruin your app's experience, the big surprises as they've launched, Ember.js' push to 1.0 and beyond, the difference between Ember.js and Backbone.js and why JavaScript matters, and much more.</p> +<ul> +<li><a href="http://tilde.io">Tilde</a></li> +<li><a href="http://Skylight.io">Skylight</a></li> +<li><a href="http://emberjs.com">Ember.js</a></li> +<li><a href="https://github.com/emberjs/data">Ember Data</a></li> +<li><a href="http://www.ehow.com/facts_5581548_concept-ladder_.html">The conceptual ladder</a></li> +<li><a href="http://www.w3.org">W3C</a></li> +<li><a href="http://www.ecma-international.org/memento/TC39.htm">TC39</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/tomdale">@tomdale</a>, and <a href="http://twitter.com/wycats">@wycats</a> on twitter.</p> + + + + In this episode Ben Orenstein is joined by Yehuda Katz and Tom Dale from Tilde. They discuss bootstrapping a business and the model behind Tilde, their breakdown of product development and consulting, and how they all met. They also talk about designing APIs and frameworks that people actually want to use, how teaching helps them be better framework developers, how they can beat the competition, how supporting multiple languages and frameworks can ruin your app's experience, the big surprises as they've launched, Ember.js' push to 1.0 and beyond, the difference between Ember.js and Backbone.js and why JavaScript matters, and much more.

+ + + +

Follow @thoughtbot, @r00k, @tomdale, and @wycats on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode Ben Orenstein is joined by Yehuda Katz and Tom Dale from Tilde. They discuss bootstrapping a business and the model behind Tilde, their breakdown of product development and consulting, and how they all met. They also talk about designing APIs and frameworks that people actually want to use, how teaching helps them be better framework developers, how they can beat the competition, how supporting multiple languages and frameworks can ruin your app's experience, the big surprises as they've launched, Ember.js' push to 1.0 and beyond, the difference between Ember.js and Backbone.js and why JavaScript matters, and much more.

+ + + +

Follow @thoughtbot, @r00k, @tomdale, and @wycats on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+xpoXjHsg + + ]]> + + + + 52: You look really fancy in your tuxedo + https://podcast.thoughtbot.com/52 + 25f5f6e6-121a-4c89-b46d-a7871cab88fd + Sun, 09 Jun 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + In this special episode, number 52, and our 1 year anniversary episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ruby and Rails core team member Aaron Patterson, thoughtbot CTO Joe Ferris, and a live studio audience. The trio discuss Rails 4, observers, callbacks, dubstep, namespaces, Scheme, functional programming, thread safety in Rails, what it would take to remove callbacks from Rails and why you would want to do it, what should be in our anniversary episode, dealing with Rails security issues, why Aaron likes to work on Rails, meeting people's expectations, Vim, intuitive software, and so much more. + + + 58:19 + no + + <p>In this special episode, number 52, and our 1 year anniversary episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ruby and Rails core team member Aaron Patterson, thoughtbot CTO Joe Ferris, and a live studio audience. The trio discuss Rails 4, observers, callbacks, dubstep, namespaces, Scheme, functional programming, thread safety in Rails, what it would take to remove callbacks from Rails and why you would want to do it, what should be in our anniversary episode, dealing with Rails security issues, why Aaron likes to work on Rails, meeting people's expectations, Vim, intuitive software, and so much more.</p> +<ul> +<li><a href="http://www.rubydoc.info/docs/rails/Array:forty_two">Array#forty_two</a></li> +<li><a href="http://www.call-cc.org/">ChickenScheme</a></li> +<li><a href="http://racket-lang.org/">The Racket language</a></li> +<li><a href="http://mitpress.mit.edu/sicp/">Structure and Interpretation of Computer Programs (SICP)</a></li> +<li><a href="http://stackoverflow.com/questions/1481053/what-is-the-exact-definition-of-a-metacircular-interpreter">Metacircular interpreter</a></li> +<li><a href="https://peepcode.com/products/play-by-play-tenderlove-ruby-on-rails">Play by Play: Aaron Patterson</a></li> +<li><a href="https://github.com/tpope/heroku-fucking-console">Heroku fucking console</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/tenderlove">@tenderlove</a>, and <a href="http://twitter.com/joeferris">@joeferris</a> on twitter.</p> + + + + In this special episode, number 52, and our 1 year anniversary episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ruby and Rails core team member Aaron Patterson, thoughtbot CTO Joe Ferris, and a live studio audience. The trio discuss Rails 4, observers, callbacks, dubstep, namespaces, Scheme, functional programming, thread safety in Rails, what it would take to remove callbacks from Rails and why you would want to do it, what should be in our anniversary episode, dealing with Rails security issues, why Aaron likes to work on Rails, meeting people's expectations, Vim, intuitive software, and so much more.

+ + + +

Follow @thoughtbot, @r00k, @tenderlove, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this special episode, number 52, and our 1 year anniversary episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ruby and Rails core team member Aaron Patterson, thoughtbot CTO Joe Ferris, and a live studio audience. The trio discuss Rails 4, observers, callbacks, dubstep, namespaces, Scheme, functional programming, thread safety in Rails, what it would take to remove callbacks from Rails and why you would want to do it, what should be in our anniversary episode, dealing with Rails security issues, why Aaron likes to work on Rails, meeting people's expectations, Vim, intuitive software, and so much more.

+ + + +

Follow @thoughtbot, @r00k, @tenderlove, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dqaye0Ew + + ]]> + + + + 51: I found a voice + https://podcast.thoughtbot.com/51 + 7daa88cb-536c-4f73-a29c-466b00a926db + Sun, 02 Jun 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + On this week's show, recorded at RailsConf 2013, Ben Orenstein is joined by Sandi Metz, developer, author, podcaster, and recent Ruby Hero award winner. Ben and Sandi discuss winning awards, writing, whether notoriety changes who you are, what Sandi is proud of, the bad code she's writing and why, what she's doing now, getting real feedback on your work, that it's OK not to know everything, and much, much more. + + + 32:50 + no + + <p>On this week's show, recorded at RailsConf 2013, Ben Orenstein is joined by Sandi Metz, developer, author, podcaster, and recent Ruby Hero award winner. Ben and Sandi discuss winning awards, writing, whether notoriety changes who you are, what Sandi is proud of, the bad code she's writing and why, what she's doing now, getting real feedback on your work, that it's OK not to know everything, and much, much more.</p> +<ul> +<li><a href="http://www.poodr.info/">Practical Object-Oriented Design in Ruby</a></li> +<li><a href="http://www.youtube.com/watch?v=URSWYvyc42M">Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz</a></li> +<li><a href="http://lanyrd.com/">Lanyrd</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/sandimetz">@sandimetz</a> on twitter.</p> + + + + On this week's show, recorded at RailsConf 2013, Ben Orenstein is joined by Sandi Metz, developer, author, podcaster, and recent Ruby Hero award winner. Ben and Sandi discuss winning awards, writing, whether notoriety changes who you are, what Sandi is proud of, the bad code she's writing and why, what she's doing now, getting real feedback on your work, that it's OK not to know everything, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @sandimetz on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + On this week's show, recorded at RailsConf 2013, Ben Orenstein is joined by Sandi Metz, developer, author, podcaster, and recent Ruby Hero award winner. Ben and Sandi discuss winning awards, writing, whether notoriety changes who you are, what Sandi is proud of, the bad code she's writing and why, what she's doing now, getting real feedback on your work, that it's OK not to know everything, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @sandimetz on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bXYNytkS + + ]]> + + + + 50: It's Monday today, let's change everything + https://podcast.thoughtbot.com/50 + fb37d023-8610-4a55-a288-3f1b0a95427e + Sun, 26 May 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + In this week's episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jeff Casimir and Katrina Owen from Jumpstart Lab and gSchool to discuss performing, speaking, and imposter syndrome, preparing for your talk, and what makes a good talk and how to give one. The also discuss gSchool, the way the program works and they way it's guaranteed, teaching, admitting ignorance, how good practice should be harder than the real thing, and why Jeff didn't like studying Computer Science and why he didn't enjoy programming and how Rails reignited his passion for creating things, and much more. + + + 43:26 + no + + <p>In this week's episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jeff Casimir and Katrina Owen from Jumpstart Lab and gSchool to discuss performing, speaking, and imposter syndrome, preparing for your talk, and what makes a good talk and how to give one. The also discuss gSchool, the way the program works and they way it's guaranteed, teaching, admitting ignorance, how good practice should be harder than the real thing, and why Jeff didn't like studying Computer Science and why he didn't enjoy programming and how Rails reignited his passion for creating things, and much more.</p> +<ul> +<li><a href="https://peepcode.com/">Peepcode</a></li> +<li><a href="http://gschool.it">gSchool</a></li> +<li><a href="http://jumpstartlab.com/">Jumpstart Lab</a></li> +<li><a href="http://www.codecademy.com/">Code Academy</a></li> +<li><a href="http://galvanize.it/">galvanize</a></li> +<li><a href="http://golang.org/">Go</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/j3">@j3</a> and <a href="http://twitter.com/kytrinyx">@kytrinyx</a> on twitter.</p> + + + + In this week's episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jeff Casimir and Katrina Owen from Jumpstart Lab and gSchool to discuss performing, speaking, and imposter syndrome, preparing for your talk, and what makes a good talk and how to give one. The also discuss gSchool, the way the program works and they way it's guaranteed, teaching, admitting ignorance, how good practice should be harder than the real thing, and why Jeff didn't like studying Computer Science and why he didn't enjoy programming and how Rails reignited his passion for creating things, and much more.

+ + + +

Follow @thoughtbot, @r00k, @j3 and @kytrinyx on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this week's episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jeff Casimir and Katrina Owen from Jumpstart Lab and gSchool to discuss performing, speaking, and imposter syndrome, preparing for your talk, and what makes a good talk and how to give one. The also discuss gSchool, the way the program works and they way it's guaranteed, teaching, admitting ignorance, how good practice should be harder than the real thing, and why Jeff didn't like studying Computer Science and why he didn't enjoy programming and how Rails reignited his passion for creating things, and much more.

+ + + +

Follow @thoughtbot, @r00k, @j3 and @kytrinyx on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+NWiW8kLW + + ]]> + + + + 49: The psychology of work + https://podcast.thoughtbot.com/49 + b707cd08-941f-4219-8ce3-775b334ad2ed + Sun, 19 May 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Gregg Pollack and Nathaniel Bibler from EnvyLabs and codeschool.com. Gregg shares what he's learned running his business, when not to be transparent, how to deal with compensation, and how the EnvyLabs compensation structure has changed over the years. Nathan, Gregg, and Ben also discuss Code School, yearly payments to a subscription, making courses effective, effective marketing, the effectiveness of mailing lists, community events, shared ownership, and much more. + + + 35:46 + no + + <p>In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Gregg Pollack and Nathaniel Bibler from EnvyLabs and codeschool.com. Gregg shares what he's learned running his business, when not to be transparent, how to deal with compensation, and how the EnvyLabs compensation structure has changed over the years. Nathan, Gregg, and Ben also discuss Code School, yearly payments to a subscription, making courses effective, effective marketing, the effectiveness of mailing lists, community events, shared ownership, and much more.</p> +<ul> +<li><a href="http://www.codeschool.com/">Code School</a></li> +<li><a href="http://workshops.railsbridge.org/">RailsBridge</a></li> +<li><a href="http://barcamporlando.org/">Barcamp Orlando</a></li> +<li><a href="http://ruby5.envylabs.com/">Ruby5 podcast</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/greggpollack">@greggpollack</a> and <a href="http://twitter.com/nbibler">@nbibler</a> on twitter.</p> + + + + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Gregg Pollack and Nathaniel Bibler from EnvyLabs and codeschool.com. Gregg shares what he's learned running his business, when not to be transparent, how to deal with compensation, and how the EnvyLabs compensation structure has changed over the years. Nathan, Gregg, and Ben also discuss Code School, yearly payments to a subscription, making courses effective, effective marketing, the effectiveness of mailing lists, community events, shared ownership, and much more.

+ + + +

Follow @thoughtbot, @r00k, @greggpollack and @nbibler on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Gregg Pollack and Nathaniel Bibler from EnvyLabs and codeschool.com. Gregg shares what he's learned running his business, when not to be transparent, how to deal with compensation, and how the EnvyLabs compensation structure has changed over the years. Nathan, Gregg, and Ben also discuss Code School, yearly payments to a subscription, making courses effective, effective marketing, the effectiveness of mailing lists, community events, shared ownership, and much more.

+ + + +

Follow @thoughtbot, @r00k, @greggpollack and @nbibler on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+wp0dBJvR + + ]]> + + + + 48: Barista imposter syndrome + https://podcast.thoughtbot.com/48 + 87297e19-7b84-42da-9f03-8e3b39bca4ef + Sun, 12 May 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jon Larkowski, closet hippie and developer at CareZone. Ben and Jon discuss being a closet hippie, transitioning from consulting to working on a startup/product team, ping-pong, paying attention to your habits and improving to your life, meditation, firewalling your attention, fostering a startup culture, imposter syndrome, podcasting, coffee, code review, guitar, and much more. + + + 37:44 + no + + <p>In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jon Larkowski, closet hippie and developer at CareZone. Ben and Jon discuss being a closet hippie, transitioning from consulting to working on a startup/product team, ping-pong, paying attention to your habits and improving to your life, meditation, firewalling your attention, fostering a startup culture, imposter syndrome, podcasting, coffee, code review, guitar, and much more.</p> +<ul> +<li><a href="http://www.e3live.com/">e3 live algae</a></li> +<li><a href="http://carezone.com">CareZone</a></li> +<li><a href="http://lift.do">Lift</a></li> +<li><a href="http://www.getsomeheadspace.com/shop/headspace-meditation-app.aspx">Headspace</a></li> +<li><a href="http://vimeo.com/3462301">The Way I Getting Things Done by Jon Larkowski</a></li> +<li><a href="http://ruby5.envylabs.com/">Ruby5 podcast</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/l4rk">@l4rk</a> on twitter.</p> + + + + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jon Larkowski, closet hippie and developer at CareZone. Ben and Jon discuss being a closet hippie, transitioning from consulting to working on a startup/product team, ping-pong, paying attention to your habits and improving to your life, meditation, firewalling your attention, fostering a startup culture, imposter syndrome, podcasting, coffee, code review, guitar, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @l4rk on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jon Larkowski, closet hippie and developer at CareZone. Ben and Jon discuss being a closet hippie, transitioning from consulting to working on a startup/product team, ping-pong, paying attention to your habits and improving to your life, meditation, firewalling your attention, fostering a startup culture, imposter syndrome, podcasting, coffee, code review, guitar, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @l4rk on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+heGr4d3u + + ]]> + + + + 47: Two hours per minute + https://podcast.thoughtbot.com/47 + 01b94069-9194-4b9e-aa9f-0998bab60a44 + Sun, 05 May 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ryan Bates of RailsCasts. Ben and Ryan discuss Ryan's transition to working on RailsCasts full time, staying up to date on the latest technology, how his coding style has changed, maintaining his open source, the process of producing RailsCasts, why he doesn't speak at conferences, the latest technology he is excited about, and much more + + + 20:53 + no + + <p>In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ryan Bates of RailsCasts. Ben and Ryan discuss Ryan's transition to working on RailsCasts full time, staying up to date on the latest technology, how his coding style has changed, maintaining his open source, the process of producing RailsCasts, why he doesn't speak at conferences, the latest technology he is excited about, and much more</p> +<ul> +<li><a href="http://railscasts.com/">RailsCasts</a></li> +<li><a href="http://rubyweekly.com/">Ruby Weekly</a></li> +<li><a href="http://angularjs.org/">Angular.js</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/rbates">@rbates</a> on twitter.</p> + + + + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ryan Bates of RailsCasts. Ben and Ryan discuss Ryan's transition to working on RailsCasts full time, staying up to date on the latest technology, how his coding style has changed, maintaining his open source, the process of producing RailsCasts, why he doesn't speak at conferences, the latest technology he is excited about, and much more

+ + + +

Follow @thoughtbot, @r00k, and @rbates on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Ryan Bates of RailsCasts. Ben and Ryan discuss Ryan's transition to working on RailsCasts full time, staying up to date on the latest technology, how his coding style has changed, maintaining his open source, the process of producing RailsCasts, why he doesn't speak at conferences, the latest technology he is excited about, and much more

+ + + +

Follow @thoughtbot, @r00k, and @rbates on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rkMWh9_S + + ]]> + + + + 46: We don't have a monopoly on being unhealthy + https://podcast.thoughtbot.com/46 + 7150bec9-3143-4bc0-9220-f6636f630452 + Sun, 28 Apr 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Joe Kutner, programmer and author of ‘The Healthy Programmer’. Ben and Joe discuss how the demands of a development job lead to unhealthy habits, and ways to address the issues. They discuss specifics like standing desks, walking desks, the pomodoro technique, exercise, vitamin D, and much more. + + + 33:43 + no + + <p>Ben Orenstein is joined by Joe Kutner, programmer and author of ‘The Healthy Programmer’. Ben and Joe discuss how the demands of a development job lead to unhealthy habits, and ways to address the issues. They discuss specifics like standing desks, walking desks, the pomodoro technique, exercise, vitamin D, and much more.</p> +<ul> +<li><a href="http://pragprog.com/book/jkthp/the-healthy-programmer">The Healthy Programmer</a></li> +<li><a href="http://en.wikipedia.org/wiki/Pomodoro_Technique">The pomodoro technique</a></li> +<li><a href="http://www.amazon.com/Starting-Strength-3rd-Mark-Rippetoe/dp/0982522738">Starting Stength</a></li> +<li><a href="http://www.amazon.com/Power-Habit-What-Life-Business/dp/1400069289">The Power of Habit: Why We Do What We Do in Life and Business</a></li> +<li><a href="http://www.youtube.com/watch?v=Z0WcQ749OIM">Big Ruby 2013 Build a Bigger Brain: How Healthy Living Makes You Smarter</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/codefinger">@codefinger</a> on twitter.</p> + + + + Ben Orenstein is joined by Joe Kutner, programmer and author of ‘The Healthy Programmer’. Ben and Joe discuss how the demands of a development job lead to unhealthy habits, and ways to address the issues. They discuss specifics like standing desks, walking desks, the pomodoro technique, exercise, vitamin D, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @codefinger on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Joe Kutner, programmer and author of ‘The Healthy Programmer’. Ben and Joe discuss how the demands of a development job lead to unhealthy habits, and ways to address the issues. They discuss specifics like standing desks, walking desks, the pomodoro technique, exercise, vitamin D, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @codefinger on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+6zLd_wJt + + ]]> + + + + 45: Tiny Robots Cuddling with other Tiny Robots + https://podcast.thoughtbot.com/45 + bbe0ec98-6d6f-46da-a61f-51f00a6cb3cc + Sun, 21 Apr 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + This week we try something a little different. Joe Ferris, Matt Jankowski, Ben Orenstein, and Chad Pytel get together and have a little fun, in what we're calling "Tiny Robots cuddling with other Tiny Robots". We'd love to get your thoughts on this special format, tweet us @thoughtbot or email learn@thoughtbot.com. + + + 34:56 + no + + <p>This week we try something a little different. Joe Ferris, Matt Jankowski, Ben Orenstein, and Chad Pytel get together and have a little fun, in what we're calling &quot;Tiny Robots cuddling with other Tiny Robots&quot;. We'd love to get your thoughts on this special format, tweet us @thoughtbot or email learn@thoughtbot.com.</p> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/joeferris">@joeferris</a>, <a href="http://twitter.com/jankowski">@jankowski</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/cpytel">@cpytel</a> on twitter.</p> + + + + This week we try something a little different. Joe Ferris, Matt Jankowski, Ben Orenstein, and Chad Pytel get together and have a little fun, in what we're calling "Tiny Robots cuddling with other Tiny Robots". We'd love to get your thoughts on this special format, tweet us @thoughtbot or email learn@thoughtbot.com.

+ +

Follow @thoughtbot, @joeferris, @jankowski, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week we try something a little different. Joe Ferris, Matt Jankowski, Ben Orenstein, and Chad Pytel get together and have a little fun, in what we're calling "Tiny Robots cuddling with other Tiny Robots". We'd love to get your thoughts on this special format, tweet us @thoughtbot or email learn@thoughtbot.com.

+ +

Follow @thoughtbot, @joeferris, @jankowski, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+q00uVSLK + + ]]> + + + + 44: I feel the opposite of burnt out + https://podcast.thoughtbot.com/44 + 9c6a1abd-12fb-4c85-84bf-84e3dff5eef5 + Sun, 14 Apr 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + In this week's podcast, Ben Orenstein is joined by Chad Fowler, author, speaker, and CTO of 6wunderkinder. Ben and Chad discuss Chad's recent move to Berlin and 6wunderkinder, what a CTO does, getting back to coding, the early Ruby community, who Chad wants to hire, predicting success of new hires, and what makes a truly good developer, favorite interview questions, how Chad's interviewing process has changed over time, how age and experience can change your perspective, how Chad built a great team, and what he might write about in the future. They also discuss Chad's new tattoo, his regrets, meditation, therapy, gaining control over your mind, and much, much more. + + + 52:52 + no + + <p>In this week's podcast, Ben Orenstein is joined by Chad Fowler, author, speaker, and CTO of 6wunderkinder. Ben and Chad discuss Chad's recent move to Berlin and 6wunderkinder, what a CTO does, getting back to coding, the early Ruby community, who Chad wants to hire, predicting success of new hires, and what makes a truly good developer, favorite interview questions, how Chad's interviewing process has changed over time, how age and experience can change your perspective, how Chad built a great team, and what he might write about in the future. They also discuss Chad's new tattoo, his regrets, meditation, therapy, gaining control over your mind, and much, much more.</p> +<ul> +<li><a href="http://www.6wunderkinder.com/wunderlist">Wunderlist</a></li> +<li><a href="http://dablog.rubypal.com/">David A. Black</a></li> +<li><a href="https://twitter.com/rich_kilmer">Rich Kilmer</a></li> +<li><a href="http://pragdave.pragprog.com/">Dave Thomas</a></li> +<li><a href="http://www.hilarymason.com/speaking/speaking-entertain-dont-teach/">Hilary Mason, Speaking: Entertain, Don’t Teach</a></li> +<li><a href="http://en.wikipedia.org/wiki/Befunge">Befunge</a></li> +<li><a href="http://www.dangermouse.net/esoteric/ook.html">Ook! a programming language designed for orangutans</a></li> +<li><a href="http://techcrunch.com/2011/03/14/livingsocial-gains-wealth-of-ruby-on-rails-expertise-with-infoether-acquisition/">LivingSocial Gains Wealth Of Ruby on Rails Expertise With InfoEther Acquisition</a></li> +<li><a href="http://benscofield.com/">Ben Scofield</a></li> +<li><a href="https://twitter.com/evanphx">Evan Pheonix</a></li> +<li><a href="http://www.amazon.com/Passionate-Programmer-Remarkable-Development-Pragmatic/dp/1934356344">The Passionate Programmer: Creating a Remarkable Career in Software Development</a></li> +<li><a href="http://www.amazon.com/Job-Went-India-Pragmatic-Programmers/dp/0976694018">My Job Went to India: 52 Ways to Save Your Job</a></li> +<li><a href="http://martinfowler.com/">Martin Fowler</a></li> +<li><a href="http://clojure.org/">Clojure</a></li> +<li><a href="http://www.scala-lang.org/">Scala</a></li> +<li><a href="http://www.ted.com/talks/amy_cuddy_your_body_language_shapes_who_you_are.html">Amy Cuddy: Your body language shapes who you are (Power Posing)</a></li> +<li><a href="https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-prn1/904042_10151635010996111_161323981_o.jpg">Railsberry Power Posing!</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/chadfowler">@chadfowler</a> on twitter.</p> + + + + In this week's podcast, Ben Orenstein is joined by Chad Fowler, author, speaker, and CTO of 6wunderkinder. Ben and Chad discuss Chad's recent move to Berlin and 6wunderkinder, what a CTO does, getting back to coding, the early Ruby community, who Chad wants to hire, predicting success of new hires, and what makes a truly good developer, favorite interview questions, how Chad's interviewing process has changed over time, how age and experience can change your perspective, how Chad built a great team, and what he might write about in the future. They also discuss Chad's new tattoo, his regrets, meditation, therapy, gaining control over your mind, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @chadfowler on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this week's podcast, Ben Orenstein is joined by Chad Fowler, author, speaker, and CTO of 6wunderkinder. Ben and Chad discuss Chad's recent move to Berlin and 6wunderkinder, what a CTO does, getting back to coding, the early Ruby community, who Chad wants to hire, predicting success of new hires, and what makes a truly good developer, favorite interview questions, how Chad's interviewing process has changed over time, how age and experience can change your perspective, how Chad built a great team, and what he might write about in the future. They also discuss Chad's new tattoo, his regrets, meditation, therapy, gaining control over your mind, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @chadfowler on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+9H-RAwoP + + ]]> + + + + 43: A good person by default + https://podcast.thoughtbot.com/43 + 00809bc5-1f97-401d-99fd-eb722ce54537 + Sun, 07 Apr 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + thoughtbot's Ben Orenstein is joined by Scott Orn, venture capitalist at Lighthouse Capital Partners by day, and co-founder of Ben's Friends by night. Ben and Scott discuss building a community, the future of Ben's Friends, and how running the site helps him be a better VC, teaching people, and getting value out of giving back. They also talk about his work as a venture capitalist at Lighthouse, how the money flows, the freemium software model, why it's good and how it works, picking the winners, and how the market can affect success, and the companies Scott thinks are great investments, and where he thinks the market is going. + + + 44:16 + no + + <p>thoughtbot's Ben Orenstein is joined by Scott Orn, venture capitalist at Lighthouse Capital Partners by day, and co-founder of Ben's Friends by night. Ben and Scott discuss building a community, the future of Ben's Friends, and how running the site helps him be a better VC, teaching people, and getting value out of giving back. They also talk about his work as a venture capitalist at Lighthouse, how the money flows, the freemium software model, why it's good and how it works, picking the winners, and how the market can affect success, and the companies Scott thinks are great investments, and where he thinks the market is going.</p> +<ul> +<li><a href="http://www.bensfriends.org/">Ben's Friends</a></li> +<li><a href="http://railsrumble.com/">Rails Rumble</a></li> +<li><a href="http://www.jonathancoulton.com/2009/03/24/payday/">Jonathan Coulton's blog post, 'Payday'</a></li> +<li><a href="http://www.lcpartners.com/">Lighthouse Capital Partners</a></li> +<li><a href="https://www.boundless.com/">Boundless</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/scottorn">@scottorn</a> on twitter.</p> + + + + thoughtbot's Ben Orenstein is joined by Scott Orn, venture capitalist at Lighthouse Capital Partners by day, and co-founder of Ben's Friends by night. Ben and Scott discuss building a community, the future of Ben's Friends, and how running the site helps him be a better VC, teaching people, and getting value out of giving back. They also talk about his work as a venture capitalist at Lighthouse, how the money flows, the freemium software model, why it's good and how it works, picking the winners, and how the market can affect success, and the companies Scott thinks are great investments, and where he thinks the market is going.

+ + + +

Follow @thoughtbot, @r00k, and @scottorn on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + thoughtbot's Ben Orenstein is joined by Scott Orn, venture capitalist at Lighthouse Capital Partners by day, and co-founder of Ben's Friends by night. Ben and Scott discuss building a community, the future of Ben's Friends, and how running the site helps him be a better VC, teaching people, and getting value out of giving back. They also talk about his work as a venture capitalist at Lighthouse, how the money flows, the freemium software model, why it's good and how it works, picking the winners, and how the market can affect success, and the companies Scott thinks are great investments, and where he thinks the market is going.

+ + + +

Follow @thoughtbot, @r00k, and @scottorn on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+VOv3sGNd + + ]]> + + + + 42: Why were you suing a website? + https://podcast.thoughtbot.com/42 + ffc46b6d-99f1-48d6-a6d9-8dd74d08a0b8 + Sun, 31 Mar 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + This week, Ben Orenstein is joined by Peter Moldave, attorney at Gesmer Updegrove to discuss attorney client privilege, what not to do with email, the similarities between lawyers and programmers, how he got into law, his history with technology, and his time as a corporate lawyer at Apple. They also dig into how EULAs work, whether they are binding, whether you should be reading them, and how they can be enforced, software licensing, copyrights and the First-sale doctrine, patent law, software patents, and navigating the patent landscape. They also discuss how to view stock options in your startup job offer, working at startups, how to have a valuable career path, what your employer owns from your side projects or your work for them, how to manage liability in your startup, web site, app on the App Store, and side projects, the best corporate structure and much, much more. + + + 50:21 + no + + <p>This week, Ben Orenstein is joined by Peter Moldave, attorney at Gesmer Updegrove to discuss attorney client privilege, what not to do with email, the similarities between lawyers and programmers, how he got into law, his history with technology, and his time as a corporate lawyer at Apple. They also dig into how EULAs work, whether they are binding, whether you should be reading them, and how they can be enforced, software licensing, copyrights and the First-sale doctrine, patent law, software patents, and navigating the patent landscape. They also discuss how to view stock options in your startup job offer, working at startups, how to have a valuable career path, what your employer owns from your side projects or your work for them, how to manage liability in your startup, web site, app on the App Store, and side projects, the best corporate structure and much, much more.</p> +<ul> +<li><a href="http://en.wikipedia.org/wiki/First-sale_doctrine">First-sale doctrine</a></li> +<li><a href="http://www.gschool.it/">gSchool</a></li> +<li><a href="http://www.contractstandards.com/document-checklists/inventions-assignment-agreement-analysis/assignment-of-inventions">Assignment of Inventions</a></li> +<li><a href="http://en.wikipedia.org/wiki/Limited_liability_company">Limited Liability Company</a></li> +<li><a href="http://www.apple.com/legal/itunes/appstore/dev/stdeula/">The default iOS app store license</a></li> +<li><a href="http://www.gesmer.com/home.php">Gesmer Updegrove, LLP</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/petermoldave">@petermoldave</a> on twitter.</p> + + + + This week, Ben Orenstein is joined by Peter Moldave, attorney at Gesmer Updegrove to discuss attorney client privilege, what not to do with email, the similarities between lawyers and programmers, how he got into law, his history with technology, and his time as a corporate lawyer at Apple. They also dig into how EULAs work, whether they are binding, whether you should be reading them, and how they can be enforced, software licensing, copyrights and the First-sale doctrine, patent law, software patents, and navigating the patent landscape. They also discuss how to view stock options in your startup job offer, working at startups, how to have a valuable career path, what your employer owns from your side projects or your work for them, how to manage liability in your startup, web site, app on the App Store, and side projects, the best corporate structure and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @petermoldave on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week, Ben Orenstein is joined by Peter Moldave, attorney at Gesmer Updegrove to discuss attorney client privilege, what not to do with email, the similarities between lawyers and programmers, how he got into law, his history with technology, and his time as a corporate lawyer at Apple. They also dig into how EULAs work, whether they are binding, whether you should be reading them, and how they can be enforced, software licensing, copyrights and the First-sale doctrine, patent law, software patents, and navigating the patent landscape. They also discuss how to view stock options in your startup job offer, working at startups, how to have a valuable career path, what your employer owns from your side projects or your work for them, how to manage liability in your startup, web site, app on the App Store, and side projects, the best corporate structure and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @petermoldave on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mp4T3RTt + + ]]> + + + + 41: This is the sausage being made + https://podcast.thoughtbot.com/41 + 004881c5-fc4d-46ae-8936-9b59266f9208 + Sun, 24 Mar 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + This week Ben Orenstein in joined by thoughtbot CEO, Chad Pytel, to discuss thoughbot's books, online and in-person training programs, other educational products, and the launch of thoughtbot's new subscription to everything they teach, Learn Prime. They also discuss some changes to apprentice.io, Five Guys, and much more! + + + 35:47 + no + + <p>This week Ben Orenstein in joined by thoughtbot CEO, Chad Pytel, to discuss thoughbot's books, online and in-person training programs, other educational products, and the launch of thoughtbot's new subscription to everything they teach, Learn Prime. They also discuss some changes to apprentice.io, Five Guys, and much more!</p> +<ul> +<li><a href="https://learn.thoughtbot.com/products/13-ruby-science">Ruby Science</a></li> +<li><a href="https://learn.thoughtbot.com/products/1-backbone-js-on-rails">Backbone.js on Rails</a></li> +<li><a href="https://learn.thoughtbot.com/workshops/21-intermediate-ruby-on-rails">Intermediate Ruby on Rails</a></li> +<li><a href="https://learn.thoughtbot.com/workshops/20-intro-to-ruby-on-rails">Intro to Ruby on Rails</a></li> +<li><a href="https://learn.thoughtbot.com/products/14-prime">Learn Prime</a></li> +<li><a href="http://apprentice.io">apprentice.io</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/cpytel">@cpytel</a> on twitter.</p> + + + + This week Ben Orenstein in joined by thoughtbot CEO, Chad Pytel, to discuss thoughbot's books, online and in-person training programs, other educational products, and the launch of thoughtbot's new subscription to everything they teach, Learn Prime. They also discuss some changes to apprentice.io, Five Guys, and much more!

+ + + +

Follow @thoughtbot, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben Orenstein in joined by thoughtbot CEO, Chad Pytel, to discuss thoughbot's books, online and in-person training programs, other educational products, and the launch of thoughtbot's new subscription to everything they teach, Learn Prime. They also discuss some changes to apprentice.io, Five Guys, and much more!

+ + + +

Follow @thoughtbot, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+HpW77Z3s + + ]]> + + + + 40: He's winking at me + https://podcast.thoughtbot.com/40 + b804f866-da69-407c-a2bc-bd2c50ed19db + Sun, 17 Mar 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben is joined by Bryan Helmkamp, the founder of CodeClimate. In Bryan's second appearance on the podcast, Ben and Bryan discuss the architecture behind CodeClimate, scaling the service, and growing the business. They also discuss speaking at conferences, proposal selection, two factor authentication and adding it to CodeClimate, marketing and content marketing, how to decide what to build and proving that it was worthwhile, strategies for testing at the beginning when you have few users, and Bryan reveals CodeClimate next big upcoming feature. + + + 32:17 + no + + <p>Ben is joined by Bryan Helmkamp, the founder of CodeClimate. In Bryan's second appearance on the podcast, Ben and Bryan discuss the architecture behind CodeClimate, scaling the service, and growing the business. They also discuss speaking at conferences, proposal selection, two factor authentication and adding it to CodeClimate, marketing and content marketing, how to decide what to build and proving that it was worthwhile, strategies for testing at the beginning when you have few users, and Bryan reveals CodeClimate next big upcoming feature.</p> +<ul> +<li><a href="https://github.com/mperham/sidekiq">Sidekiq</a></li> +<li><a href="http://jruby.org/">JRuby</a></li> +<li><a href="http://rubini.us/">Rubinius</a></li> +<li><a href="http://en.wikipedia.org/wiki/Just-in-time_compilation">Just-in-time (JIT) compilation</a></li> +<li><a href="https://metrics.librato.com/">Librato metrics</a></li> +<li><a href="https://codeclimate.com/security-monitor">Rails Security Monitor by Code Climate</a></li> +<li><a href="http://bostonrb.org/presentations/rails-application-security-in-practice">Boston.rb, Rails Application Security in Practice</a>_</li> +<li><a href="http://railssecurity.com/">railssecurity.com</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/brynary">@brynary</a> on twitter.</p> + + + + Ben is joined by Bryan Helmkamp, the founder of CodeClimate. In Bryan's second appearance on the podcast, Ben and Bryan discuss the architecture behind CodeClimate, scaling the service, and growing the business. They also discuss speaking at conferences, proposal selection, two factor authentication and adding it to CodeClimate, marketing and content marketing, how to decide what to build and proving that it was worthwhile, strategies for testing at the beginning when you have few users, and Bryan reveals CodeClimate next big upcoming feature.

+ + + +

Follow @thoughtbot, @r00k, and @brynary on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben is joined by Bryan Helmkamp, the founder of CodeClimate. In Bryan's second appearance on the podcast, Ben and Bryan discuss the architecture behind CodeClimate, scaling the service, and growing the business. They also discuss speaking at conferences, proposal selection, two factor authentication and adding it to CodeClimate, marketing and content marketing, how to decide what to build and proving that it was worthwhile, strategies for testing at the beginning when you have few users, and Bryan reveals CodeClimate next big upcoming feature.

+ + + +

Follow @thoughtbot, @r00k, and @brynary on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+BSmEZWwd + + ]]> + + + + 39: We've been watching you for some time, Mr. Grimm + https://podcast.thoughtbot.com/39 + 22366d6b-2f83-4d6b-9159-f2a3501a5d13 + Sun, 10 Mar 2013 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Avdi Grimm, software developer, author, and podcaster. Ben and Avdi discuss Emacs, Avdi's personal assistant and delegating work. They also discuss naming and finding implicit concepts in your code, encoding processes as objects in their own right, his publishing and podcasting, the pronunciation of Parley, Ruby Tapas, education resources and the benefits of open source languages, his goals, the most civilized way to travel, and what we got wrong about the Law of Demeter. + + + 38:44 + no + + <p>Ben Orenstein is joined by Avdi Grimm, software developer, author, and podcaster. Ben and Avdi discuss Emacs, Avdi's personal assistant and delegating work. They also discuss naming and finding implicit concepts in your code, encoding processes as objects in their own right, his publishing and podcasting, the pronunciation of Parley, Ruby Tapas, education resources and the benefits of open source languages, his goals, the most civilized way to travel, and what we got wrong about the Law of Demeter.</p> +<ul> +<li><a href="http://www.rubyrep.com">Mandy Moore, Assistance for Software Professionals</a></li> +<li><a href="http://www.rubytapas.com">Ruby Tapas</a></li> +<li><a href="http://c2.com/cgi/wiki?MethodObject">MethodObject</a></li> +<li><a href="http://objectsonrails.com">Objects on Rails</a></li> +<li><a href="http://exceptionalruby.com/">Exceptional Ruby</a></li> +<li><a href="http://devblog.avdi.org/2012/06/05/confident-ruby-beta/">Confident Ruby</a></li> +<li><a href="http://rubyrogues.com">Ruby Rogues podcast</a></li> +<li><a href="http://www.wideteams.com">Wide Teams</a></li> +<li><a href="https://parley.rubyrogues.com/">Ruby Rogues Parley</a></li> +<li><a href="http://learn.thoughtbot.com/podcast/27">GRSIOGR podcast on Law of Demeter, Episode 27: Fabulous new mistakes</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/avdi">@avdi</a> on twitter.</p> + + + + Ben Orenstein is joined by Avdi Grimm, software developer, author, and podcaster. Ben and Avdi discuss Emacs, Avdi's personal assistant and delegating work. They also discuss naming and finding implicit concepts in your code, encoding processes as objects in their own right, his publishing and podcasting, the pronunciation of Parley, Ruby Tapas, education resources and the benefits of open source languages, his goals, the most civilized way to travel, and what we got wrong about the Law of Demeter.

+ + + +

Follow @thoughtbot, @r00k, and @avdi on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Avdi Grimm, software developer, author, and podcaster. Ben and Avdi discuss Emacs, Avdi's personal assistant and delegating work. They also discuss naming and finding implicit concepts in your code, encoding processes as objects in their own right, his publishing and podcasting, the pronunciation of Parley, Ruby Tapas, education resources and the benefits of open source languages, his goals, the most civilized way to travel, and what we got wrong about the Law of Demeter.

+ + + +

Follow @thoughtbot, @r00k, and @avdi on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+z9GTIKUW + + ]]> + + + + 38: Standing out from the pack + https://podcast.thoughtbot.com/38 + 9865a24a-d912-4e6e-bafe-0ff462af8fcb + Sun, 03 Mar 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + This week Ben Orenstein is joined by Jeremy McAnally, employee at GitHub, author of Ruby in Practice, Rails 3 Upgrade Handbook, MacRuby in Action, and more. Jeremy and Ben discuss teaching and organizing conferences, remote working for GitHub, the and the company summits, GitHub workflows, their internal tools team. They also talk about standing out from the pack in work, life, and getting accepted to conferences, selecting people to speak at conferences, self-publishing, Jeremy's writing process and future writing plans, work-life balance, how to get a job at GitHub, and much more. + + + 37:13 + no + + <p>This week Ben Orenstein is joined by Jeremy McAnally, employee at GitHub, author of Ruby in Practice, Rails 3 Upgrade Handbook, MacRuby in Action, and more. Jeremy and Ben discuss teaching and organizing conferences, remote working for GitHub, the and the company summits, GitHub workflows, their internal tools team. They also talk about standing out from the pack in work, life, and getting accepted to conferences, selecting people to speak at conferences, self-publishing, Jeremy's writing process and future writing plans, work-life balance, how to get a job at GitHub, and much more.</p> +<ul> +<li><a href="http://magic-ruby.com">MagicRuby</a></li> +<li><a href="http://rubyhoedown.com">Ruby Hoedown</a></li> +<li><a href="http://2013.la-conf.org">La Conf</a></li> +<li><a href="http://hubot.github.com">Hubot</a></li> +<li><a href="http://codeconf.com">CodeConf</a></li> +<li><a href="http://railsgirls.com">Rails Girls</a></li> +<li><a href="http://manning.com/mcanally/">Ruby in Practice</a></li> +<li><a href="http://www.manning.com/lim/">MacRuby in Action</a></li> +<li><a href="http://www.railsupgradehandbook.com">Rails 3 Upgrade Handbook</a></li> +<li><a href="https://github.com/vmg/redcarpet">RedCarpet Markdown parser</a></li> +<li><a href="http://www.princexml.com">PrinceXML</a></li> +<li><a href="http://securingrails.com">Securing Rails</a></li> +<li><a href="http://www.ncbi.nlm.nih.gov/pubmedhealth/PMH0002499/">Seasonal Affective Disorder</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/jm">@jm</a> on twitter.</p> + + + + This week Ben Orenstein is joined by Jeremy McAnally, employee at GitHub, author of Ruby in Practice, Rails 3 Upgrade Handbook, MacRuby in Action, and more. Jeremy and Ben discuss teaching and organizing conferences, remote working for GitHub, the and the company summits, GitHub workflows, their internal tools team. They also talk about standing out from the pack in work, life, and getting accepted to conferences, selecting people to speak at conferences, self-publishing, Jeremy's writing process and future writing plans, work-life balance, how to get a job at GitHub, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @jm on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben Orenstein is joined by Jeremy McAnally, employee at GitHub, author of Ruby in Practice, Rails 3 Upgrade Handbook, MacRuby in Action, and more. Jeremy and Ben discuss teaching and organizing conferences, remote working for GitHub, the and the company summits, GitHub workflows, their internal tools team. They also talk about standing out from the pack in work, life, and getting accepted to conferences, selecting people to speak at conferences, self-publishing, Jeremy's writing process and future writing plans, work-life balance, how to get a job at GitHub, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @jm on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YvhSCMeu + + ]]> + + + + 37: You're riding the Rails bro! + https://podcast.thoughtbot.com/37 + ab456a03-5a6d-4873-895e-707624d8031f + Sun, 24 Feb 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined this week by Joe Ferris, CTO of thoughtbot. Ben and Joe discuss starting a new Rails project and our Rails application generator, Suspenders, test spies and breaking up your tests, and using Rails beta versions. + + + 34:48 + no + + <p>Ben Orenstein is joined this week by Joe Ferris, CTO of thoughtbot. Ben and Joe discuss starting a new Rails project and our Rails application generator, Suspenders, test spies and breaking up your tests, and using Rails beta versions.</p> +<ul> +<li><a href="http://github.com/thoughtbot/suspenders">Suspenders</a></li> +<li><a href="https://github.com/thoughtbot/suspenders/blob/master/templates/Gemfile_clean">Suspenders app Gemfile</a></li> +<li><a href="http://learn.thoughtbot.com/podcast/2">Podcast with Bourbon creator Phil LaPier</a></li> +<li><a href="https://devcenter.heroku.com/articles/procfile">Declaring and Scaling Process Types with Procfile</a></li> +<li><a href="http://xunitpatterns.com/Test%20Spy.html">Test spy</a></li> +<li><a href="https://trello.com/">Trello</a></li> +<li><a href="http://en.wikipedia.org/wiki/Minimum_viable_product">Minimum viable product (MVP)</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/joeferris">@joeferris</a> on twitter.</p> + + + + Ben Orenstein is joined this week by Joe Ferris, CTO of thoughtbot. Ben and Joe discuss starting a new Rails project and our Rails application generator, Suspenders, test spies and breaking up your tests, and using Rails beta versions.

+ + + +

Follow @thoughtbot, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined this week by Joe Ferris, CTO of thoughtbot. Ben and Joe discuss starting a new Rails project and our Rails application generator, Suspenders, test spies and breaking up your tests, and using Rails beta versions.

+ + + +

Follow @thoughtbot, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+FT4FxLIk + + ]]> + + + + 36: A gem called exploit + https://podcast.thoughtbot.com/36 + bc0ca359-2dd3-479b-b8c5-c790d60b878e + Sun, 17 Feb 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + This week Ben Orenstein is joined by Nick Quaranto, developer at 37signals and one of the maintainers of RubyGems.org. Nick and Ben discuss the just released Basecamp iOS app, the architecture of the app, the origins of the app and how it became what it is today, and RubyMotion in general. They then move on to discuss the recent RubyGems.org cracking, the mechanism behind it, the process of restoring the service, and how it might affect RubyGems going forward. They then circle back to talk more about RubyMotion, testing, working at 37signals, CoworkBuffalo, OpenHack, and good coffee. + + + 48:21 + no + + <p>This week Ben Orenstein is joined by Nick Quaranto, developer at 37signals and one of the maintainers of RubyGems.org. Nick and Ben discuss the just released Basecamp iOS app, the architecture of the app, the origins of the app and how it became what it is today, and RubyMotion in general. They then move on to discuss the recent RubyGems.org cracking, the mechanism behind it, the process of restoring the service, and how it might affect RubyGems going forward. They then circle back to talk more about RubyMotion, testing, working at 37signals, CoworkBuffalo, OpenHack, and good coffee.</p> +<ul> +<li><a href="http://www.rubymotion.com/conference/">#inspect, RubyMotion conference</a></li> +<li><a href="http://basecamp.com/mobile">Basecamp for iOS</a></li> +<li><a href="http://venturebeat.com/2013/01/30/rubygems-org-hacked-interrupting-heroku-services-and-putting-millions-of-sites-using-rails-at-risk/">RubyGems.org cracked</a></li> +<li><a href="http://coworkbuffalo.com/">CoworkBuffalo</a></li> +<li><a href="http://37signals.com/svn/posts/3162-the-on-call-programmer">The On-Call Programmer</a></li> +<li><a href="http://thepurdman.com/">Kevin Purdy</a></li> +<li><a href="http://www.chemexcoffeemaker.com/">Chemex Coffeemaker</a></li> +<li><a href="http://openhack.github.com/">OpenHack</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/qrush">@qrush</a> on twitter.</p> + + + + This week Ben Orenstein is joined by Nick Quaranto, developer at 37signals and one of the maintainers of RubyGems.org. Nick and Ben discuss the just released Basecamp iOS app, the architecture of the app, the origins of the app and how it became what it is today, and RubyMotion in general. They then move on to discuss the recent RubyGems.org cracking, the mechanism behind it, the process of restoring the service, and how it might affect RubyGems going forward. They then circle back to talk more about RubyMotion, testing, working at 37signals, CoworkBuffalo, OpenHack, and good coffee.

+ + + +

Follow @thoughtbot, @r00k, and @qrush on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben Orenstein is joined by Nick Quaranto, developer at 37signals and one of the maintainers of RubyGems.org. Nick and Ben discuss the just released Basecamp iOS app, the architecture of the app, the origins of the app and how it became what it is today, and RubyMotion in general. They then move on to discuss the recent RubyGems.org cracking, the mechanism behind it, the process of restoring the service, and how it might affect RubyGems going forward. They then circle back to talk more about RubyMotion, testing, working at 37signals, CoworkBuffalo, OpenHack, and good coffee.

+ + + +

Follow @thoughtbot, @r00k, and @qrush on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+rGsA82ko + + ]]> + + + + 35: I haven't lifted a pencil in years + https://podcast.thoughtbot.com/35 + 41968694-d8f6-4558-8d25-a75547dfb8a2 + Sun, 10 Feb 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Dennis Najjar CPA from AccountingDepartment.com. They discuss international companies operating in the United States, the tools of his trade, how AccountingDepartment.com is set up and what their different clients look like, and why it makes sense to outsource your bookkeeping and accounting. They also explore the checks and balances you should have in bookkeeping and accounting, the accounting departments role in an organization and 1099s their purpose, and what to do if you don't get one. + + + 29:16 + no + + <p>Ben Orenstein is joined by Dennis Najjar CPA from AccountingDepartment.com. They discuss international companies operating in the United States, the tools of his trade, how AccountingDepartment.com is set up and what their different clients look like, and why it makes sense to outsource your bookkeeping and accounting. They also explore the checks and balances you should have in bookkeeping and accounting, the accounting departments role in an organization and 1099s their purpose, and what to do if you don't get one.</p> +<ul> +<li><a href="http://AccountingDepartment.com">AccountingDepartment.com</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a> and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Dennis Najjar CPA from AccountingDepartment.com. They discuss international companies operating in the United States, the tools of his trade, how AccountingDepartment.com is set up and what their different clients look like, and why it makes sense to outsource your bookkeeping and accounting. They also explore the checks and balances you should have in bookkeeping and accounting, the accounting departments role in an organization and 1099s their purpose, and what to do if you don't get one.

+ + + +

Follow @thoughtbot and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Dennis Najjar CPA from AccountingDepartment.com. They discuss international companies operating in the United States, the tools of his trade, how AccountingDepartment.com is set up and what their different clients look like, and why it makes sense to outsource your bookkeeping and accounting. They also explore the checks and balances you should have in bookkeeping and accounting, the accounting departments role in an organization and 1099s their purpose, and what to do if you don't get one.

+ + + +

Follow @thoughtbot and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+2rQot1JZ + + ]]> + + + + 34: Very little comes to those who wait + https://podcast.thoughtbot.com/34 + 0f298c55-e89e-4c06-9a66-056a986ef20e + Sun, 03 Feb 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + In this week's episode, Ben Orenstein is joined by Steve Snyder, Entrepreneur in Residence at the law firm, Gesmer Updegrove LLP. Ben and Steve discuss Steve's history, his unique position at the law firm, mistakes to avoid, and advice and guidance to entrepreneurs just starting out. + + + 29:19 + no + + <p>In this week's episode, Ben Orenstein is joined by Steve Snyder, Entrepreneur in Residence at the law firm, Gesmer Updegrove LLP. Ben and Steve discuss Steve's history, his unique position at the law firm, mistakes to avoid, and advice and guidance to entrepreneurs just starting out.</p> +<ul> +<li><a href="http://gesmer.com">Gesmer Updegrove LLP</a></li> +<li><a href="http://www.amazon.com/gp/product/0976470705/ref=as_li_ss_tl?ie=UTF8&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0976470705&amp;linkCode=as2&amp;tag=giantrobotssm-20">The Four Steps to the Epiphany: Successful Strategies for Products that Win</a></li> +<li><a href="http://www.amazon.com/gp/product/0385512058/ref=as_li_ss_tl?ie=UTF8&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0385512058&amp;linkCode=as2&amp;tag=giantrobotssm-20">Never Eat Alone: And Other Secrets to Success, One Relationship at a Time</a></li> +<li><a href="http://www.amazon.com/gp/product/0066620996/ref=as_li_ss_tl?ie=UTF8&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0066620996&amp;linkCode=as2&amp;tag=giantrobotssm-20">Good to Great: Why Some Companies Make the Leap... and Others Don't</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a> and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + In this week's episode, Ben Orenstein is joined by Steve Snyder, Entrepreneur in Residence at the law firm, Gesmer Updegrove LLP. Ben and Steve discuss Steve's history, his unique position at the law firm, mistakes to avoid, and advice and guidance to entrepreneurs just starting out.

+ + + +

Follow @thoughtbot and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this week's episode, Ben Orenstein is joined by Steve Snyder, Entrepreneur in Residence at the law firm, Gesmer Updegrove LLP. Ben and Steve discuss Steve's history, his unique position at the law firm, mistakes to avoid, and advice and guidance to entrepreneurs just starting out.

+ + + +

Follow @thoughtbot and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+4DoiFlBw + + ]]> + + + + 33: I've failed before + https://podcast.thoughtbot.com/33 + 5df976f8-520e-4efa-8b50-180ec18bd9cb + Sun, 27 Jan 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + This week Ben Orenstein is joined by Jarrod Drysdale, the author of Bootstrapping Design. Ben and Jarrod discuss the sales and revenue of the book, and his new project, cascade.io. They also talk about learning new things, problem solving, and the differences between programming and design. They also discuss the downside to recurring revenue, successful marketing strategies for his book, advice for people who want to start something new, the concerns of a solo entrepreneur, and how his previous failures help him keep perspective. + + + 25:36 + no + + <p>This week Ben Orenstein is joined by Jarrod Drysdale, the author of Bootstrapping Design. Ben and Jarrod discuss the sales and revenue of the book, and his new project, cascade.io. They also talk about learning new things, problem solving, and the differences between programming and design. They also discuss the downside to recurring revenue, successful marketing strategies for his book, advice for people who want to start something new, the concerns of a solo entrepreneur, and how his previous failures help him keep perspective.</p> +<ul> +<li><a href="http://bootstrappingdesign.com">Bootstrapping Design</a></li> +<li><a href="http://cascade.io">cascade.io</a></li> +<li><a href="http://gettingreal.37signals.com/">Getting Real</a></li> +<li><a href="http://unicornfree.com/30x500">30x500</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/studiofellow">@studiofellow</a> on twitter.</p> + + + + This week Ben Orenstein is joined by Jarrod Drysdale, the author of Bootstrapping Design. Ben and Jarrod discuss the sales and revenue of the book, and his new project, cascade.io. They also talk about learning new things, problem solving, and the differences between programming and design. They also discuss the downside to recurring revenue, successful marketing strategies for his book, advice for people who want to start something new, the concerns of a solo entrepreneur, and how his previous failures help him keep perspective.

+ + + +

Follow @thoughtbot, @r00k, and @studiofellow on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Ben Orenstein is joined by Jarrod Drysdale, the author of Bootstrapping Design. Ben and Jarrod discuss the sales and revenue of the book, and his new project, cascade.io. They also talk about learning new things, problem solving, and the differences between programming and design. They also discuss the downside to recurring revenue, successful marketing strategies for his book, advice for people who want to start something new, the concerns of a solo entrepreneur, and how his previous failures help him keep perspective.

+ + + +

Follow @thoughtbot, @r00k, and @studiofellow on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7dJ2T6Gi + + ]]> + + + + 32: There is an excited you in there + https://podcast.thoughtbot.com/32 + d05e4b9e-3492-43a5-9e19-51ed4fca3fa5 + Sun, 20 Jan 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined this week by Daniel Jalkut, the developer of MarsEdit and other fine software. Ben and Daniel discuss the origin of Daniel's twitter username, his history at Apple and his work there, and how it influences what he builds today. They also discuss the challenges of running your own company, and how Daniel's priorities and rule systems help him get things done, how the success of MarsEdit takes up his attention at the exclusion of other ideas, and how he thinks about failure. Then then go on to talk about App Store versus direct sales, why Daniel still sells his software outside the app store as well as in it, and what the breakdown of sales are like there, as well as Daniel's thoughts on App Store pricing and the benefits of being in the app store. Finally, Daniel tells us why he thinks git is like a PC and Mercurial is like a Mac, why he dislikes git, what he thinks makes a good podcast, how his podcast has changed, and much more. + + + 42:07 + no + + <p>Ben Orenstein is joined this week by Daniel Jalkut, the developer of MarsEdit and other fine software. Ben and Daniel discuss the origin of Daniel's twitter username, his history at Apple and his work there, and how it influences what he builds today. They also discuss the challenges of running your own company, and how Daniel's priorities and rule systems help him get things done, how the success of MarsEdit takes up his attention at the exclusion of other ideas, and how he thinks about failure. Then then go on to talk about App Store versus direct sales, why Daniel still sells his software outside the app store as well as in it, and what the breakdown of sales are like there, as well as Daniel's thoughts on App Store pricing and the benefits of being in the app store. Finally, Daniel tells us why he thinks git is like a PC and Mercurial is like a Mac, why he dislikes git, what he thinks makes a good podcast, how his podcast has changed, and much more.</p> +<ul> +<li><a href="http://www.red-sweater.com/">Red Sweater Software</a></li> +<li><a href="http://www.red-sweater.com/marsedit/">MarsEdit</a></li> +<li><a href="http://cvs.nongnu.org/">CVS</a></li> +<li><a href="http://en.wikipedia.org/wiki/Revision_Control_System">RCS</a></li> +<li><a href="http://en.wikipedia.org/wiki/Apache_Subversion">SVN</a></li> +<li><a href="http://git-scm.com/">git</a></li> +<li><a href="http://bazaar.canonical.com/en/">Bazaar</a></li> +<li><a href="http://mercurial.selenic.com/">Mercurial</a></li> +<li><a href="http://coreint.org">Core Intuition</a></li> +<li><a href="http://vimeo.com/33007225">Real Artists Ship. Eventually.</a></li> +<li><a href="http://xn--ingleton-r0a.com/en/">Çingleton Symposium</a></li> +<li><a href="http://red-sweater.com/blog">Red Sweater Software Blog</a></li> +<li><a href="Bitsplitting.org">Bitsplitting.org</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/danielpunkass">@danielpunkass</a> on twitter.</p> + + + + Ben Orenstein is joined this week by Daniel Jalkut, the developer of MarsEdit and other fine software. Ben and Daniel discuss the origin of Daniel's twitter username, his history at Apple and his work there, and how it influences what he builds today. They also discuss the challenges of running your own company, and how Daniel's priorities and rule systems help him get things done, how the success of MarsEdit takes up his attention at the exclusion of other ideas, and how he thinks about failure. Then then go on to talk about App Store versus direct sales, why Daniel still sells his software outside the app store as well as in it, and what the breakdown of sales are like there, as well as Daniel's thoughts on App Store pricing and the benefits of being in the app store. Finally, Daniel tells us why he thinks git is like a PC and Mercurial is like a Mac, why he dislikes git, what he thinks makes a good podcast, how his podcast has changed, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @danielpunkass on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined this week by Daniel Jalkut, the developer of MarsEdit and other fine software. Ben and Daniel discuss the origin of Daniel's twitter username, his history at Apple and his work there, and how it influences what he builds today. They also discuss the challenges of running your own company, and how Daniel's priorities and rule systems help him get things done, how the success of MarsEdit takes up his attention at the exclusion of other ideas, and how he thinks about failure. Then then go on to talk about App Store versus direct sales, why Daniel still sells his software outside the app store as well as in it, and what the breakdown of sales are like there, as well as Daniel's thoughts on App Store pricing and the benefits of being in the app store. Finally, Daniel tells us why he thinks git is like a PC and Mercurial is like a Mac, why he dislikes git, what he thinks makes a good podcast, how his podcast has changed, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @danielpunkass on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Omf3unMr + + ]]> + + + + 31: I write everything in Markdown + https://podcast.thoughtbot.com/31 + 9205d206-31c5-48ab-bcdc-8a83de9b8580 + Sun, 13 Jan 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + This week Chad Pytel is joined by software developer, podcaster, and author, Brett Terpstra. Chad and Brett discuss Brett's work location and setup, his open source and commercial software projects, app store pricing, his publishing experience and workflow, and his podcast. They also discuss his keyboard and trackpad mappings, and much more. + + + 45:28 + no + + <p>This week Chad Pytel is joined by software developer, podcaster, and author, Brett Terpstra. Chad and Brett discuss Brett's work location and setup, his open source and commercial software projects, app store pricing, his publishing experience and workflow, and his podcast. They also discuss his keyboard and trackpad mappings, and much more.</p> +<ul> +<li><a href="http://brettterpstra.com/">brettterpstra.com</a></li> +<li><a href="http://brettterpstra.com/projects/nvalt/">nvALT</a></li> +<li><a href="http://github.com/ttscoff">Brett's GitHub profile</a></li> +<li><a href="http://markedapp.com/">Marked</a></li> +<li><a href="http://fletcherpenney.net/multimarkdown/">MultiMarkdown</a></li> +<li><a href="http://60tips.com/">60 Mountain Lion Tips</a></li> +<li><a href="http://www.apple.com/ibooks-author/">iBooks Author</a></li> +<li><a href="http://johnmacfarlane.net/pandoc/">Pandoc</a></li> +<li><a href="http://5by5.tv/systematic">Systematic on 5by5</a></li> +<li><a href="http://pqrs.org/macosx/keyremap4macbook/index.html">KeyRemap4MacBook</a></li> +<li><a href="https://itunes.apple.com/us/app/apptivate/id412442297?mt=12&amp;ls=1">Apptivate</a></li> +<li><a href="http://blog.boastr.net/">BetterTouchTool</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/cpytel">@cpytel</a>, and <a href="http://twitter.com/ttscoff">@ttscoff</a> on twitter.</p> + + + + This week Chad Pytel is joined by software developer, podcaster, and author, Brett Terpstra. Chad and Brett discuss Brett's work location and setup, his open source and commercial software projects, app store pricing, his publishing experience and workflow, and his podcast. They also discuss his keyboard and trackpad mappings, and much more.

+ + + +

Follow @thoughtbot, @cpytel, and @ttscoff on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + This week Chad Pytel is joined by software developer, podcaster, and author, Brett Terpstra. Chad and Brett discuss Brett's work location and setup, his open source and commercial software projects, app store pricing, his publishing experience and workflow, and his podcast. They also discuss his keyboard and trackpad mappings, and much more.

+ + + +

Follow @thoughtbot, @cpytel, and @ttscoff on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+y3hHteza + + ]]> + + + + 30: Giant Year-End Extravaganza + https://podcast.thoughtbot.com/30 + 0ef47ec6-a695-4fc7-9c4f-964ff6336cf8 + Sun, 06 Jan 2013 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Chad Pytel, the CEO of thoughtbot to take a look back at some of the things thoughtbot did in 2012. They then answer a bunch of listener questions. + + + 1:06:12 + no + + <p>Ben Orenstein is joined by Chad Pytel, the CEO of thoughtbot to take a look back at some of the things thoughtbot did in 2012. They then answer a bunch of listener questions.</p> +<p>January</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/16482074033/a-users-guide-to-the-trajectory-redesign">Trajectory Redesign</a></li> +<li><a href="http://robots.thoughtbot.com/post/16351438761/every-two-weeks">Open source releases every two weeks</a></li> +<li>Factory Girl <a href="http://robots.thoughtbot.com/post/16196616388/factory-girl-2-5-gets-custom-constructors">2.4 (refactoring, speed increase)</a> and <a href="http://robots.thoughtbot.com/post/15781666382/factory-girl-2-4-goes-meta">2.5 (custom constructors)</a></li> +<li><a href="http://robots.thoughtbot.com/post/16188170538/this-week-in-open-source">shoulda-context gets a new maintainer</a></li> +</ul> +<p>February</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/18206938004/this-week-in-open-source">Shoulda 3.0</a></li> +<li><a href="http://robots.thoughtbot.com/post/17272077669/your-next-great-teammate">Apprentice.io Launches</a></li> +<li><a href="http://robots.thoughtbot.com/post/17212734809/airbrake-acquired-by-exceptional">Airbrake acquired by Exceptional</a></li> +</ul> +<p>March</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/20000383818/thoughtbot-stockholm-drinkup">thoughtbot goes to Stockholm</a></li> +<li><a href="http://robots.thoughtbot.com/post/19970041727/paperclip-is-going-three-point-oh-nelly">Paperclip 3.0</a></li> +<li><a href="http://robots.thoughtbot.com/post/19412394597/factory-girl-hits-3-0">FactoryGirl 3.0</a></li> +<li><a href="http://robots.thoughtbot.com/post/19730567422/apprentice-io-is-now-available-to-all-employers">Apprentice.io opens up to all employers</a></li> +<li><a href="http://robots.thoughtbot.com/post/19388751626/copycopter-is-now-open-source">Copycopter goes open source</a></li> +<li><a href="http://robots.thoughtbot.com/post/18799337284/trajectory-gets-campfire-integration">Trajectory gets Campfire integration</a></li> +</ul> +<p>April</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/21919704809/inbox-zero-github-issues-edition">Zero Github Issues</a></li> +<li><a href="http://robots.thoughtbot.com/post/21719164760/factorygirl-3-2-so-awesome-it-needs-to-be-released">FactoryGirl 3.2</a></li> +<li><a href="http://robots.thoughtbot.com/post/20467174559/movin-on-up">New Boston office</a></li> +</ul> +<p>May</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/23991486237/trail-map">Trail Maps released</a></li> +<li><a href="http://robots.thoughtbot.com/post/23547221113/from-the-trajectory-blog-full-featured-json-api-now">Trajectory gets a full json API</a></li> +<li><a href="http://robots.thoughtbot.com/post/22443641867/humans-present-refactoring">Humans Present: Refactoring</a></li> +</ul> +<p>June</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/25723865992/backbone-js-on-rails-hits-1-0">Backbone.js on Rails hit 1.0</a></li> +<li><a href="http://robots.thoughtbot.com/post/24675868820/opening-an-office-in-san-francisco">Opening and office in SF</a></li> +<li><a href="http://robots.thoughtbot.com/post/24882797476/introducing-the-giant-robots-smashing-into-other-giant">First podcast episode!</a></li> +</ul> +<p>July</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/26629988118/the-playbook-video-edition">Playbook: Video Edition</a></li> +<li><a href="http://robots.thoughtbot.com/post/28149261375/this-week-in-open-source">Version 3.6.0 of factory_girl, memoization to the names of attributes which adds a 33% speed increase on factories with override</a></li> +</ul> +<p>August</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/28645764713/introducing-learn-thoughtbot-com">Learn launched</a></li> +</ul> +<p>September</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/34653032294/version-1-0-of-bourbon-neat-a-sass-based-responsive">Bourbon Neat version 1.0</a></li> +<li><a href="http://robots.thoughtbot.com/post/34305013700/new-online-thoughtbot-workshops">Online workshops</a></li> +</ul> +<p>November</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/36826546148/opening-an-office-in-colorado">Colorado office announced</a></li> +<li><a href="http://robots.thoughtbot.com/post/36735316520/drinkup-in-stockholm">Stockholm drinkup</a></li> +<li><a href="http://robots.thoughtbot.com/post/35710467830/take-an-online-test-driven-rails-workshop-with">2nd online workshop Test-Driven Rails</a></li> +</ul> +<p>December</p> +<ul> +<li><a href="http://robots.thoughtbot.com/post/37837704879/she-blinded-me-with-ruby-science">Ruby Science launched</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/cpytel">@cpytel</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Chad Pytel, the CEO of thoughtbot to take a look back at some of the things thoughtbot did in 2012. They then answer a bunch of listener questions.

+ +

January

+ + + +

February

+ + + +

March

+ + + +

April

+ + + +

May

+ + + +

June

+ + + +

July

+ + + +

August

+ + + +

September

+ + + +

November

+ + + +

December

+ + + +

Follow @thoughtbot, @cpytel, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Chad Pytel, the CEO of thoughtbot to take a look back at some of the things thoughtbot did in 2012. They then answer a bunch of listener questions.

+ +

January

+ + + +

February

+ + + +

March

+ + + +

April

+ + + +

May

+ + + +

June

+ + + +

July

+ + + +

August

+ + + +

September

+ + + +

November

+ + + +

December

+ + + +

Follow @thoughtbot, @cpytel, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+FlPpvS8Y + + ]]> + + + + 29: The most ironic iOS developer + https://podcast.thoughtbot.com/29 + 521ebdbd-94ec-4dd0-8a0f-ce6e959917e0 + Sun, 30 Dec 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Gordon Fontenot and Matt Mongeau, two thoughtbot developers, to discuss iOS development using both Objective-C and RubyMotion. Ben, Matt, and Gordon talk about the differences between the two platforms for iOS development, testing in iOS development, the difficulty in it, and the ways to do it. They also make they're recommendations for getting started with iOS development, and discuss iOS apps they like, designing iOS applications, the iOS release cycle, and much more. + + + 28:41 + no + + <p>Ben Orenstein is joined by Gordon Fontenot and Matt Mongeau, two thoughtbot developers, to discuss iOS development using both Objective-C and RubyMotion. Ben, Matt, and Gordon talk about the differences between the two platforms for iOS development, testing in iOS development, the difficulty in it, and the ways to do it. They also make they're recommendations for getting started with iOS development, and discuss iOS apps they like, designing iOS applications, the iOS release cycle, and much more.</p> +<ul> +<li><a href="http://www.rubymotion.com/">RubyMotion</a></li> +<li><a href="http://en.wikipedia.org/wiki/LLVM">LLVM</a></li> +<li><a href="http://coffeescript.org/">CoffeeScript</a></li> +<li><a href="https://github.com/chneukirchen/bacon">Bacon, a small RSpec clone</a></li> +<li><a href="http://www.rubymotion.com/developer-center/articles/testing/">Writing Tests for RubyMotion Apps</a></li> +<li><a href="http://www.joelonsoftware.com/articles/fog0000000319.html">Joel on Software, &quot;Back to Basics&quot;</a></li> +<li><a href="http://lldb.llvm.org/">The LLDB Debugger</a></li> +<li><a href="http://rubymotion-tutorial.com/">rubymotion-tutorial.com</a></li> +<li><a href="http://pragprog.com/book/carubym/rubymotion">RubyMotion, by Clay Allsop</a></li> +<li><a href="http://www.amazon.com/gp/product/0321774183/ref=as_li_ss_tl?ie=UTF8&amp;tag=giantrobotssm-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0321774183">Test-Driven iOS Development</a></li> +<li><a href="https://itunes.apple.com/us/book/all-the-c-you-need-to-know/id581989356?mt=11">All the C You Need to Know</a></li> +<li><a href="http://flexibits.com/fantastical-iphone">Fantastical for iPhone</a></li> +<li><a href="http://developer.apple.com/library/ios/#documentation/uikit/reference/UIAppearance_Protocol/Reference/Reference.html">UIAppearance</a></li> +<li><a href="http://cocoapods.org/">CocoaPods</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/halogenandtoast">@halogenandtoast</a>, <a href="http://twitter.com/gfontenot">@gfontenot</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Gordon Fontenot and Matt Mongeau, two thoughtbot developers, to discuss iOS development using both Objective-C and RubyMotion. Ben, Matt, and Gordon talk about the differences between the two platforms for iOS development, testing in iOS development, the difficulty in it, and the ways to do it. They also make they're recommendations for getting started with iOS development, and discuss iOS apps they like, designing iOS applications, the iOS release cycle, and much more.

+ + + +

Follow @thoughtbot, @halogenandtoast, @gfontenot, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Gordon Fontenot and Matt Mongeau, two thoughtbot developers, to discuss iOS development using both Objective-C and RubyMotion. Ben, Matt, and Gordon talk about the differences between the two platforms for iOS development, testing in iOS development, the difficulty in it, and the ways to do it. They also make they're recommendations for getting started with iOS development, and discuss iOS apps they like, designing iOS applications, the iOS release cycle, and much more.

+ + + +

Follow @thoughtbot, @halogenandtoast, @gfontenot, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+PuyG993q + + ]]> + + + + 28: Farther, further, faster + https://podcast.thoughtbot.com/28 + 0f3ed96e-6dba-438e-94a3-e9cfd5f3e4ab + Sun, 23 Dec 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by David Heinemeier Hansson, the creator of Ruby on Rails and a partner at 37signals. David and Ben discuss David's normal day, his working relationship with Jason Fried, how their blog, Signal vs. Noise, is important to the company, how he got into programming, where he draws his inspiration from, some good books he's read and how he learns today, how he overcomes fear and why he takes risks, how he got into racing, why he enjoys it, what he learns from it, and how feedback loops and goal posts help you learn, inspire you, and help you know how good you are. They then go on to explore what David would, or wouldn't, change about Rails, and how he sees Rails evolving into the future. David also talks a little bit about the new product 37signals has in development, and 37signals' overall product strategy, coding at 37signals and his approach to providing guidance to the team, what role he plays on Rails core, what he cares about, and what he pays attention to, and much, much more. + + + 47:57 + no + + <p>Ben Orenstein is joined by David Heinemeier Hansson, the creator of Ruby on Rails and a partner at 37signals. David and Ben discuss David's normal day, his working relationship with Jason Fried, how their blog, Signal vs. Noise, is important to the company, how he got into programming, where he draws his inspiration from, some good books he's read and how he learns today, how he overcomes fear and why he takes risks, how he got into racing, why he enjoys it, what he learns from it, and how feedback loops and goal posts help you learn, inspire you, and help you know how good you are. They then go on to explore what David would, or wouldn't, change about Rails, and how he sees Rails evolving into the future. David also talks a little bit about the new product 37signals has in development, and 37signals' overall product strategy, coding at 37signals and his approach to providing guidance to the team, what role he plays on Rails core, what he cares about, and what he pays attention to, and much, much more.</p> +<ul> +<li><a href="http://david.heinemeierhansson.com/">David's website</a></li> +<li><a href="http://37signals.com/svn">Signal vs. Noise</a></li> +<li><a href="http://www.amazon.com/gp/product/0321125215/ref=as_li_ss_tl?ie=UTF8&amp;tag=giantrobotssm-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0321125215">Domain-Driven Design: Tackling Complexity in the Heart of Software</a></li> +<li><a href="http://www.amazon.com/gp/product/0321127420/ref=as_li_ss_tl?ie=UTF8&amp;tag=giantrobotssm-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0321127420">Patterns of Enterprise Application Architecture</a></li> +<li><a href="http://www.amazon.com/gp/product/0201485672/ref=as_li_ss_tl?ie=UTF8&amp;tag=giantrobotssm-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0201485672">Refactoring: Improving the Design of Existing Code</a></li> +<li><a href="http://www.amazon.com/gp/product/0321278658/ref=as_li_ss_tl?ie=UTF8&amp;tag=giantrobotssm-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0321278658">Extreme Programming Explained: Embrace Change</a></li> +<li><a href="http://www.amazon.com/gp/product/013476904X/ref=as_li_ss_tl?ie=UTF8&amp;tag=giantrobotssm-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=013476904X">Smalltalk Best Practice Patterns</a></li> +<li><a href="http://www.amazon.com/gp/product/0735619670/ref=as_li_ss_tl?ie=UTF8&amp;tag=giantrobotssm-20&amp;linkCode=as2&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0735619670">Code Complete: A Practical Handbook of Software Construction</a></li> +<li><a href="http://david.heinemeierhansson.com/racing">David Heinemeier Hansson's racing</a></li> +<li><a href="http://www.sinatrarb.com/">Sinatra</a></li> +<li><a href="http://nodejs.org/">Node.js</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/dhh">@dhh</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by David Heinemeier Hansson, the creator of Ruby on Rails and a partner at 37signals. David and Ben discuss David's normal day, his working relationship with Jason Fried, how their blog, Signal vs. Noise, is important to the company, how he got into programming, where he draws his inspiration from, some good books he's read and how he learns today, how he overcomes fear and why he takes risks, how he got into racing, why he enjoys it, what he learns from it, and how feedback loops and goal posts help you learn, inspire you, and help you know how good you are. They then go on to explore what David would, or wouldn't, change about Rails, and how he sees Rails evolving into the future. David also talks a little bit about the new product 37signals has in development, and 37signals' overall product strategy, coding at 37signals and his approach to providing guidance to the team, what role he plays on Rails core, what he cares about, and what he pays attention to, and much, much more.

+ + + +

Follow @thoughtbot, @dhh, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by David Heinemeier Hansson, the creator of Ruby on Rails and a partner at 37signals. David and Ben discuss David's normal day, his working relationship with Jason Fried, how their blog, Signal vs. Noise, is important to the company, how he got into programming, where he draws his inspiration from, some good books he's read and how he learns today, how he overcomes fear and why he takes risks, how he got into racing, why he enjoys it, what he learns from it, and how feedback loops and goal posts help you learn, inspire you, and help you know how good you are. They then go on to explore what David would, or wouldn't, change about Rails, and how he sees Rails evolving into the future. David also talks a little bit about the new product 37signals has in development, and 37signals' overall product strategy, coding at 37signals and his approach to providing guidance to the team, what role he plays on Rails core, what he cares about, and what he pays attention to, and much, much more.

+ + + +

Follow @thoughtbot, @dhh, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+m0qAhxuL + + ]]> + + + + 27: Fabulous new mistakes + https://podcast.thoughtbot.com/27 + 4dd3d983-7742-462c-bddc-04fb07cd3270 + Sun, 16 Dec 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot. Inspired by a question on Law of Demeter from listener Nathan Long, Joe and Ben (hopefully) answer Nathan's question, and then go on to discuss how the Law of Demeter is a form of duplication, how it effects testing, and how to better architect your report, your view, or your entire system to better obey the Law of Demeter. They also touch upon Rails' try method, how the pain of testing helps guide the code you write, where the Law of Demeter doesn't apply, how people don't refactor their tests, how to productively refactor your tests and avoid wasting time rewriting things, and much more. + + + 26:39 + no + + <p>Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot. Inspired by a question on Law of Demeter from listener Nathan Long, Joe and Ben (hopefully) answer Nathan's question, and then go on to discuss how the Law of Demeter is a form of duplication, how it effects testing, and how to better architect your report, your view, or your entire system to better obey the Law of Demeter. They also touch upon Rails' try method, how the pain of testing helps guide the code you write, where the Law of Demeter doesn't apply, how people don't refactor their tests, how to productively refactor your tests and avoid wasting time rewriting things, and much more.</p> +<ul> +<li><a href="http://en.wikipedia.org/wiki/Law_of_Demeter">Law of Demeter, Wikipedia</a></li> +<li><a href="http://devblog.avdi.org/2011/07/05/demeter-its-not-just-a-good-idea-its-the-law/">Virtuous Code - Avdi Grimm, Demeter: It's not just a good idea. It's the law</a></li> +<li><a href="https://gist.github.com/4176695">Nathan Long's LoD question</a></li> +<li><a href="http://api.rubyonrails.org/classes/Object.html#method-i-try">#try</a></li> +<li><a href="http://en.wikipedia.org/wiki/Builder_pattern">Builder pattern, Wikipedia</a></li> +<li><a href="http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule">The Boy Scout Rule</a></li> +<li><a href="http://rubyscience.com">Ruby Science</a></li> +<li><a href="https://www.relishapp.com/rspec/rspec-mocks/v/2-0/docs/stubs/stub-a-chain-of-methods">Fluent interfaces, Stub a chain of methods</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/joeferris">@joeferris</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot. Inspired by a question on Law of Demeter from listener Nathan Long, Joe and Ben (hopefully) answer Nathan's question, and then go on to discuss how the Law of Demeter is a form of duplication, how it effects testing, and how to better architect your report, your view, or your entire system to better obey the Law of Demeter. They also touch upon Rails' try method, how the pain of testing helps guide the code you write, where the Law of Demeter doesn't apply, how people don't refactor their tests, how to productively refactor your tests and avoid wasting time rewriting things, and much more.

+ + + +

Follow @thoughtbot, @joeferris, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot. Inspired by a question on Law of Demeter from listener Nathan Long, Joe and Ben (hopefully) answer Nathan's question, and then go on to discuss how the Law of Demeter is a form of duplication, how it effects testing, and how to better architect your report, your view, or your entire system to better obey the Law of Demeter. They also touch upon Rails' try method, how the pain of testing helps guide the code you write, where the Law of Demeter doesn't apply, how people don't refactor their tests, how to productively refactor your tests and avoid wasting time rewriting things, and much more.

+ + + +

Follow @thoughtbot, @joeferris, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_nPFke88 + + ]]> + + + + 26: Deep into the psyche of Gary Bernhardt + https://podcast.thoughtbot.com/26 + b0037c94-d114-4303-8d92-e4bc4189ea02 + Sun, 09 Dec 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Gary Berhardt from Destroy All Software Screencasts. Ben and Gary discuss DAS, how it has changed over the two years he's been doing it, and how his thinking has changed over that time. They then discuss Gary's thoughts on how to write software and tests, how we wants to "fix the kernel", and his exciting plans for the future. They also discuss his background, the production process behind Destroy All Software, and much, much more. + + + 41:06 + no + + <p>Ben Orenstein is joined by Gary Berhardt from Destroy All Software Screencasts. Ben and Gary discuss DAS, how it has changed over the two years he's been doing it, and how his thinking has changed over that time. They then discuss Gary's thoughts on how to write software and tests, how we wants to &quot;fix the kernel&quot;, and his exciting plans for the future. They also discuss his background, the production process behind Destroy All Software, and much, much more.</p> +<ul> +<li><a href="https://www.destroyallsoftware.com/screencasts">Destroy All Software Screencasts</a></li> +<li><a href="https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell">Functional Core, Imperative Shell</a></li> +<li><a href="http://www.erlang.org/">Erlang</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/garybernhardt">@garybernhardt</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Gary Berhardt from Destroy All Software Screencasts. Ben and Gary discuss DAS, how it has changed over the two years he's been doing it, and how his thinking has changed over that time. They then discuss Gary's thoughts on how to write software and tests, how we wants to "fix the kernel", and his exciting plans for the future. They also discuss his background, the production process behind Destroy All Software, and much, much more.

+ + + +

Follow @thoughtbot, @garybernhardt, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Gary Berhardt from Destroy All Software Screencasts. Ben and Gary discuss DAS, how it has changed over the two years he's been doing it, and how his thinking has changed over that time. They then discuss Gary's thoughts on how to write software and tests, how we wants to "fix the kernel", and his exciting plans for the future. They also discuss his background, the production process behind Destroy All Software, and much, much more.

+ + + +

Follow @thoughtbot, @garybernhardt, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+JyPPVOKr + + ]]> + + + + 25: Long hours on the BoltBus + https://podcast.thoughtbot.com/25 + 05584609-3f28-4957-9d21-feee3370849f + Sun, 02 Dec 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Alex Godin from dispatch.io. Ben and Alex discuss Alex's hectic time in both apprentice.io and TechStars, how he got started at his age, what he's accomplished so far, what he worries about, when he is happiest, and his outlook on the future. + + + 21:30 + no + + <p>Ben Orenstein is joined by Alex Godin from dispatch.io. Ben and Alex discuss Alex's hectic time in both apprentice.io and TechStars, how he got started at his age, what he's accomplished so far, what he worries about, when he is happiest, and his outlook on the future.</p> +<ul> +<li><a href="http://apprentice.io">apprentice.io</a></li> +<li><a href="http://www.techstars.com/program/locations/nyc/">TechStars NYC</a></li> +<li><a href="http://dispatch.io">dispatch.io</a></li> +<li><a href="http://www.sethgodin.com/sg/">Seth Godin</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/alex_godin">@alex_godin</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Alex Godin from dispatch.io. Ben and Alex discuss Alex's hectic time in both apprentice.io and TechStars, how he got started at his age, what he's accomplished so far, what he worries about, when he is happiest, and his outlook on the future.

+ + + +

Follow @thoughtbot, @alex_godin, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Alex Godin from dispatch.io. Ben and Alex discuss Alex's hectic time in both apprentice.io and TechStars, how he got started at his age, what he's accomplished so far, what he worries about, when he is happiest, and his outlook on the future.

+ + + +

Follow @thoughtbot, @alex_godin, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+QM__wHkx + + ]]> + + + + 24: Not so DRY that it chafes + https://podcast.thoughtbot.com/24 + 558bac5e-5294-4731-874f-8a43af1ad902 + Sun, 25 Nov 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Sarah Mei, RailsBridge co-founder, a developer at Pivotal Labs, and Diaspora core team member. In this episode, recorded at RubyConf 2012, Ben and Sarah discuss how communication patterns of your team manifest themselves in the code it writes, and how understanding those patterns can help you improve your code. They discuss RailsBridge, teaching, how teaching is an incredible learning opportunity, and how RailsBridge has helped expand the community of women developers in San Francisco and beyond. Finally, they explore how she got into Ruby, and women in technology. + + + 31:52 + no + + <p>Ben Orenstein is joined by Sarah Mei, RailsBridge co-founder, a developer at Pivotal Labs, and Diaspora core team member. In this episode, recorded at RubyConf 2012, Ben and Sarah discuss how communication patterns of your team manifest themselves in the code it writes, and how understanding those patterns can help you improve your code. They discuss RailsBridge, teaching, how teaching is an incredible learning opportunity, and how RailsBridge has helped expand the community of women developers in San Francisco and beyond. Finally, they explore how she got into Ruby, and women in technology.</p> +<ul> +<li><a href="http://railsbridge.org/en">RailsBridge</a></li> +<li><a href="http://pivotallabs.com/">Pivotal Labs</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/sarahmei">@sarahmei</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Sarah Mei, RailsBridge co-founder, a developer at Pivotal Labs, and Diaspora core team member. In this episode, recorded at RubyConf 2012, Ben and Sarah discuss how communication patterns of your team manifest themselves in the code it writes, and how understanding those patterns can help you improve your code. They discuss RailsBridge, teaching, how teaching is an incredible learning opportunity, and how RailsBridge has helped expand the community of women developers in San Francisco and beyond. Finally, they explore how she got into Ruby, and women in technology.

+ + + +

Follow @thoughtbot, @sarahmei, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Sarah Mei, RailsBridge co-founder, a developer at Pivotal Labs, and Diaspora core team member. In this episode, recorded at RubyConf 2012, Ben and Sarah discuss how communication patterns of your team manifest themselves in the code it writes, and how understanding those patterns can help you improve your code. They discuss RailsBridge, teaching, how teaching is an incredible learning opportunity, and how RailsBridge has helped expand the community of women developers in San Francisco and beyond. Finally, they explore how she got into Ruby, and women in technology.

+ + + +

Follow @thoughtbot, @sarahmei, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+8GZp_YRU + + ]]> + + + + 23: As a consultant it's always your fault + https://podcast.thoughtbot.com/23 + 9cdc04f1-5365-4548-96ca-fae3cb28e392 + Sun, 18 Nov 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Tammer Saleh and Randall Thomas, the founders of Thunderbolt Labs. In this episode, recorded at RubyConf 2012, they discuss their philosophy of running and building the company, how they differ from other consulting companies, and how they do much more than just Rails programming and how its leading to very interesting new kinds of work. Why they list their prices right on their website, and how they derived their rate of $277 per hour. They also explore what their first year in business has been like, some challenges they've faced, and some important lessons they've learned. + + + 31:54 + no + + <p>Ben Orenstein is joined by Tammer Saleh and Randall Thomas, the founders of Thunderbolt Labs. In this episode, recorded at RubyConf 2012, they discuss their philosophy of running and building the company, how they differ from other consulting companies, and how they do much more than just Rails programming and how its leading to very interesting new kinds of work. Why they list their prices right on their website, and how they derived their rate of $277 per hour. They also explore what their first year in business has been like, some challenges they've faced, and some important lessons they've learned.</p> +<ul> +<li><a href="http://thunderboltlabs.com/">Thunderbolt Labs</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/thunderboltlabs">@thunderboltlabs</a>, <a href="http://twitter.com/brennandunn">@tsaleh</a>, <a href="http://twitter.com/brennandunn">@daksis</a> and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Tammer Saleh and Randall Thomas, the founders of Thunderbolt Labs. In this episode, recorded at RubyConf 2012, they discuss their philosophy of running and building the company, how they differ from other consulting companies, and how they do much more than just Rails programming and how its leading to very interesting new kinds of work. Why they list their prices right on their website, and how they derived their rate of $277 per hour. They also explore what their first year in business has been like, some challenges they've faced, and some important lessons they've learned.

+ + + +

Follow @thoughtbot, @thunderboltlabs, @tsaleh, @daksis and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Tammer Saleh and Randall Thomas, the founders of Thunderbolt Labs. In this episode, recorded at RubyConf 2012, they discuss their philosophy of running and building the company, how they differ from other consulting companies, and how they do much more than just Rails programming and how its leading to very interesting new kinds of work. Why they list their prices right on their website, and how they derived their rate of $277 per hour. They also explore what their first year in business has been like, some challenges they've faced, and some important lessons they've learned.

+ + + +

Follow @thoughtbot, @thunderboltlabs, @tsaleh, @daksis and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YBjFaYcw + + ]]> + + + + 22: Your code looks nice today + https://podcast.thoughtbot.com/22 + 3f706b11-2568-49f8-9fa2-0eece1d6bf7a + Thu, 15 Nov 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Bryan Helmkamp, founder of Code Climate, hosted software metrics for Ruby apps. In this episode, recorded at RubyConf 2012, they discuss what code climate is, how Bryan considers it a small business not a startup, and what its like being a solo founder. They also discuss how code metrics can help you write and maintain better software, how it helps, and how it changes behavior. Finally they explore what the biggest surprise for him has been so far, some of his plans, and what success looks like for him. + + + 23:20 + no + + <p>Ben Orenstein is joined by Bryan Helmkamp, founder of Code Climate, hosted software metrics for Ruby apps. In this episode, recorded at RubyConf 2012, they discuss what code climate is, how Bryan considers it a small business not a startup, and what its like being a solo founder. They also discuss how code metrics can help you write and maintain better software, how it helps, and how it changes behavior. Finally they explore what the biggest surprise for him has been so far, some of his plans, and what success looks like for him.</p> +<ul> +<li><a href="https://codeclimate.com/">Code Climate</a></li> +<li><a href="http://thoughtmerchants.com/">Steve Berry, Thought Merchants</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/brynary">@brynary</a> and <a href="http://twitter.com/codeclimate">@codeclimate</a> on twitter.</p> + + + + Ben Orenstein is joined by Bryan Helmkamp, founder of Code Climate, hosted software metrics for Ruby apps. In this episode, recorded at RubyConf 2012, they discuss what code climate is, how Bryan considers it a small business not a startup, and what its like being a solo founder. They also discuss how code metrics can help you write and maintain better software, how it helps, and how it changes behavior. Finally they explore what the biggest surprise for him has been so far, some of his plans, and what success looks like for him.

+ + + +

Follow @thoughtbot, @r00k, @brynary and @codeclimate on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Bryan Helmkamp, founder of Code Climate, hosted software metrics for Ruby apps. In this episode, recorded at RubyConf 2012, they discuss what code climate is, how Bryan considers it a small business not a startup, and what its like being a solo founder. They also discuss how code metrics can help you write and maintain better software, how it helps, and how it changes behavior. Finally they explore what the biggest surprise for him has been so far, some of his plans, and what success looks like for him.

+ + + +

Follow @thoughtbot, @r00k, @brynary and @codeclimate on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hdbr_rid + + ]]> + + + + 21: Data, Context and Interaction + https://podcast.thoughtbot.com/21 + d38b46a1-f727-4c07-933f-2c2f8a695f02 + Sun, 04 Nov 2012 19:00:00 -0500 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Jim Gay, author of Clean Ruby, and Joe Ferris, CTO of thoughtbot, in the episode recorded at RubyConf 2012. Ben, Joe, and Jim discuss Data, Context and Interaction (DCI), what it is, whether it is at odds with Object-Oriented Programming, how it can be applied to your applications, and much more. + + + 28:10 + no + + <p>Ben Orenstein is joined by Jim Gay, author of Clean Ruby, and Joe Ferris, CTO of thoughtbot, in the episode recorded at RubyConf 2012. Ben, Joe, and Jim discuss Data, Context and Interaction (DCI), what it is, whether it is at odds with Object-Oriented Programming, how it can be applied to your applications, and much more.</p> +<ul> +<li><a href="http://www.clean-ruby.com/">Clean Ruby</a></li> +<li><a href="http://en.wikipedia.org/wiki/Data,_context_and_interaction">DCI</a></li> +<li><a href="http://en.wikipedia.org/wiki/Data_transfer_object">DTO</a></li> +<li><a href="http://radiantcms.org/">Radiant CMS</a></li> +<li><a href="http://www.amazon.com/gp/product/0201702258/ref=as_li_ss_tl?ie=UTF8&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0201702258&amp;linkCode=as2&amp;tag=giantrobotssm-20">Writing Effective Use Cases</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/saturnflyer">@saturnflyer</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/joeferris">@joeferris</a> on twitter.</p> + + + + Ben Orenstein is joined by Jim Gay, author of Clean Ruby, and Joe Ferris, CTO of thoughtbot, in the episode recorded at RubyConf 2012. Ben, Joe, and Jim discuss Data, Context and Interaction (DCI), what it is, whether it is at odds with Object-Oriented Programming, how it can be applied to your applications, and much more.

+ + + +

Follow @thoughtbot, @saturnflyer, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Jim Gay, author of Clean Ruby, and Joe Ferris, CTO of thoughtbot, in the episode recorded at RubyConf 2012. Ben, Joe, and Jim discuss Data, Context and Interaction (DCI), what it is, whether it is at odds with Object-Oriented Programming, how it can be applied to your applications, and much more.

+ + + +

Follow @thoughtbot, @saturnflyer, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+iNZL3Sor + + ]]> + + + + 20: Ruby Lightning + https://podcast.thoughtbot.com/20 + af2343b2-5c16-4c52-a682-67adee496795 + Fri, 02 Nov 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + In this special episode from RubyConf 2012 we pulled aside some of the attendees and found out what they're working on. We also include a selection of the great lightning talks at the conference. Enjoy! + + + 33:54 + no + + <p>In this special episode from RubyConf 2012 we pulled aside some of the attendees and found out what they're working on. We also include a selection of the great lightning talks at the conference. Enjoy!</p> +<ul> +<li><a href="http://blog.robmack.com/">Rob Mack</a> from <a href="http://spiceworks.com">Spiceworks</a></li> +<li><a href="http://drnicwilliams.com/">Dr. Nic Williams</a> from <a href="http://engineyard.com">Engine Yard</a> talks about <a href="https://github.com/cloudfoundry/bosh">BOSH</a></li> +<li><a href="http://rayhightower.com/">Ray Hightower</a> from <a href="http://wisdomgroup.com/">WisdomGroup</a>, <a href="http://windycityrails.org/">WindyCityRails</a>, and <a href="http://chicagoruby.org/">ChicagoRuby</a></li> +<li><a href="http://www.noelrappin.com/">Noel Rapin</a> from <a href="http://groupon.com">Groupon</a></li> +<li><a href="http://jfoley.github.com/">John Foley</a> and <a href="http://blog.baroquebobcat.com/">Nick Howard</a> talk about <a href="http://www.projectgrok.com/">Project Grok</a>, an Open Source Code Reader Club (like a book club, but for code)</li> +<li><a href="http://brixen.io/">Brian Ford</a> from <a href="http://engineyard.com">Engine Yard</a> talks about <a href="http://rubini.us/">Rubinious</a> 2.0-rc1.</li> +<li><a href="https://twitter.com/j3">Jeff Casimir</a> from <a href="http://jumpstartlab.com/">JumpstartLab</a> talks about <a href="http://www.gschool.it/">gSchool</a></li> +<li><a href="http://verboselogging.com/">Daniel Huckstep</a> from <a href="http://getyardstick.com/">Yardstick Software</a> talks about rc files and <a href="https://github.com/37signals/sub">sub</a>.</li> +<li><a href="http://haven.loki.ws/">Joshua Szmajda</a> talks about the <a href="http://www.therubyhangout.com/">Ruby Hangout</a>, an online Ruby meetup.</li> +<li><a href="http://deadprogrammersociety.com/">Ron Evans</a> from <a href="http://hybridgroup.com/">The Hybrid Group</a> talks about <a href="https://github.com/hybridgroup/gitnesse">gitnesse</a> and wields a mean ukulele.</li> +<li><a href="https://github.com/xn">Christian Trosclair</a> from <a href="http://hybridgroup.com/">The Hybrid Group</a> talks about Kids Code Camp and <a href="http://featurecreep.io">FeatureCreep</a></li> +<li><a href="http://schneems.com/">Richard Schneeman</a> from <a href="http://heroku.com">Heroku</a> talks about <a href="http://issuetriage.heroku.com">Issue Triage</a>.</li> +<li><a href="https://github.com/tyre">Chris Maddox</a> from <a href="http://livingsocial.com">LivingSocial</a> talks about happiness.</li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a> and <a href="http://twitter.com/rubyconf">@rubyconf</a> on twitter.</p> + + + + In this special episode from RubyConf 2012 we pulled aside some of the attendees and found out what they're working on. We also include a selection of the great lightning talks at the conference. Enjoy!

+ + + +

Follow @thoughtbot and @rubyconf on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + In this special episode from RubyConf 2012 we pulled aside some of the attendees and found out what they're working on. We also include a selection of the great lightning talks at the conference. Enjoy!

+ + + +

Follow @thoughtbot and @rubyconf on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+-ufrhkRw + + ]]> + + + + 19: I have tons of guns and knives + https://podcast.thoughtbot.com/19 + aad19bc4-b7a0-45c4-beb4-b17bfd3b85fc + Wed, 31 Oct 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Aaron Patterson, Ruby Core team member, Rails Core team member, and a Señior Software Engineer at AT&T Interactive. Aaron and Ben discuss the upcoming features and excitement for Ruby 2.0 and some things Aaron would like to see in Ruby in the future that didn't quite make it into Ruby 2.0. They also discuss how the Rails Core team differs from the Ruby Core team, how much effort it takes to write a detailed blog post and how many mistakes are involved, how he likes being a ruby celebrity, his involvement in Seattle.rb and what it teaches him. Finally, how awesome his job is and how he could do it forever, how he worries about Ruby or Rails becoming irrelevant and wants to stop that from happening, how he is happy all the time, and if he could wave a magic wand and change one thing about Rails, what it would be. This and so much more in this entertaining episode recorded at RubyConf 2012. + + + 38:38 + no + + <p>Ben Orenstein is joined by Aaron Patterson, Ruby Core team member, Rails Core team member, and a Señior Software Engineer at AT&amp;T Interactive. Aaron and Ben discuss the upcoming features and excitement for Ruby 2.0 and some things Aaron would like to see in Ruby in the future that didn't quite make it into Ruby 2.0. They also discuss how the Rails Core team differs from the Ruby Core team, how much effort it takes to write a detailed blog post and how many mistakes are involved, how he likes being a ruby celebrity, his involvement in Seattle.rb and what it teaches him. Finally, how awesome his job is and how he could do it forever, how he worries about Ruby or Rails becoming irrelevant and wants to stop that from happening, how he is happy all the time, and if he could wave a magic wand and change one thing about Rails, what it would be. This and so much more in this entertaining episode recorded at RubyConf 2012.</p> +<ul> +<li><a href="http://tenderlovemaking.com/">Tender Lovemaking</a></li> +<li><a href="http://www.seattlerb.org/">Seattle.rb</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/tenderlove">@tenderlove</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Aaron Patterson, Ruby Core team member, Rails Core team member, and a Señior Software Engineer at AT&T Interactive. Aaron and Ben discuss the upcoming features and excitement for Ruby 2.0 and some things Aaron would like to see in Ruby in the future that didn't quite make it into Ruby 2.0. They also discuss how the Rails Core team differs from the Ruby Core team, how much effort it takes to write a detailed blog post and how many mistakes are involved, how he likes being a ruby celebrity, his involvement in Seattle.rb and what it teaches him. Finally, how awesome his job is and how he could do it forever, how he worries about Ruby or Rails becoming irrelevant and wants to stop that from happening, how he is happy all the time, and if he could wave a magic wand and change one thing about Rails, what it would be. This and so much more in this entertaining episode recorded at RubyConf 2012.

+ + + +

Follow @thoughtbot, @tenderlove, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Aaron Patterson, Ruby Core team member, Rails Core team member, and a Señior Software Engineer at AT&T Interactive. Aaron and Ben discuss the upcoming features and excitement for Ruby 2.0 and some things Aaron would like to see in Ruby in the future that didn't quite make it into Ruby 2.0. They also discuss how the Rails Core team differs from the Ruby Core team, how much effort it takes to write a detailed blog post and how many mistakes are involved, how he likes being a ruby celebrity, his involvement in Seattle.rb and what it teaches him. Finally, how awesome his job is and how he could do it forever, how he worries about Ruby or Rails becoming irrelevant and wants to stop that from happening, how he is happy all the time, and if he could wave a magic wand and change one thing about Rails, what it would be. This and so much more in this entertaining episode recorded at RubyConf 2012.

+ + + +

Follow @thoughtbot, @tenderlove, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+dCqdCIgt + + ]]> + + + + 18: Trading Hours for Money + https://podcast.thoughtbot.com/18 + 1a3995c5-a00e-402b-8165-1a6a5b3fb8cc + Sun, 28 Oct 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Brennan Dunn, author of double your freelancing rate and planscope.io. Ben and Brennan discuss transitioning from a freelancer to a consulting company, the issues he faced doing it, and how he overcame them. How he promoted someone to replace him in his consulting company and is focused exclusively on products now, where Planscope came from, how it works, and how he more than doubled the conversion rate. How content marketing was slow to work for him, and how he fixed it. How to effectively pitch and sell products, what victory looks like for him and what he's working for, and so much more. + + + 39:37 + no + + <p>Ben Orenstein is joined by Brennan Dunn, author of double your freelancing rate and planscope.io. Ben and Brennan discuss transitioning from a freelancer to a consulting company, the issues he faced doing it, and how he overcame them. How he promoted someone to replace him in his consulting company and is focused exclusively on products now, where Planscope came from, how it works, and how he more than doubled the conversion rate. How content marketing was slow to work for him, and how he fixed it. How to effectively pitch and sell products, what victory looks like for him and what he's working for, and so much more.</p> +<ul> +<li><a href="http://doubleyourfreelancingrate.com/">Double Your Freelancing Rate in 14 Days</a></li> +<li><a href="https://planscope.io/">Planscope, Project Management for Independents</a></li> +<li><a href="http://www.kalzumeus.com/2012/10/10/kalzumeus-podcast-3-growing-consulting-practices-with-brennan-dunn/">Kalzumeus Podcast 3: Growing Consulting Practices, with Brennan Dunn</a></li> +<li><a href="http://doubleyourfreelancingrate.com/build-a-consultancy">Workshop: Start Your Own Multi-Million Dollar Consultancy</a></li> +<li><a href="http://www.iwillteachyoutoberich.com/home/">Ramit Sethi, I Will Teach You To Be Rich</a></li> +<li><a href="http://www.amazon.com/gp/product/0473175045/ref=as_li_ss_tl?ie=UTF8&amp;camp=1789&amp;creative=390957&amp;creativeASIN=0473175045&amp;linkCode=as2&amp;tag=giantrobotssm-20">The Brain Audit: Why Customers Buy (And Why They Don't)</a></li> +<li><a href="http://www.bidsketch.com/">Bidsketch</a></li> +<li><a href="http://letsfreckle.com/">Freckle</a></li> +<li><a href="http://www.microconf.com/">MicroConf</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/brennandunn">@brennandunn</a> on twitter.</p> + + + + Ben Orenstein is joined by Brennan Dunn, author of double your freelancing rate and planscope.io. Ben and Brennan discuss transitioning from a freelancer to a consulting company, the issues he faced doing it, and how he overcame them. How he promoted someone to replace him in his consulting company and is focused exclusively on products now, where Planscope came from, how it works, and how he more than doubled the conversion rate. How content marketing was slow to work for him, and how he fixed it. How to effectively pitch and sell products, what victory looks like for him and what he's working for, and so much more.

+ + + +

Follow @thoughtbot, @r00k, and @brennandunn on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Brennan Dunn, author of double your freelancing rate and planscope.io. Ben and Brennan discuss transitioning from a freelancer to a consulting company, the issues he faced doing it, and how he overcame them. How he promoted someone to replace him in his consulting company and is focused exclusively on products now, where Planscope came from, how it works, and how he more than doubled the conversion rate. How content marketing was slow to work for him, and how he fixed it. How to effectively pitch and sell products, what victory looks like for him and what he's working for, and so much more.

+ + + +

Follow @thoughtbot, @r00k, and @brennandunn on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+K_C-8O9A + + ]]> + + + + 17: I'm feeling full and Sassy + https://podcast.thoughtbot.com/17 + 07560bc1-d4cf-43ce-95cd-b3e2ad19664e + Sun, 21 Oct 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Kyle Fiedler, a designer at thoughtbot, and one of the creators of Bourbon Neat. Ben and Kyle discuss responsive design, what it is, and how to implement it. They also discuss Bourbon (a library of Sass mixins) and Neat (a fluid grid framework based on Bourbon), what's wrong with Twitter Bootstrap and why Bourbon Neat is better, and the other reasons why Bourbon Neat was created despite all the other grid frameworks that are available. Kyle shares the most common design mistakes he sees developers make in projects, whether or not design is subjective or whether it can be more objective, his design process and how it has changed, what the Golden Ratio is, and how it's used in Neat. Finally, they also discuss the Design for Developers workshop offered by thoughtbot, which teaches the fundamental design principles and tools to developers, and much, much more. + + + 25:28 + no + + <p>Ben Orenstein is joined by Kyle Fiedler, a designer at thoughtbot, and one of the creators of Bourbon Neat. Ben and Kyle discuss responsive design, what it is, and how to implement it. They also discuss Bourbon (a library of Sass mixins) and Neat (a fluid grid framework based on Bourbon), what's wrong with Twitter Bootstrap and why Bourbon Neat is better, and the other reasons why Bourbon Neat was created despite all the other grid frameworks that are available. Kyle shares the most common design mistakes he sees developers make in projects, whether or not design is subjective or whether it can be more objective, his design process and how it has changed, what the Golden Ratio is, and how it's used in Neat. Finally, they also discuss the Design for Developers workshop offered by thoughtbot, which teaches the fundamental design principles and tools to developers, and much, much more.</p> +<ul> +<li><a href="http://thoughtbot.com/bourbon/">Bourbon</a></li> +<li><a href="http://thoughtbot.com/neat/">Bourbon Neat</a></li> +<li><a href="http://sass-lang.com/">Sass</a></li> +<li><a href="https://learn.thoughtbot.com/courses/2-design-for-developers">Design for Developers</a></li> +<li><a href="http://en.wikipedia.org/wiki/Golden_ratio">Golden ratio</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/kylefiedler">@kylefiedler</a> on twitter.</p> + + + + Ben Orenstein is joined by Kyle Fiedler, a designer at thoughtbot, and one of the creators of Bourbon Neat. Ben and Kyle discuss responsive design, what it is, and how to implement it. They also discuss Bourbon (a library of Sass mixins) and Neat (a fluid grid framework based on Bourbon), what's wrong with Twitter Bootstrap and why Bourbon Neat is better, and the other reasons why Bourbon Neat was created despite all the other grid frameworks that are available. Kyle shares the most common design mistakes he sees developers make in projects, whether or not design is subjective or whether it can be more objective, his design process and how it has changed, what the Golden Ratio is, and how it's used in Neat. Finally, they also discuss the Design for Developers workshop offered by thoughtbot, which teaches the fundamental design principles and tools to developers, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @kylefiedler on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Kyle Fiedler, a designer at thoughtbot, and one of the creators of Bourbon Neat. Ben and Kyle discuss responsive design, what it is, and how to implement it. They also discuss Bourbon (a library of Sass mixins) and Neat (a fluid grid framework based on Bourbon), what's wrong with Twitter Bootstrap and why Bourbon Neat is better, and the other reasons why Bourbon Neat was created despite all the other grid frameworks that are available. Kyle shares the most common design mistakes he sees developers make in projects, whether or not design is subjective or whether it can be more objective, his design process and how it has changed, what the Golden Ratio is, and how it's used in Neat. Finally, they also discuss the Design for Developers workshop offered by thoughtbot, which teaches the fundamental design principles and tools to developers, and much, much more.

+ + + +

Follow @thoughtbot, @r00k, and @kylefiedler on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+RX-ET1yM + + ]]> + + + + 16: Making it fast + https://podcast.thoughtbot.com/16 + eccf1329-320a-46d6-a3e3-428d0c0a0c93 + Sun, 14 Oct 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by William Josephson and Jay Moorthi from Solano Labs, the makers of tddium, the hosted, scalable continuous integration service. They discuss the architecture of the service, including how they're using Go to speed up parts of it, the surprises they've had in getting started, how they've gotten involved in the Ruby community, and how they validated their idea and get feedback from customers. Also, their experience working with thoughtbot, what has worked and not worked for driving public customers to the site and converting them, dealing with privacy, customer support, their goals and their growth plans, and much more. + + + 35:29 + no + + <p>Ben Orenstein is joined by William Josephson and Jay Moorthi from Solano Labs, the makers of tddium, the hosted, scalable continuous integration service. They discuss the architecture of the service, including how they're using Go to speed up parts of it, the surprises they've had in getting started, how they've gotten involved in the Ruby community, and how they validated their idea and get feedback from customers. Also, their experience working with thoughtbot, what has worked and not worked for driving public customers to the site and converting them, dealing with privacy, customer support, their goals and their growth plans, and much more.</p> +<ul> +<li><a href="https://www.tddium.com/">tddium</a> (Solano Labs)</li> +<li><a href="http://code.google.com/p/go/">Go</a></li> +<li><a href="http://rubyeventmachine.com/">eventmachine</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/tddium">@tddium</a> on twitter.</p> + + + + Ben Orenstein is joined by William Josephson and Jay Moorthi from Solano Labs, the makers of tddium, the hosted, scalable continuous integration service. They discuss the architecture of the service, including how they're using Go to speed up parts of it, the surprises they've had in getting started, how they've gotten involved in the Ruby community, and how they validated their idea and get feedback from customers. Also, their experience working with thoughtbot, what has worked and not worked for driving public customers to the site and converting them, dealing with privacy, customer support, their goals and their growth plans, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @tddium on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by William Josephson and Jay Moorthi from Solano Labs, the makers of tddium, the hosted, scalable continuous integration service. They discuss the architecture of the service, including how they're using Go to speed up parts of it, the surprises they've had in getting started, how they've gotten involved in the Ruby community, and how they validated their idea and get feedback from customers. Also, their experience working with thoughtbot, what has worked and not worked for driving public customers to the site and converting them, dealing with privacy, customer support, their goals and their growth plans, and much more.

+ + + +

Follow @thoughtbot, @r00k, and @tddium on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+IH54wba0 + + ]]> + + + + 15: Moving money should be free + https://podcast.thoughtbot.com/15 + 31348031-3151-4507-aecf-92d19514879b + Sun, 07 Oct 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Seth Priebatsch, creator of SCVNGR and LevelUp. Ben and Seth talk about LevelUp, how it got started, how they make money, and what the future holds. They also discuss his daily schedule, maintaining focus, what he worries about, how your motives can limit your success, how to change the world by choosing the right thing to change, why he stopped hiding doubt and started being more transparent, and much, much more, including the most interesting question he's never been asked. + + + 43:34 + no + + <p>Ben Orenstein is joined by Seth Priebatsch, creator of SCVNGR and LevelUp. Ben and Seth talk about LevelUp, how it got started, how they make money, and what the future holds. They also discuss his daily schedule, maintaining focus, what he worries about, how your motives can limit your success, how to change the world by choosing the right thing to change, why he stopped hiding doubt and started being more transparent, and much, much more, including the most interesting question he's never been asked.</p> +<ul> +<li><a href="http://www.scvngr.com/">SCVNGR</a></li> +<li><a href="https://www.thelevelup.com/">LevelUp</a></li> +<li><a href="http://www.ted.com/talks/seth_priebatsch_the_game_layer_on_top_of_the_world.html">TEDX Talks, &quot;Seth Priebatsch: The game layer on top of the world&quot;</a></li> +<li><a href="http://www.ted.com/talks/iain_hutchison_saving_faces.html">TED Talks, &quot;Iain Hutchison: Saving faces&quot;</a></li> +<li><a href="http://www.paywithisis.com/">Isis mobile wallet</a></li> +<li><a href="http://www.rtbrelay.com/">Reach the Beach Relay</a></li> +<li><a href="http://www.spartanrace.com/vermont-obstacle-racing-super-spartan.html">Killington Spartan Race</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/sethpriebatsch">@sethpriebatsch</a> on twitter.</p> + + + + Ben Orenstein is joined by Seth Priebatsch, creator of SCVNGR and LevelUp. Ben and Seth talk about LevelUp, how it got started, how they make money, and what the future holds. They also discuss his daily schedule, maintaining focus, what he worries about, how your motives can limit your success, how to change the world by choosing the right thing to change, why he stopped hiding doubt and started being more transparent, and much, much more, including the most interesting question he's never been asked.

+ + + +

Follow @thoughtbot, @r00k, and @sethpriebatsch on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Seth Priebatsch, creator of SCVNGR and LevelUp. Ben and Seth talk about LevelUp, how it got started, how they make money, and what the future holds. They also discuss his daily schedule, maintaining focus, what he worries about, how your motives can limit your success, how to change the world by choosing the right thing to change, why he stopped hiding doubt and started being more transparent, and much, much more, including the most interesting question he's never been asked.

+ + + +

Follow @thoughtbot, @r00k, and @sethpriebatsch on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YQyoz_rd + + ]]> + + + + 14: Say goodbye to that big guy + https://podcast.thoughtbot.com/14 + 5def7271-1309-4c6e-baaf-c43c1cacf13b + Sun, 30 Sep 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Prem Sichanugrist, a developer at thoughtbot and the #31 top Rails contributor. Ben and Prem walk through the major changes that will be introduced in Rails 4, including strong parameters, the new built in queue, cache\_digest, changes in ActiveRecord::Relation, and ActiveResource. The also discuss what people can do to ease contribution and issue submission to Rails, how can people get their first commit into Rails, and much more. + + + 30:37 + no + + <p>Ben Orenstein is joined by Prem Sichanugrist, a developer at thoughtbot and the #31 top Rails contributor. Ben and Prem walk through the major changes that will be introduced in Rails 4, including strong parameters, the new built in queue, cache_digest, changes in ActiveRecord::Relation, and ActiveResource. The also discuss what people can do to ease contribution and issue submission to Rails, how can people get their first commit into Rails, and much more.</p> +<ul> +<li><a href="http://bostonrb.org/presentations/what-to-expect-in-rails-40">Prems Boston.rb talk and video: What to Expect in Rails 4.0</a></li> +<li><a href="https://github.com/rails/strong_parameters">strong_parameters</a></li> +<li><a href="http://corelib.rubyonrails.org/classes/Queue.html">Queue</a></li> +<li><a href="https://github.com/rails/cache_digests">cache_digests</a></li> +<li><a href="http://en.wikipedia.org/wiki/Matryoshka_doll">Russian (Matryoshka) doll</a></li> +<li><a href="http://basecamp.com/">Basecamp next</a></li> +<li><a href="http://37signals.com/svn/posts/3090-basecamp-nexts-caching-hardware">Basecamp next RAM and caching hardware</a></li> +<li><a href="http://api.rubyonrails.org/classes/ActiveRecord/Relation.html">ActiveRecord::Relation</a></li> +<li><a href="http://en.wikipedia.org/wiki/Null_Object_pattern">Null Object pattern</a></li> +<li><a href="http://c2.com/cgi/wiki?TellDontAsk">Tell Don't Ask</a></li> +<li><a href="https://github.com/rails/activeresource">ActiveResource</a></li> +<li><a href="https://github.com/rails/rails/commit/82dd725fc195eb52eea9cbde9530ab9dff122e32">Prem's first commit to Rails</a></li> +<li><a href="https://github.com/lifo/docrails">docrails</a></li> +<li><a href="http://guides.rubyonrails.org/">Ruby on Rails Guides</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/sikachu">@sikachu</a> on twitter.</p> + + + + Ben Orenstein is joined by Prem Sichanugrist, a developer at thoughtbot and the #31 top Rails contributor. Ben and Prem walk through the major changes that will be introduced in Rails 4, including strong parameters, the new built in queue, cache_digest, changes in ActiveRecord::Relation, and ActiveResource. The also discuss what people can do to ease contribution and issue submission to Rails, how can people get their first commit into Rails, and much more.

+ + + +

Follow @thoughtbot, @sikachu on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Prem Sichanugrist, a developer at thoughtbot and the #31 top Rails contributor. Ben and Prem walk through the major changes that will be introduced in Rails 4, including strong parameters, the new built in queue, cache_digest, changes in ActiveRecord::Relation, and ActiveResource. The also discuss what people can do to ease contribution and issue submission to Rails, how can people get their first commit into Rails, and much more.

+ + + +

Follow @thoughtbot, @sikachu on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mlFdEJyb + + ]]> + + + + 13: I'll disagree in just a little bit + https://podcast.thoughtbot.com/13 + ba30ccdd-9e0c-4cce-bed3-9765fa1830bd + Sun, 23 Sep 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot, and Josh Clayton, developer at thoughtbot and the lead maintainer of FactoryGirl. In this Rails focused episode, Ben, Joe, and Josh dish on ActiveRecord callbacks, observers, state machines, and before\_filters vs. middleware. They discuss the good, the bad, and the ugly of each, and how to keep your app clean while doing the right thing. Then they touch on what's new in FactoryGirl, how using build\_stubbed can speed up your test suite, and much more. + + + 30:01 + no + + <p>Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot, and Josh Clayton, developer at thoughtbot and the lead maintainer of FactoryGirl. In this Rails focused episode, Ben, Joe, and Josh dish on ActiveRecord callbacks, observers, state machines, and before_filters vs. middleware. They discuss the good, the bad, and the ugly of each, and how to keep your app clean while doing the right thing. Then they touch on what's new in FactoryGirl, how using build_stubbed can speed up your test suite, and much more.</p> +<ul> +<li><a href="http://guides.rubyonrails.org/active_record_validations_callbacks.html">Rails Guide: Active Record Validations and Callbacks</a></li> +<li><a href="http://guides.rubyonrails.org/action_controller_overview.html#filters">Rails Guide: Action Controller, Filters</a></li> +<li><a href="http://robots.thoughtbot.com/post/29001852185/ruby-and-kiss-sitting-in-a-tree">Blog post: Ruby and KISS, Sitting in a Tree</a></li> +<li><a href="http://c2.com/cgi/wiki?MethodObject">Method Object</a></li> +<li><a href="http://sourcemaking.com/refactoring/feature-envy">Feature Envy</a></li> +<li><a href="http://rack.github.com/">Rack: a Ruby Webserver Interface</a></li> +<li><a href="http://guides.rubyonrails.org/rails_on_rack.html">Rails Guide: Rails on Rack</a></li> +<li><a href="http://rtomayko.github.com/rack-cache/">Rack::Cache</a></li> +<li><a href="http://robots.thoughtbot.com/post/22670085288/use-factory-girls-build-stubbed-for-a-faster-test">Blog post: Use Factory Girl’s build_stubbed for a Faster Test Suite</a></li> +<li><a href="http://robots.thoughtbot.com/post/28146418628/mind-bending-factories">Blog post: Mind-Bending Factories</a></li> +<li><a href="http://speakerrate.com/talks/12961">Metaprogramming in the Wild: Source-Diving FactoryGirl</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/joeferris">@joeferris</a>, and <a href="https://twitter.com/joshuaclayton">@joshuaclayton</a> on twitter.</p> + + + + Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot, and Josh Clayton, developer at thoughtbot and the lead maintainer of FactoryGirl. In this Rails focused episode, Ben, Joe, and Josh dish on ActiveRecord callbacks, observers, state machines, and before_filters vs. middleware. They discuss the good, the bad, and the ugly of each, and how to keep your app clean while doing the right thing. Then they touch on what's new in FactoryGirl, how using build_stubbed can speed up your test suite, and much more.

+ + + +

Follow @thoughtbot, @joeferris, and @joshuaclayton on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Joe Ferris, CTO of thoughtbot, and Josh Clayton, developer at thoughtbot and the lead maintainer of FactoryGirl. In this Rails focused episode, Ben, Joe, and Josh dish on ActiveRecord callbacks, observers, state machines, and before_filters vs. middleware. They discuss the good, the bad, and the ugly of each, and how to keep your app clean while doing the right thing. Then they touch on what's new in FactoryGirl, how using build_stubbed can speed up your test suite, and much more.

+ + + +

Follow @thoughtbot, @joeferris, and @joshuaclayton on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+BvHwyfXL + + ]]> + + + + 12: I think I'll be on a yacht + https://podcast.thoughtbot.com/12 + 0f368e09-aa6e-4621-821d-62f414523844 + Sun, 16 Sep 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Matt Jankowski, COO of thoughtbot. Ben and Matt start off by talking about how Matt came to join thoughtbot and his role at the company. They then discuss the typical thoughtbot sales process. How all problems are communication problems. How the way thoughtbot works is appealing to startups and how they hear about thoughtbot. How thoughtbot handles its 20% investment time in open source and our own products, how we preserve that despite trying to grow the business, and how that has evolved over time. The reasons why it's not always possible to work faster by increasing the team size. Goals, metrics, and things thoughtbot can do better. Plus, how project management techniques translate to child-rearing, his standing desk, and much more. + + + 38:26 + no + + <p>Ben Orenstein is joined by Matt Jankowski, COO of thoughtbot. Ben and Matt start off by talking about how Matt came to join thoughtbot and his role at the company. They then discuss the typical thoughtbot sales process. How all problems are communication problems. How the way thoughtbot works is appealing to startups and how they hear about thoughtbot. How thoughtbot handles its 20% investment time in open source and our own products, how we preserve that despite trying to grow the business, and how that has evolved over time. The reasons why it's not always possible to work faster by increasing the team size. Goals, metrics, and things thoughtbot can do better. Plus, how project management techniques translate to child-rearing, his standing desk, and much more.</p> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="https://twitter.com/jankowski">@jankowski</a> on twitter.</p> + + + + Ben Orenstein is joined by Matt Jankowski, COO of thoughtbot. Ben and Matt start off by talking about how Matt came to join thoughtbot and his role at the company. They then discuss the typical thoughtbot sales process. How all problems are communication problems. How the way thoughtbot works is appealing to startups and how they hear about thoughtbot. How thoughtbot handles its 20% investment time in open source and our own products, how we preserve that despite trying to grow the business, and how that has evolved over time. The reasons why it's not always possible to work faster by increasing the team size. Goals, metrics, and things thoughtbot can do better. Plus, how project management techniques translate to child-rearing, his standing desk, and much more.

+ +

Follow @thoughtbot, @r00k, and @jankowski on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Matt Jankowski, COO of thoughtbot. Ben and Matt start off by talking about how Matt came to join thoughtbot and his role at the company. They then discuss the typical thoughtbot sales process. How all problems are communication problems. How the way thoughtbot works is appealing to startups and how they hear about thoughtbot. How thoughtbot handles its 20% investment time in open source and our own products, how we preserve that despite trying to grow the business, and how that has evolved over time. The reasons why it's not always possible to work faster by increasing the team size. Goals, metrics, and things thoughtbot can do better. Plus, how project management techniques translate to child-rearing, his standing desk, and much more.

+ +

Follow @thoughtbot, @r00k, and @jankowski on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+G5E2DLOh + + ]]> + + + + 11: You want your system to bend, not to break + https://podcast.thoughtbot.com/11 + 3db61091-8abc-4713-94e6-c422ef159078 + Sun, 09 Sep 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Sean Cribbs, Software Engineer at Basho, the makers of Riak. Ben and Sean start off discussing the interesting overlap of programmers and musicians and why it seems to happen so much. They then discuss Sean's role at Basho, what Riak is, how it works, and how it differs from other NoSQL databases. Sean works remotely for Basho, which has several offices, so Ben and Sean discuss remote workers and remote offices, and the ins and outs of navigating that set up, and how he got paid to work on open source. Finally, they discuss Erlang, which most of Riak is written in. These topics, plus much more. + + + 54:24 + no + + <p>Ben Orenstein is joined by Sean Cribbs, Software Engineer at Basho, the makers of Riak. Ben and Sean start off discussing the interesting overlap of programmers and musicians and why it seems to happen so much. They then discuss Sean's role at Basho, what Riak is, how it works, and how it differs from other NoSQL databases. Sean works remotely for Basho, which has several offices, so Ben and Sean discuss remote workers and remote offices, and the ins and outs of navigating that set up, and how he got paid to work on open source. Finally, they discuss Erlang, which most of Riak is written in. These topics, plus much more.</p> +<ul> +<li><a href="http://en.wikipedia.org/wiki/Corpus_callosum">Corpus callosum</a></li> +<li><a href="http://basho.com/products/riak-overview/">Riak Overview</a></li> +<li><a href="http://basho.com/">Basho</a></li> +<li><a href="https://github.com/basho/riak-ruby-client">Ruby client for Riak</a></li> +<li><a href="http://www.read.seas.harvard.edu/%7Ekohler/class/cs239-w08/decandia07dynamo.pdf">Dynamo: Amazon’s Highly Available Key-value Store</a> - PDF</li> +<li><a href="http://en.wikipedia.org/wiki/Eventual_consistency">Eventual consistency</a></li> +<li><a href="http://wiki.basho.com/Riak-Glossary.html#Read-Repair">Riak: Read Repair</a></li> +<li><a href="http://en.wikipedia.org/wiki/Glossary_of_BitTorrent_terms#Swarm">BitTorrent Swarms</a></li> +<li><a href="http://en.wikipedia.org/wiki/Distributed_hash_table">Distributed hash table</a></li> +<li><a href="http://wiki.basho.com/Riak-Glossary.html#Ring">Riak: Ring</a></li> +<li><a href="http://wiki.basho.com/Riak-Glossary.html#Gossiping">Riak: Gossiping</a></li> +<li><a href="http://cassandra.apache.org/">Cassandra</a></li> +<li><a href="http://www.project-voldemort.com/voldemort/">Project Voldemort</a></li> +<li><a href="https://thestrangeloop.com/">Strangeloop, Sept 23-25, 2012</a></li> +<li><a href="http://basho.com/community/ricon2012/">RICON, Oct 10-11, 2012</a></li> +<li><a href="http://seancribbs.com/tech/2010/02/06/why-riak-should-power-your-next-rails-app/">Why Riak</a></li> +<li><a href="http://www.erlang.org/">Erlang Programming Language</a></li> +<li><a href="http://pragprog.com/screencasts/v-kserl/erlang-in-practice">Pragmatic Programmers: Erlang in Practice screencast</a></li> +<li><a href="http://www.erlang.org/doc/man/dialyzer.html">Erlang: dialyzer</a></li> +<li><a href="http://rubygems.org/gems/laser">Ruby laser</a></li> +<li><a href="http://pragprog.com/book/jaerlang/programming-erlang">Programming Erlang: Software for a Concurrent World</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="https://twitter.com/seancribbs">@seancribbs</a> on twitter.</p> + + + + Ben Orenstein is joined by Sean Cribbs, Software Engineer at Basho, the makers of Riak. Ben and Sean start off discussing the interesting overlap of programmers and musicians and why it seems to happen so much. They then discuss Sean's role at Basho, what Riak is, how it works, and how it differs from other NoSQL databases. Sean works remotely for Basho, which has several offices, so Ben and Sean discuss remote workers and remote offices, and the ins and outs of navigating that set up, and how he got paid to work on open source. Finally, they discuss Erlang, which most of Riak is written in. These topics, plus much more.

+ + + +

Follow @thoughtbot, @r00k, and @seancribbs on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Sean Cribbs, Software Engineer at Basho, the makers of Riak. Ben and Sean start off discussing the interesting overlap of programmers and musicians and why it seems to happen so much. They then discuss Sean's role at Basho, what Riak is, how it works, and how it differs from other NoSQL databases. Sean works remotely for Basho, which has several offices, so Ben and Sean discuss remote workers and remote offices, and the ins and outs of navigating that set up, and how he got paid to work on open source. Finally, they discuss Erlang, which most of Riak is written in. These topics, plus much more.

+ + + +

Follow @thoughtbot, @r00k, and @seancribbs on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+mZ0iMHZP + + ]]> + + + + 10: Isn't the last stage of grieving acceptance? + https://podcast.thoughtbot.com/10 + 18ae90fc-5e92-4ec6-93bc-50dcfe8aaf5c + Sun, 02 Sep 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Joe Ferris and Mike Burns. They start off with some recommendations for awesome programming books and then dive right in to questions about not following "Tell don't ask" in the view, how MVC and the Single Responsibility Principle may be at odds with "Tell don't ask" in the view, and what a more object oriented approach may look like. They also discuss "Class-oriented programming", what it is, why it is bad, how Rails does it, and how to avoid it. They take a quick trip through Mike's experiments in Ruby and Smalltalk in creating his own programming language. The three codecateers then take on the really important topic of method order and code organization, and finally they reflect on how their code has changed over the years, how no solution is foolproof, and how to move to the next level as a programmer. These topics and more, in this installment of the GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS podcast! + + + 43:03 + no + + <p>Ben Orenstein is joined by Joe Ferris and Mike Burns. They start off with some recommendations for awesome programming books and then dive right in to questions about not following &quot;Tell don't ask&quot; in the view, how MVC and the Single Responsibility Principle may be at odds with &quot;Tell don't ask&quot; in the view, and what a more object oriented approach may look like. They also discuss &quot;Class-oriented programming&quot;, what it is, why it is bad, how Rails does it, and how to avoid it. They take a quick trip through Mike's experiments in Ruby and Smalltalk in creating his own programming language. The three codecateers then take on the really important topic of method order and code organization, and finally they reflect on how their code has changed over the years, how no solution is foolproof, and how to move to the next level as a programmer. These topics and more, in this installment of the GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS podcast!</p> +<ul> +<li><a href="http://mitpress.mit.edu/sicp/">Structure and Interpretation of Computer Programs</a></li> +<li><a href="http://mitpress.mit.edu/sicp/course.html">MIT course that everyone failed</a></li> +<li><a href="http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627">Growing Object-Oriented Software, Guided by Tests</a></li> +<li><a href="http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882">Clean Code: A Handbook of Agile Software Craftsmanship</a></li> +<li><a href="http://c2.com/cgi/wiki?TellDontAsk">Tell Don't Ask</a></li> +<li><a href="http://en.wikipedia.org/wiki/Single_responsibility_principle">Single Responsibility Principle</a></li> +<li><a href="http://en.wikipedia.org/wiki/Shotgun_surgery">Shotgun Surgery</a></li> +<li><a href="http://www.squeak.org/">Smalltalk, Squeak</a></li> +<li><a href="http://www.playframework.org/">Scala, Play framework</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/joeferris">@joeferris</a>, <a href="https://twitter.com/mikeburns">@mikeburns</a> on twitter.</p> + + + + Ben Orenstein is joined by Joe Ferris and Mike Burns. They start off with some recommendations for awesome programming books and then dive right in to questions about not following "Tell don't ask" in the view, how MVC and the Single Responsibility Principle may be at odds with "Tell don't ask" in the view, and what a more object oriented approach may look like. They also discuss "Class-oriented programming", what it is, why it is bad, how Rails does it, and how to avoid it. They take a quick trip through Mike's experiments in Ruby and Smalltalk in creating his own programming language. The three codecateers then take on the really important topic of method order and code organization, and finally they reflect on how their code has changed over the years, how no solution is foolproof, and how to move to the next level as a programmer. These topics and more, in this installment of the GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS podcast!

+ + + +

Follow @thoughtbot, @r00k, @joeferris, @mikeburns on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Joe Ferris and Mike Burns. They start off with some recommendations for awesome programming books and then dive right in to questions about not following "Tell don't ask" in the view, how MVC and the Single Responsibility Principle may be at odds with "Tell don't ask" in the view, and what a more object oriented approach may look like. They also discuss "Class-oriented programming", what it is, why it is bad, how Rails does it, and how to avoid it. They take a quick trip through Mike's experiments in Ruby and Smalltalk in creating his own programming language. The three codecateers then take on the really important topic of method order and code organization, and finally they reflect on how their code has changed over the years, how no solution is foolproof, and how to move to the next level as a programmer. These topics and more, in this installment of the GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS podcast!

+ + + +

Follow @thoughtbot, @r00k, @joeferris, @mikeburns on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+hZzYuFSh + + ]]> + + + + 9: TDD for Business!! + https://podcast.thoughtbot.com/9 + 4daa4169-4eae-4992-9aac-1380bde78e4d + Thu, 23 Aug 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Chad Pytel, the CEO and Founder of thoughtbot. Ben and Chad talk about the history of thoughtbot, success, failures, lessons learned, the current growth plans for the company, and much more. They also answer listener questions about hiring, growing, balancing client and internal work like open source and products, and contractor rates and how to set them. + + + 50:19 + no + + <p>Ben Orenstein is joined by Chad Pytel, the CEO and Founder of thoughtbot. Ben and Chad talk about the history of thoughtbot, success, failures, lessons learned, the current growth plans for the company, and much more. They also answer listener questions about hiring, growing, balancing client and internal work like open source and products, and contractor rates and how to set them.</p> +<ul> +<li><a href="http://en.wikipedia.org/wiki/Stand-up_meeting">Stand-up meeting</a></li> +<li><a href="http://robots.thoughtbot.com/post/159806658/keeping-the-pressure-on">Blog post: Keeping the Pressure On</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/cpytel">@cpytel</a> on twitter.</p> + + + + Ben Orenstein is joined by Chad Pytel, the CEO and Founder of thoughtbot. Ben and Chad talk about the history of thoughtbot, success, failures, lessons learned, the current growth plans for the company, and much more. They also answer listener questions about hiring, growing, balancing client and internal work like open source and products, and contractor rates and how to set them.

+ + + +

Follow @thoughtbot, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Chad Pytel, the CEO and Founder of thoughtbot. Ben and Chad talk about the history of thoughtbot, success, failures, lessons learned, the current growth plans for the company, and much more. They also answer listener questions about hiring, growing, balancing client and internal work like open source and products, and contractor rates and how to set them.

+ + + +

Follow @thoughtbot, @r00k, and @cpytel on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+bpK4Jwvk + + ]]> + + + + 8: Wax on, Wax off + https://podcast.thoughtbot.com/8 + b27a1556-7144-4874-9d42-36867526f213 + Thu, 16 Aug 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Gabe Berke-Williams and Edward Loveall. Gabe is developer at thoughtbot and the product manager of the thoughtbot apprenticeship program, apprentice.io. Edward is a current design apprentice. Gabe, Edward, and Ben talk about apprentice.io, how it works, it's successes, and lessons learned. They also discuss how Gabe goes about mentoring new developers, and effective learning and teaching methods. Edward also gives his perspective on his apprenticeship how it went, his typical day as an apprentice, his advice for incoming apprentices, and much more. + + + 30:16 + no + + <p>Ben Orenstein is joined by Gabe Berke-Williams and Edward Loveall. Gabe is developer at thoughtbot and the product manager of the thoughtbot apprenticeship program, apprentice.io. Edward is a current design apprentice. Gabe, Edward, and Ben talk about apprentice.io, how it works, it's successes, and lessons learned. They also discuss how Gabe goes about mentoring new developers, and effective learning and teaching methods. Edward also gives his perspective on his apprenticeship how it went, his typical day as an apprentice, his advice for incoming apprentices, and much more.</p> +<ul> +<li><a href="http://apprentice.io">apprentice.io</a></li> +<li><a href="http://www.amazon.com/dp/0596518382">Apprenticship Patterns</a></li> +<li><a href="http://www.amazon.com/dp/1934356085/">The Pickaxe</a></li> +<li><a href="http://en.wikipedia.org/wiki/Red_black_trees">Red-Black Trees</a></li> +<li><a href="http://bostinno.com/channels/the-rise-of-the-software-apprenticeship-academy/">The Rise of The Software Apprenticeship Academy (BostInno)</a></li> +<li><a href="http://bostinno.com/all-series/lessons-learned-from-our-developmentdesigner-apprenticeship-program/">Lessons Learned From Our Development/Designer Apprenticeship Program (BostInno)</a></li> +<li><a href="http://en.wikipedia.org/wiki/Design_Patterns">&quot;Gang of Four&quot; Design Patterns</a></li> +<li><a href="http://intrepid.io">Intrepid Labs</a></li> +<li><a href="http://www.taketheinterview.com/">Take the Interview</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, <a href="http://twitter.com/gabebw">@gabebw</a> and <a href="http://twitter.com/edwardloveall">@edwardloveall</a> on twitter.</p> + + + + Ben Orenstein is joined by Gabe Berke-Williams and Edward Loveall. Gabe is developer at thoughtbot and the product manager of the thoughtbot apprenticeship program, apprentice.io. Edward is a current design apprentice. Gabe, Edward, and Ben talk about apprentice.io, how it works, it's successes, and lessons learned. They also discuss how Gabe goes about mentoring new developers, and effective learning and teaching methods. Edward also gives his perspective on his apprenticeship how it went, his typical day as an apprentice, his advice for incoming apprentices, and much more.

+ + + +

Follow @thoughtbot, @r00k, @gabebw and @edwardloveall on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Gabe Berke-Williams and Edward Loveall. Gabe is developer at thoughtbot and the product manager of the thoughtbot apprenticeship program, apprentice.io. Edward is a current design apprentice. Gabe, Edward, and Ben talk about apprentice.io, how it works, it's successes, and lessons learned. They also discuss how Gabe goes about mentoring new developers, and effective learning and teaching methods. Edward also gives his perspective on his apprenticeship how it went, his typical day as an apprentice, his advice for incoming apprentices, and much more.

+ + + +

Follow @thoughtbot, @r00k, @gabebw and @edwardloveall on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+YRtpzL_u + + ]]> + + + + 7: Something Else Was Smellier + https://podcast.thoughtbot.com/7 + 34654fd6-3c52-4a82-8954-dc6226426dc7 + Thu, 09 Aug 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is once again joined by Joe Ferris, CTO of thoughtbot. Joe and Ben dive right in to a technical discussion about Objects versus Structures. They then discuss what Joe does as the new CTO of thoughtbot, and how his goal is to set up a system where everybody is teaching everybody. Finally, they discuss why Joe doesn't like using rspec's let and subject, and his strategy for writing tests without them. + + + 34:08 + no + + <p>Ben Orenstein is once again joined by Joe Ferris, CTO of thoughtbot. Joe and Ben dive right in to a technical discussion about Objects versus Structures. They then discuss what Joe does as the new CTO of thoughtbot, and how his goal is to set up a system where everybody is teaching everybody. Finally, they discuss why Joe doesn't like using rspec's let and subject, and his strategy for writing tests without them.</p> +<ul> +<li>Object Mentor blog, <a href="http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects">Objects vs. Structures</a></li> +<li><a href="http://www.objectmentor.com/resources/articles/ocp.pdf">Robert Martin Shape Hierarchy (Open Closed Principle)</a></li> +<li><a href="http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672">Martin Fowler's Refactoring</a></li> +<li><a href="http://en.wikipedia.org/wiki/Code_smell">Code smell</a></li> +<li><a href="http://c2.com/cgi/wiki?SwitchStatementsSmell">Case statement code smell</a></li> +<li><a href="http://en.wikipedia.org/wiki/Visitor_pattern">Visitor pattern</a></li> +<li><a href="http://en.wikipedia.org/wiki/Shotgun_surgery">Shotgun surgery</a></li> +<li><a href="http://c2.com/cgi/wiki?MethodObject">Method object</a></li> +<li><a href="http://en.wikipedia.org/wiki/Composition_over_inheritance">Composition over inheritance</a></li> +<li><a href="http://github.com/thoughtbot/paperclip">paperclip</a></li> +<li><a href="http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627">Growing Object-Oriented Software, Guided by Tests</a></li> +<li>thoughtbot's <a href="http://apprentice.io">apprentice.io</a></li> +<li><a href="http://en.wikipedia.org/wiki/Parkinson&#x27;s_Law_of_Triviality">Parkinson's Law of Triviality (bikeshedding)</a></li> +<li><a href="http://en.wikipedia.org/wiki/Broken_windows_theory">Broken windows theory</a></li> +<li>rspec's <a href="https://www.relishapp.com/rspec/rspec-core/v/2-6/docs/helper-methods/let-and-let"><code>let</code></a> and <a href="https://www.relishapp.com/rspec/rspec-core/v/2-6/docs/subject/explicit-subject"><code>subject</code></a></li> +<li><a href="http://robots.thoughtbot.com/post/159805321/mystery-guest">Mystery Guest</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/r00k">@r00k</a>, and <a href="http://twitter.com/joeferris">@joeferris</a> on twitter.</p> + + + + Ben Orenstein is once again joined by Joe Ferris, CTO of thoughtbot. Joe and Ben dive right in to a technical discussion about Objects versus Structures. They then discuss what Joe does as the new CTO of thoughtbot, and how his goal is to set up a system where everybody is teaching everybody. Finally, they discuss why Joe doesn't like using rspec's let and subject, and his strategy for writing tests without them.

+ + + +

Follow @thoughtbot, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is once again joined by Joe Ferris, CTO of thoughtbot. Joe and Ben dive right in to a technical discussion about Objects versus Structures. They then discuss what Joe does as the new CTO of thoughtbot, and how his goal is to set up a system where everybody is teaching everybody. Finally, they discuss why Joe doesn't like using rspec's let and subject, and his strategy for writing tests without them.

+ + + +

Follow @thoughtbot, @r00k, and @joeferris on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+2Meb3caN + + ]]> + + + + 6: MVP of Personal Hygiene + https://podcast.thoughtbot.com/6 + 9b28d912-763f-459a-997d-c724384b45b8 + Thu, 02 Aug 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Dan Powell, founder of Abakas. Dan plays the role of Consulting CTO for his clients. They discuss the best and the worst of his job, his history as a Linux hacker, and what his experience has taught him about technology and technology trends, and how he stays on top of them. Also, how to create effective, well-written, maintainable software, the Rails talent crunch, developers getting promoted to management, maintaining work-life balance and how not to get burnt out, and much, much more. + + + 44:50 + no + + <p>Ben Orenstein is joined by Dan Powell, founder of Abakas. Dan plays the role of Consulting CTO for his clients. They discuss the best and the worst of his job, his history as a Linux hacker, and what his experience has taught him about technology and technology trends, and how he stays on top of them. Also, how to create effective, well-written, maintainable software, the Rails talent crunch, developers getting promoted to management, maintaining work-life balance and how not to get burnt out, and much, much more.</p> +<ul> +<li><a href="http://abakas.com/">Abakas</a></li> +<li><a href="http://www.linuxjournal.com/article/2549">Microway &quot;Screamer 533&quot;</a></li> +<li><a href="http://en.wikipedia.org/wiki/DEC_Multia">DEC Multia</a></li> +<li><a href="http://abakas.com/">Abakas</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a> and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Dan Powell, founder of Abakas. Dan plays the role of Consulting CTO for his clients. They discuss the best and the worst of his job, his history as a Linux hacker, and what his experience has taught him about technology and technology trends, and how he stays on top of them. Also, how to create effective, well-written, maintainable software, the Rails talent crunch, developers getting promoted to management, maintaining work-life balance and how not to get burnt out, and much, much more.

+ + + +

Follow @thoughtbot and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Dan Powell, founder of Abakas. Dan plays the role of Consulting CTO for his clients. They discuss the best and the worst of his job, his history as a Linux hacker, and what his experience has taught him about technology and technology trends, and how he stays on top of them. Also, how to create effective, well-written, maintainable software, the Rails talent crunch, developers getting promoted to management, maintaining work-life balance and how not to get burnt out, and much, much more.

+ + + +

Follow @thoughtbot and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7j76k9H_ + + ]]> + + + + 5: My wife is getting really into whiskey + https://podcast.thoughtbot.com/5 + d856343b-d082-4252-ae45-793e234920b8 + Thu, 26 Jul 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by “Cowboy” Ben Alman, JavaScript open source developer and Director of Pluginization at Bocoup. They discuss how Ben Alman got started with programming and his crazy projects, the open web, favorite tools, and one of his latest projects, Grunt. They also discuss CoffeeScript, and why Ben Alman’s not using it yet, speaking at conferences and how Ben Alman got more comfortable in front of crowds, whether its important to understand straight JavaScript, or just jQuery, and more! Also, Whiskey. + + + 48:36 + no + + <p>Ben Orenstein is joined by “Cowboy” Ben Alman, JavaScript open source developer and Director of Pluginization at Bocoup. They discuss how Ben Alman got started with programming and his crazy projects, the open web, favorite tools, and one of his latest projects, Grunt. They also discuss CoffeeScript, and why Ben Alman’s not using it yet, speaking at conferences and how Ben Alman got more comfortable in front of crowds, whether its important to understand straight JavaScript, or just jQuery, and more! Also, Whiskey.</p> +<ul> +<li><a href="http://benalman.com/">&quot;Cowboy&quot; Ben Alman</a></li> +<li><a href="http://bocoup.com/">Bocoup</a></li> +<li><a href="http://benalman.com/projects/">Ben Alman's enormous project listing</a></li> +<li><a href="http://bocoup.com/">Bocoup</a></li> +<li><a href="http://www.sublimetext.com/2">Sublime Text 2</a></li> +<li><a href="http://en.wikipedia.org/wiki/M%2B_Fonts">M+ monospace font</a></li> +<li><a href="https://github.com/cowboy/dotfiles">Ben Alman's dotfiles</a> and <a href="https://github.com/cowboy/dotfiles/blob/master/bin/gpr">gpr</a></li> +<li><a href="https://github.com/cowboy/grunt">Grunt</a> on github, <a href="http://weblog.bocoup.com/introducing-grunt/">Grunt introduction</a></li> +<li><a href="https://github.com/mde/jake/">jake</a></li> +<li><a href="http://www.jshint.com/">JSHint</a></li> +<li><a href="http://npmjs.org/">npm</a></li> +<li><a href="http://coffeescript.org/">CoffeeScript</a></li> +<li><a href="http://www.slideshare.net/BrendanEich/esnext">ES.next</a></li> +<li><a href="http://en.wikipedia.org/wiki/Variadic_function">Variadic function</a></li> +<li><a href="http://developer.yahoo.com/yui/compressor/">YUI Compressor</a></li> +<li><a href="http://en.wikipedia.org/wiki/Bulleit_Bourbon">Bulleit Bourbon</a></li> +<li><a href="http://en.wikipedia.org/wiki/The_Macallan">The Macallan</a></li> +<li><a href="http://benalman.com/music/big-ben-hillman-the-big-easy/">Big Ben Hillman @ The Big Easy</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/cowboy">@cowboy</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by “Cowboy” Ben Alman, JavaScript open source developer and Director of Pluginization at Bocoup. They discuss how Ben Alman got started with programming and his crazy projects, the open web, favorite tools, and one of his latest projects, Grunt. They also discuss CoffeeScript, and why Ben Alman’s not using it yet, speaking at conferences and how Ben Alman got more comfortable in front of crowds, whether its important to understand straight JavaScript, or just jQuery, and more! Also, Whiskey.

+ + + +

Follow @thoughtbot, @cowboy, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by “Cowboy” Ben Alman, JavaScript open source developer and Director of Pluginization at Bocoup. They discuss how Ben Alman got started with programming and his crazy projects, the open web, favorite tools, and one of his latest projects, Grunt. They also discuss CoffeeScript, and why Ben Alman’s not using it yet, speaking at conferences and how Ben Alman got more comfortable in front of crowds, whether its important to understand straight JavaScript, or just jQuery, and more! Also, Whiskey.

+ + + +

Follow @thoughtbot, @cowboy, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+_cJqbp-s + + ]]> + + + + 4: I've got a little thoughtbot angel or devil on my shoulder + https://podcast.thoughtbot.com/4 + 0b05d404-d798-4d99-82cf-f04501b0405c + Thu, 19 Jul 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by David Thyresson, the founder of Stattleship and a past client of thoughtbot. Ben and David discuss how he got started with Stattleship, how he came to work with thoughtbot, and what it was like to work with us. Also, how the idea of what he would initially build changed, and how through agile software development he discovered how it was wrong. How he learned Ruby on Rails from thoughtbot during his project. Finally, what has worked for driving visitors to the site, and important lessons learned about starting up, building an app, and running a business. + + + 37:37 + no + + <p>Ben Orenstein is joined by David Thyresson, the founder of Stattleship and a past client of thoughtbot. Ben and David discuss how he got started with Stattleship, how he came to work with thoughtbot, and what it was like to work with us. Also, how the idea of what he would initially build changed, and how through agile software development he discovered how it was wrong. How he learned Ruby on Rails from thoughtbot during his project. Finally, what has worked for driving visitors to the site, and important lessons learned about starting up, building an app, and running a business.</p> +<ul> +<li><a href="http://stattleship.com">Stattleship</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/stattleship">@stattleship</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by David Thyresson, the founder of Stattleship and a past client of thoughtbot. Ben and David discuss how he got started with Stattleship, how he came to work with thoughtbot, and what it was like to work with us. Also, how the idea of what he would initially build changed, and how through agile software development he discovered how it was wrong. How he learned Ruby on Rails from thoughtbot during his project. Finally, what has worked for driving visitors to the site, and important lessons learned about starting up, building an app, and running a business.

+ + + +

Follow @thoughtbot, @stattleship, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by David Thyresson, the founder of Stattleship and a past client of thoughtbot. Ben and David discuss how he got started with Stattleship, how he came to work with thoughtbot, and what it was like to work with us. Also, how the idea of what he would initially build changed, and how through agile software development he discovered how it was wrong. How he learned Ruby on Rails from thoughtbot during his project. Finally, what has worked for driving visitors to the site, and important lessons learned about starting up, building an app, and running a business.

+ + + +

Follow @thoughtbot, @stattleship, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+7XdPAvLI + + ]]> + + + + 3: The FactoryGirl Representation of a Factory + https://podcast.thoughtbot.com/3 + cd86b5f6-cea2-4d34-b80a-46c6fd5bafce + Thu, 12 Jul 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined by Josh Clayton, the maintainer of FactoryGirl, and a developer at thoughtbot. Ben and Josh discuss FactoryGirl: using it, its development progress, and features. What it's like to run an open source project, and how to contribute to open source effectively. Looking at your old code and being a better developer. Approaches to testing. And answer your questions about: FactoryGirl, How to write effective tests suites and whether integration tests are a scam, our process for upgrading between Rails versions, testing complex UI logic, and leaving code untested. + + + 40:22 + no + + <p>Ben Orenstein is joined by Josh Clayton, the maintainer of FactoryGirl, and a developer at thoughtbot. Ben and Josh discuss FactoryGirl: using it, its development progress, and features. What it's like to run an open source project, and how to contribute to open source effectively. Looking at your old code and being a better developer. Approaches to testing. And answer your questions about: FactoryGirl, How to write effective tests suites and whether integration tests are a scam, our process for upgrading between Rails versions, testing complex UI logic, and leaving code untested.</p> +<ul> +<li><a href="https://github.com/thoughtbot/factory_girl">FactoryGirl</a></li> +<li><a href="http://pragprog.com/book/ruby3/programming-ruby-1-9">The Pickaxe</a></li> +<li><a href="https://github.com/thoughtbot/factory_girl_rails">factory_girl_rails</a></li> +<li><a href="https://groups.google.com/group/factory_girl">factory_girl Google Group</a></li> +<li><a href="http://arjanvandergaag.nl/blog/factory_girl_tips.html">FactoryGirl Tips and Tricks</a></li> +<li><a href="http://www.infoq.com/presentations/integration-tests-scam/">Integration Tests Are a Scam</a></li> +<li><a href="http://www.lonestarrubyconf.com/">Lone Star Ruby Conference</a></li> +</ul> +<p>Follow <a href="http://twitter.com/thoughtbot">@thoughtbot</a>, <a href="http://twitter.com/joshuaclayton">@joshuaclayton</a>, and <a href="http://twitter.com/r00k">@r00k</a> on twitter.</p> + + + + Ben Orenstein is joined by Josh Clayton, the maintainer of FactoryGirl, and a developer at thoughtbot. Ben and Josh discuss FactoryGirl: using it, its development progress, and features. What it's like to run an open source project, and how to contribute to open source effectively. Looking at your old code and being a better developer. Approaches to testing. And answer your questions about: FactoryGirl, How to write effective tests suites and whether integration tests are a scam, our process for upgrading between Rails versions, testing complex UI logic, and leaving code untested.

+ + + +

Follow @thoughtbot, @joshuaclayton, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined by Josh Clayton, the maintainer of FactoryGirl, and a developer at thoughtbot. Ben and Josh discuss FactoryGirl: using it, its development progress, and features. What it's like to run an open source project, and how to contribute to open source effectively. Looking at your old code and being a better developer. Approaches to testing. And answer your questions about: FactoryGirl, How to write effective tests suites and whether integration tests are a scam, our process for upgrading between Rails versions, testing complex UI logic, and leaving code untested.

+ + + +

Follow @thoughtbot, @joshuaclayton, and @r00k on twitter.

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+1Ap5364e + + ]]> + + + + 2: Design with a sip of Bourbon + https://podcast.thoughtbot.com/2 + d9eae58b-6179-42aa-a12d-7da2f6c65f50 + Fri, 22 Jun 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein is joined this week by Phil LaPier, the creator of Bourbon and a designer at thoughtbot. Ben and Phil discuss the design process, fundamentals of visual design, common design errors, and how to be a better designer (even if you're a developer), and how to work with designers as a developer. They also answer some audience questions about design: How to handle feedback from clients, and HAML vs. HTML. + + + 35:36 + no + + <p>Ben Orenstein is joined this week by Phil LaPier, the creator of Bourbon and a designer at thoughtbot. Ben and Phil discuss the design process, fundamentals of visual design, common design errors, and how to be a better designer (even if you're a developer), and how to work with designers as a developer. They also answer some audience questions about design: How to handle feedback from clients, and HAML vs. HTML.</p> +<ul> +<li><a href="http://thoughtbot.com/bourbon">Bourbon</a></li> +<li><a href="http://dribbble.com">Dribbble</a></li> +<li><a href="http://dribbble.com/simplebits">Dan Cederholm - Dribbble</a></li> +<li><a href="http://twitter.com/LeaVerou">Lea Verou - Twitter</a></li> +<li><a href="http://twitter.com/bdc">Benjamin De Cock - Twitter</a></li> +<li><a href="http://twitter.com/jasonsantamaria">Jason Santa Maria - Twitter</a></li> +<li><a href="http://twitter.com/TrentWalton">Trent Walton</a></li> +<li><a href="http://www.adobe.com/products/fireworks.html">Adobe Fireworks</a></li> +<li><a href="http://thoughtbot.com/bourbon">Bourbon</a></li> +<li><a href="http://sass-lang.com/">Sass</a></li> +<li><a href="http://thoughtbot.com/bourbon/#grid-width">Bourbon Grid-Width</a></li> +<li><a href="http://thoughtbot.com/bourbon/#font-family">Bourbon Font Stacks</a></li> +</ul> + + + + Ben Orenstein is joined this week by Phil LaPier, the creator of Bourbon and a designer at thoughtbot. Ben and Phil discuss the design process, fundamentals of visual design, common design errors, and how to be a better designer (even if you're a developer), and how to work with designers as a developer. They also answer some audience questions about design: How to handle feedback from clients, and HAML vs. HTML.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein is joined this week by Phil LaPier, the creator of Bourbon and a designer at thoughtbot. Ben and Phil discuss the design process, fundamentals of visual design, common design errors, and how to be a better designer (even if you're a developer), and how to work with designers as a developer. They also answer some audience questions about design: How to handle feedback from clients, and HAML vs. HTML.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+Mm3MUUly + + ]]> + + + + 1: Polymorphism vs. Conditionals + https://podcast.thoughtbot.com/1 + 83f5b9c2-dde2-4c17-9e9f-b91f45933f4e + Mon, 11 Jun 2012 20:00:00 -0400 + thoughtbot + + full + 1 + thoughtbot + Ben Orenstein and Joe Ferris (and the surprise special guest Seana Quental) start the series off with a very technical discussion about Polymorphism vs. Conditionals. We also answer some of the audience questions we asked for last week. + + + 31:13 + no + + <p>Ben Orenstein and Joe Ferris (and the surprise special guest Seana Quental) start the series off with a very technical discussion about Polymorphism vs. Conditionals. We also answer some of the audience questions we asked for last week.</p> +<ul> +<li><a href="http://www.nongnu.org/cvs/">CVS</a></li> +<li><a href="http://subversion.apache.org/">SVN</a></li> +<li><a href="http://git-scm.com/">Git</a></li> +<li><a href="http://robots.thoughtbot.com/post/2831837714/feature-branch-code-reviews">Feature branch code reviews</a></li> +<li><a href="http://git-scm.com/book/en/Git-Branching-Rebasing">Rebasing</a></li> +<li><a href="http://en.wikipedia.org/wiki/Composition_over_inheritance">Composition over Inheritance</a></li> +<li><a href="http://objectsonrails.com/">Objects on Rails, Avdi Grimm</a></li> +<li><a href="http://en.wikipedia.org/wiki/Null_Object_pattern">NullObject</a></li> +<li><a href="http://robots.thoughtbot.com/post/20907555103/rails-refactoring-example-introduce-null-object">Rails Refactoring Example: Introduce Null Object</a></li> +<li><a href="http://api.rubyonrails.org/classes/Object.html#method-i-try">#try</a></li> +<li><a href="http://en.wikipedia.org/wiki/God_object">God objects</a></li> +<li><a href="http://www.youtube.com/watch?v=rI8tNMsozo0">Rich Hickey's Railsconf Keynote</a></li> +<li><a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html">Kingdom of Nouns, Steve Yeggie</a></li> +<li><a href="http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/">Ruby blocks</a></li> +<li><a href="http://en.wikipedia.org/wiki/Strategy_pattern">StrategyPattern</a></li> +<li><a href="http://en.wikipedia.org/wiki/Command_pattern">CommandPattern</a></li> +<li><a href="http://github.com/thoughtbot/clearance">Clearance</a></li> +<li><a href="http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612">Gang of Four Design Patterns</a></li> +</ul> + + + + Ben Orenstein and Joe Ferris (and the surprise special guest Seana Quental) start the series off with a very technical discussion about Polymorphism vs. Conditionals. We also answer some of the audience questions we asked for last week.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + + Ben Orenstein and Joe Ferris (and the surprise special guest Seana Quental) start the series off with a very technical discussion about Polymorphism vs. Conditionals. We also answer some of the audience questions we asked for last week.

+ +

Support Giant Robots Smashing Into Other Giant Robots

]]> + + https://fireside.fm/player/v2/DiNRb69N+D-u06JFt + + ]]> + + + + diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb index 6388b5f..7c2f017 100644 --- a/spec/spec_helper.rb +++ b/spec/spec_helper.rb @@ -9,3 +9,9 @@ Excon.stubs.clear end end + +RSpec::Matchers.define :match_date do |expected| + match do |actual| + expect(expected.strftime("%d-%m-%Y")).to eq(actual.strftime("%d-%m-%Y")) + end +end